【事件の表示】
　特願２０１５−２０７７１１「証明書不要公開鍵基盤に基づく安全なクライアント・サーバ通信プロトコルを設計するシステムと方法」拒絶査定不服審判事件〔平成２８年　３月１７日出願公開，特開２０１６−　３６１６６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成２２年１２月１０日（パリ条約による優先権主張２００９年１２月１０日　インド）に出願した外国語書面出願である特願２０１０−２７５３８５号の一部を，特許法第４４条第１項の規定により，平成２７年１０月２２日に新たな特許出願としたものであって，
　平成２７年１１月５日付けで特許法第３６条の２第２項の規定による外国語書面，及び，外国語要約書面の日本語による翻訳文が提出され，同日付けで審査請求がなされる共に手続補正がなされ，平成２７年１１月２７日付けで審査官により拒絶理由が通知され，これに対して平成２８年３月１４日付けで意見書が提出されると共に手続補正がなされたが，平成２８年６月１日付けで審査官により拒絶査定がなされ，これに対して平成２８年１０月７日付けで審判請求がなされたものである。
　
第２．本願発明について
　本願の請求項１〜請求項１４に係る発明は，平成２８年３月１４日付けの手続補正により補正された特許請求の範囲の請求項１〜請求項１４に記載された事項によって特定されるものである。
　
第３．原審の拒絶理由
　原審における平成２７年１１月２７日付けの拒絶理由（以下，これを「原審拒絶理由」という）は，概略，以下のとおりである。
　
「　　　　　　　　　　　　　　理由
　
１．（明確性）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。
　
２．（サポート要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていない。
　
３．（実施可能要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
４．（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
●理由１（明確性）について
＜省略＞
　
●理由２（サポート要件）について
　
・請求項　１−７
　請求項１に記載された「前記処理値を受信かつ検証することにより偽造を検出し，さらには検証値を生成する第１検証器」の「検証値」は，発明の詳細な説明に記載された何れの事項に対応するのか不明である。
　請求項２−７についても同様。
　
・請求項　１−７
　請求項１には「前記所定プリミティブを有して前記秘密鍵生成器からの前記秘密鍵を受信・・・するセッション鍵生成器」と記載されている。
　一方，発明の詳細な説明には，段落００６１，００６８，００７６，００８２，００９１，００９８に，クライアント及びサーバが，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行って秘密鍵を共有する点について記載されている。
　しかしながら，発明の詳細な説明には，クライアント及びサーバが，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行う際に，サーバがクライアントから秘密鍵を受信する点について記載も示唆も為されていない。
　
・請求項　２
　請求項２に記載された「前記処理器は，前記乱数を受信し，かつ，前記乱数を，楕円曲線暗号化を使用して前記公開鍵により暗号化する暗号化器を含む」の「前記公開鍵」は，第２検証器が生成した公開鍵を意味するといえる。
　しかしながら，発明の詳細な説明には，処理器が，受信した乱数を，楕円曲線暗号化を使用して第２検証器が生成した公開鍵により暗号化する点は記載されていない。
　
・請求項　４
　請求項４に記載された「前記第１検証器は，前記処理値を受信し，かつ，前記処理値を，楕円曲線暗号化を使用して前記個人鍵により復号化する復号化器を含む」の「前記個人鍵」は，第２検証器が生成した対応個人鍵を意味するといえる。
　しかしながら，発明の詳細な説明には，第１検証器が，受信した処理値を，楕円曲線暗号化を使用して第２検証器が生成した対応個人鍵により復号化する点は記載されていない。
　
●理由３（実施可能要件）について
　
・請求項　１−７
　請求項１には「前記所定プリミティブを有して前記秘密鍵生成器からの前記秘密鍵を受信・・・するセッション鍵生成器」と記載されている。
　発明の詳細な説明には，段落００６１，００６８，００７６，００８２，００９１，００９８に，クライアント及びサーバが，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して秘密鍵についてネゴシエーションを行って秘密鍵を共有する点について記載されている。
　鍵共有技術の分野において，楕円曲線ディフィー・ヘルマンアルゴリズムが，共有しようとする鍵自体の送受信を必要としないアルゴリズムであることは，技術常識である。
　しかしながら，発明の詳細な説明には，楕円曲線ディフィー・ヘルマンアルゴリズムを使用してサーバがクライアントから秘密鍵を受信するということが技術的に如何なることであるのかという点について記載されておらず，この点は，当業者にとって発明の詳細な説明の記載事項及び技術常識から明らかな事項でもない。
　してみると，発明の詳細な説明は，請求項１の「前記秘密鍵に対応するセッション鍵を，前記所定プリミティブに基づいて生成するセッション鍵生成器」について，当業者が実施可能な程度に記載したものでない。請求項２−７についても同様。
　
・請求項　１−１４
　請求項１には「前記秘密鍵に対応するセッション鍵を，前記所定プリミティブに基づいて生成するセッション鍵生成器」と記載されている。
　発明の詳細な説明には，段落００７６，００９１に，サーバが，クライアントと共有する秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用してセッション鍵を生成する点が記載されている。
　鍵共有技術の分野において，楕円曲線ディフィー・ヘルマンアルゴリズムが，鍵を共有しようとする装置同士が予め共有する秘密情報を必要としないアルゴリズムであることは，技術常識である。
　しかしながら，発明の詳細な説明には，サーバが，クライアントと共有する秘密鍵を使用する楕円曲線ディフィー・ヘルマンアルゴリズムというものが技術的に如何なるアルゴリズムを意味するのかという点について記載されておらず，この点は，当業者にとって発明の詳細な説明の記載事項及び技術常識から明らかな事項でもない。
　してみると，発明の詳細な説明は，請求項１の「前記秘密鍵に対応するセッション鍵を，前記所定プリミティブに基づいて生成するセッション鍵生成器」について，当業者が実施可能な程度に記載したものでない。請求項２−７についても同様。
　請求項８に記載された「セッション鍵生成器を使用して前記秘密鍵及び前記所定プリミティブに基づきセッション鍵を生成する」についても同様。請求項９−１４についても同様。
　
●理由４（進歩性）について
＜省略＞」
　
第４．原審拒絶理由に対する当審の判断
１．理由２について
（１）本願の請求項１の，
「処理値を受信かつ検証することにより偽造を検出し，さらには検証値を生成する第１の検証器」，
　という記載における「検証値」に関して，本願明細書の発明の詳細な説明には，
「　【００７５】
　サーバは，生成された値に前処理関数を施した後，当該前処理値及び当初値をクライアントに送信する。前処理値は当初値から算出され，前処理値及び当初値間の差異のみが，前処理値の場合にビットシーケンスが改変されることを示す。クライアント側において，前処理値が，シャフリング，Ｔ関数及びＬＦＳＲの関数を逆順に使用して，すなわちＬＦＳＲの後にＴ関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は，当該値を前処理する場合に逆にされる。３つの関数すべてが可逆なので，当該実行順序は，データ損失及び悪影響なしに逆にすることができる。クライアントは，上述の関数を逆順に実行した後（すなわち，ＬＦＳＲの後にＴ関数及びビットシャフリングが追従した後），
検証値
検証値
　という記載が存在し，上記引用の段落【００７５】の記載中の，
「クライアント側において，前処理値が，シャフリング，Ｔ関数及びＬＦＳＲの関数を逆順に使用して，すなわちＬＦＳＲの後にＴ関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は，当該値を前処理する場合に逆にされる。３つの関数すべてが可逆なので，当該実行順序は，データ損失及び悪影響なしに逆にすることができる。クライアントは，上述の関数を逆順に実行した後（すなわち，ＬＦＳＲの後にＴ関数及びビットシャフリングが追従した後），
検証値
検証値
　という内容から，段落【００７５】に記載の「検証値」とは，「サーバ」で，「当初値」から生成された「前処理値」を，「クライアント側」で，「前処理をする場合」の「逆」の「実行順序」で「実行した」結果，得られた値であって，この値が，「サーバ」から，「クライアント側」に送信された「当初値と比較することにより」，「前処理値」が，「偽造されたものか否かを検出する」ための「値」であって，「前処理値」が，「偽造」されていなければ，当該「検証値」は，「当初値」と一致するものである。
　一方，本願の請求項１においては，上記引用の本願の請求項１の記載にあるとおり，
「処理値」は，「受信され検証することにより偽造を検出」されるものであり，「検証値」は，「検証器」によって，“さらには，生成される”ものである。
　したがって，本願の請求項１に記載された内容からは，「検証値」は，「処理値」の「偽造を検出」ことに関与するものとは読み取れず，本願の請求項１に記載の「検証値」と，上記引用の，本願明細書の段落【００７５】に記載の「検証値」とが，同じものであるとは認められない。
　本願明細書の発明の詳細な説明には，上記引用の，段落【００７５】に記載された「検証値」以外に，検証値が存在していないので，本願の請求項１に記載の「検証値」は，本願明細書の発明の詳細な説明に記載されたものではない。
　
（２）本願の請求項１に記載された，
「所定のアルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有し」，
　に関して，本願の請求項１には，上記引用記載の後段に更に，
「サーバは，前記乱数生成器，前記処理器，前記第２検証器及び前記セッション鍵生成器を含み，
　クライアントは前記第１検証器，前記計算器及び前記秘密鍵生成器を含み」，
　と記載され，上記引用の記載から，本願の請求項１においては，「秘密鍵」を生成する「秘密鍵生成器」は，「クライアント」にしか存在していないので，「サーバ」が，「クライアント」と「秘密鍵」を「共有」するためには，「クライアント」の「秘密鍵生成器」で生成された「秘密鍵」を，「クライアント」から，「サーバ」に送信する必要があることは明らかである。
　一方，「秘密鍵生成器」，及び，「秘密鍵」を，「クライアント」と，「サーバ」とで「共有」する点に関して，本願明細書の発明の詳細な説明には，「秘密鍵生成器」という記載は存在しない。
　更に，“「秘密鍵」を，「クライアント」と，「サーバ」とで「共有」する”点については，本願明細書の発明の詳細な説明に，
　
「【００５９】
　図１に示されるように，クライアントは，「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは，クライアントメッセージに応答して，乱数生成器の使用により「ｎ」ビット長の乱数（値）を生成する。サーバはさらに，生成された値を，クライアントの公開鍵を使用して暗号化する。乱数値の暗号化のプロセス中，デジタル証明書は生成されない。サーバは，個々のクライアントに割り当てられた個人鍵及び公開鍵の組を追跡し続ける。サーバ側において当該値を暗号化するべく，楕円曲線暗号化法が利用される。クライアントの公開鍵を使用して暗号化された値は，クライアントに送信される。サーバは，クライアントに対し，暗号化された形式の数を包含する値を復号化させて自身のＩＤを証明させるようにチャレンジを行う。クライアントは，暗号化された値を受信し，かつ，当該暗号化された値を自身の個人鍵を使用して復号化する。クライアントは，暗号化された値を，自身の個人鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用して復号化し，かつ，当該値が信頼されるソースから送信されたか否かを検証する。クライアントは，暗号化された値を成功裏に復号化して当初値を回復させることにより，サーバが信頼できることを証明する。クライアントは，サーバが送信した値の検証ステップ（すなわち，サーバが送信した暗号化された値の復号化）の完了時に，楕円曲線暗号化法を使用して公開鍵及び個人鍵の対を生成する。
　【００６０】
　クライアントは，復号化された値について，楕円曲線デジタル署名アルゴリズムを使用して署名を生成し，当該署名をサーバに送信する。サーバは，自身の一部において，クライアントが送信した署名を受信し，かつ，当該署名を，楕円曲線デジタル署名アルゴリズムを使用して検証する。
サーバは，クライアントが送信した署名を検証した後すぐに，公開鍵及び個人鍵の対を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し，かつ，生成された公開鍵を当該クライアントに送信する
　【００６１】
　
クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する。サーバは，その見返りとして，楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「ｍ」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図１の参照番号１００は，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長のセッション鍵を生成するステップを示す
　
「【００６４】
　第１ステップ：クライアントは，「クライアントです。こんにちは！」とのメッセージを送信することによりサーバへの通信を開始する。
　【００６５】
　第２ステップ：サーバは，疑似乱数生成器（ＰＲＮＧ）を使用してランダムチャレンジ又はｎビットの乱数値を生成する。さらに，サーバは，楕円曲線暗号化法（ＥＣＥ）を使用してクライアントの公開鍵により乱数値を暗号化する。クライアントは，暗号化された乱数値を，ＥＣＥを使用して自身の個人鍵により復号化する。
　【００６６】
　第３ステップ：クライアントは，楕円曲線暗号化法を使用することにより楕円曲線上に公開鍵及び個人鍵を生成する。公開鍵及び個人鍵の長さは，ＮＩＳＴ（アメリカ国立標準技術研究所）により推奨される２５６ビット，３８４ビット又は５１２ビットのいずれかとなり得る。クライアントは，サーバから送られた値に基づく署名を，楕円曲線デジタル署名アルゴリズムを使用して生成し，当該署名をサーバに送信する。
　【００６７】
　第４ステップ：サーバは，当該署名を，楕円曲線デジタル署名アルゴリズムを使用して検証した後，
楕円曲線上に鍵の対を生成する。サーバは，自身の公開鍵をクライアントに送信する
　【００６８】
　第５ステップ：
クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマン）アルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う
　【００６９】
　第６ステップ：
クライアント及びサーバは，暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたｍビットのセッション鍵についてネゴシエーションを行う
　【００７０】
　第７ステップ：安全な通信がクライアント及びサーバ間に確立される。」（以下，これを「明細書記載２」という），
　
「【００７３】
　図２に示されるように，クライアントは，「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは，クライアントメッセージに応答して，乱数生成器の使用により「ｎ」ビット長の乱数（値）を生成する。サーバは，生成された乱数値を，メッセージ前処理関数（メッセージランダム化関数）を使用して処理する。メッセージ前処理関数は，３つの演算を順次に行うことを含む。３つの演算は，シャフリング，Ｔ関数及びＬＦＳＲ（線形帰還シフトレジスタ）である。前処理のプロセスは，ビットのシャフリングから開始する。ビットのシャフリングは，拡散の増加に役立つ。拡散とは，入力の統計学上の冗長性が出力において散逸する特性を言及する。シャフリングのプロセスは可逆なので，当初ビットシーケンスは，シャフリング後のビットシーケンスから容易に回復させることができる。
　【００７４】
　ビットシャフリングのプロセスの後に，Ｔ関数のプロセスが追従する。Ｔ関数は，同じビットとそれよりも下位のビットとの線形結合によってすべてのビットを更新する更新関数である。Ｔ関数のプロセスの後に，ＬＦＳＲ（線形帰還シフトレジスタ）の関数が追従する。ＬＦＳＲは，３２次かつ２３２−１周期の既約多項式を使用するプロセスである。ＬＦＳＲの場合，所与の入力が，所与の多項式に対して４〜１５周期だけシフトされる。ビットシャフリング，Ｔ関数及びＬＦＳＲ（集合的に前処理と称する）の出力は，高度にランダム化された値となる。
　【００７５】
　サーバは，生成された値に前処理関数を施した後，当該前処理値及び当初値をクライアントに送信する。前処理値は当初値から算出され，前処理値及び当初値間の差異のみが，前処理値の場合にビットシーケンスが改変されることを示す。クライアント側において，前処理値が，シャフリング，Ｔ関数及びＬＦＳＲの関数を逆順に使用して，すなわちＬＦＳＲの後にＴ関数及びビットシャフリングが追従するプロセスで検証される。上述のプロセスの実行順序は，当該値を前処理する場合に逆にされる。３つの関数すべてが可逆なので，当該実行順序は，データ損失及び悪影響なしに逆にすることができる。クライアントは，上述の関数を逆順に実行した後（すなわち，ＬＦＳＲの後にＴ関数及びビットシャフリングが追従した後），検証値を取得する。クライアントは，ＬＦＳＲ，Ｔ関数及びビットシャフリングのプロセスを実行した結果として取得された検証値を，サーバが送信した当初値と比較することにより，当該値が偽造されたものか否かを検出する。
サーバが送信した値を検証した後クライアントは，サーバが送信した値が認証された場合に公開鍵及び個人鍵の対を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。クライアントはさらに，サーバが送信した値について，楕円曲線デジタル署名アルゴリズムを使用して署名も生成し，当該署名を自身の公開鍵とともに当該サーバに送信する。サーバは署名を受信すると，クライアントが送信した署名を，楕円曲線デジタル署名アルゴリズムを使用して検証し，その後，公開鍵及び個人鍵の対を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成する。その後，サーバは，生成された公開鍵をクライアントに送信する
　【００７６】
　
クライアントは，サーバから公開鍵を受信すると，「ｍ」ビット長の秘密鍵を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し，当該秘密鍵を当該サーバと共有する。サーバは，その見返りとして，秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「ｍ」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図２の参照番号２００は，秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「ｍ」ビット長のセッション鍵を生成するステップを示す
　
「【００７７】
　第２ネットワークセキュリティプロトコルを使用するサーバ及びクライアント間の安全な通信に関連するステップは，以下のように与えられる。
　【００７８】
　第１ステップ：クライアントは，「クライアントです。こんにちは！」とのメッセージを送信することによりサーバへの通信を開始する。
　【００７９】
　第２ステップ：サーバは，ランダムチャレンジ又はｎビットの乱数を，疑似乱数生成器（ＰＲＮＧ）を使用して生成し，当該乱数のメッセージ前処理を計算する。クライアントは乱数及びＭＰ（乱数）を受信する。クライアントはＭＰ（乱数）を検証する。
　【００８０】
　第３ステップ：
クライアントは，公開鍵及び個人鍵を楕円曲線上に生成する
当該署名を自身の公開鍵とともに当該サーバに送信する
　【００８１】
　第４ステップ：
サーバは，署名を検証して鍵の対を楕円曲線上に生成する。サーバは，自身の公開鍵をクライアントに送信する
　【００８２】
　第５ステップ：
クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマン）アルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う
　【００８３】
　第６ステップ：
クライアント及びサーバは，暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたｍビットのセッション鍵についてネゴシエーションを行う
　【００８４】
　第７ステップ：安全な通信がクライアント及びサーバ間に確立される。」（以下，これを「明細書記載４」という），
　
「【００８８】
　図３に示されるように，クライアントは，「クライアントです。こんにちは。」のような導入メッセージを送信することによって通信を開始する。サーバは，クライアントメッセージに応答して，乱数生成器の使用により「ｎ」ビット長の乱数（値）を生成する。サーバはさらに，クライアントの公開鍵を使用して生成値を暗号化する。乱数値の暗号化のプロセス中，デジタル証明書は生成されない。サーバは，個々のクライアントに割り当てられた個人鍵及び公開鍵の組を追跡し続ける。サーバ側において当該値を暗号化するべく，楕円曲線暗号化法が利用される。クライアントの公開鍵を使用して暗号化された値は，クライアントに送信される。サーバは，クライアントに対し，暗号化された値を復号化させて自身のＩＤを証明させるようにチャレンジを行う。クライアントは，暗号化された値を受信し，当該暗号化された値を，自身の個人鍵及び楕円曲線暗号化法を使用して復号化する。これにより，サーバが信頼できる宛先であることが証明される。
　【００８９】
　クライアントはさらに，送信された値についてのヤコビ恒等式を計算する。すなわち，クライアントは，当該復号化された値を３つの部分に分割する。クライアントはさらに，当該受信した値についてリー積を生成する。
　【００９０】
　本発明によれば，当該値が３つの部分すなわちｘ，ｙ及びｚに分割される場合，当該値のヤコビ恒等式はｘｌｌｙｌｌｚとして表される。乱数のヤコビ恒等式は，［［ｘ，ｙ］，ｚ］＋［［ｙ，ｚ］，ｘ］＋［［ｚ，ｘ］，ｙ］＝０との関係を使用して検証される。
　【００９１】
　本発明によれば，クライアントが当該値のリー積を生成してサーバに送信すると，当該サーバは，当該クライアントが送信したリー積を，［［ｘ，ｙ］，ｚ］＋［［ｙ，ｚ］，ｘ］＋［［ｚ，ｘ］，ｘ］＝０との関係を使用して検証する。クライアントが送信したリー積の信ぴょう性が検証された後，
サーバはさらに，公開鍵及び個人鍵の対を，楕円曲線暗号化法を使用して生成する。楕円曲線暗号化法の一部をなす楕円曲線ディフィー・ヘルマンアルゴリズムが，公開鍵及び個人鍵の対を生成する目的で使用される
クライアントはその後，自身の公開鍵をクライアントに送信する。クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する。サーバは，その見返りとして，秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビットのセッション鍵を生成する。秘密鍵及び対応セッション鍵が，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成される。図３の参照番号３００は，「ｍ」ビット長のセッション鍵を生成するステップを示す。
　
「【００９２】
　第３ネットワークセキュリティプロトコルを使用するサーバ及びクライアント間の安全な通信に関連するステップは，以下のように与えられる。
　【００９３】
　初期設定：すべてのクライアントが，鍵生成センタ（ＫＧＣ）として動作するサーバが生成した公開鍵及び個人鍵の対を有する。
　【００９４】
　第１ステップ：クライアントは，「クライアントです。こんにちは！」とのメッセージを送信することによりサーバへの通信を開始する。
　【００９５】
　第２ステップ：サーバは，疑似乱数生成器（ＰＲＮＧ）を使用してランダムチャレンジ又はｎビットの乱数を生成する。さらに，サーバは，楕円曲線暗号化法（ＥＣＣ）を使用してクライアントの公開鍵により乱数を暗号化する。クライアントは，当該暗号化された乱数を，楕円曲線暗号化法を使用して自身の個人鍵により復号化する。
　【００９６】
　第３ステップ：クライアントは，乱数についてのヤコビ恒等式ｘ||ｙ||ｚを計算してリー積［［ｘ，ｙ］，ｚ］をサーバに送信する。
　【００９７】
　第４ステップ：サーバは，［［ｘ，ｙ］，ｚ］＋［［ｙ，ｚ］，ｘ］＋［［ｚ，ｘ］，ｙ］＝０との関係を検証する。
サーバは，ＥＣＣ（楕円曲線暗号化法）を使用して自身の公開鍵をクライアントに送信する
　【００９８】
　第５ステップ：
クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマンアルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う
　【００９９】
　
第６ステップ：クライアント及びサーバは，暗号化を目的として楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成されたｍビットのセッション鍵についてネゴシエーションを行う
　【０１００】
　第７ステップ：クライアント及びサーバ間に安全な通信が確立される。」（以下，これを「明細書記載６」という）
　
　と記載されていて，明細書記載１に，
「クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する」，
　明細書記載２に，
「クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマン）アルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う」，
　明細書記載３に，
「クライアントは，サーバから公開鍵を受信すると，「ｍ」ビット長の秘密鍵を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し，当該秘密鍵を当該サーバと共有する」，
　明細書記載４に，
「クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマン）アルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う」，
　明細書記載５に，
「クライアントはその後，自身の公開鍵をクライアントに送信する。クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する」，
　明細書記載６に，
「クライアント及びサーバは，ＥＣＤＨ（楕円曲線ディフィー・ヘルマンアルゴリズムを使用してｍビット共有秘密鍵についてネゴシエーションを行う」，
　とある。
　上記引用の明細書記載１〜明細書記載６の内容からは，“クライアントが，サーバから受信した公開鍵を用いて，ＥＣＤＨによって，秘密鍵を生成する”こと，及び，“当該秘密鍵を当該サーバと共有する”ことまでは読み取れるが，明細書記載２，明細書記載４，及び，明細書記載６に記載の「ネゴシエーション」とは，一般的な意味においては，単に，「交渉」という意味に過ぎず，当該技術分野においても，「サーバ」と，「クライアント」との「交渉」において，具体的に何を行うかを特定する内容を含むものではないので，単に「ネゴシエーション」といっただけでは，“秘密鍵をサーバと共有する”ための手法が示されるものではないから，明細書記載１〜明細書記載６の内容を検討しても，「クライアント」のみが「秘密鍵生成器」を有すること，及び，当該「クライアント」が有する「秘密鍵生成器からの秘密鍵」を「サーバ」が受信することで，「クライアント」と「共有」することを読み取ることはできない。
　仮に，本願の請求項に記載された字句どおり，単に，
“秘密鍵生成器からの秘密鍵を（サーバが）クライアントと共有する”
　ものであるとしても，上記に検討したように，そのような構成は，本願明細書の発明の詳細な説明に記載されてはいない。
　
　ここで，楕円曲線ディフィー・ヘルマン鍵共有（以下，これを「ＥＣＤＨ」という）について確認しておく。
　「ＥＣＤＨ」については，例えば，本願の第１国出願前に既に公知である，特開２０００-１３７４３６号公報（２０００年５月１６日公開，以下，これを「周知技術文献」という）に，
　
Ａ．「【０００９】たとえば，公開鍵暗号系と知られる（有限体上の）ディフィ−ヘルマン（Diffie-Hellman）鍵交換と同様の鍵交換方式を実現することができる。楕円曲線上のベースポイントをＧとし，Ａの秘密鍵をｓａとしＰａ＝ｓａＧを演算して公開鍵とする。また，Ｂの秘密鍵をｓｂとし，Ｐｂ＝ｓｂＧを演算してこれを公開鍵とする。ＡはＢの公開鍵Ｐｂと自分の秘密鍵ｓａから，ＫＡＢ＝ｓａＰｂ＝ｓａｓｂＧを演算することによって共通鍵を得ることができる。また，同様にして，ＢはＡの公開鍵Ｐａと自分の秘密鍵ｓｂから，ＫＢＡ＝ｓｂＰａ＝ｓｂｓａＧを演算することによって共通鍵を得ることができる。この方式は，ＥＣＤＨ（Elliptic Curve Diffie-Hellman）方式と呼ばれ，秘密鍵ｓａ，ｓｂをスカラー量として楕円曲線上の点Ｇ，Ｐａ，Ｐｂに乗算する必要があり，暗号化／復号化の際に大量の演算処理を必要とする。この他にＥＣＤＳＡ方式やＥＣＥＳ方式なども提案されているが，演算処理が大きくなる点については同様である。（以下省略）」，
　
　と記載されていて，上記Ａの記載内容から明らかなように，「ＥＣＤＨ」は，
“共通鍵を共有する，Ａと，Ｂが，互いの公開鍵Ｐａと，Ｐｂを交換し，交換した公開鍵を用いて，Ａは，自身の秘密鍵ｓａと，Ｂの公開鍵Ｐｂとから，計算でＫＡＢを求め，Ｂは，自身の秘密鍵と，Ａの公開鍵とから，計算でＫＢＡを求め，ＫＡＢ＝ＫＢＡであることは明らかであるから，当該ＫＡＢ＝ＫＢＡが，Ａと，Ｂの共通鍵となる”というものである。
　即ち，ＥＣＤＨにおいては，Ａ側からも，Ｂ側からも，共通鍵が，相手側に送信されることはない。
　以上の検討を踏まえ，上記検討の周知技術文献に記載された，周知技術である「ＥＣＤＨ」のアルゴリズムと，本願の請求項１に記載の事項，及び，本願明細書の発明の詳細な説明に記載された事項と対比すると，
　周知技術文献における「公開鍵」，「秘密鍵」が，本願における「公開鍵」，「個人鍵」に対応するものであり，周知技術文献における「共通鍵」が，本願における「秘密鍵」，或いは，「共通秘密鍵」に対応するものであると解せる。
　上記において，明細書記載１〜明細書記載６として引用し，更に，上記において，各明細書記載から抽出した記載内容に従えば，本願明細書の発明の詳細な説明においては，「秘密鍵」，或いは，「共有秘密鍵」は，「クライアント」が，「サーバ」と，「共有する」もの，或いは，「クライアント及びサーバ」は，「共有秘密鍵についてネゴシエーションを行う」ものであることが読み取れ，上記において指摘したとおり，本願明細書の発明の詳細な説明には，「クライアント」が「秘密鍵」を生成することは記載されているが，当該「クライアント」が，「秘密鍵生成器」を有することは記載されていないので，本願明細書の発明の詳細な説明に記載された「ＥＣＤＨ（楕円曲線ディフィー・ヘルマンアルゴリズム」が，上記において，周知技術文献を用いて確認した，「ＥＣＤＨ」と同じものであれば，本願明細書の発明の詳細な説明における「クライアント」と，「サーバ」とが，「秘密鍵」を「共有する」こと，或いは，「クライアント及びサーバ」は，「共有秘密鍵についてネゴシエーションを行う」ということは，周知技術である「ＥＣＤＨ」において，「クライアント」と，「サーバ」が，互いの「公開鍵」を交換して，当該交換した，「公開鍵」と，自らの「秘密鍵」とから，「共有鍵」を計算で求めることを意味するものと，一応，推察される。
　しかしながら，本願の請求項１においては，上記において指摘したとおり，「クライアント」のみが，「秘密鍵生成器」を有するものであって，本願の請求項１における「秘密鍵」は，当該「秘密鍵生成器」によって生成されるものである。
　そうすると，本願の請求項１における「秘密鍵を前記クライアントと共有する」ことが，「クライアント」から，「サーバ」へ，「秘密鍵」を送信するものと解釈するか，字句どおり，単に，「共有」すると読むかにかかわらず，周知技術である“ＥＣＤＨアルゴリズム”における“共有鍵の共有”を意味するものとは認められず，上記において検討したとおり，「ネゴシエーション」は，「共有」のための手法を何ら特定するものではないので，
　本願明細書の発明の詳細な説明からは，本願の請求項１に係る発明における“「サーバ」が，当該「クライアント」のみが有する「秘密鍵生成器」を用いて生成された「秘密鍵生成器からの秘密鍵」を，当該「クライアントと共有」する”ことを，読み取ることができない。
　
（３）以上，上記（１），及び，（２）において検討したとおりであるから，本願の請求項１に係る発明は，本願明細書の発明の詳細な説明に記載されたものではない。
　したがって，本願の請求項１を引用する，本願の請求項２〜本願の請求項７に係る発明も，本願明細書の発明の詳細な説明に記載されたものではない。
　
２．理由３について
　本願の請求項１に記載の，
「秘密鍵生成器からの前記秘密鍵を前記クライアントと共有し」，
　及び，
「クライアントは前記第１検証器，前記計算器及び前記秘密鍵生成器を含み」，
　に関して，上記１．において，検討したとおり，「秘密鍵生成器」は，本願明細書の発明の詳細な説明に記載されておらず，
　したがって，“クライアントが，秘密鍵生成器を含む”ことも，本願明細書の発明の詳細な説明に記載されていない。
　そして，上記１.において，明細書記載１〜明細書記載６として引用した，本願明細書の発明の詳細な説明の記載内容には，
“クライアントが，サーバから受信した公開鍵を用いて，ＥＣＤＨによって，秘密鍵を生成し，当該秘密鍵を，サーバと共有する”
　ということまでは読み取れるが，明細書記載１〜明細書記載６に記載された内容から読み取れることはその程度であり，当該各明細書記載から読み取れる事項を，上記１．において参照した，「ＥＣＤＨ」に関する周知の技術知識によって補足した場合は，「ＥＣＤＨ」における「共有」とは，「クライアント」と，「サーバ」が，互いの「公開鍵」を交換して，相手から受信した「公開鍵」と，自らの「秘密鍵」（本願における「個人鍵」）とから，「共有鍵」（本願における「秘密鍵」）を計算によって求めることで，「共有」することを意味するものであるから，本願の請求項１における，
“クライアントのみが有する秘密鍵生成器が生成した秘密鍵（周知技術における「共有鍵」）を，サーバと共有する”ことを，どのようにして実現するかについては，本願明細書の発明の詳細な説明に記載された内容から読み取ることができない。
　よって，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
（なお，審判請求人は，平成２８年１０月７日付けの審判請求書（以下，「審判請求書」という）において，
「４．原査定の拒絶理由への反論 
 （１）特許法第３６条第６項第１号に係る拒絶理由への反論 
 　上記拒絶理由において「請求項１には「前記所定アルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・するセッション鍵生成器」と記載されている。 
 　請求項１には「サーバは前記乱数生成器，前記処理器，前記第２検証器及び前記セッション鍵生成器を含み，クライアントは前記第１検証器，前記計算器及び前記秘密鍵生成器を含み，」とも記載されていることから，請求項１の他の記載，技術常識及び通常の日本語に鑑みれば，「前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・する」という記載は，クライアントに含まれる前記秘密鍵生成器から前記秘密鍵を受信することにより前記秘密鍵を前記クライアントと共有することを意味するといえる。」と認定されている。 
 　ここで，本願の当初明細書の段落００６１には「クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する」と記載され，段落００７６には「クライアントは，サーバから公開鍵を受信すると，「ｍ」ビット長の秘密鍵を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し，当該秘密鍵を当該サーバと共有する」と記載され，段落００９１には「クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する」と記載されている。 
 　すなわち，上記認定における「クライアントに含まれる前記秘密鍵生成器から前記秘密鍵を受信することにより前記秘密鍵を前記クライアントと共有することを意味するといえる」との事項が，本願の当初明細書に記載されている。 
 　したがって，本願発明は，発明の詳細な説明に記載したものであって，特許法第３６条第６項第１号に係る拒絶理由は解消している。 
  
 （２）特許法第３６条第４項第１号に係る拒絶理由への反論 
 　原査定に係る審査官殿は，「ＥＣＤＨにより秘密鍵として生成したもの（スカラー）を，ＥＣＤＨにおける公開鍵（ベクトル）として改めて使用することができないことは，当業者にとって明らかな事項であるから，秘密鍵生成器によりＥＣＤＨの秘密鍵として生成したものを，セッション鍵生成器によりＥＣＤＨの公開鍵として使用することは不可能である」として，請求項１の「前記所定アルゴリズムを有して前記秘密鍵生成器からの前記秘密鍵を前記クライアントと共有・・・するセッション鍵生成器」との記載について，いわゆる当業者が本願発明を実施できる程度に明確かつ十分に記載したものではないと判断しているが，出願人である本審判の請求人は，本願の当初明細書の段落００６１，００６８，００７６，００８２，００９１及び００９８に記載される楕円曲線ディフィー・ヘルマンシステム，楕円曲線デジタル署名システム，メッセージランダム化システム及びヤコビ恒等式検証システムからなる群から選択されるアルゴリズムの使用は，当業者の技術常識内において可能であると信じている。 
 　なお，原査定に係る審査官殿は「ＥＣＤＨにより秘密鍵として生成したもの（スカラー）を，ＥＣＤＨにおける公開鍵（ベクトル）として改めて使用することができない」と認定しているが，本願の当初明細書に記載されている事項は，「クライアントは，サーバから公開鍵を受信すると，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して「ｍ」ビット長の秘密鍵を生成し，かつ，当該秘密鍵を当該サーバと共有する。サーバは，その見返りとして，楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「ｍ」ビットのセッション鍵を生成する」（段落００６１），「クライアントは，サーバから公開鍵を受信すると，「ｍ」ビット長の秘密鍵を，楕円曲線ディフィー・ヘルマンアルゴリズムを使用して生成し，当該秘密鍵を当該サーバと共有する。サーバは，その見返りとして，秘密鍵及び楕円曲線ディフィー・ヘルマンアルゴリズムに基づき「ｍ」ビットのセッション鍵を生成する」（段落００７６）と記載されるように，「ＥＣＤＨにより秘密鍵として生成したもの（スカラー）を，ＥＣＤＨにおける公開鍵（ベクトル）として改めて使用すること」を記載しているわけではない。 
 　したがって，発明の詳細な説明の記載は，経済産業省令で定めるところにより，いわゆる当業者が本願発明を実施できる程度に明確かつ十分に記載したものと考えられるので，特許法第３６条第４項第１号に係る拒絶理由は解消している。」
　と主張しているが，「共有」については，上記「１．理由２について」の（２）において検討したとおりであるから，請求人の上記主張は，採用できない。
　
　また，原審における拒絶査定の理由から，特許法第２９条２項（以下，「進歩性」という）が外れているが，本願の請求項１に記載の発明が，本願明細書の発明の詳細な説明に記載されたものであると仮定した場合は，請求人も，審判請求書おいて主張しているとおり，用いられている手法は何れも，当業者には周知の技術事項に過ぎないので，進歩性の拒絶理由が解消した訳ではないことを付言しておく。）
　
第５．むすび
　したがって，本願は，特許法第３６条第４項第１号及び第６項第１号に規定する要件を満たしていない。
　
　よって，結論のとおり審決する。