JP4365497B2 - 状態管理方法及び状態管理システム - Google Patents
状態管理方法及び状態管理システム Download PDFInfo
- Publication number
- JP4365497B2 JP4365497B2 JP33157599A JP33157599A JP4365497B2 JP 4365497 B2 JP4365497 B2 JP 4365497B2 JP 33157599 A JP33157599 A JP 33157599A JP 33157599 A JP33157599 A JP 33157599A JP 4365497 B2 JP4365497 B2 JP 4365497B2
- Authority
- JP
- Japan
- Prior art keywords
- user
- state
- status
- user terminal
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術の分野】
本発明は、移動体通信網やインターネットなどのネットワークに接続されたユーザの状態を管理する状態管理システムに関する。
【０００２】
【従来の技術】
ネットワーク上でユーザ状態を共有し互いに参照するための状態管理システムとして、ＩＣＱやヤフーページャなど様々なものが提供されている。図１９は、従来の状態管理システムの一例を示す構成図である。状態管理システムは、サーバ１９１とユーザ端末１９２とがネットワーク１９３により接続されて構成されている。ネットワーク１９３としては、インターネットやイントラネット、移動体通信網などが挙げられる。ユーザ端末１９２としては、ＰＣ(Personal Computer)、ＷＳ(Work Station)、携帯電話、ＰＨＳ(Personal Handy-Phone System)などがあげられる。ユーザの状態は、ユーザ自身により入力されたり自動的に検出され、サーバ１に蓄積され、他のユーザにより参照される。
【０００３】
ユーザ状態には、ネットワークへ「接続中」や「未接続」など自動的に検出され得る状態もあるが、「離席」や「忙しい」などユーザ自身で入力しなければならない状態もある。また、状態管理システムによっては、ユーザ端末１９２上のアプリケーションの状態に応じ、「離席」や「在席」などの状態が自動的に検出される。
【０００４】
図２０は、状態管理システム上の移動通信端末におけるユーザ状態の表示例を示す。図２０では、複数のユーザの一覧が表示され、各ユーザの状態を表す絵文字がユーザ名と共に表示されている。
【０００５】
図２１は、ＰＣにおけるユーザ状態の表示例を示す画面例である。図２１（ａ）では、複数のユーザの一覧が表示され、各ユーザの状態を表すアイコンがユーザ名とともに表示されている。図２１（ｂ）は、一人のユーザについての状態が詳細に表示されている。
【０００６】
さらに、ユーザ同士で予め形成したグループ単位でユーザ状態を表示する状態管理システムも提供されている。図２２（ａ）は、移動通信端末においてグループ単位でユーザ状態を表示する例を示す。図２２（ｂ）では、グループ中の一人のユーザについての状態が詳細に表示されている。図２３は、ＰＣにおいてユーザ状態をグループ単位で表示する例である。ウインドウの左側に、グループ構成ユーザの名前と、その状態を表すアイコンとが表示されている。
【０００７】
【発明が解決しようとする課題】
前述した従来の状態管理システムにおいては、各ユーザの状態はユーザ自身が入力するか自動的に検知されることにより設定される。しかし、ユーザ自身で設定しなければならない状態は、どうしても設定を忘れてしまうことが多い。例えば、席を離れる際に自状態を「離席」に設定しておいても、席に戻ったときに自状態を「在席」に設定し直すことを忘れてしまう。
【０００８】
また、ユーザ状態を自動的に検出する手法としては、スクリーンセーバの状態やキーボード、マウスからの入力状態などに基づいて、ユーザ状態を設定するものが主である。例えば、スクリーンセーバが動作していれば、そのユーザ端末を操作するユーザの状態を「不在」に設定する。また、キーボード入力やマウス操作が常時生じていれば、ユーザ状態を「在席」に設定する。
【０００９】
しかし、スクリーンセーバが動作中であってもユーザ端末の前にユーザがいる場合がある。また、入力操作が行われていても、操作しているのはユーザ自身ではなく他人である場合もある。従って、自動検出されるユーザ状態と実際のユーザ状態とは、異なることが少なくないのが現状である。従って、正しいユーザ状態の設定は、ユーザ自身による入力に頼らざるを得ない。
【００１０】
今後、ユーザ端末がネットワークに実質的にあるいは擬似的に常時接続している状況が想定される。このような状況下で使用される状態管理システムでは、ユーザ状態の設定を忘れずに行うことがシステムの目的上重要である。ユーザ状態の設定忘れを回避するために、一定時間毎に自状態の入力を促したり、他のユーザ状態を参照する毎に入力を促すことが考えられるが、逆に面倒な場合が多く、使いやすいシステムとは言い難い。一方で、自状態を設定していないユーザが他のユーザの状態を参照できるとすれば、ユーザ間に不公平が生じる。
【００１１】
本発明では、ユーザの入力負担を軽減しつつ、ユーザ間の不公平が生じないようにユーザ状態の設定を促進する状態管理システムを提供する。
【００１２】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理方法であって、
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積し、
Ｂ；前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定し、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する、
状態管理方法を提供する。
判定条件は、システム側で設定またはユーザにより設定される。他のユーザ状態の参照要求が生じた場合、参照先状態を要求元に通知するか否かを、両者の新しさの差が判定条件で定められた範囲内か否かに基づいて判断する。参照要求を許可する場合は、通常の状態通知を行う。許可しない場合、その旨を通知する文字メッセージや、参照先状態に「？」マークを埋め込んだ状態通知を行う。ユーザは、参照先状態を知りたければ、自状態を入力すればよいことが分かる。なお、参照先及び要求元は、単一のユーザであっても良いし、複数のユーザを含むユーザグループであっても良い。
【００１３】
本願第２発明は、前記第１発明において、前記判定を、要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況とを比較し、両者の差が判定条件に定められた所定の範囲内か否かにより行う状態管理方法を提供する。
【００１４】
例えば、要求元状態が参照先状態に比して古すぎる場合、参照要求を許可しない。両者の公平を保つためである。
【００１５】
本願第３発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理システムであって、蓄積手段と判定手段と通知手段とを備える状態管理システムを提供する。
【００１６】
蓄積手段は、要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積している。判定手段は、前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する。通知手段は、前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する。
【００１７】
前記第１発明と同様の作用効果を有する。
【００１８】
本願第４発明は、前記第３発明において、判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える状態管理システムを提供する。
【００１９】
判定条件をシステム側で予め準備しておいても良いが、各ユーザが設定できるようにしても良い。例えば、ユーザＡは、他のユーザからの参照要求に対して「条件１」を設定し、条件１を満たす他のユーザに対して自状態の参照を許可する。一方、設定を行っていないユーザへの参照要求は、システム側で予め準備した所定の判定条件に従い処理される。
【００２０】
本願第５発明は、前記第３発明において、前記蓄積手段は、参照先のユーザ端末と、要求元のユーザ端末と、参照先が要求元に対して設定している判定条件とを対応付けて蓄積し、要求元毎の判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える状態管理システムを提供する。
【００２１】
設定手段は、相手が指定された判定条件の設定をユーザから受け付ける。例えば、ユーザＡは、自状態を参照するための条件として、ユーザＢに対しては「条件１」を、ユーザＣに対しては「条件２」を設定する。すると、ユーザＢがユーザＡの状態を参照しようとする場合は「条件１」を、ユーザＣがユーザＡの状態を参照しようとする場合は「条件２」を、満足しなければならない。また、設定のない他ユーザに対しては、システム側で予め準備した所定の判定条件を適用することが考えられる。
【００２２】
本願第６発明は、前記第３発明において、ユーザのユーザ状態が変化した場合に新たなユーザ状態の通知を受けるユーザを監視者とし、監視者に自ユーザ状態が通知されるユーザを監視対象とし、両者を関連付けて蓄積している第２蓄積手段と、監視対象のユーザ状態が変化した場合、監視対象を参照先とした場合の判定条件に従い、監視対象のユーザ状態を監視者へ通知することを許可するか否かを判定し、判定結果を監視者のユーザ端末に通知する第２通知手段と、を備える状態管理システムを提供する。
【００２３】
例えば、第２蓄積手段には、監視対象のユーザＡと、ユーザＡの新たな状態を通知される監視者のユーザＢとが、対応付けられて蓄積されている。一方、ユーザＡが、ユーザＢに対し、判定条件として「条件１」を設定している。この場合、ユーザＡの状態が変化したとき、ユーザＢが「条件１」を満たしていなければ、ユーザＢに状態入力を促す通知がなされる。ユーザＢに状態の入力を促し、両者間の公平を保つためである。ユーザＢが「条件１」を満たしていれば、ユーザＡの状態がユーザＢに通知される。
【００２４】
本願第７発明は、前記第３発明において、前記判定の結果、参照要求が許可されない場合、要求元のユーザ端末に対し、要求元のユーザ状態の設定を要求する設定要求を送信する促進手段をさらに備える状態管理システムを提供する。
【００２５】
例えば、ユーザＢがユーザＡの状態を参照しようとしたが、判定条件を満たしていない場合を考える。促進手段は、例えばユーザＢの情報端末に対し、自状態の設定要求を送信する。ユーザＢが新たに自状態を設定すると、前記判定が変わり、参照が可能となるからである。
【００２６】
本願第８発明は、前記第３発明において、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間から参照先のユーザ状態の最終更新時間までの経過時間に基づいて行う状態管理システムを提供する。
【００２７】
例えば、経過時間が１日以上であれば、参照要求を許可しないと判定する。要求元ユーザ状態が、参照先ユーザ状態に比して古すぎるからである。
【００２８】
本願第９発明は、前記第３発明において、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降における、参照先のユーザ状態の更新回数に基づいて行う状態管理システムを提供する。
【００２９】
例えば、要求元状態が更新されて以降、参照先状態が３回以上更新されていれば、参照要求を許可しないと判定する。要求元は、参照先に比して、状態の更新を怠っていると考えられるからである。
【００３０】
本願第１０発明は、前記第３発明において、参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新された合計回数に基づいて行う状態管理システムを提供する。
【００３１】
例えば、要求元ユーザ状態が更新されて以降に、参照先ユーザグループ内で状態が５回以上更新されていれば、参照要求が許可されない。要求元ユーザは、参照先グループに比して、状態の更新を怠っていると考えられるからである。
【００３２】
本願第１１発明は、前記第３発明において、参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新されたユーザの合計人数に基づいて行う状態管理システムを提供する。
【００３３】
例えば、要求元状態が更新されて以降に、参照先ユーザグループ内において状態を更新したユーザが５人以上いれば、参照要求が許可されない。要求元は、参照先グループのユーザに比して、状態の更新を怠っていると考えられるからである。
【００３４】
本願第１２発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元ユーザ端末に参照先のユーザ状態を提供するサーバ端末に用いられ、下記Ａ〜Ｃ段階を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積する段階、
Ｂ；前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況及び参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する段階、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する段階。
【００３５】
前記第１発明と同様の作用効果を有する。記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）などが挙げられる。
【００３６】
本願第１３発明は、ネットワークに接続され、他のユーザのユーザ状態の参照要求をユーザから受け付け、参照先のユーザ状態を取得してユーザに通知可能なユーザ端末に用いられ、下記Ａ〜Ｃ段階を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元の前記ユーザに通知するか否かを判定するための判定条件を蓄積する段階、
Ｂ；前記他のユーザ状態の参照要求を行った要求元の前記ユーザのユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元の前記ユーザからの参照要求を許可するか否かを判定する段階、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元の前記ユーザに通知する段階。
【００３７】
前記第１発明と同様の作用効果を有する。記録媒体としては、前記第１２発明と同様のものを挙げることができる。
【００３８】
【発明の実施の形態】
次に、本発明に係る状態管理システムについて、図面を参照しながら具体的に説明する。
【００３９】
＜第１実施形態例＞
［構成］
図１は、第１実施形態例に係る状態管理システムの全体構成図である。図１に示す状態管理システムは、サーバ１とユーザ端末２とがインターネットまたはイントラネット３を介して接続されて構成されている。ユーザ端末２としては、ＰＣ、ＷＳ、移動通信端末などが挙げられる。携帯電話やＰＨＳなどの移動通信端末は、移動体通信網４を介してインターネットなど３に接続されている。
【００４０】
（１）ユーザ端末
ユーザ端末２は、前述した従来の状態管理システムにおけるユーザ端末２と同様の構成を有している。すなわち、ユーザ端末２は、第１通信部２１、自状態設定部２２、自状態通知部２３、状態参照部２４及び状態表示部２５を有している。
【００４１】
第１通信部２１は、ユーザ端末２とサーバ１との間でデータを送受信する。
【００４２】
自状態設定部２２は、ユーザからの自状態の入力を受け付けたり、ユーザ端末２上のアプリケーションの状態からユーザ状態を自動的に検知する。また、自状態設定部２２は、状態変化を監視したいユーザの指定をユーザから受け付ける。
【００４３】
自状態通知部２３は、入力または検知された自状態や、設定された判定条件をサーバ１に通知する。
【００４４】
状態参照部２４は、グループまたは個人の指定をユーザから受け付け、サーバ１に通知し、指定先の状態をサーバ１から取得する。また、状態参照部２４は、監視対象に指定したユーザの新たな状態をサーバ１から取得する。
【００４５】
状態表示部２５は、サーバ１から取得したユーザ状態を表示する。
【００４６】
以上の機能に加え、本システムにおけるユーザ端末は、以下の新たな機能を有している。自状態設定部２２は、後述する判定条件の設定をユーザから受け付け、自状態通知部２３を介してサーバ１に送信する。また、自状態設定部２２は、判定条件の入力を容易にするために、ウインドウを表示する。
【００４７】
（２）サーバ
（２−１）従来のサーバ機能
サーバ１は、従来の状態管理システムにおけるサーバ１の機能に加え、さらに条件ＤＢ１０１、判定条件設定部１０２、判定部１０３を有している。従来のサーバ機能とは、第２通信部１０４、状態ＤＢ１０５、グループＤＢ１０６、通知ＤＢ１０７、設定部１０８、参照部１０９、通知部１１０及びグループ管理部１１１に相当する。
【００４８】
第２通信部１０４は、ユーザ端末２とサーバ１との間でデータの送受信を行う。
【００４９】
状態ＤＢ１０５には、各ユーザの状態が蓄積されている。
【００５０】
グループＤＢ１０６には、何らかの方法により形成されたグループの構成ユーザが、グループ名とともに蓄積されている。
【００５１】
通知ＤＢ１０７には、監視対象と監視者とが、対応付けられて蓄積されている。ここで、監視対象及び監視者とは、次のような関係にある。監視対象のユーザ状態が変化すると、その新たな状態が監視者に通知される。
【００５２】
設定部１０８は、ユーザ端末２から受信した各ユーザの状態を、状態ＤＢ１０５に記憶する。また、設定部１０８は、ユーザ端末２から監視対象の指定を受け付け、前記ユーザ端末２を操作するユーザを監視者とし、監視対象と関連付けて通知ＤＢ１０７に蓄積する。
【００５３】
参照部１０９は、ユーザ端末２からの状態参照要求を受信し、参照先の状態を状態ＤＢ１０５から取得してユーザ端末２に渡す。
【００５４】
グループ管理部１１１は、ユーザにより形成されたグループの構成ユーザ及びグループ名をユーザ端末２から受け取り、グループＤＢ１０６に格納する。また、グループ管理部１１１は、ユーザ端末２からグループを指定する状態参照要求を受信した場合、指定グループの構成ユーザを参照部１０９に渡す。
【００５５】
通知部１１０は、新たなユーザ状態が状態ＤＢ１０５に蓄積された場合、状態が変化したユーザを監視対象に指定している監視者に、新たなユーザ状態を通知する。以下、この通知を状態通知という。通知された監視対象の状態は、状態参照部２４により取得され、状態表示部２５により監視者へ通知される。この状態通知に先立ち、監視者の状態に基づいて状態通知が可能か否かを判断し、判断に従って状態通知を行うことも可能である。
【００５６】
（２−２）本システムにおけるサーバ機能
本システムにおいては、条件ＤＢ１０１、判定条件設定部１０２及び判定部１０３が新たにサーバ１に設けられている。条件ＤＢ１０１には、条件テーブルが蓄積されている。条件テーブルについては、詳細を後述する。
【００５７】
判定条件設定部１０２は、ユーザ端末２から所定の判定条件を受信し、条件ＤＢ１０１に格納する。この判定条件は、ユーザ端末２から参照要求があった場合、参照先の状態を要求元に通知しても良いか否かを判定するために用いられる。また、監視者に対し、状態通知を行っても良いか否かを判定するためにも用いられる。判定条件については、詳細を後述する。
【００５８】
判定条件は、システム側で予め設定しておいても良いが、本実施形態例においては個人またはグループがそれぞれ判定条件を設定可能である。また、ユーザは、必要に応じ、他の個人やグループに対して個別の判定条件を設定可能である。
【００５９】
判定部１０３は、ユーザ端末２からの参照要求があった場合、参照要求に基づいて参照先の状態を要求元ユーザ端末２に送信するか否かの判定を行う。また、判定部１０３は、状態ＤＢ１０５に新たな状態が設定された場合、新たな状態の状態通知を行うか否かの判定を行う。さらに、判定部１０３は、判定結果がＮＧの場合、その旨のメッセージをユーザ端末２に通知し、状態設定を要求する。本実施形態例においては、システム側でデフォルトの判定条件が予め設定されており、ユーザが判定条件を設定していない場合にはデフォルトの判定条件が用いられる。
他の構成要素の機能は、前記従来の状態管理システムと同様である。但し、参照部１０９は、参照要求をユーザ端末２から受け取ると、判定部１０３の判定結果に従って参照先の状態の送信を行う。判定により参照要求が許可されない場合、参照部１０９は、参照先状態に例えば特定のマーク「？」を埋め込み、ユーザ端末２に送信する。要求された参照先状態は、参照が許可されなかったことをユーザに示すためである。また、通知部１１０も、参照部１０９と同様に、判定部１０３の判定結果に従って状態通知を行う。
【００６０】
（２−３）判定条件
本実施形態例においては、以下の４つの判定条件及びこれらの組み合わせにより、参照先または監視対象の状態を要求元または監視者に通知しても良いか否かの判定を行う。
【００６１】
［１］時間
［２］回数
［３］合計回数
［４］人数
条件［１］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻から参照先ユーザ状態の最終更新時刻までの経過時間が所定時間以上であれば、通知をしないと判定する。要求元ユーザ状態が、参照先状態に比して古すぎると考えられるからである。
【００６２】
例えば判定時間が１日であり、ユーザＡがユーザＢの状態を参照する場合を考える。ユーザＢの状態が、ユーザＡの状態の最終更新時刻から１日以内に更新されていれば、ユーザＡはユーザＢの状態を参照することがきる。この場合、判定は「ＯＫ」となる。そうでなければ判定は「ＮＧ」となる。この場合、ユーザＡは、新たな自状態を設定しなければ、ユーザＢの状態を参照出来ない。ユーザＢの状態はユーザＡの状態に比して新しいので、両者間の公平を図るためである。
【００６３】
条件［２］の例としては以下のようなものがある。要求元ユーザ状態の最終更新時刻以降において参照先ユーザ状態の更新回数が所定回数以上であれば、通知をしないと判定する。例えば、回数が３回であり、ユーザＡがユーザＢの状態を参照する場合を考える。ユーザＡの状態の最終更新時刻以降に、ユーザＢの状態が更新された回数が２回以下であれば、判定はＯＫとなる。この場合、ユーザＡはユーザＢの状態を参照することができる。
【００６４】
しかし、ユーザＡの状態の最終更新時刻以降にユーザＢの状態が３回以上更新されていれば、ユーザＡのユーザＢに対する参照要求の判定は「ＮＧ」となる。この場合、ユーザＡは、新たな自状態を設定しなければ、ユーザＢの状態を参照出来ない。ユーザＢの状態を参照しようとしているユーザＡの状態はユーザＢの状態に比して古すぎると考えられるので、両者間の公平を図るためである。
【００６５】
条件［３］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻以降に、参照先グループ内において構成ユーザが状態を更新した合計回数が所定回数以上であれば、通知をしないと判定する。なお、条件［３］は、何らかの方法で形成されるユーザグループが設定可能な判定条件である。
【００６６】
例えば、合計回数が「３回以上」と設定されており、ユーザＡがグループＣの状態を参照する場合を考える。要求元ユーザＡの状態の最終更新時刻以降に、グループＣ内で構成ユーザが状態を更新した合計回数が３回以上であれば、判定は「ＮＧ」となる。グループＣの状態に比して、ユーザＡの状態は古すぎると考えられるからである。
【００６７】
条件［４］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻以降に、参照先グループ内のユーザのうち状態を更新したユーザの合計人数が所定人数以上であれば、通知をしないと判定する。この条件は、前記条件［３］と同様に、グループが設定可能な条件である。
【００６８】
例えば、合計人数が「３人」と設定されており、ユーザＡがグループＤの状態を参照する場合を考える。ユーザＡの状態の最終更新時刻以降に、グループＤ内で状態を更新したユーザが３人以上であれば、判定は「ＮＧ」となる。ユーザＡの状態は、グループＤの状態に比して古すぎると考えられるからである。
【００６９】
（２−４）条件テーブル
図２は、条件ＤＢ１０１に蓄積されている条件テーブルの概念説明図である。条件テーブルには、参照先、要求元及び判定条件が、対応付けられて記憶されている。例えば、図２においてグループＸはグループＹに対し、判定条件として「時間≧１２時間」を設定している。この判定条件は、グループＹ（要求元）の構成ユーザがグループＸ（参照先）の状態を参照しようとした場合に適用される。また、この判定条件は、グループＸ内のユーザについて、グループＹ内のユーザに状態通知をする場合にも適用される。
【００７０】
また、図２においてユーザＣはユーザＢに対し、判定条件として「回数≧３回」を設定している。この判定条件は、ユーザＣ（要求元）がユーザＢ（参照先）の状態を参照しようとした場合と、ユーザＢの状態をユーザＣに状態通知する場合とに適用される。
【００７１】
（３）画面例
次に、画面例に基づいて本発明の作用を説明する。
【００７２】
図３は、状態管理システムにおけるメニュー画面の一例である。メニュー画面では、選択可能な処理や、ユーザが既に作成したグループなどが表示される。例えばメニュー画面において、「私のいま！」を選択すると、ユーザの自状態を設定するための状態設定画面が表示される。また、「コミュニティ作成」を選択すると、グループを作成することが出来る。
【００７３】
図４（ａ）〜（ｃ）は、ユーザが自状態を設定するための状態設定画面の一例である。図４（ａ）及び（ｂ）は、設定対象を「気持ち」や「天気」などいくつかの分類から選択したり、自状態を表す文字を入力するための画面である。図４（ｃ）は、自状態を表す絵文字を選択入力するための画面である。また図４（ａ），（ｂ）において、画面の下部分には、自状態を文字により表現するためのフィールドが設けられている。
【００７４】
図５（ａ）〜（ｃ）及び図６（ａ）〜（ｃ）は、ユーザが個人またはグループの状態を参照しようとしたが、判定結果により相手状態を参照できない場合に表示される画面例である。図５の画面例は、移動通信端末で表示される画面例である。図６の画面例は、ＰＣ上で表示される画面例である。
図５（ａ）及び図６（ａ）は、１人のユーザの状態を参照しようとしたが、参照できない場合の画面例を示す。図５（ｂ）及び図６（ｂ）では、複数のユーザ一覧とともに各ユーザの状態が表示される場合に、何人かのユーザの状態が参照できないことを示す画面例である。これらのユーザについては、状態に「？」など特定のマークが表示されている。図５（ｃ）及び図６（ｃ）は、あるグループの状態を参照しようとしたが参照できない場合の画面例を示している。
【００７５】
図７（ａ）及び（ｂ）は、前記図５及び図６の画面を表示するに先立ち、自状態の設定を促す場合に表示される画面例である。図７（ａ）は、個人の状態を参照しようとしたが参照できない場合に表示される画面例である。図７（ｂ）は、グループの状態を参照しようとしたが参照できない場合に表示される画面例である。いずれの画面例においても、「自状態設定ボタン」を押すと、前記図４に例示する状態設定画面が表示される。逆に、「ＯＫボタン」を押すと、前記図５または図６に例示する画面が表示される。
【００７６】
図８（ａ）及び（ｂ）は、状態通知に先立ち、監視者が監視対象の状態を参照できない場合に表示される画面例である。図８（ａ）は、監視対象が個人の場合に表示される画面例である。図８（ｂ）は、監視対象がグループの場合に表示される画面例である。「自状態設定」ボタン及び「ＯＫ」ボタンが押された場合の作用は、図７と同様である。
【００７７】
図９（ａ）及び（ｂ）は、判定条件を設定するための画面例である。図９（ａ）は、個人の判定条件を設定するための画面例である。図９（ｂ）は、グループの判定条件を設定するための画面例である。画面例において複数の条件を入力すれば、その組み合わせにより判定がなされる。例えば、図９（ｂ）では、時間及び人数が設定されている。「設定」ボタンを押すと、設定された判定条件がサーバ１に送信され、条件ＤＢ１０１に格納される。
【００７８】
［処理の流れ］
次に、判定部１０３が行う処理の流れについて、フローチャートを用いて具体的に説明する。図１０は、判定部１０３が行うメイン処理の流れを示すフローチャートである。なお、説明を容易にするため、個人からの参照要求及び個人への状態通知については、時間または回数のいずれかに基づいて判定する場合を例に取る。また、グループからの参照要求及びグループへの状態通知については、時間、合計回数または回数のいずれかに基づいて判定する場合を例に取る。
【００７９】
参照要求の受信または状態ＤＢ１０５の更新により、以下の処理が開始される。
【００８０】
ステップＳ１では、判定部１０３は、要求元が参照先に設定している判定条件を条件ＤＢ１０１から読み出す。状態ＤＢ１０５が更新された場合、判定部１０３は、状態が更新されたユーザまたはグループを監視対象に指定している監視者を、通知ＤＢ１０７から読み出す。次いで、判定部１０３は、監視対象が監視者に対して設定している判定条件を、条件ＤＢ１０１から読み出す。
【００８１】
以下において、状態参照要求が生じた場合における処理を説明するが、状態通知についても、参照先を監視対象、要求元を監視者、参照部１０９を通知部１１０に読み替えれば同様である。
【００８２】
ステップＳ２では、判定部１０３は、参照先がグループであるか否かを判断する。“ＹＥＳ”と判断すると、後述するステップＳ１０に移行する。“ＮＯ”と判断すると、ステップＳ３に移行する。
【００８３】
ステップＳ３では、判定部１０３は、判定条件が時間であるか否かを判断する。参照先が要求元に対する判定条件として時間を設定しているか、システムがデフォルトの判定条件として時間を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ４に移行する。“ＮＯ”と判断すると、後述するステップＳ８に移行する。
【００８４】
ステップＳ４では、判定部１０３は、後述する時間サブルーチンを実行する。すなわち、判定部１０３は、設定された時間に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００８５】
ステップＳ５では、判定部１０３は、判定結果がＯＫであるか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ６に移行する。“ＮＯ”と判断すると、後述するステップＳ７に移行する。
【００８６】
ステップＳ６では、判定結果に基づいて、参照部１０９が、参照先の状態を要求元のユーザ端末２に送信する。ユーザ端末２上では、送信された状態が表示される。その後処理を終了する。
ステップＳ７では、参照部１０９は、判定結果に従ってＮＧ処理を行う。例えば、前記図５や図６に示すように、参照先状態に「？」を埋め込み、ユーザ端末２に送信する。ユーザ端末２上では図５や図６に例示する画面が表示される。ユーザは、参照先状態を知りたいか否かの必要に応じ、自状態を入力すればよい。その後処理を終了する。
【００８７】
前記ステップＳ３において、判定条件が時間ではないと判断されると、ステップＳ８に移行する。ステップＳ８においては、判定部１０３は、判定条件が回数であるか否かを判断する。参照先が要求元に対する判定条件として回数を設定しているか、システムがデフォルトの判定条件として回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断するとステップＳ９に移行する。“ＮＯ”と判断すると、何も条件が設定されていないので前記ステップＳ６に移行し、参照先の状態が要求元に送信される。すなわち、判定条件が設定されていない場合には、無条件に参照が許可される。
【００８８】
ステップＳ９では、判定部１０３は、後述する回数サブルーチンを実行する。すなわち、判定部１０３は、設定された回数に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００８９】
前記ステップＳ２において、参照先がグループであると判断されると、ステップＳ１０に移行する。ステップＳ１０では、判定部１０３は、判定条件が時間であるか否かを判断する。参照先グループが要求元に対する判定条件として時間を設定しているか、システムがデフォルトの判定条件として時間を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ１１に移行する。“ＮＯ”と判断すると、後述するステップＳ１２に移行する。
【００９０】
ステップＳ１１では、判定部１０３は、後述するグループ時間サブルーチンを実行する。すなわち、判定部１０３は、設定された時間に基づいて、参照先グループの状態を、要求元に通知するか否かを判定する。
【００９１】
ステップＳ１２では、判定部１０３は、判定条件が合計回数であるか否かを判断する。参照先グループが要求元に対する判定条件として合計回数を設定しているか、システムがデフォルトの判定条件として合計回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断するとステップＳ１３に移行する。“ＮＯ”と判断すると、後述するステップＳ１４に移行する。
【００９２】
ステップＳ１３では、判定部１０３は、後述する合計回数サブルーチンを実行する。すなわち、判定部１０３は、設定された合計回数に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００９３】
ステップＳ１４では、判定部１０３は、判定条件が回数であるか否かを判断する。参照先グループが要求元に対する判定条件として回数を設定しているか、システムがデフォルトの判定条件として回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ１５に移行する。“ＮＯ”と判断すると判定条件の設定がないものと見なされ、前述のステップＳ６に移行する。すなわち、参照部１０９により参照先の状態が要求元に送信される。
【００９４】
ステップＳ１５では、判定部１０３は、後述する個別回数サブルーチンを実行する。すなわち、判定部１０３は、設定された回数に基づいて、参照先グループの状態を要求元に通知するか否かを判定する。
【００９５】
この処理に従えば、ユーザは、メッセージや特定のマークの表示により要求した参照先状態を参照できないことを通知される。しかし、その都度自状態を入力する必要はなく、参照先状態を知りたいか否かに応じて自状態を入力すればよい。従って、本実施形態例に係る状態管理システムは、ユーザに過度の負担を強いることなくユーザ状態の入力を促進してシステムの有効性を高め、しかもユーザ間の公平を保つことができる。図１０ではそれぞれの条件を単独で判定しているが、これを組み合わせ、「or」や「and」条件で最終的に「ＯＫ」か「NG」かを判定しても良い。
【００９６】
（２）時間サブルーチン
図１１は、時間サブルーチンの流れを示すフローチャートである。前記メイン処理においてステップＳ４に移行すると、以下の処理が開始される。
【００９７】
ステップＳ１０１では、判定部１０３は、要求元の状態が更新された最終時間を状態ＤＢ１０５から取得する。
【００９８】
ステップＳ１０２では、判定部１０３は、読み込んだ判定条件が、参照先ユーザにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ１０３に移行する。“ＮＯ”と判断すると、後述するステップＳ１０４に移行する。
【００９９】
ステップＳ１０３では、判定部１０３は、参照先ユーザが条件ＤＢ１０１に設定している設定時間を、閾値とする。
【０１００】
ステップＳ１０４では、判定部１０３は、システム側で設定しているデフォルト値の時間を閾値とする。
【０１０１】
ステップＳ１０５では、判定部１０３は、要求元状態の最終更新時間から参照先状態の最終更新時間までの経過時間が、閾値以上であるか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ１０６に移行する。これは、要求元状態が、参照先状態に比してあまりに古いことを意味する。“ＮＯ”と判断すると、後述するステップＳ１０９に移行する。
【０１０２】
ステップＳ１０６では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２では、自状態設定部２２が、前記図７または図８に示す画面を表示する。
【０１０３】
ステップＳ１０７では、判定部１０３は、要求元の状態が設定されたか否かを判断する。この判断は、例えば次のように行う。すなわち、所定時間内に応答がないかまたは前記図７または図８において「ＯＫ」ボタンをされた場合、“ＮＯ”と判断し、その他の場合には“ＹＥＳ”と判断する。“ＮＯ”と判断するとステップＳ１０８に移行する。“ＹＥＳ”と判断すると、ステップＳ１０９に移行する。なお、ステップＳ１０６〜１０７を省略することも可能である。
【０１０４】
ステップＳ１０８では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１０５】
ステップＳ１０９では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１０６】
（３）回数サブルーチン
図１２は、回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理において、ステップＳ９に移行すると以下の処理が開始される。
【０１０７】
ステップＳ２０１では、判定部１０３は、要求元状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１０８】
ステップＳ２０２では、判定部１０３は、ステップＳ２０１において取得した時刻以降における参照先状態の更新回数を、状態ＤＢ１０５から取得する。
【０１０９】
ステップＳ２０３では、判定部１０３は、読み込んだ判定条件が、参照先により要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断するとステップＳ２０４に移行する。“ＮＯ”と判断すると、ステップＳ２０５に移行する。
【０１１０】
ステップＳ２０４では、判定部１０３は、参照先により設定されている設定回数を閾値とする。
【０１１１】
ステップＳ２０５では、判定部１０３は、システム側で予め設定されている回数を、閾値とする。
【０１１２】
ステップＳ２０６では、判定部１０３は、前記ステップＳ２０２で取得した更新回数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ１０７に移行する。すなわち、要求元の状態の更新頻度が、参照先に比して低い場合である。“ＮＯ”と判断すると、後述するステップＳ２１０に移行する。
【０１１３】
ステップＳ２０７では、判定部１０３は、要求元のユーザ端末２に対し、状態の設定要求を送信する。要求元のユーザ端末２では、前記図７または図８に例示する画面が表示される。
【０１１４】
ステップＳ２０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前記ステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ２０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ２１０に移行する。
【０１１５】
ステップＳ２０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１１６】
ステップＳ２１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１１７】
（４）グループ時間サブルーチン
図１３は、グループ時間サブルーチンで行われる処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１１に移行すると、以下の処理が開始される。
【０１１８】
ステップＳ３０１では、判定部１０３は、要求元状態の最終更新時刻を状態ＤＢ１０５から取得する。
【０１１９】
ステップＳ３０２では、判定部１０３は、読み出した判定条件が、参照先グループにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ３０３に移行する。“ＮＯ”と判断すると、後述するステップＳ３０４に移行する。“ＮＯ”と判断されるのは、判定条件の時間及び人数のいずれもがデフォルト値の場合である。
【０１２０】
ステップＳ３０３では、判定部１０３は、参照先により設定されている時間や人数を閾値とする。いずれか一方が設定されている場合、設定されていないパラメータについてはシステム側で設定しているデフォルト値を閾値とする。
【０１２１】
ステップＳ３０４では、判定部１０３は、システム側で設定している時間及び人数を、閾値とする。
【０１２２】
ステップＳ３０５では、判定部１０３は、まず、要求元状態の最終更新時刻以降に状態が更新されたユーザが、参照先グループ内に何人いるかを求める。次いで、判定部１０３は、前記求めた人数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ３０６に移行する。“ＮＯ”と判断すると、後述するステップＳ３０９に移行する。
【０１２３】
ステップＳ３０６では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前述の図７または図８に示す画面が表示される。
【０１２４】
ステップＳ３０７では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前記ステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ３０８に移行する。“ＹＥＳ”と判断すると、後述するステップＳ３０９に移行する。
【０１２５】
ステップＳ３０８では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１２６】
ステップＳ３０９では、判定部１０３は、判定結果として「ＯＫ」を参照部１０９に返す。その後、前記メイン処理に戻る。
【０１２７】
（５）合計回数サブルーチン
図１４は、判定部１０３が行う合計回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１３に移行すると、以下の処理が開始される。
【０１２８】
ステップＳ４０１では、判定部１０３は、要求元状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１２９】
ステップＳ４０２では、判定部１０３は、前記ステップＳ４０１で取得した時刻以降において、参照先グループ内で構成ユーザが状態を更新した合計回数を、状態ＤＢ１０５から取得する。
【０１３０】
ステップＳ４０３では、判定部１０３は、読み込んだ判定条件が、参照先グループにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断するとステップＳ４０４に移行する。“ＮＯ”と判断すると、ステップＳ４０５に移行する。
【０１３１】
ステップＳ４０４では、判定部１０３は、参照先グループにより設定されている合計回数を、閾値とする。
【０１３２】
ステップＳ４０５では、判定部１０３は、システム側で設定されている合計回数を、閾値とする。
【０１３３】
ステップＳ４０６では、判定部１０３は、前記ステップＳ４０２で取得した合計回数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ４０７に移行する。“ＮＯ”と判断すると、後述するステップＳ４１０に移行する。
【０１３４】
ステップＳ４０７では、判定部１０３は、要求元のユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前記図７や８に示す画面が表示される。
【０１３５】
ステップＳ４０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前述のステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ４０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ４１０に移行する。
【０１３６】
ステップＳ４０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１３７】
ステップＳ４１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１３８】
（６）個別回数サブルーチン
図１５は、判定部１０３が行う個別回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１５に移行すると、以下の処理が開始される。
【０１３９】
ステップＳ５０１では、判定部１０３は、要求元ユーザ状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１４０】
ステップＳ５０２では、判定部１０３は、要求元ユーザ状態の最終更新時刻以降において、参照先グループ内で構成ユーザが状態を更新した回数を、構成ユーザ毎に求める。この処理は、状態ＤＢ１０５に基づいて行われる。
【０１４１】
ステップＳ５０３では、判定部１０３は、読み出した判定条件が、要求元ユーザにより参照先グループに対して設定されているものか否かを判断する。回数または人数のいずれかの条件が設定されていると“ＹＥＳ”と判断し、ステップＳ５０４に移行する。いずれの設定もされていない場合“ＮＯ”と判断し、ステップＳ５０５に移行する。
【０１４２】
ステップＳ５０４では、判定部１０３は、設定されている回数や人数を閾値とする。いずれかの設定がない場合には、システム側で設定しているデフォルト値を閾値とする。
【０１４３】
ステップＳ５０５では、システム側で設定されている回数及び人数のデフォルト値を、それぞれの閾値とする。
【０１４４】
ステップＳ５０６では、判定部１０３は、まず、前記ステップＳ５０２において求めた更新回数が閾値の回数を越えているユーザの人数を求める。次いで、判定部１０３は、前記求めた人数が閾値の人数を越えているか否かを判断する。“ＹＥＳ”と判断するとステップＳ５０７に移行する。“ＮＯ”と判断すると、後述するステップＳ５１１に移行する。
【０１４５】
ステップＳ５０７では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前述した図７や図８に示す画面が表示される。
【０１４６】
ステップＳ５０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前述のステップＳ１０７と同様に行う。“ＮＯ”と判断すると、ステップＳ５０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ５１０に移行する。
【０１４７】
ステップＳ５０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１４８】
ステップＳ５１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１４９】
（７）参照部１０９または通知部１１０が行う処理の流れ
図１６は、参照部１０９または通知部１１０が行う処理の流れを示すフローチャートである。ユーザ端末２側からの参照要求または状態ＤＢ１０５の更新により、以下の処理が開始される。
【０１５０】
ステップＳ６０１では、参照部１０９または通知部１１０は、参照先ユーザまたは参照先グループの構成ユーザの状態を取得する。
【０１５１】
ステップＳ６０２では、参照部１０９または通知部１１０は、判定部１０３に対し、判定を依頼する。参照部１０９または通知部１１０は、この判定依頼とともに、要求元及び参照先または監視者及び監視対象を、判定部１０３に通知する。
【０１５２】
ステップＳ６０３では、参照部１０９または通知部１１０は、判定部１０３からの判定結果を待ち、判定結果がＯＫであるか否かを判断する。ＯＫであれば、後述するステップＳ６０４に移行する。ＯＫでなければステップＳ６０５に移行する。
【０１５３】
ステップＳ６０４では、参照部１０９または通知部１１０は、要求元または監視者のユーザ端末２に対し、参照先または監視対象の状態を送信する。ユーザ端末２上では、図２０〜図２３に例示する画面が表示される。
【０１５４】
ステップＳ６０５では、参照部１０９または通知部１１０は、状態の表示を実行するか否かを判断する。この判断は、システム側の設定に基づいて行う。“ＹＥＳ”と判断するとステップＳ６０６に移行する。“ＮＯ”と判断すると、後述するステップＳ６０７に移行する。
ステップＳ６０６では、参照部１０９または通知部１１０は、判定結果がＮ Ｇであった参照先または監視対象の状態を、例えば「？」に置き換える。その後、参照部１０９または通知部１１０は、参照先または監視対象の状態を、要求元または監視者のユーザ端末２に送信する。ユーザ端末２上では、前記図５〜７に示す画面が表示され、参照先状態は「？」で表示される。
【０１５５】
ステップＳ６０７では、所定の他の処理が行われる。例えば、要求元または監視者のユーザ端末２に対し、メニュー画面を送信することが挙げられる。
【０１５６】
［具体的な判定例］
次に、前記処理の流れを、具体例を挙げて説明する。いま、条件テーブルが図１７に示すように設定されているとする。図１７の条件テーブルは、前述した条件ＤＢと状態ＤＢとを一体化した構成となっている。また、各ユーザ状態のみならず、各ユーザ状態の更新時間も蓄積されている。なお、図１７の条件テーブルには、個人ユーザの判定条件とそのユーザ状態とが共に登録されているが、グループの判定条件については、条件ＤＢに別個に登録する必要がある。
【０１５７】
ユーザＡがユーザＤについて、参照要求を出した場合を考える。ユーザＤは、判定条件として「時間≧２時間」を設定している。ユーザＡ（要求元）の状態の最終更新時間は、１９９９／７／２６、１０：２３である。ユーザＤ（参照先）の状態の最終更新時間は、１９９９／７／２６、１３：３０である。要求元状態の最終更新時間から参照先状態の最終更新時間までに３時間７分、すなわち２時間以上が経過している。従って、ユーザＡの参照要求は許可されない。この場合、例えば、ユーザＡの端末にサーバ１から自状態の設定要求が送信され、図７に例示する画面が表示される。
【０１５８】
また、図１７の条件テーブルにおいて、システム側の設定値は、「時間≧３日」、「回数≧３回」となっている。判定条件を設定していないユーザＢの状態をユーザＡが参照しようとすると、前記２つの条件の組み合わせにより判定が行われる。ユーザＢは、ユーザＡの状態更新時刻１９９９／７／２６、１０：２３以降に２回状態を更新している。しかし、いずれもユーザＡの状態更新時刻の３回以内である。従って、ユーザＡからユーザＢへの参照要求は許可され、図２０〜２３に例示する画面がユーザＡの端末上で表示される。
【０１５９】
＜第２実施形態例＞
［構成］
図１８は、第２実施形態例に係る状態管理システムである。本実施形態例においては、ユーザ端末２ａにも判定条件設定部１０２及び判定部１０３が設けられている。他のユーザ状態の参照要求や自端末への状態通知に対しては、ユーザ端末２ａの判定部１０３が前記の判定を行い、その判定結果に基づいて状態表示が行われる。参照先の判定条件は、サーバ１から取得可能である。判定条件設定部１０２や判定部１０３を設けるユーザ端末２ａとしては、ＰＣやＷＳなどが好ましい。
【０１６０】
移動通信端末２ｂからの参照要求や移動通信端末２ｂへの状態通知については、第１実施形態例と同様にサーバ１側に設けられた判定条件設定部１０２、判定部１０３及び条件ＤＢ１０１に基づいて行う。このようにすれば、前記の第１実施形態例に比して、サーバ１の負担を軽減することができる。
【０１６１】
【発明の効果】
本発明を用いれば、ネットワークに接続されたユーザが互いの状態を参照する状態管理システムにおいて、ユーザに過度の負担をかけることなく、ユーザ間の公平を保ちながらユーザ状態の設定を促進することが出来る。
【図面の簡単な説明】
【図１】第一実施形態例に係る状態管理システムの全体構成図。
【図２】条件テーブルの概念説明図。
【図３】ユーザ端末上に表示されるメニュー画面の一例。
【図４】ユーザ端末上に表示される状態設定画面の一例。
【図５】（ａ），（ｂ），（ｃ）相手状態が参照できない場合に表示される画面例（移動通信端末）。
【図６】（ａ），（ｂ），（ｃ）相手状態が参照できない場合に表示される画面例（ＰＣ）。
【図７】（ａ），（ｂ）状態の設定を促進する画面例（状態参照時）。
【図８】（ａ），（ｂ）状態の設定を促進する画面例（状態通知時）。
【図９】（ａ），（ｂ）判定条件の設定画面例。
【図１０】判定部が行うメイン処理の流れの一例を示すフローチャート。
【図１１】時間サブルーチンの流れを示すフローチャート。
【図１２】回数サブルーチンの流れを示すフローチャート。
【図１３】グループ時間サブルーチンの流れを示すフローチャート。
【図１４】合計回数サブルーチンの流れを示すフローチャート。
【図１５】個別回数サブルーチンの流れを示すフローチャート。
【図１６】参照部及び通知部が行う処理の流れを示すフローチャート。
【図１７】条件テーブルの具体例。
【図１８】第２実施形態例に係る状態管理システムの全体構成図。
【図１９】従来の状態管理システムの全体構成図。
【図２０】ユーザ状態の個別表示例（移動通信端末）。
【図２１】（ａ），（ｂ）ユーザ状態の個別表示例（ＰＣ）。
【図２２】（ａ）ユーザ状態のグループ別表示例（移動通信端末）。
（ｂ）グループ中のユーザ状態の詳細表示例（移動通信端末）。
【図２３】ユーザ状態のグループ別表示例（ＰＣ）。
【符号の説明】
１；サーバ
２ａ，ｂ；ユーザ端末
３；イントラネット／インターネット
４；移動体通信網
１０１；条件ＤＢ
１０３；判定部
【発明の属する技術の分野】
本発明は、移動体通信網やインターネットなどのネットワークに接続されたユーザの状態を管理する状態管理システムに関する。
【０００２】
【従来の技術】
ネットワーク上でユーザ状態を共有し互いに参照するための状態管理システムとして、ＩＣＱやヤフーページャなど様々なものが提供されている。図１９は、従来の状態管理システムの一例を示す構成図である。状態管理システムは、サーバ１９１とユーザ端末１９２とがネットワーク１９３により接続されて構成されている。ネットワーク１９３としては、インターネットやイントラネット、移動体通信網などが挙げられる。ユーザ端末１９２としては、ＰＣ(Personal Computer)、ＷＳ(Work Station)、携帯電話、ＰＨＳ(Personal Handy-Phone System)などがあげられる。ユーザの状態は、ユーザ自身により入力されたり自動的に検出され、サーバ１に蓄積され、他のユーザにより参照される。
【０００３】
ユーザ状態には、ネットワークへ「接続中」や「未接続」など自動的に検出され得る状態もあるが、「離席」や「忙しい」などユーザ自身で入力しなければならない状態もある。また、状態管理システムによっては、ユーザ端末１９２上のアプリケーションの状態に応じ、「離席」や「在席」などの状態が自動的に検出される。
【０００４】
図２０は、状態管理システム上の移動通信端末におけるユーザ状態の表示例を示す。図２０では、複数のユーザの一覧が表示され、各ユーザの状態を表す絵文字がユーザ名と共に表示されている。
【０００５】
図２１は、ＰＣにおけるユーザ状態の表示例を示す画面例である。図２１（ａ）では、複数のユーザの一覧が表示され、各ユーザの状態を表すアイコンがユーザ名とともに表示されている。図２１（ｂ）は、一人のユーザについての状態が詳細に表示されている。
【０００６】
さらに、ユーザ同士で予め形成したグループ単位でユーザ状態を表示する状態管理システムも提供されている。図２２（ａ）は、移動通信端末においてグループ単位でユーザ状態を表示する例を示す。図２２（ｂ）では、グループ中の一人のユーザについての状態が詳細に表示されている。図２３は、ＰＣにおいてユーザ状態をグループ単位で表示する例である。ウインドウの左側に、グループ構成ユーザの名前と、その状態を表すアイコンとが表示されている。
【０００７】
【発明が解決しようとする課題】
前述した従来の状態管理システムにおいては、各ユーザの状態はユーザ自身が入力するか自動的に検知されることにより設定される。しかし、ユーザ自身で設定しなければならない状態は、どうしても設定を忘れてしまうことが多い。例えば、席を離れる際に自状態を「離席」に設定しておいても、席に戻ったときに自状態を「在席」に設定し直すことを忘れてしまう。
【０００８】
また、ユーザ状態を自動的に検出する手法としては、スクリーンセーバの状態やキーボード、マウスからの入力状態などに基づいて、ユーザ状態を設定するものが主である。例えば、スクリーンセーバが動作していれば、そのユーザ端末を操作するユーザの状態を「不在」に設定する。また、キーボード入力やマウス操作が常時生じていれば、ユーザ状態を「在席」に設定する。
【０００９】
しかし、スクリーンセーバが動作中であってもユーザ端末の前にユーザがいる場合がある。また、入力操作が行われていても、操作しているのはユーザ自身ではなく他人である場合もある。従って、自動検出されるユーザ状態と実際のユーザ状態とは、異なることが少なくないのが現状である。従って、正しいユーザ状態の設定は、ユーザ自身による入力に頼らざるを得ない。
【００１０】
今後、ユーザ端末がネットワークに実質的にあるいは擬似的に常時接続している状況が想定される。このような状況下で使用される状態管理システムでは、ユーザ状態の設定を忘れずに行うことがシステムの目的上重要である。ユーザ状態の設定忘れを回避するために、一定時間毎に自状態の入力を促したり、他のユーザ状態を参照する毎に入力を促すことが考えられるが、逆に面倒な場合が多く、使いやすいシステムとは言い難い。一方で、自状態を設定していないユーザが他のユーザの状態を参照できるとすれば、ユーザ間に不公平が生じる。
【００１１】
本発明では、ユーザの入力負担を軽減しつつ、ユーザ間の不公平が生じないようにユーザ状態の設定を促進する状態管理システムを提供する。
【００１２】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理方法であって、
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積し、
Ｂ；前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定し、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する、
状態管理方法を提供する。
判定条件は、システム側で設定またはユーザにより設定される。他のユーザ状態の参照要求が生じた場合、参照先状態を要求元に通知するか否かを、両者の新しさの差が判定条件で定められた範囲内か否かに基づいて判断する。参照要求を許可する場合は、通常の状態通知を行う。許可しない場合、その旨を通知する文字メッセージや、参照先状態に「？」マークを埋め込んだ状態通知を行う。ユーザは、参照先状態を知りたければ、自状態を入力すればよいことが分かる。なお、参照先及び要求元は、単一のユーザであっても良いし、複数のユーザを含むユーザグループであっても良い。
【００１３】
本願第２発明は、前記第１発明において、前記判定を、要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況とを比較し、両者の差が判定条件に定められた所定の範囲内か否かにより行う状態管理方法を提供する。
【００１４】
例えば、要求元状態が参照先状態に比して古すぎる場合、参照要求を許可しない。両者の公平を保つためである。
【００１５】
本願第３発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理システムであって、蓄積手段と判定手段と通知手段とを備える状態管理システムを提供する。
【００１６】
蓄積手段は、要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積している。判定手段は、前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する。通知手段は、前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する。
【００１７】
前記第１発明と同様の作用効果を有する。
【００１８】
本願第４発明は、前記第３発明において、判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える状態管理システムを提供する。
【００１９】
判定条件をシステム側で予め準備しておいても良いが、各ユーザが設定できるようにしても良い。例えば、ユーザＡは、他のユーザからの参照要求に対して「条件１」を設定し、条件１を満たす他のユーザに対して自状態の参照を許可する。一方、設定を行っていないユーザへの参照要求は、システム側で予め準備した所定の判定条件に従い処理される。
【００２０】
本願第５発明は、前記第３発明において、前記蓄積手段は、参照先のユーザ端末と、要求元のユーザ端末と、参照先が要求元に対して設定している判定条件とを対応付けて蓄積し、要求元毎の判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える状態管理システムを提供する。
【００２１】
設定手段は、相手が指定された判定条件の設定をユーザから受け付ける。例えば、ユーザＡは、自状態を参照するための条件として、ユーザＢに対しては「条件１」を、ユーザＣに対しては「条件２」を設定する。すると、ユーザＢがユーザＡの状態を参照しようとする場合は「条件１」を、ユーザＣがユーザＡの状態を参照しようとする場合は「条件２」を、満足しなければならない。また、設定のない他ユーザに対しては、システム側で予め準備した所定の判定条件を適用することが考えられる。
【００２２】
本願第６発明は、前記第３発明において、ユーザのユーザ状態が変化した場合に新たなユーザ状態の通知を受けるユーザを監視者とし、監視者に自ユーザ状態が通知されるユーザを監視対象とし、両者を関連付けて蓄積している第２蓄積手段と、監視対象のユーザ状態が変化した場合、監視対象を参照先とした場合の判定条件に従い、監視対象のユーザ状態を監視者へ通知することを許可するか否かを判定し、判定結果を監視者のユーザ端末に通知する第２通知手段と、を備える状態管理システムを提供する。
【００２３】
例えば、第２蓄積手段には、監視対象のユーザＡと、ユーザＡの新たな状態を通知される監視者のユーザＢとが、対応付けられて蓄積されている。一方、ユーザＡが、ユーザＢに対し、判定条件として「条件１」を設定している。この場合、ユーザＡの状態が変化したとき、ユーザＢが「条件１」を満たしていなければ、ユーザＢに状態入力を促す通知がなされる。ユーザＢに状態の入力を促し、両者間の公平を保つためである。ユーザＢが「条件１」を満たしていれば、ユーザＡの状態がユーザＢに通知される。
【００２４】
本願第７発明は、前記第３発明において、前記判定の結果、参照要求が許可されない場合、要求元のユーザ端末に対し、要求元のユーザ状態の設定を要求する設定要求を送信する促進手段をさらに備える状態管理システムを提供する。
【００２５】
例えば、ユーザＢがユーザＡの状態を参照しようとしたが、判定条件を満たしていない場合を考える。促進手段は、例えばユーザＢの情報端末に対し、自状態の設定要求を送信する。ユーザＢが新たに自状態を設定すると、前記判定が変わり、参照が可能となるからである。
【００２６】
本願第８発明は、前記第３発明において、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間から参照先のユーザ状態の最終更新時間までの経過時間に基づいて行う状態管理システムを提供する。
【００２７】
例えば、経過時間が１日以上であれば、参照要求を許可しないと判定する。要求元ユーザ状態が、参照先ユーザ状態に比して古すぎるからである。
【００２８】
本願第９発明は、前記第３発明において、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降における、参照先のユーザ状態の更新回数に基づいて行う状態管理システムを提供する。
【００２９】
例えば、要求元状態が更新されて以降、参照先状態が３回以上更新されていれば、参照要求を許可しないと判定する。要求元は、参照先に比して、状態の更新を怠っていると考えられるからである。
【００３０】
本願第１０発明は、前記第３発明において、参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新された合計回数に基づいて行う状態管理システムを提供する。
【００３１】
例えば、要求元ユーザ状態が更新されて以降に、参照先ユーザグループ内で状態が５回以上更新されていれば、参照要求が許可されない。要求元ユーザは、参照先グループに比して、状態の更新を怠っていると考えられるからである。
【００３２】
本願第１１発明は、前記第３発明において、参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新されたユーザの合計人数に基づいて行う状態管理システムを提供する。
【００３３】
例えば、要求元状態が更新されて以降に、参照先ユーザグループ内において状態を更新したユーザが５人以上いれば、参照要求が許可されない。要求元は、参照先グループのユーザに比して、状態の更新を怠っていると考えられるからである。
【００３４】
本願第１２発明は、ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元ユーザ端末に参照先のユーザ状態を提供するサーバ端末に用いられ、下記Ａ〜Ｃ段階を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積する段階、
Ｂ；前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況及び参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する段階、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する段階。
【００３５】
前記第１発明と同様の作用効果を有する。記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）などが挙げられる。
【００３６】
本願第１３発明は、ネットワークに接続され、他のユーザのユーザ状態の参照要求をユーザから受け付け、参照先のユーザ状態を取得してユーザに通知可能なユーザ端末に用いられ、下記Ａ〜Ｃ段階を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元の前記ユーザに通知するか否かを判定するための判定条件を蓄積する段階、
Ｂ；前記他のユーザ状態の参照要求を行った要求元の前記ユーザのユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元の前記ユーザからの参照要求を許可するか否かを判定する段階、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元の前記ユーザに通知する段階。
【００３７】
前記第１発明と同様の作用効果を有する。記録媒体としては、前記第１２発明と同様のものを挙げることができる。
【００３８】
【発明の実施の形態】
次に、本発明に係る状態管理システムについて、図面を参照しながら具体的に説明する。
【００３９】
＜第１実施形態例＞
［構成］
図１は、第１実施形態例に係る状態管理システムの全体構成図である。図１に示す状態管理システムは、サーバ１とユーザ端末２とがインターネットまたはイントラネット３を介して接続されて構成されている。ユーザ端末２としては、ＰＣ、ＷＳ、移動通信端末などが挙げられる。携帯電話やＰＨＳなどの移動通信端末は、移動体通信網４を介してインターネットなど３に接続されている。
【００４０】
（１）ユーザ端末
ユーザ端末２は、前述した従来の状態管理システムにおけるユーザ端末２と同様の構成を有している。すなわち、ユーザ端末２は、第１通信部２１、自状態設定部２２、自状態通知部２３、状態参照部２４及び状態表示部２５を有している。
【００４１】
第１通信部２１は、ユーザ端末２とサーバ１との間でデータを送受信する。
【００４２】
自状態設定部２２は、ユーザからの自状態の入力を受け付けたり、ユーザ端末２上のアプリケーションの状態からユーザ状態を自動的に検知する。また、自状態設定部２２は、状態変化を監視したいユーザの指定をユーザから受け付ける。
【００４３】
自状態通知部２３は、入力または検知された自状態や、設定された判定条件をサーバ１に通知する。
【００４４】
状態参照部２４は、グループまたは個人の指定をユーザから受け付け、サーバ１に通知し、指定先の状態をサーバ１から取得する。また、状態参照部２４は、監視対象に指定したユーザの新たな状態をサーバ１から取得する。
【００４５】
状態表示部２５は、サーバ１から取得したユーザ状態を表示する。
【００４６】
以上の機能に加え、本システムにおけるユーザ端末は、以下の新たな機能を有している。自状態設定部２２は、後述する判定条件の設定をユーザから受け付け、自状態通知部２３を介してサーバ１に送信する。また、自状態設定部２２は、判定条件の入力を容易にするために、ウインドウを表示する。
【００４７】
（２）サーバ
（２−１）従来のサーバ機能
サーバ１は、従来の状態管理システムにおけるサーバ１の機能に加え、さらに条件ＤＢ１０１、判定条件設定部１０２、判定部１０３を有している。従来のサーバ機能とは、第２通信部１０４、状態ＤＢ１０５、グループＤＢ１０６、通知ＤＢ１０７、設定部１０８、参照部１０９、通知部１１０及びグループ管理部１１１に相当する。
【００４８】
第２通信部１０４は、ユーザ端末２とサーバ１との間でデータの送受信を行う。
【００４９】
状態ＤＢ１０５には、各ユーザの状態が蓄積されている。
【００５０】
グループＤＢ１０６には、何らかの方法により形成されたグループの構成ユーザが、グループ名とともに蓄積されている。
【００５１】
通知ＤＢ１０７には、監視対象と監視者とが、対応付けられて蓄積されている。ここで、監視対象及び監視者とは、次のような関係にある。監視対象のユーザ状態が変化すると、その新たな状態が監視者に通知される。
【００５２】
設定部１０８は、ユーザ端末２から受信した各ユーザの状態を、状態ＤＢ１０５に記憶する。また、設定部１０８は、ユーザ端末２から監視対象の指定を受け付け、前記ユーザ端末２を操作するユーザを監視者とし、監視対象と関連付けて通知ＤＢ１０７に蓄積する。
【００５３】
参照部１０９は、ユーザ端末２からの状態参照要求を受信し、参照先の状態を状態ＤＢ１０５から取得してユーザ端末２に渡す。
【００５４】
グループ管理部１１１は、ユーザにより形成されたグループの構成ユーザ及びグループ名をユーザ端末２から受け取り、グループＤＢ１０６に格納する。また、グループ管理部１１１は、ユーザ端末２からグループを指定する状態参照要求を受信した場合、指定グループの構成ユーザを参照部１０９に渡す。
【００５５】
通知部１１０は、新たなユーザ状態が状態ＤＢ１０５に蓄積された場合、状態が変化したユーザを監視対象に指定している監視者に、新たなユーザ状態を通知する。以下、この通知を状態通知という。通知された監視対象の状態は、状態参照部２４により取得され、状態表示部２５により監視者へ通知される。この状態通知に先立ち、監視者の状態に基づいて状態通知が可能か否かを判断し、判断に従って状態通知を行うことも可能である。
【００５６】
（２−２）本システムにおけるサーバ機能
本システムにおいては、条件ＤＢ１０１、判定条件設定部１０２及び判定部１０３が新たにサーバ１に設けられている。条件ＤＢ１０１には、条件テーブルが蓄積されている。条件テーブルについては、詳細を後述する。
【００５７】
判定条件設定部１０２は、ユーザ端末２から所定の判定条件を受信し、条件ＤＢ１０１に格納する。この判定条件は、ユーザ端末２から参照要求があった場合、参照先の状態を要求元に通知しても良いか否かを判定するために用いられる。また、監視者に対し、状態通知を行っても良いか否かを判定するためにも用いられる。判定条件については、詳細を後述する。
【００５８】
判定条件は、システム側で予め設定しておいても良いが、本実施形態例においては個人またはグループがそれぞれ判定条件を設定可能である。また、ユーザは、必要に応じ、他の個人やグループに対して個別の判定条件を設定可能である。
【００５９】
判定部１０３は、ユーザ端末２からの参照要求があった場合、参照要求に基づいて参照先の状態を要求元ユーザ端末２に送信するか否かの判定を行う。また、判定部１０３は、状態ＤＢ１０５に新たな状態が設定された場合、新たな状態の状態通知を行うか否かの判定を行う。さらに、判定部１０３は、判定結果がＮＧの場合、その旨のメッセージをユーザ端末２に通知し、状態設定を要求する。本実施形態例においては、システム側でデフォルトの判定条件が予め設定されており、ユーザが判定条件を設定していない場合にはデフォルトの判定条件が用いられる。
他の構成要素の機能は、前記従来の状態管理システムと同様である。但し、参照部１０９は、参照要求をユーザ端末２から受け取ると、判定部１０３の判定結果に従って参照先の状態の送信を行う。判定により参照要求が許可されない場合、参照部１０９は、参照先状態に例えば特定のマーク「？」を埋め込み、ユーザ端末２に送信する。要求された参照先状態は、参照が許可されなかったことをユーザに示すためである。また、通知部１１０も、参照部１０９と同様に、判定部１０３の判定結果に従って状態通知を行う。
【００６０】
（２−３）判定条件
本実施形態例においては、以下の４つの判定条件及びこれらの組み合わせにより、参照先または監視対象の状態を要求元または監視者に通知しても良いか否かの判定を行う。
【００６１】
［１］時間
［２］回数
［３］合計回数
［４］人数
条件［１］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻から参照先ユーザ状態の最終更新時刻までの経過時間が所定時間以上であれば、通知をしないと判定する。要求元ユーザ状態が、参照先状態に比して古すぎると考えられるからである。
【００６２】
例えば判定時間が１日であり、ユーザＡがユーザＢの状態を参照する場合を考える。ユーザＢの状態が、ユーザＡの状態の最終更新時刻から１日以内に更新されていれば、ユーザＡはユーザＢの状態を参照することがきる。この場合、判定は「ＯＫ」となる。そうでなければ判定は「ＮＧ」となる。この場合、ユーザＡは、新たな自状態を設定しなければ、ユーザＢの状態を参照出来ない。ユーザＢの状態はユーザＡの状態に比して新しいので、両者間の公平を図るためである。
【００６３】
条件［２］の例としては以下のようなものがある。要求元ユーザ状態の最終更新時刻以降において参照先ユーザ状態の更新回数が所定回数以上であれば、通知をしないと判定する。例えば、回数が３回であり、ユーザＡがユーザＢの状態を参照する場合を考える。ユーザＡの状態の最終更新時刻以降に、ユーザＢの状態が更新された回数が２回以下であれば、判定はＯＫとなる。この場合、ユーザＡはユーザＢの状態を参照することができる。
【００６４】
しかし、ユーザＡの状態の最終更新時刻以降にユーザＢの状態が３回以上更新されていれば、ユーザＡのユーザＢに対する参照要求の判定は「ＮＧ」となる。この場合、ユーザＡは、新たな自状態を設定しなければ、ユーザＢの状態を参照出来ない。ユーザＢの状態を参照しようとしているユーザＡの状態はユーザＢの状態に比して古すぎると考えられるので、両者間の公平を図るためである。
【００６５】
条件［３］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻以降に、参照先グループ内において構成ユーザが状態を更新した合計回数が所定回数以上であれば、通知をしないと判定する。なお、条件［３］は、何らかの方法で形成されるユーザグループが設定可能な判定条件である。
【００６６】
例えば、合計回数が「３回以上」と設定されており、ユーザＡがグループＣの状態を参照する場合を考える。要求元ユーザＡの状態の最終更新時刻以降に、グループＣ内で構成ユーザが状態を更新した合計回数が３回以上であれば、判定は「ＮＧ」となる。グループＣの状態に比して、ユーザＡの状態は古すぎると考えられるからである。
【００６７】
条件［４］の例としては、以下のようなものがある。要求元ユーザ状態の最終更新時刻以降に、参照先グループ内のユーザのうち状態を更新したユーザの合計人数が所定人数以上であれば、通知をしないと判定する。この条件は、前記条件［３］と同様に、グループが設定可能な条件である。
【００６８】
例えば、合計人数が「３人」と設定されており、ユーザＡがグループＤの状態を参照する場合を考える。ユーザＡの状態の最終更新時刻以降に、グループＤ内で状態を更新したユーザが３人以上であれば、判定は「ＮＧ」となる。ユーザＡの状態は、グループＤの状態に比して古すぎると考えられるからである。
【００６９】
（２−４）条件テーブル
図２は、条件ＤＢ１０１に蓄積されている条件テーブルの概念説明図である。条件テーブルには、参照先、要求元及び判定条件が、対応付けられて記憶されている。例えば、図２においてグループＸはグループＹに対し、判定条件として「時間≧１２時間」を設定している。この判定条件は、グループＹ（要求元）の構成ユーザがグループＸ（参照先）の状態を参照しようとした場合に適用される。また、この判定条件は、グループＸ内のユーザについて、グループＹ内のユーザに状態通知をする場合にも適用される。
【００７０】
また、図２においてユーザＣはユーザＢに対し、判定条件として「回数≧３回」を設定している。この判定条件は、ユーザＣ（要求元）がユーザＢ（参照先）の状態を参照しようとした場合と、ユーザＢの状態をユーザＣに状態通知する場合とに適用される。
【００７１】
（３）画面例
次に、画面例に基づいて本発明の作用を説明する。
【００７２】
図３は、状態管理システムにおけるメニュー画面の一例である。メニュー画面では、選択可能な処理や、ユーザが既に作成したグループなどが表示される。例えばメニュー画面において、「私のいま！」を選択すると、ユーザの自状態を設定するための状態設定画面が表示される。また、「コミュニティ作成」を選択すると、グループを作成することが出来る。
【００７３】
図４（ａ）〜（ｃ）は、ユーザが自状態を設定するための状態設定画面の一例である。図４（ａ）及び（ｂ）は、設定対象を「気持ち」や「天気」などいくつかの分類から選択したり、自状態を表す文字を入力するための画面である。図４（ｃ）は、自状態を表す絵文字を選択入力するための画面である。また図４（ａ），（ｂ）において、画面の下部分には、自状態を文字により表現するためのフィールドが設けられている。
【００７４】
図５（ａ）〜（ｃ）及び図６（ａ）〜（ｃ）は、ユーザが個人またはグループの状態を参照しようとしたが、判定結果により相手状態を参照できない場合に表示される画面例である。図５の画面例は、移動通信端末で表示される画面例である。図６の画面例は、ＰＣ上で表示される画面例である。
図５（ａ）及び図６（ａ）は、１人のユーザの状態を参照しようとしたが、参照できない場合の画面例を示す。図５（ｂ）及び図６（ｂ）では、複数のユーザ一覧とともに各ユーザの状態が表示される場合に、何人かのユーザの状態が参照できないことを示す画面例である。これらのユーザについては、状態に「？」など特定のマークが表示されている。図５（ｃ）及び図６（ｃ）は、あるグループの状態を参照しようとしたが参照できない場合の画面例を示している。
【００７５】
図７（ａ）及び（ｂ）は、前記図５及び図６の画面を表示するに先立ち、自状態の設定を促す場合に表示される画面例である。図７（ａ）は、個人の状態を参照しようとしたが参照できない場合に表示される画面例である。図７（ｂ）は、グループの状態を参照しようとしたが参照できない場合に表示される画面例である。いずれの画面例においても、「自状態設定ボタン」を押すと、前記図４に例示する状態設定画面が表示される。逆に、「ＯＫボタン」を押すと、前記図５または図６に例示する画面が表示される。
【００７６】
図８（ａ）及び（ｂ）は、状態通知に先立ち、監視者が監視対象の状態を参照できない場合に表示される画面例である。図８（ａ）は、監視対象が個人の場合に表示される画面例である。図８（ｂ）は、監視対象がグループの場合に表示される画面例である。「自状態設定」ボタン及び「ＯＫ」ボタンが押された場合の作用は、図７と同様である。
【００７７】
図９（ａ）及び（ｂ）は、判定条件を設定するための画面例である。図９（ａ）は、個人の判定条件を設定するための画面例である。図９（ｂ）は、グループの判定条件を設定するための画面例である。画面例において複数の条件を入力すれば、その組み合わせにより判定がなされる。例えば、図９（ｂ）では、時間及び人数が設定されている。「設定」ボタンを押すと、設定された判定条件がサーバ１に送信され、条件ＤＢ１０１に格納される。
【００７８】
［処理の流れ］
次に、判定部１０３が行う処理の流れについて、フローチャートを用いて具体的に説明する。図１０は、判定部１０３が行うメイン処理の流れを示すフローチャートである。なお、説明を容易にするため、個人からの参照要求及び個人への状態通知については、時間または回数のいずれかに基づいて判定する場合を例に取る。また、グループからの参照要求及びグループへの状態通知については、時間、合計回数または回数のいずれかに基づいて判定する場合を例に取る。
【００７９】
参照要求の受信または状態ＤＢ１０５の更新により、以下の処理が開始される。
【００８０】
ステップＳ１では、判定部１０３は、要求元が参照先に設定している判定条件を条件ＤＢ１０１から読み出す。状態ＤＢ１０５が更新された場合、判定部１０３は、状態が更新されたユーザまたはグループを監視対象に指定している監視者を、通知ＤＢ１０７から読み出す。次いで、判定部１０３は、監視対象が監視者に対して設定している判定条件を、条件ＤＢ１０１から読み出す。
【００８１】
以下において、状態参照要求が生じた場合における処理を説明するが、状態通知についても、参照先を監視対象、要求元を監視者、参照部１０９を通知部１１０に読み替えれば同様である。
【００８２】
ステップＳ２では、判定部１０３は、参照先がグループであるか否かを判断する。“ＹＥＳ”と判断すると、後述するステップＳ１０に移行する。“ＮＯ”と判断すると、ステップＳ３に移行する。
【００８３】
ステップＳ３では、判定部１０３は、判定条件が時間であるか否かを判断する。参照先が要求元に対する判定条件として時間を設定しているか、システムがデフォルトの判定条件として時間を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ４に移行する。“ＮＯ”と判断すると、後述するステップＳ８に移行する。
【００８４】
ステップＳ４では、判定部１０３は、後述する時間サブルーチンを実行する。すなわち、判定部１０３は、設定された時間に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００８５】
ステップＳ５では、判定部１０３は、判定結果がＯＫであるか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ６に移行する。“ＮＯ”と判断すると、後述するステップＳ７に移行する。
【００８６】
ステップＳ６では、判定結果に基づいて、参照部１０９が、参照先の状態を要求元のユーザ端末２に送信する。ユーザ端末２上では、送信された状態が表示される。その後処理を終了する。
ステップＳ７では、参照部１０９は、判定結果に従ってＮＧ処理を行う。例えば、前記図５や図６に示すように、参照先状態に「？」を埋め込み、ユーザ端末２に送信する。ユーザ端末２上では図５や図６に例示する画面が表示される。ユーザは、参照先状態を知りたいか否かの必要に応じ、自状態を入力すればよい。その後処理を終了する。
【００８７】
前記ステップＳ３において、判定条件が時間ではないと判断されると、ステップＳ８に移行する。ステップＳ８においては、判定部１０３は、判定条件が回数であるか否かを判断する。参照先が要求元に対する判定条件として回数を設定しているか、システムがデフォルトの判定条件として回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断するとステップＳ９に移行する。“ＮＯ”と判断すると、何も条件が設定されていないので前記ステップＳ６に移行し、参照先の状態が要求元に送信される。すなわち、判定条件が設定されていない場合には、無条件に参照が許可される。
【００８８】
ステップＳ９では、判定部１０３は、後述する回数サブルーチンを実行する。すなわち、判定部１０３は、設定された回数に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００８９】
前記ステップＳ２において、参照先がグループであると判断されると、ステップＳ１０に移行する。ステップＳ１０では、判定部１０３は、判定条件が時間であるか否かを判断する。参照先グループが要求元に対する判定条件として時間を設定しているか、システムがデフォルトの判定条件として時間を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ１１に移行する。“ＮＯ”と判断すると、後述するステップＳ１２に移行する。
【００９０】
ステップＳ１１では、判定部１０３は、後述するグループ時間サブルーチンを実行する。すなわち、判定部１０３は、設定された時間に基づいて、参照先グループの状態を、要求元に通知するか否かを判定する。
【００９１】
ステップＳ１２では、判定部１０３は、判定条件が合計回数であるか否かを判断する。参照先グループが要求元に対する判定条件として合計回数を設定しているか、システムがデフォルトの判定条件として合計回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断するとステップＳ１３に移行する。“ＮＯ”と判断すると、後述するステップＳ１４に移行する。
【００９２】
ステップＳ１３では、判定部１０３は、後述する合計回数サブルーチンを実行する。すなわち、判定部１０３は、設定された合計回数に基づいて、参照先の状態を要求元に通知するか否かを判定する。
【００９３】
ステップＳ１４では、判定部１０３は、判定条件が回数であるか否かを判断する。参照先グループが要求元に対する判定条件として回数を設定しているか、システムがデフォルトの判定条件として回数を設定している場合、“ＹＥＳ”と判断される。“ＹＥＳ”と判断すると、ステップＳ１５に移行する。“ＮＯ”と判断すると判定条件の設定がないものと見なされ、前述のステップＳ６に移行する。すなわち、参照部１０９により参照先の状態が要求元に送信される。
【００９４】
ステップＳ１５では、判定部１０３は、後述する個別回数サブルーチンを実行する。すなわち、判定部１０３は、設定された回数に基づいて、参照先グループの状態を要求元に通知するか否かを判定する。
【００９５】
この処理に従えば、ユーザは、メッセージや特定のマークの表示により要求した参照先状態を参照できないことを通知される。しかし、その都度自状態を入力する必要はなく、参照先状態を知りたいか否かに応じて自状態を入力すればよい。従って、本実施形態例に係る状態管理システムは、ユーザに過度の負担を強いることなくユーザ状態の入力を促進してシステムの有効性を高め、しかもユーザ間の公平を保つことができる。図１０ではそれぞれの条件を単独で判定しているが、これを組み合わせ、「or」や「and」条件で最終的に「ＯＫ」か「NG」かを判定しても良い。
【００９６】
（２）時間サブルーチン
図１１は、時間サブルーチンの流れを示すフローチャートである。前記メイン処理においてステップＳ４に移行すると、以下の処理が開始される。
【００９７】
ステップＳ１０１では、判定部１０３は、要求元の状態が更新された最終時間を状態ＤＢ１０５から取得する。
【００９８】
ステップＳ１０２では、判定部１０３は、読み込んだ判定条件が、参照先ユーザにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ１０３に移行する。“ＮＯ”と判断すると、後述するステップＳ１０４に移行する。
【００９９】
ステップＳ１０３では、判定部１０３は、参照先ユーザが条件ＤＢ１０１に設定している設定時間を、閾値とする。
【０１００】
ステップＳ１０４では、判定部１０３は、システム側で設定しているデフォルト値の時間を閾値とする。
【０１０１】
ステップＳ１０５では、判定部１０３は、要求元状態の最終更新時間から参照先状態の最終更新時間までの経過時間が、閾値以上であるか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ１０６に移行する。これは、要求元状態が、参照先状態に比してあまりに古いことを意味する。“ＮＯ”と判断すると、後述するステップＳ１０９に移行する。
【０１０２】
ステップＳ１０６では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２では、自状態設定部２２が、前記図７または図８に示す画面を表示する。
【０１０３】
ステップＳ１０７では、判定部１０３は、要求元の状態が設定されたか否かを判断する。この判断は、例えば次のように行う。すなわち、所定時間内に応答がないかまたは前記図７または図８において「ＯＫ」ボタンをされた場合、“ＮＯ”と判断し、その他の場合には“ＹＥＳ”と判断する。“ＮＯ”と判断するとステップＳ１０８に移行する。“ＹＥＳ”と判断すると、ステップＳ１０９に移行する。なお、ステップＳ１０６〜１０７を省略することも可能である。
【０１０４】
ステップＳ１０８では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１０５】
ステップＳ１０９では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１０６】
（３）回数サブルーチン
図１２は、回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理において、ステップＳ９に移行すると以下の処理が開始される。
【０１０７】
ステップＳ２０１では、判定部１０３は、要求元状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１０８】
ステップＳ２０２では、判定部１０３は、ステップＳ２０１において取得した時刻以降における参照先状態の更新回数を、状態ＤＢ１０５から取得する。
【０１０９】
ステップＳ２０３では、判定部１０３は、読み込んだ判定条件が、参照先により要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断するとステップＳ２０４に移行する。“ＮＯ”と判断すると、ステップＳ２０５に移行する。
【０１１０】
ステップＳ２０４では、判定部１０３は、参照先により設定されている設定回数を閾値とする。
【０１１１】
ステップＳ２０５では、判定部１０３は、システム側で予め設定されている回数を、閾値とする。
【０１１２】
ステップＳ２０６では、判定部１０３は、前記ステップＳ２０２で取得した更新回数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ１０７に移行する。すなわち、要求元の状態の更新頻度が、参照先に比して低い場合である。“ＮＯ”と判断すると、後述するステップＳ２１０に移行する。
【０１１３】
ステップＳ２０７では、判定部１０３は、要求元のユーザ端末２に対し、状態の設定要求を送信する。要求元のユーザ端末２では、前記図７または図８に例示する画面が表示される。
【０１１４】
ステップＳ２０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前記ステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ２０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ２１０に移行する。
【０１１５】
ステップＳ２０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１１６】
ステップＳ２１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１１７】
（４）グループ時間サブルーチン
図１３は、グループ時間サブルーチンで行われる処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１１に移行すると、以下の処理が開始される。
【０１１８】
ステップＳ３０１では、判定部１０３は、要求元状態の最終更新時刻を状態ＤＢ１０５から取得する。
【０１１９】
ステップＳ３０２では、判定部１０３は、読み出した判定条件が、参照先グループにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断すると、ステップＳ３０３に移行する。“ＮＯ”と判断すると、後述するステップＳ３０４に移行する。“ＮＯ”と判断されるのは、判定条件の時間及び人数のいずれもがデフォルト値の場合である。
【０１２０】
ステップＳ３０３では、判定部１０３は、参照先により設定されている時間や人数を閾値とする。いずれか一方が設定されている場合、設定されていないパラメータについてはシステム側で設定しているデフォルト値を閾値とする。
【０１２１】
ステップＳ３０４では、判定部１０３は、システム側で設定している時間及び人数を、閾値とする。
【０１２２】
ステップＳ３０５では、判定部１０３は、まず、要求元状態の最終更新時刻以降に状態が更新されたユーザが、参照先グループ内に何人いるかを求める。次いで、判定部１０３は、前記求めた人数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ３０６に移行する。“ＮＯ”と判断すると、後述するステップＳ３０９に移行する。
【０１２３】
ステップＳ３０６では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前述の図７または図８に示す画面が表示される。
【０１２４】
ステップＳ３０７では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前記ステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ３０８に移行する。“ＹＥＳ”と判断すると、後述するステップＳ３０９に移行する。
【０１２５】
ステップＳ３０８では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１２６】
ステップＳ３０９では、判定部１０３は、判定結果として「ＯＫ」を参照部１０９に返す。その後、前記メイン処理に戻る。
【０１２７】
（５）合計回数サブルーチン
図１４は、判定部１０３が行う合計回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１３に移行すると、以下の処理が開始される。
【０１２８】
ステップＳ４０１では、判定部１０３は、要求元状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１２９】
ステップＳ４０２では、判定部１０３は、前記ステップＳ４０１で取得した時刻以降において、参照先グループ内で構成ユーザが状態を更新した合計回数を、状態ＤＢ１０５から取得する。
【０１３０】
ステップＳ４０３では、判定部１０３は、読み込んだ判定条件が、参照先グループにより要求元に対して設定されたものか否かを判断する。“ＹＥＳ”と判断するとステップＳ４０４に移行する。“ＮＯ”と判断すると、ステップＳ４０５に移行する。
【０１３１】
ステップＳ４０４では、判定部１０３は、参照先グループにより設定されている合計回数を、閾値とする。
【０１３２】
ステップＳ４０５では、判定部１０３は、システム側で設定されている合計回数を、閾値とする。
【０１３３】
ステップＳ４０６では、判定部１０３は、前記ステップＳ４０２で取得した合計回数が閾値以上であるか否かを判断する。“ＹＥＳ”と判断するとステップＳ４０７に移行する。“ＮＯ”と判断すると、後述するステップＳ４１０に移行する。
【０１３４】
ステップＳ４０７では、判定部１０３は、要求元のユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前記図７や８に示す画面が表示される。
【０１３５】
ステップＳ４０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前述のステップＳ１０７と同様に行う。“ＮＯ”と判断するとステップＳ４０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ４１０に移行する。
【０１３６】
ステップＳ４０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１３７】
ステップＳ４１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１３８】
（６）個別回数サブルーチン
図１５は、判定部１０３が行う個別回数サブルーチンの処理の流れを示すフローチャートである。前記メイン処理においてステップＳ１５に移行すると、以下の処理が開始される。
【０１３９】
ステップＳ５０１では、判定部１０３は、要求元ユーザ状態の最終更新時刻を、状態ＤＢ１０５から取得する。
【０１４０】
ステップＳ５０２では、判定部１０３は、要求元ユーザ状態の最終更新時刻以降において、参照先グループ内で構成ユーザが状態を更新した回数を、構成ユーザ毎に求める。この処理は、状態ＤＢ１０５に基づいて行われる。
【０１４１】
ステップＳ５０３では、判定部１０３は、読み出した判定条件が、要求元ユーザにより参照先グループに対して設定されているものか否かを判断する。回数または人数のいずれかの条件が設定されていると“ＹＥＳ”と判断し、ステップＳ５０４に移行する。いずれの設定もされていない場合“ＮＯ”と判断し、ステップＳ５０５に移行する。
【０１４２】
ステップＳ５０４では、判定部１０３は、設定されている回数や人数を閾値とする。いずれかの設定がない場合には、システム側で設定しているデフォルト値を閾値とする。
【０１４３】
ステップＳ５０５では、システム側で設定されている回数及び人数のデフォルト値を、それぞれの閾値とする。
【０１４４】
ステップＳ５０６では、判定部１０３は、まず、前記ステップＳ５０２において求めた更新回数が閾値の回数を越えているユーザの人数を求める。次いで、判定部１０３は、前記求めた人数が閾値の人数を越えているか否かを判断する。“ＹＥＳ”と判断するとステップＳ５０７に移行する。“ＮＯ”と判断すると、後述するステップＳ５１１に移行する。
【０１４５】
ステップＳ５０７では、判定部１０３は、要求元ユーザ端末２に対し、状態の設定要求を送信する。ユーザ端末２側では、前述した図７や図８に示す画面が表示される。
【０１４６】
ステップＳ５０８では、判定部１０３は、状態が設定されたか否かを判断する。この判断は、前述のステップＳ１０７と同様に行う。“ＮＯ”と判断すると、ステップＳ５０９に移行する。“ＹＥＳ”と判断すると、後述するステップＳ５１０に移行する。
【０１４７】
ステップＳ５０９では、判定部１０３は、判定結果として「ＮＧ」を、参照部１０９に返す。
【０１４８】
ステップＳ５１０では、判定部１０３は、判定結果として「ＯＫ」を、参照部１０９に返す。その後、前記メイン処理に戻る。
【０１４９】
（７）参照部１０９または通知部１１０が行う処理の流れ
図１６は、参照部１０９または通知部１１０が行う処理の流れを示すフローチャートである。ユーザ端末２側からの参照要求または状態ＤＢ１０５の更新により、以下の処理が開始される。
【０１５０】
ステップＳ６０１では、参照部１０９または通知部１１０は、参照先ユーザまたは参照先グループの構成ユーザの状態を取得する。
【０１５１】
ステップＳ６０２では、参照部１０９または通知部１１０は、判定部１０３に対し、判定を依頼する。参照部１０９または通知部１１０は、この判定依頼とともに、要求元及び参照先または監視者及び監視対象を、判定部１０３に通知する。
【０１５２】
ステップＳ６０３では、参照部１０９または通知部１１０は、判定部１０３からの判定結果を待ち、判定結果がＯＫであるか否かを判断する。ＯＫであれば、後述するステップＳ６０４に移行する。ＯＫでなければステップＳ６０５に移行する。
【０１５３】
ステップＳ６０４では、参照部１０９または通知部１１０は、要求元または監視者のユーザ端末２に対し、参照先または監視対象の状態を送信する。ユーザ端末２上では、図２０〜図２３に例示する画面が表示される。
【０１５４】
ステップＳ６０５では、参照部１０９または通知部１１０は、状態の表示を実行するか否かを判断する。この判断は、システム側の設定に基づいて行う。“ＹＥＳ”と判断するとステップＳ６０６に移行する。“ＮＯ”と判断すると、後述するステップＳ６０７に移行する。
ステップＳ６０６では、参照部１０９または通知部１１０は、判定結果がＮ Ｇであった参照先または監視対象の状態を、例えば「？」に置き換える。その後、参照部１０９または通知部１１０は、参照先または監視対象の状態を、要求元または監視者のユーザ端末２に送信する。ユーザ端末２上では、前記図５〜７に示す画面が表示され、参照先状態は「？」で表示される。
【０１５５】
ステップＳ６０７では、所定の他の処理が行われる。例えば、要求元または監視者のユーザ端末２に対し、メニュー画面を送信することが挙げられる。
【０１５６】
［具体的な判定例］
次に、前記処理の流れを、具体例を挙げて説明する。いま、条件テーブルが図１７に示すように設定されているとする。図１７の条件テーブルは、前述した条件ＤＢと状態ＤＢとを一体化した構成となっている。また、各ユーザ状態のみならず、各ユーザ状態の更新時間も蓄積されている。なお、図１７の条件テーブルには、個人ユーザの判定条件とそのユーザ状態とが共に登録されているが、グループの判定条件については、条件ＤＢに別個に登録する必要がある。
【０１５７】
ユーザＡがユーザＤについて、参照要求を出した場合を考える。ユーザＤは、判定条件として「時間≧２時間」を設定している。ユーザＡ（要求元）の状態の最終更新時間は、１９９９／７／２６、１０：２３である。ユーザＤ（参照先）の状態の最終更新時間は、１９９９／７／２６、１３：３０である。要求元状態の最終更新時間から参照先状態の最終更新時間までに３時間７分、すなわち２時間以上が経過している。従って、ユーザＡの参照要求は許可されない。この場合、例えば、ユーザＡの端末にサーバ１から自状態の設定要求が送信され、図７に例示する画面が表示される。
【０１５８】
また、図１７の条件テーブルにおいて、システム側の設定値は、「時間≧３日」、「回数≧３回」となっている。判定条件を設定していないユーザＢの状態をユーザＡが参照しようとすると、前記２つの条件の組み合わせにより判定が行われる。ユーザＢは、ユーザＡの状態更新時刻１９９９／７／２６、１０：２３以降に２回状態を更新している。しかし、いずれもユーザＡの状態更新時刻の３回以内である。従って、ユーザＡからユーザＢへの参照要求は許可され、図２０〜２３に例示する画面がユーザＡの端末上で表示される。
【０１５９】
＜第２実施形態例＞
［構成］
図１８は、第２実施形態例に係る状態管理システムである。本実施形態例においては、ユーザ端末２ａにも判定条件設定部１０２及び判定部１０３が設けられている。他のユーザ状態の参照要求や自端末への状態通知に対しては、ユーザ端末２ａの判定部１０３が前記の判定を行い、その判定結果に基づいて状態表示が行われる。参照先の判定条件は、サーバ１から取得可能である。判定条件設定部１０２や判定部１０３を設けるユーザ端末２ａとしては、ＰＣやＷＳなどが好ましい。
【０１６０】
移動通信端末２ｂからの参照要求や移動通信端末２ｂへの状態通知については、第１実施形態例と同様にサーバ１側に設けられた判定条件設定部１０２、判定部１０３及び条件ＤＢ１０１に基づいて行う。このようにすれば、前記の第１実施形態例に比して、サーバ１の負担を軽減することができる。
【０１６１】
【発明の効果】
本発明を用いれば、ネットワークに接続されたユーザが互いの状態を参照する状態管理システムにおいて、ユーザに過度の負担をかけることなく、ユーザ間の公平を保ちながらユーザ状態の設定を促進することが出来る。
【図面の簡単な説明】
【図１】第一実施形態例に係る状態管理システムの全体構成図。
【図２】条件テーブルの概念説明図。
【図３】ユーザ端末上に表示されるメニュー画面の一例。
【図４】ユーザ端末上に表示される状態設定画面の一例。
【図５】（ａ），（ｂ），（ｃ）相手状態が参照できない場合に表示される画面例（移動通信端末）。
【図６】（ａ），（ｂ），（ｃ）相手状態が参照できない場合に表示される画面例（ＰＣ）。
【図７】（ａ），（ｂ）状態の設定を促進する画面例（状態参照時）。
【図８】（ａ），（ｂ）状態の設定を促進する画面例（状態通知時）。
【図９】（ａ），（ｂ）判定条件の設定画面例。
【図１０】判定部が行うメイン処理の流れの一例を示すフローチャート。
【図１１】時間サブルーチンの流れを示すフローチャート。
【図１２】回数サブルーチンの流れを示すフローチャート。
【図１３】グループ時間サブルーチンの流れを示すフローチャート。
【図１４】合計回数サブルーチンの流れを示すフローチャート。
【図１５】個別回数サブルーチンの流れを示すフローチャート。
【図１６】参照部及び通知部が行う処理の流れを示すフローチャート。
【図１７】条件テーブルの具体例。
【図１８】第２実施形態例に係る状態管理システムの全体構成図。
【図１９】従来の状態管理システムの全体構成図。
【図２０】ユーザ状態の個別表示例（移動通信端末）。
【図２１】（ａ），（ｂ）ユーザ状態の個別表示例（ＰＣ）。
【図２２】（ａ）ユーザ状態のグループ別表示例（移動通信端末）。
（ｂ）グループ中のユーザ状態の詳細表示例（移動通信端末）。
【図２３】ユーザ状態のグループ別表示例（ＰＣ）。
【符号の説明】
１；サーバ
２ａ，ｂ；ユーザ端末
３；イントラネット／インターネット
４；移動体通信網
１０１；条件ＤＢ
１０３；判定部
Claims (13)
- ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理方法であって、
要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積し、
前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定し、
前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する、
状態管理方法。 - 前記判定は、要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況とを比較し、両者の差が判定条件に定められた所定の範囲内か否かにより行う、請求項１に記載の状態管理方法。
- ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元のユーザ端末に参照先のユーザ状態を通知可能な状態管理システムであって、
要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積している蓄積手段と、
前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する判定手段と、
前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する通知手段と、
を備える状態管理システム。 - 判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える、請求項３に記載の状態管理システム。
- 前記蓄積手段は、参照先のユーザ端末と、要求元のユーザ端末と、参照先が要求元に対して設定している判定条件とを対応付けて蓄積し、
要求元毎の判定条件の設定をユーザから受け付け、蓄積手段に格納する設定手段をさらに備える、請求項３に記載の状態管理システム。 - ユーザのユーザ状態が変化した場合に新たなユーザ状態の通知を受けるユーザを監視者とし、監視者に自ユーザ状態が通知されるユーザを監視対象とし、両者を関連付けて蓄積している第２蓄積手段と、
監視対象のユーザ状態が変化した場合、監視対象を参照先とした場合の判定条件に従い、監視対象のユーザ状態を監視者へ通知することを許可するか否かを判定し、判定結果を監視者のユーザ端末に通知する第２通知手段と、
を備える請求項３に記載の状態管理システム。 - 前記判定の結果、参照要求が許可されない場合、要求元のユーザ端末に対し、要求元のユーザ状態の設定を要求する設定要求を送信する促進手段をさらに備える、請求項３に記載の状態管理システム。
- 前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間から参照先のユーザ状態の最終更新時間までの経過時間に基づいて行う、請求項３に記載の状態管理システム。
- 前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降における、参照先のユーザ状態の更新回数に基づいて行う、請求項３に記載の状態管理システム。
- 参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新された合計回数に基づいて行う、請求項３に記載の状態管理システム。
- 参照先が複数のユーザを含むユーザグループである場合、前記判定は、要求元のユーザ端末のユーザ状態の最終更新時間以降に、参照先ユーザグループ内でユーザ状態が更新されたユーザの合計人数に基づいて行う、請求項３に記載の状態管理システム。
- ネットワークに接続されたユーザ端末を操作するユーザのユーザ状態を蓄積し、他のユーザ状態の参照要求に応じて要求元ユーザ端末に参照先のユーザ状態を提供するサーバ端末に用いられる、状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元のユーザ端末に通知するか否かを判定するための判定条件を蓄積する段階と、
Ｂ；前記他のユーザ状態の参照要求を行った要求元のユーザ端末のユーザ状態の更新状況及び参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元のユーザ端末からの参照要求を許可するか否かを判定する段階と、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元のユーザ端末に通知する段階と、
を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体。 - ネットワークに接続され、他のユーザのユーザ状態の参照要求をユーザから受け付け、参照先のユーザ状態を取得してユーザに通知可能なユーザ端末に用いられる状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
Ａ；要求元のユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違に基づいて、参照先のユーザ状態を要求元の前記ユーザに通知するか否かを判定するための判定条件を蓄積する段階と、
Ｂ；前記他のユーザ状態の参照要求を行った要求元の前記ユーザのユーザ状態の更新状況と参照先のユーザ状態の更新状況との差違、及び、前記蓄積されている判定条件に基づいて、要求元の前記ユーザからの参照要求を許可するか否かを判定する段階と、
Ｃ；前記判定により要求元のユーザ端末からの参照要求を許可しないと判定された場合に、当該参照元のユーザ端末に対して、当該参照元のユーザ端末のユーザ状態の更新を要求する通知を出力し、当該参照元のユーザ端末のユーザ状態が更新されるまで、参照が許可されない旨を示す表示態様にて参照先のユーザのユーザ状態を要求元の前記ユーザに通知する段階と、
を実行するための状態管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33157599A JP4365497B2 (ja) | 1999-11-22 | 1999-11-22 | 状態管理方法及び状態管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33157599A JP4365497B2 (ja) | 1999-11-22 | 1999-11-22 | 状態管理方法及び状態管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001147891A JP2001147891A (ja) | 2001-05-29 |
| JP4365497B2 true JP4365497B2 (ja) | 2009-11-18 |
Family
ID=18245197
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP33157599A Expired - Fee Related JP4365497B2 (ja) | 1999-11-22 | 1999-11-22 | 状態管理方法及び状態管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4365497B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0202371D0 (en) | 2002-02-01 | 2002-03-20 | Symbian Ltd | Footprints |
| JP5298584B2 (ja) * | 2007-08-22 | 2013-09-25 | 日本電気株式会社 | 情報端末、サーバ装置および情報処理方法 |
-
1999
- 1999-11-22 JP JP33157599A patent/JP4365497B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001147891A (ja) | 2001-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8719346B2 (en) | Automatically providing a communication based on location information for a user of a social networking system | |
| US7747752B2 (en) | Systems and methods for managing electronic communications using various negotiation techniques | |
| JP3985954B2 (ja) | クライアント管理方法及び装置 | |
| TWI477994B (zh) | 通訊存取控制系統與方法 | |
| US9531652B2 (en) | Communications routing and contact updates | |
| JP2012113440A (ja) | Ｓｎｓ統括サイト管理装置、及びｓｎｓ統括サイトを利用した情報開示方法 | |
| JP2015201073A (ja) | 情報アクセス制御システム、情報共有サーバ、情報アクセス制御方法及びプログラム | |
| JP4365497B2 (ja) | 状態管理方法及び状態管理システム | |
| JP2019185108A (ja) | コミュニケーション支援装置及びコミュニケーション支援プログラム | |
| JP4168762B2 (ja) | バディリストの動的生成方法、クライアント、サーバ、システム、プログラム | |
| CA2857470C (en) | System and method for communications routing | |
| JP2003196243A5 (ja) | ||
| JP2003196243A (ja) | 状態表示プログラム及び状態配信方法 | |
| JP6931336B2 (ja) | 情報通知システム、情報通知方法、及びプログラム | |
| JP6931335B2 (ja) | 情報通知システム、情報通知方法、及びプログラム | |
| JP2007293537A (ja) | プレゼンス管理方法及びプレゼンスサーバ装置 | |
| JP2007115271A (ja) | クライアント管理方法及び装置 | |
| JP2007047887A (ja) | チャットサービスを提供する方法およびソフトウェア | |
| JP5822440B2 (ja) | 交際支援装置、交際支援方法、プログラム及び記憶媒体 | |
| JP4480503B2 (ja) | 連絡手段に関連する情報処理を実施するためのプログラム | |
| KR102658680B1 (ko) | 시간 및 위치 기반의 메시지 관리 방법 | |
| JP2007128541A (ja) | 状態配信方法、状態配信プログラム及び状態配信装置 | |
| JP2003517771A (ja) | 背景情報を利用する存在管理システム | |
| JP2012199717A (ja) | メールサーバ、メール処理プログラム、メール処理方法およびメールシステム | |
| JP2003204395A (ja) | 将来の通信の交渉を行う方法、システム、プログラム、及び通信を延期する方法、システム、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060822 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080724 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080729 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080929 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20080929 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080930 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081224 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090220 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090407 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090706 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090722 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090818 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090821 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120828 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120828 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130828 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |