JP2010500840A - プレゼンス属性に基づくプレゼンス通知システム及び方法 - Google Patents

Abstract

プレゼンス通知を最適化するシステム及び方法を提供する。このシステムは、プレゼンス登録及びプレゼンス情報を格納するプレゼンスサーバと、認証関連情報を格納するプレゼンスＸＤＭサーバ（ＸＤＭＳ）と、を具備し、このプレゼンスサーバは、プレゼンス属性に基づく通知伝達に関するフィルタリング規則を格納する。また、この方法は、プレゼンスサーバがプレゼンス登録及びプレゼンス情報を格納するステップと、プレゼンスＸＤＭサーバ（ＸＤＭＳ）が認証関連情報を格納するステップと、を具備し、プレゼンス属性に基づく通知伝達に関するフィルタリング規則が前記プレゼンスサーバとともに使用される。

Description

本発明は、ネットワークを介したネットワーキング及び通信に関する。本発明は、オープンモバイルアライアンス（Open Mobile Alliance：以下、“ＯＭＡ”と称する。）プレゼンス及びアベイラビリティワーキンググループ（Availability Working Group）により定義されたユーザーのプレゼンス情報を通知する手続きに適用されることができる。言い換えれば、本発明は、セッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）技術に関し、プレゼンス通知を最適化することを目標としている。より具体的に、本発明は、プレゼンス通知を最適化するためのプレゼンス属性に基づくプレゼンス通知システム及び方法に関する。

プレゼンスシステム構成は、任意のユーザーのプレゼンス情報を他のユーザーと共有することをサポートする。プレゼンス情報は、基本的にユーザーの現在の位置、ユーザーに関する使用可能な接続情報又はインスタントメッセージ関連情報、ユーザーがインスタントメッセージング（Instant Messaging：以下、“ＩＭ”と称する。）でオンラインであるかオフラインであるか、プッシュツートークオーバーセルラー（Push to Talk Over Cellular：以下、“ＰｏＣ”と称する。）特定属性のようなアプリケーション特定情報などのユーザー関連情報である。現在では、ユーザーは、要求されるユーザーのプレゼンス情報を登録(subscribe)する必要があり、他のユーザーは、このユーザーが自身のプレゼンス情報を見ることを認証する。プレゼンスサーバエンティティー（Presence Server Entity）は、プレゼンス登録を保持し、ユーザーのプレゼンス情報を格納する。ユーザーのプレゼンス情報が変更されると、プレゼンスサーバは、この通知をウォッチャー（Watcher）に送信する。ウォッチャーは、基本的にユーザーのプレゼンス属性を見ることを認証されるユーザーである。現在、ユーザーがプレゼンス情報を登録すると、このユーザーは、プレゼンス情報変更の通知を継続して受信する。ＳＩＰ ＳＵＢＳＣＲＩＢＥ方法及びＳＩＰ ＮＯＴＩＦＹ方法は、この登録及び通知のために使用される。このような方法では、ネットワークオペレータの主な関心事である巨大な量の通知及びパブリッシュトラフィック（Traffic）がある。ユーザーの数が増加するに従って、負荷は、それ以上増加する。先行技術によると、不必要な通知トラフィックがネットワークエンティティー及びアクセスネットワークを介して流れる場合がある。

先行技術は、プレゼンス情報に関するフィルターを通知ボディー（Body）に定義することをサポートしている。通知ボディーは、プレゼンティティ（Presentity）の各種のプレゼンス情報でなされる。ユーザーに関するプレゼンス属性が多数存在するので、ウォッチャーは、すべてのプレゼンス属性ついて関心を有しているわけではない。これは、ＳＵＢＳＣＲＩＢＥボディーにフィルターを定義することにより実現される。ユーザーは、要求されるプレゼンス属性を登録するにあたり、フィルタリングをサポートするフィルター規則を登録ボディーに定義する。このフィルター規則は、ＩＥＴＦドラフト“イベント通知フィルタリングdraft-ietf-simple-event-filter-funct-05の機能説明（Functional Description of Event Notification Filtering draft-ietf-simple-event-filter-funct-05）”に定義されている。また、このようなフィルタリング規則は、一部のプレゼンス属性に対する特定の条件を設定することにより、通知を送信する時期に対する規則も定義している。例えば、使用可能なプレゼンス属性に対する状態がオフラインからオンラインに変更されると、この通知を送信する。このような種類のフィルタリング規則は、登録要請のボディーに割り当てられることができるので、このフィルタリング規則は、コンテンツレベルを設定するのに使用される。

上述した先行技術は、次のような限界点を有する。

１．現在では、各プレゼンス属性の変更後に通知が発送され、通知トラフィックが非常に高い。
２．現在のシナリオでは、不必要な通知を遮断するのが不可能である。
３．現在では、ユーザーは、自身の選好度に基づいて通知を制御することができない。
４．時々、ユーザーは、複数のクライアントを使用し、ユーザーが一部のクライアント装置で通知の受信を希望しない場合があるが、これを先行技術を使用して実現することができない。

ＩＥＴＦにより定義された現在のフィルターメカニズムは、基本的に、コンテンツ及び通知率を制御する規則に関するものであるが、本発明は、基本的に、ウォッチャーのプレゼンス属性に基づいて通知を遮断することを指向している。これらの規則は、ユーザーが通話中であるか又はユーザーが通知を受信しようとしない場合に、不必要なプレゼンス通知を遮断できるようにする。これは、通知トラフィックの制御に役に立つとともにユーザーの通知遮断フィルタリング規則の設定の一助となる。

したがって、本発明の目的は、プレゼンス通知を最適化するシステム及び方法を提供することにある。

本発明の他の目的は、不必要な通知を回避することによりネットワーク負荷及びユーザーに対する迷惑な通知の低減を提供することにある。

本発明のまた他の目的は、ウォッチャーのプレゼンス情報に基づいて通知を設定することを提供することにある。

本発明のさらなる目的は、ウォッチャーのプレゼンスに基づいてプレゼンス情報の通知をフィルタリングする規則を設定するシステム及び方法を提供することにある。

上記のような目的を達成するために、本発明は、プレゼンス属性に基づくプレゼンス通知システムを提案する。このシステムは、プレゼンス登録及びプレゼンス情報を格納するプレゼンスサーバと、認証関連情報を格納するプレゼンスＸＤＭＳとを具備し、このプレゼンスサーバがプレゼンス属性に基づく通知伝達に関するフィルタリング規則を格納することを特徴とする。

また、本発明は、プレゼンス属性に基づくプレゼンス通知方法を提案する。この方法は、プレゼンスサーバがプレゼンス登録及びプレゼンス情報を格納するステップと、プレゼンスＸＤＭＳが認証関連情報を格納するステップと、を具備し、プレゼンス属性に基づく通知伝達に関するフィルタリング規則をこのプレゼンスサーバとともに使用されることを特徴とする。

本発明は、ユーザーが自身のプレゼンス属性に基づいて通知遮断フィルターを設定できるようにするシステム及び方法を提供する。

本発明は、次のような長所を有する。

ｉ）所望しない通知が遮断されることができるために、この通知トラフィックを低減させることができる。
ｉｉ）ユーザーのプレゼンス情報のようなユーザー選好度を使用して通知を設定することができる。
ｉｉｉ）ユーザーは、通知に対する期間を設定することができる。
ｉｖ）ユーザーは、自身の装置タイプに基づいて通知を制御することができる。

システム構成を示す図である。 論理フローを示す図である。 シングルドメインウォッチャー及び同一のドメインでのプレゼンスを示す図である。 マルチドメイン登録シナリオを示す図である。 プレゼンスサーバがウォッチャーのプレゼンス情報を登録した後に、通知ブロックフィルター規則をプレゼンスサーバに格納する代替策を示す図である。 プレゼンス通知シナリオを示す図である。 プレゼンス通知シナリオを示す図である。

本発明の他の目的、利点、及び顕著な特徴は、添付の図面及び本発明の実施形態からなされた以下の詳細な説明から、当業者には明確になるはずである。

以下、本発明の好ましい実施形態を添付の図面を参照して説明する。しかしながら、開示される実施形態は、多様な形態で実施されることができる本発明を例示することに過ぎないことを理解すべきである。下記の説明及び図面は、本発明を限定するためのものではなく、特許請求の範囲に対する基礎として、本発明をどのように実現し、そして／または使用するかを当業者に教示するための基礎として提供されるものである。しかしながら、特定の場合には、本発明に関連した公知の機能または構成に関する具体的な説明は、本発明の要旨を不明にしないようにその詳細な説明を省略している。

現在のプレゼンスシステムは、ユーザーが他のユーザーのプレゼンス情報を登録することができるようにする。プレゼンスサーバは、登録情報及びプレゼンス情報を保持する。ＯＭＡプレゼンス及びアベイラビリティグループで定義されている現在のプレゼンスシステムは、ユーザーが通知で送信された情報の量を制御するためのフィルターを定義することができるようにする。現在では、通知率が時間属性により制御され得る。しかしながら、所望しない通知がプレゼンスサーバにより発生する場合がやはり多く存在する。ネットワークトラフィックに過大な負荷がかかる。本発明は、これら通知を制御することを目標としている。

本発明は、ウォッチャーのプレゼンス情報に基づいて通知を減少させることを目標とする。本発明は、ウォッチャーのプレゼンス情報に基づいて通知を送信することを提案する。本発明は、ユーザーが通知を送信するか又は遮断するかを決定する基盤となる規則を設定できるようにする。これに関する簡単な例は、ウォッチャーが通話中（ＢＵＳＹ）である場合には、通知を送信しないようにするものである。ユーザーが通話中であり、通知の受信は希望しないが、登録は維持したいという場合が多くある。所望しない通知が送信され、このような所望しない通知を伝達するために、ネットワーク負荷が増加するという状況もある。本発明は、このような所望しない通知を遮断するフィルター規則を提案する。

図１は、提案された本発明のシステム構成を示す。このシステム構成は、プレゼンス登録及びプレゼンス情報を格納するプレゼンスサーバ１２０と、認証関連情報を格納するプレゼンスＸＭＬ文書管理サーバ（ＸＤＭＳ）１４０と、を含む。提案された本発明は、プレゼンスサーバ１２０がプレゼンスに基づく通知の伝達に関連するフィルタリング規則も格納する。図２に示すように、プレゼンスサーバ１２０において、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターが格納され、その後に、ウォッチャーに対する通知が発生する場合には、その通知は、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターを通過し、次いで、このフィルターが許容する場合のみにこの通知がウォッチャーに送信される。本発明は、このようなウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則を設定し適用する方法を提案する。

本発明は、ＳＵＢＳＣＲＩＢＥ要請を行い、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリングボディーをＳＵＢＳＣＲＩＢＥ要請に含ませる。本発明は、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターの構成、その動作フロー、及び処理を提案する。

下記では、シングルドメイン及びマルチドメインにおけるフロー及び動作信号フローについて説明する。

図２は、シングルドメインに関する実施形態であって、上述したフィルター規則を設定するために本発明に従って実行されるステップを示す。まず、クライアント１１０は、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーを含むＳＵＢＳＣＲＩＢＥ要請を構成する。このフィルターボディーは、例えば、私のプレゼンス状態がＢＵＳＹである場合にはこの通知を送信しない、といったこの通知を送信する前に確認される詳細な条件を有する。このフィルターボディーは、ＸＭＬ（Extended Markup Language）フォーマットとなっている。プレゼンスサーバ１２０は、クライアント１１０からＳＵＢＳＣＲＩＢＥ要請を受信した後に、この条件を評価する。プレゼンスサーバ１２０がこの条件を解析し、処理することができる場合には、プレゼンスサーバは、２００ ＯＫ応答を送信し、“ＣｏｎｄＯＫ”としての登録状態ヘッダー値とプレゼンス属性を有するボディーとを含む後続通知を送信する。したがって、この要請された通知遮断フィルタリング規則は、プレゼンスサーバ１２０に格納され、通知が発生する度にこれら条件を確認する。

図３は、ウォッチャー及びプレゼンティティが同一のドメインにあるシングルドメインに対するフロー図を示す。

１．ウォッチャー３１０は、このボディーに通知遮断のためのフィルターを有するＳＵＢＳＣＲＩＢＥ要請を送信する。
２．ＳＩＰコア３２０は、この要請をプレゼンスサーバ３３０に伝達する。
３．プレゼンスサーバ３３０は、この要請を受信し、この認証を確認し、フィルターボディー構成を確認する。探し出されたフィルターボディーが有効である場合には、プレゼンスサーバ３３０は、このフィルターを格納し、肯定応答を送信する。認証が許容されないと、プレゼンスサーバ３３０は、ＳＩＰ ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ動作により否定応答を送信する。また、プレゼンスサーバ３３０は、通知遮断フィルターが許容される場合には、“ＣｏｎｄＯＫ”を応答に含ませるか、又は通知遮断フィルターが許容されない場合には、“ＣｏｎｄＲｅｊｅｃｔ”を送信した後に、要請された登録を終了させる。代案的に、プレゼンスサーバ３３０は、この要請された登録を許容しつつも、要請された通知遮断フィルタリング規則だけを無効化することもできる。
４．プレゼンスサーバ３３０は、ＳＩＰコア３２０を介して２００ ＯＫ応答を送信する。
５．ＳＩＰコア３２０は、その応答をウォッチャー３１０に伝達する。
６．プレゼンスサーバ３３０は、要請された通知遮断フィルターが受諾されたか、又は拒絶されたかを示す“ＣｏｎｄＯＫ”又は“ＣｏｎｄＲｅｊｅｃｔ”としての適切な状態を有する初期通知応答を送信する。
７．ＳＩＰコア３２０は、この通知応答をウォッチャー３１０に伝達する。
８．プレゼンティティを示すプレゼンスソース３４０は、プレゼンティティのプレゼンス情報に関する変更を識別し、更新されたプレゼンス情報をプレゼンスサーバ３３０にパブリッシュする。
９．プレゼンスサーバ３３０は、この通知を生成した後に、通知遮断フィルター規則を確認する。
１０．通知遮断フィルター規則が通知の送信を許容すると、プレゼンスサーバ３３０は、その通知をウォッチャー３１０に送信する。
１１．ＳＩＰコア３２０は、この通知要請をウォッチャー３１０に伝達する。

このように、プレゼンス通知遮断フィルターを定義し、これをプレゼンスサーバ３３０に格納することにより、ネットワークを介した不必要な通知フローを回避することができる。また、これは、このプレゼンス通知がアクセスネットワークを介して流れることを回避するのに役立ち、これは、無線環境に非常に有益である。

図４は、マルチドメインのケースを示す。ここで、クライアントは、登録要請を送信し、ルートヘッダーフィールド（route header field）を含み、ホームプレゼンスサーバ４３０としてその値を割り当てる。

１．ウォッチャー４１０は、プレゼンス属性基盤フィルタリングのためのフィルターボディーを有するＳＵＢＳＣＲＩＢＥ要請を送信し、また、自身のホームプレゼンスサーバアドレスを有するルートヘッダーフィールドを添付する。
２．ＳＩＰコア４５０は、この要請をウォッチャーのホームプレゼンスサーバ４３０に伝達する。
３．ウォッチャーのホームプレゼンスサーバ４３０は、プレゼンスに関連したフィルターを抽出し、このフィルターを設定し、記録ルートヘッダー及びこのアドレスを添付し、この要請をプレゼンティティネットワークのＳＩＰコア４５０に伝達する。
４．ＳＩＰコア４２０は、この登録要請をプレゼンティティのプレゼンスサーバ４４０に伝達する。
５．プレゼンティティのプレゼンスサーバ４４０は、認証ポリシーを確認し、ウォッチャーが認証されるか否かを確認する。プレゼンスサーバ４４０は、プレゼンス文書のコンテンツに関連したフィルターを格納し、２００ ＯＫ応答を送信する。
６．プレゼンティティのＳＩＰコア４５０は、２００ ＯＫ応答をウォッチャーのプレゼンスサーバ４３０に伝達する。
７-８．プレゼンスサーバ４３０は、２００ ＯＫ応答をＳＩＰコア４５０を介して送信する。
９-１０．プレゼンスサーバ４４０は、第１の初期通知をＳＩＰコア４２０を介してウォッチャー４１０に送信する。これは、上述した２００ ＯＫ応答と同様に、ウォッチャーのプレゼンスサーバ４３０を介してルーティングされる。
１１-１２．ウォッチャーのプレゼンスサーバ４３０は、第１の通知及び適切な状態情報を受信した後に、これをＳＩＰコア４２０を介してウォッチャー４１０に伝達する。
１３．プレゼンティティのプレゼンスソース４６０は、自身のプレゼンス情報を更新するためのＰＵＢＬＩＳＨ要請をＳＩＰコア４５０を介してプレゼンティティのプレゼンスサーバ４４０に送信する。
１４．ＳＩＰコア４５０は、この要請をプレゼンティティのプレゼンスサーバ４４０に伝達する。
１５．プレゼンティティのプレゼンスサーバ４４０は、プレゼンティティのプレゼンス文書を更新し、プレゼンス文書のコンテンツに関連したフィルターを確認し、この確認されたフィルターをルータヘッダーに添付することにより、この通知をウォッチャーのプレゼンスサーバ４３０に送信する。
１６．ＳＩＰコア４５０は、この通知をウォッチャーのプレゼンスサーバ４３０に伝達する。
１７-１８．ウォッチャーのプレゼンスサーバ４３０は、この通知を確認し、ウォッチャーのプレゼンス関連フィルターを確認し、フィルターが許容されると、この通知をＳＩＰコア４２０を介してウォッチャー４１０に伝達する。

このプレゼンスフィルターを定義し、これらをプレゼンスサーバに格納することにより、不必要な通知がネットワークを介して流れることを回避できるようにする。また、これは、このようなプレゼンス通知がアクセスネットワークを介して流れることを回避するのに役立ち、これは、無線環境に非常に有益である。

図５は、プレゼンティティのプレゼンスサーバがウォッチャーのプレゼンス情報を登録した後に、ウォッチャーのプレゼンス属性に基づく通知遮断フィルター規則をプレゼンティティのプレゼンスサーバに格納する代替策を示す。したがって、プレゼンティティのプレゼンスサーバは、ウォッチャーのプレゼンス情報に基づいてこの通知を遮断する。

１-３．ウォッチャー４１０は、フィルター規則を有するＳＵＢＳＣＲＩＢＥ要請をこのボディーに送信し、この要請は、プレゼンティティのプレゼンスサーバ４４０にルーティングされる。
４．プレゼンティティのプレゼンスサーバ４４０は、認証されたか否かを確認した後に、このフィルター規則を設定し、格納する。
５-７．プレゼンティティのプレゼンスサーバ４４０は、２００ ＯＫ応答をＳＩＰコア４５０、４２０を介してウォッチャー４１０に送信する。
８-１０．プレゼンティティのプレゼンスサーバ４４０は、プレゼンティティのプレゼンス情報の初期通知をＳＩＰコア４５０、４２０を介してウォッチャー４１０に送信する。
１１-１３．プレゼンティティのプレゼンスサーバ４４０は、ウォッチャーのプレゼンスサーバ４３０に要求されるウォッチャーのプレゼンス情報を登録する。
１４-２０．ウォッチャーのプレゼンスサーバ４３０は、主導的にプレゼンスサーバを認証した後に、２００ ＯＫ応答及びそれに続くウォッチャーのプレゼンス属性の通知をプレゼンティティのプレゼンスサーバ４４０に送信する。
２１-２２．プレゼンティティのプレゼンス情報が変更される場合には、プレゼンティティに対するプレゼンスソース４４０は、ＰＵＢＬＩＳＨ要請を送信することにより、プレゼンティティのプレゼンスサーバ４４０にあるプレゼンス情報を更新する。
２３．プレゼンスサーバ４４０は、通知遮断規則及びコンテンツフィルタリング規則を確認し、この通知を送信するか否かを決定する。
２４-２６．プレゼンティティのプレゼンスサーバ４４０は、フィルター規則を確認した後に、プレゼンティティのプレゼンス情報の通知をウォッチャーに送信する。

以下、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーの構成について説明する。

本発明は、フィルタリング規則を設定するための次のＸＭＬスキーマを有することを提案する。このスキーマは、“Ｎｏｔｉｆｉｃａｔｉｏｎ-Ｂｌｏｃｋ-Ｓｅｔ”と呼ばれる１つのルート要素を有することを提案する。このようなルート要素は、１つが“ＰｒｅｓＡｔｔｒｉｂ”であり、他の１つが“ＴｉｍｅＡｔｔｒｉｂ”である２個の要素を有する。ＰｒｅｓＡｔｔｒｉｂは、プレゼンス関連条件を設定するために使用され、ＴｉｍｅＡｔｔｒｉｂは、この通知に対する時間基盤制御を設定するために使用される。ＰｒｅｓＡｔｔｒｉｂは、次の属性でなされる。

ｉ．Ｅｑｕａｌｓ：遮断条件が何であるかに対応するプレゼンス属性
ｉｉ．Ｔｙｐｅ：ＸＰＡＴＨ又はＵＲＩなどのような値のタイプ
ｉｉｉ．ＦＩＤ：異なるフィルターと差別化するフィルターＩＤ
ｉｖ．ＶａｌｉｄＴｉｍｅ：条件の有効期間
ｖ．ＯｐｅｒａｔｉｏｎＴｙｐｅ：さらに多くのフィルターの追加、フィルタリング規則の削除のようなフィルタリング規則について遂行される動作

規則に関連して遂行される動作

ＰｒｅｓＡｔｔｒｉｂは、ＸＰＡＴＨ又はＵＲＩフォーマットでプレゼンス属性としての値を有し、これにより、プレゼンスサーバは、プレゼンス属性がＥｑｕａｌｓ属性値（必須の値である）と同一であるか否かを確認し、これに対応すると、通知を遮断する。ＶａｌｉｄＴｉｍｅ属性は、この条件に対する有効期間を付与するのに使用される。ＴｉｍｅＡｔｔｒｉｂは、ＦＲＯＭ値からＴＯ値までの通知を遮断するもののような時間に基づく通知遮断を設定するために使用される。複数のＰｒｅｓＡｔｔｒｉｂ手段を有することができるＰｒｅｓＦｉｌｔｅｒでは、１つ以上の条件が設定されることができることに留意しなければならない。１個又は２個のＰｒｅｓＡｔｔｒｉｂが存在すると、論理ＯＲ動作で処理され、これは、ＴｉｍｅＡｔｔｒｉｂに対しても同一である。

下記の＜表１Ａ＞，＜表１Ｂ＞は、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターの上述した構成に対するスキーマ定義を示す。

下記の＜表２＞は、上述した＜表１Ａ＞，＜表１Ｂ＞のスキーマ定義によるウォッチャーのプレゼンス属性に基づく通知遮断フィルターの例を示す。

通知遮断規則スキーマに対する各種の要素及び属性の定義について上述した。以下では、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターのスキーマ処理について説明し、より詳細には、ＸＭＬ文書フォーマットに対する処理規則について説明する。

まず、クライアント側のスキーマ処理について説明する。

クライアントは、このスキーマをＳＵＢＳＣＲＩＢＥボディーにプレゼンス属性に基づく通知遮断フィルタリング規則を定義するために使用する。スキーマの定義により、クライアントは、“Ｎｏｔｉｆｉｃａｔｉｏｎ-Ｂｌｏｃｋ-Ｓｅｔ”ルート要素で“ＰｒｅｓＡｔｔｒｉｂ”要素を使用しているプレゼンスフィルター規則を含む。クライアントは、ＸＰＡＴＨ表記法を使用して、又は使用されるフォーマットを言及する“Ｔｙｐｅ”属性を有する他のタイプを使用してプレゼンス属性名称としての値をＰｒｅｓＡｔｔｒｉｂに割り当て、Ｅｑｕａｌｓ属性にプレゼンス属性の値を割り当てる。“Ｔｙｐｅ”属性が欠けていると、ＸＰＡＴＨは、デフォルト値と見なされる。クライアントは、ＦＩＤ属性を使用して固有のフィルターＩＤ値を規則に割り当てる。クライアントは、１つ以上のＰｒｅｓＡｔｔｒｉｂを複数の条件を含む文書に含ませることができ、これら条件は、異なる“ＦＩＤ”値を有することに留意しなければならない。ＰｒｅｓＡｔｔｒｉｂは、“追加（ＡＤＤ）”又は“削除（ＲＥＭＯＶＥ）”のような動作のタイプを示すＯｐｅｒａｔｉｏｎＴｙｐｅ属性も有する。ＲｅｍｏｖｅＯｐｅｒａｔｉｏｎＴｙｐｅ値を有するＰｒｅｓＡｔｔｒｉｂは、フィルター規則を削除するのに使用される。ＲＥＭＯＶＥがＰｒｅｓＡｔｔｒｉｂ要素の値に言及された特定の値とともに使用されると、サーバにより置換え（REPLACE）動作が遂行される必要がある。ＯｐｅｒａｔｉｏｎＴｙｐｅが文書に含まれていないと、ＡＤＤ値は、デフォルト値と見なされる。ユーザーが特定の条件に対して論理ＡＮＤ動作を定義することを希望すると、クライアントは、２個の“ＰｒｅｓＡｔｔｒｉｂ”を追加し、同一のＦＩＤ属性値を２個のＰｒｅｓＡｔｔｒｉｂに割り当てる。

また、クライアントは、“ＴｉｍｅＡｔｔｒｉｂ”属性を使用して時間に基づくフィルター規則を定義することができる。クライアントは、ＴｉｍｅＡｔｔｒｉｂを使用し、必要とされる持続時間により、それに応じてＦＲＯＭ時間属性値及びＴＯ時間属性値を割り当てる。

次いで、サーバ側スキーマ処理について説明する。プレゼンス属性に基づく通知遮断フィルターボディーがＳＵＢＳＣＲＩＢＥ要請で受信されると、サーバは、スキーマ定義を使用して文書の有効性を確認する。フィルターが有効でない場合に、サーバは、エラーを生成する。確認後に、サーバは、“ＰｒｅｓＡｔｔｒｉｂ”要素内のプレゼンス属性及び“ＴｉｍｅＡｔｔｒｉｂ”要素内の時間属性でなされた通知遮断フィルター規則をボディーから読み出し、このフィルター規則を格納する。また、サーバは、言及されている場合にその規則に対する有効期間を確認し、クライアントにより割り当てられたＦＩＤを規則に割り当てる。

複数の“ＰｒｅｓＡｔｔｒｉｂ”要素及び“ＴｉｍｅＡｔｔｒｉｂ”要素が存在する場合には、サーバは、これらすべての条件を論理ＯＲ動作で処理する。サーバが同一のＦＩＤを有する２個の条件を識別する場合には、論理ＡＮＤ動作は、この２個の条件に対して遂行される。サーバがＦＩＤ及び“ＲＥＭＯＶＥ”としてのＯｐｅｒａｔｉｏｎＴｙｐｅを有する空の“ＰｒｅｓＡｔｔｒｉｂ”要素又は“ＴｉｍｅＡｔｔｒｉｂ”要素を受信すると、同一のＦＩＤを有する特定の既存のフィルター規則は、サーバから削除される。サーバがＦＩＤ及び“ＲＥＰＬＡＣＥ”としてのＯｐｅｒａｔｉｏｎＴｙｐｅを有する空でない“ＰｒｅｓＡｔｔｒｉｂ”要素を受信すると、同一のＦＩＤを有する特定の既存のフィルター規則は、その要素に言及された規則に置き換えられる。

以下では、ウォッチャーの動作について説明する。

特定のウォッチャーのプレゼンス条件の間にだけプレゼンティティのプレゼンス情報に関する通知を受信することを希望するウォッチャーは、このようなウォッチャーのプレゼンス条件を明示するプレゼンス通知遮断フィルターを有するＳＵＢＳＣＲＩＢＥ要請を生成する。先のセクション３で説明した通り、ウォッチャーは、通知を受信する自身の選好プレゼンス条件をフィルターボディーに明示し、このフィルターボディーをプレゼンティティのプレゼンス情報に対するＳＵＢＳＣＲＩＢＥ要請に含ませることができる。ＳＵＢＳＣＲＩＢＥ要請に含まれる場合には、このフィルターに対するコンテンツタイプは、“ｓｉｍｐｌｅ-ｆｉｌｔｅｒ-ｐｒｅｓｆｉｌｔｅｒ＋ｘｍｌ”として特定されることができる。

以下では、プレゼンスサーバの動作について説明する。

まず、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターの抽出について説明する。

本発明により提案されるようなウォッチャーのプレゼンス属性に基づく通知遮断フィルターに対する新規のコンテンツタイプは、“ｓｉｍｐｌｅ-ｆｉｌｔｅｒ-ｐｒｅｓｆｉｌｔｅｒ＋ｘｍｌ”であり得る。ＳＵＢＳＣＲＩＢＥ要請のボディーに含まれる場合に、このコンテンツタイプは、プレゼンスサーバがウォッチャーのプレゼンス関連通知遮断フィルターの存在を識別するために使用される。このように識別された場合には、プレゼンスサーバは、ＳＵＢＳＣＲＩＢＥボディーから通知遮断フィルターを抽出し、これをさらなる処理のために格納する。

次いで、抽出されたウォッチャーのプレゼンス属性に基づく通知遮断フィルターの処理について説明する。

プレゼンスサーバは、上述したように、抽出されたウォッチャーのプレゼンス属性に基づく通知遮断フィルターを次に説明するように処理する：

プレゼンスサーバがウォッチャーのプレゼンスに関連した通知遮断フィルターに明示されたようなこれら条件を解析し、処理することができると、プレゼンスサーバは、２００ ＯＫ応答を送信し、続いて、“ａｃｔｉｖｅ”及び“ＣｏｎｄＯＫ”としての登録状態ヘッダー値及びターゲットプレゼンティティの要請されたプレゼンス属性を有するボディーを含むＮＯＴＩＦＹを送信する。

このように、ウォッチャーのプレゼンスに関連した通知遮断フィルターで登録に成功すると、プレゼンスサーバは、このフィルタリング規則を格納することにより、将来のＮＯＴＩＦＹ要請の発生の際にウォッチャーに適用する。ウォッチャーにより要請されたようなプレゼンティティのプレゼンス属性を含むＮＯＴＩＦＹ要請を発生させる場合に、プレゼンスサーバは、ウォッチャーのプレゼンス属性に基づく通知遮断フィルター内の条件を確認する。この条件がプレゼンスサーバの知っている現在のウォッチャーのプレゼンス属性と一致すると、プレゼンスサーバは、ＮＯＴＩＦＹ要請をウォッチャーに送信せず、そうでなければ、ＮＯＴＩＦＹ要請をウォッチャーに送信する。図３は、これら手続きによるフローを示す。

プレゼンスサーバがウォッチャーのプレゼンス属性に基づく通知遮断フィルターを識別するが、このフィルターに明示されている条件を評価することができないと、プレゼンスサーバは、２００ ＯＫ又は２０２ Ａｃｃｅｐｔｅｄ応答を送信し、ウォッチャーのプレゼンス属性に基づく通知遮断フィルター内の要請された条件が評価されることができないことを示す“ｔｅｒｍｉｎａｔｅｄ”又は“ＣｏｎｄＲｅｊｅｃｔ”としての登録状態ヘッダー値を有するＮＯＴＩＦＹ要請を送信した後に登録を終了させる。

代案的に、プレゼンスサーバが通知遮断フィルタリング規則を解析することができないとしても、登録を維持することを希望する場合には、プレゼンスサーバは、２００ ＯＫ又は２０２ Ａｃｃｅｐｔｅｄ応答を送信し、継続して登録を行いつつ、後続のＮＯＴＩＦＹ要請で登録状態ヘッダー値を“ａｃｔｉｖｅ”又は“ＣｏｎｄＲｅｊｅｃｔ”に設定することにより登録を保持する。したがって、ウォッチャーが“ａｃｔｉｖｅ”又は“ＣｏｎｄＲｅｊｅｃｔ”としての登録状態を有するＮＯＴＩＦＹ要請を受信する場合には、クライアントは、要請された通知遮断フィルタリング規則がプレゼンスサーバにより拒絶されるか又は解析されないが、要請された登録がやはり有効であり、したがって、ターゲットプレゼンティティの要請されたプレゼンス属性に関する将来の通知を受信することができることを認識することができる。

プレゼンスサーバが通知遮断フィルタリング規則をサポートしない場合には、プレゼンスサーバは、ＳＵＢＳＣＲＩＢＥ要請に対して４０３Ｆｏｒｂｉｄｄｅｎ応答又は他の適切なエラー応答を送信する。これは、プレゼンスサーバのローカルポリシーによって変えてもよい。

次いで、マルチドメインに関する実施形態について説明する。

ウォッチャーがターゲットプレゼンティティのドメインとは異なるドメインにある場合には、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則を有するＳＵＢＳＣＲＩＢＥ要請は、図４及びこのセクション１ｂのステップで例示された通り、ウォッチャーのプレゼンスサーバにルーティングされた後に、プレゼンティティのプレゼンスサーバに伝達されなければならない。この場合に、ウォッチャーのプレゼンスサーバは、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則を上述したように処理し、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則の処理に成功すると、プレゼンティティのプレゼンス情報に対する登録を処理するためにＳＵＢＳＣＲＩＢＥ要請をプレゼンティティのプレゼンスサーバに伝達し、もし存在すると、ＲＦＣ４６６０“通知フィルタリングの機能説明（Functional Description of Notification Filtering）”によるウォッチャーのイベント通知を伝達する。プレゼンティティのプレゼンス情報に関するＮＯＴＩＦＹ要請をプレゼンティティのプレゼンスサーバから受信したウォッチャーのプレゼンスサーバは、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則が現在のウォッチャーのプレゼンス属性と一致するか否かを確認する。一致すると、ウォッチャーのプレゼンスサーバは、受信されたＮＯＴＩＦＹ要請をウォッチャーに伝達することを遮断し、そうでなければ、上記で明示された通り、ＮＯＴＩＦＹ要請を伝達する。

上述したマルチドメインにおいて、ＳＵＢＳＣＲＩＢＥ要請は、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則の処理及び格納のためにウォッチャーのプレゼンスサーバにルーティングされなければならない。しかしながら、ＳＵＢＳＣＲＩＢＥ要請は、現在ＳＩＰコアを介してのみプレゼンティティのプレゼンスサーバに直接ルーティングすることができる。このように、ウォッチャーのプレゼンスサーバをＳＵＢＳＣＲＩＢＥ ＳＩＰセッション経路にあるように強制する必要がある。これは、ウォッチャーのプレゼンスサーバ又はそのホームプレゼンスサーバのＳＩＰアドレスを有するＳＩＰルートヘッダーを使用して実現されることができる。したがって、マルチドメインの場合には、ウォッチャーに対するホームプレゼンスサーバ又はプレゼンスサーバがプレゼンティティのプレゼンスサーバからの通知を伝達する中継サーバとして機能し、ウォッチャーへの通知がウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則により制御されるべき地点として機能する。

次いで、マルチドメインに関する他の実施形態について説明する。

ウォッチャーがターゲットプレゼンティティのドメインとは異なるドメインにある場合には、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則を有するＳＵＢＳＣＲＩＢＥ要請は、プレゼンティティのプレゼンスサーバに直接ルーティングされなければならない。その後に、プレゼンティティのプレゼンスサーバが登録要請を処理し、もし存在すると、ＲＦＣ４６６０“通知フィルタリングの機能説明”によるウォッチャーのイベント通知を処理する。ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則の存在を識別すると、プレゼンティティのプレゼンスサーバは、上述したように、その規則を処理した後に、ウォッチャーのプレゼンス情報を登録することによりウォッチャーの最新のプレゼンス情報を有するためには、ＳＵＢＳＣＲＩＢＥ要請をウォッチャーのプレゼンスサーバに送信する。プレゼンティティのプレゼンス情報に関するＮＯＴＩＦＹ要請が発生すると、プレゼンティティのプレゼンスサーバは、ウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則が現在のウォッチャーのプレゼンス属性と一致するか否かを確認する。現在のウォッチャーのプレゼンス属性と一致すると、プレゼンティティのプレゼンスサーバは、ＮＯＴＩＦＹ要請をウォッチャーに送信せず、そうでなければ、ＮＯＴＩＦＹ要請をウォッチャーに送信する。図５は、これら手続きによるフローの例を示す。

以下では、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーの代案的な構成及び処理について説明する。

上述したように、ウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーに加えて、本発明は、次の対案的な構成を提案する。下記の＜表３Ａ＞，＜表３Ｂ＞，＜表３Ｃ＞は、代案的な構成に対するスキーマ定義を示す。

上述した＜表３Ａ＞，＜表３Ｂ＞，＜表３Ｃ＞は、本発明により提案されたウォッチャーのプレゼンス属性に基づく通知遮断フィルタリング規則に対する代案的なスキーマを示し、これは、基本的にＲＦＣ４６６１“イベント通知フィルタリングに対するＸＭＬ基盤フォーマット（XML Based Format for Event Notification Filtering）”及びウォッチャーのプレゼンスに基づく通知遮断フィルタリング規則をサポートする適切な改善策に基づいている。このセクションは、このスキーマ構成を簡略に説明する。

このスキーマは、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ-ｓｅｔ”と呼ばれるルート要素を定義する。ルート要素は、次の要素を有する：

ｎｓ-ｂｉｎｄｉｎｇｓ：名称空間とプレフィックスとの間のバインディングを明示する。

ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ：フィルター規則を明示する。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ-ｓｅｔ”ルート要素は、“ｗａｔｃｈｅｒ-ｕｒｉ”と呼ばれる１つの属性も有し、この属性は、そのプレゼンス属性に基づいて通知遮断フィルタリング規則を適用するターゲットウォッチャーＵＲＩを明示するのに使用される。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素は、フィルタリング規則を明示するために使用される。この要素は、次の属性を有する。

ｉ）ｉｄ：この属性は、フィルター規則を識別するのに使用される。
ｉｉ）ｒｅｍｏｖｅ：この属性は、フィルター規則を削除するのに使用される。その値は、ブール（boolean）（真／偽）である。
ｉｉｉ）ｅｎａｂｌｅ：この属性は、フィルタリング規則のイネーブル／ディスエーブルを行うのに使用される。その値は、ブール（真／偽）である。
ｉｖ）ｖａｌｉｄ-ｔｉｌｌ：この属性は、特定のフィルター規則に対する時間及び日付の効力を明示する。その値は、日時である。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素は、２個の子要素（child element）を有し、１つは、これに関する通知が遮断される特定のプレゼンス情報に対するフィルタリング規則の定義をサポートするｐｒｅｓａｔｔｒｉｂであり、他の１つは、通知を遮断する期間の識別をサポートするｔｉｍｅａｔｔｒｉｂである。“ｐｒｅｓａｔｔｒｉｂ”は、“ｉｎｃｌｕｄｅ”要素を有する。“ｉｎｃｌｕｄｅ”は、“ｉｎｃｌｕｄｅ”要素の値のタイプを明示する１つの“ｔｙｐｅ”属性を有する。“ｔｙｐｅ”属性の値は、“ｘｐａｔｈ”又は何か他のものであってよく、ここで、“ｘａｐｔｈ”は、“ｔｙｐｅ”属性がない場合にデフォルト値となる。プレゼンス属性に関する特定の条件を明示するためにＸＰＡＴＨブール演算子を使用することができる（表５の例を参照）。１つよりさらに多くのｉｎｃｌｕｄｅ要素を含むことにより、多重条件を明示する。多重条件は、論理ＡＮＤ動作で処理される。相互に異なるｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ要素に明示されたプレゼンス条件は、論理ＯＲ動作で処理される。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｔｉｍｅａｔｔｒｉｂ”子要素は、通知を遮断する期間を明示するのに使用される。このような要素は、２個の要素を有し、１つがｄｕｒａｔｉｏｎ-ｔｉｍｅであり、他の１つがｄｕｒａｔｉｏｎ-ｄａｔｅである。“ｄｕｒａｔｉｏｎ-ｔｉｍｅ”要素及び“ｄｕｒａｔｉｏｎ-ｄａｔｅ”要素は、２個の属性を有し、１つが“ｆｒｏｍ”であり、他の１つが“ｔｉｌｌ”であり、この属性は、持続時間及び持続日付を各々明示するのに使用される（表４の例を参照）。このような期間の間には、すべての通知が遮断される。

次の＜表４＞は、上述した＜表３Ａ＞，＜表３Ｂ＞，＜表３Ｃ＞におけるような代案的なスキーマ定義によるウォッチャーのプレゼンス属性に基づく通知遮断フィルターの例を示す。

上述した＜表３＞でのスキーマ定義によるウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーは、次のように処理される：

まず、クライアント側処理について説明する。

クライアントは、ＳＵＢＳＣＲＩＢＥボディーにプレゼンス属性に基づく通知遮断フィルタリング規則を定義するために上述したスキーマを使用する。スキーマの定義により、クライアントは、通知の受信を希望しない場合には、各“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素項目に通知遮断規則を明示することができる。多重通知遮断規則が明示された場合には、この通知は、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内に明示された通知遮断規則の中の１つと一致する場合に遮断される。すなわち、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ-ｓｅｔ”ルート要素の下の各“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断フィルタリング規則の評価は、論理ＯＲ動作で処理される。

クライアントは、“ｐｒｅｓａｔｔｒｉｂ”子要素又は“ｔｉｍｅａｔｔｒｉｂ”子要素を使用して“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断規則に複数の条件を明示することができる。この複数の条件の評価は、論理ＡＮＤ動作で処理される。すなわち、規則内のすべての条件がＴＲＵＥに評価された場合のみに、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断規則と一致する。

１つの通知遮断フィルタリング規則を構成する各“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素において、クライアントは、通知遮断のためのプレゼンス属性を明示するために“ｐｒｅｓａｔｔｒｉｂ”要素を使用することができる。これらプレゼンス属性は、ＸＰＡＴＨのフォーマットで表現されることができる。また、クライアントは、通知が遮断される持続時間を明示するために“ｔｉｍｅａｔｔｒｉｂ”要素を使用することができる。“ｔｉｍｅａｔｔｒｉｂ”要素は、２個のタイプの子要素を有することができる。“ｄｕｒａｔｉｏｎ-ｔｉｍｅ”子要素は、通知が遮断される毎日の持続時間を明示するために使用され、“ｄｕｒａｔｉｏｎ-ｄａｔｅ”子要素は、通知遮断のための正確な日時及び持続時間を明示するために使用される。

クライアントは、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｉｄ”属性の値を使用して“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断フィルタリング規則を識別することができる。クライアントは、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｅｎａｂｌｅ”属性の値を使用して通知遮断フィルタリング規則をイネーブル／ディスエーブルすることができる。クライアントは、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｒｅｍｏｖｅ”属性の値を使用して通知遮断フィルタリング規則を削除することができる。クライアントは、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｖａｌｉｄ-ｔｉｌｌ”属性を設定することにより通知遮断フィルタリング規則の有効持続時間を設定することができる。

次いで、サーバ側処理は、次のようである。

ＳＵＢＳＣＲＩＢＥ要請でプレゼンス属性に基づく通知遮断フィルターボディーに関するクライアントの要請を受信する場合に、サーバは、上述したスキーマ定義を使用して文書の有効性を確認する。フィルターが有効でない場合に、サーバは、エラーを発生させる。この確認の後に、サーバは、ＳＵＢＳＣＲＩＢＥボディーから通知遮断フィルター規則を抽出し、これを格納する。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素に明示された通知遮断フィルタリング規則を評価する場合に、サーバは“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ-ｓｅｔ”ルート要素の“ｗａｔｃｈｅｒ-ｕｒｉ”属性により明示されたようなターゲットのプレゼンス属性が“ｐｒｅｓａｔｔｒｉｂ”要素内のプレゼンス条件と一致するか否かを確認する。また、サーバは、現在の時間が“ｔｉｍｅａｔｔｒｉｂ”要素に明示された持続時間条件と一致するか否かを確認する。全てのプレゼンス条件及び時間条件が一致すると、通知遮断フィルタリング規則は、ＴＲＵＥに評価される。

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ-ｓｅｔ”内の１つ又はそれ以上の通知遮断規則がＴＲＵＥに評価される場合に、サーバは、通知を遮断する。サーバは、次の条件の中の１つと一致すると、“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断規則を無視し、評価しない。：

“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｅｎａｂｌｅ”属性の値が偽（ＦＡＬＳＥ）に設定された場合に、又は、
“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素の“ｖａｌｉｄ-ｔｉｌｌ”属性に明示された時間が満了した場合。

サーバが“ｉｄ”属性及びＴＲＵＥに設定された“ｒｅｍｏｖｅ”属性を有する“ｎｏｔｂｌｏｃｋ-ｆｉｌｔｅｒ”要素内の通知遮断規則を受信する場合に、サーバは、同一の“ｉｄ”属性値を有するサーバに格納されている通知遮断規則を削除する。

以下では、本発明によるプレゼンス属性に基づくプレゼンス通知方法について説明する。

次のセクションは、図６及び図７に示すフロー例を提示する。

まず、ユーザーが不在の時にフィルターを設定する場合について説明する。

図６に示すようなこの例では、ユーザーＡは、フィルター規則を“不在の時には通知を送信しないようにする”に設定する。このために、ユーザーＡは、ＳＵＢＳＣＲＩＢＥ要請を構成し、本発明で定義されたスキーマにより通知遮断フィルター規則をボディーとして含ませる。この例において、ユーザーＡは、ＲＦＣ４４８０“プレゼンス情報データフォーマットへのリッチプレゼンス拡張（Rich Presence Extensions to the Presence Information Data Format（ＰＩＤＦ））”によるＰＩＤＦ文書の“ａｗａｙ”ＲＰＩＤ要素にＰｒｅｓＡｔｔｒｉｂを設定し、これにより、サーバは、ユーザーＡのＲＰＩＤプレゼンス属性が“ａｗａｙ”である場合には、この通知を送信しない（６４０）。サーバは、この要請を受信した後に分析し、登録状態ヘッダー要素にＣｏｎｄＯＫを含む通知を送信する。このようにして、この方法を使用して通知遮断フィルタリング規則を設定する（６５０）。

次いで、クライアントが通信しようとしない場合について説明する。

図７に示すようなこの例では、ユーザーＡは、フィルター規則を通信しようとしない場合には、“通知を送信しないようにする”に設定する。このために、ユーザーＡは、ＳＵＢＳＣＲＩＢＥ要請を構成し、本発明で定義されたスキーマにより通知遮断フィルター規則をボディーとして含む。この例において、ユーザーＡは、ＰｒｅｓＡｔｔｒｉｂをＰＩＤＦ文書の“先行的であり自発的な（overriding-willingness）”要素に設定し、“Ｅｑｕａｌｓ”属性を“ｃｌｏｓｅｄ”に設定し、これにより、プレゼンスサーバは、ユーザーＡの“ｏｖｅｒｒｉｄｉｎｇ-ｗｉｌｌｉｎｇｎｅｓｓ”プレゼンス属性が“ｃｌｏｓｅｄ”である場合には、この通知を送信しない（７４０）。サーバは、この要請を受信した後に分析し、登録状態ヘッダー要素にＣｏｎｄＯＫを含む通知を送信する。したがって、この方法を使用してフィルタリング規則を設定する（７５０）。

本明細書及び添付図面により示されたような本発明の様々な方法及び装置の組合せから他の制御方法及び装置を引き出すことができ、これらも本発明の範囲内にあるものであることが当業者には自明であろう。さらに、このような組合せ及び変形が上述した説明では省略されている。あわせて、アプリケーションを格納するためのホストは、これに限定されるのではないが、マイクロチップ、マイクロプロセッサー、ポケット用通信装置、コンピュータ、レンダリング装置、又は多機能装置を含むものであることを理解すべきである。

本発明は、添付図面を参照して好ましい実施形態に関連して十分に説明されたが、様々な変更及び修正が可能であるということが、当該技術分野における通常の知識を持つ者にとっては明らかである。このような変更及び修正は、本発明の範囲及び趣旨を逸脱することなく、特許請求の範囲の記載及びこれと均等なものの範囲内に含まれる。

１１０ クライアント
１２０ プレゼンスサーバ
１４０ プレゼンスＸＭＬ文書管理サーバ（ＸＤＭＳ）
３１０ ウォッチャー
３２０ ＳＩＰコア
３３０ プレゼンスサーバ
４１０ ウォッチャー
４２０ ＳＩＰコア
４３０ ホームプレゼンスサーバ
４４０ プレゼンスサーバ
４５０ ＳＩＰコア
４６０ プレゼンスソース

Claims (15)

1. プレゼンス属性に基づくプレゼンス通知システムであって、
   プレゼンス登録及びプレゼンス情報を格納するプレゼンスサーバと、
   認証関連情報を格納するプレゼンスＸＤＭサーバ（ＸＤＭＳ）と、を具備し、
   前記プレゼンスサーバは、プレゼンス属性に基づく通知伝達に関するフィルタリング規則を格納することを特徴とするプレゼンス属性に基づくプレゼンス通知システム。
2. 前記プレゼンスサーバは、ウォッチャーがユーザーのプレゼンス属性を見るのを認証されるものに関する通知を前記ウォッチャーのプレゼンス属性に基づいてフィルタリングするフィルターを格納することを特徴とする請求項１に記載のプレゼンス属性に基づくプレゼンス通知システム。
3. 前記ウォッチャーに対して前記通知が発生した場合に、前記通知が前記ウォッチャーのプレゼンス属性に基づく通知遮断フィルターを通過することを特徴とする請求項１に記載のプレゼンス属性に基づくプレゼンス通知システム。
4. 前記通知遮断フィルターが前記通知を許容する場合に、前記通知が前記ウォッチャに送信されることを特徴とする請求項１に記載のプレゼンス属性に基づくプレゼンス通知システム。
5. プレゼンス属性に基づくプレゼンス通知方法であって、
   プレゼンスサーバがプレゼンス登録及びプレゼンス情報を格納するステップと、
   プレゼンスＸＤＭサーバ（ＸＤＭＳ）が認証関連情報を格納するステップと、
   を具備し、
   プレゼンス属性に基づく通知伝達に関するフィルタリング規則が前記プレゼンスサーバとともに使用されることを特徴とするプレゼンス属性に基づくプレゼンス通知方法。
6. 前記プレゼンスサーバは、ウォッチャーがユーザーのプレゼンス属性を見るのを認証されるものに関する通知を前記ウォッチャーのプレゼンス属性に基づいてフィルタリングするフィルターを格納することを特徴とする請求項５に記載のプレゼンス属性に基づくプレゼンス通知方法。
7. 前記ウォッチャーに対して前記通知が発生した場合に、前記通知が前記ウォッチャーのプレゼンス属性に基づく通知遮断フィルターを通過することを特徴とする請求項５に記載のプレゼンス属性に基づくプレゼンス通知方法。
8. 前記通知遮断フィルターが前記通知を許容する場合に、前記通知が前記ウォッチャに送信されることを特徴とする請求項５に記載のプレゼンス属性に基づくプレゼンス通知方法。
9. 前記フィルタリング規則を使用するフィルタリングの際に、クライアントがウォッチャーのプレゼンス属性に基づく通知遮断フィルターボディーを含むＳＵＢＳＣＲＩＢＥ要請を構成し、前記プレゼンスサーバ内に含まれているフィルターが通知を送信する前に確認されるべき詳細条件を前記通知遮断フィルターボディー内に含ませることを特徴とする請求項５に記載のプレゼンス属性に基づくプレゼンス通知方法。
10. 前記プレゼンスサーバは、前記クライアントから前記ＳＵＢＳＣＲＩＢＥ要請を受信した後に、前記詳細条件を評価することを特徴とする請求項９に記載のプレゼンス属性に基づくプレゼンス通知方法。
11. 前記プレゼンスサーバが前記詳細条件を解析し、処理することができる場合には、前記プレゼンスサーバは、肯定応答を前記クライアントに送信した後に、登録状態ヘッダー及びプレゼンス属性が含まれているフィルターを含む後続通知を前記クライアントに送信することを特徴とする請求項１０に記載のプレゼンス属性に基づくプレゼンス通知方法。
12. 前記通知されたフィルターが前記プレゼンスサーバに格納され、前記通知が発生する度に、前記詳細条件が確認されることを特徴とする請求項１１に記載のプレゼンス属性に基づくプレゼンス通知方法。
13. 相互に異なるドメインにそれぞれ位置する２つのプレゼンスサーバが、ルートヘッダーフィールドを使用してネットワーク対ネットワークインターフェーシングを行うことを特徴とする請求項５に記載のプレゼンス属性に基づくプレゼンス通知方法。
14. 図１乃至図７のうちのいずれか１つに対応するプレゼンス属性に基づくプレゼンス通知システム。
15. 図１乃至図７のうちのいずれか１つに対応するプレゼンス属性に基づくプレゼンス通知方法。

Images