(57)【特許請求の範囲】
【請求項１】
ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末と当該参照希望端末の状態情報と、複数の参照希望端末からなる1乃至複数の端末グループと、前記端末グループを構成する参照希望端末とを記憶する端末記憶手段、
前記端末記憶手段で記憶された端末グループのうち表示対象とされている端末グループであるカレントグループを構成する参照希望端末の最新の状態情報を表示する状態表示手段、
前記カレントグループを変更するためのアクションルールと、前記アクションルールを適用する状況と、を対応付けて記憶部に記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記カレントグループを変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラム。
【請求項２】
ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末と当該参照希望端末の状態情報と、複数の参照希望端末からなる1乃至複数の端末グループと、前記端末グループを構成する参照希望端末とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された端末グループのうち表示対象とされている端末グループであるカレントグループを構成する参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記カレントグループを変更するためのアクションルールと、前記アクションルールを適用する状況と、を対応付けて記憶部に記憶するルール記憶ステップと、
前記ルール記憶ステップで記憶されているいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記カレントグループを変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項３】
ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段と、
前記参照希望端末と当該参照希望端末の状態情報と、複数の参照希望端末からなる1乃至複数の端末グループと、前記端末グループを構成する参照希望端末とを記憶する端末記憶手段と、
前記端末記憶手段で記憶された端末グループのうち表示対象とされている端末グループであるカレントグループを構成する参照希望端末の最新の状態情報を表示する状態表示手段と、
前記カレントグループを変更するためのアクションルールと、前記アクションルールを適用する状況と、を対応付けて記憶部に記憶するルール記憶手段と、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段と、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記カレントグループを変更させるルール適用手段と、
を有する状態表示装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してユーザ間で互いに状態を参照することが可能な状態通知システムに関する。
本発明において、状態通知システムとは、複数のユーザ端末と状態通知サーバとがネットワークを介して接続されることにより構成される。このシステムは、ネットワークを介してユーザの最新の状態情報を取得し、これをユーザに対応付けて記憶する。ユーザ端末は、所望のユーザの状態情報を要求し、これを取得することができる。状態情報管理システムの一例としては、会社のオフィスなどでされている行き先表示システムや在席管理システム、バディリストシステムが挙げられる。バディリストシステムでは、ユーザは、参照したいユーザを、バディとしてバディリストに登録する。このバディリストは、状態通知サーバにより管理されている。ユーザ端末は、ユーザのバディの状態情報を取得して一覧表示する。
【背景技術】
【０００２】
近年、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、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
＜付記＞
（付記１）
ユーザが操作するコンピュータを機能させる状態表示プログラムであって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得手段、
前記参照希望端末とその状態情報とを記憶する端末記憶手段、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示手段、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶手段、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出手段、及び、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用手段、
として前記コンピュータを機能させる状態表示プログラム。
【００６０】
（付記２）
前記端末記憶手段は、複数の参照希望端末からなる端末グループと、前記端末グループを構成する参照希望端末とを記憶し、
前記ルール記憶手段は、前記状態表示手段で表示される端末グループであるカレントグループを切り替えるためのアクションルールを記憶し、
前記ルール適用手段は、検出された状況に応じたアクションルールに従い、いずれかの端末グループをカレントグループとし、
前記状態表示手段は、前記カレントグループを構成する参照希望端末の状態情報を表示する、
付記１に記載の状態表示プログラム。
【００６１】
（付記３）
前記カレントグループを変更する操作を検出する操作検出手段、及び
前記操作に基づき、新規なアクションルール及び前記新規なアクションルールが適用される状況を生成する生成手段、として前記コンピュータをさらに機能させ、
前記ルール記憶手段は、前記生成されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記２に記載の状態表示プログラム。
【００６２】
（付記４）
前記ルール記憶手段は、前記状態表示手段が状態情報を表示する参照希望端末を制限するためのフィルタリングルールを前記アクションルールとしてさらに含み、
前記ルール適用手段は、前記フィルタリングルールに基づいて、前記情報取得手段で受信した状態情報を表示するか否かを決定し、
前記状態表示手段は、前記ルール適用手段が表示すると決定した場合、前記状態情報を表示する、
付記１に記載の状態表示プログラム。
【００６３】
（付記５）
前記状態取得手段により取得した参照希望端末の最新の状態情報に含まれる情報に基づいて、アクションルールを適用する状況を表す情報に変換し、前記状況検出手段に通知する状態変更通知解釈手段として前記コンピュータをさらに機能させ、
前記状況検出手段は、状態変更通知解釈手段から通知された情報に基づいて、適用すべきアクションルールを抽出する、
付記１に記載委の状態表示プログラム。
【００６４】
（付記６）
前記ルール記憶手段は、前記参照希望端末の状態情報を表示する表示領域の大きさを状況として、前記状態情報の表示形態をアクションルールとしてさらに記憶し、
前記状況検出手段は、前記参照希望端末の状態情報を表示する表示領域の変化を検出し、
前記ルール適用手段は、変化後の表示領域の大きさに応じたアクションルールに従い、前記参照希望端末の状態情報の表示形態を変更する、
付記１に記載の状態表示プログラム。
【００６５】
（付記７）
前記アクションルール及びそのアクションルールが適用される状況の設定を受け付ける設定受付手段をさらに含み、
前記ルール記憶手段は、設定されたアクションルール及びそのアクションルールが適用される状況をさらに記憶する、
付記１に記載の状態表示プログラム。
【００６６】
（付記８）
ユーザが操作するコンピュータで動作する状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記ユーザが状態情報の参照を希望する参照希望端末の、最新の状態情報を取得する状態取得ステップと、
前記参照希望端末とその状態情報とを記憶する端末記憶ステップと、
前記端末記憶手段で記憶された参照希望端末の最新の状態情報を表示する状態表示ステップと、
前記参照希望端末の状態情報の表示形態を変更するためのアクションルールと、前記アクションルールを適用する状況と、前記アクションルール及び前記状況の対応と、を１レコードに記憶するルール記憶ステップと、
前記ルール記憶手段で記憶されたいずれかの状況を検出する状況検出ステップと、
検出された状況に応じたアクションルールに従い、前記状態表示手段で表示される前記参照希望端末の状態情報の表示形態を変更させるルール適用ステップと、
を実行するための状態表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
【００６７】
（付記９）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータに用いられる状態配信方法であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶ステップと、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信ステップと、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリングステップと
前記フィルタリングステップで配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信ステップと、
を含む状態配信方法。
【００６８】
（付記１０）
前記記憶ステップは、ユーザ端末のユーザ識別子と、前記ユーザ端末へ他のユーザ端末の状態情報の配信を制限するための逆フィルタリングルールと、前記逆フィルタリングルールを適用する状況と、を１レコードにさらに含み、
前記フィルタリングステップは、前記第１ユーザ端末のフィルタリングルールと、前記第１ユーザ端末の状態を参照するユーザ端末の逆フィルタリングルールとに基づいて、前記状態情報を配信する配信先を決定する、
付記９に記載の状態配信方法。
【００６９】
（付記１１）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続されるコンピュータを機能させる状態配信プログラムであって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
として前記コンピュータを機能させる状態配信プログラム。
【００７０】
（付記１２）
第１ユーザ端末及び第２ユーザ端末を含むユーザ端末とネットワークを介して接続される状態配信装置であって、
ユーザ端末を識別するユーザ識別子と、前記ユーザ端末の状態情報の配信先を制限するためのフィルタリングルールと、前記フィルタリングルールが適用される状況と、を１レコードに記憶する記憶手段、
前記第１ユーザ端末の状態情報を前記第１ユーザ端末から受信する受信手段、
前記第１ユーザ端末のフィルタリングルールに基づいて、前記第１ユーザ端末の状態情報を参照するユーザ端末のうち、前記状態情報を配信する配信先を決定するフィルタリング手段、及び
前記フィルタリング手段で配信先に決定したユーザ端末に、前記第１ユーザ端末の状態情報を送信する送信手段、
を備える状態配信装置。
【産業上の利用可能性】
【００７１】
本発明は、ネットワークを介してユーザ間で互いに状態を参照することが可能な状態通知システムに適用可能である。
【図面の簡単な説明】
【００７２】
【図１】第１実施形態例に係るバディリストシステムの全体構成例。
【図２】ユーザ端末の機能構成を示す説明図。
【図３】バディリストＤＢに蓄積されるバディ情報の概念説明図。
【図４】アクションルールＤＢに蓄積されるルール情報の概念説明図。
【図５】ユーザ管理ＤＢに蓄積されるユーザ情報の概念説明図。
【図６】ルール適用処理の流れの一例を示すフローチャート。
【図７】状態通知処理の流れの一例を示すフローチャート。
【図８】ルール作成処理の流れの一例を示すフローチャート。
【図９】第２実施形態例に係るバディリストシステムの全体構成例。
【図１０】フィルタリングルールＤＢに蓄積される情報の概念説明図。
【図１１】図９のアクションルールＤＢに蓄積されるルール情報の概念説明図。
【図１２】サーバが行う処理の流れの一例を示すフローチャート。
【図１３】アクションルール登録画面例。
【図１４】状態情報の表示の変化例。（Ａ）時間によりカレントリストが変化する例。（Ｂ）ウインドウサイズの変化に応じ、カレントリストのバディの表示順が変化する例。（Ｃ）バディ端末の位置情報に応じ、カレントリストの表示形態が変化する例。
【符号の説明】
【００７３】
１：ユーザ端末
２：バディリストサーバ
１２：アクションルールＤＢ
１９：ルール適用ジュール
【図１】
0004519886.tif 000002
【図２】
0004519886.tif 000003
【図３】
0004519886.tif 000004
【図４】
0004519886.tif 000005
【図５】
0004519886.tif 000006
【図６】
0004519886.tif 000007
【図７】
0004519886.tif 000008
【図８】
0004519886.tif 000009
【図９】
0004519886.tif 000010
【図１０】
0004519886.tif 000011
【図１１】
0004519886.tif 000012
【図１２】
0004519886.tif 000013
【図１３】
0004519886.tif 000014
【図１４】
0004519886.tif 000015