JP2015091125A - アプリケーションインターフェイスを将来のアプリケーション用に拡張するための方法 - Google Patents

Abstract

【課題】携帯端末において、新しいサービスをサポートするために、第三者アプリケーションが既存のプロトコルスタックを活用することを許す仕組みを提供する。
【解決手段】携帯端末上のセッション・イニシエーション・プロトコル・セッションがタグ付けされ、タグ付けに従って、該セッションが特定のアプリケーションに関連付られ、ＳＩＰセッションのためのＳＩＰメッセージは、特定のアプリケーションに関連付られ８１０、ルーティングされる。ユーザ端末間の同じ接続を共有する複数のアプリケーションがあるとき（８２０：はい）、コンジットマネージャは、セッションを特定のアプリケーションとマッチングする８３０。レガシーリッチ通信サービスアプリケーションを意図するＳＩＰメッセージは、当該レガシーＲＣＳアプリケーションにルーティングされ、すべての残りのメッセージは、コンジットマネージャにルーティングされる８５０。
【選択図】図８

Description

本特許出願は、アプリケーションインターフェイスを将来のアプリケーション用に拡張するための方法に関し、より具体的には、携帯端末上のセッション・イニシエーション・プロトコル（ＳＩＰ）セッションにタグ付けし、該ＳＩＰセッションを特定のアプリケーションに関連付け、該タグ付けに従って、該ＳＩＰセッションのためのＳＩＰメッセージが特定のアプリケーションに関連付られ、ルーティングされる。

携帯サービスプロバイダーは、携帯通信アソシエーションのためのグローバルシステム（ＧＳＭＡ）リッチ通信サービス（ＲＣＳ）仕様書において予め定義されたサービスに、新しい第三者アプリケーションサービスを追加することに興味を持っている。ＲＣＳ拡張（ＲＣＳ ｅ）仕様書は、新しいサービスのためのサポートをアナウンスをするために第三者が能力メッセージ中に置けるタグを定義することにより、新しいサービスを発見するための仕組みを提供している。しかし、ＧＳＭＡ仕様書は、これらの新しいサービスをサポートするために、第三者アプリケーションが既存のプロトコルスタックを活用することを許す仕組みを提供していない。

携帯端末において、新しいサービスをサポートするために、第三者アプリケーションが既存のプロトコルスタックを活用することを許す仕組みが開示される。

該仕組みは、セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージを、異なるユーザ端末上で実行される特定のアプリケーションと関連付ける方法を含む。該方法は、ＳＩＰセッションにタグ付して、該ＳＩＰセッションを特定のアプリケーションに関連付けるステップと、タグ付けに従って、該ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付けるステップと、を含む。

上記方法はさらに、ＳＩＰのヘッダにおける既存の要素を修正することにより、ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップと、ＳＩＰのヘッダに新しい要素を追加することにより、ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップと、ＳＩＰプロトコルに新しい方法を追加することにより、ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップと、ＳＩＰによってネゴーシエイトされるセッション記述プロトコル（ＳＤＰ）パラメータに新しい要素を追加することにより、ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップと、ＳＩＰセッションのＳＤＰパラメータをネゴーシエイトするときにＳＤＰパラメータの既存の要素を修正することにより、ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップであり、ＳＩＰによってネゴーシエイトされるＳＤＰパラメータの既存の要素を修正するステップは、ＳＩＰセッションのＳＤＰパラメータをネゴーシエイトするときに特定のアプリケーションをセッション名として特定することを含み得るタグ付けステップと、そして／または、新しいコンジットを開始するときにＳＤＰパラメータセクションにおける新しいデータまたはメディアタイプを記述する追加パラメータを供給することにより、または、既存のコンジットに新しいメディアデータタイプを追加することにより、予め定義されたリッチ通信サービス（ＲＣＳ）データトランザクションの１つではない、新しいデータまたはメディアタイプを追加することにより、（ＳＩＰセッションにタグ付けし、ＳＩＰセッションを特定のアプリケーションに関連付けるタグ付けステップと）、を含み得る。

上記方法はさらに、ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるときに、ＳＩＰセッションを特定のアプリケーションにマッチングさせるコンジット・マネージャを利用するステップを含み得る。

上記方法はさらに、ＳＩＰセッションマネージャを追加することによりレガシー（legacy）ＲＣＳアプリケーションを修正する修正ステップであり、該ＳＩＰセッションマネージャは、各ＳＩＰセッションをチェックして、ＳＩＰメッセージがレガシーＲＣＳアプリケーションを意図するか否かを決定し、レガシーＲＣＳアプリケーションを意図するＳＩＰメッセージをそのレガシーＲＣＳアプリケーションにルーティングし、すべての残りのＳＩＰメッセージをコンジットマネージャにルーティングする、修正ステップを含み得る。

上記方法はさらに、予め定義されたＲＣＳデータトランザクションの１つではない新しいデータまたはメディアタイプを追加する追加ステップであり、新しいコンジットを開始するとき、または、既存のコンジットに新しいメディアデータタイプを追加するときに、ＳＤＰパラメータセクションにおいて新しいデータまたはメディアタイプを記述する追加のパラメータを供給することにより追加する追加ステップを含み得る。

上記方法はさらに、各アプリケーションがＲＣＳサービスにアクセスするための有効な許可を持つことによりユーザ端末を不要なアプリケーションから守るステップを含み得る。

本発明の、これらの、そして他の目的は、以下の、さまざまな図面において示される好適な実施形態の詳細な説明を読んだ後の当業者には確実に明らかになるであろう。

２つのそれぞれの端末上の現在のアプリケーションが、どのようにお互いに通信するかのモデルを示す図である。

コンジットが、どのように２つの異なるエンドポイント上のアプリケーション間の通信インターフェイスを提供するかのモデルを示す図である。

１つの端末上のアプリケーションが別の端末についての成功セッションを開始する処理を示すコールフロー図である。

１つの端末上のアプリケーションが別の端末についての不成功セッションを開始する処理を示すコールフロー図である。

２つのアプリケーションが、どのようにＲＣＳにとってコアではない新しいメディアタイプを共有するかの例を示すコールフロー図である。

各コンジットを指定されたアプリケーションにマッチングするコンジットマネージャを利用して同じＳＩＰ接続を共有する複数のアプリケーションを示す図である。

更新されたＳＩＰセッションマネージャと新しいアプリケーションとの中間にあるコンジットマネージャの追加を示す図である。

セッションにタグ付けするために、ＳＩＰヘッダを修正するステップの例示のフローである。

セッションにタグ付けするために、新しい方法をＳＩＰプロトコルに追加するステップの例示のフローである。

セッションにタグ付けするために、ＳＩＰセッションのＳＤＰパラメータをネゴーシエイトするときにＳＤＰパラメータを修正するステップの例示のフローである。

セッションにタグ付けするために、ＳＩＰによってネゴーシエイトされるＳＤＰパラメータに新しい要素を追加する、および／または、既存のＳＤＰパラメータを修正する、ステップの例示のフローである。

ユーザ端末を不要なＲＣＳアプリケーションから守るステップの例示のフローである。

新しいサービスをサポートするために、第三者アプリケーションが既存のプロトコルスタックを活用することを許す仕組みが開示される。

そのような仕組みのための要求仕様は以下のものを含む：
１．アプリケーションは、同じ、下にあるセッションイニシエーションプロトコル（ＳＩＰ）プロトコルスタックを共有することができる。
２．アプリケーションデータは、排他的にそれぞれのアプリケーションのために指定されることができる。
３．１つのアプリケーションのためのデータおよびプロトコルは、他のアプリケーションによるアクセスから保護されなければならない。これは、敏感なコアプロトコルのためには特に重要である。
４．標準ＲＣＳ機能のために下にあるプロトコルをアプリケーション開発者が知る必要がないように、ハイレベルなアプリケーションプログラミングインターフェイス（ＡＰＩ）が利用可能でなければならない。そして、そのようなＡＰＩは開発者コミュニティーにとって採用しやすくなくてはならない。
５．さらに、既存のＲＣＳアプリケーションに対する変更は最小化されなければならない。

プライベートＳＩＰスタック

１つのアプローチにおいて、すべてのアプリケーションは独自のＳＩＰスタックを有する。すべてのアプリケーションは、独自のＳＩＰスタックをインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）サーバに登録する。したがって、もし端末が、ボイスオーバインターネットプロトコル（ＶｏＩＰ）のための独立したアプリケーションを持ち、インスタントメッセージ（ＩＭ）のための別のアプリケーションを持つならば、端末にとって２つの登録があるであろう。サービスプロバイダーは、１つの端末に対して複数の登録をサポートするＩＭＳサーバをサポートしたくないので、このアプローチは多くのネットワークにとって受け入れられるものではないであろう。このアプローチは、上記リストアップされた最初の３つの要求仕様のいずれも満たさない。

ＳＩＰスタックの共有

ＧＳＭＡワーキンググループは１つの解決案をＧＳＭＡに提案した。彼らのアプローチは、ＳＩＰプロトコルへの直接アクセスを与えるＡＰＩを提供することである。これは、上記リストアップされた最初の要求仕様、すなわち、複数のアプリケーションが同じＳＩＰプロトコルを共有することを許すこと、を満たす。しかしながら、他の同じくらい重要な要求仕様を満たさない：
１．ＳＩＰスタックは、新しい着信セッションおよびその内容が特定のアプリケーションを意図するものであることを携帯端末に通知する方法を持たない。（すなわち、上記要求仕様の２．を満たさない。）
２．すべてのアプリケーションが、ＳＩＰスタックに対する同じアクセスを持つので、第三者アプリケーションは、より安全なアプリケーションを意図したデータまたは制御を操作できてしまう（すなわち、上記要求仕様の３．を満たさない）。
３．アプリケーション開発者はＳＩＰを完全に理解しなければならない。これは、より長い開発、統合およびテスト回数につながる（すなわち、上記要求仕様の４番目を満たさない）。
４．すでに多くのＳＩＰ ＡＰＩが使用されており、それらのＡＰＩのために多くのアプリケーションが開発されている。産業界全体を説得して、単一のＡＰＩを採用し、かれらのアプリケーションをこの新しいＡＰＩに移植させることは難しいであろう（すなわち、上記の第５番目の要求仕様を満たさない）。

ＲＣＳは多くのユーザ活動を定義している（例、音声通話、ＩＭ）。ＲＣＳ標準は、ＳＩＰが、これらの活動をサポートするセッションを管理することを要求する。各活動は予め定義された特性の組を備えている。ＳＩＰは、セッションのエンドポイントが、これらの特性をネゴーシエイトすることを許す。例えば、音声通話は、エンドポイントが、コーデック種別やビデオフレームレート等の、音声およびビデオストリームの特性をネゴーシエイトすることを要求する。

ユーザ（アプリケーション）セッション（例、ビデオ通話、ＩＭ会話）は、１以上のＳＩＰセッションで構成され得る。音声通話にとって、ユーザ（アプリケーション）セッションは、ＳＩＰセッションに丁度一致する。ＳＩＰセッションが終了するとき、通話は終了する。ＩＭにおいては、ユーザアプリケーションセッション（会話）は、多くの、シーケンシャルな、そしてオーバーラップする可能性のある、ＳＩＰセッションで構成され得る。

図１は、それぞれの端末ＡおよびＢ上の現在のアプリケーション１１０が、どのようにお互いに通信するかのモデル１００を示す。端末ＡおよびＢのそれぞれは、アプリケーション１１０、ＳＩＰスタック１２０、およびインターネットプロトコル（ＩＰ）スタック１３０を含む。アプリケーション１１０は、ＩＰ接続１５０上で管理されるＳＩＰセッション１４０を使用して、互いに通信する。

コンジット

アプリケーション間の通信は、しばしばユーザまたはアプリケーションセッションとして参照される。ユーザセッションとＳＩＰセッションとを区別するために、２つのエンドポイント間の仮想ユーザ（アプリケーション）セッションの概念が、コンジットとして導入される。

図２は、コンジット２６０が、どのように２つの異なるエンドポイント（端末Ａ上の１つのエンドポイントと端末Ｂ上の別のエンドポイント）上のアプリケーション２１０間の通信インターフェイスを提供するかのモデル２００を示す。端末ＡおよびＢのそれぞれは、アプリケーション２１０、ＳＩＰスタック２２０、およびＩＰスタック２３０を含む。コンジット２６０は、下にあるＩＰ接続２５０を管理するＳＩＰセッション２４０を管理する。

コンジットは、２つの特定のアプリケーション間の通信を管理する。例えば、ビデオ通話コンジットは、２つのビデオ通話アプリケーション間の通信を管理する。コンジットを受信する各端末が、意図されたアプリケーションを知るために、各コンジットは、意図されたアプリケーションを識別する情報を含む。この情報は、ＳＩＰプロトコルを使用して、コンジットエンドポイント間で運ばれる。

この情報をＳＩＰが運ぶにはいくつかの方法がある：
１．ＳＩＰヘッダにおける既存の要素を修正する。
２．ＳＩＰヘッダに新しい要素を追加する。
３．ＳＩＰプロトコルに新しい方法を追加する。
４．ＳＩＰによってネゴーシエイトされるセッション記述プロトコル（ＳＤＰ）パラメータに新しい要素を追加する。
５．既存のＳＤＰパラメータを修正する。

上記方法１−５のいずれも、必要なアプリケーション情報を提供するであろう。しかしながら、選択されるアプローチは、ＳＩＰスタックまたはその使用方法に対して大きな変更を要求しないことが好ましい。既存のプロトコルおよびアプリケーションソフトウェアに対して最小量の変更を要求するアプローチは、既存のＳＤＰパラメータを修正することである。このアプローチを使用することは、ＳＩＰスタック、または、それがどのようにＳＤＰパラメータをネゴーシエイトするかに対していかなる変更も要求しない。これについては、後でより詳しく説明する。

コンジットを使用したＲＣＳデータトランザクション

ＲＣＳアプリケーションによって使用されるデータトランザクションは、以下のタイプの１つに分類される。
１．リアルタイムデータストリーミング
２．ショートメッセージ
３．ファイル転送

さらに、ＲＣＳは、データストリーミングの２つのタイプを定義する：音声およびビデオ。

これらの標準トランザクションはＲＣＳにおけるコアアプリケーションを形成する。
１．音声通話は、リアルタイム音声ストリーミングを使用する。
２．ビデオ通話は、リアルタイム音声ストリーミングとリアルタイムビデオストリーミングの両方を使用する。
３．ショートメッセージサービス（ＳＭＳ）とＩＭは、ショートメッセージとファイル転送を使用する。
４．ファイル転送はファイル転送を使用する。
５．コンテンツ共有は、リアルタイムビデオストリーミングとファイル転送を使用する。

これらのトランザクションは一般的にアプリケーションにグループ分けされる。例えば、音声およびビデオストリーミングは、コールマネージャアプリケーションによって管理される。１つの端末上でこれらのトランザクションを管理する１つのアプリケーションは、別の端末上のそのピア（peer）と、コンジットを使用して通信する。

コンジットは、以下に示されるように、新しいアプリケーションおよび新しいタイプのデータを扱うように拡張されることができる。

新しいアプリケーションのためのコンジットの拡張

ＲＣＳアプリケーションに対する現在のアプローチにおいては、アプリケーションは、アプリケーションが使用するデータのタイプによって定義される。このアプローチを使用して、音声およびビデオストリーミングは、コールマネージャアプリケーションによって管理される。コールマネージャアプリケーションを示すものとして、ショートテキストメッセージが、メッセージアプリケーションによって扱われる。

このアプローチに伴う１つの問題は、新しいアプリケーションは、既存のアプリケーションによって既に使用されているデータトランザクションと同じデータトランザクションを使用することができないということである。例えば、チェスアプリケーションは、その動きを通信するためにショートメッセージを使用することができない。現在のモデルにおいては、新しいアプリケーションは、自身のプロトコルおよび自身の新しいデータタイプ、およびＲＣＳサーバとの別の登録を作らなければならない。代替的に、新しいアプリケーションは、既存のメッセージアプリケーションとすべてのメッセージを共有し、すべての他のアプリケーションのためのＳＩＰスタックへの完全なアクセスを持つように、信頼されなければならない。これらの２つのアプローチの制限事項は、前のセクションにおいて議論されている。

コンジットを使用することにより、複数のアプリケーションは、安全に、同じデータトランザクションを共有することができる。必要に応じて、新しいデータトランザクションですら追加することができる。以下のセクションンでは、いかに新しいアプリケーションを追加することができるかを説明する。

既存のデータトランザクションを使用した新しいアプリケーション

新しいアプリケーションは、独立したコンジットを生成することにより、同じタイプのトランザクションを共有することができる。例えば、１つのチェスのゲームのために１つの特定のＩＭコンジットが生成される。意図されたアプリケーションを、コンジットの両側が知るために、コンジットの下にあるプロトコルは、コンジットの意図するアプリケーションを通信しなければならない。

コンジットのための意図するアプリケーションを通信するための好ましい１つの方法は、上述したように、ＳＩＰ招待のＳＤＰセクションにおける既存のフィールド：セッション名を使用することである。セッション名は、必須のフィールドであるが、ＳＩＰセッションのセッション記述パラメータをネゴーシエイトするときに、現在は使用されていない。音声／ビデオ通話、ＩＭ、等の既存のアプリケーションは、現在しているとおりに：単一のスペースを用いて埋めて、セッション名を設定できる。新しいアプリケーションは、能力交換を実行するために使用されるタグを用いて、セッション名を設定することができる。このようにＳＩＰセッションにタグを付けることにより、コンジットは、ＳＩＰセッションデータを指定されたアプリケーションに向けることができる。

能力を交換するためのＲＣＳの仕様書がすでにある。メディアタイプをアプリケーション間で共有するために、セッションが特定のアプリケーションに関連付けられていることをシグナリングする１つの提案がここでは概説されている。これは、アプリケーションをセッション名として特定することによって行われる。

以下の例は、チェスアプリケーションを特定する新しいセッション名を追加することにより、メディアセクションを拡張している。
ｓ＝ｃｈｅｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｔａｇ
ｍ＝ａｕｄｉｏ ４９１７０ ＲＴＰ／ＡＶＰ ０
ｍ＝ｍｅｓｓａｇｅ ９ ＴＣＰ／ＭＳＲＰ ＊

もし、アプリケーションが新しいストリームデータタイプを持つならば、それは、以下のようなメディアセクションを使用することにより追加することができる。
ｓ＝ｍｙ＿ｇａｍｅ＿ｔａｇ
ｍ＝ａｕｄｉｏ ４９１７０ ＲＴＰ／ＡＶＰ ０
ｍ＝ｇａｍｅ．ｓｔｒｅａｍ ５１００２ ＲＴＰ／ＧＰ ０

このテクニックは、以下の例によって示される。

アプリケーション開発者は、チェス盤上の動きを伝えるために２人のプレーヤー間で通信される単純なショートメッセージを必要とする新しいチェスゲームを追加することを望む。ＩＭおよびＳＭＳのためのメッセージアプリケーションによって使用されるショートメッセージは、チェスの動きを通信するために使用されることができる。しかしながら、チェスの動きは、メッセージアプリケーションにおいて現れてはならない。これは、以下のようにチェスアプリケーションのための新しいコンジットを生成することによって達成することができる。

ユーザが、特定のユーザとのチェスセッションを開始することを望むとき、アプリケーションは、チェスゲームのためのコンジットを要求する。プロトコルエンジンは、そのユーザの端末がチェス能力をサポートするかをＧＳＭＡのＲＣＳ−ｅ仕様書に従ってチェックする。もし遠隔の端末がチェス能力をサポートするならば、プロトコルエンジンは、ＳＩＰセッションを開始する。ＳＤＰ記述は、そのＳＩＰセッションがチェスアプリケーションのためであることを示すセッション名を提供する。

遠隔の端末は、チェスアプリケーションのＳＤＰセッション名を伴うＳＩＰ招待（SIP invitation）を受信する。遠隔の端末上のプロトコルエンジンは、リスナー（listeners）に、着信チェスコンジットが受信されたことを通知する。チェスアプリケーションは該通知を受信する。これによりユーザは新しいコンジットを受け付けるオプションを与えられる。もし、ユーザがコンジットを受け付けるならば、アプリケーションは、ショートメッセージを用いてゲームを開始する。これらのメッセージはチェスゲームのために指定されているので、メッセージアプリケーションにおいては現れない。

チェスアプリケーションのアイディアはさらに、端末間の音声会話をサポートするために拡張されることができる。必要とされているのは、コンジットに音声メディアを追加することです。下にあるプロトコルエンジンは、音声通話をネゴーシエイトするであろう。音声通話はすでにコアＲＣＳ機能としてサポートされているので、音声エンジンは、このコンジットにおいて、音声通話と全く同じように管理されることができる。

上述のコンジットを使用するアプローチを使用することで、第三者アプリケーションのためにリストアップされた上記要求仕様のすべては満足される。対照的に、ＧＳＭＡ作業グループの提案は、先程リストアップされた要求仕様のうち、最初の要求仕様以外のすべての要求仕様を満たさないであろう。

アンドロイドオペレーションシステム（ＯＳ）の初期のバージョンは、異なるアプリケーションで横断的にメッセージを共有する方法：順序付けられたブロードキャスト手法を提供していた。順序付けられたブロードキャストを使用するために、各アプリケーションは、特定の優先度を持つ特定のブロードキャスト意図を聴くために登録する。この意図に対してメッセージが利用可能であるとき、各アプリケーションは、要求優先度に基づいて通知される。優先度の鎖におけるいかなるアプリケーションは、そのメッセージを消費することができ、より低い優先度のアプリケーションがそのメッセージを受信することを防ぐことができる。これは、致命的なセキュリティ上の欠陥であることがわかった。この欠陥は、1つのアプリケーションだけにＳＭＳメッセージを受信することを許すアンドロイド４．４（キットカット（Kit Kat））において対応された。このアプリケーションはユーザによって選択されることができる。この更新により、メッセージはもはや異なるアプリケーションによって共有されない。

コンジットの成功、および、不成功ネゴーシエイションを示す２つのコールフローが、チェスゲームの例のためにここで提供される。以下のアプリケーションフローは、２つのクライアントが接続され登録されていることを想定している。
成功セッションネゴーシエイション

図３は、１つの端末上のアプリケーションが別の端末についての成功セッションを開始する処理を示すコールフロー図であり、図３において示された同じステップ番号に対応するステップ番号が付されている。
１．標準的なディスカバリーの仕組みを使用して、離れた相手の能力を得る。
２．アプリケーションは、コンジットマネージャに要求して、特定のユーザの遠隔の能力を得る。
３．コンジットマネージャはＩＭＳコアに要求をする。
４．ＩＭＳコアは、その要求を、遠隔のクライアント上で実行されているコンジットマネージャに中継する。
５．コンジットマネージャは、クライアントＢの能力を用いて要求に対して応答する。
６．ＩＭＳコアは、応答をクライアントＡに中継する。
７．コンジットマネージャはアプリケーションに、能力が受信されたことを通知する。
８．もしユーザBがこのアプリケーションをサポートする能力を持つならば、新しいセッションが開始される。
９．アプリケーションは、新しいコンジットを、適用可能なメディアとともに生成する。
１０．コンジットマネージャは、招待（invite）を送信することによりセッションを開始する。
１１．ＩＭＳコアは、招待をユーザＢに中継する。
１２．ＩＭＳコアは、招待が送信されたことをＳＩＰ ＴＲＹＩＮＧ応答を用いてユーザＡに知らせる。
１３．コンジットマネージャは、特定のアプリーケーションのための新しい着信コンジットがあったことをアプリケーションに知らせる。
１４．アプリケーションはコンジットを受け付ける。
１５．端末Ｂ上のコンジットマネージャは、ＯＫ応答で応答する。
１６．ＩＭＳコアは、その応答を端末Ａに中継する。
１７．端末Ａは、端末ＢへのＡＣＫを返す。
１８．ＩＭＳコアは、そのＡＣＫを端末Ｂに中継する。
１９．コンジットマネージャはアプリケーションに、コンジットは今や有効であり、メディアは交換することができることを合図する。
不成功なＳＤＰネゴーシエイション

図４は、１つの端末上のアプリケーションが別の端末についての不成功セッションを開始する処理を示すコールフロー図であり、図４において示された同じステップ番号に対応するステップ番号が付されている。この例示のコールフローにおいて、クライアントは成功裏に能力を交換する。クライアントBは、ＳＤＰメッセージを受け付けない。これがクライアントＡによって検出され、セッションは終了する。
１．標準的なディスカバリーの仕組みを使用して、離れた相手の能力を得る。
２．アプリケーションは、コンジットマネージャに要求して、特定のユーザの遠隔の能力を得る。
３．コンジットマネージャはＩＭＳコアに要求をする。
４．ＩＭＳコアは、その要求を、遠隔のクライアント上で実行されているコンジットマネージャに中継する。
５．コンジットマネージャは、クライアントＢの能力を用いて要求に対して応答する。
６．ＩＭＳコアは、応答をクライアントＡに中継する。
７．コンジットマネージャはアプリケーションに、能力が受信されたことを通知する。
８．もしユーザBがこのアプリケーションをサポートする能力を持つならば、新しいセッションが開始される。
９．アプリケーションは、新しいコンジットを、適用可能なメディアとともに生成する。
この新しいメディアは、ＳＤＰメディアおよび属性として記述される。
１０．コンジットマネージャは、招待（invite）を送信することによりセッションを開始する。
この招待は、新しいメディアによって要求されるいかなる標準メディアの記述を含む。
１１．ＩＭＳコアは、招待をユーザＢに中継する。
１２．ＩＭＳコアは、招待が送信されたことをＳＩＰ ＴＲＹＩＮＧ応答を用いてユーザＡに知らせる。
１３．コンジットマネージャは、特定のアプリーケーションのための新しい着信コンジットがあったことをアプリケーションに知らせる。
１４．アプリケーションはコンジットを受け付ける。
１５．端末Ｂ上のコンジットマネージャは、ＯＫ応答で応答する。
サポートされるメディアにおける不整合のため、クライアントＢの応答は、新しいメディアの記述を含まない。
１６．ＩＭＳコアは、その応答を端末Ａに中継する。
１７．端末Ａは、端末ＢへのＡＣＫを返す。
１８．ＩＭＳコアは、そのＡＣＫを端末Ｂに中継する。
１９．コンジットマネージャはアプリケーションに、コンジットは今や有効であり、メディアは交換することができることを合図する。
２０．アプリケーションは応答を解析し、新しいメディアは受け付けられなかったことを知る。
２１．アプリケーションはコンジットを終了する。
２２．コンジットマネージャは、メディアは受け付けられなかったという理由とともにＢＹＥメッセージを送信する。
２３．ＩＭＳコアは、このメッセージをクライアントＢに中継する。
２４．クライアントＢ上のコンジットマネージャは、コンジットが終了したことをアプリケーションに知らせる。
２５．コンジットマネージャは、ＳＩＰ ＯＫ応答とともにＢＹＥメッセージを確認する。
２６．ＩＭＳコアは、そのメッセージを中継する。
２７．コンジットが終了する。

新しいデータトランザクションタイプのためにコンジットを拡張する

アプリケーション間で標準のＲＣＳデータトランザクションを共有することに加えて、アプリケーションは、ＲＣＳにとってコアではない新しいタイプのデータを導入することができる。この場合、アプリケーションは、この新しいタイプのストリームを管理することが要求される。コンジットインターフェイスは、ストリームの拡張可能な記述を伴う新しいデータストリーミングメディアタイプを許す。これは、ＳＤＰセクションのために新しいメディアタイプを記述する追加のパラメータを、アプリケーションに供給させることによって達成できる。これらのパラメータは、新しいコンジットを開始するとき、または、新しいメディアデータタイプを既存のコンジットに追加するときに使用することができる。

遠隔の相手が、新しいストリーミングデータタイプの記述を必要とする新しいコンジットを生成するとき、コンジットは、このメディアのためにアプリケーションに対してパラメータを報告する。

このアプローチは、プロトコルエンジンの修正を必要とすることなく、または、直接ＳＩＰスタックにアクセスすることを必要とすることなく、新しいタイプのストリーミングデータをアプリケーションがサポートすることを許す。

図５は、２つのアプリケーションが、ＲＣＳにとってコアではない新しいメディアタイプをどのように共有することができるかの例を示すコールフロー図であり、図５において示された同じステップ番号に対応するステップ番号が付されている。
１．標準的なディスカバリーの仕組みを使用して、離れた相手の能力を得る。
２．アプリケーションは、コンジットマネージャに要求して、特定のユーザの遠隔の能力を得る。
３．コンジットマネージャはＩＭＳコアに要求をする。
４．ＩＭＳコアは、その要求を、遠隔のクライアント上で実行されているＣＳＩに中継する。
５．コンジットマネージャは、クライアントＢの能力を用いて要求に対して応答する。
６．ＩＭＳコアは、応答をクライアントＡに中継する。
７．コンジットマネージャはアプリケーションに、能力が受信されたことを通知する。
８．もしユーザBがこのアプリケーションをサポートする能力を持つならば、新しいセッションが開始される。
９．アプリケーションは、新しいコンジットを、適用可能なメディアとともに生成する。
このコンジットを生成するとき、新しいメディアタイプが記述される。
１０．コンジットマネージャは、招待（invite）を送信することによりセッションを開始する。
招待は、新しいメディアタイプの記述を含む。
１１．ＩＭＳコアは、招待をユーザＢに中継する。
１２．ＩＭＳコアは、招待が送信されたことをＳＩＰ ＴＲＹＩＮＧ応答を用いてユーザＡに知らせる。
１３．コンジットマネージャは、特定のアプリーケーションのための新しい着信コンジットがあったことをアプリケーションに知らせる。
１４．アプリケーションはコンジットを受け付ける。
１５．端末Ｂ上のコンジットマネージャは、ＯＫ応答で応答する。
１６．ＩＭＳコアは、その応答を端末Ａに中継する。
１７．端末Ａは、端末ＢへのＡＣＫを返す。
１８．ＩＭＳコアは、そのＡＣＫを端末Ｂに中継する。
１９．コンジットマネージャはアプリケーションに、コンジットは今や有効であり、メディアは交換することができることを合図する。
２０．今やクライアントＡは新しいタイプに基づいてメディアをクライアントＢに送信することができる。

複数のアプリケーションをコンジットを用いてサポートする

前のセクションは、アプリケーションを異なるデータタイプに関連付けるために、どのようにコンジットが使用できるかを示した。同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、図６において示されるように、各コンジットを指定されたアプリケーションとマッチさせるためにコンジットマネージャが追加される。端末Ａ、Ｂ、およびＣのそれぞれは、少なくとも、１つのアプリケーション３６０、および／または、３７０、コンジットマネージャ３１０、ＳＩＰスタック３２０、およびＩＰスタック３３０を備える。明らかに、図６は、クレームの範囲から逸脱することなく、いかなる数の端末、コンジット、および／または、アプリケーションに適用することができる１つの例に過ぎない。

図６において、端末Ａのユーザは、端末Ｂのユーザを相手にチェス３７０をしており、同時に、端末Ｂのそのユーザにメッセージング３６０をしている。コンジットマネージャ３１０は、それらの端末ＡおよびＢ上の、チェスアプリケーション３７０間のチェスコンジット３６５、および、ＩＭアプリケーション３６０間のＩＭコンジット３５５を提供し維持する。もし、端末Ｂのユーザがまた、端末Ｃ上のユーザとＩＭ会話を持つならば、端末Ｂ上のコンジットマネージャ３１０は、端末ＢおよびＣ上のＩＭアプリケーション３６０間のＩＭコンジット３５０を提供し維持するであろう。

レガシーＲＣＳアプリケーションに新しいアプリケーションを追加する

これまで、どのように複数のアプリケーションがコンジットを使用して単一のＳＩＰスタック上でサポートされることができるかが示されてきた。しかし、既存のＲＣＳアプリケーションとＳＩＰアプリケーションが既に大量に存在する。コンジットを使用するメリットの１つは、（コンジットを使用しない）レガシーＲＣＳおよびＳＩＰアプリケーションが、コンジットをサポートするアプリケーションと相互運用することができることである。さらに、レガシーアプリケーションへの影響が最小限またはゼロで、新しいアプリケーションをレガシーＳＩＰアプリケーションに追加することができる。その詳細は、以下のセクションで提供される。

（コンジットをサポートしない）レガシーアプリケーションと相互運用する

もし、ＲＣＳアプリケーションがコンジットをサポートしないならば、端末は、端末がサポートするコアＲＣＳアプリケーションに限定される。そのような端末に対して遠隔の端末が、サポートされないアプリケーションとのセッションの生成を要求するとき、能力発見は、そのような要求を拒否するである。しかし、レガシーＲＣＳアプリケーションからの要求は、レガシーアプリケーションあるいは下にあるＳＩＰスタックにいかなる修正をすることなく、受け付けられ、正しく機能するであろう。

既存のアプリケーションにコンジットサポートを追加するために、ＳＩＰセッションを管理するＳＩＰアプリケーションの部分は、新しいＳＩＰセッションマネージャを含むように修正できる。セッションマネージャは、意図されたアプリケーションのための各セッションをチェックする。レガシーＲＣＳデータトランザクションのためのセッション名は空（未使用）のままとなっているであろう。レガシーＲＣＳアプリケーションのためのすべてのセッションは、ＳＩＰセッションマネージャによってＲＣＳアプリケーションにルーティングされるであろう。残りのセッションは、コンジットマネージャにルーティングされるであろう。図７は、更新されたＳＩＰセッションマネージャ４１５と新しいアプリケーションとの中間にあるコンジットマネージャ４１０の追加４００を示しており、第三者アプリケーションをサポートするために使用することができる。

図７の左側は、古いアプリケーション、ＲＣＳアプリケーション４５０、ＳＩＰセッションマネージャ４１２、ＳＩＰスタック４２０、およびＩＰスタック４３０を含む端末を示している。図７の左側の端末は、図７の右側の端末において示されているように、修正して、レガシーアプリケーションにコンジットサポートを追加することができる。図７の右側の端末は、新しいアプリケーション４５５、ＲＣＳアプリケーション４５０、コンジットマネージャ４１０、更新されたＳＩＰセッションマネージャ４１５、ＳＩＰスタック４２０、およびＩＰスタック４３０を含む。

コンジットマネージャ４１０の追加にともなって、もともとのＳＩＰセッションマネージャインターフェイス４１２は保たれる。これは、既存のＲＣＳアプリケーション４５０は、いかなる変更もなく動作し続けるであろうことを意味している。しかし、新しいアプリケーション４５５は、コンジットマネージャ４１０によって供給されるソフトウェアインターフェイスを使用しなければならない。これにより、新しいアプリケーション４５５は、レガシーアプリケーションと同じＳＩＰスタック４３０と登録を共有することが許される。

コンジットを使用する代替：もし、アプリケーション開発者が、新しいアプリケーションのためにコンジットを使用することを望まないならば、新しいアプリケーションはそれでもそのようなアプリケーションと同じＳＩＰ接続およびソフトウェアスタックを共有することができる。これは、コンジット機能に置き換わるアプリケーションインターフェイスを提供することによって達成される。そのようなインターフェイスに含まれなければならない、鍵となるコンジットの相互運用性機能は：
１．意図するアプリケーションは、ＳＤＰメッセージにおけるセッション名パラメータを使用して伝えられる。
２．アプリケーションインターフェイスは、新しいアプリケーションが新しいメディアタイプをＳＩＰセッションに追加することを許さなければならない。

アンドロイドＯＳ下のコンジットを確保（secure）する

アンドロイドのセキュリティは以下の考え方に基づいている：
１．アンドロイドアプリケーションサンドボックス。各アプリケーションの各データおよびコード実行は、サンドボックスによって他のアプリケーションから隔離されている。
２．すべてのアプリケーションは証明書によって署名されている。
３．アンドロイド許可は、アプリケーション単位で、データへのアクセスおよびコード実行を制御するために使用することができる。

アプリケーション開発者は、バックグラウンドにおいて長く実行されるバックグラウンド動作を実行するためにアンドロイドサービスを使用する。ＳＩＰセッションは、長く実行されるバックグラウンド動作であり得るので、開発者は、ＳＩＰセッションマネージャおよびＳＩＰスタックを、ＲＣＳサービスとして、あるいは、ＲＣＳサービスからアクセスされるネイティブアプリケーションとして、実装する。アプリケーションは、ＲＣＳサービスとのアンドロイドＩＢｉｎｄｅｒインターフェイスを使用してＳＩＰスタックと通信する。

アプリケーションがコンジットを使用するとき、コンジットは、ＲＣＳサービスと通信する。コンジットを確保（secure）するためには、ＲＣＳサービスとのＩＢｉｎｄｅｒインターフェイスが確保（secure）されなければならない。

携帯端末（電話）メーカ（「ＯＥＭ」）が、携帯端末（電話）にソフトウェアをロードするとき、すべての許可されたアプリケーションおよびサービスは、ＯＥＭキーによって署名される。もし、ＲＣＳアプリケーションとＲＣＳサービスが同じキーによって署名されるならば、ＲＣＳサービスとのＩＢｉｎｄｅｒインターフェイスは容易に確保（secure）することができる。これは、ＲＣＳアプリケーションとＲＣＳサービスが同じプロセスを共有することにより、または、ＲＣＳサービスが、通信がＲＣＳアプリケーションから来ていることをチェックすることにより、行うことができる。

（ＯＥＭによって署名されていない）第三者プリケーションにコンジットへのアクセスを提供するためには、ＲＣＳサービスは、アプリケーションがサービスへのアクセスを持つべきか否かを決定することができなければならない。許可（permission）と、証明書（certificate）の検証（validation）との組合せが、アプリケーションを、コンジットインターフェイスのすべてまたは部分集合に制限するために使用されることができる。以下のセクションでは、コンジットインターフェイスを確保（secure）するための異なるアプローチが説明される。

アンドロイド許可（permission）

最も基本的なアプローチは、各アプリケーションに、ＲＣＳサービスにアクセスするための有効な許可（permission）を持つことを要求することである。もし、許可が、「危険」と記されていたならば、そのアプリケーションをインストールし、ＲＣＳサービスへのアクセスを与えるか否かをユーザが決定する。

証明書（certificate）の検証（validation）

各アプリケーションは、証明書によって署名されている。ＲＣＳサービスは証明書をチェックすることができる。もし、証明書がＯＥＭ証明書と整合するならば、アプリケーションは、ＲＣＳサービスによってサポートされるすべてのインターフェイスへのフルアクセスが付与されている。もしＯＥＭ証明書でないならば、アクセスは、セキュリティポリシーによって決定される。セキュリティポリシーは、第三者アプリケーションに制限されたアクセスを付与し得る。

より高いレベルのセキュリティのために、証明書は、既知の良いリスト（ホワイトリスト）および既知の悪いリスト（ブラックリスト）に対してチェックされ得る。もし、証明書が、いずれのリストにも載っていないならば、セキュリティポリシーがアクセスを指示し得る。ホワイトリストおよびブラックリストは、動的に更新可能であり得る。最新のリストは、悪いアプリケーションがＲＣＳサービスへのアクセスを得られないことを確保する。

アプリケーション検証

コンジットは、アプリケーションのＩＤを含むので、コンジットのセキュリティは、コンジットを特定のアプリケーションに制限し得る。ＲＣＳサービス内のセキュリティマネージャは、どの証明書がどのタイプのコンジットと関連付けられることが可能か管理することが必要となり得る。

コンジットの実装

前述したように、コンジットは２つの特定のアプリケーション間の通信を管理する。コンジットを受信する各端末が意図したアプリケーションを知るために、各コンジットは、意図したアプリケーションを識別する情報を含む。この情報は、ＳＩＰプロトコルを使用してコンジットエンドポイント間を伝送される。そして、ＳＩＰがこの情報を伝送するためにいくつかの方法がある。ＳＩＰメッセージを、異なるユーザ端末上で実行されている特定のアプリケーションと関連付ける好適な方法は、ＳＩＰセッションをタグ付けし、ＳＩＰセッションを特定のアプリケーションと関連付けること、および、タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付けること、を含む。

ＳＩＰセッションのタグ付けは、とりわけ、ＳＩＰヘッダの既存の要素を修正することにより、または、ＳＩＰヘッダに新しい要素を追加することにより、または、ＳＩＰプロトコルに新しい方法を追加することにより、または、ＳＩＰによってネゴーシエイトされるＳＤＰパラメータに新しい要素を追加することにより、および／または、既存のＳＤＰパラメータを修正することにより、等のいくつかの方法で達成することができる。

図８は、セッションにタグ付けするために、ＳＩＰヘッダを修正するステップの例示のフロー８００である。ＳＩＰヘッダは、修正された既存の要素を持つことが出来、および／または、ＳＩＰヘッダに新しい要素を追加することが出来る。フロー８００におけるステップは、以下のステップを含み得るが、ステップ８２０−８５０は、実装および状況に応じてオプションとなり得る。

ステップ８１０：ＳＩＰセッションにタグを付け、ＳＩＰのヘッダを修正することにより、ＳＩＰセッションを特定のアプリケーションに関連付ける。

ステップ８２０、８３０：コンジットマネージャを利用して、ユーザ端末間で同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションを特定のアプリケーションにマッチングする。

ステップ８４０、８５０：レガシーＲＣＳアプリケーションを使用しているとき、各ＳＩＰセッションをチェックして、ＳＩＰメッセージがレガシーＲＣＳアプリケーションのために意図されているか否かを判定し、レガシーＲＣＳアプリケーションのために意図されているＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングし、すべての残りのＳＩＰメッセージをコンジットマネージャにルーティングするＳＩＰセッションマネージャを追加することにより、レガシーＲＣＳアプリケーションを修正する。

ステップ８６０：タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付ける。

図９は、セッションにタグ付けするために、新しい方法をＳＩＰプロトコルに追加するステップの例示のフロー９００である。フロー９００におけるステップは、以下のステップを含み得るが、ステップ９２０−９５０は、実装および状況に応じてオプションとなり得る。

ステップ９１０：ＳＩＰセッションにタグを付け、ＳＩＰプロトコルに新しい方法を追加することにより、ＳＩＰセッションを特定のアプリケーションに関連付ける。

ステップ９２０、９３０：ユーザ端末間の同じＳＩＰ接続を複数のアプリケーションが共有するときに、コンジットマネージャを利用して、ＳＩＰセッションを特定のアプリーケーションにマッチングする。

ステップ９４０、９５０：レガシーＲＣＳアプリケーションを使用しているとき、各ＳＩＰセッションをチェックして、ＳＩＰメッセージがレガシーＲＣＳアプリケーションを意図するものか否かを判定し、レガシーＲＣＳアプリケーションを意図するＳＩＰメッセージをそのレガシーＲＣＳアプリケーションにルーティングし、すべての残りのＳＩＰメッセージをコンジットマネージャにルーティングする、ＳＩＰセッションマネージャを追加することにより、レガシーＲＣＳアプリケーションを修正する。

ステップ９６０：タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付ける。

図１０は、セッションにタグ付けするために、ＳＩＰセッションのＳＤＰパラメータをネゴーシエイトするときにＳＤＰパラメータを修正するステップの例示のフロー１０００である。フロー１０００におけるステップは、以下のステップを含み得るが、ステップ１０２０−１０５０は、実装および状況に応じてオプションとなり得る。

ステップ１０１０：ＳＩＰセッションにタグを付け、ＳＩＰセッションのＳＤＰパラメータをネゴーシエイトするときにＳＤＰパラメータを修正することにより、ＳＩＰセッションを特定のアプリケーションに関連付ける。

ステップ１０２０、１０３０：ユーザ端末間の同じＳＩＰ接続を複数のアプリケーションが共有するときに、コンジットマネージャを利用して、ＳＩＰセッションを特定のアプリーケーションにマッチングする。

ステップ１０４０、１０５０：レガシーＲＣＳアプリケーションを使用しているときに、各ＳＩＰセッションをチェックして、ＳＩＰメッセージがレガシーＲＣＳアプリケーションを意図するものか否かを判定し、レガシーＲＣＳアプリケーションを意図するＳＩＰメッセージをそのレガシーＲＣＳアプリケーションにルーティングし、すべての残りのＳＩＰメッセージをコンジットマネージャにルーティングするＳＩＰセッションマネージャを追加することにより、レガシーＲＣＳアプリケーションを修正する。

ステップ１０６０：タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付ける。

図１１は、ＳＩＰによってネゴーシエイトされるＳＤＰパラメータに新しい要素を追加するステップ、および／または、既存のＳＤＰパラメータを修正するステップ、の例示のフロー１１００である。フロー１１００におけるステップは、以下のステップを含み得るが、ステップ１１２０は、実装および状況に応じてオプションとなり得る。

ステップ１１１０：ＳＩＰセッションにタグを付け、ＳＩＰセッションを特定のアプリケーションに関連付ける。

ステップ１１２０：新しいコンジットを開始するときにＳＤＰパラメータにおける新しいデータまたはメディアタイプを記述する追加パラメータを供給することにより、または、既存のコンジットに新しいメディアデータタイプを追加することにより、予め定義されたＲＣＳデータトランザクションの１つではない新しいデータまたはメディアタイプを追加する。

ステップ１１３０：タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付ける。

図１２は、ユーザ端末を不要なＲＣＳアプリケーションから守るステップの例示のフロー１２００である。フロー１２００におけるステップは、以下のステップを含み得るが、ステップ１２２０は、実装および状況に応じてオプションとなり得る。

ステップ１２１０：ＳＩＰセッションにタグを付け、ＳＩＰセッションを特定のアプリケーションに関連付ける。

ステップ１２２０：各アプリケーションがＲＣＳサービスにアクセスするための有効な許可を保つことにより、ユーザ端末を、不要なＲＣＳアプリケーションから守る。

ステップ１２３０：タグ付けに従って、ＳＩＰセッションのためのＳＩＰメッセージを特定のアプリケーションに関連付ける。

まとめ

この文書は、新しいアプリケーションをサポートするため、ＲＣＳを拡張するための安全で開発者フレンドリーなアプローチをまとめた。このアプローチは、既存のアプリケーションと干渉することなく、同じデータトランザクションを新しいアプリケーションが使用することを許すことにより、コアデータトランザクションを活用する。加えて、移植性およびセキュリティの心配の原因となる低レベルのプロトコルへのアクセスをアプリケーションに与えることなく、新しいタイプのデータトランザクションをサポートすることができる。そして、上述の技術を使用するために、既存のアプリケーションおよびプロトコルスタックは容易に拡張することができる。

当業者は、発明の教示を保持しつつ、装置および方法の多くの修正や変更がなされ得ることを容易に観察するであろう。それに応じて、上述の開示は、添付の特許請求の範囲によってのみ制限されると解釈されるべきである。

本出願は、２０１３年１１月５日に出願された米国仮出願番号６１／９００，３５７の優先権を主張し、その全体は参照により本明細書に取り込まれる。

Claims (21)

1. セッション・イニシエーション・プロトコル（ＳＩＰ）メッセージを、異なるユーザ端末上で実行されている特定のアプリケーションと関連付ける方法であって、
   ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップと、
   前記タグ付けステップに従って、前記ＳＩＰセッションのためのＳＩＰメッセージを前記特定のアプリケーションに関連付ける関連付けステップと、を備える
   方法。
2. 請求項１に記載の方法であって、前記ＳＩＰのヘッダ内の既存の要素を修正することにより、前記ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップをさらに備える、
   方法。
3. 請求項２に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
   方法。
4. 請求項３に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
   方法。
5. 請求項１に記載の方法であって、前記ＳＩＰのヘッダに新しい要素を追加することにより、前記ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップをさらに備える、
   方法。
6. 請求項５に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
   方法。
7. 請求項６に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
   方法。
8. 請求項１に記載の方法であって、前記ＳＩＰプロトコルに新しい方法を追加することにより、前記ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップをさらに備える、
   方法。
9. 請求項８に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
   方法。
10. 請求項９に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
    方法。
11. 請求項１に記載の方法であって、前記ＳＩＰによってネゴーシエイトされるセッション記述プロトコル（ＳＤＰ）パラメータに新しい要素を追加することにより、前記ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップをさらに備える、
    方法。
12. 請求項１１に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
    方法。
13. 請求項１２に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
    方法。
14. 請求項１に記載の方法であって、セッション記述プロトコル（ＳＤＰ）パラメータの既存の要素を、ＳＩＰセッションの前記ＳＤＰパラメータをネゴーシエイトするときに、修正することにより、前記ＳＩＰセッションをタグ付けし、前記ＳＩＰセッションを前記特定のアプリケーションに関連付けるタグ付けステップをさらに備える、
    方法。
15. 請求項１４に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
    方法。
16. 請求項１５に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
    方法。
17. 請求項１４に記載の方法であって、前記ＳＩＰによってネゴーシエイトされる前記ＳＤＰパラメータの前記既存の要素を修正する修正ステップは、前記ＳＩＰセッションの前記ＳＤＰパラメータをネゴーシエイトするときに前記特定のアプリケーションをセッション名として特定する特定ステップを含む、
    方法。
18. 請求項１７に記載の方法であって、ユーザ端末間の同じＳＩＰ接続を共有する複数のアプリケーションがあるとき、ＳＩＰセッションと前記特定のアプリケーションとをマッチングするためにコンジットマネージャを活用する活用ステップをさらに備える、
    方法。
19. 請求項１８に記載の方法であって、レガシー・リッチ・通信サービス（ＲＣＳ）アプリケーションを修正する修正ステップであり、前記ＳＩＰメッセージが前記レガシーＲＣＳアプリケーションを意図するか否かを判定するために各ＳＩＰセッションをチェックするＳＩＰセッションを追加することにより、そして、前記レガシーＲＣＳアプリケーションを意図する前記ＳＩＰメッセージを当該レガシーＲＣＳアプリケーションにルーティングすることにより、そして、すべての残りのＳＩＰメッセージを前記コンジットマネージャにルーティングすることにより、前記レガシーＲＣＳアプリケーションを修正する修正ステップをさらに備える、
    方法。
20. 請求項１に記載の方法であって、事前に定義されたリッチ通信サービス（ＲＣＳ）データトランザクションの１つではない新しいデータまたはメディアタイプ、を追加する追加ステップであり、新しいコンジットを開始するとき、または、前記新しいメディアデータタイプを既存のコンジットに追加するときに、セッション記述プロトコル（ＳＤＰ）パラメータにおいて前記新しいデータまたはメディアタイプを記述する追加のパラメータを供給することにより、前記新しいデータまたはメディアタイプ追加する追加ステップ、をさらに備える、
    方法。
21. 請求項１に記載の方法であって、不要なリッチ通信サービス（ＲＣＳ）アプリケーションからユーザ端末を守るステップであり、ＲＣＳサービスにアクセスするための有効な許可を各アプリケーションが持つことにより、ユーザ端末を守るステップをさらに備える、
    方法。

Images