【事件の表示】
　特願２００８−５１８７７６「ウェブ・サービスにおける秘密データ通信」拒絶査定不服審判事件〔平成１９年　１月　４日国際公開、ＷＯ２００７／０００３８６、平成２０年１２月　４日国内公表、特表２００８−５４４７１３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯
　本願は
２００６年０６月０６日（パリ条約による優先権主張外国庁受理２００５年６月２８日、アメリカ合衆国）を国際出願日とする出願であって、
平成１９年１２月１７日付けで特許法第１８４条の５第１項の規定による書面、及び、特許法第１８４条の４第１項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文が提出され、
平成２１年１月２２日付けで手続補正書が提出され、
同年２月１９日付けで審査請求がなされ、
平成２２年２月２５日付けで、拒絶理由通知（同年３月２日発送）がなされたが、請求人からは指定された期間内に意見書も手続補正書も提出されず、
同年７月２０日付けで拒絶査定（同年７月２７日発送）がなされ、
同年８月１８日付けで審判請求がされると共に、同日付けで手続補正書が提出されたものである。
　
　なお、平成２２年１１月１６日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２３年３月２５日付けで当該報告に対する意見を求める旨の審尋（同年３月２９日発送)がなされ、これに対して
同年６月２９日付けで回答書が提出されている。
　
　
２．本願発明の認定
　本願の請求項１に係る発明（以下「本願発明」と言う。）は、上記平成２２年８月１８日付けの手続補正書の請求項１に記載されたとおりの次のものと認める。
　
＜本願発明＞
「ウェブ・サービスにおける秘密データ通信のための方法であって、前記方法は、
　値を有する第１署名を帯びているエレメントを含む、暗号化されているリクエストをリクエスタからウェブ・サービスで受け取るステップと、
　前記第１署名の値を署名し、これにより第２署名を作成するステップと、
　前記ウェブ・サービスから前記第２署名を含む、暗号化したレスポンスを前記リクエスタに送るステップと、
　前記レスポンスが、前記第１署名の値を署名して作成された前記第２署名を含むことを前記リクエスタにより確認するステップと、
　を含むことを特徴とする方法。」
　
　
３．先行技術
　
（１）引用文献
　本願の出願前かつ本願の優先権主張日よりも前に頒布され、原審の拒絶の査定の理由である上記平成２２年２月２５日付けの拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
　
＜引用文献１＞
特開２００３−２９６１９２号公報（平成１５年１０月１７日出願公開）
　
　＜引用文献記載事項１−１＞
「【請求項１】 
サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、ＬＡＮなどに代表される通信手段と、サーバー用電子署名プログラムと、ＷＥＢサーバーとを少なくとも備えるサーバーシステムと、から構成され
電子署名・電子文書保管システム
　
　＜引用文献記載事項１−２＞
「【請求項４】 請求項１または２に記載の発明において、
前記のサーバーシステムにはさらに、クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、前記の電子文書に検証したことを示すサーバーの電子署名をした上で、クライアント端末の、ブラウザと連携して備えられるクライアント用電子署名プログラムに対し、サーバーの電子署名のされた前記の電子文書を送信する
　
　＜引用文献記載事項１−３＞
「【００５０】また、注文に対する注文請書など、返信用データファイルの選択を行い、またはあらかじめ返信用データファイルの設定をしておき（Ｓ１１７）、サーバーの電子署名を施したデータファイルをクライアント端末に返信するように、サーバー用電子署名プログラムにおいて設定しておくことができる。クライアント端末に返信するデータファイルは、クライアント端末から受信したファイルとは別のファイルを返信する場合には、返信メッセージ用データファイルを参照し選択して（Ｓ３００）、返信メッセージ用データファイルにサーバーの電子署名を挿入する（Ｓ３０１）。挿入はすべて自動処理とすることができる。
一方、クライアント端末から受信したデータファイルと同じファイルを返信する場合には、電子署名付きデータファイルにサーバーの電子署名を挿入して（Ｓ１１８）、クライアント端末に返信する（Ｓ１１９）。
　
　＜引用文献記載事項１−４＞
『【００５１】次に、
サーバーの電子署名付きデータファイルをクライアント端末において受信する（Ｓ１２１）。
クライアント端末においては、ブラウザを用いて、サーバーからの署名つきのデータファイルの確認や、データファイルの保存をすることができる（Ｓ１２２）。
　
　
＜引用文献２＞
国際公開第０３／０８８０５２号（２００３年４月１１日国際公開。特表２００５−５２２７７５号公報（平成１７年７月２８日公表）に対応。）
　
　＜引用文献記載事項２−１＞
「At step 406 , this message is digitally signed. To sign the message, a hash value is generated from the message content, and the resulting hash value is encrypted with a private encryption key of the client system 104 . All encryptions are based on the standard RSA public key encryption scheme, described at http://www.rsa.com; however, it will be apparent that other encryption schemes can alternatively be used. The encrypted hash, being the signature of the client system 104 , is added to the message, as follows:」（８頁１６行〜２１行）
（公表公報の対応部分：「【００２３】
　段階４０６において、このメッセージにデジタル署名を施す。即ち、このメッセージに署名するべく、メッセージコンテンツからハッシュ値を生成し、この結果生成されたハッシュ値をクライアントシステム１０４のプライベート暗号化キーによって暗号化するのである。尚、すべての暗号化は、ｈｔｔｐ：／／ｗｗｗ．ｒｓａ．ｃｏｍに記述さている標準的なＲＳＡパブリックキー暗号化方式に基づくものであるが、この代わりに、その他の暗号化方式を使用可能であることは明らかである。そして、クライアントシステム１０４の署名であるこの暗号化されたハッシュを、次のようにメッセージに付加する。」
　
　＜引用文献記載事項２−２＞
「At step 408 , the entire message is encrypted using a public encryption key of the information server 102 . This ensures that the message can only be decrypted by the information server 102 . At step 410 , the encrypted message is sent to the information server 102 using a suitable communications protocol, such as TCP/IP. The process then waits to receive a reply from the information server 102 at step 412 .」（８頁２４行〜２８行）
（公表公報の対応部分：「【００２５】
　 段階４０８において、このメッセージの全体を情報サーバ１０２のパブリック暗号化キーを使用して暗号化する。この結果、このメッセージを暗号解読できるのは、情報サーバ１０２のみとなる。そして、段階４１０において、この暗号化したメッセージを、ＴＣＰ／ＩＰなどの適切な通信プロトコルを使用して情報サーバ１０２に送信する。そして、本プロセスは、段階４１２において、情報サーバ１０２から回答を受信するべく待機することになる。」）
　
　＜引用文献記載事項２−３＞
「At step 520 , this message is encrypted with the client system's public key, and the encrypted reply is sent to the client system 104 at step 522 .」（１０頁２６行〜２７行）
（公表公報の対応部分：「【００３８】
　段階５２０において、このメッセージをクライアントシステムのパブリックキーによって暗号化し、この暗号化した回答を段階５２２においてクライアントシステム１０４に送信する。」）
　
　
＜引用文献３＞
特開２００５−５７４１７号公報（平成１７年３月３日出願公開）
　
　＜引用文献記載事項３−１＞
「【請求項２】
請求項１記載の電子文書交換システムにおいて、
 前記文書交換部が、
 前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を、その送信先の公開鍵を用いて暗号化した後、送信する構成を有することを特徴とする電子文書交換システム。」
　
　
（２）参考文献
　本願の出願前かつ本願の優先権主張日よりも前に頒布されされた刊行物である下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。（下線は当審付与。）
　
＜参考文献１＞
特表平１１−５０９３５４号公報（平成１１年８月１７日公表）
　
　＜参考文献記載事項１−１＞
『匿名の通信および公開キー・インフラストラクチャ、およびおそらくは公開キー証明（ＰＫＣ）の方法を提供するネットワークにおいて、本発明は所望の安全な匿名通信の方法を提供する。簡単に言えば、送信側はまず「主題質問」および自身のディジタル署名を含む暗号化した要求を作成する。この要求は匿名で１つまたは複数の受信側に送信される。各受信側は「主題応答」および自身のディジタル署名を含む暗号化した応答を作成する。「主題質問」および「主題応答」は特定のビジネスで使われる対応する情報セットの対、例えば特定の商品の説明および販売業者からのこれに対応するオファー、特定のサービスの要求およびサービス・プロバイダのこれに対応するオファー、またはオークションでの入札者の入札および競売人の応答を示す。』（第９頁第６行〜第１５行）
　
　
＜参考文献２＞
特開２００４−３１８９００号公報（平成１６年１１月１１日出願公開）
　
　＜参考文献記載事項２−１＞
「【請求項７１】
 前記支払手段、請求手段、決済処理手段並びに前記サービス提供手段のユーザ情報処理手段、マーチャント情報処理手段及び決済処理機関情報処理手段が、送信する前記メッセージデータにデジタル署名と封書化処理とを併せて施し、前記メッセージデータを受信した前記支払手段、請求手段、決済処理手段並びに前記サービス提供手段のユーザ情報処理手段、マーチャント情報処理手段及び決済処理機関情報処理手段の各々が、封書化されたメッセージデータの暗号を復号化して、デジタル署名の検証処理を行なうことを特徴とする請求項７０に記載のパーソナル電子決済システム。」
　
　＜参考文献記載事項２−２＞
「【０１１２】
 この時、パーソナル・クレジット端末100とクレジット決済装置101とは、伝送路105を用いて、赤外線通信を行ない、パーソナル・クレジット端末100とサービス提供システム102とは、伝送路106及び基地局104、さらに、デジタル通信回線107、デジタル公衆網108及びデジタル通信回線109を介して、デジタル無線電話によるデジタル電話通信を行ない、クレジット決済装置101とサービス提供システム102とは、デジタル電話通信回線110、デジタル公衆網108及びデジタル通信回線109を介してデジタル電話通信を行なう。そして、サービス提供システム102と決済システム103とは、デジタル通信回線111を介して、デジタルデータ通信を行なう。
 パーソナル・クレジット端末100とサービス提供システム102との通信、クレジット決済装置101とサービス提供システム102との通信、及び、サービス提供システム102と決済システム103との通信では、交換される決済情報を、全て、暗号化して通信する。暗号化には、秘密鍵方式の暗号処理と公開鍵方式の暗号処理とを組み合わせて、情報を電子封書化して通信する。」
　
　＜参考文献記載事項２−３＞
『【０１３６】
　次に、パーソナル・クレジット端末が、クレジット決済端末とサービス提供システムとに送信するメッセージを生成する際に行なうデジタル署名処理及び封書化処理について説明する。
　デジタル署名処理と封書化処理とは、クレジット決済端末でも同様の処理を行なうので、以下では、登場人物は、ユーザ、マーチャント、サービス提供者という呼び方はせず、Ａさん、Ｂさんというように、登場人物を一般化して説明する。
　デジタル署名は、公開鍵方式の暗号化処理の「プライベート鍵で暗号化したメッセージは、そのプライベート鍵に対応する公開鍵でしか復号化できない」という性質を利用して、メッセージに電子的な署名を施す処理である。
　図２０（ａ）、（ｂ）は、それぞれ、メッセージ(Message)に、Ａさんのデジタル署名をする場合のデジタル署名処理の手順を示すフロー図と、フローの概念解説図である。
　まず、ステップ2000で、ＣＰＵは、メッセージ2003に対して、ハッシュ関数演算を行ない、メッセージ・ダイジェスト2004を生成する。
　次に、ステップ2001で、ＣＰＵは、暗号処理プロセッサを用いて、メッセージ・ダイジェスト2004を、Ａさんのプライベート鍵で暗号化して、デジタルサイン2005を生成する。
　次に、ステップ2002で、ＣＰＵは、デジタルサイン2005を、もとのメッセージ2003に付加する。以上の手順によって、ＣＰＵは、Ａさんのデジタル署名をしたメッセージ2006を生成する。
　図２０（ｂ）の2006は、Ａさんのデジタル署名をしたメッセージを図示したものであり、以下では、デジタル署名されたメッセージは、図面の中では、2006のように、図示することとする。』
　
　
＜参考文献３＞　国際公開第０４／２８０７７号（２００４年４月１日国際公開。特表２００５−５３９４４１号公報（平成１７年１２月２２日公表）に対応。）
　
　＜参考文献記載事項３−１＞
「90. A method for controlling the distribution of digital data in a public key system using digital signatures on said digital data, said method comprising the steps of；.
　computing a hash value of said digital data by a sender;
　computing a first digital signature by said sender by encripting said hash value according to a first digital signature scheme using a first private key of a first public key pair;
　computing a secand digital signature by encripting said first digital signature according to a second digital signature scheme using a secand private key of a second public key pair;
　providing said second digital signature and said digital data to a recipient of said digital data;
　computing a first verification value of said second digital signature according to said second digital signature scheme using the public key of said second public key pair;
　computing a second verification value of said first verification value according to said first digital signature scheme using the public key of said first public key pair;
　obtaining a hash value of said digital data;
　comparing said obtained hash value and said second verification value; and 
　if said comparing step shows different values, establishing that the data distribution process to said recipient deviates from the intended process flow.」（６１頁５行〜２８行）
（公表公報の対応部分：「【請求項９０】
　公開鍵システムにおけるデジタルデータの配信を前記デジタルデータ上のデジタル署名を使用して制御するための方法であって、
　前記デジタルデータのハッシュ値を送信者により算出するステップと、
　第１のデジタル署名を前記送信者により、前記ハッシュ値を第１のデジタル署名スキームに従って第１の公開鍵対の第１の秘密鍵を使用して暗号化することによって算出するステップと、
　第２のデジタル署名を、前記第１のデジタル署名を第２のデジタル署名スキームに従って第２の公開鍵対の第２の秘密鍵を使用して暗号化することによって算出するステップと、
　前記第２のデジタル署名及び前記デジタルデータを前記デジタルデータの受信者へ供給するステップと、
　前記第２のデジタル署名の第１の検証値を前記第２のデジタル署名スキームに従って前記第２の公開鍵対の公開鍵を使用して算出するステップと、
　前記第１の検証値の第２の検証値を前記第１のデジタル署名スキームに従って前記第１の公開鍵対の公開鍵を使用して算出するステップと、
　前記デジタルデータのハッシュ値を取得するステップと、
　前記取得されたハッシュ値と前記第２の検証値とを比較するステップと、
　前記比較するステップの結果、値が異なれば、前記受信者へのデータ配信プロセスは意図されたプロセスフローから外れていることを確立するステップとを含む、方法。」）
　
　＜参考文献記載事項３−２＞
「According to a further embodiment of the present invention, afore described considerations regarding the layered encryption aspects also apply the public key signature schemes. In comparison to the described encryption schemes a public key based digital signature scheme only swaps the roles of all corresponding encryption and decryption processes. Whereby the previous encryption process corresponds to the verification step performed by the recipients and the respective decryption step as performed by the signer or sender of a digital data comprises the operations of the decryption step. Correspondingly applies the sender or signer of data its own private key and the recipient or signature verifier has to obtain the signers public key. Most used signature schemes additionally require a comparison step as part of the signature verification process of the computed and an expected result. Due to the same underlying public key system, the layered encryption and the specified and controlled distribution via predetermined network nodes can be applied to digital signatures. Typically when signing digital data, a hash function is applied on that data and the signing operation involving the signer's private key is performed on that computed hash value. In terms of a layered signature scheme, this would translate to signing the same successively at different signature layers with different private keys, and accordingly verifying it in corresponding verifying processes by the recipient(s).」（３３頁１５行〜３３行）
（公表公報の対応部分：「【００９８】
　本発明のさらなる実施形態によれば、層状の暗号化態様に関連して先に述べた考慮事項が公開鍵署名スキームにも当てはまる。先に述べた暗号化スキームに比較すると、公開鍵を基礎とするデジタル署名スキームは、対応する全ての暗号化及び復号化プロセスの役割を交換するだけである。これにより、先の暗号化プロセスは受信者によって実行される検証ステップに対応し、デジタルデータの署名者又は送信者によって実行される個々の復号化ステップは復号化ステップのオペレーションを含む。相応してデータの送信者又は署名者はその固有の秘密鍵を適用し、受信者又は署名の検証者は署名者の公開鍵を入手しなければならない。使用される大部分の署名スキームはさらに、算出され且つ予測された結果の署名検証プロセスの一部として比較ステップを必要とする。基礎的な公開鍵システムが同じであることから、層状の暗号化及び所定のネットワークノードを介する指定され且つ制御される配信をデジタル署名に適用することができる。デジタルデータへの署名に際しては、典型的にはハッシュ関数がそのデータに適用され且つ署名者の秘密鍵を包含する署名オペレーションがその算出されたハッシュ値に対して実行される。層状の署名スキームに関しては、これは異なる秘密鍵を有する、異なる署名層における連続的な署名へと移行し、受信者による対応する検証プロセスにおいて適宜これを検証する。」）
　
　＜参考文献記載事項３−３＞
「Usually one would generate a signature at one specific layer by hashing the data and the signature that was produced by the previous layer, since both together would form the message to be signed. Similar to the layered encryption, it would not be necessary to hash this complete message at each layer. Only the previously computed hash value has to be re-signed respectively with the associated private key of this layer, which might further involve some common data formatting or hashing according to the employed digital signature scheme. This would result in a digital signature for each layer that are mutually independent except that they are performed on the same hash value (of the same digital data in question). Therefore, alternatively, instead of the hash value, the actual signature (the signed hash value) of the respectively previous layer can be signed at each layer. Because the signatures of all (but the first) layers are issued not only on the hashed data but also on the signatures of the previous layer, this alternative has the advantage that it can be easier established and controlled which signature has been issued first and thus must be verified last, i.e. which signature corresponds to which signature layer. With this it is also possible, though not required in all instances, instead of signing the signature of the previous layer to hash the previous signature and sign this new hash value, which now accounts not only for the digital data but also for the previous signature and thus leads to the same conclusion as above. These layered signatures can be combined with those embodiments concerning the layered encryption process of the distributed digital data.」（３３頁３４行〜３４頁２２行）
（公表公報の対応部分：「【００９９】
 メッセージはデータ及び先行層によって生成された署名の双方によって形成されることから、通常、署名は、ある特定の層において両者をハッシュすることによって生成される。
層状の暗号化と同様に、各層でこのメッセージ全体をハッシュする必要はない。
従って代替として、ハッシュ値ではなく、各層において個々の先行層の実署名（署名されたハッシュ値）が署名されることが可能である。
先行署名をハッシュしてこの新しいハッシュ値に署名することもまた、全ての例において必要とされるわけではないが可能であり
　
　
＜参考文献４＞
特開平１０−１８７８３６号公報（平成１０年７月２１日出願公開）
　
　＜参考文献記載事項４−１＞
「【００４７】電子署名ＳＡ（Ｍ）の作成方法としては、任意のものを用いることができる。例えば、取り引き文書Ｍを所定の圧縮アルゴリズムで圧縮したり、ハッシュしたりしてデータ量を削減し、得られたデータを秘密鍵ＳＡで暗号化する方法がある。もちろん、取り引き文書Ｍをそのまま秘密鍵ＳＡで暗号化してもかまわない。」
　
　
４．引用発明の認定
　
（１）引用文献１には上記引用文献記載事項１−１や１−２のとおりの「電子署名・電子文書保管システム」が記載されているところ、これによってなされる「電子署名・電子文書保管方法」も開示されていると言える。
　したがって、引用文献１には「電子署名・電子文書保管システムによってなされる電子署名・電子文書保管方法」が記載されていると言える。
　
（２）該「電子署名・電子文書保管システム」は、上記引用文献記載事項１−１記載の通り、「サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、ＬＡＮなどに代表される通信手段と、サーバー用電子署名プログラムと、ＷＥＢサーバーとを少なくとも備えるサーバーシステムと、から構成され」るものである。
　
（３）そして、前記「サーバーシステム」は、上記引用文献記載事項１−２の如く「クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、前記の電子文書に検証したことを示すサーバーの電子署名をした上で、クライアント端末の、ブラウザと連携して備えられるクライアント用電子署名プログラムに対し、サーバーの電子署名のされた前記の電子文書を送信する」ものであるところ、上記引用文献記載事項１−３には、「サーバーの電子署名」がされる「前記の電子文書」としては「クライアント端末から受信したデータファイルと同じファイル」である「電子署名付きデータファイル」とすることも記載されている。
　したがって、引用文献１には「前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信」することも記載されていると言える。
　
（４）さらに、上記引用文献記載事項１−４の「サーバーの電子署名付きデータファイルをクライアント端末において受信する（Ｓ１２１）。」「クライアント端末においては、ブラウザを用いて、サーバーからの署名つきのデータファイルの確認や、データファイルの保存をすることができる（Ｓ１２２）。」との記載から、引用文献１には「前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信し、前記サーバーシステムからの署名つきのデータファイルの確認をする」ことも記載されていると言える。
　
　
（５）よって、引用文献には下記の引用発明が記載されていると認められる。
　
＜引用発明＞
「電子署名・電子文書保管システムによってなされる電子署名・電子文書保管方法であって
　該電子署名・電子文書保管システムは、サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、ＬＡＮなどに代表される通信手段と、サーバー用電子署名プログラムと、ＷＥＢサーバーとを少なくとも備えるサーバーシステムと、から構成され、
　前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信し、
　前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信し、前記サーバーシステムからの署名つきのデータファイルの確認をする方法。」
　
　
５．対比
　以下に、本願発明と引用発明とを比較する。
　
（１）引用発明における「電子署名・電子文書保管システム」が、「サーバーシステムにアクセスするために通信手段に接続され」る「クライアント端末」と、「インターネット、ＬＡＮなどに代表される通信手段と」、「ＷＥＢサーバーとを少なくとも備えるサーバーシステムと、から構成され」ており、しかも、引用発明においては「前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信し」、「前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信し」、「前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信」するのであるから、引用発明と本願発明とは「ウェブ・サービスにおける」「データ通信のための方法」と言えるものである点で一致すると言える。
　
（２）引用発明における「サーバーシステム」が提供するサービスは本願発明における「ウェブ・サービス」に対応付けられるものであるところ、前者は「ＷＥＢサーバー」を備えている事から見て、後者と同様に「ウェブ・サービス」とも言えるものである。
　
（３）引用発明における「クライアント端末」は、本願発明における「リクエスタ」に対応付けられるものであるところ、前者が「サーバーシステム」にサービスの要求をするものであることは明らかであるから、後者と同様に「リクエスタ」とも言えるものである。
　
（４）引用発明においては「前記サーバーシステム」が「前記クライアント端末から送信された電子署名のされた電子文書を受信」するものであるところ、通常「電子署名」とは、文字コード等の値をもつディジタル情報として表現され、該署名の対象となる情報の要素の一つとしてこれに付加されるものであるから、「電子署名のされた電子文書」とは「値を有する」「署名を帯びているエレメントを含む」ものとも言える。また、引用発明において「クライアント端末から」「電子文書」を「送信」することは、該文書の「電子署名・電子文書保管」を要求することに他ならないものであるから、これも「リクエスト」と言えるものである。
　したがって、引用発明と本願発明とは「値を有する第１署名を帯びているエレメントを含む、」「リクエストをリクエスタからウェブ・サービスで受け取るステップ」を有していると言えるものである点で一致すると言える。
　
（５）引用発明においては「サーバーシステム」が「該電子署名のされた電子文書に検証したことを示すサーバーの電子署名を」するのであるから、引用発明における「サーバーの電子署名」の対象には「前記クライアント端末から送信された」「電子文書」に付された「電子署名」も含まれていることは明らかである。
　したがって、引用発明と本願発明とは「前記第１署名の値を署名し、これにより第２署名を作成するステップ」を有していると言えるものである点でも一致すると言える。
　
（６）引用発明においては「サーバーシステム」が「該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信」するものであるところ、「該サーバーの電子署名のされた前記電子文書」は、上記「リクエスト」に対する「レスポンス」に他ならないものである。
　したがって、引用発明と本願発明とは「前記ウェブ・サービスから前記第２署名を含む、」「レスポンスを前記リクエスタに送るステップ」を有していると言えるものである点でも一致すると言える。
　
（７）そして、引用発明においては「前記クライアント端末において、前記サーバーシステムからの署名つきのデータファイルの確認をする」のであるから、引用発明と本願発明とは「前記レスポンスが、前記第１署名の値を署名して作成された前記第２署名を含むことを前記リクエスタにより確認するステップを」有していると言えるものである点でも一致すると言える。
　
　
（８）よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。
　
＜一致点＞
「ウェブ・サービスにおけ
るデ
　値を有する第１署名を帯びているエレメントを含む
、リ
　前記第１署名の値を署名し、これにより第２署名を作成するステップと、
　前記ウェブ・サービスから前記第２署名を含む
、レ
　前記レスポンスが、前記第１署名の値を署名して作成された前記第２署名を含むことを前記リクエスタにより確認するステップと、
　を含むことを特徴とする方法。」
（下線は上記２．の＜本願発明＞と相違する箇所。）
　
＜相違点＞
　本願発明におけるデータ通信は、リクエストもレスポンスも「暗号化」された「秘密」データ通信である点。（これに対し、引用文献１にはリクエストやレスポンスが「暗号化」された「秘密」データ通信であることの記載は無い。）
　
　
６．判断
　上記相違点について検討するに、送受信する情報を暗号化することで秘密データ通信を行うことは、当業者が従来から必要に応じて適宜に採用している周知慣用技術に過ぎないものである（必要があれば上記引用文献２（特に引用文献記載事項２−２、２−３）、上記引用文献３（特に引用文献記載事項３−３）、参考文献１（特に参考文献記載事項１−１）、参考文献２（特に参考文献記載事項２−１、２−２）等参照。）から、引用発明においてリクエストやレスポンスを暗号化して秘密データ通信を行うこと、即ち、上記相違点に係る構成を採用することも、当業者が必要に応じて適宜に採用し得たことである。
　
　してみると、本願発明の構成は引用文献１に記載された発明に基づいて、当業者が容易に想到し得たものである。
　また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用文献１に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
７．回答書の補正案について、
　なお、請求人は、上記平成２３年６月２９日付けの回答書において、請求項１を、
「ウェブ・サービスにおける秘密データ通信のための方法であって、前記方法は、
　値を有する第１署名を帯びているエレメントを含む、暗号化されているリクエストをリクエスタからウェブ・サービスで受け取るステップと、
　
前記ウェブ・サービスで、
ハッシュし秘密キーで当該ハッシュを暗号化する
を
　前記ウェブ・サービスから前記第２署名を含む、暗号化したレスポンスを前記リクエスタに送るステップと、
　
前記第２署名を前記秘密キーに対応するパブリック・キーで解読して前記第１署名の値のハッシュが得られることにより、
　を特徴とする方法。」
とする補正案を提示しているが、署名に際しハッシュと暗号化を行うことも、適宜に採用される周知慣用技術に他ならないものである（必要があれば引用文献２（特に上記引用文献記載事項２−１）、参考文献２（特に上記参考文献記載事項２−３）、参考文献３（特に上記参考文献記載事項３−１、３−２）、参考文献４（特に上記参考文献記載事項４−１）等参照。）から、仮に当該補正案通りの補正がなされたとしても、本審決の結論には影響しない。
　さらに、当該補正案の「前記第１署名の値をハッシュし秘密キーで当該ハッシュを暗号化する署名」との記載は、「前記第１署名の値」のみを「ハッシュ」及び「暗号化」の対象とし、リクエスト全体を「ハッシュ」及び「暗号化」の対象とはしない構成を表現しようとしているとの推測も可能であるが、このような構成は、本願の発明の詳細な説明や当初明細書等（平成１９年１２月１７日付けで提出された特許法第１８４条の４第１項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文等）に明記されるものではないので、係る補正が許されるものではない。しかも、メッセージ全体をハッシュせずに第１の署名をハッシュして暗号化することで第２の署名を算出することは、引用文献３（特に上記参考文献記載事項３−１、３−３）等に記載される如く、本願優先日前には公知となっていた技術思想であるから、仮に上記推測される構成のものへの補正が許されると仮定した場合でも、これに進歩性を認めることはできず、やはり、本審決の結論には影響しない。
　
　
８．むすび
　以上のとおり、本願請求項１に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、他の請求項についての検討をするまでもなく、本願は、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。