(57)【特許請求の範囲】
【請求項１】
第１のユーザを探索する要求であって第１のユーザの識別（ＩＤ）コードを含む要求を第１のサービスプロバイダーで受信する処理と、
前記第１のユーザが前記第１のサービスプロバイダーに登録されているかどうか決定するために登録データベースに問合せする処理と、
ユーザが前記第１のサービスプロバイダーに登録されていない場合には、異なるサービスプロバイダーに各々関連した複数のブルームフィルタに問合せする処理と、
各々のブルームフィルタから肯定又は否定応答を受信する処理であって、肯定応答は、前記第１のユーザが各ブルームフィルタに関連したサービスプロバイダーに登録されているかもしれないし又は登録されていないかもしれないことを指示し、そして否定応答は、前記第１のユーザが各ブルームフィルタに関連したサービスプロバイダーに登録されていないことを確実に指示する当該処理と、
肯定応答が受信されたサービスプロバイダーのみに前記第１のユーザを探索する要求を送信する処理と、
がコンピュータで実行される方法。
【請求項２】
前記肯定応答が受信されたサービスプロバイダーから戻される応答を受信する処理であって、その応答は、前記第１のユーザが各サービスプロバイダーに登録されているかどうか確実に指示する当該処理と、
前記第１のユーザとのピア・ツー・ピア（Ｐ２Ｐ）ネットワーク接続を確立するため、前記第１のユーザが登録されたサービスプロバイダーを識別するネットワーク接続データを第２のユーザに与える処理と、
が更に実行される請求項１に記載の方法。
【請求項３】
前記ＩＤコードは、アルファニューメリックストリングを含む、請求項１に記載の方法。
【請求項４】
前記ＩＤコードは、ｅ−メールアドレスを含む、請求項１に記載の方法。
【請求項５】
前記ＩＤコードは、電話番号を含む、請求項１に記載の方法。
【請求項６】
前記第１のユーザが前記第１のサービスプロバイダーに登録されている場合には、前記第１のユーザとのピア・ツー・ピア（Ｐ２Ｐ）ネットワーク接続を確立するために、前記第１のサービスプロバイダーにより管理されるネットワークアドレスを識別するネットワーク接続データを第２のユーザに与える処理を更に含む、請求項１に記載の方法。
【請求項７】
前記第１のユーザが前記第１のサービスプロバイダーに登録されていないが、ブルームフィルタにより識別された第２のサービスプロバイダーに登録されている場合には、前記第１のユーザから、前記第１のサービスプロバイダーに登録された第２のユーザへピア・ツー・ピア（Ｐ２Ｐ）接続を確立するのに必要なネットワーク化データを含む接続データを前記第１のユーザへ送信するために前記第２のサービスプロバイダーをプロキシーとして使用する処理を更に含む、請求項１に記載の方法。
【請求項８】
前記第２のユーザから前記第１のユーザへＰ２Ｐ接続を確立するのに必要な接続データを前記第１のユーザから前記第２のユーザに与えるために前記第１のサービスプロバイダーをプロキシーとして使用する処理を更に含む、請求項７に記載の方法。
【請求項９】
前記ネットワークアドレスは、ＴＣＰ／ＩＰアドレスを含む、請求項６に記載の方法。
【請求項１０】
ユーザ登録データベースへの複数の更新を受信する処理であって、その更新は、第１のサービスプロバイダーに登録された新たなユーザに関連した新たな識別（ＩＤ）コードを含む当該処理と、
前記新たなＩＤコードと、前記第１のサービスプロバイダーに既に登録された既存のユーザに関連した複数の既存のＩＤコードとを使用して、ブルームフィルタを発生する処理と、
新たなブルームフィルタを複数の他のサービスプロバイダーの各々へ送信する処理であって、そのブルームフィルタは、あるＩＤコードが第１のサービスプロバイダーに登録されたユーザを識別しないことを確実に決定するために前記複数の他のサービスプロバイダーにより使用可能なものである処理と、
がコンピュータで実行される方法。
【請求項１１】
前記他のサービスプロバイダーの各々によって発生されたブルームフィルタを受信する処理を更に含み、そのブルームフィルタは、所与のＩＤコードが各々のサービスプロバイダーに登録されたユーザを識別しないことを確実に決定するために前記第１のサービスプロバイダーにより使用可能である、請求項１０に記載の方法。
【請求項１２】
特定のサービスプロバイダーに関連した第１のブルームフィルタで問合せを受信する処理であって、その問合せは、ユーザに関連した識別（ＩＤ）コードを含み、前記ブルームフィルタは、それに応答して肯定又は否定応答を発生し、肯定応答は、第１のユーザがそのブルームフィルタに関連した特定のサービスプロバイダーに登録されているかもしれないし又は登録されていないかもしれないことを指示し、そして否定応答は、前記第１のユーザがそのブルームフィルタに関連した特定のサービスプロバイダーに登録されていないことを確実に指示する当該処理と、
肯定応答が受信された場合だけ特定のサービスプロバイダーに前記第１のユーザを探索する要求を送信する処理と、
を更に含む請求項１１に記載の方法。
【請求項１３】
１つ以上のマシンの実行により、
第１のユーザを探索する要求であって第１のユーザの識別（ＩＤ）コードを含む要求を第１のサービスプロバイダーで受信し、
前記第１のユーザが前記第１のサービスプロバイダーに登録されているかどうか決定するために登録データベースに問合せし、
ユーザが前記第１のサービスプロバイダーに登録されていない場合には、異なるサービスプロバイダーに各々関連した複数のブルームフィルタに問合せし、
各々のブルームフィルタから肯定又は否定応答を受信し、肯定応答は、前記第１のユーザが各ブルームフィルタに関連したサービスプロバイダーに登録されているかもしれないし又は登録されていないかもしれないことを指示し、そして否定応答は、前記第１のユーザが各ブルームフィルタに関連したサービスプロバイダーに登録されていないことを確実に指示するものであり、
肯定応答が受信されたサービスプロバイダーのみに前記第１のユーザを探索する要求を送信する、
という動作を遂行するようにさせるプログラムコードが記憶されたマシン読み取り可能な記録媒体。
【請求項１４】
前記肯定応答が受信されたサービスプロバイダーから戻される応答を受信し、その応答は、前記第１のユーザが各サービスプロバイダーに登録されているかどうか確実に指示するものであり、
前記第１のユーザとのピア・ツー・ピア（Ｐ２Ｐ）ネットワーク接続を確立するため、前記第１のユーザが登録されたサービスプロバイダーを識別するネットワーク接続データを第２のユーザに与える、
という付加的な動作を遂行するための付加的なプログラムコードを含む、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項１５】
前記ＩＤコードは、アルファニューメリックストリングを含む、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項１６】
前記ＩＤコードはｅ−メールアドレスを含む、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項１７】
前記ＩＤコードは電話番号を含む、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項１８】
前記第１のユーザが前記第１のサービスプロバイダーに登録されている場合には、前記第１のユーザとのピア・ツー・ピア（Ｐ２Ｐ）ネットワーク接続を確立するために、前記第１のサービスプロバイダーにより管理されるネットワークアドレスを識別するネットワーク接続データを第２のユーザに与える、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項１９】
前記第１のユーザが前記第１のサービスプロバイダーに登録されていないが、ブルームフィルタにより識別された第２のサービスプロバイダーに登録されている場合には、前記第１のユーザから、前記第１のサービスプロバイダーに登録された第２のユーザへピア・ツー・ピア（Ｐ２Ｐ）接続を確立するのに必要なネットワーク化データを含む接続データを前記第１のユーザへ送信するために前記第２のサービスプロバイダーをプロキシーとして使用する、請求項１３に記載のマシン読み取り可能な記録媒体。
【請求項２０】
前記第２のユーザから前記第１のユーザへＰ２Ｐ接続を確立するのに必要な接続データを前記第１のユーザから前記第２のユーザに与えるために前記第１のサービスプロバイダーをプロキシーとして使用する、請求項１９に記載のマシン読み取り可能な記録媒体。
【請求項２１】
前記ネットワークアドレスはＴＣＰ／ＩＰアドレスを含む、請求項１８に記載のマシン読み取り可能な記録媒体。
【請求項２２】
１つ以上のマシンの実行により、
ユーザ登録データベースへの複数の更新を受信し、その更新は、第１のサービスプロバイダーに登録された新たなユーザに関連した新たな識別（ＩＤ）コードを含み、
前記新たなＩＤコードと、前記第１のサービスプロバイダーに既に登録された既存のユーザに関連した複数の既存のＩＤコードとを使用して、ブルームフィルタを発生し、
新たなブルームフィルタを複数の他のサービスプロバイダーの各々へ送信し、そのブルームフィルタは、あるＩＤコードが第１のサービスプロバイダーに登録されたユーザを識別しないことを確実に決定するために前記複数の他のサービスプロバイダーにより使用可能である、
という動作を遂行するようにさせるプログラムコードが記憶されたマシン読み取り可能な記録媒体。
【請求項２３】
前記他のサービスプロバイダーの各々によって発生されたブルームフィルタを受信し、そのブルームフィルタは、所与のＩＤコードが各々のサービスプロバイダーに登録されたユーザを識別しないことを確実に決定するために前記第１のサービスプロバイダーにより使用可能である、請求項２２に記載のマシン読み取り可能な記録媒体。
【請求項２４】
特定のサービスプロバイダーに関連した第１のブルームフィルタで問合せを受信し、その問合せは、ユーザに関連した識別（ＩＤ）コードを含み、前記ブルームフィルタは、それに応答して肯定又は否定応答を発生し、肯定応答は、第１のユーザがそのブルームフィルタに関連した特定のサービスプロバイダーに登録されているかもしれないし又は登録されていないかもしれないことを指示し、そして否定応答は、前記第１のユーザがそのブルームフィルタに関連した特定のサービスプロバイダーに登録されていないことを確実に指示するものであり、更に、
肯定応答が受信された場合だけ特定のサービスプロバイダーに前記第１のユーザを探索する要求を送信する、
ことを更に含む請求項２３に記載のマシン読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には、コンピューティングネットワークの分野に関する。より特定すれば、本発明は、移動装置間のピア・ツー・ピア（Ｐ２Ｐ）接続を管理するための改良された装置及び方法に関する。
【０００２】
本出願は、２０１１年３月２１日に出願された“Apparatus and Method for Managing Peer-To-Peer Connections Between Different Service Providers”と題する米国仮特許出願第６１／４５４，９３０号の優先権を主張する。
【背景技術】
【０００３】
Ａ．ネットワークアドレス変換（ＮＡＴ）
インターネットのような大きなパブリックネットワークは、多くの場合、会社、インターネットサービスプロバイダー、又は個人の家庭で管理されるような小さなプライベートネットワークへの接続を有する。パブリックネットワークは、各々の性質により、ネットワークアドレス、即ちパブリックアドレスの共通に合意した割り当てを有していなければならない。種々の理由で、プライベートネットワークの保守者は、多くの場合に、共通に合意した割り当ての一部分ではないプライベートネットワークのプライベートネットワークアドレスを使用するように選択する。従って、プライベートネットワークからのネットワークトラフィックがパブリックネットワークを横断できるようにするために、ある形態のプライベート／パブリックネットワークアドレス変換（ＮＡＴ）が必要とされる。
【０００４】
ＮＡＴオペレーションを行う装置は、プライベートネットワークから送出されるデータパケットを、パブリックネットワークのアドレススキームに合致するように変更する。特に、ネットワークアドレス変換器は、発信するプライベートアドレス及びパケットのポート番号を、それ自身のパブリックアドレス及び指定のポート番号に置き換える。又、ネットワークアドレス変換器は、プライベートネットワークのコンピュータに対して受け取られるデータパケットを変更して、行先パブリックアドレス及びポート番号を、意図された受信者の正しいプライベートアドレス及びポート番号に置き換える。ここで使用する「アドレス」という語は、当業者に明らかなように、文脈上適当であれば、アドレス及びポート番号の両方を含むものと解釈しなければならない。
【０００５】
ＮＡＴは、近代的なネットワークコンピューティングにおいて益々一般的なものになりつつある。ＮＡＴの１つの効果は、パブリックネットワークのアドレススペースの減少を遅らせることである。例えば、インターネットに使用されるＴＣＰ／ＩＰアドレッシングは、各々３つのデジットの４つのストリングより成り、従って、限定アドレススペースを与える。更に、このアドレススペースのある部分は、特定の使用又はユーザのために予約され、利用できる実際のアドレス数を更に減少させる。しかしながら、ＮＡＴが使用される場合には、プライベートネットワーク又はサブネットが任意の数のアドレスを使用し、依然単一の標準的なパブリックアドレスを外界に提示する。これは、利用可能なアドレスの数を実際上無制限とする。というのは、各プライベートネットワークが、理論上、厳密に同じアドレスを使用できるからである。
【０００６】
ＮＡＴにより与えられる１つの効果は、パブリックネットワーク上にいる者がプライベートネットワーク上のコンピュータの実際の（即ち、プライベート）ネットワークアドレスを決定できないことから得られる高いセキュリティである。これは、ネットワークアドレス変換器によりパブリックネットワーク上にはパブリックアドレスしか与えられないためである。更に、このパブリックアドレスは、プライベートネットワーク上のいかなる数のコンピュータに対応してもよい。
【０００７】
異なるＮＡＴ形式は、異なるレベルのセキュリティを使用する。例えば、「完全コーン(full cone)ＮＡＴ」では、内部アドレス（ｉＡｄｄｒ：ｉＰｏｒｔ）が外部アドレス（ｅＡｄｄｒ：ｅＰｏｒｔ）へマップされると、外部ホストは、パケットをｅＡｄｄｒ：ｅＰｏｒｔへ送信することにより、パケットをｉＡｄｄｒ：ｉＰｏｒｔへ送信することができる。「制限コーン(restricted cone)ＮＡＴ」では、アドレスｈＡｄｄｒをもつ外部ホストは、ｉＡｄｄｒ：ｉＰｏｒｔがｈＡｄｄｒに既にパケットを送信している場合だけ、ｅＡｄｄｒ：ｅＰｏｒｔへパケットを送信することによりｉＡｄｄｒ：ｉＰｏｒｔへパケットを送信することができる。外部ホストのポートは、無関係である。「ポート制限コーン(Port Restricted Cone)ＮＡＴ」では、アドレス／ポートｈＡｄｄｒ：ｈＰｏｒｔを有する外部ホストは、ｉＡｄｄｒ：ｉＰｏｒｔがｈＡｄｄｒ：ｈＰｏｒｔに既にパケットを送信している場合だけ、ｅＡｄｄｒ：ｅＰｏｒｔへパケットを送信することによりｉＡｄｄｒ：ｉＰｏｒｔへパケットを送信することができる。最終的に、「対称的(Symmetric)ＮＡＴ」では、同じｉＡｄｄｒ：ｉＰｏｒｔから特定の行先ＩＰアドレス及びポートへの各要求が独特のｅＡｄｄｒ：ｅＰｏｒｔへマップされる。同じ内部ホストが異なる行先へパケットを送信する場合には、異なる外部アドレス及びポートマッピングが使用される。内部ホストからパケットを受け取る外部ホストだけがパケットを内部ホストに返送することができる。
【０００８】
Ｂ．ピア・ツー・ピアネットワークに伴うＮＡＴ問題
ピア・ツー・ピア（Ｐ２Ｐ）コンピューティングとは、リソースの一部分を他のネットワーク参加者に直接利用できるようにするコンピューティングノードより成る分散型ネットワークアーキテクチャーを指す。Ｐ２Ｐネットワークにおけるピアは、互いに直接的な通信チャンネルを確立し、そしてクライアント及びサーバーの両方として働き、これは、サーバーがリソースを供給しそしてクライアントがリソースを消費する慣習的なクライアント／サーバーモデルとは対照的である。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述したＮＡＴオペレーションは、Ｐ２Ｐ接続について多数の問題を引き起こす。例えば、上述した１つ以上のＮＡＴの後方にピアの一方又は両方が位置する場合には、２つのピア間に直接的接続を確立することが次第に困難になる。この問題は、Ａｐｐｌｅ  ｉＰａｄ  Ｔｏｕｃｈ（登録商標）、Ａｐｐｌｅ  ｉＰｈｏｎｅ（登録商標）、Ａｐｐｌｅ  ｉＰａｄ（登録商標）、及び種々の他の装置（例えば、ＲＩＭ  Ｂｌａｃｋｂｅｒｒｙ（登録商標）装置、Ｐａｌｍ  Ｐｒｅ（登録商標）装置、等）のような移動装置が、異なるＮＡＴ構成をもつネットワーク間で頻繁に移動されることにより悪化する。例えば、Ａｐｐｌｅ  ｉＰｈｏｎｅTMは、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ、ｇ、ｎネットワーク）、３Ｇネットワーク（例えば、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）ネットワーク、高速アップリンクパケットアクセス（ＨＳＵＰＡ）ネットワーク、等）及びＢｌｕｅｔｏｏｔｈネットワーク（パーソナルエリアネットワーク（ＰＡＮ）として知られている）を経て通信することができる。将来の移動装置は、幾つか挙げると、ＷｉＭＡＸ、インターナショナルモバイルテレコミュニケーション（ＩＭＴ）進歩型、及び長期進化（ＬＴＥ）進歩型、のような付加的な通信チャンネルを経て通信することができるであろう。
【課題を解決するための手段】
【００１０】
ブルームフィルタを使用してサービスプロバイダーを識別するシステム及び方法が提供される。本発明の１つの実施形態において、サービスプロバイダーは、登録されたユーザのユーザＩＤコードでブルームフィルタを生成し、そしてそのブルームフィルタを互いに交換する。第１のユーザを探索する要求に応答して、第１のサービスプロバイダーは、それ自身の登録データベースに質問し、第１のユーザが第１のサービスプロバイダーに登録されているかどうか決定する。第１のユーザが第１のサービスプロバイダーに登録されていない場合には、第１のサービスプロバイダーは、そのブルームフィルタに問合せして、第１のユーザが登録される他のサービスプロバイダーを識別する。ブルームフィルタからの肯定応答は、第１のユーザがそのブルームフィルタに関連したサービスプロバイダーに登録されていることもいないこともあることを指示し、そして否定応答は、第１のユーザがそのブルームフィルタに関連したサービスプロバイダーに登録されていないことを確実に指示する。第１のユーザを探索する要求は、肯定のブルームフィルタ応答が受け取られたサービスプロバイダーのみに送信される。
【００１１】
本発明は、添付図面を参照した以下の詳細な説明から良く理解されるであろう。
【図面の簡単な説明】
【００１２】
【図１】移動装置のグループ及びサービスがネットワークを経て通信するネットワークアーキテクチャーを示す。
【図２ａ】接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス、及び／又はインビテーションサービス間のトランザクションの一実施形態を示す。
【図２ｂ】接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス、及び／又はインビテーションサービス間のトランザクションの一実施形態を示す。
【図２ｃ】接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス、及び／又はインビテーションサービス間のトランザクションの一実施形態を示す。
【図３】チケットデータ構造体の一実施形態を示す。
【図４】ＣＤＸサービスにより実施される方法の一実施形態を示す。
【図５】移動装置により実施される方法の一実施形態を示す。
【図６】一次及び二次通信チャンネルを通して接続される移動装置のグループを示す。
【図７】一次及び二次通信チャンネル間で選択を行う移動装置の一実施形態を示す。
【図８ａ】一次及び二次通信チャンネルを通して接続される移動装置のグループ及びそれにより生じるネットワークトポロジーを示す。
【図８ｂ】一次及び二次通信チャンネルを通して接続される移動装置のグループ及びそれにより生じるネットワークトポロジーを示す。
【図９】一次及び二次通信チャンネル間を選択するコンピュータ実施方法の一実施形態を示す。
【図１０】移動装置のグループと、ディレクトリサービス及びプッシュ通知サービスを含むサービスとがネットワークを経て通信するネットワークアーキテクチャーを示す。
【図１１】インビテーションサービス、プッシュ通知サービス及び接続データ交換（ＣＤＸ）サービス間のトランザクションの一実施形態を示す。
【図１２】インビテーションサービス、プッシュ通知サービス及びリレーサービス間のトランザクションの一実施形態を示す。
【図１３】２つ以上の移動装置間のリレー接続を確立するためのリレーサービスの一実施形態を示す。
【図１４】ＮＡＴ適合性を決定するためのＮＡＴ適合性チャートの一実施形態を示す。
【図１５】オンラインアプリケーションについて移動装置を対戦させるマッチメーカーサービスの一実施形態を示す。
【図１６】ユーザ／装置を対戦させる方法の一実施形態を示す。
【図１７ａ】ユーザ／装置を対戦させるために行われる規範的な一連のテーブル更新を示す。
【図１７ｂ】ユーザ／装置を対戦させるために行われる規範的な一連のテーブル更新を示す。
【図１７ｃ】ユーザ／装置を対戦させるために行われる規範的な一連のテーブル更新を示す。
【図１７ｄ】ユーザ／装置を対戦させるために行われる規範的な一連のテーブル更新を示す。
【図１８】異なる対戦適合変数を使用してユーザ／装置を対戦させるための方法を示す。
【図１９】アプリケーションのためのアプリケーションプログラミングインターフェイス（ＡＰＩ）及び１組のサービスと通信するためのサービスＡＰＩを露出させるフレームワークを示す。
【図２０】アプリケーションのためのＡＰＩ、ゲームデーモン、及びサービスと通信するゲームサービスモジュールを伴うゲームフレームワークの一実施形態を示す。
【図２１】ＡＰＩ実施ソフトウェアコンポーネント及びＡＰＩコーリングソフトウェアコンポーネントの一実施形態を示す。
【図２２】オペレーティングシステム、サービス、及びアプリケーションの間でＡＰＩコールがなされる一実施形態を示す。
【図２３】規範的なコンピュータシステムアーキテクチャーの一実施形態を示す。
【図２４】規範的なコンピュータシステムアーキテクチャーの別の実施形態を示す。
【図２５】複数の異なるサービスプロバイダーを経て接続された複数のユーザを示す。
【図２６】ユーザの位置を識別するためにブルームフィルタを使用する本発明の一実施形態を示す。
【図２７】ブルームフィルタを使用する方法の一実施形態を示す。
【図２８】ブルームフィルタを使用する方法の別の実施形態を示す。
【図２９】本発明の一実施形態によりポイント・ツー・ポイント（Ｐ２Ｐ）接続を確立する２人のユーザを示す。
【図３０】特定のサービスプロバイダーにより使用されるリレーサービスを通してＰ２Ｐ接続を確立する２人のユーザを示す。
【図３１】リレーサービスを経てＰ２Ｐ接続を確立する本発明の別の実施形態を示す。
【図３２】本発明の一実施形態に使用されるＲＦＣ３９８４ヘッダを伴うＲＴＰパケットを示す。
【図３３】プッシュ通知サービス及び安全なインスタントメッセージングサービスを示す。
【図３４】安全なインスタントメッセージングセッションを確立する方法の一実施形態を示す。
【図３５】安全なインスタントメッセージングセッションを確立する方法の別の実施形態を示す。
【図３６】アイデンティティサービス及びアプリケーション認証サービスを含むシステムアーキテクチャーを示す。
【図３７】ユーザを安全に認証する方法の一実施形態を示す。
【図３８】キャッシング及び指紋を使用して認証効率を改善する本発明の一実施形態を示す。
【発明を実施するための形態】
【００１３】
ネットワーク上に一次及び／又はバックアップピア・ツー・ピア（Ｐ２Ｐ）通信チャンネルを確立し、維持し及び利用するための装置、方法、及びマシン読み取り可能な媒体の実施形態について以下に説明する。Ｐ２Ｐセッションに対して、ユーザを招待し及びユーザを対戦させるための、各々、インビテーションサービス及びマッチメーカーサービスについても説明する。更に、ある特定の条件のもとでユーザがリレー接続を確立できるようにするリレーサービスについても説明する。最後に、ここに述べる種々の共同なオンライン特徴の利点を取り入れたアプリケーションをアプリケーション開発者が設計できるようにするためのアプリケーションフレームワーク及びそれに関連したアプリケーションプログラミングインターフェイス（ＡＰＩ）について説明する。
【００１４】
本発明を完全に理解するために、記述全体を通して、説明上、多数の特定の細部について述べる。しかしながら、当業者であれば、幾つかの特定の細部がなくても、本発明を実施できることが明らかであろう。他の点については、本発明の基礎的な原理を不明瞭にしないために、良く知られた構造及び装置は、図示しないか又はブロック図の形態で示す。
【００１５】
接続データを効率的に且つ安全に交換する装置及び方法
図１に示すように、本発明の一実施形態で具現化される一般的なネットワークトポロジーは、「クライアント」又は「ピア」移動コンピューティング装置Ａ−Ｄ、１２０−１２３のグループを備え、これらは、ネットワーク１２０を経て互いに通信すると共に、１つ以上のサーバー１１０−１１２と通信する。図１には、単一のネットワーククラウドとして示されているが、「ネットワーク」１２０は、幾つか挙げると、インターネットのようなパブリックネットワークと、ローカルＷｉ−Ｆｉネットワーク（例えば、８０２．１１ｎホームワイヤレスネットワーク又はワイヤレスホットスポット）、ローカルエリアイーサネットネットワーク、セルラーデータネットワーク（例えば、３Ｇ、Ｅｄｇｅ、等）及びＷｉＭＡＸネットワークのようなプライベートネットワークと、を含めて種々の異なるコンポーネントを含む。例えば、移動装置Ａ  １２０は、ネットワークリンク１２５で表されたホームＷｉ−Ｆｉネットワークに接続され、移動装置Ｂ  １２１は、ネットワークリンク１２６で表された３Ｇネットワーク（例えば、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）、高速アップリンクパケットアクセス（ＨＳＵＰＡ）、等）に接続され、移動装置Ｃ  １２２は、ネットワークリンク１２７で表されたＷｉＭＡＸネットワークに接続され、そして移動装置１２３は、ネットワークリンク１２８で表されたパブリックＷｉ−Ｆｉネットワークに接続される。移動装置１２０−１２３が接続されるローカルネットワークリンク１２５−１２８の各々は、ゲートウェイ及び／又はＮＡＴ装置（図１には示さず）を通してインターネットのようなパブリックネットワークに結合され、それにより、パブリックネットワークを経て種々の移動装置１２０−１２３間で通信を行うことができる。しかしながら、２つの移動装置が、同じローカル又はプライベートネットワーク（例えば、同じＷｉ−Ｆｉネットワーク）にある場合には、２つの装置は、パブリックネットワークをバイパスして、そのローカル／プライベートネットワークを経て直接通信することができる。もちろん、本発明の基礎的な原理は、特定の１組のネットワーク形式又はネットワークトポロジーに制限されないことに注意されたい。
【００１６】
図１に示す移動装置１２０−１２３の各々は、接続データ交換（ＣＤＸ）サービス１１０、マッチメーカーサービス１１１、及びインビテーションサービス１１２と通信することができる。１つの実施形態において、サービス１１０−１１２は、サーバーのような１つ以上の物理的コンピューティング装置にわたって実行されるソフトウェアとして具現化することができる。図１に示したように、１つの実施形態では、サービス１１０−１１２は、同じエンティティ（例えば、同じデータサービスプロバイダー）により管理され且つ各移動装置１２０−１２３によりネットワーク１２０を経てアクセスできる大きなデータサービス１００のコンテキスト内で具現化される。このデータサービス１００は、種々の形式のサーバー及びデータベースを接続するローカルエリアネットワーク（例えば、イーサネットベースのＬＡＮ）を備えている。又、データサービス１００は、データを記憶するための１つ以上の記憶エリアネットワーク（ＳＡＮ）も備えている。１つの実施形態において、データベースは、移動装置１２０−１２３の各々及びそれら装置のユーザに関連したデータ（例えば、ユーザアカウントデータ、装置アカウントデータ、ユーザアプリケーションデータ、等）を記憶し且つ管理する。
【００１７】
１つの実施形態において、マッチメーカーサービス１１１は、特定の１組の条件に基づいて共同Ｐ２Ｐセッションに対して２つ以上の移動装置を対戦させることができる。例えば、２つ以上の移動装置のユーザは、特定のマルチプレーヤゲームをプレイすることに関心がある。そのような場合に、マッチメーカーサービス１１１は、各ユーザの専門的レベル、各ユーザの年齢、対戦要求のタイミング、対戦が要求される特定のゲーム、及び種々のゲーム特有変数のような変数に基づき、ゲームに参加すべき移動装置のグループを識別する。例えば、これに限定されないが、マッチメーカーサービス１１１は、特定のゲームをプレイする際に同様の経験レベルをもつユーザを対戦させるように試みる。更に、大人は、他の大人と対戦し、子供は、他の子供と対戦する。更に、マッチメーカーサービス１１１は、ユーザの要求を、それらの要求が受け取られた順序に基づいてプライオリティ決めする。本発明の基礎的な原理は、特定の１組の対戦基準にも、特定形式のＰ２Ｐアプリケーションにも限定されない。
【００１８】
以下に詳細に述べるように、対戦要求に応答して、マッチメーカーサービス１１１は、ＣＤＸサービス１１０と整合して、全ての対戦参加者が効率的に且つ安全にＰ２Ｐセッションを確立するのに必要な接続データを受け取ることを保証する。
【００１９】
１つの実施形態において、インビテーションサービス１１２も、共同Ｐ２Ｐセッションへの参加に対して移動装置を識別する。しかしながら、インビテーションサービス１１２の場合には、参加者の少なくとも１人が別の参加者により特別に識別される。例えば、移動装置Ａ  １２０のユーザは、移動装置Ｂ  １２１のユーザとの共同セッションを特別に要求する（例えば、移動装置ＢをユーザＩＤ又は電話番号で識別する）。マッチメーカーサービス１１１と同様に、インビテーション要求に応答して、インビテーションサービス１１２は、１組の参加者を識別し、そしてＣＤＸサービス１１０と整合して、全ての対戦参加者が効率的に且つ安全にＰ２Ｐセッションを確立するのに必要な接続データを受け取ることを保証する。
【００２０】
上述したように、１つの実施形態では、ＣＤＸサービス１１０は、２つ以上の移動装置間にＰ２Ｐセッションを確立するために要求される接続データのための中央交換点として動作する。特に、ＣＤＸサービスの１つの実施形態は、移動装置要求に応答してＮＡＴ横断データ（時々「ホール・パンチ」データとも称される）を発生し、外部サービス及びクライアントが各移動装置のＮＡＴを通して通信する（即ち、ＮＡＴに「穴を開けて」装置に到達する）ことができるようにする。例えば、１つの実施形態では、ＣＤＸサービスは、移動装置と通信するのに必要な外部ＩＰアドレス及びポートを検出し、そしてこの情報を移動装置に与える。１つの実施形態において、ＣＤＸサービスは、マッチメーカーサービス１１１及びインビテーションサービス１１２により発生された移動装置のリストを受け取って処理し、そしてそのリストに含まれた各移動装置へ接続データを効率的且つ安全に配布する（以下に詳細に述べるように）。
【００２１】
１つの実施形態において、移動装置とＣＤＸサービス１１０との間の通信は、ユーザデータグラムプロトコル（ＵＤＰ）ソケットのような比較的軽量のネットワークプロトコルを使用して確立される。当業者に知られたように、ＵＤＰソケット接続は、パケット信頼性、順序又はデータ完全性を保証するためにハンドシェークダイアログを要求せず、それ故、ＴＣＰソケット接続のように多量のパケット処理オーバーヘッドを消費しない。その結果、ＵＤＰの軽量でステートレスの性質は、膨大な数のクライアントからの小さな問合せに返答するサーバーにとって有用である。更に、ＴＣＰとは異なり、ＵＤＰは、パケットブロードキャスティング（ローカルネットワーク上の全ての装置にパケットが送信される）、及びマルチキャスティング（ローカルネットワーク上の装置の副組にパケットが送信される）に適合する。以下に述べるように、たとえＵＤＰが使用されても、セッションキーを使用してＮＡＴ横断データを暗号化することによりＣＤＸサービス１１０にセキュリティを維持することができる。
【００２２】
ＣＤＸサービス１１０により使用される低オーバーヘッドの軽量ネットワークプロトコルとは対照的に、１つの実施形態では、移動装置１２０−１２３とマッチメーカーサービス１１１及び／又はインビテーションサービス１１２との間の通信は、ハイパーテキストトランスファープロトコルセキュア（ＨＴＴＰＳ）のような本来的に安全なネットワークプロトコルで確立され、これは、セキュアソケットレイヤ（ＳＳＬ）又はトランスポートレイヤセキュリティ（ＴＬＳ）接続に依存する。これらのプロトコルに関する詳細は、当業者に良く知られている。
【００２３】
図２ａは、ＣＤＸサーバーにより実施できる規範的な一連のトランザクションを示す。ＣＤＸサーバーの１つの実施形態の動作を説明するときには、以下の用語は、以下の意味をもつ。
【００２４】
接続データ：これは、潜在的なピアが、ピア・ツー・ピアセッションを確立するために互いに交換する必要のある情報である。この情報をどのように交換するかのメカニズムの実施形態は、以下で説明する。
【００２５】
ＣＤＸサーバー：１つの実施形態におけるＣＤＸサーバーは、許可されたエンティティが任意のデータを交換できるようにする認証マルチキャストリフレクタ(authenticated multicast reflector)である。このデータは、ペイロードと称される。
【００２６】
ＣＤＸセッション：ＣＤＸセッションとは、ＣＤＸサーバーを経て互いに通信することのできるクライアント装置のグループを指す。セッションの一部分である各クライアント装置には、ＣＤＸチケットが指定される。各セッションは、独特のＣＤＸセッションＩＤを有し、これは、個々のセッションを識別し又は参照するのに使用できる大きな整数である。
【００２７】
ＣＤＸ要求：クライアント装置からＣＤＸサーバーへ伝送される要求である。この要求は、一般的に、２つの部分、即ちＣＤＸチケット及びペイロードより成る。この実施形態では、ペイロードは、セッションキーで暗号化された接続データである。
【００２８】
ＣＤＸ応答：ＣＤＸ応答は、ＣＤＸサーバーがＣＤＸセッションのメンバーからＣＤＸ要求を受け取るときにＣＤＸセッションにおいて他の装置へ「反射」して戻されるものである。これは、所与のＣＤＸ要求に使用されるＣＤＸチケットのＣＤＸチケットスタブにペイロードを添付することにより構成される。
【００２９】
ＣＤＸチケット：ＣＤＸチケットは、ＣＤＸセッションのメンバーにペイロードをどのように送信するかＣＤＸサーバーに告げる。１つの実施形態では、偽造又は改竄を防止するためにＣＤＸチケットキーで「署名」される。図３に示すように、１つの実施形態では、ＣＤＸチケットは、次の情報を含む。
【００３０】
ある実施形態では暗号化も不明瞭化もされないセッションＩＤ３０１。
【００３１】
ある実施形態では暗号化も不明瞭化もされないセッションにおける参加者数３０２。
【００３２】
このチケットがセッションにおいてどの参加者を指すかのインデックス３０３（ある実施形態では暗号化も不明瞭化もされない）。
【００３３】
それ以降はチケットが無効になると考えられる満了時間／日付３０４（ある実施形態では暗号化も不明瞭化もされない）。
【００３４】
ある実施形態ではＣＤＸチケットキーを使用して暗号化されるセッションにおける各参加者のためのＣＤＸホール・パンチデータ。
【００３５】
チケットが本物であることを保証するために「デジタル署名」として働くＣＤＸチケットキーを使用するメッセージ認証コード３０７。
【００３６】
ＣＤＸチケットスタブ：ＣＤＸチケットの第１部分、マイナスＣＤＸホール・パンチデータ及びメッセージ認証コード。
【００３７】
ペイロード：これは、ＣＤＸ要求及びＣＤＸ応答の第２部分である。ペイロードは、クライアント装置がＣＤＸセッションにおける他の装置へ通信したいデータである。この実施形態では、ペイロードは、セッションキーで暗号化された接続データである。ＣＤＸサーバーは、ペイロードを解読せず、１つの実施形態では、不変のまま通過させるだけである。
【００３８】
セッションキー：これは、接続データを暗号化するためにクライアントにより使用されるキーである。ある実施形態では、このキーは、ＣＤＸサーバーに知られていない。この実施形態では、セッションキーは、マッチメーカーサービスにより発生され、そしてそれらの個々のＣＤＸチケットと共にクライアントへ伝送される。
【００３９】
ＣＤＸチケットキー：これは、ＣＤＸチケットを生成しそして「署名」するために使用されるキーである。ＣＤＸチケットキーは、ＣＤＸサーバーと、ＣＤＸチケットを発生するサービスしか知らないもので、そのサービスは、以下に述べるように、マッチメーカーサービス及び／又はインビテーションサービスである。
【００４０】
ＣＤＸホール・パンチ要求：ＣＤＸサーバーからＣＤＸホール・パンチデータを得るのに使用されるＣＤＸ要求の特殊な形式。
【００４１】
ＣＤＸホール・パンチデータ：これは、最初に要求を発したクライアントへＣＤＸサーバーがどのように情報を送信できるか記述する不透明なデータブロブである。これは、ＣＤＸホール・パンチ要求をＣＤＸサーバーに送信することにより得られる。ＣＤＸホール・パンチデータは、ＣＤＸチケットを発生する前にＣＤＸセッションにおいて各クライアント装置から収集されねばならない。ＣＤＸホール・パンチデータ（時々「ＮＡＴ横断データ」とも称される）は、要求側装置のパブリックＩＰアドレス及びポートを含む。
【００４２】
図２ａを参照すれば、１つの実施形態において、移動装置Ａ  １２０及び移動装置Ｂ  １２１は、１つ以上の他のコンピューティング装置とのＰ２Ｐ接続を要求するマルチプレーヤゲーム又は共同チャットセッションのような共同アプリケーションを実行することができる。２０１ａにおいて、移動装置Ａ  １２０は、ＣＤＸホール・パンチ要求をＣＤＸサーバー１１０へ送信する。ＣＤＸサーバー１１０は、２０２ａにおいて、ＣＤＸホール・パンチデータで応答する。１つの実施形態では、ホール・パンチデータは、移動装置ＡのパブリックＩＰアドレス及びポート、及び／又は移動装置ＡのＮＡＴを通して穴を開けるのに必要な他のデータ（例えば、移動装置ＡのＮＡＴ形式を定めるＮＡＴ形式データ）を含む。移動装置Ｂについても、２０１ｂ及び２０２ｂにおいて、各々、同様のトランザクションが遂行される。
【００４３】
次いで、２０３ａ及び２０３ｂにおいて、移動装置Ａ及びＢは、ＣＤＸホール・パンチデータを含む対戦要求を、付加的な対戦基準（以下に述べる）と共に、マッチメーカーサービスへ送信する。この段階で、移動装置Ａ及びＢは、Ｐ２Ｐ接続を確立するのに必要な接続データを形成し始める。これは、例えば、標準的インターネット接続確立（ＩＣＥ）トランザクションのようなトランザクションを使用して（例えば、ＮＡＴ横断サービスにより）達成される。しかしながら、本発明の基礎的な原理は、接続データを決定するための特定のメカニズムに限定されない。
【００４４】
１つの実施形態において、マッチメーカーサービス１１１が対戦基準で１組のクライアント装置を見つけると、独特のＣＤＸセッションＩＤ、ＣＤＸセッションの各メンバーに対する独特のＣＤＸチケット、及び独特のセッションキーを発生する。１つの実施形態において、マッチメーカーサービス１１１は、独特のＣＤＸチケットキーを使用してＣＤＸチケットのためのＣＤＸホール・パンチデータを暗号化する。２０４ａ及び２０４ｂにおいて、マッチメーカーサービスは、移動装置Ａ及びＢの各々に、それらのＣＤＸチケット及びセッションキーを送信する。
【００４５】
移動装置Ａは、ＣＤＸチケット及びセッションキーを受け取り、そしてセッションキーを使用して、その既に決定された接続データを暗号化して、ペイロードを形成する。１つの実施形態において、移動装置Ａは、形成されたペイロードをＣＤＸチケットに添付することによりＣＤＸ要求を形成する。２０５ａにおいて、移動装置Ａは、ＣＤＸ要求をＣＤＸサーバー１１０へ送信する。移動装置Ｂも、同じ動作を行って、２０５ｂにおいてＣＤＸサーバーへ要求を送信する。
【００４６】
２０６ａにおいて、ＣＤＸサーバー１１０は、ＣＤＸ要求を受け取り、それが有効であり且つ本物であることを保証するためにチケットを検査する（例えば、メッセージ認証コード３０７に基づき）。ＣＤＸチケットが無効である場合には、要求がドロップされる。１つの実施形態では、ＣＤＸサーバーは、ＣＤＸチケットキーを使用してＣＤＸチケットに含まれたＣＤＸホール・パンチデータセットを解読する。１つの実施形態では、ＣＤＸチケットキーは、チケットと共に送信される満了時間／日付を含む。ＣＤＸサービス１１０及びマッチメーカーサービス１１１は、暗号／解読のために２つ（以上）の異なるＣＤＸチケットキー、即ち現在アクティブな第１キー、及び第１キーの満了時間／日付に到達した際にアクティブとなる第２キーを記憶することができる。チケットを受け取ると、ＣＤＸサービス１１０は、満了時間／日付を読み取って、どのチケットキーを使用すべきか決定することができる。ＣＤＸチケットキーが満了になると、ＣＤＸサービス１１０及びマッチメーカーサービス１１１は、各々、新たなチケットキー（現在チケットキーが満了になった後に使用される次のキー）を発生することができる。１つの実施形態では、ＣＤＸサービス１１０及びマッチメーカーサービス１１１は、２つのチケットキーとの一貫性を保証するために同じキー発生アルゴリズムを実行する。例えば、良く知られたＲＳＡ  ＳｅｃｕｒｅＩＤ認証メカニズムに使用される技術であって、新たな認証コードが固定のインターバルで発生される技術が使用される。１つの実施形態では、新たなＣＤＸチケットキーが毎日発生される。しかしながら、本発明の基礎的な原理は、ＣＤＸチケットキーを発生するための特定のメカニズムに限定されない。
【００４７】
移動装置Ｂについても、２０６ｂに示すように同じ動作を行うことができる。ＣＤＸサーバーは、ＣＤＸ要求からＣＤＸ応答を形成し、次いで、ＣＤＸホール・パンチデータを使用して、ＣＤＸ応答をＣＤＸセッションにおける参加者に送信する（２０７ａにおいて移動装置Ｂに及び２０７ｂにおいて移動装置Ａに送信する）。
【００４８】
移動装置Ｂは、ＣＤＸサーバーからＣＤＸ応答２０７ａを受け取る。クライアント装置Ｂは、セッションＩＤがそれ自身のＣＤＸチケットのセッションＩＤに一致することを保証するためにＣＤＸチケットスタブを検査する。次いで、移動装置Ｂは、セッションキーを使用してペイロードを解読し、移動装置Ａから接続データを生じさせる。次いで、移動装置Ｂは、移動装置Ａからの接続データを使用して、Ｐ２Ｐセッションを確立するプロセスを開始する。１つの実施形態では、それらは、標準的なトランザクションを含む。しかしながら、本発明の基礎的な原理は、Ｐ２Ｐ通信を確立するための特定のメカニズムに限定されない。
【００４９】
上述したように、１つの実施形態では、移動装置Ａ及びＢは、（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）マッチメーカーサービス１１１と通信するためにハイパーテキストトランスファープロトコルセキュア（ＨＴＴＰＳ）セッションを確立すると共に、ＣＤＸサービスと通信するためにＵＤＰソケットを確立する。対戦要求２０４ａ、２０４ｂは、各々の移動装置について以前に決定されたＮＡＴ形式及びホール・パンチデータ（例えば、パブリックＩＰアドレス及びポート）を含む。マルチプレーヤゲームを含む実施形態では、各対戦要求は、各移動装置のプレーヤ（例えば、独特のプレーヤＩＤコードを使用する）、各ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び／又は希望のゲームに関連した他のゲーム構成変数を識別することができる。例えば、これに限定されないが、ゲームに関連したゲーム構成変数は、困難さのレベル（例えば、容易、普通、困難）、ユーザの年齢（例えば、「１３未満」）、ゲームのサブ領域（例えば、「レベル２」）、及び／又はプレーヤの熟練度レベル（例えば、熟練者、初心者、中間者）を含む。以下に詳細に述べるように、これらの変数は、時々、ゲーム「バケット(bucket)」と称され、そして独特の「バケットＩＤ」を使用して識別される。各ゲームは、異なるゲーム構成変数を識別するためにバケットＩＤの異なるセットを含む。
【００５０】
１つの実施形態では、移動装置Ｂは、２０８ａ及び２０９ａにおいて確認を送信する。同様に、２０８ｂ及び２０９ｂにおいて、移動装置Ａの確認が送信される。移動装置Ａ又はＢの確認が指定期間の後に受け取られない場合には、接続データ２０７ａが移動装置Ｂ２１２へ再送される。ＣＤＸサーバー１１０が再試みを開始するか、及び／又は移動装置Ａ  １２０が再試みを開始する。
【００５１】
図２ｂは、３つの異なる移動装置１２０−１２２がＣＤＸサービス及びマッチメーカーサービス１１１を使用してＰ２Ｐ接続についてネゴシエーションする例を更に詳細に示す。又、図２ｂは、接続を確立するために移動装置１２０−１２２により使用される２つの付加的なサービス、即ちＮＡＴ形式を決定するためのＮＡＴ横断サービス２９１と、（例えば、ＩＣＥ接続データトランザクションを使用して）各移動装置のための完全接続データを決定するＮＡＴ横断サービス２９０も示している。しかしながら、本発明の基礎的な原理に合致するために個別のサービスは要求されないことに注意されたい。例えば、別の実施形態では、それらのサービス２９０−２９１の各々によって行われるＮＡＴ横断機能は、ＣＤＸサービス１１０及び／又はマッチメーカーサービス１１１内に直接的に一体化される。同様に、両ＮＡＴ横断サービス２９０−２９１によって行われる機能は、単一のＮＡＴ横断サービス内に一体化される。要約すれば、図２ｂに示す特定の機能分離は、本発明の基礎的な原理に合致するために要求されるものではない。
【００５２】
図２ｂの特定の細部を参照すれば、２２０において、移動装置Ａは、ＮＡＴ形式の要求をＮＡＴ横断サービス２９１へ送信する。それに応答して、ＮＡＴ横断サービス２９１は、一連のトランザクションを実施することを含む種々の既知の技術を使用して、移動装置Ａにより使用されるＮＡＴ形式を決定する。例えば、ＮＡＴ横断サービス２９１は、移動装置ＡのＮＡＴにおける異なるＩＰアドレス及びポートをオープンし、そして異なるＩＰ／ポート組み合わせを使用してそれらおポートを通して移動装置Ａと通信するように試みる。このように、移動装置Ａにより使用されるＮＡＴは、上述したＮＡＴ形式（例えば、完全コーン、制限コーン、ポート制限コーン、対称的）又は別のＮＡＴ形式の一方として分類される。この情報は、次いで、図示されたように、移動装置Ａ  １２０へ送られる。
【００５３】
２２１において、移動装置Ａ  １２０は、ＮＡＴ横断要求をＣＤＸサービス１１０で開始する。それに応答して、ＣＤＸサービス１１０は、その要求に使用されたパブリックＩＰアドレス及びパブリックポート番号を読み取り、そしてその情報を移動装置Ａ  １２０へ返送する。上述したように、装置がＮＡＴの後方にある場合には、そのパブリックポート及びＩＰアドレスは、各々、そのプライベートポート及びＩＰアドレスとは異なる。従って、使用するＮＡＴの形式に基づき、パブリックＩＰアドレス及びポートは、移動装置に到達するためにＮＡＴ装置を通して「穴を開ける(punch a hole)」のに使用される。
【００５４】
２２２において、移動装置Ａ  １２０は、対戦要求２２２をマッチメーカーサービス１１１へ送信する。上述したように、１つの実施形態では、移動装置Ａは、ハイパーテキストトランスファープロトコル（ＨＴＴＰＳ）セッションを使用して（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）マッチメーカーサービスと通信する。対戦要求は、移動装置Ａ  １２０について以前に決定されたＮＡＴ形式及びホール・パンチデータ（例えば、パブリックＩＰアドレス及びポート）を含む。マルチプレーヤゲームを含む実施形態では、対戦要求は、移動装置Ａのプレーヤ（例えば、独特のプレーヤＩＤコードを使用する）、ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び／又は希望のゲームに関連した他のゲーム構成変数を識別することができる（図２ａを参照して上述したように）。
【００５５】
２２３−２２５において、トランザクション２２０−２２２に対応する１組のトランザクションが移動装置Ｂ  １２１について行われ、そして２２６−２２８において、トランザクション２２０−２２２に対応する１組のトランザクションが移動装置Ｃ  １２２について行われる。従って、トランザクション２２８に続いて、マッチメーカーサービス１１１は、３つの移動装置１２０−１２２の全部について対戦要求を受け取る。この特定例では、対戦要求の結果として、移動装置１２０−１２２は、マルチプレーヤゲームのような特定の共同セッションに対して試合が組まれる（例えば、これら移動装置のユーザは、同じ又は同様の組の変数で同じゲームを選択し、それにより、マッチメーカーサービス１１１で試合を組むことになる）。
【００５６】
マッチメーカーサービス１１１は、各対戦要求に含まれたデータを使用して、チケットＡ、チケットＢ、及びチケットＣを発生し、チケットＡは、２２９において移動装置Ａへ送信され、チケットＢは、２３０において移動装置Ｂへ送信され、そしてチケットＣは、２３１において移動装置Ｃへ送信される。図２ｂには示されていないが、マッチメーカーサービス１１１は、チケットＡ、Ｂ及びＣを各々移動装置Ａ、Ｂ及びＣにプッシュするためにプッシュ通知サービスを使用する（例えば、図１１−１２に示すプッシュ通知サービス１０５０のような）。チケットＡ、Ｂ及びＣに使用されるチケットデータ構造の１つの実施形態は、図３を参照して上述した。
【００５７】
２３２において、移動装置Ａ  １２０は、ＮＡＴ横断サービス２９０と通信して、それ自身の接続データを決定する。１つの実施形態では、これは、標準的ＩＣＥ接続データトランザクションを含む。既に述べたように、接続データは、移動装置Ａ  １２０のパブリック／プライベートＩＰアドレス、ポート及びＮＡＴ形式を含む。
【００５８】
移動装置Ａ  １２０は、その接続データをチケットＡに添付し、２３３において、チケットＡを接続データと共にＣＤＸサービス１１０へ送信する。１つの実施形態では、ＣＤＸサービス１１０は、チケットＡを上述したように処理し、２３４において、接続データ（暗号化された）を移動装置Ｂ  １２１及び移動装置Ｃ  １２２へ送信する。これらトランザクションでは、ＣＤＸサービス１１０は、チケットＡと共に含まれた移動装置Ｂ及びＣのＮＡＴ横断データを使用する。
【００５９】
２３６−２３８において、トランザクション２３２−２３４に対応する１組のトランザクションは、チケットＢを使用して行われ、そして２３８−２４０において、トランザクション２３２−２３４に対応する１組のトランザクションは、チケットＣを使用して行われる。従って、トランザクション２４０に続いて、接続データが各移動装置１２０−１２２間で共有される。接続データを使用して、移動装置ＡとＢとの間、移動装置ＡとＣとの間、そして移動装置ＡとＣとの間にＰ２Ｐセッションが確立される。
【００６０】
図２ｃに示すように、インビテーションサービス１１２もＣＤＸサービス１１０と共に使用される（マッチメーカーサービス１１１に代わって又はそれに加えて）。１つの実施形態では、インビテーションサービス１１２は、特定の移動装置及び／又はユーザとのＰ２Ｐ接続に対するインビテーション要求を処理する。このインビテーションサービス１１２は、ステートレスサービス（即ち、各ワイヤレス装置間のトランザクションの現在状態をタックしないサービス）として実施される。
【００６１】
この特定例を参照すれば、２５０において、移動装置Ａ  １２０は、ＮＡＴ形式要求をＮＡＴ横断サービス２９１へ送信する。それに応答して、ＮＡＴ横断サービス２９１は、種々の既知の技術を使用して、移動装置Ａにより使用されるＮＡＴ形式を決定する（その幾つかは、上述した）。２５１において、移動装置Ａ  １２０は、ＣＤＸサービス１１０でＮＡＴ横断要求を開始する。それに応答して、ＣＤＸサービス１１０は、要求に使用されたパブリックＩＰアドレス及びパブリックポート番号を読み取り、そしてその情報を移動装置Ａ  １２０へ返送する。上述したように、装置がＮＡＴの後方にある場合には、そのパブリックポート及びＩＰアドレスが各々そのプライベートポート及びＩＰアドレスとは異なる。従って、使用されるＮＡＴの形式に基づき、パブリックＩＰアドレス及びポートは、移動装置に到達するためにＮＡＴ装置を通して「穴を開ける」のに使用される。
【００６２】
マッチメーカーサービスと同様に、１つの実施形態では、各移動装置は、ハイパーテキストトランスファープロトコルセキュア（ＨＴＴＰＳ）セッションを使用して（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）インビテーションサービス１１２と通信する。
【００６３】
２５２において、移動装置Ａ  １２０は、移動装置ＡのＮＡＴ横断データ（例えば、ＮＡＴ形式、パブリックＩＰアドレス／ポート）を含むインビテーション要求をインビテーションサービス１１２へ送信する。プッシュ通知サービス（以下に詳細に述べる）を使用する実施形態では、インビテーション要求は、移動装置Ａのプッシュトークンも含む。インビテーション要求２５２は、１つ以上の他のユーザ／装置、この場合は、移動装置Ｂ  １２１及びＣ  １２２のユーザを識別する識別コードも含む。種々の異なる識別コード形式が使用される。例えば、マルチプレーヤゲームの場合には、識別コードは、ゲーム特有のプレーヤＩＤコードを含む。オーディオ／ビデオチャットセッションの場合には、識別コードは、移動装置Ａの「相棒」リストのユーザから１人以上のユーザを識別する電話番号又は独特のＩＤコードを含む。
【００６４】
１つの実施形態において、インビテーションサービス１１２は、インビテーション要求から識別コードを読み取り、そして登録データベース（図示せず）においてルックアップを遂行して、移動装置Ｂ及びＣの各々を探索する。１つの特定の実施形態では、移動装置Ｂ及びＣの各々は、インビテーションサービス１１２からプッシュ通知を受け取るためにプッシュサービスに既に登録されている。従って、この実施形態では、インビテーションサービス１１２は、プッシュ通知サービスを使用して、インビテーション要求を、２５３及び２５４において、移動装置Ｂ  １２１及び移動装置Ｃ  １２２に各々プッシュする。プッシュ通知サービスに関連した付加的な細部は、以下に説明され（例えば、図１１−１２及び関連テキストを参照）、並びに前記プッシュ通知アプリケーションに説明されている。
【００６５】
１つの実施形態において、インビテーション要求２５３及び２５４は、図３に示されて図２ａ−ｂを参照して上述されたチケットデータ構造を含む。特に、移動装置Ｂへ送られるチケットは、移動装置Ａ及びＢを識別する暗号リストを含み、そして移動装置Ｃへ送られるチケットは、移動装置Ａ及びＣを識別する暗号リストを含む。１つの実施形態では、インビテーションサービス１１２がまだ移動装置ＢのＮＡＴ横断データをもたないので、２５３において「チケット」は、移動装置Ｂを識別する他の情報を含む。例えば、リレーサービス及びプッシュ通知サービスを利用する実施形態について以下に述べるように（例えば、図１１−１２を参照）、２５３において「チケット」は、移動装置ＡのＮＡＴ横断データ、装置ＡのＩＤコード、装置Ａのプッシュトークン、装置ＢのＩＤコード及び移動装置Ｂのプッシュトークンを含む。２５４において、移動装置Ａ及びＣに対して同じ形式の情報が与えられる。
【００６６】
２５５において、移動装置Ｂは、そのＮＡＴ形式を決定するためにＮＡＴ横断サービス２９１と通信し、そして２５６において、移動装置Ｂは、そのＮＡＴ横断データ（例えば、パブリックＩＰアドレス／ポート）を決定するためＣＤＸサービス１１０と通信する。２５７において、移動装置Ｂは、移動装置Ａ及び移動装置Ｂの識別コードと、ＮＡＴ横断データと、プッシュ通知サービスが使用される場合は移動装置Ａ及びＢのためのプッシュトークンとを含むインビテーション応答をインビテーションサービス１１２へ送信する。２５８において、移動装置Ｂは、移動装置Ｂは、ＮＡＴ横断サービス２９１と通信することによりその現在接続データを検索する。２５９において、移動装置Ｂは、そのチケット（チケットＢ）をその現在接続データと共にＣＤＸサービス１１０へ送信する。それに応答して、ＣＤＸサーバー１１０は、上述したようにチケットを処理し、そして接続データを移動装置Ａ  １２０に転送する。
【００６７】
移動装置Ｂのインビテーション応答を受信すると、インビテーションサービス１１２は、移動装置Ａの暗号チケットを発生し、そして２６０において、そのチケットを移動装置Ａへ送信する。１つの実施形態では、そのチケットは、移動装置Ａ及びＢのＮＡＴ横断データ、ＮＡＴ形式、及びプッシュトークン（プッシュ通知サービスが使用される場合）を含む。図２ｃを参照して述べる「チケット」は、マッチメーカーサービス１１１を参照して述べる「チケット」のためのデータ構造と同じでもよいし、異なってもよい。例えば、上述したように暗号「チケット」を発生するのではなく、インビテーションサービス１１２は、各移動装置でインビテーションセッションを識別するために独特のセッションＩＤを発生するだけでもよい。
【００６８】
２６１において、移動装置Ａは、ＮＡＴ横断サービス２９０と通信することによりその現在通知データを検索する。次いで、移動装置Ａは、その接続データをチケットに添付し、そして２６２において、チケットをその接続データと共にＣＤＸサービス１１０へ送信する。ＣＤＸサービス１１０は、上述したようにチケットを処理し、そして移動装置Ａの接続データを移動装置Ｂへ転送する。最後に、２６３において、移動装置Ａ及びＢは、交換した接続データを使用して直接Ｐ２Ｐ接続をオープンする。以下に述べるように、移動装置Ａ及びＢのＮＡＴ形式が不適合である場合には、リレーサービスを使用して、移動装置ＡとＢとの間で通信を行えるようにする。
【００６９】
２６４−２７２において、移動装置Ｃ  １２２及び移動装置Ａは、一連のトランザクションを実行して、移動装置Ｂ及びＡについて２５５−２６３で述べたＰ２Ｐ接続を確立する。特に、６２４において、移動装置Ｃ  １２２は、そのＮＡＴ形式を決定するためにＮＡＴ横断サービス２９１と通信し、そして２６５において、そのＮＡＴ横断データ（例えば、パブリックＩＰアドレス／ポート）を決定するためにＣＤＸサービス１１０と通信する。２６６において、移動装置Ｃは、移動装置Ｃ及び移動装置ＡのＮＡＴ形式、ＮＡＴ横断データ及びプッシュトークン（プッシュ通知サービスが使用される場合）を含むインビテーション応答を送信する。２６７において、移動装置Ｃは、ＮＡＴ横断Ｐ２Ｐサービス２９０を通してその現在接続データを検索し、そして２６８において、移動装置Ｃは、その接続データをチケットＣに添付して、チケットＣをＣＤＸサービス１１０へ送信する。ＣＤＸサービス１１０は、上述したようにチケットを処理し、そして移動装置Ｃの接続データを移動装置Ａ  １２０へ転送する。
【００７０】
２６９において、移動装置Ａ  １２０は、移動装置Ａ及びＣのＮＡＴ形式、ＮＡＴ横断データ及びプッシュトークン（プッシュサービスが利用される場合）を含む移動装置Ｃのインビテーション応答をインビテーションサービス１１２から受信する。２７０において、移動装置Ａは、その現在接続をＮＡＴ横断サービス２９０から検索し、その現在接続データをチケットＡに添付し、そして２７１において、チケットＡをＣＤＸサービス１１０へ送信する。或いは又、トランザクション２７０は、移動装置がトランザクション２６１においてその接続データを決定しているために要求されない。ＣＤＸサービス１１０は、上述したようにチケットを処理し、そして移動装置Ａの接続データを移動装置Ｃへ転送する。最後に、２７２において、移動装置Ａ及びＣは、交換した接続データを使用して、直接Ｐ２Ｐ接続２７２を確立する。
【００７１】
１つの実施形態において、インビテーションサービス１１２及びマッチメーカーサービス１１１は、移動装置へデータをプッシュするためにプッシュ通知サービス（図示せず）に依存する。例えば、図２ｃにおいて、インビテーション要求２５３及び２５４は、プッシュ通知サービスを経て移動装置Ｂ  １２１及びＣ  １２２へプッシュされる。同様に、図２ａにおいて、チケットＡ及びＢは、移動装置Ａ  １２０及びＢ  １２１へプッシュされる。１つの実施形態において、移動装置は、それがネットワークにおいてアクチベートされると、プッシュ通知サービスによりアクセス可能な中央登録ディレクトリにそのプッシュトークンを登録する。１つの実施形態では、登録ディレクトリは、パスワードで保護されたユーザＩＤ又は電話番号をプッシュトークンに関連付ける。ディレクトリにおいてプッシュトークンを識別できる場合には、プッシュ通知サービスは、プッシュトークンを使用してプッシュ通知を移動装置へ送信する。１つの実施形態では、プッシュ通知サービスは、本出願の譲受人により設計されて前記プッシュ通知アプリケーションに述べられたアップルプッシュ通知サービス（ＡＰＮＳ）である。しかしながら、プッシュ通知サービスは、図２ａ−ｃに示す本発明の実施形態により要求されるものでないことに注意されたい。例えば、プッシュ通知は、ＣＤＸサービス１１０がここに述べるその動作を遂行するのに要求されるものではない。
【００７２】
図４は、接続データを交換するためにＣＤＸサービス１１０により実施できる方法を示し、そして図５は、接続データを交換してＰ２Ｐ接続を確立するために移動装置により実施される方法を示す。これらの方法の幾つかの観点は、図１−２ｃを参照して既に説明した。特に、これらの方法は、図１−２ｃに示すネットワークアーキテクチャーの環境内で実施されるが、そのようなアーキテクチャーに限定されるものではない。１つの実施形態において、これらの方法は、プロセッサにより実行されたときに、これらの方法の動作を遂行させるプログラムコードで実施される。このプログラムコードは、プロセッサにより実行される間にランダムアクセスメモリ（ＲＡＭ）のようなマシン読み取り可能な媒体に記憶される。プロセッサは、汎用プロセッサ（例えば、Ｉｎｔｅｌ(登録商標)ＣｏｒｅTMプロセッサ）又は特殊目的プロセッサである。しかしながら、これらの方法は、ハードウェア、ソフトウェア及びファームウェアの組み合わせを使用して具現化されてもよい。更に、プログラムコードは、ハードディスクドライブのような不揮発性記憶装置、光学的ディスク（例えば、デジタルビデオディスク又はコンパクトディスク）、又はフラッシュメモリ装置のような不揮発性メモリに記憶される。
【００７３】
図４に示した方法を参照すれば、４０１において、特定の移動装置、この例では「移動装置Ａ」に対してＮＡＴ横断要求（時々「ホール・パンチ」要求とも称される）が受け取られる。４０２において、ＮＡＴ横断応答が発生されて移動装置Ａへ送信される。１つの実施形態では、ＮＡＴ横断応答の発生は、移動装置Ａの現在パブリックＩＰアドレス／ポート及び／又はＮＡＴ形式を決定することを含む。
【００７４】
その後、上述したマッチメーカーサービス１１１又はインビテーションサービス１１２のようなチケット発生エンティティにより移動装置Ａのチケットが発生されて暗号化される。４０３において、移動装置Ａに対して発生されたチケット（チケットＡ）が受け取られ、これは、ＮＡＴ横断データ（装置Ａ及び１つ以上の他の装置のための）及び装置Ａの接続データを含む。４０４において、メッセージ認証コードを使用してチケットが認証されると共に、チケットを暗号化するためにチケット発生エンティティにより使用されたものと同じＣＤＸチケットキーを使用してホール・パンチデータが解読される。上述したように、１つの実施形態では、ＣＤＸチケットキーに関連した満了時間／日付を使用して、正しいＣＤＸチケットキーが識別される。
【００７５】
４０５において、移動装置のためのＮＡＴ横断データが抽出される。４０６において、移動装置Ａの接続データは、ＮＡＴ横断データを使用して各ピアへ送信される。４０７において、各ピアから確認が受信される。全てのピアから確認が受信されないことが４０８において決定されると、移動装置Ａの接続データは、４０９において、応答していないピアへ再送信される。全ての接続データが確認されたことが４０８において決定されると、この方法は、終了となる。
【００７６】
１つの実施形態において、図４に示す方法は、Ｐ２Ｐ接続を確立するのに必要な接続データを各ピアが受信するよう保証するためにＰ２Ｐトランザクションに含まれた各ピアについて行うことができる。
【００７７】
図５は、ここに述べる本発明の実施形態に基づいて移動装置によって遂行される方法を示す。５０１において、ＮＡＴ横断要求が送信され、そして５０２において、ＮＡＴ横断応答が受信される。上述したように、その応答に含まれるＮＡＴ横断データは、要求側装置のパブリックポート／ＩＰアドレスを含む。５０３において、ＮＡＴ横断データを含む対戦要求が送信される。その後、上述したマッチメーカーサービス１１１又はインビテーションサービス１１２のようなチケット発生エンティティによって移動装置のチケットが発生され暗号化される。上述したチケットデータ構造とは別に、マッチメーカーサービス１１１及び／又はインビテーションサービス１１２は、独特のセッションＩＤを使用して各参加者を識別するだけでもよい。
【００７８】
５０４において、チケットが受信され、５０５において、移動装置の接続データがチケットに添付され、そして５０６において、接続データを伴うチケットが送信される。５０７において、１つ以上の他のピアとＰ２Ｐ接続を確立するのに必要な接続データが受信される。５０８において、１つ以上の他のワイヤレス装置が５０６において送信された接続データを受信したことを指示する確認が受け取られる。全ての確認が受信されない場合には、５１０において、確認が受信されていない移動装置へ接続データが再送信される。全ての確認が受信されたことが５０９で決定された場合は、５０７で受信された接続データを使用して、他の移動装置とのＰ２Ｐセッションを確立する。
【００７９】
バックアップ通信チャンネルを確立して利用する装置及び方法
現在の移動装置は、種々の異なる通信チャンネルを経て通信することができる。例えば、アップルｉＰｈｏｎｅTMは、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ、ｇ、ｎネットワーク）；３Ｇネットワーク（例えば、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）ネットワーク、高速アップリンクパケットアクセス（ＨＳＵＰＡ）ネットワーク、等）；及びＢｌｕｅｔｏｏｔｈネットワーク（パーソナルエリアネットワーク（ＰＡＮ）として知られている）を経て通信することができる。将来の移動装置は、幾つか挙げると、ＷｉＭＡＸ、インターナショナルモバイルテレコミュニケーション（ＩＭＴ）進歩型、及び長期進化（ＬＴＥ）進歩型、のような付加的な通信チャンネルを経て通信することができるであろう。
【００８０】
動作に際して、現在移動装置は、１組の利用可能なチャンネルの中から１つの一次通知ンチャンネルを選択する。例えば、移動装置は、Ｗｉ−Ｆｉが利用できる場合にはそれを選択し、そしてＷｉ−Ｆｉが利用できない場合にはセルラーデータ接続（例えば、ＵＭＴＳ接続）を選択するように構成されることが多い。
【００８１】
本発明の１つの実施形態では、移動装置のグループは、最初、標準的ＩＣＥ接続データ交換を使用し及び／又は上述した接続データ交換技術を使用して、一次ピア・ツー・ピア（Ｐ２Ｐ）通信チャンネルを確立する。次いで、移動装置は、一次チャンネルを経て接続データを交換して、いずれかの一次チャンネルがフェイルした場合にバックアップチャンネルとして使用される１つ以上の二次通信チャンネルを確立する。１つの実施形態では、二次通信チャンネルは、これらのチャンネルを経て「ハートビート」パケットを周期的に送信することによりＮＡＴファイアウオールを通してオープンに維持される。
【００８２】
ここで使用される通信「チャンネル」とは、２つの移動装置間の完全ネットワーク経路を指し、そして通知ン「リンク」とは、通信経路に使用される１つの特定の接続を指す。例えば、装置ＡがＷｉ−Ｆｉ接続を使用してインターネットに接続され、そして装置Ｂが３Ｇ接続を使用してインターネットに接続される場合には、装置Ａと装置Ｂとの間の「チャンネル」がＷｉ−Ｆｉリンク及び３Ｇリンクの両方によって定義され、装置ＡはＷｉ−Ｆｉ通信「リンク」を有し、そして装置Ｂは、３Ｇ通信「リンク」を有する。従って、装置ＡがＷｉ−Ｆｉリンクから３Ｇリンクへスイッチする場合には、装置Ｂの３Ｇリンクが同じままであるにも関わらず、装置Ａと装置Ｂとの間の「チャンネル」が変更される。
【００８３】
移動装置が一次及び二次通信チャンネルを確立する特定例を、図６を参照して以下に述べる。しかしながら、本発明の基礎的な原理は、図６に示す通信リンク及び通信チャンネルの特定のセットに限定されないことに注意されたい。
【００８４】
図６において、移動装置Ａ  ６０１は、ＮＡＴ装置６１１との通信リンク６０５を経て及びＮＡＴ装置６１２との通信リンク６０６を経てネットワーク６１０（例えば、インターネット）に接続することができる。同様に、装置Ｃ  ６０３は、ＮＡＴ装置６１３との通信リンク６０９を経て及びＮＡＴ装置６１３との通信リンク６１０を経てネットワーク６１０に接続することができる。例えば、これに限定されないが、通信リンク６０５及び６０９は、３Ｇ通信リンクであり、そして通信リンク６０６及び６１０は、Ｗｉ−Ｆｉ通信リンクである。
【００８５】
従って、この例では、移動装置Ａと移動装置Ｂとの間に確立される４つの異なる通信チャンネル：即ち、リンク６０５及び６０９を使用する第１チャンネル；リンク６０５及び６１０を使用する第２チャンネル；リンク６０６及び６０９を使用する第３チャンネル；並びにリンク６０６及び６１０を使用する第３チャンネル；がある。１つの実施形態において、移動装置Ａ及びＢは、これらチャンネルの１つをプライオリティ決めスキームに基づいて一次通信チャンネルとして選択し、そして残りの３つのチャンネルをバックアップ通信チャンネルとして選択する。例えば、１つのプライオリティ決めスキームは、最大帯域巾をもつチャンネルを一次チャンネルとして選択し、そして残りのチャンネルを二次チャンネルとして使用する。２つ以上のチャンネルが同等の帯域巾を有する場合には、プライオリティ決めスキームは、最も費用の低いチャンネルを選択することを含む（ユーザが１つ以上のチャンネルを使用するために料金を支払うと仮定すれば）。或いは又、プライオリティ決めスキームは、最も費用の低いチャンネルを一次チャンネルとして選択し、そして各チャンネルのコストが同じである場合には、最大帯域巾チャンネルを選択する。本発明の基礎的な原理に適合しながら種々の異なるプライオリティ決めスキームを実施することができる。
【００８６】
移動装置Ａ  ６０１及びＣ  ６０３は、上述した技術を使用して、一次通信チャンネルを確立する（例えば、ＣＤＸサービス１１０を経て通信データを交換することにより）。或いは又、移動装置６０１、６０３は、標準的インターネット接続確立（ＩＣＥ）トランザクションを実施して、接続データを交換する。一次チャンネルをどのように確立するかに関わらず、それが確立されると、移動装置Ａ  ６０１及びＣ  ６０３は、一次通信チャンネルを経て二次通信チャンネルのための接続データを交換する。例えば、図６の一次通信チャンネルが通信リンク６０６及び通信リンク６０９を含む場合には、この接続は、それが確立されると、通信リンク６０５及び６０９を含む二次通信チャンネルのための接続データを交換するのに使用される。この例では、一次通信チャンネルを経て交換される接続データは、各移動装置のパブリック及びプライベートＩＰアドレス／ポートを含めて、ＮＡＴ６１１及びＮＡＴ６１３のためのＮＡＴ横断データ及びＮＡＴ形式データを含む。
【００８７】
二次通信チャンネルが確立されると、それらは、ハートビートパケットを使用してオープンに維持される。例えば、装置Ａは、小さな「ハートビート」パケットを装置Ｃへ周期的に送信し、及び／又は装置Ａは、小さな「ハートビート」パケットを装置Ｃへ周期的に送信して、二次チャンネルに使用されるＮＡＴポートがオープンのままとなる（ＮＡＴがインアクティビティのためにポートをしばしばクローズする）ことを保証する。ハートビートパケットは、ペイロードをもたないＵＤＰパケットであるが、本発明の基礎的な原理は、特定のパケットフォーマットに限定されない。ハートビートパケットは、それらのペイロードヘッダに自己識別形式フィールドをもつＵＤＰパケットであり、そしてこれに限定されないがチャンネルのタイム・ツー・リブ(time-to-live)値を含む任意の付加的にフォーマットされた情報を含む。
【００８８】
図７に示すように、各移動装置６０１は、一次及び二次通信チャンネルのリストを含むデータ構造体７１０（例えば、テーブル、テキストファイル、データベース、等）を記憶して維持する。各通信チャンネルに対して個別のエントリが設けられ、これは、そのチャンネルを使用するのに必要な接続データ（例えば、プライベート／パブリックＩＰアドレス、ＮＡＴ形式、等）、及びそのチャンネルの現在状態（例えば、一次、二次１、二次２、等）を含む。
【００８９】
１つの実施形態では、通信リンク６０５及び通信リンク６０６を経て通信するために、各々、通信インターフェイス７０１及び７０２が使用される。特定の通信インターフェイス／リンクがフェイルするか又は指定のスレッシュホールドより下がったときを検出するために移動装置６０１において欠陥検出モジュール７０５を実行することができる。それに応答して、リンクマネージメントモジュール７０６が一次／二次接続データ７１０を読み取り、一次チャンネルに対して次に高いプライオリティをもつ二次チャンネルを昇格させる。二次チャンネルのプライオリティ決めは、一次チャンネルについて上述したものと同じ原理を使用して（例えば、帯域巾、コスト、信頼性、等に基づき）達成される。二次チャンネルが選択されると、リンクマネージメントモジュール７０６は、他の移動装置のリンクマネージメントモジュールへリンク欠陥指示を送信し、それらの装置に、二次通信チャンネルを一次通信チャンネルに昇格させるよう命令する。それらの装置は、次いで、その選択された一次チャンネルに関連した接続データの使用を開始する。
【００９０】
１つの実施形態において、二次通信チャンネルの１つへスイッチを強制するのに、一次通信チャンネルの完全な「欠陥」は要求されない。例えば、１つの実施形態において、一次通信チャンネルが充分に質低下した場合には（例えば、特定の帯域巾、ビットレート、又は信頼性スレッシュホールドより低く）、二次チャンネルへの切り換えは、ここに述べるように実施される。１つの実施形態において、二次チャンネルへのスイッチは、二次チャンネルが現在の一次チャンネルより優れた性能（例えば、帯域巾、ビットレート、又は信頼性）をサポートできる場合しか行われない。
【００９１】
図８ａは、図６に示す同じネットワーク構成を示すが、移動装置Ｂ  ６０２が追加されて、ネットワーク６１０に直結されると共に、プライベートネットワーク接続６２０を経て装置Ｃ  ６０３に接続されている。プライベートネットワーク６２０は、例えば、装置Ｂ  ６０２と装置Ｃ  ６０３との間のＢｌｕｅｔｏｏｔｈ  ＰＡＮ接続である。この例から、一次チャンネルから二次チャンネルへのスイッチングは、ネットワークトポロジーを劇的に変更することが分かる。例えば、図８ｂに示すように、移動装置の一次チャンネル８０１が通信リンク６０９を含み（装置Ａ、Ｂ及びＣ間に直接的な接続を生じる）そして二次チャンネルがプライベートネットワーク６２０を含む場合には、ネットワークトポロジーは、図８ｃに示すように変化する。というのは、装置Ａ及び装置Ｃがプライベートネットワークを使用して通信する唯一の方法が装置Ｂを通ることだからである。これは、３つの装置だけの簡単な例であるが、著しく多数の装置が使用されて、一次と二次との通信チャンネル間をスイッチングするときには、種々の異なるネットワークトポロジー構成が生じる。
【００９２】
二次チャンネルを確立し及び維持する方法の一実施形態が図８に示されている。１つの実施形態では、この方法は、各移動装置のリンクマネージメントモジュール７０６により実行される。しかしながら、この方法は、特定の装置構成に限定されない。
【００９３】
９０１において、一次Ｐ２Ｐ通信チャンネルが選択される。上述したように、一次チャンネルは、所定のプライオリティ決めスキームに基づいて選択される。例えば、ある通信チャンネル形式は、他の通信チャンネル形式の前にプライオリティ決めされる。又、チャンネルは、帯域巾、使用コスト、及び／又は信頼性のような変数に基づいてプライオリティ決めされてもよい。
【００９４】
９０２において、バックアップＰ２Ｐ通信チャンネルが確立される。１つの実施形態において、これは、一次通信チャンネルを経て全ての移動装置間に接続データを共有することにより達成される。９０３において、バックアップチャンネルが維持される。１つの実施形態において、これは、二次通信チャンネルを経て周期的にデータを送信することを含む（例えば、周期的なハートビートパケットの形態で）。
【００９５】
９０４において、一次Ｐ２Ｐチャンネルがフェイルした場合には（例えば、特定の移動装置の通信リンクがダウンするか、又は移動装置が通信リンクの範囲から出たために）、９０５において、移動装置は、プライオリティが最も高いバックアップチャンネルを一次チャンネルへ昇格させる。１つの実施形態において、これは、リンクがフェイルした移動装置が、そのリンクフェイルの通知を、二次チャンネルを経て他の装置へ送信することを含む。最後に、９０６において、バックアップチャンネルが一次チャンネルとなり、そしてプロセスは９０２へ戻る（付加的なバックアップチャンネルが発見されて、プライオリティ決めスキームに追加される）。
【００９６】
ピア・ツー・ピア(Ｐ２Ｐ)通信チャンネルを確立するインビテーションサービスのための装置及び方法
図１０に示すように、ＣＤＸサービス１１０、マッチメーカーサービス１１１及びインビテーションサービス１１２（その幾つかの実施形態は、上述した）に加えて、本発明の１つの実施形態は、登録／ディレクトリサービス１０５２、プッシュ通知サービス１０５０、及びリレーサービス１０５１を含む。上述したように、１つの実施形態では、インビテーションサービス１１２及び／又はマッチメーカーサービス１１１は、登録された移動装置を識別するために登録／ディレクトリサービス１０５２を、そして移動装置へデータをプッシュするためにプッシュ通知サービス１０５０を使用する。１つの実施形態において、移動装置は、それがネットワークにおいてアクチベートされると、「プッシュトークン」（プッシュ通知アプリケーションでは「通知サービスアカウント識別子」とも称される）を、そのプッシュトークンをパスワード保護のユーザＩＤ又は電話番号に関連付けることにより、登録／ディレクトリサービス１０５２により維持されるデータベースに登録する。プッシュトークンが登録ディレクトリにおいて識別された場合には（例えば、ユーザＩＤで問合せを遂行することにより）、プッシュ通知サービス１０５０は、そのプッシュトークンを使用して、移動装置へプッシュ通知を送信することができる。１つの実施形態において、プッシュ通知サービスは、本出願の譲受人により設計されて、例えば、前記プッシュ通知アプリケーションに説明されたアップルプッシュ通知サービス（ＡＰＮＳ）である。
【００９７】
図１１は、プッシュ通知サービス１０５０を使用して２つの移動装置間に直接的なＰ２Ｐ接続を確立する本発明の実施形態を示し、そして図１２は、リレーサービス１０５１を通してＰ２Ｐ接続を確立するのに使用される実施形態を示す。以下に述べるように、リレーサービス１０５１を使用してＰ２Ｐ接続を確立すべきかどうかの判断は、移動装置間に直接Ｐ２Ｐ接続を確立する実現性に基づく（例えば、ＮＡＴ適合性の問題に基づく）。
【００９８】
図１１を参照すれば、１１０１において、移動装置Ａ  １２０は、移動装置Ｂ  １２１をＰ２Ｐ通信セッション（例えば、共同ビデオゲーム、Ｐ２Ｐビデオチャット、等）へ招待するためのインビテーションを移動装置Ｂへ送信する。１つの実施形態において、インビテーションは、特定オンラインアプリケーションのコンテキスト内で移動装置Ｂ  １２１（及び／又は移動装置Ｂのユーザ）を識別するユーザＩＤコードを含む。例えば、ユーザＩＤコードは、特定のマルチプレーヤＰ２ＰゲームのためのプレーヤＩＤであり、例えば、ユニバーサルユニークアイデンティファイア（ＵＵＩＤ）の形態をとる。或いは又、ある実施形態では、ＩＤコードは、移動装置Ｂ  １２１の電話番号でもよい。ゲームＩＤコードは、移動装置Ａが移動装置Ｂの参加を招待するところのマルチプレーヤゲームを識別するのに使用される。バケットＩＤは、そのゲームの構成（マッチメーカーサービスに関してここに述べる）を識別するのに使用される。
【００９９】
又、インビテーション１１０１は、移動装置Ａ  １２０を識別するＩＤコードと、移動装置Ａに関連したＮＡＴ横断／接続データ（例えば、移動装置Ａのパブリック／プライベートＩＰアドレス及びポート、並びに装置ＡのＮＡＴ装置のＮＡＴ形式）も含む。ＮＡＴ横断／接続データ又はＮＡＴ形式データは、インビテーション要求１１０１の前に移動装置Ａにより既に決定されている（例えば、図２ａ−ｃを参照して上述したもののようなＮＡＴ横断、ＮＡＴ形式及び接続データトランザクションを経て）。既に述べたように、インビテーション要求１１０１は、ＨＴＴＰＳ要求の形態をとる。更に、付加的なセキュリティとして、インビテーション要求１１０１は、予め指定された証明当局により署名されたクライアント証明書を含む。
【０１００】
移動装置Ｂを識別するのに使用されるＩＤコードの特定形式に関わらず、インビテーションサービス１１２によりＩＤコードが受け取られ、そして１１０２において、インビテーションサービス１１２は、ディレクトリサービス１０５２（図１１には示さず）のルックアップを遂行して、移動装置Ｂへ通知をプッシュするのに使用されるプッシュトークン（プッシュ・トークン・Ｂ）のような通知サービスアカウント識別子を識別する。１つの実施形態では、ルックアップ動作は、インビテーションを許すべきかどうか決定するために多数のチェックを遂行することができる。先ず、移動装置Ａの識別コード（ＩＤ−Ａ）及び装置Ａのプッシュトークン（プッシュ・トークン・Ａ）がディレクトリサービスデータベース内の登録された関連付けであることを確認する。又、ルックアップ動作１１０２は、移動装置Ａのユーザが移動装置Ｂのユーザを招待することが許されることも確認する（例えば、移動装置Ｂのユーザは、Ｂの友人として登録された他のユーザしかユーザＢを招待できないことを指定するか、又は招待が許されないことを指定する）１つの実施形態において、これらチェックのいずれが不合格である場合には、インビテーションがキャンセルされ、インビテーションサービス１１２は、移動装置Ａにエラーを返送する。
【０１０１】
この実施形態では「プッシュトークン」について述べたが、本発明の基礎的な原理は、「プッシュトークン」の使用、又は移動装置を認証してそこに通知をプッシュする他の特定のデータ構造の使用に限定されないことに注意されない。
【０１０２】
１つの実施形態において、プッシュトークンが識別された後に、インビテーションサービス１１２は、更に別の全てのトランザクションにおいてインビテーションセッションに指定されてそのセッションを識別するのに使用される安全な一度限りの「セッショントークン」を発生する。次いで、セッショントークンのコピーが移動装置Ａ  １２０に返送されると共に、インビテーション要求と共に移動装置Ｂに送信される。ある実施形態では、セッショントークンが上述したチケットデータ構造体と一緒に使用され、そして別の実施形態では、セッショントークンだけが使用される。
【０１０３】
１１０３において、インビテーションサービス１１２は、プッシュ通知サービス１０５０にプッシュ要求を送信する。ある実施形態では、プッシュ要求は、移動装置ＡのＮＡＴ横断データ、装置ＡのＩＤコード、プッシュ・トークン・Ａ、装置ＢのＩＤコード、及びプッシュ・トークン・Ｂを含む。ある実施形態では、この情報は、「チケット」データ構造体内にパッケージされ、そして上述したように暗号化される。別の実施形態では、このデータは、単に、インビテーションセッションＩＤと共に送信される。
【０１０４】
この例では、移動装置Ｂ  １２１がプッシュ通知サービス１０５０に登録されるので、プッシュ通知サービス１０５０は、１１０４において、移動装置Ｂ  １２１を探索して、そこにインビテーション要求をプッシュすることができる。プッシュされるインビテーション１１０４は、セッショントークン、移動装置ＡのＮＡＴ横断データ／接続データ、及び移動装置ＢのＩＤコードを含む。インビテーション要求に応答して、移動装置Ｂは、上述したＮＡＴ横断サービス又はＣＤＸサービス１１０へコールを発することによりそのネットワーク情報（例えば、ＮＡＴ横断／接続データ、ＮＡＴ形式、等）を決定することができる。
【０１０５】
１１０５において、移動装置Ｂは、インビテーションを受け容れる。この受け容れ１１０５は、インビテーションサービス１１２へのＨＴＴＰＳコールの形態をとり、予め指定された証明当局により署名されたクライアント証明書を含む（インビテーション要求について上述した）。１つの実施形態では、受け容れ１１０５は、移動装置Ａ及びＢのＩＤコードと、移動装置Ａ及びＢのためのＮＡＴ横断／接続データ及び／又はＮＡＴ形式とを含む。又、受け容れ１１０５は、移動装置Ａ及びＢのプッシュトークン、及び／又はセッショントークンも含む。１つの実施形態では、受け容れ１１０５は、以前に失敗した直接接続の試みからの再試みであるかどうかの指示も含む。しかしながら、別の実施形態では、受け容れ１１０５は、受け容れ１１０５は、再試み指示を含まない。むしろ、失敗したＰ２Ｐ接続試みを検出すると、２つの移動装置の一方が特殊な「リレー」インビテーションをインビテーションサービス１１２へ送信する。それに応答して、そのサービスは、図１２を参照して以下に述べる一連のリレートランザクション（１２０１でスタート）を直接開始する。
【０１０６】
１１０６において、インビテーションサービス１１２は、移動装置ＡとＢとの間の直接Ｐ２Ｐ接続が実現可能であるかどうか決定するために適合性チェックを遂行する。例えば、１つの実施形態では、移動装置Ｂから受信した受け容れ１１０５が、それが以前に失敗した直接接続試みからの再試み（又は指定数の以前に失敗した直接接続試み）であることを指示する場合には、インビテーションサービスは、直接Ｐ２Ｐ接続が実現不能であると結論する。インビテーションサービス１１２は、移動装置Ａ及びＢのＮＡＴ形式データを比較して、移動装置Ａ及びＢのＮＡＴ装置が直接Ｐ２Ｐ接続をサポートするかどうか決定する。ＮＡＴ形式のある組み合わせは、Ｐ２Ｐ接続を確立するのに不適合であることが知られている。例えば、完全コーンＮＡＴが、クローズ／ファイアウオール付きＮＡＴ以外のＮＡＴ形式と共に使用されて、直接Ｐ２Ｐ接続を確立する。対照的に、対称的なＮＡＴのみが完全コーンＮＡＴと共に使用されて、直接Ｐ２Ｐ接続を確立してもよい。本発明の１つの実施形態において種々のＮＡＴ形式を組み合わせる実現性は、列がある移動装置（例えば、移動装置Ａ）のＮＡＴ形式を表わしそして行が他の移動装置（例えば、移動装置Ｂ）のＮＡＴ形式を表わす図１４に示すＮＡＴ適合性テーブル１４００に示されている。セルにおける「１．０」は、関連する行及び列におけるＮＡＴ形式が適合であることを示し、そして「０．０」は、ＮＡＴ形式が不適合であることを示す。
【０１０７】
１つの実施形態において、直接Ｐ２Ｐ接続が実現不能であることを適合性チェック１１０６が決定する場合には、インビテーションサービス１１２は、図１２を参照して以下に述べるように、リレールックアップ要求１２０１を送信することができる。しかしながら、直接Ｐ２Ｐ接続が実現可能であることを適合性チェック１１０６が決定する場合には、インビテーションサービス１１２は、移動装置Ａのインビテーションについての移動装置Ｂの受け容れを含むプッシュ要求１１０７をプッシュ通知サービス１０５０へ送信する。プッシュ要求１１０７、及びプッシュ通知サービス１０５０から移動装置Ａへのその後のプッシュ通信１１０８は、セッショントークン、移動装置Ａ及びＢ両方のプッシュトークン、ＩＤコード、及び／又はＮＡＴ横断／接続データを含む。１つの実施形態では、この情報は、上述した「チケット」データ構造体内にパックされ（例えば、図２ａ−ｃ及び関連テキストを参照）そして独特のキーを使用して暗号化される。或いは又、この情報は、独特のインビテーションセッションＩＤと共に送信されるだけでもよい。インビテーションサービス１０５０は、直接接続が試みられることを移動装置Ｂに通知してもよい。
【０１０８】
この段階において、移動装置Ａ及びＢは、直接Ｐ２Ｐ接続を確立するに充分な情報を有する。１つの実施形態では、これは、上述したＣＤＸサービス１１０を使用して達成される。例えば、移動装置Ｂは、その接続データをチケットＢに添付し、そして１１０９において、チケットＢを（接続データと共に）ＣＤＸサービスへ送信する。このトランザクションの直前に、移動装置Ｂは、図２Ｂに示すトランザクション２３５のようなトランザクションを実施して、その接続データが現在のものであることを保証する。次いで、ＣＤＸサービス１１０は、チケットを認証し（例えば、上述した独特のセッションキーを使用して）、移動装置Ｂの接続データを抽出し、そして１１１０において、接続データを移動装置Ａへ転送する。同様に、移動装置Ａは、その接続データをチケットＡに添付し、そして１１１において、チケットＡを（接続データと共に）ＣＤＸサービス１１０へ送信する。このトランザクションの直前に、移動装置Ａは、図２ｂに示すトランザクション２３２のようなトランザクションを実施して、その接続データが現在のものであることを保証する。次いで、ＣＤＸサービス１１０は、チケットを認証し（例えば、上述した独特のセッションキーを使用して）、移動装置Ａの接続データを抽出し、そして１１１２において、その接続データを移動装置Ｂへ転送する。最後に、１１１３において、移動装置Ａ及びＢは、交換した接続データを使用して直接Ｐ２Ｐ接続に入る。
【０１０９】
図１２を参照すると、直接Ｐ２Ｐ接続が実現不能であることを適合性チェック１１０６が決定した場合には、インビテーションサービス１１２は、リレールックアップ要求１２０１をリレーサービス１０５１へ送信して、各移動装置により使用されるべきリレーホストを決定する。要求１２０１は、移動装置Ａ及びＢのネットワーク情報（例えば、ＮＡＴ横断／接続データ及び／又はＮＡＴ形式データ）を含み、これは、両移動装置に対する適切なリレーホストを選択するためにリレーサービス１０５１により使用される。図１３に示すように、リレーサービス１０５１の１つの実施形態は、複数のリレーホスト１３０２−１３０３と、各リレーホストに関するネットワーク情報を含むリレーホストデータベース１３０１とを含む。インビテーションサービス１１２は、リレールックアップ要求１２０１をリレールックアップサービス１３００へ送信し、これは、移動装置Ａ及びＢのネットワーク情報を使用してリレーホストデータベース１３０１に問合せする。データベースの結果を受け取ると、リレールックアップサービス１３００は、選択されたリレーホスト１３０２−１３０３を識別する応答１２０２を与える。
【０１１０】
１つの実施形態において、リレールックアップ応答１２０２は、リレーサービスにより発生されるリレートークンと、リレー接続のために移動装置Ａ及びＢによって使用されるリレーホスト１３０２−１３０３のネットワークアドレス（ＩＰアドレス／ポート）とを含む。１つの実施形態では、リレートークンは、リレーセッションに関連付けられ、そしてリレーサービス１０５１への接続の際に移動装置Ａ及びＢを認証するためにリレーホスト１３０２−１３０３により使用される。トークンは、例えば、独特のＩＤリレーセッションＩＤコード、デジタル証明書、及び／又はリレーセッションに関連した独特の暗号キーを含む種々の形態をとる。
【０１１１】
１２０３において、インビテーションサービスは、リレー接続を行うとの指示を含むリレー応答１２０３を移動装置Ｂ  １２１へ送信する。１つの実施形態では、リレー応答１２０３は、リレートークンと、リレーホストＢ  １３０３のネットワーク情報とを含む。１つの実施形態では、応答１２０３は、移動装置Ｂの受け容れ１１０５に応答して送信されるので、（プッシュ通知サービス１０５０をバイパスして）移動装置Ｂへ直接送信される。
【０１１２】
インビテーションサービス１１２は、リレーホストＢ  １３０３のリレートークン及びネットワーク情報を含むリレー応答１２０４を移動装置Ａへ送信する。この場合には、応答１２０４は、トランザクション１２０５において、プッシュ通知サービス１０５０を経て移動装置Ａへプッシュされる。
【０１１３】
１２０６において、移動装置Ａ  １２０は、リレーホストＡ  １３０２のネットワーク情報を使用して、リレーサービス１０５１との接続を確立する。同様に、１２０７において、移動装置Ｂ  １２１は、リレーホストＢ  １３０３のネットワーク情報を使用して、リレーサービス１０５１との接続を確立する。これらトランザクションの各々において、移動装置Ａ及びＢのＮＡＴファイアウオールに新たな穴が開けられ、移動装置Ａ及びＢのＮＡＴ横断／接続データがリレーサービス１０５１により決定されて、移動装置Ａ及びＢへ各々返送される（例えば、装置のパブリックＩＰ／ポートを決定することにより）。１つの実施形態では、リレーサービス１０５１と、移動装置Ａ及びＢは、当業者に明らかなように、ＮＡＴ又はファイアウオール後方の要素がＴＣＰ又はＵＤＰ接続を経て到来するデータを受信するのを許す「リレーＮＡＴを使用する横断(Traversal Using Relay NAT)（ＴＵＲＮ）」プロトコルを実施する。
【０１１４】
１２０８において、移動装置Ａは、インビテーションサービス１１２へリレー更新を送信し、これは、１２０９において、プッシュ通知サービスへ転送され、そして１２１０において、移動装置Ｂへプッシュされる。同様に、１２１１において、移動装置Ｂも、インビテーションサービス１１２へリレー更新を送信し、これは、１２１２において、プッシュ通知サービスへ転送され、そして１２１３において、移動装置Ａへプッシュされる。移動装置Ａによって送信されるリレー更新は、セッショントークン、各装置のＩＤコード、及び１２０６及び１２０７により決定されたＮＡＴ横断／接続データを含む（即ち、移動装置Ａは、そのＮＡＴ横断／接続データを移動装置Ｂに送信し、そしてその逆も行われる）。１つの実施形態では、各移動装置のＮＡＴ情報が変化するので、リレー更新動作が遂行される。
【０１１５】
最後に、１２１４及び１２１５において、移動装置Ａ及びＢは、各々、リレーサービス１０５１を通してＰ２Ｐ接続を確立する。１つの実施形態において、移動装置Ａが移動装置ＢのＮＡＴ横断／接続データをリレーサービス１０５１へ送信し、及びその逆が行われたときに、リレー接続を確立して、リレーサービスで各ピアのリレーホスト１３０２−１３０３への正しい経路を決定できるようにする。
【０１１６】
上述した技術を使用して、インビテーションサービス１１２は、膨大な数の移動装置を伴う大規模システムでも、本来拡張可能で且つ弾力性のあるステートレスサービスとして実施される。例えば、プッシュ通知サービス１０５０は、本来、コンテンツを探索して、登録された移動装置へプッシュすることができるので、各装置の現在位置を追跡するのにインビテーションサービスは必要とされない。更に、装置は、全セッション状態データを各要求及び応答と共に送信するので、インビテーションサービスは、接続ごとの状態情報を維持する必要がなく、インビテーションサービスの記憶及び処理要件が緩和される。そのような実施は、大規模システムでは特に有用である。
【０１１７】
オンラインセッションに対してユーザを対戦させるシステム及び方法
図１５に示すように、マッチメーカーサービス１１１の１つの実施形態は、対戦要求を受け取って対戦応答を移動装置１２０−１２２へプッシュするためのマッチメーカーディスパッチャー１５０１と；対戦要求を要求テーブル１５０２に記憶し且つ対戦可能なセットデータを対戦可能なセット識別子（ＭＳＴ）テーブル１５０３に記憶するためのデータベース１５１２と；データベース１５１２から対戦要求をフェッチし、対戦を組む動作を行い、そして対戦を組んだ結果をデータベース１５１２に記憶するための１つ以上のマッチメーカー１５１０と；を備えている。しかしながら、本発明の基礎的な原理は、図１５に示す特定のアーキテクチャーに限定されないことに注意されたい。
【０１１８】
１つの実施形態において、マッチメーカーディスパッチャー１５０１は、マッチメーカーサービス１１１へのインターフェイスとして働き、移動装置１２０−１２２から要求を受け取り、それらの要求を、データベース１５１２に要求を記憶するためのコマンドへと変換し、データベース１５１２から対戦組み結果を読み取り、そしてそれらの結果を変換して移動装置１２０−１２２へ通信する。
【０１１９】
動作中、新たな対戦要求が到着すると、マッチメーカーディスパッチャー１５０１は、その要求を要求テーブル１５０２のある行内に記憶する。１つの実施形態において、ディスパッチャー１５０１は、各対戦要求に要求ＩＤ（ＲＩＤ）コードを指定し、このコードは、図１５には単に“Ａ”、“Ｂ”及び“Ｃ”と示されている（移動装置Ａ、Ｂ及びＣに各々対応して）。簡単化のために図１５には文字呼称を使用して示されているが、ＲＩＤコードは、データベース内の対戦要求を追跡するのに適したストリングでも、整数でも、又は他の変数形式でもよい。
【０１２０】
各対戦要求には、要求テーブル１５０２に記憶される対戦可能なセット識別子（ＭＳＩ）値が指定される。１つの実施形態では、ＭＳＩは、対戦が要求される特定のアプリケーション、及び／又はそのアプリケーションに使用されるべき構成パラメータを識別する。例えば、１２：４のＭＳＩ値は、識別子１２で特定のマルチプレー他ゲームを識別し、そして識別子４でそのゲームの特定の構成を識別する。より詳細には、１２というＩＤコードは、特定のマルチプレーヤレーシングゲームを識別し、そして４というＩＤコードは、特定のレーシングトラック、スピード、又はそのレーシングゲームのプレーヤ経験レベルを特定する。１つの実施形態において、アプリケーション開発者には、このようにＭＳＩ値を使用してアプリケーション構成パラメータを特定するオプションが与えられる。１つの実施形態では、ＭＳＩを直接特定するのではなく、アプリケーション開発者は、ゲームＩＤ（特定のゲームを識別する）及びバケットＩＤ（特定のゲーム構成を識別する）を特定し、これらの値は、マッチメーカーディスパッチャー１５０１によりＭＳＩ値へマップされる。
【０１２１】
更に、多数の異なる構成パラメータ（例えば、１２：４：１は、１２＝レーシングゲーム、４＝トラック、及び１＝経験レベルを表わす）を特定するために、多数の異なるＭＳＩ値が単一のＭＳＩ内に使用される。以下に詳細に述べるように、１つの実施形態では、対戦を組ませる動作を遂行できる１組の対戦要求を識別するために各ＭＳＩがマッチメーカー１５１０により使用される（例えば、ＭＳＩに基づいて要求がグループ化され、そして各ＭＳＩグループ内で対戦が組まれる。１つの実施形態では、各ＭＳＩは、異なるマシンパーティションを識別するパーティションＩＤを含ませるためにディスパッチャーにより動的に変更／選択される。例えば、特定のＭＳＩが過負荷になると、ディスパッチャーは、ＭＳＩを２つ以上の異なるサーバー及び／又は記憶パーティション間で分割する（例えば、最後の桁が各々パーティション１及び２を識別するとすれば、４：３：１及び４：３：２のような呼称を使用して）。次いで、異なるマッチメーカーが異なるサーバー各々からの異なるＭＳＩ各々からの要求を独立して検索し処理する。
【０１２２】
図１５に示すように、対戦要求データは、要求ごとに要求テーブル１５０２内にも記憶される。要求データは、マッチメークの判断を行わせるのに使用できるデータ、及び／又はネットワークを経て要求を開始する移動装置にアクセスするのに必要なデータを含む。例えば、１つの実施形態では、各要求の対戦要求データは、要求を開始する移動装置に対するＮＡＴ形式データ及び／又はＮＡＴ横断／接続データを含む。装置接続速度（１００ｋｂｐｓ、１Ｍｂｐｓ、等）、接続形式（例えば、３Ｇ、ＥＤＧＥ、Ｅｉ−Ｆｉ、等）、装置の位置（例えば、ジオロケーション技術により決定される）、言語（英語、スペイン語、等）、及び／又はユーザの好みのような、他の形式の要求データも要求テーブル１５０２内に記憶される。要求データは、各移動装置１２０−１２２によって決定されて、各対戦要求と共にマッチメーカーディスパッチャー１５０１へ送信される。例えば、各移動装置は、種々の技術（幾つかを個々に述べる）を使用して、その接続データ、接続形式、装置位置、等を決定する（例えば、ＮＡＴ横断サーバーと通信して、ＮＡＴ横断／接続データを決定し、ＧＰＳを使用して、装置位置を決定し、ＨＴＴＰ情報を読み取って、言語を決定し、等々）。
【０１２３】
図１５に示すように、１つの実施形態では、各アクティブなＭＳＩに、ＭＳＩテーブル１５０３の行が指定される。１つの実施形態において、要求テーブル１５０２に要求を追加するのに加えて、新たな要求が到着したときに、ディスパッチャー１５０１は、ＭＳＩテーブル１５０３をチェックして、その要求に対してＭＳＩが既に存在するかどうか（即ち、同じＭＳＩを有する他の要求が既に受け取られたかどうか）も決定する。一致するＭＳＩが見つからない場合には、ディスパッチャー１５０１は、新たな要求のための新たなエントリをＭＳＩテーブル１５０３に生成する。一致するＭＳＩが見つかった場合には、ディスパッチャーは、上述したように、要求テーブル１５０２に新たな要求を単に追加するだけである。
【０１２４】
要求テーブル１５０２及びＭＳＩテーブル１５０３がマッチメーカーディスパッチャー１５０１により更新されると、マッチメーカーモジュール１５０１のインスタンス（以下、単に「マッチメーカー１５１０」と称する）は、対戦を組む動作を遂行するためにデータをフェッチする。複数のマッチメーカーインスタンスを同時に実行して対戦を組む要求を遂行することができ、又、単一のマッチメーカー１５１０が複数の異なるＭＳＩグループにおいて対戦を組む複数の動作を同時に処理することができる。
【０１２５】
１つの実施形態において、マッチメーカー１５１０が利用可能になると（例えば、ＭＳＩグループの対戦を組む動作が完了した後、又は初期化された後に）、ＭＳＩテーブルに問合せをして、処理すべき新たなＭＳＩを識別する。図１５において、ＭＳＩ  ３：１の場合のマッチメーカーＩＤフィールドの「Ｎ／Ａ」値は、そのＭＳＩ値を処理する責任がマッチメーカーにまだ指定されていないことを指示する。１つの実施形態では、各ＭＳＩエントリがタイムスタンプされ、そしてマッチメーカー１５１０が、最も古いタイムスタンプをもつＭＳＩを選択する。
【０１２６】
１つの実施形態では、マッチメーカー１５１０は、特定ＭＳＩに対する責任を引き受けると、ＭＳＩテーブル１５０３におけるそのマッチメーカーＩＤコードを更新し、そしてそのＭＳＩに対するリース期間（例えば、５秒）を特定する。１つの実施形態において、マッチメーカー１５１０は、そのＭＳＩについての対戦を処理するときにリース値を更新し続ける。リース値は、失敗したマッチメーカー１５１０に指定されたＭＳＩを識別するのに使用される。例えば、リース値が満了になった場合には、ＭＳＩがマッチメーカーに既に指定されたことをＭＳＩテーブル１５０３が指示するにも関わらず、そのＭＳＩが新たなマッチメーカーにより請求される。
【０１２７】
マッチメーカー１５１０は、ＭＳＩに対する責任を引き受けると、そのＭＳＩに関連した要求をメモリに読み込むために要求テーブル１５０２に問合せすることができる。次いで、マッチメーカー１５１０は、対戦を組む動作を遂行して、１組の対戦組み基準（例えば、以下に述べる）に基づいてユーザ及び移動装置の対戦を組むことができる。マッチメーカー１５１０は、移動装置の対戦が組まれたときを指示するために要求テーブル１５１２を更新することができる。例えば、マッチメーカーは、要求テーブル１５１２のＭＳＩ列からＭＳＩ値を除去し、そして所定値を入力して、対戦組みが完了したことを指示することができる。更に、マッチメーカー１５１０は、その参加者が対戦する他の参加者を識別するために各参加者の「要求データ」フィールドを更新する（例えば、他の参加者と通信するのに必要なＮＡＴ横断／接続データを書き込むことにより）。
【０１２８】
ディスパッチャー１５０１は、完了した対戦組みを識別するために要求テーブル１５０２に周期的に問合せする。完了した対戦組みを検出するのに応答して、ディスパッチャー１５０１は、その対戦に含まれる移動装置へプッシュ通知を送信する（例えば、ここ及び同時係争中の出願に述べたプッシュ通知技術を使用して）。１つの実施形態では、プッシュ通知は、上述した「チケット」データ構造体を含む。次いで、移動装置は、各チケットを使用して、上述したＣＤＸサーバー１１０を経て接続データを交換する。
【０１２９】
プッシュ通知を使用するのに加えて、１つの実施形態では、移動装置１２０−１２２がディスパッチャー１５０１に周期的に問合せて、対戦が組まれたかどうか決定する。移動装置に対してプッシュ通知がそれを行わない場合には、周期的な問合せが有用である。しかしながら、プッシュアーキテクチャーが使用される場合には、周期的な問合せが比較的低いレートにセットされ、マッチメーカーサービスにおける負荷を減少する。
【０１３０】
図１６は、マッチメーカーサービス１１１により２つの移動装置Ａ及びＢの対戦を組む方法の規範的実施形態を示す。図１７ａ−ｄは、方法の進行と共に生じる要求テーブル１５０２及びＭＳＩテーブル１５０３への規範的な更新を示す。
【０１３１】
１６０１において、移動装置Ａから対戦要求が受け取られる。１６０２において、図１７ａに示したように、移動装置Ａの要求が要求テーブルに入力され、そして新たなＭＳＩエントリ（ＭＳＩ  １：１）がＭＳＩテーブルに入力される（それがまだ存在しない場合には）。１６０３において、移動装置Ｂから対戦要求が受け取られ、そして１６０４において、移動装置Ｂの対戦要求は、図１７ｂに示すように、要求テーブルにも入力される。
【０１３２】
１６０５において、特定のマッチメーカーインスタンス（マッチメーカー＃Ｎ）は、ＭＳＩテーブルをチェックし、そして別のマッチメーカーインスタンスによってＭＳＩ  １：１が請求されなかったことを検出する。或いは又、マッチメーカーは、ＭＳＩにおいて既に機能しているマッチメーカーが失敗したことを示すリース満了のＭＳＩテーブルエントリを検出してもよい。１つの実施形態では、リース満了のＭＳＩエントリは、（マッチメーカーがまだ指定されていない）新たなＭＳＩエントリより高いプライオリティが与えられる。更に、１つの実施形態において、比較的古いＭＳＩエントリには、比較的新しいＭＳＩエントリより高いプライオリティが与えられる。マッチメーカーがＭＳＩをどのように選択するかに関わらず、それを行うときには、図１７ｃに示すように、その識別子を付加し、そしてＭＳＩエントリの新たなリース値をセットする（例えば、図示された例では、５秒のリース値を使用する）。次いで、マッチメーカーは、要求テーブルに問合せし、そしてそのＭＳＩをもつ要求テーブルエントリをメモリに読み込んで、それらを処理できるようにする。
【０１３３】
１６０６において、マッチメーカーは、各要求に対して適切な対戦を選択するため一連の対戦組み動作を遂行する。図１８を参照して、対戦組み動作の幾つかの実施形態を以下に説明する。簡単に述べると、１つの実施形態では、「適切」な対戦を決定するために評価される変数は、ＮＡＴ形式（例えば、完全コーン、ポート制約、対称的、等）、接続形式（例えば、ＷｉＦｉ、３Ｇ、Ｅｄｇｅ、等）、ユーザに関連した言語（ＨＴＴＰ要求受け入れ言語ヘッダから導出された）、及び各対戦要求の年齢を含む。一般的に、マッチメーカー１５１０は、適合するＮＡＴ形式（リレーサービスは、時々、以下に述べるように使用されるが）、同じ接続形式、及び同じ言語を有する移動装置を対戦させるように試みる。１つの実施形態では、マッチメーカー１５１０は、対戦要求の年齢に基づいて対戦を組むという要件でのより寛大なものである（即ち、要求が古いほど、対戦を組む制約が適用される寛容度が大きい）。
【０１３４】
図１６に戻ると、１６０７において、対戦を組む決定に続いて、マッチメーカー１５１０は、図１７ｄに示すように、対戦組みが完了したことを指示するために要求テーブルを更新する。又、更新の一部分として、マッチメーカーは、移動装置Ａ及びＢの要求データも更新する。例えば、１つの実施形態において、マッチメーカー１５１０は、移動装置ＢのＮＡＴ横断／接続データを移動装置Ａの要求データ列に書き込み、そして移動装置ＡのＮＡＴ横断／接続データを移動装置Ｂの要求データ列に書き込む。
【０１３５】
１６０８において、ディスパッチャー１５０１は、要求テーブルを読み取って、対戦が組まれた要求エントリを識別する。１つの実施形態では、移動装置Ａ及びＢの対戦が組まれたことを検出すると、（上述したようにマッチメーカーにより更新された）要求データを読み取り、そして移動装置Ａ及びＢのための通知を発生する。ある実施形態では、通知は、上述した「チケット」データ構造体であり、これは、暗号化され、そして各移動装置のＮＡＴ横断／接続データを含む。先に述べたように、ある実施形態では、プッシュ通知サービス１０５０は、移動装置Ａ及びＢへ通知をプッシュするのに使用される。更に、移動装置Ａ及びＢは、対戦が組まれたかどうか決定するためにディスパッチャー１５０１を周期的にポーリングする。この実施形態では、何らかの理由で移動装置の一方に首尾良くプッシュされなかった対戦組みを識別するために、ポーリング技術は、比較的低い速度で行われる。プッシュ通知を使用してポーリング要求負荷をマネージすることで、そうでなければ移動装置からのポーリング要求で負荷が掛けられたマッチメーカーサービス１１１の負荷が著しく減少される。
【０１３６】
同じＭＳＩに対して付加的な対戦要求が未決であることが１６０８において決定されると、マッチメーカーは、そのＭＳＩ内で移動装置／ユーザの対戦を組み続ける。１６１０において、マッチメーカーは、ＭＳＩテーブル１５０３内のリース値をリセットする。１６１１において、付加的な対戦組みが遂行され、そして要求テーブルが更新される（上述したように）。１６１２において、付加的な対戦組みが要求テーブルから読み取られ、そして付加的な移動装置が更新される（上述したように）。ＭＳＩに対して未決となっている付加的な対戦要求がない場合には、１６０９において、ＭＳＩエントリがＭＳＩテーブルから除去される（例えば、ディスパッチャー及び／又はマッチメーカーからの削除コマンドを経て）。
【０１３７】
図１８は、移動装置／ユーザ間で対戦を組むこと（図１６の動作１６０６）を行う方法の一実施形態を示す。１８０１において、全ての現在ＭＳＩ要求（例えば、特定のアプリケーション／バケット組み合わせに対する）がペアで配列される。１８０２において、各ペア間の対戦「フィット性(fit)」が評価され、そして１８０３において、ペアがフィット性降下順に分類される。「フィット性」は、これに限定されないが、ＮＡＴ形式（例えば、完全コーン、ポート制限、対称的、等）、接続形式（例えば、ＷｉＦｉ、３Ｇ、Ｅｄｇｅ、等）、ユーザに関連した言語（ＨＴＴＰ要求受け容れ言語ヘッダから導出される）、及び各対戦要求の年齢を含む複数の異なる変数に基づき評価される。マッチメーク判断のファクタとなる他の変数は、各移動装置の位置（例えば、特定位置にいるユーザを対戦させる試みの場合）、最小及び／又は最大プレーヤ要件（例えば、ユーザ及び／又はアプリケーションにより特定される）、ＭＳＩに含まれるユーザの１人以上が「友人」であるか又はＰ２Ｐ接続に既に入っているか（例えば、「友人」又は以前からの知人を対戦させることが好きな場合）、及びアプリケーションでのユーザの経験（例えば、マルチプレーヤゲームでは、同様の経験をもつユーザを対戦させることが好きな場合、各ユーザのスコアボードのランクがファクタとされる）を含む。
【０１３８】
以下のテーブルＡに示すように、ある実施形態では、「フィット性」の評価は、０．０ないし１．０の数値である。浮動小数点値を使用することで、各基準に対するフィット性を正規化することができる。浮動小数点の演算を避けるために、非正規化の整数値を適当な評価で使用することができ、従って、フィット性の値を比較することができる。
【０１３９】
ある実施形態において、全ての基準は、適合(compatible)（正規化値が１．０）であるか又は非適合（正規化値が１．０未満）であるというバイナリーフィット性を有する。これらは、フィット性が年齢と共に変化する必要な基準であると考えられる（以下に述べる）。位置が変数として追加される場合には、最良のフィット性は、必要な基準に一致することに最も近いプレーヤということになる。
【０１４０】
対戦フィット性 − テーブル A
0005711849.tif 000002
【０１４１】
ある実施形態において、フィット性は、前記基準各々に対する（正規化重み＊年齢ファクタ値）の和に等しい。年齢ファクタ値は、値１でスタートして、所定の期間が経過した後に増加する。次いで、時間の経過と共に増加し続ける（例えば、指定の量だけ周期的に増加する）。１つの実施形態では、上述した年齢ファクタ値を使用するのではなく、以下に述べるように、年齢スレッシュホールドが確立される。接続形式及び言語のようなある変数の正規化／重み値は、ある年齢スレッシュホールドの上に適用される（それらが一致しなくても）。
【０１４２】
ある実施形態において、一対の要求ＡとＢとの間の「フィット性」は、ＡとＢ及びＢとＡのフィット性の平均である。更に、各ファクタに対するＡとＢのフィット性は、Ａの年齢に基づいて調整される（その逆のことも言える）。１つの実施形態において、適合する対戦としては１．０のフィット性が要求される。これは、ＡとＢが、ＮＡＴ適合性、接続形式及び言語が一致する（正規化値が１．０となる）場合しか対戦しないか、或いは前記変数の幾つか（例えば、接続形式及び言語）が実際上無視されるような年齢にＡ及び／又はＢがなる（前記年齢ファクタ値又は以下のスレッシュホールドを使用して）場合しか対戦しないことを意味する。
【０１４３】
年齢 − テーブルB
0005711849.tif 000003
【０１４４】
年齢スレッシュホールドは、前記テーブルＢに示すように確立される。各年齢スレッシュホールドに合格すると（即ち、要求が指定スレッシュホールドより古くなると）、年齢ファクタ値が次第に大きな値（例えば、１．５、２．０、等）へ増加される。それとは別に又はそれに加えて、異なる年齢スレッシュホールドに合格するにつれて、ある変数の重み値が対戦組み判断に追加される（例えば、以下に述べる接続形式及び言語、等）。
【０１４５】
ある実施形態において、テーブルＢに指定された要求年齢限界は、所与のＭＳＩの対戦フローレートに基づいて調整される。フローレートは、指定の単位時間（例えば、１０秒ごと、毎分、等）ごとに遂行される対戦組みの数として指定される。従って、フローレートは、特定のＭＳＩセットがどれほどビジーであるかの指示を与える。１つの実施形態において、セットがビジーであるほど、早期に首尾良く対戦組みする確率を高め且つマッチメーカーの負荷を軽減するために前記スレッシュホールドの各々が前記テーブルＢにおいてより低くセットされる。更に、所与のＭＳＩセットの負荷は、エンドユーザに与えられ（例えば、対戦値に対する推定時間の形態で）、従って、エンドユーザは、特にビジーであるマルチプレーヤゲームに入るよう試みるべきかどうか選択することができる。負荷値は、プッシュ通知の形態でユーザに与えられる。
【０１４６】
テーブルＡからの各変数を参照すれば、１つの実施形態において、図１４に示すＮＡＴ適合性チャート１４００からＮＡＴ適合性が決定される。２つのＮＡＴがこのチャートに基づいて適合であると決定された場合には、ＮＡＴ適合性重みが適用される。
【０１４７】
接続形式 − テーブルＣ
0005711849.tif 000004
【０１４８】
接続形式は、前記テーブルＣに示すようなチャートを使用して評価される。この例では、装置Ａ及びＢの接続形式が同じである（同じ接続形式を満足するセルにおいて１．０で示された）場合には、テーブルＡからの重み付けされた接続形式値がフィット性の決定に含まれる。上述したように、接続形式の決定に影響するように各要求の年齢を使用する。例えば、１つの実施形態では、接続形式のフィット値は、スレッシュホールド１、２及び３の年齢についてテーブルＣのマトリクスを使用して選択される。スレッシュホールド４以上の年齢については、接続形式が１．０にセットされ（非対戦接続形式でも）、そしてそれに対応する重み付けされた接続形式値が適用される。幾つかの実施形態において接続「形式」が使用されるが、接続形式と共に、又はそれに代わって、接続速度が決定されて使用されてもよい。例えば、ある指定範囲内の接続速度は、「適合」と考えられる（例えば、０−１００ｋｂｐｓ；１００−５００ｋｂｐｓ；５００−１０００ｋｂｐｓ；１０００−１５００ｋｂｐｓ、等）。ここに述べる対戦組み変数は、どれも、対戦フィット性の計算に重みとして適用され、そして上述したように年をとる。
【０１４９】
１つの実施形態において、プレーヤの言語は、１つ以上の言語を好みファクタと共に含むＨＴＴＰ要求受け容れ言語ヘッダから導出することができる。ディスパッチャーは、最も好ましい言語を抽出して、その情報をマッチメーカーへ通す。１つの実施形態において、テーブルＡからの重み付けされた言語値は、言語が同じである場合には１．０にセットされ、又は同じでない場合には０．０にセットされる。しかしながら、１つの実施形態では、年齢が指定のスレッシュホールドより上である場合には（例えば、年齢がテーブルＢにおいてスレッシュホールド２以上である場合には）言語が異なっても、重み付けされた言語値が適用される。
【０１５０】
１つの実施形態において、非適合のＮＡＴ形式をもつ２人のユーザ間で対戦が組まれる。例えば、マッチメーカーは、特定のＭＳＩに対して異なる仕方で対戦を組むユーザを有する場合に、指定の期間の後に、上述した技術を使用してリレーサービス１０５１を経て接続をルーティングする。このようにして、リレーサービス１０５１は、プレッシャー値として働き、非適合のＮＡＴ形式であるにも関わらず、年齢対戦を組めるようにする。又、リレーサービス１０５１は、１つ以上の対戦組み試み失敗を検出するのに応答して使用されてもよい。この実施形態では、移動装置により提出される各対戦要求は、１つ以上の不首尾な対戦組みが以前に試みられたかどうかの指示を含む。
【０１５１】
種々の付加的な対戦基準が評価され、そして例えば、これに限定されないが、対戦を要求するいずれかのユーザが友人であるかどうかの指示を含む重み値が対戦フィット性決定の一部分として与えられる。例えば、マッチメーカー１５１０は、対戦フィット性の計算に「友人」重みを適用することにより「友人」であるユーザの要求をマッチングさせるよう試みる。同様に、友人の友人も重み付けされる（例えば、２つ以上の分離度で）。加えて、プレーヤは、特定のゲームに対して他のプレーヤを格付けし、そしてマッチメーカーは、対戦を行うときにそれらの格付けを評価する（ユーザを、比較的高い格付けのプレーヤと対戦させ、且つユーザを、低い格付けのプレーヤとは対戦させない傾向で）。更に、ユーザの接続のレイテンシーが評価され（例えば、単純なピン(ping)動作を使用して）、そしてマッチメーキング判断の一部分として使用される。
【０１５２】
プレーヤを対戦させるのに使用される更に別の変数は、装置の形式である。例えば、マッチメーカー１５１０は、同様の装置形式（例えば、ｉＰａｄ、ｉＰｏｄ、ｉＴｏｕｃｈ、ｉＰｈｏｎｅ、ＲＩＭ  Ｂｌａｃｋｂｅｒｒｙ、等）をもつプレーヤを対戦させるよう試みる。付加的な変数は、ユーザのスコアボードのランキング、現在位置、現在の住居、年齢、性別を含み、そして同様のゲーム収蔵品も、対戦決定について同様に評価される（即ち、多くのケースでは、同様の基準をもつユーザ間の対戦を好む傾向がある）。最終的に、ユーザが適切なＭＳＩ及び同じ年齢の他のユーザのみと対戦するよう保証するために親コントロールがマッチメーカー１５１０により評価される。
【０１５３】
マッチメーカーサービス１１１は、データサービス１００内に管理された１つ以上のデータベースから前記変数をいずれも検索することができる（例えば、図１９を参照して以下に述べるデータベース１９２０を参照）。例えば、ユーザの友人のデータは、友人サービスデータベースからアクセスされ、そして各ユーザの年齢、性別、ゲーム収集品、等の他の情報は、１つ以上の他のデータベースからアクセスされる（例えば、ユーザプロフィール、ゲームデータベース、スコアボードデータベース、等）。１つの実施形態において、ここに述べる全てのサービスには、マッチメーキング判断を行うのに使用される種々の異なる形式のユーザ／装置データの全部を記憶するために同じ中央データベース（又はデータベースのグループ）へのアクセスが与えられる。
【０１５４】
多数の特定例について上述したが、本発明の基礎的な原理は、対戦のフィット性レベルを決定するための特定の１組の変数に限定されないことが明らかであろう。１つの実施形態において、ここに述べるシステム及び方法で実行されるアプリケーションを設計するアプリケーションプログラマーは、異なるＭＳＩ基準を使用して要求をマッチングさせ及び／又はグループ化するそれ自身の１組の基準を特定することができる。
【０１５５】
図１８の方法へ戻ると、各ペア間の対戦「フィット性」が決定されると、１８０３において、それらのペアがフィット性降下順に分類される（例えば、最も高いフィット性を有するペアが、リストのトップとなる）。１８０４において、指定スレッシュホールドより上の最も高いフィット値を有するペアで「対戦セット」がシードされる。前記のように、「スレッシュホールド」値は、テーブルＡに示された１．０の正規化値にセットされる。１８０５において、対戦セットの現在メンバーの１人又は全員とのフィット値が指定スレッシュホールドより高い新たな有望なパートナーが対戦セットに追加される。例えば、対戦セットが最初にＡ及びＢでシードされた場合に、Ａ−Ｃ及び／又はＢ−Ｃのフィット値が指定スレッシュホールドより高ければ、Ｃが対戦セットに追加される。１つの実施形態において、単一の対戦フィットが有望な当事者のスレッシュホールドより高い場合だけ、その当事者が対戦セットに追加される（即ち、必要に応じて、その当事者は、適当な対戦フィット性を有する１人の当事者を通して全ての当事者と通信できるからである）。１人以上の新たな当事者が対戦セットに追加されると、対戦のためのサイズ要件を満足することが１８０６において決定された場合に、対戦組み結果が１８０７において記憶され報告される（例えば、上述したように、要求テーブル１５０２を更新し、通知を送信することにより）。１つの実施形態において、単一の対戦要求は、複数のユーザを表わす（例えば、以下に述べるように、対戦要求がインビテーションシーケンスをたどるとき）。このケースでは、サイズ要件が、各対戦要求により表されるユーザの数に基づいて評価される。サイズ要件が満足されない場合には、プロセスが１８０５へ戻り、新たな当事者が対戦セットに追加される（即ち、そのセットの現在メンバーの１人以上との対戦フィット値が指定スレッシュホールドより高い当事者）。
【０１５６】
１８０８において、対戦が組まれた要求は、マッチメーカー１５１０により処理されている要求の現在セットから除去される。１８０９において、次にシードされた対戦セットが選択され、そしてプロセスは、更なる対戦を組むために１８０４へ戻る。図１８には、順次のプロセスとして示されているが、本発明の基礎的な原理に合致しつつ、複数のシードされた対戦セットを同時に処理できることに注意されたい。
【０１５７】
個別のサービスとして上述したが、マッチメーカーサービス１１１及びインビテーションサービス１１２は、Ｐ２Ｐユーザを接続するように一緒に動作する。例えば、１つの実施形態では、第１のユーザは、１人以上の友人をオンラインセッションに招待し、１人以上の付加的なユーザとの対戦を要求する（例えば、友人「ボブ」を招待し、そしてマルチプレーヤビデオゲームに対して３人の付加的なプレーヤに対戦を組む）。そのようなケースでは、インビテーションサービス１１２は、最初に、第１ユーザと第１ユーザの友人とを接続するための第１ユーザのインビテーション要求を処理する。インビテーション要求の結果（例えば、Ｐ２Ｐ接続成功）がユーザの移動ステーションへ報告される。マッチメーカーサービス１１１は、次いで、付加的なプレーヤを要求する対戦要求を第１ユーザの移動装置から受け取る（又は１つの実施形態では、インビテーションサービスから直接、又は第１ユーザの友人から）。それに応答して、マッチメーカーサービス１１１は、第１ユーザと、第１ユーザの要求と同じＭＳＩを有する１つ以上の他の対戦要求との対戦を組ませる（上述したように）。対戦要求は、第１ユーザの対戦基準を含むだけでもよいし、又は第１ユーザ及び第１ユーザの友人の対戦基準（例えば、ＮＡＴ形式、接続形式、言語、位置、等）を含んでもよい。ある実施形態では、第１ユーザの友人の１人以上が、対戦の組まれた別のユーザと直接Ｐ２Ｐ接続を確立できない場合には、対戦の組まれたユーザと第１ユーザの友人との接続は、第１ユーザのデータ処理装置を通して確立され（例えば、第１ユーザの移動装置を接続のプロキシーとして使用して）、及び／又はリレーサービスを利用してユーザを接続する（上述したように）。
【０１５８】
１つの実施形態において、第１ユーザは、最初、マッチメーカーサービスによって１人以上のユーザと対戦が組まれ（上述したように）、次いで、第１ユーザは、１人以上の友人を、第１ユーザ及び対戦が組まれたユーザとのオンラインセッションに加えるために招待する。この実施形態では、ユーザの情報及び対戦が組まれたユーザの情報の両方（例えば、ＮＡＴ／接続データ、ユーザＩＤ、プッシュトークン、等）が、インビテーションサービスを通して、招待ユーザと交換される（上述したように）。本発明の基礎的な原理は、対戦を最初に組ませた後に招待するか、招待を最初に行った後に、対戦を組ませるかに関わらず、同じである。
【０１５９】
共同オンラインアプリケーションのためのアプリケーションプログラミングインターフェイスを伴うアプリケーションフレームワーク
図１９に示すように、本発明の一実施形態は、１つ以上のアプリケーション１９１１とインターフェイスするためのアプリケーションプログラミングインターフェイス（ＡＰＩ）１９１０、及び複数のネットワークサービス１９０１−１９０３と通信するためのサービスサイドＡＰＩ  １９１０を伴う規定のソフトウェアフレームワーク１９１２を有する移動装置１２０のコンテキスト内で具現化される。図１９に示すように、ネットワークサービス１９０１−１９０３は、同じオンラインデータサービス１００によって設計及び／又は管理される（が、そのような構成は、必要とされない）。Ｐ２Ｐゲームアプリケーション及び他の形式の共同オンラインアプリケーションのようなアプリケーション１９１１は、ＡＰＩ１９１０へコールをなすことによりＡＰＩ１９１０を通してネットワークサービス１９０１−１９０３にアクセスするように設計される。アプリケーション１９１１の設計は、フレームワーク１９１２及びネットワークサービス１９０１−１９０３の開発者により提供されるソフトウェア開発キッド（ＳＤＫ）を使用して容易にされる。フレームワーク１９１２及びＡＰＩ１９１０、１９１３のより特定の実施形態は、図２０を参照して以下に説明する。
【０１６０】
図示されたように、各サービスには、サービスにより使用されるデータを記憶するためのデータベース１９２０へのアクセスが与えられる。１つの特定例は、マッチメーカーサービス１１１により使用されるデータベース１５１２である（上述した）。他の例は、スコアボードデータを記憶するためのスコアボードデータベース、友人状態レコードを記憶するための友人サービスデータベース、ユーザプロフィールデータを記憶するためのプロフィールデータベース、及びオンラインゲームに関連したデータを記憶するためのゲームデータベースを含む。任意の形式のデータベース（例えば、ＭｙＳＱＬ、Ｍｉｃｒｏｓｏｆｔ  ＳＱＬ、等）を使用できるが、１つの特定の実施形態では、Ｂｅｒｋｌｅｙ  ＤＢ及び／又はＭＺＢａｓｉｃ  ＤＢのようなキー／値データベースを使用することができる。データベースは、記憶エリアネットワーク（ＳＡＮ）又は他の記憶構成で多数の大量記憶装置（例えば、ハードドライブ）にわたって分散される。
【０１６１】
従って、特定のサービスが、上述したように、データを処理し及び／又は記憶するときには、データがデータベース１９２０内に記憶される。しかしながら、あるサービスは、データベースを使用しない。例えば、上述したように、インビテーションサービスは、ステートレスサービスとして実施され、それ故、データベース１９２０内にデータを記憶することが要求されない（が、本発明の基礎的な原理によれば、そのような実施形態も考えられる）。
【０１６２】
ＡＰＩ１９１３は、例えば、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰをネットワークレイヤに、及びＨＴＴＰＳをアプリケーションレイヤに含む適当なネットワークプロトコルスタックを使用して、ネットワークサービス１９０１−１９０３と通信し、そしてそれらと情報を交換するように設計される。ＳＯＡＰのようなＨＴＴＰ又はＨＴＴＰＳを経てのリモート手順コール（ＲＰＣ）ベースのプロトコルが使用され、及び／又は代表的状態転送（ＲＥＳＴ）プロトコルが使用される。更に、サービスは、例えば、Ｕｎｉｘ、Ｌｉｎｕｘ又はＡｐａｃｈｅソフトウェアプラットホームを実行するＸｓｅｒｖｅ又は同様のサーバーを含むコンピューティングプラットホームにおいて実施される。ある特定の実施形態では、プラットホームは、Ｌｉｎｕｘにおいて実施されるウェブオブジェクトを含む。前記の例は、説明上のものに過ぎない。本発明の基礎的な原理は、アプリケーションをサーバー、又はネットワークプロトコルの特定セットにリンクするための特定のメカニズムに限定されない。
【０１６３】
図２０は、本発明の１つの実施形態においてワイヤレス装置１２０上で実施されるアプリケーションプログラミングインターフェイス（ＡＰＩ）２００１ａ−ｂを含むより詳細なソフトウェアアーキテクチャーを示す。この実施形態は、マルチプレーヤゲームフレームワーク２０００のコンテキスト内で説明するが、本発明の基礎的な原理は、ゲームの実施形態に限定されない。例えば、図２０に示すソフトウェアアーキテクチャーは、ゲーム以外の種々の共同アプリケーション（例えば、共同チャット、多当事者共同オーディオ／ビデオ、等）をサポートするのに使用される。
【０１６４】
図２０に示すアーキテクチャーでは、ここに述べる種々の多当事者特徴及びＰ２Ｐ特徴をサポートするためにゲームフレームワーク２０００が設けられる。１つの実施形態では、ゲームフレームワーク２０００は、移動装置のオペレーティングシステム２００５上で実行するように設計される。例えば、移動装置１２０がｉＰｈｏｎｅ、ｉＰａｄ、又はｉＰｏｄ  Ｔｏｕｃｈである場合には、オペレーティングシステム２００５は、本発明の譲受人によって設計された移動オペレーティングシステムであるｉＰｈｏｎｅ  ＯＳである。
【０１６５】
ゲームフレークワーク２０００は、パブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）２００１ｂ及びプライベート又は「セキュア」なＡＰＩ２００１ａを備えている。１つの実施形態では、ここに述べる種々のゲーム関連特徴を与えるように設計されたゲームセンターアプリケーション２０３１は、パブリックＡＰＩ２００１ｂ及びプライベートＡＰＩ２００１ａの両方にコールを発信し、一方、他のアプリケーション２０３０（例えば、第三者により設計されたアプリケーション）にはパブリックＡＰＩ２００１ｂのみへのアクセスが与えられる。例えば、移動装置１２０の設計者は、潜在的に繊細な情報を含む幾つかのＡＰＩ機能をパブリックＡＰＩ２００１ｂから締め出して、第三者の開発者（例えば、友人要求、友人リスト、等）による誤用を回避することを望む。しかしながら、セキュアなＡＰＩ２００１ａ及びパブリックＡＰＩ２００１ｂの両方は、移動装置の全てのアプリケーションによってアクセス可能な単一のＡＰＩへ合体される（即ち、本発明の基礎的な原理に合致するためにＡＰＩを個別のパブリック及びプライベートコンポーネントに分離することは要求されない）。「ＡＰＩ２００１」という呼称は、以下、パブリックＡＰＩ２００１ｂ及び／又はプライベートＡＰＩ２００１ａのいずれかに見られる動作を指すために時々使用される。
【０１６６】
ゲームセンターアプリケーション２０３１の１つの実施形態は、Marcel Van Os及びMike Lampellを発明者とする、２０１０年４月７日に出願された“System and Methods for Providing a Game Center”と題する同時係争中の特許出願（代理人管理番号４８６０．Ｐ９１２７ＵＳＰ１）（以下、「ゲームセンター特許出願」という）に記載されており、これは、本出願の譲受人に譲渡されたもので、参考としてここに援用される。簡単に述べると、ゲームセンターアプリケーション２０３１は、マルチプレーヤゲームを通してナビゲートし、新たなゲームを購入し、ゲームに関連した情報（例えば、スコアボード情報、実績、友人情報、等）を検索し、ゲームをプレイするために友人に連絡し、他のユーザとのゲーム対戦を要求し、そして特定のユーザを招待するためのゲームセンターグラフィックユーザインターフェイス（ＧＵＩ）を含む。ゲームセンターアプリケーション２０３１により遂行される種々の他の機能は、前記ゲームセンター特許出願に記載されている。ゲームセンター機能の幾つかは、ゲームフレームワーク２０００によって与えられ、パブリックＡＰＩ２００１ｂを通して他のアプリケーション２０３０にアクセスできるようにされる。
【０１６７】
１つの実施形態において、ゲームフレームワーク２０００により露出されるＡＰＩ２００１は、移動装置１２０のためのマルチプレーヤ共同ゲームを設計するプロセスを簡単化する。特に、１つの実施形態では、ＡＰＩ２００１は、開発者が簡単なＡＰＩコールを発信して、マルチプレーヤＰ２Ｐゲームセッションのためにユーザを接続する比較的複雑なプロセスを呼び出すことができるようにする。例えば、ＩＮＶＩＴＥ（プレーヤＢ  ＩＤ、バケットＩＤ）のような簡単なＡＰＩコールは、上述した詳細なインビテーションシーケンスを開始するためにＡＰＩ２００１から呼び出される。同様に、ＭＡＴＣＨ（プレーヤＡ  ＩＤ、バケットＩＤ）のようなＡＰＩコールは、上述した詳細なマッチメークシーケンスを開始するためにＡＰＩ２００１から呼び出される。ＩＮＶＩＴＥ及びＭＡＴＣＨ機能は、一般的に、ここでは「Ｐ２Ｐ接続機能」とも称される。１つの実施形態において、ゲームフレームワーク２０００は、これらのＡＰＩコールに応答してインビテーション及びマッチメーカー動作を管理するのに必要なプログラムコードを含む（以下に詳細に述べる）。実際のＡＰＩ機能は、上述したものとは若干異なるデータを有する（が、ゲームフレームワーク２０００により遂行される同様の動作を生じる）。本発明の基礎的な原理は、ＡＰＩ機能を指定する特定のフォーマットに限定されない。
【０１６８】
種々の他の形式のゲーム関連トランザクション及び情報も、ゲームセンターアプリケーション２０３１及び他のアプリケーション２０３０に代わってゲームフレームワーク２０００により管理される。この情報の幾つかは、前記ゲームセンター特許出願に記載されている。例えば、これに限定されないが、この情報は、各ゲームについてトップスコアを達成したユーザに関連した「スコアボード」情報と、あるゲーム特有の実績を果たしたユーザを識別する「実績」情報とを含む。各アプリケーション開発者は、各ゲームアプリケーション２０３０に対しそれ自身の１組の「実績」（例えば、完了レベル１−３；完了レベル１は５分以内；レベル当たり５０以上の破壊；２０本の旗をノックダウン；等）を指定する。
【０１６９】
又、ゲームフレームワーク２０００は、ユーザの友人データを管理すると共に、ゲームセンター２０３１及び他のゲームアプリケーション２０３０のコンテキスト内に友人データを集積するためのプログラムコードも含む。例えば、ユーザがゲームセンター２０３１内の特定のゲームへのリンクを選択すると、ユーザの各友人に関連した情報がそのゲームについて表示される（例えば、スコアボード上の友人のランキング、友人の実績、ユーザがその友人の各々とゲームをプレイしたときの結果、等）。１つの実施形態において、ゲームフレームワーク２０００のＡＰＩ２００１は、友人サービスにより管理される友人データにアクセスするための機能を含み、これは、例えば、Amol Pattekar、Jeremy Werner、Patric Gate及びAndrew H. Vyrrosを発明者とする、２０１０年４月７日に出願された“Apparatus and Methods for Efficiently Managing Data in a Social Networking Service”と題する同時係争中の特許出願（代理人管理番号４８６０．Ｐ９１４０）（以下、「友人サービス出願」という）に記載されており、これは、本出願の譲受人に譲渡されたもので、参考としてここに援用される。
【０１７０】
図２０に示すように、１つの実施形態では、ゲームデーモン２０２０は、ゲームフレームワーク２０００を第１組のサービス２０５０へインターフェイスし、そしてゲームサービスコンポーネント２０１０は、ゲームフレームワーク２０００を第２組のサービス２０５１へインターフェイスする。例えば、第１組のサービス２０５０は、上述したインビテーションサービス１１２、マッチメーカーサービス１１１、及びリレーサービス１０５１と、上述した友人サービス出願に記載された友人サービスとを含む。ゲームデーモン２０２０を経てアクセスされる他のサービスは、スコアボードサービス（スコアボードデータを与える）、ゲームサービス（ゲーム及びゲーム購入能力の各々に関連した統計値及び他のデータを与える）、ユーザ認証サービス（移動装置のユーザを認証する）、及び／又はユーザプロフィールサービス（ユーザの好みのようなユーザプロフィールデータを記憶する）を含む。ゲームサービスコンポーネント２０１０を経てアクセスされる第２組のサービス２０５１は、上述した接続データ交換（ＣＤＸ）サービス１１０、及びＮＡＴ横断サービス２９０−２９１を含む。説明上、図２０には個別のコンポーネントとして示されているが、ゲームデーモン２０２０及びゲームサービスモジュール２０１０は、実際には、ゲームフレームワーク２０００のコンポーネントである。１つの実施形態において、ゲームデーモン２０２０及び２０１０は、規定のＡＰＩを通してネットワークサービス２０５０−２０５１の各々と通信し、規定のＡＰＩは、１つの実施形態では、プライベートＡＰＩである（即ち、第三者の開発者へ発行されない）。
【０１７１】
１つの実施形態において、ゲームデーモン２０２０は、ＨＴＴＰＳプロトコルを使用してマッチメーカーサービス１１１、インビテーションサービス１１２及び他のサービス２０５０と通信し、一方、ゲームサービスモジュール２０１０は、ＵＤＰソケットのような比較的軽量のプロトコルを使用してＣＤＸサービス１１０及びＮＡＴ横断サービス２９０−２９１と通信する。しかしながら、上述したように、本発明の基礎的な原理に合致しながら、種々の他のネットワークプロトコルが使用されてもよい。
【０１７２】
更に、図２０に示されたように、ゲームデーモン２０２０は、あるサービス２０５２（例えば、インビテーションサービス及びマッチメーカーサービス）により発生されたプッシュ通知２０５２を受け取り、一方、他の形式のプッシュ通知２０５３は、ゲームセンターにより直接受信される（例えば、新たな友人要求のような友人サービス通知）。１つの実施形態において、これらのプッシュ通知２０５３は、ユーザの繊細なデータが、第三者のアプリケーション開発者により設計されたアプリケーション２０３０へアクセスされないよう保証するために、ゲームセンター２０３１へ直接与えられる。
【０１７３】
図１１について上述したゲームインビテーション例に戻ると、移動装置Ａのアプリケーション２０３０が、移動装置Ｂのユーザを招待するためにゲームフレームワーク２０００のＡＰＩ２００１ｂへインビテーションコールを発信すると（例えば、ＩＮＶＩＴＥ（プレーヤＢ  ＩＤ、ゲーム／バケットＩＤ））、ゲームフレームワーク２０００は、インビテーション要求を移動装置Ａのゲームデーモン２０２０へ送る。ゲームデーモン２０２０は、次いで、インビテーション要求を提出するためにインビテーションサービス１１２と通信する。インビテーションサービス１１２は、次いで、プッシュ通知サービス１０５０を使用して、移動装置Ｂのゲームデーモン２０２０にインビテーションをプッシュする。次いで、移動装置Ｂのゲームデーモン２０２０は、移動装置Ｂのゲームフレームワーク２０００と通信して、インビテーションが送られるところのゲームが移動装置Ｂにインストールされるかどうか決定する。もしそうであれば、ゲームフレームワーク２０００は、アプリケーション２０３０をトリガーし、及び／又はインビテーションのビジュアル通知を発生する。アプリケーションがインストールされない場合には、ゲームフレームワーク２０００は、ゲームを購入するオファーと共に移動装置Ｂのユーザへインビテーションのビジュアル通知をトリガーする（例えば、ゲームセンター２０３１ＧＵＩを経て）。或いは又、ビジュアル通知は、移動装置１２０（図示せず）上で実行されるプッシュ通知デーモンにより発生されてもよい。移動装置Ｂのユーザがゲームを購入する場合には、購入後にインビテーションシーケンスが続けられる。移動装置Ｂのユーザがインビテーション要求を受け容れる場合には、移動装置Ｂのゲームフレームワーク２０００がインビテーション要求をそのゲームデーモン２０２０へ送り、これは、次いで、インビテーションサービス１１２に応答する。
【０１７４】
図１１において、移動装置Ａ及びＢのＮＡＴ形式が適合することを適合性チェック１１０６が決定したことを想起されたい。従って、１１０８において、移動装置Ａのゲームデーモン２０２０は、移動装置Ｂの受け容れを受信し（例えば、この例ではプッシュ通知を経て）、そして１つの実施形態において、その受け容れをゲームフレームワーク２０００へ通す。この段階において、移動装置Ａのゲームフレームワーク２０００は、移動装置Ｂが受け容れたことを（ＡＰＩ２００１を経て）要求側アプリケーション２０３０に通知するか、或いは装置が首尾良く接続されるまで要求側アプリケーション２０３０への通知を待機する。いずれにせよ、ゲームフレームワーク２０００は、接続要求をゲームサービスモジュール２０１０へ送り、該モジュールは、１つの実施形態では、移動装置Ｂとの接続データの交換を開始する。特に、ゲームサービスモジュールは、ＣＤＸサービス１１０を使用して移動装置Ａの接続データを移動装置Ｂへ送信する（例えば、図１１のトランザクション１１１１及び１１１２を参照）。上述したように、この通信は、セキュアな「チケット」データ構造体を使用してＵＤＰ接続として実施される。
【０１７５】
図１２において、移動装置Ａ及びＢのＮＡＴ形式が適合しないことを適合性チェック１１０６が決定した場合には、リレーサービス１０５１を使用して、装置間の接続を与えることを想起されたい。従って、移動装置Ｂのゲームデーモン２０２０は、インビテーションサービス（図１２に示す）からリレー応答１２０３を受け取り、そして移動装置Ａのゲームデーモン２０２０は、インビテーションサービスから（プッシュ通知サービス１０５０を経て）リレー応答１２０５を受け取る。移動装置Ａ及びＢのゲームデーモン２０２０は、１２０６及び１２０７においてリレーサービスと通信して、構成データを検索する。１２１０において、移動装置Ｂのゲームデーモン２０２０は、移動装置Ａからリレー更新データを受け取り、そして１２１３において、移動装置Ａのゲームデーモン２０２０は、移動装置Ｂからリレー更新データを受け取る。
【０１７６】
図１１及び１２に示すプロセスの最終結果は、移動装置Ａ及びＢが互いに接続を確立した（直接Ｐ２Ｐ接続又はリレー接続）ことである。１つの実施形態において、接続成功を検出すると、ゲームフレームワーク２０００は、ＡＰＩコール（例えば、ＣＯＮＮＥＣＴＥＤ（プレーヤＡ  ＩＤ、プレーヤＢ  ＩＤ））を使用して、接続を要求したアプリケーション２０３０に通知を行う。次いで、移動装置Ａ及びＢは、確立された接続を使用して指定のゲーム又は他の共同アプリケーション２０３０をプレイする。
【０１７７】
従って、ＡＰＩ２００１からの比較的簡単なコール（例えば、ＩＮＶＩＴＥ（プレーヤＢ  ＩＤ、ゲーム／バケットＩＤ））に応答して、複雑な一連のトランザクションがゲームフレームワーク２０００により管理されて、移動装置ＡとＢとの間にＰ２Ｐ又はリレー接続を確立する。１つの実施形態では、ゲームフレームワーク２０００は、移動装置Ａ及びＢを接続するための一連の動作を遂行し、次いで、要求側アプリケーション２０３０に結果を与えて、ＡＰIコールの細部をアプリケーションの設計者に対して透過的のままにする。従って、アプリケーション設計者は、ネットワーク上で移動装置Ａ及びＢをどのように接続するか理解したり、又は装置間の通信を可能にするために要求される種々の他の機能を遂行したりする必要がなく、それにより、アプリケーション設計プロセスが簡単化される。
【０１７８】
同様に、ゲームフレームワーク２０００は、図２ａ−ｂに関して上述したようにマッチメーカーサービス１１１を使用して移動装置Ａと他の参加者との間に対戦を確立する。この例では、アプリケーション２０３０は、ＭＡＴＣＨ（プレーヤＡ  ＩＤ、ゲーム／バンドルＩＤ）のような簡単なコールをＡＰＩ２００１へ発信する。これに応答して、ゲームフレームワーク２０００は、対戦組み及び接続データ交換動作を管理することができる。対戦を組む動作及び／又はＰ２Ｐ接続が完了すると、ゲームフレームワーク２０００は、その結果をアプリケーション２０３０に与える。
【０１７９】
例えば、図２ｂにおいて、ゲームフレームワーク２０００は、ゲームサービスモジュール２０１０を使用して、接続データ交換（ＣＤＸ）サービス１１０及びＮＡＴ横断サービス２９０−２９１と通信し、そしてゲームデーモンを使用して、マッチメーカーサービス１１１と通信する。対戦が組まれると、移動装置Ａのゲームデーモン２０２０は、２２９において、チケットＡを受け取り、そしてゲームフレームワーク２０００は、その情報を使用して、ゲームサービスモジュール２０１０を通して接続データ交換を実施する。例えば、ＮＡＴ横断サービス２９０を通してそれ自身の接続データを要求し、次いで、２３３−２３４において、その接続データを、ＣＤＸサービス１１０を通して交換する。２３７及び２４０において、移動装置Ａのゲームサービスモジュール２０１０は、移動装置Ａ及びＣの接続データを各々受け取る。それらの交換に続いて、ゲームサービスモジュール２０１０は、２４１において、Ｐ２Ｐ接続を確立し、そしてゲームフレームワーク２０００は、ＡＰＩ通知（例えば、ＭＡＴＣＨ  ＣＯＭＰＬＥＴＥ（プレーヤＢ  ＩＤ、プレーヤＣ  ＩＤ）)を使用して接続プロセスが完了したことをアプリケーション２０３０に通知する。次いで、アプリケーションは、確立したＰ２Ｐ接続の使用を行う。
【０１８０】
ある実施形態では、ユーザには、現在「オンライン」として登録されている他の友人とゲームをプレイするオプションが与えられる。このケースでは、ある友人がオンラインであるとの通知がプッシュ通知２０５２又はプッシュ通知２０５３（ゲームセンター２０３１により直接受け取られる）を経て与えられる。ゲームセンター２０３１及び／又はアプリケーション２０３０は、次いで、ユーザに通知を与えると共に、１人以上の選択されたオンライン友人とプレイするオプションをユーザに与える。しかしながら、ここに述べるインビテーションシーケンスは、オンライン通知が与えられるかどうかに関わらず機能することに注意されたい。１つの実施形態では、ユーザのオンライン状態は、ゲームデーモン２０２０によりアクセス可能なサービスにより監視される（例えば、上述した友人サービス又は個別の「存在」サービスにより）。
【０１８１】
ゲームフレームワーク２０００の１つの実施形態は、対戦が組まれた未知の参加者のグループとゲームをプレイするためにユーザが１人以上の友人を招待するインビテーション／マッチメーカー組み合わせ動作を与える。例えば、ゲームが４人のプレーヤを必要としそして第１のユーザがゲームをプレイするために第２のユーザを招待する場合には、インビテーションサービス１１２は、最初に、第１のユーザと第２のユーザを接続し、そしてマッチメーカーサービス１１１は、第１ユーザ及び第２ユーザと他の２人（以上）のプレーヤとの対戦を組む。この実施形態では、ゲームフレームワーク２０００は、最初、上述したインビテーションシーケンスを遂行して、第１ユーザと第２ユーザを接続する。１つの実施形態では、第１ユーザと第２ユーザが首尾良く接続されたときに、ゲームフレームワーク２０００は、マッチメーキングシーケンスを実施して、他方のユーザを識別し接続する。上述したように、１つの実施形態では、マッチメーカーサービスにより適用される対戦を組む基準は、第１及び第２の両ユーザを含む（例えば、第１及び第２の両ユーザのＮＡＴ形式、接続形式、言語、等）。或いは又、２人のユーザの一方の基準を評価して、対戦を組む判断を行ってもよい。
【０１８２】
全てのユーザが接続されると、ゲームフレームワーク２０００は、ＡＰＩ２００１を経て接続を要求したアプリケーション２０３０に接続結果を与える。ここでも、アプリケーション２０３０による比較的簡単なＡＰＩコールに応答して、ゲームフレームワーク２０００は、１組の複雑なトランザクションに入り、各装置を接続する。装置が首尾良く接続されると、ゲームフレームワーク２０００は、要求側アプリケーション２０３０に結果を与える。
【０１８３】
図２０に示すように、ゲームフレームワーク２０００は、ユーザと他のゲーム参加者との間の通信を一時的に記憶するために通信バッファ２００３を備えている。通信は、例えば、テキスト、オーディオ及び／又はビデオ通信を含む。ゲームフレームワーク２０００は、各アプリケーション２０３０の要件に基づいてバッファ２００３を確立する。例えば、低速のネットワーク接続でオーディオ／ビデオ通信するには、比較的大きなバッファ２００３が要求される。１つの実施形態において、各アプリケーション２０３０は、ＡＰＩ２００１を経てあるサイズの通信バッファを確立するために明確な要求を行う（例えば、ＢＵＦＦＥＲ（サイズ）コマンドを使用して）。或いは又、ゲームフレームワーク２０００は、各アプリケーションの通信要件に基づいてバッファを自動的に生成する。例えば、ゲームフレームワーク２０００は、テキスト、オーディオ及び／又はビデオをサポートする必要があるかどうかに基づき特定のバッファを選択する。
【０１８４】
１つの実施形態において、通信バッファ２００３は、ユーザ間に全てのＰ２Ｐ接続が確立されるまで通信ストリームを一時的に記憶する。例えば、インビテーションサービス１１２又はマッチメーカーサービス１１１が各ユーザを識別した後であるが、ＣＤＸサービス１１０が接続データ交換動作を完了する前に、各ユーザには、接続されているプロセス内の他のゲーム参加者が通知される。この段階で、移動装置１２０のユーザは、テキスト、オーディオ及び／又はビデオ通信ストリームを他の参加者に送信する。ゲームフレームワーク２０００は、まだ接続されていない参加者に対して通信バッファ２００３内に通信ストリームを記憶する。次いで、ゲームフレームワーク２０００は、各装置の接続が完了したときにバッファ２００３からテキスト、オーディオ及び／又はビデオを送信する。
【０１８５】
１つの実施形態において、ゲームデーモン２０２０は、ネットワークトラフィックを減少するために各サービス２０５０に存続するデータをキャッシュ記憶するキャッシュ２０２１を含む。例えば、ユーザの友人リスト、スコアボードデータ、実績データ、存在データ及びプロフィールデータが、キャッシュ管理ポリシーにより指定されてキャッシュ２０２１に記憶される。１つの実施形態において、キャッシュ管理ポリシーは、データが記憶される各個々のサービスにより駆動される。従って、ｎ個の異なるサービスについて、ｎ個の異なるキャッシュ管理ポリシーがキャッシュ２０２１に適用される。更に、キャッシュ管理ポリシーは、サービスにより駆動されるので、現在ネットワーク及び／又はサーバー負荷状態に基づいて動的に変更される。例えば、サービスに大きい負荷がかかる期間中には（例えば、クリスマス、新製品発売日、等）、サービスは、あまり頻繁にキャッシュ更新しない（例えば、１２時間ごとに更新する）キャッシュ管理ポリシーを動的に指定する。対照的に、サービスにあまり負荷がかからない期間中には、サービスは、より頻繁にキャッシュ更新する（例えば、３０分ごと、１時間ごと、２時間ごと、等に更新する）キャッシュポリシーを指定する。
【０１８６】
１つの実施形態において、キャッシュ管理ポリシーは、キャッシュ２０２１に記憶されたあるデータレコードに対してタイム・ツー・リブ（ＴＴＬ）値を使用して指定される。データレコードがそのＴＴＬ値を越えてキャッシュに記憶されていたときには、そのデータは、「古くなった」と考えられ、そのデータに対するローカル要求がそのデータに関連したサービスへ直接転送される。１つの実施形態では、その要求は、データの現在バージョンを識別するＩＤコードを含む。ＩＤコードがサービスのＩＤコードに一致する場合には、データが依然有効であり、更新する必要がない。次いで、キャッシュのデータが現在のものであることを示す応答がサービスから返送され、そしてデータレコードのＴＴＬ値がリセットされる。
【０１８７】
上述したようにキャッシュ管理ポリシーを使用するのに加えて、１つの実施形態では、ある形式のデータに対するキャッシュ更新が、プッシュ通知サービス１０５０を使用して移動装置へプッシュされる。例えば、ユーザの友人リスト又はユーザの友人の現在オンライン状態に対する変化がユーザの移動装置１２０へ動的にプッシュされる。プッシュ通知は、ゲームデーモン２０２０により受け取られ、次いで、そのゲームデーモンは、サーバーによりプッシュされたデータの相対的部分を含むようにキャッシュ２０２１を更新する（即ち、そのサービスに関連したキャッシュにおける全データの更新が要求されるのではない）。対照的に、あるプッシュ通知は、キャッシュの全コンテンツ（又はプッシュを実行するサービスに関連したキャッシュの少なくとも一部分）をオーバーライトするようにゲームデーモン２０２０に命令する。
【０１８８】
キャッシュ２０２１を更新するためにプッシュを利用するサービスは、キャッシュ２０２１に記憶されたデータを更新するために通知をプッシュすることができるので、比較的高いＴＴＬを選択する（及び／又はＴＴＬ値をセットしない）。１つの実施形態では、各サービスは、プッシュ通知キャッシュ更新をトリガーする１組のイベントを指定する。例えば、キャッシュ更新イベントは、友人のオンライン状態の変化、新たな友人要求、友人要求の受け容れ、友人解除(de-friend)動作、友人が特定のゲームをプレイしているとの指示、友人が到達したゲーム実績、特定のスコアボードのトップ１０の更新、又はキャッシュ更新を保証するためにかなり重要と思われる他のイベントを含む。このようにプッシュ通知を使用してキャッシュ２０２１を更新することで、ネットワーク及びサービスの負荷が減少される。というのは、プッシュ更新で、移動装置とサービスとの間の周期的なポーリングが不要になるからである。
【０１８９】
ゲームフレームワーク２０００の１つの実施形態は、ユーザの国及び／又は地理的位置に基づいてエンドユーザに提示されるデータを独特にフォーマットする。例えば、現在の日時及び通貨価値のような値は、異なる国及び位置においてユーザに異なる仕方で提示される。例えば、米国では、日付フォーマットは、［月、日、年］（例えば、April 25, 2010）であり、一方、他の国々では、［日、月、年］（例えば、25 April, 2010）である。同様に、米国及び他の国々において時間を表わすときは、ＡＭ／ＰＭの呼称が使用され、時間と分との間にコロンが使用される（例えば、３：００  ＰＭ）。対照的に、他の多数の国々は、ＡＭ／ＰＭ呼称を使用せず、及び／又は時間と分との間にコンマを使用する（例えば、１５，００）。別の例として、世界の多くの地域ではメートル系を使用するが、ある地域では使用しない（例えば、米国）。これらは、本発明の幾つかの実施形態により使用される単なる例示に過ぎないことに注意されたい。本発明の基礎的な原理は、特定の１組の日付フォーマットに限定されない。
【０１９０】
１つの実施形態において、これらの異なるデータフォーマットは、スコアボードデータ、実績データ、友人データ、及び／又はゲームフレームワーク２０００により処理される他のデータを表示するときに選択される。ゲームフレームワーク２０００は、ユーザの国及び／又は地理的位置を種々の仕方で決定する。例えば、１つの実施形態では、この情報は、単にユーザプロフィールデータに与えられ、及び／又はユーザのセルラーサービスプロバイダーに基づいて決定される。又、ユーザの位置は、例えば、グローバルポジショニングシステム（ＧＰＳ）追跡を使用して決定されてもよい。
【０１９１】
地理的位置及び／又は国に関連しない他の形式のデータフォーマットも、ゲームフレームワーク２０００により管理される。例えば、スコアボードデータを表示するときには、最低スコアのユーザをスコアボードの最上部に入れるか最下部に入れるか知っていることが重要である。あるゲーム（例えば、ゴルフ、トラック、レース、スキー、等）では、低い数字が良い成績を示し、一方、他のゲーム（フットボール、野球、等）では、高い数字が良い成績を示す。従って、１つの実施形態では、アプリケーション２０３０は、ＡＰＩ２００１を経て使用されるスコアの形式（例えば、「上昇順」又は「降下順」）を指定する。次いで、ゲームフレームワーク２０００は、スコアを表示するための適当な１組のラベル及びフォーマットを使用する。
【０１９２】
又、ゲームフレームワーク２０００の１つの実施形態は、ユーザとユーザの友人との関係に基づきユーザデータをフィルタリングする。例えば、本発明の１つの実施形態では、「詳細」ビュー、「友人」ビュー及び「パブリック」ビューが許される。１つの実施形態において、詳細ビューは、データを所有するユーザに利用でき（即ち、ユーザのパーソナル情報）、友人ビューは、ユーザの友人に利用でき、そしてパブリックビューは、他の全てのユーザに利用できる。
【０１９３】
例えば、パブリックビューは、単に、各ユーザに関連した「別名(alias)」、別名でプレイしたゲーム及びその関連スコア、及びゲームがプレイされた日時を含む。この情報は、パブリックスコアボードをポピュレートして、ゲームセンター２０３１を経て表示するようにゲームフレームワーク２０００により使用される。
【０１９４】
友人ビューは、一般的ビューからの全ての情報、及びユーザの友人間で共有すべき付加的な情報を含み、これは、例えば、幾つか挙げると、ユーザが所有するゲーム、ユーザがプレイするゲーム、ユーザの実績及びスコア、何人の友人をユーザが有するか、それら友人のアイデンティティ、ユーザの化身を識別するＵＲＬ、及び／又はユーザのオンライン状態を含む。１つの実施形態では、「友人」ビューは、友人と共有すべき情報のデフォールトセットを与えるが、エンドユーザは、このデフォールト構成を調整し、そして各個々の友人又は友人のグループ（例えば、仕事の同僚、家族メンバー、大学／高校の友人、等）により共有すべき情報の形式を詳細事項で指定する。
【０１９５】
「詳細」ビューは、「パブリック」及び「友人」ビューからの全ての情報、並びにエンドユーザに代わって種々のサービス２０５０により管理される他の情報を含む。一例として、これは、ユーザのプロフィールデータ、ユーザのユニバーサルユニーク識別子（ＵＵＩＤ）（ここでは「プレーヤＩＤ」とも称される）、プレーヤの名前、別名、ゲーム数及びゲームのアイデンティティ、ユーザの友人、ユーザの全実績、等の全てを含む。
【０１９６】
ある環境において、アプリケーション２０３０は、各ユーザに関連した僅かな量の情報、例えば、各ユーザのプレーヤＩＤしか要求しない。例えば、１つの実施形態では、対戦を組むことが要求されたとき、ゲームフレームワーク２０００は、最初に、各プレーヤのＩＤしか要求しない。マッチメーカーサービス（前記を参照）により対戦が組まれると、ゲームフレームワーク２０００は、対戦が組まれたユーザのいずれかが友人であるかどうか決定する（例えば、友人サービスとの通信を経て及び／又はユーザのローカル友人データに質問することにより）。もしそうであれば、ゲームフレームワーク２０００は、付加的なユーザデータを検索し、そしてそのデータを対戦が組まれた友人に与える。このようにして、ゲームフレームワーク２０００は、ユーザのアイデンティティ、及び各ユーザの関係に基づいて情報をフィルタリングする。
【０１９７】
１つの実施形態において、ゲームフレームワーク２０００は、最初に、第１ユーザ及び第２ユーザが友人関係にない場合には２人のユーザ間のパブリックビューを与える。しかしながら、１つの実施形態では、ゲームフレームワーク２０００は、第１ユーザが第２ユーザに友人要求を送信するのを許す（例えば、第２ユーザの別名を使用して）。友人要求が受け容れられた場合には、ゲームフレームワーク２０００は、各ユーザに付加的な情報を与える（例えば、デフォールト「友人」ビュー）。
【０１９８】
異なるＡＰＩ実施形態
１つの実施形態において具現化されるＡＰＩは、ソフトウェアコンポーネント（以下、ＡＰＩ実施ソフトウェアコンポーネント）により具現化されるインターフェイスであり、これは、異なるソフトウェアコンポーネント（以下、ＡＰＩコールソフトウェアコンポーネント）が、１つ以上の機能、方法、手順、データ構造体、及び／又はＡＰＩ実施ソフトウェアコンポーネントにより提供される他のサービスにアクセスして利用するのを許すものである。例えば、ＡＰＩは、ＡＰＩコールソフトウェアコンポーネントの開発者（第三者の開発者）がＡＰＩ実施ソフトウェアコンポーネントにより提供される指定の特徴をレバレッジするのを許す。１つのＡＰＩコールソフトウェアコンポーネントがあってもよいし、又は２つ以上のそのようなソフトウェアコンポーネントがあってもよい。ＡＰＩは、ソフトウェアアプリケーションからのサービス要求をサポートするためにコンピュータシステム又はプログラムライブラリーが提供するソースコードインターフェイスである。ＡＰＩは、データがメモリにどのようにレイアウトされるかの明確な低レベル記述ではなく、アプリケーションを構築するときに解釈でき又はコンパイルできるプログラミング言語に関して指定される。
【０１９９】
ＡＰＩは、ＡＰＩ実施ソフトウェアコンポーネントの指定の特徴にアクセスして使用するときにＡＰＩコールソフトウェアコンポーネントが使用する言語及びパラメータを定義する。例えば、ＡＰＩコールソフトウェアコンポーネントは、ＡＰＩにより露出される１つ以上のＡＰＩコール（機能又は方法コールとも称される）を通してＡＰＩ実施ソフトウェアコンポーネントの指定の特徴にアクセスする。ＡＰＩ実施ソフトウェアコンポーネントは、ＡＰＩコールソフトウェアコンポーネントからのＡＰＩコールに応答してＡＰＩを通して値を返送する。ＡＰＩは、ＡＰＩコールのシンタックス及び結果（例えば、ＡＰＩコールをどのように呼び出し及びＡＰＩコールが何を行うか）を定義するが、ＡＰＩは、典型的に、ＡＰＩコールにより指定された機能をＡＰＩコールがどのように遂行するか明らかにするものではない。種々の機能コール又はメッセージは、コールソフトウェア（ＡＰＩコールソフトウェアコンポーネント）とＡＰＩ実施ソフトウェアコンポーネントとの間の１つ以上のアプリケーションプログラミングインターフェイスを経て転送される。機能コール又はメッセージの転送は、機能コール又はメッセージを発行し、開始し、呼び出し、コールし、受信し、返送し、又はそれに応答することを含む。従って、ＡＰＩコールソフトウェアコンポーネントは、コールを転送し、そしてＡＰＩ実施ソフトウェアコンポーネントも、コールを転送することができる。
【０２００】
一例として、ＡＰＩ実施ソフトウェアコンポーネント２０１０及びＡＰＩコールソフトウェアコンポーネントは、オペレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュールである（ＡＰＩ実施ソフトウェアコンポーネント及びＡＰＩコールソフトウェアコンポーネントは、互いに同じ形式のソフトウェアモジュールでも異なる形式のソフトウェアモジュールでもよいことを理解されたい）。ＡＰＩコールソフトウェアコンポーネントは、ローカルソフトウェアコンポーネント（即ち、ＡＰＩ実施ソフトウェアコンポーネントと同じデータ処理システムにある）でもよいし、又はネットワーク上でＡＰＩを通してＡＰＩ実施ソフトウェアコンポーネントと通信するリモートソフトウェアコンポーネント（即ち、ＡＰＩ実施ソフトウェアコンポーネントとは異なるデータ処理システムにある）でもよい。ＡＰＩ実施ソフトウェアコンポーネントは、ＡＰＩコールソフトウェアコンポーネントとしても働き（即ち、異なるＡＰＩ実施ソフトウェアコンポーネントにより露出されるＡＰＩへＡＰＩコールを発信し）、そしてＡＰＩコールソフトウェアコンポーネントは、異なるＡＰＩコールソフトウェアコンポーネントへ露出されるＡＰＩを実施することによりＡＰＩ実施ソフトウェアコンポーネントとしても働くことを理解されたい。
【０２０１】
ＡＰＩは、異なるプログラミング言語で書かれた複数のＡＰＩコールソフトウェアコンポーネントがＡＰＩ実施ソフトウェアコンポーネントと通信できるようにする（従って、ＡＰＩは、ＡＰＩ実施ソフトウェアコンポーネントとＡＰＩコールソフトウェアコンポーネントとの間でコール及び返信を変換するための特徴を含む）。しかしながら、ＡＰＩは、特定のプログラミング言語に関して実施される。
【０２０２】
図２１は、ＡＰＩ２１２０を実施するＡＰＩ実施ソフトウェアコンポーネント２１１０（例えば、オペレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）を備えたＡＰＩアーキテクチャーの１つの実施形態である。ＡＰＩ２１２０は、ＡＰＩコールソフトウェアコンポーネント２１３０により使用されるＡＰＩ実施ソフトウェアコンポーネントの１つ以上の機能、方法、クラス、オブジェクト、プロトコル、データ構造、フォーマット及び／又は他の特徴を指定する。ＡＰＩ２１２０は、ＡＰＩ実施ソフトウェアコンポーネントの機能がＡＰＩコールソフトウェアコンポーネントからパラメータをどのように受け取るか、そしてその機能がＡＰＩコールソフトウェアコンポーネントへ結果をどのように返送するか指定する少なくとも１つのコール慣習を指定することができる。ＡＰＩコールソフトウェアコンポーネント２１３０（例えば、オペレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）は、ＡＰＩ２１２０により指定されたＡＰＩ実施ソフトウェアコンポーネント２１１０の特徴にアクセスして使用するためにＡＰＩ２１２０を通してＡＰＩコールを発信する。ＡＰＩ実施ソフトウェアコンポーネント２１１０は、ＡＰＩコールに応答してＡＰＩ２１２０を通してＡＰＩコールソフトウェアコンポーネント２１３０へ値を返送する。
【０２０３】
ＡＰＩ実施ソフトウェアコンポーネント２１１０は、ＡＰＩ２１２０を通して指定されず且つＡＰＩコールソフトウェアコンポーネント２１３０に利用できない付加的な機能、方法、クラス、データ構造体、及び／又は他の特徴を含むことが明らかである。ＡＰＩコールソフトウェアコンポーネント２１３０は、ＡＰＩ実施ソフトウェアコンポーネント２１１０と同じシステム上にあってもよいし、又はリモート位置に配置されてネットワーク上のＡＰＩ２１２０を使用してＡＰＩ実施ソフトウェアコンポーネント２１１０にアクセスしてもよい。図２１は、ＡＰＩ２１２０と相互作用する単一のＡＰＩコールソフトウェアコンポーネント２１３０を示すが、ＡＰＩコールソフトウェアコンポーネント２１３０とは異なる言語（又は同じ言語）で書かれた他のＡＰＩコールソフトウェアコンポーネントもＡＰＩ２１２０を使用できることを理解されたい。
【０２０４】
ＡＰＩ実施ソフトウェアコンポーネント２１１０、ＡＰＩ２１２０、及びＡＰＩコールソフトウェアコンポーネント２１３０は、マシン（例えば、コンピュータ又は他のデータ処理システム）により読み取りできる形態で情報を記憶するためのメカニズムを含むマシン読み取り可能な媒体に記憶される。例えば、マシン読み取り可能な媒体は、磁気ディスク、光学的ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置、等を含む。
【０２０５】
図２２（ソフトウェアスタック）の規範的な実施形態において、アプリケーションは、多数のサービスＡＰＩを使用してサービス１又は２へ、及び多数のＯＳ  ＡＰＩを使用してオペレーティングシステム（ＯＳ）へコールを発信する。サービス１及び２は、多数のＯＳ  ＡＰＩを使用してＯＳへコールを発信することができる。
【０２０６】
サービス２は、２つのＡＰＩを有し、その一方（サービス２  ＡＰI１）は、アプリケーション１からコールを受け取ってそこへ値を返送し、そしてその他方（サービス２  ＡＰＩ２）は、アプリケーション２からコールを受け取ってそこへ値を返送する。サービス１（例えば、ソフトウェアライブラリ）は、ＯＳ  ＡＰＩ１へコールを発信しそしてそこから返送値を受け取り、そしてサービス２（例えば、ソフトウェアライブラリ）は、ＯＳＡＰＩ１及びＯＳ  ＡＰＩ２へコールを発信しそしてそこから返送値を受け取る。アプリケーション２は、ＯＳ  ＡＰＩ２へコールを発信し、そしてそこから返送値を受け取る。
【０２０７】
規範的なデータ処理装置
図２３は、本発明の幾つかの実施形態に使用される規範的なコンピュータ装置を示すブロック図である。図２３は、コンピュータシステムの種々のコンポーネントを示すが、その細部は本発明と関わりがないので、コンポーネントを相互接続する特定のアーキテクチャー又は仕方を表わすものではないことを理解されたい。本発明では、コンポーネントがより少ない又はより多い他のコンピュータシステムも使用できることが明らかであろう。
【０２０８】
図２３に示すように、データ処理システムの一形態であるコンピュータシステム２３００は、バス２３５０を備え、このバスは、処理システム２３２０、電源２３２５、メモリ２３３０、及び不揮発性メモリ２３４０（例えば、ハードドライブ、フラッシュメモリ、位相変化メモリ（ＰＣＭ）、等）に結合される。バス２３５０は、この分野で良く知られたように、種々のブリッジ、コントローラ、及び／又はアダプタを通して互いに接続される。処理システム２３２０は、メモリ２３３０及び／又は不揮発性メモリ２３４０からインストラクションを検索し、そしてインストラクションを実行して、上述したオペレーションを遂行する。バス２３５０は、前記コンポーネントを一緒に相互接続すると共に、それらのコンポーネントを、任意のドック２３６０、ディスプレイコントローラ＆ディスプレイ装置２３７０、入力／出力装置２３８０（例えば、ＮＩＣ（ネットワークインターフェイスカード）、カーソルコントロール（例えば、マウス、タッチスクリーン、タッチパッド、等）、キーボード、等）、並びに任意のワイヤレストランシーバ２３９０（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、赤外線、等）に相互接続する。
【０２０９】
図２４は、本発明の幾つかの実施形態に使用される規範的なデータ処理システムを示すブロック図である。例えば、データ処理システム２４００は、ハンドヘルドコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、移動電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、又はハンドヘルドコンピューティング装置であり、このコンピューティング装置は、移動電話、メディアプレーヤ、及び／又はゲームシステムを含む。別の例として、データ処理システム２４００は、ネットワークコンピュータ、又は別の装置に埋め込まれた処理装置である。
【０２１０】
本発明の１つの実施形態によれば、データ処理システム２４００の規範的なアーキテクチャーは、上述した移動装置に使用される。データ処理システム２４００は、１つ以上のマイクロプロセッサ及び／又はシステムを集積回路上に含む処理システム２４２０を備えている。処理システム２４２０は、メモリ２４１０、電源２４２５（１つ以上のバッテリを含む）、オーディオ入力／出力２４４０、ディスプレイコントローラ及びディスプレイ装置２４６０、任意の入力／出力２４５０、入力装置２４７０、及びワイヤレストランシーバ２４３０に結合される。本発明の幾つかの実施形態では、図２４に図示されていない付加的なコンポーネントもデータ処理システム２４００の一部分であり、又、本発明の幾つかの実施形態では、図２４に示すものより少数のコンポーネントが使用されてもよい。更に、この分野で良く知られたように、図２４に示されていない１つ以上のバスを使用して、種々のコンポーネントを相互接続してもよい。
【０２１１】
メモリ２４１０は、データ処理システム２４００によって実行するためのデータ及び／又はプログラムを記憶する。オーディオ入力／出力２４４０は、マイクロホン及び／又はスピーカを備え、例えば、スピーカ及びマイクロホンを通して音楽を再生し、及び／又は電話機能を与える。ディスプレイコントローラ及びディスプレイ装置２４６０は、グラフィックユーザインターフェイス（ＧＵＩ）を含む。ワイヤレス（例えば、ＲＦ）トランシーバ２４３０（例えば、ＷｉＦｉトランシーバ、赤外線トランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバ、ワイヤレスセルラー電話トランシーバ、等）は、他のデータ処理システムと通信するのに使用される。１つ以上の入力装置２４７０は、ユーザがシステムへ入力を与えるのを許す。これら入力装置は、キーパッド、キーボード、タッチパネル、マルチタッチパネル、等である。任意の他の入力／出力２４５０は、ドックのコネクタである。
【０２１２】
異なるサービスプロバイダーにわたりＰ２Ｐ接続を管理する実施形態
本発明の１つの実施形態において、上述したアーキテクチャーは、異なるサービスプロバイダーにおけるピアが、リアルタイムオーディオ、ビデオ、及び／又はチャット接続のようなピア・ツー・ピア（Ｐ２Ｐ）接続を確立できるように拡張される。異なるサービスプロバイダーは、それら自身のプロトコル及びそれら自身のクライアントＩＤネームスペースを利用するので、本発明のこれら実施形態は、装置が、使用されるプロトコルに関わらず相互に動作し、且つネームスペースを単一のグローバルなネームスペースへと一体化できるようにする技術を提供する。
【０２１３】
全てのシステムにおける全てのユーザのグローバルなネームスペースを追跡するためにグローバルなデータベースが維持される。しかしながら、サービスプロバイダーにわたって膨大な数のユーザが分散されると、グローバルなデータベース解決策は、管理が困難となる。或いは又、ユーザ及び／又はデータ処理装置を識別するのに使用されるネーム（例えば、ユーザＩＤ、電話番号）が他の全てのサービスプロバイダーへブロードキャストされて、要求された接続に誰が応答できるか識別してもよい。しかしながら、ここでも、そのようなシステムは、うまく拡張されない（即ち、各試みられた接続に対してブロードキャストメッセージを送信すると、著しい量の帯域巾が消費される）。
【０２１４】
前記問題に対処するために、本発明の１つの実施形態は、接続試み中にブルームフィルタを使用して当該サービスプロバイダーを探索する。この実施形態は、図２５−２６に示すアーキテクチャーについて説明する。４つのサービスプロバイダー、即ちサービスプロバイダーＡ  ２５１０、サービスプロバイダーＢ  ２５１１、サービスプロバイダーＣ  ２５１２、及びサービスプロバイダーＤ  ２５１３が、図２５に示されている。先に述べた実施形態のように、各サービスプロバイダーは、サービスプロバイダーからデータ通信サービスが提供される１組のユーザのユーザＩＤ及び／又は電話番号を含む登録データベース２５２０−２５２３を管理する。一例として、図２５において、ユーザＡ−Ｃ２５０１−２５０３には、サービスプロバイダーＡ  ２５１０からサービスが提供され、そしてユーザＤ−Ｆには、サービスプロバイダーＤ  ２５１３からサービスが提供される。上述したように、１つの実施形態では、登録データベース２５２０−２５２３は、電話番号又はユーザＩＤを各ユーザのデータ処理装置のプッシュトークンへマッピングする。従って、サービスプロバイダーにより維持されるサーバーは、特定サービスプロバイダーのユーザが、上述した技術（例えば、図１０−１４及び当該記載を参照）を使用して、ピア・ツー・ピア接続を探索し互いに確立できるようにする。一例として、サービスプロバイダーにより維持されるサーバーは、ユーザが、フェースタイムＴＭチャット(FaceTimeTMChat)セッション（本特許出願の譲受人により設計された技術）のようなオーディオ／ビデオチャットセッションを互いに確立できるようにする。
【０２１５】
サービスプロバイダー自身のユーザ間にＰ２Ｐ接続を可能にするのに加えて、図２５及び２６に示す実施形態は、異なるサービスプロバイダーのユーザが互いにＰ２Ｐ接続を確立できるようにする。特に、図２６に示すように、各サービスプロバイダーは、サービスプロバイダーの登録データベース２５２０、２５２３に最初に問合せをして、特定のユーザがサービスプロバイダーにより管理されるかどうか決定するためのユーザ位置サービス２６００、２６１０を備えている。（図２６には、簡単化のために２つのサービスプロバイダー（プロバイダーＡ及びＤ）しか示されていない。）ユーザＡ  ２５０１が、同じサービスプロバイダーにより管理される別のユーザ、例えば、ユーザＢ  ２５０２とのＰ２Ｐ接続を要求する場合には、サービスプロバイダーＡのユーザ位置サービス２６００が、登録データベースからユーザＢを識別し、そして接続要求をユーザＢへ送信する（例えば、登録データベース２５２０から検索されたユーザＢのプッシュトークンと共に）。
【０２１６】
しかしながら、ユーザＡが、異なるサービスプロバイダーにより管理されるユーザ、例えば、ユーザＦ  ２５０６とのＰ２Ｐ接続を要求する場合には、サービスプロバイダーＡ２５１０の位置サービス２６００が、他のサービスプロバイダーの各々から受け取られるブルームフィルタ２６０１−２６０３を使用して、異なるサービスプロバイダーにおいてユーザＦを探索するよう試みる。特に、図２６に示すように、各サービスプロバイダーは、登録データベース２５２０、２５２３の現在コンテンツに基づいてブルームフィルタを発生するためのブルームフィルタジェネレータ２６５０、２６５１を備えている。当業者に明らかなように、ブルームフィルタは、あるエレメントが１つの組のメンバーであるかどうかテストするのに使用されるスペース効率の良い確率データ構造体である。偽の肯定が考えられるが、偽の否定はない。ここに示す実施形態では、各ブルームフィルタを発生するのに使用される「エレメント」は、各ユーザのユーザＩＤ及び／又は電話番号である。図２６において、例えば、サービスプロバイダーＡ  ２５１０のブルームフィルタジェネレータ２６５０は、そのユーザＩＤ（Ａｎｄｙ１２４、Ｔｏｍ４５４６、等）を全部使用して、そのブルームフィルタ２６０４を発生する。同様に、サービスプロバイダーＤ  ２５１３のブルームフィルタジェネレータ２６５１は、その登録データベースにおけるユーザＩＤ（Ｗｏｏｄｙ１２３４、Ｒｉｃｋ４５６、等）を全部使用して、そのブルームフィルタ２６０３を発生する。１つの実施形態において、各サービスプロバイダーは、それ自身のブルームフィルタをこのように発生し、そしてそのブルームフィルタを他の全てのサービスプロバイダーへ周期的に送信する。次いで、各サービスプロバイダーは、他のサービスプロバイダーから受け取られたブルームフィルタを使用して、特定のユーザが他のサービスプロバイダーにより管理されるかどうかテストし決定する。
【０２１７】
一例として、図２６において、Ａｎｄｙ１２３のユーザＩＤをもつユーザＡ  ２５０１が、Ｗｏｏｄｙ１２３のユーザＩＤをもつユーザＦ  ２５０６とのＰ２Ｐセッション（例えば、パーソナルオーディオ／ビデオチャット）を確立するよう試みた場合に、サービスプロバイダーＡ  ２５１０のユーザ位置サービス２６００は、最初に、ユーザＦのユーザ名、Ｗｏｏｄｙ１２３をそれ自身の登録データベース２５２０において探索するように試みる。不成功の場合には、１つの実施形態において、他のサービスプロバイダーのブルームフィルタ２６０１−２６０３に問合せし、ユーザＩＤ“Ｗｏｏｄｙ１２３”を管理するサービスプロバイダーを探索するよう試みる。上述したように、ブルームフィルタは、偽の肯定は与えるが、偽の否定は与えない。従って、サービスプロバイダーＡ及びＣがＷｏｏｄｙ１２３を管理しないことをブルームフィルタが指示する場合には、サービスプロバイダーＡは、Ｗｏｏｄｙ１２３がそれらのサービスプロバイダーにより管理されないことを最終的に知る。ここに示す例では、ブルームフィルタ問合せは、Ｗｏｏｄｙ１２３がサービスプロバイダーＤにより管理されることを指示すると共に、Ｗｏｏｄｙ１２３が１つ以上の他のサービスプロバイダーにより管理されることも指示する。従って、１つの実施形態では、サービスプロバイダーＡは、初期メッセージ（例えば、ユーザＦをＰ２Ｐセッションに招待するＩＮＶＩＴＥコマンド）を、このユーザＩＤを潜在的に管理する各サービスプロバイダーへ送信する。このユーザＩＤを実際に管理するサービスプロバイダーは、サービスプロバイダーＡに肯定で応答する。正しいサービスプロバイダーがそれ自身、この例ではサービスプロバイダーＤ、を識別すると、２つのサービスプロバイダーがそれらの各ユーザ（この例ではユーザＡ及びＦ）に対してプロキシーとして働き、そしてユーザ間の通信チャンネルをオープンする。ユーザＡ及びＦは、接続データを交換すると、直接Ｐ２Ｐ通知ンチャンネルを互いにオープンする（例えば、図１１について上述した技術を使用し及び／又は標準的インターネット接続確立（ＩＣＥ）トランザクションを実施して交換を行うことにより）。或いは又、直接Ｐ２Ｐ接続が実現不能である（例えば、ＮＡＴ形式が不適合なために）場合には、ユーザＡ及びＦは、図１３に示したリレーサービス１０５１を使用してリレー接続をオープンする（図１２及びその関連記載も参照）。
【０２１８】
１つの実施形態において、各サービスプロバイダーは、それ自身のブルームフィルタを更新し続けそしてそのブルームフィルタを、Ｐ２Ｐオーディオ／ビデオ接続をサポートするために参加する他のサービスプロバイダーの各々に送信することが期待される。更新は、規則的な間隔で（例えば、１時間に一回、毎日一回、等）、及び／又はある数の新たなユーザＩＤが登録データベースに追加された後に、行われる。本発明の基礎的な原理は、サービスプロバイダー間でブルームフィルタを交換するための特定のメカニズムに限定されない。
【０２１９】
ブルームフィルタを発生し更新する方法の１つの実施形態が図２７に示されている。この方法は、図２５−２６に示されたアーキテクチャーにおいて実行されるが、特定のシステムアーキテクチャーに限定されない。２７０１において、特定のサービスプロバイダーにおけるユーザ登録データベースが更新される。例えば、新たなユーザＩＤ／電話番号が追加され、そして古いユーザＩＤ／電話番号が削除される。２７０２において、完全な１組のユーザＩＤ／電話番号を使用して新たなブルームフィルタが発生される。２７０３において、新たなブルームフィルタが参加サービスプロバイダーへ送信される。
【０２２０】
ブルームフィルタを使用してクライアントのためのサービスプロバイダーを探索する方法の１つの実施形態が図２７に示されている。この方法は、図２５−２６に示されたアーキテクチャーにおいて実行されるが、特定のシステムアーキテクチャーに限定されない。２８０１において、参加サービスプロバイダーのグループのブルームフィルタが受け取られる。ブルームフィルタは、効率的なアクセスのために揮発性メモリに記憶され、及び／又は不揮発性記憶位置に存続される。２８０２において、ユーザ（この例では、ユーザＡ）から接続要求が受け取られて、別のユーザ（ユーザＦ）とのＰ２Ｐ接続が確立される。２８０３において、ユーザＦのユーザＩＤ（例えば、前記例からのＷｏｏｄｙ１２３）に対してブルームフィルタ機能が実行されて、あるサービスプロバイダーを除外する。ブルームフィルタ機能が特定のブルームフィルタに対して否定結果を返送する場合には、ユーザＦは、その特定のブルームフィルタにより管理されない。しかしながら、ブルームフィルタに対して肯定結果が返送される場合には、そのブルームフィルタに関連したサービスプロバイダーがユーザＦを管理する妥当なチャンスがある。１つの肯定結果しか返送されない場合には、２８０４において、そのサービスプロバイダーへ接続インビテーションが送信される。複数の肯定結果が返送される場合には、２８０４において、個別の接続インビテーションが各当該サービスプロバイダーへ送信される。
【０２２１】
次いで、ユーザＦが登録されているサービスプロバイダーが肯定応答し、そして２つのサービスプロバイダーが２８０６においてプロキシーとして働いて、ユーザが、上述したように接続データを交換できるようにする（例えば、プッシュトークン、パブリック／プライベートネットワークアドレス／ポート、ＮＡＴ形式、等）。２つ以上のサービスプロバイダーが肯定応答する場合には（２つのサービスプロバイダーが同じユーザＩＤでユーザをサポートすることを意味する）、正しいユーザを識別するために付加的なステップが取られる（例えば、電話番号、本当の名前、ネットワークアドレス、又は接続を希望するユーザに関して知られている他の情報を比較する）。
【０２２２】
ユーザＦの正しいサービスプロバイダーが識別されそして必要な接続データが交換されると、２８０７において、上述したように、ユーザＡとユーザＦとの間に直接Ｐ２Ｐ接続又はリレー接続（もし必要であれば）が確立される。
【０２２３】
図１１−１２について上述したように、本発明の幾つかの実施形態では、２人（以上）のユーザ間にＰ２Ｐ接続を確立するのに使用される種々のサーバーは、接続プロセス中に接続状態情報を維持する必要がない。これは、例えば、インビテーションサービス１１２及び接続データ交換サービス１１０を含む。むしろ、これらの実施形態では、これに限定されないが、パブリック／プライベートＩＰ及びポート（一般的にネットワーク情報とも称される）、ＮＡＴ形式、ユーザＩＤ、プッシュトークン、等を含む完全な接続情報が、各次々のユーザトランザクションと共に累積されて送信される。図２９に示すように、各トランザクションと共に送信されるマルチプロバイダーコンテキストにおける状態情報の１つの付加的な断片は、プロバイダーＩＤコードである。
【０２２４】
図２９の特定の細部を参照すれば、ユーザＡは、開始要求２９０１（ここでは「インビテーション」要求とも称される）を送信し、これは、それ自身のネットワークＩＤ（ＩＤ−Ａ）、前記技術を使用して決定されたそれ自身のネットワーク情報（例えば、パブリック／プライベートＩＰ／ポートデータ、ＮＡＴ形式、等）、それ自身のプッシュトークン（Ｔｏｋｅｎ−Ａ）、及びＩＤコード、電話番号、及び／又はユーザＦの他の形式の識別子を含む。開始要求は、最初、ユーザＡのサービスプロバイダーにより受け取られ、これは、図２５−２８について上述したいずれかの技術を実施してユーザＦのサービスプロバイダーを探索する（例えば、ブルームフィルタを使用して、あるサービスプロバイダーを除外する）。（ユーザＡ及びユーザＦのサービスプロバイダーは、簡単化のために図２９には示されていない）。
【０２２５】
１つの実施形態において、ユーザＦのサービスプロバイダーが識別されると、開始プッシュ動作２９０２がユーザＦのサービスプロバイダーからユーザＦへ送信され、それは、ユーザＡのサービスプロバイダーの識別子、即ちこの例では「プロバイダーＡ」を含む。プロバイダーＡの識別子は、Ｎビット識別コードのように簡単である（例えば、１６ビット、３２ビット、等）。或いは又、プロバイダーＡの識別子は、プロバイダーＡのネットワークゲートウェイを識別するパブリックＩＰアドレス、又はプロバイダーＤに接続するのに必要な他のネットワークデータを含む。本発明の基礎的な原理は、一連のＰ２Ｐ接続トランザクションでプロバイダーＡを識別するのに使用されるフォーマットに関わらず、同じままである。
【０２２６】
１つの実施形態において、プッシュトランザクション２９０２は、上述したプッシュ通知サービス１０５０のようなプッシュ通知サービスによって発生される（例えば、図１１及びその関連記載を参照）。上述したように、ユーザＡにより与えられるオリジナル状態情報及びサービスプロバイダーＡのサーバーにより収集される付加的な状態情報は、全て、開始プッシュトランザクション２９０２に含まれる。
【０２２７】
図２９に示す例では、ユーザＦは、以前の全状態情報（ＩＤ−Ａ、ＮｅｔＩｎｆｏ−Ａ、プロバイダーＡ）を、Ｐ２Ｐ接続を確立するのに必要なユーザＦの情報と共に含む受け容れトランザクション２９０３で応答し、そのユーザＦの情報は、例えば、これに限定されないが、ユーザＦのＩＤ、（ＩＤ−Ｆ）、ユーザＦのネットワーク情報（ＮｅｔＩｎｆｏ−Ｆ；これは、パブリック／プライベートＩＰアドレス／ポート、ＮＡＴ形式、等を含む）、及びユーザＦのトークン（トークンＦ）を含む。ユーザＡ及びユーザＦの接続状態情報は、全て、ユーザＦのサービスプロバイダー（この例では、「プロバイダーＤ」）によって受信され、このサービスプロバイダーは、それ自身のプロバイダーＩＤコードをトランザクション（プロバイダーＤ）に取り付け、そしてそれをユーザＡのサービスプロバイダーへ転送する。プロバイダーＡについて上述したように、プロバイダーＤの識別子は、Ｎビット識別コードのように簡単である。或いは又、プロバイダーＤの識別子は、プロバイダーＤのネットワークゲートウェイを識別するパブリックＩＰアドレス、又はプロバイダーＤに接続するために必要な他のネットワークデータを含んでもよい。本発明の基礎的な原理は、Ｐ２Ｐ接続トランザクション内でプロバイダーＤを識別するのに使用されるフォーマットに関わらず、同じままである。
【０２２８】
全ての接続状態データがユーザＡにより受信されると（プロバイダーＤのデータを含む）、ユーザＡ及びユーザＦは、トランザクション２９０５により指示されたように、上述した技術を使用してＰ２Ｐ接続を確立する。
【０２２９】
上述したように、ある条件のもとでは、ユーザＡ及びユーザＦは、直接Ｐ２Ｐ接続ではなく、リレーサービス１０５１（例えば、図１０を参照）を通して接続を確立することが必要である。図３０に示すように、１つの実施形態において、両サービスプロバイダーＡ及びＦは、それら自身のリレーサービス３００１−３００２を使用する（及び／又は第三者のリレーサービスとの関係を有する）。１つの実施形態において、ユーザＡとユーザＦとの間に試みたＰ２Ｐ接続が失敗すると、接続をサポートするためにサービスプロバイダーＡのリレーサービス３００１（即ち、Ｐ２Ｐ接続を開始するユーザのプロバイダー）が使用される。別の実施形態では、接続をサポートするためにユーザＦのリレーサービス３００２（即ち、接続を要求しているユーザのプロバイダー）が使用される（図３１においてユーザＡ  ２５０１と、リレーサービス３００２と、ユーザＦ  ２５０６との間の点線で示す）。更に別の実施形態では、全てのプロバイダーが単一のリレーサービスに合意し、そしてそのリレーサービスを利用して、ユーザ間にＰ２Ｐ接続を確立する。
【０２３０】
本発明の１つの実施形態は、ユーザ装置間にセキュアなオーディオ／ビデオＰ２Ｐ通信をサポートするために種々の異なる通信プロトコルを結合する。これらのプロトコルは、（これに限定されないが）Ｐ２Ｐ接続を経てセキュアな通信を与えるためのデータグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）；ユニキャスト（装置対装置）及びマルチキャスト（装置対複数装置）の両アプリケーションのためのＲＴＰデータに暗号化、メッセージ認証及び完全性、再生保護を与えることが意図されたＲＴＰ（リアルタイムトランスポートプロトコル）を定義するセキュアなリアルタイムトランスポートプロトコル（又はＳＲＴＰ）；及びユーザ装置間にボイス／ビデオ接続を確立するセッションイニシエーションプロトコル（ＳＩＰ）を含む。これらのプロトコルは、ここに述べる本発明のいずれの実施形態のコンテキスト内に使用されてもよい。
【０２３１】
１つの実施形態において、図２５に示すオープンのプロバイダー間ネットワークにおける各装置は、アイデンティティの検証、及びＳＴＲＰを使用するストリームの端−端暗号化の目的で、他の装置に対してセキュアに識別することができる。セキュアな通信を可能にするために各サービスプロバイダーにより発生する必要のある証明書フォーマットについて以下に述べる。
【０２３２】
１つの実施形態において、各プロバイダーは、他のピアプロバイダーをどのようにして発見するか知る必要がある。１つの実施形態において、コールルーティング及びピア情報について質問するためにグローバルで且つセキュアなプロバイダーリストがある。これは、信頼性のあるサーバーのリスト及びそれらのアドレス情報である。プロバイダーの１つがこのサービスをホストする。
【０２３３】
プロバイダー間の接続を有効で且つ信頼できるものにするためにプロバイダー間に必要とされるセキュリティ及び認証のレベルについて以下に述べる。これは、プロバイダーとグローバルルックアップデータベースとの間に使用されるもの及びＰ２Ｐ接続を認証するのに使用されるものとは異なる１組のクレデンシャルである。
【０２３４】
１つの実施形態において、コールルーティング時間に、受信者のプロバイダー（即ち、被呼ユーザ）は、エンドポイント間のＰ２Ｐ接続を認証するのに使用されるピア証明書を発呼者に返送する。この証明書は、外部エンティティにより署名することができ、そして証明書の要件は、ｅ−メールだけでなく、任意の形式のアイデンティティを許す。
【０２３５】
更に、１つの実施形態において、オーディオ、ビデオ及びシグナリングデータは、単一のデータポートを経て各データ処理装置において一緒にマルチプレクスされる。次いで、オーディオ、ビデオ及びシグナリングデータは、行先装置においてデマルチプレクスされデコードされる。
【０２３６】
図２５に示すプロバイダー間ネットワークは、多数の相互動作レイヤより成る。これらレイヤの相互作用は、種々のプロトコルにより指定される。この相互作用の目標は、接続を確立するユーザの要求を処理して、ユーザエンドポイント（図２５にユーザＡ−Ｆ２５０１−２５０６として識別された）間に必要とされる情報交換を遂行し、それらがオーディオ／ビデオコールセッションを確立できるようにすることである。
【０２３７】
動作中に、図２５に示すプロバイダー間ネットワークは、要求を発信し及びそれに応答するように互いに通信する１組のサーバーとして実施される。それらの要求は、ユーザエンドポイントがメディアチャンネル接続データを交換してオーディオ／ビデオコールセッションを形成できるように要求を転送するのに必要なプロトコルアクションである。１つの実施形態では、各サービスプロバイダーは、そのユーザエンドポイントとの全ての直接通信を管理する。
【０２３８】
１つの実施形態において、ユーザエンドポイントは、エンドポイントをコントロールする当事者を識別するユニフォームリソース識別子（ＵＲＩ）を経て表わされる。最初にサポートされるＵＲＩスキームは、ｔｅｌ：（電話番号用）及びｍａｉｌｔｏ：（メールアドレス用）である。他のＵＲＩスキームも将来サポートされる。
【０２３９】
１つの実施形態において、各ユーザエンドポイントへのＵＲＩのマッピングは、アイデンティティマッピングではなく、多数対多数関係である。単一のＵＲＩは、多数のエンドポイントへマップし、そして単一のエンドポイントは、多数のＵＲＩへマップされる。更に、ＵＲＩ対エンドポイントのマッピングは、多数のプロバイダーに広がる。例えば、プロバイダーＡには１つのエンドポイントがあり、プロバイダーＢには異なるエンドポイントがあり、それら両方のエンドポイントは、同じＵＲＩによりマップされる。（しかしながら、１つの実施形態では、エンドポイントは、一度に１つのプロバイダーによってホストされるだけである。）１つの実施形態において、エンドポイントＵＲＩは、電話番号やｅ−メールアドレスのようなジェネリックなユーザレベル識別子である。それらをプロバイダー及びエンドポイントへマッピングさせることは、システムにより遂行され、エンドユーザにとって透過的である。
【０２４０】
１つの実施形態において、図２５に示すプロバイダー間通信に使用されるメタプロトコルは、ＨＴＴＰを経てのディクショナリーである。この実施形態では、全てのアクションがＨＴＴＰ  ＧＥＴ又はＰＯＳＴとして遂行される。アクションがＨＴＴＰ  ＧＥＴとして指定される場合には、ボディーが空となる。アクションがＨＴＴＰ  ＰＯＳＴとして指定される場合には、ボディーは、ディクショナリーとしてエンコードされた要求パラメータを含む。応答は、ディクショナリーとしてエンコードされた応答パラメータを含むボディーを有する。１つの実施形態において、ディクショナリーの初期エンコーディングは、「アップルＸＭＬプロパティリスト」である。ＪＳＯＮ又はプロトコルバッファのような他のエンコーディングも使用される。１つの実施形態では、異なるサービスプロバイダーが任意の１組のプロトコル又は通信メカニズムを使用して個々のユーザ装置と通信する。
【０２４１】
１つの実施形態において、図２５に示すサービスプロバイダーが互いに発見できるようにするためにプロバイダー発見プロトコルが使用される。１つの実施形態において、ネットワークの管理エンティティ（例えば、一次又は管理サービスプロバイダー）によりブートストラップＵＲＩが発行される。このブートストラップＵＲＩは、このネットワークの受け容れられたメンバーである１組のプロバイダーを含む発見ディクショナリーを指す。各サービスプロバイダーに対して、このディクショナリーは、識別情報、及びこのプロバイダーとどのように通信するか指定する更なるＵＲＩを含む。１つの実施形態において、サービスプロバイダーは、それが始動するとき、及びその後は周期的に、発見ディクショナリーを検索する。次いで、それらプロバイダーは、ディクショナリーの情報に基づいて他のプロバイダーと通信するようにそれ自身を構成する。
【０２４２】
ユーザ間にＰ２Ｐ通信セッションを確立するための特定の１組のプロトコルの細部について以下に説明する。しかしながら、これらの特定の細部は、特定の実施形態を表わすに過ぎず、本発明の基礎的な原理に合致するために必要とされるものではないことに注意されたい。
【０２４３】
１．インビテーションプロトコル
初期コール設定のために１つの実施形態のインビテーションプロトコルが使用される。これは、ビデオコールセッションのメディアチャンネルを確立するのに使用されるメディアチャンネル接続データを交換するためにユーザエンドポイント（例えば、図２５におけるユーザエンドポイント２５０１−２５０６）により使用されるアウト・オブ・バンドシグナリングである。
【０２４４】
１．１．アクション
インビテーションプロトコルには、４つの主たるアクションがある。
【０２４５】
１．１．１．開始
コールをスタートするための開始側エンドポイントにより送信。フィールド：セッション−ｉｄ、自己−ｕｒｉ、自己−トークン、自己−ブロブ、ピア−ｕｒｉ。
【０２４６】
１．１．２．受け容れ
コールに参加する意思があることを指示するために受信側エンドポイントにより送信。
【０２４７】
フィールド：セッション−ｉｄ、自己−ｕｒｉ、自己−トークン、自己−ブロブ、ピア−ｕｒｉ、ピア−トークン、ピア−ブロブ。
【０２４８】
１．１．３．拒絶
コールに参加する意思がないことを指示するために受信側エンドポイントにより送信。フィールド：セッション−ｉｄ、自己−ｕｒｉ、自己−トークン、自己−ブロブ、ピア−ｕｒｉ、ピア−トークン、ピア−ブロブ。
【０２４９】
１．１．４．キャンセル
コールを終了すべきであることを指示するためいずれかのエンドポイントにより送信。フィールド：セッション−ｉｄ、自己−ｕｒｉ、自己−トークン、自己−ブロブ、ピア−ｕｒｉ、ピア−トークン、ピア−ブロブ。
【０２５０】
１．２．アクション変化
アクションに作用する当事者に基づき、３つの形態をとる。
＊要求（エンドポイントからプロバイダー）
＊転送（プロバイダーからプロバイダー）
＊プッシュ（プロバイダーからエンドポイント）
【０２５１】
１．３．コールフロー
１．３．１．ユーザエントリ
エンドポイントは、接続を確立したいとき、ＵＲＩが受信側エンドポイントを識別することを必要とする。このＵＲＩは、おそらく、ユーザにより与えられたある情報、例えば、ダイヤルした電話番号、又はアドレス帳に記憶されたｅ−メールアドレスから導出される。次いで、エンドポイントは、そのホスティングプロバイダーにおける「開始要求」にコールする。
【０２５２】
１．３．２．開始要求
開始側プロバイダーは、ＵＲＩを見て、そのＵＲＩによりマップされたエンドポイントをホストする受信側プロバイダーのセットを決定する。（プロバイダーのこのセットは、開始側プロバイダーそれ自身を含む。）次いで、全ての適用可能な受信側プロバイダーにおける「開始転送」をコールする。
【０２５３】
１．３．３．開始転送
各受信側プロバイダーは、受信側エンドポイントを決定し、それに「開始プッシュ」を送信する。
【０２５４】
１．３．４．開始プッシュ
受信側エンドポイントは、「開始プッシュ」を得て、ユーザに情報を提示する。（これは、典型的に、「ＸＸＸがコールしている」のラインに沿ったＵＩである。）ユーザがコールを受ける決心をすると、エンドポイントは、「受け容れ要求」をコールする。（さもなければ、「拒絶要求」をコールする。）
【０２５５】
１．３．５．受け容れ要求
受信側エンドポイントは、そのホストプロバイダーにおいて「受け容れ要求」をコールする。
【０２５６】
１．３．６．受け容れ転送
受信側プロバイダーは、開始側エンドポイントに「受け容れプッシュ」を送信する。
【０２５７】
１．３．７．受け容れプッシュ
開始側エンドポイントは、「受け容れプッシュ」を得、接続を形成して進むことをユーザに指示する。この点において、両エンドポイントは、メディアチャンネル接続データを交換しており、従って、オーディオ／ビデオコールセッションに対してメディアチャンネルを確立する準備ができる。ここから、（以下の）「メディアセッションマネージメント」で文書化されたように、流れは「メディアチャンネル確立」と続く。
【０２５８】
２．ディスパッチ最適化プロトコル
前記で詳細に述べたように、１つの実施形態において、開始コール要求に応答できる候補サービスプロバイダーを選択するためにブルームフィルタが使用される。１つの実施形態において、プロバイダーは、それらが現在ホストするエンドポイントの全てのＵＲＩを表わす最新のブルームフィルタを維持することが要求される。全てのプロバイダーに対するブルームフィルタは、インクリメント形態で他の全てのプロバイダーへ配布される。
【０２５９】
ディスパッチ最適化プロトコル：オリジナルコールをディスパッチするとき、プロバイダーは、先ず、他の全てのプロバイダーのブルームフィルタを調査する。そこから、プロバイダーは、実際上コールに応対できるプロバイダーの候補セットを得る。次いで、その候補セットだけに開始アクションが送られる。
【０２６０】
３．メディアセッションマネージメント
メディアセッションマネージメントは、メディアチャンネル及びそのメディアチャンネル上に延びるメディアストリームのセットアップ、コントロール及びティアダウンを指す。メディアセッションマネージメントは、次の章で詳細に述べる。
【０２６１】
４．メディアチャンネル確立
メディアシグナリング、メディアフロー、及びセッションティアダウンのためのネットワークパケットがメディアチャンネルを経て送信される。メディアチャンネルは、ＮＡＴ横断又はリレー構成（前記で詳細に述べた）を通して確立される。ＮＡＴ横断及びリレー構成は、両方とも、各エンドポイントが両エンドポイントのメディアチャンネル接続データを所有することを要求する。
【０２６２】
４．１．ＮＡＴ横断プロトコル
１つの実施形態において、ＮＡＴ横断プロトコルは、直接ピア・ツー・ピア接続を経てメディアチャンネルを確立するのに使用される。これは、「双方向接続確立」（ＩＣＥ）［ＲＦＣ  ５２４５］でカバーされる技術の利用を含む。
【０２６３】
４．２．リレー構成プロトコル
１つの実施形態において、リレープロトコルは、リレーネットワークを経てメディアチャンネルを確立するのに使用される。又、これは、１つの実施形態では、ＴＵＲＮ［ＲＦＣ  ５７６１］の使用を含む。
【０２６４】
５．メディアチャンネルシグナリング
メディアシグナリングは、メディアネゴシエーション及びメディア暗号化のためのセキュリティのセットアップ、並びにオーディオ及びビデオパラメータのためのメディアネゴシエーションをカバーする。
【０２６５】
５．１．セキュリティのセットアップ
上述したように、１つの実施形態において、「データグラムトランスポートレイヤセキュリティ」（ＤＴＬＳ）［ＲＦＣ  ４３４７］を使用して、メディアチャンネルを経てのネットワークトラフィックの通信をセキュアなものにする。ＤＴＬＳプロトコルは、ユーザ間に送信されたボイス／ビデオパケット内の暗号化されたコンテンツにサービスプロバイダーがアクセスできないように端−端暗号化を与えるよう実施される。
【０２６６】
５．２．メディアネゴシエーション
１つの実施形態において、ＳＩＰ［ＲＦＣ  ３２６１］は、ビデオコーリングセッションのオーディオ及びビデオパラメータをネゴシエーションするのに使用される。
【０２６７】
５．３．オーディオ及びビデオ暗号化
１つの実施形態において、ＳＲＴＰ［ＲＦＣ  ３７１１］は、オーディオ及びビデオペイロードを暗号化するのに使用される。
【０２６８】
６．メディアフローコントロール
メディアフローコントロールは、アクティブなメディアストリームの管理、及びメディアチャンネルを経てのメディア状態変化の通知をカバーする。
【０２６９】
６．１．ネットワーク適応
１つの実施形態において、ネットワーク適応技術は、通信チャンネルの変動を考慮するために実施される。特に、ユーザのエンドポイントは、オーディオ及び／又はビデオビットレートのようなストリームパラメータを調整して、スループットの変化、パケットロス及びレイテンシーのような変化するネットワーク状態に適応させる。
【０２７０】
６．２．ビデオミューティング
ビデオを送信するエンドポイントは、ビデオをミュート／アンミュートする。ＳＩＰ  ＭＥＳＳＡＧＥを使用してリモートエンドポイントに通知が送信される。
【０２７１】
６．３．ビデオの向き
ビデオを送信するエンドポイントは、ビデオの向きを変更する。ＲＴＰヘッダ拡張情報を使用してリモートエンドポイントへ通知が送られる。
【０２７２】
６．４．ビデオスイッチング
ビデオを送信するエンドポイントは、ビデオのソースをスイッチする。例えば、前方を向いたカメラ及び後方を向いたカメラの両方を含むユーザ装置では、ビデオは、前向きから後ろ向きにスイッチする。ＲＴＰヘッダ拡張情報を使用してリモートエンドポイントへ通知が送られる。
【０２７３】
６．５．ハングアップ
１つの実施形態において、エンドポイントは、ＳＩＰ  ＢＹＥメッセージを送信することによりアクティブなセッションを明確に終了させることができる。
【０２７４】
７．メディアチャンネルティアダウン
メディアセッションは、明示的又は暗示的にティアダウンされる。メディアチャンネルの明示的ティアダウンは、ＳＩＰ  ＢＹＥメッセージを送信又は受信することにより行われる。暗示的ティアダウンは、ネットワーク接続ロス又は不充分なネットワーク性能のために生じる。
【０２７５】
８．セキュリティ
８．１．証明書
１つの実施形態において、図２５に示すプロバイダー間システムのエンドポイント間の通信は、パブリックキー暗号化を使用してセキュアなものとされる。各エンティティ（プロバイダー及びエンドポイント）は、アイデンティティを署名する信頼できるＣＡにより発行された証明書を有する。この証明書は、エンティティに属するＵＲＩ、及び他の識別情報を含む。証明書は、通信時にエンティティのアイデンティティを検証するために相手の当事者により使用される。
【０２７６】
８．２．メディアチャンネルシグナリング
ＳＩＰメッセージは、ＤＴＬＳ［ＲＦＣ  ４３４７］を使用してセキュアなものとされる。
【０２７７】
８．３．アーでぃオ及びビデオ
オーディオ及びビデオストリームは、ＳＲＴＰ［ＲＦＣ  ３７１１］を使用してセキュアなものとされる。
【０２７８】
９．エンコーディング
９．１．オーディオ
９．１．１．オーディオコーディック
オーディオコーディックは、ＭＰＥＧ−４  改善型低遅延(Enhanced Low Delay)ＡＡＣ（ＡＡＣ−ＥＬＤ、ＩＳＯ／ＩＥＣ  １４４９６−３）に準拠する。
【０２７９】
９．１．２．オーディオクオリティ
１つの実施形態では、オーディオ信号音響特性が、ワイドバンド電話ターミナルのための３ＤＰＰ仕様書ＴＳ２６．１３１及びＴＳ２６．１３２によって指定される。
【０２８０】
９．１．２．オーディオＲＴＰペイロードフォーマット
９．２．ビデオ
１つの実施形態において、シーケンスパラメータセット（ＳＰＳ）及びピクチャーパラメータセット（ＰＰＳ）ＮＡＬＵは、ビデオストリーム記述をビットストリームにおいて搬送するのに使用される。
【０２８１】
９．２．１．ビデオコーデック
１つの実施形態において、図２５のユーザ間で通信するのに使用されるビデオコーデックは、ｂフレームなしのＨ．２６４高プロフィール、レベル１．２（実際には、ＱＶＧＡ１５ｆｐｓ、最大３００ｋｂｐｓ）である。しかしながら、本発明の基礎的な原理は、特定のオーディオ／ビデオフォーマットに限定されないことに注意されたい。
【０２８２】
９．２．２．ビデオＲＴＰペイロードフォーマット
上述したように、リアルタイムトランスポートプロトコル（ＲＴＰ）は、ユーザエンドポイント間のオーディオ／ビデオ通信をサポートするのに使用される。図３２に示すように、１つの実施形態では、ＲＦＣ  ３９８４ヘッダ３２０２（即ち、ＲＦＣ  ３９８４、Ｈ．２６４ビデオのためのＲＴＰペイロードフォーマットにより定義された）は、（ＲＴＰデータパケットを含む）各１２バイトＲＴＰペイロード３２０１に添付される。ヘッダは、Ｈ．２６４画像記述拡張を使用してＲＴＰデータをどのようにパケット化するか指定する。
【０２８３】
本発明の実施形態は、上述した種々のステップを含む。それらのステップは、汎用又は特殊目的プロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションにおいて実施される。或いは又、それらのステップは、それらのステップを遂行するためのハードワイヤードロジックを含む特定のハードウェアコンポーネントによって遂行されてもよいし、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの組み合わせにより遂行されてもよい。
【０２８４】
又、本発明の要素は、マシン実行可能なプログラムコードを記憶するためのマシン読み取り可能な媒体としても提供される。マシン読み取り可能な媒体は、これに限定されないが、フロッピーディスケット、光学的ディスク、ＣＤ−ＲＯＭ、磁気−光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、或いは電子プログラムコードを記憶するのに適した他の形式の媒体／マシン読み取り可能な媒体を含む。
【０２８５】
以上の記載全体にわたり、説明上、本発明を完全に理解するために多数の特定の細部について述べた。しかしながら、当業者であれば、それら特定の細部の幾つかがなくても、本発明を実施できることが明らかであろう。例えば、当業者であれば、ここに述べる機能的モジュール及び方法は、ソフトウェア、ハードウェア又はその組み合わせとして実施できることが容易に明らかであろう。更に、本発明の実施形態は、移動コンピューティング環境に関して（即ち、移動装置１２０−１２３；６０１−６０３を使用して）説明したが、本発明の基礎的な原理は、移動コンピューティング実施形態に限定されない。実際上、例えば、デスクトップ又はワークステーションコンピュータを含む幾つかの実施形態において、任意の形式のクライアント又はピアデータ処理装置を使用することができる。従って、本発明の範囲及び精神は、特許請求の範囲に関して判断されるべきである。
【符号の説明】
【０２８６】
１００：データサービス
１１０：接続データ交換（ＣＤＸ）サービス
１１１：マッチメーカーサービス
１１２：インビテーションサービス
１２０：ネットワーク
１２０−１２３：移動コンピューティング装置Ａ−Ｄ
１２５−１２８：リンク
２０４ａ：チケット
３０１：セッションＩＤ
３０２：参加者No.
３０３：インデックス
３０４：満了時間／日付
３０５：ＣＤＸホール・パンチＡ
３０６：ＣＤＸホール・パンチＢ
３０７：メッセージ認証コード
６０１：装置Ａ
６０３：装置Ｃ
６０５：通信リンク
６０６：通信リンク
６０７：通信リンク
６０８：通信リンク
６０９：通信リンク
６１０：通信リンク
６１０：ネットワーク
６１１、６１２、６１３、６１４：ＮＡＴ
６２０：プライベートネットワーク
７０１、７０２：インターフェイス
７０５：欠陥検出
７０６：リンクマネージメント
７１０：一次／二次接続データ
８０１、８０２：一次チャンネル
１０５０：プッシュ通知サービス
１０５１：リレーサービス
１０５２：登録／ディレクトリサービス
１３０１：リレーホストＤＢ
１３０２：リレーホストＡ
１３０３：リレーホストＢ
１４００：ＮＡＴ適合性チャート
１５０１：マッチメーカーディスパッチャー
１５０２：要求テーブル
１５０３：ＭＳＩテーブル
１５１０：マッチメーカー
１５１２：データベース
【図１】
0005711849.tif 000005
【図２ａ】
0005711849.tif 000006
【図２ｂ】
0005711849.tif 000007
【図２ｃ】
0005711849.tif 000008
【図３】
0005711849.tif 000009
【図４】
0005711849.tif 000010
【図５】
0005711849.tif 000011
【図６】
0005711849.tif 000012
【図７】
0005711849.tif 000013
【図８ａ】
0005711849.tif 000014
【図８ｂ】
0005711849.tif 000015
【図９】
0005711849.tif 000016
【図１０】
0005711849.tif 000017
【図１１】
0005711849.tif 000018
【図１２】
0005711849.tif 000019
【図１３】
0005711849.tif 000020
【図１４】
0005711849.tif 000021
【図１５】
0005711849.tif 000022
【図１６】
0005711849.tif 000023
【図１７ａ】
0005711849.tif 000024
【図１７ｂ】
0005711849.tif 000025
【図１７ｃ】
0005711849.tif 000026
【図１７ｄ】
0005711849.tif 000027
【図１８】
0005711849.tif 000028
【図１９】
0005711849.tif 000029
【図２０】
0005711849.tif 000030
【図２１】
0005711849.tif 000031
【図２２】
0005711849.tif 000032
【図２３】
0005711849.tif 000033
【図２４】
0005711849.tif 000034
【図２５】
0005711849.tif 000035
【図２６】
0005711849.tif 000036
【図２７】
0005711849.tif 000037
【図２８】
0005711849.tif 000038
【図２９】
0005711849.tif 000039
【図３０】
0005711849.tif 000040
【図３１】
0005711849.tif 000041
【図３２】
0005711849.tif 000042