図1Bは、複数の通信事業者が存在する環境下におけるPNMソリューションである、本発明の全体システムを示す。複数の通信事業者が存在する環境下におけるPNMソリューションは、マスターデバイス16、PNM11、プロキシ12、およびゲストデバイス18により構成される。
マスターデバイス16は、パーソナルネットワーク内のデバイスであり、パーソナルネットワーク内のデバイスの登録および登録解除、アクセス制御など(ただしこれらに限定されない)の管理能力を持つ。
パーソナルネットワーク管理(PNM)11は、ユーザのパーソナルネットワークを管理するエンティティであり、複数のデバイスがそれぞれの場所に関係なくシームレスな接続によって互いに通信できるようにする。パーソナルネットワーク管理(PNM)は、アクセス制御手法を使用可能にすることによって、ユーザが自身のパーソナルネットワークを制御できるようにする。
プロキシ12は、デバイス認証を提供するPNMとさらに複数の通信事業者間の通信を最適化するためのフィルタリングメカニズムをサポートするエンティティである。プロキシの目的は、通信事業者間の通信量を最小に抑え、それによりコアネットワークの負担を減少させること、認証機能を信頼性のある各ドメインに分散すること、さらにセキュアなルーティング性を確保することである。プロキシ12は、通信事業者によってホストされるが、その通信事業者に加入しているデバイスが他の通信事業者によって管理されるPNにゲストデバイス18として登録され得る。
ゲストデバイス18は、外部通信事業者に加入しているクライアントのデバイスであり、ホーム通信事業者によって管理されているパーソナルネットワークへのアクセスを取得する。
本発明の理解を助けるため、以下に主要な用語の定義を示しておく。
マスターデバイス16とゲストデバイス18は、各々のパーソナルネットワーク15の一部であってもよい。パーソナルネットワーク15は、単一ユーザの制御下にある2つ以上のデバイスからなるネットワークである。デバイスは、ユーザには連続的なセキュア接続が認識されるように管理される。パーソナルネットワークは15、ユーザが自身のパーソナルネットワーク15を制御する目的に使用するマスターデバイスを備えていることができる。また、パーソナルネットワーク15は、マスターデバイスの制御下にあるネイティブデバイスおよびゲストデバイス18を備えていることもでき、この場合、ネイティブデバイスはホーム通信事業者20に加入しており、ゲストデバイス18は外部通信事業者に加入している。
ホストは、パーソナルネットワークを所有し、それを制御するユーザである。
クライアントは、ホストのパーソナルネットワーク15へのアクセスを望んでいるユーザである。ホストとクライアントが同一ユーザである可能性もある。
ホストの通信事業者を以下ではホーム通信事業者と称し、ホーム通信事業者20は、ホストのパーソナルネットワーク15を管理する。
クライアントは、外部通信事業者21に加入している。外部通信事業者21が、クライアントにPNサービスを提供してもよい。
通信事業者は、加入者にサービスを提供するネットワーク通信事業者またはサービスプロバイダである。
以下の説明においては、本発明を完全に理解することができるように、説明を目的として、特定の数、回数、構造、プロトコル名、その他のパラメータを記載してある。しかしながら、当業者には、本発明はこれらの特定の詳細には従わずに実施できることが明らかであろう。なお、本発明が不必要にあいまいになることを避けるため、周知の構成要素およびモジュールはブロック図として示してある。
以下の説明から明らかになるように、本明細書に記載されている本出願の実施形態は、幅広い用途に適用することができ、本明細書に提示したパーソナルネットワーク15のシナリオに必ずしも限定されない。
ユーザが、別の通信事業者に加入しているデバイスを追加する必要があるときには、別の通信事業者に加入しているデバイスをユーザが追加するプロセスが、別のユーザによって行われないようにする必要がある。
言い換えれば、パーソナルネットワーク15に登録されているユーザ以外の人からのアクセスを制限することによって、ホストのパーソナルネットワーク15を保護することが重要である。
用語「通信事業者」は、包括的な用語であり、モバイルネットワーク、WLANシステム、無線パーソナルエリアネットワーク(ただしこれらに限定されない)を意味するものとする。
本発明では、ユーザは、外部ネットワークに加入しているデバイスを追加することができ、従って、ユーザには、自身が望む任意のデバイスをパーソナルネットワーク15に追加する自由が与えられる。外部ネットワークに加入しているデバイスは、ユーザ自身のデバイスであるか、または、ユーザと信頼関係にある別のユーザ(例:家族、友人)が所有しているデバイスとすることができる。
一般的に、パーソナルネットワーク15は、パーソナルネットワーク15のユーザ手順(例:別のデバイスをパーソナルネットワーク15に登録、登録解除する)を可能にする1つ以上のマスターデバイス16を備えていることができる。ゲストデバイス18と対話するデバイスはマスターデバイス16について提案しているが、別のデバイスがゲストデバイス18と対話する代替実施形態も可能である。これらの方策によって、ユーザは、自身のパーソナルネットワーク15を中央のデバイスによって制御することができ、意思決定能力を備えた複数のデバイスが存在するために同期処理が複雑になることが回避される。
図1Bは、本発明の好ましいシステムを示している。このシステムは、ホーム通信事業者20におけるエンティティPNM11と、ホストのパーソナルネットワーク15のマスターデバイス16であって、ホーム通信事業者20に加入している、マスターデバイス16と、外部通信事業者21におけるプロキシ12であって、必要な場合にデバイス認証を実行することと、PNM11と協働する、プロキシ12と、外部通信事業者21に加入していて、ホーム通信事業者20のPNMによって管理される特定のPNにゲストデバイスとして登録されたデバイスの詳細を保存するプロキシデータ123によって可能とされる、ホーム通信事業者20のPNM11へのアクセスを要求するデバイスへのルーティング機能を提供することによって外部通信事業者21に加入しているゲストデバイス18であって、特定のパーソナルネットワーク15へのアクセスを要求する、ゲストデバイス18と、を備えている。リンク13(セキュアリンク)は、SS7、IP、またはATMシングナリングを使用することができ、ただしこれらに限定されない。リンク14(セキュアリンク)は、セルラーアクセス、無線LAN、IP、または固定バンドアクセスとすることができ、ただしこれらに限定されない。リンク19(セキュアリンク)は、Bluetoothアクセス、IP、セルラー、ATM、無線LAN、あるいはスマートカードなどの携帯記憶装置を使用しての物理的な接触とすることができ、ただしこれらに限定されない。マスターデバイス16は、パーソナルネットワーク15の1つの要素であり、アクセス制御機能を備えており、ただしこれに限定されない。マスターデバイス16は、どのデバイスにパーソナルネットワーク15へのアクセスを許可するかを制御することができる。本発明の観点においては、ゲストデバイス18は、ホーム通信事業者20とは異なる通信事業者に加入しており、パーソナルネットワーク15へのアクセスを要求するデバイスである。プロキシ12は、外部通信事業者21に属するデバイスによるPNM11のアクセス数を制限するためのフィルタリングシステムとして使用され、これによりすべての要求を各PNMへ安全にルーティングし、その結果、2つの通信事業者/ネットワーク間のトラフィックを制限し、確実にする。プロキシは、PN事前登録の制限的/静的または半静的なデータベースとして実現することができるプロキシデータ123を有する。PNM11にあるデータベース、すなわちパーソナルネットワーク情報113は動的であり、リアルタイムまたはリアルタイムに近いデータを保持することができる。PNM11は、その結果、最終認証エンティティとして機能することができ、暗号化キー、またはパスワード、またはピンID―これらに限定されないが―の形をとることができる、そこに保持されたサービスキーの知識を用いてゲストデバイス18を確認する。これにより、外部通信事業者21はプロキシデータ123を使用して事前登録を確認する前にゲストデバイスの加入を暗黙に確認することになるので、ホーム通信事業者20は、ゲストデバイス18を確認するための外部通信事業者21への依存を制限することができる。
本発明の別の実施形態においては、プロキシ12をホーム通信事業者20自身に存在させることができる。その場合のシステムでは、ユーザは、同じ通信事業者に加入している別のデバイスを追加することができる。この実施形態においては、ゲストデバイスは、マスターデバイスと同じ通信事業者に加入している。この場合、プロキシ12の機能は、PNMの機能に統合可能である。すなわち、デバイス認証とサービス認証の両方がPNM自身によって行われる。
図2は、PNM11の好ましい構成要素を示している。PNMは、ユーザのパーソナルネットワーク15を管理する役割を果たし、ユーザが自身の位置あるいはデバイスの位置には関係なく自身のパーソナルネットワーク15にアクセスできるようにする。本発明では、エンティティPNM11によって、パーソナルネットワーク15の所有者は、ゲストデバイスが加入しているネットワーク/オペレータ/認証ドメインに関係なくデバイスを追加できる。
PNM11は、(PNM内)マスターデバイスインタフェース112と、(PNM内)プロキシインタフェース110と、サービス認証モジュール111とを備えている。(PNM内)マスターデバイスインタフェース112は、通信デバイス(通常はパーソナルネットワーク15のマスターデバイス16)と対話する。(PNM内)マスターデバイスインタフェース112におけるアクセスネットワークは、通常は、WCDMA、CDMA2000、GSM、WLANなどの無線アクセスであり、ただしこれらに限定されない。(PNM内)マスターデバイスインタフェース112は、ゲストのサービスキー406を受信し、ゲストデバイスの設定を確認する。(PNM内)プロキシインタフェース110は、外部通信事業者21のネットワークに存在しているプロキシと対話する。(PNM内)プロキシインタフェース110におけるプロトコルは、通常は、SS7、IP、またはSIPであり、ただしこれらに限定されない。(PNM内)プロキシインタフェース110は、ゲストデバイス18用のルートを、ゲストデバイス18がアクセスを要求しているPNM11に関連付ける。
サービス認証モジュール111は、サービスキー406を管理することによって、ゲストデバイス18の認証を可能にする。この場合、サービスキーは、パスワード、ピン、または独自に生成された暗号化キーの形式とすることができる。サービス認証は、パーソナルネットワーク15へのアクセスをその所有者が制御できるようにする目的で使用される。例えば、パーソナルネットワーク15の所有者は、ゲストデバイス18からのアクセスを停止させる必要がある場合、ゲストデバイスによるアクセスを簡単に取り消すことができる。これについての別の利点は、パーソナルネットワーク情報113は動的性を保たれ、ユーザの選択に応じて最新にできる一方、プロキシデータ123は比較的静的に保たれるので、ユーザが自分のプリファレンス(好みの設定)を変更する際に必要とされるシグナリングを最小にできる。PNMは、ゲストデバイスリスト中の変更の集約リストをプロキシに定期的に送信することもできる。マスターデバイス16は、サービスキー406を変更することもできる。これは、PNMにおいて別のサービスキーを設定することによって行われる。ゲストデバイスの代替のサービスキー406が更新されると、ゲストデバイスによるアクセスがサービス認証モジュール111において許可されず、なぜなら、ゲストデバイスが提示するサービスキー406と、更新されたサービスキー406とが合致しないためである。従って、たとえゲストデバイス18がプロキシ12においてデバイス認証されても、PNM11においては認証されず、従って、ユーザは、自身のパーソナルネットワーク15へのアクセスを完全に制御することができる。
図3は、パーソナルネットワーク情報113の構成要素を示している。前述したように、パーソナルネットワーク情報113は、パーソナルネットワーク15のすべての詳細を含むことができ、ユーザのプリファレンス(設定)に対して動的であるので、ユーザのアクセス制御プリファレンス(設定)を即時に反映することができる。パーソナルネットワーク情報113は、パーソナルネットワークの中のデバイスのリスト401を含んでいる。このリストは、デバイスのそれぞれのデバイスID403を含んでいる。また、パーソナルネットワーク情報113は、ルートリスト400を含んでおり、このリストは、デバイスのそれぞれを相互接続させる目的で維持されているローカルルーティングテーブルである。さらに、パーソナルネットワーク情報113は、デバイスごとに、そのデバイスのアクセス特権に基づく個別のルーティングリスト400も含んでいることができる。
各デバイスは、デバイスID403、デバイスタイプ404、アクセスリスト405、およびサービスキー406の各情報が含まれているデバイス属性を持つことができる。このうちデバイスタイプは、デバイスがマスターデバイス16であるか、ネイティブデバイスであるか、またはゲストデバイス14であるかを示す。アクセスリスト405には、マスターデバイス16によって設定される各デバイスのアクセス特権が含まれている。サービスキー406は、PNM11における認証を得る目的でゲストデバイスが保持しているキーである。
図4は、プロキシ12の好ましい構成要素を示している。プロキシは、2つのインタフェース、すなわちPNMインタフェースとゲストデバイスインタフェースとを備えている。また、プロキシは、デバイス認証モジュール121とプロキシデータ123とを備えている。プロキシ12は、外部通信事業者21のネットワークにおける、PNM11に対応するエンティティである。ここでのプロキシ12は、ホーム通信事業者20のPNM11エンティティと協調する外部通信事業者21のPNM11エンティティであることは大いにあり得ることだと理解される。プロキシ12の主要機能は、PNアクセスを要求しているゲストデバイス18の加入を認証し、プロキシデータ123のデータベースを使用してその事前登録ステータスを確認し、ゲストデバイス18を所望の通信事業者のPNM11に向けてルーティングすることである。プロキシの設定および使用の料金は、ゲストデバイス18に課すことができる。プロキシ12は、PNM11へのセキュアかつ直接的なアクセスを提供する必要がある。プロキシ12は、デバイス認証を実行して、特定のPNM11へのアクセス要求を認証することができる。この方法では、パーソナルネットワーク15へのアクセスを要求しているデバイスは、PNM11においては有効なゲストデバイス18としてすでに認証されている。さらに、ゲストデバイスがプロキシ12を使用してPNM11にアクセスする方式では、ゲストデバイス18に加入契約確認モジュール160が存在することによる暗黙的なセキュリティも存在する。加入契約確認モジュールは、SIMまたはUSIM、あるいは代替のセキュアアクセス方法とすることができ、これにより、プロキシ12へのアクセスが、有効な加入契約を持つエンティティに限定される。
プロキシ12は、2つのインタフェース、すなわち(プロキシ内)PNMインタフェース120と(プロキシ内)ゲストデバイスインタフェース122とを備えていることができる。(プロキシ内)PNMインタフェース120は、PNM11とのすべての通信、例えば、ルートを関連付ける、ゲストデバイス18のデバイスID403をPNMから取得する、あるいはゲストデバイス18からのパスまたはルーティングデータをPNM11に提供する役割を果たすことができる。PNMインタフェース(プロキシ側の)120でのプロトコルは、通常、IPまたはSIPまたはSS7−これらに限定されないが―である。ルートの関連付けとは、ゲストデバイスからの特定のパーソナルネットワークへの接続要求を、そのパーソナルネットワークを管理している特定のPNMに関連付けて、これによって、そのパーソナルネットワークまたはPNMに関連するすべての情報をPNMにルーティングすることである。(プロキシ内)ゲストデバイスインタフェース122は、ゲストデバイス18とのすべての通信を行うことができ、ゲストデバイスのデバイスIDを取得する。(プロキシ内)ゲストデバイスインタフェース122は、PNM11を宛先とするすべてのデータを認識し、それらのデータがPNM11にルーティングされるように、それらのデータを(プロキシ内)PNMインタフェース120に渡す。(プロキシ内)ゲストデバイスインタフェース122におけるアクセスネットワークは、通常、WLAN、WCDMA、またはCDMA2000であり、ただしこれらに限定されない。
デバイス認証モジュール121は、最初に、ゲストデバイス18が正当な装置であるか否かを確認することができる。次に、同モジュールは、PNM11へのアクセスを要求しているゲストデバイス18が特定のPNM11によって事前に登録されたか否かを確認することによって事前登録チェックを行う。ゲストデバイス18が事前に登録されていた場合、ゲストデバイス18はPNMと通信することを許可される。
図5は、プロキシデータ123の構成要素を示している。プロキシデータ123は、マスターデバイスID125に対応するパーソナルネットワーク15に関連するデータを意味する。マスターデバイスID125の各エントリは、ゲストデバイスID126のリストを有する。さらに、通信事業者ID128(マスターデバイスが加入しているホーム通信事業者)のエントリも含めることができる。たいていの場合、通信事業者IDは、マスターデバイスID自体から引き出すことができる。
図6は、マスターデバイス16の構成要素のうち、本発明に関連するモジュールを示している。マスターデバイス16は、通信デバイスであり、PNM11と通信することのできる(マスターデバイス内)PNMインタフェースモジュール164を備えている。(マスターデバイス内)PNMインタフェースモジュール164は、PNM11にキーを預け、ゲストアクセスの要求を送信し、ゲストデバイス18がアクセスするための設定が完了したときにPNM11からの確認応答を受信する役割を果たす。(マスターデバイス内)PNMインタフェースモジュール164におけるアクセスネットワークは、通常は、WCDMA、CDMA2000、WLANなどの無線アクセス方法であり、ただしこれらに限定されない。
加入契約確認モジュール160は、加入契約情報と認証キーとを含んでおり、通信ネットワークにおける有効な加入契約を持つものとしてデバイスを認証する役割を果たす。
アクセスリスト生成モジュール161は、アプリケーション層モジュールとすることができ、ユーザは、このモジュールを使用することで、パーソナルネットワーク内のデバイスのアクセス特権を設定するアクセスリスト405を生成する。アクセスリスト生成モジュール161は、ゲストデバイス16からパーソナルネットワーク内のデバイスへのアクセスを許可・拒否する手順を提供する単純なユーザインタフェースを提供する。
キー生成モジュール162は、特定のゲストデバイス18のサービスキー406を生成する。サービスキー406は、ランダムキー生成関数、RSA(Rivest Shamir Adleman)、DES(Data Encryption Standard)、またはその他のキー生成関数によって生成することができ、ただしこれらに限定されない。サービスキー406は、PNM11とゲストデバイス18の両方に預けられ、PNM11とゲストデバイス18によって共有される秘密鍵である。これに代えて、サービスキー406をPNM自身において生成し、それをマスターデバイス16に送信し、さらにゲストデバイス18に転送することもできる。
(マスターデバイス内)ゲストデバイスインタフェースモジュール184は、ゲストデバイス18にキーをセキュアに送信する役割を果たす。(マスターデバイス内)ゲストデバイスインタフェースモジュール184におけるアクセスネットワークは、通常は、直接的な接触(セキュアメモリモジュール)、またはBluetoothあるいはWLANであり、ただしこれらに限定されない。サービスキー406は、セキュアメモリモジュールまたは代替のセキュア方式を使用して送信することができる。
図7は、ゲストデバイス18の構成要素のうち、本発明に関連するモジュールを示している。ゲストデバイス18は、通信デバイスであり、(ゲストデバイス内)プロキシインタフェースモジュール180を備えていることができ、このモジュール180は、プロキシ12へのアクセスの要求など、プロキシ12との通信のすべてを行う。(ゲストデバイス内)プロキシインタフェースモジュール180におけるアクセスネットワークは、通常、WCDMA、CDMA2000、GSM、WLANなどの無線アクセスであり、ただしこれらに限定されない。(ゲストデバイス内)プロキシインタフェースモジュール180は、デバイスID403の認証情報を提供する。認証は、ゲストデバイス18がマスターデバイス16のデバイスID403を提示したときに行われ、プロキシ12は、そのマスターデバイス16に対応するゲストデバイス18のリストを調べる。要求中のデバイスのIDと、事前登録されているゲストデバイス18のIDとが合致する場合、デバイス認証が達成される。
ゲストデバイス18は、(ゲストデバイス内)PNMインタフェースモジュール183を備えており、このモジュール183は、PNM11との通信を行い、例えば、パーソナルネットワーク15へのアクセスの要求時に認証情報としてサービスキー406を提供する。PNMインタフェースモジュールは、プロキシインタフェースモジュールと同じアクセスネットワーク(無線またはIP)を使用するが、PNMと通信する目的でプロキシ(ルーターとして機能する)を経由するシグナリングをさらに使用する。PNM11は、以前に預かったサービスキー406を使用してサービスキー406をチェックし、キーが合致する場合、サービス認証が達成される。
ゲストデバイス18は、(ゲストデバイス内)マスターデバイスインタフェース184も備えており、このインタフェース184は、マスターデバイス16からゲストデバイス18にサービスキー406をセキュアに送信できるようにする。(ゲストデバイス内)マスターデバイスインタフェース184におけるアクセスネットワークは、直接的な接触(セキュアメモリモジュール)、あるいは、Bluetooth、WLAN、またはIPとすることができ、ただしこれらに限定されない。(ゲストデバイス内)マスターデバイスインタフェース184は、パーソナルネットワークへのアクセスの最初の要求を実行することもできる。
ゲストデバイス18は、セキュアキーストレージモジュール181を備えており、このモジュール181は、ゲストデバイス18が設定された直後のみならず以降の任意の時点においてゲストデバイス18がパーソナルネットワーク15にアクセスできるようにする。セキュアキーストレージモジュール181は、セキュアメモリまたはその他のセキュアストレージモジュールとすることができる。ゲストデバイス18は、PNM11におけるサービスキー406が変更されないかぎりは、パーソナルネットワーク15にアクセスすることができる。マスターデバイス16がPNM11におけるサービスキー406を変更すると、ゲストデバイス18のサービス認証は達成されない。マスターデバイス16とPNM11は、ゲストデバイス18ごとに異なるサービスキー406を維持することができる。
図8は、ゲストデバイス18をパーソナルネットワーク15に事前登録しておき、サービス認証、デバイス認証、およびアクセスリストの適用を可能にする好ましい方法について説明したシーケンス図である。この好ましい実施形態においては、ホストは、外部ネットワークに加入しているゲストデバイス18を追加することを望むとき、そのゲストデバイス18のデバイスID403を取得する。デバイスID403は、MSISDN、IPアドレス、またはURLの形式とすることができ、ただしこれらに限定されない。このデバイスID403は、ゲストデバイス18による要求20を通じて取得することができ、または、パブリックID(MSISDN、IPアドレス、またはURL)とすることもでき、その場合には既知である。
このIDは、後の時点で、ゲストデバイス18がパーソナルネットワーク15へのアクセスの取得をプロキシ12を通じて望むときに、ゲストデバイスを識別する目的に使用することができる。これによって、PNM11は、プロキシ12におけるデバイス認証によって有効であることが確認されたデバイスのみと通信する。このことは、関連する方法を説明した後に明らかになるであろう。
好ましい実施形態においては、サービスキー406は、マスターデバイス16において、キー生成モジュール162によって生成される。これに代えて、キーをPNM自体で生成し、マスターデバイスに送信することができる。マスターデバイス16がゲストデバイスIDを取得した後、キー生成モジュール162は、ゲストデバイス18のサービスレベルの認証を提供する目的で使用されるキーを生成することができる。
次いで、アクセスリスト生成モジュール161は、ゲストデバイス18のアクセス制御に関する所有者のプリファレンスに基づいて、アクセスリスト405を生成する。この場合、パーソナルネットワークにおける特定のデバイスへのアクセスを許可および拒否するための単純な手順を、ユーザインタフェースとして実施することができる。アクセスリスト405の使用例として、ユーザが自身のパーソナルネットワーク15の中に5つのデバイスを持っており、そのうちの3つのみを共有するように望む場合、アクセスリスト405は、それら特定の3つのデバイスに対してのみゲストデバイス18からのアクセスが許可され、それ以外のデバイスに対してはアクセスが許可されないことを、PNM11に伝える。
アクセスリスト405は、エンティティPNM11が使用するアクセス制御情報を提供する。エンティティPNM11は、このルート情報を使用して、デバイスへのアクセスをゲストデバイス18に許可するか否かの決定を行うことができる。
キーとアクセスリスト405とが生成されると、マスターデバイス16は、アクセスリスト405と、サービスキー406と、ゲストデバイス18のIDとを含んでいるルート情報23を、(マスターデバイス内)PNMインタフェースモジュール164を通じてPNM11に提供する。PNM11は、アクセスリスト405と、サービスキー406と、外部デバイスのIDとを、パーソナルネットワーク情報113の中に格納する(24)。次いで、PNM11は、アクセスリスト405を使用して、ゲストデバイス18が含まれている下位レベルのルートリストを生成する(25)。このようにして、PNM11は、パーソナルネットワーク15の要素とゲストデバイス18との間で情報をルーティングすることができ、これによりゲストデバイス18がネットワークに登録される。
ユーザは、特定のデバイスのユーザ自身のルートリストを提供することもできる。例えば、ユーザのマスターデバイスにゲストデバイスによってアクセスされるとき、使用される通常のルートが、ユーザのホームネットワークまでの第1のホップと、ユーザのデバイスまでの第2のホップであるとする。場合によっては、ホストが、ゲストデバイスがホームネットワークを経由しないことを望むことがある。そのような場合、特定のデバイスへの特定のルートを決定する手順をユーザに提供することができる。
次いで、エンティティPNM11は、ゲストデバイス18の通信事業者またはHLR番号を、ゲストデバイス18のIDから導く(26)。外部デバイスの通信事業者が導かれると、(PNM内)プロキシインタフェース110は、外部通信事業者21におけるプロキシ12にルート27を要求し、ゲストデバイス18のIDを提供する。このルートは、ゲストデバイス18がパーソナルネットワーク15へのアクセスを取得した後に、ゲストデバイス18とパーソナルネットワーク15との間のトラフィックすべてをルーティングする目的に使用することができる。このルートは、通信事業者間の専用経路とするか、または(IPSECまたは代替のセキュリティプロトコルを用いて)IPを使用する、またはSS7を使用することができ、ただしこれらに限定されない。前提条件は、ルートがセキュアであることである。
プロキシ12は、特定の外部通信事業者21に加入しているゲストデバイス18のIDとマスターデバイスのIDとに、このルートを関連付ける(28)。この関連付けは、プロキシデータ123に格納される。関連付けが格納されると、(プロキシ内)PNMインタフェース120は、プロキシ12がゲストデバイス18のルーティングとデバイス認証とを実行する準備ができたことの確認応答を、エンティティPNM11に送信する(29)。
PNM11は、この確認応答を受信すると、ゲストデバイス18からパーソナルネットワーク15へのアクセスを許可する準備がエンティティPNM11において完了したことを伝える確認応答を、マスターデバイス16に転送する(210)。
マスターデバイス16は、この確認応答を受信すると、以前に生成されたサービスキー406を(マスターデバイス内)ゲストインタフェースモジュール184を通じてゲストデバイスに提供することによって、ゲストデバイス18によるアクセスの要求に応答する(211)。このキーは、セキュアメモリモジュール(直接的な接触)またはその他のセキュアアクセス方式を使用して送信することができる。
ゲストデバイス18は、パーソナルネットワーク15へのアクセスをPNM11に要求するときに、このサービスキー406を使用することができる。さらに、セキュアキーストレージモジュール181は、後の時点で使用する目的でサービスキー406を格納しておくことができる。
この時点で、ゲストデバイス18は、必要なときにPNM11へのアクセスを取得できるように事前登録され、なぜなら、PNM11とプロキシ12の両方がゲストデバイス18を認証してパーソナルネットワーク15へのアクセスを許可できる状態にあるためである。
別の実施形態においては、図9は、サービス認証のみが実施される方法を示している。この方法では、プロキシにおける複雑さを軽減することができ、なぜなら、プロキシは、単純にPNM11への転送デバイスとして機能するためである。従って、通信事業者間での最小限の相互合意が必要である。この実施形態は、プロキシ12を最小の要件で機能させるときに好ましい。プロキシ12は、PNM11へのアクセス要求すべてを対応するPNM11に単に転送する。この結果、サービスキー406を保持するゲストデバイス18は、パーソナルネットワーク15へのアクセスを取得することができる。
サービスキー406を保持するゲストデバイス18は、自身のパーソナルネットワーク15にアクセスすることができる。このシステムでは、PNM11における単一レベルの認証を使用し、外部通信事業者21におけるデバイスレベルの認証は行われない。これにより、プロキシ12が単純化され、なぜなら、プロキシ12はゲストデバイス18からの情報をPNM11に単に転送するためである。なお、この場合、ゲストデバイス18がプロキシと通信するための認証は公開鍵基盤(PKI)によってすでに行われ、PKIは、SIMカードの形式とすることができ、ただしこれに限定されない。残りのステップは、好ましい実施形態と同様である。
図10は、システムがデバイス認証の実現のみを可能にする場合の、パーソナルネットワーク15にゲストデバイス18を事前登録するための別の実施形態を示す。このシステムの利点は、ゲストデバイス18のためのサービスキー406を管理する必要がないことである。ただし、プロキシ18における追加の事前登録が必要となる。従って、ゲストデバイス18によって要求が行われると(20)、マスターデバイス16は、ステップ120において、アクセスリスト405を生成し(22)、デバイスID403とアクセスリスト405とを含んでいるルート情報をPNM11に送信する。次いで、PNM11は、プロキシ12においてゲストデバイス18を事前登録する(20)。残りのステップ25,26,27,28,29,210は好ましい実施形態と同様である。本実施形態ではサービスキー406は生成されないので、ステップ121に示すとおり、確認応答メッセージには、マスターデバイス16とゲストデバイス18間でのサービスキー406の転送は発生しない。
別の実施形態においては、システムにおいてアクセスリスト405を使用しないことができる。ゲストデバイスは、パーソナルネットワーク内のすべてのデバイスにアクセスすることができる。この場合、システムは、サービス認証とデバイス認証の両方、サービス認証のみ、またはデバイス認証のみ、を使用することができる。
この方法は、2つのステップ、すなわち、PNMにアクセスするステップと、そのアクセスが許可される場合、パーソナルネットワーク15にアクセスするステップ、を含んでいる。ゲストデバイス18は、パーソナルネットワーク15へのアクセス要求に対する確認応答を受信するときに、自身がアクセスを望んでいるパーソナルネットワーク15のマスターデバイス16からサービスキー406を受信する。この時点で、ゲストデバイス18は、パーソナルネットワーク15にアクセスするための証明書を持ち、この場合の証明書は、暗黙的なデバイス認証を提供するデバイスID403と、明示的なサービス認証を提供するサービスキー406である。デバイス認証が暗黙的であるというのは、ゲストデバイス18が同一ドメインに属する限り、プロキシ12はデバイスID403自体を確認する能力を持ち得るからである。
図11は、ゲストデバイスがパーソナルネットワークにアクセスする好ましい方法を示している。ゲストデバイス18は、PNM11にアクセスすることを望むとき、最初に、プロキシへのアクセスをプロキシ12に要求し(ステップ30)、自身のIDと、自身がアクセスを望んでいるパーソナルネットワーク15のマスターデバイス16のIDとを提供する。ステップ32aに示すとおり、プロキシは、ゲストデバイスがPLMNに登録された正当なデバイスであることを確認する。また、マスターデバイス16のデバイスID403から、ゲストデバイス18を登録したマスターデバイスのリストを含み得るプロキシデータ123をプロキシは確認できる。プロキシ12は、そこに保持されたマスターデバイスのリストに特定のマスターデバイス16が存在するか否かを確認できる。存在する場合には、プロキシ12は次に、ステップ32bに示すように、アクセスを要求しているゲストデバイス18がマスターデバイス16によって事前に登録されたか否かを確認できる。このようにして、デバイス認証が可能となる。存在しなければ、要求はプロキシ自体によって拒否される。したがって、このフィルタリング処理は、プロキシがPNに登録されていないデバイスをすぐに拒否できるようにし、認証をPNMにまで引き延ばした後に否定応答を受信し、その結果、不必要な冗長なシグナリングを行うことになるのを避ける。プロキシ12は、マスターデバイス16が属している通信事業者のIDを導く(31)。
次いで、プロキシは、ゲストデバイス18からのすべてのデータを、対応するPNM11に関連付ける、すなわち、ゲストデバイス18のIDにルートを関連付ける(33)。この時点で、PNM11に必要とされるゲストデバイス18のデータすべてを、プロキシ12によってPNM11に直接的にルーティングすることができる。プロキシは次に、ステップ34に示すように、ゲストデバイス18によって送信されたアクセス要求メッセージを後続の処理のためにPNMへ転送する。PNM11は、アクセス要求を受信すると、そこに保持されたサービスキーの知識を検証することによってゲストデバイス18の真偽を調べる。ゲストデバイス18がサービスキーを使用して自身を認証できる場合、ステップ35に示すとおり、セキュリティアソシエーションすなわちSAがPNM11とゲストデバイス18の間に確立される。この認証は、httpまたはその他の一般的な認証方法に基づくことができる。
次のステップ37において、PNMは特定のゲストデバイス18用のルートリストをイネーブルできる。
次いで、PNM11は、パーソナルネットワーク15の一部となる要求が許可されたことの確認応答をゲストデバイス18に送信する(38)。
この時点で、ゲストデバイス18は、パーソナルネットワーク15の一部であり、パーソナルネットワークにアクセスする(39)。
図12は、ゲストデバイスのパーソナルネットワークへのアクセスにおいてサービス認証のみを実現可能とする場合の、ゲストデバイスがパーソナルネットワークへアクセスする別の実施形態を示す。この実施形態においては、プロキシ12が単純に転送デバイスとして機能することによって、プロキシ12における複雑さが回避されている。
ゲストデバイス18のデバイスID403は、マスターデバイスによって事前に登録されているものとして確認されなくてよい。有効な加入契約を有するゲストデバイス18による、プロキシ12へのアクセスの要求は、すべて許可される。従って、プロキシ12は、ルーティングデバイスとしてのみ機能し、ゲストデバイス18の要求すべてをPNM11に直接的にルーティングする。この実施形態における他のステップは、図11と同様である。
図13は、ゲストデバイスのパーソナルネットワークへのアクセスにおいてデバイス認証のみを実現可能とする場合の、ゲストデバイスがパーソナルネットワークへアクセスする別の実施形態を示す。この実施形態においては、PNMにおいてサービスキーを管理する必要がない。ここで、サービス認証ステージであり、必要ではないステップ35を除き、すべてのステップ30、31、32a、32b、33、34、37、38および39は、上記の好ましい実施形態と同様である。この実施形態では、ゲストデバイスにおける半永久的な信用を想定しており、従って、サービスキーを生成する必要がない。
別の実施形態においては、システムは、アクセスリスト405を備えていない。さらには、この実施形態は、前の実施形態において説明したように、サービス認証とデバイス認証の両方、サービス認証のみ、またはデバイス認証のみを実施するように選択することができる。
図14は、ゲストデバイスの追加を可能にするためにマスターデバイス16が提供できるユーザインタフェースを示す。ステップ140に示すように、ユーザには、デバイスの登録、自分のPNの確認、その他のPNへのアクセスの選択肢が提示される。ユーザは、ステップ141に示すように、ネイティブデバイスまたはゲストデバイスを追加することが可能とされる。代替の実施では、この詳細をユーザから隠し、ユーザが追加したいデバイスのIDをユーザがただ入力すればよいようにする。PNMがデバイスの加入先を発見する機能を持つようにすればよい。次のステップ142では、ゲストデバイスIDがユーザによって指定される。この特定のIDに対応する通信事業者がサポートされている場合、ステップ143において、ユーザはこの特定のゲストデバイス用のアクセスリストを発行するか否かを問われる。通信事業者がサポートされていない場合、特定の通信事業者はサポートされていないというメッセージがユーザに提示されてもよい。ステップ142aに示すように、ユーザはゲストデバイスのパスワードを入力するようにさらに求められることもある。ステップ145で、ユーザは、各デバイスに対するアクセス優先度のリストを指定することができる。例えば、この例では、ユーザはID1に完全なアクセスを与え、ID3の存在を隠すことを望んでいる。
図15は、PNヘアクセスするためのゲストデバイス用のユーザインタフェースを示す。ステップ150は、基本的なPNインタフェースを提示する。ステップ151に示すように、その他のPNへのアクセスをユーザが選択時にはユーザはマスターデバイスIDを指定することができる。パスワードに基づいた登録が済んでいる場合には、ステップ153へ進み、キーに基づいた登録がされていない場合には、ステップ152が提示される。デバイスがPNMによってサービス認証済みであれば、ユーザはPNへアクセスできる。
本出願は、2006年1月31日付け申請の国際特許出願No.PCT/JP06/301950および2006年4月18日付け申請の米国仮特許出願No.60/792,613を基にしており、これらのすべての内容は参照することにより本文書に明確に組み込まれる。