JP5596849B2 - オンライン通信セッションのためのクライアントコンピュータデバイスの登録 - Google Patents

Description

本発明の実施形態は、コンピュータネットワーキングの分野に関し、より具体的には、オンライン通信セッションのためのクライアントコンピュータデバイスの登録に関する。

〔関連出願への相互参照〕
本出願は、２０１０年９月２０日出願の米国特許出願第１２／８８６，４７９号に対する優先権を請求するものであり、かつ２０１０年９月１３日出願の米国特許仮出願第６１／３８２，４７９号、各々が２０１０年８月３１日出願の米国特許仮出願第６１／３７８，９２４号及び米国特許仮出願第６１／３７８，９２６号、２０１０年６月４日出願の米国特許仮出願第６１／３５１，８１４号、及び各々が２０１０年４月７日出願の米国特許仮出願第６１／３２１，８６５号及び米国特許仮出願第６１／３２１，８６６号の恩典も主張するものであり、これらの特許の各々は、引用により本明細書に組み込まれている。

本出願は、２０１０年４月７日出願の「ユーザをオンラインセッションに招待するための装置及び方法」という名称の現在特許出願中の本出願と同一の本出願人に譲渡された米国特許仮出願第６１／３２１，８３２号に関連の主題を含む場合があり、この特許は、引用により本明細書で組み込まれる。

オンライン通信セッション（例えば、インスタントメッセージ、テレビ会議など）を行うための多くの実施は、コンピュータデバイスのユーザがソフトウエアをインストールし及び／又はサービスと登録することを要求する。従って、ユーザが別のユーザとのオンライン通信セッションを確立する前提条件として、両方のユーザが登録済みであり及び／又は同じソフトウエアがインストールされていなければならない。多くの実施はまた、ユーザが他のユーザのステータス（例えば、オンライン、オフライン、アウェーなど）を判断することを可能にするプレゼンス（例えば、フレンドリスト）を維持する。

「インターネット」のような大規模パブリックネットワークは、会社、「インターネット」サービスプロバイダ、又は更に個々の一般家庭によって維持されるもののようなより小規模のプライベートネットワークにとの接続を有することが多い。まさしくその性質により、パブリックネットワークは、ネットワークアドレスの一般的に同意された割り当て、すなわち、パブリックアドレスを有するべきである。様々な理由から、プライベートネットワークの維持管理者は、一般的に同意された割り当ての一部でないプライベートネットワークに対してプライベートネットワークアドレスを使用したいと思うことが多い。従って、プライベートネットワークからのネットワークトラフィックがパブリックネットワークをトラバースすることができるためには、何らかの形態のプライベート／パブリックネットワークアドレス変換（ＮＡＴ）が必要である。

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

ＮＡＴは、最新のネットワークコンピュータにおいて益々一般的になっている。ＮＡＴの１つの利点は、それがパブリックネットワークアドレス空間の枯渇を遅らせるという点である。例えば、「インターネット」上に使用されるＴＣＰ／ＩＰアドレス指定は、各３桁の４つのストリングを含み、従って、有限のアドレス空間を提供する。更に、このアドレス空間のある一定の部分は、特定の用途又はユーザに向けて留保され、更に利用可能なアドレスの実際の数が減少する。しかし、ＮＡＴを使用した場合に、プライベートネットワーク又はサブネットは、任意の数のアドレスを使用し、依然として外側世界に単一の標準化されたパブリックアドレスのみを呈示することができる。それによって利用可能なアドレスの数が実際的には無限になるが、その理由は、各プライベートネットワークは、同一のプライベートアドレスを理論的に使用することができるからである。

ＮＡＴによって得られる１つの利点は、パブリックネットワーク上のコンピュータがプライベートネットワーク上のコンピュータの実際の（すなわち、プライベートの）ネットワークアドレスを判断することができないことから生じるセキュリティの強化である。これは、パブリックアドレスのみがネットワークアドレス変換器によりパブリックネットワーク上に提供されるからである。更に、このパブリックアドレスは、プライベートネットワーク上のあらゆる数のコンピュータに対応することができる。

ＮＡＴタイプが異なれば、その使用するセキュリティのレベルも異なる。例えば、「全コーンＮＡＴ」を用いて、内部アドレス（ｉＡｄｄｒ：Ｐｏｒｔ）が外部アドレス（ｅＡｄｄｒ：ｅＰｏｒｔ）にマップされた状態で、あらゆる外部ホストは、ｅＡｄｄｒ：ｅＰｏｒｔにパケットを送ることによりｉＡｄｄｒ：ｉＰｏｒｔにパケットを送ることができる。「制限付きコーンＮＡＴ」を用いて、アドレスｈＡｄｄｒを有する外部ホストは、ｉＡｄｄｒ：ｉＰｏｒｔが以前にｈＡｄｄｒにパケットを送ったことがある場合に限り、ｅＡｄｄｒ：ｅＰｏｒｔにパケットを送ることによってｉＡｄｄｒ：ｉＰｏｒｔにパケットを送ることができる。外部ホストのポートは無関係である。「ポート制限付きコーンＮＡＴ」を用いて、ｉＡｄｄｒ：ｉＰｏｒｔが以前にｈＡｄｄｒ：ｈＰｏｒｔにパケットを送っていた場合に限り、アドレス／ポートｈＡｄｄｒ：ｈＰｏｒｔを有する外部ホストは、ｅＡｄｄｒ：ｅＰｏｒｔにパケットを送ることによってｉＡｄｄｒ：ｉＰｏｒｔにパケットを送ることができる。最後に、対称ＮＡＴを用いて、同じｉＡｄｄｒ：ｉＰｏｒｔから特定の宛先ＩＰアドレス及びポートへの各要求は、固有のｅＡｄｄｒ：ｅＰｏｒｔにマップされる。同じ内部ホストが異なる宛先にパケットを送った場合に、異なる外部アドレス及びポートマッピングが使用される。内部ホストからパケットを受信する外部ホストのみが、内部ホストにパケットを送り返すことができる。

ピアツーピア（Ｐ２Ｐ）コンピューティングは、コンピュータノードのリソースの一部を他のネットワーク参加者に直接に利用可能にするコンピュータノードで構成された分散型ネットワークアーキテクチャを指す。Ｐ２Ｐネットワーク内のピアは、サーバがリソースを供給し、クライアントがリソースを消費する従来のクライアント−サーバモデルとは対照的に、相互の直通通信チャンネルを確立してクライアント及びサーバの両方として作用する。

上述のＮＡＴ作動では、Ｐ２Ｐ接続に対して多くの問題がある。例えば、ピアの一方又は両方が上述のＮＡＴタイプの１つ又はそれよりも多くの裏側に位置する場合に、２つのピアの間に直接接続を確立することは益々困難になる。この問題は、「Ａｐｐｌｅ ｉＰｏｄ Ｔｏｕｃｈ（登録商標）」、「Ａｐｐｌｅ ｉＰｈｏｎｅ（登録商標）」、「Ａｐｐｌｅ ｉＰａｄ（登録商標）」、及び様々な他のデバイス（例えば、「ＲＩＭ Ｂｌａｃｋｂｅｒｒｙ（登録商標）」デバイス、「Ｐａｌｍ Ｐｒｅ（登録商標）」デバイスなど）のようなクライアントデバイスが、異なるＮＡＴ実施を有するネットワークの間で頻繁に移動することによって悪化する。例えば、「Ａｐｐｌｅ ｉＰｈｏｎｅ（登録商標）」は、Ｗｉ−Ｆｉネットワーク（例えば、８０２．１１ｂ、ｇ、ｎネットワーク）、３Ｇネットワーク（例えば、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）ネットワーク、高速アップリンクパケットアクセス（ＨＳＵＰＡ）ネットワークなど）、及びＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク（パーソナルエリアネットワーク（ＰＡＮ）として公知）上で通信することができる。今後のクライアントデバイスは、少し例を挙げれば、ＷｉＭａｘ、インターナショナルモバイルテレコミュニケーション（ＩＭＴ）アドバンスト、及びロングタームエボリューション（ＬＴＥ）アドバンストのような付加的な通信チャンネル上に通信することができることになる。

ハンズフリーユニット（例えば、ヘッドホン、自動車キット）は、一般的に、ハンズフリーサービスのためのコンピュータデバイスとピア接続するのに使用される。例えば、携帯電話通信の機能性を含むコンピュータデバイスが、ハンズフリーユニットとコンピュータデバイスの間の音声リレーとして作用するハンズフリーユニットとピア接続する機能を含むことは一般的である。

ヘッドホンプロフィール（ＨＳＰ）１．２仕様書、２００８年１２月１８日 ハンズフリープロフィール１．５（ＨＦＰ１．５）仕様書、２００５年１１月２５日

クライアントコンピュータデバイス（クライアントデバイス）（例えば、ワークステーション、ラップトップ、パームトップ、携帯電話、スマートフォン、マルチメディア電話、タブレット、携帯式メディアプレーヤ、ＧＰＳユニット、ゲームシステムなど）をオンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージなど）に向けて自動的に登録する方法及び装置を説明する。一実施形態では、コンピュータデバイスでのイベント時に（例えば、電源が投入されるコンピュータデバイス）、クライアントデバイスは、オンライン通信セッションの登録処理を自動的に始める。自動登録処理は、クライアントデバイスが、ＳＭＳトランジットデバイス（例えば、ＳＭＳゲートウェイ又はＳＭＳアグリゲータ）に識別トークン（例えば、そのプッシュトークン）を有するＳＭＳ（ショートメッセージサービス）メッセージを送信することを含む。識別トークンは、クライアントデバイスを一意的に識別し、一実施形態では、プッシュ通知サービスがクライアントデバイスの位置付けることを可能にする情報を含むことができるプッシュトークンである。プッシュ通知サービスの実施形態における識別トークンは、特定の通知が合法的であるという信頼を確立する方法としても使用される。他の実施形態では、独自のトークンにクライアントデバイスのあらゆる登録又はマッピングを用いて、識別トークンをクライアントデバイスに関連付け、かつクライアントデバイスのアイデンティティを一意的に識別されたトークンに関連付ける信頼された方法を提供することができる。

ＳＭＳトランジットデバイスは、クライアントデバイスの電話番号を判断して（例えば、ＳＭＳメッセージのヘッダを調べることにより）、識別トークン及び電話番号を用いてＩＰ（インターネットプロトコル）メッセージを登録サーバに送信する。登録サーバは、識別トークン及び電話番号に基づいて署名を発生させてクライアントデバイスへの配信に向けてＳＭＳトランジットデバイスにこれらを送信する。ＳＭＳトランジットデバイスは、クライアントデバイスに署名と識別トークンと電話番号とを含むＳＭＳメッセージを送信する。クライアントデバイスは、次に、署名、識別トークン、及び電話番号を用いて登録サーバにＩＰメッセージを送信する。登録サーバは、クライアントデバイスからの情報を検証し、オンライン通信セッション登録データストア内に識別トークンと電話番号の間の関連付けを記憶する。識別トークンと電話番号の関連付けられた対を併せて、オンライン通信セッションネットワーク内でデバイスを一意的に識別する。

クライアントデバイスが登録された後に、クライアントデバイスのユーザは、オンライン通信セッション（例えば、映像チャット／会議セッション、インスタントメッセージセッションなど）を開始し及び／又はその招待を受け入れることができる。一実施形態では、クライアントデバイスの電話番号は、オンライン通信セッションのオンライン通信セッション終点識別子として使用される。一例として、クライアントデバイスのユーザは、電話番号を使用してオンライン通信セッションに参加するように他のクライアントデバイスの他のユーザを招待することができる。一部の実施形態では、クライアントデバイスは、それ自体の電話番号を自然には知らない。

本発明は、本発明の実施形態を示すために使用される以下の説明及び添付図面を参照することによって最も良く理解することができる。

一実施形態によるオンライン通信セッションのためのクライアントデバイスの登録を示すデータ流れ図である。 一実施形態によりより詳細に図１のクライアントデバイスを示すブロック図である。 一実施形態によりより詳細に図１の登録サーバを示すブロック図である。 一実施形態によるオンライン通信セッションのためのクライアントデバイスを登録する例示的な作動を示す流れ図である。 一実施形態による例示的な登録データストアを示す図である。 一実施形態の一般的なネットワークトポロジーを示す図である。 一実施形態によるクライアントデバイス間のオンライン通信セッション確立を示すデータ流れ図である。 一実施形態による例示的なリレーサービスを示すブロック図である。 一実施形態によるＡＰＩアーキテクチャの一実施形態を示す図である。 一実施形態による例示的な登録データストアを示す図である。 一実施形態による例示的なＮＡＴ互換性チャートを示す図である。 一部の実施形態による回線交換通話と映像通話の間で遷移するのに使用される例示的なクライアントデバイス及びグラフィカルユーザインタフェースを示す図である。 一実施形態による映像プレビューを示す図１２のクライアントデバイスを示す図である。 一実施形態による映像通話招待を受諾又は拒否するのに使用される例示的なクライアントデバイス及びグラフィカルユーザインタフェースを示す図である。 一実施形態による映像通話に遷移した後のクライアントデバイスを示す図である。 一実施形態による映像通話に遷移した後のクライアントデバイスを示す図である。 一実施形態による映像通話と音声専用回線交換通話間で遷移する例示的な作動を示す流れ図である。 一実施形態による映像通話と音声専用回線交換通話間で遷移する例示的な作動を示す流れ図である。 一実施形態による映像通話拒否メッセージを受信したクライアントデバイス上で行われる例示的な作動を示す流れ図である。 一実施形態による映像通話から回線交換通話へ遷移するクライアントデバイス上で行われる例示的な作動を示す流れ図である。 一実施形態によるオンライン通信セッション終点識別子として電子メールアドレスを使用してオンライン通信セッションのためのクライアントデバイスを登録するのに使用される一般的なネットワークトポロジーを示す図である。 一実施形態によるオンライン通信セッション終点識別子として電子メールアドレスを登録する例示的な作動を示す流れ図である。 一実施形態によるオンライン通信セッション終点識別子として電子メールアドレスを登録する例示的な作動を示す流れ図である。 一実施形態によるオンライン通信セッション終点識別子として電子メールアドレスを登録する初期化情報を提供するユーザに関する例示的な作動を示す流れ図である。 一実施形態による電子メールアドレスを検証する例示的な作動を示す図である。 一実施形態による電子メールアドレスが検証された時に登録サービスに行われる例示的な作動を示す流れ図である。 一実施形態によるユーザが同じオンライン通信セッション終点識別子に関連付けられている複数のクライアントデバイスを有する時に招待を管理する例示的な作動を示すデータ流れ図である。 一実施形態による直接的なＰ２Ｐ接続が達成可能である時に行われる例示的な作動を示すデータ流れ図である。 一実施形態による直接的なＰ２Ｐ接続が達成不可能である時に行われる例示的な作動を示すデータ流れ図である。 一実施形態によるオンライン通信セッションが終了する時に行われる例示的な作動を示すデータ流れ図である。 一実施形態による１つのクライアントデバイスから別のクライアントデバイスにオンライン通信セッションを転送するために行われる例示的な作動を示す流れ図である。 一実施形態による複数のユーザとのオンライン通信セッションを開始かつ確立する例示的な作動を示す流れ図である。 一実施形態によるハンズフリーユニットとインタフェースで接続するクライアントコンピュータデバイスを示すブロック図である。 一実施形態による映像通話の招待を受信し、ハンズフリーデバイスに電話させ、ハンズフリーデバイスから応答表示を受信し、映像通話を確立し、ハンズフリーデバイスに音声を経路指定するクライアントコンピュータデバイスを示す図である。 一実施形態による映像通話を開始してハンズフリーデバイスを通じて確立した映像通話に向けて音声を経路指定するクライアントコンピュータデバイスを示す図である。 一実施形態によるハンズフリーデバイスから通話要求を受信することに応答して映像通話を開始するクライアントコンピュータデバイスを示す図である。 一実施形態による確立された映像通話の音声をハンズフリーデバイスに経路指定するクライアントコンピュータデバイスを示す図である。 一実施形態によるハンズフリーデバイスから通話終了要求を受信することに応答して映像通話を終了するクライアントコンピュータデバイスを示す図である。 一部の実施形態に使用することができる例示的なコンピュータシステムを示すブロック図である。 一部の実施形態に使用することができる例示的なデータ処理システムを示すブロック図である。

以下の説明では、多くの特定の詳細に対して説明する。しかし、本発明の実施形態は、これらの特定の詳細がなくても実施することができることが理解される。他の例において、公知の回路、構造、及び技術は、この説明の理解を不明瞭にしないために詳細な図示を割愛した。当業者は、説明した説明により、不相応な実験なしに適切な機能性を実施することができるであろう。

本明細書における「一実施形態」、「実施形態」、「例示的な実施形態」などへの言及は、説明する実施形態は、特定の特徴、構造、又は特性を含むことができるが、全ての実施形態が、特定の特徴、構造、又は特性を必ずしも含むことができるわけではないことを示している。更に、このような語句は、必ずしも同じ実施形態を指すわけではない。更に、特定の特徴、構造、又は特性を実施形態に関連して説明する時に、明示的に説明されているか否かに関わらず、他の実施形態に関連してこのような特徴、構造、又は特性を実施することが当業者の知識の範囲にあるように考えられている。

以下の説明及び特許請求の範囲において「結合された」、「接続された」という用語は、その派生語と共にそれらを使用する場合がある。これらの用語は互いの同意語を意図していないことを理解すべきである。「結合された」は、２つ又はそれよりも多くの要素を示すために使用しており、２つ又はそれよりも多くの要素は、互いに直接的に物理的又は電気的に接触しているか、又は互いと協働又は相互作用する場合もあれば、そうではない場合もある。「接続された」は、互いに結合された２つ又はそれよりも多くの要素間の通信の確立を示すために使用している。

オンライン通信セッションの自動登録
オンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージなど）に向けてクライアントコンピュータデバイス（クライアントデバイス）（例えば、ワークステーション、ラップトップ、パームトップ、携帯電話、スマートフォン、マルチメディア電話、タブレット、携帯式メディアプレーヤ、ＧＰＳユニット、ゲームシステムなど）を自動的に登録する方法及び装置に対して説明する。一実施形態では、コンピュータデバイス（例えば、電源が投入されるコンピュータデバイス）でのイベントで、クライアントデバイスは、オンライン通信セッションの登録処理を自動的に始める。自動登録処理は、クライアントデバイスは、ＳＭＳトランジットデバイス（例えば、ＳＭＳゲートウェイ又はＳＭＳアグリゲータ）に識別トークン（例えば、プッシュトークン）と、クライアントデバイス識別子とを有するＳＭＳ（ショートメッセージサービス）メッセージを送信することを含む。識別トークンは、オンライン通信セッションメッセージ（例えば、招待要求メッセージ及び招待受諾メッセージ）のためのクライアントデバイスを一意的に識別するものであり、一実施形態では、プッシュ通知サービスによりクライアントデバイスの位置付けることを可能にする情報を含むことができるプッシュトークンである。プッシュ通知サービスの実施形態における識別トークンは、特定の通知が合法的であるという信頼を確立する方法としても使用される。他の実施形態では、独自のトークンにクライアントデバイスのあらゆる登録又はマッピングを用いて、識別トークンをクライアントデバイスに関連付け、かつクライアントデバイスのアイデンティティを一意的に識別されたトークンに関連付ける信頼された方法を提供することができる。デバイス識別子は、クライアントデバイスを一意的に識別するものであり、かつ一般的に１つ又はそれよりも多くのハードウエア識別子（例えば、デバイスの製造番号、ＳＩＭ（加入者アイデンティティモジュール）カードのＩＣＣ−ＩＤ（集積回路カードＩＤなど）に基づくものである。

ＳＭＳトランジットデバイスは、クライアントデバイスの電話番号を判断して（例えば、ＳＭＳメッセージのヘッダを調べることにより）、識別トークン、デバイス識別子、及び電話番号を用いてＩＰ（インターネットプロトコル）メッセージを登録サーバに送信する。登録サーバは、識別トークン、デバイス識別子、及び電話番号に基づいて署名を発生させてクライアントデバイスへの配信に向けてＳＭＳトランジットデバイスにこれらを送信する。ＳＭＳトランジットデバイスは、クライアントデバイスに署名と電話番号とを含むＳＭＳメッセージを送信する。クライアントデバイスは、次に、署名、デバイス識別子、識別トークン及び電話番号を用いて登録サーバにＩＰメッセージを送信する。

登録サーバは、クライアントデバイスからの情報を検証し、オンライン通信セッション登録データストア内に識別トークンと電話番号の間の関連付けを記憶する。識別トークンと電話番号との関連付けられた対を併せて、オンライン通信セッションネットワーク内でデバイスを一意的に識別する。クライアントデバイスが登録された後に、クライアントデバイスのユーザは、オンライン通信セッション（例えば、映像チャット／会議セッション、インスタントメッセージセッションなど）を開始し及び／又はその招待を受け入れることができる。一実施形態では、クライアントデバイスの電話番号は、オンライン通信セッションのオンライン通信セッション終点識別子として使用される。一例として、クライアントデバイスのユーザは、電話番号を使用してオンライン通信セッションに参加するように他のクライアントデバイスの他のユーザを招待することができる。一部の実施形態では、クライアントデバイスは、それ自体の電話番号を自然には知らない。

図１は、一実施形態によるオンライン通信セッションのためのクライアントデバイスの登録を示すデータ流れ図である。図１は、クライアントデバイス１１０と、ＳＭＳネットワーク１２０と、登録サーバ１４０と、ＩＰメッセージングデータストア１５０とを含む。クライアントデバイス１１０（例えば、ワークステーション、ラップトップ、パームトップ、コンピュータ電話、スマートフォン、マルチメディア電話、タブレット、携帯式メディアプレーヤ、ＧＰＳユニット、ゲームシステムなど）は、識別トークン１１５（一実施形態ではプッシュトークンとすることができる）を含む。識別トークン１１５は、本明細書でより詳細に後述する招待要求メッセージ及び招待受諾（又は拒否）メッセージ受信するクライアントデバイス１１０を一意的に識別するものである。デバイス識別子１１７は、クライアントデバイスを一意的に識別するものであり、かつ一般的に１つ又はそれよりも多くのハードウエア識別子（例えば、デバイスの製造番号、ＳＩＭ（加入者アイデンティティモジュール）カードのＩＣＣ−ＩＤ（集積回路カードＩＤなど））に基づくものである。クライアントデバイス１１０は、ＳＭＳメッセージを送受信する機能、並びにＩＰメッセージを接続して送信／受信する機能を含む。

オンライン通信セッションに向けて登録した後に、クライアントデバイス１１０は、オンライン通信セッションを招待し及び／又はオンライン通信セッションの招待を受諾することができる。クライアントデバイス１１０は、オンライン通信セッション終点識別子を通じて、オンライン通信セッションにおいて識別される。一実施形態では、オンライン通信セッション終点識別子がクライアントデバイス１１０の電話番号であるが、他の実施形態では、オンライン通信セッション終点識別子は、異なる識別子（例えば、ユーザ名（例えば、アップルＩＤ）、電子メールアドレス、郵便先住所、ＭＡＣアドレス又は他の識別子）である。

ＳＭＳネットワーク１２０は、キャリアＳＭＳＣ（ショートメッセージサービスセンター）１２５とＳＭＳトランジットデバイス１３０（例えば、ＳＭＳゲートウェイ又はＳＭＳアグリゲータ）とを含む。キャリアＳＭＳＣ１２５は、コンピュータキャリア特定であり、ＳＭＳメッセージを受信及び配信する。例えば、キャリアＳＭＳＣ１２５は、クライアントデバイス１１０から送られたＳＭＳメッセージをＳＭＳトランジットデバイス１３０に配信し、ＳＭＳトランジットデバイス１３０から送られたＳＭＳメッセージをクライアントデバイス１１０に配信する。ＳＭＳトランジットデバイス１３０は、モバイルネットワーク及びＩＰネットワークを分離する。

登録サーバ１４０は、オンライン通信セッションのためのクライアントデバイス１１０のようなクライアントデバイスを登録する。オンライン通信セッションのためのクライアントデバイスの登録は、デバイスの識別トークンをデバイスの電話番号（又は他のオンライン通信セッション終点識別子）に関連付けることを含む。識別トークンとオンライン通信セッション端部識別子間の関連付けは、オンライン通信セッション登録データストア１５０に記憶される。

クライアントデバイス１１０で行われるイベント時に（例えば、電源が投入されるクライアントデバイス、オンライン通信セッションアプリケーション（例えば、Ｐ２Ｐテレビ会議アプリケーション、Ｐ２Ｐインスタントメッセージアプリケーションなど）の起動など）、クライアントデバイス１１０は、オンライン通信セッションに向けて登録処理を始める。一実施形態では、登録処理は、自動的に始まり（ユーザとの対話処理なしで）、一方、他の実施形態では、登録処理は、ユーザがオンライン通信セッションのためのクライアントデバイスを登録することを選択した後に始まる。

クライアントデバイス１１０の電話番号がオンライン通信セッション終点識別子として使用され、従って、登録データストア１５０内のクライアントデバイス１１０の識別トークン１１５に関連付けられることになっている実施形態では、クライアントデバイス１１０の電話番号を判断すべきである。クライアントデバイス１１０はそれ自体の電話番号を自然には知らないので、一部の実施形態では、クライアントデバイス１１０の電話番号は、ＳＭＳメッセージを送信するクライアントデバイス１１０を通じて判断される。例えば、作動１で、クライアントデバイス１１０は、その識別トークン１１５及びデバイス識別子１１７を用いてＳＭＳメッセージをキャリアＳＭＳＣ１２５を通じてＳＭＳトランジットデバイス１３０に送信する。一部の実施形態では、ＳＭＳメッセージは、電話番号にアドレス指定され、電話番号は、標準的な長さの番号、又はオンライン通信セッション登録に向けて特に確立される短いコード（完全な電話番号より、すなわち、一般的に有意に短い一種の電話番号）とすることができる。ＳＭＳメッセージのアドレス指定先である電話番号は、クライアントデバイス（例えば、キャリアバンドルで）に記憶される。

キャリアＳＭＳＣ１２５は、ＳＭＳメッセージを受信してＳＭＳトランジットデバイス１３０を配信する。ＳＭＳトランジットデバイス１３０は、作動２でクライアントデバイスの電話番号を判断する。例えば、ＳＭＳトランジットデバイス１３０は、ＳＭＳメッセージのヘッダを調べてクライアントデバイス１１０の電話番号を判断する。電話番号を判断した後に、ＳＭＳトランジットデバイス１３０は、クライアントデバイス１１０の電話番号、識別トークン１１５、及びデバイス識別子１１７を用いて登録サーバ１４０にＩＰメッセージを送信する。これは、登録要求メッセージと呼ぶこともある。

登録サーバ１４０は、クライアントデバイス１１０の電話番号と、識別トークン１１５と、デバイス識別子１１７とを含むＩＰメッセージをＳＭＳトランジットデバイスから受信して署名を作成する。署名は、クライアントデバイス１１０の電話番号、識別トークン１１５及び／又はデバイス識別子１１７に基づくことができ、検証（本明細書でより詳細に後述）に使用される。一部の実施形態では、複数のクライアントデバイスが同じ電話番号を有する状況に対処するために、署名を発生させる時に乱数も使用される。登録サーバ１４０は、作動５で、ＳＭＳトランジットデバイス１３０に署名、電話番号、デバイス識別子、及びトークンを送り返す（例えば、ＩＰメッセージで）。これは、登録応答メッセージと呼ぶこともある。

ＳＭＳトランジットデバイス１３０は、登録サーバ１４０から署名、電話番号、デバイス識別子及びトークンを受信し、署名及びクライアントデバイス１１０の電話番号を用いてＳＭＳメッセージを生成する。ＳＭＳトランジットデバイス１３０は、作動６で、署名及び電話番号を用いてクライアントデバイス１１０にＳＭＳメッセージを送信する（キャリアＳＭＳＣ１２５を通じて）。

クライアントデバイス１１０は、ＳＭＳメッセージを受信し、電話番号を記憶することを含め処理する。クライアントデバイス１１０は、作動７で、識別トークン１１５、デバイス識別子１１７、電話番号、及び登録サーバによって生成される署名を用いたＩＰメッセージを登録サーバ１４０に送信する。これは、登録検証要求メッセージと呼ぶこともある。

署名を使用し、登録サーバ１４０は、クライアントデバイス１１０によって送られたデータを検証する。例えば、登録サーバ１４０は、クライアントデバイス１１０によって送られた署名を作動４中に発生された署名と比較する。署名が適合した場合に、データは、検証される。データが有効であると仮定し、登録サーバ１４０は、オンライン通信セッション登録データストア１５０内の識別トークン１１５とクライアントデバイス１１０の電話番号との関連付けを記憶する。

代替実施形態では、ＳＭＳメッセージの送信を通じてクライアントデバイス１１０の電話番号を判断する代わりに、デバイスのユーザは、クライアントデバイス１１０の電話番号を入力することを促される。これらの実施形態では、クライアントデバイス１１０は、クライアントデバイス１１０の電話番号（ユーザによる入力として）及びその識別トークン１１５を登録サーバ１４０に直接に送信し、登録サーバ１４０は、オンライン通信セッション登録データストア１５０においてそれらを関連付けることができる。

図５は、一実施形態による例示的な登録データストア１５０を示している。図５に示すように、オンライン通信セッション識別子記録５１０の各々は、識別トークンフィールド５２０及び電話番号フィールド５２５を含む。一部の状況では、単一の電話番号が複数の識別トークンに関連付けられることが可能である。例えば、異なるクライアントデバイスは、同じ電話番号を有することができる。これらの場合には、これらの異なるクライアントデバイスは、異なる識別トークンを有する。従って、オンライン通信セッション招待が複数の識別トークンに関連付けられた電話番号に向けて送られた時に、招待は、識別トークンに関連付けられた各デバイスに送信されることになる。

図２は、一実施形態によるより詳細に図１のクライアントデバイス１１０を示すブロック図である。図２を図４の例示的な実施形態を参照して説明するが、図４は、オンライン通信セッションのためのクライアントデバイスを登録する例示的な作動を示す流れ図である。しかし、図４の作動は図２を参照して説明したもの以外の実施形態により行うことができ、図２を参照して説明する実施形態は、図４を参照して説明したものと異なる作動を行うことができることを理解すべきである。

図２に示すように、クライアントデバイス１１０は、クライアントオンライン通信セッション登録モジュール（クライアント登録モジュール）２１０と、キャリアバンドル２１５と、プッシュトークン１１５と、デバイス識別子１１７と、ＳＭＳモジュール２２０と、クライアントオンライン通信セッション登録データストア（クライアント登録データストア）２３０とを含む。クライアント登録モジュール２１０は、オンライン通信セッションのためのクライアントデバイス１１０の登録を制御する。キャリアバンドル２１５は、登録に使用されるＳＭＳトランジットデバイスに向ける電話番号を含むキャリア特定の設定（例えば、ＳＭＳトランジットデバイス１３０の番号）と、他の設定（例えば、アクセスポイント名（ＡＰＮ）設定、マルチメディアメッセージングサービス（ＭＭＳ）設定など）とを含む。ＳＭＳモジュール２２０は、ＳＭＳメッセージを送受信する。クライアント登録データストア２３０は、オンライン通信セッション登録に関連付けられたデータ（例えば、一旦判断されたクライアントデバイス１１０の電話番号）を記憶する。

図４を参照すると、ブロック４１０で、クライアント登録モジュール２１０は、オンライン通信セッション登録をトリガするイベントを検出又は受信する。このようなイベントには、クライアントデバイス１１０の電源が投入され、ユーザがオンライン通信アプリケーション（例えば、Ｐ２Ｐテレビ会議アプリケーション、Ｐ２Ｐインスタントメッセージアプリケーションなど）を開くなどがある。一部の実施形態では、登録処理は、クライアントデバイス４１０の電源が投入される度に実行され、一方、他の実施形態では、登録処理は、クライアントデバイス１１０の電源が初めて投入された時に実行される。フローは、ブロック４１０からブロック４１５に移動する。

ブロック４１５で、クライアント登録モジュール２１０は、有効な識別トークンがクライアントデバイス１１０に向けてあるか否かを判断する。識別トークンがないか又は識別トークンが満了していた場合に、フローは、ブロック４２５に移動して代替アクションが講じられる。例えば、プッシュトークンを使用する実施形態では、クライアントデバイス１１０は、プッシュ通知サービス（一般的にクライアントデバイス１１０から遠く離れている）によって生成すべきプッシュトークンを要求することによってトークン生成手順を開始することができる。プッシュ通知サービスにより、クライアントデバイス１１０に特定のプッシュトークンが生成してクライアントデバイス１１０に戻される。有効な識別トークンがある場合に、フローは、ブロック４２０に移動し、クライアント登録モジュール２１０は、識別トークン１１５にアクセスする。フローは、ブロック４２０からブロック４２８に移動する。

ブロック４２８で、クライアント登録モジュール２１０は、デバイス識別子１１７にアクセスする。フローは、次に、ブロック４３０に移動し、クライアント登録モジュール２１０は、登録処理に使用されるＳＭＳトランジットデバイスの電話番号を判断する。例えば、クライアント登録モジュール２１０は、キャリアバンドル２１５にアクセスしてＳＭＳトランジットデバイスの電話番号を判断する。電話番号は、短いコードとすることができ、又は標準的な長さの番号とすることができる。この例において、登録処理に使用されるＳＭＳトランジットデバイスは、ＳＭＳトランジットデバイス１３０である。フローは、ブロック４３０からブロック４３５に移動する。

ブロック４３５で、識別トークン１１５及びデバイス識別子１１７を有するＳＭＳメッセージは、判断された番号をＳＭＳトランジットデバイス１３０に送信させる。例えば、クライアント登録モジュール２１０は、識別トークン１１５及びデバイス識別子１１７を用いたＳＭＳメッセージを判断した番号に送信するようにＳＭＳモジュール２２０を要求する。ＳＭＳモジュール２２０は、識別トークンを用いたＳＭＳメッセージを判断した番号に送信する。フローは、ブロック４３５からブロック４４０に移動する。ＳＭＳメッセージは、キャリアＳＭＳＣ１２５によって受信されることになり、キャリアＳＭＳＣ１２５は、ＳＭＳトランジットデバイス１３０にメッセージを配信する。

ブロック４４０で、ＳＭＳトランジットデバイス１３０は、受信したＳＭＳメッセージに基づいてクライアントデバイス１１０の電話番号を判断する。例えば、ＳＭＳトランジットデバイスは、ＳＭＳメッセージのヘッダを調べ、ヘッダは、送信側の電話番号を含むことになり、この場合に、送信側は、クライアントデバイス１１０である。フローは、次に、ブロック４４５に移動し、ＳＭＳトランジットデバイス１３０は、クライアントデバイス１１０の電話番号、識別トークン１１５及びデバイス識別子１１７を登録サーバ１４０（例えば、セキュアなＩＰメッセージで）に送信する。フローは、ブロック４４５からブロック４５０に移動する。

図３は、一実施形態によるより詳細に登録サーバ１４０を示すブロック図である。図３を図４の例示的な実施形態を参照して説明する。しかし、図４の作動は、図３を参照して説明したもの以外の実施形態により行うことができ、図３を参照して説明する実施形態は、図４を参照して説明したものと異なる作動を行うことができることを理解すべきである。図３に示すように、登録サーバ１４０は、サーバオンライン通信セッション登録モジュール３０５を含み、サーバオンライン通信セッション登録モジュール３０５は、ＳＭＳトランジットインタフェース３１０と、署名発生器３１５、クライアントデバイスインタフェース３２５と、検証モジュール３３０と、検証データストア３３５と、関連付けモジュール３４０とを含む。ＳＭＳトランジットインタフェース３１０は、メッセージを受信してＳＭＳトランジットデバイス１３０に送る。例えば、ＳＭＳトランジットインタフェース３１０は、電話番号、識別トークン及びデバイス識別子タプルをＳＭＳトランジットインタフェース３１０から受信し、電話番号、識別トークン、デバイス識別子及び署名タプル（「検証タプル」こともある）をＳＭＳトランジットインタフェース３１０に送信する。クライアントデバイスインタフェース３２５は受信すると、クライアントデバイスにメッセージを送信することができる。例えば、クライアントデバイスインタフェース３２５は、検証タプルをクライアントデバイスから受信する。

図４を再び参照すると、ブロック４５０で、署名発生器３１０は、電話番号、識別トークン、及びＳＭＳトランジットデバイス１３０から受信したデバイス識別子タプルに対して署名を発生させる。署名は、登録データストア１５０内に対を記憶する前に電話番号及び識別トークンのペアリングを検証するのに使用されることになる。一部の実施形態では、署名は、電話番号、識別トークン及び／又はデバイス識別子に基づくものである（例えば、署名を発生させるために、暗号のハッシュが、電話番号、識別トークンやデバイス識別子、又はその一部に適用される）。一部の実施形態では、署名は、複数のクライアントデバイスが同じ電話番号を有する状況に対処する乱数に基づくものである。署名発生器３１０は、検証データストア３２５内に署名及び任意的に電話番号、識別トークン及び／又はデバイス識別子を記憶する。フローは、次に、ブロック４５５に移動し、ＳＭＳトランジットインタフェース３１０は、署名、電話番号、デバイス識別子及び識別トークンをＳＭＳトランジットデバイス１３０に送信する。フローは、ブロック４５５からブロック４６０に移動する。

ＳＭＳトランジットデバイス１３０は、署名、電話番号、及び識別トークンを登録サーバ１４０から受信する。ブロック４６０で、ＳＭＳトランジットデバイスは、クライアントデバイス１１０の署名及び電話番号を用いてＳＭＳメッセージを送信する（キャリアＳＭＳＣ１２５を通じて）。フローは、次に、ブロック４６５に移動する。

ブロック４６５で、ＳＭＳモジュール２２０は、署名及び電話番号を用いたＳＭＳメッセージを受信し、クライアント登録データストア２３０内に署名及び電話番号を記憶する。フローは、次に、ブロック４７０に移動し、クライアント登録モジュール２１０は、電話番号、識別トークン１１５、デバイス識別子１１７及び署名を用いて登録サーバにＩＰメッセージを送信する。フローは、次に、ブロック４７５に移動する。

クライアントデバイスインタフェース３２５は、電話番号、識別トークン、デバイス識別子及び署名をクライアントデバイスから受信する。情報は、検証モジュール３３０に伝えられ、検証モジュール３３０は、ブロック４７５で、データが有効か否かを判断する。例えば、署名を発生させる時印加するのと同じハッシュ機能が、クライアントデバイスから受信した電話番号、識別トークン及び／又はデバイス識別子上に使用され、検証モジュール３３０は、結果を以前は生成された（検証データストア３３５に記憶済み）署名と比較する。署名が適合した場合に、データは、有効であり、フローは、ブロック４８０に移動する。

ブロック４８０で、登録サーバ１４０の関連付けモジュール３４０は、クライアントデバイスの電話番号及びクライアントデバイスの識別トークンの関連付けを登録データストア１５０に記憶する。一部の実施形態では、登録サーバ１４０は、クライアントデバイス１１０に登録ステータスメッセージを送信して登録が成功したか否かに関してクライアントデバイス１１０の注意を喚起することができる。

クライアントデバイスが登録された後に、クライアントデバイスのユーザは、オンライン通信セッション（例えば、映像チャット／会議セッション、インスタントメッセージセッションなど）を開始し及び／又はその招待を受け入れることができる。一例として、クライアントデバイスのユーザは、電話番号を使用してオンライン通信セッションに参加するように他のクライアントデバイスの他のユーザを招待することができる。一部の実施形態では、クライアントデバイスは、それ自体の電話番号を自然には知らない。実施形態を登録中のＳＭＳメッセージの使用を説明したが、他の実施形態では、他のタイプのテキストメッセージング（例えば、ＭＭ（マルチメディアのメッセージングサービス））を用いることができる。

オンライン通信セッションのための電子メールアドレスの登録
図１をオンライン通信セッション終点識別子として電話番号を登録することに関して説明したが、他の実施形態では、電子メールアドレスが、オンライン通信セッション終点識別子として使用される。図２１は、オンライン通信セッション終点識別子として電子メールアドレスを使用してオンライン通信セッションのためのクライアントデバイスを登録するのに使用される一般的なネットワークトポロジーを示している。クライアントデバイス２１１０Ａ〜Ｎは、オンライン通信セッションに向けて登録するために登録サービス２１３０を使用する。例えば、一実施形態では、クライアントデバイス２１１０Ａのユーザは、オンライン通信セッションクライアント２１１５を使用し、ネットワーク２１８０（例えば、「インターネット」）上のオンライン通信用オンライン通信セッション識別子としての使用向けて電子メールアドレスを登録する。

図２２Ａ〜図２２Ｂは、一実施形態によるオンライン通信セッション終点識別子として電子メールアドレスを登録する例示的な作動を示す流れ図である。図２２Ａ〜図２２Ｂを図２１に示す例示的な実施形態を参照して説明する。しかし、図２２Ａ〜図２２Ｂの作動は、図２１を参照して説明したもの以外の実施形態により行うことができ、図２１を参照して説明した実施形態は、図２２Ａ〜図２２Ｂを参照して説明するものと異なる作動を行うことができることを理解すべきである。

作動２２１０で、登録サービス２１３０は、クライアントデバイス２１１０Ａから認証要求を受信する。例えば、初期化情報を提供するユーザの例示的な作動を説明する図２３を参照すると、作動２３１０で、オンライン通信セッションアプリケーション２１１５は、クライアントデバイス２１１０Ａの上で開始される。フローは、次に、ブロック２３１５に移動し、クライアントデバイス２１１０Ａは、オンライン通信セッション終点識別子としての使用に向けて登録するユーザＩＤ及びパスワード及び１つ又はそれよりも多くの電子メールアドレスを含む入力をユーザから受信する。フローは、次に、作動２３２０に移動し、クライアントデバイス２１１０Ａは、ユーザＩＤ及びパスワードを登録サービス２１３０に送信する。

クライアントデバイス２１１０Ａは、オンライン通信セッション終点識別子として電子メールアドレスを登録し、しかし、電話機能性を含まない場合があるが、電子メールアドレスの代わりに電話番号を使用してオンライン通信セッション招待を送ることができる。登録するユーザＩＤ、パスワード及び１つ又はそれよりも多くの電子メールアドレスを受信することに加えて、一部の実施形態では、ユーザは、ユーザが国別コード及び／又は地域コードを含まない電話番号にオンライン通信セッションを開始する場合に対応する国別コード及び／又は地域コードを使用することができるようにどの国及び／又は地域に現在位置するかに関する情報を提供することができる。例えば、米国では、市内通話は、７桁（従って、国別コード及び市外局番は不要）を使用して行うことができる。基本的電話方式は、自動的に国及び地域コードを判断して通話を完了する。しかし、クライアントデバイス２１１０Ａが電話機能性を含まない場合に、クライアントデバイス２１１０Ａは、国別コード及び／又は地域コードを含まない電話番号を使用してオンライン通信セッションにユーザを招待した時に国別コードや地域コードを自動的に含むように基本的電話方式に頼ることができない。

作動２３２０で、クライアントデバイス２１１０Ａは、どの国及び／又は地域に位置するのか（例えば、市外局番、ステータス、行政区、都市など）に関する入力をユーザから受信する。フローは、次に、ブロック２３２０に移動し、クライアントデバイス２３２０は、ユーザが地方のコードや地域コードを含まない電話番号へのオンライン通信セッションを開始する場合に、対応する国や地域電話国番号を使用に向けてオンライン通信セッションアプリケーション２１１５に関連付ける。例えば、ユーザが米国に位置することを示し、そのユーザが国別コードを含まない１０桁の電話番号を使用してオンライン通信セッションにユーザを招待した場合に、クライアントデバイス２１１０Ａは、電話番号に米国の国別コードを自動的に追加する。

図２２Ａを再び参照すると、クライアントデバイス２１１０Ａから認証要求を受信した後に、認証処理は、供給されたユーザ名及びパスワードを使用して実行される。一実施形態では、登録サービス２１３０が、認証処理を実行し、一方、別の実施形態では、ユーザディレクトリサービス２１６０が、認証処理を実施する。ユーザディレクトリサービス２１６０は、ユーザ会計、認証及び他の検査を行う集中サービスである。ユーザディレクトリサービス２１６０は、ユーザ記録２１６５を管理する。一実施形態では、各々の認証されたユーザは、様々な情報（例えば、ユーザＩＤ、パスワード、郵送先住所、電話番号、名称、誕生日、国、ユーザに関連付けられた電子メールのリスト（電子メールアドレスが検証されたか否かを示すことができる）などの１つ又はそれよりも多く）を含むユーザ記録に関連している。認証が成功した場合に、フローは、作動２２１６に移動する。認証が失敗した場合に、フローは、作動２２１４に移動し、代替アクションが講じられる（例えば、登録サービス２１３０は、ユーザ名及び／又はパスワードが正しくないことを示すエラーメッセージをクライアントデバイス２１１０Ａに送信する）。

作動２２１６で、登録サービス２１３０は、ユーザＩＤに関連付けられたオンライン通信セッションプロフィールを生成又はアクセスする。例えば、登録サービス２１３０は、オンライン通信セッションプロフィール記録２１５０を管理するオンライン通信セッション口座サーバ２１４０を含むことができる。一実施形態では、オンライン通信セッションに向けて登録中であるか又は登録済みである各ユーザは、対応するオンライン通信セッションプロフィール記録を有する。各オンライン通信セッションプロフィール記録は、プロフィールに関連付けられた検証ステータスを含む１組の１つ又はそれよりも多くの電子メールアドレスを含むことができる。各オンライン通信セッションプロフィール記録は、オンライン通信セッションに向けて登録済みである１つ又はそれよりも多くのクライアントデバイスにそれぞれ対応する１つ又はそれよりも多くのプッシュトークンを含むことができる。各プロフィール記録は、クライアントデバイスからの特定の通信を検証するのに使用されるプロフィール信用証明を含むことができる。各プロフィール記録は、どのクライアントデバイス（プッシュトークンにより表示）がどの電子メールアドレスを登録したか、又は登録しようとするかを示すことができる。

フローは、作動２２１６から作動２２１８に移動し、登録サービス２１３０は、プロフィールＩＤ（例えば、供給されたユーザＩＤに関連付けられたプロフィールを識別するストリング）及びプロフィール信用証明を含む認証返答をクライアントデバイス２１１０Ａに送信する。認証返答は、認証が成功したことを示すことができる。フローは、次に、作動２２２０に移動し、登録サービス２１３０は、検証すべき１つ又はそれよりも多くの電子メールアドレス、プロフィールＩＤ、プロフィール信用証明及びクライアントデバイス２１１０Ａのプッシュトークンを含む電子メール検証要求をクライアントデバイス２１１０Ａから受信する。電子メール検証要求メッセージは、クライアントデバイス２１１０ＡのデバイスＩＤを含むことができる。登録サービス２１３０は、次に、作動２２２２で、プロフィール信用証明がプロフィールＩＤに対して有効か否かを判断する。有効ではなかった場合に、フローは、作動２２２４に移動し、代替アクションが講じられる（例えば、登録サービス２１３０は、クライアントデバイス２１１０Ａにエラーメッセージを送信する）。プロフィール信用証明が有効な場合に、フローは、作動２２２３に移動する。作動２２２３で、登録サービス２１３０は、プッシュトークンをプロフィールに関連付ける。例えば、オンライン通信セッションアカウントサーバ２１４０は、ユーザのプロフィール記録内にプッシュトークンを記憶する。

フローは、次に、ブロック２２２６に移動し、登録サービス２１３０は、電子メールアドレスが検証されたか否かを判断する。検証された電子メールアドレスは、オンライン通信セッション終点識別子としての使用に向けて電子メールアドレスを登録するように要求しているユーザのものであると検証された電子メールアドレスである。オンライン通信セッションアカウントサーバ２１４０は、ユーザのプロフィール記録２１５０にアクセスし、電子メールアドレスは検証されたか否かを判断する。プロフィール記録が電子メールアドレスは検証されたことを示さなかった場合に、一部の実施形態では、登録サービス２１３０は、電子メールアドレス検証要求をユーザディレクトリサービス２１６０に送信してユーザのユーザ記録２１６５が電子メールアドレスは検証されたことを示すか否かを判断する。電子メールアドレスが適切性は確認されていなかった場合に、フローは、作動２２２７に移動し、登録サービス２１３０により、検証電子メールメッセージは、選択された時に（又は「インターネット」ブラウザに入力された時に）電子メールアドレスを検証するリンクを含む電子メールアドレスに送られる。例えば、リンクの選択により、電子メールアドレスを検証するのに使用される電子メールアドレス及び検証トークンを含む電子メールアドレス検証メッセージが送られる。登録サービス２１３０は、電子メールアドレスは検証されていない（従って、検証する必要がある）ことを示し、かつ検証電子メールメッセージがこのような電子メールアドレスに送られたことを示すことができる電子メール検証要メッセージをクライアントデバイスに送信することができる。フローは、次に、作動２４１０に移動するが、これは図２４を参照して説明する。しかし、電子メールアドレスが検証された場合に、フローは、作動２２２８に移動する。

作動２２２８で、登録サービス２１３０は、電子メールアドレスが検証されたことを示す電子メールアドレス検証成功メッセージをクライアントデバイス２２２８に送信する。フローは、次に、作動２２３０に移動し、登録サービス２１３０は、電子メールアドレスと、プロフィールＩＤと、プロフィール信用証明とを含むクライアントデバイス２２２８から活性化電子メール要求を受信する。登録サービス２１３０は、次に、作動２２２３で、プロフィール信用証明がプロフィールＩＤに対して有効か否かを判断する。有効ではなかった場合に、フローは、作動２２２４に移動し、代替アクションが講じられる（例えば、登録サービス２１３０は、クライアントデバイス２１１０Ａにエラーメッセージを送信する）。プロフィール信用証明が有効な場合に、フローは、作動２２４０に移動する。

作動２２４０で、登録サービス２１３０は、電子メールアドレスに向けて電子メール信用証明を生成するか又はアクセスする。例えば、一実施形態では、オンライン通信セッションアカウントサーバ２１４０は、そのユーザのプロフィール記録２１５０内のユーザの各々が検証された電子メールアドレスに対して電子メール信用証明を記憶する。フローは、次に、ブロック２２４２に移動し、登録サービス２１３０は、電子メールアドレス及び電子メール信用証明を含むクライアントデバイス２１１０Ａに作動成功メッセージを送信する。

フローは、作動２２４２から作動２２４４に移動し、登録サービス２１３０は、電子メールアドレスと、電子メール信用証明と、プロフィールＩＤと、プロフィール信用証明と、クライアントデバイス２１１０Ａのプッシュトークンと、クライアントデバイス２１１０ＡのデバイスＩＤとを含む登録要求メッセージを受信する。一実施形態では、要求メッセージは、オンライン通信セッション登録サーバ２１４５で受信される。オンライン通信セッション登録サーバは、オンライン通信セッション登録データストア２１５５を管理する。オンライン通信セッション登録データストア２１５５は、プッシュトークン（及び任意的にデバイスＩＤ）をオンライン通信セッション終点識別子として１組の１つ又はそれよりも多くの電子メールアドレスを有するプロフィールに関連付ける。従って、通信セッション登録データストア２１５５内の各記録は、特定のプッシュトークンを有する特定のデバイスがそのデバイスでのユーザをオンライン通信セッションに招待するのに使用することができる１つ又はそれよりも多くの電子メールアドレスを有するオンライン通信セッションプロフィールを使用することを表している。フローは、作動２２４４から作動２２４６まで移動する。

作動２２４６で、登録サービス２１３０（例えば、オンライン通信セッション登録サーバ２１４５）は、プロフィール信用証明が有効か否かを判断する。有効でなかった場合に、フローは、作動２２５０に移動し、代替アクションが講じられる（例えば、登録サービス２１３０は、クライアントデバイス２１１０Ａにエラーメッセージを送信する）。有効であった場合に、フローは、作動２２２８に移動し、登録サービス２１３０（例えば、オンライン通信セッション登録サーバ２１４５）は、電子メールアドレス信用証明が有効か否かを判断する。有効ではなかった場合に、フローは、作動２２５０に移動する。有効であった場合に、フローは、作動２２５２に移動する。

作動２２５２で、登録サービス２１３０（例えば、オンライン通信セッション登録サーバ２１４５）は、プッシュトークンを有するクライアントデバイス２１１０Ａを電子メールアドレスを有するプロフィールに関連付けて登録データストア２１５５内にその関連付けを記憶する。フローは、次に、ブロック２２５４に移動し、登録サービス２１３０は、オンライン通信セッションアカウント識別子及びオンライン通信セッション信用証明を生成し、作動２２５６でクライアントデバイス２１１０Ａに送信する。

実施形態が異なれば、電子メールアドレスを検証する方法も異なる。電子メールアドレスを検証する例示的な作動を示す流れ図である図２４を参照すると、作動２４１０で、クライアントデバイス２１１０Ａは、それが、登録しようとし、かつポジティブな検証電子メールメッセージを受信していない電子メールアドレスのアカウントを含む電子メールクライアントを含むか否かを判断する。このような電子メールクライアントを含んでいなかった場合に、フローは、作動２４４０に移動するか、又は含んでいた場合に、フローは、作動２４１５に移動する。

作動２４１５で、電子メールアカウントは、自動的かつ定期的に検証電子メールメッセージ（例えば、作動２２２７で送信された検証電子メールメッセージ）がないかを点検される。一実施形態では、オンライン通信セッションアプリケーション２１１５は、検証電子メールメッセージがないかを検査するように電子メールクライアント２１２０を定期的に要求する（電子メールクライアント２１２０は、電子メールサーバ２１７０をポーリングして検証電子メールメッセージかないかを検査することができる）。検証電子メールメッセージは、電子メールアドレスを検証するのに使用されるＦｒｏｍ：フィールド、Ｔｏ：フィールド、及び検証トークン（検証トークンは、検証された各電子メールアドレスに対して独特のものとすることができる）を含む１組の１つ又はそれよりも多くの基準により識別される。検証トークンは、検証電子メールメッセージのヘッダ又は本文に位置することができる。検証電子メールメッセージを受信した場合に、フローは、作動２４２０から作動２４２５まで移動し、受信されなかった場合に、フローは、作動２４３５に移動する。

作動２４２５で、検証電子メールメッセージは、オンライン通信セッションアプリケーション２１１５に戻され、オンライン通信セッションアプリケーション２１１５は、メッセージを構文解析して検証トークンを位置付ける。検証トークンを位置付けた後に、オンライン通信セッションアプリケーション２１１５は、検証トークン、電子メールアドレス、プロフィールＩＤ、及びプロフィール信用証明を用いて電子メールアドレス検証メッセージを登録サービス２１３０に送信する。従って、この実施形態では、電子メールアドレスは、自動的に検証され、ユーザは、リンクをクリックし又は他の方法で電子メールアドレスを検証する必要がない。一実施形態では、メッセージを受信し、プロフィール信用証明が有効であると判断した後に、登録サービス２１３０は、電子メールアドレスの検証が成功したことを示す電子メール検証済みプッシュメッセージをデバイスに送信する（プッシュ通知サービス６４０を通じて）。従って、フローは、作動２４２５から作動２４３０に移動し、クライアントデバイス２１１０Ａは、電子メールアドレス検証済みプッシュメッセージを受信するのを待つ。

検証電子メールメッセージが受信されなかった場合に、フローは、作動２４３５に移動し、クライアントデバイスは、登録されようとする電子メールアドレスが検証されたことを示す電子メール検証済みプッシュメッセージを受信したか否かを判断する。このようなメッセージを受信した場合に、フローは、作動２４４５に移動し、受信されなかった場合に、フローは、作動２４１５に戻る。

作動２４４０で（クライアントデバイス２１１０Ａは、登録された電子メールアドレスのアカウントを含む電子メールクライアントを含まない）、クライアントデバイス２１１０Ａは、登録されようとする電子メールアドレスが検証されたことを示す電子メール検証済みプッシュメッセージを受信するのを待つ。このようなメッセージを受信した場合に、フローは、作動２４４５に移動し、受信されなかった場合に、フローは、作動２４４０５に留まる。

作動２４４５で、クライアントデバイス２１１０Ａは、電子メールアドレスが検証されたことを表示し、ユーザにその電子メールアドレスで登録処理を続けるように求める。クライアントデバイス２１１０Ａが登録処理を続けることを示す入力を受信した場合に、フローは、作動２４５５に移動し、クライアントデバイス２１１０Ａは、電子メールアドレスと、プロフィールＩＤと、プロフィール信用証明とを含むアクティブ電子メール要求を登録サーバに送信する。図２２の作動２２３０で始まると説明した作動が、次に、実行される。クライアントデバイス２１１０Ａが、ユーザが登録処理を再開したくないことを示す入力を受信した場合に、フローは、作動２４５０から作動２４６０に移動し、処理は、終了する。

図２５は、一実施形態による電子メールアドレスが検証された時に登録サービスに行われる例示的な作動を示す流れ図である。作動２５１０で、登録サービス２１３０は、オンライン通信セッションプロフィールに関連付けられた電子メールアドレスが検証されたことを示す電子メールアドレス検証済みステータスメッセージを受信する。電子メール検証済みステータスメッセージは、作動２４２５の結果として受信した場合があるか、又は異なる方法で検証される電子メールアドレスの結果として受信した場合がある（例えば、ユーザが検証メッセージング内の検証リンクをクリックすることによってメッセージアドレスが検証され、電子メールアドレスは、オンライン通信セッションにおける使用に向けて電子メールアドレスを登録しようとするデバイスと異なるデバイス上で送られる場合がある）。

フローは、次に、作動２５１５に移動し、登録サービス２１３０は、プロフィール記録２１５０において電子メールアドレスの検証ステータスを更新する。フローは、次に、作動２５１５に移動し、登録サービス２１３０は、電子メールアドレスを検証することを求めた電子メール検証済みメッセージを受信していないオンライン通信セッションプロフィールに関連しているクライアントデバイスがあるか否かを判断する。例えば、登録サービス２１３０は、オンライン通信セッションプロフィールに向けてプロフィール記録２１５０にアクセスし、どのクライアントデバイス（例えば、独自のプッシュトークンにより識別された）が電子メールアドレスを検証するように求めてその電子メールアドレスの電子メールアドレス検証メッセージを受信していないかを判断する。各このようなクライアントデバイスに対し、登録サービスは、電子メール検証済みプッシュメッセージをプロフィールＩＤと、プロフィール信用証明と、作動２５２５で検証された電子メールアドレスとを含むそのクライアントデバイスに送信する。電子メール検証済みプッシュメッセージは、電子メールアドレスが検証されたことを示すステータス更新を含むことができる。電子メールアドレスを検証するように求めた電子メール検証済みメッセージを受信していないデバイスがない場合に、フローは、作動２５３０に移動し、処理は、終了する。

オンライン通信セッションの確立
図６に示すように、一実施形態に実施された一般的なネットワークトポロジーは、ネットワーク６６０上で互いと及び１つ又はそれよりも多くのサービス６１０、６２０、６３０、６４０、及び６５０と通信するそれぞれいくつかのクライアントデバイスＡ〜Ｎ、６７０Ａ〜Ｎを含むことができる。単一のネットワーククラウドであるように示されたが、ネットワーク６６０は、少し例を挙げれば、「インターネット」のようなパブリックネットワーク、及びＷｉＭＡＸネットワーク（例えば、８０２．ｎホーム無線ネットワーク又は無線ホットスポット）、ローカルＷｉ−Ｆｉネットワーク、ローカルエリアイーサネット（登録商標）ネットワーク、セルラーデータネットワーク（例えば、３Ｇ、４Ｇ、Ｅｄｇｅなど）のようなプライベートネットワークを含む様々な異なる構成要素を含むことができる。クライアントデバイス６７０Ａ〜Ｎは、異なるネットワークリンク上でネットワーク６６０に接続することができる。例えば、クライアントデバイス６７０Ａは、ネットワークリンク６７５Ａにより表されるホームＷｉ−Ｆｉネットワークに接続することができ、クライアントデバイス６７０Ｎは、ネットワークリンク６７５Ｎ上で３Ｇネットワーク（例えば、ユニバーサル移動通信システム（ＵＭＴＳ）、高速アップリンクパケットアクセス（ＨＳＵＰＡ）など）に接続することができる。クライアントデバイス６７０Ａ〜Ｎが接続されるネットワークリンク６７５Ａ〜Ｎの各々は、ゲートウェイ及び／又はＮＡＴ（ネットワークアドレス変換）デバイス（図６には図示せず）を通じて「インターネット」のようなパブリックネットワークに結合することができ、従って、パブリックネットワーク上の様々なクライアントデバイス６７０Ａ〜Ｎ間の通信が可能である。しかし、２つのクライアントデバイスが同じローカルネットワーク又はプライベートネットワーク（例えば、同じＷｉ−Ｆｉネットワーク）上にある場合に、２つのデバイスは、パブリックネットワークをバイパスし、そのローカルネットワーク／プライベートネットワーク上で直接に通信することができる。勿論、本発明の根本的原理は、あらゆる特定の１組のネットワークタイプ又はネットワークトポロジーに限定されないことに注意すべきである。

クライアントデバイス６７０Ａ〜Ｎの各々は、接続データ交換（ＣＤＸ）サービス６１０、招待サービス６２０、登録サービス６３０、プッシュ通知サービス６４０、及びリレーサービス６５０と通信することができる。一実施形態では、サービス６１０−６５０は、サーバのような１つ又はそれよりも多くの物理的コンピュータデバイス上で実行されるソフトウエアとして実施することができる。

一実施形態では、ＣＤＸサービス６１０は、２つ又はそれよりも多くのクライアントデバイス間のオンライン通信セッションを確立するのに必要とされる接続データの中心相互接続点として作動する。具体的には、ＣＤＸサービス６１０の一実施形態は、外部サービス及びクライアントが各クライアントデバイスのＮＡＴを通じて通信する（すなわち、デバイスに到達するためにＮＡＴを通じて「孔を開ける」ために）ことを可能にするクライアントデバイス要求に応答してＮＡＴトラバーサルデータ（「ホールパンチ」データと呼ぶこともある）を生成する。例えば、一実施形態では、ＣＤＸサービスは、クライアントデバイスと通信するのに必要とされる外部ＩＰアドレス及びポートを検出してクライアントデバイスにこの情報を提供する。一実施形態では、ＣＤＸサービスは、招待サービス６２０によって生成されたクライアントデバイスのリストも受信及び処理し、リスト上に含まれたクライアントデバイスの各々に効率的にかつ確実に接続データを配信する（以下で詳細に説明するように）。

クライアントデバイス６７０Ａ〜Ｎのユーザは、招待サービス６２０を使用し、共同オンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージチャット／会議など）に参加するようにユーザを招待する。例えば、クライアントデバイス６７０Ａのユーザは、他のユーザの各々のオンライン通信セッション終点識別子を含む招待サービス６２０に招待要求を送信することにより、１つ又はそれよりも多くの異なるクライアントデバイスの１つ又はそれよりも多くのユーザとのオンライン通信セッションを要求する。オンライン通信セッション終点識別子は、異なる実施形態において異なるもの（例えば、電話番号、ユーザ名（例えば、アップルＩＤ）、電子メールアドレス、郵送先住所、ＭＡＣアドレス又は他の識別子）とすることができる。招待サービス６２０は招待要求からオンライン通信セッション終点識別子を読み取って、登録データストア６５５において検索を実行してオンライン通信セッション終点識別子に関連付けられたクライアントデバイスを位置付ける。

クライアントデバイス６７０Ａ〜Ｎは、オンライン通信セッションに向けて登録するために登録サービス６３０を使用する。例えば、一実施形態では、クライアントデバイス６７０Ａ−Ｎの各々の電源を投入されて、ネットワークの上で作動された時に、識別トークン（例えば、プッシュトークン）をオンライン通信セッション終点識別子に関連付ける。関連付けは、登録データストア６５５に記憶される。一実施形態では、クライアントデバイス６７０Ａ〜Ｎは、図４に関して上述したように、登録サービス６３０を使用してオンライン通信セッションサービスに関する参加に向けて登録し、一方、他の実施形態では、登録処理は、違った方法で行われる（例えば、プッシュトークン及びオンライン通信セッション終点識別子を供給することにより）。

プッシュ通知サービス６４０はクライアントデバイス６７０Ａ−Ｎのプッシュトークンを使用し、プッシュ通知をクライアントデバイス６７０Ａ〜Ｎに送信する。一実施形態では、プッシュ通知は、オンライン通信セッションの招待を送信するのに使用される。リレーサービス６５０は、クライアントデバイスのＮＡＴタイプが適合しないか、又はＰ２Ｐ接続確立がクライアントデバイス間に失敗した時にクライアントデバイス間のオンライン通信セッション接続を確立する。

一実施形態では、ユーザデータグラムプロトコル（ＵＤＰ）ソケットのような比較的軽量ネットワークプロトコルを使用してクライアントデバイスとＣＤＸサービス６１０間の通信を確立する。当業者には公知であるように、ＵＤＰソケット接続は、パケットに信頼性、順序付け又はデータ保全性を留保するハンドシェイキングダイアログを必要とせず、従って、ＴＣＰソケット接続ほど多くのパケット処理オーバヘッドを消費しない。その結果、ＵＤＰ軽量のステートレスの性質は、非常に多くのクライアントから小さいクエリに応答するサーバに有用である。更に、ＴＣＰとは異なり、ＵＤＰは、パケットブロードキャスティング（パケットがローカルネットワーク上の全てのデバイスに送られる）及びマルチキャスティング（パケットがローカルネットワーク上のデバイスの部分集合に送られる）に適合する。以下に説明するように、たとえＵＤＰを使用することができるとしても、セッションキーを使用してセキュリティをＮＡＴトラバーサルデータを暗号化することによってＣＤＸサービス６１０上で維持することができる。

ＣＤＸサービス６１０によって使用される低値オーバヘッド軽量ネットワークプロトコルとは対照的に、一実施形態では、クライアントデバイス６７０Ａ〜Ｎと招待サービス６２０、登録サービス６３０、プッシュ通知サービス６４０、及び／又はリレーサービス６５０間の通信は、セキュアソケットレイヤ（ＳＳＬ）又はトランスポート層セキュリティ（ＴＬＳ）接続に頼るハイパーテキスト転送プロトコルセキュア（ＨＴＴＰ）のような本質的にセキュアなネットワークプロトコルで確立される。これらのプロトコルに関連の詳細は、当業者に公知である。

図７は、一実施形態によるクライアントデバイス間のオンライン通信セッション確立を示すデータ流れ図である。図７の例において、クライアントデバイスＡ７１０のユーザは、クライアントデバイスＢ７２０のユーザをオンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージ通信システムなど）に招待する。この実施例では、クライアントデバイスＡ７１０は、開始クライアントデバイスこともあり、クライアントデバイスＢ７２０のユーザは、意図する受信者こともあり、クライアントデバイスＢ７２０は、意図する受信者クライアントデバイスこともある。一部の実施形態では、オンライン通信セッション招待は、プレゼンスのない盲目的な招待である。例えば、クライアントデバイスＡ７１０のユーザは、クライアントデバイスＢ７２０のユーザが現在オンラインであるか、又はオンライン通信セッションに参加するのに利用可能か否かに関して知っていない。

図６及び図７を参照して説明する実施形態は、プッシュトークン及びプッシュ通知を使用することを専門とするが、他の実施形態は、そのように限定されない。例えば、他の実施形態では、独自のトークンにクライアントデバイスのあらゆる登録又はマッピングを用いて識別トークンをクライアントデバイスに関連付け、かつクライアントデバイスのアイデンティティを一意的に識別されたトークンに関連付ける信頼された方法を提供することができる。

作動１で、クライアントデバイスＡ７１０は、接続データを接続データ交換部６１０に要求する。接続データは、クライアントデバイスが相互に交換してオンライン通信セッション（例えば、Ｐ２Ｐセッション）を確立するための情報を含む。接続データは、クライアントデバイスのＩＰアドレス（例えば、パブリックＩＰアドレス）、要求のポート番号及び他の情報（例えば、プリファレンス情報など）を含む。接続データ交換部６１０は、クライアントデバイスＡ７１０の接続データ（例えば、パブリック／プライベートＩＰアドレス及びポート、クライアントデバイスＡのＮＡＴデバイスのＮＡＴタイプ）を判断する。作動２で、接続データ交換部６１０は、接続データをクライアントデバイスＡ７１０に戻す。

作動３で、クライアントデバイスＡ７１０は、オンライン通信セッション招待要求を招待サービス６２０に送信し、クライアントデバイスＢ７２０をオンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージセッションなど）に招待する。一実施形態では、招待は、クライアントデバイスＡ７１０の接続データを含み、クライアントデバイスＡ７１０の接続データには、クライアントデバイスＡ７１０パブリック／プライベートＩＰアドレス及びポート、クライアントデバイスＡのＮＡＴデバイスのＮＡＴタイプ、クライアントデバイスＢ７２０のユーザに関連付けられたオンライン通信セッション終点識別子（例えば、クライアントデバイスＢ７２０の電話番号、ユーザのユーザ名（例えば、アップルＩＤ）、電子メールアドレス、メーリングアドレス、ＭＡＣアドレスなど）を含むことができる。オンライン通信セッション招待要求は、ＨＴＴＰ要求の形式を取ることができ、プレ−指定の証明権限者により署名されたクライアント証明書を含むことができる。

作動４で、招待サービス６２０は、作動３の要求内に含まれたオンライン通信セッション終点識別子に関連付けられたプッシュトークンを判断する。例えば、招待サービス６２０は、登録データストア６５５にアクセスしてオンライン通信セッション終点識別子に関連付けられたプッシュトークンを判断する。図７に示すように、プッシュトークン７２５は、クライアントデバイスＢ７２０に割り当てられ、従って、オンライン通信セッション終点識別子に関連付けられる。図１０は、一実施形態による例示的な登録データストア６５５を示している。図１０に示すように、オンライン通信セッション識別子記録１０１０の各々は、プッシュトークンフィールド１０１５とオンライン通信セッション識別子フィールド１０２０とを含む。図１０に示すように、同じオンライン通信セッション識別子を複数のプッシュトークンに関連付けることができる。このような場合に、複数の招待が送信されることになる（例えば、プッシュトークン当たりに１つ）。

招待サービス６２０は、プッシュ要求メッセージをプッシュ通知サービス６４０に送信する。作動５で、プッシュ通知サービス６４０は、プッシュ通知メッセージの形態でオンライン通信セッション招待要求をクライアントデバイスＢ７２０に送信する。要求は、接続データと、オンライン通信セッション終点識別子）と、クライアントデバイスＡ７１０のプッシュトークン（プッシュトークン７１５）とを含む。招待要求は、招待に関する情報（例えば、招待を送る人の名称（例えば、ユーザ名、実際の名称、電話番号又はその何らかの組合せ）、招待の目的（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージセッションなど））をクライアントデバイスＢ７２０のユーザに供給するためのオンライン通信セッション特定の情報を含むことができる。

オンライン通信セッション招待要求は、電源が投入されて正しく作動している場合に、クライアントデバイスＢ７２０上で受信及び表示される。招待要求は、ユーザが招待を受諾又は拒否する機構（例えば、受諾ボタン及び拒否ボタン）を含む。クライアントデバイスＡ７１０のユーザは、招待要求が拒否された場合に通知を受信することができる。クライアントデバイスＢ７２０のユーザが招待要求を受諾すると仮定し、作動６で、クライアントデバイスＢ７２０は、接続データを接続データ交換部６１０に要求する。接続データ交換部６１０は、クライアントデバイスＢ７２０）の接続データ（例えば、パブリック／プライベートＩＰアドレス及びポート、クライアントデバイスＢのＮＡＴデバイスのＮＡＴタイプ）を判断し、作動７で、接続データをクライアントデバイスＢ７２０に戻す。

クライアントデバイスＢ７２０は、次に、作動８で、受諾メッセージを招待サービス６２０に送信する。受諾メッセージは、クライアントデバイスＢの７２０接続データを含み、かつクライアントデバイスＡ７１０のプッシュトークンを含む。受諾メッセージは、クライアントデバイスＡ７１０とクライアントデバイスＢ７２０の間の以前の失敗した直接のＰ２Ｐ接続試行からの再試行であるか否かに関する表示を含む場合もある。受諾メッセージは、ＨＴＴＰメッセージの形式を取ることができる。

一部の実施形態では、招待サービス６２０は、クライアントデバイスＡ７１０とクライアントデバイスＢ７２０の間のＰ２Ｐ接続が達成可能であるか否かを判断する。作動９で、招待サービス６２０は、クライアントデバイスＡ及びＢ間の直接のＰ２Ｐ接続が達成可能であるか否かを判断する。例えば、一実施形態では、クライアントデバイスＢ６２０から受信した受諾メッセージが以前の失敗した直接の接続試行からの再試行（又は指定の回数の以前の失敗した直接の接続試行）であることを示す場合に、招待サービス６２０は、直接のＰ２Ｐ接続が実行不可能であると結論を下す場合がある。達成可能性を判断するために、招待サービス６２０は、クライアントデバイスＡ及びＢのＮＡＴタイプデータを比較し、クライアントデバイスＡ及びＢのＮＡＴデバイスが直接のＰ２Ｐ接続をサポートするか否かを判断することができる。一実施形態では、上述の受諾メッセージは、以前の失敗した試行の表示を含まない。むしろ、失敗した直接の接続試行の後に、クライアントデバイス７１０〜７２０のいずれかは、リレー接続が必要であることを示す特別「リレー招待」要求（例えば、図７内の作動３での招待要求の代わりに）を送信することができる。これに応答し、招待サービスは、本明細書に説明する（以下に説明するように）リレー作動を自動的に呼び出すことができる。

ＮＡＴタイプのある一定の組合せは、Ｐ２Ｐ接続を確立するのに不適合であることは公知である。例えば、全コーンＮＡＴは、直接のＰ２Ｐ接続を確立するクローズド／ファイアウォールＮＡＴを除きあらゆる他のＮＡＴタイプと使用することができる。一方、対称ＮＡＴは、直接のＰ２Ｐ接続を確立するために全コーンＮＡＴとのみ使用することができる。一実施形態において様々なＮＡＴタイプを結合する達成可能性は、図１１に示すＮＡＴ互換性チャート１１１０に定められ、表中、縦列は、１つのクライアントデバイス（例えば、クライアントデバイスＡ７１０）のＮＡＴタイプを表し、横列は、他のクライアントデバイス（例えば、クライアントデバイスＢ７２０）のＮＡＴタイプを表している。セル内のＡ「１．０」は、関連の横列及び縦列内のＮＡＴタイプが適合することを示し、「０．０」は、ＮＡＴタイプが不適合であることを示している。

招待サービス６２０が、直接のＰ２Ｐ接続が達成可能であると判断した場合に、招待サービス６２０は、招待要求の受諾を送信するプッシュ要求をプッシュ通知サービス６４０に送信する。従って、作動１０Ｂで、プッシュ通知サービス６４０は、プッシュ通知の形態でオンライン通信セッション受諾メッセージをクライアントデバイスＢ７１０に送信する。受諾メッセージは、接続データと、オンライン通信セッション終点識別子と、クライアントデバイスＢ７２０プッシュトークンとを含む。受諾メッセージは、クライアントデバイスＡ７１０上に表示されることになる。クライアントデバイスＡ及びＢが互いの接続データを有するので、クライアントデバイスＡ及びＢは、直接のＰ２Ｐ接続を確立するのに十分な情報を有する。従って、作動１１Ａで、クライアントデバイスＡ及びＢは、やり取りされた接続データを使用して直接のＰ２Ｐ接続を確立する。直接のＰ２Ｐ接続は、公知の機構を通じて（例えば、インターネットコネクティビティエスタブリッシュメント（ＩＣＥ）又は他の公知のＰ２Ｐ接続性機構を使用して）確立することができる。

しかし、招待サービス６２０が、直接のＰ２Ｐ接続が実行不可能であると判断した場合に、それは、作動１０Ｂでリレー検索要求をリレーサービス６５０に送信し、クライアントデバイスＡ及びＢが接続に使用すべき１つ又はそれよりも多くのリレーホストを判断する。リレー検索要求は、クライアントデバイスの両方に適切なリレーホストを選択するためにリレーサービス６５０によって使用されるクライアントデバイスＡ及びＢのネットワーク情報（例えば、ＮＡＴトラバーサル／接続データ及び／又はＮＡＴタイプデータ）を含むことができる。

図８に示すように、一実施形態では、リレーサービス６５０は、リレー検索モジュール８０５と、複数のリレーホスト８１５Ａ〜Ｂと、リレーホスト８１５Ａ〜Ｂの各々に関連付けられたネットワーク情報を含むリレーホストデータベース８１０とを含む。図８が２つのリレーホストを示すが、一部の実施形態ではリレーホスト数の増加又は低減がある場合があることを理解すべきである。招待サービス６２０は、リレー検索要求をリレー検索モジュール８０５に送信し、リレー検索モジュール８０５は、クライアントデバイスＡ及びＢのネットワーク情報を使用してリレーホストデータベース８１０に問い合わせる。データベース結果を受信すると、リレー検索モジュール８０５は、作動１１Ｂで、選択されたリレーホスト８１５Ａ〜Ｂを識別する応答を招待サービス６２０に供給する。

一実施形態では、リレー検索応答は、リレーサービス６５０と、リレー接続に向けてクライアントデバイスＡ及びＢにより使用すべき選択されたリレーホスト８１５Ａのネットワークアドレス（ＩＰアドレス／ポート）によって生成されたリレートークンとを含む。一実施形態では、リレートークンは、リレーセッションに関連しており、リレーサービス６５０に接続すると、クライアントデバイスＡ及びＢを認証するためにリレーホスト８１５Ａによって使用される。トークンは、例えば、独自のＩＤリレーセッションＩＤコード、デジタル証明書、及び／又はリレーセッションに関連付けられた独自の暗号化キーを含む様々な形を取ることができる。

招待サービス６２０は、リレー接続が行われることになることを示すリレー応答をクライアントデバイスＡ及びＢに送信する。一実施形態では、クライアントデバイスＢへのリレー応答は、リレーホスト８１５Ｂのリレートークン及びネットワーク情報を含むことができる。一実施形態では、クライアントデバイスＢへの応答は、クライアントデバイスＢの招待受諾メッセージに応答して送られているので直接に送ることができる（プッシュ通知サービス６４０をバイパスして）。招待サービス６２０は、リレーホストＡ８１５Ａのリレートークン及びネットワーク情報を含むことができるリレー応答をクライアントデバイスＡにも送信する。この例において、応答は、プッシュ通知サービス６４０を通じてクライアントデバイスＡにプッシュされる。

作動１２Ｂで、クライアントデバイスＡ７１０は、リレーホスト８１５Ａのネットワーク情報を使用し、リレーサービス６５０との接続を確立する。同様に、作動１３Ｂ０で、クライアントデバイスＡ７２０は、リレーホスト８１５Ｂのネットワーク情報を使用し、リレーサービス６５０との接続を確立する。これらのトランザクションの各々において、新しいホールが、クライアントデバイスＡ及びＢのあらゆるＮＡＴファイアウォールに開けられ、クライアントデバイスＡ及びＢのＮＡＴトラバーサル／接続データは、リレーサービス６５０により判断し、それぞれ、クライアントデバイスＡ及びＢに戻すことができる（例えば、デバイスのパブリックＩＰ／ポートを判断することにより）。一実施形態では、リレーサービス６５０及びクライアントデバイスＡ及びＢは、トラバーサルユージングリレーＮＡＴ（ＴＵＲＮ）プロトコルを実施し、それによって当業者により理解されるように、ＮＡＴ又はファイアウォールの後の要素は、ＴＣＰ又はＵＤＰ接続で着信データを受信することができる。

作動１４Ｂで、クライアントデバイスＡ７１０は、招待サービス６２０にリレー更新を送信し、リレー更新はプッシュ通知サービスに転送され、作動１７ＢでクライアントデバイスＢ７２０にプッシュされる。同様に、作動１５ＢでクライアントデバイスＢ７２０は、招待サービス６２０にリレー更新を送信し、リレー更新は、プッシュ通知サービス６２０に転送されて、作動１６ＢでクライアントデバイスＡ６１０にプッシュされる。クライアントデバイスＡ７１０によって送信されたリレー更新は、リレーサービス６５０により判断されたセッショントークンと、各デバイスのオンライン通信セッション終点識別子と、ＮＡＴトラバーサル／接続データとを含むことができる。

作動１８Ｂ及び１９Ｂで、クライアントデバイスＡ及びＢは、それぞれ、リレーサービス６５０を通じてオンライン通信セッション接続を確立する。一実施形態では、リレー接続は、クライアントデバイスＡ７１０がリレーサービス６５０にＮＡＴにクライアントデバイスＢ７２０のトラバーサル／接続データを送り、クライアントデバイスＡ７２０がリレーサービス６５０にＮＡＴにクライアントデバイスＢ７１０のトラバーサル／接続データを送った時に確立することができ、従って、リレーサービスは、各ピアのリレーホスト８１５Ａへの正しい経路を判断することができる。

上述の技術を使用し、招待サービス６２０は、非常に多くのクライアントデバイスを有する大規模システムにおいてさえも、本質的に拡張性がありかつ弾力的なステートレスのサービスとして実施することができる。例えば、プッシュ通知サービス６４０が本質的に登録されたクライアントデバイスを位置付けてコンテンツを登録されたクライアントデバイスにプッシュすることができるので、招待サービス６２０は、各デバイスの現在の位置を追跡することを必要としない。更に、デバイスは要求及び応答を用いてＮＡＴトラバーサル／接続データを送信することができるので、招待サービス６２０は、決して接続当たりのステータス情報を維持することは必要とされず、従って、招待サービスの記憶必要量及び処理必要量が低減される。このような実施例は、特に大規模なシステムにおいて有用である。

図７は、クライアントデバイスのユーザがオンライン通信セッションに単一のユーザを招待するのを説明しているが、実施形態は、そのように限定されない。例えば、一部の実施形態では、クライアントデバイスのユーザは、複数のユーザをオンライン通信セッションに招待することができる。例えば、ユーザは、複数のオンライン通信セッション終点識別子を用いて単一の招待要求メッセージを招待サービスに送信し、オンライン通信セッションに参加するように異なるクライアントデバイスの複数のユーザを招待することができる。

一部の状況では、ユーザは同じオンライン通信セッション終点識別子に関連付けられた複数のクライアントデバイスを有することができる。図２６は、ユーザが同じオンライン通信セッション終点識別子に関連付けられている複数のクライアントデバイスを有する時に招待を管理する例示的な作動を示すデータ流れ図である。

クライアントデバイスＡ（ユーザＡにより操作）２６１０は、作動２６３２で接続データ交換部６１０への接続データの要求を送信する。接続データ交換部６１０は、作動２６３４でクライアントデバイスＡの接続データを戻す。クライアントデバイスは、次に、オンライン通信セッション（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージセッション、映像通話など）にユーザＢを招待するために、ユーザＩＤ（Ｂ）を用いて招待サービス６２０にオンライン通信セッション招待要求を送信する。招待要求は、Ａの接続データを含む。

招待サービスは、作動２６３８で、招待要求メッセージ内に含まれたＢのＩＤに基づいてディレクトリルックアップを提供する。この例において、ディレクトリルックアップ作動では、クライアントデバイスＢ１のプッシュトークン及びクライアントデバイスＢ２のプッシュトークンを戻す。従って、クライアントデバイスＢｌ及びＢ２は、ＢのＩＤに関連付けられる。招待サービス６２０は、次に、作動２６４０で、クライアントデバイスＢ１（２６１５）及びクライアントデバイスＢ２（２６２０）に招待要求メッセージをプッシュするためにプッシュ通知サービス６４０にプッシュ要求メッセージを送信する。プッシュ通知サービス６４０は、作動２６４２でクライアントデバイスＢ１２６１５に、及び作動２６４４でクライアントデバイスＢ２（２６２０）にプッシュ通知メッセージの形態でオンライン通信セッション招待要求を送信する。各招待要求メッセージは、クライアントデバイスＡ２６１０の接続データと、ユーザＡによって使用されるオンライン通信セッション終点識別子と、クライアントデバイスＡ２６１０のプッシュトークンとを含む。招待要求は、オンライン通信セッション特定の情報（例えば、招待を送る人の名称（例えば、ユーザ名、実際の名称、電話番号又はその何らかの組合せ）、招待の目的（例えば、Ｐ２Ｐテレビ会議、Ｐ２Ｐインスタントメッセージセッションなど））を含むことができる。従って、オンライン通信セッション招待要求は、最初の招待要求内に含まれたオンライン通信セッション終点識別子に関連付けられたデバイスの各々に送られる。

一実施形態では、招待サービス６２０は、招待がどのクライアントデバイスに送信されたかを示すステータスメッセージを招待側クライアントデバイスに送信する。従って、作動２６４６で、招待サービス６２０は、オンライン通信セッション招待要求がクライアントデバイスＢ１（２６１５）及びクライアントデバイスＢ２（２６２０）に送られたことを示す招待ステータス更新をクライアントデバイスＡ２６１０に送信する。一実施形態では、クライアントデバイスＡ２６１０は、どのクライアントデバイスが招待を受け入れるかに対して追跡し、他のクライアントデバイスをオンライン通信セッションの状態を既知であるように保つ。

一実施形態では、クライアントデバイスＢ１（２６１５）及びクライアントデバイスＢ２（２６２０）は、電源が投入されて招待要求を受信することができた場合は招待要求を表示する。図２６に示す例において、クライアントデバイスＢ１（２６１５）のユーザは、招待を受諾することになる。従って、作動２６４８で、クライアントデバイスＢ１（２６１５）は、接続データを接続データ交換部６１０に要求する。接続データ交換部６１０は、クライアントデバイスＢ１（２６１５）の接続データを判断し、作動２６５０で、クライアントデバイスＢ１（２６１５）に戻す。

クライアントデバイスＢ１（２６１５）は、次に、作動２６５２で、受諾メッセージを招待サービス６２０に送信する。受諾メッセージは、クライアントデバイスＢ１（２６１５）の接続データと、クライアントデバイスＡ２６１０のプッシュトークンとを含む。受諾メッセージは、クライアントデバイスＡ２６１０とクライアントデバイスＢ２６１５の間の以前の失敗した直接のＰ２Ｐ接続試行からの再試行であるか否かに関する表示を含む場合もある。更に、受諾メッセージは、Ａ及びＢのオンライン通信セッション終点識別子と、クライアントデバイスＢ２６１５のプッシュトークンとを含むことができる。

一部の実施形態では、オンライン通信セッションに対する受諾メッセージを受信した後に、招待サービス６２０は、直接のＰ２Ｐ接続が達成可能であるか否かを判断する。従って、作動２６５４で、招待サービス６２０は、直接のＰ２Ｐ適合性検査を行って、上述のものと同様の方法で、クライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間の直接のＰ２Ｐ接続が達成可能であるか否かを判断する。クライアントデバイスが直接のＰ２Ｐ接続に適合した場合に、図２７を参照して説明した作動（作動２７１０で開始）が実行される。クライアントデバイスが直接のＰ２Ｐ接続に適合しなかった場合に、図２８を参照して説明した作動（作動２８１０で開始）が実行される。

直接のＰ２Ｐ接続が達成可能であった時に実行される作動を示す図２７を参照すると、作動２７１０で、招待サービス６２０は、クライアントデバイスＢ１（２６１５）による招待の受諾を送信するためにプッシュ通知サービス６４０にプッシュ要求を送信する。作動１０Ｂで、プッシュ通知サービス６４０は、プッシュ通知の形態でオンライン通信セッション受諾メッセージをクライアントデバイスＢ２６１０に送信する。この受諾メッセージは、クライアントデバイスＢ１（２６１５）の接続データ及びプッシュトークンと、ユーザＢによって使用されるオンライン通信セッション終点識別子とを含む。

一実施形態では、クライアントデバイスＢ１（２６１５）が招待を受諾したことを示す受諾メッセージを受信した後に、しばらくしてクライアントデバイスＡ２６１０は、クライアントデバイスＡ２６２０が招待を受諾したことをクライアントデバイスＢ２（２６２０）に知らせる。従って、作動２７１４で、クライアントデバイスＡ２６１０は、ユーザＢのオンライン通信セッション終点識別子を含む招待更新要求を招待サービスに送信し、クライアントデバイスＢ１（２６１５）が招待を受諾したことを示している。招待更新要求は、ユーザＢのオンライン通信セッション終点識別子に関連付けられたどのクライアントデバイスが招待更新メッセージを受信すべきかを招待サービス６２０に教えるか又は示すことができる（この実施例では、クライアントデバイスＢ２（２６２０）は、招待更新メッセージを受信すべきである）。

招待サービス６２０は、ユーザＢのオンライン通信セッション終点識別子に基づいてディレクトリルックアップ２７１６を行って、クライアントデバイスＢ２（２６２０）のプッシュトークンを判断する。プッシュトークンを判断した後に、招待サービスは、作動２７１８で、クライアントデバイスＢ２（２６２０）に招待更新メッセージをプッシュするためにプッシュ通知サービス６４０に、プッシュ要求を送信する。作動２７２０で、プッシュ通知サービス６４０は、プッシュ通知メッセージの形態でオンライン通信セッション招待要求をクライアントデバイスＢ２（２６２０）に送信する。招待更新メッセージは、クライアントデバイスＢ１（２６１５）がオンライン通信セッション招待を受諾したことを示している。クライアントデバイスＢ２（２６２０）は、招待更新メッセージを表示することができ、かつクライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションの状態（例えば、オンライン通信セッションの持続時間など）を維持することができる。図３０を参照してより詳細に説明することになるように、一実施形態では、クライアントデバイスＢ２（２６２０）は、オンライン通信セッションをクライアントデバイスＢ１（２６１５）からクライアントデバイスＢ２（２６２０）に転送させる転送分要求を送信することができる。

作動２７１２において、招待受諾メッセージを受信した後、しばらくしてクライアントデバイスＡ２６１０及びクライアントデバイスＢ１（２６１５）は、作動２７２２で、やり取りされた接続データを使用して直接のＰ２Ｐ接続を確立する。直接のＰ２Ｐ接続は、公知の機構を通じて（例えば、インターネットコネクティビティエスタブリッシュメント（ＩＣＥ）又は他の公知のＰ２Ｐ接続性機構を使用して）確立することができる。作動２７２２を作動２７１４〜２７２０の前又はその作動中に行うことができることを理解すべきである。

図２６は単一のクライアントデバイスだけが招待メッセージを受諾する実施例を説明しているが、一部の状況では、複数のクライアントデバイスは、単一のユーザのためのオンライン通信セッションへの招待を受諾することができる。例えば、クライアントデバイスＢ１（２６１５）及びクライアントデバイスＢ２（２６２０）が、一部の状況において招待を受諾することができる。一実施形態では、クライアントデバイスＡ２６１０は、受諾メッセージの受信元である第１のクライアントデバイスとオンライン通信セッションを確立する。クライアントデバイスＡ２６１０は、キャンセルメッセージを他のクライアントデバイスへ送らせることができる（例えば、キャンセルメッセージは招待サービスに送信することができ、次に、このような他のクライアントデバイスにプッシュ通知サービスを通じてプッシュすることができる）。図２６の作動２６５４を再び参照すると、直接のＰ２Ｐ接続がクライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）の間に達成可能でなかった場合に、図２８に説明する作動が行われる。図２８は、直接的なＰ２Ｐ接続が達成不可能である時に行われる例示的な作動を示すデータ流れ図である。作動２８１０で、招待サービス６２０は、リレーサービス６５０にリレー検索要求２８１０を送信し、クライアントデバイスＡ２６１０及びクライアントデバイスＢ１（２６１５）により使用すべきリレーホストを判断する。リレー検索要求は、クライアントデバイスに適切なリレーホストを選択するためにリレーサービス６５０によって使用されるクライアントデバイスのネットワーク情報（例えば、ＮＡＴトラバーサル／接続データ及び／又はＮＡＴタイプデータ）を含むことができる。図８に示すように、リレーサービス６５０の一実施形態は、複数のリレーホスト８１５Ａ〜Ｂと、リレーホストの各々に関連付けられたネットワーク情報を含むリレーホストデータベース８１０とを含む。例えば、招待サービス６２０は、リレー検索要求をリレーサービス６５０に送信し、リレーサービス６５０は、クライアントデバイスのネットワーク情報を使用してリレーホストデータベース８１０に問い合わせる。データベース検索結果を受信すると、瞬時に、リレーサービス６５０は、作動１２０１で、選択されたリレーホスト８１５Ａを識別するリレー検索応答を供給する。一実施形態では、リレー検索応答は、リレーサービス６５０によって生成されるリレートークンと、リレー接続に向けてクライアントデバイスにより使用すべきリレーホスト８１５Ａのネットワークアドレス（ＩＰアドレス／ポート）とを含む。一実施形態では、リレートークンは、リレーセッションに関連しており、リレーサービス６５０に接続すると、クライアントデバイスＡ２６１０及びクライアントデバイスＢ１（２６１５）を認証するためにリレーホスト８１５Ａによって使用される。トークンは、例えば、独自のＩＤリレーセッションＩＤコード、デジタル証明書及び／又はリレーセッションに関連付けられた独自の暗号化キーを含む様々な形を取ることができる。

招待サービス６２０は、次に、作動２８１４で、リレー接続が行われるという表示を含むリレー応答をクライアントデバイスＢ１（２６１５）に送信する。一実施形態では、リレー応答は、リレートークンと、クライアントデバイスＢ１（２６１５に向けて選択されたリレーホストのネットワーク情報とを含むことができる。一実施形態では、リレー応答は、クライアントデバイスＢ１（２６１５）に直接に送ることができる（プッシュ通知サービス６４０をバイパスして）。招待サービス６２０は、作動２８１６で、リレートークンとクライアントデバイスＡ２６１０に向けて選択されたリレーホストのネットワーク情報とを含むリレー応答もクライアントデバイスＡ２６１０に送信する。一部の実施形態では、リレー応答は、プッシュ通知サービス６４０を通じてモバイルデバイスＡにプッシュされる。

作動２８１８で、クライアントデバイスＡ２６１０は、次に、ユーザＢのオンライン通信セッション終点識別子を含むと共にクライアントデバイスＢ１（２６１５）が招待を受諾したことを示す招待更新要求を招待サービス６２０に送信する。招待更新要求は、ユーザＢのオンライン通信セッション終点識別子に関連付けられたどのクライアントデバイスが招待更新メッセージを受信すべきかを招待サービス６２０に教えるか又は示すことができる（この実施例では、クライアントデバイスＢ２（２６２０）は、招待更新メッセージを受信すべきである）。

招待サービス６２０は、ユーザＢのオンライン通信セッション終点識別子に基づいてディレクトリルックアップ２８２０を行って、クライアントデバイスＢ２（２６２０）のプッシュトークンを判断する。プッシュトークンを判断した後に、招待サービスは、作動２８２２で、クライアントデバイスＢ２（２６２０）に招待更新メッセージをプッシュするプッシュ要求をプッシュ通知サービス６４０に送信する。作動２８２４で、プッシュ通知サービス６４０は、プッシュ通知メッセージの形態で、招待更新メッセージをクライアントデバイスＢ２（２６２０）に送信する。招待更新メッセージは、クライアントデバイスＢ１（２６１５）がオンライン通信セッション招待を受諾したことを示している。クライアントデバイスＢ２（２６２０）は、招待更新メッセージを表示することができ、かつクライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションの状態（例えば、オンライン通信セッションの持続時間など）を維持することができる。一実施形態では、クライアントデバイスＢ２（２６２０）は、オンライン通信セッションをクライアントデバイスＢ１（２６１５）からクライアントデバイスＢ２（２６２０）に転送させる転送分要求を送信することができる。

作動２８２６で、クライアントデバイスＡ２６１０は、選択されたリレーホストのネットワーク情報を使用し、リレーサービス６５０との接続を確立する。同様に、作動２８２８で、クライアントデバイスＢ１（２６２０）は、選択されたリレーホストのネットワーク情報を使用し、リレーサービス６５０との接続を確立する。これらの作動の各々において、新しいホールをクライアントデバイスのあらゆるＮＡＴファイアウォールに開けることができ、クライアントデバイスのＮＡＴトラバーサル／接続データは、リレーサービス６５０により判断してクライアントデバイスに戻すことができる（例えば、クライアントデバイスのパブリックＩＰ／ポートを判断することにより）。一実施形態では、リレーサービス６５０及びクライアントデバイスＡ２６１０は、トラバーサルユージングリレーＮＡＴ（ＴＵＲＮ）プロトコルを実行し、それによって当業者により理解されるように、ＮＡＴ又はファイアウォールの後の要素は、ＴＣＰ又はＵＤＰ接続で着信データを受信することができる。

作動２８３０で、クライアントデバイスＡ２６１０は、招待サービス６２０にリレー更新を送信し、リレー更新は、作動２８３２でプッシュ通知サービスに転送され、作動２８３４でクライアントデバイスＢ１（２６１５）にプッシュされる。同様に、作動２８３６で、クライアントデバイスＢ１（２６１５）は、招待サービス６２０にリレー更新を送信し、リレー更新は、作動２８３８でプッシュ通知サービス６４０に転送され、作動２８４０でクライアントデバイスＡ２６１０にプッシュされる。クライアントデバイスＡ２６１０によって送信されたリレー更新メッセージは、作動２８２６及び２８２８でリレーサービス６５０により判断されたセッショントークンと、各デバイスのオンライン通信セッション終点識別子と、ＮＡＴトラバーサル／接続データとを含むことができる。一実施形態では、クライアントデバイスのＮＡＴ情報の１つ又はそれよりも多くが変わった可能性があるのでリレー更新作動が行われる。最後に、作動２８４２及び２８４４で、クライアントデバイスＡ２６１０及びクライアントデバイスＢ１（２６２０）は、リレーサービス６５０を通じてそれぞれＰ２Ｐ接続を確立する。一実施形態では、リレー接続は、クライアントデバイスＡ２６１０がリレーサービス６５０にクライアントデバイスＢ１（２６１５）のＮＡＴトラバーサル／接続データを送信し、クライアントデバイスＢ１（２６１５）がリレーサービス６５０にクライアントデバイスＡ２６１０のＮＡＴトラバーサル／接続データを送信することに応答して確立することができ、従って、リレーサービス６５０は、各ピアのリレーホストへの正しい経路を判断することができる。

図２９は、一実施形態によるオンライン通信セッションが終了する時に行われる例示的な作動を示すデータ流れ図である。作動２９１０で、クライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションは終了している。例えば、クライアントデバイスＡ２６１０又はクライアントデバイスＢ１（２６１５）は、オンライン通信セッションを終了している（代替的に、オンライン通信セッションは、その他の方法で終了されている）。オンライン通信セッションは、直接のＰ２Ｐ接続を通じて又はリレーを通じたものであった可能性がある。

作動２９１２で、オンライン通信セッションが終了した後、しばらくしてクライアントデバイスＡ２６１０は、オンライン通信セッション更新要求を招待サービス６２０に送信する。オンライン通信セッション更新は、オンライン通信セッションの一部ではないクライアントデバイスＢ２（２６２０）にオンライン通信セッションの終了を通知するために送られる。オンライン通信セッション更新要求は、ユーザＢのオンライン通信セッション識別子を含むことができ、かつ招待サービス６２０に対して、ユーザＢに関連付けられたいずれのクライアントデバイス（例えば、クライアントデバイスＢ２（２６２０））が更新を受信することになっているかを教えるか又は示すことができる。

招待サービス６２０は、ユーザＢのオンライン通信セッション終点識別子に基づいてディレクトリルックアップ作動２９１４を行って、クライアントデバイスＢ２（２６２０）のプッシュトークンを判断する。プッシュトークンを判断した後に、招待サービスは、作動６４０で、クライアントデバイスＢ２（２６２０）に更新メッセージをプッシュするためにプッシュ通知サービス６４０にプッシュ要求を送信する。作動２７２０で、プッシュ通知サービス６４０は、プッシュ通知メッセージの形態でオンライン通信更新メッセージをクライアントデバイスＢ２（２６２０）に送信する。オンライン通信セッション更新メッセージは、クライアントデバイスＡ２９１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションは終了していることを示している。

図３０は、一実施形態による１つのクライアントデバイスから別のクライアントデバイスにオンライン通信セッションを転送するために行われる例示的な作動を示す流れ図である。図３０に示す例において、クライアントデバイスＢ１（２６１５）及びＢ２（２６２０）の各々がクライアントデバイスＡ２６１０により起こされるオンライン通信セッションへの招待を受信し（各々、招待に使用されたオンライン通信セッション終点識別子を共有する）、クライアントデバイスＢ１（２６１５）が受諾してクライアントデバイスＡ２６１０とのオンライン通信セッションを確立したと仮定している（図２６及び２７又は２８で上述したように）。更に、クライアントデバイスＢ２（２６２０）は、クライアントデバイスＢ１（２６１５）が招待を受諾したことを示す招待更新を受信している。図３０に示す実施例では、オンライン通信セッションは、クライアントデバイスＢ１（２６１５）からクライアントデバイスＢ２（２６２０）に転送されることになる。例えば、クライアントデバイスＢ２（２６２０）でのユーザは、クライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６２０）間のオンライン通信セッションを引き継ぎたいことを示している。一実施形態では、オンライン通信セッションアプリケーション２１１５は、クライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションの状態を表示し、この状態により、クライアントデバイスＢ２（２６２０）のユーザは、転送オンライン通信セッション要求を出すことができる（例えば、クライアントデバイスＢ１（２６１５）のオンライン通信セッションアプリケーション２１１５上で利用可能なリンク又は仮想ボタンをクリック又は押して）。

作動３０１０で、クライアントデバイスＢ２（２６２０）は、接続データを接続データ交換部６１０に要求し、作動３０１２で、要求の接続データを受信する（それが、接続データをまだ知らない場合）。クライアントデバイスＢ２（２６２０）は、次に、作動３０１４で、クライアントデバイスＡ２６１０のプッシュトークンとクライアントデバイスＢ２（２６２０）の接続データとを含む転送要求メッセージを招待サービス６２０に送信する。転送メッセージはまた、Ａ及び／又はＢのオンライン通信セッション終点識別子及び／又はクライアントデバイスＡ２６１０のプッシュトークンを含むことができる。

招待サービス６２０は、次に、作動３０１６で、プッシュ要求をプッシュ通知サービス６４０に送信し、プッシュ通知サービス６４０にクライアントデバイスＡ２６１０にプッシュ通知の形態で転送メッセージを送信させる。招待サービス６２０は、作動３０１８で、直接のＰ２Ｐ適合性検査を行って、クライアントデバイスＡ２６１０とクライアントデバイスＢ２（２６２０間の直接のＰ２Ｐ接続が達成可能であるか否かを判断する。この例の目的上、直接の接続は達成可能であるが、オンライン通信セッション転送はリレー状況においても行うことができることを理解すべきである。

作動３０２０で、プッシュ通知サービスは、転送分要求メッセージをクライアントデバイスＡ２６１０に送信する。転送分要求メッセージは、Ｂのオンライン通信セッション終点識別子とクライアントデバイスＢ２（２６２０）の接続データとを含むことができる。転送分要求メッセージはまた、オンライン通信セッション転送を要求しているのがどのデバイスであるか（すなわち、クライアントデバイスＢ２（２６２０）を示す（例えば、クライアントデバイスＢ２（２６２０）のデバイスＩＤ及び／又はプッシュトークンを通じて）。転送要求メッセージは、クライアントデバイスＡ２６１０のオンライン通信セッションアプリケーション２１１５に転送要求を表示させることができ、かつユーザが転送要求を受諾又は拒否することを可能にすることができる。転送要求が受諾されたと仮定し、クライアントデバイスＡ２６１０は、作動３０２２で、やり取りされた接続データを使用してクライアントデバイスＢ２６２０との直接のＰ２Ｐ接続を確立する。この時点で、クライアントデバイスＡ２６１０とクライアントデバイスＢ１（２６１５）間のオンライン通信セッションがアクティブであることを理解すべきである。クライアントデバイスＡ２６１０は、次に、オンライン通信セッションがクライアントデバイスＢ２（２６２０）に移行されることになることを示すオンライン通信セッション更新をクライアントデバイスＢ１（２６１５）に送信する。一実施形態では、この更新メッセージは、クライアントデバイス間の既存のオンライン通信セッション上で送信される。クライアントデバイスＡ２６１０は、次に、作動３０２６で、クライアントデバイスＢ２（２６２０）とのオンライン通信セッションに切り換わると、作動３０２８で、クライアントデバイスＢ１（２６１５）とのオンライン通信セッションを解消する。

実施形態をオンライン通信セッション（複数のクライアントデバイスに関連付けられる場合もあれば、関連付けられない場合もある）に単一のユーザを招待することを参照して説明しているが、一部の実施形態では、複数のユーザをオンライン通信セッションに招待することができる。図３１は、複数のユーザとのオンライン通信セッションを開始かつ確立する例示的な作動を示す流れ図である。

クライアントデバイス３１１０は、作動３１３２で接続データを接続データ交換部６１０に要求し、要求の接続データは、作動３１３４で戻される。作動３１３６で、クライアントデバイスＡ３１１０は、クライアントデバイスＡ３１１０の接続データと、ユーザＢに関連付けられたオンライン通信セッション終点識別子と、ユーザＣに関連付けられたオンライン通信セッション終点識別子とを含む招待要求を招待サービス６２０に送信する。従って、クライアントデバイスＡ３１１０のユーザは、複数のユーザをオンライン通信セッションに招待している。

招待サービス６２０は、ディレクトリルックアップ作動３１３８を行って、ユーザＢのオンライン通信セッション終点識別子及びユーザＣのオンライン通信セッション終点識別子に関連付けられたプッシュトークンを判断する。この例において、及び簡潔さの目的として、ディレクトリルックアップは、ユーザＢのオンライン通信セッション終点識別子に関連付けられるクライアントデバイスＢ３１１５及びユーザＣのオンライン通信セッション終点識別子に関連付けられるクライアントデバイスＣ３１２０の結果を戻す。招待サービス６２０は、プッシュ要求メッセージ３１４０をプッシュ通知サービス６４０に送信して。プッシュ通知サービス６４０がクライアントデバイスＢ及びＣにプッシュメッセージの形態で招待を送信することを要求する。プッシュ通知サービス６４０は、次に、作動３１４２で招待要求をクライアントデバイスＢ３１１５に送信し、作動３１４４で招待要求をクライアントデバイスＣ３１２０に送信する。各招待要求メッセージは、クライアントデバイスＡ３１１０の接続データと、ユーザＡによって使用されるオンライン通信セッション終点識別子と、クライアントデバイスＡ３１１０のプッシュトークンとを含む。

一実施形態では、招待サービス６２０は、招待がどのクライアントデバイスに送信されたかを示すステータスメッセージを招待側クライアントデバイスに送信する。従って、作動３１４６で、招待サービス６２０は、オンライン通信セッション招待要求がクライアントデバイスＢ３１１５及びクライアントデバイスＣ３１２０に送られたことを示す招待ステータス更新をクライアントデバイスＡ３１１０に送信する。一実施形態では、クライアントデバイスＢ３１１５及びクライアントデバイスＣ３１２０は、電源が投入されて招待要求を受信することができた場合は招待要求を表示する。

図３１に示す実施例では、招待の各々が受諾されることになる。従って、作動３１４８で、クライアントデバイスＢ３１１５は、接続データを接続データ交換部６１０に要求する。接続データ交換部６１０は、クライアントデバイスＢ３１１５の接続データを判断し、作動３１５０で、クライアントデバイスＢ３１１５に戻す。同様に、クライアントデバイスＢ３２１０は、作動２６４８で、接続データを接続データ交換部６１０に要求する。接続データ交換部６１０は、クライアントデバイスＣ３１２０の接続データを判断し、作動３１５４で、クライアントデバイスＢ３１２０に戻す。クライアントデバイスＢ３１１５は、次に、作動３１５６で、受諾メッセージを招待サービス６２０に送信し、クライアントデバイスＣ３１２０は、作動３１５８で、受諾メッセージを招待サービス６２０に送信する。招待サービス６２０は、次に、直接のＰ２Ｐ適合性検査３１６０を行って、直接のＰ２Ｐ接続がクライアントデバイスＡ３１１０とクライアントデバイスＢ３１１５間に、及びクライアントデバイスＡ３１１０とクライアントデバイスＣ３１２０間に達成可能であるか否かを判断する。この例の目的上、直接のＰ２Ｐ接続は、クライアントデバイス間に達成可能である。従って、やり取りされた接続データを使用し、クライアントデバイスＡ３１１０及びクライアントデバイスＢ３１１５は、作動３１６２で、オンライン通信セッションに向けて直接のＰ２Ｐ接続を確立し、クライアントデバイスＡ３１１０及びクライアントデバイスＢ３１２０は、作動３１６４で、オンライン通信セッションに向けて直接のＰ２Ｐ接続を確立する。この例において、クライアントデバイスＡ３１１０は、本質的にオンライン通信セッションのホストとして作用する。従って、クライアントデバイスＢ３１１５とクライアントデバイスＣ３１２０間に送信されるデータは、クライアントデバイスＡ３１１０によりリレーされる。他の実施形態では、接続のフルメッシュが、当事者間に確立される。このような実施形態では、別のＰ２Ｐ接続が、クライアントデバイスＢ３１１５とクライアントデバイスＣ３１２０の間に確立されることになると考えられる。

本明細書に説明する実施形態は、オンライン通信セッションに向けてクライアントデバイスを登録する機構を説明しているが、一部の実施形態では、登録１４０は、ＡＰＩを実行し、異なるアプリケーションがオンライン通信セッション終点識別子及びプッシュトークンを登録することを可能にすることができる。一実施形態内で実行されたＡＰＩは、異なるソフトウエア構成要素（以下「ＡＰＩ発呼ソフトウエア構成要素」）がＡＰＩ実施ソフトウエア構成要素によって供給された１つ又はそれよりも多くの機能、方法、手順、データ構造、及び／又は他のサービスにアクセスして利用することを可能にするソフトウエア構成要素（以下「ＡＰＩ実施ソフトウエア構成要素」）によって実行されるインタフェースである。例えば、ＡＰＩにより、ＡＰＩ発呼ソフトウエア構成要素の開発者（第三者開発者とすることができる）がＡＰＩ実施ソフトウエア構成要素によって供給された指定の特徴を利用することができる。１つのＡＰＩ発呼ソフトウエア構成要素がある場合があり、又は１つよりも多いこのようなソフトウエア構成要素がある場合がある。ＡＰＩは、ソフトウエアアプリケーションへのサービスの要求をサポートするためにコンピュータシステム又はプログラムライブラリが供給するソースコードインタフェースとすることができる。ＡＰＩは、どのようにしてデータがメモリ内に説明されたかという明示的な低レベル説明ではなく、アプリケーションが構成された時に解説的であるか又はコンパイルすることができるプログラミング言語に関して指定することができる。

ＡＰＩは、ＡＰＩ実施ソフトウエア構成要素の指定の特徴にアクセスして使用する時に、ＡＰＩ発呼ソフトウエア構成要素を使用する言語及びパラメータを定義する。例えば、ＡＰＩ発呼ソフトウエア構成要素は、ＡＰＩにより顕在化される１つ又はそれよりも多くのＡＰＩ発呼（機能又は方法通話であることもある）を通じてＡＰＩ実施ソフトウエア構成要素の指定の特徴にアクセスする。ＡＰＩ実施ソフトウエア構成要素は、ＡＰＩ発呼ソフトウエア構成要素からのＡＰＩ発呼に応答してＡＰＩを通じて値を戻すことができる。ＡＰＩはＡＰＩ発呼の構文及び結果を定義するが（例えば、ＡＰＩ発呼を起動する方法及びＡＰＩ発呼が行うこと）、ＡＰＩは、一般的に、ＡＰＩ発呼がＡＰＩ発呼により指定される機能をもたらす方法を示さない。様々な機能通話又はメッセージは、通話ソフトウエア（ＡＰＩ発呼ソフトウエア構成要素）とＡＰＩ実施ソフトウエア構成要素の間の１つ又はそれよりも多くのアプリケーションプログラミングインタフェースを通じて転送される。機能通話又はメッセージの転送は、機能通話又はメッセージの発信、開始、起動、通話、受信、返答、又は応答を含むことができる。従って、ＡＰＩ発呼ソフトウエア構成要素は通話を転送することができ、かつＡＰＩ実施ソフトウエア構成要素は、通話を転送することができる。

一例として、ＡＰＩ実施ソフトウエア構成要素及びＡＰＩ発呼ソフトウエア構成要素は、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウエアモジュールとすることができる（ＡＰＩ実施ソフトウエア構成要素及びＡＰＩ発呼ソフトウエア構成要素は、同じか又は互いと異なるタイプのソフトウエアモジュールとすることができることを理解されたい）。ＡＰＩ発呼ソフトウエア構成要素は、ネットワークでＡＰＩを通じてＡＰＩ実施ソフトウエア構成要素と通信するローカルソフトウエア構成要素（すなわち、ＡＰＩ実施ソフトウエア構成要素と同じデータ処理システム上の）、又はリモートソフトウエア構成要素（すなわち、ＡＰＩ実施ソフトウエア構成要素として異なるデータ処理システム上の）とすることができる。ＡＰＩ実施ソフトウエア構成要素は、ＡＰＩ発呼ソフトウエア構成要素として作用することができ（すなわち、異なるＡＰＩ実施ソフトウエア構成要素により顕在化されたＡＰＩにＡＰＩ発呼を行うことができ）、ＡＰＩ発呼ソフトウエア構成要素は、異なるＡＰＩ発呼ソフトウエア構成要素に顕在化されたＡＰＩを実施することによってソフトウエア構成要素を実施するＡＰＩとして作用することができることを理解すべきである。

ＡＰＩは、異なるプログラミング言語で書き込まれた複数のＡＰＩ発呼ソフトウエア構成要素がＡＰＩ実施ソフトウエア構成要素と通信することを可能にすることができる（従って、ＡＰＩは、ＡＰＩ実施ソフトウエア構成要素とＡＰＩ発呼ソフトウエア構成要素間の発呼及び返答を中継する特徴を含むことができる）が、ＡＰＩは、特定のプログラミング言語に関して実施することができる。

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

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

ＡＰＩ実施ソフトウエア構成要素９１０、ＡＰＩ９２０、及びＡＰＩ発呼ソフトウエア構成要素９３０は、機械（例えば、コンピュータ又は他のデータ処理システム）により可読形式で情報を記憶するあらゆる機構を含む機械可読媒体に記憶することができる。例えば、機械可読媒体には、磁気ディスク、光ディスク、ランダムアクセスメモリ、読取専用メモリ、フラッシュメモリデバイスなどがある。

回線交換式通話と映像通話の間の遷移
一部の実施形態では、クライアントデバイスは、当事者の間の通信を有意に中断することなく、確立された音声専用回線交換通話から映像通話に遷移することができる。例えば、確立されたた音声専用回線交換通話の１つの当事者は、映像通話（映像フレーム及び音声を含む）に遷移することに選択し、それによって映像通話開始メッセージ（オンライン通信セッション招待メッセージの１つの形）が通話の他の参加者に送られる。他の参加者が映像通話招待を受諾した場合に、Ｐ２Ｐ接続が、参加者のクライアントデバイス間に確立される。Ｐ２Ｐ接続が交渉される間、参加者は、音声専用回線交換通話を通じて通信することができる。Ｐ２Ｐ接続が確立されて映像が当事者の間に通信された後に、クライアントデバイスは、映像通話に遷移する。音声専用回線交換通話が次に中断されると、参加者は、映像通話を通じて通信することができる。

図１２は、一部の実施形態により回線交換通話と映像通話間で遷移するのに使用される例示的なクライアントデバイス１２１０及びグラフィカルユーザインタフェースを示している。クライアントデバイス１２１０は、スピーカ１２５５（スピーカフォンモードで使用）と、前向きカメラ１２６０（映像通話に使用された映像を捕捉）と、マイク１２６５（音を捕捉）と、受信機／スピーカ１２７０（一般的にユーザが通話中に耳にクライアントデバイス１２１０を保持する時に使用）と、表示画面１２７５（一部の実施形態ではタッチスクリーン）とを含む。クライアントデバイス１２１０は、ヘッドホン／ヘッドホンジャックと、近接センサと、周囲光センサと、加速度計と、他の構成要素とを含むことができる。クライアントデバイス１２１０のアーキテクチャは例示的であり、より多くの又はより少ない構成要素を含む異なるアーキテクチャを実施形態に使用することができることを理解すべきである。

図１２に示すように、グラフィカルユーザインタフェース１２０５が、現在表示画面１２７５上に表示されている。クライアントデバイス１２１０のユーザは、現在、音声専用電話（電話番号（４０８）５５５−１２３４で）で参加している。グラフィカルユーザインタフェース１２０５は、通話中のユーザのいくつかの異なる選択肢を含む。例えば、クライアントデバイス１２１０は、ユーザ入力（例えば、適切なアイコン上のタッピング又は他の予め定義された動作）を受信することに応答して以下を行い、すなわち、入力が終了通話アイコン１２５０に適用された時に通話を終了し、入力がミュートアイコン１２２０に適用されることに応答して音声通話の音を消し、入力がキーパッドアイコン１２２５に適用されることに応答し、数値キーパッドを表示し（例えば、通話に付加的な電話番号を追加するために）、入力がスピーカアイコン１２３０に適用されることに応答して通話をスピーカフォンに設け（音声出力をスピーカ１２５５に変更する）、入力が追加通話アイコン１２３５に適用されることに応答し、通話を追加し、入力がホールドアイコン１２４０に適用されることに応答して通話をホールドし、入力が連絡先アイコン１２４５に適用されることに応答してユーザ連絡先リストを表示し、かつ入力が映像通話アイコン１２１５に適用されることに応答して映像通話に遷移する。

図１７及び図１８は、一実施形態による映像通話と音声専用回線交換通話間で遷移する例示的な作動を示す流れ図である。図１７及び図１８を図１２、図１３、及び図１４の例示的な実施形態を参照して説明する。しかし、図１７〜図１８の作動は、図１２、図１３、及び図１４を参照して説明したもの以外の本発明の実施形態により行うことができ、図１２、図１３、及び図１４を参照して説明した実施形態は、図１７〜図１８を参照して説明したものと異なる作動を行うことができることを理解すべきである。

図１７に示すように、クライアントデバイス１２１０及び１４１０は、音声専用回線交換通話１７１０を通じて接続される（クライアントデバイス１２１０のユーザ又はクライアントデバイス１４１０のユーザは、通話を開始している）。従って、クライアントデバイス１２１０及び１４１０のユーザは、確立された回線交換音声通話で通信することができる。ブロック１７１２で、クライアントデバイス１２１０は映像通話に遷移する入力を受信する。例えば、ユーザは、タッピングを又は映像通話アイコン１２１５上で別の定義された動作を行うことによって映像通話に遷移することを選択している。

フローは、次に、ブロック１７１４に移動し、クライアントデバイス１２１０は、映像通話招待メッセージ（それは、オンライン通信セッション招待要求メッセージの形態である）をクライアントデバイス１４１０に送らせる（クライアントデバイス１４１０の電話番号により識別されたように）。一部の実施形態では、オンライン通信セッション招待要求メッセージは、図６及び図７に説明したアーキテクチャで送られる。フローは、次に、ブロック１７１６に移動する。

ブロック１７１６で、クライアントデバイス１２１０は、音声が現在スピーカフォン（例えば、スピーカ１２５５）を通じて、又はヘッドホン／ヘッドホンジャックを通じて経路指定されたか否かを判断する。経路指定された場合に、フローは、ブロック１７２０に移動する。経路指定されていない場合に、フローはブロック１７１８に移動し、クライアントデバイス１２１０は、クライアントデバイス１２１０（例えば、スピーカ１２５５）のスピーカフォンを通じて音声を経路指定し、フローは、ブロック１７２０に移動する。

ブロック１７２０で、クライアントデバイス１２１０は、前向きカメラ１２６０が現在捕捉しているものの映像プレビューを表示し、クライアントデバイス１２１０のユーザが映像通話を準備をすること（例えば、映像通話に向けてクライアントデバイス１２１０を適切に位置決めすること）を可能にする。図１３は、前向きカメラ１２６０が現在捕捉しているものの映像を表示する映像プレビュー１３１０を示すクライアントデバイス１２１０を示している。図１３には図示していないが、一部の実施形態では、ユーザが映像通話招待を取り消すことを可能にするキャンセルボタンも、ＧＵＩ１３０５上に表示されている。フローは、ブロック１７２０からブロック１７２２に移動する。

ブロック１７２６で、クライアントデバイス１４１０は、クライアントデバイス１４１０のユーザを映像通話に招待する映像通話招待メッセージを受信する。フローは、ブロック１７２６からブロック１７２８に移動する。一部の実施形態では、クライアントデバイス１４１０は、クライアントデバイス１２１０と類似のアーキテクチャを有する。例えば、図１４に示すように、クライアントデバイス１４１０は、スピーカ１４５５（スピーカフォンモードで使用）と、前向きカメラ１４６０（映像通話に使用された映像を捕捉）と、マイク１４６５（音を捕捉）と、受信機／スピーカ１４７０（一般的にユーザが通話中に耳にクライアントデバイス１４１０を保持する時に使用）と、表示画面１４７５（一部の実施形態ではタッチスクリーン）とを含む。クライアントデバイス１４１０は、ヘッドホン／ヘッドホンジャックと、近接センサと、周囲光センサと、加速度計と、他の構成要素とを含むことができる。クライアントデバイス１４１０のアーキテクチャは例示的であり、より多くの又はより少ない構成要素を含む異なるアーキテクチャを実施形態に使用することができることを理解すべきである。

ブロック１７２８で、クライアントデバイス１４１０は、メッセージの受信を示す１つ又はそれよりも多くの音声トーンを再生し、ユーザにメッセージに対して注意を喚起する。音声トーンは、異なる実施形態において異なることができる（例えば、音声トーンは、クライアントデバイス１４１０上に使用された通話待機音と類似とすることができ（それらは、クライアントデバイス１４１０に関連付けられたキャリアから出ていないが）、音声トーンは、独自のものでありかつ映像通話特定などとすることができる）。一部の実施形態では、クライアントデバイス１４１０は、クライアントデバイス１４１０がユーザの耳の近くではない場合に、及び／又は通話が現在スピーカフォンモードではない場合に、映像通話招待メッセージの受信を示す音声トーンを再生しない（例えば、クライアントデバイス１４１０の近接センサによって示すように）。フローは、ブロック１７２８からブロック１７３０に移動する。

ブロック１７３０で、クライアントデバイス１４１０は、映像通話招待メッセージを表示し、前向きカメラ１４６０が現在捕捉しているものの映像プレビューを任意的に表示し、クライアントデバイス１４１０のユーザが映像通話の準備をすることを可能にし、フローは、ブロック１７３２に移動する。図１４は、映像通話招待１４４０を表示するＧＵＩ１４０５を示している。図１４に示すように、映像通話招待１４４０は、受諾ボタン１４３２と、拒否ボタン１４３４と、映像プレビュー１４３０（前向きカメラ１４６０が現在捕捉しているものを示す）とを含む。図１４１０は、映像プレビュー１４３０（映像プレビュー１４３０が映像通話招待１４４０内に含まれている）を含む映像通話招待１４４０を示すが、他の実施形態では、映像プレビュー１４３０は、映像通話招待１４４０の外側に位置し及び／又は映像通話招待１４４０に重なっている。クライアントデバイス１４１０のユーザは、受諾ボタン１４３２を選択し、映像通話招待を受諾することができ（例えば、タッピング又は受諾ボタン１４３２上での入力に向けて別の予め定義された動作を行うことにより）、拒否ボタン１４３４を選択して映像通話招待を拒否することができる（例えば、タッピング又は拒否ボタン１４３４上での入力に向けて別の予め定義された動作を行うことにより）。

ブロック１７３２で、クライアントデバイス１４１０は、映像通話を受諾するために入力を受信したか否か（例えば、ユーザが受諾ボタン１４３２を選択することによって映像通話招待を受諾したか否か）を判断する。クライアントデバイス１４１０が映像通話を受諾する入力を受信した場合に、フローは、ブロック１７３４に移動し、そうでなければ、フローは、ブロック１７３６に移動する。ブロック１７３４で、クライアントデバイス１４１０は、映像通話受諾メッセージをクライアントデバイス１２１０に送信させる。一部の実施形態では、受諾メッセージは、図６及び図７に説明したアーキテクチャでクライアントデバイス１２１０に送信される。フローは、次に、ブロック１８１０に移動する。

ブロック１７３６で、映像通話要求を拒否するために入力を受信したか否かを判断する（例えば、拒否ボタン１４３４を選択することによってユーザが映像通話招待を拒否したか否か）。クライアントデバイス１４１０が映像通話を拒否する入力を受信した場合に、フローは、ブロック１７３８に移動し、そうでなければ、フローは、ブロック１７３２に移動する。ブロック１７３８で、クライアントデバイス１４１０は、映像通話拒否メッセージをクライアントデバイス１２１０に送信させる。クライアントデバイス１４１０は、映像通話招待１４４０を消去して映像プレビュー１４３０を表示することを停止することができる。一部の実施形態では、映像通話拒否メッセージは、図６及び図７に説明したアーキテクチャでクライアントデバイス１２１０に送信される。

ブロック１７２２で、クライアントデバイス１２１０は、クライアントデバイス１４１０から映像通話受諾メッセージを受信したか否かを判断する。受信していた場合に、フローは、ブロック１８１６に移動し、受信していなかった場合に、フローは、ブロック１７２４に移動し、クライアントデバイス１２１０は、クライアントデバイス１４１０から映像通話拒否メッセージを受信したか否かを判断する。受信していた場合に、フローは、ブロック１９１０に移動し、受信していなかった場合に、フローは、ブロック１７２２に移動する。

図１８を参照すると、ブロック１８１０で（クライアントデバイス１４１０のユーザは、映像通話招待を受諾した）、クライアントデバイス１４１０は、音声が現在スピーカフォン（例えば、スピーカ１４７０）又はクライアントデバイス１４１０のヘッドホンを通じて経路指定されたか否かを判断する。経路指定されていない場合に、フローはブロック１８１２に移動し、音声ルートは、スピーカ１４５５からスピーカフォン（例えば、スピーカ１４７０）に変更され、フローは、ブロック１８１４に移動する。音声がスピーカフォン又はヘッドホンを通じて経路指定された場合に、フローは、ブロック１８１４に移動する。

ブロック１８１４で、クライアントデバイス１４１０は、前向きカメラ１２６０が現在を捕捉しているものビデオプレビューを表示する。ブロック１８１４の作動は、映像プレビューがブロック１７３０で作動の結果として現在表示されていない場合に限り、行われる。フローは、ブロック１８１４からブロック１８２０に移動する。

ブロック１８１８及び１８２０で、クライアントデバイス１２１０及び１４１０は、互いとのＰ２Ｐ接続を確立する。直接のＰ２Ｐ接続は、公知の機構を通じて（例えば、インターネットコネクティビティエスタブリッシュメント（ＩＣＥ）又は他の公知のＰ２Ｐ接続性機構を使用して）確立することができる。Ｐ２Ｐ接続の確立が成功したと仮定し、フローは、それぞれ、ブロック１８１８及び１８２０からブロック１８２２及び１８２４に移動し、クライアントデバイス１２１０及び１４１０は、Ｐ２Ｐ接続で互いに映像（フロントビデオカメラ１２６０及び１４６０からの映像）を送信し始める。一部の実施形態では、映像は、映像フレームと対応する音声（それぞれクライアントデバイス１２１０及び１４１０のマイク１２６５及び１４６５により捕捉）とを含み、一方、他の実施形態では、映像及び音声は、Ｐ２Ｐ接続にわたって通信される別々のストリームである。

フローは、それぞれ、ブロック１８２２及び１８２４からブロック１８２６及び１８２８に移動する。ブロック１８２６及び１８２８で、クライアントデバイス１２１０及び１４１０は、それぞれ、ピアから１つ又はそれよりも多くの映像フレームを受信したか否かを判断する。受信していた場合に、フローは、それぞれブロック１８２６及び１８２８からブロック１８３０及び１８３２に移動する。受信していなかった場合に、フローは、１つ又はそれよりも多くの映像フレームが受信されるまで、ブロック１８２６及び１８２８のままである。

一部の実施形態では、クライアントデバイス１２１０及び１４１０は、何らかの時間にわたって互いから映像フレームを受信するのを待ち、その時間に映像フレームをやり取りしなかった場合に、代替アクションが講じられる。例えば、一部の実施形態では、映像通話が取り消され、映像通話を確立することができなかったというメッセージが、クライアントデバイス１２１０及び１４１０の画面上に表示されている。映像通話は、帯域幅が映像通話に不十分である、映像フレームを送信又は受信に失敗したなどを含むいくつかの理由で確立し損なう場合がある。一部の実施形態では、クライアントデバイスが先に進む前に映像の単一のフレームを待つが、他の実施形態では、クライアントデバイスは、先に進む前に特定の期間（例えば、映像フレームのフロー）にわたっていくつかのフレームを受信するのを待つ。

ブロック１８３０及び１８３２で、クライアントデバイス１２１０及び１４１０は、それぞれ、映像通話に遷移する。映像通話への遷移は、受信された映像を表示して回線交換音声通話から映像通話に音声ルートを変更することを含む。一部の実施形態では、映像プレビュー（例えば、映像プレビュー１３１０）が、画面のコーナに移動し（かつ縮小し）、ピアから受信された映像が示されている。従って、音声ルートが回線交換音声通話から映像通話に変更されるまで、参加者は、回線交換音声通話を通じて通信することができる（映像通話が交渉された間、回線交換音声通話は確立されたままである）ことを理解すべきである。映像通話に遷移した後に、回線交換音声通話を中断することができる。従って、フローは、それぞれ、ブロック１８３０及び１８３２からブロック１８３４及び１８３６に移動し、回線交換音声通話が中断される。

図１５及び図１６は、それぞれ、映像通話に遷移した後のクライアントデバイス１２１０及び１４１０を示している。図１５に示すように、クライアントデバイス１２１０は、クライアントデバイス１４１０の前向きカメラ１４６０により捕捉されたもの映像である映像１５１０を表示する。クライアントデバイス１２１０は、前向きカメラ１２６０により捕捉されたもの映像である映像１５１５も表示する。ＧＵＩ１５０５は、映像終了ボタン１５２０と映像通話終了ボタンとも含む。映像終了ボタン１５２０により、ユーザは映像通話を終了して音声通話だけに戻ることができる。映像終了及び通話ボタン１５２５により、ユーザは、完全に映像通話を終了する（例えば、クライアントデバイス１４１０のユーザとの会話を終了する）ことができる。図１６に示すように、クライアントデバイス１４１０は、クライアントデバイス１２１０の前向きカメラ１２６０により捕捉されたもの映像である映像１６１０を表示する。クライアントデバイス１４１０は、前向きカメラ１４６０により捕捉されたもの映像である映像１６１５を表示する。ＧＵＩ１６０５はまた、映像終了ボタン１６２０と映像通話終了ボタンとを含む。

図１９は、一実施形態による映像通話拒否メッセージを受信したクライアントデバイス上で行われる例示的な作動を示す流れ図である。ブロック１９１０で、クライアントデバイス１２１０は、映像通話拒否メッセージを受信する（クライアントデバイス１４１０のユーザは、映像通話招待を拒否したのである）。フローは、ブロック１９１０からブロック１９１２に移動し、クライアントデバイス１２１０は、映像通話拒否されたメッセージを表示し、かつ映像通話拒否メッセージの受信を示す１つ又はそれよりも多くの音声トーンを任意的に再生する。フローは、次に、ブロック１９１４に移動し、クライアントデバイス１２１０は、独自の映像プレビューを表示することを停止する。クライアントデバイス１２１０は、ブロック１７１８で音声出力が以前にスピーカフォンに変更されていた場合に、ユーザに初期の音声出力に戻るように促すことができる（例えば、スピーカ１２７０を通じて）。

図２０は、一実施形態による映像通話から回線交換通話へ遷移するクライアントデバイス上で行われる例示的な作動を示す流れ図である。映像通話２０１０は、クライアントデバイス１２１０及び１４１０の間に確立される（映像通話は、図１７及び図１８を参照して説明した機構により確立することができ、又は回線交換音声通話から遷移せずに確立することができる）。ブロック１７１２で、クライアントデバイス１２１０は、音声専用回線交換通話に遷移する入力を受信する。例えば、図１５を参照すると、クライアントデバイス１２１０のユーザは、映像終了ボタン１５２０を選択している（例えば、タッピング又は映像終了ボタン１５２０で別の予め定義された動作を行うことにより）。クライアントデバイス１２１０は、次に、音声専用回線交換通話２０１４への遷移を示すメッセージをクライアントデバイス１４１０に送信する。

クライアントデバイス１２１０は、次に、クライアントデバイス１４１０に回線交換音声通話要求を開始する（例えば、クライアントデバイス１２１０は、クライアントデバイス１４１０の番号に自動的に通話する）。一部の実施形態では、これは、背景で行われるので、ユーザとの対話処理は不要である。通話は、キャリアネットワークインフラストラクチャーのいくつかのネットワーク要素（例えば、基地局、モバイル交換局など）を通じて経路指定される。

クライアントデバイス１４１０は、回線交換通話２０２０受信して応える。一実施形態では、クライアントデバイス１４１０は着信要求を表示し、着信要求を示す音声トーン（例えば、通話待機音又は他のトーン）を再生することができ、かつ通話に出るためにユーザ介入が必要である。別の実施形態では、クライアントデバイス１４１０は、ユーザの介入がなくても自動的に通話に出る（かつ着信要求を示す音声トーンを再生する場合もあれば、再生しない場合もある）。通話に出た後に、音声専用回線交換通話が、クライアントデバイス１２１０及び１４１０間に確立される（２０３０）。

音声専用回線交換通話の確立が成功した後に、クライアントデバイス１２１０及び１４１０は、それぞれ音声専用通話２０３２及び２０３４に遷移する。例えば、音声専用通話への遷移は、映像通話から回線交換通話に音声ルートを変更して受信中の映像を表示することを停止して映像を送信することを停止することを含む。クライアントデバイスは、映像プレビューを表示することを停止することができる。従って、回線交換音声専用通話が交渉中である間、クライアントデバイス１２１０及び１４１０のユーザは、映像通話を通じて通信することができる（音声専用回線交換通話が交渉中である間、映像通話は、確立されたままである）ことを理解すべきである。音声専用回線交換通話に問題なく遷移した後に、クライアントデバイス１２１０及び１４１０は、Ｐ２Ｐ接続２０４０を終了する。クライアントデバイス１２１０及び１４１０のユーザは、次に、音声専用回線交換通話を通じて通信することができる。

本発明の実施形態を２人の参加者を有する映像通話に関して説明したが、実施形態は、映像通話においてより多くの参加者がいる場合があるのでそのように限定されない。このような実施形態では、クライアントデバイスは、映像チャットの各々の異なる参加者から複数の映像ストリームを表示することができる。

本発明の実施形態を２人の参加者を有する映像通話に関して説明したが、各参加者が映像を送信する場合に、実施形態は、そのように限定されない。例えば、一部の実施形態では、単一の当事者のみが他の参加者に映像を送信している場合があり、それらの他の参加者はオーディオを送信しているのみである場合がある。一部の実施形態では、各参加者は、映像通話中にあらゆる時点で映像を送信することを中止すべきか否かを判断することができる。

一部の実施形態では、通話中に送信される映像の品質は、ネットワーク条件に基づいて動的に調節される。例えば、ネットワークが混雑している期間中、映像のビットレートを遅くすることができる。同様に、ネットワークが比較的混雑のない期間中は、映像のビットレートを速めることができる。一部の実施形態では、ネットワーク条件により映像を送信することができない場合に、参加者クライアントデバイスは、音声専用回線交換通話に自動的に遷移する。従って、帯域幅が特定のレベルより下回った場合に、参加者クライアントデバイスは、音声専用回線交換通話に自動的に遷移することができる（又は音声専用回線交換通話に遷移するようにユーザに促すことができる）。

ＩＰ映像通話のためのハンズフリーデバイスを通じたハンズフリーサービスサポート
一実施形態では、クライアントデバイスはハンズフリーユニットとのＩＰ映像通話を管理するサポートを含むＷＰＡＮ（無線パーソナルエリアネットワーク）（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ジクビー（ＺｉｇＢｅｅ）など）上のハンズフリーデバイス（例えば、ヘッドホン、カートキット）との対話をサポートする機能性を含む。図３２は、一実施形態によるハンズフリーユニットとインタフェースで接続してＩＰ映像通話を管理クライアントコンピュータデバイスを示すブロック図である。クライアントデバイス３２１０は、映像通話を開始する（例えば、映像通話であるオンライン通信セッションに１人又はそれよりも多くの受信者を招待する）機能と映像通話を受諾する機能とを含む。一部の実施形態では、クライアントデバイス３２１０は、携帯電話通話を行って、セルラー接続を通じて携帯電話通信を受信し、及び／又は「インターネット」又は他のネットワークにアクセスする携帯電話通信構成要素も含む。

図３２に示すように、クライアントデバイス３２１０は、ＩＰ映像通話マネージャ３２５０と、電話通信マネージャ３２６０と、音声マネージャ３２７５及びハンズフリーマネージャ３２７０とを含む。一部の実施形態では、クライアントデバイス３２１０は、セルラー通話マネージャ３２５５も含む。ＩＰ映像通話マネージャ３２５０は、本明細書で上述したように、ＩＰ映像通話サービス３２３０を通じてＩＰネットワーク３２３５上で「ＩＰ Ｐ２Ｐ」映像通話を確立することを含むＰ２Ｐ映像通話アプリケーションを管理する。一実施形態では、ＩＰ映像通話サービス３２３０は、招待サービス６２０、プッシュ通知サービス６４０、登録サービス６３０や登録サービス２１３０、及びリレーサービス６５０のうちの１つ又はそれよりも多くを含む。携帯電話通話マネージャ３２５５は、携帯電話音声通話サービス３２４０を使用して携帯電話ネットワーク３２４５上で音声専用携帯電話通話を行ないかつ受信する携帯電話構成要素を管理する。

ＩＰ映像通話マネージャ３２５０及び携帯電話通話マネージャ３２５５は、電話通信マネージャ３２６０と結合される。電話通信マネージャ３２６０は、通話に関連付けられた通話履歴（映像通話及び音声専用携帯電話通話に向けて）及び他の情報を追跡することを含むＩＰ映像通話マネージャ３２５０及び携帯電話通話マネージャ３２５５の両方の電話通信作動を管理する。電話通信マネージャ３２６０は、ハンズフリーマネージャ３２７０とインタフェースで接続し、ＩＰ映像通話マネージャ３２５０及び携帯電話通話マネージャ３２５５のためにＩＰ映像通話及び携帯電話通話のための外部ハンズフリーデバイスを通じてハンズフリーサービスも提供する。一実施形態では、共通のメッセージタイプが、異なるプロトコル及び通話タイプ（ＩＰ映像通話及び音声専用携帯電話通話）に向けてハンズフリーサービスのサポートを行うためにＩＰ映像通話マネージャ３２５０、携帯電話通話マネージャ３２５５、及び電話通信マネージャ３２６０の間に使用される。従って、電話通信マネージャ３２６０は、ハンズフリーサービスがＩＰ映像通話又は音声専用携帯電話通話を対象とするのか否かに関わらず、ハンズフリーサービスに対して類似のサポートを提供する。それによってハンズフリーデバイスにより理解することができる標準的な指令をＩＰ映像通話に向けて、並びに音声専用携帯電話通話に向けてハンズフリーサービスを提供するのに使用することができるように、ハンズフリーマネージャ３２７０は、ハンズフリーサービスがＩＰ映像通話又は音声専用携帯電話通話を対象とするのか否かを理解せずに済む。

一実施形態では、電話通信マネージャ３２６０は、ＩＰ映像通話マネージャ３２５０と携帯電話通話マネージャ３２５５の間で仲裁もする。例えば、電話通信マネージャ３２６０は、ＩＰ映像通話をホールドさせて確立した音声専用携帯電話通話に切り換えることができ、及び／又は音声専用携帯電話通話をホールドさせてＩＰ映像通話に切り換えることができる。

ハンズフリーマネージャ３２７０は、ハンズフリー処理のサポートを提供する。一実施形態では、ハンズフリーマネージャ３２７０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ヘッドホン及びＢｌｕｅｔｏｏｔｈ（登録商標）カートキットのようなＢｌｕｅｔｏｏｔｈ（登録商標）準拠ハンズフリーデバイスへの接続に向けてＢｌｕｅｔｏｏｔｈ（登録商標）プロトコルスタックを実施する。１つの特定的な実施形態では、ハンズフリーマネージャ３２７０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ヘッドセットプロフィール（例えば、２００８年１２月１８日付けのヘッドホンプロフィール（ＨＳＰ）１．２仕様書に定義）及び／又はＢｌｕｅｔｏｏｔｈ（登録商標）ハンズフリープロフィール（例えば、２００５年１１月２５日付けのハンズフリープロフィール１．５（ＨＦＰ１．５）仕様書に定義）を実施する。ハンズフリーマネージャ３２７０は、ハンズフリーユニット３２２０がＩＰ映像通話に向けて及びＷＰＡＮ３２２５上の音声専用携帯電話通話に向けて音声リレーとして作用し、並びに他のハンズフリー検査を行うことを可能にする。例えば、ＩＰ映像通話の場合に、通話の音声部分は、クライアントデバイス３２１０のスピーカの代わりに、ハンズフリーユニット３２２０を通じて経路指定することができ、一方、通話の映像部分は、クライアントデバイス３２１０（代替的に、付属のディスプレイにより）により表示中のままである。ハンズフリーユニット３２２０は、クライアントコンピュータデバイス３２１０にその後送信される音声情報を捕捉するマイクも含む。従って、ユーザは、ハンズフリーユニット３２２０を使用して話したり、又はＩＰ映像通話中に及び／又は音声専用携帯電話通話中に音声を聴くことができる。

ハンズフリーマネージャ３２７０は、ＩＰ映像通話及び／又は音声専用携帯電話通話に向けて以下のもの、すなわち、ユーザが通話に応答することを可能にする、通話を終了する、通話をホールドにする、通話の音を消す、通話のボリュームを上げ／下げる、音声をクライアントデバイスに転送する、音声をハンズフリーユニットに転送する、通話を掛ける、及び最終の通話をリダイヤルすることのうちの１つ又はそれよりも多くを行うことを含めハンズフリーユニット３２２０からの入力を受信することに応答し、他のハンズフリーサービスもサポートする。従って、ユーザは、ハンズフリーユニット３２２０を使用し、ＩＰに映像通話に応答し、ＩＰ映像通話を終了し、ＩＰ映像通話をホールド及び／又はミュートにし、ＩＰ映像通話のボリュームを上げ／下げ、出力すべきＩＰ映像通話の音声をクライアントデバイス３２１０のスピーカに転送し、クライアントデバイス３２１０からハンズフリーユニット３２２０に音声を転送し、ＩＰ映像通話を掛け、及び最終ＩＰ映像通話をリダイヤルすることができる。

ＩＰ映像通話マネージャ３２５０、携帯電話通話マネージャ３２５５、及びハンズフリーマネージャ３２７０は、音声マネージャ３２７５とも結合される。音声マネージャ３２７５は、異なるソースを通じてＩＰ映像通話及び音声専用携帯電話通話の音声を経路指定する。例えば、音声マネージャ３２７５は、スピーカフォンモードに適するクライアントデバイス３２１０のスピーカを通じて、ユーザが通話中に耳にクライアントデバイス３２１０を保持した時に使用されるクライアントデバイス３２１０のスピーカを通じて、クライアントデバイス３２１０にプラグで入力されているヘッドホン又はヘッドホンのヘッドホン／ヘッドフォンジャックを通じて、かつピア接続されたハンズフリーユニット（ハンズフリーユニット３２２０など）を通じて音声を出力させることができる。

図３３は、一実施形態による映像通話の招待を受信し、ハンズフリーデバイスに電話させ、ハンズフリーデバイスから応答表示を受信し、映像通話を確立し、ハンズフリーデバイスに音声を経路指定するクライアントコンピュータデバイス３２１０を示している。図３３を図３２の例示的な実施形態を参照して説明する。しかし、図３３の作動は図３２を参照して説明したもの以外の実施形態により行うことができ、図３２を参照して説明する実施形態は、図３３を参照して説明したものと異なる作動を行うことができることを理解すべきである。

作動３３１０で、ＩＰ映像通話マネージャ３２５０は、ＩＰ映像通話に参加するようにクライアントデバイス３２１０のユーザを招待する別のクライアントデバイスからＩＰ映像通話招待を受信する。ＩＰ映像通話招待は、本明細書で上述したように招待の形式を取ることができる。ＩＰ映像通話マネージャ３２５０は、招待を作動３３１５で表示させることを含む招待要求を処理する。例えば、招待要求は、図１４に示す例示的な映像通話招待１４１０と同様に表示することができる。

更に、ＩＰ映像通話マネージャ３２５０は、通話オブジェクト３３２０を生成して電話通信マネージャ３２６０に送信する。通話オブジェクト３３２０は、通話に関する１組のパラメータを含む。例えば、通話オブジェクトパラメータは、通話のステータス（例えば、接続中）及び通話参加者識別子（例えば、電話番号、電子メールアドレス、又は他のオンライン通信セッション終点識別子）、開始時間、配信又は着信であるか否かの表示、及び通話を識別するために内部的に使用される通話識別子のうちの１つ又はそれよりも多くを含む。

一実施形態では、通話オブジェクト３３２０は、パラメータはＩＰ映像通話招待からの情報に基づくが、ＩＰ映像通話招待要求及び引込み音声専用携帯電話通話に向けて共通であるフォーマットである一般的な通話オブジェクトである。従って、着信音声専用携帯電話通話を受信した時に、携帯電話通話マネージャ３２５５は、同じフォーマットの着信オブジェクトを生成する。従って、電話通信マネージャ３２６０の観点からすれば、ＩＰ映像通話招待要求又は引込み音声専用携帯電話通話は、同じであるように見える。

電話通信マネージャ３２６０は、通話履歴構造の一部として通話オブジェクト３３２０内に情報を記憶する。電話通信マネージャ３２６０、着信メッセージ３３２２を生成してハンズフリーマネージャ３２７０に送る。一実施形態では、電話通信マネージャ３２６０は、クライアントデバイス３２１０に匹敵するハンズフリーデバイス３２２０のようなハンズフリーデバイスがある場合に、着信メッセージ３３２２を送るだけである（例えば、電話通信マネージャ３２６０は、最初に、クライアントデバイス３２１０に匹敵するハンズフリーデバイスがあるか否かを調べる）。他の実施形態では、電話通信マネージャ３２６０は、ピア接続されたハンズフリーデバイスがあるか否かに関わらず、ハンズフリーマネージャ３２７０に着信メッセージ３３２２０を送り、ハンズフリーマネージャ３２７０は、ピア接続されたハンズフリーデバイスがあるか否かにより、メッセージを断念／無視すべきであるか、又は処理すべきか否かを判断する。図３３及びその後の図の目的上、ハンズフリーデバイス３２２０はクライアントコンピュータデバイス３２１０に匹敵すると仮定する。一実施形態では、着信メッセージ３３２２は、通話識別子を含む。

着信メッセージ３３２０を受信することに応答し、ハンズフリーマネージャ３２７０は、一連のメッセージをハンズフリーデバイス３２２０に送信させて、着信があるとハンズフリーデバイス３２２０及びユーザの注意を喚起する。図３３に示すように、ハンズフリーマネージャは、確立した音声接続３３２５上で呼出し音にメッセージ３３３０を送る前にハンズフリーデバイス３２２０との音声接続３３２５（例えば、シンクロノス・コネクション・オリエンテッド（ＳＣＯ）リンク）を確立する。この呼出し音メッセージは、クライアントデバイス３２１０により選択されるものであり、クライアントデバイス３２１０のユーザによりカスタマイズ可能にすることができる。一実施形態では、ＩＰ映像通話の呼出し音メッセージは、音声専用携帯電話通話の呼出し音と異なっている。別の実施形態では、通話に応答するまで音声接続は確立されない。このような実施形態では、着信音メッセージが、ハンズフリーデバイス３２２０に送られ、ハンズフリーデバイス３２２０は、次に、着信メロディを再生して着信に対してユーザの注意を喚起すべきか否かをローカルに判断する（着信音メッセージは、着信メロディメッセージ３３３０を送る前に送ることができる）。このような実施形態では、着信音メッセージは、通話が応えられるか又は終了されるまでハンズフリーデバイス３２２０に複数回を送ることができる。

着信音メッセージ及び／又はリングメッセージ３３３０を受信した後、しばらくしてハンズフリーデバイス３２２０は、ユーザが通話に応えたことを示す応答済みメッセージ３３３５を送信する。例えば、ユーザは、ハンズフリーデバイス３２２０上で応答ボタンを押したか、又は通話に応えるためにハンズフリーデバイス３２２０上で他の方法でアクションを講じている。ハンズフリーマネージャ３２７０は、応答済みメッセージ３３３５を受信すると、応答済みメッセージ３３４０を電話通信マネージャ３２６０に送信する。一実施形態では、応答済みメッセージ３３４０は、通話識別子を含む。図３３には図示していないが、ハンズフリーマネージャ３２７０は、応答済みメッセージ３３３５を受信することに応答し、確認応答メッセージをハンズフリーデバイス３２２０に送信することができる。

電話通信マネージャ３２６０は、応答済み通話メッセージ３３４０が通話オブジェクト３３２０に示す通話のものであると判断し（例えば、メッセージ３３４０内に含まれた通話識別子を通話オブジェクト３３２０から記憶された情報と比較することにより）、通話が応答されたことを示すメッセージ３３４５をＩＰ映像通話マネージャ３２５０に送信する。このメッセージを受信することに応答し、ＩＰ映像通話マネージャ３２５０は、作動３３５０で、ＩＰ映像通話を確立する。例えば、ＩＰ映像通話マネージャ３２５０は、本明細書で上述したようにＩＰ映像通話受諾メッセージを招待サービスに送らせ、Ｐ２Ｐ接続が、招待を送信したコンピュータデバイスと確立される（直接に又はリレーを通じて）。

ＩＰ映像通話が確立された後、しばらくしてＩＰ映像通話マネージャ３２５０は、通話オブジェクト３３５５を電話通信マネージャ３２６０に送信する。通話オブジェクト３３５５は、ステータスが接続中から接続済みに変わった点を除いて、通話オブジェクト３３２０と類似の１組のパラメータを含む。一実施形態では、通話オブジェクト３３５５は、確立されたＩＰ映像通話及び接続済みた音声専用携帯電話通話に対して共通であるフォーマットである一般的な通話オブジェクトである。

更に、ＩＰ映像通話が確立された後、しばらくして音声マネージャ３２７５は、ハンズフリーデバイス３２２０を通じて確立されたＩＰ映像通話の音声部分を経路指定する。一実施形態では、ＩＰ映像通話マネージャ３２５０又は電話通信マネージャ３２６０は、ハンズフリーデバイスを通じて音声を経路指定するように音声マネージャ３２７５を要求する。音声マネージャ３２７５は、音声ルートがハンズフリーデバイス３２２０を通過するように変更されることになることを示すメッセージ３３６０をハンズフリーマネージャ３２７０に送信することができる。音声接続がまだ確立されていない場合に、ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０との音声接続を確立する。確立された音声接続があると仮定し、映像通話の音声部分３３６５は、ハンズフリーデバイス３２２０に経路指定される。従って、映像通話の音声部分は、ハンズフリーデバイス３２２０を通じて処理され、一方、映像通話の映像部分は、クライアントデバイス３２１０上に表示されている。

図３４は、一実施形態による映像通話を開始してハンズフリーデバイスを通じて確立された映像通話に向けて音声を経路指定するクライアンデバイス３２１０を示している。図３４を図３２の例示的な実施形態を参照して説明する。しかし、図３４の作動は図３２を参照して説明したもの以外の実施形態により行うことができ、図３２を参照して説明する実施形態は、図３４を参照して説明したものと異なる作動を行うことができることを理解すべきである。

作動３４１０で、ＩＰ映像通話マネージャ３２５０は、ＩＰ映像通話にユーザを招待するために１つ又はそれよりも多くのＩＰ映像通話招待メッセージを他のクライアントデバイスに送らせる。ＩＰ映像通話招待メッセージは、本明細書で上述したように招待の形式を取ることができる。ＩＰ映像通話マネージャ３２５０は、通話オブジェクト３４１５を生成して電話通信マネージャ３２６０に送信する。通話オブジェクト３３２０と同様に、通話オブジェクト３４１５は、通話に関する１組のパラメータを含み、かつ一般的なフォーマットである。電話通信マネージャ３２６０は、通話履歴構造の一部として通話オブジェクト３４１５内に情報を記憶する。

一実施形態では、電話通信マネージャ３２６０は、発信があることを示す発信メッセージ３４２０も生成してハンズフリーマネージャ３２７０に送る。このメッセージに応答し、ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０との音声接続３４２５を確立し（カスタムメイドの帯域内の着信メロディが送られることになっている場合）、次に、着信メロディメッセージ３４３０をハンズフリーデバイス３２２０に送信する。他の実施形態では、ハンズフリーマネージャ３２７０は、音声接続を確立して帯域内の着信メロディを送信するのではなく、着信メロディ警報メッセージのみをハンズフリーデバイス３２２０に送信する。

ＩＰに映像通話招待を送った後、しばらくしてＩＰ映像通話マネージャ３２５０は、本明細書で上述したように映像通話受諾メッセージの形式を取ることができるＩＰ映像通話受諾メッセージ３４３５を受信する。このメッセージを受信した後に、「Ｐ２Ｐ ＩＰ」映像通話が、作動３４４０で受諾側クライアントデバイスと確立される（例えば、Ｐ２Ｐ接続（直接に又はリレーを通じた）が、招待を受諾したコンピュータデバイスと確立される）。

ＩＰ映像通話が確立された後、しばらくしてＩＰ映像通話マネージャ３２５０は、通話オブジェクト３４４５を電話通信マネージャ３２６０に送信する。通話オブジェクト３４４５は、ステータスが接続中から接続済みに変わった点を除いて、通話オブジェクト３４１５と類似の１組のパラメータを含む。通話オブジェクト３４４５も、一般的なフォーマットである。更に、ＩＰ映像通話が確立された後、しばらくして音声マネージャ３２７５は、ハンズフリーデバイス３２２０を通じて確立されたＩＰ映像通話の音声部分を経路指定する。一実施形態では、ＩＰ映像通話マネージャ３２５０又は電話通信マネージャ３２６０は、ハンズフリーデバイスを通じて音声を経路指定するように音声マネージャ３２７５を要求する。音声マネージャ３２７５は、音声ルートがハンズフリーデバイス３２２０を通過するように変更されることになることを示すメッセージ３４５５をハンズフリーマネージャ３２７０に送信することができる。音声接続がまだ確立されていない場合に、ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０との音声接続を確立する。確立された音声接続があると仮定し、映像通話の音声部分３４６０は、ハンズフリーデバイス３２２０に経路指定される。従って、映像通話の音声部分は、ハンズフリーデバイス３２２０を通じて処理され、一方、映像通話の映像部分は、クライアントデバイス３２１０上に表示される。

図３５は、一実施形態によるハンズフリーデバイス３２２０から通話要求を受信することに応答して映像通話を開始するクライアントデバイス３２１０を示している。図３５を図３２の例示的な実施形態を参照して説明する。しかし、図３５の作動は図３２を参照して説明したもの以外の実施形態により行うことができ、図３２を参照して説明する実施形態は、図３５を参照して説明したものと異なる作動を行うことができることを理解すべきである。

ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０から通話要求３５１０を受信する。通話要求３５１０は、ユーザが呼び出される電話番号又は他のオンライン通信セッション終点識別子を選択することに応答して生成することができる。例えば、ユーザは、最終の通話をリダイヤルするように要求するリダイヤルボタンをハンズフリーデバイス３２２０上で選択することができる。ハンズフリーマネージャ３２７０は、通話要求メッセージ３５２０を電話通信マネージャ３２６０に送信する。電話通信マネージャ３２６０は、通話要求メッセージ３５２０が映像通話に関連付けられたのか（従って、通話要求メッセージは、ＩＰ映像通話マネージャ３２５０に送られるべきである）、又は音声専用携帯電話通話の電話番号に関連付けられた識別子への通話を要求しているのか（従って、携帯電話通話マネージャ３２５５に送られるべきである）を判断する。例えば、通話要求３５２０がリダイヤル要求である場合に、電話通信マネージャ３２６０は、ＩＰ映像通話又は音声専用携帯電話通話である可能性がある最終ダイヤルされた通話にアクセスし、どこに通話要求を送るべきかを判断する。図３５に示すように、電話通信マネージャは、通話要求にメッセージ３５２５をＩＰ映像通話マネージャ３２５０に送る。通話要求メッセージ３５２５は、映像通話の要求された参加者の識別子（例えば、電話番号、電子メールアドレス、又は他のオンライン通信セッション終点識別子）を含む。通話要求メッセージ３５２５を受信することに応答し、ＩＰ映像通話マネージャ３２５０は、図３４で上述したように作動３４１０で、ＩＰ映像通話招待メッセージを表示された参加者に送らせる。図３５に示す残りの作動は、図３４を参照して上述したように行われる。従って、クライアントデバイス３２１０は、ピア接続されたハンズフリーデバイスでユーザアクションの結果としてＩＰ映像通話を確立することをサポートする。

図３６は、一実施形態による確立された映像通話の音声をハンズフリーデバイス３２２０に経路指定するクライアントコンピュータデバイス３２１０を示している。確立されたＩＰ映像通話３６１０が、クライアントデバイス３２１０と１つ又はそれよりも多くの他のクライアントデバイスの間に存在する。この通話の音声部分は、現在、クライアントデバイス３２１０のスピーカにより、又はクライアントデバイス３２１にプラグ入力されているヘッドホンを通じて出力される。作動３６１５で、ＩＰ映像通話マネージャ３２５０は、音声をハンズフリーデバイス３２２０に転送する入力を受信する。例えば、クライアントデバイス３２１０のユーザは、ピア接続されたハンズフリーデバイスに音声を転送する入力をＩＰ映像通話アプリケーションに供給している。このような入力を受信することに応答し、ＩＰ映像通話マネージャ３２５０は、ハンズフリーデバイス３２２０を通じて映像通話の音声部分を経路指定する音声ルート要求３６２０を音声マネージャ３２７５に送る。音声マネージャ３２７５は、音声ルートがハンズフリーデバイス３２２０を通過するように変更されることになることを示すメッセージ３６２５をハンズフリーマネージャ３２７０に送信することができる。音声接続がまだ確立されていない場合に、ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０との音声接続を確立する。確立された音声接続があると仮定し、映像通話の音声部分３６３５は、ハンズフリーデバイス３２２０に経路指定される。従って、ＩＰ映像通話が確立された後と、クライアントデバイス３２１０は、ユーザが音声をハンズフリーデバイスに転送することを可能にする。

図３６は、クライアントデバイスで直接に入力を受信することに応答して音声をハンズフリーデバイスに転送することを示すが、他の実施形態では、ユーザは、ハンズフリーデバイス３２２０での入力を通じてハンズフリーデバイス３２２０に音声を転送することができる。このような実施形態では、ハンズフリーマネージャ３２７０は、ハンズフリーデバイス３２２０から音声を転送する指令を受信する。ハンズフリーマネージャ３２７０は、次に、音声マネージャ３２７５に要求を送り、音声マネージャ３２７５は、次に、音声をルート変更する。

更に、図３６は、音声をハンズフリーデバイスに転送することを示すが、一部の実施形態では、音声は、ハンズフリーデバイスへクライアントデバイス３２１０のスピーカ（又はヘッドホン）に転送することができる。これは、クライアントデバイス３２１０及び／又はハンズフリーデバイス３２２０で開始することができる。このような実施形態では、音声マネージャ３２７５は、クライアントデバイス３２１０に音声を経路指定する音声経路指定要求を受信して（ＩＰ映像通話マネージャ３２５０又はハンズフリーマネージャ３２７０から）、かつ相応に作用する。

図３７は、一実施形態によるハンズフリーデバイス３２２０から通話終了要求を受信することに応答して映像通話を終了するクライアントデバイス３２１０を示している。ハンズフリーマネージャ３２７０は、ユーザがハンズフリーデバイス３２２０で通話を終了することを選択すること（例えば、終了ボタンがハンズフリーデバイス３２２０上で選択されたこと）に応答してハンズフリーデバイス３２２０から通話終了メッセージ３７１０を受信する。ハンズフリーマネージャ３２７０は、通話終了メッセージ３７１５を電話通信マネージャ３２６０に送信する。一実施形態では、通話終了要求３７１５は、どの通話を終了すべきか（複数の通話がある場合を示す通話識別子を含む。電話通信マネージャ３２６０は、終了すべき通話がＩＰ映像通話マネージャ３２５０に関連していると判断して通話終了メッセージ３７２０をＩＰ映像通話マネージャ３２５０に送る。通話終了メッセージ３７２０を受信することに応答し、ＩＰ映像通話マネージャ３２５０は、ＩＰ映像通話を終了させてクライアントデバイス３２１０をＰ２Ｐ接続から切り離させる。従って、クライアントデバイス３２１０は、ユーザがピア接続されたハンズフリーデバイスを使用してＩＰ映像通話を終了することを可能にすることをサポートする。

図３８は、一部の実施形態に使用することができる例示的なコンピュータシステムを示すブロック図である。例えば、コンピュータシステム３８００の例示的なアーキテクチャは、クライアントデバイス１１０、１２１０、１４１０、２１１０、２６１０、３２１０、又は本明細書に説明する他のコンピュータデバイス内に含めることができる。図３８は、コンピュータシステムの様々な構成要素を示すが、このような詳細は本発明とは密接な関係がないので、これは、構成要素を相互接続する特定のアーキテクチャ又は方法を表すように意図しているものではないことを理解すべきである。より少ない構成要素又はより多くの構成要素を有する他のコンピュータシステムを使用することができることが認められるであろう。

図３８に示すように、コンピュータシステム３８００（データ処理システムの形態である）は、処理システム３８２０、電源３８２５、メモリ３８３０及び不揮発性メモリ３８４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）など）と結合されたバス３８５０を含む。バス３８５０は、当業技術で公知のように、様々な架橋部、コントローラ、及び／又はアダプタを通じて互いに接続することができる。処理システム３８２０は、メモリ３０及び／又は不揮発性メモリ３８４０から命令を検索し、命令を実行し、上述のような作動を行うことができる。バス３８５０は、上述の構成要素を互いに相互接続し、任意的なドック３８６０、ディスプレイコントローラ及びディスプレイデバイス３８７０、入力／出力デバイス３８８０（例えば、ＮＩＣ（ネットワークインタフェースカード）、カーソル制御部（例えば、マウス、タッチスクリーン、タッチパッドなど）、キーボードなど）、及び任意的な無線送受信機３８９０（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ、赤外線など）にもそれらの構成要素を相互接続する。

図３９は、一部の実施形態に使用することができる例示的なデータ処理システムを示すブロック図である。例えば、データ処理システム３９００は、手持ち式コンピュータ、携帯情報端末（ＰＤＡ）、モバイル電話、携帯式ゲームシステム、携帯式メディアプレーヤ、タブレット、又はモバイル電話、メディアプレーヤ、及び／又はゲームシステムを含むことができる手持ち式コンピュータデバイスとすることができる。別の例として、データ処理システム３９００は、ネットワークコンピュータ又は別のデバイス内の内蔵型処理デバイスとすることができる。

一実施形態により、データ処理システム３９００の例示的なアーキテクチャは、クライアントデバイス１１０、１２１０、１４１０、２１１０、２６１０、３２１０、又は本明細書に説明する他のコンピュータデバイス内に含めることができる。データ処理システム３９００は、処理システム３９２０を含み、処理システム３９２０は、集積回路上の１つ又はそれよりも多くのマイクロプロセッサ及び／又はシステムを含むことができる。処理システム３９２０は、メモリ３９１０、電源３９２５（１つ又はそれよりも多くのバッテリを含む）、音声入力／出力部３９４０、ディスプレイコントローラ及びディスプレイデバイス３９６０、任意的な入力／出力部３９５０、入力デバイス３９７０、及び無線送受信機３９３０と結合される。図３９に示していない付加的な構成要素をある一定の実施形態においてデータ処理システム３９００の一部とすることができ、ある一定の実施形態では、図３９に示すよりも少ない構成要素を使用することができることが認められるであろう。更に、図３９に示していない１つ又はそれよりも多くのバスを用いて、当業技術で公知のような様々な構成要素を相互接続することができることが認められるであろう。

メモリ３９１０は、データ処理システム３９００による実行に向けてデータ及び／又はプログラムを記憶することができる。音声入力／出力部３９４０は、例えば、スピーカ及びマイクを通じて音楽を再生し及び／又は電話通信機能性をもたらすマイクやスピーカを含むことができる。ディスプレイコントローラ及びディスプレイデバイス３９６０は、グラフィカルユーザインタフェース（ＧＵＩ）を含むことができる。無線（例えば、ＲＦ）送受信機３９３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、Ｂｌｕｅｔｏｏｔｈ（登録商標）送受信機、無線携帯電話通信送受信機など）を使用して他のデータ処理システムと通信することができる。１つ又はそれよりも多くの入力デバイス３９７０は、ユーザがシステムに入力を供給することを可能にする。これらの入力デバイスは、キーパッド、キーボード、タッチパネル、マルチタッチパネルなどとすることができる。任意的な他の入力／出力部３９５０は、ドックのためのコネクタとすることができる。

図に示す技術は、１つ又はそれよりも多くのコンピュータデバイス（例えば、クライアントデバイス、サーバなど）上に記憶及び実行されるコード及びデータを使用して実施することができる。このようなコンピュータデバイスは、持続性有形機械可読媒体（例えば、磁気ディスク、光ディスク、読取専用メモリ、フラッシュメモリデバイスのような機械可読ストレージ媒体）のような機械可読媒体、及び一時的な伝播性信号（例えば、電気的、光学的、音響的、又は搬送波、赤外線信号、デジタル信号などの他の形態の伝播信号）を使用して、コード（ソフトウエア命令で構成）及びデータを記憶及び送信する（内部的に及び／又は他のコンピュータデバイスネットワークを用いて）。更に、このようなコンピュータデバイスには、一般的に、１つ又はそれよりも多くの持続性有形機械可読媒体（コード及び／又はデータを記憶する）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、及びネットワーク接続（一時的な伝播信号を使用してコード及び／又はデータを送信する）のような１つ又はそれよりも多くの他の構成要素に結合された１組の１つ又はそれよりも多くのプロセッサがある。１組のプロセッサ及び他の構成要素の結合は、一般的に１つ又はそれよりも多くのバス及び架橋部（バスコントローラとも呼ばれる）によるものである。従って、所定のコンピュータデバイスの持続性機械可読媒体は、一般的に、そのコンピュータデバイスの１組の１つ又はそれよりも多くのプロセッサ上の実行に向けて命令を記憶する。実施形態の１つ又はそれよりも多くの部分は、ソフトウエア、ファームウエア、及び／又はハードウエアの異なる組合せを使用して実施することができる。

オンライン通信セッション終点識別子として使用される電子メールアドレスを検証することに関して検証電子メールメッセージ内に含まれたリンクをクリックすることをユーザに求めることなく自動的に電子メールアドレスを検証することを参照して本明細書で作動を説明したが、実施形態は、そのように限定されない。例えば、一部の実施形態では、自動的に電子メールアドレスを検証することを参照して説明した作動は、他の理由で電子メールアドレスを検証する必要がある時に行われる。例えば、ユーザは、登録処理の一部として電子メールアドレスがそのユーザのものであるとしてそれを検証する必要があるサービスに向けて登録することになると考えられる。ユーザは、サービスに電子メールアドレスを供給し、電子メールアドレスを検証する必要があり、かつ電子メール検証メッセージが供給された電子メールアドレスに送られるか又は送られたことを示すメッセージを受信する（例えば、サービスのウェブページの表示を通じて）（電子メール検証メッセージは、検証リンクを含む場合もあれば、含まない場合もある）。クライアントデバイス上のアプリケーションは、検証メッセージの電子メールアドレスに対応する電子メールアカウントを自動的に検査することができ、電子メールの位置が識別された時に、自動的にメッセージを構文解析し、検証トークンを位置付け、電子メールアドレスを検証するために、電子メールアドレス及び検証トークンを含む電子メールアドレス検証メッセージをサービスに関連付けられた電子メール検証サーバに送信する。図中の流れ図はある一定の実施形態により行われる作動の特定の順番を示すが、このような順番は、例示的であることを理解すべきである（例えば、代替的な実施形態は、異なる順番で作動を提供し、ある一定の作動を結合し、ある一定の作動と重なることができるなど）。

本発明をいくつかの実施形態に関して説明したが、当業者は、本発明が説明された実施形態に限定されず、すなわち、特許請求の範囲の精神及び範囲内で修正及び変更を行って実施することができることを認識するであろう。説明は、従って、制限的なものではなく例示的なものであると見なすものとする。

１１０ クライアントデバイス
１１５ 識別トークン
１２０ ＳＭＳネットワーク
１２５ キャリアＳＭＳＣ
１５０ オンライン通信セッション登録データストア

Claims (16)

1. オンライン通信セッションのためにクライアントコンピュータデバイスを登録する方法であって、
   クライアントコンピュータデバイスに固有である識別トークンとそのクライアントコンピュータデバイスの電話番号とを有するメッセージをＳＭＳ（ショートメッセージサービス）トランジットデバイスから受信する段階であって、前記ＳＭＳトランジットデバイスは前記クライアントコンピュータデバイスから前記識別トークンを有するＳＭＳメッセージを受信するものであり、前記ＳＭＳトランジットデバイスは前記識別トークンを用いて前記クライアントコンピュータデバイスの前記電話番号を判断したものである、段階と、
   前記識別トークンと前記電話番号とを関連付ける段階であって、この関連付けはオンライン通信セッションネットワークにおける前記デバイスを一意に識別するためのものである、段階と、
   オンライン通信セッション登録データストア内に前記関連付けを記憶する段階と、
   を含むことを特徴とする方法。
2. 前記ＳＭＳトランジットデバイスからの前記メッセージは、前記クライアントコンピュータデバイスの電源が投入されて前記識別トークンを有する前記ＳＭＳメッセージを該クライアントコンピュータデバイスに自動的に送信することに応答して送信されたものであることを特徴とする請求項１に記載の方法。
3. 前記識別トークンは、プッシュ通知サービスが該クライアントコンピュータデバイスを位置付けてそこにプッシュ通知メッセージを送信することを可能にする情報を含むことを特徴とする請求項１に記載の方法。
4. 前記クライアントコンピュータデバイスにオンライン通信セッション招待を送信する時に使用されるオンライン通信セッション招待サービスに前記識別トークンと前記電話番号の間の前記関連付けを提供する段階を更に含むことを特徴とする請求項１に記載の方法。
5. 前記識別トークン及び前記電話番号を関連付ける段階の前に、
   前記識別トークン及び前記電話番号に基づいて署名を発生させる段階と、
   前記クライアントコンピュータデバイスへの配信に向けて前記ＳＭＳトランジットデバイスに前記署名と、前記識別トークンと、前記電話番号とを含むメッセージを送信する段階と、
   前記クライアントコンピュータデバイスから前記署名と、識別トークンと、前記電話番号とを有するメッセージを受信する段階と、
   前記クライアントコンピュータデバイスから受信した前記識別トークン及び電話番号を検証する段階と、
   を実行する段階、
   を更に含むことを特徴とする請求項１に記載の方法。
6. 前記ＳＭＳトランジットデバイスは、ＳＭＳゲートウェイ又はＳＭＳアグリゲータであることを特徴とする請求項１に記載の方法。
7. オンライン通信セッションのためにクライアントコンピュータデバイスを登録する登録サーバであって、
   ＳＭＳトランジットデバイスから登録要求メッセージを受信するＳＭＳ（ショートメッセージサービス）トランジットインタフェースであって、前記ＳＭＳトランジットデバイスは複数のクライアントコンピュータデバイスからＳＭＳメッセージを受信し、各登録要求メッセージが、前記複数のクライアントコンピュータデバイスのうちの１つのクライアントコンピュータデバイスに固有である識別トークンを含み、そのクライアントコンピュータデバイスの電話番号は前記ＳＭＳトランジットデバイスによって決定されるものである、ＳＭＳトランジットインタフェースと、
   オンライン通信セッションネットワークにおける前記クライアントコンピュータデバイスを一意に識別するために前記識別トークンと決定された電話番号を関連付け、そして、その関連付けをオンライン通信セッションネットワーク登録データストアに記憶する関連付けモジュールと、
   を含むことを特徴とする登録サーバ。
8. 識別トークンが、クライアントコンピュータデバイスを一意的に識別し、かつプッシュ通知サービスがそのクライアントコンピュータデバイスを位置付けてそこにプッシュ通知メッセージを送信することを可能にする情報を含むことを特徴とする請求項７に記載の登録サーバ。
9. 前記ＳＭＳトランジットデバイスから受信した各識別トークン及び決定された電話番号の対に対して署名を発生させる署名発生モジュールであって、前記ＳＭＳトランジットデバイスは前記登録サーバのＳＭＳトランジットインタフェースから登録応答メッセージを受信したものである、署名発生モジュールと、
   前記ＳＭＳトランジットデバイスから受信された各データの対のための署名を含む登録検証要求メッセージをクライアントデバイスから受信するクライアントデバイスインタフェースと、
   前記データの対の間の関連付けの発生の前に前記署名を用いてクライアントコンピュータデバイスのためのデータの対を検証する検証モジュールと、
   を更に含むことを特徴とする請求項７に記載の登録サーバ。
10. 前記ＳＭＳトランジットデバイスは、ＳＭＳゲートウェイ又はＳＭＳアグリゲータであることを特徴とする請求項７に記載の登録サーバ。
11. プロセッサによって実行された時に該プロセッサをして請求項１から請求項６のいずれか１項に記載のオンライン通信セッションのためにクライアントコンピュータデバイスを登録する方法を実行させることになる命令を提供する持続性機械可読ストレージ媒体。
12. クライアントコンピュータデバイスに固有の識別トークンと前記クライアントコンピュータデバイスに関連付けられた決定された電話番号を含むデータの対を関連付ける登録サーバであって、オンライン通信セッション登録データストア内に前記データの対を記憶する登録サーバと、
    複数のクライアントコンピュータデバイスからＳＭＳメッセージを受信するＳＭＳ（ショートメッセージサービス）トランジットデバイスであって、前記メッセージは前記クライアントコンピュータデバイスの識別トークンを含み、前記ＳＭＳトランジットデバイスは前記ＳＭＳメッセージから前記クライアントコンピュータデバイスの電話番号を決定し、前記ＳＭＳトランジットデバイスはさらに識別トークン及び決定された電話番号の対を前記登録サーバに送信する、ＳＭＳトランジットデバイスと、
    を含むことを特徴とするオンライン通信セッション登録システム。
13. 各識別トークンが、クライアントコンピュータデバイスを一意的に識別し、かつプッシュ通知サービスがこのクライアントコンピュータデバイスを位置付けてそこにプッシュ通知メッセージを送信することを可能にする情報を含むことを特徴とする請求項１２に記載のシステム。
14. 前記登録サーバは、更に、前記ＳＭＳトランジットデバイスから受信した各識別トークン及び決定された電話番号の対に対して署名を発生させ、かつクライアントコンピュータデバイスに対する署名と、識別トークンと、電話番号とを有するメッセージを該ＳＭＳトランジットデバイスに送信することを特徴とする請求項１２に記載のシステム。
15. 前記ＳＭＳトランジットデバイスは、更に、前記クライアントコンピュータデバイスに前記登録サーバよって発生された署名とそのクライアントコンピュータデバイスに対する電話番号とを各々が有するＳＭＳメッセージを送信することを特徴とする請求項１４に記載のシステム。
16. 前記登録サーバは、更に、署名と電話番号と識別トークンとを各々が含むメッセージをクライアントコンピュータデバイスから受信し、
    前記登録サーバは、更に、前記クライアントコンピュータデバイスから受信した前記署名と該登録サーバによって発生された前記署名とに基づいて、該クライアントコンピュータデバイスから受信した前記識別トークン及び電話番号の対を検証する、
    ことを特徴とする請求項１５に記載のシステム。

Images