JP5486078B2 - 通信ネットワーク間ユーザコンテキスト伝送のための方法およびノード - Google Patents

Description

本発明は広く相互運用通信ネットワークの分野、特に異なるネットワーク運用事業者の相互運用通信ネットワーク間でのユーザコンテキストの伝送に関する。

今日、異なる通信ネットワーク間の相互運用性を容易化し、それによって、互いに合意を確立したネットワーク運用事業者が、ネットワーク運用事業者自身の通信ネットワークを介するばかりでなく、他のネットワーク運用事業者の通信ネットワークを介しても、それぞれの加入者によるサービスへのアクセスを可能ならしめる、利用可能な規格が存在する。

図１は従来技術による相互運用を確立することができる２つの通信ネットワークを示す簡単な例図である。第１のネットワーク運用事業者のネットワークである第１の通信ネットワーク１００は、ネットワーク・ツー・ネットワーク・インタフェース（ＮＮＩ、Network to Network Interface）１０２を介して第２のネットワーク運用事業者の第２の通信ネットワーク１０１と相互接続する。両通信ネットワーク１００、１０１は一般にコアノード、アクセスノードおよびゲートウェイノードのような複数の相互接続ネットワークノードを含み、これらのノードは信号を管理し、加入者にサービスを提供するように構成されている。簡単化のため例えば、承認済み加入者へのプレゼンスサービスを提供するためのプレゼンスサーバのようなただそれぞれただ１つのサーバ１０３、１０４およびそれぞれ１つのアクセスノード１０５、１０６を、図１の通信ネットワークのそれぞれに示す。

第１のネットワーク運用事業者の加入者であるユーザＡ１０７はサーバ１０３により提供されるサービスにアクセスするため、または各通信ネットワーク１００、１０１のネットワーク運用事業者が相互に相互運用合意を確立していればＮＮＩ１０２を介してサーバ１０４にアクセスするため、アクセスノード１０５を介して通信ネットワーク１００にアクセスできる。同様の方法で、第２のネットワーク運用事業者の加入者である別のユーザＢ１０８はアクセスノード１０６を介してサーバ１０４並びに１０３にアクセスできる。

とはいえ、加入した場合には、種々のオプションと、ネットワーク運用事業者への加入者の通信ネットワークを介して加入者が利用可能なサービスとを提供する運用事業者は、同じ方法で別の運用事業者の通信ネットワークの加入者を扱う可能性は全くない。これは、この他の通信ネットワークにこれらの加入者、および、それら加入者と加入者自身の運用事業者との合意に関する知識がないことによる。

例として、あるネットワーク運用事業者はその加入者と、その通信ネットワークを介してサービスについて、例えば使用法の様々なレベルを提供する種々のタイプのサービス合意、即ち契約を設定していることがありえる。このネットワーク運用事業者が別のネットワーク運用事業者と相互運用合意を交わしているとすれば、この別のネットワーク運用事業者はこれらの種々の契約タイプに関し何も知りえないであろう。その結果、ネットワーク運用事業者は例えばそれ自体の加入者と作成する種々の取り決めに従いサービス多様化、または加入者の分類を行うことができるが、その一方、別のネットワーク運用事業者と相互運用合意を交わすネットワーク運用事業者は、この別のネットワーク運用事業者の全ての加入者から受信する全ての加入要求を一様な方法で扱わねばならないであろう。

上記課題の少なくとも幾つかに対処し、より詳細には、異なる通信ネットワークのネットワーク運用事業者が、ユーザの固有情報の通信ネットワーク間伝送することを可能にし、２つのネットワーク運用事業者間相互運用合意が両ネットワークで有効であることを可能にすることが本書類の目的である。

一態様によれば、前記第２のネットワーク運用事業者と相互運用合意を確立した第１のネットワーク運用事業者の発信元ネットワークノードにおける加入要求の管理方法を提供し、本方法では第１のネットワーク運用事業者の加入者であるユーザから、またはユーザに代わり発生する受信加入要求にユーザコンテキストを容易に追加できる。第１のネットワーク運用事業者と加入者間の合意を明記しているユーザコンテキストはメモリから入手し、加入要求に追加し、その後加入要求を第２のネットワーク運用事業者の着信ネットワークノードに送信する。

ユーザコンテキストの着信ネットワークノードへの提供により、第２のネットワーク運用事業者によっても合意を加入者に適用するようにユーザコンテキストのコンテンツに少なくとも一部基づき第２のネットワーク運用事業者は加入要求を認可することができよう。

別の態様によれば、第１のネットワーク運用事業者が第２のネットワーク運用事業者と相互運用合意を確立する第２のネットワーク運用事業者の着信ネットワークノードにおいて第１のネットワーク運用事業者の加入者であるユーザから、またはユーザに代わり発生する加入要求の認可方法を提供する。第１のネットワーク運用事業者と加入者間合意を明記しているユーザコンテキストを含む加入要求を第１のネットワーク運用事業者の発信元ネットワークノードから受信する。ユーザコンテキストを蓄積し、従来規則のみならず被送信ユーザコンテキストをも考慮する加入要求の認可により、この合意は第２のネットワーク運用事業者によっても加入者への適用が可能であろう。

さらに別の態様によれば、ユーザコンテキストの考慮下で認可した加入要求に関連する少なくとも１つの動作の実行方法を提供する。そのような実行は被認可加入要求に関連する通知トリガの受信により開始する。一度受信すると、通知トリガの処理は規則に加えて
通知トリガの処理過程で一般に考慮するユーザコンテキストコンテンツに依存するであろう。

ユーザコンテキストは新規ヘッダ、既存ヘッダまたは加入要求本体に追加することができ、加入要求を開始した加入者のユーザ特定情報に依存して一般にユーザコンテキストを選択するであろう。

示唆する方法は種々のタイプの通信ネットワークへの実装に適し、また種々の種類のサービスに適用できる。

示唆する方法に加えて、本発明の請求は発信元ネットワークノードおよび着信ネットワークノードにも関連し、そのそれぞれは示唆する方法の実行に適する。

添付する図面は本発明の例示的実施形態を図示し、本発明の説明と共に本発明の原理の説明に役立つ。

従来技術による２つの相互接続通信ネットワークの簡単な例図である。 例示した一実施形態による通信ネットワーク間ユーザコンテキスト伝送およびこのような被送信コンテキストの使用方法を図示する概要信号方式である。 例示した一実施形態により図３を参照して示唆する方法のプレゼンスの場合への適用可能法を示すシステム構成の簡単な概要例図である。 例示した一実施形態による発信元ネットワークノード構成である。 例示した一実施形態による着信ネットワークノード構成である。

本書類は、第２のネットワーク運用事業者と相互運用合意を交わす第１のネットワーク運用事業者を動作可能にし、種々の加入者が種々の条件下で第１のネットワーク運用事業者の第１の通信ネットワークを介してサービスにアクセスできるようにその加入者を分類し、加入者が第２のネットワーク運用事業者の第２の通信ネットワークを介してこのサービスにアクセスする場合にもこれらの加入者に同じ分類を提供する機構に言及する。

ネットワーク運用事業者の加入者は加入者のネットワーク運用事業者がそのサービスを提供する特定の通信ネットワークに常に属する。そのような通信ネットワークを一般に加入者のホームネットワークと呼ぶ。

上記課題を解決する一般的原理は幾つかの従来通信ネットワークにおいて適用可能な既知の加入／通知機構の修正に基づく。提案する方法の基本的考え方は、以後第１の通信ネットワークと呼ぶ第１のネットワーク運用事業者の通信ネットワークから以後第２の通信ネットワークと呼ぶ第２のネットワーク運用事業者の通信ネットワークへの加入者に関連する分類情報の送信を許容し、第１のネットワーク運用事業者の加入者にこれらのサービスを提供する場合にサービスの区別のため第１の通信ネットワークを介して第１のネットワーク運用事業者によりこれら加入者に行うのと類似した方法で、第２のネットワーク運用事業者にも第２の通信ネットワークにおける転送した分類情報の使用を可能にする方法を規定することである。

提案する方法は既知の加入／通知機構の修正に基づき、この機構は、加入要求により加入者が、または加入者に代わり各サービスを発動し、そして１つ以上の通知として要求されたサービスを加入者に提供するあらゆる状況において、例えばプレゼンスおよびＸＭＬ書類変更の申し込みのような種々のタイプのサービスに適用可能である。

図２は第２の通信ネットワーク２０１と相互接続する第１の通信ネットワーク２００において適用する場合のより詳細な、提案した加入／通知機構の一般的態様を図示する信号方式である。上述したように、第１の通信ネットワーク２００のネットワーク運用事業者が第２の通信ネットワーク２０１のネットワーク運用事業者と相互運用合意を確立していることが前提条件である。

図２を参照して以下に図示することにするように、提案した修正済み加入／通知機構は、加入者のホーム通信ネットワークから第２の通信ネットワークへの、以後ユーザコンテキストと呼ぶ加入者に関連する情報の、加入要求を介した伝送を可能にするであろう。修正加入／通知機構はまた、第２の通信ネットワーク２０１を介して第１の通信ネットワーク２００の加入者がサービスにアクセスしようとする場合に、第２の通信ネットワーク２０１のネットワーク運用事業者にサービス配信の差別化および第１の通信ネットワーク２００の加入者の分類を許容するであろう。

より詳細には、承認のために従来使用された情報に加えて、ユーザコンテキストは加入要求を介して第１の通信ネットワークから第２の通信ネットワークに提供され、第２の通信ネットワークにおいてユーザコンテキストはアクセスされ、加入要求の承認の間に使用される。いったん加入要求が承認されれば、第２の通信ネットワークで承認済みの各加入に関して通知トリガが評価されるたびに通常適用される方針（ポリシ）および規則と共に、承認手順の間に格納したユーザコンテキストもまた第２の通信ネットワークにより考慮される。

第１のステップ２：１では、通信ネットワーク２００のネットワーク運用事業者により提供されるサービスのユーザ、即ちここでユーザＡ２０２と呼び、通信ネットワーク２０２、即ちそのホーム通信ネットワークとして第１の通信ネットワークを持ち、サービスへの加入を望む加入者は、第１の通信ネットワーク２００の、以後発信元ネットワークノード２０３と呼ぶネットワークノードを介して従来手順により生成した加入要求を送信する。そのような発信元ネットワークノードは例えばリソースリストサーバ（ＲＬＳ、Resource List Server）、呼セッション制御機能（ＣＳＣＦ、Call Session Control Function）、ネットワーク・セッション・ボーダ・ゲートウェイ（Ｎ−ＳＢＧ、Network Session Border Gateway）、加入者デバイス、ＳＩＰクライアント、バック・ツー・バック・ユーザ・エージェント（Ｂ２Ｂ ＵＡ、Back-to-Back user agent）、ＳＩＰプロキシまたはウオッチャエージェントの何れかでありうる。

別のステップ２：２では、発信元ネットワークノード２０３は、ユーザＡ２０２に関連するユーザコンテキストを加入要求に付加する。一般に、発信元ネットワークノード２０３により転送され、最終宛先として別の通信ネットワークの通信ネットワークノードを持つ全ての加入要求は、それぞれの加入者に関連するユーザコンテキストと供に提供されるが、ユーザコンテキストを付加する加入要求を選択的に判断するフィルタリングの態様をその代わりに考慮してもよい。

従来の加入要求で通常提供される情報に加えて、別のステップ２：３により示すように、次に付加したユーザコンテキストを含む加入要求を次いで第２の通信ネットワーク２０１の着信ネットワークノード２０４に送信する。以後このような宛先ネットワークノードを着信ネットワークノードと呼ぶことにする。要求されたサービスに依存して、着信ネットワークノードは提案する方法に従う例えばプレゼンスサーバ、通知機、ＳＩＰサーバ、バック・ツー・バック・ユーザ・エージェント（Ｂ２Ｂ ＵＡ）、ＳＩＰプロキシまたはＸＭＬ書類管理サーバ若しくは加入要求処理に適する他の任意のタイプのノードでありうる。

一度着信ネットワークノード２０４により受信すると、別のステップ２：４により示すように、一般に事前に定めた承認規則に対する要求のチェックを含みうる従来手順に従って加入要求を処理する。とはいえ本方法によれば、着信ネットワークノード２０４は承認手順中の入力として、加入要求で提供されるユーザコンテキストも使用することができるであろうし、この付加情報に基づいて、第１の通信ネットワーク２００のユーザＡに通常適用可能な一定の区別または分類を第２の通信ネットワーク２０１でもユーザＡ２０２に適用できる。

図では明確に示していないが承認ステップ２：４の結果に基づき、着信ネットワークノードにより追加的な動作を行いうることを理解すべきである。このような動作は、しかしながらこの書類の範囲外であり、このためさらに詳細には考察しないことにする。

承認のための使用に加えて次のステップ２：５により示すように、加入要求の中から獲得されるユーザコンテキストは、着信ネットワークノード２０４のメモリにまたは着信ネットワークノード２０４によりアクセス可能に蓄積される。これは、通知トリガを着信ネットワークノードが後で受信して処理する場合に何時でも、ユーザコンテキストにアクセスできることを確実にするためである。

着信ネットワークノード２０４により承認に成功すれば、ステップ２：６および後続ステップ２：７により示すように、着信ネットワークノード２０４はユーザＡ２０２への加入応答メッセージ、例えば２００ ＯＫメッセージの転送により、このことをユーザＡ２０２に対して証明する。あるいは加入要求に応答して、加入要求を拒否することを示す加入応答メッセージをユーザＡ２０２に提供できる。

承認済み加入に従い、かつ、事前に定められ、着信ネットワークノード２０４に格納した、あるいはアクセス可能な方針および、以後簡単に規則と呼ぶ規則に従い、着信ネットワークノード２０４は次に第１の通信ネットワーク２００のネットワーク運用事業者により分類されたサービスのユーザＡ２０２への提供に備える。とはいえユーザコンテキストは着信ネットワークノード２０４にもアクセスできるので、承認の間のみならず、承認済み加入に関連して、ステップ２：１で必要な通知トリガをここで通知ソース２０５と呼ぶ別のユーザから、または別のユーザの代表として受信したときには何時でも、この付加情報は考慮されるであろう。

図２の次のステップ２：８により示すように、着信ネットワークノード２０４は要求され、承認された加入に関連する通知トリガをあらゆる段階で受信できる。プレゼンスサービスを適用すれば、そのような通知トリガは例えば通知ソース２０５から受信する公開要求でありえ、一方代わってＸＭＬ書類変更更新を適用すれば通知トリガとしてＸＣＡＰ ＰＵＴを使用できる。そのような通知トリガに応じて、着信ネットワークノード２０４は、以前にステップ２：３で着信ネットワークノード２０４に提供され、ステップ２：５で格納したユーザコンテキストと共に適用可能な規則を適用しよう。そのような手順を後続ステップ２：９により示す。

ステップ２：９の結果として、次いでステップ２：１０で通知を発信元ネットワークノード２０３に転送し、後続ステップ２：１１でユーザＡ２０２に転送する。例えば各タイプの加入に対して事前に定めた期限のような標準的な手順に従って各加入が終了するまで、着信ネットワークノード２０４で受信する後続の通知トリガに応じて、適用可能な規則に従い追加、後続イベントを実行しうる。

ただ１つの着信ネットワークノードおよび１つの通知ソースを図２に示すが、代表的シナリオは、同じ通信ネットワークか若しくは異なる通信ネットワークに位置し得る複数の着信ネットワークノードおよび通知ソースまたはそのいずれかを含んでもよいことを理解すべきである。そのような場合には、ステップ２：１に示した１つの加入要求は、１つ以上の着信ネットワークノードに送信される、ステップ２：３に示した複数の加入要求を結果として生じる可能性がある。各加入要求は、反復されるステップ２：２で各加入要求に付加されたユーザコンテキストを含んでいる。その結果、ステップ２：４乃至ステップ２：７により示すように、複数の加入要求は複数の承認、格納および応答ステップを結果として生じるであろう。

上記方法が適用可能でありうる特定サービス、即ちプレゼンスサービスは、次に図３を参照して被要求加入認可実行の代表的シナリオを例示することにする。

この特定例で、第１のＩＭＳネットワーク３００を管理する第１の運用事業者Ｘはその加入者に異なる加入であるゴールド加入、シルバー加入およびブロンズ加入を提供し、ゴールド加入はシルバーおよびブロンズ加入より高度なサービスをその加入者に提供しうるとする。本例では、また一般にウオッチャ３０２と呼ぶ加入者が運用事業者Ｘとシルバー加入の設定を選択し、運用事業者Ｘと、別のＩＭＳネットワーク３０１を管理する別の運用事業者Ｙとが相互運用合意を有し、運用事業者Ｙは例えば運用事業者Ｘのゴールド加入者にフルサービスを提供でき、一方若干制限のあるサービスをシルバー加入者に提供し、さらに限定した契約をブロンズ加入者に適用することを仮定する。

第１のステップ３：１で、ウオッチャ３０２は運用事業者ＸのＩＭＳ加入者であり、そのプレゼンスリストへの加入を望み、ＩＭＳネットワーク３００のＲＬＳ３０３に加入要求を送信する。ＲＬＳ３０３はＲＬＳ ＸＤＭＳ３０４の起動およびウオッチャ３０２のプレゼンスリスト３０５の決定によりこのような要求に応じる。これをステップ３：２により示す。起動／決定ステップに基づき、ＲＬＳ３０３はプレゼンスリスト３０５の全てのコンタクト先にプレゼンス加入要求を送出する。とはいえプレゼンス加入要求の送信前に、ウオッチャ３０２に関連する、事前に定められたユーザコンテキストを各要求に付加する。このような手順を図３のステップ３：３により示す。

本例で、ユーザコンテキストは例えば情報「シルバー」を含むことができ、この情報を加入要求に導入した例えば新規のヘッダに付加してもよい。あるいはユーザコンテキストは加入要求の既存のヘッダに例えば１つ以上のパラメータとして付加してもよい。さらなる代替として、ユーザコンテキストは代わって加入要求の本体に付加してもよい。

ＩＭＳネットワーク３０１のプレゼンスサーバ（ＰＳ、Presence Server）３０６に宛てるこの送信は図３のステップ３：４により示す。以上に示すように、代表的シナリオは複数の加入要求の１つ以上のプレゼンスリストのコンタクト先への送信を含みうる。簡単化のため、図３は１つのこのような送信のみを図示する。

いったんＰＳ３０６が加入要求を受信すると、ステップ３：５により示すようにユーザコンテキストをメモリに格納し、その通常の承認方針／規則に基づくのみならず、加入要求で提供するユーザコンテキストをも考慮して、加入要求を承認する。そのプレゼンスＸＤＭＳ３０７をチェックし、ＰＳ３０６により一般的に実行するこのような承認を次のステップ３：６により示す。この章にステップの結果をステップ３：７により示すようにＲＬＳ３０３に送信し、ここからこの結果を次いで最終ステップ３：８により示すようにウオッチャ３０２に転送する。

いったん２つのネットワーク運用事業者間で加入が設定されると、その加入が終了するまで、各サービス（この場合にはプレゼンス）に適用される加入に従って、ウオッチャ３０２は通知を受信できるであろう。

例として、運用事業者Ｙは、全てのそのシルバー加入者およびブロンズ加入者が例えば時間当たり最大１つの通知という通知速度の制限を有する一方、全てのゴールド加入者は何ら速度制限なく通知を受信するという方針を事前に規定していたとする。

ユーザが運用事業者に設定した特定タイプの加入に適用されるべき一般的ユーザコンテキスト、または運用事業者により提供されるサービスに対してサービスベースで区別されるべき一般的ユーザコンテキストとして、ユーザコンテキストを規定しておくことができる。後者の場合、プレゼンスに関連した加入を要求するユーザに例えばゴールド加入を提供しうるが、一方シルバー加入は他の任意のタイプの加入／通知サービスに関連した加入に提供する。

図４を参照して以下に例示するように、発信元ネットワークノード２０３は機能ユニットにより構成できる。図４の発信元ネットワークノード２０３はここで要求処理ユニット４００と呼ぶユニットを含み、ノードにより受信する各加入要求へのユーザコンテキストの付加を担当する。第１のネットワーク運用事業者の加入者であるユーザから発する、またはそのユーザを代表する加入要求を発信元ネットワークノード２０３の受信機４０１が受信したときは何時でも、要求処理ノード４００はそのときを認識するように構成される。要求処理ユニット４００はさらにメモリ４０２からユーザコンテキストを選択し、選択済みユーザコンテキストを加入要求に付加するように構成される。各加入者と加入者のネットワーク運用事業者間の合意が記述され、メモリ４０２に事前に格納されているユーザコンテキストは、加入者のユーザ特定情報に基づいて要求処理ユニット４００により選択できる。いったんユーザコンテキストを加入要求に付加すると、以上の例の何れかで示す如く、第２のネットワーク運用事業者の着信ネットワークノードに加入要求を送信できるように、要求処理ユニット４００は送信機４０３と相互動作するように構成される。

図５を参照して一例示実施形態による着信ネットワークノード２０４を次に以下でさらに詳細に説明することにする。図５の着信ネットワークノード２０４は、着信ネットワークノード２０４の受信機５０１により着信ネットワークノード２０４の加入要求を受信したことを認識するように構成した、処理ユニット５００と呼ばれるユニットを含む。処理ユニット５００はまた、加入要求がユーザコンテキストを含むことを認識し、ユーザコンテキストをメモリ５０２に格納し、このタイプの承認手順の過程で通常考慮する他の情報に加えてユーザコンテキストを考慮する承認手順を実行するように構成される。

処理ユニット５００はまた、当初加入要求により開始したサービスに関連する種々の動作の開始に通常使用するトリガを処理するように構成される。従来の加入／通知機構に従って、通知トリガの受信に応じて、処理ユニット５００は任意のタイプの事前に規定した規則を適用するように構成される。メモリ５０２または（図示しない）別のメモリ手段に格納しうる事前に規定した規則の考慮に加えて、処理ユニット５００はまた、メモリ５０２に予め格納したユーザコンテキストを考慮するようにも構成される。規則及びユーザコンテキストの考慮の結果に依存して、処理ユニット５００は送信機５０３を介して送信するように構成されている通知を生成しうる。

上記発信元ネットワークノード並びに着信ネットワークノードは上記方法の実行に適するような各ノードの構成に関する１つの代替手法を示すに過ぎず、提案した加入／通知機構、即ち以上の例示で説明した方法のステップの実装を可能にする他の構成が可能であろうことを理解すべきである。また、従来通信ネットワークにおける加入要求および関連通知の処理に通常必要であるが、提案した方法および関連するネットワークノードの理解に必要でないステップ並びに機能ユニットは簡単化のためこの書類では省略したことを理解すべきである。そのような各方法のステップおよび／または機能ユニットは所与の例で参照する対応する方法のステップおよび機能ユニットと協同して使用できるように任意の従来教示に従い容易に実装できる。

略語
ＣＳＣＦ Call Session Control Function（呼セッション制御機能）
ＲＬＳ Resource List Server（リソースリストサーバ）
ＮＮＩ Network to Network Interface（ネットワーク・ツー・ネットワーク・インタフェース）
Ｎ−ＳＢＧ Network Session Border Gateway（ネットワーク・セッション・ボーダ・ゲートウェイ）

Claims (22)

1. 第１のネットワーク運用事業者の発信元ネットワークノードにおける加入要求の管理方法であって、
   前記第１のネットワーク運用事業者の加入者であるユーザから発した、前記ユーザが加入していない第２のネットワーク運用事業者に対する加入要求を受信するステップと、
   前記第１のネットワーク運用事業者と前記加入者との間の合意を記述してあるユーザコンテキストを、前記加入要求に付加するステップと、
   前記第１のネットワーク運用事業者が相互運用合意を確立している前記第２のネットワーク運用事業者の着信ネットワークノードに前記加入要求を送信するステップとを含み、
   前記３つのステップを含むことにより、前記第２のネットワーク運用事業者によっても前記合意を前記加入者に適用するように、前記ユーザコンテキストの内容の少なくとも一部に基づいて前記第２のネットワーク運用事業者が前記加入要求を承認することを可能にすることを特徴とする方法。
2. 第１のネットワーク運用事業者の加入者であるユーザから発する、前記ユーザが加入していない第２のネットワーク運用事業者に対する加入要求の承認方法であって、前記方法は、前記第１のネットワーク運用事業者が相互運用合意を確立した前記第２のネットワーク運用事業者の着信ネットワークノードにおいて実行される、
   前記第１のネットワーク運用事業者の発信元ネットワークノードから前記第１のネットワーク運用事業者と前記加入者との間の合意を記述してあるユーザコンテキストを含む加入要求を受信するステップと、
   前記ユーザコンテキストを格納するステップと、
   前記第２のネットワーク運用事業者によっても前記合意を前記加入者に適用するように、前記ユーザコンテキストの少なくとも一部に基づいて前記加入要求を承認するステップと
   を含むことを特徴とする方法。
3. 前記ユーザコンテキストが、前記加入者に対して事前に規定したユーザ特定情報を含むことを特徴とする請求項１または請求項２に記載の方法。
4. 前記ユーザコンテキストが、加入ベースで有効なユーザ特定情報を含むことを特徴とする請求項１または請求項２または請求項３に記載の方法。
5. 前記ユーザコンテキストが、サービスベースで有効なユーザ特定情報を含むことを特徴とする請求項１または請求項２または請求項３に記載の方法。
6. 前記加入要求が、プレゼンスサービス要求またはＸＭＬ書類変更への加入であることを特徴とする請求項５に記載の方法。
7. 前記付加するステップの間に、前記ユーザコンテキストを前記加入要求ヘッダに付加することを特徴とする請求項１乃至請求項６の何れか一項に記載の方法。
8. 前記付加するステップの間に、前記ユーザコンテキストを１つ以上のユーザコンテキストパラメータとして前記ヘッダに付加することを特徴とする請求項７に記載の方法。
9. 前記付加するステップの間に、前記ユーザコンテキストを前記加入要求の本体に付加することを特徴とする請求項１乃至請求項６の何れか一項に記載の方法。
10. 請求項２乃至請求項８の何れか一項に従い承認した加入要求に関連する少なくとも１つの動作の実行方法であって、
    前記承認済み加入要求に関連する通知トリガを受信するステップと、
    前記ユーザコンテキストの内容の少なくとも一部に依存して前記通知トリガを処理するステップと
    を含むことを特徴とする方法。
11. 前記少なくとも１つの動作が前記発信元ネットワークノードへの通知を生成し、送信するステップを含むことを特徴とする請求項１０に記載の方法。
12. 加入要求を管理する第１のネットワーク運用事業者の発信元ネットワークノードであって、
    受信機、送信機およびメモリに、動作可能なように接続された要求処理ユニットを含み、
    前記要求処理ユニットが、
    前記第１のネットワーク運用事業者の加入者であるユーザから発する、前記ユーザが加入していない第２のネットワーク運用事業者に対する加入要求を前記受信機により受信したことを認識し、
    前記第１のネットワーク運用事業者と前記加入者との間の合意を記述してある、前記メモリに格納されている前記ユーザコンテキストを前記加入要求に付加し、
    前記第１のネットワーク運用事業者が相互運用合意を有する前記第２のネットワーク運用事業者の着信ネットワークノードに前記加入要求を送信するように前記送信機と相互動作し、それによって前記第２のネットワーク運用事業者によっても前記合意を前記加入者に適用可能とするように構成されることを特徴とする発信元ネットワークノード。
13. 前記発信元ネットワークノードがコアネットワークノードであることを特徴とする請求項１２に記載の発信元ネットワークノード。
14. 前記発信元ネットワークノードが、加入者デバイス、またはＳＩＰクライアント、バック・ツー・バック・ユーザ・エージェント、ＳＩＰプロキシ、リソースリストサーバ、ウオッチャエージェント、呼セッション制御機能、ネットワーク・セッション・ボーダ・ゲートウェイの何れかであることを特徴とする請求項１２または請求項１３に記載の発信元ネットワークノード。
15. 前記要求処理ユニットが、前記ユーザコンテキストを前記加入要求のヘッダに付加するように構成されることを特徴とする請求項１２または請求項１３または請求項１４に記載の発信元ネットワークノード。
16. 前記要求処理ユニットが、前記加入要求のヘッダの少なくとも１つのパラメータとして前記ユーザコンテキストを付加するように構成されることを特徴とする請求項１５に記載の発信元ネットワークノード。
17. 前記要求処理ユニットが、前記加入要求の本体に前記ユーザコンテキストを付加するように構成されることを特徴とする請求項１２乃至請求項１４の何れか一項に記載の発信元ネットワークノード。
18. 前記要求処理ユニットが、前記加入者のユーザ特定情報に基づいて前記加入要求に付加すべきユーザコンテキストを選択するように構成されることを特徴とする請求項１２乃至請求項１７の何れか一項に記載の発信元ネットワークノード。
19. 第１のネットワーク運用事業者の加入者であるユーザから発する、前記ユーザが加入していない第２のネットワーク運用事業者に対する加入要求を承認する、前記第２のネットワーク運用事業者のネットワークノードである着信ネットワークノードであって、
    メモリおよび受信機に、動作可能なように接続された処理ユニットを含み、
    前記処理ユニットが、
    前記前記第１のネットワーク運用事業者の加入者であるユーザから発する加入要求を前記受信機により受信したことを認識し、
    前記加入要求内において、前記第１のネットワーク運用事業者と前記加入者間との合意を記述してあるユーザコンテキストを前記加入要求に対して認識し、前記ユーザコンテキストをメモリに格納し、
    前記ユーザコンテキストを考慮することを含む承認手順を実行し、それによって前記第２のネットワーク運用事業者によっても前記合意を前記加入者に適用可能とするように構成されることを特徴とする着信ネットワークノード。
20. 前記着信ネットワークノードが、プレゼンスサーバ、または通知機、ＳＩＰサーバ、バック・ツー・バック・ユーザ・エージェント、ＳＩＰプロキシ、ＸＭＬ書類管理サーバの何れかであることを特徴とする請求項１９に記載の着信ネットワークノード。
21. 前記処理ユニットはさらに承認済み加入要求に関連する少なくとも１つの動作を実行するように構成され、
    前記処理ユニットがさらに、
    前記承認済み加入要求に関連する通知トリガを受信し、
    前記ユーザコンテキストの内容の少なくとも一部に依存して前記通知トリガを処理するように構成されることを特徴とする請求項１９または請求項２０に記載の着信ネットワークノード。
22. 前記第１のネットワーク運用事業者および前記第２のネットワーク運用事業者がそれぞれのＩＭＳネットワークの運用事業者であることを特徴とする請求項１９乃至請求項２１の何れか一項に記載の着信ネットワークノード。

Images