• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1250720
審判番号 不服2010-18647  
総通号数 147 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-03-30 
種別 拒絶査定不服の審決 
審判請求日 2010-08-18 
確定日 2012-01-18 
事件の表示 特願2008-518776「ウェブ・サービスにおける秘密データ通信」拒絶査定不服審判事件〔平成19年 1月 4日国際公開、WO2007/000386、平成20年12月 4日国内公表、特表2008-544713〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続きの経緯
本願は
2006年06月06日(パリ条約による優先権主張外国庁受理2005年6月28日、アメリカ合衆国)を国際出願日とする出願であって、
平成19年12月17日付けで特許法第184条の5第1項の規定による書面、及び、特許法第184条の4第1項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文が提出され、
平成21年1月22日付けで手続補正書が提出され、
同年2月19日付けで審査請求がなされ、
平成22年2月25日付けで、拒絶理由通知(同年3月2日発送)がなされたが、請求人からは指定された期間内に意見書も手続補正書も提出されず、
同年7月20日付けで拒絶査定(同年7月27日発送)がなされ、
同年8月18日付けで審判請求がされると共に、同日付けで手続補正書が提出されたものである。

なお、平成22年11月16日付けで特許法第164条第3項に定める報告(前置報告)がなされ、
平成23年3月25日付けで当該報告に対する意見を求める旨の審尋(同年3月29日発送)がなされ、これに対して
同年6月29日付けで回答書が提出されている。


2.本願発明の認定
本願の請求項1に係る発明(以下「本願発明」と言う。)は、上記平成22年8月18日付けの手続補正書の請求項1に記載されたとおりの次のものと認める。

<本願発明>
「ウェブ・サービスにおける秘密データ通信のための方法であって、前記方法は、
値を有する第1署名を帯びているエレメントを含む、暗号化されているリクエストをリクエスタからウェブ・サービスで受け取るステップと、
前記第1署名の値を署名し、これにより第2署名を作成するステップと、
前記ウェブ・サービスから前記第2署名を含む、暗号化したレスポンスを前記リクエスタに送るステップと、
前記レスポンスが、前記第1署名の値を署名して作成された前記第2署名を含むことを前記リクエスタにより確認するステップと、
を含むことを特徴とする方法。」


3.先行技術

(1)引用文献
本願の出願前かつ本願の優先権主張日よりも前に頒布され、原審の拒絶の査定の理由である上記平成22年2月25日付けの拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。)


<引用文献1>
特開2003-296192号公報(平成15年10月17日出願公開)

<引用文献記載事項1-1>
「【請求項1】 サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、LANなどに代表される通信手段と、サーバー用電子署名プログラムと、WEBサーバーとを少なくとも備えるサーバーシステムと、から構成され、前記のサーバーシステムは、クライアント端末に送信されクライアント端末のブラウザに表示されるコンテンツデータファイルに、電子文書と、電子文書への電子署名を行うクライアント用電子署名プログラムを起動させるための記述を含んで備えられ、前記のクライアント用電子署名プログラムは、ブラウザと連携し、クライアント端末においてブラウザに表示された前記のコンテンツデータファイルからクライアント用電子署名プログラムを起動させ、ブラウザに表示される前記の電子文書に電子署名をして、クライアント端末に記憶すると共に、サーバーシステムに送信する機能を備え、前記のサーバーシステムにはさらに、クライアント端末から送信された電子署名のされた電子文書を受信して、検証すると共に記憶する機能を備えることを特徴とする、電子署名・電子文書保管システム。」

<引用文献記載事項1-2>
「【請求項4】 請求項1または2に記載の発明において、前記のサーバーシステムにはさらに、クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、前記の電子文書に検証したことを示すサーバーの電子署名をした上で、クライアント端末の、ブラウザと連携して備えられるクライアント用電子署名プログラムに対し、サーバーの電子署名のされた前記の電子文書を送信することを特徴とする、電子署名・電子文書保管システム。」

<引用文献記載事項1-3>
「【0050】また、注文に対する注文請書など、返信用データファイルの選択を行い、またはあらかじめ返信用データファイルの設定をしておき(S117)、サーバーの電子署名を施したデータファイルをクライアント端末に返信するように、サーバー用電子署名プログラムにおいて設定しておくことができる。クライアント端末に返信するデータファイルは、クライアント端末から受信したファイルとは別のファイルを返信する場合には、返信メッセージ用データファイルを参照し選択して(S300)、返信メッセージ用データファイルにサーバーの電子署名を挿入する(S301)。挿入はすべて自動処理とすることができる。一方、クライアント端末から受信したデータファイルと同じファイルを返信する場合には、電子署名付きデータファイルにサーバーの電子署名を挿入して(S118)、クライアント端末に返信する(S119)。返信される電子署名付きデータファイルは、サーバーの記憶手段に記憶する(S120)。」

<引用文献記載事項1-4>
『【0051】次に、サーバーの電子署名付きデータファイルをクライアント端末において受信する(S121)。たとえば図11に示すように、注文に対する注文請書のサーバーからの通知を行う画面(コンテンツデータファイル)を送信してクライアント端末に表示させるような方式を採用することもできる。クライアント端末においては、ブラウザを用いて、サーバーからの署名つきのデータファイルの確認や、データファイルの保存をすることができる(S122)。図12にサーバーの署名付き電子文書の保存処理をする画面イメージ図を示す。保存されるファイルは拡張子「.p7m」のような汎用的な電子署名ファイルであり、いつでもその内容や署名を確認することができる。図13は、前記のように、電子証明書に不備があった場合などに、署名の有効性が確認されず、検証がNOであった旨のメッセージなどを示すメッセージがクイアント端末に送信して表示される一例を示している。クライアント用電子署名プログラムがその目セージを受領するが、電子証明書が元々不備であった場合のほか、改ざんなどの不正が行われた可能性もある。したがってサーバーでの検証の結果、不備の内容をメッセージで通知することが好ましく、図13においても一例として、「正しい証明書を使って署名されています。文章は改ざんされていません」、「文章は改ざんされていませんが、証明書の有効期限が切れているか、証明書のパスが切れている可能性があります」、「文章が改ざんされている可能性があります」、「署名がついていないのでは?と思われる場合や、署名ファイルとは違うファイルを開いた場合に表示されます」、などの不備の種類を表示させている。』


<引用文献2>
国際公開第03/088052号(2003年4月11日国際公開。特表2005-522775号公報(平成17年7月28日公表)に対応。)

<引用文献記載事項2-1>
「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:」(8頁16行?21行)
(公表公報の対応部分:「【0023】
段階406において、このメッセージにデジタル署名を施す。即ち、このメッセージに署名するべく、メッセージコンテンツからハッシュ値を生成し、この結果生成されたハッシュ値をクライアントシステム104のプライベート暗号化キーによって暗号化するのである。尚、すべての暗号化は、http://www.rsa.comに記述さている標準的なRSAパブリックキー暗号化方式に基づくものであるが、この代わりに、その他の暗号化方式を使用可能であることは明らかである。そして、クライアントシステム104の署名であるこの暗号化されたハッシュを、次のようにメッセージに付加する。」

<引用文献記載事項2-2>
「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 .」(8頁24行?28行)
(公表公報の対応部分:「【0025】
段階408において、このメッセージの全体を情報サーバ102のパブリック暗号化キーを使用して暗号化する。この結果、このメッセージを暗号解読できるのは、情報サーバ102のみとなる。そして、段階410において、この暗号化したメッセージを、TCP/IPなどの適切な通信プロトコルを使用して情報サーバ102に送信する。そして、本プロセスは、段階412において、情報サーバ102から回答を受信するべく待機することになる。」)

<引用文献記載事項2-3>
「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 .」(10頁26行?27行)
(公表公報の対応部分:「【0038】
段階520において、このメッセージをクライアントシステムのパブリックキーによって暗号化し、この暗号化した回答を段階522においてクライアントシステム104に送信する。」)


<引用文献3>
特開2005-57417号公報(平成17年3月3日出願公開)

<引用文献記載事項3-1>
「【請求項2】
請求項1記載の電子文書交換システムにおいて、
前記文書交換部が、
前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を、その送信先の公開鍵を用いて暗号化した後、送信する構成を有することを特徴とする電子文書交換システム。」


(2)参考文献
本願の出願前かつ本願の優先権主張日よりも前に頒布されされた刊行物である下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。(下線は当審付与。)

<参考文献1>
特表平11-509354号公報(平成11年8月17日公表)

<参考文献記載事項1-1>
『匿名の通信および公開キー・インフラストラクチャ、およびおそらくは公開キー証明(PKC)の方法を提供するネットワークにおいて、本発明は所望の安全な匿名通信の方法を提供する。簡単に言えば、送信側はまず「主題質問」および自身のディジタル署名を含む暗号化した要求を作成する。この要求は匿名で1つまたは複数の受信側に送信される。各受信側は「主題応答」および自身のディジタル署名を含む暗号化した応答を作成する。「主題質問」および「主題応答」は特定のビジネスで使われる対応する情報セットの対、例えば特定の商品の説明および販売業者からのこれに対応するオファー、特定のサービスの要求およびサービス・プロバイダのこれに対応するオファー、またはオークションでの入札者の入札および競売人の応答を示す。』(第9頁第6行?第15行)


<参考文献2>
特開2004-318900号公報(平成16年11月11日出願公開)

<参考文献記載事項2-1>
「【請求項71】
前記支払手段、請求手段、決済処理手段並びに前記サービス提供手段のユーザ情報処理手段、マーチャント情報処理手段及び決済処理機関情報処理手段が、送信する前記メッセージデータにデジタル署名と封書化処理とを併せて施し、前記メッセージデータを受信した前記支払手段、請求手段、決済処理手段並びに前記サービス提供手段のユーザ情報処理手段、マーチャント情報処理手段及び決済処理機関情報処理手段の各々が、封書化されたメッセージデータの暗号を復号化して、デジタル署名の検証処理を行なうことを特徴とする請求項70に記載のパーソナル電子決済システム。」

<参考文献記載事項2-2>
「【0112】
この時、パーソナル・クレジット端末100とクレジット決済装置101とは、伝送路105を用いて、赤外線通信を行ない、パーソナル・クレジット端末100とサービス提供システム102とは、伝送路106及び基地局104、さらに、デジタル通信回線107、デジタル公衆網108及びデジタル通信回線109を介して、デジタル無線電話によるデジタル電話通信を行ない、クレジット決済装置101とサービス提供システム102とは、デジタル電話通信回線110、デジタル公衆網108及びデジタル通信回線109を介してデジタル電話通信を行なう。そして、サービス提供システム102と決済システム103とは、デジタル通信回線111を介して、デジタルデータ通信を行なう。
パーソナル・クレジット端末100とサービス提供システム102との通信、クレジット決済装置101とサービス提供システム102との通信、及び、サービス提供システム102と決済システム103との通信では、交換される決済情報を、全て、暗号化して通信する。暗号化には、秘密鍵方式の暗号処理と公開鍵方式の暗号処理とを組み合わせて、情報を電子封書化して通信する。」

<参考文献記載事項2-3>
『【0136】
次に、パーソナル・クレジット端末が、クレジット決済端末とサービス提供システムとに送信するメッセージを生成する際に行なうデジタル署名処理及び封書化処理について説明する。
デジタル署名処理と封書化処理とは、クレジット決済端末でも同様の処理を行なうので、以下では、登場人物は、ユーザ、マーチャント、サービス提供者という呼び方はせず、Aさん、Bさんというように、登場人物を一般化して説明する。
デジタル署名は、公開鍵方式の暗号化処理の「プライベート鍵で暗号化したメッセージは、そのプライベート鍵に対応する公開鍵でしか復号化できない」という性質を利用して、メッセージに電子的な署名を施す処理である。
図20(a)、(b)は、それぞれ、メッセージ(Message)に、Aさんのデジタル署名をする場合のデジタル署名処理の手順を示すフロー図と、フローの概念解説図である。
まず、ステップ2000で、CPUは、メッセージ2003に対して、ハッシュ関数演算を行ない、メッセージ・ダイジェスト2004を生成する。
次に、ステップ2001で、CPUは、暗号処理プロセッサを用いて、メッセージ・ダイジェスト2004を、Aさんのプライベート鍵で暗号化して、デジタルサイン2005を生成する。
次に、ステップ2002で、CPUは、デジタルサイン2005を、もとのメッセージ2003に付加する。以上の手順によって、CPUは、Aさんのデジタル署名をしたメッセージ2006を生成する。
図20(b)の2006は、Aさんのデジタル署名をしたメッセージを図示したものであり、以下では、デジタル署名されたメッセージは、図面の中では、2006のように、図示することとする。』


<参考文献3> 国際公開第04/28077号(2004年4月1日国際公開。特表2005-539441号公報(平成17年12月22日公表)に対応。)

<参考文献記載事項3-1>
「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.」(61頁5行?28行)
(公表公報の対応部分:「【請求項90】
公開鍵システムにおけるデジタルデータの配信を前記デジタルデータ上のデジタル署名を使用して制御するための方法であって、
前記デジタルデータのハッシュ値を送信者により算出するステップと、
第1のデジタル署名を前記送信者により、前記ハッシュ値を第1のデジタル署名スキームに従って第1の公開鍵対の第1の秘密鍵を使用して暗号化することによって算出するステップと、
第2のデジタル署名を、前記第1のデジタル署名を第2のデジタル署名スキームに従って第2の公開鍵対の第2の秘密鍵を使用して暗号化することによって算出するステップと、
前記第2のデジタル署名及び前記デジタルデータを前記デジタルデータの受信者へ供給するステップと、
前記第2のデジタル署名の第1の検証値を前記第2のデジタル署名スキームに従って前記第2の公開鍵対の公開鍵を使用して算出するステップと、
前記第1の検証値の第2の検証値を前記第1のデジタル署名スキームに従って前記第1の公開鍵対の公開鍵を使用して算出するステップと、
前記デジタルデータのハッシュ値を取得するステップと、
前記取得されたハッシュ値と前記第2の検証値とを比較するステップと、
前記比較するステップの結果、値が異なれば、前記受信者へのデータ配信プロセスは意図されたプロセスフローから外れていることを確立するステップとを含む、方法。」)

<参考文献記載事項3-2>
「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).」(33頁15行?33行)
(公表公報の対応部分:「【0098】
本発明のさらなる実施形態によれば、層状の暗号化態様に関連して先に述べた考慮事項が公開鍵署名スキームにも当てはまる。先に述べた暗号化スキームに比較すると、公開鍵を基礎とするデジタル署名スキームは、対応する全ての暗号化及び復号化プロセスの役割を交換するだけである。これにより、先の暗号化プロセスは受信者によって実行される検証ステップに対応し、デジタルデータの署名者又は送信者によって実行される個々の復号化ステップは復号化ステップのオペレーションを含む。相応してデータの送信者又は署名者はその固有の秘密鍵を適用し、受信者又は署名の検証者は署名者の公開鍵を入手しなければならない。使用される大部分の署名スキームはさらに、算出され且つ予測された結果の署名検証プロセスの一部として比較ステップを必要とする。基礎的な公開鍵システムが同じであることから、層状の暗号化及び所定のネットワークノードを介する指定され且つ制御される配信をデジタル署名に適用することができる。デジタルデータへの署名に際しては、典型的にはハッシュ関数がそのデータに適用され且つ署名者の秘密鍵を包含する署名オペレーションがその算出されたハッシュ値に対して実行される。層状の署名スキームに関しては、これは異なる秘密鍵を有する、異なる署名層における連続的な署名へと移行し、受信者による対応する検証プロセスにおいて適宜これを検証する。」)

<参考文献記載事項3-3>
「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.」(33頁34行?34頁22行)
(公表公報の対応部分:「【0099】
メッセージはデータ及び先行層によって生成された署名の双方によって形成されることから、通常、署名は、ある特定の層において両者をハッシュすることによって生成される。層状の暗号化と同様に、各層でこのメッセージ全体をハッシュする必要はない。当該層の関連の秘密鍵によって個々に署名し直されなければならないものは先行して算出されたハッシュ値だけであるが、これは、使用されるデジタル署名スキームに従って何らかの一般的なデータフォーマット又はハッシュを必要とする可能性がある。その結果、各層で(問題の同一のデジタルデータの)同一のハッシュ値に対して実行されることを除けば互いに独立しているデジタル署名が生成される。従って代替として、ハッシュ値ではなく、各層において個々の先行層の実署名(署名されたハッシュ値)が署名されることが可能である。(第1の層を除く)全ての層の署名はハッシュされたデータだけでなく先行層の署名に対しても発行されることから、この代替案は、どの署名が最初に発行されていて、よって最初に検証されなければならないか、即ちどの署名がどの署名層に対応するかをより簡単に確立し且つ制御することができるという優位点を有する。これにより、先行層の署名に署名する代わりに、先行署名をハッシュしてこの新しいハッシュ値に署名することもまた、全ての例において必要とされるわけではないが可能であり、これで、デジタルデータだけでなく先行署名に対しても責任を負うことになり、よって先に述べたものと同じ結果がもたらされる。これらの層状の署名は、配信されるデジタルデータの層状の暗号化プロセスに関する実施形態と組み合わされることが可能である。」)


<参考文献4>
特開平10-187836号公報(平成10年7月21日出願公開)

<参考文献記載事項4-1>
「【0047】電子署名SA(M)の作成方法としては、任意のものを用いることができる。例えば、取り引き文書Mを所定の圧縮アルゴリズムで圧縮したり、ハッシュしたりしてデータ量を削減し、得られたデータを秘密鍵SAで暗号化する方法がある。もちろん、取り引き文書Mをそのまま秘密鍵SAで暗号化してもかまわない。」


4.引用発明の認定

(1)引用文献1には上記引用文献記載事項1-1や1-2のとおりの「電子署名・電子文書保管システム」が記載されているところ、これによってなされる「電子署名・電子文書保管方法」も開示されていると言える。
したがって、引用文献1には「電子署名・電子文書保管システムによってなされる電子署名・電子文書保管方法」が記載されていると言える。

(2)該「電子署名・電子文書保管システム」は、上記引用文献記載事項1-1記載の通り、「サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、LANなどに代表される通信手段と、サーバー用電子署名プログラムと、WEBサーバーとを少なくとも備えるサーバーシステムと、から構成され」るものである。

(3)そして、前記「サーバーシステム」は、上記引用文献記載事項1-2の如く「クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、前記の電子文書に検証したことを示すサーバーの電子署名をした上で、クライアント端末の、ブラウザと連携して備えられるクライアント用電子署名プログラムに対し、サーバーの電子署名のされた前記の電子文書を送信する」ものであるところ、上記引用文献記載事項1-3には、「サーバーの電子署名」がされる「前記の電子文書」としては「クライアント端末から受信したデータファイルと同じファイル」である「電子署名付きデータファイル」とすることも記載されている。
したがって、引用文献1には「前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信」することも記載されていると言える。

(4)さらに、上記引用文献記載事項1-4の「サーバーの電子署名付きデータファイルをクライアント端末において受信する(S121)。」「クライアント端末においては、ブラウザを用いて、サーバーからの署名つきのデータファイルの確認や、データファイルの保存をすることができる(S122)。」との記載から、引用文献1には「前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信し、前記サーバーシステムからの署名つきのデータファイルの確認をする」ことも記載されていると言える。


(5)よって、引用文献には下記の引用発明が記載されていると認められる。

<引用発明>
「電子署名・電子文書保管システムによってなされる電子署名・電子文書保管方法であって
該電子署名・電子文書保管システムは、サーバーシステムにアクセスするために通信手段に接続され、ブラウザと、クライアント用電子署名プログラムとを少なくとも備えるクライアント端末と、インターネット、LANなどに代表される通信手段と、サーバー用電子署名プログラムと、WEBサーバーとを少なくとも備えるサーバーシステムと、から構成され、
前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信して、検証し記憶すると共に、該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信し、
前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信し、前記サーバーシステムからの署名つきのデータファイルの確認をする方法。」


5.対比
以下に、本願発明と引用発明とを比較する。

(1)引用発明における「電子署名・電子文書保管システム」が、「サーバーシステムにアクセスするために通信手段に接続され」る「クライアント端末」と、「インターネット、LANなどに代表される通信手段と」、「WEBサーバーとを少なくとも備えるサーバーシステムと、から構成され」ており、しかも、引用発明においては「前記サーバーシステムが、前記クライアント端末から送信された電子署名のされた電子文書を受信し」、「前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信し」、「前記クライアント端末において、前記サーバーの電子署名のされた前記電子文書をクライアント端末において受信」するのであるから、引用発明と本願発明とは「ウェブ・サービスにおける」「データ通信のための方法」と言えるものである点で一致すると言える。

(2)引用発明における「サーバーシステム」が提供するサービスは本願発明における「ウェブ・サービス」に対応付けられるものであるところ、前者は「WEBサーバー」を備えている事から見て、後者と同様に「ウェブ・サービス」とも言えるものである。

(3)引用発明における「クライアント端末」は、本願発明における「リクエスタ」に対応付けられるものであるところ、前者が「サーバーシステム」にサービスの要求をするものであることは明らかであるから、後者と同様に「リクエスタ」とも言えるものである。

(4)引用発明においては「前記サーバーシステム」が「前記クライアント端末から送信された電子署名のされた電子文書を受信」するものであるところ、通常「電子署名」とは、文字コード等の値をもつディジタル情報として表現され、該署名の対象となる情報の要素の一つとしてこれに付加されるものであるから、「電子署名のされた電子文書」とは「値を有する」「署名を帯びているエレメントを含む」ものとも言える。また、引用発明において「クライアント端末から」「電子文書」を「送信」することは、該文書の「電子署名・電子文書保管」を要求することに他ならないものであるから、これも「リクエスト」と言えるものである。
したがって、引用発明と本願発明とは「値を有する第1署名を帯びているエレメントを含む、」「リクエストをリクエスタからウェブ・サービスで受け取るステップ」を有していると言えるものである点で一致すると言える。

(5)引用発明においては「サーバーシステム」が「該電子署名のされた電子文書に検証したことを示すサーバーの電子署名を」するのであるから、引用発明における「サーバーの電子署名」の対象には「前記クライアント端末から送信された」「電子文書」に付された「電子署名」も含まれていることは明らかである。
したがって、引用発明と本願発明とは「前記第1署名の値を署名し、これにより第2署名を作成するステップ」を有していると言えるものである点でも一致すると言える。

(6)引用発明においては「サーバーシステム」が「該電子署名のされた電子文書に検証したことを示すサーバーの電子署名をした上で、前記クライアント端末の、前記ブラウザと連携して備えられる前記クライアント用電子署名プログラムに対し、該サーバーの電子署名のされた前記電子文書を送信」するものであるところ、「該サーバーの電子署名のされた前記電子文書」は、上記「リクエスト」に対する「レスポンス」に他ならないものである。
したがって、引用発明と本願発明とは「前記ウェブ・サービスから前記第2署名を含む、」「レスポンスを前記リクエスタに送るステップ」を有していると言えるものである点でも一致すると言える。

(7)そして、引用発明においては「前記クライアント端末において、前記サーバーシステムからの署名つきのデータファイルの確認をする」のであるから、引用発明と本願発明とは「前記レスポンスが、前記第1署名の値を署名して作成された前記第2署名を含むことを前記リクエスタにより確認するステップを」有していると言えるものである点でも一致すると言える。


(8)よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。

<一致点>
「ウェブ・サービスにおけるデータ通信のための方法であって、前記方法は、
値を有する第1署名を帯びているエレメントを含む、リクエストをリクエスタからウェブ・サービスで受け取るステップと、
前記第1署名の値を署名し、これにより第2署名を作成するステップと、
前記ウェブ・サービスから前記第2署名を含む、レスポンスを前記リクエスタに送るステップと、
前記レスポンスが、前記第1署名の値を署名して作成された前記第2署名を含むことを前記リクエスタにより確認するステップと、
を含むことを特徴とする方法。」
(下線は上記2.の<本願発明>と相違する箇所。)

<相違点>
本願発明におけるデータ通信は、リクエストもレスポンスも「暗号化」された「秘密」データ通信である点。(これに対し、引用文献1にはリクエストやレスポンスが「暗号化」された「秘密」データ通信であることの記載は無い。)


6.判断
上記相違点について検討するに、送受信する情報を暗号化することで秘密データ通信を行うことは、当業者が従来から必要に応じて適宜に採用している周知慣用技術に過ぎないものである(必要があれば上記引用文献2(特に引用文献記載事項2-2、2-3)、上記引用文献3(特に引用文献記載事項3-3)、参考文献1(特に参考文献記載事項1-1)、参考文献2(特に参考文献記載事項2-1、2-2)等参照。)から、引用発明においてリクエストやレスポンスを暗号化して秘密データ通信を行うこと、即ち、上記相違点に係る構成を採用することも、当業者が必要に応じて適宜に採用し得たことである。

してみると、本願発明の構成は引用文献1に記載された発明に基づいて、当業者が容易に想到し得たものである。
また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本願発明は、引用文献1に記載された発明に基づいて、当業者が容易に発明をすることができたものである。


7.回答書の補正案について、
なお、請求人は、上記平成23年6月29日付けの回答書において、請求項1を、
「ウェブ・サービスにおける秘密データ通信のための方法であって、前記方法は、
値を有する第1署名を帯びているエレメントを含む、暗号化されているリクエストをリクエスタからウェブ・サービスで受け取るステップと、
前記ウェブ・サービスで、前記第1署名の値をハッシュし秘密キーで当該ハッシュを暗号化する署名をし、これにより第2署名を作成するステップと、
前記ウェブ・サービスから前記第2署名を含む、暗号化したレスポンスを前記リクエスタに送るステップと、
前記第2署名を前記秘密キーに対応するパブリック・キーで解読して前記第1署名の値のハッシュが得られることにより、前記レスポンスが、前記第1署名の値を署名して作成された前記第2署名を含むことを前記リクエスタにより確認するステップと、を含むこと
を特徴とする方法。」
とする補正案を提示しているが、署名に際しハッシュと暗号化を行うことも、適宜に採用される周知慣用技術に他ならないものである(必要があれば引用文献2(特に上記引用文献記載事項2-1)、参考文献2(特に上記参考文献記載事項2-3)、参考文献3(特に上記参考文献記載事項3-1、3-2)、参考文献4(特に上記参考文献記載事項4-1)等参照。)から、仮に当該補正案通りの補正がなされたとしても、本審決の結論には影響しない。
さらに、当該補正案の「前記第1署名の値をハッシュし秘密キーで当該ハッシュを暗号化する署名」との記載は、「前記第1署名の値」のみを「ハッシュ」及び「暗号化」の対象とし、リクエスト全体を「ハッシュ」及び「暗号化」の対象とはしない構成を表現しようとしているとの推測も可能であるが、このような構成は、本願の発明の詳細な説明や当初明細書等(平成19年12月17日付けで提出された特許法第184条の4第1項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文等)に明記されるものではないので、係る補正が許されるものではない。しかも、メッセージ全体をハッシュせずに第1の署名をハッシュして暗号化することで第2の署名を算出することは、引用文献3(特に上記参考文献記載事項3-1、3-3)等に記載される如く、本願優先日前には公知となっていた技術思想であるから、仮に上記推測される構成のものへの補正が許されると仮定した場合でも、これに進歩性を認めることはできず、やはり、本審決の結論には影響しない。


8.むすび
以上のとおり、本願請求項1に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、他の請求項についての検討をするまでもなく、本願は、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2011-08-18 
結審通知日 2011-08-23 
審決日 2011-09-07 
出願番号 特願2008-518776(P2008-518776)
審決分類 P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 松平 英  
特許庁審判長 山崎 達也
特許庁審判官 冨吉 伸弥
吉田 美彦
発明の名称 ウェブ・サービスにおける秘密データ通信  
復代理人 正林 真之  
代理人 市位 嘉宏  
代理人 太佐 種一  
代理人 上野 剛史  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ