"複数の端末の状態情報を管理するサーバを備えた状態情報管理システムであって、上記サーバは、上記状態情報と、上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つとを対応付けて格納する記憶部と、上記複数の端末のうちの第1の端末から状態情報公開要求を受信する受信部と、上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、上記記憶部に格納された情報のうちの上記状態情報抽出条件に合致する一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つを上記第1の端末に送信する送信部とを有し、上記送信部は、上記状態情報抽出条件に合致する他の上記端末が増加または減少した場合には、上記増加または減少を反映した一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つをあらためて上記状態情報公開要求に対する応答として上記第1の端末に送信することを特徴とする状態情報管理システム。請求項1に記載の状態情報管理システムであって、上記状態情報抽出条件は、状態情報の少なくとも一部を指定したものであり、上記送信部は、上記状態情報抽出条件で指定された状態情報と合致する状態情報を有する上記他の端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報を上記第1の端末に送信することを特徴とする状態情報管理システム。複数の端末の状態情報を管理する状態情報管理サーバであって、上記状態情報と、上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つとを対応付けて格納する記憶部と、上記複数の端末のうちの第1の端末から状態情報公開要求を受信する受信部と、上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、上記記憶部に格納された状態情報のうちの上記状態情報抽出条件に合致する一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つを上記第1の端末に送信する送信部とを有し、上記送信部は、上記状態情報抽出条件に合致する他の上記端末が増加または減少した場合には、上記増加または減少を反映した一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つをあらためて上記状態情報公開要求に対する応答として上記第1の端末に送信することを特徴とする状態情報管理サーバ。請求項3に記載の状態情報管理サーバであって、上記状態情報抽出条件は、状態情報の少なくとも一部を指定したものであり、上記送信部は、上記状態情報抽出条件で指定された状態情報と合致する状態情報を有する上記他の端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報を上記第1の端末に送信することを特徴とする状態情報管理サーバ。複数の端末の状態情報を管理する状態情報管理方法であって、上記複数の端末のうちの第1の端末から状態情報公開要求を受信するステップと、上記状態情報公開要求から状態情報抽出条件を抽出するステップと、上記状態情報抽出条件に合致する一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つを上記第1の端末に送信するステップと、上記状態情報抽出条件に合致する他の上記端末が増加または減少した場合には、上記増加または減少を反映した一または複数の他の上記端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報のうちの少なくともいずれか一つをあらためて上記状態情報公開要求に対する応答として上記第1の端末に送信するステップと、を有することを特徴とする状態情報管理方法。請求項5に記載の状態情報管理方法であって、上記状態情報抽出条件は、状態情報の少なくとも一部を指定したものであり、上記状態情報抽出条件で指定された状態情報と合致する状態情報を有する上記他の端末を示す情報、上記端末のユーザを示す情報、または上記端末もしくは上記端末のユーザが属するグループを示す情報を上記第1の端末に送信することを特徴とする状態情報管理方法。背景技術で述べたユーザIDを指定したサブスクライブ方法,グループIDを指定して所属ユーザのプレゼンス情報を一括取得するサブスクライブ方法,どちらを利用しても,サブスクライブするユーザはサブスクライブする対象のIDを明示的に指定してプレゼンス情報の通知を希望するサブスクライブメッセージを送信する必要がある。この方法では予め自分がサブスクライブしたい相手ユーザのIDやグループIDを把握することが必須となる。とりあえずテンポラリにプレゼンスを参照したい場合,サブスクライブ対象を短時間で変化させるようなプレゼンス情報通信モデルを考た時,相手のIDやグループIDを把握する負担により,本方式でのサブスクライブでは実現することが困難となる。例えば,出席した会議で初めて会った会議メンバのプレゼンス情報をとりあえずテンポラリに知りたい場合,参加中の会議室名は分からないが,その場所にいるユーザの状態が知りたい場合,自分が現在テンポラリで座っている机の周囲の人のプレゼンス情報を知りたい場合が挙げられる。この様な状態で毎回相手のIDを聞く,現在自分がテンポラリに所属しているグループIDを調べることはユーザビリティの低下を招く。サブスクライブメッセージを相手のIDやグループIDを指定して送信するのではなく,条件対象となるプレゼンス情報のある項目とその項目に対する条件を指定して行う。例えばあるユーザが現在位置のプレゼンス情報が同一である事を条件としてサブスクライブを行う。この時,サブスクライブを行ったユーザの現在位置プレゼンス情報が201会議室であった場合,同じく現在位置プレゼンスが201会議室である他ユーザに対して自動的にサブスクライブが行われ,プレゼンス情報の通知を受けることができる。その後,サブスクライブを行っているユーザの現在位置プレゼンス情報が502実験室に変化すると,現在位置が201会議室であったときにプレゼンス情報閲覧していたメンバへのサブスクライブは自動的に解除され,現在位置が502実験室であるメンバに対するサブスクライブが自動的に開始する。また,サブスクライブされる側のユーザは他のユーザからのサブスクライブに対してプレゼンス情報を公開するか否か、あるいはどこまで公開するか等を設定しておき,必要以上のプレゼンス情報が他のユーザに知られないようにガードする。各ユーザはサブスクライブを行う時に相手ユーザ,またはグループのIDを明示的指定する必要がなくなる。これによりサブスクライブ対象のIDを入手する手間の解消によるユーザビリティ向上する。また,自分のプレゼンス情報の変化に応じてサブスクライブ対象となるユーザが自動的に変化するので,サブスクライブ対象を変化させる際にメッセージ数が削減される。本実施例では、まず,プレゼンス情報を送受信するサーバの論理的構造,物理的構造、動作概要、及びそのサーバを用いたサービスを実現するためのネットワーク概要について説明する。その後,サーバ内部で保持するデータ例,フローチャート例を用いて本願発明装置の処理を説明する。図1には,本実施例のプレゼンス情報を送受信するサーバの機能ブロック図を示した。図1の機能ブロック図は,ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。図2には、図1に示した機能ブロックが、ハードウェア上、どのように実現されているかを示した。図1に示した種々の機能ブロックの動作は、図2に示すメモリ22の処理モジュール群26に収納されており,動作時にはCPU23がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な情報は、データベース31及びメモリ22上のテンポラリメモリテーブル24に格納されており必要に応じて読み出し,書き込みが行われる。その際,データベース31に格納されたデータの読み出し,書き込み処理はインタフェース30とテーブル情報入出力部37を経由して行われる。なお,データベース31とサーバ1は物理的に異なる装置で構成することも可能であるし,同一装置内部に論理的に構成することも可能である。まずは,図1,図2に示したプレゼンス情報の送受信機能を有するサーバ1を用いて各ユーザがどのようなことを行えるかについての概要を図3の動作概念図を用いて説明する。図3では45に示したユーザがサブスクライブ条件対象となるプレゼンス項目を41に示すようにlocationに,その条件を42の様にsameに設定しサーバ1に対してサブスクライブを行っている状態である。この時45に示すユーザがもし会議室43に現在滞在しており,自分のプレゼンス情報locationを46-1のように会議室と登録していた場合,サーバ1は現在同じ場所に滞在し,プレゼンス情報locationが同じ会議室である51に示すA,52に示すB,53に示すFを471の様にサブスクライブ対象と自動的に認識し,45に示すユーザはA,B,Fのプレゼンス情報を取得することができる。その後,45に示すユーザが居室44に移動したとする。そして45に示すユーザはプレゼンス情報locationを462のように居室に更新する。するとサーバ1はプレゼンス情報の更新を契機に471のサブスクライブ対象を一旦破棄,さらに現在同じ場所に滞在し,プレゼンス情報locationが同じ居室である54に示すC,55に示すG,56に示すD,57に示すEを472の様にサブスクライブ対象と自動的に新たに認識し,45に示すユーザはC,G,DEのプレゼンス情報を取得することができるようになる。つまり,45に示すユーザがサーバ1に対して一度サブスクライブを希望するメッセージを送信すると,ユーザ本人の状態変化に応じてサーバ1がサブスクライブ対象を471から472の様に自動的に変更する。この処理によりサブスクライブを行っているユーザは明示的にサブスクライブ対象を変更することなく,場合に応じた相手に対するサブスクライブを開始することが可能となる。また,逆に場合に応じて必要なくなった相手へのサブスクライブを明示的に宣言することなく終了することが可能となる。次に,上記概要の詳細な動作内容の例を図1のモジュール図,図2の物理的ハードウェア図,図4のネットワーク図,図5のシーケンス図,図6~8のメッセージ例,図9~図14のテーブル図,図16~20のフローチャート図を用いて説明する。但し,これら説明で記述する具体的な送受信メッセージ内容,シーケンス,テーブル構成,ソフトウェアのモジュール構成,ハードウェア構成,処理フローチャートは一例であり,目的の動作を実現することで発明の効果を奏することが可能な限り,別な方法及び構成を用いて実現しても構わない。図4は本願発明を用いたサービス例のネットワーク図である。このネットワーク上では61に示すUserA,62に示すUserB,63に示すUserCの3ユーザがそれぞれ無線アクセス網1061,有線アクセス網1062,IPNetwork1063を経由して通信事業者1064が所有するプレゼンス送受信サーバ1にアクセスし,他ユーザのプレゼンス情報を閲覧している,つまり他ユーザに対してサブスクライブしている状態である。各端末は通信事業者1064が所有する認証サーバ68やSIPサーバ69を利用している可能性もある。また,UserAは利用端末に64に示す情報端末の他に65に示すセンシングデバイスを用いているとする。センシングデバイスとはRFIDの様な小型のタグや自らが現在位置を発信することが可能なGPS付携帯電話の様に何らかの方法で自分の位置情報をサーバに登録することが可能な装置のことである。センシングデバイスを用いることでユーザの現在位置を1065に示すような受信機を用いて無線経由でシステムに通知することが可能となる。本例ではUserAは第2の端末としてセンシングデバイスを用いているが,本端末には他のデバイスや端末,アプリケーションを用いることも考えられるし,UserAが複数端末を利用せず,64の情報端末のみ用いている場合も考えられる。図5は図4の動作シーケンス図である。このシーケンスを順番に説明することで詳細な動作の流れを説明する。なお,図4のシーケンス開始時,各ユーザのプレゼンス情報の初期値は70の表に示した値であり,UserB,UserCは既にサーバ1に対するログイン処理を終了し,本願発明の条件指定型のサブスクライブを開始しているものとする。また,UserB,UserCが行っている条件指定型サブスクライブのサブスクライブ条件はUserAが行う条件指定型サブスクライブのサブスクライブ条件であるプレゼンス情報locationがsameとう条件と同様とする。まず61に示すUserAは端末64を用いてステップ71でプレゼンス情報送受信サーバ1にログインする。ログイン後,ステップ72で条件を指定したプレゼンス情報要求を送信する。つまり,本願発明の条件指定型サブスクライブを開始する。その時のメッセージ例を図6に示す。図6はサブスクライブがSIPで行われている場合のメッセージ例である。UserAはサブスクライブ対象を示すリクエストライン101,Toヘッダ102にはサブスクライブ対象となる相手ユーザやグループのSIPURIを示さずに自分のSIPURIを示している。リクエストライン,Toヘッダは,SIPメッセージの転送規定上,必ず記述する必要があるが本例で示した自分のSIPURIの様に,SIPメッセージがサーバ1に転送されるSIPURIならばどのような値でも構わない。また,サブスクライブの条件をContactヘッダ内部のURIパラメータ103に記述している。サブスクライブ条件の記述はこの様に既存ヘッダ内部にURIパラメータの形で拡張して記述する方法の他に,104の様に独自拡張ヘッダに記述する方式,105の様にSIPメッセージボディ部に記述する形を取ってもよい。条件は記述場所は問わないが,サーバ1がサブスクライブ条件からサブスクライブ対象を特定する為に最低1つは記述する必要がある。また,条件を複数記述することで複数の条件にマッチする対象を検索することが可能となる。サーバ1が64に示すUserAの端末が送信したサブスクライブ要求を受信した後に行う処理フローチャートを示した図が図16,図17である。図16,17を用いてサーバ1の処理手順について説明する。サーバ1は図16のステップ191でサブスクライブ要求を図1のプレゼンス情報取得要求モジュール13で受信するとステップ192でサブスクライブメッセージを解析し,サブスクライバと条件を抽出する。サブスクライバとは他ユーザのプレゼンス情報の取得を要求するユーザのことで,本例ではプレゼンス情報要求を送信したユーザのことである。本処理はプレゼンス情報取得要求解析モジュール12で行う。また,ステップ192ではこれら解析した情報をプレゼンス情報,サブスクライブ情報管理機能2に送信する。送信された情報はステップ193にてサブスクライブ状態管理モジュール7で処理される。サブスクライブ状態管理モジュール7はサブスクライブの開始,終了等のサブスクライブ状態や各サブスクライブの条件を図2に示すサブスクライブ管理テーブル25を用いて管理するモジュールである。サブスクライブ管理テーブルの詳細な内容を図9に示す。サブスクライブ状態管理モジュールはプレゼンス情報取得要求解析モジュールから送信された情報を元に図9のテーブル121内の122に示すサブスクライバ,及び124に示す条件1にサブスクライブ条件を登録する。サブスクライブ条件が複数存在する場合は125以降に条件を書き込む。サブスクライブ登録処理を完了したサーバ1は次にステップ194において,サブスクライブをしてきたUserAに対して現在サブスクライブ条件にマッチしているユーザ,及びそれらユーザのプレゼンス情報を通知する為に,UserAが指定したサブスクライブ条件に現時点でマッチしている他ユーザを検索する。本処理は図1に示すサブスクライブ対象管理モジュール6で行われる。サブスクライブ対象管理モジュール6は図2の条件付サブスクライブ管理テーブル25に記述された条件を元にIF30,データベース31のテーブル情報入出力部37を経由してプレゼンス情報管理テーブル34からサブスクライブ条件にマッチするユーザを検索する。プレゼンス情報管理テーブル34には具体的には各ユーザの現在のプレゼンス情報の一覧が記録されているので,サブスクライブ条件に合ったプレゼンス情報を登録しているユーザを検索すればよい。これにより、サブスクライブの際にユーザ名やグループ名を指定しなくても、条件にマッチしたユーザのプレゼンス情報を閲覧することができる。その後,ステップ195で条件にマッチしたユーザがいなかった場合,ステップ196から201までの処理を行う必要がないので,ステップ202まで進み,図17のステップ212,213,214の処理にてマッチしたユーザがいなかったことをサブスクライバに通知してステップ215にて処理が終了する。ステップ195で条件にマッチしたユーザがいることを確認した場合,ステップ196にて公開プレゼンス制御モジュール8でデータベース31のパーミッション情報管理テーブル32を検索する。これは、もしユーザがサブスクライバに対して自分のプレゼンス情報を公開しないという設定を行っていた場合には、当該ユーザのプレゼンス情報がサブスクライバの指定した条件にマッチしたとしても、条件にマッチしたことをサブスクライバには告げないという制御を行うためである。この制御を行うことによって、非公開設定をしているユーザのプレゼンス情報が条件にマッチしたことをサブスクライバに告げてしまう、つまり暗にプレゼンス情報を公開してしまうことを防止することができる。パーミッション情報管理テーブルは図14のテーブル171様な構成となっており,173に示すアクセス対象ユーザが172に示すアクセスユーザに対してどのようなプレゼンス情報を公開するかについてパーミッション情報174に記述されている。このパーミッションについては特願2004-108642のマルチレベルパーミッション機能を用いて設定された内容を用いてもよい。パーミッション情報管理テーブル32を検索した後,ステップ197で条件とマッチし、プレゼンス情報がサブスクライバに対して公開となっていた場合にのみ,そのユーザをステップ198にて図2のメモリ22上にあるサブスクライブ対象管理テーブル27に登録する。図10の131はサブスクライブ対象管理テーブル27のテーブル構成例である。サブスクライブ対象管理モジュール6はこのテーブル131のサブスクライブ番号132に図9のテーブル121サブスクライブ管理番号123に記述したサブスクライバのサブスクライブ管理番号を,サブスクライブ対象ユーザ133のカラムにマッチしたユーザ名をペアで書き込み,現在どの番号のサブスクライブがどのユーザと条件がマッチして,プレゼンス情報を閲覧中であるかを管理する。ステップ197でプレゼンス情報を非公開と設定されていた場合はステップ198,199の処理をスキップしてそのユーザを条件に合致したユーザとは認識しない。非公開設定とは設定したユーザがサブスクライバに対して自分の存在を知らせたくないことを意味する。ここでサブスクライバに通知を行わないことで,非公開設定を行ったユーザの存在を隠すことが可能となる。ステップ198でサブスクライブ対象ユーザを登録した後,そのユーザのプレゼンス情報をサブスクライバに対して送信するメッセージを作成する分けだが,この時,通知しても良いプレゼンス情報をステップ199にて公開するプレゼンス情報をフィルタリングすることで確認する。この処理は図1の公開プレゼンス制御モジュール8で行い,データベース31のパーミッション情報管理テーブル32,プレゼンス情報公開ポリシ管理テーブル33,テンプレート管理テーブル35を検索して通知するプレゼンス情報を決定する。公開プレゼンス制御モジュール8はまずポリシ管理テーブル33を検索する。ポリシ管理テーブルの詳細は図12に示すテーブル151となる。このテーブルではまず,UserAが登録しているプレゼンス情報を確認して,153,155等のプレゼンス項目,及び154,156等のプレゼンス値がUserAのプレゼンス値と一致するレコードを検索する。各レコードでは複数のプレゼンス項目を指定可能であるので,場合によっては複数レコードが条件にマッチする可能性がある。例えば,レコード157と158がそのような例で,本例ではUserAの初期プレゼンス値がlocationが会議室でsectionが設計部であることより,レコード157,158両方にマッチする。この場合,条件指定が詳細なレコードを優先する。本例ではレコード157の方が条件とするプレゼンス項目の数が多く,詳細な条件となっているのでレコード157にマッチしたとみなす。このマッチ処理の優先順位については本例の方法以外の方法で実現してもよい。本例ではレコード157にマッチしたとみなしたので,レコード157の割り当てテンプレート152を確認する。本例ではAと記述してあるが,この値はテンプレート管理テーブル35で管理しているテンプレート値である。テンプレート管理テーブル35の詳細なテーブル構成を図13のテーブル161に示す。このテーブルではテンプレート名称162がAであるレコードでは公開プレゼンス163,164,165の値がlocation,comment,materialと指定されている。つまり,これら3つのプレゼンスが公開されるという意味である。結果,UserAがlocation会議室,section設計部のプレゼンスを持ちサブスクライブを行っている場合,マッチした他ユーザのlocation,comment,materialのプレゼンス項目を参照することが可能という事である。本例では図12の割り当てテンプレート152には1つのテンプレートを割当てているが,これを複数割当てることも可能である。この様にサーバ1はUserAのプレゼンス情報の値により条件マッチユーザのどのプレゼンス情報を閲覧可能であるかを判断する。なお,本処理により公開すると判断されたプレゼンス情報でもパーミッション情報管理テーブル32で個別設定でプレゼンス情報を非公開とすると設定されていた場合,そちらの情報を優先し,プレゼンス情報を非公開とする。プレゼンス情報公開ポリシ管理テーブル33,テンプレート管理テーブル35はシステムの管理者が設定する。一方,パーミッション情報管理テーブル32は各ユーザが自分の登録したプレゼンス情報に対して自分のプライバシを保護する為に設定する。よってたとえシステム管理者が公開と設定したプレゼンス情報でも個々人が自分のプライバシを守るために行った設定が非公開で合った場合,個々人の意思を尊重してそのプレゼンス情報は非公開とサーバ1は判断する。このように個々人が設定可能なフィルタ機能を最優先にしてサブスクライバへの公開ポリシを決定することで,各ユーザが個人的に持つ公開ポリシに沿ってプライバシの保護を行うことが可能となる。ステップ199でプレゼンス情報のフィルタリングを行った後,ステップ200で公開可能なプレゼンス情報について通知メッセージを作成し,テンポラリメモリテーブルに保存しておき,送信準備を行う。これら処理が終了した後,ステップ201にて全条件マッチユーザの処理が終了していなかった場合,次のユーザについて再度ステップ196から処理を行い,全てのマッチしたユーザについての処理が終了するまで繰り返し処理を行う。全マッチユーザについての処理が終了した場合,図17のステップ212にてテンポラリメモリテーブルに登録してあった全マッチユーザのメッセージを取得し,ステップ213にて全メッセージを合成し,サブスクライバへの通知メッセージを作成する。本処理は図1のプレゼンス情報分析構築モジュール10で行う。その後,ステップ214にてプレゼンス情報更新通知送信モジュール14から図5のステップ74で送信する。その時の送信メッセージ例を図7及び図8に示す。この例ではプレゼンス情報の通知にSIPのNOTIFYメッセージを利用しているが,同様の機能を満足できれば他のプロトコルを用いてもよい。図7の111に示す部分がSIPメッセージヘッダ部であり,113,114に示す部分がSIPメッセージボディ部である。SIPメッセージヘッダ部にはメッセージの送信元を示すFromヘッダ112があるが,そこには送信元ユーザやグループのSIPURIではなく,UserA自身のSIPURIが記述されている。この部分はUserAのSIPURIである必要はなく,どのような値でも構わない。また,113,114はプレゼンス情報の内容を示すSIPボディ部分であるが,この部分はdraftietfsimpleeventlist06txtで規定されたフォーマットに従って記述されている。113に示す部分はこの通知メッセージにプレゼンス情報を記述しているメンバ一覧,つまり先ほどのサブスクライブ対象管理モジュール6でマッチしたユーザ一覧を記述している。図8の114には各ユーザのプレゼンス情報の内容を記述している。この例ではプレゼンス情報の記述をdraftietfsimpleeventlist06txtの規定に従い記述しているが,その他の方法でプレゼンス情報を記述しても構わない。次にサーバ1はシーケンス図のステップ75でサブスクライブを行ったUserAに対して他のユーザのサブスクライブに対して自分のプレゼンス情報をどれだけ公開するかについての問い合わせを送信する。問合せを行うことにより,サーバ1はプレゼンス情報を公開するユーザの情報公開ポリシを確認することが可能となる。この問い合わせはUserAのプレゼンス情報が更新され、マッチング対象が変化する度に送信される。UserAはプレゼンス情報の内容によって公開ポリシを変更したい可能性がある。この様な場合にプレゼンス情報の更新毎に問合せを行うことで,サーバ1はUserAの公開ポリシの細かな変化を知ることができる。この問い合わせによりUserAは例えば、会議室でなら持込資料やコメントまで見せてもよいが、自席に座っているときは見せたくないを判断し、公開プレゼンス情報を変化させることができる。先ほどステップ74でUserAが条件にマッチしたユーザのプレゼンス情報を受信したときはマッチした他ユーザは自分のプレゼンス情報locationを会議室に変更した際にすでにステップ75のような問い合わせを受けており、それに対して公開を許可する応答をしていたからUserAにプレゼンス情報が送信されている。この問い合わせを受けてUserAがステップ76でプレゼンス情報の公開を許可する応答を行った場合、サーバ1はUserCに対してUserAが条件にマッチした通知をステップ77で送信する。しかし、UserAがプレゼンス情報の公開を拒否する応答をステップ76で送信した場合、ステップ77のメッセージは通知されない。通知しないことで,公開を拒否したUserAの情報が流出することを防止できる。なお、ステップ76でプレゼンス情報の公開を許可する応答をUserAが行った場合、本例ではUserA自身にもUserAが条件にマッチしたことをステップ78にて通知しているが、本処理は行っても行わなくてもよく、システム毎に送信可否のポリシを決定すればよい。さらにステップ75から78の部分についてもシステム単位で実行可否のポリシを決定し、必要がない場合は行わなくてもよい。もし、このステップ群を行わなかった場合、UserAのプレゼンス情報はUserAが事前に設定したパーミッション情報、及びシステム管理者が設定した図2のデータベース31にあるプレゼンス情報公開ポリシ管理テーブル33の設定に従いUserCに通知される。通知処理の方法については後述するUserAがプレゼンス情報を更新した場合の処理フローチャートに従う。その後、UserAがステップ79で自分のプレゼンス情報locationを会議室から居室に変更したとする。このときサーバ1はプレゼンス情報の更新に伴うサブスクライブマッチユーザの変更を確認するための処理を行うが、その内容について詳細説明する。図18、図19は上記処理のフローチャート図である。サーバ1は図18のステップ231において図1のプレゼンス情報送受信モジュール11でプレゼンス情報更新メッセージを受信し、さらにプレゼンス情報分析構築モジュール10で登録するプレゼンス情報を抽出した後、プレゼンス情報管理モジュール9で各種情報入力モジュール4を経由し、IF30からデータベース31のプレゼンス情報管理テーブル34のプレゼンス情報を更新する。その後、プレゼンス更新によるサブスクライブマッチユーザの更新処理を開始する。まず、サーバ1はステップ232において、図1のサブスクライブ対象管理モジュール6でメモリ22の条件付サブスクライブ管理テーブル25を検索し、プレゼンス更新ユーザが現在サブスクライブ中であるかどうかを確認する。次にステップ233においてもしサブスクライブ中でない場合はその後のステップ234から247の処理をスキップしてステップ248において次のステップに進む。もし、ステップ233においてサブスクライブ中であると判断した場合、次にステップ234においてそのサブスクライブの条件をメモリ22の条件つきサブスクライブ管理テーブル25を検索することにより、確認する。サブスクライブの条件には対象となるプレゼンス情報の項目とその値に関する条件等が記述されているが,次のステップ235で条件確認の結果、更新したプレゼンス情報の項目がサブスクライブ条件として指定したプレゼンス情報項目の一部に含まれていなかった場合はステップ236から247までの処理をスキップしてステップ248において次のステップに進む。本例ではUserAがサブスクライブ条件にプレゼンス情報の項目locationが自分と同じ値であることを指定している。そこでUserAがlocationを会議室から居室に変更したので,サーバ1は更新したプレゼンス情報の項目がサブスクライブの条件の一部に含まれていると判断する。本例のように自分のプレゼンス情報の値と相手のプレゼンス情報の値を比較する条件を提示している時に,更新プレゼンス情報の項目に条件としたプレゼンス情報の項目の一部が含まれていた場合,UserAがプレゼンス情報を更新することにより,UserAのサブスクライブ条件がlocationが会議室であることからlocationが居室であることへと条件事態が変化する。もし、ステップ235において、更新したプレゼンス情報の項目がサブスクライブの条件に含まれていると判断した場合、次にステップ236でメモリ22上のサブスクライブ対象管理テーブル27からこのサブスクライブに現在マッチしているユーザをすべて削除する。これはサブスクライバがプレゼンス情報を更新したことにより、条件にマッチするユーザが変更となるので、再度マッチング処理を行うためである。本例ではUserAが更新したプレゼンス情報locationがUserAのサブスクライブ条件に含まれているのでステップ236へと処理が進む。次からのステップ237からステップ247までの処理については、前述図16のステップ194から図17のステップ214までの処理フローチャートと同様である。ステップ247で送信したメッセージは図5に示すシーケンスのステップ74でUserAに送信される。次にサーバ1はステップ1252において図1のサブスクライブ対象管理モジュール6でメモリテーブル22上のサブスクライブ対象管理テーブル27を検索し、現在プレゼンス情報を更新したユーザに対してサブスクライブを行っている他ユーザを確認する。もしステップ1253でサブスクライブ中の他ユーザが存在しないと判断した場合、ステップ1254から1258までの処理をスキップし、ステップ1259から次のステップへと進む。もしステップ1253でサブスクライブ中の他ユーザが存在すると判断した場合、次に、ステップ1254でそのサブスクライブを行っている上記他ユーザのサブスクライブ条件をメモリ22上の条件付サブスクライブ管理テーブル25から確認する。その後、ステップ1255で更新されたUserAのプレゼンス情報が上記他ユーザのサブスクライブ条件にマッチしているかどうかを確認し、マッチしている場合はサブスクライブ対象の更新を行う必要がないので、ステップ1256、1257の処理をスキップし、ステップ1258へと進む。ステップ1255で更新されたUserAのプレゼンス情報が上記他ユーザのサブスクライブ条件にマッチしていなかった場合はステップ1256に進む。本例ではUserAがプレゼンス情報を更新した結果、UserCが行っているサブスクライブ条件にマッチしなくなったのでステップ1256に進む。ステップ1256ではプレゼンス対象管理モジュール6でメモリ22上のサブスクライブ対象管理テーブル27から対象サブスクライブのエントリを削除する。これはプレゼンス情報を更新したユーザの新しいプレゼンス情報が条件にマッチしなくなり、サブスクライブ対象から外れるためである。その後、ステップ1257でサブスクライブ条件マッチユーザが変更したことをサブスクライバである上記他ユーザに対して通知する。本例ではその結果、シーケンス図のステップ83でUserCに対してUserAが条件マッチユーザに含まれていないプレゼンス情報通知を行っている。次にステップ1258で全ユーザについての処理が終了していなかった場合、ステップ1254に戻り、他のユーザ分についての処理を再度行う。全ユーザについての処理が終了した場合、ステップ1259に進み次のステップ252の処理に入る。サーバ1は図20のステップ252において図1のサブスクライブ対象管理モジュール6でメモリテーブル22上の条件付サブスクライブ管理テーブル25を検索し、更新された新しいプレゼンス情報と現在サブスクライブされている他ユーザのサブスクライブ条件とのマッチングを行う。ステップ253で更新された新しいプレゼンス情報を対象とする条件付サブスクライブを行っている他ユーザが存在しなかった場合、ステップ254から261までの処理はスキップし、ステップ262にて処理を終了する。もし存在した場合はステップ254に進む。本例ではUserBが対象にする条件付サブスクライブを行っていたのでステップ254に処理が進む。ステップ254では条件内容とプレゼンス情報更新ユーザの更新後のプレゼンス情報を比較する。その後、ステップ255でサブスクライブ条件とプレゼンス情報更新ユーザの更新後のプレゼンス情報がマッチしなかった場合、ステップ256からステップ261までの処理をスキップしてステップ262で処理を終了する。マッチした場合はステップ256に処理が進む。本例ではUserBの条件にUserAの新しいプレゼンス情報がマッチしたので、ステップ256へと処理が進む。この条件マッチングを行うことで,UserAがプレゼンス情報を更新した結果他ユーザであるUserBのサブスクライブ条件にマッチしているユーザを更新することが可能となる。ステップ256からステップ259までの処理は図16のフローチャートで述べた図18のステップ239からステップ243と同様にパーミッション関係の処理である。パーミッションの処理が終わった後、プレゼンス情報を公開することを判断した場合に限り、ステップ260にてUserBに対して新規にマッチしたユーザを通知する。また、これらパーミッション処理はシーケンス図のステップ84のサーバ1からのプレゼンス情報公開要求メッセージとステップ85の返信メッセージ、その後のステップ87のメッセージも含む。この2つのステップの内容はシーケンス図の枠82と同様である。ステップ260の処理により、シーケンス図の78でサーバ1からUserBに対してメッセージが送信される。その後、ステップ261で全ユーザについての処理が終了していなかった場合、残りのユーザについての処理を行うためにステップ254に戻り再度処理を行う。全ユーザについての処理が終了していた場合、ステップ262に進み処理を終了する。その後、シーケンス図ではステップ79でUserAがプレゼンス情報locationを会議室から居室に変更し、そのことがUserCに通知されているが、この処理についてはシーケンス図のステップ79、83と同様である。このような動作で各ユーザはサーバ1に対して条件付サブスクライブを行い、互いのプレゼンス情報の変化に伴いサブスクライブ対象を変化しながら、条件にマッチした他ユーザのプレゼンス情報をシステム、さらに他ユーザ自身が公開を許可した情報を参照することが可能となる。この様にして,UserAはユーザIDやグループIDを指定せず,条件のみを指定したサブスクライブを行うことで,相手ユーザID,グループIDを知らなくてもサブスクライブ対象とすることが可能となる。さらに,UserAのプレゼンス情報の変化に伴い,サブスクライブ対象が変化した時,UserAは何も行うことなく,新規条件にマッチした他ユーザに対するサブスクライブを自動的に開始し,条件の変化によりサブスクライブ対象から外れた他ユーザのサブスクライブを自動的に解除することが可能となる。図21は本願発明の第2の実施例である。この例では273で示すAと272で示すBと271で示すCがそれぞれ異なるサブスクライブ条件274、275、276を条件としてサブスクライブを行っている。本例では条件に図3の様なsameではなく、○○m以内と範囲を指定している。このように条件に範囲を指定することで,条件にマッチしてサブスクライブの対象となるユーザに幅を持たせることが可能となる。それぞれのプレゼンス情報locationの値は277、278、279の値となっている。この時それぞれのユーザが指定するサブスクライブ条件が異なるため、サブスクライブ対象が非対称となっている。つまり280に示すようにCの条件にマッチしている他ユーザはおらず、Cは他ユーザのプレゼンス情報を閲覧していないのに対して、Bは281のようにCのプレゼンス情報を閲覧している。また、BとAについては281、282のように対称でサブスクライブを行っており、互いにプレゼンス情報を閲覧している。条件の指定の仕方によりこのような非対称な状態でのサブスクライブが発生する可能性がある。各ユーザは実施例1の様なシステム上で各自独立した条件を設定することが可能である。この仕組みを利用して各ユーザが別々のサブスクライブ条件をサーバに提示することでこの様な非対称なサブスクライブが実現する。図22は本願発明の第3の実施例である。この例では291に示すA、292に示すB、293に示すC,294に示すDの4人が条件付サブスクライブを行っており、それぞれの条件は295から302となっている。本例では各ユーザがサブスクライブ条件としてプレゼンス情報の値を指定するのではなく、自分のバディリストへ登録されていることを条件として指定している。この設定はサブスクライブを行う側が条件にマッチするユーザの範囲を限定している。このように各ユーザは自分がサブスクライブする時に自ら条件マッチの範囲を指定することができる。さらに、システム管理者がこのような範囲を設定することも可能である。各ユーザが自分がサブスクライブを行う時にこの様にマッチするユーザの範囲を限定するような条件を指定した場合もその条件内容は図9のテーブル121上の124等の条件カラムに記述される。管理者が設定した場合、各ユーザがサブスクライブした時、管理者が設定したユーザの範囲でしかマッチングが行われない。また、各ユーザがプレゼンス情報locationに対して設定している条件も図3の例の様に、sameではなく、±○○以内と範囲指定してもよい。この範囲指定について図23を用いて説明する。図23はプレゼンス情報locationについての値間の関連図である。このような設定を管理者がシステム内で設定しておくことで、値の範囲を定義することを可能とする。この例では例えば、338センタ街と337ハチ公前の間の距離は1と設定してある。このように考えると、例えば、333タイムズスクエアと334原宿の距離は3である。また、338センタ街と335西部前の距離は2、もしくは3と考えることができる。センタ街から西部前への距離計算パターンは2種類存在するからである、このような場合、短い距離を選択するか、長い距離を選択するかについてはシステム単位でどちらの選択を行ってもよい。本例では短い距離を選択する判断を行っている。この例ではプレゼンス情報に位置情報を用いているので、距離とは物理的な距離のことを指しているが、距離とは物理的な距離のみを指すわけではなく論理的な距離を指す言葉として定義することもできる。例えば、930に示すclassに距離を定義することも可能である。この場合の距離とは931に示す本部長、932に示すセンタ長を最上位に933に示す部長、その下に934に示す課長、935に示すユニットリーダなどの、組織図上の上下関係の近さを表す論理的な距離である。このように定義対象となるプレゼンス項目によっては、論理的な距離を定義することも可能である。図22に戻り、各ユーザの条件内容とマッチングユーザについて考える。図22で各ユーザの現在のプレゼンス情報は303から306であり、各ユーザのバディリスト登録ユーザは307から310である。291に示すAは311のようにlocationの条件範囲内にいるBのプレゼンス情報を閲覧している。CはAのバディリストに登録されているが、CのlocationがAの条件範囲内でないのでCはAのサブスクライブ条件にはマッチしていない。292に示すBはA,C,Dの3人がlocationの範囲内に入っているのだが、バディリストに登録しているユーザはA,Dのみなので312のようにこれら2人のプレゼンス情報のみを閲覧している。CはバディリストにAのみを登録しているが、Aはlocationの条件範囲内に入っていないので、サブスクライブ対象は313の様になしとなっている。Dはlocationの条件範囲内にBが存在するので314の様にBをサブスクライブ対象としている。この様にプレゼンス情報の値間に距離を定義することで,実施例3の地名の様な値間の具体的な距離が分からない概念的な値の間にも論理的な距離を定義して,サーバがサブスクライブの範囲を計算することを可能とする。図24は本願発明の第4の実施例のサービスイメージ図である。このサービスはバス停でバスを待っているユーザ372が375の様に自分が乗るべきバスの運行状況を確認するサービス、バス運行会社373が自社のバスの運行状況を確認するサービス、運行中のバスが374の様に先のバス停でバスを待っているユーザがいるかどうかを確認するサービスの3つを含んでいる。このサービスの具体的な内容を図25を用いて説明する。図25は図24のサービスの動作概念図である。本例では342に示すA、343に示すB、344に示すCがそれぞれバス停でバスを待っている。また、341に示すバスが現在運行中である。バスの行き先は353のdestinationに示すように国立であり、途中で経由するバス停はviaに示すように○○一丁目,○○大学,国立である。AとCが行きたいバス停は354、356のgoalに示すように国立、Bが行きたいバス停は355のgoalに示すように立川である。A,B,C、バスはサーバ1に対してそれぞれ345から352を条件にして条件指定型のサブスクライブを行っているものとする。また、バス停の間には図23の322から331に示すような形で値間の関係を設定しているものとする。この時Aは○○一丁目のバス停で待っており、さらに降りるバス停が国立である。341のバスは現在Aのひとつ手前のバス停におり、さらに行き先が国立であるので条件にマッチする。よってAのサブスクライブ対象には341に示すバスが含まれ、304の様に04系バス国立行きが一つ前のバス停を出発したことをAに通知される。Bは待っているバス停はAと同じだが、行き先が立川で341のバスが停車しないバス停であるのでBには341に示すバスの情報は通知されない。またCは行き先は国立であるが、バスとの距離が2であるため、locationの条件にマッチしないので、Cにも341のバスの情報は通知されない。なお、A,B,Cのユーザ間もlocationの範囲が1以内ではあるが各ユーザが2つ目の条件に指定しているviaの値についてお互いマッチしないのでユーザ間でのマッチングは発生しない。また、341に示すバスはlocationが±2以内かつ自分のviaに相手のgoalと同じ値があることを条件にサブスクライブを行っている。よってgoalの値を国立とバスのviaに存在する値で登録しているA,Cについての情報を得ることができ、その結果、357のように1つ先のバス停に乗車客一人がおり、2つ先のバス停に乗車客一人がいることをバス停に行くまでに事前に把握することが可能となる。location,via,goalの3つのプレゼンスはそれぞれそのプレゼンスが表す意味は異なるが,各ユーザの目的によってはこの様にそれぞれのプレゼンス情報の項目をマッチング条件に指定することでこの例の様に各ユーザの行きたい場所とそこまで輸送するバスが経由する場所をマッチングさせることで各ユーザの目的を達成することが可能となる。この様にバスの運行システムに応用した場合,各ユーザは道路状況により,到着時刻が変動しやすいバスの実際の運行状況をバス停で待ちながらにして知ることができる。さらにバス側では今まで各バス停で停車すべきかどうかをバス停で待っているユーザを目視で確認する必要があり,確実に確認が正しいとは限らなかったが,各バス停で待っているユーザを事前に知ることにより,各バス停での停車の必要性を確実に知ることができる。"