ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 H04L 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 H04L |
---|---|
管理番号 | 1337361 |
審判番号 | 不服2016-15175 |
総通号数 | 220 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2018-04-27 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2016-10-07 |
確定日 | 2018-02-07 |
事件の表示 | 特願2015-207711「証明書不要公開鍵基盤に基づく安全なクライアント・サーバ通信プロトコルを設計するシステムと方法」拒絶査定不服審判事件〔平成28年 3月17日出願公開,特開2016- 36166〕について,次のとおり審決する。 |
結論 | 本件審判の請求は,成り立たない。 |
理由 |
第1.手続の経緯 本願は,平成22年12月10日(パリ条約による優先権主張2009年12月10日 インド)に出願した外国語書面出願である特願2010-275385号の一部を,特許法第44条第1項の規定により,平成27年10月22日に新たな特許出願としたものであって, 平成27年11月5日付けで特許法第36条の2第2項の規定による外国語書面,及び,外国語要約書面の日本語による翻訳文が提出され,同日付けで審査請求がなされる共に手続補正がなされ,平成27年11月27日付けで審査官により拒絶理由が通知され,これに対して平成28年3月14日付けで意見書が提出されると共に手続補正がなされたが,平成28年6月1日付けで審査官により拒絶査定がなされ,これに対して平成28年10月7日付けで審判請求がなされたものである。 第2.本願発明について 本願の請求項1?請求項14に係る発明は,平成28年3月14日付けの手続補正により補正された特許請求の範囲の請求項1?請求項14に記載された事項によって特定されるものである。 第3.原審の拒絶理由 原審における平成27年11月27日付けの拒絶理由(以下,これを「原審拒絶理由」という)は,概略,以下のとおりである。 「 理由 1.(明確性)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。 2.(サポート要件)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号に規定する要件を満たしていない。 3.(実施可能要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。 4.(進歩性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。 記 (引用文献等については引用文献等一覧参照) ●理由1(明確性)について <省略> ●理由2(サポート要件)について ・請求項 1-7 請求項1に記載された「前記処理値を受信かつ検証することにより偽造を検出し,さらには検証値を生成する第1検証器」の「検証値」は,発明の詳細な説明に記載された何れの事項に対応するのか不明である。 請求項2-7についても同様。 ・請求項 1-7 請求項1には「前記所定プリミティブを有して前記秘密鍵生成器からの前記秘密鍵を受信・・・するセッション鍵生成器」と記載されている。 一方,発明の詳細な説明には,段落0061,0068,0076,0082,0091,0098に,クライアント及びサーバが,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行って秘密鍵を共有する点について記載されている。 しかしながら,発明の詳細な説明には,クライアント及びサーバが,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行う際に,サーバがクライアントから秘密鍵を受信する点について記載も示唆も為されていない。 ・請求項 2 請求項2に記載された「前記処理器は,前記乱数を受信し,かつ,前記乱数を,楕円曲線暗号化を使用して前記公開鍵により暗号化する暗号化器を含む」の「前記公開鍵」は,第2検証器が生成した公開鍵を意味するといえる。 しかしながら,発明の詳細な説明には,処理器が,受信した乱数を,楕円曲線暗号化を使用して第2検証器が生成した公開鍵により暗号化する点は記載されていない。 ・請求項 4 請求項4に記載された「前記第1検証器は,前記処理値を受信し,かつ,前記処理値を,楕円曲線暗号化を使用して前記個人鍵により復号化する復号化器を含む」の「前記個人鍵」は,第2検証器が生成した対応個人鍵を意味するといえる。 しかしながら,発明の詳細な説明には,第1検証器が,受信した処理値を,楕円曲線暗号化を使用して第2検証器が生成した対応個人鍵により復号化する点は記載されていない。 ●理由3(実施可能要件)について ・請求項 1-7 請求項1には「前記所定プリミティブを有して前記秘密鍵生成器からの前記秘密鍵を受信・・・するセッション鍵生成器」と記載されている。 発明の詳細な説明には,段落0061,0068,0076,0082,0091,0098に,クライアント及びサーバが,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行って秘密鍵を共有する点について記載されている。 鍵共有技術の分野において,楕円曲線ディフィー・ヘルマンアルゴリズムが,共有しようとする鍵自体の送受信を必要としないアルゴリズムであることは,技術常識である。 しかしながら,発明の詳細な説明には,楕円曲線ディフィー・ヘルマンアルゴリズムを使用してサーバがクライアントから秘密鍵を受信するということが技術的に如何なることであるのかという点について記載されておらず,この点は,当業者にとって発明の詳細な説明の記載事項及び技術常識から明らかな事項でもない。 してみると,発明の詳細な説明は,請求項1の「前記秘密鍵に対応するセッション鍵を,前記所定プリミティブに基づいて生成するセッション鍵生成器」について,当業者が実施可能な程度に記載したものでない。請求項2-7についても同様。 ・請求項 1-14 請求項1には「前記秘密鍵に対応するセッション鍵を,前記所定プリミティブに基づいて生成するセッション鍵生成器」と記載されている。 発明の詳細な説明には,段落0076,0091に,サーバが,クライアントと共有する秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用してセッション鍵を生成する点が記載されている。 鍵共有技術の分野において,楕円曲線ディフィー・ヘルマンアルゴリズムが,鍵を共有しようとする装置同士が予め共有する秘密情報を必要としないアルゴリズムであることは,技術常識である。 しかしながら,発明の詳細な説明には,サーバが,クライアントと共有する秘密鍵を使用する楕円曲線ディフィー・ヘルマンアルゴリズムというものが技術的に如何なるアルゴリズムを意味するのかという点について記載されておらず,この点は,当業者にとって発明の詳細な説明の記載事項及び技術常識から明らかな事項でもない。 してみると,発明の詳細な説明は,請求項1の「前記秘密鍵に対応するセッション鍵を,前記所定プリミティブに基づいて生成するセッション鍵生成器」について,当業者が実施可能な程度に記載したものでない。請求項2-7についても同様。 請求項8に記載された「セッション鍵生成器を使用して前記秘密鍵及び前記所定プリミティブに基づきセッション鍵を生成する」についても同様。請求項9-14についても同様。 ●理由4(進歩性)について <省略>」 第4.原審拒絶理由に対する当審の判断 1.理由2について (1)本願の請求項1の, 「処理値を受信かつ検証することにより偽造を検出し,さらには検証値を生成する第1の検証器」, という記載における「検証値」に関して,本願明細書の発明の詳細な説明には, 「 【0075】 サーバは,生成された値に前処理関数を施した後,当該前処理値及び当初値をクライアントに送信する。前処理値は当初値から算出され,前処理値及び当初値間の差異のみが,前処理値の場合にビットシーケンスが改変されることを示す。クライアント側において,前処理値が,シャフリング,T関数及びLFSRの関数を逆順に使用して,すなわちLFSRの後にT関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は,当該値を前処理する場合に逆にされる。3つの関数すべてが可逆なので,当該実行順序は,データ損失及び悪影響なしに逆にすることができる。クライアントは,上述の関数を逆順に実行した後(すなわち,LFSRの後にT関数及びビットシャフリングが追従した後),検証値を取得する。クライアントは,LFSR,T関数及びビットシャフリングのプロセスを実行した結果として取得された検証値を,サーバが送信した当初値と比較することにより,当該値が偽造されたものか否かを検出する。サーバが送信した値を検証した後クライアントは,サーバが送信した値が認証された場合に公開鍵及び個人鍵の対を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。クライアントはさらに,サーバが送信した値について,楕円曲線デジタル署名アルゴリズムを使用して署名も生成し,当該署名を自身の公開鍵とともに当該サーバに送信する。サーバは署名を受信すると,クライアントが送信した署名を,楕円曲線デジタル署名アルゴリズムを使用して検証し,その後,公開鍵及び個人鍵の対を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。その後,サーバは,生成された公開鍵をクライアントに送信する。」(下線は,当審にて,説明の都合上,付加したものである。以下,同じ。) という記載が存在し,上記引用の段落【0075】の記載中の, 「クライアント側において,前処理値が,シャフリング,T関数及びLFSRの関数を逆順に使用して,すなわちLFSRの後にT関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は,当該値を前処理する場合に逆にされる。3つの関数すべてが可逆なので,当該実行順序は,データ損失及び悪影響なしに逆にすることができる。クライアントは,上述の関数を逆順に実行した後(すなわち,LFSRの後にT関数及びビットシャフリングが追従した後),検証値を取得する。クライアントは,LFSR,T関数及びビットシャフリングのプロセスを実行した結果として取得された検証値を,サーバが送信した当初値と比較することにより,当該値が偽造されたものか否かを検出する」, という内容から,段落【0075】に記載の「検証値」とは,「サーバ」で,「当初値」から生成された「前処理値」を,「クライアント側」で,「前処理をする場合」の「逆」の「実行順序」で「実行した」結果,得られた値であって,この値が,「サーバ」から,「クライアント側」に送信された「当初値と比較することにより」,「前処理値」が,「偽造されたものか否かを検出する」ための「値」であって,「前処理値」が,「偽造」されていなければ,当該「検証値」は,「当初値」と一致するものである。 一方,本願の請求項1においては,上記引用の本願の請求項1の記載にあるとおり, 「処理値」は,「受信され検証することにより偽造を検出」されるものであり,「検証値」は,「検証器」によって,“さらには,生成される”ものである。 したがって,本願の請求項1に記載された内容からは,「検証値」は,「処理値」の「偽造を検出」ことに関与するものとは読み取れず,本願の請求項1に記載の「検証値」と,上記引用の,本願明細書の段落【0075】に記載の「検証値」とが,同じものであるとは認められない。 本願明細書の発明の詳細な説明には,上記引用の,段落【0075】に記載された「検証値」以外に,検証値が存在していないので,本願の請求項1に記載の「検証値」は,本願明細書の発明の詳細な説明に記載されたものではない。 (2)本願の請求項1に記載された, 「所定のアルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有し」, に関して,本願の請求項1には,上記引用記載の後段に更に, 「サーバは,前記乱数生成器,前記処理器,前記第2検証器及び前記セッション鍵生成器を含み, クライアントは前記第1検証器,前記計算器及び前記秘密鍵生成器を含み」, と記載され,上記引用の記載から,本願の請求項1においては,「秘密鍵」を生成する「秘密鍵生成器」は,「クライアント」にしか存在していないので,「サーバ」が,「クライアント」と「秘密鍵」を「共有」するためには,「クライアント」の「秘密鍵生成器」で生成された「秘密鍵」を,「クライアント」から,「サーバ」に送信する必要があることは明らかである。 一方,「秘密鍵生成器」,及び,「秘密鍵」を,「クライアント」と,「サーバ」とで「共有」する点に関して,本願明細書の発明の詳細な説明には,「秘密鍵生成器」という記載は存在しない。 更に,“「秘密鍵」を,「クライアント」と,「サーバ」とで「共有」する”点については,本願明細書の発明の詳細な説明に, 「【0059】 図1に示されるように,クライアントは,「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは,クライアントメッセージに応答して,乱数生成器の使用により「n」ビット長の乱数(値)を生成する。サーバはさらに,生成された値を,クライアントの公開鍵を使用して暗号化する。乱数値の暗号化のプロセス中,デジタル証明書は生成されない。サーバは,個々のクライアントに割り当てられた個人鍵及び公開鍵の組を追跡し続ける。サーバ側において当該値を暗号化するべく,楕円曲線暗号化法が利用される。クライアントの公開鍵を使用して暗号化された値は,クライアントに送信される。サーバは,クライアントに対し,暗号化された形式の数を包含する値を復号化させて自身のIDを証明させるようにチャレンジを行う。クライアントは,暗号化された値を受信し,かつ,当該暗号化された値を自身の個人鍵を使用して復号化する。クライアントは,暗号化された値を,自身の個人鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用して復号化し,かつ,当該値が信頼されるソースから送信されたか否かを検証する。クライアントは,暗号化された値を成功裏に復号化して当初値を回復させることにより,サーバが信頼できることを証明する。クライアントは,サーバが送信した値の検証ステップ(すなわち,サーバが送信した暗号化された値の復号化)の完了時に,楕円曲線暗号化法を使用して公開鍵及び個人鍵の対を生成する。 【0060】 クライアントは,復号化された値について,楕円曲線デジタル署名アルゴリズムを使用して署名を生成し,当該署名をサーバに送信する。サーバは,自身の一部において,クライアントが送信した署名を受信し,かつ,当該署名を,楕円曲線デジタル署名アルゴリズムを使用して検証する。サーバは,クライアントが送信した署名を検証した後すぐに,公開鍵及び個人鍵の対を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し,かつ,生成された公開鍵を当該クライアントに送信する。 【0061】 クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する。サーバは,その見返りとして,楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「m」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図1の参照番号100は,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長のセッション鍵を生成するステップを示す。サーバ及びクライアント間におけるその後の通信及び取引すべてに対し,そのセッション鍵が使用される。セッション鍵はサーバ及びクライアントのみが知っているので,クライアント及びサーバ間の通信は完全に安全である。」(以下,これを「明細書記載1」という), 「【0064】 第1ステップ:クライアントは,「クライアントです。こんにちは!」とのメッセージを送信することによりサーバへの通信を開始する。 【0065】 第2ステップ:サーバは,疑似乱数生成器(PRNG)を使用してランダムチャレンジ又はnビットの乱数値を生成する。さらに,サーバは,楕円曲線暗号化法(ECE)を使用してクライアントの公開鍵により乱数値を暗号化する。クライアントは,暗号化された乱数値を,ECEを使用して自身の個人鍵により復号化する。 【0066】 第3ステップ:クライアントは,楕円曲線暗号化法を使用することにより楕円曲線上に公開鍵及び個人鍵を生成する。公開鍵及び個人鍵の長さは,NIST(アメリカ国立標準技術研究所)により推奨される256ビット,384ビット又は512ビットのいずれかとなり得る。クライアントは,サーバから送られた値に基づく署名を,楕円曲線デジタル署名アルゴリズムを使用して生成し,当該署名をサーバに送信する。 【0067】 第4ステップ:サーバは,当該署名を,楕円曲線デジタル署名アルゴリズムを使用して検証した後,楕円曲線上に鍵の対を生成する。サーバは,自身の公開鍵をクライアントに送信する。 【0068】 第5ステップ:クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマン)アルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う。 【0069】 第6ステップ:クライアント及びサーバは,暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたmビットのセッション鍵についてネゴシエーションを行う。クライアント及びサーバは暗号スイートを有する。 【0070】 第7ステップ:安全な通信がクライアント及びサーバ間に確立される。」(以下,これを「明細書記載2」という), 「【0073】 図2に示されるように,クライアントは,「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは,クライアントメッセージに応答して,乱数生成器の使用により「n」ビット長の乱数(値)を生成する。サーバは,生成された乱数値を,メッセージ前処理関数(メッセージランダム化関数)を使用して処理する。メッセージ前処理関数は,3つの演算を順次に行うことを含む。3つの演算は,シャフリング,T関数及びLFSR(線形帰還シフトレジスタ)である。前処理のプロセスは,ビットのシャフリングから開始する。ビットのシャフリングは,拡散の増加に役立つ。拡散とは,入力の統計学上の冗長性が出力において散逸する特性を言及する。シャフリングのプロセスは可逆なので,当初ビットシーケンスは,シャフリング後のビットシーケンスから容易に回復させることができる。 【0074】 ビットシャフリングのプロセスの後に,T関数のプロセスが追従する。T関数は,同じビットとそれよりも下位のビットとの線形結合によってすべてのビットを更新する更新関数である。T関数のプロセスの後に,LFSR(線形帰還シフトレジスタ)の関数が追従する。LFSRは,32次かつ232-1周期の既約多項式を使用するプロセスである。LFSRの場合,所与の入力が,所与の多項式に対して4?15周期だけシフトされる。ビットシャフリング,T関数及びLFSR(集合的に前処理と称する)の出力は,高度にランダム化された値となる。 【0075】 サーバは,生成された値に前処理関数を施した後,当該前処理値及び当初値をクライアントに送信する。前処理値は当初値から算出され,前処理値及び当初値間の差異のみが,前処理値の場合にビットシーケンスが改変されることを示す。クライアント側において,前処理値が,シャフリング,T関数及びLFSRの関数を逆順に使用して,すなわちLFSRの後にT関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は,当該値を前処理する場合に逆にされる。3つの関数すべてが可逆なので,当該実行順序は,データ損失及び悪影響なしに逆にすることができる。クライアントは,上述の関数を逆順に実行した後(すなわち,LFSRの後にT関数及びビットシャフリングが追従した後),検証値を取得する。クライアントは,LFSR,T関数及びビットシャフリングのプロセスを実行した結果として取得された検証値を,サーバが送信した当初値と比較することにより,当該値が偽造されたものか否かを検出する。サーバが送信した値を検証した後クライアントは,サーバが送信した値が認証された場合に公開鍵及び個人鍵の対を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。クライアントはさらに,サーバが送信した値について,楕円曲線デジタル署名アルゴリズムを使用して署名も生成し,当該署名を自身の公開鍵とともに当該サーバに送信する。サーバは署名を受信すると,クライアントが送信した署名を,楕円曲線デジタル署名アルゴリズムを使用して検証し,その後,公開鍵及び個人鍵の対を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。その後,サーバは,生成された公開鍵をクライアントに送信する。 【0076】 クライアントは,サーバから公開鍵を受信すると,「m」ビット長の秘密鍵を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し,当該秘密鍵を当該サーバと共有する。サーバは,その見返りとして,秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「m」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図2の参照番号200は,秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「m」ビット長のセッション鍵を生成するステップを示す。サーバ及びクライアント間におけるその後の通信及び取引すべてに対し,そのセッション鍵が使用される。セッション鍵はサーバ及びクライアントのみが知っているので,クライアント及びサーバ間の通信は完全に安全である。」(以下,これを「明細書記載3」という), 「【0077】 第2ネットワークセキュリティプロトコルを使用するサーバ及びクライアント間の安全な通信に関連するステップは,以下のように与えられる。 【0078】 第1ステップ:クライアントは,「クライアントです。こんにちは!」とのメッセージを送信することによりサーバへの通信を開始する。 【0079】 第2ステップ:サーバは,ランダムチャレンジ又はnビットの乱数を,疑似乱数生成器(PRNG)を使用して生成し,当該乱数のメッセージ前処理を計算する。クライアントは乱数及びMP(乱数)を受信する。クライアントはMP(乱数)を検証する。 【0080】 第3ステップ:クライアントは,公開鍵及び個人鍵を楕円曲線上に生成する。個人鍵及び公開鍵の長さは,NIST(アメリカ国立標準技術研究所)により推奨される256ビット,384ビット又は512ビットのいずれかとなり得る。クライアントは,サーバが送信した値に,楕円曲線デジタル署名アルゴリズムを使用して署名し,当該署名を自身の公開鍵とともに当該サーバに送信する。 【0081】 第4ステップ:サーバは,署名を検証して鍵の対を楕円曲線上に生成する。サーバは,自身の公開鍵をクライアントに送信する。 【0082】 第5ステップ:クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマン)アルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う。 【0083】 第6ステップ:クライアント及びサーバは,暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたmビットのセッション鍵についてネゴシエーションを行う。クライアント及びサーバは暗号スイートを有する。 【0084】 第7ステップ:安全な通信がクライアント及びサーバ間に確立される。」(以下,これを「明細書記載4」という), 「【0088】 図3に示されるように,クライアントは,「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは,クライアントメッセージに応答して,乱数生成器の使用により「n」ビット長の乱数(値)を生成する。サーバはさらに,クライアントの公開鍵を使用して生成値を暗号化する。乱数値の暗号化のプロセス中,デジタル証明書は生成されない。サーバは,個々のクライアントに割り当てられた個人鍵及び公開鍵の組を追跡し続ける。サーバ側において当該値を暗号化するべく,楕円曲線暗号化法が利用される。クライアントの公開鍵を使用して暗号化された値は,クライアントに送信される。サーバは,クライアントに対し,暗号化された値を復号化させて自身のIDを証明させるようにチャレンジを行う。クライアントは,暗号化された値を受信し,当該暗号化された値を,自身の個人鍵及び楕円曲線暗号化法を使用して復号化する。これにより,サーバが信頼できる宛先であることが証明される。 【0089】 クライアントはさらに,送信された値についてのヤコビ恒等式を計算する。すなわち,クライアントは,当該復号化された値を3つの部分に分割する。クライアントはさらに,当該受信した値についてリー積を生成する。 【0090】 本発明によれば,当該値が3つの部分すなわちx,y及びzに分割される場合,当該値のヤコビ恒等式はxllyllzとして表される。乱数のヤコビ恒等式は,[[x,y],z]+[[y,z],x]+[[z,x],y]=0との関係を使用して検証される。 【0091】 本発明によれば,クライアントが当該値のリー積を生成してサーバに送信すると,当該サーバは,当該クライアントが送信したリー積を,[[x,y],z]+[[y,z],x]+[[z,x],x]=0との関係を使用して検証する。クライアントが送信したリー積の信ぴょう性が検証された後,サーバはさらに,公開鍵及び個人鍵の対を,楕円曲線暗号化法を使用して生成する。楕円曲線暗号化法の一部をなす楕円曲線ディフィー・ヘルマンアルゴリズムが,公開鍵及び個人鍵の対を生成する目的で使用される。クライアントはその後,自身の公開鍵をクライアントに送信する。クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する。サーバは,その見返りとして,秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図3の参照番号300は,「m」ビット長のセッション鍵を生成するステップを示す。サーバ及びクライアント間におけるその後の通信及び取引すべてに対し,そのセッション鍵が使用される。セッション鍵はサーバ及びクライアントのみが知っているので,クライアント及びサーバ間の通信は完全に安全である。」(以下,これを「明細書記載5」という), 「【0092】 第3ネットワークセキュリティプロトコルを使用するサーバ及びクライアント間の安全な通信に関連するステップは,以下のように与えられる。 【0093】 初期設定:すべてのクライアントが,鍵生成センタ(KGC)として動作するサーバが生成した公開鍵及び個人鍵の対を有する。 【0094】 第1ステップ:クライアントは,「クライアントです。こんにちは!」とのメッセージを送信することによりサーバへの通信を開始する。 【0095】 第2ステップ:サーバは,疑似乱数生成器(PRNG)を使用してランダムチャレンジ又はnビットの乱数を生成する。さらに,サーバは,楕円曲線暗号化法(ECC)を使用してクライアントの公開鍵により乱数を暗号化する。クライアントは,当該暗号化された乱数を,楕円曲線暗号化法を使用して自身の個人鍵により復号化する。 【0096】 第3ステップ:クライアントは,乱数についてのヤコビ恒等式x||y||zを計算してリー積[[x,y],z]をサーバに送信する。 【0097】 第4ステップ:サーバは,[[x,y],z]+[[y,z],x]+[[z,x],y]=0との関係を検証する。サーバは,ECC(楕円曲線暗号化法)を使用して自身の公開鍵をクライアントに送信する。 【0098】 第5ステップ:クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマンアルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う。 【0099】 第6ステップ:クライアント及びサーバは,暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたmビットのセッション鍵についてネゴシエーションを行う。クライアント及びサーバは暗号スイートを有する。 【0100】 第7ステップ:クライアント及びサーバ間に安全な通信が確立される。」(以下,これを「明細書記載6」という) と記載されていて,明細書記載1に, 「クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する」, 明細書記載2に, 「クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマン)アルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う」, 明細書記載3に, 「クライアントは,サーバから公開鍵を受信すると,「m」ビット長の秘密鍵を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し,当該秘密鍵を当該サーバと共有する」, 明細書記載4に, 「クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマン)アルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う」, 明細書記載5に, 「クライアントはその後,自身の公開鍵をクライアントに送信する。クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する」, 明細書記載6に, 「クライアント及びサーバは,ECDH(楕円曲線ディフィー・ヘルマンアルゴリズムを使用してmビット共有秘密鍵についてネゴシエーションを行う」, とある。 上記引用の明細書記載1?明細書記載6の内容からは,“クライアントが,サーバから受信した公開鍵を用いて,ECDHによって,秘密鍵を生成する”こと,及び,“当該秘密鍵を当該サーバと共有する”ことまでは読み取れるが,明細書記載2,明細書記載4,及び,明細書記載6に記載の「ネゴシエーション」とは,一般的な意味においては,単に,「交渉」という意味に過ぎず,当該技術分野においても,「サーバ」と,「クライアント」との「交渉」において,具体的に何を行うかを特定する内容を含むものではないので,単に「ネゴシエーション」といっただけでは,“秘密鍵をサーバと共有する”ための手法が示されるものではないから,明細書記載1?明細書記載6の内容を検討しても,「クライアント」のみが「秘密鍵生成器」を有すること,及び,当該「クライアント」が有する「秘密鍵生成器からの秘密鍵」を「サーバ」が受信することで,「クライアント」と「共有」することを読み取ることはできない。 仮に,本願の請求項に記載された字句どおり,単に, “秘密鍵生成器からの秘密鍵を(サーバが)クライアントと共有する” ものであるとしても,上記に検討したように,そのような構成は,本願明細書の発明の詳細な説明に記載されてはいない。 ここで,楕円曲線ディフィー・ヘルマン鍵共有(以下,これを「ECDH」という)について確認しておく。 「ECDH」については,例えば,本願の第1国出願前に既に公知である,特開2000-137436号公報(2000年5月16日公開,以下,これを「周知技術文献」という)に, A.「【0009】たとえば,公開鍵暗号系と知られる(有限体上の)ディフィ-ヘルマン(Diffie-Hellman)鍵交換と同様の鍵交換方式を実現することができる。楕円曲線上のベースポイントをGとし,Aの秘密鍵をs_(a)としPa=s_(a)Gを演算して公開鍵とする。また,Bの秘密鍵をs_(b)とし,Pb=s_(b)Gを演算してこれを公開鍵とする。AはBの公開鍵Pbと自分の秘密鍵s_(a)から,K_(AB)=s_(a)Pb=s_(a)s_(b)Gを演算することによって共通鍵を得ることができる。また,同様にして,BはAの公開鍵Paと自分の秘密鍵s_(b)から,K_(BA)=s_(b)Pa=s_(b)s_(a)Gを演算することによって共通鍵を得ることができる。この方式は,ECDH(Elliptic Curve Diffie-Hellman)方式と呼ばれ,秘密鍵s_(a),s_(b)をスカラー量として楕円曲線上の点G,Pa,Pbに乗算する必要があり,暗号化/復号化の際に大量の演算処理を必要とする。この他にECDSA方式やECES方式なども提案されているが,演算処理が大きくなる点については同様である。(以下省略)」, と記載されていて,上記Aの記載内容から明らかなように,「ECDH」は, “共通鍵を共有する,Aと,Bが,互いの公開鍵Paと,Pbを交換し,交換した公開鍵を用いて,Aは,自身の秘密鍵s_(a)と,Bの公開鍵Pbとから,計算でK_(AB)を求め,Bは,自身の秘密鍵と,Aの公開鍵とから,計算でK_(BA)を求め,K_(AB)=K_(BA)であることは明らかであるから,当該K_(AB)=K_(BA)が,Aと,Bの共通鍵となる”というものである。 即ち,ECDHにおいては,A側からも,B側からも,共通鍵が,相手側に送信されることはない。 以上の検討を踏まえ,上記検討の周知技術文献に記載された,周知技術である「ECDH」のアルゴリズムと,本願の請求項1に記載の事項,及び,本願明細書の発明の詳細な説明に記載された事項と対比すると, 周知技術文献における「公開鍵」,「秘密鍵」が,本願における「公開鍵」,「個人鍵」に対応するものであり,周知技術文献における「共通鍵」が,本願における「秘密鍵」,或いは,「共通秘密鍵」に対応するものであると解せる。 上記において,明細書記載1?明細書記載6として引用し,更に,上記において,各明細書記載から抽出した記載内容に従えば,本願明細書の発明の詳細な説明においては,「秘密鍵」,或いは,「共有秘密鍵」は,「クライアント」が,「サーバ」と,「共有する」もの,或いは,「クライアント及びサーバ」は,「共有秘密鍵についてネゴシエーションを行う」ものであることが読み取れ,上記において指摘したとおり,本願明細書の発明の詳細な説明には,「クライアント」が「秘密鍵」を生成することは記載されているが,当該「クライアント」が,「秘密鍵生成器」を有することは記載されていないので,本願明細書の発明の詳細な説明に記載された「ECDH(楕円曲線ディフィー・ヘルマンアルゴリズム」が,上記において,周知技術文献を用いて確認した,「ECDH」と同じものであれば,本願明細書の発明の詳細な説明における「クライアント」と,「サーバ」とが,「秘密鍵」を「共有する」こと,或いは,「クライアント及びサーバ」は,「共有秘密鍵についてネゴシエーションを行う」ということは,周知技術である「ECDH」において,「クライアント」と,「サーバ」が,互いの「公開鍵」を交換して,当該交換した,「公開鍵」と,自らの「秘密鍵」とから,「共有鍵」を計算で求めることを意味するものと,一応,推察される。 しかしながら,本願の請求項1においては,上記において指摘したとおり,「クライアント」のみが,「秘密鍵生成器」を有するものであって,本願の請求項1における「秘密鍵」は,当該「秘密鍵生成器」によって生成されるものである。 そうすると,本願の請求項1における「秘密鍵を前記クライアントと共有する」ことが,「クライアント」から,「サーバ」へ,「秘密鍵」を送信するものと解釈するか,字句どおり,単に,「共有」すると読むかにかかわらず,周知技術である“ECDHアルゴリズム”における“共有鍵の共有”を意味するものとは認められず,上記において検討したとおり,「ネゴシエーション」は,「共有」のための手法を何ら特定するものではないので, 本願明細書の発明の詳細な説明からは,本願の請求項1に係る発明における“「サーバ」が,当該「クライアント」のみが有する「秘密鍵生成器」を用いて生成された「秘密鍵生成器からの秘密鍵」を,当該「クライアントと共有」する”ことを,読み取ることができない。 (3)以上,上記(1),及び,(2)において検討したとおりであるから,本願の請求項1に係る発明は,本願明細書の発明の詳細な説明に記載されたものではない。 したがって,本願の請求項1を引用する,本願の請求項2?本願の請求項7に係る発明も,本願明細書の発明の詳細な説明に記載されたものではない。 2.理由3について 本願の請求項1に記載の, 「秘密鍵生成器からの前記秘密鍵を前記クライアントと共有し」, 及び, 「クライアントは前記第1検証器,前記計算器及び前記秘密鍵生成器を含み」, に関して,上記1.において,検討したとおり,「秘密鍵生成器」は,本願明細書の発明の詳細な説明に記載されておらず, したがって,“クライアントが,秘密鍵生成器を含む”ことも,本願明細書の発明の詳細な説明に記載されていない。 そして,上記1.において,明細書記載1?明細書記載6として引用した,本願明細書の発明の詳細な説明の記載内容には, “クライアントが,サーバから受信した公開鍵を用いて,ECDHによって,秘密鍵を生成し,当該秘密鍵を,サーバと共有する” ということまでは読み取れるが,明細書記載1?明細書記載6に記載された内容から読み取れることはその程度であり,当該各明細書記載から読み取れる事項を,上記1.において参照した,「ECDH」に関する周知の技術知識によって補足した場合は,「ECDH」における「共有」とは,「クライアント」と,「サーバ」が,互いの「公開鍵」を交換して,相手から受信した「公開鍵」と,自らの「秘密鍵」(本願における「個人鍵」)とから,「共有鍵」(本願における「秘密鍵」)を計算によって求めることで,「共有」することを意味するものであるから,本願の請求項1における, “クライアントのみが有する秘密鍵生成器が生成した秘密鍵(周知技術における「共有鍵」)を,サーバと共有する”ことを,どのようにして実現するかについては,本願明細書の発明の詳細な説明に記載された内容から読み取ることができない。 よって,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。 (なお,審判請求人は,平成28年10月7日付けの審判請求書(以下,「審判請求書」という)において, 「4.原査定の拒絶理由への反論 (1)特許法第36条第6項第1号に係る拒絶理由への反論 上記拒絶理由において「請求項1には「前記所定アルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・するセッション鍵生成器」と記載されている。 請求項1には「サーバは前記乱数生成器,前記処理器,前記第2検証器及び前記セッション鍵生成器を含み,クライアントは前記第1検証器,前記計算器及び前記秘密鍵生成器を含み,」とも記載されていることから,請求項1の他の記載,技術常識及び通常の日本語に鑑みれば,「前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・する」という記載は,クライアントに含まれる前記秘密鍵生成器から前記秘密鍵を受信することにより前記秘密鍵を前記クライアントと共有することを意味するといえる。」と認定されている。 ここで,本願の当初明細書の段落0061には「クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する」と記載され,段落0076には「クライアントは,サーバから公開鍵を受信すると,「m」ビット長の秘密鍵を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し,当該秘密鍵を当該サーバと共有する」と記載され,段落0091には「クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する」と記載されている。 すなわち,上記認定における「クライアントに含まれる前記秘密鍵生成器から前記秘密鍵を受信することにより前記秘密鍵を前記クライアントと共有することを意味するといえる」との事項が,本願の当初明細書に記載されている。 したがって,本願発明は,発明の詳細な説明に記載したものであって,特許法第36条第6項第1号に係る拒絶理由は解消している。 (2)特許法第36条第4項第1号に係る拒絶理由への反論 原査定に係る審査官殿は,「ECDHにより秘密鍵として生成したもの(スカラー)を,ECDHにおける公開鍵(ベクトル)として改めて使用することができないことは,当業者にとって明らかな事項であるから,秘密鍵生成器によりECDHの秘密鍵として生成したものを,セッション鍵生成器によりECDHの公開鍵として使用することは不可能である」として,請求項1の「前記所定アルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・するセッション鍵生成器」との記載について,いわゆる当業者が本願発明を実施できる程度に明確かつ十分に記載したものではないと判断しているが,出願人である本審判の請求人は,本願の当初明細書の段落0061,0068,0076,0082,0091及び0098に記載される楕円曲線ディフィー・ヘルマンシステム,楕円曲線デジタル署名システム,メッセージランダム化システム及びヤコビ恒等式検証システムからなる群から選択されるアルゴリズムの使用は,当業者の技術常識内において可能であると信じている。 なお,原査定に係る審査官殿は「ECDHにより秘密鍵として生成したもの(スカラー)を,ECDHにおける公開鍵(ベクトル)として改めて使用することができない」と認定しているが,本願の当初明細書に記載されている事項は,「クライアントは,サーバから公開鍵を受信すると,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「m」ビット長の秘密鍵を生成し,かつ,当該秘密鍵を当該サーバと共有する。サーバは,その見返りとして,楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「m」ビットのセッション鍵を生成する」(段落0061),「クライアントは,サーバから公開鍵を受信すると,「m」ビット長の秘密鍵を,楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し,当該秘密鍵を当該サーバと共有する。サーバは,その見返りとして,秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「m」ビットのセッション鍵を生成する」(段落0076)と記載されるように,「ECDHにより秘密鍵として生成したもの(スカラー)を,ECDHにおける公開鍵(ベクトル)として改めて使用すること」を記載しているわけではない。 したがって,発明の詳細な説明の記載は,経済産業省令で定めるところにより,いわゆる当業者が本願発明を実施できる程度に明確かつ十分に記載したものと考えられるので,特許法第36条第4項第1号に係る拒絶理由は解消している。」 と主張しているが,「共有」については,上記「1.理由2について」の(2)において検討したとおりであるから,請求人の上記主張は,採用できない。 また,原審における拒絶査定の理由から,特許法第29条2項(以下,「進歩性」という)が外れているが,本願の請求項1に記載の発明が,本願明細書の発明の詳細な説明に記載されたものであると仮定した場合は,請求人も,審判請求書おいて主張しているとおり,用いられている手法は何れも,当業者には周知の技術事項に過ぎないので,進歩性の拒絶理由が解消した訳ではないことを付言しておく。) 第5.むすび したがって,本願は,特許法第36条第4項第1号及び第6項第1号に規定する要件を満たしていない。 よって,結論のとおり審決する。 |
審理終結日 | 2017-08-30 |
結審通知日 | 2017-09-05 |
審決日 | 2017-09-22 |
出願番号 | 特願2015-207711(P2015-207711) |
審決分類 |
P
1
8・
537-
Z
(H04L)
P 1 8・ 536- Z (H04L) |
最終処分 | 不成立 |
前審関与審査官 | 金沢 史明 |
特許庁審判長 |
高木 進 |
特許庁審判官 |
石井 茂和 山崎 慎一 |
発明の名称 | 証明書不要公開鍵基盤に基づく安全なクライアント・サーバ通信プロトコルを設計するシステムと方法 |
代理人 | 松永 宣行 |
代理人 | 伊藤 正和 |
代理人 | 原 裕子 |
代理人 | 三好 秀和 |