(57)【特許請求の範囲】
【請求項１】
通信ネットワークにおいて要求側ノードから応答側ノードへのリクエストであって、ユーザに関連付けられた前記リクエストを処理し、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を有するリポジトリが前記応答側ノードに関連付けられ、前記応答側ノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられる方法であって、
前記応答側ノードの前記データ構造内における前記ユーザプロファイルの格納位置を示す固有のユーザインデックスを、前記データ構造内の各ユーザプロファイルへ割り当てるステップと、
前記要求側ノードへ少なくとも１つのユーザインデックスを通知するステップと、
前記要求側ノードによる前記リクエストに前記ユーザインデックスを組み込むステップと、
前記要求側ノードから前記応答側ノードへ前記リクエストを送信するステップと、
前記応答側ノードにおいて、前記ユーザインデックスが示す格納位置に格納された情報を、前記応答側ノードによって前記リクエストに関連付けられたユーザに関連する前記ユーザプロファイルとして取り出すステップと
を含むことを特徴とする方法。
【請求項２】
前記固有のユーザインデックスは、前記応答側ノードによって割り当てられることを特徴とする請求項１に記載の方法。
【請求項３】
前記固有のユーザインデックスは、セントラル・ノードによって割り当てられることを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザインデックスは、整数値であることを特徴とする請求項１乃至３の何れか１項に記載の方法。
【請求項５】
前記ネットワークは、ボイス・オーバ・インターネット・プロトコル（ＶＯＩＰ）ネットワークであることを特徴とする請求項１乃至４の何れか１項に記載の方法。
【請求項６】
前記ネットワークは、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークであることを特徴とする請求項１乃至５の何れか１項に記載の方法。
【請求項７】
前記リクエストは、セッション開始プロトコル（ＳＩＰ）Ｉｎｖｉｔｅを含む最初のセッション開始プロトコル（ＳＩＰ）リクエストであることを特徴とする請求項１乃至６の何れか１項に記載の方法。
【請求項８】
前記応答側ノードは、代理呼セッション制御機能（Ｐ−ＣＳＣＦ）エンティティ、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）エンティティ、セッション開始プロトコル・アプリケーション・サーバ（ＳＩＰ−ＡＳ）、又はホーム加入者サーバ（ＨＳＳ）であることを特徴とする請求項１乃至７の何れか１項に記載の方法。
【請求項９】
前記要求側ノードによる前記リクエストに前記ユーザインデックスを組み込む前記ステップは、
セッション開始プロトコルＩｎｖｉｔｅリクエスト・メッセージのセッション開始プロトコル・ヘッダを含む、前記リクエスト・メッセージの既存のデータ・エレメントに、パラメータとして前記ユーザインデックスを追加するステップと、
ユニバーサル・リソース識別子（ＵＲＩ）のユーザ部分を含む、前記リクエスト・メッセージの既存のデータ・エレメントに前記ユーザインデックスを組み込むステップと
を含むことを特徴とする請求項１乃至８の何れか１項に記載の方法。
【請求項１０】
前記要求側ノードへ少なくとも１つのユーザインデックスを通知する前記ステップは、前記ネットワークのユーザとして前記ユーザによる登録中に実行されることを特徴とする請求項１乃至９の何れか１項に記載の方法。
【請求項１１】
要求側ノードからのリクエストであって、ユーザに関連付けられた前記リクエストを処理する通信ネットワークにおいて使用されるネットワークノードであって、
複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を含むリポジトリを有し、
前記ネットワークノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられ、
前記ネットワークノードの前記データ構造内における前記ユーザプロファイルの格納位置を示す固有のユーザインデックスが、前記データ構造内の各ユーザプロファイルへ割り当てられ、かつ、前記ネットワークノードが、該ネットワークノードの外部、即ち、要求側ノードへ少なくとも１つのユーザインデックスを通知するように構成され、
前記ネットワークノードは、さらに、前記ユーザインデックスが示す格納位置に格納された情報を、前記リクエストに関連付けられた前記ユーザに関連する前記ユーザプロファイルとして取り出すように構成されることを特徴とするネットワークノード。
【請求項１２】
前記ネットワークノードは、前記データ構造の各ユーザプロファイルに、前記固有のユーザインデックスを割り当てるように構成されることを特徴とする請求項１１に記載のネットワークノード。
【請求項１３】
ユーザインデックスを含むリクエストを受信する際に、前記ユーザインデックスによって参照される格納位置に前記ノードの前記データ構造内に格納されたユーザプロファイルが前記リクエストを発行する前記ユーザに実際に関連付けられているか否かを検証するようにさらに構成されていることを特徴とする請求項１１又は１２記載のネットワークノード。
【請求項１４】
前記ノードが前記受信したリクエストが該リクエストを発行する前記ユーザに関連付けられていないと判定すると、前記リクエストを送信する前記ノードへの前記リクエストを発行する前記ユーザに関連付けられた、更新したユーザインデックスを返すようにさらに構成されることを特徴とする請求項１３に記載のネットワークノード。
【請求項１５】
応答側ノードへのリクエストであって、ユーザに関連付けられた前記リクエストを送信するための通信ネットワークにおいて使用されるネットワークノードであって、
前記応答側ノードは、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を含むリポジトリを有し、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付け、
前記応答側ノードの前記データ構造内における前記複数のユーザプロファイルの少なくとも１つのユーザプロファイルの格納位置を示す固有のユーザインデックスを前記応答側ノードから受信し、前記データ構造内に前記ユーザインデックスを格納するように構成され、
前記リクエストを送信する前に、前記リクエストに前記ユーザインデックスを組み込むように構成されることを特徴とするネットワークノード。
【請求項１６】
インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークにおける、ボイス・オーバ・インターネット・プロトコル（ＶＯＩＰ）ネットワークを含む通信ネットワークであって、
請求項１１乃至１４の何れか１項に記載の応答側ノードと、請求項１５に記載の要求側ノードとを含むことを特徴とする通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおいて、要求側ノードから応答側ノードへのユーザに関連付けられたリクエストを処理する方法に関するものである。
【背景技術】
【０００２】
ネットワークにおいて、要求側ノードから応答側ノードへのユーザに関連付けられたリクエストを処理する方法が既に知られており、当該方法は、例えばユーザに関連付けられたユーザプロファイルに格納されたユーザに関する情報であって、例えば何れのリクエストが扱われるべきかを判定するために応答側ノードによって取り出される情報を必要としてもよい。例えば、ユーザに関連する情報は、いずれのリクエストが扱われるかや、リクエストのサービスレベル、リクエストの承認レベルなどの可能性がある。そのような既知の方法は、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークにおいて使用される。ＩＭＳネットワークのいくつかのエントリは、例えば、セッション開始プロトコル（ＳＩＰ）セッション確立要求を処理する際に、データベース検索を実行する必要がある。それらのエントリの例として、代理呼セッション制御機能（Ｐ−ＣＳＣＦ）エントリ、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）エントリ及びセッション開始プロトコル・アプリケーション・サーバ（ＳＩＰ−ＡＳ）などが含まれる。
【０００３】
データベース検索を実行する必要のあるそのようなエントリを以下に例示する。
【０００４】
（１）ＩＭＳユーザが呼を確立するときに（即ち、ＳＩＰセッションを確立するとき）、Ｓ−ＣＳＣＦエントリは、Ｐ−ＣＳＣＦエントリ又はＩ−ＣＳＣＦエントリからＳＩＰ  Ｉｎｖｉｔｅを受信する。ＳＩＰ  Ｉｎｖｉｔｅは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｆｙ（ＰＡＩ）ヘッダを含む。ＰＡＩヘッダは、発呼加入者（ｔｈｅ ｃａｌｌｉｎｇ ｓｕｂｓｃｒｉｂｅｒ）を識別する。Ｓ−ＣＳＣＦエントリは、当該加入者のユーザプロファイルを獲得するために、登録された加入者の内部データベースを検索する検索基準としてＰＡＩを使用する。
【０００５】
（２）呼がＩＭＳ加入者へ確立されると（即ち、ＳＩＰセッションが確立されると）、Ｓ−ＣＳＣＦエントリは、Ｉ−ＣＳＣＦエントリからＳＩＰ  Ｉｎｖｉｔｅを受信する。ＳＩＰ  Ｉｎｖｉｔｅは、リクエスト・ユニフォーム・リソース識別子（Ｒ−ＵＲＩ）を含む。Ｒ−ＵＲＩは、着呼加入者（ｔｈｅ ｃａｌｌｅｄ ｓｕｂｓｃｒｉｂｅｒ）を識別する。Ｓ−ＣＳＣＦエントリは、当該加入者のユーザプロファイルを獲得するために、登録された加入者の内部データベースを検索する検索基準としてＲ−ＵＲＩを使用する。
【０００６】
（３）呼がＩＭＳ加入者へ確立されると、その後、加入者をサービングするＰ−ＣＳＣＦエントリは、Ｓ−ＣＳＣＦエントリからＳＩＰ  Ｉｎｖｉｔｅを受信する。Ｐ−ＣＳＣＦエントリは、当該加入者のユーザプロファイルを獲得するために、登録された加入者の内部データベースを検索する検索基準として、ＳＩＰ  ＩｎｖｉｔｅにおけるＲ−ＵＲＩ又はＰ−Ｃａｌｌｅｄ−Ｕｓｅｒヘッダに含まれる連絡先アドレスを使用する。
【０００７】
（４）ＳＩＰ−ＡＳがサービス実施（ｉｎｖｏｃａｔｉｏｎ）要求を処理する際に、その後、ＳＩＰ−ＡＳへ送信されるＳＩＰ  Ｉｎｖｉｔｅは、ＰＡＩ及びＲ−ＵＲＩの少なくとも一方を含む。ＳＩＰ  Ｉｎｖｉｔｅが発信側ＳＩＰセッション確立に関連する場合、ＳＩＰ−ＡＳは、当該加入者のユーザプロファイルを獲得するために、供給されかつ登録された加入者の内部データベースを検索する検索基準として、ＰＡＩを使用する。ＳＩＰ  Ｉｎｖｉｔｅが終端側ＳＩＰセッション確立に関連する場合、ＳＩＰ−ＡＳは、当該加入者のユーザプロファイルを獲得するために、供給されかつ登録された加入者の内部データベースを検索する検索基準として、Ｒ−ＵＲＩを使用する。
【０００８】
ＩＭＳネットワーク（例えば、ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ）が、自身のドメインに属する（例えば、ｓｉｐ： ｕｓｅｒ＿１２３４＠ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ）パブリックＳＩＰ−ＵＲＩ’ｓ、即ち、ＩＭＳパブリック・ユーザ識別子（ＩＭＰＵ）のみをサポートする場合、Ｐ−ＣＳＣＦエントリ又はＳ−ＣＳＣＦエントリなどのネットワークのノードは、当該加入者の情報を発見する、即ち、その内部加入者レコードにおける一致を発見するための検索キーとして、それらのＳＩＰ  ＵＲＩ’ｓのユーザ部分（例えば、ｕｓｅｒ＿１２３４）を使用することができる。
【０００９】
ＩＭＳネットワークが複数の他のパブリックＳＩＰ−ＵＲＩ（例えば、ｓｉｐ：ｊｏｓ．ｄｅｎ．ｈａｒｔｏｇ＠ｅｒｉｃｓｓｏｎ．ｃｏｍ）を許容する場合、ホーム加入者サーバ（ＨＳＳ）（及び、Ｓ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティ）は、加入者用の検索キーとして、この完全な文字列を使用しなければならない。
【００１０】
上記例での１つの問題点は、一般的なネットワークにおいて、要求側ノードから応答側ノードへのユーザに関連付けられたリクエストを処理するための他の方法においてもそうであるが、データベースを検索するステップ、例えば、登録された加入者のデータベースを検索するステップがいずれかのタイミングで実行されることである。上述したように、データベースからの情報の取り出しを要求するリクエストを取り扱う場合には、当該処理は、リクエストを処理する際に遅延の原因となりうる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、上述した問題に鑑みて成されたものであり、ＩＭＳネットワークにおいて、リクエストに関連付けられたユーザに関連するユーザプロファイルをデータベースに効果的に配置するための方法を提供する。
【課題を解決するための手段】
【００１２】
したがって、本発明によれば、以下の方法を提供する。即ち、通信ネットワークにおいて要求側ノードから応答側ノードへのリクエストであって、ユーザに関連付けられた前記リクエストを処理し、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を有するリポジトリが前記応答側ノードに関連付けられ、前記応答側ノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられる方法であって、前記データ構造内の前記ユーザプロファイルの位置を示す固有のユーザインデックスを、前記データ構造内の各ユーザプロファイルへ割り当てるステップと、前記要求側ノードへ少なくとも１つのユーザインデックスを通知するステップと、前記要求側ノードによる前記リクエストに前記ユーザインデックスを組み込むステップと、前記要求側ノードから前記応答側ノードへ前記リクエストを送信するステップと、前記ユーザインデックスに基づき、前記応答側ノードによって前記リクエストに関連付けられたユーザに関連する前記ユーザプロファイルを取り出すステップとを含むことを特徴とする。
【００１３】
より好ましくは、前記固有のユーザインデックスは、前記応答側ノードによって割り当てられる。また、前記固有のユーザインデックスは、セントラル・ノードによって割り当てられる。
【００１４】
これは、要求側ノードが、例えば応答側ノードによって、ユーザインデックスが与えられ、それにより、応答側ノードが当該応答側ノードによって容易に処理可能なユーザインデックスを生成するという利益を享受する。ユーザインデックスが応答側ノードのデータ構造内のユーザプロファイルの位置を示すため、応答側ノードは、ユーザプロファイルを含むデータ構造内の位置に直接アクセスすることができる。したがって、応答側ノードは、必要とされるユーザプロファイルがデータ構造内に格納されているかを検索する必要がない。
【００１５】
選択的に、ユーザインデックスは整数値であってもよい。発明者はユーザ部分及びドメインネームが長くなりうることに気付いている。したがって、検索キーとして、文字列”ｕｓｅｒ＠ｄｏｍａｉｎ”を検索するステップが処理負荷の高いものとなりうる。整数値であるユーザインデックスを割り当てるステップは、ユーザインデックスがユーザプロファイルのデータ構造内の位置へのポインタであることを許容する。
【００１６】
本発明の他の形態によれば、ユーザインデックスが整数値であるが、当該整数値がユーザプロファイルのデータ構造内の位置を示さない可能性もあることが理解されるであろう。これは、整数サーチが故事列サーチよりもより高速に実行する利益を与えるであろう。
【００１７】
選択的に、ネットワークは、ボイス・オーバ・インターネット・プロトコル（ＶＯＩＰ）ネットワークであり、より好ましくは、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークである。リクエストは、セッション開始プロトコル（ＳＩＰ）ｉｎｖｉｔｅなどの最初のセッション開始プロトコル（ＳＩＰ）であってもよい。
【００１８】
このように、本発明の一形態によれば、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークにおいて要求側ノードから応答側ノードへの最初のセッション開始プロトコル（ＳＩＰ）リクエストであって、ユーザに関連付けられた前記最初のセッション開始プロトコル（ＳＩＰ）リクエストを処理し、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を有するリポジトリが前記応答側ノードに関連付けられ、前記応答側ノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられる方法であって、前記データ構造内の前記ユーザプロファイルの位置を示す固有のユーザインデックスを、前記データ構造内の各ユーザプロファイルへ割り当てるステップと、前記要求側ノードへ少なくとも１つのユーザインデックスを通知するステップと、前記要求側ノードによる前記最初のセッション開始プロトコル（ＳＩＰ）リクエストに前記ユーザインデックスを組み込むステップと、前記要求側ノードから前記応答側ノードへ前記最初のセッション開始プロトコル（ＳＩＰ）リクエストを送信するステップと、前記ユーザインデックスに基づき、前記応答側ノードによって前記最初のセッション開始プロトコル（ＳＩＰ）リクエストに関連付けられたユーザに関連する前記ユーザプロファイルを取り出すステップとを含むことを特徴とする。
【００１９】
応答側ノードは、代理呼セッション制御機能（Ｐ−ＣＳＣＦ）エンティティ、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）エンティティ、セッション開始プロトコル・アプリケーション・サーバ（ＳＩＰ−ＡＳ）、又はホーム加入者サーバ（ＨＳＳ）であってもよい。Ｐ−ＣＳＣＦエンティティ、Ｓ−ＣＳＣＦエンティティ、ＳＩＰ−ＡＳ、又はＨＳＳはリポジトリであってもよい。
【００２０】
選択的に、前記要求側ノードによる前記リクエストに前記ユーザインデックスを組み込む前記ステップは、セッション開始プロトコルＩｎｖｉｔｅリクエスト・メッセージのセッション開始プロトコル・ヘッダなどの、前記リクエスト・メッセージの既存のデータ・エレメントに、パラメータとして前記ユーザインデックスを追加するステップと、ユニバーサル・リソース識別子（ＵＲＩ）のユーザ部分などの、前記リクエスト・メッセージの既存のデータ・エレメントに前記ユーザインデックスを組み込むステップとを含む。ユーザインデックスは、例えば、最初のＩｎｖｉｔｅリクエスト・メッセージのＳＩＰ  Ｒｏｕｔｅヘッダにパラメータとして追加されてもよい。ここで、Ｒｏｕｔｅヘッダは、応答側ノードがＳＩＰ  Ｕｓｅｒ  Ａｇｅｎｔであり、応答側ノードがＳ−ＣＳＣＦである場合において、応答側ノードからの要求側ノードによって受信されるＳｅｒｖｉｃｅ経路を含む。パラメータとしてユーザインデックスを追加するステップは、応答側ノードが本発明に係る機能に適応されない場合には、応答側ノードはパラメータを無視してもよい。したがって、本発明に従って機能する応答側ノードが本発明に従って機能しない要求側ノードに適合するため又はその逆において、ネットワークの何れかのノードにおいて本発明の方法を実装することが可能である。このように、既存のネットワークに対して本発明を実装するために、ネットワークにおける多くのノードの大規模なアップグレードを必要としない。
【００２１】
選択的に、少なくとも１つのユーザインデックスを要求側ノードに通知するステップは、ユーザインデックスに関連付けられたユーザによってネットワークのユーザとして登録中に実行される。
【００２２】
選択的に、本方法は、ユーザインデックスを含むリクエストを受信する際に、前記ユーザインデックスによって参照される位置に前記ノードの前記データ構造内に格納されたユーザプロファイルが前記リクエストを発行する前記ユーザに実際に関連付けられているか否かを検証するステップを含む。したがって、応答側ノードは、受信したユーザインデックス上で、バリディティチェックを実行してもよい。前記応答ノードが前記受信したリクエストが該リクエストを発行する前記ユーザに関連付けられていないと判定すると、本方法は、応答側ノードが（既知の）ユーザプロファイル取り出し方法を実行する構成に戻すステップを含んでもよい。選択的に、本方法は、上述したバリディティチェックが否定的な結果を示す場合、応答側ノードによって、更新した（例えば、新たな）ユーザインデックスを要求側ノードへ返すステップを含む。
【００２３】
本発明は、また、要求側ノードからのリクエストであって、ユーザに関連付けられた前記リクエストを処理する通信ネットワークにおいて使用されるネットワークノードに関連する。当該ノードは、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を含むリポジトリを有し、前記ネットワークノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられ、前記データ構造内の前記ユーザプロファイルの位置を示す固有のユーザインデックスが、前記データ構造内の各ユーザプロファイルへ割り当てられ、かつ、前記ネットワークノードが、該ネットワークノードの外部、即ち、要求側ノードへ少なくとも１つのユーザインデックスを通知するように構成され、前記ネットワークノードは、さらに、前記ユーザインデックスに基づき、前記リクエストに関連付けられた前記ユーザに関連する前記ユーザプロファイルを取り出すように構成される。このようなネットワークノードは、通信ネットワーク内の応答側ノードとして機能してもよいことが理解されるであろう。
【００２４】
本発明は、また、応答側ノードへのリクエストであって、ユーザに関連付けられた前記リクエストを送信するための通信ネットワークにおいて使用されるネットワークノードに関連する。当該ノードは、複数のユーザに関連付けられた複数のユーザプロファイルを含むデータ構造を含むリポジトリを有し、前記ネットワークノードにおいて、複数のユーザプロファイルのうちの１つのユーザプロファイルが前記ユーザに関連付けられ、前記データ構造内の前記複数のユーザプロファイルの少なくとも１つのユーザプロファイルに関連付けられた固有のユーザインデックスを前記応答側ノードから受信し、前記データ構造内に前記ユーザインデックスを格納するように構成され、前記リクエストを送信する前に、前記リクエストに前記ユーザインデックスを組み込むように構成される。このようなネットワークノードは、通信ネットワーク内の要求側ノードとして機能してもよいことが理解されるであろう。
【００２５】
本発明は、また、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークにおける、ボイス・オーバ・インターネット・プロトコル（ＶＯＩＰ）ネットワークなどの通信ネットワークに関連する。当該通信ネットワークは、上記応答側ノード及び上記要求側ノードを含む。
【図面の簡単な説明】
【００２６】
以下では、以下の図面を参照して実施例を説明することにより、本発明を限定することなく、より詳細に説明する。
【図１】本発明に係るシステムの一例を示す図である。
【図２】本発明に係る方法の一例を示す図である。
【図３】一実施形態に係る静的な加入者データの配信を示す図である。
【図４】一実施形態に係る発信側の呼確立を示す図である。
【図５】一実施形態に係る終端側の呼確立を示す図である。
【発明を実施するための形態】
【００２７】
図１は、本発明に係るシステムの一例を示す図である。図２は、本発明に係る方法の一例を示す図である。図２において、応答側ノード１と要求側ノード２との間の通信が示されている。
【００２８】
所定のタイミングにおいて、ユーザ１００は、応答側ノード１を登録する。応答側ノードは、例えば、以下で説明する実施形態において、登録エンティティでありうる。応答側ノードは、リポジトリ４のデータ構造内にユーザ１００に関連するユーザプロファイルを格納し、例えば、インデックス生成部５によってユーザプロファイルにユーザインデックスを割り当てる。本実施例において、ユーザインデックスは、データ構造内でのユーザプロファイルの位置を示す。ユーザインデックスは、例えば、データ構造内のユーザプロファイルの開始のメモリ位置を示す整数値であってもよい。応答側ノード１、例えば、応答側ノード１の出力モジュール６は、ユーザインデックスを、応答側ノード１と通信可能に接続された要求側ノード２に通知する。要求側ノード２は、例えば、入力モジュール８を用いて、ユーザインデックスを受信し、要求側ノード２のリポジトリ１０に当該ユーザインデックスを格納する。或いは、要求側ノード２は、ユーザインデックスを当該ユーザと繋げてもよい。これにより、当該システムが使用可能になる。
【００２９】
要求側ノード２がユーザ１００に関連するリクエストを受信すると、要求側ノード２は、ユーザ１００に関連付けられたユーザインデックスをリクエストに組み込む。次に、要求側ノード２は、応答側ノード１に対して、例えば、出力モジュール１２を用いて、当該リクエストを送信する。要求側ノード２が入力モジュール８、リポジトリ１０、及び出力モジュール１２を制御するために、かつ、メッセージ及びユーザインデックスを処理するためにプロセッサ１４を備えてもよいことが理解されるであろう。
【００３０】
リクエストを受信すると、例えば入力モジュール１６を用いて、応答側ノード１は、リクエスト内のユーザインデックスを認識し、当該ユーザインデックスに基づいて、リクエストに関連付けられたユーザに関連するユーザプロファイルをデータ構造内から取り出してもよい。ユーザインデックスがデータ構造内のユーザプロファイル位置を示すため、ユーザプロファイルを取り出すために応答側ノード１によって必要とされる時間が減少されうることは理解されるであろう。また、応答側ノード１が入力モジュール１６、リポジトリ４、及び出力モジュール６を制御するために、かつ、メッセージ及びユーザインデックスを処理するためにプロセッサ１８を備えてもよいことが理解されるであろう。
【００３１】
ユーザプロファイルが取り出されるとすぐに、応答側ノード１は、例えばリクエストを送信先の加入者（例えば、インスタント・メッセージの着呼側パーティ又は意図した受信側）に転送することによって、当該リクエストを処理してもよい。
【００３２】
上記方法において、例えば、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）エンティティ、代理呼セッション制御機能（Ｐ−ＣＳＣＦ）エンティティ、セッション開始プロトコル・アプリケーション・サーバ（ＳＩＰ−ＡＳ）又はホーム加入者サーバ（ＨＳＳ）がリポジトリを含む応答側ノードとして動作する可能性がある。それらのケースでは、ユーザインデックスが当該Ｓ−ＣＳＣＦエンティティ、Ｐ−ＣＳＣＦエンティティ、ＳＩＰ−ＡＳ又はＨＳＳのそれぞれにおけるローカルユーザインデックスであることが理解されるであろう。ユーザインデックスはリポジトリにおけるデータ構造内においてユーザプロファイルの位置を表す。
【００３３】
そのようなノード・オリエンテッドのユーザインデックスが使用される場合、ユーザインデックスの発行元は、発行された値が当該ノードにおけるリポジトリのデータ構造において使用された値と同様の値であることを確認することができる。そこで、当該ノードが、データを格納するためにレコード及びレコード・ポインタを使用する場合、発行されたユーザインデックス（例えば、整数値）は、（例えば、ポインタとして）直接的に使用されうる。
【００３４】
他の実施形態において、ホーム加入者サーバは、応答側ノードとして動作してもよい。この場合、ユーザインデックスはローカル又はグローバル・ユーザインデックスであってもよい。
【００３５】
加入者がＨＳＳにおいてサービス提供を受ける場合、ＨＳＳはユーザインデックス、例えば、整数値をユーザに割り当ててもよい。この整数値は、ユーザのパブリック・ユーザ識別子（ＩＭＰＵ）又は加入者レコードへまとめてリンク付けられてもよい。後者の場合、加入者が複数のＩＭＰＵを有していれば、ユーザインデックスが複数のＩＭＰＵへ関連してもよい。
【００３６】
ＨＳＳは、通常、内部リポジトリのサービス提供を行う加入者を格納するために配列構造又はリスト構造を使用してもよい。当該配列構造又はリスト構造の各エントリは（例えば、整数の）識別子を有するであろう。当該識別子は、本発明においてユーザインデックスとして使用されてもよい。複数のＨＳＳが使用されると、各ＨＳＳは、当該ＩＭＳネットワークにおいて加入者に使用される全てのユーザインデックスが独自性を保証するように、ＨＳＳ識別子をユーザインデックスに加える、例えば、固有の１０進数字を整数値に加えることができる。複数のＨＳＳが分散され、加入者ロケーション機能（ＳＬＦ）が直接的なメッセージを正しいＨＳＳへ向けるために使用されることから、複数のＨＳＳの中での独自性が厳密に必要とされることがないことは理解されるであろう。
【００３７】
ＨＳＳによって発行されたユーザインデックスはまた、応答側ノードとして動作する際に、他の分散したノードによっても使用されることができるセントラル・ユーザインデックスとして使用されうる。そのようなセントラル・ユーザインデックスが使用されると、セントラル・ノード（ＨＳＳ）によって使用される値の範囲（ＨＳＳユーザインデックス用の）が応答側ノードとして動作する場合のそれらのインデックスを使用しなければならない分散ノード（ｔｈｅ ｄｅｃｅｎｔｒａｌ ｎｏｄｅ）のレコード量よりも大きくなる可能性がある。そこで、分散ノードがＨＳＳによって発行されるような当該範囲に適応するために、より多くのレコード（及びポインタ）を割り当てるか、或いは、分散ノードがＨＳＳによって発行されたときのインデックスを分散ノード自身によって使用されるようなインデックス（及び、ポインタ）へマップする内部テーブルを使用するかの何れかである。
【００３８】
分散ノードがＨＳＳによって発行された場合の範囲に適応するようにより多くのレコード（及びポインタ）が割り当てられる場合には、ＨＳＳのユーザインデックスは、ＨＳＳ及び分散ノードの両方にとって、それぞれが、ＨＳＳ及び分散ノードのリポジトリのユーザプロファイルの位置を表すことが理解されるであろう。
【００３９】
分散ノードがＨＳＳによって発行されたときのインデックス（及び、ポインタ）を分散ノード自身によって使用されるようなインデックス（及び、ポインタ）へマップする内部テーブルを使用する場合には、ＨＳＳのユーザインデックスは、ＨＳＳのリポジトリのユーザプロファイルの位置を表すことが理解されるであろう。
【００４０】
上記方法及びシステムを以下の実施例においてより詳細に説明する。
【００４１】
＜第１の実施形態：ＳＩＰセッションを発信するためのＳ−ＣＳＣＦオリエンテッド・ユーザインデックス＞
インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）加入者が応答側ノードとしてサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）エンティティに登録されると、Ｓ−ＣＳＣＦエンティティはＳｅｒｖｉｃｅ−Ｒｏｕｔｅ（サービス経路）とともに加入者を提供する。当該Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅは要求側ノードとしてユーザ・エージェント（ＵＡ）によって格納され、セッション開始プロトコル（ＳＩＰ）セッションを確立する際にユーザ・エージェントによって使用される。ＵＡはＳＩＰ  Ｉｎｖｉｔｅ（又は、他のＳＩＰリクエスト）のＲｏｕｔｅヘッダを満たすために、受信したＳｅｒｖｉｃｅ−Ｒｏｕｔｅを使用する。この方法において、ＳＩＰ  Ｉｎｖｉｔｅは、当該加入者が登録されているＳ−ＣＳＣＦエンティティを介して経路付けられるであろう。Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅは、Ｓ−ＣＳＣＦのホストネーム及びオプションとしてユーザ部分を含む、セッション開始プロトコル・ユニフォーム・リソース識別子（ＳＩＰ  ＵＲＩ）の形式を有する。
【００４２】
Ｓ−ＣＳＣＦに関連するＳｅｒｖｉｃｅ−ＲｏｕｔｅのＳＩＰ  ＵＲＩは例えばＳｅｒｖｉｃｅ−Ｒｏｕｔｅ：＜ｓｉｐ：ｏｒｉｇ＠Ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ＞のように構成されてもよい。
【００４３】
Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅは、１つ以上のパラメータを含む。上述のように、’ｌｒ’パラメータは、一例であり、ルーズ・ルーティング（ｌｏｏｓｅ ｒｏｕｔｉｎｇ）を示す。
【００４４】
本発明の一形態によれば、Ｓ−ＣＳＣＦエンティティは、Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅにおけるパラメータとしてユーザインデックスを含み、本実施形態において、ユーザインデックス・パラメータは、Ｓ−ＣＳＣＦエンティティにおけるリポジトリのデータ構造における位置を示す。当該位置は必要とされるユーザプロファイルの位置である。例えば、
Ｓｅｖｉｃｅ−Ｒｏｕｔｅ：    ＜ｓｉｐ：ｏｒｉｇ＠ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ；ｕｓｅｒ−ｉｎｄｅｘ＝１２４５７＞  又は、
Ｓｅｖｉｃｅ−Ｒｏｕｔｅ：    ＜ｓｉｐ：ｏｒｉｇ＿ｕｓｅｒ１２４５７＠ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ＞
と示される。
【００４５】
パラメータｕｓｅｒ−ｉｎｄｅｘ＝１２４５７は、当該加入者のユーザプロファイルがユーザプロファイルを含むＳ−ＣＳＣＦエンティティの内部データ構造において１２４５７の位置に配置されていることを示す。第２の形態において、Ｓ−ＣＳＣＦアドレスのユーザ部分においてユーザインデックスを含む。これは、要求側ノードが個別のアドレスパラメータ（ｕｓｅｒ−ｉｎｄｅｘ＝１２４５７）を格納する際や後に使用する際に追加の動作を必要としないという更なる利益を享受する。
【００４６】
ユーザは、従来技術に従って、呼を確立する際に、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅをＳＩＰ  ＩｎｖｉｔｅのＲｏｕｔｅヘッダにコピーする。当該Ｒｏｕｔｅヘッダは、Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅのパラメータも含むであろう。そこで、当該Ｒｏｕｔｅヘッダは、ユーザインデックスを含むであろう。Ｓ−ＣＳＣＦエンティティは、この方法において、着信ＳＩＰ  Ｉｎｖｉｔｅを、ユーザプロファイルを含む内部データ構造における位置１２４５７に直接関連付けることができる。
【００４７】
それにもかかわらず、Ｓ−ＣＳＣＦエンティティは、自身の内部データ構造における位置１２４５７が加入者のユーザプロファイルを実際に含むことをさらに検証してもよい。このようなケースでなければ、Ｓ−ＣＳＣＦエンティティがユーザインデックスを無視し、ユーザプロファイルを発見する標準的な方法に戻る。
【００４８】
＜第２の実施形態：ＳＩＰセッションを終端するためのＳ−ＣＳＣＦオリエンテッド・ユーザインデックス＞
インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）加入者がＳ−ＣＳＣＦエンティティに登録する場合、応答側ノードとしてのＳ−ＣＳＣＦエンティティは、そのアドレスをホーム加入者サーバ（ＨＳＳ）へ提供し、そのため、ＨＳＳはそれに続く着信ＳＩＰセッションを当該Ｓ−ＣＳＣＦエンティティへ導くことができる。Ｓ−ＣＳＣＦエンティティは、Ｄｉａｍｅｔｅｒサーバ・アシスト要求（ＳＡＲ）の指定されたパラメータでそのアドレスを提供してもよい。その後、ＨＳＳが問い合わせ呼セッション制御機能（Ｉ−ＣＳＣＦ）エンティティからのＤｉａｍｅｔｅｒ位置情報要求（ＬＩＲ）を受信すると、ＨＳＳは、Ｄｉａｍｅｔｅｒロケーション情報応答（ＬＩＡ）において、格納しているＳ−ＣＳＣＦエンティティのアドレスをＩ−ＣＳＣＦエンティティに返す。ＬＩＡにおいて指定されたパラメータは、Ｓ−ＣＳＣＦエンティティ・ネーム（即ち、ＳＩＰ  ＵＲＩの形式でのアドレス）をＩ−ＣＳＣＦエンティティへ返すために使用されてもよい。
【００４９】
Ｓ−ＣＳＣＦエンティティがＨＳＳにそのアドレスを提供する場合（Ｄｉａｍｅｔｅｒ  ＳＡＲにおいて）、Ｓ−ＣＳＣＦエンティティはユーザインデックス・パラメータをそのアドレスを含むＳＩＰ  ＵＲＩへ加えてもよい。そこで、
Ｓｅｒｖｅｒ ｎａｍｅ＝ｓｉｐ：ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ
のアドレスを登録加入者用のＨＳＳに提供する代わりに、Ｓ−ＣＳＣＦエンティティは、
Ｓｅｒｖｅｒ ｎａｍｅ＝ｓｉｐ：ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ；ｕｓｅｒ−ｉｎｄｅｘ＝１２４５７
のアドレスを当該登録加入者用のＨＳＳに提供する。ここで、ユーザインデックスはパラメータ”ｕｓｅｒ−ｉｎｄｅｘ”に含まれる。Ｓ−ＣＳＣＦは、また、
Ｓｅｒｖｅｒ ｎａｍｅ＝ｓｉｐ：ｕｓｅｒ＿１２４５７＠ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ
のアドレスを当該登録加入者用のＨＳＳに提供する可能性がある。ここで、ユーザインデックスはユーザアドレスのユーザ部分に含まれる。Ｓ−ＣＳＣＦは、また、
Ｓｅｒｖｅｒ ｎａｍｅ＝ｓｉｐ：ｕｓｅｒ＿１２４５７＿ｏｒｉｇ＠ｓ−ｃｓｃｆ１．ｉｍｓ．ｐｒｏｖｉｄｅｒ．ｃｏｍ；ｌｒ
のアドレスを当該登録加入者用のＨＳＳに提供する可能性がある。ここで、ユーザインデックスはユーザアドレスのユーザ部分に含まれる。この例において、Ｓ−ＣＳＣＦは、当該登録加入者用の発信側アドレスと終端側アドレスと区別するために、ユーザ部分に”ｏｒｉｇ”を追加する。
【００５０】
ＨＳＳがＤｉａｍｅｔｅｒ  ＬＩＡをＩ−ＣＳＣＦエンティティに送信する場合、Ｄｉａｍｅｔｅｒ  ＬＩＡに応じて、ＨＳＳはユーザインデックス、例えば、ｕｓｅｒ−ｉｎｄｅｘ＝１２４５７パラメータを含むＳ−ＣＳＣＦエンティティ・アドレスをＩ−ＣＳＣＦエンティティへ提供する。Ｉ−ＣＳＣＦエンティティは、Ｉ−ＣＳＣＦエンティティがＳ−ＣＳＣＦエンティティに転送するであろうＳＩＰ  ＩｎｖｉｔｅのＲｏｕｔｅヘッダに設定するために、ＨＳＳから受信した、任意のパラメータ又はユーザ部分におけるユーザインデックスを含むＳ−ＣＳＣＦエンティティ・アドレスを使用する。このように、Ｓ−ＣＳＣＦエンティティは、着信ＳＩＰ  Ｉｎｖｉｔｅを、ユーザプロファイルを含むその内部データ構造において位置１２４５７に直接関連付ける。Ｓ−ＣＳＣＦエンティティは、実際に加入者のユーザプロファイルを含むその内部データ構造において位置１２４５７をさらに検証するようにしてもよい。
【００５１】
＜第３の実施形態：サーバ発のＳＩＰセッションのためのＳ−ＣＳＣＦオリエンテッド・ユーザインデックス＞
発信側ＳＩＰセッション確立は、Ｉ−ＣＳＣＦエンティティがＨＳＳからのＳ−ＣＳＣＦエンティティ・アドレスを得るために、要求側ノードとしてのＩ−ＣＳＣＦエンティティを介して実行されてもよい。そのような状況は、当該加入者のＳ−ＣＳＣＦエンティティ・アドレスを知らないＳＩＰアプリケーション・サーバによってセッションが確立される際に発生しうる。この場合、Ｉ−ＣＳＣＦエンティティは、Ｒｏｕｔｅヘッダの応答側ノードとしてのＳ−ＣＳＣＦエンティティへ当該Ｉ−ＣＳＣＦエンティティを介してＳＩＰ  Ｉｎｖｉｔｅを経路付けるために使用される、ＲｏｕｔｅヘッダのＳＩＰ  ＵＲＩにおける’ｏｒｉｇ’パラメータを受信する。Ｉ−ＣＳＣＦエンティティはＨＳＳに接続し、ＨＳＳは格納されたＳ−ＣＳＣＦエンティティ・アドレスをＩ−ＣＳＣＦエンティティへ提供する。この格納されたＳ−ＣＳＣＦエンティティ・アドレスは、登録の際に、Ｓ−ＣＳＣＦエンティティによってＨＳＳへ提供されるＳ−ＣＳＣＦエンティティ・アドレスである。
【００５２】
登録中にＳ−ＣＳＣＦエンティティによってＨＳＳに提供されたＳ−ＣＳＣＦエンティティ・アドレスは、Ｓ−ＣＳＣＦエンティティに関連するユーザプロファイル・インデックスを含むパラメータに拡張される。したがって、Ｉ−ＣＳＣＦエンティティは、パラメータを含む当該Ｓ−ＣＳＣＦエンティティ・アドレスを受信し、ＳＩＰ  ＩｎｖｉｔｅをＳ−ＣＳＣＦエンティティへ経路付ける。ＳＩＰ  Ｉｎｖｉｔｅのユーザインデックス・パラメータは、Ｓ−ＣＳＣＦエンティティが当該加入者におけるユーザプロファイルを直接選択することを許容する。Ｓ−ＣＳＣＦエンティティは、内部データ構造内を示す位置が実際に加入者のユーザプロファイルを含むことをさらに検証してもよい。
【００５３】
Ｓ−ＣＳＣＦエンティティが２つのアドレス：当該Ｓ−ＣＳＣＦエンティティを通じてＳＩＰセッション確立を終端するためのアドレスと、当該Ｓ−ＣＳＣＦエンティティを通じてＳＩＰセッション確立を発信するための他のアドレスとを、ＨＳＳへ提供してもよいことは理解されるであろう。ユーザインデックスは、終端側ＳＩＰセッションのアドレス、発信側ＳＩＰセッションのアドレス、又は両方のアドレスへ追加されてもよい。
【００５４】
＜第４の実施形態：ＳＩＰセッションを終端するためのＰ−ＣＳＣＦオリエンテッド・ユーザインデックス＞
インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）加入者がＳ−ＣＳＣＦエンティティに登録する場合、ＳＩＰレジスタ・メッセージがＰ−ＣＳＣＦエンティティを通過する。Ｐ−ＣＳＣＦエンティティはＳＩＰレジスタのＰａｔｈヘッダに含まれるであろう。Ｓ−ＣＳＣＦエンティティは、Ｐａｔｈヘッダに含まれるＳＩＰ  ＵＲＩを格納し、ＳＩＰセッション確立を終端するためのＲｏｕｔｅヘッダをＩＭＳ加入者に設定するために、当該ＳＩＰ  ＵＲＩを使用する。
【００５５】
上述したＳ−ＣＳＣＦオリエンテッド・ユーザインデックスの説明に沿って、応答側ノードとしてのＰ−ＣＳＣＦエンティティは、以下のＰａｔｈヘッダ：
Ｐａｔｈ：＜ｓｉｐ：ｔｅｒｍ＠ｐ−ｃｓｃｆ１．ｉｍｓ．ｔｅｌｉａ．ｓｅ；ｌｒ；ｕｓｅｒ−ｉｎｄｅｘ＝３４６７９＞又は
Ｐａｔｈ：＜ｓｉｐ：ｕｓｅｒ＿３４６７９＿ｔｅｒｍ＠ｐ−ｃｓｃｆ１．ｉｍｓ．ｔｅｌｉａ．ｓｅ；ｌｒ＞
をＳ−ＣＳＣＦエンティティに提供する。
【００５６】
１つ目のＰａｔｈの例では、ｕｓｅｒ−ｉｎｄｅｘ＝３４６７９は、Ｐ−ＣＳＣＦエンティティがユーザプロファイルを格納する内部データ構造内の位置３４６７９に加入者のユーザプロファイルが格納されていることを示す。２つ目のＰａｔｈの例では、Ｐ−ＣＳＣＦエンティティがＳ−ＣＳＣＦアドレスのユーザ部分におけるユーザインデックスを含んでいる。Ｐ−ＣＳＣＦエンティティが終端側セッションのためのＳＩＰ  Ｉｎｖｉｔｅを受信する場合、Ｐ−ＣＳＣＦエンティティがＳＩＰ  Ｉｎｖｉｔｅを、ユーザプロファイルを含むためのその内部データ構造において位置３４６７９に直接関連付けることができる。Ｐ−ＣＳＣＦエンティティは、内部データ構造における位置３４６７９が実際に加入者のユーザプロファイルを含むことをさらに検証してもよい。
【００５７】
＜第５の実施形態：ＨＳＳオリエンテッド・ユーザインデックス＞
２つのＨＳＳ問い合わせが単一のＳＩＰセッション確立において行われると、ＨＳＳオリエンテッド・ユーザインデックスが使用されてもよい。ここで、ＨＳＳオリエンテッド・ユーザインデックスの使用は、登録に関連する一実施形態によって説明される。
【００５８】
加入者がＩＭＳに登録する場合、ＳＩＰレジスタ要求メッセージはＩ−ＣＳＣＦを通過する。Ｉ−ＣＳＣＦエンティティは、Ｓ−ＣＳＣＦエンティティ・アドレスを得るために、ＨＳＳ（Ｄｉａｍｅｔｅｒユーザ認証リクエスト（ＵＡＲ））に質問する。その時に加入者が登録されていないことを想定すると、ＨＳＳは（Ｄｉａｍｅｔｅｒユーザ認証応答（ＵＡＡ）において）Ｓ−ＣＳＣＦエンティティ機能を返す。Ｉ−ＣＳＣＦエンティティは返された機能に基づき、Ｓ−ＣＳＣＦエンティティを選択し、ＳＩＰレジスタを当該Ｓ−ＣＳＣＦエンティティへ転送する。Ｓ−ＣＳＣＦエンティティは、（Ｄｉａｍｅｔｅｒマルチメディア認証リクエスト（ＭＡＲ）において）認証を実行するために、又は、（Ｄｉａｍｅｔｅｒサーバ・アライメント・リクエスト（ＳＡＲ）において）ユーザ割り当てを実行するために、ＨＳＳを接続しなければならない。
【００５９】
応答側ノードとしてのＨＳＳは、Ｄｉａｍｅｔｅｒ認証応答（ＵＡＡ）においてユーザインデックスを含んでもよい。このユーザインデックスは、ユーザプロファイルを格納するためのＨＳＳのリポジトリにおいて内部データ構造における位置に関連してもよい。Ｉ−ＣＳＣＦエンティティは、パラメータとしてのこのユーザインデックスを、ＳＩＰレジスタ要求メッセージのＦｒｏｍヘッダに含まれるＳＩＰ  ＵＲＩか、Ｔｏヘッダに含まれるＳＩＰ  ＵＲＩの少なくとも一方に追加する。Ｆｒｏｍヘッダ及びＴｏヘッダのＳＩＰ  ＵＲＩは加入者を識別する。要求側ノードとしてのＳ−ＣＳＣＦエンティティは、Ｄｉａｍｅｔｅｒ  ＭＡＲ又はＤｉａｍｅｔｅｒ  ＳＡＲにおいて、ユーザインデックス・パラメータを含む、当該加入者のＳＩＰ  ＵＲＩを使用する。この方法で、ＨＳＳは、着信Ｄｉａｍｅｔｅｒ  ＭＡＲ又はＤｉａｍｅｔｅｒ  ＳＡＲを、ユーザプロファイルを含むためのその内部データ構造における位置に直接関連付けることができる。ＨＳＳは、その内部データ構造における当該位置が実際に加入者のユーザプロファイルを含むかをさらに検証してもよい。
【００６０】
加入者登録について上述したように、このメカニズムはまた、発信側の登録されていないＳＩＰセッション確立や終端側の登録されていないＳＩＰセッション確立に使用されてもよい。それらのケースにおいて、Ｓ−ＣＳＣＦへのユーザＵＲＩを通過するＩ−ＣＳＣＦとともに、２つのＨＳＳ問い合わせも存在する。
【００６１】
＜第６の実施形態：セントラル・ユーザインデックス＞
図３は、本発明に係る静的な加入者データ配信を示す図である。図３の例において、ＨＳＳは、００１２３４５６を、ユーザインデックスとして加入者に割り当てている。本実施形態において、先頭の数字（００）は、ＨＳＳを識別し、続く数字（１２３４５６）はＨＳＳ内のユーザを識別する。したがって、このユーザインデックスは、ＨＳＳ内のユーザプロファイルの位置を示してもよい。本実施形態において、ＳＩＰ−ＡＳ、Ｐ−ＣＳＣＦエンティティ又はＳ−ＣＳＣＦエンティティなどの他のノードはまた、それらのリポジトリに格納されたそれらの加入者レコードのインデックスを使用する。
【００６２】
このように、ＩＭＳ加入者がＩＭＳネットワークにおいてサービス提供される場合、本例の整数値におけるＨＳＳユーザインデックスは、（サービス提供中に）当該ユーザに割り当てられる。当該ＨＳＳユーザインデックスは、ＨＳＳによって提供され、登録中にＨＳＳからＳ−ＣＳＣＦエンティティへ送信されるＤｉａｍｅｔｅｒメッセージの１つにおいて、Ｓ−ＣＳＣＦエンティティに送信される。Ｓ−ＣＳＣＦエンティティは、当該ＨＳＳユーザインデックスを、内部加入者関連データ（ユーザプロファイル）に格納し、ＨＳＳユーザインデックスをＰ−ＣＳＣＦエンティティ（ＳＩＰ  ２００  Ｏｋにおいて）へ転送する。Ｐ−ＣＳＣＦエンティティは、他のユーザ関連データとともに、その内部データ・レコードにＨＳＳユーザインデックスを格納する。
【００６３】
Ｓ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティの少なくとも一方は、内部リポジトリの所定の位置に加入者関連データを格納してもよい。当該所定の位置は、ＨＳＳユーザインデックスが示すそれぞれＳ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティの少なくとも一方のリポジトリ内での加入者データの位置である。さらに、Ｓ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティの少なくとも一方がＨＳＳによって発行される範囲に適応するために、より多くのレコード（及び、ポイント）を割り当てなければならない可能性がある。また、Ｓ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティの少なくとも一方がＨＳＳユーザインデックスをメモリ位置（例えば、ポインタ）にマッピングするために内部テーブル、又は、Ｓ−ＣＳＣＦエンティティ及びＰ−ＣＳＣＦエンティティの少なくとも一方自身によって使用される同等のユーザインデックスを使用する可能性がある。
【００６４】
Ｓ−ＣＳＣＦエンティティは、’サードパーティ登録’手続きの一部として、１つ以上の開始プロトコルアプリケーションサーバ（ＳＩＰ−ＡＳ’ｓ）に対してＳＩＰレジスタを送信し、その結果、Ｓ−ＣＳＣＦエンティティはＳＩＰレジスタにもそれらのＳＩＰ−ＡＳ’ｓへのＨＳＳユーザインデックスを含む。ＳＩＰ−ＡＳはその内部の、加入者関連データレコード（ユーザプロファイル）にＨＳＳユーザインデックスを格納する。
【００６５】
図４は、本発明に係る発信側の呼確立を示す図である。図４に示すように、ＨＳＳユーザインデックスをＳＩＰ  Ｉｎｖｉｔｅへ追加するステップは、パラメータとして当該ＨＳＳユーザインデックスをＰ−ａｓｓｅｒｔｅｄ−ｉｄヘッダへ追加することによって行われてもよい。Ｓ−ＣＳＣＦエンティティがＳＩＰ  Ｉｎｖｉｔｅの処理を完了すると、ＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスは、さらなる機能を提供せず、したがって、Ｓ−ＣＳＣＦエンティティによってＳＩＰ  Ｉｎｖｉｔｅから取り除かれるであろう。
【００６６】
加入者が呼（ＳＩＰセッション）を確立する場合、Ｐ−ＣＳＣＦエンティティは、発呼加入者の識別子を決定する一般的な（従来の）手順を適用する。これは、Ｆｒｏｍヘッダを解析することによって、又は、ＳＩＰ  ＵＡ及びＰ−ＣＳＣＦエンティティ間のＩＰ  Ｓｅｃ関係によってでもよい。Ｐ−ＣＳＣＦエンティティは、Ｐ−ＣＳＣＦエンティティがＳ−ＣＳＣＦエンティティに転送するＳＩＰ  Ｉｎｖｉｔｅの上述のＨＳＳユーザインデックスを含む。Ｓ−ＣＳＣＦエンティティは、そのリポジトリからユーザプロファイルを得るために検索基準としてＨＳＳユーザインデックスを使用する。Ｓ−ＣＳＣＦエンティティが整数値に基づいてユーザプロファイルを得ると、ＳＩＰ  Ｉｎｖｉｔｅにおいて受信されたＰ−ａｓｓｅｒｔｅｄ−ｉｄヘッダがユーザプロファイルに含まれることをさらに検証してもよい。
【００６７】
Ｓ−ＣＳＣＦエンティティは、１つ以上のＳＩＰ−ＡＳを通じてＳＩＰ  Ｉｎｖｉｔｅを経路付けてもよい。Ｓ−ＣＳＣＦエンティティは、ＳＩＰ−ＡＳへ送信されるＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスを維持する。ＳＩＰ−ＡＳは、ユーザプロファイルを得るために、検索基準としてＨＳＳユーザインデックスを使用する。ＳＩＰ−ＡＳがＨＳＳユーザインデックスに基づきユーザプロファイルを得ると、ＳＩＰ  Ｉｎｖｉｔｅで受信されたＰＡＩがユーザプロファイルに含まれることをさらに検証してもよい。
【００６８】
ＳＩＰ−ＡＳによるユーザインデックスの使用はオプションである。ＳＩＰ−ＡＳがこのメカニズムをサポートしていなければ、ユーザインデックスを無視し、発呼加入者を決定するために、即ち、ＰＡＩ及び格納したユーザレコード間で一致する文字列を適用するために、一般的な方法が適用される。
【００６９】
図５は、本発明に係る終端側の呼確立を示す図である。ＨＳＳがＤｉａｍｅｔｅｒ位置情報応答（ＬＩＡ）（Ｄｉａｍｅｔｅｒ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ａｎｓｗｅｒ）メッセージにＨＳＳユーザインデックスを追加する場合、当該ＨＳＳユーザインデックスはＳｅｖｅｒ−Ｎａｍｅデータ・エレメントのＳ−ＣＳＣＦエンティティ・アドレスに追加されるパラメータに含まれてもよい。Ｓｅｒｖｅｒ−Ｎａｍｅデータ・エレメントは、Ｄｉａｍｅｔｅｒメッセージに含まれるパラメータであってもよい。
【００７０】
ＩＭＳネットワークのＩ−ＣＳＣＦエンティティが加入者のための呼（ＳＩＰセッション確立要求メッセージ）を受信する場合、Ｉ−ＣＳＣＦエンティティは、ＳＩＰ  Ｉｎｖｉｔｅが転送されるべきＳ−ＣＳＣＦエンティティのアドレスを得るために一般的な方法を適用する、即ち、Ｉ−ＣＳＣＦエンティティがＨＳＳに接続する。ＨＳＳは、Ｉ−ＣＳＣＦエンティティへの応答において、上述したＨＳＳユーザインデックスを含む。したがって、Ｉ−ＣＳＣＦエンティティは、Ｓ−ＣＳＣＦエンティティへのＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスを含む。Ｓ−ＣＳＣＦエンティティは、Ｓ−ＣＳＣＦエンティティリポジトリにおいてユーザプロファイルを得るために、検索基準としてＨＳＳユーザインデックスを使用する。Ｓ−ＣＳＣＦエンティティがＨＳＳユーザインデックスに基づいてユーザプロファイルを得ると、Ｓ−ＣＳＣＦエンティティは、ＳＩＰ  Ｉｎｖｉｔｅにおいて受信されたＲ−ＵＲＩがユーザプロファイルに含まれることをさらに検証してもよい。
【００７１】
Ｓ−ＣＳＣＦエンティティは、１つ以上のＳＩＰ−ＡＳを通じて、ＳＩＰ  Ｉｎｖｉｔｅを経路付けてもよい。Ｓ−ＣＳＣＦエンティティは、ＳＩＰ−ＡＳへ送信されるＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスを維持する。ＳＩＰ  ＡＳは、ＳＩＰ−ＡＳリポジトリからユーザプロファイルを得るために、検索基準としてＨＳＳユーザインデックスを使用する。ＳＩＰ−ＡＳがＨＳＳユーザインデックスに基づきユーザプロファイルを得ると、ＳＩＰ  Ｉｎｖｉｔｅに受信されたＲ−ＵＲＩがユーザプロファイルに含まれることをさらに検証してもよい。
【００７２】
ＳＩＰ−ＡＳによる整数の使用はオプションである。ＳＩＰ−ＡＳが当該メカニズムをサポートしていなければ、結果的に、ＨＳＳユーザインデックスを無視し、発呼加入者を決定する一般的な方法を適用する、即ち、Ｒ−ＵＲＩ及び格納されたユーザレコードの間で一致する文字列を適用する。
【００７３】
呼制御の終端が完了すると、Ｓ−ＣＳＣＦエンティティは、ＳＩＰ  ＩｎｖｉｔｅをＰ−ＣＳＣＦエンティティへ転送するであろう。Ｓ−ＣＳＣＦエンティティは、Ｐ−ＣＳＣＦエンティティへ送信されるＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスを維持する。Ｐ−ＣＳＣＦエンティティは、Ｐ−ＣＳＣＦエンティティのリポジトリにおけるユーザプロファイルを得るために、検索基準として、ＳＩＰ  ＩｎｖｉｔｅのＨＳＳユーザインデックスを使用する。Ｐ−ＣＳＣＦエンティティがＨＳＳユーザインデックスに基づいてユーザプロファイルを得ると、加入者の連絡先アドレスを含むＳＩＰ  Ｉｎｖｉｔｅにおいて受信したＲ−ＵＲＩがＨＳＳユーザインデックスとともに得られた加入者のユーザプロファイルの連絡先アドレスと一致することをさらに検証してもよい。
【００７４】
上述したように、本発明のいくつかの実施形態を特定するために図面を参照して本発明について説明した。しかしながら、広義の精神及び添付の請求項で定義した発明の範囲から離れることなく、様々な修正及び変形が可能であろう。
【００７５】
ＩＭＳ加入者が１つ以上のプライベート・ユーザ識別子（ＩＭＰＩ）を有し、１つ以上のパブリック・ユーザ識別子（ＩＭＰＵ）を有する可能性がある。複数のＩＭＰＵは”間接的な登録セット（ｉｍｐｌｉｃｉｔ ｒｅｇｉｓｔｒａｔｉｏｎ ｓｅｔ）”に組み合わされてもよい。
【００７６】
Ｓ−ＣＳＣＦエンティティが加入者のための情報（開始フィルタ基準：Ｉｎｉｔｉａｌ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ， ＩＦＣ）を格納する場合、当該情報がどのように格納されるか、及び、アクセスされるかの少なくとも一方でＨＳＳとＳ−ＣＳＣＦエンティティとの間の共通理解があってもよい。
・Ｓ−ＣＳＣＦエンティティが各登録ＩＭＰＵにおける１つのレコードを使用する場合、ＨＳＳはＩＭＰＵにつき１つのＨＳＳユーザインデックス（例えば、整数値）を割り当てることができる。
・Ｓ−ＣＳＣＦエンティティが登録された各”登録セット”（複数のＩＭＰＵを含む）ごとに、１つのレコードを使用する場合、ＨＳＳはセットごとに１つのＨＳＳユーザインデックスを割り当てることができる。ＨＳＳがＨＳＳユーザインデックスをＩ−ＣＳＣＦエンティティへ返す場合、ＨＳＳは、要求されたＲＥＱ−ＵＲＩに属するセットを確認し、当該セットにおける整数値を返すことができる。
【００７７】
本実施形態において、インターネット・プロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）通信ネットワークに関連する。本発明は、インターネット・プロトコル・ネットワークを介した他の音声などの通信ネットワークに基づく他のネットワークにおいても適用することができる。
【００７８】
しかしながら、他の修正、変形及び代替の実施形態も可能である。したがって、明細書、図面及び実施例は、制限する目的で記載したのではなく、説明のためのものである。
【００７９】
請求項において、括弧内に記載された参照記号は請求項限定するように解釈されるべきではない。用語「備える」は、請求項に記載したものから他の特徴又はステップの存在を排除しない。さらに、用語「ａ」及び「ａｎ」は「１つのみ」と解釈されるべきではなく、少なくとも１つの意味として使用されており、複数を排除するものではない。所定の量が相互に異なる請求項で記載された場合は、それらの量の組み合わせが利益に享受しないことを示しているわけではない。
【図１】
0005613229.tif 000002
【図２】
0005613229.tif 000003
【図３】
0005613229.tif 000004
【図４】
0005613229.tif 000005
【図５】
0005613229.tif 000006