JP4777222B2 - 状態管理装置及び状態管理方法 - Google Patents

Description

本発明は、プレゼンティティの状態情報を管理・通知する状態管理システムに関する。
状態管理システムは、プレゼンスサーバと複数のクライアントとを含む。プレゼンスサーバは、任意のクライアントＣ１から収集した状態情報(以下、プレゼンス情報という)を記憶し、別のクライアントＣ２に配信する。
プレゼンティティとは、プレゼンス情報の所有者であるクライアントを言う。

ウォッチャーとは、あるプレゼンティティのプレゼンス情報の配信先クライアントを言う。
バディとは、ウォッチャーにプレゼンス情報を提供するプレゼンティティを言う。
パブリッシャとは、自分以外の他のクライアントであるプレゼンティティに、プレゼンス情報を設定するクライアントを言う。パブリッシャがプレゼンス情報を設定しようとしているプレゼンティティが、その設定を許可しているか否かは問わない。

ユビキタス社会を想定し、プレゼンティティのプレゼンス情報が、そのプレゼンティティ以外のクライアント、すなわちパブリッシャにより設定・更新される状態管理システムが提案されている。これを可能にするためには、あるプレゼンティティＡのプレゼンス情報を設定・更新しようとするパブリッシャＢは、予めプレゼンティティＡから、そのプレゼンス情報の設定及び更新許可をもらっておく。プレゼンスサーバは、プレゼンティティ毎に、そのプレゼンス情報の設定・更新を許可するパブリッシャを記憶している。従って、許可されているパブリッシャＢからのプレゼンス情報のみが、プレゼンティティＡのプレゼンス情報として書き込まれる。プレゼンティティＡから拒否されているパブリッシャＣや許可も拒否もされていないパブリッシャＤからのプレゼンス情報は、プレゼンティティＡのプレゼンス情報としては受け付けられない。

ユビキタス社会では、膨大な量のパブリッシャがプレゼンティティＡのプレゼンス情報をプレゼンスサーバに送信するようになると予想される。そのとき、それら全てのプレゼンス通知の送信に先だって、プレゼンティティＡが、全てのパブリッシャについての許可／拒否を設定することは現実的には難しい。従って、許可も拒否もされていないパブリッシャ、すなわちプレゼンティティの認識外のパブリッシャが多数存在することになる。

例えば、新規に設定されたパブリッシャ・更新されたパブリッシャ・状態管理システムの管理者とは異なる管理者が設置しているパブリッシャなどは、プレゼンティティの認識外のパブリッシャとなる確率が高い。このような認識外のパブリッシャからのプレゼンス情報は、現状ではプレゼンス情報として設定されない。これでは、プレゼンス情報をリアルタイムに把握し、ウォッチャーに通知することが難しくなる。その結果、ウォッチャーは、プレゼンス情報が変更されているにもかかわらず、本当のプレゼンス情報と自分が見ているプレゼンス情報とのずれを知り得ないことになる。これでは、状態管理システムの存在意義が低下する。

一方で、プレゼンティティの認識外のパブリッシャからのプレゼンス情報を、そのプレゼンティティのプレゼンス情報として設定すれば、プレゼンティティのプライバシーを侵害するおそれがある。プレゼンティティの認識を超える範囲のプレゼンス情報が、知らない間にウォッチャーに通知されることになるからである。
本発明は、プレゼンティティが認識していないパブリッシャの動的変化を、プレゼンス情報の変化に反映させることを目的とする。また、本発明は、プレゼンティティのプライバシーを保護し、プレゼンティティの認識の範囲内で、パブリッシャの動的変化に応じたプレゼンス情報の変化通知を行うことを目的とする。

前記課題を解決するために、本発明１は、複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理装置を提供する。この状態管理装置は、以下の手段を有している。
・各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段、
・各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段、
・任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段、
・前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段、
・前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段、
・更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段。

本発明では、設定クライアントが対象クライアントの状態情報を状態管理装置に送信すると、変化通知が対象クライアントのウォッチャーに通知される。対象クライアントは、変化通知の後に、設定クライアントに対して更新許可または更新拒否を設定すればよい。更新が許可されれば、設定クライアントからの状態情報に基づいて、対象クライアントのいわゆるプレゼンス情報が更新される。更新が拒否されれば、対象クライアントのプレゼンス情報は更新されない。この場合であっても、プレゼンス情報が本当は変化していることが、変化通知によりウォッチャーに通知されている。従って、いかなる設定クライアントからの状態情報であっても、対象クライアントのプレゼンス情報の変化に反映させることができる。それと同時に、対象クライアントのプライバシーを保護し、対象クライアントの認識の範囲内でプレゼンス情報の変化通知を行うことができる。なお、対象クライアントとは、いわゆるプレゼンティティである。また、設定クライアントとは、いわゆるパブリッシャである。参照クライアントとは、いわゆるウォッチャーである。

本発明２は、前記発明１において、許可リスト記憶手段をさらに有する状態管理装置を提供する。許可リスト記憶手段は、前記状態記憶手段に記憶されている状態情報の更新が許可または拒否されているクライアントである認識クライアントを、クライアント毎に対応付けて記憶する。この装置において、前記変化通知手段は、前記設定クライアントが前記認識クライアントに含まれているか否かを判断し、含まれていない場合に前記変化通知を送信する。

許可リストに登録されていない設定クライアントは、対象クライアントが認識していないクライアントである。このようなクライアントから状態情報が送信された場合であっても、ウォッチャーに変化通知が送信される。従って、設定クライアントが新たに設置されるなどの動的変化を、対象クライアントのプレゼンス情報の変化に反映させることができる。

本発明３は、前記発明２において、バディリスト記憶手段をさらに有する状態管理装置を提供する。バディリスト記憶手段は、参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶する。この装置において、前記変化通知手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記変化通知を送信する。

被参照クライアントとはいわゆるバディである。例えば、多くのバディが許可している設定クライアントであれば、変化通知を送信することにしてもよい。逆に、多くのバディが拒否している設定クライアントであれば、変化通知を送信しないこともできる。バディリストを用いて設定クライアントのフィルタリングを行うことにより、無駄な変化通知を減らすことができる。

本発明４は、前記発明２において、バディリスト記憶手段と問い合わせ手段とをさらに有する状態管理装置を提供する。バディリスト記憶手段は、参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶する。問い合わせ手段は、前記設定クライアントによる状態情報の更新を許可するか否かの問い合わせを、前記対象クライアントに送信する。さらに前記問い合わせ手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記問い合わせを送信する。

例えば、多くのバディが許可している設定クライアントから状態情報を受信した場合、プレゼンティティに問い合わせを送信するとよい。逆に、多くのバディが拒否している設定クライアントから状態情報を受信した場合、プレゼンティティに問い合わせを送信しないこともできる。バディリストを用いて設定クライアントのフィルタリングを行うことにより、無駄な問い合わせをプレゼンティティに送信せずに済む。

本発明５は、前記発明２において、前記設定受付手段が、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を受け付けた場合、前記設定クライアントと、前記対象クライアントと、前記更新許可または更新拒否と、を対応付けて前記許可リスト記憶手段に書き込む状態管理装置を提供する。
非認識パブリッシャから設定情報を受信した場合、そのパブリッシャを、プレゼンティティからの応答に応じて許可リストまたは拒否リストに登録する。設定情報の受信に先立ってパブリッシャが認識されていなくても、受信後に設定される許可／拒否を記憶することにより、以降の設定情報の受信にその認識結果を用いることが可能となる。

本発明６は、前記発明１において、加工ルール記憶手段をさらに有する状態管理装置を提供する。加工ルール記憶手段は、前記設定クライアントから受信した状態情報を加工する加工ルールを、前記対象クライアントと対応付けて記憶する。この装置において、前記変化通知手段は、前記設定クライアントから受信した状態情報を、前記加工ルールに基づいて加工して仮情報を生成し、前記仮情報を含む変化通知を送信する。

設定クライアントからの状態情報そのものではなく、加工した情報を送信する。これにより、対象クライアントの状態が変化したことをウォッチャーに通知しつつ、対象クライアントのプライバシーを保護することができる。
本発明７は、前記発明１において、前記設定受付手段が、前記設定クライアントによる状態情報の更新許可の設定を受け付けた場合、前記対象クライアントに対応付けられている前記状態情報よりも以前の状態情報を、前記履歴情報から削除する状態管理装置を提供する。

設定クライアントによる状態情報の設定が許可された場合、それ以前の状態情報を削除する。これにより、履歴情報を必要最小限に抑えることができ、状態管理装置のリソースを有効に使用できる。
本発明８は、前記発明１において、前記設定受付手段が、前記設定クライアントによる状態情報の更新拒否の設定を受け付けた場合、前記設定クライアントからの状態情報を前記履歴情報から削除する状態管理装置を提供する。

設定クライアントによる状態情報の設定が拒否された場合、その状態情報が履歴情報に書き込まれる以前の状態に履歴情報を戻す。拒否された状態情報を記憶しておく必要はないため、不要な情報を削除することにより、状態管理装置のリソースを有効に使用できる。
本発明９は、複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理プログラムを提供する。このプログラムは、以下の手段としてコンピュータを機能させる。
・各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段、
・各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段、
・任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段、
・前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段、
・前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段、及び
・更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段。

このプログラムは、コンピュータ端末を発明１の状態管理装置として機能させ、発明１と同様の作用効果を奏する。
本発明１０は、複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理方法を提供する。この方法は、以下のステップを含む。
・各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶ステップ、
・各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶ステップ、
・任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新ステップ、
・前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知ステップ、
・前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付ステップ、
・更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶ステップで記憶されている前記対象クライアントの状態情報を更新する更新ステップ。

この方法は、発明１の状態管理装置が実行する方法であり、発明１と同様の作用効果を奏する。

本発明を用いれば、設定クライアントが対象クライアントにより認識されていなくても、対象クライアントの状態情報を参照している参照クライアントに変化通知が送信される。従って、設定クライアントによる状態情報の更新が対象クライアントにより拒否されたとしても、状態情報が本当は変化していることが変化通知により参照クライアントに通知されている。従って、設定クライアントの動的変化を、対象クライアントの状態情報の変化に反映させることができる。それと同時に、対象クライアントのプライバシーを保護し、対象クライアントの認識の範囲内で状態情報の変化通知を行うことができる。

＜発明の概要＞
図１は、本発明のプレゼンスサーバ１００の機能構成の一例を示すブロック図である。プレゼンスサーバ１００は、複数のクライアントとネットワークで接続され、状態管理システムを形成する。プレゼンスサーバ１００は、クライアントから状態情報を受信し、状態情報に基づいてプレゼンティティのプレゼンスデータを更新し、各プレゼンティティのウォッチャーに更新されたプレゼンスデータを配信する。クライアントは、ユーザが操作するコンピュータ端末だけでなく、各種センサなど状態情報を生成しうる装置を広く含む。以下では、プレゼンスサーバ１００がクライアントから受信する状態情報を「設定情報」と呼び、設定情報を加工して得られる状態情報である「プレゼンスデータ」と区別する。設定情報は、プレゼンティティ自身から送信される場合と、パブリッシャから送信される場合と、がある。プレゼンスデータは、プレゼンティティ自身が送信した設定情報を加工することにより得られるものと、プレゼンティティに許可されたパブリッシャが送信した設定情報を加工することにより得られるものと、がある。なお、設定情報を変更することなく、そのままプレゼンスデータとしたものも加工することの特別な例とする。

図２は、プレゼンスサーバ１００を含む状態管理システムで実行される処理の流れの概要を示す説明図である。プレゼンスサーバ１００は、あるプレゼンティティＡの状態を示す設定情報を、パブリッシャＢから受信すると（＃１）、これを履歴テーブル９に保存し、プレゼンスデータを一時的に書き換える（＃２）。一時的に書き換えられたプレゼンスデータを、仮情報という。次いで、プレゼンスサーバ１００は、プレゼンティティＡの仮情報を、プレゼンティティＡのウォッチャーＣに通知する（＃３）。この通知は、プレゼンスデータの更新を通知するプレゼンス更新コマンドにより送信される。ただし、以下の説明では、仮情報の通知を、プレゼンスデータの更新とは区別して、変化通知という。プレゼンスサーバ１００は、プレゼンティティＡに対し、設定情報に基づいた新たなプレゼンスデータを設定してもいいか否かの問い合わせを送信するとよい（＃４）。

上記問い合わせに対して「許可」の応答を受信した場合（＃５，＃６）、プレゼンスサーバ１００は許可リストＤＢ８内の許可リスト８ａに、パブリッシャＢを追加する（＃７）。また、プレゼンスサーバ１００は、履歴テーブル９から読み出した設定情報に基づいて、プレゼンスデータを生成する（＃８）。生成されたプレゼンスデータは、プレゼンス管理ＤＢ２ｂに登録される（＃９）。登録されたプレゼンスデータは、プレゼンティティＡのウォッチャーＣに、プレゼンス更新コマンドにより通知される（＃１０）。

上記問い合わせに対して「拒否」の応答を受信した場合（＃１１）、プレゼンスサーバ１００は許可リストＤＢ８内の拒否リスト８ｂに、パブリッシャＢを追加する（＃１２）。またプレゼンスサーバ１００は、パブリッシャＢから受信した設定情報を、履歴テーブル９から削除する。
以上の処理により、仮にパブリッシャＢが事前に許可または拒否されていなくても、ウォッチャーＣはプレゼンティティＡのプレゼンスデータに変化があったことを知る（＃３）。さらに、パブリッシャＢが事後的に許可されることにより、ウォッチャーＣはプレゼンティティＡの新たなプレゼンスデータを知る（＃９）。パブリッシャＢが事後的に拒否された場合でも、変化通知によりウォッチャーＣはプレゼンティティＡのプレゼンスデータに変化があったことを知っている。従って、プレゼンティティが意識していないパブリッシャの変化が生じていても、プレゼンティティのプライバシーを保護しつつ、プレゼンスデータの変化を通知することができる。

＜第１実施形態＞
《構成》
再び図１を参照し、本発明の第１実施形態に係るプレゼンスサーバ１００の機能構成について説明する。プレゼンスサーバ１００は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスクなどを有するコンピュータ端末を用いて構成される。プレゼンスサーバ１００のＣＰＵは、受信部１、プレゼンス管理部２、プレゼンス通知部３、履歴管理部４、仮設定判断部５、問い合わせ部６及び加工部７として機能する。さらに、プレゼンスサーバ１００は、ＲＯＭやハードディスク等の記憶領域上に、バディリスト２ａ、プレゼンス管理テーブル２ｂ、許可リストデータベース（以下、単にＤＢという）９、履歴テーブル９及び加工ルールテーブル１０を有している。まず、各データベース及びテーブルについて説明し、その後各部の機能について説明する。本状態管理システムにおいて、各クライアントはクライアントＩＤにより一義的に特定される。

〔各データベース及びテーブル〕
（１）バディリスト
図３は、バディリスト２ａの概念説明図である。バディリスト２ａは、各クライアントのバディを記憶している。具体的には、バディリスト２ａは、「ウォッチャーＩＤ」、「バディＩＤ」、及び「表示名」を、互いに対応付けて記憶している。「ウォッチャーＩＤ」は、バディのプレゼンスデータの参照を希望するクライアントのクライアントＩＤである。「バディＩＤ」は、バディのクライアントＩＤである。「表示名」は、ウォッチャーのクライアントのＰＣ上で用いられるバディの表示用名称である。

（２）プレゼンス管理テーブル
図４は、プレゼンス管理テーブル２ｂの概念説明図である。プレゼンス管理テーブル２ｂは、各プレゼンティティの最新のプレゼンスデータとそのウォッチャーとを管理している。具体的には、プレゼンス管理テーブル２ｂは、「プレゼンティティＩＤ」、「プレゼンスデータ」、「ウォッチャーＩＤ」、及び「状態」を、互いに対応付けて記憶している。「プレゼンティティＩＤ」は、プレゼンスデータのプレゼンティティを特定するクライアントＩＤである。「プレゼンスデータ」は、プレゼンティティの状態情報である。プレゼンスデータは、プレゼンティティ自身により設定される場合と、パブリッシャにより設定される場合とがある。「ウォッチャーＩＤ」は、プレゼンスデータの配信先クライアント、すなわちウォッチャーのクライアントＩＤである。「状態」は、ウォッチャーへの配信を許可するか否かを示す。「allow」は配信の許可を、「deny」は配信の禁止を、「asking」はプレゼンティティに配信を許可するかどうかの問い合わせ中であることを、それぞれ示している。

（３）許可リストＤＢ
（３−１）許可リスト
図５は、許可リストＤＢ８に格納されている許可リスト８ａの概念説明図である。同図（ａ）は、初期状態の許可リスト８ａを示す。同図（ｂ）は、パブリッシャ“Sensor4”が新たに追加された、更新後の許可リスト８ａを示す。許可リストは、「プレゼンティティＩＤ」、「許可パブリッシャＩＤ」、及び「許可時間」を、対応付けて記憶している。「プレゼンティティＩＤ」は、プレゼンティティのクライアントＩＤである。「許可パブリッシャＩＤ」は、プレゼンティティのプレゼンスデータの設定が許可されているパブリッシャのクライアントＩＤである。「許可時間」は、パブリッシャがプレゼンスデータを設定可能な時間帯を示す。「許可時間」を対応付けて記憶していれば、プレゼンティティは、時間帯に応じてプレゼンスデータの設定を許可することができる。ただし、「許可時間」は必ずしも必須ではない。また、「許可時間」は、プレゼンスデータの更新を許可する条件の一種であり、他の条件を設定することも可能である。例えばパブリッシャに属性が設定されている場合、所定の属性を有することを、更新許可の条件とすることもできる。

（３−２）拒否リスト
図６は、許可リストＤＢ８に格納されている拒否リスト８ｂの概念説明図である。同図（ａ）は、初期状態の許可リスト８ｂを示す。同図（ｂ）は、パブリッシャ“Sensor4”が新たに追加された、更新後の拒否リスト８ｂを示す。拒否リストは、「プレゼンティティＩＤ」、「拒否パブリッシャＩＤ」、及び「拒否時間」を、対応付けて記憶している。「プレゼンティティＩＤ」は、プレゼンティティのクライアントＩＤである。「拒否パブリッシャＩＤ」は、プレゼンティティのプレゼンスデータの設定を拒否されているパブリッシャのクライアントＩＤである。「拒否時間」は、パブリッシャがプレゼンスデータを設定できない時間帯を示す。「拒否時間」を対応付けて記憶していれば、プレゼンティティは、時間帯に応じてプレゼンスデータの設定を拒否することができる。ただし、「拒否時間」は必ずしも必須ではない。また、「拒否時間」は、プレゼンスデータの更新を拒否する条件の一種であり、他の条件を設定することも可能である。例えばパブリッシャに属性が設定されている場合、所定の属性を有することを、更新拒否の条件とすることもできる。

（４）履歴テーブル
図７ａ〜図７ｅは、履歴テーブル９の概念説明図である。履歴テーブル９は、パブリッシャから受信した設定情報を、プレゼンティティと対応付けて記憶する。図７ａは、ある時点での状態(以下、初期状態)の履歴テーブル９を示す。図７ｂは、パブリッシャ“Sensor4”からのプレゼンス設定コマンド受信後の履歴テーブル９である。図７ｃは、仮設定可能な場合の履歴テーブル９である。「仮設定」については詳細を後述する。図７ｄは、プレゼンティティ“User2”がパブリッシャ“Sensor4”によるプレゼンスデータの設定を許可した場合の履歴テーブル９である。図７ｅは、プレゼンティティ“User2”がパブリッシャ“Sensor4”によるプレゼンスデータの設定を拒否した場合の履歴テーブル９である。履歴テーブル９の変化については詳細を後述することとし、ここでは履歴テーブルに記憶される情報について説明する。

具体的には、履歴テーブル９は、「プレゼンティティＩＤ」、「設定ＩＤ」、「パブリッシャＩＤ」、「問い合わせ実行」、「設定許可」、「設定内容」、「状態」、及び「直前設定」を、対応付けて記憶している。「プレゼンティティＩＤ」は、プレゼンティティのクライアントＩＤである。「設定ＩＤ」は、履歴テーブル９内のエントリを特定する。「パブリッシャＩＤ」は、設定情報の送信元パブリッシャのクライアントＩＤである。「問い合わせ実行」フィールドは、その設定情報に基づくプレゼンスデータの設定の可否について、プレゼンティティに問い合わせが必要か否かを示す。「設定許可」フィールドは、設定情報に基づくプレゼンスデータの設定がプレゼンティティにより許可されているか否かを示す。「設定内容」フィールドには、パブリッシャから受信した設定情報が設定される。「状態」フィールドは、“設定中”であればそのエントリが最新のエントリ、すなわちカレントエントリであることを示す。“待避中”であればそのエントリの設定内容は過去の設定情報であることを示す。「直前設定」フィールドの値が“Ｙｅｓ”であれば、そのエントリは現在のカレントエントリの前のカレントエントリだったことを示す。

例えば図７ａの履歴テーブル９の設定ＩＤ“６”のエントリ（以下、単にエントリ“６”という）は、プレゼンティティ“User2”がパブリッシャ“Sensor1”によるプレゼンスデータの設定を許可したことを示している。またこのエントリは、この許可がプレゼンティティに対する問い合わせにより得られたことを示している。履歴テーブル９の更新については、詳細を後述する。

（５）加工ルールテーブル
図８は、加工ルールテーブル１０の概念説明図である。加工ルールテーブル１０は、設定情報を加工するためのルールを記憶している。具体的には、加工ルールテーブル１０は、「プレゼンティティＩＤ」、「パブリッシャＩＤ」、「許可時ルール」、及び「未許可時ルール」を対応付けて記憶している。「プレゼンティティＩＤ」及び「パブリッシャＩＤ」は、履歴テーブル９と同様である。図中、「＊」は任意のパブリッシャを示す。「許可時ルール」は、設定情報をプレゼンスデータに加工するルールを示す。許可時ルールは、プレゼンティティがパブリッシャによるプレゼンスデータの更新を許可している場合に適用される。「未許可時ルール」は、非認識パブリッシャからの設定情報を仮情報に加工するルールを示す。仮情報とは、前述したように、一時的に設定されるプレゼンスデータである。非認識パブリッシャとは、許可リスト８ａにも拒否リスト８ｂにも登録されていないパブリッシャである。

許可時ルールの例を具体的に説明する。図８は、パブリッシャからの設定情報が、<place>、<floor>、<area>でタグ付けされている場合の加工ルールを示している。許可時ルール「<place>+<floor>+<area>」は、全てのデータを連結することを示す。例えば、設定情報「<place>本社</place><floor>6F</floor><area>A事業部</area>」は、「本社6FA事業部(08/18 10:15)」に加工される。ここで、時刻情報「(08/18 10:15)」は、プレゼンスデータを更新した時刻を示し、状態管理装置が付与する値である。

次に未許可時ルールを具体的に説明する。例えば、未許可時ルール「<place>」は、設定情報中のタグ<place>のデータを抽出することを示す。このルールを適用すると、設定情報「<place>本社</place><floor>8F</floor><area>A会議室</area>」は、仮情報「本社」に加工される。その結果、仮情報「本社」がウォッチャーに送信される。
位置情報は上記のように独自のXML(eXtensible Markup Language)によるデータフォーマットで設定することも可能であるが、例えばRFIDタグを使った流通管理システムの標準化を進めているEPC Globalが策定したPML (Physical Markup Language)を使うことも可能である。PMLでは<loc>タグで指定場所を起点としたパブリッシャの相対的な位置を記述できるため、位置情報としてPMLを利用することで位置情報を統一したフォーマットで記述することが可能となる。

〔各部の機能〕
次に、プレゼンスサーバ１００の各部の機能について、各部が実現する機能毎に説明する。プレゼンスサーバ１００は、大別して（１）プレゼンス管理機能、（２）仮設定機能、（３）変化通知機能、（４）設定受付機能、（５）プレゼンスデータ更新機能を有している。

（１）プレゼンス管理機能
プレゼンスサーバ１００は、プレゼンティティ自身によるプレゼンスデータの設定及び更新を受け付ける。またプレゼンスサーバ１００は、更新されたプレゼンスデータを、プレゼンティティのウォッチャーに配信する。さらにプレゼンスサーバ１００は、バディリストの登録を受け付ける。

（１−１）プレゼンスデータの設定・更新・配信
プレゼンスデータの設定・更新・配信について、より具体的に説明する。受信部１は、プレゼンス設定コマンドを受信すると、そのコマンドがプレゼンティティ自身により送信されているのか、パブリッシャにより送信されているのかを、判断する。この判断は、プレゼンス設定コマンドに含まれる送信元クライアントのＩＤ及び状態設定の対象を特定するプレゼンティティＩＤを比較することにより行われる。両者が一致する場合、受信部１は、プレゼンス設定コマンドがプレゼンティティ自身により送信されていると判断する。受信した設定情報及びクライアントＩＤは、プレゼンス管理部２に渡される。プレゼンス管理部２は受信した設定情報に基づいてプレゼンスデータを更新し、プレゼンス通知部３がウォッチャーに新たなプレゼンスデータを配信する。新たなプレゼンスデータは、プレゼンス更新コマンドにより通知される。このとき、プレゼンス管理部２は、加工ルールテーブル１０を参照し、受信した設定情報をプレゼンスデータに加工することができる。加工ルールとしては、許可時ルールを用いるとよい。

（１−２）バディリストの登録
バディリストの登録について、より具体的に説明する。プレゼンス管理部２は、受信部１を介してクライアントから参照依頼コマンドを受信すると、この依頼コマンドに基づいてバディリスト２ａ及びプレゼンス管理テーブル２ｂを更新する。参照依頼コマンドには、ウォッチャーＩＤと、バディＩＤと、表示名と、が含まれている。これらが対応付けられて、バディリスト２ａ及びプレゼンス管理テーブル２ｂに登録される。さらにプレゼンス管理部２は、バディに対してプレゼンスデータを配信しても良いかどうかの問い合わせを行い、これに対する応答をプレゼンス管理テーブル２ｂに書き込むとよい。これにより、プレゼンスデータを参照されるバディの意図に反するプレゼンスデータの配信を防止できる。

（２）仮設定機能
プレゼンスサーバ１００は、パブリッシャからの設定情報を受信すると、履歴テーブル９に登録する。またプレゼンスサーバ１００は、バディリスト２ａを参照し、変化通知を送信するか否か、プレゼンティティに対して問い合わせを送信するか否かを決定してもよい(以下、これを仮設定という)。この場合、プレゼンスサーバ１００は、決定に応じて履歴テーブル９を更新する。

（２−１）設定情報の登録
まず履歴テーブル９への設定情報の登録について、具体的に説明する。受信部１は、受信したプレゼンス設定コマンドがパブリッシャからであると判断すると、受信したプレゼンス設定コマンドを履歴管理部４に渡す。このときプレゼンス設定コマンドには、パブリッシャＩＤとプレゼンティティＩＤと設定情報とが含まれている。履歴管理部４は、許可リスト８ａ及び拒否リスト８ｂのいずれにおいても前記パブリッシャＩＤが前記プレゼンティティＩＤと対応付けられていない場合、設定情報を履歴テーブル９に登録する。すなわち、パブリッシャが、プレゼンティティに認識されていない場合、設定情報は履歴テーブル９に登録される。図７ａ及び図７ｂの履歴テーブルは、パブリッシャからのプレゼンス設定コマンドによる履歴テーブル９の変化を示す。図７ｂにおいて、新たなエントリ“７”が追加されている。このエントリには、パブリッシャＩＤ“Sensor4”からの設定情報が書き込まれている。

一方、パブリッシャＩＤがプレゼンティティＩＤと対応付けられて許可リスト８ａに登録されている場合もあり得る。すなわち、パブリッシャによるプレゼンスデータの更新が、既にプレゼンティティにより許可されている場合である。この場合、履歴管理部４は、設定情報を履歴テーブル９に登録し、プレゼンス管理部２に設定情報を渡す。設定情報は、許可時ルールに従ってプレゼンスデータに加工され、プレゼンス管理テーブル２ｂに登録され、ウォッチャーに送信される。

逆にパブリッシャＩＤがプレゼンティティＩＤと対応付けられて拒否リスト８ｂに登録されている場合もあり得る。すなわち、パブリッシャによるプレゼンスデータの更新が、既にプレゼンティティにより拒否されている場合である。この場合、履歴管理部４は設定情報を破棄し、次のプレゼンス設定コマンドを待機する。
（２−２）仮設定
次に、仮設定について具体的に説明する。仮設定判断部５は、後述する変化通知や問い合わせを行うに先立ち、パブリッシャのフィルタリングを行う。すなわち、仮設定判断部５は、変化通知や、パブリッシャによるプレゼンスデータの更新を許可するか否かの問い合わせを送信するか否かを、判断する。全ての設定情報の受信に応じて変化通知や問い合わせを送信することは、プレゼンスサーバ１００の負荷やネットワーク負荷の増大につながると共に、ウォッチャーやプレゼンティティに無駄な情報を送信することになりかねないからである。この判断は、例えばプレゼンティティのバディの許可リスト８ａや拒否リスト８ｂに基づいて行うことができる。例えばプレゼンティティのバディのうち所定割合以上のバディが拒否しているパブリッシャであれば、仮設定不可能と判断することができる。この場合は、変化通知や問い合わせは送信されない。逆に、例えばプレゼンティティのバディのうち所定割合以上のバディが許可しているパブリッシャであれば、仮設定可能と判断してもよい。この場合は、変化通知や問い合わせが送信される。

図７ｃの履歴テーブルは、仮設定可能と判断され、変化通知及び問い合わせが送信された段階での履歴テーブル９を示す。エントリ“７”において、「問い合わせ実行」フィールドの値が“Ｙｅｓ”になり、「状態」フィールドの値が“設定中”に変化している。これは、カレントエントリがエントリ“７”であることを示す。また元々登録されていたエントリ“６”において、「状態」フィールドの値が“待避中”になり、「直前設定」フィールドの値が“Ｙｅｓ”に変化している。これは、エントリ“６”が直前までカレントエントリであったことを示す。問い合わせの結果、パブリッシャ“Sensor4”がプレゼンティティにより拒否された場合、「直前設定」フィールドの値に基づいてエントリ“６”が再びカレントエントリとなる。

（３）変化通知機能
プレゼンスサーバ１００は、プレゼンティティに認識されていないパブリッシャからの設定情報を受信した場合、変化通知を送信する。具体的には、プレゼンス通知部３は、プレゼンティティの状態情報に変化が生じたことを示す変化通知を、そのプレゼンティティのウォッチャーに送信する。本実施形態では、仮設定判断部５が仮設定可能と判断した場合、仮情報がプレゼンス管理テーブル２ｂに設定される。仮情報は、一時的に設定されるプレゼンスデータであり、加工ルールテーブル１０の未許可時ルールを用いて加工部７が設定情報から生成する。プレゼンス通知部３は、プレゼンスデータが変化するので、プレゼンス更新コマンドをウォッチャーに送信する。本実施形態では、仮情報を通知するプレゼンス更新コマンドを、通常のプレゼンス更新コマンドと区別して変化通知という。

変化通知は、プレゼンティティの状態情報が変化したことを示す情報を含む。本実施形態の仮情報は、設定情報の一部を含む情報である。ただし、仮情報は、必ずしも設定情報の一部とは限らない。例えば仮情報は、一定の値やメッセージであってもよい。設定情報そのものとは異なる情報を変化通知としてウォッチャーに通知することにより、何らかの状態変化がプレゼンティティに生じたことをウォッチャーに通知することができる。しかも、プレゼンティティの認識外で、プレゼンティティの状態情報がウォッチャーに知られることを防止し、プレゼンティティのプライバシーを保護することができる。

（４）設定受付機能
プレゼンスサーバ１００は、パブリッシャによるプレゼンスデータの更新を許可するか否かの設定を、プレゼンティティから受け付けてこれを許可リストＤＢ８に記憶する。
（４−１）問い合わせ
本実施形態では、問い合わせ部６が、パブリッシャによるプレゼンスデータの更新を許可するか否かの問い合わせを、プレゼンティティに対して送信する。また問い合わせ部６は、問い合わせに対する応答をプレゼンティティから受信すると、応答に応じた処理を行う。問い合わせは、例えばパブリッシャＩＤと、パブリッシャに関する詳細情報と、を含む。パブリッシャに関する詳細情報とは、例えばパブリッシャの設置場所やパブリッシャの管理者名などである。

図９は、問い合わせ部６がプレゼンティティに送信する設定画面例である。問い合わせ部６は、この画面上で、プレゼンティティの応答を受け付ける。設定画面は、パブリッシャフィールド９１、パブリッシャ詳細フィールド９２、処理内容選択ラジオボタン９３、条件選択ラジオボタン９４、時間入力フィールド９５、及び設定ボタン９６を有している。パブリッシャフィールド９１には、パブリッシャＩＤが表示される。この例では、“Sensor4”が表示されている。パブリッシャ詳細フィールド９２には、この例ではパブリッシャであるセンサの設定場所が表示されている。プレゼンティティは、パブリッシャＩＤやパブリッシャに関する詳細情報に基づいて、条件選択ボタン９４により処理内容、すなわち「許可」／「拒否」／「いずれでもない」を選択する。また、この例では、時間入力フィールド９５により、許可時間や拒否時間等の時間条件を設定できる。これらを設定して「設定ボタン９６」が押下されると、応答がプレゼンスサーバ１００に送信される。この応答には、パブリッシャＩＤと選択された処理内容とが含まれ、設定されている場合には時間条件がさらに含まれる。

（４−２）応答後の処理
「許可」の応答を受信した場合、問い合わせ部６は、履歴テーブル９のカレントエントリよりも以前のエントリを、履歴テーブル９から削除する。言い換えれば、そのプレゼンティティに関しては、パブリッシャからのプレゼンス設定コマンドにより設定された最新の設定情報だけを、履歴テーブル９に残す。図７ｄの履歴テーブル９は、新たに許可されたパブリッシャ“Sensor4”からの設定情報が、プレゼンティティ“User2”の最新の状態情報となっていることを示す。また問い合わせ部６は、許可されたパブリッシャＩＤとプレゼンティティＩＤとを、対応付けて許可リスト８ａに登録する。さらに、この許可された設定情報に基づいてプレゼンスデータを生成し、これをプレゼンス管理テーブル２ｂに書き込む。

「拒否」の応答を受信した場合、問い合わせ部６は、履歴テーブル９のカレントエントリを削除する。言い換えれば、拒否されたパブリッシャからの設定情報を含むエントリを削除し、カレントエントリを直前のカレントエントリに戻す。また、この直前のカレントエントリの設定情報に基づいてプレゼンスデータを生成し、これをプレゼンス管理テーブル２ｂに書き込む。図７ｅは、拒否されたパブリッシャ“Sensor4”からの設定情報を含むエントリ“７”が削除された履歴テーブル９を示す。この履歴テーブル９では、エントリ“７”がカレントエントリになる直前にカレントエントリであったエントリ“６”が、再びカレントエントリになっている。エントリ“６”の設定情報に基づいて、プレゼンスデータが生成され、プレゼンス管理テーブル７ｂに書き込まれる。すなわち、パブリッシャによるプレゼンスデータの更新がプレゼンティティにより拒否された場合、履歴テーブル９を用いてプレゼンティティの設定情報及びプレゼンスデータを遡及させることができる。さらに問い合わせ部６は、拒否されたパブリッシャＩＤとプレゼンティティＩＤとを、対応付けて拒否リスト８ｂに登録する。

(５)プレゼンスデータ更新機能
プレゼンスサーバ１００は、プレゼンティティからの応答に応じ、プレゼンティティのプレゼンスデータを更新する。より具体的には、加工部７は、許可されたパブリッシャからの設定情報に基づいて新たなプレゼンスデータを生成し、プレゼンス管理テーブル２ｂに登録する。プレゼンスデータの生成には、加工ルールテーブル１０の許可時ルールが用いられる。新たなプレゼンスデータは、プレゼンス通知部３によりプレゼンス更新コマンドとしてウォッチャーに通知される。従って、パブリッシャが許可された場合には、ウォッチャーは、まず変化通知を受信し、その後新たなプレゼンスデータを受信することになる。逆にパブリッシャが拒否された場合には、ウォッチャーは変化通知と直前に設定されていたプレゼンスデータを受信することになる。

《処理》
（１）メインルーチン
図１０ａは、プレゼンスサーバ１００が実行するメインルーチンの処理の流れの一例を示すフローチャートである。なお、説明を容易にするために、この図ではプレゼンティティ自身によるプレゼンスデータの更新を省略し、パブリッシャによるプレゼンスデータの更新について説明する。

ステップＳ１：プレゼンスサーバ１００は、プレゼンス設定コマンドの受信を待機し、これを受信するとステップＳ２に移行する。
ステップＳ２：プレゼンスサーバ１００は、プレゼンス設定コマンドの送信元パブリッシャが、プレゼンティティにより既に拒否されているか否かを判断する。この判断は、送信元のパブリッシャＩＤと、プレゼンスデータの設定対象であるプレゼンティティＩＤとが、拒否リスト８ｂに対応付けられて記憶されているか否かにより行う。パブリッシャがプレゼンティティにより既に拒否されていれば、本処理を終了する。そのようなパブリッシャからの設定情報に基づくプレゼンスデータの更新は勿論、変化通知も送信しないことがプレゼンティティの意図に沿っていると考えられるからである。

ステップＳ３：プレゼンスサーバ１００は、受信した設定情報を履歴テーブル９に書き込む。
ステップＳ４：プレゼンスサーバ１００は、プレゼンス設定コマンドの送信元パブリッシャが、プレゼンティティにより既に許可されたパブリッシャか否かを判断する。この判断は、送信元のパブリッシャＩＤと、プレゼンスデータの設定対象であるプレゼンティティＩＤとが、許可リスト８ａに対応付けられて記憶されているか否かにより行う。パブリッシャが既に許可されていれば、ステップＳ５に移行する。許可されていなければ、後述するステップＳ７に移行する。

ステップＳ５〜Ｓ６：プレゼンスサーバ１００は、プレゼンティティに関し、新たに許可されたパブリッシャからの設定情報を含むエントリよりも古いエントリを、履歴テーブル９から削除する（Ｓ５）。前記図７を用いて説明すれば、図７ｃの履歴テーブル９からエントリ“６”を削除する。またプレゼンスサーバ１００は、新たに許可されたパブリッシャからの設定情報を含むエントリを、カレントエントリに設定する（Ｓ６）。前記図７ｄを参照すれば、エントリ“７”の「状態」フィールドを“設定中”に変更する。

ステップＳ７：プレゼンスサーバ１００は、仮設定するか否かを判断する。この判断は、前述したように、プレゼンティティのバディの多くがパブリッシャを許可しているか否か等に基づいて行うことができる。仮設定しない場合、プレゼンスサーバ１００は本処理を終了する。仮設定する場合、ステップＳ８に移行する。
ステップＳ８：プレゼンスサーバ１００は、履歴テーブル９に新たに書き込んだ設定情報のエントリをカレントエントリに変更する。すなわち、新たなエントリの「状態」フィールドの値を“設定中”に変更する。また他の古いエントリの「状態」フィールドの値を“待避中”に変更し、元カレントエントリの「直前設定」フィールドの値を“Ｙｅｓ”に変更する。これにより、仮にパブリッシャが拒否された場合でも、どのエントリをカレントエントリに戻すかが判断可能になる。

ステップＳ９：プレゼンスサーバ１００は、プレゼンティティに対し、パブリッシャによるプレゼンスデータの更新を許可するか否かの問い合わせを送信する。
ステップＳ１０〜Ｓ１１：許可されていないパブリッシャからの設定情報を受信している場合（Ｓ４，Ｓ７〜Ｓ９）、プレゼンスサーバ１００は未許可時ルールに基づいて設定情報からプレゼンスデータを生成する（Ｓ１０）。生成されたプレゼンスデータは、プレゼンティティＩＤと対応付けてプレゼンス管理テーブル２ｂに書き込まれる（Ｓ１１）。このプレゼンスデータは、パブリッシャがプレゼンティティから拒否された場合、その前の値に戻される可能性がある。さらにプレゼンスサーバ１００は、新たなプレゼンスデータを、変化通知としてそのウォッチャーに送信する。

既に許可されたパブリッシャからの設定情報を受信している場合（Ｓ４〜Ｓ６）、プレゼンスサーバ１００は許可時ルールに基づいて設定情報からプレゼンスデータを生成する（Ｓ１０）。生成されたプレゼンスデータは、プレゼンティティＩＤと対応付けてプレゼンス管理テーブル２ｂに書き込まれる（Ｓ１１）。さらにプレゼンスサーバ１００は、新たなプレゼンスデータを記述したプレゼンス更新コマンドを、そのウォッチャーに送信する。

（２）応答処理
図１０ｂは、プレゼンスサーバ１００がプレゼンティティの応答に応じて行う応答処理の流れの一例を示すフローチャートである。
ステップＳ１０１〜Ｓ１０２：プレゼンスサーバ１００は、プレゼンティティからの応答を待機し（Ｓ１０１）、応答が「許可」であればステップＳ１０３に移行する（Ｓ１０２）。応答が「拒否」であれば、後述するステップＳ１０６に移行する。

ステップＳ１０３〜Ｓ１０５：プレゼンスサーバ１００は、プレゼンティティに関し、新たに許可されたパブリッシャからの設定情報を含むエントリよりも古いエントリを、履歴テーブル９から削除する（Ｓ１０３）。前記図７を用いて説明すれば、図７ｃの履歴テーブル９からエントリ“６”を削除する。またプレゼンスサーバ１００は、新たに許可されたパブリッシャからの設定情報を含むエントリを、カレントエントリに設定する（Ｓ１０４）。前記図７ｄを参照すれば、エントリ“７”の「状態」フィールドを“設定中”に変更する。さらにプレゼンスサーバ１００は、許可されたパブリッシャのクライアントＩＤを、プレゼンティティＩＤと対応付けて許可リスト８ａに登録する（Ｓ１０５）。

ステップＳ１０６：プレゼンスサーバ１００は、拒否されたパブリッシャからの設定情報を含むエントリを、履歴テーブル９から削除する（Ｓ１０６）。前記図７を用いて説明すれば、図７ｃの履歴テーブル９からエントリ“７”を削除する。またプレゼンスサーバ１００は、削除されたエントリがカレントエントリになる以前にカレントエントリだったエントリを、再びカレントエントリに戻す。前記図７ｅを参照すれば、エントリ“６”の「状態」フィールドを“設定中”に変更する。また、プレゼンスサーバ１００は、このカレントエントリの設定情報に基づいてプレゼンスデータを生成し、プレゼンス管理テーブル７ｂに書き込む。言い換えれば、プレゼンスサーバ１００は、プレゼンスデータを仮情報設定前の状態に戻す。さらにプレゼンスサーバ１００は、拒否されたパブリッシャのクライアントＩＤを、プレゼンティティＩＤと対応付けて拒否リスト８ｂに登録する（Ｓ１０５）。

以上の処理（１）、（２）により、プレゼンティティが認識していないパブリッシャからのプレゼンス設定コマンドを受信しても、プレゼンティティの状態に何らかの変化が生じたことをウォッチャーに通知することができる。また、変化通知や更新許可の問い合わせを、プレゼンス設定コマンドの一部に対して送信するので、ウォッチャーやプレゼンティティの負担やプレゼンスサーバの負担を軽減することができる。さらに、プレゼンティティがパブリッシャを拒否した場合には、プレゼンティティの最新の状態情報を拒否前の状態に戻すことができる。

＜第２実施形態＞
前記第１実施形態のプレゼンスサーバ１００は、パブリッシャからプレゼンス設定コマンドを受信するたびに、プレゼンティティに問い合わせを送信する。一方、本実施形態のプレゼンスサーバ１００’は、複数のプレゼンス設定コマンドに対するプレゼンティティの許可／拒否を、まとめて問い合わせる。

《構成》
図１１は、第２実施形態に係るプレゼンスサーバ１００’の機能構成を示すブロック図である。図中、第１実施形態と同様の機能を有するブロックは、同じ符号番号を付して示している。プレゼンスサーバ１００’のＣＰＵは、受信部１、プレゼンス管理部２、プレゼンス通知部３、履歴管理部４、仮設定判断部５、問い合わせ部６’及び加工部７として機能する。さらに、プレゼンスサーバ１００’は、ＲＯＭやハードディスク等の記憶領域上に、バディリスト２ａ、プレゼンス管理テーブル２ｂ、許可リストデータベース（以下、単にＤＢという）８、履歴テーブル９’、加工ルールテーブル１０及び問い合わせ条件テーブル１１を有している。以下では、説明を容易にするために、第１実施形態と異なる部分について説明する。

（１）問い合わせ条件テーブル
図１２は、問い合わせ条件テーブル１１の概念説明図である。問い合わせ条件テーブル１１は、「プレゼンティティＩＤ」及び「一括通知するまでの回数」を、対応付けて記憶している。「一括通知するまでの回数」が“Ｎ”であれば、プレゼンティティに対してプレゼンス設定コマンドをＮ回受信する毎に、そのプレゼンティティに問い合わせすることを示す。

例えば、プレゼンティティ“User1”に対しては、“Default”が設定されている。従って、プレゼンスサーバ１００’が定める所定数のプレゼンス設定コマンドをこのプレゼンティティに対して受信する毎に、プレゼンティティ“User1”に問い合わせが送信される。
また例えばプレゼンティティ“User2”に対しては、一括通知するまでの回数として“５”が設定されている。従って、このプレゼンティティに対するプレゼンス設定コマンドを５回受信する毎に、プレゼンティティ“User2”に問い合わせが送信される。

（２）履歴テーブル
（２−１）履歴テーブルの構成
図１３ａ〜図１３ｈは、第２実施形態における履歴テーブル９’の概念説明図である。履歴テーブル９’は、第１実施形態の履歴テーブル９に加え、「問い合わせ済」フィールドを、１レコードにさらに含む。「問い合わせ済」フィールドは、各エントリに含まれる設定情報によるプレゼンスデータの更新の可否を、プレゼンティティに問い合わせしたか否かを示す。

例えば図１３ａの履歴テーブル９’の設定ＩＤ“６”のエントリは、「問い合わせ済」フィールドが“Ｙｅｓ”、「設定許可」フィールドが“Ｙｅｓ”になっている。これは、このエントリの設定情報によるプレゼンスデータの更新について問い合わせた結果、更新が許可されたことを示す。
また例えば図１３ｂの履歴テーブル９’の設定ＩＤ“７”のエントリは、「問い合わせ実行」フィールドが“Ｙｅｓ”、「問い合わせ済」フィールドが“Ｎｏ”になっている。これは、このエントリの設定情報によるプレゼンスデータの更新について問い合わせをすることになっているものの、まだ問い合わせを実行していないことを示す。

（２−２）履歴テーブルの変化と問い合わせ部
次に履歴テーブル９’の変化と共に、問い合わせ部６’の機能について説明する。説明を容易にするために、問い合わせ条件テーブルは図１２に示す状態になっているとする。また、プレゼンティティが“User2”であり、プレゼンス設定コマンドを５回受信するたびにプレゼンティティへの問い合わせを実行する場合を考える。

(i)図１３ａは、ある時点での状態(以下、初期状態)の履歴テーブル９’を示す。この例では、パブリッシャ“Sensor1”によるプレゼンティティ“User2”のプレゼンスデータの設定が、問い合わせの結果許可されている。また、エントリ“６”の「状態」フィールドが“設定中”であり、このエントリ“６”がカレントエントリであることを示している。すなわち、カレントエントリ“６”の設定情報が、プレゼンティティ“User2”の最新のプレゼンスデータの元となる。

(ii)図１３ｂは、パブリッシャ“Sensor4”から１回目のプレゼンス設定コマンドを受信した後の履歴テーブル９’である。エントリ“７”が新たに追加され、このエントリがカレントエントリとなっている。しかし、エントリ“７”の「問い合わせ済」フィールドは“Ｎｏ”である。すなわち、パブリッシャ“Sensor4”によるプレゼンスデータの設定可否の問い合わせは、まだ送信されていない。

(iii)図１３ｃは、“Sensor9”から４回目のプレゼンス設定コマンドを受信した後の履歴テーブル９’である。図１３ｃの履歴テーブル９’では、１〜４回目のプレゼンス設定コマンドの受信により新たに追加されたエントリ“７”、“８”、“９”、“１０”の「問い合わせ済」フィールドが、“Ｎｏ”になっている。カレントエントリは、最も新しく登録されたエントリ“１０”である。３番目に登録されたエントリ“９”の「直前設定」フィールドの値は“Ｙｅｓ”になっている。

(iv)図１３ｄは、５回目のプレゼンス設定コマンドを受信した直後の履歴テーブル９’である。５回目のプレゼンス設定コマンドの受信に応じ、エントリ“１１”が登録され、カレントエントリとなる。
(v)図１３ｅは、問い合わせ送信後の履歴テーブル９’である。問い合わせ部６’は、プレゼンティティ“User2”に対してプレゼンス設定コマンドを５回受信する毎に、プレゼンティティに問い合わせを送信する。本図の履歴テーブル９’は、この問い合わせ送信後の状態である。受信したプレゼンス設定コマンドに対応する５つのエントリ“７”、“８”、“９”、“１０”、“１１”の「問い合わせ済」フィールドの値は“Ｙｅｓ”に変更されている。すなわち、プレゼンティティ“User2”に対し、これらのエントリに記述されたパブリッシャによるプレゼンスデータの更新を許可するか否か、の問い合わせが送信されている。

(vi)図１３ｆは、問い合わせに対する応答受信後の履歴テーブル９’である。問い合わせ部６’は、応答に応じ、履歴テーブル９’を更新する。この例は、パブリッシャ“Sensor9”によるプレゼンスデータの更新が許可された場合を示す。パブリッシャ“Sensor9”のエントリ“１０”では、「設定許可」フィールドが“Ｙｅｓ”に変更されている。またこのエントリ“１０”がカレントエントリに変更されている。他のエントリ“７”、“８”、“９”、“１１”は、拒否されたため、削除されている。また初期状態でのエントリ“６”も、不要となったため削除されている。なお、更新が許可されたパブリッシャ“Sensor9”は、問い合わせ部６’により許可リスト８ａに登録される。

(vii)図１３ｇは、問い合わせに対する別の応答受信後の履歴テーブル９’である。問い合わせ部６’は、応答に応じ、履歴テーブル９’を更新する。この例は、新たにプレゼンス設定コマンドを送信した全てのパブリッシャが拒否された場合である。この場合、初期状態で登録されていたエントリ“６”だけが履歴テーブル９’に残る。また、このエントリ“６”の「状態」フィールドが“設定中”に変更され、エントリ“６”が再びカレントエントリとなる。問い合わせの対象となったエントリ“７”、“８”、“９”、“１０”及び“１１”は、問い合わせ部６’により拒否リスト８ｂに登録される。

(viii)図１３ｈは、問い合わせに対するさらに別の応答受信後の履歴テーブル９’である。問い合わせ部６’は、応答に応じ、履歴テーブル９’を更新する。この例は、パブリッシャ“Sensor7”によるプレゼンスデータの更新が許可され、パブリッシャ“Sensor11”は許可も拒否もされず、その他のパブリッシャは拒否された場合を示す。パブリッシャ“Sensor7”のエントリ“９”では、「設定許可」フィールドが“Ｙｅｓ”に変更されている。またこのエントリ“１０”がカレントエントリに変更されている。パブリッシャ“Sensor11”のエントリ“１１”では、「設定許可」フィールドが“Ｎｏ”に変更されている。またこのエントリ“１１”の「状態」フィールドは、“待避中”に設定される。拒否されたエントリ“７”、“８”、“９”、“１０”は、履歴テーブル９’から削除されている。また初期状態でのエントリ“６”も、不要となったため削除されている。更新が許可されたパブリッシャ“Sensor7”は、問い合わせ部６’により許可リスト８ａに登録される。更新が拒否されたパブリッシャ“Sensor4”、“Sensor6”、“Sensor7”、“Sensor9”は、問い合わせ部６’により拒否リスト８ｂに登録される。許可も拒否もされなかったパブリッシャ“Sensor11”は、許可リスト８ａにも拒否リスト８ｂにも登録されない。

《処理》
（１）メインルーチン
図１４ａは、本実施形態のプレゼンスサーバ１００’が実行する処理の流れの一例を示すフローチャートである。前記第１実施形態と同様、説明を容易にするために、この図ではプレゼンティティ自身によるプレゼンスデータの更新を省略し、パブリッシャによるプレゼンスデータの更新について説明する。ステップＳ２１〜Ｓ２８の処理は、前記第１実施形態のステップＳ１〜Ｓ８の処理と同様である。

ステップＳ２１：プレゼンスサーバ１００は、プレゼンス設定コマンドの受信を待機し、これを受信するとステップＳ２に移行する。
ステップＳ２２：プレゼンスサーバ１００は、プレゼンス設定コマンドの送信元パブリッシャが、プレゼンス設定コマンドに記述されているプレゼンティティにより既に拒否されているか否かを、拒否リスト８ｂを参照して判断する。パブリッシャがこのプレゼンティティにより既に拒否されていれば、本処理を終了する。

ステップＳ２３：パブリッシャがプレゼンティティにより許可されていない場合、このパブリッシャはプレゼンティティが認識していない非認識パブリッシャである。そこで、プレゼンスサーバ１００は、受信した設定情報を履歴テーブル９’に書き込む。
ステップＳ２４：プレゼンスサーバ１００は、プレゼンス設定コマンドの送信元パブリッシャが、プレゼンティティにより既に許可されたパブリッシャか否かを判断する。この判断は、送信元のパブリッシャＩＤと、プレゼンスデータの設定対象であるプレゼンティティＩＤとが、許可リスト８ａに対応付けられて記憶されているか否かにより行う。パブリッシャが既に許可されていれば、ステップＳ２５に移行する。許可されていなければ、後述するステップＳ２７に移行する。

ステップＳ２５〜Ｓ２６：プレゼンスサーバ１００は、プレゼンティティに関し、新たに許可されたパブリッシャからの設定情報を含むエントリよりも古いエントリを、履歴テーブル９から削除する（Ｓ２５）。
ステップＳ２７：プレゼンスサーバ１００は、例えばプレゼンティティが許可／拒否しているパブリッシャを参照し、仮設定するか否かを判断する。仮設定しない場合、プレゼンスサーバ１００は本処理を終了する。仮設定する場合、ステップＳ２８に移行する。

ステップＳ２８：プレゼンスサーバ１００は、履歴テーブル９’に新たに書き込んだ設定情報のエントリをカレントエントリに変更する。すなわち、新たなエントリの「状態」フィールドの値を“設定中”に変更する。またそれまでカレントエントリだったエントリの「状態」フィールドの値を“待避中”に変更し、「直前設定」フィールドの値を“Ｙｅｓ”に変更する（図１３ｂ、図１３ｃ、図１３ｄ参照）。

ステップＳ２９：プレゼンスサーバ１００は、ステップＳ２１で受信したプレゼンス設定コマンド中のプレゼンティティについて、問い合わせ条件が満足されているか否かを、履歴テーブル９’を参照して判断する。問い合わせ条件が満たされている場合、ステップＳ３０に移行する。例えば前述のプレゼンティティ“User2”に対し、プレゼンス設定コマンドを５回受信した場合である。問い合わせ条件を満たしていない場合、再度ステップＳ２１に戻り、次のプレゼンス設定コマンドを待機する。

ステップＳ３０：プレゼンスサーバ１００は、プレゼンティティに対し、パブリッシャによるプレゼンスデータの更新を許可するか否かの問い合わせを送信する。
ステップＳ３１〜Ｓ３２：許可されていないパブリッシャからの設定情報を受信している場合（Ｓ２４，Ｓ２７〜Ｓ２８）、プレゼンスサーバ１００は未許可時ルールに基づいて設定情報からプレゼンスデータを生成する（Ｓ３１）。生成されたプレゼンスデータは、プレゼンティティＩＤと対応付けてプレゼンス管理テーブル２ｂに書き込まれる（Ｓ３２）。このプレゼンスデータは、パブリッシャがプレゼンティティから拒否された場合、その前の値に戻される可能性がある。さらにプレゼンスサーバ１００は、新たなプレゼンスデータを、変化通知としてそのウォッチャーに送信する。

既に許可されたパブリッシャからの設定情報を受信している場合（Ｓ２５〜Ｓ２６）、プレゼンスサーバ１００は許可時ルールに基づいて設定情報からプレゼンスデータを生成する（Ｓ３１）。生成されたプレゼンスデータは、プレゼンティティＩＤと対応付けてプレゼンス管理テーブル２ｂに書き込まれる（Ｓ３２）。さらにプレゼンスサーバ１００は、新たなプレゼンスデータを通知するプレゼンス更新コマンドを、ウォッチャーに送信する。

（２）応答処理
図１４ｂは、プレゼンスサーバ１００’がプレゼンティティの応答に応じて行う処理の流れの一例を示すフローチャートである。
ステップＳ２０１：プレゼンスサーバ１００’は、プレゼンティティからの応答を待機し、応答を得るとステップＳ２０２に移行する。

ステップＳ２０２〜Ｓ２０３：プレゼンスサーバ１００’は、プレゼンティティから許可されたパブリッシャからの設定情報を含むエントリがある場合、許可されたエントリよりも古いエントリを、履歴テーブル９’から削除する（Ｓ２０２）。さらに、許可されたエントリの「設定許可」フィールドに“Ｙｅｓ”を設定する（Ｓ２０３）。
ステップＳ２０４：プレゼンスサーバ１００’は、拒否されたパブリッシャからの設定情報を含むエントリを、履歴テーブル９’から削除する。

ステップＳ２０５：プレゼンスサーバ１００’は、履歴テーブル９’に残ったエントリのうち、最新の許可エントリの「状態」フィールドに“設定中”を設定し、このエントリをカレントエントリとする。それ以外のエントリの「状態」フィールドには、“待避中”が設定される。またプレゼンスサーバ１００’は、カレントエントリの設定情報に基づいてプレゼンスデータを生成し、プレゼンス管理テーブル７ｂに書き込む。言い換えれば、プレゼンスサーバ１００は、プレゼンスデータを仮情報設定前の状態に戻す。

ステップＳ２０６：プレゼンスサーバ１００’は、応答に応じ、許可リストＤＢ８内の許可リスト８ａや拒否リスト８ｂを更新する。
以上の処理により、プレゼンティティが認識していないパブリッシャからのプレゼンス設定コマンドを複数回分まとめて、プレゼンティティが許可または拒否の設定をすることができる。従って、プレゼンス設定コマンド受信毎に設定する場合に比して、プレゼンティティの設定負担が軽減する利点がある。また、プレゼンスサーバ１００’からの問い合わせの頻度が減少するので、ネットワーク負荷も軽減される。

＜その他の実施形態＞
（Ａ）前記第１実施形態や第２実施形態では、プレゼンティティに対してパブリッシャによるプレゼンスデータの更新を許可するか否かの問い合わせを送信している。しかし、問い合わせの送信は、必ずしも必須ではない。例えば、プレゼンティティから任意のタイミングで許可／拒否の設定を受け付けることもできる。この場合、問い合わせ部６は、プレゼンティティからの要求に応じて前記図９に例示する設定画面をプレゼンティティに送信する。設定画面上には、履歴テーブル９上で「問い合わせ実行」フィールドが“Ｎｏ”になっているエントリに含まれるパブリッシャＩＤが表示される。設定画面は、各パブリッシャＩＤに対する処理内容や時間条件の設定を受け付ける。

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

前記コンピュータプログラムは、前記記録媒体に記録されたものに限られず、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク等を経由して伝送されるものであってもよい。
＜付記＞
（付記１）
複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理装置であって、
各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段と、
各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段と、
任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段と、
前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段と、
前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段と、
更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段と、
を有する状態管理装置。

（付記２）
前記状態記憶手段に記憶されている状態情報の更新が許可または拒否されているクライアントである認識クライアントを、クライアント毎に対応付けて記憶する許可リスト記憶手段をさらに有し、
前記変化通知手段は、前記設定クライアントが前記認識クライアントに含まれているか否かを判断し、含まれていない場合に前記変化通知を送信する、
付記1に記載の状態管理装置。

（付記３）
参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶するバディリスト記憶手段をさらに有し、
前記変化通知手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記変化通知を送信する、
付記２に記載の状態管理装置。

（付記４）
参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶するバディリスト記憶手段と、
前記設定クライアントによる状態情報の更新を許可するか否かの問い合わせを、前記対象クライアントに送信する問い合わせ手段と、をさらに有し、
前記問い合わせ手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記問い合わせを送信する、
付記２に記載の状態管理装置。

（付記５）
前記設定受付手段は、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を受け付けた場合、前記設定クライアントと、前記対象クライアントと、前記更新許可または更新拒否と、を対応付けて前記許可リスト記憶手段に書き込む、付記２に記載の状態管理装置。

（付記６）
前記設定クライアントから受信した状態情報を加工する加工ルールを、前記対象クライアントと対応付けて記憶する加工ルール記憶手段をさらに有し、
前記変化通知手段は、前記設定クライアントから受信した状態情報を、前記加工ルールに基づいて加工して仮情報を生成し、前記仮情報を含む変化通知を送信する、付記１に記載の状態管理装置。

（付記７）
前記設定受付手段が、前記設定クライアントによる状態情報の更新許可の設定を受け付けた場合、前記対象クライアントに対応付けられている前記状態情報よりも以前の状態情報を、前記履歴情報から削除する、付記１に記載の状態管理装置。
（付記８）
前記設定受付手段が、前記設定クライアントによる状態情報の更新拒否の設定を受け付けた場合、前記設定クライアントからの状態情報を前記履歴情報から削除する、付記１に記載の状態管理装置。

（付記９）
複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理プログラムであって、
各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段、
各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段、
任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段、
前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段、
前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段、及び
更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段、
としてコンピュータを機能させる状態管理プログラム。

（付記１０）
複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理方法であって、
各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶ステップと、
各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶ステップと、
任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新ステップと、
前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知ステップと、
前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付ステップと、
更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶ステップで記憶されている前記対象クライアントの状態情報を更新する更新ステップと、
を有する状態管理方法。

（付記１１）
複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段、
各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段、
任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段、
前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段、
前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段、及び
更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段、
としてコンピュータを機能させる状態管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。

本発明は、状態管理システムに広く適用可能である。

プレゼンスサーバの機能構成の一例を示すブロック図 図１のプレゼンスサーバを含む状態管理システムで実行される処理の流れの概要を示す説明図 バディリストの概念説明図 プレゼンス管理テーブルの概念説明図 （ａ）初期状態の許可リストの概念説明図（ｂ）更新後の許可リストの概念説明図 （ａ）初期状態の拒否リストの概念説明図（ｂ）更新後の拒否リストの概念説明図 初期状態の履歴テーブルの概念説明図 パブリッシャ“Sensor4”からのプレゼンス設定コマンド受信後の履歴テーブルの概念説明図 仮設定可能な場合の履歴テーブルの概念説明図 パブリッシャ“Sensor4”によるプレゼンスデータの設定が許可された場合の履歴テーブルの概念説明図 パブリッシャ“Sensor4”によるプレゼンスデータの設定が拒否された場合の履歴テーブルの概念説明図 加工ルールテーブルの概念説明図 図１のプレゼンスサーバがプレゼンティティに送信する設定画面の一例 図１のプレゼンスサーバが実行するメインルーチンの流れの一例を示すフローチャート 図１のプレゼンスサーバが実行する応答処理の流れの一例を示すフローチャート 第２実施形態に係るプレゼンスサーバの機能構成を示すブロック図 図１１のプレゼンスサーバが有する問い合わせ条件テーブルの概念説明図 初期状態の履歴テーブルの概念説明図 １回目のプレゼンス設定コマンドを受信した後の履歴テーブルの概念説明図 ４回目のプレゼンス設定コマンドを受信した後の履歴テーブルの概念説明図 ５回目のプレゼンス設定コマンドを受信した直後の履歴テーブルの概念説明図 問い合わせ送信後の履歴テーブルの概念説明図 問い合わせに対する応答受信後の履歴テーブルの概念説明図 問い合わせに対する別の応答受信後の履歴テーブルの概念説明図 問い合わせに対するさらに別の応答受信後の履歴テーブルの概念説明図 図１１のプレゼンスサーバが実行するメインルーチンの流れの一例を示すフローチャート 図１１のプレゼンスサーバが実行する応答処理の流れの一例を示すフローチャート

符号の説明

１００：プレゼンスサーバ
２：プレゼンス管理部
３：プレゼンス通知部
４：履歴管理部
５：仮設定判断部
６：問い合わせ部
７：加工部
８：許可リストＤＢ
９：履歴テーブル
１０：加工ルールテーブル

Claims (10)

1. 複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理装置であって、
   各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段と、
   各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段と、
   任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段と、
   前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段と、
   前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段と、
   更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段と、
   を有する状態管理装置。
2. 前記状態記憶手段に記憶されている状態情報の更新が許可または拒否されているクライアントである認識クライアントを、クライアント毎に対応付けて記憶する許可リスト記憶手段をさらに有し、
   前記変化通知手段は、前記設定クライアントが前記認識クライアントに含まれているか否かを判断し、含まれていない場合に前記変化通知を送信する、
   請求項1に記載の状態管理装置。
3. 参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶するバディリスト記憶手段をさらに有し、
   前記変化通知手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記変化通知を送信する、
   請求項２に記載の状態管理装置。
4. 参照クライアントにより状態情報が参照されている被参照クライアントを、各参照クライアントと対応付けて記憶するバディリスト記憶手段と、
   前記設定クライアントによる状態情報の更新を許可するか否かの問い合わせを、前記対象クライアントに送信する問い合わせ手段と、をさらに有し、
   前記問い合わせ手段は、前記対象クライアントが状態情報を参照している被参照クライアントの認識クライアントと前記設定クライアントとを比較し、比較結果に基づいて前記問い合わせを送信する、
   請求項２に記載の状態管理装置。
5. 前記設定受付手段は、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を受け付けた場合、前記設定クライアントと、前記対象クライアントと、前記更新許可または更新拒否と、を対応付けて前記許可リスト記憶手段に書き込む、請求項２に記載の状態管理装置。
6. 前記設定クライアントから受信した状態情報を加工する加工ルールを、前記対象クライアントと対応付けて記憶する加工ルール記憶手段をさらに有し、
   前記変化通知手段は、前記設定クライアントから受信した状態情報を、前記加工ルールに基づいて加工して仮情報を生成し、前記仮情報を含む変化通知を送信する、請求項１に記載の状態管理装置。
7. 前記設定受付手段が、前記設定クライアントによる状態情報の更新許可の設定を受け付けた場合、前記対象クライアントに対応付けられている前記状態情報よりも以前の状態情報を、前記履歴情報から削除する、請求項１に記載の状態管理装置。
8. 前記設定受付手段が、前記設定クライアントによる状態情報の更新拒否の設定を受け付けた場合、前記設定クライアントからの状態情報を前記履歴情報から削除する、請求項１に記載の状態管理装置。
9. 複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理プログラムであって、
   各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶手段、
   各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶手段、
   任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新手段、
   前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知手段、
   前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付手段、及び
   更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶手段に記憶されている前記対象クライアントの状態情報を更新する更新手段、
   としてコンピュータを機能させる状態管理プログラム。
10. 複数のクライアントにネットワークを介して接続され、各クライアントの状態情報をその状態情報を参照している参照クライアントに送信する状態管理方法であって、
    各クライアントの最新の状態情報を、クライアント毎に記憶する状態記憶ステップと、
    各クライアントの状態情報を含む履歴情報を、クライアント毎に記憶する履歴記憶ステップと、
    任意のクライアントである対象クライアントの状態情報を、前記対象クライアントと異なるクライアントである設定クライアントから受信し、前記履歴情報に追加する履歴更新ステップと、
    前記状態情報の受信に応じ、前記対象クライアントの状態情報に変化が生じたことを示す変化通知を、前記対象クライアントの状態情報を参照している参照クライアントに送信する変化通知ステップと、
    前記変化通知の送信後に、前記設定クライアントによる状態情報の更新許可または更新拒否の設定を前記対象クライアントから受け付け、記憶する設定受付ステップと、
    更新許可の設定を受け付けた場合、前記設定クライアントから受信した状態情報に基づいて、前記状態記憶ステップで記憶されている前記対象クライアントの状態情報を更新する更新ステップと、
    を有する状態管理方法。

Images