JP4951676B2 - マルチメディア・ネットワークにおいてサービス要求を処理するための方法及び装置 - Google Patents

Description

本発明は、概して、マルチメディア・ネットワークにおけるサービス要求の効率的処理に関し、特に、エイリアス識別（ａｌｉａｓ−ｉｄｅｎｔｉｔｙ）を含むサービス要求に関する。

ＩＰマルチメディア・サブシステム（ＩＭＳ）は、パケット交換ネットワーク上で広範囲にわたる高度なインターネット・ベースのマルチメディア・サービス及びアプリケーションを使用可能にするための共通プラットフォームを作成するセッション開始プロトコル（ＳＩＰ）に基づくアーキテクチャである。

図１では、ユーザ機器をＩＭＳに登録するため、及びＩＭＳベースのサービスを要求するためのＩＭＳネットワークにおける従来の手順を示す。この図には基本ノードのみが提示されているが、本発明による影響を受けないいずれの中間ノードも省略されている。

機能の中で、サービス提供コール・セッション制御機能（Ｓ−ＣＳＣＦ／Ｓｅｒｖｉｎｇ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）ノードは、ＩＭＳへの登録済みのユーザ機器から受信された登録要求を処理するＳＩＰサーバ又はセッション制御ユニットである。登録済みのユーザ機器からＩＭＳベースのサービスに対する要求を受け取ったＳ−ＣＳＣＦノードは、要求されたサービスをさらに処理するために、そのサービス要求を特定のアプリケーション・サーバ（ＡＳ）に転送する責務を負う。

ホーム加入者サーバ（ＨＳＳ）は、ＩＭＳのすべての加入者関連及びサービス関連のデータのためのメイン・データ・ストレージである。ＨＳＳに格納されたメイン・データには、ＩＭＳに登録された各ユーザに関するユーザ・プロファイルが含まれる。ユーザ・プロファイルとは、永続的にＨＳＳに格納されるユーザ特有の情報の集合である。ユーザに関連付けられたユーザ・プロファイルは、そのユーザをＩＭＳに登録するための要求を受け取ると同時にＳ−ＣＳＣＦノードにダウンロードされる。サービス・プロファイルには、すべての公開ユーザ識別、すなわち、ＩＭＳにサービスを要求する際に使用可能なすべての識別が含まれる。公開ユーザ識別は、例えば、ｂｏｂ．ｈｏｍｅ＠ｘ．ｃｏｍなどのＳＩＰ ＵＲＩとするか、又は例えば、ｔｅｌ：＋４６ ８ １２３ ４５６ ６７などのｔｅｌ ＵＲＩとすることができる。サービス・プロファイルは、サービス要求が特定のアプリケーション・サーバへルーティングされることになる際に従う条件を定義するトリガ規則も含む。サービス要求に挿入されたユーザ識別に関連付けられたトリガ規則をチェックすることによって、Ｓ−ＣＳＣＦノードからサービス要求がルーティングされることになるアプリケーション・サーバを決定することができる。

アプリケーション・サーバでは、アプリケーション・サーバに予め格納され、かつ、サービス要求から取り出されたユーザ識別に関連付けられたユーザ・データに、サービス要求がリンク付けされる必要がある。このリンク付けがどのように達成されるかは、本発明の範囲外である。しかし、サービス要求を適切なユーザ・データに効率良くリンク付けするための周知の方法は、ハッシュ関数を使用することであり、ここでは、サービス要求で受信されたユーザ識別をハッシュ・キーとして使用することができる。

必要であれば、ユーザは、１つ又は複数のアプリケーション・サーバに格納された同じユーザ・プロファイル及び同じデータにリンク付けされることになる複数の異なるユーザ識別を定義することが可能であり、すなわち、異なるユーザ識別を有する同一のサービス要求は同じ動作をトリガすることができる。こうした代替のユーザ識別がエイリアス（ａｌｉａｓｅｓ）と呼ばれる。エイリアスは、他の公開ユーザ識別に関連付けられたデータへのアクセスを制限するために使用することも可能である。

図１の第１のステップ１：１で、提供システム１００は、１つ又は複数のエイリアス識別を含むことが可能な既知のユーザ識別を含むＨＳＳ１０１内の特定のユーザ識別に関連付けられたサービスを実行するために必要なすべてのデータを作成する。他のステップ１：２で、提供システムは、関連付けられたアプリケーション・サーバ１０２で必要なユーザ識別を含む対応データも作成する。このデータは、第１のユーザ識別も含み、さらにアプリケーション・サーバの機能に応じて既知のエイリアス識別も含む。

他のステップ１：３で、ＩＭＳネットワークによって提供されるマルチメディア・サービスへのアクセスを希望するユーザは、ＩＭＳネットワークにＳＩＰ登録メッセージを送信することによって、ユーザ機器１０３を登録する。ＳＩＰ登録メッセージは、ユーザに割り振られているＳ−ＣＳＣＦノード１０４に送信され、これによって評価される。Ｓ−ＣＳＣＦノードは、本質的にはＳＩＰサーバであるが、レジストラ（ｒｅｇｉｓｔｒａｒ）としても動作し、これは、登録済みのユーザ機器の場所と、ユーザ機器のユーザに関連付けられたユーザ識別との間のバインディング（ｂｉｎｄｉｎｇ）を維持することを意味する。Ｓ−ＣＳＣＦノードが登録要求を受け取った場合、ステップ１：４で、ユーザに関する更新済みのユーザ・プロファイルが、ホーム加入者サーバ（ＨＳＳ）からＳ−ＣＳＣＦノードにダウンロードされる。ユーザに関連付けられたユーザ・プロファイルは、認証目的にのみ使用される非公開ユーザ識別と、それぞれが１つ又は複数の公開ユーザ識別に適用可能な１つ又は複数のサービス・プロファイルとを含む。

ユーザ機器が登録された後、ステップ１：５で、所望のサービスに対する要求１０５がＳ−ＣＳＣＦノードに送信される。この場合、ユーザは、サービスを要求する際にエイリアス識別１を使用している。ステップ１：６でサービス要求内のユーザ識別を問い合わせることによって、Ｓ−ＣＳＣＦノードは、それぞれのユーザ識別に関連付けられたサービス・プロファイル内のどのトリガ規則が満たされているか、及び要求されたサービスをさらに処理するためにどのアプリケーション・サーバにサービス要求をルーティングするかを決定する。

他のステップ１：７で、エイリアス識別１を含むサービス要求１０５が、それぞれのトリガ規則によってポイントされたアプリケーション・サーバにルーティングされる。

最終のステップ１：８で、サービス要求から取り出されたユーザ識別を、それぞれのユーザ識別に関連付けられたデータにリンク付けするために、適切なデータ・モデルが使用される。このようなリンク付け手順は、複雑である場合、及び多くのリソースを消費する場合の両方である可能性がある。

図２は、ユーザに関連付けられたエイリアス識別を含む異なるユーザ識別の例を示す。第１のユーザ識別、すなわちｂｏｂ．ｈｏｍｅ＠ｘ．ｃｏｍは、第１のユーザ識別として定義され、例えば、それぞれのユーザに関連付けられたユーザ・データへのフル・アクセスを与えることができるが、追加のユーザ識別、すなわちｂｏｂ．ｗｏｒｋ＠ｘ．ｃｏｍ及びｂｏｂ．ｓｏｃｃｅｒ＠ｘ．ｃｏｍも、それぞれのユーザ識別又はエイリアス識別に対して設定されたトリガ規則に従って、それぞれのユーザ・データへのフル又は制限付きアクセスを与えることができる。

既存の解決方法の１つの問題は、アプリケーション・サーバがサービス要求内のエイリアス識別を理解することができなければならない場合、アプリケーション・サーバの提供が複雑になることである。

他の問題は、アプリケーション・サーバが、着信エイリアスを解釈及び理解することができなければならない場合、アプリケーション・サーバのデータ・モデル並びに要求のルーティングが複雑になることである。

さらに他の問題は、ＩＭＳネットワーク内のすべてのノードが同様のデータ・モデルを共有する必要がある場合があることである。これにより、ＩＭＳネットワークのアップグレードが必要な場合さらに複雑になる。

他の問題は、エイリアス識別の処理に関連するアプリケーション・サーバ内で実行されることになる特別なデータベース要求及びさらなる論理に対する要件である。

本発明の目的は、上記で概説した問題のうちの少なくとも一部に対処することである。より詳細には、本発明の目的は、サービス要求、特に、セッション制御機能内及びマルチメディア・ネットワークのアプリケーション・サーバ内にエイリアス識別を含むサービス要求の処理を簡略化できる解決方法を提供することである。

これら及び他の目的は、添付の特許請求の範囲による方法及び装置をそれぞれ提供することによって入手可能である。一態様によれば、マルチメディア・ネットワーク内のセッション制御ユニット内でサービス要求を処理するための方法が提供される。

本発明の方法では、ユーザ識別を含むサービス要求がユーザ機器から送信され、コール・セッション制御機能で受信される。コール・セッション制御機能は、サービス提供コール・セッション制御機能、ＸＭＬ構成アクセス・プロトコル集約プロキシとすることができる。サービス要求のユーザ識別に関連付けられたサービス・プロファイルが、上記サービス要求の送信先であるアプリケーション・サーバを見つけるためにチェックされる。この方法は、要求がアプリケーション・サーバにルーティングされる前に、上記サービス要求が１次ユーザ識別を含むことを確保（保証）するステップも開示する。

アプリケーション・サーバでは、１次ユーザ識別が、上記要求されたサービスを実行するために必要な格納済みデータを見つけるために使用される。１次ユーザ識別は、サービス要求がすでに１次ユーザ識別を含んでいるか否かを判別した後に、サービス要求に挿入することができる。別の方法としては、１次ユーザ識別は、いかなる判別又はチェックも実行することなく挿入することができる。

判別ステップでは、１次ユーザ識別を、新しい１次ユーザ識別ヘッダ、又はサービス・プロファイルの第１のユーザ識別位置から取り出すことができる。サービス要求のユーザ識別は、リクエストＵＲＩ（Ｒｅｑｕｅｓｔ−ＵＲＩ）から、又はＰ−アサーテッド識別（Ｐ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙ）から取り出すことができる。

１次ユーザ識別は、新しい１次ユーザ識別ヘッダへ、又はサービス・プロファイルのルート・ヘッダへ挿入することができる。サービス・プロファイルへの１次ユーザ識別の挿入は、単にサービス要求内のエイリアス識別を１次ユーザ識別に置き換えることによっても実行可能である。さらに、アプリケーション・サーバ内では、１次ユーザ識別を含むサービス要求は、要求されたサービスを実行するために必要なデータへの即時アクセスを提供することになる。

他の態様によれば、セッション制御ユニット内のサービス要求を処理するための装置を提供する。本発明の装置は、ユーザ識別を含むサービス要求を、ユーザ機器から受信するための手段を備える。この装置は、サービス要求のルーティング先であるアプリケーション・サーバを見つけるために、ユーザ識別に関連付けられたサービス・プロファイルをチェックするための手段をさらに備える。サービス要求がルーティング手段を介してアプリケーション・サーバにルーティングされる前に、サービス要求が１次ユーザ識別を含むことを確保するための確保手段（ｅｎｓｕｒｉｎｇ ｍｅａｎｓ）が構成される。

他の態様によれば、セッション制御ユニットから受信したサービス要求によって示されるサービスを実行するために、アプリケーション・サーバが提供される。アプリケーション・サーバは、１次ユーザ識別を読み取ることによって、要求されたサービスを実行するのに必要な格納済みデータへの即時アクセスを提供するように構成された手段を備える。

さらに他の態様によれば、サービス・プロファイルをセッション制御ユニットに転送するために、ホーム加入者サーバが提供される。ホーム加入者サーバは、サービス・プロファイル内の第１のユーザ識別を１次ユーザ識別として定義するための手段を備える。別の方法としては、それぞれの１次ユーザ識別が、サービス・プロファイル内の新しい１次ユーザ識別ヘッダに挿入される。

次に、例示的な実施形態を用いて、また添付の図面を参照しながら、本発明についてより詳細に説明する。

従来技術による、ユーザ機器をＩＭＳに登録するため、及びＩＭＳベースのサービスを要求するための従来の手順を示す概略ブロック図である。 ユーザに関連付けることが可能なＩＭＳに登録されたユーザ識別の例を示す表である。 一実施形態による、ＩＭＳベースのサービスに対するサービス要求を処理するための手順を示す概略ブロック図である。 図３を参照しながら説明したノードの基本機能を示す概略高レベル・ブロック図である。 図３を参照しながら説明した実施形態による、サービス要求を処理するための基本手順を示すフローチャートである。 図５のステップ５０２に記載された手順の代替実施形態を示すフローチャートである。

簡単に説明すると、本発明は、ＩＭＳネットワークのＨＳＳ及びアプリケーション・サーバのデータ・モデル及び提供が簡略化され、特にメモリ要件及び待ち時間を考慮すると、サービス要求の処理に対する性能が向上した解決方法を提供する。

図３は、ＩＭＳにおけるサービス要求の処理の第１の実施形態を示す。第１のステップ３：１で、提供システム３００は、１次ユーザ識別として定義されたユーザ識別及び任意の既知のエイリアス識別を含むすべての必要なデータを作成し、このデータをＨＳＳ３０１に転送する。提供手順はユーザによって開始され、１次ユーザ識別と示されたエイリアス識別をユーザ識別に割り振るように、提供システムに接続されたサービス・プロバイダ（図示せず）に要求する。１次ユーザ識別は、これに接続された特定のサービス・セットを伴うユーザ識別であり、ユーザがそれぞれのサービス・セットに加入している限り存在することになる。１次ユーザ識別が除去された場合、それぞれのサービス・セットも、関連付けられたすべてのエイリアス識別と共に除去されることになる。

一実施形態では、サービス・プロファイルに格納された第１のユーザ識別は、常に１次ユーザ識別として定義される。この実施形態の実施では、ＨＳＳにおけるいかなる修正も必要としない。さらに、１次ユーザ識別は既存のデータ・フィールド内に配置されるため、この実施形態は、Ｓ−ＣＳＣＦ内のわずかな変更のみを必要とする。

代替実施形態では、１次ユーザ識別専用の新しい１次ユーザ識別フィールドが、サービス・プロファイル内に作成される。しかし、新しいフィールドをサービス・プロファイルに導入するためには、提供中に新しいフィールドへの１次ユーザ識別の挿入を処理できなければならないＨＳＳにおける変更と、サービス・プロファイルに格納された他のユーザ識別から１次ユーザ識別を識別できなければならないＳ−ＣＳＣＦノード３０２における変更とが必要である。

本発明は、Ｓ−ＣＳＣＦにおけるサービス要求の処理に限定されるものではなく、他のセッション制御ユニットでも実施可能であることを理解されたい。代替シナリオの１つは、ＸＭＬフォーマットで格納されたデータの処理を開示することができる。上記シナリオは、ＸＣＡＰ集約プロキシ（ＸＣＡＰ ＡＰ）での要求を処理するためにＸＭＬ構成アクセスプロトコル（ＸＣＡＰ）を使用することによって、及びＳ−ＣＳＣＦに関して説明した実施形態のうちのいずれかに従ってＸＣＡＰ ＡＰを構成することによって処理することができる。

他のステップ３：２でも、提供システムは、それぞれのユーザ識別に関連付けられたデータを、それぞれのユーザ識別に関連付けられたサービスの実行専用のそれぞれのアプリケーション・サーバ３０３に転送する。提供システムは、オプションとしてそれぞれのアプリケーション・サーバに転送されるデータ内にすべての使用可能なエイリアス識別を含むことができる。しかし、本発明を実行する目的で、提供プロセス中にエイリアス識別をアプリケーション・サーバに転送する必要はない。

ステップ３：３で、ユーザＡは、それぞれのユーザ機器からレジストラとして動作するＳ−ＣＳＣＦノードへ登録要求（ＳＩＰ ＲＥＧＩＳＴＥＲ）を転送することによって、ユーザ機器３０４をＩＭＳに登録する。登録要求は、１次ユーザ識別とすることが可能なユーザ識別、例えば、ｂｏｂ．ｈｏｍｅ＠ｘ．ｃｏｍ、又は代替ユーザ識別を定義することが可能なエイリアス識別、例えば、ｂｏｂ．ｓｏｃｃｅｒ＠ｘ．ｃｏｍを含む。

登録要求に応答して、Ｓ−ＣＳＣＦノードは、ユーザＡに関する更新済みのサービス・プロファイルをＨＳＳに要求し、ここから取り出す。これはステップ３：４に示されている。サービス・プロファイルは、１次ユーザ識別と、もしもあれば、ユーザＡに提供されたすべてのエイリアス識別とを含む。

次のステップで、ユーザ機器をＩＭＳに登録したユーザＡは、特定のユーザ識別に関連付けられたサービスへの加入を希望する。そこで、ステップ３：５で、このケースではエイリアス識別、すなわちエイリアス識別１を含むサービス要求３０５、例えば、ＳＩＰ ＳＵＢＳＣＲＩＢＥが、Ｓ−ＣＳＣＦノードに転送される。Ｓ−ＣＳＣＦノードがどのアプリケーション・サーバにサービス要求を転送するかを決定するために、ステップ３：６で、サービス要求のユーザ識別に関連付けられたサービス・プロファイルがチェックされる。サービス・プロファイルのトリガ規則は、それぞれのアプリケーション・サーバが、サービス要求のルーティング用、及び要求されたサービスの実行用に選択される際に従う条件を指定する。

サービス要求がそれぞれのアプリケーション・サーバにルーティングされる前に、サービス要求が１次ユーザ識別を含むことを確保する目的を有する新規なステップ３：７が実行される。次に、このステップを実行するための幾つかの代替実施形態が提示される。

第１の実施形態では、１次ユーザ識別は常にそれぞれのサービス要求に挿入される。この実施形態によれば、サービス要求は、Ｓ−ＣＳＣＦへ到達した時点で、１次ユーザ識別又はエイリアス識別を含むか否かをチェックする必要はない。サービス要求でどちらのユーザ識別が使用されているかにかかわらず、１次ユーザ識別は常にサービス要求に挿入されることになる。

代替実施形態では、Ｓ−ＣＳＣＦノードは、常にサービス要求のエイリアス識別をそれぞれの１次ユーザ識別に変換し、エイリアス識別をサービス要求内の１次ユーザ識別に置き換えることができる。エイリアス識別がサービス要求に含まれることがないため、この実施形態は、それぞれのアプリケーション・サーバがそれぞれのサービス要求の実行にエイリアス識別を必要としない場合にのみ、代替実施形態とすることができる。

さらに他の実施形態では、Ｓ−ＣＳＣＦは、サービス要求内の特定フィールド又はヘッダのコンテンツを比較する。それぞれのフィールド又はヘッダのコンテンツをそれぞれのサービス・プロファイル内の１次ユーザ識別と比較することにより、上記１次ユーザ識別をサービス要求のヘッダ内へ実施しなければならないか否かが決定される。１次ユーザ識別がサービス要求内にすでに存在することがわかった場合、サービス要求は未変更のままとすることができ、それぞれのアプリケーション・サーバにルーティングすることができる。比較手順においてチェックのためにどのヘッダを選択するかは、発信のケースであるか終端のケースであるかに応じて異なる場合がある。終端のケースでは、ＳＩＰ ＵＲＩとすることが可能なＲｅｑｕｅｓｔ−ＵＲＩ、セキュアＳＩＰ（ＳＩＰＳ）ＵＲＩ、又はＴＥＬ ＵＲＩをチェックすることが可能であり、発信のケースでは、Ｐ−Ａｓｓｅｒｔｅｄ識別ヘッダをチェックすることができる。

１次ユーザ識別は、サービス要求内の新しいヘッダに挿入することができる。代替実施形態では、この目的で既存のルート・ヘッダを使用することができる。これは、以下のように示すことができる。
ＳＩＰ：ｓｉｐａｓ１＠ｘ．ｃｏｍ，ｓｅｓｓｉｏｎｃａｓｅ＝ｏｒｉｇｉｎａｔｉｎｇ；
ｐｒｉｍａｒｙｕｓｅｒｉｄ＝ｓｉｐ：ｂｏｂ．ｈｏｍｅ＠ｘ．ｃｏｍ
ここで、ｓｉｐａｓ１＠ｘ．ｃｏｍは、サービスを実行するべきであるアプリケーション・サーバのｓｉｐアドレスであり、ｂｏｂ．ｈｏｍｅ＠ｘ．ｃｏｍは、１次ユーザ識別である。この例で、ｓｅｓｓｉｏｎｃａｓｅは発信セッションとして定義され、これが、どのアプリケーション・サーバ宛にＳ−ＣＳＣＦがサービス要求をルーティングするべきであるかに関する情報を保持するＰ−Ａｓｓｅｒｔｅｄ識別であることを示す。この実施形態を実施することによって、着信サービス要求をルーティング先のアプリケーション・サーバに問い合わせる場合、１次ユーザ識別が現在のシステムで既にチェックされた既存のヘッダ内に常時含まれるため、Ｓ−ＣＳＣＦノード内で特定の対策を講じる必要がない。

ステップ３：８で、エイリアス識別、すなわちエイリアス識別１を含み、またここで、エイリアス識別に関連付けられた１次ユーザ識別、すなわち１次ユーザ識別１を用いて完了した修正済みのサービス要求３０６が、要求されたサービスを実行するために、それぞれのアプリケーション・サーバにルーティングされる。

最終ステップ３：９は、アプリケーション・サーバ内で実行される内部サービス実行プロセスを示す。このステップでは、ユーザ識別、すなわち１次ユーザ識別が識別され、サービス要求を、１次ユーザ識別、並びにサービス要求のエイリアス識別に関連付けられたデータにリンク付けするために使用される。１次ユーザ識別を使用することによって、アプリケーション・サーバ内でのサービス要求の処理が改善され、簡略化されることになる。最も重要なことは、提案された１次ユーザ識別を使用することによって、それぞれのデータへの即時アクセスが達成されるため、着信サービス要求内でのエイリアス識別の解釈が必要なくなることである。

要求されたサービスの実行プロセスに複数のアプリケーション・サーバが関与可能であることに留意されたい。この場合、サービス要求は、１次ユーザ識別、及び使用される場合は、サービス要求内のエイリアス識別を介して識別されたユーザ・データに従って、これらのアプリケーション・サーバ間でルーティングすることができる。

本発明のハイレベル・ブロック図が、図４に示される。この図は、図示されていない提供システムから特定のユーザ識別に関連付けられたユーザ・データを受信可能な受信手段４０１を備えたＨＳＳ４００を示す。次に、ユーザ・データは処理手段４０２内で処理され、ここで、それぞれのユーザ識別に関連付けられたサービス・プロファイルは、記憶手段４０３内で更新され格納されることになる。それぞれのサービス・プロファイルの更新済みバージョンのダウンロードの要求を受信すると、送信手段及び受信手段を備える通信手段４０４は、サービス・プロファイルをＳ−ＣＳＣＦ４０５にダウンロードする。Ｓ−ＣＳＣＦでは、受信手段及び送信手段を備える通信手段４０６が、サービス・プロファイルを受信し、これを記憶手段４０７に格納する。サービス要求は、好ましいユーザ識別を使用するユーザによって、図示されていないユーザ機器で起動することができ、ここでサービス要求は、ユーザ機器専用のＳ−ＣＳＣＦに送信され、Ｓ−ＣＳＣＦの通信手段で受信される。サービス要求は、チェック手段４０８に送信され、ここで、サービス要求のルーティング先であるＡＳを見つけるために、サービス要求のユーザ識別に関連付けられたサービス・プロファイルのトリガ規則がチェックされる。サービス要求は、それぞれのＡＳにルーティングされる前に確保手段４０９に送信される。確保手段では、サービス要求のユーザ識別に関連付けられた１次ユーザ識別がサービス要求に含まれることを確保するためのプロセスが開始される。確保手段のプロセスを実行する幾つかの代替方法については、図３のステップ３：７を参照しながら上述した。確保手段は、いずれの比較手順も実行せずに、１次ユーザ識別を挿入するための手段、及び／又は指定されたフィールド又はヘッダと受信したサービス要求のユーザ識別とを比較するための手段を備えることができる。別の方法としては、確保手段は、この目的専用の新しいヘッダ・フィールド又は既存のヘッダ・フィールドに１次ユーザ識別を挿入するように構成された手段を備えることができる。次に、１次ユーザ識別を用いて完了したサービス要求を、ルーティング手段４１０を介してそれぞれのＡＳにルーティングすることができる。ＡＳ４１１では、サービス要求が受信手段４１２によって受信され、サービス要求を関係データにリンク付けするため、及び要求されたサービスを処理するために処理手段４１３へと転送される。

図５は、本発明の基本原理に従ってサービス要求を処理するための一般的なステップを示すフローチャートである。第１のステップ５００では、ユーザ機器から送信されたサービス要求が、例えば、Ｓ−ＣＳＣＦなどのセッション制御ユニット内で受信される。次のステップ５０１では、サービス要求のユーザ識別に関連付けられたサービス・プロファイルに対してチェックが実行される。このチェックの結果として、どのＡＳにサービス要求がルーティングされることになるかが決定される。次のステップ５０２では、１次ユーザ識別を処理するための手順により、ステップ５０３でそれぞれのアプリケーション・サーバにルーティングされる前に、サービス要求がそれぞれの１次ユーザ識別を含むことが確保される。１次ユーザ識別を処理するための一実施形態は、ユーザ識別内のオリジナルのコンテンツのいかなる評価も必要なしに、受信されたサービス要求に１次ユーザ識別を常に挿入するものとすることができる。１次ユーザ識別の処理の代替実施形態については、図６を参照しながら以下で説明する。最終ステップ５０４では、要求されたサービスが、サービス要求がルーティングされたアプリケーション・サーバ内で実行される。アプリケーション・サーバ内で行われるこの最終実行ステップでは、１次ユーザ識別が、要求されたサービスを実行するために必要なデータへの即時アクセスを提供する。

最後に、図５のステップ５０３を参照しながら上述した１次ユーザ識別を処理するための代替実施形態について、図６のフローチャートを参照しながら説明する。

図６では、セッション制御ユニットに到達した時点で、受信されたサービス要求が、対応するサービス・プロファイルから識別された１次ユーザ識別を含むか否かが判別される。

受信されたサービス要求のユーザ識別のチェック、並びに１次ユーザ識別のサービス要求への挿入は、図３のステップ３：７を参照しながら上述した幾つかの代替方法で実施することができる。

上記端的なルーティング手順を導入することによって、データ・モデル、並びにアプリケーション・サーバの内部論理を簡略化することが可能である一方で、アプリケーション・サーバの性能は、現在使用可能なシステムに比べて向上させることができる。

以上、特定の例示的実施形態を参照しながら本発明について説明してきたが、本発明は、開示された例示的実施形態に限定されないことを理解されたい。説明は、全体として発明の概念を例示することのみを意図するものであり、添付の特許請求の範囲によって定義される本発明の範囲を制限するものと解釈すべきではない。特許請求の範囲は、すべてのこのような修正並びに等価の構造及び機能を包含するように最も広義に解釈すべきである。

Claims (32)

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. 前記サービス・プロファイル内の第１のユーザ識別を前記１次ユーザ識別として定義し、または前記１次ユーザ識別を前記サービス・プロファイル内の新しい１次ユーザ識別ヘッダに挿入するように構成された手段を備える請求項１６〜２９のいずれか１項に記載の装置に、サービス・プロファイルを転送するためのホーム加入者サーバ（ＨＳＳ）。

Images