JP5543663B2 - ユーザをオンラインセッションにマッチングさせるための装置及び方法 - Google Patents

Description

（関連出願）
本出願は、２０１０年月７日出願の米国仮出願番号６１／３２１，８４２「ユーザをオンラインセッションにマッチングするための装置及び方法」の優先権を主張するものである。

本出願に開示され請求項に記載される発明は、時期早々でＡｐｐｌｅ社の許可なく２０１０年３月２５日にＡｐｐｌｅ社の技術者がＡｐｐｌｅ社のｉＰｈｏｎｅ４の試作品を明白に盗難した時に公知になった。本出願が基礎とする米国優先権出願は、明白な盗難の前には出願されていない。

（技術分野）
本発明は、全体的にはコンピュータネットワークの分野に関する。詳細には、本発明は、モバイル装置等のコンピュータ装置のユーザをオンライン通信セッション（例えば、ピアツーピアセッション）にマッチングさせるための改良された装置及び方法に関する。

Ａ．ネットワークアドレス交換（ＮＡＴ）
インターネット等の大規模パブリックネットワークは、企業、インターネットサービスプロバイダ、又は個別の家庭でメンテナンスされるような小規模のプライベートネットワークと頻繁に接続する必要がある。本質的に、パブリックネットワークは、共通に取り決められたネットワークアドレス、つまりパブリックアドレスの割り当てをもつ必要がある。種々の理由から、プライベートネットワークのメンテナンスは、共通に取り決められた割り当ての一部ではない、プライベートネットワーク用のプライベートネットワークアドレスの使用を選択する場合が多い。つまり、プライベートネットワークからパブリックネットワークを横切ることになるネットワークトラフィックに関して、何らかの形のプライベート／パブリックネットワークアドレス交換（ＮＡＴ）が必要である。

ＮＡＴ動作を行うデバイスは、パブリックネットワークのアドレス方式に適合するようにプライベートネットワークから送信されるデータパケットを変更する。特に、ネットワークアドレス変換器は、パケットの送信側プライベートアドレス及びポート番号を、独自のパブリックアドレス及び割り当てられたポート番号に置き換える。また、ネットワークアドレス変換器は、プライベートネットワークでコンピュータが受信するデータパケットに変更して、宛先パブリックアドレス及びポート番号を、対象とする受信者の正しいプライベートアドレス及びポート番号に置き換えるようになっている。本明細書で使用する場合、用語「アドレス」は、当業者であれば理解できるように、適切な場合はアドレス及びポート番号を含むと解釈すべきである。

ＮＡＴは、最新のネットワークコンピューティングではますます一般的になっている。ＮＡＴの１つの利点は、パブリックネットワークアドレス空間の枯渇を遅くする点にある。例えば、インターネットで使用するＴＣＰ／ＩＰアドレッシングは、各々３桁の４つの列から構成されるのでの有限アドレス空間をもたらす。更に、このアドレス空間の特定の部分は、特定の用途又はユーザに確保されており、利用できる実際のアドレス数は更に使い尽くされる。しかしながら、ＮＡＴを使用すると、プライベートネットワーク又はサブネットは、任意数のアドレスを使用でき、依然として外部世界に対して単一の標準パブリックアドレスを提示する。これにより、各プライベートネットワークは、理論的に全く同じプライベートアドレスを使用できるので利用可能なアドレス数は実質的に無限になる。

ＮＡＴが提供する１つの利点は、パブリックネットワーク上ではプライベートネットワーク上のコンピュータの実際の（つまり、プライベート）ネットワークアドレスを特定できないことに起因する高いセキュリティである。これは、パブリックアドレスだけがネットワークアドレス変換器によってパブリックネットワーク上に供給されるからである。更に、このパブリックアドレスは、プライベートネットワーク上の多くのコンピュータに対応することができる。

異なるＮＡＴ対応は、異なるレベルのセキュリティを使用する。例えば、「ｆｕｌｌ ｃｏｎｅ ＮＡＴ」に関して、内部アドレス（ｉＡｄｄｒ：ｉＰｏｒｔ）が外部アドレス（ｅＡｄｄｒ：ｅＰｏｒｔ）に対応付けされると、いずれかの外部ホストは、パケットをｅＡｄｄｒ：ｅポートに送信することで、パケットをｉＡｄｄｒ：ｉポートに送信できる。「ｒｅｓｔｒｉｃｔｅｄ ｃｏｎｅ ＮＡＴ」に関して、アドレスｈＡｄｄｒの外部ホストは、ｉＡｄｄｒ：ｉポートが以前にパケットをｈＡｄｄｒに送信している場合にだけ、パケットをｅＡｄｄｒ：ｅポートに送信することで、パケットをｉＡｄｄｒ：ｉポートに送信することができる。外部ホストのポートは無関係である。「ポート Ｒｅｓｔｒｉｃｔｅｄ Ｃｏｎｅ ＮＡＴ」に関して、アドレス／ポートｈＡｄｄｒ：ｈポートを有する外部ホストは、ｉＡｄｄｒ：ｉポートが以前にパケットをｈＡｄｄｒ：ｈＰｏｒｔに送信している場合にだけ、パケットをｅＡｄｄｒ：ｅポートに送信することで、パケットをｉＡｄｄｒ：ｉポートに送信することができる。最後に、Ｓｙｍｍｅｔｒｉｃ ＮＡＴに関して、同じｉＡｄｄｒ：ｉポートから特定の宛先ＩＰアドレス及びポートへの各々のリクエストは、固有のｅＡｄｄｒ：ｅＰｏｒｔに対応付けされる。同じ内部ホストがパケットを異なる宛先に送信する場合、異なる部アドレス及びポートマッピングを使用できる。内部ホストからパケットを受信した外部ホストだけがパケットを内部ホストに返信することができる。

Ｂ．ＮＡＴのピアツーピアネットワークの問題
ピアツーピア（Ｐ２Ｐ）コンピューティングは、リソースの一部を他のネットワーク参加者が直接利用できるようにするコンピュータノードを備える分散ネットワークアーキテクチャを呼ぶ。サーバがリソースを供給してクライアントがリソースを消費する従来のクライアント−サーバモデルと対照的に、Ｐ２Ｐネットワークのピアは、相互間の直接的な通信チャンネルを設定し、クライアント及びサーバの機能を果たす。

前述のＮＡＴ動作は、Ｐ２Ｐ接続に関する複数の問題を提起する。例えば、ピアの一方又は両方が前述のタイプの１つ又はそれ以上のＮＡＴの背後に配置される場合、２つのピア間で直接的な接続を確立することは非常に難しくなる。この問題は、Ａｐｐｌｅ ｉＰｏｄ Ｔｏｕｃｈ（登録商標）、Ａｐｐｌｅ ｉＰｈｏｎｅ（登録商標）、Ａｐｐｌｅ ｉＰａｄ（登録商標）、及び種々の他のデバイス（例えば、ＲＩＭ Ｂｌａｃｋｂｅｒｒｙ（登録商標）デバイス、Ｐａｌｍ Ｐｒｅ（登録商標）デバイス）等のモバイル装置が、異なるＮＡＴ実装のネットワーク間を頻繁に移動するという現実によって悪化する。例えば、Ａｐｐｌｅ ｉＰｈｏｎｅ（商標）は、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ，ｇ，ｎネットワーク）、３Ｇネットワーク（例えば、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅ通信ｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）ネットワーク、Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐリンク Ｐａｃｋｅｔ Ａｃｃｅｓｓ（ＨＳＵＰＡ） ネットワーク等）、及びＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク（パーソナルエリアネットワーク（ＰＡＮ））で通信できる。他のモバイル装置は、ＷｉＭＡＸ、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅ通信（ＩＭＴ）Ａｄｖａｎｃｅｄ、及びＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）Ａｄｖａｎｃｅ等の追加の通信チャンネルで通信できるであろう。

ピアツーピア（Ｐ２Ｐ）通信チャンネルを確立するための装置、方法、及びコンピュータ可読媒体を説明する。詳細には、１つの実施形態において、マッチングサービスは、一連の動作を実行してモバイル装置のグループから受信したマッチリクエストをサービスするようになっている。１つの実施形態において、マッチングサービスは、リクエストを受信したアプリケーション及び該アプリケーションに関する１つ又はそれ以上の変数に基づいてマッチリクエストをマッチ可能なセットにグループ化する。各マッチセット内のマッチリクエストは、各モバイル装置に関連するＮＡＴタイプ、接続タイプ、及び言語に基づいてマッチさせることができる。また、地理的位置、経験レベル、及びマッチリクエストの経時等の他の変数は、マッチ判定を行うために使用することができる。

本発明は、添付図面と併せて以下の詳細な説明から十分に理解することができる。

モバイル装置及びサービスのグループがネットワーク上で通信するネットワークアーキテクチャを示す。 接続データ交換（ＣＤＸ）サービス、仲介サービス、及び／又は招待サービスの間のトランザクションを示す。 接続データ交換（ＣＤＸ）サービス、仲介サービス、及び／又は招待サービスの間のトランザクションを示す。 接続データ交換（ＣＤＸ）サービス、仲介サービス、及び／又は招待サービスの間のトランザクションを示す。 チケットデータ構造の１つの実施形態を示す。 ＣＤＸサービスが実施する方法の１つの実施形態を示す。 モバイル装置が実施する方法の１つの実施形態を示す。 一次及び二次通信チャンネルを経由し接続されるモバイル装置のグループを示す。 一次及び二次通信チャンネルの間を選択するためのモバイル装置の１つの実施形態を示す。 一次及び二次通信チャンネルを経由して接続されるモバイル装置のグループ、及び結果として得られるネットワークトポロジーを示す。 一次及び二次通信チャンネルを経由して接続されるモバイル装置のグループ、及び結果として得られるネットワークトポロジーを示す。 一次及び二次通信チャンネルの間を選択するためのコンピュータに実装された方法の１つの実施形態を示す。 ［ディレクトリサービス及びプッシュ通知サービスを含むモバイル装置及びサービスのグループがネットワーク上で通信するネットワークアーキテクチャを示す。 １つの実施形態の招待サービス、プッシュ通知サービス、及び接続データ交換（ＣＤＸ）サービスの間のトランザクションを示す。 １つの実施形態の招待サービス、プッシュ通知サービス、及びリレーサービスの間のトランザクションを示す。 ２つ又はそれ以上のモバイル装置の間のリレー接続を確立するためのリレーサービスの１つの実施形態を示す。 ＮＡＴ互換性を決定するためのＮＡＴ互換性チャートの１つの実施形態を示す。 モバイル装置をオンラインアプリケーションに仲介するための仲介サービスの１つの実施形態を示す。 ユーザ／デバイスを仲介するための方法の１つの実施形態を示す。 ユーザ／デバイスを仲介するために行われるテーブル更新の例示的なサービスを示す。 ユーザ／デバイスを仲介するために行われるテーブル更新の例示的なサービスを示す。 ユーザ／デバイスを仲介するために行われるテーブル更新の例示的なサービスを示す。 ユーザ／デバイスを仲介するために行われるテーブル更新の例示的なサービスを示す。 異なるマッチ適合変数を使用してユーザ／デバイスを仲介するための方法を示す。 アプリケーションのためのアプリケーションプログラミングインタフェース（ＡＰＩ）及びサービスセットと通信するためのサービスＡＰＩを公開するフレームワークを示す。 アプリケーションのためのＡＰＩ、ゲームデーモン、及びサービスと通信するためのゲームサービスモジュールを備えるゲームフレームワークの１つの実施形態を示す。 ＡＰＩ実装ソフトウェアコンポーネント及びＡＰＩ呼び出しソフトウェアコンポーネントの１つの実施形態を示す。 ＡＰＩ呼び出しがオペレーティングシステム、サービス、及びアプリケーションの間で行われる１つの実施形態を示す。 例示的なコンピュータシステムアーキテクチャの１つの実施形態を示す。 例示的なコンピュータシステムアーキテクチャの他の実施形態を示す。

以下にネットワーク上の主要及び／又は予備ピアツーピア（Ｐ２Ｐ）通信チャンネルを確立、維持、利用するための装置、方法、及びコンピュータ可読媒体の実施形態を説明する。また、Ｐ２Ｐセッションに関してユーザを招待しユーザを仲介するための招待サービス及び仲介サービスを説明する。更に、ユーザが特定条件の下でリレー接続を確立できるリレーサービスが開示される。最後に、アプリケーションフレームワーク及び関連のアプリケーションプログラミングインタフェース（ＡＰＩ）が開示され、アプリケーション開発者は、本明細書で説明する共同オンライン機能を利用するアプリケーションを設計できる。

明細書全体にわたって、本発明を完全に理解できるように説明目的で多数の具体的事項が示されている。しかしながら、当業者であれば、本発明はこれらの具体的詳細がなくても実施できることは理解できることを理解されたい。場合によっては、本発明の基本的原理が曖昧にならないように、公知の構成要素及び装置は示されていないか又はブロック図形式で示されている。

接続データを効率的かつ安全に交換するための装置及び方法
図１に示すように、本発明の１つの実施形態で実施する全体的なネットワークトポロジーは、相互に及びネットワーク１２０上で１つ又はそれ以上のサービス１１０−１１２と通信する「クライアント」又は「ピア」モバイルコンピュータ装置Ａ−Ｄ、１２０−１２３のグループを含むことができる。図１において、単一のネットワーククラウドとして示されているが、「ネットワーク」１２０は、インターネット等のパブリックネットワーク及びローカルＷｉ−Ｆｉネットワーク（例えば、８０２．１１ｎホーム無線ネットワーク又は無線ホットスポット）等のプライベートネットワーク、ローカルエリアイーサネット（登録商標）ネットワーク、セルラーデータネットワーク（例えば、３Ｇ、Ｅｄｇｅ）、及びＷｉＭＡＸ ネットワーク等の種々の異なる構成要素を含むことができる。例えば、モバイル装置Ａ１２０は、ネットワークリンク１２５で示すホームＷｉ−Ｆｉネットワークに接続することができ、モバイル装置Ｂ１２１は、ネットワークリンク１２６で示す３Ｇネットワーク（例えば、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅ通信ｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）、Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐリンク Ｐａｃｋｅｔ Ａｃｃｅｓｓ（ＨＳＵＰＡ））に接続することができ、モバイル装置Ｃ１２２は、ネットワークリンク１２７で示すＷｉＭＡＸネットワークに接続することができ、モバイル装置１２３は、ネットワークリンク１２８で示すパブリックＷｉ−Ｆｉネットワークに接続ことができる。モバイル装置１２０−１２３が接続されるローカルネットワークリンク１２５−１２８の各々は、ゲートウェイ及び／又はＮＡＴデバイス（図１には示されていない）経由でインターネット等のパブリックネットワークに接続できるので、パブリックネットワーク上で各モバイル装置１２０−１２３の間で通信できる。しかしながら、２つのモバイル装置が同じローカル又はプライベートネットワーク（例えば、同じＷｉ−Ｆｉネットワーク）にある場合、２つの装置は、パブリックネットワークを迂回してローカル／プライベートネットワーク上で直接通信できる。勿論、本発明の基本的原理は、ネットワークタイプ又はネットワークトポロジーの何らかの特定のセットに限定されないことに留意されたい。

図１に示すモバイル装置１２０−１２３の各々は、接続データ交換（ＣＤＸ）サービス１１０、仲介サービス１１１、及び招待サービス１１２と通信を行うことができる。１つの実施形態において、各サービス１１０−１１２は、サーバ等の１つ又はそれ以上の物理的コンピュータ装置で実行されるソフトウェアとして実装ことができる。図１に示すように、１つの実施形態において、サービス１１０−１１２は、同じエンティティ（例えば、同じデータサービスプロバイダ）が管理する大規模データサービス１００の枠内で実装することができ、モバイル装置１２０−１２３の各々がネットワーク１２０上でアクセスできる。データサービス１００は、種々の形式のサーバ及びデータベースに接続するローカルエリアネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）式ＬＡＮ）を含むことができる。また、データサービス１００は、データを格納するための１つ又はそれ以上のストレージエリアネットワーク（ＳＡＮ）を含むことができる。１つの実施形態において、データベースは、各々のモバイル装置１２０−１２３及びこれらの装置のユーザに関するデータを格納及び管理する（例えば、ユーザアカウントデータ、デバイスアカウントデータ、ユーザアプリケーションデータ）。

１つの実施形態において、仲介サービス１１１は、特定の条件セットに基づいて共同Ｐ２Ｐセッションに対して２つ又はそれ以上のモバイル装置の仲介を行うことができる。例えば、２つ又はそれ以上のモバイル装置のユーザは、特定の多人数参加型ゲームに興味をもつ場合がある。この場合、仲介サービス１１１は、モバイル装置のグループを特定して、各ユーザの経験レベル、各ユーザの年令、マッチリクエストの時期、仲介がリクエストされた特定のゲーム、及び種々のゲーム固有の変数等の変数に基づいてゲームに参加する。例示的かつ非限定的に、仲介サービス１１１は、特定のゲームで同じ経験レベルのユーザを仲介するよう試みる。更に、大人には他の大人を、子供には他の子供を仲介することができる。更に、仲介サービス１１１は、リクエストを受信した順番に基づいてユーザリクエストに優先順位をつけることができる。本発明の基本的原理は、何らかの特定のマッチ基準又はＰ２Ｐアプリケーションの何らかの特定のタイプに限定されない。

以下に詳細に説明するように、マッチリクエストに応答して、仲介サービス１１１は、効率的かつ安全な方法でＰ２Ｐセッションを確立するために全ての仲介参加者が必要な接続データを受信できるように、ＣＤＸサービス１１０と協働することができる。

１つの実施形態において、招待サービス１１２は、共同Ｐ２Ｐセッションに参加するためにモバイル装置を特定できる。しかしながら、招待サービス１１２の場合、参加者の少なくとも一人は他の参加者によって具体的に特定される。例えば、モバイル装置Ａ１２０のユーザは、モバイル装置Ｂ１２１のユーザとの共同セッションを具体的にリクエストすることができる（例えば、ユーザＩＤ又は電話番号でモバイル装置Ｂを特定する）。仲介サービス１１１と同様に、招待リクエストに応答して、招待サービス１１２は参加者セットを特定でき、ＣＤＸサービス１１０と協働して、効率的かつ安全な方法でＰ２Ｐセッションを確立するために全ての参加者が必要な接続データを受信できるようにする。

前述のように、実施形態において、ＣＤＸサービス１１０は、２つ又はそれ以上のモバイル装置の間のＰ２Ｐセッションを確立するこが要求される、接続データに関する中央交換ポイントとして機能する。特に、ＣＤＸサービスの１つの実施形態は、外部サービス及びクライアントが各モバイル装置のＮＡＴを経由して通信を行う（つまり、デバイスに到達するためにＮＡＴを介して「穴を開ける」ためのモバイル装置リクエストに応答して、ＮＡＴトラバーサルデータ（「ホールパンチ（Ｈｏｌｅ Ｐｕｎｃｈ）」データと呼ぶ場合もある）を発生する。例えば、１つの実施形態において、ＣＤＸサービスはモバイル装置と通信するのに必要な外部ＩＰアドレス及びポートを検出して、この情報をモバイル装置に提供する。１つの実施形態において、ＣＤＸサービスは、仲介サービス１１１及び招待サービス１１２が生成したモバイル装置リストを受信及び処理して、効率的かつ安全に接続データをリストに含まれる各々のモバイル装置に配信する（以下に詳細に説明する）。

１つの実施形態において、モバイル装置とＣＤＸサービス１１０との間の通信は、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）ソケット等の比較的軽量なネットワークプロトコルを使用して確立される。当業者であれば理解できるように、ＵＤＰソケット接続は、パケット信頼性、順序づけ、データ整合性を保障するためにハンドシェイクダイアログを必要としないので、ＴＣＰソケット接続に比べて、多くのパケット処理オーバーヘッドを消費しない。結果的に、ＵＤＰの軽量、ステートレス性は、膨大な数のクライアントからの問い合わせに少しだけ応答するサーバに有用である。更に、ＴＣＰとは異なり、ＵＤＰは、パケット同報通信（パケットがローカルネットワーク上の全てのデバイスに送信される）及びマルチキャスティング（パケットがローカルネットワーク上のデバイスのサブセットに送信される）と互換性がある。以下に説明するように、ＵＤＰを使用できるが、セキュリティは、セッションキーを用いてＮＡＴトラバーサルデータを暗号化することで、ＣＤＸサービス１１０上で維持できる。

ＣＤＸサービス１１０が使用するオーバーヘッドの少ない軽量ネットワークプロトコルとは対照的に、１つの実施形態において、モバイル装置１２０−１２３と仲介サービス１１１及び／又は招待サービス１１２との間の通信は、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ（ＳＳＬ）又はＴｒａｎｓポート Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）接続に依存するＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）等の本質的にセキュアなネットワークプロトコルを用いて確立される。これらのプロトコルの詳細は当業者には公知である。

図２ａは、ＣＤＸサーバで実施できる例示的な一連のトランザクションを示す。１つの実施形態のＣＤＸサービスの作動を説明する場合、以下の用語は以下の意味を有することになる。

「接続データ」は、ピアツーピアセッションを確立するために、どの潜在的ピアが相互に交換する必要があるかの情報である。以下の実施形態はこの情報を交換する方法を示す。

１つの実施形態において、「ＣＤＸサーバ」は認証されたマルチキャストリフレクタであり、認可エンティティは任意データを交換できる。このデータはＰａｙｌｏａｄと呼ばれる。

「ＣＤＸセッション」は、ＣＤＸサーバを介して相互に通信できるクライアント装置のグループに関する。セッションの一部である各クライアント装置は、ＣＤＸチケットが割り当てられる。各セッションは、個々のセッションを特定するために又はこれを参照するために使用できる大きな整数である、固有ＣＤＸセッションＩＤを有している。

「ＣＤＸリクエスト」は、クライアント装置からＣＤＸサーバに送信されるリクエストである。リクエストは、概してＣＤＸチケット及びＰａｙｌｏａｄの２つの部分から成る。本実施形態において、Ｐａｙｌｏａｄは、セッションキーで暗号化された接続データである。

「ＣＤＸレスポンス」は、ＣＤＸサーバがＣＤＸセッションのメンバからのＣＤＸリクエストを受信した場合に、ＣＤＸセッションの他のデバイスに「反射されて」戻されたものである。Ｐａｙｌｏａｄを所定のＣＤＸリクエストに使用するＣＤＸチケットのＣＤＸチケット半券に付加することで構成される。

「ＣＤＸチケット」は、ＣＤＸサーバにＰａｙｌｏａｄをＣＤＸセッションの各メンバへ送信する方法を伝える。１つの実施形態において、ＣＤＸチケットキーで「署名」されており、偽造又は改ざんを防止するようになっている。図３に示すように、１つの実施形態において、ＣＤＸチケットは以下の情報を含む。

１つの実施形態において、暗号化又は難読化されていないセッションＩＤ３０１。
１つの実施形態において、暗号化又は難読化されていないセッションの参加者数３０２。
セッションのどの参加者がこのチケットを参照しているかのインデックス３０３（１つの実施形態において、暗号化又は難読化されていない）。
チケットが無効になる期限切れ時間／日付３０４１つの実施形態において、暗号化又は難読化されていない）。
１つの実施形態において、ＣＤＸチケットキーを用いて暗号化される、セッションの各参加者に関するＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａ３０５−３０６。
チケットが認証されていることを保証する「デジタル署名」のように機能する、ＣＤＸチケットキーを使用するＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ ３０７。

「ＣＤＸチケット半券」は、ＣＤＸチケットの最初の部分からＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａ及びＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅを差し引いたものである。

「Ｐａｙｌｏａｄ」は、ＣＤＸリクエスト及びＣＤＸレスポンスの第２の部分である。ペイロードは、クライアント装置がＣＤＸセッションの他のデバイスに伝達しようするデータである。本実施形態において、ペイロードはセッションキーで暗号化された接続データである。ＣＤＸサーバはペイロードを復号化せず、１つの実施形態において、不変で単純に通過するだけである。

「セッションキー」は、クライアントが使用して接続データを暗号化するためのキーである。１つの実施形態において、このキーはＣＤＸサーバには知られていない。本実施形態において、セッションキーは、仲介サービスが発生して、個々のＣＤＸチケットと一緒にクライアントへ送信される。

「ＣＤＸチケットキー」は、ＣＤＸチケットを生成して「署名」するために使用するキーである。ＣＤＸチケットキーはＣＤＸサーバだけが知っており、以下に説明するＣＤＸチケットを生成するサービスは、仲介サービス及び／又は招待サービスとすることができる。

「ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｒｅｑｕｅｓｔ」は、ＣＤＸリクエストの特殊なタイプであり、ＣＤＸサーバからＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａを取得するために使用する。

「ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａ」は、ＣＤＸサーバが情報を要求するクライアントへ送信する方法を説明する不透明データブロブである。これは、ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ ＲｅｑｕｅｓｔをＣＤＸサーバへ送信することで得られる。ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａは、ＣＤＸチケットが生成される前に、ＣＤＸセッションにおいて各クライアント装置から収集する必要がある。ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａ（「ＮＡＴトラバーサルデータ」と呼ぶ場合もある）は、要求デバイスのパブリックＩＰアドレス及びポートを含むことができる。

図２ａを参照すると、１つの実施形態において、モバイル装置Ａ１２０及びモバイル装置Ｂ１２１は、１つ又はそれ以上の他のコンピュータ装置とのＰ２Ｐ接続を必要とする、多人数参加型ゲーム等の共同アプリケーション又は共同チャットセッションを実行することができる。２０１ａにおいて、モバイル装置Ａ１２０は、ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ ＲｅｑｕｅｓｔをＣＤＸサーバ１１０に送信する。次に、ＣＤＸサーバ１１０は、２０２ａにおいて、ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａに応答する。１つの実施形態において、この「ホールパンチデータ」は、モバイル装置ＡのパブリックＩＰアドレス及びポート及び／又はモバイル装置ＡのＮＡＴを通る穴を開けるために必要な何らかの他のデータ（例えば、モバイル装置ＡのＮＡＴタイプを規定するＮＡＴタイプデータ）を含む。同様のトランザクションは、それぞれ２０１ｂ及び２０２ｂにおいてモバイル装置Ｂに関して行われる。

２０３ａ及び２０３ｂにおいて、モバイル装置Ａ及びＢは、何らかの追加のマッチ基準（以下に説明する）と一緒に、ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａを含むマッチリクエストを仲介サービスに送信する。この段階で、モバイル装置Ａ及びＢ は、Ｐ２Ｐ接続を確立するのに必要な接続データの構築を開始できる。このことは、例えば、標準のＩｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＩＣＥ）トランザクション等のトランザクションを使用して（例えば、ＮＡＴトラバースサービスによって）で実現できる。しかしながら、本発明の基本的原理は、接続データを決定するための何らかの特定の機構に限定されない。

１つの実施形態において、仲介サービス１１１は、マッチ基準と一緒にクライアント装置セットを見つけると、固有ＣＤＸセッションＩＤ、ＣＤＸセッションの各メンバに対する固有ＣＤＸチケット、及び固有セッションキーを生成することができる。１つの実施形態において、０仲介サービス１１１は、固有ＣＤＸチケットキーを使用してＣＤＸチケットに関するＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａを暗号化することができる。２０４ａ及び２０４ｂにおいて、仲介サービスは、モバイル装置Ａ及びＢの各々にＣＤＸチケット及びセッションキーを送信することができる。

モバイル装置Ａは、ＣＤＸチケット及びセッションキーを受信して、セッションキーを使用して先に決定した接続データを暗号化してＰａｙｌｏａｄを作る。１つの実施形態において、モバイル装置Ａは、構築したＰａｙｌｏａｄをＣＤＸチケットに付加することで、ＣＤＸリクエストを構築する。２０５ａにおいて、モバイル装置Ａは、ＣＤＸリクエストをＣＤＸサーバ１１０に送信する。また、モバイル装置Ｂは、同じ作動を行って２０５ｂにおいてＣＤＸサーバにリクエストを送信することができる。

２０６ａにおいて、ＣＤＸサーバ１１０はＣＤＸリクエストを受信して、チケットが有効で認証されていることを調べる（例えば、メッセージ認証コード３０７に基づいて）。ＣＤＸチケットが無効の場合、リクエストは撤回される。１つの実施形態において、ＣＤＸサーバは、次に、ＣＤＸチケットキーを用いてＣＤＸチケットに包含されたＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａセットを復号化する。１つの実施形態において、ＣＤＸチケットキーは、チケットと一緒に送信することができる期限切れ時間／日付を含むことができる。ＣＤＸサービス１１０及び仲介サービス１１１は、暗号化／復号化のための２つ（又はそれ以上の）異なるＣＤＸチケットキーを記憶できるが、ＣＤＸサービスは現在アクティブであり、仲介サービスはＣＤＸサービスの期限切れ時間／日付に達するとアクティブになる。チケットを受け取りと、ＣＤＸサービス１１０は期限切れ時間／日付を読み取ってどのチケットキーを使用するかを決める。ＣＤＸチケットキーが期限切れになると、ＣＤＸサービス１１０及び仲介サービス１１１は、それぞれ新しいチケットキーを生成する（現在のチケットキーが期限切れになった後に使用する次のキーとすることができる）。１つの実施形態において、ＣＤＸサービス１１０及び仲介サービス１１１は、同じキー生成アルゴリズムを実行して、２つのチケットキーの一貫性を保証するようになっている。例えば、公知のＲＳＡ ＳｅｃｕｒＩＤ認証機構に使用する技術を使用でき、ここでは新しい認証コードが一定間隔で生成される。１つの実施形態において、新しいＣＤＸチケットキーは毎日生成できる。しかしながら、本発明の基本的原理は、ＣＤＸチケットキーを生成するための何らかの特定の機構に限定されない。

２０６ｂに示すように、モバイル装置Ｂに関しても同じ作動を行うことができる。ＣＤＸサーバはＣＤＸリクエストからＣＤＸレスポンスを構築し、次に、ＣＤＸ Ｈｏｌｅ−Ｐｕｎｃｈ Ｄａｔａを使用して、ＣＤＸレスポンスをＣＤＸセッションの参加者に送信する（２０７ａでモバイル装置Ｂに、２０７ｂでモバイル装置Ａに送信する）。

２０７ａにおいて、モバイル装置Ｂは、ＣＤＸサーバからＣＤＸレスポンスを受信する。クライアント装置Ｂは、ＣＤＸチケット半券を調べてセッションＩＤが自分のＣＤＸチケットのセッションＩＤと一致することを確認する。次に、モバイル装置Ｂは、セッションキーを用いてＰａｙｌｏａｄを復号化することができ、モバイル装置Ａから接続データを発生させる。次に、モバイル装置Ｂは、モバイル装置Ａからの接続データを使用して、Ｐ２Ｐセッションを確立するための処理を開始する。１つの実施形態において、このことは標準ＩＣＥトランザクションを必要とする。しかしながら、本発明の基本的原理は、Ｐ２Ｐ通信を確立するための何らかの特定の機構に限定されない。

前述のように、１つの実施形態において、モバイル装置Ａ及びＢは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）セッションを確立して仲介サービス１１１と通信する（例えば、ＨＴＴＰＳ リクエスト／レスポンストランザクションを使用して）と共に、ＵＤＰソケットを確立してＣＤＸサービスと通信するようになっている。マッチリクエスト２０４ａ、２０４ｂは、それぞれのモバイル装置に関して以前に決定したＮＡＴタイプ及びホールパンチデータ（例えば、パブリックＩＰアドレス及びポート）を含むことができる。多人数参加型ゲームを含む実施形態において、各マッチリクエストは、各モバイル装置のプレーヤー（例えば、固有プレーヤーＩＤコードを用いて）、ユーザがやりたいと思うゲーム、ゲームに参加するプレーヤー数、及び／又は所望のゲームに関連する他のゲーム構成変数を特定することができ、例示的かつ非限定的に、ゲームに関連するゲーム構成変数は、難易度（例えば、簡単、普通、困難）、ユーザの年令（例えば、「１３才以下」）、ゲームのサブ区域（例えば、「レベル２」）、及び／又はプレーヤーの経験レベル（例えば、エキスパート、初心者、中間）を含むことができる。以下に詳細に示すように、これらの変数は、ゲーム「バケット」と呼ぶ場合があり、固有「バケットＩＤ」を使用して特定される。各ゲームは、異なるゲーム構成変数を特定するために異なるバケットＩＤセットを含むことができる。

１つの実施形態において、モバイル装置Ｂは、２０８ａ及び２０９ａにおいて受信確認を送信する。同様に、モバイル装置Ａは、２０８ｂ及び２０９ｂにおいて受信確認を送信する。所定期間後にモバイル装置Ａ又はＢの受信確認を受信できない場合、２０７ａにおいて接続データはモバイル装置Ｂ２１２に再送される。ＣＤＸサービス１１０は再送を開始でき、及び／又はモバイル装置Ａ１２０は再送を開始できる。

図２ｂは、３つの異なるモバイル装置１２０−１２２がＣＤＸサービス及び仲介サービス１１１を用いてＰ２Ｐ接続を取り決める更に詳細な実施例を示す。また、図２ｂはモバイル装置１２０−１２２が使用して接続を行う２つの追加のサービスを示し、ＮＡＴタイプを決定するＮＡＴトラバースサービス２９１、及び各モバイル装置に関する完全接続データを決定するＮＡＴトラバースサービス２９０である（例えば、ＩＣＥ接続データトランザクションを利用する）。しかしながら、本発明の基本的原理に従うために別々のサービスは必要ないことに留意されたい。例えば、他の実施形態において、サービス２９０−２９１の各々で行われるＮＡＴトラバース機能は、ＣＤＸサービス１１０及び／又は仲介サービス１１１内に直接組み込むことができる。同様に、ＮＡＴトラバースサービス２９０−２９１の両者が行う機能は、単一のＮＡＴトラバースサービスに組み込むことができる。つまり、図２ｂに示すこの特定の機能分離は、本発明の基本的原理に従うために必須ではない。

図２ｂの具体的詳細を参照すると、２２０において、モバイル装置は、ＮＡＴタイプリクエストをＮＡＴトラバースサービス２９１に送信する。これに応答して、ＮＡＴトラバースサービス２９１は、モバイル装置Ａが使用するＮＡＴタイプを決定するための一連のトランザクションを実施することを含む、種々の公知技術を使用ことができる。例えば、ＮＡＴトラバースサービス２９１は、モバイル装置ＡのＮＡＴの異なるＩＰアドレス及びポートを開放して、異なるＩＰ／ポートの組み合わせを用いてこのポートを介してモバイル装置Ａと通信することを試みることができる。このようにして、モバイル装置Ａが採用するＮＡＴは、前述のＮＡＴタイプ（例えば、「ｆｕｌｌ ｃｏｎｅ」、「ｒｅｓｔｒｉｃｔｅｄ ｃｏｎｅ」、「ｐｏｒｔ ｒｅｓｔｒｉｃｔｅｄ ｃｏｎｅ」、「ｓｙｍｍｅｔｒｉｃ」）又は他のＮＡＴタイプの１つに分類することができる。次に、この情報は、図示のようにモバイル装置Ａ１２０に提供される。

２２１において、モバイル装置Ａ１２０は、ＣＤＸサービス１１０に対してＮＡＴトラバースリクエストを開始する。これに応答して、ＣＤＸサービス１１０は、リクエストに使用したパブリックＩＰアドレス及びパブリックポート番号を読み取り、この情報をモバイル装置Ａ１２０に返信することができる。前述のように、デバイスがＮＡＴの背部にある場合、そのパブリックポート及びＩＰアドレスは、そのプライベートポート及びＩＰアドレスのそれぞれとは異なるはずである。つまり、使用するＮＡＴ対応に応じて、パブリックＩＰアドレス及びポートは、ＮＡＴデバイスを通ってモバイル装置に達する「穴を開ける」ために使用できる。

２２２において、モバイル装置Ａ１２０は、マッチリクエスト２２２を仲介サービス１１１に送信する。前述のように、１つの実施形態において、モバイル装置Ａは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）セッションを使用して（例えば、ＨＴＴＰＳリクエスト／レスポンストランザクションを使用して）仲介サービス１１１と通信する。マッチリクエストは、以前モバイル装置Ａ１２０に関して決定したＮＡＴタイプ及びホールパンチデータ（例えば、パブリックＩＰアドレス及びポート）を含むことができる。多人数参加型ゲームを含む実施形態において、マッチリクエストは、モバイル装置Ａのプレーヤー（例えば、固有プレーヤーＩＤコードを使用する）、ユーザがやりたいと思うゲーム、ゲームに参加するプレーヤー数、及び／又は（図２ａを参照して説明したような）所望のゲームに関する他のゲーム構成変数を特定できる。

２２３−２２５において、トランザクション２２０−２２２に対応するトランザクションセットは、モバイル装置Ｂ１２１に関して実行され、２２６−２２８において、トランザクション２２０−２２２に対応するトランザクションセットは、モバイル装置Ｃ１２２に関して実行される。つまり、トランザクション２２８に続いて、仲介サービス１１１は、モバイル装置１２０−１２２の３つ全てに関するマッチリクエストを受信する。この特定の実施例において、マッチリクエストにより、モバイル装置１２０−１２２は多人数参加型ゲーム等の特定の共同セッションに対して仲介される（例えば、これらのモバイル装置のユーザは、同じ又は類似の変数セットを用いて同じゲームを選択することができるので、仲介サービス１１１による仲介につながる）。

仲介サービス１１１は、マッチリクエストの各々に含まれるデータを使用して、２２９においてモバイル装置Ａに送信されるチケットＡ、２３０においてモバイル装置Ｂに送信されるチケットＢ、及び２３１においてモバイル装置Ｃに送信されるチケットＣを生成する。図２ｂには示されていないが、仲介サービス１１１は、プッシュ通知サービスを使用して（例えば、図１１−１２に示すプッシュ通知サービス１０５０）、チケットＡ、Ｂ、及びＣをそれぞれモバイル装置Ａ、Ｂ、及びＣにプッシュ配信することができる。チケットＡ、Ｂ、及びＣに使用するチケットデータ構造の１つの実施形態は、図３に関して説明される。

２３２において、モバイル装置Ａ１２０は、ＮＡＴトラバースサービス２９０と通信して自分の接続データを決定できる。１つの実施形態において、標準ＩＣＥ接続データトランザクションを含むことができる。前述のように、接続データは、モバイル装置Ａ１２０に関するパブリック／プライベートＩＰアドレス、ポート、及びＮＡＴタイプを含むことができる。

モバイル装置Ａ１２０は自分の接続データをチケットＡに付加し、２３３において、接続データを備えるチケットＡをＣＤＸサービス１１０に送信する。１つの実施形態において、ＣＤＸサービス１１０は、前述のようにチケットＡを処理し、２３４において、接続データ（暗号化できる）をモバイル装置Ｂ１２１及びモバイル装置Ｃ１２２に送信する。これらのトランザクションに関して、ＣＤＸサービス１１０は、チケットＡに含まれるＮＡＴトラバーサルデータをモバイル装置Ｂ及びＣのために利用する。

２３６−２３８において、トランザクション２３２−２３４に対応するトランザクションセットは、チケットＢを用いて行われ、２３８−２４０において、トランザクション２３２−２３４に対応するトランザクションセットは、チケットＣに関して行われる。つまり、トランザクション２４０に続いて、接続データは、モバイル装置１２０−１２２の各々の間で共有されている。接続データを使用して、Ｐ２Ｐセッションは、モバイル装置ＡとＢの間。モバイル装置ＡとＣの間、及びモバイル装置ＡとＣの間で確立される。

図２ｃに示すように、招待サービス１１２は、ＣＤＸサービス１１０とともに使用される（仲介サービス１１１の代わりに又は一緒に）。１つの実施形態において、招待サービス１１２は、特定のモバイル装置及び／又はユーザとのＰ２Ｐ接続に関する招待リクエストを処理する。招待サービス１１２はステートレスサービスとして実施できる（つまり、各無線装置の間のトランザクションの現在の状態を変更しないサービス）。

この特定の実施例において、２５０において、モバイル装置Ａ１２０は、ＮＡＴタイプリクエストをＮＡＴトラバースサービス２９１に送信する。これに応答して、ＮＡＴトラバースサービス２９１は、種々の公知技術を利用してモバイル装置Ａが使用するＮＡＴタイプを決定する。（いくつかは前述されている）。２５１において、モバイル装置Ａ１２０は、ＣＤＸサービス１１０に対してＮＡＴトラバースリクエストを開始する。これに応答して、ＣＤＸサービス１１０は、リクエストに使用されるパブリックＩＰアドレス及びパブリックポート番号を読み取り、この情報をモバイル装置Ａ１２０に返信する。前述のように、デバイスがＮＡＴの背部にある場合、そのパブリックポート及びＩＰアドレスは、そのプライベートポート及びＩＰアドレスのそれぞれとは異なるはずである。つまり、使用するＮＡＴ対応に応じて、パブリックＩＰアドレス及びポートは、ＮＡＴデバイスを通ってモバイル装置に達する「穴を開ける」ために使用できる。

仲介サービスと同様に、１つの実施形態において、モバイル装置の各々は、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）セッションを使用して（例えば、ＨＴＴＰＳリクエスト／レスポンストランザクションを使用して）招待サービス１１２と通信する。

２５２において、モバイル装置Ａ１２０は、モバイル装置ＡのＮＡＴトラバーサルデータ（例えば、ＮＡＴタイプ、パブリックＩＰアドレス／ポート）を含む招待リクエストを招待サービス１１２に送信する。プッシュ通知サービス（以下に詳細の説明する）を利用する実施形態において、招待リクエストは、モバイル装置Ａのプッシュトークンを含むこともできる。招待リクエスト２５２は、１つ又はそれ以上の他のユーザ／デバイス（この場合はモバイル装置Ｂ１２１及びＣ１２２ユーザである）を特定する識別コードを含むこともできる。種々の異なる識別コードタイプを使用できる。例えば、多人数参加型ゲームの場合、識別コードは、ゲーム固有プレーヤーＩＤコードを含むことができる。オーディオ／ビデオチャットセッションの場合、識別コードは、１人又はそれ以上のユーザをモバイル装置Ａの「バディ」リストのユーザから特定するための電話番号又は固有ＩＤコードを含むことができる。

１つの実施形態において、招待サービス１１２は、招待リクエストから識別コードを読み取り、登録データベース（図示せず）を調べてモバイル装置Ｂ及びＣの各々を見つける。１つの特定の実施形態において、モバイル装置Ｂ及びＣの各々は、プッシュサービスで登録されて招待サービス１１２からのプッシュ通知を受信するようになっている。従って、本実施形態において、招待サービス１１２は、プッシュ通知サービスを使用して、招待リクエストを２５３及び２５４においてそれぞれモバイル装置Ｂ１２１及びモバイル装置Ｃ１２２にプッシュ配信する。プッシュ通知サービスに関する追加的な詳細は、以下に（例えば、図１１−１２及び関連の本文を参照）、及び前述のプッシュ通知アプリケーションに説明される。

１つの実施形態において、招待リクエスト２５３及び２５４は、図３及び前述の図２ａ−ｂに示すチケットデータ構造を含む。特に、モバイル装置Ｂに送られるチケットは、モバイル装置Ａ及びＢを特定する暗号化リストを含み、モバイル装置Ｃに送られるチケットはモバイル装置Ａ及びＣを特定する暗号化リストを含む。１つの実施形態において、招待サービス１１２は今のところモバイル装置ＢのＮＡＴトラバーサルデータをもつことができないので、２５３における「チケット」は、モバイル装置Ｂを特定する他の情報をもつことができる。例えば、リレーサービス及びプッシュ通知サービス（例えば、図１１−１２参照）を利用する実施形態に関連して以下に説明するように、２５３における「チケット」は、モバイル装置Ａに関するＮＡＴトラバーサルデータ、装置ＡのＩＤコード、装置Ａのプッシュトークン、装置ＢのＩＤコード、及びモバイル装置Ｂに関するプッシュトークンを含む。２５４において、モバイル装置Ａ及びＣに対して同じ形式の情報を提供できる。

２５５において、モバイル装置Ｂは、ＮＡＴトラバースサービス２９１と通信してそのＮＡＴタイプを決定でき、２５６において、モバイル装置Ｂは、ＣＤＸサービス１１０と通信してそのＮＡＴトラバーサルデータを決定できる（例えば、パブリックＩＰアドレス／ポート）。２５７において、モバイル装置Ｂは、モバイル装置Ａ及びモバイル装置Ｂの識別コード、ＮＡＴトラバーサルデータ、及びプッシュ通知サービスを使用する場合はモバイル装置Ａ及びＢに関するプッシュトークンを含む、招待レスポンスを招待サービス１１２に送信する。２５８において、モバイル装置Ｂは、ＮＡＴトラバースサービス２９０と通信することで、その現在の接続データを読み出す。２５９において、モバイル装置Ｂは、自身の現在の接続データと共にチケット（チケットＢ）をＣＤＸサービス１１０に送信する。これに応答して、ＣＤＸサービス１１０は、前述のようにチケットを処理して、接続データをモバイル装置Ａ１２０に送る。

モバイル装置Ｂの招待レスポンスを受信すると、招待サービス１１２は、モバイル装置Ａに関する暗号化チケットを生成して、２６０において、チケットをモバイル装置Ａに送信することができる。１つの実施形態において、チケットは、モバイル装置Ａ及びＢに関するＮＡＴトラバーサルデータ、ＮＡＴタイプ、及びプッシュトークン（プッシュ通知サービスを使用する場合）を含む。図２ｃに関連して説明する「チケット」は、仲介サービス１１１に関連して説明する「チケット」のデータ構造と同じ又は異なることができる。例えば、前述のように暗号化「チケット」を生成するのではなく、招待サービス１１２は、単純に固有セッションＩＤを生成して、モバイル装置の各々に対する招待セッションを特定することができる。

２６１において、モバイル装置Ａは、ＮＡＴトラバースサービス２９０と通信することで自身の現在の接続データを読み出す。次に、モバイル装置Ａは、その接続データをチケットに付加して、２６２において、接続データを有するチケットをＣＤＸサービス１１０に送信することができる。ＣＤＸサービス１１０は、前述のようにチケットを処理して、モバイル装置Ａの接続データをモバイル装置Ｂに送る。最後に、２６３において、モバイル装置Ａ及びＢは、交換した接続データを使用して、直接的なＰ２Ｐ接続を開く。以下に説明するように、モバイル装置Ａ及びＢのＮＡＴタイプに互換性がない場合、リレーサービスを使用してモバイル装置ＡとＢとの間の通信を可能にする。

２６４−２７２において、モバイル装置Ｃ１２２及びモバイル装置Ａは、モバイル装置Ｂ及びＡに関する２５５−２６３で説明したように、一連のトランザクションを実行してＰ２Ｐ接続を確立できる。詳細には、２６４において、モバイル装置Ｃ１２２は、ＮＡＴトラバースサービス２９１と通信して自身のＮＡＴタイプを決定でき、２６５において、ＣＤＸサービス１１０と通信して自身のＮＡＴトラバーサルデータを決定できる（例えば、パブリックＩＰアドレス／ポート）。２６６において、モバイル装置Ｃは、モバイル装置Ｃ及びモバイル装置ＡのＮＡＴタイプ、ＮＡＴトラバーサルデータ、及びプッシュトークン（プッシュ通知サービスを使用する場合）を含む招待レスポンスを送信する。２６７において、モバイル装置Ｃは、ＮＡＴトラバースＰ２Ｐサービス２９０経由で自身の現在の接続データを読み出し、２６８において、モバイル装置Ｃは、その接続データをチケットＣに付加し、チケットＣをＣＤＸサービス１１０に送信する。ＣＤＸサービス１１０は、前述のようにチケットを処理して、モバイル装置Ｃの接続データをモバイル装置Ａ１２０に送る。

２６９において、モバイル装置Ａ１２０は、モバイル装置Ａ及びＣのＮＡＴタイプ、ＮＡＴトラバーサルデータ、及びプッシュトークン（プッシュサービスを使用する場合）を含む、モバイル装置Ｃの招待レスポンスを招待サービス１１２から受信する。２７０において、モバイル装置Ａは、現在の接続データをＮＡＴトラバースサービス２９０から読み出し、現在の接続データをチケットＡに付加して、２７１において、チケットＡをＣＤＸサービス１１０に送信する。もしくは、モバイル装置は自身の接続データをトランザクション２６１で決定しているのでトランザクション２７０は必要ない場合もある。ＣＤＸサービス１１０は、前述のようにチケットＡを処理してモバイル装置Ａの接続データをモバイル装置Ｃに送る。最後に、２７２において、モバイル装置Ａ及びＣは、交換した接続データを使用して直接的なＰ２Ｐ接続２７２を確立する。

１つの実施形態において、招待サービス１１２及び仲介サービス１１１は、データをモバイル装置へプッシュ配信するためのプッシュ通知サービス（図示せず）に依存することができる。例えば、図２ｃにおいて、招待リクエスト２５３及び２５４は、プッシュ通知サービスによりモバイル装置Ｂ１２１及びＣ１２２へプッシュ配信することができる。同様に、図２ａにおいて、チケットＡ及びＢは、モバイル装置Ａ１２０及びＢ１２１へプッシュ配信することができる。１つの実施形態において、モバイル装置がネットワーク上でアクティブである場合、プッシュ通知サービスがアクセス可能な中央レジストレーションディレクトリのプッシュトークンを登録する。１つの実施形態において、レジストレーションディレクトリは、ユーザＩＤで保護されたパスワード又は電話番号をプッシュトークンと関連付けることができる。プッシュトークンがこのディレクトリで特定できる場合、プッシュ通知サービスは、プッシュトークンを使用してプッシュ通知をモバイル装置に送信することができる。１つの実施形態において、プッシュ通知サービスは、本出願人が設計した、例えば、前述のプッシュ通知アプリケーションに説明されるＡｐｐｌｅプッシュ通知サービス（ＡＰＮＳ）である。しかしながら、プッシュ通知サービスは図２ａ−ｃに示す本発明の実施形態に必須ではないことに留意されたい。例えば、プッシュ通知は、本明細書で説明する作動を行うためにＣＤＸサービス１１０に必須ではない。

図４は、接続データを交換するためにＣＤＸサービス１１０が実施できる方法を示し、図５は、接続データを交換してＰ２Ｐ接続を確立するためにモバイル装置が実施できる方法を示す。これらの特定の態様は、図１から２ｃに関連して既に説明されている。詳細には、これらの方法は、図１−２ｃに示すネットワークアーキテクチャの枠の中で実施できるが、このようなアーキテクチャに限定されるものではない。１つの実施形態において、本方法は、プロセッサが実行すると所望の作動をもたらすプログラムコードに組み込むことができる。プログラムコードは、プロセッサでの実行中にランダムアクセスメモリ（ＲＡＭ）等のコンピュータ可読媒体に格納することができる。プロセッサは、汎用プロセッサ（例えば、Ｉｎｔｅｌ（登録商標）ＣｏｒｅＴＭプロセッサ）又は特定用途向けプロセッサとすることができる。しかしながら、本方法は、ハードウェア，ソフトウェア、及びファームウェアの何らかの組み合わせで実施できる。更に、プログラムコードは、ハードディスクドライブ、光ディスク（例えば、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｋ又はＣｏｍｐａｃｔ Ｄｉｓｃ）等の不揮発性記憶デバイス、又はフラッシュメモリデバイス等の不揮発性メモリに格納できる。

図４に示す方法を参照すると、４０１において、ＮＡＴトラバースリクエスト（「ホールパンチ」リクエストと呼ぶ場合もある）を、特定のモバイル装置（例えば、モバイル装置Ａ）から受信する。４０２において、ＮＡＴトラバースレスポンスを生成してモバイル装置Ａに送信する。１つの実施形態において、ＮＡＴトラバースレスポンスの生成は、モバイル装置Ａの現在のパブリックＩＰアドレス／ポート及び／又はＮＡＴタイプの決定を含むことができる。

その後、モバイル装置Ａに関するチケットを、前述の仲介サービス１１１又は招待サービス１１２等のチケット生成エンティティで生成及び暗号化する。４０３において、ＮＡＴトラバーサルデータ（装置Ａ及び１つ又はそれ以上の他の装置に関する）及び装置Ａに関する接続データを含む、モバイル装置Ａ対して生成したチケット（チケットＡ）を受信する。４０４において、メッセージ認証コードを利用してチケットを認証し、チケットを暗号化するためにチケット生成エンティティが使用したのと同じＣＤＸチケットキーを使用して、ホールパンチデータを復号化する。前述のように、１つの実施形態において、正しいＣＤＸチケットキーは、ＣＤＸチケットキーに関連する期限切れ時間／日付を使用して特定される。

４０５において、各モバイル装置に関するＮＡＴトラバーサルデータを復元する。４０６において、モバイル装置Ａに関する接続データを、ＮＡＴトラバーサルデータを使用してピアの各々に送信する。４０７において、ピアの各々から受信確認を受信する。４０８において、全てのピアからの受信確認を受信していないと判定すると、４０９において、モバイル装置Ａの接続データを未応答のこれらのピアに再送する。全ての接続データの受信確認があったと判定すると、本方法は終了する。

１つの実施形態において、図４に示す本方法は、Ｐ２Ｐトランザクションに含まれる各々のピアに対して実行することができ、各ピアは確実にＰ２Ｐ接続を確立するのに必要な接続データを確実に受信できる。

図５は、本発明の実施形態によるモバイル装置が実行する方法を示す。５０１において、ＮＡＴトラバースリクエストを送信し、５０２においてＮＡＴトラバースレスポンスを受信する。前述のように、このレスポンスに含まれるＮＡＴトラバーサルデータは、要求装置のパブリックポート／ＩＰアドレスを含むことができる。５０３において、ＮＡＴトラバーサルデータを含むマッチリクエストを送信する。次に、前述の仲介サービス１１１又は招待サービス１１２等のチケット生成エンティティで、モバイル装置に関するチケットを生成して暗号化する。前述のチケットデータ構造の他の別例として、仲介サービス１１１及び／又は招待サービス１１２は、単純に固有セッションＩＤを使用して参加者の各々を特定できる。

５０４において、チケットを受信することができ、５０５において、モバイル装置に関する接続データをチケットに付加し、５０６において、接続データを含むチケットを送信する。５０７において、１つ又はそれ以上の他のピアとのＰ２Ｐ接続の確立が必要な接続データを受信する。５０８において、１つ又はそれ以上の他の無線装置が５０６で送信した接続データを受信したことを示す受信確認を受信する。全ての受信確認を受信していない場合、５１０において、受信確認を受信していないモバイル装置に対して接続データを再送する。５０９８において、全ての受信確認を受信したと判定すると、５０７で受信した接続データを使用して他のモバイル装置とのＰ２Ｐセッションを確立する。

予備通信チャンネルを確立して利用する装置及び方法
最新のモバイル装置は、種々の異なる通信チャンネル上で通信できる。例えば、Ａｐｐｌｅ ｉＰｈｏｎｅ（商標）は、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ，ｇ，ｎネットワーク）、３Ｇネットワーク（例えば、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）ネットワーク、Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐリンク Ｐａｃｋｅｔ Ａｃｃｅｓｓ（ＨＳＵＰＡ）ネットワーク等）、及びＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク（パーソナルエリアネットワーク（ＰＡＮ）として公知）上を通信できる。別のモバイル装置は、ＷｉＭＡＸ、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（ＩＭＴ） Ａｄｖａｎｃｅｄ、及びＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ） Ａｄｖａｎｃｅｄ等の追加的な通信チャンネル上で通信できるであろう。

作動時、最新のモバイル装置は、利用可能なチャンネルセットの間の１つの主要通信チャンネルを選択する。例えば、モバイル装置は、１つが利用可能な場合には大抵Ｗｉ−Ｆｉ接続を選択し、Ｗｉ−Ｆｉが利用できない場合にはセルラーデータ接続（例えば、ＵＴＭＳ接続）を選択するように構成される。

本発明の１つの実施形態において、モバイル装置のグループは、最初は標準ＩＣＥ接続データ交換を使用して及び／又は前述の接続データ交換技術を使用して一次ピアツーピア（Ｐ２Ｐ）通信チャンネルを確立する。次に、モバイル装置は、一次チャンネル上で接続データを交換して、一次チャンネルが故障した場合の予備チャンネルとして使用する１つ又はそれ以上の二次通信チャンネルを確立することができる。１つの実施形態において、二次通信チャンネルは、このチャンネル上で「ハートビート」パケットを定期的に送信することで、ＮＡＴファイアウォールを通ってオープンのままである。

本明細書で使用する場合、通信「チャンネル」は２つのモバイル装置の間の全ネットワーク経路を呼び、通信「リンク」は通信経路で使用する特定の接続の１つを呼ぶ。例えば、装置ＡがＷｉ−Ｆｉ接続を使用してインターネットに接続され、装置Ｂが３Ｇ接続を使用してインターネットに接続される場合、装置Ａと装置Ｂとの間の「チャンネル」は、Ｗｉ−Ｆｉリンク及び３Ｇリンクで規定され、装置ＡはＷｉ−Ｆｉ通信「リンク」を有し、装置Ｂは３Ｇ通信リンクを有する。従って、装置ＡがＷｉ−Ｆｉリンクから３Ｇリンクに切り替わると、装置Ａと装置Ｂとの間の「チャンネル」は、装置Ｂの３Ｇリンクが同じ状態のままであるにもかかわらず変更される。

図６を参照して、モバイル装置が一次及び二次通信チャンネルを確立する特定の実施例を説明する。しかしながら、本発明の基本的原理は、図６の通信リンク及び通信チャンネルの特定のセットに限定されないことに留意されたい。

図６において、モバイル装置Ａ６０１は、ＮＡＴデバイス６１１を備える通信リンク６０５上及びＮＡＴデバイス６１２を備える通信リンク６０６上でネットワーク６１０（例えば、インターネット）に接続できる。同様に、装置Ｃ６０３は、ＮＡＴデバイス６１３を備えた通信リンク６０９上及びＮＡＴデバイス６１３を備えた通信リンク６１０上でネットワーク６１０に接続できる。例示的かつ非限定的に、通信リンク６０５及び６０９は３Ｇ通信リンクとすること、及び通信リンク６０６及び６１０はＷｉ−Ｆｉ通信リンクとすることができる。

結果的に、本実施例において、モバイル装置Ａとモバイル装置Ｂとの間で確立できる４つの異なる通信チャンネルが存在するが、第１のチャンネルはリンク６０５及び６０９を使用し、第２のチャンネルはリンク６０５及び６１０を使用し、第３のチャンネルはリンク６０６及び６０９を使用し、第４のチャンネルはリンク６０６及び６１０を使用する。１つの実施形態において、モバイル装置Ａ及びＢは、優先順位決定スキームに基づいてこれらのチャンネルの中の１つを一次通信チャンネルとして選択でき、３つの残りのチャンネルを予備通信チャンネルとして選択できる。例えば、１つの優先順位決定スキームは、最大の帯域幅をもつチャンネルを一次チャンネルとして選択して、残りのチャンネルを二次チャンネルとして使用することができる。２つ又はそれ以上のチャンネルが同程度の帯域幅をもつ場合、優先順位決定スキームは、一番安価なチャンネル（ユーザが１つ又はそれ以上のチャンネルを使用するために料金を払っていると想定すると）の選択を含むことができる。もしくは、優先順位決定スキームは、一番安価なチャンネルを一次チャンネルとして選択すること、及び各チャンネルの料金が同じ場合は最大の帯域幅のチャンネルを選択することができる。本発明の基本的原理に従う種々の異なる優先順位決定スキームを実施できる。

モバイル装置Ａ６０１及びＣ６０３は、前述の技術を利用して一次通信チャンネルを確立することができる（例えば、ＣＤＸサービス１１０により接続データを交換することで）。もしくは、モバイル装置６０１、６０３は、標準Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＩＣＥ）トランザクションを実行して接続データを交換することができる。一次チャンネルの確立方法に関わらず、一度確立されると、モバイル装置Ａ６０１及びＣ６０３は、一次通信チャンネル上で二次通信チャンネルに関する接続データを交換できる。例えば、図６の一次通信チャンネルが、通信リンク６０６及び通信リンク６０９を含む場合、この接続は一度確立すると通信リンク６０５及び６０９を含む二次通信チャンネルに関する接続データを交換するために使用できる。本実施例において、一次通信チャンネル上で交換される接続データは、モバイル装置の各々に関するパブリック及びプライベートＩＰアドレス／ポートを含む、ＮＡＴトラバーサルデータ並びにＮＡＴ６１１及びＮＡＴ６１３に関するＮＡＴタイプデータを含むことができる。

二次通信チャンネルが確立されると、ハートビートパケットを使用してオープンのままになる。例えば、装置Ａは、定期的に小さな「ハートビート」パケットを装置Ｃに送信すること、及び／又は装置Ａは、定期的に小さな「ハートビート」パケットを装置Ｃに送信して二次チャンネルに使用するＮＡＴポートを開いたままとすることができる（ＮＡＴは、非作動時にポートを閉じる場合がある）。ハートビートパケットは、ペイロードのないＵＤＰパケットとすることができるが、本発明の基本的原理は、特定のパケットフォーマットに限定だれない。ハートビートパケットは、ペイロードヘッダーに自己識別形式フィールドを有するＵＤＰパケットとすることができ、随意的な、例えばチャンネルの有効期限値を含む、追加的にフォーマットされた情報を含むことができる。

図７に示すように、各モバイル装置６０１は、一次及び二次通信チャンネルのリストを包含するデータ構造７１０（例えば、テーブル、テキストファイル、データベース）を格納及び保持することができる。別個のエントリは各々の通信チャンネルに対して設けられており、このチャンネルを使用するのに必要な接続データ（例えば、プライベート／パブリックＩＰアドレス、ＮＡＴタイプ）、及びチャンネルの現在の状態（例えば、一次、二次１、二次２）を含んでいる。

１つの実施形態において、通信インタフェース７０１及び７０２は、通信リンク６０５及び通信リンク６０６上で通信するために使用される。モバイル装置６０１で故障検出モジュール７０５を実行して、特定の通信インタフェース／リンクの故障又は特定の閾値以下の機能低下を検出することができる。これに応答して、リンク管理モジュール７０６は、一次／二次接続データ７１０を読み取って、次に高い優先順序の二次チャンネルを一次チャンネルに昇格させる。二次チャンネルの優先順位決定は一次チャンネルに関して前述したのと同じ原理を使用して行うことができる（例えば、帯域幅、コスト、信頼性に基づいて）。二次チャンネルが選択されると、リンク管理モジュール７０６は、リンク故障識別子を他のモバイル装置のリンク管理モジュールに送信することができ、これらの装置に二次通信チャンネルを一次通信チャンネルに昇格させるよう指示する。次に、これらの装置は選択された一次チャンネルに関連する接続データを使用して開始することになる。

１つの実施形態において、二次通信チャンネルの１つへの切り替えを強制するために、一次通信チャンネルの完全な「故障」は必須ではない。例えば、１つの実施形態において、一次通信チャンネルが十分に機能低下した場合（例えば、特定の帯域幅、ビットレート、信頼性閾値以下）、本明細書で説明するように二次チャンネルへの変更を行うことができる。１つの実施形態において、二次チャンネルへの切り替えは、現在の一次チャンネルよりも二次チャンネルが良好な性能（例えば、帯域幅、ビットレート、又は信頼性）をサポートできる場合にだけ行われる。

図８ａは、図６と同じネットワーク構成を示すが、ネットワーク６１０に直接接続されると共にプライベートネットワーク接続６２０経由で装置Ｃ６０３に接続される、追加のモバイル装置Ｂ ６０２を備えている。プライベートネットワーク６２０は、例えば、装置Ｂ６０２と装置Ｃ６０３との間のＢｌｕｅｔｏｏｔｈ（登録商標） ＰＡＮ接続とすることができる。この実施例から分かるように、一次チャンネルから二次チャンネルへの切り替えは、ネットワークトポロジーを著しく変える場合がある。例えば、図８ｂに示すように、モバイル装置の一次チャンネル８０１が通信リンク６０９を含み（結果的に、装置Ａ、Ｂ、及びＣの間の直接接続になる）、二次チャンネルがプライベートネットワーク６２０を含む場合、プライベートネットワークを使用した装置Ａ及び装置Ｃの唯一の通信は装置Ｂを経由するので、ネットワークトポロジーは図８ｃに示すように変わる。これは３つの装置だけの単純な例であるが、多数の装置を使用することができ、一次及び二次通信チャンネルの間で切り替える場合、結果的に種々の異なるネットワークトポロジー構成がもたらされる。

図９は、二次チャンネルを確立して維持する方法の１つの実施形態を示す。１つの実施形態において、本方法は、モバイル装置のリンク管理モジュール７０６で実行できる。しかしながら、本方法は、特定のデバイス構成に限定されない。

９０１において、一次Ｐ２Ｐ通信チャンネルを選択する。前述のように、一次チャンネルは、予め定められた優先順位決定スキームに基づいて選択できる。例えば、特定の通信チャンネルタイプの優先度を他の通信チャンネルタイプよりも高くすることができる。また、チャンネルは、帯域幅、利用料金、及び／又は信頼性等の変数に基づいて優先順位を決めることができる。

９０２において、予備Ｐ２Ｐ通信チャンネルを確立する。１つの実施形態において、これは一次通信チャンネル上の全てのモバイル装置の間の共有接続データによって実現できる。９０３において、予備チャンネルを維持する。１つの実施形態において、これは二次通信チャンネル上でデータを定期的に送信することを含む（例えば、定期的なハートビートパケットの形態で）。

９０４において、一次Ｐ２Ｐチャンネルが故障した場合（例えば、特定のモバイル装置の通信リンクがダウンしたので、又はモバイル装置が通信リンクの圏外になったので）、９０５において、モバイル装置は優先順位が最も高い予備チャンネルを一次チャンネルに昇格する。１つの実施形態において、これは故障リンクのモバイル装置が、二次チャンネル上の他の装置にリンク故障の通知を送信することを含む。最後に、９０６において、予備チャンネルが一次チャンネルになり、処理は９０２に戻る（何らかの追加の予備チャンネルを発見して優先順位決定スキームに追加する）。

ピアツーピア（Ｐ２Ｐ）通信チャンネルを確立する招待サービスのための装置及び方法
図１０に示すように、ＣＤＸサービス１１０、仲介サービス１１１、及び招待サービス１１２（いくつかの実施形態は前記に説明した）に加えて、本発明の１つの実施形態は、レジストレーション／ディレクトリサービス１０５２、プッシュ通知サービス１０５０、及びリレーサービス１０５１を含むことができる。前述のように、１つの実施形態において、招待サービス１１２及び／又は仲介サービス１１１は、レジストレーション／ディレクトリサービス１０５２を使用して登録されたモバイル装置及びモバイル装置にデータをプッシュ配信するプッシュ通知サービス１０５０を特定することができる。１つの実施形態において、モバイル装置がネットワーク上でアクティブな場合、「プッシュトークン」（プッシュ通知アプリケーションの「通知サービスアカウント識別子」と呼ぶ場合もある）を、プッシュトークンをパスワード保護されたユーザＩＤ又は電話番号に関連付けることで、レジストレーション／ディレクトリサービス１０５２が保持するデータベースに登録する。プッシュトークンがレジストレーションディレクトリで特定されると（例えば、ユーザＩＤを用いた照会を行うことで）、プッシュ通知サービス１０５０は、プッシュトークンを使用してプッシュ通知をモバイル装置に送信することができる。１つの実施形態において、プッシュ通知サービスは、本出願人が設計した、例えば、前述のプッシュ通知アプリケーションで説明するＡｐｐｌｅプッシュ通知サービス（ＡＰＮＳ）とすることができる。

図１１は、２つのモバイル装置の間の直接Ｐ２Ｐ接続を確立するためにプッシュ通知サービス１０５１を使用する本発明の実施形態を示し、図１２は、リレーサービス１０５１を介したＰ２Ｐ接続を確立するために使用する実施形態を示す。以下に説明するように、Ｐ２Ｐ接続を確立するためにリレーサービス１０５１を使用するか否かの決定は、各モバイル装置の間で直接Ｐ２Ｐ接続を確立する実現可能性に基づく場合がある（例えば、ＮＡＴ互換性の問題に基づく）。

図１１を参照すると、１１０１において、モバイル装置Ａ１２０は、モバイル装置Ｂ１２１を招待するための招待リクエストを送信して、モバイル装置ＢをＰ２Ｐ通信セッション（例えば、共同ビデオゲーム、Ｐ２Ｐビデオチャット）に招待する。１つの実施形態において、招待状は、特定のオンラインアプリケーションの枠の中でモバイル装置Ｂ１２１（及び／又はモバイル装置Ｂのユーザ）を特定するユーザＩＤコードを含む。例えば、ユーザＩＤコードは、特定の多人数参加型Ｐ２ＰゲームのためのプレーヤーＩＤとすること、及び例えば、Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＵＩＤ）の形態とすることができる。もしくは、いくつかの実施形態において、ＩＤコードは、モバイル装置Ｂ１２１の電話番号とすることができる。ゲームＩＤコードは、モバイル装置Ａがモバイル装置Ｂに参加するように勧誘している多人数参加型ゲームを特定するために使用することができる。バケットＩＤは、ゲーム構成を特定するために使用できる（仲介サービスに関連して本明細書で説明するように）。

また、招待リクエスト１１０１は、モバイル装置Ａ１２０及び該モバイル装置Ａに関連するＮＡＴトラバース／接続データを特定するＩＤコードを含むことができる（例えば、モバイル装置Ａのパブリック／プライベートＩＰアドレス及びポート、及び装置ＡのＮＡＴデバイスのＮＡＴタイプ）。ＮＡＴトラバース／接続データ又はＮＡＴタイプデータは、招待リクエスト１１０１の前にモバイル装置Ａが既に決定している（例えば、図２ａから２ｃに関連して説明したような、ＮＡＴトラバース、ＮＡＴタイプ、及び接続データトランザクションによって）。前述のように、招待リクエスト１１０１は、ＨＴＴＰＳリクエストの形態とすることができる。更に、追加的なセキュリティのために、招待リクエスト１１０１は、事前に指定された認証オーソリティが署名したクライアント認証を含むことができる。

モバイル装置Ｂを特定するために使用される特定のＩＤコードタイプとは無関係に、招待サービス１１２はＩＤコードを受信し、１１０２において、招待サービス１１２は、ディレクトリサービス１０５２（図１１には示されていない）内で参照して、通知をモバイル装置Ｂプッシュ配信するために使用されるプッシュトークン（プッシュトークンＢ）等の、通知サービスアカウント識別子を特定することができる。１つの実施形態において、この参照動作は、複数のチェックを行って招待リクエストが許可されるべきか否かを決定するようになっている。最初に、モバイル装置Ａの識別コード（ＩＤ−Ａ）及び装置Ａのプッシュトークン（プッシュトークンＡ）は、ディレクトリサービスデータベース内の登録アソシエーションであること確認する。また、参照動作１１０２は、モバイル装置Ａのユーザがモバイル装置Ｂのユーザを招待できることを確認できる（例えば、モバイル装置Ｂのユーザは、Ｂの友人として登録された他のユーザがユーザＢを招待できることを規定できる、又は招待は許可しないこと規定できる）。１つの実施形態において、これらのチェックのいずれかが不合格になると、招待リクエストはキャンセルとなり、招待サービス１１２はモバイル装置Ａにエラーを戻す。

本実施形態では「プッシュトークン」が説明されているが、本発明の基本的原理は、「プッシュトークン」又はモバイル装置を認証して通知をプッシュ配信するための他の特定のデータ構造の使用に限定されないことに留意されたい。

１つの実施形態において、プッシュトークンを特定した後に、招待サービス１１２は、招待セッションに割り当てられて全ての追加的なトランザクションにおいてセッションを特定するために使用される、セキュアな一度だけの「セッショントークン」を生成できる。次に、セッショントークンのコピーがモバイル装置Ａ１２０に返信され、招待リクエストと一緒にモバイル装置Ｂへ送られる。１つの実施形態において、セッショントークンは、前述のチケットデータ構造と共に使用され、別の実施形態において、セッショントークンだけが使用される。

１１０３において、招待サービス１１２は、プッシュリクエストをプッシュ通知サービス１０５０に送信する。１つの実施形態において、プッシュリクエストは、モバイル装置Ａに関するＮＡＴトラバーサルデータ、装置ＡのＩＤコード、プッシュトークンＡ、装置ＢのＩＤコード、プッシュトークンＢを含むことができる。１つの実施形態において、この情報は、「チケット」データ構造内にパッケージ化すること及び前述のように暗号化することができる。他の実施形態において、このデータは、招待セッションＩＤと一緒に単純に送信される。

本実施例のモバイル装置Ｂ１２１はプッシュ通知サービス１０５０に登録されるので、プッシュ通知サービス１０５０は、１１０４において、招待リクエストをモバイル装置Ｂ１２１に位置付けてプッシュ配信することができる。プッシュ配信される招待リクエスト１１０４は、セッショントークン、モバイル装置ＡのＮＡＴトラバーサルデータ／接続データ、及びモバイル装置ＢのＩＤコードを含むことができる。これに応答して、招待リクエストに対して、モバイル装置Ｂは、前述のようにＮＡＴトラバースサービス又はＣＤＸサービス１１０を呼び出すことで、ネットワーク情報を決定できる（例えば、ＮＡＴトラバース／接続データ、ＮＡＴタイプ）。

１１０５において、モバイル装置Ｂは招待リクエストを受諾する。受諾１１０５は、招待サービス１１２のＨＴＴＰＳ呼び出しの形態とすることができ、（招待リクエストに関連して説明した）事前に指定された認証オーソリティが署名したクライアント認証を含むことができる。１つの実施形態において、受諾１１０５は、モバイル装置Ａ及びＢに関するＩＤコード、及びモバイル装置Ａ及びＢに関するＮＡＴトラバース／接続データ及び／又はＮＡＴタイプを含むことができる。また、受諾１１０５は、モバイル装置Ａ及びＢに関するプッシュトークン、及び／又はセッショントークンを含むことができる。１つの実施形態において、また、受諾１１０５は、前回失敗した直接接続試行からの再試行であるか否かの表示を包含することができる。しかしながら、他の実施形態において、受諾１１０５は、再試行表示を包含しない、その代わりに、Ｐ２Ｐ接続試行の失敗を検出すると、２つのモバイル装置のうちの一方は、特別な「リレー招待リクエスト」を招待サービス１１２に送信することができる。これに応答して、このサービスは、図１２（１２０１から始まる）に関連して以下に説明する一連のリレートランザクションを直接開始することができる。

１１０６において、招待サービス１１２は、互換性チェックを行ってモバイル装置Ａ及びＢの間の直接Ｐ２Ｐ接続が実現可能か否かを決定することができる。例えば、１つの実施形態において、モバイル装置Ｂから受信した 受諾１１０５が、前回失敗した直接接続試行（又は、所定回数の前回失敗した直接接続試行）からの再試行であることを示す場合、招待サービスは、直接Ｐ２Ｐ接続が実現不能であるとの結論を下すことができる。招待サービス１１２は、モバイル装置Ａ及びＢに関するＮＡＴタイプデータを比較して、モバイル装置Ａ及びＢのＮＡＴデバイスが直接Ｐ２Ｐ接続をサポートできるか否かを決定することができる。ＮＡＴタイプの特定の組み合わせは、Ｐ２Ｐ接続を確立するための互換性がないことが知られている。例えば、「ｆｕｌｌ ｃｏｎｅ」ＮＡＴは、直接Ｐ２Ｐ接続を確立するために、クローズ／ファイアウォールＮＡＴ以外の任意の他のＮＡＴタイプと一緒に使用できる。対照的に、「ｓｙｍｍｅｔｒｉｃ」ＮＡＴは、接Ｐ２Ｐ接続を確立するために、「ｆｕｌｌ ｃｏｎｅ」ＮＡＴと一緒にだけ使用できる。本発明の１つの実施形態の種々のＮＡＴタイプを組み合わせる実現可能性は、図１４に示すＮＡＴ互換性テーブル１４００に説明する。このテーブルにおいて、縦列は１つのモバイル装置（例えば、モバイル装置Ａ）のＮＡＴタイプを示し、横列は他のモバイル装置（例えば、モバイル装置Ｂ）のＮＡＴタイプを示す。セル内の「１．０」は関連の横列及び縦列のＮＡＴタイプに互換性があり、「０．０」はＮＡＴタイプに互換性がないことを示す。

１つの実施形態において、互換性チェック１１０６が直接Ｐ２Ｐ接続を実行不可能であると判定すると、招待サービス１１２は、図１２に関連して以下に説明するように、リレー参照リクエスト１２０１を送信できる。しかしながら、互換性チェック１１０６が直接Ｐ２Ｐ接続を実行可能と判定すると、招待サービス１１２は、モバイル装置Ａの招待へのモバイル装置Ｂの受諾を含むプッシュリクエスト１１０７をプッシュ通知サービス１０５０に送信できる。プッシュリクエスト１１０７、及びプッシュ通知サービス１０５０からモバイル装置Ａへの後続のプッシュ通信１１０８は、セッショントークン、並びにモバイル装置Ａ及びＢの両者のプッシュトークン、ＩＤコード、及び／又はＮＡＴトラバース／接続データを含むことができる。１つの実施形態において、この情報は、前述の「チケット」データ構造内にパケット化すること（例えば、図２ａから２ｃ及び関連の記載を参照）、及び固有キーを使用して暗号化することができる。もしくは、この情報は、固有招待セッションＩＤと一緒に単純に送信することができる。また、招待サービス１０５０は、直接接続が試行されることになるモバイル装置Ｂを通知することができる。

この段階で、モバイル装置Ａ及びＢは、直接Ｐ２Ｐ接続を確立するための十分な情報を有している。１つの実施形態において、前述のように、直接Ｐ２Ｐ接続はＣＤＸサービス１１０を使用して実現できる。例えば、モバイル装置Ｂは、自身の接続データをチケットＢに付加し、１１０９において、チケットＢ（接続データと一緒に）をＣＤＸサービスに送信する。このトランザクションの直前で、モバイル装置Ｂは、この接続データが最新であることを保証するために図２ｂに示すトランザクション２３５等のトランザクションを実行することができる。次に、ＣＤＸサービス１１０はチケットを認証し（例えば、前述のように、固有セッションキーを使用して）、モバイル装置Ｂの接続データを復元して、１１１０において接続データをモバイル装置Ａに送る。同様に、モバイル装置Ａは自身の接続データをチケットＡに付加し、１１１１において、チケットＡ（接続データと一緒に）ＣＤＸサービス１１０に送信する。このトランザクションの直前で、モバイル装置Ａは、この接続データが最新であることを保証するために図２ｂに示すトランザクション２３２等のトランザクションを実行することができる。次に、ＣＤＸサービス１１０はチケットを認証し（例えば、例えば、前述のように、固有セッションキーを使用して）、モバイル装置Ａの接続データを復元して、１１１２において、接続データをモバイル装置Ｂに送る。最後に、１１１３において、モバイル装置Ａ及びＢは、交換接続データを使用して直接Ｐ２Ｐ接続に参加する。

図１２を参照すると、互換性チェック１１０６ が直接Ｐ２Ｐ接続を実行できないと判定すると、招待サービス１１２は、リレー参照リクエスト１２０１をリレーサービス１０５１に送信して各モバイル装置がリレーホストを使用することを決めることができる。リクエスト１２０１は、モバイル装置Ａ及びＢに関するネットワーク情報（例えば、ＮＡＴトラバース／接続データ及び／又はＮＡＴタイプデータ）を含むことができ、リレーサービス１０５１はこの情報を使用して両モバイル装置に適切なリレーホストを選択する。図１３に示すように、リレーサービス１０５１の１つの実施形態は、複数のリレーホスト１３０２−１３０３及びリレーホストの各々に関するネットワーク情報を包含するリレーホストデータベース１３０１を含む。招待サービス１１２は、リレー参照リクエスト１２０１をリレー参照サービス１３００に送信し、リレー参照サービスはモバイル装置Ａ及びＢに関するネットワーク情報を使用するリレーホストデータベース１３０１を照会する。データベースの結果を受信すると、リレー参照サービス１３００は、選択されたリレーホスト１３０２−１３０３を特定するレスポンス１２０２を提供する。

１つの実施形態において、リレー参照レスポンス１２０２は、リレーサービスが生成したリレートークン、及びモバイル装置Ａ及びＢがリレー接続のために使用するリレーホスト１３０２−１３０３のネットワークアドレス（ＩＰアドレス／ポート）を含む。１つの実施形態において、リレートークンは、リレーセッションに関連付けされ、リレーサービス１０５１への接続時にリレーホスト１３０２−１３０３が使用してモバイル装置Ａ及びＢを認証するようになっている。トークンは、例えば、固有ＩＤリレーセッションＩＤコード、デジタル認証、及び／又はリレーセッションに関連付けされた固有暗号化キーを含む種々の形態をとることができる。

１２０３において、招待サービスは、リレー接続が行われるであろうという表示を含むリレーレスポンス１２０３をモバイル装置Ｂ１２１に送信する。１つの実施形態において、リレーレスポンス１２０３は、リレートークン及びリレーホストＢ１３０３に関するネットワーク情報を含むことができる。１つの実施形態において、レスポンス１２０３は、モバイル装置Ｂの受諾１１０５に応答して送られるので、モバイル装置Ｂに直接送ることができる（プッシュ通知サービス１０５０を迂回して）。

招待サービス１１２は、リレートークン及びリレーホストＢ１３０３に関するネットワーク情報を含む、リレーレスポンス１２０４をモバイル装置Ａに送信する。この場合、レスポンス１２０４は、トランザクション１２０５において、プッシュ通知サービス１０５０によって、モバイル装置Ａにプッシュ配信される。

１２０６において、モバイル装置Ａ１２０は、リレーホストＡ１３０２に関するネットワーク情報を使用して、リレーサービス１０５１との接続を確立できる。同様に、１２０７において、モバイル装置Ｂ１２１は、リレーホストＢ１３０３に関するネットワーク情報を使用して、リレーサービス１０５１との接続を確立できる。このトランザクションの各々において、モバイル装置Ａ及びＢの任意のＮＡＴファイアウォールに新しいホールが開けられて、モバイル装置Ａ及びＢに関するＮＡＴトラバース／接続データはリレーサービス１０５１で決定されて、それぞれモバイル装置Ａ及びＢに返信される（例えば、装置のパブリックＩＰ／ポートを決定することで）。１つの実施形態において、リレーサービス１０５１及びモバイル装置Ａ及びＢは、当業者には理解できるように、ＮＡＴ又はファイアウォールの背部の構成要素がＴＣＰ又はＵＤＰ接続上で到来データを受信できるようにする、Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙ ＮＡＴ（ＴＵＲＮ）プロトコルを実装する。

１２０８において、モバイル装置Ａは、１２０９においてプッシュ通知サービスに送られて、１２１０においてモバイル装置Ｂにプッシュ配信される、リレーアップデートを招待サービス１１２に送信する。同様に、１２１１において、モバイル装置Ｂは、１２１２においてプッシュ通知サービスに送られて、１２１３においてモバイル装置Ａにプッシュ配信される、リレーアップデートを招待サービス１１２に送信する。モバイル装置Ａが送信するリレーアップデートは、セッショントークン、各装置のＩＤコード、及び１２０６及び１２０７におけるリレーで決定されるＮＡＴトラバース／接続データ（つまり、モバイル装置Ａを用いて自身のＮＡＴトラバース／接続データをモバイル装置Ｂに送る、又はその逆）を含むことができる。１つの実施形態において、リレーアップデート動作は、各モバイル装置のＮＡＴ情報が変化する可能性があるので行われる。

最後に、１２１４及び１２１５において、モバイル装置Ａ及びＢはそれぞれリレーサービス１０５１を介してＰ２Ｐ接続を確立する。１つの実施形態においてモバイル装置Ａがモバイル装置ＢのＮＡＴトラバース／接続データをリレーサービス１０５１に送った場合に又はその逆の場合にリレー接続が確立されるので、リレーサービスは、各ピアのリレーホスト１３０２−１３０３への正しい経路を決定できる。

前述の技術を利用して、招待サービス１１２は、ステートレスサービスとして実行することができ、これは膨大な数のモバイル装置を備える大規模システムであっても、本質的に拡張性があり回復機能がある。例えば、プッシュ通知サービス１０５０は、本質的にコンテンツを登録されたモバイル装置に位置付けしてプッシュ配信できるので、招待サービスは、各装置の現在の位置を追跡する必要はない。更に、装置が各リクエスト及びレスポンスと一緒に全セッション状態データを送信するので、招待サービスは、何らかの事前接続状態情報を保持する必要がなく、招待サービスの記憶及び処理要件が低減する。このような実施例は、大規模システムに特に有用である。

ユーザをオンラインセッションに仲介するためのシステム及び方法
図１５に示すように、仲介サービス１１１の１つの実施形態は、マッチリクエストを受信してマッチレスポンスをモバイル装置１２０−１２２にプッシュ配信する仲介ディスパッチャ１５０１と、マッチリクエストをリクエストテーブル１５０２に格納すると共に適合可能なセットデータを適合可能なセット識別子（ＭＳＩ）テーブル１５０３に格納するためのデータベース１５１２と、データベース１５１２からのマッチリクエストを取り出し、マッチング動作を行って、マッチ結果をデータベース１５１２に戻す１つ又はそれ以上の仲介部１５１０を含むことができる。しかしながら、本発明の基本的原理は、図１５に示す特定のアーキテクチャに限定されないことに留意されたい。

１つの実施形態において、仲介ディスパッチャ１５０１は、仲介サービス１１１のインタフェースとして機能して、モバイル装置１２０−１２２からのリクエストを受信し、このリクエストを命令に翻訳してリクエストをデータベース１５１２に格納し、データベース１５１２からのマッチ結果を読み出して、この結果を翻訳してモバイル装置１２０−１２２に伝える。

作動時、新しいマッチリクエストが届くと、仲介ディスパッチャ１５０１は、リクエストをリクエストテーブル１５０２内の横列に格納することができる。１つの実施形態において、ディスパッチャ１５０１は、各マッチリクエストに、単純に図１５に「Ａ」、「Ｂ」、及び「Ｃ」（モバイル装置Ａ、Ｂ、及びＣに対応する）で示すリクエストＩＤ（ＲＩＤ）コードを割り当てる。単純化のために図１５では文字記号を用いて示すが、ＲＩＤコードは、文字列、整数、又はデータベース内のマッチリクエストを追跡するのに適する他の種々の形式の変数とすることができる。

各マッチリクエストには、リクエストテーブル１５０２に記憶される、適合可能なセット識別子（ＭＳＩ）値を割り当てることができる。１つの実施形態において、ＭＳＩは、照会がリクエストされた特定のアプリケーション及び／又はそのアプリケーションのために使用される機器構成パラメータを特定できる。例えば、１２：４のＭＳＩ値は、識別子「１２」を有する特定の多人数参加型ゲームを特定すること、及び識別子「４」を有するゲームに関する特定の機器構成を特定することができる。詳細には、ＩＤコード「１２」は特定の多人数参加型レーシングゲームを特定し、ＩＤコード「４」はレーシングゲームに関する特定のレーストラック、速度、プレーヤー経験レベルを規定することができる。１つの実施形態において、アプリケーション開発者は、このＭＳＩ値を用いて何らかのアプリケーション機器構成パラメータを規定する選択肢を提供する。１つの実施形態において、ＭＳＩを直接規定する以外に、アプリケーション開発者は、ゲームＩＤ（特定のゲームを識別するための）及びバケットＩＤ（特定のゲーム構成を識別するための）を規定するが、これらの値は仲介ディスパッチャ１５０１によりＭＳＩ値にマッピングされる。

更に、単一のＭＳＩ内で複数の異なるＭＳＩ値を用いて、複数の異なる機器構成パラメータを規定できる（例えば、１２：４：１は、１２＝レーシングゲーム、４＝トラック、及び１＝経験レベルと表すことができる。）。以下に詳細に説明するように、１つの実施形態において、各ＭＳＩは、仲介部１５１０が使用して、仲介動作を行うことができるマッチリクエストセットを特定するようになっている（例えば、リクエストは、ＭＳＩに基づいてグループ化され、マッチは各ＭＳＩグループ内で行われる）。１つの実施形態において、各ＭＳＩは、ディスパッチャによって動的に変更／選択でき、異なるマシンパーティションを特定するパーティションＩＤを含むことができる。例えば、特定のＭＳＩが過負荷になると、ディスパッチャは、ＭＳＩを２つ又はそれ以上の異なるサーバ及び／又は格納パーティションの間に分割することができる（例えば、最後の数字がパーティション１及び２を特定する４：３：１及び４：３：２という記号表示を用いて）。次に、異なる仲介部は、異なるサーバの各々の異なるＭＳＩの各々からのリクエストを独立して読み出して処理することができる。

図１５に示すように、マッチリクエストデータは、各リクエストに関するリクエストテーブル１５０２内に格納できる。リクエストデータは、仲介判定を提供するのに適する任意のデータ、及び／又はネットワーク上でリクエストを開始するモバイル装置にアクセスするのに必要な任意のデータを含むことができる。例えば、１つの実施形態において、各リクエストのマッチリクエストデータは、リクエストを開始するモバイル装置に関するＮＡＴタイプデータ及び／又はＮＡＴトラバース／接続データを含む。また、デバイス接続速度（１００ｋｂｐｓ、１Ｍｂｐｓ等）、接続タイプ（例えば、３Ｇ、ＥＤＧＥ、ＷｉＦｉ）、装置の位置（例えば、地理位置情報技術で決定される）、言語（英語、スペイン語等）、及び／又はユーザ嗜好等の、リクエストデータの他のタイプはリクエストテーブル１５０２内に格納できる。リクエストデータは、各モバイル装置１２０−１２２で決定でき、各マッチリクエストと一緒に仲介ディスパッチャ１５０１に送信される。例えば、各モバイル装置は、自身の接続データ、接続タイプ、装置の位置等を種々の技術を用いて決定できるが、その中のいくつかは本明細書で説明する（例えば、ＮＡＴトラバースサーバを用いて通信を行いＮＡＴトラバース／接続データを決定する、ＧＰＳを用いて装置位置を決定する、ＨＴＴＰ情報を読み取って言語を決定する等）。

図１５に示すように、１つの実施形態において、各アクティブＭＳＩは、ＭＳＩテーブル１５０３の横列に割り当てることができる。１つの実施形態において、新しいリクエストが届くと、リクエストをリクエストテーブル１５０２に追加することに加えて、ディスパッチャ１５０１は、ＭＳＩテーブル１５０３をチェックして、そのリクエストに関してＭＳＩが既に存在するか否かを判定する（つまり、同じＭＳＩを有する他のリクエストが既に届いているか否か）。一致するＭＳＩが見つからない場合、ディスパッチャ１５０１は、ＭＳＩテーブル１５０３に新しいリクエストのための新しいエントリを作成することができる。一致したＭＳＩが見つかると、前述のように、ディスパッチャは新しいリクエストをリクエストテーブル１５０２に単純に追加する。

リクエストテーブル１５０２及びＭＳＩ テーブル１５０３が仲介ディスパッチャ１５０１によって更新されると、仲介モジュール１５１０のインスタンス（以下では単に「仲介部１５１０」と呼ぶ）は、データを取り出して仲介動作を行う。複数の仲介部のインスタンスを同時に実行して仲介リクエストを処理することができ、単一の仲介部１５１０は複数の異なるＭＳＩグループ上で同時に複数の仲介動作を処理することができる。

１つの実施形態において、仲介部１５１０が利用可能になると（例えば、ＭＳＩグループのマッチング動作の完了後、又は初期化後）、ＭＳＩテーブル１５０３に問い合わせて、新しいＭＳＩを特定して処理する。図１５において、仲介部ＩＤフィールドのＭＳＩ３：１に関する「Ｎ／Ａ」値は、このＭＳＩを処理するための責任が仲介部に割り当てられていないことを示す。１つの実施形態において、各ＭＳＩエントリは、タイムスタンプが付与されており、仲介部１５１０は、最も古いタイムスタンプのＭＳＩを選択する。

１つの実施形態において、仲介部１５１０が特定のＭＳＩに対して責任を引き受ける場合、ＭＳＩテーブル１５０３の仲介部ＩＤコードを更新して、ＭＳＩのリース期間（例えば、５秒）を規定する。１つの実施形態において、仲介部１５１０は、ＭＳＩに適するようにリース値を継続的に更新する。リース値は、故障した仲介部１５１０に割り当てられたＭＳＩを特定するために使用できる。例えば、リース値が期限切れの場合、該当ＭＳＩは、ＭＳＩテーブル１５０３がＭＳＩは既に仲介部に割り当てられていると示唆するにもかかわらず、新しい仲介部から要求される場合がある。

仲介部１５１０がＭＳＩに関して責任を引き受ける場合、リクエストテーブル１５０２に問い合わせて、該当ＭＳＩに関連するリクエストをメモリに読み出す。次に、仲介部１５１０は、マッチング動作を行ってマッチ基準セット（例えば、以下に説明するような）に基づいてユーザとモバイル装置とをマッチする。仲介部１５１０は、リクエストテーブル１５１２を更新して、モバイル装置のマッチをいつ行ったかを示すようになっている。例えば、仲介部は、ＭＳＩ値をリクエストテーブル１５１２のＭＳＩ縦列から取り除いて、マッチが完了したことを表す所定値を入力することができる。更に、仲介部１５１０は、各参加者に関する「リクエストデータ」フィールドを更新して、この参加者がマッチされた他の参加者を示すことができる（例えば、他の参加者と通信するために必要なＮＡＴトラバース／接続データを書き出すことで）。

ディスパッチャ１５０１は、定期的にリクエストテーブル１５０２に問い合わせして、完了したマッチを特定することができる。完了したマッチに応答して、ディスパッチャ１５０１は、マッチに含まれるモバイル装置にプッシュ通知を送信することができる（例えば、本明細書及び同時継続出願に説明するプッシュ通知技術を用いて）。１つの実施形態において、プッシュ通知は前述の「チケット」データ構造を含む。次に、モバイル装置は、各チケットの各々を使用して、前述のように、ＣＤＸサービス１１０によって接続データを交換することができる。

プッシュ通知を使用することに加えて、１つの実施形態において、モバイル装置１２０−１２２は、定期的にディスパッチャ１５０１に問い合わせして、マッチが行われたか否かを判定する。定期的問い合わせは、プッシュ通知がモバイル装置に到達していない場合に有効である。しかしながら、プッシュ配信アーキテクチャを使用するので、定期的問い合わせは、比較的低速に設定できるので、仲介サービス１１１の負荷を低減できる。

図１６は、２つのモバイル装置Ａ及びＢを仲介サービス１１１でマッチする方法の例示的な実施形態を示す。図１７ａ−１７ｄは、リクエストテーブル１５０２及びＭＳＩテーブル１５０３に対する例示的な更新を示すが、これは本方法が進行すると生じる。

１６０１において、マッチリクエストをモバイル装置Ａから受信する。１６０２において、図１７ａに示すように、モバイル装置Ａのリクエストをリクエストテーブルに入力し、新しいＭＳＩエントリ（ＭＳＩ１：１）をＭＳＩテーブルに入力する（既に存在しない場合）。１６０３において、マッチリクエストをモバイル装置Ｂから受信して、１６０４において、図１７ｂに示すように、モバイル装置Ｂのマッチリクエストを同様にリクエストテーブルに入力する。

１６０５において、特定の仲介部インスタンス（仲介部＃Ｎ）は、ＭＳＩテーブルをチェックして、他の仲介部インスタンスによってＭＳＩ１：１が要求されていないこと検出する。もしくは、仲介部は、前回ＭＳＩで作動した仲介部が故障していることを示す期限切れリースをもつＭＳＩテーブルエントリを検出する。１つの実施形態において、期限切れリースをもつＭＳＩエントリは、新しいＭＳＩエントリ（仲介部が割り当てられていない）よりも高い優先順位が与えられる。更に、１つの実施形態において、比較的古いＭＳＩエントリには比較的新しいＭＳＩエントリよりも高い優先順位を与えることができる。仲介部がＭＳＩを選択する方法には無関係に、選択が行われると、図１７Ｃに示すように、識別子及びＭＳＩエントリに関する新しいリース値セットが付与される（例えば、例示的にリース値５秒を用いて）。次に、仲介部は、リクエストテーブルに問い合わせて、処理できるようにＭＳＩをもつリクエストテーブルエントリをメモリに読み出すことができる。

１６０６において、仲介部は、一連のマッチング動作を行ってリクエストに対して適切に適合するものを選択する。適合動作のいくつかの実施形態は、図１８を参照して以下に説明する。簡単には、１つの実施形態において、「適切な」適合を決定するために評価される変数は、ＮＡＴタイプ（例えば、「ｆｕｌｌ ｃｏｎｅ」、「ｐｏｒｔ ｒｅｓｔｒｉｃｔｅｄ」、「ｓｙｍｍｅｔｒｉｃ」）、接続タイプ（例えば、ＷｉＦｉ、３Ｇ、Ｅｄｇｅ）、ユーザ言語（ＨＴＴＰリクエストの受諾言語ヘッダーから得る）、及びマッチリクエストの各々の経時を含むことができる。一般に、仲介部１５１０は、互換性のあるＮＡＴタイプ（しかし、以下に説明するようにリレーサービスを使用する場合もある）、同じ接続タイプ、及び同じ言語をもつモバイル装置をマッチしようと試行する。１つの実施形態において、仲介部１５１０は、マッチリクエストの経時に基づくマッチング要件に対してより自由とすることができる（つまり、古いリクエストにはより自由にマッチング制限を付与できる）。

図１６に戻ると、１６０７において、マッチング決定に続いて、仲介部１５１０は、図１７ｄに示すように、リクエストテーブルを更新して、マッチが完了したことを示すことができる。更新の一部として、仲介部は、モバイル装置Ａ及びＢのリクエストデータを更新することもできる。例えば、１つの実施形態において、仲介部１５１０は、モバイル装置ＢのＮＡＴトラバース／接続データをモバイル装置Ａのリクエストデータの縦列に書き込み、モバイル装置ＡのＮＡＴトラバース／接続データをモバイル装置Ｂのリクエスト縦列に書き込む。

１６０８において、ディスパッチャ１５０１は、リクエストテーブルから読み出してマッチされたリクエストエントリを特定することができる。１つの実施形態において、モバイル装置Ａ及びＢがマッチされていることを検出すると、リクエストデータを読み出して（前述のように仲介部が更新）、モバイル装置Ａ及びＢに対する通知を生成する。１つの実施形態において、通知は前述の暗号化された「チケット」データ構造であり、各モバイル装置に関するＮＡＴトラバース／接続データを含む。前述のように、１つの実施形態において、プッシュ通知サービス１０５０を使用してこの通知をモバイル装置Ａ及びＢにプッシュ配信する。更に、モバイル装置Ａ及びＢは、ディスパッチャ１５０１を定期的にポーリングして、マッチが行われたか否かを決定する。本実施形態において、ポーリング技術は、比較的低速で行って何らかの理由でモバイル装置の１つに上手くプッシュ配信されなかったマッチを特定することができる。ポーリングリクエスト負荷を管理するためにプッシュ通知を用いると、さもなければモバイル装置からのポーリングリクエストに負担をかける、仲介サービス１１１の負荷が著しく低下する。

１６０８において判定される同じＭＳＩに関する追加のマッチリクエストが未決定の場合、仲介部は、ＭＳＩ内のモバイル装置／ユーザのマッチを続けることができる。１６１０において、仲介部はＭＳＩテーブル１５０３内のリース値をリセットできる。１６１１において、追加のマッチが実行されて、リクエストテーブルが更新される（前述のように）。１６１２において、追加のマッチは、リクエストテーブルから読み出されて追加のモバイル装置が更新される（前述のように）。ＭＳＩに関する未決定の追加のマッチリクエストが無い場合、１６０９において、ＭＳＩエントリはＭＳＩテーブルから取り除かれる（例えば、ディスパッチャ及び／又は仲介部のいずれかからの命令を消去することで）。

図１８は、モバイル装置／ユーザの間のマッチを行う方法の１つの実施形態を示す（図１６の動作１６０６）。１８０１において、全ての最新のＭＳＩリクエスト（例えば、特定のアプリケーション／バケット組み合わせに関する）を２つ１ペアに配置する。１８０２において、各ペアのマッチ「適合」を評価して、１８０３において、各ペアは、降順適合によってソートする。「適合」は、ＮＡＴタイプ（例えば、「ｆｕｌｌ ｃｏｎｅ」、「ｐｏｒｔ ｒｅｓｔｒｉｃｔｅｄ」、「ｓｙｍｍｅｔｒｉｃ」）、接続タイプ（例えば、ＷｉＦｉ、３Ｇ、Ｅｄｇｅ）、ユーザ言語（ＨＴＴＰリクエストの受諾言語ヘッダーから得る）、及びマッチリクエストの各々の経時を含むが限定されるものではない、複数の異なる変数に基づいて評価する。仲介判定で考慮できる他の変数としては、各モバイル装置の位置（例えば、特定の位置のユーザにマッチする試行に関する）、最小及び／又は最大プレーヤー要件（例えば、ユーザ及び／又はアプリケーションで規定される）、ＭＳＩに含まれる１人又はそれ以上のユーザが「友人」か、又は以前Ｐ２Ｐ接続に参加したか否か（例えば、マッチする「友人」の好み、又は前回の知人に関する）、及びアプリケーションに対するユーザの経験（例えば、多人数参加型ゲームに関して、各ユーザのリーダーボードランキングは、同じようにマッチする好みをもつに経験のあるユーザのファクタであろう）を挙げることができる。

以下のテーブルＡに示すように、１つの実施形態において、「適合度」の評価値は、０．０と１．０との間の数値である。浮動小数点値を使用すると、各基準に関する適合度の正規化が可能になる。浮動小数点演算を防ぐために、適切な評価値に非正規化整数値を使用できるので適合値を比較できる。

１つの実施形態において、全ての基準は、コンパチブルであるか（１．０の正規化値を有している）又はコンパチブルでないか（１．０未満の正規化値を有している）のいずれかである２進適合度を有している。しかし、これらは適合度が経時的に変わる可能性がある（以下に説明する）所要の基準と考えることができる。変数として位置が追加されると、最良適合は所要基準にマッチする最も近いプレーヤーに対するものとなる。
テーブルＡ
マッチ適合度

１つの実施形態において、適合度は、前記基準の各々に関する（正規化重み付け＊経時ファクタ値）の合計である。経時ファクタ値は、値「１」から始まり、所定時間が経過すると増加する。時間の経過と共に継続的に増加することができる（例えば、定期的に所定量だけ増加する）。１つの実施形態において、前述の経時ファクタ値を使用する代わりに、以下に説明するように、経時閾値を設定することができる。接続タイプ及び言語等の所定変数の正規化／重み付けは、前述の所定の経時閾値に加えることができる（マッチしなくても）。

１つの実施形態において、一対のリクエストＡ及びＢの間の「適合度」は、Ｂに対するＡの適合度及びＡに対するＢも適合度の平均である。更に、各ファクタに関するＢに対するＡの適合度は、Ａの経時に基づいて調整できる（又はその逆）。１つの実施形態において、１．０の適合度は、コンパチブルなマッチに必須である。このことはＡ及びＢが、ＮＡＴ互換性、接続タイプ、及び言語がマッチする（１．０の正規化値がもたらす）場合にだけ、又はＡ及び／又はＢが、前述のいくつかの変数（例えば、接続タイプ及び言語）が事実上無視されるように（前述の経時ファクタ値又は以下の閾値のいずれかを使用して）経時した場合に、マッチするであろうことを意味する。
テーブルＢ
経時

経時閾値は、前述のテーブルＢに説明するように設定できる。各経時閾値を超えると（つまり、リクエストが特定の閾値よりも古くなる）、経時ファクタ値は逐次的に大きな値に増加する（例えば、１．５、２．０等）。別の方法として又は追加的に、別の経時閾値を超える場合、特定の変数に関する重み付けをマッチング判定に加えることができる（例えば、以下に説明するように接続タイプ及び言語）。

１つの実施形態において、テーブルＢで規定するリクエスト経時制限は、マッチ流動率に応じて調整される。１つの実施形態において、流動率は、特定の時間単位毎に行われるマッチの数として規定される（例えば、１０秒毎、１分毎）。つまり、流動率は、特定のＭＳＩセットがどれだけビジーであるかの指標である。１つの実施形態において、このセットがビジーであるほど、前述の低い閾値の各々は、前述のテーブルＢにおいて早期の良好なマッチの可能性を高めるように設定され、仲介部の負荷を低減するようになっている。更に、所定のＭＳＩセットの負荷はエンドユーザに提供できるので（例えば、数値データにマッチする推定時間の形態で）、エンドユーザは、特にビジーな多人数参加型ゲームに参加しようと試みるか否かを選択できる。負荷値は、ユーザに対してプッシュ通知の形態で提供できる。

テーブルＡの各変数を参照すると、１つの実施形態において、ＮＡＴ互換性は、図１４に示すＮＡＴ互換性表１４００で決定する。この表に基づいて２つのＮＡＴの互換性があると判定すると、ＮＡＴ互換性重み付けを加えることができる。
テーブルＣ
接続タイプ

接続タイプは、テーブルＣに示す表を用いて評価できる。本実施例において、装置Ａ及びＢの接続タイプが同じ場合（セル内で１．０で示す）、テーブルＡからの重み付けされた接続タイプ値は、適合度判定に含めることができる。前述のように、各リクエストの経時を使用して、接続タイプ判定に影響を与えることができる。例えば、１つの実施形態において、接続タイプの適合値は、閾値１、２、及び３での経時に関するテーブルＣの行列を用いて選択する。閾値４又はそれ以上の経時に関して、接続タイプは１．０に設定でき（非マッチング接続タイプであっても）、対応する重み付けされた接続タイプ値を加えることができる。接続「タイプ」が特定の実施形態で使用されるが、接続速度を決定して接続タイプと一緒に、又はその代わりに使用できる。例えば、特定の範囲の各接続速度は「コンパチブル」と見なすことができる（例えば、０−１００ｋｂｐｓ、１００−５００ｋｂｐｓ、５００−１０００ｋｂｐｓ、１０００−１５００ｋｂｐｓ）。また、本明細書で説明する何らかのマッチング変数は、重み付けとしてマッチ適合演算に加えて、前述のように経時処理することができる。

１つの実施形態において、プレーヤー言語は、優先ｑファクタと一緒に１つ又はそれ以上の言語を含むＨＴＴＰリクエスト受諾言語ヘッダーから得ることができる。ディスパッチャは、最も好ましい言語を抜き出してこの情報を仲介部へ送る。１つの実施形態において、テーブルＡからの重み付けされた言語値は、言語が同じ場合には１．０に設定され、同じでない場合は０．０に設定される。しかしながら、１つの実施形態において、重み付けされた言語値は、言語が異なる場合で経時が所定の閾値以上である場合は適用することができる（例えば、テーブルＢの経時が閾値２か又はそれ以上の場合）。

１つの実施形態において、マッチは、互換性のないＮＡＴタイプの２つのユーザ間で行うことができる。例えば、仲介部が特定のＭＳＩに関してマッチング困難なユーザを有する場合、所定時間後に、前述の技術を使用して、リレーサービス１０５１経由の接続経路を定めることができる。このような方法で、リレーサービス１０５１は、互換性のないＮＡＴタイプにもかかわらず経時マッチの発生を可能にする圧力バルブとして機能する。また、リレーサービス１０５１は、１つ又はそれ以上の失敗したマッチ試行の検出に応じて使用できる。本実施形態において、モバイル装置が送出した各マッチリクエストは、１つ又はそれ以上の失敗に終わったマッチが以前に試行されたか否かの表示を含むことができる。

種々の追加のマッチ基準を評価して、例示的かつ非限定的に、マッチをリクエストしている任意のユーザが友人であるか否かの表示を含むマッチ適合判定の一部として重み付け値を提供できる。例えば、仲介部１５１０は、マッチ適合演算に「友人」重み付けを加えることで、「友人」であるユーザに関する何らかのリクエストにマッチしようと試みることができる。同様に、友人の友人も重み付けすることができる（例えば、２又はそれ以上の分離度で）。更に、特定のゲームに関して、プレーヤーは他のプレーヤーを格付けすることができ、仲介部は、マッチを行う際にこの格付けを評価することができる（ユーザを比較的高い格付けのプレーヤーにマッチし、ユーザを格付けが低いプレーヤーにマッチしない傾向でもって）。更に、ユーザの接続待ち時間を評価して（例えば、簡単なピング動作を使用して）、仲介判定の一部として使用することができる。

プレーヤーをマッチするために使用する更に他の変数は、装置タイプとすることができる。例えば、仲介部１５１０は、単に装置タイプでプレーヤーをマッチしようと試みることができる（例えば、ｉＰａｄｓ、ｉＰｏｄｓ、ｉＴｏｕｃｈｅｓ、ｉＰｈｏｎｅｓ、ＲＩＭ Ｂｌａｃｋｂｅｒｒｉｅｓ）。追加の変数としては、ユーザのリーダーボードランキング、現在地、現住所、年令、性別を挙げることができ、同じゲームコレクションは、同様にマッチ判定のために評価される（つまり、多くの場合、好みの傾向は、これらにユーザの間で同じ基準でマッチする）。最後に、ペアレンタルコントロールは仲介部１５１０で評価することができ、ユーザが適切なＭＳＩ及び同じ年令の他のユーザにだけマッチすることを保証できる。

仲介サービス１１１は、データサービス１００内で管理される１つ又はそれ以上のデータベースからの前述の任意の変数を読み出すことができる（例えば、図１９に関して以下に説明するデータベース１９２０を参照）。例えば、ユーザの友人データは友人サービスデータベースからアクセスでき、ユーザの年令、性別、ゲームコレクション等の他の情報は、１つ又はそれ以上の他のデータベースからアクセスできる（例えば、ユーザプロファイル、ゲームデータベース、リーダーボードデータベース）。１つの実施形態において、本明細書で説明する全てのサービスは、仲介判定を行うために使用される全ての種々の異なるユーザ／装置タイプを記憶するための同じ中央データベース（又はデータベースグループ）へのアクセスできる。

複数の特定の実施例を説明したが、本発明の基本的原理は、マッチのための適合レベルを決定するための何らかの特定の変数セットに限定されないことを理解されたい。１つの実施形態において、アプリケーションをシステム上で実行されるように設計するアプリケーションプログラマ及び本明細書で説明する方法は、異なるＭＳＩ基準を用いてリクエストをマッチングするために及び／又はグループ化するために自身の基準セットを規定できる。

図１８の方法に戻ると、各ペアの間のマッチ「適合」が判定されると、１８０３において、ペアは降順適合でソートする（例えば、適合度が最も高いペアはリストの最上部になる）。１８０４において「マッチセット」を特定の閾値を超える最も高い適合値をもつペアでシードする。前述のように、「閾値」は、テーブルＡに示す１．０の正規化値に設定できる。１８０５において、新しい見込みのあるパートナーを、マッチセットの中で１人又は全ての現在のメンバに関する、特定の閾値を超える適合値を有するマッチセットに加える。例えば、マッチセットが最初はＡ及びＢでシードされる場合、Ａ−Ｃ及び／又はＢ−Ｃの適合値が特定の閾値を超える場合にＣをマッチセットに加えることができる。１つの実施形態において、単一のマッチ適合が見込みのある相手に関する閾値以上の場合、この相手はマッチセットに加えることができる（つまり、必要であれば、この相手は適切なマッチ適合を有する１人の相手を介して全ての相手と通信することができるはずである）。１人又はそれ以上の新しい相手がマッチセットに追加されると、１８０６において判定されるマッチに関するサイズ要件を満たす場合、マッチ結果を格納して、１８０７においてレポートする（例えば、前述のように、リクエストテーブル１５０２を更新して通知を送信することで）。１つの実施形態において、単一のマッチリクエストは、複数のユーザを示すことがでる（例えば、以下に説明するように、マッチリクエストが招待シーケンスに続く場合）。この場合、サイズ要件は、マッチリクエストが示すユーザ数に基づいて評価される。サイズ要件を満たさない場合、処理は１８０５に戻り、新しい相手がマッチセットに追加される（つまり、１人又はそれ以上の現在のメンバセットに関する、特定の閾値を超えるマッチ適合を有する相手）。

１８０８において、マッチしたリクエストを仲介部１５１０で処理される現在のリクエストセットから取り除く。１８０９において、次にシードしたマッチセットを選択して、処理は１８０４に戻り別のマッチングを行う。図１８は連続した処理として示すが、本発明の基本的原理に依然として従いながら、複数のシードされたマッチセットを同時に処理することができる。

前記では別個のサービスとして説明するが、仲介サービス１１１及び招待サービス１１２は、２Ｐユーザに接続するために同時に作動することができる。例えば、１つの実施形態において、第１のユーザは、１人又はそれ以上の友人をオンラインセッション招待して、１人又はそれ以上の別のユーザとのマッチをリクエストすることができる（例えば、多人数参加型ゲームに関して、友人「Ｂｏｂ」を招待して、３人の別のプレーヤーをマッチする）。この場合、招待サービス１１２は、初めに第１のユーザの招待リクエストを処理して、第１のユーザ及び第１のユーザの友人に接続することができる。招待リクエストの結果は（例えば、成功したＰ２Ｐ接続）、ユーザのモバイル装置にレポートを返すことができる。次に、仲介サービス１１１は、第１のユーザのモバイル装置からの追加のプレーヤーをリクエストするマッチリクエストを受信することができる（又は、１つの実施形態において、招待サービスから直接、又は第１のユーザの友人から）。これに応答して、仲介サービス１１１は、第１のユーザを第１のユーザのリクエストと同じＭＳＩをもつ１つ又はそれ以上の他のマッチリクエストとマッチすることができる（前述のように）。マッチリクエストは、第１のユーザのマッチ基準だけをもつこと、又は第１のユーザ及び第１のユーザの友人のマッチ基準をもつことができる（例えば、ＮＡＴタイプ、接続タイプ、言語、位置）。１つの実施形態において、１人又はそれ以上の第１のユーザの友人が他のマッチユーザと直接Ｐ２Ｐ接続を確立できなかった場合、マッチユーザの第１のユーザの友人との接続は、第１のユーザのデータ処理装置を介して確立することができ（例えば、第１のユーザのモバイル装置を接続のプロキシとして使用して）、及び／又はリレーサービスはユーザを接続するために使用することができる（前述のように）。

１つの実施形態において、第１のユーザは最初に仲介サービスによって１人又はそれ以上のユーザとマッチさせることができ（前述のように）、次に、第１のユーザは１人又はそれ以上の友人を招待して、オンラインセッションに第１のユーザ及びマッチユーザを結び付けることができる。本実施形態において、ユーザの情報及びマッチユーザの情報（例えば、ＮＡＴ／接続データ、ユーザＩＤ、プッシュトークン）は、招待サービスを介して招待ユーザと交換することができる（前述のように）。最初にマッチングが起こり、その後に招待が続くか、又は招待が起こり、その後にマッチングが続くかに関わらず、本発明の基本的原理は変化しない。

共同オンラインアプリケーションに関するアプリケーションプログラミングインタフェースを備えるアプリケーションフレームワーク
図１９に示すように、本発明の１つの実施形態は、１つ又はそれ以上のアプリケーション１９１１とインタフェース接続するアプリケーションプログラミングインタフェース（ＡＰＩ）１９１０及び複数のネットワークサービス１９０１−１９０３と通信を行うサービスサイドＡＰＩ１９１３と共に、所定のソフトウェアフレームワーク１９１２を有するモバイル装置１２０との関連において実装される。図１９に示すように、ネットワークサービス１９０１−１９０３は、同じオンラインデータサービス１００によってデザイン及び管理することができる（このような機器構成は必須ではないが）。Ｐ２Ｐゲームアプリケーション及び他のタイプの共同オンラインアプリケーション等のアプリケーション１９１１は、ＡＰＩ１９１０を呼び出すことでＡＰＩ１９１０を介してネットワークサービス１９０１−１９０３にアクセスするようにデザインできる。アプリケーション１９１１のデザインは、フレームワーク１９１２及びネットワークサービス１９０１−１９０３の開発者が提供するソフトウェア開発キット（ＳＤＫ）を用いて容易にすることができる。フレームワーク１９１２及びＡＰＩ１９１０、１９１３の追加の特定の実施例は図２０に関連して以下に説明する。

図示のように、各サービスは、サービスが使用するデータを格納するデータベース１９２０へのアクセスで提供される。１つの特定の実施例は、前述の仲介サービス１１１が使用するデータベース１５１２である。他の実施例としては、リーダーボードデータを格納するリーダーボードデータベース、友人ステートレコードを格納する友人サービスデータベース、ユーザプロファイルデータを格納するプロファイルデータベース、及びオンラインゲームに関するデータを格納するゲームデータベースを挙げることができる。任意のタイプのデータベースを使用できるが（例えば、ＭｙＳＱＬ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ）、１つの特定の実施形態において、Ｂｅｒｋｌｅｙ ＤＢ等のＫｅｙ−Ｖａｌｕｅデータベース及び／又はＭＺＢａｓｉｃ ＤＢを使用できる。データベースは、ストレージエリアネットワーク（ＳＡＮ）の多数の大容量記憶装置（例えば、ハードドライブ）又は他の記憶構成機器に分散させることができる。

結果的に、前述のように特定のサービスがデータを処理する及び／又はデータを格納する場合、データは、データベース１９２０内に格納することができる。しかしながら、特定のサービスはデータベースを使用しない場合がある。例えば、前述のように、招待サービス１１２は、ステートレスサービスとして実装できるので、データをデータベース１９２０内に格納することを必要としない場合がある（しかしながら、この実施例は本発明の基本的原理に依然として従うことができる）。

ＡＰＩ１９１３は、ネットワークレイヤのＴＣＰ／ＩＰ又はＵＤＰ／ＩＰ、及びアプリケーションレイヤのＨＴＴＰＳを含む任意の適切なネットワークプロトコルスタックを使用して、ネットワークサービス１９０１−１９０３と通信して情報を交換するように設計できる。ＳＯＡＰ等のＨＴＴＰ又はＨＴＴＰＳ上の遠隔手続呼び出し（ＲＰＣ）ベースのプロトコルを使用でき、及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）プロトコルを使用できる。更に、サービスは、例示的に、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、又はＡｐａｃｈｅソフトウェアプラットフォームで実行されるＸｓｅｒｖｅ又は類似のサーバを含む、任意のコンピューティングプラットフォーム上に実装できる。１つの特定の実施形態において、プラットフォームは、Ｌｉｎｕｘ（登録商標）に実装されるＷｅｂオブジェクトを含む。前述の実施例は例示目的である。本発明の基本的原理は、アプリケーションをサービス又は任意の特定のネットワークプロトコルセットにリンクさせるための特定の機構に限定されない。

図２０は、本発明の１つの実施形態の無線装置１２０に実装できるアプリケーションプログラミングインタフェース（ＡＰＩ）２００１ａ−ｂを含むソフトウェアアーキテクチャの詳細を示す。本実施形態は多人数参加型ゲームフレームワーク２０００に関して説明するが、本発明の基本的原理はゲームの実施例に限定されない。例えば、図２０に示すソフトウェアアーキテクチャは、ゲーム以外の種々の共同アプリケーションをサポートするために使用できる（例えば、共同チャット、マルチパーティ共同オーディオ／ビデオ）。

図２０に示すアーキテクチャにおいて、ゲームフレームワーク２０００は、本明細書で説明する種々のマルチパーティ機能及びＰ２Ｐ機能をサポートするために設けられる。１つの実施形態において、ゲームフレームワーク２０００は、モバイル装置のオペレーティングシステム２００５で実行されるように設計される。例えば、モバイル装置１２０がＰｈｏｎｅ、ｉＰａｄ、又はｉＰｏｄ Ｔｏｕｃｈの場合、オペレーティングシステム２００５はｉＰｈｏｎｅ ＯＳ、つまり本出願人がデザインしたモバイルオペレーティングシステムとすることができる。

ゲームフレームワーク２０００は、パブリック・アプリケーションプログラミングインタフェース（ＡＰＩ）２００１ｂ、及びプライベート又は「セキュア」ＡＰＩ２００１ａを含むことができる。１つの実施形態において、本明細書で説明する種々のゲーム関連機能を提供する油にデザインされたゲームセンタアプリケーション２０３１は、パブリックＡＰＩ２００１ｂ及びプライベートＡＰＩ２００１ａの両者を呼び出すことができるが、他のアプリケーション２０３０（例えば、サードパーティが設計したアプリケーション）は、パブリックＡＰＩ２００１ｂだけにアクセスするように設けられる。例えば、モバイル装置１２０の設計者は、パブリックＡＰＩ２００１ｂ以外に、サードパーティ開発者の悪用を防止するために、潜在的な極秘情報（例えば、友人リクエスト、友人リスト）を含む特定のＡＰＩ機能を保持したいと考える場合がある。しかしながら、セキュアＡＰＩ２００１ａ及びパブリックＡＰＩ２００１ｂの両者は、モバイル装置の全てのアプリケーションがアクセス可能な単一のＡＰＩに統合することができる（つまり、本発明の基本的原理に従うために、ＡＰＩを別個のパブリック及びプライベート構成要素に分離する必要はない）。「ＡＰＩ２００１」の表示は、以下ではパブリックＡＰＩ２００１ｂ及び／又はプライベートＡＰＩ２００１ａのいずれかに見出すことができる作動を呼ぶ場合がある。

ゲームセンタアプリケーション２０３１の１つの実施形態は、同時継続出願の２０１０年４月１７日出願の米国出願番号６１／３２１，８６１「ゲームセンタを提供するシステム及び方法」（代理人整理番号：４８６０．Ｐ９１２７ＵＳＰ１）に説明されており、発明者はＭａｒｃｅｌ Ｖａｎ Ｏｓ及びＭｉｋｅ Ｌａｍｐｅｌｌであり、本出願人に譲渡され、参照によって本明細書に組み込まれている（以下、「ゲームセンタの特許出願」と呼ぶ）。簡単には、ゲームセンタアプリケーション２０３１は、多人数参加型ゲームを検索し、新しいゲームを購入し、ゲームに関する情報を読み出し（例えば、リーダーボード情報、アチーブメント、友人情報）、ゲームを行うために友人とコンタクトし、他のユーザとのゲームマッチをリクエストし、及び特定のユーザを招待するためのゲーム中心のグラフィカルユーザインタフェース（ＧＵＩ）を含む。ゲームセンタアプリケーション２０３１が実行する種々の他の機能は、前述のゲームセンタの特許出願に開示されている。いくつかのゲームセンタ機能は、ゲームフレームワーク２０００が提供し、パブリックＡＰＩ２００１ｂを介して他のアプリケーション２０３０がアクセスできる。

１つの実施形態において、ゲームフレームワーク２０００が公開するＡＰＩ２００１は、モバイル装置１２０に関しての多人数参加型ゲームをデザインするプロセスを単純化する。詳細には、１つの実施形態において、ＡＰＩ２００１により、開発者は、単純なＡＰＩ呼び出しを行って、ユーザを多人数参加型Ｐ２Ｐゲームセッションに接続する比較的複雑なプロセスを呼び出すことができる。例えば、招待（プレーヤーＢ ＩＤ、バケットＩＤ）等の単純なＡＰＩ呼び出しは、ＡＰＩ２００１から呼び出して前述の詳細なＩＮＶＩＴＥシーケンスを起動することができる。同様に、ＭＡＴＣＨ（プレーヤーＡ ＩＤ、バケットＩＤ）等のＡＰＩ呼び出しは、ＡＰＩ２００１から呼び出して前述の仲介シーケンスを起動することができる。ＩＮＶＩＴＥ及びＭＡＴＣＨ機能は、本明細書では「Ｐ２Ｐ接続機能」と呼ぶ場合もある。１つの実施形態において、ゲームフレームワーク２０００は、ＡＰＩ呼び出しに応答して招待及び仲介動作を管理するのに必要なプログラムコードを含む（以下に詳細に説明するように）。実際のＡＰＩ機能は前述とは多少異なるデータ形式をもつ場合があることに留意されたい（しかし、ゲームフレームワーク２０００で実行されるのと同じ動作をもたらすことができる）。本発明の基本的原理は、ＡＰＩ機能を規定するための何らかの特定の形式に限定されない）

また、種々の他のタイプのゲーム関連トランザクション及び情報は、ゲームセンタ２０３１及び他のアプリケーション２０３０の代わりに、ゲームフレームワーク２０００で管理できる。この情報のいくつかはゲームセンタの特許出願に開示されている。例示的かつ非限定的に、この情報は、各ゲームのトップスコアを達成したユーザに関する「リーダーボード」情報、及び特定のゲーム固有アチーブメントを達成したユーザを特定する「アチーブメント」情報を含むことができる。各アプリケーション開発者は、各ゲームアプリケーション２０３０に関する自身の「アチーブメント」セットを規定できる（例えば、レベル１−３を達成、レベル１を５分以内に達成、レベル毎に５０以上を仕留めた、２０フラグを倒した）。

また、ゲームフレームワーク２０００は、ユーザの友人データを管理して、友人データをゲームセンタ２０３１内及び他のゲームアプリケーション２０３０内に統合するためのプログラムコードを含むことができる。例えば、ユーザがゲームセンタ２０３１内の特定のゲームへのリンクを選択する場合、ユーザの友人の各々に関連する情報は、そのゲームに表示することができる（例えば、友人のリーダーボード上の順位、友人のアチーブメント、ユーザが彼／彼女の友人とゲームをした時の結果）。１つの実施形態において、ゲームフレームワーク２０００のＡＰＩ２００１は、友人サービスが管理する友人データにアクセスする機能を含み、このことは、同時継続出願の２０１０年４月１７日出願の米国出願番号６１／３２１，８４８「ソーシャルネットワーキングサービスのデータを効率的に管理するための装置及び方法」（代理人整理番号：４８６０．Ｐ９２４０）に説明されており、発明者はＡｍｏｌ Ｐａｔｔｅｋａｒ、Ｊｅｒｅｍｙ Ｗｅｒｎｅｒ、Ｐａｔｒｉｃｋ Ｇａｔｅｓ、及びＡｎｄｒｅｗ Ｈ． Ｖｙｒｒｏｓであり、本出願人に譲渡され、参照によって本明細書に組み込まれている（以下、「友人サービスの出願」と呼ぶ）。

図２０に示すように、１つの実施形態において、ゲームデーモン２０２０は、ゲームフレームワーク２０００をサービス２０５０の第１のセットにインタフェース接続することができ、ゲームサービスコンポーネント２０１０は、ゲームフレームワーク２０００をサービス２０５１の第２のセットにインタフェース接続することができる。例示的に、サービス２０５０の第１のセットは、招待サービス１１２、仲介サービス１１１、及び前述のリレーサービス１０５１及びに前記友人サービスアプリケーションに説明する友人サービスを含むことができる。ゲームデーモン２０２０がアクセス可能な他のサービスとしては、リーダーボードサービス（リーダーボードデータを提供する）、ゲームサービス（各ゲーム及びゲームを購入する能力に関連する統計データ及び他のデータを提供する）、ユーザ認証サービス（モバイル装置のユーザを認証するため）、及び／又はユーザプロファイルサービス（ユーザ嗜好等のユーザプロファイルデータを記憶するため）を挙げることができる。ゲームサービスコンポーネント２０１０によりアクセスするサービス２０５１の第２のセットは、前述の接続データ交換（ＣＤＸ）サービス１１０及びＮＡＴトラバースサービス２９０−２９１を含むことができる。図２０では例示的に別個のコンポーネントが示されているが、ゲームデーモン２０２０及びゲームサービスモジュール２０１０は、実際にはゲームフレームワーク２０００のコンポーネントとすることができる。１つの実施形態において、ゲームデーモン２０２０及び２０１０は、１つの実施形態において、プライベートＡＰＩである（つまり、サードパーティ開発者には公開されていない）、所定のＡＰＩを経由して各ネットワークサービス２０５０−２０５１と通信できる。

１つの実施形態において、ゲームデーモン２０２０は、ＨＴＴＰＳプロトコルを使用して仲介サービス１１１、招待サービス１１２、及び他のサービス２０５０と通信できるが、ゲームサービスモジュール２０１０は、ＵＤＰソケット等の比較的軽量なプロトコルを使用してＣＤＸサービス１１０及びＮＡＴトラバースサービス２９０−２９１と通信できる。しかしながら、前述のように、本発明の基本的原理に依然として従いながら種々の他のネットワークプロトコルを使用できる。

更に、図２０に示すように、ゲームデーモン２０２０は、特定のサービス２０５２が生成したプッシュ通知２０５２を受信できるが（例えば、招待サービス及び仲介サービス）、プッシュ通知２０５３の他のタイプをゲームセンタで直接受信することができる（例えば、新しい友人リクエスト等の友人サービス通知）。１つの実施形態において、これらのプッシュ通知２０５３は、ゲームセンタ２０３１に直接供給して、サードパーティのアプリケーション開発者がデザインしたアプリケーション２０３０ではユーザの極秘データにアクセスできないようにすることができる。

図１１に説明するゲーム招待の実施例に戻ると、モバイル装置Ａのアプリケーション２０３０は、ゲームフレームワーク２０００のＡＰＩ２００１ｂに対して招待呼び出しを行ってモバイル装置Ｂのユーザを招待し（例えば、ＩＮＶＩＴＥ（プレーヤーＢ ＩＤ、ゲーム／バケットＩＤ））、ゲームフレームワーク２０００は、招待リクエストをモバイル装置Ａのゲームデーモン２０２０に送ることができる。次に、ゲームデーモン２０２０は、招待サービス１１２と通信して招待リクエストを送出することができる。次に、招待サービス１１２は、プッシュ通知サービス１０５０を使用して（前述のように）、招待リクエストをモバイル装置Ｂのゲームデーモン２０２０にプッシュ配信することができる。次に、モバイル装置Ｂのゲームデーモン２０２０は、モバイル装置Ｂのゲームフレームワーク２０００と通信して、招待リクエストが送信されたゲームがモバイル装置Ｂにインストールされているか否かを判定する。インストールされている場合、ゲームフレームワーク２０００は、アプリケーション２０３０をトリガすること及び／又は招待リクエストの可視通知を生成することができる。アプリケーションがインストールされていない場合、ゲームフレームワーク２０００は、モバイル装置Ｂのユーザに対するゲームを購入する提案と共に招待リクエストの可視通知をトリガすることができる（例えば、ゲームセンタ２０３１ ＧＵＩによって）。もしくは、可視通知は、モバイル装置１２０で実行されるプッシュ通知デーモンで生成することができる（図示せず）。モバイル装置Ｂのユーザがゲームを購入すると、招待シーケンスは次に進むことができる。モバイル装置Ｂのユーザが招待リクエストを受諾すると、次に、モバイル装置Ｂのゲームフレームワーク２０００は、招待リクエストを自身のゲームデーモン２０２０に送り、次に、ゲームデーモン２０２０は、招待サービス１１２に応答することができる。

図１１に戻ると、互換性チェック１１０６は、モバイル装置Ａ及びＢのＮＡＴタイプに互換性があるか否かを判定する。つまり、１１０８において、モバイル装置Ａのゲームデーモン２０２０はモバイル装置Ｂの受諾情報を受信することができ（例えば、プッシュ通知により）、１つの実施形態において、受諾情報をゲームフレームワーク２０００に送ることができる。この段階で、モバイル装置Ａのゲームフレームワーク２０００は、リクエスト中のアプリケーション２０３０にモバイル装置Ｂが受諾したことを通知すること（ＡＰＩ２００１によって）又はリクエスト中のアプリケーション２０３０に装置が上手く接続されるまで通知を待つことができる。いずれの場合も、ゲームフレームワーク２０００は、接続リクエストをゲームサービスモジュール２０１０に送ることができ、１つの実施形態において、ゲームサービスモジュール２０１０はモバイル装置Ｂとの接続データ交換を開始できる。特に、ゲームサービスモジュールは、ＣＤＸサービス１１０を使用して、モバイル装置Ａの接続データをモバイル装置Ｂに送信することができる（例えば、図１１のトランザクション１１１１及び１１１２を参照）。前述のように、この通信は、セキュア「チケット」データ構造を使用してＵＤＰ接続として実施できる。

図１２に戻ると、互換性チェック１１０６がモバイル装置Ａ及びＢのＮＡＴタイプに互換性がないと判定した場合、リレーサービス１０５１を使用して各装置間の接続を行うことができる。結果的に、モバイル装置Ｂのゲームデーモン２０２０は、招待サービス（図１２に示す）からリレーレスポンス１２０３を受信することができ、モバイル装置Ａのゲームデーモン２０２０は、招待サービスからリレーレスポンス１２０５を受信することができる（プッシュ通知サービス１０５０によって）。モバイル装置Ａ及びＢの各ゲームデーモン２０２０は、１２０６及び１２０７においてリレーサービスと通信して機器構成データを読み出すことができる。１２１０において、モバイル装置Ｂのゲームデーモン２０２０は、モバイル装置Ａからリレーアップデートデータを受信し、１２１３において、モバイル装置Ａのゲームデーモン２０２０は、モバイル装置Ｂからリレーアップデートを受信する。

図１１及び１２に示す処理の最終結果は、モバイル装置Ａ及びＢの相互接続の確立である（直接Ｐ２Ｐ接続又はリレー接続）。１つの実施形態において、成功裏の接続を検出すると、ゲームフレームワーク２０００は、接続をリクエストしたアプリケーション２０３０にＡＰＩ呼び出しを用いて通知することができる（例えば、ＣＯＮＮＥＣＴＥＤ（プレーヤーＡ ＩＤ、プレーヤーＢ ＩＤ））。次に、モバイル装置Ａ及びＢは、確立した接続を用いて特定のゲーム又は他の共同アプリケーション２０３０を行うことができる。

つまり、ＡＰＩ２００１からの比較的単純な呼び出しに応答して（例えば、ＩＮＶＩＴＥ（プレーヤーＢ ＩＤ、ゲーム／バケット ＩＤ）、複雑な一連のトランザクションをゲームフレームワーク２０００で管理してモバイル装置Ａ及びＢの間のＰ２Ｐ又はリレー接続を確立することができる。１つの実施形態において、ゲームフレームワーク２０００は、モバイル装置Ａ及びＢを接続する動作シーケンスを実行し、次に、その結果をリクエスト中のアプリケーション２０３０に提供することができるので、ＡＰＩ呼び出しの詳細をアプリケーション設計者に透過的なままにしておくことができる。従って、アプリケーション設計者は、ネットワーク上のモバイル装置Ａ及びＢを接続する方法を理解する必要がなく、又は装置間の通信を確立するのに必要な種々の他の機能を実行する必要がない。

同様に、ゲームフレームワーク２０００は、図２ａ−ｂに関して説明したように、仲介サービス１１１を使用してモバイル装置Ａと他の参加者との間のマッチングを確立することができる。本実施例の場合、アプリケーション２０３０は、ＡＰＩ２００１に対して単純な呼び出しを行うことができるＭＡＴＣＨ（プレーヤーＡ ＩＤ、ゲーム／バンドルＩＤ）。これに応答して、ゲームフレームワーク２０００は、マッチング及び接続データ交換動作を管理することができる。マッチング動作及び／又はＰ２Ｐ接続が完了すると、ゲームフレームワーク２０００は、その結果をアプリケーション２０３０に戻す。

例えば、図２ｂにおいて、ゲームフレームワーク２０００は、ゲームサービスモジュール２０１０を使用して接続データ交換（ＣＤＸ）サービス１１０及びＮＡＴトラバースサービス２９０−２９１と通信することができ、更に、ゲームデーモンを使用して仲介サービス１１１と通信することができる。マッチングが行われると、モバイル装置Ａのゲームデーモン２０２０は、２２９においてチケットＡを受信し、ゲームフレームワーク２０００はこの情報を使用して、ゲームサービスモジュール２０１０を介して接続データ交換を実行する。例えば、２３２において、ＮＡＴトラバースサービス２９０を介して自身の接続データをリクエストして、２３３−２３４において、ＣＤＸサービス１１０を介してその接続データを交換することができる。２３７及び２４０において、モバイル装置Ａのゲームサービスモジュール２０１０は、それぞれモバイル装置Ｂ及びＣに関する接続データを受信する。この交換に続いて、ゲームサービスモジュール２０１０は、２４１においてＰ２Ｐ接続を確立し、ゲームフレームワーク２０００は、アプリケーション２０３０にＡＰＩ通知を用いて接続処理が完了したという通知を行う（例えば、ＭＡＴＣＨ ＣＯＭＰＬＥＴＥ（プレーヤーＢ ＩＤ、プレーヤーＣ ＩＤ））。次に、アプリケーションは確立されたＰ２Ｐ接続を用いて実行される。

特定の実施形態において、ユーザは、現在「オンライン」の他の友人とゲームをすることを選択できる。この場合、特定の友人がオンラインであるという通知をプッシュ通知２０５２又はプッシュ通知２０５３で提供できる（ゲームセンタ２０３１から直接受信）。次に、ゲームセンタ２０３１及び／又はアプリケーション２０３０はこの通知をユーザに提供すること、及びユーザに１人又はそれ以上の選択したオンラインの友人とゲームをするための選択肢を与えることができる。しかしながら、本明細書で説明する招待シーケンスは、オンライン通知が提供されるか否かに関わらず機能できることに留意されたい。１つの実施形態において、ユーザのオンライン状態は、ゲームデーモン２０２０がアクセス可能なサービスによって監視できる（例えば、前述の友人サービス又は独立した「プレゼンス」サービス）。

ゲームフレームワーク２０００の１つの実施形態は、ユーザが１人又はそれ以上の 友人を招待して未知のマッチした参加者のグループとゲームできる、組み合わせ招待／仲介動作を提供する。例えば、ゲームが４人プレーヤーを必要とし、第１のユーザが第２のユーザを招待してゲームを行う場合、招待サービス１１２は、最初は第１のユーザと第２のユーザを接続することができ、次に、仲介サービス１１１は、第１のユーザ及び第２のユーザを２人の（又はそれ以上の）他のプレーヤーとマッチすることができる。本実施形態において、ゲームフレームワーク２０００は、最初は前述の招待シーケンスを実行して第１のユーザ及び第２のユーザを接続するようになっている。１つの実施形態において、第１のユーザ及び第２のユーザを上手く接続すると、ゲームフレームワーク２０００は、仲介シーケンスを実施して、他のユーザを特定してこのユーザと接続させることができる。前述のように、１つの実施形態において、仲介サービスが適用するマッチ基準は、第１及び第２のユーザを含むことができる（例えば、第１及び第２のユーザの両者のＮＡＴタイプ、接続タイプ、言語）。もしくは、２人のユーザの一方の基準を評価して仲介判定を行うことができる。

全てのユーザが接続されると、ゲームフレームワーク２０００は、ＡＰＩ２００１を介して、接続結果を、接続をリクエストしたアプリケーション２０３０に提供することができる。再度、アプリケーション２０３０による比較的単純なＡＰＩ呼び出しに応答して、ゲームフレームワーク２０００は、複雑なトランザクションセットに入って装置の各々を接続する。各装置が上手く接続されると、ゲームフレームワーク２０００は、その結果をリクエスト中のアプリケーション２０３０に戻す。

図２０に示すように、ゲームフレームワーク２０００は、ユーザと他のゲーム参加者との間の通信を一次的に記憶する通信バッファ２００３を含むことができる。通信は、例えば、テキスト、オーディオ、及び／又はビデオ通信を含むことができる。ゲームフレームワーク２０００は、各アプリケーション２０３０の要求に基づいてバッファ２００３を確立できる。例えば、低速ネットワーク接続のオーディオ／ビデオ通信には比較的大きなバッファ２００３が必要である。１つの実施形態において、各アプリケーション２０３０は、ＡＰＩ２００１を介して、明示的リクエストを行って所定サイズの通信バッファを確立することができる（例えば、ＢＵＦＦＥＲ（サイズ）コマンドを用いて）。もしくは、ゲームフレームワーク２０００は、各アプリケーションの通信要件に基づいてバッファを自動的に生成することができる。例えば、ゲームフレームワーク２０００は、テキスト、オーディオ、及び／又はビデオをサポートする必要があるか否かに基づいて、特定のバッファサイズを選択することができる。

１つの実施形態において、通信バッファ２００３は、各ユーザ間で全てのＰ２Ｐ接続が確立される前に、通信ストリームを一時的に記憶することができる。例えば、招待サービス１１２又は仲介サービス１１１がユーザの各々を特定した後であるがＣＤＸサービス１１０が接続データ交換動作を完了する前に、各ユーザは、他のゲーム参加者が接続処理中であることを通知される。この段階で、モバイル装置１２０のユーザは、他の参加者にテキスト、オーディオ、及び／又はビデオ通信ストリームを送信することができる。ゲームフレームワーク２０００は、未接続の参加者に関する通信ストリームを通信バッファ２００３内に記憶することができる。次に、ゲームフレームワーク２０００は、接続が完了するとテキスト、オーディオ、及び／又はビデオをバッファ２００３から送信することができる。

１つの実施形態において、ゲームデーモン２０２０は、サービス２０５０の各々に存続するデータをキャッシュしてネットワークトラフィックを低減するためのキャッシュ２０２１を含む。例えば、ユーザの友人リスト、リーダーボードデータ、アチーブメントデータ、プレゼンスデータ、及びプロファイルデータは、キャッシュ管理ポリシーの規定に従ってキャッシュ２０２１に格納できる。１つの実施形態において、キャッシュ管理ポリシーは、データが格納される個々のサービスで決定される。結果的にｎの異なるサービスに関して、キャッシュ２０２１に対してｎの異なるキャッシュ管理ポリシーを適用できる。更に、キャッシュ管理ポリシーは各サービスで決定できるので、現在のネットワーク及び／又はサーバ負荷状况に基づいて動的に変更できる。例えば、サービスが高負荷の期間では（例えば、クリスマス、新製品リリース日）、サービスは、キャッシュ管理ポリシーを動的に規定してキャッシュの更新を低頻度にすることができる（例えば、１２時間毎に更新する）。対照的に、サービスの負荷が高くない期間では、サービスは、キャッシュ更新を頻繁に行うキャッシュポリシーを規定できる（例えば、半時間毎、１時間毎、２時間毎に更新する）。

１つの実施形態において、キャッシュ管理ポリシーは、キャッシュ２０２１に格納される特定のデータレコードに関する有効期限（ＴＴＬ）値を用いて規定できる。ＴＴＬ値が過ぎたデータレコードがキャッシュに格納されている場合、このデータは「陳腐化」していると見なされて、このデータに関するローカルリクエストは、このデータに関連するサービスに直接送ることができる。１つの実施形態において、リクエストは、データの最新バージョンを特定するＩＤコードを含む。ＩＤコードがサービスのＩＤコードと一致する場合、データは依然として有効であり、更新する必要はない。次に、キャッシュのデータが最新であることを示す応答をサービスから返送することができ、データレコードのＴＴＬ値をリセットすることができる。

前述のようにキャッシュ管理ポリシーを使うことに加えて、１つの実施形態において、特定のデータタイプに関するキャッシュ更新値は、プッシュ通知サービス１０５０を用いてモバイル装置にプッシュ配信することができる。例えば、ユーザの友人リストへの変更、又はユーザの友人の現在のオンライン状態への変更は、ユーザのモバイル装置１２０へ動的にプッシュ配信することができる。プッシュ通知はゲームデーモン２０２０で受信でき、ゲームデーモン２０２０は、キャッシュ２０２１を更新して、サービスがキャッシュ配信したデータの関連部分を含めることができる（つまり、サービスに関連するキャッシュ内の全てのデータの更新は必須ではない場合がある）。対照的に、いくつかのプッシュ通知は、ゲームデーモン２０２０に対してキャッシュの全てのコンテンツを上書きするように指示できる（又は、プッシュ配信を行うサービスに関連するキャッシュの少なくとも一部）。

キャッシュ２０２１を更新するためにプッシュ配信を利用するこれらのサービスは、通知をプッシュ配信してキャッシュ２０２１に格納されたデータを更新することができるので、比較的大きなＴＴＬ値を選択することができる（及び／又は、ＴＴＬ値を設定できない）。１つの実施形態において、各サービスは、プッシュ通知キャッシュ更新をトリガできるイベントセットを規定する。例えば、キャッシュ更新イベントは、友人のオンライン状態への変化、新しい友人リクエスト、友人リクエストの受諾、友人削除操作、友人が特定のゲームを行っていることの表示、友人が到達したゲームアチーブメント、特定のリーダーボードのトップ１０の更新、又はキャッシュ更新を許可するために重要になると思われる何らかの他のイベントを含むことができる。キャッシュ２０２１を更新するためにプッシュ通知するこの方法では、プッシュ配信による更新によって、モバイル装置とサービスとの間の定期的なポーリングを必要としないので、ネットワーク及びサービス負荷が低減する。

ゲームフレームワーク２０００の１つの実施形態は、ユーザの国及び／又は地理的位置に基づいてエンドユーザに表示されるデータを一意的にフォーマットする。例えば、現在の日付、時間、及び通貨の値は、異なる国及び位置のユーザに対して異なるように表示される。例示的に、米国では、日付形式は、「月、日、年」（例えば、Ａｐｒｉｌ ２５，２０１０）とすることができるが、他の国では日付形式は「日、月、年」（例えば、２５ Ａｐｒｉｌ，２０１０）とすることができる。同様に、米国及びいくつかの他の国で時間を表示する場合、ＡＭ／ＰＭ表記を使用でき、時と分の間にコロンを使用できる（例えば、３：００ＰＭ）。対照的に、他の多くの国ではＡＭ／ＰＭ表記を使用せず及び／又は時と分の間にカンマを使用する（例えば、１５，００）。他の実施例として、世界の大部分ではメートル制を採用しているが一部では採用していない（例えば、米国）。これらは単純な例示であり本発明の特定の実施形態で使用できることに留意されたい。本発明の基本的原理は、何らかの特定のデータ形式に限定されない。

１つの実施形態において、これらの異なるデータ形式は、リーダーボードデータ、アチーブメントデータ、友人データ、及び／又はゲームフレームワーク２０００が処理する何らかの他のデータを表示する場合に選択できる。ゲームフレームワーク２０００は、ユーザの国及び／又は地理的位置を種々の方法で決定できる。例えば、１つの実施形態において、この情報は、単純にユーザのプロファイルデータで提供され、及び／又はユーザの携帯電話サービスプロバイダに基づいて決定することができる。また、ユーザの位置は、例えば、Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（ＧＰＳ）追尾を使用して決定できる。

また、地理的位置及び／又は国に関係のない他のデータ形式もゲームフレームワーク２０００で管理できる。例えば、リーダーボードデータを表示する場合、することは重要である。最低スコアはユーザをリーダーボードの最上位に又最下位に位置づけるかを知ることは重要である。いくつかのゲームに関して（例えば、ゴルフ、トラック競技、競争、スキー）、低いスコアは優れた成績を示すが、他のゲームでは（例えば、サッカー、野球）、高いスコアは優れた成績を示す。つまり、１つの実施形態において、アプリケーション２０３０は、ＡＰＩ２００１で使用することになるスコアのタイプを規定する。（例えば、「昇順」又は「降順」）。次に、ゲームフレームワーク２０００は適切なラベルセットを使用してスコアを表示するために書式設定することができる。

また、ゲームフレームワーク２０００１つの実施形態は、ユーザとユーザの友人との間の関係に基づいてユーザデータをフィルタ処理する。例えば、本発明の１つの実施形態は、「詳細」表示、「友人」表示、及び「パブリック」表示を行うことができる。１つの実施形態において、詳細表示はデータを所有するユーザが利用でき（つまり、ユーザの個人情報）、友人表示はユーザの友人が利用でき、及びパブリック表示は、全ての他のユーザが利用できる。

例示的に、パブリック表示は、単に各ユーザの「別名」、別名で行われたゲーム及び関連のスコア、及びゲームが行われ日付／時間を含むことがでる。この情報は、ゲームフレームワーク２０００が使用してパブリックリーダーボードに追加するようになっており、その後、ゲームセンタ２０３１で表示できる。

友人表示は、全体表示からの全ての情報、並びにユーザの友人の間で共有される任意の追加情報を含むことができ、例えば、ユーザが所有するゲーム、ユーザが行ったゲーム、ユーザのアチーブメント及びスコア、ユーザの友人数、これらの友人の識別、ユーザのアバターを特定するＵＲＬ、及び／又はユーザのオンライン状態等を挙げることができる。１つの実施形態において、「友人」表示は、各友人が共有することになるデフォルト設定情報セットを提供するが、エンドユーザは、このデフォルト設定を調整して、個々の友人又は友人グループが共有する情報タイプを詳細に規定することができる（例えば、仕事仲間、家族の一員、大学／高校の友人）。

「詳細」表示は、「パブリック」及び「友人」表示からの全ての情報、並びにエンドユーザの代わりに種々のサービス２０５０が管理する何らかの他の情報を含むことができる。例示的に、これは、全てのユーザのプロファイルデータ、ユーザのＵｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＵＩＤ）（本明細書では「プレーヤーＩＤ」と呼ぶ場合もある）、プレーヤー名、別名、ゲーム数及びゲーム識別、ユーザの友人、全てのユーザのアチーブメント等を含むことができる。

状况次第では、アプリケーション２０３０は、各ユーザのプレーヤーＩＤ等の各ユーザに関する僅かな情報だけを必要とすることができる。例えば、１つの実施形態において、マッチがリクエストされると、ゲームフレームワーク２０００は、最初に各プレーヤーのＩＤだけを必要とする。前述の仲介サービスがマッチを行うと、ゲームフレームワーク２０００は、任意のマッチユーザが友人か否かを決定できる（例えば、友人サービスとの通信で、及び／又はユーザのローカル友人データを調べることで）。友人の場合は、ゲームフレームワーク２０００は、追加のユーザデータを読み出してこのデータを任意のマッチした友人に提供することができる。この方法で、ゲームフレームワーク２０００は、ユーザの識別及び各ユーザの間の関係性に基づいて情報をフィルタ処理する。

１つの実施形態において、ゲームフレームワーク２０００は、２人のユーザが友人関係にない場合には、最初に第１のユーザと第２のユーザとの間のパブリック表示を与える。しかしながら、１つの実施形態において、ゲームフレームワーク２０００により、第１のユーザは、友人リクエストを第２のユーザに送ることができる（例えば、第２のユーザの別名を使用して）。友人リクエストが受諾されると、ゲームフレームワーク２０００は、追加の情報を各ユーザに提供することになる（例えば、デフォルト「友人」表示）。

別のＡＰＩの実施形態
１つの実施形態おいて実施されるＡＰＩは、ソフトウェアコンポーネントで実装されるインタフェースであり（以下「ＡＰＩ実装ソフトウェアコンポーネント」と呼ぶ）、これにより異なるソフトウェアコンポーネント（以下「ＡＰＩ呼び出しソフトウェアコンポーネント」と呼ぶ）は、１つ又はそれ以上の機能、方法、手順、データ構造、及び／又はＡＰＩ実装ソフトウェアコンポーネントが提供する他のサービスにアクセスして使用することができる。例えば、ＡＰＩにより、ＡＰＩ呼び出しソフトウェアコンポーネントの開発者は（サードパーティ開発者とすることができる）、ＡＰＩ実装ソフトウェアコンポーネントが提供する特定機能を活用することができる。１つ又はそれ以上のＡＰＩ呼び出しソフトウェアコンポーネントが存在可能である。ＡＰＩは、ソフトウェアアプリケーションからのサービスに関するリクエストをサポートするためにコンピュータシステム又はプログラムライブラリが提供する、ソースコードインタフェースとすることができる。ＡＰＩは、プログラミング言語を用いて規定することができ、どのようにデータをメモリにレイアウトするかの 明示的な低レベル記述ではなく、アプリケーションが構築されると解釈的とすること又はコンパイルすることができる。

ＡＰＩは、ＡＰＩ呼び出しソフトウェアコンポーネントがＡＰＩ実装ソフトウェアコンポーネントの特定の機能にアクセスして使用する場合に使用する、言語及びパラメータを規定する。例えば、ＡＰＩ呼び出しソフトウェアコンポーネントは、１つ又はそれ以上のＡＰＩ呼び出しにより（機能又は方法呼び出しと称する場合もある）、ＡＰＩが公開するＡＰＩ実装ソフトウェアコンポーネントの特定の機能にアクセスする。ＡＰＩ実装ソフトウェアコンポーネントは、ＡＰＩ呼び出しソフトウェアコンポーネントからのＡＰＩ呼び出しに応答して、ＡＰＩを介して値を戻すことができる。ＡＰＩは、ＡＰＩ呼び出しの構文及び結果を規定するが（例えば、ＡＰＩ呼び出しを呼び出す方法及びＡＰＩ呼び出しが行う何か）、一般に、ＡＰＩは、ＡＰＩ呼び出しがＡＰＩ呼び出しで規定される機能を実現する方法を明示しない。種々の機能呼び出し又はメッセージは、１つ又はそれ以上のアプリケーションプログラミングインタフェースによって、呼び出しソフトウェア（ＡＰＩ呼び出しソフトウェアコンポーネント）とＡＰＩ実装ソフトウェアコンポーネントとの間で転送される。機能呼び出しの転送は、送出、起動、実行、呼び出し、受信、返信、機能呼び出し又はメッセージに対する応答を含む。従って、ＡＰＩ呼び出しソフトウェアコンポーネントは呼び出しを転送することができ、ＡＰＩ実装ソフトウェアコンポーネントは呼び出しを転送することができる。

例示的に、ＡＰＩ実装ソフトウェアコンポーネント２０１０及びＡＰＩ呼び出しソフトウェアコンポーネントは、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、他のソフトウェアモジュールとすることができる（ＡＰＩ実装ソフトウェアコンポーネント及びＡＰＩ呼び出しソフトウェアコンポーネントは、互いに同じ又は異なるタイプのソフトウェアモジュールにできることを理解されたい）。ＡＰＩ呼び出しソフトウェアコンポーネントは、ローカルソフトウェアコンポーネントとすること（つまり、ＡＰＩ実装ソフトウェアコンポーネントとして同じデータ処理システム上で）、又はネットワーク上でＡＰＩを介してＡＰＩ実装ソフトウェアコンポーネントと通信するリモートソフトウェアコンポーネントとすることができる（つまり、ＡＰＩ実装ソフトウェアコンポーネントとして異なるデータ処理システム上で）。ＡＰＩ実装ソフトウェアコンポーネントは、ＡＰＩ呼び出しソフトウェアコンポーネントとしても機能できること（つまり、異なるＡＰＩ実装ソフトウェアコンポーネント公開するＡＰＩに対してＡＰＩ呼び出しを行うことができる）、及びＡＰＩ呼び出しソフトウェアコンポーネントは、異なるＡＰＩ呼び出しソフトウェアコンポーネントに対して公開されたＡＰＩを実装することで、ＡＰＩ実装ソフトウェアコンポーネントとしても機能できることを理解されたい。

ＡＰＩにより、複数のプログラミング言語で記述された複数のＡＰＩ呼び出しソフトウェアコンポーネントはＡＰＩ実装ソフトウェアコンポーネントと通信することができる（つまり、ＡＰＩは、ＡＰＩ実装ソフトウェアコンポーネントとＡＰＩ呼び出しソフトウェアコンポーネントとの間のコール及びリターンを翻訳する機能を含むことができる）。しかしながら、ＡＰＩは、特定のプログラミング言語を用いて実行することができる。

図２１は、ＡＰＩ２１２０を実装するＡＰＩ実装ソフトウェアコンポーネント２１１０（例えば、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）を含むＡＰＩアーキテクチャの１つの実施形態を示す。ＡＰＩ２１２０は、１つ又はそれ以上の機能、方法、クラス、オブジェクト、プロトコル、データ構造、フォーマット、及び／又はＡＰＩ呼び出しソフトウェアコンポーネント２１３０が使用できるＡＰＩ実装ソフトウェアコンポーネントの他の機能を特定する。ＡＰＩ２１２０は、ＡＰＩ実装ソフトウェアコンポーネントの機能がＡＰＩ呼び出しソフトウェアコンポーネントからパラメータを受信する方法、及びこの機能が結果をＡＰＩ呼び出しソフトウェアコンポーネントに返信する方法を規定する、少なくとも１つの呼び出し規則を規定できる。ＡＰＩ呼び出しソフトウェアコンポーネント２１３０は（例えば、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）、ＡＰＩ２１２０を介してＡＰＩ呼び出しを行い、ＡＰＩ２１２０で規定されるＡＰＩ実装ソフトウェアコンポーネント ２１１０の機能を使用する。ＡＰＩ実装ソフトウェアコンポーネント２１１０は、ＡＰＩ呼び出しに応答して、ＡＰＩ２１２０を介してＡＰＩ呼び出しソフトウェアコンポーネント２１３０に値を戻すことができる。

ＡＰＩ実装ソフトウェアコンポーネント２１１０は、追加の機能、方法、クラス、データ構造及び／又はＡＰＩ２１２０で規定されずＡＰＩ呼び出しソフトウェアコンポーネント２１３０が利用できない他の機能を含み得ることを理解されたい。ＡＰＩ呼び出しソフトウェアコンポーネント２１３０は、ＡＰＩ実装ソフトウェアコンポーネント２１１０と同じシステム上にあることができること、又は遠く離れて配置されてネットワーク上でＡＰＩ２１２０を使用してＡＰＩ実装ソフトウェアコンポーネント２１１０にアクセスすることができることを理解されたい。図２１はＡＰＩ２１２０と対話する単一のＡＰＩ呼び出しソフトウェアコンポーネント２１３０を示すが、ＡＰＩ呼び出しソフトウェアコンポーネント２１３０とは異なる言語（又は同じ言語）で記述することができる他のＡＰＩ呼び出しソフトウェアコンポーネントは、ＡＰＩ２１２０を使用できることを理解されたい。

ＡＰＩ実装ソフトウェアコンポーネント２１１０、ＡＰＩ２１２０、及びＡＰＩ呼び出しソフトウェアコンポーネント２１３０は、コンピュータ（例えば、コンピュータ又は他のデータ処理システム）が可読の形態で情報を記憶する何らかの機構を有するコンピュータ可読媒体に記憶できる。例えば、コンピュータ可読媒体は、磁気ディスク、光ディスク、ランダムアクセスメモリ、リードオンリーメモリ、フラッシュメモリデバイス等を含む。

図２２において、例示的な実施形態（ソフトウェアスタック）のアプリケーションは、サービスＡＰＩを用いてサービス１又は２を呼び出すこと、及び複数のＯＳ ＡＰＩを用いてオペレーティングシステム（ＯＳ）を呼び出すことができる。サービス１及び２は、複数のＯＳ ＡＰＩを用いてＯＳを呼び出すことができる。

サービス２は２つのＡＰＩを備え、一方は（サービス２ ＡＰＩ １）は、アプリケーション１から呼び出しを受信してこれに値を戻し、他方は（サービス２ ＡＰＩ ２）は、アプリケーション２から呼び出しを受信してこれに値を戻す。サービス１（これは、例えばソフトウェアライブラリとすることができる）は、ＯＳ ＡＰＩ １を呼び出して戻り値を受信し、サービス２（これは、例えばソフトウェアライブラリとすることができる）は、ＯＳ ＡＰＩ １及びＯＳ ＡＰＩ ２を呼び出して戻り値を受信する。アプリケーション２は、ＯＳ ＡＰＩ ２を呼び出して戻り値を受信する。

例示的なデータ処理装置
図２３は、本発明の特定の実施形態で使用できる例示的なコンピュータシステムを示すブロック図である。図２３はコンピュータシステムの種々のコンポーネントを示すが、各コンポーネントを相互接続する何らかの特定のアーキテクチャ又は方法を示すことは意図されておらず、詳細事項は本発明とは密接な関係がないことを理解されたい。本発明ではより少ないコンポーネント又はより多くのコンポーネントを有する他のコンピュータシステムを使用できることを理解されたい。

図２３に示すように、データ処理システムの形態のコンピュータシステム２３００は、処理システム２３２０、電源２３２５、メモリ２３３０、及び不揮発性メモリ２３４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ））に接続されるバス２３５０を含む。バス２３５０は、従来から知られている種々のブリッジ、コントローラ、及び／又はアダプタを介して相互に接続できる。処理システム２３２０は、命令をメモリ２３３０及び／又は不揮発性メモリ２３４０から呼び出して、この命令を実行して前述の動作を行うことができる。バス２３５０は前述のコンポーネントを相互接続し、また、これらのコンポーネントを随意的なドック２３６０、表示コントローラ及び表示装置２３７０、入力／出力デバイス２３８０（例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）、カーソル制御部（例えば、マウス、タッチスクリーン、タッチパッド）、キーボード）、及び随意的な無線送受信機２３９０（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ、Ｉｎｆｒａｒｅｄ）に相互接続ことができる。

図２４は、本発明の特定の実施形態で使用できる例示的なデータ処理システムを示すブロック図である。例えば、データ処理システム２４００は、ハンドヘルドコンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、携帯ゲームシステム、携帯メディアプレーヤー、並びに携帯電話、メディアプレーヤー、及び／又はゲームシステムを含むことができるタブレット又はハンドヘルドコンピュータ装置とすることができる。他の例として、データ処理システム２４００は、ネットワークコンピュータ、又は他のデバイスに組み込まれた処理デバイスとすることができる。

本発明の１つの実施形態によれば、データ処理システム２４００の例示的なアーキテクチャは、前述のモバイル装置に使用できる。データ処理システム２４００は、集積回路上の１つ又はそれ以上のマイクロプロセッサ及び／又はシステムを含むことができる、処理システム２４２０を含む。処理システム２４２０は、メモリ２４１０、電源２４２５（１つ又はそれ以上のバッテリを含む）、オーディオ入力／出力２４４０、表示コントローラ及び表示装置２４６０、随意的な入力／出力２４５０、入力デバイス２４７０、及び無線送受信機２４３０に接続する。本発明の特定の実施形態において、図２４に示されていない追加のコンポーネントをデータ処理システム２４００の一部とすることができ、本発明の特定の実施形態において、図２４よりも少ないコンポーネントを使用できることを理解されたい。更に、図２４に示されていない１つ又はそれ以上のバスを、従来から知られているように、種々のコンポーネントを相互接続するために使用できることを理解されたい。

メモリ２４１０は、データ及び／又はデータ処理システム２４００で実行するプログラムを記憶することができる。オーディオ入力／出力２４４０は、例えば、音楽を再生するための及び／又はスピーカ及びマイクロフォンによって電話機能を実現するための、マイクロフォン及び／又はスピーカを含むことができる。表示コントローラ及び表示装置２４６０は、グラフィカルユーザインタフェース（ＧＵＩ）を含むことができる。無線（例えば、ＲＦ）送受信機２４３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、Ｂｌｕｅｔｏｏｔｈ（登録商標）送受信機、無線セルラ電話送受信機）は、他のデータ処理システムと通信するために使用できる。１つ又はそれ以上の入力デバイス２４７０により、ユーザはシステムへの入力を行うことができる。これらの入力デバスは、キーパッド、キーボード、タッチパネル、マルチタッチパネル等とすることができる。随意的な他の入力／出力２４５０はドックコネクタとすることができる。

本発明の実施形態は、前述の種々のステップを含むことができる。各ステップは、汎用又は特定用途向けプロセッサに特定のステップを実行させるコンピュータ実行可能命令に組み込むことができる。もしくは、これらのステップは、このステップを実行するハードワイヤロジックを含む特定のハードウェアコンポーネントによって、又はプログラムコンピュータコンポーネント及び特注ハードウェアコンポーネントの任意の組み合わせによって実行できる。

また、本発明の構成要素は、コンピュータ実行可能プログラムコードを記憶するコンピュータ可読媒体として提供できる。コンピュータ可読媒体は、限定されるものではないが、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気及び光カード、又は電子プログラムコードを記憶するのに適する他のタイプの媒体／コンピュータ可読媒体とすることができる。

前述の説明の全体を通して、例示目的で、複数の特定の詳細事項は、本発明の種々の実施形態を完全に理解するために提示される。しかしながら、当業者であれば、これらの特定の詳細事項がなくても本発明を実施できる。例えば、当業者であれば、本明細書で説明する機能モジュール及び方法はソフトウェア、ハードウェア、又はこれらの任意の組み合わせで実装できることを容易に理解できるはずである。更に、本発明の実施形態は、モバイルコンピューティング環境に関連して説明されるが（つまり、モバイル装置１２０−１２３；６０１−６０３を使用して）、本発明の基本的原理は、モバイルコンピューティングの実施例に限定されるものではない。特定の実施形態において、例えば、ディスクトップワークステーションコンピュータを含む種々の他のタイプのクライアント又はピアデータ処理装置を使用することができる。従って、本発明の範囲及び精神は、以下の請求項に関して判断する必要がある。

Claims (17)

1. モバイル装置の間のピアツーピア（Ｐ２Ｐ）通信を確立するためのコンピュータに実装された方法であって、
   複数のモバイル装置から複数のマッチリクエストをサーバで受信する段階であって、前記マッチリクエストの各々が、マッチリクエストされた特定のアプリケーションを示し且つ当該アプリケーションに関するコンフィグレーション変数を含むアプリケーションデータを含むと共に複数のモバイル装置に関するネットワーク構成を示すネットワークコンフィグレーションデータを含む、前記複数のマッチリクエストをサーバで受信する段階と、
   前記サーバが、前記モバイル装置の前記ネットワークコンフィグレーションデータの少なくとも一部に基づいて複数のモバイル装置のグループに関するマッチ適合度を決定する段階であって、マッチ適合度は前記コンフィグレーション変数に基づく当該段階と、
   前記サーバが、前記コンフィグレーション変数を含む前記アプリケーションデータ及び前記モバイル装置に関して決定した前記マッチ適合度に基づいて、２つ又はそれ以上のモバイル装置に関するマッチを引き起こす段階と、
   を含む方法。
2. 前記マッチ適合度を決定する段階は、前記マッチリクエストを送出する２つ又はそれ以上のモバイル装置の前記ネットワーク構成の間の互換性を判定する段階を含む、請求項１に記載の方法。
3. 前記ネットワーク構成の互換性を判定する段階は、前記２つ又はそれ以上のモバイル装置が使用するネットワークアドレス交換（ＮＡＴ）デバイスタイプを判定する段階を含み、本方法は、直接Ｐ２Ｐ通信チャンネルを確立することができるＮＡＴデバイスタイプを有する、各モバイル装置の間のマッチを引き起こすように試行する段階を更に含む、請求項２に記載の方法。
4. 前記マッチ適合度は前記モバイル装置の各々の接続タイプに基づいており、本方法は、接続タイプが同じモバイル装置の間でマッチを引き起こすように試行する段階を更に含む、請求項１に記載の方法。
5. 前記接続タイプは、ＷｉＦｉ接続、第３世代（３Ｇ）セルラ接続、及びＥｄｇｅセルラ接続を含む、請求項４に記載の方法。
6. 前記マッチ適合度はモバイル装置が設定される１以上の言語に基づいており、本方法は、１以上の共通した言語が同じモバイル装置の間でマッチを引き起こすように試行する段階を更に含む、請求項１に記載の方法。
7. 前記コンフィグレーション変数は、少なくとも１つのアプリケーション又は該アプリケーションのサブアプリケーションに関する経験レベルを含む、請求項１に記載の方法。
8. 前記サーバが、前記マッチリクエストの各々の経時を判定する段階と、
   前記サーバが、前記マッチリクエストの経時に基づいて２つ又はそれ以上のモバイル装置の間の可能性があるマッチに関するマッチ適合度を調整する段階と、
   を含む、請求項１に記載の方法。
9. 前記調整する段階は、特定の閾値以上の経時を有する可能性のあるマッチに関するマッチ適合度を増加させる段階を含む、請求項８に記載の方法。
10. 前記調整する段階は、経時が１つ又はそれ以上の追加の閾値以上に増加するとマッチ適合度を継続的に増加させる、請求項９に記載の方法。
11. 前記マッチを引き起こす段階は、前記サーバが、
    前記アプリケーションデータに基づいてマッチリクエストをマッチグループにグループ化する段階と、
    各マッチグループ内のマッチリクエストに関してマッチ適合度を決定する段階と、
    決定したマッチ適合度に基づいて各マッチグループに対して前記モバイル装置のマッチを引き起こす段階と、
    を更に含む、請求項１に記載の方法。
12. 前記マッチを引き起こす段階は、
    前記アプリケーションデータに基づいてマッチリクエストを１以上のマッチセットにグループ化する段階と、
    各マッチセット内のマッチリクエストのペアに関する前記マッチ適合度を決定する段階と、
    複数のマッチセットの各々を特定の閾値以上のマッチ適合度を有するマッチリクエストのペアでシードする段階と、
    マッチリクエストをマッチセットの各々に追加する段階と、
    前記マッチ適合度の総数が特定の閾値以下の場合、各マッチセット内の追加のマッチリクエストを格付けする段階と、
    を更に含む、請求項１に記載の方法。
13. マッチサイズ要件を満足するまで、継続的にマッチセットを追加する段階を更に含む、請求項１２に記載の方法。
14. 前記マッチリクエストは、前記モバイル装置の各々に関連するNATトラバース/接続データを含み、本方法は、マッチしたモバイル装置セットにマッチが行われたという通知を送信する段階を更に含み、各モバイル装置に送信される前記通知は、前記マッチに含まれる１つ又はそれ以上の他のモバイル装置に接続するために必要なNATトラバース/接続データを含む、請求項１に記載の方法。
15. NATトラバース/接続データは、前記モバイル装置の各々に関するパブリックIPアドレス及びポートを含む、請求項１４に記載の方法。
16. コンピュータ装置で実行されると該コンピュータ装置に請求項１から１５のいずれかに記載の方法を実行させるプログラムコードを記憶したコンピュータ読み取り可能な記憶媒体。
17. プログラムコードを格納するメモリ及びプログラムコードを処理して請求項１から１５のいずれかに記載の方法を実行するプロセッサを備えるコンピュータ装置。

Images