ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F |
---|---|
管理番号 | 1200961 |
審判番号 | 不服2005-16285 |
総通号数 | 117 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2009-09-25 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2005-08-25 |
確定日 | 2009-07-23 |
事件の表示 | 特願2002-350379「双方向通信方法」拒絶査定不服審判事件〔平成15年 9月 5日出願公開、特開2003-249919〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1.手続の経緯 本願は、平成14年12月2日(国内優先権主張 平成13年12月17日)の出願であって、平成17年7月20日付けで拒絶査定がなされ、これに対して、平成17年8月25日に拒絶査定不服審判が請求されるとともに、平成17年9月21日付けで手続補正がされ、平成21年2月16日付けで当審から拒絶理由が通知されたのに対して、平成21年4月20日付けで意見書が提出されるとともに、手続補正がされたものである。 第2.本願発明1について 1.本願発明1 本願の請求項1に係る発明(以下、「本願発明1」という。)は、平成21年4月20日付け手続補正書で補正された特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものと認める。 「 【請求項1】 レスポンス側との間にファイアウォールを備えたリクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側が前記レスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続け、 前記レスポンス側が前記リクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続ける、 ことを特徴とする双方向通信方法。」 2.刊行物に記載された発明 当審の拒絶理由に引用された特開2000-339253号公報(以下、「刊行物1」という。)には、図面とともに以下の記載がある。 (a)段落番号【0016】 「図2は図1のシステムにおけるHTMLデータ追加方法の処理を表わしたシーケンス図の一例であり、登録画面表示要求操作201、登録画面表示要求処理202、登録画面データ送信処理203、登録画面表示処理204、登録要求操作205、コンテンツデータ送信処理206、コンテンツデータ格納処理207、HTMLデータ生成処理208、アクセスインデックス作成処理209から成る。以下では本発明のHTMLデータ追加方法の一例について説明を行う。」 (b)段落番号【0017】 「登録画面表示要求処理202は、登録画面表示要求操作201を受けたクライアント装置110が、サーバ装置120に対して操作用画面の表示を要求する処理である。 登録画面データ送信処理203は、登録画面表示要求処理202を受けたサーバ装置120が、クライアント装置110に対して、操作用画面に対応するHTMLデータをWebサーバ部122から送信する処理である。」 (c)段落番号【0017】 「コンテンツデータ送信処理206は、登録要求操作205を受けたクライアント装置110がサーバ装置120に対して、コンテンツデータ送信部115からコンテンツデータを送信する処理である。」 したがって、刊行物1には、次の発明(以下、「刊行物1記載の発明」と呼ぶ。)が記載されている。 「 登録画面表示要求操作201、登録画面表示要求処理202、登録画面データ送信処理203、登録画面表示処理204、登録要求操作205、コンテンツデータ送信処理206、コンテンツデータ格納処理207、HTMLデータ生成処理208、アクセスインデックス作成処理209から成るHTMLデータ追加方法であって、 登録画面表示要求処理202は、登録画面表示要求操作201を受けたクライアント装置110が、サーバ装置120に対して操作用画面の表示を要求する処理であり、 登録画面データ送信処理203は、登録画面表示要求処理202を受けたサーバ装置120が、クライアント装置110に対して、操作用画面に対応するHTMLデータをWebサーバ部122から送信する処理であり、 コンテンツデータ送信処理206は、登録要求操作205を受けたクライアント装置110がサーバ装置120に対して、コンテンツデータ送信部115からコンテンツデータを送信する処理である HTMLデータ追加方法。」 また、同じく当審の拒絶理由に引用された特開平10-187575号公報(以下、「刊行物2」という。)には、図面とともに以下の記載がある。 (d)段落番号【0015】 「 或る実施例では、特に使用されるWANがインターネットである場合、クライアント・プロセッサ110(2)からサーバー・プロセッサ120へのネットワーク経路が不法あるいは不必要なネットワーク・トラフィックを除去する1つまたはそれ以上のファイアウォール132を包含していてもよい。この場合、ファイアウォール132は本発明の実施例で使用されるネットワーク・メッセージの通過を妨げる。それ故、ファイアウォール・ネゴシエータ134を設けてこのようなネットワーク・メッセージをクライアント・プロセッサ110(2)からサーバー・プロセッサ120までネットワーク経路全体を横切らせるようにしてもよい。ファイアウォール、ファイアウォール・ネゴシエータはこの技術分野では周知のものである。」 (e)段落番号【0017】 「 API114はクライアント通信マネージャ116(CCM)と通信してネットワーク130を横切ってメッセージをゲートウェイ実行プログラム122との間でやり取りする。或る実施例においては、API114とCCM116のコネクション115は、本発明を用いて処理されるトランザクションのACIDプロパティを保証するプロセスを含むアクティブなものであってもよい。ACIDプロパティとはアトミシティー、コンシステンシー、アイソレーション、デュラビリティーであり、この技術分野では周知のものである。CCM116はネットワークに付属する。 ゲートウェイ実行プログラム122はサーバー・プロセッサ120上で実行され、ネットワーク130に付属していて1つまたはそれ以上のCCM116によって送られてきたメッセージを処理する。メッセージの受信に応答して、ゲートウェイ実行プログラム122はメッセージをそれぞれのCCM116に送ることができる。本発明の一実施例においては、サーバー・プロセッサ120との通信を開始するのはクライアント・プロセッサ110であるが、その逆はない。ゲートウェイ実行プログラム122からCCM116へ送られたメッセージはCCM116から送られてきた或る種のより早期のメッセージに応答したものである。」 また、同じく当審の拒絶理由に引用された特開平10-190768号公報(以下、「刊行物3」という。)には、図面とともに以下の記載がある。 (f)段落番号【0038】 「 通信端末装置は、プロバイダのコンピュータ (以下、サーバという) との回線が設定されると、例えば、PAP(Password Authentication Protocol)に従って、ユーザIDとパスワードを、プロバイダから Ackまたは Nack を受信するまで送信し続ける。」 また、同じく当審の拒絶理由に引用された国際公開00/59155号パンフレット(以下、「刊行物4」という。)には、図面とともに以下の記載がある。なお、刊行物4はドイツ語で書かれた文献であるが、特許庁の起案システムにはドイツ語のウムラウトを表記する機能がないので、アウンダーラインでウムラウトを表すことにして、たとえば「aのウムラウト」を「a」で表すことにする。 (g)刊行物4の第11ページ第32行-第12ページ第4行 「Nach erfolgter Ablage des(verschlusselten) Dokumentes wird eine vom Server mit dessen personlichem Schlussel signierte Empfangsbestatigung an den Absender zuruckgegeben als zweifelsfreier Nachweis der erfolgten Ablage des Dokumentes.」 (訳文:(暗号化された)文書の保存に成功した後、文書の保存に間違いなく成功した証拠として、サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される。) (h)刊行物4の第14ページ第5行-第8行 「Eine vom Empfanger mit dessen personlichem Schlussel signierte Empfangsbestatigung wird an den Server zuruckgegeben als zweifelsfreier Nachweis der erfolgten Ubermittlung des Dokumentes.」 (訳文:受信者の秘密鍵で署名された受信者の受信通知は、文書の保存に間違いなく成功した証拠として、サーバに返される。) また、同じく当審の拒絶理由に引用された特開2001-282624号公報(以下、「刊行物5」という。)には、図面とともに以下の記載がある。 (i)段落番号【0016】 「また送信側からの否認に対しては、送信側で行われたデジタル署名の存在によって否認の防止が可能である。」 3.本願発明1と刊行物1記載の発明の一致点・相違点 刊行物1記載の発明の登録画面表示要求処理202は、クライアント装置110がサーバ装置120に対して操作用画面の表示を要求する処理であり、本願発明1の「リクエスト側からレスポンス側への片方向のリクエスト」に相当する。そして、刊行物1記載の発明のクライアント装置110、サーバ装置120が、各々、本願発明1のリクエスト側、レスポンス側に相当する。 刊行物1記載の発明の登録画面データ送信処理203は、登録画面表示要求処理202を受けたサーバ装置120が、クライアント装置110に対して、操作用画面に対応するHTMLデータをWebサーバ部122から送信する処理であり、本願発明1の「該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンス」に相当する。そして、「操作用画面に対応するHTMLデータ」は、本願発明1の「レスポンス側がリクエスト側に向けて送信するメッセージ」に相当する。 刊行物1記載の発明のコンテンツデータ送信処理206は、クライアント装置110がサーバ装置120に対して、コンテンツデータ送信部115からコンテンツデータを送信する処理である。そして、「コンテンツデータ」が、本願発明1の「リクエスト側がレスポンス側に向けて送信するメッセージ」に相当する。 したがって、刊行物1記載の発明では、サーバ装置120がクライアント装置110に対してリクエストをすることはなく、またリクエストを受信していないサーバ装置120が、いきなりリクエストクライアント装置110に対してメッセージを送ることもなく、通信はサーバ装置120とクライアント装置110との間で双方向で行われているから、刊行物1記載の発明における通信は、クライアント装置110をリクエスト側、サーバ装置120をレスポンス側とした「リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いる双方向通信」である。 したがって、本願発明1と刊行物1記載の発明のクライアント装置110とサーバ装置120間の通信方法との一致点・相違点は以下のとおりである。 [一致点] 「 リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、 前記レスポンス側が前記リクエスト側に向けてメッセージを送信する 双方向通信方法。」である点。 [相違点] (ア)本願発明1では、リクエスト側がレスポンス側との間にファイアウォールを備えているのに対して、刊行物1記載の発明では、ファイアウォールについての記載がない点。 (イ)本願発明1では、リクエスト側がレスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続けるのに対して、 刊行物1記載の発明では、レスポンス側がメッセージを受信したことを、リクエスト側に返信するまで、リクエスト側が同じ該メッセージを前記レスポンス側に送信し続けることについての記載がない点。 (ウ)本願発明1では、レスポンス側がリクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続けるのに対して、 刊行物1記載の発明では、リクエスト側が該メッセージを受信したことを、新たな通信でレスポンス側に受信通知するまで、レスポンス側が同じ該メッセージを前記リクエスト側に送信し続けることについての記載がない点。 4.相違点の検討 (ア)刊行物2の段落番号【0015】に「特に使用されるWANがインターネットである場合、クライアント・プロセッサ110(2)からサーバー・プロセッサ120へのネットワーク経路が不法あるいは不必要なネットワーク・トラフィックを除去する1つまたはそれ以上のファイアウォール132を包含していてもよい。」と記載されている。 また、同段落番号【0015】には、「この場合、ファイアウォール132は本発明の実施例で使用されるネットワーク・メッセージの通過を妨げる。」と記載されている。この記載は、一見、「ファイアウォール132を設けることにより、ネットワーク・メッセージの通信ができなくなる。」と思わせる記載である。 しかし、同段落番号【0015】には「それ故、ファイアウォール・ネゴシエータ134を設けてこのようなネットワーク・メッセージをクライアント・プロセッサ110(2)からサーバー・プロセッサ120までネットワーク経路全体を横切らせるようにしてもよい。ファイアウォール、ファイアウォール・ネゴシエータはこの技術分野では周知のものである。」と記載されているから、ファイアウォール132と共にファイアウォール・ネゴシエータ134を設ければ、ネットワーク・メッセージをクライアント・プロセッサ110(2)とサーバー・プロセッサ120との間で通信できることが記載されている。 また、刊行物2の段落番号【0017】には、「API114はクライアント通信マネージャ116(CCM)と通信してネットワーク130を横切ってメッセージをゲートウェイ実行プログラム122との間でやり取りする。」及び「ゲートウェイ実行プログラム122はサーバー・プロセッサ120上で実行され、ネットワーク130に付属していて1つまたはそれ以上のCCM116によって送られてきたメッセージを処理する。メッセージの受信に応答して、ゲートウェイ実行プログラム122はメッセージをそれぞれのCCM116に送ることができる。本発明の一実施例においては、サーバー・プロセッサ120との通信を開始するのはクライアント・プロセッサ110であるが、その逆はない。ゲートウェイ実行プログラム122からCCM116へ送られたメッセージはCCM116から送られてきた或る種のより早期のメッセージに応答したものである。」と記載されており、ファイアウォール132と共にファイアウォール・ネゴシエータ134を設ければ、ネットワーク・メッセージをクライアント・プロセッサ110(2)とサーバー・プロセッサ120との間で通信できることが確認できる。 また、刊行物2の段落番号【0017】には、「本発明の一実施例においては、サーバー・プロセッサ120との通信を開始するのはクライアント・プロセッサ110であるが、その逆はない。」と記載されており、刊行物2の一実施例は、刊行物1記載の発明及び本願発明1と同じく、「リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステム」であることが前提となっている。 したがって、刊行物1記載の発明において、クライアント装置110がサーバ装置120との間にファイアウォールを備えることは、刊行物2から容易に想到できたことである。 (イ)及び(ウ)刊行物3の段落番号【0038】に「通信端末装置は、プロバイダのコンピュータ (以下、サーバという) との回線が設定されると、例えば、PAP(Password Authentication Protocol)に従って、ユーザIDとパスワードを、プロバイダから Ackまたは Nack を受信するまで送信し続ける。」と記載されているように、「メッセージを送信するとき、受信通知を受信するまでは、同じメッセージを送信し続けること」は周知である。 したがって、刊行物1記載の発明において、 「クライアント装置110がサーバ装置120に向けてメッセージを送信する際は、前記サーバ装置120がメッセージを受信したことを、前記クライアント装置110に返信するまで、同じ該メッセージを前記サーバ装置120に送信し続けること」及び 「サーバ装置120がクライアント装置110に向けてメッセージを送信する際は、前記クライアント装置110が該メッセージを受信したことを、新たな通信で前記サーバ装置120に受信通知するまで、同じ該メッセージを前記クライアント装置110に送信し続けること」 は、容易に想到できたことである。 そして、本願発明1の作用効果も、刊行物1?3に記載された発明から当業者が予測できる範囲のものである。 5.むすび 以上のとおり、本願発明1は、刊行物1?3に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 第3.本願発明2について 1.本願発明2 本願の請求項2に係る発明(以下、「本願発明2」という。)は、平成21年4月20日付け手続補正書で補正された特許請求の範囲の請求項2に記載された事項により特定される次のとおりのものと認める。 「 【請求項2】 リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側が前記レスポンス側に向けてメッセージを送信する際は、前記レスポンス側から該メッセージを受信したことを示す電子署名が付加された第一のメッセージの返信を受けるまで、同じメッセージを前記レスポンス側に送信し続け、 前記レスポンス側が前記リクエスト側からのリクエストに応じて該リクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、受信通知用電子署名が付加されたメッセージとして新たな通信で前記レスポンス側に受信通知するまで、同じメッセージを前記リクエスト側に送信し続ける ことを特徴とする双方向通信方法。」 2.刊行物に記載された発明 上記「第2.2.」に記載されたとおりである。 3.本願発明2と刊行物1記載の発明の一致点・相違点 本願発明2と刊行物1記載の発明のクライアント装置110とサーバ装置120間の通信方法との一致点・相違点は以下のとおりである。 [一致点] 「 リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、 前記レスポンス側が前記リクエスト側に向けてメッセージを送信する 双方向通信方法。」である点。 [相違点] (カ)本願発明2では、リクエスト側がレスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続けるのに対して、 刊行物1記載の発明では、レスポンス側がメッセージを受信したことを、リクエスト側に返信するまで、リクエスト側が同じ該メッセージを前記レスポンス側に送信し続けることについての記載がない点。 (キ)本願発明2では、レスポンス側がリクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続けるのに対して、 刊行物1記載の発明では、リクエスト側が該メッセージを受信したことを、新たな通信でレスポンス側に受信通知するまで、レスポンス側が同じ該メッセージを前記リクエスト側に送信し続けることについての記載がない点。 (ク)本願発明2では、「メッセージを受信したことを示すメッセージ」に電子署名が付加されているのに対して、刊行物1記載の発明では、「メッセージを受信したことを示すメッセージ」に電子署名を付加することが記載されていない点。 なお、平成21年4月20日付けの意見書において、「引用例2に開示のファイやウォールが本願の補正後の独立請求項1?3に記載のファイヤウォールと異なるので、」と主張しているが、本願発明2には「レスポンス側との間にファイアウォールを備えた」ことは規定されていない。 4.相違点の検討 (カ)及び(キ) 上記「第2.4.」で指摘したように、刊行物1記載の発明において、「クライアント装置110がサーバ装置120に向けてメッセージを送信する際は、前記サーバ装置120がメッセージを受信したことを、前記クライアント装置110に返信するまで、同じ該メッセージを前記サーバ装置120に送信し続けること」及び 「サーバ装置120がクライアント装置110に向けてメッセージを送信する際は、前記クライアント装置110が該メッセージを受信したことを、新たな通信で前記サーバ装置120に受信通知するまで、同じ該メッセージを前記クライアント装置110に送信し続けること」 は、容易に想到できたことである。 (ク)刊行物4には、「サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される」こと及び「受信者の秘密鍵で署名された受信者の受信通知が、サーバに返される」ことが記載されているから、刊行物1記載の発明において、「メッセージを受信したことを示すメッセージ」に電子署名を付加することは、容易に想到できたことである。 そして、本願発明2の作用効果も、刊行物1,3,4に記載された発明から当業者が予測できる範囲のものである。 5.むすび 以上のとおり、本願発明2は、刊行物1,3,4に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 第4.本願発明3について 1.本願発明3 本願の請求項3に係る発明(以下、「本願発明3」という。)は、平成21年4月20日付け手続補正書で補正された特許請求の範囲の請求項3に記載された事項により特定される次のとおりのものと認める。 「 【請求項3】 レスポンス側との間にファイアウォールを備えたリクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側から前記レスポンス側に向けたメッセージまたは、前記レスポンス側から前記リクエスト側に向けたメッセージにつき、該メッセージの送信側から送信される送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管し、 前記第一のメッセージの受信側から前記第一のメッセージの受信に応答して返信される受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管する ことを特徴とする双方向通方法。」 2.刊行物に記載された発明 上記「第2.2.」に記載されたとおりである。 3.本願発明3と刊行物1記載の発明の一致点・相違点 本願発明3と刊行物1記載の発明のクライアント装置110とサーバ装置120間の通信方法との一致点・相違点は以下のとおりである。 [一致点] 「 リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト/レスポンス型の同期通信のみを用いるシステムにおいて、 前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、 前記レスポンス側が前記リクエスト側に向けてメッセージを送信する 双方向通信方法。」である点。 [相違点] (サ)本願発明3では、リクエスト側がレスポンス側との間にファイアウォールを備えているのに対して、刊行物1記載の発明では、ファイアウォールについての記載がない点。 (シ)本願発明3では、メッセージの送信側から送信される送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管しているのに対して、刊行物1記載の発明では、メッセージに送信メッセージ用電子署名を付加すること及び 送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管することについての記載がない点。 (ス)本願発明3では、メッセージの受信に応答して返信される受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管しているのに対して、刊行物1記載の発明では、メッセージ受信通知に受信通知用電子署名を付加すること及び受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管することについての記載がない点。 4.相違点の検討 (サ)上記「第2.4.」で指摘したように、刊行物1記載の発明において、クライアント装置110がサーバ装置120との間にファイアウォールを備えることは、刊行物2から容易に想到できたことである。 (シ)刊行物5には「また送信側からの否認に対しては、送信側で行われたデジタル署名の存在によって否認の防止が可能である。」と記載されている。この記載は、送信側においてデジタル署名を作成し、送信データに付加して送ることを意味している。 また、刊行物5には「デジタル署名の存在によって」と記載されているから、送信側が否認したときに受信側がデジタル署名を所有していることが必要であることが明らかである。したがって、将来、送信側が否認したときに備えて、受信側が送信側で行われたデジタル署名付きの送信データを保管することは、記載されていなくても当業者にとって自明な事項である。 したがって、刊行物1記載の発明において、送信メッセージに送信メッセージ用電子署名を付加し、該送信メッセージ用電子署名が付加された送信メッセージを、該送信メッセージの受信側が保管することは、容易に想到できたことである。 (ス)刊行物4には、「サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される」こと及び「受信者の秘密鍵で署名された受信者の受信通知が、サーバに返される」ことが記載されている。 また、刊行物4には「(暗号化された)文書の保存に成功した後、文書の保存に間違いなく成功した証拠として、」及び「文書の保存に間違いなく成功した証拠として、」と記載されているから、将来において証拠となるような署名付き受信通知を保管しておくことは、記載されていなくても当業者にとって自明な事項である。 したがって、刊行物1記載の発明において、「メッセージを受信したことを示す受信通知」に電子署名を付加し、該電子署名が付加された「メッセージを受信したことを示す受信通知」を、該メッセージの送信側が保管することは、容易に想到できたことである。 そして、本願発明3の作用効果も、刊行物1,2,4,5に記載された発明から当業者が予測できる範囲のものである。 5.むすび 以上のとおり、本願発明3は、刊行物1,2,4,5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 第5.全体のむすび 以上のとおり、本願発明1?3は特許法第29条2項の規定により特許を受けることができないものであり、請求項4に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。 |
審理終結日 | 2009-05-21 |
結審通知日 | 2009-05-26 |
審決日 | 2009-06-08 |
出願番号 | 特願2002-350379(P2002-350379) |
審決分類 |
P
1
8・
121-
WZ
(G06F)
|
最終処分 | 不成立 |
前審関与審査官 | 石井 茂和 |
特許庁審判長 |
江口 能弘 |
特許庁審判官 |
篠塚 隆 清水 稔 |
発明の名称 | 双方向通信方法 |
代理人 | 西山 雅也 |
代理人 | 樋口 外治 |
代理人 | 石田 敬 |
代理人 | 土屋 繁 |
代理人 | 鶴田 準一 |