プライバシ制御を実装するための方法およびシステム
通信ネットワークにおいてプライバシ制御を実装するための方法およびシステムを提供する。本方法は、プライバシサーバにおいてパラメータハッシングまたは非パラメータハッシングを使って各ユーザ要求について第１の要求検証コード（ＲＶＣ）を生成し、ユーザ要求を第１のＲＶＣと一緒にＳＰに転送するステップと、プライバシサーバにおいて第２のＲＶＣとユーザプライバシ設定とを検証するステップとを含み、ここで第２のＲＶＣは、更なる要求と一緒にＳＰから受信される。本システムは、アプリケーションサービスを提供するための少なくとも１つのサービスプロバイダ（ＳＰ）を含む信用できないサブシステムと、通信サービスを提供するための少なくとも１つのモバイルオペレータモジュールを含む信用できるサブシステムとを備え、ここでモバイルオペレータモジュールは更に、要求検証コード（ＲＶＣ）を使ってユーザプライバシ制御を提供するための少なくとも１つのモバイルコアネットワークを備える。本発明の方法およびシステムによって、通信ネットワークにおけるセキュリティおよびプライバシ制御が大いに向上する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、通信ネットワークにおけるユーザエンティティの検証のための方法およびシステムに関する。詳細には、本発明は、通信ネットワークのプライバシ制御の改良に関する。
【背景技術】
【０００２】
通信技術の発達によって、ユーザは多種多様なネットワークサービスを体験できる。その例示的な一例として、位置情報サービスがある。位置情報サービスとは情報および娯楽サービスであって、モバイルネットワークを通じて移動デバイスを使ってアクセス可能であり、移動デバイスの地理的な位置を利用する機能を活用するものである。モバイルオペレータは、自社のモバイルネットワーク内でエンドユーザの移動デバイスの位置を特定することによって、この種のサービスを提供することができる。位置情報サービスは、例えば、友人（ユーザＡ）は、あなた（ユーザＢ）が偶然近くにいるならば、あなたと昼食を共にしたいと思っているというようなシナリオに大いに役立つであろう。あなたの正確な位置を見つけるため、友人は、あなたのモバイルオペレータが提供するあなたの位置情報にアクセスする必要がある。それ以外にも、友人は、近くのレストランを見つけることにも関心があるだろう。この場合、あなたの友人がアクセスしたいと思っている情報源には、あなたの位置情報とレストランの位置情報とが含まれる。あなたの位置情報とレストランの位置情報とが、友人に公開される。
【０００３】
ＳＰ（サービスプロバイダ）に位置特定機能および／または追従機能を公開すると、例えば最も近い病院を探すこと、友人の位置を知ること、車両を追従すること、更には位置情報ゲームで遊ぶことといった、多くの空想的な(fancy)位置ベースのアプリケーションを促進できるということは事実である。しかし、位置情報はデリケート(sensitive)かつ私的なものであるため、無許可のアクセスは避けられるべきである。モバイルオペレータは、プライバシ保護を保証し、位置インタフェースがサービスプロバイダに公開される場合には重要な役割を担わなければならない。
【０００４】
残念ながら、現行の方法では、個々のユーザをそのユーザについての個別のデータと共に特定することが比較的容易であり、それゆえ、プライバシの懸念が生じている。例えばＰａｒｌａｙ−ＸおよびＭＬＰのような現行の標準および解決策は、プライバシ保護における強力な支援を提供できない。典型的には、ＳＰは、ユーザがオペレータ側でプライバシ設定を行っている時でさえ、なりすまし攻撃をしかけることができるだろう。例えば、ＳＰは、要求の「要求側」フィールドを修正してプライバシ設定を迂回することができる。以下の例は、この種の攻撃を示す：
ユーザＡの以下のプライバシ設定を考えると：
ユーザＢがユーザＡの位置を特定すること‐禁止
ユーザＣがユーザＡの位置を特定すること‐許可
【０００５】
現行の標準および／または解決策では、ＳＰは、ユーザＢがユーザＡの位置を特定しようとする場合に、「要求側」フィールドを「ユーザＣ」に修正することによって、ユーザＡの位置の特定に成功できるように、なりすまし攻撃をしかけることを手伝うことができるであろう。
【０００６】
ＳＰが（ＭＳＩＳＤＮのような）ユーザの実際のＩＤを入手することを避けるため、ユーザの別名または暗号化されたアドレスを用いるといった解決策があるが、それらはすべて、ＳＰのアプリケーションに制限または影響を与える一方で、一部のＳＰのアプリケーションはサービスを完了するために結局実際のユーザＩＤを必要とすることがある。
【０００７】
従って、上記の欠点を克服するため、通信ネットワークにおいてプライバシ制御を実装する方法およびそのためのシステムを提供することが望ましいであろう。
【発明の概要】
【０００８】
従って、ネットワークセキュリティを向上させるために通信ネットワークにプライバシ制御を実装する方法とそのためのシステムとを提供することによって上記の欠点に対処することが、本発明の目的である。
【０００９】
本発明の一態様によって、少なくとも１つのプライバシサーバと少なくとも１つのサービスプロバイダ（ＳＰ）とを含む通信ネットワークにおいてプライバシ制御を実装する方法を提供する。方法は、プライバシサーバにおいてパラメータハッシングまたは非パラメータハッシングを使って各ユーザ要求について第１のＲｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（ＲＶＣ：要求検証コード）を生成し、ユーザ要求を第１のＲＶＣと一緒にＳＰに転送することと、プライバシサーバにおいて第２のＲＶＣおよびユーザプライバシ設定を検証することとを含み、ここで第２のＲＶＣは、更なる要求と一緒にＳＰから受信される。
【００１０】
方法の一実施形態では、プライバシサーバは、第１のＲＶＣを記憶し、その後、要求を転送して、第２のＲＶＣが記憶された第１のＲＶＣと同一であることを検証する。
【００１１】
方法の一実施形態では、非パラメータハッシングが行われる場合、ＲＶＣには検証情報が含まれていないため、（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」を含む）ユーザ要求に関連するパラメータが、更なる検証用にプライバシサーバの中に記憶される。第２のＲＶＣがＳＰから来た場合、パラメータが第２のＲＶＣと一緒にプライバシサーバによってチェックされ、それらが無修正であるか（改竄されていないか）どうか判断される。
【００１２】
方法の一実施形態では、パラメータハッシングが行われる場合、プライバシサーバは第１のＲＶＣを記憶すべきであって、プライバシサーバは、第１のＲＶＣがそれに基づいているパラメータをすでに知っているはずであり（ＲＶＣは少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」に基づくべき）、従って、パラメータを記憶することは不要である。第２のＲＶＣが来た場合、プライバシサーバは、ＳＰからの更なる要求に含まれるパラメータに基づいて新たなＲＶＣを生成し、新たなＲＶＣがＳＰからの第２のＲＶＣと同等であるかどうか判断する。この新たなＲＶＣは、ＳＰからの第２のＲＶＣと同等であるべきであり、かつ、ストレージの中にすでに記憶された第１のＲＶＣとも同等であるべきである。
【００１３】
方法の一実施形態では、第２のＲＶＣとユーザプライバシ設定とを検証することは、更に、第２のＲＶＣは第１のＲＶＣと同等であるかどうかチェックすることと、ユーザ要求を開始しているユーザが、要求されているユーザのユーザプライバシ設定の下で許可されているかどうか検証することとを含む。
【００１４】
パラメータハッシングでは第１のＲＶＣはユーザ要求のパラメータに基づいて生成され、非パラメータハッシングでは第１のＲＶＣはユーザ要求のパラメータに依存しない一意の（固有の）ＩＤであることが望ましい。
【００１５】
方法の一実施形態では、方法は更に、ＳＰが第１のＲＶＣを伴うユーザ要求を受信した後、ＳＰにおいてビジネスロジックを実行することと、ＳＰからの位置要求をＰａｒｌａｙ−Ｘゲートウェイに転送することと、更なる要求を検証するためにＰａｒｌａｙ−Ｘゲートウェイからプライバシサーバへの要求を呼び出す（開始する）こととを含む。
【００１６】
方法の一実施形態では、方法は更に、第２のＲＶＣおよびユーザプライバシ設定が検証された後、要求された情報をＭｏｂｉｌｅ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（ＭＰＳ：モバイルポジショニングシステム）からＰａｒｌａｙ−Ｘゲートウェイに転送することと、要求された情報をＳＰにおいて公開する（開示する）こととを含む。
【００１７】
Ｐａｒｌａｙ−Ｘゲートウェイに転送される更なる要求は、ユーザ要求を開始するユーザを示す「要求者（ｒｅｑｕｅｓｔｏｒ）」と、要求されている別のユーザを示し、位置特定されることになるアドレスとを含むことが望ましい。
【００１８】
ユーザ要求は、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ：ショートメッセージサービス）および／またはＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ：マルチメディアメッセージサービス）を使って開始されることが望ましい。
【００１９】
ユーザ要求は、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ワイヤレスアプリケーションプロトコル）アクセスを使って開始されることが望ましい。
【００２０】
ユーザ要求は、ウェブアクセスを使って開始されることが望ましい。
【００２１】
方法の一実施形態では、ユーザ要求は、Ｐａｒｌａｙ−Ｘゲートウェイと、ＳＭＳＣ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｃｅｎｔｒｅ：ショートメッセージ・サービスセンタ）、および／または、ＭＭＳＣ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｃｅｎｔｒｅ：マルチメディアメッセージ・サービスセンタ）とによってインターセプト（傍受）され、そしてできれば、Ｐａｒｌａｙ−Ｘゲートウェイは、ユーザ要求をインターセプトした後、ユーザ要求が更なる要求を含むかどうか判断し、ユーザ要求が更なる要求を含むならばＲＶＣを生成するようにプライバシサーバに要求することが望ましい。
【００２２】
方法の一実施形態では、ユーザ要求は、ＳＰ ＷＡＰポータルによってインターセプトされ、そしてできれば、ユーザ要求は更なる要求を含むという判断に基づいて第１のＲＶＣが生成されることが望ましい。
【００２３】
方法の一実施形態では、ユーザ要求は、ＳＰウェブポータルによってインターセプトされ、そしてできれば、ユーザ要求を開始するユーザは、ユーザ要求が更なる要求を含む場合にはログインするように要求され、そして、ユーザＩＤとパスワードとの検証に基づいて第１のＲＶＣが生成されることが望ましい。
【００２４】
本発明の別の態様によって、プライバシ制御を提供するための通信システムを提供する。通信システムは、アプリケーションサービスを提供するための少なくとも１つのサービスプロバイダ（ＳＰ）を備えた信用できないサブシステムと、通信サービスを提供するための少なくとも１つのモバイルオペレータモジュールを備えた信用できるサブシステムとを備え、ここでモバイルオペレータモジュールは更に、要求検証コード（ＲＶＣ）を使ってユーザプライバシ制御を提供するための少なくとも１つのモバイルコアネット―クを備える。
【００２５】
通信システムの一実施形態では、モバイルオペレータモジュールは更に、移動ユーザの位置を特定するためのモバイルポジショニングシステム（ＭＰＳ）を備える。
【００２６】
通信システムの一実施形態では、モバイルコアネットワークは、少なくとも１つのＰａｒｌａｙ−Ｘゲートウェイと、前記Ｐａｒｌａｙ−Ｘゲートウェイに結合された少なくとも１つのプライバシサーバとを含む。Ｐａｒｌａｙ−Ｘゲートウェイに関連するプライバシサーバは、パラメータハッシングまたは非パラメータハッシングを使って各ユーザ要求について第１のＲＶＣを生成し、そして、第２のＲＶＣとユーザプライバシ設定とを検証するように構成される。Ｐａｒｌａｙ−Ｘゲートウェイは、ＳＰから更なる要求と第２のＲＶＣとを受信するため、または要求された情報をＳＰに送信するため、または、要求された情報をＳＰに公開するために、ＳＰに結合され、そしてＰａｒｌａｙ−Ｘゲートウェイは更に、更なる要求をＭＰＳに送信して、要求された情報をＭＰＳから受信するために、ＭＰＳに結合される。
【００２７】
方法の一実施形態では、非パラメータハッシングが行われる場合、ＲＶＣには検証情報が含まれていないため、（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」を含む）ユーザ要求に関連するパラメータが、更なる検証用にプライバシサーバの中に記憶される。第２のＲＶＣがＳＰから来た場合、プライバシサーバは、第２のＲＶＣとパラメータとがいずれも無修正であるかどうかチェックする必要がある。
【００２８】
方法の一実施形態では、パラメータハッシングが行われる場合、プライバシサーバは、第１のＲＶＣを記憶すべきであって、プライバシサーバは、ＲＶＣがどのパラメータに基づくかも知っているはずであり（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」に基づくべき）、従って、パラメータを記憶する必要はない。第２のＲＶＣが来た場合、プライバシサーバは、ＳＰからの更なる要求の中のパラメータに基づいて新たなＲＶＣを生成し、新たなＲＶＣがＳＰからの第２のＲＶＣと同等であるかどうか判断する。この新たなＲＶＣは、ＳＰからの第２のＲＶＣと同等であるべきであり、かつ、ストレージの中にすでに記憶された第１のＲＶＣとも同等であるべきである。
【００２９】
パラメータハッシングでは、第１のＲＶＣは、数学的アルゴリズムに従ってユーザ要求のパラメータに基づいて生成されることが望ましく、そして、非パラメータハッシングでは、第１のＲＶＣは、ユーザ要求のパラメータに依存しない一意のＩＤであることが望ましい。
【００３０】
通信システムの一実施形態では、モバイルオペレータモジュールは更に、ＳＭＳおよび／またはＭＭＳを送受信するためにモバイルコアネットワークに関連付けられたＳＭＳＣおよび／またはＭＭＳＣを含む。
【００３１】
通信システムの一実施形態では、Ｐａｒｌａｙ−Ｘゲートウェイは、ＳＭＳおよび／またはＭＭＳをインターセプトするためにＳＭＳＣおよび／またはＭＭＳＣに関連付けられ、そして、Ｐａｒｌａｙ−Ｘゲートウェイは更に、ＳＭＳおよび／またはＭＭＳが更なる要求を含むという判断に基づいて更なる要求を検証する目的でプライバシサーバへの要求を呼び出すために、プライバシサーバに関連づけられる。
【００３２】
通信システムの一実施形態では、プライバシサーバが、第２のＲＶＣの検証を提供するために第２のＲＶＣが第１のＲＶＣと同等であるかどうかチェックするように構成され、プライバシサーバは更に、ユーザ要求を開始しているユーザがユーザプライバシ設定の下で許可されているかどうか判断するように構成される。
【００３３】
通信システムの一実施形態では、ＳＰは更に、プライバシサーバに関連付けられたＳＰウェブポータルを含み、ここでプライバシサーバは、ユーザ要求が更なる要求を含む場合にはログインするようにユーザに要求し、そして、ユーザＩＤとパスワードとの検証に基づいて第１のＲＶＣを生成するように構成される。
【００３４】
通信システムの一実施形態では、ＳＰは更に、プライバシサーバに関連付けられたＳＰワイヤレスアプリケーションプロトコル（ＷＡＰ）ポータルを含み、ここでプライバシサーバは、ユーザ要求が更なる要求を含むという判断に基づいて第１のＲＶＣを生成するように構成される。
【００３５】
本発明の別の態様によって、通信ネットワークにおいてプライバシ保護を実装するための装置を提供するが、装置は、各ユーザ要求について第１の要求検証コード（ＲＶＣ）を生成するための手段と、移動ユーザの位置を特定するための手段と、第２のＲＶＣおよびユーザプライバシ設定を検証するための手段と、前記検証に応じて、要求された情報を公開するための手段とを備える。
【００３６】
本発明の別の態様によって、実行された場合には前記方法を行うような命令を記録した、機械可読媒体を提供する。
【００３７】
本発明の別の態様によって、要求検証コード（ＲＶＣ）および関連するプライバシ制御データ、例えば、パラメータ、許可される単一または複数の利用を生成するタイムスタンプ、利用カウンタ等を記憶するためのデータ構造を提供する。このデータ構造は、プライバシサーバの中に維持されることが望ましい。
【００３８】
本発明による方法およびシステムは、既存のＰａｒｌａｙ−Ｘゲートウェイおよびプライバシサーバのアーキテクチャに基づいて、Ｐａｒｌａｙ−Ｘ仕様の単純な改良とＳＰアプリケーションとの統合を行えば、容易に実装される。更に、ＳＭＳおよびＷＡＰ利用についてはエンドユーザ体験にまったく影響を与えず、ウェブアクセスにおいてもエンドユーザ体験にほとんど影響を与えない。ＳＰアプリケーション開発の観点からは、ユーザのＭＳＩＳＤＮまたは同様の実際のユーザＩＤをＳＰアプリケーションが知ることを防ぐ目的でユーザの別名（エイリアス）を用いる一部のソリューションとは異なり、本発明によるソリューションは、ＳＰアプリケーションがＭＳＩＳＤＮを検索することを妨げず、そしてこれが、ＳＰアプリケーション開発の柔軟性を保つ。
【図面の簡単な説明】
【００３９】
本発明の上記およびその他の態様、特徴、利点は、添付の図面と併せて提示される本発明の下記の詳細記述から一層明らかになるであろう。
図面中、対応する参照文字は、図面の複数の図を通じて対応するコンポーネントを示す。
【図１】プライバシ制御を実装しうる通信ネットワークを例示する簡略化したブロック図である。
【図２】ＳＭＳアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【図３】ＷＡＰアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【図４】ウェブアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【発明を実施するための形態】
【００４０】
以下に記述した実施形態は、当業者が本発明を実施できるようにするために必要な情報を表し、本発明を実施する上でのベストモードを図解する。添付の図面の図を考慮に入れて下記の記述を読めば直ちに、当業者なら本発明の概念を理解し、本書で特に取り上げていないこれらの概念の応用例を認識するであろう。理解されるべきだが、これらの概念および応用例は、開示および添付の請求項の範囲内に入る。
【００４１】
本明細書の記述および請求項の全体を通じて、「ＳＰ」という用語は、サービスプロバイダを含むが、それに限定されず、用語「ＳＭＳ」は、ショートメッセージサービスを含むが、それに限定されず、用語「ＭＭＳ」は、マルチメディアサービスを含むが、それに限定されず、用語「ＳＭＳＣ」は、ショートメッセージ・サービスセンタを含むが、それに限定されず、用語「ＭＭＳＣ」は、マルチメディア・サービスセンタを含むが、それに限定されず、用語「ＳＭＰＰ」は、ショートメッセージ・ピア・ツー・ピアを含むが、それに限定されず、用語「ＭＬＰ」は、モバイルロケーションプロトコルを含むが、それに限定されず、用語「ＭＰＳ」は、モバイルポジショニングシステムを含むが、それに限定されず、用語「ＷＡＰ」は、ワイヤレスアプリケーションプロトコルを含むが、それに限定されず、そして、「ＲＶＣ」は、Ｒｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（要求検証コード）を含むが、それに限定されない。
【００４２】
図１は、本発明の一実施形態がその中に実装される通信システムの概略ブロック図である。図示するように、通信システムは２つのサブシステム、すなわち信用できるシステム１００と信用できないシステム２００とを含む。本実施形態では、信用できるサブシステム１００とは、モバイルオペレータ領域のことを言い、更にＰａｒｌａｙ−Ｘゲートウェイ１２０と、プライバシサーバ１４０と、ＭＰＳ１６０とＳＭＳＣ１８０とを備える。信用できないサブシステム２００は、ＳＰ ＷＡＰアプリケーションおよびＳＰウェブアプリケーションのようなアプリケーションサービスを提供するためのＳＰ２１０およびＳＰ２３０を備える。モバイルオペレータ領域では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＭＳおよび／またはＭＭＳを送受信するため、ＳＭＳＣ１８０に接続され、更に、移動ユーザの位置を特定するためＭＰＳ１６０に接続される。更に、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰ２１０および２３０に対して統一されたインタフェースを公開するために用いられる。ＭＰＳ１６０は、モバイルネットワークを使って移動ユーザの位置を特定するために用いることができる。ＳＭＳＣ１８０は、ＳＭＳメッセージを送受信するためにＰａｒｌａｙ−Ｘゲートウェイ１２０に接続される。ＳＭＳＣ１８０は、ＭＭＳを提供するためにＭＭＳＣに変更されてもよい。他方、ＳＰアプリケーションを使ってアプリケーションサービスを提供するために、ＳＰ２１０および２３０が用いられてもよい。そのようなＳＰのアプリケーションの例として、ユーザプレゼンスサービスがある。
【００４３】
当業者であれば、プライバシサーバ１４０のない図１に示すアーキテクチャに詳しいであろう。従って、これらの部分の記述は、本願の実施形態の理解を提供するのに必要な程度に留める。しかし、他方、図１に示すアーキテクチャがプライバシサーバ１４０を含む場合、アーキテクチャの性能と機能とは大幅に改良されている。
【００４４】
プライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に結合されており、ＳＰ２１０および２３０に関連付けられている。
【００４５】
第１にプライバシサーバ１４０は、ユーザプライバシ設定を記憶するために用いることができる。ユーザプライバシ設定の一例が、位置情報のための「許可リスト」であってもよい。例えば、ユーザＢおよびユーザＣが必要に応じてユーザＡの位置を特定できるように、ユーザＡが、ユーザＢとユーザＣとをプライバシサーバ１４０の中の「許可リスト」に設定してもよい。リストの中に存在しない人は、ユーザＡの位置を特定することはできない。
【００４６】
第２に、プライバシサーバ１４０は、Ｒｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（ＲＶＣ：要求検証コード）と名付けられた一意のコードを生成して検証することによって、本発明の実施形態において重要な役割を果たす。具体的には、ＲＶＣは、各ユーザ要求についてパラメータハッシングまたは非パラメータハッシングを使って生成される。
【００４７】
パラメータハッシングについては、ＲＶＣは、数学的アルゴリズム、例えばＭＤ５に従ってユーザ要求のパラメータに基づいて生成される。このコード生成は、一般に「ハッシング」として知られる。例えば、ユーザＡがチャネルＳＭＳによってユーザＢの位置を特定する要求を出す場合、プライバシサーバは、このユーザ要求の内容に基づいてＲＶＣを生成するであろう。ハッシング用に用いられる情報は、必ずしも要求全体である必要はなく、ユーザＡのＭＳＩＳＤＮ、要求のタイムスタンプ等のような特定の要素（パラメータ）に限定されてもよい。後で要求の完全性(integrity)を検証するため、ハッシングが再度行われるが、以前と同じコードが生じるはずである。
【００４８】
非パラメータハッシングについては、ＲＶＣは、一意のＩＤであってユーザ要求のパラメータには依存しない。この場合、検証とは、特定のパラメータがＩＤと共に記憶され、その後、これらが、要求の中のパラメータと比較されなければならないことを意味する。
【００４９】
上記は、ＲＶＣに関する簡単な紹介にすぎず、詳細記述は、以下で図２、３、４に関連して行う。理解されるべきだが、１つ以上のＰａｒｌａｙ−Ｘゲートウェイ１２０、プライバシサーバ１４０、ＭＰＳ１６０およびＳＭＳＣ１８０ならびにＳＰ２１０および２３０は、ハードウェア、ソフトウェア、またはそれらのいずれかの組み合わせを含んでもよい。少なくとも１つの実施形態では、これらの部分は、以下に論じる方法のステップに対応する動作を実行するための命令を含む。そのような命令は、記憶されたプログラム命令を記憶要素（例えばメモリ）の中に含む、１つ以上のコンピュータプログラムとして具現化されてもよい。
【００５０】
次に図２を参照すると、本発明の一実施形態に関連する通信ネットワーク内の位置プライバシ保護の方法を例示するフローチャートを示す。理解されるべきだが、方法は必ずしも例示されたシーケンスに限定される必要はなく、必要に応じて一部のステップが省略されてもよく、一部のステップが、一緒に行われるかまたは、その他のやり方で相互に関連する形で行われてもよい。
【００５１】
このシナリオでは、ユーザは、ＳＭＳによってユーザ要求を開始する。アプリケーション２１１は、前もって作成されており、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に接続していて、そこに何らかの形で登録されている。キー情報は、「登録」の一部である。アプリケーション２１１は、下記のキー情報と共にＰａｒｌａｙ−Ｘゲートウェイ１２０によって知られる。すなわちキー情報とは、これはＳＭＳアプリケーションであり、これは位置ベースのアプリケーションであり、このＳＭＳアプリケーションをインターセプト（傍受）するか否かを示すフラグが存在し、例えば「ＬＯＣＡＴＥ」のようなインターセプトのためのＳＭＳキーワードが存在する。モバイルオペレータは、この情報をチェックして承認する必要がある。
【００５２】
方法は、ステップＳ２０１で始まり、ここではエンドユーザＢ１１０がユーザＡの位置を特定するためにＳＭＳを送信する。例えば、ＳＭＳの内容は、「ＬＯＣＡＴＥ ４６１９３５７９」であってもよい。ＳＭＳの内容は、ユーザＡについて位置特定が行われることになることを識別する。ＳＭＳＣ１８０は、直ちにＳＭＳを受信し、このＳＭＳを、ステップＳ２０２で、ＳＭＰＰに従って更にＰａｒｌａｙ−Ｘゲートウェイ１２０に転送する。留意されるべきだが、「ＳＭＰＰ」という用語は、序論で概要を述べたように用いられる。実際のＳＭＰＰの代わりに、例えばＵＣＰおよびＭＭ７のような、類似のプロトコルを用いてもよい。ＳＭＳを受信した後、ステップＳ２０３で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＳＭＳの内容をチェックして、ＳＭＳキーワードを比較することによってそれが位置情報サービス要求なのかどうかを判断する。位置要求が存在した場合には、ステップＳ２０４に示すように、ユーザＢ１１０のＭＳＩＳＤＮを持つＲＶＣを入手するためにＰａｒｌａｙ−Ｘゲートウェイ１２０が要求をプライバシサーバ１４０に送信し、そうでない場合、フローはステップＳ２０６に進む。Ｐａｒｌａｙ−Ｘゲートウェイ１２０から要求を受信する場合、プライバシサーバ１４０は、ユーザＢ １１０からのユーザ要求に基づいて第１のＲＶＣを生成し、次いで、ステップＳ２０５に図解するように、第１のＲＶＣをＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。
【００５３】
その後、ステップＳ２０６で、第１のＲＶＣを搬送するＳＭＳが、Ｐａｒｌａｙ−Ｘゲートウェイ１２０によってアプリケーション２１１に転送されるであろう。ＳＭＳがどのようにしてＲＶＣを搬送するかを例示するため、Ｐａｒｌａｙ−Ｘ ＳＭＳの簡単な説明をここで行おう。
【００５４】
本書で示すように、Ｐａｒｌａｙ−Ｘショートメッセージングの仕様では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、動作ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎを用いてＳＭＳをＳＰ２１０（アプリケーション２１１）に転送する。ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎの定義を表１乃至３で示すように簡単に例示する。
【００５５】
【表１】
【００５６】
【表２】
【００５７】
【表３】
【００５８】
表１は、入力メッセージ：ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎＲｅｑｕｅｓｔの定義を提供し、表２は、ＳｍｓＭｅｓｓａｇｅ構造を提供し、表３は、出力メッセージ：ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎＲｅｓｐｏｎｓｅを定義する。
【００５９】
このメッセージの中でＲＶＣを搬送するため、以下のやり方が提供される。すなわち、ｓｅｎｄｅｒＡｄｄｒｅｓｓを使ってＳｍｓＭｅｓｓａｇｅの中にＲＶＣを符号化するかまたは、ＲＶＣを含むようにＳｍｓＭｅｓｓａｇｅを拡張するかまたは、ＳＯＡＰヘッダの中にＲＶＣを追加する。
【００６０】
ステップＳ２０７に戻るが、第１のＲＶＣを搬送するＳＭＳを受信した後、ＳＰアプリケーションは、ＳＭＳを処理して、例えば、ユーザＢが関心を持つ情報を見つけるためにビジネスロジックを実行する。本実施形態では、ユーザＢ１１０はユーザＡの位置情報に関心を持つ。従って、ＳＰアプリケーションは、ステップＳ２０８で、ユーザＡの位置を特定するため、位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信するであろう。
【００６１】
ここで採用される命令は、ｇｅｔＬｏｃａｔｉｏｎ（要求者、アドレス、ＲＶＣ）であり、ここで入力パラメータは、ユーザＢを「要求者」として採用し、ユーザＡを位置特定されることになるアドレスとして採用する。そして、ＲＶＣは、第２のＲＶＣであり、これはＳＰアプリケーションから来る。
【００６２】
明確にするために、用語「ｇｅｔＬｏｃａｔｉｏｎ」を、簡単な紹介として明記する。Ｐａｒｌａｙ−Ｘ Ｔｅｒｍｉｎａｌ Ｌｏｃａｔｉｏｎ仕様では、動作ｇｅｔＬｏｃａｔｉｏｎが、Ｐａｒｌａｙ−Ｘゲートウェイに対して端末位置を要求するために、アプリケーションによって用いられる。ｇｅｔＬｏｃａｔｉｏｎの定義を以下に例示する。
【００６３】
【表４】
【００６４】
【表５】
【００６５】
表４は、入力メッセージの形式を定義し、表５は、出力メッセージの定義を提供する。このメッセージの中でＲＶＣを搬送するには、３つのやり方がありうる。すなわち、要求側と共にＲＶＣを符号化することと、ＲＶＣを含むようにこのメッセージを拡張することと、ＳＯＡＰヘッダ内にＲＶＣを追加することである。更に、同じスキームを他の動作に適用することもできる。例えば、ｇｅｔＴｅｒｍｉｎａｌＤｉｓｔａｎｃｅ、ｇｅｔＬｏｃａｔｉｏｎＦｏｒＧｒｏｕｐ、ｓｔａｒｔＧｅｏｇｒａｐｈｉｃａｌＮｏｔｉｆｉｃａｔｉｏｎ、ｓｔａｒｔＰｅｒｉｏｄｉｃＮｏｔｉｆｉｃａｔｉｏｎである。
【００６６】
ステップＳ２０９に戻ると、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、第２のＲＶＣを検証するために、要求をプライバシサーバ１４０に提出する。同様に、入力パラメータには、要求者（ユーザＢ）と、位置特定されることになるアドレス（ユーザＡ）と、第２のＲＶＣとが含まれる。次いでステップＳ２１０で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのＳＭＳ要求から来た正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じであるかどうかをチェックする。更に、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答して、その後、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。それが「真」である場合、すなわち、ＲＶＣが正しく、そして、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ２１１に示すように、位置要求を「ＭＬＰ．Ｌｏｃａｔｅ（アドレス）」の形式でＭＰＳ１６０に送信する。そうではなく、第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。それに続いて、ステップＳ２１２で、ＭＰＳ１６０は、ユーザＡの位置情報を発見して、それをＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ２１３で、ユーザＡの位置をＳＰアプリケーション２１１に転送する。その後、ステップＳ２１４で、ＳＰアプリケーション２１１は、位置情報またはサービス情報をユーザＡの位置情報に基づいてＳＭＳによってＰａｒｌａｙ−Ｘゲートウェイ１２０に送信する。最後に、ステップＳ２１５およびＳ２１６に示すように、Ｐａｒｌａｙ−Ｘゲートウェイ１２０はＳＭＳをＳＭＳＣ１８０に送信し、ＳＭＳＣ１８０は、ＳＭＳをユーザＢ１１０に更に転送する。上記のステップに従って、ユーザＢ１１０は、最後に、ＳＭＳを使ってユーザＡの位置情報を受信する。
【００６７】
上記の実施形態では、ＲＶＣの寿命は、期限切れ時刻および最大回数に依存してもよい。期限切れ時刻とは、１つのＲＶＣが作成された後の一定期間それを使用することができるということを意味する。例えば、それが２時間使用されてもよい。最大回数とは、１つのＲＶＣを１回または複数回使用することができるということを意味する。いずれのパラメータも、Ｐａｒｌａｙ−Ｘゲートウェイの中で構成することができ、プライバシサーバは、これらのパラメータに従って適切なＲＶＣを生成することができる。
【００６８】
本発明の一態様による別の実施形態は、ユーザＢ１１０がＷＡＰアクセスを使ってユーザＡの位置を受信することもできる一シナリオを例示する。このシナリオでは、ＳＰ位置ＷＡＰ ＵＲＬがプライバシサーバ１４０によって設定される。
【００６９】
本実施形態では、最初に、ユーザＢ１１０がＳＰ ＷＡＰポータルに入り、そして、ユーザＡを選択して位置を特定するためにＷＡＰページを閲覧する。次いでステップＳ３０２で、ＳＰ ＷＡＰポータルが、プライバシサーバ１４０のＷＡＰ ＵＲＬにリダイレクトする。プライバシサーバ１４０は、ＳＰ ＷＡＰポータルからのＵＲＬを検証して、それが位置についてのＵＲＬであることを確信し、そして、ステップＳ３０３で、移動端末のブラウザからユーザのＭＳＩＳＤＮを検索する。
【００７０】
次のステップＳ３０４で、プライバシサーバ１４０は、ユーザのＭＳＩＳＤＮを入手して、要求セッションを作成する。更に、プライバシサーバ１４０は、セッションについての第１のＲＶＣを生成する。ステップＳ３０５では、プライバシサーバ１４０は、第１のＲＶＣと共にＳＰ ＷＡＰポータルへリダイレクトして戻る。ステップＳ３０６で、ＳＰ ＷＡＰアプリケーション２１２が、ビジネスロジックを実行する。ステップＳ３０７では、ＳＰ ＷＡＰアプリケーション２１２が、ユーザＡの位置を特定するため位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信し、入力パラメータには、要求者としてユーザＢ、位置特定されることになるアドレスとしてユーザＡ、そしてＲＶＣが含まれる。ステップＳ３０８では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＲＶＣを検証するためにプライバシサーバ１４０への要求を呼び出し、ここで入力パラメータには、要求者がユーザＢとして、位置が特定されることになるアドレスがユーザＡとして、そして第２のＲＶＣが含まれる。次いでステップＳ３０９で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのＷＡＰ要求の中にある正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じかどうかをチェックする。加えて、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答し、その後Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。これが「真」である場合、すなわち、ＲＶＣが正しくて、かつ、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ３１０に示す「ＭＬＰ．Ｌｏｃａｔｅ（ａｄｄｒｅｓｓ）」の形式で、位置要求をＭＰＳ１６０に送信する。第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。ＲＶＣが正しく、かつ、ユーザプライバシ設定が検証された場合には、ステップＳ３１１で示すように、ＭＰＳ１６０が、ユーザＡの位置をＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。最後に、ステップＳ３１２およびＳ３１３で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ユーザＡの位置をＳＰ ＷＡＰアプリケーション２１２に返信し、ＳＰ ＷＡＰアプリケーション２１２は、位置情報またはサービス情報をユーザＡの位置情報に基づいてＷＡＰポータルにおいてユーザＢ１１０に示す。上記のステップに従って、ユーザＢ１１０は最後に、ＷＡＰアクセスを使ってユーザＡの位置情報を入手する。
【００７１】
本発明の一態様による別の代替実施形態は、ユーザＢがユーザＡの位置情報をウェブアクセスを使って入手しようとするシナリオを例示する。このシナリオでは、ＳＰ位置ウェブＵＲＬが、プライバシサーバ１４０によって設定され、更に、ユーザＢ１１０は、プライバシサーバ１４０のウェブポータルの中に登録すべきである。
【００７２】
本実施形態では、方法のメッセージフローは、ＷＡＰアクセスとして実装されている前の実施形態とは、主にステップＳ４０１乃至Ｓ４０６において異なる。具体的には、最初に、同様に、ユーザＢ１１０がＳＰウェブポータルに入り、そして、ユーザＡを選択して位置を特定するためにウェブページを閲覧する。次いで、ステップＳ４０２で、ＳＰウェブポータルが、プライバシサーバ１４０のウェブＵＲＬにリダイレクトする。プライバシサーバ１４０は、ＳＰウェブポータルからのＵＲＬを検証して、それが位置についてのＵＲＬであることを確信し、そして、ステップＳ４０３で、ユーザＢ１１０にログインするように要求する。ステップＳ４０４で、ユーザＢ１１０は、自分のユーザＩＤ（ＭＳＩＳＤＮ）とパスワードを使ってログインするはずである。ユーザＩＤとパスワードとの検証に成功した後、プライバシサーバ１４０は、ステップＳ４０５で要求セッションを作成する。更に、プライバシサーバ１４０は、このセッションについての第１のＲＶＣを生成する。ステップＳ４０６で、プライバシサーバ１４０は、第１のＲＶＣと共にＳＰウェブポータルへリダイレクトして戻る。
【００７３】
以下のステップは、前の実施形態で記述したものと同様である。ステップＳ４０７で、ＳＰウェブアプリケーション２１３が、ビジネスロジックを実行する。ステップＳ４０８では、ＳＰウェブアプリケーション２１３が、ユーザＡの位置を特定するため位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信し、入力パラメータには、要求者としてユーザＢが、位置特定されることになるアドレスとしてユーザＡが、そしてＲＶＣが含まれる。ステップＳ４０９では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＲＶＣを検証するためにプライバシサーバへの要求を呼び出し、ここで入力パラメータには、要求者がユーザＢとして、位置が特定されることになるアドレスがユーザＡとして、そして第２のＲＶＣが含まれる。次いでステップＳ４１０で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのウェブ要求の中にある正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じかどうかをチェックする。加えて、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答し、その後Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。これが「真」である場合、すなわち、ＲＶＣが正しくて、かつ、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ４１１に示す「ＭＬＰ．Ｌｏｃａｔｅ（ａｄｄｒｅｓｓ）」の形式で、位置要求をＭＰＳ１６０に送信する。第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。ＲＶＣが正しく、かつ、ユーザプライバシ設定が検証された場合には、ステップＳ３１１で示すように、ＭＰＳ１６０が、ユーザＡの位置をＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。最後に、ステップＳ４１３およびＳ４１４で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ユーザＡの位置をＳＰウェブアプリケーション２１３に返信し、ＳＰウェブアプリケーション２１３は、ユーザＡの位置情報またはサービス情報をウェブポータルにおいてユーザＢ１１０に示す。上記のステップに従って、ユーザＢ１１０は最後に、ウェブアクセスを使ってユーザＡの位置情報を入手する。
【００７４】
結果として、通信ネットワークのセキュリティ性能が大いに向上する。図２乃至３に例示した方法は、移動無線ネットワークに適用されるだけでなく、有線ネットワークにも、あるいは、無線ネットワークと有線ネットワークとの組み合わせに基づく通信ネットワークにも適用される。
【００７５】
分かりやすいように、実施形態では、要求および応答に適用されるチャネルタイプは同じであるとして提示してきた。実際には、本発明の中核から逸脱することなく、これらは、ウェブベースの要求と共にＳＭＳベースまたはＭＭＳベースの応答というように、異なってもよい。
【００７６】
また理解されるべきだが、実施形態はプライバシ制御の一例だけに基づいて、すなわち位置情報と「許可リスト」について、記述してきた。しかし、本発明の中核は、要求の完全性(integrity)に関する制御であり、プライバシまたはアクセスポリシーに限らずあらゆる種類のポリシーの実施に適用することができる。
【００７７】
本明細書の記述および請求項全体を通じて、「ｃｏｍｐｒｉｓｅ（備える）」、「ｉｎｃｌｕｄｅ（含む）」という言葉およびそれらの言葉の変化形、例えば「ｃｏｍｐｒｉｓｉｎｇ（備えている）」、「ｃｏｍｐｒｉｓｅｓ（備える）」は、「含むけれどもそれに限定されない」ことを意味しており、他のコンポーネント、整数またはステップを除外することを意図していない（かつ、除外されない）。
【００７８】
本明細書の記述および請求項全体を通じて、文脈上異なる解釈を要する場合を除き、単数形は複数形も含む。特に、不定冠詞が用いられる場合、文脈上異なる解釈を要する場合を除き、明細書は、単数だけでなく複数も意図すると理解されるべきである。
【００７９】
理解されるべきだが、本発明の実施形態の以上の記述は、例示および説明の目的で提示されたものである。本記述は、網羅的なものではなく、請求された本発明を、まさに開示された形態に限定するものではない。修正形態および変形形態が、上記の記述に照らして可能であるか、または、本発明を実施することから得られうる。請求項およびそれらの均等物が本発明の範囲を定義する。
【技術分野】
【０００１】
本発明は一般に、通信ネットワークにおけるユーザエンティティの検証のための方法およびシステムに関する。詳細には、本発明は、通信ネットワークのプライバシ制御の改良に関する。
【背景技術】
【０００２】
通信技術の発達によって、ユーザは多種多様なネットワークサービスを体験できる。その例示的な一例として、位置情報サービスがある。位置情報サービスとは情報および娯楽サービスであって、モバイルネットワークを通じて移動デバイスを使ってアクセス可能であり、移動デバイスの地理的な位置を利用する機能を活用するものである。モバイルオペレータは、自社のモバイルネットワーク内でエンドユーザの移動デバイスの位置を特定することによって、この種のサービスを提供することができる。位置情報サービスは、例えば、友人（ユーザＡ）は、あなた（ユーザＢ）が偶然近くにいるならば、あなたと昼食を共にしたいと思っているというようなシナリオに大いに役立つであろう。あなたの正確な位置を見つけるため、友人は、あなたのモバイルオペレータが提供するあなたの位置情報にアクセスする必要がある。それ以外にも、友人は、近くのレストランを見つけることにも関心があるだろう。この場合、あなたの友人がアクセスしたいと思っている情報源には、あなたの位置情報とレストランの位置情報とが含まれる。あなたの位置情報とレストランの位置情報とが、友人に公開される。
【０００３】
ＳＰ（サービスプロバイダ）に位置特定機能および／または追従機能を公開すると、例えば最も近い病院を探すこと、友人の位置を知ること、車両を追従すること、更には位置情報ゲームで遊ぶことといった、多くの空想的な(fancy)位置ベースのアプリケーションを促進できるということは事実である。しかし、位置情報はデリケート(sensitive)かつ私的なものであるため、無許可のアクセスは避けられるべきである。モバイルオペレータは、プライバシ保護を保証し、位置インタフェースがサービスプロバイダに公開される場合には重要な役割を担わなければならない。
【０００４】
残念ながら、現行の方法では、個々のユーザをそのユーザについての個別のデータと共に特定することが比較的容易であり、それゆえ、プライバシの懸念が生じている。例えばＰａｒｌａｙ−ＸおよびＭＬＰのような現行の標準および解決策は、プライバシ保護における強力な支援を提供できない。典型的には、ＳＰは、ユーザがオペレータ側でプライバシ設定を行っている時でさえ、なりすまし攻撃をしかけることができるだろう。例えば、ＳＰは、要求の「要求側」フィールドを修正してプライバシ設定を迂回することができる。以下の例は、この種の攻撃を示す：
ユーザＡの以下のプライバシ設定を考えると：
ユーザＢがユーザＡの位置を特定すること‐禁止
ユーザＣがユーザＡの位置を特定すること‐許可
【０００５】
現行の標準および／または解決策では、ＳＰは、ユーザＢがユーザＡの位置を特定しようとする場合に、「要求側」フィールドを「ユーザＣ」に修正することによって、ユーザＡの位置の特定に成功できるように、なりすまし攻撃をしかけることを手伝うことができるであろう。
【０００６】
ＳＰが（ＭＳＩＳＤＮのような）ユーザの実際のＩＤを入手することを避けるため、ユーザの別名または暗号化されたアドレスを用いるといった解決策があるが、それらはすべて、ＳＰのアプリケーションに制限または影響を与える一方で、一部のＳＰのアプリケーションはサービスを完了するために結局実際のユーザＩＤを必要とすることがある。
【０００７】
従って、上記の欠点を克服するため、通信ネットワークにおいてプライバシ制御を実装する方法およびそのためのシステムを提供することが望ましいであろう。
【発明の概要】
【０００８】
従って、ネットワークセキュリティを向上させるために通信ネットワークにプライバシ制御を実装する方法とそのためのシステムとを提供することによって上記の欠点に対処することが、本発明の目的である。
【０００９】
本発明の一態様によって、少なくとも１つのプライバシサーバと少なくとも１つのサービスプロバイダ（ＳＰ）とを含む通信ネットワークにおいてプライバシ制御を実装する方法を提供する。方法は、プライバシサーバにおいてパラメータハッシングまたは非パラメータハッシングを使って各ユーザ要求について第１のＲｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（ＲＶＣ：要求検証コード）を生成し、ユーザ要求を第１のＲＶＣと一緒にＳＰに転送することと、プライバシサーバにおいて第２のＲＶＣおよびユーザプライバシ設定を検証することとを含み、ここで第２のＲＶＣは、更なる要求と一緒にＳＰから受信される。
【００１０】
方法の一実施形態では、プライバシサーバは、第１のＲＶＣを記憶し、その後、要求を転送して、第２のＲＶＣが記憶された第１のＲＶＣと同一であることを検証する。
【００１１】
方法の一実施形態では、非パラメータハッシングが行われる場合、ＲＶＣには検証情報が含まれていないため、（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」を含む）ユーザ要求に関連するパラメータが、更なる検証用にプライバシサーバの中に記憶される。第２のＲＶＣがＳＰから来た場合、パラメータが第２のＲＶＣと一緒にプライバシサーバによってチェックされ、それらが無修正であるか（改竄されていないか）どうか判断される。
【００１２】
方法の一実施形態では、パラメータハッシングが行われる場合、プライバシサーバは第１のＲＶＣを記憶すべきであって、プライバシサーバは、第１のＲＶＣがそれに基づいているパラメータをすでに知っているはずであり（ＲＶＣは少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」に基づくべき）、従って、パラメータを記憶することは不要である。第２のＲＶＣが来た場合、プライバシサーバは、ＳＰからの更なる要求に含まれるパラメータに基づいて新たなＲＶＣを生成し、新たなＲＶＣがＳＰからの第２のＲＶＣと同等であるかどうか判断する。この新たなＲＶＣは、ＳＰからの第２のＲＶＣと同等であるべきであり、かつ、ストレージの中にすでに記憶された第１のＲＶＣとも同等であるべきである。
【００１３】
方法の一実施形態では、第２のＲＶＣとユーザプライバシ設定とを検証することは、更に、第２のＲＶＣは第１のＲＶＣと同等であるかどうかチェックすることと、ユーザ要求を開始しているユーザが、要求されているユーザのユーザプライバシ設定の下で許可されているかどうか検証することとを含む。
【００１４】
パラメータハッシングでは第１のＲＶＣはユーザ要求のパラメータに基づいて生成され、非パラメータハッシングでは第１のＲＶＣはユーザ要求のパラメータに依存しない一意の（固有の）ＩＤであることが望ましい。
【００１５】
方法の一実施形態では、方法は更に、ＳＰが第１のＲＶＣを伴うユーザ要求を受信した後、ＳＰにおいてビジネスロジックを実行することと、ＳＰからの位置要求をＰａｒｌａｙ−Ｘゲートウェイに転送することと、更なる要求を検証するためにＰａｒｌａｙ−Ｘゲートウェイからプライバシサーバへの要求を呼び出す（開始する）こととを含む。
【００１６】
方法の一実施形態では、方法は更に、第２のＲＶＣおよびユーザプライバシ設定が検証された後、要求された情報をＭｏｂｉｌｅ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（ＭＰＳ：モバイルポジショニングシステム）からＰａｒｌａｙ−Ｘゲートウェイに転送することと、要求された情報をＳＰにおいて公開する（開示する）こととを含む。
【００１７】
Ｐａｒｌａｙ−Ｘゲートウェイに転送される更なる要求は、ユーザ要求を開始するユーザを示す「要求者（ｒｅｑｕｅｓｔｏｒ）」と、要求されている別のユーザを示し、位置特定されることになるアドレスとを含むことが望ましい。
【００１８】
ユーザ要求は、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ：ショートメッセージサービス）および／またはＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ：マルチメディアメッセージサービス）を使って開始されることが望ましい。
【００１９】
ユーザ要求は、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ワイヤレスアプリケーションプロトコル）アクセスを使って開始されることが望ましい。
【００２０】
ユーザ要求は、ウェブアクセスを使って開始されることが望ましい。
【００２１】
方法の一実施形態では、ユーザ要求は、Ｐａｒｌａｙ−Ｘゲートウェイと、ＳＭＳＣ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｃｅｎｔｒｅ：ショートメッセージ・サービスセンタ）、および／または、ＭＭＳＣ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｃｅｎｔｒｅ：マルチメディアメッセージ・サービスセンタ）とによってインターセプト（傍受）され、そしてできれば、Ｐａｒｌａｙ−Ｘゲートウェイは、ユーザ要求をインターセプトした後、ユーザ要求が更なる要求を含むかどうか判断し、ユーザ要求が更なる要求を含むならばＲＶＣを生成するようにプライバシサーバに要求することが望ましい。
【００２２】
方法の一実施形態では、ユーザ要求は、ＳＰ ＷＡＰポータルによってインターセプトされ、そしてできれば、ユーザ要求は更なる要求を含むという判断に基づいて第１のＲＶＣが生成されることが望ましい。
【００２３】
方法の一実施形態では、ユーザ要求は、ＳＰウェブポータルによってインターセプトされ、そしてできれば、ユーザ要求を開始するユーザは、ユーザ要求が更なる要求を含む場合にはログインするように要求され、そして、ユーザＩＤとパスワードとの検証に基づいて第１のＲＶＣが生成されることが望ましい。
【００２４】
本発明の別の態様によって、プライバシ制御を提供するための通信システムを提供する。通信システムは、アプリケーションサービスを提供するための少なくとも１つのサービスプロバイダ（ＳＰ）を備えた信用できないサブシステムと、通信サービスを提供するための少なくとも１つのモバイルオペレータモジュールを備えた信用できるサブシステムとを備え、ここでモバイルオペレータモジュールは更に、要求検証コード（ＲＶＣ）を使ってユーザプライバシ制御を提供するための少なくとも１つのモバイルコアネット―クを備える。
【００２５】
通信システムの一実施形態では、モバイルオペレータモジュールは更に、移動ユーザの位置を特定するためのモバイルポジショニングシステム（ＭＰＳ）を備える。
【００２６】
通信システムの一実施形態では、モバイルコアネットワークは、少なくとも１つのＰａｒｌａｙ−Ｘゲートウェイと、前記Ｐａｒｌａｙ−Ｘゲートウェイに結合された少なくとも１つのプライバシサーバとを含む。Ｐａｒｌａｙ−Ｘゲートウェイに関連するプライバシサーバは、パラメータハッシングまたは非パラメータハッシングを使って各ユーザ要求について第１のＲＶＣを生成し、そして、第２のＲＶＣとユーザプライバシ設定とを検証するように構成される。Ｐａｒｌａｙ−Ｘゲートウェイは、ＳＰから更なる要求と第２のＲＶＣとを受信するため、または要求された情報をＳＰに送信するため、または、要求された情報をＳＰに公開するために、ＳＰに結合され、そしてＰａｒｌａｙ−Ｘゲートウェイは更に、更なる要求をＭＰＳに送信して、要求された情報をＭＰＳから受信するために、ＭＰＳに結合される。
【００２７】
方法の一実施形態では、非パラメータハッシングが行われる場合、ＲＶＣには検証情報が含まれていないため、（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」を含む）ユーザ要求に関連するパラメータが、更なる検証用にプライバシサーバの中に記憶される。第２のＲＶＣがＳＰから来た場合、プライバシサーバは、第２のＲＶＣとパラメータとがいずれも無修正であるかどうかチェックする必要がある。
【００２８】
方法の一実施形態では、パラメータハッシングが行われる場合、プライバシサーバは、第１のＲＶＣを記憶すべきであって、プライバシサーバは、ＲＶＣがどのパラメータに基づくかも知っているはずであり（少なくとも「要求者（ｒｅｑｕｅｓｔｏｒ）」に基づくべき）、従って、パラメータを記憶する必要はない。第２のＲＶＣが来た場合、プライバシサーバは、ＳＰからの更なる要求の中のパラメータに基づいて新たなＲＶＣを生成し、新たなＲＶＣがＳＰからの第２のＲＶＣと同等であるかどうか判断する。この新たなＲＶＣは、ＳＰからの第２のＲＶＣと同等であるべきであり、かつ、ストレージの中にすでに記憶された第１のＲＶＣとも同等であるべきである。
【００２９】
パラメータハッシングでは、第１のＲＶＣは、数学的アルゴリズムに従ってユーザ要求のパラメータに基づいて生成されることが望ましく、そして、非パラメータハッシングでは、第１のＲＶＣは、ユーザ要求のパラメータに依存しない一意のＩＤであることが望ましい。
【００３０】
通信システムの一実施形態では、モバイルオペレータモジュールは更に、ＳＭＳおよび／またはＭＭＳを送受信するためにモバイルコアネットワークに関連付けられたＳＭＳＣおよび／またはＭＭＳＣを含む。
【００３１】
通信システムの一実施形態では、Ｐａｒｌａｙ−Ｘゲートウェイは、ＳＭＳおよび／またはＭＭＳをインターセプトするためにＳＭＳＣおよび／またはＭＭＳＣに関連付けられ、そして、Ｐａｒｌａｙ−Ｘゲートウェイは更に、ＳＭＳおよび／またはＭＭＳが更なる要求を含むという判断に基づいて更なる要求を検証する目的でプライバシサーバへの要求を呼び出すために、プライバシサーバに関連づけられる。
【００３２】
通信システムの一実施形態では、プライバシサーバが、第２のＲＶＣの検証を提供するために第２のＲＶＣが第１のＲＶＣと同等であるかどうかチェックするように構成され、プライバシサーバは更に、ユーザ要求を開始しているユーザがユーザプライバシ設定の下で許可されているかどうか判断するように構成される。
【００３３】
通信システムの一実施形態では、ＳＰは更に、プライバシサーバに関連付けられたＳＰウェブポータルを含み、ここでプライバシサーバは、ユーザ要求が更なる要求を含む場合にはログインするようにユーザに要求し、そして、ユーザＩＤとパスワードとの検証に基づいて第１のＲＶＣを生成するように構成される。
【００３４】
通信システムの一実施形態では、ＳＰは更に、プライバシサーバに関連付けられたＳＰワイヤレスアプリケーションプロトコル（ＷＡＰ）ポータルを含み、ここでプライバシサーバは、ユーザ要求が更なる要求を含むという判断に基づいて第１のＲＶＣを生成するように構成される。
【００３５】
本発明の別の態様によって、通信ネットワークにおいてプライバシ保護を実装するための装置を提供するが、装置は、各ユーザ要求について第１の要求検証コード（ＲＶＣ）を生成するための手段と、移動ユーザの位置を特定するための手段と、第２のＲＶＣおよびユーザプライバシ設定を検証するための手段と、前記検証に応じて、要求された情報を公開するための手段とを備える。
【００３６】
本発明の別の態様によって、実行された場合には前記方法を行うような命令を記録した、機械可読媒体を提供する。
【００３７】
本発明の別の態様によって、要求検証コード（ＲＶＣ）および関連するプライバシ制御データ、例えば、パラメータ、許可される単一または複数の利用を生成するタイムスタンプ、利用カウンタ等を記憶するためのデータ構造を提供する。このデータ構造は、プライバシサーバの中に維持されることが望ましい。
【００３８】
本発明による方法およびシステムは、既存のＰａｒｌａｙ−Ｘゲートウェイおよびプライバシサーバのアーキテクチャに基づいて、Ｐａｒｌａｙ−Ｘ仕様の単純な改良とＳＰアプリケーションとの統合を行えば、容易に実装される。更に、ＳＭＳおよびＷＡＰ利用についてはエンドユーザ体験にまったく影響を与えず、ウェブアクセスにおいてもエンドユーザ体験にほとんど影響を与えない。ＳＰアプリケーション開発の観点からは、ユーザのＭＳＩＳＤＮまたは同様の実際のユーザＩＤをＳＰアプリケーションが知ることを防ぐ目的でユーザの別名（エイリアス）を用いる一部のソリューションとは異なり、本発明によるソリューションは、ＳＰアプリケーションがＭＳＩＳＤＮを検索することを妨げず、そしてこれが、ＳＰアプリケーション開発の柔軟性を保つ。
【図面の簡単な説明】
【００３９】
本発明の上記およびその他の態様、特徴、利点は、添付の図面と併せて提示される本発明の下記の詳細記述から一層明らかになるであろう。
図面中、対応する参照文字は、図面の複数の図を通じて対応するコンポーネントを示す。
【図１】プライバシ制御を実装しうる通信ネットワークを例示する簡略化したブロック図である。
【図２】ＳＭＳアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【図３】ＷＡＰアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【図４】ウェブアクセスを使ったシナリオにおいてプライバシ制御を実装した実施形態を例示する例示的なメッセージフローを表す図である。
【発明を実施するための形態】
【００４０】
以下に記述した実施形態は、当業者が本発明を実施できるようにするために必要な情報を表し、本発明を実施する上でのベストモードを図解する。添付の図面の図を考慮に入れて下記の記述を読めば直ちに、当業者なら本発明の概念を理解し、本書で特に取り上げていないこれらの概念の応用例を認識するであろう。理解されるべきだが、これらの概念および応用例は、開示および添付の請求項の範囲内に入る。
【００４１】
本明細書の記述および請求項の全体を通じて、「ＳＰ」という用語は、サービスプロバイダを含むが、それに限定されず、用語「ＳＭＳ」は、ショートメッセージサービスを含むが、それに限定されず、用語「ＭＭＳ」は、マルチメディアサービスを含むが、それに限定されず、用語「ＳＭＳＣ」は、ショートメッセージ・サービスセンタを含むが、それに限定されず、用語「ＭＭＳＣ」は、マルチメディア・サービスセンタを含むが、それに限定されず、用語「ＳＭＰＰ」は、ショートメッセージ・ピア・ツー・ピアを含むが、それに限定されず、用語「ＭＬＰ」は、モバイルロケーションプロトコルを含むが、それに限定されず、用語「ＭＰＳ」は、モバイルポジショニングシステムを含むが、それに限定されず、用語「ＷＡＰ」は、ワイヤレスアプリケーションプロトコルを含むが、それに限定されず、そして、「ＲＶＣ」は、Ｒｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（要求検証コード）を含むが、それに限定されない。
【００４２】
図１は、本発明の一実施形態がその中に実装される通信システムの概略ブロック図である。図示するように、通信システムは２つのサブシステム、すなわち信用できるシステム１００と信用できないシステム２００とを含む。本実施形態では、信用できるサブシステム１００とは、モバイルオペレータ領域のことを言い、更にＰａｒｌａｙ−Ｘゲートウェイ１２０と、プライバシサーバ１４０と、ＭＰＳ１６０とＳＭＳＣ１８０とを備える。信用できないサブシステム２００は、ＳＰ ＷＡＰアプリケーションおよびＳＰウェブアプリケーションのようなアプリケーションサービスを提供するためのＳＰ２１０およびＳＰ２３０を備える。モバイルオペレータ領域では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＭＳおよび／またはＭＭＳを送受信するため、ＳＭＳＣ１８０に接続され、更に、移動ユーザの位置を特定するためＭＰＳ１６０に接続される。更に、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰ２１０および２３０に対して統一されたインタフェースを公開するために用いられる。ＭＰＳ１６０は、モバイルネットワークを使って移動ユーザの位置を特定するために用いることができる。ＳＭＳＣ１８０は、ＳＭＳメッセージを送受信するためにＰａｒｌａｙ−Ｘゲートウェイ１２０に接続される。ＳＭＳＣ１８０は、ＭＭＳを提供するためにＭＭＳＣに変更されてもよい。他方、ＳＰアプリケーションを使ってアプリケーションサービスを提供するために、ＳＰ２１０および２３０が用いられてもよい。そのようなＳＰのアプリケーションの例として、ユーザプレゼンスサービスがある。
【００４３】
当業者であれば、プライバシサーバ１４０のない図１に示すアーキテクチャに詳しいであろう。従って、これらの部分の記述は、本願の実施形態の理解を提供するのに必要な程度に留める。しかし、他方、図１に示すアーキテクチャがプライバシサーバ１４０を含む場合、アーキテクチャの性能と機能とは大幅に改良されている。
【００４４】
プライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に結合されており、ＳＰ２１０および２３０に関連付けられている。
【００４５】
第１にプライバシサーバ１４０は、ユーザプライバシ設定を記憶するために用いることができる。ユーザプライバシ設定の一例が、位置情報のための「許可リスト」であってもよい。例えば、ユーザＢおよびユーザＣが必要に応じてユーザＡの位置を特定できるように、ユーザＡが、ユーザＢとユーザＣとをプライバシサーバ１４０の中の「許可リスト」に設定してもよい。リストの中に存在しない人は、ユーザＡの位置を特定することはできない。
【００４６】
第２に、プライバシサーバ１４０は、Ｒｅｑｕｅｓｔ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ（ＲＶＣ：要求検証コード）と名付けられた一意のコードを生成して検証することによって、本発明の実施形態において重要な役割を果たす。具体的には、ＲＶＣは、各ユーザ要求についてパラメータハッシングまたは非パラメータハッシングを使って生成される。
【００４７】
パラメータハッシングについては、ＲＶＣは、数学的アルゴリズム、例えばＭＤ５に従ってユーザ要求のパラメータに基づいて生成される。このコード生成は、一般に「ハッシング」として知られる。例えば、ユーザＡがチャネルＳＭＳによってユーザＢの位置を特定する要求を出す場合、プライバシサーバは、このユーザ要求の内容に基づいてＲＶＣを生成するであろう。ハッシング用に用いられる情報は、必ずしも要求全体である必要はなく、ユーザＡのＭＳＩＳＤＮ、要求のタイムスタンプ等のような特定の要素（パラメータ）に限定されてもよい。後で要求の完全性(integrity)を検証するため、ハッシングが再度行われるが、以前と同じコードが生じるはずである。
【００４８】
非パラメータハッシングについては、ＲＶＣは、一意のＩＤであってユーザ要求のパラメータには依存しない。この場合、検証とは、特定のパラメータがＩＤと共に記憶され、その後、これらが、要求の中のパラメータと比較されなければならないことを意味する。
【００４９】
上記は、ＲＶＣに関する簡単な紹介にすぎず、詳細記述は、以下で図２、３、４に関連して行う。理解されるべきだが、１つ以上のＰａｒｌａｙ−Ｘゲートウェイ１２０、プライバシサーバ１４０、ＭＰＳ１６０およびＳＭＳＣ１８０ならびにＳＰ２１０および２３０は、ハードウェア、ソフトウェア、またはそれらのいずれかの組み合わせを含んでもよい。少なくとも１つの実施形態では、これらの部分は、以下に論じる方法のステップに対応する動作を実行するための命令を含む。そのような命令は、記憶されたプログラム命令を記憶要素（例えばメモリ）の中に含む、１つ以上のコンピュータプログラムとして具現化されてもよい。
【００５０】
次に図２を参照すると、本発明の一実施形態に関連する通信ネットワーク内の位置プライバシ保護の方法を例示するフローチャートを示す。理解されるべきだが、方法は必ずしも例示されたシーケンスに限定される必要はなく、必要に応じて一部のステップが省略されてもよく、一部のステップが、一緒に行われるかまたは、その他のやり方で相互に関連する形で行われてもよい。
【００５１】
このシナリオでは、ユーザは、ＳＭＳによってユーザ要求を開始する。アプリケーション２１１は、前もって作成されており、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に接続していて、そこに何らかの形で登録されている。キー情報は、「登録」の一部である。アプリケーション２１１は、下記のキー情報と共にＰａｒｌａｙ−Ｘゲートウェイ１２０によって知られる。すなわちキー情報とは、これはＳＭＳアプリケーションであり、これは位置ベースのアプリケーションであり、このＳＭＳアプリケーションをインターセプト（傍受）するか否かを示すフラグが存在し、例えば「ＬＯＣＡＴＥ」のようなインターセプトのためのＳＭＳキーワードが存在する。モバイルオペレータは、この情報をチェックして承認する必要がある。
【００５２】
方法は、ステップＳ２０１で始まり、ここではエンドユーザＢ１１０がユーザＡの位置を特定するためにＳＭＳを送信する。例えば、ＳＭＳの内容は、「ＬＯＣＡＴＥ ４６１９３５７９」であってもよい。ＳＭＳの内容は、ユーザＡについて位置特定が行われることになることを識別する。ＳＭＳＣ１８０は、直ちにＳＭＳを受信し、このＳＭＳを、ステップＳ２０２で、ＳＭＰＰに従って更にＰａｒｌａｙ−Ｘゲートウェイ１２０に転送する。留意されるべきだが、「ＳＭＰＰ」という用語は、序論で概要を述べたように用いられる。実際のＳＭＰＰの代わりに、例えばＵＣＰおよびＭＭ７のような、類似のプロトコルを用いてもよい。ＳＭＳを受信した後、ステップＳ２０３で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＳＭＳの内容をチェックして、ＳＭＳキーワードを比較することによってそれが位置情報サービス要求なのかどうかを判断する。位置要求が存在した場合には、ステップＳ２０４に示すように、ユーザＢ１１０のＭＳＩＳＤＮを持つＲＶＣを入手するためにＰａｒｌａｙ−Ｘゲートウェイ１２０が要求をプライバシサーバ１４０に送信し、そうでない場合、フローはステップＳ２０６に進む。Ｐａｒｌａｙ−Ｘゲートウェイ１２０から要求を受信する場合、プライバシサーバ１４０は、ユーザＢ １１０からのユーザ要求に基づいて第１のＲＶＣを生成し、次いで、ステップＳ２０５に図解するように、第１のＲＶＣをＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。
【００５３】
その後、ステップＳ２０６で、第１のＲＶＣを搬送するＳＭＳが、Ｐａｒｌａｙ−Ｘゲートウェイ１２０によってアプリケーション２１１に転送されるであろう。ＳＭＳがどのようにしてＲＶＣを搬送するかを例示するため、Ｐａｒｌａｙ−Ｘ ＳＭＳの簡単な説明をここで行おう。
【００５４】
本書で示すように、Ｐａｒｌａｙ−Ｘショートメッセージングの仕様では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、動作ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎを用いてＳＭＳをＳＰ２１０（アプリケーション２１１）に転送する。ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎの定義を表１乃至３で示すように簡単に例示する。
【００５５】
【表１】
【００５６】
【表２】
【００５７】
【表３】
【００５８】
表１は、入力メッセージ：ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎＲｅｑｕｅｓｔの定義を提供し、表２は、ＳｍｓＭｅｓｓａｇｅ構造を提供し、表３は、出力メッセージ：ｎｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎＲｅｓｐｏｎｓｅを定義する。
【００５９】
このメッセージの中でＲＶＣを搬送するため、以下のやり方が提供される。すなわち、ｓｅｎｄｅｒＡｄｄｒｅｓｓを使ってＳｍｓＭｅｓｓａｇｅの中にＲＶＣを符号化するかまたは、ＲＶＣを含むようにＳｍｓＭｅｓｓａｇｅを拡張するかまたは、ＳＯＡＰヘッダの中にＲＶＣを追加する。
【００６０】
ステップＳ２０７に戻るが、第１のＲＶＣを搬送するＳＭＳを受信した後、ＳＰアプリケーションは、ＳＭＳを処理して、例えば、ユーザＢが関心を持つ情報を見つけるためにビジネスロジックを実行する。本実施形態では、ユーザＢ１１０はユーザＡの位置情報に関心を持つ。従って、ＳＰアプリケーションは、ステップＳ２０８で、ユーザＡの位置を特定するため、位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信するであろう。
【００６１】
ここで採用される命令は、ｇｅｔＬｏｃａｔｉｏｎ（要求者、アドレス、ＲＶＣ）であり、ここで入力パラメータは、ユーザＢを「要求者」として採用し、ユーザＡを位置特定されることになるアドレスとして採用する。そして、ＲＶＣは、第２のＲＶＣであり、これはＳＰアプリケーションから来る。
【００６２】
明確にするために、用語「ｇｅｔＬｏｃａｔｉｏｎ」を、簡単な紹介として明記する。Ｐａｒｌａｙ−Ｘ Ｔｅｒｍｉｎａｌ Ｌｏｃａｔｉｏｎ仕様では、動作ｇｅｔＬｏｃａｔｉｏｎが、Ｐａｒｌａｙ−Ｘゲートウェイに対して端末位置を要求するために、アプリケーションによって用いられる。ｇｅｔＬｏｃａｔｉｏｎの定義を以下に例示する。
【００６３】
【表４】
【００６４】
【表５】
【００６５】
表４は、入力メッセージの形式を定義し、表５は、出力メッセージの定義を提供する。このメッセージの中でＲＶＣを搬送するには、３つのやり方がありうる。すなわち、要求側と共にＲＶＣを符号化することと、ＲＶＣを含むようにこのメッセージを拡張することと、ＳＯＡＰヘッダ内にＲＶＣを追加することである。更に、同じスキームを他の動作に適用することもできる。例えば、ｇｅｔＴｅｒｍｉｎａｌＤｉｓｔａｎｃｅ、ｇｅｔＬｏｃａｔｉｏｎＦｏｒＧｒｏｕｐ、ｓｔａｒｔＧｅｏｇｒａｐｈｉｃａｌＮｏｔｉｆｉｃａｔｉｏｎ、ｓｔａｒｔＰｅｒｉｏｄｉｃＮｏｔｉｆｉｃａｔｉｏｎである。
【００６６】
ステップＳ２０９に戻ると、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、第２のＲＶＣを検証するために、要求をプライバシサーバ１４０に提出する。同様に、入力パラメータには、要求者（ユーザＢ）と、位置特定されることになるアドレス（ユーザＡ）と、第２のＲＶＣとが含まれる。次いでステップＳ２１０で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのＳＭＳ要求から来た正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じであるかどうかをチェックする。更に、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答して、その後、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。それが「真」である場合、すなわち、ＲＶＣが正しく、そして、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ２１１に示すように、位置要求を「ＭＬＰ．Ｌｏｃａｔｅ（アドレス）」の形式でＭＰＳ１６０に送信する。そうではなく、第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。それに続いて、ステップＳ２１２で、ＭＰＳ１６０は、ユーザＡの位置情報を発見して、それをＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ２１３で、ユーザＡの位置をＳＰアプリケーション２１１に転送する。その後、ステップＳ２１４で、ＳＰアプリケーション２１１は、位置情報またはサービス情報をユーザＡの位置情報に基づいてＳＭＳによってＰａｒｌａｙ−Ｘゲートウェイ１２０に送信する。最後に、ステップＳ２１５およびＳ２１６に示すように、Ｐａｒｌａｙ−Ｘゲートウェイ１２０はＳＭＳをＳＭＳＣ１８０に送信し、ＳＭＳＣ１８０は、ＳＭＳをユーザＢ１１０に更に転送する。上記のステップに従って、ユーザＢ１１０は、最後に、ＳＭＳを使ってユーザＡの位置情報を受信する。
【００６７】
上記の実施形態では、ＲＶＣの寿命は、期限切れ時刻および最大回数に依存してもよい。期限切れ時刻とは、１つのＲＶＣが作成された後の一定期間それを使用することができるということを意味する。例えば、それが２時間使用されてもよい。最大回数とは、１つのＲＶＣを１回または複数回使用することができるということを意味する。いずれのパラメータも、Ｐａｒｌａｙ−Ｘゲートウェイの中で構成することができ、プライバシサーバは、これらのパラメータに従って適切なＲＶＣを生成することができる。
【００６８】
本発明の一態様による別の実施形態は、ユーザＢ１１０がＷＡＰアクセスを使ってユーザＡの位置を受信することもできる一シナリオを例示する。このシナリオでは、ＳＰ位置ＷＡＰ ＵＲＬがプライバシサーバ１４０によって設定される。
【００６９】
本実施形態では、最初に、ユーザＢ１１０がＳＰ ＷＡＰポータルに入り、そして、ユーザＡを選択して位置を特定するためにＷＡＰページを閲覧する。次いでステップＳ３０２で、ＳＰ ＷＡＰポータルが、プライバシサーバ１４０のＷＡＰ ＵＲＬにリダイレクトする。プライバシサーバ１４０は、ＳＰ ＷＡＰポータルからのＵＲＬを検証して、それが位置についてのＵＲＬであることを確信し、そして、ステップＳ３０３で、移動端末のブラウザからユーザのＭＳＩＳＤＮを検索する。
【００７０】
次のステップＳ３０４で、プライバシサーバ１４０は、ユーザのＭＳＩＳＤＮを入手して、要求セッションを作成する。更に、プライバシサーバ１４０は、セッションについての第１のＲＶＣを生成する。ステップＳ３０５では、プライバシサーバ１４０は、第１のＲＶＣと共にＳＰ ＷＡＰポータルへリダイレクトして戻る。ステップＳ３０６で、ＳＰ ＷＡＰアプリケーション２１２が、ビジネスロジックを実行する。ステップＳ３０７では、ＳＰ ＷＡＰアプリケーション２１２が、ユーザＡの位置を特定するため位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信し、入力パラメータには、要求者としてユーザＢ、位置特定されることになるアドレスとしてユーザＡ、そしてＲＶＣが含まれる。ステップＳ３０８では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＲＶＣを検証するためにプライバシサーバ１４０への要求を呼び出し、ここで入力パラメータには、要求者がユーザＢとして、位置が特定されることになるアドレスがユーザＡとして、そして第２のＲＶＣが含まれる。次いでステップＳ３０９で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのＷＡＰ要求の中にある正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じかどうかをチェックする。加えて、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答し、その後Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。これが「真」である場合、すなわち、ＲＶＣが正しくて、かつ、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ３１０に示す「ＭＬＰ．Ｌｏｃａｔｅ（ａｄｄｒｅｓｓ）」の形式で、位置要求をＭＰＳ１６０に送信する。第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。ＲＶＣが正しく、かつ、ユーザプライバシ設定が検証された場合には、ステップＳ３１１で示すように、ＭＰＳ１６０が、ユーザＡの位置をＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。最後に、ステップＳ３１２およびＳ３１３で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ユーザＡの位置をＳＰ ＷＡＰアプリケーション２１２に返信し、ＳＰ ＷＡＰアプリケーション２１２は、位置情報またはサービス情報をユーザＡの位置情報に基づいてＷＡＰポータルにおいてユーザＢ１１０に示す。上記のステップに従って、ユーザＢ１１０は最後に、ＷＡＰアクセスを使ってユーザＡの位置情報を入手する。
【００７１】
本発明の一態様による別の代替実施形態は、ユーザＢがユーザＡの位置情報をウェブアクセスを使って入手しようとするシナリオを例示する。このシナリオでは、ＳＰ位置ウェブＵＲＬが、プライバシサーバ１４０によって設定され、更に、ユーザＢ１１０は、プライバシサーバ１４０のウェブポータルの中に登録すべきである。
【００７２】
本実施形態では、方法のメッセージフローは、ＷＡＰアクセスとして実装されている前の実施形態とは、主にステップＳ４０１乃至Ｓ４０６において異なる。具体的には、最初に、同様に、ユーザＢ１１０がＳＰウェブポータルに入り、そして、ユーザＡを選択して位置を特定するためにウェブページを閲覧する。次いで、ステップＳ４０２で、ＳＰウェブポータルが、プライバシサーバ１４０のウェブＵＲＬにリダイレクトする。プライバシサーバ１４０は、ＳＰウェブポータルからのＵＲＬを検証して、それが位置についてのＵＲＬであることを確信し、そして、ステップＳ４０３で、ユーザＢ１１０にログインするように要求する。ステップＳ４０４で、ユーザＢ１１０は、自分のユーザＩＤ（ＭＳＩＳＤＮ）とパスワードを使ってログインするはずである。ユーザＩＤとパスワードとの検証に成功した後、プライバシサーバ１４０は、ステップＳ４０５で要求セッションを作成する。更に、プライバシサーバ１４０は、このセッションについての第１のＲＶＣを生成する。ステップＳ４０６で、プライバシサーバ１４０は、第１のＲＶＣと共にＳＰウェブポータルへリダイレクトして戻る。
【００７３】
以下のステップは、前の実施形態で記述したものと同様である。ステップＳ４０７で、ＳＰウェブアプリケーション２１３が、ビジネスロジックを実行する。ステップＳ４０８では、ＳＰウェブアプリケーション２１３が、ユーザＡの位置を特定するため位置要求をＰａｒｌａｙ−Ｘゲートウェイ１２０に送信し、入力パラメータには、要求者としてユーザＢが、位置特定されることになるアドレスとしてユーザＡが、そしてＲＶＣが含まれる。ステップＳ４０９では、Ｐａｒｌａｙ−Ｘゲートウェイ１２０が、ＲＶＣを検証するためにプライバシサーバへの要求を呼び出し、ここで入力パラメータには、要求者がユーザＢとして、位置が特定されることになるアドレスがユーザＡとして、そして第２のＲＶＣが含まれる。次いでステップＳ４１０で、プライバシサーバ１４０は、第２のＲＶＣが、ユーザＢ１１０からのウェブ要求の中にある正しいものであるかどうかをチェックする。言い換えると、プライバシサーバ１４０は、第２のＲＶＣが第１のＲＶＣと同じかどうかをチェックする。加えて、プライバシサーバ１４０は、ユーザＢ１１０がユーザＡの許可リストの中にあるかどうかもチェックする。次いでプライバシサーバ１４０は、Ｐａｒｌａｙ−Ｘゲートウェイ１２０に応答し、その後Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、プライバシサーバ１４０からの応答をチェックするであろう。これが「真」である場合、すなわち、ＲＶＣが正しくて、かつ、ユーザプライバシ設定が検証された場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ステップＳ４１１に示す「ＭＬＰ．Ｌｏｃａｔｅ（ａｄｄｒｅｓｓ）」の形式で、位置要求をＭＰＳ１６０に送信する。第２のＲＶＣが第１のＲＶＣと同等でない場合、すなわち、ＲＶＣが壊れたか失われた場合には、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ＳＰアプリケーションに失敗応答を送信する。ＲＶＣが正しく、かつ、ユーザプライバシ設定が検証された場合には、ステップＳ３１１で示すように、ＭＰＳ１６０が、ユーザＡの位置をＰａｒｌａｙ−Ｘゲートウェイ１２０に返信する。最後に、ステップＳ４１３およびＳ４１４で、Ｐａｒｌａｙ−Ｘゲートウェイ１２０は、ユーザＡの位置をＳＰウェブアプリケーション２１３に返信し、ＳＰウェブアプリケーション２１３は、ユーザＡの位置情報またはサービス情報をウェブポータルにおいてユーザＢ１１０に示す。上記のステップに従って、ユーザＢ１１０は最後に、ウェブアクセスを使ってユーザＡの位置情報を入手する。
【００７４】
結果として、通信ネットワークのセキュリティ性能が大いに向上する。図２乃至３に例示した方法は、移動無線ネットワークに適用されるだけでなく、有線ネットワークにも、あるいは、無線ネットワークと有線ネットワークとの組み合わせに基づく通信ネットワークにも適用される。
【００７５】
分かりやすいように、実施形態では、要求および応答に適用されるチャネルタイプは同じであるとして提示してきた。実際には、本発明の中核から逸脱することなく、これらは、ウェブベースの要求と共にＳＭＳベースまたはＭＭＳベースの応答というように、異なってもよい。
【００７６】
また理解されるべきだが、実施形態はプライバシ制御の一例だけに基づいて、すなわち位置情報と「許可リスト」について、記述してきた。しかし、本発明の中核は、要求の完全性(integrity)に関する制御であり、プライバシまたはアクセスポリシーに限らずあらゆる種類のポリシーの実施に適用することができる。
【００７７】
本明細書の記述および請求項全体を通じて、「ｃｏｍｐｒｉｓｅ（備える）」、「ｉｎｃｌｕｄｅ（含む）」という言葉およびそれらの言葉の変化形、例えば「ｃｏｍｐｒｉｓｉｎｇ（備えている）」、「ｃｏｍｐｒｉｓｅｓ（備える）」は、「含むけれどもそれに限定されない」ことを意味しており、他のコンポーネント、整数またはステップを除外することを意図していない（かつ、除外されない）。
【００７８】
本明細書の記述および請求項全体を通じて、文脈上異なる解釈を要する場合を除き、単数形は複数形も含む。特に、不定冠詞が用いられる場合、文脈上異なる解釈を要する場合を除き、明細書は、単数だけでなく複数も意図すると理解されるべきである。
【００７９】
理解されるべきだが、本発明の実施形態の以上の記述は、例示および説明の目的で提示されたものである。本記述は、網羅的なものではなく、請求された本発明を、まさに開示された形態に限定するものではない。修正形態および変形形態が、上記の記述に照らして可能であるか、または、本発明を実施することから得られうる。請求項およびそれらの均等物が本発明の範囲を定義する。
【特許請求の範囲】
【請求項１】
少なくとも１つのプライバシサーバ（１４０）と少なくとも１つのサービスプロバイダ（ＳＰ）（２１０）とを含む通信ネットワークにおいてプライバシ制御を実装する方法であって、
前記プライバシサーバ（１４０）において、ユーザ要求の各々についてパラメータハッシングまたは非パラメータハッシングを用いて第１の要求検証コード（ＲＶＣ）を生成し、前記ユーザ要求を前記第１のＲＶＣと共に前記ＳＰ（２１０）へ転送するステップと、
前記プライバシサーバ（１４０）において、前記ＳＰ（２１０）から更なる要求と共に受信した第２のＲＶＣと、ユーザプライバシ設定とを検証するステップと、
を備えることを特徴とする方法。
【請求項２】
前記プライバシサーバ（１４０）は、前記第１のＲＶＣを記憶した後に、前記ユーザ要求を転送して、前記第２のＲＶＣが前記記憶した第１のＲＶＣに等しいかを検証する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記非パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）において前記ユーザ要求に関連するパラメータが更なる検証のために記憶され、前記第２のＲＶＣと共に前記パラメータが前記プライバシサーバ（１４０）によってチェックされてこれらが改竄されていないかどうか判断される
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）は、前記ＳＰ（２１０）からの前記更なる要求中のパラメータに基づいて新たなＲＶＣを生成し、前記新たなＲＶＣが前記ＳＰ（２１０）からの前記第２のＲＶＣに等しいか否かを判断する
ことを特徴とする請求項１に記載の方法。
【請求項５】
ユーザプライバシ設定を検証する前記ステップは、前記ユーザ要求を開始したユーザが要求されたユーザのユーザプライバシ設定の下で許可されているか否かを検証するステップを更に含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記パラメータハッシングにおいて、前記ユーザ要求のパラメータに基づいて前記第１のＲＶＣが生成される
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記非パラメータハッシングにおいて、前記第１のＲＶＣは、前記ユーザ要求のパラメータに依存しない固有ＩＤである
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記ユーザ要求は位置情報に関連する
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記ＳＰ（２１０）が前記ユーザ要求および前記第１のＲＶＣを受信した後に、前記ＳＰ（２１０）においてビジネスロジックを実行するステップと、
前記ＳＰ（２１０）からの前記更なる要求をＰａｒｌａｙ−Ｘゲートウェイ（１２０）へ転送するステップと、
前記更なる要求を検証するために、前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）から前記プライバシサーバ（１４０）への要求を開始するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記第２のＲＶＣおよび前記ユーザプライバシ設定が検証された後に、要求された情報をモバイルポジショニングシステム（ＭＰＳ）（１６０）からＰａｒｌａｙ−Ｘゲートウェイ（１２０）へ転送するステップと、
前記要求された情報を前記ＳＰ（２１０）に対して開示するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）へと転送される前記更なる要求は、前記ユーザ要求を開始したユーザを示す「要求者（ｒｅｑｕｅｓｔｏｒ）」と、要求されるユーザを示す、位置特定されるアドレスと、を含む
ことを特徴とする請求項９に記載の方法。
【請求項１２】
前記ユーザ要求は、ショートメッセージサービス（ＳＭＳ）およびマルチメディアメッセージサービス（ＭＭＳ）のうちの少なくとも一方を用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記ユーザ要求は、ワイヤレスアプリケーションプロトコル（ＷＡＰ）アクセスを用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１４】
前記ユーザ要求は、ウェブアクセスを用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１５】
前記ユーザ要求は、Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）と、ショートメッセージ・サービスセンタ（ＳＭＳＣ）およびマルチメディアメッセージ・サービスセンタ（ＭＭＳＣ）（１８０）のうちの少なくとも一方と、によって傍受される
ことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、前記プライバシサーバ（１４０）に対して、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて前記第１のＲＶＣを生成するように要求する
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ユーザ要求は、ＳＰ ＷＡＰポータルによって傍受される
ことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記第１のＲＶＣは、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて生成される
ことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記ユーザ要求は、ＳＰウェブポータルによって傍受される
ことを特徴とする請求項１４に記載の方法。
【請求項２０】
前記ユーザ要求が前記更なる要求を含む場合、前記ユーザ要求を開始するユーザは、ログインするように要求され、
前記第１のＲＶＣは、ユーザＩＤおよびパスワードの検証に基づいて生成される
ことを特徴とする請求項１４に記載の方法。
【請求項２１】
プライバシ制御を提供するための通信システムであって、
アプリケーションサービスを提供する少なくとも１つのサービスプロバイダ（ＳＰ）（２１０）を含む信用できないサブシステム（２００）と、
通信サービスを提供する少なくとも１つのモバイルオペレータモジュールを含む信用できるサブシステム（１００）と、
を備え、
前記モバイルオペレータモジュールは更に、要求検証コード（ＲＶＣ）を用いてユーザのプライバシ制御を提供する少なくとも１つのモバイルコアネットワークを含む
ことを特徴とする通信システム。
【請求項２２】
前記モバイルオペレータモジュールは更に、移動ユーザの位置を特定するモバイルポジショニングシステム（ＭＰＳ）（１６０）を含む
ことを特徴とする請求項２１に記載の通信システム。
【請求項２３】
前記モバイルコアネットワークは、少なくとも１つのＰａｒｌａｙ−Ｘゲートウェイ（１２０）および少なくとも１つのプライバシサーバ（１４０）を含み、
前記プライバシサーバ（１４０）は、ユーザ要求の各々についてパラメータハッシングまたは非パラメータハッシングを用いて第１のＲＶＣを生成し、第２のＲＶＣおよびユーザプライバシ設定を検証するように構成され、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、更なる要求および前記第２のＲＶＣを前記ＳＰ（２１０）から受信する、または要求された情報を前記ＳＰ（２１０）に送信するために、あるいは、前記要求された情報を前記ＳＰ（２１０）に開示するために、前記ＳＰ（２１０）に結合され、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は更に、前記更なる要求を前記ＭＰＳ（１６０）に送信して前記要求された情報を前記ＭＰＳ（１６０）から受信するために前記ＭＰＳ（１６０）に結合される
ことを特徴とする請求項２２に記載の通信システム。
【請求項２４】
前記プライバシサーバ（１４０）は、前記第１のＲＶＣを記憶した後に、前記ユーザ要求を転送して、前記第２のＲＶＣが前記記憶した第１のＲＶＣに等しいかを検証する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２５】
前記非パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）において前記ユーザ要求に関連するパラメータが検証のために記憶され、前記第２のＲＶＣと共に前記パラメータが前記プライバシサーバ（１４０）によってチェックされてこれらが改竄されていないかどうか判断される
ことを特徴とする請求項２３に記載の通信システム。
【請求項２６】
前記パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）は、前記ＳＰからの前記更なる要求中のパラメータに基づいて新たなＲＶＣを生成し、前記新たなＲＶＣが前記ＳＰからの前記第２のＲＶＣに等しいか否かを判断する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２７】
前記ユーザ要求は位置情報に関連する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２８】
前記パラメータハッシングにおいて、前記ユーザ要求のパラメータに基づいて前記第１のＲＶＣが生成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項２９】
前記非パラメータハッシングにおいて、前記第１のＲＶＣは、前記ユーザ要求のパラメータに依存しない固有ＩＤである
ことを特徴とする請求項２３に記載の通信システム。
【請求項３０】
前記モバイルオペレータモジュールは更に、ショートメッセージサービス（ＳＭＳ）およびマルチメディアメッセージサービス（ＭＭＳ）のうちの少なくとも一方を送受信するために、前記モバイルコアネットワークに関連付けられたショートメッセージ・サービスセンタ（ＳＭＳＣ）およびマルチメディアメッセージ・サービスセンタ（ＭＭＳＣ）（１８０）のうちの少なくとも一方を含む
ことを特徴とする請求項２３に記載の通信システム。
【請求項３１】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、ＳＭＳおよびＭＭＳの少なくとも一方を傍受するために、前記ＳＭＳＣおよび前記ＭＭＳＣ（１８０）のうちの少なくとも一方に関連付けられ、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は更に、前記プライバシサーバ（１４０）に対して、前記ＳＭＳおよび前記ＭＭＳのうちの少なくとも一方が前記更なる要求を含んでいるという判断に基づいて前記更なる要求を検証することを求める要求を開始するために、前記プライバシサーバ（１４０）に関連付けられる
ことを特徴とする請求項３０に記載の通信システム。
【請求項３２】
前記プライバシサーバ（１４０）は、前記第２のＲＶＣが前記第１のＲＶＣに等しいか否かをチェックすることによって前記第２のＲＶＣを検証するように構成され、
前記プライバシサーバ（１４０）は更に、前記ユーザ要求を開始したユーザが要求されたユーザのユーザプライバシ設定の下で許可されているか否かを判断することによって前記ユーザプライバシ設定を検証するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３３】
前記ＳＰ（２１０）は更に、前記プライバシサーバ（１４０）に関連付けられたＳＰウェブポータルを含み、
前記プライバシサーバ（１４０）は、前記ユーザ要求が前記更なる要求を含む場合にユーザに対してログインするように要求し、ユーザＩＤおよびパスワードの検証に基づいて前記第１のＲＶＣを生成するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３４】
前記ＳＰ（２１０）は更に、前記プライバシサーバ（１４０）に関連付けられたＳＰワイヤレスアプリケーションプロトコル（ＷＡＰ）ポータルを含み、
前記プライバシサーバ（１４０）は、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて前記第１のＲＶＣを生成するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３５】
通信ネットワークにおいてプライバシ保護を実装するための装置であって、
ユーザ要求の各々について第１の要求検証コード（ＲＶＣ）を生成する手段と、
移動ユーザの位置を特定する手段と、
第２のＲＶＣおよびユーザプライバシ設定を検証する手段と、
前記検証に応えて、要求された情報を開示する手段と、
を備えることを特徴とする装置。
【請求項３６】
実行された場合に請求項１乃至２０のいずれか１項に記載の方法を実行する命令を記録した機械可読媒体。
【請求項３７】
請求項１乃至２０のいずれか１項に記載の方法および請求項２１乃至３４のいずれか１項に記載の通信システムにおいて要求検証コード（ＲＶＣ）および関連するプライバシ制御データを記憶するためのデータ構造。
【請求項１】
少なくとも１つのプライバシサーバ（１４０）と少なくとも１つのサービスプロバイダ（ＳＰ）（２１０）とを含む通信ネットワークにおいてプライバシ制御を実装する方法であって、
前記プライバシサーバ（１４０）において、ユーザ要求の各々についてパラメータハッシングまたは非パラメータハッシングを用いて第１の要求検証コード（ＲＶＣ）を生成し、前記ユーザ要求を前記第１のＲＶＣと共に前記ＳＰ（２１０）へ転送するステップと、
前記プライバシサーバ（１４０）において、前記ＳＰ（２１０）から更なる要求と共に受信した第２のＲＶＣと、ユーザプライバシ設定とを検証するステップと、
を備えることを特徴とする方法。
【請求項２】
前記プライバシサーバ（１４０）は、前記第１のＲＶＣを記憶した後に、前記ユーザ要求を転送して、前記第２のＲＶＣが前記記憶した第１のＲＶＣに等しいかを検証する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記非パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）において前記ユーザ要求に関連するパラメータが更なる検証のために記憶され、前記第２のＲＶＣと共に前記パラメータが前記プライバシサーバ（１４０）によってチェックされてこれらが改竄されていないかどうか判断される
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）は、前記ＳＰ（２１０）からの前記更なる要求中のパラメータに基づいて新たなＲＶＣを生成し、前記新たなＲＶＣが前記ＳＰ（２１０）からの前記第２のＲＶＣに等しいか否かを判断する
ことを特徴とする請求項１に記載の方法。
【請求項５】
ユーザプライバシ設定を検証する前記ステップは、前記ユーザ要求を開始したユーザが要求されたユーザのユーザプライバシ設定の下で許可されているか否かを検証するステップを更に含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記パラメータハッシングにおいて、前記ユーザ要求のパラメータに基づいて前記第１のＲＶＣが生成される
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記非パラメータハッシングにおいて、前記第１のＲＶＣは、前記ユーザ要求のパラメータに依存しない固有ＩＤである
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記ユーザ要求は位置情報に関連する
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記ＳＰ（２１０）が前記ユーザ要求および前記第１のＲＶＣを受信した後に、前記ＳＰ（２１０）においてビジネスロジックを実行するステップと、
前記ＳＰ（２１０）からの前記更なる要求をＰａｒｌａｙ−Ｘゲートウェイ（１２０）へ転送するステップと、
前記更なる要求を検証するために、前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）から前記プライバシサーバ（１４０）への要求を開始するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記第２のＲＶＣおよび前記ユーザプライバシ設定が検証された後に、要求された情報をモバイルポジショニングシステム（ＭＰＳ）（１６０）からＰａｒｌａｙ−Ｘゲートウェイ（１２０）へ転送するステップと、
前記要求された情報を前記ＳＰ（２１０）に対して開示するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）へと転送される前記更なる要求は、前記ユーザ要求を開始したユーザを示す「要求者（ｒｅｑｕｅｓｔｏｒ）」と、要求されるユーザを示す、位置特定されるアドレスと、を含む
ことを特徴とする請求項９に記載の方法。
【請求項１２】
前記ユーザ要求は、ショートメッセージサービス（ＳＭＳ）およびマルチメディアメッセージサービス（ＭＭＳ）のうちの少なくとも一方を用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記ユーザ要求は、ワイヤレスアプリケーションプロトコル（ＷＡＰ）アクセスを用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１４】
前記ユーザ要求は、ウェブアクセスを用いて開始される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１５】
前記ユーザ要求は、Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）と、ショートメッセージ・サービスセンタ（ＳＭＳＣ）およびマルチメディアメッセージ・サービスセンタ（ＭＭＳＣ）（１８０）のうちの少なくとも一方と、によって傍受される
ことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、前記プライバシサーバ（１４０）に対して、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて前記第１のＲＶＣを生成するように要求する
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ユーザ要求は、ＳＰ ＷＡＰポータルによって傍受される
ことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記第１のＲＶＣは、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて生成される
ことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記ユーザ要求は、ＳＰウェブポータルによって傍受される
ことを特徴とする請求項１４に記載の方法。
【請求項２０】
前記ユーザ要求が前記更なる要求を含む場合、前記ユーザ要求を開始するユーザは、ログインするように要求され、
前記第１のＲＶＣは、ユーザＩＤおよびパスワードの検証に基づいて生成される
ことを特徴とする請求項１４に記載の方法。
【請求項２１】
プライバシ制御を提供するための通信システムであって、
アプリケーションサービスを提供する少なくとも１つのサービスプロバイダ（ＳＰ）（２１０）を含む信用できないサブシステム（２００）と、
通信サービスを提供する少なくとも１つのモバイルオペレータモジュールを含む信用できるサブシステム（１００）と、
を備え、
前記モバイルオペレータモジュールは更に、要求検証コード（ＲＶＣ）を用いてユーザのプライバシ制御を提供する少なくとも１つのモバイルコアネットワークを含む
ことを特徴とする通信システム。
【請求項２２】
前記モバイルオペレータモジュールは更に、移動ユーザの位置を特定するモバイルポジショニングシステム（ＭＰＳ）（１６０）を含む
ことを特徴とする請求項２１に記載の通信システム。
【請求項２３】
前記モバイルコアネットワークは、少なくとも１つのＰａｒｌａｙ−Ｘゲートウェイ（１２０）および少なくとも１つのプライバシサーバ（１４０）を含み、
前記プライバシサーバ（１４０）は、ユーザ要求の各々についてパラメータハッシングまたは非パラメータハッシングを用いて第１のＲＶＣを生成し、第２のＲＶＣおよびユーザプライバシ設定を検証するように構成され、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、更なる要求および前記第２のＲＶＣを前記ＳＰ（２１０）から受信する、または要求された情報を前記ＳＰ（２１０）に送信するために、あるいは、前記要求された情報を前記ＳＰ（２１０）に開示するために、前記ＳＰ（２１０）に結合され、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は更に、前記更なる要求を前記ＭＰＳ（１６０）に送信して前記要求された情報を前記ＭＰＳ（１６０）から受信するために前記ＭＰＳ（１６０）に結合される
ことを特徴とする請求項２２に記載の通信システム。
【請求項２４】
前記プライバシサーバ（１４０）は、前記第１のＲＶＣを記憶した後に、前記ユーザ要求を転送して、前記第２のＲＶＣが前記記憶した第１のＲＶＣに等しいかを検証する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２５】
前記非パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）において前記ユーザ要求に関連するパラメータが検証のために記憶され、前記第２のＲＶＣと共に前記パラメータが前記プライバシサーバ（１４０）によってチェックされてこれらが改竄されていないかどうか判断される
ことを特徴とする請求項２３に記載の通信システム。
【請求項２６】
前記パラメータハッシングが実行される場合、前記プライバシサーバ（１４０）は、前記ＳＰからの前記更なる要求中のパラメータに基づいて新たなＲＶＣを生成し、前記新たなＲＶＣが前記ＳＰからの前記第２のＲＶＣに等しいか否かを判断する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２７】
前記ユーザ要求は位置情報に関連する
ことを特徴とする請求項２３に記載の通信システム。
【請求項２８】
前記パラメータハッシングにおいて、前記ユーザ要求のパラメータに基づいて前記第１のＲＶＣが生成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項２９】
前記非パラメータハッシングにおいて、前記第１のＲＶＣは、前記ユーザ要求のパラメータに依存しない固有ＩＤである
ことを特徴とする請求項２３に記載の通信システム。
【請求項３０】
前記モバイルオペレータモジュールは更に、ショートメッセージサービス（ＳＭＳ）およびマルチメディアメッセージサービス（ＭＭＳ）のうちの少なくとも一方を送受信するために、前記モバイルコアネットワークに関連付けられたショートメッセージ・サービスセンタ（ＳＭＳＣ）およびマルチメディアメッセージ・サービスセンタ（ＭＭＳＣ）（１８０）のうちの少なくとも一方を含む
ことを特徴とする請求項２３に記載の通信システム。
【請求項３１】
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は、ＳＭＳおよびＭＭＳの少なくとも一方を傍受するために、前記ＳＭＳＣおよび前記ＭＭＳＣ（１８０）のうちの少なくとも一方に関連付けられ、
前記Ｐａｒｌａｙ−Ｘゲートウェイ（１２０）は更に、前記プライバシサーバ（１４０）に対して、前記ＳＭＳおよび前記ＭＭＳのうちの少なくとも一方が前記更なる要求を含んでいるという判断に基づいて前記更なる要求を検証することを求める要求を開始するために、前記プライバシサーバ（１４０）に関連付けられる
ことを特徴とする請求項３０に記載の通信システム。
【請求項３２】
前記プライバシサーバ（１４０）は、前記第２のＲＶＣが前記第１のＲＶＣに等しいか否かをチェックすることによって前記第２のＲＶＣを検証するように構成され、
前記プライバシサーバ（１４０）は更に、前記ユーザ要求を開始したユーザが要求されたユーザのユーザプライバシ設定の下で許可されているか否かを判断することによって前記ユーザプライバシ設定を検証するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３３】
前記ＳＰ（２１０）は更に、前記プライバシサーバ（１４０）に関連付けられたＳＰウェブポータルを含み、
前記プライバシサーバ（１４０）は、前記ユーザ要求が前記更なる要求を含む場合にユーザに対してログインするように要求し、ユーザＩＤおよびパスワードの検証に基づいて前記第１のＲＶＣを生成するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３４】
前記ＳＰ（２１０）は更に、前記プライバシサーバ（１４０）に関連付けられたＳＰワイヤレスアプリケーションプロトコル（ＷＡＰ）ポータルを含み、
前記プライバシサーバ（１４０）は、前記ユーザ要求が前記更なる要求を含んでいるという判断に基づいて前記第１のＲＶＣを生成するように構成される
ことを特徴とする請求項２３に記載の通信システム。
【請求項３５】
通信ネットワークにおいてプライバシ保護を実装するための装置であって、
ユーザ要求の各々について第１の要求検証コード（ＲＶＣ）を生成する手段と、
移動ユーザの位置を特定する手段と、
第２のＲＶＣおよびユーザプライバシ設定を検証する手段と、
前記検証に応えて、要求された情報を開示する手段と、
を備えることを特徴とする装置。
【請求項３６】
実行された場合に請求項１乃至２０のいずれか１項に記載の方法を実行する命令を記録した機械可読媒体。
【請求項３７】
請求項１乃至２０のいずれか１項に記載の方法および請求項２１乃至３４のいずれか１項に記載の通信システムにおいて要求検証コード（ＲＶＣ）および関連するプライバシ制御データを記憶するためのデータ構造。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１２−５１７７５４（Ｐ２０１２−５１７７５４Ａ）
【公表日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−５４９４１２（Ｐ２０１１−５４９４１２）
【出願日】平成２１年２月１３日（２００９．２．１３）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０００１５１
【国際公開番号】ＷＯ２０１０／０９１５３４
【国際公開日】平成２２年８月１９日（２０１０．８．１９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２１年２月１３日（２００９．２．１３）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０００１５１
【国際公開番号】ＷＯ２０１０／０９１５３４
【国際公開日】平成２２年８月１９日（２０１０．８．１９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]