【事件の表示】
　特願２０１１−５０３９６９「認証および鍵一致（ＡＫＡ）機構に基づくＫｅｒｂｅｒｏｓ対応アプリケーションへの認証されたユーザアクセスのための方法および装置」拒絶査定不服審判事件〔平成２１年１０月１５日国際公開、ＷＯ２００９／１２６２１０、平成２３年　９月　１日国内公表、特表２０１１−５２４６５２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，２００９年３月２６日（パリ条約による優先権主張外国庁受理２００８年４月１０日，米国）を国際出願日とする出願であって，平成２４年１１月２６日付けの拒絶理由通知に対して，平成２５年５月３０日に意見書と手続補正書が提出されたが，同年６月１７日付けで拒絶査定がなされ，これに対して，同年１０月２４日に拒絶査定不服審判の請求がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２５年５月３０日に提出された手続補正書により補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
　
「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションに対してユーザを認証するための方法であって，
　前記ユーザおよび１つまたは複数のサーバを相互に認証するブートストラッププロトコルに基づく認証および鍵一致機構を使用して前記ユーザを認証するステップを備え，前記ブートストラッププロトコルは汎用ブートストラップアーキテクチャに基づいており，チケットがチケット交付サーバへ発行され，さらに，前記方法は，
　前記ユーザを認証すると，前記ユーザがセッション鍵を導出することを可能にするステップであって，前記チケット交付サーバが，１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションを提供する１つまたは複数のアプリケーションサーバへのチケットを提供する，ステップとを備える，方法。」
　
３．引用例
（１）引用例１
　原査定の拒絶理由通知で引用された「国際公開第２００７／０８５１７５号」（以下「引用例１」という。）には，図面とともに以下の事項が記載されている。
　なお，上記引用例１として公開された国際出願の対応する日本国公表特許公報である特表２００９−５２４３６９号公報の対応箇所の記載を当審の仮訳とした。
　
（ア）「
」（第１頁２行〜１６行）
（当審仮訳：
技術分野
　本発明は，ネットワーク通信サービス技法に関し，具体的には，
モバイルネットワークに基づくエンドツーエンド通信での認証の方法
　
背景技術
　現在，サービスをモバイル加入者に提供する時に，アプリケーションサーバの大多数は，まず，モバイル加入者と認証プロキシとの間，モバイル加入者と公開鍵基盤(PKI)証明機関との間，モバイル加入者とコンテンツ提供サーバとの間など，相互信頼関係をモバイル加入者と共に確立する。一般に，そのような信頼関係は，モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。
　3G無線通信標準規格では，GAA(Generic Authentication Architecture)が，加入者識別情報を検証するためにさまざまなアプリケーションサービスエンティティによって使用される一般的アーキテクチャであり，アプリケーションサービス加入者をチェックし，加入者識別情報を検証することができる。上記アプリケーションサービスは，マルチキャスト/ブロードキャストサービス，ユーザ証明書サービス，瞬時情報を提供するサービス，またはプロキシサービスとすることができる。）
（イ）「
」（第１頁１７行〜第２頁１５行）
（当審仮訳：
図1は，GAAのアーキテクチャを示す概略図であり，このGAAは，一般に，加入者101，加入者識別情報の初期チェックおよび検証を実行するBSF(Bootstrapping Server Function) 102，HSS(Home Subscriber Server) 103，およびNAF(Network Application Function) 104を含む。BSF 102は，加入者101との相互識別情報検証を実行し，BSF 102および加入者101の共有鍵を生成するように働く
　サービスを使用することを望む時に，加入者は，サービスがBSFを用いる相互認証手順を必要とする場合に，相互認証のために直接にBSFと通信する。そうでない場合には，加入者は，まずサービスに対応するNAFに連絡し，NAFがGAAを使用するがサービスを要求する加入者が相互認証手順のためにBSFと通信してはいない場合には，NAFは，サービスを要求する加入者に，BSFとの識別情報検証を実行するように通知する。
　相互認証が成功した時に，加入者およびBSFは，互いの識別情報を認証し，共有鍵Ksを生成する。さらに，BSFは，Ksの更新を容易にするために，Ksの寿命を定義する。後に，BSFは，加入者のB-TID(Bootstrapping Transaction Identifier)を割り振り，そのB-TIDをKsの寿命と共にユーザ機器(UE)に転送し，ここで，B-TIDが，Ksに関連付けられる。共有鍵Ksは，ルート鍵として使用されるが，加入者のUEおよびBSFから出ない。加入者がNAFと通信する時には，Ksから導出された鍵Ks_NAFが，通信を保護するのに使用される。
　GAAの不利益は，1. 1つの認証機構(すなわちAKA認証機構)だけが，加入者とBSFとの間の認証でサポートされることと，2. 認証機構が，BSFとNAFとの間の認証を提供せず，これが，NAFを偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性があることである。）
（ウ）「
」（第６頁１１行〜１７行）
（当審仮訳：本発明の実施形態による技術的解決策によってもたらされる有益な効果は，真の包括的認証アーキテクチャが提供されることであり，ここで，GAAによって提供される認証機構は，複数の認証機構および認証モジュールに関するネゴシエーションおよび選択を実行することができ，これは，認証機構の柔軟性および一般性を高める。
本発明の実施形態によるフレームワークでは，サービスプロバイダを，モバイルネットワーク内のアプリケーションサーバ
とすることができ，
（エ）「
」（第９頁１６行〜第１１頁２行）
（当審仮訳：
本発明の実施形態によって提供される認証手順は，次のステージを含む
　
第1ステージ(エンティティ認証プロセスと称する):サービスエンティティは，ネットワーク内の各SSがSPと通信する前に，まず，EACに行って，認証機構をネゴシエートし，サービスエンティティの識別情報を認証しなければならない
　認証機構をネゴシエートするプロセスは，サービスエンティティによって開始され，サービスエンティティの識別情報およびサービスのセキュリティ度合要件が，ネゴシエーションを開始するために要求メッセージ内で伝えられる。EACは，セキュリティ度合，ネットワークサポート条件(たとえば，ネットワークがサポートした認証モード)，およびエンティティサブスクリプション情報に従って認証機構を選択し，認証リクエスタとして振る舞うサービスエンティティに対応する情報を返す。サービスの異なるセキュリティ度合は，異なる認証モードが選択されることにつながる。認証リクエスタは，ネゴシエーション手順の終りを示すために確認メッセージを発行する。
　サービスエンティティおよびEACは，ネゴシエートされた機構に従って，それらの間で相互認証を実行する。この認証は，双方向である。認証の後に，認証リクエスタ(すなわち，認証を要求するサービスエンティティ)およびEACは，共有鍵材料を生成し，EACは，認証リクエスタに，そのサブスクリプション情報に従って一時IDおよび対応する寿命を割り振る。認証リクエスタがSSである場合には，EACは，ISR-ID(Interim Service Request Identifier)を認証リクエスタに割り振り，認証リクエスタがSPである場合には，EACは，IAC-ID(Interim Authentication Check Identifier)を認証リクエスタに割り振る。EACは，サービスエンティティの一時IDおよび寿命を，認証を要求するサービスエンティティに転送する。この後に，認証を要求するサービスエンティティとEACとの間の通信を，そのサービスエンティティとEACとの間の認証手順で生成された共有鍵材料を使用することによって保護することができる。
　
第2ステージ(認証問合せプロセスと称する):EACとの認証を実行した後に，SSは，SPにサービスを要求することができる
　サービス要求を受信した時に，SPまたはSSPがEACとの認証を実行し，有効なIAC-IDを獲得済みであるならば，SPまたはSSPは，SSの認証条件についてEACに問い合わせることができる。そうでない場合には，SPまたはSSPは，まずEACと通信して認証および鍵ネゴシエーションを実行しなければならず，その後，SSのISR-IDおよびSPまたはSSPのIAC-IDを伝える問合せ要求を送信することによって，SSの認証条件についてEACに問い合わせなければならない。問合せ要求を受信した時に，EACは，まず，SSおよびSPがSSのIDおよびSPのIDに従って権限を有するかどうかを問い合わせ，次に，SSおよびSPの一時IDとSS/SPによってEACとネゴシエートされたKsとを使用することによってSSとSPとの間のサービス通信を保護する派生鍵を計算し，その派生鍵をSPに転送する。その間に，SSは，同一のパラメータおよびアルゴリズムに従って派生鍵を計算する。サービスエンティティとEACとの間で確立される信頼関係は，寿命を有する。この寿命が，満了しようとしているかまたは満了済みである場合には，サービスエンティティは，新しい信頼関係を確立するために，EACとの再認証手順を必要とする。
　
第3ステージ(サービスエンティティ間の相互認証プロセスと称する):共有される派生鍵を獲得した後に，SSおよびSPは，その派生鍵を使用して，各サービス通信の前にこの2つの当事者間で相互認証を実行し，通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成し，その後，そのセッション鍵を使用してサービス通信を保護することができる
（オ）「
」（第１１頁３行〜第１３頁１行）
（当審仮訳：
本発明の実施形態によって提供される認証手順の各ステージを，これより，添付の図面を参照して詳細に説明する
　
図4は，本発明による実施形態での，サービスエンティティとEACとの間で認証機構をネゴシエートし，相互認証を実行するプロセスを示す流れ図である。この実施形態では，サービスエンティティとEACとの間で認証機構をネゴシエートし，相互認証を実行するプロセスは，図4に示されているようにサービスエンティティによって開始され，次のステップを含む
　
ブロック401:サービスエンティティは，要求されたサービスまたは提供されるサービス(たとえば，ビデオ会議サービス)に対応する認証機構のセキュリティ度合要件(たとえば，高セキュリティ度合)を自動的に選択する
　
ブロック402:サービスエンティティが，サービスエンティティのID，サービスエンティティによって選択された認証機構のセキュリティ度合などの関連情報を伝える認証要求をEACに転送する
　
ブロック403:認証要求を受信した時に，EACは，ローカルに格納されたセキュリティ度合リストを検索して，ネットワークによって現在サポートされ，認証プロトコルおよび暗号化アルゴリズムを含むセキュリティ度合要件を満足する少なくとも1つの認証機構を見つける。たとえば，Http AKAは，ネットワークと無線ネットワーク内の端末との間の相互認証プロトコルである。このプロトコルを実行することによって，2つの通信当事者は，互いの識別情報を認証し，同一の鍵をそれぞれ生成することができる
　
ブロック404:サービスエンティティの識別情報に従って，EACは，ESDに格納されたサブスクリプション情報を問い合わせ，サービスエンティティの認証情報，たとえば，認証プロトコル，暗号化アルゴリズム，および他の関連パラメータを含む，サービスエンティティによってサポートされる認証機構を得る
　
ブロック405:ESDは，サービスエンティティの認証機能情報(たとえば，サポートされる認証プロトコル，暗号化アルゴリズムなど)および他の関連パラメータをEACに返す
　
ブロック406:EACは，ローカルポリシに従って，サービスエンティティおよびネットワークによってサポートされる認証プロトコルおよび暗号化アルゴリズムを照合し，やはりセキュリティ度合要件に従って，両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズム(すなわち，認証機構)を判定する
　
ブロック407:EACは，認証プロトコルおよび暗号化アルゴリズムを含む選択された認証機構をサービスエンティティに返す
　
ブロック408:EACによって返された情報を受信した時に，サービスエンティティは，認証機構を判断し，確認応答をEACに返す
　
ブロック409:サービスエンティティおよびEACは，選択された認証プロトコルおよび暗号化アルゴリズムを使用して，相互認証を実行する
　サービスエンティティがモバイル端末である場合には，共有鍵材料を，共有鍵(Ks)とすることができる。サービスエンティティがモバイルコアネットワークドメイン内のアプリケーションサーバ(AS)である場合には，サービスエンティティとEACとの間の相互認証手順でネゴシエートされる共有鍵材料を，SA(Security Association)すなわち，インターネットプロトコルセキュリティ(IPSec)に従ってネゴシエートされるセキュリティ通信の鍵および鍵アルゴリズム情報とすることができる。
　
ブロック410:EACは，認証成功応答をサービスエンティティに返し，サービスエンティティの一時IDおよび対応する寿命を割り振る
　
ブロック411:EACおよびサービスエンティティは，それぞれ，対応するセキュリティ度合に関連する共有鍵材料を格納する
（カ）「
」（第１３頁２行〜４行）
（当審仮訳：図5は，本発明による実施形態での，サービスエンティティとEACとの間での認証問合せ手順を示す流れ図である。
この実施形態では，相互認証を実行した後に，サービスエンティティおよびEACは，認証問合せ手順を実行する
（キ）「
」（第１６頁２３行〜第１８頁１６行）
（当審仮訳：
エンティティ認証センタ(EAC)が，Kerberosサーバの機能を有する場合には，Kerberosモデルと組み合わされた認証問合せの機構を使用することができる。図6は，Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である
許可チケットに従って派生鍵を生成し，その後，SSにサービス応答を返す。
　
図7は，図6に示された，Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である
ブロック701:あるサービスを獲得することを望む時に，SSは，まず，そのサービスに対応するサービス許可チケットがローカルに格納されているかどうかを検索する
格納されている場合には，ブロック705に進む。格納されていない場合には，SSは，SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送する
　
ブロック702:サービス許可チケット要求を受信した時に，EACは，識別情報の妥当性および権限をチェックする
まず，EACは，要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって，SSがそのサービスを使用する資格を与えられているかどうかを判断し，次に，要求内で伝えられたSPのUIDに従ってSPのIAC-IDを獲得し，IAC-IDが有効であるかどうかを判断することによって，SPがそのサービスを提供する資格を与えられているかどうかを判断する
上記の判断が，SPがそのサービスを提供する資格を与えられている(すなわち，SPが正当である)ことを示す場合には，EACは，SSおよびSPの識別情報とSSおよびEACの共有鍵材料とに従って，SSとSPとの間のサービス通信を保護するための派生鍵K-SSP/SPを計算する。EACは，さらに，その派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し，それ自体およびSPの共有鍵材料を使用して，そのSGTを暗号化する
　上記の判断が，SPがそのサービスを提供する資格を与えられていない(すなわち，SPが不正である)ことを示す場合には，EACは，エラーメッセージを転送し，EACでその識別情報を認証することについて，対応するエンティティに通知し，現在の手順を打ち切る。
　
ブロック703:EACは，上記で暗号化されたSGTをSSに転送する
　
ブロック704:SGTを受信した時に，SSは，EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって，EACが生成したものと同一の派生鍵をローカルに生成する
　
ブロック705:SSは，SGTを伝えるサービス要求をSPに転送する
　
ブロック706:SPは，SGTを暗号化解除して，派生鍵を獲得する
ブロック707:SPは，成功を識別するサービス要求応答をSSに返す
　
ブロック708:SSおよびSPは，派生鍵を使用して，それらの間でサービスを保護する
　上記のブロック以外に，EACは，それ自体およびSSの共有鍵材料を使用して，派生鍵を暗号化し，暗号化された派生鍵をSSに転送することができる。したがって，SSは，ローカルに再計算するのではなく暗号化解除によって派生鍵を獲得することができる。
　同様に，
共有される派生鍵を獲得した後に，SSおよびSPは，その派生鍵を使用して，各サービス通信が始まる前にこの2つの当事者の間で相互認証を実行することができ，さらに，その通信のセキュリティを保護するセッション鍵Kr-SS-SPを生成し，その後，このセッション鍵を使用してサービス通信を保護する
　ここで，上記引用例１に記載されている事項を検討する。
　
（ａ）上記摘記事項（エ）の記載によれば，引用例１の発明の実施形態によって提供される認証手順は，エンティティ認証プロセスと称する第1ステージ（ここでは，サービスエンティティが，EACに行って，認証機構をネゴシエートし，サービスエンティティおよびEACは，ネゴシエートされた機構に従って，それらの間で相互認証を実行する。）と，認証問合せプロセスと称する第2ステージと，サービスエンティティ間の相互認証プロセスと称する第3ステージ（ここでは，SSおよびSPが，その派生鍵を使用して相互認証を実行し，通信のセキュリティを保護するためのセッション鍵Kr-SS-SPを生成する。）とを含むものである。
　
（ｂ）上記摘記事項（オ）の「図4は，本発明による実施形態での，サービスエンティティとEACとの間で認証機構をネゴシエートし，相互認証を実行するプロセスを示す流れ図である。」との記載からみて，図4は，上記摘記事項（エ）の第1ステージに対応するプロセスである。
　
（ｃ）上記摘記事項（カ）によれば，サービスエンティティおよびEACは，「相互認証を実行した後に，認証問合せ手順を実行する」ものである。
（ｄ）上記摘記事項（キ）によれば，エンティティ認証センタ(EAC)が，Kerberosサーバの機能を有する場合には，Kerberosモデルと組み合わされた認証問合せの機構を使用することができ，図6は，Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図であり，また，図7は，図6に示された，Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である。
　してみれば，図6，図7は，上記摘記事項（エ）の第2ステージに対応するプロセスであると認められる。
（ｅ）図7のブロック705の記載によれば，ブロック705において，SSは，「SGTを含むサービス要求をspに転送」しているものである。
　以上の点を踏まえ，上記摘記事項（ア）〜（キ）の記載及び図面の記載を総合すると，引用例１には，次のとおりの発明（以下，「引用発明」という。）が記載されていると認められる。
　
「モバイルネットワークに基づくエンドツーエンド通信での認証の方法であって，
　認証手順は，
　エンティティ認証プロセスと称する第1ステージと，認証問合せプロセスと称する第2ステージと，サービスエンティティ間の相互認証プロセスと称する第3ステージとを含み，
　第1ステージでは，
　サービスエンティティが，EACに行って，サービスエンティティの識別情報を認証するために，
　サービスエンティティは，要求されたサービスまたは提供されるサービスに対応する認証機構のセキュリティ度合要件を自動的に選択し（ブロック401），
　サービスエンティティが，サービスエンティティのID，サービスエンティティによって選択された認証機構のセキュリティ度合などの関連情報を伝える認証要求をEACに転送し（ブロック402），
　認証要求を受信した時に，EACは，ローカルに格納されたセキュリティ度合リストを検索して，ネットワークによって現在サポートされ，認証プロトコルおよび暗号化アルゴリズムを含むセキュリティ度合要件を満足する少なくとも1つの認証機構を見つけ，たとえば，Http AKAは，ネットワークと無線ネットワーク内の端末との間の相互認証プロトコルであり，このプロトコルを実行することによって，2つの通信当事者は，互いの識別情報を認証し，同一の鍵をそれぞれ生成することができるものであり（ブロック403），
　サービスエンティティの識別情報に従って，EACは，ESDに格納されたサブスクリプション情報を問い合わせ，サービスエンティティの認証情報，たとえば，認証プロトコル，暗号化アルゴリズム，および他の関連パラメータを含む，サービスエンティティによってサポートされる認証機構を得（ブロック404），
　ESDは，サービスエンティティの認証機能情報および他の関連パラメータをEACに返し（ブロック405），
　EACは，ローカルポリシに従って，サービスエンティティおよびネットワークによってサポートされる認証プロトコルおよび暗号化アルゴリズムを照合し，やはりセキュリティ度合要件に従って，両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズムを判定し（ブロック406），
　EACは，認証プロトコルおよび暗号化アルゴリズムを含む選択された認証機構をサービスエンティティに返し（ブロック407），
　EACによって返された情報を受信した時に，サービスエンティティは，認証機構を判断し，確認応答をEACに返し（ブロック408），
　サービスエンティティおよびEACは，選択された認証プロトコルおよび暗号化アルゴリズムを使用して，相互認証を実行し（ブロック409），
　EACは，認証成功応答をサービスエンティティに返し，サービスエンティティの一時IDおよび対応する寿命を割り振り（ブロック410），
　ここで，:1) 認証要求をEACに発行するサービスエンティティがサービス加入者(SS/SSP)である場合に，EACは，SS/SSPが他のエンティティにサービスを要求する場合に使用されるISR-IDをSS/SSPに割り振り，2) 認証要求をEACに発行するサービスエンティティがサービスプロバイダ(SP/SSP)である場合に，EACは，SS/SSPがSSの認証条件についてEACに問い合わせる必要がある場合に使用されるIAC-IDをSS/SSPに割り振るものであり，
　EACおよびサービスエンティティは，それぞれ，対応するセキュリティ度合に関連する共有鍵材料を格納し（ブロック411），
　第2ステージでは，
　エンティティ認証センタ(EAC)が，Kerberosサーバの機能を有する場合には，Kerberosモデルと組み合わされた認証問合せの機構を使用することができ，
　あるサービスを獲得することを望む時に，SSは，まず，そのサービスに対応するサービス許可チケットがローカルに格納されているかどうかを検索し，格納されている場合には，ブロック705に進み，格納されていない場合には，SSは，SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送し（ブロック701），
　サービス許可チケット要求を受信した時に，まず，EACは，要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって，SSがそのサービスを使用する資格を与えられているかどうかを判断し，次に，要求内で伝えられたSPのUIDに従ってSPのIAC-IDを獲得し，IAC-IDが有効であるかどうかを判断することによって，SPがそのサービスを提供する資格を与えられているかどうかを判断し（ブロック702），
　上記の判断が，SPがそのサービスを提供する資格を与えられている(すなわち，SPが正当である)ことを示す場合には，EACは，SSおよびSPの識別情報とSSおよびEACの共有鍵材料とに従って，SSとSPとの間のサービス通信を保護するための派生鍵K-SSP/SPを計算し，EACは，さらに，その派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し，それ自体およびSPの共有鍵材料を使用して，そのSGTを暗号化し，
　EACは，上記で暗号化されたSGTをSSに転送し（ブロック703），
　SGTを受信した時に，SSは，EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって，EACが生成したものと同一の派生鍵をローカルに生成し（ブロック704），
　SSは，SGTを含むサービス要求をSPに転送し（ブロック705），
　SPは，SGTを暗号化解除して，派生鍵を獲得し（ブロック706），
　SPは，成功を識別するサービス要求応答をSSに返し（ブロック707），
　SSおよびSPは，派生鍵を使用して，それらの間でサービスを保護し（ブロック708），
　第3ステージでは，
　共有される派生鍵を獲得した後に，SSおよびSPは，その派生鍵を使用して，各サービス通信の前にこの2つの当事者間で相互認証を実行し，通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成し，その後，そのセッション鍵を使用してサービス通信を保護することができ，
　サービスプロバイダは，モバイルネットワーク内のアプリケーションサーバとすることができる，
　方法。」
　
４．対比
　本願発明と，引用発明とを比較する。
　
（ａ）
（ａ−１）引用発明のサービスプロバイダ（SP）は，「モバイルネットワーク内のアプリケーションサーバとすることができ」るものであるから，引用発明のサービスプロバイダ（SP）は，所定のサービスを提供するために，当該サービスに対応した「アプリケーション」を有しているということができる。
　引用発明の第2ステージでは，ブロック705において，「Kerberosモデルと組み合わされた認証問合せの機構を使用」して，「SSが，SGT（サービス許可チケット）を含むサービス要求をSPに転送」すると，SPは，「SGTを暗号化解除して，派生鍵を獲得し（ブロック706）」たり，「成功を識別するサービス要求応答をSSに返し（ブロック707）」たりしているから，引用発明のサービスプロバイダ（SP）は，「Kerberos」に「対応」したものといえる。
　そうすると，引用発明の「サービスプロバイダ（SP）」が有する「アプリケーション」は，「Kerberosに対応したKerberos対応アプリケーション」であるといえるから，引用発明と本願発明とは，「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーション」を有する点で共通する。
（ａ−２）引用発明の「サービス加入者(SS)」は，「サービスを獲得することを望む」主体であることから，本願発明の「ユーザ」に相当する。
　引用発明では，「あるサービスを獲得することを望む時に」，「SSが，SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送」すると，「EACは，要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって，SSがそのサービスを使用する資格を与えられているかどうかを判断し」ている。ここで，「SSがそのサービスを使用する資格を与えられているかどうかを判断すること」は，すなわち，「SS（ユーザ）がそのサービス（を提供するためのアプリケーション）を使用する資格を与えられているかどうかを判断（認証）すること」である。
　してみれば，引用発明の「SSがそのサービスを使用する資格を与えられているかどうかを判断すること」が本願発明の「アプリケーションに対してユーザを認証する」ことに相当する。
（ａ−３）上記（ａ−１），（ａ−２）の検討から，引用発明と本願発明とは，「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションに対してユーザを認証するための方法」である点で共通している。
　
（ｂ）
（ｂ−１）引用発明では，「サービスエンティティおよびEACは，選択された認証プロトコルおよび暗号化アルゴリズムを使用して，相互認証を実行し（ブロック409）」ている。
　ここで，引用発明の「サービスエンティティ」は，「サービス加入者（SS）」を含む概念であるから，引用発明の「サービスエンティティ」が本願発明の「ユーザ」に相当する。　また，引用発明は，「エンティティ認証センタ(EAC)が，Kerberosサーバの機能を有する場合」の発明であるから，引用発明の「EAC」が本願発明の「サーバ」に相当する。
　してみれば，引用発明と本願発明とは，「ユーザおよび１つまたは複数のサーバを相互に認証する」ものである点で共通している。
（ｂ−２）引用発明では，「相互認証プロトコル」として，「Http AKA」を実行するものである。ここで，「AKA」とは，「
Ａ
Ｋ
Ａ
　そして，引用発明では，相互認証プロトコルとして，「Http AKA（認証および鍵一致機構）」を「使用して」，「サービスエンティティ（ユーザ）」を「認証」しているものである。
（ｂ−３）上記（ｂ−１），（ｂ−２）の検討から，引用発明と本願発明とは，後記する点で相違するものの，「ユーザおよび１つまたは複数のサーバを相互に認証する認証および鍵一致機構を使用して前記ユーザを認証するステップ」を備えている点で共通している。
　
（ｃ）
（ｃ−１）引用発明の「サービスエンティティの識別情報を認証する」が，本願発明の「ユーザを認証する」に相当する。
　引用発明では，第1ステージにおいて「サービスエンティティ（ユーザ）の識別情報を認証する」と，続く第2ステージにおいて，「SPがそのサービスを提供する資格を与えられている(すなわち，SPが正当である)ことを示す場合には，EACは，SSおよびSPの識別情報とSSおよびEACの共有鍵材料とに従って，SSとSPとの間のサービス通信を保護するための派生鍵K-SSP/SPを計算し，EACは，さらに，その派生鍵とSSおよびSPの識別情報とを含むサービス許可チケット（SGT）を生成し，それ自体およびSPの共有鍵材料を使用して，そのSGTを暗号化し，EACは，上記で暗号化されたSGTをSSに転送し（ブロック703），SGTを受信した時に，SSは，EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって，EACが生成したものと同一の派生鍵をローカルに生成し（ブロック704）」ている。
　ここで，引用発明の「派生鍵」は，SSおよびSPが，当該「派生鍵」を使用して，それらの間でサービスを保護するための鍵であり，また，引用発明では，「共有される派生鍵を獲得した後に，SSおよびSPは，その派生鍵を使用して，各サービス通信の前にこの2つの当事者間で相互認証を実行し，通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成し，その後，そのセッション鍵を使用してサービス通信を保護することができ」るものであるから，引用発明の「派生鍵」及び「セッション鍵」が本願発明の「セッション鍵」に相当し，引用発明の「SSが，EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって，EACが生成したものと同一の派生鍵をローカルに生成」すること，及び「共有される派生鍵を獲得した後に，SSは，その派生鍵を使用して，各サービス通信の前にこの2つの当事者間で相互認証を実行し，通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成」することが，本願発明の「ユーザがセッション鍵を導出すること」に相当する。
　してみれば，引用発明と本願発明とは，「さらに，前記方法は，ユーザを認証すると，前記ユーザがセッション鍵を導出することを可能にするステップ」を備えている点で共通している。
（ｃ−２）引用発明のサービスプロバイダ（SP）は，「モバイルネットワーク内のアプリケーションサーバとすることができ」るものであるから，引用発明の「サービスプロバイダ（SP）」が本願発明の「アプリケーションサーバ」に相当する。
　そして，上記（ａ−１）で検討したように，引用発明の「サービスプロバイダ（SP）」は，「Kerberosに対応したサービスプロバイダ（SP）」であり，「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーション」を「提供する」ものである。
　してみれば，引用発明の「サービスプロバイダ（SP）」が本願発明の「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションを提供する１つまたは複数のアプリケーションサーバ」に相当する。
（ｃ−３）引用発明において，「SSは，SGT（サービス許可チケット）を含むサービス要求をSP（アプリケーションサーバ）に転送し（ブロック705）」ていることから，引用発明の「SGT（サービス許可チケット）」が本願発明の「アプリケーションサーバへのチケット」に相当する。
（ｃ−４）引用発明では，ブロック703において，「EAC」は，「派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し，それ自体およびSPの共有鍵材料を使用して，そのSGT（サービス許可チケット）を暗号化し，EACは，上記で暗号化されたSGT（サービス許可チケット）をSSに転送し」ており，引用発明の「SGT（サービス許可チケット）をSSに転送」することが，本願発明の「チケットを提供する」ことに相当する。
（ｃ−５）上記（ｃ−１）〜（ｃ−４）の検討から，引用発明と本願発明とは，後記する点で相違するものの，「さらに，方法は，ユーザを認証すると，前記ユーザがセッション鍵を導出することを可能にするステップであって，１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションを提供する１つまたは複数のアプリケーションサーバへのチケットを提供する，ステップ」を備えている点で共通している。
　そうすると，本願発明と引用発明とは，
　
「１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションに対してユーザを認証するための方法であって，
　前記ユーザおよび１つまたは複数のサーバを相互に認証する認証および鍵一致機構を使用して前記ユーザを認証するステップを備え，
　さらに，前記方法は，
　前記ユーザを認証すると，前記ユーザがセッション鍵を導出することを可能にするステップであって，１つまたは複数のＫｅｒｂｅｒｏｓ対応アプリケーションを提供する１つまたは複数のアプリケーションサーバへのチケットを提供する，ステップとを備える，方法。」
　
の点で一致し，以下の点で相違する。  
　
［相違点１］
　「認証および鍵一致機構」が，本願発明では，「ブートストラッププロトコルに基づく」ものであるのに対して，引用発明では，そのような特定はなされていない点。
　
［相違点２］
　本願発明では，「ブートストラッププロトコルは汎用ブートストラップアーキテクチャに基づいて」いるのに対して，引用発明では，そのような特定はなされていない点。
［相違点３］
　本願発明では，「チケットがチケット交付サーバへ発行され」ており，「前記チケット交付サーバ」が，アプリケーションサーバへのチケットを提供しているのに対して，引用発明では，そのような構成は特定されていない点。
５．判断  
　上記各相違点について，検討する。
 　 
［相違点１］及び［相違点２］について
　本願の明細書【００２３】段落には，「図３に示されるように，ステップ３６０の間のユーザ３１０とＢＳＦ  ３３０の間の例示的な対話は，図１に関連して上記に説明されたように，ブートストラッププロトコル（たとえばＨＴＴＰダイジェストＡＫＡ）に従って実施されてよい。」と記載されており，ブートストラッププロトコルとして，「ＨＴＴＰダイジェストＡＫＡ」が例示されている。
　ここで，ＡＫＡプロトコルとして，「ＨＴＴＰダイジェストＡＫＡ」を用いることは，当該技術分野の周知技術である。
　例えば「江川　尚志　外１名，技術から理解する　ＮＧＮ入門　次世代の通信インフラはこうして作られる！−第５回　安全で安定した通信のためのセキュリティ対策−，ＮＥＴＷＯＲＫ　ＷＯＲＬＤ，（株）ＩＤＧジャパン，２００７年３月１日，第１２巻，第３号，ｐ１１８〜１２１」には，
「ユーザーからの認証・登録要求が来ると，ＩＥＴＦ ＲＦＣ ３３１０に規定された「ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ：認証／暗号鍵配送方式）」が実行され，網と端末が共有している秘密鍵を使ってＩＰｓｅｃ用の鍵を生成してＩＰｓｅｃトンネルを張り，これを使ってＳ−ＣＳＣＦと通信してＳＩＰ認証を行う。」（第１２０頁右欄１９〜２４行）
と記載されている。
　例えば国際公開第２００７／０６２８８２号には，
「The simple network model for the GBA architecture is illustrated in the schematic diagram of Figure 2. When a UE knows that a bootstrapping procedure is required, it will first perform a bootstrapping authentication with the BSF using the http digest AKA procedure (RFC 3310). 」（第３頁３１行〜第４頁１行）（当審仮訳：ＧＢＡアーキテクチャの単純なネットワークモデルを図２に概略的に示す。ブートストラッピング手順が必要であることをＵＥが知っている場合，最初に，ＵＥはｈｔｔｐダイジェストＡＫＡ手順（ＲＦＣ３３１０）を使用してＢＳＦと共にブートストラッピング認証を実行する。）
と記載されている。
　
　また，「ＡＫＡプロトコル」を「汎用ブートストラップアーキテクチャに基づい」たものとすることも当該技術分野の周知技術である。
　例えば国際公開第２００７／０６２８８２号には，
「3GPP Technical Specification TS 33.220 specifies the so-called Generic Bootstrapping Architecture (GBA). GBA provides a mechanism whereby a client terminal (UE) can be authenticated to a Network Authentication Function (NAF) - i.e. the service node or service provider - and secure session keys (Ks_NAF) obtained for use between the UE and the NAF, based upon keys CK and IK obtained during a re-run of the AKA procedure (this procedure should be distinguished from the initial AKA process run at registration or re-registration of the UE). A Bootstrapping Server Function (BSF) is introduced into the UE's home network, and the AKA re-run is between the UE and the BSF.
　The simple network model for the GBA architecture is illustrated in the schematic diagram of Figure 2. When a UE knows that a bootstrapping procedure is required, it will first perform a bootstrapping authentication with the BSF using the http digest AKA procedure (RFC 3310). 」（第３頁２１行〜第４頁１行）（当審仮訳：３ＧＰＰ技術仕様書TS33.220は，いわゆる汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を規定する。ＧＢＡは，ＡＫＡ手順（この手順は，ＵＥの登録時又は再登録時に実行される初期ＡＫＡ処理とは区別される必要がある）の再実行中に取得される鍵ＣＫ及びＩＫに基づいて，クライアント端末（ＵＥ）がネットワーク認証機能（ＮＡＦ），すなわちサービスノード又はサービスプロバイダと，ＵＥとＮＡＦとの間で使用するために取得されるセキュアセッション鍵（Ｋｓ＿ＮＡＦ）とに対して認証される機構を提供する。ブートストラッピングサーバ機能（ＢＳＦ）はＵＥのホームネットワークに導入され，ＡＫＡの再実行はＵＥとＢＳＦとの間で行なわれる。
  ＧＢＡアーキテクチャの単純なネットワークモデルを図２に概略的に示す。ブートストラッピング手順が必要であることをＵＥが知っている場合，最初に，ＵＥはｈｔｔｐダイジェストＡＫＡ手順（ＲＦＣ３３１０）を使用してＢＳＦと共にブートストラッピング認証を実行する。）
と記載されている。
　例えば特表２００７−５３５２５９号公報には，
「ＧＡＡと同様に，本発明の実施形態は，一般的ブートストラップアーキテクチャー（ＧＢＡ）を組み込んだネットワークに適用することができる。ＧＢＡは，認証及びキー合意（ＡＫＡ）を使用してＵＥとサーバーとの間に共有シークレットをインストールするメカニズムを提供する。ＡＫＡは，移動ネットワークに使用される非常にパワフルなメカニズムである。ＧＢＡは，好都合にも，このメカニズムを使用して，アプリケーションセキュリティをブートストラップする。」（【００４７】〜【００４８】段落）
と記載されている。
　
　してみれば，引用発明において，「認証および鍵一致機構」（ＡＫＡプロトコル）を周知のＨＴＴＰダイジェストＡＫＡ（ブートストラッププロトコル）に基づくものとし，さらに，このＨＴＴＰダイジェストＡＫＡ（ブートストラッププロトコル）」を「汎用ブートストラップアーキテクチャに基づい」たものとすることにより，相違点１及び２に係る本願発明の構成とすることは，当業者が容易に想到し得たことである。
　
［相違点３］について
　情報を提供する形態をどのようなものとするかは，当業者が適宜なし得る設計的事項である。
　また，引用発明は，Ｋｅｒｂｅｒｏｓプロトコルを用いるものであり，このＫｅｒｂｅｒｏｓプロトコルでは，サーバから発行される「ユーザの身元を確立するための情報」として，「チケット」の形態を用いることが広く知られている。
　さらに，Ｋｅｒｂｅｒｏｓプロトコルにおいて，認証サーバとともに「チケット交付サーバ（チケット発行サーバ）」を用いることは周知技術である。
　例えば特開２００２−２０８９２４号公報には，
「図９と図10を参照して，第４の従来例のケルベロス（Kerberos）システムを説明する。ケルベロスは，サービスに対して，ユーザーの身元を証明する認証方式である。図９は，従来のケルベロス（Kerberos）システムの機能ブロック図である。図９において，ユーザー91は，ケルベロスシステムの利用者である。AS92は，認証サーバーである。TGS93は，チケット発行サーバーである。サービス機関94は，ユーザーに所定のサービスを提供するシステムである。」（【００２４】段落）
「図10は，従来のケルベロス（Kerberos）システムの動作を示す流れ図である。図10において，TGS用チケット要求1001は，ユーザーからASにTGS用チケットの交付を要求する手続きである。TGS用チケット配送1002は，ASからユーザーにTGS用チケットを配送する手続きである。サービスチケット要求1003は，ユーザーがTGSにサービスチケットの交付を要求する手続きである。サービスチケット配送1004は，TGSからユーザーにサービスチケットを配送する手続きである。サービスチケット伝送1005は，ユーザーからサービス機関にサービスチケットを伝送する手続きである。サービス提供1006は，サービス機関がユーザーにサービスを提供する手続きである。」（【００２５】段落）
「上記のように構成された第４の従来例のケルベロス（Kerberos）システムの動作を説明する。認証は，チケットと呼ばれる暗号化情報を用いて行われる。図10に示すTGS用チケット要求1001では，ユーザーからASにTGS用チケットの交付を要求する。TGS用チケット配送1002では，ASからユーザーにTGS用チケットを配送する。サービスチケット要求1003では，ユーザーがTGSにサービスチケットの交付を要求する。サービスチケット配送1004では，TGSからユーザーにサービスチケットを配送する。サービスチケット伝送1005では，ユーザーからサービス機関にサービスチケットを伝送する。サービス提供1006では，サービス機関がユーザーにサービスを提供する。」（【００２６】段落）
と記載されている。
　してみれば，引用発明において，ユーザの身元を確立するための情報であるＩＳＲ−ＩＤを，Ｋｅｒｂｅｒｏｓプロトコルで用いられている「チケット」の形態とし，この「チケット」が「チケット交付サーバ」へ「発行」されるように構成するとともに，この「チケット」を受け取った「チケット交付サーバ」が，アプリケーションサーバへのチケットを提供するように構成することは当業者が容易に想到し得たことである。
　
　そして，本願発明の作用効果も，引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　したがって，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
６．むすび  
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は他の請求項について検討するまでもなく拒絶されるべきものである。
　よって，結論のとおり審決する。