(57)【要約】  セッション・イニシェーション・プロトコル・メッセージが関係するＩＰマルチメディア・サブシステム通信サービスを示す方法であって、前記セッション・イニシェーション・プロトコル・メッセージ中に、フィーチャ・タグとして、一つまたはそれ以上の通信サービス識別子を含む方法。
2008543133.tif 000002
【特許請求の範囲】
【請求項１】
セッション・イニシェーション・プロトコル・メッセージが関係するＩＰマルチメディア・サブシステム通信サービスを示す方法であって、前記セッション・イニシェーション・プロトコル・メッセージ中に、該メッセージのフィーチャ・タグとして、１以上の通信サービス識別子を含ませる工程を有し、前記通信サービス識別子は、複数の通信サービスの一つを識別することを特徴とする方法。
【請求項２】
前記フィーチャ・タグは、ＳＩＰメッセージのＣｏｎｔａｃｔ，Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダの一つに含まれていることを特徴とする請求項１に記載の方法。
【請求項３】
セッション・イニシェーション・プロトコル・メッセージが関係する、ユーザ・ターミナルに存在する、アプリケーションを識別する方法であって、前記セッション・イニシェーション・プロトコル・メッセージ中に、アプリケーション・リファレンスを含ませる工程を有することを特徴とする方法。
【請求項４】
アプリケーション・リファレンスが、前記ＳＩＰメッセージのヘッダ中に、フィーチャ・タグとして含まれていることを特徴とする請求項３に記載の方法。
【請求項５】
前記フィーチャ・タグは、ＳＩＰメッセージのＣｏｎｔａｃｔ，Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダの一つに含まれていることを特徴とする請求項４に記載の方法。
【請求項６】
前記アプリケーション・リファレンスは、前記ＳＩＰメッセージのＳＤＰ部分中の、“ｍ−ｌｉｎｅ”を拡大する“ａ−ｌｉｎｅ”として含まれていることを特徴とする請求項３に記載の方法。
【請求項７】
複数のアプリケーション・リファレンスが、前記ＳＩＰメッセージ中に、フィーチャ・タグおよびａ−ｌｉｎｅの両方として含まれていることを特徴とする請求項３に記載の方法。
【請求項８】
フィーチャ・タグとして含まれる前記アプリケーション・リファレンスは主アプリケーションを識別し、ａ−ｌｉｎｅに含まれるアプリケーション・リファレンスは補助アプリケーションを識別することを特徴とする請求項７に記載の方法。
【請求項９】
ユーザ・ターミナルまたはＩＭＳネットワーク・ノードを動作させる方法であって、
ＩＭＳスタックにおいて、受信したセッション・イニシェーション・プロトコル・メッセージ中に含まれる通信サービス識別子に基づいて、適切な通信サービスを識別する工程と、
前記メッセージを前記サービスへ転送する工程と、
前記識別された通信サービスにおいて前記メッセージを受信する工程と、
前記セッション・イニシェーション・プロトコル・メッセージ中に含まれるアプリケーション・リファレンスに基づいて、適切なアプリケーションを識別する工程と、
前記メッセージを前記アプリケーションに転送する工程と、を有する方法。
【請求項１０】
複数の通信サービスを、ＩＰマルチメディア・サブシステムまたはユーザ装置に関連付けることを可能にする方法であって、当該または各関連サービスを、セッション・イニシェーション・プロトコル・メッセージ中のフィーチャ・タグとして識別する工程を有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰマルチメディア・サブシステム（ＩＭＳ）サービスを識別する方法および装置に関し、特に、ＩＭＳ通信または通信リクエストが係わるＩＭＳサービスを識別する方法および装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディア・サービスは、同一セッション中に、音声、ビデオ、メッセージング、データ等を動的に提供する。基本アプリケーションの数、および組み合わせ可能なメディアの数が増大しているため、エンド・ユーザに提供されるサービスの数も増大し、個人間通信体験も豊富になっている。これにより、後に詳細に説明するいわゆる“組合せＩＰマルチメディア”を含む、個人化された豊富なマルチメディア通信サービスが誕生しつつある。
【０００３】
ＩＰマルチメディア・サブシステム（ＩＭＳ）は、移動通信ネットワークを介してＩＰマルチメディア・サービスを提供する第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって定義された技術である（３ＧＰＰ  ＴＳ２２．２２８，ＴＳ２３．２２８，ＴＳ２４．２２９，ＴＳ２９．２２８，ＴＳ２９．２２９，ＴＳ２９．３２８およびＴＳ２９．３２９リリース５およびリリース６）。ＩＭＳは、規格化されたＩＭＳサービス・イネーブラを使用してエンド・ユーザのパーソン・ツー・パーソン通信体験を豊富にするキー・フィーチャを提供しており、このキー・フィーチャは、ＩＰベースのネットワークを介したパーソン・ツー・コンテント（クライアント・ツー・サーバ）サービスだけでなく、新しい豊富なパーソン・ツー・パーソン（クライアント・ツー・クライアント）通信サービスを容易にする。ＩＭＳは、ユーザ・ターミナル間（またはユーザ・ターミナルとアプリケーション・サーバとの間）のコールまたはセッションをセットアップし制御するセッション・イニシェーション・プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングにより実行されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディア・コンポーネントを記述し、これとネゴシエーションするのに使用される。ＳＩＰは、ユーザ・ツー・ユーザ・プロトコルとして創作されたものであるが、ＩＭＳは、オペレータおよびサービス・プロバイダが、サービスに対するユーザ・アクセスを制御し、これに応じたユーザに対する課金を可能にする。
【０００４】
図１は、ＧＰＲＳ／ＰＳアクセス・ネットワークにおいて、ＩＭＳが移動ネットワーク・アーキテクチャにいかにして適合しているかを概略的に示している。コール／セッション・コントロール・ファンクション（ＣＳＣＦ）は、ＩＭＳに対するＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３つのタイプのＣＳＣＦ、すなわち、ＳＩＰターミナルに対するＩＭＳ内の第１のコンタクト・ポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザがサブスクライブしたサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを識別し、Ｐ−ＣＳＣＦを介してＳＩＰターミナルから受けたリクエストをそのＳ−ＣＳＣＦに転送する役割を有するインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）とを定義している。
【０００５】
ユーザは、規定されたＳＩＰ  ＲＥＧＩＳＴＥＲ（レジスター）方法を使用して、ＩＭＳに登録する。これは、ＩＭＳに加入し、ＳＩＰユーザ・アイデンティティに到着できるアドレスをＩＭＳに告知するメカニズムである。３ＧＰＰにおいては、ＳＩＰターミナルがレジストレーションを行うとき、ＩＭＳは、ユーザの真正を証明し、利用可能なＳ−ＣＳＣＦのセットの中からそのユーザに一つのＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は、３ＧＰＰによって規定されていないが、これらは、負荷共有およびサービス必要条件を含みうる。Ｓ−ＣＳＣＦを割り当てることは、ＩＭＳベースのサービスへのユーザ・アクセスの制御（および課金）のキーである。オペレータは、Ｓ−ＣＳＣＦをバイパスする直接ユーザ・ツー・ユーザＳＩＰセッションを防ぐメカニズムを提供することができる。
【０００６】
レジストレーション・プロセスの間、Ｓ−ＣＳＣＦがまだ選択されていなければ、Ｓ−ＣＳＣＦを選択するのは、Ｉ−ＣＳＣＦの責任である。Ｉ−ＣＳＣＦは、ホーム・ネットワークのホーム加入者サーバから必要なＳ−ＣＳＣＦ能力を受けて、受けた能力に基づいて適切なＳ−ＣＳＣＦを選択する。（ユーザが別のパーティによってコールされたが、そのユーザには現在Ｓ−ＣＳＣＦが割り当てられていない場合にも、Ｓ−ＣＳＣＦ割当は、ユーザのためにＩ−ＣＳＣＦによって実行されることに留意されたい。）登録されたユーザが、次に、セッション・リクエストをＩＭＳに送ると、Ｐ−ＣＳＣＦは、レジストレーション・プロセスの間Ｓ−ＣＳＣＦから受けた情報に基づいて、選択されたＳ−ＣＳＣＦにリクエストを転送できる。
【０００７】
ＩＭＳサービス・ネットワーク内に、ＩＭＳサービス・ファンクショナリティを実施するために、アプリケーション・サーバ（ＡＳ）が設けられる。アプリケーション・サーバは、ＩＭＳシステム内のエンド・ユーザにサービスを提供し、３ＧＰＰで規定されたＭｒインターフェースを介してエンド・ポイントとして、または３ＧＰＰで規定されたＩＳＣインターフェースを介してＳ−ＣＳＣＦによって“リンクド・イン”で接続される。後者の場合、ＳＩＰセッション確立の間、どのアプリケーション・サーバを“リンクド・イン”させるか決めるために、Ｓ−ＣＳＣＦによって初期フィルタ基準（ＩＦＣ）が使用される。ＩＦＣは、ＩＭＳレジストレーション・プロシージャの間、ユーザのユーザ・プロファイルの一部として、ＨＳＳからＳ−ＣＳＣＦによって受信される。
【０００８】
図２は、ＡＳとＳ−ＣＳＣＦとの間のＩＭＳサービス・コントロール（ＩＳＣ）インターフェースを、ＩＭＳ内の他のインターフェースとともに示している。図２には、Ｓ−ＣＳＣＦに単一のインターフェースのみが設けられているものとして示されているが、実際には、ＩＳＣインターフェースは、所与のオペレータのネットワークの多くの（または全ての）ＣＳＣＦサーバが接続された通信ネットワークにわたって張り渡され、ＡＳが全てのこれらのＣＳＣＦと通信することができることが理解されるだろう。
【０００９】
図には示されていないが、ＡＳとユーザ・ターミナル（ＴＳ２３．００２）との間には、別のインターフェース（Ｕｔ）が存在する。Ｕｔインターフェースは、ユーザが、ユーザのサービスに関連した情報を管理すること、すなわち、例えば、パブリック・サービス・アイデンティティの作成および割当、例えば“プレゼンス”サービスによって使用される権限付与ポリシーの管理、コンファレンス・ポリシー管理等を可能にする。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ＩＭＳサービスが必要とされる場合、異なる通信サービスが、ＩＭＳおよびユーザ・ターミナルによって異なる扱いを必要とすることが多い。より具体的には以下の通りである。
・異なるサービスが、ＩＳＣインターフェースを介して異なるアプリケーション・サーバの“リンキング・イン”を必要とするかもしれない。
・セッションが関係するサービスに応じて、セッションが、所与のユーザがＩＭＳに登録した異なるエンド・ユーザ・ターミナルへ向けたルートを通るかもしれない（例えば、分岐を回避するために、サービス・タイプへのターミナル能力適合を使用できる）。
・受信側のターミナル中の異なるファンクショナル・エンティティが、異なるサービスを取り扱うのに指定されるかもしれない（例えば、ＰｏＣおよびＰ２Ｐマルチメディア）。
・ネットワーク・オペレータが、異なるサービスに対して異なる権限付与レベルを有するかもしれない。
・異なるサービスに対して異なるメディア権限付与ポリシーが適用されるかもしれない。例えば、ＰｏＣ中の音声（オーディオ）は、Ｐ２Ｐマルチメディアと同じクオリティ・オブ・サービス・サポートを必要とせず、従って、それに応じたメディアが割り当てられるだろう。
・ネットワーク・オペレータが、そのＩＭＳサービスに応じて、異なる課金ルールを適用するかもしれない。
・サービス・インターワーキング要件（例えば、ＩＭＳ遅延メッセージング−ＭＭＳ）は、ＩＭＳサービスに依存するかもしれない。
【００１１】
ＳＩＰのセッション記述プロトコル（ＳＤＰ）は、ＩＭＳサービスのために使用されるメディアの初期タイプを規定するいわゆる“ｍ−ｌｉｎｅ”フィールドを詳細に記述している。例えば、“ｍ−ｌｉｎｅ”は、“ａｕｄｉｏ  ２００００  ＲＴＰ／ＡＶＰ  ０”または“ｖｉｄｅｏ  ２００００  ＲＴＰ／ＡＶＰ  ０”を特定できる。（“ｍ−ｌｉｎｅ”フォーマットは、ＩＦＴＦ  ＲＦＣ（２３２７）に規定されている。“２００００”は、使用されるべきポート番号、“ＲＴＰ”はプロトコルである。“ＡＶＰ”は、異なるプロトコルのために規定されており、“ＡＶＰ”に割り当てられる値は、プロトコルに応じて異なる意味を有する。例えば、ある特定値は、使用されるべきＣＯＤＥＣを示す。）従来、“ｍ−ｌｉｎｅ”情報は、ＩＭＳ通信サービス・タイプを識別できると考えられていた。しかしながら、ＩＭＳの成功は、同じメディア・タイプを有する多数の異なる通信サービスが存在することを意味する。例えば、ＰｏＣおよびパーソン・ツー・パーソン・マルチメディアがともに、“オーディオ”メディア・タイプを使用する可能性がある。従って、“ｍ−ｌｉｎｅ”情報は、ＩＭＳ通信サービスをユニークに識別することができない。この問題は、本発明の発明者によって、“ＩＭＳ通信サービス識別子（ＳｅｒｖＩＤ）”というタイトルの３ＧＰＰワーク・アイテム中で特定されている。
【課題を解決するための手段】
【００１２】
本発明の第１の側面によれば、セッション・イニシェーション・プロトコル・メッセージが関係するＩＰマルチメディア・サブシステム通信サービスを示す方法であって、前記セッション・イニシェーション・プロトコル・メッセージ中に、フィーチャ・タグとして、一つまたはそれ以上の通信サービス識別子を含ませる工程を有し、前記通信サービス識別子は、複数の通信サービスの一つを識別することを特徴とする方法が提供される。
【００１３】
ＳＩＰメッセージは、例えば、ＳＩＰ  ＲＥＧＩＳＴＥＲメッセージの場合、一つまたはそれ以上の通信サービス識別子をフィーチャ・タグとして含んでもよい。
【００１４】
フィーチャ・タグは、レジストレーションの間、Ｃｏｎｔａｃｔ  Ｈｅａｄｅｒ，Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダ中に含められてもよく、セッション確立の間、またはセッション・ベースではないＳＩＰメッセージ例えば“ＳＩＰ  Ｍｅｓｓａｇｅ”のためのメッセージ配達の間、呼び出し側プリファランスとして、含められてもよい。
【００１５】
本発明の第２の側面によれば、セッション・イニシェーション・プロトコル・メッセージが関係する、ユーザ・ターミナルに存在する、アプリケーションを識別する方法であって、前記セッション・イニシェーション・プロトコル・メッセージ中に、アプリケーション・リファレンスを含ませる工程を有することを特徴とする方法が提供される。
【００１６】
アプリケーション・リファレンスは、ＳＩＰメッセージ・ヘッダ中に、フィーチャ・タグとして含めてもよく、例えば、Ｒｅｇｉｓｔｅｒ  Ｍａｓｓａｇｅ中では、Ｃｏｎｔａｃｔヘッダ中に、他のＳＩＰメッセージ（例えば、ＩＮＶＩＴＥ（招待））中では、Ａｃｃｅｐｔ−ＣｏｎｔａｃｔまたはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダ中に含めてもよい。このようにする代わりに、アプリケーション・リファレンスは、ＳＩＰメッセージのＳＤＰ部分中に“ｍ−ｌｉｎｅ”を拡大する“ａ−ｌｉｎｅ”として含めてもよい。アプリケーション・リファレンスは、例えば、主アプリケーションおよび補助アプリケーションをともに識別するために、フィーチャ・タグとしてだけではなく、同じＳＩＰメッセージ中の“ａ−ｌｉｎｅ”としても、含めてもよい。
【００１７】
本発明の好ましい実施形態は、本発明の第１面と第２面を組み合わせる。ユーザ・ターミナルまたはＩＭＳネットワーク・ノードにおいて、ＩＭＳスタックは、受信したセッション・イニシェーション・プロトコル・メッセージ中に含まれている通信サービス識別子に基づいて、適切な通信サービスを識別し、当該メッセージを、このサービスを実行するファンクショナル・（ソフトウェア）エンティティに転送する。当該メッセージを受信した通信サービスは、セッション・イニシェーション・プロトコル・メッセージ中に含まれるアプリケーション・リファレンスに基づいて適切なアプリケーションを識別し、当該メッセージをそのアプリケーションに転送する。
【００１８】
本発明の第３の側面によれば、複数の通信サービスを、ＩＰマルチメディア・サブシステムまたはユーザ装置に関連付けることを可能にする方法であって、当該または各関連サービスを、セッション・イニシェーション・プロトコル・メッセージ中のフィーチャ・タグとして識別する工程を有することを特徴とする方法が提供される。
【００１９】
例えば、本発明は、複数の同時の行われるＩＭＳ通信サービス、例えば、Ｐ２ＰマルチメディアとＩＭＳメッセージングとを関連付けることを可能にし、および／または、ＩＭＳ通信サービスと、例えば回線接続スピーチのような他の同時に行われるサービスとを相互に関係付けることを可能にする。
【００２０】
本発明の好ましい実施形態においては、本発明の第３の面が、本発明の第１および第２の面の両方または一方と組み合わせられる。
【００２１】
本発明の他の側面には、以下のことが含まれる：
・ユーザ・ターミナルおよびネットワーク・ノードが、セッション・イニシェーション・プロトコル・メッセージ中に、通信サービス識別子を、そのメッセージのフィーチャ・タグとして挿入する手段を含む。
・ユーザ・ターミナルおよびネットワーク・ノードが、セッション・イニシェーション・プロトコル・メッセージ中に、アプリケーション・リファレンスを挿入する手段を含む。
・ユーザ・ターミナルおよびネットワーク・ノードが、セッション・イニシェーション・プロトコル・メッセージ中に挿入する手段を含む。
【００２２】
本発明のさらに別の側面によれば、一つまたはそれ以上の新たなＳＩＰ情報エレメント（パラメータ）が、通信サービス識別子、アプリケーション・リファレンス、およびＭＣＳクオリファイア（通信サービス関連識別子）の一つまたはそれ以上を実行するために標準化されてもよい。
【発明を実施するための最良の形態】
【００２３】
セッション・イニシェーション・プロトコル・メッセージに関係するＩＰマルチメディア・サブシステム（ＩＭＳ）の特定のサービスを識別できることは、多くの利点がある。これらは、既に上述した。ここでは、ＳＩＰメッセージ中に“通信サービス識別子”を含ませることにより、特に、通信サービス識別子をフィーチャ・タグとして含ませることにより、識別を容易にすることを提案する。
【００２４】
適切なフィーチャ・タグは、“Ｃａｌｌｅｒ  Ｐｒｅｆｅｒｅｎｃｅ”の一つとして、ＳＩＰメッセージのＣｏｎｔａｃｔ（Ｒｅｇｉｓｔｅｒ），Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダの一つに含まれる。サービス識別子の例は、次の通りである。
"+g.communication service=+g.p2p.multimedia"
"+g.communication service=+g.poc.talkburst"
"+g.communication service=+g.instant.messaging"
"+g.communication service=+g.deferred.multimedia.messaging"
ここで、接尾辞、例えば”multimedia”は、ＩＭＳ通信サービスを示す。
【００２５】
図３は、通信サービス識別子をＣｏｎｔａｃｔヘッダ中に含ませることにより、メッセージ・センダー（ユーザ装置）によってサポートされた通信サービスを識別するＳＩＰ  ＲＥＧＩＳＴＥＲのストラクチャを（部分的に）示す。Ｒｅｇｉｓｔｅｒ  Ｍｅｓｓａｇｅ中のフィーチャ・タグは、ターミナルの能力をネットワークに告知する。ネットワークは（例えば、Ｓ−ＣＳＣＦにおいて）、受信側で登録されたターミナルのセットの中から、ＳＩＰセッションのオリジネータによって示された（要求された）発信側プリファランスに最も適合したものを見つけるために、この情報を使用できる。この例では、サポートされているサービスは、“ｍｕｌｔｉｍｅｄｉａ（マルチメディア）”，“ｔａｌｋｂｕｒｓｔ（トークバースト）”および“ｍｕｌｔｉｍｅｄｉａ  ｍｅｓｓａｇｉｎｇ（マルチメディア・メッセージング）”である。このようなＲＥＧＩＳＴＥＲメッセージは、ＵＥによってサービング・コール／セッション・コントロール・ファンクション（Ｓ−ＣＳＣＦ）に送られる。
【００２６】
図４は、特定のＩＭＳ通信サービスを開始するのに使用されるＳＩＰ  ＩＮＶＩＴＥメッセージのストラクチャを（部分的に）示す。ＩＮＶＩＴＥメッセージは、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダ中で、イニシェーテイングＵＥによってサポートされるメディア、すなわち、メッセージが関係するサービスすなわちパーソン・ツー・パーソン（Ｐ２Ｐ）・マルチメディアだけでなく、オーディオ、ビデオ、データ等を識別する。ＳＤＰメッセージ部分の“ｍ−ｌｉｎｅ”は、最初のセッションは、オーディオのみのセッションであることを示す。Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダ中で識別される他のメディア、ビデオおよびデータは、セッションで使用されるが最初は使用されない。このメッセージの最終受信体は、例“ＳＩＰ  ＵＲＩ  ＳＩＰ−ＵＲＩ１＠ｏｐｅｒａｔｏｒ．ｃｏｍ”によって特定されたピアＵＥである。しかしながら、イニシェーティングＵＥをサービスしているＳ−ＣＳＣＦがメッセージを検査して、通信サービス識別子によって特定されたサービスに応じて、当該メッセージを転送するか否かを決定する。この加入者が、Ｐ２Ｐマルチメディア・サービスを使用する権限が付与されていれば、このＩＮＶＩＴＥメッセージは、受信体であるＵＥに転送される（必要ならば、能力ベースで選択されて）。課金も、また、そのサービスとそのＳＩＰメッセージ・パスとの少なくともいずれかにリンクド・インされたＳＩＰ  ＡＳに基づいて開始される。
【００２７】
上述のアプローチの改良として、フィーチャ・タグ中の通信サービス識別子に関連バージョン番号を付けることができる。
【００２８】
典型的ＵＥにおいては、特定の（規格化された）通信サービスは、多くの場合ターミナル・ベンダーによって“本来的に”提供されるアプリケーションによって取り扱われる。これらのアプリケーションは、特定の合意された規格に適合しており、ここでは、規格化ＩＭＳ通信サービスのための“デフォルト”アプリケーションと呼ぶことにする。例えば、Ｐ２ＰマルチメディアやＰｏＣセッションを扱うアプリケーションが、デフォルト・アプリケーションである。例えば、ゲームに関するアプリケーション、会社特有のオフィス・アプリケーション等のＵＥに存在する他のアプリケーションは、規格化されていない可能性がある。図５は、ＩＭＳスタックの最上位置に、ＵＥに存在するアプリケーションおよび通信サービスを示す。
【００２９】
特定の通信サービスを取り扱うのに使用するアプリケーションを、“アプリケーション・リファレンス”によって、ＳＩＰメッセージ中で特定できると便利である。これは、ＩＭＳ通信サービスが、その通信サービスのために規定されたルール、プロシージャおよび関連メディアに従って、アプリケーションが通信するのを許可するときに有効である。ＩＭＳ通信サービスを使用するが、そのサービスのＳＩＰ通信部分を実装していないアプリケーションは、内部インターフェースを介してこの目的のための通信サービスを使用する（処理を荷負わせる（ｐｉｇｇｙｂａｃｋｓ  ｏｎ“））。アプリケーション・リファレンスは、通信サービスのトップに位置するアプリケーションを識別する。なお、アプリケーションは、そのアプリケーションの専権であるＳＩＰベースの通信を実装することが可能であり、この場合、アプリケーションは、通信サービス識別子によって識別される。このことが、図６に示されている。
【００３０】
アプリケーション・リファレンスは、フィーチャ・タグとして、あるいは、ＳＩＰメッセージのＳＤＰ部分中の“ｍ−ｌｉｎｅ”拡大“ａ−ｌｉｎｅ”として実装できる。ともに、有利な点および不利な点がある。
【００３１】
フィーチャ・タグとしてのアプリケーション・リファレンス
アプリケーション・リファレンスをフィーチャ・タグとして含むと、そのメカニズムが全てのＳＩＰ  Ｍｅｓｓａｇｅ（すなわち、ＳＤＰを実行するもののみではない）に使用できる利点がある。このメカニズムは、また、通信サービスを確立するにはどのアプリケーションを使用すべきかを、受信体エンド・ポイントに示す。このアプリケーションがこのセッションの“主”アプリケーションであり、それに付随するメディアを管理する。しかし、このメカニズムは、セッション確立においてのみ使用でき、例えば、特定のファンクショナリティのためにＲｅ−ｉｎｖｉｔｅにおいてどのメディアを使用すべきか明確にするために、セッション確立の間に“サブ−ファンクショナリティ”を示すのに適していない。例えば、フィーチャ・タグ・アプローチを使用すること自体、「メッセージ・セッション・リレー・プロトコル（ＭＲＳＰ）が“ホワイトボーディング（Ｗｈｉｔｅｂｏａｒｄｉｎｇ）”に使用すべきで“ピクチュアビューア（ＰｉｃｔｕｒｅＶｉｅｗｅｒ）”には使用すべきでない」という表現は許されない。
【００３２】
ＳＤＰ中のｍ−ｌｉｎｅ拡大ａ−ｌｉｎｅとしてのアプリケーション・リファレンス
このメカニズムは、確立されたＳＩＰセッション中に“サブ−ファンクショナリティ”をアドレスできる利点がある。受信体アプリケーションは、使用されるべき初期メディアを示すｍ−ｌｉｎｅに続くａ−ｌｉｎｅに表現される。しかし、このメカニズムは、ＳＤＰボデイを担持するＳＩＰメッセージのみに使用できるだけである（例えば、ＳＩＰ  Ｍｅｓｓａｇｅには使用できない）。
【００３３】
これら２つのアプローチを組み合わせることにより、上記不利な点を回避できる。従って、アプリケーション・リファレンスが、フィーチャ・タグとしておよびＳＤＰボデイ中に転送を許容されることを提案する。フィーチャ・タグは、セッションのための“主アプリケーション”を示すのに使用される。規格化された通信サービスにとって、これは、“デフォルト・アプリケーション”であり、その値は、通信サービス識別子と同じにセットされる。例えば、
"Communication Service Identifier=P2P Multimedia
Application Reference=P2P Multimedia"
もちろん、アプリケーションがデフォルト・アプリケーションであるときには、アプリケーション・リファレンスを省略することができる。
【００３４】
規格化通信サービスを使用するオペレータまたはベンダー特定アプリケーションに対しては、アプリケーション・リファレンスは、このアプリケーションの名前を含む。例えば、
"Communication Service Identifier=P2P Multimedia
Application Reference=OperatorOfficeHelper"
【００３５】
ＳＩＰメッセージ・タイプがＳＤＰボデイを担持していない（例えば、ＳＩＰ  Ｍｅｓｓａｇｅ）とき、フィーチャ・タグは、受信体アプリケーションをアドレスするのに常に使用される。
【００３６】
ＳＩＰメッセージ・タイプがＳＤＰボデイを担持しているとき（例えば、Ｉｎｖｉｔｅ）とき、ＳＤＰボデイ中のａ−ｌｉｎｅは、ｍ−ｌｉｎｅが使用されるコンテキストを明確化するようにｍ−ｌｉｎｅを拡大するのに使用される。
【００３７】
図７は、ＳＩＰ  ＲＥＧＩＳＴＥＲメッセージのストラクチャを示し、ここでは、送信側ＵＥによってサポートされた通信サービスを識別するフィーチャ・タグが、Ｃｏｎｔａｃｔヘッダ中で識別される。図８は、イニシェーテイングＵＥと、ＳＩＰ  ＵＲＩ１＠ｏｐｅｒａｔｏｒ．ｃｏｍというＳＩＰ  ＵＲＩによって特定されたＵＥとの間のセッションを開始するＳＩＰ  ＩＮＶＩＴＥメッセージ・ストラクチャを示す。通信サービス識別子（＋ｇｐ２ｐ．ｍｕｌｔｉｍｅｄｉａ）は、フィーチャ・タグとして含められ、アプリケーション・リファレンス（＋ｇｃｏｍｍｕｎｉｃａｔｉｏｎ  ｓｅｒｖｉｃｅ）は、主アプリケーションを識別するために、第２フィーチャ・タグとして含められている。“ａ−ｌｉｎｅ”は、主アプリケーションによって同じセッションにリンクド・インされる別のアプリケーション（“３ｇｐｐ．ＶｉｄｅｏＳｈａｒｉｎｇ”）を識別するために含められる。
【００３８】
アプリケーションに関連した同時に生じる通信サービス（ＩＭＳサービスと、回線接続（ＣＳ）スピーチのような他のサービスとをともに）を、ＩＭＳ内およびＵＥにおいて識別できる必要がある。ここで“ＭＣＳクオリファイア”と呼ばれる識別子が、いくつかの同時に発生するＩＭＳ通信サービス・セッション（例えば、Ｐ２ＰマルチメディアおよびＩＭＳメッセージング）を相互に関連付け、ＩＭＳ通信サービスを他の非ＩＭＳ通信サービス例えばＣＳスピーチに相互に関連付けることができるアプリケーションを提供する。
【００３９】
ＭＣＳクオリファイアは、例えばセッションに適用される料金を決定するのに使用できる。一つの例においては、ＣＳスピーチは、組合せサービス（ＣＳＩ）態様で実施されるビデオ共用のために、ＩＭＳ  Ｐ２Ｐマルチメディア・サービスと組み合わされる。ＭＣＳクオリファイアが存在することにより、ネットワークは料金を決定でき、ビデオ伝送に対するＩＭＳ通信部分につき異なる料金請求規則および料率を適用でき、ビデオがＩＭＳ上を“非ＣＳＩコンテキスト”で、すなわち“スタンドアローン・コンテキスト”で伝送されるときに適用されるものとは異なる料金請求規則および料率を適用できる。
【００４０】
図９は、特定のアプリケーション、この場合、ネットワーク・オペレータ特定ヘルプ・アプリケーション“オペレータ・オフィス・ヘルパー（ＯｐｅｒａｔｏｒＯｆｆｉｃｅＨｅｌｐｅｒ）”が、ＩＭＳ通信サービスＰ２Ｐマルチメディア、およびＣＳスピーチ・サービスを使用する例を示す。有意義な通信を行うために、“オペレータ・オフィス・ヘルパー（ＯｐｅｒａｔｏｒＯｆｆｉｃｅＨｅｌｐｅｒ）”は、通信に関与するターミナルにインストールされなければならない。アプリケーション・リファレンスが、“オペレータ・オフィス・ヘルパー（ＯｐｅｒａｔｏｒＯｆｆｉｃｅＨｅｌｐｅｒ）”にセットされ、フィーチャ・タグとして符号化される。通信サービス識別子は、Ｐ２Ｐマルチメディアにセットされ、ＭＣＳクオリファイアが、ＩＭＳＰ２ＰマルチメディアおよびＣＳスピーチにセットされる。このマルチプル通信サービス識別子を組み入れたＳＩＰ  ＩＮＶＩＴＥストラクチャが、図１０に示されている。
【００４１】
図１１は、ＣＳスピーチおよびＰ２Ｐマルチメディア・サービスと組み合わされて送信されるＳＩＰ  Ｍｅｓｓａｇｅストラクチャの一例を示す。この例では、ＳＩＰ  Ｍｅｓｓａｇｅは、ＩＭＳメッセージング通信サービスとともに送られるものと仮定する。ＳＩＰ  Ｍｅｓｓａｇｅは、次のパラメータを担持する。
Communication Service Id=IMS Messaging
Application Reference=OperatorOfficeHelper
MCS-Qualifiers, CS-Speech, P2P Multimedia, IMS Messaging
【００４２】
当業者には、本発明の範囲を逸脱することなく、上述の実施形態に種々の変更を加えることができることを理解できるであろう。例えば、ＳＩＰメッセージ中の、通信サービス識別子、アプリケーション・リファレンスおよびＭＣＳクオリファイアを表現するのに、他のメカニズムを使用できる。特に、この目的のために、新たなＳＩＰ情報エレメント（ヘッダ／パラメータ）を定義できる。
【図面の簡単な説明】
【００４３】
【図１】ＩＰマルチメディア・サブシステムの３Ｇ移動通信システムへのインテグレーションを概略的に示す図である。
【図２】アプリケーション・サーバおよびサービング・コール／状態・コントロール・ファンクションを含むＩＰマルチメディア・サブシステムの特定のエンティティを概略的示す図である。
【図３】通信サービス識別子を組み入れたＳＩＰ  ＲＥＧＩＳＴＥＲメッセージの例を示す図である。
【図４】通信サービス識別子を組み入れたＳＩＰ  ＩＮＶＩＴＥメッセージの例を示す図である。
【図５】通信サービス識別子およびアプリケーション・リファレンスを使用するＵＥアーキテクチャを概略的に示す図である。
【図６】あるアプリケーションがそのアプリケーション専権のＳＩＰベースの通信を実行するターミナル・アーキテクチャを概略的に示す図である。
【図７】通信サービス識別子およびアプリケーション・リファレンスを組み入れたＳＩＰ  ＲＥＧＩＳＴＥＲメッセージの例を示す図である。
【図８】通信サービス識別子およびアプリケーション・リファレンスを組み入れたＳＩＰ  ＩＮＶＩＴＥメッセージの例を示す図である。
【図９】通信サービス識別子、アプリケーション・リファレンスおよびマルチプル通信サービス・クオリファイアを使用するＵＥアーキテクチャを概略的に示す図である。
【図１０】通信サービス識別子、アプリケーション・リファレンスおよびマルチプル通信サービス・クオリファイアを組み入れたＳＩＰ  ＩＮＶＩＴＥメッセージの例を示す図である。
【図１１】通信サービス識別子、アプリケーション・リファレンスおよびマルチプル通信サービス・クオリファイアを組み入れたＳＩＰ  Ｍｅｓｓａｇｅの例を示す図である。
【図１】
2008543133.tif 000003
【図２】
2008543133.tif 000004
【図３】
2008543133.tif 000005
【図４】
2008543133.tif 000006
【図５】
2008543133.tif 000007
【図６】
2008543133.tif 000008
【図７】
2008543133.tif 000009
【図８】
2008543133.tif 000010
【図９】
2008543133.tif 000011
【図１０】
2008543133.tif 000012
【図１１】
2008543133.tif 000013
【手続補正書】
【提出日】平成19年1月29日(2007.1.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
セッション・イニシェーション・プロトコル・メッセージが関係するＩＰマルチメディア・サブシステム通信サービスとターミナル・アプリケーションとを示す方法であって、
前記セッション・イニシェーション・プロトコル・メッセージ中に、１以上の通信サービス識別子を含ませる工程を有し、
前記通信サービス識別子は、複数の通信サービスの一つを識別し、前記メッセージ中のアプリケーション・リファレンスを含み、
前記アプリケーション・リファレンスは前記識別された通信サービスを処理するために使用されるターミナル・アプリケーションを識別することを特徴とする方法。
【請求項２】
前記１以上の通信サービス識別子は、前記セッション・イニシェーション・プロトコル・メッセージ中にフィーチャ・タグとして含まれることを特徴とする請求項１に記載の方法。
【請求項３】
前記フィーチャ・タグは、セッション・イニシェーション・プロトコル・メッセージのＣｏｎｔａｃｔ，Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダの一つに含まれていることを特徴とする請求項２に記載の方法。
【請求項４】
前記アプリケーション・リファレンスは、前記セッション・イニシェーション・プロトコル・メッセージのヘッダ中に、フィーチャ・タグとして含まれていることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記フィーチャ・タグは、セッション・イニシェーション・プロトコル・メッセージのＣｏｎｔａｃｔ，Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ，またはＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダの一つに含まれていることを特徴とする請求項４に記載の方法。
【請求項６】
前記アプリケーション・リファレンスは、前記セッション・イニシェーション・プロトコル・メッセージのセッション記述部分中の、“ｍ−ｌｉｎｅ”を拡大する“ａ−ｌｉｎｅ”として含まれていることを特徴とする請求項１に記載の方法。
【請求項７】
複数のアプリケーション・リファレンスが、前記セッション・イニシェーション・プロトコル・メッセージ中に、フィーチャ・タグおよびａ−ｌｉｎｅの両方として含まれていることを特徴とする請求項１に記載の方法。
【請求項８】
フィーチャ・タグとして含まれる前記アプリケーション・リファレンスは主アプリケーションを識別し、ａ−ｌｉｎｅに含まれるアプリケーション・リファレンスは補助アプリケーションを識別することを特徴とする請求項７に記載の方法。
【請求項９】
ユーザ・ターミナルまたはＩＭＳネットワーク・ノードを動作させる方法であって、
ＩＭＳスタックにおいて、受信したセッション・イニシェーション・プロトコル・メッセージ中に含まれる通信サービス識別子に基づいて、適切な通信サービスを識別する工程と、
前記メッセージを前記サービスへ転送する工程と、
前記識別された通信サービスにおいて前記メッセージを受信する工程と、
前記セッション・イニシェーション・プロトコル・メッセージ中に含まれるアプリケーション・リファレンスに基づいて、適切なアプリケーションを識別する工程と、
前記メッセージを前記アプリケーションに転送する工程と、を有する方法。
【国際調査報告】
2008543133.tif 000014
2008543133.tif 000015
2008543133.tif 000016
2008543133.tif 000017
2008543133.tif 000018