(57)【要約】【課題】  ルートを記録しないことが適当であるとき及びルートの記録が効果的であるときを知るための能力を、アクセスされているサービスの形式に基づいてプロキシーサーバーに与える上で、一般的に問題が生じる。本発明は、この問題の１つ以上に対処する。【解決手段】  サブスクリプションサービスを提供する方法であって、サブスクリプションをアクチベートするためにサブスクリプションダイアログを確立し、前記サブスクリプションの確立時に前記サブスクリプションダイアログを終了し、そして加入者への通知を確立する段階を含む方法において、更に、加入者の位置を決定し、その位置が決定された加入者に通知するための通知ダイアログを確立し、そしてその通知の完了時に前記通知ダイアログを終了するというステップを備えた方法が開示される。
2006514816.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク要素を構成する方法において、
ルート記録命令を受け取るステップと、
サブスクリプション要求を受け取るステップと、
前記ルート記録命令に基づいて前記サブスクリプション要求のルートを記録するステップと、
を備えた方法。
【請求項２】
前記ルート記録命令をフェッチする、請求項１に記載の方法。
【請求項３】
前記ルート記録命令をフィルタ基準の一部分として受信する、請求項１又は２に記載の方法。
【請求項４】
前記ルート記録命令をシステムフィルタ基準の一部分として受信する、請求項３に記載の方法。
【請求項５】
前記システムフィルタ基準は、全ての加入者に対して構成される、請求項４に記載の方法。
【請求項６】
前記システムフィルタ基準は、前記ネットワーク要素において予め構成される、請求項４又は５に記載の方法。
【請求項７】
前記システムフィルタ基準は、更に別のネットワーク要素から前記ネットワーク要素へロードされる、請求項４又は５に記載の方法。
【請求項８】
前記更に別のネットワーク要素は、ＨＳＳ、Ｓ−ＣＳＣＦ又はデータベースの１つを含む、請求項７に記載の方法。
【請求項９】
前記フィルタ基準は、更に、加入者特有のフィルタ基準を含む、請求項３から７のいずれかに記載の方法。
【請求項１０】
前記加入者特有のフィルタ基準が前記システム特有のフィルタ基準に一致する場合には、前記システム特有のフィルタ基準と前記加入者特有のフィルタ基準の両方を組み合わせて適応する、請求項９、及び請求項２４から２８のいずれかに記載の方法。
【請求項１１】
前記システム特有のフィルタ基準のデータは、前記加入者特有のフィルタ基準のデータをオーバーライドする、請求項１０に記載の方法。
【請求項１２】
前記加入者特有のフィルタ基準のデータは、前記システム特有のフィルタ基準のデータをオーバーライドする、請求項１０に記載の方法。
【請求項１３】
前記フィルタ基準はサービス特有のものである、請求項３から１２のいずれかに記載の方法。
【請求項１４】
前記サービスはプレゼンスサービスである、請求項１３に記載の方法。
【請求項１５】
前記ルート記録は、前記サブスクリプションに関連したサービスプロフィールの一部分として受信される、請求項４から１４のいずれかに記載の方法。
【請求項１６】
前記サブスクリプション要求は、ＳＩＰセッションのメッセージである、請求項１から１５のいずれかに記載の方法。
【請求項１７】
前記ネットワーク要素は、プロキシーサーバーであるか、或いはサービングコール状態制御ファンクション又はサービングコールセッション制御ファンクションを与えるサーバーである、請求項１から１６のいずれかに記載の方法。
【請求項１８】
サービスに対するルート記録命令を生成することを含む、サブスクリプションサービスを提供する方法。
【請求項１９】
サブスクリプションサービスのメッセージに対するヘッダーであって、ネットワーク要素の特性を制御するためのルート記録命令を含むヘッダー。
【請求項２０】
サブスクリプションサービスを提供する方法において、
サブスクリプションをアクチベートするためにサブスクリプションダイアログを確立するステップと、
前記サブスクリプションダイアログにフィルタ基準を与えるステップと、
を備え、前記フィルタ基準は、ネットワーク要素においてサブスクリプションルートを選択的に記録するためにネットワーク要素に対する命令を含むように適応された方法。
【請求項２１】
前記ネットワーク要素は、サブスクリプションサービスを提供するサーバーに関連したサービングコール状態又はセッション制御ファンクションである、請求項２０に記載の方法。
【請求項２２】
前記フィルタ基準は、加入者フィルタ基準であり、前記方法は、更に、前記ネットワーク要素にシステムフィルタ基準を与えることを含み、前記システムフィルタ基準が前記加入者フィルタ基準に一致する場合に、両フィルタ基準を組み合わせて適用する、請求項２０又は２１に記載の方法。
【請求項２３】
前記システム特有のフィルタ基準のデータは、前記加入者特有のフィルタ基準のデータをオーバーライドする、請求項２２に記載の方法。
【請求項２４】
前記加入者特有のフィルタ基準のデータは、前記システム特有のフィルタ基準のデータをオーバーライドする、請求項２２に記載の方法。
【請求項２５】
サブスクリプションサービスを提供するためのネットワーク要素において、該要素は、ルート記録命令を受信するように適応され、前記ルート記録命令に応答して、前記サブスクリプションのメッセージに関連した通信セッションのルートを選択的に記録するようにされたネットワーク要素。
【請求項２６】
前記ルート記録命令は、フィルタ基準において与えられる、請求項２５に記載のネットワーク要素。
【請求項２７】
前記フィルタ基準は、システムフィルタ基準である、請求項２６に記載のネットワーク要素。
【請求項２８】
前記システムフィルタ基準は、ネットワークエンティティ及び／又はデータベースから受信される、請求項２７に記載のネットワーク要素。
【請求項２９】
前記システムフィルタ基準は前記ネットワーク要素において構成される、請求項２７に記載のネットワーク要素。
【請求項３０】
前記システムフィルタ基準は全ての加入者メッセージに適用される、請求項２７に記載のネットワーク要素。
【請求項３１】
前記ネットワーク要素は、更に、加入者フィルタ基準も受信する、請求項２５から３０のいずれかに記載のネットワーク要素。
【請求項３２】
前記加入者フィルタ基準が前記システムフィルタ基準に一致する場合には、両フィルタ基準を組み合わせて適用する、請求項２５に記載のネットワーク要素。
【請求項３３】
前記システム特有のフィルタ基準のデータは、前記加入者特有のフィルタ基準のデータをオーバーライドする、請求項３２に記載のネットワーク要素。
【請求項３４】
前記加入者特有のフィルタ基準のデータは、前記システム特有のフィルタ基準のデータをオーバーライドする、請求項３２に記載のネットワーク要素。
【請求項３５】
前記ネットワーク要素は、サービングコール状態又はセッション制御ファンクションを含む、請求項２５から３４のいずれかに記載のネットワーク要素。
【請求項３６】
前記ルート記録命令は、ホーム加入者サーバーから受信される、請求項２５から３５のいずれかに記載のネットワーク要素。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、例えばプレゼンスサービスのようなサブスクリプションサービスの分野に係り、より詳細には、セッション開始プロトコルダイアログを使用してサブスクリプションサービスをサポートすることに係るが、これに限定されない。
【背景技術】
【０００２】
通常、３ＧＰＰの全ＩＰアーキテクチャーにおいては、ユーザは、サブスクリプションサービスを申し込むことができる。サブスクリプションサービスは、通常、サブスクリプションメッセージを使用して開始される。好ましいサブスクリプションメッセージは、しばしば、ＳＩＰ（セッション開始プロトコル）メッセージを使用する。サブスクリプション事象を検出すると、サブスクリプションサーバーが、通常、一般的に通知メッセージを使用して、その事象を加入者に通知する。既知のシステムでは、サブスクリプション及び／又は通知メッセージは、一般に、接続処理サーバー（ＣＰＳ）として構成されたプロキシーサーバーにより容易にされる。サブスクリプションは、通常、ＣＰＳを通してＳＩＰダイアログを確立し、そしてＣＰＳは、通常、そのダイアログを維持し、通常、全ての通知に対して使用される。このようにして、ＣＰＳは、通常、サブスクリプションのルートを効果的に記録する。
【０００３】
多くの実際的な場合には、ＣＰＳが大量のサブスクリプションをサポートすることができ、そして通知を容易にするために大量のサブスクリプションに関連した非常に多数のルートを記録する通常の必要性が、ＣＰＳのリソースに著しい影響を及ぼすことがある。更に、記録されたルートに関連してＣＰＳに記憶されているダイアログが、一般に、非常に長期間にわたり未使用となる。それ故、ＣＰＳの容量が、通常、インアクティブなダイアログによって使用される。
【０００４】
３ＧＰＰ  ＩＭＳ  リリース６は、プレゼンスサービスを導入する。３ＧＰＰ  ＴＳ  ２３．２４１  ６．１．０は、プレゼンスサービスに対してサブスクリプションのダイアログをルート記録するために、プレゼンティティのサービングコール状態又はセッション制御ファンクション（Ｓ‐ＣＳＣＦ）が少なくとも通常は要求されないことを規定している。サブスクリプションの「ルート記録(record-route)」は、通常、ダイアログに対してプロキシーサーバーとして働いて、サブスクリプションメッセージのルートを記録するＳ‐ＣＳＣＦを効果的に含む。より詳細には、これは、ダイアログの詳細を記憶し、換言すれば、サブスクリプションが設定されたときにダイアログを維持するプロキシーサーバーを一般に含む。「ルート記録」を維持するプロキシーサーバーに伴う通常の欠点は、それが、通常、プロキシーサーバーの限定されたリソースを使用することである。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ルートを記録しないことが適当であるとき及びルートの記録が効果的であるときを知るための能力を、アクセスされているサービスの形式に基づいてプロキシーサーバーに与える上で、一般的に問題が生じる。
【０００６】
それ故、本発明の実施形態の目的は、上述した問題の１つ以上に対処することである。
【課題を解決するための手段】
【０００７】
本発明の１つの態様によれば、サブスクリプションサービスを提供する方法であって、サブスクリプションをアクチベートするためにサブスクリプションダイアログを確立し、前記サブスクリプションの確立時に前記サブスクリプションダイアログを終了し、そして加入者への通知を確立する段階を含む方法において、加入者の位置を決定し、その位置が決定された加入者に通知するための通知ダイアログを確立し、そしてその通知の完了時に前記通知ダイアログを終了するというステップを備えた方法が提供される。
【０００８】
サブスクリプションダイアログ及び通知ダイアログは、ＳＩＰセッションを含んでもよい。
前記方法は、更に、前記サブスクリプションの確立時にサブスクリプション識別子を記憶するステップを含むことができる。
加入者への通知を確立する前記ステップは、サブスクリプション事象の発生に応答して行うことができる。
加入者の位置を決定する前記ステップは、サブスクリプション識別子を位置サービスファンクションへ送信することを含んでもよい。
【０００９】
更に別の態様において、本発明は、サブスクリプションサービスを提供するためのネットワーク要素であって、加入者からサブスクリプションサービスのためのサブスクリプション要求を受け取る受信手段と、加入者とサブスクリプションサービスとの間のダイアログセッションをサポートする手段と、サブスクリプション要求をサブスクリプションサービスへ送信するための送信手段とを備え、前記受信手段は、更に、サブスクリプションサービスからサブスクリプションの確認を受け取り、前記送信手段は、更に、そのサブスクリプション確認を加入者へ転送し、そして更に、その確認に応答して、ネットワーク要素がダイアログセッションを解除するように構成されたネットワーク要素を提供する。
【００１０】
前記受信手段は、更に、加入者に対するサブスクリプションサービスからの通知を受信し、それに応答して、通知ダイアログセッションが確立され、前記送信手段は、加入者の位置を決定するための位置要求を送信し、加入者のための位置情報に応答して、上記送信手段は、更に、加入者へその通知を送信するように構成される。
【００１１】
前記受信手段は、加入者から前記通知の確認を受信し、その確認に応答して、前記送信手段は、サブスクリプションサービスへ確認を送信し、そしてダイアログセッションを解除する。
【００１２】
ダイアログは、ＳＩＰセッションを備えてもよい。
ネットワーク要素は、更に、前記サブスクリプションの確立の際にサブスクリプション識別子を記憶するように構成される。
加入者への通知を確立する前記ステップは、サブスクリプション事象の発生に応答してもよい。
加入者の位置を決定する前記ステップは、位置サービスファンクションへ加入者の識別子を送信することを含んでもよい。
【００１３】
更に別の態様によれば、本発明は、サブスクリプション要求を送信することを含むサブスクリプションダイアログを開始する加入者と、サブスクリプション要求を受信しそしてそのサブスクリプション要求をサブスクリプションサービスへ転送するためのネットワーク要素と、ネットワーク要素からサブスクリプション要求を受信するサブスクリプションサービス要素であって、加入者の識別子を記憶するための手段を有するサブスクリプションサービス要素とを備え、サブスクリプションサービス要素からの確認に応答して、前記ネットワーク要素がサブスクリプションダイアログを解除し、そしてサブスクリプション要素からの通知ダイアログの通知メッセージに応答して、前記ネットワーク要素が加入者の位置を決定しそして通知メッセージを加入者に転送するような通信システムを提供する。
【００１４】
別の態様によれば、本発明は、サーバーを構成する方法であって、ルート記録命令及びサブスクリプション要求を受信し、そしてルート記録命令に基づいてサブスクリプション要求のルートを記録するステップを備えた方法を提供する。
【００１５】
一実施形態では、ルート記録命令は、サブスクリプション要求の前に受信される。別の実施形態では、サブスクリプション要求がルート記録命令の前に受信される。
【００１６】
ルート記録命令はフェッチできる。このルート記録命令は、フィルタ基準の一部分として受信されてもよい。フィルタ基準は、サービス特定のものでよい。サービスは、プレゼンスサービスでよい。
【００１７】
ルート記録は、サブスクリプションに関連したサービスプロフィールの一部分として受信されてもよい。サブスクリプションは、ＳＩＰセッションのメッセージでよい。サーバーは、プロキシーサーバーでもよいし、又はサービングコール状態制御ファンクションを与えるサーバーでもよい。
前記方法は、サービスに対するルート記録命令を生成するステップを含むことができる。
【００１８】
更に別の態様によれば、本発明は、サブスクリプションサービスにおけるメッセージのヘッダーであって、このヘッダーはルート記録命令を含み、この命令は、ネットワーク要素の特性を制御するためのものであるヘッダーを提供する。
【００１９】
更に別の態様において、サブスクリプションを提供する方法において、サブスクリプションをアクチベートするためにサブスクリプションダイアログを確立するステップと、前記サブスクリプションダイアログにフィルタ基準を設けるステップと、サブスクリプションルートをネットワーク要素において選択的に記録するためにネットワーク要素に対する命令を含むように前記フィルタ基準を適応させるステップとを備えた方法が提供される。
【００２０】
前記ネットワーク要素は、申し込まれたサービスを提供するサーバーに関連したサービングコール状態又はセッション制御ファンクションでよい。
又、本発明は、サブスクリプションサービスを提供するためのネットワーク要素であって、この要素はルート記録命令を含むメッセージを受信し、このルート記録命令に応答して、前記メッセージに関連した通信セッションのルートを選択的に記録するようなネットワーク要素も提供する。
【発明を実施するための最良の形態】
【００２１】
本発明及びその実施形態を適切に理解するために、添付図面を参照して説明する。
本発明の幾つかの実施形態を、特定の構成を参照して一例として説明する。特に、本発明は、２つの特定の実施形態を参照してここに説明する。しかしながら、本発明は、ここに述べる実施形態及び／又は構成に限定されない。
【００２２】
本発明の第１の実施形態を、図１から３を参照して以下に一般的に説明する。図１、２及び３は、ＩＥＴＦ実施に適応される第１の実施形態を示す。
【００２３】
図１は、本発明の第１の実施形態を具現化できる移動通信ネットワークの要素を示す。この第１の実施形態において、本発明は、一般に、ＳＩＰ‐ＮＯＴＩＦＹメッセージのルーティングを実行することに係る。このようなメッセージルーティングは、例えば、一般に、３ＧＰＰ全ＩＰアーキテクチャーをサポートするＧＰＲＳ及び／又はＵＭＴＳ通信ネットワークにおいて実施できる。本発明のこの実施形態を理解する上で通常必要な要素だけを図示して説明する。ネットワークを完全に実施するために非常に好ましいか又は必要である他の要素は、当業者に明らかであろう。
【００２４】
ネットワークは、一般に、参照番号１０２で示される。このネットワーク１０２は、一般に、無線アクセスネットワーク１０４が設けられ、これは、移動装置、例えば、ユーザ装置（ＵＥ）１００（これに限定されないが）のネットワークへのアクセスを与える。本発明の第１の実施形態を理解するために、ネットワーク１０２は、無線アクセスネットワーク１０４への接続１１６を有するプロキシーサーバー１０６と、このプロキシーサーバー１０６への接続１１２を有するノーティファイヤ１０８と、プロキシーサーバー１０６への接続１１４を有する位置サーバー１１０とを含むように示されている。図示された要素は、通常、少なくとも非常に好ましいものであり、ある場合には、ＳＩＰ‐ＮＯＴＩＦＹメッセージのルーティングのために必要なものである。３ＧＰＰ  ＩＭＳにおける位置サーバーの一実施形態は、ＩＭＲ／ＨＳＳである。ある実施形態では、ノーティファイヤがサブスクリプションサーバーと称されてもよい。
【００２５】
ＩＥＦＴ実施における本発明の第１の実施形態は、図２の代表的シグナリング図及び図３のフローチャートを参照して更に説明する。
【００２６】
第１ステップ３０２において、ＵＥ（ユーザ装置）１００に関連した加入者は、通常、サービスへの申し込みを開始する。この申し込みの開始は、定常的に、ステップ３０４で表された第１のＳＩＰダイアログを生成する。ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージ２０２が、ＵＥ１００からプロキシーサーバー１０６へ共通に送信される。次いで、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージ２０４が、通常、プロキシーサーバー１０６からサブスクリプションサーバー１０８へ送信される。サブスクリプションサーバー１０８は、次いで、申し込みされたサービスに対するサブスクリプションデータベースに、ＵＥ１００に関連した加入者のパブリックＩＤ（識別子）をしばしば記憶する。
【００２７】
次いで、申し込みは、通常、ステップ３０６で表されたように、サブスクリプションサーバー１０８により受け容れられ、サブスクリプションサーバーは、受け容れられたＳＵＢＳＣＲＩＢＥメッセージ２０６をプロキシーサーバー１０６へ返送し、プロキシーサーバーは、次いで、通常、受け容れられたＳＵＢＳＣＲＩＢＥメッセージ２０８をＵＥ１００へ返送する。受け容れられたＳＵＢＳＣＲＩＢＥメッセージは、図２に示す例では、「２０２受け容れられた応答」である。しかしながら、このメッセージは、このようなフォーマットに限定されない。例えば、受け容れられたＳＵＢＳＣＲＩＢＥメッセージは、「２００ＯＫ」メッセージ応答でもよい。このように、申し込みが受け容れられる。これで、申し込みトランザクション及び第１のＳＩＰダイアログが完了となる。サブスクリプション情報は、サブスクリプションサーバー１０８に記憶される。
【００２８】
本発明の原理によれば、第１の実施形態において、申し込みに対して生成されたダイアログの応答は、次いで、ステップ３０８に示すように、プロキシーサーバー１０６により解除又は終了される。
【００２９】
受け容れられたＳＵＢＳＣＲＩＢＥメッセージの直後に、第１のＮＯＴＩＦＹメッセージを送信しなければならないことに注意されたい。このような場合には、この第１のＮＯＴＩＦＹメッセージが送信された後に、サブスクリプションに対して生成されたダイアログを解除又は終了するのが効果的である。これは、特定の実施形態の要求に応じて実施できる任意の特徴である。例えば、直ちにＮＯＴＩＦＹメッセージが必要とされない実施形態もあり、この場合には、第１のＮＯＴＩＦＹメッセージまでダイアログを維持するのは効果的でない。
【００３０】
ある時間の後に、サブスクリプションサーバー／ノーティファイヤ１０８は、サブスクリプション事象の検出に応答して、ステップ３１０において、ＵＥ１００に対する通知を開始する。第１のステップ３１２として、サブスクリプションサーバー／ノーティファイヤは、ＮＯＴＩＦＹ要求を含む新たなトランザクションを伴う第２のダイアログを生成する。サブスクリプションサーバー／ノーティファイヤ１０８は、ユーザ装置１００に関連した加入者を識別するＮＯＴＩＦＹメッセージ２１０をプロキシーサーバー１０６へ送信する。この通知メッセージは、サブスクリプション事象の通知を含む。これに応答して、ステップ３１４において、プロキシーサーバー１０６は、位置問合せメッセージ２１２を位置サーバー１１０へ送信する。位置サーバー１１０は、位置問合せ応答２１２を、ＵＥ１００に関連した加入者の位置の詳細と共に、プロキシーサーバー１０６へ返送する。
【００３１】
プロキシーサーバー１０６は、次いで、ＮＯＴＩＦＹメッセージ２１６をＵＥ１００へ送信する。ＵＥは、ＮＯＴＩＦＹ確認メッセージ２１８をプロキシーサーバー１０６へ返送し、プロキシーサーバー１０６は、次いで、ＮＯＴＩＦＹ確認メッセージ２２０をサブスクリプションサーバー／ノーティファイヤ１０８へ返送する。実際には、複数のＮＯＴＩＦＹメッセージが加入者サーバーからプロキシーサーバーを経てＵＥへ送信されてもよい。ＮＯＴＩＦＹトランザクション及びＮＯＴＩＦＹダイアログは、ステップ３１６で最初のＮＯＴＩＦＹのトランザクションが終了した後に閉じられてもよいが、継続されてもよい。
【００３２】
一連のメッセージが近い時間内に送信されることが意図される場合には、ＮＯＴＩＦＹメッセージに含まれた付加的なヘッダー／パラメーターが、通知ダイアログを閉じるかどうかについてプロキシーサーバー及びサブスクリプションサーバーに命令することができる。このヘッダー／パラメーターは、サブスクリプションの終了をＵＥ１００に命令するＮＯＴＩＦＹメッセージの既存の「サブスクリプション状態：終了」パラメーターと混合されないのが好ましい。サブスクリプションの終了は、図３のステップ３２０に示されている。
【００３３】
ＮＯＴＩＦＹダイアログが終了すると、ステップ３１８に到達する。ＮＯＴＩＦＹダイアログは、サブスクリプションの終了の前又はそれと共に終了されねばならない。
以上のことから明らかなように、プロキシーサーバー１０６がアクティブなセッション以外のダイアログに関連した詳細を記憶する必要はない。サブスクリプションが確立されると、プロキシーサーバーは、加入者の詳細をそこに記憶しない。プロキシーサーバーは、位置サーバーを使用して、通知が必要なときに加入者を探索する。従って、プロキシーサーバーは、加入者のいわゆる「ルート記録」を記憶しない。プロキシーサーバーは、アクティブなダイアログ中に使用されるが、このようなダイアログがもはやアクティブでなくなると、詳細を記憶しない。
【００３４】
図１には、簡単化のために１つのプロキシーサーバーしか示されていない。実際の３ＧＰＰの場合には、このようなプロキシーに関連した多数のコール状態又はセッション制御ファンクション（ＣＳＣＦ）と同様に、多数のプロキシーサーバーが含まれてもよい。非アクティブなダイアログを記憶しないという原理は、このような全てのプロキシー及びＣＳＣＦに適応することができる。しかしながら、ある場合には、インアクティブなダイアログを保持することが望まれる。
【００３５】
アクティブなセッション以外のダイアログの保持を防止することは、多数の方法で達成できる。例えば、
１．ダイアログの保持をプロキシーサーバーに必要とするかどうかを指示する新たな又は適応されたＳＩＰメッセージが設けられてもよい。
２．サブスクリプション又は通知セッションの完了時に、プロキシーサーバーがダイアログを維持すべきか解除すべきかを指示する付加的なヘッダーが既存のＳＵＢＳＣＲＩＢＥメッセージに設けられてもよい。
３．ＳＵＢＳＣＲＩＢＥメッセージにおける既存のＳＩＰヘッダーの値を使用して、サブスクリプション又は通知セッションの完了時にプロキシーサーバーがダイアログを維持すべきか解除すべきかを指示してもよい。
４．ＳＩＰプロキシー、ＩＭＳエンティティ又は非ＩＭＳエンティティにおいて、ルート記録をデフォールトにより自動的に省略してもよい。このような技術は、エレメントを適応させることを必要とする。
【００３６】
ダイアログリソースは、プロキシーサーバー又はＣＳＣＦにおいて解除されるが、サブスクリプションは、サブスクリプションサーバー／ノーティファイヤにおいて依然アクティブである。それ故、サブスクリプションサーバー／ノーティファイヤは、新たなサブスクリプション情報を加入者／ユーザ装置へ発行すべきときに、ＮＯＴＩＦＹメッセージを通常の仕方でプロキシーサーバーへ送信する。それ故、サブスクリプションサーバー／ノーティファイヤの変更は必要ない。ＮＯＴＩＦＹメッセージは、通常の又は単一のトランザクションとして送信されてもよい。ＮＯＴＩＦＹメッセージに対する別のＳＩＰ要求が使用されてもよい。この実施形態は、プロキシー又はＣＳＣＦエンティティにおけるダイアログの保持に対する変更だけを提案する。
【００３７】
本発明のこの実施形態によれば、通知が必要とされるときにプロキシーサーバー（又は同等の機能的エンティティ）へ位置を与えるために、プロキシーサーバー（又は同等の機能的エンティティ）が加入者のダイアログを解除することが、位置サーバー或いは他のレジスタ又は位置機能サービスへのアクセスにより補償される。
【００３８】
通常、プロキシーサーバー１０６は、実際には、ユーザ装置とサブスクリプションサーバー１０８との間にダイアログを確立するための接続処理サーバー（ＣＰＳ）である。ある実施形態によれば、ＣＰＳは、セッションコントローラーサブシステムの一部分であるのが好ましい。
【００３９】
本発明のこの第１の実施形態は、好ましくは、プロキシーサーバーのリソースを解放するという顕著な効果を発揮する。さもなければ、プロキシーサーバー、ひいては、接続処理サーバーは、一般に、ダイアログ及び／又はルート記録を記憶しなければならないことにより甚だしい制約を受ける。
【００４０】
図１及び２を参照して述べた本発明の第１の実施形態は、本発明の考えられる実施形態を例示するものであることに注意されたい。より詳細には、この例は、加入者が単一ネットワークにおいてプレゼンス情報を申し込む筋書きに係るものである。しかしながら、本発明の第１の実施形態は、このようなネットワーク筋書きのみへの適用に限定されないことに注意されたい。又、本発明の第１の実施形態の原理は、「ウオッチャー」がプレゼンティティのホームネットワーク以外に位置するような筋書きへ拡張することもできる。このような筋書きでは、サブスクリプションサーバー即ちノーティファイヤ１０８は、図１のプロキシーサーバー１０６ではなく、ウオッチャーのホームネットワークのプロキシーへＮＯＴＩＦＹメッセージを直接送信することができる。ＮＯＴＩＦＹメッセージは、サブスクリプション手順中に記憶されるウオッチャーの認識を含むのが好ましい。ＮＯＴＩＦＹメッセージがウオッチャーのホームネットワークのプロキシーにより受信されると、ウオッチャーのホームネットワークにおける位置サーバーへ問い合わせが行われ、そしてＮＯＴＩＦＹメッセージのルートは、この技術で知られている通常の着信ルートと一貫したものであるのが好ましい。
【００４１】
従って、一般に、第１の実施形態に関連して説明した本発明の原理によれば、申し込み事象を通知するために、ＮＯＴＩＦＹメッセージがノーティファイヤにより発生されると、ＮＯＴＩＦＹメッセージは、サブスクリプション中に記憶されるウオッチャーの認識で特定されるターゲットネットワークのプロキシーに向かって送信される。このプロキシーは、ウオッチャーのホームネットワークのプロキシーサーバーでよく、これは、ウオッチャーの位置を見出すことができる。
【００４２】
以下の説明において、この一般化は、ＩＭＳ環境に適応される本発明の第２の実施形態を示した図４及び５に示すＩＭＳ環境に適用される。
【００４３】
又、本発明の第１の実施形態の原理は、「ウオッチャー」がプレゼンティティのホームネットワーク以外に位置するようなＩＭＳネットワークにおける筋書きへと拡張することもできる。このような筋書きでは、サブスクリプションサーバー即ちノーティファイヤ１０８は、ＮＯＴＩＦＹメッセージを直接又はプロキシーを経てウオッチャーのホームネットワークのプロキシーへ送信することができる（図１のプロキシーサーバー１０６ではなく）。図４に示すように、ＩＭＳの場合には、ウオッチャーのホームネットワークにおけるこのプロキシーは、エントリーポイントプロキシーでよく、例えば、質問コール状態又はセッション制御ファンクション（Ｉ‐ＣＳＣＦ）でよい。ＮＯＴＩＦＹメッセージは、サブスクリプション手順中に記憶されるウオッチャーの認識を含むのが好ましい。ＮＯＴＩＦＹメッセージが、エントリーポイントプロキシー、例えば、Ｉ‐ＣＳＣＦにより受信されると、位置サーバー、例えば、ウオッチャーのホームネットワークにおけるＨＳＳへ問い合わせが行われ、ＮＯＴＩＦＹメッセージのルートは、この技術で知られたようにＩＭＳにおける通常の着信ルートと一貫しているのが好ましい。
【００４４】
図４は、本発明の第２の実施形態を具現化できる移動通信ネットワークの要素を示す。本発明のこの実施形態を理解するのに通常必要な要素のみを図示して説明する。ネットワークを完全に実施するのに非常に好ましい又は必要な他の要素は、当業者に明らかであろう。図５は、第２の実施形態の特徴を更に示すシグナリング図である。図５のシグナリング図において、図の複雑さを軽減するために、図４の全てのネットワーク要素が含まれているのではない。図５のシグナリング図と図４のネットワーク実施形態との間の関係は、以下の説明から明らかとなろう。
【００４５】
図４を参照すれば、プレゼンスサービスに対するウオッチャー又は加入者であるＵＥ６０６の、ネットワークＡで示すネットワーク６０４が一般的に示されている。更に、ＵＥ６０６に関連したウオッチャーが申し込むサブスクリプションサービスプロバイダーのホームネットワークである、ネットワークＢで示すネットワーク６０２も示されている。
【００４６】
ウオッチャーＵＥ６０６のホームネットワークは、Ｐ‐ＣＳＣＦ６０８、Ｓ‐ＣＳＣＦ６１０、Ｉ‐ＣＳＣＦ６１２、及びレジスタ６１４を備えている。プレゼンスサービスプロバイダーのホームネットワーク６０２は、サブスクリプションサーバー６１６、Ｓ‐ＣＳＣＦ６１８、Ｉ‐ＣＳＣＦ６２０、及びレジスタ６２２を備えている。これらネットワーク６０２及び６０４各々のレジスタ６２２及び６１４は、各々、各ネットワークに接続される要素の位置情報を与えるのに適した位置サーバー又はホーム加入者サーバーであることに注意されたい。
【００４７】
以下、図４及び５を参照して、本発明の第２の実施形態を詳細に説明する。先ず、図４を参照すれば、ウオッチャーＵＥ６０６は、先ず、サブスクリプションサーバー６１６に関連したプレゼンスサービスに申し込む。これを達成するために、ＵＥ６０６は、図４に信号６２４で示されたＳＵＢＳＣＲＩＢＥメッセージを、ＵＥ６０６に関連したＰ‐ＣＳＣＦであるＰ‐ＣＳＣＦ６０８へ送信する。このＳＵＢＳＣＲＩＢＥメッセージは、次いで、信号６２６で示すように、Ｐ‐ＣＳＣＦ６０８からＳ‐ＣＳＣＦ６１０へ送信され、Ｓ‐ＣＳＣＦ６１０は、ＵＥ６０６に関連したホームＳ‐ＣＳＣＦである。次いで、Ｓ‐ＣＳＣＦ６１０は、信号６２８で示すようにＳＵＢＳＣＲＩＢＥメッセージをネットワーク６０２のＩ‐ＣＳＣＦ６２０へ送信する。ＳＵＢＳＣＲＩＢＥメッセージを、サブスクリプションサーバーが位置するネットワークのＩ‐ＣＳＣＦへ送信することは、この技術で既に知られている。従って、図５のシグナリング図では、ＵＥ６０６からＩ‐ＣＳＣＦ６２０へのＳＵＢＳＣＲＩＢＥメッセージの送信は、単一の信号７０２で示されている。
【００４８】
再び図４を参照すれば、ＳＵＢＳＣＲＩＢＥメッセージを受信すると、Ｉ−ＣＳＣＦ６２０は、信号６３０で示すように、位置問合せメッセージをレジスタ６２２へ送信する。位置問合せメッセージは、図５に信号７０４で示されている。これに応答して、レジスタ６２２は、図４に信号６３２で示すように、位置問合せ返答をＩ−ＣＳＣＦ６２０へ返送する。位置問合せ返答は、図５に信号７０６で示されている。
【００４９】
レジスタ６２２は、Ｉ−ＣＳＣＦ６２０にＳ−ＣＳＣＦの認識を返送し、これを使用して、ＳＵＢＳＣＲＩＢＥ要求を、Ｓ−ＣＳＣＦ６１８の認識であるサブスクリプションサーバーへルーティングすることができる。それ故、Ｉ−ＣＳＣＦ６２０は、信号６３４で示すように、Ｓ−ＣＳＣＦ６１８にＳＵＢＳＣＲＩＢＥメッセージを転送し、これは、次いで、ＳＵＢＳＣＲＩＢＥメッセージを、信号６３６で示すように、サブスクリプションサーバー６１６へ転送する。図５を参照すると、Ｉ−ＣＳＣＦ６２０からサブスクリプションサーバー６１６へのＳＵＢＳＣＲＩＢＥメッセージの送信は、単一の信号７０８で示されている。
【００５０】
ＳＵＢＳＣＲＩＢＥメッセージを受信すると、サブスクリプションサーバー６１６は、プレゼンスサービスに対してＵＥ６０６を登録し、そしてＵＥ６０６は、サブスクリプションサーバー６１６の加入者となる。図５にブロック７２６で示すように、サブスクリプションサーバー６１６は、加入者のパブリック認識をそのサブスクリプションデータベースに記憶する。その後、２０２ＳＵＢＳＣＲＩＢＥ受け容れメッセージが、図４に信号６３５、６３３、６２７、６２５及び６２３で示すように、ＳＵＢＳＣＲＩＢＥメッセージが送信されたのと同じ経路を経てユーザ装置６０６へ返送される。同様に、図５において、ＳＵＢＳＣＲＩＢＥ受け容れメッセージの戻り路が、信号７１０及び７１２で一般的に示されている。
【００５１】
この段階において、プレゼンスサービスへの申し込みが完了となる。本発明の技術によれば、申し込みに対して形成されたダイアログが解除又は終了される。これが、図５に、ブロック８２８で示されている。
【００５２】
その後のある段階で、サブスクリプションサーバー６１６は、プレゼンスアクティビティをウオッチャーに通知することが必要になり、新たなダイアログを開始しなければならない。それ故、サブスクリプションサーバー６１６は、ＵＥ６０６へ送信するためのＮＯＴＩＦＹメッセージを発生する。加入者のパブリック認識をそのデータベースに記憶すると、サブスクリプションサーバー６１６は、図４に信号６３８で示すように、ウオッチャーネットワーク６０４のＩ−ＣＳＣＦ６１２へＮＯＴＩＦＹメッセージを直接送信する。これも、図５に信号７１４で同様に示されている。
【００５３】
次いで、Ｉ−ＣＳＣＦ６１２は、信号６４０で示すように、位置問合せ信号をレジスタ６１４へ送信し、該レジスタは、信号６４２で示すように、Ｉ−ＣＳＣＦ６１２へ位置問合せ回答を返送する。図５において、Ｉ−ＣＳＣＦ６１２からレジスタ６１４への位置問合せは、信号７１６で示され、そして位置問合せ回答は、信号７１８で示されている。
【００５４】
その後、Ｉ−ＣＳＣＦ６１２は、ＮＯＴＩＦＹメッセージをＳ−ＣＳＣＦ６１０へ転送し、その認識はレジスタ６１４により与えられる。Ｓ−ＣＳＣＦ６１０へのＮＯＴＩＦＹメッセージの転送は、図４に信号６４４で示されている。次いで、Ｓ−ＣＳＣＦ６１０は、ＵＥ６０６に関連したＰ−ＣＳＣＦ６０８へＮＯＴＩＦＹメッセージを転送し、これは、次いで、ＮＯＴＩＦＹメッセージを、信号６４８で示すように、ＵＥ６０６へ転送する。Ｉ−ＣＳＣＦ６１２からＵＥ６０６へのＮＯＴＩＦＹメッセージの転送は、図５に単一の信号７２０で示されている。
【００５５】
その後、ＵＥ６０６は、この技術で良く知られたように、ＮＯＴＩＦＹメッセージの受信をサブスクリプションサーバー６１６へ確認する。図５に示すように、ＵＥ６０６は、信号７２２で示すように、２００ＮＯＴＹＦＹ・ＯＫメッセージをＩ−ＣＳＣＦ６１２へ返送する。実際に、このメッセージは、Ｐ−ＣＳＣＦ６０８及びＳ−ＣＳＣＦ６１０を通る戻り路をたどる。Ｉ−ＣＳＣＦ６１２は、次いで、図５に信号７２４で示すように、２００ＮＯＴＹＦＹ・ＯＫメッセージをサブスクリプションサーバー６１６へ転送する。図５にブロック７３０で示すように、ウオッチャーへ通知を与えるためにオープンした更に別のダイアログが解除又は終了される。
【００５６】
従って、一般に、第１の実施形態に関連した述べた本発明の原理によれば、申し込み事象を通知するために、ノーティファイヤによりＮＯＴＩＦＹメッセージが発生されると、サブスクリプション中に記憶されるウオッチャーの認識で特定されるターゲットネットワークのＩ−ＣＳＣＦに向かってＮＯＴＩＦＹメッセージが送信される。Ｉ−ＣＳＣＦは、ウオッチャーのホームネットワークのプロキシーサーバーでよい。
【００５７】
図６及び７を参照して、本発明の第３の実施形態を以下に説明する。
図６は、本発明の第３の実施形態を具現化できる移動通信ネットワークの典型的な要素を示す。この第３の実施形態において、本発明は、再び、一般に、ＳＵＢＳＣＲＩＢＥ及びＳＩＰ−ＮＯＴＩＦＹメッセージのルーティングの実行に係る。このようなメッセージルーティングは、ここでも、３ＧＰＰ全ＩＰアーキテクチャーをサポートするＧＰＲＳ又はＵＭＴＳ通信ネットワークにおいて実施することができる。本発明のこの実施形態を理解するのに必要な要素のみを図示して説明する。ネットワークを完全に実施するのに必要な他の要素は、当業者に明らかであろう。
【００５８】
図１を参照して上述した実施形態では、ユーザ装置とサブスクリプションサーバーとが共通のネットワークに接続された簡単な例を説明した。図６の実施形態では、ユーザ装置とサブスクリプションサーバー（又はアプリケーションサーバー）とが異なるネットワークに接続された例が示されている。
【００５９】
図６には、２つのネットワークが示されている。第１ネットワーク４０６は、ウオッチャーに関連したユーザ装置（ＵＥ）４０２に対するホームネットワーク（ホームネットワーク＃１）である。ウオッチャーとは、一般に、プレゼンスサービスへの加入者を説明するのに使用される語である。第２ネットワーク４０４（ホームネットワーク＃２）は、プレゼンティティに対するホームネットワークである。プレゼンティティとは、一般に、プレゼンスサービスを提供するエンティティを説明するのに使用される語である。プレゼンティティは、アプリケーションサーバー（ＡＳ）４１４で実行されるプレゼンスサーバーアプリケーションにより表わされる。ここに述べる実施形態では、アプリケーションサービスを提供すると一般に考えられるアプリケーションサーバー４１４が、プレゼンスサービスを提供し、それ故、プレゼンスサーバー（ＰＳ）と考えてもよい。
【００６０】
第１ホームネットワーク４０６は、第１のプロキシーコール状態又はセッション制御ファンクション（Ｐ−ＣＳＣＦ＃１）４２０に接続された無線アクセスネットワーク４１８を備え、Ｐ−ＣＳＣＦ＃１は、次いで、第１のサービングコール状態又はセッション制御ファンクション（Ｓ−ＣＳＣＦ＃１）４２２に接続される。第２のホームネットワーク４０４は、無線アクセスネットワーク４１６も備えている。質問側コール状態又はセッション制御ファンクション（Ｉ−ＣＳＣＦ）４０８が、ＨＳＳ（ホーム加入者サーバー）４１０及び第２のサービングコール状態又はセッション制御ファンクション（Ｓ−ＣＳＣＦ＃２）に接続される。第２のサービングコール状態又はセッション制御ファンクション（Ｓ−ＣＳＣＦ＃２）は、アプリケーションサーバー４１４に接続される。
【００６１】
図７のシグナリング図を参照し、第３の実施形態に基づき本発明を更に説明する。プレゼンスサービスに関して上述したように、ウオッチャー（又はプレゼンスサービスへの加入者）と考えられるＵＥ４０２は、サブスクリプション要求メッセージをアプリケーションサーバー４１４に向けて送信する。サブスクリプション要求は、ウオッチャーが申し込みしたいプレゼンス情報に対するユーザのパブリックユーザ認識を含む。
【００６２】
サブスクリプション要求は、ＵＥ４０２からユーザホームネットワークのＰ−ＣＳＣＦ＃１  ４２０へのＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージ５０２の送信と、加入者ホームネットワークのＰ−ＣＳＣＦ＃１  ４２０から加入者ホームネットワークのＳ−ＣＳＣＦ＃１  ４２２へのＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージ５０４の送信とを含む。Ｐ−ＣＳＣＦ＃１  ４２０は、ユーザのホームネットワークに配置されてもよいし、或いはユーザのホームネットワーク以外に配置されてもよく、例えば、ユーザが自分の母国以外をローミングする場合には訪問先ネットワークにあってもよい。
【００６３】
Ｓ−ＣＳＣＦ＃１  ４２２では、サブスクリプションに対する初期フィルタ基準の評価が、ＩＰマルチメディアサブシステムのＩＳＣインターフェイスに対するルーティング原理に基づいて実行される。
【００６４】
次いで、ＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージ５０６が、プレゼンス情報を申し込むユーザのパブリックユーザ認識に基づいてＩＭＳを経て、加入者ホームネットワークのＳ−ＣＳＣＦ＃１  ４２２から、第２ホームネットワーク即ちプレゼンティティのホームネットワークのＩ−ＣＳＣＦ４０８へ更に送信される。次いで、ＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージ５１０が、ＨＳＳ４１０へ送信された位置問合せ５０８に対する応答として受け取られる情報に基づいて、プレゼンティティのホームネットワークのＳ−ＣＳＣＦ＃２  ４１２へ転送される。
【００６５】
ＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージを受け取る前に、Ｓ−ＣＳＣＦ＃２  ４１２は、ウオッチャーが申し込みしたいプレゼンス情報に対する加入者（プレゼンティティ）のフィルタ基準をＨＳＳ４１０から受け取ることができる。このフィルタ基準は、加入者に対するルート記録情報を含んでもよい。従って、サブスクリプションメッセージを受け取る前に、Ｓ−ＣＳＣＦ＃２は、加入者に対するルート記録情報を既に受け取っているのが好ましい。
【００６６】
しかしながら、これは、必ずしも全ての実施形態に当てはまるものではない。他の実施形態では、特定のＳ−ＣＳＣＦがサブスクリプションメッセージを最初に受け取り、次いで、例えば、フィルタ基準に含まれたルート記録情報をフェッチしてもよい。
【００６７】
いずれにせよ、Ｓ−ＣＳＣＦ＃２  ４１２は、ウオッチャーが申し込みしたいプレゼンス情報に対する加入者（プレゼンティティ）について、好ましくはユーザプロフィールに含まれたルート記録命令を含むフィルタ基準を受け取る。これは、一実施形態では、ＨＳＳ４１０から受け取られる。従って、加入者に対するルート記録命令は、一実施形態では、ＨＳＳに記憶されてもよい。メッセージがＳ−ＣＳＣＦ＃２  ４１２により受け取られるか、又はより一般的には、プロキシーサーバーにより受け取られると、プロキシーサーバーは、その受け取ったフィルタ基準に基づいてルート記録を実施すべきかどうか選択できる。別の実施形態では、Ｉ−ＣＳＣＦ４０８が、Ｓ−ＣＳＣＦ＃２に対するフィルタ基準をフェッチしてもよい。
【００６８】
Ｓ−ＣＳＣＦ＃２  ４１２において、当業者に馴染み深いプレゼンスサービスに対して提案された技術に基づき、初期フィルタ基準の更に別の評価が実行される。初期フィルタ基準の更に別の評価は、Ｓ−ＣＳＣＦ＃２  ４１２が加入者のサービスプロフィールを確認することを含む。本発明のこの第３の実施形態によれば、加入者要求のフィルタ基準は、Ｓ−ＣＳＣＦ＃２  ４１２が、アクティブでないときに、サブスクリプションに対する「ルート記録」エントリーを生成すべきかどうかの指示を含むように適応される。フィルタ基準は、サブスクリプション要求をルーティングすべきアプリケーションサーバーに関して、ルートを記録すべきでない命令で、Ｓ−ＣＳＣＦ＃２に命令することができる。
【００６９】
この分野のプレゼンスサービスに対する提案において、Ｓ−ＣＳＣＦが全てのＳＩＰダイアログ生成要求をルート記録する必要がないことが既に提案されている。プレゼンスサービスでは、特に、プレゼンティティのＳ−ＣＳＣＦが、Ｓ−ＣＳＣＦの静的な割り当てを回避するために、プレゼンスＳＵＢＳＣＲＩＢＥダイアログから意図的に除外される。多数の新たな事象パッケージが出現するために、Ｓ−ＣＳＣＦが、ＳＩＰダイアログをルート記録すべきかどうかについて適切に判断するよう確保することが益々重要になる。Ｓ−ＣＳＣＦは、ルート記録が必要なときにそれを行うことが重要であるが、システムリソースを最大にするために、Ｓ−ＣＳＣＦが必ずしもルート記録を行わないことも重要である。この問題は、Ｓ−ＣＳＣＦがＳＩＰダイアログにおいてＳＩＰプロキシーサーバーとして働く場合に特に明らかである。
【００７０】
従って、ここに述べる第３の実施形態では、サブスクリプションメッセージをアプリケーションサーバーへルーティングするＳ−ＣＳＣＦ＃２は、初期フィルタ基準を使用して、ＩＳＣインターフェイスに関するルート判断を行う。本発明の原理によれば、初期フィルタ基準は、ルート記録の振舞いに関してＳ−ＣＳＣＦ＃２に命令するように拡張することができる。初期フィルタ基準は、サービス特有のものであり、それ故、Ｓ−ＣＳＣＦがルート記録すべきかどうかに関する情報を追加する適切な場所である。
【００７１】
例えば、プレゼンスサービスの場合に、ＴＲ２４．８４１  ０．５．０のフロー６．１．２．１、ステップ７において、拡張された初期フィルタ基準に基づく振舞いは、次の通りである。
Ｓ−ＣＳＣＦ＃２は、この加入者のサービスプロフィールを確認し、そして初期フィルタ基準を評価する。ｓｉｐ：ｕｓｅｒ２＿ｐｕｂｌｉｃ１＠ｈｏｍｅ２．ｎｅｔに対して、Ｓ−ＣＳＣＦ＃２は、終了初期フィルタ基準を有し、その当該サービスポイントは、Method＝SUBSCRIBE and Event＝”presence” and action＝”create Record-Route entry: no” that informs the S-CSCF to route the SUBSCRIBE request to the Application Server ps.home2.net and do not create a Record-Route entry for the request.である。
【００７２】
次いで、Ｓ−ＣＳＣＦ＃２  ４１２は、ＳＩＰ−ＳＵＢＳＣＲＩＢＥメッセージ５１４をアプリケーションサーバー４１４へ転送する。ブロック５１６で示されたように、次いで、ウオッチャーの許可が、この技術で知られたように、ＵＥ４０２に関連した加入者に対して確立される。
【００７３】
一連のＳＩＰ２００ＯＫメッセージが、次いで、同じルートを逆にＵＥへと流れて、サブスクリプション設定の完了を指示し、これは、メッセージ５１８、５２０、５２２、５２４、５２６により表わされる。
【００７４】
これに続いて、アプリケーションサーバーは、加入者へ事象を通知する。図７に示すように、アプリケーションサーバーは、ＳＩＰ−ＮＯＴＩＦＹメッセージ５３２を、ＩＭＳのＵＥホームネットワークのＳ−ＣＳＣＦ＃１  ４２２へ直接送信し、これは、次いで、ＳＩＰ−ＮＯＴＩＦＹメッセージ５３０をＰ−ＣＳＣＦ＃１へ送信し、これは、次いで、ＳＩＰ−ＮＯＴＩＦＹメッセージ５２８をＵＥ４０２へ送信する。一連のＳＩＰ−２００ＯＫメッセージが逆のルートをたどり、これは、ＳＩＰ２００ＯＫメッセージ５３４、５３６及び５３８で示されている。従って、アプリケーションサーバーは、ＳＩＰ−ＮＯＴＩＦＹメッセージを、サブスクリプションが設定されて確認されたルートを通らずに、加入者のホームネットワークのＳ−ＣＳＣＦ＃１へ直接送信する。
【００７５】
従って、１つのネットワーク（接続ネットワーク）に接続された加入者が、別のネットワーク（サービスネットワーク）に接続されたサービスプロバイダーに申し込みするという筋書きのサブスクリプションサービスの実施形態では、サービスネットワークのプロキシー又はＣＳＣＦがルート記録情報を保持することが要求されない。
【００７６】
サービスネットワークのＳ−ＣＳＣＦは、ルート記録情報を保持してもよいし、しなくてもよい。ルート記録情報が保持されない場合には、Ｓ−ＣＳＣＦ＃２が、通知をルーティングする経路からドロップされ、即ちＳ−ＣＳＣＦ＃２を経て通知がルーティングされない。
【００７７】
図６の実施形態では、上述したように、Ｓ−ＣＳＣＦ＃２  ４１２は、ウオッチャーが申し込みしたいプレゼンス情報に対する加入者のフィルタ基準をＨＳＳ４１０から受け取る。このフィルタ基準は、ＨＳＳ４１０により自動的に与えられてもよいし、或いはＨＳＳ４１０から検索されてもよい。上述した実施形態では、フィルタ基準は、Ｓ−ＣＳＣＦ＃２  ４１２がその加入者に対するＳＩＰダイアログをルート記録すべきかどうか指示するルート記録命令を含む。
【００７８】
図６の実施形態のこの観点の改善、より詳細には、Ｓ−ＣＳＣＦ＃２  ４１２へ供給されるか又はＳ−ＣＳＣＦ＃２  ４１２で構成されるフィルタ基準に関する改善について、以下に述べる。この改善において、各加入者に対する加入者フィルタ基準に加えて、システムフィルタ基準がＩＭＳへ導入される。このシステムフィルタ基準は、特定の加入者に関連していない。あらゆる場合のあらゆるメッセージに対する全システムフィルタ基準を設けることができる。或いは又、特定形式の全てのサブスクリプション又はシステム内の特定ポイントにおける全てのサブスクリプションに適用されるシステムフィルタ基準が設けられてもよい。例えば、ＵＥ発信のケース、着信登録のケース、ＡＳ発信のケース、着信非登録のケース、又は他のケースに対して個別のシステムフィルタ基準が存在してもよい。上述した４つのケースについて以下に述べる。
【００７９】
ＵＥ発信のケースは、ユーザのホームネットワークにおけるユーザホームＳ−ＣＳＣＦへのメッセージフローを指すもので、ここでは、メッセージフローが、ユーザ装置から、プロキシーＣＳＣＦ（訪問先ネットワーク又はユーザのホームネットワークに位置する）、ユーザのホームネットワークのサービングＣＳＣＦ、及びアプリケーションサーバーへと流れるか、或いはそれとは逆に流れる。ユーザ装置及びアプリケーションサーバーが同じネットワークに接続された図１の構成では、全てのメッセージが発信のケースに入る。図６では、発信のケースは、第１ホームネットワーク４０６におけるメッセージを指す。
【００８０】
着信登録のケースは、アプリケーションのホームネットワークにおいて、一般に、アプリケーションのホームネットワークの質問側ＣＳＣＦから、アプリケーションのホームネットワークのサービングＣＳＣＦ、及びアプリケーションサーバーへ、或いはそれとは逆に流れるメッセージフローを指す。図６において、着信のケースは、第２のホームネットワーク４０４におけるメッセージを指す。
【００８１】
ＡＳ発信のケースは、発信者がアプリケーションサーバーであるユーザのホームネットワークにおけるメッセージフローを指す。このメッセージフローは、ＡＳから、ユーザのホームネットワークのサービングＣＳＣＦへ及び任意であるが別のアプリケーションサーバーに向かって流れ、或いはそれとは逆に流れる。
【００８２】
着信非登録のケースは、ターゲット認識、例えば、ユーザ装置が登録されないアプリケーションのホームネットワークにおけるメッセージフローを指す。着信登録のケースと同様に、メッセージフローは、アプリケーションのホームネットワークの質問側ＣＳＣＦから、アプリケーションのホームネットワークのサービングＣＳＣＦ、及びアプリケーションサーバーへ、或いはそれとは逆に流れる。図４において、着信のケースは、第２のホームネットワーク４０４におけるメッセージを指す。
【００８３】
システムのフィルタ基準は、上述したＵＥ、並びにＡＳ発信及び着信登録及び非登録のケースの各々又は全部に対する１つ以上のシステムフィルタ基準を含んでもよく、各形式のケースにはおそらく異なるシステムフィルタ基準が適用される。或いは又、上述したケースの１つ以上に対してシステムフィルタ基準が共通であってもよい。
【００８４】
一般に、システムフィルタ基準は、オペレータのＩＭＳネットワークにおける１つ以上のＳ−ＣＳＣＦに関連したオペレータのＩＭＳネットワークの構成データを含むと考えられる。
【００８５】
システムフィルタ基準の全部又はその一部分が、１つ以上のＳ−ＣＳＣＦにおいて構成されるか又はそこに供給されてもよく、及び／又はシステムフィルタ基準の全部又はその一部分が、データベースから、及び／又はテーブルから、及び／又はリストから、及び／又はファイルから、及び／又は１つ以上のＳ−ＣＳＣＦに共通の同様のソースから、１つ以上のＳ−ＣＳＣＦへロードされてもよい。このようなシステムフィルタ基準は、１つ以上のＳ−ＣＳＣＦ、及び／又は他の任意のネットワークエンティティ、及び／又はネットワークのどこかに配置されてもよい。
【００８６】
システムフィルタ基準の全部又はその一部分がＳ−ＣＳＣＦにおいて構成されるときには、Ｓ−ＣＳＣＦの開始前、及び／又はそのもとで、及び／又はその後に、及び／又は必要に応じて、構成が行われてもよい。システムフィルタ基準の全部又はその一部分が、Ｓ−ＣＳＣＦにロードされるときには、Ｓ−ＣＳＣＦの開始前、及び／又はそのもとで、及び／又はその後に、及び／又は必要に応じて、ロードが行われてもよい。
【００８７】
システムフィルタ基準を使用すると、特定の個々の加入者フィルタ基準がオーバーライドを行い又はこれをオーバーライドすることができる。例えば、Ｓ−ＣＳＣＦがルート記録を保持してはならないことが要求されるようにネットワークが構成されてもよい。しかしながら、特定の加入者に関連した加入者フィルタ基準セットが、ダイアログセッションの確立に関連したＳ−ＣＳＣＦがルート記録を保持しなければならないことを指示してもよい。システムフィルタ基準セットを使用すると、このような特定の加入者フィルタ基準情報をオーバーライドすることができ、ネットワークは、ネットワーク構成の制御を維持する。別の例では、ネットワークは、Ｓ−ＣＳＣＦがルート記録を保持してはならないことが要求されるように構成されてもよい。しかしながら、特定の加入者に関連した加入者フィルタ基準セットが、ダイアログセッションの確立に関連したＳ−ＣＳＣＦがルート記録を保持しなければならないことを指示してもよい。システムフィルタ基準セットを使用すると、特定の加入者フィルタ基準情報がデフォールトをオーバーライドできるようにデフォールト（即ち、ルートを記録しない）を定義することができる。
【００８８】
加入者フィルタ基準は、プレゼンス事象への申し込みに対してルート記録エントリーを生成すべきでないことを規定してもよい。これは、初期加入者フィルタ基準において、例えば、次のように定義することができる（ＴＲ２４．８４１、バージョン１．０．０、サブクローズ６．１．２．１から抜粋）
Method = SUBSCRIBER and EVENT = “presence” and action = 
“create record-route entry: no”
各加入者事象に対してルート記録が保持されないことを確保するために、このような加入者フィルタ基準を各加入者の各セッションにおいて定義することが必要となる。
【００８９】
ネットワークにおいて一貫したオペレーションを確保するより効率的な方法として、プレゼンス情報を申し込むための全ての要求に適用できるシステムフィルタ基準を、例えば、次のように定義することができる。
Method = SUBSCRIBER and EVENT = “presence” and action = 
“create record-route entry: no”
【００９０】
この単一システムフィルタ基準は、ＨＳＳ４１０、Ｓ−ＣＳＣＦ４１２、又は他のネットワークエンティティ、或いは任意のデータベースのいずれか１つに単一のフィルタ基準として記憶及び／又は構成されてもよいが、全ての加入者セッションに適用できる。この単一のシステムフィルタ基準は、単一のフィルタ基準として記憶及び／又は構成されてもよいし、或いは記憶及び／又は構成されたフィルタ基準セットの一部分であってもよい。記憶及び／又は構成された単一システムフィルタ基準のフォーマット及びコンテンツは、加入者フィルタ基準の場合と同じであってもよいし、そうでなくてもよい。
【００９１】
これは、次いで、加入者フィルタ基準を簡単化するのを許す。プレゼンス情報に申し込みしたい全てのユーザのサービスプロフィールにおける加入者フィルタ基準は、例えば、次のように簡単化することができる。
Method = SUBSCRIBER and EVENT = “presence”
【００９２】
従って、本発明の実施形態のこの改善は、ルート記録を保持すべきかどうかに関するフィルタ基準の一般的機能を、システムフィルタ基準に一度記述するだけでよくし、単一の加入者ごとにフィルタ基準にそれを挿入する必要性をなくすことである。好都合にも、これは、ＨＳＳのスペースを節約する。この単一システムフィルタ基準は、大量の加入者特有のフィルタ基準より維持が非常に容易である。
【００９３】
又、システムフィルタ基準を実施する際には、システムフィルタ基準と加入者フィルタ基準の両方が特定のセッションに対して存在する場合にはそれらの間の衝突を取り扱うためのプライオリティルールを実施することも必要となる。このような場合には、実施において、両方のフィルタ基準を新たな適用可能なフィルタ基準に結合し、システムフィルタ基準におけるデータが加入者フィルタ基準における対応データをオーバーライドするか、又は加入者フィルタ基準におけるデータがシステムフィルタ基準における対応データをオーバーライドするようにする。従って、衝突するシステム及び加入者フィルタ基準に代わって、新たな適用可能なフィルタ基準を使用することができる。
【００９４】
第１の実施形態は、システムフィルタ基準が加入者フィルタ基準をオーバーライドするものである。この実施形態では、Ｓ−ＣＳＣＦ４１２のようなＳ−ＣＳＣＦは、先ず、加入者フィルタ基準を評価することができる。特定の加入者セッションの場合にその加入者に対して一致が見つかると、その加入者フィルタ基準がピックアップされて適用される。
【００９５】
その後、システムフィルタ基準を個別のセットとして評価することができる。特定の加入者セッションの場合にシステムフィルタ基準に対して一致が見つかると、システムフィルタ基準がピックアップされて適用される。
又、評価順序は、最初に、システムフィルタ基準、次いで、加入者フィルタ基準でもよい。
【００９６】
ピックアップされた両方のフィルタ基準、即ちシステムフィルタ基準セット及び加入者フィルタ基準セットが、同じデータ、例えば、値、パラメーター又は同様のもの（例えば、変数、エントリー、リスト、データ、フィールド、テーブル等）を含む場合には、システムフィルタ基準のデータが加入者フィルタ基準のデータをオーバーライドし、そして加入者フィルタ基準のデータではなく、システムフィルタ基準のデータが適用される。
【００９７】
第２の実施形態は、加入者フィルタ基準がシステムフィルタ基準をオーバーライドするというものである。この実施形態では、Ｓ−ＣＳＣＦ４１２のようなＳ−ＣＳＣＦは、先ず、システムフィルタ基準を評価することができる。特定の加入者セッションの場合にシステムフィルタ基準に対して一致が見つかると、そのシステムフィルタ基準がピックアップされて適用される。
【００９８】
その後、加入者フィルタ基準を個別のセットとして評価することができる。特定の加入者セッションの場合に加入者フィルタ基準に対して一致が見つかると、加入者フィルタ基準がピックアップされて適用される。
又、評価順序は、最初に、加入者フィルタ基準、次いで、システムフィルタ基準でもよい。
【００９９】
ピックアップされた両方のフィルタ基準、即ちシステムフィルタ基準及び加入者フィルタ基準が、同じデータ、例えば、値、パラメーター又は同様のもの（例えば、変数、エントリー、リスト、データ、フィールド、テーブル等）を含む場合には、加入者フィルタ基準のデータがシステムフィルタ基準のデータをオーバーライドし、そしてシステムフィルタ基準のデータではなく、加入者フィルタ基準のデータが適用される。
【０１００】
第３の実施形態では、一般的なプライオリティルールに代わって、個々のプライオリティルールがフィルタ基準において実施され、必要に応じて使用されてもよい。例えば、システムフィルタ基準は、そのデータが加入者フィルタ基準の対応データをオーバーライドするか、又は同じプライオリティをもつ加入者フィルタ基準の対応データによりオーバーライドされるという指示を含んでもよい。或いは又、加入者フィルタ基準は、そのデータがシステムフィルタ基準の対応データをオーバーライドするか、又は同じプライオリティをもつシステムフィルタ基準の対応データによりオーバーライドされるという指示を含んでもよい。
【０１０１】
第４の実施形態では、一般的及び個々のプライオリティルールが組み合わせて使用される。例えば、デフォールトは、システムフィルタ基準又は加入者フィルタ基準において明確に指定されるとき以外、加入者フィルタ基準のデータがシステムフィルタ基準の対応データをオーバーライドする（或いはこれによりオーバーライドされる）というものでよい。
【０１０２】
上記の例では、異なるケース（例えば、発信及び着信）に対して個別のシステムフィルタ基準が存在する場合には、着信加入者フィルタ基準、即ち着信ケースの加入者フィルタ基準に対して、加入者着信フィルタ基準が適用されてもよく、そして着信システムフィルタ基準、即ち着信ケースのシステムフィルタ基準も同様である。
【０１０３】
フィルタ基準を適用するこのようなルールの変更が、異なる実施形態において、ネットワーク要件に基づいて与えられてもよい。このようなルールの種々の組み合わせ及び適応が考えられる。
上記例では、フィルタ基準の本質的な部分しか示されておらず、他の部分は、明瞭化のために省略されている。
【０１０４】
上記例では、システムフィルタ基準及び／又は加入者フィルタ基準が設けられることを説明したが、他の実施形態では、システムフィルタ基準だけを効果的に設けてもよいことに注意されたい。例えば、全ての加入者がプレゼンスサービスに申し込む場合には、加入者フィルタ基準を設ける必要なく、必要なフィルタ基準をシステムフィルタ基準により取り扱うことができる。
【０１０５】
ＵＥ発信のケースでは、図６の例において、ユーザ装置から、Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びアプリケーションサーバーへのルートで、システムフィルタ基準は、ルート記録エントリーをＳ−ＣＳＣＦに挿入して、Ｓ−ＣＳＣＦが発信経路に留まれるようにしなければならないことを定義できる。同時に、システムフィルタ基準は、着信ケースに対してルート記録エントリーを維持する必要がないことも定義できる。
【０１０６】
図４及び５並びに図６及び７を参照して説明した、改善された第２及び第３実施形態は、より一般的にサブスクリプションのルーティングに適用できる。これらは、ルート記録情報をＳ−ＣＳＣＦに保持すべきかどうかの判断を必要とするルーティングのケースに適用できる。
上記実施形態において、ＡＳ、Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦ及びＩ−ＣＳＣＦは、ＳＩＰプロキシーサーバーの例である。
【０１０７】
本発明の幾つかの実施形態を一例として説明した。当業者であれば、本発明がこのような実施形態への適用に限定されないことが明らかであろう。本発明により提供される保護の範囲は、特許請求の範囲に規定する。
【図面の簡単な説明】
【０１０８】
【図１】ＩＥＴＦ（インターネットエンジニアリングタスクフォース）のための第１の実施形態に関するネットワーク筋書きを示す図である。
【図２】ＩＥＴＦに対する第１の実施形態におけるシグナリング構成を示す図である。
【図３】ＩＥＴＦに対する第１の実施形態における方法ステップを示す図である。
【図４】ＩＭＳ（ＩＰマルチメディアサブシステム）に対する第２の実施形態に関連したネットワーク筋書きを示す図である。
【図５】ＩＭＳに対する第２の実施形態におけるシグナリング構成の全体図である。
【図６】第３の実施形態に関するネットワーク筋書きを示す図である。
【図７】第３の実施形態におけるシグナリング構成を示す図である。
【図１】
2006514816.tif 000003
【図２】
2006514816.tif 000004
【図３】
2006514816.tif 000005
【図４】
2006514816.tif 000006
【図５】
2006514816.tif 000007
【図６】
2006514816.tif 000008
【図７−１】
2006514816.tif 000009
【図７−２】
2006514816.tif 000010
【国際調査報告】
2006514816.tif 000011
2006514816.tif 000012
2006514816.tif 000013
2006514816.tif 000014