【事件の表示】
　特願２０１０−５１０９１９「認証方法及び認証実行用電子装置」拒絶査定不服審判事件〔平成２０年１２月１８日国際公開，ＷＯ２００８／１５２５３３，平成２２年　８月２６日国内公表，特表２０１０−５２９７６７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２００８年４月２８日（パリ条約による優先権主張外国庁受理２００７年６月１１日（以下，「優先日」という），欧州）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。
　
　　平成２１年１２月　８日　　　：国内書面，出願審査請求書の提出
　　平成２４年　６月１３日付け　：拒絶理由の通知
　　平成２４年　９月　５日　　　：意見書，手続補正書の提出
　　平成２４年１２月　６日付け　：拒絶査定　
　　平成２５年　３月１２日　　　：審判請求書，手続補正書の提出
　　平成２５年　５月１７日　　　：前置報告
　　平成２５年１０月　４日付け　：審尋
　　平成２６年　１月　８日　　　：回答書の提出
　　平成２６年１１月　６日付け　：平成２５年３月１２日付け手続補正
　　　　　　　　　　　　　　　　　についての補正却下の決定，
　　　　　　　　　　　　　　　　　拒絶理由の通知（当審）
　　平成２７年　２月　９日　　　：意見書，手続補正書の提出
　　平成２７年　６月１０日付け　：拒絶理由の通知（当審）
　　平成２７年　７月２８日　　　：意見書，手続補正書の提出
　
　
第２　本願発明
　
　本願の請求項１乃至５に係る発明は，上記平成２７年７月２８日付け手続補正書により補正された特許請求の範囲の請求項１乃至５に記載されたとおりのものであると認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
　
「　安全なデータ伝送の為の認証方法において，この認証方法が，
　プロセッサが，第１の暗号を用いることにより第１の認証プロトコルを実行するステップと，
　前記プロセッサが，第２の暗号を用いることにより第２の認証プロトコルを実行するステップとを具え，
　前記第１の暗号を，前記第２の暗号よりも安全性の高い暗号とし，
　前記第２の暗号を，前記第１の暗号よりも安全性の低く，かつ前記第１の暗号よりもデータ通信を高速にする暗号とし，
　さらに前記プロセッサが，共有キー及び乱数を入力として前記第１の暗号により第１のシードを出力するステップと，
　前記プロセッサが，前記第１のシードに基づいて第１のセッションキーを発生させるステップとを具え，
　前記第２の認証プロトコルに対する入力を前記第１のセッションキーとする認証方法。」　
　
　
第３　引用例
　
１　引用例１に記載されている技術的事項および引用発明
　
（１）本願の優先日前に頒布され，当審からの上記平成２７年６月１０日付け拒絶理由通知において引用された，“Ｐａｒｔ２　インターネットＶＰＮを実現するセキュリティプロトコル”，ＮＥＴＷＯＲＫ　ＷＯＲＬＤ，（株）ＩＤＧジャパン，２００３年３月１日，第8巻，第3号，p.41-50（以下，「引用例１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「
インターネットＶＰＮその要件とＩＰｓｅｃ
　ネットワーク上のセキュリティを確保するために，これまでに多くのセキュリティプロトコルが開発されている（表２）。だが，これらのすべてのプロトコルがインターネットＶＰＮを実現するのに適切というわけではない。　
　インターネットＶＰＮを実現するためには，次のような機能を実現することがプロトコルに求められる。　
●盗聴を防止するための暗号機能　
●なりすましを防止するための認証機能　
　また，
インターネットＶＰＮは，主にビジネスで利用することが目的となる。そこで，プロトコル以外の条件として，ビジネスアプリケーションとの親和性の高さも要求される。
　
このような条件を満たすのが，ＩＰｓｅｃである。ネットワーク層で定義されたプロトコルであるＩＰｓｅｃは，アプリケーション層やデータリンク層に依存しない。そのため，インターネットＶＰＮを実現する事実上の標準プロトコルとして使用されている。
　
Ｂ　「端末どうしがＩＰｓｅｃで通信するための設定項目　
　
ＩＰｓｅｃでは，セキュリティゲートウェイどうしが信頼できる通信相手とやり取りしているかどうかを確認したり，公のネットワーク上でのセキュリティを確保したパケット（ＩＰｓｅｃパケット）を確実に読み取ったりする作業が必要になる。
ＩＫＥ　
　
ＩＰｓｅｃでは認証や完全性の確保，データ暗号化機能を提供するために，セキュリティゲートウェイどうしで，あらかじめどのような認証方法や暗号化アルゴリズムを使用するか取り決めておく必要がある。この取り決めを行う機能がＩＫＥだ（図９）。
　
Ｃ　「
ＳＡの確立に重要なＩＫＥは相互接続のコア技術
　ＩＰｓｅｃでの通信のメカニズムを解説したときに，ＳＡの確立時に使用するＩＫＥについて触れた。…（中略）…
　ＩＫＥは，ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ ａｎｄ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のフレームワークのもと，Ｏａｋｌｅｙ機能などを踏襲して開発した鍵管理プロトコルで，ＵＤＰの５００番ポートを使って通信する。ＩＫＥを使用できる対称は，ＩＰｓｅｃだけに限らない。
ＩＰｓｅｃで使用するＩＫＥは，「ＩＰｓｅｃ ＤＯＩ（Ｄｏｍａｉｎ ｏｆ Ｉｎｔｅｒｐｒｅｔａｔｉｏｎ）」を含んでＩＰｓｅｃに特化した形態になっている。ＩＰｓｅｃでは，ＩＫＥが２つのフェーズを用いてＳＡを確立する。
　
Ｄ　「
ＩＫＥ ＳＡを確立するフェーズ１の役割と認証方法
　この項では，ＩＫＥがＳＡを確立する２つのフェーズのうちの「フェーズ１」の役割や認証方法について解説する。　
フェーズ１の役割　
　まず，フェーズ１の役割について説明しよう。
フェーズ１には，次の３つの役割がある。
●ＩＫＥ ＳＡを確立する
●フェーズ２の通信を安全に行う共有秘密鍵を生成する
●ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証する
　ＩＫＥ ＳＡは，先に述べたＳＡとは異なるので，インターネットＶＰＮを構築する作業では，両者をしっかり使い分けてほしい。ＩＫＥ ＳＡは，方向性を持たないため１つしか確立しない。」（第４５頁右欄２９行−第４６頁左欄８行）　
　
Ｅ　「
通信相手の認証方法
　
フェーズ１では，次の４とおりの方法で通信相手を認証する。
事前共有秘密鍵認証方式
（Ｐｒｅ−Ｓｈａｒｅｄ Ｓｅｃｒｅｔ）
セキュリティゲートウェイどうしがあらかじめ取り決めた秘密鍵で認証する。
電子署名認証方式
…（中略）…
公開鍵暗号認証方式
…（中略）…
改良型公開鍵暗号認証方式
…（中略）…
鍵計算の方法　
フェーズ１の擬似乱数発生関数の鍵には，「ＳＫＥＹＩＤ」を使用する。この「ＳＫＥＹＩＤ」の計算式は通信相手の認証方式ごとに異なる。
事前共有秘密鍵認証方式でのＳＫＥＹＩＤの計算式　
ＳＫＥＹＩＤ＝ｐｒｆ（事前共有秘密鍵，Ｎｉ＿ｂ｜Ｎｒ＿ｂ）　
…（中略）…
　これらの計算式の中の，「ｐｒｆ」は擬似乱数発生関数を表す。「ｐｒｆ（ｘｘ，ｙｙｙｙ）」は，ｘｘを鍵にしてｙｙｙｙに対して擬似乱数発生関数を使用することを表す。
「Ｎｉ＿ｂ」はイニシエータのセキュリティゲートウェイ（以下，イニシエータ）が発生した乱数，「Ｎｒ＿ｂ」はレスポンダのセキュリティゲートウェイ（以下，レスポンダ）が発生した乱数を意味し，「｜」が前後のメッセージを連結することを意味する。したがって，事前共有秘密鍵認証方式のＳＫＥＹＩＤの計算式では，事前共有秘密鍵を鍵にして，Ｎｉ＿ｂとＮｒ＿ｂを連結したメッセージに対して擬似乱数発生関数を使用することになる。
　
また，このようにして求めたＳＫＥＹＩＤを基に，次の３つの暗号鍵を生成する。
ＩＰｓｅｃで通信するときに使用する暗号鍵「ＳＫＥＹＩＤ＿ｄ」の計算式
ＳＫＥＹＩＤ＿ｄ＝ｐｒｆ（ＳＫＥＹＩＤ，ｇ＾ｘｙ｜ＣＫＹ−Ｉ｜ＣＫＹ−Ｒ｜０）
フェーズ２（後述）のメッセージ認証に使用する暗号鍵「ＳＫＥＹＩＤ＿ａ」の計算式
ＳＫＥＹＩＤ＿ａ＝ｐｒｆ（ＳＫＥＹＩＤ，ＳＫＥＹＩＤ＿ｄ｜ｇ＾ｘｙ｜ＣＫＹ−Ｉ｜ＣＫＹ−Ｒ｜１）
ＩＫＥ暗号通信に使用する暗号鍵「ＳＫＥＹＩＤ＿ｄ」の計算式
ＳＫＥＹＩＤ＿ｅ＝ｐｒｆ（ＳＫＥＹＩＤ，ＳＫＥＹＩＤ＿ａ｜ｇ＾ｘｙ｜ＣＫＹ−Ｉ｜ＣＫＹ−Ｒ｜２）
「ｇ＾ｘｙ」はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）鍵共有アルゴリズムによる鍵交換で生成された共有秘密鍵である。」（第４６頁左欄９行−右欄下から１行）　
　
Ｆ　「
ＩＫＥ ＳＡを確立するフェーズ１で３つの作業
　それでは，セキュリティゲートウェイどうしがフェーズ１を完了するまでのやり取りについて説明しよう。
フェーズ１では「パラメータ折衝」「鍵情報の交換」「認証」の順に作業する。
パラメータ折衝（図１２）　
　
イニシエータはＳＰＤに設定された処理内容に従い，レスポンダにＳＡパラメータを提案する。このときに提案されるパラメータの項目と内容は，表３のとおりである。
　
Ｇ　「
ＩＫＥのフェーズ１で提案するＳＡパラメータの項目と内容
暗号化アルゴリズム
ＤＥＳ
３ＤＥＳ
ＡＥＳ
　
Ｈ　「
鍵情報の交換（図１３）
　
パラメータ折衝が完了すると，イニシエータとレスポンダはＳＫＥＹＩＤを計算するために必要な鍵情報を交換する。
そこで，認証の段階からは暗号通信となる。
　
Ｊ　「
ＩＰｓｅｃ ＳＡを確立するフェーズ２
　この項では，ＩＫＥがＳＡを確立する２つのフェーズの「フェーズ２」の役割や認証方法について解説する。　
フェーズ２の役割　
　
フェーズ２には，次の２つの役割がある。
●ＩＰｓｅｃ ＳＡの確立
●ＩＰｓｅｃで通信するときに使用する秘密鍵の生成
ＩＰｓｅｃ ＳＡを確立するモード
　ＩＰｓｅｃ ＳＡを確立するには，３回の通信でＳＡが確立する「クイックモード」を使用する。クイックモードには方向性があり受信用のＩＰｓｅｃ ＳＡと送信用のＩＰｓｅｃ ＳＡが確立する。
フェーズ２では，クイックモードで「パラメータ折衝」「認証確認」の手順を経て，ＩＰｓｅｃ ＳＡを確立する。
パラメータ折衝（図１６）
　
フェーズ２のパラメータ折衝では，イニシエータがレスポンダにハッシュ値を認証情報として送信したあとに，ＳＡパラメータグループを提案する。複数のＳＡパラメータグループを提案することも可能だ。このとき提案されるＳＡパラメータの項目と内容は表４のとおりである。
　
Ｋ　「
ＩＫＥのフェーズ２で提案するＳＡパラメータの項目と内容
暗号化アルゴリズム
３ＤＥＳ
ＡＥＳ
　
　
（２）ここで，引用例１に記載されている事項を検討する。　
　
ア　上記Ａの「インターネットＶＰＮその要件とＩＰｓｅｃ　…（中略）…　インターネットＶＰＮは，主にビジネスで利用することが目的となる。そこで，プロトコル以外の条件として，ビジネスアプリケーションとの親和性の高さも要求される。このような条件を満たすのが，ＩＰｓｅｃである。ネットワーク層で定義されたプロトコルであるＩＰｓｅｃは，アプリケーション層やデータリンク層に依存しない。そのため，インターネットＶＰＮを実現する事実上の標準プロトコルとして使用されている。」との記載からすると，「ＩＰｓｅｃ」はインターネットＶＰＮを実現する標準プロトコルとして使用されていることが読み取れる。
　また，上記Ｂの「ＩＰｓｅｃでは，セキュリティゲートウェイどうしが信頼できる通信相手とやり取りしているかどうかを確認したり，公のネットワーク上でのセキュリティを確保したパケット（ＩＰｓｅｃパケット）を確実に読み取ったりする作業が必要になる。　…（中略）…　ＩＰｓｅｃでは認証や完全性の確保，データ暗号化機能を提供するために，セキュリティゲートウェイどうしで，あらかじめどのような認証方法や暗号化アルゴリズムを使用するか取り決めておく必要がある。この取り決めを行う機能がＩＫＥだ（図９）。」との記載，上記Ｃの「ＳＡの確立に重要なＩＫＥは相互接続のコア技術　…（中略）…　ＩＰｓｅｃで使用するＩＫＥは，「ＩＰｓｅｃ ＤＯＩ（Ｄｏｍａｉｎ ｏｆ Ｉｎｔｅｒｐｒｅｔａｔｉｏｎ）」を含んでＩＰｓｅｃに特化した形態になっている。ＩＰｓｅｃでは，ＩＫＥが２つのフェーズを用いてＳＡを確立する。」との記載からすると，「ＩＰｓｅｃ」では，ネットワーク上でのセキュリティ確保のために，「ＩＫＥ」が２つのフェーズを用いてＳＡを確立することが読み取れるから，引用例１には，
“ネットワーク上でのセキュリティ確保のために，ＩＰｓｅｃのＩＫＥが２つのフェーズを用いてＳＡを確立する方法”
が記載されていると解される。
　
イ　上記Ｄの「ＩＫＥ ＳＡを確立するフェーズ１の役割と認証方法　…（中略）…　フェーズ１には，次の３つの役割がある。●ＩＫＥ ＳＡを確立する　●フェーズ２の通信を安全に行う共有秘密鍵を生成する　●ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証する」との記載からすると，「ＩＫＥ」の「フェーズ１」では，ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証し，フェーズ２の通信を安全に行う共有秘密鍵を生成し，ＩＫＥ ＳＡを確立すると解される。
　また，上記Ｆの「ＩＫＥ ＳＡを確立するフェーズ１で３つの作業　…（中略）…　フェーズ１では「パラメータ折衝」「鍵情報の交換」「認証」の順に作業する。　…（中略）…　イニシエータはＳＰＤに設定された処理内容に従い，レスポンダにＳＡパラメータを提案する。このときに提案されるパラメータの項目と内容は，表３のとおりである。」との記載からすると，「ＩＫＥ」の「フェーズ１」では，初めにイニシエータとレスポンダがパラメータの折衝を行い，対応可能なパラメータにより通信が行われる。そして，上記Ｇの「ＩＫＥのフェーズ１で提案するＳＡパラメータの項目と内容」について，「項目」「暗号化アルゴリズム」に対応する「内容」として「ＤＥＳ」，「３ＤＥＳ」，「ＡＥＳ」が例示されている記載，上記Ｈの「鍵情報の交換（図１３）　パラメータ折衝が完了すると，イニシエータとレスポンダはＳＫＥＹＩＤを計算するために必要な鍵情報を交換する。　…（中略）…　そこで，認証の段階からは暗号通信となる。」との記載からすると，「パラメータ」の項目には，「暗号化アルゴリズム」が含まれ，「パラメータ折衝」の後は暗号通信となることから，「ＩＫＥ」の「フェーズ１」では，例えば，「ＤＥＳ」，「３ＤＥＳ」，「ＡＥＳ」などからパラメータ折衝により選択された暗号化アルゴリズム（以下，「第１の暗号アルゴリズム」という。）を用いることにより，イニシエータとレスポンダが通信を行うことが読み取れる。
　そうすると，引用例１には，
“パラメータ折衝により選択された第１の暗号化アルゴリズムを用いることにより，ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証し，フェーズ２の通信を安全に行う共有秘密鍵を生成し，ＩＫＥ ＳＡを確立するフェーズ１”
が記載されていると解される。
　
ウ　上記Ｊの「ＩＰｓｅｃ ＳＡを確立するフェーズ２　…（中略）…　フェーズ２には，次の２つの役割がある。●ＩＰｓｅｃ ＳＡの確立　●ＩＰｓｅｃで通信するときに使用する秘密鍵の生成」との記載からすると，「ＩＫＥ」の「フェーズ２」では，ＩＰｓｅｃで通信するときに使用する秘密鍵を生成し，ＩＰｓｅｃ ＳＡを確立すると解される。
　また，上記Ｊの「フェーズ２では，クイックモードで「パラメータ折衝」「認証確認」の手順を経て，ＩＰｓｅｃ ＳＡを確立する。　…（中略）…　フェーズ２のパラメータ折衝では，イニシエータがレスポンダにハッシュ値を認証情報として送信したあとに，ＳＡパラメータグループを提案する。複数のＳＡパラメータグループを提案することも可能だ。このとき提案されるＳＡパラメータの項目と内容は表４のとおりである。」との記載，上記Ｋの「ＩＫＥのフェーズ２で提案するＳＡパラメータの項目と内容」について，「項目」「暗号化アルゴリズム」に対応する「内容」として「ＤＥＳ」，「３ＤＥＳ」，「ＡＥＳ」が例示されている記載からすると，「ＩＫＥ」の「フェーズ２」でも，初めにイニシエータとレスポンダがパラメータの折衝を行い，「パラメータ」の項目に「暗号化アルゴリズム」が含まれることから，「ＩＫＥ」の「フェーズ２」でも，例えば，「ＤＥＳ」，「３ＤＥＳ」，「ＡＥＳ」などからパラメータ折衝により新たに選択された暗号化アルゴリズム（以下，「第２の暗号アルゴリズム」という。）を用いることにより，イニシエータとレスポンダが通信を行うことが読み取れる。
　そうすると，引用例１には，
“パラメータ折衝により新たに選択された第２の暗号化アルゴリズムを用いることにより，ＩＰｓｅｃで通信するときに使用する秘密鍵を生成し，ＩＰｓｅｃ ＳＡを確立するフェーズ２”
が記載されていると解される。
　
エ　上記Ｅの「通信相手の認証方法　フェーズ１では，次の４とおりの方法で通信相手を認証する。　事前共有秘密鍵認証方式（Ｐｒｅ−Ｓｈａｒｅｄ Ｓｅｃｒｅｔ）　セキュリティゲートウェイどうしがあらかじめ取り決めた秘密鍵で認証する。　電子署名認証方式　…（中略）…　公開鍵暗号認証方式　…（中略）…　改良型公開鍵暗号認証方式」との記載からすると，「フェーズ１」での通信相手の認証方法の態様として，セキュリティゲートウェイどうしがあらかじめ取り決めた事前共有秘密鍵で認証する「事前共有秘密鍵認証方式」を読み取ることができる。
　また，上記Ｅの「フェーズ１の擬似乱数発生関数の鍵には，「ＳＫＥＹＩＤ」を使用する。この「ＳＫＥＹＩＤ」の計算式は通信相手の認証方式ごとに異なる。　…（中略）…　「Ｎｉ＿ｂ」はイニシエータのセキュリティゲートウェイ（以下，イニシエータ）が発生した乱数，「Ｎｒ＿ｂ」はレスポンダのセキュリティゲートウェイ（以下，レスポンダ）が発生した乱数を意味し，「｜」が前後のメッセージを連結することを意味する。したがって，事前共有秘密鍵認証方式のＳＫＥＹＩＤの計算式では，事前共有秘密鍵を鍵にして，Ｎｉ＿ｂとＮｒ＿ｂを連結したメッセージに対して擬似乱数発生関数を使用することになる。」との記載からすると，上記の「事前共有秘密鍵認証方式」では，「事前共有秘密鍵」のほか，イニシエータが発生したＮｉ＿ｂやレスポンダが発生したＮｒ＿ｂの「乱数」に基づき「ＳＫＥＹＩＤ」を求めることが読み取れ，さらに，上記Ｅの「また，このようにして求めたＳＫＥＹＩＤを基に，次の３つの暗号鍵を生成する。　ＩＰｓｅｃで通信するときに使用する暗号鍵「ＳＫＥＹＩＤ＿ｄ」の計算式　…（中略）…　フェーズ２（後述）のメッセージ認証に使用する暗号鍵「ＳＫＥＹＩＤ＿ａ」の計算式　ＩＫＥ暗号通信に使用する暗号鍵「ＳＫＥＹＩＤ＿ｄ」の計算式」との記載からすると，求められた「ＳＫＥＹＩＤ」に基づき３つの暗号鍵を生成し，生成された３つの暗号鍵が上記イで認定したフェーズ２の通信を安全に行う「共有秘密鍵」であると言えることから，引用例１には，
“フェーズ１では，セキュリティゲートウェイどうしがあらかじめ取り決めた事前共有秘密鍵で認証し，前記事前共有秘密鍵や乱数に基づきＳＫＥＹＩＤを求め，前記ＳＫＥＹＩＤに基づき，フェーズ２の通信を安全に行う前記共有秘密鍵を生成する”
ことが記載されていると解される。
　
（３）以上，ア乃至エの検討によれば，引用例１には次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「　ネットワーク上でのセキュリティ確保のために，ＩＰｓｅｃのＩＫＥが２つのフェーズを用いてＳＡを確立する方法において，
　パラメータ折衝により選択された第１の暗号化アルゴリズムを用いることにより，ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証し，フェーズ２の通信を安全に行う共有秘密鍵を生成し，ＩＫＥ ＳＡを確立するフェーズ１と，
　パラメータ折衝により新たに選択された第２の暗号化アルゴリズムを用いることにより，ＩＰｓｅｃで通信するときに使用する秘密鍵を生成し，ＩＰｓｅｃ ＳＡを確立するフェーズ２とを具え，
　前記フェーズ１では，セキュリティゲートウェイどうしがあらかじめ取り決めた事前共有秘密鍵で認証し，前記事前共有秘密鍵や乱数に基づきＳＫＥＹＩＤを求め，前記ＳＫＥＹＩＤに基づき，フェーズ２の通信を安全に行う前記共有秘密鍵を生成する方法。」　
　
　
２　引用例２に記載されている技術的事項
　
　本願の優先日前に頒布され，当審からの上記平成２７年６月１０日付け拒絶理由通知において引用された，特表２００３−５２９２４３号公報（平成１５年９月３０日公表，以下，「引用例２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｌ　「　　 【０００９】
　
ＩＰｓｅｃプロトコルは，現代の暗号化方法を利用してプライバシーと認証サービスを提供する，セキュリティ拡張セットである。
　
Ｍ　「　　 【００１３】
　安全なセッションを開始するためには，その前に，通信者間で通信用語を交渉する必要がある。これらの用語は，セキュリティアソシエーション（ＳＡ）によって定義されている。
ＳＡを確立し，インターネットのようなグローバルネットワークでプロセスを実現可能にするために，自動化されたプロトコルが必要である。この自動化されたプロトコルは，インターネット鍵交換（ＩＫＥ）である。ＩＫＥは，ＳＡの確立，交渉，変更，及び削除を目的として作られたものである。それは，ホストのためにランダムな短期間のセッションキーを安全に作成し，共有された秘密（パスワード）を使用するか又は証明書を使用した暗号化によりホストを認証する。
　　 【００１４】
　ＩＫＥ鍵交渉と交換は２つの段階で機能する。第一の段階では，ＩＫＥは，更なる交渉トラフィックのためのセキュアチャネルを確立し，交渉の間使用されるセキュリティアソシエーションを定義する。第二の段階では，ＩＰｓｅｃによって使用されるセキュリティアソシエーションを交渉する。
第一段階には時間がかかるが，結局は，第一段階の交渉が実施された後はより頻繁に実施される第二段階の交渉が速く実施されるので，時間は節約される。
　
３　引用例３に記載されている技術的事項
　
　本願の優先日前に電気通信回線を通じて公衆に利用可能となり，当審からの上記平成２７年６月１０日付け拒絶理由通知において引用された，松島　正明，“IPsecの基本とリモートアクセスへの応用”，Internet Week 2003 チュートリアルプレゼンテーション資料，p.16-30，[online]，２００３年１２月，
[平成２７年６月１日検索]，インターネット＜URL:https://www.nic.ad.jp/ja/materials/iw/2003/proceedings/T10-1.pdf＞（以下，「引用例３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｎ　「ＩＫＥ　Ｐｈａｓｅ１ネゴシエーションの詳細　
　パラメータ折衝（Ｐｒｅ−Ｓｈａｒｅｄ　Ｋｅｙ）
　　　　　　　　　　ＩＫＥ ＳＡを確立するために
　　　　　　　　　　使用するパラメータを提案
Ｉｎｉｔｉａｔｏｒ　　　　−−−−−→　　　　Ｒｅｓｐｏｎｄｅｒ
　　　　　　　　　　　　（複数提案可能）
　＜
◆暗号アルゴリズム：３ＤＥＳ
　＜
◆暗号アルゴリズム：ＤＥＳ
　
　　　　　　受入れたパラメータを回答
　　　　　　　←−−−−−　＜
◆暗号アルゴリズム：ＤＥＳ
　　　　　　（複数回答不可）　　　　　　　　　　　　　」（第２２−第２３頁）
　
Ｐ　「ＩＫＥ　Ｐｈａｓｅ２ネゴシエーションの詳細　
　パラメータ提案　
　　　　　　　　　　ＩＫＥ　ＳＡによって暗号化　
Ｉｎｉｔｉａｔｏｒ　　−−−−−−−−−−　　　Ｒｅｓｐｏｎｄｅｒ
　　
認証済み鍵素材
　　　
ＳＫＥＹＩＤ＿ｄ
　　　
ＳＫＥＹＩＤ＿ａ
　　　
ＳＫＥＹＩＤ＿ｅ
　　…（中略）…　
　　　　　　　　　　　　　　　　　　ＩＰｓｅｃ ＳＡを確立するために
＜
◆暗号アルゴリズム：３ＤＥＳ
　　　　　　　　　　　　　　　　　　　　　−−−−−−−−−−−→
＜
◆暗号アルゴリズム：ＤＥＳ
　
パラメータ選択
　　　　　　　　　　ＩＫＥ　ＳＡによって暗号化　
Ｉｎｉｔｉａｔｏｒ　−−−−−−−−−−−−　　　Ｒｅｓｐｏｎｄｅｒ
　　　　　　　　　　　　　　　　　　　　　　　　　　…（中略）…
　　　　受入れたパラメータを回答
　　　　　←−−−−−−−　＜
◆暗号アルゴリズム：ＤＥＳ
」（第２７頁−第２９頁）
　
　
第４　対比
　
１　本願発明と引用発明とを対比する。
　
（１）引用発明は「ネットワーク上でのセキュリティ確保のために，ＩＰｓｅｃのＩＫＥが２つのフェーズを用いてＳＡを確立する方法」であるところ，引用例１の上記Ｆの「フェーズ１では「パラメータ折衝」「鍵情報の交換」「認証」の順に作業する。」との記載，上記Ｊの「フェーズ２では，クイックモードで「パラメータ折衝」「認証確認」の手順を経て，ＩＰｓｅｃ ＳＡを確立する。」との記載からみて，「ＩＰｓｅｃ」の「ＩＫＥ」による「ＳＡ」の確立は安全なデータ伝送のための「認証」を含むと解されることから，引用発明と本願発明とは，“安全なデータ伝送の為の認証方法”という点で一致すると言える。
　
（２）引用発明では，２つのフェーズを用いてＳＡを確立し，「パラメータ折衝により選択された第１の暗号化アルゴリズムを用いることにより，ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証し，フェーズ２の通信を安全に行う共有秘密鍵を生成し，ＩＫＥ ＳＡを確立するフェーズ１」を具えるところ，「フェーズ１」は「プロセッサ」により実行されることは明らかであり，第１の暗号化アルゴリズムを用いて，ＳＡを確立する相手の認証を含む「フェーズ１」をはじめに実行することから，引用発明の「フェーズ１」は本願発明の「第１の認証プロトコルを実行するステップ」に相当すると言える。
　また，本願発明では，「第１の暗号を用いることにより第１の認証プロトコルを実行する」ことから，引用発明の「第１の暗号化アルゴリズム」は本願発明の「第１の暗号」に相当すると言える。
　そうすると，引用発明の「パラメータ折衝により選択された第１の暗号化アルゴリズムを用いることにより，ＳＡを確立する相手がインターネットＶＰＮで通信する正当な相手かどうかを認証し，フェーズ２の通信を安全に行う共有秘密鍵を生成し，ＩＫＥ ＳＡを確立するフェーズ１」は本願発明の「プロセッサが，第１の暗号を用いることにより第１の認証プロトコルを実行するステップ」に相当すると言える。
　
（３）引用発明では，ＳＡの確立のために，「フェーズ１」の後に実行される「パラメータ折衝により新たに選択された第２の暗号化アルゴリズムを用いることにより，ＩＰｓｅｃで通信するときに使用する秘密鍵を生成し，ＩＰｓｅｃ ＳＡを確立するフェーズ２」を具えるところ，「フェーズ２」も「プロセッサ」により実行されることは明らかであり，引用例１の上記Ｊの「フェーズ２では，クイックモードで「パラメータ折衝」「認証確認」の手順を経て，ＩＰｓｅｃ ＳＡを確立する。」との記載からみて，第２の暗号化アルゴリズムを用いて，ＳＡを確立するための認証を含む「フェーズ２」を実行することから，引用発明の「フェーズ２」は本願発明の「第２の認証プロトコルを実行するステップ」に相当すると言える。
　また，本願発明では，「第２の暗号を用いることにより第２の認証プロトコルを実行する」ことから，引用発明の「第２の暗号化アルゴリズム」は本願発明の「第２の暗号」に相当すると言える。
　そうすると，引用発明の「パラメータ折衝により新たに選択された第２の暗号化アルゴリズムを用いることにより，ＩＰｓｅｃで通信するときに使用する秘密鍵を生成し，ＩＰｓｅｃ ＳＡを確立するフェーズ２」は本願発明の「プロセッサが，第２の暗号を用いることにより第２の認証プロトコルを実行するステップ」に相当すると言える。
　
（４）引用発明では，「フェーズ１では，セキュリティゲートウェイどうしがあらかじめ取り決めた事前共有秘密鍵で認証し，前記事前共有秘密鍵や乱数に基づきＳＫＥＹＩＤを求め」るところ，「フェーズ１」が「第１の暗号化アルゴリズム」を用いて「プロセッサ」により実行されることは明らかであり，「ＳＫＥＹＩＤ」は，「事前共有秘密鍵」や「乱数」を入力として「第１の暗号化アルゴリズム」により出力されるとみることができる。
　そうすると，引用発明の「事前共有秘密鍵」，「乱数」，「ＳＫＥＹＩＤ」は，本願発明の「共有キー」，「乱数」，「第１のシード」に相当すると言えることから，引用発明における「フェーズ１では，セキュリティゲートウェイどうしがあらかじめ取り決めた事前共有秘密鍵で認証し，前記事前共有秘密鍵や乱数に基づきＳＫＥＹＩＤを求め」ることは，本願発明の「前記プロセッサが，共有キー及び乱数を入力として前記第１の暗号により第１のシードを出力するステップ」に相当すると言える。
　
（５）引用発明では，「フェーズ１」において，「前記ＳＫＥＹＩＤに基づき，フェーズ２の通信を安全に行う前記共有秘密鍵を生成する」ところ，「フェーズ１」は「ＳＫＥＹＩＤ」に基づいて「共有秘密鍵」を発生させるステップとみることができ，また，上記（４）の検討から，引用発明における「ＳＫＥＹＩＤ」は本願発明の「第１のシード」に相当すると言える。
　そして，引用発明では，「共有秘密鍵」は「フェーズ２の通信を安全に行う」ためのものであることから，引用発明の「共有秘密鍵」と本願発明の「第１のセッションキー」とは，「第２の認証プロトコル」を実行させるための“第１のキー”である点で共通すると言える。
　そうすると，引用発明における「前記ＳＫＥＹＩＤに基づき，フェーズ２の通信を安全に行う前記共有秘密鍵を生成する」ことと，本願発明における「前記第２の認証プロトコルに対する入力を前記第１のセッションキー」とし，「前記プロセッサが，前記第１のシードに基づいて第１のセッションキーを発生させるステップ」とは，後記する点で相違するものの，“前記プロセッサが，前記第１のシードに基づいて，第１のキーを発生させるステップ”であって，“前記第２の認証プロトコルを実行させるための前記第１のキーとする”点で共通すると言える。
　
２　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞ 
　
「　安全なデータ伝送の為の認証方法において，この認証方法が，
　プロセッサが，第１の暗号を用いることにより第１の認証プロトコルを実行するステップと，
　前記プロセッサが，第２の暗号を用いることにより第２の認証プロトコルを実行するステップとを具え，
　前記プロセッサが，共有キー及び乱数を入力として前記第１の暗号により第１のシードを出力するステップと，
　前記プロセッサが，前記第１のシードに基づいて，第１のキーを発生させるステップとを具え，
　前記第２の認証プロトコルを実行させるための前記第１のキーとする認証方法。」　
　
＜相違点１＞
　
　第１の暗号と第２の暗号との関係に関し，本願発明では，「第１の暗号を，前記第２の暗号よりも安全性の高い暗号とし，前記第２の暗号を，前記第１の暗号よりも安全性の低く，かつ前記第１の暗号よりもデータ通信を高速にする暗号とし」ているのに対して，引用発明では，「第１の暗号化アルゴリズム」と「第２の暗号化アルゴリズム」との関係については特定されていない点。
　
＜相違点２＞
　
　第２の認証プロトコルを実行させるための第１のキーに関し，本願発明では，「第２の認証プロトコルに対する入力」となる「第１のセッションキー」であるのに対して，引用発明では，「第２の認証プロトコル」（フェーズ２）の通信を安全に行う「共有秘密鍵」である点。　
　
　
第５　当審の判断
　
　上記相違点１，２について検討する。
　
１　相違点１について
　
　引用例１（４６，４７，４９頁の図１２，１６，表３，４）の記載からすると，引用発明において，フェーズ１で用いる第１の暗号化アルゴリズムと，フェーズ２で用いる第２の暗号化アルゴリズムはそれぞれ，イニシエータとレスポンダとの折衝により決定されるパラメータの１つであって，ＤＥＳ，３ＤＥＳ，ＡＥＳなどからその都度別々に選択可能であったと解される。ＩＰｓｅｃのＩＫＥにおいて，フェーズ１で用いる暗号化アルゴリズムと，フェーズ２で用いる暗号化アルゴリズムとが，イニシエータとレスポンダとの折衝により決定されるパラメータの１つであることは，例えば引用例３（上記Ｎ，Ｐを参照）に記載されるように当該技術分野における周知の技術的事項である。
　また，引用例２（上記Ｌ，Ｍを参照）に記載されるように，ＩＰｓｅｃのＩＫＥ鍵交渉においては，第一段階は時間がかかるが，第一段階の交渉が実施された後により頻繁に実施される第二段階の交渉は速く実施されることは，本願の優先日前には当該技術分野における周知の技術であり，第一段階の交渉，第二段階の交渉それぞれで使用される暗号化アルゴリズムがそれぞれの交渉の速さ，すなわちデータ通信の速さに影響を与えることは自明である。
　そうすると，引用発明において，引用例２に記載される上記周知技術を適用し，フェーズ２をフェーズ１よりも速く実行するために，フェーズ１，フェーズ２それぞれについて別々の暗号化アルゴリズムを選択して，適宜，第１の暗号化アルゴリズムを，第２の暗号化アルゴリズムよりも安全性の高い暗号とし，前記第２の暗号化アルゴリズムを，前記第１の暗号化アルゴリズムよりも安全性の低く，かつ前記第１の暗号化アルゴリズムよりもデータ通信を高速にする暗号とすること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
２　相違点２について
　
　引用発明では，「ＳＫＥＹＩＤ」に基づき「共有秘密鍵」を生成するところ，引用例１（上記Ｅ，図１３を参照）の記載からすると，フェーズ１において，「ＳＫＥＹＩＤ」を基に，３つの暗号鍵［ＳＫＥＹＩＤ＿ｄ］，［ＳＫＥＹＩＤ＿ａ］，［ＳＫＥＹＩＤ＿ｅ］を生成し，ＩＫＥ暗号通信やフェーズ２のメッセージ認証において使用されることが読み取れる。
　また，引用例３（上記Ｐ）に記載されるように，ＩＰｓｅｃのＩＫＥのフェーズ２において，フェーズ１で「ＳＫＥＹＩＤ」を基に生成された３つの鍵素材［ＳＫＥＹＩＤ＿ｄ］，［ＳＫＥＹＩＤ＿ａ］，［ＳＫＥＹＩＤ＿ｅ］を使用することは，本願の優先日前には当該技術分野における周知技術であった。
　そうすると，引用発明において，第１の認証プロトコル（フェーズ１）で，第１のシード（ＳＫＥＹＩＤ）を求めることに加えて，該第１のシードに基づいて第２の認証プロトコル（フェーズ２）に対する入力となる第１のセッションキーを生成すること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　
３　小括
　
　上記で検討したごとく，相違点１，２に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　
第６　むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。