JP4330584B2 - Ｉｍｃにおける要求リダイレクションハンドリング - Google Patents

Description

本発明は、ＩＭＣ（ＩＰマルチメディアコア）におけるサービス要求のハンドリングに関する。詳述すれば、本発明は、ＩＭＣ内のサービスを受けるユーザのためのサービス要求リダイレクションに関する。

セッションの開設及び管理が必要な多くのインターネットアプリケーションが存在している。セッションは、関係者のアソシエーション間でのデータの交換と考えられる。これらのアプリケーションの実現は、関係者の実施によって複雑である。即ち、ユーザはエンドポイント間を移動するかも知れず、複数の名前によってアドレス可能であるかも知れず、そして幾つかの異なるメディアで（時には、同時に）通信可能であるかも知れない。音声、ビデオ、またはテキストメッセージのような種々の形状の実時間マルチメディアセッションデータを運ぶ多くのプロトコルが公認されている。セッション開始プロトコル（ＳＩＰ）は、インターネットエンドポイント（ユーザエージェントと呼ぶ）が互いを認め合うことを、及びそれらが共用しようとするセッションの特徴に合意することを可能にすることによって、これらのプロトコルと協力して動作する。予測されるセッション関係者を探知するために、及び他の機能のために、ＳＩＰは、ユーザエージェントがそれへの登録、セッションへの勧誘、その他の要求を送ることができるネットワークホスト（プロキシサーバーと呼ぶ）のインフラストラクチャを開設することができる。ＳＩＰは、セッションを開設し、変更し、そして終了させる機敏な汎用ツールであり、基礎をなしている輸送プロトコルには無関係に、そして確立されているセッションの型には依存することなく動作する。

ＩＥＴＦ（インターネットエンジニアリングタスクフォース）によって定義されているＳＩＰに関する詳細は、ＲＦＣ（コメントに関する要求）３２６１に記載されている。上述したように、ＳＩＰは、終端間マルチメディアセッションの確立、ハンドリング、及び解放を可能にする。ＳＩＰプロトコルには幾つかの追加が存在し、これらは例えばＳＩＰをベースとするイベント通知を可能にし、これがＳＩＰをベースとするプレゼンスサービスその他のサービスのための基礎である。

３ＧＰＰ（第３世代パートナーシッププロジェクトＩＰマルチメディアサブシステム）は、３ＧＰＰ（無線）ネットワーク内において広範な機能を達成するためにＳＩＰを使用する。

ＩＭＳ内のＳ−ＣＳＣＦ（サービング呼出し状態制御機能）は、ＨＳＳ（ホーム加入者システム）からフィルタ基準（ＦＣ）をダウンロードする。ＦＣは、１つずつ評価される。即ち、到来要求は、要求−ＵＲＩ（ユニバーサル資源識別子）内のパブリックユーザアイデンティティに基づくＳ−ＣＳＣＦによって、初めの、または初期ＦＣ（最高優先順位）が一致するか否かがチェックされる。もしそれが一致すれば、Ｓ−ＣＳＣＦはそれをＦＣによって指示されている関連アプリケーションサーバー（ＡＳ）へ送り、ルートヘッダー内に“対話識別子”を追加する。これはＳ−ＣＳＣＦへポイントバックされる。

要求がＡＳから送り返されてＳ−ＣＳＣＦにおいて再度受信されると、Ｓ−ＣＳＣＦは対話識別子によってその要求を識別し、次に低い優先順位のＦＣの一致をチェックし、先に接触したＡＳから受信したフィルタ基準をＳＩＰ方法に適用する。先行プロセスの結果に依存して、Ｓ−ＣＳＣＦは１またはそれ以上のアプリケーションサーバーと接触することができる。

若干の特別サービスに起因して、ＡＳはその要求をリダイレクト（例えば、呼出し転送）することができる。これらの場合、ＡＳにとって、Ｓ−ＣＳＣＦがその後のＦＣを遂行することは望ましくないかも知れない。従来技術によれば、Ｓ−ＣＳＣＦのこのような挙動はＡＳによって影響され得ない。

サービス要求リダイレクションの例としての呼出し転送は、遠隔通信システムにおいて最も一般的に使用されるサービスの１つである。その使用は、ＩＰマルチメディアコアサブシステムにおけるセッションのハンドリングに重大なインパクトを与えるので、それは正確に定義すべきである。

３ＧＰＰ ＴＳ ２４．２２９の最新バージョンであるリリース５標準（ｖ．５．３．０）は、一般的に、実行されるサービスの特別な効果を斟酌することなくＳ−ＣＳＣＦにおける終了手順を指定している。要求リダイレクションは影響を受けたセッションの要求−ＵＲＩデータを変更するが、これは、上記標準の一般的記述を用いては達成することができないＳ−ＣＳＣＦにおける特別な処理を必要とする。３ＧＰＰ ＴＳ ２４．２２９、ｖ．５．３．０のチャプタ５．４．３．３“サービスを受けるユーザにおいて終了した要求（Request terminated at the served yser）”に記載されている従来技術によれば、呼出し転送のような要求リダイレクションの状況においては、残余の手順の実行が呼出し転送の目的と衝突する。３ＧＰＰ ＴＳ ２４．２２９、ｖ．５．３．０のチャプタ５．４．３．３“サービスを受けるユーザにおいて終了した要求”のポイント１１の一般的記述によれば、要求−ＵＲＩは上書きされて呼出し転送自体の可能性が排除される。換言すれば、従来技術によれば、Ｓ−ＣＳＣＦによってサービスを受けるユーザが到達可能である場合には、保管された接触ＵＲＬ（ユニバーサル資源ロケーター）の内容を用いてＳ−ＣＳＣＦによって要求−ＵＲＩが構築される（この接触ＵＲＬは、宛先パブリックユーザアイデンティティから決定される）。

従来は、ＩＰマルチメディアサブシステム（ＩＭＳ）内に呼出し転送の特定の記述は与えられておらず、またＩＭＳにおける呼出し転送ハンドリングは他の既存システムのそれとは完全に異なっている。

従って、本発明の目的は、ＩＭＣにおける呼出し転送のような要求のリダイレクションを可能にすることである。

本発明によれば、この目的は、特許請求の範囲の請求項１に記載のサービス要求を処理する方法、請求項１６に記載のサービスを処理する方法、及び請求項２６に記載のサービス要求をハンドリングする方法によって達成される。

上記目的は、請求項１２に記載のデバイス、及び請求項２７に記載のサービス要求を処理するデバイスによって達成される。

上記目的は、請求項２２に記載のユニット、及び請求項２８に記載のサービスを処理するユニットによって達成される。

更に、上記目的は、請求項１３に記載のコンピュータプログラムプロダクト、及び請求項２３に記載のコンピュータプログラムプロダクトによって達成される。

上記目的は更に、請求項２９に記載のＩＰマルチメディアコアネットワークによって達成される。

本発明のさらなる特色は、従属請求項に定義されている。

本発明によれば、呼出し転送の場合に終了Ｓ−ＣＳＣＦによって実行されるタスクが定義される。呼出し転送の場合には、終了Ｓ−ＣＳＣＦはさらなるフィルタを評価しないが、呼出し転送を操作（ハンドル）する。更に、呼出し転送の場合にアプリケーションサーバーによって実行することができるタスクが定義される。

図１Ａは、ＩＰマルチメディアコアネットワークにおけるサービス要求を処理する方法を示している。ステップＳ１１において、ユーザのサービス要求がユーザにサービスを提供する（サービング）デバイスによって受信される。例えば、このサービス要求は、第１のユーザから第２のユーザに向けて開始される。ステップＳ１２において、受信されたサービス要求はサービスを処理するユニットへ転送される。次いで、ステップＳ１６において処理結果が処理ユニットから受信される。ステップＳ１７において、受信した処理結果に基づいて、第２のユーザに関するサービス要求処理を停止するか否かが決定される。

図１Ｂは、処理ユニットへ転送されたサービス要求に従ってサービスを処理する方法を示している。ステップＳ１３において、第２のユーザに向けて第１のユーザによって開始されたサービス要求が、第２のユーザにサービスを提供するデバイスから受信される。ステップＳ１４においてサービスが処理され、ステップＳ１５において処理結果がデバイスへ戻され、それに基づいてデバイスは、第２のユーザに関するサービス要求処理を停止するか否かを決定することができる（図１ＡのステップＳ１７）。

図２に、図１Ａ及び１Ｂに示すステップ１１乃至１７を遂行するように配列されているＩＰマルチメディアコアネットワーク（ＩＭＣネットワーク）を示す。詳述すれば、ＩＭＣネットワーク２９は、サービスを受けるユーザに関するサービス要求を処理するためにユーザにサービスを提供するデバイス２０と、そのサービス要求に対応するサービスを処理する処理ユニット２８とを含む。

サービス提供デバイス２０は、サービスを受けるユーザに関するサービス要求を受信する第１の受信ブロック２２と、受信したサービス要求を処理ユニット２８へ転送してサービスを処理させる転送ブロック２１と、処理ユニット２８からの処理結果を受信する第２の受信ブロック２３と、受信した処理結果に基づいて、サービスを受けるユーザに関するサービス要求処理を停止するか否かを決定する決定ブロック２４とを含む。

処理ユニット２８は、サービス提供デバイス２０からサービス要求を受信する受信ブロック２５と、サービスを処理する処理ブロック２６と、処理結果をサービス提供デバイス２０へ戻し、その結果に基づいて第２のユーザに関するサービス要求処理を停止するか否かをデバイス２０が決定できるようにする戻しブロック２７とを含む。

本発明の一実施の形態によれば、処理ユニット２８は、サービスを受ける（第２の）ユーザに関するサービス要求処理を停止する指示を、処理結果内に含ませることができる。即ち、サービス提供デバイス２０は、処理ユニット２８から受信した処理結果が第２のユーザに関するサービス要求処理を停止する指示を含むか否かをチェックし、その指示が存在する場合には第２のユーザに関するサービス要求処理を停止する。またサービス提供デバイス２０は、その指示が有効か否かをもチェックする。

更に、第２のユーザに対するサービス要求処理を停止する前に、サービス提供デバイス２０は課金処理を遂行することができる。

本発明の別の実施の形態によれば、第１のユーザによって開始されて受信されたサービス要求は、第２のユーザの宛先識別子を含むことができ、サービス処理を行う時に、処理ユニット２８はそのサービス要求を第３のユーザへ転送することを決定し、第２のユーザの宛先識別子を第３のユーザの宛先識別子に置換し、そして処理結果を第３のユーザの宛先識別子と共にサービス提供デバイス２０へ戻すことができる。サービス提供デバイス２０は、処理ユニット２８へ転送されたサービス要求の宛先識別子と、処理ユニット２８から受信した処理結果とを比較し、比較した識別子が互いに異なることを検出した場合には第２のユーザに関するサービス要求処理を停止することができる。更に、サービス提供デバイス２０は、受信した処理結果に基づいて、サービス要求を第３のユーザへ転送するか否かを決定することができ、処理結果内に含まれる宛先識別子に基づいてサービス要求を第３のユーザへ転送することができる。

サービス提供デバイス２０によって受信される第２のユーザに関する第１のユーザのサービス要求は、第１のユーザの発信識別子を含むことができ、また処理ユニット２８は、それがサービスを処理中にそのサービス要求を第２のユーザから第３のユーザへリダイレクトすることを決定すると、処理結果内に第２のユーザの発信識別子を含むことができる。次いで、転送手順中にサービス提供デバイス２０は、処理結果内に含まれる発信識別子が第２のユーザの発信識別子であることを検出することができ、処理結果内に含まれる発信識別子に基づいてサービス要求を転送することができる。しかしながら、処理結果内に含まれる発信識別子が第２のユーザの発信識別子ではない場合には、サービス提供デバイス２０は、転送されるサービス要求内に第２のユーザの発信識別子を含ませることができる。代替として、転送手順中サービス提供デバイス２０は、処理結果内に含まれる発信識別子を常に使用することができる。

本発明の一実施の形態によれば、第１のユーザの発信識別子は、第２のユーザの発信識別子に置換される。代替として、第１のユーザの発信識別子に第２のユーザの発信識別子が付加される。

以下に、図３乃至５を参照して本発明の実施例を説明する。

図３は、ユーザＡ（第１のユーザ）がユーザＢ（第２のユーザ）に向けて最初のサービス要求を送る場合のシグナリング図である。サービス要求はユーザＢにサービスを提供するＩＭＣ内のデバイス（サービス提供デバイス）、例えばＳ−ＣＳＣＦ（サービング呼出し状態制御機能）によって受信される。Ｓ−ＣＳＣＦはこの最初のサービス要求をユーザＢのための対応アプリケーションサーバーＡＳ（処理ユニット）へ転送し、そのサービス要求を処理させる。処理の後に、ＡＳは処理結果をＳ−ＣＳＣＦへ戻す。ここまでの処理は、３ＧＰＰ ＴＳ ２４．２２９、バージョン５．３．０、リリース５、チャプタ５．４．３．３“サービスを受けるユーザにおいて終了した要求”に準拠している。

本発明によれば、サービスを受ける加入者またはＳ−ＣＳＣＦ内のユーザの終了サービスを処理中、各サービスの実行の後に、そのサービスがプロセスを含むか否かを決定するためにチェックを遂行すべきである（Ｓ−ＣＳＣＦはその後のフィルタ基準を遂行すべきではないから）。例えば、呼出し転送のようなサービスリダイレクションの場合には、呼出されたパーティのさらなる終了サービスを実行すべきではない、即ち、次に優先順位が低いフィルタ基準が一致するか否かのチェックは停止すべきである。

図３に示すように、ユーザＢのＳ−ＣＳＣＦは、ＡＳから受信した処理結果から、ユーザＢに関する終了処理を停止すべきことを検出する。終了処理を停止する前に、Ｓ−ＣＳＣＦは３ＧＰＰ ＴＳ ２４．２２９、ｖ．５．３．０、リリース５のチャプタ５．４．３．３“サービスを受けるユーザにおいて終了した要求”のポイント５乃至７に記載されているような課金関連機能を遂行することができる。

終了処理を停止すべきことの検出の他に、本発明によれば、サービス要求を別のユーザＣへ転送しなければならないことをＳ−ＣＳＣＦによって検出することができる。この検出の後に、Ｓ−ＣＳＣＦは、上述した課金関連タスクを遂行し、発信モードへスイッチし、そして最後に、図３に示すように、最初のサービス要求をユーザＣに向けて転送することによってこの要求リダイレクションを操作することができる。

図４は、図３の実施の形態の例である。図４によれば、Ｂ Ｓ−ＣＳＣＦに向けて送られる最初の要求は、ユーザＢのＲ−ＵＲＩ（要求−ユニバーサル資源識別子）（宛先識別子）を含む。Ｂ Ｓ−ＣＳＣＦはこの要求をユーザＢのＡＳへ転送する。サービスを処理することによってＢ ＡＳは、例えばサービス要求のユーザＣへのリダイレクションを検出することができる。この場合、Ｂ Ｓ−ＣＳＣＦはその後のフィルタ基準を遂行すべきではないから、Ｂ ＡＳはＢ Ｓ−ＣＳＣＦがさらなるフィルタ基準を評価すべきではないことの指示をセットすることができる。

ＡＳは、例えばＳ−ＣＳＣＦへ送り返される要求の要求−ＵＲＩの一部としてこの指示をセットすることができる。これは、例えば、
Sip:Georg.Mayer@miesbach.de;FC=off
のような要求−ＵＲＩ内のタグであることができる。ここに、“Sip:Georg.Mayer@miesbach.de”はユーザＣのＲ−ＵＲＩである。

この指示は、別の手法（例えば、エキストラヘッダー、別のヘッダーのパラメータ等）でセットすることもできる。

次いでＳ−ＣＳＣＦは、要求を送り返してきたＡＳが上記指示をセットすることを許しているか否かをチェックすべきである。もしセットすることを許していれば、Ｓ−ＣＳＣＦはその後のＦＣの評価を停止し、直ちに（または、少なくとも上述した課金動作を遂行した直後に）要求リダイレクションを操作すべきである。換言すれば、Ｂ Ｓ−ＣＳＣＦがＢ ＡＳから戻された処理結果内のタグ“ＦＣ＝ＯＦＦ”を検出した時に、それはユーザＢに関する終了処理を停止し、例えば、戻された処理結果内に指示されている要求−ＵＲＩに向けて呼出し転送を操作するための発信役割へスイッチする。

図５は、図３の実施の形態のさらなる例である。図５によれば、Ｂ Ｓ−ＣＳＣＦに向けて送られる最初の要求は、ユーザＢのＲ−ＵＲＩ（要求−ユニバーサル資源識別子）、及びユーザＡのＰ−Ａ−ＩＤ（Ｐ−表明されたアイデンティティ）ヘッダー（発信識別子）を含んでいる。Ｂ Ｓ−ＣＳＣＦは、ユーザＢのＡＳへ要求を転送する。サービス処理の結果は、ユーザＣへのサービス要求のリダイレクションであることができる。要求リダイレクションを検出するために、ＡＳへ送られる要求−ＵＲＩ、及びＡＳから受信する要求−ＵＲＩは、常にＳ−ＣＳＣＦによって比較される。図５に示すように、Ｒ−ＵＲＩがＢからＣへ変化しているので、Ｓ−ＣＳＣＦは呼出し転送のような要求リダイレクションを含む実行された要求を検出する。

呼出し転送の場合には、Ｐ−表明されたＩＤヘッダーは、ユーザＣが、ユーザＡからの要求または呼出しがユーザＢを通して到来したことを通知できるように変更すべきである。例えば、もしユーザＣがユーザＡに関して阻止されている呼出しを有しており、またユーザＡが、ユーザＣへ転送される呼出しを有するユーザＢを呼出すものとすれば、ユーザＢの観点からこの転送は失敗しよう。本発明によれば、Ｐ−表明されたＩＤヘッダーの変更は、呼出し転送サービスを実現するＡＳ、または（ＡＳがヘッダーを変更しない場合には）呼出し転送を検出する終了Ｓ−ＣＳＣＦの何れかによって行うことができる。図５によれば、Ｂ ＡＳは既にＰ−Ａ−ＩＤをＡからＢへ変更している。この変更は、図５に示すようにＰ−表明されたＩＤヘッダーを、サービスを受けるユーザのＩＭＰＵ（ＩＰマルチメディアパブリックユーザアイデンティティ）（それは、サービスを受ける別のＩＭＰＵであることもできる）に置換する、またはサービスを受けるユーザのＩＭＰＵ（この場合も、それはサービスを受ける別のＩＭＰＵであることもできる）を元のＰ−表明されたＩＤヘッダーの始まりに挿入する、即ち‘Ｐ−Ａ−ＩＤ＝Ｂ，Ａ’の何れかである。図５に示すように、次いでＰ−Ａ−ＩＤ＝Ｂを用いて呼出しが転送される。

Ｂ Ｓ−ＣＳＣＦは、呼出し転送を検出した後に３ＧＰＰ ＴＳ ２４．２２９、ｖ．５．３．０、リリース５、チャプタ５．４．３．３“サービスを受けるユーザにおいて終了した要求”のポイント５、６、及び７に記載されているように、課金に関するタスクを遂行することができる。もしユーザＢが呼出し転送をセットしていれば、ユーザＢは、ＢからＣへの呼出の転送された部分に関して支払いをすべきである。

課金に関する機能が完了すると、終了Ｓ−ＣＳＣＦはその役割を終了Ｓ−ＣＳＣＦから発信Ｓ−ＣＳＣＦへ変化させ、３ＧＰＰ ＴＳ ２４．２２９、ｖ．５．３．０、リリース５、チャプタ５．４．３．２“サービスを受けるユーザにおいて終了した要求”に記載されているような動作を開始する。この場合、この発信Ｓ−ＣＳＣＦ内のサービスを受けるユーザは、Ｐ−表明されたＩＤヘッダー、即ちユーザＢ内に格納されている転送ＩＭＰＵである。換言すれば、Ｂ Ｓ−ＣＳＣＦは発信役割へスイッチし、３ＧＰＰ ＴＳ ２４．２２９、バージョン５．３．０、チャプタ５．４．３．２“サービスを受けるユーザにおいて終了した要求”に従って、最初のサービス要求をユーザＣに向けて転送する。

Ｂ Ｓ−ＣＳＣＦは、Ｂによって発信された呼出しに関して定義されている全ての制約／セッティングが満足されることを保証すべきである。

従って、本発明によれば、ユーザＢの発信サービスが実行される。例えば呼出し転送の場合に発信サービスを実行しないことによって加入者は、呼出しを、呼出し阻止番号への転送にセットし、加入者自体を呼出すことによって、阻止された番号を呼出すことができるようになる。

図５のブロック５に示す課金タスクは、図４の実施の形態においても、Ｂに関する終了処理が停止されたことを検出した後に、且つＢに関する終了処理が実際に停止される前に遂行できることにも注目されたい。更に、Ｐ−Ａ−ＩＤ変更は図４の実施の形態にも適用することができる。

更に、上述した例を、異なる手法で組合わせ得ることに注目されたい。例えば、
Ｒ−ＵＲＩ変化に関して：
ａ．Ｂ ＡＳがＲ−ＵＲＩを変化させ、処理結果内に特別な指示が存在しない、
ｂ．Ｂ ＡＳが処理結果においてＲ−ＵＲＩの変化を指示する。
Ｐ−Ａ−ＩＤを変化させるために、オプションとして２つの場所が存在する：
変化の場所：
０．変化なし（この方法ではＣはＢが含まれていることを知らないが、これも可能なオプションである）、
１．Ｂ ＡＳにおいて行われる、
２．リダイレクションが検出された後にＢ Ｓ−ＣＳＣＦにおいて（ある点において）行われる。
変化の方法：
Ｘ．ＡをＢに置換、
Ｙ．ＡをＢ，Ａに置換。

これにより、可能な組合わせは、０、１Ｘ、１Ｙ、２Ｘ、及び２Ｙである。

Ｒ−ＵＲＩ変化をも斟酌すると、可能な組合わせは、ａ０、ｂ０、ａ１Ｘ、ｂ１Ｙ、ａ２Ｘ、ｂ２Ｘ、ａ２Ｙ、及びｂ２Ｙである。

以上の説明は、本発明を例示したに過ぎず、本発明を限定する意図の下になされたものではない。当業者ならば、特許請求の範囲に記載されている本発明の真の思想及び範囲から逸脱することなく、種々の変更及びアプリケーションを考案することが可能であろう。

図１Ａは、本発明によるサービス要求処理方法を示すフロー図であり、図１Ｂは、本発明によるサービス処理方法を示すフロー図である。 本発明によるＩＰマルチメディアコアネットワーク内のサービス提供デバイス及び処理ユニットの概要ブロック図である。 本発明の一実施の形態によるサービス要求ハンドリングを示すシグナリング図である。 本発明の一実施の形態によるＳ−ＣＳＣＦにおける呼出し転送ハンドリングを示すシグナリング図である。 本発明の上記実施の形態によるＳ−ＣＳＣＦにおける呼出し転送ハンドリングの別の例を示すシグナリング図である。

Claims (27)

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. 前記コンピュータプログラムプロダクトは、前記コンピュータの内部メモリ内へ直接ロード可能であることを特徴とする請求項２３に記載のコンピュータプログラムプロダクト。
26. ＩＰマルチメディアコアネットワークにおいてサービス要求を処理するデバイスであって、
    第１のユーザによって開始され第２のユーザにおいて終了するセッション開始プロトコルに従ったサービス要求を受信する手段と、
    を含み、当該デバイスが前記第２のユーザにサービスを提供するものであり、
    さらに、
    前記受信したサービス要求を、該サービス要求を処理するためのアプリケーションサーバに転送する手段と、
    前記処理されたサービス要求の処理結果を、前記アプリケーションサーバから受信する手段と、
    前記受信した処理結果に基づいて、当該デバイスにおける前記サービス要求のサービス要求処理を停止するか否かを決定する手段と、
    を含むことを特徴とするデバイス。
27. ＩＰマルチメディアコアネットワークにおいてサービスを処理するユニットであって、 第１のユーザによって開始され第２のユーザにおいて終了するセッション開始プロトコルに従ったサービス要求を、前記第２のユーザにサービスを提供するデバイスから受信する手段と、
    前記サービス要求を処理する手段と、
    前記処理されたサービス要求の処理結果を、前記デバイスに戻す手段と、
    を含み、
    前記デバイスが、前記処理結果に基づいて、該デバイスにおける前記サービス要求のサービス要求処理を停止するか否かを決定するように設けられている、
    ことを特徴とするユニット。

Images