JP2006286011A

JP2006286011A - 状態情報管理システム及び状態情報管理サーバ

Info

Publication number: JP2006286011A
Application number: JP2006138427A
Authority: JP
Inventors: Tatsuhiko Miyata; 辰彦宮田; Kenji Kasuga; 謙治春日
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-05-18
Filing date: 2006-05-18
Publication date: 2006-10-19
Anticipated expiration: 2025-04-01
Also published as: JP4736945B2

Abstract

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

Description

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

”プレゼンス”と呼ばれる概念を利用したユーザ間の状態把握技術の開発が近年盛んに
行なわれている。”プレゼンス”とはその名の如く，他ユーザに通知するための各ユーザ
の”存在”であり，具体的には各ユーザの現在位置や現在状態，その他様々な自分の存在
を示す情報である。この”プレゼンス”を他のユーザに対してリアルタイムに通知するこ
とでお互いの現在状態を把握することが可能となる。これらプレゼンスの概念と通信技術
はIM(Instant Messaging)技術から発展した。IM，及びプレゼンスの概念についてはIETF(
Internet Engineering Task Force)のimpp(Instant Messaging and Presence Protocol)
ワーキンググループを中心に標準化が行われている（非特許文献１、２参照）。また，具
体的なプレゼンス通信技術についてはimppで規定された概念を元に様々なIETFのワーキン
ググループで議論，標準化が行われている。プレゼンス通信技術についての概要を図１５
を用いて説明する。ここではプレゼンスの代表的な通信技術の一つである、IETF(Interne
t Engineering Task Force)のSIMPLE(Sip for Intstant Messaging and Presence Levera
ging Extensions)ワーキンググループで標準化が進んでいるSIP(Session Initiation Pro
tocol)用いたプレゼンス通信技術を用いて概要を説明する。
図１５は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，U
serCがプレゼンス配信機能付サーバ181に対して自分のプレゼンス情報を更新する度に，U
serAに対して更新通知がNOTIFYメッセージを用いて行われる。これらのSIPを用いた基本
的なプレゼンス情報通信の規定については非特許文献３及び非特許文献４にその詳細内容
の記述がある。また，もうひとつの通信方法にグループを指定した一括プレゼンス情報取
得がある。例えば185に示すようなお友達リストを一つのグループとして考え，このグル
ープに188に示す様なグループＩＤを割当て，プレゼンス配信機能付サーバ181に保持して
おく。182に示すUserAはUserB,UserCのプレゼンス情報を知りたい場合，UserB，及びUser
Cの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付携帯電話の様に何らかの方法で自分の位置情報をサーバに登録するこ
とが可能な装置のことである。センシングデバイスを用いることでユーザの現在位置を10
65に示すような受信機を用いて無線経由でシステムに通知することが可能となる。本例で
はUserAは第2の端末としてセンシングデバイスを用いているが，本端末には他のデバイ
スや端末，アプリケーションを用いることも考えられるし，UserAが複数端末を利用せず
，64の情報端末のみ用いている場合も考えられる。

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

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

その時のメッセージ例を図６に示す。図６はサブスクライブがSIPで行われている場合
のメッセージ例である。UserAはサブスクライブ対象を示すリクエストライン101，Toヘッ
ダ102にはサブスクライブ対象となる相手ユーザやグループのSIP-URIを示さずに自分のSI
P-URIを示している。リクエストライン，Toヘッダは，SIPメッセージの転送規定上，必ず
記述する必要があるが本例で示した自分のSIP-URIの様に，SIPメッセージがサーバ１に転
送されるSIP-URIならばどのような値でも構わない。また，サブスクライブの条件をConta
ctヘッダ内部の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から20
1までの処理を行う必要がないので，ステップ202まで進み，図17のステップ212，213，21
4の処理にてマッチしたユーザがいなかったことをサブスクライバに通知してステップ215
にて処理が終了する。

ステップ195で条件にマッチしたユーザがいることを確認した場合，ステップ196にて公
開プレゼンス制御モジュール8でデータベース31のパーミッション情報管理テーブル32を
検索する。これは、もしユーザがサブスクライバに対して自分のプレゼンス情報を公開し
ないという設定を行っていた場合には、当該ユーザのプレゼンス情報がサブスクライバの
指定した条件にマッチしたとしても、条件にマッチしたことをサブスクライバには告げな
いという制御を行うためである。この制御を行うことによって、非公開設定をしているユ
ーザのプレゼンス情報が条件にマッチしたことをサブスクライバに告げてしまう、つまり
暗にプレゼンス情報を公開してしまうことを防止することができる。パーミッション情報
管理テーブルは図14のテーブル171様な構成となっており，173に示すアクセス対象ユーザ
が172に示すアクセスユーザに対してどのようなプレゼンス情報を公開するかについてパ
ーミッション情報174に記述されている。このパーミッションについては特願2004−10864
2のマルチレベルパーミッション機能を用いて設定された内容を用いてもよい。パーミッ
ション情報管理テーブル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が”設計部”であることより，レコード1
57，158両方にマッチする。この場合，条件指定が詳細なレコードを優先する。本例では
レコード157の方が条件とするプレゼンス項目の数が多く，詳細な条件となっているので
レコード157にマッチしたとみなす。このマッチ処理の優先順位については本例の方法以
外の方法で実現してもよい。

本例ではレコード157にマッチしたとみなしたので，レコード157の割り当てテンプレー
ト152を確認する。本例では”A”と記述してあるが，この値はテンプレート管理テーブル
35で管理しているテンプレート値である。テンプレート管理テーブル35の詳細なテーブル
構成を図13のテーブル161に示す。このテーブルではテンプレート名称162が”A”である
レコードでは公開プレゼンス163，164，165の値が”location”，”comment”，”materi
al”と指定されている。つまり，これら3つのプレゼンスが公開されるという意味である
。結果，UserAが”location=会議室”，”section=設計部”のプレゼンスを持ちサブスク
ライブを行っている場合，マッチした他ユーザの”location”，”comment”，”materia
l”のプレゼンス項目を参照することが可能という事である。本例では図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-iet
f-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のような問い合わせを受けており、それに対して公開を許可する応答をしていたからUs
erAにプレゼンス情報が送信されている。この問い合わせを受けて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のサブスクライブ条件に含まれているのでステップ2
36へと処理が進む。

次からのステップ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に進む。本例ではUs
erBが対象にする条件付サブスクライブを行っていたのでステップ254に処理が進む。
ステップ254では条件内容とプレゼンス情報更新ユーザの更新後のプレゼンス情報を比較
する。

その後、ステップ255でサブスクライブ条件とプレゼンス情報更新ユーザの更新後のプ
レゼンス情報がマッチしなかった場合、ステップ256からステップ261までの処理をスキッ
プしてステップ262で処理を終了する。マッチした場合はステップ256に処理が進む。本例
ではUserBの条件にUserAの新しいプレゼンス情報がマッチしたので、ステップ256へと処
理が進む。この条件マッチングを行うことで，UserAがプレゼンス情報を更新した結果他
ユーザであるUserBのサブスクライブ条件にマッチしているユーザを更新することが可能
となる。

ステップ256からステップ259までの処理は図16のフローチャートで述べた図18のステッ
プ239からステップ243と同様にパーミッション関係の処理である。パーミッションの処理
が終わった後、プレゼンス情報を公開することを判断した場合に限り、ステップ260にてU
serBに対して新規にマッチしたユーザを通知する。また、これらパーミッション処理はシ
ーケンス図のステップ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以内と範囲を指
定している。このように条件に範囲を指定することで，条件にマッチしてサブスクライブ
の対象となるユーザに幅を持たせることが可能となる。それぞれのプレゼンス情報”loca
tion”の値は277、278、279の値となっている。この時それぞれのユーザが指定するサブ
スクライブ条件が異なる(範囲が異なる)ため、サブスクライブ対象が非対称となっている
。つまり280に示すようにＣの条件にマッチしている他ユーザはおらず、Ｃは他ユーザの
プレゼンス情報を閲覧していないのに対して、Ｂは281のようにＣのプレゼンス情報を閲
覧している。また、ＢとＡについては281、282のように対称でサブスクライブを行ってお
り、互いにプレゼンス情報を閲覧している。条件の指定の仕方によりこのような非対称な
状態でのサブスクライブが発生する可能性がある。各ユーザは実施例１の様なシステム上
で各自独立した条件を設定することが可能である。この仕組みを利用して各ユーザが別々
のサブスクライブ条件をサーバに提示することでこの様な非対称なサブスクライブが実現
する。

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

複数の端末の状態情報を管理するサーバを備えた状態情報管理システムであって、
上記サーバは、
上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態
情報を上記第１の端末に送信する送信部を有し、
上記状態情報抽出条件は、上記他の端末を示す情報、上記他の端末のユーザを示す情報、
または上記他の端末もしくは上記他の端末のユーザが属するグループを示す情報のいずれ
でもないことを特徴とする状態情報管理システム。
複数の端末の状態情報を管理するサーバを備えた状態情報管理システムであって、
上記サーバは、
上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態
情報を上記第１の端末に送信する送信部を有し、
上記送信部は、上記状態情報抽出条件に合致する他の端末が増加または減少した場合には
、上記増加または減少を反映した一または複数の他の端末の新たな状態情報をあらためて
上記第１の端末に送信することを特徴とする状態情報管理システム。
請求項１または２に記載の状態情報管理システムであって、
上記状態情報抽出条件は、状態情報の値の少なくとも一部を指定したものであり、
上記送信部は、上記状態情報抽出条件で指定された状態情報の値の少なくとも一部と合致
する状態情報を有する上記他の端末の状態情報を上記第１の端末に送信することを特徴と
する状態情報管理システム。
請求項３記載の状態情報管理システムであって、
上記状態情報抽出条件は、状態情報の値の範囲を指定したものであることを特徴とする状
態情報管理システム。
請求項４記載の状態情報管理システムであって、
上記状態情報抽出条件は、上記第１の端末の状態情報の値と一定の距離内にある状態情報
の値を指定したものであることを特徴とする状態情報管理システム。
請求項５記載の状態情報管理システムであって、
上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴と
する状態情報管理システム。
請求項６記載の状態情報管理システムであって、
上記状態情報の値は、端末または該端末のユーザの所在地であり、上記距離は物理的な距
離または道のりに基づいて定められた距離であることを特徴とする状態情報管理システム
。
請求項６記載の状態情報管理システムであって、
上記状態情報の値は、端末のユーザの役職名であって、上記距離は上記役職名間の組織階
層上の近さを表す論理的な距離であることを特徴とする状態情報管理システム。
請求項３記載の状態情報管理システムであって、
上記状態情報抽出条件は、上記第１の端末の状態情報との関係が一定の条件を満たす状態
情報の値を指定するものであり、
上記送信部は、上記一定の条件を満たす値を有する他の端末の状態情報を上記第１の端末
に送信することを特徴とする状態情報管理システム。
請求項９記載の状態情報管理システムであって、
上記一定の条件とは、上記第１の端末の状態情報の値と同一の値であるという条件である
ことを特徴とする状態情報管理システム。
請求項９記載の状態情報管理システムであって、
上記一定の条件とは、上記第１の端末の状態情報の値と一定の距離にある値であるという
条件であることを特徴とする状態情報管理システム。
請求項１１記載の状態情報管理システムであって、
上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴と
する状態情報管理システム。
請求項９記載の状態情報管理システムであって、
上記状態情報には複数の項目が含まれており、
上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と同じ項目に対す
る条件であることを特徴とする状態情報管理システム。
請求項９記載の状態情報管理システムであって、
上記状態情報には複数の項目が含まれており、
上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と一致しない項目
に対する条件であることを特徴とする状態情報管理システム。
請求項１または２記載の状態情報管理システムであって、
上記送信部は、上記一または複数の他の端末のうち一部の限定された一または複数の他の
端末の状態情報のみを上記第１の端末に送信し、
上記他の端末を限定する条件は、該他の端末の状態情報の値には基づかずに限定する条件
であることを特徴とする状態情報管理システム。
請求項１５記載の状態情報管理システムであって、
上記他の端末を限定する条件は、上記第１の端末が指定することを特徴とする状態情報管
理システム。
請求項１６記載の状態情報管理システムであって、
上記他の端末を限定する条件とは、上記第１の端末があらかじめ指定した他の端末のリス
トに含まれる端末のみに限定するという条件であることを特徴とする状態情報管理システ
ム。
請求項１５記載の状態情報管理システムであって、
上記他の端末を限定する条件は、該システムの管理者が設定することを特徴とする状態情
報管理システム。
請求項１５記載の状態情報管理システムであって、
上記他の端末を限定する条件とは、上記一または複数の他の端末のうち状態情報の公開を
拒否する他の端末を除くという条件であることを特徴とする状態情報管理システム。
請求項１９記載の状態情報管理システムであって、
上記状態情報の公開を拒否する他の端末は、公開を拒否する状態情報の値、または公開を
拒否する相手端末の少なくともいずれか一方を、予め該サーバに登録しておくことを特徴
とする状態情報管理システム。
請求項１９記載の状態情報管理システムであって、
上記サーバは、
上記一または複数の端末に対して状態情報公開の可否を問い合わせることを特徴とする状
態情報管理システム。
請求項２１記載の状態情報管理システムであって、
上記問い合わせは、上記状態情報抽出条件に合致した上記他の端末に対して行われること
を特徴とする状態情報管理システム。
請求項２記載の状態情報管理システムであって、
上記新たな状態情報は、上記第１の端末の状態情報が更新された際に、上記第１の端末に
送信されることを特徴とする状態情報管理システム。
請求項２記載の状態情報管理システムであって、
上記新たな状態情報は、上記第１の端末以外の端末のいずれかの状態情報が更新された際
に、上記第１の端末に送信されることを特徴とする状態情報管理システム。
複数の端末の状態情報を管理する状態情報管理サーバであって、
上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態
情報を上記第１の端末に送信する送信部を有し、
上記状態情報抽出条件は、上記他の端末を示す情報、上記他の端末のユーザを示す情報、
または上記他の端末もしくは上記他の端末のユーザが属するグループを示す情報のいずれ
でもないことを特徴とする状態情報管理サーバ。
複数の端末の状態情報を管理する状態情報管理サーバであって、
上記複数の端末のうちの第１の端末から状態情報公開要求を受信する受信部と、
上記状態情報公開要求から状態情報抽出条件を抽出する制御部と、
上記複数の端末のうちの上記状態情報抽出条件に合致する一または複数の他の端末の状態
情報を上記第１の端末に送信する送信部を有し、
上記送信部は、上記状態情報抽出条件に合致する他の端末が増加または減少した場合には
、上記増加または減少を反映した一または複数の他の端末の新たな状態情報をあらためて
上記第１の端末に送信することを特徴とする状態情報管理サーバ。
請求項２５または２６に記載の状態情報管理サーバであって、
上記状態情報抽出条件は、状態情報の値の少なくとも一部を指定したものであり、
上記送信部は、上記状態情報抽出条件で指定された状態情報の値の少なくとも一部と合致
する状態情報を有する上記他の端末の状態情報を上記第１の端末に送信することを特徴と
する状態情報管理サーバ。
請求項２７記載の状態情報管理サーバであって、
上記状態情報抽出条件は、状態情報の値の範囲を指定したものであることを特徴とする状
態情報管理サーバ。
請求項２８記載の状態情報管理サーバであって、
上記状態情報抽出条件は、上記第１の端末の状態情報の値と一定の距離内にある状態情報
の値を指定したものであることを特徴とする状態情報管理サーバ。
請求項２９記載の状態情報管理サーバであって、
上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴と
する状態情報管理サーバ。
請求項３０記載の状態情報管理サーバであって、
上記状態情報の値は、端末または該端末のユーザの所在地であり、上記距離は物理的な距
離または道のりに基づいて定められた距離であることを特徴とする状態情報管理サーバ。
請求項３０記載の状態情報管理サーバであって、
上記状態情報の値は、端末のユーザの役職名であって、上記距離は上記役職名間の組織階
層上の近さを表す論理的な距離であることを特徴とする状態情報管理サーバ。
請求項２７記載の状態情報管理サーバであって、
上記状態情報抽出条件は、上記第１の端末の状態情報との関係が一定の条件を満たす状態
情報の値を指定するものであり、
上記送信部は、上記一定の条件を満たす値を有する他の端末の状態情報を上記第１の端末
に送信することを特徴とする状態情報管理サーバ。
請求項３３記載の状態情報管理サーバであって、
上記一定の条件とは、上記第１の端末の状態情報の値と同一の値であるという条件である
ことを特徴とする状態情報管理サーバ。
請求項３３記載の状態情報管理サーバであって、
上記一定の条件とは、上記第１の端末の状態情報の値と一定の距離にある値であるという
条件であることを特徴とする状態情報管理サーバ。
請求項３５記載の状態情報管理サーバであって、
上記距離とは、物理的または論理的な距離に基づいて定められた距離であることを特徴と
する状態情報管理サーバ。
請求項３３記載の状態情報管理サーバであって、
上記状態情報には複数の項目が含まれており、
上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と同じ項目に対す
る条件であることを特徴とする状態情報管理サーバ。
請求項３３記載の状態情報管理サーバであって、
上記状態情報には複数の項目が含まれており、
上記一定の条件とは、上記第１の端末の状態情報の一または複数の項目と一致しない項目
に対する条件であることを特徴とする状態情報管理サーバ。
請求項２５または２６記載の状態情報管理サーバであって、
上記送信部は、上記一または複数の他の端末のうち一部の限定された一または複数の他の
端末の状態情報のみを上記第１の端末に送信し、
上記他の端末を限定する条件は、該他の端末の状態情報の値には基づかずに限定する条件
であることを特徴とする状態情報管理サーバ。
請求項３９記載の状態情報管理サーバであって、
上記他の端末を限定する条件は、上記第１の端末が指定することを特徴とする状態情報管
理サーバ。
請求項４０記載の状態情報管理サーバであって、
上記他の端末を限定する条件とは、上記第１の端末があらかじめ指定した他の端末のリス
トに含まれる端末のみに限定するという条件であることを特徴とする状態情報管理サーバ
。
請求項３９記載の状態情報管理サーバであって、
上記他の端末を限定する条件は、該サーバの管理者が設定することを特徴とする状態情報
管理サーバ。
請求項４０記載の状態情報管理サーバであって、
上記他の端末を限定する条件とは、上記一または複数の他の端末のうち状態情報の公開を
拒否する他の端末を除くという条件であることを特徴とする状態情報管理サーバ。
請求項４３記載の状態情報管理サーバであって、
上記状態情報の公開を拒否する他の端末は、公開を拒否する状態情報の値、または公開を
拒否する相手端末の少なくともいずれか一方を、予め該サーバに登録しておくことを特徴
とする状態情報管理サーバ。
請求項４３記載の状態情報管理サーバであって、
上記一または複数の端末に対して状態情報公開の可否を問い合わせることを特徴とする状
態情報管理サーバ。
請求項４５記載の状態情報管理サーバであって、
上記問い合わせは、上記状態情報抽出条件に合致した上記他の端末に対して行われること
を特徴とする状態情報管理サーバ。
請求項２６記載の状態情報管理サーバであって、
上記新たな状態情報は、上記第１の端末の状態情報が更新された際に、上記第１の端末に
送信されることを特徴とする状態情報管理サーバ。
請求項２６記載の状態情報管理サーバであって、
上記新たな状態情報は、上記第１の端末以外の端末のいずれかの状態情報が更新された際
に、上記第１の端末に送信されることを特徴とする状態情報管理サーバ。