【事件の表示】
　特願２０１６−５４１８３５「プライバシー機密情報の交換を制御するための方法およびシステム」拒絶査定不服審判事件〔平成２７年　３月１９日国際公開，ＷＯ２０１５／０３６０８７，平成２８年１０月　６日国内公表，特表２０１６−５３１５２８，請求項の数（１５）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　本願は，２０１４年８月１８日（パリ条約による優先権主張外国庁受理２０１３年９月１３日　欧州特許庁）を国際出願日とする出願であって，
　平成２８年４月１４日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，平成２９年４月２８日付けで審査官により拒絶理由が通知され，これに対して平成２９年７月１２日付けで意見書が提出されると共に手続補正がなされたが，平成２９年１２月２１日付けで審査官により拒絶査定がなされ（謄本送達；平成３０年１月９日），これに対して平成３０年５月８日付けで審判請求がなされたものである。
　
第２．原査定の概要
　原審における平成２９年１２月２１日付けの拒絶査定（以下，これを「原審拒絶査定」という）は，概略，以下のとおりである。
「備考
・請求項　１−１５
・引用文献等　１，２
　引用文献１には，アプリケーションを開始すると，そのアプリケーションが信頼されたエージェントと通信し（段落［００２８］），信頼されたエージェントが，開始しようとするセッションのためのトークン要求を認証サーバに送信すると，認証サーバが，トークンを信頼されたエージェントに返送し，ここでトークンはダイジェストの計算に用いられる乱数であり，信頼されたエージェントが，ＩＮＶＩＴＥ要求を，ダイジェストを付加することにより変更し，ダイジェストは，秘密鍵とトークンとを用いて計算され，ＩＮＶＩＴＥ要求は，呼処理サーバに送信され，アプリケーションを認証するために，認証処理が実行され，そのために，呼処理サーバは認証要求を認証サーバに送信し，認証要求はダイジェストを含み，認証サーバが，算出したダイジェストが認証要求において受信したダイジェストが一致することを検出した場合，アプリケーションが認証され，認証サーバが呼処理サーバに認証応答を返し，その応答が認証成功を示す場合，呼処理サーバは，ＩＮＶＩＴＥ要求を他の端末へ転送し，セッションの料金記録を生成する（段落［００３４］−［００３８］），ことが記載されている。
　引用文献１に記載された発明において，アプリケーションが信頼されたエージェントと通信し，信頼されたエージェントが，開始しようとするセッションのためのトークン要求を認証サーバに送信することは，その結果，呼処理サーバが，ＩＮＶＩＴＥ要求を他の端末へ転送し，セッションの料金記録を生成することから，補正後の請求項１に記載された発明の「プライベートデータの使用を要求するサービス（１０５；２０５）へのアクセスのためのリクエストを，アプリケーション（１０３；２０３）から，サービングノードに送信するステップ」に相当
する。
　してみれば，補正後の請求項１に係る発明と引用文献１に記載された発明とは，上記拒絶理由通知書において述べた相違点（ａ）及び（ｂ）にて相違し，それ以外の点で一致する。そして，それら相違点については，上記拒絶理由通知書において述べたと同様，引用文献２に記載の技術を参酌することで，当業者が容易になし得たことである。
　したがって，補正後の請求項１に係る発明は依然として，引用文献１に記載された発明及び引用文献２に記載の技術に基づいて当業者が容易に想到し得たものであるから，特許法第２９条第２項の規定により特許を受けることができない。
請求項２−１５に係る発明についても同様のことがいえる。
　なお出願人は意見書において「引用文献２の記載にしたがって，引用文献１の上記実施形態が，ダイジェストまたはデジタル署名をＩＮＶＩＴＥ要求に加えることによって修正されたＩＮＶＩＴＥ要求が，信頼されたエージェントの代わりにアプリケーションからＳＩＰプロトコルスタックに送信されるように修正された場合，信頼されたエージェントは，修正されたＩＮＶＩＴＥ要求をアプリケーションに戻す必要があり，結果として，信頼されたエージェントからアプリケーションへの余分のステップを生じさせることになる。
　したがって，当業者は，あえて，引用文献１を引用文献２と組み合わせようとはしない。」と主張している。
　しかしながら，引用文献１に記載された発明は，認証情報であるダイジェストを，ＩＮＶＩＴＥ要求という，ＳＩＰプロトコルにて送信することから，ＳＩＰプロトコルスタックにより，その送信を行うものであるところ，認証情報を如何なるプロコトルにて送信するかは，当業者の設計的事項にすぎず，認証情報を，アプリケーションが処理するプロトコルにて送信することも，本願出願前に一般に行われていたことである。事実，引用文献２に記載の技術は，認証情報である応答を，ブラウザ／アプリケーションを介して送信するものであるから，認証情報を，アプリケーションが処理するプロトコルにて送信するものである。
　そうすると，引用文献１に記載された発明では，信頼されたエージェントが，ダイジェストをＳＩＰプロトコルスタックに転送し，ＳＩＰプロトコルスタックがダイジェストを呼処理サーバに送信するのに対して，引用文献１に記載された発明を，引用文献２に記載の技術を考慮して修正すれば，信頼されたエージェントが，ダイジェストをアプリケーションに転送し，アプリケーションがダイジェストを呼処理サーバに送信することになる。これらは，信頼されたエージェントから呼処理サーバへダイジェストを送信するにあたり，ＳＩＰプロトコルスタックを経由するかアプリケーションを経由するかが異なるにすぎず，修正することにより，出願人が主張する「余分なステップ」が生じることはない。
・・・・(中略）・・・・
　　　　　　　　　　　　＜引用文献等一覧＞
　１．米国特許出願公開第２００５／０１３５３８８号明細書
　２．特表２０１１−５０７０６０号公報」
　
第３．本願発明について
　本願の請求項１〜本願の請求項１５に係る発明（以下，これを「本願発明１〜本願発明１５」という）は，平成２９年７月１２日付けの手続補正により補正された特許請求の範囲の請求項１〜請求項１５に記載された事項により特定されるものであり，そのうち，本願発明１は，次のとおりのものである。
　
「【請求項１】
　データネットワークにおいて，装置（１００；２００）上で，または装置（１００；２００）用に実行するアプリケーション（１０３；２０３）とサービングノードとの間での，クライアント装置（１００；２００）に関連するプライベートデータの交換を制御するための方法であって，
　プライベートデータの使用を要求するサービス（１０５；２０５）へのアクセスのためのリクエストを，アプリケーション（１０３；２０３）から，サービングノードに送信するステップ（１）と，
　サービングノードからのチャレンジデータ（１０７）を，アプリケーション（１０３；２０３）で受信するステップ（３）と，
　チャレンジデータ（１０７）に基づき，クライアント装置（１００；２００）のセキュアユーザインタフェース（１１１；２１３）を使用して，信頼された情報マネージャ（１０９；２０７）に，プライベートデータの使用に対する認可を要求するステップ（５）と，
　アプリケーション（１０３；２０３）が，プライベートデータの知識を得ることができないように，認可に基づいて，サービス（１０５；２０５）で使用されるプライベートデータの難読化バージョン（１１３）を，信頼された情報マネージャ（１０９；２０７）からアプリケーション（１０３；２０３）を介して，サービングノードに送信するステップ（６）と
を含む，方法。」
　
第４．引用文献に記載の事項及び引用文献に記載の発明
１．引用文献１について
　原審拒絶査定の拒絶の理由に引用された引用文献１には，次の事項が記載されている。
　
Ａ．「[0024]　FIG.1 shows an example of a general communication environment in which the present invention can be applied, the communication environment being based on the IMS architecture as defined by the 3GPP. It is thus assumed here that a call processing server 110 includes the Call State Control Functions (CSCF) according to the IMS architecture and that it is connected to the core network elements, such as the Home Subscriber Server (HSS) 112, needed for provision of multimedia services. The HSS contains the master database for a given user. The call processing server, which also generates billing data for a separate billing system (not shown in the figure), is connected to a General Packet Radio Service (GPRS) network 104. The GPRS network is further connected to a Radio Access Network (RAN) 103 comprising a plurality of base stations 102 with which mobile terminals 100 communicate through a radio interface. 
The user of a mobile terminal is thus a subscriber in a mobile communication system, such as the GSM or UMTS system, while the terminal is typically a multimedia phone.
[0025]　
FIG.2 is a schematic illustration of one embodiment of a terminal according to the invention. The entities relevant to the invention reside in a tamper resistant area 200 of the terminal or in an open platform area 201. The tamper resistant area includes at least one trusted agent 212, which acts as a controlling entity controlling the rights and behavior of the applications. The trusted agent may be a dedicated software agent or a Digital Rights Management (DRM) agent whose normal functionality has been modified for the method of the invention. The open platform area in turn includes a plurality of applications 210
１
 to 210
Ｎ
 which may be downloaded from the delivery server 111, for example.
（［００２４］　図１は，本発明が適用され得る，一般的な通信環境の例を示す。その通信環境は，３ＧＰＰによって適宜なされるものとして，ＩＭＳアーキテクチャ上に基礎をおくものである。それ故，ここでは，呼処理サーバ１１０が，ＩＭＳアーキテクチャに従う呼状態制御関数（ＣＳＣＦ）を含むことと，それが，メディア・サービスの提供のために必要とされる，自宅加入者サーバ（ＨＳＳ）１１２のような，コア・ネットワーク・エレメントに接続されることを仮定する。ＨＳＳは，与えられたユーザのためのマスタ・データベースを含む。独立した請求システム（図示せず）のための請求データを生成もする呼処理サーバは，一般のパケット無線通信サービス（ＧＰＲＳ）ネットワーク１０４に接続されている。ＧＰＲＳネットワークは，更に，無線通信インタフェースを介して，モバイル端末１００が通信するところの，多数のベース・ステーション１０２を包含する，無線通信アクセス・ネットワーク（ＲＡＮ）１０３に接続されている。
モバイル端末のユーザは，それ故，ＧＳＭ，或いは，ＵＭＴＳシステムといった，モバイル通信システムの加入者であり，さらに，その端末は，通常は，マルチメディア・フォンである。
［００２５］　
図２は，本発明に従う端末の１実施例の略図である。本発明に関するエンティティは，端末の改ざん耐性領域２００内，或いは，オープン・プラットフォーム領域２０１内に属する。改ざん耐性領域は，アプリケーションの動作と権利とを管理する管理エンティティである信頼されているエージェント２１２を，少なくとも１つ含んでいる。信頼されているエージェントは，専用のソフトウェア・エージェントか，本発明の方法のために，通常の機能が修正されているデジタル権利管理（ＤＲＭ）エージェントか，であり得る。次に，オープン・プラットフォーム領域は，例えば，配信サーバ１１１からダウンロードされ得る複数のアプリケーション２１０
１
〜２１０
Ｎ
を含む。
　
Ｂ．「[0028]　
When the user starts the application, the application communicates (step 1) with the trusted agent
（［００２８］　
ユーザが，アプリケーションを開始すると，アプリケーションは，信頼されているエージェントと通信する（ステップ１）
　
Ｃ．「[0034]　
FIG.5 illustrates one embodiment of the message exchange in the environment of FIG.4. When the application is started, the trusted agent first checks the rights of the application (step 2). If the rights are valid, the trusted agent sends a token request to the authentication server (step 2A) requesting a token for the session that is about to start
In response to the request, the authentication server returns a token to the trusted agent (step 2B)
The token is typically a random number used in digest calculation, i.e. it is different for each request (session) in order to eliminate misuse by replaying messages
When the trusted agent has received the token
However, in the example of FIG.5 the trusted agent modifies the INVITE request by adding a digest, or a digital signature, to the INVITE request at step 8
[0035]　
The INVITE request is then transmitted (step 10) to the call processing server, which now performs an additional authentication step in order to authenticate the application
the call processing server sends an authentication request to the authentication server (step 11). This authentication request includes, in addition to the digest, the subscriber identifier so that the authentication server is able to identify the correct token it previously assigned for this session
 Based on the token found, the authentication server calculates a digest and compares it with the digest received in the authentication request
[0036]　
The digest may be calculated in a standard manner using the same algorithm in the terminal and in the authentication server
（［００３４］　
図５は，図４の環境における，メッセージ交換の１実施例を説明する。アプリケーションが開始されると，信頼されているエージェントが，先ず，アプリケーションの権利を確認する（ステップ２）。もし，権利が正当であれば，信頼されているエージェントは，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する（ステップ２Ａ）
その要求についての応答において，認証サーバは，信頼されているエージェントへ，トークンを返送する（ステップ２Ｂ）
そのトークンは，通常は，例えば，再送メッセージによる悪用を除去するために，それぞれの要求（セッション）について異なっている，ダイジェストの計算において用いられる乱数である
信頼されているエージェントが，トークンを受信したとき
信頼されているエージェントは，INVITEリクエストを，ダイジェスト，或いは，電子署名を加えることで，ステップ８でのINVITEリクエストに修正する
［００３５］　
INVITEリクエストは，次に，アプリケーションを認証するために，すぐに，追加の認証ステップを行う，呼処理サーバに送信される（ステップ１０）
呼処理サーバは，認証サーバに，認証要求を送信する（ステップ１１）
この認証要求は，認証サーバが，このセッションに事前に割り当てた正しいトークンを識別できるために，ダイジェストに加えて加入者識別子を含む
見つけられたトークンに基づいて，認証サーバは，ダイジェストを計算し，それを，認証要求において受け取ったダイジェストと比較する
［００３６］　
ダイジェストは，端末と認証サーバにおいて同じアルゴリズムを用いた，
通常の方法で，計算されるであろう
　
Ｄ．「[0037]　
If the authentication server detects that the digest calculated by it matches the digest received in the authentication request, the application is successfully authenticated
[0038]　The authentication server then returns an authentication response to the call processing server (step 12).
 If the response indicates that the authentication was successful, the call-processing server forwards the INVITE request to the opposite terminal
（［００３７］　
もし，認証サーバが，認証サーバによって計算されたダイジェストと，認証要求において受信したダイジェストとが一致すると判断すると，アプリケーションは，成功裏に認証される
［００３８］　
認証サーバは，次に，認証応答を，呼処理サーバに返送する
もし，応答が，認証は成功だったことを示していれば，呼処理サーバは，相手側である端末に，INVITEリクエストを転送し
　
２．引用文献２について
　原審拒絶査定の拒絶の理由に引用された引用文献２には，次の事項が記載されている。
　
Ｅ．「【００４７】
　図１は，モバイル・スマートカード・リーダを使用してスマートカードを第１のコンピューティング・デバイスに接続することにより，第１のコンピューティング・デバイスを介したコンピュータ・ネットワークへのアクセスを要求し，認証サーバから課題を受信し，応答の第１の部分を認証サーバへ送信する，諸ステップを示す図である。
【００４８】
　設定は，縦の破線によって示されるクライアント／サーバ・インターフェースである。クライアントは，図１には示されていない第１のコンピューティング・デバイス上で実行する。クライアント側は，ユーザ，スマートカード，ブラウザ／アプリケーション，ならびに，データ交換のため，および最終的にはカードリーダのバッテリをロードするために，ＵＳＢ（Universal Serial Bus）ポートを介して第１のコンピューティング・デバイスに接続可能な，カードリーダを備え，サーバ側は，認証サーバを備える。
【００４９】
　第１のステップでは，矢印１によって示されるように，ブラウザ／アプリケーションと認証サーバとの間に，ＳＳＬ（セキュア・ソケット・レイヤ）接続が確立される。ＳＳＬ接続を使用して，たとえば「中間者攻撃（man-in-the-middle-attack）」を避けることができる。
【００５０】
　次のステップでは，ユーザは新しい課題の生成を要求する。この要求は，矢印２によって示されるようにブラウザ／アプリケーションへとアドレス指定され，矢印３によって示されるように認証サーバへと転送される。その後，認証サーバは，１つまたは複数の課題４を生成して格納する。
【００５１】
　さらに次のステップでは，矢印５および６によって示されるように，課題４はブラウザ／アプリケーションを介してカードリーダへと送信される。課題４は，矢印７によって示されるように，カードリーダからスマートカードへと転送される。
【００５２】
　ユーザは，矢印８に従って，カードリーダのＰＩＮパッドにＰＩＮを入力する。ＰＩＮは，矢印９のようにスマートカードに送信される。課題４は，ユーザの秘密認証鍵を使用して暗号化される。暗号化された課題１０は応答と呼ばれ，スマートカード上に生成される。
【００５３】
　スマートカードは，矢印１１に従って応答をカードリーダに送信し，矢印１２および１３のように，応答の第１の部分は，カードリーダからブラウザ／アプリケーションを介して認証サーバへと送信される。応答の第１の部分１４は認証サーバに格納される。」
　
３．引用文献１に記載の発明
（１）上記Ａの「The user of a mobile terminal is thus a subscriber in a mobile communication system, such as the GSM or UMTS system, while the terminal is typically a multimedia phone.（モバイル端末のユーザは，それ故，ＧＳＭ，或いは，ＵＭＴＳシステムといった，モバイル通信システムの加入者であり，さらに，その端末は，通常は，マルチメディア・フォンである。）」という記載，及び，同じく，上記Ａの「FIG.2 is a schematic illustration of one embodiment of a terminal according to the invention. The entities relevant to the invention reside in a tamper resistant area 200 of the terminal or in an open platform area 201. The tamper resistant area includes at least one trusted agent 212, which acts as a controlling entity controlling the rights and behavior of the applications. The trusted agent may be a dedicated software agent or a Digital Rights Management (DRM) agent whose normal functionality has been modified for the method of the invention. The open platform area in turn includes a plurality of applications 210１ to 210Ｎ which may be downloaded from the delivery server 111, for example. （図２は，本発明に従う端末の１実施例の略図である。本発明に関するエンティティは，端末の改ざん耐性領域２００内，或いは，オープン・プラットフォーム領域２０１内に属する。改ざん耐性領域は，アプリケーションの動作と権利とを管理する管理エンティティである信頼されているエージェント２１２を，少なくとも１つ含んでいる。信頼されているエージェントは，専用のソフトウェア・エージェントか，本発明の方法のために，通常の機能が修正されているデジタル権利管理（ＤＲＭ）エージェントか，であり得る。次に，オープン・プラットフォーム領域は，例えば，配信サーバ１１１からダウンロードされ得る，複数のアプリケーション２１０１〜２１０Ｎを含む。）」という記載から，引用文献１においては，
“モバイル通信システムに接続されるモバイル端末が，複数のアプリケーションを含む”ものであることが読み取れる。
　
（２）上記Ｂの「When the user starts the application, the application communicates (step 1) with the trusted agent（ユーザが，アプリケーションを開始すると，アプリケーションは，信頼されているエージェントと通信する（ステップ１））」という記載，及び，上記Ｃの「FIG.5 illustrates one embodiment of the message exchange in the environment of FIG.4. When the application is started, the trusted agent first checks the rights of the application (step 2). If the rights are valid, the trusted agent sends a token request to the authentication server (step 2A) requesting a token for the session that is about to start. （図５は，図４の環境における，メッセージ交換の１実施例を説明する。アプリケーションが開始されると，信頼されているエージェントが，先ず，アプリケーションの権利を確認する（ステップ２）。もし，権利が正当であれば，信頼されているエージェントは，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する（ステップ２Ａ））」という記載から，引用文献１には，
“ユーザが，アプリケーションを開始すると，前記アプリケーションは，信頼されているエージェントと通信し，前記信頼されているエージェントは，前記アプリケーションの権利を確認し，前記権利が正当であれば，前記信頼されているエージェントが，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する，メッセージ交換のための方法”が記載されていることが読み取れる。
　
（３）上記Ｃの「In response to the request, the authentication server returns a token to the trusted agent (step 2B)（その要求についての応答において，認証サーバは，信頼されているエージェントへ，トークンを返送する（ステップ２Ｂ））」という記載，同じく，上記Ｃの「The token is typically a random number used in digest calculation, i.e. it is different for each request (session) in order to eliminate misuse by replaying messages（そのトークンは，通常は，例えば，再送メッセージによる悪用を除去するために，それぞれの要求（セッション）について異なっている，ダイジェストの計算において用いられる乱数である）」という記載，同じく，上記Ｃの「When the trusted agent has received the token（信頼されているエージェントが，トークンを受信したとき）」という記載，同じく，上記Ｃの「However, in the example of FIG.5 the trusted agent modifies the INVITE request by adding a digest, or a digital signature, to the INVITE request at step 8（信頼されているエージェントは，INVITEリクエストを，ダイジェスト，或いは，電子署名を加えることで，ステップ８でのINVITEリクエストに修正する）」という記載，同じく，上記Ｃの「The INVITE request is then transmitted (step 10) to the call processing server, which now performs an additional authentication step in order to authenticate the application（INVITEリクエストは，次に，アプリケーションを認証するために，すぐに，追加の認証ステップを行う，呼処理サーバに送信される（ステップ１０））」という記載，及び，同じく上記Ｃの「the call processing server sends an authentication request to the authentication server (step 11). This authentication request includes, in addition to the digest, the subscriber identifier so that the authentication server is able to identify the correct token it previously assigned for this session（呼処理サーバは，認証サーバに，認証要求を送信する（ステップ１１）。この認証要求は，認証サーバが，このセッションに事前に割り当てた正しいトークンを識別できるために，ダイジェストに加えて加入者識別子を含む）」という記載から，引用文献１においては，
“認証サーバは，信頼されているエージェントへ，ダイジェストの計算において用いられる乱数であるトークンを返送し，前記信頼されているエージェントが，前記トークンを受信したとき，前記信頼されているエージェントは，前記トークンを用いてダイジェストを計算し，前記ダイジェストを含むINVITEリクエストを生成し，前記INVITEリクエストを，アプリケーションを認証するために，呼処理サーバに送信し，前記呼処理サーバは，前記認証サーバに，前記ダイジェストと加入者識別子とを含む認証要求を送信する”ものであることが読み取れる。
　
（４）上記Ｃの「 Based on the token found, the authentication server calculates a digest and compares it with the digest received in the authentication request（見つけられたトークンに基づいて，認証サーバは，ダイジェストを計算し，それを，認証要求において受け取ったダイジェストと比較する）」という記載，同じく，上記Ｃの「The digest may be calculated in a standard manner using the same algorithm in the terminal and in the authentication server（ダイジェストは，端末と認証サーバにおいて同じアルゴリズムを用いた通常の方法で，計算されるであろう）」という記載，上記Ｄの「If the authentication server detects that the digest calculated by it matches the digest received in the authentication request, the application is successfully authenticated（もし，認証サーバが，認証サーバによって計算されたダイジェストと，認証要求において受信したダイジェストとが一致すると判断すると，アプリケーションは，成功裏に認証された）」という記載，及び，同じく，上記Ｄの「The authentication server then returns an authentication response to the call processing server（認証サーバは，次に，認証応答を，呼処理サーバに返送する）」という記載，及び，同じく，上記Ｄの「If the response indicates that the authentication was successful, the call-processing server forwards the INVITE request to the opposite terminal（もし，応答が，認証は成功だったことを示していれば，呼処理サーバは，相手側である端末に，INVITEリクエストを転送し）」という記載において，「見つけられたトークン」とは，「認証サーバ」が，「信頼されているエージェント」に送信した「トークン」のことであるから，上記において引用した記載から，引用文献１においては，
“認証サーバは，信頼されているエージェントに送信したトークンを用い，端末と同じアルゴリズムを用いてダイジェストを計算し，得られたダイジェストと，認証要求に含まれるダイジェストを比較し，前記得られたダイジェストと，認証要求において受信したダイジェストとが一致した場合，認証が成功したとして，認証の成功を示す認証応答を，呼処理サーバに返送し，前記呼処理サーバは，前記認証の成功を示す認証応答を受信した場合に，相手側である端末に，INVITEリクエストを転送する”ものであることが読み取れる。
　
（５）以上，上記（１）〜上記（４）において検討した事項から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「モバイル通信システムに接続されるモバイル端末が，複数のアプリケーションを含み，ユーザが，前記アプリケーションを開始すると，
　前記アプリケーションは，信頼されているエージェントと通信し，
　前記信頼されているエージェントは，前記アプリケーションの権利を確認し，
　前記権利が正当であれば，前記信頼されているエージェントが，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する，
　メッセージ交換のための方法であって，
　前記認証サーバは，信頼されているエージェントへ，ダイジェストの計算において用いられる乱数であるトークンを返送し，
　前記信頼されているエージェントが，前記トークンを受信したとき，
　前記信頼されているエージェントは，
　前記トークンを用いてダイジェストを計算し，
　前記ダイジェストを含むINVITEリクエストを生成し，
　前記INVITEリクエストを，アプリケーションを認証するために，呼処理サーバに送信し，
　前記呼処理サーバは，前記認証サーバに，前記ダイジェストと加入者識別子とを含む認証要求を送信し，
　前記認証サーバは，信頼されているエージェントに送信したトークンを用い，端末と同じアルゴリズムを用いてダイジェストを計算し，
　得られたダイジェストと，認証要求に含まれるダイジェストを比較し，
　前記得られたダイジェストと，認証要求において受信したダイジェストとが一致した場合，認証が成功したとして，認証の成功を示す認証応答を，前記呼処理サーバに返送し，
　前記呼処理サーバは，前記認証の成功を示す認証応答を受信した場合に，相手側である端末に，INVITEリクエストを転送する，方法。」
　
第５．本願発明と引用発明との対比及び相違点についての判断
１．本願発明１と引用発明との対比
（１）引用発明における「モバイル通信システム」は，データを通信するネットワークを構成するものであるから，引用発明における「モバイル通信システム」が，
　本願発明１における「ネットワーク」に相当し，
　引用発明において，「モバイル端末」は，「アプリケーション」を含むものであるから，
　本願発明１における「装置」，及び，「クライアント装置」に相当し，
　引用発明における「トークン」は，「乱数」であるから，
　本願発明１における「チャレンジデータ」と，“計算に使用されるデータ”である点で共通し，
　引用発明における「ダイジェスト」と，
　本願発明１における「プライベートデータの難読化バージョン」は，“計算によって得られるデータ”である点で共通し，
　引用発明における「信頼されているエージェント」は，「トークン」を用いて，「ダイジェスト」の計算を行っているので，
　引用発明における「信頼されているエージェント」と
　本願発明１における「信頼された情報マネージャ」とは，
“計算によって得られるデータを計算する手段”である点で共通し，
　引用発明における「認証サーバ」は，「トークン」を，「信頼されているエージェント」に送信し，
　引用発明における「呼処理サーバ」は，「信頼されているエージェント」から，「ダイジェスト」を含む「INVITEリクエスト」を受信していて，
「認証サーバ」と，「呼処理サーバ」は，「信頼されているエージェント」との間で「トークン」と，「ダイジェスト」の授受を行っているので，
　引用発明における「認証サーバ」及び「呼処理サーバ」と，
　本願発明１における「サービングノード」とは，“要求先”である点で共通する。
　
（２）引用発明における「トークン・リクエストを，認証サーバに送信する」ことは，「メッセージ交換」に関するものであって，「メッセージ交換」は，「データの交換」の一種であるから，上記（１）において検討した事項を踏まえると，
　引用発明における「モバイル通信システムに接続されるモバイル端末が，複数のアプリケーションを含み，ユーザが，前記アプリケーションを開始すると，
　前記アプリケーションは，信頼されているエージェントと通信し，
　前記信頼されているエージェントは，前記アプリケーションの権利を確認し，
　前記権利が正当であれば，前記信頼されているエージェントが，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する，
　メッセージ交換のための方法」と，
　本願発明１における「データネットワークにおいて，装置（１００；２００）上で，または装置（１００；２００）用に実行するアプリケーション（１０３；２０３）とサービングノードとの間での，クライアント装置（１００；２００）に関連するプライベートデータの交換を制御するための方法」とは，
“データネットワークおいて，アプリケーションが実行される装置と，要求先との間での，データの交換を制御するための方法”である点で共通する。
　
（３）上記（１）において検討したとおり，引用発明における「信頼されているエージェント」は，本願発明１における「信頼された情報マネージャ」と，“計算によって得られるデータを計算する手段”である点で共通するものであるが，
引用発明において，「信頼されているエージェントは，前記アプリケーションの権利を確認し，前記権利が正当であれば，前記信頼されているエージェントが，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する」ことは，「信頼されているエージェント」が，“要求元”として，「トークン・リクエスト」を，“要求先”である「認証サーバ」に送信することであるから，
　引用発明における「信頼されているエージェントは，前記アプリケーションの権利を確認し，前記権利が正当であれば，前記信頼されているエージェントが，開始についてのセッションのためのトークンを要求するトークン・リクエストを，認証サーバに送信する」ことと，
　本願発明１における「プライベートデータの使用を要求するサービス（１０５；２０５）へのアクセスのためのリクエストを，アプリケーション（１０３；２０３）から，サービングノードに送信するステップ」とは，
“要求元から，要求先へ，リクエストを送信するステップ”である点で共通する。
　
（４）引用発明における「信頼されているエージェントが，前記トークンを受信したとき」と，
　本願発明１における「サービングノードからのチャレンジデータ（１０７）を，アプリケーション（１０３；２０３）で受信するステップ（３）」とは，
“要求先から，計算に使用されるデータを受信するステップ”である点で共通する。
　
（５）引用発明における「信頼されているエージェントは，前記トークンを用いてダイジェストを計算し，前記ダイジェストを含むINVITEリクエストを生成し，前記INVITEリクエストを，アプリケーションを認証するために，呼処理サーバに送信し」と，
　本願発明１における「チャレンジデータ（１０７）に基づき，クライアント装置（１００；２００）のセキュアユーザインタフェース（１１１；２１３）を使用して，信頼された情報マネージャ（１０９；２０７）に，プライベートデータの使用に対する認可を要求するステップ（５）と，
　アプリケーション（１０３；２０３）が，プライベートデータの知識を得ることができないように，認可に基づいて，サービス（１０５；２０５）で使用されるプライベートデータの難読化バージョン（１１３）を，信頼された情報マネージャ（１０９；２０７）からアプリケーション（１０３；２０３）を介して，サービングノードに送信するステップ」とは，
“計算に使用されるデータに基づき，計算によって得られるデータを，計算によって得られるデータを計算する手段から，要求先に送信するステップ”である点で共通する。
　
（６）以上，上記（１）〜（５）において検討した事項から，本願発明１と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　データネットワークおいて，アプリケーションが実行される装置と，要求先との間での，データの交換を制御するための方法であって，
　要求元から，前記要求先へ，リクエストを送信するステップと，
　前記要求先から，計算に使用されるデータを受信するステップと，
　前記計算に使用されるデータに基づき，計算によって得られるデータを，計算によって得られるデータを計算する手段から，前記要求先に送信するステップと
　を含む方法。
　
［相違点１］
“アプリケーションが実行される装置と，要求先との間での，データの交換を制御するための方法”に関して，
　本願発明１においては，「要求先」が，「サービングノード」であり，「装置（１００；２００）上で，または装置（１００；２００）用に実行するアプリケーション（１０３；２０３）とサービングノードとの間での，クライアント装置（１００；２００）に関連するプライベートデータの交換を制御するための方法」であるのに対して，
　引用発明においては，「アプリケーション」と，「サービングノード」との間での「クライアント装置」に関連する「プライベートデータの交換を制御する」ことに関する言及がない点。
　
［相違点２］
“要求元から，前記要求先へ，リクエストを送信する”ことに関して，
　本願発明１においては，「要求元」は，「アプリケーション」であり，「リクエスト」が，「プライベートデータの使用を要求するサービス（１０５；２０５）へのアクセスのためのリクエスト」であるのに対して，
　引用発明においては，「要求元」は，「信頼されているエージェント」であり，「リクエスト」が，「開始についてのセッションのためのトークンを要求するトークン・リクエスト」である点。
　
［相違点３］
“要求先から，計算に使用されるデータを受信するステップ”に関して，
　本願発明１においては，「受信する」のが，「アプリケーション」であり，「計算に使用されるデータ」が，「チャレンジデータ」であるのに対して，
　引用発明においては，「受信する」のが，「信頼されているエージェント」であり，「計算に使用されるデータ」が，「ダイジェスト」を生成するための「トークン」である点。
　
［相違点４］
　本願発明１においては，「チャレンジデータ（１０７）に基づき，クライアント装置（１００；２００）のセキュアユーザインタフェース（１１１；２１３）を使用して，信頼された情報マネージャ（１０９；２０７）に，プライベートデータの使用に対する認可を要求するステップ」が存在するのに対して，
　引用発明においては，そのような「ステップ」が存在しない点。
　
［相違点５］
“計算によって得られるデータを，計算によって得られるデータを計算する手段から，前記要求先に送信する”ことに関して，
　本願発明１においては，「アプリケーション（１０３；２０３）が，プライベートデータの知識を得ることができないように，認可に基づいて，サービス（１０５；２０５）で使用されるプライベートデータの難読化バージョン（１１３）を，信頼された情報マネージャ（１０９；２０７）からアプリケーション（１０３；２０３）を介して，サービングノードに送信する」ものであるのに対して，
　引用発明においては，“アプリケーションが，プライベートデータの知識を得ることができないように，認可に基づいて，サービスで使用されるプライベートデータの難読化バージョンを，信頼された情報マネージャからアプリケーションを介して，サービングノードに送信する”ことは行っていない点。
　
２．本願発明１と引用発明との相違点についての判断
　事案に鑑みて，先に，［相違点５］について検討すると，上記Ｅに引用した，引用文献２の記載には，「課題」に関する記載が存在するが，当該「課題」が，「プライベートデータ」であることは，引用文献２の全ての記載内容を検討しても読み取れない。
　したがって，［相違点５］に係る本願発明１における“アプリケーションが，プライベートデータの知識を得ることができないように，認可に基づいて，サービスで使用されるプライベートデータの難読化バージョンを，信頼された情報マネージャからアプリケーションを介して，サービングノードに送信する”という構成は，引用文献１，及び，引用文献２には記載されておらず，本願の第１国出願前に周知技術であったともいえない。
　以上のとおりであるから，他の相違点を検討するまでもなく，当業者であっても，引用発明，及び，引用文献２に記載の技術事項に基づいて，容易に発明できたものであるとはいえない。
　
３．本願発明２〜本願発明１５について
（１）本願発明２〜本願発明８に関して
　本願の請求項２〜本願の請求項８は，本願の請求項１を直接・間接に引用するものであるから，本願発明２〜本願発明８は，本願発明１の構成を内包している。
　よって，上記２．において検討したとおり，本願発明２〜本願発明８は，引用発明，及び，引用文献２に記載の技術事項に基づいて，容易に発明できたものであるとはいえない。
　
（２）本願発明９〜本願発明１１に関して
　本願発明９は，方法の発明である本願発明１を，システムの発明としたものであるから，カテゴリが相違するものの，本願発明１と，ほぼ同等の構成を有しており，本願の請求項１０，及び，本願の請求項１１は，本願の請求項９を直接・間接に引用するものであるから，本願発明１０，及び，本願発明１１は，本願発明９の構成を内包している。
　よって，上記２．において検討したとおり，本願発明９〜本願発明１１は，引用発明，及び，引用文献２に記載の技術事項に基づいて，容易に発明できたものであるとはいえない。
　
（３）本願発明１２〜本願発明１４に関して
　本願発明１２は，「信頼された情報マネージャ」に関する発明であって，上記２．において検討した［相違点５］に係る構成を有するものであり，本願の請求項１３，及び，本願の請求項１４は，本願の請求項１２を直接・間接に引用するものであるから，本願発明１３，及び，本願発明１４は，本願発明１２の構成を内包している。
　よって，上記２．において検討したとおり，本願発明１２〜本願発明１４は，引用発明，及び，引用文献２に記載の技術事項に基づいて，容易に発明できたものであるとはいえない。
　
（４）本願発明１５に関して
　本願の請求項１５は，本願の請求項１〜本願の請求項８の何れか一項を引用するものであるから，本願発明１５は，本願発明１の構成を内包している。
　よって，上記２．において検討したとおり，本願発明１５は，引用発明，及び，引用文献２に記載の技術事項に基づいて，容易に発明できたものであるとはいえない。
　
第６．原査定についての判断
　本願発明１〜本願発明１５は，上記「第５．本願発明と引用発明との対比及び相違点についての判断」における「２．本願発明１と引用発明との相違点についての判断」において検討した［相違点５］に係る構成を有するものであるから，当業者であっても，原審拒絶査定の拒絶の理由に引用された引用文献１，及び，引用文献２に基づいて，容易に発明できたものとはいえない。したがって，原査定の理由を維持することはできない。
　
第７．むすび
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。