(57)【要約】ＩＰマルチメディアサブシステム内におけるセション開始プロトコルの通信を処理する方法であって、その通信はセション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従う。その方法は、ＩＮＶＩＴＥのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能において、ＩＮＶＩＴＥを受信する工程と、サービング呼／状態制御機能において、元々の対話識別子と共にサービング呼／状態制御機能のＲ−ＵＲＩをＩＮＶＩＴＥのルートヘッダに追加し、サービング呼／状態制御機能において元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを保持する工程とを含む。そのＩＮＶＩＴＥは前記アプリケーションサーバに転送され、呼を転送されることになるユーザ機器のＵＲＩに、Ｒ−ＵＲＩを変更する。転送指示情報をＩＮＶＩＴＥのヘッダに追加し、そのＩＮＶＩＴＥをサービング呼／状態制御機能に返送する。サービング呼／状態制御機能において、前記転送指示情報の存在が識別され、応答として返送されたＩＮＶＩＴＥに含まれる元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別する。元々のＲ−ＵＲＩに基づいて、呼の制限とＩＦＣとが識別される。
2008543135.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、元々の対話識別子と共に前記サービング呼／状態制御機能のＵＲＩを前記メッセージのルートヘッダに追加し、前記元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを前記サービング呼／状態制御機能において維持する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記呼が転送されることになるユーザ機器のＵＲＩに前記メッセージにおける前記Ｒ−ＵＲＩを変更し、前記メッセージに転送指示情報を追加して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記転送指示情報の存在を識別し、応答として、前記返送されたメッセージに含まれる前記元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項２】
前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記転送指示情報は、前記ルートヘッダに含まれることを特徴とする請求項１又は２に記載の方法。
【請求項４】
Ｐ−アサート・アイデンティティは前記Ｓ−ＣＳＣＦにおいて受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバであって、
転送指示情報と呼が転送されることになるユーザ機器を識別するＲ−ＵＲＩを含むように、受信されたセション開始プロトコルメッセージを修正することにより、呼転送動作を実施するための処理手段を有することを特徴とするアプリケーションサーバ。
【請求項６】
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバから受信されたセション開始プロトコルメッセージを処理するための処理手段を有するサービング呼／状態制御装置であって、
前記処理手段は、ルートヘッダがセション開始プロトコルのアプリケーションサーバにより追加された転送指示情報を含むかどうかを判断するように動作し、
前記処理手段は、前記ルートヘッダが転送指示情報を含めば、前記受信したメッセージに含まれる元々の対話識別子に基づいて元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩに依存して発信手順に従って前記メッセージを処理することを特徴とするサービング呼／状態制御装置。
【請求項７】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージのＰ−アサート・アイデンティティを前記Ｒ−ＵＲＩに変更して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記Ｐ−アサート・アイデンティティのフィールドに含まれる前記Ｒ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項８】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージに転送指示情報を追加し、最上位エントリとして転送ユーザ機器のＳＩＰ  ＵＲＩを含む履歴情報ヘッダを追加する工程と、
前記サービング呼／状態制御機能に前記メッセージを転送する工程と、
前記サービング呼／状態制御機能において、前記メッセージにおける前記転送指示情報の存在を識別し、前記履歴情報ヘッダに含まれるＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項９】
前記転送指示情報は、前記メッセージの前記ルートヘッダに含まれることを特徴とする請求項８に記載の方法。
【請求項１０】
前記サービング呼／状態制御機能において受信した前記メッセージを処理する工程は、元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項７乃至９のいずれか１項に記載の方法。
【請求項１１】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、前記Ｒ−ＵＲＩを格納する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、呼を転送することになるユーザ機器のＲ−ＵＲＩに前記メッセージのＲ−ＵＲＩを変更する工程と、
前記サービング呼／状態制御機能において、前記メッセージのＲ−ＵＲＩにおける変化を識別し、応答として、元々のＲ−ＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項１２】
前記セション開始プロトコルのメッセージは、初期要求メッセージ或いは独立のメッセージであることを特徴とする請求項１乃至４、或いは請求項７乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記セション開始プロトコルのメッセージは、ＩＮＶＩＴＥメッセージであることを特徴とする請求項１２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）における呼転送に関し、特に、ＩＭＳ内のサービング呼／セション制御機能における呼転送に関係するセション開始プロトコルメッセージを取り扱う方法及び装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディアサービスは同じセションの中で音声、ビデオ、メッセージング、データなどの動的組み合わせを提供する。基本アプリケーションと、組み合わせ可能なメディアの数を増やすことにより、エンドユーザに提供されるサービスの数が増え、個人間の通信経験が豊かになるであろう。これは、以下でさらに詳細に考慮する所謂“組み合わせＩＰマルチメディア”サービスを含む、個人的で豊かなマルチメディア通信サービスの新世代に繋がるであろう。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動体通信ネットワーク（３ＧＰＰ  ＴＳ２２．２２８、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９リリース５及びリリース６）によりＩＰマルチメディアサービスを提供するために第３世代パートナシッププロジェクト（３ＧＰＰ）により定義される技術である。ＩＭＳはエンドユーザの人対人の通信経験を豊かにする重要な特徴を標準化されたＩＭＳサービスイネイブラ（Enablers）の使用を通じて提供する。この標準化されたＩＭＳサービスイネイブラ（Enablers）はＩＰベースのネットワークにより、新しく豊かな人対人（クライアント対クライアント）の通信サービスとともに、人対コンテンツ(クライアント対サーバ）サービスをも容易にする。ＩＭＳはユーザ端末（またはユーザ端末とアプリケーションサーバ)間の呼やセションをセットアップし、制御するためのセション開始プロトコル（ＳＩＰ）を利用する。ＳＩＰシグナリングにより搬送されるセション記述プロトコル（ＳＤＰ）が用いられて、セションのメディア構成要素を記述し、ネゴシエートする。ＳＩＰはユーザ対ユーザのプロトコルとして創成されたが、ＩＭＳによりオペレータおよびサービスプロバイダがサービスへのユーザアクセスを制御し、これに従いユーザに課金することを可能にする。
【０００４】
図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合、移動体ネットワークアーキテクチャにＩＭＳがどのように適合するのかを概略的に示している。呼／セション制御機能（ＣＳＣＦｓ）はＩＭＳによるＳＩＰプロキシとして動作する。３ＧＰＰのアーキテクチャは３つのタイプのＣＳＣＦｓを定義する。即ち、ＳＩＰ端末にとりＩＭＳ内における最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザが加入するサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを識別し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信した要求をそのＳ−ＣＳＣＦに転送する役割をもつ問い合わせを行うＣＳＣＦ（Ｉ−ＣＳＣＦ）である。
【０００５】
指定されたＳＩＰ  ＲＥＧＩＳＴＥＲ方法を使用して、ユーザはＩＭＳに登録する。これは、ＩＭＳに所属し、ＳＩＰユーザのアイデンティティに到達できるアドレスをＩＭＳに知らせる機構である。ユーザはＳ−ＣＳＣＦから固有のＵＲＩを受信し、Ｓ−ＣＳＣＦは対話を始める場合に固有のＵＲＩを使用するであろう。３ＧＰＰでＳＩＰ端末が登録を行う場合、ＩＭＳはそのユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからそのユーザにＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰにより規定されていないが、これらは負荷分担およびサービス要求を含むことができる。なお、Ｓ−ＣＳＣＦの割り当てがＩＭＳベースのサービスへのユーザアクセスの制御（およびその課金）に重要である。オペレータは直接のユーザ対ユーザＳＩＰセションを防止する機構を提供することができ、さもなければユーザ対ユーザＳＩＰセションはＳ−ＣＳＣＦをバイパスするであろう。
【０００６】
Ｓ−ＣＳＣＦが既に選択されていなければ、登録の過程でＳ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの責任である。Ｉ−ＣＳＣＦはホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要なＳ−ＣＳＣＦの能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。[なお、ユーザが別の相手により呼を受け、現在ユーザがＳ−ＣＳＣＦを割り当てられていない場合、Ｓ−ＣＳＣＦのユーザへの割り当てもＩ−ＣＳＣＦにより実行される。]  登録したユーザがその後セション要求（例えば、ＳＩＰ  ＩＮＶＩＴＥ）をＩＭＳに送信する場合、その要求はＰ−ＣＳＣＦ及びＳ−ＣＳＣＦ  ＵＲＩを含み、その結果、Ｐ−ＣＳＣＦはその要求を選択されたＳ−ＣＳＣＦに転送することができる。これは（ＩＭＳの）発信側および着信側の両方に当てはまる。［着信呼の場合、その要求はＰ−ＣＳＣＦアドレスとＵＥアドレスとを含むであろう］。
【０００７】
ＩＭＳサービスネットワーク内では、ＩＭＳサービスの機能を実現するために、アプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバはＩＭＳシステムのエンドユーザにサービスを提供し、３ＧＰＰの定義するＭｒインタフェースによりエンドポイントとして接続するか、または３ＧＰＰの定義するＩＳＣインタフェースによりＳ−ＣＳＣＦにより“リンクイン”されても良い。後者の場合、初期フィルタ基準（ＩＦＣ）がＳ−ＣＳＣＦにより使用され、ＳＩＰセション確立中にどのアプリケーションサーバが“リンクイン”されるべきなのかを決定する。ＩＭＳ登録手順の過程でユーザのユーザプロファイルの一部として、ＩＦＣがＨＳＳからＳ−ＣＳＣＦにより受信される。
【０００８】
ＥＴＳＩ  ＴＩＳＰＡＮとして知られるワーキンググループは、固定広帯域アクセスに対するＩＭＳの使用を開発している。そのタスクの１つは、３ＧＰＰにより定義されるＩＭＳに基づいて補完的サービスを開発することである。これら補完的サービスは、ＴＳ２４．２２９などのコア技術仕様に影響するであろうが、別の技術仕様において定義されるであろう。図２は、ＴＳ２４．２２９（第５．４．３．２節）に従う呼の発信側におけるＩＭＳ内のＳＩＰ  ＩＮＶＩＴＥのメッセージフローを模式的に図示している。ステップ１）において、ＩＮＶＩＴＥが発信元のユーザ機器（ＵＥ）からＰ−ＣＳＣＦに送信される。このＩＮＶＩＴＥはそのヘッダに所謂、Ｐ−プリファードアイデンティティを含むとともに、ＳＩＰルートヘッダの最上位レベルにＰ−ＣＳＣＦのＵＲＩと第２のエントリとしてＳ−ＣＳＣＦのＵＲＩを含む。ＵＥはまた、要求ＵＲＩに通信相手のアイデンティティを含む。ＩＮＶＩＴＥを受信すると、Ｐ−ＣＳＣＦは、発信元のＵＥがＰ−プリファードアイデンティティとして含まれるアイデンティティを使用することが許可されていることを調べ、もし許可されていれば、そのアイデンティティをＰ−アサート・アイデンティティとして出力するＩＮＶＩＴＥに含ませる。Ｐ−アサート・アイデンティティは、信頼されたＳＩＰエンティティ、通常は中継者の間で使用され、それが認証により検証されたとき、ＳＩＰメッセージを送信するユーザのアイデンティティを搬送するアイデンティティである。Ｐ−ＣＳＣＦはルートヘッダを見ることにより発信元ＵＥに割り当てられたＳ−ＣＳＣＦを識別し、ステップ２）で、そのＳ−ＣＳＣＦに修正されたＩＮＶＩＴＥを転送する。
【０００９】
Ｓ−ＣＳＣＦは発信呼の手順に従って呼を処理する。Ｓ−ＣＳＣＦはＰ−アサート・アイデンティティを使用して、何か関係する制限が発信元ＵＥに設定されているかどうか、例えば、ＵＥが要求サービスの使用を禁止されているかどうかをチェックする。Ｓ−ＣＳＣＦはまた、Ｐ−アサート・アイデンティティを使用して、そのＵＥに対するＩＦＣを決定する。図２の例では、ＩＦＣはＳ−ＣＳＣＦがＩＮＶＩＴＥを特定のＡＳに転送する（ステップ３））ことを要求するものと想定する。Ｓ−ＣＳＣＦはＳＩＰルートヘッダの最上位レベルにＡＳのＵＲＩを含む。Ｓ−ＣＳＣＦはまた、元々の対話識別子（ＯＤＩ）と共に、それ自身のＵＲＩを次位レベルに含む。ＯＤＩはＳ−ＣＳＣＦにより生成され、Ｓ−ＣＳＣＦへの呼をユニークに識別する。ＡＳがＩＮＶＩＴＥをＳ−ＣＳＣＦに返信する（ステップ４））とき、そのＡＳはルートヘッダからＡＳのＵＲＩを取り除き、ＯＤＩのタグと共にＳ−ＣＳＣＦのＵＲＩを残す。ＯＤＩのタグにより、Ｓ−ＣＳＣＦがそのＩＮＶＩＴＥが以前の対話に関係すると判断することが可能になる。
【００１０】
ＡＳのロジックが新しいセションのセットアップを要求することは可能である。この場合、発信元のアイデンティティ、即ち、ステップ４）におけるＩＮＶＩＴＥのＰ−アサート・アイデンティティは、発信元ＵＥのアイデンティティ、ＡＳのアイデンティティ、或いは、ＡＳが新しいセションを設定しようとする第３の相手のアイデンティティでありうる。この場合、Ｓ−ＣＳＣＦは呼制限のチェックを繰り返し、“新しい”ＩＮＶＩＴＥに含まれるＰ−アサート・アイデンティティに基づいてＩＦＣを決定するであろう。ＩＦＣに基づいて、さらにリンクインするＡＳがないと仮定し、Ｓ−ＣＳＣＦはＩＮＶＩＴＥに含まれる要求ＵＲＩ（Ｒ−ＵＲＩ）にそのＩＮＶＩＴＥを転送する。これは、元々のＩＮＶＩＴＥに含まれるＲ−ＵＲＩ、或いは、それが異なるならば新しいＩＮＶＩＴＥに含まれる新規Ｒ−ＵＲＩであるかもしれない。
【００１１】
図３は、呼の着信側におけるＩＭＳ内のＳＩＰ  ＩＮＶＩＴＥのメッセージフローを模式的に図示している（ＴＳ２４．２２９の第５．４．３．２節）。ステップ１）で被呼者を示すＲ−ＵＲＩを含むＩＮＶＩＴＥがＩ−ＣＳＣＦ（不図示）から着信する。Ｓ−ＣＳＣＦはこのＵＲＩを使用し、被呼者に設定された制限をチェックし、ＩＦＣを取得する。この場合、ＩＦＣはＡＳにコンタクトする必要があることを示唆しない。Ｓ−ＣＳＣＦはＲ−ＵＲＩに基づいて、被呼者についての事前にロードしたルートヘッダを獲得し、これらのルートヘッダのエントリに基づいてＩＮＶＩＴＥをＵＥに転送するであろう。Ｓ−ＣＳＣＦにおける事前にロードされたルートに従って、ＩＮＶＩＴＥはＰ−ＣＳＣＦにより受信され、Ｐ−ＣＳＣＦはコンタクトヘッダに従ってＵＥにＩＮＶＩＴＥを送信する。
【００１２】
図４は、代替のＩＮＶＩＴＥメッセージフローのシナリオを図示している。ここでは、発信元端末（ＵＥ−Ｏ）からピア端末（ＵＥ−Ｆ）への呼が着信端末（ＵＥ−Ｔ）に転送される。呼転送動作はアプリケーションサーバ（ＡＳ−Ｆ）により実行される。呼のフローは以下の通りである。
【００１３】
１）ＩＮＶＩＴＥをＵＥ−ＯからＵＥ−Ｆ（Ｒ−ＵＲＩ）に宛てて送信する。Ｓ−ＣＳＣＦ  Ｏは、図２を参照して記述したように発信側の呼の手順を実行する。
【００１４】
２）ＡＳ−Ｏとの相互動作の後（この段階でＲ−ＵＲＩに対して変更を行わない）、Ｓ−ＣＳＣＦ  ＯはＵＥ−ＦのホームネットワークのＩ−ＣＳＣＦ（不図示）にＩＮＶＩＴＥを送信する。Ｉ−ＣＳＣＦは、ＵＥ−ＦがＨＳＳから登録されるＳ−ＣＳＣＦのアドレスを取得する。ＩＮＶＩＴＥはそのＳ−ＣＳＣＦ、即ち、Ｓ−ＣＳＣＦ  Ｆに送信される。Ｓ−ＣＳＣＦ  Ｆは制限要求をチェックし、（着信側の場合について）図３を参照して上記したように、即ち、ＩＮＶＩＴＥに含まれるＲ−ＵＲＩに基づいてＩＦＣを獲得するであろう。図４に図示されたシナリオでは、呼転送が起動されるＡＳ−ＦにＩＮＶＩＴＥが送信される。
【００１５】
３）ＡＳ−ＦはＩＮＶＩＴＥのヘッダのＲ−ＵＲＩをＵＥ−ＦのＲ−ＵＲＩからＵＥ−ＴのＲ−ＵＲＩへ変更する。修正されたＩＮＶＩＴＥはＳ−ＣＳＣＦ  Ｆに返送される。
【００１６】
４）Ｓ−ＣＳＣＦ  ＦはＵＥ−ＴネットワークのＩ−ＣＳＣＦにＩＮＶＩＴＥを送信し、Ｉ−ＣＳＣＦ（不図示）はＨＳＳに問い合わせ、ＵＥ−ＴのＳ−ＣＳＣＦ  Ｔのアドレスを得、Ｓ−ＣＳＣＦ  ＴにそのＩＮＶＩＴＥを転送する。
【００１７】
５）Ｓ−ＣＳＣＦ  Ｔは、図３を参照して説明したようにＩＮＶＩＴＥに含まれるＲ−ＵＲＩ（即ち、ＵＥ−ＴのＲ−ＵＲＩ）に基づいて、着信手順を実行する。
【非特許文献１】ＴＳ２４．２２９
【発明の開示】
【発明が解決しようとする課題】
【００１８】
再び図４において、ステップ４）では、転送端末ＵＥ−Ｆに制限が存在するかどうかをチェックすることがさらにＳ−ＣＳＣＦ  Ｆに必要であろう。これを行うために、Ｓ−ＣＳＣＦは図２の発信側の手順を使用すべきである。しかしながら、ＡＳ−Ｆにより実施される特別の手順が何もない場合、ＡＳ−ＦによりＳ−ＣＳＣＦ  Ｆに返送されるＩＮＶＩＴＥは、Ｐ−アサート・アイデンティティのフィールドにＵＥ−Ｏのアイデンティティを含むであろう。Ｓ−ＣＳＣＦ  ＦがＰ−アサート・アイデンティティを使用してＩＮＶＩＴＥについての発信側のチェックを実行するとしても、そのアイデンティティはＳ−ＣＳＣＦ  Ｆに“属さ”ない（むしろ、それはＳ−ＣＳＣＦ  Ｏに属する）ので、Ｓ−ＣＳＣＦ  Ｆはこのアイデンティティについての記録を突き止めることが不可能であろう。これに対して、もしＳ−ＣＳＣＦがＩＮＶＩＴＥについての着信側のチェックを実行すれば、ＩＮＶＩＴＥに含まれるＲ−ＵＲＩがＵＥ−Ｔを識別するので、そのチェックはまた、Ｒ−ＵＲＩがＳ−ＣＳＣＦ  ＦよりむしろＳ−ＣＳＣＦ  Ｔに属することに関することとなろう。この問題は、例えば、他の初期要求メッセージ及び独立のメッセージを含むＩＮＶＩＴＥ以外のメッセージにより生じる。
【００１９】
この課題に対する解決策は、ＡＳ−ＦがＵＥ−ＯのＰ−アサート・アイデンティティをＵＥ−Ｆのそれと置換することであるかもしれない。しかしながら、Ｐ−アサート・アイデンティティをエンド・ツー・エンドで不変にしておくことを好むオペレータは、おそらくこれを受け入れないだろう。オペレータの観点からは、Ｐ−アサート・アイデンティティフィールドは、従来（ＰＳＴＮ）の発呼回線のアイデンティティに類似する。それ故、この課題に対する他の解決策を模索しなければならない。
【課題を解決するための手段】
【００２０】
本発明の第１の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、元々の対話識別子と共に前記サービング呼／状態制御機能のＵＲＩを前記メッセージのルートヘッダに追加し、前記元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを前記サービング呼／状態制御機能において維持する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記呼が転送されることになるユーザ機器のＵＲＩに前記メッセージにおける前記Ｒ−ＵＲＩを変更し、前記メッセージに転送指示情報を追加して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記転送指示情報の存在を識別し、応答として、前記返送されたメッセージに含まれる前記元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法が備えられる。
【００２１】
前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことが好ましい。
【００２２】
前記転送指示情報は、前記ルートヘッダに含まれることが好ましい。
【００２３】
Ｐ−アサート・アイデンティティは前記Ｓ−ＣＳＣＦにおいて受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することが好ましい。
【００２４】
本発明の第２の側面からすれば、ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバであって、転送指示情報と呼が転送されることになるユーザ機器を識別するＲ−ＵＲＩを含むように、受信されたメッセージを修正することにより、呼転送動作を実施するための処理手段を有することを特徴とするアプリケーションサーバを備える。
【００２５】
本発明の第３の側面からすれば、ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバから受信されたセション開始プロトコルメッセージを処理するための処理手段を有するサービング呼／状態制御機能であって、前記処理手段は、ルートヘッダがセション開始プロトコルのアプリケーションサーバにより追加された転送指示情報を含むかどうかを判断するように動作し、前記処理手段は、前記ルートヘッダが転送指示情報を含めば、前記受信したメッセージに含まれる元々の対話識別子に基づいて元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩに依存して発信手順に従って前記メッセージを処理することを特徴とするサービング呼／状態制御機能を備える。
【００２６】
本発明の第４の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージのＰ−アサート・アイデンティティを前記Ｒ−ＵＲＩに変更して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記Ｐ−アサート・アイデンティティのフィールドに含まれる前記Ｒ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。
【００２７】
本発明の第５の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージに転送指示情報を追加し、最上位エントリとして転送ユーザ機器のＳＩＰ  ＵＲＩを含む履歴情報ヘッダを追加する工程と、
前記サービング呼／状態制御機能に前記メッセージを転送する工程と、
前記サービング呼／状態制御機能において、前記メッセージにおける前記転送指示情報の存在を識別し、前記履歴情報ヘッダに含まれるＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。
【００２８】
本発明の第６の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、前記Ｒ−ＵＲＩを格納する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、呼を転送することになるユーザ機器のＲ−ＵＲＩに前記メッセージのＲ−ＵＲＩを変更する工程と、
前記サービング呼／状態制御機能において、前記メッセージのＲ−ＵＲＩにおける変化を識別し、応答として、元々のＲ−ＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。
【００２９】
本発明は特に、セション開始プロトコルの初期要求メッセージ、例えば、ＩＮＶＩＴＥに、そして、独立のセション開始プロトコルメッセージ、例えば、プレゼンスサービスに関係するメッセージに適用可能である。
【００３０】
本発明の他の側面は、アプリケーションサーバ、及び本発明の第４と第５の側面の特徴を実施する処理手段を有するサービング呼／状態制御機能に関係する。
【発明を実施するための最良の形態】
【００３１】
“転送を行う”Ｓ−ＣＳＣＦがＩＮＶＩＴＥメッセージに関する制限のチェックを実行することを可能にする課題を以上で考察した。アプリケーションサーバからの受信されるＩＮＶＩＴＥをＰ−ＣＳＣＦまたはその他のＣＳＣＦから受信されるＩＮＶＩＴＥとは異なる方法で取り扱う必要がある識別する機構を、転送を行うＳ−ＣＳＣＦに提供することが必要である。
【００３２】
４つの代替的解決策がここで提案される。
【００３３】
解決策１
Ｓ−ＣＳＣＦに着信するＩＮＶＩＴＥは、Ｓ−ＣＳＣＦ  Ｆの登録ユーザの１つ、ＵＥ−Ｆを指すＲ−ＵＲＩ、即ち、userf_public1@home2.netをそのヘッダに含む。それはまた、ＵＥ−ＯのＰ−アサート・アイデンティティ、即ち、“John Doe”＜sip:user1_public1@home1.net＞、＜tel:+1-212-555-1111＞を含む。Ｓ−ＣＳＣＦ  Ｆは、ルートヘッダの最上位ＵＲＩとして、ＡＳのＳＩＰ  ＵＲＩ、即ち、sip:as1.home1.net;lrを加え、初期要求または独立のトランザクションをＡＳに（ＵＥ−Ｆに対して取得したＩＦＣｓに応答して）送信する。加えて、Ｓ−ＣＳＣＦ  Ｆは、“元々の対話識別子”（ＯＤＩ）と共にそれ自身のＳＩＰ  ＵＲＩをルートヘッダのＡＳ  ＵＲＩの下部に含ませる。同時に、Ｓ−ＣＳＣＦ  Ｆは、受信したＩＮＶＩＴＥのＲ−ＵＲＩをＯＤＩに結びつけ、この結合をローカルデータベースに格納する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成は図５に示されている。ここで、ルートヘッダに追加されるＳ−ＣＳＣＦ  ＦのＵＲＩは“scscf1.home1.net;lr”であり、ＯＤＩは“cb03a0s09a2sdfglkj490333”である。
【００３４】
ＡＳ−ＦからＳ−ＣＳＣＦ  Ｆに返送されるＩＮＶＩＴＥの構成が図６に示されている。ＡＳ−Ｆは到来するＩＮＶＩＴＥにおいて受信する情報を含む。特に、オペレータの要求を満たすために、Ｐ−アサート・アイデンティティは不変である。しかしながら、ＡＳ−Ｆは、呼が転送されることになるＵＥであるＵＥ−ＴのＵＲＩに対応する新しいＲ−ＵＲＩ“usert_public1@home2.net”を追加し、履歴情報ヘッダの拡張部において定義されるように履歴情報ヘッダを追加し、新しい呼処理手順、即ち、転送手順を使用すべきであることをＳ−ＣＳＣＦ  Ｆに指示するであろう。このことは、ルートヘッダに“ｆｏｒｗ”パラメータを含ませることにより指示される。
【００３５】
Ｓ−ＣＳＣＦ  ＦがＡＳ−Ｆからそのような修正メッセージを受信すると、“ｆｏｒｗ”パラメータを含むことに基づいて、Ｓ−ＣＳＣＦは呼がＡＳから来ることを知り、Ｓ−ＣＳＣＦ  Ｆの自体のＵＲＩに添付されたＯＤＩを判断する。ＯＤＩを使用して、Ｓ−ＣＳＣＦはローカルデータベースからこのＯＤＩに結び付けられたＲ−ＵＲＩ、即ち、転送端末ＵＥ−ＦのＵＲＩを判断する。次いで、Ｓ−ＣＳＣＦ  ＦはＵＥ−ＴのＵＲＩでなく、元々の（即ち、ＵＥ−Ｆの）Ｒ−ＵＲＩに基づいて、制限のチェックとＩＦＣの識別を実行する。［Ｓ−ＣＳＣＦ  ＦとＡＳとの間で全ての相互動作が実行された後、ＴＳ２４．２２９の第５．４．３．２節に始まる段落の動作９乃至１５が実行される］。
【００３６】
解決策２
Ｓ−ＣＳＣＦ  Ｆが初期要求をＡＳに送信する場合、Ｓ−ＣＳＣＦ  Ｆは現行標準に記載されるようにＵＥ−ＯのＰ−アサート・アイデンティティをＩＮＶＩＴＥに保持する。Ｓ−ＣＳＣＦ  Ｆは、ルートヘッダの最上位ＵＲＩとしてＡＳのＳＩＰ  ＵＲＩとともに、それ自体のＳＩＰ  ＵＲＩもＡＳ  ＵＲＩの下部に追加する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成が図７に示されている。
【００３７】
ＡＳ−ＦによるＩＮＶＩＴＥの受信に続いて、ＡＳ−Ｆが呼転送を実行し、Ｒ−ＵＲＩもＵＥ−ＴのＵＲＩに変更すべきであると判断する場合、ＡＳ−Ｆは発呼者のＰ−アサート・アイデンティティを元々のメッセージのＲ−ＵＲＩ、即ち、ＵＥ−ＦのＵＲＩにより置換する。加えて、ＡＳ−Ｆはルートヘッダに“ｏｒｉｇ”パラメータを加え、発信呼のタイプの手順を使用してＩＮＶＩＴＥを扱うべきであることを指示する。ＡＳ−Ｆはまた、メッセージの新しいヘッダフィールドに（ＵＥ−Ｏの）受信されたＰ−アサート・アイデンティティを含ませる。修正されたＩＮＶＩＴＥはＳ−ＣＳＣＦ  Ｆに返送され、図８には修正されたＩＮＶＩＴＥが示されている。
【００３８】
修正されたＩＮＶＩＴＥを受信するとき、Ｓ−ＣＳＣＦ  Ｆはメッセージのヘッダから、発信呼のタイプの手順を使用して、ＩＮＶＩＴＥを扱うべきであることを知る、即ち、Ｓ−ＣＳＣＦ  ＦはＵＥ−ＦのＲ−ＵＲＩを含むであろうＰ−アサート・アイデンティティに基づいて、制限のチェックを実行し、適切なＩＦＣを決定する。Ｓ−ＣＳＣＦ  ＦはこのＵＲＩの“所有者”であるので、そのチェックは成功裏に実行されるであろう。
【００３９】
ＵＥ−Ｔに関連するＩ−ＣＳＣＦにＩＮＶＩＴＥを転送する前に、Ｓ−ＣＳＣＦ  Ｆは、ＩＮＶＩＴＥが再度修正され、ＵＥ−ＦのＲ−ＵＲＩをＵＥ−ＯのＰ−アサート・アイデンティティにより置換しなければならないことを（新しいヘッダにおいて受信する情報から）認識する。このアイデンティティはなお、メッセージのヘッダ内にあるので、Ｓ−ＣＳＣＦ  Ｆに容易に利用可能である。“新しいヘッダ”のメッセージにおける存在によりこの動作が起動される契機がつくられる。
【００４０】
解決策３
さらに別の解決策は、Ｓ−ＣＳＣＦが履歴情報ヘッダに含まれる情報の使用を可能にすることである。
【００４１】
Ｓ−ＣＳＣＦ  Ｆが初期要求をＡＳに送信するとき、Ｓ−ＣＳＣＦ  Ｆは現行標準に記載されるように、ＵＥ−ＯのＰ−アサート・アイデンティティをＩＮＶＩＴＥに保持する。Ｓ−ＣＳＣＦ  Ｆは、ルートヘッダの最上位ＵＲＩとしてＡＳのＳＩＰ  ＵＲＩを追加するとともに、それ自体のＳＩＰ  ＵＲＩもＡＳ  ＵＲＩ下部に追加する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成は図９に示されている。ＡＳ−ＦによるＩＮＶＩＴＥの受信に続いて、ＡＳ−Ｆが呼の転送を実行し、ＩＮＶＩＴＥのＲ−ＵＲＩもＵＥ−ＴのＲ−ＵＲＩに変更すべきであると判断する場合、ＡＳ−Ｆは履歴情報ヘッダを追加する。履歴情報ヘッダは履歴情報ヘッダの最上位エントリとしてＵＥ−ＦのＳＩＰ  ＵＲＩを含む。ＡＳはＳ−ＣＳＣＦ  Ｆに、新しい呼処理手順、即ち、転送手順を使用すべきであることを指示する。このことは、ルートヘッダに“ｆｏｒｗ”パラメータを含ませることにより指示される。
【００４２】
Ｓ−ＣＳＣＦ  ＦがＡＳ−Ｆからそのような修正されたＩＮＶＩＴＥを受信すると、“ｆｏｒｗ”パラメータを含むことに基づいて、Ｓ−ＣＳＣＦ  Ｆは呼がＡＳから来ることを知る。次いで、Ｓ−ＣＳＣＦ  Ｆは履歴情報ヘッダの最上位ヘッダ、即ち、ＵＥ−ＦのＵＲＩに基づいて、制限のチェックとＩＦＣの識別とを実行する。
【００４３】
解決策４
この解決策は、（Ｉ−ＣＳＣＦから）Ｓ−ＣＳＣＦ  Ｆにおいて受信されるＩＮＶＩＴＥに含まれるＲ−ＵＲＩを格納することが関係している。これはＯＤＩに対して対応付けられても良い。ＡＳはＩＮＶＩＴＥのＲ−ＵＲＩを、ＩＮＶＩＴＥが転送されることになるＵＥ、即ち、ＵＥ−ＴのＲ−ＵＲＩに変更する。Ｓ−ＣＳＣＦ  ＦはＡＳから受信されるＩＮＶＩＴＥのＲ−ＵＲＩについての初期チェックを実行し、それが変更されたかどうかを見る。もし変更されていれば、次いで、元々の（即ち、ＵＥ−Ｆの）Ｒ−ＵＲＩに基づいて、制限のチェックとＩＦＣの決定とが実行される。
【００４４】
本発明の範囲を逸脱することなく、上述した実施例に種々の変更を行うことができることを当業者は認識するであろう。
【図面の簡単な説明】
【００４５】
【図１】ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合を概略的に示した図である。
【図２】ＩＭＳの発信呼側におけるＳＩＰ  ＩＮＶＩＴＥのフローを示した図である。
【図３】ＩＭＳの着信呼側におけるＳＩＰ  ＩＮＶＩＴＥのフローを示した図である。
【図４】ＩＭＳ内の呼転送シナリオにおけるＳＩＰ  ＩＮＶＩＴＥのフローを示した図である。
【図５】、
【図６】、
【図７】、
【図８】、
【図９】、
【図１０】ＳＩＰ  ＩＮＶＩＴＥメッセージの構成例を示した図である。
【図１】
2008543135.tif 000003
【図２】
2008543135.tif 000004
【図３】
2008543135.tif 000005
【図４】
2008543135.tif 000006
【図５】
2008543135.tif 000007
【図６】
2008543135.tif 000008
【図７】
2008543135.tif 000009
【図８】
2008543135.tif 000010
【図９】
2008543135.tif 000011
【図１０】
2008543135.tif 000012
【手続補正書】
【提出日】平成18年12月13日(2006.12.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、元々の対話識別子と共に前記サービング呼／状態制御機能のＵＲＩを前記メッセージのルートヘッダに追加し、前記元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを前記サービング呼／状態制御機能において維持する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記呼が転送されることになるユーザ機器のＵＲＩに前記メッセージにおける前記Ｒ−ＵＲＩを変更し、前記メッセージに転送指示情報を追加し、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記転送指示情報の存在を識別し、応答として、前記対応付けを用いて前記返送されたメッセージに含まれる前記元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項２】
前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記転送指示情報は、前記ルートヘッダに含まれることを特徴とする請求項１又は２に記載の方法。
【請求項４】
Ｐ−アサート・アイデンティティは前記Ｓ−ＣＳＣＦにおいて受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバであって、
転送指示情報と呼が転送されることになるユーザ機器を識別するＲ−ＵＲＩを含むように、受信されたセション開始プロトコルメッセージを修正することにより、呼転送動作を実施するための処理手段を有することを特徴とするアプリケーションサーバ。
【請求項６】
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバから受信されたセション開始プロトコルメッセージを処理するための処理手段を有するサービング呼／状態制御装置であって、
前記処理手段は、ルートヘッダがセション開始プロトコルのアプリケーションサーバにより追加された転送指示情報を含むかどうかを判断するように動作し、
前記処理手段は、前記ルートヘッダが転送指示情報を含めば、前記受信したメッセージに含まれる元々の対話識別子に基づいて、元々のＲ−ＵＲＩと前記元々の対話識別子との間の以前に格納された対応付けを用いて、前記元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩに依存して発信手順に従って前記メッセージを処理することを特徴とするサービング呼／状態制御装置。
【請求項７】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージに転送指示情報を追加し、最上位エントリとして転送ユーザ機器のＳＩＰ  ＵＲＩを含む履歴情報ヘッダを追加する工程と、
前記サービング呼／状態制御機能に前記メッセージを転送する工程と、
前記サービング呼／状態制御機能において、前記メッセージにおける前記転送指示情報の存在を識別し、前記履歴情報ヘッダに含まれるＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項８】
前記転送指示情報は、前記メッセージの前記ルートヘッダに含まれることを特徴とする請求項７に記載の方法。
【請求項９】
前記サービング呼／状態制御機能において受信した前記メッセージを処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項７又は８に記載の方法。
【請求項１０】
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、前記Ｒ−ＵＲＩを格納する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、呼を転送することになるユーザ機器のＲ−ＵＲＩに前記メッセージのＲ−ＵＲＩを変更する工程と、
前記サービング呼／状態制御機能において、前記メッセージのＲ−ＵＲＩにおける変化を識別し、応答として、元々のＲ−ＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
【請求項１１】
前記セション開始プロトコルのメッセージは、初期要求メッセージ或いは独立のメッセージであることを特徴とする請求項１乃至４、或いは請求項７乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記セション開始プロトコルのメッセージは、ＩＮＶＩＴＥメッセージであることを特徴とする請求項１１に記載の方法。
【手続補正書】
【提出日】平成20年5月19日(2008.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項２
【補正方法】変更
【補正の内容】
【請求項２】
前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についての初期フィルタ基準（ＩＦＣ）を識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項１に記載の方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項４
【補正方法】変更
【補正の内容】
【請求項４】
Ｐ−アサート・アイデンティティは前記サービング呼／状態制御機能において受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【手続補正３】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項９
【補正方法】変更
【補正の内容】
【請求項９】
前記サービング呼／状態制御機能において受信した前記メッセージを処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についての初期フィルタ基準（ＩＦＣ）を識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項７又は８に記載の方法。
【国際調査報告】
2008543135.tif 000013
2008543135.tif 000014
2008543135.tif 000015