拒絶査定不服の審決｜不服2013-20674 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない。 H04L
管理番号	1306829
審判番号	不服2013-20674
総通号数	192
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2015-12-25
種別	拒絶査定不服の審決
審判請求日	2013-10-24
確定日	2015-10-14
事件の表示	特願2011-503969「認証および鍵一致(AKA)機構に基づくKeｒbeｒｏｓ対応アプリケーションへの認証されたユーザアクセスのための方法および装置」拒絶査定不服審判事件〔平成21年10月15日国際公開、WO2009/126210、平成23年 9月 1日国内公表、特表2011-524652〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続の経緯本願は,2009年3月26日(パリ条約による優先権主張外国庁受理2008年4月10日,米国)を国際出願日とする出願であって,平成24年11月26日付けの拒絶理由通知に対して,平成25年5月30日に意見書と手続補正書が提出されたが,同年6月17日付けで拒絶査定がなされ,これに対して,同年10月24日に拒絶査定不服審判の請求がなされたものである。 2.本願発明本願の請求項1に係る発明(以下,「本願発明」という。)は,平成25年5月30日に提出された手続補正書により補正された特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものである。「1つまたは複数のKeｒbeｒｏｓ対応アプリケーションに対してユーザを認証するための方法であって, 前記ユーザおよび1つまたは複数のサーバを相互に認証するブートストラッププロトコルに基づく認証および鍵一致機構を使用して前記ユーザを認証するステップを備え,前記ブートストラッププロトコルは汎用ブートストラップアーキテクチャに基づいており,チケットがチケット交付サーバへ発行され,さらに,前記方法は, 前記ユーザを認証すると,前記ユーザがセッション鍵を導出することを可能にするステップであって,前記チケット交付サーバが,1つまたは複数のKeｒbeｒｏｓ対応アプリケーションを提供する1つまたは複数のアプリケーションサーバへのチケットを提供する,ステップとを備える,方法。」 3.引用例 (1)引用例1 原査定の拒絶理由通知で引用された「国際公開第2007/085175号」(以下「引用例1」という。)には,図面とともに以下の事項が記載されている。なお,上記引用例1として公開された国際出願の対応する日本国公表特許公報である特表2009-524369号公報の対応箇所の記載を当審の仮訳とした。 (ア)「」(第1頁2行?16行) (当審仮訳:技術分野本発明は,ネットワーク通信サービス技法に関し,具体的には,モバイルネットワークに基づくエンドツーエンド通信での認証の方法,システム,および認証センタに関する。背景技術現在,サービスをモバイル加入者に提供する時に,アプリケーションサーバの大多数は,まず,モバイル加入者と認証プロキシとの間,モバイル加入者と公開鍵基盤(PKI)証明機関との間,モバイル加入者とコンテンツ提供サーバとの間など,相互信頼関係をモバイル加入者と共に確立する。一般に,そのような信頼関係は,モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。 3G無線通信標準規格では,GAA(Generic Authentication Architecture)が,加入者識別情報を検証するためにさまざまなアプリケーションサービスエンティティによって使用される一般的アーキテクチャであり,アプリケーションサービス加入者をチェックし,加入者識別情報を検証することができる。上記アプリケーションサービスは,マルチキャスト/ブロードキャストサービス,ユーザ証明書サービス,瞬時情報を提供するサービス,またはプロキシサービスとすることができる。) (イ)「」(第1頁17行?第2頁15行) (当審仮訳:図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の共有鍵を生成するように働く。HSS 103は,加入者情報を記述するプロファイルを格納し,認証情報を生成する機能を有する。サービスを使用することを望む時に,加入者は,サービスが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を偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性があることである。) (ウ)「」(第6頁11行?17行) (当審仮訳:本発明の実施形態による技術的解決策によってもたらされる有益な効果は,真の包括的認証アーキテクチャが提供されることであり,ここで,GAAによって提供される認証機構は,複数の認証機構および認証モジュールに関するネゴシエーションおよび選択を実行することができ,これは,認証機構の柔軟性および一般性を高める。本発明の実施形態によるフレームワークでは,サービスプロバイダを,モバイルネットワーク内のアプリケーションサーバ,オープンネットワーク内のアプリケーションサーバ,または高度な機能を有するモバイル端末とすることができ,これは,サービス加入者がより豊富なサービスリソースを使用することを可能にする。この認証解決策は,モバイル端末が,サービスプロバイダになるためにアップグレードされる状況をサポートし,これは,高度な機能を有するモバイル端末がサービスを提供することを望むという需要を満足する。) (エ)「」(第9頁16行?第11頁2行) (当審仮訳:本発明の実施形態によって提供される認証手順は,次のステージを含む。第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をさらに生成し,その後,そのセッション鍵を使用してサービス通信を保護することができる。) (オ)「」(第11頁3行?第13頁1行) (当審仮訳:本発明の実施形態によって提供される認証手順の各ステージを,これより,添付の図面を参照して詳細に説明する。図4は,本発明による実施形態での,サービスエンティティとEACとの間で認証機構をネゴシエートし,相互認証を実行するプロセスを示す流れ図である。この実施形態では,サービスエンティティとEACとの間で認証機構をネゴシエートし,相互認証を実行するプロセスは,図4に示されているようにサービスエンティティによって開始され,次のステップを含む。ブロック401:サービスエンティティは,要求されたサービスまたは提供されるサービス(たとえば,ビデオ会議サービス)に対応する認証機構のセキュリティ度合要件(たとえば,高セキュリティ度合)を自動的に選択する。ブロック402:サービスエンティティが,サービスエンティティのID,サービスエンティティによって選択された認証機構のセキュリティ度合などの関連情報を伝える認証要求をEACに転送する。ブロック403:認証要求を受信した時に,EACは,ローカルに格納されたセキュリティ度合リストを検索して,ネットワークによって現在サポートされ,認証プロトコルおよび暗号化アルゴリズムを含むセキュリティ度合要件を満足する少なくとも1つの認証機構を見つける。たとえば,Http AKAは,ネットワークと無線ネットワーク内の端末との間の相互認証プロトコルである。このプロトコルを実行することによって,2つの通信当事者は,互いの識別情報を認証し,同一の鍵をそれぞれ生成することができる。ブロック404:サービスエンティティの識別情報に従って,EACは,ESDに格納されたサブスクリプション情報を問い合わせ,サービスエンティティの認証情報,たとえば,認証プロトコル,暗号化アルゴリズム,および他の関連パラメータを含む,サービスエンティティによってサポートされる認証機構を得る。ブロック405:ESDは,サービスエンティティの認証機能情報(たとえば,サポートされる認証プロトコル,暗号化アルゴリズムなど)および他の関連パラメータをEACに返す。ブロック406:EACは,ローカルポリシに従って,サービスエンティティおよびネットワークによってサポートされる認証プロトコルおよび暗号化アルゴリズムを照合し,やはりセキュリティ度合要件に従って,両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズム(すなわち,認証機構)を判定する。セキュリティ度合要件にも従う,両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズムがない場合には,EACは,エラー表示をサービスエンティティに返し,現在の手順を打ち切る。ブロック407:EACは,認証プロトコルおよび暗号化アルゴリズムを含む選択された認証機構をサービスエンティティに返す。ブロック408:EACによって返された情報を受信した時に,サービスエンティティは,認証機構を判断し,確認応答をEACに返す。ブロック409:サービスエンティティおよびEACは,選択された認証プロトコルおよび暗号化アルゴリズムを使用して,相互認証を実行する。成功の認証の後に,両方の当事者は,共有鍵材料(共有される秘密情報とも称する)を獲得する。サービスエンティティがモバイル端末である場合には,共有鍵材料を,共有鍵(Ks)とすることができる。サービスエンティティがモバイルコアネットワークドメイン内のアプリケーションサーバ(AS)である場合には,サービスエンティティとEACとの間の相互認証手順でネゴシエートされる共有鍵材料を,SA(Security Association)すなわち,インターネットプロトコルセキュリティ(IPSec)に従ってネゴシエートされるセキュリティ通信の鍵および鍵アルゴリズム情報とすることができる。ブロック410:EACは,認証成功応答をサービスエンティティに返し,サービスエンティティの一時IDおよび対応する寿命を割り振るが,これには,次の状況が含まれる:1) 認証要求をEACに発行するサービスエンティティがサービス加入者(SS/SSP)である場合に,EACは,SS/SSPが他のエンティティにサービスを要求する場合に使用されるISR-IDをSS/SSPに割り振り,2) 認証要求をEACに発行するサービスエンティティがサービスプロバイダ(SP/SSP)である場合に,EACは,SS/SSPがSSの認証条件についてEACに問い合わせる必要がある場合に使用されるIAC-IDをSS/SSPに割り振る。ブロック411:EACおよびサービスエンティティは,それぞれ,対応するセキュリティ度合に関連する共有鍵材料を格納するが,これは,ISR-ID/IAC-ID,鍵材料,認証機構,およびセキュリティ度合を関連付け,かつ格納することを含む。) (カ)「」(第13頁2行?4行) (当審仮訳:図5は,本発明による実施形態での,サービスエンティティとEACとの間での認証問合せ手順を示す流れ図である。この実施形態では,相互認証を実行した後に,サービスエンティティおよびEACは,認証問合せ手順を実行するが,その詳細な説明が,図5に示されている。) (キ)「」(第16頁23行?第18頁16行) (当審仮訳:エンティティ認証センタ(EAC)が,Kerberosサーバの機能を有する場合には,Kerberosモデルと組み合わされた認証問合せの機構を使用することができる。図6は,Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。図6に示されているように,SSは,サービス許可チケットSGT(service granted ticket)をEACに要求し,SSのISR-IDおよびUIDをEACに供給する。EACは,ISR-IDおよびIAC-IDの妥当性をチェックし,サービス許可チケットを生成し,このサービス許可チケットをSSに返す。サービス要求をSPに発行する時に,SSは,要求内でサービス許可チケットを伝える。SPは,サービス許可チケットに従って派生鍵を生成し,その後,SSにサービス応答を返す。図7は,図6に示された,Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である。図7に示されているように,詳細なステップは,次の通りである。ブロック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に記載されている事項を検討する。 (a)上記摘記事項(エ)の記載によれば,引用例1の発明の実施形態によって提供される認証手順は,エンティティ認証プロセスと称する第1ステージ(ここでは,サービスエンティティが,EACに行って,認証機構をネゴシエートし,サービスエンティティおよびEACは,ネゴシエートされた機構に従って,それらの間で相互認証を実行する。)と,認証問合せプロセスと称する第2ステージと,サービスエンティティ間の相互認証プロセスと称する第3ステージ(ここでは,SSおよびSPが,その派生鍵を使用して相互認証を実行し,通信のセキュリティを保護するためのセッション鍵Kr-SS-SPを生成する。)とを含むものである。 (b)上記摘記事項(オ)の「図4は,本発明による実施形態での,サービスエンティティとEACとの間で認証機構をネゴシエートし,相互認証を実行するプロセスを示す流れ図である。」との記載からみて,図4は,上記摘記事項(エ)の第1ステージに対応するプロセスである。 (c)上記摘記事項(カ)によれば,サービスエンティティおよびEACは,「相互認証を実行した後に,認証問合せ手順を実行する」ものである。 (d)上記摘記事項(キ)によれば,エンティティ認証センタ(EAC)が,Kerberosサーバの機能を有する場合には,Kerberosモデルと組み合わされた認証問合せの機構を使用することができ,図6は,Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図であり,また,図7は,図6に示された,Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である。してみれば,図6,図7は,上記摘記事項(エ)の第2ステージに対応するプロセスであると認められる。 (e)図7のブロック705の記載によれば,ブロック705において,SSは,「SGTを含むサービス要求をspに転送」しているものである。以上の点を踏まえ,上記摘記事項(ア)?(キ)の記載及び図面の記載を総合すると,引用例1には,次のとおりの発明(以下,「引用発明」という。)が記載されていると認められる。「モバイルネットワークに基づくエンドツーエンド通信での認証の方法であって, 認証手順は, エンティティ認証プロセスと称する第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をさらに生成し,その後,そのセッション鍵を使用してサービス通信を保護することができ, サービスプロバイダは,モバイルネットワーク内のアプリケーションサーバとすることができる, 方法。」 4.対比本願発明と,引用発明とを比較する。 (a) (a-1)引用発明のサービスプロバイダ(SP)は,「モバイルネットワーク内のアプリケーションサーバとすることができ」るものであるから,引用発明のサービスプロバイダ(SP)は,所定のサービスを提供するために,当該サービスに対応した「アプリケーション」を有しているということができる。引用発明の第2ステージでは,ブロック705において,「Kerberosモデルと組み合わされた認証問合せの機構を使用」して,「SSが,SGT(サービス許可チケット)を含むサービス要求をSPに転送」すると,SPは,「SGTを暗号化解除して,派生鍵を獲得し(ブロック706)」たり,「成功を識別するサービス要求応答をSSに返し(ブロック707)」たりしているから,引用発明のサービスプロバイダ(SP)は,「Kerberos」に「対応」したものといえる。そうすると,引用発明の「サービスプロバイダ(SP)」が有する「アプリケーション」は,「Kerberosに対応したKerberos対応アプリケーション」であるといえるから,引用発明と本願発明とは,「1つまたは複数のKeｒbeｒｏｓ対応アプリケーション」を有する点で共通する。 (a-2)引用発明の「サービス加入者(SS)」は,「サービスを獲得することを望む」主体であることから,本願発明の「ユーザ」に相当する。引用発明では,「あるサービスを獲得することを望む時に」,「SSが,SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送」すると,「EACは,要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって,SSがそのサービスを使用する資格を与えられているかどうかを判断し」ている。ここで,「SSがそのサービスを使用する資格を与えられているかどうかを判断すること」は,すなわち,「SS(ユーザ)がそのサービス(を提供するためのアプリケーション)を使用する資格を与えられているかどうかを判断(認証)すること」である。してみれば,引用発明の「SSがそのサービスを使用する資格を与えられているかどうかを判断すること」が本願発明の「アプリケーションに対してユーザを認証する」ことに相当する。 (a-3)上記(a-1),(a-2)の検討から,引用発明と本願発明とは,「1つまたは複数のKeｒbeｒｏｓ対応アプリケーションに対してユーザを認証するための方法」である点で共通している。 (b) (b-1)引用発明では,「サービスエンティティおよびEACは,選択された認証プロトコルおよび暗号化アルゴリズムを使用して,相互認証を実行し(ブロック409)」ている。ここで,引用発明の「サービスエンティティ」は,「サービス加入者(SS)」を含む概念であるから,引用発明の「サービスエンティティ」が本願発明の「ユーザ」に相当する。また,引用発明は,「エンティティ認証センタ(EAC)が,Kerberosサーバの機能を有する場合」の発明であるから,引用発明の「EAC」が本願発明の「サーバ」に相当する。してみれば,引用発明と本願発明とは,「ユーザおよび1つまたは複数のサーバを相互に認証する」ものである点で共通している。 (b-2)引用発明では,「相互認証プロトコル」として,「Http AKA」を実行するものである。ここで,「AKA」とは,「AUTHENTICATION AND KEY AGREEMENT」,すなわち,「認証および鍵一致」のことであるから,引用発明の「Http AKA」が本願発明の「認証および鍵一致機構」に相当する。そして,引用発明では,相互認証プロトコルとして,「Http AKA(認証および鍵一致機構)」を「使用して」,「サービスエンティティ(ユーザ)」を「認証」しているものである。 (b-3)上記(b-1),(b-2)の検討から,引用発明と本願発明とは,後記する点で相違するものの,「ユーザおよび1つまたは複数のサーバを相互に認証する認証および鍵一致機構を使用して前記ユーザを認証するステップ」を備えている点で共通している。 (c) (c-1)引用発明の「サービスエンティティの識別情報を認証する」が,本願発明の「ユーザを認証する」に相当する。引用発明では,第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をさらに生成」することが,本願発明の「ユーザがセッション鍵を導出すること」に相当する。してみれば,引用発明と本願発明とは,「さらに,前記方法は,ユーザを認証すると,前記ユーザがセッション鍵を導出することを可能にするステップ」を備えている点で共通している。 (c-2)引用発明のサービスプロバイダ(SP)は,「モバイルネットワーク内のアプリケーションサーバとすることができ」るものであるから,引用発明の「サービスプロバイダ(SP)」が本願発明の「アプリケーションサーバ」に相当する。そして,上記(a-1)で検討したように,引用発明の「サービスプロバイダ(SP)」は,「Kerberosに対応したサービスプロバイダ(SP)」であり,「1つまたは複数のKeｒbeｒｏｓ対応アプリケーション」を「提供する」ものである。してみれば,引用発明の「サービスプロバイダ(SP)」が本願発明の「1つまたは複数のKeｒbeｒｏｓ対応アプリケーションを提供する1つまたは複数のアプリケーションサーバ」に相当する。 (c-3)引用発明において,「SSは,SGT(サービス許可チケット)を含むサービス要求をSP(アプリケーションサーバ)に転送し(ブロック705)」ていることから,引用発明の「SGT(サービス許可チケット)」が本願発明の「アプリケーションサーバへのチケット」に相当する。 (c-4)引用発明では,ブロック703において,「EAC」は,「派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し,それ自体およびSPの共有鍵材料を使用して,そのSGT(サービス許可チケット)を暗号化し,EACは,上記で暗号化されたSGT(サービス許可チケット)をSSに転送し」ており,引用発明の「SGT(サービス許可チケット)をSSに転送」することが,本願発明の「チケットを提供する」ことに相当する。 (c-5)上記(c-1)?(c-4)の検討から,引用発明と本願発明とは,後記する点で相違するものの,「さらに,方法は,ユーザを認証すると,前記ユーザがセッション鍵を導出することを可能にするステップであって,1つまたは複数のKeｒbeｒｏｓ対応アプリケーションを提供する1つまたは複数のアプリケーションサーバへのチケットを提供する,ステップ」を備えている点で共通している。そうすると,本願発明と引用発明とは, 「1つまたは複数のKeｒbeｒｏｓ対応アプリケーションに対してユーザを認証するための方法であって, 前記ユーザおよび1つまたは複数のサーバを相互に認証する認証および鍵一致機構を使用して前記ユーザを認証するステップを備え, さらに,前記方法は, 前記ユーザを認証すると,前記ユーザがセッション鍵を導出することを可能にするステップであって,1つまたは複数のKeｒbeｒｏｓ対応アプリケーションを提供する1つまたは複数のアプリケーションサーバへのチケットを提供する,ステップとを備える,方法。」の点で一致し,以下の点で相違する。 [相違点1] 「認証および鍵一致機構」が,本願発明では,「ブートストラッププロトコルに基づく」ものであるのに対して,引用発明では,そのような特定はなされていない点。 [相違点2] 本願発明では,「ブートストラッププロトコルは汎用ブートストラップアーキテクチャに基づいて」いるのに対して,引用発明では,そのような特定はなされていない点。 [相違点3] 本願発明では,「チケットがチケット交付サーバへ発行され」ており,「前記チケット交付サーバ」が,アプリケーションサーバへのチケットを提供しているのに対して,引用発明では,そのような構成は特定されていない点。 5.判断上記各相違点について,検討する。 [相違点1]及び[相違点2]について本願の明細書【0023】段落には,「図3に示されるように,ステップ360の間のユーザ310とBSF 330の間の例示的な対話は,図1に関連して上記に説明されたように,ブートストラッププロトコル(たとえばHTTPダイジェストAKA)に従って実施されてよい。」と記載されており,ブートストラッププロトコルとして,「HTTPダイジェストAKA」が例示されている。ここで,AKAプロトコルとして,「HTTPダイジェストAKA」を用いることは,当該技術分野の周知技術である。例えば「江川尚志外1名,技術から理解する NGN入門次世代の通信インフラはこうして作られる!-第5回安全で安定した通信のためのセキュリティ対策-,NETWORK WORLD,(株)IDGジャパン,2007年3月1日,第12巻,第3号,ｐ118?121」には, 「ユーザーからの認証・登録要求が来ると,IETF RFC 3310に規定された「HTTP Digeｓｔ AKA(Aｕｔhenｔicaｔiｏn and Keｙ Agｒeemenｔ:認証/暗号鍵配送方式)」が実行され,網と端末が共有している秘密鍵を使ってIPｓec用の鍵を生成してIPｓecトンネルを張り,これを使ってS-CSCFと通信してSIP認証を行う。」(第120頁右欄19?24行) と記載されている。例えば国際公開第2007/062882号には, 「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). 」(第3頁31行?第4頁1行)(当審仮訳:GBAアーキテクチャの単純なネットワークモデルを図2に概略的に示す。ブートストラッピング手順が必要であることをUEが知っている場合,最初に,UEはhｔｔｐダイジェストAKA手順(RFC3310)を使用してBSFと共にブートストラッピング認証を実行する。) と記載されている。また,「AKAプロトコル」を「汎用ブートストラップアーキテクチャに基づい」たものとすることも当該技術分野の周知技術である。例えば国際公開第2007/062882号には, 「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). 」(第3頁21行?第4頁1行)(当審仮訳:3GPP技術仕様書TS33.220は,いわゆる汎用ブートストラッピングアーキテクチャ(GBA)を規定する。GBAは,AKA手順(この手順は,UEの登録時又は再登録時に実行される初期AKA処理とは区別される必要がある)の再実行中に取得される鍵CK及びIKに基づいて,クライアント端末(UE)がネットワーク認証機能(NAF),すなわちサービスノード又はサービスプロバイダと,UEとNAFとの間で使用するために取得されるセキュアセッション鍵(Kｓ_NAF)とに対して認証される機構を提供する。ブートストラッピングサーバ機能(BSF)はUEのホームネットワークに導入され,AKAの再実行はUEとBSFとの間で行なわれる。 GBAアーキテクチャの単純なネットワークモデルを図2に概略的に示す。ブートストラッピング手順が必要であることをUEが知っている場合,最初に,UEはhｔｔｐダイジェストAKA手順(RFC3310)を使用してBSFと共にブートストラッピング認証を実行する。) と記載されている。例えば特表2007-535259号公報には, 「GAAと同様に,本発明の実施形態は,一般的ブートストラップアーキテクチャー(GBA)を組み込んだネットワークに適用することができる。GBAは,認証及びキー合意(AKA)を使用してUEとサーバーとの間に共有シークレットをインストールするメカニズムを提供する。AKAは,移動ネットワークに使用される非常にパワフルなメカニズムである。GBAは,好都合にも,このメカニズムを使用して,アプリケーションセキュリティをブートストラップする。」(【0047】?【0048】段落) と記載されている。してみれば,引用発明において,「認証および鍵一致機構」(AKAプロトコル)を周知のHTTPダイジェストAKA(ブートストラッププロトコル)に基づくものとし,さらに,このHTTPダイジェストAKA(ブートストラッププロトコル)」を「汎用ブートストラップアーキテクチャに基づい」たものとすることにより,相違点1及び2に係る本願発明の構成とすることは,当業者が容易に想到し得たことである。 [相違点3]について情報を提供する形態をどのようなものとするかは,当業者が適宜なし得る設計的事項である。また,引用発明は,Keｒbeｒｏｓプロトコルを用いるものであり,このKeｒbeｒｏｓプロトコルでは,サーバから発行される「ユーザの身元を確立するための情報」として,「チケット」の形態を用いることが広く知られている。さらに,Keｒbeｒｏｓプロトコルにおいて,認証サーバとともに「チケット交付サーバ(チケット発行サーバ)」を用いることは周知技術である。例えば特開2002-208924号公報には, 「図9と図10を参照して,第4の従来例のケルベロス(Kerberos)システムを説明する。ケルベロスは,サービスに対して,ユーザーの身元を証明する認証方式である。図9は,従来のケルベロス(Kerberos)システムの機能ブロック図である。図9において,ユーザー91は,ケルベロスシステムの利用者である。AS92は,認証サーバーである。TGS93は,チケット発行サーバーである。サービス機関94は,ユーザーに所定のサービスを提供するシステムである。」(【0024】段落) 「図10は,従来のケルベロス(Kerberos)システムの動作を示す流れ図である。図10において,TGS用チケット要求1001は,ユーザーからASにTGS用チケットの交付を要求する手続きである。TGS用チケット配送1002は,ASからユーザーにTGS用チケットを配送する手続きである。サービスチケット要求1003は,ユーザーがTGSにサービスチケットの交付を要求する手続きである。サービスチケット配送1004は,TGSからユーザーにサービスチケットを配送する手続きである。サービスチケット伝送1005は,ユーザーからサービス機関にサービスチケットを伝送する手続きである。サービス提供1006は,サービス機関がユーザーにサービスを提供する手続きである。」(【0025】段落) 「上記のように構成された第4の従来例のケルベロス(Kerberos)システムの動作を説明する。認証は,チケットと呼ばれる暗号化情報を用いて行われる。図10に示すTGS用チケット要求1001では,ユーザーからASにTGS用チケットの交付を要求する。TGS用チケット配送1002では,ASからユーザーにTGS用チケットを配送する。サービスチケット要求1003では,ユーザーがTGSにサービスチケットの交付を要求する。サービスチケット配送1004では,TGSからユーザーにサービスチケットを配送する。サービスチケット伝送1005では,ユーザーからサービス機関にサービスチケットを伝送する。サービス提供1006では,サービス機関がユーザーにサービスを提供する。」(【0026】段落) と記載されている。してみれば,引用発明において,ユーザの身元を確立するための情報であるISR-IDを,Keｒbeｒｏｓプロトコルで用いられている「チケット」の形態とし,この「チケット」が「チケット交付サーバ」へ「発行」されるように構成するとともに,この「チケット」を受け取った「チケット交付サーバ」が,アプリケーションサーバへのチケットを提供するように構成することは当業者が容易に想到し得たことである。そして,本願発明の作用効果も,引用発明及び周知技術から当業者が予測できる範囲のものである。したがって,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。 6.むすび以上のとおり,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。したがって,本願は他の請求項について検討するまでもなく拒絶されるべきものである。よって,結論のとおり審決する。
審理終結日	2015-05-12
結審通知日	2015-05-19
審決日	2015-06-03
出願番号	特願2011-503969(P2011-503969)
審決分類	P 1 8・ 121- Z (H04L)
最終処分	不成立
前審関与審査官	宮司卓佳
特許庁審判長	辻本泰隆
特許庁審判官	須田勝巳戸島弘詩
発明の名称	認証および鍵一致(AKA)機構に基づくKeｒbeｒｏｓ対応アプリケーションへの認証されたユーザアクセスのための方法および装置
代理人	特許業務法人川口國際特許事務所

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