JP6014297B2 - 異なる端末のアプリケーション間の通信 - Google Patents

Description

関連出願

本出願は、２０１１年１０月１８日出願の米国特許出願番号１３／２７６２１１、２０１１年１０月１８日出願の米国特許出願番号１３／２７６２２０、２０１１年１０月１８日出願の米国特許出願番号１３／２７６２２９、および２０１１年２月２４日出願の米国仮出願番号６１／４４６０４５の優先権の利益を有し、引用により本明細書に組み込まれるものとする。

ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークアーキテクチャは、ＩＰ関連技術を用いたリアルタイムマルチメディア配信を可能にする端末間アーキテクチャの例である。これにより、インターネット、固定有線電話通信および無線通信機能が融合される。これにより、無線アクセスネットワークの異なるネットワーク間のハンドオーバやローミングなどの異種環境アクセス技術によって課せられる異なるアクセス関連制約を管理し、多種の機器がサポートされる。たとえば、テキストによるチャット、写真・映像・音楽・ファイルの転送、ライブ映像の共有、グループチャット、位置の共有、双方向またはグループ通信などの多様な通信技術をサポートする多様なアプリケーションにおいて、ネットワークを介してアプリケーション間通信を提供する必要性が高まっている。本発明は、この必要性を満足させる。

いくつかの実施形態において、ネットワークを介してメディア情報を通信する方法が提示される。第１端末装置で動いている第１アプリケーションからの、第２端末装置で動いている第２アプリケーションとのメディア接続の要求に応じて、第２アプリケーションとのメディア接続の要求をネットワークを介して送信する。メディア接続要求は第１アプリケーションに関連付けられたアプリケーション識別子（ＡｐｐＩＤ）を含んでいる。第１アプリケーションによる要求に応じて、要求されたメディア接続の承認を得る承認要求がネットワークを介してアプリケーション管理サーバに送信される。承認要求は第１アプリケーションに関連付けられたＡｐｐＩＤを含んでいる。メディア接続要求に応じて、第１端末装置と第２端末装置との間に確立された制御セッションを介して制御情報が通信される。制御情報は第１アプリケーションに関連付けられたＡｐｐＩＤを含んでいる。メディア接続要求に応じて、第１端末装置と第２端末装置との間に確立されたメディアセッションを介してメディア情報が通信される。

図１Ａは、いくつかの実施形態におけるシステムを例示する図である。 図１Ｂは、いつくかの実施形態において、図１Ａのアプリケーション管理サーバを使用して実行される第１プロセスの例示的なフローチャートである。 図１Ｃは、いつくかの実施形態において、図１Ｂの第１プロセス内の判定モジュールの詳細を示す例示的なフローチャートである。 図１Ｄは、いつくかの実施形態において、図１Ｃの第１プロセス内の判定モジュールの詳細を示す例示的なフローチャートである。 図１Ｅは、いくつかの実施形態において、図１Ａのアプリケーション管理サーバにより実行される第２プロセスの例示的なフローチャートである。 図２Ａは、いくつかの実施形態において、図１のシステムの複数の端末装置のアプリケーション間のメディア通信を初期化する信号フロープロトコルを例示する図である。 図２Ｂは、いくつかの実施形態における代替システム２６０の例示的な図である。 図３は、いくつかの実施形態における要求例の構成内のフィールドを例示する図である。 図４は、いくつかの実施形態におけるメッセージ例の構成内のヘッダフィールドを例示する図である。 図５は、いくつかの実施形態において、メディア通信の初期化が成功し、端末装置間でメディアデータを送信するために通信プロトコルスタックが使用される、図１および図２のシステムの例示的な図である。 図６は、図５のメディアセッションの詳細を例示し、メディアセッションに関連付けられた異なるポート例を示す図である。 図７は、いくつかの実施形態において、図２Ａの通信プロトコルに従ってセッションの初期化成功後に第１および第２の端末装置内に１つ以上のデータバッファが割り当てられていることを示すシステムの例示的な図である。 図８は、いくつかの実施形態において、Ａ２Ａ対応アプリケーションがメディアセッションを用いるプロセスを例示するフローチャートである。 図９は、いくつかの実施形態において、Ａ２ＡエンジンがＡ２Ａ対応アプリケーションおよび通信プロトコルスタックと相互作用するプロセスを例示するフローチャートである。 図１０は、本明細書に記載される１つ以上の手順をコンピュータに実行させるように、命令セットが実行される端末装置として動作するコンピュータ処理装置のブロックシステムである。

以下、承認済アプリケーション間通信をマルチメディアネットワークを介して安定して確保するシステム、方法および製品アーティクルを、当業者が作成・使用できるように記載される。好ましい実施形態に対する種々の変更は当業者には容易に明らかであり、本明細書に記載される一般的原理は本発明の主旨・範囲からはずれることなく他の態様や使用に適用可能である。以下、アプリケーションやモジュールにより特定された動作を実行する１つ以上のプロセッサを構成するように、たとえば、ＲＡＭなどの揮発性記憶媒体やディスクやフラッシュなどの不揮発性記憶媒体に格納されたコンピュータプログラムコードにより構成されるアプリケーションやプロセスモジュールについて開示する。さらに、以下に、多くの詳細事項が説明のために記載されている。しかし、当業者は、それら特定の詳細事項を使用せずに本発明を実施できることを理解できるであろう。また、不要な詳細により本発明の記載が理解しにくくならないように、周知の構成やプロセスについてはブロック図形式で示している。このように、本発明は、以下に示される実施形態に限定されることなく、本明細書に開示される原理や特徴に沿った最も広い範囲として認められるべきものである。

図１Ａはいくつかの実施形態におけるシステム１００を例示する図である。システム１００は、マルチメディアサービス配信ネットワークアーキテクチャ２０８を介して通信する第１端末装置２０２−１と第２端末装置２０２−２を備える。端末装置は、移動電話無線装置、セットトップボックス、タブレットコンピュータ、自動車ナビゲーション／娯楽システム、ゲームコンソール、パーソナルコンピュータ、またはこれらの組合せを備える。いくつかの実施形態では、ネットワークアーキテクチャ２０８はＩＭＳアーキテクチャを備える。

第１および第２端末装置２０２−１、２０２−２はアプリケーション間（以下、Ａ２Ａ）通信用に構成されている。すなわち、第１装置２０２−１で動いているアプリケーションは、第２装置２０２−２で動いているアプリケーションと通信することができる。たとえば、マルチユーザＡ２Ａ通信ゲームアプリケーションによれば、ゲームの音声や映像とともにゲームデータを交換することができ、ゲーム中にユーザがお互いに話したり見たりすることができる。別の例として、マルチメディアＡ２Ａ通信メッセージングアプリケーションによれば、テキストによるチャット、写真／映像／音楽／ファイルの転送、ライブ映像の共有、グループチャット、位置の共有、またはあらゆる種類の双方向またはグループの通信を行うことができる。さらに別の例として、マルチプレーヤＡ２Ａ通信ゲームアプリケーションによれば、短い待ち時間、２者以上の間でのピアツーピアのデータ交換、および／または音声・映像またはテキストによるチャットなどの他のマルチメディア機能を含むことができる。Ａ２Ａ通信を含むアプリケーションの他の例としては、統合通信アプリケーション、顧客ケアアプリケーション、社交／交際アプリケーション、企業アプリケーションが挙げられる。これらの例示されたＡ２Ａ通信アプリケーションは、ピアツーピアのデータ交換やマルチメディアメッセージ交換（テキスト、映像、音声、写真、または他のマルチメディアタイプ）など、同様な機能を利用することができる。他のＡ２Ａ通信アプリケーションは、音声／映像会議アプリケーションを含んでいてもよい。以下に詳細に説明されるように、装置はアプリケーションが他のアプリケーションとメディアデータを通信できる１以上のメディアセッションを確立する。

Ａ２Ａアプリケーション管理サーバ１０２は、Ａ２Ａ対応アプリケーション間のメディアセッションの確立中は制御パスに配置される。サーバ１０２は、Ａ２Ａアプリケーション間のメディア接続の承認を管理する。さらに詳細には、様々な異なるＡ２Ａアプリケーションが様々な異なる端末装置で動いていてもよい。アプリケーション管理サーバ１０２は、端末装置で動くとともにＡ２Ａ通信に対応可能なアプリケーション（以下、Ａ２Ａ対応アプリケーション）間のメディア接続の承認を管理する。

管理承認は、Ａ２Ａ対応アプリケーションを識別することを含む。また、管理承認は、他のＡ２Ａ対応アプリケーションとの間でＡ２Ａ通信を確立するために、表面上は識別されたＡ２Ａ対応アプリケーションから受領した要求が、その要求を送信したとされるＡ２Ａ対応アプリケーションによって実際に送信されたと確認することも含む。さらに、いくつかの実施形態では、管理承認は、要求内で特定されたユーザにアプリケーションが承認されるか否か判定するための１つ以上の規定を適用することを含む。

いくつかの実施形態では、アプリケーション管理サーバはアプリケーション登録インターフェース１１２を含み、Ａ２Ａ対応アプリケーションに関連付けられたアプリケーション識別子（ＡｐｐＩＤ）やアプリケーション秘密情報（アプリケーション秘密）などの非公開情報を指定するために使用するように、ウェブサーバ、データベース、遠隔プロセス、または分散クライアントや他のシステムに中央管理されたデータを利用可能にする他の手段として機能する。いくつかの実施形態では、開発者は、Ａ２Ａ対応アプリケーションを登録するために、アプリケーション登録インターフェース１１２を使用する。予備登録段階では、開発者は、アプリケーションをアプリケーションレジストリ１０４に登録する。ＡｐｐＩＤとアプリケーション秘密が返送されて、アプリケーションにインデックスを付ける。ＡｐｐＩＤは、メッセージ中のＡｐｐＩＤとアプリケーションのＡｐｐＩＤとの一致によってすべてのメッセージの経路を決めるために使用される。この登録は、一回限りのイベントであり、アプリケーション配備のために一回発生する。アプリケーション秘密は、動的にアプリケーショントークンを作成するために使用される。動的登録段階では、開発者は事前にアプリケーションを登録することはせず、複数のアプリケーションの動的な登録を可能にする開発者キーまたはトークンを有する。これは、プラットフォームで承認された「信任開発者」である。開発者キーは、動作中のアプリケーション登録中にパスし、バックエンドレジストリデータベース内の開発者キーのホワイトリストに対して確認される。それぞれの開発者キーには特性が関連付けられ、たとえば、動的登録または携帯電話会社により登録される個別のアプリケーションの数を制限する。他の特性も可能である。動的登録の間に、ＡｐｐＩＤおよびアプリケーション秘密を引き出すために、開発者キーはアプリケーションのスタートアップまたはインストールに進む。セッションの間またはプラットフォームにより定義される長い期間、アプリケーション秘密は有効となっている。

ＡｐｐＩＤを登録するときに、開発者／アプリケーションは、どのようなタイプのメッセージがＡｐｐＩＤに対応するアプリケーションによって受信可能か特定してもよい。ここで、以下のような選択肢が考えられる。
（１）アプリケーションは、同一のアプリケーション／ＡｐｐＩＤからのメッセージのみ受信することができる。
（２）アプリケーションは、そのＡｐｐＩＤに対してアプリケーションレジストリ１０４にホワイトリストされているアプリケーションの定義されたリストからのメッセージを受信することができる。
（３）アプリケーションは、特定の開発者からのメッセージを受信することができる。
（４）アプリケーションは、たとえば特定のまたはリストされた国の携帯ネットワークなど、特定のネットワークまたはネットワークオペレータからのすべてのメッセージを受信できる。
（５）アプリケーションは、誰からもメッセージを受信することができる。
他の制約も可能であり、ＡｐｐＩＤ登録の登録パラメータに追加することができる。

ＡｐｐＩＤは、システム１００内においてＡ２Ａ対応アプリケーションを固有に識別する識別子である。言い換えれば、それぞれの異なる種類のＡ２Ａアプリケーションは、自身の固有なＡｐｐＩＤに関連付けられている。ＡｐｐＩＤは、異なる方法により生成することができ、異なるフォーマットを有することができる。異なるフォーマットには、数字の識別子（たとえば、１２３４）、英数字の識別子（たとえば、ａｃｍｅ―ａｐｐｌｉｃａｔｉｏｎ―１）、ホスト／ドメイン／パッケージの名称（たとえば、ｃｏｍ．ａｃｍｅ．ｘｙｚ）やランダムな値が含まれるがこれらには限定されない。

アプリケーション管理サーバ１０２がメディア接続要求のソースを確認する際に使用するために、Ａ２Ａ対応アプリケーションに関連付けられた秘密情報は、メディア要求の一部としてネットワーク２０８を介して送信されるトークン（シグナチャ）を生成するために使用される。いくつかの実施形態では、たとえば、ＡｐｐＩＤ、秘密情報、および要求に固有に関連付けられた他の情報（ヘッダ情報、タイムスタンプ、またはノンスなど）の機能として、トークンが動的に生成される。当然のことながら、トークンを生成するために特定の要求の特性に関連付けられた情報を使用することにより、たとえばリプレーアタックを回避しやすくなる。いくつかの実施形態では、たとえばＭＤ５ハッシュまたはＨＭＡＣ−ＳＨＡ１ハッシュなどのハッシュ技術によりトークンが生成される。トークン生成の構成は本発明の範囲に含まれない。トークンやハッシュなどを生成するいくつかの一般的な方法は、当業者には容易に利用可能である。アプリケーション管理サーバ１０２もＡｐｐＩＤに関連付けられた秘密情報を所有（共有）し、メディア接続要求がその要求を送信したとされるＡ２Ａ対応アプリケーションによって実際に送信されたことを確認するために秘密情報とトークンを使用する。このように、サーバ１０２は、ネットワーク２０８を介して秘密情報を送信する必要なしに要求を確認するためにトークンを使用する。

Ａ２Ａサーバ１０２は、それぞれ持続性記憶媒体内にコード化されたＡ２Ａアプリケーションレジストリ１０４とユーザプロファイルレジストリ１０６を備える。Ａ２Ａアプリケーション管理サーバ１０２は、アプリケーションサービス１０８とユーザデータ収集サービス１１０を実行する。

表１は、いくつかの実施形態における持続性記憶媒体内にコード化されたアプリケーションレジストリ１０４の情報構造例を示す。

アプリケーションレジストリ１０４は、それぞれに異なるＡ２Ａ対応アプリケーションを固有に識別する複数のＡｐｐＩＤを含む。レジストリ内の各ＡｐｐＩＤは、メディア接続要求のソースを確認するために使用される秘密情報に関連付けられている。各ＡｐｐＩＤは、ＡｐｐＩＤに対応するＡ２Ａアプリケーションに関連付けられた規則を示すメタデータに関連付けられてもよい。

表２は、いくつかの実施形態のおける持続性記憶媒体内にコード化されたユーザプロファイルレジストリ１０６の情報構造例を示す。

ユーザプロファイルレジストリ１０６は、メディア接続要求において特定されたユーザに関連付けられたユーザプロファイル情報を提供する。ユーザプロファイル情報は、サービス加入状態やユーザにより申し込まれたサービス品質の情報（最大許容ビットレートまたは許容転送量クラスなど）などの情報を含んでいてもよい。いくつかの実施形態では、アプリケーション管理サーバ１０２は、ホーム回線サーバ（ＨＳＳ）やユーザ回線関連情報を含む３Ｇネットワークのマスターデータベースなどの携帯電話会社データベースから、情報をプロファイルレジストリ１０６内に入手する。いくつかの実施形態では、ユーザプロファイルレジストリ１０６は、携帯電話会社データベースの拡張として機能する。

図１Ｂは、いくつかの実施形態において、図１Ａのアプリケーション管理サーバ１０２のアプリケーションサービス１０８を使用して実行される第１プロセス１２０の例示的なフローチャートである。特定のＡｐｐＩＤと秘密情報に関連付けられたＡ２Ａアプリケーションのインスタンスを含む第２装置２０２−２とのＡ２Ａ通信を確立するために第１端末装置２０２−１で動いているＡ２Ａアプリケーションから発せられた要求を受信すると、モジュール１２２では、アプリケーションレジストリ１０４からＡｐｐＩＤに対応する情報一式を引き出すように試みられる。いくつかの実施形態では、第１端末装置２０２−１がネットワーク２０８を介して要求を送信する。要求は、ネットワーク２０８内の後述のプロキシサーバがこの要求をアプリケーション管理サーバ１０２に転送させる命令を含む。判定モジュール１２４において、ＡｐｐＩＤが登録されているか否か、すなわち、アプリケーションレジストリ１０４がＡｐｐＩＤにより有効なＡ２Ａ対応アプリケーションを特定されていることを示すか否かを判定される。判定モジュール１２４においてＡｐｐＩＤがレジストリ１０４に格納されていないと判定された場合には、モジュール１２６において要求拒絶を示すメッセージが発せられる。いくつかの実施形態では、拒絶メッセージは、拒絶に応じて要求を第２装置２０２−２に送信しないように判定するプロキシサーバに送信される。

判定モジュール１２４においてＡｐｐＩＤがレジストリ１０４に格納されていると判定された場合には、制御は判定モジュール１２８に進み、要求が、実際に承認済Ａ２Ａ対応アプリケーションから発せられたことを示す有効なトークンを含んでいるか否か、そして、たとえばスパムではないか否かが判定される。トークンの確認は、アプリケーションレジストリ１０４内で要求に含まれるＡｐｐＩＤに関連付けられた秘密情報の使用を含む。いくつかの実施形態では、トークンの確認は、上述のように変換情報を生成するために要求内のヘッダ情報のハッシュを反転させることを含む。判定モジュール１２８において変換情報が識別されたＡｐｐＩＤを有する秘密情報に一致しないと判定された場合には、要求は有効なトークンを含まない。そして、上述のように、モジュール１２６において要求拒絶を示すメッセージが発せられる。いくつかの実施形態では、モジュール１２６において、要求を発した端末装置に要求が拒絶されたことを通知するメッセージがネットワークを介して送信される。

判定モジュール１２８において要求が有効なトークンを含んでいると判定された場合には、制御は判定モジュール１３０に進み、アプリケーションレジストリ１０４内で要求に含まれるＡｐｐＩＤに関連付けられたメタデータにより示された規則や規定に要求が適合するか否かが判定される。判定モジュール１３０においてＡｐｐＩＤに関連付けられた規則が要求を拒絶すべきことを示すと判定された場合には、モジュール１２６により要求拒絶を示すメッセージが発せられる。しかし、モジュール１３０においていずれの規則や他の基準も要求許可を妨げないと判定された場合には、モジュール１３２において要求は受諾される。いくつかの実施形態では、要求の受諾は、要求が申し込まれた端末装置にネットワークを介して要求を転送することを含む。

図１Ｃは、いくつかの実施形態における判定モジュール１３０の詳細を示す例示的なフローチャート１４０である。判定モジュール１４２において、ＡｐｐＩＤに関連付けられたメタデータが要求の際のメッセージで特定されたユーザとの同一性に関わらず適用可能な１つ以上の規則を含んでいるか否かが判定される。本明細書で使用されているように、ユーザは、個々のユーザと、たとえば、特定のグループ、組織または組織内の部署に関連付けられたユーザなどのユーザカテゴリを含む。たとえば、Ａ２Ａ対応アプリケーションは、周知のセキュリティまたは不正の問題によりグローバルにブラックリストされているかもしれない。判定モジュール１４２において規則が要求を拒絶すべきことを示すと判定された場合には、モジュール１２６において要求拒絶を示すメッセージが発せられる。判定モジュール１４２において要求拒絶を求めるユーザに依存しない規則が存在しないと判定された場合には、制御は判定モジュール１４４に進み、ＡｐｐＩＤに関連付けられたメタデータと併せてユーザに依存する規則が承認要求を拒絶されるべきことを示すか否かが判定される。判定モジュール１４４においてユーザに依存する規則が要求を拒絶すべきことを示す場合には、モジュール１２６により要求拒絶を示すメッセージが発せられる。そうでない場合には、モジュールにおいて要求は受諾される。

図１Ｄは、いくつかの実施形態において、判定モジュール１４４の詳細を示す例示的なフローチャート１７０である。モジュール１７２において、ＡｐｐＩＤに関連付けられたアプリケーションメタデータが取得される。モジュール１７４において、アプリケーションメタデータに関連するユーザプロファイル情報が取得される。モジュール１７６において、ユーザプロファイルとアプリケーションメタデータの機能として、１つ以上の承認規則が適用される。たとえば、Ａ２Ａ対応アプリケーションは、携帯電話契約に基づいて特定の顧客にはブラックリストされているかもしれない（たとえば、ある映像チャットアプリケーションは未成年者には利用させるべきではない）。他のＡ２Ａ対応アプリケーション（たとえば、ＨＤ品質テレビ会議）は、特別契約によってのみ利用可能かもしれない。

したがって、第１端末装置２０２−１で動いているＡ２Ａ対応アプリケーション２０４−１によりネットワーク２０８を介して送信された、第２端末装置２０２−２で動いている他のＡ２Ａ対応アプリケーション２０４−２とのメディア通信の要求は、アプリケーションに関連付けられたメタデータおよびアプリケーションのユーザに関連付けられたプロファイル情報に基づいて承認されることが可能となる。

図１Ｅは、いくつかの実施形態において、図１Ａのアプリケーション管理サーバ１０２のユーザデータサービス１０８を使用して実行される第２プロセス１５０の例示的なフローチャートである。モジュール１５２において、ＡｐｐＩＤに関連付けられたアプリケーションメタデータが取得される。モジュール１５４において、アプリケーションメタデータに関連するユーザプロファイル情報が取得される。モジュール１５６において、ユーザプロファイルとアプリケーションメタデータの機能として、１つ以上のユーザ管理規則が適用される。たとえば、管理規則は、統計のため拒絶された要求のログを生成し、要求している装置のユーザに携帯電話会社の顧客サポートシステムを介して拒絶を通知（電子メールやＳＭＳなど）し、またはこの情報を他の手段を介してユーザに返信してもよい。別の例として、管理規則により、特定のユーザが特定のＡｐｐＩＤに関連付けられたアプリケーションにアクセスするときには特別な請求料率が適用されるように定めてもよい。たとえば、ユーザは特定のゲームアプリケーションを特別料金で使用することを申し込んでもよい。さらに別の例として、管理規則は、携帯電話会社の課金システムによって処理される請求詳細記録（ＣＤＲ）を生成してもよい。さらに別の例として、管理規則により、管理サーバ１０２が前払いの課金システムまたは他の手段（たとえば、Ｐａｙｐａｌサービスやクレジットカードなど）とやり取りするように構成されてもよい。さらに別の例として、アプリケーションレジストリ１０４とアイデンティティレジストリ１０６の一方または他方に含まれる管理規則によって、特定のＡｐｐＩＤの関連付けられたＡ２Ａ対応アプリケーションが一定のサービス品質で提供され、ユーザの同一性に関わらず、一定の料金が請求されるべきであることを定めてもよい。たとえば、緊急医療サービスの提供に含まれるアプリケーションがネットワークを介した通信において最優先で提供されてもよく、また、割増料金で提供されてもよい。

図２Ａは、いくつかの実施形態において、図１のシステム１００の複数の端末装置のアプリケーション間のメディア通信を初期化する信号フロープロトコルを例示する図である。システム１００は、第１端末装置２０２−１と、第２端末装置２０２−２と、通信ネットワーク２０８を備える。第１端末装置２０２−１は、アプリケーションに関連付けられた機能を実行するために第１端末２０２−１を構成するＡ２Ａ対応アプリケーション２０４−１の第１インスタンスでコード化されたコンピュータ読み取り可能な持続性記憶媒体を含む。第２端末装置２０２−２は、同じアプリケーションに関連付けられた機能を実行するために第２端末２０２−２を構成するＡ２Ａ対応アプリケーション２０４−２の第２インスタンスでコード化されたコンピュータ読み取り可能な持続性記憶媒体を含む。

本明細書で使用する「アプリケーション」という用語は、ユーザインターフェースを有し、メディア通信機能（たとえば、ＶＯＩＰ、映像、ピアツーピアパケットデータ通信、ファイル転送、チャットなど）を有するアプリケーションを指す。さらに、「アプリケーション」という用語は、例示的かつ非限定的に、スタンドアロンアプリケーションを含むように解釈され、複数のファイルとシステム設定、システムソフトウェア、ランタイムライブラリ、またはプラグインまたは拡張（たとえば、ブラウザプラグイン）に関連付けられていてもよい。本明細書における目的のために、アプリケーションは、ユーザインターフェースを生成する実行可能なファイルまたはファイルグループである。第１および第２のＡ２Ａ対応アプリケーションの両者が起動されると、両端末装置が同一のＡ２Ａ対応アプリケーションを実行するように構成される。第１装置２０２−１はＡ２Ａ通信エンジン２０６−１の第１インスタンスを実行するように構成され、第２装置２０２−２はＡ２Ａ通信エンジン２０６−２の第２インスタンスを実行するように構成される。

口語的にネットワーク「クラウド」と称されることがあるネットワーク２０８のＩＭＳ実装には、複数のＳＩＰプロキシサーバ２１０（１つが示される）とＡ２Ａアプリケーション管理サーバ１０２が含まれる。「ＳＩＰ」という用語は、セッション初期化プロトコルを意味する。「セッション」という用語は、通信する１つ以上の送信側および受信側のセットと、通信の間それらの送信側および受信側に保存されている状態を意味する。開示されている実施形態ではＳＩＰメッセージが使用されているが、スカイププロトコルなど他のメッセージプロトコル、ジングル（音声用）などのＸＭＰＰ拡張、およびピアツーピア通信を確立するための他の一般的なプロトコルを代わりに使用してもよい。「サーバ」は、たとえばコンピュータなどの機器であり、他の機器に対して情報や経路サービスを提供するように構成される。サーバへのアクセスを要求する機器（コンピュータまたはスマートホン）は機器のクライアントとみなされる。

ネットワーク２０８は、典型的には基幹機器間で信号を伝達するが、セッションの間にデータ通信のための固定されたパスは構成せず、端末装置における状態は維持される。セッションの例としては、インターネット電話、マルチメディア配信、マルチメディア会議、分散型コンピュータゲームなどが挙げられる。ＳＩＰはインターネットモデルに適合する終端間信号プロトコルであり、ＳＩＰメッセージの経路を除くすべてのロジックは端末装置に格納されている。ＳＩＰプロキシサーバ２１０は、たとえば、被招待装置の現位置、承認、課金などの要素に応じて招待装置から被招待装置に送信される招待案内の経路を決定する。実際には、被招待装置の実際のネットワーク位置を認知しているＳＩＰが見つかるまで、招待装置により発信されたセッション招待案内は複数のＳＩＰプロキシサーバ２１０（１つが示されている）をしばしば通過する。そして、被招待装置はセッション招待案内を受諾あるいは拒否できる。

さらに、携帯ネットワーク２０８の詳細は、使用されるアクセス技術によって変化する。さらに、ＳＩＰセッションの確立には、様々なネットワーク機器間の通信が含まれてもよい。たとえば、ＳＩＰセッションの確立には、さらに、レジストラサーバ（不図示）との通信と、ユーザからの登録を受信し、それらの現在位置（たとえば、ＩＰアドレス、ポート、およびユーザ名）に関する情報を抽出し、ＳＩＰサーバがアクセス可能な位置データベースのその情報を格納するＳＩＰ主体とが含まれてもよい。また、ＳＩＰセッションの確立には、要求を受信し、レジストラによって生成された位置データベース内で要求の意図された受領側を検索し、特定のユーザの現在位置のリストを含む返信を送り返すリダイレクトサーバ（不図示）との通信が含まれてもよい。このように、ネットワーク２０８は、多数のプロキシサーバ、リダイレクトサーバ、レジストラサーバ、および無線・電話通信・インターネット通信の使用される他の基幹機器を含んでもよい。しかし、本明細書における不要な複雑さを避けるために、ＳＩＰセッションの確立に含まれるネットワーク２０８の動作はプロキシサーバ２１０によって説明されるものとする。

図２Ａは、Ａ２Ａアプリケーション２０４−１，２０４−２の第１および第２イスタンス間の通信セッションの確立に含まれるシステム１００の機器間の通信の複数の通信ステージＳ０−Ｓ５を示す。第１端末装置２０２−１と第２端末装置２０２−２間の通信の確立には、ネットワーク２０８を介して信号を送信することが含まれる。上述のように、ＳＩＰプロキシサーバ２１０は、招待端末機器から被招待端末機器にセッション招待案内を送るために使用される。図２Ａの信号フローの例において、第１端末装置２０２−１を招待装置とし、第２端末装置２０２−２を被招待装置とする。セッションの確立には、他のメッセージ伝達が追加されてもよい。しかし、そのような追加可能なメッセージ伝達の詳細は、本発明において重要ではなく当業者には容易に理解されるものである。したがって、本明細書での説明は省略する。

ステージＳ０において、第２端末装置２０２−２のＡ２Ａ対応アプリケーション２０４−２の第２インスタンスとのメディアセッションを確立するために、第１端末装置２０２−１のＡ２Ａ対応アプリケーション２０４−１の第１インスタンスは装置２０２−１が要求２１２をＡ２Ａ通信エンジン２０６−１の第１インスタンスに送信するように構成する。以下に詳細に説明するように、Ａ２Ａエンジン２０６−１とＡ２Ａエンジン２０６−２はＡ２Ａ対応アプリケーションインスタンス２０４−１、２０４−２、および各通信プロトコルスタックの間のインターフェースとして動作する。いくつかの実施形態では、要求２１２は、第１装置２０２−１で動いているＡ２Ａ通信エンジン２０６−１の第１インスタンスへのメソッド呼出しを含む。いくつかの実施形態では、メソッド呼出しは、Ｃ、Ｃ＋＋、Ｊａｖａ、または他の一般的なプログラム言語またはスクリプト言語による手続き呼出しを含んでもよい。また、メソッド呼出しは、ＡＩＤＬ、ＲＭＩ、ＣＯＲＢＡ、または他の仕組みを使用した別のプロセスに対する、パイプ、キュー、ソケット、または他の遠隔手続き呼出しなどの利用可能な仕組みを使用したメッセージを含んでもよい。

図３は、メソッド呼出し要求２１２の例のデータ構成内のフィールドを例示する図である。ＳＩＰユーアールアイ（ＵＲＩ）フィールドは、被招待装置２０２−２を特定する。ＡｐｐＩＤフィールドは、要求アプリケーションを特定する。構成によっては、セキュリティ情報フィールドは、セキュリティのために使用されるトークン情報やトークンを生成するために使用される秘密情報を含んでもよい。また、発せられた要求は、たとえば、音声、映像、ファイル転送、チャット、グループチャット、リアルタイムピアツーピアデータ転送、アプリケーション配置などの１種類以上のメディアを含む、要求されたメディアセッションなどの追加情報を含んでもよい。

ステージＳ１において、Ａ２Ａ通信エンジン２０６−１の第１インスタンスは、要求２１２を端末ネットワーク２０８内でＳＩＰプロキシサーバ２１０への送信に適したＳＩＰ招待メッセージ２１４に変換するインターフェースとして動作するように、第１端末装置２０２−１を構成する。上述のように、実際の送信は、たとえば、いくつかの異なるプロキシ間の往来、また場合によっては、ネットワーク２０８内のレジストラサーバ（不図示）やリダイレクトサーバ（不図示）の使用を含んでもよい。ＳＩＰメッセージ２１４の例は、第１識別子（たとえば、第１ＳＩＰ−ＵＲＩ）を有する第１端末装置から第２識別子（たとえば、第２ＳＩＰ−ＵＲＩ）を有する第２端末装置への招待を含む。

図４は、ＳＩＰメッセージ２１４の例の構成内のヘッダフィールドを例示する図である。「発信元」および「宛先」のアドレスフィールドは、それぞれ第１ＳＩＰ−ＵＲＩおよび第２ＳＩＰ−ＵＲＩを示す。サービスタグのフィールドは、通信タイプを「Ａｐｐ２Ａｐｐ（すなわち、アプリケーション間）」として示す。ＡｐｐＩＤフィールドは、通信セッションを介してアプリケーションの固有なタイプを特定し追跡するパラメータとして動作するグローバルに固有な識別子を提供する。いくつかの実施形態では、オプションセキュリティ情報フィールドは、メッセージを認証するために使用されるセキュリティトークンを含む。ＳＤＰフィールドは、セッション中のネゴシエーションメディア送信に使用される情報を提供する。この例では、メディアは、たとえばＨ２６４フォーマットを使用し特定のビットレート（不図示）を有する映像メディアを含む。

ステージＳ２において、メッセージがＡｐｐＩＤに関連付けられたＡ２Ａ対応アプリケーションによる要求を含むことを示すサービスタグに応じて、ＳＩＰプロキシサーバ２１０はメディアセッション要求を評価するＡ２Ａアプリケーションマネージャ１０２にメッセージ２１６を送信する。さらに詳しくは、いくつかの実施形態では、サービスタグは、プロキシサーバ２１０に対する、要求を第２端末装置２０２−２に転送する前に承認要求２１６をアプリケーション管理サーバ１０２に送信する命令として動作する。このように、要求２１４には、要求２１６を生成する命令が埋め込まれている。いくつかの実施形態では、メッセージ２１６は、図４に示され参照して説明されるヘッダ情報を含む。たとえば、特定の装置やユーザに対する、セキュリティ情報の確認、使用統計の生成、メディアセッション課金のトリガー、またはセキュリティエラーまたはＡｐｐＩＤのブラックリストによりメディアセッション要求が拒絶されるべきか否かの判定などの１つ以上の機能を実行するために、メッセージ２１６に応じて、Ａ２Ａアプリケーションマネージャ１０２は、図１Ｂから図１Ｅにより説明した第１および第２のプロセスを実行する。Ａ２Ａ対応メッセージを示すサービスタグが実質的に含まれることにより、プロキシサーバ２１０がメディア接続を確立するためにアプリケーションマネージャに対して承認を要求することになる。このように、第２端末装置２０２−２で動いているＡ２Ａ対応アプリケーション２０４−２の第２インスタンスとのメディア接続を確立する要求と、アプリケーション管理サーバ１０２に対するＳＩＰメッセージに含まれたＡｐｐＩＤを有するＡ２Ａアプリケーションの承認の要求とが、両者ともＳＩＰ招待２１４に埋め込まれている。

ステージＳ３において、メッセージ２１６および上述のＡ２Ａアプリケーションマネージャ動作の完了に応じて、Ａ２Ａアプリケーションマネージャ１０２は、要求されたサービス、Ａ２Ａサービス、およびＡｐｐＩＤの端末装置２０２−１、２０２−２に対する送受信を特定するとともに要求されたメディアセッションが受諾されるべきか拒絶されるべきかを示すメッセージ２１８を、プロキシサーバ２１０に送信する。いくつかの実施形態では、Ａ２Ａアプリケーションマネージャ１０２は、承認と判定されるＳＩＰメッセージ／要求をネットワーク２０８を介して第２端末装置２０２−２に転送する。要求が拒絶された場合には、Ａ２Ａアプリケーションマネージャ１０２は、要求を発した第１端末装置２０２−１に拒絶通知を送信する。ステージＳ４において、プロキシサーバ２１０は、図４の構成中の情報を含むメッセージ２２０を第２端末装置２０２−２で動いているＡ２Ａ通信エンジン２０６−２の第２インスタンスに送信する。Ａ２Ａ通信エンジン２０６−２は、メッセージ２２０中のＡｐｐＩＤに対応するアプリケーションのインスタンスが第２端末装置２０２−２にインストール済で動いているかどうかを判定する。いくつかの実施形態では、アプリケーション２０４−２のインスタンスがすでにインストール済であるが動いていない場合には、Ａ２Ａ通信エンジン２０６−２はアプリケーションを起動する。

アプリケーション２０４−２のインスタンスがインストールされていない場合、一般的には、Ａ２Ａ通信エンジン２０６−２は、端末装置２０２−２要求されたアプリケーション２０４−２のインスタンスをインストールしたか否かについての事前情報を得ることになる。しかし、いくつかの実施形態では、アプリケーションがインストールされていない場合には、Ａ２Ａ通信エンジン２０６−２は自動的に招待を拒絶する。また、いくつかの実施形態では、Ａ２Ａ通信エンジン２０６−２は、第２端末装置２０２−２に対して、失敗した招待のＡｐｐＩＤを使用して、不足しているアプリケーションのダウンロードリンクなどのメタデータが得られるアプリケーションレジストリ１０４でアプリケーションを検索して、不足しているアプリケーションをダウンロードするように促す。いくつかの実施形態では、第２端末装置２０２−２のユーザインターフェースが、装置のユーザに対して失敗した招待を示し、不足しているアプリケーションの取得方法についての情報を提供する。たとえば、「「ａｂｃ」という名称（ＡｐｐＩＤとは異なってもよい）のアプリケーションの実施の招待／申込みに失敗しました。ここをクリックしてダウンロードしてください。」のようなメッセージが提供されてもよい。

ステージＳ５において、アプリケーションがインストール済で動いている（起動している）と仮定すると、Ａ２Ａ通信エンジン２０６−２は、図４の構成内の情報を含むメッセージ２２２を第２端末装置２０２−２で動いているアプリケーション２０４−２の第２インスタンスに送信する。いくつかの実施形態では、第２端末装置のプラットフォームおよび／またはプログラム言語によっては、メッセージ２２２は、たとえば、コールバック／イベント装置、手続き呼出し、またはプロセス間通信のための他のプラットフォームに特定の手段（たとえば、アンドロイドプラットフォームの「インテント」）を介して配信されてもよい。一般的には、いくつかの実施形態では、メッセージはＳＩＰプロトコルレベルで認識される（ＡＣＫおよびＯＫメッセージ）。適用可能な場合には、タイムアウトもメッセージに関連付けられる（たとえば、ＩＮＶＩＴＥ）。ＳＩＰプロトコルによって、たとえば、「ＶＩＡ」ヘッダが、招待端末装置２０２−１にたどり着くために往来するネットワークノードを示すために使用されてもよい。タイムアウトの場合には、被招待装置２０２−２による積極的な招待拒絶とは対照的に、招待装置２０２−１は、被招待装置２０２−２が招待の受諾に失敗したと認識する。

図２Ｂは、いくつかの実施形態における代替システム１６０の例示的な図である。代替システム１６０の機器は、図１Ａから図２Ａを用いて説明したものと実質的に同一である。以下、システム１００とシステム１６０の違いを説明する。具体的には、Ａ２Ａエンジン２０６−１’は、現在承認済のＡ２Ａ対応アプリケーションのＡｐｐＩＤの表示を周期的に要求するように構成される。具体的には、Ａ２Ａエンジン２０６−１’は、装置２０２−１’の現在登録済のアプリケーションのＡｐｐＩＤ承認を周期的に要求する。Ａ２Ａエンジン２０６−１’は、承認済Ａ２Ａ対応アプリケーションを示すローカル端末装置アプリケーションレジストリ１６２を維持する。関連付けられたＡｐｐＩＤを有するＡ２Ａ対応アプリケーションからの、メディアセッション確立の要求に応じて、Ａ２Ａエンジンが、レジストリ１６２の内容に基づいてＡ２Ａ対応アプリケーション２０４−１’がそのＡｐｐＩＤに基づいて承認されるか否かを決定する。このように、図２の信号フローにおけるステージＳ２とＳ３を回避することができる。第１端末装置２０２−１’は、ネットワーク（不図示）を介してＳＩＰ招待１６４を送信することができる。また、第２端末装置２０２−２’は、通信セッション確立の過程でマネージャ１０２に問い合わせる必要なしに、ネットワークを介してＳＩＰ応答１６６を送信ことができる。

図５は、メディア通信の初期化が成功し、第１および第２の端末装置２０１−１、２０２−２の間でメディアデータを送信するために通信プロトコルスタック５３０−１、５３０−２が使用される、図２Ａのシステム１００の例示的な図である。通信プロトコルスタック５３０−１、５３０−２はいずれも階層プロトコルスタックである。一般的に、ネットワークプロトコルは、ネットワーク機能が層に分割されるように階層化されている。プロトコルスタックにおいて、各層は、下層のサービスに依存する明確なサービスを実行し、上層にサービスを提供する。一般に、通信プロトコルは、スタック内の１つの層で通信サービスを提供するソフトウェアシステムを規定するために使用される。結果として生じる階層化プロトコルは、プロトコルスタックと呼ばれる。プロトコルスタックは、複数のプロトコルを含むネットワーク機能を規定する。さらに詳細には、プロトコルスタック層は、持続性媒体にコード化された命令を有し、端末装置２０２−１、２０２−２およびネットワーク２０８の機器にプロトコル層によって規定されたネットワーク機構を実行させる。

いくつかの実施形態では、第１および第２の通信プロトコルスタック５３０−１，５３０−２は、ＩＭＳネットワークアーキテクチャに準拠する。ＩＭＳプロトコルスタックは、異なる標準またはＲＦＣ（コメント要求）によって規定された異なるプロトコルを異なる層に有している。ＩＭＳネットワークアーキテクチャにおいて、典型的には、ＳＩＰは、ＲＴＰ（リアルタイム転送プロトコル）とＳＤＰ（セッション記述プロトコル）を含んで、ＩＭＳ準拠の通信プロトコルスタックの一部である他のいくつかのプロトコルと連動して使用される。典型的には、ＲＴＰは、リアルタイムマルチメディアデータ（たとえば、音声、映像共有、チャット、ファイル共有、ＸＭＰＰ準拠プロトコルおよび拡張（たとえば、ＩＰを介した音声サービスのジングル）、およびその他ピアツーピアリアルタイム通信の仕組み）をコード化してパケットに分割し、パケットをインターネットを介して転送するように使用される。典型的には、ＳＤＰは、セッション参加メンバーの能力を記述しコード化するように使用される。このような記述は、メディアをコード化するコーデックや使用する転送プロトコルなど、セッションの特徴を取り決めるために使用できる。その結果、すべての装置がセッションに参加できるようになる。もちろん、異なる特定の使用のために異なるプロトコルのオプションを使用することをＩＭＳネットワークアーキテクチャが指定してもよい。

図５は、図２Ａの通信プロトコルに従ってセッションの初期化成功後に第１および第２の端末装置２０２−１、２０２−２の間に１つ以上の通信セッション５３２が確立されていることを示す。また、図５は、通信セッション５３２が同一のプロトコルスタックインスタンス５３０−１，５３０−２によって特定されたプロトコルに従ってネットワーク２０８を介してデータを転送することも示す。以下の詳細に説明するように、Ａ２Ａエンジンインスタンス２０６−１、２０６−２は、インターフェースとして動作し、（１）Ａ２Ａ対応アプリケーションインスタンス２０４−１，２０４−２から受信したメソッド呼出し要求やメッセージを、ネットワーク２０８で使用可能な形式に変換し、（２）ネットワーク２０８から受信したネットワークパケットやフレームをＡ２Ａ対応アプリケーションインスタンス２０４−１、２０４−２が使用可能な形式に変換し、（３）各アプリケーションインスタンス２０４−１、２０４−２およびプロトコルスタックインスタンス５３０−１、５３０−２の間のセッション５３２中に、制御データとメディアデータをネットワーク２０８を介して送信する。

図６は、図５のメディアセッション５３２の詳細を例示し、メディアセッションに関連付けられた異なるポート例を示す図である。例示されたメディアセッション５３２は、第１装置２０２−１と第２装置２０２−２の間で確立された２つの通信セッション、すなわち、メディア制御信号セッション６０２とメディア（たとえば、映像）セッション６０４を実際に含んでいる。制御信号セッション６０２は、メディアセッション６０４を確立しメディアセッション６０４によるメディア配信を制御するために使用されるＳＩＰメッセージの通信に使用される。図示された例では、メディアセッション６０４によって映像データが装置間で転送される。制御セッション６０２と映像セッション６０４のいずれも、フレーム構造６０６，６０８で情報を送信する。制御セッション６０２のフレーム構造６０６はＡｐｐＩＤ情報を含む。このＡｐｐＩＤ情報は、第１および第２のアプリケーションインスタンス２０４−１、２０４−２により共有される固有のグローバルな識別子として機能し、メディアセッション６０４が関連するＡ２Ａ対応アプリケーション２０４−１，２０４−２を示す。

セッション６０２、６０４は、多少ともソフトウェアポート番号に基づいた共有ＡｐｐＩＤに基づいて、Ａ２Ａアプリケーションインスタンス２０４−１、２０４−２に関連付けられている。このように、ポートは、事前に特定のアプリケーションに割り当てられる必要はなく、可用性などの要因に基づいてメディアセッションに関連付けられてもよい。セッション６０２、６０４は、第１および第２の装置２０２−１、２０２−２の異なるソフトウェアポートの関連付けられてもよい。この例では、メディア制御信号セッション６０２は、第１装置２０２−１のＮＸポートおよび第２装置２０２−２のＮＭポートに関連付けられている。メディアセッション６０４は、第１装置２０２−１のＮＺポートおよび第２装置２０２−２のＮＱポートに関連付けられている。

図７は、いくつかの実施形態において、図２Ａの通信プロトコルに従ってセッション６０２、６０４の初期化成功後に第１および第２の端末装置２０２−１、２０２−２内に１つ以上のデータバッファが割り当てられていることを示すシステム１００の例示的な図である。図示された例では、第１装置２０２−１の持続性記憶媒体内に割り当てられた第１バッファ７０２−１は、共有ＡｐｐＩＤのラベルが付けられ、制御セッション６０２を使用して通信される制御データを一時的に保存する。第２装置２０２−２の持続性記憶媒体に割り当てられた対応する第２バッファ７０２−２は、共有ＡｐｐＩＤのラベルが付けられ、制御セッション６０２を使用して通信される制御データを一時的に保存する。

動作中、それぞれのバッファ７０２−１、７０２−２によって受信された制御情報は、それぞれの通信スタック５３０−１、５３０−２に従って処理される。通信スタック５３０−１、５３０−２は、処理した制御情報をそれぞれのＡ２Ａエンジンに通知する。第１および第２のＡ２Ａエンジン２０６−１、２０６−２は、バッファ７０２−１、７０２−２内の情報にアクセスし、ネットワーク２０８を介して使用されバッファ７０２−１、７０２−２に格納される形式とＡ２Ａアプリケーション２０４−１、２０４−２の第１および第２のインスタンスが理解可能な形式との間における制御信号メッセージの変換を実行するそれぞれのインターフェースとして動作する。また、第１および第２のＡ２Ａエンジン２０６−１、２０６−２は、変換された制御メッセージをＡｐｐＩＤに基づいて第１および第２バッファ７０２−１，７０２−２と適切なアプリケーションインスタンス２０４−１、２０４−２の間で転送するようにＡｐｐＩＤを使用するそれぞれのインターフェースとしても動作する。

同様に、第１装置２０２−１の持続性記憶媒体内に割り当てられた第３バッファ７０４−１は、共有ＡｐｐＩＤのラベルが付けられ、メディアセッション６０４を使用して通信されるメディアデータを一時的に保存する。第２装置２０２−２の持続性記憶媒体に割り当てられた対応する第４バッファ７０４−２は、共有ＡｐｐＩＤのラベルが付けられ、メディアセッション６０４を使用して通信されるメディアデータを一時的に保存する。いくつかの実施形態では、Ａ２Ａエンジンインスタンス２０６−１、２０６−２は、装置オペレーティングシステム７０８−１、７０８−２のアクセス可能なポートと装置２０２−１、２０２−２で動いているそれぞれのＡ２Ａアプリケーション２０４−１、２０４−２との間にそれぞれのメディア通信チャネル７０６−１、７０６−２を提供するようにそれぞれの端末装置２０２−１、２０２−２を構成するように動作する。これらのメディア通信チャネル７０６−１、７０６−２は、メディアデータ（たとえば、映像データ）のより高速な通信を可能にする。典型的には、Ａ２Ａ対応アプリケーションは、概してバックグラウンドプロセスとして指定される通信スタック関連プロセスよりも多くのプロセッササイクルに割り当てられるフォアグラウンドプロセスとして、オペレーティングシステムによって指定される。さらに、メディア通信チャネルによって、Ａ２Ａエンジン２０６−１、２０６−２を経由することなく、メディアセッション６０４につながるそれぞれのオペレーティングシステムレベルのポートとＡ２Ａアプリケーション２０４−１、２０４−２の第１および第２インスタンスとの間をメディアが往来することができる。その結果として、通信スタック関連プロセスとＡ２Ａ対応アプリケーションとの間でメディアデータを転送するためのプロセス間通信が不要となる。

図８は、いくつかの実施形態において、Ａ２Ａ対応アプリケーションがメディアセッションを用いるプロセスを例示するフローチャートである。プロセス８００は、Ａ２Ａ対応アプリケーション２０４−１、２０４−２の第１および第２のインスタンスのいずれにも適用可能である。モジュール８０２において、図２Ａの信号プロトコルに従ってメディアセッションを確立するように、対応するＡ２Ａエンジン２０６−１、２０６−２に要求が発せられる。たとえば、ユーザは、特定のＡ２Ａアプリケーションのインスタンスが動いている装置の他のユーザ（たとえば、友人または知人）を特定するように、端末装置２０２−１に要求を入力し、そして、Ａ２Ａアプリケーションを介した通信に参加するように１人以上の他のユーザを招待する要求を装置２０２−１に入力してもよい。たとえば、Ａ２Ａアプリケーションは、映像メディア、音声メディア、およびゲームデータを含むゲームアプリケーションであってよい。いくつかの実施形態では、そのような要求は、要求しているＡ２Ａ対応アプリケーションで内部的に生成されるトークンを含む。他の実施形態では、対応するＡ２Ａエンジンがトークンを生成できるように、要求がＡ２Ａ対応アプリケーションに関連付けられた秘密情報を含んでいてもよい。判定モジュール８０４において、メディアセッションが初期化に成功したか否かを判定する。失敗した場合には、モジュール８０６において、メディアセッション初期化の失敗が報告される。判定モジュール８０８において、Ａ２Ａ対応アプリケーションが、他の装置で動いているＡ２Ａ対応アプリケーションの対応するインスタンスにメディアデータを送信するか否かを判定する。送信する場合には、モジュール８１０において、アプリケーションのＡｐｐＩＤとともにメディアデータがＡ２Ａエンジンに提供される。送信しない場合には、判定８１２において、メディアデータがすでにＡ２Ａエンジンに提供されているか否かを判定する。提供されている場合には、モジュール８１４において、メディアデータをＡ２Ａエンジンから回収する。提供されていない場合には、制御は判定モジュール８０８に戻る。さらに、各モジュール８１０、８１４に続いて、制御は判定モジュール８０８に戻る。

図９は、いくつかの実施形態において、Ａ２ＡエンジンがＡ２Ａ対応アプリケーションおよび通信プロトコルスタックと相互作用するプロセス９００を例示する図である。プロセス９００は、Ａ２Ａエンジン２０６−１、２０６−２の第１および第２のインスタンスのいずれにも適用可能である。モジュール９０２において、アプリケーションのＡｐｐＩＤを特定するＡ２Ａ対応アプリケーションからの要求が受信される。上述のように、いくつかの実施形態では、そのような要求は、要求しているＡ２Ａ対応アプリケーションで内部的に生成されるトークンを含む。他の実施形態では、対応するＡ２Ａエンジンがトークンを生成できるように、要求がＡ２Ａ対応アプリケーションに関連付けられた秘密情報を含んでいてもよい。アプリケーションからの要求に応じて、モジュール９０２において、ＡｐｐＩＤ、セキュリティ（すなわち、ＡｐｐＩＤと秘密キーの機能として生成されるトークン）、およびメディア形式を含むＳＩＰ要求が生成され、図２Ａと図５に従って説明したように、そのＳＩＰ要求が通信プロトコルスタックに転送される。図２Ａに従って説明したように、いくつかの実施形態では、メディアセッションを確立するために異なる端末装置で動いているアプリケーションの別のインスタンスに要求を送信する前提条件としてＡ２Ａアプリケーションマネージャ１０２から承認を得るために、ＳＩＰ要求により、ネットワーク上の１つ以上のプロキシサーバからＡ２Ａアプリケーションマネージャ１０２にメッセージが送信される。モジュール９０４では、メディアセッションの初期化が成功したか失敗したかが、要求しているＡ２Ａ対応アプリケーションに報告される。初期化に失敗した場合には、判定モジュール９０６によりプロセスが終了する。初期化が成功した場合には、制御は判定モジュール９０６からモジュール９０８に進む。ここでは、オペレーティングシステム（７０８−１または７０８−２）により、メディアバッファ（７０４−１または７０４−２）が割り当てられ、メディアバッファを使用するＡ２Ａ対応アプリケーション（２０４−１または２０４−２）に直結する通信ルートが生成される。いくつかの実施形態では、一旦通信ルートが確立されると、Ａ２Ａエンジンは、Ａ２Ａアプリケーションとの間のメディア転送に関して更なる役割を有しない。モジュール９０８において、通信プロトコルスタックにより開放された制御バッファ（たとえば、バッファ７０２−１または７０２−２）が決定される。

判定モジュール９１０と９１４は並行して動作する。判定モジュール９１０において、通信スタックに配信するために、ＡｐｐＩＤに関連付けられた制御情報がＡ２Ａ対応アプリケーションにより提供されているか否かが判定される。提供されている場合には、モジュール９１２において、制御情報はプロトコルスタックの使用に適した形式に変換され、制御バッファに供給するために、Ａ２Ａ対応アプリケーションから受信したＡｐｐＩＤヘッダ情報に関連付けられた変換済制御情報が通信スタックに提供される。提供されていない場合には、制御は判定モジュール９１０に戻り、制御情報がＡ２Ａ対応アプリケーションにより提供されているか否かの判定を継続する。

判定モジュール９１４において、Ａ２Ａ対応アプリケーションに配信するために、関連付けられたＡｐｐＩＤヘッダ情報とともに制御情報が通信プロトコルスタックによって制御データバッファに提供されているか否かが判定される。提供されている場合には、モジュール９１６において、受信した制御情報が変換され、その制御情報は提供された制御情報に含まれているＡｐｐＩＤと同一のＡｐｐＩＤを有するＡ２Ａ対応アプリケーションに送信される。提供されていない場合には、判定モジュール９１４に戻り、制御情報が通信スタックにより提供されているか否かの判断を継続する。

図示された例においては、各端末装置では単一のＡ２Ａ対応アプリケーションのみが動いている。しかし、当然ながら、各端末装置で複数のＡ２Ａ対応アプリケーションが動くことも可能である。各Ａ２Ａ対応アプリケーションは、固有のＡｐｐＩＤを有している。Ａ２Ａエンジンは、通信スタックからＡｐｐＩＤに基づいて異なるＡ２Ａ対応アプリケーション制御メッセージを送信する。また、単一の制御セッションにより複数の異なるＡ２Ａ対応アプリケーションのためのメディアセッションが制御可能であることも理解される。それぞれの異なるＡ２Ａ対応アプリケーションのために、制御セッションがそのＡ２Ａ対応アプリケーション専用の１つ以上のメディアセッションを確立する。制御セッションを介して通信された情報のフレームまたはパケットは、フレームまたはパケット内に含まれたＡｐｐＩＤに基づいて異なるＡ２Ａ対応アプリケーションに送信される。さらに、本明細書における例では、同一のＡｐｐＩＤを有する２つのＡ２Ａアプリケーション間での通信について説明しているが、異なるＡｐｐＩＤを有する２つのＡ２Ａ対応アプリケーション間で通信を確立してもよい。

ハードウェアの構成例
図１０は、本明細書に記載される１つ以上の手順をコンピュータに実行させるように、命令セットが実行される端末装置として動作するコンピュータ処理システムのブロック図である。例示の処理システム１０００は、プロセッサ１００２（たとえば、中央演算装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、またはその両者）と、バス１００８を介して互いに通信する持続性メイン記憶媒体１００４および持続性スタティック記憶媒体１００６を備える。さらに、コンピュータ処理システム１０００は、映像ディスプレイ装置１０１０（たとえば、プラズマディスプレイ、液晶ディスプレイ（ＬＣＤ）、またはブラウン管（ＣＲＴ））を備えてもよい。また、処理システム１０００は、英数字入力装置１０１２（たとえば、キーボード）と、ユーザインターフェース（ＵＩ）ナビゲーション装置１０１４（たとえば、マウス、タッチスクリーンなど）と、ディスクドライブユニット１０１６と、信号発生装置１０１８（たとえば、スピーカ）と、ネットワークインターフェース装置１０２０とを備える。

ディスクドライブユニット１０１６は、本明細書に記載される１つ以上の手順や機能を実施または利用する１セット以上の命令とデータ構造（たとえば、ソフトウェア１０２４）が格納されたコンピュータ読み取り可能な持続性記憶装置１０２２を備える。ソフトウェア１０２４は、全体または少なくとも一部が、持続性メイン記憶装置１００４などのコンピュータ読み取り可能な記憶装置の内部、および／または、処理システム１１００、持続性メイン記憶装置１００４、およびコンピュータ読み取り可能で理解可能な媒体をも構成するプロセッサ１００２により実行中のプロセッサ１００２の内部に存在していてもよい。

さらに、ソフトウェア１０２４は、多数の周知の転送プロトコル（たとえば、ＨＴＴＰ）のいずれか１つを利用するネットワークインターフェース装置１０２０によりネットワーク１１２６を介して送受信されてもよい。

コンピュータ読み取り可能な記憶装置１０２２は、実施例では単一のメディアとして示されているが、「コンピュータ読み取り可能な記憶装置」という用語は、１セット以上の命令を格納する単一または複数の媒体（たとえば、集中型または分散型のデータベース、および／または関連するキャッシュおよびサーバ）を含むものとする。また、「コンピュータ読み取り可能な記憶装置」という用語は、コンピュータによる実行のための１セット以上の命令を格納し、コード化し、保持することが可能であって、現アプリケーションの１つ以上の手順をコンピュータに実行させる媒体、またはそのような命令セットに利用されるか関連づけられるデータ構造を格納し、コード化し、保存することが可能である媒体を含むものとする。したがって、「コンピュータ読み取り可能な記憶装置」という用語は、ソリッドステートメモリや光学および磁気媒体を含むが、これらに限定されるものではない。

本明細書において単一の例として説明されている要素、動作、または構成には、複数の例が採用されてもよい。最後に、様々な要素、動作、およびデータ保存の間の境界は多少任意的であり、特定の動作は特定の例示的な構成との関連で例示される。機能の他の配分も構想されるが、それらも本発明の権利範囲に含まれるであろう。一般的に、典型的な構成において別々の要素として達成される構成や機能は、組み合わされた構成や要素として実行されてもよい。同様に、単一の要素によって達成される構成や機能は別々の要素として実行されてもよい。上記および他の変更、修正、追加、および改良は、本発明の権利範囲に属するものとする。

したがって、上記の実施形態の説明および図面は、単に本発明の原理を説明するためのものである。当業者によって、添付された特許請求の範囲に規定された本発明の精神および範囲からはずれることなく、上記実施形態に対して様々な修正が可能である。

Claims (25)

1. ネットワークを介してメディア情報を通信する方法であって、
   第１端末装置で動いている第１アプリケーションからの、第２端末装置で動いている第２アプリケーションとのメディア接続要求に応じて、前記第１アプリケーションに関連付けられたアプリケーション識別子(ＡｐｐＩＤ)と秘密情報を含んだ要求であって、前記第２アプリケーションとのメディア接続要求をネットワークを介して送信する工程と、
   前記第１アプリケーションにより生成された前記メディア接続要求は、少なくとも部分的には前記ＡｐｐＩＤおよび前記第１アプリケーションに関連付けられた秘密情報に基づいて前記第１アプリケーションにより生成されたトークンを含み、
   前記第１アプリケーションによる前記要求に応じて、前記第１アプリケーションに関連付けられた前記ＡｐｐＩＤを含んだ要求であって、
   前記要求されたメディア接続の承認を得る承認要求を前記ネットワークを介してアプリケーション管理サーバに送信する工程と、
   前記メディア接続要求は前記トークン情報を含んだ前記承認要求を送信するためのプロキシサーバへの指示を含み、
   前記メディア接続要求に応じて、前記第１アプリケーションに関連付けられた前記ＡｐｐＩＤを含んだ制御情報であって、前記第１端末装置と前記第２端末装置との間に確立された制御セッションを介して制御情報を通信する工程と、
   前記メディア接続要求に応じて、前記第１端末装置と前記第２端末装置との間に確立されたメディアセッションを介してメディア情報を通信する工程と、
   を含む方法。
2. 前記第１アプリケーションにより生成された前記メディア接続要求は前記ＡｐｐＩＤを含む、
   請求項１に記載の方法。
3. 前記第１アプリケーションにより生成された前記メディア接続要求が前記第１アプリケーションに関連付けられた秘密情報を含んでおり、
   少なくとも部分的には前記ＡｐｐＩＤおよび前記秘密情報に基づいてトークンを生成する工程をさらに含む、
   請求項１に記載の方法。
4. 前記承認要求は前記トークンを含む、
   請求項３に記載の方法。
5. 前記第１アプリケーションからの要求をセッション初期化プロトコル（ＳＩＰ）要求に変換する工程をさらに含み、
   メディア接続要求をネットワークを介して送信する前記工程は前記ＳＩＰ要求の送信を含む、
   請求項１に記載の方法。
6. 前記制御セッションを介して制御情報を送受信するためのバッファを前記第１端末装置に割り当てる工程をさらに含む、
   請求項１に記載の方法。
7. 前記メディアセッションを介してメディア情報を送受信するためのバッファを前記第１端末装置に割り当てる工程をさらに含む、
   請求項１に記載の方法。
8. 前記第１アプリケーションと前記第２アプリケーションは同一のアプリケーションの異なるインスタンスであり、同一のＡｐｐＩＤに関連付けられている、
   請求項１に記載の方法。
9. 前記承認要求を送信する工程は、前記メディア接続要求の送信に先立って行われ、
   さらに、前記承認要求に対する応答を受信する工程を含み、
   前記メディア接続要求を送信する工程は、前記承認要求に対する前記応答が前記第１アプリケーションが承認されたことを示す場合にのみ行われることを特徴とする、
   請求項１に記載の方法。
10. ネットワークを介して通信するアプリケーション間の通信を制御する方法であって、
    マルチメディア情報の配信に適したネットワークにつながっている端末装置で動くのに適したアプリケーション間（Ａ２Ａ）対応の多数のアプリケーションのそれぞれに異なるアプリケーション識別子（ＡｐｐＩＤ）を指定する工程と、
    承認済ＡｐｐＩＤを示すレジストリを持続性媒体に提供する工程と、
    前記ネットワークを介して、ＡｐｐＩＤと少なくとも前記ＡｐｐＩＤに対応した秘密情報として生成されたトークン情報を含み第１端末装置から発せられるメディア接続の承認要求を受信する工程と、
    前記承認要求に応じて、前記承認要求内の前記ＡｐｐＩＤと前記トークン情報を生成させるために使用され対応している前記秘密情報が前記レジストリ内に示される承認済ＡｐｐＩＤと承認済秘密情報に一致するか否かを判定する工程と、
    前記ＡｐｐＩＤと前記秘密情報が前記レジストリ内に示された前記承認済ＡｐｐＩＤと前記秘密情報に一致しないという判定に応じて、前記承認要求を拒絶する工程と、
    を含む方法。
11. 前記レジストリはそれぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれブラックリスト情報を示す、請求項１０に記載の方法であって、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記ＡｐｐＩＤに関連付けられたアプリケーションがブラックリストされていることを示すか否かを判定する工程と、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記アプリケーションがブラックリストされていることを示すという判定に応じて、前記承認要求を拒絶する工程と、
    をさらに含む方法。
12. 前記レジストリはそれぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれのメタデータを示し、前記承認要求はトークン情報とユーザ識別情報（ｕｓｅｒＩＤ）を含む、請求項１０に記載の方法であって、
    前記承認要求内の前記ｕｓｅｒＩＤに関連付けられたユーザプロフィール情報へのアクセスを提供する工程と、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記メタデータが、得られたプロフィールを有するユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていることを示すか否かを判定する工程と、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記メタデータが、前記得られたプロフィールを有する前記ユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていないことを示すという判定に応じて、前記承認要求を拒絶する工程と、
    をさらに含む方法。
13. 前記レジストリはそれぞれの承認済のアプリケーション識別子（ＡｐｐＩＤ）に関連付けられたそれぞれ秘密情報とブラックリスト情報を示し、前記承認要求はトークン情報を含む、請求項１０に記載の方法であって、
    それぞれの異なるＡｐｐＩＤに対してそれぞれ異なる秘密情報を指定する工程と、
    変換情報を生成するために、前記トークン情報を変換する工程と、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致するか否か、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記ＡｐｐＩＤに関連付けられたアプリケーションがブラックリストされていることを示すか否かの、少なくともいずれかを判定する工程と、
    前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致しないこと、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記アプリケーションがブラックリストされていることを示すことの、少なくともいずれかの判定に応じて、前記承認要求を拒絶する工程と、
    をさらに含む方法。
14. 前記承認要求を受信する工程は、前記ネットワークの一部であるプロキシサーバにより送信される承認要求の受信を含む、請求項１０に記載の方法。
15. 前記拒絶する工程は前記ネットワークの一部であるプロキシサーバへのメッセージの送
    信を含む、請求項１０に記載の方法。
16. ネットワークを介して通信するアプリケーション間の通信を制御するシステムであって、
    マルチメディア情報の配信に適したネットワークにつながっている端末装置で動くのに適したアプリケーション間（Ａ２Ａ）対応の多数のアプリケーションのそれぞれに異なるアプリケーション識別子（ＡｐｐＩＤ）と対応する秘密情報を指定する手段と、
    承認済ＡｐｐＩＤおよび前記対応する秘密情報を示すレジストリを有する持続性媒体を含むアプリケーション管理サーバとを含み、
    前記管理サーバは、第１端末装置から発せられるメディア接続要求の承認要求を前記ネットワークを介して受信するように構成され、
    前記承認要求はＡｐｐＩＤと少なくとも前記ＡｐｐＩＤに対応した秘密情報として生成されたトークン情報を含み、
    前記アプリケーション管理サーバは、前記承認要求の受信に応じて、前記承認要求内の前記ＡｐｐＩＤと前記トークンを生成させるために使用された対応する秘密情報が前記レジストリ内に示される承認済ＡｐｐＩＤと前記対応する秘密情報に一致するか否かを判定するように構成され、
    前記アプリケーション管理サーバは、前記ＡｐｐＩＤと前記トークン情報を生成させるために使用された対応する秘密情報が前記レジストリ内に示された承認済ＡｐｐＩＤと前記対応する秘密情報に一致しないという判定に応じて、前記承認要求を拒絶するように構成される、
    システム。
17. 前記指定手段は異なるアプリケーション識別子（ＡｐｐＩＤ）ごとにそれぞれ異なる秘密情報を指定し、
    前記レジストリは、それぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれの秘密情報を示し、
    前記承認要求はトークン情報を含み、
    前記アプリケーション管理サーバは、変換情報を生成するために前記トークン情報を変換するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致するか否かを判定するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致しないという判定に応じて、前記承認要求を拒絶するように構成される、
    請求項１６に記載のシステム。
18. 前記レジストリは、それぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれブラックリスト情報を示し、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記ＡｐｐＩＤに関連付けられたアプリケーションがブラックリストされていることを示すか否かを判定するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記アプリケーションがブラックリストされていることを示すという判定に応じて、前記承認要求を拒絶するように構成される、
    請求項１６に記載のシステム。
19. 前記レジストリは、それぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれのメタデータを示し、
    前記承認要求はトークン情報とユーザ識別情報（ｕｓｅｒＩＤ）を含み、
    アプリケーション管理サーバは、前記承認要求内の前記ｕｓｅｒＩＤに関連付けられたユーザプロフィール情報へのアクセスを提供するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられたメタデータが、得られたプロフィールを有するユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていることを示すか否か判定するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記メタデータが、前記得られたプロフィールを有する前記ユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていないことを示すという判定に応じて、前記承認要求を拒絶するように構成される、
    請求項１６に記載のシステム。
20. 前記指定手段は異なるアプリケーション識別子（ＡｐｐＩＤ）ごとにそれぞれ異なる秘密情報を指定し、
    前記レジストリは、それぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれ秘密情報と
    ブラックリスト情報を示し、
    前記承認要求はトークン情報を含み、
    前記アプリケーション管理サーバは、変換情報を生成するために前記トークン情報を変換するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致するか否か、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記ＡｐｐＩＤに関連付けられたアプリケーションがブラックリストされていることを示すか否かを判定するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致しないこと、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記ブラックリスト情報が、前記アプリケーションがブラックリストされていることを示すことの、少なくともいずれかの判定に応じて、前記承認要求を拒絶するように構成される、
    請求項１６に記載のシステム。
21. 前記指定手段は異なるアプリケーション識別子（ＡｐｐＩＤ）ごとにそれぞれ異なる秘密情報を指定し、
    前記レジストリは、それぞれの承認済ＡｐｐＩＤに関連付けられたそれぞれ秘密情報とメタデータを示し、
    前記承認要求はトークン情報とユーザ識別情報（ｕｓｅｒＩＤ）を含み、
    前記アプリケーション管理サーバは、変換情報を生成するために前記トークン情報を変換するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ｕｓｅｒＩＤに関連付けられたユーザプロフィール情報へのアクセスを提供するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致するか否か、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記メタデータが、得られたプロフィールを有するユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていることを示すか否かを判定するように構成され、
    前記アプリケーション管理サーバは、前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記秘密情報が前記変換情報に一致しないこと、および前記承認要求内の前記ＡｐｐＩＤに一致する前記レジストリ内のＡｐｐＩＤに関連付けられた前記メタデータが、前記得られたプロフィールを有する前記ユーザが前記ＡｐｐＩＤに関連付けられた前記アプリケーションの使用を承認されていないことを示すことの、少なくともいずれかの判定に応じて、前記承認要求を拒絶するように構成される、
    請求項１６に記載のシステム。
22. ネットワークを介してメディア情報を通信する方法であって、
    端末装置に登録されたアプリケーションのアプリケーション識別子（ＡｐｐＩＤ）を示すレジストリを、前記端末装置の持続性媒体に提供する工程と、
    前記端末装置のレジストリ内に示されたＡｐｐＩＤのメディア接続要求を得るために、前記ネットワークを介してアプリケーション管理サーバに、前記端末レジストリ内に示された１つ以上のＡｐｐＩＤと少なくとも秘密情報の機能として生成されたトークン情報を含む承認要求を定期的に送信する工程と、
    前記ネットワークを介して前記アプリケーション管理サーバからそれぞれのＡｐｐＩＤの承認指示を受信する工程と、
    前記端末装置レジストリ内の対応するＡｐｐＩＤに関連付けられたそれぞれの前記受信した承認指示を示す工程と、
    前記端末装置で動いている第１アプリケーションからの、異なる端末装置で動いている第２アプリケーションとのメディア接続要求であって、前記第１アプリケーションに関連付けられたＡｐｐＩＤを含んだメディア接続要求に応じて、前記メディア接続要求に含まれる前記ＡｐｐＩＤと前記トークン情報と前記端末装置レジストリ内の前記ＡｐｐＩＤに対応する承認指示に基づいて前記メディア接続を承認するか否かを判定する工程と、
    前記要求に含まれる前記ＡｐｐＩＤの前記メディア接続が承認されるという判定に応じて、ネットワークを介して前記第２アプリケーションとのメディア接続要求を送信する工程と、
    前記メディア接続要求に応じて、前記第１アプリケーションに関連付けられた前記ＡｐｐＩＤを含んだ制御情報であって、前記端末装置と前記異なる端末装置との間に確立された制御セッションを介して制御情報を通信する工程と、
    前記メディア接続要求に応じて、前記端末装置と前記異なる端末装置との間に確立されたメディアセッションを介してメディア情報を通信する工程と、
    を含む方法。
23. プロセッサと、ネットワークを介した通信の実行に適した通信プロトコルスタックによりコード化された持続性媒体とを含む端末装置であって、
    前記端末装置で動くように構成されたアプリケーションであって、
    前記アプリケーションは秘密情報と
    前記アプリケーションに関連付けられた固有のアプリケーション識別子（ＡｐｐＩＤ）を含むメソッド呼出しを送信するように構成され、異なる端末装置で動く他のアプリケーションとのメディア接続を要求するアプリケーションと、
    前記メソッド呼出しを、前記ＡｐｐＩＤと少なくとも秘密情報の機能として生成されたトークン情報とを含み前記異なる端末装置とのメディア接続を要求するメディア要求と前記ＡｐｐＩＤを含みアプリケーション管理サーバからの承認を要求する承認要求とを含むネットワークメッセージに変換し、
    前記ネットワークメッセージは前記トークン情報を含んだ前記承認要求を送信するためのプロキシサーバへの指示を含み、
    前記ネットワークを介した送信のための前記通信プロトコルスタックに前記ネットワークメッセージを提供し、
    前記通信プロトコルスタックに関連付けられたバッファからの情報であって、前記通信プロトコルスタックを使用して前記ネットワークを介して受信し、ＡｐｐＩＤ情報に関連付けられた情報にアクセスし、
    前記ＡｐｐＩＤに関連付けられた前記アプリケーションに前記アクセスされた情報を送るため、前記アクセスされた情報に関連付けられた前記ＡｐｐＩＤ情報を使用するように構成されたインターフェースと、
    を含む端末装置。
24. 前記アプリケーションは、さらに秘密情報を前記メソッド呼出しに含ませるように構成され、
    前記インターフェースは、さらに、少なくとも前記ＡｐｐＩＤと前記秘密情報の機能として前記承認要求に含ませるようにトークンを生成するように構成される、
    請求項２３に記載の端末装置。
25. 前記アプリケーションは、前記アプリケーションに関連付けられた少なくとも前記ＡｐｐＩＤと前記秘密情報の機能としてのトークンを生成し、前記トークンを前記メソッド呼出しに含ませるように構成され、
    前記インターフェースは、前記トークンを前記承認要求に含ませるように構成される、
    請求項２４に記載の端末装置。