概略
セキュアなインスタントメッセージングのためのシステム及び方法について説明する。例えば、1つの実施形態において、第1ユーザは、第2ユーザのIDコードでインスタントメッセージングセッションをするために第2ユーザを識別する。それに応答して、第1ユーザには、第2ユーザのためのネットワーク情報と、第2ユーザに関連したパブリックキーとが与えられる。次いで、第1ユーザは、第2ユーザのパブリックキー及びプライベートキーを使用してインスタントメッセージを暗号化する。1つの実施形態において、第1ユーザは、第2ユーザのパブリックキーを使用してインスタントメッセージのコンテンツ(例えば、テキスト及び/又はアタッチメント)を暗号化し、そして第1ユーザのプライベートキーを使用してコンテンツに署名する。暗号化されたメッセージは、第1ユーザから第2ユーザへ送信される。次いで、第2ユーザは、第2ユーザのプライベートキーを使用してインスタントメッセージを解読し、第1ユーザのパブリックキーで署名を検証する。
好ましい実施形態の詳細な説明
ネットワークに一次及び/又はバックアップピア・ツー・ピア(“P2P”)通信チャンネルを確立し、維持しそして使用するための装置、方法及びマシン読み取り可能な媒体の実施形態を以下に述べる。P2Pセッションに対してユーザを招待しユーザを各々対戦させるためのインビテーションサービス及びマッチメーカーサービスについても説明する。加えて、ユーザがある特定の条件のもとでリレー接続を確立できるようにするためのリレーサービスについても説明する。最終的に、アプリケーション開発者が、ここに述べる種々の協力的オンライン特徴の利点を取り入れるアプリケーションを設計できるようにするためのアプリケーションフレームワーク及び関連アプリケーションプログラミングインターフェイス(API)についても説明する。
この説明全体を通して、説明の目的上、本発明を完全に理解するため多数の特定の細部について述べる。しかしながら、当業者であれば、幾つかのこれら特定の細部がなくても本発明を実施できることが明らかであろう。他の点については、本発明の基礎的な原理を不明瞭にしないため、良く知られた構造及び装置は、図示しないか、又はブロック図形態で示す。
接続データを効率的に且つセキュアに交換する装置及び方法
図1に示すように、本発明の一実施形態において具現化される一般的なネットワークトポロジーは、ネットワーク120を経て互いに且つ1つ以上のサービス110−112と通信する「クライアント」又は「ピア」移動コンピューティング装置A−D、各々、120−123のグループを備えている。図1に単一のネットワーククラウドとして示されているが、「ネットワーク」120は、幾つか挙げると、インターネットのようなパブリックネットワークと、ローカルWi−Fiネットワーク(例えば、802.11nホームワイヤレスネットワーク又はワイヤレスホットスポット)、ローカルエリアイーサネットネットワーク、セルラーデータネットワーク(例えば、3G、Edge、等)、及びWiMAXネットワークのようなプライベートネットワークを含む種々の異なるコンポーネントを包含する。例えば、移動装置A 120は、ネットワークリンク125で表されたホームWi−Fiネットワークに接続され、移動装置B 121は、ネットワークリンク126で表された3Gネットワーク(例えば、ユニバーサル移動テレコミュニケーションズシステム(UMTS)、高速アップリンクパケットアクセス(HSUPA)、等)に接続され、移動装置C 122は、ネットワークリンク127により表されたWiMAXネットワークに接続され、そして移動装置123は、ネットワークリンク128により表されたパブリックWi−Fiネットワークに接続される。移動装置120−123が接続されるローカルネットワークリンク125−128の各々は、ゲートウェイ及び/又はNAT装置(図1には示さず)を通してインターネットのようなパブリックネットワークに結合され、従って、パブリックネットワークを経て種々の移動装置120−123間で通信を行うことができる。しかしながら、2つの移動装置が同じ位置又はプライベートネットワーク(例えば、同じWi−Fiネットワーク)にある場合には、2つの装置は、パブリックネットワークをバイパスして、その位置/プライベートネットワークを経て直接通信することができる。もちろん、本発明の基礎的な原理は、ネットワーク形式又はネットワークトポロジーの特定セットに限定されないことに注意されたい。
図1に示す移動装置120−123の各々は、接続データ交換(CDX)サービス110、マッチメーカーサービス111及びインビテーションサービス112と通信することができる。1つの実施形態において、サービス110−112は、サーバーのような1つ以上の物理的コンピューティング装置にわたって実行されるソフトウェアとして具現化される。図1に示すように、1つの実施形態では、サービス110−112は、同じエンティティ(例えば、同じデータサービスプロバイダー)により管理され且つ各移動装置120−123によりネットワーク120を経てアクセスできるより大きなデータサービス100の環境内で具現化される。データサービス100は、種々の形式のサーバー及びデータベースを接続するローカルエリアネットワーク(例えば、イーサネットベースのLAN)を含む。又、データサービス100は、データを記憶するための1つ以上の記憶エリアネットワーク(SAN)も含む。1つの実施形態において、データベースは、移動装置120−123及びそれら装置のユーザの各々に関連したデータ(例えば、ユーザアカウントデータ、装置アカウントデータ、ユーザアプリケーションデータ、等)を記憶しそして管理する。
1つの実施形態において、マッチメーカーサービス111は、特定の1組の条件に基づいて協力的P2Pセッションに対して2つ以上の移動装置を対戦させることができる。例えば、2つ以上の移動装置のユーザは、特定のマルチプレーヤゲームをプレイすることに関心がある。そのようなケースでは、マッチメーカーサービス111は、各ユーザの専門レベル、各ユーザの年齢、対戦要求のタイミング、対戦が要求される特定のゲーム、及び種々のゲーム特有変数のような変数に基づいて、ゲームに参加する移動装置のグループを識別する。例えば、これに限定されないが、マッチメーカーサービス111は、特定ゲームのプレイに際して同様の経験レベルのユーザを対戦させるよう試みる。更に、大人は、他の大人と対戦され、そして子供は、他の子供と対戦される。更に、マッチメーカーサービス111は、ユーザの要求を、それら要求を受け取った順序に基づいてプライオリティ決めする。本発明の基礎的な原理は、特定の1組の対戦基準又は特定形式のP2Pアプリケーションに限定されない。
以下に詳細に述べるように、対戦要求に応答して、マッチメーカーサービス111は、全ての対戦参加者が効率的で且つセキュアな仕方でP2Pセッションを確立するに必要な接続データを受信するように保証するためにCDXサービス110と整合することができる。
1つの実施形態では、インビテーションサービス112は、協力的P2Pセッションに参加するための移動装置も識別する。しかしながら、インビテーションサービス112のケースでは、参加者の少なくとも1人が、別の参加者により特別に識別される。例えば、移動装置A 120のユーザは、移動装置B 121のユーザとの協力的セッションを特別に要求する(例えば、移動装置BをユーザID又は電話番号で識別する)。マッチメーカーサービス111の場合と同様に、インビテーション要求に応答して、インビテーションサービス112は、1組の参加者を識別し、そして全ての参加者が効率的で且つセキュアな仕方でP2Pセッションを確立するに必要な接続データを受信するように保証するためにCDXサービス110と整合することができる。
上述したように、1つの実施形態では、CDXサービス110は、2つ以上の移動装置間にP2Pセッションを確立するのに必要な接続データのための中央交換ポイントとして動作する。特に、CDXサービスの一実施形態は、移動装置の要求に応答してNAT横断データ(時々「ホールパンチ」データとも称される)を発生し、外部サービス及びクライアントが各移動装置のNATを通して通信できるようにする(即ち、NATを通して「ホールをパンチ」し、装置に届くようにする)。例えば、1つの実施形態では、CDXサービスは、移動装置と通信するのに必要な外部IPアドレス及びポートを検出し、そしてこの情報を移動装置に与える。又、1つの実施形態では、CDXサービスは、マッチメーカーサービス111及びインビテーションサービス112により発生された移動装置のリストを受信し処理して、接続データをそのリストに含まれた移動装置の各々に効率的に且つセキュアに配布する(以下に詳細に述べるように)。
1つの実施形態では、移動装置とCDXサービス110との間の通信は、ユーザデータグラムプロトコル(UDP)ソケットのような比較的軽い重みのネットワークプロトコルを使用して確立される。当業者に知られたように、UDPソケット接続は、パケット信頼性、順序又はデータ完全性を保証するためのハンドシェークダイアログを要求せず、それ故、TCPソケット接続と同程度の処理オーバーヘッドを消費することはない。従って、膨大な数のクライアントからの小さな問合せに応答するサーバーにとってUDPの軽い重みのステートレス特性が有用である。更に、TCPとは異なり、UDPは、(パケットがローカルネットワーク上の全ての装置へ送られる)パケットブロードキャスティング、及び(パケットがローカルネットワーク上の装置のサブセットへ送られる)マルチキャスティングと適合する。以下に述べるように、UDPが使用されても、セッションキーを使用してNAT横断データを暗号化することによりCDXサービス110にセキュリティを維持することができる。
CDXサービス110により使用される低オーバーヘッドで軽い重みのネットワークプロトコルとは対照的に、1つの実施形態では、移動装置120−123と、マッチメーカーサービス111及び/又はインビテーションサービス112との間の通信は、セキュアなソケットレイヤ(SSL)又はトランスポートレイヤセキュリティ(TLS)接続に依存するハイパーテキストトランスファープロトコルセキュア(HTTPS)のような本来的にセキュアなネットワークプロトコルで確立される。これらのプロトコルに関連した詳細は、当業者に良く知られている。
図2aは、CDXサーバーにより実施できる規範的な一連のトランザクションを示す。CDXサービスの一実施形態の動作を説明するとき、以下の用語は、次の意味をもつ。
接続データ:これは、潜在的なピアがピア・ツー・ピアセッションを確立するために互いに交換する必要のある情報である。この情報をどのように交換できるかのメカニズムの実施形態を以下に説明する。
CDXサーバー:一実施形態におけるCDXサーバーは、許可されたエンティティが任意のデータを交換するのを許す認証されたマルチキャストリフレクタである。このデータは、ペイロードと称される。
CDXセッション:CDXセッションは、CDXサーバーを経て互いに通信できるクライアント装置のグループを指す。セッションの一部分である各クライアント装置には、CDXチケットが指定される。各セッションは、個々のセッションを識別し又は参照するのに使用できる大きな整数である独特のCDXセッションIDを有する。
CDX要求:クライアント装置からCDXサーバーへ送信される要求である。この要求は、一般的に、2つの部分、即ちCDXチケット及びペイロードより成る。この実施形態では、ペイロードは、セッションキーで暗号化される接続データである。
CDX応答:CDX応答は、CDXサーバーがCDXセッションのメンバーからCDX要求を受信するときにCDXセッションにおいて他の装置へ「反射して」戻されるものである。これは、所与のCDX要求に使用されるCDXチケットのCDXチケットスタブにペイロードを添付することにより構成される。
CDXチケット:CDXチケットは、CDXセッションのメンバーにペイロードをどのように送信するかCDXサーバーに告げる。一実施形態では、偽造又は改竄を防止するためにCDXチケットキーで「署名」される。図3に示すように、一実施形態では、CDXチケットは、次の情報を含む。
一実施形態では暗号化もされず分かり難くもされないセッションID301。
一実施形態では暗号化もされず分かり難くもされないセッションにおける参加者302の数。
このチケットが参照する(一実施形態では暗号化もされず分かり難くもされない)セッションにおける参加者のインデックス303。
それ以降チケットが無効となると考えられる(一実施形態では暗号化もされず分かり難くもされない)満了日時304。
セッションの各参加者のためのもので、一実施形態ではCDXチケットキーを使用して暗号化されたCDXホールパンチデータ305−306。
CDXチケットキーを使用するメッセージ認証コード307であって、チケットが本物であることを保証するために「デジタル署名」として働くもの。
CDXチケットスタブ:CDXチケットの第1の部分から、CDXホールパンチデータ及びメッセージ認証コードを差し引いたもの。
ペイロード:これは、CDX要求及びCDX応答の第2の部分である。ペイロードは、クライアント装置がCDXセッションにおいて他の装置と通信することを望むデータである。この実施形態では、ペイロードは、接続データをセッションキーで暗号化したものである。CDXサーバーは、ペイロードを解読せず、一実施形態では、不変のまま通過させるだけである。
セッションキー:これは、接続データを暗号化するためにクライアントにより使用されるキーである。一実施形態では、このキーは、CDXサーバーに知られていない。この実施形態では、セッションキーは、マッチメークサービスにより発生され、そしてそれらの個々のCDXチケットと共にクライアントへ送信される。
CDXチケットキー:これは、CDXチケットを生成しそしてそれに「署名」するのに使用されるキーである。CDXチケットキーは、CDXサーバーと、CDXチケットを発生するサービス、即ち以下に述べるように、マッチメークサービス及び/又はインビテーションサービスとによって知られているだけである。
CDXホールパンチ要求:CDXサーバーからCDXホールパンチデータを得るのに使用されるCDX要求の特殊な形式。
CDXホールパンチデータ:これは、情報を最初に要求したクライアントにCDXサーバーがどのようにその情報を送信するか記述する不透明なデータブロブである。これは、CDXホールパンチ要求をCDXサーバーへ送信することにより得られる。CDXホールパンチデータは、CDXチケットを発生する前にCDXセッションにおいて各クライアント装置から収集されねばならない。CDXホールパンチデータ(時々「NAT横断データ」とも称される)は、要求側装置のパブリックIPアドレス及びポートを含む。
図2aを参照すれば、一実施形態において、移動装置A 120及び移動装置B 121は、1つ以上の他のコンピューティング装置とのP2P接続を要求するマルチプレーヤゲーム又は協力的チャットセッションのような協力的アプリケーションを実行することができる。201aにおいて、移動装置A 120は、CDXホールパンチ要求をCDXサーバー110へ送信する。CDXサーバー110は、次いで、202aにおいて、CDXホールパンチデータで応答する。1つの実施形態において、ホールパンチデータは、移動装置AのパブリックIPアドレス及びポート、及び/又は移動装置AのNATを通してホールをパンチするのに必要な他のデータ(例えば、移動装置AのNAT形式を定義するNAT形式データ)を含む。201b及び202bにおいて各々移動装置Bに対して同様のトランザクションが遂行される。
次いで、203a及び203bにおいて、移動装置A及びBは、CDXホールパンチデータを含む対戦要求を、付加的な対戦基準(以下に述べる)と共に、マッチメークサービスへ送信する。この段階において、移動装置A及びBは、P2P接続を確立するのに必要な接続データを構成し始める。これは、例えば、標準インターネット接続確立(ICE)トランザクションのようなトランザクションを使用して遂行される(例えば、NAT横断サービスにより)。しかしながら、本発明の基礎的な原理は、接続データを決定するための特定のメカニズムに限定されない。
1つの実施形態において、マッチメークサービス111は、対戦基準で1組のクライアント装置を見つけると、独特のCDXセッションIDと、CDXセッションのメンバーごとの独特のCDXチケットと、独特のセッションキーとを発生する。1つの実施形態では、マッチメークサービス111は、独特のCDXチケットキーを使用してCDXチケットに対してCDXホールパンチデータを暗号化する。次いで、204a及び204bにおいて、マッチメークサービスは、移動装置A及びBの各々にそれらのCDXチケット及びセッションキーを送信する。
移動装置Aは、CDXチケット及びセッションキーを受信し、そしてセッションキーを使用してその以前に決定された接続データを暗号化し、ペイロードを形成する。1つの実施形態では、移動装置Aは、形成されたペイロードをCDXチケットに添付することによりCDX要求を形成する。205aにおいて、移動装置Aは、CDX要求をCDXサーバー110へ送信する。又、移動装置Bは、同じ動作を遂行し、そして205bにおいてCDXサーバーへ要求を送信する。
206aにおいて、CDXサーバー110は、CDX要求を受信し、チケットを検査して、それが有効で且つ本物であるかどうか保証する(例えば、メッセージ認証コード307に基づいて)。CDXチケットが無効である場合には、要求がドロップされる。1つの実施形態では、CDXサーバーは、次いで、CDXチケットキーを使用して、CDXチケットに含まれたCDXホールパンチデータセットを解読する。1つの実施形態では、CDXチケットキーは、チケットと共に送信される満了日時も含む。CDXサーバー110及びマッチメーカーサービス111は、暗号/解読のために2つ(以上)の異なるCDXチケットキーを記憶し、その第1は、現在アクティブであり、そしてその第2は、第1のチケットキーの満了日時に到達したときにアクティブとなる。チケットを受信すると、CDXサービス110は、満了日時を読み取って、どのチケットキーを使用すべきか決定する。CDXチケットキーが満了になると、CDXサービス110及びマッチメーカーサービス111は、どちらも各々新たなチケットキーを発生する(それは、現在チケットキーが満了となった後に使用される次のキーである)。1つの実施形態では、CDXサービス110及びマッチメーカーサービス111は、2つのチケットキーとの一貫性を保証するために同じキー発生アルゴリズムを実行する。例えば、新たな認証コードが固定インターバルで発生される、良く知られたRSA SecurID認証メカニズムに使用されるもののような技術が使用されてもよい。1つの実施形態では、新たなCDXチケットキーが毎日発生される。しかしながら、本発明の基礎的な原理は、CDXチケットキーを発生するための特定のメカニズムに限定されない。
移動装置Bについては206bに示すように同じ動作を遂行することができる。CDXサーバーは、CDX要求からCDX応答を形成し、次いで、CDXホールパンチデータを使用して、CDX応答をCDXセッションの参加者へ送信する(207aでは移動装置Bへ及び207bでは移動装置Aへ送信する)。
移動装置Bは、CDXサーバーからCDX応答207aを受信する。クライアント装置Bは、CDXチケットスタブを検査し、セッションIDがそれ自身のCDXチケットのセッションIDに一致することを保証する。次いで、移動装置Bは、セッションキーを使用してペイロードを解読し、移動装置Aから接続データを発生させる。次いで、移動装置Bは、移動装置Aからの接続データを使用して、P2Pセッション確立プロセスを開始する。1つの実施形態では、これらは、標準ICEトランザクションを含む。しかしながら、本発明の基礎的な原理は、P2P通信を確立する特定のメカニズムに限定されない。
上述したように、1つの実施形態では、移動装置A及びBは、ハイパーテキストトランスファープロトコルセキュア(“HTTPS”)セッションを確立して、(例えば、HTTPS要求/応答トランザクションを使用して)マッチメーカーサービス111と通信すると共に、UDPソケットを確立して、CDXサービスと通信する。対戦要求204a、204bは、各移動装置について以前に決定されたNAT形式及びホールパンチデータ(例えば、パブリックIPアドレス及びポート)を含む。マルチプレーヤゲームを含む実施形態では、各対戦要求は、各移動装置のプレーヤ(例えば、独特のプレーヤIDコードを使用して)、各ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び/又は望ましいゲームに関連した他のゲーム構成変数を識別する。例えば、これに限定されないが、ゲームに関連したゲーム構成変数は、困難さのレベル(例えば、容易、普通、困難)、ユーザ年齢(例えば、13未満)、ゲームのサブ領域(例えば、レベル2)、及び/又はプレーヤの熟練度レベル(例えば、熟練者、初心者、中間者)を含む。以下に詳細に述べるように、これらの変数は、時々、ゲーム「バケット(bucket)」とも称され、独特の「バケットID」を使用して識別される。各ゲームは、異なるゲーム構成変数を識別するためにバケットIDの異なるセットを含む。
1つの実施形態では、移動装置Bは、208a及び209aにおいて送信及び確認を行う。同様に、移動装置Aの確認は、208b及び209bにおいて送信される。移動装置A又はBの確認が指定の期間後に受け取られない場合には、接続データ207aが移動装置B 212へ再送信される。CDXサービス110が再試みを開始するか、及び/又は移動装置A 120が再試みを開始する。
図2bは、3つの異なる移動装置120−122がCDXサービス及びマッチメーカーサービス111を使用してP2P接続についてネゴシエーションする詳細例を示す。又、図2bは、接続を確立するために移動装置120−122により使用される2つの付加的なサービス、即ちNAT形式を決定するためのNAT横断サービス291と、(例えば、ICE接続データトランザクションを利用して)各移動装置の全接続データを決定するためのNAT横断サービス290も示している。しかしながら、本発明の基礎的な原理に適合するための個別のサービスは要求されないことに注意されたい。例えば、別の実施形態では、これらサービス290−291の各々により遂行されるNAT横断機能は、CDXサービス110及び/又はマッチメーカーサービス111内に直接一体化されてもよい。同様に、両NAT横断サービス290−291によって遂行される機能も、単一のNAT横断サービス内に一体化されてもよい。要約すれば、本発明の基礎的な原理に適合するために図2bに示す特定の機能分離が要求されるのではない。
図2bの特定の細部を参照すれば、移動装置Aは、NAT形式の要求をNAT横断サービス291へ送信する。それに応答して、NAT横断サービス291は、一連のトランザクションを実施して、移動装置Aにより使用されるNAT形式を決定することを含む種々の既知の技術を使用することができる。例えば、NAT横断サービス291は、移動装置AのNATの異なるIPアドレス及びポートをオープンし、そして異なるIP/ポート組み合わせを使用してそれらのポートを経て移動装置Aと通信するように試みる。このように、移動装置Aによって使用されるNATは、上述したNAT形式(例えば、全コーン、制限コーン、ポート制限コーン、対称性)、或いは別のNAT形式の1つとして分類される。次いで、この情報は、図示されたように、移動装置A 120へ送られる。
221において、移動装置A 120は、CDXサービス110とでNAT横断要求を開始する。それに応答して、CDXサービス110は、要求に使用されるパブリックIPアドレス及びパブリックポート番号を読み取り、そしてその情報を移動装置A 120へ返送する。上述したように、装置がNATの後方にある場合には、そのパブリックポート及びIPアドレスが、各々、そのプライベートポート及びIPアドレスとは異なる。従って、使用されるNATの形式に基づいて、パブリックIPアドレス及びポートは、NAT装置を通して「ホールをパンチ」して、移動装置に到達するのに使用される。
222において、移動装置A 120は、対戦要求222をマッチメーカーサービス111へ送信する。上述したように、1つの実施形態では、移動装置Aは、ハイパーテキストトランスファープロトコルセキュア(“HTTPS”)セッションを使用して(例えば、HTTPS要求/応答トランザクションを使用して)、マッチメーカーサービス111と通信する。対戦要求は、移動装置A 120について以前に決定されたNAT形式及びホールパンチデータ(例えば、パブリックIPアドレス及びポート)を含む。マルチプレーヤゲームを含む実施形態では、対戦要求は、各移動装置Aのプレーヤ(例えば、独特のプレーヤIDコードを使用して)、ユーザがプレイしたいゲーム、ゲームに参加するプレーヤの人数、及び/又は望ましいゲームに関連した他のゲーム構成変数を識別する(図2aを参照して上述したように)。
223−225において、トランザクション220−222に対応する1組のトランザクションが移動装置B 121に対して遂行され、そして226−228において、トランザクション220−222に対応する1組のトランザクションが移動装置C 122について遂行される。従って、トランザクション228に続いて、マッチメーカーサービス111は、3つの移動装置120−122の前部に対して対戦要求を受け取る。この特定の例では、対戦要求の結果、移動装置120−122は、マルチプレーヤゲームのような特定の協力的セッションに対して対戦が組まれる(例えば、それら移動装置のユーザは、同じ又は同様の組の変数で同じゲームを選択し、従って、マッチメーカーサービス111により対戦が組まれる)。
マッチメーカーサービス111は、各対戦要求に含まれたデータを使用して、229において移動装置Aへ送信されるチケットA;230において移動装置Bへ送信されるチケットB;及び231において移動装置Cへ送信されるチケットC;を発生する。図2bには示されていないが、マッチメーカーサービス111は、プッシュ通知サービスを利用して、チケットA、B及びCを、各々、移動装置A、B及びCへとプッシュする(例えば、図11−12に示すプッシュ通知サービス1050のように)。チケットA、B及びCに使用されるチケットデータ構造の一実施形態は、図3を参照して上述した。
232において、移動装置A 120は、NAT横断サービス290と通信して、それ自身の接続データを決定する。1つの実施形態では、これは、標準ICE接続データトランザクションを含む。上述したように、接続データは、移動装置A 120に対するパブリック/プライベートIPアドレス、ポート及びNAT形式を含む。
移動装置A 120は、その接続データをチケットAに添付し、そして233において、チケットAを接続データと共に、CDXサービス110へ送信する。一実施形態では、CDXサービス110は、チケットAを上述したように処理し、そして234において、接続データ(暗号化されてもよい)を移動装置B 121及び移動装置C 122へ送信する。これらのトランザクションに対して、CDXサービス110は、チケットAと共に含まれる移動装置B及びCのNAT横断データを利用する。
236−238において、トランザクション232−234に対応する1組のトランザクションがチケットBを使用して遂行され、そして238−240において、トランザクション232−234に対応する1組のトランザクションがチケットCに対して遂行される。従って、トランザクション240に続いて、各移動装置120−122間に接続データが共有される。接続データを使用して、移動装置AとBとの間、移動装置AとCとの間及び移動装置AとCとの間にP2Pセッションが確立される。
図2cに示したように、インビテーションサービス112も、CDXサービス110に使用される(マッチメーカーサービス111に代わって又はそれに加えて)。1つの実施形態では、インビテーションサービス112は、特定の移動装置、及び/又はユーザとのP2P接続に対してインビテーション要求を処理する。インビテーションサービス112は、ステートレスサービス(即ち、各ワイヤレス装置間のトランザクションの現在状態をタックしないサービス)として実施することができる。
この特定例を参照すれば、250において、移動装置A 120は、NAT形式の要求をNAT横断サービス291へ送信する。それに応答して、NAT横断サービス291は、移動装置Aにより使用されるNAT形式を決定するために種々の既知の技術を使用する(その幾つかは、上述した)。251において、移動装置A 120は、CDXサービス110とでNAT横断要求を開始する。それに応答して、CDXサービス110は、その要求に使用されるパブリックIPアドレス及びパブリックポート番号を読み取り、そしてこの情報を移動装置A 120へ返送する。上述したように、装置がNATの後方にある場合には、そのパブリックポート及びIPアドレスは、各々、そのプライベートポート及びIPアドレスとは異なる。従って、使用されるNATの形式に基づいて、パブリックIPアドレス及びポートは、NAT装置を通して「ホールをパンチ」して、移動装置に到達するのに使用される。
マッチメーカーサービスの場合と同様に、1つの実施形態では、各移動装置は、ハイパーテキストトランスファープロトコルセキュア(“HTTPS”)セッションを使用して(例えば、HTTPS要求/応答トランザクションを使用して)、インビテーションサービス112と通信する。
252において、移動装置A 120は、移動装置AのNAT横断データ(例えば、NAT形式、パブリックIPアドレス/ポート)を含むインビテーション要求をインビテーションサービス112へ送信する。(以下に詳細に述べる)プッシュ通知サービスを利用する実施形態では、インビテーション要求は、移動装置Aのプッシュトークンも含む。又、インビテーション要求252は、1つ以上の他のユーザ/装置、このケースでは、移動装置B 121及びC 122のユーザを識別する識別コードも含む。種々の異なる識別コード形式が使用される。例えば、マルチプレーヤゲームのケースでは、識別コードは、ゲーム特有のプレーヤIDコードを含む。オーディオ/ビデオチャットセッションのケースでは、識別コードは、移動装置Aのユーザの「仲間(buddy)」リストから1人以上のユーザを識別する電話番号又は独特のIDコードを含む。
1つの実施形態では、インビテーションサービス112は、インビテーション要求から識別コードを読み取り、そして登録データベース(図示せず)においてルックアップを遂行して移動装置B及びCの各々を探索する。1つの特定の実施形態では、移動装置B及びCの各々は、インビテーションサービス112からプッシュ通知を受信するためにプッシュサービスに既に登録されている。従って、この実施形態では、インビテーションサービス112は、プッシュ通知サービスを使用して、253及び254においてインビテーション要求を移動装置B 121及び移動装置C 122へ各々プッシュする。プッシュ通知サービスに関連した付加的な詳細は、以下に説明する(例えば、図11−12及び関連テキストを参照)と共に、前記で参照したプッシュ通知アプリケーションに述べられている。
1つの実施形態において、インビテーション要求253及び254は、図3に示されて図2a−bを参照して述べたチケットデータ構造を含む。特に、移動装置Bへ送られるチケットは、移動装置A及びBを識別する暗号リストを含み、そして移動装置Cへ送られるチケットは、移動装置A及びCを識別する暗号リストを含む。1つの実施形態では、インビテーションサービス112が移動装置BのNAT横断データをまだもたないので、235における「チケット」は、移動装置Bを識別する他の情報を含む。例えば、リレーサービス及びプッシュ通知サービスを利用する実施形態を参照して以下に述べるように(例えば、図11−12を参照)、253における「チケット」は、移動装置AのNAT横断データ、装置AのIDコード、装置Aのプッシュトークン、装置BのIDコード、及び移動装置Bのプッシュトークンを含む。254において、移動装置A及びCに対して同じ形式の情報が与えられる。
255において、移動装置Bは、NAT横断サービス291と通信して、そのNAT形式を決定し、そして256において、移動装置Bは、CDXサービス110と通信して、そのNAT横断データ(例えば、パブリックIPアドレス/ポート)を決定する。257において、移動装置Bは、移動装置A及び移動装置Bの識別コード、NAT横断データ、及びプッシュ通知サービスが使用される場合には移動装置A及びBのプッシュトークンを含むインビテーション応答をインビテーションサービス112へ送信する。258において、移動装置Bは、NAT横断サービス290と通信することによりその現在接続データを検索する。259において、移動装置Bは、そのチケット(チケットB)をその現在接続データと共にCDXサービス110へ送信する。それに応答して、CDXサービス110は、上述したように、チケットを処理し、そして接続データを移動装置A 120へ転送する。
移動装置Bのインビテーション応答を受信すると、インビテーションサービス112は、移動装置Aのための暗号チケットを発生し、そしてそのチケットを260において移動装置Aへ送信する。1つの実施形態では、チケットは、NAT横断データ、NAT形式、並びに移動装置A及びBのプッシュトークン(プッシュ通知サービスが利用される場合)を含む。図2cを参照して述べる「チケット」は、マッチメーカーサービス111に関して述べる「チケット」のデータ構造と同じでもよいし異なってもよい。例えば、上述した暗号「チケット」発生するのではなく、インビテーションサービス112は、各移動装置とのインビテーションセッションを識別するために独特のセッションIDを発生するだけでよい。
261において、移動装置Aは、NAT横断サービス290と通信することによりその現在接続データを検索する。次いで、移動装置Aは、その接続データをチケットに添付し、そして262において、チケットをその接続データと共にCDXサービス110へ送信する。CDXサービス110は、上述したようにチケットを処理し、そして移動装置Aの接続データを移動装置Bへ転送する。最終的に、263において、移動装置A及びBは、交換した接続データを使用して、直接P2P接続をオープンする。以下に述べるように、移動装置A及びBのNAT形式が適合しない場合には、リレーサービスを利用して、移動装置AとBとの間の通信を行うことができる。
264−272において、移動装置C 122及び移動装置Aは、移動装置B及びAについて255−263で述べたように、P2P接続を確立するために一連のトランザクションを実行する。より詳細には、624において、移動装置C 122は、NAT横断サービス291と通信して、そのNAT形式を決定し、そして265において、CDXサービス110と通信して、そのNAT横断データを決定する(例えば、パブリックIPアドレス/ポート)。266において、移動装置Cは、移動装置C及び移動装置AのNAT形式、NAT横断データ及びプッシュトークン(プッシュ通知サービスが利用される場合)を含むインビテーション応答を送信する。267において、移動装置Cは、NAT横断P2Pサービス290を通してその現在接続データを検索し、そして268において、移動装置Cは、その接続データをチケットCに添付して、チケットCをCDXサービス110へ送信する。CDXサービス110は、上述したようにチケットを処理し、そして移動装置Cの接続データを移動装置A 120へ転送する。
269において、移動装置A 120は、両移動装置A及びCのNAT形式、NAT横断データ及びプッシュトークン(プッシュ通知サービスが利用される場合)を含むインビテーションサービス112からの移動装置Cのインビテーション応答を受信する。270において、移動装置Aは、NAT横断サービス290からその現在接続データを検索し、その現在接続データをチケットAに添付し、そして271において、チケットAをCDXサービス110へ送信する。或いは又、移動装置がその接続データをトランザクション261において決定するので、トランザクション270は必要とされなくてもよい。CDXサービス110は、上述したようにチケットAを処理し、そして移動装置Aの接続データを移動装置Cへ転送する。最後に、272において、移動装置A及びCは、交換した接続データを使用して、直接的なP2P接続272を確立する。
1つの実施形態において、インビテーションサービス112及びマッチメーカーサービス111は、移動装置へデータをプッシュするためにプッシュ通知サービス(図示せず)に依存する。例えば、図2cにおいて、インビテーション要求253及び254がプッシュ通知サービスを経て移動装置B 121及びC 122へプッシュされる。同様に、図2aでは、チケットA及びBは、移動装置A 120及びB 121へプッシュされる。1つの実施形態において、移動装置は、それがネットワークにおいてアクチベートされると、そのプッシュトークンを、プッシュ通知サービスによりアクセスできる中央登録ディレクトリに登録する。1つの実施形態では、登録ディレクトリは、パスワード保護されたユーザID又は電話番号をプッシュトークンに関連付ける。ディレクトリにおいてプッシュトークンを識別できる場合には、プッシュ通知サービスがそのプッシュトークンを使用してプッシュ通知を移動装置へ送信する。1つの実施形態では、プッシュ通知サービスは、本出願の譲受人により設計されて、例えば、前記で参照された「プッシュ通知アプリケーション」に述べられた「アップル(R)プッシュ通知サービス(APNS)」である。しかしながら、プッシュ通知サービスは、図2a−cに示す本発明の実施形態では必要とされないことに注意されたい。例えば、CDXサービス110がここに述べる動作を遂行するためにプッシュ通知が要求されることはない。
図4は、接続データを交換するためにCDXサービス110により具現化される方法を示し、そして図5は、接続データを交換してP2P接続を確立するために移動装置により具現化される方法を示す。これら方法の幾つかの観点は、図1−2cを参照して既に上述した。特に、これらの方法は、図1−2cに示すネットワークアーキテクチャーに関して具現化されるが、そのようなアーキテクチャーに限定されない。1つの実施形態において、それらの方法は、プロセッサにより実行されたときに、それら方法の動作を遂行するようにさせるプログラムコードで実施される。そのプログラムコードは、プロセッサにより実行される間にランダムアクセスメモリ(RAM)のようなマシン読み取り可能な媒体に記憶される。プロセッサは、汎用プロセッサ(例えば、Intel Core(登録商標)プロセッサ)又は特殊目的プロセッサである。しかしながら、これらの方法は、ハードウェア、ソフトウェア及びファームウェアの組み合わせを使用して具現化される。更に、プログラムコードは、ハードディスクドライブ、光学的ディスク(例えば、デジタルビデオディスク又はコンパクトディスク)、又はフラッシュメモリ装置のような不揮発性メモリに記憶される。
図4に示す方法を参照すれば、401において、特定の移動装置、この例では、「移動装置A」に対してNAT横断要求(時々「ホールパンチ」要求とも称される)が受信される。402において、NAT横断応答が発生されて、移動装置Aへ送信される。1つの実施形態では、NAT横断応答を発生することは、移動装置Aの現在パブリックIPアドレス/ポート及び/又はNAT形式を決定することを含む。
移動装置Aのチケットは、その後、上述したマッチメーカーサービス111又はインビテーションサービス112のようなチケット発生エンティティにより発生されて暗号化される。403において、NAT横断データ(装置A及び1つ以上の他の装置の)及び装置Aの接続データを含む、移動装置Aに対して発生されたチケット(チケットA)が受信される。404において、メッセージ認証コードを使用してチケットが認証され、そしてチケットの暗号化のためにチケット発生エンティティにより使用されたものと同じCDXチケットキーを使用してホールパンチデータが解読される。上述したように、1つの実施形態では、CDXチケットキーに関連した満了日時を使用して正しいCDXチケットキーが識別される。
405において、移動装置のNAT横断データが抽出される。406において、NAT横断データを使用して移動装置Aの接続データが各ピアへ送信される。407において、各ピアから確認が受信される。408において、全てのピアから確認が受信されていないことが決定されると、移動装置Aの接続データが、409において、応答していないピアへ再送信される。全ての接続データが確認されたことが408において決定されると、この方法は、終了となる。
1つの実施形態において、図4に示す方法は、各ピアがP2P接続の確立に必要な接続データを受信することを保証するためにP2Pトランザクションに含まれる各ピアに対して遂行することができる。
図5は、ここに述べる本発明の実施形態により移動装置により遂行できる方法を示す。501において、NAT横断要求が送信され、そして502において、NAT横断応答が受信される。先に述べたように、応答に含まれるNAT横断データは、要求側装置のパブリックポート/IPアドレスを含む。503において、NAT横断データを含む対戦要求が送信される。その後、上述したマッチメーカーサービス111又はインビテーションサービス112のようなチケット発生エンティティにより移動装置のチケットが発生されて暗号化される。上述したチケットデータ構造とは別に、マッチメーカーサービス111及び/又はインビテーションサービス112は、独特のセッションIDを使用して各参加者を単に識別するだけである。
504において、チケットが受信され;505において、移動装置の接続データがチケットに添付され;506において、接続データを伴うチケットが送信される。507において、1つ以上の他のピアとP2P接続を確立するのに必要な接続データが受信される。508において、506で送信された接続データを1つ以上の他のワイヤレス装置が受信したことを示す確認が受け取られる。全ての確認が受け取られない場合には、510において、確認が受け取られなかった移動装置へ接続データが再送信される。全ての確認が受け取られたことが509において決定されると、507で受け取られた接続データを使用して、他の移動装置とのP2Pセッションが確立される。
バックアップ通信チャンネルを確立して使用する装置及び方法
現在の移動装置は、種々の異なる通信チャンネルを経て通信を行うことができる。例えば、アップル(R)iPhoneTM(登録商標)は、Wi−Fiネットワーク(例えば、802.11b、g、n ネットワーク);3Gネットワーク(例えば、ユニバーサル移動テレコミュニケーションズシステム(UMTS)ネットワーク、高速アップリンクパケットアクセス(HSUPA)ネットワーク、等);及びBluetooth(登録商標)ネットワーク(パーソナルエリアネットワーク(PAN)としても知られている)を経て通信することができる。将来の移動装置は、幾つか挙げると、WiMAX、インターナショナル移動テレコミュニケーション(IMT)アドバンスト、及び長期進化(LTE)アドバンストのような付加的な通信チャンネルを経て通信を行うことができる。
動作中に、現在の移動装置は、1組の利用可能なチャンネルの中から1つの一次通信チャンネルを選択する。例えば、移動装置は、Wi−Fi接続が利用できる場合にはそれを選択し、そしてWi−Fiが利用できない場合にはセルラーデータ接続(例えば、UTMS接続)を選択するようにしばしば構成される。
本発明の1つの実施形態では、移動装置のグループは、最初、標準的ICE接続データ交換を使用し及び/又は上述した接続データ交換技術を使用して、一次ピア・ツー・ピア(P2P)通信チャンネルを確立する。次いで、移動装置は、一次チャンネルを経て接続データを交換して1つ以上の二次通信チャンネルを確立し、このチャンネルは、いずれかの一次チャンネルが失敗となった場合にバックアップチャンネルとして使用される。1つの実施形態において、二次通信チャンネルは、それらのチャンネルを経て「心鼓動」パケットを周期的に送信することにより、NATファイアウオールを通してオープンに維持される。
ここで使用する通信「チャンネル」とは、2つの移動装置間の完全なネットワーク経路を指し、そして通信「リンク」とは、通信経路に使用される1つの特定の接続を指す。例えば、装置AがWi−Fi接続を使用してインターネットに接続され、そして装置Bが3G接続を使用してインターネットに接続された場合には、装置Aと装置Bとの間の「チャンネル」は、Wi−Fiリンク及び3Gリンクの両方により定義され、装置Aは、Wi−Fi通信「リンク」を有し、そして装置Bは、3G通信「リンク」を有する。従って、装置AがWi−Fiリンクから3Gリンクへスイッチする場合には、装置Bの3Gリンクが同じままであるにも関わらず、装置Aと装置Bとの間の「チャンネル」が変更される。
移動装置が一次及び二次通信チャンネルを確立する特定の例を、図6を参照して以下に述べる。しかしながら、本発明の基礎的な原理は、図6に示す通信リンク及び通信チャンネルの特定セットに限定されないことに注意されたい。
図6において、移動装置A 601は、NAT装置611との通信リンク605を経て及びNAT装置612との通信リンク606を経てネットワーク610(例えば、インターネット)に接続することができる。同様に、装置C 603も、NAT装置613との通信リンク609を経て及びNAT装置614との通信リンク610を経てネットワーク610に接続することができる。例えば、これに限定されないが、通信リンク605及び609は、3G通知ンリンクであり、通知ンリンク606及び610は、Wi−Fi通信リンクである。
従って、この例では、移動装置Aと移動装置Bとの間には、リンク605及び609を使用する第1のチャンネル、リンク605及び610を使用する第2のチャンネル、リンク606及び609を使用する第3のチャンネル、並びにリンク606及び610を使用する第4のチャンネル、の4つの異なる通信チャンネルが確立される。1つの実施形態において、移動装置A及びBは、これらチャンネルの1つを、プライオリティ決めスキームに基づいて一次通信チャンネルとして選択し、そして3つの残りのチャンネルをバックアップ通知ンチャンネルとして選択する。例えば、1つのプライオリティ決めスキームは、最も高い帯域巾をもつチャンネルを一次チャンネルとして選択し、そして残りのチャンネルを二次チャンネルとして使用する。2つ以上のチャンネルが同等の帯域巾を有する場合には、優先順位決めスキームは、最も安価なチャンネルを選択することを含む(1つ以上のチャンネルを使用するためにユーザが料金を支払うと仮定すれば)。或いは又、プライオリティ決めスキームは、最も安価なチャンネルを一次チャンネルとして選択し、そして各チャンネルのコストが同じ場合には、最も高い帯域巾のチャンネルを選択する。本発明の基礎的な原理に適合しながら、種々の異なるプライオリティ決めスキームを具現化することができる。
移動装置A 601及びC 603は、上述した技術を使用して、一次通信チャンネルを確立する(例えば、CDXサービス110を経て接続データを交換することにより)。或いは又、移動装置601、603は、標準的インターネット接続確立(ICE)トランザクションを具現化して、接続データを交換することもできる。一次チャンネルをどのように確立するかに関わらず、それが確立されると、移動装置A 601及びC 603は、一次通信チャンネルを経て二次通信チャンネルのための接続データを交換する。例えば、図6の一次通信チャンネルが通信リンク606及び通信リンク609を含む場合には、この接続が確立されると、それを使用して、通信リンク605及び609を含む二次通信チャンネルの接続データを交換する。この例では、一次通信チャンネルを経て交換される接続データは、各移動装置のパブリック及びプライベートIPアドレス/ポートを含めて、NAT611及びNAT613のNAT横断データ及びNAT形式データを含む。
二次通信チャンネルが確立されると、それらは、心鼓動パケットを使用してオープンに維持される。例えば、装置Aは、小さな「心鼓動」パケットを装置Cへ周期的に送信し、及び/又は装置Aは、二次チャンネルに使用されるNATポートがオープンのままであるよう保証するために小さな「心鼓動」パケットを装置Cへ周期的に送信する(NATは、インアクティビティによりポートをしばしばクローズする)。心鼓動パケットは、ペイロードを伴わないUDPパケットであるが、本発明の基礎的な原理は、特定のパケットフォーマットに限定されない。心鼓動パケットは、それらのペイロードヘッダに自己識別形式のフィールドを伴うUDPパケットであり、これに限定されないが、チャンネル生存時間(time-to-live)値を含む任意に付加的にフォーマットされる情報を含む。
図7に示すように、各移動装置601は、一次及び二次通信チャンネルのリストを含むデータ構造体710(例えば、テーブル、テキストファイル、データベース、等)を記憶し維持する。通信チャンネルごとに個別のエントリが設けられ、これは、そのチャンネルを使用するのに必要な接続データ(例えば、プライベート/パブリックIPアドレス、NAT形式、等)と、そのチャンネルの現在状態(例えば、一次、二次1、二次2、等)を含む。
1つの実施形態では、通信リンク605及び通信リンク606を経て各々通信するために通信インターフェイス701及び702が使用される。特定の通信インターフェイス/リンクが失敗となるか又は指定スレッシュホールドより下がったときを検出するために、移動装置601において欠陥検出モジュール705を実行することができる。それに応答して、リンクマネージメントモジュール706は、一次/二次接続データ710を読み取り、次に最も高いプライオリティを有する二次チャンネルを一次チャンネルへ昇進させる。二次チャンネルのプライオリティ決めは、一次チャンネルについて上述したものと同じ原理を使用して遂行される(例えば、帯域巾、コスト、信頼性、等)。二次チャンネルが選択されると、リンクマネージメントモジュール706は、他の移動装置のリンクマネージメントモジュールへリンク欠陥指示を送信して、それらの装置に、二次通信チャンネルを一次通信チャンネルへ昇進させるよう命令する。次いで、それらの装置は、選択された一次チャンネルに関連した接続データの使用を開始する。
1つの実施形態では、二次通信チャンネルの1つへの切り換えを強制するのに一次通信チャンネルの完全な「欠陥」が要求されるのではない。例えば、一実施形態では、一次通信チャンネルが充分に質低下した場合に(例えば、特定の帯域巾、ビットレート又は信頼性スレッシュホールドより低く)、ここに述べるように、二次チャンネルへの切り換えが実施される。一実施形態では、二次チャンネルへの切り換えは、二次チャンネルが現在の一次チャンネルより優れた性能(例えば、帯域巾、ビットレート又は信頼性)をサポートできる場合にしか遂行されない。
図8aは、図6に示された同じネットワーク構成を示すが、ネットワーク610に直接接続されると共にプライベートネットワーク接続620を通して装置C 603にも接続された移動装置B 602が追加されている。プライベートネットワーク620は、例えば、装置B 602と装置C 603との間のBluetooth(登録商標) PAN接続である。この例から、一次チャンネルから二次チャンネルへの切り換えは、ネットワークトポロジーを劇的に変化させることが明らかである。例えば、図8bに示すように、移動装置の一次チャンネル801が通信リンク609を含み(装置AとBとCとの間に直接的な接続を生じる)、そして二次チャンネルがプライベートネットワーク620を含む場合には、ネットワークトポロジーは、図8cに示すように変化する。というのは、装置A及び装置Cがプライベートネットワークを使用して通信する唯一の方法は、装置Bを通ることだからである。これは、装置が3つだけの簡単な例であるが、著しく多数の装置を使用すると、一次通信チャンネルと二次通信チャンネルとの間を切り換えるときには種々の異なるネットワークトポロジー構成が生じ得る。
二次チャンネルを確立して維持する方法の1つの実施形態が図8に示されている。1つの実施形態において、この方法は、各移動装置のリンクマネージメントモジュール706により実行される。しかしながら、この方法は、特定の装置構成に限定されない。
901において、一次P2P通信チャンネルが選択される。上述したように、一次チャンネルは、既定のプライオリティ決めスキームに基づいて選択される。例えば、ある通信チャンネル形式が、他の通信チャンネル形式に先行してプライオリティ決めされる。又、チャンネルは、帯域巾、使用コスト、及び/又は信頼性に基づいてプライオリティ決めされてもよい。
902において、バックアップP2P通信チャンネルが確立される。1つの実施形態では、これは、一次通信チャンネルにわたり全ての移動装置間で接続データを共有することにより達成される。903において、バックアップチャンネルが維持される。1つの実施形態では、これは、二次通信チャンネルを経てデータを周期的に送信することを含む(例えば、周期的な心鼓動パケットの形態で)。
904において、一次P2Pチャンネルが失敗となった場合には(例えば、特定の移動装置の通信リンクがダウンするか、又は移動装置が通信リンクの範囲から出たために)、905において、移動装置は、プライオリティの最も高いバックアップチャンネルを一次チャンネルへ昇進させる。1つの実施形態では、これは、リンクが失敗となった移動装置が、そのリンク欠陥の通知を、二次チャンネルを経て他の装置へ送信することを含む。最終的に、906において、バックアップチャンネルが一次チャンネルとなり、そしてプロセスが902へ戻る(付加的なバックアップチャンネルが発見されて、プライオリティ決めスキームに追加される)。
ピア・ツー・ピア(P2P)通信チャンネルを確立するインビテーションサービスのための装置及び方法
図10に示すように、CDXサービス110、マッチメーカーサービス111及びインビテーションサービス112(その幾つかの実施形態を上述した)に加えて、本発明の一実施形態には、登録/ディレクトリサービス1052、プッシュ通知サービス1050、及びリレーサービス1051が含まれる。上述したように、一実施形態では、インビテーションサービス112及び/又はマッチメーカーサービス111は、登録/ディレクトリサービス1052を使用して、登録された移動装置を識別すると共に、プッシュ通知サービス1050を使用して、移動装置へデータをプッシュする。一実施形態では、移動装置は、ネットワークにおいてアクチベートされると、「プッシュトークン」(プッシュ通知アプリケーションにおいて「通知サービスアカウント識別子」とも称される)を、登録/ディレクトリサービス1052により維持されたデータベースに登録し、これは、そのプッシュトークンをパスワード保護ユーザID又は電話番号に関連付けることで行われる。プッシュトークンが登録ディレクトリにおいて識別される場合には(例えば、ユーザIDで問合せを行うことで)、プッシュ通知サービス1050がそのプッシュトークンを使用して、プッシュ通知を移動装置に送信することができる。1つの実施形態では、プッシュ通知サービスは、本出願の譲受人によって設計されて、例えば、前記で参照したプッシュ通知アプリケーションに述べられたアップル(R)プッシュ通知サービス(APNS)である。
図11は、プッシュ通知サービス1051を使用して2つの移動装置間に直接的なP2P接続を確立する本発明の実施形態を示し、そして図12は、リレーサービス1051を通してP2P接続を確立するのに使用される実施形態を示す。以下に述べるように、リレーサービス1051を使用してP2P接続を確立すべきかどうかの判断は、移動装置間に直接的なP2P接続を確立する実現性に基づく(例えば、NAT互換性の問題に基づく)。
図11を参照すれば、1101において、移動装置A 120は、移動装置B 121をP2P通信セッション(例えば、協力的ビデオゲーム、P2Pビデオチャット、等)に招待するために、移動装置Bを招待するインビテーションを送信する。1つの実施形態において、インビテーションは、特定のオンラインアプリケーションの環境内で移動装置B121(及び/又は移動装置Bのユーザ)を識別するユーザIDコードを含む。例えば、ユーザIDコードは、特定のマルチプレーヤ、P2PゲームのためのプレーヤIDであり、例えば、ユニバーサルユニーク識別子(UUID)の形態をとる。或いは又、ある実施形態では、IDコードは、移動装置B 121の電話番号でもよい。移動装置Aが移動装置Bの参加を招待するマルチプレーヤゲームを識別するためにゲームIDコードが使用される。そのゲームのための構成を識別するためにバケットIDが使用される(マッチメーカーサービスについて説明したように)。
インビテーション1101は、移動装置A 120を識別するIDコードと、移動装置Aに関連したNAT横断/接続データ(例えば、移動装置Aのためのパブリック/プライベートIPアドレス及びポートや、装置AのNAT装置のNAT形式)も含む。NAT横断/接続データ又はNAT形式データは、インビテーション要求1101の前に移動装置Aにより事前に決定されてもよい(例えば、図2a−cを参照して上述したもののようなNAT横断、NAT形式及び接続データトランザクションを経て)。上述したように、インビテーション要求1101は、HTTPS要求の形態をとる。更に、付加的なセキュリティのために、インビテーション要求1101は、予め指定された証明書当局により署名されたクライアント証明書を含むことができる。
移動装置Bを識別するのに使用されるIDコードの特定形式に関わらず、IDコードは、インビテーションサービスにより受け取られ、そして1102において、インビテーションサービス112は、ディレクトリサービス1052(図11には示さず)においてルックアップを遂行し、移動装置Bへ通知をプッシュするのに使用されるプッシュトークン(プッシュトークンB)のような通知サービスアカウント識別子を識別する。1つの実施形態において、ルックアップ動作は、インビテーションを許すべきかどうか決定するために多数のチェックを遂行する。先ず、移動装置Aの識別コード(ID−A)及び装置Aのプッシュトークン(プッシュトークンA)がディレクトリサービスデータベース内の登録関連性であることを確認することができる。又、ルックアップ動作1102は、移動装置Aのユーザが移動装置Bのユーザを招待することが許されたことも確認できる(例えば、移動装置Bのユーザは、Bの友人として登録された他のユーザしかユーザBを招待できないことを指定するか、又は招待が許されないことを指定する)。1つの実施形態において、これらチェックのいずれかが失敗となった場合には、インビテーションがキャンセルされ、インビテーションサービス112は、移動装置Aにエラーを返送する。
この実施形態では「プッシュトークン」を説明するが、本発明の基礎的な原理は、「プッシュトークン」の使用や、移動装置を認証して通知をプッシュするための他の特定のデータ構造に限定されないことに注意されたい。
1つの実施形態において、プッシュトークンが識別された後に、インビテーションサービス112は、インビテーションセッションに指定されて全ての更に別のトランザクションにおいてセッションを識別するのに使用されるセキュアな一回限りの「セッショントークン」を発生することができる。次いで、セッショントークンのコピーが、移動装置A 120へ返送されると共に、インビテーション要求と共に移動装置Bへ送られる。1つの実施形態では、セッショントークンは、上述したチケットデータ構造体と一緒に使用され、そして別の実施形態では、セッショントークンのみが使用される。
1103において、インビテーションサービス112は、プッシュ通知サービス1050にプッシュ要求を送信する。1つの実施形態において、プッシュ要求は、移動装置AのNAT横断データ、装置AのIDコード、プッシュトークンA、装置BのIDコード、及びプッシュトークンBを含む。1つの実施形態において、この情報は、「チケット」データ構造体内にパッケージされ、そして上述したように暗号化される。別の実施形態では、データは、単に、インビテーションセッションIDと共に送信される。
この例の移動装置B 121は、プッシュ通知サービス1050に登録されるので、プッシュ通知サービス1050は、1104において、インビテーション要求を探索して、移動装置B 121へプッシュすることができる。プッシュされたインビテーション1104は、セッショントークン、移動装置AのNAT横断データ/接続データ、及び移動装置BのIDコードを含む。インビテーション要求に応答して、移動装置Bは、上述したように、NAT横断サービス又はCDXサービス110へコールをなすことによりそのネットワーク情報(例えば、NAT横断/接続データ、NAT形式、等)を決定する。
1105において、移動装置Bがインビテーションを受け容れる。この受け容れは、インビテーションサービス112へのHTTPコールの形態をとり、事前に指定された証明書当局により署名されたクライアント証明書を含む(インビテーション要求に関して上述した)。1つの実施形態では、受け容れ1105は、移動装置A及びBのIDコードと、移動装置A及びBのNAT横断/接続データ及び/又はNAT形式とを含む。又、受け容れ1105は、移動装置A及びBのプッシュトークン、及び/又はセッショントークンも含む。1つの実施形態では、受け容れ1105は、それが以前に失敗した直接接続試みからの再試みであるかどうかの指示も含む。しかしながら、別の実施形態では、受け容れ1105は、再試みの指示を含まない。むしろ、失敗したP2P接続の試みを検出すると、2つの移動装置の一方が特殊な「リレーインビテーション」をインビテーションサービス112へ送信する。それに応答して、そのサービスは、図12を参照して以下に説明する一連のリレートランザクション(1201でスタートする)を直接開始する。
1106において、インビテーションサービス112は、適合性チェックを遂行して、移動装置AとBとの間の直接的P2P接続が実現可能であるかどうか決定する。例えば、1つの実施形態では、受け容れ1105が移動装置Bから受け取られて、それが以前に失敗した直接接続試みからの再試みである(又は指定数の以前に失敗した直接接続試みである)ことを示す場合には、インビテーションサービスは、直接的P2P接続が実現不能であると結論付ける。インビテーションサービス112は、移動装置A及びBのNAT形式データを比較して、移動装置A及びBのNAT装置が直接的P2P接続をサポートするかどうか決定する。NAT形式のある組み合わせは、P2P接続を確立するのに不適合であることが知られている。例えば、全コーンNATは、直接的P2P接続を確立するためにクローズ/ファイアウオール型NAT以外のNAT形式と共に使用される。これとは対照的に、直接的P2P接続を確立するために全コーンNATと共に使用できるのは、対称性NATだけである。本発明の1つの実施形態において種々のNAT形式を結合する実現性が、図14のNAT適合性テーブル1400に示されており、ここで、列は、一方の移動装置(例えば、移動装置A)のNAT形式を表わし、そして行は、他方の移動装置(例えば、移動装置B)のNAT形式を表わす。セルにおける“1.0”は、関連する行及び列のNAT形式が適合できることを示し、そして“0.0”は、NAT形式が不適合であることを示す。
1つの実施形態において、直接的P2P接続が実現不能であることが適合性チェック1106で決定されると、インビテーションサービス112は、図12を参照して以下に述べるように、リレールックアップ要求1201を送信する。しかしながら、直接的P2P接続が実現可能であることが適合性チェック1106で決定されると、インビテーションサービス112は、移動装置Aのインビテーションを移動装置Bが受け容れることを含むプッシュ要求1107をプッシュ通知サービス1050へ送信する。プッシュ要求1107と、プッシュ通知サービス1050から移動装置Aへのその後のプッシュ通信1108は、セッショントークン、両移動装置A及びBのプッシュトークン、IDコード、及び/又はNAT横断/接続データを含む。1つの実施形態において、この情報は、上述した「チケット」データ構造体内にパックされ(例えば、図2a−c及び関連テキストを参照)、そして独特のキーを使用して暗号化される。或いは又、この情報は、単に、独特のインビテーションセッションIDと共に送信されてもよい。又、インビテーションサービス1050は、直接接続が試みられることを移動装置Bに通知することもできる。
この段階において、移動装置A及びBは、直接的P2P接続を確立するに充分な情報を有する。1つの実施形態では、これは、上述したCDXサービス110を使用して達成される。例えば、移動装置Bは、その接続データをチケットBに添付し、そして1109において、チケットBを(接続データと共に)CDXサービスへ送信する。このトランザクションの直前に、移動装置Bは、その接続データが現在のものであることを保証するために、図2bに示すトランザクション235のようなトランザクションを実施する。次いで、CDXサービス110は、チケットを認証し(例えば、上述した独特のセッションキーを使用して)、移動装置Bの接続データを抽出し、そしてその接続データを1110において移動装置Aへ転送する。同様に、移動装置Aは、その接続データをチケットAに添付し、そして1111において、チケットAを(接続データと共に)CDXサービス110へ送信する。このトランザクションの直前に、移動装置Aは、その接続データが現在のものであることを保証するために、図2bに示すトランザクション232のようなトランザクションを実施する。次いで、CDXサービス110は、チケットを認証し(例えば、上述した独特のセッションキーを使用して)、移動装置Aの接続データを抽出し、そしてその接続データを1112において移動装置Bへ転送する。最終的に、1113において、移動装置A及びBは、交換した接続データを使用して直接的P2P接続へ入る。
図12を参照すれば、直接的P2P接続が実現不能であることが適合性チェック1106で決定されると、インビテーションサービス112は、リレールックアップ要求1201をリレーサービス1051へ送信して、各移動装置によって使用されるリレーホストを決定する。要求1201は、移動装置A及びBからのネットワーク情報(例えば、NAT横断/接続データ及び/又はNAT形式データ)を含み、これは、両移動装置に適したリレーホストを選択するためにリレーサービス1051により使用される。図13に示すように、リレーサービス1051の一実施形態は、複数のリレーホスト1302−1303と、各リレーホストに関連したネットワーク情報を含むリレーホストデータベース1301とを含む。インビテーションサービス112は、リレールックアップ要求1201をリレールックアップサービス1300へ送信し、これは、移動装置A及びBのネットワーク情報を使用してリレーホストデータベース1301に問合せする。データベースの結果を受け取ると、リレールックアップサービス1300は、選択されたリレーホスト1302−1303を識別する応答1202を与える。
1つの実施形態において、リレールックアップ応答1202は、リレーサービスにより発生されるリレートークンと、リレー接続のために移動装置A及びBにより使用されるリレーホスト1302−1303のネットワークアドレス(IPアドレス/ポート)とを含む。1つの実施形態では、リレートークンは、リレーセッションに関連され、そしてリレーサービス1051に接続するときに移動装置A及びBを認証するためにリレーホスト1302−1303により使用される。トークンは、例えば、独特のIDリレーセッションIDコード、デジタル証明書、及び/又はリレーセッションに関連した独特の暗号キーを含む種々の形態で得られる。
1203において、インビテーションサービスは、リレー接続がなされるという指示を含むリレー応答1203を移動装置B 121へ送信する。1つの実施形態では、リレー応答1203は、リレートークン、及びリレーホストB 1303のためのネットワーク情報を含む。1つの実施形態では、応答1203は、(プッシュ通知サービス1050をバイパスして)移動装置Bへ直接送信される。というのは、それが移動装置Bの受け容れ1105に応答して送信されるからである。
インビテーションサービス112は、リレートークン、及びリレーホストB 1303のネットワーク情報を含むリレー応答1204を移動装置Aへ送信する。この例では、応答1204は、トランザクション1205においてプッシュ通知サービス1050を経て移動装置Aへプッシュされる。
1206において、移動装置A 120は、リレーホストA 1302のネットワーク情報を使用して、リレーサービス1051との接続を確立する。同様に、1207において、移動装置B 121は、リレーホストB 1303のネットワーク情報を使用して、リレーサービス1051との接続を確立する。これらトランザクションの各々において、移動装置A及びBのNATファイアウオールに新たなホールが開けられ、そして移動装置A及びBのNAT横断/接続データは、リレーサービス1051により決定されて、移動装置A及びBへ各々返送される(例えば、装置のパブリックIP/ポートを決定することにより)。1つの実施形態において、リレーサービス1051、及び移動装置A、Bは、リレーNAT使用横断(TURN)プロトコルを実施し、このプロトコルは、当業者に明らかなように、NAT又はファイアウオールの後方の要素がTCP又はUDP接続を経て到来データを受け取るのを許す。
1208において、移動装置Aは、インビテーションサービス112へリレー更新を送信し、これは、1209において、プッシュ通知サービスへ転送され、そして1210において、移動装置Bへプッシュされる。同様に、1211において、移動装置Bは、インビテーションサービス112へリレー更新を送信し、これは、1212において、プッシュ通知サービスへ転送され、そして1213において移動装置Aへプッシュされる。移動装置Aにより送信されるリレー更新は、セッショントークンと、各装置のIDコードと、1206及び1207においてリレーにより決定されるNAT横断/接続データとを含む(即ち、移動装置AがそのNAT横断/接続データを移動装置Bへ送信し、及びその逆のことも言える)。1つの実施形態において、各移動装置のNAT情報が変化するために、リレー更新動作が遂行される。
最終的に、1214及び1215において、移動装置A及びBは、各々、リレーサービス1051を通してP2P接続を確立する。1つの実施形態において、移動装置Aが移動装置BのNAT横断/接続データをリレーサービス1051へ送信するときにリレー接続が確立され、そしてその逆のことも言え、従って、リレーサービスは、1302−1303において各ピアのリレーホストへの正しい経路を決定することができる。
上述した技術を使用して、インビテーションサービス112は、膨大な数の移動装置を伴う大規模システムであっても本来拡張可能で且つ柔軟性があるステートレスサービスとして実施される。例えば、プッシュ通知サービス1050は、本来、コンテンツを探索しそしてそれを登録された移動装置へプッシュできるので、インビテーションサービスは、各装置の現在位置を追跡することが要求されない。更に、装置は、全セッション状態データを各要求及び応答と共に送信するので、インビテーションサービスは、接続ごとの状態情報を維持することが要求されず、従って、インビテーションサービスの記憶及び処理要件を緩和する。そのような実施は、大規模システムにおいて特に有用である。
オンラインセッションに対してユーザを対戦させるシステム及び方法
図15に示すように、マッチメーカーサービス111の1つの実施形態は、対戦要求を受け取りそして対戦応答を移動装置120−122へプッシュするためのマッチメーカーディスパッチャー1501と、対戦要求を要求テーブル1502に記憶しそして対戦可能セットデータを対戦可能セット識別子(MSI)テーブル1503に記憶するためのデータベース1512と、データベース1512から対戦要求をフェッチし、対戦を組む動作を遂行し、そして対戦組み結果をデータベース1512に記憶するための1つ以上のマッチメーカー1510と、を備えている。しかしながら、本発明の基礎的な原理は、図15に示す特定のアーキテクチャーに限定されないことに注意されたい。
1つの実施形態において、マッチメーカーディスパッチャー1501は、マッチメーカーサービス111へのインターフェイスとして働き、移動装置120−122から要求を受け取り、その要求を、データベース1512に要求を記憶するコマンドへと変換し、データベース1512から対戦組み結果を読み取り、そしてその結果を変換して移動装置120−122へ通信する。
動作中、新たな対戦要求が到着すると、マッチメーカーディスパッチャー1501は、要求テーブル1502の行内にその要求を記憶する。1つの実施形態では、ディスパッチャー1501は、(移動装置A、B及びCに各々対応して)図15に“A”、“B”及び“C”と単に示された要求ID(RID)コードを各対戦要求に指定する。簡単化のために図15には文字呼称を使用して示されているが、RIDコードは、データベース内の対戦要求を追跡するのに適したストリング、整数、又は他の変数形式でよい。
各対戦要求には、要求テーブル1502に記憶された対戦可能セット識別子(MSI)の値が指定される。1つの実施形態では、MSIは、対戦が要求されている特定のアプリケーション、及び/又はそのアプリケーションに使用される構成パラメータを識別することができる。例えば、12:4のMSI値は、識別子“12”で特定のマルチプレーヤゲームを識別し、そして識別子“4”でゲームの特定の構成を識別する。より詳細には、12のIDコードは、特定のマルチプレーヤ競走ゲームを識別し、そして4のIDコードは、競走ゲームの特定の競走トラック、スピード、又はプレーヤの経験レベルを指定する。1つの実施形態において、アプリケーション開発者には、このようにMSI値を使用してアプリケーション構成パラメータを指定するオプションが与えられる。1つの実施形態において、MSIを直接指定するのではなく、アプリケーション開発者は、ゲームID(特定のゲームを識別するための)及びバケットID(特定のゲーム構成を識別するための)を指定し、そしてこれらの値は、マッチメーカーディスパッチャー1501によりMSI値へマップされる。
更に、多数の異なる構成パラメータを指定するために、単一のMSI内に多数の異なるMSI値が使用されてもよい(例えば、12:4:1は、12=競走ゲーム;4=トラック;及び1=経験レベルを表わす)。以下に詳細に述べるように、1つの実施形態において、各MSIは、対戦を組む動作が遂行される1組の対戦要求を識別するためにマッチメーカー1510によって使用される(例えば、要求はMSIに基づいてグループ化され、そして各MSIグループ内で対戦が行われる)。1つの実施形態において、各MSIは、異なるマシンパーティションを識別するパーティションIDを含むようにディスパッチャーにより動的に変更/選択される。例えば、特定のMSIが過負荷になった場合に、ディスパッチャーは、MSIを2つ以上の異なるサーバー及び/又は記憶パーティション間で分割する(例えば、4:3:1及び4:3:2のような呼称を使用し、最後の桁は、パーティション1及び2を各々識別する)。次いで、異なるマッチメーカーが、各異なるサーバーからの各異なるMSIから要求を独立して検索して処理する。
又、図15に示したように、対戦要求データは、要求ごとに要求テーブル1502内に記憶される。要求データは、対戦を組む判断をするのに有用なデータ、及び/又はネットワークを経て要求を開始する移動装置にアクセスするのに必要なデータを含む。例えば、1つの実施形態において、各要求の対戦要求データは、要求を開始する移動装置のためのNAT形式データ及び/又はNAT横断/接続データを含む。又、装置接続速度(100kbps、1Mbps、等)、接続形式(例えば、3G、EDGE、Wi−Fi、等)、装置位置(例えば、地理的位置技術により決定された)、言語(英語、スペイン語、等)及び/又はユーザの好みのような他の形式の要求データも要求テーブル1502内に記憶される。要求データは、各移動装置120−122によって決定され、そして各対戦要求と共にマッチメーカーディスパッチャー1501へ送信される。例えば、各移動装置は、ここに幾つか述べる種々の技術を使用して、その接続データ、接続形式、装置位置、等を決定する(例えば、NAT横断サーバーと通信してNAT横断/接続データを決定し、GPSを使用して装置位置を決定し、HTTP情報を読み取って言語を決定し、等)。
図15に示すように、1つの実施形態において、各アクティブなMSIには、MSIテーブル1503の行が指定される。1つの実施形態では、新たな要求が到着するときに、要求テーブル1502に要求を追加するのに加えて、ディスパッチャー1501は、MSIテーブル1503をチェックして、その要求に対してMSIが既に存在するかどうか(即ち、同じMSIを有する他の要求が既に受け取られたかどうか)も決定する。一致するMSIが見つからない場合には、ディスパッチャー1501は、新たな要求に対してMSIテーブル1503に新たなエントリを生成する。一致するMSIが見つかる場合には、ディスパッチャーは、上述したように、要求テーブル1502に新たな要求を単に追加する。
要求テーブル1502及びMSIテーブル1503がマッチメーカーディスパッチャー1501により更新されると、マッチメーカーモジュール1510のインスタンス(以下、単に、「マッチメーカー1510」と称する)が、データをフェッチして、対戦を組む動作を遂行する。多数のマッチメーカーインスタンスを同時に実行して、対戦を組む要求を遂行し、そして単一のマッチメーカー1510は、多数の異なるMSIグループにおいて多数の対戦組み動作を同時に処理する。
一実施形態において、マッチメーカー1510は、それが利用可能になると(例えば、MSIグループに対して対戦を組む動作を完了した後又は初期化の後)、MSIテーブル1503に問合せをして、処理すべき新たなMSIを識別する。図15において、MSI3:1に対するマッチメーカーIDフィールドの“N/A”値は、このMSIを処理するための責任がマッチメーカーにまだ指定されていないことを指示する。1つの実施形態では、各MSIエントリがタイムスタンプされ、そしてマッチメーカー1510は、最も古いタイムスタンプを有するMSIを選択する。
一実施形態において、マッチメーカー1510は、それが特定のMSIに対する責任を負うときに、MSIテーブル1503におけるそのマッチメーカーIDコードを更新し、そしてそのMSIのリース期間(例えば、5秒)を指定する。一実施形態において、マッチメーカー1510は、そのMSIに対して対戦を処理するときにリース値を更新し続ける。リース値は、失敗となったマッチメーカー1510に指定されたMSIを識別するのに使用される。例えば、リース値が満了となった場合には、MSIがマッチメーカーに既に指定されたことをMSIテーブル1503が指示するにも関わらず、そのMSIが新たなマッチメーカーにより請求される。
マッチメーカー1510は、それがMSIに対する責任を負うと、要求テーブル1502に問合せをして、そのMSIに関連した要求をメモリへと読み込むことができる。次いで、マッチメーカー1510は、対戦を組む基準のセットに従ってユーザ及び移動装置を対戦させるために対戦を組む動作を遂行する(例えば、以下に述べるように)。マッチメーカー1510は、移動装置の対戦が行われたときを指示するために要求テーブル1512を更新する。例えば、マッチメーカーは、要求テーブル1512のMSI列からMSI値を除去し、そして対戦が完了したことを指示するための既定値を入力する。それに加えて、マッチメーカー1510は、参加者が対戦した他の参加者を識別するために各参加者の「要求データ」フィールドを更新する(例えば、他の参加者と通信するのに必要なNAT横断/接続データを書き込むことにより)。
ディスパッチャー1501は、完了した対戦を識別するために要求テーブル1502に周期的に問合せする。完了した対戦を検出するのに応答して、ディスパッチャー1501は、対戦に関与する移動装置にプッシュ通知を送信する(例えば、本出願及び同時係争中の出願に述べられたプッシュ通知技術を使用して)。1つの実施形態では、プッシュ通知は、上述した「チケット」データ構造を含む。次いで、移動装置は、それらの各チケットを使用して、上述したCDXサービス110を経て接続データを交換する。
プッシュ通知の使用に加えて、一実施形態では、移動装置120−122は、ディスパッチャー1501に周期的に問合せして、対戦がなされたかどうか決定する。移動装置にプッシュ通知がなされない場合には、周期的な問合せが有用である。しかしながら、プッシュアーキテクチャーが使用されるために、周期的な問合せは、比較的低いレートにセットされ、マッチメーカーサービス111に対する負荷を減少させる。
図16は、2つの移動装置A及びBがマッチメーカーサービス111により対戦させられる方法の規範的な実施形態を示す。図17a−dは、その方法が進行するにつれて行われる要求テーブル1502及びMSIテーブル1503への規範的な更新を示す。
1601において、移動装置Aから対戦要求が受け取られる。1602において、図17aに示すように、移動装置Aの要求が要求テーブルに入力され、新たなMSIエントリ(MSI 1:1)がMSIテーブルに入力される(それがまだ存在しない場合)。1603において、対戦要求が移動装置Bから受け取られ、1604において、移動装置Bの対戦要求も、図17bに示すように、要求テーブルに入力される。
1605において、特定のマッチメーカーインスタンス(マッチメーカー#N)は、MSIテーブルをチェックし、そして別のマッチメーカーインスタンスによってMSI 1:1が請求されていないことを検出する。或いは又、マッチメーカーは、MSIに対してそれまで作用していたマッチメーカーが失敗となったことを指示するリース満了のMSIテーブルエントリを検出する。1つの実施形態では、リース満了のMSIエントリには、(マッチメーカーがまだ指定されていない)新たなMSIエントリより高いプライオリティが与えられる。更に、一実施形態では、比較的古いMSIエントリに、比較的新しいMSIエントリより高いプライオリティが与えられる。マッチメーカーは、それがMSIをどのように選択するかに関わらず。そのようにしたときは、図17cに示すように、その識別子を追加し、そしてMSIエントリに対して新たなリース値をセットする(例えば、図示された例では、5秒のリース値を使用して)。次いで、マッチメーカーは、要求テーブルに問合せし、そして要求テーブルエントリをそのMSIと共にメモリへ読み込み、それらを処理できるようにする。
1606において、マッチメーカーは、一連の対戦組み動作を遂行して、各要求に対して適当な対戦を選択する。対戦を組む動作の幾つかの実施形態は、図18を参照して以下に説明する。簡単に述べると、一実施形態では、「適切」な対戦を決定するために評価される変数は、NAT形式(例えば、全コーン、ポート制限、対称性、等)、接続形式(例えば、WiFi、3G、EDGE、等)、ユーザに関連した言語(HTTP要求受け容れ言語ヘッダから導出された)、及び各対戦要求の年齢を含む。一般的に、マッチメーカー1510は、適合するNAT形式(リレーサービスは、時々、以下に述べるように使用されるが)、同じ接続形式、及び同じ言語を有する移動装置を対戦させるように試みる。一実施形態において、マッチメーカー1510は、対戦要件が対戦要求の年齢に基づくように、より自由である(即ち、要求が古いほど、より自由に対戦制限を適用する)。
図16に戻ると、1607において、対戦を組む判断に続いて、マッチメーカー1510は、図17dに示すように、対戦組みが完了したことを指示するために要求テーブルを更新する。その更新の一部分として、マッチメーカーは、移動装置A及びBの要求データも更新する。例えば、一実施形態では、マッチメーカー1510は、移動装置BのNAT横断/接続データを移動装置Aの要求データ列に書き込み、そして移動装置AのNAT横断/接続データを移動装置Bの要求列に書き込む。
1608において、ディスパッチャー1501は、要求テーブルを読み取って、対戦が組まれた要求エントリを識別する。一実施形態において、移動装置A及びBの対戦が組まれたことを検出すると、要求データ(上述したようにマッチメーカーにより更新された)を読み取り、そして移動装置A及びBのための通知を発生する。一実施形態では、通知は、暗号化された前記「チケット」データ構造であり、各移動装置のNAT横断/接続データを含む。先に述べたように、一実施形態では、プッシュ通知サービス1050を使用して、移動装置A及びBへ通知がプッシュされる。更に、移動装置A及びBは、ディスパッチャー1501を周期的にポーリングして、対戦が組まれたかどうか決定する。この実施形態では、ポーリング技術は、何らかの理由で、移動装置の一方に首尾良くプッシュされなかった対戦を識別するために、比較的ゆっくりとした速度で行われる。プッシュ通知を使用してポーリング要求負荷を管理することで、移動装置からのポーリング要求で負荷のかかるマッチメーカーサービスの負荷が著しく減少される。
同じMSIに対して付加的な対戦要求が保留となっていることが1608で決定されると、マッチメーカーは、MSI内で移動装置/ユーザの対戦組みを続ける。1610において、マッチメーカーは、MSIテーブル1503内のリース値をリセットする。1611において、付加的な対戦が組まれて、要求テーブルが更新される(上述したように)。1612において、付加的な対戦が要求テーブルから読み取られ、付加的な移動装置が更新される(上述したように)。MSIに対して付加的な対戦要求が保留になっていない場合には、1609において、MSIエントリがMSIテーブルから除去される(例えば、ディスパッチャー及び/又はマッチメーカーのいずれかからの削除コマンドを経て)。
図18は、移動装置/ユーザ間の対戦を組む方法(図16の動作1606)の一実施形態を示す。1801において、全ての現在MSI要求(例えば、特定のアプリケーション/バケット組み合わせのための)が対に配列される。1802において、各対の間の対戦「フィット性(fit)」が評価され、そして1803において、それらの対が減少フィット性により分類される。「フィット性」は、複数の異なる変数に基づいて評価され、それら変数は、NAT形式(例えば、全コーン、ポート制限、対称性、等)、接続形式(例えば、WiFi、3G、EDGE、等)、ユーザに関連した言語(HTTP要求受け容れ言語ヘッダから導出された)、及び各対戦要求の年齢を含むが、これに限定されない。対戦組み判断の因子となる他の変数は、各移動装置の位置(例えば、特定位置のユーザの対戦を試みる場合)、最小及び/又は最大プレーヤ要件(例えば、ユーザ及び/又はアプリケーションにより指定される)、MSIに含まれる1人以上のユーザが「友人」であるか、又はP2P接続に以前に入ったことがあるか(例えば、「友人」又は以前の知合いとの対戦を好む場合)、及びアプリケーションでのユーザの経験(例えば、マルチプレーヤゲームに対し、同様の経験をもつユーザとの対戦を好む場合には、各ユーザのスコアボードランクが因子とされる)を含む。
以下のテーブルAに示すように、一実施形態では、「フィット性」の評価は、0.0と1.0との間の数値である。浮動小数点の値を使用することで、各基準に対してフィット性を正規化することができる。浮動小数点演算を回避するために、非正規化の整数値を適当な評価と共に使用し、従って、フィット値を比較することができる。
1つの実施形態において、全ての基準は、それらが適合する(compatible)(正規化値が1.0)か、又は適合しない(正規化値が1.0未満)というバイナリフィット性を有する。それらは、(以下に述べるように)フィット性が年齢と共に変化する必要な基準と考えられる。位置が変数として追加される場合に、最良のフィット性は、最も近いプレーヤが必要な基準に合致するというものである。
対戦フィット性 − テーブルA
一実施形態において、フィット性は、前記基準の各々に対し(正規化された重み*年齢因子値)の和に等しい。年齢因子値は、値1でスタートし、そして所定の期間が経過した後に増加する。これは、次いで、時間の経過と共に増加し続ける(例えば、周期的に特定量増加する)。一実施形態では、上述した年齢因子値を使用するのではなく、年齢スレッシュホールドが、以下に述べるように確立される。接続形式及び言語のようなある変数の正規化/重み付け値は、ある年齢スレッシュホールドの上で適用される(たとえそれらが一致しなくても)。
一実施形態において、一対の要求AとBとの間の「フィット性」は、AとB及びBとAとのフィット性の平均である。更に、各因子に対するAとBのフィット性は、Aの年齢に基づいて調整される(その逆のことも言える)。一実施形態において、適合する対戦のためには1.0のフィット性が要求される。これは、NAT適合性、接続形式及び言語が一致する(正規化値1.0を生じる)場合、又は(スレッシュホールドより上又は下のいずれかの年齢因子値を使用して)前記変数の幾つか(例えば、接続形式及び言語)を実際上無視できるほどA及び/又はBが加齢した場合にのみAとBが対戦することを意味する。
年齢 − テーブルB
年齢スレッシュホールドは、前記テーブルBに示すように確立される。各年齢スレッシュホールドを経過すると(即ち、要求が指定スレッシュホールドより古くなると)、年齢因子値が、次第に大きな値(例えば、1.5、2.0、等)へと増加する。それとは別に又はそれに加えて、異なる年齢スレッシュホールドを経過するにつれて、ある変数に対する重み値が対戦組み判断に追加される(例えば、以下に述べる接続形式及び言語)。
一実施形態において、テーブルBに示された要求年齢限界が所与のMSIに対する対戦フローレートに基づいて調整される。一実施形態において、フローレートは、指定の単位時間(例えば、10秒毎、毎分、等)当たりに行われる対戦組みの数として指定される。従って、フローレートは、特定のMSIセットがどのようにビジーであるかの指示を与える。一実施形態では、そのセットがビジーであるほど、早期に成功する対戦の確率を高め且つマッチメーカーの負荷を減少するために前記スレッシュホールドの各々が前記テーブルBにセットされることが少なくなる。更に、所与のMSIセットについての負荷がエンドユーザに与えられ(例えば、対戦値までの推定時間の形態で)、従って、エンドユーザは、特にビジーなマルチプレーヤゲームに入るよう試みるべきかどうか選択することができる。負荷値は、プッシュ通知の形態でユーザに与えられる。
テーブルAからの各変数を参照すれば、一実施形態において、NAT適合性は、図14に示すNAT適合性チャート1400から決定される。このチャートに基づき2つのNATが適合であると決定される場合には、NAT適合性重みが適用される。
接続形式 − テーブルC
接続形式は、テーブルCとして上に示されたもののようなチャートを使用して評価される。この例では、装置A及びBの接続形式が同じである場合(同じ接続形式に出会うセルにおいて1.0で示される)、テーブルAからの重み付けされた接続形式値がフィット性の決定に含まれる。上述したように、各要求の年齢は、接続形式の決定に作用するように使用される。例えば、一実施形態では、接続形式に対するフィット値は、スレッシュホールド1、2及び3の年齢についてテーブルCのマトリクスを使用して選択される。スレッシュホールド4以上の年齢については、接続形式が1.0にセットされ(非対戦の接続形式についても)、そしてそれに対応する重み付けされた接続形式値が適用される。幾つかの実施形態では、接続「形式」が使用されるが、接続形式と共に、又はそれに代わって、接続速度が決定されて使用されてもよい。例えば、ある指定範囲内の接続速度は、「適合」と考えられる(例えば、0−100kbps、100−500kbps、500−1000kbps、1000−1500kbps、等)。ここに述べる対戦組み変数は、いずれも、対戦フィット性の計算に対する重みとして適用され、上述したように加齢される。
一実施形態において、プレーヤの言語は、好み因子を伴う1つ以上の言語を含むHTTP要求受け容れ言語ヘッダから導出される。ディスパッチャーは、最も好ましい言語を抽出し、そしてその情報をマッチメーカーへ送る。一実施形態では、テーブルAからの重み付けされた言語値は、言語が同じである場合は1.0にセットされ、又は同じでない場合には0.0にセットされる。しかしながら、一実施形態では、重み付けされた言語値は、年齢が指定のスレッシュホールドより高い場合には(例えば、年齢がテーブルBにおいてスレッシュホールド2以上である場合には)、たとえ言語が異なるものであっても適用される。
一実施形態において、不適合なNAT形式をもつ2人のユーザ間で対戦を組むこともできる。例えば、マッチメーカーは、特定のMSIに対してユーザの対戦を組むのが困難な場合に、指定の期間の後に、上述した技術を使用してリレーサービス1051を通る接続をルーティングする。このように、リレーサービス1051は、圧力弁として働き、不適合なNAT形式であるにも関わらず、加齢して対戦を組めるようにする。又、リレーサービス1051は、1つ以上の失敗した対戦組みの試みを検出するのに応答して使用することもできる。この実施形態では、移動装置によって提出される各対戦要求は、1つ以上の不首尾な対戦組みが以前に試みられたかどうかの指示を含む。
種々の付加的な対戦基準が評価され、そして対戦フィット性決定の一部分として重み値が与えられ、これは、例えば、対戦を要求しているユーザのいずれかが友人であるかどうかの指示を含むが、これに限定されない。例えば、マッチメーカー1510は、対戦フィット性の計算に「友人」重みを適用することにより、友人であるユーザの要求を対戦組みするよう試みる。同様に、友人の友人も重み付けされる(例えば、2つ以上の分離度で)。更に、プレーヤは、特定のゲームに対して他のプレーヤを格付けし、そしてマッチメーカーは、対戦を組むときにそれらの格付けを評価する(ユーザを、比較的高い格付けのプレーヤと対戦させ、低い格付けのプレーヤとは対戦させない傾向で)。更に、ユーザの接続の待ち時間も評価され(例えば、簡単なピン(ping)動作を使用して)、そして対戦を組む判断の一部分として使用される。
プレーヤを対戦させるのに使用される更に別の変数は、装置の形式である。例えば、マッチメーカー1510は、同様の装置形式(例えば、iPad(R)、iPod(R)、iTouch(R)、iPhone(R)、RIM Blackberry(R)、等)をもつプレーヤを対戦させるよう試みる。付加的な変数は、ユーザのスコアボードランキング、現在位置、現住地、年齢、性別を含み、そして対戦決定のために同様のゲームコレクションが同様に評価される(即ち、同様の基準でのユーザ間の対戦を奨励する傾向のある多くのケースにおいて)。最終的に、ユーザが適切なMSIで且つ同じ年齢の他のユーザのみと対戦されることを保証するためにマッチメーカー1510によりペアレンタルコントロールが評価される。
マッチメーカーサービス111は、データサービス100内で管理される1つ以上のデータベースから前記変数のいずれかを検索する(例えば、図19を参照して以下に述べるデータベース1920を参照)。例えば、ユーザの友人のデータは、友人サービスデータベースからアクセスされ、そして各ユーザの年齢、性別、ゲームコレクション、等の他の情報は、1つ以上の他のデータベース(例えば、ユーザプロフィール、ゲームデータベース、スコアボードデータベース、等)からアクセスされる。一実施形態では、ここに述べる全てのサービスに、対戦を組む判断を行うのに使用される全ての種々の異なる形式のユーザ/装置データを記憶するための同じ中央データベース(又はデータベースのグループ)へのアクセス権が与えられる。
多数の特定例を上述したが、本発明の基礎的な原理は、対戦のフィット性レベルを決定する特定の1組の変数に限定されないことが明らかである。一実施形態において、ここに述べるシステム及び方法に対して実行されるアプリケーションを設計するアプリケーションプログラマは、異なるMSI基準を使用して要求をマッチングさせ及び/又はグループ分けさせるそれ自身の1組の基準を指定することができる。
図18の方法に戻ると、各対間の対戦「フィット性」が決定されると、1803において、減少するフィット性によって対が分類される(例えば、最も高いフィット性を有する対がリストのトップとなる)。1804において、「対戦セット」に、指定のスレッシュホールドより上の最高フィット値を有する対がシードされる。上述したように、「スレッシュホールド」値は、前記テーブルAに示された1.0の正規化値にセットされる。1805において、対戦セット内の現在メンバーの1人又は全員が指定スレッシュホールドより上となるようなフィット値を有する新たな有望なパートナーが対戦セットに追加される。例えば、対戦セットに最初にA及びBがシードされた場合に、A−C及び/又はB−Cのフィット値が指定スレッシュホールドより上になるならば、Cが対戦セットに追加される。一実施形態では、単一の対戦フィットだけが有望な当事者のスレッシュホールドより上である場合に、その当事者が対戦セットに追加される(即ち、必要に応じて、その当事者が、適当な対戦フィット性をもつところの1人の当事者を通して全ての当事者と通信できるので)。1人以上の新たな当事者が対戦セットに追加されると、対戦のサイズ要件が満足されたことが1806において決定された場合に、(例えば、上述したように、要求テーブル1502を更新しそして通知を送信することにより)1807において対戦組み結果が記憶され報告される。一実施形態では、単一の対戦要求が複数のユーザを表わしてもよい(例えば、以下に述べるように、対戦要求の後にインビテーションシーケンスが続くとき)。このケースでは、サイズ要件は、各対戦要求により表されるユーザの人数に基づいて評価される。サイズ要件が満足されない場合には、プロセスが1805へ戻り、新たな当事者が対戦セットに追加される(即ち、セットの現在メンバーの1人以上が指定のスレッシュホールドより上となるような対戦フィット性を有する当事者)。
1808において、対戦が組まれた要求が、マッチメーカー1510により処理されている要求の現在セットから除去される。1809において、次にシードされる対戦セットが選択され、プロセスは、付加的な対戦を組むために1804へ戻る。図18には、順次のプロセスとして示されているが、シードされた複数の対戦セットは、本発明の基礎的な原理に適合しつつ、同時に処理されてもよいことに注意されたい。
個別のサービスとして上述したが、マッチメーカーサービス111及びインビテーションサービス112は、P2Pユーザを接続するように一緒に動作することができる。例えば、一実施形態では、第1のユーザが1人以上の友人をオンラインセッションに招待し、そして1人以上の付加的なユーザとの対戦を要求する(例えば、友人「ボブ」を招待し、そしてマルチレイヤビデオゲームに対して3人の付加的なプレーヤと対戦させる)。そのようなケースでは、インビテーションサービス112は、第1ユーザと第1ユーザの友人とを接続するために第1ユーザのインビテーション要求を最初に処理する。次いで、インビテーション要求の結果(例えば、P2P接続成功)がユーザの移動装置へ報告されて戻される。マッチメーカーサービス111は、次いで、付加的なプレーヤを要求する対戦要求を第1ユーザの移動装置から(又は一実施形態ではインビテーションサービスから直接又は第1ユーザの友人から)受け取る。それに応答して、マッチメーカーサービス111は、第1ユーザと、第1ユーザの要求と同じMSIを有する1つ以上の他の対戦要求との対戦を組む(上述したように)。対戦要求は、第1ユーザの対戦基準のみを含むか、又は第1ユーザ及び第1ユーザの友人の対戦基準(例えば、BAT形式、接続形式、言語、位置、等)を含む。一実施形態において、第1ユーザの友人の1人以上が、別の対戦ユーザとの直接的なP2P接続を確立できない場合には、第1ユーザの友人と対戦ユーザとの接続が、第1ユーザのデータ処理装置を通して確立され(例えば、第1ユーザの移動装置を接続のためのプロキシーとして使用して)、及び/又はリレーサービスを使用して、ユーザを接続する(上述したように)。
一実施形態において、第1ユーザは、マッチメーカーサービスにより1人以上のユーザと最初に対戦が組まれ(上述したように)、次いで、第1ユーザは、第1ユーザ及び対戦ユーザとのオンラインセッションに加わるように1人以上の友人を招待する。この実施形態では、ユーザの情報及び対戦ユーザの情報の両方(例えば、NAT/接続データ、ユーザID、プッシュトークン、等)が、インビテーションサービスを通して招待ユーザとで交換される(上述したように)。本発明の基礎的な原理は、最初に対戦が組まれた後に招待されるか、又は最初に招待された後に対戦が組まれるかに関わりなく、同じである。
協力的オンラインアプリケーションのためのアプリケーションプログラミングインターフェイスを伴うアプリケーションフレームワーク
図19に示すように、本発明の一実施形態は、既定のソフトウェアフレームワーク1912を、1つ以上のアプリケーション1911とインターフェイスするためのアプリケーションプログラミングインターフェイス(API)1910、及び複数のネットワークサービス1901−1903と通信するためのサービス側API1913と共に有する移動装置120の環境内で具現化される。図19に示すように、ネットワークサービス1901−1903は、同じオンラインデータサービス100により設計及び/又は管理される(が、そのような構成は要求されない)。P2Pゲームアプリケーション及び他の形式の協力的オンラインアプリケーションのようなアプリケーション1911は、API1910へコールを発することによりAPI1910を通してネットワークサービス1901−1903にアクセスするように設計される。アプリケーション1911の設計は、フレームワーク1912及びネットワークサービス1901−1903の開発者により与えられるソフトウェア開発キッド(SDK)を使用して促進される。フレームワーク1912及びAPI1910、1913のより特定の具現化は、図20を参照して以下に述べる。
図示されたように、各サービスには、サービスにより使用されるデータを記憶するためのデータベース1920へのアクセス権が与えられる。1つの特定例は、マッチメーカーサービス111により使用されるデータベース1512である(上述したように)。他の例は、スコアボードデータを記憶するためのスコアボードデータベースと、友人状態レコードを記憶するための友人サービスデータベースと、ユーザプロフィールデータを記憶するためのプロフィールデータベースと、オンラインゲームに関連したデータを記憶するためのゲームデータベースとを含む。任意の形式のデータベース(例えば、MySQL、Microsoft SQL、等)が使用されるが、1つの特定の実施形態では、Berkley DB及び/又はMZBasic DBのようなキー/値データベースを使用することができる。データベースは、記憶エリアネットワーク(SAN)又は他の記憶構成において多数の大量記憶装置(例えば、ハードドライブ)にわたって分散される。
その結果、特定のサービスが、上述したように、データを処理し及び/又は記憶するときには、データがデータベース1920内に記憶される。しかしながら、あるサービスでは、データベースが使用されない。例えば、上述したように、インビテーションサービス112は、ステートレスサービスとして実施され、それ故、データベース1920内にデータを記憶することが要求されない(が、そのような実施は、本発明の基礎的な原理でも可能である)。
API1913は、例えば、ネットワークレイヤではTCP/IP又はUDP/IPをそしてアプリケーションレイヤではHTTPSを含む適当なネットワークプロトコルスタックを使用してネットワークサービス1901−1903と通信しそしてそれらと情報を交換するように設計される。SOAPのようなHTTP又はHTTPSを経てのリモート手順コール(RPC)ベースのプロトコルが使用され、及び/又は代表的状態転送(REST)プロトコルが使用される。更に、サービスは、例えば、Unix、Linux又はApacheソフトウェプラットホームを実行するXserver又は同様のサーバーを含むコンピューティングプラットホームにおいて実施される。1つの特定の実施形態では、プラットホームは、Linuxにおいて具現化されるウェブオブジェクトを含む。以上の例は、説明上与えられたものに過ぎない。本発明の基礎的な原理は、アプリケーションをサービス又は特定セットのネットワークプロトコルにリンクするための特定のメカニズムに限定されない。
図20は、本発明の一実施形態においてワイヤレス装置120で実施されるアプリケーションプログラミングインターフェイス(API)2001a−bを含むより詳細なソフトウェアアーキテクチャーを示す。この実施形態は、マルチプレーヤゲームフレームワーク2000の環境内で説明するが、本発明の基礎的な原理は、ゲームの実施に限定されない。例えば、図20に示すソフトウェアアーキテクチャーは、ゲーム以外の種々の協力的アプリケーション(例えば、協力的チャット、多当事者協力的オーディオ/ビデオ、等)をサポートするのに使用される。
図20に示すアーキテクチャーにおいて、ゲームフレームワーク2000は、ここに述べる種々の多当事者特徴及びP2P特徴をサポートするために設けられる。一実施形態において、ゲームフレームワーク2000は、移動装置のオペレーティングシステム2005上で実行されるように構成される。例えば、移動装置120がiPhone(R)、iPad(R)又はiPod Touch(R)である場合に、オペレーティングシステム2005は、本出願の譲受人によって設計された移動オペレーティングシステムであるiPhone(R) OSである。
ゲームフレームワーク2000は、パブリックアプリケーションプログラミングインターフェイス(API)2001b及びプライベート又は「セキュア」なAPI2001aを含む。一実施形態において、ここに述べる種々のゲーム関連特徴を与えるように設計されたゲームセンターアプリケーション2031は、パブリックAPI2001b及びプライベートAPI2001aの両方にコールを発信し、一方、他のアプリケーション2030(例えば、第三者により設計されたアプリケーション)には、パブリックAPI2001bのみへのアクセス権が与えられる。例えば、移動装置120の設計者は、第三者の開発者による悪用を回避するためにパブリックAPI2001bからの潜在的に微妙な情報(例えば、友人の要求、友人リスト、等)を伴う幾つかのAPI機能を保持することを希望する。しかしながら、セキュアなAPI2001a及びパブリックAPI2001bは、両方とも、移動装置の全てのアプリケーションによりアクセス可能な単一のAPIへと合流される(即ち、本発明の基礎的な原理に適合するために個別のパブリック及びプライベートコンポーネントへのAPIの分離は、要求されない)。「API2001」の呼称は、パブリックAPI2001b及び/又はプライベートAPI2001aのいずれかに見られる動作を指すために以下で時々使用される。
ゲームセンターアプリケーション2031の一実施形態は、本出願の譲受人に譲渡されそして参考としてここに援用される2010年4月7日に出願されたMarcel Van Os及びMike Lampellを発明者とする“Systems and Methods for Providing a Game Center”と題する同時係争中の出願(代理人管理番号第4860.P9127USP1号)(以下、「ゲームセンター特許出願」)に説明されている。簡単に述べると、ゲームセンターアプリケーション2031は、マルチプレーヤゲームを通してナビゲートし、新たなゲームを購入し、ゲームに関連した情報(例えば、スコアボード情報、実績、友人情報、等)を検索し、ゲームをプレイするために友人に連絡し、他のユーザとのゲーム対戦を要求し、及び特定のユーザを招待するためにゲームセンターグラフィックユーザインターフェイス(GUI)を含む。ゲームセンターアプリケーション2031により行われる種々の他の機能は、前記ゲームセンター特許出願に説明されている。幾つかのゲームセンター機能は、ゲームフレームワーク2000により与えられ、そしてパブリックAPI2001bを通して他のアプリケーション2030へアクセスできるようにされる。
一実施形態において、ゲームフレームワーク2000により露出されるAPI2001は、移動装置120のためのマルチプレーヤの協力的ゲームを設計するプロセスを簡単化する。特に、一実施形態では、API2001は、マルチプレーヤのP2Pゲームセッションに対してユーザを接続する比較的複雑なプロセスを呼び出すために開発者が簡単なAPIコールを発信できるようにする。例えば、上述した詳細なインビテーションシーケンスを開始するために、INVITE(プレーヤB ID、バケットID)のような簡単なAPIコールがAPI2001呼び出される。同様に、上述した詳細なマッチメークシーケンスを開始するためにMATCH(プレーヤA ID、バケットID)がAPI2001から呼び出される。INVITE及びMATCH機能は、一般的に、「P2P接続機能」とも称される。一実施形態において、ゲームフレームワーク2000は、これらのAPIコールに応答してインビテーション及びマッチメーク動作を管理するのに必要なプログラムコードを含む。実際のAPI機能は、上述したものとはある程度異なるデータフォーマットを有する(が、ゲームフレームワーク2000により遂行される同様の動作を生じる)。本発明の基礎的な原理は、API機能を指定するための特定のフォーマットに限定されない。
種々の他の形式のゲーム関連トランザクション及び情報も、ゲームセンター2031及び他のアプリケーション2030に代わって、ゲームフレームワーク2000により管理される。この情報の幾つかは、前記ゲームセンター特許出願に説明されている。例えば、これに限定されないが、この情報は、各ゲームの最高スコアを得たユーザに関連した「スコアボード」情報と、幾つかのゲーム特有の実績を完成したユーザを識別する「実績」情報とを含む。各アプリケーション開発者は、各ゲームアプリケーション2030に対してそれ自身の1組の「実績」を指定する(例えば、完成レベル1−3;完成レベル1は5分以内;レベル当たり50キル以上;ノックダウン20フラグ;等)。
又、ゲームフレームワーク2000は、ユーザの友人データを管理しそしてゲームセンター2031及び他のゲームアプリケーション2030の環境内で友人データを統合するためのプログラムコードも含む。例えば、ユーザがゲームセンター2031内の特定のゲームへのリンクを選択するとき、ユーザの各友人に関連した情報がそのゲームに対して表示される(例えば、スコアボード上の友人のランキング、友人の実績、ユーザが自分の各友人とゲームをプレイしたときの結果、等)。一実施形態において、ゲームフレームワーク2000のAPI2001は、友人サービスにより管理される友人データにアクセスするための機能を含み、これは、例えば、本出願の譲受人に譲渡されそして参考としてここに援用される2010年4月7日に出願されたAmol Pattekar、Jeremy Werner、Patric Gate及びAndrew H.Vyrrosを発明者とする“Apparatus and Methods for Efficiently Managing Data in a Social Networking Service”と題する同時係争中の出願(代理人管理番号第4860.P9420号)(以下、「友人サービス特許出願」)に説明されている。
図20に示すように、一実施形態において、ゲームデーモン2020は、ゲームフレームワーク2000を第1セットのサービス2050へインターフェイスし、そしてゲームサービスコンポーネント2010は、ゲームフレームワーク2000を第2セットのサービス2051へインターフェイスする。例えば、第1セットのサービス2050は、上述したインビテーションサービス112、マッチメーカーサービス111、及びリレーサービス1051と、前記友人サービス特許出願に説明された友人サービスとを含む。ゲームデーモン2020を経てアクセスされる他のサービスは、スコアボードサービス(スコアボードデータを与える)、ゲームサービス(各ゲームに関連した統計値及び他のデータ並びにゲームを購入する能力を与える)、ユーザ認証サービス(移動装置のユーザを認証するための)、及び/又はユーザプロフィールサービス(ユーザの好みのようなユーザプロフィールデータを記憶するための)を含む。ゲームサービスコンポーネント2010を経てアクセスされる第2セットのサービス2051は、上述した接続データ交換(CDX)サービス110、及びNAT横断サービス290−291を含む。説明上、図20には個別のコンポーネントとして示されているが、ゲームデーモン2020及びゲームサービスモジュール2010は、実際には、ゲームフレームワーク2000のコンポーネントである。一実施形態において、ゲームデーモン2020及び2010は、一実施形態ではプライベートAPI(即ち、第三者の開発者には公表されず)である既定のAPIを通して各ネットワークサービス2050−2051と通信する。
一実施形態において、ゲームデーモン2020は、HTTPSプロトコルを使用してマッチメーカーサービス111、インビテーションサービス112及び他のサービス2050と通信し、一方、ゲームサービスモジュール2010は、UDPソケットのような比較的軽い重みのプロトコルを使用してCDXサービス110及びNAT横断サービス290−291と通信する。しかしながら、上述したように、本発明の基礎的な原理に適合しつつ、種々の他のネットワークプロトコルを使用することができる。
更に、図20に示すように、ゲームデーモン2020は、幾つかのサービス2052(例えば、インビテーションサービス及びマッチメーカーサービス)により発生されたプッシュ通知2052を受け取り、一方、他の形式のプッシュ通知2053は、ゲームセンターによって直接受け取られる(例えば、新たな友人要求のような友人サービス通知)。一実施形態において、これらのプッシュ通知2053は、ユーザの繊細なデータが第三者のアプリケーション開発者により設計されたアプリケーション2030へ接近できないよう保証するためにゲームセンター2031へ直接与えられる。
図11について上述したゲームインビテーション例に戻ると、移動装置Aのアプリケーション2030がゲームフレームワーク2000のAPI2001bへインビテーションコールを行って、移動装置Bのユーザを招待するときに(例えば、INVITE(プレーヤB ID、ゲーム/バケットID)、ゲームフレームワーク2000は、インビテーション要求を移動装置Aのゲームデーモン2020へ通す。次いで、ゲームデーモン2020は、インビテーションサービス112と通信して、インビテーション要求を提出する。次いで、インビテーションサービス112は、プッシュ通知サービス1050を利用して(上述したように)、移動装置Bのゲームデーモン2020へプッシュする。移動装置Bのゲームデーモン2020は、移動装置Bのゲームフレームワーク2000と通信して、インビテーションが送られたゲームが移動装置Bにインストールされているかどうか決定する。もしそうであれば、ゲームフレームワーク2000は、アプリケーション2030をトリガーし及び/又はインビテーションの視覚通知を発生する。アプリケーションがインストールされていない場合には、ゲームフレームワーク2000は、インビテーションの視覚通知を、ゲームを購入するオファーと共に移動装置Bのユーザへ(例えば、ゲームセンター2031のGUIを経て)トリガーする。或いは又、視覚通知は、移動装置120(図示せず)で実行されるプッシュ通知デーモンにより発生されてもよい。移動装置Bのユーザがゲームを購入する場合には、購入の後にインビテーションシーケンスが続けられる。移動装置Bのユーザがインビテーション要求を受け容れる場合には、移動装置Bのゲームフレームワーク2000がそのインビテーション要求をゲームデーモン2020へ通し、ゲームデーモンは、次いで、インビテーションサービス112に応答する。
図11において、移動装置A及びBのNAT形式が適合すると適合性チェック1106が決定することを想起されたい。従って、1108において、移動装置Aのゲームデーモン2020は、移動装置bの受け容れを受け取り(例えば、この例ではプッシュ通知を経て)、そして一実施形態では、その受け容れをゲームフレームワーク2000へ通す。この段階において、移動装置Aのゲームフレームワーク2000は、移動装置Bが受け容れたことを要求側アプリケーション2030に通知するか(API2001を経て)、又は装置が首尾良く接続されるまで要求側アプリケーション2030に通知するのを待機する。いずれにせよ、ゲームフレームワーク2000は、接続要求をゲームサービスモジュール2010へ通し、このモジュールは、一実施形態では、移動装置Bとの接続データ交換を開始する。特に、ゲームサービスモジュールは、CDXサービス110を使用して移動装置Bへ移動装置Aの接続データを送信する(例えば、図11のトランザクション1111及び1112を参照)。上述したように、この通信は、セキュアな「チケット」データ構造を使用してUDP接続として実施される。
図12において、移動装置A及びBのNAT形式が適合しないと適合性チェック1106が決定した場合には、リレーサービス1051を使用して、装置間に接続を与えることができる。その結果、移動装置Bのゲームデーモン2020は、インビテーションサービスからリレー応答1203を受け取り(図12に示す)、そして移動装置Aのゲームデーモン2020は、インビテーションサービスからリレー応答1205を受け取る(プッシュ通知サービス1050を経て)。移動装置A及びBのゲームデーモン2020は、1206及び1207においてリレーサービスと通信して、構成データを検索する。1210において、移動装置Bのゲームデーモン2020は、移動装置Aからリレー更新データを受け取り、そして1213において、移動装置Aのゲームデーモン2020は、移動装置Bからリレー更新データを受け取る。
図11及び12に示すプロセスの最終結果として、移動装置A及びBは、互いに接続を確立する(直接的なP2P接続、又はリレー接続)。一実施形態において、接続成功を検出すると、ゲームフレームワーク2000は、APIコールを使用して接続を要求したアプリケーション2030に通知する(例えば、CONNECTED(プレーヤA ID、プレーヤB ID))。次いで、移動装置A及びBは、確立された接続を使用して指定のゲーム又は他の協力的アプリケーション2030をプレイする。
従って、API2001からの比較的簡単なコールに応答して(例えば、INVITEプレーヤB ID、ゲーム/バケットID)、移動装置AとBとの間にP2P又はリレー接続を確立するために複雑な一連のトランザクションがゲームフレームワーク2000によって管理される。一実施形態において、ゲームフレームワーク2000は、移動装置A及びBを接続する一連の動作を遂行し、次いで、結果を要求側アプリケーション2030に与え、それにより、APIコールの詳細をアプリケーション設計者に対して透過的なままとする。従って、アプリケーション設計者は、ネットワーク上の移動装置A及びBをどのように接続するか、又はそれら装置間の通信を可能にするために要求される種々の他の機能をどのように遂行するか理解する必要がなく、従って、アプリケーション設計プロセスが簡単化される。
同様に、ゲームフレームワーク2000は、図2a−bについて上述したマッチメーカーサービス111を使用して移動装置Aと他の参加者との間の対戦を確立する。この例では、アプリケーション2030は、MATCH(プレーヤA ID、ゲーム/バンドル ID)のような簡単なコールをAPI2001へ発信する。それに応答して、ゲームフレームワーク2000は、対戦を組む動作及び接続データ交換動作を管理する。対戦を組む動作及び/又はP2P接続が完了すると、ゲームフレームワーク2000は、その結果をアプリケーション2030に与える。
例えば、図2bにおいて、ゲームフレームワーク2000は、ゲームサービスモジュール2010を使用して、接続データ交換(CDX)サービス110及びNAT横断サービス290−291と通信し、そしてゲームデーモンを使用して、マッチメーカーサービス111と通信する。対戦が決められると、移動装置Aのゲームデーモン2020は、229においてチケットAを受け取り、そしてゲームフレームワーク2000は、この情報を使用して、ゲームサービスモジュール2010を通して接続データ交換を実施する。たとえば、232において、NAT横断サービス290を通してそれ自身の接続データを要求し、次いで、233−234において、CDX)サービス110を通してその接続データを交換する。237及び240において、移動装置Aのゲームサービスモジュール2010は、移動装置A及びBの接続データを各々受け取る。これらの交換に続いて、ゲームサービスモジュール2010は、241において、P2P接続を確立し、そしてゲームフレームワーク2000は、API通知(例えば、MATCH COMPLETE(プレーヤB ID、プレーヤC ID))を使用して接続プロセスが完了したことをアプリケーション2030に通知する。次いで、アプリケーションは、確立されたP2P接続を使用して実行することができる。
ある実施形態において、ユーザには、現在「オンライン」として登録されている他の友人とゲームをプレイするオプションが与えられる。このケースでは、ある友人がオンラインであるとの通知がプッシュ通知2052又はプッシュ通知2053(ゲームセンター2031によって直接受け取られる)を経て与えられる。次いで、ゲームセンター2031及び/又はアプリケーション2030は、ユーザに通知を与えると共に、1人以上の選択されたオンライン友人とプレイするオプションをユーザに与える。しかしながら、ここに述べるインビテーションシーケンスは、オンライン通知が与えられるかどうかに関わらず作用することに注意されたい。一実施形態において、ユーザのオンライン状態は、ゲームデーモン2020がアクセスできるサービスによって監視される(例えば、上述した友人サービス又は個別の「存在」サービスにより)。
ゲームフレームワーク2000の一実施形態は、ユーザが未知の対戦参加者のグループとゲームをプレイするために1人以上の友人を招待する組み合わせ招待/対戦組み動作を与える。例えば、ゲームが4人のプレーヤを必要とし、そして第1ユーザがゲームをプレイするために第2ユーザを招待する場合には、インビテーションサービス112は、最初に、第1ユーザと第2ユーザを接続し、そしてマッチメーカーサービス111は、第1ユーザ及び第2ユーザを2人(以上)の他のプレーヤと対戦させる。この実施形態では、ゲームフレームワーク2000が、最初に、上述したインビテーションシーケンスを遂行して、第1ユーザと第2ユーザを接続する。一実施形態において、第1ユーザと第2ユーザが首尾良く接続されると、ゲームフレームワーク2000は、対戦を組むシーケンスを実施して、他のユーザを識別しそしてそれと接続する。上述したように、一実施形態では、マッチメーカーサービスにより適用される対戦組み基準は、第1及び第2の両ユーザを含む(例えば、第1及び第2の両ユーザのNAT形式、接続形式、言語、等)。或いは又、対戦を組む判断をするために2人のユーザの一方の基準が評価されてもよい。
全てのユーザが接続されると、ゲームフレームワーク2000は、API2001を経て接続を要求したアプリケーション2030に接続結果を与える。この場合も、アプリケーション2030による比較的簡単なAPIコールに応答して、ゲームフレームワーク2000は、各装置を接続するための1組の複雑なトランザクションに入る。装置が首尾良く接続されると、ゲームフレームワーク2000は、要求側アプリケーション2030に結果を返送する。
図20に示すように、ゲームフレームワーク2000は、ユーザと他のゲーム参加者との間の通信を一時的に記憶するための通信バッファ2003を含む。通信は、例えば、テキスト、オーディオ及び/又はビデオ通信を含む。ゲームフレームワーク2000は、各アプリケーション2030の要件に基づいてバッファ2003を確立する。例えば、低速ネットワーク接続でのオーディオ/ビデオ通信については、比較的大きなバッファ2003が要求される。一実施形態では、各アプリケーション2030は、API2001を経てあるサイズの通信バッファを確立するために明確な要求をなす(例えば、BUFFER(サイズ)コマンドを使用して)。或いは又、ゲームフレームワーク2000は、各アプリケーションの通信要件に基づいて自動的にバッファを生成する。例えば、ゲームフレームワーク2000は、テキスト、オーディオ及び/又はビデオをサポートする必要があるかどうかに基づいて特定のバッファサイズを選択する。
一実施形態において、通信バッファ2003は、ユーザ間に全てのP2P接続が確立される前に通信ストリームを一時的に記憶する。例えば、インビテーションサービス112又はマッチメーカーサービス111が各ユーザを識別した後であって、CDXサービス110が接続データ交換動作を完了する前に、各ユーザには、接続プロセスにある他のゲーム参加者が通知される。この段階において、移動装置120のユーザは、テキスト、オーディオ及び/又はビデオ通信ストリームを他の参加者へ送信する。ゲームフレームワーク2000は、まだ接続されていない参加差について通信ストリームを通信バッファ2003内に記憶する。次いで、ゲームフレームワーク2000は、各装置のための接続が完了するときに、テキスト、オーディオ及び/又はビデオをバッファ2003から送信する。
一実施形態では、ゲームデーモン2020は、各サービス2050において持続するデータをキャッシュしてネットワークトラフィックを減少するためのキャッシュ2021を含む。例えば、ユーザの友人のリスト、スコアボードデータ、実績データ、存在データ、及びプロフィールデータは、キャッ巣マネージメントポリシーで指定されるようにキャッシュ2021に記憶される。一実施形態では、キャッシュマネージメントポリシーは、データが記憶される各個々のサービスにより駆動される。その結果、n個の異なるサービスに対して、n個の異なるキャッシュマネージメントポリシーがキャッシュ2021に適用される。更に、キャッシュマネージメントポリシーは、サービスにより駆動されるので、現在ネットワーク及び/又はサーバー負荷状態に基づいて動的に変更される。例えば、サービスの負荷が厳しい期間中(例えば、クリスマス、新製品発売日、等)、サービスは、あまり頻繁にキャッシュ更新しない(例えば、12時間ごとに更新の)キャッシュマネージメントポリシーを動的に指定する。対照的に、サービスの負荷が厳しくない期間中は、サービスは、より頻繁にキャッシュ更新する(例えば、30分、1時間、2時間ごと、等に更新の)キャッシュポリシーを指定する。
一実施形態において、キャッシュマネージメントポリシーは、キャッシュ2021に記憶されるあるデータレコードのための生存時間(TTL)値を使用して指定される。データレコードがそのTTL値を越えてキャッシュに記憶されていたときには、そのデータが「古くなった(stale)」と考えられ、そのデータのローカル要求が、そのデータに関連したサービスへ直接転送される。一実施形態において、要求は、データの現在バージョンを識別するIDコードを含む。IDコードがサービスのIDコードに一致する場合には、データが依然有効であり、更新の必要がない。次いで、キャッシュのデータが現在のものであることを指示する応答がサービスから返送され、そしてデータレコードのためのTTL値がリセットされる。
上述したキャッシュマネージメントポリシーを使用するのに加えて、一実施形態では、ある形式のデータに対するキャッシュ更新が、プッシュ通知サービス1050を使用して移動装置へプッシュされる。例えば、ユーザの友人リスト、又はユーザの友人の現在オンライン状態に対する変更は、ユーザの移動装置120へ動的にプッシュされる。プッシュ通知は、ゲームデーモン2020により受け取られ、ゲームデーモンは、次いで、サービスによってプッシュされるデータの当該部分を含むようにキャッシュ2021を更新する(即ち、そのサービスに関連したキャッシュ内の全てのデータの更新が要求されるのではない)。対照的に、あるプッシュ通知は、キャッシュの全コンテンツ(又はプッシュを遂行するサービスに関連したキャッシュの少なくとも一部分)をオーバーライトするようにゲームデーモン2020に命令する。
プッシュを利用してキャッシュ2021を更新するサービスは、キャッシュ2021に記憶されたデータを更新するための通知をプッシュできるので、比較的高いTTL値を選択する(及び/又はTTL値をセットしない)。一実施形態において、各サービスは、プッシュ通知キャッシュ更新をトリガーする1組の事象を指定する。例えば、キャッシュ更新事象は、友人のオンライン状態に対する変更、新たな友人要求、友人要求の受け容れ、友人解除(de-friend)動作、友人が特定ゲームをプレイしているという指示、友人が到達したゲーム実績、特定のスコアボードのトップ10に対する更新、又はキャッシュ更新を保証するに充分なほど重要であると思われる他の事象を含む。このようにプッシュ通知を使用してキャッシュ2021を更新することは、ネットワーク及びサービス負荷を減少する。というのは、プッシュ更新では、移動装置とサービスとの間の周期的なポーリングが要求されないためである。
ゲームフレームワーク2000の一実施形態は、エンドユーザに提示されるデータを、ユーザの国及び/又は地理的位置に基づいて独特にフォーマットする。例えば、現在日時及び通貨値のような値は、異なる国及び位置にいるユーザにとって異なる仕方で提示される。例えば、米国では、日付フォーマットは、[月、日、年](例えば、April 25, 2010)であり、一方、他の国々では、日付フォーマットは、[日、月、年](例えば、25 April, 2010)である。同様に、米国及び他の国々で時刻を表わすときには、AM/PM呼称が使用され、そして時間と分との間にはコロンが使用される(例えば、3:00PM)。対照的に、他の多数の国々では、AM/PM故障を使用されず、及び/又は時間と分との間にコンマが使用される(例えば、15,00)。別の例として、世界の多くの地域ではメートル系が使用されるが、世界のある地域では使用されない(例えば、米国)。これらは、本発明の幾つかの実施形態により使用される単なる例示に過ぎないことに注意されたい。本発明の基礎的な原理は、特定の1組のデータフォーマットに限定されない。
一実施形態では、これらの異なるデータフォーマットは、スコアボードデータ、実績データ、友人データ、及び/又はゲームフレームワーク2000により処理される他のデータを表示するときに選択される。ゲームフレームワーク2000は、ユーザの国及び/又は地理的位置を種々の仕方で決定する。例えば、一実施形態では、この情報は、単にユーザのプロフィールデータに与えられ、及び/又はユーザのセルラーサービスプロバイダーに基づいて決定される。又、ユーザの位置は、例えば、グローバルポジショニングシステム(GPS)追跡を使用して決定される。
地理的位置及び/又は国に無関係な他の形式のデータフォーマットも、ゲームフレームワーク2000によって管理される。例えば、スコアボードデータを表示するときには、最低スコアのユーザをスコアボードの最上部に入れるか最下部に入れるか知ることが重要である。あるゲーム(例えば、ゴルフ、トラック、レース、スキー、等)では、数値が低いほど、成績が良いが、他のゲーム(例えば、フットボール、野球、等)では、数値が高いほど、成績が良い。従って、一実施形態では、アプリケーション2030は、API2001を経て使用されるスコアの形式を指定する(例えば、「増加順」又は「減少順」)。次いで、ゲームフレームワーク2000は、スコアを表示するための適当な1組のラベル及びフォーマットを使用する。
又、ゲームフレームワーク2000の一実施形態では、ユーザとユーザの友人との間の関係に基づいてユーザデータがフィルタリングされる。例えば、本発明の一実施形態では、「詳細」図、「友人」図、及び「パブリック」図が許される。一実施形態において、詳細図は、データを所有するユーザに利用され(即ち、ユーザのパーソナル情報)、友人図は、ユーザの友人に利用され、そしてパブリック図は、他の全てのユーザに利用される。
一例として、パブリック図は、単に、各ユーザに関連した「エイリアス」名、エイリアスによりプレイされるゲーム及び関連スコア、並びにゲームをプレイした日時を含む。この情報は、ゲームフレームワーク2000により使用されて、パブリックスコアボードをポピュレートし、このスコアボードは、ゲームセンター2031を経て表示される。
友人図は、一般的な図からの全ての情報、及びユーザの友人の間で共有される付加的な情報を含み、これは、幾つか挙げると、例えば、ユーザにより所有されるゲーム、ユーザによりプレイされるゲーム、ユーザの実績及びスコア、ユーザが何人の友人をもつか、それら友人のアイデンティティ、ユーザの化身を識別するURL、及び/又はユーザのオンライン状態を含む。一実施形態において、「友人」図は、友人で共有されるべき情報のデフォールトセットを与えるが、エンドユーザは、このデフォールト構成を調整し、そして特に情報の形式で、各個々の友人又は友人グループ(例えば、同僚、家族メンバー、大学/高校の友人、等)により共有されることを指定する。
「詳細」図は、「パブリック」及び「友人」図からの全ての情報、並びにエンドユーザに代わって種々のサービス2050により管理される他の情報を含む。例えば、これは、ユーザのプロフィールデータ、ユーザのユニバーサルユニーク識別子(UUID)(ここでは「プレーヤID」とも称される)、プレーヤの名前、エイリアス名、ゲームの数及びゲームのアイデンティティ、ユーザの友人、全ユーザ実績、等、の全てを含む。
ある環境において、アプリケーション2030は、各ユーザのプレーヤIDのような、各ユーザに関連した少量の情報しか要求しない。例えば、一実施形態では、対戦が要求されるときに、ゲームフレームワーク2000は、最初に、各プレーヤのIDしか要求しない。マッチメーカーサービスにより対戦が決められたとき(前記参照)、ゲームフレームワーク2000は、対戦ユーザのいずれかが友人であるかどうか決定する(例えば、友人サービスとの通信を経て、及び/又はユーザのローカル友人データに質問することにより)。もしそうであれば、ゲームフレームワーク2000は、付加的なユーザデータを検索し、そしてそのデータを対戦友人に与える。このように、ゲームフレームワーク2000は、ユーザのアイデンティティ及び各ユーザ間の関係に基づいて情報をフィルタリングする。
一実施形態では、ゲームフレームワーク2000は、最初に、2人のユーザが友人関係をもたない場合に、第1ユーザと第2ユーザとの間にパブリック図を与える。しかしながら、一実施形態では、ゲームフレームワーク2000は、第1ユーザが第2ユーザに友人要求を送信するのを許す(例えば、第2ユーザのエイリアスを使用して)。友人要求が受け容れられた場合には、ゲームフレームワーク2000は、各ユーザに付加的な情報を与える(例えば、デフォールト「友人」図)。
異なるAPI実施形態
一実施形態において実施されるAPIは、ソフトウェアコンポーネント(以下、「API実施ソフトウェアコンポーネント」)により実施されるインターフェイスであり、これは、異なるソフトウェアコンポーネント(以下、「APIコールソフトウェアコンポーネント」)が、API実施ソフトウェアコンポーネントにより提供される1つ以上の機能、方法、手順、データ構造、及び/又は他のサービスにアクセスしてそれらを使用するのを許す。例えば、APIは、APIコールソフトウェアコンポーネントの開発者(第三者の開発者)が、API実施ソフトウェアコンポーネントにより与えられる指定の特徴をレバレッジするのを許す。1つのAPIコールソフトウェアコンポーネントが存在してもよいし、又は2つ以上のそのようなソフトウェアコンポーネントが存在してもよい。APIは、ソフトウェアアプリケーションからのサービス要求をサポートするためにコンピュータシステム又はプログラムライブラリーが提供するソースコードインターフェイスである。APIは、データがメモリにおいてどのようにレイアウトされるかの明確な低レベル記述ではなく、アプリケーションが構築されるときに解釈でき又はコンパイルできるプログラミング言語に関して指定される。
APIは、API実施ソフトウェアコンポーネントの指定の特徴にアクセスしてそれを使用するときにAPIコールソフトウェアコンポーネントが使用する言語及びパラメータを定義する。例えば、APIコールソフトウェアコンポーネントは、APIにより露出される1つ以上のAPIコール(機能又は方法コールとも称される)を通してAPI実施ソフトウェアコンポーネントの指定の特徴にアクセスする。API実施ソフトウェアコンポーネントは、APIコールソフトウェアコンポーネントからのAPIコールに応答して、APIを通して値を返送する。APIは、APIコールのシンタックス及び結果を定義するが(例えば、APIコールをどのように呼び出すか及びAPIコールが何を行うか)、典型的に、APIは、APIコールによって指定された機能をAPIコールがどのように遂行するか明らかにしない。種々の機能コール又はメッセージは、コールソフトウェア(APIコールソフトウェアコンポーネント)とAPI実施ソフトウェアコンポーネントとの間で1つ以上のアプリケーションプログラミングインターフェイスを経て転送される。機能コール又はメッセージを転送することは、機能コール又はメッセージを発行し、開始し、呼び出し、コールし、受信し、返送し、又は応答することを含む。ここで、APIコールソフトウェアコンポーネントは、コールを転送し、そしてAPI実施ソフトウェアコンポーネントは、コールを転送する。
一例として、API実施ソフトウェアコンポーネント2010及びAPIコールソフトウェアコンポーネントは、オペレーティングシステム、ライブラリー、装置ドライバー、API、アプリケーションプログラム、又は他のソフトウェアモジュールである(API実施ソフトウェアコンポーネント及びAPIコールソフトウェアコンポーネントは、互いに同じ形式のソフトウェアモジュールでもよいし、異なる形式のソフトウェアモジュールでもよいことを理解されたい)。APIコールソフトウェアコンポーネントは、ローカルソフトウェアコンポーネントである(即ち、API実施ソフトウェアコンポーネントと同じデータ処理システム上にある)か、リモートソフトウェアコンポーネントであって(即ち、API実施ソフトウェアコンポーネントとは異なるデータ処理システム上にあって)、APIを通りネットワークを経てAPI実施ソフトウェアコンポーネントと通信するものである。又、API実施ソフトウェアコンポーネントは、APIコールソフトウェアコンポーネントとしても働き(即ち、異なるAPI実施ソフトウェアコンポーネントにより露出されるAPIへAPIコールを発信し)、そしてAPIコールソフトウェアコンポーネントは、異なるAPIコールソフトウェアコンポーネントへ露出されるAPIを実施することによりAPI実施ソフトウェアコンポーネントとしても働くことを理解されたい。
APIは、異なるプログラミング言語で書かれた複数のAPIコールソフトウェアコンポーネントがAPI実施ソフトウェアコンポーネントと通信するのを許す(従って、APIは、API実施ソフトウェアコンポーネントとAPIコールソフトウェアコンポーネントとの間でコールを変換して返送する特徴を含む)が、APIは、特定のプログラミング言語に関して実施されてもよい。
図21は、API2120を実施するAPI実施ソフトウェアコンポーネント2110(例えば、オペレーティングシステム、ライブラリー、装置ドライバー、API、アプリケーションプログラム、又は他のソフトウェアモジュール)を含むAPIアーキテクチャーの一実施形態を示す。API2120は、APIコールソフトウェアコンポーネント2130により使用されるAPI実施ソフトウェアコンポーネントの1つ以上の機能、方法、クラス、オブジェクト、プロトコル、データ構造、フォーマット、及び/又は他の特徴を指定する。API2120は、API実施ソフトウェアコンポーネントの機能がAPIコールソフトウェアコンポーネントからパラメータをどのように受け取るか及びその機能が結果をAPIコールソフトウェアコンポーネントへどのように返送するか指定する少なくとも1つのコール規定を指定することができる。APIコールソフトウェアコンポーネント2130(例えば、オペレーティングシステム、ライブラリー、装置ドライバー、API、アプリケーションプログラム、又は他のソフトウェアモジュール)は、API2120により指定されたAPI実施ソフトウェアコンポーネント2110の特徴にアクセスしてそれを使用するためにAPI2120を通してAPIコールを発信する。API実施ソフトウェアコンポーネント2110は、APIコールに応答してAPI2120を通してAPIコールソフトウェアコンポーネント2130へ値を返送する。
API実施ソフトウェアコンポーネント2110は、API2120を通して指定されず且つAPIコールソフトウェアコンポーネント2130に利用できない付加的な機能、方法、クラス、データ構造、及び/又は他の特徴を含むことが明らかであろう。APIコールソフトウェアコンポーネント2130は、API実施ソフトウェアコンポーネント2110と同じシステム上にあってもよいし、又はリモート位置にあって、ネットワークを経てAPI2120を使用してAPI実施ソフトウェアコンポーネント2110にアクセスするようにしてもよいことを理解されたい。図21は、API2120と相互作用する単一のAPIコールソフトウェアコンポーネント2130を示すが、APIコールソフトウェアコンポーネント2130とは異なる言語(又は同じ言語)で書かれた他のAPIコールソフトウェアコンポーネントが、API2120を使用してもよいことを理解されたい。
API実施ソフトウェアコンポーネント2110、API2120、及びAPIコールソフトウェアコンポーネント2130は、マシン(例えば、コンピュータ又は他のデータ処理システム)により読み取れる形態で情報を記憶するメカニズムを含むマシン読み取り可能な媒体に記憶される。例えば、マシン読み取り可能な媒体は、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置、等を含む。
図22(ソフトウェアスタック)の規範的な実施形態において、アプリケーションは、多数のサービスAPIを使用してサービス1又は2へ、及び多数のOS APIを使用してオペレーティングシステム(OS)へコールを発信する。サービス1及び2は、多数のOS APIを使用してOSへコールを発信する。
サービス2は、2つのAPIを有し、その一方(サービス2のAPI1)は、アプリケーション1からコールを受け取ってそこへ値を返送し、そしてその他方(サービス2のAPI2)は、アプリケーション2からコールを受け取ってそこへ値を返送することに注意されたい。サービス1(例えば、ソフトウェアライブラリー)は、OS API1へコールを発信してそこから返送値を受け取り、そしてサービス2(例えば、ソフトウェアライブラリー)は、OS API1及びOS API2の両方へコールを発信してそこから返送値を受け取る。アプリケーション2は、OS API2へコールを発信してそこから返送値を受け取る。
規範的なデータ処理装置
図23は、本発明の幾つかの実施形態に使用される規範的なコンピュータシステムを示すブロック図である。図23は、コンピュータシステムの種々のコンポーネントを示しているが、その細部は本発明には関係ないものであるから、それらコンポーネントの特定のアーキテクチャー又は接続の仕方を表わすことを意図していないことを理解されたい。それより少数のコンポーネント又は多数のコンポーネントを有する他のコンピュータシステムも、本発明に使用できることが明らかである。
図23に示すように、データ処理システムの形態であるコンピュータシステム2300は、バス2350を備え、これは、処理システム2320、電源2325、メモリ2330、及び不揮発性メモリ2340(例えば、ハードドライブ、フラッシュメモリ、相変化メモリ(PCM)、等)に結合される。バス2350は、この分野で良く知られたように、種々のブリッジ、コントローラ、及び/又はアダプタを通して互いに接続される。処理システム2320は、メモリ2330及び/又は不揮発性メモリ2340からインストラクション(1つ又は複数)を検索し、そしてそれらインストラクションを実行して、上述した動作を遂行する。バス2350は、前記コンポーネントを一緒に相互接続すると共に、それらのコンポーネントを、任意のドック2360、ディスプレイコントローラ&ディスプレイ装置2370、入力/出力装置2380(例えば、NIC(ネットワークインターフェイスカード)、カーソルコントロール(例えば、マウス、タッチスクリーン、タッチパッド、等)、キーボード、等)、及び任意のワイヤレストランシーバ2390(例えば、Bluetooth、WiFi、赤外線、等)へも相互接続する。
図24は、本発明の幾つかの実施形態に使用される規範的なデータ処理システムを示すブロック図である。例えば、データ処理システム2400は、ハンドヘルドコンピュータ、パーソナルデジタルアシスタント(PDA)、移動電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、又は移動電話やメディアプレーヤやゲームシステムを含むハンドヘルドコンピューティング装置である。別の例として、データ処理システム2400は、ネットワークコンピュータ、又は別の装置内の埋め込み型処理装置である。
本発明の一実施形態によれば、データ処理システム2400の規範的なアーキテクチャーは、上述した移動装置に使用される。データ処理システム2400は、処理システム2420を備え、これは、1つ以上のマイクロプロセッサ及び/又は集積回路上のシステムを含む。処理システム2420は、メモリ2410、電源2425(1つ以上のバッテリを含む)、オーディオ入力/出力2440、ディスプレイコントローラ・ディスプレイ装置2460、任意の入力/出力2450、入力装置2470、及びワイヤレストランシーバ2430に結合される。図24に示されていない付加的なコンポーネントも、本発明の幾つかの実施形態ではデータ処理システム2400の一部分であり、又、本発明の幾つかの実施形態では、図24に示されたものより少数のコンポーネントが使用されてもよい。更に、この分野で良く知られているように、種々のコンポーネントを相互接続するため、図24には示されていない1つ以上のバスが使用されてもよい。
メモリ2410は、データ処理システム2400で実行するためのデータ及び/又はプログラムを記憶する。オーディオ入力/出力2440は、例えば、音楽を演奏するためのマイクロホン及び/又はスピーカを含み、及び/又はスピーカ及びマイクロホンを通して電話機能を与える。ディスプレイコントローラ・ディスプレイ装置2460は、グラフィックユーザインターフェイス(GUI)を備えている。ワイヤレス(例えば、RF)トランシーバ2430(例えば、WiFiトランシーバ、赤外線トランシーバ、Bluetoothトランシーバ、ワイヤレスセルラー電話トランシーバ、等)は、他のデータ処理システムと通信するのに使用される。1つ以上の入力装置2470は、ユーザがシステムへ入力を与えることができるようにする。これらの入力装置は、キーパッド、キーボード、タッチパネル、マルチタッチパネル、等である。任意のための入力/出力2450は、ドックのコネクタである。
異なるサービスプロバイダーにわたるP2P接続を管理するための実施形態
本発明の一実施形態において、上述したアーキテクチャーは、異なるサービスプロバイダーのピアが、リアルタイムオーディオ、ビデオ及び/又はチャット接続のようなピア・ツー・ピア(P2P)接続を確立できるように拡張される。異なるサービスプロバイダーは、それら自身のプロトコル及びそれら自身のクライアントIDネームスペースを使用するので、本発明のこれらの実施形態は、装置が使用プロトコルに関わらず相互作用し且つネームスペースを単一のグローバルなネームスペースへと一体化できるようにする技術を提供する。
全てのシステムにおける全てのユーザのグローバルなネームスペースを追跡するためにグローバルなデータベースが維持される。しかしながら、サービスプロバイダーにわたって膨大な数のユーザが分散されると、グローバルなデータベースの解決策は、管理が困難となる。或いは又、要求された接続に誰が応答できるか識別するため、ユーザ及び/又はデータ処理装置を識別するのに使用される名前(例えば、ユーザID、電話番号)が他の全てのサービスプロバイダーへブロードキャストされてもよい。しかしながら、この場合も、そのようなシステムは、充分なスケールにならない(即ち、各試みられた接続に対してブロードキャストメッセージを送信すると、著しい量の帯域巾が消費される)。
以上の問題に対処するために、本発明の一実施形態は、接続の試み中にブルームフィルタを使用して、当該サービスプロバイダーを探索する。この実施形態は、図25−26に示すアーキテクチャーに関して説明する。図25には、サービスプロバイダーA 2510、サービスプロバイダーB 2511、サービスプロバイダーC 2512及びサービスプロバイダーD 2513、の4つのサービスプロバイダーが示されている。先の実施形態と同様に、各サービスプロバイダーは、サービスプロバイダーからデータ通信サービスが提供される1組のユーザのユーザID及び/又は電話番号を含む登録データベース2520−2523を管理する。一例として、図25において、ユーザA−C 2501−2503には、サービスプロバイダーA 2510からサービスが提供され、そしてユーザD−Fには、サービスプロバイダーD 2513からサービスが提供される。上述したように、一実施形態において、登録データベース2520−2523は、電話番号又はユーザIDを各ユーザのデータ処理装置のプッシュトークンへマップする。従って、サービスプロバイダーにより維持されるサーバーは、特定のサービスプロバイダーのユーザが、前記技術(例えば、図10−14及び関連記載を参照)を使用して、探索を行って互いにピア・ツー・ピア接続を確立できるようにする。一例として、サービスプロバイダーにより維持されるサーバーは、ユーザが、FaceTimeTMチャットセッション(本特許出願の譲受人により設計された技術)のようなオーディオ/ビデオチャットセッションを互いに確立できるようにする。
サービスプロバイダー自身のユーザ間にP2P接続を確立できるのに加えて、図25及び26に示す実施形態では、異なるサービスプロバイダーのユーザが互いにP2P接続を確立できるようにする。特に、図26に示すように、各サービスプロバイダーは、サービスプロバイダーの登録データベース2520、2523に最初に問合せをして、特定のユーザがサービスプロバイダーにより管理されるかどうか決定するためにユーザ位置サービス2600、2610を備えている。(図26には、簡単化のために2つのサービスプロバイダー(プロバイダーAおよびD)しか示されていない。)ユーザA 2501が、同じサービスプロバイダーにより管理される別のユーザ、例えば、ユーザB 2502とのP2P接続を要求する場合には、サービスプロバイダーAのユーザ位置サービス2600が登録データベースからユーザBを識別し、そして接続要求をユーザBへ送信する(例えば、ユーザBのプッシュトークンが登録データベース2520から検索される)。
しかしながら、ユーザAが、異なるサービスプロバイダーにより管理されるユーザ、例えば、ユーザF 2506とのP2P接続を要求する場合には、サービスプロバイダーA2510の位置サービス2600が、他のサービスプロバイダーの各々から受け取ったブルームフィルタ2601−2603を使用して異なるサービスプロバイダーにおいてユーザFを探索するよう試みる。特に、図26に示すように、各サービスプロバイダーは、登録データベース2520、2523の現在コンテンツに基づいてブルームフィルタを発生するためにブルームフィルタジェネレータ2650、2651を備えている。この分野の当業者に明らかなように、ブルームフィルタは、エレメントがセットのメンバーであるかどうかテストするのに使用されるスペース効率の良い確率データ構造体である。偽の肯定が考えられるが、偽の否定はない。ここに述べる実施形態では、各ブルームフィルタを発生するのに使用される「エレメント」は、各ユーザのユーザID及び/又は電話番号である。図26において、例えば、サービスプロバイダーA 2510のブルームフィルタジェネレータ2650は、全てのユーザID(Andy124、Tom4546、等)を使用して、そのブルームフィルタ2604を発生する。同様に、サービスプロバイダーD 2513のブルームフィルタジェネレータ2651は、その登録データベースにおける全てのユーザID(Woody1234、Rick456、等)を使用して、そのブルームフィルタ2603を発生する。一実施形態では、各サービスプロバイダーは、このようにそれ自身のブルームフィルタを発生し、そして他の全てのサービスプロバイダーにブルームフィルタを周期的に送信する。次いで、各サービスプロバイダーは、他のサービスプロバイダーから受け取ったブルームフィルタを使用して、特定のユーザが他のサービスプロバイダーにより管理されるかどうかテストし決定する。
一例として、図26において、Andy123のユーザIDを伴うユーザA 2051が、Woody123のユーザIDを伴うユーザF 2506とのP2Pセッション(例えば、パーソナルオーディオ/ビデオチャット)を確立するよう試みる場合には、サービスプロバイダーA 2510のユーザ位置サービス2600が、最初に、それ自身の登録データベース2520においてユーザFのユーザ名、Woody123を探索するように試みる。不成功の場合には、一実施形態において、他のサービスプロバイダーのブルームフィルタ2601−2603に問合せし、ユーザID“Woody123”を管理するサービスプロバイダーを探索するよう試みる。上述したように、ブルームフィルタは、偽の肯定を与えることがあるが、偽の否定は与えない。従って、サービスプロバイダーB及びCがWoody123を管理しないことをブルームフィルタが指示する場合に、サービスプロバイダーAは、Woody123がこれらのサービスプロバイダーによって管理されないことを最終的に知る。ここに示す例では、ブルームフィルタの問合せは、Woody123がサービスプロバイダーDによって管理されることを指示すると共に、Woody123が1つ以上の他のサービスプロバイダーによって管理されることも指示する。従って、一実施形態では、サービスプロバイダーAは、開始メッセージ(例えば、ユーザFをP2Pセッションに招待するINVITEコマンド)を、このユーザIDを潜在的に管理する各サービスプロバイダーへ送信する。実際に、このユーザIDを管理するサービスプロバイダーは、サービスプロバイダーAに肯定応答する。正しいサービスプロバイダーがそれ自身、この例ではサービスプロバイダーD、を識別すると、2つのサービスプロバイダーは、各ユーザ(この例ではユーザA及びF)についてプロキシーとして働き、そしてユーザ間の通信チャンネルをオープンさせる。ユーザA及びFは、接続データを交換すると、直接的P2P通信チャンネルを互いにオープンする(例えば、図11を参照して上述した技術を使用して交換し、及び/又は標準的なインターネット接続確立(ICE)トランザクションを実施することにより)。或いは又、直接的なP2P接続が実現不能である場合には(例えば、NAT形式が不適合であるために)、ユーザA及びFは、図13に示したリレーサービス1051を使用してリレー接続をオープンする(図12及び関連記載も参照)。
一実施形態において、各サービスプロバイダーは、それ自身のブルームフィルタを連続的に更新し、そしてそのブルームフィルタを、P2Pオーディオ/ビデオ接続をサポートすることに関与する他のサービスプロバイダーの各々へ送信することが予想される。更新は、規則的な間隔(例えば、1時間に一度、毎日一度、等)で行われ、及び/又はある数の新たなユーザIDが登録データベースに追加された後に行われる。本発明の基礎的な原理は、ブルームフィルタをサービスプロバイダー間で交換する特定のメカニズムに限定されない。
ブルームフィルタを発生し更新するための方法の一実施形態が図27に示されている。この方法は、図25−26に示すアーキテクチャーで実行されるが、特定のシステムアーキテクチャーに限定されない。2701において、特定のサービスプロバイダーにおけるユーザ登録データベースが更新される。例えば、新たなユーザID/電話番号が追加され、古いユーザID/電話番号が削除される。2702において、ユーザID/電話番号の完全なセットを使用して新たなブルームフィルタが発生される。2703において、新たなブルームフィルタが参加サービスプロバイダーへ送信される。
ブルームフィルタを使用してクライアントに対するサービスプロバイダーを探索する方法の一実施形態が図27に示されている。この方法は、図25−26に示すアーキテクチャーで実行されるが、特定のシステムアーキテクチャーに限定されない。2801において、参加サービスプロバイダーのグループのブルームフィルタが受け取られる。ブルームフィルタは、効率的にアクセスするために揮発性メモリに記憶され、及び/又は不揮発性記憶位置へ存続される。2802において、別のユーザ(ユーザF)とのP2P接続を確立するためにユーザ(この例ではユーザA)から接続要求が受け取られる。2803において、ブルームフィルタ機能がユーザFのユーザID(例えば、前記例からのWoody123)に対して実行されて、あるサービスプロバイダーを除外する。ブルームフィルタ機能が特定のブルームフィルタについて否定結果を返送する場合には、ユーザFは、その特定のブルームフィルタによって管理されない。しかしながら、ブルームフィルタについて肯定結果が返送される場合には、そのブルームフィルタに関連したサービスプロバイダーがユーザFを管理する適度な機会が存在する。1つの肯定結果のみが返送される場合には、2804において、接続招待がそのサービスプロバイダーへ送信される。複数の肯定結果が返送される場合には、2804において、個別の接続招待が各関連サービスプロバイダーへ送信される。
次いで、ユーザFが登録を有するところのサービスプロバイダーが肯定応答し、そして2つのサービスプロバイダーが、2806において、プロキシーとして働いて、ユーザが上述したように接続データを交換するのを許す(例えば、プッシュトークン、パブリック/プライベートネットワークアドレス/ポート、NAT形式、等)。2つ以上のサービスプロバイダーが肯定応答する(2つのサービスプロバイダーが同じユーザIDをもつユーザをサポートすることを意味する)場合には、正しいユーザを識別するために付加的なステップが取られる(例えば、電話番号、本名、ネットワークアドレス、又は接続を望むユーザに関して知られている他の情報を比較する)。
ユーザFに対する正しいサービスプロバイダーが識別され、そして必要な接続データが交換されると、2807において、上述したように、ユーザAとユーザFとの間に直接的P2P接続又はリレー接続(必要に応じて)が確立される。
図11−12を参照して述べたように、本発明のある実施形態では、2人(以上)のユーザ間にP2P接続を確立するのに使用される種々のサーバーは、接続プロセス中に接続状態情報を維持する必要がない。これは、例えば、インビテーションサービス112及び接続データ交換サービス110を含む。むしろ、これら実施形態では、これに限定されないが、パブリック/プライベートIP及びポート(一般的にネットワーク情報とも称される)、NAT形式、ユーザID、プッシュトークン、等を含む完全な接続情報が累積されて、各次々のトランザクションで送信される。図29に示すように、各トランザクションで送信されるマルチプロバイダーコンテキストにおける状態情報の1つの付加的な断片は、プロバイダーIDコードである。
図29の特定の細部へ戻ると、ユーザAは、開始要求2901(ここでは「インビテーション」要求とも称される)を送信し、これは、それ自身のネットワークID(ID−A)、上述した技術を使用して決定されるそれ自身のネットワーク情報(例えば、パブリック/プライベートIP/ポートデータ、NAT形式、等)、それ自身のプッシュトークン(Token−A)、及びユーザFのIDコード、電話番号及び/又は他の形式の識別子を含む。この開始要求は、図25−28を参照して上述したいずれかの技術を実施するユーザAのサービスプロバイダーによって最初に受け取られて、ユーザFのサービスプロバイダーを探索する(例えば、ブルームフィルタを使用して、あるサービスプロバイダーを除外する)。(ユーザA及びユーザFのサービスプロバイダーは、簡単化のために図29には示されていない。)
一実施形態において、ユーザFのサービスプロバイダーが識別されると、ユーザFのサービスプロバイダーからユーザFへ開始プッシュ動作2902が送信され、これは、ユーザAのサービスプロバイダー、この例では「プロバイダーA」の識別子を含む。プロバイダーAの識別子は、Nビット識別コード(例えば、16ビット、32ビット、64ビット、等)のような簡単なものである。或いは又、プロバイダーAの識別子は、プロバイダーAのネットワークゲートウェイを識別するパブリックIPアドレス、又はプロバイダーDへ接続するのに必要な他のネットワークデータを含む。本発明の基礎的な原理は、一連のP2P接続トランザクションでプロバイダーAを識別するのに使用されるフォーマットに関わりなく同じである。
一実施形態において、上述したプッシュ通知サービス1050のようなプッシュ通知サービスによりプッシュトランザクション2902が発生される(例えば、図11及び関連テキストを参照)。上述したように、ユーザAによって与えられる全てのオリジナル状態情報、及びサービスプロバイダーAのサーバーによって収集される付加的な状態情報は、開始プッシュトランザクション2902に含まれる。
図29に示す例では、ユーザFは、受け容れトランザクション2903で応答し、これは、全ての以前の状態情報(ID−A、NetInfo−A、Provider A)を、P2P接続の確立に必要なユーザFの情報と共に含み、これは、例えば、ユーザFのID(ID−F)、ユーザFのネットワーク情報(NetInfo−F;これは、パブリック/プライベートIPアドレス/ポート、NAT形式、等を含む)、及びユーザFのトークン(Token−F)を含むが、これに限定されない。ユーザA及びユーザFの全ての接続状態情報は、ユーザFのサービスプロバイダー(この例では「プロバイダーD」)によって受け取られ、該プロバイダーは、それ自身のプロバイダーIDコードをトランザクションに添付し(Provider−D)、そしてそれをユーザAのサービスプロバイダーに転送する。プロバイダーAについて上述したように、プロバイダーDの識別子は、Nビット識別コードほど簡単である。或いは又、プロバイダーDの識別子は、プロバイダーDのネットワークゲートウェイを識別するパブリックIPアドレス、又はプロバイダーDに接続するのに必要な他のネットワークデータを含んでもよい。本発明の基礎的な原理は、一連のP2P接続トランザクション内でプロバイダーDを識別するのに使用されるフォーマットに関わりなく同じである。
全ての接続状態データがユーザAによって受信されると(プロバイダーDデータを含めて)、ユーザA及びユーザFは、トランザクション2905により示されたように、上述した技術を使用してP2P接続を確立する。
上述したように、ある条件のもとでは、ユーザA及びユーザFは、直接的P2P接続ではなく、リレーサービス1051(例えば、図10を参照)を通して接続を確立する必要がある。図30に示すように、一実施形態において、両サービスプロバイダーA及びFは、それら自身のリレーサービス3001−3002を使用する(及び/又は第三者リレーサービスとの関係を有する)。一実施形態において、ユーザAとユーザFとの間に試みられたP2P接続が失敗した場合には、サービスプロバイダーAのリレーサービス3001(即ち、P2P接続を開始するユーザのプロバイダー)を使用して、接続がサポートされる。別の実施形態では、ユーザFのリレーサービス3002(即ち、接続が要求されているユーザのプロバイダー)を使用して、接続がサポートされる(図31においてユーザA2501とリレーサービス3002とユーザF 2506との間の点線で示すように)。更に別の実施形態では、全てのプロバイダーが単一リレーサービスに合意し、そのリレーサービスを利用して、ユーザ間にP2P接続を確立する。
本発明の一実施形態では、ユーザ装置間にセキュアなオーディオ/ビデオP2P通信をサポートするために種々の異なる通信プロトコルが結合される。これらのプロトコルは、(これに限定されないが)P2P接続を経てセキュアな通信を与えるためのデータグラムトランスポートレイヤセキュリティ(DTLS);暗号、メッセージ認証及び完全性を与えるように意図されたRTP(リアルタイムトランスポートプロトコル)のプロフィールと、ユニキャスト(装置対装置)及びマルチキャスト(装置対複数装置)の両アプリケーションのためのRTPデータに対する再生保護とを定義するセキュアなリアルタイムトランスポートプロトコル(又はSRTP);及びユーザ装置間に音声/ビデオ接続を確立するためのセッションイニシエーションプロトコル(SIP);を含む。これらのプロトコルは、ここに述べる本発明のいずれかの実施形態の環境内で使用される。
一実施形態において、図25に示すオープンのプロバイダー間ネットワーク上の各装置は、STRPを使用してアイデンティティ検証及びストリームの端・端暗号化の目的で、他の装置に対してセキュアに識別することができる。セキュアな通信を可能にするために各サービスプロバイダーにより発行される必要のある証明書フォーマットについて以下に説明する。
一実施形態において、各プロバイダーは、他のピアプロバイダーをどのように発見するか知ることが必要である。一実施形態において、コールルーティング及びピア情報を問合わせるためのグローバルで且つセキュアなプロバイダーリストが存在する。これは、信頼性のあるサーバー及びそれらのアドレス情報のリストである。プロバイダーの1つがこのサービスのホストとなる。
プロバイダー間の接続を有効とし且つ信頼するためにプロバイダー間に必要とされるセキュリティ及び認証のレベルについて以下に述べる。これは、プロバイダーとグローバルなルックアップデータベースとの間に使用されるもの並びにP2P接続の認証に使用されるもの以外の1組のクレデンシャルである。
一実施形態において、コールルーティング時に、受信側のプロバイダー(即ち、被呼ユーザ)は、エンドポイント間のP2P接続を認証するのに使用するべく発呼者へ返送するピア証明書を与える。この証明書は、外部エンティティにより署名することができ、証明書の要件は、e−メールだけではなく、任意の形式のアイデンティティを許す。
更に、一実施形態において、オーディオ、ビデオ及びシグナリングデータは、単一のデータポートを経て各データ処理装置において一緒にマルチプレクスされる。次いで、オーディオ、ビデオ及びシグナリングデータは、行先装置においてデマルチプレクス及びデコードされる。
図25に示すプロバイダー間ネットワークは、多数の相互動作レイヤより成る。これらレイヤの相互作用は、種々のプロトコルにより指定される。この相互作用の目標は、接続を確立するユーザの要求を処理し、(図25にユーザA−F 2501−2506として識別された)ユーザエンドポイント間に必要な情報交換を遂行して、それらがオーディオ/ビデオコールセッションを確立できるようにすることである。
動作中に、図25に示すプロバイダー間ネットワークは、要求を発信したり要求に応答したりして互いに通信する1組のサーバーとして実施される。これらの要求は、ユーザエンドポイントがメディアチャンネル接続データを交換し且つオーディオ/ビデオコールセッションを形成できるように、要求を転送するのに必要なプロトコルアクションである。一実施形態において、各サービスプロバイダーは、そのユーザエンドポイントとの全ての直接通信を管理する。
一実施形態において、ユーザエンドポイントは、そのエンドポイントをコントロールする当事者を識別するユニフォームリソース識別子(URI)を経て表わされる。最初にサポートされるURIスキームは、tel:(電話番号のための)及びmailto:(e−メールアドレスのための)である。将来は、他のURIスキームがサポートされる。
一実施形態において、各ユーザエンドポイントへのURIのマッピングは、アイデンティティマッピングではなく、多対多の関係である。単一のURIは、多数のエンドポイントへマップされ、そして単一のエンドポイントは、多数のURIへマップされる。更に、URIからエンドポイントへのマッピングは、多数のプロバイダーに及ぶ。例えば、プロバイダーAに1つのエンドポイントがあり、プロバイダーBに異なるエンドポイントがあり、そしてそれらの両エンドポイントは、同じURIによりマップされる。(しかしながら、一実施形態では、エンドポイントは、一度に1つのプロバイダーによってホストされるだけである。)一実施形態において、エンドポイントURIは、電話番号及びe−メールアドレスのようなジェネリックなユーザレベル識別子である。プロバイダー及びエンドポイントへのそれらのマッピングは、システムによって遂行され、エンドユーザにとって透過的である。
一実施形態において、図25に示されたプロバイダー間通信に使用されるメタプロトコルは、HTTPを経てのディクショナリーである。この実施形態では、全てのアクションがHTTP GET又はPOSTとして遂行される。アクションがHTTP GETとして指定される場合には、ボディが空である。アクションがHTTP POSTとして指定される場合には、ボディがディクショナリーとしてエンコードされる要求パラメータを含む。応答は、ディクショナリーとしてエンコードされた応答パラメータを含むボディを有する。一実施形態において、ディクショナリーの初期エンコーディングは、アップル(R)XMLプロパティリストである。JSON又はプロトコルバッファのような他のエンコーディングも使用される。一実施形態において、異なるサービスプロバイダーが、任意の1組のプロトコル又は通信メカニズムを使用して、個々のユーザ装置と通信する。
一実施形態において、図25に示すサービスプロバイダーが互いに発見するのを許すためにプロバイダー発見プロトコルが使用される。一実施形態において、ブートストラップURIがネットワークの管理エンティティ(例えば、一次又は管理サービスプロバイダー)により出版される。このブートストラップURIは、このネットワークの受け容れられたメンバーである1組のプロバイダーを含む発見ディクショナリーを指す。サービスプロバイダーごとに、このディクショナリーは、識別情報を含むと共に、このプロバイダーとどのように通信するか指定する更に別のURIも含む。一実施形態において、サービスプロバイダーが始動するとき及びその後は周期的に、それらが発見ディクショナリーを検索する。次いで、それらは、ディクショナリーの情報に基づいて他のプロバイダーと通信するようにそれら自体を構成する。
ユーザ間にP2P通信セッションを確立するための特定の1組のプロトコルの詳細を以下に説明する。しかしながら、これらの特定の詳細は、特定の実施形態を示すに過ぎず、本発明の基礎的な原理に合致するために要求されるものではない。
1.インビテーションプロトコル
1つの実施形態のインビテーションプロトコルは、初期コールセットアップに使用される。これは、ビデオコールセッションのメディアチャンネルの確立に使用されるメディアチャンネル接続データを交換するためにユーザエンドポイント(例えば、図25のユーザエンドポイント2501−2506)により使用されるアウトオブバンドシグナリングである。
1.1.アクション
インビテーションプロトコルには4つのメインアクションがある。
1.1.1.開始
コールをスタートするために開始エンドポイントにより送信する。フィールド:セッションid、自己uri、自己トークン、自己ブロブ、ピアuri。
1.1.2.受け容れ
コールに参加する意志を示すために受信エンドポイントにより送信する。
フィールド:セッションid、自己uri、自己トークン、自己ブロブ、ピアuri、ピアトークン、ピアブロブ。
1.1.3.拒絶
コールに参加する意志がないことを示すために受信エンドポイントにより送信する。フィールド:セッションid、自己uri、自己トークン、自己ブロブ、ピアuri、ピアトークン、ピアブロブ。
1.1.4.キャンセル
コールを終了すべきことを示すためにいずれかのエンドポイントにより送信する。フィールド:セッションid、自己uri、自己トークン、自己ブロブ、ピアuri、ピアトークン、ピアブロブ。
1.2.アクション変化
アクションにサービスしている当事者に基づき、これらは、次の3つの形態をとる。
*要求(エンドポイントからプロバイダー)
*転送(プロバイダーからプロバイダー)
*プッシュ(プロバイダーからエンドポイント)
1.3.コールフロー
1.3.1.ユーザエントリ
エンドポイントは、それが接続を確立したいとき、受信エンドポイントを識別するためにURIを必要とする。このURIは、おそらく、ユーザによって提供されるある情報、例えば、ダイヤルされた電話番号、又はアドレス帳に記憶されたe−メールアドレスから導出される。次いで、エンドポイントは、そのホストプロバイダー上の開始要求にコールする。
1.3.2.開始要求
開始プロバイダーは、URIを見て、そのURIによりマップされるエンドポイントをホストする1組の受信プロバイダーを決定する。(この1組のプロバイダーは、開始プロバイダーそれ自身を含む。)次いで、全ての適用可能な受信プロバイダー上の開始転送にコールする。
1.3.3.開始転送
各受信プロバイダーは、受信エンドポイントを決定し、そしてそれに開始プッシュを送信する。
1.3.4.開始プッシュ
受信エンドポイントは、開始プッシュを得て、ユーザに情報を提示する。(これは、典型的に、「XXXがコールしている」ラインに沿ったUIである。)ユーザがコールを行うように判断した場合には、エンドポイントは、受け容れ要求にコールする。(さもなければ、拒絶要求にコールする。)
1.3.5.受け容れ要求
受信エンドポイントは、そのホストプロバイダー上の受け容れ要求にコールする。
1.3.6.受け容れ転送
受信プロバイダーは、受け容れプッシュを開始エンドポイントへ送信する。
1.3.7.受け容れプッシュ
開始エンドポイントは、受け容れプッシュを得て、接続を形成して進めることをユーザに指示する。この点において、両エンドポイントは、メディアチャンネル接続データを交換し、従って、それらは、オーディオ/ビデオコールセッションのためのメディアチャンネルを確立する準備ができる。ここから、流れは、メディアセッションマネージメント(以下の)に文書化されたメディアチャンネルエスタブリッシュメントに続く。
2.ディスパッチ最適化プロトコル
前記で詳細に述べたように、一実施形態において、ブルームフィルタは、開始コール要求に応答できる候補サービスプロバイダーを選択するのに使用される。一実施形態において、プロバイダーは、それが現在ホストしているエンドポイントの全てのURIを表わす最新のブルームフィルタを維持することが要求される。全てのプロバイダーのブルームフィルタが増分形態で他の全てのプロバイダーへ配布される。
ディスパッチ最適化プロトコル:発信コールをディスパッチするときに、プロバイダーは、先ず、他の全てのプロバイダーのブルームフィルタに相談する。それにより、プロバイダーは、コールに実際にサービスできるプロバイダーの候補セットを得る。次いで、開始アクションがその候補リストのみに送られる。
3.メディアセッションマネージメント
メディアセッションマネージメントは、メディアチャンネルのセットアップ、コントロール及びティアダウン、並びにメディアチャンネル上に流れるメディアストリームを指す。メディアセッションマネージメントは、以下に詳細に述べる。
4.メディアチャンネル確立
メディアシグナリング、メディアフロー、及びセッションティアダウンのためのネットワークパケットがメディアチャンネルを経て送信される。メディアチャンネルは、NAT横断又はリレー構成のいずれかにより確立される(前記で詳細に述べたように)。NAT横断及びリレー構成は、両方とも、各エンドポイントが両エンドポイントのメディアチャンネル接続データを所有することを要求する。
4.1.NAT横断プロトコル
一実施形態において、NAT横断プロトコルは、直接的ピア・ツー・ピア接続を経てメディアチャンネルを確立するのに使用される。これは、双方向接続確立(ICE)[RFC5245]に網羅された技術の使用を含む。
4.2.リレー構成プロトコル
一実施形態において、リレープロトコルは、リレーネットワークを経てメディアチャンネルを確立するのに使用される。一実施形態において、このプロトコルは、TURN[RFC5761]の使用を含む。
5.メディアチャンネルシグナリング
メディアシグナリングは、メディアネゴシエーション及びメディア暗号化のためのセキュリティの設定と、オーディオ及びビデオパラメータのためのメディアネゴシエーションとをカバーする。
5.1.セキュリティの設定
上述したように、一実施形態において、データグラムトランスポートレイヤセキュリティ(DTLS)[RFC4347]は、メディアチャンネルにわたるネットワークトラフィックの通信をセキュアなものにするために使用される。DTLSプロトコルは、サービスプロバイダーが、ユーザ間で送信される音声/ビデオパケット内の暗号コンテンツにアクセスできないように、端・端暗号化を与えるように実施される。
5.2.メディアネゴシエーション
一実施形態において、SIP[RFC3261]は、ビデオコールセッションのオーディオ及びビデオパラメータをネゴシエーションするのに使用される。
5.3.オーディオ及びビデオ暗号化
一実施形態において、SRTP[RFC3711]は、オーディオ及びビデオペイロードを暗号化するのに使用される。
6.メディアフローコントロール
メディアフローコントロールは、アクティブなメディアストリームのマネージメント、及びメディアチャンネルを経てのメディア状態変化の通知をカバーする。
6.1.ネットワーク適応
一実施形態において、通信チャンネルの変動を考慮するためにネットワーク適応技術が実施される。特に、ユーザエンドポイントは、スループット、パケットロス及びレイテンシーの変化のような変化するネットワーク状態に適応させるため、オーディオ及び/又はビデオビットレートのようなストリームパラメータを調整する。
6.2.ビデオミューティング
エンドポイント送信ビデオは、ビデオをミュート/アンミュートする。SIP MESSAGEを使用してリモートエンドポイントに通知が送られる。
6.3.ビデオの方向
エンドポイント送信ビデオは、ビデオの方向を変更する。RTPヘッダ拡張情報を使用してリモートエンドポイントに通知が送られる。
6.4.ビデオスイッチング
エンドポイント送信ビデオは、ビデオのソースを切り換える。例えば、前向き及び後向きの両カメラを含むユーザ装置では、ビデオが前向きから後向きへ切り換える。RTPヘッダ拡張情報を使用してリモートエンドポイントへ通知が送られる。
6.5.ハングアップ
一実施形態において、エンドポイントは、SIP BYEメッセージを送信することによりアクティブなセッションを明確に終了させる。
7.メディアチャンネルティアダウン
メディアセッションは、明確に又は暗示的にティアダウンされる。メディアチャンネルの明確なティアダウンは、SIP BYEメッセージを送信又は受信することにより行われる。暗示的なティアダウンは、ネットワーク接続ロス又は悪いネットワーク性能のために生じる。
8.セキュリティ
8.1.証明書
一実施形態において、図25に示すプロバイダー間システムのエンドポイント間の通信は、パブリックキー暗号化を使用してセキュアなものとされる。各エンティティ(プロバイダー及びエンドポイント)は、そのアイデンティティに署名する信頼できるCAにより発行された証明書を有する。この証明書は、エンティティに属するURI及び他の識別情報を含む。証明書は、通信時にエンティティのアイデンティティを検証するために相手方によって使用される。
8.2.メディアチャンネルシグナリング
SIPメッセージは、DTLS[RFC4347]を使用してセキュアなものとされる。
8.3.オーディオ及びビデオ
オーディオ及びビデオストリームは、SRTP[RFC3711]を使用してセキュアなものとされる。
9.エンコーディング
9.1.オーディオ
9.1.1.オーディオCodec
オーディオCodecは、MPEG−4改善型低遅延AAC(AAC−ELD、ISO/IEC 14496−3)に準じたものである。
9.1.2.音質
一実施形態において、オーディオ信号の音響特性は、ワイドバンド電話端子の3GPP仕様、TS26.131及びTS26.132により指定される。
9.1.2.オーディオRTPペイロードフォーマット
9.2.ビデオ
一実施形態において、ビットストリーム内でビデオストリーム記述を実行するためシーケンスパラメータセット(SPS)及びピクチャーパラメータセット(PPS)NALUが使用される。
9.2.1.ビデオCodec
一実施形態において、図25に示すユーザ間の通信に使用されるビデオCodecは、bフレームなしのH.264高プロフィール、レベル1.2(有効QVGA15fps、max300kbps)である。しかしながら、本発明の基礎的な原理は、特定のオーディオ/ビデオフォーマットに限定されないことに注意されたい。
9.2.2.ビデオRTPペイロードフォーマット
上述したように、ユーザエンドポイント間のオーディオ/ビデオ通信をサポートするためにリアルタイムトランスポートプロトコル(RTP)が使用される。図32に示すように、一実施形態において、RFC3984ヘッダ3202(即ち、RFC3984、H.264ビデオのためのRTPペイロードフォーマットにより定義された)が各12バイトRTPペイロード3201(RTPデータパケットを含む)に添付される。ヘッダは、H.264画像記述拡張を使用してRTPデータをどのようにパケット化するか指定する。
セキュアなインスタントメッセージングのためのシステム及び方法
本発明の一実施形態は、インスタントメッセージング及びビデオチャットのようなアプリケーションに対して移動装置間でセキュアなピア・ツー・ピアセッションを行えるようにするアーキテクチャーを提供する。図33に示すように、本発明のこの実施形態は、ユーザを認証するためのアイデンティティサービス3301、(上述したように)移動装置へ通知をプッシュするためのプッシュ通知サービス1050、及び2人以上の移動ユーザ(図33にはユーザA 110及びB 111が示されている)間にセキュアなインスタントメッセージングセッションを確立するためのセキュアなインスタントメッセージングサービス3302を備えている。一実施形態において、アイデンティティサービス3301は、アクティブなユーザIDのユーザ登録ディレクトリ3302、認証キー及びプッシュトークンを管理し、それらは、移動装置へプッシュ通知を送信するためにここに述べるように通知サービス1050により使用される。一実施形態において、ユーザIDは、e−メールアドレスであるが、本発明の既存的な原理は、特定形式のユーザIDに限定されない。更に、単一のユーザが異なるアプリケーション(例えば、インスタントメッセージング、ビデオチャット、ファイルシェアリング、等)に対して多数のユーザIDを有し、そして異なる移動装置(例えば、本特許出願の譲受人によって設計されたiPhoneTM(R)及び個別のiPadTM(R)装置)を有してもよい。
セキュアなピア・ツー・ピア通信チャンネルを確立するためのコンピュータ実施方法の一実施形態が図34に示されている。この方法は、最初に、図33に示すアーキテクチャーの環境内で説明するが、本発明の基礎的な原理は、この特定のアーキテクチャーに限定されないことに注意されたい。
3401において、ユーザAは、ユーザBの識別子(例えば、ユーザBのe−メールアドレス及び/又は電話番号)を含む問合せをアイデンティティサービス3301へ送信して、ユーザBとのセキュアな通信チャンネルを開始する。それに応答して、アイデンティティサービス3301は、3402において、ユーザIDが問合せに一致するかどうか(例えば、ユーザBのe−メールアドレス又は電話番号がアイデンティティサービス内に登録されているかどうか)決定する。もしそうでなければ、3403において、アイデンティティサービスは、失敗通知をユーザAへ送信する。
一致が見つかった場合には、3404において、ユーザAは、ユーザBのネットワークアドレス情報及びパブリックキーをアイデンティティサービス3301から検索する。一実施形態において、アドレス情報は、ユーザBのコンピューティング装置のトークンを含み、従って、ユーザAがこの特定のアドレスをもつユーザBと話をするのを許可する(装置Aのトークンは、Bのトークンと話ができる)。ユーザBが複数の装置を有する場合には、複数のトークンがアイデンティティサービス3301から与えられ(装置ごとに1つ)そしてユーザAへ個別にルーティングされる。
一実施形態において、セッションキーも発生され(ここでは「問合わせ署名」とも称され)、これは、アイデンティティサービス3301によって与えられる現在時間のタイムスタンプ、ユーザAのID、ユーザBのID、ユーザAのトークン、及びユーザBのトークンの上の署名である。このセッションキーは、その後、(以下に述べるように)アイデンティティサービスを伴わずに2人のユーザを認証するためにセキュアなIMサービス3302により使用される。
ユーザAは、今や、これらアドレスユニット(ターゲットID/トークン)の各々に対してアドレス情報及びパブリックキーを有する。3404において、装置Aは、ユーザBへ送信されるべきメッセージ及びアタッチメントをユーザAのプライベートキー及び装置Bのパブリックキーで暗号化する。一実施形態において、これは、テキスト/アタッチメントのコンテンツをユーザBのキーで暗号化しそしてそのコンテンツをユーザAのキーで署名することを含む。暗号化されると、メッセージは、ユーザAとユーザBとの間に位置するいずれのサーバーでも解読できないが、サーバーは、送信されるメッセージの形式(例えば、それがテキストメッセージであるか読み取った受領書であるか)を見ることができる。ユーザBのパブリックキーを使用した暗号化の結果として、ユーザBだけがメッセージのコンテンツを読み取ることができる。又、ユーザBは、ユーザAの署名を使用して送信者(ユーザA)を検証することもできる。
3406において、ユーザAは、データグラムトランスポートレイヤセキュリティ(DTLS)を使用してプッシュ通知サービス1050でセキュアな通信チャンネルをオープンし、そして暗号化されたメッセージを、ユーザBのトークン、ユーザID、及びユーザAのユーザIDと共にプッシュ通知サービス1050へ送信する。当業者に知られたように、DTLSプロトコルは、通信のプライバシーを与え、盗聴、改竄又はメッセージ偽造を防止するように設計された仕方でデータグラムベースのアプリケーションが通信するのを許す。DTLSプロトコルに関連した特定の細部は、良く知られているから、ここでは詳細に述べない。
一実施形態において、ユーザAのトークンは、この段階では、プッシュ通知サービス1050へ送信されず、プッシュ通知サービス1050とのユーザAの通信に基づいて推測される。3407において、プッシュ通知サービス1050は、セキュアなインスタントメッセージングサービス3302とのセキュアな通信チャンネルをオープンし、そして要求があった際に、セキュアなインスタントメッセージングサービスにユーザAのプッシュトークンを与える。従って、この段階において、セキュアなインスタントメッセージングサービス3302は、ユーザBのトークン及びID、並びにユーザAのトークン及びIDを有する。一実施形態において、例えば、ユーザBのトークン及びID、ユーザAのトークン及びID、並びにタイムスタンプでセッションキーを再発生し、そしてその発生されたセッションキーをプッシュ通知サービス1050から受け取られたものと比較することにより、上述したセッションキーを使用してこの情報を検証する。一実施形態において、現在のタイムスタンプがオリジナルのタイムスタンプの遥かに前方にある場合には、署名が一致せず、検証失敗が生じる。署名が一致する(即ち、メッセージに満足な署名がある)場合には、3409において、セキュアなインスタントメッセージングサービス3302は、プッシュ通知サービス1050との第2の出て行くセキュアな通信チャンネルをオープンし、ユーザAのプッシュトークンをメッセージに追加し(ユーザBのプッシュトークン及びIDと共に)、そしてメッセージを、ユーザBへの配布のためにプッシュ通知サービス1050へ送信する。重要なことに、この段階では、セキュアなIMサービス3302は、検証の目的でアイデンティティサービス3301に問合せする必要がなく、従って、ネットワーク帯域巾を保存する。
3410において、プッシュ通知サービスは、トランスポートレイヤセキュリティ(TLS)を使用してユーザBとのセキュアな通信チャンネルをオープンし、そしてユーザBへメッセージをプッシュする。3411において、ユーザBは、ユーザAについて上述した同じ検証動作を遂行して、メッセージを検証し解読する。特に、ユーザBは、アイデンティティサービス3301に問合せしてユーザAのパブリックキーを検索し、次いで、そのパブリックキーを使用して、メッセージ(ユーザAのプライベートキーを使用して以前に署名され且つユーザBのパブリックキーで暗号化されている)を検証する。この段階において、ユーザA及びBは、3410でセキュアなIMセッションを確立するのに必要な全ての情報(例えば、パブリックキー及びトークン)を有する。
図35に示す一実施形態において、上述した技術に代わって又はそれに加えて、オフ・ザ・レコード・メッセージング(OTR)ネゴシエーションが使用される。当業者に知られたように、OTRは、AES対称的キーアルゴリズム、ディフィー・ヘルマンキー交換、及びSHA−1ハッシュ関数の組み合わせを使用するインスタントメッセージング会話のための強力な暗号を与える暗号プロトコルである。一実施形態において、上述したセキュアなメッセージング技術が試みられ、それが不成功な場合に、図35に示すOTR技術が使用される。
3501において、ユーザAは、ユーザBのID(例えば、e−メールアドレス、電話番号、等)を使用してアイデンティティサービスに問合せし、そしてアイデンティティサービスからユーザBのパブリックキーを検索する。3502において、ユーザAは、ユーザBのパブリックキーを使用して暗号化することによりセキュアなOTRセッション要求を発生し、そしてその要求をユーザBへ送信する。3503において、ユーザBは、ユーザBのプライベートキーを使用して解読し、そしてセッション要求に応答して、ユーザBは、ユーザAのパブリックキーを検索する。
3504において、ユーザBは、OTR応答を発生し、その応答をユーザAのパブリックキーで暗号化する。3505において、ユーザA及びBは、付加的なOTR接続メッセージを交換する。この段階で交換される特定のメッセージは、現在のOTR仕様によって定義され、それ故、ここでは詳細に述べない。3506において、全ての必要な接続データが交換されると、ユーザA及びBは、互いにセキュアなインスタントメッセージング通信チャンネルをオープンする。
上述した実施形態は、インスタントメッセージングの実施に焦点を合わせたが、本発明の基礎的な原理は、ピア・ツー・ピアオーディオ及び/又はビデオサービスのような他の形式のピア・ツー・ピア通信形式でも実施できる。
移動ユーザを接続するためのアイデンティティサービスの実施形態
上述したように、一実施形態において、アイデンティティサービス3301は、アクティブなユーザID、認証キー、及びプッシュトークンのユーザ登録ディレクトリ3302を管理する。アイデンティティサービス3301は、プッシュ通知サービス1050及びセキュアなインスタントメッセージングサービス3302のような他のサービスによって使用されて、人間が使用できる入力に基づき移動装置及びユーザの効率的な識別情報を与える。特に、一実施形態では、アイデンティティサービスは、便利なユーザ読み取り可能なユーザIDコード(例えば、電話番号、e−メールアドレス、ゲームセンターニックネーム、等)を詳細なユーザ/装置情報へマップするテーブルを伴う共有ユーザ登録データベース3302を備えている。
一実施形態において、単一のユーザIDは、ユーザ登録ディレクトリ3302内の複数の物理的装置へマップされる。例えば、ID tom@bstz.comを伴うユーザは、iPhoneTM(R)及び個別のiPadTM(R)(本特許出願の譲受人により設計された装置)並びに個別のノートブック/デスクトップパーソナルコンピュータのような多数の移動装置を有する。必要な認証クレデンシャルを伴うユーザ又はサービスは、他のユーザに関する情報を検索するためにアイデンティティサービスに問合せする。以上の特定の装置は、説明上使用されたものであるが、本発明の基礎的な原理は、その特定の装置形式に限定されない。
一実施形態において、各装置に対し維持される装置情報は、(1)装置のプッシュトークン(上述したように装置のネットワークアドレス情報を含む)、及び(2)装置の1組の能力を含む。その能力は、装置のサービスプロバイダーのアイデンティティ(例えば、AT&T vs Verizon)、装置のバージョン情報(例えば、ソフトウェアOSバージョン及び/又はアプリケーションバージョン)、及び装置によってサポートされる1つ以上のプロトコル(例えば、装置にインストールされたアプリケーションプログラムコードに基づく)を含む。例えば、装置がFacetimeTMアプリケーションをインストールしている場合には、この情報は、装置情報と共にアイデンティティサービスにより記憶される。更に、装置情報は、各ユーザ装置が通信することのできるサービスの形式(例えば、上述したセキュアなインスタントメッセージングサービス)を指定する。
従って、ユーザBの装置情報を検索するための問合せに応答して、ユーザAは、ユーザBの各装置の前記装置情報を含む応答をアイデンティティサービス3301から受け取る。これは、ユーザAの装置に、ユーザAの装置がユーザBと通信する種々の方法を有効に通知する。例えば、ユーザAがユーザBと同じ通信アプリケーションを幾つか有し(例えば、同じインスタントメッセージングクライアント、Facetimeアプリケーション、ファイルシェアアプリケーション、等)、正しいバージョンがインストールされている場合には、ユーザAの装置がこの情報を使用して、ユーザBとの通信チャンネルをオープンするよう試みる。
一実施形態において、装置情報は、各アプリケーションの特定のアプリケーション能力を識別する1組のフラグも含む。前記Facetimeの例に戻ると、装置情報は、ユーザBの装置が3Gネットワークを経てFacetimeチャンネルをサポートすることを指定する。そのようなケースでは、ユーザAの装置は、次いで、ユーザBの装置によってサポートされる特定のプロトコルを使用して3Gネットワークを経てユーザBの装置との通信チャンネルをオープンするように試みる。もちろん、以上の説明は、単なる例示に過ぎない。本発明の基礎的な原理は、任意の特定の1組のアプリケーション能力又はプロトコルに限定されない。
図36に示す本発明の一実施形態において、アイデンティティサービスと相互作用するために装置が遂行する動作は、次の4つがある:(1)認証;(2)登録;(3)正規化;及び(4)問合せ。
(1)認証
ここで使用する「認証」は、特定のユーザ識別子(ID)のアイデンティティを与えることを指す。一実施形態において、行われる認証は、異なる形式のIDコード(例えば、e−メールアドレス、サービスニックネーム、ユーザIDコード、電話番号、等)に対して異なるものである。例えば、e−メールアドレスの認証は、電話番号又はサービスIDコードの認証とは異なる。
これらの動作は、図36に示すシステムアーキテクチャー及び図37に示す方法に関して説明する。しかしながら、図37に示す方法は、本発明の基礎的な原理に適合しつつ、異なるシステムアーキテクチャーで実施できることに注意されたい。
3701において、ユーザAは、1組のアプリケーション特有のクレデンシャルをアプリケーション認証サービス3601へ送信する。例えば、e−メールアプリケーションの場合には、クレデンシャルは、ユーザAのe−メールアドレス及びパスワードを含み、ゲームアプリケーションの場合には、これは、ゲームサービスに対するユーザID及びパスワードを含み、そして電話番号の場合には、ショートメッセージサービス(SMS)署名を含む。更に、図36には個別のサービスとして示されているが、アプリケーション認証サービス3601及びアイデンティティサービス3301は、単一の一体化されたサービスを形成してもよい。
それに応答して、3702において、アプリケーション認証サービス3601は、与えられた認証クレデンシャルを得て、それに署名し、それを、ここで「プロビジョニング証明書」と称する認証証明書に入れ、そしてそのプロビジョニング証明書をユーザAに送信する。一実施形態において、プロビジョニング証明書は、暗号ナンス(例えば、タイムスタンプ)及び署名を含む。
プロビジョニング証明書に加えて、一実施形態において、ユーザAには、3703において、プッシュ通知サービスから受け取られた「プッシュ証明書」が与えられ、これは、ユーザAのプッシュトークン、ナンス(例えば、タイムスタンプ)、及びユーザAの能力(例えば、ユーザAの装置にインストールされた特定のアプリケーション)のリストの上の署名を含む。一実施形態において、ユーザAの装置が最初にネットワークにプロビジョニングされるときにユーザAの装置にプッシュ証明書が与えられる。
(2)登録
3704において、ユーザAは、そのプッシュ証明書及びそのプロビジョニング証明書をアイデンティティサービスに登録し、そして3705において、アイデンティティサービスは、プッシュ証明書及びプロビジョニング証明書からある所定の情報を抽出し、そしてそれらのエンティティに対するそれ自身の署名、ここではユーザAの「アイデンティティ証明書」と称する、を発生し、これは、その後、ネットワーク上のいずれかのサービスでユーザAのアイデンティティを検証するのに使用される(即ち、検証のためにアイデンティティサービスに個々に連絡するためのサービスを必要とせずに)。
(3)正規化
ある形式のユーザIDは、それらが種々の異なるフォーマットを使用してしばしば表現されることを意味する「ノイズ性」である。例えば、同じ電話番号が、408−555−1212、1−408−555−212、又は4085551212のいずれかで表される。又、異なるフォーマットをとる種々の国際アクセスコード及びキャリアアクセスコードもある。その結果、第1ユーザは、第2ユーザの電話番号を知っているが、登録データベース3302内で第2ユーザの電話番号を探索するために現在コンテキスト(例えば、ユーザが現在どこを歩きまわっているか、電話番号がどのようなフォーマットであるか)が与えられたときにユーザに到達するに必要な特定フォーマットを知らないことがある。
登録データベース内に特定ユーザIDの異なる変化の各々を記憶するのは効率的でない(即ち、著しい量のスペースを消費し、そしてあり得る全ての異なるフォーマットを首尾良く捕獲しないことがある)。従って、この問題に対処するために、本発明の一実施形態は、登録データベース3302内にユーザIDを記憶する前にユーザIDを正規化する(例えば、合意した正規化フォーマットを使用して)。
一実施形態において、アイデンティティサービス3301は、ユーザの現在コンテキスト及び要求側装置の設定に基づいて正規化を遂行するためのロジックを含む。例えば、図37において、ユーザBは、アイデンティティサービス3301に、そのホームキャリアのアイデンティティ(例えば、AT&T)、その現在ローミングキャリア(例えば、TMobile)、ユーザ設定(例えば、国際援助が使用されているかどうかの指示)、及び生のターゲットIDコード(例えば、4085551212のような非正規化形態でのユーザAの電話番号)を与える。それに応答して、アイデンティティサービス3301は、登録データベース3302の問合せを遂行する前に全ての前記変数に基づいて生のターゲットIDを正規化する。従って、ユーザAの正規ID(生のIDではない)が、アイデンティティサービスへのユーザBの問合せに応答してユーザBに与えられる(以下に詳細に述べる)。
(4)問合せ
上述したように、ターゲットユーザとのセキュアな通信チャンネルを確立するために、ユーザは、最初に、アイデンティティサービスに問合せして、ターゲットユーザのアイデンティティを検索する。図36に示すように、ユーザBは、ユーザAのアイデンティティの問合せを送信し、それ自身のアイデンティティ証明書を問合せの一部分として送る。それに応答して、アイデンティティサービスは、0以上のアイデンティティ証明書を返送し、その各々は、ユーザAのIDコード(上述した正規化形態の)と、そのアイデンティティに対するプッシュトークンと、ユーザAのID及びプッシュトークン並びにユーザBのID及びプッシュトークンの上に発生される問合せ署名と、を含む。
認証が要求されるたびに各サービスがIDSに問合せするよう強制するのは効率的でない。例えば、ユーザAがユーザBへメッセージを送信したいとき、上述したインスタントメッセージングサービスは、ユーザAのトークン及び署名並びにユーザBのトークン及び署名でアイデンティティサービスに問合せする必要があり、これは、ネットワークリソースを消費する。
この問題に対処するために、ここに述べる本発明の実施形態では、1組の0以上の署名がユーザ間のトランザクションごとにアイデンティティサービスによって発生され、この1組の署名は、各要求と共に各サービスへ送信される。署名は、上述したように、ソースID、ソーストークン、ターゲットID、ターゲットトークン、及びタイムスタンプのタプルの上になされる。従って、いかなるサービスも、それらエンティティの上に暗号署名を動的に発生することによりそれ自身の検証を行って、アイデンティティサービスに連絡せずに検証することができる。
更に、各個々のサービスは、検証を首尾良く行うためにはどれほど新しいタイムスタンプが必要であるか判断することができる。アイデンティティサービスにより発生されたオリジナルのタイムスタンプから既定の時間ウインドウ内に検証が行われる限り、トランザクションは、首尾良く検証される。従って、アイデンティティサービスは、アプリケーションサービスがユーザを認証できるようにするツールを提供するが、どのように認証を行うべきか(例えば、どのように新しいタイムスタンプが必要であるか)のポリシー判断は行わない。従って、異なるアプリケーションは、認証に対して異なるポリシーを有する。
アイデンティティサービスの一実施形態は、ネットワークトラフィックの量を更に減少するために問合せのキャッシュアーキテクチャーを実施する。図38a−bに示したように、この実施形態では、ユーザIDの装置キャッシュ3801が各ユーザ装置111に維持され、又、中間システムキャッシュ3802がネットワーク上でアイデンティティサービス3301と装置3801との間で実施されて、アイデンティティ要求にサービスし、従って、アイデンティティサービスの負荷を減少する。一実施形態において、システムキャッシュ3802は、アカマイ(Akamai)から現在入手できるようなコンテンツ配布ネットワーク及び他のコンテンツ配布サービスにより形成される。
図38aに示すように、システムキャッシュは、それがユーザAのための有効なエントリを現在有していない場合に、アイデンティティサービスへ要求を転送し、アイデンティティサービスは、上述したように、ユーザAに対する0以上の識別子で応答する。更に、図38aに示す実施形態では、アイデンティティサービスは、ユーザAのアイデンティティのための指紋を発生し、そしてその指紋をシステムキャッシュへ返送する。一実施形態において、指紋は、ユーザAのアイデンティティ(即ち、Aの正規化されたID、プッシュトークン及びタイムスタンプ)を含むエンティティ上のハッシュである。一実施形態において、ハッシュは、SHA−1であるが、本発明の基礎的な原理は、特定の形式のハッシュアルゴリズムに限定されない。
次いで、指紋は、図38bに示したように、システムキャッシュにユーザAのアイデンティティと共にキャッシュされる(例えば、ユーザAの正規化されたアイデンティティを使用してインデックスされる)。更に、指紋及び関連IDは、ユーザBの装置の装置キャッシュ3801内にキャッシュされる。
ユーザBがその後にユーザAのアイデンティティについて問合せすることが必要になったときに、ユーザBは、最初に、装置キャッシュ3801内を見て、ユーザAのアイデンティティに対して有効なキャッシュエントリが存在するかどうか決定する。一実施形態において、各キャッシュエントリは、それに関連した生存時間(TTL)値を有する(図38に示すタイムスタンプ列で決定されるように)。アイデンティティの要求がタイムスタンプから指定の時間ウインドウ内に生じる限り、装置キャッシュ3801のエントリは有効であり、ネットワークを経ての問合せは要求されない(即ち、ユーザBは、装置キャッシュ3801からユーザAのアイデンティティを読み取る)。
しかしながら、装置キャッシュ3801内のキャッシュエントリが満了となった(即ち、TTL値を過ぎた)場合には、ユーザBがユーザAのアイデンティティの問合せをシステムキャッシュ3802へ送信し、このシステムキャッシュは、(ユーザAの正規化されたIDコードを使用して)ユーザAの指紋をルックアップし、そしてその指紋を、ユーザAの問合せと共にアイデンティティサービス3301へ送信する。指紋がまだ有効であることがアイデンティティサービス3301により決定された場合には(例えば、タイムスタンプがまだ有効な時間ウインドウ内である場合には)、アイデンティティサービス3301により要求される唯一の応答が指紋有効性の指示である。次いで、システムキャッシュ3802は、図38bに示すように、ユーザAのアイデンティティのキャッシュコピーをユーザBへ返送する。以上のキャッシュ技術は、ユーザB及びユーザAのアイデンティティ上に新たな1組の署名を発生することが必要となる著しい量の処理リソースを節約する。
一実施形態において、上述したキャッシュTTL値は、アプリケーションごとに(即ち、アプリケーション設計者のセキュリティの好みに基づいて)構成可能である。従って、例えば、FacetimeTMのようなアプリケーションには、iChat以外のTTL値が設けられる。更に、TTL値は、現在ネットワーク状態に基づき動的にセットされる。例えば、ネットワークが、現在、トラフィックで過負荷になった場合には、TTL値が、より高い値に動的にセットされる(キャッシュされるアイデンティティが、より長い期間有効となるように)。更に、一実施形態において、上述した全てのキャッシュ技術は、アプリケーション開発者に露出されるAPI内で実施される。従って、アイデンティティのキャッシュ処理は、それらを使用するアプリケーションに対して透過的に行われる。
本発明の実施形態は、上述した種々のステップを含む。それらのステップは、汎用又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションで実施される。或いは又、それらのステップは、それらのステップを遂行するためのハードワイヤードロジックを含む特定のハードウェアコンポーネントにより遂行されてもよいし、プログラム型コンピュータコンポーネント及びカスタムハードウェアコンポーネントの組み合わせによって遂行されてもよい。
又、本発明の要素は、マシン実行可能なプログラムコードを記憶するためのマシン読み取り可能な媒体として設けられてもよい。マシン読み取り可能な媒体は、フロッピーディスケット、光学ディスク、CD−ROM、磁気光学ディスク、ROM、RAM、EPROM、EEPROM、磁気又は光学カード、或いは電子的プログラムコードを記憶するのに適した他の形式の媒体/マシン読み取り可能な媒体を含むが、これに限定されない。
以上の記述全体を通して、説明上、本発明を完全に理解するため多数の特定の細部について述べた。しかしながら、当業者であれば、幾つかの特定の細部がなくても、本発明を実施できることが明らかであろう。例えば、ここに述べる機能的モジュール及び方法は、ソフトウェア、ハードウェア又はその組み合わせとして実施できることが当業者に容易に明らかであろう。更に、本発明の実施形態は、移動コンピューティング環境に関して(即ち、移動装置120−123;601−603を使用して)ここに説明するが、本発明の基礎的な原理は、移動コンピューティング実施に限定されない。例えば、デスクトップ又はワークステーションコンピュータを含む幾つかの実施形態に実質上いかなる形式のクライアント又はピアデータ処理装置を使用してもよい。従って、本発明の精神及び範囲は、特許請求の範囲において判断されるべきである。