• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1353846
審判番号 不服2018-6258  
総通号数 237 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-09-27 
種別 拒絶査定不服の審決 
審判請求日 2018-05-08 
確定日 2019-08-20 
事件の表示 特願2016-541835「プライバシー機密情報の交換を制御するための方法およびシステム」拒絶査定不服審判事件〔平成27年 3月19日国際公開,WO2015/036087,平成28年10月 6日国内公表,特表2016-531528,請求項の数(15)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1.手続の経緯
本願は,2014年8月18日(パリ条約による優先権主張外国庁受理2013年9月13日 欧州特許庁)を国際出願日とする出願であって,
平成28年4月14日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成29年4月28日付けで審査官により拒絶理由が通知され,これに対して平成29年7月12日付けで意見書が提出されると共に手続補正がなされたが,平成29年12月21日付けで審査官により拒絶査定がなされ(謄本送達;平成30年1月9日),これに対して平成30年5月8日付けで審判請求がなされたものである。

第2.原査定の概要
原審における平成29年12月21日付けの拒絶査定(以下,これを「原審拒絶査定」という)は,概略,以下のとおりである。
「備考
・請求項 1-15
・引用文献等 1,2
引用文献1には,アプリケーションを開始すると,そのアプリケーションが信頼されたエージェントと通信し(段落[0028]),信頼されたエージェントが,開始しようとするセッションのためのトークン要求を認証サーバに送信すると,認証サーバが,トークンを信頼されたエージェントに返送し,ここでトークンはダイジェストの計算に用いられる乱数であり,信頼されたエージェントが,INVITE要求を,ダイジェストを付加することにより変更し,ダイジェストは,秘密鍵とトークンとを用いて計算され,INVITE要求は,呼処理サーバに送信され,アプリケーションを認証するために,認証処理が実行され,そのために,呼処理サーバは認証要求を認証サーバに送信し,認証要求はダイジェストを含み,認証サーバが,算出したダイジェストが認証要求において受信したダイジェストが一致することを検出した場合,アプリケーションが認証され,認証サーバが呼処理サーバに認証応答を返し,その応答が認証成功を示す場合,呼処理サーバは,INVITE要求を他の端末へ転送し,セッションの料金記録を生成する(段落[0034]-[0038]),ことが記載されている。
引用文献1に記載された発明において,アプリケーションが信頼されたエージェントと通信し,信頼されたエージェントが,開始しようとするセッションのためのトークン要求を認証サーバに送信することは,その結果,呼処理サーバが,INVITE要求を他の端末へ転送し,セッションの料金記録を生成することから,補正後の請求項1に記載された発明の「プライベートデータの使用を要求するサービス(105;205)へのアクセスのためのリクエストを,アプリケーション(103;203)から,サービングノードに送信するステップ」に相当
する。
してみれば,補正後の請求項1に係る発明と引用文献1に記載された発明とは,上記拒絶理由通知書において述べた相違点(a)及び(b)にて相違し,それ以外の点で一致する。そして,それら相違点については,上記拒絶理由通知書において述べたと同様,引用文献2に記載の技術を参酌することで,当業者が容易になし得たことである。
したがって,補正後の請求項1に係る発明は依然として,引用文献1に記載された発明及び引用文献2に記載の技術に基づいて当業者が容易に想到し得たものであるから,特許法第29条第2項の規定により特許を受けることができない。
請求項2-15に係る発明についても同様のことがいえる。
なお出願人は意見書において「引用文献2の記載にしたがって,引用文献1の上記実施形態が,ダイジェストまたはデジタル署名をINVITE要求に加えることによって修正されたINVITE要求が,信頼されたエージェントの代わりにアプリケーションからSIPプロトコルスタックに送信されるように修正された場合,信頼されたエージェントは,修正されたINVITE要求をアプリケーションに戻す必要があり,結果として,信頼されたエージェントからアプリケーションへの余分のステップを生じさせることになる。
したがって,当業者は,あえて,引用文献1を引用文献2と組み合わせようとはしない。」と主張している。
しかしながら,引用文献1に記載された発明は,認証情報であるダイジェストを,INVITE要求という,SIPプロトコルにて送信することから,SIPプロトコルスタックにより,その送信を行うものであるところ,認証情報を如何なるプロコトルにて送信するかは,当業者の設計的事項にすぎず,認証情報を,アプリケーションが処理するプロトコルにて送信することも,本願出願前に一般に行われていたことである。事実,引用文献2に記載の技術は,認証情報である応答を,ブラウザ/アプリケーションを介して送信するものであるから,認証情報を,アプリケーションが処理するプロトコルにて送信するものである。
そうすると,引用文献1に記載された発明では,信頼されたエージェントが,ダイジェストをSIPプロトコルスタックに転送し,SIPプロトコルスタックがダイジェストを呼処理サーバに送信するのに対して,引用文献1に記載された発明を,引用文献2に記載の技術を考慮して修正すれば,信頼されたエージェントが,ダイジェストをアプリケーションに転送し,アプリケーションがダイジェストを呼処理サーバに送信することになる。これらは,信頼されたエージェントから呼処理サーバへダイジェストを送信するにあたり,SIPプロトコルスタックを経由するかアプリケーションを経由するかが異なるにすぎず,修正することにより,出願人が主張する「余分なステップ」が生じることはない。
・・・・(中略)・・・・
＜引用文献等一覧＞
1.米国特許出願公開第2005/0135388号明細書
2.特表2011-507060号公報」

第3.本願発明について
本願の請求項1?本願の請求項15に係る発明(以下,これを「本願発明1?本願発明15」という)は,平成29年7月12日付けの手続補正により補正された特許請求の範囲の請求項1?請求項15に記載された事項により特定されるものであり,そのうち,本願発明1は,次のとおりのものである。

「【請求項1】
データネットワークにおいて,装置(100;200)上で,または装置(100;200)用に実行するアプリケーション(103;203)とサービングノードとの間での,クライアント装置(100;200)に関連するプライベートデータの交換を制御するための方法であって,
プライベートデータの使用を要求するサービス(105;205)へのアクセスのためのリクエストを,アプリケーション(103;203)から,サービングノードに送信するステップ(1)と,
サービングノードからのチャレンジデータ(107)を,アプリケーション(103;203)で受信するステップ(3)と,
チャレンジデータ(107)に基づき,クライアント装置(100;200)のセキュアユーザインタフェース(111;213)を使用して,信頼された情報マネージャ(109;207)に,プライベートデータの使用に対する認可を要求するステップ(5)と,
アプリケーション(103;203)が,プライベートデータの知識を得ることができないように,認可に基づいて,サービス(105;205)で使用されるプライベートデータの難読化バージョン(113)を,信頼された情報マネージャ(109;207)からアプリケーション(103;203)を介して,サービングノードに送信するステップ(6)と
を含む,方法。」

第4.引用文献に記載の事項及び引用文献に記載の発明
1.引用文献1について
原審拒絶査定の拒絶の理由に引用された引用文献1には,次の事項が記載されている。

A.「[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. A delivery server 111, from which applications may be downloaded to the mobile terminals is connected to the GPRS network, either directly or through another packet network, such as the Internet.
[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_(1) to 210_(N) which may be downloaded from the delivery server 111, for example. The applications access the network through a protocol stack 220, which is a Session Initiation Protocol (SIP) stack in this environment. The tamper resistant area may further include an application repository 211 that includes identifiers of applications that need to be controlled by the trusted agent 212. The arrows provided with underlined numbers 1-10 present the cooperation of the different terminal entities when an authorized application residing in the terminal is started.」
([0024] 図1は,本発明が適用され得る,一般的な通信環境の例を示す。その通信環境は,3GPPによって適宜なされるものとして,IMSアーキテクチャ上に基礎をおくものである。それ故,ここでは,呼処理サーバ110が,IMSアーキテクチャに従う呼状態制御関数(CSCF)を含むことと,それが,メディア・サービスの提供のために必要とされる,自宅加入者サーバ(HSS)112のような,コア・ネットワーク・エレメントに接続されることを仮定する。HSSは,与えられたユーザのためのマスタ・データベースを含む。独立した請求システム(図示せず)のための請求データを生成もする呼処理サーバは,一般のパケット無線通信サービス(GPRS)ネットワーク104に接続されている。GPRSネットワークは,更に,無線通信インタフェースを介して,モバイル端末100が通信するところの,多数のベース・ステーション102を包含する,無線通信アクセス・ネットワーク(RAN)103に接続されている。モバイル端末のユーザは,それ故,GSM,或いは,UMTSシステムといった,モバイル通信システムの加入者であり,さらに,その端末は,通常は,マルチメディア・フォンである。そこからモバイル端末へ,アプリケーションがダウンロード可能な,配信サーバ111は,直接,或いは,インターネットのような,他のパケット・ネットワークを介して,GPRSネットワークに接続されている。
[0025] 図2は,本発明に従う端末の1実施例の略図である。本発明に関するエンティティは,端末の改ざん耐性領域200内,或いは,オープン・プラットフォーム領域201内に属する。改ざん耐性領域は,アプリケーションの動作と権利とを管理する管理エンティティである信頼されているエージェント212を,少なくとも1つ含んでいる。信頼されているエージェントは,専用のソフトウェア・エージェントか,本発明の方法のために,通常の機能が修正されているデジタル権利管理(DRM)エージェントか,であり得る。次に,オープン・プラットフォーム領域は,例えば,配信サーバ111からダウンロードされ得る複数のアプリケーション210_(1)?210_(N)を含む。アプリケーションは,この実施例において,セッション開始プロトコル(SIP)スタックであるプロトコル・スタック220を介して,ネットワークにアクセスする。改ざん耐性領域は,更に,信頼されているエージェント212によって制御されるために必要であるアプリケーションの識別子を含む。下線を附された1-10の数字とともに与えられる矢印は,その端末に属している許可されたアプリケーションが開始されると,異なる端末エンティティの連携を提示する。<当審にて訳出。以下,同じ。>)

B.「[0028] When the user starts the application, the application communicates (step 1) with the trusted agent. The trusted agent checks (step 2) the rights of the application and allows the decryption of the application if it detects that the application is legally downloaded from the delivery server or is otherwise legally acquired. The checking of the rights and the decryption of the application is normally handled by the DRM agent, so if there is a separate trusted agent in addition to a normal DRM agent, these steps may be handled by the DRM agent.」
([0028] ユーザが,アプリケーションを開始すると,アプリケーションは,信頼されているエージェントと通信する(ステップ1)。信頼されているエージェントは,アプリケーションの権利をチェックし(ステップ2),もし,アプリケーションが,配信サーバから合法的にダウンロードされている,或いは,さもなければ,合法的に取得されていることが判明すれば,アプリケーションの復号を許可する。権利のチェックと,アプリケーションの復号は,通常,DRMエージェントによって扱われる。それ故,もし,DRMエージェントに加えて,別々になった信頼されているエージェントがあれば,これらのステップは,DRMエージェントによって,扱われ得る。)

C.「[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 request may include, for example, the subscriber identifier in question so that the authentication server will be able to associate a subsequent authentication request with the correct token. 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, the application control continues as discussed in connection with FIGS.2 and 3. Reference numeral 230 in FIG.5 refers to the block marked with the same reference numeral in FIG.3. 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. In other words, in the embodiment of FIG.5 the control data shown in the modified INVITE request of FIG.3 includes a digest.
[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. For this purpose, 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. The authentication request may also include the whole INVITE request (including the subscriber identifier). Based on the token found, the authentication server calculates a digest and compares it with the digest received in the authentication request. The token may also be transmitted to the authentication server, whereby no other search keys are needed for identifying the correct token in the authentication server.
[0036] The digest may be calculated in a standard manner using the same algorithm in the terminal and in the authentication server and using a secret key, the token, and possibly also other predetermined data, such as the subscriber identifier, as the input data for the algorithm, which then outputs the digest. The secret key may be a symmetric key (shared secret) or the private key of the trusted agent. In the latter case the authentication server uses the public key of the trusted agent. The algorithm used may be the MD5 or the SHA-1, for example. As discussed below, the secret key may received in connection with each application download (the key in the rights module), or a key stored permanently in the tamper resistant area may be used for the authentication of the applications.」
([0034] 図5は,図4の環境における,メッセージ交換の1実施例を説明する。アプリケーションが開始されると,信頼されているエージェントが,先ず,アプリケーションの権利を確認する(ステップ2)。もし,権利が正当であれば,信頼されているエージェントは,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する(ステップ2A)。その要求についての応答において,認証サーバは,信頼されているエージェントへ,トークンを返送する(ステップ2B)。そのトークン・リクエストは,例えば,認証サーバが,正しいトークンを,次の認証要求と関連付けることが可能となるように,問題になっている加入者識別子を含み得る。そのトークンは,通常は,例えば,再送メッセージによる悪用を除去するために,それぞれの要求(セッション)について異なっている,ダイジェストの計算において用いられる乱数である。信頼されているエージェントが,トークンを受信したとき,アプリケーション制御は,図2,及び,図3による接続についての説明のように続く。図5における参照数字230は,図3における同一の参照数字が付けられているブロックを引用する。しかしながら,図5の例においては,信頼されているエージェントは,INVITEリクエストを,ダイジェスト,或いは,電子署名を加えることで,ステップ8でのINVITEリクエストに修正する。言い換えると,図5の実施例において,図3の修正されたINVITEリクエストにおいて示される制御データは,ダイジェストを含んでいる。
[0035] INVITEリクエストは,次に,アプリケーションを認証するために,すぐに,追加の認証ステップを行う,呼処理サーバに送信される(ステップ10)。この目的のために,呼処理サーバは,認証サーバに,認証要求を送信する(ステップ11)。この認証要求は,認証サーバが,このセッションに事前に割り当てた正しいトークンを識別できるために,ダイジェストに加えて加入者識別子を含む。認証要求は,また,(加入者識別子を含むところの)全てのINVITEリクエストを含み得る。見つけられたトークンに基づいて,認証サーバは,ダイジェストを計算し,それを,認証要求において受け取ったダイジェストと比較する。そのトークンは,また,認証サーバへ送信され得るが,それによって,その認証サーバにおいて,正しいトークンを識別することのために何らの検索キーも必要としない。
[0036] ダイジェストは,端末と認証サーバにおいて同じアルゴリズムを用いた,そして,秘密鍵,トークン,及び,或いは同様の,その結果,ダイジェストを出力する,アルゴリズムのための入力データとしての予め定められたデータを用いた,通常の方法で,計算されるであろう。秘密鍵は,対称鍵(共有された秘密),或いは,信頼されているエージェントの個別鍵であり得る。後者の場合,認証サーバは,信頼されているエージェントの公開鍵を使用する。用いられるアルゴリズムは,例えば,MD5,或いは,SHA-1であり得る。以下に考察するように,秘密鍵は,各アプリケーションのダウンロードに関連して受信されてもよく(権利モジュール内の鍵),或いは,改ざん耐性領域内に恒久的に格納されている鍵が,アプリケーションの認証のために用いられてもよい。)

D.「[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. In other words, the authentication server can be sure that the application is controlled by the trusted agent in the terminal, and therefore no misuse is possible in the terminal.
[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 (step 13) and generates a charging record for the session. However, if the authentication did not succeed, the call processing server sends an error message to the terminal.」
([0037] もし,認証サーバが,認証サーバによって計算されたダイジェストと,認証要求において受信したダイジェストとが一致すると判断すると,アプリケーションは,成功裏に認証される。言い換えると,認証サーバは,端末において信頼されているエージェントによって,アプリケーションが制御され,それによって,端末において,何らの悪用も不可能であることを確信することができる。
[0038] 認証サーバは,次に,認証応答を,呼処理サーバに返送する(ステップ12)。もし,応答が,認証は成功だったことを示していれば,呼処理サーバは,相手側である端末に,INVITEリクエストを転送し(ステップ13),セッションのための課金記録を作成する。しかしながら,もし,認証が失敗であれば,呼処理サーバは,端末に,エラー・メッセージを送信する。)

2.引用文献2について
原審拒絶査定の拒絶の理由に引用された引用文献2には,次の事項が記載されている。

E.「【0047】
図1は,モバイル・スマートカード・リーダを使用してスマートカードを第1のコンピューティング・デバイスに接続することにより,第1のコンピューティング・デバイスを介したコンピュータ・ネットワークへのアクセスを要求し,認証サーバから課題を受信し,応答の第1の部分を認証サーバへ送信する,諸ステップを示す図である。
【0048】
設定は,縦の破線によって示されるクライアント/サーバ・インターフェースである。クライアントは,図1には示されていない第1のコンピューティング・デバイス上で実行する。クライアント側は,ユーザ,スマートカード,ブラウザ/アプリケーション,ならびに,データ交換のため,および最終的にはカードリーダのバッテリをロードするために,USB(Universal Serial Bus)ポートを介して第1のコンピューティング・デバイスに接続可能な,カードリーダを備え,サーバ側は,認証サーバを備える。
【0049】
第1のステップでは,矢印1によって示されるように,ブラウザ/アプリケーションと認証サーバとの間に,SSL(セキュア・ソケット・レイヤ)接続が確立される。SSL接続を使用して,たとえば「中間者攻撃(man-in-the-middle-attack)」を避けることができる。
【0050】
次のステップでは,ユーザは新しい課題の生成を要求する。この要求は,矢印2によって示されるようにブラウザ/アプリケーションへとアドレス指定され,矢印3によって示されるように認証サーバへと転送される。その後,認証サーバは,1つまたは複数の課題4を生成して格納する。
【0051】
さらに次のステップでは,矢印5および6によって示されるように,課題4はブラウザ/アプリケーションを介してカードリーダへと送信される。課題4は,矢印7によって示されるように,カードリーダからスマートカードへと転送される。
【0052】
ユーザは,矢印8に従って,カードリーダのPINパッドにPINを入力する。PINは,矢印9のようにスマートカードに送信される。課題4は,ユーザの秘密認証鍵を使用して暗号化される。暗号化された課題10は応答と呼ばれ,スマートカード上に生成される。
【0053】
スマートカードは,矢印11に従って応答をカードリーダに送信し,矢印12および13のように,応答の第1の部分は,カードリーダからブラウザ/アプリケーションを介して認証サーバへと送信される。応答の第1の部分14は認証サーバに格納される。」

3.引用文献1に記載の発明
(1)上記Aの「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.(モバイル端末のユーザは,それ故,GSM,或いは,UMTSシステムといった,モバイル通信システムの加入者であり,さらに,その端末は,通常は,マルチメディア・フォンである。)」という記載,及び,同じく,上記Aの「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_(1) to 210_(N) which may be downloaded from the delivery server 111, for example. (図2は,本発明に従う端末の1実施例の略図である。本発明に関するエンティティは,端末の改ざん耐性領域200内,或いは,オープン・プラットフォーム領域201内に属する。改ざん耐性領域は,アプリケーションの動作と権利とを管理する管理エンティティである信頼されているエージェント212を,少なくとも1つ含んでいる。信頼されているエージェントは,専用のソフトウェア・エージェントか,本発明の方法のために,通常の機能が修正されているデジタル権利管理(DRM)エージェントか,であり得る。次に,オープン・プラットフォーム領域は,例えば,配信サーバ111からダウンロードされ得る,複数のアプリケーション210_(1)?210_(N)を含む。)」という記載から,引用文献1においては,
“モバイル通信システムに接続されるモバイル端末が,複数のアプリケーションを含む”ものであることが読み取れる。

(2)上記Bの「When the user starts the application, the application communicates (step 1) with the trusted agent(ユーザが,アプリケーションを開始すると,アプリケーションは,信頼されているエージェントと通信する(ステップ1))」という記載,及び,上記Cの「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. (図5は,図4の環境における,メッセージ交換の1実施例を説明する。アプリケーションが開始されると,信頼されているエージェントが,先ず,アプリケーションの権利を確認する(ステップ2)。もし,権利が正当であれば,信頼されているエージェントは,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する(ステップ2A))」という記載から,引用文献1には,
“ユーザが,アプリケーションを開始すると,前記アプリケーションは,信頼されているエージェントと通信し,前記信頼されているエージェントは,前記アプリケーションの権利を確認し,前記権利が正当であれば,前記信頼されているエージェントが,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する,メッセージ交換のための方法”が記載されていることが読み取れる。

(3)上記Cの「In response to the request, the authentication server returns a token to the trusted agent (step 2B)(その要求についての応答において,認証サーバは,信頼されているエージェントへ,トークンを返送する(ステップ2B))」という記載,同じく,上記Cの「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(そのトークンは,通常は,例えば,再送メッセージによる悪用を除去するために,それぞれの要求(セッション)について異なっている,ダイジェストの計算において用いられる乱数である)」という記載,同じく,上記Cの「When the trusted agent has received the token(信頼されているエージェントが,トークンを受信したとき)」という記載,同じく,上記Cの「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リクエストを,ダイジェスト,或いは,電子署名を加えることで,ステップ8でのINVITEリクエストに修正する)」という記載,同じく,上記Cの「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リクエストは,次に,アプリケーションを認証するために,すぐに,追加の認証ステップを行う,呼処理サーバに送信される(ステップ10))」という記載,及び,同じく上記Cの「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(呼処理サーバは,認証サーバに,認証要求を送信する(ステップ11)。この認証要求は,認証サーバが,このセッションに事前に割り当てた正しいトークンを識別できるために,ダイジェストに加えて加入者識別子を含む)」という記載から,引用文献1においては,
“認証サーバは,信頼されているエージェントへ,ダイジェストの計算において用いられる乱数であるトークンを返送し,前記信頼されているエージェントが,前記トークンを受信したとき,前記信頼されているエージェントは,前記トークンを用いてダイジェストを計算し,前記ダイジェストを含むINVITEリクエストを生成し,前記INVITEリクエストを,アプリケーションを認証するために,呼処理サーバに送信し,前記呼処理サーバは,前記認証サーバに,前記ダイジェストと加入者識別子とを含む認証要求を送信する”ものであることが読み取れる。

(4)上記Cの「 Based on the token found, the authentication server calculates a digest and compares it with the digest received in the authentication request(見つけられたトークンに基づいて,認証サーバは,ダイジェストを計算し,それを,認証要求において受け取ったダイジェストと比較する)」という記載,同じく,上記Cの「The digest may be calculated in a standard manner using the same algorithm in the terminal and in the authentication server(ダイジェストは,端末と認証サーバにおいて同じアルゴリズムを用いた通常の方法で,計算されるであろう)」という記載,上記Dの「If the authentication server detects that the digest calculated by it matches the digest received in the authentication request, the application is successfully authenticated(もし,認証サーバが,認証サーバによって計算されたダイジェストと,認証要求において受信したダイジェストとが一致すると判断すると,アプリケーションは,成功裏に認証された)」という記載,及び,同じく,上記Dの「The authentication server then returns an authentication response to the call processing server(認証サーバは,次に,認証応答を,呼処理サーバに返送する)」という記載,及び,同じく,上記Dの「If the response indicates that the authentication was successful, the call-processing server forwards the INVITE request to the opposite terminal(もし,応答が,認証は成功だったことを示していれば,呼処理サーバは,相手側である端末に,INVITEリクエストを転送し)」という記載において,「見つけられたトークン」とは,「認証サーバ」が,「信頼されているエージェント」に送信した「トークン」のことであるから,上記において引用した記載から,引用文献1においては,
“認証サーバは,信頼されているエージェントに送信したトークンを用い,端末と同じアルゴリズムを用いてダイジェストを計算し,得られたダイジェストと,認証要求に含まれるダイジェストを比較し,前記得られたダイジェストと,認証要求において受信したダイジェストとが一致した場合,認証が成功したとして,認証の成功を示す認証応答を,呼処理サーバに返送し,前記呼処理サーバは,前記認証の成功を示す認証応答を受信した場合に,相手側である端末に,INVITEリクエストを転送する”ものであることが読み取れる。

(5)以上,上記(1)?上記(4)において検討した事項から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「モバイル通信システムに接続されるモバイル端末が,複数のアプリケーションを含み,ユーザが,前記アプリケーションを開始すると,
前記アプリケーションは,信頼されているエージェントと通信し,
前記信頼されているエージェントは,前記アプリケーションの権利を確認し,
前記権利が正当であれば,前記信頼されているエージェントが,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する,
メッセージ交換のための方法であって,
前記認証サーバは,信頼されているエージェントへ,ダイジェストの計算において用いられる乱数であるトークンを返送し,
前記信頼されているエージェントが,前記トークンを受信したとき,
前記信頼されているエージェントは,
前記トークンを用いてダイジェストを計算し,
前記ダイジェストを含むINVITEリクエストを生成し,
前記INVITEリクエストを,アプリケーションを認証するために,呼処理サーバに送信し,
前記呼処理サーバは,前記認証サーバに,前記ダイジェストと加入者識別子とを含む認証要求を送信し,
前記認証サーバは,信頼されているエージェントに送信したトークンを用い,端末と同じアルゴリズムを用いてダイジェストを計算し,
得られたダイジェストと,認証要求に含まれるダイジェストを比較し,
前記得られたダイジェストと,認証要求において受信したダイジェストとが一致した場合,認証が成功したとして,認証の成功を示す認証応答を,前記呼処理サーバに返送し,
前記呼処理サーバは,前記認証の成功を示す認証応答を受信した場合に,相手側である端末に,INVITEリクエストを転送する,方法。」

第5.本願発明と引用発明との対比及び相違点についての判断
1.本願発明1と引用発明との対比
(1)引用発明における「モバイル通信システム」は,データを通信するネットワークを構成するものであるから,引用発明における「モバイル通信システム」が,
本願発明1における「ネットワーク」に相当し,
引用発明において,「モバイル端末」は,「アプリケーション」を含むものであるから,
本願発明1における「装置」,及び,「クライアント装置」に相当し,
引用発明における「トークン」は,「乱数」であるから,
本願発明1における「チャレンジデータ」と,“計算に使用されるデータ”である点で共通し,
引用発明における「ダイジェスト」と,
本願発明1における「プライベートデータの難読化バージョン」は,“計算によって得られるデータ”である点で共通し,
引用発明における「信頼されているエージェント」は,「トークン」を用いて,「ダイジェスト」の計算を行っているので,
引用発明における「信頼されているエージェント」と
本願発明1における「信頼された情報マネージャ」とは,
“計算によって得られるデータを計算する手段”である点で共通し,
引用発明における「認証サーバ」は,「トークン」を,「信頼されているエージェント」に送信し,
引用発明における「呼処理サーバ」は,「信頼されているエージェント」から,「ダイジェスト」を含む「INVITEリクエスト」を受信していて,
「認証サーバ」と,「呼処理サーバ」は,「信頼されているエージェント」との間で「トークン」と,「ダイジェスト」の授受を行っているので,
引用発明における「認証サーバ」及び「呼処理サーバ」と,
本願発明1における「サービングノード」とは,“要求先”である点で共通する。

(2)引用発明における「トークン・リクエストを,認証サーバに送信する」ことは,「メッセージ交換」に関するものであって,「メッセージ交換」は,「データの交換」の一種であるから,上記(1)において検討した事項を踏まえると,
引用発明における「モバイル通信システムに接続されるモバイル端末が,複数のアプリケーションを含み,ユーザが,前記アプリケーションを開始すると,
前記アプリケーションは,信頼されているエージェントと通信し,
前記信頼されているエージェントは,前記アプリケーションの権利を確認し,
前記権利が正当であれば,前記信頼されているエージェントが,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する,
メッセージ交換のための方法」と,
本願発明1における「データネットワークにおいて,装置(100;200)上で,または装置(100;200)用に実行するアプリケーション(103;203)とサービングノードとの間での,クライアント装置(100;200)に関連するプライベートデータの交換を制御するための方法」とは,
“データネットワークおいて,アプリケーションが実行される装置と,要求先との間での,データの交換を制御するための方法”である点で共通する。

(3)上記(1)において検討したとおり,引用発明における「信頼されているエージェント」は,本願発明1における「信頼された情報マネージャ」と,“計算によって得られるデータを計算する手段”である点で共通するものであるが,
引用発明において,「信頼されているエージェントは,前記アプリケーションの権利を確認し,前記権利が正当であれば,前記信頼されているエージェントが,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する」ことは,「信頼されているエージェント」が,“要求元”として,「トークン・リクエスト」を,“要求先”である「認証サーバ」に送信することであるから,
引用発明における「信頼されているエージェントは,前記アプリケーションの権利を確認し,前記権利が正当であれば,前記信頼されているエージェントが,開始についてのセッションのためのトークンを要求するトークン・リクエストを,認証サーバに送信する」ことと,
本願発明1における「プライベートデータの使用を要求するサービス(105;205)へのアクセスのためのリクエストを,アプリケーション(103;203)から,サービングノードに送信するステップ」とは,
“要求元から,要求先へ,リクエストを送信するステップ”である点で共通する。

(4)引用発明における「信頼されているエージェントが,前記トークンを受信したとき」と,
本願発明1における「サービングノードからのチャレンジデータ(107)を,アプリケーション(103;203)で受信するステップ(3)」とは,
“要求先から,計算に使用されるデータを受信するステップ”である点で共通する。

(5)引用発明における「信頼されているエージェントは,前記トークンを用いてダイジェストを計算し,前記ダイジェストを含むINVITEリクエストを生成し,前記INVITEリクエストを,アプリケーションを認証するために,呼処理サーバに送信し」と,
本願発明1における「チャレンジデータ(107)に基づき,クライアント装置(100;200)のセキュアユーザインタフェース(111;213)を使用して,信頼された情報マネージャ(109;207)に,プライベートデータの使用に対する認可を要求するステップ(5)と,
アプリケーション(103;203)が,プライベートデータの知識を得ることができないように,認可に基づいて,サービス(105;205)で使用されるプライベートデータの難読化バージョン(113)を,信頼された情報マネージャ(109;207)からアプリケーション(103;203)を介して,サービングノードに送信するステップ」とは,
“計算に使用されるデータに基づき,計算によって得られるデータを,計算によって得られるデータを計算する手段から,要求先に送信するステップ”である点で共通する。

(6)以上,上記(1)?(5)において検討した事項から,本願発明1と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
データネットワークおいて,アプリケーションが実行される装置と,要求先との間での,データの交換を制御するための方法であって,
要求元から,前記要求先へ,リクエストを送信するステップと,
前記要求先から,計算に使用されるデータを受信するステップと,
前記計算に使用されるデータに基づき,計算によって得られるデータを,計算によって得られるデータを計算する手段から,前記要求先に送信するステップと
を含む方法。

[相違点1]
“アプリケーションが実行される装置と,要求先との間での,データの交換を制御するための方法”に関して,
本願発明1においては,「要求先」が,「サービングノード」であり,「装置(100;200)上で,または装置(100;200)用に実行するアプリケーション(103;203)とサービングノードとの間での,クライアント装置(100;200)に関連するプライベートデータの交換を制御するための方法」であるのに対して,
引用発明においては,「アプリケーション」と,「サービングノード」との間での「クライアント装置」に関連する「プライベートデータの交換を制御する」ことに関する言及がない点。

[相違点2]
“要求元から,前記要求先へ,リクエストを送信する”ことに関して,
本願発明1においては,「要求元」は,「アプリケーション」であり,「リクエスト」が,「プライベートデータの使用を要求するサービス(105;205)へのアクセスのためのリクエスト」であるのに対して,
引用発明においては,「要求元」は,「信頼されているエージェント」であり,「リクエスト」が,「開始についてのセッションのためのトークンを要求するトークン・リクエスト」である点。

[相違点3]
“要求先から,計算に使用されるデータを受信するステップ”に関して,
本願発明1においては,「受信する」のが,「アプリケーション」であり,「計算に使用されるデータ」が,「チャレンジデータ」であるのに対して,
引用発明においては,「受信する」のが,「信頼されているエージェント」であり,「計算に使用されるデータ」が,「ダイジェスト」を生成するための「トークン」である点。

[相違点4]
本願発明1においては,「チャレンジデータ(107)に基づき,クライアント装置(100;200)のセキュアユーザインタフェース(111;213)を使用して,信頼された情報マネージャ(109;207)に,プライベートデータの使用に対する認可を要求するステップ」が存在するのに対して,
引用発明においては,そのような「ステップ」が存在しない点。

[相違点5]
“計算によって得られるデータを,計算によって得られるデータを計算する手段から,前記要求先に送信する”ことに関して,
本願発明1においては,「アプリケーション(103;203)が,プライベートデータの知識を得ることができないように,認可に基づいて,サービス(105;205)で使用されるプライベートデータの難読化バージョン(113)を,信頼された情報マネージャ(109;207)からアプリケーション(103;203)を介して,サービングノードに送信する」ものであるのに対して,
引用発明においては,“アプリケーションが,プライベートデータの知識を得ることができないように,認可に基づいて,サービスで使用されるプライベートデータの難読化バージョンを,信頼された情報マネージャからアプリケーションを介して,サービングノードに送信する”ことは行っていない点。

2.本願発明1と引用発明との相違点についての判断
事案に鑑みて,先に,[相違点5]について検討すると,上記Eに引用した,引用文献2の記載には,「課題」に関する記載が存在するが,当該「課題」が,「プライベートデータ」であることは,引用文献2の全ての記載内容を検討しても読み取れない。
したがって,[相違点5]に係る本願発明1における“アプリケーションが,プライベートデータの知識を得ることができないように,認可に基づいて,サービスで使用されるプライベートデータの難読化バージョンを,信頼された情報マネージャからアプリケーションを介して,サービングノードに送信する”という構成は,引用文献1,及び,引用文献2には記載されておらず,本願の第1国出願前に周知技術であったともいえない。
以上のとおりであるから,他の相違点を検討するまでもなく,当業者であっても,引用発明,及び,引用文献2に記載の技術事項に基づいて,容易に発明できたものであるとはいえない。

3.本願発明2?本願発明15について
(1)本願発明2?本願発明8に関して
本願の請求項2?本願の請求項8は,本願の請求項1を直接・間接に引用するものであるから,本願発明2?本願発明8は,本願発明1の構成を内包している。
よって,上記2.において検討したとおり,本願発明2?本願発明8は,引用発明,及び,引用文献2に記載の技術事項に基づいて,容易に発明できたものであるとはいえない。

(2)本願発明9?本願発明11に関して
本願発明9は,方法の発明である本願発明1を,システムの発明としたものであるから,カテゴリが相違するものの,本願発明1と,ほぼ同等の構成を有しており,本願の請求項10,及び,本願の請求項11は,本願の請求項9を直接・間接に引用するものであるから,本願発明10,及び,本願発明11は,本願発明9の構成を内包している。
よって,上記2.において検討したとおり,本願発明9?本願発明11は,引用発明,及び,引用文献2に記載の技術事項に基づいて,容易に発明できたものであるとはいえない。

(3)本願発明12?本願発明14に関して
本願発明12は,「信頼された情報マネージャ」に関する発明であって,上記2.において検討した[相違点5]に係る構成を有するものであり,本願の請求項13,及び,本願の請求項14は,本願の請求項12を直接・間接に引用するものであるから,本願発明13,及び,本願発明14は,本願発明12の構成を内包している。
よって,上記2.において検討したとおり,本願発明12?本願発明14は,引用発明,及び,引用文献2に記載の技術事項に基づいて,容易に発明できたものであるとはいえない。

(4)本願発明15に関して
本願の請求項15は,本願の請求項1?本願の請求項8の何れか一項を引用するものであるから,本願発明15は,本願発明1の構成を内包している。
よって,上記2.において検討したとおり,本願発明15は,引用発明,及び,引用文献2に記載の技術事項に基づいて,容易に発明できたものであるとはいえない。

第6.原査定についての判断
本願発明1?本願発明15は,上記「第5.本願発明と引用発明との対比及び相違点についての判断」における「2.本願発明1と引用発明との相違点についての判断」において検討した[相違点5]に係る構成を有するものであるから,当業者であっても,原審拒絶査定の拒絶の理由に引用された引用文献1,及び,引用文献2に基づいて,容易に発明できたものとはいえない。したがって,原査定の理由を維持することはできない。

第7.むすび
以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2019-08-01 
出願番号 特願2016-541835(P2016-541835)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 中里 裕正  
特許庁審判長 辻本 泰隆
特許庁審判官 山崎 慎一
石井 茂和
発明の名称 プライバシー機密情報の交換を制御するための方法およびシステム  
代理人 特許業務法人川口國際特許事務所  

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