JP4616758B2 - プレゼンス管理方法及びプレゼンス管理装置 - Google Patents

Description

本発明は、プレゼンスシステムにおけるプレゼンス管理方法に関する。

プレゼンスシステムとは、人や物などのプレゼンティティに関する現在の状態、すなわちプレゼンス情報を管理するシステムである。プレゼンスシステムでは、何れかのプレゼンティティのプレゼンス情報が更新されると、そのプレゼンティティのプレゼンス情報をサブスクライブしているウォッチャーに、そのプレゼンス情報がリアルタイムで通知される。

近年、人を介さずに情報を送受できる無線タグ技術が、流通システムや在庫管理システムなど物品管理システムにおいて用いられつつある。従来の物品管理システムでは独自の情報管理が行われている。しかし、物品管理システムなどにおいて、物品の管理へのプレゼンスシステムの適用が今後拡大すると予想される。プレゼンスシステムでは、物品のプレゼンス情報の管理とプレゼンス情報の変化通知とを、リアルタイムに行うことができるからである。

従来のプレゼンスシステムでは、プレゼンス情報の更新の都度、更新されたプレゼンス情報がウォッチャーに通知される。しかし、物品の管理にプレゼンスシステムを適用しようとすると、プレゼンス情報の通知回数は膨大になる。そのため、ウォッチャーにとって、効率的なプレゼンスの管理が難しい。例えば、ウォッチャーが物品を効率的に管理するためには、自分で物品のプレゼンス情報を分類しなければならない。また、大量に存在する物品それぞれのプレゼンス情報に対し、サブスクライブを一つ一つ実行しなければならない。このため、ウォッチャーの負担が高くなってしまうと言う問題がある。

さらに、大量の物品のプレゼンス情報を、それらが変化するたびにウォッチャーに通知すると、通知の頻度が高く、送信される情報量も相当なものとなり、ネットワークの負荷が増大すると言う問題がある。
特許文献１には、プレゼンスの通知方法において、ウォッチャーに通知すべきプレゼンスがある場合、一定時間毎に全てのプレゼンスを一括で送信する技術が開示されている。
特開2004-72485公報

前記特許文献１は、プレゼンス情報の通知回数を減じ、ネットワーク負荷を減じる点である程度の効果を奏すると考えられる。その一方、特許文献１に記載の技術は、プレゼンス情報の通知先毎に、プレゼンティティの複数のプレゼンス情報を一括通知する。このため、ウォッチャーから見れば、様々なプレゼンス情報が一括通知されてきてしまうことになる。結局、ウォッチャーが自分でプレゼンス情報を分類しなければならなくなるという問題は解消されていない。また、大量に存在する物品一つ一つに対するサブスクライブの負担も依然として残存したままである。

本発明は、プレゼンスシステムを用いて人や物のプレゼンス情報をサブスクライブするウォッチャーの負担を軽減することを目的とする。

前記課題を解決するために、発明１は、複数のクライアントと接続され、管理手段と通知先管理手段と集約手段と集約通知手段とを有するプレゼンス管理装置が実行するプレゼンス管理方法を提供する。この方法は、以下のステップを含む。
・属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する、前記管理手段により実行される管理ステップ、
・前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する、前記通知先管理手段により実行される通知先管理ステップ、
・同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する、前記集約手段により実行される集約ステップ、
・前記集約ステップで生成された集約プレゼンス情報を、前記通知先クライアントに通知する、前記集約通知手段により実行される集約通知ステップ。
前記管理ステップは、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
前記集約ステップは、
・前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
・実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
・前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
・前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する。

発明２は、前記発明１において、前記通知先管理ステップが、前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、そのプレゼンス情報の通知先クライアントと、の新たな対応付けの登録を受け付け、受け付けた対応付けを、前記通知先管理テーブルにさらに記憶するプレゼンス管理方法を提供する。この方法において、前記集約ステップは、１）前記新たな対応付けにおける提供元クライアントのプレゼンス情報に含まれる属性値を抽出し、２）前記新たな対応付けにおける通知先クライアントと対応づけられている既存の提供元クライアントであって、前記抽出した属性値をそのプレゼンス情報に含む既存の提供元クライアントを、前記通知先管理テーブルから検索し、３）検索した既存の提供元クライアントのプレゼンス情報と、前記新たな提供元クライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成する。また、前記集約通知ステップは、前記集約プレゼンス情報を、前記新たな通知先クライアントに通知する。

発明３は、前記発明１において、前記集約ステップが、１）任意のクライアントから属性値を含む集約条件の指定を受け付け、２）前記通知先管理テーブルにおいて前記指定元クライアントを通知先とするプレゼンス情報のうち、前記指定された属性値を有するプレゼンス情報の提供元クライアントを特定し、３）前記特定した提供元クライアントのプレゼンス情報を含む集約プレゼンス情報を生成する、プレゼンス管理方法を提供する。この方法において、前記集約通知ステップは、前記生成した集約プレゼンス情報を、前記集約条件の指定元クライアントに通知する。

発明４は、前記発明１において、前記管理ステップが、任意のクライアントからプレゼンス情報の更新を受け付けるプレゼンス管理方法を提供する。この方法において、前記集約ステップは、１）更新されたプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアントを特定し、２）前記特定された提供元クライアントに対し、前記通知先管理テーブルで対応づけられている通知先クライアントを特定し、３）前記特定された提供元クライアントのプレゼンス情報と、前記更新されたプレゼンス情報と、を含む集約プレゼンス情報を生成する。また、前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する。

発明５は、前記発明１において、前記集約ステップは、前記同一の属性値と、前記同一の属性値を有するプレゼンス情報である集約対象プレゼンス情報の提供元クライアントと、前記集約対象プレゼンス情報に基づいて生成される集約プレゼンス情報の識別子と、前記集約プレゼンス情報の通知先クライアントと、を対応づける集約情報テーブルを記憶するプレゼンス管理方法を提供する。この方法において、前記管理ステップは、前記集約ステップで生成された集約プレゼンス情報と、前記集約プレゼンス情報の識別子と、を対応付けて管理する。

発明６は、前記発明１において、前記集約情報テーブルに記憶されているいずれかの属性値の指定を任意のクライアントから受け付け、前記クライアントを通知先クライアントとする集約プレゼンス情報のうち、指定された属性値を有する集約プレゼンス情報のエントリを、前記集約情報テーブルから削除する解除ステップをさらに含むプレゼンス管理方法を提供する。

発明７は、発明１において、集約プレゼンス情報の通知条件を定義する通知ルールを記憶する通知ルール記憶ステップをさらに含むプレゼンス管理方法を提供する。このプレゼンス管理方法において、前記集約ステップは、前記通知ルールに基づいて、集約プレゼンス情報を生成するか否かを判断する。また、前記集約通知ステップは、前記通知ルールに基づいて、集約プレゼンス情報を送信するか否かを判断する。

発明８は、複数のクライアントと接続されるプレゼンス管理装置を提供する。この装置は以下の手段を含む。
・属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段、
・前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段、
・同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段、
・前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段。
前記管理手段は、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
前記集約手段は、
・前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
・実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
・前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
・前記集約通知手段は、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する。

発明９は、複数のクライアントと接続されるコンピュータが実行するプレゼンス管理プログラムを提供する。このプログラムは、前記コンピュータを機能させる。
・属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段、
・前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段、
・同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段、及び
・前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段。
前記管理手段は、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
前記集約手段は、
・前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
・実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
・前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
・前記集約通知手段は、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する。

本発明を用いれば、複数のプレゼンス情報を属性毎に集約して一括通知するので、ウォッチャーはプレゼンス情報の属性毎にプレゼンス情報の更新通知を受けることができる。そのため、ウォッチャーが受信したプレゼンス情報を分類する負担が軽減される。

＜語句の定義＞
最初に、以下の実施形態で説明するプレゼンスシステムにおける用語の定義を説明する。
プレゼンティティ：プレゼンス情報を設定する主体であり、下記実施形態のクライアントに相当する。

ウォッチャー（サブスクライバー）：他の主体のプレゼンス情報をサブスクライブし、変更時にそのプレゼンス情報を受信する主体である。サブスクライブされる他の主体のプレゼンス情報をサブスクライブする側の主体として、サブスクライバーと称する場合がある。
バディ（サブスクライビー）：プレゼンス情報のサブスクライブを希望する主体が指定したサブスクライブ先の主体。サブスクライブされる側の主体として、サブスクライビーと称する場合がある。

サブスクライブ：ある主体が他の主体のプレゼンス情報を参照すること。より厳密には、ある主体が他の主体のプレゼンス情報を自己に配信してもらうために、プレゼンスシステム内のサーバに対し、自己をウォッチャーとして、他の主体をバディとして登録すること。
＜第１実施形態＞
《構成》
１．システム全体
図１は、第１実施形態に係るプレゼンスシステムの構成を示す説明図である。プレゼンスシステムは、サーバＳと複数のクライアントＣ１，Ｃ２，Ｃ３，Ｃ４・・・（以下、単にクライアントＣと記載する）とを含む。サーバＳとクライアントＣとは、インターネットや電話回線などのネットワークを介して接続される。サーバＳ及びクライアントＣは、共にコンピュータ端末で実現される。

サーバＳは、各クライアントＣからプレゼンス情報を受信し、各クライアントＣの最新のプレゼンス情報を記憶する。また、サーバＳは、プレゼンス情報をそのウォッチャーであるクライアントＣに配信する。本プレゼンスシステムにおいて、サーバＳが管理するプレゼンス情報は、属性値を含む。属性値は、プレゼンス情報の一部である。属性値としては、商品名や場所の名前などを一例として挙げることができ、特に限定されない。例えば、属性値は、プレゼンス情報を構成するXML(eXtensible Markup Language)フォーマットで記述されたデータ内のタグの名称であってもよい。

本プレゼンスシステムにおいて、各クライアントはクライアントＩＤで特定される。以下において、プレゼンス情報を提供するクライアントをプレゼンティティ、他のプレゼンティティのプレゼンス情報を参照するクライアントをウォッチャーと言う。なお、クライアントは、プレゼンティティ及びウォッチャーとして機能するものもあれば、どちらか一方の機能しか有しないものもある。また、プレゼンティティであるクライアントのＩＤをプレゼンティティＩＤ、ウォッチャーであるクライアントのＩＤをウォッチャーＩＤという。

２．サーバ
図２（ａ）は、サーバＳの機能構成を示すブロック図である。サーバＳは、下記（ａ）〜（ｊ）の機能を有している。
（ａ）バディリスト１１
（ｂ）ウォッチャーリスト１２
（ｃ）集約情報テーブル１３
（ｄ）ルールＤＢ１４
（ｅ）プレゼンス管理部１５
（ｆ）プレゼンス通知部１６
（ｇ）集約部１７
（ｈ）集約許可取得部１８
（ｉ）通知ルール設定部１９
（ｊ）解除部１１０
以下、各機能について詳述する。

（ａ）バディリスト
図３は、バディリスト１１の一例を示す説明図である。バディリスト１１は、「サブスクライバーＩＤ」と、「バディＩＤ」と、を対応付けて記憶する。サブスクライバーは、バディと呼ばれる他のクライアントのウォッチャーである。以下、サブスクライバーのクライアントＩＤを、単にサブスクライバーＩＤという。バディは、サブスクライバーがサブスクライブしているプレゼンティティである。以下、バディのクライアントＩＤを、バディＩＤという。サブスクライバーがバディＩＤを指定してサブスクライブすることにより、サブスクライバーＩＤとバディＩＤとが対応付けてバディリスト１１に登録される。

（ｂ）ウォッチャーリスト
図４は、ウォッチャーリスト１２の一例を示す説明図である。ウォッチャーリスト１２は、「サブスクライビーＩＤ」と、サブスクライビーの「プレゼンス情報」と、「ウォッチャーＩＤ」と、を対応付けて記憶する(管理ステップ、通知先管理ステップに相当)。サブスクライビーは、前記バディリスト１１におけるバディに相当する。サブスクライビーのクライアントＩＤを、サブスクライビーＩＤという。ウォッチャーは、前記バディリスト１１におけるサブスクライバーに相当する。ウォッチャーのクライアントＩＤを、ウォッチャーＩＤという。バディリスト１１にサブスクライバーＩＤとバディＩＤとが登録されると、ウォッチャーリスト１２にはバディＩＤがサブスクライビーＩＤとして、サブスクライバーＩＤがウォッチャーＩＤとして、それぞれ登録される。プレゼンス情報は、プレゼンス管理部１５により更新される。

本発明では、サブスクライビーＩＤとして、実在するクライアントのＩＤ以外に、集約プレゼンティティと呼ばれる仮想クライアントのＩＤが記述される。集約プレゼンティティは、集約プレゼンス情報のプレゼンティティである。集約プレゼンス情報は、同一のウォッチャーに対応付けられた複数のプレゼンティティのプレゼンス情報であって、同一属性値を有するプレゼンス情報を含む。この例は、集約プレゼンティティＩＤ「User1＿DVDRecorder」の集約プレゼンス情報を、ウォッチャー「User1」がサブスクライブしていることを示す。

なお、この例では、ウォッチャーリスト１２は各サブスクライビーＩＤで特定されるクライアントのプレゼンス情報を管理するテーブルとしての機能も有している。
（ｃ）集約情報テーブル
図５は、集約情報テーブル１３の一例を示す説明図である。集約情報テーブル１３は、「サブスクライバーＩＤ」と、「集約属性」と、「集約プレゼンティティＩＤ」と、「集約対象プレゼンティティＩＤ」とを、対応付けて記憶している。

「サブスクライバーＩＤ」は、集約プレゼンス情報のウォッチャーのクライアントＩＤである。「集約属性」は、集約されるプレゼンス情報が共通に有している属性値である。言い換えれば、あるウォッチャーに通知されるプレゼンス情報のうち、同一の属性値を有するプレゼンス情報は、集約プレゼンス情報に集約される。以下、集約プレゼンス情報に集約されるプレゼンス情報を、集約対象プレゼンス情報という。

「集約プレゼンティティＩＤ」は、集約プレゼンス情報のプレゼンティティである集約プレゼンティティを特定する識別子である。集約プレゼンティティＩＤは、いかなるクライアントＩＤとも重複しないように設定される。
「集約対象プレゼンティティＩＤ」は、集約対象プレゼンティティを特定するクライアントＩＤである。集約対象プレゼンティティは、集約対象プレゼンス情報のプレゼンティティである。

この図では、例えば、ウォッチャー「User1」がサブスクライブしているプレゼンス情報のうち、属性値「DVDRecorder」を有するプレゼンス情報のプレゼンティティは、「Item1」、「Item2」、「Item10」である。プレゼンティティ「Item1」、「Item2」、「Item10」の各プレゼンス情報を含む集約プレゼンス情報のプレゼンティティは、「User1＿DVDRecorder」である。従って、ウォッチャー「User1」には、プレゼンティティ「Item1」、「Item2」、「Item10」の集約プレゼンス情報「User1＿DVDRecorder」が通知される。

（ｄ）ルールＤＢ
ルールＤＢ１４には、各種のルールが記憶される。例えば、集約ルールや集約許可ルール、プロファイル定義、通知ルールが、ルールＤＢ１４に記憶される。各ルールの詳細については後述する。
（ｅ）プレゼンス管理部
プレゼンス管理部１５は、属性を含むプレゼンス情報の設定指示を任意のクライアントＣから受信し、これをウォッチャーリスト１２に書き込む。これにより、最新のプレゼンス情報がウォッチャーリスト１２に保持される(管理ステップに相当)。またプレゼンス管理部１５は、任意のクライアントＣからサブスクライブやその削除を受け付け、バディリスト１１及びウォッチャーリスト１２を更新する。プレゼンス管理部１５は、新たなクライアントＣの登録を、プレゼンスシステムの管理者が操作するクライアントＣから受け付けることもできる。さらに本実施形態では、プレゼンス管理部１５は、集約の指示、集約解除の指示、及び集約プレゼンス情報の通知ルールの指示を、クライアントＣから受け付け、集約部１７、解除部１１０、及び通知ルール設定部１９にそれぞれ受け付けた指示を渡す。

より具体的には、プレゼンス管理部１５は、クライアントＣに対し、メニュー画面やサブメニュー画面をクライアントＣに提供し、これらの画面においてプレゼンス情報の設定やサブスクライブなどの指示を受け付ける。クライアント側での各画面の表示や、入力内容の取得には、JavaScript(登録商標)やVBScript、PerlScriptなどの技術が用いられる。また、メニュー画面やサブメニュー画面の描画を、クライアントＣ側で実行することもできる。描画実行のタイミングは、クライアントＣの起動時やプレゼンス情報の通知時、操作者から指示を受け付けたときなどである。リアルタイム性が要求されるプレゼンスシステムでは、クライアントＣ側で画面を描画する方が好ましい。

図６は、メニュー画面の一例を示す説明図である。メニュー画面は、クライアントＣを操作する操作者から各種指示を受け付けるためのインターフェースであり、サブスクライブ、新規プレゼンティティ登録、集約及び集約解除の指示を受け付ける。なお、「新規プレゼンティティ登録ボタン」は、プレゼンスシステムの管理者のクライアントのみで押下可能になっていることが、プレゼンスシステムのセキュリティ上好適である。

図７は、サブメニュー画面の一つであるサブスクライブ画面の一例を示す説明図である。図６のメニュー画面において「サブスクライブボタン」が選択されると、サブスクライブ画面がクライアント上で表示される。この画面は、少なくともバディＩＤの指定を受け付ける。受け付けられたバディＩＤは、クライアントＩＤ、すなわちサブスクライバーＩＤと共に、クライアントＣからサーバＳに送信される。サーバＳのプレゼンス管理部１５は、受信したバディＩＤ及びサブスクライバーＩＤを、それぞれバディリスト１１及びウォッチャーリスト１２に登録する。なお、バディＩＤはサブスクライビーＩＤとして、サブスクライバーＩＤはウォッチャーＩＤとして、それぞれウォッチャーリスト１２に登録される。

図８は、サブメニュー画面の一つである新規プレゼンティティ登録画面の一例を示す説明図である。図６のメニュー画面において「新規プレゼンティティ登録ボタン」が選択されると、新規ユーザ登録画面がクライアント上で表示される。この画面は、少なくともプレゼンティティＩＤ及び初期プレゼンス情報の指定を受け付ける。受け付けられたプレゼンティティＩＤ及び初期プレゼンス情報は、クライアントCからサーバＳに送信される。サーバＳのプレゼンス管理部１５は、新たなエントリをウォッチャーリスト１２に生成し、受信したプレゼンティティＩＤの値をサブスクライビーＩＤとして、初期プレゼンス情報をプレゼンス情報として書き込む。

１つのプレゼンティティが複数のプレゼンス情報を有することができるプレゼンスシステムにおいては、同様にして既存のプレゼンティティの新たなプレゼンス情報の登録を受け付けても良い。
図９は、サブメニュー画面の一つである集約依頼画面の一例を示す説明図である。図６のメニュー画面において「集約ボタン」が選択されると、集約依頼画面がクライアント上で表示される。この画面は、少なくとも集約属性値を含む集約条件の指定を受け付ける。集約条件としては、この他に、集約するプレゼンス情報の最小数や、最小集約数を満たした場合に自動的に集約するかそれとも集約実行前に問い合わせするかの設定などを含んでいてもよい。この画面は、集約条件として、最小集約数の指定をさらに受け付ける。受け付けられた集約条件は、集約依頼コマンドと共に、クライアントＣからサーバＳに送信される。サーバＳのプレゼンス管理部１５は、受信した集約属性値及び最小集約数を、集約部１７に渡す。集約部１７は、渡された集約属性値や最小集約数に基づいて集約を実行する。

図１０は、サブメニュー画面の一つである集約解除依頼画面の一例を示す説明図である。図６のメニュー画面において「集約解除ボタン」が選択されると、集約解除依頼画面がクライアント上で表示される。この画面は、集約プレゼンス情報の指定を受け付ける。この画面例では、集約プレゼンス情報の指定として、集約属性値の指定を受け付ける。受け付けられた集約属性値は、集約解除コマンド及びクライアントＩＤと共に、クライアントＣからサーバＳに送信される。プレゼンス管理部１５は、受信した集約属性値及びクライアントＩＤを、解除部１１０に渡す。解除部１１０は、渡された集約属性値及びクライアントＩＤに基づいて、集約情報テーブル１３の該当エントリを削除する。

（ｆ）プレゼンス通知部
プレゼンス通知部１６は、ウォッチャーリスト１２に書き込まれたプレゼンス情報を監視し、いずれかのプレゼンス情報が更新されると、そのプレゼンス情報のウォッチャーに更新されたプレゼンス情報を通知する。ここで言うプレゼンス情報には集約プレゼンス情報も含まれる。従って、プレゼンス通知部１６は、ウォッチャーリスト１２に書き込まれた集約プレゼンス情報が更新された場合も、同様に集約プレゼンス情報のウォッチャーに集約プレゼンス情報を通知する(集約通知ステップに相当)。

プレゼンス通知部１６は、後述する通知ルールに従って集約プレゼンス情報を通知するとよい。これにより、プレゼンス通知部１６は、例えば、以下(i),(ii)のように、集約プレゼンス情報の通知に用いる通信サービスを制御する。またプレゼンス通知部１６は、以下(iii),(iv)のように、集約プレゼンス情報を通知するタイミングを制御する。
(i)通信サービスCS1を用いて通知
(ii)通信サービスCS2を用いて通知
(iii)集約対象プレゼンス情報のいずれかが変化する毎に集約プレゼンス情報を通知
(iv)一定時間毎に集約プレゼンス情報を通知
（ｇ）集約部
集約部１７は、任意のウォッチャーに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する(集約ステップに相当)。集約部１７は、集約ルールに従って集約を実行する。以下に集約のタイミング、集約の実行及び集約ルールについて、説明する。

〔集約のタイミング〕
集約のタイミングは、特に限定されない。本実施形態では、以下の3つのタイミングで集約プレゼンスを生成する。
(i)サブスクライブ時：サブスクライブ時に集約を実行することにより、新たなバディと同一の属性値を有するプレゼンス情報を持つ既存のバディと新たなバディとが集約されるので、新たなバディを一人一人を分類する負担からウォッチャーを解放することができる。

(ii) 新規プレゼンティティ登録時：新たなプレゼンティティが登録される度に集約することにより、既存のプレゼンス情報のウォッチャーは、すでに登録されているバディのプレゼンス情報と共に、集約プレゼンス情報の一部として新たなプレゼンティティのプレゼンス情報をサブスクライブすることなく参照することができる。従って、次々に登録される新たなプレゼンティティをウォッチャーが一つ一つバディとして登録する負担から、ウォッチャーを解放することができる。

(iii)ユーザによる集約指示時：ユーザによる属性値の指示に応じて集約することで、ウォッチャーは、自分の好みの分類基準に基づいて容易にバディを分類することができ、しかもバディ一人一人を分類する負担から軽減される。
〔集約の実行〕
集約部１７による集約の実行は、具体的には、i)新たな集約プレゼンティティＩＤの生成、ii)集約プレゼンティティのウォッチャーの特定、iii)集約属性値の決定、iv)集約対象プレゼンティティＩＤの特定、v)集約情報テーブル１３の更新、vi)集約プレゼンス情報の生成、及びvii)ウォッチャーリスト１２の更新、を含む。すなわち、集約部１７は、集約情報テーブル１３に、新たなエントリを生成し、サブスクライバーＩＤ、集約属性値、集約プレゼンティティＩＤ及び新たな集約対象プレゼンティティＩＤを書き込む。さらに、集約部１７は、書き込んだ集約対象プレゼンティティＩＤそれぞれの全プレゼンス情報を含む集約プレゼンス情報を生成し、これをウォッチャーリスト１２に書き込む。書き込まれる集約プレゼンス情報に対応づけられるサブスクライビーＩＤは集約プレゼンティティＩＤである。集約プレゼンス情報がウォッチャーリスト１２に記憶されるので、ウォッチャーはいつでも集約プレゼンス情報を参照することができる。そのため、ウォッチャーは、集約プレゼンス情報を記憶・管理する負担から解放される。

〔集約ルール〕
図１１は、ＸＭＬで記述した集約ルールの一例を示す説明図である。集約部１７は、集約ルールに基づいて集約を実行したり、集約実行の是非を判断することができる。集約ルールは、図９の集約依頼画面において指定された集約属性値や最小集約数に基づいて集約部１７が生成してもよいし、予めルールＤＢ１４に記憶されていてもよい。また、集約ルールは、クライアントＣに共通のルールであってもよいし、クライアントＣ毎のルールであってもよい。この例では、クライアントＩＤ毎に集約ルールが生成されている。集約ルールに基づいて集約実行の是非を判断することにより、ウォッチャーは、集約に先立ち、集約の要否を判断することができる。なお、集約ルールはこの例に限定されない。

例えば、クライアント「user1」は、属性「商品」の値が「DVDRecorder」であるプレゼンス情報を持つバディが3つとなった場合、自動的に集約を実行することを設定している。従って、集約部１７は、属性「商品」の値が「DVDRecorder」であるプレゼンス情報を持つバディが3つとなった場合、集約を実行する。一方、このクライアント「user1」は、属性「商品」の値が「LcdTv」であるプレゼンス情報を持つバディが5つとなった場合に、集約の是非の問い合わせを設定している。集約部１７は、この設定に基づいて問い合わせをウォッチャーに送信し、「集約しない」旨の応答を受信すると、集約の実行を中止する。

（ｈ）集約許可取得部
集約許可取得部１８は、集約対象プレゼンス情報のプレゼンティティ、すなわち集約対象プレゼンティティに対し、集約許可ルールに従って、集約を許可するか否かを問い合わせる。集約許可ルールは、集約対象プレゼンティティに対する問い合わせに対する応答に従って集約許可取得部１８が生成してもよいし、予めルールＤＢ１４に記憶されていてもよい。前記問い合わせは、集約部１７による集約実行前に、集約許可取得部１８が集約対象プレゼンティティに対して送信する。集約許可ルールは、クライアントＣに共通のルールであってもよいし、クライアントＣ毎のルールであってもよい。

図１２は、ルールＤＢ１４に記憶される集約許可ルールの一例を示す説明図である。この例では、プレゼンティティとなるクライアントＩＤ毎に集約許可ルールが生成されている。例えば、クライアント「item1」は、属性「商品」の値が「DVDRecorder」である自己のプレゼンス情報の集約時に、クライアント「user1」に対しては集約を許可し、別のクライアント「user9」に対しては集約を拒否し、それ以外のクライアントに対しては集約の可否を問い合わせることを設定している。

集約許可ルールを設定しておくことにより、集約対象プレゼンティティから見れば、知らないうちに同じ属性を有する他のプレゼンティティのプレゼンス情報と共に、自分のプレゼンス情報が第３者に提供されてしまうことを防止できる。従って、集約対象プレゼンティティのプライバシーを保護することができる。
なお集約許可ルールの内容は、前述の例に限定されない。例えば、集約を許可／拒否／問い合わせする対象クライアントを、クライアントＩＤではなく属性で指定することが考えられる。また、集約の許可などを、期間や自己のプレゼンス情報の属性を用いて設定することもできる。

（ｉ）通知ルール設定部
通知ルール設定部１９は、集約プレゼンス情報の通知条件の指定を集約プレゼンス情報のウォッチャーから受け付け、指定された通知条件に基づいて通知ルールを生成し、指定された通知ルールをルールＤＢ１４に記憶する。プレゼンス通知部１６は、ルールＤＢ１４に記憶されている通知ルールに従って集約プレゼンス情報を通知する。

図１３は、通知ルール指定画面の一例を示す説明図である。例えば図９の集約依頼画面で「集約ボタン」が選択されると、通知ルール指定画面がクライアント上で表示される。また、前記図6のメニュー画面において、集約プレゼンス情報の通知ルール設定ボタンを設け、そのボタンが押下されると通知ルール指定画面が表示されるようにしてもよい。通知ルール指定画面は、集約プレゼンス情報のウォッチャーから、集約プレゼンス情報の通知条件の指定を受け付ける。この例では、通知条件として、通信サービス及び通知タイミングが設定される。受け付けられた通知条件は、クライアントＣからサーバＳに送信される。サーバＳのプレゼンス管理部１５は、受信した通知条件を、通知ルール設定部１９に渡す。通知ルール設定部１９は、渡された通知条件に基づいて通知ルールを生成し、これをルールＤＢ１４に登録する。

図１４は、ＸＭＬで記述された通知ルールの一例を示す説明図である。この通知ルールは、通知ルール指定画面で指定された通信サービスを定義している。例えば、通信サービス「profile1」は、プレゼンスシステムがデフォルトの通信サービスとして設定しており、「帯域幅は狭く、料金は高い」ことを示している。通信サービス「user1＿profile1」は、クライアントが設定した通信サービスであり、帯域幅は広く、コストは中程度である」ことを示している。

図１５は、ＸＭＬで記述された通知ルールの別の一例を示す説明図である。この通知ルールは、通知ルール指定画面で指定された通知タイミングを定義している。例えば、通知タイミング「method1」は、「プレゼンスシステムにより定義されたデフォルトの通知タイミング」であり、「30分毎に、直近に更新された10の集約対象プレゼンス情報を含めて通知する」ことを定義している。また、通知タイミング「user1＿method1」は、「クライアントにより定義された通知タイミング」であり、「集約プレゼンス情報が最後に変更されてから1分更新がないと、全ての集約対象プレゼンス情報を含めて通知する」ことを定義している。

適度な間隔で集約プレゼンス情報が通知されるよう通知タイミングを設定すれば、集約プレゼンス情報の通知頻度を抑制することができる。ひいては、ウォッチャーの監視負担を軽減し、ネットワーク負荷を軽くすることができる。
（ｊ）解除部
解除部１１０は、集約を解除する。解除の判断基準としては、集約解除対象を指定されたとき、集約条件を満たさなくなったとき、などが考えられる。判断基準はプレゼンス集約解除ルールにより定義される。次にこの二つの判断基準及びプレゼンス集約解除ルールについて、より詳細に説明する。

〔指定による解除〕
解除の指定は、前述の図１０に例示される集約解除依頼画面により受け付けられ、クライアントCからサーバＳに送信される。解除部１１０は、図１０の集約解除依頼画面で指定された集約属性値及びウォッチャーＩＤをプレゼンス管理部１５から取得し、指定された集約プレゼンス情報の集約を解除する。集約の解除とは、具体的には、ウォッチャーリスト１２及び集約情報テーブル１３から、指定された集約プレゼンス情報のエントリを削除することである。

より具体的には、解除部１１０は、指定された集約属性値及びウォッチャーＩＤをキーに集約情報テーブル１３を検索し、該当するエントリを特定する。さらに解除部１１０は、そのエントリに記述された集約情報プレゼンティティＩＤを読み出し、その集約情報プレゼンティティＩＤと一致するサブスクライビーＩＤを含むエントリを、ウォッチャーリスト１２から特定する。特定されたエントリは、集約情報テーブル１３及びウォッチャーリスト１２から削除される。これにより、集約の解除が完了する。

〔条件を満たさなくなることによる解除〕
解除部１１０は、集約条件が満たさなくなった集約を解除する。集約条件を満たしているか否かの判断のタイミングは、例えばプレゼンス情報の更新時に行うことが考えられる。具体的には、解除部１１０は、集約対象プレゼンティティのプレゼンス情報が更新され、その属性値が集約属性値と一致しなくなる場合を検出する。次いで、解除部１１０は、残っている集約対象プレゼンティティの数が最小集約数以上か否かを判断する。残りの集約対象プレゼンティティが最小集約数を下回った場合、解除部１１０はその集約プレゼンティティＩＤを特定し、そのＩＤを含むエントリを集約情報テーブル１３及びウォッチャーリスト１２から削除する。

なお、解除部１１０は、集約を解除するに先立ち、ウォッチャーに問い合わせを送信し、その応答に応じて集約解除を実行または中止してもよい。これにより、ウォッチャーは、集約解除前に集約が解除されることを知ることができる。
〔プレゼンス集約解除ルール〕
図１６は、ＸＭＬで記述されたプレゼンス集約解除ルールの一例を示す説明図である。プレゼンス集約解除ルールは、集約解除の判断基準を定義する。このルールは、予めルールＤＢ１４に記憶されていてもよいし、クライアントＣから受け付けた解除条件に基づいて生成されてもよい。プレゼンス集約解除ルールは、クライアントＣに共通のルールであってもよいし、クライアントＣ毎のルールであってもよい。

図１６の例では、プレゼンス集約解除ルールは、クライアント「user1」は、属性「商品」の値が「DVDRecorder」であるプレゼンス情報の最小集約数が３未満になると自動的に集約解除することを定義している。またこのクライアント「user1」は、属性「商品」の値が「LcdTv」であるプレゼンス情報の最小集約数が５未満になると、集約解除の可否をユーザに問い合わせる」ことを意味している。

３．クライアント
再び図２に戻り、クライアントＣの機能について説明する。図２（ｂ)は、クライアントＣの機能構成を示すブロック図である。クライアントＣは、以下の構成要素（ａ）〜（ｄ）を有している。
（ａ）プレゼンス検出部２１：クライアントＣまたはその操作者のプレゼンス情報の変化を検出する。例えば特定のアプリケーションが動作しているか否か、キーボードやマウスなどによる入力間隔や、操作者自身によるプレゼンス情報の入力などを検出する。

（ｂ）プレゼンス更新部２２：プレゼンス検出部２１が検出したプレゼンス情報を、サーバＳに対して送信する。
（ｃ）プレゼンス受信部２３：バディのプレゼンス情報や集約プレゼンス情報を、サーバＳから受信する。
（ｄ）プレゼンス表示部２４：サーバＳから画面が提供される場合には、提供されるメニュー画面やサブメニュー画面を表示する（前記図６〜図１０、図１３参照）。クライアントＣ側で画面を描画する場合には、画面の描画を実行する。また、プレゼンス表示部２４は、メニュー画面内の所定の領域に、プレゼンス情報と集約プレゼンス情報とを視覚的に区別可能に表示する。前記図６は、プレゼンス情報と集約プレゼンス情報とを区別可能に表示した表示例である。この図では、集約プレゼンス情報と未集約プレゼンス情報とが、別々のフィールドに表示されている。また、集約プレゼンス情報の集約属性値が表示され、集約属性値をクリックすると集約対象プレゼンス情報が表示される。図６は、集約属性値「デスクトップＰＣ」がクリックされ、その集約対象プレゼンス情報と集約対象プレゼンティティＩＤ(item16, item23)とが表示されている例を示している。

集約プレゼンス情報をその集約属性値などでまとめて表示することにより、限られた表示領域を有効に利用することができる。また、大量に存在するプレゼンス情報を階層的に表示することになるので、ウォッチャーがプレゼンス情報を監視するのに要する労力を軽減することにつながる。
《処理》
（１）集約
次にサーバＳが実行する集約処理を、例を挙げて説明する。以下では、サブスクライブ時、新規ユーザ登録時、クライアントからの集約依頼時に、プレゼンス情報を集約する場合を例に挙げて説明する。ただし、集約の実行タイミングは、これらの例に限定されない。

（１−１）サブスクライブ集約処理
図１７は、サーバＳが実行するサブスクライブ集約処理の流れの一例を示すフローチャートである。この処理は、サーバの起動により開始される。この処理は、集約済判断処理、集約実行処理、集約見送り処理及び集約通知処理に大別される。
〔集約済判断処理：Ｓ１０１〜Ｓ１０４〕
集約済判断処理では、新たなサブスクライブが発生する度に、サブスクライバーにとってサブスクライビーが有する属性に基づく集約が実行されているか否かを判断する。

ステップＳ１０１：集約部１７は、プレゼンス管理部１５を介し、任意のクライアントからのサブスクライブを待機する。サブスクライブが生じるとステップＳ１０２に移行する。今、サブスクライバー「User1」から、サブスクライビー「Item10」に対するサブスクライブが生じた場合を考える。
ステップＳ１０２：集約部１７は、新たなサブスクライビーの現在のプレゼンス情報から、１以上の属性値を抽出する。具体的には、集約部１７は、クライアントからの受信データから、サブスクライビーＩＤ「Item10」を抽出する。また、集約部１７は、「ウォッチャーテーブル」から、サブスクライビー「Item10」の現在のプレゼンス情報「<商品>DVDRecorder</商品>輸送中」を読み出す。さらに、集約部１７は、読み出したプレゼンス情報から属性値「DVDRecorder」を抽出する。

ステップＳ１０３：集約部１７は、抽出した属性値「DVDRecorder」を、集約情報テーブル１３内で検索する。
ステップＳ１０４：集約部１７は、抽出した属性値「DVDRecorder」が集約情報テーブル１３になければ、ステップＳ１０５に移行し、集約及び集約プレゼンス情報の通知を実行する（Ｓ１０５〜Ｓ１１１）。すなわち、サブスクライビーの属性が未集約の場合、集約を実行する。

逆に、抽出した属性値「DVDRecorder」が集約情報テーブル１３にあれば、対応する集約プレゼンティティＩＤ「User1＿DVDRecorder」を抽出し、後述するステップＳ１１４に移行する。すなわち、サブスクライビーの属性が集約されていれば、集約情報テーブル１３の更新を行い、集約プレゼンス情報をサブスクライバーに通知する。
〔集約実行処理：Ｓ１０５〜Ｓ１１２〕
集約実行処理では、集約されていないが、同じ属性を有するサブスクライビーがすでに規定数いる場合、集約を実行し、集約対象プレゼンティティのプレゼンス情報をまとめてサブスクライバーに通知する。

ステップＳ１０５：集約部１７は、新たにサブスクライブされたプレゼンス情報が集約されていない場合、サブスクライバーＩＤ「User1」に対応づけられた既存のバディＩＤを、バディリスト１１から読み出す。
ステップＳ１０６：集約部１７は、ウォッチャーテーブルを検索し、取得した既存バディＩＤそれぞれのプレゼンス情報に含まれる属性値を取得する。さらに集約部１７は、既存バディＩＤの属性値を、新たなサブスクライビーの属性値「DVDRecorder」と順次比較し、新たなサブスクライビーの属性値「DVDRecorder」と一致する属性値を有する既存バディＩＤの数をカウントする。

ステップＳ１０７：集約部１７は、新たなサブスクライビーの属性値「DVDRecorder」と一致する属性値を有する既存バディＩＤの数が、規定数以上か否かを判断する。規定数以上であれば、集約すると判断し、ステップＳ１０８に移行する。規定数未満であれば、集約しないと判断し、後述するステップＳ１１３に移行する。
ステップＳ１０８：集約部１７は、新たな集約プレゼンティティＩＤ、例えば「User1＿DVDRecorder」を生成する。また、サブスクライビー「Item10」と同一の属性値「DVDRecorder」を有する既存バディＩＤ及びサブスクライビーＩＤ「Item10」を、集約対象プレゼンティティＩＤに決定する。

ステップＳ１０９：集約部１７は、ウォッチャーリスト１２へのサブスクライビーＩＤ及びウォッチャーＩＤの登録依頼をプレゼンス管理部１５に渡す。この登録依頼は、サブスクライビーＩＤとして集約プレゼンティティＩＤ「User1＿DVDRecorder」を、ウォッチャーＩＤとしてサブスクライバーＩＤ「User1」を、それぞれ含む。この登録依頼により、ウォッチャーリスト１２に新たなエントリが追加される。このエントリには、サブスクライビーＩＤ「User1＿DVDRecorder」及びウォッチャーＩＤ「User1」が、それぞれ書き込まれる。

また、プレゼンス管理部１５は、バディリスト１１において、サブスクライバー「User1」に対応するバディＩＤに、サブスクライビーＩＤ「Item10」が追加される。また、ウォッチャーリスト１２において、サブスクライビー「Item10」に対応するウォッチャーＩＤに、サブスクライバーＩＤ「User1」が追加される。
ステップＳ１１０：集約部１７は、集約情報テーブル１３に新たなエントリを生成し、サブスクライバーＩＤ、集約属性、集約プレゼンティティＩＤ及び集約対象プレゼンティティＩＤを、書き込む。この例では、サブスクライバーＩＤ「User1」、集約属性「DVDRecorder」、集約プレゼンティティＩＤ「User1＿DVDRecorder」、集約対象プレゼンティティＩＤ「Item1」、「Item2」、「Item10」が、それぞれ書き込まれる。

ステップＳ１１１：集約部１７は、集約対象プレゼンティティＩＤに対応するプレゼンス情報をウォッチャーリスト１２から読み出し、全てのプレゼンス情報を含む集約プレゼンス情報を生成する。生成された集約プレゼンス情報は、集約プレゼンティティＩＤ「User1＿DVDRecorder」のプレゼンス情報として、ウォッチャーリスト１２に書き込まれる。
ステップＳ１１２：ウォッチャーリスト１２のプレゼンス情報が更新されると、プレゼンス通知部１６は、更新されたプレゼンス情報をそのウォッチャーに送信する。具体的には、プレゼンス通知部１６は、書き込まれた集約プレゼンス情報のウォッチャー「User1」に、集約プレゼンス情報を送信する。

〔集約見送り処理：Ｓ１１３〕
集約見送り処理では、サブスクライビーが集約されていないものの、同じ属性を有するサブスクライビーが規定数に達しない場合、集約は行わず、通常のサブスクライブを行う。
ステップＳ１１３：前記ステップＳ１０７で、新たなサブスクライビーの属性値「DVDRecorder」と一致する属性値を有する既存バディＩＤの数が、規定数未満の場合、集約は実行されない。その場合、集約部１７は、通常のサブスクライブに対応する処理を、プレゼンス管理部１５に依頼する。プレゼンス管理部１５は、サブスクライビーＩＤ「Item10」を、サブスクライバーＩＤ「User1」のバディＩＤとしてバディリスト１１に追加登録する。また、プレゼンス管理部１５は、サブスクライビー「Item10」のウォッチャーＩＤとして、サブスクライバーＩＤ「User1」をウォッチャーリスト１２に追加登録する。その後、プレゼンス通知部１６は、サブスクライビー「Item10」のプレゼンス情報を、ウォッチャー「User1」に通知する。

〔集約通知処理：Ｓ１１４〜Ｓ１１６，Ｓ１１２〕
集約通知処理では、新たなサブスクライビーが有する属性に基づく集約が実行されていれば、他の集約対象プレゼンティティのプレゼンス情報と共に、そのサブスクライビーのプレゼンス情報がサブスクライバーに通知される。
ステップＳ１１４：ステップＳ１０４において、新たにサブスクライブされたプレゼンス情報が集約されていれば、ステップＳ１１４に移行する。集約部１７は、プレゼンス管理部１５に対し、サブスクライブを発行する。このサブスクライブには、サブスクライバーＩＤ「User1」及びサブスクライビーＩＤ「Item10」が含まれている。

このサブスクライブに応じ、プレゼンス管理部１５は、サブスクライバーＩＤ「User1」のバディＩＤにサブスクライビーＩＤ「Item10」を登録し、サブスクライビーＩＤ「Item10」のウォッチャーＩＤに「User1」を登録する。
ステップＳ１１５：集約部１７は、ステップＳ１０４で抽出した集約プレゼンティティＩＤ「User1＿DVDRecorder」の集約対象プレゼンティティＩＤに、サブスクライビーＩＤ「Item10」を追加登録する。

ステップＳ１１６：集約部１７は、集約プレゼンティティ「User1＿DVDRecorder」の集約プレゼンス情報を生成し、ウォッチャーリスト１２に書き込む。集約プレゼンス情報は、集約プレゼンティティＩＤに対応する集約対象プレゼンティティＩＤのプレゼンス情報を全て含む。その後、プレゼンス通知部１６は、更新されたプレゼンス情報、この場合は集約プレゼンス情報を、そのウォッチャーに送信する（Ｓ１１２）。

ステップＳ１１７：上記Ｓ１０１〜Ｓ１１６の処理は、サーバの電源がオフになるまで繰り返される。
以上の処理により、新たなサブスクライブが発生する度に、必要に応じて集約が実行される。ウォッチャーから見れば、サブスクライブするだけで、属性に応じてバディが集約されるので、バディを手作業で分類する負担から解放される。

前記ステップＳ１０８に先立ち、集約許可取得部１８は、プレゼンス情報を集約してもいいか否かの問い合わせを、サブスクライビー「Item10」に送信してもよい。この場合、応答に応じてステップＳ１０８以降の処理を行う。
（１−２）新規プレゼンティティ集約処理
図１８は、サーバＳが実行する新規プレゼンティティ集約処理の流れの一例を示すフローチャートである。この処理は、サーバの起動により開始される。この処理は集約済判断処理及び集約通知処理に大別される。

〔集約済判断処理：Ｓ２０１〜Ｓ２０４〕
集約済判断処理では、新たなプレゼンティティがプレゼンスシステムに登録される度に、そのプレゼンティティが有する属性に基づく集約が実行されているか否かを判断する。
ステップＳ２０１：集約部１７は、プレゼンス管理部１５を介し、任意のクライアントからの新規プレゼンティティの登録依頼を待機する。登録依頼が生じるとステップＳ２０２に移行する。今、管理者のクライアントから、新たなプレゼンティティＩＤ「Item10」と、そのプレゼンス情報「<商品>DVDRecorder</商品>輸送中」と、が登録された場合を考える。

ステップＳ２０２：プレゼンス管理部１５は、新たなプレゼンティティＩＤ「Item10」とそのプレゼンス情報とを、ウォッチャーリスト１２に登録する。
ステップＳ２０３：集約部１７は、新たなプレゼンティティのプレゼンス情報から、属性値、例えば「DVDRecorder」を抽出する。
ステップＳ２０４：集約部１７は、抽出した属性値「DVDRecorder」を、集約情報テーブル１３内で検索し、その属性値に基づく集約がすでに実行されているか否かを判断する。

集約部１７は、抽出した属性値「DVDRecorder」が集約情報テーブル１３になければ、ステップＳ２１０に移行し、サーバの電源がオフになるまでステップＳ２０１に戻って前述の処理を繰り返す。すなわち、新たなプレゼンティティの属性が未集約であれば、何も処理を行わない。
逆に、抽出した属性値「DVDRecorder」と一致する集約属性値が集約情報テーブル１３にあれば、集約部１７は、後述するステップＳ２０５に移行する。

〔集約通知処理：Ｓ２０５〜Ｓ２０９〕
集約通知処理では、新たなプレゼンティティが有する属性に基づく集約が実行されていない場合はなにもしない。実行されている場合は、他の集約対象プレゼンティティのプレゼンス情報と共に、そのプレゼンティティのプレゼンス情報が集約プレゼンス情報のウォッチャーに通知される。

ステップＳ２０５：集約部１７は、プレゼンス管理部１５に対し、サブスクライブを発行する。このサブスクライブには、サブスクライバーＩＤ「User1」及びサブスクライビーＩＤ「Item10」が含まれている。
このサブスクライブに応じ、プレゼンス管理部１５は、サブスクライバーＩＤ「User1」のバディＩＤにサブスクライビーＩＤ「Item10」を登録し、サブスクライビーＩＤ「Item10」のウォッチャーＩＤに「User1」を登録する。

ステップＳ２０６：集約部１７は、集約属性値「DVDRecorder」に対応する集約対象プレゼンティティＩＤに、新たなプレゼンティティＩＤ「Item10」を追加登録する。
ステップＳ２０７：集約部１７は、集約属性値「DVDRecorder」に対応づけられた既存の集約対象プレゼンティティＩＤを、集約情報テーブル１３から読み出す。また、集約属性値に対応する集約プレゼンティティＩＤ、例えば「User1＿DVDRecorder」を、集約情報テーブル１３から読み出す。

ステップＳ２０８：集約部１７は、集約プレゼンス情報を生成し、ウォッチャーリスト１２に登録する。生成される集約プレゼンス情報は、既存の集約対象プレゼンティティのプレゼンス情報と、新たに登録されたプレゼンティティ「Item10」のプレゼンス情報と、を含む。
ステップＳ２０９：プレゼンス通知部１６は、ウォッチャーリスト１２内でのプレゼンス情報の更新に応じ、集約プレゼンス情報を、そのウォッチャーに送信する。

ステップＳ２１０：集約部１７は、上記の処理を、サーバの電源がオフになるまで繰り返す。
以上の処理により、新たに登録されたプレゼンティティをバディとして登録しなくても、そのプレゼンティティのプレゼンス情報が集約され、通知される。
前記ステップＳ２０５に先立ち、集約許可取得部１８は、新規プレゼンティティのプレゼンス情報を集約しても良いか否かを、新規プレゼンティティに問い合わせてもよい。この場合、応答に応じてステップＳ２０５以降の処理を行う。

ここでは新規プレゼンティティの登録時を例に挙げているが、各プレゼンティティが複数のプレゼンス情報を有するプレゼンス管理システムでは、既存のプレゼンティティに新たなプレゼンス情報を追加する場合にも上記の処理を実行することができる。
（１−３）条件指定集約処理
図１９は、サーバＳが実行する条件指定集約処理の流れの一例を示すフローチャートである。この処理は、サーバの起動により開始される。この処理では、ユーザが指定した集約条件に従った集約が実行される。ここでは、前記図９の集約依頼画面により、クライアント「User1」が、属性値「DVDRecorder」と、最小集約数「３」と、を集約条件として指定した場合を考える。

ステップＳ３０１：集約部１７は、集約の指示の受信を待機し、集約指示を受信するとステップＳ３０２に移行する。
ステップＳ３０２：集約部１７は、受信した集約指示に含まれる集約属性値、例えば「DVDRecorder」を抽出し、抽出した集約属性値「DVDRecorder」を、集約情報テーブル１３内で検索する。集約部１７は、抽出した集約属性値「DVDRecorder」が集約情報テーブル１３になければ、ステップＳ３０３に移行する。集約属性値「DVDRecorder」が集約情報テーブル１３にあれば、ステップＳ３０８に移行し、サーバの電源がオフにならない限り、ステップＳ３０１に戻って新たな集約指示の受信を待機する。

ステップＳ３０３：集約部１７は、指定された新たな集約属性値「DVDRecorder」に応じ、新たな集約プレゼンティティＩＤ、例えば「User1＿DVDRecorder」を生成する。また、集約部１７は、集約対象プレゼンティティＩＤを特定する。この特定は、集約依頼元「User1」のバディの中から属性値「DVDRecorder」を持つバディを検索することにより行う。

ステップＳ３０４： 集約部１７は、ウォッチャーリスト１２への登録依頼をプレゼンス管理部１５に渡す。この登録依頼は、サブスクライビーＩＤ「User1＿DVDRecorder」と、ウォッチャーＩＤ「User1」と、を含む。この登録依頼により、ウォッチャーリスト１２に新たなエントリが追加される。この例では、新たなエントリに、サブスクライビーＩＤ「User1＿DVDRecorder」及びウォッチャーＩＤ「User1」が、それぞれ書き込まれる。

ステップＳ３０５：集約部１７は、「集約情報テーブル１３」に新たなエントリを生成し、サブスクライバーＩＤ、集約属性、集約プレゼンティティＩＤ及び集約対象プレゼンティティＩＤを、書き込む。この例では、サブスクライバーＩＤ「User1」、集約属性「DVDRecorder」、集約プレゼンティティＩＤ「User1＿DVDRecorder」、集約対象プレゼンティティＩＤ「Item1」、「Item2」、「Item10」が、それぞれ書き込まれる。

ステップＳ３０６：集約部１７は、新たに生成した集約プレゼンティティＩＤに対応する集約プレゼンス情報を生成し、ウォッチャーリスト１２に登録する。集約プレゼンス情報は、全集約対象プレゼンティティのプレゼンス情報を含む。
ステップＳ３０７：ウォッチャーリスト１２のプレゼンス情報が更新されると、プレゼンス通知部１６は、集約プレゼンス情報を、そのウォッチャーに送信する。この例では、集約プレゼンティティＩＤ「User1＿DVDRecorder」のプレゼンス情報が、集約依頼元「User1」に送信される。

ステップＳ３０８：上記Ｓ３０１〜Ｓ３０７の処理は、サーバの電源がオフになるまで繰り返される。
以上の処理により、ユーザが指定した集約条件に基づいて集約を実行することができる。ユーザは、属性値を指定するだけでバディを分類することができるので、バディを手作業で分類する負担から解放される上、自分にとって必要な属性値を指定できる利点がある。

なお、本実施形態例では、集約部１７が集約情報テーブル１３を検索することで、指定された集約属性値を属性値とするプレゼンス情報が集約されているかどうかを判断している。しかし、クライアント側で集約済みの集約属性値を管理しておくこともできる。こうすれば、集約済みの集約属性値が指定された場合、エラー画面を表示したり、サーバに無駄な集約指示を送信することを防止することができる。

（２）集約解除
図２０は、サーバＳが実行する条件指定集約解除処理の流れの一例を示すフローチャートである。この処理は、サーバの起動により開始される。この処理では、ユーザが指定した集約対象の集約が解除される。ここでは、前記図１０の集約解除依頼画面により、クライアント「User1」が、属性値「DVDRecorder」を指定した場合を考える。

ステップＳ４０１：解除部１１０は、集約解除依頼の受信を待機し、受信するとステップＳ４０２に移行する。
ステップＳ４０２：解除部１１０は、集約解除依頼に含まれる集約属性値、例えば「DVDRecorder」を抽出し、抽出した集約属性値を集約情報テーブル１３内で検索する。集約属性値「DVDRecorder」が集約情報テーブル１３内にあれば、ステップＳ４０３に移行する。なければ、後述するステップＳ４０５に移行する。

ステップＳ４０３：解除部１１０は、サブスクライバーＩＤが解除依頼元ＩＤ「User1」と一致し、かつ集約属性値が「DVDRecorder」であるエントリの集約プレゼンティティＩＤ、例えば「User1＿DVDRecorder」を特定する。その後、そのエントリを、集約情報テーブル１３から削除する。
ステップＳ４０４：解除部１１０は、ウォッチャーＩＤが解除依頼元ＩＤ「User1」と一致し、かつサブスクライビーＩＤが削除された集約プレゼンティティＩＤ「User1＿DVDRecorder」と一致するエントリを、ウォッチャーリスト１２から削除する。

ステップＳ４０５：上記Ｓ４０１〜Ｓ４０４の処理は、サーバの電源がオフになるまで繰り返される。
以上の処理により、ユーザにより指定された集約プレゼンス情報の集約が解除される。
＜第２実施形態＞
〔構成〕
第２実施形態のプレゼンスシステムは、前記第１実施形態と同様の構成を有する。ただし、プレゼンス情報は、属性として「位置」に関する値を含む。また、このプレゼンスシステムは、プレゼンス情報の集約や解除を、プレゼンス情報の変化時に行う。そのため、集約部１７及び解除部１１０は、以下の機能をさらに有している。以下では、説明を容易にするため、集約条件として集約プレゼンス情報の最小集約数が“３”の場合を考える。

集約部１７は、プレゼンス情報が更新されると、集約を実行するか否かを判断し、判断結果に応じて集約を実行する。集約を実行するか否かは、最小集約数が満たされたか否かにより判断される。集約実行に先立ち、集約部１７は、生成しようとしている集約プレゼンス情報のウォッチャーとなるクライアントＣに対し、問い合わせを送信してもよい。
また、集約部１７は、集約対象プレゼンス情報のいずれかが更新されると、集約プレゼンス情報を更新し、更新した集約プレゼンス情報をウォッチャーリスト１２に書き込む。これにより、集約プレゼンス情報の最新の値がウォッチャーリスト１２に保持されるので、集約プレゼンス情報のウォッチャーはいつでも最新の集約プレゼンス情報を参照することができる。

解除部１１０は、プレゼンス情報が更新されると、最小集約数が満たされなくなった集約プレゼンス情報があるか否かを判断する。具体的には、解除部１１０は、更新前のプレゼンス情報の属性値に基づいて、集約情報テーブル１３を検索する。検索の結果、プレゼンス情報の更新後は集約対象プレゼンティティＩＤの数が最小集約数未満となる場合、解除部１１０は該当エントリを集約情報テーブル１３から削除する。解除部１１０は、削除に先立ち、集約プレゼンス情報のウォッチャーに問い合わせを送信してもよい。

図２１及び図２２は、本実施形態におけるバディリスト１１、ウォッチャーリスト１２及び集約情報テーブル１３の一例を示す説明図である。この例では、クライアント「Worker4」の属性「位置」の値は、「Ｅ市Ｆ町」から「Ａ市Ｂ区」に変化し、属性値「Ａ市Ｂ区」に基づく集約が実行される。図２１は変化前を、図２２は変化後の状態を示す。この変化により、位置「Ａ市Ｂ区」を有するプレゼンティティの数が「２」から「３」になり、属性値「Ａ市Ｂ区」に基づく集約条件が満たされる（図２１（ｂ）、図２２（ｂ）のウォッチャーリスト１２参照）。図２２（ｃ）は、集約属性値「Ａ市Ｂ区」を有する集約プレゼンティティＩＤ「Manager1＿AB」のエントリが生成された状態の集約情報テーブル１３である。同様に、プレゼンス情報の変化によりいずれかのエントリの集約プレゼンティティ数が最小集約数を満たさなくなった場合、そのエントリはウォッチャーリスト１２及び集約情報テーブル１３から削除される。

〔プレゼンス変化集約処理〕
図２３は、サーバＳが行うプレゼンス変化集約処理の流れの一例を示すフローチャートである。この処理では、プレゼンス情報が変化したときに集約が実行される。この処理は、サーバの起動により開始される。今、説明を容易にするために、クライアント「Worker4」から新たなプレゼンス情報「<位置>Ａ市Ｂ区</位置>移動中」を受信したとする（前記図２２参照）。

ステップＳ５０１：プレゼンス管理部１５は、任意のクライアントからのプレゼンス情報の更新依頼を待機する。この例では、クライアント「Worker4」からの更新依頼が生じるとステップＳ５０２に移行する。
ステップＳ５０２：プレゼンス管理部１５は、ウォッチャーリスト１２を更新する。この例では、ウォッチャーリスト１２のサブスクライビーＩＤ「Worker4」に対応するプレゼンス情報を、「<位置>Ａ市Ｂ区</位置>移動中」に更新する。またプレゼンス管理部１５は、クライアントＩＤ「Worker4」及び新たなプレゼンス情報の値を集約部１７に渡す。

ステップＳ５０３：集約部１７は、新たなプレゼンス情報「<位置>Ａ市Ｂ区</位置>移動中」から属性値を抽出する。この例では、属性値「Ａ市Ｂ区」を抽出する。
ステップＳ５０４：集約部１７は、抽出した属性値「Ａ市Ｂ区」を、集約情報テーブル１３内で検索する。集約部１７は、抽出した属性値「Ａ市Ｂ区」が集約情報テーブル１３になければ、後述するステップＳ５０７に移行し、集約を実行する（Ｓ５０７〜Ｓ５１３）。すなわち、プレゼンス情報の変化により新たに満たされた集約条件に従い、新たな集約プレゼンス情報を生成する。逆に、抽出した属性値「Ａ市Ｂ区」が集約情報テーブル１３にあれば、対応する集約プレゼンティティＩＤ、例えば「Manager1＿AB」を抽出し、ステップＳ５０５に移行する。すなわち、属性値「Ａ市Ｂ区」に基づく集約が実行されていれば、集約プレゼンティティＩＤを抽出してステップＳ５０５に移行する。

ステップＳ５０５： 集約部１７は、抽出した集約プレゼンティティＩＤ、例えば「Manager1＿AB」に基づいてウォッチャーリスト１２を更新する。具体的には、集約部１７は、集約プレゼンティティＩＤ「Manager1＿AB」の集約対象プレゼンティティＩＤを読み出す。さらに集約部１７は、集約対象プレゼンティティのプレゼンス情報をウォッチャーリスト１２から読み出す。集約部１７は、読み出したプレゼンス情報を含む集約プレゼンス情報を生成し、ウォッチャーリスト１２に書き込む。これにより、集約プレゼンス情報が更新される。

ステップＳ５０６：プレゼンス通知部１６は、ウォッチャーリスト１２に書き込まれた集約プレゼンス情報を、そのウォッチャーに送信する。
ステップＳ５０７〜Ｓ５０９：更新されたプレゼンス情報の属性値「Ａ市Ｂ区」が集約情報テーブル１３にないと判断した場合（ステップＳ５０４）、集約部１７は、ウォッチャーリスト１２を参照し、同一ウォッチャーＩＤに対応づけられたプレゼンス情報のうち、属性値「Ａ市Ｂ区」を有するプレゼンス情報が、３つ以上になったか否かを判断する。３つ以上、すなわち集約条件を満たしていると判断すると、ステップＳ５１０に移行する。集約条件を満たしていない場合、後述するステップＳ５１４に移行し、通常のプレゼンス情報の通知を行う。

ステップＳ５１０：集約部１７は、新たな集約プレゼンティティＩＤ、例えば「Manager１＿AB」を生成する。また、集約部１７は、集約対象プレゼンティティＩＤ及びサブスクライバーＩＤを、ウォッチャーリスト１２を参照して決定する。具体的には、サブスクライビーＩＤ「Worker4」に対応づけられたウォッチャーＩＤ、例えば「Manager1」を、サブスクライバーＩＤとする。また、ウォッチャーＩＤ「Manager1」に対応づけられたプレゼンス情報のうち、属性値「Ａ市Ｂ区」を有するプレゼンス情報に対応づけられたサブスクライビーＩＤを、集約対象プレゼンティティＩＤとする。

ステップＳ５１１：集約部１７は、ウォッチャーリスト１２に新たなエントリを追加する。新たなエントリには、生成した集約対象プレゼンティティＩＤ「Manager1＿AB」がサブスクライビーＩＤとして、集約プレゼンス情報のサブスクライバーＩＤ「Manager1」がウォッチャーＩＤとして、それぞれ書き込まれる。
ステップＳ５１２：集約部１７は、集約情報テーブル１３に新たなエントリを生成し、ステップＳ５１０で決定したサブスクライバーＩＤ、集約プレゼンティティＩＤ及び集約対象プレゼンティティＩＤを、書き込む。また、集約属性値としては、更新されたプレゼンス情報の属性値、この例では「Ａ市Ｂ町」を書き込む。

ステップＳ５１３：集約部１７は、生成した集約対象プレゼンティティＩＤに対応するプレゼンス情報をウォッチャーリスト１２から読み出し、全てのプレゼンス情報を含む集約プレゼンス情報を生成する。生成された集約プレゼンス情報は、集約プレゼンティティＩＤ「Manager1＿AB」のプレゼンス情報として、ウォッチャーリスト１２に書き込まれる。

ステップＳ５０６：ウォッチャーリスト１２のプレゼンス情報が更新されると、プレゼンス通知部１６は、更新されたプレゼンス情報をそのウォッチャーに送信する。具体的には、プレゼンス通知部１６は、更新されたプレゼンス情報、この場合は書き込まれた集約プレゼンス情報のウォッチャー「Manager1」に、生成した集約プレゼンス情報を送信する。

ステップＳ５１４：プレゼンス通知部１６は、クライアント「Worker4」の更新されたプレゼンス情報を、そのウォッチャー「Manager1」に通知する。
ステップＳ５１５：上記Ｓ５０１〜Ｓ５１４の処理は、サーバの電源がオフになるまで繰り返される。
以上の処理により、プレゼンス情報が更新されるのを契機として、集約条件を満足するようになった新たな集約プレゼンス情報が生成・通知される。従って、プレゼンス情報が動的に変化する場合であっても、ウォッチャーは変化に応じて逐一集約し直す負担から解放される。また、ウォッチャーは、その変化を属性単位で監視することができる利点がある。

前記ステップＳ５１０に先立ち、新たに生成しようとしている集約プレゼンス情報のウォッチャーに対し、集約の是非を問い合わせ、応答に応じてステップＳ５１０以下の処理を行ってもよい。ウォッチャーは、集約前に集約が実行されようとしていることを知ることができる利点がある。
〔プレゼンス変化集約解除処理〕
図２４は、サーバＳが行うプレゼンス変化集約解除処理の流れの一例を示すフローチャートである。この処理では、プレゼンス情報が変化したときに集約解除が実行される。この処理は、サーバの起動により開始される。この処理では、プレゼンス情報の変化により集約が解除される。ここでは、クライアント「Worker4」のプレゼンス情報が、「<位置>Ａ市Ｂ区</位置>移動中」（図２２（ｂ）参照）から「<位置>Ｃ市Ｄ町</位置>移動中」（図２１（ｂ）参照）に変化した場合を考える。

ステップＳ６０１：プレゼンス管理部１５は、任意のクライアントからのプレゼンス情報の更新依頼を待機する。この例では、クライアント「Worker4」からの更新依頼が生じるとステップＳ６０２に移行する。
ステップＳ６０２：プレゼンス管理部１５は、ウォッチャーリスト１２を更新する。この例では、ウォッチャーリスト１２のサブスクライビーＩＤ「Worker4」に対応するプレゼンス情報を、「<位置>Ｃ市Ｄ町</位置>移動中」に更新する。またプレゼンス管理部１５は、クライアントＩＤ「Worker4」、更新前のプレゼンス情報の値「<位置>Ａ市Ｂ区</位置>移動中」及び更新後のプレゼンス情報の値「<位置>C市D町</位置>移動中」を、解除部１１０に渡す。

ステップＳ６０３：解除部１１０は、更新前のプレゼンス情報「<位置>Ａ市Ｂ区</位置>移動中」から属性値を抽出する。この例では、属性値「Ａ市Ｂ区」を抽出する。
ステップＳ６０４：解除部１１０は、抽出した属性値「Ａ市Ｂ区」を、集約情報テーブル１３内で検索する。解除部１１０は、抽出した属性値「Ａ市Ｂ区」が集約情報テーブル１３になければ、後述するステップＳ６１２に移行する。すなわち、古いプレゼンス情報は集約対象プレゼンス情報ではないので、集約を解除する必要がないためステップＳ６１２に移行する。逆に、抽出した属性値「Ａ市Ｂ区」が集約情報テーブル１３にあれば、ステップ６０５に移行する。

ステップ６０５：解除部１１０は、更新後のプレゼンス情報「<位置>C市D町</位置>移動中」から属性値を抽出する。この例では、属性値「Ｃ市Ｄ町」を抽出する。
ステップ６０６：解除部１１０は、更新前のプレゼンス情報と更新後のプレゼンス情報とで、属性値が一致しているか否かを判断する。すなわち、解除部１１０は、プレゼンス情報の更新により、属性値が変化したか否かを判断する。一致していれば、ステップＳ６１１に移行する。一致していなければ、ステップ６０７に移行する。

ステップ６０７：解除部１１０は、集約対象プレゼンティティＩＤ「Worker4」に対応する集約プレゼンティティＩＤ、例えば「Manager1＿AB」を抽出し、ステップＳ６０８に移行する。すなわち、更新前のプレゼンス情報の属性値「Ａ市Ｂ区」に基づく集約が実行されていれば、その集約プレゼンティティＩＤを抽出してステップＳ６０８に移行する。
ステップＳ６０８：解除部１１０は、集約情報テーブル１３を参照し、集約プレゼンティティＩＤ「Manager1＿AB」に対応づけられた集約対象プレゼンティティＩＤから、「Worker4」を削除する。すなわち、クライアント「Worker4」を、旧属性値「Ａ市Ｂ区」の集約対象プレゼンティティからはずす。

ステップＳ６０９：解除部１１０は、集約属性値「Ａ市Ｂ区」の集約対象プレゼンティティＩＤの数が、最小集約数を満たしているか否かを判断する。満たしていれば、後述するステップＳ６１１に移行する。満たしていない場合、ステップＳ６１０に移行する。
ステップＳ６１０：解除部１１０は、集約情報テーブル１３から、集約属性値「Ａ市Ｂ区」を含むエントリを削除する。

ステップＳ６１１：集約部１７は、更新前のプレゼンス情報が有していた古い集約属性値「Ａ市Ｂ区」に対応付けられた集約対象プレゼンティティＩＤが最小集約数以上ある場合、その集約プレゼンス情報を更新する。集約対象プレゼンティティが減少したため、集約プレゼンス情報を更新すべきだからである。プレゼンス通知部１６は、更新された集約プレゼンス情報を、そのウォッチャーに通知する。

ステップＳ６１２：プレゼンス通知部１６は、クライアント「Worker4」の更新されたプレゼンス情報を、そのウォッチャー「manager1」に通知する。
ステップＳ６１３：上記Ｓ６０１〜Ｓ６１２の処理は、サーバの電源がオフになるまで繰り返される。
以上の処理により、プレゼンス情報の更新により最小集約数を満たさなくなった集約を自動的に解除し、ウォッチャーによる解除の負担を軽減することができる。

前記ステップＳ６１０に先立ち、集約プレゼンス情報のウォッチャーに、集約解除の是非を問い合わせ、応答に応じて集約情報テーブル１３のエントリを削除してもよい。ウォッチャーは、集約が解除されるのを前もって確認することができる。
〔本発明の効果〕
本発明を用いれば、複数のプレゼンス情報を属性毎に集約して一括通知するので、ウォッチャーはプレゼンス情報の属性毎にプレゼンス情報の更新通知を受けることができる。そのため、ウォッチャーが受信したプレゼンス情報を分類する負担が軽減される。

また、新規に登録されたプレゼンス情報が自動的に集約対象に追加されるため、ウォッチャーは全てのプレゼンス情報に対して一つ一つサブスクライブせずにすみ、サブスクライブの負担が軽減される。
さらに、集約対象となったプレゼンス情報だけでなく、集約されたプレゼンス情報についても、最新の値をプレゼンス管理装置に保持している。そのため、ウォッチャーは、集約されたプレゼンス情報を保存しなくても、集約されたプレゼンス情報をいつでも参照することができる。

＜その他の実施形態＞
前述した方法をコンピュータに実行させるコンピュータプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで、コンピュータ読み取り可能な記録媒体としては、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕｅ−ｒａｙ Ｄｉｓｃ）、半導体メモリを挙げることができる。

前記コンピュータプログラムは、前記記録媒体に記録されたものに限られず、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送されるものであってもよい。
＜付記＞
（付記１）
複数のクライアントと接続されるプレゼンス管理装置が実行するプレゼンス管理方法であって、
属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理ステップと、
前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理ステップと、
同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約ステップと、
前記集約ステップで生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知ステップと、
を含むプレゼンス管理方法。

このプレゼンス管理方法は、サーバとクライアントとを含むプレゼンスシステムにおいて、サーバにより実行される。クライアントには、プレゼンス提供装置やプレゼンス情報の通知先が含まれる。属性値とは、プレゼンス情報の一部分の値である。具体的には所定のタグ、例えば商品名や場所の名前を挙げることができ、特に限定されない。
このプレゼンス管理方法は、次のように作用する。例えば、属性が商品名であり、商品Ａ，Ｂ，Ｃが同一の属性値「DVDRecorder」を有するとする。サーバは、商品Ａ，Ｂ，Ｃ(提供元に相当)のプレゼンス情報を含む集約プレゼンス情報を生成し、商品Ａ，Ｂ，Ｃのプレゼンス情報のウォッチャー（通知先に相当）Wに対し、これを通知する。ウォッチャーＷは、商品名毎にプレゼンス情報をまとめて受信するので、商品名毎にプレゼンス情報を分類する負担から解放される。

（付記２）
前記通知先管理ステップは、前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、そのプレゼンス情報の通知先クライアントと、の新たな対応付けの登録を受け付け、受け付けた対応付けを、前記通知先管理テーブルにさらに記憶し、
前記集約ステップは、
前記新たな対応付けにおける提供元クライアントのプレゼンス情報に含まれる属性値を抽出し、
前記新たな対応付けにおける通知先クライアントと対応づけられている既存の提供元クライアントであって、前記抽出した属性値をそのプレゼンス情報に含む既存の提供元クライアントを、前記通知先管理テーブルから検索し、
検索した既存の提供元クライアントのプレゼンス情報と、前記新たな提供元クライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
前記集約通知ステップは、前記集約プレゼンス情報を、前記新たな通知先クライアントに通知する、付記1に記載のプレゼンス管理方法。

新たにサブスクライブが発生する度に、新たなバディと同一の属性値を有するプレゼンス情報を持つ既存のバディを新たなバディと共に集約する。この集約は、ウォッチャー毎に実行される。これにより、バディ一人一人を分類する負担からウォッチャーを解放することができる。
（付記３）
前記管理ステップは、新たなクライアント及びそのプレゼンス情報の登録を受け付け、
前記集約ステップは、
前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、付記1に記載のプレゼンス管理方法。

新たなプレゼンティティとそのプレゼンス情報Ｐ１が登録されたとき、そのプレゼンス情報と同じ属性値を有するプレゼンス情報Ｐ２，Ｐ３・・・を、新たなプレゼンス情報Ｐ１と共に集約する。集約プレゼンス情報は、既存のプレゼンス情報Ｐ２，Ｐ３・・・の通知先に通知される。言い換えれば、既存のプレゼンス情報Ｐ２，Ｐ３・・・のウォッチャーは、新たなプレゼンティティのプレゼンス情報Ｐ１をサブスクライブしなくても、すでに登録されているバディのプレゼンス情報Ｐ２，Ｐ３・・・と共に、集約プレゼンス情報の一部として新たなプレゼンス情報Ｐ１を参照することができる。従って、新たなプレゼンティティが次々に登録される場合には、ウォッチャーが一つ一つバディを登録する負担から解放される。

（付記４）
前記集約ステップは、
任意のクライアントから属性値を含む集約条件の指定を受け付け、
前記通知先管理テーブルにおいて前記指定元クライアントを通知先とするプレゼンス情報のうち、前記指定された属性値を有するプレゼンス情報の提供元クライアントを特定し、
前記特定した提供元クライアントのプレゼンス情報を含む集約プレゼンス情報を生成し、
前記集約通知ステップは、前記生成した集約プレゼンス情報を、前記集約条件の指定元クライアントに通知する、
付記1に記載のプレゼンス管理方法。

ウォッチャーから少なくとも属性値の指定を受け付け、そのウォッチャーのバディのプレゼンス情報のうち、その属性値を含むプレゼンス情報を集約する。これにより、ウォッチャーは、自分の好みの分類基準に基づいて、容易にバディを分類することができる。
（付記５）
前記管理ステップは、任意のクライアントからプレゼンス情報の更新を受け付け、
前記集約ステップは、
更新されたプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアントを特定し、
前記特定された提供元クライアントに対し、前記通知先管理テーブルで対応づけられている通知先クライアントを特定し、
前記特定された提供元クライアントのプレゼンス情報と、前記更新されたプレゼンス情報と、を含む集約プレゼンス情報を生成し、
前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、付記1に記載のプレゼンス管理方法。

プレゼンス情報が更新され、集約プレゼンス情報が動的に変化しても、最新の集約プレゼンス情報が通知先に通知される。従って、プレゼンス情報が動的に変化する場合であっても、ウォッチャーはその変化を属性単位で監視することができる。
（付記６）
前記集約ステップは、前記同一の属性値と、前記同一の属性値を有するプレゼンス情報である集約対象プレゼンス情報の提供元クライアントと、前記集約対象プレゼンス情報に基づいて生成される集約プレゼンス情報の識別子と、前記集約プレゼンス情報の通知先クライアントと、を対応づける集約情報テーブルを記憶し、
前記管理ステップは、前記集約ステップで生成された集約プレゼンス情報と、前記集約プレゼンス情報の識別子と、を対応付けて管理する、
付記1に記載のプレゼンス管理方法。

集約プレゼンス情報と、その通知先と、をサーバ側で記憶しておくので、クライアント側で集約プレゼンスを保存したり管理したりする必要がない。そのため、大量のクライアントから提供されるプレゼンス情報を参照するウォッチャーの負担が軽減される。なお、集約情報テーブルには、必ずしも集約プレゼンス情報そのものを記憶する必要はない。例えば、集約のキーとなる属性値、その属性値を有するプレゼンス情報の提供元、集約プレゼンス情報の識別子などを、通知先と対応づけて記憶する形態が挙げられる。

（付記７）
前記集約情報テーブルに記憶されているいずれかの属性値の指定を任意のクライアントから受け付け、前記クライアントを通知先クライアントとする集約プレゼンス情報のうち、指定された属性値を有する集約プレゼンス情報のエントリを、前記集約情報テーブルから削除する解除ステップをさらに含む、付記６に記載のプレゼンス管理方法。

ウォッチャーは、属性単位で集約されているプレゼンス情報を、属性単位で解除することができるので、利便性が増す。
（付記８）
前記集約ステップは、
前記管理ステップが管理する任意のプレゼンス情報の属性値が変化した場合、前記集約情報テーブルを更新し、
前記プレゼンス情報の変化前の属性値と同一の属性値を有するプレゼンス情報の提供元クライアントの数が所定値未満になったか否かを判断し、
前記提供元クライアントの数が所定値未満になったと判断した場合、前記集約情報テーブルにおいて前記属性値に対応付けられたエントリを削除する、
付記６に記載のプレゼンス管理方法。

プレゼンス情報の変化により、同一属性を有するプレゼンス情報があまりにも少なくなった場合、集約する意味に乏しくなるので集約を解除してもよい。その場合、集約プレゼンス情報の通知先に確認することが好ましい場合がある。プレゼンス情報の性質によっては、集約プレゼンス情報のウォッチャーが知らない間に集約が解除されることが好ましくない場合がある。

（付記９）
前記集約プレゼンス情報を生成するに先立ち、前記同一の属性値を有するプレゼンス情報の提供元クライアントに対し、集約の是非の問い合わせを送信し、問い合わせに対する応答を取得する集約許可取得ステップをさらに含み、
前記集約ステップは、前記集約許可取得ステップにおいて取得する応答に応じ、集約プレゼンス情報を生成する、
付記１に記載のプレゼンス管理方法。

プレゼンティティから見れば、知らないうちに同じ属性を有する他のプレゼンティティのプレゼンス情報と共に、自分のプレゼンス情報が第３者に提供されてしまうおそれがある。そのため、集約に先立ち、集約されるプレゼンス情報の提供元に対して問い合わせを行うことで、提供元のプライバシーを保護することができる。
問い合わせは、集約毎に行うことができる。また、集約許可ルールを問い合わせ、応答に基づいて集約許可ルールを決定し、決定した集約許可ルールに基づいて集約を実行するか否かを決定しても良い。

（付記１０）
前記集約プレゼンス情報を生成するに先立ち、前記集約プレゼンス情報の通知先クライアントに対し、集約の是非の問い合わせを送信し、問い合わせに対する応答を取得する集約許可取得ステップをさらに含み、
前記集約ステップは、前記集約許可取得ステップにおいて取得する応答に応じ、集約プレゼンス情報を生成する、
付記１に記載のプレゼンス管理方法。

ウォッチャーから見れば、集約するか否かを集約前に問い合わせてもらうことにより、集約の要否を判断することができる。問い合わせは、集約毎に行うことができる。また、集約許可ルールを問い合わせ、応答に基づいて集約許可ルールを決定し、決定した集約許可ルールに基づいて集約を実行するか否かを決定しても良い。
（付記１１）
集約プレゼンス情報の通知条件を定義する通知ルールを記憶する通知ルール記憶ステップをさらに含み、
前記集約ステップは、前記通知ルールに基づいて、集約プレゼンス情報を生成するか否かを判断する、
付記１に記載のプレゼンス管理方法。

所定の通知ルールは、集約プレゼンス情報の通知条件、例えば集約プレゼンス情報の生成条件、通知に用いる通信サービスや通知タイミングを定義する。例えば、生成条件を規定する通知ルールとしては、「「所定時間毎」や「集約対象プレゼンスが５個変化する毎」に集約プレゼンス情報を生成する」が挙げられる。通知ルールは、サーバが予め記憶していても良い。また、ウォッチャーから通知ルールの指定を受け付け、指定された通知ルールを記憶しても良い。

（付記１２）
集約プレゼンス情報の通知条件を定義する通知ルールを記憶する通知ルール記憶ステップをさらに含み、
前記集約ステップは、前記通知ルールに基づいて、集約プレゼンス情報を生成するか否かを判断し、
前記集約通知ステップは、前記通知ルールに基づいて、集約プレゼンス情報を送信するか否かを判断する、付記１に記載のプレゼンス管理方法。

本発明では、通知ルールに基づいて、集約プレゼンス情報の生成条件及び通知タイミングを制御する。通知タイミングを規定する通知ルールとしては、例えば、「所定時間毎に集約プレゼンス情報を通知する」、「集約プレゼンス情報を生成する毎に、生成された集約プレゼンス情報を通知する」が挙げられる。集約されるプレゼンス情報が大量にある場合、個々のプレゼンス情報が変化するたびに集約プレゼンス情報が通知されると、通知頻度が高くなりすぎるおそれがある。そのため、適度な間隔で集約プレゼンス情報が通知されるよう、通知タイミングを設定することが好ましい。これにより、ウォッチャーの監視負担を軽減し、ネットワーク負荷を軽くすることができる。

（付記１３）
集約プレゼンス情報の通知条件を定義する通知ルールを記憶する通知ルール記憶ステップをさらに含み、
前記集約通知ステップは、前記通知ルールに基づいて、集約プレゼンス情報を送信するか否かを判断する、請求項１に記載のプレゼンス管理方法。

本発明では、通知ルールに基づいて、集約プレゼンス情報の送信タイミングを制御する。
（付記１４）
複数のクライアントと接続されるプレゼンス管理装置であって、
属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段と、
前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段と、
同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段と、
前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段と、
を含むプレゼンス管理装置。

本発明のプレゼンス管理装置は、発明１のプレゼンス管理方法を実行する。
（付記１５）
複数のクライアントと接続されるコンピュータが実行するプレゼンス管理プログラムであって、
属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段、
前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段、
同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段、及び
前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段、
として前記コンピュータを機能させるプレゼンス管理プログラム。

本発明のプログラムは、本発明１に記載の方法をコンピュータに実行させる。
（付記１６）
複数のクライアントと接続されるプレゼンス管理装置としてコンピュータを機能させるプレゼンス管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段、
前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段、
同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段、及び
前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段、
として前記コンピュータを機能させるプレゼンス管理プログラムを記録したコンピュータ読み取り可能な記録媒体。

本発明は、前記発明１５と同様の作用効果を奏する。
（付記１７）
複数のプレゼンス提供装置のプレゼンス情報を管理及び配信するプレゼンス管理装置と接続されるプレゼンス参照装置であって、
属性値を含む前記プレゼンス情報を前記プレゼンス管理装置から受信する受信手段と、
前記受信したプレゼンス情報を、前記属性値に応じて分類表示する表示手段と、
を備えるプレゼンス参照装置。

このプレゼンス参照装置は、前記発明1のクライアントの一形態である。このプレゼンス参照装置は、プレゼンス情報と、集約プレゼンス情報と、を区別可能に表示する。
（付記１８）
複数のプレゼンス提供装置のプレゼンス情報を管理及び配信するプレゼンス管理装置と接続されるコンピュータが実行するプレゼンス参照プログラムであって、
属性値を含む前記プレゼンス情報を前記プレゼンス管理装置から受信する受信手段、及び
前記受信したプレゼンス情報を、前記属性値に応じて分類表示する表示手段、
として前記コンピュータを機能させるプレゼンス参照プログラム。

本発明のプログラムは、コンピュータを前記発明１７のプレゼンス参照装置として機能させる。
（付記１９）
複数のプレゼンス提供装置のプレゼンス情報を管理及び配信するプレゼンス管理装置と接続されるコンピュータが実行するプレゼンス参照プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
属性値を含む前記プレゼンス情報を前記プレゼンス管理装置から受信する受信手段、及び
前記受信したプレゼンス情報を、前記属性値に応じて分類表示する表示手段、
として前記コンピュータを機能させるプレゼンス参照プログラムを記録したコンピュータ読み取り可能な記録媒体。

本発明は、前記第１８発明と同様の作用効果を有する。

本発明は、物流システム、在庫管理システム、アドホックネットワークを用いたセンサシステムなど、人や物のプレゼンス情報が発生するあらゆるシステムやユビキタス社会に適用可能である。

第１実施形態に係るプレゼンスシステムの構成を示す説明図 （ａ）図１のサーバＳの機能構成を示すブロック図（ｂ）図１のクライアントＣの機能構成を示すブロック図 バディリストの一例を示す説明図 ウォッチャーリストの一例を示す説明図 集約情報テーブルの一例を示す説明図 メニュー画面の一例を示す説明図 サブスクライブ画面の一例を示す説明図 新規プレゼンティティ登録画面の一例を示す説明図 集約依頼画面の一例を示す説明図 集約解除依頼画面の一例を示す説明図 ＸＭＬで記述した集約ルールの一例を示す説明図 XMLで記述された集約許可ルールの一例を示す説明図 通知ルール指定画面の一例を示す説明図 ＸＭＬで記述された通知ルール（通信サービス）の一例を示す説明図 ＸＭＬで記述された通知ルール（通知タイミング）の別の一例を示す説明図 ＸＭＬで記述されたプレゼンス集約解除ルールの一例を示す説明図 サーバＳが実行するサブスクライブ集約処理の流れの一例を示すフローチャート サーバＳが実行する新規プレゼンティティ集約処理の流れの一例を示すフローチャート サーバＳが実行する条件指定集約処理の流れの一例を示すフローチャート サーバＳが実行する条件指定集約解除処理の流れの一例を示すフローチャート （ａ）第２実施形態におけるバディリストの一例を示す説明図（プレゼンス情報変化前）（ｂ）第２実施形態におけるウォッチャーリストの一例を示す説明図（プレゼンス情報変化前）（ｃ）第２実施形態における集約情報テーブルの一例を示す説明図（プレゼンス情報変化前） （ａ）第２実施形態におけるバディリストの一例を示す説明図（プレゼンス情報変化後）（ｂ）第２実施形態におけるウォッチャーリストの一例を示す説明図（プレゼンス情報変化後）（ｃ）第２実施形態における集約情報テーブルの一例を示す説明図（プレゼンス情報変化後） サーバＳが行うプレゼンス変化集約処理の流れの一例を示すフローチャート サーバＳが行うプレゼンス変化集約解除処理の流れの一例を示すフローチャート

符号の説明

Ｓ：サーバ
Ｃ：クライアント

Claims (9)

1. 複数のクライアントと接続され、管理手段と通知先管理手段と集約手段と集約通知手段とを有するプレゼンス管理装置が実行するプレゼンス管理方法であって、
   属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する、前記管理手段により実行される管理ステップと、
   前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する、前記通知先管理手段により実行される通知先管理ステップと、
   同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する、前記集約手段により実行される集約ステップと、
   前記集約ステップで生成された集約プレゼンス情報を、前記通知先クライアントに通知する、前記集約通知手段により実行される集約通知ステップと、を含み、
   前記管理ステップは、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
   前記集約ステップは、
   前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
   実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
   前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
   前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、
   プレゼンス管理方法。
2. 前記通知先管理ステップは、前記管理ステップで管理されているプレゼンス情報の提供元クライアントと、そのプレゼンス情報の通知先クライアントと、の新たな対応付けの登録を受け付け、受け付けた対応付けを、前記通知先管理テーブルにさらに記憶し、
   前記集約ステップは、
   前記新たな対応付けにおける提供元クライアントのプレゼンス情報に含まれる属性値を抽出し、
   前記新たな対応付けにおける通知先クライアントと対応づけられている既存の提供元クライアントであって、前記抽出した属性値をそのプレゼンス情報に含む既存の提供元クライアントを、前記通知先管理テーブルから検索し、
   検索した既存の提供元クライアントのプレゼンス情報と、前記新たな提供元クライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
   前記集約通知ステップは、前記集約プレゼンス情報を、前記新たな通知先クライアントに通知する、請求項1に記載のプレゼンス管理方法。
3. 前記集約ステップは、
   任意のクライアントから属性値を含む集約条件の指定を受け付け、
   前記通知先管理テーブルにおいて前記指定元クライアントを通知先とするプレゼンス情報のうち、前記指定された属性値を有するプレゼンス情報の提供元クライアントを特定し、
   前記特定した提供元クライアントのプレゼンス情報を含む集約プレゼンス情報を生成し、
   前記集約通知ステップは、前記生成した集約プレゼンス情報を、前記集約条件の指定元クライアントに通知する、
   請求項1に記載のプレゼンス管理方法。
4. 前記管理ステップは、任意のクライアントからプレゼンス情報の更新を受け付け、
   前記集約ステップは、
   更新されたプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアントを特定し、
   前記特定された提供元クライアントに対し、前記通知先管理テーブルで対応づけられている通知先クライアントを特定し、
   前記特定された提供元クライアントのプレゼンス情報と、前記更新されたプレゼンス情報と、を含む集約プレゼンス情報を生成し、
   前記集約通知ステップは、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、請求項1に記載のプレゼンス管理方法。
5. 前記集約ステップは、前記同一の属性値と、前記同一の属性値を有するプレゼンス情報である集約対象プレゼンス情報の提供元クライアントと、前記集約対象プレゼンス情報に基づいて生成される集約プレゼンス情報の識別子と、前記集約プレゼンス情報の通知先クライアントと、を対応づける集約情報テーブルを記憶し、
   前記管理ステップは、前記集約ステップで生成された集約プレゼンス情報と、前記集約プレゼンス情報の識別子と、を対応付けて管理する、
   請求項1に記載のプレゼンス管理方法。
6. 前記集約情報テーブルに記憶されているいずれかの属性値の指定を任意のクライアントから受け付け、前記クライアントを通知先クライアントとする集約プレゼンス情報のうち、指定された属性値を有する集約プレゼンス情報のエントリを、前記集約情報テーブルから削除する解除ステップをさらに含む、請求項５に記載のプレゼンス管理方法。
7. 集約プレゼンス情報の通知条件を定義する通知ルールを記憶する通知ルール記憶ステップをさらに含み、
   前記集約ステップは、前記通知ルールに基づいて、集約プレゼンス情報を生成するか否かを判断し、
   前記集約通知ステップは、前記通知ルールに基づいて、集約プレゼンス情報を送信するか否かを判断する、請求項１に記載のプレゼンス管理方法。
8. 複数のクライアントと接続されるプレゼンス管理装置であって、
   属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段と、
   前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段と、
   同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段と、
   前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段と、を含み、
   前記管理手段は、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
   前記集約手段は、
   前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
   実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
   前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
   前記集約通知手段は、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、
   プレゼンス管理装置。
9. 複数のクライアントと接続されるコンピュータが実行するプレゼンス管理プログラムであって、
   属性値を含むプレゼンス情報を前記クライアントから受信し、受信したプレゼンス情報の提供元クライアントと前記プレゼンス情報とを対応付けて記憶する管理手段、
   前記管理手段で管理されているプレゼンス情報の提供元クライアントと、各プレゼンス情報の通知先クライアントと、を対応づける通知先管理テーブルを記憶する通知先管理手段、
   同一の通知先クライアントに通知される複数のプレゼンス情報のうち、同一の属性値を有するプレゼンス情報を含む集約プレゼンス情報を生成する集約手段、及び
   前記集約手段で生成された集約プレゼンス情報を、前記通知先クライアントに通知する集約通知手段、
   として前記コンピュータを機能させるプレゼンス管理プログラムであり、
   前記管理手段は、新たにプレゼンス情報を提供するクライアントであり前記管理手段に未登録の新たなクライアント及びそのプレゼンス情報の登録を受け付け、
   前記集約手段は、
   前記新たなクライアント及びそのプレゼンス情報の登録に応じ、前記新たなクライアントのプレゼンス情報と同一の属性値に基づく集約がすでに実行されているか否かを判断し、
   実行されていると判断した場合、前記新たなクライアントのプレゼンス情報と同一の属性値を有するプレゼンス情報の提供元クライアント及びそのプレゼンス情報の通知先クライアントを特定し、
   前記特定された提供元クライアントのプレゼンス情報と、前記新たなクライアントのプレゼンス情報と、を含む集約プレゼンス情報を生成し、
   前記集約通知手段は、前記集約ステップで生成された集約プレゼンス情報を、前記集約ステップで特定された通知先クライアントに通知する、
   プレゼンス管理プログラム。

Images