【事件の表示】
　特願２００２−３５０３７９「双方向通信方法」拒絶査定不服審判事件〔平成１５年　９月　５日出願公開、特開２００３−２４９９１９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯 
　本願は、平成１４年１２月２日（国内優先権主張　平成１３年１２月１７日）の出願であって、平成１７年７月２０日付けで拒絶査定がなされ、これに対して、平成１７年８月２５日に拒絶査定不服審判が請求されるとともに、平成１７年９月２１日付けで手続補正がされ、平成２１年２月１６日付けで当審から拒絶理由が通知されたのに対して、平成２１年４月２０日付けで意見書が提出されるとともに、手続補正がされたものである。
　
　　　 
第２．本願発明１について
　　
１．本願発明１
　本願の請求項１に係る発明（以下、「本願発明１」という。）は、平成２１年４月２０日付け手続補正書で補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものと認める。
　
「　【請求項１】　レスポンス側との間にファイアウォールを備えたリクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側が前記レスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続け、
　前記レスポンス側が前記リクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続ける、
ことを特徴とする双方向通信方法。」
　
　
２．刊行物に記載された発明 
　
　当審の拒絶理由に引用された特開２０００−３３９２５３号公報（以下、「刊行物１」という。）には、図面とともに以下の記載がある。 
　
（ａ）段落番号【００１６】
「図２は図１のシステムにおけるＨＴＭＬデータ追加方法の処理を表わしたシーケンス図の一例であり、登録画面表示要求操作２０１、登録画面表示要求処理２０２、登録画面データ送信処理２０３、登録画面表示処理２０４、登録要求操作２０５、コンテンツデータ送信処理２０６、コンテンツデータ格納処理２０７、ＨＴＭＬデータ生成処理２０８、アクセスインデックス作成処理２０９から成る。以下では本発明のＨＴＭＬデータ追加方法の一例について説明を行う。」
　
（ｂ）段落番号【００１７】
「登録画面表示要求処理２０２は、登録画面表示要求操作２０１を受けたクライアント装置１１０が、サーバ装置１２０に対して操作用画面の表示を要求する処理である。
　登録画面データ送信処理２０３は、登録画面表示要求処理２０２を受けたサーバ装置１２０が、クライアント装置１１０に対して、操作用画面に対応するＨＴＭＬデータをＷｅｂサーバ部１２２から送信する処理である。」
　
（ｃ）段落番号【００１７】
「コンテンツデータ送信処理２０６は、登録要求操作２０５を受けたクライアント装置１１０がサーバ装置１２０に対して、コンテンツデータ送信部１１５からコンテンツデータを送信する処理である。」
　
　したがって、刊行物１には、次の発明（以下、「刊行物１記載の発明」と呼ぶ。）が記載されている。 
　　
「　登録画面表示要求操作２０１、登録画面表示要求処理２０２、登録画面データ送信処理２０３、登録画面表示処理２０４、登録要求操作２０５、コンテンツデータ送信処理２０６、コンテンツデータ格納処理２０７、ＨＴＭＬデータ生成処理２０８、アクセスインデックス作成処理２０９から成るＨＴＭＬデータ追加方法であって、
　登録画面表示要求処理２０２は、登録画面表示要求操作２０１を受けたクライアント装置１１０が、サーバ装置１２０に対して操作用画面の表示を要求する処理であり、
　登録画面データ送信処理２０３は、登録画面表示要求処理２０２を受けたサーバ装置１２０が、クライアント装置１１０に対して、操作用画面に対応するＨＴＭＬデータをＷｅｂサーバ部１２２から送信する処理であり、
　コンテンツデータ送信処理２０６は、登録要求操作２０５を受けたクライアント装置１１０がサーバ装置１２０に対して、コンテンツデータ送信部１１５からコンテンツデータを送信する処理である
　ＨＴＭＬデータ追加方法。」
　
　
　また、同じく当審の拒絶理由に引用された特開平１０−１８７５７５号公報（以下、「刊行物２」という。）には、図面とともに以下の記載がある。　　
　　
（ｄ）段落番号【００１５】
「　或る実施例では、特に使用されるＷＡＮがインターネットである場合、クライアント・プロセッサ１１０（２）からサーバー・プロセッサ１２０へのネットワーク経路が不法あるいは不必要なネットワーク・トラフィックを除去する１つまたはそれ以上のファイアウォール１３２を包含していてもよい。この場合、ファイアウォール１３２は本発明の実施例で使用されるネットワーク・メッセージの通過を妨げる。それ故、ファイアウォール・ネゴシエータ１３４を設けてこのようなネットワーク・メッセージをクライアント・プロセッサ１１０（２）からサーバー・プロセッサ１２０までネットワーク経路全体を横切らせるようにしてもよい。ファイアウォール、ファイアウォール・ネゴシエータはこの技術分野では周知のものである。」
　
（ｅ）段落番号【００１７】
「　ＡＰＩ１１４はクライアント通信マネージャ１１６（ＣＣＭ）と通信してネットワーク１３０を横切ってメッセージをゲートウェイ実行プログラム１２２との間でやり取りする。或る実施例においては、ＡＰＩ１１４とＣＣＭ１１６のコネクション１１５は、本発明を用いて処理されるトランザクションのＡＣＩＤプロパティを保証するプロセスを含むアクティブなものであってもよい。ＡＣＩＤプロパティとはアトミシティー、コンシステンシー、アイソレーション、デュラビリティーであり、この技術分野では周知のものである。ＣＣＭ１１６はネットワークに付属する。
　ゲートウェイ実行プログラム１２２はサーバー・プロセッサ１２０上で実行され、ネットワーク１３０に付属していて１つまたはそれ以上のＣＣＭ１１６によって送られてきたメッセージを処理する。メッセージの受信に応答して、ゲートウェイ実行プログラム１２２はメッセージをそれぞれのＣＣＭ１１６に送ることができる。本発明の一実施例においては、サーバー・プロセッサ１２０との通信を開始するのはクライアント・プロセッサ１１０であるが、その逆はない。ゲートウェイ実行プログラム１２２からＣＣＭ１１６へ送られたメッセージはＣＣＭ１１６から送られてきた或る種のより早期のメッセージに応答したものである。」
　
　
　また、同じく当審の拒絶理由に引用された特開平１０−１９０７６８号公報（以下、「刊行物３」という。）には、図面とともに以下の記載がある。
　
（ｆ）段落番号【００３８】
「  通信端末装置は、プロバイダのコンピュータ (以下、サーバという) との回線が設定されると、例えば、ＰＡＰ(Password Authentication Protocol)に従って、ユーザＩＤとパスワードを、プロバイダから Ackまたは Nack を受信するまで送信し続ける。」
　
　
　また、同じく当審の拒絶理由に引用された国際公開００／５９１５５号パンフレット（以下、「刊行物４」という。）には、図面とともに以下の記載がある。なお、刊行物４はドイツ語で書かれた文献であるが、特許庁の起案システムにはドイツ語のウムラウトを表記する機能がないので、アウンダーラインでウムラウトを表すことにして、たとえば「ａのウムラウト」を「
ａ
　
（ｇ）刊行物４の第１１ページ第３２行−第１２ページ第４行 
 「Nach　erfolgter　Ablage　des（verschl
u
o
u
a
u
（訳文：（暗号化された）文書の保存に成功した後、文書の保存に間違いなく成功した証拠として、サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される。） 
　　 
（ｈ）刊行物４の第１４ページ第５行−第８行 
 「Eine　vom　Empf
a
o
u
a
u
U
（訳文：受信者の秘密鍵で署名された受信者の受信通知は、文書の保存に間違いなく成功した証拠として、サーバに返される。） 　　 
　
　
　また、同じく当審の拒絶理由に引用された特開２００１−２８２６２４号公報（以下、「刊行物５」という。）には、図面とともに以下の記載がある。 
　
（ｉ）段落番号【００１６】
「また送信側からの否認に対しては、送信側で行われたデジタル署名の存在によって否認の防止が可能である。」　
　
　 
３．本願発明１と刊行物１記載の発明の一致点・相違点 
　
　刊行物１記載の発明の登録画面表示要求処理２０２は、クライアント装置１１０がサーバ装置１２０に対して操作用画面の表示を要求する処理であり、本願発明１の「リクエスト側からレスポンス側への片方向のリクエスト」に相当する。そして、刊行物１記載の発明のクライアント装置１１０、サーバ装置１２０が、各々、本願発明１のリクエスト側、レスポンス側に相当する。
　
　刊行物１記載の発明の登録画面データ送信処理２０３は、登録画面表示要求処理２０２を受けたサーバ装置１２０が、クライアント装置１１０に対して、操作用画面に対応するＨＴＭＬデータをＷｅｂサーバ部１２２から送信する処理であり、本願発明１の「該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンス」に相当する。そして、「操作用画面に対応するＨＴＭＬデータ」は、本願発明１の「レスポンス側がリクエスト側に向けて送信するメッセージ」に相当する。　
　刊行物１記載の発明のコンテンツデータ送信処理２０６は、クライアント装置１１０がサーバ装置１２０に対して、コンテンツデータ送信部１１５からコンテンツデータを送信する処理である。そして、「コンテンツデータ」が、本願発明１の「リクエスト側がレスポンス側に向けて送信するメッセージ」に相当する。
　
　したがって、刊行物１記載の発明では、サーバ装置１２０がクライアント装置１１０に対してリクエストをすることはなく、またリクエストを受信していないサーバ装置１２０が、いきなりリクエストクライアント装置１１０に対してメッセージを送ることもなく、通信はサーバ装置１２０とクライアント装置１１０との間で双方向で行われているから、刊行物１記載の発明における通信は、クライアント装置１１０をリクエスト側、サーバ装置１２０をレスポンス側とした「リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いる双方向通信」である。
　
　したがって、本願発明１と刊行物１記載の発明のクライアント装置１１０とサーバ装置１２０間の通信方法との一致点・相違点は以下のとおりである。　
　
［一致点］
「　リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、
　前記レスポンス側が前記リクエスト側に向けてメッセージを送信する
双方向通信方法。」である点。
　
［相違点］
（ア）本願発明１では、リクエスト側がレスポンス側との間にファイアウォールを備えているのに対して、刊行物１記載の発明では、ファイアウォールについての記載がない点。　
　　
（イ）本願発明１では、リクエスト側がレスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続けるのに対して、
　刊行物１記載の発明では、レスポンス側がメッセージを受信したことを、リクエスト側に返信するまで、リクエスト側が同じ該メッセージを前記レスポンス側に送信し続けることについての記載がない点。
　
（ウ）本願発明１では、レスポンス側がリクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続けるのに対して、
　刊行物１記載の発明では、リクエスト側が該メッセージを受信したことを、新たな通信でレスポンス側に受信通知するまで、レスポンス側が同じ該メッセージを前記リクエスト側に送信し続けることについての記載がない点。
　　
　　
４．相違点の検討 
　　
（ア）刊行物２の段落番号【００１５】に「特に使用されるＷＡＮがインターネットである場合、クライアント・プロセッサ１１０（２）からサーバー・プロセッサ１２０へのネットワーク経路が不法あるいは不必要なネットワーク・トラフィックを除去する１つまたはそれ以上のファイアウォール１３２を包含していてもよい。」と記載されている。
　また、同段落番号【００１５】には、「この場合、ファイアウォール１３２は本発明の実施例で使用されるネットワーク・メッセージの通過を妨げる。」と記載されている。この記載は、一見、「ファイアウォール１３２を設けることにより、ネットワーク・メッセージの通信ができなくなる。」と思わせる記載である。
　しかし、同段落番号【００１５】には「それ故、ファイアウォール・ネゴシエータ１３４を設けてこのようなネットワーク・メッセージをクライアント・プロセッサ１１０（２）からサーバー・プロセッサ１２０までネットワーク経路全体を横切らせるようにしてもよい。ファイアウォール、ファイアウォール・ネゴシエータはこの技術分野では周知のものである。」と記載されているから、ファイアウォール１３２と共にファイアウォール・ネゴシエータ１３４を設ければ、ネットワーク・メッセージをクライアント・プロセッサ１１０（２）とサーバー・プロセッサ１２０との間で通信できることが記載されている。
　また、刊行物２の段落番号【００１７】には、「ＡＰＩ１１４はクライアント通信マネージャ１１６（ＣＣＭ）と通信してネットワーク１３０を横切ってメッセージをゲートウェイ実行プログラム１２２との間でやり取りする。」及び「ゲートウェイ実行プログラム１２２はサーバー・プロセッサ１２０上で実行され、ネットワーク１３０に付属していて１つまたはそれ以上のＣＣＭ１１６によって送られてきたメッセージを処理する。メッセージの受信に応答して、ゲートウェイ実行プログラム１２２はメッセージをそれぞれのＣＣＭ１１６に送ることができる。本発明の一実施例においては、サーバー・プロセッサ１２０との通信を開始するのはクライアント・プロセッサ１１０であるが、その逆はない。ゲートウェイ実行プログラム１２２からＣＣＭ１１６へ送られたメッセージはＣＣＭ１１６から送られてきた或る種のより早期のメッセージに応答したものである。」と記載されており、ファイアウォール１３２と共にファイアウォール・ネゴシエータ１３４を設ければ、ネットワーク・メッセージをクライアント・プロセッサ１１０（２）とサーバー・プロセッサ１２０との間で通信できることが確認できる。
　また、刊行物２の段落番号【００１７】には、「本発明の一実施例においては、サーバー・プロセッサ１２０との通信を開始するのはクライアント・プロセッサ１１０であるが、その逆はない。」と記載されており、刊行物２の一実施例は、刊行物１記載の発明及び本願発明１と同じく、「リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステム」であることが前提となっている。
　したがって、刊行物１記載の発明において、クライアント装置１１０がサーバ装置１２０との間にファイアウォールを備えることは、刊行物２から容易に想到できたことである。　
　　　
（イ）及び（ウ）刊行物３の段落番号【００３８】に「通信端末装置は、プロバイダのコンピュータ (以下、サーバという) との回線が設定されると、例えば、ＰＡＰ(Password Authentication Protocol)に従って、ユーザＩＤとパスワードを、プロバイダから Ackまたは Nack を受信するまで送信し続ける。」と記載されているように、「メッセージを送信するとき、受信通知を受信するまでは、同じメッセージを送信し続けること」は周知である。　
　したがって、刊行物１記載の発明において、
「クライアント装置１１０がサーバ装置１２０に向けてメッセージを送信する際は、前記サーバ装置１２０がメッセージを受信したことを、前記クライアント装置１１０に返信するまで、同じ該メッセージを前記サーバ装置１２０に送信し続けること」及び
「サーバ装置１２０がクライアント装置１１０に向けてメッセージを送信する際は、前記クライアント装置１１０が該メッセージを受信したことを、新たな通信で前記サーバ装置１２０に受信通知するまで、同じ該メッセージを前記クライアント装置１１０に送信し続けること」
は、容易に想到できたことである。
　
　そして、本願発明１の作用効果も、刊行物１〜３に記載された発明から当業者が予測できる範囲のものである。 
　　　 
５．むすび 
　以上のとおり、本願発明１は、刊行物１〜３に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
　
第３．本願発明２について
　
１．本願発明２
　本願の請求項２に係る発明（以下、「本願発明２」という。）は、平成２１年４月２０日付け手続補正書で補正された特許請求の範囲の請求項２に記載された事項により特定される次のとおりのものと認める。
　　
「　【請求項２】　リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側が前記レスポンス側に向けてメッセージを送信する際は、前記レスポンス側から該メッセージを受信したことを示す電子署名が付加された第一のメッセージの返信を受けるまで、同じメッセージを前記レスポンス側に送信し続け、
　前記レスポンス側が前記リクエスト側からのリクエストに応じて該リクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、受信通知用電子署名が付加されたメッセージとして新たな通信で前記レスポンス側に受信通知するまで、同じメッセージを前記リクエスト側に送信し続ける
　ことを特徴とする双方向通信方法。」
　
　　
２．刊行物に記載された発明 
　上記「第２．２．」に記載されたとおりである。
　
　
３．本願発明２と刊行物１記載の発明の一致点・相違点 
　
　本願発明２と刊行物１記載の発明のクライアント装置１１０とサーバ装置１２０間の通信方法との一致点・相違点は以下のとおりである。　
　
［一致点］
「　リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、
　前記レスポンス側が前記リクエスト側に向けてメッセージを送信する
双方向通信方法。」である点。
　
［相違点］
（カ）本願発明２では、リクエスト側がレスポンス側に向けてメッセージを送信する際は、前記レスポンス側がメッセージを受信したことを、前記リクエスト側に返信するまで、同じ該メッセージを前記レスポンス側に送信し続けるのに対して、
　刊行物１記載の発明では、レスポンス側がメッセージを受信したことを、リクエスト側に返信するまで、リクエスト側が同じ該メッセージを前記レスポンス側に送信し続けることについての記載がない点。
　
（キ）本願発明２では、レスポンス側がリクエスト側に向けてメッセージを送信する際は、前記リクエスト側が該メッセージを受信したことを、新たな通信で前記レスポンス側に受信通知するまで、同じ該メッセージを前記リクエスト側に送信し続けるのに対して、
　刊行物１記載の発明では、リクエスト側が該メッセージを受信したことを、新たな通信でレスポンス側に受信通知するまで、レスポンス側が同じ該メッセージを前記リクエスト側に送信し続けることについての記載がない点。
　
（ク）本願発明２では、「メッセージを受信したことを示すメッセージ」に電子署名が付加されているのに対して、刊行物１記載の発明では、「メッセージを受信したことを示すメッセージ」に電子署名を付加することが記載されていない点。
　
　なお、平成２１年４月２０日付けの意見書において、「引用例２に開示のファイやウォールが本願の補正後の独立請求項1〜３に記載のファイヤウォールと異なるので、」と主張しているが、本願発明２には「レスポンス側との間にファイアウォールを備えた」ことは規定されていない。
　
　
４．相違点の検討 
　
（カ）及び（キ）　上記「第２．４．」で指摘したように、刊行物１記載の発明において、「クライアント装置１１０がサーバ装置１２０に向けてメッセージを送信する際は、前記サーバ装置１２０がメッセージを受信したことを、前記クライアント装置１１０に返信するまで、同じ該メッセージを前記サーバ装置１２０に送信し続けること」及び
「サーバ装置１２０がクライアント装置１１０に向けてメッセージを送信する際は、前記クライアント装置１１０が該メッセージを受信したことを、新たな通信で前記サーバ装置１２０に受信通知するまで、同じ該メッセージを前記クライアント装置１１０に送信し続けること」
は、容易に想到できたことである。
　
（ク）刊行物４には、「サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される」こと及び「受信者の秘密鍵で署名された受信者の受信通知が、サーバに返される」ことが記載されているから、刊行物１記載の発明において、「メッセージを受信したことを示すメッセージ」に電子署名を付加することは、容易に想到できたことである。
　
　そして、本願発明２の作用効果も、刊行物１，３，４に記載された発明から当業者が予測できる範囲のものである。 
　
５．むすび 
　以上のとおり、本願発明２は、刊行物１，３，４に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
　
第４．本願発明３について
　
１．本願発明３
　本願の請求項３に係る発明（以下、「本願発明３」という。）は、平成２１年４月２０日付け手続補正書で補正された特許請求の範囲の請求項３に記載された事項により特定される次のとおりのものと認める。
　　
「　【請求項３】　レスポンス側との間にファイアウォールを備えたリクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側から前記レスポンス側に向けたメッセージまたは、前記レスポンス側から前記リクエスト側に向けたメッセージにつき、該メッセージの送信側から送信される送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管し、
　前記第一のメッセージの受信側から前記第一のメッセージの受信に応答して返信される受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管する
　ことを特徴とする双方向通方法。」
　
２．刊行物に記載された発明 
　上記「第２．２．」に記載されたとおりである。
　
３．本願発明３と刊行物１記載の発明の一致点・相違点 
　
　本願発明３と刊行物１記載の発明のクライアント装置１１０とサーバ装置１２０間の通信方法との一致点・相違点は以下のとおりである。　　
　
［一致点］
「　リクエスト側からレスポンス側への片方向のリクエストと該リクエストに対する前記レスポンス側から前記リクエスト側へのレスポンスを行うリクエスト／レスポンス型の同期通信のみを用いるシステムにおいて、
　前記リクエスト側が前記レスポンス側に向けてメッセージを送信し、
　前記レスポンス側が前記リクエスト側に向けてメッセージを送信する
双方向通信方法。」である点。
　
［相違点］
（サ）本願発明３では、リクエスト側がレスポンス側との間にファイアウォールを備えているのに対して、刊行物１記載の発明では、ファイアウォールについての記載がない点。　
　　
（シ）本願発明３では、メッセージの送信側から送信される送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管しているのに対して、刊行物１記載の発明では、メッセージに送信メッセージ用電子署名を付加すること及び
送信メッセージ用電子署名が付加された第一のメッセージを、該第一のメッセージの受信側が保管することについての記載がない点。
　
（ス）本願発明３では、メッセージの受信に応答して返信される受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管しているのに対して、刊行物１記載の発明では、メッセージ受信通知に受信通知用電子署名を付加すること及び受信通知用電子署名が付加されたメッセージ受信通知を、該第一のメッセージの送信側が保管することについての記載がない点。
　
　
４．相違点の検討 
　　
（サ）上記「第２．４．」で指摘したように、刊行物１記載の発明において、クライアント装置１１０がサーバ装置１２０との間にファイアウォールを備えることは、刊行物２から容易に想到できたことである。
　
（シ）刊行物５には「また送信側からの否認に対しては、送信側で行われたデジタル署名の存在によって否認の防止が可能である。」と記載されている。この記載は、送信側においてデジタル署名を作成し、送信データに付加して送ることを意味している。
　また、刊行物５には「デジタル署名の存在によって」と記載されているから、送信側が否認したときに受信側がデジタル署名を所有していることが必要であることが明らかである。したがって、将来、送信側が否認したときに備えて、受信側が送信側で行われたデジタル署名付きの送信データを保管することは、記載されていなくても当業者にとって自明な事項である。
　したがって、刊行物１記載の発明において、送信メッセージに送信メッセージ用電子署名を付加し、該送信メッセージ用電子署名が付加された送信メッセージを、該送信メッセージの受信側が保管することは、容易に想到できたことである。
　　
（ス）刊行物４には、「サーバの秘密鍵を用いて署名された受信通知が、サーバによって送信者に返される」こと及び「受信者の秘密鍵で署名された受信者の受信通知が、サーバに返される」ことが記載されている。
　また、刊行物４には「（暗号化された）文書の保存に成功した後、文書の保存に間違いなく成功した証拠として、」及び「文書の保存に間違いなく成功した証拠として、」と記載されているから、将来において証拠となるような署名付き受信通知を保管しておくことは、記載されていなくても当業者にとって自明な事項である。
　したがって、刊行物１記載の発明において、「メッセージを受信したことを示す受信通知」に電子署名を付加し、該電子署名が付加された「メッセージを受信したことを示す受信通知」を、該メッセージの送信側が保管することは、容易に想到できたことである。
　　
　そして、本願発明３の作用効果も、刊行物１，２，４，５に記載された発明から当業者が予測できる範囲のものである。 
　
　
５．むすび 
　以上のとおり、本願発明３は、刊行物１，２，４，５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
　
第５．全体のむすび
　以上のとおり、本願発明１〜３は特許法第２９条２項の規定により特許を受けることができないものであり、請求項４に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　
　よって、結論のとおり審決する。