JP2012532476A - ユーザデータ・コンバージェンス（ｕｄｃ）通知の管理 - Google Patents

Abstract

イベント通知を受信する、通信ネットワーク内のアプリケーション・フロントエンド（34a〜34e）を選択するための、ユーザデータ・リポジトリ（ＵＤＲ）（30）における方法及び装置を提供する。関連するアプリケーション・タイプと、当該通信ネットワークに含まれるアクセス可能な部分を識別するグループ識別子とが、複数のアプリケーション・フロントエンドのそれぞれについてデータベース（88）に保存される。当該グループ識別子は、所定の条件（87）が満たされた場合、例えば、ユーザデータを修正するＵＤＲリクエストの場合に、データベース内で更新されうる。その後のイベント通知手続が開始されると、ＵＤＲ（30）は、選択されるアプリケーションＦＥのアプリケーション・タイプ及びグループ識別子に基づいて、イベント通知を受信するアプリケーションＦＥを選択する。複数のアプリケーションＦＥのそれぞれに対して負荷分散重みが割り当てられてもよく、当該選択プロセスにおいて当該負荷分散重みが考慮されてもよい。

Description

本出願は、２００９年６月１１日に提出された米国仮出願６１／１８６，２４０号の優先権を主張するものである。

本発明は、全体として通信ネットワークに関するものであり、具体的には、通信ネットワークにおけるユーザデータ・リポジトリ（ＵＤＲ：User Data Repository）と複数のアプリケーション・フロントエンド（アプリケーションＦＥ：Application Front End）との間のユーザデータ・コンバージェンス（ＵＤＣ：User Data Convergence）通知を管理するためのシステム及び方法に関するものである。

ユーザデータ・コンバージェンス（ＵＤＣ）は、現在、第３世代パートナシップ・プロジェクト（３ＧＰＰ）によって開発されている。技術仕様３ＧＰＰ ＴＳ ２３．３５５では、ＵＤＣの技術的な実現について説明されており、ＵＤＣは、異なる複数のネットワーク・エレメントのアプリケーション・ロジックからユーザデータを分離する。ユーザデータ・リポジトリ（ＵＤＲ）は、集中型データベースを提供し、当該データベースは、異なる複数のアプリケーションＦＥによってアクセスされる。

図１は、一般的なＵＤＣアーキテクチャ１０の簡略化したブロック図である。ユーザデータは、ＵＤＲ１１に保存される。アプリケーション・フロントエンド（ＦＥ）１２ａ〜１２ｃは、データ無しの機能的なエンティティである。アプリケーションＦＥは、ホーム・ロケーション・レジスタ（ＨＬＲ）、ホーム加入者サーバ（ＨＳＳ）、認証センタ（ＡＵＳ）、アプリケーション・サーバ（ＡＳ）、プロビジョニング・システム等の、機能的なネットワーク・エンティティのアプリケーション・ロジックを保持するが、局所的に、ユーザデータを恒久的には保存することがない。アプリケーションＦＥは、１つ以上のアプリケーションを同時に処理しうる。ＵＤＣアーキテクチャは、ダイアメータ（Diameter）、モバイル・アプリケーション・プロトコル（ＭＡＰ）、セッション確立プロトコル（ＳＩＰ）、またはその他の適切なプロトコル等の、プロトコル１４を介して、コアネットワーク、サービス・レイヤ、及びオペレーション・サポート・システム（ＯＳＳ）１３とのインタフェースとして機能する。ＵＤＣの実装の要求条件は、既存のネットワークに対する影響を最小限にすることである。

図２は、ＵＤＲ１１が、複数のＨＬＲ−ＦＥ２２ａ〜２２ｅとして実装されている複数のアプリケーションＦＥのためのユーザデータを提供する、ＵＤＣアーキテクチャの簡略化したブロック図である。複数のＨＬＲ−ＦＥは、同様に、複数のＭＳＣ／ＶＬＲ２２ａ〜２２ｅをサポートする。同図から明らかなように、各アプリケーションＦＥは、「フロントエンド識別子」として通常知られている個別の識別子を用いて構成されており、当該識別子は、当該アーキテクチャに含まれる他のエンティティとの通信を確立するために使用される。ＵＤＲと複数のＨＬＲ−ＦＥとの間のインタフェース２３は、ＵＤＲ内の特定のユーザデータに対して起こりうる特定のイベントについて、関連のあるＨＬＲ−ＦＥにＵＤＲが通知することを可能にする通知機能をサポートしている。当該イベントは、既存のユーザデータに対する変更、ユーザデータに対する追加等であってもよい。コアネットワーク及びサービス・レイヤ・アプリケーションは、これらの通知を明示的に予約（subscribe）してもよい。例えば、（アプリケーションＦＥの一例としての）ＡＳは、特定のユーザデータに対する変更情報を受信することを予約してもよい。あるいは、コアネットワーク及びサービス・レイヤ・アプリケーションは、ＵＤＣコンセプトに従った通知を黙示的に予約してもよい。例えば、ユーザが位置しているという通知とその位置情報は、管理上で削除されてもよい。

「ＨＬＲ」等の特定のアプリケーション・タイプの任意のアプリケーションＦＥは、当該アプリケーション・タイプに関連するコアネットワーク／サービス・レイヤ／ＯＳＳ内のエレメントのいずれかに対する通知を処理するのに適していることが想定されている。このため、図２では、ＵＤＲ１１が任意のＨＬＲ−ＦＥ２１ａ〜２１ｃに、ユーザデータの変更を通知可能であり、また、通知を受けたＨＬＲ−ＦＥが、条件（例えば、ユーザの地理的位置）を問わず、ＭＳＣ／ＶＬＲ２２ａ〜２２ｃのいずれかに通知可能であることが想定されている。したがって、ＵＤＲが、特定のＨＬＲ−ＦＥに通知を送信することを懸念することはない。

しかし、大規模なネットワークを有するオペレータによっては、例えば複数の信号中継局（ＳＴＰ：Signaling Transfer Point）によって接続された複数のエリアネットワークに、ネットワーク全体が分割されているルーティング階層を利用する可能性がある。このネットワーク構成では、第１のエリアネットワーク内のＨＬＲ−ＦＥは、第２のエリアネットワーク内のＭＳＣ／ＶＬＲに対する「直接の」シグナリング・コネクションを有しない可能性がある一方で、１つ以上のＳＴＰを通じてシグナリングがルーティングされる「間接の」コネクションを有する可能性がある。また、通信ネットワークにおいて全てのノードを相互にメッシュ状にすることは、通常、複雑かつ高価な開発を必要とすることを考慮すると、例えば他の地理的位置のエリア内の全てのＭＳＣ／ＶＬＲとのシグナリング・コネクションをＨＬＲ−ＦＥが有しえないことが生じる可能性がある。このため、特定のＭＳＣ／ＶＬＲに対して影響を与えるデータの変更について、ＵＤＲは、影響を受ける当該ＭＳＣ／ＶＬＲに到達することができないＨＬＲ−ＦＥを当該ＵＤＲが選択することがないように、ＨＬＲ−ＦＥの選択を管理しなければならない。

この課題を解決するための３ＧＰＰにおいて規定された仕組みは、現時点では存在しない。これは、定義された全てのエリアネットワークに全てのアプリケーションＦＥが到達することが想定されていないためである。現在の仕様では、ＵＬＲは、ユーザによらず、かつ、当該ユーザの「位置」によらず、任意のアプリケーションＦＥを選択して、データ変更の通知を送信（例えば、プロビジョニング）する。したがって、ＵＤＲは、通知を必要としているネットワーク・エレメントに対して当該通知を提供することができないアプリケーションＦＥに、当該通知を送信する可能性がある。本発明は、ＵＤＲと複数のアプリケーションＦＥとの間のＵＤＣ通知を管理するための方法及び装置を提供することで、この課題を解決する。

一実施形態において、本発明は、通信ネットワーク内の複数のアプリケーションＦＥから、イベント通知を受信するアプリケーションＦＥを選択するための、ＵＤＲにおける方法を対象としている。本方法は、複数のアプリケーションＦＥのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベースに追加するステップを含み、各グループ識別子は、関連付けられたアプリケーションＦＥを介してアクセス可能な、通信ネットワークに含まれる異なる部分を識別する。本方法は、更に、その後、特定のユーザのユーザデータの変更を報告するためのイベント通知手続を開始するステップと、選択されるアプリケーションＦＥのアプリケーション・タイプ及びグループ識別子に基づいて、イベント通知を受信するアプリケーションＦＥを選択するステップとを含む。複数のアプリケーションＦＥのうちの１つからＵＤＲ操作リクエストが受信された際に、当該複数のアプリケーションＦＥのそれぞれについてのアプリケーション・タイプ及びグループ識別子を保存することによって、データベースに追加されてもよい。所与のアプリケーションＦＥについてのグループ識別子は、所定の条件が満たされた場合にデータベース内で更新されてもよい。

任意的に、本方法は、複数のアプリケーションＦＥのそれぞれに、負荷分散重みを割り当てるステップと、さらに、割り当てられている負荷分散重みを、アプリケーションＦＥの選択の基礎とするステップとを含んでいてもよい。

別の実施形態において、本発明は、通信ネットワーク内の複数のアプリケーションＦＥから、イベント通知を受信するアプリケーションＦＥを選択するための、ＵＤＲにおける装置を対象としうる。本装置は、複数のアプリケーションＦＥのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベースに追加する手段であって、各グループ識別子は、関連付けられたアプリケーションＦＥを介してアクセス可能な、通信ネットワークに含まれる異なる部分を識別する、追加する手段と、その後、特定のユーザのユーザデータの変更を報告するために、イベント通知手続を開始する手段と、選択されるアプリケーションＦＥのアプリケーション・タイプ及びグループ識別子に基づいて、イベント通知を受信するアプリケーションＦＥを選択する手段とを備える。データベースに追加する手段は、複数のアプリケーションＦＥのうちの１つからＵＤＲ操作リクエストが受信された際に、当該複数のアプリケーションＦＥのそれぞれについてのアプリケーション・タイプ及びグループ識別子を保存してもよい。所与のアプリケーションＦＥについてのグループ識別子は、所定の条件が満たされた場合にデータベース内で更新されてもよい。

任意的に、イベント通知を受信するアプリケーションＦＥを選択する手段は、複数のアプリケーションＦＥのそれぞれに割り当てられた負荷分散重みに基づいて、アプリケーションＦＥを選択してもよく、所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みが当該所与のアプリケーションＦＥに割り当てられており、当該所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みが当該所与のアプリケーションＦＥに割り当てられている。

本発明は、ＵＤＲ通知に関連した目的で、ネットワーク・トコポジの考察を有利に考慮する。本発明は、全てのコアネットワーク・エレメントが、関連する（１つまたは複数の）全てのアプリケーションＦＥに接続されているとは限らない配置を対象とする。本発明は、グループＩＤ及び負荷分散重みを使用することによって、ＵＤＲ通知に関連した負荷分散メカニズムについての柔軟性を提供する。その結果、当該通知に関連した負荷が、それに応じて分散されうる。本発明は、ＵＤＲ通知に関連した目的で、拡張性のあるソリューションも提供する。これは、関連するグループＩＤのＵＤＲ設定の修正のみが、より多くのアプリケーションＦＥを追加するために必要とされるためである。最後に、本発明は、ＵＤＲ通知に関連した目的で、耐障害性ソリューションを提供する。これは、通知を発行するために特定のグループＩＤ値を共有する全てのアプリケーションＦＥの中からＵＤＲが選択できるためである。

一般的なＵＤＲアーキテクチャについての簡略化したブロック図である。 ＵＤＲが、ＨＬＲ−ＦＥとして実装される複数のＦＥのためのユーザデータを提供する、ＵＤＲアーキテクチャについての簡略化したブロック図である。 本発明を実装するのに適したＵＤＲアーキテクチャについての簡略化したブロック図である。 ＵＤＲ操作がリクエストされた際に、グループＩＤ属性を更新するか否かを決定する方法の一実施形態に含まれるステップを示すフローチャートである。 オペレータが、異なるＳ−ＣＳＣＦベンダを有するＵＤＲアーキテクチャについての簡略化したブロック図である。 本発明の一実施形態における、ユーザの登録及び登録解除を行う方法を示す信号フロー図である。 本発明の教示に従って修正されたユーザデータ・リポジトリ（ＵＤＲ）についての簡略化したブロック図である。 本発明の方法の例示的な実施形態についてのステップを示すフローチャートである。

図３は、本発明を実装するのに適したＵＤＲアーキテクチャについての簡略化したブロック図である。オペレータのネットワーク全体は、信号中継局（ＳＴＰ１）３３によって接続された、第１のエリアネットワーク（エリアネットワーク１）３１と第２のエリアネットワーク（エリアネットワーク２）３２とに分割される。このネットワーク構成において、修正されたＵＤＲ３０は、ＨＬＲ−ＦＥ３４ａ〜３４ｅとして実装される複数のアプリケーションＦＥのためのユーザデータを提供する。同様に、ＨＬＲ−ＦＥは、複数のＭＳＶ／ＶＬＲ３５ａ〜３５ｅをサポートする。しかし、ＨＬＲ−ＦＥの全てが、全てのＭＳＣ／ＶＬＲに到達できるわけではない。例えば、エリアネットワーク２内に位置するＨＬＲ−ＦＥ５は、エリアネットワーク１内に位置するＭＳＣ／ＶＬＲ１またはＭＳＣ／ＶＬＲ２に、到達することができない。その他のいくつかの場合において、いくつかのＨＬＲ−ＦＥは、ＳＴＰ１を介してのみ、間接的にＭＳＣ／ＶＬＲに到達することができる。例えば、エリアネットワーク２内に位置するＨＬＲ−ＦＥ３は、ＳＴＰ１を介してのみ、エリアネットワーク１内に位置するＭＳＣ／ＶＬＲ１に到達することができる。これらの場合、たとえアクセスが可能であっても、オペレータは、最短のパスを使用してＭＳＣ／ＶＬＲ１に到達することを望むこともありうる。例えば、ＨＬＲ−ＦＥ３は、ＭＳＣ／ＶＬＲ１に到達するためには最良の選択ではない可能性がある。これは、ＨＬＲ−ＦＥ１またはＨＬＲ−ＦＥ２からの「直接の」パスが、ＳＴＰを介したルーティング・シグナリングを全く必要とせず、より適切であるためである。

適切なＭＳＣ／ＶＬＲに通知を確実に到達させるため、及び、最適なパスが確実に利用されるようにするため、ＵＤＲは、発行された通知をどこに送信するのかを決定する際に、ルーティングの決定を行わなければならない。例えば、回線交換／パケット交換（ＣＳ／ＰＳ）ユーザがエリアネットワーク１内に位置するＭＳＣ／ＶＬＲによって管理される予定であることコアネットワークが決定する場合には、「マップ位置更新（MAP Location Update）」操作情報が、（通常の場合）ＭＳＣ／ＶＬＲ１またはＭＳＣ／ＶＬＲ２から、ＨＬＲ−ＦＥ１またはＨＬＲ−ＦＥ２に向かって送信される。その後、ＵＤＲは、このユーザについてのＨＬＲ関連通知（HLR-related notification）を送信する必要がありうる。例えば、このユーザについてのＣＳ／ＰＳ関連属性（CS/PS-related attribute）が、プロビジョニング・エンティティによってＵＤＲにおいて変更されており、この新たなデータは、このユーザの「ホスティング」を現在行っているＭＳＣ／ＶＬＲエレメントにおいて更新される必要がある。この場合、ＭＳＣ／ＶＬＲ１またはＭＳＣ／ＶＬＲ２へ通知を配信するためには、ＨＬＲ−ＦＥ１またはＨＬＲ−ＦＥ２を選択することが、ＵＤＲにとっての最適な選択であろう。このＵＤＲ通知によってトリガされる最終的なＭＡＰ操作情報がＳＴＰ１を介してＭＳＣ／ＶＬＲ１またはＭＳＣ／ＶＬＲ２に到達しなければならないため、ＨＬＲ−ＦＥ３またはＨＬＲ−ＦＥ４は最適な選択ではなく、遅延の理由から望ましくないであろう。なお、ＵＤＲは、このＣＳ／ＰＳユーザ関連通知を、ＨＬＲ−ＦＥ５に対して送信してはならない。これは、ＨＬＲ−ＦＥ５が、ＳＴＰ１に対するコネクションを有しておらず、それ故に、エリアネットワーク１内に位置するいずれのＭＳＣ／ＶＬＲに対しても到達する方法を有していないためである。

本発明は、オペレータのネットワーク内のアプリケーションＦＥを設定するための新たなパラメータを導入する。ＵＤＲ３０に保存される追加的な情報は、例えばあるユーザのデータが修正された際に発行される通知の送信先となる、適切な（１つまたは複数の）アプリケーションＦＥをＵＤＲが選択することを可能にする。

３ＧＰＰ ＴＳ ２３．３３５によれば、オペレータのネットワーク内の各アプリケーションＦＥは、そのアプリケーション・タイプ（Application Type）（例えば、ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ、ＡｐｐＴｙｐｅ＝ＨＳＳ−ＦＥ等）を定義するように設定されている。本発明は、さらに、ＵＤＲにおける新たなパラメータ、即ち、アプリケーションＦＥがサービスを行う「（１つまたは複数の）エリアネットワーク」に関連付けられた「グループ識別子」（グループＩＤ：GroupId）を用いてアプリケーションＦＥを設定する。特定のアプリケーションＦＥが、１つ以上のエリアネットワークにサービスを行う場合、当該特定のアプリケーションＦＥは、サービスが行われる各エリアネットワークに対応するグループＩＤを用いて、ＵＤＲにおいて設定される。例えば、図３のＨＬＲ−ＦＥ３は、エリアネットワーク２に属するように設定されるが、エリアネットワーク１に属するようにも設定されうる。これは、ＨＬＲ−ＦＥ３が、エリアネットワーク１内のＭＳＣ／ＶＬＲに、ＳＴＰ１（３３）を介して間接的に接続可能であるためである。

一例として、全てのＨＬＲ−ＦＥが、「ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ」（全てについて同一のＡｐｐＴｙｐｅ値）を用いて設定されうるとともに、それらは「エリアネットワーク」においてグループ化されうる。このため、同一のエリアネットワーク内に配置された全てのＨＬＲ−ＦＥは、同一のグループＩＤ値を共有し、当該グループＩＤ値は、当該エリアネットワークに割り当てられる。この情報は、ＵＤＲ内に保存されてもよいし、または、ＵＤＲがアクセス可能なデータベース内に保存されてもよい。ＨＬＲ−ＦＥが、取り出し／更新リクエスト（本明細書では、共通して「ＵＤＲ操作リクエスト」と称する。）をＵＤＲへ送信する場合、ＵＤＲは、当該リクエストから、当該リクエスト中のＨＬＲ−ＦＥに関連付けられたＡｐｐＴｙｐｅ値およびグループＩＤ値を得ることができる。好ましくは、特定のアプリケーションＦＥのアプリケーション・タイプ（ＡｐｐＴｙｐｅ）は、フロントエンド識別子から、またはそれに対応するグループ識別子（グループＩＤ）から得られることが好ましい。

これは、ＬＤＡＰがＵＤＲデータアクセス・インタフェースである場合には、それぞれが特定のＡｐｐＴｙｐｅ値及び特定のグループＩＤ値を有する、種々の「ディレクトリアクセス認証情報（credentials）」エントリを定義することによって達成されうる。同一の「ディレクトリアクセス認証情報」エントリを使用してＬＤＡＰセッションを確立する全てのＨＬＲ−ＦＥは、同一のＡｐｐＴｙｐｅ及び同一のグループＩＤを共有する。

ＭＳＣ／ＶＬＲが、選択されたＨＬＲ−ＦＥを介してＣＳ／ＰＳユーザデータの取り出し／更新をリクエストする場合、または、Ｓ−ＣＳＣＦが、選択されたＨＳＳ−ＦＥを介してＩＭＳユーザデータの取り出し／更新をリクエストする場合、当該選択されたＨＬＲ−ＦＥまたはＨＳＳ−ＦＥは、ＵＤＲにアクセスして、いわゆるＵＤＲ操作リクエスト（例えば、ＬＤＡＰ操作）によってＣＳ／ＰＳユーザ関連データの取り出し／更新を行う。ＵＤＲは、このリクエストされた操作を確認するとともに、関係するＡｐｐＴｙｐｅに対応する選択されたＨＬＲ−ＦＥまたはＨＳＳ−ＦＥに関連付けられた（１つまたは複数の）グループＩＤ値が、ユーザレベルで（即ち、ＵＤＲによってユーザとの関係で保持されているデータの一部として）保存されているか否かを判定する。例えば、特定のユーザについての「ＣＳ位置データ」の更新（即ち、当該ユーザを現在管理しているＭＳＣ／ＶＬＲエンティティを保存しているユーザ属性の更新）を行うために、ＨＬＲ−ＦＥがＵＤＲに対して操作をリクエストするごとに、ＵＤＲは、当該関係するユーザについて、この更新リクエストを発行している特定のＨＬＲ−ＦＥに割り当てられている（１つまたは複数の）グループＩＤを有するＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥに関連付けられたグループＩＤ値を更新する。

その後、保存された［ＡｐｐＴｙｐｅ，（１つまたは複数の）グループＩＤ値］のペアは、ＵＤＲにおいて保存／管理されているユーザごとに、特定のユーザについての特定のアプリケーション・タイプに関連する発行された通知を報告するのに利用可能な、当該特定のアプリケーション・タイプの複数のアプリケーションＦＥから成るグループを識別する。また、ＵＤＲは、識別される複数のアプリケーションＦＥ間で、通知の負荷分散を行うために、予め設定された決定論的なアルゴリズムを利用しうる。特定のアプリケーション・タイプに対応する全てのアプリケーションＦＥが、あるエリアに対して一様に有効である場合には、ＵＤＲは、任意のアプリケーションＦＥを使用できるため、可能性のある複数のアプリケーションＦＥから成るリストを用いて設定される必要がない。

保存された［ＡｐｐＴｙｐｅ，（１つまたは複数の）グループＩＤ値］のペアは、ＵＤＲから、このＡｐｐＴｙｐｅに属するアプリケーションＦＥ（または複数のアプリケーションＦＥから成るグループ）に、ユーザについて発行される任意の通知に対して適用されることに留意されたい。したがって、［ＡｐｐＴｙｐｅ，（１つまたは複数の）グループＩＤ値］のペアは、「ユーザ」に関係するとともに、特定のＡｐｐＴｙｐｅに関係する一方で、複数のユーザ関連属性から成る特定のグループに関係することは全くない。

図４は、ＵＤＲ操作がステップ４１においてリクエストされた際に、グループＩＤ属性を更新するか否かを決定する方法の一実施形態に含まれるステップを示すフローチャートである。複数のＦＥ（例えば、ＨＬＲ−ＦＥ３４ａ〜３４ｅ）のいずれかからリクエストされるＵＤＲ操作は、ＵＤＲ内の、関係する（１または複数の）ユーザのデータをアドレス指定するために使用可能な識別子を含む。特定ユーザの（本明細書では「ユーザ・アプリケーションデータ」または「ユーザデータ」と称される）データの取り出し／更新を直近にリクエストしたアプリケーションＦＥの（１つまたは複数の）グループＩＤ値をＵＤＲが保存／更新するか否かを決定するための基準／条件のセットが、ＵＤＲによって既知の各ＡｐｐＴｙｐｅについて指定される。図４に示す条件は例示のみであり、特定ユーザのユーザデータの取り出し／更新を直近にリクエストしたアプリケーションＦＥの（１つまたは複数の）グループＩＤ値をＵＤＲが保存／更新するか否かを決定する際に、追加の条件を考慮することも可能である。

ステップ４２では、リクエストを送信するアプリケーションＦＥに関連付けられているアプリケーション・タイプ（ＡｐｐＴｙｐｅ）が、特定のエリアネットワークに関連付けられているか否かが判定される。ＨＬＲ及びＨＳＳは特定のエリアネットワークに関連付けられているため、例えば、ＡｐｐＴｙｐｅ＝ＨＬＲ、または、ＡｐｐＴｙｐｅ＝ＨＳＳは、更新処理を必要としうる。ＡｐｐＴｙｐｅが、特定のエリアネットワークに関連付けられていない場合には、本方法はステップ４３に移行し、グループＩＤ値は更新されない。ＡｐｐＴｙｐｅが特定のエリアネットワークに関連付けられている場合には、本方法はステップ４４に移行し、当該ステップにおいて、アプリケーションＦＥによってリクエストされているデータベース操作が、更新リクエストまたは作成リクエスト等のオリジネーティング・リクエスト（originating request）であるか、取り出しリクエストまたは削除リクエスト等のターミネーティング・リクエスト（terminating request）であるかが判定される。典型的には、リクエストされた操作が更新である場合、この情報は、いずれのアプリケーションＦＥがオリジネーティング・リクエスト（例えば、ＩＭＳ登録）に対応するユーザに対処しているかを知ることについて関連性があるため、ＵＤＲは、（１つまたは複数の）グループＩＤ値を保存する。ターミネーティング・リクエストについては、実行される操作はデータの取り出しであり、これは、典型的には、ＵＤＲ内のグループＩＤを更新させる結果とはならない。したがって、アプリケーションＦＥによってリクエストされているデータベース操作がターミネーティング・リクエストである場合、本方法はステップ４３に移行して、グループＩＤ値は更新されない。

アプリケーションＦＥによってリクエストされているデータベース操作が、オリジネーティング・リクエストである場合、本方法はステップ４５に進み、当該ステップにおいて、修正されたユーザ・アプリケーションデータが、グループＩＤに関連しているか否かが判定される。この（関連している／関連していない）要素は、修正されたデータのタイプに依存しうるとともに、ユーザの位置に関連したデータ（例えば、割り当てられたＭＳＣ／ＶＳＲ名、または割り当てられたＳ−ＣＳＣＦ名、特定のサービスに関連したユーザデータ等）等の、特定のデータタイプに、ＵＤＲ内で関連した属性である可能性がある。例えば、ユーザが登録されているＳ−ＣＳＣＦの名前が変わる場合、ＵＤＲは、グループＩＤ値を保存する。これは、ユーザが別のエリア（即ち、異なるグループＩＤ値を有するエリア）に移動した可能性があるためである。あるいは、操作の結果としてユーザの転送先番号（forwarded-to number）等のユーザデータが変わる場合、ＵＤＲは、グループＩＤ値を保存／上書きする必要はない。したがって、修正されたユーザ・アプリケーションデータがグループＩＤに関連していない場合、本方法はステップ４３に移行して、グループＩＤ値は更新されない。

修正されたユーザ・アプリケーションデータがグループＩＤに関連している場合、本方法はステップ４６に移行し、当該ステップにおいて、リクエストされた操作がＵＤＲにおいて成功したか否かが判定される。成功しなかった場合、本方法はステップ４３に移行して、グループＩＤ値は更新されない。リクエストされた操作がＵＤＲにおいて成功した場合、本方法はステップ４７に進み、当該ステップにおいて、グループＩＤ値が更新される。

適用可能な条件は、各ＡｐｐＴｙｐｅに関連付けてＵＤＲにおいて設定されうる。例えば、条件のセットは、ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥに対応して設定されうるし、ＡｐｐＴｙｐｅ＝ＨＳＳ−ＦＥに対応して設定されうる、等である。

３ＧＰＰ ＴＳ ２３．３３５では、ＵＤＲは、現在、ＵＤＲに接続するアプリケーションＦＥを認証することが要求されており、それ故に、各アプリケーションＦＥについての認証データを既に保管している。新しいグループＩＤ値は、ＵＤＲにおいて管理されることになる、各アプリケーションＦＥに関連付けられた追加の属性である。

再び図３を参照すると、ＵＤＲ３０に設定されている、配置されたＨＬＲ−ＦＥ３４ａ〜３４ｅを記述する設定パラメータの一例は、以下のとおりである。
・ＨＬＲ−ＦＥ１ →［ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ１］
・ＨＬＲ−ＦＥ２ →［ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ１］
・ＨＬＲ−ＦＥ３ →［ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ２］
・ＨＬＲ−ＦＥ４ →［ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ２］
・ＨＬＲ−ＦＥ５ →［ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ２］

負荷分散重みが、各アプリケーションＦＥについて更に保存されてもよい。当該重みは、特定のユーザに対して通知を送信するための特定のアプリケーションＦＥを選択することの望ましさ（desirability）を示しうる。上記の予め設定されたグループＩＤ値によって、かつ、負荷分散重みも含まれた状態で、通知分散（notification distribution）を目的としたＵＤＲの設定は、以下のようになりうる。
（１）ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ１
・ＨＬＲ−ＦＥ１（負荷分散重み：１００）
・ＨＬＲ−ＦＥ２（負荷分散重み：１００）
・ＨＬＲ−ＦＥ３（負荷分散重み：１）
・ＨＬＲ−ＦＥ４（負荷分散重み：１）

（２）ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥ，グループＩＤ＝ＡＮ２
・ＨＬＲ−ＦＥ１（負荷分散重み：１）
・ＨＬＲ−ＦＥ２（負荷分散重み：１）
・ＨＬＲ−ＦＥ３（負荷分散重み：１００）
・ＨＬＲ−ＦＥ４（負荷分散重み：１００）
・ＨＬＲ−ＦＥ５（負荷分散重み：１００）

なお、ＨＬＲ−ＦＥ５はエリアネットワーク１内のいずれのＭＳＣ／ＶＳＲにも接続することはできないため、ＨＬＲ−ＦＥ５は、グループＩＤ＝ＡＮ１についてのリストには含まれていない。また、関連するエリアネットワーク内のＭＳＣ／ＶＳＲに対してＳＴＰ１を介して接続しなければならないＨＬＲ−ＦＥには、低い負荷分散重みが割り当てられている一方で、関連するエリアネットワーク内のＭＳＣ／ＶＳＲに対して直接に接続するＨＬＲ−ＦＥには、高い負荷分散重みが割り当てられている。当然ながら、ＦＥを選択する際に追加的な要素を考慮するために、他の負荷分散重もありうる。

最後に、ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥについての（ユーザレベルで管理された）グループＩＤ属性を更新する、本例における条件は、以下のようになりうる。
ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥについてのグループＩＤ値を更新する「条件のセット」
‐リクエストされた操作：更新
かつ
‐ユーザデータ：ＣＳ／ＰＳ位置データ
かつ
‐操作結果：成功

この条件のセットは、ＭＡＰ位置更新の操作情報が、特定のユーザについて、選択されたＨＬＲ−ＦＥに向けてＭＳＣ／ＶＬＲから発行された際に、ＵＤＲ３０が、当該選択されたＨＬＲ−ＦＥについてのグループＩＤ値を保存し、かつ、当該グループＩＤを当該特定のユーザと関連付けることを保証することに、留意されたい。

ＵＤＲが上記で示したように設定されており、かつ、エリアネットワーク１内に位置するＭＳＣ／ＶＳＲによってユーザが管理されており、かつ、ＡｐｐＴｙｐｅ＝ＨＬＲ−ＦＥに関連付けられた通知がＵＤＲによってＨＬＲ−ＦＥに向けて送信される必要がある場合には、ＵＤＲにおいて設定された決定論的な通知分散アルゴリズムによって、通知の約５０パーセントがＨＬＲ−ＦＥ１に対して配信され、通知の約５０パーセントがＨＬＲ−ＦＥ２に配信される。非常に稀な場合（例えば、ＨＬＲ−ＦＥ１及びＨＬＲ−ＦＥ２が到達不可能である場合）にのみ、ＵＤＲは、ＨＬＲ−ＦＥ３またはＨＬＲ−ＦＥ４に通知を送信し、ＨＬＲ−ＦＥ３またはＨＬＲ−ＦＥ４は、必要に応じて、ＳＴＰ１を介してＭＳＣ／ＶＳＲ１またはＭＳＣ／ＶＳＲ２に当該通知を転送する。これと同様に、ユーザが、エリアネットワーク２内に位置するＭＳＣ／ＶＳＲによって管理されている場合、通常、ＨＬＲ−ＦＥ３、ＨＬＲ−ＦＥ４、またはＨＬＲ−ＦＥ５に対して通知が送信されることで、負荷の分担がそれらに適用される。非常に稀な場合（例えば、ＨＬＲ−ＦＥ３、ＨＬＲ−ＦＥ４及びＨＬＲ−ＦＥ５が到達不可能である場合）にのみ、ＵＤＲは、ＨＬＲ−ＦＥ１またはＨＬＲ−ＦＥ２に通知を送信し、ＨＬＲ−ＦＥ１またはＨＬＲ−ＦＥ１は、必要に応じて、ＳＴＰ１を介してＭＳＣ／ＶＳＲ３、ＭＳＣ／ＶＳＲ４、またはＭＳＣ／ＶＳＲ５に当該通知を転送する。

図５は、オペレータが、異なるＳ−ＣＳＣＦベンダを有するＵＤＲアーキテクチャについての簡略化したブロック図である。Ｓ−ＣＳＣＦ１及びＳ−ＣＳＣＦ２（５１ａ及び５１ｂ）は、ベンダ１（５２）によって提供される。Ｓ−ＣＳＣＦ３、Ｓ−ＣＳＣＦ４及びＳ−ＣＳＣＦ５（５１ｃ〜５１ｅ）は、ベンダ２（５３）によって提供される。複数のＳ−ＣＳＣＦは、異なるベンダによって提供されうる。これは、例えば、Ｓ−ＣＳＣＦ１及びＳ−ＣＳＣＦ２が、ベンダ１によってのみサポートされているプレゼンス・サービス及び優先サービスを利用可能な特定のユーザにサービスを行うことが意図されているためである。オペレータは、これらのサービスを提供するために、プライベートかつ分散したネットワークを有する。

本例のＵＤＲ３０は、複数のＨＳＳ−ＦＥ５４ａ〜５４ｅを介して、また、ダイアメータ・プロキシ１及びダイアメータ・プロキシ２（５５ａ及び５５ｂ）を介して、様々なＳ−ＣＳＣＦに接続する。このアーキテクチャを利用する方法について、図６を参照しながら以下で説明する。

図６は、本発明の一実施形態における、ユーザの登録及び登録解除を行う方法を示す信号フロー図である。図５及び図６を参照すると、ベンダ１（５２）を介して優先サービスに加入しているユーザ（例えば、ネットワークが高いトラヒック負荷を処理している場合に、特定の呼に対して優先付け（prioritization）を要求可能なユーザ）が、ステップ６１において、ＩＭＳ登録を実行する。Ｓ−ＣＳＣＦ１（５１ａ）及びＳ−ＣＳＣＦ２（５２ｂ）のみが、このユーザにサービスを行うことができる。このため、登録メッセージをユーザから受信するインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）６２は、ステップ６３〜６６に示されている登録手続の間、当該ユーザのために必要とされる能力に従って、（負荷バランシング設定において）Ｓ−ＣＳＣＦ１またはＳ−ＣＳＣＦ２を選択する。本例では、Ｓ−ＣＳＣＦ１が選択され、ステップ６７〜６８において登録メッセージはＳ−ＣＳＣＦ１に対して転送される。

ステップ６８において、ＨＳＳ−ＦＥ１（５４ａ）は、ダイアメータ・リクエストをＳ−ＣＳＣＦ１から受信すると、ステップ６９において、ＨＳＳ−ＦＥ１は、ユーザがサービスを受けるＳ−ＣＳＣＦ名を設定するために、ＵＤＲ３０に更新コマンドを送信する。登録状態も変更される。なお、ＨＳＳ−ＦＥ１は、新たなグループＩＤ（即ち、ベンダ１）に属しているため、オペレータは、（ベンダ２に属している）Ｓ−ＣＳＣＦ３とは異なるアクセスルールを設定しうる。これは、ユーザに優先サービスを保証するために必要とされうる。ＵＤＲは、更新コマンドの受信に応じて、ステップ７０においてグループＩＤを保存する／保存しないための条件を確認する。ユーザはそれ以前に登録されていなかったため、当該条件は、Ｓ−ＣＳＣＦ名が更新されることである。その結果、ＵＤＲは、グループＩＤ（ベンダ１）とＡｐｐＴｙｐｅ＝ＨＳＳとを保存する。

その後、オペレータは、優先サービスをユーザから解除することを決定しうる。この場合、当該ユーザは、その時点で、ベンダ２のＳ−ＣＳＣＦ２のいずれかによってサービスを受けうる。オペレータが、ユーザをベンダ２のＳ−ＣＳＣＦ２に移動させることを決定すると、それを行うために当該ユーザのために必要となる能力が変更される。ユーザの能力が変更されているため、オペレータは、ステップ７１において、新たなＳ−ＣＳＣＦが割り当てられるように、管理上でユーザの登録解除を行う。（登録状態がアプリケーション・タイプ＝プロビジョニングによって変更される）ＵＤＲにおいて設定された条件は、（登録されていない）新たな状態とＳ−ＣＳＣＦ名（Ｓ−ＣＳＣＦ１）とを有するＨＳＳ−ＦＥに向けられる通知をトリガする。ＡｐｐＴｙｐｅ＝ＨＳＳについてのユーザに対応して保存されたグループＩＤを使用することによって、ＵＤＲは、通知を送信するための適切な複数のＨＳＳ−ＦＥ（ＨＳＳ−ＦＥ１及びＨＳＳ−ＦＥ２）から成るリストを有する。その両方に対して設定された優先度／重みは同一であるため、ＵＤＲは、ステップ７２において、ＨＳＳ−ＦＥ２（５４ｂ）を選択して、通知を送信する。ステップ７３における確認応答に続いて、ＨＳＳ−ＦＥ２は、ステップ７４において、登録解除コマンドをＳ−ＣＳＣＦ１に向かって送信する。

ユーザは、この登録解除について通知されるため、ユーザ装置（ＵＥ）は、上述の手続と同様の手続を使用して、新たな登録を実行する。そのような手続（図示せず）において、Ｉ−ＣＳＣＦは、新たな能力に基づいて、適切なＳ−ＣＳＣＦをユーザに対して選択する。例えば、Ｓ−ＣＳＣＦ４が選択されうるとともに、Ｓ−ＣＳＣＦ４は、ダイアメータ・リクエストを、ＨＳＳ−ＦＥ５（５４ｅ）等のＨＳＳ−ＦＥに送信する。ＨＳＳ−ＦＥ５からの、それに続く更新コマンドを受信すると、ＵＤＲ３０は、グループＩＤを保存する／保存しないための条件を確認する。当該条件は、更新されたデータがＳ−ＣＳＣＦ名である、ということである（ユーザが登録されなかったため、Ｓ−ＣＳＣＦ名は空であった）。したがって、ＵＤＲは、グループＩＤ（ベンダ２）及びＡｐｐＴｙｐｅ＝ＨＳＳを保存する。

図７は、本発明の教示に従って修正されたＵＤＲ３０についての簡略化したブロック図である。ＵＤＲの動作は、プログラム・メモリ８２に保存されているコンピュータ・プログラム・ソフトウェアを実行するプロセッサ８１によって制御されうる。図３に関連して上述したように、ＵＤＲは、アプリケーションＦＥインタフェース部８３を、ＨＬＲ−ＦＥ５（３４ａ〜ｅ）を介してＨＬＲ−ＦＥ１等のアプリケーションＦＥと通信するために利用しうる。ＵＤＲ操作リクエストがアプリケーションＦＥから受信された場合、認証部８４は、保存されている認証データ８５を、当該リクエスト中のアプリケーションＦＥを認証するために利用しうる。ＵＤＲ操作リクエストが、このアプリケーションＦＥからの最初のリクエストである場合、保存決定部８６は、ＦＥ ＡｐｐＴｙｐｅ及びリクエスト中のアプリケーションＦＥに対応するグループＩＤを、ＦＥアプリケーション・タイプ／グループＩＤテーブル８７に保存する。これがこのアプリケーションＦＥからの最初のＵＤＲ操作リクエストではない場合、図４に関連して示し、かつ、説明したように、保存決定部は、当該リクエスト中のアプリケーションＦＥに対応する更新されたグループＩＤ情報を保存するか否かを決定するために、所定の保存条件８８を利用しうる。肯定的な決定に応じて、保存決定部は、ＦＥアプリケーション・タイプ／グループＩＤテーブル内のグループＩＤ情報を更新する。その後、特定のユーザデータに関するＵＤＣイベント通知が、関連するアプリケーションＦＥに対して送信される必要がある場合には、アプリケーションＦＥ選択部８９は、ＦＥアプリケーション・タイプ／グループＩＤテーブル内の情報にアクセスして、当該イベント通知を受信する適切なアプリケーションＦＥを選択する。

図８は、本発明の方法の例示的な実施形態についてのステップを示すフローチャートである。ステップ９１において、上述したように、各アプリケーションＦＥには、ＡｐｐＴｙｐｅ、グループＩＤ、及び負荷分散重みが割り当てられる。ステップ９２において、ＵＤＲは、ＵＤＲ操作リクエストをアプリケーションＦＥから受信する。ステップ９３において、ＵＤＲは、アプリケーションＦＥを認証する。ステップ９４において、このリクエストが、このアプリケーションＦＥから受信された最初のＵＤＲ操作リクエストであるか否かが判定される。当該ＵＤＲ操作リクエストが、このアプリケーションＦＥから受信された最初のリクエストである場合には、本方法はステップ９５に移行し、当該ステップにおいて、ＵＤＲは、当該リクエスト中のアプリケーションＦＥについてのＦＥアプリケーション・タイプ及びグループＩＤを保存する。当該ＵＤＲ操作リクエストが、このアプリケーションＦＥから受信された最初のリクエストではない場合には、本方法はステップ９６に移行し、当該ステップにおいて、ＵＤＲは、このリクエスト中のアプリケーションＦＥについての更新されたグループＩＤを保存するか否かを決定するために、所定の保存条件を利用しうる。当該リクエストが所定の保存条件を満たす場合には、ステップ９５において、ＵＤＲは、ＦＥアプリケーション・タイプ／グループＩＤテーブル内のグループＩＤ情報を更新する。その後、ＵＤＲは、特定のユーザに関するＵＤＲイベント通知が関連するアプリケーションＦＥに対して送信される必要がある場合には、ステップ９８において、保存したＦＥアプリケーション・タイプ／グループＩＤ情報にアクセスするとともに、任意的に、当該情報を負荷分散重みとともに使用して、当該イベント通知を受信する適切なアプリケーションＦＥを選択する。

当然ながら、本発明は、本発明の本質的な特徴から逸脱することなく、本明細書で説明した方法以外の方法によって実施されることもありうる。したがって、本実施形態は、あらゆる点で例示的であると考えられるべきであり、添付の特許請求の範囲の意味及び均等の範囲内のあらゆる変更が、本発明に包含されることを意図している。

Claims (19)

1. 通信ネットワーク内の複数のアプリケーション・フロントエンド（アプリケーションＦＥ）（34a〜34e）から、イベント通知を受信するアプリケーションＦＥを選択するための、ユーザデータ・リポジトリ（ＵＤＲ）（30）における方法であって、
   前記複数のアプリケーションＦＥのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベース（88）に追加するステップ（95）であって、各グループ識別子は、前記関連付けられたアプリケーションＦＥを介してアクセス可能な、前記通信ネットワークに含まれる異なる部分を識別する、前記追加するステップと、
   その後、特定のユーザのユーザデータの変更を報告するためのイベント通知手続を開始するステップ（97）と、
   選択されるアプリケーションＦＥの前記アプリケーション・タイプ及びグループ識別子に基づいて、前記イベント通知を受信するアプリケーションＦＥを選択するステップ（98）と
   を含むことを特徴とする方法。
2. 前記データベースに追加する前記ステップ（95）は、
   前記複数のアプリケーションＦＥのうちの１つからＵＤＲ操作リクエストが受信された際に（92）、アプリケーションＦＥについての前記アプリケーション・タイプ及びグループ識別子を、ユーザレベルで前記データベースに保存するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記保存するステップは、
   所与のアプリケーションＦＥからＵＤＲ操作リクエストを受信するステップ（92）であって、当該リクエストは、ユーザデータを変更し、かつ、当該所与のアプリケーションＦＥについてのアプリケーション・タイプ及びグループ識別子を含む、前記受信するステップと、
   前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された最初のＵＤＲ操作リクエストであるか否かを判定するステップ（94）と、
   前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された前記最初のＵＤＲ操作リクエストである場合に、前記アプリケーション・タイプ及びグループ識別子を前記データベースに保存するステップ（95）と、
   前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された前記最初のＵＤＲ操作リクエストではない場合に、更新されたグループ識別子を保存するか否かを決定するステップ（96）と
   を含むことを特徴とする請求項２に記載の方法。
4. 更新されたグループ識別子を保存するか否かを決定する前記ステップ（96）は、
   前記ＵＤＲ操作リクエストに関する所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定するステップ
   を含むことを特徴とする請求項３に記載の方法。
5. 所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定する前記ステップ（96）は、
   前記アプリケーション・タイプが、前記通信ネットワークの、前記特定のユーザの位置に依存した部分に関連付けられたタイプであると、前記更新されたグループ識別子を保存するステップ
   を含むことを特徴とする請求項４に記載の方法。
6. 所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定する前記ステップ（96）は、
   前記ＵＤＲ操作リクエストが、更新リクエストまたは生成リクエストであると、前記更新されたグループ識別子を保存するステップ
   を含むことを特徴とする請求項４に記載の方法。
7. 所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定する前記ステップ（96）は、
   変更された前記ユーザデータが、前記グループ識別子に関連している場合にのみ、前記更新されたグループ識別子を保存するステップ
   を含むことを特徴とする請求項４に記載の方法。
8. 所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定する前記ステップ（96）は、
   前記リクエストされたＵＤＲ操作が、前記ＵＤＲにおいて成功した場合にのみ、前記更新されたグループ識別子を保存するステップ
   を含むことを特徴とする請求項４に記載の方法。
9. 前記複数のアプリケーションＦＥのそれぞれに、負荷分散重みを割り当てるステップ（91）を更に含み、
   当該割り当てるステップでは、
   所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みを当該所与のアプリケーションＦＥに割り当て、当該所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みを当該所与のアプリケーションＦＥに割り当てる
   ことを特徴とする請求項１に記載の方法。
10. 前記イベント通知を受信するアプリケーションＦＥを選択する前記ステップ（98）は、
    選択されるアプリケーションＦＥに割り当てられている前記負荷分散重みに基づいて、前記アプリケーションＦＥを選択するステップ
    をさらに含むことを特徴とする請求項９に記載の方法。
11. 通信ネットワーク内の複数のアプリケーション・フロントエンド（アプリケーションＦＥ）（34a〜34e）から、イベント通知を受信するアプリケーションＦＥを選択するための、ユーザデータ・リポジトリ（ＵＤＲ）（30）における装置であって、
    前記複数のアプリケーションＦＥのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベース（88）に追加する手段（86）であって、各グループ識別子は、前記関連付けられたアプリケーションＦＥを介してアクセス可能な、前記通信ネットワークに含まれる異なる部分を識別する、前記追加する手段と、
    その後、特定のユーザのユーザデータの変更を報告するために、イベント通知手続を開始する手段（81）と、
    選択されるアプリケーションＦＥの前記アプリケーション・タイプ及びグループ識別子に基づいて、前記イベント通知を受信するアプリケーションＦＥを選択する手段（89）と
    を備えることを特徴とする装置。
12. 前記データベースに追加する前記手段（86）は、
    前記複数のアプリケーションＦＥのうちの１つからＵＤＲ操作リクエストが受信された際に（92）、アプリケーションＦＥについての前記アプリケーション・タイプ及びグループ識別子を、ユーザレベルで前記データベースに保存する
    ことを特徴とする請求項１１に記載の装置。
13. 前記追加する手段は、
    所与のアプリケーションＦＥからＵＤＲ操作リクエストを受信するインタフェース部（83）であって、当該リクエストは、ユーザデータを変更し、かつ、当該所与のアプリケーションＦＥについてのアプリケーション・タイプ及びグループ識別子を含む、前記インタフェース部と、
    前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された最初のＵＤＲ操作リクエストであるか否かを判定する手段（86）と、
    前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された前記最初のＵＤＲ操作リクエストである場合に、前記アプリケーション・タイプ及びグループ識別子を前記データベースに保存するとともに、前記ＵＤＲ操作リクエストが、前記所与のアプリケーションＦＥから受信された前記最初のＵＤＲ操作リクエストではない場合に、更新されたグループ識別子を保存するか否かを決定する保存決定部（86）と
    を備えること特徴とする請求項１２に記載の装置。
14. 前記保存決定部（86）は、前記ＵＤＲ操作リクエストに関する所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定する
    ことを特徴とする請求項１３に記載の装置。
15. 前記所定の基準（87）のうちの１つは、前記所与のアプリケーションＦＥの前記アプリケーション・タイプであり、
    前記保存決定部（86）は、前記アプリケーション・タイプが、前記通信ネットワークの、前記特定のユーザの位置に依存した部分に関連付けられたタイプであると、前記更新されたグループ識別子を保存する
    ことを特徴とする請求項１４に記載の装置。
16. 前記所定の基準（87）のうちの１つは、受信されたＵＤＲ操作リクエストのタイプであり、
    前記保存決定部（86）は、前記ＵＤＲ操作リクエストが、更新リクエストまたは生成リクエストであると、前記更新されたグループ識別子を保存する
    ことを特徴とする請求項１４に記載の装置。
17. 前記所定の基準（87）のうちの１つは、変更された前記ユーザデータの前記グループ識別子に対する関連性であり、
    前記保存決定部（86）は、変更された前記ユーザデータが、前記グループ識別子に関連している場合にのみ、前記更新されたグループ識別子を保存する
    ことを特徴とする請求項１４に記載の装置。
18. 前記所定の基準（87）のうちの１つは、前記リクエストされたＵＤＲ操作の成功または失敗であり、
    前記保存決定部（86）は、前記リクエストされたＵＤＲ操作が、前記ＵＤＲにおいて成功した場合にのみ、前記更新されたグループ識別子を保存する
    ことを特徴とする請求項１４に記載の装置。
19. 前記イベント通知を受信するアプリケーションＦＥを選択する前記手段は、さらに、前記複数のアプリケーションＦＥのそれぞれに割り当てられた負荷分散重みに基づいて、前記アプリケーションＦＥを選択し、
    所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みが当該所与のアプリケーションＦＥに割り当てられており、
    当該所与のアプリケーションＦＥが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みが当該所与のアプリケーションＦＥに割り当てられている
    ことを特徴とする請求項１１に記載の装置。

Images