(57)【要約】  ＩＰマルチメディアサブシステム内の加入者にセッション開始プロトコルアプリケーションサーバを割り当てる方法である。この方法は、ホーム加入者サーバにおいて加入者に対して、プロビジョンされる初期フィルタ基準セットを識別することを含み、この初期フィルタ基準セットは、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを有する。初期フィルタ基準セットは、ホーム加入者サーバから加入者に割り当てられている在圏呼／セッション制御機能に送信され、在圏呼／セッション制御機能で受信される。この汎用セッション開始プロトコルアプリケーションサーバアイデンティティは、複数のアプリケーションサーバアドレスに解決され、そのアドレスの中の１つが、加入者へのサービスのプロビジョン時で使用するために加入者に割り当てられる。この割り当てられているアドレスは、その後の使用のためにその加入者に対する在圏呼／セッション制御機能にキャッシュされる。【選択図】  なし
2009502063.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム内の加入者へセッション開始プロトコルアプリケーションサーバを割り当てる方法であって、
ホーム加入者サーバにおいて、前記加入者に対してプロビジョンされる初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを識別する工程と、
前記初期フィルタ基準セットを、前記ホーム加入者サーバから、前記加入者に割り当てられている在圏呼／セッション制御機能へ送信する工程と、
前記在圏呼／セッション制御機能において、前記初期フィルタ基準セットを受信し、前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決する工程と、
前記加入者へのサービスのプロビジョンで使用するために、前記加入者に前記アドレスの１つを割り当てる工程と、
前記在圏呼／セッション制御機能において、その後の使用のために、前記加入者に対して割り当てられているアドレスをキャッシュする工程と
を備えることを特徴とする方法。
【請求項２】
前記セッション開始プロトコルアプリケーションアイデンティティは、ＳＩＰ−ＵＲＩである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のアプリケーションサーバのアドレスは、完全記述ドメイン名あるいはＩＰアドレスである
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決する工程は、
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含むリクエストをドメインネームサーバへ送信し、
前記ドメインネームサーバが、前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティに対応する複数のアプリケーションサーバのアドレスを識別することによって応答し、
在圏呼／セッション制御機能に前記複数のアプリケーションサーバのアドレスを送信する
ことを含んでいる
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
加入者へのアプリケーションサーバのアドレスへの割当に続いて、前記在圏呼／セッション制御機能において、前記加入者と前記アドレスとの間の関連付けをキャッシュする
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項６】
当該方法は、前記セッション開始プロトコルの加入者登録で実行される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
当該方法は、前記加入者が登録抹消されているが、セッション開始プロトコルの呼の終了端にある場合に実行される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項８】
前記割り当てられているアドレスに対応する前記アプリケーションサーバから中央記憶装置へ、前記アプリケーションサーバの１つ以上のインタフェースアドレスを送信する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記中央記憶装置は、前記ホーム加入者サーバである
ことを特徴とする請求項８に記載の方法。
【請求項１０】
ＩＰマルチメディアサブシステム内で使用する在圏呼／セッション制御機能ノードであって、
加入者に対する初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを、ホーム加入者サーバから受信するために、前記ホーム加入者サーバに接続されている入力部と、
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決し、前記加入者へのサービスのプロビジョン時に使用するために、前記加入者に前記アドレスの１つを割り当てる処理手段と、
前記加入者に関連付けて、前記割り当てられているアドレスをキャッシュするメモリと
を備えることを特徴とする在圏呼／セッション制御機能ノード。
【請求項１１】
ＩＰマルチメディアサブシステム内の在圏呼／セッション制御機能とアプリケーションサーバとの間でセッション開始プロトコルメッセージをルーティングする方法であって、
前記在圏呼／セッション制御機能において、所与の加入者に割り当てられる前記アプリケーションサーバのアドレスを識別する工程と、
前記アドレスと前記加入者との間の関連付けをキャッシュする工程と、
前記加入者との間で送受信される今後のセッション開始プロトコルメッセージの転送のために、前記関連付けを使用する工程と
を備えることを特徴とする方法。
【請求項１２】
ＩＰマルチメディアサブシステムの加入者に割り当てられているＳＩＰアプリケーションサーバを識別する方法であって、
加入者へのＳＩＰアプリケーションサーバの割当時に、前記アプリケーションサーバから中央記憶装置へ、前記アプリケーションサーバの１つ以上のインタフェースのアドレスを送信する工程と、
前記中央記憶装置において、前記加入者のアイデンティティに関連付けて、受信したアドレス（群）を記憶する工程と、
前記ＩＰマルチメディアサブシステムのアプリケーションサーバにおいて、加入者からのリクエストを受信し、それに応じて前記中央記憶装置にクエリーを送信する工程と、
前記中央記憶装置で前記クエリーの受信時に、前記加入者に割り当てられている前記アプリケーションサーバに対するアドレス（あるいはアドレス群）を識別し、前記クエリーを送信しているアプリケーションサーバに、その識別されたアドレス（群）を送信する工程と
を備えることを特徴とする方法。
【請求項１３】
前記リクエストを受信する前記アプリケーションンサーバが、前記割り当てられているアプリケーションサーバでない場合、前記リクエストは、前記識別されたアドレスを使用して前記割り当てられているアプリケーションサーバへ転送され、前記加入者にアプリケーションサーバが割り当てられていない場合、前記リクエストを受信するアプリケーションサーバは、自身のアドレスを前記中央記憶装置へ送信する
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
請求項１に記載の方法と請求項１２に記載の方法を使用して、前記アプリケーションサーバから中央記憶装置へ、前記アプリケーションサーバの１つ以上のインタフェースのアドレスを送信する工程は、前記在圏呼／セッション制御機能から前記アプリケーションサーバへのＳＩＰメソッドの送信に続いて実行される
ことを特徴とする方法。
【請求項１５】
ＩＰマルチメディアサブシステムで使用するアプリケーションサーバであって、
加入者に対する在圏呼／セッション制御機能からＳＩＰメソッドを受信し、前記加入者に対して割り当てられているサーバとするアプリケーションサーバを識別するための入力部と、
自身のインタフェースアドレス（群）を、前記加入者のアイデンティティと関連付けて記憶するために中央記憶装置へ送信すること
を備えることを特徴とするアプリケーションサーバ。
【請求項１６】
ＩＰマルチメディアサブシステムで使用するアプリケーションサーバであって、
加入者に関連するリクエストを受信するための入力部と、
前記加入者を識別するクエリーを中央記憶装置に送信することと、
前記加入者に既に割り当てられているアプリケーションサーバのアドレスを含む応答を、前記中央記憶装置から受信することと、
前記割り当てられているアプリケーションサーバが前記リクエストを受信するアプリケーションでない場合、前記割り当てられているアプリケーションサーバのアドレスにリクエストを転送することと
を備えることを特徴とするアプリケーションサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野
本発明は、ＩＰマルチメディアサブシステムにおけるアプリケーションサーバの割当方法および装置に関するものである。
【０００２】
本発明に対する背景
ＩＰマルチメディアサービスは、同一セッション内の音声、ビデオ、メッセージング、データ等の動的な組み合わせを提供する。組み合わせすることが可能な基本アプリケーション数およびメディア数の増加によって、エンドユーザに提供されるサービス数は増大し、個人間通信の経験は豊かになるだろう。このことは、いわゆる「複合ＩＰマルチメディア」サービスを含む、個人向けの豊かなマルチメディア通信サービスの新世代を導くことになるだろう。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって規定された技術であり、これは、移動通信ネットワーク上でＩＰマルチメディアサービスを提供する（３ＧＰＰ  ＴＳ  ２２．２２８、ＴＳ  ２３．２２８、ＴＳ  ２４．２２９、ＴＳ  ２９．２２８、ＴＳ  ２９．２２９、ＴＳ  ２９．３２８およびＴＳ  ２９．３２９  リリース５〜７）。ＩＭＳは、標準化ＩＭＳサービスイネーブラの使用を通じて、エンドユーザの個人対個人の通信経験を豊かにするための重要な機能を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワーク上で、新規の豊かな個人対個人（クライアント・ツー・クライアント）通信サービスおよび個人対コンテンツ（クライアント・ツー・サーバ）サービスを容易にする。ＩＭＳは、ユーザ端末間（またはユーザ端末とアプリケーションサーバとの間）の呼またはセッションをセットアップおよび制御するために、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）を使用する。ＳＩＰシグナリングにより搬送されるセッション記述プロトコル（ＳＤＰ：Session Description Protocol）は、セッションのメディアコンポーネントを記述し、かつネゴシエートするために使用される。ＳＩＰがユーザ対ユーザのプロトコルとして生成されているのに対して、ＩＭＳは、オペレータおよびサービスプロバイダがサービスへのユーザアクセスを制御し、それに応じてユーザに課金することを可能にする。
【０００４】
一例として、図１は、ＧＰＲＳ／ＰＳアクセスネットワーク（ＩＭＳは、もちろん他のアクセスネットワーク上で動作してもよい）の場合に、移動ネットワークアーキテクチャにＩＭＳがどのように適合するかを概略的に示している。呼／セッション制御機能（ＣＳＣＦ：Call/Session Control Function）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを規定している。これらの内、プロキシ（Ｐｒｏｘｙ）  ＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＳＩＰ端末に対するＩＭＳ内の第１の接点である。在圏（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）は、ユーザにユーザが加入しているサービスを提供する。尋問（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）  ＣＳＣＦ（Ｉ−ＣＳＣＦ）の役割は、正規のＳ−ＣＳＣＦを識別し、そのＳ−ＣＳＣＦにＰ−ＣＳＣＦを介してＳＩＰ端末から受信するリクエストを転送することである。
【０００５】
ユーザは、規定のＳＩＰ  ＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳに参加し、ＳＩＰユーザアイデンティティに到達できるアドレスをＩＭＳに通知するメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行する場合、ＩＭＳはユーザを認証し、そのユーザに利用可能なＳ−ＣＳＣＦのセットの中からＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰでは規定されていないが、これには、負荷分散およびサービス要件を含んでも良い。Ｓ−ＣＳＣＦの割当は、ＩＭＳベースのサービスへのユーザアクセスを制御（および課金）するために重要であることに注意されたい。オペレータは、直接のユーザ対ユーザＳＩＰセッションを防ぐメカニズムを提供してもよく、そうしないと直接のユーザ対ユーザＳＩＰセッションは、Ｓ−ＣＳＣＦを回避することになる。
【０００６】
Ｓ−ＣＳＣＦがまだ選択されていない場合、登録プロセス中に、Ｓ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの担当となる。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）から必要なＳ−ＣＳＣＦ機能を受信し、その受信した機能に基づいて適切なＳ−ＣＳＣＦを選択する。［Ｓ−ＣＳＣＦ割当は、ユーザが別のパーティ（加入者）からの呼を受け、ユーザがＳ−ＣＳＣＦを現在割り当てられていない場合に、そのユーザに対しても、Ｉ−ＣＳＣＦによって実行されることに注意されたい。］登録されたユーザが引き続きＩＭＳにセッションリクエストを送信する場合、Ｐ−ＣＳＣＦは、登録プロセス中にＳ−ＣＳＣＦから受信される情報に基づいて、選択されたＳ−ＣＳＣＦにそのリクエストを転送することができる。
【０００７】
ＩＭＳサービスネットワーク内には、ＩＭＳサービス機能を実現するために、アプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供し、３ＧＰＰが規定するＭｒインタフェースを通じて端点として接続されても良いし、または、３ＧＰＰ規定のＩＳＣインタフェースを通じてＳ−ＣＳＣＦによって「リンクイン（liked in）」されても良い。後者の場合には、初期フィルタ基準（ＩＦＣ：Initial Filter Criteria）がＳ−ＣＳＣＦによって使用され、ＳＩＰセッション確立中（または、実際には、任意のＳＩＰメソッドのために、セッションに関係または非セッションに関係）、どのアプリケーションサーバが「リンクイン」されるべきかを決定する。このＩＦＣは、ユーザのユーザプロファイルの一部としてＩＭＳ登録手順中、ＨＳＳからＳ−ＣＳＣＦによって受信される。
【０００８】
図２は、ＡＳとＳ−ＣＳＣＦとの間のＩＭＳサービス制御（ＩＳＣ：IMS Service Control）インタフェースおよびＩＭＳ内の他のインタフェースを示している。図２のＡＳは、Ｓ−ＣＳＣＦへのインタフェースを１つだけ有するように示されているが、当然のことながら、実際には、ＩＳＣインタフェースは、所与のオペレータのネットワークのＣＳＣＦサーバの多く（またはすべて）が接続されている通信ネットワークの全域で使用され、ＡＳがこれらのＣＳＣＦのすべてと通信することを可能にする。［図１に示される他のエンティティは、当業者には周知であろう。］
別のインタフェース（Ｕｔ）が、ＡＳとユーザ端末（ＴＳ  ２３．００２）との間に存在するが、これは図示されていない。Ｕｔインタフェースは、例えば、パブリックサービスアイデンティティの生成および割当、例えば、「プレゼンス（存在）」サービスによって使用される権限付与（認可）ポリシーの管理、会議ポリシー管理等の自身のサービスに関する情報を、ユーザが管理することを可能にする。
【０００９】
３ＧＰＰで規定されるＩＭＳでは、加入者はＨＳＳに静的に割り当てられるが、ＡＳこそが、ネットワークによって提供されるサービスである場合に特定の値を提供する。３ＧＰＰ規格のリリース５と６の解釈は、加入者は固定の方法で特定のＳＩＰ  ＡＳに割り当てられることを示唆している。この基本概念は、所与の１つ以上のサービスに対して特定のＳＩＰ−ＡＳアプリケーションサーバによってサポートされることが加入者に提供されることである。割り当てられたＳ−ＣＳＣＦがＩＳＣインタフェースを通じて割り当てられたＡＳに到達することを可能にするために、そのサービスに関するその加入者に対するフィルタ基準（ＨＳＳからＳ−ＣＳＣＦに送信されるＩＦＣ内に含まれる）は、宛先アドレス（ＳＩＰ−ＵＲＩとして記号化される）として完全記述ドメイン名（ＦＱＤＮ：fully qualified domain name）またはＩＰアドレスを含んでいる。このことが意味することは、例えば、Ｓ−ＣＳＣＦが、特定のＩＮＶＩＴＥをＡＳに転送されるべきであると識別する場合に、Ｓ−ＣＳＣＦに、Ｃｘインタフェースを介して特定のＡＳのアドレスが提供されることである。例えば、ユーザ端末とＳＩＰ−ＡＳとの間のＵｔインタフェース等の他のインタフェースに対する正規のＡＳを識別するために、ルーティングプロキシには、特定のユーザに対するＡＳのアドレスが提供される。加入者に特定のＡＳが割り当てられる場合、端末はそのインタフェースおよびサービスに対するＡＳのアドレスで設定される、または端末はその加入者に対するＡＳのアドレスの取得方法を知っているエンティティにリクエストを送信する。「フロントエンド」はこれを実行することができ、そのような場合、ルーティング機能はフロントエンドに構成されることになる。
【００１０】
本発明の要約
上述の説明から明らかであるように、加入者へのＡＳの割当に関する既存の提案は、所与のサービスまたはサービスセットに対して、ユーザへの特定のＳＩＰアプリケーションサーバのプロビジョン（provisioning）を必要とする。これは、高レベルの利用可能性およびＡＳでの永続的なデータ記憶を必要とする。その理由は、１つのＡＳが一時的に利用不可能になる場合または適切な情報を保有しない場合、そのＡＳが割り当てられている加入者に対しては、プロビジョンされているサービス（群）は利用不可能になるからである。このアプローチの採用は、各ＡＳに冗長性の組み込みを必要としても良い。
【００１１】
本発明の第１の態様に従えば、ＩＰマルチメディアサブシステム内の加入者へセッション開始プロトコルアプリケーションサーバを割り当てる方法が提供される。この方法は、
ホーム加入者サーバにおいて、加入者に対してプロビジョンされる初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを識別する工程と、
初期フィルタ基準セットを、ホーム加入者サーバから、加入者に割り当てられている在圏呼／セッション制御機能へ送信する工程と、
在圏呼／セッション制御機能において、初期フィルタ基準セットを受信し、汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバアドレスに解決する工程と、
加入者へのサービスのプロビジョンで使用するために、加入者に複数のアプリケーションサーバアドレスの１つを割り当てる工程と、
その後の使用のために、加入者に対して割り当てられているアドレスを在圏呼／セッション制御機能でキャッシュする工程と
を備える。
【００１２】
本発明の実施形態は、加入者にＳＩＰアプリケーションサーバを割り当てるプロセスに相当の柔軟性を導入する。所与のＳＩＰアプリケーションサーバが、利用不可能になる、または所望のサービスを提供することが不可能になる場合には、Ｓ−ＣＳＣＦは、加入者に新規のアプリケーションサーバを単に割り当てれば良い。
【００１３】
好ましくは、セッション開始プロトコルアプリケーションサーバアイデンティティは、ＳＩＰ−ＵＲＩである。
【００１４】
好ましくは、複数のアプリケーションサーバアドレスは、完全記述ドメイン名またはＩＰアドレスである。
【００１５】
好ましくは、汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバアドレスに解決する工程は、汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含むリクエストをドメインネームサーバへ送信し、ドメインネームサーバが、汎用セッション開始プロトコルアプリケーションサーバアイデンティティに対応する複数のアプリケーションサーバアドレスを識別することによって応答し、在圏呼／セッション制御機能に複数のアドレスを送信することを含んでいる。
【００１６】
本発明の一実施形態では、加入者へのサービスプロビジョンで使用するために、加入者にアドレスの１つを割り当てる工程は、ドメインネームサーバによって提供されるアドレスの優先順位付けに基づいて選択することを含んでいる。選択は、優先順位に従って重み付けされている、ラウンドロビン選択に基づいても良い。
【００１７】
好ましくは、方法は、加入者へのアプリケーションサーバアドレスの割当に続いて、在圏呼／セッション制御機能において、加入者とアドレスとの間の関連付けをキャッシュすることを含んでいる。
【００１８】
本発明の上記第１の態様の方法は、セッション開始プロトコルの加入者登録で実行される。この方法は、加入者が登録抹消（unregistered）されているが、セッション開始プロトコル呼の終了端（terminating end）にある場合に実行されても良い。
【００１９】
本発明の第１の態様の実施形態では、この方法は、割り当てられているアドレスに対応するアプリケーションサーバから中央記憶装置（cetrnal store）へ、アプリケーションサーバの１つ以上のインタフェースアドレスを送信することを含んでいる。この中央記憶装置は、ホーム加入者サーバであることが好ましい。これは、アプリケーションサーバが現在知識を有していないユーザに対するＳＩＰリクエストの受信後に実行される。
【００２０】
本発明の第２の態様に従えば、ＩＰマルチメディアサブシステム内で使用する在圏呼／セッション制御機能ノードが提供される。このノードは、
加入者に対する初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを、ホーム加入者サーバから受信するために、それに接続されている入力部と、
汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバアドレスに解決し、加入者へのサービスのプロビジョン時に使用するために、加入者に複数のアプリケーションサーバアドレスの１つを割り当てる処理手段と、
加入者に関連付けて割り当てられているアプリケーションサーバアドレスをキャッシュするメモリと
を備える。
【００２１】
本発明の第３の態様に従えば、ＩＰマルチメディアサブシステム内の在圏呼／セッション制御機能とアプリケーションサーバとの間でセッション開始プロトコルメッセージをルーティングする方法が提供される。この方法は、
在圏呼／セッション制御機能において、所与の加入者に割り当てられるアプリケーションサーバのアドレスを識別する工程と、
アドレスと加入者との間の関連付けをキャッシュする工程と、
加入者との間で送受信する今後のセッション開始プロトコルメッセージの転送のために、関連付けを使用する工程と
を備える。
【００２２】
本発明の第４の態様に従えば、ＩＰマルチメディアサブシステムの加入者に割り当てられているＳＩＰアプリケーションサーバを識別する方法が提供される。この方法は、
加入者へのＳＩＰアプリケーションサーバの割当時に、アプリケーションサーバから中央記憶装置へ、アプリケーションサーバの１つ以上のインタフェースアドレスまたは別のアプリケーションサーバの１つ以上のインタフェースアドレスを送信する工程と、
中央記憶装置において、加入者のアイデンティティに関連付けて、受信したアドレス（群）を記憶する工程と、
引き続き、ＩＰマルチメディアサブシステムのアプリケーションサーバにおいて、加入者または別のネットワークエンティティからのリクエストを受信し、それに応じて中央記憶装置にクエリーを送信する工程と、
中央記憶装置でクエリーの受信時に、加入者に割り当てられているアプリケーションサーバアドレス（アドレス群）を識別し、前記クエリーを送信しているアプリケーションサーバに、識別したアドレス（群）を送信する工程と
を備える。
【００２３】
「アプリケーションサーバ」という用語は、本明細書で使用する限り、従来のＳＩＰアプリケーションサーバおよびＳＩＰインタフェースを有する他のサーバを包含するものである。
【００２４】
好ましくは、中央記憶装置は、ホーム加入者サーバであり、Ｓｈインタフェースは、インタフェースアドレス（群）をホーム加入者サーバに転送するために使用される。ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Lightweight Directory Access Protocol）および構造化照会言語（ＳＱＬ：Structured Query Language）等のプロトコルが、他の中央記憶装置にアドレス（群）を送信するために使用されても良い。
【００２５】
リクエストを受信するアプリケーションサーバは、割り当てられているアプリケーションサーバであっても良いしなくても良い。割り当てられているアプリケーションサーバでない場合には、このリクエストは識別されているアドレスを使用して、割り当てられているアプリケーションサーバに転送される。
【００２６】
このリクエストは、例えば、ＸＤＭＳのフロントエンド等のフロントエンドディストリビュータによってアプリケーションサーバで受信されても良い。
【００２７】
このリクエストは、Ｕｔインタフェースを通じて加入者端末からアプリケーションサーバに送信されても良い。
【００２８】
本発明の第１と第４の態様の組み合わせを採用することは有用であり、その場合には、アプリケーションサーバから中央記憶装置へ、アプリケーションサーバの１つ以上のインタフェースアドレスを送信する工程は、アプリケーションサーバが現在知識を有していない加入者に対して、在圏呼／セッション制御機能からアプリケーションサーバへの、例えば、ＳＩＰリクエストまたは登録メッセージ等のＳＩＰ「メソッド（method）」での送信に続いて実行される。
【００２９】
本発明の第５の態様に従えば、ＩＰマルチメディアサブシステムで使用するアプリケーションサーバが提供される。このアプリケーションサーバは、
加入者に対する在圏呼／セッション制御機能からＳＩＰメソッドを受信し、加入者に対して割り当てられているサーバとしてアプリケーションサーバを識別するための入力部と、
自身の１つ以上のインタフェースアドレスまたは別のアプリケーションサーバに対する１つ以上のインタフェースアドレスを、加入者のアイデンティティと関連付けて記憶するために中央記憶装置に送信するための送信部と
を備える。
【００３０】
本発明の第６の態様に従えば、ＩＰマルチメディアサブシステムで使用するアプリケーションサーバが提供される。このアプリケーションサーバは、
加入者に関連するリクエストを受信するための入力部と、
加入者を識別するクエリーを中央記憶装置に送信するための送信部と、
加入者に既に割り当てられているアプリケーションサーバのアドレスを含む応答を、中央記憶装置から受信するための受信部と、
割り当てられているアプリケーションサーバがリクエストを受信するアプリケーションでない場合、割り当てられているサーバのアドレスにリクエストを転送するための転送部と
を備える。
【発明を実施するための最良の形態】
【００３１】
上述で参照する３ＧＰＰ技術標準は、初期フィルタ基準（ＩＦＣ）の使用を記述し、この初期フィルタ基準は、ＨＳＳに記憶され、加入者登録時または未登録の加入者に終了呼（terminating call）がなされる場合にサービング（serving：在圏）呼／セッション制御機能（Ｓ−ＣＳＣＦ）ノードに送信される。従来は、加入者に関するＩＦＣは、例えば、完全記述ドメイン名（ＦＱＤＮ）のような特定のＳＩＰアプリケーションサーバ（ＡＳ）アドレスを含んでいる。これは、所与のサービスに対するその加入者に割り当てられるＡＳを識別する。［ＩＦＣは、それぞれのＩＭＳサービスに対応する２つ以上のＡＳアドレスを有することが可能である。］ＩＦＣ内のＡＳアドレスがＳＩＰ−ＵＲＬである場合、ＤＮＳは、ＳＩＰ−ＵＲＬをＩＰアドレスに解決するために使用される。Ｓ−ＣＳＣＦは、効率化のために、特定のＳＩＰ−ＡＳアドレスとＩＰアドレスとの間の関連付けをキャッシュしても良い。このキャッシングは、ＤＮＳクライアント（Ｓ−ＣＳＣＦ内）では一般的であり、ユーザ単位ではなくノード単位でキャッシュされる。
【００３２】
特定のアプリケーションサーバアドレスを、例えば、ＳＩＰ−ＡＳ．ｏｐｅｒａｔｏｒ．ｃｏｍ等の汎用ＡＳアイデンティティで置き換えることを、ここでは提案する。これは、所定のＡＳのグループを識別し、このＡＳグループのすべては所与のＩＭＳサービスを提供することができる。特に、ＨＳＳに記憶されている初期フィルタ基準（ＩＦＣ）は、アプリケーションサーバの汎用名（例えば、ＳＩＰ−ＡＳ．ｏｐｅｒａｔｏｒ．ｃｏｍ）でプロビジョンされる。加入者の登録時（または未登録加入者に対する呼終了時）、ＩＦＣは、３ＧＰＰ  ＴＳ  ２３．２２８、３ＧＰＰ  ＴＳ  ２９．２２８および３ＧＧ  ＴＳ  ２９．２２９に記述される手順に従ってＣｘインタフェースを介してＳ−ＣＳＣＦにダウンロードされる。ＳＩＰ−ＡＳの汎用アイデンティティは、ＩＰアドレスにさらに解決される特定の名前（例えば、ＳＩＰ−ＡＳ１．ｏｐｅｒａｔｏｒ．ｃｏｍ）に解決される、またはこの汎用アイデンティティはいくつかのＩＰアドレスに直接解決される。既存のＤＮＳメソッドは、解決プロセスで使用される。［汎用アイデンティティが、ＩＰアドレスにさらに解決される特定の名前に解決される場合には、Ｓ−ＣＳＣＦとＤＮＳとの間で２往復（ラウンドトリップ）が必要とされる。］ＩＦＣは、Ｓ−ＣＳＣＦによって、選択されたＳＩＰ−ＡＳへのサードパーティ登録メッセージ（すなわち、ＳＩＰ  ＲＥＧＩＳＴＥＲメッセージ）のプロビジョン（provision）を起動する。Ｓ−ＣＳＣＦは、加入者と、選択されたＡＳアドレスとの間の関連付けを覚えておいて、特定のＳＩＰ−ＡＳアドレスにそのフィルタのセットに対してその後のすべてのメッセージを転送する。
【００３３】
このプロセスを容易にするために、ＤＮＳには、いくつかの完全記述ドメイン名またはＩＰアドレスに解決することができる汎用ドメイン名がプロビジョンされる。汎用ドメイン名（例えば、ＳＩＰ−ＡＳ．ｏｐｅｒａｔｏｒ．ｃｏｍで、特定のＩＭＳサービスに対応する）は、多数のアプリケーションサーバを表現することができる。完全記述ドメイン名またはＩＰアドレスは、特定のアプリケーションサーバ（例えば、ＦＱＤＮの場合のＳＩＰ−ＡＳ３２．ｏｐｅｒａｔｏｒ．ｃｏｍ）を示している。本明細書で記述される柔軟なＳＩＰ−ＡＳ割当方法では、Ｓ−ＣＳＣＦが関与しないインタフェースを通じてユーザリクエストを受信することを可能にするために、割り当てられたＳＩＰ−ＡＳに中央記憶装置、通常は、ＨＳＳに、加入者のプロファイルに関連付けられているその連絡アドレス（群）をキャッシュすることを可能にすることは有用である。これにより、そのようなインタフェースを通じて受信される後のリクエストを、割り当てられたＳＩＰ−ＡＳに転送することが可能になる。
【００３４】
図３を参照して、これよりＳＩＰ−ＡＳ割当手順を、特定の加入者に対するＳＩＰ登録の状況で説明する。この手順の工程は、以下の通りであり、工程の番号は図で使用される番号に対応する。
【００３５】
１ａ．加入者端末が、Ｓ−ＣＳＣＦ（Ｐ−ＣＳＣＦ経由で）にＳＩＰ  ＲＥＧＩＳＴＥＲメッセージを送信することによって登録（ＲＥＧＩＳＴＲＡＴＩＯＮ）プロセスを開始する。
【００３６】
１ｂ．登録プロセス中、加入者に関するサービスプロファイルがＨＳＳからＳ−ＣＳＣＦへダウンロードされる。このサービスプロファイルは、汎用アプリケーションサーバアイデンティティを含む初期フィルタ基準を有している。
【００３７】
２ａ．登録プロセス完了後、Ｓ−ＣＳＣＦは、アプリケーションサーバにサードパーティ登録リクエストを送信すべきであることを、ＩＦＣから学習する。しかしながら、Ｓ−ＣＳＣＦは、まず、ＤＮＳサーバに汎用アイデンティティを送信することによって、ＩＰアドレスをＤＮＳサーバからリクエストしなければならない。ＤＮＳサーバは、それぞれの利用可能なＡＳに対応するいくつかのＩＰアドレスを返信する。このアドレスには、それぞれの優先順位の重みが付加されている。
【００３８】
２ｂ．Ｓ−ＣＳＣＦは、登録メッセージを転送するために、返信されたＩＰアドレスの１つを選択する。この選択は、ＤＮＳによって割り当てられた優先順位に従って重み付けされている、ラウンドロビン選択に基づいている。Ｓ−ＣＳＣＦは、加入者と選択されたＡＳ  ＩＰアドレスとの間のマッピングをキャッシュする。
【００３９】
２ｃ．サードパーティ登録メッセージは、Ｓ−ＣＳＣＦによって選択されたＡＳに送信される。
【００４０】
３．サードパーティ登録メッセージ受信時、ＡＳは以下の動作を実行する。
【００４１】
−ＨＳＳに自装置のアドレスを記憶する。このアドレスは、様々なインタフェースに関する一連のアドレスを実際に備えても良く、例えば、ＨＴＴＰトラフィック等のＳＩＰメッセージの受信のために様々なアドレスが存在していても良い。［アドレス（１つまたは複数のアドレス中の１つ）は、アイデンティティ解決工程中にＳ−ＣＳＣＦに提供されるＳＩＰ−ＡＳアドレスであっても良いが、そうである必要はない。］
−ＨＳＳから必要なアプリケーション固有の加入者データを取得する。
【００４２】
−ＡＳは、加入者データのその後の変更を通知して欲しいことをＨＳＳに指示する。
【００４３】
短期間では、ＳＩＰ−ＡＳは、Ｓｈインタフェースを通じて「トランスペアレントデータ」を使用して、ＨＳＳにそのアドレスを記憶しても良い。長期間では、ＳＩＰ−ＡＳアドレスは、ＨＳＳの非トランスペアレントデータに追加されても良い。
【００４４】
この例では、ＨＳＳは、ＡＳアドレス（および加入者データ）の中央リポジトリであるが、代わりに他の中央リポジトリが使用されてもよいことに注意されたい。この中央リポジトリは、ＩＭＳサービスを実現するＡＳのセットに（直接）結合するデータベースにすることができる、あるいは、オペレータ／サービスプロバイダのドメイン内のすべてのＡＳに対する総称である。
【００４５】
このプロセスの完了時、ＳＩＰ−ＡＳは、加入者に対して選択されている。ＳＩＡ−ＡＳは、ＨＳＳから加入者データのコピーを取得していて、Ｓ−ＣＳＣＦはそのユーザに割り当てられているＳＩＰ−ＡＳのアドレスをキャッシュしている。ＳＩＰ−ＡＳは、ＨＳＳで、加入者アイデンティティに関連付けて自装置のアドレスも記憶している。登録抹消中は、ＳＩＰ−ＡＳは、ＨＳＳから、記憶されているＡＳアドレスを削除する。
【００４６】
これより図４を参照して、既に登録されている加入者に関する発信呼または終了呼の処理手順を説明する。発信呼または終了呼に対するフローは、以下の通りである。
【００４７】
１．加入者に対するＳＩＰリクエストが、Ｓ−ＣＳＣＦで受信される。
【００４８】
２．Ｓ−ＣＳＣＦは、そのＳＩＰリクエストを解析する。Ｓ−ＣＳＣＦは、この加入者に対して以前にキャッシュされているＡＳＩＰアドレスを識別する。
【００４９】
３．ＳＩＰリクエストは、ＳＩＰ−ＡＳに送信される。ＳＩＰ−ＡＳは、以前の登録プロセス中にダウンロードされている加入者用のアプリケーション専用データのコピーを有していて、ＳＩＰリクエストの処理を進める。
【００５０】
これより、図５を参照して、未登録加入者に対する終了呼の処理手順を説明する。加入者は今までのところ登録抹消されていないので、Ｓ−ＣＳＣＦは、この加入者に対してキャッシュされているＳＩＰ−ＡＳＩＰアドレスを有していないし、ＳＩＰ−ＡＳもＨＳＳからのアプリケーション専用加入者データを有していない。プロセスフローは、以下の通りである。
【００５１】
１．Ｓ−ＣＳＣＦは、終了ＳＩＰリクエストを受信する。
【００５２】
２．Ｓ−ＣＳＣＦは、ＨＳＳからサービスプロファイルをダウンロードする。これは、ＳＩＰ−ＡＳに対する汎用アイデンティティを含む初期フィルタ基準を含んでいる。
【００５３】
３ａ．Ｓ−ＣＳＣＦは、そのＳＩＰリクエストを解析する。ＩＦＣの１つがマッチする場合、Ｓ−ＣＳＣＦは、アプリケーションサーバに終了ＳＩＰリクエストを送信すべきであると理解する。ＩＦＣに含まれるアプリケーションサーバアイデンティティは汎用名である。それゆえ、Ｓ−ＣＳＣＦは、ＤＮＳサーバからＩＰアドレスをリクエストする。ＤＮＳサーバは、いくつかのＩＰアドレスを返信する。
【００５４】
３ｂ．Ｓ−ＣＳＣＦは、登録メッセージを転送するために、返信されたＩＰアドレスの１つを選択する。Ｓ−ＣＳＣＦは、加入者と、選択したＡＳＩＰアドレスとの間のマッピングをキャッシュする。
【００５５】
４．終了ＳＩＰリクエストは、選択されたＳＩＰ−ＡＳに転送される。
【００５６】
５．終了ＳＩＰリクエストを受信時、ＡＳは、以下の動作を実行する。
【００５７】
−ＨＳＳにユーザに対する自装置のアドレスを記憶する。
【００５８】
−ＨＳＳから必要なアプリケーション専用加入者データを取得する。
【００５９】
−加入者データのその後の変更を通知して欲しいことをＨＳＳに指示する。
【００６０】
登録抹消中、ＳＩＰ−ＡＳは、ＨＳＳから、記憶されているＡＳデータを削除する。オプションとしては、ＳＩＰ−ＡＳおよびＳ−ＣＳＣＦは、登録抹消後の一定期間に対してデータが維持されてもよいことを示すタイマを有していても良い。この場合は、ＳＩＰ−ＡＳは、タイマの満了時に、記憶されているＡＳアドレスを削除することになる。
【００６１】
例えば、ＳＩＰ−ＡＳが別のＳＩＰ−ＡＳに（Ｓ−ＣＳＣＦから受信している）リクエストを転送する等の場合では、最初に言及したＡＳによってＨＳＳに記憶されているアドレスは、他のＡＳのアドレスであってもよいことに注意されたい。これは、ＡＳがフロントエンド（ＦＥ：front end）配信機能を有する場合、または当初選択されているＡＳからの応答がない場合に行われてもよく、新たな選択が行われる。それは、Ｓ−ＣＳＣＦによって記憶されているアドレスと、ユーザにサービスを提供しているＡＳとの間にミスマッチがある場合にも行われても良い。この場合、最初にリクエストを受信するＡＳは、加入者が別のＡＳに割り当てられているかどうかを、ＨＳＳのユーザとＡＳとの関連付けを参照することによってチェックするべきである。これが存在する場合、リクエストは正規のＡＳに転送されるべきである。ユーザがＡＳに割り当てられていない（ＨＳＳにユーザとＡＳとの関連付けがない）場合、ＡＳは、ＨＳＳにそのアドレスを書き込むべきである。これは、ＦＥからのトラフィックを正規のＡＳに転送することを可能にする。
【００６２】
加入者のＩＭＳへの登録に続いて、加入者は何らかの動作、例えば、Ｕｔインタフェースを通じてＡＳへリクエストを送信することによって、データおよび特定のＩＭＳサービス機能の変更を開始することが可能である。Ｕｔトラフィックを処理する機能エンティティはＸＤＭＳと呼ばれ、このＸＭＬ文書管理サーバ（ＸＤＭＳ：XML Document Management Server）は特定のＡＳと通常同一位置に配置される。そのＡＳのアドレスは、Ｕｔインタフェースに対するデフォルトアドレスとして端末に事前に記憶されていても良い。Ｓ−ＣＳＣＦが特定のユーザにサービスを提供しているＡＳにシグナリングを転送する場合に、ＩＳＣトラフィックが処理される方法と同様の方法で、フロントエンド機能エンティティは、Ｕｔトラフィックがユーザにサービスを提供しているＡＳと同一位置に配置されるＸＤＭＳに転送されることを保証することが要求される。
【００６３】
Ｕｔインタフェースを通じて送信される加入者端末からのリクエストは、ＸＤＭＳフロントエンドによって受信される。ＸＤＭＳフロントエンドは、ＸＤＭＳ機能性に関するＡＳのアドレスを、Ｓｈインタフェースを通じて参照する（注：これは、上記の手順で記憶されたＡＳアドレスの１つである）。ＳＩＰ−ＡＳアドレスが記憶されていない場合は、フロントエンド自体がＳＩＰ−ＡＳを選択し、ＳＩＰ−ＡＳへリクエストを転送する。リクエストが転送さされているＳＩＰ−ＡＳは、次いでＨＳＳにそのアドレスを記憶し、ＨＳＳ（または他の中央記憶装置）から加入者データを取得しし、リクエストの処理を進める。
【００６４】
図６を参照して、ＡＳが既に加入者に割り当てられている場合の、他のインタフェース（Ｕｔインタフェースを含む）からのリクエストの処理に関する汎用プロセスを、これより説明する。
【００６５】
１．リクエストが加入者端末からインタフェースを通じて受信される。このリクエストは、そのフロントエンドによって代理されるサービスに対しては、「フロントエンドディストリビュータ（ＦＥ−ＤＩＳＴ：Front End distributor）」で終了される。
【００６６】
２．ＦＥ−ＤＩＳＴは、ＨＳＳ（または他の中央記憶位置）からアプリケーションに対するＡＳアドレスをリクエストする。
【００６７】
３．ＡＳアドレスは、ＦＥ−ＤＩＳＴに返信される。
【００６８】
４．このリクエストは、ＦＥ−ＤＩＳＴによってＸＤＭＳに転送される。
【００６９】
図７を参照して、ＡＳがまだ加入者に割り当てられていない場合の、他のインタフェース（Ｕｔインタフェースを含む）からのリクエストの処理に関する汎用プロセスを、これより説明する。
【００７０】
１．リクエストが加入者端末から特定のインタフェースを通じて受信される。このリクエストは、そのフロントエンドによって代理されるサービスに対しては「フロントエンドディストリビュータ」で終了される。
【００７１】
２．ＦＥ−ＤＩＳＴは、ＨＳＳからサービスに対するＡＳアドレスをリクエストする。
【００７２】
３．ＡＳは割り当てられていないとの指示が、ＦＥ−ＤＩＳＴに返信される。
【００７３】
４．ＦＥ−ＤＩＳＴは、ＡＳを選択する（有効なＡＳ名を取得するために他のデータベースを使用してもよい）。
【００７４】
５．このリクエストは、選択されているＡＳに転送される。
【００７５】
６．その選択されているＡＳは、以下を実行する。
【００７６】
−ＨＳＳにその名前を記憶してもよい（注：トランザクションが一度だけ発生することになっていて、その後のリクエストが予期されない場合、これは必要とされなくてもよい）。
【００７７】
−ＨＳＳから加入者データを読み取る。
【００７８】
−そのリクエストを処理する。
【００７９】
ＳＩＰリクエストがＳ−ＣＳＣＦでそれ以降受信されるイベントでは、これは、上述のアプローチに従って、Ｓ−ＣＳＣＦが汎用ＡＳアイデンティティを使用して新規のＳＩＰ−ＡＳを選択することによって取り扱われても良い。ＨＳＳにその選択が通知され、順に以前に割り当てられているＡＳに、これ以上割り当てられないことを通知し、また、記憶しているデータを解放し、ユーザを忘れてもよい（ＡＳがＨＳＳにおけるデータ要素の変更に「同意（subscribed）」している結果として）。
【００８０】
当業者には、本発明の範囲から逸脱することなく、上述の実施形態を様々に変更することが可能であることが明らかであろう。
【図面の簡単な説明】
【００８１】
【図１】ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合の概略図である。
【図２】アプリケーションサーバおよび在圏呼／セッション制御機能を有するＩＰマルチメディアサブシステムのエンティティの概略図である。
【図３】ＩＭＳ登録中、加入者にＳＩＰ−ＡＳを割り当てるプロセスの概略図である。
【図４】登録加入者に対する発信呼または終了呼リクエストの処理プロセスの概略図である。
【図５】未登録加入者に対する終了呼リクエストの処理プロセスの概略図である。
【図６】加入者がＩＭＳに登録されている場合に、非ＩＳＣインタフェースを通じて加入者から受信されるリクエストの処理プロセスの概略図である。
【図７】加入者がＩＭＳに登録されていない場合に、非ＩＳＣインタフェースを通じて加入者から受信されるリクエストの処理プロセスの概略図である。
【図２】
2009502063.tif 000003
【図１】
2009502063.tif 000004
【図３】
2009502063.tif 000005
【図４】
2009502063.tif 000006
【図５】
2009502063.tif 000007
【図６】
2009502063.tif 000008
【図７】
2009502063.tif 000009
【手続補正書】
【提出日】平成19年5月14日(2007.5.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム内の加入者へセッション開始プロトコルアプリケーションサーバを割り当てる方法であって、
ホーム加入者サーバにおいて、前記加入者に対してプロビジョンされる初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを識別する工程と、
前記初期フィルタ基準セットを、前記ホーム加入者サーバから、前記加入者に割り当てられている在圏呼／セッション制御機能へ送信する工程と、
前記在圏呼／セッション制御機能において、前記初期フィルタ基準セットを受信し、前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決する工程と、
前記加入者へのサービスのプロビジョンで使用するために、前記加入者に前記アドレスの１つを割り当てる工程と、
前記在圏呼／セッション制御機能において、その後の使用のために、前記加入者に対して割り当てられているアドレスをキャッシュする工程と、
前記在圏呼／セッション制御機能から前記割り当てられているアドレスでの前記アプリケーションサーバへＳＩＰメッセージを送信する工程と、
前記アプリケーションサーバにおける前記ＳＩＰメッセージの受信時に、Ｓｈインタフェースを通じて、前記アプリケーションサーバのアドレスを非トランスペアレントデータとして前記ホーム加入者サーバに記憶する工程と
を備えることを特徴とする方法。
【請求項２】
前記セッション開始プロトコルアプリケーションアイデンティティは、ＳＩＰ−ＵＲＩである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のアプリケーションサーバのアドレスは、完全記述ドメイン名あるいはＩＰアドレスである
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決する工程は、
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含むリクエストをドメインネームサーバへ送信し、
前記ドメインネームサーバが、前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティに対応する複数のアプリケーションサーバのアドレスを識別することによって応答し、
在圏呼／セッション制御機能に前記複数のアプリケーションサーバのアドレスを送信する
ことを含んでいる
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
当該方法は、前記セッション開始プロトコルの加入者登録で実行される
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
当該方法は、前記加入者が登録抹消されているが、セッション開始プロトコルの呼の終了端にある場合に実行される
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項７】
ＩＰマルチメディアサブシステム内で使用する在圏呼／セッション制御機能ノードであって、
加入者に対する初期フィルタ基準セットであって、少なくとも１つの汎用セッション開始プロトコルアプリケーションサーバアイデンティティを含む初期フィルタ基準セットを、ホーム加入者サーバから受信するために、前記ホーム加入者サーバに接続されている入力部と、
前記汎用セッション開始プロトコルアプリケーションサーバアイデンティティを複数のアプリケーションサーバのアドレスに解決し、前記加入者へのサービスのプロビジョン時に使用するために、前記加入者に前記アドレスの１つを割り当てる処理手段と、
前記加入者に関連付けて、前記割り当てられているアドレスをキャッシュするメモリと、
前記在圏呼／セッション制御機能から前記割り当てられているアドレスにおける前記アプリケーションサーバへＳＩＰメッセージを送信する手段と
を備えることを特徴とする在圏呼／セッション制御機能ノード。
【請求項８】
ＩＰマルチメディアサブシステム内の在圏呼／セッション制御機能とアプリケーションサーバとの間でセッション開始プロトコルメッセージをルーティングする方法であって、
前記在圏呼／セッション制御機能におけるＳＩＰメッセージの受信時に、所与の加入者に割り当てられる前記アプリケーションサーバのアドレスを識別する工程と、
前記アドレスと前記加入者との間の関連付けをキャッシュする工程と、
前記加入者との間で送受信される今後のセッション開始プロトコルメッセージの転送のために、前記関連付けを使用する工程と
を備えることを特徴とする方法。
【請求項９】
ＩＰマルチメディアサブシステムの加入者に割り当てられているＳＩＰアプリケーションサーバを識別する方法であって、
加入者へのＳＩＰアプリケーションサーバの割当時に、前記アプリケーションサーバから中央記憶装置へ、前記アプリケーションサーバの１つ以上のインタフェースのアドレスを送信する工程と、
前記中央記憶装置において、前記加入者のアイデンティティに関連付けて、受信したアドレス（群）を記憶する工程と、
前記ＩＰマルチメディアサブシステムのアプリケーションサーバにおいて、加入者からのリクエストを受信し、それに応じて前記中央記憶装置にクエリーを送信する工程と、
前記中央記憶装置で前記クエリーの受信時に、前記加入者に割り当てられている前記アプリケーションサーバに対するアドレス（あるいはアドレス群）を識別し、前記クエリーを送信しているアプリケーションサーバに、その識別されたアドレス（群）を送信する工程と
を備えることを特徴とする方法。
【請求項１０】
前記リクエストを受信する前記アプリケーションンサーバが、前記割り当てられているアプリケーションサーバでない場合、前記リクエストは、前記識別されたアドレスを使用して前記割り当てられているアプリケーションサーバへ転送され、前記加入者にアプリケーションサーバが割り当てられていない場合、前記リクエストを受信するアプリケーションサーバは、自身のアドレスを前記中央記憶装置へ送信する
ことを特徴とする請求項９に記載の方法。
【請求項１１】
請求項１に記載の方法と請求項９に記載の方法を使用して、前記アプリケーションサーバから中央記憶装置へ、前記アプリケーションサーバの１つ以上のインタフェースのアドレスを送信する工程は、前記在圏呼／セッション制御機能から前記アプリケーションサーバへのＳＩＰメソッドの送信に続いて実行される
ことを特徴とする方法。
【請求項１２】
ＩＰマルチメディアサブシステムで使用するアプリケーションサーバであって、
加入者に対する在圏呼／セッション制御機能からＳＩＰメソッドを受信し、前記加入者に対して割り当てられているサーバとするアプリケーションサーバを識別するための入力部と、
自身のインタフェースアドレス（群）を、前記加入者のアイデンティティと関連付けて記憶するために中央記憶装置へ送信するための送信部と
を備えることを特徴とするアプリケーションサーバ。
【請求項１３】
ＩＰマルチメディアサブシステムで使用するアプリケーションサーバであって、
加入者に関連するリクエストを受信するための入力部と、
前記加入者を識別するクエリーを中央記憶装置に送信するための送信部と、
前記加入者に既に割り当てられているアプリケーションサーバのアドレスを含む応答を、前記中央記憶装置から受信するための受信部と、
前記割り当てられているアプリケーションサーバが前記リクエストを受信するアプリケーションでない場合、前記割り当てられているアプリケーションサーバのアドレスにリクエストを転送するための転送部と
を備えることを特徴とするアプリケーションサーバ。
【国際調査報告】
2009502063.tif 000010
2009502063.tif 000011
2009502063.tif 000012