【書類名】 明細書
【発明の名称】 状態表示プログラム及び状態配信方法
【特許請求の範囲】
【請求項１】
ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末とその状態情報とを記憶する端末記憶手段、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラム。
【請求項２】
ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶ステップと、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項３】
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータに用いられる状態配信方法であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶ステップと、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信ステップと、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリングステップと
前記フィルタリングステップで配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信ステップと、
を含む状態配信方法。
【請求項４】
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータを機能させる状態配信プログラムであって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
として前記コンピュータを機能させる状態配信プログラム。
【請求項５】
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続される状態配信装置であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
を備える状態配信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介してユーザ間で互いに状態を参照することが可能な状態通知システムに関する。
本発明において、状態通知システムとは、複数のユーザ端末と状態通知サーバとがネットワークを介して接続されることにより構成される。このシステムは、ネットワークを介してユーザの最新の状態情報を取得し、これをユーザに対応付けて記憶する。ユーザ端末は、所望のユーザの状態情報を要求し、これを取得することができる。状態情報管理システムの一例としては、会社のオフィスなどでされている行き先表示システムや在席管理システム、バディリストシステムが挙げられる。バディリストシステムでは、ユーザは、参照したいユーザを、バディとしてバディリストに登録する。このバディリストは、状態通知サーバにより管理されている。ユーザ端末は、ユーザのバディの状態情報を取得して一覧表示する。
【０００２】
【従来の技術】
近年、MSN MessengerやAOL Instant Messenger、Yahoo Messengerなどのバディリストシステムによるコミュニケーションが、インターネット上で急速に普及している。これらのシステムでは、ユーザがバディリストに登録しているバディの状態情報が表示され、状態情報が変化すると表示が更新される。バディの状態とは、例えばインターネットへの接続状態が「オン」、「在席中」、「多忙」である。さらにシステムによっては、ユーザが、インスタントメッセージやチャットなどのコミュニケーション手段を、バディの状態に応じて選択することができる。バディリストシステムでは、１人のユーザが複数のバディリストを持つこともできる。ユーザは、自分のバディリストの中から表示するいずれかのバディリストを選択することができる。
【０００３】
【発明が解決しようとする課題】
しかし、バディの状態情報の表示の変化は、そのバディへの興味が薄れている場面では煩わしく感じられることがある。例えば、仕事仲間をバディとするバディリスト「仕事用」と、友人をバディとするバディリスト「プライベート」とをあるユーザが有するとする。仕事中は仕事仲間の状態に対する関心が高く、友人達への関心は低い。従って、友人達の状態情報が変化する度に、その友人達の状態情報の表示が変化するのは煩わしく感じられる。だからといって、バディに対するユーザの興味はユーザの状況に応じて変化するので、バディリストを構成するバディをユーザのニーズに常に合致させておくことは現実的ではない。
【０００４】
さらに、バディに対するユーザの興味は、ユーザ自身の置かれている状況だけでなく、バディの状況との関係によっても大きく変化するが、ユーザの状況とバディの状況との関係をバディの状態情報の表示に反映したバディリストシステムは未だ提供されていない。
本発明は、ユーザの状況に応じた状態情報の表示を、ユーザの操作負担を抑えつつ実現するための技術を提供することを目的とする。
【０００５】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
・前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
・前記参照希望端末とその状態情報とを記憶する端末記憶手段、
・前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
・前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶手段、
・前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、
・検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラムを提供する。
【０００６】
バディリストシステムやインスタントメッセージングシステムなどの状態通知システムにおいて、ルール記憶手段に記憶されたルールに従い、状態情報の表示を変更する。定時になるとバディリストが切り替わる、一定時間の間、特定のユーザからの状態更新通知だけを表示する、などが一例として挙げられる。
好ましい態様として、
・前記端末記憶手段は、複数の参照希望端末からなる端末グループと、前記端末グループを構成する参照希望端末とを記憶し、
・前記ルール記憶手段は、前記状態表示手段で表示される端末グループであるカレントグループを切り替えるためのアクションルールを記憶し、
・前記ルール適用手段は、検出された状況に応じたアクションルールに従い、いずれかの端末グループをカレントグループとし、
・前記状態表示手段は、前記カレントグループを構成する参照希望端末の状態情報を表示する状態表示プログラムが挙げられる。
【０００７】
別の好ましい態様として、
・前記カレントグループを変更する操作を検出する操作検出手段、及び
・前記操作に基づき、新規なアクションルール及び前記新規なアクションルールが適用される状況を生成する生成手段、として前記コンピュータをさらに機能させ、
・前記ルール記憶手段は、前記生成されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
状態表示プログラムが挙げられる。
【０００８】
このプログラムは、ユーザの操作によりカレントグループが切り替わった場合、操作とその結果とからアクションルールとその適用状況の候補を自動的に生成する。
別の好ましい態様として、
・前記ルール記憶手段は、前記状態表示手段が状態情報を表示する参照希望端末を制限するためのフィルタリングルールを前記アクションルールとしてさらに含み、
・前記ルール適用手段は、前記フィルタリングルールに基づいて、前記情報取得手段で受信した状態情報を表示するか否かを決定し、
・前記状態表示手段は、前記ルール適用手段が表示すると決定した場合、前記状態情報を表示する状態表示プログラムが挙げられる。
【０００９】
この発明では、受信する全ての状態情報更新通知を表示するのではなく、その一部だけを表示するためのフィルタリングルールを設定可能である。受信したバディの状態情報更新通知は、フィルタリングにより取捨選択されて表示される。
好ましい態様として、前記状態取得手段により取得した参照希望端末の最新の状態情報に含まれる情報に基づいて、アクションルールを適用する状況を表す情報に変換し、前記状況検出手段に通知する状態変更通知解釈手段として前記コンピュータをさらに機能させ、
前記状況検出手段は、状態変更通知解釈手段から通知された情報に基づいて、適用すべきアクションルールを抽出する状態表示プログラムが挙げられる。
【００１０】
別の好ましい態様として、
・前記ルール記憶手段は、前記参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態をアクションルールとしてさらに記憶し、
・前記状況検出手段は、前記参照希望端末の状態情報を表示する表示領域の変化を検出し、
・前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記参照希望端末の状態情報の表示形態を変更する、
状態表示プログラムが挙げられる。
【００１１】
バディの状態情報を表示するウインドウサイズに応じて表示形態が変化する。例えばウインドウが大きければアルファベット順に、小さければ参照回数順に表示する。
別の好ましい態様として、
・前記アクションルール及びそのアクションルールが適用される状況の設定を受け付ける設定受付手段をさらに含み、
・前記ルール記憶手段は、設定されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
状態表示プログラムが挙げられる。
【００１２】
ユーザからのアクションルール及びそのルールが適用される状況の設定を受け付ける。
本願第２発明は、ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶ステップと、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１３】
ここで、記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、CD-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
本願第３発明は、第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータに用いられる状態配信方法であって、
・ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶ステップと、
・前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信ステップと、
・前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリングステップと
・前記フィルタリングステップで配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信ステップと、
を含む状態配信方法を提供する。
【００１４】
この方法は、例えばバディリストシステムのバディリストサーバに用いられる。フィルタリングルールは、ユーザ端末をバディに登録している参照ユーザ端末のうちどの端末に状態情報を配信するかを規定する。バディリストサーバは、ユーザ端末から状態情報更新通知を受信すると、フィルタリングルールを満たす参照ユーザ端末に、前記状態情報更新通知を配信する。
前記方法の好ましい態様として、
・前記記憶ステップは、ユーザ端末のユーザ識別子と、前記ユーザ端末へ他のユーザ端末の状態情報の配信を制限するための逆フィルタリングルールと、前記逆フィルタリングルールを適用する状況と、を１レコードにさらに含み、
・前記フィルタリングステップは、前記第１ユーザ端末のフィルタリングルールと、前記第１ユーザ端末の状態を参照するユーザ端末の逆フィルタリングルールとに基づいて、前記状態情報を配信する配信先を決定する、
状態配信方法が挙げられる。
【００１５】
逆フィルタリングルールは、ユーザ端末のバディの端末からの状態情報更新通知を制限する。例えばバディの状態情報が更新された場合、バディ端末のフィルタリングルールと、ユーザ端末の逆フィルタリングルールとに基づいて、状態情報更新通知の配信先が決定する。
本願第４発明は、第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータを機能させる状態配信プログラムであって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
として前記コンピュータを機能させる状態配信プログラムを提供する。
【００１６】
本願第５発明は、第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続される状態配信装置であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
を備える状態配信装置を提供する。
【００１７】
【発明の実施の形態】
＜バディリストシステム＞
まず始めに、バディリストシステムについて説明する。バディリストシステムは、本発明の状態表示プログラムや状態配信方法が適用される状態通知システムの一例である。
図１は、バディリストシステムの構成を示す。バディリストシステムは、ユーザの状態情報を管理しているバディリストサーバ２と、複数のユーザ端末１ａ、１ｂ、１ｃ（以下、単にユーザ端末１という）とが、ネットワーク３を介して接続されて構成される。バディリストサーバ２及びユーザ端末１は、コンピュータを用いて実現可能である。
【００１８】
ユーザ端末１ａ(UserID:U100)を操作するユーザＡは、１または複数の自己の状態情報を、バディリストサーバ２に登録する。ユーザ端末１ａは、登録した状態情報の公開レベル、例えば「参照許可ユーザ」を、状態情報毎に設定することも可能である。ここで参照許可ユーザとは、ユーザ端末１ａの状態情報の参照を許可するユーザＡ以外の他のユーザである。またユーザＡは、自分が状態情報を参照したいユーザグループをバディリストサーバ２に登録する。このユーザグループをバディリストと言い、ユーザグループを構成する各ユーザをバディと言う。ユーザＡは、複数のバディリストを登録することもできる。バディをバディリストに登録するために、バディに指定されたユーザから参照許可を要するバディリストシステムでは、ユーザＡは参照許可ユーザを設定する必要はない。
【００１９】
一方でユーザ端末１ａは、バディであるユーザＢ，Ｃが操作するユーザ端末１ｂ、１ｃの状態情報の更新通知をバディリストサーバ２から受信し、これらの表示を更新する。ユーザ端末１ａが起動されていない間に更新されたユーザ端末１ｂ、１ｃの最新の状態情報は、ユーザ端末１ａが起動された時点で、バディリストサーバ２から通知され、ユーザ端末１ａで表示される。
バディリストサーバ２は、ユーザ管理ＤＢ２１と、状態配信モジュール２２と、状態受付モジュール２３とを有している。状態受付モジュール２３は、ユーザ端末１ａから通知される状態情報を、ユーザＩＤ「U001」に対応づけてユーザ管理データベース（ＤＢ）２１に記憶する。ユーザ管理ＤＢ２１は、１つのユーザＩＤに対し、１または複数の状態情報を記憶することができる。また状態受付モジュール２３は、ユーザ端末１ａから通知された参照許可ユーザ及びバディリストの内容を、ユーザ管理ＤＢ２１に記憶しておく。バディリストシステムによっては、バディリストにバディを登録するためには、バディからの参照許可を要するものもある。このようなバディリストシステムでは、ユーザ管理ＤＢ２１は、バディとは別に参照許可ユーザを記憶しておく必要はない。状態配信モジュール２２は、ユーザ端末１ａの最新の状態情報を受け取ると、ユーザ端末１ａの参照許可ユーザへ、更新された状態情報を通知する。なお、バディリストサーバ２は、各ユーザ端末をユーザＩＤにより一義的に識別する。
【００２０】
つまり、バディリストシステムでは、ユーザは、関心を持つ他のユーザであるバディと、自己の最新の状態情報とを登録しておく。これにより、基本的にはバディの状態がユーザ端末１上で一覧表示される。また、ユーザのバディの状態情報が変更された場合、ユーザ端末１上で表示されているバディの状態情報が自動的に更新される。ユーザ端末１は、バディリストサーバ２にバディリストを登録しておくことにより、気になるユーザの状態を手軽に参照することが可能となる。
【００２１】
＜第１実施形態例＞
次に、前記図１に示すバディリストシステムに本発明を適用した第１実施形態例について説明する。
［ユーザ端末］
図２は、前記ユーザ端末１の機能構成を示すブロック図である。このユーザ端末１は、バディリストシステムを構成するユーザ端末としての機能に加え、本発明に係る状態表示プログラムの機能を有している。ユーザ端末１には、キーボードやマウスなどの入力手段４と、ディスプレイなどの出力手段５とが接続されている。ユーザ端末１は、バディリストＤＢ１１（端末記憶手段）、アクションルールＤＢ１２（ルール記憶手段）及び複数のモジュールを有している。
【００２２】
図３は、バディリストＤＢ１１に蓄積されるバディ情報の概念説明図である。バディリストＤＢ１１には、ユーザ端末１を操作するユーザ（UserＩＤ：U100）のバディリスト（端末グループ）及び各バディ（参照希望端末）の状態情報が記憶されている。この図が示すように、バディリストＤＢ１１は、１または複数のバディリストを保持することができる。この例では、バディ情報は以下の（ａ）〜（ｇ）のデータを含んでいる。
（ａ）バディリストＩＤ：バディリストを特定する識別データ。
（ｂ）バディリスト名：ユーザがバディリストにつけた名称。バディリスト名はユーザが任意の名称を設定することができる。
（ｃ）バディＩＤ：バディリストを構成するバディのユーザＩＤ。
（ｄ）バディ名：バディの名称。
（ｅ）状態情報：バディの状態情報。
（ｆ）通信アドレス：バディが操作するユーザ端末（以下、バディ端末という）のネットワークアドレス。
（ｇ）位置情報：バディ端末の位置を示すデータ。バディ端末の位置情報は、例えばユーザ端末１がＧＰＳを搭載した携帯型コンピュータである場合には、ＧＰＳ座標を用いることができる。
【００２３】
図４は、アクションルールＤＢ１２に記憶されるルール情報の一例の概念説明図である。ルール情報は、バディの状態情報の表示の仕方を変更するための「アクションルール」と、アクションルールが適用される状況を示す「適用状況」と、アクションＩＤとを１レコードに含んでいる。この例では、アクションＩＤ“１”、“２”及び“４”のアクションルールは、ディスプレイなどに表示されるバディリストを切り換えるためのアクションルールである。例えば、アクションＩＤ“２”の適用状況及びアクションルールに従えば、時刻が９〜１７時の間は、バディリスト「仕事用」が表示対象となる。これにより、ユーザの状況に応じたバディリストを自動的に表示することができる。以下、表示対象のバディリストをカレントリスト（カレントグループに相当）という。
【００２４】
アクションＩＤ“３”のアクションルールは、通知される状態情報を制限するためのアクションルールである。アクションＩＤ“２”の適用状況及びアクションルールに従えば、時刻が８〜１７時の間はフィルタ「working」を用いる。このフィルタは、通信アドレスが「*＠fujitsu.com」以外から通知される状態情報の更新通知を表示しないことを規定する。これにより、例えば仕事中に仕事仲間以外からの状態情報更新通知が表示され、仕事の邪魔になるというようなことを防止できる。
【００２５】
アクションＩＤ“５”及び“６”の適用状況及びアクションルールは、状態情報を表示するウインドウの大きさの変化に対応して状態情報の表示形態を変えるためのアクションルールである。この例では、ウインドウが大きい場合、状態情報をバディ名のアルファベット順に表示することになっている。また、ウインドウが小さい場合、状態情報の参照回数が多い順にバディを表示することになっている。
アクションＩＤ“７”の適用状況及びアクションルールは、近くにバディがいる場合、カレントリストの中で近くにいるバディの状態情報を表示するためのアクションルールである。ここでは、半径１０キロ以内にいるバディを近くにいると判断する。近くにいるか否かは、ユーザ端末及びバディ端末の状態情報に基づいて判断可能である。以上に述べたルール情報は、説明のための一例に過ぎない。ルール情報に含まれる適用状況やアクションルールの内容は、ニーズに応じて適宜変更可能である。
【００２６】
［バディリストサーバ］
前述したように、バディリストサーバ２は、状態受付モジュール２３によりユーザ端末の状態情報及びバディリストの変更を受け付け、状態配信モジュール２２により状態情報をユーザ端末に配信する。状態情報やバディリストは、ユーザ管理ＤＢ２１に記憶されている。
図５は、バディリストサーバ２のユーザ管理ＤＢ２１に記憶されるユーザ情報の概念説明図である。ユーザ管理ＤＢ２１には、ユーザごとにユーザの状態情報やバディリストなどが記憶されている。この例では、ユーザ情報は、データを１レコードに含んでいる。なお、ここに示したユーザ情報は、バディリストにバディを登録するために、バディからの参照許可を要する場合のユーザ情報である。従って、ユーザ情報には参照許可ユーザが含まれていない。またここでは、１つのユーザ端末に１つの状態情報が対応する例を示す。
（ａ）ユーザＩＤ：バディリストシステム上でユーザを識別する識別子。
（ｂ）状態情報：ユーザＩＤで特定されるユーザ端末の状態情報。
（ｃ）通信アドレス：ユーザ端末のネットワークアドレス。
（ｄ）位置情報：ユーザ端末の位置を示すデータ。例えばＧＰＳ座標、
（ｅ）バディリスト名：ユーザＩＤで特定されるユーザ端末が保持するバディリスト名。
（ｆ）バディＩＤ：各バディリストを構成するバディのユーザＩＤ。
（ｇ）バディ名：各ユーザ端末が保持するバディの名称。
【００２７】
［処理の流れ］
次に、ユーザ端末１の各モジュール及びバディリストサーバ２の各モジュールの機能について、例を挙げて説明する。以下では説明を容易にするために、バディリストＤＢ１１、アクションルールＤＢ１２及びユーザ管理ＤＢ２１は、前記図３〜図５に示した状態にあると仮定する。
（１）ルール適用処理
図６は、ユーザ端末１が行うルール適用処理の流れを示すフローチャートである。この処理では、検知された状況に応じ、バディリストの表示が変更される。例えば、ユーザ端末１の電源が投入されることにより、以下の処理が開始される。
【００２８】
ステップＳ１：状況検出モジュール１８（状況検出手段）は、アクションルールＤＢ１２に記憶されているいずれかの適用状況の発生を待機し、適用状況の発生が検出されるとステップＳ２に以降する。例えば、「バディ状態情報の更新通知」、「所定の時刻になった」、などの状況を検出する。
ステップＳ２：ルール適用モジュール１９（ルール適用手段）は、検出された適用状況によりカレントリストが変更されるか否かを判断する。この例では、カレントリストを変更する適用状況とは、時刻が９時になる場合、１７時になる場合、または２０時になる場合である。“Ｙｅｓ”と判断するとステップＳ３に移行する。“Ｎｏ”と判断すると、後述するステップＳ５に移行する。
【００２９】
ステップＳ３、Ｓ４：ルール適用モジュール１９は、アクションルールＤＢ１２を参照し、生じた状況に応じたアクションルールに従ってカレントリストを変更する。例えば、時刻が９時になった場合、バディリスト「仕事用」を構成するバディの状態情報やバディ名をバディリストＤＢ１１から読み出し、バディリスト表示モジュール２０に送出する（Ｓ３）。バディリスト表示モジュール２０は、新たなカレントリスト「仕事用」のバディの状態情報などをディスプレイなどに出力する（Ｓ４）。
【００３０】
ステップＳ５：発生した状況がカレントリストを変更する状況ではない場合、ステップＳ５に移行する。ルール適用モジュール１９は、生じた状況がバディの新たな状態情報の通知であるか否かを判断する。“Ｙｅｓ”と判断するとステップＳ６に移行する。“Ｎｏ”と判断すると、後述するステップＳ９に移行する。
ステップＳ６：ルール適用モジュール１９は、適用するアクションルールがあるか否かを判断する。時刻が８〜１７時であれば、アクションＩＤ“３”のアクションルールが適用される。すなわち、ルール適用モジュール１９は、状態情報が更新されたバディの通信アドレスを参照し、「*＠fujitsu.com」か否かを判断する。“Ｙｅｓ”と判断すると、表示を更新すると判断する。“Ｎｏ”と判断すると、表示を更新しないと判断する。
【００３１】
ステップＳ７：ルール適用モジュール１９は、表示を更新する場合ステップＳ８に移行し、表示を更新しない場合には後述するステップＳ１３に移行する。
ステップＳ８：ルール適用モジュール１９は、更新された状態情報をバディリスト表示モジュール２０に送出する。バディリスト表示モジュール２０は、このデータに基づいてカレントリストのバディの一人の状態情報の表示を更新する。
ステップＳ９：ルール適用モジュール１９は、前記ステップＳ１でウインドウサイズの変更が検出された場合、ステップＳ１０に移行する。そうでない場合には、後述するステップＳ１１に移行する。
【００３２】
ステップＳ１０：ルール適用モジュール１９は、新たなウインドウサイズに応じて適用するアクションルールを決定し、状態情報の表示データを変更する。例えばウインドウサイズが大きくなった場合には、アクションＩＤ“５”のアクションルールを適用する。すなわち、ルール適用モジュール１９は、カレントリストのバディをバディ名のアルファベット順に並べ直す。バディリスト表示モジュール２０は、アルファベット順にバディがソートされたカレントリストの表示用データを生成し、ディスプレイなどに出力する。
【００３３】
ステップＳ１１：ルール適用モジュール１９は、前記ステップＳ１でバディの位置情報がバディリストサーバ２から通知されたか否かを判断する。“Ｙｅｓ”と判断するとステップＳ１２に移行する。“Ｎｏ”と判断すると後述するステップＳ１３に移行する。
ステップＳ１２：ルール適用モジュール１９は、カレントリストの中で近くにいるバディを状態情報解釈モジュール１１０に問い合わせて判定し、該当するバディだけを残し、他を削除する。この場合、状態情報解釈モジュール１１０は、バディの位置情報に基づいて自端末とバディとの距離を算出し、状況検出モジュール１８に通知する。状況検出モジュール１８は、状態情報解釈モジュール１１０で解釈された自端末からの距離情報に基づいて、適用するアクションルールの対象となるバディを抽出する。バディリスト表示モジュール２０は、変更された一時的なバディリストに基づいて表示用データを生成し、出力手段５に出力する。例えば、カレントリスト「緊急時待機用」において、バディ「小沢さん」と「小泉君」とが近くに検出されたとする。その場合、ルール適用モジュール１９は、表示対象のバディを「小沢さん」と「小泉君」とに変更する。バディリスト表示モジュール２０は、この二人の状態情報だけを表示する表示用データを生成し、ディスプレイなどに出力する。
【００３４】
ステップＳ１３：ルール適用モジュール１９は、ユーザ端末１の動作が終了するか否かを判断する。“Ｎｏ”と判断すると、前記ステップＳ１に戻り、同様の処理を繰り返す。“Ｙｅｓ”と判断すると処理を終了する。
（２）状態通知処理
図７は、前記ルール適用処理とは独立にユーザ端末１が行う状態通知処理である。この処理は、バディリストシステムのユーザ端末として機能するための処理である。この処理は、大別して自状態及びバディリストの通知と、バディの状態情報の受信及び表示とを行う。
【００３５】
ステップＳ２１：状態通知モジュール１４は、自状態情報が変更された否かを判断する。“Ｙｅｓ”と判断するとステップＳ２２に移行する。“Ｎｏ”と判断するとステップＳ２３に移行する。自状態情報の更新は、状態通知モジュール１４が検出してもよいし、状態通知モジュール１４が新たな自状態情報の設定を受け付けてもよい。状態通知モジュール１４が検出可能な自状態情報としては、スクリーンセーバーの動作時間による離席／在席、キーボード入力の頻度による多忙／普通、スケジュール帳（図示せず）の参照による外出中／移動中などが一例として挙げられる。もちろん、これらの状態情報のユーザによる入力・設定を状態通知モジュール１４が受け付けることもできる。
【００３６】
ステップＳ２２：状態通知モジュール１４は、バディリストサーバ２に新たな自状態情報とユーザＩＤとを通知する。これを受信したバディリストサーバ２は、新たな状態情報をユーザ管理ＤＢ２１に記憶し、ユーザ端末の状態情報を更新する。
ステップＳ２３：状態取得モジュール１３（状態取得手段）はバディリストサーバ２からの状態情報更新通知を待機しており、これを受信するとステップＳ２４に移行する。状態情報更新通知には、バディのユーザＩＤと、バディの新たな状態情報とが含まれている。
【００３７】
ステップＳ２４：状態取得モジュール１３は、受信したバディの新たな状態情報をバディリストＤＢ１１に書き込み、そのバディの状態情報を更新する。
ステップＳ２５：状態通知モジュール１４は、ユーザの操作によるバディリストの変更を待機しており、バディリストが変更されるとステップＳ２６に移行する。
ステップＳ２６：状態通知モジュール１４は、新たなバディリストをバディリストＤＢ１１に書き込み、バディ情報を更新する。バディ情報の更新とは、新たなバディリストの生成、既存のバディリストへの新たなバディの追加、既存のバディリストからのバディの削除などである。また、バディリスト名の変更も含まれる。
【００３８】
ステップＳ２７：さらに状態通知モジュール１４は、更新したバディ情報を、バディリストサーバ２に通知する。この通知には、ユーザ端末のユーザＩＤも含まれる。この通知を受け、バディリストサーバ２は、ユーザ管理ＤＢ２１に新たなバディ情報を書き込む。
ステップＳ２８：状態取得モジュール１３及び状態通知モジュール１４は、ユーザ端末１の電源がオフにされるなどにより処理を終了する。処理が終了されるまで、前記ステップＳ２１〜Ｓ２７が繰り返される。
【００３９】
（３）ルール作成処理
図８は、ユーザ端末１が行うルール作成処理の流れを示すフローチャートである。この処理では、アクションルール及びその適用状況の作成が行われる。
ステップＳ３１：操作検出モジュール１６（操作検出手段）は、ユーザがカレントリストを変更する操作を検出する。例えば１２時に、カレントリストがバディリスト「プライベート」にユーザの操作により変更されることを検出する。
ステップＳ３２：ルール生成モジュール１７（生成手段）は、操作及びカレントリストの変化に基づいて、新しいアクションルールとその適用状況とを生成し、アクションルールＤＢ１２に登録する。例えば、バディリストがカレントリストとして用いられた時刻「12:00」からシステムで予め設定されたデフォルト値、例えば１時間が経過した時刻「13:00」を終了時刻として、適用状況を生成する。アクションルールとして、「カレントリスト＝バディリスト「プライベート」」を設定する。
【００４０】
ステップＳ３３：設定受付モジュール１５（設定受付手段）は、アクションルールの設定が指示されるのを待機し、ステップＳ３４に移行する。例えば、設定受付モジュール１５は、カレントリストと共に「アクションルール設定ボタン」を表示させ、これを押されたか否かにより指示の有無を判断する。
ステップＳ３４：設定受付モジュール１５は、入力手段４からアクションルール及びその適用状況の入力を受け付け、これらをアクションルールＤＢ１２に登録する。例えば、設定受付モジュール１５は、新しいアクションルールとその適用状況とを入力する画面を出力手段５に出力し、画面上での入力を受け付けてもよい。
【００４１】
ステップＳ３５：設定受付モジュール１５、操作検出モジュール１６及びルール生成モジュール１７は、ユーザ端末１の電源がオフになると処理を終了する。それまでは前記ステップＳ３１〜３４までの処理を繰り返し実行する。
＜第２実施形態例＞
図９は、第２実施形態例に係るバディリストシステムの全体構成図である。このバディリストシステムは、前記第１実施形態例と同様に、ユーザ端末１及びバディリストサーバ２がネットワーク３により接続され構成されている。
【００４２】
［バディリストサーバ］
バディリストサーバ２は、バディリストサーバとしての機能に加え、本発明に係る状態配信方法を実行する機能をさらに有している。具体的にはバディリストサーバ２は、ユーザ管理ＤＢ２１、状態配信モジュール２２、状態受付モジュール２３に加え、フィルタリングルールＤＢ２４、フィルタリングモジュール２６及びルール登録モジュール２７をさらに有している。図中、第１実施形態例と同様の機能を有する要素については、同じ番号を付して示している。ユーザ管理ＤＢ２１には、前記図５に例示するユーザ情報が蓄積されている。
【００４３】
図１０は、フィルタリングルールＤＢ２４に記憶されるフィルタリング情報の概念説明図である。フィルタリング情報は、「ユーザＩＤ」、「フィルタリングルール」、及びフィルタンリングルールが適用される「適用状況」を、１レコードに含んでいる。１レコードには、複数の適用状況とフィルタンリングルールとの組み合わせを記憶することができる。例えば、ユーザＩＤ「U100」のユーザは、時刻８時〜１７時までに適用されるフィルタ「working」とそれ以外でのフィルタ「private」とを登録している。
【００４４】
フィルタは、この例では、ユーザが参照許可ユーザへの自状態の通知を制限する送信フィルタ（逆フィルタリングルール）と、自分のバディからの状態更新通知（フィルタリングルール）を制限するための受信フィルタとがある。この図では、ユーザ「U100」のフィルタ「working」は自分のバディからの状態更新通知を制限するための受信フィルタである。また、フィルタ「private」は、自状態を参照する参照ユーザ、すなわちユーザU100をバディに登録している他のユーザへの自状態情報の通知を制限するための送信フィルタである。フィルタリング情報やフィルタリングの内容は、ニーズに応じて適宜変更可能である。
【００４５】
［ユーザ端末］
ユーザ端末１の機能構成は前記図２と同様である。図中、第１実施形態例と同様の機能を有する要素については、同じ番号を付して示している。バディリスト１１には、前記図３に例示するバディ情報が蓄積されている。
図１１は、ユーザ端末のアクションルールＤＢ１２に記憶されるルール情報の概念説明図である。前記第１実施形態例と同様に、アクションルールＤＢ１２には、「アクションＩＤ」、「適用状況」及び「アクションルール」が１レコードに記憶される。ただしこの例では、バディからの状態情報更新通知を制限するフィルタはバディリストサーバ２に記憶されているので、アクションルールＤＢ１２には記憶されていない。
【００４６】
［処理の流れ］
以下、バディリストサーバ２及びユーザ端末１の各モジュールの機能について、具体的に説明する。以下において、ユーザ管理ＤＢ２１、フィルタリングルールＤＢ２４、バディリストＤＢ１１及びアクションルールＤＢ１２は、図５、図１０、図３及び図１１に例示する状態にあると仮定する。
図１２は、バディリストサーバ２が行う処理の流れを示すフローチャートである。この処理では、バディリストサーバ２は、ユーザ端末の状態情報の受信とその更新及び配信とに加え、配信する状態情報のフィルタリングを行う。
【００４７】
ステップＳ４１：状態受付モジュール２３は、いずれかのユーザ端末１からの状態更新通知を待機している。今、説明を容易にするために、ユーザU100から状態情報の更新通知があったと仮定する。状態更新通知を受信するとステップＳ４２に移行する。
ステップＳ４２：状態受付モジュール２３は、受信した状態情報を、通知元のユーザ端末U100の新たな状態情報として、ユーザ管理ＤＢ２１に書き込む。
ステップＳ４３：フィルタリングモジュール２６は、通知元ユーザU100をバディに登録している全ての参照ユーザを、ユーザ管理ＤＢ２１から読み出す。次いでフィルタリングモジュール２６は、参照ユーザ及び通知元ユーザのフィルタリングルールの中で適用されるフィルタリングルールがあるか否かを判断する。例えば、どのユーザのフィルタリングルールも設定されていない時刻であれば、フィルタリングルールはないと判断される。フィルタリングルールがある場合、ステップＳ４４に移行する。ない場合、後述するステップ４５に移行する。
【００４８】
ステップＳ４４：フィルタリングモジュール２６は、参照ユーザ及び通知元ユーザU100のフィルタリングルールを、フィルタリングルールＤＢ２４から読み出す。図３を参照すれば、ユーザU101は、ユーザU100をバディに登録している。従って、ユーザU100及びユーザU101のフィルタリングルールが読み出される。
ステップＳ４５：フィルタリングモジュール２６は、読み出されたフィルタリングルールに基づいて、状態情報の配信先を決定する。例えば、時刻が１０時であればユーザU100は自状態情報を通知することについては制限していない。一方、ユーザU100の参照ユーザの１人であるU101は、バディリスト「仕事用」のバディからの状態更新通知のみを受け付ける受信フィルタ「working」を設定している。通知元ユーザU100は、ユーザU101のバディリスト「仕事用」のバディの１人であるから、配信先の１つはユーザU101と決定する。なお、適用すべきフィルタリングルールがない場合、フィルタリングモジュール２６は、全ての参照ユーザを配信先とする。
【００４９】
ステップＳ４６：フィルタリングモジュール２６は、配信先があるか否かを判断し、ある場合には状態配信モジュール２２に状態情報の配信を依頼する。この依頼には、配信先ユーザ端末の通信アドレス、配信される状態情報、その状態情報の持ち主であるユーザのユーザＩＤが含まれている。
ステップＳ４７：状態配信モジュール２２は、依頼された状態情報を依頼された配信先に配信する。
前記ステップＳ４１で状態情報の通知ではないと判断すると、ステップＳ４８に移行する。ステップＳ４８では、状態受付モジュール２３はバディリストの更新通知か否かを判断する。“Ｙｅｓ”と判断するとステップＳ４９に移行し、“Ｎｏ”と判断すると再び前記ステップＳ４１に戻る。
【００５０】
ステップＳ４９：状態受付モジュール２３は、受信した新たなバディリストをユーザ管理ＤＢ２１に書き込む。
ステップＳ４１０：ルール登録モジュール２７は、フィルタリングルールをユーザ端末１から受信したか否かを判断し、“Ｙｅｓ”と判断するとステップＳ４１１に移行する。なお、本第２実施形態例においては、ユーザ端末１の設定受付モジュール１５は、フィルタリングルール及びその適用状況の設定を受け付け、受け付けた情報をバディリストサーバ２に送信する。
【００５１】
ステップＳ４１１：ルール登録モジュール２７は、ユーザ端末１から受信したフィルタリングルール及びその適用状況を、フィルタリングルールＤＢ２４に書き込む。
＜画面例＞
図１３は、ユーザ端末１の設定受付モジュール１５が表示するアクションルール登録画面例である。この画面は、アクションルール及びその適用状況の設定を受け付ける。
【００５２】
図１４は、ユーザ端末１のルール適用モジュール１９による状態情報の表示の変化例である。図１４（Ａ）は、時間によりカレントリストが変化する例である。これは、前記図４におけるアクションＩＤ“２”のルール情報に対応する。
図１４（Ｂ）は、ウインドウサイズの変化に応じ、カレントリストのバディの表示順が変化する例である。図中左側は、ウインドウサイズが大きい場合に、バディとその状態とがアルファベット順に表示される例を示す。図中右側は、ウインドウサイズが小さくなった場合に、バディとその状態情報とがバディの状態情報の参照回数順に表示される例を示す。なお、参照回数は、例えばユーザ端末１の状態取得モジュール１３により算出可能である。このウインドウ変化は、前記図４のアクションＩＤ“５”及び“６”のルール情報に対応する。
【００５３】
図１４（Ｃ）は、バディ端末の位置情報に応じ、カレントリストの表示形態が変化する例である。この図は、前記図４のアクションＩＤ“７”におけるルール情報に対応する。図中左側は、近くにバディがいない場合の状態情報の表示例である。図中右側は、近くにバディが検出された場合の状態情報の表示例である。
＜その他の実施形態例＞
（Ａ）ユーザの操作に基づいてアクションルール及びその適用状況を生成する場合、何度か同じ操作が頻繁に繰り返されたことを条件にルール情報を生成しても良い。３日続けて、１２時〜１３時に、プライベートリストをカレントリストとしたら、ルール情報を生成するなどである。
【００５４】
（Ｂ）前述した方法を実行するプログラム及びこのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。ここで、記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、CD-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
＜付記＞
（付記１）
ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末とその状態情報とを記憶する端末記憶手段、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラム。
【００５５】
（付記２）
前記端末記憶手段は、複数の参照希望端末からなる端末グループと、前記端末グループを構成する参照希望端末とを記憶し、
前記ルール記憶手段は、前記状態表示手段で表示される端末グループであるカレントグループを切り替えるためのアクションルールを記憶し、
前記ルール適用手段は、検出された状況に応じたアクションルールに従い、いずれかの端末グループをカレントグループとし、
前記状態表示手段は、前記カレントグループを構成する参照希望端末の状態情報を表示する、
付記１に記載の状態表示プログラム。
【００５６】
（付記３）
前記カレントグループを変更する操作を検出する操作検出手段、及び
前記操作に基づき、新規なアクションルール及び前記新規なアクションルールが適用される状況を生成する生成手段、として前記コンピュータをさらに機能させ、
前記ルール記憶手段は、前記生成されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記２に記載の状態表示プログラム。
【００５７】
（付記４）
前記ルール記憶手段は、前記状態表示手段が状態情報を表示する参照希望端末を制限するためのフィルタリングルールを前記アクションルールとしてさらに含み、
前記ルール適用手段は、前記フィルタリングルールに基づいて、前記情報取得手段で受信した状態情報を表示するか否かを決定し、
前記状態表示手段は、前記ルール適用手段が表示すると決定した場合、前記状態情報を表示する、
付記１に記載の状態表示プログラム。
【００５８】
（付記５）
前記状態取得手段により取得した参照希望端末の最新の状態情報に含まれる情報に基づいて、アクションルールを適用する状況を表す情報に変換し、前記状況検出手段に通知する状態変更通知解釈手段として前記コンピュータをさらに機能させ、
前記状況検出手段は、状態変更通知解釈手段から通知された情報に基づいて、適用すべきアクションルールを抽出する、
付記１に記載委の状態表示プログラム。
【００５９】
（付記６）
前記ルール記憶手段は、前記参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態をアクションルールとしてさらに記憶し、
前記状況検出手段は、前記参照希望端末の状態情報を表示する表示領域の変化を検出し、
前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記参照希望端末の状態情報の表示形態を変更する、
付記１に記載の状態表示プログラム。
【００６０】
（付記７）
前記アクションルール及びそのアクションルールが適用される状況の設定を受け付ける設定受付手段をさらに含み、
前記ルール記憶手段は、設定されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記１に記載の状態表示プログラム。
（付記８）
ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶ステップと、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
【００６１】
（付記９）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータに用いられる状態配信方法であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶ステップと、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信ステップと、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリングステップと
前記フィルタリングステップで配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信ステップと、
を含む状態配信方法。
【００６２】
（付記１０）
前記記憶ステップは、ユーザ端末のユーザ識別子と、前記ユーザ端末へ他のユーザ端末の状態情報の配信を制限するための逆フィルタリングルールと、前記逆フィルタリングルールを適用する状況と、を１レコードにさらに含み、
前記フィルタリングステップは、前記第１ユーザ端末のフィルタリングルールと、前記第１ユーザ端末の状態を参照するユーザ端末の逆フィルタリングルールとに基づいて、前記状態情報を配信する配信先を決定する、
付記９に記載の状態配信方法。
【００６３】
（付記１１）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータを機能させる状態配信プログラムであって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
として前記コンピュータを機能させる状態配信プログラム。
【００６４】
（付記１２）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続される状態配信装置であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
を備える状態配信装置。
【００６５】
【発明の効果】
本発明を用いれば、ユーザの操作負担を増加させることなく、ユーザの状態に適した状態情報を表示することができる。
【図面の簡単な説明】
【図１】
第１実施形態例に係るバディリストシステムの全体構成例。
【図２】
ユーザ端末の機能構成を示す説明図。
【図３】
バディリストＤＢに蓄積されるバディ情報の概念説明図。
【図４】
アクションルールＤＢに蓄積されるルール情報の概念説明図。
【図５】
ユーザ管理ＤＢに蓄積されるユーザ情報の概念説明図。
【図６】
ルール適用処理の流れの一例を示すフローチャート。
【図７】
状態通知処理の流れの一例を示すフローチャート。
【図８】
ルール作成処理の流れの一例を示すフローチャート。
【図９】
第２実施形態例に係るバディリストシステムの全体構成例。
【図１０】
フィルタリングルールＤＢに蓄積される情報の概念説明図。
【図１１】
図９のアクションルールＤＢに蓄積されるルール情報の概念説明図。
【図１２】
サーバが行う処理の流れの一例を示すフローチャート。
【図１３】
アクションルール登録画面例。
【図１４】
状態情報の表示の変化例。
（Ａ）時間によりカレントリストが変化する例。
（Ｂ）ウインドウサイズの変化に応じ、カレントリストのバディの表示順が変化する例。
（Ｃ）バディ端末の位置情報に応じ、カレントリストの表示形態が変化する例。
【符号の説明】
１：ユーザ端末
２：バディリストサーバ
１２：アクションルールＤＢ
１９：ルール適用ジュール
[Document name] statement
Patent application title: State display program and state distribution method
[Claim of claim]
[Claim 1]
A state display program that causes a computer operated by a user to function,
The user refers to the state information State acquisition means for acquiring the latest state information of the desired reference request terminal,
Terminal storage means for storing the reference request terminal and its state information;
State display means for displaying the latest state information of the reference request terminal stored by the terminal storage means;
Rule storage means for storing in one record an action rule for changing the display mode of the state information of the reference request terminal, the situation to which the action rule is applied, and the correspondence between the action rule and the situation
Condition detection means for detecting any of the conditions stored in the rule storage means;
Rule application means for changing the display mode of the state information of the reference request terminal displayed by the state display means according to an action rule corresponding to the detected situation;
A status display program that causes the computer to function.
[Claim 2]
A computer readable recording medium storing a status display program operating on a computer operated by a user, comprising:
The user refers to the state information A state acquisition step of acquiring the latest state information of a desired reference request terminal;
A terminal storage step of storing the reference request terminal and its state information;
A state display step of displaying the latest state information of the reference request terminal stored in the terminal storage means;
An action rule for changing a display mode of state information of the reference request terminal, a condition storing the action rule, and a rule storing step of storing the action rule and correspondence of the condition in one record;
A situation detection step of detecting any situation stored in the rule storage means;
A rule application step of changing a display mode of the state information of the reference desired terminal displayed by the state display unit according to an action rule corresponding to the detected situation;
A computer readable recording medium recording a status display program for executing.
[Claim 3]
A state distribution method used for a computer connected via a network to a user terminal including a first user terminal and a second user terminal, the network comprising:
Storing, in one record, a user identifier for identifying a user terminal, a filtering rule for limiting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving the status information of the first user terminal from the first user terminal;
A filtering step of determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
A transmitting step of transmitting state information of the first user terminal to the user terminal determined as the distribution destination in the filtering step;
State delivery method including:
[Claim 4]
A state distribution program that causes a computer connected via a network to a user terminal including a first user terminal and a second user terminal to function,
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
A state delivery program that causes the computer to function.
[Claim 5]
A state distribution device connected via a network to a user terminal including a first user terminal and a second user terminal, the network comprising:
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
A state distribution device comprising:
Detailed Description of the Invention
[0001]
Field of the Invention
The present invention relates to a status notification system capable of referring to each other among users via a network.
In the present invention, the status notification system is configured by connecting a plurality of user terminals and a status notification server via a network. This system acquires the latest state information of the user via the network, associates it with the user, and stores it. The user terminal can request and obtain desired user status information. As an example of the status information management system, there are a destination display system, a presence management system, and a buddy list system which are used in a company office or the like. In the buddy list system, a user registers a user who wants to refer to the buddy list as a buddy. This buddy list is managed by the status notification server. The user terminal acquires the state information of the buddy of the user and displays a list.
[0002]
[Prior Art]
In recent years, communication by buddy list systems such as MSN Messenger, AOL Instant Messenger, Yahoo Messenger, etc. is rapidly spreading on the Internet. In these systems, the state information of the buddy registered by the user in the buddy list is displayed, and the display is updated when the state information changes. The state of buddy is, for example, the state of connection to the Internet being "on", "being present", or "busy". Furthermore, depending on the system, the user can select communication means such as instant messaging and chat according to the state of the buddy. In the buddy list system, one user can have multiple buddy lists. The user can select any of the buddy lists to display from his / her buddy list.
[0003]
[Problems to be solved by the invention]
However, changes in the display of a buddy's status information may be annoying in situations where the buddy's interest is diminishing. For example, it is assumed that a user has a buddy list “for work” whose buddies are buddy and a buddy list “private” whose buddy is a friend. During work, interest in the status of co-workers is high and interest in friends is low. Therefore, it may be bothersome that the display of the friend's status information changes whenever the friend's status information changes. However, since the user's interest in the buddy changes according to the user's situation, it is not realistic to keep the buddy composing the buddy list always match the user's needs.
[0004]
Furthermore, although the user's interest in the buddy changes greatly depending not only on the user's own situation but also on the relationship with the buddy's situation, the relationship between the user's situation and the buddy's situation is The buddy list system reflected on the display has not been provided yet.
An object of the present invention is to provide a technique for realizing display of state information according to a user's situation while suppressing a user's operation load.
[0005]
[Means for Solving the Problems]
In order to solve the above problems, a first invention of the present application is a status display program that causes a computer operated by a user to function,
・ The user refers to the state information State acquisition means for acquiring the latest state information of the desired reference request terminal,
Terminal storage means for storing the reference request terminal and its state information,
· State display means for displaying the latest state information of the reference request terminal stored in the terminal storage means,
A rule storage means for storing in one record an action rule for changing a display form of state information of the reference request terminal, a situation to which the action rule is applied, and a correspondence between the action rule and the situation
Situation detection means for detecting any situation stored in the rule storage means
A rule application unit that changes the display mode of the state information of the reference request terminal displayed by the state display unit according to an action rule corresponding to the detected situation;
And providing a status display program for causing the computer to function.
[0006]
In a status notification system such as a buddy list system or an instant messaging system, display of status information is changed in accordance with the rules stored in the rule storage means. As one example, the buddy list is switched at a fixed time, and only a status update notification from a specific user is displayed for a fixed time.
As a preferred embodiment,
-The terminal storage means stores a terminal group consisting of a plurality of reference request terminals and a reference request terminal constituting the terminal group,
-The rule storage means stores an action rule for switching a current group which is a terminal group displayed by the state display means,
The rule application unit sets one of the terminal groups as a current group in accordance with an action rule according to the detected situation.
The state display means may include a state display program for displaying the state information of the reference request terminal forming the current group.
[0007]
In another preferred embodiment,
Operation detecting means for detecting an operation of changing the current group,
The computer further functions as generation means for generating a new action rule and a situation to which the new action rule is applied based on the operation.
The rule storage means further stores the generated action rule and a situation to which the action rule is applied.
There is a status display program.
[0008]
When the current group is switched by the user's operation, this program automatically generates action rules and their application status candidates from the operation and the result thereof.
In another preferred embodiment,
-The rule storage means is the state display means Displays status information Further including, as the action rule, a filtering rule for restricting a reference desired terminal;
The rule application unit determines whether to display the state information received by the information acquisition unit, based on the filtering rule.
The state display means may include a state display program for displaying the state information when the rule application means determines to display.
[0009]
According to the present invention, it is possible to set a filtering rule for displaying only a part of the received status information update notification instead of displaying the notification. The received buddy state information update notification is selected and displayed by filtering.
As a preferable aspect, a state change notification of converting into information representing a state to which an action rule is applied based on information included in the latest state information of the reference request terminal acquired by the state acquisition means, and notifying the state detection means Making the computer function as an interpretation means,
The status detection means may include a state display program for extracting an action rule to be applied based on the information notified from the state change notification interpretation means.
[0010]
In another preferred embodiment,
-The rule storage means further stores the display form of the state information as an action rule, using the size of the display area for displaying the state information of the reference request terminal as a condition,
-The condition detection means detects a change in a display area for displaying the state information of the reference request terminal,
The rule application unit changes the display mode of the state information of the reference request terminal according to an action rule according to the size of the display area after the change.
There is a status display program.
[0011]
The display mode changes according to the window size for displaying the buddy's state information. For example, if the window is large, it is displayed in alphabetical order, and if it is small, it is displayed in order of reference frequency.
In another preferred embodiment,
-Further including setting receiving means for receiving the setting of the action rule and the situation to which the action rule is applied,
The rule storage means further stores the set action rule and the situation to which the action rule is applied.
There is a status display program.
[0012]
Accept the setting of the action rule from the user and the situation to which the rule is applied.
According to a second aspect of the present invention, there is provided a computer readable recording medium having recorded thereon a status display program operated by a computer operated by a user.
The user refers to the state information A state acquisition step of acquiring the latest state information of a desired reference request terminal;
A terminal storage step of storing the reference request terminal and its state information;
A state display step of displaying the latest state information of the reference request terminal stored in the terminal storage means;
An action rule for changing a display mode of state information of the reference request terminal, a condition storing the action rule, and a rule storing step of storing the action rule and correspondence of the condition in one record;
A situation detection step of detecting any situation stored in the rule storage means;
A rule application step of changing a display mode of the state information of the reference desired terminal displayed by the state display unit according to an action rule corresponding to the detected situation;
A computer readable recording medium recording a status display program for executing the program.
[0013]
Here, examples of the recording medium include a floppy disk which can be read and written by a computer, a hard disk, a semiconductor memory, a CD-ROM, a DVD, a magneto-optical disk (MO) and others.
A third invention of the present application is a state distribution method used for a computer connected via a network with a user terminal including a first user terminal and a second user terminal,
A storage step of storing, in one record, a user identifier for identifying a user terminal, a filtering rule for limiting a delivery destination of state information of the user terminal, and a condition to which the filtering rule is applied;
A receiving step of receiving state information of the first user terminal from the first user terminal;
A filtering step of determining a distribution destination to which the state information is to be distributed among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
A transmitting step of transmitting state information of the first user terminal to the user terminal determined as the distribution destination in the filtering step;
Provide a state delivery method including:
[0014]
This method is used, for example, for the buddy list server of the buddy list system. The filtering rule defines which terminal among the reference user terminals registering the user terminal in the buddy to which state information is to be distributed. When the buddy list server receives the status information update notification from the user terminal, the buddy list server delivers the status information update notification to the reference user terminal satisfying the filtering rule.
As a preferred embodiment of the method,
The storing step includes, in one record, a user identifier of a user terminal, a reverse filtering rule for restricting distribution of state information of another user terminal to the user terminal, and a state of applying the reverse filtering rule In addition,
The filtering step determines a distribution destination to which the state information is distributed, based on the filtering rule of the first user terminal and the inverse filtering rule of the user terminal that refers to the state of the first user terminal.
The state delivery method is mentioned.
[0015]
The reverse filtering rule restricts state information update notification from the buddy's terminal of the user terminal. For example, when the state information of the buddy is updated, the distribution destination of the state information update notification is determined based on the filtering rule of the buddy terminal and the reverse filtering rule of the user terminal.
A fourth invention of the present application is a state distribution program that causes a computer connected via a network to a user terminal including a first user terminal and a second user terminal to function,
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
Providing a state distribution program that causes the computer to function as
[0016]
A fifth invention of the present application is a state distribution device connected via a network to a user terminal including a first user terminal and a second user terminal,
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
To provide a state distribution device.
[0017]
BEST MODE FOR CARRYING OUT THE INVENTION
<Buddy List System>
First, the buddy list system will be described. The buddy list system is an example of a state notification system to which the state display program and the state distribution method of the present invention are applied.
FIG. 1 shows the configuration of the buddy list system. The buddy list system is configured by connecting a buddy list server 2 managing user status information and a plurality of user terminals 1a, 1b and 1c (hereinafter simply referred to as user terminal 1) via a network 3 Be done. The buddy list server 2 and the user terminal 1 can be realized using a computer.
[0018]
The user A who operates the user terminal 1 a (User ID: U 100) registers one or more own state information in the buddy list server 2. The user terminal 1a can also set the disclosure level of the registered state information, for example, the "reference permitted user", for each state information. Here, the reference permitted user is another user other than the user A who permits reference to the state information of the user terminal 1a. The user A also registers in the buddy list server 2 a user group that he / she wants to refer to the status information. This user group is referred to as a buddy list, and each user configuring the user group is referred to as a buddy. The user A can also register a plurality of buddy lists. In the buddy list system requiring a reference permission from the user designated by the buddy to register the buddy in the buddy list, the user A does not have to set the reference permitted user.
[0019]
On the other hand, the user terminal 1a receives an update notification of the state information of the user terminals 1b and 1c operated by the users B and C who are buddies from the buddy list server 2, and updates these displays. The latest state information of the user terminals 1b and 1c updated while the user terminal 1a is not activated is notified from the buddy list server 2 when the user terminal 1a is activated and displayed on the user terminal 1a. .
The buddy list server 2 has a user management DB 21, a status distribution module 22, and a status reception module 23. The state reception module 23 stores the state information notified from the user terminal 1 a in the user management database (DB) 21 in association with the user ID “U001”. The user management DB 21 can store one or more pieces of status information for one user ID. Further, the state acceptance module 23 stores the contents of the reference permitted user and the buddy list notified from the user terminal 1 a in the user management DB 21. Some buddy list systems require a reference permission from the buddy to register the buddy in the buddy list. In such a buddy list system, the user management DB 21 does not have to store a reference permitted user separately from the buddy. When receiving the latest status information of the user terminal 1a, the status distribution module 22 notifies the reference-authorized user of the user terminal 1a of the updated status information. The buddy list server 2 uniquely identifies each user terminal by the user ID.
[0020]
That is, in the buddy list system, the user registers the buddy who is another user who is interested and his / her latest status information. As a result, basically the buddy state is displayed on the user terminal 1 in a list. Further, when the state information of the buddy of the user is changed, the state information of the buddy displayed on the user terminal 1 is automatically updated. By registering the buddy list in the buddy list server 2, the user terminal 1 can easily refer to the state of the user who is concerned.
[0021]
First Embodiment
Next, a first embodiment in which the present invention is applied to the buddy list system shown in FIG. 1 will be described.
[User terminal]
FIG. 2 is a block diagram showing a functional configuration of the user terminal 1. The user terminal 1 has the function of the state display program according to the present invention in addition to the function as a user terminal constituting the buddy list system. The user terminal 1 is connected with input means 4 such as a keyboard and a mouse, and output means 5 such as a display. The user terminal 1 has a buddy list DB 11 (terminal storage means), an action rule DB 12 (rule storage means), and a plurality of modules.
[0022]
FIG. 3 is a conceptual explanatory view of buddy information accumulated in the buddy list DB 11. As shown in FIG. The buddy list DB 11 stores the buddy list (terminal group) of the user (UserID: U100) operating the user terminal 1 and the state information of each buddy (reference request terminal). As this figure shows, the buddy list DB 11 can hold one or more buddy lists. In this example, the buddy information includes the following data (a) to (g).
(A) Buddy list ID: identification data specifying a buddy list.
(B) Buddy list name: The name given to the buddy list by the user. The buddy list name can be set arbitrarily by the user.
(C) Buddy ID: User ID of a buddy who constitutes a buddy list.
(D) Buddy name: The name of the buddy.
(E) Status information: Status information of buddy.
(F) Communication address: Network address of the user terminal operated by the buddy (hereinafter referred to as buddy terminal).
(G) Position information: data indicating the position of the buddy terminal. The position information of the buddy terminal can use GPS coordinates, for example, when the user terminal 1 is a portable computer equipped with GPS.
[0023]
FIG. 4 is a conceptual explanatory view of an example of rule information stored in the action rule DB 12. The rule information includes, in one record, an "action rule" for changing the display method of the buddy's state information, an "application status" indicating a situation where the action rule is applied, and an action ID. In this example, the action rules of action IDs “1”, “2” and “4” are action rules for switching the buddy list displayed on the display or the like. For example, according to the application status of the action ID “2” and the action rule, the buddy list “for work” is displayed between 9 and 17 o'clock. Thereby, the buddy list according to the user's situation can be displayed automatically. Hereinafter, the buddy list to be displayed is referred to as a current list (corresponding to a current group).
[0024]
The action rule of the action ID "3" is an action rule for limiting the notified state information. According to the application status of the action ID "2" and the action rule, the filter "working" is used between 8 and 17 o'clock. This filter specifies that the notification of the update of the status information notified from other than "*@fujitsu.com" is not displayed. This makes it possible to prevent, for example, displaying status information update notifications from people other than work colleagues during work, and getting in the way of work.
[0025]
The application statuses of the action IDs “5” and “6” and the action rules are action rules for changing the display mode of the state information in accordance with the change of the size of the window displaying the state information. In this example, when the window is large, the state information is to be displayed in alphabetical order of buddy names. In addition, when the window is small, the buddies are displayed in descending order of the number of times of reference of the state information.
The application status of the action ID “7” and the action rule are action rules for displaying the state information of the buddy nearby in the current list when there is a buddy nearby. Here, it is judged that the buddy who is within 10 km radius is near. Whether or not the user is near can be determined based on the state information of the user terminal and the buddy terminal. The rule information described above is merely an example for explanation. The application status and the content of the action rule included in the rule information can be appropriately changed according to the needs.
[0026]
[Buddy List Server]
As described above, the buddy list server 2 receives the change of the state information and the buddy list of the user terminal by the state receiving module 23, and distributes the state information by the state distribution module 22 to the user terminal. The state information and the buddy list are stored in the user management DB 21.
FIG. 5 is a conceptual explanatory view of user information stored in the user management DB 21 of the buddy list server 2. The user management DB 21 stores user state information, a buddy list, and the like for each user. In this example, the user information includes data in one record. The user information shown here is user information in the case where it is necessary to permit reference from the buddy in order to register the buddy in the buddy list. Therefore, the user information does not include the reference permitted user. Here, an example in which one piece of state information corresponds to one user terminal is shown.
(A) User ID: An identifier for identifying a user on the buddy list system.
(B) State information: State information of the user terminal specified by the user ID.
(C) Communication address: Network address of the user terminal.
(D) Position information: data indicating the position of the user terminal. Eg GPS coordinates,
(E) Buddy list name: A buddy list name held by the user terminal specified by the user ID.
(F) Buddy ID: User ID of a buddy who constitutes each buddy list.
(G) Buddy name: Name of buddy held by each user terminal.
[0027]
[Flow of processing]
Next, functions of each module of the user terminal 1 and each module of the buddy list server 2 will be described by way of an example. In the following, in order to facilitate the explanation, it is assumed that the buddy list DB 11, the action rule DB 12 and the user management DB 21 are in the states shown in FIGS.
(1) Rule application process
FIG. 6 is a flowchart showing the flow of the rule application process performed by the user terminal 1. In this process, the display of the buddy list is changed according to the detected situation. For example, when the user terminal 1 is powered on, the following processing is started.
[0028]
Step S1: The situation detection module 18 (state detection means) waits for the occurrence of any of the application situations stored in the action rule DB 12. If the occurrence of the application situation is detected, the process goes to step S2. For example, a situation such as "notice of updating buddy state information" or "predetermined time has come" is detected.
Step S2: The rule application module 19 (rule application means) determines whether or not the current list is changed according to the detected application status. In this example, the application status for changing the current list is when the time is 9 o'clock, 17 o'clock or 20 o'clock. If it judges "Yes", it will transfer to step S3. If it judges "No", it will transfer to step S5 mentioned later.
[0029]
Steps S3 and S4: The rule application module 19 refers to the action rule DB 12 and changes the current list in accordance with the action rule according to the situation that has occurred. For example, when the time is 9 o'clock, the state information and the buddy names of the buddy constituting the buddy list “for work” are read out from the buddy list DB 11 and sent out to the buddy list display module 20 (S3). The buddy list display module 20 outputs the state information and the like of the buddy of the new current list "for work" to a display or the like (S4).
[0030]
Step S5: If the situation that has occurred is not the situation for changing the current list, the process proceeds to step S5. The rule application module 19 determines whether the resulting situation is a notification of new state information of the buddy. If it judges "Yes", it will transfer to step S6. If it judges "No", it will transfer to step S9 mentioned later.
Step S6: The rule application module 19 determines whether there is an action rule to apply. If the time is 8 to 17 o'clock, the action rule of the action ID "3" is applied. That is, the rule application module 19 refers to the communication address of the buddy whose state information has been updated, and determines whether or not "*@fujitsu.com". If the determination is "Yes", it is determined that the display is to be updated. If the determination is "No", it is determined that the display is not updated.
[0031]
Step S7: The rule application module 19 proceeds to step S8 when updating the display, and proceeds to step S13 described later when not updating the display.
Step S8: The rule application module 19 sends the updated state information to the buddy list display module 20. Based on this data, the buddy list display module 20 updates the display of the state information of one buddy in the current list.
Step S9: The rule application module 19 proceeds to step S10 when the change of the window size is detected in the step S1. If not, the process proceeds to step S11 described later.
[0032]
Step S10: The rule application module 19 determines an action rule to be applied according to the new window size, and changes the display data of the state information. For example, when the window size is increased, the action rule of the action ID "5" is applied. That is, the rule application module 19 rearranges the buddy in the current list in alphabetical order of the buddy names. The buddy list display module 20 generates display data of the current list in which the buddy is sorted in alphabetical order, and outputs it to a display or the like.
[0033]
Step S11: The rule application module 19 determines whether or not the buddy's position information has been notified from the buddy list server 2 in the step S1. If it judges "Yes", it will transfer to step S12. If it judges "No", it will transfer to step S13 mentioned later.
Step S12: The rule application module 19 inquires the state information interpretation module 110 about the buddy nearby in the current list, determines it, leaves only the relevant buddy, and deletes the others. In this case, the state information interpretation module 110 calculates the distance between the own terminal and the buddy based on the position information of the buddy, and notifies the situation detection module 18 of the distance. The situation detection module 18 extracts a buddy to be a target of the action rule to be applied based on the distance information from the own terminal interpreted by the state information interpretation module 110. The buddy list display module 20 generates display data based on the changed temporary buddy list and outputs the display data to the output means 5. For example, it is assumed that the buddy "Mr. Ozawa" and "Mr. Koizumi" are detected nearby in the current list "for emergency standby". In that case, the rule application module 19 changes the buddy to be displayed to "Mr. Ozawa" and "Mr. Koizumi". The buddy list display module 20 generates display data that displays only the status information of the two persons, and outputs the display data to a display or the like.
[0034]
Step S13: The rule application module 19 determines whether the operation of the user terminal 1 ends. If the determination is "No", the process returns to step S1 and the same process is repeated. If the determination is "Yes", the process ends.
(2) Status notification processing
FIG. 7 is a state notification process performed by the user terminal 1 independently of the rule application process. This process is a process for functioning as a user terminal of the buddy list system. This processing is roughly divided into notification of the own state and the buddy list, and reception and display of the buddy's state information.
[0035]
Step S21: The state notification module 14 determines whether or not its own state information has been changed. If it judges "Yes", it will transfer to step S22. If it judges "No", it will transfer to step S23. The update of the own state information may be detected by the state notification module 14, or the state notification module 14 may receive the setting of new own state information. The own state information that can be detected by the state notification module 14 includes leaving / present by the screen saver operation time, busy / normal by the frequency of keyboard input, going out / moving by referring to a schedule book (not shown), etc. Is mentioned as an example. Of course, the status notification module 14 can also receive input / setting of the status information by the user.
[0036]
Step S22: The state notification module 14 notifies the buddy list server 2 of the new self state information and the user ID. The buddy list server 2 having received this stores the new state information in the user management DB 21 and updates the state information of the user terminal.
Step S23: The state acquisition module 13 (state acquisition means) stands by for the state information update notification from the buddy list server 2, and when it is received, the process proceeds to step S24. The state information update notification includes the buddy's user ID and the buddy's new state information.
[0037]
Step S24: The state acquisition module 13 writes the new state information of the buddy received into the buddy list DB 11, and updates the state information of the buddy.
Step S25: The state notification module 14 waits for the change of the buddy list by the operation of the user, and when the buddy list is changed, the process proceeds to step S26.
Step S26: The state notification module 14 writes a new buddy list into the buddy list DB 11 and updates the buddy information. Updating buddy information includes creating a new buddy list, adding a new buddy to an existing buddy list, and deleting a buddy from an existing buddy list. It also includes buddy list renaming.
[0038]
Step S27: Further, the state notification module 14 notifies the buddy list server 2 of the updated buddy information. This notification also includes the user ID of the user terminal. In response to this notification, the buddy list server 2 writes the new buddy information in the user management DB 21.
Step S28: The state acquisition module 13 and the state notification module 14 end the processing when the power of the user terminal 1 is turned off or the like. Steps S21 to S27 are repeated until the process is completed.
[0039]
(3) Rule creation process
FIG. 8 is a flowchart showing a flow of rule creation processing performed by the user terminal 1. In this process, action rules and their application statuses are created.
Step S31: The operation detection module 16 (operation detection means) detects an operation in which the user changes the current list. For example, at 12 o'clock, it is detected that the current list is changed to the buddy list "private" by the operation of the user.
Step S32: The rule generation module 17 (generation means) generates a new action rule and its application status based on the operation and the change of the current list, and registers it in the action rule DB 12. For example, the application status is generated with a default value preset in the system from time "12:00" when the buddy list is used as the current list, for example, time "13:00" when one hour has elapsed as the end time. Set "current list = buddy list" private "" as the action rule.
[0040]
Step S33: The setting reception module 15 (setting reception means) waits for an instruction to set an action rule, and proceeds to step S34. For example, the setting reception module 15 displays the “action rule setting button” together with the current list, and determines the presence or absence of an instruction depending on whether or not the button is pressed.
Step S34: The setting acceptance module 15 accepts the input of the action rule and its application status from the input means 4, and registers these in the action rule DB 12. For example, the setting receiving module 15 may output a screen for inputting a new action rule and its application status to the output means 5 and may receive an input on the screen.
[0041]
Step S35: The setting acceptance module 15, the operation detection module 16, and the rule generation module 17 end the processing when the power of the user terminal 1 is turned off. Until then, the processing of the steps S31 to S34 is repeatedly executed.
Second Embodiment
FIG. 9 is an overall configuration diagram of a buddy list system according to the second embodiment. In the buddy list system, the user terminal 1 and the buddy list server 2 are connected by the network 3 as in the first embodiment.
[0042]
[Buddy List Server]
The buddy list server 2 further has a function of executing the state distribution method according to the present invention in addition to the function as the buddy list server. Specifically, the buddy list server 2 further includes a filtering rule DB 24, a filtering module 26, and a rule registration module 27 in addition to the user management DB 21, the status distribution module 22, and the status reception module 23. In the figure, elements having the same functions as in the first embodiment are indicated by the same reference numerals. The user management DB 21 stores user information exemplified in FIG.
[0043]
FIG. 10 is a conceptual explanatory view of the filtering information stored in the filtering rule DB 24. As shown in FIG. The filtering information includes, in one record, a “user ID”, a “filtering rule”, and an “application status” to which the filtering rule is applied. One record can store combinations of a plurality of application statuses and filtering rules. For example, the user with the user ID "U100" registers a filter "working" applied from 8:00 to 17:00 and a filter "private" at other times.
[0044]
In this example, the filter includes a transmission filter (inverse filtering rule) for limiting the notification of the user's own state to the reference permitted user and a reception filter for limiting the state update notification (filtering rule) from his / her buddy. There is. In this figure, the filter "working" of the user "U100" is a reception filter for limiting the notification of state update from its own buddy. In addition, the filter “private” is a transmission filter for restricting the notification of the own state information to the reference user who refers to the own state, that is, the other users who have registered the user U 100 in the buddy. The filtering information and the content of the filtering can be appropriately changed according to the needs.
[0045]
[User terminal]
The functional configuration of the user terminal 1 is the same as that of FIG. In the figure, elements having the same functions as in the first embodiment are indicated by the same reference numerals. In the buddy list 11, buddy information illustrated in FIG. 3 is accumulated.
FIG. 11 is a conceptual explanatory view of rule information stored in the action rule DB 12 of the user terminal. As in the first embodiment, in the action rule DB 12, "action ID", "application status" and "action rule" are stored in one record. However, in this example, the filter for limiting the notification of the state information update from the buddy is stored in the buddy list server 2 and therefore is not stored in the action rule DB 12.
[0046]
[Flow of processing]
The functions of each module of the buddy list server 2 and the user terminal 1 will be specifically described below. In the following, it is assumed that the user management DB 21, the filtering rule DB 24, the buddy list DB 11 and the action rule DB 12 are in the states illustrated in FIG. 5, FIG. 10, FIG. 3 and FIG.
FIG. 12 is a flowchart showing the flow of processing performed by the buddy list server 2. In this process, the buddy list server 2 performs filtering of the state information to be distributed, in addition to the reception of the state information of the user terminal and its update and distribution.
[0047]
Step S41: The state reception module 23 stands by for a state update notification from any of the user terminals 1. Now, for ease of explanation, it is assumed that the user U 100 has notified of updating of state information. When the state update notification is received, the process proceeds to step S42.
Step S42: The state receiving module 23 writes the received state information in the user management DB 21 as new state information of the user terminal U100 of the notification source.
Step S43: The filtering module 26 reads from the user management DB 21 all reference users who have registered the notification source user U100 in the buddy. The filtering module 26 then determines whether there are filtering rules applied among the filtering rules of the reference user and the notifying user. For example, if it is a time when no filtering rule of any user is set, it is determined that there is no filtering rule. If there is a filtering rule, the process proceeds to step S44. If not, the process proceeds to step 45 described later.
[0048]
Step S44: The filtering module 26 reads the filtering rules of the reference user and the notification source user U100 from the filtering rule DB 24. Referring to FIG. 3, user U101 has registered user U100 in the buddy. Therefore, the filtering rules of the user U100 and the user U101 are read out.
Step S45: The filtering module 26 determines the distribution destination of the state information based on the read filtering rule. For example, if the time is 10 o'clock, the user U 100 does not restrict notification of self-state information. On the other hand, U101, which is one of the reference users of the user U100, sets a reception filter "working" for receiving only the status update notification from the buddy of the buddy list "for work". Since the notification source user U100 is one of the buddys of the buddy list "for work" of the user U101, one of the delivery destinations is determined to be the user U101. In addition, when there is no filtering rule to apply, the filtering module 26 makes all the reference users a delivery destination.
[0049]
Step S46: The filtering module 26 determines whether or not there is a distribution destination, and if there is, it requests the state distribution module 22 to distribute the state information. This request includes the communication address of the delivery destination user terminal, the status information to be delivered, and the user ID of the user who is the owner of the status information.
Step S47: The state distribution module 22 distributes the requested state information to the requested distribution destination.
If it is determined in step S41 that the notification is not notification of state information, the process proceeds to step S48. In step S48, the state receiving module 23 determines whether the notification is a buddy list update notification. If the determination is "Yes", the process proceeds to step S49, and if the determination is "No", the process returns to the step S41 again.
[0050]
Step S49: The state acceptance module 23 writes the received new buddy list into the user management DB 21.
Step S410: The rule registration module 27 determines whether or not the filtering rule has been received from the user terminal 1, and if “Yes”, the process proceeds to step S411. In the second embodiment, the setting receiving module 15 of the user terminal 1 receives the setting of the filtering rule and the application state thereof, and transmits the received information to the buddy list server 2.
[0051]
Step S411: The rule registration module 27 writes the filtering rule received from the user terminal 1 and the application status thereof to the filtering rule DB 24.
<Screen example>
FIG. 13 is an example of an action rule registration screen displayed by the setting acceptance module 15 of the user terminal 1. This screen receives settings of action rules and their application status.
[0052]
FIG. 14 is a change example of the display of the state information by the rule application module 19 of the user terminal 1. FIG. 14A is an example in which the current list changes with time. This corresponds to the rule information of the action ID "2" in FIG.
FIG. 14B shows an example in which the display order of buddies in the current list changes in accordance with the change in the window size. The left side of the figure shows an example in which the buddy and its state are displayed in alphabetical order when the window size is large. The right side of the figure shows an example in which the buddy and its state information are displayed in order of the number of times of referring to the state information of the buddy when the window size becomes smaller. The number of times of reference can be calculated, for example, by the state acquisition module 13 of the user terminal 1. This window change corresponds to the rule information of the action IDs "5" and "6" of FIG.
[0053]
FIG. 14C is an example in which the display form of the current list changes according to the position information of the buddy terminal. This figure corresponds to the rule information in the action ID "7" of FIG. The left side in the figure is a display example of the state information when there is no buddy nearby. The right side in the figure is a display example of state information when a buddy is detected nearby.
<Other Embodiments>
(A) When generating an action rule and its application status based on a user's operation, rule information may be generated on the condition that the same operation is frequently repeated several times. If the private list is made the current list from 12 o'clock to 13 o'clock on three consecutive days, rule information is generated.
[0054]
(B) A program for executing the above-described method and a computer-readable recording medium recording the program are included in the present invention. Here, examples of the recording medium include a floppy disk which can be read and written by a computer, a hard disk, a semiconductor memory, a CD-ROM, a DVD, a magneto-optical disk (MO) and others.
<Supplementary Note>
(Supplementary Note 1)
A state display program that causes a computer operated by a user to function,
The user refers to the state information State acquisition means for acquiring the latest state information of the desired reference request terminal,
Terminal storage means for storing the reference request terminal and its state information;
State display means for displaying the latest state information of the reference request terminal stored by the terminal storage means;
Rule storage means for storing in one record an action rule for changing the display mode of the state information of the reference request terminal, the situation to which the action rule is applied, and the correspondence between the action rule and the situation
Condition detection means for detecting any of the conditions stored in the rule storage means;
Rule application means for changing the display mode of the state information of the reference request terminal displayed by the state display means according to an action rule corresponding to the detected situation;
A status display program that causes the computer to function.
[0055]
(Supplementary Note 2)
The terminal storage means stores a terminal group consisting of a plurality of reference request terminals and a reference request terminal constituting the terminal group,
The rule storage means stores an action rule for switching a current group which is a terminal group displayed by the state display means,
The rule application unit sets one of the terminal groups as a current group in accordance with an action rule according to the detected situation.
The state display means displays state information of reference request terminals that constitute the current group.
The status display program according to Appendix 1.
[0056]
(Supplementary Note 3)
Operation detecting means for detecting an operation of changing the current group;
Causing the computer to further function as generation means for generating a new action rule and a situation to which the new action rule is applied based on the operation;
The rule storage means further stores the generated action rule and a situation to which the action rule is applied.
The status display program described in Appendix 2.
[0057]
(Supplementary Note 4)
The rule storage means is the state display means Displays status information Further including, as the action rule, a filtering rule for restricting a reference desired terminal;
The rule application unit determines whether to display the state information received by the information acquisition unit, based on the filtering rule.
The state display means displays the state information when the rule application means determines to display.
The status display program according to Appendix 1.
[0058]
(Supplementary Note 5)
Based on the information contained in the latest state information of the reference request terminal acquired by the state acquisition means, it is converted into information representing the situation to which the action rule is applied, and the state change notice interpretation means for notifying the situation detection means Make the computer function more
The situation detection means extracts an action rule to be applied based on the information notified from the state change notice interpretation means.
The status display program described in Appendix 1.
[0059]
(Supplementary Note 6)
The rule storage means further stores the display form of the state information as an action rule, with the size of the display area for displaying the state information of the reference request terminal as a state.
The status detection means detects a change in a display area for displaying status information of the reference request terminal,
The rule application unit changes the display mode of the state information of the reference request terminal according to an action rule according to the size of the display area after the change.
The status display program according to Appendix 1.
[0060]
(Appendix 7)
The system further includes setting receiving means for receiving the setting of the action rule and the situation to which the action rule is applied,
The rule storage means further stores a set action rule and a situation to which the action rule is applied.
The status display program according to Appendix 1.
(Supplementary Note 8)
A computer readable recording medium storing a status display program operating on a computer operated by a user, comprising:
The user refers to the state information A state acquisition step of acquiring the latest state information of a desired reference request terminal;
A terminal storage step of storing the reference request terminal and its state information;
A state display step of displaying the latest state information of the reference request terminal stored in the terminal storage means;
An action rule for changing a display mode of state information of the reference request terminal, a condition storing the action rule, and a rule storing step of storing the action rule and correspondence of the condition in one record;
A situation detection step of detecting any situation stored in the rule storage means;
A rule application step of changing a display mode of the state information of the reference desired terminal displayed by the state display unit according to an action rule corresponding to the detected situation;
A computer readable recording medium recording a status display program for executing.
[0061]
(Appendix 9)
A state distribution method used for a computer connected via a network to a user terminal including a first user terminal and a second user terminal, the network comprising:
Storing, in one record, a user identifier for identifying a user terminal, a filtering rule for limiting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving the status information of the first user terminal from the first user terminal;
A filtering step of determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
A transmitting step of transmitting state information of the first user terminal to the user terminal determined as the distribution destination in the filtering step;
State delivery method including:
[0062]
(Supplementary Note 10)
The storing step further includes, in one record, a user identifier of a user terminal, a reverse filtering rule for restricting distribution of state information of another user terminal to the user terminal, and a state of applying the reverse filtering rule Including
The filtering step determines a distribution destination to which the state information is distributed, based on a filtering rule of the first user terminal and a reverse filtering rule of a user terminal that refers to the state of the first user terminal.
The state delivery method according to appendix 9.
[0063]
(Supplementary Note 11)
A state distribution program that causes a computer connected via a network to a user terminal including a first user terminal and a second user terminal to function,
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
A state delivery program that causes the computer to function.
[0064]
(Supplementary Note 12)
A state distribution device connected via a network to a user terminal including a first user terminal and a second user terminal, the network comprising:
Storage means for storing in one record a user identifier for identifying a user terminal, a filtering rule for restricting a delivery destination of status information of the user terminal, and a condition to which the filtering rule is applied;
Receiving means for receiving state information of the first user terminal from the first user terminal;
Filtering means for determining a delivery destination to which the state information is to be delivered among user terminals that refer to the state information of the first user terminal based on the filtering rule of the first user terminal;
Transmitting means for transmitting state information of the first user terminal to the user terminal determined as the distribution destination by the filtering means;
A state distribution device comprising:
[0065]
【Effect of the invention】
According to the present invention, it is possible to display state information suitable for the state of the user without increasing the operation load of the user.
Brief Description of the Drawings
[Fig. 1]
The whole structural example of the buddy list system which concerns on the example of 1st Embodiment.
[Fig. 2]
Explanatory drawing which shows the function structure of a user terminal.
[Fig. 3]
Conceptual explanatory drawing of the buddy information accumulate | stored in buddy list DB.
[Fig. 4]
Conceptual explanatory drawing of the rule information accumulate | stored in action rule DB.
[Fig. 5]
Conceptual explanatory view of user information accumulated in a user management DB.
[Fig. 6]
The flowchart which shows an example of the flow of a rule application process.
[Fig. 7]
The flowchart which shows an example of the flow of a state notification process.
[Fig. 8]
The flowchart which shows an example of the flow of a rule creation process.
[Fig. 9]
The whole structural example of the buddy list system which concerns on the example of 2nd Embodiment.
[Fig. 10]
Conceptual explanatory drawing of the information accumulate | stored in filtering rule DB.
[Fig. 11]
The concept explanatory drawing of the rule information accumulate | stored in action rule DB of FIG.
[Fig. 12]
The flowchart which shows an example of the flow of the process which a server performs.
[Fig. 13]
Example of action rule registration screen.
[Fig. 14]
Change example of display of status information.
(A) An example in which the current list changes with time.
(B) An example in which the display order of buddies in the current list changes in accordance with a change in window size.
(C) An example in which the display form of the current list changes according to the position information of the buddy terminal.
[Description of the code]
1: User terminal
2: Buddy list server
12: Action rule DB
19: Rule application module