JP4280284B2 - 通信システムにおけるサービスの提供 - Google Patents

Description

本発明は、通信システムに関し、特に通信システムと関連するエンティティ間で通信を必要とするサービスの提供の開始に関する。

通信システムは、通信システムと関連するユーザ機器、通信ネットワーク要素および他のエンティティなどの２つ以上のエンティティ間の通信を可能にする装置とみなすことができる。概して通信システムは、所与の規格または通信システムと関連する様々なエンティティの何が実行を許可され、それがどのように達成されるべきかを定義する仕様に基づいて動作する。例えば、その規格または仕様は、ユーザ、より正確にはユーザ機器または端末がユーザ回路交換サービスおよび／またはパケット交換サービスによって提供されたかどうかを定義することが可能である。接続に用いられる通信プロトコルおよび／またはパラメータも、定義することが可能である。すなわち、その通信が基づくことのできる特定の一連の「規定」は、そのシステムによって通信が可能になるように定義される必要がある。

無線通信をユーザ機器に提供する通信システムは、公知である。無線システムの一例には、セルラーネットワークがある。セルラーシステムにおいて、基地局（ＢＴＳ）または類似的なアクセスエンティティは、これらのエンティティの間の無線インターフェースを介して移動局（ＭＳ）または他の無線ユーザ機器（ＵＥ）のような役割を果たす。ユーザ機器と通信ネットワークとの間の通信は、適切な通信プロトコルに基づくことができる。基地局の装置および他の通信に必要な装置の動作は、１つまたは複数の制御エンティティによって制御することができる。様々な制御エンティティを相互接続してもよい。１つ以上のゲートウェイノードをセルラーネットワークを他のネットワーク、例えば、公衆交換電話網（ＰＳＴＮ）および／またはＩＰ（インターネットプロトコル)のような他の通信ネットワーク、および／または他のパケット交換ネットワークなどへの接続のために提供してもよい。

通信システムへの加入者に対して提供することが可能なサービスの例には、いわゆるマルチメディアサービスがある。マルチメディアサービスの提供が可能となった通信システムは、ＩＰマルチメディアネットワークと呼ばれることもある。ＩＰマルチメディアネットワークの機能は、ＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム、または短くＩＰマルチメディアサブシステム（ＩＭＳ）によって提供することができる。ＩＭＳは、マルチメディアサービスの提供のために様々なエンティティを備える。

通信システムは、ネットワークの様々なサービスの提供機能がサーバとして公知のネットワークエンティティによって取り扱う方向で開発されている。例えば、現在の第三世代（３Ｇ）の無線マルチメディアネットワークのアーキテクチャにおいて、いくつかの異なるサーバを異なる機能を取り扱うために用いることも考えられる。これらには、コールセッション制御機能（ＣＳＣＦｓ）などの機能が挙げられる。このコールセッション機能は、プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）、問合せコールセッション制御機能（Ｉ−ＣＳＣＦ）、およびサービングコールセッション制御機能（ＳＣＳＣＦ）などの様々なカテゴリに分類することが可能である。時折ＣＳＣＦｓをコール状態制御機能またはコールサーバ制御機能と呼ぶことが好まれると理解されたい。

サービングコールセッション制御機能は、通信システムからサービスを要求できるようにするために加入者が登録する必要のあるエンティティを形成する。サービングコールセッション制御機能は、セッションの発信側および受信側において発信側コールセッション制御機能（Ｏ−ＣＳＣＦ）および受信側コールセッション制御機能（Ｔ−ＣＳＣＦ）にさらに分類することができる。

サービング制御エンティティに加えて、ユーザは、Ｐ−ＣＳＣＦのようなプロキシ制御エンティティを伴うことを必要とすることがある。プロキシエンティティは、ユーザがサービスを提供されるエリアに割り当てることが可能である。

加入者管理サーバ（Home Subscriber Server, ＨＳＳ）および様々なアプリケーションサーバのようなエンティティも、通信ネットワーク内に提供することが可能である。加入者管理サーバ（ＨＳＳ）は、上述のサーバから加入者に関連した情報を格納するためのものである。加入者情報には、認証データ（例えば、加入者または端末の登録識別）などの情報を含むことが可能である。ＨＳＳは、概して恒久的に加入者のプロフィール情報を格納するために用いられる。加入者管理サーバ（HSS）は、例えばセッションのセットアップ手順の間に他の機能エンティティによって問合せを受けることが可能である。

アプリケーションサーバ（ＡＳ）は、付加価値ＩＭサービスをユーザに提供するように構成されたエンティティである。アプリケーションサーバは、ユーザの家庭用ネットワーク内に存在することが可能である。アプリケーションサーバはまた、代わりとして、ユーザの家庭用ネットワークの外部となること、またサードパーティのサービスによって提供されることも可能である。このサードパーティは、別のネットワークまたは単にスタンドアロンのアプリケーションサーバであってもよい。アプリケーションサーバは、オペレータのネットワークによってサポートされるサービスに代わってのデータ通信セッションを左右したり影響を与えたりすることがある。アプリケーションサーバは、サービスのホストし、実行することが可能である。アプリケーションサーバの例には、セッション開始プロトコル（ＳＩＰ）アプリケーションサーバ、オープンサービスアクセス（ＯＳＡ）アプリケーションサーバ、およびモバイルネットワーク用拡張ロジックＩＰマルチメディアサービスの交換機能のためのカスタマイズアプリケーション（ＣＡＭＥＬ ＩＭ−ＳＳＦ）が挙げられる。

因習的に、通信システムは、ユーザ、概して加入者が通信システム上で通信を始めなければならないように構成される。例えば、ユーザは、通信のセッション、処理または他のタイプに適切な通信ネットワークエンティティから要求することが可能である。このような通信は、ユーザから発信するとみなすことができる。

従って、発信側のセッション／トランザクションは、通常ユーザのユーザ機器か、またはユーザの代わってのネットワークエンティティによって送られるセッション／トランザクションであると理解される。受信側のセッション／トランザクションは、通常ユーザのユーザ機器かまたはユーザの代わってのネットワークエンティティによって受信されるセッション／トランザクションである。

例えば、３ＧＰＰ（第三世代標準化団体）規格のリリース５（Ｒｅｌ−５）のＩＭＳネットワークは、ユーザ機器（ＵＥ）がどのようにセッションおよび単一のトランザクションを開始できるのかという規定を定義する。しかしながら、Ｒｅｌ−５に表される唯一の規定では、いわゆる発信側のフィルター基準がどのように適用されるのかということに焦点を当てている。リリース５は、他のパーティがユーザに代わってセッションやトランザクションを開始することを許可していない。３ＧＰＰ規格のリリース６では、アプリケーションサーバ（ＡＰ）が、Ｓ−ＣＳＣＦへのＩＳＣ（ＩＰマルチメディアサービス制御）を介してユーザ機器に代わってセッション開始プロトコル（ＳＩＰ）の要求を送信できなければならないことを求めている。しかしながら、現在の３ＧＰＰリリース６規格であっても、アプリケーションサーバの発信側要求がユーザ機器からの発信の要求によって直接引き起こされるという例外的な場合を除いて、アプリケーションサーバがそうすることを可能にするアプリケーションサーバ（ＡＳ）に対する機構を提供していない。従って、アプリケーションサーバは、依然としてＳＩＰの要求またはユーザに代わっての他の要求を発信するサービスを実行することができない。

本発明者らは、アプリケーションサーバのようなネットワークエンティティが、ユーザを発信側のパーティであるとみなすことができるようなユーザに代わっての通信を必要とするプロセスを開始することができれば、利点になりうるということを見出した。有用となりうるサービスの一例には、ユーザに代わってリストのメンバーにメッセージを送信することが可能なアプリケーションサーバであるメッセージングリストが挙げられる。別の例には、ユーザの存在状態を通信するユーザメッセージに代わって送信することができるアプリケーションサーバがある。さらに別の例には、例えば会議やグループコール、またはチャットアプリケーションなどのためにユーザに代わってセッションまたはトランザクションを開始することが可能なアプリケーションがある。上述はほんの数例を示すにすぎないこと、また通信に対して要求を発信することを可能にするネットワークエンティティの可能性によって利益を得ることができる様々な他のサービスがあると理解されたい。

しかしながら、このような動作の要求を発信するネットワークエンティティの取り扱いに対する機構の不足のため、現在の通信システムに問題が生じる可能性がある。例えば、二次的な通信のルーティングや課金機能などに関する問題が生じる可能性がある。これは、通信システムの他のエンティティが、例えば、更なるメッセージをどこで通信すべきか、またはどのように通信を制御すべきかなどを認識できていないために生じる。

例えば、Ｓ−ＣＳＣＦがメッセージを受信する場合、そのメッセージをどのように取り扱うのかを決定できることが必要になる。現在のシステムにおいて、Ｓ−ＣＳＣＦは、「発信側フィルタ」および「受信側フィルタ」として公知である、メッセージに対するフィルタ基準を適用することが可能である。「フィルタ基準」（Ｆｉｌｔｅｒ
Ｃｒｉｔｅｒｉａ，ＦＣ）という用語は、特定のサービスアプリケーションのための関連するサービスポイントトリガ（ＳＰＴｓ）を定義する用語を示す。ＳＩＰの通信環境では、このフィルタ基準は特定のサービスアプリケーションに送信される、または代理となるべきＳＣＳＣＦによって受信されるＳＩＰの要求のサブセットを定義する。ＳＣＳＣＦは、このフィルタ基準を加入者管理サーバ（ＨＳＳ）またはアプリケーションサーバ（ＡＳ）から受信することが可能である。

従来技術では、受信側のフィルタ基準は、アプリケーションサーバからの全てのメッセージに適用される。しかしながら、メッセージは、アプリケーションサーバが発信したサービスの要求またはネットワーク内のユーザに代わって発信された他のこのようなメッセージである可能性がある。従って、本発明者らは、受信側のフィルタ基準ではなく発信側のフィルタ基準が適用されるべきであるかどうかを決定するための機構が要求されていることを見出した。これは、発信側のフィルタ基準がそのようなメッセージに対してより正確な評価結果を表すことが可能だからである。

誤った「役割」すなわちフィルタ基準がメッセージに用いられた場合、このことが、例えば、ルーティングおよび他の制御動作の観点から問題を起こす可能性がある。この点に関して一旦決定が行われると、その決定された役割は、メッセージが送信されたユーザに代わってのユーザ以外であるエンティティから発信されたメッセージの評価に対する適切なフィルタ基準を適用できるように通信システムの他のエンティティに通信される必要も生じうる。

本発明の実施例は、上述の問題点のうちの１つまたは複数に対処することを目標としている。

本発明の一側面によれば、通信システムにおけるサービスの提供方法であって、前記通信システムと関連する第１のエンティティにおいて、前記通信システムのユーザにサービスを提供することが可能な通信制御に関するストレージエンティティの情報通信システムから受信するステップと、前記情報に基づいて、前記第１のエンティティから前記通信制御エンティティに発信側要求を送るステップと、を備える方法が提供される。

本発明の一側面によれば、通信システムのユーザにサービスを提供するために構成された前記通信システムであって、前記通信システムのユーザにサービスを提供することができる通信制御エンティティと、ユーザに関するストレージエンティティからの情報を受信するための第１のインターフェースを備える第１のエンティティと、前記ストレージエンティティからの前記情報に基づいて前記通信制御エンティティへ発信側要求を送るための第２のインターフェースと、を備える通信システムが提供される。

本発明の別の側面によれば、通信システムのためのアプリケーションサーバであって、前記通信システムのユーザに関するストレージエンティティからの情報を受信するための第１のインターフェースと、前記ストレージエンティティからの前記情報に基づいてユーザにサービスを提供することが可能な通信制御エンティティに発信側要求を送るための第２のインターフェースとを備えるアプリケーションサーバが提供される。

本発明のさらに別の側面によれば、通信システムの第１のエンティティと前記通信システムの使用のサービスの提供が可能な通信制御エンティティとの間のインターフェースに送られる発信側要求であって、前記発信側要求はユーザ情報のストレージエンティティからの情報に基づいて発生される、発信側要求が提供される。

より具体的な実施態様では、前記発信側要求が、前記要求に関連する通信の取り扱いに関する情報を含む。前記発信側要求は、前記発信側要求に関連する更なる通信は、その要求がユーザから発信したかのような同様の方法で取り扱われるべきであるとする指示を含むことが可能である。受信側サービスあるいは発信側サービスのどちらかを、前記要求に基づいて提供することが可能である。

第１のエンティティで、前記通信制御エンティティが前記要求に関連する更なる要求をどのように取り扱うべきであるかを決定することが可能である。

第１のエンティティは、ユーザに代わって前記発信側要求を発生させることが可能である。

前記発信側要求を、前記通信制御エンティティのアドレスに関する情報に基づいて発生することが可能である。第１のエンティティは、前記発信側要求を送信する前に前記通信制御エンティティのアドレスに関する前記情報を修正することが可能である。第１のエンティティは、前記発信側要求にサービスタイプの表示子を付け加えることが可能である。前記サービスタイプの表示子を、前記通信制御エンティティの前記アドレス内に含むことが可能である。

第１のエンティティは、要求を送信すべきポートを選択することが可能である。

発信側要求を送信する前に第１のエンティティからデータベースに問合せを送信することが可能である。このような問合せは、前記通信制御エンティティに基づく。

ユーザにサービスを提供することを可能にする前記通信制御エンティティに関する前記情報に対する問合せを、第１のエンティティから送信することが可能である。

前記通信制御エンティティの情報に対する少なくとも２つの異なるアドレスに関する情報を、前記ストレージエンティティに格納することが可能である。

前記発信側要求は、前記要求に適用されるフィルタ基準を示すことが可能である。

本発明のこれらの実施態様は、ユーザに代わって機能するサービスを実行する可能性を有する通信ネットワークのエンティティを可能にできる。本解決策は、現存する通信システムにおける実施が実質的に容易である。ユーザ情報が加入者管理サーバ（ＨＳＳ）のような集中化された方法で格納された事例では、この集中化されたストレージを修正する必要がない。特定の実施態様において、ユーザ情報ストレージに、サービスへの適切なエントリ点を見つけ出すためのクエリーのような通常の通信プロトコルや手順を用いて問い合わせることができる。

本発明の好適な実施形態の説明

本発明の更なる理解のために、添付図面を例として参照する。

本発明を具体化することが可能であるＩＰマルチメディアネットワークを示す図１を参照する。ＩＰマルチメディアサービスは、ＩＰマルチメディアネットワークの加入者に提供されることが可能である。ＩＰマルチメディア（ＩＭ）機能は、サービスを提供するための様々なエンティティを備えるコアネットワークシステム（ＣＮ）によって提供されることができる。

本発明において、通信システムのエンティティは、通信制御エンティティによってユーザに提供されるサービスと関連する発信側の要求を送信する。下記の詳細な例において、アプリケーションサーバおよび通信制御エンティティを備えるエンティティは、サービングコールセッション制御機能によって提供される。実施態様を更に詳細に説明する前に、これらの実施態様および実施態様と関連する他の可能な要素を、図１を参照して以下に簡単に説明する。図１は、モバイル通信システムの一部にすぎないということを理解されたい。

示された配置において、基地局１１は、セルラー通信ネットワークのアクセスエンティティを提供する。無線アクセスネットワーク１１は、適切な制御装置（明確にするため図示せず）によって制御される。制御装置を各基地局に備えることが可能であるか、または制御装置が複数の基地局を制御することが可能である。複数の基地局を制御するために、制御装置を個々の基地局および無線アクセスネットワーク階層内に備えるという解決策も公知である。従って、システムに基づいたアクセスネットワーク制御装置の名前、位置および数は、システムに依存すると理解されたい。例えば、ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）は、無線ネットワーク制御装置（ＲＮＣ）と呼ばれるコントローラノードを使用することが可能である。ＧＳＭおよびＣＤＭＡ２０００において、対応する無線ネットワーク制御装置エンティティは、基地局コントローラ（ＢＳＣ）と呼ばれる。

図１は、非常に模式的であり、実用的な実施においては基地局の数が実質的に多くなるということを理解されたい。１つのアクセスネットワークは複数の基地局を備えることが可能である。基地局装置または基地局部もまた、複数のアクセスネットワークを提供することが可能である。これらの特徴は、実施および環境に依存する。

基地局１１は、モバイルユーザ、すなわち無線インターフェースを介した加入者のモバイルユーザ機器１０と信号を送受信するように構成される。それに応じて、モバイルユーザ機器１０は、無線インターフェースを介して基地局と信号を送受信することができる。モバイルユーザは、ネットワークに接続するためにインターネットプロトコル（ＩＰ）に適応されるあらゆる適切なモバイル機器を用いることが可能である。例えばモバイルユーザは、パーソナルコンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、移動局（ＭＳ）などによってセルラーネットワークにアクセスすることが可能である。以下の例は、移動局のコンテキストに記載されている。

当業者は、代表的な移動局の特徴および動作に精通している。従って、これらは何らかの詳細な説明を必要としない。ユーザは、電話の使用、ネットワークとのデータの送受信、および、例えば、マルチメディアのコンテンツを体験するなどのタスクために移動局１０を使用することが可能であるということに十分気がつく。移動局は、モバイル通信ネットワークの基地局と無線での送受信のためのアンテナ要素を備えることが可能である。移動局１０はまた、モバイルユーザ機器のユーザに画像および他のグラフィック情報を表示するためのディスプレイも備えることが可能である。スピーカ手段もまた、概して提供される。モバイルユーザ機器の動作は、制御ボタンや音声コマンドなどの適切なユーザインタフェースによって制御することが可能である。さらに、モバイルユーザ機器は、プロセッサエンティティおよびメモリ手段を備える。明確にするために図１には１つの移動局しか示されていないが、複数の移動局をモバイル通信システムの各基地局と同時に通信するようにできると理解されたい。

コアネットワーク（ＣＮ）エンティティは、複数の無線アクセスネットワークを介した通信、および１つの通信システムを他のセルラーシステムおよび／または固定回線通信システムのような他の通信システムと接続することを可能にするためのスイッチング、他の制御エンティティおよびゲートウェイを概して備える。

現在の第三世代（３Ｇ）の無線ＩＰマルチメディアネットワークアーキテクチャでは、複数の異なるサーバエンティティが異なる機能を取り扱うために用いられることを前提とする。これらは、コールセッション制御機能（ＣＳＣＦｓ）を取り扱うエンティティを備える。このコールセッション機能は、プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）１２、問合せコールセッション制御機能（Ｉ−ＣＳＣＦ）２４、およびサービングコールセッション制御機能（Ｓ−ＣＳＣＦ）１４などの様々なカテゴリに分類することが可能である。

サービングコールセッション制御機能１４は、加入者１０を登録するエンティティを形成する。通信システムからサービスへ要求できるようにするために、登録が必要である。ユーザは、基地局１１などの通信システムのアクセスエンティティを経て、当人自身を登録することが可能である。サービングコールセッション制御機能１４は、セッションまたはトランザクションの発信および受信側で、発信側のコールセッション制御機能（Ｏ−ＣＳＣＦ）および受信側コールセッション制御機能（Ｔ−ＣＳＣＦ）を提供するとみなすことができる。

ユーザは、同時に複数のコールセッション制御機能に登録することが可能である。サービング制御エンティティ１４に加えて、ユーザは、図１のＰ−ＣＳＣＦ１２などのプロキシ制御エンティティと関連している必要がある。プロキシエンティティ１２は、ユーザが移動しているエリアに割り当てることが可能である。従って、ユーザが任意のタイプのアクセスネットワークを通じてネットワークにアクセスする場合、このアクセスネットワークは、例えばバンド幅の管理のためのネットワークの観点から、アクセスしたサービスを制御するためのプロキシ制御エンティティを割り当てることが可能である。ユーザが、アクセスネットワークからの支援なしに自分のユーザ機器によって適切なＰ−ＣＳＣＦを探し出すことも可能であると考えられる。

加入者管理サーバ（ＨＳＳ）２０も示される。上述のように、加入者管理サーバ（ＨＳＳ）２０は、加入者、すなわちユーザに関連した情報を格納するためのものである。加入者管理サーバ（ＨＳＳ）には、例えばセッションのセットアップ手順の間に適切なインターフェースについて、他の機能エンティティによってクエリーを行うことができる。

加入者管理サーバ（ＨＳＳ）２０とサービングコールセッション制御機能（Ｓ−ＣＳＣＦ）１４とを接続するアプリケーションサーバ２２も示される。一般的に、アプリケーションサーバは、ユーザの申込みに基づいて、セッション／トランザクションで利用可能なサービスをホストするエンティティであるとみなすことができる。アプリケーションサーバに対するルーティングを、ユーザの申込みと関連するフィルタ基準の評価の結果として実行することができる。

上述のように、２組のフィルタ基準を用いることが可能である。このフィルタ基準の内の１組を受信側セッション／トランザクションのために、もう１組を発信側のセッション／トランザクションのために用いることができる。代表的な動作において、フィルタリングは第１のメッセージ、すなわち初期の要求に対してのみ適用される。残りのメッセージは、初期の要求のルーティングの間に記録することができるので、フィルタリングなしで取り扱うことができる。このように、フィルタ基準は、記録されたルートを介して経路を定められるので、更なる要求に影響を与える。従って、二次的なメッセージ、すなわち初期の要求の後の同じダイアログにおけるメッセージに対するフィルタ基準を評価しないことが起こりうる。しかしながら、二次的なメッセージにフィルタリングを適用することも可能である。

アプリケーションサーバ２２が、Ｓ−ＣＳＣＦ１４にメッセージを送信することによってセッションまたはトランザクションを開始する場合、このＳ−ＣＳＣＦ１４は、どの役割を機能させるのかを決定する必要がある。Ｓ−ＣＳＣＦ１４が、発信側の役割を行うように選択する場合、Ｓ−ＣＳＣＦは、入力メッセージに発信側フィルタ基準を適用する。受信側の役割において、Ｓ−ＣＳＣＦは受信側のフィルタ基準を評価する。この選択を実施するための様々な代替方法を下記に記載する。その役割に従って、ＳＣＳＣＦはそれから登録メッセージに応答してＰ−ＣＳＣＦに戻るサービスのアドレスを構築することが可能である。Ｐ−ＣＳＣＦはそれから、Ｓ−ＣＳＣＦにメッセージを渡すときにそのアドレスを使用しなければならない。

登録の間、Ｓ−ＣＳＣＦ１４は、受信側のセッションまたはトランザクションで使用しなければならないＨＳＳ２０のアドレスと通信することが好ましい。

図２に示される好適な実施態様によれば、アプリケーションサーバ１４は、ユーザ機器１０がＨＳＳ２０から登録されるＳ−ＣＳＣＦ１４に関するアドレス情報を受信する。アドレス情報は、例えばエンティティ間のＳｈインターフェースを通じてのクエリーに応答して提供することが可能である。図２のステップ１を参照。アドレス情報は、Ｓ−ＣＳＣＦの名前またはＳ−ＣＳＣＦのＵＲＩ（ユニバーサルリソース識別子）などのあらゆる適切な情報の形式とすることが可能である。

本発明の好ましい形態によれば、アドレス情報は、所望の役割に関する情報を含めるように構成される。アドレス情報は、本発明の原理に従って、アプリケーションサーバ２２またはそのアプリケーションサーバの外部で構成されることが可能である。後者の場合、その情報を、アドレス情報が取り込まれた情報源において、リストやテーブルまたはデータベースなどに構成された形式に格納することが可能である。代わりに、ユーザ機器またはネットワークのエンティティから受信した要求から、アドレス情報を獲得および格納することが可能である。

図２において、アプリケーションサーバ２０は、アドレス情報の公正に対応するようにステップ番号２で表される。より詳しくは、アプリケーションサーバ２２は、適切なサービスのタイプが加入者に提供されるようにアドレス情報を修正することが可能である。例えば、アプリケーションサーバ２０は、必要とされるサービスのための適切なアドレスを構築するためにサービスの名前を修正することが可能である。Ｓ−ＣＳＣＦの名前は、例えば、ＨＳＳから受信した名前に対する接頭辞として表示子パラメータ「ｔｅｒｍ」または「ｏｒｉｇ」を追加して修正することが可能である。例えば、アドレス

scscf12.operator.net name

を、アプリケーションサーバを開始するセッションまたはトランザクションが、送信側または受信側のセッションまたはトランザクションであるかどうかによって、以下のうちの１つに修正することが可能である。

orig.scscf12.operator.net または、
term.scscf12.operator.net

ステップ３において、アドレスは、適切なサービスのＩＰアドレスを得るためにＤＮＳ（ドメインネームシステム）２６によって解決される。

この修正に従って、アドレスは、メッセージを発信側または受信側サービスに向ける。従って、アプリケーションサーバ２２は、ステップ４においてサービス要求のメッセージを発信側サービスまたは受信側サービスに経路を定めることができる手段によって提供される。図１に示すように、これをＩＳＣ（ＩＰマルチメディアサービス制御）インターフェースにおいて生じさせることが可能である。

アプリケーションサーバ２２は、発信側のサービスに適切なアドレスを構築するためにＵＲＩに特定のパラメータを付け加えることによって、代わりにサービスのＵＲＩを修正することが可能である。アプリケーションサーバ２０はそれから、ルーティングアドレスとしてのパラメータとともにＵＲＩを用いているメッセージの経路を定めることが可能である。

アプリケーションサーバ２２は、受信側のサービスのための名前またはＵＲＩを修正することを必ずしも必要としないと理解されたい。すなわち、修正が行われなければ、受信側サービスが提供される。

また、受信側のサービスの場合にのみアドレスが修正され、発信側のサービスの場合にはアドレスの修正は行われない、ということも考えられる。

しかしながら、受信側および発信側のサービスアドレスの修正が、例えば対称性の理由のために、特定のアプリケーションに要求されることがある。

以下の例は、可能な動作を上記の原理に従って更に詳細に示す。アプリケーションサーバが、ＨＳＳから受信側のアドレスを獲得したと仮定する。例えば、セッション開始プロトコル（ＳＩＰ）を次の形式のアドレスにしてみる（ユーザ部分を省略していることに注意）

xx44@scscf7.operator.net

アプリケーションサーバ２２が受信側のセッション／トランザクションを開始しようとしている場合、アプリケーションサーバ２２は、受信側のセッション／トランザクションの役割を行わなければならないＳ−ＣＳＣＦであるターゲットＳ−ＣＳＣＦ１４に信号を送るために、前記アドレスを使用する。代表的な動作において、これは、入力メッセージの評価時にＳ−ＣＳＣＦ１４が受信側のフィルタ基準を適用する必要があることを意味する。

アプリケーションサーバ２２が、発信側のセッション／トランザクションを開始しようとしている場合、アプリケーションサーバ２２はアドレスを修正する。これは、そのアドレスに新たな「役割」パラメータを付け加えることによって行うことができる。従って、役割パラメータrole=origを備えている修正アドレスは、例えば次の形式を有することが可能である。

xx44@scscf7.operator.net;role=orig

この修正アドレスは、それから、ターゲットＳ−ＣＳＣＦが発信側のセッション／トランザクションの役割を行わなければならないことを示す表示子として、ターゲットＳ−ＣＳＣＦに送られる。代表的な動作において、Ｓ−ＣＳＣＦが発信側のフィルタ基準を評価する必要があることを意味する。

Ｓ−ＣＳＣＦのアドレスは、そのアドレスを必要とするアプリケーションサーバ２２の中で構成されることが可能である。代わりに、そのアドレスは、全てのアプリケーションサーバで構成されることが可能である。後者の代替案は、例えば、アプリケーションサーバ２２から加入者管理サーバ２０へのＳｈインターフェースがないか、またはインターフェースが一時的に利用できない場合に有利になりうる。

代替案によれば、アドレスそのものを修正するというよりも、アプリケーションサーバ２２は、データベース、ファイル、リスト、テーブルなどから修正データを取り込むことが可能である。データベースは、アプリケーションサーバ２２内に位置するか、またはこのアプリケーションサーバの外部のデータベースとすることが可能である。

パラメータがＳ−ＣＳＣＦ１４のアドレスとともにＨＳＳ２０に格納されるというアドレス構築の可能性がある。アプリケーションサーバ２２は、それから修正プロセスのための入力としてのＨＳＳからのアドレスおよびパラメータの情報を用いて、適切なアドレスを構築することが可能である。

図３に示される可能性によれば、アプリケーションサーバ２２は、ステップ１でＨＳＳから戻されるアドレス情報に基づいて、ＤＮＳ（ドメインネームシステム）クエリーを行う。戻されたＳ−ＣＳＣＦの名前は、例えば、必要とされるサービス（発信側または受信側）が利用可能であるアドレスおよびポートを見つけ出すためのＳＲＶのリソースレコードを要求するために用いることが可能である。ＳＲＶは、サービス（ＤＮＳ ＳＲＶ）の位置を指定するためのＤＮＳのリソースレコード（ＲＲ）である。ＳＲＶのリソースレコードの使用は、特定のサービスおよび／または特定のドメインのプロトコルに対してクエリーを行うことを可能にする。その応答は、それから基準を満たすあらゆる利用可能なサーバ名前を含むことになる。

例えば、発信側のフィルタ基準を評価しなければならない場合、ＳＲＶのリソースレコードからの以下のＤＮＳクエリーを実行することが可能である。ＳＲＶのリソースレコードは、概してプロトコルおよびサービスの両方を指定する。ＳＲＶのレコードは、以下のアドレスを引数として用いることによってステップ２でクエリーを行うことができる。

_orig._sip.scscf12.operator.net

ステップ２での応答は、ポート5060を用いて指定されたアドレス“orig.scscf12.operator.net”に経路を定めるための通知とすることが可能である。

_orig._sip.scscf12.operator.net SRV 0 0
5060 orig.scscf12.operator.net.

代わりに、その応答は、当初のアドレス“scscf12.operator.net”を有する指定されたポート55334に経路を定めることが可能である。

_orig._sip.scscf12.operator.net SRV 0 0
55334 scscf12.operator.net.

以下の引数は、受信側のフィルタ基準を評価しなければならない場合に、ＤＮＳクエリー（ＳＲＶ）に用いることが可能である。

_term._sip.scscf12.operator.net

その応答は、ポート5060を用いて指定されたアドレス“term.scscf12.operator.net”に経路を定めるための通知とすることが可能である。

_term._sip.scscf12.operator.net SRV 0 0
5060 term.scscf12.operator.net.

または、上記のようにその応答は、例えば当初のアドレス“scscf12.operator.net”を有する指定されたポート55335に経路を定めることが可能である。

_term._sip.scscf12.operator.net SRV 0 0
55335scscf12.operator.net.

概して、アプリケーションサーバの発信側の要求がどのように取り扱われるのかが示されるので、上記のタイプの経路指定は発信側のサービスには必要でないことがあると理解されたい。発信側のサービスに特別な経路指定のないアプリケーションも考えられる。アドレス修正と同様に、上述のタイプの経路指定は、例えば対称性の理由のために要求されることがある。

アプリケーションサーバは、その後、ステップ３でＤＮＳによってアドレスを解決することが可能で、ステップ４で示されたアドレスおよび／またはポートにメッセージをルーティングすることが可能である。

別の可能性によれば、加入者データベース（例えばＨＳＳ２０）は、ステップ１でＳ−ＣＳＣＦの名前を返す。アプリケーションサーバは、その後、利用可能なサービス（発信側および／または受信側）を見つけ出すためのＮＡＰＴＲ（ネーミングオーソリティポインタ）を要求する、返されたＳ−ＣＳＣＦの名前を有するＤＮＳクエリーを作成する。その応答に基づいて、アプリケーションサーバは、それから所望のアドレスに要求メッセージの経路を定めることが可能である。この実施態様によって、ドメインネームの構文にはない様々なリソースネームに対するルックアップサービスためのＤＮＳの使用が可能になる。可能なリソースネームは、サービスのためのＵＲＩを備える。

以下は、ＳＲＶを有するＮＡＰＴＲクエリーの例である。ＤＮＳクエリーは、例えば次のＳ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲのリソースレコードを要求することによって行われる。

scscf12.operator.net

結果は、以下のようになりうる。

IN NAPTR 100 10 “S”“sip+orig”
””_orig._sip.scscf12.operator.net.
IN NAPTR 100 10 “S”“sip+term”
””_term._sip.scscf12.operator.net.

命令および優先フィールドが等しいので、任意のＲＲｓを選択することができる。発信側のセッション／トランザクションのためのＳ−ＣＳＣＦのアドレスが必要である場合、最初のアドレスを選択することが可能である。フラグ「Ｓ」は、次のＤＮＳクエリーがＳＲＶ ＲＲを要求して実行されることを示す。このＤＮＳクエリーは、ドメインネーム、すなわち上述のようなアドレスによってＳＲＶ ＲＲを要求して実行することが可能である。

_orig._sip.scscf12.operator.net.

DNSクエリーの結果は、ＩＰアドレスまたは他のいずれの適切な経路指定情報であることが可能である。

また、ＳＲＶクエリーを行わないＮＡＰＴＲを実施することも考えられる。上記のように、ＤＮＳクエリーは、Ｓ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲ ＲＲを要求して実行することが可能である。例えば、

scscf12.operator.net

その結果は、次のようになりうる。

IN NAPTR 100 10 “A”“sip+orig” ””
orig.scscf12.operator.net.
IN NAPTR 100 10 “A”“sip+term” ””
term.scscf12.operator.net.

命令および優先フィールドが等しいので、任意のＲＲｓを選択することができる。発信側のセッション／トランザクションのためのＳ−ＣＳＣＦのアドレスが必要である場合、最初のアドレスを選択することが可能である。フラグ「Ａ」は、次のＤＮＳクエリーが、ＳＲＶ Ａ，ＡＡＡＡまたはＡ６のリソースレコードを要求して実行されることを示す。ＤＮＳクエリーは、それからドメインネームorig.scscf12.operator.netを有するＡ，ＡＡＡＡまたはＡ６ ＲＲを要求して実行される。クエリーは、結果としてＩＰアドレスになる。

更なる選択肢によれば、ＤＮＳクエリーは、Ｓ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲ ＲＲを要求して実行され、以下のような結果となる。

IN NAPTR 100 10 ”U” ”sip+orig”
”!(^.$)!sip:orig.\1!”.
IN NAPTR 100 10 ”U” ”sip+term”
”!(^.$)!sip:term.\1!”.

この選択肢の利点は、全てのＳ−ＣＳＣＦが概して共通のＮＡＰＴＲのリソースレコードを有するということである。命令および優先フィールドが等しいので、任意のＲＲｓを選択することができ、従って発信側のセッション／トランザクションの最初のものを選択することができる。フラグ「Ｕ」は、結果がＵＲＩとなることを示す。その結果は、次のようになりうる。

sip:orig.scscf12.operator.net.

ＵＲＩのドメイン部分は、ＩＰアドレスに対してＤＮＳクエリーによって解決される。このＤＮＳクエリーは、ドメインネームを有するＡ，ＡＡＡＡまたはＡ６ ＲＲを要求して実行することが可能で、その結果はＩＰアドレスとなる。

アプリケーションサーバがメッセージを送信する適切なポートを選択または修正するという可能性がある。そのポートはアドレスの最後に付け加えられることができる。

上記例において、示されたサービスタイプは、アドレスのドメイン部分に含められた。アプリケーションサーバがアドレスのユーザ部分を選択または修正するという可能性がある。例えば、アプリケーションサーバは、次のアドレスを

scscf12.operator.net

ユーザ部分としてタグ、文字、文字列またはビット列を付け加えることによって次のように修正することが可能であり、従って、発信側のサービス（またはその逆）のためのアドレスを構築する。

orig@scscf12.operator.net

上記の実施態様では、Ｓ−ＣＳＣＦのアドレスが１つだけＨＳＳに格納される。この例において、役割は、修正ユーザ部分、修正ホストまたはドメインネーム、修正ポート番号、アドレスに付け加えられたパラメータ、またはこれらの任意の組み合わせを含むことが可能である修正アドレスによって、Ｓ−ＣＳＣＦへ送られる。好ましい形態における動作では、パラメータが存在するか、またはアドレスが修正された場合、Ｓ−ＣＳＣＦは発信側の役割を行わなければならないようなものとなる。付け加えられたパラメータが見つからない、またはアドレスが修正されない場合、Ｓ−ＣＳＣＦは受信側の役割を行う。

しかしながら、ＨＳＳ内のＳ−ＣＳＣＦの２つのアドレス（すなわち、発信側に対するアドレスおよび受信側の役割に対するアドレス）を格納することも可能である。故に、図４に示される別の実施態様に従って、Ｓ−ＣＳＣＦに対する１つ以上のアドレスが加入者管理サーバ（ＨＳＳ）２０に格納される。

より詳しくは、ＨＳＳ２０は、発信側のフィルタ基準をトリガーするための、および受信側のフィルタ基準をトリガーするためのＳ−ＣＳＣＦアドレスを格納することが可能である。アプリケーションサーバ２２は、ユーザ機器１０に代わって機能する必要がある場合に、それからＳｈインターフェースを介して所望のアドレスを取り込むことが可能である。または、アプリケーションサーバ２２は、両方のアドレスを取り込み、必要な１つを選択することが可能である。これは、実施に関わる問題である。

２つの曲線状の経路指定矢印３０および３１は、２つの異なるサービスタイプへのメッセージングを示す。メッセージング矢印３０は、受信側サービスプロファイルに基づいて実行されるユーザの受信側のサービスの情報フローを示す。メッセージング矢印３１は、発信側サービスプロファイルに基づいて実行されるユーザの発信側のサービスの情報フローを示す。

図５は、上記の実施態様によるサービスの提供の可能性を示す。ステップ１、２および４に対しては、図２および３の実施態様の説明を参照のこと。ステップ５において、サービスに対する要求として提供されるサービスは、ユーザから生じることになる。

上記の例証された通信環境において、現存のＳｈインターフェースへの拡張は、発信側のＳ−ＣＳＣＦアドレスをＨＳＳからアプリケーションサーバに引き込むことが必要となる場合がある。これは、「Ｓ−ＣＳＣＦネーム」の情報要素を包含するためのＳｈ−ｐｕｌｌ要求への拡張によって提供することができる。同様に、ＨＳＳ２０とＳ−ＣＳＣＦ１４との間のＣｘインターフェースへの拡張は、Ｓ−ＣＳＣＦ１４からＨＳＳ２０までの発信側のＳ−ＣＳＣＦアドレス情報をプッシュするために必要となる場合がある。

ストレージエンティティに格納される通信制御エンティティのアドレスまたは名前は、ユーザ部分を含んだり含まなかったりすることがあるということを理解されたい。アドレスまたは名前は、ポートを含むものまたは含まないものでも良い。

ＩＰマルチメディアサービスを有するユーザ機器の登録の間に、Ｓ−ＣＳＣＦが発信側の要求のためにそのアドレスをＣｘインターフェースを介してＨＳＳにプッシュすることが可能であるように配置してよい。Ｃｘ：Ｓ−ＣＳＣＦ登録および／または登録の取り消し通知の要求が、発信側のＳ−ＣＳＣＦおよび受信側のＳ−ＣＳＣＦのアドレスのどちらも含むように延長することが可能である。

上記の例において、 ユーザ機器は、少なくとも１つのサービングコールセッション制御機能によって登録されると考えられた。そのユーザに対する登録が見つからないか、またはＳ−ＣＳＣＦのアドレスがＨＳＳから受信されない場合は、デフォルトのアドレスか最新のアドレスを使用することが可能である。

簡潔に前述したように、アプリケーションサーバが外部のデータベースからアドレス情報を取り込むことを必要としない場合がある。上述のＨＳＳに加えて、アドレス情報は、加入者位置機能（ＳＬＦ）またはサービスおよび加入者リポジトリ（ＳＳＲ）などのあらゆる外部データベースから得ることが可能である。

アプリケーションサーバまたは他のいずれの適切なエンティティは、ユーザ機器から受信した要求からのＳ−ＣＳＣＦのアドレス情報を、最初に受信することも可能である。受信したアドレス情報を、アプリケーションサーバと一体化されたストレージエンティティに格納することが可能である。アドレス情報が発信側の要求に対して後に必要とされる場合、その情報は、それからアプリケーションサーバに内蔵されたストレージエンティティから得ることが可能である。

ユーザは間接的に発信側または受信側のサービスを生じさせることができるが、サービス通信制御エンティティ(例えばＳ−ＣＳＣＦ)のアドレスまたは名前を取り扱うことの責務は、アプリケーションサーバにあると理解されたい。従って、ユーザは、直接的にサービス通信制御エンティティのアドレス指定を行っていない。このように、アプリケーションサーバは、様々なソースから、ユーザ機器にサービスを提供することが可能な通信制御エンティティに関する情報を受信することが可能である。加入者データベース（例えばＨＳＳ）またはアプリケーションサーバの内部データベースなどのストレージエンティティに加えて、アプリケーションサーバは、サービス通信制御エンティティまたは他のいずれのネットワークエンティティから受信されるメッセージから、サービス通信制御エンティティの名前またはアドレスを得ることも可能である。このようなメッセージは、例えば、アプリケーションサーバに受信されるより以前の要求であってよい。

また、アプリケーションサーバが、ＨＳＳまたは他のデータベースから、サービス通信制御エンティティのアドレスのリストを得ることも可能である。そしてＡＳは、適切なものをそのリストから選択することが可能である。これは、例えばユーザが全く登録されておらず、ＨＳＳで利用可能なＳ−ＣＳＣＦのアドレスがない場合に有用なオプションになりうる。ＡＳは、その後、アドレスをデフォルトのＳ−ＣＳＣＦｓのリストから取り出すことが可能である。このような状況では、ＨＳＳは、それから単に機能を戻すことしかできない。ＡＳは、この情報に基づいて適切なＳ−ＣＳＣＦを選択することができる。

本発明の実施態様は移動局に関して記載されているが、本発明の実施態様は他のいずれの好適なタイプのユーザ機器にも適用可能であると理解されたい。

本発明の実施態様は、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）、ｉ−ｐｈｏｎｅまたはＣＤＭＡ２０００、および地上基盤無線（ＴＥＴＲＡ）システムなどの第三世代のモバイル通信システムというコンテキストにおいて説明された。さらにまた、所与の例は、全てのＳＩＰエンティティを有するいわゆる全ＳＩＰネットワークというコンテキストにおいて説明された。本発明はまた、他のいずれの適切な通信システム、無線あるいは固定回線システムの両方、そして規格およびプロトコルに適用可能である。これらを制限することなく、無線データ通信サービスを可能にする他の考えられる通信システムの例としては、汎用パケット無線システム（ＧＰＲＳ）、ＧＳＭ進化型高速データレート
（ＥＤＧＥ）モバイルデータネットワーク、および様々な無線ローカルエリアネットワーク（Ｗ−ＬＡＮ）アプリケーションなどが挙げられる。固定回線システムの例としては、家庭やオフィスなどの異なる場所でユーザにインターネットへのアクセスを提供する様々なブロードバンド技術が挙げられる。本発明は、通信ネットワークに用いられる規格およびプロトコルに関係なく、ネットワークエンティティが発信側のセッションまたはトランザクションを可能にするすべての通信ネットワークに適用することができる。

本発明の実施態様では、アプリケーションサーバエンティティとサービスコールセッション制御機能エンティティとの間のインターフェースについて述べた。

しかしながら、このアプリケーションサーバはサーバの一例にすぎないということを理解されたい。本発明の実施態様は、該当する場合には、他のネットワークエンティティに適用可能である。従って、アプリケーションサーバは、ゲートウェイ、他のいずれかのサーバ、プロキシ、クライアント、ユーザエージェントまたは他のいずれのネットワーク要素、機能、またはセッションまたはトランザクションを開始することが可能である同種のものに対して有効であることも理解されたい。

通信という用語は、コール、データ（例えばウェブの閲覧）またはマルチメディア通信などのあらゆるセッションまたはトランザクションを指しているということを理解されたい。

上述した以外にも、それらを置き換えたり、それらに付け加えたりするいくつかの役割がある。類似的な機構を、他の役割を取り扱うために用いることが可能である。追加的な役割を用いる場合、その追加的な役割は、例えば、それから加入者データベースに格納されるか、または新しいパラメータによって示されるそれら自身のアドレスとともに割り当てられる。

上記の実施態様は、それらが互いに実施するか、または互いに同時に並行して用いられるように組み合わせることができる。通信システムは、異なる実施を異なるネットワークエンティティで使用することができる。例えば、通信システムのエンティティは、図２に記載された解決策を使用することが可能で、同一の通信システムの別のエンティティは、図４の実施態様を使用することが可能である。

また本願明細書には、上記の本発明の実施態様を例証する一方で、添付の請求の範囲に記載された本発明の範囲を逸脱することなく、開示された解決策に対して行うことが可能な様々なバリエーション、組み合わせおよび修正があるということにも注目されたい。

本発明を具体化することが可能である通信システムを示す。 本発明の実施態様を示す。 他の実施態様を示す。 他の実施態様を示す。 実施態様を用いたサービスの提供を表すフローチャートを示す。

Claims (65)

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. 前記サービスタイプ表示子が、前記通信制御エンティティの前記アドレスに含まれる、請求項２６に記載の通信システム。
28. サービスに関連する情報を格納するためのデータベースを備える、請求項２５乃至２７のいずれかに記載の通信システム。
29. 前記データベースが、ドメインネームシステムを含む、請求項２８に記載の通信システム。
30. 前記ストレージエンティティが、前記通信制御エンティティのための少なくとも２つの異なるアドレスに関する情報を格納する、請求項２５乃至２９のいずれかに記載の通信システム。
31. 前記最初の要求が、前記要求に適用されるべきフィルタ基準を示す、請求項２５乃至３０のいずれかに記載の通信システム。
32. 通信システムのための装置であって、
    前記通信システムのユーザにサービスを提供しうる通信制御エンティティの名前又はアドレスを含む情報をストレージエンティティからの情報を受信する第１のインターフェースと、前記ストレージエンティティからの前記情報に基づいて前記通信制御エンティティに最初の要求を送る第２のインターフェースとを備えると共に、
    前記ユーザに代わって前記最初の要求を生成するように構成され、
    ここで前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、前記情報は、開始サービスと終了サービスのどちらを前記通信制御エンティティが提供すべきかを示す、
    装置。
33. ネットワークエンティティである請求項３２に記載の装置。
34. ゲートウェイ、サーバ、プロキシ、クライアント、ユーザーエージェントのいずれかである、請求項３３に記載の装置。
35. アプリケーションサーバである請求項３２に記載の装置。
36. 発信側の役割のためのアドレス及び受信側の役割のためのアドレスの、通信制御エンティティに関する２つのアドレスを格納するストレージエンティティであって、
    ユーザに代わって最初の要求を生成するために使いたいとの要求に応じて、前記アドレスの一方又は両方を送信するように構成され、
    ここで前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、前記情報は、開始サービスと終了サービスのどちらを前記通信制御エンティティが提供すべきかを示す、
    ストレージエンティティ。
37. 通信システムにおいてサービスを提供する方法であって、
    前記通信システムのユーザにサービスを提供しうる通信制御エンティティが、最初の要求を受信すること、ただし、前記最初の要求は、前記通信システムに関連付けられる第１のネットワークエンティティが前記ユーザの代わりに生成したものであり、前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、該情報は、開始サービス又は終了サービスを示すものである、前記受信することと；
    前記通信制御エンティティが、前記情報に基づいて、開始サービス又は終了サービスを提供することと；
    を含む方法。
38. 前記最初の要求は、該最初の要求に関するさらなる通信は、該要求が前記ユーザからなされたものであるかのように取り扱われるべきであることの表示子を含む、請求項３７に記載の方法。
39. 前記最初の要求はサービスタイプ表示子を含む、請求項３７又は３８に記載の方法。
40. 前記最初の要求は前記通信制御エンティティのアドレスを含み、前記サービスタイプ表示子は前記アドレスに含まれる、請求項３９に記載の方法。
41. 前記最初の要求は、該要求に適用されるべきフィルタ基準を示すように構成される、請求項３７から４０のいずれかに記載の方法。
42. 前記第１のネットワークエンティティはアプリケーションサーバを備え、前記通信制エンティティはサービング・コールセッション制御機能を備える、請求項３７から４１のいずれかに記載の方法。
43. 通信システムのユーザにサービスを提供しうる通信制御エンティティにおいて、前記通信システムに関連付けられる第１のネットワークエンティティが前記ユーザの代わりに生成した最初の要求を受信するように構成される受信手段であって、前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、前記情報は、開始サービス又は終了サービスを示す、前記受信手段と、
    前記通信エンティティが、前記情報に基づいて、開始サービス又は終了サービスを提供しうるように構成される処理手段と、
    を備える装置。
44. 前記処理手段は、前記最初の要求に関するさらなる通信は、該要求が前記ユーザからなされたものであるかのように取り扱われるべきであることの表示子に基づき、前記最初の要求に関するさらなる通信を、該要求が前記ユーザからなされたものであるかのように取り扱うように構成される、請求項４３に記載の装置。
45. 前記処理手段は、前記最初の要求に含まれる表示子に基づいてフィルタ基準を適用するように構成される、請求項４３または４４に記載の装置。
46. 前記通信制御エンティティはサービング・コールセッション制御機能を備える、請求項４３から４５のいずれかに記載の装置。
47. プロセッサで実行されるとき、該プロセッサに次の動作：
    ・ 通信システムのユーザにサービスを提供する通信制御エンティティの名前又はアドレスを含む情報を、ストレージエンティティから受信すること；及び、
    ・ 前記情報に基づき、前記通信制御エンティティへ最初の要求を送信すること；
    を実行させるコンピュータ・プログラムであって、前記最初の要求は前記ユーザに代わって生成されたものであり、前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、該情報は、開始サービスと終了サービスのどちらを前記通信制御エンティティが提供すべきかを示す、コンピュータ・プログラム。
48. 前記最初の要求は、該最初の要求に関するさらなる通信は、該要求が前記ユーザからなされたものであるかのように取り扱われるべきであることの表示子を含む、請求項４７に記載のコンピュータ・プログラム。
49. 前記通信制御エンティティが前記最初の要求に関するさらなる通信をどのように取り扱うかを決定するように前記プロセッサをさらに動作させる、請求項４７または４８に記載のコンピュータ・プログラム。
50. 前記最初の要求は、前記通信制御エンティティのアドレスに関する情報に基づいて生成される、請求項４７から４９のいずれかに記載のコンピュータ・プログラム。
51. 前記通信制御エンティティのアドレスに関する情報は、前記最初の要求が送信される前に修正される、請求項５０に記載のコンピュータ・プログラム。
52. 前記最初の要求にサービスタイプ表示子が付加される、請求項４７から５１のいずれかに記載のコンピュータ・プログラム。
53. 前記ストレージエンティティから受信した前記情報は、前記通信制御エンティティのユニバーサルリソース識別子（ＵＲＩ）を含む、請求項４７から５２のいずれかに記載のコンピュータ・プログラム。
54. 前記ストレージエンティティから受信した前記情報は、サービスタイプ表示子パラメータを含む、請求項４７から５３のいずれかに記載のコンピュータ・プログラム。
55. 前記最初の要求を送信する前にデータベースへ問合せを送信させ、前記問合せが前記通信制御エンティティの前記情報に基づいている、請求項４７から５４のいずれかに記載のコンピュータ・プログラム。
56. 前記問合わせは、所望のサービスに関するルーティング情報を得るための、ドメインネームシステムのＳＲＶの記録への問い合わせである、請求項５５に記載のコンピュータ・プログラム。
57. 前記問合わせは、利用可能なサービスを見つけ出すためのネーミングオーソリティポインタ（ＮＡＰＴＲ）のリソース記録への問い合わせである、請求項５５に記載のコンピュータ・プログラム。
58. 前記ユーザにサービスを提供することを可能にする前記通信制御エンティティに関する前記情報に対する問合せを送信させる、請求項４７から５７のいずれかに記載のコンピュータ・プログラム。
59. 前記通信制御エンティティの情報に対する少なくとも２つの異なるアドレスに関する情報が、前記ストレージエンティティに格納されており、前記要求の送信前に、前記少なくとも２つの異なるアドレスを前記ストレージエンティティから取りに行かせるように構成される、請求項４７から５８のいずれかに記載のコンピュータ・プログラム。
60. 前記最初の要求が、該要求に適用されるべきフィルタ基準を示す、請求項４７から５９のいずれかに記載のコンピュータ・プログラム。
61. プロセッサで実行されるとき、該プロセッサに次の動作：
    ・ 通信システムのユーザにサービスを提供しうる通信制御エンティティが、最初の要求を受信すること、ただし、前記最初の要求は、前記通信システムに関連付けられる第１のネットワークエンティティが前記ユーザの代わりに生成したものであり、前記最初の要求は、該要求に関連する通信の取り扱いに関する情報を含み、該情報は、開始サービス又は終了サービスを示すものである、前記受信することと；
    ・ 前記通信制御エンティティが、前記情報に基づいて、開始サービス又は終了サービスを提供することと；
    を実行させるコンピュータ・プログラム。
62. 前記最初の要求は、該最初の要求に関するさらなる通信が、該要求が前記ユーザからなされたものであるかのように取り扱われるべきであることの表示子を含む、請求項６１に記載のコンピュータ・プログラム。
63. 前記最初の要求はサービスタイプ表示子を含む、請求項６１又は６２に記載のコンピュータ・プログラム。
64. 前記最初の要求は前記通信制御エンティティのアドレスを含み、前記サービスタイプ表示子は前記アドレスに含まれる、請求項６３に記載のコンピュータ・プログラム。
65. 前記最初の要求は、該要求に適用されるべきフィルタ基準を示すように構成される、請求項６１から６４のいずれかに記載のコンピュータ・プログラム。

Images