JP4060592B2 - 状態表示プログラム及び記録媒体 - Google Patents
状態表示プログラム及び記録媒体 Download PDFInfo
- Publication number
- JP4060592B2 JP4060592B2 JP2001400575A JP2001400575A JP4060592B2 JP 4060592 B2 JP4060592 B2 JP 4060592B2 JP 2001400575 A JP2001400575 A JP 2001400575A JP 2001400575 A JP2001400575 A JP 2001400575A JP 4060592 B2 JP4060592 B2 JP 4060592B2
- Authority
- JP
- Japan
- Prior art keywords
- rule
- status
- terminal
- display
- user
- 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
【発明の属する技術分野】
本発明は、ネットワークを介してユーザ間で互いに状態を参照することが可能な状態通知システムに関する。
本発明において、状態通知システムとは、複数のユーザ端末と状態通知サーバとがネットワークを介して接続されることにより構成される。このシステムは、ネットワークを介してユーザの最新の状態情報を取得し、これをユーザに対応付けて記憶する。ユーザ端末は、所望のユーザの状態情報を要求し、これを取得することができる。状態情報管理システムの一例としては、会社のオフィスなどでされている行き先表示システムや在席管理システム、バディリストシステムが挙げられる。バディリストシステムでは、ユーザは、参照したいユーザを、バディとしてバディリストに登録する。このバディリストは、状態通知サーバにより管理されている。ユーザ端末は、ユーザのバディの状態情報を取得して一覧表示する。
【0002】
【従来の技術】
近年、MSN MessengerやAOL Instant Messenger、Yahoo Messengerなどのバディリストシステムによるコミュニケーションが、インターネット上で急速に普及している。これらのシステムでは、ユーザがバディリストに登録しているバディの状態情報が表示され、状態情報が変化すると表示が更新される。バディの状態とは、例えばインターネットへの接続状態が「オン」、「在席中」、「多忙」である。さらにシステムによっては、ユーザが、インスタントメッセージやチャットなどのコミュニケーション手段を、バディの状態に応じて選択することができる。バディリストシステムでは、1人のユーザが複数のバディリストを持つこともできる。ユーザは、自分のバディリストの中から表示するいずれかのバディリストを選択することができる。
【0003】
【発明が解決しようとする課題】
しかし、バディの状態情報の表示の変化は、そのバディへの興味が薄れている場面では煩わしく感じられることがある。例えば、仕事仲間をバディとするバディリスト「仕事用」と、友人をバディとするバディリスト「プライベート」とをあるユーザが有するとする。仕事中は仕事仲間の状態に対する関心が高く、友人達への関心は低い。従って、友人達の状態情報が変化する度に、その友人達の状態情報の表示が変化するのは煩わしく感じられる。だからといって、バディに対するユーザの興味はユーザの状況に応じて変化するので、バディリストを構成するバディをユーザのニーズに常に合致させておくことは現実的ではない。
【0004】
さらに、バディに対するユーザの興味は、ユーザ自身の置かれている状況だけでなく、バディの状況との関係によっても大きく変化するが、ユーザの状況とバディの状況との関係をバディの状態情報の表示に反映したバディリストシステムは未だ提供されていない。
本発明は、ユーザの状況に応じた状態情報の表示を、ユーザの操作負担を抑えつつ実現するための技術を提供することを目的とする。
【0005】
【課題を解決するための手段】
前記課題を解決するために、本願第1発明は、ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
・前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
・前記参照希望端末とその状態情報とを記憶する端末記憶手段、
・前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
・前記参照希望端末の一部を表示対象として選択することにより前記表示対象の参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶手段、
・前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、
・検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される表示対象の参照希望端末と、前記表示対象の参照希望端末の状態情報の表示形態を変更させるルール適用手段、として前記コンピュータを機能させ、
・前記ルール記憶手段は、前記表示対象の参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態を特定するための参照希望端末の表示順を変更する変更条件をアクションルールとしてさらに記憶し、
・前記状況検出手段は、前記表示対象の参照希望端末の状態情報を表示する表示領域の変化を検出し、
・前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記表示対象の参照希望端末及び前記表示対象の参照希望端末の状態情報の表示形態を変更する、
状態表示プログラムを提供する。
【0006】
バディリストシステムやインスタントメッセージングシステムなどの状態通知システムにおいて、ルール記憶手段に記憶されたルールに従い、状態情報の表示を変更する。定時になるとバディリストが切り替わる、一定時間の間、特定のユーザからの状態更新通知だけを表示する、などが一例として挙げられる。
好ましい態様として、
・前記端末記憶手段は、複数の参照希望端末からなる端末グループと、前記端末グループを構成する参照希望端末とを記憶し、
・前記ルール記憶手段は、前記状態表示手段で表示される端末グループであるカレントグループを切り替えるためのアクションルールを記憶し、
・前記ルール適用手段は、検出された状況に応じたアクションルールに従い、いずれかの端末グループをカレントグループとし、
・前記状態表示手段は、前記カレントグループを構成する参照希望端末の状態情報を表示する状態表示プログラムが挙げられる。
【0007】
別の好ましい態様として、
・前記カレントグループを変更する操作を検出する操作検出手段、及び
・前記操作に基づき、新規なアクションルール及び前記新規なアクションルールが適用される状況を生成する生成手段、として前記コンピュータをさらに機能させ、
・前記ルール記憶手段は、前記生成されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
状態表示プログラムが挙げられる。
【0008】
このプログラムは、ユーザの操作によりカレントグループが切り替わった場合、操作とその結果とからアクションルールとその適用状況の候補を自動的に生成する。
別の好ましい態様として、
・前記ルール記憶手段は、前記状態表示手段が状態情報を表示する参照希望端末を制限するためのフィルタリングルールを前記アクションルールとしてさらに含み、
・前記ルール適用手段は、前記フィルタリングルールに基づいて、前記情報取得手段で受信した状態情報を表示するか否かを決定し、
・前記状態表示手段は、前記ルール適用手段が表示すると決定した場合、前記状態情報を表示する状態表示プログラムが挙げられる。
【0009】
この発明では、受信する全ての状態情報更新通知を表示するのではなく、その一部だけを表示するためのフィルタリングルールを設定可能である。受信したバディの状態情報更新通知は、フィルタリングにより取捨選択されて表示される。
好ましい態様として、前記状態取得手段により取得した参照希望端末の最新の状態情報に含まれる情報に基づいて、アクションルールを適用する状況を表す情報に変換し、前記状況検出手段に通知する状態変更通知解釈手段として前記コンピュータをさらに機能させ、
前記状況検出手段は、状態変更通知解釈手段から通知された情報に基づいて、適用すべきアクションルールを抽出する状態表示プログラムが挙げられる。
【0010】
別の好ましい態様として、
・前記ルール記憶手段は、前記参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態をアクションルールとしてさらに記憶し、
・前記状況検出手段は、前記参照希望端末の状態情報を表示する表示領域の変化を検出し、
・前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記参照希望端末の状態情報の表示形態を変更する、
状態表示プログラムが挙げられる。
【0011】
バディの状態情報を表示するウインドウサイズに応じて表示形態が変化する。例えばウインドウが大きければアルファベット順に、小さければ参照回数順に表示する。
別の好ましい態様として、
・前記アクションルール及びそのアクションルールが適用される状況の設定を受け付ける設定受付手段をさらに含み、
・前記ルール記憶手段は、設定されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
状態表示プログラムが挙げられる。
【0012】
ユーザからのアクションルール及びそのルールが適用される状況の設定を受け付ける。
本願第2発明は、ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
・前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
・前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
・前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
・前記参照希望端末の一部を表示対象として選択することにより前記表示対象の参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶ステップと、
・前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
・検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される表示対象の参照希望端末と、前記表示対象の参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、を実行し、
・前記ルール記憶ステップは、前記表示対象の参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態を特定するための参照希望端末の表示順を変更する変更条件をアクションルールとしてさらに記憶し、
・前記状況検出ステップは、前記表示対象の参照希望端末の状態情報を表示する表示領域の変化を検出し、
・前記ルール適用ステップは、変化後の表示領域の大きさに応じたアクションルールに従い、前記表示対象の参照希望端末及び前記表示対象の参照希望端末の状態情報の表示形態を変更する、
状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【0013】
ここで、記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、CD-ROM、DVD、光磁気ディスク(MO)、その他のものが挙げられる。
【0014】
【発明の実施の形態】
<バディリストシステム>
まず始めに、バディリストシステムについて説明する。バディリストシステムは、本発明の状態表示プログラムや状態配信方法が適用される状態通知システムの一例である。
【0015】
図1は、バディリストシステムの構成を示す。バディリストシステムは、ユーザの状態情報を管理しているバディリストサーバ2と、複数のユーザ端末1a、1b、1c(以下、単にユーザ端末1という)とが、ネットワーク3を介して接続されて構成される。バディリストサーバ2及びユーザ端末1は、コンピュータを用いて実現可能である。
【0016】
ユーザ端末1a(UserID:U100)を操作するユーザAは、1または複数の自己の状態情報を、バディリストサーバ2に登録する。ユーザ端末1aは、登録した状態情報の公開レベル、例えば「参照許可ユーザ」を、状態情報毎に設定することも可能である。ここで参照許可ユーザとは、ユーザ端末1aの状態情報の参照を許可するユーザA以外の他のユーザである。またユーザAは、自分が状態情報を参照したいユーザグループをバディリストサーバ2に登録する。このユーザグループをバディリストと言い、ユーザグループを構成する各ユーザをバディと言う。ユーザAは、複数のバディリストを登録することもできる。バディをバディリストに登録するために、バディに指定されたユーザから参照許可を要するバディリストシステムでは、ユーザAは参照許可ユーザを設定する必要はない。
【0017】
一方でユーザ端末1aは、バディであるユーザB,Cが操作するユーザ端末1b、1cの状態情報の更新通知をバディリストサーバ2から受信し、これらの表示を更新する。ユーザ端末1aが起動されていない間に更新されたユーザ端末1b、1cの最新の状態情報は、ユーザ端末1aが起動された時点で、バディリストサーバ2から通知され、ユーザ端末1aで表示される。
【0018】
バディリストサーバ2は、ユーザ管理DB21と、状態配信モジュール22と、状態受付モジュール23とを有している。状態受付モジュール23は、ユーザ端末1aから通知される状態情報を、ユーザID「U001」に対応づけてユーザ管理データベース(DB)21に記憶する。ユーザ管理DB21は、1つのユーザIDに対し、1または複数の状態情報を記憶することができる。また状態受付モジュール23は、ユーザ端末1aから通知された参照許可ユーザ及びバディリストの内容を、ユーザ管理DB21に記憶しておく。バディリストシステムによっては、バディリストにバディを登録するためには、バディからの参照許可を要するものもある。このようなバディリストシステムでは、ユーザ管理DB21は、バディとは別に参照許可ユーザを記憶しておく必要はない。状態配信モジュール22は、ユーザ端末1aの最新の状態情報を受け取ると、ユーザ端末1aの参照許可ユーザへ、更新された状態情報を通知する。なお、バディリストサーバ2は、各ユーザ端末をユーザIDにより一義的に識別する。
【0019】
つまり、バディリストシステムでは、ユーザは、関心を持つ他のユーザであるバディと、自己の最新の状態情報とを登録しておく。これにより、基本的にはバディの状態がユーザ端末1上で一覧表示される。また、ユーザのバディの状態情報が変更された場合、ユーザ端末1上で表示されているバディの状態情報が自動的に更新される。ユーザ端末1は、バディリストサーバ2にバディリストを登録しておくことにより、気になるユーザの状態を手軽に参照することが可能となる。
【0020】
<第1実施形態例>
次に、前記図1に示すバディリストシステムに本発明を適用した第1実施形態例について説明する。
[ユーザ端末]
図2は、前記ユーザ端末1の機能構成を示すブロック図である。このユーザ端末1は、バディリストシステムを構成するユーザ端末としての機能に加え、本発明に係る状態表示プログラムの機能を有している。ユーザ端末1には、キーボードやマウスなどの入力手段4と、ディスプレイなどの出力手段5とが接続されている。ユーザ端末1は、バディリストDB11(端末記憶手段)、アクションルールDB12(ルール記憶手段)及び複数のモジュールを有している。
【0021】
図3は、バディリストDB11に蓄積されるバディ情報の概念説明図である。バディリストDB11には、ユーザ端末1を操作するユーザ(UserID:U100)のバディリスト(端末グループ)及び各バディ(参照希望端末)の状態情報が記憶されている。この図が示すように、バディリストDB11は、1または複数のバディリストを保持することができる。この例では、バディ情報は以下の(a)〜(g)のデータを含んでいる。
(a)バディリストID:バディリストを特定する識別データ。
(b)バディリスト名:ユーザがバディリストにつけた名称。バディリスト名はユーザが任意の名称を設定することができる。
(c)バディID:バディリストを構成するバディのユーザID。
(d)バディ名:バディの名称。
(e)状態情報:バディの状態情報。
(f)通信アドレス:バディが操作するユーザ端末(以下、バディ端末という)のネットワークアドレス。
(g)位置情報:バディ端末の位置を示すデータ。バディ端末の位置情報は、例えばユーザ端末1がGPSを搭載した携帯型コンピュータである場合には、GPS座標を用いることができる。
【0022】
図4は、アクションルールDB12に記憶されるルール情報の一例の概念説明図である。ルール情報は、バディの状態情報の表示の仕方を変更するための「アクションルール」と、アクションルールが適用される状況を示す「適用状況」と、アクションIDとを1レコードに含んでいる。この例では、アクションID“1”、“2”及び“4”のアクションルールは、ディスプレイなどに表示されるバディリストを切り換えるためのアクションルールである。例えば、アクションID“2”の適用状況及びアクションルールに従えば、時刻が9〜17時の間は、バディリスト「仕事用」が表示対象となる。これにより、ユーザの状況に応じたバディリストを自動的に表示することができる。以下、表示対象のバディリストをカレントリスト(カレントグループに相当)という。
【0023】
アクションID“3”のアクションルールは、通知される状態情報を制限するためのアクションルールである。アクションID“2”の適用状況及びアクションルールに従えば、時刻が8〜17時の間はフィルタ「working」を用いる。このフィルタは、通信アドレスが「*@fujitsu.com」以外から通知される状態情報の更新通知を表示しないことを規定する。これにより、例えば仕事中に仕事仲間以外からの状態情報更新通知が表示され、仕事の邪魔になるというようなことを防止できる。
【0024】
アクションID“5”及び“6”の適用状況及びアクションルールは、状態情報を表示するウインドウの大きさの変化に対応して状態情報の表示形態を変えるためのアクションルールである。この例では、ウインドウが大きい場合、状態情報をバディ名のアルファベット順に表示することになっている。また、ウインドウが小さい場合、状態情報の参照回数が多い順にバディを表示することになっている。
【0025】
アクションID“7”の適用状況及びアクションルールは、近くにバディがいる場合、カレントリストの中で近くにいるバディの状態情報を表示するためのアクションルールである。ここでは、半径10キロ以内にいるバディを近くにいると判断する。近くにいるか否かは、ユーザ端末及びバディ端末の状態情報に基づいて判断可能である。以上に述べたルール情報は、説明のための一例に過ぎない。ルール情報に含まれる適用状況やアクションルールの内容は、ニーズに応じて適宜変更可能である。
【0026】
[バディリストサーバ]
前述したように、バディリストサーバ2は、状態受付モジュール23によりユーザ端末の状態情報及びバディリストの変更を受け付け、状態配信モジュール22により状態情報をユーザ端末に配信する。状態情報やバディリストは、ユーザ管理DB21に記憶されている。
【0027】
図5は、バディリストサーバ2のユーザ管理DB21に記憶されるユーザ情報の概念説明図である。ユーザ管理DB21には、ユーザごとにユーザの状態情報やバディリストなどが記憶されている。この例では、ユーザ情報は、データを1レコードに含んでいる。なお、ここに示したユーザ情報は、バディリストにバディを登録するために、バディからの参照許可を要する場合のユーザ情報である。従って、ユーザ情報には参照許可ユーザが含まれていない。またここでは、1つのユーザ端末に1つの状態情報が対応する例を示す。
(a)ユーザID:バディリストシステム上でユーザを識別する識別子。
(b)状態情報:ユーザIDで特定されるユーザ端末の状態情報。
(c)通信アドレス:ユーザ端末のネットワークアドレス。
(d)位置情報:ユーザ端末の位置を示すデータ。例えばGPS座標、
(e)バディリスト名:ユーザIDで特定されるユーザ端末が保持するバディリスト名。
(f)バディID:各バディリストを構成するバディのユーザID。
(g)バディ名:各ユーザ端末が保持するバディの名称。
【0028】
[処理の流れ]
次に、ユーザ端末1の各モジュール及びバディリストサーバ2の各モジュールの機能について、例を挙げて説明する。以下では説明を容易にするために、バディリストDB11、アクションルールDB12及びユーザ管理DB21は、前記図3〜図5に示した状態にあると仮定する。
【0029】
(1)ルール適用処理
図6は、ユーザ端末1が行うルール適用処理の流れを示すフローチャートである。この処理では、検知された状況に応じ、バディリストの表示が変更される。例えば、ユーザ端末1の電源が投入されることにより、以下の処理が開始される。
【0030】
ステップS1:状況検出モジュール18(状況検出手段)は、アクションルールDB12に記憶されているいずれかの適用状況の発生を待機し、適用状況の発生が検出されるとステップS2に以降する。例えば、「バディ状態情報の更新通知」、「所定の時刻になった」、などの状況を検出する。
ステップS2:ルール適用モジュール19(ルール適用手段)は、検出された適用状況によりカレントリストが変更されるか否かを判断する。この例では、カレントリストを変更する適用状況とは、時刻が9時になる場合、17時になる場合、または20時になる場合である。“Yes”と判断するとステップS3に移行する。“No”と判断すると、後述するステップS5に移行する。
【0031】
ステップS3、S4:ルール適用モジュール19は、アクションルールDB12を参照し、生じた状況に応じたアクションルールに従ってカレントリストを変更する。例えば、時刻が9時になった場合、バディリスト「仕事用」を構成するバディの状態情報やバディ名をバディリストDB11から読み出し、バディリスト表示モジュール20に送出する(S3)。バディリスト表示モジュール20は、新たなカレントリスト「仕事用」のバディの状態情報などをディスプレイなどに出力する(S4)。
【0032】
ステップS5:発生した状況がカレントリストを変更する状況ではない場合、ステップS5に移行する。ルール適用モジュール19は、生じた状況がバディの新たな状態情報の通知であるか否かを判断する。“Yes”と判断するとステップS6に移行する。“No”と判断すると、後述するステップS9に移行する。
ステップS6:ルール適用モジュール19は、適用するアクションルールがあるか否かを判断する。時刻が8〜17時であれば、アクションID“3”のアクションルールが適用される。すなわち、ルール適用モジュール19は、状態情報が更新されたバディの通信アドレスを参照し、「*@fujitsu.com」か否かを判断する。“Yes”と判断すると、表示を更新すると判断する。“No”と判断すると、表示を更新しないと判断する。
【0033】
ステップS7:ルール適用モジュール19は、表示を更新する場合ステップS8に移行し、表示を更新しない場合には後述するステップS13に移行する。
ステップS8:ルール適用モジュール19は、更新された状態情報をバディリスト表示モジュール20に送出する。バディリスト表示モジュール20は、このデータに基づいてカレントリストのバディの一人の状態情報の表示を更新する。
【0034】
ステップS9:ルール適用モジュール19は、前記ステップS1でウインドウサイズの変更が検出された場合、ステップS10に移行する。そうでない場合には、後述するステップS11に移行する。
ステップS10:ルール適用モジュール19は、新たなウインドウサイズに応じて適用するアクションルールを決定し、状態情報の表示データを変更する。例えばウインドウサイズが大きくなった場合には、アクションID“5”のアクションルールを適用する。すなわち、ルール適用モジュール19は、カレントリストのバディをバディ名のアルファベット順に並べ直す。バディリスト表示モジュール20は、アルファベット順にバディがソートされたカレントリストの表示用データを生成し、ディスプレイなどに出力する。
【0035】
ステップS11:ルール適用モジュール19は、前記ステップS1でバディの位置情報がバディリストサーバ2から通知されたか否かを判断する。“Yes”と判断するとステップS12に移行する。“No”と判断すると後述するステップS13に移行する。
ステップS12:ルール適用モジュール19は、カレントリストの中で近くにいるバディを状態情報解釈モジュール110に問い合わせて判定し、該当するバディだけを残し、他を削除する。この場合、状態情報解釈モジュール110は、バディの位置情報に基づいて自端末とバディとの距離を算出し、状況検出モジュール18に通知する。状況検出モジュール18は、状態情報解釈モジュール110で解釈された自端末からの距離情報に基づいて、適用するアクションルールの対象となるバディを抽出する。バディリスト表示モジュール20は、変更された一時的なバディリストに基づいて表示用データを生成し、出力手段5に出力する。例えば、カレントリスト「緊急時待機用」において、バディ「小沢さん」と「小泉君」とが近くに検出されたとする。その場合、ルール適用モジュール19は、表示対象のバディを「小沢さん」と「小泉君」とに変更する。バディリスト表示モジュール20は、この二人の状態情報だけを表示する表示用データを生成し、ディスプレイなどに出力する。
【0036】
ステップS13:ルール適用モジュール19は、ユーザ端末1の動作が終了するか否かを判断する。“No”と判断すると、前記ステップS1に戻り、同様の処理を繰り返す。“Yes”と判断すると処理を終了する。
(2)状態通知処理
図7は、前記ルール適用処理とは独立にユーザ端末1が行う状態通知処理である。この処理は、バディリストシステムのユーザ端末として機能するための処理である。この処理は、大別して自状態及びバディリストの通知と、バディの状態情報の受信及び表示とを行う。
【0037】
ステップS21:状態通知モジュール14は、自状態情報が変更された否かを判断する。“Yes”と判断するとステップS22に移行する。“No”と判断するとステップS23に移行する。自状態情報の更新は、状態通知モジュール14が検出してもよいし、状態通知モジュール14が新たな自状態情報の設定を受け付けてもよい。状態通知モジュール14が検出可能な自状態情報としては、スクリーンセーバーの動作時間による離席/在席、キーボード入力の頻度による多忙/普通、スケジュール帳(図示せず)の参照による外出中/移動中などが一例として挙げられる。もちろん、これらの状態情報のユーザによる入力・設定を状態通知モジュール14が受け付けることもできる。
【0038】
ステップS22:状態通知モジュール14は、バディリストサーバ2に新たな自状態情報とユーザIDとを通知する。これを受信したバディリストサーバ2は、新たな状態情報をユーザ管理DB21に記憶し、ユーザ端末の状態情報を更新する。
ステップS23:状態取得モジュール13(状態取得手段)はバディリストサーバ2からの状態情報更新通知を待機しており、これを受信するとステップS24に移行する。状態情報更新通知には、バディのユーザIDと、バディの新たな状態情報とが含まれている。
【0039】
ステップS24:状態取得モジュール13は、受信したバディの新たな状態情報をバディリストDB11に書き込み、そのバディの状態情報を更新する。
ステップS25:状態通知モジュール14は、ユーザの操作によるバディリストの変更を待機しており、バディリストが変更されるとステップS26に移行する。
【0040】
ステップS26:状態通知モジュール14は、新たなバディリストをバディリストDB11に書き込み、バディ情報を更新する。バディ情報の更新とは、新たなバディリストの生成、既存のバディリストへの新たなバディの追加、既存のバディリストからのバディの削除などである。また、バディリスト名の変更も含まれる。
【0041】
ステップS27:さらに状態通知モジュール14は、更新したバディ情報を、バディリストサーバ2に通知する。この通知には、ユーザ端末のユーザIDも含まれる。この通知を受け、バディリストサーバ2は、ユーザ管理DB21に新たなバディ情報を書き込む。
ステップS28:状態取得モジュール13及び状態通知モジュール14は、ユーザ端末1の電源がオフにされるなどにより処理を終了する。処理が終了されるまで、前記ステップS21〜S27が繰り返される。
【0042】
(3)ルール作成処理
図8は、ユーザ端末1が行うルール作成処理の流れを示すフローチャートである。この処理では、アクションルール及びその適用状況の作成が行われる。
ステップS31:操作検出モジュール16(操作検出手段)は、ユーザがカレントリストを変更する操作を検出する。例えば12時に、カレントリストがバディリスト「プライベート」にユーザの操作により変更されることを検出する。
【0043】
ステップS32:ルール生成モジュール17(生成手段)は、操作及びカレントリストの変化に基づいて、新しいアクションルールとその適用状況とを生成し、アクションルールDB12に登録する。例えば、バディリストがカレントリストとして用いられた時刻「12:00」からシステムで予め設定されたデフォルト値、例えば1時間が経過した時刻「13:00」を終了時刻として、適用状況を生成する。アクションルールとして、「カレントリスト=バディリスト「プライベート」」を設定する。
【0044】
ステップS33:設定受付モジュール15(設定受付手段)は、アクションルールの設定が指示されるのを待機し、ステップS34に移行する。例えば、設定受付モジュール15は、カレントリストと共に「アクションルール設定ボタン」を表示させ、これを押されたか否かにより指示の有無を判断する。
ステップS34:設定受付モジュール15は、入力手段4からアクションルール及びその適用状況の入力を受け付け、これらをアクションルールDB12に登録する。例えば、設定受付モジュール15は、新しいアクションルールとその適用状況とを入力する画面を出力手段5に出力し、画面上での入力を受け付けてもよい。
【0045】
ステップS35:設定受付モジュール15、操作検出モジュール16及びルール生成モジュール17は、ユーザ端末1の電源がオフになると処理を終了する。それまでは前記ステップS31〜34までの処理を繰り返し実行する。
<第2実施形態例>
図9は、第2実施形態例に係るバディリストシステムの全体構成図である。このバディリストシステムは、前記第1実施形態例と同様に、ユーザ端末1及びバディリストサーバ2がネットワーク3により接続され構成されている。
【0046】
[バディリストサーバ]
バディリストサーバ2は、バディリストサーバとしての機能に加え、本発明に係る状態配信方法を実行する機能をさらに有している。具体的にはバディリストサーバ2は、ユーザ管理DB21、状態配信モジュール22、状態受付モジュール23に加え、フィルタリングルールDB24、フィルタリングモジュール26及びルール登録モジュール27をさらに有している。図中、第1実施形態例と同様の機能を有する要素については、同じ番号を付して示している。ユーザ管理DB21には、前記図5に例示するユーザ情報が蓄積されている。
【0047】
図10は、フィルタリングルールDB24に記憶されるフィルタリング情報の概念説明図である。フィルタリング情報は、「ユーザID」、「フィルタリングルール」、及びフィルタンリングルールが適用される「適用状況」を、1レコードに含んでいる。1レコードには、複数の適用状況とフィルタンリングルールとの組み合わせを記憶することができる。例えば、ユーザID「U100」のユーザは、時刻8時〜17時までに適用されるフィルタ「working」とそれ以外でのフィルタ「private」とを登録している。
【0048】
フィルタは、この例では、ユーザが参照許可ユーザへの自状態の通知を制限する送信フィルタ(逆フィルタリングルール)と、自分のバディからの状態更新通知(フィルタリングルール)を制限するための受信フィルタとがある。この図では、ユーザ「U100」のフィルタ「working」は自分のバディからの状態更新通知を制限するための受信フィルタである。また、フィルタ「private」は、自状態を参照する参照ユーザ、すなわちユーザU100をバディに登録している他のユーザへの自状態情報の通知を制限するための送信フィルタである。フィルタリング情報やフィルタリングの内容は、ニーズに応じて適宜変更可能である。
【0049】
[ユーザ端末]
ユーザ端末1の機能構成は前記図2と同様である。図中、第1実施形態例と同様の機能を有する要素については、同じ番号を付して示している。バディリスト11には、前記図3に例示するバディ情報が蓄積されている。
図11は、ユーザ端末のアクションルールDB12に記憶されるルール情報の概念説明図である。前記第1実施形態例と同様に、アクションルールDB12には、「アクションID」、「適用状況」及び「アクションルール」が1レコードに記憶される。ただしこの例では、バディからの状態情報更新通知を制限するフィルタはバディリストサーバ2に記憶されているので、アクションルールDB12には記憶されていない。
【0050】
[処理の流れ]
以下、バディリストサーバ2及びユーザ端末1の各モジュールの機能について、具体的に説明する。以下において、ユーザ管理DB21、フィルタリングルールDB24、バディリストDB11及びアクションルールDB12は、図5、図10、図3及び図11に例示する状態にあると仮定する。
【0051】
図12は、バディリストサーバ2が行う処理の流れを示すフローチャートである。この処理では、バディリストサーバ2は、ユーザ端末の状態情報の受信とその更新及び配信とに加え、配信する状態情報のフィルタリングを行う。
ステップS41:状態受付モジュール23は、いずれかのユーザ端末1からの状態更新通知を待機している。今、説明を容易にするために、ユーザU100から状態情報の更新通知があったと仮定する。状態更新通知を受信するとステップS42に移行する。
【0052】
ステップS42:状態受付モジュール23は、受信した状態情報を、通知元のユーザ端末U100の新たな状態情報として、ユーザ管理DB21に書き込む。
ステップS43:フィルタリングモジュール26は、通知元ユーザU100をバディに登録している全ての参照ユーザを、ユーザ管理DB21から読み出す。次いでフィルタリングモジュール26は、参照ユーザ及び通知元ユーザのフィルタリングルールの中で適用されるフィルタリングルールがあるか否かを判断する。例えば、どのユーザのフィルタリングルールも設定されていない時刻であれば、フィルタリングルールはないと判断される。フィルタリングルールがある場合、ステップS44に移行する。ない場合、後述するステップ45に移行する。
【0053】
ステップS44:フィルタリングモジュール26は、参照ユーザ及び通知元ユーザU100のフィルタリングルールを、フィルタリングルールDB24から読み出す。図3を参照すれば、ユーザU101は、ユーザU100をバディに登録している。従って、ユーザU100及びユーザU101のフィルタリングルールが読み出される。
ステップS45:フィルタリングモジュール26は、読み出されたフィルタリングルールに基づいて、状態情報の配信先を決定する。例えば、時刻が10時であればユーザU100は自状態情報を通知することについては制限していない。一方、ユーザU100の参照ユーザの1人であるU101は、バディリスト「仕事用」のバディからの状態更新通知のみを受け付ける受信フィルタ「working」を設定している。通知元ユーザU100は、ユーザU101のバディリスト「仕事用」のバディの1人であるから、配信先の1つはユーザU101と決定する。なお、適用すべきフィルタリングルールがない場合、フィルタリングモジュール26は、全ての参照ユーザを配信先とする。
【0054】
ステップS46:フィルタリングモジュール26は、配信先があるか否かを判断し、ある場合には状態配信モジュール22に状態情報の配信を依頼する。この依頼には、配信先ユーザ端末の通信アドレス、配信される状態情報、その状態情報の持ち主であるユーザのユーザIDが含まれている。
ステップS47:状態配信モジュール22は、依頼された状態情報を依頼された配信先に配信する。
【0055】
前記ステップS41で状態情報の通知ではないと判断すると、ステップS48に移行する。ステップS48では、状態受付モジュール23はバディリストの更新通知か否かを判断する。“Yes”と判断するとステップS49に移行し、“No”と判断すると再び前記ステップS41に戻る。
ステップS49:状態受付モジュール23は、受信した新たなバディリストをユーザ管理DB21に書き込む。
【0056】
ステップS410:ルール登録モジュール27は、フィルタリングルールをユーザ端末1から受信したか否かを判断し、“Yes”と判断するとステップS411に移行する。なお、本第2実施形態例においては、ユーザ端末1の設定受付モジュール15は、フィルタリングルール及びその適用状況の設定を受け付け、受け付けた情報をバディリストサーバ2に送信する。
【0057】
ステップS411:ルール登録モジュール27は、ユーザ端末1から受信したフィルタリングルール及びその適用状況を、フィルタリングルールDB24に書き込む。
<画面例>
図13は、ユーザ端末1の設定受付モジュール15が表示するアクションルール登録画面例である。この画面は、アクションルール及びその適用状況の設定を受け付ける。
【0058】
図14は、ユーザ端末1のルール適用モジュール19による状態情報の表示の変化例である。図14(A)は、時間によりカレントリストが変化する例である。これは、前記図4におけるアクションID“2”のルール情報に対応する。
図14(B)は、ウインドウサイズの変化に応じ、カレントリストのバディの表示順が変化する例である。図中左側は、ウインドウサイズが大きい場合に、バディとその状態とがアルファベット順に表示される例を示す。図中右側は、ウインドウサイズが小さくなった場合に、バディとその状態情報とがバディの状態情報の参照回数順に表示される例を示す。なお、参照回数は、例えばユーザ端末1の状態取得モジュール13により算出可能である。このウインドウ変化は、前記図4のアクションID“5”及び“6”のルール情報に対応する。
【0059】
図14(C)は、バディ端末の位置情報に応じ、カレントリストの表示形態が変化する例である。この図は、前記図4のアクションID“7”におけるルール情報に対応する。図中左側は、近くにバディがいない場合の状態情報の表示例である。図中右側は、近くにバディが検出された場合の状態情報の表示例である。
<その他の実施形態例>
(A)ユーザの操作に基づいてアクションルール及びその適用状況を生成する場合、何度か同じ操作が頻繁に繰り返されたことを条件にルール情報を生成しても良い。3日続けて、12時〜13時に、プライベートリストをカレントリストとしたら、ルール情報を生成するなどである。
【0060】
(B)前述した方法を実行するプログラム及びこのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。ここで、記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、CD-ROM、DVD、光磁気ディスク(MO)、その他のものが挙げられる。
<付記>
(付記1)
ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末とその状態情報とを記憶する端末記憶手段、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラム。
【0061】
(付記2)
前記端末記憶手段は、複数の参照希望端末からなる端末グループと、前記端末グループを構成する参照希望端末とを記憶し、
前記ルール記憶手段は、前記状態表示手段で表示される端末グループであるカレントグループを切り替えるためのアクションルールを記憶し、
前記ルール適用手段は、検出された状況に応じたアクションルールに従い、いずれかの端末グループをカレントグループとし、
前記状態表示手段は、前記カレントグループを構成する参照希望端末の状態情報を表示する、
付記1に記載の状態表示プログラム。
【0062】
(付記3)
前記カレントグループを変更する操作を検出する操作検出手段、及び
前記操作に基づき、新規なアクションルール及び前記新規なアクションルールが適用される状況を生成する生成手段、として前記コンピュータをさらに機能させ、
前記ルール記憶手段は、前記生成されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記2に記載の状態表示プログラム。
【0063】
(付記4)
前記ルール記憶手段は、前記状態表示手段が状態情報を表示する参照希望端末を制限するためのフィルタリングルールを前記アクションルールとしてさらに含み、
前記ルール適用手段は、前記フィルタリングルールに基づいて、前記情報取得手段で受信した状態情報を表示するか否かを決定し、
前記状態表示手段は、前記ルール適用手段が表示すると決定した場合、前記状態情報を表示する、
付記1に記載の状態表示プログラム。
【0064】
(付記5)
前記状態取得手段により取得した参照希望端末の最新の状態情報に含まれる情報に基づいて、アクションルールを適用する状況を表す情報に変換し、前記状況検出手段に通知する状態変更通知解釈手段として前記コンピュータをさらに機能させ、
前記状況検出手段は、状態変更通知解釈手段から通知された情報に基づいて、適用すべきアクションルールを抽出する、
付記1に記載委の状態表示プログラム。
【0065】
(付記6)
前記ルール記憶手段は、前記参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態をアクションルールとしてさらに記憶し、
前記状況検出手段は、前記参照希望端末の状態情報を表示する表示領域の変化を検出し、
前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記参照希望端末の状態情報の表示形態を変更する、
付記1に記載の状態表示プログラム。
【0066】
(付記7)
前記アクションルール及びそのアクションルールが適用される状況の設定を受け付ける設定受付手段をさらに含み、
前記ルール記憶手段は、設定されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記1に記載の状態表示プログラム。
【0067】
(付記8)
ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶ステップと、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
【0068】
(付記9)
第1ユーザ端末及び第2ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータに用いられる状態配信方法であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を1レコードに記憶する記憶ステップと、
前記第1ユーザ端末の状態情報を前記第1ユーザ端末から受信する受信ステップと、
前記第1ユーザ端末のフィルタリングルールに基づいて、前記第1ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリングステップと
前記フィルタリングステップで配信先に決定したユーザ端末に、前記第1ユーザ端末の状態情報を送信する送信ステップと、
を含む状態配信方法。
【0069】
(付記10)
前記記憶ステップは、ユーザ端末のユーザ識別子と、前記ユーザ端末へ他のユーザ端末の状態情報の配信を制限するための逆フィルタリングルールと、前記逆フィルタリングルールを適用する状況と、を1レコードにさらに含み、
前記フィルタリングステップは、前記第1ユーザ端末のフィルタリングルールと、前記第1ユーザ端末の状態を参照するユーザ端末の逆フィルタリングルールとに基づいて、前記状態情報を配信する配信先を決定する、
付記9に記載の状態配信方法。
【0070】
(付記11)
第1ユーザ端末及び第2ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータを機能させる状態配信プログラムであって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を1レコードに記憶する記憶手段、
前記第1ユーザ端末の状態情報を前記第1ユーザ端末から受信する受信手段、
前記第1ユーザ端末のフィルタリングルールに基づいて、前記第1ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第1ユーザ端末の状態情報を送信する送信手段、
として前記コンピュータを機能させる状態配信プログラム。
【0071】
(付記12)
第1ユーザ端末及び第2ユーザ端末を含むユーザ端末とネットワークを介して接続される状態配信装置であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を1レコードに記憶する記憶手段、
前記第1ユーザ端末の状態情報を前記第1ユーザ端末から受信する受信手段、
前記第1ユーザ端末のフィルタリングルールに基づいて、前記第1ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第1ユーザ端末の状態情報を送信する送信手段、
を備える状態配信装置。
【0072】
【発明の効果】
本発明を用いれば、ユーザの操作負担を増加させることなく、ユーザの状態に適した状態情報を表示することができる。
【図面の簡単な説明】
【図1】第1実施形態例に係るバディリストシステムの全体構成例。
【図2】ユーザ端末の機能構成を示す説明図。
【図3】バディリストDBに蓄積されるバディ情報の概念説明図。
【図4】アクションルールDBに蓄積されるルール情報の概念説明図。
【図5】ユーザ管理DBに蓄積されるユーザ情報の概念説明図。
【図6】ルール適用処理の流れの一例を示すフローチャート。
【図7】状態通知処理の流れの一例を示すフローチャート。
【図8】ルール作成処理の流れの一例を示すフローチャート。
【図9】第2実施形態例に係るバディリストシステムの全体構成例。
【図10】フィルタリングルールDBに蓄積される情報の概念説明図。
【図11】図9のアクションルールDBに蓄積されるルール情報の概念説明図。
【図12】サーバが行う処理の流れの一例を示すフローチャート。
【図13】アクションルール登録画面例。
【図14】状態情報の表示の変化例。
(A)時間によりカレントリストが変化する例。
(B)ウインドウサイズの変化に応じ、カレントリストのバディの表示順が変化する例。
(C)バディ端末の位置情報に応じ、カレントリストの表示形態が変化する例。
【符号の説明】
1:ユーザ端末
2:バディリストサーバ
12:アクションルールDB
19:ルール適用ジュール
Claims (2)
- ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末とその状態情報とを記憶する端末記憶手段、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
前記参照希望端末の一部を表示対象として選択することにより前記表示対象の参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される表示対象の参照希望端末と、前記表示対象の参照希望端末の状態情報の表示形態を変更させるルール適用手段、として前記コンピュータを機能させ、
前記ルール記憶手段は、前記表示対象の参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態を特定するための参照希望端末の表示順を変更する変更条件をアクションルールとしてさらに記憶し、
前記状況検出手段は、前記表示対象の参照希望端末の状態情報を表示する表示領域の変化を検出し、
前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記表示対象の参照希望端末及び前記表示対象の参照希望端末の状態情報の表示形態を変更する、状態表示プログラム。 - ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の一部を表示対象として選択することにより前記表示対象の参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を1レコードに記憶するルール記憶ステップと、
前記ルール記憶ステップで記憶されているいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される表示対象の参照希望端末と、前記表示対象の参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、を実行し、
前記ルール記憶ステップは、前記表示対象の参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態を特定するための参照希望端末の表示順を変更する変更条件をアクションルールとしてさらに記憶し、
前記状況検出ステップは、前記表示対象の参照希望端末の状態情報を表示する表示領域の変化を検出し、
前記ルール適用ステップは、変化後の表示領域の大きさに応じたアクションルールに従い、前記表示対象の参照希望端末及び前記表示対象の参照希望端末の状態情報の表示形態を変更する、
状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001400575A JP4060592B2 (ja) | 2001-12-28 | 2001-12-28 | 状態表示プログラム及び記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001400575A JP4060592B2 (ja) | 2001-12-28 | 2001-12-28 | 状態表示プログラム及び記録媒体 |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006344437A Division JP4244359B2 (ja) | 2006-12-21 | 2006-12-21 | 状態配信方法、状態配信プログラム及び状態配信装置 |
JP2007160498A Division JP4519886B2 (ja) | 2007-06-18 | 2007-06-18 | 状態表示プログラム、記録媒体及び装置 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2003196243A JP2003196243A (ja) | 2003-07-11 |
JP2003196243A5 JP2003196243A5 (ja) | 2005-05-26 |
JP4060592B2 true JP4060592B2 (ja) | 2008-03-12 |
Family
ID=27605070
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001400575A Expired - Fee Related JP4060592B2 (ja) | 2001-12-28 | 2001-12-28 | 状態表示プログラム及び記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4060592B2 (ja) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4549687B2 (ja) * | 2004-01-29 | 2010-09-22 | 富士通株式会社 | 連携システム及び連携方法 |
JP2005275890A (ja) * | 2004-03-25 | 2005-10-06 | Nec Corp | プレゼンス情報発行装置およびシステムならびにプログラム |
JP4547990B2 (ja) | 2004-05-25 | 2010-09-22 | 富士ゼロックス株式会社 | 情報処理装置、及び情報処理プログラム |
JP4416686B2 (ja) | 2005-04-01 | 2010-02-17 | 株式会社日立製作所 | 状態情報管理システム、状態情報管理サーバ、状態情報管理プログラム |
JP4736945B2 (ja) * | 2006-05-18 | 2011-07-27 | 株式会社日立製作所 | 状態情報管理システム及び状態情報管理サーバ |
KR20080016467A (ko) * | 2006-08-14 | 2008-02-21 | 삼성전자주식회사 | 프레즌스 속성 기반의 프레즌스 통지 시스템 및 방법 |
JP4637192B2 (ja) * | 2008-02-13 | 2011-02-23 | 株式会社コナミデジタルエンタテインメント | 端末装置、ユーザリスト表示方法、および、プログラム |
JP6154773B2 (ja) * | 2014-03-31 | 2017-06-28 | 株式会社日立製作所 | 画面処理システム |
-
2001
- 2001-12-28 JP JP2001400575A patent/JP4060592B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2003196243A (ja) | 2003-07-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2526187C (en) | Presence and geographic location notification | |
JP3927834B2 (ja) | サービス提供システム、方法、プログラム及び記憶媒体 | |
JP3943949B2 (ja) | 電子メール処理システム、方法、プログラム及び記憶媒体 | |
US20060242239A1 (en) | Presence information processing method and computer | |
JP4250366B2 (ja) | 電子メール処理システム、方法、プログラム及び記憶媒体 | |
CN102067163B (zh) | 通信接入控制系统和方法 | |
WO2002075549A1 (fr) | Systeme de synchronisation de donnees, dispositif utilise avec le systeme, et procede de synchronisation de donnees | |
KR100396204B1 (ko) | 이메일 작성시 수신자의 이메일 주소 입력방법 및 이를구현할 수 있는 프로그램이 수록된 컴퓨터로 읽을 수 있는기록매체 | |
JP4060592B2 (ja) | 状態表示プログラム及び記録媒体 | |
JP2002157198A (ja) | ファイル管理装置、ファイル管理方法およびファイル管理プログラムを記録したコンピュータ読取可能な記録媒体 | |
JP4871085B2 (ja) | 位置情報提供システム | |
JP2004355427A (ja) | 電子メールシステム、端末装置、ソフトウェア及び電子メール共有方法 | |
US20030018722A1 (en) | Method of managing an update of a changed electronic mail address | |
US20090163177A1 (en) | Guest Communication and Information Delivery User Interface | |
JP2003196243A5 (ja) | ||
JP4046534B2 (ja) | プレゼンス管理方法及びプレゼンス設定方法 | |
JP3764738B2 (ja) | メール管理システム、装置及び方法、並びにプログラム及び記録媒体 | |
JP4244359B2 (ja) | 状態配信方法、状態配信プログラム及び状態配信装置 | |
JP2003256684A (ja) | 社会福祉活動の仲介方法及びその支援方法 | |
JP2008504632A (ja) | メッセージ送受信および掲示システム、送受信および掲示方法、並びに、その方法を具現するプログラムを記録したコンピュータで読出可能な保存媒体 | |
JP4519886B2 (ja) | 状態表示プログラム、記録媒体及び装置 | |
JP4288410B2 (ja) | プレゼンスシステム、プレゼンスサーバおよびプログラム | |
JP6931335B2 (ja) | 情報通知システム、情報通知方法、及びプログラム | |
JP2004310435A (ja) | コンテンツ閲覧管理装置 | |
JP2022032901A (ja) | マッチング支援方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040728 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040728 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061024 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061221 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070417 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070618 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070622 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071030 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071119 |
|
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: 20071218 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071220 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101228 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4060592 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111228 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111228 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121228 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121228 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131228 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |