特許 5904682 セキュアなインスタントメッセージングのためのシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5904682

(24)【登録日】2016年3月25日

(45)【発行日】2016年4月20日

(54)【発明の名称】セキュアなインスタントメッセージングのためのシステム及び方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20160407BHJP

   H04M 11/00 20060101ALI20160407BHJP

【ＦＩ】

   G06F13/00 650B

   H04M11/00 302

【請求項の数】24

【全頁数】75

(21)【出願番号】特願2014-513720(P2014-513720)

(86)(22)【出願日】2012年5月31日

(65)【公表番号】特表2014-522014(P2014-522014A)

(43)【公表日】2014年8月28日

(86)【国際出願番号】US2012040314

(87)【国際公開番号】WO2012166990

(87)【国際公開日】20121206

【審査請求日】2014年1月30日

(31)【優先権主張番号】13/224,599

(32)【優先日】2011年9月2日

(33)【優先権主張国】US

(31)【優先権主張番号】61/492,903

(32)【優先日】2011年6月3日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503260918

【氏名又は名称】アップル インコーポレイテッド

(74)【代理人】

【識別番号】100092093

【弁理士】

【氏名又は名称】辻居 幸一

(74)【代理人】

【識別番号】100082005

【弁理士】

【氏名又は名称】熊倉 禎男

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100122563

【弁理士】

【氏名又は名称】越柴 絵里

(72)【発明者】

【氏名】メディーナ アレクサンダー エイ

(72)【発明者】

【氏名】ヴァイロス アンドリュー エイチ

(72)【発明者】

【氏名】ブロー ダリル エヌ

(72)【発明者】

【氏名】デイヴィー ジェフリー ティー

(72)【発明者】

【氏名】サンタマリア ジャスティン イー

(72)【発明者】

【氏名】ウッド ジャスティン エヌ

【審査官】 小林 義晴

(56)【参考文献】

【文献】 米国特許出願公開第２００７／０１６２５５４（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００７／０１３０４６４（ＵＳ，Ａ１）

【文献】 欧州特許出願公開第０２３１７７０９（ＥＰ，Ａ１）

【文献】 米国特許出願公開第２００３／０１２６２１３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０４Ｍ １１／００

(57)【特許請求の範囲】

【請求項1】

セキュアなインスタントメッセージングを実施する方法であって、
第２ユーザとのインスタントメッセージングセッションを確立するために第１ユーザの移動装置から要求をアイデンティティサービスが受け取る処理であって、その要求は、第２ユーザを識別する識別コードを含むものである当該処理と、
第２ユーザが１つ以上の移動装置をネットワークサービスに登録しているかどうかを前記アイデンティティサービスによって決定する処理と、
第２ユーザが１つ以上の移動装置を登録している場合には、その１つ以上の移動装置を識別するアドレス情報及び第２ユーザに関連したパブリックキーを前記アイデンティティサービスが第１ユーザの移動装置に与える処理と、
前記アイデンティティサービスが、第１及び第２のユーザの識別コードと、前記第１及び第２のユーザの移動装置に関するネットワークアドレス情報とにより生成された署名を含むセッションキーをプッシュ通知サービスに提供する処理と、
第２ユーザの前記パブリックキー及び第１ユーザのプライベートキーを使用して、前記第１ユーザの移動装置により生成した暗号インスタントメッセージを受け取る処理と、
前記プッシュ通知サービスが、前記セッションキー及び前記暗号インスタントメッセージをセキュアなインスタントメッセージングサービスに送信する処理と、
前記セキュアなインスタントメッセージングサービスが、前記第１及び第２のユーザの識別コードと、前記第１及び第２のユーザのネットワークアドレス情報と、前記セッションキーとを用いて前記暗号インスタントメッセージを検証する処理と、
前記プッシュ通知サービスが、前記セキュアなインスタントメッセージングサービスから、検証された前記暗号インスタントメッセージを受け取る処理と、
前記プッシュ通知サービスが、検証された前記暗号インスタントメッセージを前記第２ユーザの１つ以上の移動装置へ送信する処理であって、第２ユーザの移動装置の１つ以上の移動装置はその後に前記第２ユーザのプライベートキーを使用して前記暗号インスタントメッセージを解読する当該処理と、が実行される方法。

【請求項2】

前記識別コードは、第２ユーザのｅ−メールアドレスを含む、請求項１に記載の方法。

【請求項3】

前記アドレス情報は、ネットワークサービスにおいて第２ユーザの１つ以上の移動装置を独特に識別するトークンを含む、請求項１に記載の方法。

【請求項4】

前記決定する処理は、更に、第２ユーザがネットワークサービスに登録されているかどうか決定するために登録データベースに問合せすることを含み、その登録データベースは、第２ユーザを１つ以上の識別コードに関連付ける、請求項１に記載の方法。

【請求項5】

インスタントメッセージを暗号化する前記処理は、更に、第２ユーザのパブリックキーを使用してテキスト及び／又はアタッチメントを含むインスタントメッセージのコンテンツを暗号化し、そして第１ユーザのプライベートキーを使用してそのコンテンツに署名することを含む、請求項１に記載の方法。

【請求項6】

検証された前記暗号インスタントメッセージを解読することは、前記第２ユーザのプライベートキーを使用して前記コンテンツを解読し、そして前記第１ユーザのパブリックキーを使用して前記コンテンツの署名を検証することを含む、請求項５に記載の方法。

【請求項7】

前記第２ユーザの１つ以上の移動装置は、第１ユーザのパブリックキーを前記アイデンティティサービスから検索する、請求項６に記載の方法。

【請求項8】

前記検証する処理は、前記セキュアなインスタントメッセージングサービスにおいて前記セッションキーを再生成することを含む、請求項１に記載の方法。

【請求項9】

セキュアなインスタントメッセージングを実施するシステムにおいて、プログラムコードを記憶するメモリと、そのプログラムコードを処理して、
第２ユーザとのインスタントメッセージングセッションを確立するために第１ユーザの移動装置から要求をアイデンティティサービスが受け取り、その要求は、第２ユーザを識別する識別コードを含むものであり、
第２ユーザが１つ以上の移動装置をネットワークサービスに登録しているかどうかを前記アイデンティティサービスによって決定し、
第２ユーザが１つ以上の移動装置を登録している場合には、その１つ以上の移動装置を識別するアドレス情報及び第２ユーザに関連したパブリックキーを前記アイデンティティサービスが第１ユーザの移動装置に与え、
前記アイデンティティサービスが、第１及び第２のユーザの識別コードと、前記第１及び第２のユーザの移動装置に関するネットワークアドレス情報とにより生成された署名を含むセッションキーをプッシュ通知サービスに提供し、
第２ユーザの前記パブリックキー及び第１ユーザのプライベートキーを使用して、前記第１ユーザの移動装置により生成した暗号インスタントメッセージを受け取り、
前記プッシュ通知サービスが、前記セッションキー及び前記暗号インスタントメッセージをセキュアなインスタントメッセージングサービスに送信し、
前記セキュアなインスタントメッセージングサービスが、前記第１及び第２のユーザの識別コードと、前記第１及び第２のユーザのネットワークアドレス情報と、前記セッションキーとを用いて前記暗号インスタントメッセージを検証し、
前記プッシュ通知サービスが、前記セキュアなインスタントメッセージングサービスから、検証された前記暗号インスタントメッセージを受け取り、
前記プッシュ通知サービスが、検証された前記暗号インスタントメッセージを前記第２ユーザの１つ以上の移動装置へ送信し、第２ユーザの移動装置の１つ以上の移動装置はその後に前記第２ユーザのプライベートキーを使用して前記暗号インスタントメッセージを解読する、
という動作を遂行するための少なくとも１つのプロセッサと、を備えたシステム。

【請求項10】

前記識別コードは、第２ユーザのｅ−メールアドレスを含む、請求項９に記載のシステム。

【請求項11】

前記アドレス情報は、ネットワークサービスにおいて第２ユーザの１つ以上の移動装置を独特に識別するトークンを含む、請求項９に記載のシステム。

【請求項12】

前記決定は、更に、第２ユーザがネットワークサービスに登録されているかどうか決定するために登録データベースに問合せすることを含み、その登録データベースは、第２ユーザを１つ以上の識別コードに関連付ける、請求項９に記載のシステム。

【請求項13】

前記インスタントメッセージの暗号化は、更に、第２ユーザのパブリックキーを使用してテキスト及び／又はアタッチメントを含むインスタントメッセージのコンテンツを暗号化し、そして第１ユーザのプライベートキーを使用してそのコンテンツに署名することを含む、請求項９に記載のシステム。

【請求項14】

検証された前記暗号インスタントメッセージを解読することは、前記第２ユーザのプライベートキーを使用して前記コンテンツを解読し、そして前記第１ユーザのパブリックキーを使用して前記コンテンツの署名を検証することを含む、請求項１３に記載のシステム。

【請求項15】

前記第２ユーザの１つ以上の移動装置は、第１ユーザのパブリックキーを前記アイデンティティサービスから検索する、請求項１４に記載のシステム。

【請求項16】

前記検証は、前記セキュアなインスタントメッセージングサービスにおいて前記セッションキーを再生成することを含む、請求項９に記載のシステム。

【請求項17】

マシンにより実行されたときに、そのマシンが、
第２ユーザとのインスタントメッセージングセッションを確立するために第１ユーザの移動装置から要求をアイデンティティサービスが受け取り、その要求は、第２ユーザを識別する識別コードを含むものであり、
第２ユーザが１つ以上の移動装置をネットワークサービスに登録しているかどうかを前記アイデンティティサービスによって決定し、
第２ユーザが１つ以上の移動装置を登録している場合には、その１つ以上の移動装置を識別するアドレス情報及び第２ユーザに関連したパブリックキーを前記アイデンティティサービスが第１ユーザの移動装置に与え、
前記アイデンティティサービスが、第１及び第２のユーザの識別コードと、前記第１及び第２のユーザの移動装置に関するネットワークアドレス情報とにより生成された署名を含むセッションキーをプッシュ通知サービスに提供し、
第２ユーザの前記パブリックキー及び第１ユーザのプライベートキーを使用して、前記第１ユーザの移動装置により生成した暗号インスタントメッセージを受け取り、
前記プッシュ通知サービスが、前記セッションキー及び前記暗号インスタントメッセージをセキュアなインスタントメッセージングサービスに送信し、
前記セキュアなインスタントメッセージングサービスが、前記第１及び第２のユーザの識別コードと、前記第１及び第２のユーザのネットワークアドレス情報と、前記セッションキーとを用いて前記暗号インスタントメッセージを検証し、
前記プッシュ通知サービスが、前記セキュアなインスタントメッセージングサービスから、検証された前記暗号インスタントメッセージを受け取り、
前記プッシュ通知サービスが、検証された前記暗号インスタントメッセージを前記第２ユーザの１つ以上の移動装置へ送信し、第２ユーザの移動装置の１つ以上の移動装置はその後に前記第２ユーザのプライベートキーを使用して前記暗号インスタントメッセージを解読する、
という動作を遂行するようにさせるプログラムコードを記憶しているマシン読み取り可能な記録媒体。

【請求項18】

前記識別コードは、第２ユーザのｅ−メールアドレスを含む、請求項１７に記載のマシン読み取り可能な記録媒体。

【請求項19】

前記アドレス情報は、ネットワークサービスにおいて第２ユーザの１つ以上の移動装置を独特に識別するトークンを含む、請求項１７に記載のマシン読み取り可能な記録媒体。

【請求項20】

前記決定は、更に、第２ユーザがネットワークサービスに登録されているかどうか決定するために登録データベースに問合せすることを含み、その登録データベースは、第２ユーザを１つ以上の識別コードに関連付ける、請求項１７に記載のマシン読み取り可能な記録媒体。

【請求項21】

前記インスタントメッセージの暗号化は、更に、第２ユーザのパブリックキーを使用してテキスト及び／又はアタッチメントを含むインスタントメッセージのコンテンツを暗号化し、そして第１ユーザのプライベートキーを使用してそのコンテンツに署名することを含む、請求項１７に記載のマシン読み取り可能な記録媒体。

【請求項22】

検証された前記暗号インスタントメッセージを解読することは、前記第２ユーザのプライベートキーを使用して前記コンテンツを解読し、そして前記第１ユーザのパブリックキーを使用して前記コンテンツの署名を検証することを含む、請求項２１に記載のマシン読み取り可能な記録媒体。

【請求項23】

前記第２ユーザの１つ以上の移動装置は、第１ユーザのパブリックキーを前記アイデンティティサービスから検索する、請求項２２に記載のマシン読み取り可能な記録媒体。

【請求項24】

前記検証は、前記セキュアなインスタントメッセージングサービスにおいて前記セッションキーを再生成することを含む、請求項１７に記載のマシン読み取り可能な記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、全般的に、コンピュータネットワーキングの分野に関する。より詳細には、本発明は、セキュアなインスタントメッセージングのための改善された装置及び方法に関する。

【0002】

優先権の主張：本願は、２０１１年６月３日に出願された米国仮特許出願第６１／４９２，９０３号の、３５Ｕ.Ｓ.Ｃ.§１１９（ｅ）のもとでの出願日の利益を主張するものである。

【背景技術】

【0003】

ピア・ツー・ピア（“Ｐ２Ｐ”）コンピューティングとは、自分のリソースの一部分を他のネットワーク参加者に直接的に利用できるようにするコンピューティングノードより成る分散型ネットワークアーキテクチャーを指す。サーバーがリソースを供給し、クライアントがリソースを消費する慣習的なクライアント−サーバーモデルとは対照的に、Ｐ２Ｐネットワークにおけるピアは、互いに直接的な通信チャンネルを確立し、クライアント及びサーバーの両方として働く。

【0004】

インスタントメッセージング及びビデオチャットのような多数の現在のＰ２Ｐアプリケーションは、ピア間で送信される基礎的なコンテンツを保護するのに充分なセキュリティ手段を備えていない。従って、ピアを識別し、そしてネットワークにわたってセキュアなＰ２Ｐトランザクションを行うための改善された技術が要望される。

【0005】

本発明は、添付図面を参照した以下の詳細な説明から良く理解されるであろう。

【図面の簡単な説明】

【0006】

【図1】移動装置及びサービスのグループがネットワークを経て通信するネットワークアーキテクチャーを示す。

【図2a】一実施形態の接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス及び／又はインビテーションサービスの間のトランザクションを示す。

【図2b】一実施形態の接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス及び／又はインビテーションサービスの間のトランザクションを示す。

【図2c】一実施形態の接続データ交換（ＣＤＸ）サービス、マッチメーカーサービス及び／又はインビテーションサービスの間のトランザクションを示す。

【図3】チケットデータ構造の一実施形態を示す。

【図4】ＣＤＸサービスにより実施される方法の一実施形態を示す。

【図5】移動装置により実施される方法の一実施形態を示す。

【図6】一次及び二次通信チャンネルを通して接続された移動装置のグループを示す。

【図7】一次及び二次通信チャンネル間を選択するための移動装置の一実施形態を示す。

【図8a】一次及び二次通信チャンネルを経て接続された移動装置のグループ、及びそれにより得られるネットワークトポロジーを示す。

【図8b】一次及び二次通信チャンネルを経て接続された移動装置のグループ、及びそれにより得られるネットワークトポロジーを示す。

【図9】一次及び二次通信チャンネル間を選択するためのコンピュータ実施方法の一実施形態を示す。

【図10】移動装置と、ディレクトリサービス及びプッシュ通知サービスを含むサービスとのグループがネットワークを経て通信するネットワークアーキテクチャーを示す。

【図11】一実施形態のインビテーションサービスと、プッシュ通知サービスと、接続データ交換（ＣＤＸ）サービスとの間のトランザクションを示す。

【図12】一実施形態のインビテーションサービスと、プッシュ通知サービスと、リレーサービスとの間のトランザクションを示す。

【図13】２つ以上の移動装置間にリレー接続を確立するためのリレーサービスの一実施形態を示す。

【図14】ＮＡＴ互換性を決定するためのＮＡＴ互換性チャートの一実施形態を示す。

【図15】オンラインアプリケーションに対して移動装置を対戦させるためのマッチメーカーサービスの一実施形態を示す。

【図16】ユーザ／装置を対戦させる方法の一実施形態を示す。

【図17a】ユーザ／装置を対戦させるために遂行される規範的な一連のテーブル更新を示す。

【図17b】ユーザ／装置を対戦させるために遂行される規範的な一連のテーブル更新を示す。

【図17c】ユーザ／装置を対戦させるために遂行される規範的な一連のテーブル更新を示す。

【図17d】ユーザ／装置を対戦させるために遂行される規範的な一連のテーブル更新を示す。

【図18】異なる対戦適合変数を使用してユーザ／装置を対戦させる方法を示す。

【図19】アプリケーションのためのアプリケーションプログラミングインターフェイス（ＡＰＩ）と、１組のサービスと通信するためのサービスＡＰＩとを露出させるフレームワークを示す。

【図20】アプリケーションのためのＡＰＩ、ゲームデーモン、及びサービスと通信するためのゲームサービスモジュールを伴うゲームフレームワークの一実施形態を示す。

【図21】ＡＰＩ実施ソフトウェアコンポーネント及びＡＰＩコーリングソフトウェアコンポーネントの一実施形態を示す。

【図22】オペレーティングシステムと、サービスと、アプリケーションとの間でＡＰＩコールがなされる１つの実施形態を示す。

【図23】規範的なコンピュータシステムアーキテクチャーの一実施形態を示す。

【図24】規範的なコンピュータシステムアーキテクチャーの別の実施形態を示す。

【図25】複数の異なるサービスプロバイダーを経て接続された複数のユーザを示す。

【図26】ユーザの位置を識別するためのブルームフィルタを使用する本発明の実施形態を示す。

【図27】ブルームフィルタを使用する方法の一実施形態を示す。

【図28】ブルームフィルタを使用する方法の別の実施形態を示す。

【図29】本発明の一実施形態によりポイント・ツー・ポイント（Ｐ２Ｐ）接続を確立する２人のユーザを示す。

【図30】特定のサービスプロバイダーにより使用されるリレーサービスを経てＰ２Ｐ接続を確立する２人のユーザを示す。

【図31】リレーサービスを経てＰ２Ｐ接続を確立する本発明の別の実施形態を示す。

【図32】本発明の一実施形態に使用されるＲＦＣ３９８４ヘッダを伴うＲＴＰパケットを示す。

【図33】プッシュ通知サービス及びセキュアなインスタントメッセージングサービスを示す。

【図34】セキュアなインスタントメッセージングセッションを確立するための方法の一実施形態を示す。

【図35】セキュアなインスタントメッセージングセッションを確立するための方法の別の実施形態を示す。

【図36】アイデンティティサービス及びアプリケーション認証サービスを含むシステムアーキテクチャーを示す。

【図37】ユーザをセキュアに認証する方法の一実施形態を示す。

【図38a】キャッシング及び指紋を使用して認証効率を改善する本発明の一実施形態を示す。

【図38b】キャッシング及び指紋を使用して認証効率を改善する本発明の一実施形態を示す。

【発明を実施するための形態】

【0007】

概略
セキュアなインスタントメッセージングのためのシステム及び方法について説明する。例えば、１つの実施形態において、第１ユーザは、第２ユーザのＩＤコードでインスタントメッセージングセッションをするために第２ユーザを識別する。それに応答して、第１ユーザには、第２ユーザのためのネットワーク情報と、第２ユーザに関連したパブリックキーとが与えられる。次いで、第１ユーザは、第２ユーザのパブリックキー及びプライベートキーを使用してインスタントメッセージを暗号化する。１つの実施形態において、第１ユーザは、第２ユーザのパブリックキーを使用してインスタントメッセージのコンテンツ（例えば、テキスト及び／又はアタッチメント）を暗号化し、そして第１ユーザのプライベートキーを使用してコンテンツに署名する。暗号化されたメッセージは、第１ユーザから第２ユーザへ送信される。次いで、第２ユーザは、第２ユーザのプライベートキーを使用してインスタントメッセージを解読し、第１ユーザのパブリックキーで署名を検証する。

【0008】

好ましい実施形態の詳細な説明
ネットワークに一次及び／又はバックアップピア・ツー・ピア（“Ｐ２Ｐ”）通信チャンネルを確立し、維持しそして使用するための装置、方法及びマシン読み取り可能な媒体の実施形態を以下に述べる。Ｐ２Ｐセッションに対してユーザを招待しユーザを各々対戦させるためのインビテーションサービス及びマッチメーカーサービスについても説明する。加えて、ユーザがある特定の条件のもとでリレー接続を確立できるようにするためのリレーサービスについても説明する。最終的に、アプリケーション開発者が、ここに述べる種々の協力的オンライン特徴の利点を取り入れるアプリケーションを設計できるようにするためのアプリケーションフレームワーク及び関連アプリケーションプログラミングインターフェイス（ＡＰＩ）についても説明する。

【0009】

この説明全体を通して、説明の目的上、本発明を完全に理解するため多数の特定の細部について述べる。しかしながら、当業者であれば、幾つかのこれら特定の細部がなくても本発明を実施できることが明らかであろう。他の点については、本発明の基礎的な原理を不明瞭にしないため、良く知られた構造及び装置は、図示しないか、又はブロック図形態で示す。

【0010】

接続データを効率的に且つセキュアに交換する装置及び方法
図１に示すように、本発明の一実施形態において具現化される一般的なネットワークトポロジーは、ネットワーク１２０を経て互いに且つ１つ以上のサービス１１０−１１２と通信する「クライアント」又は「ピア」移動コンピューティング装置Ａ−Ｄ、各々、１２０−１２３のグループを備えている。図１に単一のネットワーククラウドとして示されているが、「ネットワーク」１２０は、幾つか挙げると、インターネットのようなパブリックネットワークと、ローカルＷｉ−Ｆｉネットワーク（例えば、８０２．１１ｎホームワイヤレスネットワーク又はワイヤレスホットスポット）、ローカルエリアイーサネットネットワーク、セルラーデータネットワーク（例えば、３Ｇ、Ｅｄｇｅ、等）、及びＷｉＭＡＸネットワークのようなプライベートネットワークを含む種々の異なるコンポーネントを包含する。例えば、移動装置Ａ １２０は、ネットワークリンク１２５で表されたホームＷｉ−Ｆｉネットワークに接続され、移動装置Ｂ １２１は、ネットワークリンク１２６で表された３Ｇネットワーク（例えば、ユニバーサル移動テレコミュニケーションズシステム（ＵＭＴＳ）、高速アップリンクパケットアクセス（ＨＳＵＰＡ）、等）に接続され、移動装置Ｃ １２２は、ネットワークリンク１２７により表されたＷｉＭＡＸネットワークに接続され、そして移動装置１２３は、ネットワークリンク１２８により表されたパブリックＷｉ−Ｆｉネットワークに接続される。移動装置１２０−１２３が接続されるローカルネットワークリンク１２５−１２８の各々は、ゲートウェイ及び／又はＮＡＴ装置（図１には示さず）を通してインターネットのようなパブリックネットワークに結合され、従って、パブリックネットワークを経て種々の移動装置１２０−１２３間で通信を行うことができる。しかしながら、２つの移動装置が同じ位置又はプライベートネットワーク（例えば、同じＷｉ−Ｆｉネットワーク）にある場合には、２つの装置は、パブリックネットワークをバイパスして、その位置／プライベートネットワークを経て直接通信することができる。もちろん、本発明の基礎的な原理は、ネットワーク形式又はネットワークトポロジーの特定セットに限定されないことに注意されたい。

【0011】

図１に示す移動装置１２０−１２３の各々は、接続データ交換（ＣＤＸ）サービス１１０、マッチメーカーサービス１１１及びインビテーションサービス１１２と通信することができる。１つの実施形態において、サービス１１０−１１２は、サーバーのような１つ以上の物理的コンピューティング装置にわたって実行されるソフトウェアとして具現化される。図１に示すように、１つの実施形態では、サービス１１０−１１２は、同じエンティティ（例えば、同じデータサービスプロバイダー）により管理され且つ各移動装置１２０−１２３によりネットワーク１２０を経てアクセスできるより大きなデータサービス１００の環境内で具現化される。データサービス１００は、種々の形式のサーバー及びデータベースを接続するローカルエリアネットワーク（例えば、イーサネットベースのＬＡＮ）を含む。又、データサービス１００は、データを記憶するための１つ以上の記憶エリアネットワーク（ＳＡＮ）も含む。１つの実施形態において、データベースは、移動装置１２０−１２３及びそれら装置のユーザの各々に関連したデータ（例えば、ユーザアカウントデータ、装置アカウントデータ、ユーザアプリケーションデータ、等）を記憶しそして管理する。

【0012】

１つの実施形態において、マッチメーカーサービス１１１は、特定の１組の条件に基づいて協力的Ｐ２Ｐセッションに対して２つ以上の移動装置を対戦させることができる。例えば、２つ以上の移動装置のユーザは、特定のマルチプレーヤゲームをプレイすることに関心がある。そのようなケースでは、マッチメーカーサービス１１１は、各ユーザの専門レベル、各ユーザの年齢、対戦要求のタイミング、対戦が要求される特定のゲーム、及び種々のゲーム特有変数のような変数に基づいて、ゲームに参加する移動装置のグループを識別する。例えば、これに限定されないが、マッチメーカーサービス１１１は、特定ゲームのプレイに際して同様の経験レベルのユーザを対戦させるよう試みる。更に、大人は、他の大人と対戦され、そして子供は、他の子供と対戦される。更に、マッチメーカーサービス１１１は、ユーザの要求を、それら要求を受け取った順序に基づいてプライオリティ決めする。本発明の基礎的な原理は、特定の１組の対戦基準又は特定形式のＰ２Ｐアプリケーションに限定されない。

【0013】

以下に詳細に述べるように、対戦要求に応答して、マッチメーカーサービス１１１は、全ての対戦参加者が効率的で且つセキュアな仕方でＰ２Ｐセッションを確立するに必要な接続データを受信するように保証するためにＣＤＸサービス１１０と整合することができる。

【0014】

１つの実施形態では、インビテーションサービス１１２は、協力的Ｐ２Ｐセッションに参加するための移動装置も識別する。しかしながら、インビテーションサービス１１２のケースでは、参加者の少なくとも１人が、別の参加者により特別に識別される。例えば、移動装置Ａ １２０のユーザは、移動装置Ｂ １２１のユーザとの協力的セッションを特別に要求する（例えば、移動装置ＢをユーザＩＤ又は電話番号で識別する）。マッチメーカーサービス１１１の場合と同様に、インビテーション要求に応答して、インビテーションサービス１１２は、１組の参加者を識別し、そして全ての参加者が効率的で且つセキュアな仕方でＰ２Ｐセッションを確立するに必要な接続データを受信するように保証するためにＣＤＸサービス１１０と整合することができる。

【0015】

上述したように、１つの実施形態では、ＣＤＸサービス１１０は、２つ以上の移動装置間にＰ２Ｐセッションを確立するのに必要な接続データのための中央交換ポイントとして動作する。特に、ＣＤＸサービスの一実施形態は、移動装置の要求に応答してＮＡＴ横断データ（時々「ホールパンチ」データとも称される）を発生し、外部サービス及びクライアントが各移動装置のＮＡＴを通して通信できるようにする（即ち、ＮＡＴを通して「ホールをパンチ」し、装置に届くようにする）。例えば、１つの実施形態では、ＣＤＸサービスは、移動装置と通信するのに必要な外部ＩＰアドレス及びポートを検出し、そしてこの情報を移動装置に与える。又、１つの実施形態では、ＣＤＸサービスは、マッチメーカーサービス１１１及びインビテーションサービス１１２により発生された移動装置のリストを受信し処理して、接続データをそのリストに含まれた移動装置の各々に効率的に且つセキュアに配布する（以下に詳細に述べるように）。

【0016】

１つの実施形態では、移動装置とＣＤＸサービス１１０との間の通信は、ユーザデータグラムプロトコル（ＵＤＰ）ソケットのような比較的軽い重みのネットワークプロトコルを使用して確立される。当業者に知られたように、ＵＤＰソケット接続は、パケット信頼性、順序又はデータ完全性を保証するためのハンドシェークダイアログを要求せず、それ故、ＴＣＰソケット接続と同程度の処理オーバーヘッドを消費することはない。従って、膨大な数のクライアントからの小さな問合せに応答するサーバーにとってＵＤＰの軽い重みのステートレス特性が有用である。更に、ＴＣＰとは異なり、ＵＤＰは、（パケットがローカルネットワーク上の全ての装置へ送られる）パケットブロードキャスティング、及び（パケットがローカルネットワーク上の装置のサブセットへ送られる）マルチキャスティングと適合する。以下に述べるように、ＵＤＰが使用されても、セッションキーを使用してＮＡＴ横断データを暗号化することによりＣＤＸサービス１１０にセキュリティを維持することができる。

【0017】

ＣＤＸサービス１１０により使用される低オーバーヘッドで軽い重みのネットワークプロトコルとは対照的に、１つの実施形態では、移動装置１２０−１２３と、マッチメーカーサービス１１１及び／又はインビテーションサービス１１２との間の通信は、セキュアなソケットレイヤ（ＳＳＬ）又はトランスポートレイヤセキュリティ（ＴＬＳ）接続に依存するハイパーテキストトランスファープロトコルセキュア（ＨＴＴＰＳ）のような本来的にセキュアなネットワークプロトコルで確立される。これらのプロトコルに関連した詳細は、当業者に良く知られている。

【0018】

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

【0019】

接続データ：これは、潜在的なピアがピア・ツー・ピアセッションを確立するために互いに交換する必要のある情報である。この情報をどのように交換できるかのメカニズムの実施形態を以下に説明する。

【0020】

ＣＤＸサーバー：一実施形態におけるＣＤＸサーバーは、許可されたエンティティが任意のデータを交換するのを許す認証されたマルチキャストリフレクタである。このデータは、ペイロードと称される。

【0021】

ＣＤＸセッション：ＣＤＸセッションは、ＣＤＸサーバーを経て互いに通信できるクライアント装置のグループを指す。セッションの一部分である各クライアント装置には、ＣＤＸチケットが指定される。各セッションは、個々のセッションを識別し又は参照するのに使用できる大きな整数である独特のＣＤＸセッションＩＤを有する。

【0022】

ＣＤＸ要求：クライアント装置からＣＤＸサーバーへ送信される要求である。この要求は、一般的に、２つの部分、即ちＣＤＸチケット及びペイロードより成る。この実施形態では、ペイロードは、セッションキーで暗号化される接続データである。

【0023】

ＣＤＸ応答：ＣＤＸ応答は、ＣＤＸサーバーがＣＤＸセッションのメンバーからＣＤＸ要求を受信するときにＣＤＸセッションにおいて他の装置へ「反射して」戻されるものである。これは、所与のＣＤＸ要求に使用されるＣＤＸチケットのＣＤＸチケットスタブにペイロードを添付することにより構成される。

【0024】

ＣＤＸチケット：ＣＤＸチケットは、ＣＤＸセッションのメンバーにペイロードをどのように送信するかＣＤＸサーバーに告げる。一実施形態では、偽造又は改竄を防止するためにＣＤＸチケットキーで「署名」される。図３に示すように、一実施形態では、ＣＤＸチケットは、次の情報を含む。

【0025】

一実施形態では暗号化もされず分かり難くもされないセッションＩＤ３０１。

【0026】

一実施形態では暗号化もされず分かり難くもされないセッションにおける参加者３０２の数。

【0027】

このチケットが参照する（一実施形態では暗号化もされず分かり難くもされない）セッションにおける参加者のインデックス３０３。

【0028】

それ以降チケットが無効となると考えられる（一実施形態では暗号化もされず分かり難くもされない）満了日時３０４。

【0029】

セッションの各参加者のためのもので、一実施形態ではＣＤＸチケットキーを使用して暗号化されたＣＤＸホールパンチデータ３０５−３０６。

【0030】

ＣＤＸチケットキーを使用するメッセージ認証コード３０７であって、チケットが本物であることを保証するために「デジタル署名」として働くもの。

【0031】

ＣＤＸチケットスタブ：ＣＤＸチケットの第１の部分から、ＣＤＸホールパンチデータ及びメッセージ認証コードを差し引いたもの。

【0032】

ペイロード：これは、ＣＤＸ要求及びＣＤＸ応答の第２の部分である。ペイロードは、クライアント装置がＣＤＸセッションにおいて他の装置と通信することを望むデータである。この実施形態では、ペイロードは、接続データをセッションキーで暗号化したものである。ＣＤＸサーバーは、ペイロードを解読せず、一実施形態では、不変のまま通過させるだけである。

【0033】

セッションキー：これは、接続データを暗号化するためにクライアントにより使用されるキーである。一実施形態では、このキーは、ＣＤＸサーバーに知られていない。この実施形態では、セッションキーは、マッチメークサービスにより発生され、そしてそれらの個々のＣＤＸチケットと共にクライアントへ送信される。

【0034】

ＣＤＸチケットキー：これは、ＣＤＸチケットを生成しそしてそれに「署名」するのに使用されるキーである。ＣＤＸチケットキーは、ＣＤＸサーバーと、ＣＤＸチケットを発生するサービス、即ち以下に述べるように、マッチメークサービス及び／又はインビテーションサービスとによって知られているだけである。

【0035】

ＣＤＸホールパンチ要求：ＣＤＸサーバーからＣＤＸホールパンチデータを得るのに使用されるＣＤＸ要求の特殊な形式。

【0036】

ＣＤＸホールパンチデータ：これは、情報を最初に要求したクライアントにＣＤＸサーバーがどのようにその情報を送信するか記述する不透明なデータブロブである。これは、ＣＤＸホールパンチ要求をＣＤＸサーバーへ送信することにより得られる。ＣＤＸホールパンチデータは、ＣＤＸチケットを発生する前にＣＤＸセッションにおいて各クライアント装置から収集されねばならない。ＣＤＸホールパンチデータ（時々「ＮＡＴ横断データ」とも称される）は、要求側装置のパブリックＩＰアドレス及びポートを含む。

【0037】

図２ａを参照すれば、一実施形態において、移動装置Ａ １２０及び移動装置Ｂ １２１は、１つ以上の他のコンピューティング装置とのＰ２Ｐ接続を要求するマルチプレーヤゲーム又は協力的チャットセッションのような協力的アプリケーションを実行することができる。２０１ａにおいて、移動装置Ａ １２０は、ＣＤＸホールパンチ要求をＣＤＸサーバー１１０へ送信する。ＣＤＸサーバー１１０は、次いで、２０２ａにおいて、ＣＤＸホールパンチデータで応答する。１つの実施形態において、ホールパンチデータは、移動装置ＡのパブリックＩＰアドレス及びポート、及び／又は移動装置ＡのＮＡＴを通してホールをパンチするのに必要な他のデータ（例えば、移動装置ＡのＮＡＴ形式を定義するＮＡＴ形式データ）を含む。２０１ｂ及び２０２ｂにおいて各々移動装置Ｂに対して同様のトランザクションが遂行される。

【0038】

次いで、２０３ａ及び２０３ｂにおいて、移動装置Ａ及びＢは、ＣＤＸホールパンチデータを含む対戦要求を、付加的な対戦基準（以下に述べる）と共に、マッチメークサービスへ送信する。この段階において、移動装置Ａ及びＢは、Ｐ２Ｐ接続を確立するのに必要な接続データを構成し始める。これは、例えば、標準インターネット接続確立（ＩＣＥ）トランザクションのようなトランザクションを使用して遂行される（例えば、ＮＡＴ横断サービスにより）。しかしながら、本発明の基礎的な原理は、接続データを決定するための特定のメカニズムに限定されない。

【0039】

１つの実施形態において、マッチメークサービス１１１は、対戦基準で１組のクライアント装置を見つけると、独特のＣＤＸセッションＩＤと、ＣＤＸセッションのメンバーごとの独特のＣＤＸチケットと、独特のセッションキーとを発生する。１つの実施形態では、マッチメークサービス１１１は、独特のＣＤＸチケットキーを使用してＣＤＸチケットに対してＣＤＸホールパンチデータを暗号化する。次いで、２０４ａ及び２０４ｂにおいて、マッチメークサービスは、移動装置Ａ及びＢの各々にそれらのＣＤＸチケット及びセッションキーを送信する。

【0040】

移動装置Ａは、ＣＤＸチケット及びセッションキーを受信し、そしてセッションキーを使用してその以前に決定された接続データを暗号化し、ペイロードを形成する。１つの実施形態では、移動装置Ａは、形成されたペイロードをＣＤＸチケットに添付することによりＣＤＸ要求を形成する。２０５ａにおいて、移動装置Ａは、ＣＤＸ要求をＣＤＸサーバー１１０へ送信する。又、移動装置Ｂは、同じ動作を遂行し、そして２０５ｂにおいてＣＤＸサーバーへ要求を送信する。

【0041】

２０６ａにおいて、ＣＤＸサーバー１１０は、ＣＤＸ要求を受信し、チケットを検査して、それが有効で且つ本物であるかどうか保証する（例えば、メッセージ認証コード３０７に基づいて）。ＣＤＸチケットが無効である場合には、要求がドロップされる。１つの実施形態では、ＣＤＸサーバーは、次いで、ＣＤＸチケットキーを使用して、ＣＤＸチケットに含まれたＣＤＸホールパンチデータセットを解読する。１つの実施形態では、ＣＤＸチケットキーは、チケットと共に送信される満了日時も含む。ＣＤＸサーバー１１０及びマッチメーカーサービス１１１は、暗号／解読のために２つ（以上）の異なるＣＤＸチケットキーを記憶し、その第１は、現在アクティブであり、そしてその第２は、第１のチケットキーの満了日時に到達したときにアクティブとなる。チケットを受信すると、ＣＤＸサービス１１０は、満了日時を読み取って、どのチケットキーを使用すべきか決定する。ＣＤＸチケットキーが満了になると、ＣＤＸサービス１１０及びマッチメーカーサービス１１１は、どちらも各々新たなチケットキーを発生する（それは、現在チケットキーが満了となった後に使用される次のキーである）。１つの実施形態では、ＣＤＸサービス１１０及びマッチメーカーサービス１１１は、２つのチケットキーとの一貫性を保証するために同じキー発生アルゴリズムを実行する。例えば、新たな認証コードが固定インターバルで発生される、良く知られたＲＳＡ ＳｅｃｕｒＩＤ認証メカニズムに使用されるもののような技術が使用されてもよい。１つの実施形態では、新たなＣＤＸチケットキーが毎日発生される。しかしながら、本発明の基礎的な原理は、ＣＤＸチケットキーを発生するための特定のメカニズムに限定されない。

【0042】

移動装置Ｂについては２０６ｂに示すように同じ動作を遂行することができる。ＣＤＸサーバーは、ＣＤＸ要求からＣＤＸ応答を形成し、次いで、ＣＤＸホールパンチデータを使用して、ＣＤＸ応答をＣＤＸセッションの参加者へ送信する（２０７ａでは移動装置Ｂへ及び２０７ｂでは移動装置Ａへ送信する）。

【0043】

移動装置Ｂは、ＣＤＸサーバーからＣＤＸ応答２０７ａを受信する。クライアント装置Ｂは、ＣＤＸチケットスタブを検査し、セッションＩＤがそれ自身のＣＤＸチケットのセッションＩＤに一致することを保証する。次いで、移動装置Ｂは、セッションキーを使用してペイロードを解読し、移動装置Ａから接続データを発生させる。次いで、移動装置Ｂは、移動装置Ａからの接続データを使用して、Ｐ２Ｐセッション確立プロセスを開始する。１つの実施形態では、これらは、標準ＩＣＥトランザクションを含む。しかしながら、本発明の基礎的な原理は、Ｐ２Ｐ通信を確立する特定のメカニズムに限定されない。

【0044】

上述したように、１つの実施形態では、移動装置Ａ及びＢは、ハイパーテキストトランスファープロトコルセキュア（“ＨＴＴＰＳ”）セッションを確立して、（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）マッチメーカーサービス１１１と通信すると共に、ＵＤＰソケットを確立して、ＣＤＸサービスと通信する。対戦要求２０４ａ、２０４ｂは、各移動装置について以前に決定されたＮＡＴ形式及びホールパンチデータ（例えば、パブリックＩＰアドレス及びポート）を含む。マルチプレーヤゲームを含む実施形態では、各対戦要求は、各移動装置のプレーヤ（例えば、独特のプレーヤＩＤコードを使用して）、各ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び／又は望ましいゲームに関連した他のゲーム構成変数を識別する。例えば、これに限定されないが、ゲームに関連したゲーム構成変数は、困難さのレベル（例えば、容易、普通、困難）、ユーザ年齢（例えば、１３未満）、ゲームのサブ領域（例えば、レベル２）、及び／又はプレーヤの熟練度レベル（例えば、熟練者、初心者、中間者）を含む。以下に詳細に述べるように、これらの変数は、時々、ゲーム「バケット(bucket)」とも称され、独特の「バケットＩＤ」を使用して識別される。各ゲームは、異なるゲーム構成変数を識別するためにバケットＩＤの異なるセットを含む。

【0045】

１つの実施形態では、移動装置Ｂは、２０８ａ及び２０９ａにおいて送信及び確認を行う。同様に、移動装置Ａの確認は、２０８ｂ及び２０９ｂにおいて送信される。移動装置Ａ又はＢの確認が指定の期間後に受け取られない場合には、接続データ２０７ａが移動装置Ｂ ２１２へ再送信される。ＣＤＸサービス１１０が再試みを開始するか、及び／又は移動装置Ａ １２０が再試みを開始する。

【0046】

図２ｂは、３つの異なる移動装置１２０−１２２がＣＤＸサービス及びマッチメーカーサービス１１１を使用してＰ２Ｐ接続についてネゴシエーションする詳細例を示す。又、図２ｂは、接続を確立するために移動装置１２０−１２２により使用される２つの付加的なサービス、即ちＮＡＴ形式を決定するためのＮＡＴ横断サービス２９１と、（例えば、ＩＣＥ接続データトランザクションを利用して）各移動装置の全接続データを決定するためのＮＡＴ横断サービス２９０も示している。しかしながら、本発明の基礎的な原理に適合するための個別のサービスは要求されないことに注意されたい。例えば、別の実施形態では、これらサービス２９０−２９１の各々により遂行されるＮＡＴ横断機能は、ＣＤＸサービス１１０及び／又はマッチメーカーサービス１１１内に直接一体化されてもよい。同様に、両ＮＡＴ横断サービス２９０−２９１によって遂行される機能も、単一のＮＡＴ横断サービス内に一体化されてもよい。要約すれば、本発明の基礎的な原理に適合するために図２ｂに示す特定の機能分離が要求されるのではない。

【0047】

図２ｂの特定の細部を参照すれば、移動装置Ａは、ＮＡＴ形式の要求をＮＡＴ横断サービス２９１へ送信する。それに応答して、ＮＡＴ横断サービス２９１は、一連のトランザクションを実施して、移動装置Ａにより使用されるＮＡＴ形式を決定することを含む種々の既知の技術を使用することができる。例えば、ＮＡＴ横断サービス２９１は、移動装置ＡのＮＡＴの異なるＩＰアドレス及びポートをオープンし、そして異なるＩＰ／ポート組み合わせを使用してそれらのポートを経て移動装置Ａと通信するように試みる。このように、移動装置Ａによって使用されるＮＡＴは、上述したＮＡＴ形式（例えば、全コーン、制限コーン、ポート制限コーン、対称性）、或いは別のＮＡＴ形式の１つとして分類される。次いで、この情報は、図示されたように、移動装置Ａ １２０へ送られる。

【0048】

２２１において、移動装置Ａ １２０は、ＣＤＸサービス１１０とでＮＡＴ横断要求を開始する。それに応答して、ＣＤＸサービス１１０は、要求に使用されるパブリックＩＰアドレス及びパブリックポート番号を読み取り、そしてその情報を移動装置Ａ １２０へ返送する。上述したように、装置がＮＡＴの後方にある場合には、そのパブリックポート及びＩＰアドレスが、各々、そのプライベートポート及びＩＰアドレスとは異なる。従って、使用されるＮＡＴの形式に基づいて、パブリックＩＰアドレス及びポートは、ＮＡＴ装置を通して「ホールをパンチ」して、移動装置に到達するのに使用される。

【0049】

２２２において、移動装置Ａ １２０は、対戦要求２２２をマッチメーカーサービス１１１へ送信する。上述したように、１つの実施形態では、移動装置Ａは、ハイパーテキストトランスファープロトコルセキュア（“ＨＴＴＰＳ”）セッションを使用して（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）、マッチメーカーサービス１１１と通信する。対戦要求は、移動装置Ａ １２０について以前に決定されたＮＡＴ形式及びホールパンチデータ（例えば、パブリックＩＰアドレス及びポート）を含む。マルチプレーヤゲームを含む実施形態では、対戦要求は、各移動装置Ａのプレーヤ（例えば、独特のプレーヤＩＤコードを使用して）、ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び／又は望ましいゲームに関連した他のゲーム構成変数を識別する（図２ａを参照して上述したように）。

【0050】

２２３−２２５において、トランザクション２２０−２２２に対応する１組のトランザクションが移動装置Ｂ １２１に対して遂行され、そして２２６−２２８において、トランザクション２２０−２２２に対応する１組のトランザクションが移動装置Ｃ １２２について遂行される。従って、トランザクション２２８に続いて、マッチメーカーサービス１１１は、３つの移動装置１２０−１２２の前部に対して対戦要求を受け取る。この特定の例では、対戦要求の結果、移動装置１２０−１２２は、マルチプレーヤゲームのような特定の協力的セッションに対して対戦が組まれる（例えば、それら移動装置のユーザは、同じ又は同様の組の変数で同じゲームを選択し、従って、マッチメーカーサービス１１１により対戦が組まれる）。

【0051】

マッチメーカーサービス１１１は、各対戦要求に含まれたデータを使用して、２２９において移動装置Ａへ送信されるチケットＡ；２３０において移動装置Ｂへ送信されるチケットＢ；及び２３１において移動装置Ｃへ送信されるチケットＣ；を発生する。図２ｂには示されていないが、マッチメーカーサービス１１１は、プッシュ通知サービスを利用して、チケットＡ、Ｂ及びＣを、各々、移動装置Ａ、Ｂ及びＣへとプッシュする（例えば、図１１−１２に示すプッシュ通知サービス１０５０のように）。チケットＡ、Ｂ及びＣに使用されるチケットデータ構造の一実施形態は、図３を参照して上述した。

【0052】

２３２において、移動装置Ａ １２０は、ＮＡＴ横断サービス２９０と通信して、それ自身の接続データを決定する。１つの実施形態では、これは、標準ＩＣＥ接続データトランザクションを含む。上述したように、接続データは、移動装置Ａ １２０に対するパブリック／プライベートＩＰアドレス、ポート及びＮＡＴ形式を含む。

【0053】

移動装置Ａ １２０は、その接続データをチケットＡに添付し、そして２３３において、チケットＡを接続データと共に、ＣＤＸサービス１１０へ送信する。一実施形態では、ＣＤＸサービス１１０は、チケットＡを上述したように処理し、そして２３４において、接続データ（暗号化されてもよい）を移動装置Ｂ １２１及び移動装置Ｃ １２２へ送信する。これらのトランザクションに対して、ＣＤＸサービス１１０は、チケットＡと共に含まれる移動装置Ｂ及びＣのＮＡＴ横断データを利用する。

【0054】

２３６−２３８において、トランザクション２３２−２３４に対応する１組のトランザクションがチケットＢを使用して遂行され、そして２３８−２４０において、トランザクション２３２−２３４に対応する１組のトランザクションがチケットＣに対して遂行される。従って、トランザクション２４０に続いて、各移動装置１２０−１２２間に接続データが共有される。接続データを使用して、移動装置ＡとＢとの間、移動装置ＡとＣとの間及び移動装置ＡとＣとの間にＰ２Ｐセッションが確立される。

【0055】

図２ｃに示したように、インビテーションサービス１１２も、ＣＤＸサービス１１０に使用される（マッチメーカーサービス１１１に代わって又はそれに加えて）。１つの実施形態では、インビテーションサービス１１２は、特定の移動装置、及び／又はユーザとのＰ２Ｐ接続に対してインビテーション要求を処理する。インビテーションサービス１１２は、ステートレスサービス（即ち、各ワイヤレス装置間のトランザクションの現在状態をタックしないサービス）として実施することができる。

【0056】

この特定例を参照すれば、２５０において、移動装置Ａ １２０は、ＮＡＴ形式の要求をＮＡＴ横断サービス２９１へ送信する。それに応答して、ＮＡＴ横断サービス２９１は、移動装置Ａにより使用されるＮＡＴ形式を決定するために種々の既知の技術を使用する（その幾つかは、上述した）。２５１において、移動装置Ａ １２０は、ＣＤＸサービス１１０とでＮＡＴ横断要求を開始する。それに応答して、ＣＤＸサービス１１０は、その要求に使用されるパブリックＩＰアドレス及びパブリックポート番号を読み取り、そしてこの情報を移動装置Ａ １２０へ返送する。上述したように、装置がＮＡＴの後方にある場合には、そのパブリックポート及びＩＰアドレスは、各々、そのプライベートポート及びＩＰアドレスとは異なる。従って、使用されるＮＡＴの形式に基づいて、パブリックＩＰアドレス及びポートは、ＮＡＴ装置を通して「ホールをパンチ」して、移動装置に到達するのに使用される。

【0057】

マッチメーカーサービスの場合と同様に、１つの実施形態では、各移動装置は、ハイパーテキストトランスファープロトコルセキュア（“ＨＴＴＰＳ”）セッションを使用して（例えば、ＨＴＴＰＳ要求／応答トランザクションを使用して）、インビテーションサービス１１２と通信する。

【0058】

２５２において、移動装置Ａ １２０は、移動装置ＡのＮＡＴ横断データ（例えば、ＮＡＴ形式、パブリックＩＰアドレス／ポート）を含むインビテーション要求をインビテーションサービス１１２へ送信する。（以下に詳細に述べる）プッシュ通知サービスを利用する実施形態では、インビテーション要求は、移動装置Ａのプッシュトークンも含む。又、インビテーション要求２５２は、１つ以上の他のユーザ／装置、このケースでは、移動装置Ｂ １２１及びＣ １２２のユーザを識別する識別コードも含む。種々の異なる識別コード形式が使用される。例えば、マルチプレーヤゲームのケースでは、識別コードは、ゲーム特有のプレーヤＩＤコードを含む。オーディオ／ビデオチャットセッションのケースでは、識別コードは、移動装置Ａのユーザの「仲間(buddy)」リストから１人以上のユーザを識別する電話番号又は独特のＩＤコードを含む。

【0059】

１つの実施形態では、インビテーションサービス１１２は、インビテーション要求から識別コードを読み取り、そして登録データベース（図示せず）においてルックアップを遂行して移動装置Ｂ及びＣの各々を探索する。１つの特定の実施形態では、移動装置Ｂ及びＣの各々は、インビテーションサービス１１２からプッシュ通知を受信するためにプッシュサービスに既に登録されている。従って、この実施形態では、インビテーションサービス１１２は、プッシュ通知サービスを使用して、２５３及び２５４においてインビテーション要求を移動装置Ｂ １２１及び移動装置Ｃ １２２へ各々プッシュする。プッシュ通知サービスに関連した付加的な詳細は、以下に説明する（例えば、図１１−１２及び関連テキストを参照）と共に、前記で参照したプッシュ通知アプリケーションに述べられている。

【0060】

１つの実施形態において、インビテーション要求２５３及び２５４は、図３に示されて図２ａ−ｂを参照して述べたチケットデータ構造を含む。特に、移動装置Ｂへ送られるチケットは、移動装置Ａ及びＢを識別する暗号リストを含み、そして移動装置Ｃへ送られるチケットは、移動装置Ａ及びＣを識別する暗号リストを含む。１つの実施形態では、インビテーションサービス１１２が移動装置ＢのＮＡＴ横断データをまだもたないので、２３５における「チケット」は、移動装置Ｂを識別する他の情報を含む。例えば、リレーサービス及びプッシュ通知サービスを利用する実施形態を参照して以下に述べるように（例えば、図１１−１２を参照）、２５３における「チケット」は、移動装置ＡのＮＡＴ横断データ、装置ＡのＩＤコード、装置Ａのプッシュトークン、装置ＢのＩＤコード、及び移動装置Ｂのプッシュトークンを含む。２５４において、移動装置Ａ及びＣに対して同じ形式の情報が与えられる。

【0061】

２５５において、移動装置Ｂは、ＮＡＴ横断サービス２９１と通信して、そのＮＡＴ形式を決定し、そして２５６において、移動装置Ｂは、ＣＤＸサービス１１０と通信して、そのＮＡＴ横断データ（例えば、パブリックＩＰアドレス／ポート）を決定する。２５７において、移動装置Ｂは、移動装置Ａ及び移動装置Ｂの識別コード、ＮＡＴ横断データ、及びプッシュ通知サービスが使用される場合には移動装置Ａ及びＢのプッシュトークンを含むインビテーション応答をインビテーションサービス１１２へ送信する。２５８において、移動装置Ｂは、ＮＡＴ横断サービス２９０と通信することによりその現在接続データを検索する。２５９において、移動装置Ｂは、そのチケット（チケットＢ）をその現在接続データと共にＣＤＸサービス１１０へ送信する。それに応答して、ＣＤＸサービス１１０は、上述したように、チケットを処理し、そして接続データを移動装置Ａ １２０へ転送する。

【0062】

移動装置Ｂのインビテーション応答を受信すると、インビテーションサービス１１２は、移動装置Ａのための暗号チケットを発生し、そしてそのチケットを２６０において移動装置Ａへ送信する。１つの実施形態では、チケットは、ＮＡＴ横断データ、ＮＡＴ形式、並びに移動装置Ａ及びＢのプッシュトークン（プッシュ通知サービスが利用される場合）を含む。図２ｃを参照して述べる「チケット」は、マッチメーカーサービス１１１に関して述べる「チケット」のデータ構造と同じでもよいし異なってもよい。例えば、上述した暗号「チケット」発生するのではなく、インビテーションサービス１１２は、各移動装置とのインビテーションセッションを識別するために独特のセッションＩＤを発生するだけでよい。

【0063】

２６１において、移動装置Ａは、ＮＡＴ横断サービス２９０と通信することによりその現在接続データを検索する。次いで、移動装置Ａは、その接続データをチケットに添付し、そして２６２において、チケットをその接続データと共にＣＤＸサービス１１０へ送信する。ＣＤＸサービス１１０は、上述したようにチケットを処理し、そして移動装置Ａの接続データを移動装置Ｂへ転送する。最終的に、２６３において、移動装置Ａ及びＢは、交換した接続データを使用して、直接Ｐ２Ｐ接続をオープンする。以下に述べるように、移動装置Ａ及びＢのＮＡＴ形式が適合しない場合には、リレーサービスを利用して、移動装置ＡとＢとの間の通信を行うことができる。

【0064】

２６４−２７２において、移動装置Ｃ １２２及び移動装置Ａは、移動装置Ｂ及びＡについて２５５−２６３で述べたように、Ｐ２Ｐ接続を確立するために一連のトランザクションを実行する。より詳細には、６２４において、移動装置Ｃ １２２は、ＮＡＴ横断サービス２９１と通信して、そのＮＡＴ形式を決定し、そして２６５において、ＣＤＸサービス１１０と通信して、そのＮＡＴ横断データを決定する（例えば、パブリックＩＰアドレス／ポート）。２６６において、移動装置Ｃは、移動装置Ｃ及び移動装置ＡのＮＡＴ形式、ＮＡＴ横断データ及びプッシュトークン（プッシュ通知サービスが利用される場合）を含むインビテーション応答を送信する。２６７において、移動装置Ｃは、ＮＡＴ横断Ｐ２Ｐサービス２９０を通してその現在接続データを検索し、そして２６８において、移動装置Ｃは、その接続データをチケットＣに添付して、チケットＣをＣＤＸサービス１１０へ送信する。ＣＤＸサービス１１０は、上述したようにチケットを処理し、そして移動装置Ｃの接続データを移動装置Ａ １２０へ転送する。

【0065】

２６９において、移動装置Ａ １２０は、両移動装置Ａ及びＣのＮＡＴ形式、ＮＡＴ横断データ及びプッシュトークン（プッシュ通知サービスが利用される場合）を含むインビテーションサービス１１２からの移動装置Ｃのインビテーション応答を受信する。２７０において、移動装置Ａは、ＮＡＴ横断サービス２９０からその現在接続データを検索し、その現在接続データをチケットＡに添付し、そして２７１において、チケットＡをＣＤＸサービス１１０へ送信する。或いは又、移動装置がその接続データをトランザクション２６１において決定するので、トランザクション２７０は必要とされなくてもよい。ＣＤＸサービス１１０は、上述したようにチケットＡを処理し、そして移動装置Ａの接続データを移動装置Ｃへ転送する。最後に、２７２において、移動装置Ａ及びＣは、交換した接続データを使用して、直接的なＰ２Ｐ接続２７２を確立する。

【0066】

１つの実施形態において、インビテーションサービス１１２及びマッチメーカーサービス１１１は、移動装置へデータをプッシュするためにプッシュ通知サービス（図示せず）に依存する。例えば、図２ｃにおいて、インビテーション要求２５３及び２５４がプッシュ通知サービスを経て移動装置Ｂ １２１及びＣ １２２へプッシュされる。同様に、図２ａでは、チケットＡ及びＢは、移動装置Ａ １２０及びＢ １２１へプッシュされる。１つの実施形態において、移動装置は、それがネットワークにおいてアクチベートされると、そのプッシュトークンを、プッシュ通知サービスによりアクセスできる中央登録ディレクトリに登録する。１つの実施形態では、登録ディレクトリは、パスワード保護されたユーザＩＤ又は電話番号をプッシュトークンに関連付ける。ディレクトリにおいてプッシュトークンを識別できる場合には、プッシュ通知サービスがそのプッシュトークンを使用してプッシュ通知を移動装置へ送信する。１つの実施形態では、プッシュ通知サービスは、本出願の譲受人により設計されて、例えば、前記で参照された「プッシュ通知アプリケーション」に述べられた「アップル（Ｒ）プッシュ通知サービス（ＡＰＮＳ）」である。しかしながら、プッシュ通知サービスは、図２ａ−ｃに示す本発明の実施形態では必要とされないことに注意されたい。例えば、ＣＤＸサービス１１０がここに述べる動作を遂行するためにプッシュ通知が要求されることはない。

【0067】

図４は、接続データを交換するためにＣＤＸサービス１１０により具現化される方法を示し、そして図５は、接続データを交換してＰ２Ｐ接続を確立するために移動装置により具現化される方法を示す。これら方法の幾つかの観点は、図１−２ｃを参照して既に上述した。特に、これらの方法は、図１−２ｃに示すネットワークアーキテクチャーに関して具現化されるが、そのようなアーキテクチャーに限定されない。１つの実施形態において、それらの方法は、プロセッサにより実行されたときに、それら方法の動作を遂行するようにさせるプログラムコードで実施される。そのプログラムコードは、プロセッサにより実行される間にランダムアクセスメモリ（ＲＡＭ）のようなマシン読み取り可能な媒体に記憶される。プロセッサは、汎用プロセッサ（例えば、Ｉｎｔｅｌ Ｃｏｒｅ(登録商標)プロセッサ）又は特殊目的プロセッサである。しかしながら、これらの方法は、ハードウェア、ソフトウェア及びファームウェアの組み合わせを使用して具現化される。更に、プログラムコードは、ハードディスクドライブ、光学的ディスク（例えば、デジタルビデオディスク又はコンパクトディスク）、又はフラッシュメモリ装置のような不揮発性メモリに記憶される。

【0068】

図４に示す方法を参照すれば、４０１において、特定の移動装置、この例では、「移動装置Ａ」に対してＮＡＴ横断要求（時々「ホールパンチ」要求とも称される）が受信される。４０２において、ＮＡＴ横断応答が発生されて、移動装置Ａへ送信される。１つの実施形態では、ＮＡＴ横断応答を発生することは、移動装置Ａの現在パブリックＩＰアドレス／ポート及び／又はＮＡＴ形式を決定することを含む。

【0069】

移動装置Ａのチケットは、その後、上述したマッチメーカーサービス１１１又はインビテーションサービス１１２のようなチケット発生エンティティにより発生されて暗号化される。４０３において、ＮＡＴ横断データ（装置Ａ及び１つ以上の他の装置の）及び装置Ａの接続データを含む、移動装置Ａに対して発生されたチケット（チケットＡ）が受信される。４０４において、メッセージ認証コードを使用してチケットが認証され、そしてチケットの暗号化のためにチケット発生エンティティにより使用されたものと同じＣＤＸチケットキーを使用してホールパンチデータが解読される。上述したように、１つの実施形態では、ＣＤＸチケットキーに関連した満了日時を使用して正しいＣＤＸチケットキーが識別される。

【0070】

４０５において、移動装置のＮＡＴ横断データが抽出される。４０６において、ＮＡＴ横断データを使用して移動装置Ａの接続データが各ピアへ送信される。４０７において、各ピアから確認が受信される。４０８において、全てのピアから確認が受信されていないことが決定されると、移動装置Ａの接続データが、４０９において、応答していないピアへ再送信される。全ての接続データが確認されたことが４０８において決定されると、この方法は、終了となる。

【0071】

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

【0072】

図５は、ここに述べる本発明の実施形態により移動装置により遂行できる方法を示す。５０１において、ＮＡＴ横断要求が送信され、そして５０２において、ＮＡＴ横断応答が受信される。先に述べたように、応答に含まれるＮＡＴ横断データは、要求側装置のパブリックポート／ＩＰアドレスを含む。５０３において、ＮＡＴ横断データを含む対戦要求が送信される。その後、上述したマッチメーカーサービス１１１又はインビテーションサービス１１２のようなチケット発生エンティティにより移動装置のチケットが発生されて暗号化される。上述したチケットデータ構造とは別に、マッチメーカーサービス１１１及び／又はインビテーションサービス１１２は、独特のセッションＩＤを使用して各参加者を単に識別するだけである。

【0073】

５０４において、チケットが受信され；５０５において、移動装置の接続データがチケットに添付され；５０６において、接続データを伴うチケットが送信される。５０７において、１つ以上の他のピアとＰ２Ｐ接続を確立するのに必要な接続データが受信される。５０８において、５０６で送信された接続データを１つ以上の他のワイヤレス装置が受信したことを示す確認が受け取られる。全ての確認が受け取られない場合には、５１０において、確認が受け取られなかった移動装置へ接続データが再送信される。全ての確認が受け取られたことが５０９において決定されると、５０７で受け取られた接続データを使用して、他の移動装置とのＰ２Ｐセッションが確立される。

【0074】

バックアップ通信チャンネルを確立して使用する装置及び方法
現在の移動装置は、種々の異なる通信チャンネルを経て通信を行うことができる。例えば、アップル（Ｒ）ｉＰｈｏｎｅ^TM（登録商標）は、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ、ｇ、ｎ ネットワーク）；３Ｇネットワーク（例えば、ユニバーサル移動テレコミュニケーションズシステム（ＵＭＴＳ）ネットワーク、高速アップリンクパケットアクセス（ＨＳＵＰＡ）ネットワーク、等）；及びＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク（パーソナルエリアネットワーク（ＰＡＮ）としても知られている）を経て通信することができる。将来の移動装置は、幾つか挙げると、ＷｉＭＡＸ、インターナショナル移動テレコミュニケーション（ＩＭＴ）アドバンスト、及び長期進化（ＬＴＥ）アドバンストのような付加的な通信チャンネルを経て通信を行うことができる。

【0075】

動作中に、現在の移動装置は、１組の利用可能なチャンネルの中から１つの一次通信チャンネルを選択する。例えば、移動装置は、Ｗｉ−Ｆｉ接続が利用できる場合にはそれを選択し、そしてＷｉ−Ｆｉが利用できない場合にはセルラーデータ接続（例えば、ＵＴＭＳ接続）を選択するようにしばしば構成される。

【0076】

本発明の１つの実施形態では、移動装置のグループは、最初、標準的ＩＣＥ接続データ交換を使用し及び／又は上述した接続データ交換技術を使用して、一次ピア・ツー・ピア（Ｐ２Ｐ）通信チャンネルを確立する。次いで、移動装置は、一次チャンネルを経て接続データを交換して１つ以上の二次通信チャンネルを確立し、このチャンネルは、いずれかの一次チャンネルが失敗となった場合にバックアップチャンネルとして使用される。１つの実施形態において、二次通信チャンネルは、それらのチャンネルを経て「心鼓動」パケットを周期的に送信することにより、ＮＡＴファイアウオールを通してオープンに維持される。

【0077】

ここで使用する通信「チャンネル」とは、２つの移動装置間の完全なネットワーク経路を指し、そして通信「リンク」とは、通信経路に使用される１つの特定の接続を指す。例えば、装置ＡがＷｉ−Ｆｉ接続を使用してインターネットに接続され、そして装置Ｂが３Ｇ接続を使用してインターネットに接続された場合には、装置Ａと装置Ｂとの間の「チャンネル」は、Ｗｉ−Ｆｉリンク及び３Ｇリンクの両方により定義され、装置Ａは、Ｗｉ−Ｆｉ通信「リンク」を有し、そして装置Ｂは、３Ｇ通信「リンク」を有する。従って、装置ＡがＷｉ−Ｆｉリンクから３Ｇリンクへスイッチする場合には、装置Ｂの３Ｇリンクが同じままであるにも関わらず、装置Ａと装置Ｂとの間の「チャンネル」が変更される。

【0078】

移動装置が一次及び二次通信チャンネルを確立する特定の例を、図６を参照して以下に述べる。しかしながら、本発明の基礎的な原理は、図６に示す通信リンク及び通信チャンネルの特定セットに限定されないことに注意されたい。

【0079】

図６において、移動装置Ａ ６０１は、ＮＡＴ装置６１１との通信リンク６０５を経て及びＮＡＴ装置６１２との通信リンク６０６を経てネットワーク６１０（例えば、インターネット）に接続することができる。同様に、装置Ｃ ６０３も、ＮＡＴ装置６１３との通信リンク６０９を経て及びＮＡＴ装置６１４との通信リンク６１０を経てネットワーク６１０に接続することができる。例えば、これに限定されないが、通信リンク６０５及び６０９は、３Ｇ通知ンリンクであり、通知ンリンク６０６及び６１０は、Ｗｉ−Ｆｉ通信リンクである。

【0080】

従って、この例では、移動装置Ａと移動装置Ｂとの間には、リンク６０５及び６０９を使用する第１のチャンネル、リンク６０５及び６１０を使用する第２のチャンネル、リンク６０６及び６０９を使用する第３のチャンネル、並びにリンク６０６及び６１０を使用する第４のチャンネル、の４つの異なる通信チャンネルが確立される。１つの実施形態において、移動装置Ａ及びＢは、これらチャンネルの１つを、プライオリティ決めスキームに基づいて一次通信チャンネルとして選択し、そして３つの残りのチャンネルをバックアップ通知ンチャンネルとして選択する。例えば、１つのプライオリティ決めスキームは、最も高い帯域巾をもつチャンネルを一次チャンネルとして選択し、そして残りのチャンネルを二次チャンネルとして使用する。２つ以上のチャンネルが同等の帯域巾を有する場合には、優先順位決めスキームは、最も安価なチャンネルを選択することを含む（１つ以上のチャンネルを使用するためにユーザが料金を支払うと仮定すれば）。或いは又、プライオリティ決めスキームは、最も安価なチャンネルを一次チャンネルとして選択し、そして各チャンネルのコストが同じ場合には、最も高い帯域巾のチャンネルを選択する。本発明の基礎的な原理に適合しながら、種々の異なるプライオリティ決めスキームを具現化することができる。

【0081】

移動装置Ａ ６０１及びＣ ６０３は、上述した技術を使用して、一次通信チャンネルを確立する（例えば、ＣＤＸサービス１１０を経て接続データを交換することにより）。或いは又、移動装置６０１、６０３は、標準的インターネット接続確立（ＩＣＥ）トランザクションを具現化して、接続データを交換することもできる。一次チャンネルをどのように確立するかに関わらず、それが確立されると、移動装置Ａ ６０１及びＣ ６０３は、一次通信チャンネルを経て二次通信チャンネルのための接続データを交換する。例えば、図６の一次通信チャンネルが通信リンク６０６及び通信リンク６０９を含む場合には、この接続が確立されると、それを使用して、通信リンク６０５及び６０９を含む二次通信チャンネルの接続データを交換する。この例では、一次通信チャンネルを経て交換される接続データは、各移動装置のパブリック及びプライベートＩＰアドレス／ポートを含めて、ＮＡＴ６１１及びＮＡＴ６１３のＮＡＴ横断データ及びＮＡＴ形式データを含む。

【0082】

二次通信チャンネルが確立されると、それらは、心鼓動パケットを使用してオープンに維持される。例えば、装置Ａは、小さな「心鼓動」パケットを装置Ｃへ周期的に送信し、及び／又は装置Ａは、二次チャンネルに使用されるＮＡＴポートがオープンのままであるよう保証するために小さな「心鼓動」パケットを装置Ｃへ周期的に送信する（ＮＡＴは、インアクティビティによりポートをしばしばクローズする）。心鼓動パケットは、ペイロードを伴わないＵＤＰパケットであるが、本発明の基礎的な原理は、特定のパケットフォーマットに限定されない。心鼓動パケットは、それらのペイロードヘッダに自己識別形式のフィールドを伴うＵＤＰパケットであり、これに限定されないが、チャンネル生存時間(time-to-live)値を含む任意に付加的にフォーマットされる情報を含む。

【0083】

図７に示すように、各移動装置６０１は、一次及び二次通信チャンネルのリストを含むデータ構造体７１０（例えば、テーブル、テキストファイル、データベース、等）を記憶し維持する。通信チャンネルごとに個別のエントリが設けられ、これは、そのチャンネルを使用するのに必要な接続データ（例えば、プライベート／パブリックＩＰアドレス、ＮＡＴ形式、等）と、そのチャンネルの現在状態（例えば、一次、二次１、二次２、等）を含む。

【0084】

１つの実施形態では、通信リンク６０５及び通信リンク６０６を経て各々通信するために通信インターフェイス７０１及び７０２が使用される。特定の通信インターフェイス／リンクが失敗となるか又は指定スレッシュホールドより下がったときを検出するために、移動装置６０１において欠陥検出モジュール７０５を実行することができる。それに応答して、リンクマネージメントモジュール７０６は、一次／二次接続データ７１０を読み取り、次に最も高いプライオリティを有する二次チャンネルを一次チャンネルへ昇進させる。二次チャンネルのプライオリティ決めは、一次チャンネルについて上述したものと同じ原理を使用して遂行される（例えば、帯域巾、コスト、信頼性、等）。二次チャンネルが選択されると、リンクマネージメントモジュール７０６は、他の移動装置のリンクマネージメントモジュールへリンク欠陥指示を送信して、それらの装置に、二次通信チャンネルを一次通信チャンネルへ昇進させるよう命令する。次いで、それらの装置は、選択された一次チャンネルに関連した接続データの使用を開始する。

【0085】

１つの実施形態では、二次通信チャンネルの１つへの切り換えを強制するのに一次通信チャンネルの完全な「欠陥」が要求されるのではない。例えば、一実施形態では、一次通信チャンネルが充分に質低下した場合に（例えば、特定の帯域巾、ビットレート又は信頼性スレッシュホールドより低く）、ここに述べるように、二次チャンネルへの切り換えが実施される。一実施形態では、二次チャンネルへの切り換えは、二次チャンネルが現在の一次チャンネルより優れた性能（例えば、帯域巾、ビットレート又は信頼性）をサポートできる場合にしか遂行されない。

【0086】

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

【0087】

二次チャンネルを確立して維持する方法の１つの実施形態が図８に示されている。１つの実施形態において、この方法は、各移動装置のリンクマネージメントモジュール７０６により実行される。しかしながら、この方法は、特定の装置構成に限定されない。

【0088】

９０１において、一次Ｐ２Ｐ通信チャンネルが選択される。上述したように、一次チャンネルは、既定のプライオリティ決めスキームに基づいて選択される。例えば、ある通信チャンネル形式が、他の通信チャンネル形式に先行してプライオリティ決めされる。又、チャンネルは、帯域巾、使用コスト、及び／又は信頼性に基づいてプライオリティ決めされてもよい。

【0089】

９０２において、バックアップＰ２Ｐ通信チャンネルが確立される。１つの実施形態では、これは、一次通信チャンネルにわたり全ての移動装置間で接続データを共有することにより達成される。９０３において、バックアップチャンネルが維持される。１つの実施形態では、これは、二次通信チャンネルを経てデータを周期的に送信することを含む（例えば、周期的な心鼓動パケットの形態で）。

【0090】

９０４において、一次Ｐ２Ｐチャンネルが失敗となった場合には（例えば、特定の移動装置の通信リンクがダウンするか、又は移動装置が通信リンクの範囲から出たために）、９０５において、移動装置は、プライオリティの最も高いバックアップチャンネルを一次チャンネルへ昇進させる。１つの実施形態では、これは、リンクが失敗となった移動装置が、そのリンク欠陥の通知を、二次チャンネルを経て他の装置へ送信することを含む。最終的に、９０６において、バックアップチャンネルが一次チャンネルとなり、そしてプロセスが９０２へ戻る（付加的なバックアップチャンネルが発見されて、プライオリティ決めスキームに追加される）。

【0091】

ピア・ツー・ピア（Ｐ２Ｐ）通信チャンネルを確立するインビテーションサービスのための装置及び方法
図１０に示すように、ＣＤＸサービス１１０、マッチメーカーサービス１１１及びインビテーションサービス１１２（その幾つかの実施形態を上述した）に加えて、本発明の一実施形態には、登録／ディレクトリサービス１０５２、プッシュ通知サービス１０５０、及びリレーサービス１０５１が含まれる。上述したように、一実施形態では、インビテーションサービス１１２及び／又はマッチメーカーサービス１１１は、登録／ディレクトリサービス１０５２を使用して、登録された移動装置を識別すると共に、プッシュ通知サービス１０５０を使用して、移動装置へデータをプッシュする。一実施形態では、移動装置は、ネットワークにおいてアクチベートされると、「プッシュトークン」（プッシュ通知アプリケーションにおいて「通知サービスアカウント識別子」とも称される）を、登録／ディレクトリサービス１０５２により維持されたデータベースに登録し、これは、そのプッシュトークンをパスワード保護ユーザＩＤ又は電話番号に関連付けることで行われる。プッシュトークンが登録ディレクトリにおいて識別される場合には（例えば、ユーザＩＤで問合せを行うことで）、プッシュ通知サービス１０５０がそのプッシュトークンを使用して、プッシュ通知を移動装置に送信することができる。１つの実施形態では、プッシュ通知サービスは、本出願の譲受人によって設計されて、例えば、前記で参照したプッシュ通知アプリケーションに述べられたアップル（Ｒ）プッシュ通知サービス（ＡＰＮＳ）である。

【0092】

図１１は、プッシュ通知サービス１０５１を使用して２つの移動装置間に直接的なＰ２Ｐ接続を確立する本発明の実施形態を示し、そして図１２は、リレーサービス１０５１を通してＰ２Ｐ接続を確立するのに使用される実施形態を示す。以下に述べるように、リレーサービス１０５１を使用してＰ２Ｐ接続を確立すべきかどうかの判断は、移動装置間に直接的なＰ２Ｐ接続を確立する実現性に基づく（例えば、ＮＡＴ互換性の問題に基づく）。

【0093】

図１１を参照すれば、１１０１において、移動装置Ａ １２０は、移動装置Ｂ １２１をＰ２Ｐ通信セッション（例えば、協力的ビデオゲーム、Ｐ２Ｐビデオチャット、等）に招待するために、移動装置Ｂを招待するインビテーションを送信する。１つの実施形態において、インビテーションは、特定のオンラインアプリケーションの環境内で移動装置Ｂ１２１（及び／又は移動装置Ｂのユーザ）を識別するユーザＩＤコードを含む。例えば、ユーザＩＤコードは、特定のマルチプレーヤ、Ｐ２ＰゲームのためのプレーヤＩＤであり、例えば、ユニバーサルユニーク識別子（ＵＵＩＤ）の形態をとる。或いは又、ある実施形態では、ＩＤコードは、移動装置Ｂ １２１の電話番号でもよい。移動装置Ａが移動装置Ｂの参加を招待するマルチプレーヤゲームを識別するためにゲームＩＤコードが使用される。そのゲームのための構成を識別するためにバケットＩＤが使用される（マッチメーカーサービスについて説明したように）。

【0094】

インビテーション１１０１は、移動装置Ａ １２０を識別するＩＤコードと、移動装置Ａに関連したＮＡＴ横断／接続データ（例えば、移動装置Ａのためのパブリック／プライベートＩＰアドレス及びポートや、装置ＡのＮＡＴ装置のＮＡＴ形式）も含む。ＮＡＴ横断／接続データ又はＮＡＴ形式データは、インビテーション要求１１０１の前に移動装置Ａにより事前に決定されてもよい（例えば、図２ａ−ｃを参照して上述したもののようなＮＡＴ横断、ＮＡＴ形式及び接続データトランザクションを経て）。上述したように、インビテーション要求１１０１は、ＨＴＴＰＳ要求の形態をとる。更に、付加的なセキュリティのために、インビテーション要求１１０１は、予め指定された証明書当局により署名されたクライアント証明書を含むことができる。

【0095】

移動装置Ｂを識別するのに使用されるＩＤコードの特定形式に関わらず、ＩＤコードは、インビテーションサービスにより受け取られ、そして１１０２において、インビテーションサービス１１２は、ディレクトリサービス１０５２（図１１には示さず）においてルックアップを遂行し、移動装置Ｂへ通知をプッシュするのに使用されるプッシュトークン（プッシュトークンＢ）のような通知サービスアカウント識別子を識別する。１つの実施形態において、ルックアップ動作は、インビテーションを許すべきかどうか決定するために多数のチェックを遂行する。先ず、移動装置Ａの識別コード（ＩＤ−Ａ）及び装置Ａのプッシュトークン（プッシュトークンＡ）がディレクトリサービスデータベース内の登録関連性であることを確認することができる。又、ルックアップ動作１１０２は、移動装置Ａのユーザが移動装置Ｂのユーザを招待することが許されたことも確認できる（例えば、移動装置Ｂのユーザは、Ｂの友人として登録された他のユーザしかユーザＢを招待できないことを指定するか、又は招待が許されないことを指定する）。１つの実施形態において、これらチェックのいずれかが失敗となった場合には、インビテーションがキャンセルされ、インビテーションサービス１１２は、移動装置Ａにエラーを返送する。

【0096】

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

【0097】

１つの実施形態において、プッシュトークンが識別された後に、インビテーションサービス１１２は、インビテーションセッションに指定されて全ての更に別のトランザクションにおいてセッションを識別するのに使用されるセキュアな一回限りの「セッショントークン」を発生することができる。次いで、セッショントークンのコピーが、移動装置Ａ １２０へ返送されると共に、インビテーション要求と共に移動装置Ｂへ送られる。１つの実施形態では、セッショントークンは、上述したチケットデータ構造体と一緒に使用され、そして別の実施形態では、セッショントークンのみが使用される。

【0098】

１１０３において、インビテーションサービス１１２は、プッシュ通知サービス１０５０にプッシュ要求を送信する。１つの実施形態において、プッシュ要求は、移動装置ＡのＮＡＴ横断データ、装置ＡのＩＤコード、プッシュトークンＡ、装置ＢのＩＤコード、及びプッシュトークンＢを含む。１つの実施形態において、この情報は、「チケット」データ構造体内にパッケージされ、そして上述したように暗号化される。別の実施形態では、データは、単に、インビテーションセッションＩＤと共に送信される。

【0099】

この例の移動装置Ｂ １２１は、プッシュ通知サービス１０５０に登録されるので、プッシュ通知サービス１０５０は、１１０４において、インビテーション要求を探索して、移動装置Ｂ １２１へプッシュすることができる。プッシュされたインビテーション１１０４は、セッショントークン、移動装置ＡのＮＡＴ横断データ／接続データ、及び移動装置ＢのＩＤコードを含む。インビテーション要求に応答して、移動装置Ｂは、上述したように、ＮＡＴ横断サービス又はＣＤＸサービス１１０へコールをなすことによりそのネットワーク情報（例えば、ＮＡＴ横断／接続データ、ＮＡＴ形式、等）を決定する。

【0100】

１１０５において、移動装置Ｂがインビテーションを受け容れる。この受け容れは、インビテーションサービス１１２へのＨＴＴＰコールの形態をとり、事前に指定された証明書当局により署名されたクライアント証明書を含む（インビテーション要求に関して上述した）。１つの実施形態では、受け容れ１１０５は、移動装置Ａ及びＢのＩＤコードと、移動装置Ａ及びＢのＮＡＴ横断／接続データ及び／又はＮＡＴ形式とを含む。又、受け容れ１１０５は、移動装置Ａ及びＢのプッシュトークン、及び／又はセッショントークンも含む。１つの実施形態では、受け容れ１１０５は、それが以前に失敗した直接接続試みからの再試みであるかどうかの指示も含む。しかしながら、別の実施形態では、受け容れ１１０５は、再試みの指示を含まない。むしろ、失敗したＰ２Ｐ接続の試みを検出すると、２つの移動装置の一方が特殊な「リレーインビテーション」をインビテーションサービス１１２へ送信する。それに応答して、そのサービスは、図１２を参照して以下に説明する一連のリレートランザクション（１２０１でスタートする）を直接開始する。

【0101】

１１０６において、インビテーションサービス１１２は、適合性チェックを遂行して、移動装置ＡとＢとの間の直接的Ｐ２Ｐ接続が実現可能であるかどうか決定する。例えば、１つの実施形態では、受け容れ１１０５が移動装置Ｂから受け取られて、それが以前に失敗した直接接続試みからの再試みである（又は指定数の以前に失敗した直接接続試みである）ことを示す場合には、インビテーションサービスは、直接的Ｐ２Ｐ接続が実現不能であると結論付ける。インビテーションサービス１１２は、移動装置Ａ及びＢのＮＡＴ形式データを比較して、移動装置Ａ及びＢのＮＡＴ装置が直接的Ｐ２Ｐ接続をサポートするかどうか決定する。ＮＡＴ形式のある組み合わせは、Ｐ２Ｐ接続を確立するのに不適合であることが知られている。例えば、全コーンＮＡＴは、直接的Ｐ２Ｐ接続を確立するためにクローズ／ファイアウオール型ＮＡＴ以外のＮＡＴ形式と共に使用される。これとは対照的に、直接的Ｐ２Ｐ接続を確立するために全コーンＮＡＴと共に使用できるのは、対称性ＮＡＴだけである。本発明の１つの実施形態において種々のＮＡＴ形式を結合する実現性が、図１４のＮＡＴ適合性テーブル１４００に示されており、ここで、列は、一方の移動装置（例えば、移動装置Ａ）のＮＡＴ形式を表わし、そして行は、他方の移動装置（例えば、移動装置Ｂ）のＮＡＴ形式を表わす。セルにおける“１．０”は、関連する行及び列のＮＡＴ形式が適合できることを示し、そして“０．０”は、ＮＡＴ形式が不適合であることを示す。

【0102】

１つの実施形態において、直接的Ｐ２Ｐ接続が実現不能であることが適合性チェック１１０６で決定されると、インビテーションサービス１１２は、図１２を参照して以下に述べるように、リレールックアップ要求１２０１を送信する。しかしながら、直接的Ｐ２Ｐ接続が実現可能であることが適合性チェック１１０６で決定されると、インビテーションサービス１１２は、移動装置Ａのインビテーションを移動装置Ｂが受け容れることを含むプッシュ要求１１０７をプッシュ通知サービス１０５０へ送信する。プッシュ要求１１０７と、プッシュ通知サービス１０５０から移動装置Ａへのその後のプッシュ通信１１０８は、セッショントークン、両移動装置Ａ及びＢのプッシュトークン、ＩＤコード、及び／又はＮＡＴ横断／接続データを含む。１つの実施形態において、この情報は、上述した「チケット」データ構造体内にパックされ（例えば、図２ａ−ｃ及び関連テキストを参照）、そして独特のキーを使用して暗号化される。或いは又、この情報は、単に、独特のインビテーションセッションＩＤと共に送信されてもよい。又、インビテーションサービス１０５０は、直接接続が試みられることを移動装置Ｂに通知することもできる。

【0103】

この段階において、移動装置Ａ及びＢは、直接的Ｐ２Ｐ接続を確立するに充分な情報を有する。１つの実施形態では、これは、上述したＣＤＸサービス１１０を使用して達成される。例えば、移動装置Ｂは、その接続データをチケットＢに添付し、そして１１０９において、チケットＢを（接続データと共に）ＣＤＸサービスへ送信する。このトランザクションの直前に、移動装置Ｂは、その接続データが現在のものであることを保証するために、図２ｂに示すトランザクション２３５のようなトランザクションを実施する。次いで、ＣＤＸサービス１１０は、チケットを認証し（例えば、上述した独特のセッションキーを使用して）、移動装置Ｂの接続データを抽出し、そしてその接続データを１１１０において移動装置Ａへ転送する。同様に、移動装置Ａは、その接続データをチケットＡに添付し、そして１１１１において、チケットＡを（接続データと共に）ＣＤＸサービス１１０へ送信する。このトランザクションの直前に、移動装置Ａは、その接続データが現在のものであることを保証するために、図２ｂに示すトランザクション２３２のようなトランザクションを実施する。次いで、ＣＤＸサービス１１０は、チケットを認証し（例えば、上述した独特のセッションキーを使用して）、移動装置Ａの接続データを抽出し、そしてその接続データを１１１２において移動装置Ｂへ転送する。最終的に、１１１３において、移動装置Ａ及びＢは、交換した接続データを使用して直接的Ｐ２Ｐ接続へ入る。

【0104】

図１２を参照すれば、直接的Ｐ２Ｐ接続が実現不能であることが適合性チェック１１０６で決定されると、インビテーションサービス１１２は、リレールックアップ要求１２０１をリレーサービス１０５１へ送信して、各移動装置によって使用されるリレーホストを決定する。要求１２０１は、移動装置Ａ及びＢからのネットワーク情報（例えば、ＮＡＴ横断／接続データ及び／又はＮＡＴ形式データ）を含み、これは、両移動装置に適したリレーホストを選択するためにリレーサービス１０５１により使用される。図１３に示すように、リレーサービス１０５１の一実施形態は、複数のリレーホスト１３０２−１３０３と、各リレーホストに関連したネットワーク情報を含むリレーホストデータベース１３０１とを含む。インビテーションサービス１１２は、リレールックアップ要求１２０１をリレールックアップサービス１３００へ送信し、これは、移動装置Ａ及びＢのネットワーク情報を使用してリレーホストデータベース１３０１に問合せする。データベースの結果を受け取ると、リレールックアップサービス１３００は、選択されたリレーホスト１３０２−１３０３を識別する応答１２０２を与える。

【0105】

１つの実施形態において、リレールックアップ応答１２０２は、リレーサービスにより発生されるリレートークンと、リレー接続のために移動装置Ａ及びＢにより使用されるリレーホスト１３０２−１３０３のネットワークアドレス（ＩＰアドレス／ポート）とを含む。１つの実施形態では、リレートークンは、リレーセッションに関連され、そしてリレーサービス１０５１に接続するときに移動装置Ａ及びＢを認証するためにリレーホスト１３０２−１３０３により使用される。トークンは、例えば、独特のＩＤリレーセッションＩＤコード、デジタル証明書、及び／又はリレーセッションに関連した独特の暗号キーを含む種々の形態で得られる。

【0106】

１２０３において、インビテーションサービスは、リレー接続がなされるという指示を含むリレー応答１２０３を移動装置Ｂ １２１へ送信する。１つの実施形態では、リレー応答１２０３は、リレートークン、及びリレーホストＢ １３０３のためのネットワーク情報を含む。１つの実施形態では、応答１２０３は、（プッシュ通知サービス１０５０をバイパスして）移動装置Ｂへ直接送信される。というのは、それが移動装置Ｂの受け容れ１１０５に応答して送信されるからである。

【0107】

インビテーションサービス１１２は、リレートークン、及びリレーホストＢ １３０３のネットワーク情報を含むリレー応答１２０４を移動装置Ａへ送信する。この例では、応答１２０４は、トランザクション１２０５においてプッシュ通知サービス１０５０を経て移動装置Ａへプッシュされる。

【0108】

１２０６において、移動装置Ａ １２０は、リレーホストＡ １３０２のネットワーク情報を使用して、リレーサービス１０５１との接続を確立する。同様に、１２０７において、移動装置Ｂ １２１は、リレーホストＢ １３０３のネットワーク情報を使用して、リレーサービス１０５１との接続を確立する。これらトランザクションの各々において、移動装置Ａ及びＢのＮＡＴファイアウオールに新たなホールが開けられ、そして移動装置Ａ及びＢのＮＡＴ横断／接続データは、リレーサービス１０５１により決定されて、移動装置Ａ及びＢへ各々返送される（例えば、装置のパブリックＩＰ／ポートを決定することにより）。１つの実施形態において、リレーサービス１０５１、及び移動装置Ａ、Ｂは、リレーＮＡＴ使用横断（ＴＵＲＮ）プロトコルを実施し、このプロトコルは、当業者に明らかなように、ＮＡＴ又はファイアウオールの後方の要素がＴＣＰ又はＵＤＰ接続を経て到来データを受け取るのを許す。

【0109】

１２０８において、移動装置Ａは、インビテーションサービス１１２へリレー更新を送信し、これは、１２０９において、プッシュ通知サービスへ転送され、そして１２１０において、移動装置Ｂへプッシュされる。同様に、１２１１において、移動装置Ｂは、インビテーションサービス１１２へリレー更新を送信し、これは、１２１２において、プッシュ通知サービスへ転送され、そして１２１３において移動装置Ａへプッシュされる。移動装置Ａにより送信されるリレー更新は、セッショントークンと、各装置のＩＤコードと、１２０６及び１２０７においてリレーにより決定されるＮＡＴ横断／接続データとを含む（即ち、移動装置ＡがそのＮＡＴ横断／接続データを移動装置Ｂへ送信し、及びその逆のことも言える）。１つの実施形態において、各移動装置のＮＡＴ情報が変化するために、リレー更新動作が遂行される。

【0110】

最終的に、１２１４及び１２１５において、移動装置Ａ及びＢは、各々、リレーサービス１０５１を通してＰ２Ｐ接続を確立する。１つの実施形態において、移動装置Ａが移動装置ＢのＮＡＴ横断／接続データをリレーサービス１０５１へ送信するときにリレー接続が確立され、そしてその逆のことも言え、従って、リレーサービスは、１３０２−１３０３において各ピアのリレーホストへの正しい経路を決定することができる。

【0111】

上述した技術を使用して、インビテーションサービス１１２は、膨大な数の移動装置を伴う大規模システムであっても本来拡張可能で且つ柔軟性があるステートレスサービスとして実施される。例えば、プッシュ通知サービス１０５０は、本来、コンテンツを探索しそしてそれを登録された移動装置へプッシュできるので、インビテーションサービスは、各装置の現在位置を追跡することが要求されない。更に、装置は、全セッション状態データを各要求及び応答と共に送信するので、インビテーションサービスは、接続ごとの状態情報を維持することが要求されず、従って、インビテーションサービスの記憶及び処理要件を緩和する。そのような実施は、大規模システムにおいて特に有用である。

【0112】

オンラインセッションに対してユーザを対戦させるシステム及び方法
図１５に示すように、マッチメーカーサービス１１１の１つの実施形態は、対戦要求を受け取りそして対戦応答を移動装置１２０−１２２へプッシュするためのマッチメーカーディスパッチャー１５０１と、対戦要求を要求テーブル１５０２に記憶しそして対戦可能セットデータを対戦可能セット識別子（ＭＳＩ）テーブル１５０３に記憶するためのデータベース１５１２と、データベース１５１２から対戦要求をフェッチし、対戦を組む動作を遂行し、そして対戦組み結果をデータベース１５１２に記憶するための１つ以上のマッチメーカー１５１０と、を備えている。しかしながら、本発明の基礎的な原理は、図１５に示す特定のアーキテクチャーに限定されないことに注意されたい。

【0113】

１つの実施形態において、マッチメーカーディスパッチャー１５０１は、マッチメーカーサービス１１１へのインターフェイスとして働き、移動装置１２０−１２２から要求を受け取り、その要求を、データベース１５１２に要求を記憶するコマンドへと変換し、データベース１５１２から対戦組み結果を読み取り、そしてその結果を変換して移動装置１２０−１２２へ通信する。

【0114】

動作中、新たな対戦要求が到着すると、マッチメーカーディスパッチャー１５０１は、要求テーブル１５０２の行内にその要求を記憶する。１つの実施形態では、ディスパッチャー１５０１は、（移動装置Ａ、Ｂ及びＣに各々対応して）図１５に“Ａ”、“Ｂ”及び“Ｃ”と単に示された要求ＩＤ（ＲＩＤ）コードを各対戦要求に指定する。簡単化のために図１５には文字呼称を使用して示されているが、ＲＩＤコードは、データベース内の対戦要求を追跡するのに適したストリング、整数、又は他の変数形式でよい。

【0115】

各対戦要求には、要求テーブル１５０２に記憶された対戦可能セット識別子（ＭＳＩ）の値が指定される。１つの実施形態では、ＭＳＩは、対戦が要求されている特定のアプリケーション、及び／又はそのアプリケーションに使用される構成パラメータを識別することができる。例えば、１２：４のＭＳＩ値は、識別子“１２”で特定のマルチプレーヤゲームを識別し、そして識別子“４”でゲームの特定の構成を識別する。より詳細には、１２のＩＤコードは、特定のマルチプレーヤ競走ゲームを識別し、そして４のＩＤコードは、競走ゲームの特定の競走トラック、スピード、又はプレーヤの経験レベルを指定する。１つの実施形態において、アプリケーション開発者には、このようにＭＳＩ値を使用してアプリケーション構成パラメータを指定するオプションが与えられる。１つの実施形態において、ＭＳＩを直接指定するのではなく、アプリケーション開発者は、ゲームＩＤ（特定のゲームを識別するための）及びバケットＩＤ（特定のゲーム構成を識別するための）を指定し、そしてこれらの値は、マッチメーカーディスパッチャー１５０１によりＭＳＩ値へマップされる。

【0116】

更に、多数の異なる構成パラメータを指定するために、単一のＭＳＩ内に多数の異なるＭＳＩ値が使用されてもよい（例えば、１２：４：１は、１２＝競走ゲーム；４＝トラック；及び１＝経験レベルを表わす）。以下に詳細に述べるように、１つの実施形態において、各ＭＳＩは、対戦を組む動作が遂行される１組の対戦要求を識別するためにマッチメーカー１５１０によって使用される（例えば、要求はＭＳＩに基づいてグループ化され、そして各ＭＳＩグループ内で対戦が行われる）。１つの実施形態において、各ＭＳＩは、異なるマシンパーティションを識別するパーティションＩＤを含むようにディスパッチャーにより動的に変更／選択される。例えば、特定のＭＳＩが過負荷になった場合に、ディスパッチャーは、ＭＳＩを２つ以上の異なるサーバー及び／又は記憶パーティション間で分割する（例えば、４：３：１及び４：３：２のような呼称を使用し、最後の桁は、パーティション１及び２を各々識別する）。次いで、異なるマッチメーカーが、各異なるサーバーからの各異なるＭＳＩから要求を独立して検索して処理する。

【0117】

又、図１５に示したように、対戦要求データは、要求ごとに要求テーブル１５０２内に記憶される。要求データは、対戦を組む判断をするのに有用なデータ、及び／又はネットワークを経て要求を開始する移動装置にアクセスするのに必要なデータを含む。例えば、１つの実施形態において、各要求の対戦要求データは、要求を開始する移動装置のためのＮＡＴ形式データ及び／又はＮＡＴ横断／接続データを含む。又、装置接続速度（１００ｋｂｐｓ、１Ｍｂｐｓ、等）、接続形式（例えば、３Ｇ、ＥＤＧＥ、Ｗｉ−Ｆｉ、等）、装置位置（例えば、地理的位置技術により決定された）、言語（英語、スペイン語、等）及び／又はユーザの好みのような他の形式の要求データも要求テーブル１５０２内に記憶される。要求データは、各移動装置１２０−１２２によって決定され、そして各対戦要求と共にマッチメーカーディスパッチャー１５０１へ送信される。例えば、各移動装置は、ここに幾つか述べる種々の技術を使用して、その接続データ、接続形式、装置位置、等を決定する（例えば、ＮＡＴ横断サーバーと通信してＮＡＴ横断／接続データを決定し、ＧＰＳを使用して装置位置を決定し、ＨＴＴＰ情報を読み取って言語を決定し、等）。

【0118】

図１５に示すように、１つの実施形態において、各アクティブなＭＳＩには、ＭＳＩテーブル１５０３の行が指定される。１つの実施形態では、新たな要求が到着するときに、要求テーブル１５０２に要求を追加するのに加えて、ディスパッチャー１５０１は、ＭＳＩテーブル１５０３をチェックして、その要求に対してＭＳＩが既に存在するかどうか（即ち、同じＭＳＩを有する他の要求が既に受け取られたかどうか）も決定する。一致するＭＳＩが見つからない場合には、ディスパッチャー１５０１は、新たな要求に対してＭＳＩテーブル１５０３に新たなエントリを生成する。一致するＭＳＩが見つかる場合には、ディスパッチャーは、上述したように、要求テーブル１５０２に新たな要求を単に追加する。

【0119】

要求テーブル１５０２及びＭＳＩテーブル１５０３がマッチメーカーディスパッチャー１５０１により更新されると、マッチメーカーモジュール１５１０のインスタンス（以下、単に、「マッチメーカー１５１０」と称する）が、データをフェッチして、対戦を組む動作を遂行する。多数のマッチメーカーインスタンスを同時に実行して、対戦を組む要求を遂行し、そして単一のマッチメーカー１５１０は、多数の異なるＭＳＩグループにおいて多数の対戦組み動作を同時に処理する。

【0120】

一実施形態において、マッチメーカー１５１０は、それが利用可能になると（例えば、ＭＳＩグループに対して対戦を組む動作を完了した後又は初期化の後）、ＭＳＩテーブル１５０３に問合せをして、処理すべき新たなＭＳＩを識別する。図１５において、ＭＳＩ３：１に対するマッチメーカーＩＤフィールドの“Ｎ／Ａ”値は、このＭＳＩを処理するための責任がマッチメーカーにまだ指定されていないことを指示する。１つの実施形態では、各ＭＳＩエントリがタイムスタンプされ、そしてマッチメーカー１５１０は、最も古いタイムスタンプを有するＭＳＩを選択する。

【0121】

一実施形態において、マッチメーカー１５１０は、それが特定のＭＳＩに対する責任を負うときに、ＭＳＩテーブル１５０３におけるそのマッチメーカーＩＤコードを更新し、そしてそのＭＳＩのリース期間（例えば、５秒）を指定する。一実施形態において、マッチメーカー１５１０は、そのＭＳＩに対して対戦を処理するときにリース値を更新し続ける。リース値は、失敗となったマッチメーカー１５１０に指定されたＭＳＩを識別するのに使用される。例えば、リース値が満了となった場合には、ＭＳＩがマッチメーカーに既に指定されたことをＭＳＩテーブル１５０３が指示するにも関わらず、そのＭＳＩが新たなマッチメーカーにより請求される。

【0122】

マッチメーカー１５１０は、それがＭＳＩに対する責任を負うと、要求テーブル１５０２に問合せをして、そのＭＳＩに関連した要求をメモリへと読み込むことができる。次いで、マッチメーカー１５１０は、対戦を組む基準のセットに従ってユーザ及び移動装置を対戦させるために対戦を組む動作を遂行する（例えば、以下に述べるように）。マッチメーカー１５１０は、移動装置の対戦が行われたときを指示するために要求テーブル１５１２を更新する。例えば、マッチメーカーは、要求テーブル１５１２のＭＳＩ列からＭＳＩ値を除去し、そして対戦が完了したことを指示するための既定値を入力する。それに加えて、マッチメーカー１５１０は、参加者が対戦した他の参加者を識別するために各参加者の「要求データ」フィールドを更新する（例えば、他の参加者と通信するのに必要なＮＡＴ横断／接続データを書き込むことにより）。

【0123】

ディスパッチャー１５０１は、完了した対戦を識別するために要求テーブル１５０２に周期的に問合せする。完了した対戦を検出するのに応答して、ディスパッチャー１５０１は、対戦に関与する移動装置にプッシュ通知を送信する（例えば、本出願及び同時係争中の出願に述べられたプッシュ通知技術を使用して）。１つの実施形態では、プッシュ通知は、上述した「チケット」データ構造を含む。次いで、移動装置は、それらの各チケットを使用して、上述したＣＤＸサービス１１０を経て接続データを交換する。

【0124】

プッシュ通知の使用に加えて、一実施形態では、移動装置１２０−１２２は、ディスパッチャー１５０１に周期的に問合せして、対戦がなされたかどうか決定する。移動装置にプッシュ通知がなされない場合には、周期的な問合せが有用である。しかしながら、プッシュアーキテクチャーが使用されるために、周期的な問合せは、比較的低いレートにセットされ、マッチメーカーサービス１１１に対する負荷を減少させる。

【0125】

図１６は、２つの移動装置Ａ及びＢがマッチメーカーサービス１１１により対戦させられる方法の規範的な実施形態を示す。図１７ａ−ｄは、その方法が進行するにつれて行われる要求テーブル１５０２及びＭＳＩテーブル１５０３への規範的な更新を示す。

【0126】

１６０１において、移動装置Ａから対戦要求が受け取られる。１６０２において、図１７ａに示すように、移動装置Ａの要求が要求テーブルに入力され、新たなＭＳＩエントリ（ＭＳＩ １：１）がＭＳＩテーブルに入力される（それがまだ存在しない場合）。１６０３において、対戦要求が移動装置Ｂから受け取られ、１６０４において、移動装置Ｂの対戦要求も、図１７ｂに示すように、要求テーブルに入力される。

【0127】

１６０５において、特定のマッチメーカーインスタンス（マッチメーカー＃Ｎ）は、ＭＳＩテーブルをチェックし、そして別のマッチメーカーインスタンスによってＭＳＩ １：１が請求されていないことを検出する。或いは又、マッチメーカーは、ＭＳＩに対してそれまで作用していたマッチメーカーが失敗となったことを指示するリース満了のＭＳＩテーブルエントリを検出する。１つの実施形態では、リース満了のＭＳＩエントリには、（マッチメーカーがまだ指定されていない）新たなＭＳＩエントリより高いプライオリティが与えられる。更に、一実施形態では、比較的古いＭＳＩエントリに、比較的新しいＭＳＩエントリより高いプライオリティが与えられる。マッチメーカーは、それがＭＳＩをどのように選択するかに関わらず。そのようにしたときは、図１７ｃに示すように、その識別子を追加し、そしてＭＳＩエントリに対して新たなリース値をセットする（例えば、図示された例では、５秒のリース値を使用して）。次いで、マッチメーカーは、要求テーブルに問合せし、そして要求テーブルエントリをそのＭＳＩと共にメモリへ読み込み、それらを処理できるようにする。

【0128】

１６０６において、マッチメーカーは、一連の対戦組み動作を遂行して、各要求に対して適当な対戦を選択する。対戦を組む動作の幾つかの実施形態は、図１８を参照して以下に説明する。簡単に述べると、一実施形態では、「適切」な対戦を決定するために評価される変数は、ＮＡＴ形式（例えば、全コーン、ポート制限、対称性、等）、接続形式（例えば、ＷｉＦｉ、３Ｇ、ＥＤＧＥ、等）、ユーザに関連した言語（ＨＴＴＰ要求受け容れ言語ヘッダから導出された）、及び各対戦要求の年齢を含む。一般的に、マッチメーカー１５１０は、適合するＮＡＴ形式（リレーサービスは、時々、以下に述べるように使用されるが）、同じ接続形式、及び同じ言語を有する移動装置を対戦させるように試みる。一実施形態において、マッチメーカー１５１０は、対戦要件が対戦要求の年齢に基づくように、より自由である（即ち、要求が古いほど、より自由に対戦制限を適用する）。

【0129】

図１６に戻ると、１６０７において、対戦を組む判断に続いて、マッチメーカー１５１０は、図１７ｄに示すように、対戦組みが完了したことを指示するために要求テーブルを更新する。その更新の一部分として、マッチメーカーは、移動装置Ａ及びＢの要求データも更新する。例えば、一実施形態では、マッチメーカー１５１０は、移動装置ＢのＮＡＴ横断／接続データを移動装置Ａの要求データ列に書き込み、そして移動装置ＡのＮＡＴ横断／接続データを移動装置Ｂの要求列に書き込む。

【0130】

１６０８において、ディスパッチャー１５０１は、要求テーブルを読み取って、対戦が組まれた要求エントリを識別する。一実施形態において、移動装置Ａ及びＢの対戦が組まれたことを検出すると、要求データ（上述したようにマッチメーカーにより更新された）を読み取り、そして移動装置Ａ及びＢのための通知を発生する。一実施形態では、通知は、暗号化された前記「チケット」データ構造であり、各移動装置のＮＡＴ横断／接続データを含む。先に述べたように、一実施形態では、プッシュ通知サービス１０５０を使用して、移動装置Ａ及びＢへ通知がプッシュされる。更に、移動装置Ａ及びＢは、ディスパッチャー１５０１を周期的にポーリングして、対戦が組まれたかどうか決定する。この実施形態では、ポーリング技術は、何らかの理由で、移動装置の一方に首尾良くプッシュされなかった対戦を識別するために、比較的ゆっくりとした速度で行われる。プッシュ通知を使用してポーリング要求負荷を管理することで、移動装置からのポーリング要求で負荷のかかるマッチメーカーサービスの負荷が著しく減少される。

【0131】

同じＭＳＩに対して付加的な対戦要求が保留となっていることが１６０８で決定されると、マッチメーカーは、ＭＳＩ内で移動装置／ユーザの対戦組みを続ける。１６１０において、マッチメーカーは、ＭＳＩテーブル１５０３内のリース値をリセットする。１６１１において、付加的な対戦が組まれて、要求テーブルが更新される（上述したように）。１６１２において、付加的な対戦が要求テーブルから読み取られ、付加的な移動装置が更新される（上述したように）。ＭＳＩに対して付加的な対戦要求が保留になっていない場合には、１６０９において、ＭＳＩエントリがＭＳＩテーブルから除去される（例えば、ディスパッチャー及び／又はマッチメーカーのいずれかからの削除コマンドを経て）。

【0132】

図１８は、移動装置／ユーザ間の対戦を組む方法（図１６の動作１６０６）の一実施形態を示す。１８０１において、全ての現在ＭＳＩ要求（例えば、特定のアプリケーション／バケット組み合わせのための）が対に配列される。１８０２において、各対の間の対戦「フィット性(fit)」が評価され、そして１８０３において、それらの対が減少フィット性により分類される。「フィット性」は、複数の異なる変数に基づいて評価され、それら変数は、ＮＡＴ形式（例えば、全コーン、ポート制限、対称性、等）、接続形式（例えば、ＷｉＦｉ、３Ｇ、ＥＤＧＥ、等）、ユーザに関連した言語（ＨＴＴＰ要求受け容れ言語ヘッダから導出された）、及び各対戦要求の年齢を含むが、これに限定されない。対戦組み判断の因子となる他の変数は、各移動装置の位置（例えば、特定位置のユーザの対戦を試みる場合）、最小及び／又は最大プレーヤ要件（例えば、ユーザ及び／又はアプリケーションにより指定される）、ＭＳＩに含まれる１人以上のユーザが「友人」であるか、又はＰ２Ｐ接続に以前に入ったことがあるか（例えば、「友人」又は以前の知合いとの対戦を好む場合）、及びアプリケーションでのユーザの経験（例えば、マルチプレーヤゲームに対し、同様の経験をもつユーザとの対戦を好む場合には、各ユーザのスコアボードランクが因子とされる）を含む。

【0133】

以下のテーブルＡに示すように、一実施形態では、「フィット性」の評価は、０．０と１．０との間の数値である。浮動小数点の値を使用することで、各基準に対してフィット性を正規化することができる。浮動小数点演算を回避するために、非正規化の整数値を適当な評価と共に使用し、従って、フィット値を比較することができる。

【0134】

１つの実施形態において、全ての基準は、それらが適合する(compatible)（正規化値が１．０）か、又は適合しない（正規化値が１．０未満）というバイナリフィット性を有する。それらは、（以下に述べるように）フィット性が年齢と共に変化する必要な基準と考えられる。位置が変数として追加される場合に、最良のフィット性は、最も近いプレーヤが必要な基準に合致するというものである。
対戦フィット性 − テーブルＡ

【0135】

一実施形態において、フィット性は、前記基準の各々に対し（正規化された重み＊年齢因子値）の和に等しい。年齢因子値は、値１でスタートし、そして所定の期間が経過した後に増加する。これは、次いで、時間の経過と共に増加し続ける（例えば、周期的に特定量増加する）。一実施形態では、上述した年齢因子値を使用するのではなく、年齢スレッシュホールドが、以下に述べるように確立される。接続形式及び言語のようなある変数の正規化／重み付け値は、ある年齢スレッシュホールドの上で適用される（たとえそれらが一致しなくても）。

【0136】

一実施形態において、一対の要求ＡとＢとの間の「フィット性」は、ＡとＢ及びＢとＡとのフィット性の平均である。更に、各因子に対するＡとＢのフィット性は、Ａの年齢に基づいて調整される（その逆のことも言える）。一実施形態において、適合する対戦のためには１．０のフィット性が要求される。これは、ＮＡＴ適合性、接続形式及び言語が一致する（正規化値１．０を生じる）場合、又は（スレッシュホールドより上又は下のいずれかの年齢因子値を使用して）前記変数の幾つか（例えば、接続形式及び言語）を実際上無視できるほどＡ及び／又はＢが加齢した場合にのみＡとＢが対戦することを意味する。
年齢 − テーブルB

【0137】

年齢スレッシュホールドは、前記テーブルＢに示すように確立される。各年齢スレッシュホールドを経過すると（即ち、要求が指定スレッシュホールドより古くなると）、年齢因子値が、次第に大きな値（例えば、１．５、２．０、等）へと増加する。それとは別に又はそれに加えて、異なる年齢スレッシュホールドを経過するにつれて、ある変数に対する重み値が対戦組み判断に追加される（例えば、以下に述べる接続形式及び言語）。

【0138】

一実施形態において、テーブルＢに示された要求年齢限界が所与のＭＳＩに対する対戦フローレートに基づいて調整される。一実施形態において、フローレートは、指定の単位時間（例えば、１０秒毎、毎分、等）当たりに行われる対戦組みの数として指定される。従って、フローレートは、特定のＭＳＩセットがどのようにビジーであるかの指示を与える。一実施形態では、そのセットがビジーであるほど、早期に成功する対戦の確率を高め且つマッチメーカーの負荷を減少するために前記スレッシュホールドの各々が前記テーブルＢにセットされることが少なくなる。更に、所与のＭＳＩセットについての負荷がエンドユーザに与えられ（例えば、対戦値までの推定時間の形態で）、従って、エンドユーザは、特にビジーなマルチプレーヤゲームに入るよう試みるべきかどうか選択することができる。負荷値は、プッシュ通知の形態でユーザに与えられる。

【0139】

テーブルＡからの各変数を参照すれば、一実施形態において、ＮＡＴ適合性は、図１４に示すＮＡＴ適合性チャート１４００から決定される。このチャートに基づき２つのＮＡＴが適合であると決定される場合には、ＮＡＴ適合性重みが適用される。
接続形式 − テーブルC

【0140】

接続形式は、テーブルＣとして上に示されたもののようなチャートを使用して評価される。この例では、装置Ａ及びＢの接続形式が同じである場合（同じ接続形式に出会うセルにおいて１．０で示される）、テーブルＡからの重み付けされた接続形式値がフィット性の決定に含まれる。上述したように、各要求の年齢は、接続形式の決定に作用するように使用される。例えば、一実施形態では、接続形式に対するフィット値は、スレッシュホールド１、２及び３の年齢についてテーブルＣのマトリクスを使用して選択される。スレッシュホールド４以上の年齢については、接続形式が１．０にセットされ（非対戦の接続形式についても）、そしてそれに対応する重み付けされた接続形式値が適用される。幾つかの実施形態では、接続「形式」が使用されるが、接続形式と共に、又はそれに代わって、接続速度が決定されて使用されてもよい。例えば、ある指定範囲内の接続速度は、「適合」と考えられる（例えば、０−１００ｋｂｐｓ、１００−５００ｋｂｐｓ、５００−１０００ｋｂｐｓ、１０００−１５００ｋｂｐｓ、等）。ここに述べる対戦組み変数は、いずれも、対戦フィット性の計算に対する重みとして適用され、上述したように加齢される。

【0141】

一実施形態において、プレーヤの言語は、好み因子を伴う１つ以上の言語を含むＨＴＴＰ要求受け容れ言語ヘッダから導出される。ディスパッチャーは、最も好ましい言語を抽出し、そしてその情報をマッチメーカーへ送る。一実施形態では、テーブルＡからの重み付けされた言語値は、言語が同じである場合は１．０にセットされ、又は同じでない場合には０．０にセットされる。しかしながら、一実施形態では、重み付けされた言語値は、年齢が指定のスレッシュホールドより高い場合には（例えば、年齢がテーブルＢにおいてスレッシュホールド２以上である場合には）、たとえ言語が異なるものであっても適用される。

【0142】

一実施形態において、不適合なＮＡＴ形式をもつ２人のユーザ間で対戦を組むこともできる。例えば、マッチメーカーは、特定のＭＳＩに対してユーザの対戦を組むのが困難な場合に、指定の期間の後に、上述した技術を使用してリレーサービス１０５１を通る接続をルーティングする。このように、リレーサービス１０５１は、圧力弁として働き、不適合なＮＡＴ形式であるにも関わらず、加齢して対戦を組めるようにする。又、リレーサービス１０５１は、１つ以上の失敗した対戦組みの試みを検出するのに応答して使用することもできる。この実施形態では、移動装置によって提出される各対戦要求は、１つ以上の不首尾な対戦組みが以前に試みられたかどうかの指示を含む。

【0143】

種々の付加的な対戦基準が評価され、そして対戦フィット性決定の一部分として重み値が与えられ、これは、例えば、対戦を要求しているユーザのいずれかが友人であるかどうかの指示を含むが、これに限定されない。例えば、マッチメーカー１５１０は、対戦フィット性の計算に「友人」重みを適用することにより、友人であるユーザの要求を対戦組みするよう試みる。同様に、友人の友人も重み付けされる（例えば、２つ以上の分離度で）。更に、プレーヤは、特定のゲームに対して他のプレーヤを格付けし、そしてマッチメーカーは、対戦を組むときにそれらの格付けを評価する（ユーザを、比較的高い格付けのプレーヤと対戦させ、低い格付けのプレーヤとは対戦させない傾向で）。更に、ユーザの接続の待ち時間も評価され（例えば、簡単なピン(ping)動作を使用して）、そして対戦を組む判断の一部分として使用される。

【0144】

プレーヤを対戦させるのに使用される更に別の変数は、装置の形式である。例えば、マッチメーカー１５１０は、同様の装置形式（例えば、ｉＰａｄ（Ｒ）、ｉＰｏｄ（Ｒ）、ｉＴｏｕｃｈ（Ｒ）、ｉＰｈｏｎｅ（Ｒ）、ＲＩＭ Ｂｌａｃｋｂｅｒｒｙ（Ｒ）、等）をもつプレーヤを対戦させるよう試みる。付加的な変数は、ユーザのスコアボードランキング、現在位置、現住地、年齢、性別を含み、そして対戦決定のために同様のゲームコレクションが同様に評価される（即ち、同様の基準でのユーザ間の対戦を奨励する傾向のある多くのケースにおいて）。最終的に、ユーザが適切なＭＳＩで且つ同じ年齢の他のユーザのみと対戦されることを保証するためにマッチメーカー１５１０によりペアレンタルコントロールが評価される。

【0145】

マッチメーカーサービス１１１は、データサービス１００内で管理される１つ以上のデータベースから前記変数のいずれかを検索する（例えば、図１９を参照して以下に述べるデータベース１９２０を参照）。例えば、ユーザの友人のデータは、友人サービスデータベースからアクセスされ、そして各ユーザの年齢、性別、ゲームコレクション、等の他の情報は、１つ以上の他のデータベース（例えば、ユーザプロフィール、ゲームデータベース、スコアボードデータベース、等）からアクセスされる。一実施形態では、ここに述べる全てのサービスに、対戦を組む判断を行うのに使用される全ての種々の異なる形式のユーザ／装置データを記憶するための同じ中央データベース（又はデータベースのグループ）へのアクセス権が与えられる。

【0146】

多数の特定例を上述したが、本発明の基礎的な原理は、対戦のフィット性レベルを決定する特定の１組の変数に限定されないことが明らかである。一実施形態において、ここに述べるシステム及び方法に対して実行されるアプリケーションを設計するアプリケーションプログラマは、異なるＭＳＩ基準を使用して要求をマッチングさせ及び／又はグループ分けさせるそれ自身の１組の基準を指定することができる。

【0147】

図１８の方法に戻ると、各対間の対戦「フィット性」が決定されると、１８０３において、減少するフィット性によって対が分類される（例えば、最も高いフィット性を有する対がリストのトップとなる）。１８０４において、「対戦セット」に、指定のスレッシュホールドより上の最高フィット値を有する対がシードされる。上述したように、「スレッシュホールド」値は、前記テーブルＡに示された１．０の正規化値にセットされる。１８０５において、対戦セット内の現在メンバーの１人又は全員が指定スレッシュホールドより上となるようなフィット値を有する新たな有望なパートナーが対戦セットに追加される。例えば、対戦セットに最初にＡ及びＢがシードされた場合に、Ａ−Ｃ及び／又はＢ−Ｃのフィット値が指定スレッシュホールドより上になるならば、Ｃが対戦セットに追加される。一実施形態では、単一の対戦フィットだけが有望な当事者のスレッシュホールドより上である場合に、その当事者が対戦セットに追加される（即ち、必要に応じて、その当事者が、適当な対戦フィット性をもつところの１人の当事者を通して全ての当事者と通信できるので）。１人以上の新たな当事者が対戦セットに追加されると、対戦のサイズ要件が満足されたことが１８０６において決定された場合に、（例えば、上述したように、要求テーブル１５０２を更新しそして通知を送信することにより）１８０７において対戦組み結果が記憶され報告される。一実施形態では、単一の対戦要求が複数のユーザを表わしてもよい（例えば、以下に述べるように、対戦要求の後にインビテーションシーケンスが続くとき）。このケースでは、サイズ要件は、各対戦要求により表されるユーザの人数に基づいて評価される。サイズ要件が満足されない場合には、プロセスが１８０５へ戻り、新たな当事者が対戦セットに追加される（即ち、セットの現在メンバーの１人以上が指定のスレッシュホールドより上となるような対戦フィット性を有する当事者）。

【0148】

１８０８において、対戦が組まれた要求が、マッチメーカー１５１０により処理されている要求の現在セットから除去される。１８０９において、次にシードされる対戦セットが選択され、プロセスは、付加的な対戦を組むために１８０４へ戻る。図１８には、順次のプロセスとして示されているが、シードされた複数の対戦セットは、本発明の基礎的な原理に適合しつつ、同時に処理されてもよいことに注意されたい。

【0149】

個別のサービスとして上述したが、マッチメーカーサービス１１１及びインビテーションサービス１１２は、Ｐ２Ｐユーザを接続するように一緒に動作することができる。例えば、一実施形態では、第１のユーザが１人以上の友人をオンラインセッションに招待し、そして１人以上の付加的なユーザとの対戦を要求する（例えば、友人「ボブ」を招待し、そしてマルチレイヤビデオゲームに対して３人の付加的なプレーヤと対戦させる）。そのようなケースでは、インビテーションサービス１１２は、第１ユーザと第１ユーザの友人とを接続するために第１ユーザのインビテーション要求を最初に処理する。次いで、インビテーション要求の結果（例えば、Ｐ２Ｐ接続成功）がユーザの移動装置へ報告されて戻される。マッチメーカーサービス１１１は、次いで、付加的なプレーヤを要求する対戦要求を第１ユーザの移動装置から（又は一実施形態ではインビテーションサービスから直接又は第１ユーザの友人から）受け取る。それに応答して、マッチメーカーサービス１１１は、第１ユーザと、第１ユーザの要求と同じＭＳＩを有する１つ以上の他の対戦要求との対戦を組む（上述したように）。対戦要求は、第１ユーザの対戦基準のみを含むか、又は第１ユーザ及び第１ユーザの友人の対戦基準（例えば、ＢＡＴ形式、接続形式、言語、位置、等）を含む。一実施形態において、第１ユーザの友人の１人以上が、別の対戦ユーザとの直接的なＰ２Ｐ接続を確立できない場合には、第１ユーザの友人と対戦ユーザとの接続が、第１ユーザのデータ処理装置を通して確立され（例えば、第１ユーザの移動装置を接続のためのプロキシーとして使用して）、及び／又はリレーサービスを使用して、ユーザを接続する（上述したように）。

【0150】

一実施形態において、第１ユーザは、マッチメーカーサービスにより１人以上のユーザと最初に対戦が組まれ（上述したように）、次いで、第１ユーザは、第１ユーザ及び対戦ユーザとのオンラインセッションに加わるように１人以上の友人を招待する。この実施形態では、ユーザの情報及び対戦ユーザの情報の両方（例えば、ＮＡＴ／接続データ、ユーザＩＤ、プッシュトークン、等）が、インビテーションサービスを通して招待ユーザとで交換される（上述したように）。本発明の基礎的な原理は、最初に対戦が組まれた後に招待されるか、又は最初に招待された後に対戦が組まれるかに関わりなく、同じである。

【0151】

協力的オンラインアプリケーションのためのアプリケーションプログラミングインターフェイスを伴うアプリケーションフレームワーク
図１９に示すように、本発明の一実施形態は、既定のソフトウェアフレームワーク１９１２を、１つ以上のアプリケーション１９１１とインターフェイスするためのアプリケーションプログラミングインターフェイス（ＡＰＩ）１９１０、及び複数のネットワークサービス１９０１−１９０３と通信するためのサービス側ＡＰＩ１９１３と共に有する移動装置１２０の環境内で具現化される。図１９に示すように、ネットワークサービス１９０１−１９０３は、同じオンラインデータサービス１００により設計及び／又は管理される（が、そのような構成は要求されない）。Ｐ２Ｐゲームアプリケーション及び他の形式の協力的オンラインアプリケーションのようなアプリケーション１９１１は、ＡＰＩ１９１０へコールを発することによりＡＰＩ１９１０を通してネットワークサービス１９０１−１９０３にアクセスするように設計される。アプリケーション１９１１の設計は、フレームワーク１９１２及びネットワークサービス１９０１−１９０３の開発者により与えられるソフトウェア開発キッド（ＳＤＫ）を使用して促進される。フレームワーク１９１２及びＡＰＩ１９１０、１９１３のより特定の具現化は、図２０を参照して以下に述べる。

【0152】

図示されたように、各サービスには、サービスにより使用されるデータを記憶するためのデータベース１９２０へのアクセス権が与えられる。１つの特定例は、マッチメーカーサービス１１１により使用されるデータベース１５１２である（上述したように）。他の例は、スコアボードデータを記憶するためのスコアボードデータベースと、友人状態レコードを記憶するための友人サービスデータベースと、ユーザプロフィールデータを記憶するためのプロフィールデータベースと、オンラインゲームに関連したデータを記憶するためのゲームデータベースとを含む。任意の形式のデータベース（例えば、ＭｙＳＱＬ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ、等）が使用されるが、１つの特定の実施形態では、Ｂｅｒｋｌｅｙ ＤＢ及び／又はＭＺＢａｓｉｃ ＤＢのようなキー／値データベースを使用することができる。データベースは、記憶エリアネットワーク（ＳＡＮ）又は他の記憶構成において多数の大量記憶装置（例えば、ハードドライブ）にわたって分散される。

【0153】

その結果、特定のサービスが、上述したように、データを処理し及び／又は記憶するときには、データがデータベース１９２０内に記憶される。しかしながら、あるサービスでは、データベースが使用されない。例えば、上述したように、インビテーションサービス１１２は、ステートレスサービスとして実施され、それ故、データベース１９２０内にデータを記憶することが要求されない（が、そのような実施は、本発明の基礎的な原理でも可能である）。

【0154】

ＡＰＩ１９１３は、例えば、ネットワークレイヤではＴＣＰ／ＩＰ又はＵＤＰ／ＩＰをそしてアプリケーションレイヤではＨＴＴＰＳを含む適当なネットワークプロトコルスタックを使用してネットワークサービス１９０１−１９０３と通信しそしてそれらと情報を交換するように設計される。ＳＯＡＰのようなＨＴＴＰ又はＨＴＴＰＳを経てのリモート手順コール（ＲＰＣ）ベースのプロトコルが使用され、及び／又は代表的状態転送（ＲＥＳＴ）プロトコルが使用される。更に、サービスは、例えば、Ｕｎｉｘ、Ｌｉｎｕｘ又はＡｐａｃｈｅソフトウェプラットホームを実行するＸｓｅｒｖｅｒ又は同様のサーバーを含むコンピューティングプラットホームにおいて実施される。１つの特定の実施形態では、プラットホームは、Ｌｉｎｕｘにおいて具現化されるウェブオブジェクトを含む。以上の例は、説明上与えられたものに過ぎない。本発明の基礎的な原理は、アプリケーションをサービス又は特定セットのネットワークプロトコルにリンクするための特定のメカニズムに限定されない。

【0155】

図２０は、本発明の一実施形態においてワイヤレス装置１２０で実施されるアプリケーションプログラミングインターフェイス（ＡＰＩ）２００１ａ−ｂを含むより詳細なソフトウェアアーキテクチャーを示す。この実施形態は、マルチプレーヤゲームフレームワーク２０００の環境内で説明するが、本発明の基礎的な原理は、ゲームの実施に限定されない。例えば、図２０に示すソフトウェアアーキテクチャーは、ゲーム以外の種々の協力的アプリケーション（例えば、協力的チャット、多当事者協力的オーディオ／ビデオ、等）をサポートするのに使用される。

【0156】

図２０に示すアーキテクチャーにおいて、ゲームフレームワーク２０００は、ここに述べる種々の多当事者特徴及びＰ２Ｐ特徴をサポートするために設けられる。一実施形態において、ゲームフレームワーク２０００は、移動装置のオペレーティングシステム２００５上で実行されるように構成される。例えば、移動装置１２０がｉＰｈｏｎｅ（Ｒ）、ｉＰａｄ（Ｒ）又はｉＰｏｄ Ｔｏｕｃｈ（Ｒ）である場合に、オペレーティングシステム２００５は、本出願の譲受人によって設計された移動オペレーティングシステムであるｉＰｈｏｎｅ（Ｒ） ＯＳである。

【0157】

ゲームフレームワーク２０００は、パブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）２００１ｂ及びプライベート又は「セキュア」なＡＰＩ２００１ａを含む。一実施形態において、ここに述べる種々のゲーム関連特徴を与えるように設計されたゲームセンターアプリケーション２０３１は、パブリックＡＰＩ２００１ｂ及びプライベートＡＰＩ２００１ａの両方にコールを発信し、一方、他のアプリケーション２０３０（例えば、第三者により設計されたアプリケーション）には、パブリックＡＰＩ２００１ｂのみへのアクセス権が与えられる。例えば、移動装置１２０の設計者は、第三者の開発者による悪用を回避するためにパブリックＡＰＩ２００１ｂからの潜在的に微妙な情報（例えば、友人の要求、友人リスト、等）を伴う幾つかのＡＰＩ機能を保持することを希望する。しかしながら、セキュアなＡＰＩ２００１ａ及びパブリックＡＰＩ２００１ｂは、両方とも、移動装置の全てのアプリケーションによりアクセス可能な単一のＡＰＩへと合流される（即ち、本発明の基礎的な原理に適合するために個別のパブリック及びプライベートコンポーネントへのＡＰＩの分離は、要求されない）。「ＡＰＩ２００１」の呼称は、パブリックＡＰＩ２００１ｂ及び／又はプライベートＡＰＩ２００１ａのいずれかに見られる動作を指すために以下で時々使用される。

【0158】

ゲームセンターアプリケーション２０３１の一実施形態は、本出願の譲受人に譲渡されそして参考としてここに援用される２０１０年４月７日に出願されたＭａｒｃｅｌ Ｖａｎ Ｏｓ及びＭｉｋｅ Ｌａｍｐｅｌｌを発明者とする“Systems and Methods for Providing a Game Center”と題する同時係争中の出願（代理人管理番号第４８６０．Ｐ９１２７ＵＳＰ１号）（以下、「ゲームセンター特許出願」）に説明されている。簡単に述べると、ゲームセンターアプリケーション２０３１は、マルチプレーヤゲームを通してナビゲートし、新たなゲームを購入し、ゲームに関連した情報（例えば、スコアボード情報、実績、友人情報、等）を検索し、ゲームをプレイするために友人に連絡し、他のユーザとのゲーム対戦を要求し、及び特定のユーザを招待するためにゲームセンターグラフィックユーザインターフェイス（ＧＵＩ）を含む。ゲームセンターアプリケーション２０３１により行われる種々の他の機能は、前記ゲームセンター特許出願に説明されている。幾つかのゲームセンター機能は、ゲームフレームワーク２０００により与えられ、そしてパブリックＡＰＩ２００１ｂを通して他のアプリケーション２０３０へアクセスできるようにされる。

【0159】

一実施形態において、ゲームフレームワーク２０００により露出されるＡＰＩ２００１は、移動装置１２０のためのマルチプレーヤの協力的ゲームを設計するプロセスを簡単化する。特に、一実施形態では、ＡＰＩ２００１は、マルチプレーヤのＰ２Ｐゲームセッションに対してユーザを接続する比較的複雑なプロセスを呼び出すために開発者が簡単なＡＰＩコールを発信できるようにする。例えば、上述した詳細なインビテーションシーケンスを開始するために、ＩＮＶＩＴＥ（プレーヤＢ ＩＤ、バケットＩＤ）のような簡単なＡＰＩコールがＡＰＩ２００１呼び出される。同様に、上述した詳細なマッチメークシーケンスを開始するためにＭＡＴＣＨ（プレーヤＡ ＩＤ、バケットＩＤ）がＡＰＩ２００１から呼び出される。ＩＮＶＩＴＥ及びＭＡＴＣＨ機能は、一般的に、「Ｐ２Ｐ接続機能」とも称される。一実施形態において、ゲームフレームワーク２０００は、これらのＡＰＩコールに応答してインビテーション及びマッチメーク動作を管理するのに必要なプログラムコードを含む。実際のＡＰＩ機能は、上述したものとはある程度異なるデータフォーマットを有する（が、ゲームフレームワーク２０００により遂行される同様の動作を生じる）。本発明の基礎的な原理は、ＡＰＩ機能を指定するための特定のフォーマットに限定されない。

【0160】

種々の他の形式のゲーム関連トランザクション及び情報も、ゲームセンター２０３１及び他のアプリケーション２０３０に代わって、ゲームフレームワーク２０００により管理される。この情報の幾つかは、前記ゲームセンター特許出願に説明されている。例えば、これに限定されないが、この情報は、各ゲームの最高スコアを得たユーザに関連した「スコアボード」情報と、幾つかのゲーム特有の実績を完成したユーザを識別する「実績」情報とを含む。各アプリケーション開発者は、各ゲームアプリケーション２０３０に対してそれ自身の１組の「実績」を指定する（例えば、完成レベル１−３；完成レベル１は５分以内；レベル当たり５０キル以上；ノックダウン２０フラグ；等）。

【0161】

又、ゲームフレームワーク２０００は、ユーザの友人データを管理しそしてゲームセンター２０３１及び他のゲームアプリケーション２０３０の環境内で友人データを統合するためのプログラムコードも含む。例えば、ユーザがゲームセンター２０３１内の特定のゲームへのリンクを選択するとき、ユーザの各友人に関連した情報がそのゲームに対して表示される（例えば、スコアボード上の友人のランキング、友人の実績、ユーザが自分の各友人とゲームをプレイしたときの結果、等）。一実施形態において、ゲームフレームワーク２０００のＡＰＩ２００１は、友人サービスにより管理される友人データにアクセスするための機能を含み、これは、例えば、本出願の譲受人に譲渡されそして参考としてここに援用される２０１０年４月７日に出願されたＡｍｏｌ Ｐａｔｔｅｋａｒ、Ｊｅｒｅｍｙ Ｗｅｒｎｅｒ、Ｐａｔｒｉｃ Ｇａｔｅ及びＡｎｄｒｅｗ Ｈ．Ｖｙｒｒｏｓを発明者とする“Apparatus and Methods for Efficiently Managing Data in a Social Networking Service”と題する同時係争中の出願（代理人管理番号第４８６０．Ｐ９４２０号）（以下、「友人サービス特許出願」）に説明されている。

【0162】

図２０に示すように、一実施形態において、ゲームデーモン２０２０は、ゲームフレームワーク２０００を第１セットのサービス２０５０へインターフェイスし、そしてゲームサービスコンポーネント２０１０は、ゲームフレームワーク２０００を第２セットのサービス２０５１へインターフェイスする。例えば、第１セットのサービス２０５０は、上述したインビテーションサービス１１２、マッチメーカーサービス１１１、及びリレーサービス１０５１と、前記友人サービス特許出願に説明された友人サービスとを含む。ゲームデーモン２０２０を経てアクセスされる他のサービスは、スコアボードサービス（スコアボードデータを与える）、ゲームサービス（各ゲームに関連した統計値及び他のデータ並びにゲームを購入する能力を与える）、ユーザ認証サービス（移動装置のユーザを認証するための）、及び／又はユーザプロフィールサービス（ユーザの好みのようなユーザプロフィールデータを記憶するための）を含む。ゲームサービスコンポーネント２０１０を経てアクセスされる第２セットのサービス２０５１は、上述した接続データ交換（ＣＤＸ）サービス１１０、及びＮＡＴ横断サービス２９０−２９１を含む。説明上、図２０には個別のコンポーネントとして示されているが、ゲームデーモン２０２０及びゲームサービスモジュール２０１０は、実際には、ゲームフレームワーク２０００のコンポーネントである。一実施形態において、ゲームデーモン２０２０及び２０１０は、一実施形態ではプライベートＡＰＩ（即ち、第三者の開発者には公表されず）である既定のＡＰＩを通して各ネットワークサービス２０５０−２０５１と通信する。

【0163】

一実施形態において、ゲームデーモン２０２０は、ＨＴＴＰＳプロトコルを使用してマッチメーカーサービス１１１、インビテーションサービス１１２及び他のサービス２０５０と通信し、一方、ゲームサービスモジュール２０１０は、ＵＤＰソケットのような比較的軽い重みのプロトコルを使用してＣＤＸサービス１１０及びＮＡＴ横断サービス２９０−２９１と通信する。しかしながら、上述したように、本発明の基礎的な原理に適合しつつ、種々の他のネットワークプロトコルを使用することができる。

【0164】

更に、図２０に示すように、ゲームデーモン２０２０は、幾つかのサービス２０５２（例えば、インビテーションサービス及びマッチメーカーサービス）により発生されたプッシュ通知２０５２を受け取り、一方、他の形式のプッシュ通知２０５３は、ゲームセンターによって直接受け取られる（例えば、新たな友人要求のような友人サービス通知）。一実施形態において、これらのプッシュ通知２０５３は、ユーザの繊細なデータが第三者のアプリケーション開発者により設計されたアプリケーション２０３０へ接近できないよう保証するためにゲームセンター２０３１へ直接与えられる。

【0165】

図１１について上述したゲームインビテーション例に戻ると、移動装置Ａのアプリケーション２０３０がゲームフレームワーク２０００のＡＰＩ２００１ｂへインビテーションコールを行って、移動装置Ｂのユーザを招待するときに（例えば、ＩＮＶＩＴＥ（プレーヤＢ ＩＤ、ゲーム／バケットＩＤ）、ゲームフレームワーク２０００は、インビテーション要求を移動装置Ａのゲームデーモン２０２０へ通す。次いで、ゲームデーモン２０２０は、インビテーションサービス１１２と通信して、インビテーション要求を提出する。次いで、インビテーションサービス１１２は、プッシュ通知サービス１０５０を利用して（上述したように）、移動装置Ｂのゲームデーモン２０２０へプッシュする。移動装置Ｂのゲームデーモン２０２０は、移動装置Ｂのゲームフレームワーク２０００と通信して、インビテーションが送られたゲームが移動装置Ｂにインストールされているかどうか決定する。もしそうであれば、ゲームフレームワーク２０００は、アプリケーション２０３０をトリガーし及び／又はインビテーションの視覚通知を発生する。アプリケーションがインストールされていない場合には、ゲームフレームワーク２０００は、インビテーションの視覚通知を、ゲームを購入するオファーと共に移動装置Ｂのユーザへ（例えば、ゲームセンター２０３１のＧＵＩを経て）トリガーする。或いは又、視覚通知は、移動装置１２０（図示せず）で実行されるプッシュ通知デーモンにより発生されてもよい。移動装置Ｂのユーザがゲームを購入する場合には、購入の後にインビテーションシーケンスが続けられる。移動装置Ｂのユーザがインビテーション要求を受け容れる場合には、移動装置Ｂのゲームフレームワーク２０００がそのインビテーション要求をゲームデーモン２０２０へ通し、ゲームデーモンは、次いで、インビテーションサービス１１２に応答する。

【0166】

図１１において、移動装置Ａ及びＢのＮＡＴ形式が適合すると適合性チェック１１０６が決定することを想起されたい。従って、１１０８において、移動装置Ａのゲームデーモン２０２０は、移動装置ｂの受け容れを受け取り（例えば、この例ではプッシュ通知を経て）、そして一実施形態では、その受け容れをゲームフレームワーク２０００へ通す。この段階において、移動装置Ａのゲームフレームワーク２０００は、移動装置Ｂが受け容れたことを要求側アプリケーション２０３０に通知するか（ＡＰＩ２００１を経て）、又は装置が首尾良く接続されるまで要求側アプリケーション２０３０に通知するのを待機する。いずれにせよ、ゲームフレームワーク２０００は、接続要求をゲームサービスモジュール２０１０へ通し、このモジュールは、一実施形態では、移動装置Ｂとの接続データ交換を開始する。特に、ゲームサービスモジュールは、ＣＤＸサービス１１０を使用して移動装置Ｂへ移動装置Ａの接続データを送信する（例えば、図１１のトランザクション１１１１及び１１１２を参照）。上述したように、この通信は、セキュアな「チケット」データ構造を使用してＵＤＰ接続として実施される。

【0167】

図１２において、移動装置Ａ及びＢのＮＡＴ形式が適合しないと適合性チェック１１０６が決定した場合には、リレーサービス１０５１を使用して、装置間に接続を与えることができる。その結果、移動装置Ｂのゲームデーモン２０２０は、インビテーションサービスからリレー応答１２０３を受け取り（図１２に示す）、そして移動装置Ａのゲームデーモン２０２０は、インビテーションサービスからリレー応答１２０５を受け取る（プッシュ通知サービス１０５０を経て）。移動装置Ａ及びＢのゲームデーモン２０２０は、１２０６及び１２０７においてリレーサービスと通信して、構成データを検索する。１２１０において、移動装置Ｂのゲームデーモン２０２０は、移動装置Ａからリレー更新データを受け取り、そして１２１３において、移動装置Ａのゲームデーモン２０２０は、移動装置Ｂからリレー更新データを受け取る。

【0168】

図１１及び１２に示すプロセスの最終結果として、移動装置Ａ及びＢは、互いに接続を確立する（直接的なＰ２Ｐ接続、又はリレー接続）。一実施形態において、接続成功を検出すると、ゲームフレームワーク２０００は、ＡＰＩコールを使用して接続を要求したアプリケーション２０３０に通知する（例えば、ＣＯＮＮＥＣＴＥＤ（プレーヤＡ ＩＤ、プレーヤＢ ＩＤ））。次いで、移動装置Ａ及びＢは、確立された接続を使用して指定のゲーム又は他の協力的アプリケーション２０３０をプレイする。

【0169】

従って、ＡＰＩ２００１からの比較的簡単なコールに応答して（例えば、ＩＮＶＩＴＥプレーヤＢ ＩＤ、ゲーム／バケットＩＤ）、移動装置ＡとＢとの間にＰ２Ｐ又はリレー接続を確立するために複雑な一連のトランザクションがゲームフレームワーク２０００によって管理される。一実施形態において、ゲームフレームワーク２０００は、移動装置Ａ及びＢを接続する一連の動作を遂行し、次いで、結果を要求側アプリケーション２０３０に与え、それにより、ＡＰＩコールの詳細をアプリケーション設計者に対して透過的なままとする。従って、アプリケーション設計者は、ネットワーク上の移動装置Ａ及びＢをどのように接続するか、又はそれら装置間の通信を可能にするために要求される種々の他の機能をどのように遂行するか理解する必要がなく、従って、アプリケーション設計プロセスが簡単化される。

【0170】

同様に、ゲームフレームワーク２０００は、図２ａ−ｂについて上述したマッチメーカーサービス１１１を使用して移動装置Ａと他の参加者との間の対戦を確立する。この例では、アプリケーション２０３０は、ＭＡＴＣＨ（プレーヤＡ ＩＤ、ゲーム／バンドル ＩＤ）のような簡単なコールをＡＰＩ２００１へ発信する。それに応答して、ゲームフレームワーク２０００は、対戦を組む動作及び接続データ交換動作を管理する。対戦を組む動作及び／又はＰ２Ｐ接続が完了すると、ゲームフレームワーク２０００は、その結果をアプリケーション２０３０に与える。

【0171】

例えば、図２ｂにおいて、ゲームフレームワーク２０００は、ゲームサービスモジュール２０１０を使用して、接続データ交換（ＣＤＸ）サービス１１０及びＮＡＴ横断サービス２９０−２９１と通信し、そしてゲームデーモンを使用して、マッチメーカーサービス１１１と通信する。対戦が決められると、移動装置Ａのゲームデーモン２０２０は、２２９においてチケットＡを受け取り、そしてゲームフレームワーク２０００は、この情報を使用して、ゲームサービスモジュール２０１０を通して接続データ交換を実施する。たとえば、２３２において、ＮＡＴ横断サービス２９０を通してそれ自身の接続データを要求し、次いで、２３３−２３４において、ＣＤＸ）サービス１１０を通してその接続データを交換する。２３７及び２４０において、移動装置Ａのゲームサービスモジュール２０１０は、移動装置Ａ及びＢの接続データを各々受け取る。これらの交換に続いて、ゲームサービスモジュール２０１０は、２４１において、Ｐ２Ｐ接続を確立し、そしてゲームフレームワーク２０００は、ＡＰＩ通知（例えば、ＭＡＴＣＨ ＣＯＭＰＬＥＴＥ（プレーヤＢ ＩＤ、プレーヤＣ ＩＤ））を使用して接続プロセスが完了したことをアプリケーション２０３０に通知する。次いで、アプリケーションは、確立されたＰ２Ｐ接続を使用して実行することができる。

【0172】

ある実施形態において、ユーザには、現在「オンライン」として登録されている他の友人とゲームをプレイするオプションが与えられる。このケースでは、ある友人がオンラインであるとの通知がプッシュ通知２０５２又はプッシュ通知２０５３（ゲームセンター２０３１によって直接受け取られる）を経て与えられる。次いで、ゲームセンター２０３１及び／又はアプリケーション２０３０は、ユーザに通知を与えると共に、１人以上の選択されたオンライン友人とプレイするオプションをユーザに与える。しかしながら、ここに述べるインビテーションシーケンスは、オンライン通知が与えられるかどうかに関わらず作用することに注意されたい。一実施形態において、ユーザのオンライン状態は、ゲームデーモン２０２０がアクセスできるサービスによって監視される（例えば、上述した友人サービス又は個別の「存在」サービスにより）。

【0173】

ゲームフレームワーク２０００の一実施形態は、ユーザが未知の対戦参加者のグループとゲームをプレイするために１人以上の友人を招待する組み合わせ招待／対戦組み動作を与える。例えば、ゲームが４人のプレーヤを必要とし、そして第１ユーザがゲームをプレイするために第２ユーザを招待する場合には、インビテーションサービス１１２は、最初に、第１ユーザと第２ユーザを接続し、そしてマッチメーカーサービス１１１は、第１ユーザ及び第２ユーザを２人（以上）の他のプレーヤと対戦させる。この実施形態では、ゲームフレームワーク２０００が、最初に、上述したインビテーションシーケンスを遂行して、第１ユーザと第２ユーザを接続する。一実施形態において、第１ユーザと第２ユーザが首尾良く接続されると、ゲームフレームワーク２０００は、対戦を組むシーケンスを実施して、他のユーザを識別しそしてそれと接続する。上述したように、一実施形態では、マッチメーカーサービスにより適用される対戦組み基準は、第１及び第２の両ユーザを含む（例えば、第１及び第２の両ユーザのＮＡＴ形式、接続形式、言語、等）。或いは又、対戦を組む判断をするために２人のユーザの一方の基準が評価されてもよい。

【0174】

全てのユーザが接続されると、ゲームフレームワーク２０００は、ＡＰＩ２００１を経て接続を要求したアプリケーション２０３０に接続結果を与える。この場合も、アプリケーション２０３０による比較的簡単なＡＰＩコールに応答して、ゲームフレームワーク２０００は、各装置を接続するための１組の複雑なトランザクションに入る。装置が首尾良く接続されると、ゲームフレームワーク２０００は、要求側アプリケーション２０３０に結果を返送する。

【0175】

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

【0176】

一実施形態において、通信バッファ２００３は、ユーザ間に全てのＰ２Ｐ接続が確立される前に通信ストリームを一時的に記憶する。例えば、インビテーションサービス１１２又はマッチメーカーサービス１１１が各ユーザを識別した後であって、ＣＤＸサービス１１０が接続データ交換動作を完了する前に、各ユーザには、接続プロセスにある他のゲーム参加者が通知される。この段階において、移動装置１２０のユーザは、テキスト、オーディオ及び／又はビデオ通信ストリームを他の参加者へ送信する。ゲームフレームワーク２０００は、まだ接続されていない参加差について通信ストリームを通信バッファ２００３内に記憶する。次いで、ゲームフレームワーク２０００は、各装置のための接続が完了するときに、テキスト、オーディオ及び／又はビデオをバッファ２００３から送信する。

【0177】

一実施形態では、ゲームデーモン２０２０は、各サービス２０５０において持続するデータをキャッシュしてネットワークトラフィックを減少するためのキャッシュ２０２１を含む。例えば、ユーザの友人のリスト、スコアボードデータ、実績データ、存在データ、及びプロフィールデータは、キャッ巣マネージメントポリシーで指定されるようにキャッシュ２０２１に記憶される。一実施形態では、キャッシュマネージメントポリシーは、データが記憶される各個々のサービスにより駆動される。その結果、ｎ個の異なるサービスに対して、ｎ個の異なるキャッシュマネージメントポリシーがキャッシュ２０２１に適用される。更に、キャッシュマネージメントポリシーは、サービスにより駆動されるので、現在ネットワーク及び／又はサーバー負荷状態に基づいて動的に変更される。例えば、サービスの負荷が厳しい期間中（例えば、クリスマス、新製品発売日、等）、サービスは、あまり頻繁にキャッシュ更新しない（例えば、１２時間ごとに更新の）キャッシュマネージメントポリシーを動的に指定する。対照的に、サービスの負荷が厳しくない期間中は、サービスは、より頻繁にキャッシュ更新する（例えば、３０分、１時間、２時間ごと、等に更新の）キャッシュポリシーを指定する。

【0178】

一実施形態において、キャッシュマネージメントポリシーは、キャッシュ２０２１に記憶されるあるデータレコードのための生存時間（ＴＴＬ）値を使用して指定される。データレコードがそのＴＴＬ値を越えてキャッシュに記憶されていたときには、そのデータが「古くなった(stale)」と考えられ、そのデータのローカル要求が、そのデータに関連したサービスへ直接転送される。一実施形態において、要求は、データの現在バージョンを識別するＩＤコードを含む。ＩＤコードがサービスのＩＤコードに一致する場合には、データが依然有効であり、更新の必要がない。次いで、キャッシュのデータが現在のものであることを指示する応答がサービスから返送され、そしてデータレコードのためのＴＴＬ値がリセットされる。

【0179】

上述したキャッシュマネージメントポリシーを使用するのに加えて、一実施形態では、ある形式のデータに対するキャッシュ更新が、プッシュ通知サービス１０５０を使用して移動装置へプッシュされる。例えば、ユーザの友人リスト、又はユーザの友人の現在オンライン状態に対する変更は、ユーザの移動装置１２０へ動的にプッシュされる。プッシュ通知は、ゲームデーモン２０２０により受け取られ、ゲームデーモンは、次いで、サービスによってプッシュされるデータの当該部分を含むようにキャッシュ２０２１を更新する（即ち、そのサービスに関連したキャッシュ内の全てのデータの更新が要求されるのではない）。対照的に、あるプッシュ通知は、キャッシュの全コンテンツ（又はプッシュを遂行するサービスに関連したキャッシュの少なくとも一部分）をオーバーライトするようにゲームデーモン２０２０に命令する。

【0180】

プッシュを利用してキャッシュ２０２１を更新するサービスは、キャッシュ２０２１に記憶されたデータを更新するための通知をプッシュできるので、比較的高いＴＴＬ値を選択する（及び／又はＴＴＬ値をセットしない）。一実施形態において、各サービスは、プッシュ通知キャッシュ更新をトリガーする１組の事象を指定する。例えば、キャッシュ更新事象は、友人のオンライン状態に対する変更、新たな友人要求、友人要求の受け容れ、友人解除(de-friend)動作、友人が特定ゲームをプレイしているという指示、友人が到達したゲーム実績、特定のスコアボードのトップ１０に対する更新、又はキャッシュ更新を保証するに充分なほど重要であると思われる他の事象を含む。このようにプッシュ通知を使用してキャッシュ２０２１を更新することは、ネットワーク及びサービス負荷を減少する。というのは、プッシュ更新では、移動装置とサービスとの間の周期的なポーリングが要求されないためである。

【0181】

ゲームフレームワーク２０００の一実施形態は、エンドユーザに提示されるデータを、ユーザの国及び／又は地理的位置に基づいて独特にフォーマットする。例えば、現在日時及び通貨値のような値は、異なる国及び位置にいるユーザにとって異なる仕方で提示される。例えば、米国では、日付フォーマットは、［月、日、年］（例えば、April 25, 2010）であり、一方、他の国々では、日付フォーマットは、［日、月、年］（例えば、25 April, 2010）である。同様に、米国及び他の国々で時刻を表わすときには、ＡＭ／ＰＭ呼称が使用され、そして時間と分との間にはコロンが使用される（例えば、３：００ＰＭ）。対照的に、他の多数の国々では、ＡＭ／ＰＭ故障を使用されず、及び／又は時間と分との間にコンマが使用される（例えば、１５，００）。別の例として、世界の多くの地域ではメートル系が使用されるが、世界のある地域では使用されない（例えば、米国）。これらは、本発明の幾つかの実施形態により使用される単なる例示に過ぎないことに注意されたい。本発明の基礎的な原理は、特定の１組のデータフォーマットに限定されない。

【0182】

一実施形態では、これらの異なるデータフォーマットは、スコアボードデータ、実績データ、友人データ、及び／又はゲームフレームワーク２０００により処理される他のデータを表示するときに選択される。ゲームフレームワーク２０００は、ユーザの国及び／又は地理的位置を種々の仕方で決定する。例えば、一実施形態では、この情報は、単にユーザのプロフィールデータに与えられ、及び／又はユーザのセルラーサービスプロバイダーに基づいて決定される。又、ユーザの位置は、例えば、グローバルポジショニングシステム（ＧＰＳ）追跡を使用して決定される。

【0183】

地理的位置及び／又は国に無関係な他の形式のデータフォーマットも、ゲームフレームワーク２０００によって管理される。例えば、スコアボードデータを表示するときには、最低スコアのユーザをスコアボードの最上部に入れるか最下部に入れるか知ることが重要である。あるゲーム（例えば、ゴルフ、トラック、レース、スキー、等）では、数値が低いほど、成績が良いが、他のゲーム（例えば、フットボール、野球、等）では、数値が高いほど、成績が良い。従って、一実施形態では、アプリケーション２０３０は、ＡＰＩ２００１を経て使用されるスコアの形式を指定する（例えば、「増加順」又は「減少順」）。次いで、ゲームフレームワーク２０００は、スコアを表示するための適当な１組のラベル及びフォーマットを使用する。

【0184】

又、ゲームフレームワーク２０００の一実施形態では、ユーザとユーザの友人との間の関係に基づいてユーザデータがフィルタリングされる。例えば、本発明の一実施形態では、「詳細」図、「友人」図、及び「パブリック」図が許される。一実施形態において、詳細図は、データを所有するユーザに利用され（即ち、ユーザのパーソナル情報）、友人図は、ユーザの友人に利用され、そしてパブリック図は、他の全てのユーザに利用される。

【0185】

一例として、パブリック図は、単に、各ユーザに関連した「エイリアス」名、エイリアスによりプレイされるゲーム及び関連スコア、並びにゲームをプレイした日時を含む。この情報は、ゲームフレームワーク２０００により使用されて、パブリックスコアボードをポピュレートし、このスコアボードは、ゲームセンター２０３１を経て表示される。

【0186】

友人図は、一般的な図からの全ての情報、及びユーザの友人の間で共有される付加的な情報を含み、これは、幾つか挙げると、例えば、ユーザにより所有されるゲーム、ユーザによりプレイされるゲーム、ユーザの実績及びスコア、ユーザが何人の友人をもつか、それら友人のアイデンティティ、ユーザの化身を識別するＵＲＬ、及び／又はユーザのオンライン状態を含む。一実施形態において、「友人」図は、友人で共有されるべき情報のデフォールトセットを与えるが、エンドユーザは、このデフォールト構成を調整し、そして特に情報の形式で、各個々の友人又は友人グループ（例えば、同僚、家族メンバー、大学／高校の友人、等）により共有されることを指定する。

【0187】

「詳細」図は、「パブリック」及び「友人」図からの全ての情報、並びにエンドユーザに代わって種々のサービス２０５０により管理される他の情報を含む。例えば、これは、ユーザのプロフィールデータ、ユーザのユニバーサルユニーク識別子（ＵＵＩＤ）（ここでは「プレーヤＩＤ」とも称される）、プレーヤの名前、エイリアス名、ゲームの数及びゲームのアイデンティティ、ユーザの友人、全ユーザ実績、等、の全てを含む。

【0188】

ある環境において、アプリケーション２０３０は、各ユーザのプレーヤＩＤのような、各ユーザに関連した少量の情報しか要求しない。例えば、一実施形態では、対戦が要求されるときに、ゲームフレームワーク２０００は、最初に、各プレーヤのＩＤしか要求しない。マッチメーカーサービスにより対戦が決められたとき（前記参照）、ゲームフレームワーク２０００は、対戦ユーザのいずれかが友人であるかどうか決定する（例えば、友人サービスとの通信を経て、及び／又はユーザのローカル友人データに質問することにより）。もしそうであれば、ゲームフレームワーク２０００は、付加的なユーザデータを検索し、そしてそのデータを対戦友人に与える。このように、ゲームフレームワーク２０００は、ユーザのアイデンティティ及び各ユーザ間の関係に基づいて情報をフィルタリングする。

【0189】

一実施形態では、ゲームフレームワーク２０００は、最初に、２人のユーザが友人関係をもたない場合に、第１ユーザと第２ユーザとの間にパブリック図を与える。しかしながら、一実施形態では、ゲームフレームワーク２０００は、第１ユーザが第２ユーザに友人要求を送信するのを許す（例えば、第２ユーザのエイリアスを使用して）。友人要求が受け容れられた場合には、ゲームフレームワーク２０００は、各ユーザに付加的な情報を与える（例えば、デフォールト「友人」図）。

【0190】

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

【0191】

ＡＰＩは、ＡＰＩ実施ソフトウェアコンポーネントの指定の特徴にアクセスしてそれを使用するときにＡＰＩコールソフトウェアコンポーネントが使用する言語及びパラメータを定義する。例えば、ＡＰＩコールソフトウェアコンポーネントは、ＡＰＩにより露出される１つ以上のＡＰＩコール（機能又は方法コールとも称される）を通してＡＰＩ実施ソフトウェアコンポーネントの指定の特徴にアクセスする。ＡＰＩ実施ソフトウェアコンポーネントは、ＡＰＩコールソフトウェアコンポーネントからのＡＰＩコールに応答して、ＡＰＩを通して値を返送する。ＡＰＩは、ＡＰＩコールのシンタックス及び結果を定義するが（例えば、ＡＰＩコールをどのように呼び出すか及びＡＰＩコールが何を行うか）、典型的に、ＡＰＩは、ＡＰＩコールによって指定された機能をＡＰＩコールがどのように遂行するか明らかにしない。種々の機能コール又はメッセージは、コールソフトウェア（ＡＰＩコールソフトウェアコンポーネント）とＡＰＩ実施ソフトウェアコンポーネントとの間で１つ以上のアプリケーションプログラミングインターフェイスを経て転送される。機能コール又はメッセージを転送することは、機能コール又はメッセージを発行し、開始し、呼び出し、コールし、受信し、返送し、又は応答することを含む。ここで、ＡＰＩコールソフトウェアコンポーネントは、コールを転送し、そしてＡＰＩ実施ソフトウェアコンポーネントは、コールを転送する。

【0192】

一例として、ＡＰＩ実施ソフトウェアコンポーネント２０１０及びＡＰＩコールソフトウェアコンポーネントは、オペレーティングシステム、ライブラリー、装置ドライバー、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュールである（ＡＰＩ実施ソフトウェアコンポーネント及びＡＰＩコールソフトウェアコンポーネントは、互いに同じ形式のソフトウェアモジュールでもよいし、異なる形式のソフトウェアモジュールでもよいことを理解されたい）。ＡＰＩコールソフトウェアコンポーネントは、ローカルソフトウェアコンポーネントである（即ち、ＡＰＩ実施ソフトウェアコンポーネントと同じデータ処理システム上にある）か、リモートソフトウェアコンポーネントであって（即ち、ＡＰＩ実施ソフトウェアコンポーネントとは異なるデータ処理システム上にあって）、ＡＰＩを通りネットワークを経てＡＰＩ実施ソフトウェアコンポーネントと通信するものである。又、ＡＰＩ実施ソフトウェアコンポーネントは、ＡＰＩコールソフトウェアコンポーネントとしても働き（即ち、異なるＡＰＩ実施ソフトウェアコンポーネントにより露出されるＡＰＩへＡＰＩコールを発信し）、そしてＡＰＩコールソフトウェアコンポーネントは、異なるＡＰＩコールソフトウェアコンポーネントへ露出されるＡＰＩを実施することによりＡＰＩ実施ソフトウェアコンポーネントとしても働くことを理解されたい。

【0193】

ＡＰＩは、異なるプログラミング言語で書かれた複数のＡＰＩコールソフトウェアコンポーネントがＡＰＩ実施ソフトウェアコンポーネントと通信するのを許す（従って、ＡＰＩは、ＡＰＩ実施ソフトウェアコンポーネントとＡＰＩコールソフトウェアコンポーネントとの間でコールを変換して返送する特徴を含む）が、ＡＰＩは、特定のプログラミング言語に関して実施されてもよい。

【0194】

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

【0195】

ＡＰＩ実施ソフトウェアコンポーネント２１１０は、ＡＰＩ２１２０を通して指定されず且つＡＰＩコールソフトウェアコンポーネント２１３０に利用できない付加的な機能、方法、クラス、データ構造、及び／又は他の特徴を含むことが明らかであろう。ＡＰＩコールソフトウェアコンポーネント２１３０は、ＡＰＩ実施ソフトウェアコンポーネント２１１０と同じシステム上にあってもよいし、又はリモート位置にあって、ネットワークを経てＡＰＩ２１２０を使用してＡＰＩ実施ソフトウェアコンポーネント２１１０にアクセスするようにしてもよいことを理解されたい。図２１は、ＡＰＩ２１２０と相互作用する単一のＡＰＩコールソフトウェアコンポーネント２１３０を示すが、ＡＰＩコールソフトウェアコンポーネント２１３０とは異なる言語（又は同じ言語）で書かれた他のＡＰＩコールソフトウェアコンポーネントが、ＡＰＩ２１２０を使用してもよいことを理解されたい。

【0196】

ＡＰＩ実施ソフトウェアコンポーネント２１１０、ＡＰＩ２１２０、及びＡＰＩコールソフトウェアコンポーネント２１３０は、マシン（例えば、コンピュータ又は他のデータ処理システム）により読み取れる形態で情報を記憶するメカニズムを含むマシン読み取り可能な媒体に記憶される。例えば、マシン読み取り可能な媒体は、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置、等を含む。

【0197】

図２２（ソフトウェアスタック）の規範的な実施形態において、アプリケーションは、多数のサービスＡＰＩを使用してサービス１又は２へ、及び多数のＯＳ ＡＰＩを使用してオペレーティングシステム（ＯＳ）へコールを発信する。サービス１及び２は、多数のＯＳ ＡＰＩを使用してＯＳへコールを発信する。

【0198】

サービス２は、２つのＡＰＩを有し、その一方（サービス２のＡＰＩ１）は、アプリケーション１からコールを受け取ってそこへ値を返送し、そしてその他方（サービス２のＡＰＩ２）は、アプリケーション２からコールを受け取ってそこへ値を返送することに注意されたい。サービス１（例えば、ソフトウェアライブラリー）は、ＯＳ ＡＰＩ１へコールを発信してそこから返送値を受け取り、そしてサービス２（例えば、ソフトウェアライブラリー）は、ＯＳ ＡＰＩ１及びＯＳ ＡＰＩ２の両方へコールを発信してそこから返送値を受け取る。アプリケーション２は、ＯＳ ＡＰＩ２へコールを発信してそこから返送値を受け取る。

【0199】

規範的なデータ処理装置
図２３は、本発明の幾つかの実施形態に使用される規範的なコンピュータシステムを示すブロック図である。図２３は、コンピュータシステムの種々のコンポーネントを示しているが、その細部は本発明には関係ないものであるから、それらコンポーネントの特定のアーキテクチャー又は接続の仕方を表わすことを意図していないことを理解されたい。それより少数のコンポーネント又は多数のコンポーネントを有する他のコンピュータシステムも、本発明に使用できることが明らかである。

【0200】

図２３に示すように、データ処理システムの形態であるコンピュータシステム２３００は、バス２３５０を備え、これは、処理システム２３２０、電源２３２５、メモリ２３３０、及び不揮発性メモリ２３４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）、等）に結合される。バス２３５０は、この分野で良く知られたように、種々のブリッジ、コントローラ、及び／又はアダプタを通して互いに接続される。処理システム２３２０は、メモリ２３３０及び／又は不揮発性メモリ２３４０からインストラクション（１つ又は複数）を検索し、そしてそれらインストラクションを実行して、上述した動作を遂行する。バス２３５０は、前記コンポーネントを一緒に相互接続すると共に、それらのコンポーネントを、任意のドック２３６０、ディスプレイコントローラ＆ディスプレイ装置２３７０、入力／出力装置２３８０（例えば、ＮＩＣ（ネットワークインターフェイスカード）、カーソルコントロール（例えば、マウス、タッチスクリーン、タッチパッド、等）、キーボード、等）、及び任意のワイヤレストランシーバ２３９０（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、赤外線、等）へも相互接続する。

【0201】

図２４は、本発明の幾つかの実施形態に使用される規範的なデータ処理システムを示すブロック図である。例えば、データ処理システム２４００は、ハンドヘルドコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、移動電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、又は移動電話やメディアプレーヤやゲームシステムを含むハンドヘルドコンピューティング装置である。別の例として、データ処理システム２４００は、ネットワークコンピュータ、又は別の装置内の埋め込み型処理装置である。

【0202】

本発明の一実施形態によれば、データ処理システム２４００の規範的なアーキテクチャーは、上述した移動装置に使用される。データ処理システム２４００は、処理システム２４２０を備え、これは、１つ以上のマイクロプロセッサ及び／又は集積回路上のシステムを含む。処理システム２４２０は、メモリ２４１０、電源２４２５（１つ以上のバッテリを含む）、オーディオ入力／出力２４４０、ディスプレイコントローラ・ディスプレイ装置２４６０、任意の入力／出力２４５０、入力装置２４７０、及びワイヤレストランシーバ２４３０に結合される。図２４に示されていない付加的なコンポーネントも、本発明の幾つかの実施形態ではデータ処理システム２４００の一部分であり、又、本発明の幾つかの実施形態では、図２４に示されたものより少数のコンポーネントが使用されてもよい。更に、この分野で良く知られているように、種々のコンポーネントを相互接続するため、図２４には示されていない１つ以上のバスが使用されてもよい。

【0203】

メモリ２４１０は、データ処理システム２４００で実行するためのデータ及び／又はプログラムを記憶する。オーディオ入力／出力２４４０は、例えば、音楽を演奏するためのマイクロホン及び／又はスピーカを含み、及び／又はスピーカ及びマイクロホンを通して電話機能を与える。ディスプレイコントローラ・ディスプレイ装置２４６０は、グラフィックユーザインターフェイス（ＧＵＩ）を備えている。ワイヤレス（例えば、ＲＦ）トランシーバ２４３０（例えば、ＷｉＦｉトランシーバ、赤外線トランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバ、ワイヤレスセルラー電話トランシーバ、等）は、他のデータ処理システムと通信するのに使用される。１つ以上の入力装置２４７０は、ユーザがシステムへ入力を与えることができるようにする。これらの入力装置は、キーパッド、キーボード、タッチパネル、マルチタッチパネル、等である。任意のための入力／出力２４５０は、ドックのコネクタである。

【0204】

異なるサービスプロバイダーにわたるＰ２Ｐ接続を管理するための実施形態
本発明の一実施形態において、上述したアーキテクチャーは、異なるサービスプロバイダーのピアが、リアルタイムオーディオ、ビデオ及び／又はチャット接続のようなピア・ツー・ピア（Ｐ２Ｐ）接続を確立できるように拡張される。異なるサービスプロバイダーは、それら自身のプロトコル及びそれら自身のクライアントＩＤネームスペースを使用するので、本発明のこれらの実施形態は、装置が使用プロトコルに関わらず相互作用し且つネームスペースを単一のグローバルなネームスペースへと一体化できるようにする技術を提供する。

【0205】

全てのシステムにおける全てのユーザのグローバルなネームスペースを追跡するためにグローバルなデータベースが維持される。しかしながら、サービスプロバイダーにわたって膨大な数のユーザが分散されると、グローバルなデータベースの解決策は、管理が困難となる。或いは又、要求された接続に誰が応答できるか識別するため、ユーザ及び／又はデータ処理装置を識別するのに使用される名前（例えば、ユーザＩＤ、電話番号）が他の全てのサービスプロバイダーへブロードキャストされてもよい。しかしながら、この場合も、そのようなシステムは、充分なスケールにならない（即ち、各試みられた接続に対してブロードキャストメッセージを送信すると、著しい量の帯域巾が消費される）。

【0206】

以上の問題に対処するために、本発明の一実施形態は、接続の試み中にブルームフィルタを使用して、当該サービスプロバイダーを探索する。この実施形態は、図２５−２６に示すアーキテクチャーに関して説明する。図２５には、サービスプロバイダーＡ ２５１０、サービスプロバイダーＢ ２５１１、サービスプロバイダーＣ ２５１２及びサービスプロバイダーＤ ２５１３、の４つのサービスプロバイダーが示されている。先の実施形態と同様に、各サービスプロバイダーは、サービスプロバイダーからデータ通信サービスが提供される１組のユーザのユーザＩＤ及び／又は電話番号を含む登録データベース２５２０−２５２３を管理する。一例として、図２５において、ユーザＡ−Ｃ ２５０１−２５０３には、サービスプロバイダーＡ ２５１０からサービスが提供され、そしてユーザＤ−Ｆには、サービスプロバイダーＤ ２５１３からサービスが提供される。上述したように、一実施形態において、登録データベース２５２０−２５２３は、電話番号又はユーザＩＤを各ユーザのデータ処理装置のプッシュトークンへマップする。従って、サービスプロバイダーにより維持されるサーバーは、特定のサービスプロバイダーのユーザが、前記技術（例えば、図１０−１４及び関連記載を参照）を使用して、探索を行って互いにピア・ツー・ピア接続を確立できるようにする。一例として、サービスプロバイダーにより維持されるサーバーは、ユーザが、ＦａｃｅＴｉｍｅ^TMチャットセッション（本特許出願の譲受人により設計された技術）のようなオーディオ／ビデオチャットセッションを互いに確立できるようにする。

【0207】

サービスプロバイダー自身のユーザ間にＰ２Ｐ接続を確立できるのに加えて、図２５及び２６に示す実施形態では、異なるサービスプロバイダーのユーザが互いにＰ２Ｐ接続を確立できるようにする。特に、図２６に示すように、各サービスプロバイダーは、サービスプロバイダーの登録データベース２５２０、２５２３に最初に問合せをして、特定のユーザがサービスプロバイダーにより管理されるかどうか決定するためにユーザ位置サービス２６００、２６１０を備えている。（図２６には、簡単化のために２つのサービスプロバイダー（プロバイダーＡおよびＤ）しか示されていない。）ユーザＡ ２５０１が、同じサービスプロバイダーにより管理される別のユーザ、例えば、ユーザＢ ２５０２とのＰ２Ｐ接続を要求する場合には、サービスプロバイダーＡのユーザ位置サービス２６００が登録データベースからユーザＢを識別し、そして接続要求をユーザＢへ送信する（例えば、ユーザＢのプッシュトークンが登録データベース２５２０から検索される）。

【0208】

しかしながら、ユーザＡが、異なるサービスプロバイダーにより管理されるユーザ、例えば、ユーザＦ ２５０６とのＰ２Ｐ接続を要求する場合には、サービスプロバイダーＡ２５１０の位置サービス２６００が、他のサービスプロバイダーの各々から受け取ったブルームフィルタ２６０１−２６０３を使用して異なるサービスプロバイダーにおいてユーザＦを探索するよう試みる。特に、図２６に示すように、各サービスプロバイダーは、登録データベース２５２０、２５２３の現在コンテンツに基づいてブルームフィルタを発生するためにブルームフィルタジェネレータ２６５０、２６５１を備えている。この分野の当業者に明らかなように、ブルームフィルタは、エレメントがセットのメンバーであるかどうかテストするのに使用されるスペース効率の良い確率データ構造体である。偽の肯定が考えられるが、偽の否定はない。ここに述べる実施形態では、各ブルームフィルタを発生するのに使用される「エレメント」は、各ユーザのユーザＩＤ及び／又は電話番号である。図２６において、例えば、サービスプロバイダーＡ ２５１０のブルームフィルタジェネレータ２６５０は、全てのユーザＩＤ（Ａｎｄｙ１２４、Ｔｏｍ４５４６、等）を使用して、そのブルームフィルタ２６０４を発生する。同様に、サービスプロバイダーＤ ２５１３のブルームフィルタジェネレータ２６５１は、その登録データベースにおける全てのユーザＩＤ（Ｗｏｏｄｙ１２３４、Ｒｉｃｋ４５６、等）を使用して、そのブルームフィルタ２６０３を発生する。一実施形態では、各サービスプロバイダーは、このようにそれ自身のブルームフィルタを発生し、そして他の全てのサービスプロバイダーにブルームフィルタを周期的に送信する。次いで、各サービスプロバイダーは、他のサービスプロバイダーから受け取ったブルームフィルタを使用して、特定のユーザが他のサービスプロバイダーにより管理されるかどうかテストし決定する。

【0209】

一例として、図２６において、Ａｎｄｙ１２３のユーザＩＤを伴うユーザＡ ２０５１が、Ｗｏｏｄｙ１２３のユーザＩＤを伴うユーザＦ ２５０６とのＰ２Ｐセッション（例えば、パーソナルオーディオ／ビデオチャット）を確立するよう試みる場合には、サービスプロバイダーＡ ２５１０のユーザ位置サービス２６００が、最初に、それ自身の登録データベース２５２０においてユーザＦのユーザ名、Ｗｏｏｄｙ１２３を探索するように試みる。不成功の場合には、一実施形態において、他のサービスプロバイダーのブルームフィルタ２６０１−２６０３に問合せし、ユーザＩＤ“Ｗｏｏｄｙ１２３”を管理するサービスプロバイダーを探索するよう試みる。上述したように、ブルームフィルタは、偽の肯定を与えることがあるが、偽の否定は与えない。従って、サービスプロバイダーＢ及びＣがＷｏｏｄｙ１２３を管理しないことをブルームフィルタが指示する場合に、サービスプロバイダーＡは、Ｗｏｏｄｙ１２３がこれらのサービスプロバイダーによって管理されないことを最終的に知る。ここに示す例では、ブルームフィルタの問合せは、Ｗｏｏｄｙ１２３がサービスプロバイダーＤによって管理されることを指示すると共に、Ｗｏｏｄｙ１２３が１つ以上の他のサービスプロバイダーによって管理されることも指示する。従って、一実施形態では、サービスプロバイダーＡは、開始メッセージ（例えば、ユーザＦをＰ２Ｐセッションに招待するＩＮＶＩＴＥコマンド）を、このユーザＩＤを潜在的に管理する各サービスプロバイダーへ送信する。実際に、このユーザＩＤを管理するサービスプロバイダーは、サービスプロバイダーＡに肯定応答する。正しいサービスプロバイダーがそれ自身、この例ではサービスプロバイダーＤ、を識別すると、２つのサービスプロバイダーは、各ユーザ（この例ではユーザＡ及びＦ）についてプロキシーとして働き、そしてユーザ間の通信チャンネルをオープンさせる。ユーザＡ及びＦは、接続データを交換すると、直接的Ｐ２Ｐ通信チャンネルを互いにオープンする（例えば、図１１を参照して上述した技術を使用して交換し、及び／又は標準的なインターネット接続確立（ＩＣＥ）トランザクションを実施することにより）。或いは又、直接的なＰ２Ｐ接続が実現不能である場合には（例えば、ＮＡＴ形式が不適合であるために）、ユーザＡ及びＦは、図１３に示したリレーサービス１０５１を使用してリレー接続をオープンする（図１２及び関連記載も参照）。

【0210】

一実施形態において、各サービスプロバイダーは、それ自身のブルームフィルタを連続的に更新し、そしてそのブルームフィルタを、Ｐ２Ｐオーディオ／ビデオ接続をサポートすることに関与する他のサービスプロバイダーの各々へ送信することが予想される。更新は、規則的な間隔（例えば、１時間に一度、毎日一度、等）で行われ、及び／又はある数の新たなユーザＩＤが登録データベースに追加された後に行われる。本発明の基礎的な原理は、ブルームフィルタをサービスプロバイダー間で交換する特定のメカニズムに限定されない。

【0211】

ブルームフィルタを発生し更新するための方法の一実施形態が図２７に示されている。この方法は、図２５−２６に示すアーキテクチャーで実行されるが、特定のシステムアーキテクチャーに限定されない。２７０１において、特定のサービスプロバイダーにおけるユーザ登録データベースが更新される。例えば、新たなユーザＩＤ／電話番号が追加され、古いユーザＩＤ／電話番号が削除される。２７０２において、ユーザＩＤ／電話番号の完全なセットを使用して新たなブルームフィルタが発生される。２７０３において、新たなブルームフィルタが参加サービスプロバイダーへ送信される。

【0212】

ブルームフィルタを使用してクライアントに対するサービスプロバイダーを探索する方法の一実施形態が図２７に示されている。この方法は、図２５−２６に示すアーキテクチャーで実行されるが、特定のシステムアーキテクチャーに限定されない。２８０１において、参加サービスプロバイダーのグループのブルームフィルタが受け取られる。ブルームフィルタは、効率的にアクセスするために揮発性メモリに記憶され、及び／又は不揮発性記憶位置へ存続される。２８０２において、別のユーザ（ユーザＦ）とのＰ２Ｐ接続を確立するためにユーザ（この例ではユーザＡ）から接続要求が受け取られる。２８０３において、ブルームフィルタ機能がユーザＦのユーザＩＤ（例えば、前記例からのＷｏｏｄｙ１２３）に対して実行されて、あるサービスプロバイダーを除外する。ブルームフィルタ機能が特定のブルームフィルタについて否定結果を返送する場合には、ユーザＦは、その特定のブルームフィルタによって管理されない。しかしながら、ブルームフィルタについて肯定結果が返送される場合には、そのブルームフィルタに関連したサービスプロバイダーがユーザＦを管理する適度な機会が存在する。１つの肯定結果のみが返送される場合には、２８０４において、接続招待がそのサービスプロバイダーへ送信される。複数の肯定結果が返送される場合には、２８０４において、個別の接続招待が各関連サービスプロバイダーへ送信される。

【0213】

次いで、ユーザＦが登録を有するところのサービスプロバイダーが肯定応答し、そして２つのサービスプロバイダーが、２８０６において、プロキシーとして働いて、ユーザが上述したように接続データを交換するのを許す（例えば、プッシュトークン、パブリック／プライベートネットワークアドレス／ポート、ＮＡＴ形式、等）。２つ以上のサービスプロバイダーが肯定応答する（２つのサービスプロバイダーが同じユーザＩＤをもつユーザをサポートすることを意味する）場合には、正しいユーザを識別するために付加的なステップが取られる（例えば、電話番号、本名、ネットワークアドレス、又は接続を望むユーザに関して知られている他の情報を比較する）。

【0214】

ユーザＦに対する正しいサービスプロバイダーが識別され、そして必要な接続データが交換されると、２８０７において、上述したように、ユーザＡとユーザＦとの間に直接的Ｐ２Ｐ接続又はリレー接続（必要に応じて）が確立される。

【0215】

図１１−１２を参照して述べたように、本発明のある実施形態では、２人（以上）のユーザ間にＰ２Ｐ接続を確立するのに使用される種々のサーバーは、接続プロセス中に接続状態情報を維持する必要がない。これは、例えば、インビテーションサービス１１２及び接続データ交換サービス１１０を含む。むしろ、これら実施形態では、これに限定されないが、パブリック／プライベートＩＰ及びポート（一般的にネットワーク情報とも称される）、ＮＡＴ形式、ユーザＩＤ、プッシュトークン、等を含む完全な接続情報が累積されて、各次々のトランザクションで送信される。図２９に示すように、各トランザクションで送信されるマルチプロバイダーコンテキストにおける状態情報の１つの付加的な断片は、プロバイダーＩＤコードである。

【0216】

図２９の特定の細部へ戻ると、ユーザＡは、開始要求２９０１（ここでは「インビテーション」要求とも称される）を送信し、これは、それ自身のネットワークＩＤ（ＩＤ−Ａ）、上述した技術を使用して決定されるそれ自身のネットワーク情報（例えば、パブリック／プライベートＩＰ／ポートデータ、ＮＡＴ形式、等）、それ自身のプッシュトークン（Ｔｏｋｅｎ−Ａ）、及びユーザＦのＩＤコード、電話番号及び／又は他の形式の識別子を含む。この開始要求は、図２５−２８を参照して上述したいずれかの技術を実施するユーザＡのサービスプロバイダーによって最初に受け取られて、ユーザＦのサービスプロバイダーを探索する（例えば、ブルームフィルタを使用して、あるサービスプロバイダーを除外する）。（ユーザＡ及びユーザＦのサービスプロバイダーは、簡単化のために図２９には示されていない。）

【0217】

一実施形態において、ユーザＦのサービスプロバイダーが識別されると、ユーザＦのサービスプロバイダーからユーザＦへ開始プッシュ動作２９０２が送信され、これは、ユーザＡのサービスプロバイダー、この例では「プロバイダーＡ」の識別子を含む。プロバイダーＡの識別子は、Ｎビット識別コード（例えば、１６ビット、３２ビット、６４ビット、等）のような簡単なものである。或いは又、プロバイダーＡの識別子は、プロバイダーＡのネットワークゲートウェイを識別するパブリックＩＰアドレス、又はプロバイダーＤへ接続するのに必要な他のネットワークデータを含む。本発明の基礎的な原理は、一連のＰ２Ｐ接続トランザクションでプロバイダーＡを識別するのに使用されるフォーマットに関わりなく同じである。

【0218】

一実施形態において、上述したプッシュ通知サービス１０５０のようなプッシュ通知サービスによりプッシュトランザクション２９０２が発生される（例えば、図１１及び関連テキストを参照）。上述したように、ユーザＡによって与えられる全てのオリジナル状態情報、及びサービスプロバイダーＡのサーバーによって収集される付加的な状態情報は、開始プッシュトランザクション２９０２に含まれる。

【0219】

図２９に示す例では、ユーザＦは、受け容れトランザクション２９０３で応答し、これは、全ての以前の状態情報（ＩＤ−Ａ、ＮｅｔＩｎｆｏ−Ａ、Ｐｒｏｖｉｄｅｒ Ａ）を、Ｐ２Ｐ接続の確立に必要なユーザＦの情報と共に含み、これは、例えば、ユーザＦのＩＤ（ＩＤ−Ｆ）、ユーザＦのネットワーク情報（ＮｅｔＩｎｆｏ−Ｆ；これは、パブリック／プライベートＩＰアドレス／ポート、ＮＡＴ形式、等を含む）、及びユーザＦのトークン（Ｔｏｋｅｎ−Ｆ）を含むが、これに限定されない。ユーザＡ及びユーザＦの全ての接続状態情報は、ユーザＦのサービスプロバイダー（この例では「プロバイダーＤ」）によって受け取られ、該プロバイダーは、それ自身のプロバイダーＩＤコードをトランザクションに添付し（Ｐｒｏｖｉｄｅｒ−Ｄ）、そしてそれをユーザＡのサービスプロバイダーに転送する。プロバイダーＡについて上述したように、プロバイダーＤの識別子は、Ｎビット識別コードほど簡単である。或いは又、プロバイダーＤの識別子は、プロバイダーＤのネットワークゲートウェイを識別するパブリックＩＰアドレス、又はプロバイダーＤに接続するのに必要な他のネットワークデータを含んでもよい。本発明の基礎的な原理は、一連のＰ２Ｐ接続トランザクション内でプロバイダーＤを識別するのに使用されるフォーマットに関わりなく同じである。

【0220】

全ての接続状態データがユーザＡによって受信されると（プロバイダーＤデータを含めて）、ユーザＡ及びユーザＦは、トランザクション２９０５により示されたように、上述した技術を使用してＰ２Ｐ接続を確立する。

【0221】

上述したように、ある条件のもとでは、ユーザＡ及びユーザＦは、直接的Ｐ２Ｐ接続ではなく、リレーサービス１０５１（例えば、図１０を参照）を通して接続を確立する必要がある。図３０に示すように、一実施形態において、両サービスプロバイダーＡ及びＦは、それら自身のリレーサービス３００１−３００２を使用する（及び／又は第三者リレーサービスとの関係を有する）。一実施形態において、ユーザＡとユーザＦとの間に試みられたＰ２Ｐ接続が失敗した場合には、サービスプロバイダーＡのリレーサービス３００１（即ち、Ｐ２Ｐ接続を開始するユーザのプロバイダー）を使用して、接続がサポートされる。別の実施形態では、ユーザＦのリレーサービス３００２（即ち、接続が要求されているユーザのプロバイダー）を使用して、接続がサポートされる（図３１においてユーザＡ２５０１とリレーサービス３００２とユーザＦ ２５０６との間の点線で示すように）。更に別の実施形態では、全てのプロバイダーが単一リレーサービスに合意し、そのリレーサービスを利用して、ユーザ間にＰ２Ｐ接続を確立する。

【0222】

本発明の一実施形態では、ユーザ装置間にセキュアなオーディオ／ビデオＰ２Ｐ通信をサポートするために種々の異なる通信プロトコルが結合される。これらのプロトコルは、（これに限定されないが）Ｐ２Ｐ接続を経てセキュアな通信を与えるためのデータグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）；暗号、メッセージ認証及び完全性を与えるように意図されたＲＴＰ（リアルタイムトランスポートプロトコル）のプロフィールと、ユニキャスト（装置対装置）及びマルチキャスト（装置対複数装置）の両アプリケーションのためのＲＴＰデータに対する再生保護とを定義するセキュアなリアルタイムトランスポートプロトコル（又はＳＲＴＰ）；及びユーザ装置間に音声／ビデオ接続を確立するためのセッションイニシエーションプロトコル（ＳＩＰ）；を含む。これらのプロトコルは、ここに述べる本発明のいずれかの実施形態の環境内で使用される。

【0223】

一実施形態において、図２５に示すオープンのプロバイダー間ネットワーク上の各装置は、ＳＴＲＰを使用してアイデンティティ検証及びストリームの端・端暗号化の目的で、他の装置に対してセキュアに識別することができる。セキュアな通信を可能にするために各サービスプロバイダーにより発行される必要のある証明書フォーマットについて以下に説明する。

【0224】

一実施形態において、各プロバイダーは、他のピアプロバイダーをどのように発見するか知ることが必要である。一実施形態において、コールルーティング及びピア情報を問合わせるためのグローバルで且つセキュアなプロバイダーリストが存在する。これは、信頼性のあるサーバー及びそれらのアドレス情報のリストである。プロバイダーの１つがこのサービスのホストとなる。

【0225】

プロバイダー間の接続を有効とし且つ信頼するためにプロバイダー間に必要とされるセキュリティ及び認証のレベルについて以下に述べる。これは、プロバイダーとグローバルなルックアップデータベースとの間に使用されるもの並びにＰ２Ｐ接続の認証に使用されるもの以外の１組のクレデンシャルである。

【0226】

一実施形態において、コールルーティング時に、受信側のプロバイダー（即ち、被呼ユーザ）は、エンドポイント間のＰ２Ｐ接続を認証するのに使用するべく発呼者へ返送するピア証明書を与える。この証明書は、外部エンティティにより署名することができ、証明書の要件は、ｅ−メールだけではなく、任意の形式のアイデンティティを許す。

【0227】

更に、一実施形態において、オーディオ、ビデオ及びシグナリングデータは、単一のデータポートを経て各データ処理装置において一緒にマルチプレクスされる。次いで、オーディオ、ビデオ及びシグナリングデータは、行先装置においてデマルチプレクス及びデコードされる。

【0228】

図２５に示すプロバイダー間ネットワークは、多数の相互動作レイヤより成る。これらレイヤの相互作用は、種々のプロトコルにより指定される。この相互作用の目標は、接続を確立するユーザの要求を処理し、（図２５にユーザＡ−Ｆ ２５０１−２５０６として識別された）ユーザエンドポイント間に必要な情報交換を遂行して、それらがオーディオ／ビデオコールセッションを確立できるようにすることである。

【0229】

動作中に、図２５に示すプロバイダー間ネットワークは、要求を発信したり要求に応答したりして互いに通信する１組のサーバーとして実施される。これらの要求は、ユーザエンドポイントがメディアチャンネル接続データを交換し且つオーディオ／ビデオコールセッションを形成できるように、要求を転送するのに必要なプロトコルアクションである。一実施形態において、各サービスプロバイダーは、そのユーザエンドポイントとの全ての直接通信を管理する。

【0230】

一実施形態において、ユーザエンドポイントは、そのエンドポイントをコントロールする当事者を識別するユニフォームリソース識別子（ＵＲＩ）を経て表わされる。最初にサポートされるＵＲＩスキームは、ｔｅｌ：（電話番号のための）及びｍａｉｌｔｏ：（ｅ−メールアドレスのための）である。将来は、他のＵＲＩスキームがサポートされる。

【0231】

一実施形態において、各ユーザエンドポイントへのＵＲＩのマッピングは、アイデンティティマッピングではなく、多対多の関係である。単一のＵＲＩは、多数のエンドポイントへマップされ、そして単一のエンドポイントは、多数のＵＲＩへマップされる。更に、ＵＲＩからエンドポイントへのマッピングは、多数のプロバイダーに及ぶ。例えば、プロバイダーＡに１つのエンドポイントがあり、プロバイダーＢに異なるエンドポイントがあり、そしてそれらの両エンドポイントは、同じＵＲＩによりマップされる。（しかしながら、一実施形態では、エンドポイントは、一度に１つのプロバイダーによってホストされるだけである。）一実施形態において、エンドポイントＵＲＩは、電話番号及びｅ−メールアドレスのようなジェネリックなユーザレベル識別子である。プロバイダー及びエンドポイントへのそれらのマッピングは、システムによって遂行され、エンドユーザにとって透過的である。

【0232】

一実施形態において、図２５に示されたプロバイダー間通信に使用されるメタプロトコルは、ＨＴＴＰを経てのディクショナリーである。この実施形態では、全てのアクションがＨＴＴＰ ＧＥＴ又はＰＯＳＴとして遂行される。アクションがＨＴＴＰ ＧＥＴとして指定される場合には、ボディが空である。アクションがＨＴＴＰ ＰＯＳＴとして指定される場合には、ボディがディクショナリーとしてエンコードされる要求パラメータを含む。応答は、ディクショナリーとしてエンコードされた応答パラメータを含むボディを有する。一実施形態において、ディクショナリーの初期エンコーディングは、アップル（Ｒ）ＸＭＬプロパティリストである。ＪＳＯＮ又はプロトコルバッファのような他のエンコーディングも使用される。一実施形態において、異なるサービスプロバイダーが、任意の１組のプロトコル又は通信メカニズムを使用して、個々のユーザ装置と通信する。

【0233】

一実施形態において、図２５に示すサービスプロバイダーが互いに発見するのを許すためにプロバイダー発見プロトコルが使用される。一実施形態において、ブートストラップＵＲＩがネットワークの管理エンティティ（例えば、一次又は管理サービスプロバイダー）により出版される。このブートストラップＵＲＩは、このネットワークの受け容れられたメンバーである１組のプロバイダーを含む発見ディクショナリーを指す。サービスプロバイダーごとに、このディクショナリーは、識別情報を含むと共に、このプロバイダーとどのように通信するか指定する更に別のＵＲＩも含む。一実施形態において、サービスプロバイダーが始動するとき及びその後は周期的に、それらが発見ディクショナリーを検索する。次いで、それらは、ディクショナリーの情報に基づいて他のプロバイダーと通信するようにそれら自体を構成する。

【0234】

ユーザ間にＰ２Ｐ通信セッションを確立するための特定の１組のプロトコルの詳細を以下に説明する。しかしながら、これらの特定の詳細は、特定の実施形態を示すに過ぎず、本発明の基礎的な原理に合致するために要求されるものではない。

【0235】

１．インビテーションプロトコル
１つの実施形態のインビテーションプロトコルは、初期コールセットアップに使用される。これは、ビデオコールセッションのメディアチャンネルの確立に使用されるメディアチャンネル接続データを交換するためにユーザエンドポイント（例えば、図２５のユーザエンドポイント２５０１−２５０６）により使用されるアウトオブバンドシグナリングである。

【0236】

１．１．アクション
インビテーションプロトコルには４つのメインアクションがある。

【0237】

１．１．１．開始
コールをスタートするために開始エンドポイントにより送信する。フィールド：セッションｉｄ、自己ｕｒｉ、自己トークン、自己ブロブ、ピアｕｒｉ。

【0238】

１．１．２．受け容れ
コールに参加する意志を示すために受信エンドポイントにより送信する。
フィールド：セッションｉｄ、自己ｕｒｉ、自己トークン、自己ブロブ、ピアｕｒｉ、ピアトークン、ピアブロブ。

【0239】

１．１．３．拒絶
コールに参加する意志がないことを示すために受信エンドポイントにより送信する。フィールド：セッションｉｄ、自己ｕｒｉ、自己トークン、自己ブロブ、ピアｕｒｉ、ピアトークン、ピアブロブ。

【0240】

１．１．４．キャンセル
コールを終了すべきことを示すためにいずれかのエンドポイントにより送信する。フィールド：セッションｉｄ、自己ｕｒｉ、自己トークン、自己ブロブ、ピアｕｒｉ、ピアトークン、ピアブロブ。

【0241】

１．２．アクション変化
アクションにサービスしている当事者に基づき、これらは、次の３つの形態をとる。
＊要求（エンドポイントからプロバイダー）
＊転送（プロバイダーからプロバイダー）
＊プッシュ（プロバイダーからエンドポイント）

【0242】

１．３．コールフロー
１．３．１．ユーザエントリ
エンドポイントは、それが接続を確立したいとき、受信エンドポイントを識別するためにＵＲＩを必要とする。このＵＲＩは、おそらく、ユーザによって提供されるある情報、例えば、ダイヤルされた電話番号、又はアドレス帳に記憶されたｅ−メールアドレスから導出される。次いで、エンドポイントは、そのホストプロバイダー上の開始要求にコールする。

【0243】

１．３．２．開始要求
開始プロバイダーは、ＵＲＩを見て、そのＵＲＩによりマップされるエンドポイントをホストする１組の受信プロバイダーを決定する。（この１組のプロバイダーは、開始プロバイダーそれ自身を含む。）次いで、全ての適用可能な受信プロバイダー上の開始転送にコールする。

【0244】

１．３．３．開始転送
各受信プロバイダーは、受信エンドポイントを決定し、そしてそれに開始プッシュを送信する。

【0245】

１．３．４．開始プッシュ
受信エンドポイントは、開始プッシュを得て、ユーザに情報を提示する。（これは、典型的に、「ＸＸＸがコールしている」ラインに沿ったＵＩである。）ユーザがコールを行うように判断した場合には、エンドポイントは、受け容れ要求にコールする。（さもなければ、拒絶要求にコールする。）

【0246】

１．３．５．受け容れ要求
受信エンドポイントは、そのホストプロバイダー上の受け容れ要求にコールする。

【0247】

１．３．６．受け容れ転送
受信プロバイダーは、受け容れプッシュを開始エンドポイントへ送信する。

【0248】

１．３．７．受け容れプッシュ
開始エンドポイントは、受け容れプッシュを得て、接続を形成して進めることをユーザに指示する。この点において、両エンドポイントは、メディアチャンネル接続データを交換し、従って、それらは、オーディオ／ビデオコールセッションのためのメディアチャンネルを確立する準備ができる。ここから、流れは、メディアセッションマネージメント（以下の）に文書化されたメディアチャンネルエスタブリッシュメントに続く。

【0249】

２．ディスパッチ最適化プロトコル
前記で詳細に述べたように、一実施形態において、ブルームフィルタは、開始コール要求に応答できる候補サービスプロバイダーを選択するのに使用される。一実施形態において、プロバイダーは、それが現在ホストしているエンドポイントの全てのＵＲＩを表わす最新のブルームフィルタを維持することが要求される。全てのプロバイダーのブルームフィルタが増分形態で他の全てのプロバイダーへ配布される。

【0250】

ディスパッチ最適化プロトコル：発信コールをディスパッチするときに、プロバイダーは、先ず、他の全てのプロバイダーのブルームフィルタに相談する。それにより、プロバイダーは、コールに実際にサービスできるプロバイダーの候補セットを得る。次いで、開始アクションがその候補リストのみに送られる。

【0251】

３．メディアセッションマネージメント
メディアセッションマネージメントは、メディアチャンネルのセットアップ、コントロール及びティアダウン、並びにメディアチャンネル上に流れるメディアストリームを指す。メディアセッションマネージメントは、以下に詳細に述べる。

【0252】

４．メディアチャンネル確立
メディアシグナリング、メディアフロー、及びセッションティアダウンのためのネットワークパケットがメディアチャンネルを経て送信される。メディアチャンネルは、ＮＡＴ横断又はリレー構成のいずれかにより確立される（前記で詳細に述べたように）。ＮＡＴ横断及びリレー構成は、両方とも、各エンドポイントが両エンドポイントのメディアチャンネル接続データを所有することを要求する。

【0253】

４．１．ＮＡＴ横断プロトコル
一実施形態において、ＮＡＴ横断プロトコルは、直接的ピア・ツー・ピア接続を経てメディアチャンネルを確立するのに使用される。これは、双方向接続確立（ＩＣＥ）［ＲＦＣ５２４５］に網羅された技術の使用を含む。

【0254】

４．２．リレー構成プロトコル
一実施形態において、リレープロトコルは、リレーネットワークを経てメディアチャンネルを確立するのに使用される。一実施形態において、このプロトコルは、ＴＵＲＮ［ＲＦＣ５７６１］の使用を含む。

【0255】

５．メディアチャンネルシグナリング
メディアシグナリングは、メディアネゴシエーション及びメディア暗号化のためのセキュリティの設定と、オーディオ及びビデオパラメータのためのメディアネゴシエーションとをカバーする。

【0256】

５．１．セキュリティの設定
上述したように、一実施形態において、データグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）［ＲＦＣ４３４７］は、メディアチャンネルにわたるネットワークトラフィックの通信をセキュアなものにするために使用される。ＤＴＬＳプロトコルは、サービスプロバイダーが、ユーザ間で送信される音声／ビデオパケット内の暗号コンテンツにアクセスできないように、端・端暗号化を与えるように実施される。

【0257】

５．２．メディアネゴシエーション
一実施形態において、ＳＩＰ［ＲＦＣ３２６１］は、ビデオコールセッションのオーディオ及びビデオパラメータをネゴシエーションするのに使用される。

【0258】

５．３．オーディオ及びビデオ暗号化
一実施形態において、ＳＲＴＰ［ＲＦＣ３７１１］は、オーディオ及びビデオペイロードを暗号化するのに使用される。

【0259】

６．メディアフローコントロール
メディアフローコントロールは、アクティブなメディアストリームのマネージメント、及びメディアチャンネルを経てのメディア状態変化の通知をカバーする。

【0260】

６．１．ネットワーク適応
一実施形態において、通信チャンネルの変動を考慮するためにネットワーク適応技術が実施される。特に、ユーザエンドポイントは、スループット、パケットロス及びレイテンシーの変化のような変化するネットワーク状態に適応させるため、オーディオ及び／又はビデオビットレートのようなストリームパラメータを調整する。

【0261】

６．２．ビデオミューティング
エンドポイント送信ビデオは、ビデオをミュート／アンミュートする。ＳＩＰ ＭＥＳＳＡＧＥを使用してリモートエンドポイントに通知が送られる。

【0262】

６．３．ビデオの方向
エンドポイント送信ビデオは、ビデオの方向を変更する。ＲＴＰヘッダ拡張情報を使用してリモートエンドポイントに通知が送られる。

【0263】

６．４．ビデオスイッチング
エンドポイント送信ビデオは、ビデオのソースを切り換える。例えば、前向き及び後向きの両カメラを含むユーザ装置では、ビデオが前向きから後向きへ切り換える。ＲＴＰヘッダ拡張情報を使用してリモートエンドポイントへ通知が送られる。

【0264】

６．５．ハングアップ
一実施形態において、エンドポイントは、ＳＩＰ ＢＹＥメッセージを送信することによりアクティブなセッションを明確に終了させる。

【0265】

７．メディアチャンネルティアダウン
メディアセッションは、明確に又は暗示的にティアダウンされる。メディアチャンネルの明確なティアダウンは、ＳＩＰ ＢＹＥメッセージを送信又は受信することにより行われる。暗示的なティアダウンは、ネットワーク接続ロス又は悪いネットワーク性能のために生じる。

【0266】

８．セキュリティ
８．１．証明書
一実施形態において、図２５に示すプロバイダー間システムのエンドポイント間の通信は、パブリックキー暗号化を使用してセキュアなものとされる。各エンティティ（プロバイダー及びエンドポイント）は、そのアイデンティティに署名する信頼できるＣＡにより発行された証明書を有する。この証明書は、エンティティに属するＵＲＩ及び他の識別情報を含む。証明書は、通信時にエンティティのアイデンティティを検証するために相手方によって使用される。

【0267】

８．２．メディアチャンネルシグナリング
ＳＩＰメッセージは、ＤＴＬＳ［ＲＦＣ４３４７］を使用してセキュアなものとされる。

【0268】

８．３．オーディオ及びビデオ
オーディオ及びビデオストリームは、ＳＲＴＰ［ＲＦＣ３７１１］を使用してセキュアなものとされる。

【0269】

９．エンコーディング
９．１．オーディオ
９．１．１．オーディオＣｏｄｅｃ
オーディオＣｏｄｅｃは、ＭＰＥＧ−４改善型低遅延ＡＡＣ（ＡＡＣ−ＥＬＤ、ＩＳＯ／ＩＥＣ １４４９６−３）に準じたものである。

【0270】

９．１．２．音質
一実施形態において、オーディオ信号の音響特性は、ワイドバンド電話端子の３ＧＰＰ仕様、ＴＳ２６．１３１及びＴＳ２６．１３２により指定される。

【0271】

９．１．２．オーディオＲＴＰペイロードフォーマット
９．２．ビデオ
一実施形態において、ビットストリーム内でビデオストリーム記述を実行するためシーケンスパラメータセット（ＳＰＳ）及びピクチャーパラメータセット（ＰＰＳ）ＮＡＬＵが使用される。

【0272】

９．２．１．ビデオＣｏｄｅｃ
一実施形態において、図２５に示すユーザ間の通信に使用されるビデオＣｏｄｅｃは、ｂフレームなしのＨ．２６４高プロフィール、レベル１．２（有効ＱＶＧＡ１５ｆｐｓ、ｍａｘ３００ｋｂｐｓ）である。しかしながら、本発明の基礎的な原理は、特定のオーディオ／ビデオフォーマットに限定されないことに注意されたい。

【0273】

９．２．２．ビデオＲＴＰペイロードフォーマット
上述したように、ユーザエンドポイント間のオーディオ／ビデオ通信をサポートするためにリアルタイムトランスポートプロトコル（ＲＴＰ）が使用される。図３２に示すように、一実施形態において、ＲＦＣ３９８４ヘッダ３２０２（即ち、ＲＦＣ３９８４、Ｈ．２６４ビデオのためのＲＴＰペイロードフォーマットにより定義された）が各１２バイトＲＴＰペイロード３２０１（ＲＴＰデータパケットを含む）に添付される。ヘッダは、Ｈ．２６４画像記述拡張を使用してＲＴＰデータをどのようにパケット化するか指定する。

【0274】

セキュアなインスタントメッセージングのためのシステム及び方法
本発明の一実施形態は、インスタントメッセージング及びビデオチャットのようなアプリケーションに対して移動装置間でセキュアなピア・ツー・ピアセッションを行えるようにするアーキテクチャーを提供する。図３３に示すように、本発明のこの実施形態は、ユーザを認証するためのアイデンティティサービス３３０１、（上述したように）移動装置へ通知をプッシュするためのプッシュ通知サービス１０５０、及び２人以上の移動ユーザ（図３３にはユーザＡ １１０及びＢ １１１が示されている）間にセキュアなインスタントメッセージングセッションを確立するためのセキュアなインスタントメッセージングサービス３３０２を備えている。一実施形態において、アイデンティティサービス３３０１は、アクティブなユーザＩＤのユーザ登録ディレクトリ３３０２、認証キー及びプッシュトークンを管理し、それらは、移動装置へプッシュ通知を送信するためにここに述べるように通知サービス１０５０により使用される。一実施形態において、ユーザＩＤは、ｅ−メールアドレスであるが、本発明の既存的な原理は、特定形式のユーザＩＤに限定されない。更に、単一のユーザが異なるアプリケーション（例えば、インスタントメッセージング、ビデオチャット、ファイルシェアリング、等）に対して多数のユーザＩＤを有し、そして異なる移動装置（例えば、本特許出願の譲受人によって設計されたｉＰｈｏｎｅ^TM（Ｒ）及び個別のｉＰａｄ^TM（Ｒ）装置）を有してもよい。

【0275】

セキュアなピア・ツー・ピア通信チャンネルを確立するためのコンピュータ実施方法の一実施形態が図３４に示されている。この方法は、最初に、図３３に示すアーキテクチャーの環境内で説明するが、本発明の基礎的な原理は、この特定のアーキテクチャーに限定されないことに注意されたい。

【0276】

３４０１において、ユーザＡは、ユーザＢの識別子（例えば、ユーザＢのｅ−メールアドレス及び／又は電話番号）を含む問合せをアイデンティティサービス３３０１へ送信して、ユーザＢとのセキュアな通信チャンネルを開始する。それに応答して、アイデンティティサービス３３０１は、３４０２において、ユーザＩＤが問合せに一致するかどうか（例えば、ユーザＢのｅ−メールアドレス又は電話番号がアイデンティティサービス内に登録されているかどうか）決定する。もしそうでなければ、３４０３において、アイデンティティサービスは、失敗通知をユーザＡへ送信する。

【0277】

一致が見つかった場合には、３４０４において、ユーザＡは、ユーザＢのネットワークアドレス情報及びパブリックキーをアイデンティティサービス３３０１から検索する。一実施形態において、アドレス情報は、ユーザＢのコンピューティング装置のトークンを含み、従って、ユーザＡがこの特定のアドレスをもつユーザＢと話をするのを許可する（装置Ａのトークンは、Ｂのトークンと話ができる）。ユーザＢが複数の装置を有する場合には、複数のトークンがアイデンティティサービス３３０１から与えられ（装置ごとに１つ）そしてユーザＡへ個別にルーティングされる。

【0278】

一実施形態において、セッションキーも発生され（ここでは「問合わせ署名」とも称され）、これは、アイデンティティサービス３３０１によって与えられる現在時間のタイムスタンプ、ユーザＡのＩＤ、ユーザＢのＩＤ、ユーザＡのトークン、及びユーザＢのトークンの上の署名である。このセッションキーは、その後、（以下に述べるように）アイデンティティサービスを伴わずに２人のユーザを認証するためにセキュアなＩＭサービス３３０２により使用される。

【0279】

ユーザＡは、今や、これらアドレスユニット（ターゲットＩＤ／トークン）の各々に対してアドレス情報及びパブリックキーを有する。３４０４において、装置Ａは、ユーザＢへ送信されるべきメッセージ及びアタッチメントをユーザＡのプライベートキー及び装置Ｂのパブリックキーで暗号化する。一実施形態において、これは、テキスト／アタッチメントのコンテンツをユーザＢのキーで暗号化しそしてそのコンテンツをユーザＡのキーで署名することを含む。暗号化されると、メッセージは、ユーザＡとユーザＢとの間に位置するいずれのサーバーでも解読できないが、サーバーは、送信されるメッセージの形式（例えば、それがテキストメッセージであるか読み取った受領書であるか）を見ることができる。ユーザＢのパブリックキーを使用した暗号化の結果として、ユーザＢだけがメッセージのコンテンツを読み取ることができる。又、ユーザＢは、ユーザＡの署名を使用して送信者（ユーザＡ）を検証することもできる。

【0280】

３４０６において、ユーザＡは、データグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）を使用してプッシュ通知サービス１０５０でセキュアな通信チャンネルをオープンし、そして暗号化されたメッセージを、ユーザＢのトークン、ユーザＩＤ、及びユーザＡのユーザＩＤと共にプッシュ通知サービス１０５０へ送信する。当業者に知られたように、ＤＴＬＳプロトコルは、通信のプライバシーを与え、盗聴、改竄又はメッセージ偽造を防止するように設計された仕方でデータグラムベースのアプリケーションが通信するのを許す。ＤＴＬＳプロトコルに関連した特定の細部は、良く知られているから、ここでは詳細に述べない。

【0281】

一実施形態において、ユーザＡのトークンは、この段階では、プッシュ通知サービス１０５０へ送信されず、プッシュ通知サービス１０５０とのユーザＡの通信に基づいて推測される。３４０７において、プッシュ通知サービス１０５０は、セキュアなインスタントメッセージングサービス３３０２とのセキュアな通信チャンネルをオープンし、そして要求があった際に、セキュアなインスタントメッセージングサービスにユーザＡのプッシュトークンを与える。従って、この段階において、セキュアなインスタントメッセージングサービス３３０２は、ユーザＢのトークン及びＩＤ、並びにユーザＡのトークン及びＩＤを有する。一実施形態において、例えば、ユーザＢのトークン及びＩＤ、ユーザＡのトークン及びＩＤ、並びにタイムスタンプでセッションキーを再発生し、そしてその発生されたセッションキーをプッシュ通知サービス１０５０から受け取られたものと比較することにより、上述したセッションキーを使用してこの情報を検証する。一実施形態において、現在のタイムスタンプがオリジナルのタイムスタンプの遥かに前方にある場合には、署名が一致せず、検証失敗が生じる。署名が一致する（即ち、メッセージに満足な署名がある）場合には、３４０９において、セキュアなインスタントメッセージングサービス３３０２は、プッシュ通知サービス１０５０との第２の出て行くセキュアな通信チャンネルをオープンし、ユーザＡのプッシュトークンをメッセージに追加し（ユーザＢのプッシュトークン及びＩＤと共に）、そしてメッセージを、ユーザＢへの配布のためにプッシュ通知サービス１０５０へ送信する。重要なことに、この段階では、セキュアなＩＭサービス３３０２は、検証の目的でアイデンティティサービス３３０１に問合せする必要がなく、従って、ネットワーク帯域巾を保存する。

【0282】

３４１０において、プッシュ通知サービスは、トランスポートレイヤセキュリティ（ＴＬＳ）を使用してユーザＢとのセキュアな通信チャンネルをオープンし、そしてユーザＢへメッセージをプッシュする。３４１１において、ユーザＢは、ユーザＡについて上述した同じ検証動作を遂行して、メッセージを検証し解読する。特に、ユーザＢは、アイデンティティサービス３３０１に問合せしてユーザＡのパブリックキーを検索し、次いで、そのパブリックキーを使用して、メッセージ（ユーザＡのプライベートキーを使用して以前に署名され且つユーザＢのパブリックキーで暗号化されている）を検証する。この段階において、ユーザＡ及びＢは、３４１０でセキュアなＩＭセッションを確立するのに必要な全ての情報（例えば、パブリックキー及びトークン）を有する。

【0283】

図３５に示す一実施形態において、上述した技術に代わって又はそれに加えて、オフ・ザ・レコード・メッセージング（ＯＴＲ）ネゴシエーションが使用される。当業者に知られたように、ＯＴＲは、ＡＥＳ対称的キーアルゴリズム、ディフィー・ヘルマンキー交換、及びＳＨＡ−１ハッシュ関数の組み合わせを使用するインスタントメッセージング会話のための強力な暗号を与える暗号プロトコルである。一実施形態において、上述したセキュアなメッセージング技術が試みられ、それが不成功な場合に、図３５に示すＯＴＲ技術が使用される。

【0284】

３５０１において、ユーザＡは、ユーザＢのＩＤ（例えば、ｅ−メールアドレス、電話番号、等）を使用してアイデンティティサービスに問合せし、そしてアイデンティティサービスからユーザＢのパブリックキーを検索する。３５０２において、ユーザＡは、ユーザＢのパブリックキーを使用して暗号化することによりセキュアなＯＴＲセッション要求を発生し、そしてその要求をユーザＢへ送信する。３５０３において、ユーザＢは、ユーザＢのプライベートキーを使用して解読し、そしてセッション要求に応答して、ユーザＢは、ユーザＡのパブリックキーを検索する。

【0285】

３５０４において、ユーザＢは、ＯＴＲ応答を発生し、その応答をユーザＡのパブリックキーで暗号化する。３５０５において、ユーザＡ及びＢは、付加的なＯＴＲ接続メッセージを交換する。この段階で交換される特定のメッセージは、現在のＯＴＲ仕様によって定義され、それ故、ここでは詳細に述べない。３５０６において、全ての必要な接続データが交換されると、ユーザＡ及びＢは、互いにセキュアなインスタントメッセージング通信チャンネルをオープンする。

【0286】

上述した実施形態は、インスタントメッセージングの実施に焦点を合わせたが、本発明の基礎的な原理は、ピア・ツー・ピアオーディオ及び／又はビデオサービスのような他の形式のピア・ツー・ピア通信形式でも実施できる。

【0287】

移動ユーザを接続するためのアイデンティティサービスの実施形態
上述したように、一実施形態において、アイデンティティサービス３３０１は、アクティブなユーザＩＤ、認証キー、及びプッシュトークンのユーザ登録ディレクトリ３３０２を管理する。アイデンティティサービス３３０１は、プッシュ通知サービス１０５０及びセキュアなインスタントメッセージングサービス３３０２のような他のサービスによって使用されて、人間が使用できる入力に基づき移動装置及びユーザの効率的な識別情報を与える。特に、一実施形態では、アイデンティティサービスは、便利なユーザ読み取り可能なユーザＩＤコード（例えば、電話番号、ｅ−メールアドレス、ゲームセンターニックネーム、等）を詳細なユーザ／装置情報へマップするテーブルを伴う共有ユーザ登録データベース３３０２を備えている。

【0288】

一実施形態において、単一のユーザＩＤは、ユーザ登録ディレクトリ３３０２内の複数の物理的装置へマップされる。例えば、ＩＤ [e-mail]を伴うユーザは、ｉＰｈｏｎｅ^TM（Ｒ）及び個別のｉＰａｄ^TM（Ｒ）（本特許出願の譲受人により設計された装置）並びに個別のノートブック／デスクトップパーソナルコンピュータのような多数の移動装置を有する。必要な認証クレデンシャルを伴うユーザ又はサービスは、他のユーザに関する情報を検索するためにアイデンティティサービスに問合せする。以上の特定の装置は、説明上使用されたものであるが、本発明の基礎的な原理は、その特定の装置形式に限定されない。

【0289】

一実施形態において、各装置に対し維持される装置情報は、（１）装置のプッシュトークン（上述したように装置のネットワークアドレス情報を含む）、及び（２）装置の１組の能力を含む。その能力は、装置のサービスプロバイダーのアイデンティティ（例えば、ＡＴ＆Ｔ ｖｓ Ｖｅｒｉｚｏｎ）、装置のバージョン情報（例えば、ソフトウェアＯＳバージョン及び／又はアプリケーションバージョン）、及び装置によってサポートされる１つ以上のプロトコル（例えば、装置にインストールされたアプリケーションプログラムコードに基づく）を含む。例えば、装置がＦａｃｅｔｉｍｅ^TMアプリケーションをインストールしている場合には、この情報は、装置情報と共にアイデンティティサービスにより記憶される。更に、装置情報は、各ユーザ装置が通信することのできるサービスの形式（例えば、上述したセキュアなインスタントメッセージングサービス）を指定する。

【0290】

従って、ユーザＢの装置情報を検索するための問合せに応答して、ユーザＡは、ユーザＢの各装置の前記装置情報を含む応答をアイデンティティサービス３３０１から受け取る。これは、ユーザＡの装置に、ユーザＡの装置がユーザＢと通信する種々の方法を有効に通知する。例えば、ユーザＡがユーザＢと同じ通信アプリケーションを幾つか有し（例えば、同じインスタントメッセージングクライアント、Ｆａｃｅｔｉｍｅアプリケーション、ファイルシェアアプリケーション、等）、正しいバージョンがインストールされている場合には、ユーザＡの装置がこの情報を使用して、ユーザＢとの通信チャンネルをオープンするよう試みる。

【0291】

一実施形態において、装置情報は、各アプリケーションの特定のアプリケーション能力を識別する１組のフラグも含む。前記Ｆａｃｅｔｉｍｅの例に戻ると、装置情報は、ユーザＢの装置が３Ｇネットワークを経てＦａｃｅｔｉｍｅチャンネルをサポートすることを指定する。そのようなケースでは、ユーザＡの装置は、次いで、ユーザＢの装置によってサポートされる特定のプロトコルを使用して３Ｇネットワークを経てユーザＢの装置との通信チャンネルをオープンするように試みる。もちろん、以上の説明は、単なる例示に過ぎない。本発明の基礎的な原理は、任意の特定の１組のアプリケーション能力又はプロトコルに限定されない。

【0292】

図３６に示す本発明の一実施形態において、アイデンティティサービスと相互作用するために装置が遂行する動作は、次の４つがある：（１）認証；（２）登録；（３）正規化；及び（４）問合せ。

【0293】

（１）認証
ここで使用する「認証」は、特定のユーザ識別子（ＩＤ）のアイデンティティを与えることを指す。一実施形態において、行われる認証は、異なる形式のＩＤコード（例えば、ｅ−メールアドレス、サービスニックネーム、ユーザＩＤコード、電話番号、等）に対して異なるものである。例えば、ｅ−メールアドレスの認証は、電話番号又はサービスＩＤコードの認証とは異なる。

【0294】

これらの動作は、図３６に示すシステムアーキテクチャー及び図３７に示す方法に関して説明する。しかしながら、図３７に示す方法は、本発明の基礎的な原理に適合しつつ、異なるシステムアーキテクチャーで実施できることに注意されたい。

【0295】

３７０１において、ユーザＡは、１組のアプリケーション特有のクレデンシャルをアプリケーション認証サービス３６０１へ送信する。例えば、ｅ−メールアプリケーションの場合には、クレデンシャルは、ユーザＡのｅ−メールアドレス及びパスワードを含み、ゲームアプリケーションの場合には、これは、ゲームサービスに対するユーザＩＤ及びパスワードを含み、そして電話番号の場合には、ショートメッセージサービス（ＳＭＳ）署名を含む。更に、図３６には個別のサービスとして示されているが、アプリケーション認証サービス３６０１及びアイデンティティサービス３３０１は、単一の一体化されたサービスを形成してもよい。

【0296】

それに応答して、３７０２において、アプリケーション認証サービス３６０１は、与えられた認証クレデンシャルを得て、それに署名し、それを、ここで「プロビジョニング証明書」と称する認証証明書に入れ、そしてそのプロビジョニング証明書をユーザＡに送信する。一実施形態において、プロビジョニング証明書は、暗号ナンス（例えば、タイムスタンプ）及び署名を含む。

【0297】

プロビジョニング証明書に加えて、一実施形態において、ユーザＡには、３７０３において、プッシュ通知サービスから受け取られた「プッシュ証明書」が与えられ、これは、ユーザＡのプッシュトークン、ナンス（例えば、タイムスタンプ）、及びユーザＡの能力（例えば、ユーザＡの装置にインストールされた特定のアプリケーション）のリストの上の署名を含む。一実施形態において、ユーザＡの装置が最初にネットワークにプロビジョニングされるときにユーザＡの装置にプッシュ証明書が与えられる。

【0298】

（２）登録
３７０４において、ユーザＡは、そのプッシュ証明書及びそのプロビジョニング証明書をアイデンティティサービスに登録し、そして３７０５において、アイデンティティサービスは、プッシュ証明書及びプロビジョニング証明書からある所定の情報を抽出し、そしてそれらのエンティティに対するそれ自身の署名、ここではユーザＡの「アイデンティティ証明書」と称する、を発生し、これは、その後、ネットワーク上のいずれかのサービスでユーザＡのアイデンティティを検証するのに使用される（即ち、検証のためにアイデンティティサービスに個々に連絡するためのサービスを必要とせずに）。

【0299】

（３）正規化
ある形式のユーザＩＤは、それらが種々の異なるフォーマットを使用してしばしば表現されることを意味する「ノイズ性」である。例えば、同じ電話番号が、４０８−５５５−１２１２、１−４０８−５５５−２１２、又は４０８５５５１２１２のいずれかで表される。又、異なるフォーマットをとる種々の国際アクセスコード及びキャリアアクセスコードもある。その結果、第１ユーザは、第２ユーザの電話番号を知っているが、登録データベース３３０２内で第２ユーザの電話番号を探索するために現在コンテキスト（例えば、ユーザが現在どこを歩きまわっているか、電話番号がどのようなフォーマットであるか）が与えられたときにユーザに到達するに必要な特定フォーマットを知らないことがある。

【0300】

登録データベース内に特定ユーザＩＤの異なる変化の各々を記憶するのは効率的でない（即ち、著しい量のスペースを消費し、そしてあり得る全ての異なるフォーマットを首尾良く捕獲しないことがある）。従って、この問題に対処するために、本発明の一実施形態は、登録データベース３３０２内にユーザＩＤを記憶する前にユーザＩＤを正規化する（例えば、合意した正規化フォーマットを使用して）。

【0301】

一実施形態において、アイデンティティサービス３３０１は、ユーザの現在コンテキスト及び要求側装置の設定に基づいて正規化を遂行するためのロジックを含む。例えば、図３７において、ユーザＢは、アイデンティティサービス３３０１に、そのホームキャリアのアイデンティティ（例えば、ＡＴ＆Ｔ）、その現在ローミングキャリア（例えば、ＴＭｏｂｉｌｅ）、ユーザ設定（例えば、国際援助が使用されているかどうかの指示）、及び生のターゲットＩＤコード（例えば、４０８５５５１２１２のような非正規化形態でのユーザＡの電話番号）を与える。それに応答して、アイデンティティサービス３３０１は、登録データベース３３０２の問合せを遂行する前に全ての前記変数に基づいて生のターゲットＩＤを正規化する。従って、ユーザＡの正規ＩＤ（生のＩＤではない）が、アイデンティティサービスへのユーザＢの問合せに応答してユーザＢに与えられる（以下に詳細に述べる）。

【0302】

（４）問合せ
上述したように、ターゲットユーザとのセキュアな通信チャンネルを確立するために、ユーザは、最初に、アイデンティティサービスに問合せして、ターゲットユーザのアイデンティティを検索する。図３６に示すように、ユーザＢは、ユーザＡのアイデンティティの問合せを送信し、それ自身のアイデンティティ証明書を問合せの一部分として送る。それに応答して、アイデンティティサービスは、０以上のアイデンティティ証明書を返送し、その各々は、ユーザＡのＩＤコード（上述した正規化形態の）と、そのアイデンティティに対するプッシュトークンと、ユーザＡのＩＤ及びプッシュトークン並びにユーザＢのＩＤ及びプッシュトークンの上に発生される問合せ署名と、を含む。

【0303】

認証が要求されるたびに各サービスがＩＤＳに問合せするよう強制するのは効率的でない。例えば、ユーザＡがユーザＢへメッセージを送信したいとき、上述したインスタントメッセージングサービスは、ユーザＡのトークン及び署名並びにユーザＢのトークン及び署名でアイデンティティサービスに問合せする必要があり、これは、ネットワークリソースを消費する。

【0304】

この問題に対処するために、ここに述べる本発明の実施形態では、１組の０以上の署名がユーザ間のトランザクションごとにアイデンティティサービスによって発生され、この１組の署名は、各要求と共に各サービスへ送信される。署名は、上述したように、ソースＩＤ、ソーストークン、ターゲットＩＤ、ターゲットトークン、及びタイムスタンプのタプルの上になされる。従って、いかなるサービスも、それらエンティティの上に暗号署名を動的に発生することによりそれ自身の検証を行って、アイデンティティサービスに連絡せずに検証することができる。

【0305】

更に、各個々のサービスは、検証を首尾良く行うためにはどれほど新しいタイムスタンプが必要であるか判断することができる。アイデンティティサービスにより発生されたオリジナルのタイムスタンプから既定の時間ウインドウ内に検証が行われる限り、トランザクションは、首尾良く検証される。従って、アイデンティティサービスは、アプリケーションサービスがユーザを認証できるようにするツールを提供するが、どのように認証を行うべきか（例えば、どのように新しいタイムスタンプが必要であるか）のポリシー判断は行わない。従って、異なるアプリケーションは、認証に対して異なるポリシーを有する。

【0306】

アイデンティティサービスの一実施形態は、ネットワークトラフィックの量を更に減少するために問合せのキャッシュアーキテクチャーを実施する。図３８ａ−ｂに示したように、この実施形態では、ユーザＩＤの装置キャッシュ３８０１が各ユーザ装置１１１に維持され、又、中間システムキャッシュ３８０２がネットワーク上でアイデンティティサービス３３０１と装置３８０１との間で実施されて、アイデンティティ要求にサービスし、従って、アイデンティティサービスの負荷を減少する。一実施形態において、システムキャッシュ３８０２は、アカマイ(Akamai)から現在入手できるようなコンテンツ配布ネットワーク及び他のコンテンツ配布サービスにより形成される。

【0307】

図３８ａに示すように、システムキャッシュは、それがユーザＡのための有効なエントリを現在有していない場合に、アイデンティティサービスへ要求を転送し、アイデンティティサービスは、上述したように、ユーザＡに対する０以上の識別子で応答する。更に、図３８ａに示す実施形態では、アイデンティティサービスは、ユーザＡのアイデンティティのための指紋を発生し、そしてその指紋をシステムキャッシュへ返送する。一実施形態において、指紋は、ユーザＡのアイデンティティ（即ち、Ａの正規化されたＩＤ、プッシュトークン及びタイムスタンプ）を含むエンティティ上のハッシュである。一実施形態において、ハッシュは、ＳＨＡ−１であるが、本発明の基礎的な原理は、特定の形式のハッシュアルゴリズムに限定されない。

【0308】

次いで、指紋は、図３８ｂに示したように、システムキャッシュにユーザＡのアイデンティティと共にキャッシュされる（例えば、ユーザＡの正規化されたアイデンティティを使用してインデックスされる）。更に、指紋及び関連ＩＤは、ユーザＢの装置の装置キャッシュ３８０１内にキャッシュされる。

【0309】

ユーザＢがその後にユーザＡのアイデンティティについて問合せすることが必要になったときに、ユーザＢは、最初に、装置キャッシュ３８０１内を見て、ユーザＡのアイデンティティに対して有効なキャッシュエントリが存在するかどうか決定する。一実施形態において、各キャッシュエントリは、それに関連した生存時間（ＴＴＬ）値を有する（図３８に示すタイムスタンプ列で決定されるように）。アイデンティティの要求がタイムスタンプから指定の時間ウインドウ内に生じる限り、装置キャッシュ３８０１のエントリは有効であり、ネットワークを経ての問合せは要求されない（即ち、ユーザＢは、装置キャッシュ３８０１からユーザＡのアイデンティティを読み取る）。

【0310】

しかしながら、装置キャッシュ３８０１内のキャッシュエントリが満了となった（即ち、ＴＴＬ値を過ぎた）場合には、ユーザＢがユーザＡのアイデンティティの問合せをシステムキャッシュ３８０２へ送信し、このシステムキャッシュは、（ユーザＡの正規化されたＩＤコードを使用して）ユーザＡの指紋をルックアップし、そしてその指紋を、ユーザＡの問合せと共にアイデンティティサービス３３０１へ送信する。指紋がまだ有効であることがアイデンティティサービス３３０１により決定された場合には（例えば、タイムスタンプがまだ有効な時間ウインドウ内である場合には）、アイデンティティサービス３３０１により要求される唯一の応答が指紋有効性の指示である。次いで、システムキャッシュ３８０２は、図３８ｂに示すように、ユーザＡのアイデンティティのキャッシュコピーをユーザＢへ返送する。以上のキャッシュ技術は、ユーザＢ及びユーザＡのアイデンティティ上に新たな１組の署名を発生することが必要となる著しい量の処理リソースを節約する。

【0311】

一実施形態において、上述したキャッシュＴＴＬ値は、アプリケーションごとに（即ち、アプリケーション設計者のセキュリティの好みに基づいて）構成可能である。従って、例えば、Ｆａｃｅｔｉｍｅ^TMのようなアプリケーションには、ｉＣｈａｔ以外のＴＴＬ値が設けられる。更に、ＴＴＬ値は、現在ネットワーク状態に基づき動的にセットされる。例えば、ネットワークが、現在、トラフィックで過負荷になった場合には、ＴＴＬ値が、より高い値に動的にセットされる（キャッシュされるアイデンティティが、より長い期間有効となるように）。更に、一実施形態において、上述した全てのキャッシュ技術は、アプリケーション開発者に露出されるＡＰＩ内で実施される。従って、アイデンティティのキャッシュ処理は、それらを使用するアプリケーションに対して透過的に行われる。

【0312】

本発明の実施形態は、上述した種々のステップを含む。それらのステップは、汎用又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションで実施される。或いは又、それらのステップは、それらのステップを遂行するためのハードワイヤードロジックを含む特定のハードウェアコンポーネントにより遂行されてもよいし、プログラム型コンピュータコンポーネント及びカスタムハードウェアコンポーネントの組み合わせによって遂行されてもよい。

【0313】

又、本発明の要素は、マシン実行可能なプログラムコードを記憶するためのマシン読み取り可能な媒体として設けられてもよい。マシン読み取り可能な媒体は、フロッピーディスケット、光学ディスク、ＣＤ−ＲＯＭ、磁気光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、或いは電子的プログラムコードを記憶するのに適した他の形式の媒体／マシン読み取り可能な媒体を含むが、これに限定されない。

【0314】

以上の記述全体を通して、説明上、本発明を完全に理解するため多数の特定の細部について述べた。しかしながら、当業者であれば、幾つかの特定の細部がなくても、本発明を実施できることが明らかであろう。例えば、ここに述べる機能的モジュール及び方法は、ソフトウェア、ハードウェア又はその組み合わせとして実施できることが当業者に容易に明らかであろう。更に、本発明の実施形態は、移動コンピューティング環境に関して（即ち、移動装置１２０−１２３；６０１−６０３を使用して）ここに説明するが、本発明の基礎的な原理は、移動コンピューティング実施に限定されない。例えば、デスクトップ又はワークステーションコンピュータを含む幾つかの実施形態に実質上いかなる形式のクライアント又はピアデータ処理装置を使用してもよい。従って、本発明の精神及び範囲は、特許請求の範囲において判断されるべきである。

【符号の説明】

【0315】

１００：データサービス
１１０：ＣＤＸサービス
１１１：マッチメーカーサービス
１１２：インビテーションサービス
１２０−１２３：移動装置
１２５−１２８：ローカルネットワークリンク
６０１：移動装置Ａ
６０３：移動装置Ｃ
６０５、６０６、６０７、６０８、６０９、６１０：通信リンク
６１０：ネットワーク
６１１、６１２、６１３、６１４：ＮＡＴ装置
６２０：プライベートネットワーク
１０５０：プッシュ通知サービス
１０５１：リレーサービス
１０５２：登録／ディレクトリサービス
１３００：リレールックアップサービス
１３０１：リレーホストデータベース
１３０２：リレーホストＡ
１３０３：リレーホストＢ
１５０１：マッチメーカーディスパッチャー
１５０２：要求テーブル
１５０３：ＭＳＩテーブル
１５１０：マッチメーカー
１５１２：データベース
１９１０：ＡＰＩ
１９１１：アプリケーション
１９１２：フレームワーク
１９１３：サービスＡＰＩ
１９２０：データベース
２０００：ゲームフレームワーク
２００１ａ：セキュアなＡＰＩ
２００１ｂ：パブリックＡＰＩ
２００３：通信バッファ
２００５：ＯＳ
２０１０：ゲームサービス
２０２０：ゲームデーモン
２０２１：キャッシュ
２０３０：アプリケーション
２０３１：ゲームセンター
２０５０、２０５１：サービス
２０５２、２０５３：プッシュ通知

【図1】

【図2a】

【図2b】

【図2c】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8a】

【図8b】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17a】

【図17b】

【図17c】

【図17d】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38a】

【図38b】