(57)【要約】  この方法及び装置は、少なくとも１つのリソースデータに対するリソースを監視クライアントへ提供する。監視クライアントから送信されるリソースに関するリソースデータに対する加入リクエストは、通知サーバによって受信され（７００）、この加入リクエストは、監視クライアントに対してデータベースにおいて予め構成設定されている通知ルールへのリファレンスを含んでいる。監視クライアントへの通知の配信は、リファレンスに基づいて制御される（７１０）。加入リクエストを、実際の通知ルールに代えて被観測リソース（群）に関する予め構成設定されている通知ルールへのリファレンスで補完することによって、監視クライアントに対する複数の加入リクエストで送信される情報の量を削減する。【選択図】  なし
2012518326.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバにおける方法であって、
前記少なくとも１つのリソースに関するリソースデータに対する前記監視クライアントから送信される加入リクエストとして、前記監視クライアントに対するデータベース内で予め構成設定されている少なくとも１つの通知ルールへのリファレンスを含む加入リクエストを受信するステップ（７００）と、
前記リファレンスに基づいて、リソースデータを含む通知の前記監視クライアントへの配信を制御するステップ（７１０）と
を備えることを特徴とする方法。
【請求項２】
前記制御するステップは、更に、
前記リファレンスに従って前記データベースから前記少なくとも１つの通知ルールを取得すること（７０２）と、
リソースデータサーバからリソースデータを検索する（７０６）ために、あるいは前記通知を配信する（７１０）ために、取得される前記通知ルール（群）の少なくとも１つを適用すること
を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
取得される前記通知ルールの少なくとも１つは、
受信される前記加入リクエストを前記監視クライアントによって適用されるリソースデータモデルから前記少なくとも１つのリソースによって適用されるリソースデータモデルへ変換すること（７０４）、
あるいは
検索される前記リソースデータを前記少なくとも１つのリソースによって適用されるリソースデータモデルから前記監視クライアントによって適用される前記リソースデータモデルへ変換すること（７０８）
のいずれかのために適用される
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記少なくとも１つの通知ルールは、フィルタで定義される
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記フィルタは、ＸＭＬフォーマットに従ってフォーマットされ、
前記データベースは、ＸＤＭＳに記憶されている
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記フィルタは、
リソースデータの一定のタイプを含む通知、
最大データ量を越えない通知
１つ以上の特定のリソースに対する通知、
一日、１週間、１シーズンの内の一定の時間での通知
の少なくとも１つに関する通知ルールを定義する
ことを特徴とする請求項４または５に記載の方法。
【請求項７】
前記フィルタは、リクエストメッセージと通知の、第１のリソースデータモデルから第２のリソースデータモデルへの変換に関する通知ルールを定義する
ことを特徴とする請求項４または５に記載の方法。
【請求項８】
少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバ（８００、８００’）であって、
第１の通信リンク（８２０）上の前記監視クライアントからの前記リソースに関する前記リソースデータに対する加入リクエストを受信し、前記リソースデータを含む少なくとも１つの通知を前記第１の通信リンク（８２０）上の前記監視クライアントへ配信するように構成されている第１の通信ユニット（８０２）と、
前記加入リクエストで供給されるリファレンスを識別し、前記リファレンスに基づいてデータベース（８５０）から少なくとも１つの通知ルールを取得し、前記リソースデータを検索し、前記リソースデータの少なくともいくつかを含む少なくとも１つの通知を形成するように構成されている通知ルールマネージャ（８０４、８０４’）と、
前記通知ルールマネージャ（８０４、８０４’）によって取得される前記通知ルール（群）がアップロードされて、前記取得される通知ルール（群）を記憶するように構成されている通知ルール記憶ユニット（８０６）と、
リソースデータを記憶するように構成されているリソースデータ記憶ユニット（８１０）とを備え、
前記通知ルールマネージャ（８０４、８０４’）は、更に、リソースデータの検索を実行するための、あるいは前記通知を形成するための、取得される前記通知ルール（群）の少なくとも１つを適用するように構成されている
ことを特徴とする通知サーバ（８００、８００’）。
【請求項９】
前記通知ルールマネージャ（８０４、８０４’）は、更に、前記取得される通知ルール（群）を分割し、各被観測リソースに対して関連のある前記取得される通知ルール（群）を適用するように構成されている
ことを特徴とする請求項８に記載の通知サーバ（８００、８００’）。
【請求項１０】
前記通知ルールマネージャ（８０４）は、更に、前記リソースデータ記憶ユニット（８１０）から前記リソースデータを検索するように構成されている
ことを特徴とする請求項８または９に記載の通知サーバ（８００、８００’）。
【請求項１１】
前記通知ルールマネージャ（８０４’）は、更に、リソースデータサーバから前記リソースデータを検索するように構成されていて、
当該通知サーバ（８００’）は、第２の通信リンク（８２２）上の前記リソースデータサーバから前記リソースデータの検索を実行するように構成されている第２の通信ユニット（８０８）を備え、
前記リソースデータ記憶ユニット（８１０）は、更に、前記通知ルールマネージャ（８０４’）によって検索される前記リソースデータでアップロードされるように構成されている
ことを特徴とする請求項８または９に記載の通知サーバ（８００、８００’）。
【請求項１２】
前記第１の通信ユニット（８０２）から受信される加入リクエスト（群）を、前記監視クライアントによって適用されるリソースデータモデルから、少なくとも１つの前記リソースによって適用されるリソースデータモデルへ変換すること、
前記第１の通信ユニット（８０２）によって送信される通知を、少なくとも１つの前記リソースによって適用されるリソースデータモデルから、前記監視クライアントによって適用される前記リソースデータモデルへ変換すること
の少なくとも１つに対して、前記取得される通知ルールの少なくとも１つを適用するように構成されている変換ユニット（８０４ｂ）を更に備える
ことを特徴とする請求項８乃至１１のいずれか１項に記載の通知サーバ（８００、８００’）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、被観測リソース（observed source）、例えば、クライアント、ドキュメント、あるいはコンテンツサービスのリソースデータに対する加入を処理するための方法及び装置に関するものである。
【背景技術】
【０００２】
３Ｇモバイルテレフォニーの出現に伴い、ＩＰ（インターネットプロトコル）を使用する新規のパケットベースの通信技術がマルチメディアサービスの使用をサポートするために開発されている一方で、マルチメディア通信用の新機能を有する様々な移動端末と固定ユーザ端末とが市場で出現している。マルチメディアサービスを通常に消費する際の経験の品質を高め、その使用の範囲を増加するために、端末のユーザに対する新規のサービスも絶えず開発されている。
【０００３】
ＩＭＳ（ＩＰマルチメディアサブシステム）ネットワークは、様々な異なるアクセスネットワークに接続されるユーザ端末に対するマルチメディアセッションを開始して制御することによって、マルチメディアサービスを実現可能にするために使用することができる。
【０００４】
「ＳＩＰ」（セッション開始プロトコル）と呼ばれるシグナリングプロトコルは、ＩＭＳネットワークと他の通信サービスネットワークにおいてマルチメディアセッションを処理するために一般に使用されている。ＩＭＳは、本明細書では例示の目的のために言及され、これは、本発明をＩＭＳネットワークに排他的に制限するものではない。ユーザとそのユーザの通信端末は、しばしば「クライアント」とよばれ、この用語は、本明細書では一般的に使用する。
【０００５】
ＩＭＳ対応サービスの特定の例には「プレゼンス」サービスがあり、これは、クライアントのプレゼンスデータを他のクライアントあるいはアプリケーションに利用可能にするための、そのクライアントのプレゼンスデータの発行を含んでいる。プレゼンスデータは、基本的には、クライアントのステータス、シチュエーションあるいは状態を意味するものであり、これには、例えば、クライアントの現在の地理的位置、接続ステータス、サービス可用性、及び端末ケイパビリティ、更には、任意のパーソナル特性、プリファレンス及び設定がある。プレゼンスデータは、そのようなクライアント関連情報の発行に基づいて、ＩＭＳネットワーク内のプレゼンスサーバに記憶することができる。これらの発行は、クライアントの任意のプレゼンスデータが利用可能になるあるいは更新されるときはいつでも、クライアントの端末から、あるいはクライアントによって使用されるアクセスネットワークから取得することができる。
【０００６】
クライアントは、例えば、確立済のあるいは所定のクライアントグループの所定のリストに従って、１つ以上の他のクライアントの選択されたプレゼンスデータに加入することもできる。プレゼンスの加入も、典型的には、ＩＭＳネットワークにおけるプレゼンスサーバによって処理され、これには、様々な情報フィルタ、承認ルール及びポリシーを含むことができる。加入するクライアントは、プレゼンスサーバから、現在のプレゼンスデータ、任意の一般フィルタ、ルール、あるいはポリシーに関する通知を、自動的にあるいはリクエストに応じて受信することができる。
【０００７】
ＳＩＰでは、「発行（ＰＵＢＬＩＳＨ）」と呼ばれるメッセージは、プレゼンスサーバにデータを提供するためにクライアントによって使用することができる。このメッセージは、基本的には新規のデータを開始し、データを「リフレッシュ」し（すなわち、先に開始されているデータが有効に継続しているかを確認する）、データを変更し、そして、これ以上有効でないデータを終了するために使用される。また、「加入（ＳＵＢＳＣＲＩＢＥ）」と呼ばれるメッセージは、プレゼンスサーバによって処理されるように、他のクライアントのプレゼンスデータに加入するためにクライアントによって使用することができ、そして、許可されたクライアントのみがこのようなデータを受信する権利を与えられる。「通知（ＮＯＴＩＦＹ）」と呼ばれる別のメッセージは、加入しているクライアントへプレゼンスデータを提供するために、プレゼンスサーバによって使用することができる。「登録（ＲＥＧＩＳＴＥＲ）」と呼ばれる更に別のメッセージは、ＩＭＳネットワークあるいはアクセスネットワークへのログオンするためにクライアントによって使用することができる。
【０００８】
プレゼンスサービスが大部分はクライアントデータの発行に基づいている一方で、クライアントは、一般的には、上述のメカニズムを基本的には使用する任意のリソースデータに加入することができる。ここで、このリソースデータは、別のクライアントとは別に、コンテンツサービスあるいは情報サービスのような関心のある任意のオブジェクトであっても良い。例えば、グループあるいはデータ管理のための通知は、例えば、コンタクトリストあるいはアドレスブックのような文書における変更を言及することができる。更には、コンテンツサービスあるいは情報サービスに対する通知は、株式取引、天気予報、スポーツの結果、あるいは任意の他の情報更新を言及することができる。一般的には、リソースデータの通知は、リソースデータの加入に従って、被観測リソースの状態変更あるいは更新を言及することができる。
【０００９】
本明細書において、用語「監視（watching：ウォッチング）クライアント」は、リソースデータへ加入するあるいはリソースデータをリクエストするクライアントを表していて、用語「被観測リソース」は、許可された監視クライアントに対して利用可能となるように発行されているリソースデータに対するリソースを表している。プレゼンスサービスの状況では、監視クライアントは「ウォッチャー（監視者）」と呼ばれ、監視（観測）されるクライアント（被観測クライアント（observed client））は「プレゼンティティ（presentity）」と呼ばれる。例えば、通知は、ウォッチャーリクエストを参照する場合があり、これは、基本的には、プレゼンティティに、ウォッチャーが一定のプレゼンス情報を受信することを許可することを依頼するものである。
【００１０】
上述の加入メッセージは、典型的には、タイムアウトパラメータを含み、これは、加入の期間を判定するために設定することができ、時には、ＴＴＬ（有効期間）とも呼ばれる。加入メッセージ内のタイムアウトパラメータがゼロに設定される場合、リクエストされたプレゼンスデータを伴う通知が一回だけ取得され、その後、加入が即座に終了される。タイムアウトパラメータが０より大きい一定の時間期間に設定される場合、監視クライアントは、加入期間が満了するまで、いくつかの所定のスキームに従って通知を受信することになる。また、「加入」メッセージは、典型的には、どのクライアント（群）からプレゼンスデータを検索し、どのデータを検索するか等に関する情報を含んでいる。この情報は、「加入」メッセージ内に含まれるフィルタで定義することができる。
【００１１】
図１は、プレゼンスデータを提供するための従来の手順を示していて、この手順では、ウォッチングクライアントＡと、被観測クライアントＢとプレゼンスサーバ１００とが関与し、このプレゼンスサーバ１００は、データベース１０２内でクライアントＢに対するプレゼンスデータを記憶する。第１のステップ１：１ａは、一般的には、プレゼンスデータが被観測クライアントＢに対して発行されることを示していて、この発行は、従来のルーチンに従って、クライアントＢからあるいはクライアントＢのアクセスネットワーク（不図示）から、プレゼンスサーバ１００へ頻繁に送信される発行メッセージによってなされる。次のステップ１：１ｂは、データベース１０２がステップ１：１ａの発行メッセージに従って更新されることを示している。ステップ１：１ａとステップ１：１ｂは、一般的なルーチンに従って、全体を通してバックグラウンドで継続する。
【００１２】
ステップ１：２では、クライアントＡは、加入メッセージをクライアントＢのプレゼンスデータに対する加入リクエストとして送信し、これには、所望の加入時間期間に対するタイムアウトパラメータが特定されている。ステップ１：３で、プレゼンスサーバ１００は、次に、クライアントＢのプレゼンスデータを検索し、ステップ１：４で示されるように、初期通知メッセージであるＳＩＰ通知（ＮＯＴＩＦＹ）でクライアントＡに検索したプレゼンスデータを送信する。ステップ１：４における破線で示されるように、クライアントＡは、このような通知を複数個、与えられる加入時間の間で、定期的な間隔であるいはプレゼンスデータが変更される時のいずれかの後続の機会で受信することができる。加入を延長あるいは「リフレッシュ」するために、クライアントＡは、加入時間が満了する前に自動的に更なる加入メッセージを送信する。これにより、プレゼンスサーバは、クライアントＡへ通知を送信することを継続することになる。
【００１３】
監視クライアントは、いくつかの被観測クライアントのプレゼンスデータに加入することもでき、これは、しばしば監視クライアントに送信される更新済のプレゼンスデータに対するいくつかの通知をもたらすことになる。ＲＬＳ（リソースリストサーバ）と呼ばれる情報配信サーバは、次に、複数のクライアントの通知を収集し、かつすべての被観測クライアントに対する統合通知を監視クライアントへ送信するために使用することができ、これによって、通知の数を削減する。この統合通知には、膨大な量のデータを含む場合がある。
【００１４】
図２は、クライアントＢ、Ｃ及びＤにおける監視クライアントＡへ情報を提供するＲＬＳ２００を示していて、クライアントＢ、Ｃ及びＤはそれぞれ自身のプレゼンスサーバ２０６Ｂ、２０６Ｃ及び２０６Ｄへデータｐを発行する。ユーザリストデータベース２０８は、例えば、ＸＤＭＳ文書で特定される、電話帳、連絡グループ、アドホックグループあるいは、その類のような、加入クライアントのための様々なユーザリストを保持する。最初に示されるステップ２：１では、クライアントＡは、所定のユーザリストへのリファレンスによって示されるように、プレゼンスデータに対する加入リクエストをクライアントＢ、Ｃ及びＤへ送信する。次に、ステップ２：２では、ＲＬＳ２００は、データベース２０８からユーザリストをフェッチし、そして、ステップ２：３では、プレゼンスサーバ２０６Ｂ−Ｄからの通知として所望のデータを取得するために、クライアントＢ、Ｃ及びＤのプレゼンスデータに対するバックエンド加入をプレゼンスサーバ２０６Ｂ−Ｄとの間で確立する。最終のステップ２：４では、ＲＬＳ２００は、統合通知をクライアントＡへ送信する。これには、すべてのクライアントＢ−Ｄにおける所望のデータを含んでいる。
【００１５】
リソースデータへ加入する場合には、監視クライアントは、各加入リクエスト内に、どのリソースデータが被観測リソースから検索されるか定義するパラメータを含め、更には、監視クライアントへのデータの配信を指示するパラメータを含めなければならない場合がある。しかしながら、これらのパラメータは、典型的には、相対的に大量の情報を含んでいて、より大きな帯域幅を必要とする。また、同一のパラメータが、頻繁に、複数の加入リクエストで送信される。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
ここで、上述の既存のソリューションに関連していくつかの問題が存在する。ネットワークノード間の情報転送に対するキャパシティに制限があることを考慮すると、転送される情報が遅延することなく、あるいはネットワークノードに対する能力の損失を招くことなく、リソースデータを処理するためのシステムを設計することには課題がある。
【００１７】
本発明の目的は、上述のいくつかの課題に対処することである。特に、監視クライアントに対して、１つ以上のリソースに対するリソースデータを相対的に効率的に提供することを達成することを目的とする。これらの課題及びそれ以外の課題は、添付の請求項に従う解決策によって基本的には達成することができる。
【課題を解決するための手段】
【００１８】
一態様に従えば、少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバにおける方法が達成される。通知サーバでは、加入リクエストが受信される。この加入リクエストは監視クライアントから送信され、また、監視クライアントに対するデータベース内で予め構成設定されている少なくとも１つの通知ルールへのリファレンスを含んでいる。通知サーバは、リファレンスに従って、データベースから予め構成設定されている通知ルール（群）を取得することができる。次に、通知サーバは、少なくとも１つの通知ルール（群）を適用し、かつ、通知ルール（群）に基づいて少なくとも１つのリソースデータサーバからリソース（群）に関するリソースデータを検索することができる。通知サーバは、更に、リソースデータサーバ（群）からリソースデータを含む通知を受信することができる。通知サーバは、更に、通知ルール（群）に基づいて、監視クライアントへ通知を配信するための少なくとも１つの取得される通知ルール（群）を適用することができる。更に、通知サーバは、受信される加入リクエスト（群）をリソース（群）によって適用されるリソースデータモデルへ変換するための、あるいは検索されるリソースデータを監視クライアントによって適用されるリソースデータモデルへ変換するための、少なくとも１つの取得される通知ルールを適用することができる。
【００１９】
加入リクエストに、実際の通知ルールに代えて被観測リソース（群）に関する予め構成設定されている通知ルールへのリファレンスで補完することによって、監視クライアントに対する複数の加入リクエストで送信される情報の両方を削減することができる。また、適用されるリソースデータモデルの間で、加入リクエストと通知との少なくとも一方を変換することによって、送信される情報の量を更に削減することができる。
【００２０】
別の態様に従えば、少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバが達成される。通知サーバは、第１の通信リンク上の監視クライアントからのリソース（群）に関するリソースデータに対する加入リクエストを受信するように構成されている第１の通信ユニットを備える。この第１の通信ユニットは、更に、リソースデータを含む少なくとも１つの通知を第１の通信リンク上の監視クライアントへ配信するように構成されている。また、通知サーバは、加入リクエストで供給されるリファレンスを識別し、リファレンスに基づいてデータベースから通知ルールを取得するように構成されている通知ルールマネージャを備える。通知ルールマネージャは、更に、リソースデータサーバからリソースデータを検索し、検索されるリソースデータの少なくともいくつかを含む少なくとも１つの通知を形成するように構成されている。
【００２１】
通知サーバに通知ルール記憶ユニットが構成され、これは、通知ルールマネージャによって取得される通知ルール（群）がアップロードされるように構成されていて、更に、取得される通知ルール（群）を記憶するように構成されている。通知サーバにリソースデータ記憶ユニットが構成され、これは、リソースデータを記憶するように構成されている。
【００２２】
通知ルールマネージャは、更に、リソースデータの検索を実行するための、あるいは通知を形成するための、取得される通知ルール（群）の少なくとも１つを適用するように構成されている。
【００２３】
通知サーバは、リソースデータサーバとして動作する、あるいは外部リソースデータサーバからリソースデータを検索するように構成されている。通知サーバがリソースデータサーバとして動作する場合、通知ルールマネージャは、更に、リソースデータ記憶ユニットからリソースデータを検索するように構成されていても良い。
【００２４】
通知サーバが外部リソースデータサーバと通信する場合、通知サーバは、更に、通知サーバに構成されていても良い第２の通信ユニットを通じてリソースデータを検索するように構成されていても良い。第２の通信ユニットは、第２の通信リンク上のリソースデータサーバと通信するように構成されていても良い。通知サーバマネージャは、更に、監視クライアントと被観測リソース（群）とによって適用されるリソースデータモデルとの間で加入リクエスト（群）及び通知の少なくとも一方を変換するように構成されている変換ユニットを備えていても良い。変換ユニットは、少なくとも１つの取得される通知ルール（群）を適用するように構成されていても良い。
【図面の簡単な説明】
【００２５】
【図１】従来技術に従う、通知サーバに関連付けられている、監視クライアントとリソースを有する状況を示す基本的な外観を示す図である。
【図２】従来技術に従う、１つ以上のリソースデータサーバを介して通知サーバに関連付けられている１つ以上のリソースを有する状況を示す基本的な外観を示す図である。
【図３】一実施形態に従う、通知サーバに関連付けられている、監視クライアントと１つ以上のリソースデータを有する状況を示す基本的な外観を示す図である。
【図４】別の実施形態に従う、通知サーバに関連付けられている、監視クライアントと１つ以上のリソースデータを有する状況を示す基本的な外観を示す図である。
【図５】更に別の実施形態に従う、通知サーバを介して関連付けられている、監視クライアントと、１つ以上の通知サーバ／リソースデータサーバを有する状況を示す基本的な外観を示す図である。
【図６】更なる実施形態に従う、１つ以上の通知サーバ／リソースデータサーバに関連付けられている監視クライアントを有する状況を示す基本的な外観を示す図である。
【図７】更なる実施形態に従う、通知サーバで実行される１つ以上のリソースに対するリソースデータに加入するための手順を示すフローチャートである。
【図８ａ】更なる実施形態に従う、リソースデータへの加入を実現するための通知サーバを示すブロック図である。
【図８ｂ】更なる実施形態に従う、リソースデータへの加入を実現するための通知サーバを示すブロック図である。
【発明を実施するための形態】
【００２６】
簡潔に言えば、本発明は、監視クライアントがより効果的に１つ以上の被観測リソースからのリソースデータデータへ加入することができるソリューションを提供する。１つ以上の被観測リソースに関する通知ルールは、各加入リクエストで補完される代わりに、監視クライアントに対するデータベースにおいて事前に構成設定することができる。１つ以上の被観測リソースに対するリソースデータをリクエストする監視クライアントは、被観測リソース（群）に関する１つ以上のそのような事前に構成設定される通知ルールへのリファレンスで補完される加入リクエストを、通知サーバへ送信する。この通知サーバは、このリファレンスを使用して、データベースから事前に構成設定される通知ルールを取得し、取得される通知ルール（群）は被観測リソース（群）からリソースデータを検索するために適用される。
【００２７】
加えて、通知サーバあるいはリソースデータサーバの内の任意の１つに、リソースデータを１つのリソースデータモデルから別のリソースデータモデルへ変換するための変換部を提供することができる。
【００２８】
現在のアクセスネットワークに依存する様々な通知ルールを適用することで、リソースデータを伴う通知を被観測クライアントへ配信することを、適用される通知ルール（群）に従って制御するようにすることができる。通知ルールは、配信フィルタによって定義することができ、この配信フィルタは、例えば、一定のタイプのリソースデータを伴う通知、最大データ量を越えない通知、１つ以上の特定の被観測リソースの通知、あるいは一日、１週間、１シーズンの内の一定の時間での通知の配信のみを許容するものである。
【００２９】
本明細書の全体を通して、用語「通知ルール」は、どのデータが検索されるか、あるいはどのようにしてデータが監視クライアントへ提示されるか等についてを定義する任意のルールを参照する。このような通知ルールは、典型的には、加入リクエストに補完される。「フィルタ」は、少なくとも１つのルールを示し、または、異なる種類のフィルタは異なるセットの通知ルールに定義することができる。例えば、配信フィルタは、リソースデータをどのようにして監視クライアントへ配信されるかに関する通知ルールを含むことができ、プレゼンスフィルタは、ウォッチャーに対してどのリソースデータに関心があるかを示すことができる。
【００３０】
フィルタ群、例えば、配信フィルタとプレゼンスフィルタは、データベース内のファイルとして記憶することができる。配信フィルタはトリガフィルタとして実現することができ、プレゼンスフィルタは周知の規格に従うホワットフィルタ（what filter）として実現することができる。このようなホワットフィルタは、どのリソースデータが監視クライアントに対して関心があるのかについて定義する。トリガフィルタは、監視クライアントに通知されるべきパラメータのステータス変更を定義する。以下の例は、ＲＦＣ４６６０／４６６１に従う、ホワットフィルタの実装の使用を示している。
SUBSCRIBE sip:List1@example.com SIP/2.0
...
＜?xml version="1.0" encoding="UTF-8"?＞
＜filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"＞
＜ns-bindings＞
＜ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/＞
＜/ns-bindings＞
＜filter id="999" uri="sip:sarah@example.com"＞
＜what＞
＜include type="namespace"＞
urn:ietf:params:xml:ns:pidf＜/include＞
＜exclude＞
//pidf:tuple/pidf:note＜/exclude＞
＜/what＞
＜/filter＞
＜filter id="8439" uri="sip:alice@biloxi.com"＞
＜what＞
＜include＞
//pidf:tuple/pidf:status/pidf:basic＜/include＞
＜/what＞
＜/filter＞
＜/filter-set＞
しかしながら、本発明はこれに限定されるものではなく、どのリソースデータが検索されるかあるいは監視クライアントへ配信されるかについて定義する任意の適切なフィルタを、上述の方法で実現することができる。例えば、監視クライアントと被観測リソースが異なるリソースデータモデルを適用する場合、どのようして１つリソースデータモデルを別のリソースデータモデルへ変換しても良いかを定義するパラメータ群を、ホワットフィルタあるいはトリガフィルタの任意のもので実現することができる。
【００３１】
通知ルールはレート限定を含むこともでき、そうすることで、通知の頻度を所定の限度を越えないようにする、例えば、１時間に１回を越えないようにする、あるいは３時間毎にする等にする。加入リクエストで与えられるタイムアウトあるいはＴＴＰパラメータに依存する通知の配信を、例えば、異なる通知ルールを選択することによって制御することもできる。例えば、ＴＴＬはゼロに設定する場合、すべての通知の配信を許容することができる、あるいは配信フィルタ「ｘ」を選択的に適用することができる、一方、タイムアウトパラメータが０より大きい一定の時間期間に設定される場合、これ以上の通知の配信を許容しないようにすることができる、あるいは配信フィルタ「ｙ」を選択的に適用することができる。
【００３２】
本明細書では、用語「通知サーバ」は、通知内の１つ以上の被観測リソースのリクエストされたリソースデータを許可済の監視クライアントへ提供することができる任意のサーバを表すために使用され、これには、例えば、図１及び図２それぞれで示されるプレゼンスサーバあるいはＲＬＳノードがある。リファレンスは、周知のＳＩＰメッセージによって作成されることになるが、本発明は、一般的にはこれに限定されない。
【００３３】
また、本明細書における、通知サーバ、リソースデータサーバ、加入クライアント、リソース及びデータベースは、機能を提供する任意の追加の汎用的な手段を備えることができ、これには、例えば、様々な制御ユニット及びメモリ、適切に動作するために必要とされる一般的な機能及び特徴があることが理解されるべきである。しかしながら、簡略化のために、加入サービスを実現する本提案を理解するために必要のない任意の手段あるいは機能は図面では省略し、また、本明細書では更なる詳細は説明しない。
【００３４】
図３−図６に関して、本発明のいくつかの実施形態を説明する。このソリューションは、リソースリストサーバ（ＲＬＳ）があってもなくても実行することができる。また、通知サーバは、ＲＬＳとしても、あるいは任意の適切なリソースデータサーバとして実現することができる。また、本実施形態に従って説明されるリソースデータサーバは、２つ以上の被観測リソースにサービスを提供することができる。簡略化のために、１つの被観測リソースだけが図中の各リソースデータサーバに関連付けられているとし、これは、本発明の範囲を制限するものではない。以下の図では、１つの端末だけが各クライアントに関連付けられている。しかしながら、当業者は、２つ以上の端末を複数のクライアント、例えば、１つのユーザ機器と１つのコンピュータにどのようにして関連付けるかについて理解している。
【００３５】
図３を参照して、監視クライアントＡが、被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対する通知サーバ３００からの所望のリソースデータへ加入する状況の実施形態を説明する。この場合、通知サーバは、ＲＬＳとして実現される。最初のステップ３：１では、リソースデータへ加入する監視クライアントＡは、加入リクエストを通知サーバ３００へ送信することによって加入を開始する。ここで、加入リクエストは、通知サーバがアクセスすることができるデータベース３０２において予め構成設定される１つ以上の通知ルールへのリファレンス（図では、＜ｒｅｆ＞で示されている）で補完されている。通知ルール（群）は、フィルタとしてデータベース３０２に記憶することができ、これは、例えば、ＸＭＬ−フォーマット（拡張マークアップ言語）に従ってフォーマットされている。データベース３０２は、本明細書では、ＸＤＭＳ（ＸＭＬ文書管理サーバ）として実現される。加入リクエストは、加入メッセージ、例えば、加入＜ｒｅｆ＞として実現することができる。しかしながら、本発明はこれに限定されず、加入リクエストは使用されるリソースデータモデルに従う任意の他の適切なメッセージとして実現することもできる。
【００３６】
次に、続くステップ３：２では、通知サーバ３００は、データベース３０２から通知ルール（群）を取得するために、受信したリファレンスを使用する。通知ルール（群）を取得することは、ＸＣＡＰ（ＸＭＬコンフィグレーションアクセスプロトコル）、ＲＦＣ４８２５に従う、ＨＴＴＰ  ＧＥＴ（取得）動作として実行することができる。しかしながら、本発明はこれに限定されず、通知ルールを取得するための任意の他の適切なプロトコルを上述の方法で使用することができる。
【００３７】
続くステップ３：３では、通知サーバ３００は、被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対するリソースデータサーバ３０４ａ、ｂ、ｃ、．．．の内の少なくとも１つからリソースデータを検索する。この検索は、いわゆるバックエンド加入によって実行されても良く、また、加入リクエストを通知サーバ３００からリソースデータサーバ３０４ａ、ｂ、ｃ、．．．の内の少なくとも１つへ送信し、それから１つ以上の通知を受信することによって実現することができる。加入リクエストは、加入メッセージとして実現することができる。この通知は、通知メッセージとして実現することができ、これには、どのリソースが監視クライアントＡへ供給されることを同意しているかについてのリソースデータを含んでいる。典型的には、取得される通知ルールは、どの被観測リソースがその通知ルールに関連しているかに基づいて通知サーバ３００によって分割することができ、各被観測リソースＢ、Ｃ、Ｄ、．．．に関連する通知ルールだけが、被観測リソースＢ、Ｃ、Ｄ、．．．に対する加入リクエストに補完されることになる。また、１つの通知ルールが２つ以上の被観測リソースに関連している場合、その通知ルールは、その通知ルールに関連する各被観測リソースＢ、Ｃ、Ｄ、．．．に対する加入リクエストに補完されることになる。
【００３８】
最終のステップ３：４では、所望のリソースデータが、取得される通知ルール（群）に従って監視クライアントＡに配信される。このような通知ルールは、監視クライアントＡがどのような頻度で被観測リソースＢ、Ｃ、Ｄ、．．．に対するリソースデータの更新に関して通知されることになるか、また、どのリソースデータが監視クライアントに対して関心のあるものであるかについて定義しても良く、また、別の通知ルールは監視クライアントＡが更新を受信するために利用可能である場合を定義しても良い。リソースデータは、１つ以上の通知に含まれていても良く、これは、通知メッセージとして、あるいは使用されるリソースデータモデルに適切な他のメッセージとして実現することができる。どのようにして監視クライアントへ通知するべきか、例えば、どのような頻度で、どのリソースデータが更新されるかに関して、等を配信フィルタとして定義することができる。
【００３９】
この実施形態では、通知サーバ３００はＲＬＳとして実現され、データベース３０２はＸＤＭＳとして実現され、リソースデータサーバ３０４ａ、ｂ、ｃ、．．．はプレゼンスサーバとして実現される。しかしながら、これらのサーバとデータベースは任意の他の適切な通信ノードとして実現されても良い。また、１つ以上のサーバとデータベースが１つの同一のード内で実現されても良い。
【００４０】
図４を参照して、監視クライアントＡが、被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対する通知サーバ４００からの所望のリソースデータへ加入する状況の別の実施形態を説明する。ステップ４：１と４：２はそれぞれ、図３を参照して説明される実施形態のステップ３：１と３：２に対応するので、ここでは、説明を必要としない。
【００４１】
次のステップ４：３では、図３を参照して説明される実施形態のステップ３：３とは異なり、通知サーバ４００が被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対するリソースデータサーバ４０４ａ、ｂ、ｃ、．．．の内の少なくとも１つから所望のリソースデータを検索する。これは、取得される通知ルール（図では＜フィルタ＞で示される）の内の少なくとも１つを加入リクエストに補完することによって行う。この通知ルールは、リソースデータサーバ４０４ａ、ｂ、ｃ、．．．の内の少なくとも１つによって適用されるものである。そのような通知ルールは、例えば、どのリソースデータが監視クライアントによって所望されるかについてを定義することができる。また、上述の実施形態のように、ステップ４：１と４：３では、加入リクエストは加入メッセージとして実現することができ、また、所望のリソースデータは１つ以上の通知として検索することができる。つまり、ステップ４：３で送信される加入リクエスト（群）は上述の実施形態のステップ３：３で送信される加入リクエスト（群）とは異なり、少なくとも１つの通知ルールによって補完される。
【００４２】
最終のステップ４：４では、所望のリソースデータが、取得される通知ルール（群）に従って監視クライアントＡに配信される。このステップは、基本的には、図３を参照して説明される実施形態のステップ３：４に等しい。
【００４３】
また、この実施形態では、記載されるサーバ４００、４００ａ、ｂ、ｃ、．．．とデータベース４０２は１つ以上の適切な通信ノード（群）として実現することができる。
【００４４】
図５を参照して、監視クライアントＡが、被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対する通知サーバ５００からの所望のリソースデータへ加入する状況の更なる別の実施形態を説明する。この実施形態と、図３及び図４を参照して説明される実施形態との違いは、リソースデータサーバ（群）５０４ａ、ｂ、ｃ、．．．が通知サーバとしても動作し、かつ通知サーバ５００に代って自身で所望の通知ルール（群）を取得することである。リソースデータサーバ５０４ｂ、ｃ、．．．と、被観測リソースＣ、Ｄ、．．．は、図では示されていない。
【００４５】
ステップ５：１は、基本的には、図３を参照して説明されるステップ３：１に等しい。それゆえ、ここでは、その詳細については説明しない。続くステップ５：２では、通知サーバ５００は、受信した加入リクエストをリソースデータサーバ（群）５０４ａ、ｂ、ｃ、．．．へ転送する。次に、更に続くステップ５：３では、補完されるリファレンスに従って、自身でデータベース５０２から通知ルール（群）を取得する。典型的には、データベース５０２は監視クライアントＡの通信ネットワークに関連付けて、そして監視クライアントＡに関心のある被観測リソース（群）Ｂ、Ｃ、Ｄ、．．．に関する予め構成設定される通知ルール（群）を記憶することができる。データベース５０２は、例えば、ＸＣＡＰに従って、ネットワーク間インタフェース５０６を介して各通知サーバ５０４ａ、ｂ、ｃ、．．．によってアクセスすることができる。しかしながら、本発明はこれに限定されず、データベースは、通知サーバ（群）５０４ａ、ｂ、ｃ、．．．がアクセスすることができる、別の適切なネットワークに関連付けられていても良い。
【００４６】
更に別のステップ５：４では、通知サーバ（群）５０４ａ、ｂ、ｃ、．．．は、所望のリソースデータを検索する。これに応じて、ステップ５：４に対して、続くステップ５：５では、通知サーバ５０４ａ、ｂ、ｃ、．．．は、取得される通知ルール（群）に従って、所望のリソースデータを通知として監視クライアントＡへ配信する。しかしながら、更に続くステップ５：６では、この通知は通知サーバ５００を介して転送される。
【００４７】
この実施形態では、通知サーバ５００は、通知サーバ（群）５０４ａ、ｂ、ｃ、．．．に送信される、受信した加入リクエストに影響を与えないし、また、監視クライアントＡに送信される通知にも影響を与えない。しかしながら、当業者は、通知サーバ５００を変更して、例えば、通知サーバ５００によって加入リクエスト（群）あるいは通知に更なる通知ルール（群）を適用することを可能にする、あるいは加入リクエスト（群）及び通知の少なくとも一方に更なる通知ルール（群）に影響を与えることが可能であることに注意すべきである。
【００４８】
図６を参照して、監視クライアントＡが、被観測リソースＢ、Ｃ、Ｄ、．．．の内の少なくとも１つに対する通知サーバ６００からの所望のリソースデータへ加入する状況の更なる別の実施形態を説明する。リソースデータサーバ５０４ｂ、ｃ、．．．と被観測リソースＣ、Ｄ、．．．は図では示されていない。この実施形態と、図５を参照して説明される実施形態との違いは、通知サーバ６００が被観測リソース（群）Ｂ、Ｃ、Ｄ、．．．に対するリソースデータサーバとして動作すること、即ち、監視クライアントＡが被観測リソース（群）Ｂ、Ｃ、Ｄ、．．．として同一の通信ネットワークに関連付けられ、かつ別個の通知サーバが存在しないことである。
【００４９】
ステップ６：１では、リソースデータに加入する監視クライアントＡは、加入リクエストを通知サーバ６００へ送信することによって加入を開始し、この加入リクエストは、通知サーバがアクセスすることができるデータベース６０２内で予め構成設定されている１つ以上の通知ルールへのリファレンス（図６では＜ｒｅｆ＞で示される）で補完されている。次に、ステップ６：２では、通知サーバ６００は、データベース６０２から通知ルール（群）を取得するために受信されるリファレンスを使用する。しかしながら、この実施形態でも、通知ルール（群）を、上述の実施形態のように、ネットワーク間インタフェース６０６を介して取得することができる。続くステップ６：３では、所望のリソースデータが検索される。そして、ステップ６：４では、検索されるリソースデータが取得される通知ルール（群）に従って監視クライアントＡへ配信される。
【００５０】
図７を参照して、通知サーバが、少なくとも１つの被観測リソースを提供するリソースデータサーバからのリソースデータへの加入を処理する実施形態を説明する。この実施形態に従う加入は、加入クライアントによってリクエストされる。この実施形態に従えば、以下のステップ群が通知サーバにおいて実行される。
【００５１】
最初のステップ７００では、通知サーバは、少なくとも１つの被観測リソースに関するリソースデータに対する加入リクエストを受信する。この加入リクエストは監視クライアントから送信される。この加入リクエストは、データベース内で予め構成設定されている少なくとも１つの通知ルールへのリファレスを含んでいる。この加入リクエストは、例えば、ＳＩＰ（セッション開始プロトコル）に従う加入＜ｒｅｆ＞であるリファレンスで補完される加入メッセージとして実現されても良い。
【００５２】
次に、別のステップ７０２では、通知サーバは、そのリファレンスに従ってデータベースから予め構成設定される通知ルールを取得する。この取得は、ＸＣＡＰに従うＨＴＴＰ  ＧＥＴ動作として実行することができる。また、通知サーバとデータベースが同一の通信ネットワークに関連付けられていない場合では、この取得は、上述の実施形態で示されるネットワーク間インタフェース（ＮＮＩ）を介して実行することができる。取得される通知ルール（群）は、例えば、どのリソースデータが監視クライアントによって所望されるか、どのリソースデータの更新を監視クライアントが受信することになるか、どのくらいの頻度で監視クライアントが更新されるか等を定義することができる。どのリソースデータが監視クライアントの関心にあるかを定義する通知ルールは、ホワットフィルタあるいはプレゼンスフィルタで定義することができる。いつリソースデータステータス変更で監視クライアントが更新されることになるか、及びどのリソースデータステータス変更で監視クライアントを更新されることになるかについての少なくとも一方についてを定義する通知ルールは、トリガフィルタあるいは配信フィルタとして定義することができる。
【００５３】
続くステップ７０６では、リソースデータサーバによって提供される被観測リソース（群）に関するリソースデータが検索される。通知サーバが少なくとも１つのリソースデータサーバでサービスを提供する場合には、この検索はいわゆるバックエンド加入によって実行することができる。この通知サーバは、リソースデータサーバが供給することに同意するすべてのリソースデータ（図３を参照して説明される）、あるいは所望のリソースデータ（図４を参照して説明される）を検索することができる。所望のリソースデータを検索する場合には、通知サーバは取得される通知ルール（群）を分割して、各リソースデータサーバから、監視クライアントによって所望されるリソースデータだけをリクエストする。
【００５４】
リソースデータサーバが通知サーバとしても動作する場合（図５及び図６を参照して説明される）には、リソースデータサーバは、リソースデータサーバによるアクセスを有する記憶ユニット（不図示）から所望のリソースデータを検索する。この記憶ユニットは、リソースデータサーバ内の別個のデータベースあるいは内部記憶ユニットとして実現される。ステップ７０６で説明される各場合に従うリソースデータの検索は、加入メッセージと通知によって実現することができる。
【００５５】
最終のステップ７１０では、通知サーバは、所望のリソースデータで補完される通知の監視クライアントへの配信を制御する。この通知は、ステップ７０２で取得される通知ルールの少なくとも１つに従って監視クライアントへ送信され、この通知ルール（群）は監視クライアントへの通知の配信を調整するように意図されている。典型的には、このような通知ルールはトリガフィルタで定義される。
【００５６】
ステップ７０２とステップ７０６との間で実行されるオプションの中間のステップ７０４では、リソースデータサーバによって、加入リクエストが別のリソースデータモデルに変換され、適用されても良い。しかしながら、ステップ７０４はオプションのステップであり（図では破線で示される）、異なるリソースデータモデルが監視クライアントとリソースデータサーバによって適用される場合に実行されることになる。
【００５７】
ステップ７０６とステップ７１０との間で実行される、別の中間のステップ７０８では、監視クライアントによって、通知がリソースデータモデルに変換され、適用されても良い。この追加のステップ７０４とステップ７０８の両方に従えば、ステップ７０２で取得される通知ルールの少なくとも１つは、異なるリソースデータモデル間の変換を定義することができる。
【００５８】
別の実施形態では、上述の実施形態に基づいて、リソースデータサーバが（図５を参照して説明される）通知サーバとしても動作する。この別の実施形態に従うステップ７００と、上述の実施形態との違いは、監視クライアントによって送信される加入リクエスト（群）が別の通知サーバを介して転送されることであり、この別の通知サーバは、影響を受けることなく監視クライアントに関連付けられている。これに対応して、ステップ７１０と、上述の実施形態との違いは、監視クライアントへ送信される通知が、影響を受けることなく、監視クライアントへ転送されることである。ブロック図を示す図８ａと図８ｂとを参照すると、被観測リソースに関するリソースデータを監視クライアントへ提供するための通知サーバ８００、８００’の２つの実施形態が説明される。通知サーバ８００、８００’は、第１の通信ユニット８０２、通知サーバマネージャ８０４、８０４’、通知ルール記憶ユニット８０６、オプションの第２の通信ユニット８０８、及びリソースデータ記憶ユニット８１０を備える。
【００５９】
第１の通信ユニット８０２は、通信リンク８２０上の監視クライアント（不図示）から送信される加入リクエストを受信するように構成されている。この加入リクエストは、監視クライアントに対するデータベース８５０において予め構成設定されている少なくとも１つの通知ルールへのリファレンスを含んでいる。通知サーバマネージャ８０４、８０４’は、このリファレンスに基づいて予め構成設定されている通知ルール（群）を取得するように構成されている。通知サーバマネージャ８０４、８０４’は、加入リクエストに含まれるリファレンスを処理するように構成されているリファレンスユニット８０４ａを備えている。このリファレンスユニット８０４ａは、取得のために使用されるリファレンスを識別するように構成されている。この取得は、上述の実施形態で説明されるように、ＨＴＴＰ  ＧＥＴ動作によって実行することができる。また、データベース８５０が通知サーバ８００として同一のネットワークに関連付けられていない場合、この取得は、ネットワーク間インタフェース（ＮＮＩ）（破線で示される）を介して実行されても良い。
【００６０】
通知ルール記憶ユニット８０６は、通知サーバマネージャ８０４、８０４’から取得される通知ルール（群）を受信し、それらを記憶するように構成されている。また、通知ルール記憶ユニット８０６は、上述の実施形態で説明されるように、ホワットルールとトリガルール等の、異なるカテゴリの通知ルールを記憶することができる。
【００６１】
通知サーバマネージャ８０４、８０４’は、更に、取得されるリソース（群）に関するリソースデータを検索するように構成されている。この検索は、内部リソースデータ記憶ユニット８１０（以下で説明する）から、あるいは第２の通信リンク８２２を介するリソースデータサーバ（不図示）から、実行することができる。通知サーバ８００は、図５及び図６で示される方法（図８ａで示される通知サーバ）を実行するように構成されている。一方、通知サーバ８００’は、図３及び図４で示される（図８ｂで示される）方法を実行するように構成されている。
【００６２】
通知サーバマネージャ８０４’は、更に、取得される通知ルール（群）を分割して、各被観測リソースに対して関連する通知ルール（群）を提供するように構成することができる。選択的には、検索は、通知ルール（群）を適用することなく実行することができる。この場合（図３を参照して説明される）では、通知サーバマネージャ８０４、８０４’は、被観測リソースの任意の１つが監視クライアントへ供給することを同意するリソースデータのすべてを検索するように構成されている。
【００６３】
リソースデータがリソースデータサーバ（図８ｂを参照する）から検索されることになる場合、通知サーバ８００’は、通知サーバマネージャ８０４’によって形成されるリソースデータに対するリクエストあるいはリクエスト群を受信し、そのリクエスト（群）を第２の通信リンク８２２上のリソースデータサーバ（不図示）へ送信するように構成されている。このリソースデータサーバは、被観測リソース（群）に対するリソースデータのアクセスを有している。第２の通信ユニット８０８は、更に、例えば、バックエンド加入として、第２の通信リンク８２２上のリソースデータサーバから、リクエストされるリソースデータを受信するように構成されている。リソースデータサーバからのリソースデータの検索は、１つ以上のバックエンド加入によって実行することができる。通知サーバマネージャ８０４’は、更に、第２の通信ユニットが受信しているリソースデータを受信し、そして、それらをリソースデータ記憶ユニット８１０に記憶するように構成されている。
【００６４】
通知サーバマネージャ８０４、８０４’は、通知の配信を調整することが意図される任意の取得される通知ルール（群）、例えば、トリガフィルタで定義される通知ルールに基づいて、記憶されているリソースデータの少なくともいくつかを備える１つ以上の通知を形成するように構成されている。第１の通信ユニット８０２は、更に、形成される通知（群）を受信し、それらを第１の通信リンク８２０上の監視クライアントへ送信するように構成されている。
【００６５】
加えて、通知サーバマネージャ８０４、８０４’は、２つのリソースデータモデルとの間でメッセージと加入を変換するように構成されている変換部８０４ｂを備えることもできる。変換部８０４ｂは、取得される通知ルール（群）の少なくとも１つを適用し、被観測リソースからのリソースデータに対するリクエスト（群）を、リソースデータサーバによって適用されるリソースデータモデルへ変換するように構成されている。これに対応して、変換部８０４ｂは、また、被観測リソースから受信されるリソースデータを、監視クライアントによって適用されるリソースデータモデルへ変換するように構成されている。変換部８０４ｂはリソースデータサーバへ送信されるリクエストと、リソースデータサーバから受信される通知を変換するために実現され、当業者は、これに代えて、監視クライアントから受信されるリクエストと、監視クライアントへ送信される通知を変換するための機能を、変換部８０４ｂで実現することができることに注意すべきである。変換部の機能は、任意の適切なハードウェアとソフトウェアの少なくとも一方によって実際には実現することができる。
【００６６】
選択的には、上述の任意の実施形態に従って、第１の通信ユニット８０２によって受信される加入リクエスト（群）は、別の通知サーバ（不図示）を介して受信することができる。
【００６７】
上述の実施形態におけるメッセージと通知はＳＩＰに従うメッセージとして実現されているとしても、その代わりに、任意の他の適切なプロトコル、例えば、ＨＴＴＰ、ＴＣＰ、ＳＭＰＰ、あるいはＳＭＴＰを使用することができる。
【００６８】
また、上述の実施形態に従う通知サーバ８００、８００’は、別個の、通信するためのユニット、記憶するためのユニット、及びリソースデータを管理するためのユニットを備えているが、これに限定されるものではない。当業者は、１つの同一のユニットにおいてこれらのユニットの任意の機能を実現することができる。例えば、通知ルール記憶ユニット８０６の機能と、データ記憶ユニット８１０の機能は、通知ルールマネージャ８０４、８０４’において実現されても良い。
【００６９】
上述の実施形態を示す図では、通知サーバとリソースデータサーバはそれぞれ、リソースリストサーバ（ＲＬＳ）とプレゼンスサーバ（ＰＳ）として実現されている。しかしながら、当業者は、任意の適切なハードウェアあるいはソフトウェアによって、例えば、任意の適切な通知サーバあるいはリソースデータサーバによって、実際にはこれらの機能を実現することができる。
【００７０】
本発明によって、１つ以上の被観測リソースに対するリソースデータに効果的に加入する方法が達成される。監視クライアントは、実際の通知ルール（群）に代えて、被観測リソース（群）に関する予め構成設定されている通知ルール（群）へのリファレンスを、加入リクエスト（群）に補完する。それゆえ、監視クライアントに対する複数の加入リクエスト（群）で送信される情報の量は削減されることになる。また、監視クライアントと被観測リソース（群）との間で送信されるリソースデータを１つの同一のリソースデータモデルに変換することによって、情報量を更に削減することができる。
【００７１】
本発明は、一般的には、以下の請求項によって定義される。
【００７２】
略語リスト
ＩＰ        インターネットプロトコル
ＩＭＳ      ＩＰマルチメディアサブシステム
ＳＩＰ      セッション開始プロトコル
ＸＭＬ      拡張マークアップ言語
ＸＤＭＳ    ＸＭＬ文書管理サーバ
ＸＣＡＰ    ＸＭＬコンフィグレーション（構成設定）アクセスプロトコル
ＲＬＳ      リソースリストサーバ
ＰＳ        プレゼンスサーバ
【図１】
2012518326.tif 000003
【図２】
2012518326.tif 000004
【図３】
2012518326.tif 000005
【図４】
2012518326.tif 000006
【図５】
2012518326.tif 000007
【図６】
2012518326.tif 000008
【図７】
2012518326.tif 000009
【図８ａ】
2012518326.tif 000010
【図８ｂ】
2012518326.tif 000011
【手続補正書】
【提出日】平成22年12月10日(2010.12.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバにおける方法であって、
前記少なくとも１つのリソースに関するリソースデータに対する前記監視クライアントから送信される加入リクエストとして、前記監視クライアントに対するデータベース内で予め構成設定されているフィルタで定義される少なくとも１つの通知ルールへのリファレンスを含む加入リクエストを受信するステップ（７００）と、
前記リファレンスに基づいて、リソースデータを含む通知の前記監視クライアントへの配信を制御するステップ（７１０）と
を備えることを特徴とする方法。
【請求項２】
前記制御するステップは、更に、
前記リファレンスに従って前記データベースから前記少なくとも１つの通知ルールを取得すること（７０２）と、
リソースデータサーバからリソースデータを検索する（７０６）ために、あるいは前記通知を配信する（７１０）ために、取得される前記通知ルール（群）の少なくとも１つを適用すること
を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
取得される前記通知ルールの少なくとも１つは、
受信される前記加入リクエストを前記監視クライアントによって適用されるリソースデータモデルから前記少なくとも１つのリソースによって適用されるリソースデータモデルへ変換すること（７０４）、
あるいは
検索される前記リソースデータを前記少なくとも１つのリソースによって適用されるリソースデータモデルから前記監視クライアントによって適用される前記リソースデータモデルへ変換すること（７０８）
のいずれかのために適用される
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記フィルタは、ＸＭＬフォーマットに従ってフォーマットされ、
前記データベースは、ＸＤＭＳに記憶されている
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記フィルタは、
リソースデータの一定のタイプを含む通知、
最大データ量を越えない通知
１つ以上の特定のリソースに対する通知、
一日、１週間、１シーズンの内の一定の時間での通知
の少なくとも１つに関する通知ルールを定義する
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記フィルタは、リクエストメッセージと通知の、第１のリソースデータモデルから第２のリソースデータモデルへの変換に関する通知ルールを定義する
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
少なくとも１つのリソースに関するリソースデータを監視クライアントへ提供するための通知サーバ（８００、８００’）であって、
第１の通信リンク（８２０）上の前記監視クライアントからの前記リソースに関する前記リソースデータに対する加入リクエストを受信し、前記リソースデータを含む少なくとも１つの通知を前記第１の通信リンク（８２０）上の前記監視クライアントへ配信するように構成されている第１の通信ユニット（８０２）と、
前記加入リクエストで供給されるリファレンスを識別し、前記リファレンスに基づいてデータベース（８５０）からフィルタで定義される少なくとも１つの通知ルールを取得し、前記リソースデータを検索し、前記リソースデータの少なくともいくつかを含む少なくとも１つの通知を形成するように構成されている通知ルールマネージャ（８０４、８０４’）と、
前記通知ルールマネージャ（８０４、８０４’）によって取得される前記通知ルール（群）がアップロードされて、前記取得される通知ルール（群）を記憶するように構成されている通知ルール記憶ユニット（８０６）と、
リソースデータを記憶するように構成されているリソースデータ記憶ユニット（８１０）とを備え、
前記通知ルールマネージャ（８０４、８０４’）は、更に、リソースデータの検索を実行するための、あるいは前記通知を形成するための、取得される前記通知ルール（群）の少なくとも１つを適用するように構成されている
ことを特徴とする通知サーバ（８００、８００’）。
【請求項８】
前記通知ルールマネージャ（８０４、８０４’）は、更に、前記取得される通知ルール（群）を分割し、各被観測リソースに対して関連のある前記取得される通知ルール（群）を適用するように構成されている
ことを特徴とする請求項７に記載の通知サーバ（８００、８００’）。
【請求項９】
前記通知ルールマネージャ（８０４）は、更に、前記リソースデータ記憶ユニット（８１０）から前記リソースデータを検索するように構成されている
ことを特徴とする請求項７または８に記載の通知サーバ（８００、８００’）。
【請求項１０】
前記通知ルールマネージャ（８０４’）は、更に、リソースデータサーバから前記リソースデータを検索するように構成されていて、
当該通知サーバ（８００’）は、第２の通信リンク（８２２）上の前記リソースデータサーバから前記リソースデータの検索を実行するように構成されている第２の通信ユニット（８０８）を備え、
前記リソースデータ記憶ユニット（８１０）は、更に、前記通知ルールマネージャ（８０４’）によって検索される前記リソースデータでアップロードされるように構成されている
ことを特徴とする請求項７または８に記載の通知サーバ（８００、８００’）。
【請求項１１】
前記第１の通信ユニット（８０２）から受信される加入リクエスト（群）を、前記監視クライアントによって適用されるリソースデータモデルから、少なくとも１つの前記リソースによって適用されるリソースデータモデルへ変換すること、
前記第１の通信ユニット（８０２）によって送信される通知を、少なくとも１つの前記リソースによって適用されるリソースデータモデルから、前記監視クライアントによって適用される前記リソースデータモデルへ変換すること
の少なくとも１つに対して、前記取得される通知ルールの少なくとも１つを適用するように構成されている変換ユニット（８０４ｂ）を更に備える
ことを特徴とする請求項７乃至１０のいずれか１項に記載の通知サーバ（８００、８００’）。
【国際調査報告】
2012518326.tif 000012
2012518326.tif 000013
2012518326.tif 000014