JP2006285708A - 状態情報管理システム、状態情報管理サーバ、状態情報管理プログラム、及び状態情報管理方法 - Google Patents

Abstract

【課題】プレゼンス情報を取得するためのサブスクライブを始めるときに今までは必ずサブスクライブ対象のIDをなんらかの方法で取得して、それを指定したサブスクライブを始める必要があった。
【解決手段】サブスクライブ対象を指定せず，サブスクライブ対象の条件(プレゼンスの値等)を指定してサブスクライブを行う。例えば，現在位置が同じであることを条件にサブスクライブを行うと条件に合ったユーザ対するサブスクライブが自動的に開始され，プレゼンスを取得できるが，相手や自分のプレゼンスが異なる値に変化した時にサブスクライブ対象は自動的に変化する。
【効果】サブスクライブ開始時にサブスクライブ対象のユーザID，グループID等を事前に取得する必要がなくなる。
【選択図】図３

Description

本発明は、情報公開の設定方式に関する。

”プレゼンス”と呼ばれる概念を利用したユーザ間の状態把握技術の開発が近年盛んに行なわれている。”プレゼンス”とはその名の如く，他ユーザに通知するための各ユーザの”存在”であり，具体的には各ユーザの現在位置や現在状態，その他様々な自分の存在を示す情報である。この”プレゼンス”を他のユーザに対してリアルタイムに通知することでお互いの現在状態を把握することが可能となる。これらプレゼンスの概念と通信技術はIM(Instant Messaging)技術から発展した。IM，及びプレゼンスの概念についてはIETF(Internet Engineering Task Force)のimpp(Instant Messaging and Presence Protocol)ワーキンググループを中心に標準化が行われている（非特許文献１、２参照）。また，具体的なプレゼンス通信技術についてはimppで規定された概念を元に様々なIETFのワーキンググループで議論，標準化が行われている。プレゼンス通信技術についての概要を図１５を用いて説明する。ここではプレゼンスの代表的な通信技術の一つである、IETF(Internet Engineering Task Force)のSIMPLE(Sip for Intstant Messaging and Presence Leveraging Extensions)ワーキンググループで標準化が進んでいるSIP(Session Initiation Protocol)用いたプレゼンス通信技術を用いて概要を説明する。
図１５は182に示すUserAの端末，183に示すUserBの端末，184に示すUserCの端末がお互いのプレゼンス情報を送受信している様子を示している。

例えば182に示すUserAが185に示すような型でUserB，UserCのプレゼンス情報を知りたい場合，UserB，UserCのID(SIPではSIP-URI)をUserAが把握し，UserAがUserB,UserCのSIP-URIを指定してプレゼンス受信の通知を希望する(以後この動作をサブスクライブと呼ぶ)SIPメッセージSUBSCRIBEメッセージをプレゼンス配信機能付サーバ181に送信する。このメッセージを受信したプレゼンス配信機能付サーバ181は対応するSIP-URIのプレゼンス情報，つまりUserB，及びUserCのプレゼンス情報をUserAにSIPのNOTIFYメッセージを用いて通知する。以後，UserAからUserB,UserCへのサブスクライブが有効である限り，UserB，UserCがプレゼンス配信機能付サーバ181に対して自分のプレゼンス情報を更新する度に，UserAに対して更新通知がNOTIFYメッセージを用いて行われる。これらのSIPを用いた基本的なプレゼンス情報通信の規定については非特許文献３及び非特許文献４にその詳細内容の記述がある。また，もうひとつの通信方法にグループを指定した一括プレゼンス情報取得がある。例えば185に示すようなお友達リストを一つのグループとして考え，このグループに188に示す様なグループＩＤを割当て，プレゼンス配信機能付サーバ181に保持しておく。182に示すUserAはUserB,UserCのプレゼンス情報を知りたい場合，UserB，及びUserCのSIP-URIを指定して別々にプレゼンス情報の通知を希望するSUBSCRIBEメッセージを送信するのでは無く，UserBとUserCをグループメンバとして含んだグループID188を指定したSUBSCRIBEメッセージを送信し，そのグループメンバであるUserBとUserCのプレゼンス情報を一括して取得する。IETFのSIMPLEワーキンググループではこの様にグループを指定してそのメンバのプレゼンス情報を一括取得する方法を「イベントリストサブスクライブ」と呼び，非特許文献５でその方法を規定している。

本例ではプレゼンス情報の通信技術にSIPを用いて概要を説明したが，基本的な概念については他の通信技術を用いても同様である。他人のプレゼンス情報を閲覧したいユーザはプレゼンス閲覧対象となるユーザのユーザID，もしくは対象ユーザが所属するグループのIDを指定してプレゼンス情報の通知を希望するメッセージを181の様なプレゼンス情報の送受信機能を持ったサーバに対して送信し，希望する相手のプレゼンス情報を取得するモデルが基本となる。

RFC 2778

RFC 2779 RFC 3265 RFC 3856 IETF Internet Draft draft-ietf-simple-event-list-06.txt

背景技術で述べたユーザIDを指定したサブスクライブ方法，グループIDを指定して所属ユーザのプレゼンス情報を一括取得するサブスクライブ方法，どちらを利用しても，サブスクライブするユーザはサブスクライブする対象のID(相手ユーザやグループ)を明示的に指定してプレゼンス情報の通知を希望するサブスクライブメッセージを送信する必要がある。この方法では予め自分がサブスクライブしたい相手ユーザのIDやグループIDを把握することが必須となる。とりあえずテンポラリにプレゼンスを参照したい場合，サブスクライブ対象を短時間で変化させるようなプレゼンス情報通信モデルを考た時，相手のIDやグループIDを把握する負担により，本方式でのサブスクライブでは実現することが困難となる。例えば，出席した会議で初めて会った会議メンバのプレゼンス情報をとりあえずテンポラリに知りたい場合，参加中の会議室名(つまりグループID)は分からないが，その場所にいるユーザの状態が知りたい場合，自分が現在テンポラリで座っている机の周囲の人のプレゼンス情報を知りたい場合が挙げられる。この様な状態で毎回相手のIDを聞く，現在自分がテンポラリに所属しているグループIDを調べることはユーザビリティの低下を招く。

サブスクライブメッセージを相手のIDやグループIDを指定して送信するのではなく，条件対象となるプレゼンス情報のある項目とその項目に対する条件を指定して行う。例えばあるユーザが”現在位置”のプレゼンス情報が”同一である”事を条件としてサブスクライブを行う。この時，サブスクライブを行ったユーザの”現在位置”プレゼンス情報が”201会議室”であった場合，同じく”現在位置”プレゼンスが”201会議室”である他ユーザに対して自動的にサブスクライブが行われ，プレゼンス情報の通知を受けることができる。その後，サブスクライブを行っているユーザの”現在位置”プレゼンス情報が”502実験室”に変化すると，”現在位置”が”201会議室”であったときにプレゼンス情報閲覧していたメンバへのサブスクライブは自動的に解除され，”現在位置”が”502実験室”であるメンバに対するサブスクライブが自動的に開始する。また，サブスクライブされる側のユーザは他のユーザからのサブスクライブに対してプレゼンス情報を公開するか否か、あるいはどこまで公開するか等を設定しておき，必要以上のプレゼンス情報が他のユーザに知られないようにガードする。

各ユーザはサブスクライブを行う時に相手ユーザ，またはグループのIDを明示的指定する必要がなくなる。これによりサブスクライブ対象のIDを入手する手間の解消によるユーザビリティ向上する。また，自分のプレゼンス情報の変化に応じてサブスクライブ対象となるユーザが自動的に変化するので，サブスクライブ対象を変化させる際にメッセージ数が削減される。

本実施例では、まず，プレゼンス情報を送受信するサーバの論理的構造，物理的構造、動作概要、及びそのサーバを用いたサービスを実現するためのネットワーク概要について説明する。その後，サーバ内部で保持するデータ例，フローチャート例を用いて本願発明装置の処理を説明する。

図１には，本実施例のプレゼンス情報を送受信するサーバの機能ブロック図を示した。図１の機能ブロック図は，ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。

図２には、図１に示した機能ブロックが、ハードウェア上、どのように実現されているかを示した。図１に示した種々の機能ブロックの動作は、図２に示すメモリ22の処理モジュール群26に収納されており，動作時にはＣＰＵ23がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な情報は、データベース31及びメモリ22上のテンポラリメモリテーブル24に格納されており必要に応じて読み出し，書き込みが行われる。その際，データベース31に格納されたデータの読み出し，書き込み処理はインタフェース(IF)30とテーブル情報入出力部37を経由して行われる。なお，データベース31とサーバ1は物理的に異なる装置で構成することも可能であるし，同一装置内部に論理的に構成することも可能である。

まずは，図１，図２に示したプレゼンス情報の送受信機能を有するサーバ１を用いて各ユーザがどのようなことを行えるかについての概要を図３の動作概念図を用いて説明する。図３では45に示したユーザがサブスクライブ条件対象となるプレゼンス項目を41に示すように”location(場所)”に，その条件を42の様に”same(同じ)”に設定しサーバ１に対してサブスクライブを行っている状態である。この時45に示すユーザがもし会議室43に現在滞在しており，自分のプレゼンス情報”location”を46−1のように”会議室”と登録していた場合，サーバ1は現在同じ場所に滞在し，プレゼンス情報”location”が同じ”会議室”である51に示すＡ，52に示すＢ，53に示すＦを47-1の様にサブスクライブ対象と自動的に認識し，45に示すユーザはＡ，Ｂ，Ｆのプレゼンス情報を取得することができる。その後，45に示すユーザが居室44に移動したとする。そして45に示すユーザはプレゼンス情報”location”を46-2のように”居室”に更新する。するとサーバ１はプレゼンス情報の更新を契機に47-1のサブスクライブ対象を一旦破棄，さらに現在同じ場所に滞在し，プレゼンス情報”location”が同じ”居室”である54に示すＣ，55に示すＧ，56に示すＤ，57に示すＥを47-2の様にサブスクライブ対象と自動的に新たに認識し，45に示すユーザはＣ，Ｇ，ＤＥのプレゼンス情報を取得することができるようになる。つまり，45に示すユーザがサーバ１に対して一度サブスクライブを希望するメッセージを送信すると，ユーザ本人の状態変化に応じてサーバ１がサブスクライブ対象を47-1から47-2の様に自動的に変更する。この処理によりサブスクライブを行っているユーザは明示的にサブスクライブ対象を変更することなく，場合に応じた相手に対するサブスクライブを開始することが可能となる。また，逆に場合に応じて必要なくなった相手へのサブスクライブを明示的に宣言することなく終了することが可能となる。

次に，上記概要の詳細な動作内容の例を図１のモジュール図，図２の物理的ハードウェア図，図４のネットワーク図，図５のシーケンス図，図６〜８のメッセージ例，図９〜図１４のテーブル図，図１６〜２０のフローチャート図を用いて説明する。但し，これら説明で記述する具体的な送受信メッセージ内容，シーケンス，テーブル構成，ソフトウェアのモジュール構成，ハードウェア構成，処理フローチャートは一例であり，目的の動作を実現することで発明の効果を奏することが可能な限り，別な方法及び構成を用いて実現しても構わない。

図４は本願発明を用いたサービス例のネットワーク図である。このネットワーク上では61に示すUserA，62に示すUserB，63に示すUserCの3ユーザがそれぞれ無線アクセス網1061，有線アクセス網1062，IP Network1063を経由して通信事業者1064が所有するプレゼンス送受信サーバ１にアクセスし，他ユーザのプレゼンス情報を閲覧している，つまり他ユーザに対してサブスクライブしている状態である。各端末は通信事業者1064が所有する認証サーバ68やSIPサーバ69を利用している可能性もある。また，UserAは利用端末に64に示す情報端末の他に65に示すセンシングデバイスを用いているとする。センシングデバイスとはRFID(Radio Frequency Identification)の様な小型のタグや自らが現在位置を発信することが可能なGPS付携帯電話の様に何らかの方法で自分の位置情報をサーバに登録することが可能な装置のことである。センシングデバイスを用いることでユーザの現在位置を1065に示すような受信機を用いて無線経由でシステムに通知することが可能となる。本例ではUserAは第2の端末として センシングデバイスを用いているが，本端末には他のデバイスや端末，アプリケーションを用いることも考えられるし，UserAが複数端末を利用せず，64の情報端末のみ用いている場合も考えられる。

図５は図４の動作シーケンス図である。このシーケンスを順番に説明することで詳細な動作の流れを説明する。なお，図４のシーケンス開始時，各ユーザのプレゼンス情報の初期値は70の表に示した値であり，UserB，UserCは既にサーバ１に対するログイン処理を終了し，本願発明の条件指定型のサブスクライブを開始しているものとする。また，UserB，UserCが行っている条件指定型サブスクライブのサブスクライブ条件はUserAが行う条件指定型サブスクライブのサブスクライブ条件であるプレゼンス情報”location”が”same(同じ)”とう条件と同様とする。

まず61に示すUserAは端末64を用いてステップ71でプレゼンス情報送受信サーバ１にログインする。ログイン後，ステップ72で条件を指定したプレゼンス情報要求を送信する。つまり，本願発明の条件指定型サブスクライブを開始する。

その時のメッセージ例を図６に示す。図６はサブスクライブがSIPで行われている場合のメッセージ例である。UserAはサブスクライブ対象を示すリクエストライン101，Toヘッダ102にはサブスクライブ対象となる相手ユーザやグループのSIP-URIを示さずに自分のSIP-URIを示している。リクエストライン，Toヘッダは，SIPメッセージの転送規定上，必ず記述する必要があるが本例で示した自分のSIP-URIの様に，SIPメッセージがサーバ１に転送されるSIP-URIならばどのような値でも構わない。また，サブスクライブの条件をContactヘッダ内部のURIパラメータ103に記述している。サブスクライブ条件の記述はこの様に既存ヘッダ内部にURIパラメータの形で拡張して記述する方法の他に， 104の様に独自拡張ヘッダに記述する方式，105の様にSIPメッセージボディ部に記述する形を取ってもよい。条件は記述場所は問わないが，サーバ1がサブスクライブ条件からサブスクライブ対象を特定する為に最低1つは記述する必要がある。また，条件を複数記述することで複数の条件にマッチする対象を検索することが可能となる。

サーバ１が64に示すUserAの端末が送信したサブスクライブ要求を受信した後に行う処理フローチャートを示した図が図16，図17である。図16，17を用いてサーバ１の処理手順について説明する。
サーバ１は図16のステップ191でサブスクライブ要求を図１のプレゼンス情報取得要求モジュール13で受信するとステップ192でサブスクライブメッセージを解析し，サブスクライバと条件を抽出する。サブスクライバとは他ユーザのプレゼンス情報の取得を要求するユーザのことで，本例ではプレゼンス情報要求を送信したユーザのことである。本処理はプレゼンス情報取得要求解析モジュール１２で行う。また，ステップ192ではこれら解析した情報をプレゼンス情報，サブスクライブ情報管理機能２に送信する。

送信された情報はステップ193にてサブスクライブ状態管理モジュール７で処理される。サブスクライブ状態管理モジュール７はサブスクライブの開始，終了等のサブスクライブ状態や各サブスクライブの条件を図２に示すサブスクライブ管理テーブル25を用いて管理するモジュールである。サブスクライブ管理テーブルの詳細な内容を図９に示す。サブスクライブ状態管理モジュールはプレゼンス情報取得要求解析モジュールから送信された情報を元に図９のテーブル121内の122に示すサブスクライバ，及び124に示す条件１にサブスクライブ条件を登録する。サブスクライブ条件が複数存在する場合は125以降に条件を書き込む。

サブスクライブ登録処理を完了したサーバ１は次にステップ194において，サブスクライブをしてきたUserAに対して現在サブスクライブ条件にマッチしているユーザ，及びそれらユーザのプレゼンス情報を通知する為に， UserAが指定したサブスクライブ条件に現時点でマッチしている他ユーザを検索する。本処理は図１に示すサブスクライブ対象管理モジュール６で行われる。サブスクライブ対象管理モジュール６は図２の条件付サブスクライブ管理テーブル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にて図２のメモリ22上にあるサブスクライブ対象管理テーブル27に登録する。図１０の131はサブスクライブ対象管理テーブル27のテーブル構成例である。サブスクライブ対象管理モジュール６はこのテーブル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つのテンプレートを割当てているが，これを複数割当てることも可能である。この様にサーバ１はUserAのプレゼンス情報の値により条件マッチユーザのどのプレゼンス情報を閲覧可能であるかを判断する。なお，本処理により公開すると判断されたプレゼンス情報でもパーミッション情報管理テーブル32で個別設定でプレゼンス情報を非公開とすると設定されていた場合，そちらの情報を優先し，プレゼンス情報を非公開とする。プレゼンス情報公開ポリシ管理テーブル33，テンプレート管理テーブル35はシステムの管理者が設定する。一方，パーミッション情報管理テーブル32は各ユーザが自分の登録したプレゼンス情報に対して自分のプライバシを保護する為に設定する。よってたとえシステム管理者が公開と設定したプレゼンス情報でも個々人が自分のプライバシを守るために行った設定が非公開で合った場合，個々人の意思を尊重してそのプレゼンス情報は非公開とサーバ１は判断する。このように個々人が設定可能なフィルタ機能を最優先にしてサブスクライバへの公開ポリシを決定することで，各ユーザが個人的に持つ公開ポリシに沿ってプライバシの保護を行うことが可能となる。

ステップ199でプレゼンス情報のフィルタリングを行った後，ステップ200で公開可能なプレゼンス情報について通知メッセージを作成し，テンポラリメモリテーブルに保存しておき，送信準備を行う。
これら処理が終了した後，ステップ201にて全条件マッチユーザの処理が終了していなかった場合，次のユーザについて再度ステップ196から処理を行い，全てのマッチしたユーザについての処理が終了するまで繰り返し処理を行う。

全マッチユーザについての処理が終了した場合，図17のステップ212にてテンポラリメモリテーブルに登録してあった全マッチユーザのメッセージを取得し，ステップ213にて全メッセージを合成し，サブスクライバへの通知メッセージを作成する。本処理は図１のプレゼンス情報分析・構築モジュール10で行う。その後，ステップ214にてプレゼンス情報更新通知送信モジュール14から図５のステップ74で送信する。その時の送信メッセージ例を図７及び図８に示す。この例ではプレゼンス情報の通知にSIPのNOTIFYメッセージを利用しているが，同様の機能を満足できれば他のプロトコルを用いてもよい。図７の111に示す部分がSIPメッセージヘッダ部であり，113，114に示す部分がSIPメッセージボディ部である。SIPメッセージヘッダ部にはメッセージの送信元を示すFromヘッダ112があるが，そこには送信元ユーザやグループのSIP-URIではなく，UserA自身のSIP-URIが記述されている。この部分はUserAのSIP-URIである必要はなく，どのような値でも構わない。また，113，114はプレゼンス情報の内容を示すSIPボディ部分であるが，この部分はdraft-ietf-simple-event-list-06.txtで規定されたフォーマットに従って記述されている。113に示す部分はこの通知メッセージにプレゼンス情報を記述しているメンバ一覧，つまり先ほどのサブスクライブ対象管理モジュール6でマッチしたユーザ一覧を記述している。図８の114には各ユーザのプレゼンス情報の内容を記述している。この例ではプレゼンス情報の記述をdraft-ietf-simple-event-list-06.txtの規定に従い記述しているが，その他の方法でプレゼンス情報を記述しても構わない。

次にサーバ１はシーケンス図のステップ75でサブスクライブを行ったUserAに対して他のユーザのサブスクライブに対して自分のプレゼンス情報をどれだけ公開するかについての問い合わせを送信する。問合せを行うことにより，サーバ1はプレゼンス情報を公開するユーザの情報公開ポリシを確認することが可能となる。この問い合わせはUserAのプレゼンス情報が更新され、マッチング対象が変化する度に送信される。UserAはプレゼンス情報の内容によって公開ポリシを変更したい可能性がある。この様な場合にプレゼンス情報の更新毎に問合せを行うことで，サーバ1はUserAの公開ポリシの細かな変化を知ることができる。この問い合わせによりUserAは例えば、会議室でなら持込資料やコメントまで見せてもよいが、自席に座っているときは見せたくない(見せる必要がないと判断する場合も含まれる)を判断し、公開プレゼンス情報を変化させることができる。先ほどステップ74でUserAが条件にマッチしたユーザのプレゼンス情報を受信したときはマッチした他ユーザは自分のプレゼンス情報”location”を”会議室”に変更した際にすでにステップ75のような問い合わせを受けており、それに対して公開を許可する応答をしていたからUserAにプレゼンス情報が送信されている。この問い合わせを受けてUserAがステップ76でプレゼンス情報の公開を許可する応答を行った場合、サーバ１はUserCに対してUserAが条件にマッチした通知をステップ77で送信する。しかし、UserAがプレゼンス情報の公開を拒否する応答をステップ76で送信した場合、ステップ77のメッセージは通知されない。通知しないことで，公開を拒否したUserAの情報が流出することを防止できる。なお、ステップ76でプレゼンス情報の公開を許可する応答をUserAが行った場合、本例ではUserA自身にもUserAが条件にマッチしたことをステップ78にて通知しているが、本処理は行っても行わなくてもよく、システム毎に送信可否のポリシを決定すればよい。さらにステップ75から78の部分(82の枠で囲んだステップ群)についてもシステム単位で実行可否のポリシを決定し、必要がない場合は行わなくてもよい。もし、このステップ群を行わなかった場合、UserAのプレゼンス情報はUserAが事前に設定したパーミッション情報、及びシステム管理者が設定した図２のデータベース31にあるプレゼンス情報公開ポリシ管理テーブル33の設定に従いUserCに通知される。通知処理の方法については後述するUserAがプレゼンス情報を更新した場合の処理フローチャートに従う。

その後、UserAがステップ79で自分のプレゼンス情報”location”を”会議室”から”居室”に変更したとする。このときサーバ１はプレゼンス情報の更新に伴うサブスクライブマッチユーザの変更を確認するための処理を行うが、その内容について詳細説明する。

図18、図19は上記処理のフローチャート図である。サーバ１は図18のステップ231において図１のプレゼンス情報送受信モジュール11でプレゼンス情報更新メッセージを受信
し、さらにプレゼンス情報分析・構築モジュール10で登録するプレゼンス情報を抽出した後、プレゼンス情報管理モジュール9で各種情報入力モジュール4を経由し、IF30からデータベース31のプレゼンス情報管理テーブル34のプレゼンス情報を更新する。その後、プレゼンス更新によるサブスクライブマッチユーザの更新処理を開始する。
まず、サーバ1はステップ232において、図１のサブスクライブ対象管理モジュール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の処理に入る。
サーバ１は図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のサーバ１からのプレゼンス情報公開要求メッセージとステップ85の返信メッセージ、その後のステップ87のメッセージも含む。この2つのステップの内容はシーケンス図の枠82と同様である。ステップ260の処理により、シーケンス図の78でサーバ1からUserBに対してメッセージが送信される。

その後、ステップ261で全ユーザについての処理が終了していなかった場合、残りのユーザについての処理を行うためにステップ254に戻り再度処理を行う。全ユーザについての処理が終了していた場合、ステップ262に進み処理を終了する。

その後、シーケンス図ではステップ79でUserAがプレゼンス情報”location”を”会議室”から”居室”に変更し、そのことがUserCに通知されているが、この処理についてはシーケンス図のステップ79、83と同様である。
このような動作で各ユーザはサーバ１に対して条件付サブスクライブを行い、互いのプレゼンス情報の変化に伴いサブスクライブ対象を変化しながら、条件にマッチした他ユーザのプレゼンス情報をシステム、さらに他ユーザ自身が公開を許可した情報を参照することが可能となる。

この様にして，UserAはユーザIDやグループIDを指定せず，条件のみを指定したサブスクライブを行うことで，相手ユーザID，グループIDを知らなくてもサブスクライブ対象とすることが可能となる。さらに，UserAのプレゼンス情報の変化に伴い，サブスクライブ対象が変化した時，UserAは何も行うことなく，新規条件にマッチした他ユーザに対するサブスクライブを自動的に開始し，条件の変化によりサブスクライブ対象から外れた他ユーザのサブスクライブを自動的に解除することが可能となる。

図21は本願発明の第2の実施例である。この例では273で示すＡと272で示すＢと271で示すＣがそれぞれ異なるサブスクライブ条件274、275、276を条件としてサブスクライブを行っている。本例では条件に図３の様な”same(同じ)”ではなく、○○m以内と範囲を指定している。このように条件に範囲を指定することで，条件にマッチしてサブスクライブの対象となるユーザに幅を持たせることが可能となる。それぞれのプレゼンス情報”location”の値は277、278、279の値となっている。この時それぞれのユーザが指定するサブスクライブ条件が異なる(範囲が異なる)ため、サブスクライブ対象が非対称となっている。つまり280に示すようにＣの条件にマッチしている他ユーザはおらず、Ｃは他ユーザのプレゼンス情報を閲覧していないのに対して、Ｂは281のようにＣのプレゼンス情報を閲覧している。また、ＢとＡについては281、282のように対称でサブスクライブを行っており、互いにプレゼンス情報を閲覧している。条件の指定の仕方によりこのような非対称な状態でのサブスクライブが発生する可能性がある。各ユーザは実施例１の様なシステム上で各自独立した条件を設定することが可能である。この仕組みを利用して各ユーザが別々のサブスクライブ条件をサーバに提示することでこの様な非対称なサブスクライブが実現する。

図22は本願発明の第3の実施例である。この例では291に示すＡ、292に示すＢ、293に示すＣ，294に示すＤの4人が条件付サブスクライブを行っており、それぞれの条件は295から302となっている。本例では各ユーザがサブスクライブ条件としてプレゼンス情報の値を指定するのではなく、自分のバディリストへ登録されていることを条件として指定している。この設定はサブスクライブを行う側が条件にマッチするユーザの範囲を限定している。このように各ユーザは自分がサブスクライブする時に自ら条件マッチの範囲を指定することができる。さらに、システム管理者がこのような範囲を設定することも可能である。各ユーザが自分がサブスクライブを行う時にこの様にマッチするユーザの範囲を限定するような条件を指定した場合もその条件内容は図9のテーブル121上の124等の条件カラムに記述される。管理者が設定した場合、各ユーザがサブスクライブした時、管理者が設定したユーザの範囲でしかマッチングが行われない。また、各ユーザがプレゼンス情報”location”に対して設定している条件も図３の例の様に、”same(同じ)”ではなく、±○○以内と範囲指定してもよい。この範囲指定について図２３を用いて説明する。

図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に示すＡは311のように”location”の条件範囲内にいるＢのプレゼンス情報を閲覧している。ＣはＡのバディリストに登録されているが、Ｃの”location”がＡの条件範囲内でないのでＣはＡのサブスクライブ条件にはマッチしていない。292に示すＢはＡ，Ｃ，Ｄの3人が”location”の範囲内に入っているのだが、バディリストに登録しているユーザはＡ，Ｄのみなので312のようにこれら2人のプレゼンス情報のみを閲覧している。ＣはバディリストにＡのみを登録しているが、Ａは”location”の条件範囲内に入っていないので、サブスクライブ対象は313の様に”なし”となっている。Ｄは”location”の条件範囲内にＢが存在するので314の様にＢをサブスクライブ対象としている。この様にプレゼンス情報の値間に距離を定義することで，実施例３の地名の様な値間の具体的な距離が分からない概念的な値の間にも論理的な距離を定義して，サーバがサブスクライブの範囲を計算することを可能とする。

図２４は本願発明の第4の実施例のサービスイメージ図である。このサービスはバス停でバスを待っているユーザ372が375の様に自分が乗るべきバスの運行状況を確認するサービス、バス運行会社373が自社のバスの運行状況を確認するサービス、運行中のバスが374の様に先のバス停でバスを待っているユーザがいるかどうかを確認するサービスの3つを含んでいる。このサービスの具体的な内容を図25を用いて説明する。図25は図24のサービスの動作概念図である。本例では342に示すＡ、343に示すＢ、344に示すＣがそれぞれバス停でバスを待っている。また、341に示すバスが現在運行中である。バスの行き先は353の”destination”に示すように”国立”であり、途中で経由するバス停は”via”に示すように”○○一丁目”，”○○大学”，”国立”である。ＡとＣが行きたいバス停は354、356の”goal”に示すように”国立”、Ｂが行きたいバス停は355の”goal”に示すように”立川”である。Ａ，Ｂ，Ｃ、バスはサーバ1に対してそれぞれ345から352を条件にして条件指定型のサブスクライブを行っているものとする。また、バス停の間には図23の322から331に示すような形で値間の関係を設定しているものとする。

この時Ａは○○一丁目のバス停で待っており、さらに降りるバス停が”国立”である。341のバスは現在Ａのひとつ手前のバス停におり、さらに行き先が国立であるので条件にマッチする。よってＡのサブスクライブ対象には341に示すバスが含まれ、304の様に04系バス国立行きが一つ前のバス停を出発したことをＡに通知される。Ｂは待っているバス停はＡと同じだが、行き先が立川で341のバスが停車しないバス停であるのでＢには341に示すバスの情報は通知されない。またＣは行き先は国立であるが、バスとの距離が２であるため、”location”の条件にマッチしないので、Ｃにも341のバスの情報は通知されない。なお、Ａ，Ｂ，Ｃのユーザ間も”location”の範囲が1以内ではあるが各ユーザが2つ目の条件に指定している”via”の値についてお互いマッチしない(Ａ，Ｂ，Ｃはプレゼンス情報”via”はそもそも持っておらず設定していない)のでユーザ間でのマッチングは発生しない。

また、341に示すバスは”location”が±2以内かつ自分の”via”に相手の”goal”と同じ値があることを条件にサブスクライブを行っている。よって”goal”の値を”国立”とバスの”via”に存在する値で登録しているＡ，Ｃについての情報を得ることができ、その結果、357のように1つ先のバス停に乗車客一人(Ａ)がおり、2つ先のバス停に乗車客一人(Ｃ)がいることをバス停に行くまでに事前に把握することが可能となる。”location”，”via”，”goal”の3つのプレゼンスはそれぞれそのプレゼンスが表す意味は異なるが，各ユーザの目的によってはこの様にそれぞれのプレゼンス情報の項目をマッチング条件に指定することでこの例の様に各ユーザの”行きたい場所”とそこまで輸送するバスが”経由する場所”をマッチングさせることで各ユーザの目的を達成することが可能となる。
この様にバスの運行システムに応用した場合，各ユーザは道路状況により，到着時刻が変動しやすいバスの実際の運行状況をバス停で待ちながらにして知ることができる。さらにバス側では今まで各バス停で停車すべきかどうかをバス停で待っているユーザを目視で確認する必要があり，確実に確認が正しいとは限らなかったが，各バス停で待っているユーザを事前に知ることにより，各バス停での停車の必要性を確実に知ることができる。

本願発明における条件付サブスクライブ方式を適用したプレゼンスサーバの機能ブロック図である。 本願発明における条件付サブスクライブ方式を適用したプレゼンスサーバの装置図である。 本願発明装置の動作概要図である。 本願発明装置を用いた接続形態を示すネットワーク図である。 本願発明装置を用いた接続形態の動作シーケンス図である。 本願発明装置に対してユーザが送信するプレゼンス情報要求時のSIPメッセージである。 本願発明装置がユーザに対して送信するプレゼンス情報通知時のSIPメッセージである。 本願発明装置がユーザに対して送信するプレゼンス情報通知時のSIPメッセージである。 本願発明装置が記憶する条件付サブスクライブ管理用テーブル図である。 本願発明装置が記憶するサブスクライブ対象管理用テーブル図である。 本願発明装置が記憶するサブスクライブ条件テンプレート用テーブル図である。 本願発明装置が記憶するパーミッション設定用テーブル図である。 本願発明装置が記憶するパーミッション設定用テーブル図である。 本願発明装置が記憶するパーミッション設定用テーブル図である。 従来技術利用時のネットワーク図である。 本願発明装置のフローチャート図である。 本願発明装置のフローチャート図である。 本願発明装置のフローチャート図である。 本願発明装置のフローチャート図である。 本願発明装置のフローチャート図である。 本願発明の第2の動作概念図である。 本願発明の第3の動作概念図である。 プレゼンス情報内容間の関係図である。 本願発明の第4のサービスイメージ図である。 本願発明の第4の動作概念図である。

符号の説明

１・・・プレゼンスサーバ、２・・・パーミッション情報制御部、３・・・パーミッション管理部。

Claims (48)

1. 複数の端末の状態情報を管理するサーバを備えた状態情報管理システムであって、
   上記サーバは、
   上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
   上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
   上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態情報を上記第１の端末に送信する送信部を有し、
   上記状態情報抽出条件は、上記他の端末を示す情報、上記他の端末のユーザを示す情報、または上記他の端末もしくは上記他の端末のユーザが属するグループを示す情報のいずれでもないことを特徴とする状態情報管理システム。
2. 複数の端末の状態情報を管理するサーバを備えた状態情報管理システムであって、
   上記サーバは、
   上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
   上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
   上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態情報を上記第１の端末に送信する送信部を有し、
   上記送信部は、上記状態情報抽出条件に合致する他の端末が増加または減少した場合には、上記増加または減少を反映した一または複数の他の端末の新たな状態情報をあらためて上記第１の端末に送信することを特徴とする状態情報管理システム。
3. 請求項１または２に記載の状態情報管理システムであって、
   上記状態情報抽出条件は、状態情報の値の少なくとも一部を指定したものであり、
   上記送信部は、上記状態情報抽出条件で指定された状態情報の値の少なくとも一部と合致する状態情報を有する上記他の端末の状態情報を上記第１の端末に送信することを特徴とする状態情報管理システム。
4. 請求項３記載の状態情報管理システムであって、
   上記状態情報抽出条件は、状態情報の値の範囲を指定したものであることを特徴とする状態情報管理システム。
5. 請求項４記載の状態情報管理システムであって、
   上記状態情報抽出条件は、上記第１の端末の状態情報の値と一定の距離内にある状態情報の値を指定したものであることを特徴とする状態情報管理システム。
6. 請求項５記載の状態情報管理システムであって、
   上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴とする状態情報管理システム。
7. 請求項６記載の状態情報管理システムであって、
   上記状態情報の値は、端末または該端末のユーザの所在地であり、上記距離は物理的な距離または道のりに基づいて定められた距離であることを特徴とする状態情報管理システム。
8. 請求項６記載の状態情報管理システムであって、
   上記状態情報の値は、端末のユーザの役職名であって、上記距離は上記役職名間の組織階層上の近さを表す論理的な距離であることを特徴とする状態情報管理システム。
9. 請求項３記載の状態情報管理システムであって、
   上記状態情報抽出条件は、上記第１の端末の状態情報との関係が一定の条件を満たす状態情報の値を指定するものであり、
   上記送信部は、上記一定の条件を満たす値を有する他の端末の状態情報を上記第１の端末に送信することを特徴とする状態情報管理システム。
10. 請求項９記載の状態情報管理システムであって、
    上記一定の条件とは、上記第１の端末の状態情報の値と同一の値であるという条件であることを特徴とする状態情報管理システム。
11. 請求項９記載の状態情報管理システムであって、
    上記一定の条件とは、上記第１の端末の状態情報の値と一定の距離にある値であるという条件であることを特徴とする状態情報管理システム。
12. 請求項１１記載の状態情報管理システムであって、
    上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴とする状態情報管理システム。
13. 請求項９記載の状態情報管理システムであって、
    上記状態情報には複数の項目が含まれており、
    上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と同じ項目に対する条件であることを特徴とする状態情報管理システム。
14. 請求項９記載の状態情報管理システムであって、
    上記状態情報には複数の項目が含まれており、
    上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と一致しない項目に対する条件であることを特徴とする状態情報管理システム。
15. 請求項１または２記載の状態情報管理システムであって、
    上記送信部は、上記一または複数の他の端末のうち一部の限定された一または複数の他の端末の状態情報のみを上記第１の端末に送信し、
    上記他の端末を限定する条件は、該他の端末の状態情報の値には基づかずに限定する条件であることを特徴とする状態情報管理システム。
16. 請求項１５記載の状態情報管理システムであって、
    上記他の端末を限定する条件は、上記第１の端末が指定することを特徴とする状態情報管理システム。
17. 請求項１６記載の状態情報管理システムであって、
    上記他の端末を限定する条件とは、上記第１の端末があらかじめ指定した他の端末のリストに含まれる端末のみに限定するという条件であることを特徴とする状態情報管理システム。
18. 請求項１５記載の状態情報管理システムであって、
    上記他の端末を限定する条件は、該システムの管理者が設定することを特徴とする状態情報管理システム。
19. 請求項１５記載の状態情報管理システムであって、
    上記他の端末を限定する条件とは、上記一または複数の他の端末のうち状態情報の公開を拒否する他の端末を除くという条件であることを特徴とする状態情報管理システム。
20. 請求項１９記載の状態情報管理システムであって、
    上記状態情報の公開を拒否する他の端末は、公開を拒否する状態情報の値、または公開を拒否する相手端末の少なくともいずれか一方を、予め該サーバに登録しておくことを特徴とする状態情報管理システム。
21. 請求項１９記載の状態情報管理システムであって、
    上記サーバは、
    上記一または複数の端末に対して状態情報公開の可否を問い合わせることを特徴とする状態情報管理システム。
22. 請求項２１記載の状態情報管理システムであって、
    上記問い合わせは、上記状態情報抽出条件に合致した上記他の端末に対して行われることを特徴とする状態情報管理システム。
23. 請求項２記載の状態情報管理システムであって、
    上記新たな状態情報は、上記第１の端末の状態情報が更新された際に、上記第１の端末に送信されることを特徴とする状態情報管理システム。
24. 請求項２記載の状態情報管理システムであって、
    上記新たな状態情報は、上記第１の端末以外の端末のいずれかの状態情報が更新された際に、上記第１の端末に送信されることを特徴とする状態情報管理システム。
25. 複数の端末の状態情報を管理する状態情報管理サーバであって、
    上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
    上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
    上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態情報を上記第１の端末に送信する送信部を有し、
    上記状態情報抽出条件は、上記他の端末を示す情報、上記他の端末のユーザを示す情報、または上記他の端末もしくは上記他の端末のユーザが属するグループを示す情報のいずれでもないことを特徴とする状態情報管理サーバ。
26. 複数の端末の状態情報を管理する状態情報管理サーバであって、
    上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
    上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
    上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態情報を上記第１の端末に送信する送信部を有し、
    上記送信部は、上記状態情報抽出条件に合致する他の端末が増加または減少した場合には、上記増加または減少を反映した一または複数の他の端末の新たな状態情報をあらためて上記第１の端末に送信することを特徴とする状態情報管理サーバ。
27. 請求項２５または２６に記載の状態情報管理サーバであって、
    上記状態情報抽出条件は、状態情報の値の少なくとも一部を指定したものであり、
    上記送信部は、上記状態情報抽出条件で指定された状態情報の値の少なくとも一部と合致する状態情報を有する上記他の端末の状態情報を上記第１の端末に送信することを特徴とする状態情報管理サーバ。
28. 請求項２７記載の状態情報管理サーバであって、
    上記状態情報抽出条件は、状態情報の値の範囲を指定したものであることを特徴とする状態情報管理サーバ。
29. 請求項２８記載の状態情報管理サーバであって、
    上記状態情報抽出条件は、上記第１の端末の状態情報の値と一定の距離内にある状態情報の値を指定したものであることを特徴とする状態情報管理サーバ。
30. 請求項２９記載の状態情報管理サーバであって、
    上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴とする状態情報管理サーバ。
31. 請求項３０記載の状態情報管理サーバであって、
    上記状態情報の値は、端末または該端末のユーザの所在地であり、上記距離は物理的な距離または道のりに基づいて定められた距離であることを特徴とする状態情報管理サーバ。
32. 請求項３０記載の状態情報管理サーバであって、
    上記状態情報の値は、端末のユーザの役職名であって、上記距離は上記役職名間の組織階層上の近さを表す論理的な距離であることを特徴とする状態情報管理サーバ。
33. 請求項２７記載の状態情報管理サーバであって、
    上記状態情報抽出条件は、上記第１の端末の状態情報との関係が一定の条件を満たす状態情報の値を指定するものであり、
    上記送信部は、上記一定の条件を満たす値を有する他の端末の状態情報を上記第１の端末に送信することを特徴とする状態情報管理サーバ。
34. 請求項３３記載の状態情報管理サーバであって、
    上記一定の条件とは、上記第１の端末の状態情報の値と同一の値であるという条件であることを特徴とする状態情報管理サーバ。
35. 請求項３３記載の状態情報管理サーバであって、
    上記一定の条件とは、上記第１の端末の状態情報の値と一定の距離にある値であるという条件であることを特徴とする状態情報管理サーバ。
36. 請求項３５記載の状態情報管理サーバであって、
    上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴とする状態情報管理サーバ。
37. 請求項３３記載の状態情報管理サーバであって、
    上記状態情報には複数の項目が含まれており、
    上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と同じ項目に対する条件であることを特徴とする状態情報管理サーバ。
38. 請求項３３記載の状態情報管理サーバであって、
    上記状態情報には複数の項目が含まれており、
    上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と一致しない項目に対する条件であることを特徴とする状態情報管理サーバ。
39. 請求項２５または２６記載の状態情報管理サーバであって、
    上記送信部は、上記一または複数の他の端末のうち一部の限定された一または複数の他の端末の状態情報のみを上記第１の端末に送信し、
    上記他の端末を限定する条件は、該他の端末の状態情報の値には基づかずに限定する条件であることを特徴とする状態情報管理サーバ。
40. 請求項３９記載の状態情報管理サーバであって、
    上記他の端末を限定する条件は、上記第１の端末が指定することを特徴とする状態情報管理サーバ。
41. 請求項４０記載の状態情報管理サーバであって、
    上記他の端末を限定する条件とは、上記第１の端末があらかじめ指定した他の端末のリストに含まれる端末のみに限定するという条件であることを特徴とする状態情報管理サーバ。
42. 請求項３９記載の状態情報管理サーバであって、
    上記他の端末を限定する条件は、該サーバの管理者が設定することを特徴とする状態情報管理サーバ。
43. 請求項４０記載の状態情報管理サーバであって、
    上記他の端末を限定する条件とは、上記一または複数の他の端末のうち状態情報の公開を拒否する他の端末を除くという条件であることを特徴とする状態情報管理サーバ。
44. 請求項４３記載の状態情報管理サーバであって、
    上記状態情報の公開を拒否する他の端末は、公開を拒否する状態情報の値、または公開を拒否する相手端末の少なくともいずれか一方を、予め該サーバに登録しておくことを特徴とする状態情報管理サーバ。
45. 請求項４３記載の状態情報管理サーバであって、
    上記一または複数の端末に対して状態情報公開の可否を問い合わせることを特徴とする状態情報管理サーバ。
46. 請求項４５記載の状態情報管理サーバであって、
    上記問い合わせは、上記状態情報抽出条件に合致した上記他の端末に対して行われることを特徴とする状態情報管理サーバ。
47. 請求項２６記載の状態情報管理サーバであって、
    上記新たな状態情報は、上記第１の端末の状態情報が更新された際に、上記第１の端末に送信されることを特徴とする状態情報管理サーバ。
48. 請求項２６記載の状態情報管理サーバであって、
    上記新たな状態情報は、上記第１の端末以外の端末のいずれかの状態情報が更新された際に、上記第１の端末に送信されることを特徴とする状態情報管理サーバ。