JP2007179566A - 状態変化通知方法及び状態変化通知システム - Google Patents

Abstract

【課題】状態変化をリアルタイムに通知し、情報を共有しているとの認識を持つことを可能にする。
【解決手段】チャネルに参加して同時に会話可能な情報端末群への通知を想定する。チャネルの外部に設けられたＤＢと、ＤＢの状態変化を監視し、状態変化が発生した場合、状態変化を知らせる通知を発行する監視手段１とを備える。情報端末群の少なくとも１つに、監視手段１から状態変化の通知を受け取り、他の情報端末群に状態変化を同報的に通知するために通知をチャネルに送出する通知手段３を設ける。
【選択図】図２

Description

本発明は、コンピュータネットワークを介して接続されている複数の利用者間のコミュニケーションを活発化、円滑化する技術に関する。
本発明において、チャットシステムとは、チャットサーバとチャットクライアントとから構成され、複数のチャットクライアントが互いに同一のネットワーク、すなわち仮想空間を共有して同時に双方向通信可能なシステムを言う。チャネルとは、複数の利用者により共有され、会話が行われるネットワークもしくは仮想空間を意味する。

また、メーリングリストシステムとは、所定の電子メールアドレス群へ電子メールを同報的に配送するシステムを言う。このシステムは、電子メールアドレス群のリストと、電子メールアドレス群を代表する電子メールアドレスとを管理する。代表メールアドレスは、前記電子メールアドレス群への転送を行うための特別なアドレスである。代表メールアドレスへ配送された電子メールは、リスト上の個別の電子メールアドレスへ配送される。以下、代表メールアドレスを単にメーリングリストという。

ネットワークの外部における状態変化とは、例えばチャットシステムにおいては、チャネル内での発言の発生、チャネルへの参加や離脱、チャネルの特性の変化などチャネルに関する状態変化以外の状態変化を言う。このような状態変化としては、例えば、外部データベースへの情報の登録、削除及び更新、メーリングリストへのメールの投稿が挙げられる。

データベースとは、情報が蓄積された資源を広く意味する。例えば、ＷＷＷ(World Wide Web)上のホームページもデータベースに含まれる。

近年、チャットシステムや電子メール等、コンピュータネットワーク上のコミュニケーションシステムが急速に普及している。これに従い、これらのコミュニケーションシステムにおける利用者同士のコミュニケーションをより活発化し、円滑化するための様々な手段が考案されている。
例えば、チャットから外部データベースを呼び出せるようにした技術が提供されている。また、本発明者らは、特許文献１において、チャットシステムから外部データベースへの登録や検索を行う技術を提供している。これらの技術においては、誰がどんな文脈でＤＢにアクセスしたかがリアルタイムで判り、チャットを通じた情報の共有が促進される。

また、電子メールシステム上のコミュニケーションを促進させる技術として、特許文献２には、データベースの状態変化を電子メールで通知する技術が開示されている。
特開２０００−７６１７１号公報 米国特許５，５４８，７５３号明細書

前記特許文献１の技術に従えば、チャットに参加しているユーザがデータベースの検索やデータベースの情報の登録を行った場合、同じチャネル内の他のユーザに対し検索結果やデータベースの変更が通知される。しかし、データベースの管理者等、チャネルに参加していないユーザが、データベースへ情報の登録や削除、更新等を行った場合、データベースの状態が変化したことをすぐに知ることができないという問題点がある。

一方、前記特許文献２においては、データベースの状態変化が電子メールによってユーザに通知される。そのため、実際にデータベースの状態変化が生じてからユーザが通知された電子メールを読むまでの間に時間的な遅れが生じ、ユーザが適切な対応をすることができない場合がある。また、ユーザ同士は、自分が通知された情報を他のユーザが知っているか否かを判らず、情報を共有しているという認識にたってコミュニケーションをすることが難しい。

本発明は、外部状態が変化したことをユーザにリアルタイムに通知し、かつユーザが互いに情報を共通しているとの認識の上にたったコミュニケーションを可能にする技術を提供することを目的とする。

前記課題を解決するために、本願第１発明は、互いに同一の仮想空間を共有して同時に双方向通信可能な情報端末に設けられ、情報が蓄積され前記仮想空間の外部に設けられたデータベースの状態変化を知らせる所定形式の通知を、前記仮想空間内の通信データから抽出し、視覚的に出力する状態変化表示装置を提供する。
例えば、表示手段は、チャネル内の会話が表示されているウインドウとは別のウインドウを画面上に表示する。そして、通知手段からの所定の形式の通知を、チャネル内における通常の会話から抽出し、前記ウインドウに表示する。表示形式は、文字でもよいし、アイコンなど視覚的な表示形式でも良い。

本願第２発明は、互いに同一の仮想空間を共有して同時に双方向通信可能な情報端末に用いられる、状態変化表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
Ａ；情報が蓄積され、前記仮想空間の外部に設けられたデータベースの状態変化を知らせる所定形式の前記通知を、前記仮想空間内の通信データから抽出する段階と、
Ｂ；前記抽出された通知を視覚的に出力する段階と、
を実行するための状態変化表示プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。

前記第１発明と同様の作用効果を有する。
本願第３発明は、同一の仮想空間を共有して同時に双方向通信可能な情報端末群宛の電子メールを、それぞれの情報端末に配送可能な電子メール配送装置に用いられるメール通知装置であって、
・前記情報端末群に含まれ、いずれかの前記情報端末群宛に配送される電子メールを検知し、前記電子メールの宛先を特定する検知手段と、
・前記情報端末群と前記仮想空間とを対応付けるテーブルと、
・前記テーブルに基づいて、前記配送される電子メールの宛先の情報端末群に対応する仮想空間を決定する決定手段と、
・前記決定した仮想空間に対し、前記電子メールが投稿されたことを知らせる通知を送出する通知手段と、
を備えるメール通知装置を提供する。

例えば、あるメーリングリスト宛に電子メールが投稿される。検知手段はメーリングリストに含まれているので、電子メールの投稿を検知し、メーリングリストを特定する。決定手段は、そのメーリングリストと対応付けられたチャネル＃ＣＨ１を特定する。通知手段は、特定したチャネル＃ＣＨ１に対し、電子メールの投稿通知を送出する。メーリングリストに含まれる情報端末は、チャネル＃ＣＨ１に参加していれば、電子メールの投稿があったことをリアルタイムに知ることができる。

なお、複数の利用者端末群が同一のネットワークを共有して同時に双方向通信可能な通信システムに用いられる状態変化通知方法であって、
Ａ；前記ネットワークの外部における状態変化の発生を検知し、
Ｂ；前記状態変化を、前記ネットワークを介して前記利用者端末群に同報的に通知する、
状態変化通知方法も考えられる。

前記通信システムとしては、例えば利用者がチャネル内で会話するチャットシステムが挙げられる。ネットワークの外部における状態変化とは、チャネルに関する状態変化以外の状態変化を言う。例えば、外部ＤＢやＷＷＷ上のホームページの更新、メーリングリストへの電子メールの投稿である。状態変化として、ニュース速報のホームページに新しいニュースが掲載された場合を例に取る。ホームページの更新が検知されると、あるチャネル＃ＣＨ１に対し、ホームページの変化がテキストメッセージで発言される。この発言により、チャネル＃ＣＨ１の参加者は、同時に情報を取得し、かつ他の参加者がその情報を知っているという認識の上に立って会話をすることができる。ホームページは、予め所定のチャネル＃ＣＨ１と対応付けておくとよい。

また、同一のネットワークを共有して同時に双方向通信可能な情報端末群への状態変化通知システムであって、前記ネットワークの外部における状態変化を監視し、前記状態変化が発生した場合は前記状態変化を知らせる通知を発行する監視手段を備えた状態変化通知システムも考えられる。このシステムにおいては、前記情報端末の少なくとも１つは、前記監視手段から前記状態変化の通知を受け取り、他の前記情報端末群に前記状態変化を同報的に通知するために前記通知を前記ネットワークに送出する通知手段を有している。

前記提案の状態変化通知方法と同様の作用効果を有する。
また、同一のネットワークを共有して同時に双方向通信可能な情報端末群への状態変化通知システムであって、蓄積手段と、監視手段とを備える状態変化通知システムも考えられる。
蓄積手段は、前記ネットワークの外部に設けられ、情報が蓄積されている。監視手段は、前記蓄積手段の状態変化を監視し、前記状態変化が発生した場合、前記状態変化を知らせる通知を発行する。前記情報端末群の少なくとも１つは、前記監視手段から前記状態変化の通知を受け取り、他の前記情報端末群に前記状態変化を同報的に通知するために前記通知を前記ネットワークに送出する通知手段を有している。

例えば、チャットシステム上の複数の情報端末がチャットクライアントによりチャネル＃ＣＨ１に参加しているとする。監視手段は、外部のＤＢへの情報の登録や削除、更新を監視している。ＤＢに生じた状態変化は、監視手段により通知手段に通知される。通知手段は、チャットクライアントにより、ＤＢの状態変化通知をチャネル＃ＣＨ１に発言する。この発言により、チャネル＃ＣＨ１に参加している他の情報端末に、ＤＢの状態変化が同報的に通知される。

また、前記状態変化通知システムにおいて、前記監視手段が、前記蓄積手段と前記監視手段と前記通知手段とが対応付けられた第１対応テーブルをさらに備え、前記第１対応テーブルに基づいて前記状態変化の発生を通知する通知手段を決定する状態変化通知システムも考えられる。
例えば、ＤＢ、監視手段及び通知手段が複数ある場合を考える。監視手段は、監視しているＤＢの状態変化を１つの通知手段に通知しても良いし、複数の通知手段に通知することもできる。逆に、通知手段は、複数の監視手段からの通知を受け取ることもできる。監視手段が監視するＤＢは、１つでも複数でも良い。ＤＢ、監視手段及び通知手段の対応付けをニーズに応じて変化させることにより、柔軟なシステムを構築することができる。

また、前記システムにおいて、前記通知手段は、前記ネットワークと前記通知手段とを対応付ける第２対応テーブルをさらに備え、前記第２対応テーブルに基づいて前記通知を送出するネットワークを決定する状態変化通知システムも考えられる。
例えば、ネットワークが複数ある場合、１つの通知手段と複数のネットワークとを対応付け、１つの通知手段から複数のネットワークに通知を送出する。また、１つのネットワークに対し、複数の通知手段から通知を送出してもよい。

また、前記システムにおいて、前記通知手段は、前記状態変化通知を前記ネットワークに送出するタイミングを、所定の条件に基づいて管理する、状態変化通知システムも考えられる。
ニーズに応じて送出のタイミングを制御する。例えば、”過去３分間チャネル内での発言がない場合に通知を行う”、”時刻が9:00〜17:00の範囲において通知を行う”、”通知に含まれる時刻情報に基づいて通知を行う”などである。

また、前記システムにおいて、前記通知手段が、保持手段と、管理手段と、送出手段とを有する状態変化通知システムも考えられる。
保持手段は、前記監視手段からの状態変化通知を保持するためのものである。管理手段は、所定の条件に基づいて前記通知を送出するタイミングを決定し、前記決定に従って前記通知の送出を指示する。送出手段は、前記管理手段からの指示に基づいて、前記保持手段内の状態変化通知を前記ネットワークに送出する。

例えば、過去３分間チャネル内での発言がない場合に通知を送出すると仮定する。監視手段からの通知は、保持手段に一時的に蓄積される。管理手段は、チャネル内の発言状況を参照し、発言しても良いと判断すると送出手段に送出を指示する。送出手段は、決定手段からの指示に基づいて、保持手段内の最も古い通知をネットワークに送出する。
また、前記システムにおいて、前記管理手段は、前記ネットワークの状態に基づいて前記状態変化通知を送出するタイミングを決定する状態変化通知システムも考えられる。

例えば、管理手段は、チャネル内で発言が頻繁に行われている場合ではなく、発言がとぎれたときを通知タイミングに決定する。
また、前記システムにおいて、前記管理手段は、前記監視手段からの状態変化通知に時刻情報が含まれている場合、前記時刻情報に基づいて前記状態変化通知を送出するタイミングを決定する状態変化通知システムも考えられる。

例えば、ＷＷＷ上のホームページに１月８日に、１月２９日公開の新製品の紹介情報が登録された場合を考える。この場合、管理手段は、送出のタイミングを１月２９日に設定する。もちろん、チャネルの状態と通知内容との両方に基づいて、タイミングを決定することも可能である。
また、前記通知手段は、前記監視手段からの状態変化通知を所定の形式に変換する変換手段をさらに備える状態変化通知システムも考えられる。

例えば、変換手段により、監視手段からの状態変化通知を利用者にとって見やすい形式に変換する。また、監視手段と通知手段との通信プロトコルと、通知手段と利用者端末との通信プロトコルとが異なる場合も、変換が必要である。さらに、チャネル内での通常の会話と区別可能にするために、所定の形式に変換することも考えられる。
また、前記通知手段は、前記監視手段からの状態変化通知を所定の形式に変換する変換手段をさらに備え、前記ネットワークを介して前記通知を受け取る前記情報端末は、前記形式に変換された通知を、前記ネットワーク内の通信データから抽出して表示する表示手段をさらに有する状態変化通知システムも考えられる。

例えば、表示手段は、チャネル内の会話が表示されているウインドウとは別のウインドウを画面上に表示する。そして、通知手段からの所定の形式の通知を、チャネル内における通常の会話から抽出し、前記ウインドウに表示する。表示形式は、文字でもよいし、アイコンなど視覚的な表示形式でも良い。
また、前記蓄積手段は、電子メールを保管するメールＤＢであり、前記監視手段は予め定められた宛先へ送信される電子メールが投稿されたことを前記通知手段に通知し、前記通知手段は、前記情報端末群が共有するネットワークに前記電子メールの投稿通知を送出する状態変化通知システムが考えられる。

メーリングリストへの電子メールの投稿がＤＢに蓄積される場合、メーリングリストに記載された利用者に対し、チャットでメールの投稿が通知される。
また、前記情報端末は、前記通知手段に加え、所定の情報端末群のリストと電子メールを配送可能な電子メール配送装置とをさらに備え、前記通知手段は、メール先決定手段とメール送出手段とをさらに有する状態変化通知システムが考えられる。

メール先決定手段は、前記状態変化通知を送出したネットワークを共有している情報端末と前記リストとに基づいて、前記電子メール配送装置による通知先を決定する。メール送出手段は、前記決定された通知先に対し前記電子メール装置を用いて前記通知を送出する。
例えば、チャネルに参加している情報端末には、チャットによりリアルタイムに状態変化が通知される。チャネルに参加していない情報端末には、電子メールにより所定のデータベースの状態変化が通知される。

また、情報が蓄積された外部データベースを管理する管理装置とともに用いられ、前記データベースの状態変化を監視し、同一のネットワークを共有して同時に双方向通信可能な情報端末群に対し前記状態変化を同報的に通知するために、前記情報端末群のうちの所定の端末に前記状態変化を通知する監視装置も考えられる。
前記システムにおける監視手段と同様の作用効果を有する。

また、同一のネットワークを共有して同時に双方向通信可能な情報端末群のうちの少なくとも１つに設けられ、情報が蓄積された外部データベースに状態変化が発生したことを知らせる通知を前記ネットワーク外から受信し、前記状態変化を他の前記情報端末に同報的に通知するために、前記通知を前記ネットワークに所定のタイミングで送出する通知装置も考えられる。

前記システムにおける通知手段と同様の作用効果を有する。
また、情報が蓄積された外部データベースを管理する管理装置に用いられる監視通知プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
Ａ；前記データベースの状態変化を監視する段階と、
Ｂ；前記状態変化が発生した場合、同一のネットワークを共有して同時に双方向通信可能な情報端末群に対し前記状態変化を同報的に通知するために、前記情報端末群のうちの所定の端末に前記状態変化の発生を通知する段階と、
を実行させるための監視通知プログラムを記録した、コンピュータ読み取り可能な記録媒体も考えられる。

前記システムにおける監視手段と同様の作用効果を有する。
また、同一のネットワークを共有して同時に双方向通信可能な情報端末群のうちの少なくとも１つの端末に用いられる同報通知プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
Ａ；情報が蓄積された外部データベースに状態変化が発生したことを知らせる通知を前記ネットワーク外から受信する段階と、
Ｂ；前記状態変化を他の前記情報端末に同報的に通知するために、前記通知を前記ネットワークに所定のタイミングで送出する段階と、
を実行させるための同報通知プログラムを記録したコンピュータ読み取り可能な記録媒体が考えられる。

前記システムにおける通知手段と同様の作用効果を有する。

本発明を用いれば、ネットワークを共有するユーザに対し、ネットワーク外の状態変化をリアルタイムに通知することができ、またユーザは互いに情報を共有しているとの認識に立ってコミュニケーションをすることができる。

以下に、本発明の状態変化通知システムについて、図面を参照しながら具体的に説明する。
＜基本構成＞
図１は、本発明の状態変化通知システムの基本的な構成を示す図である。以下においては、本発明をＩＲＣ（Internet Relay Chat）に基づいたチャットシステムに適応する場合を例にとり説明する。状態変化通知システムは、ホームページなどの状態変化発生源、監視手段、通知手段及びチャネルを共有する複数のチャットクライアントからなっている。

監視手段は、状態変化発生源を監視し、何らかの状態変化を検知すると通知手段に通知する。通知手段は、通知された内容を、必要に応じてＩＲＣの通信プロトコルに従って変換し、チャットクライアントＡを介してチャネルに送出する。従って、生じた状態変化は、チャネルに参加している他のチャットクライアントＢ、Ｃにリアルタイムで通知される。

＜第１実施形態例＞
［全体構成］
図２は、本発明の第１実施形態例に係る状態変化通知システムの全体構成図である。状態変化通知システムは、複数のデータベース（以下にＤＢという）１，２、各ＤＢを管理するＤＢ管理システムＤＢＭＳ（Data Base Management System）１，２、複数の代理端末Ａ，Ｂ、複数のユーザ端末Ａ，Ｂ，Ｃ，Ｄ及びチャットサーバから構成されている。代理端末及びユーザ端末はネットワークを介してチャットサーバに接続されている。代理端末Ａ及びユーザ端末Ａ，Ｂは、チャネル＃ＣＨ１に参加している。代理端末Ｂ及びユーザ端末Ｃ，Ｄは、チャネル＃ＣＨ２に参加している。

［ＤＢＭＳ］
ＤＢＭＳ１及び２は、それぞれＤＢ１及び２の管理を行う。具体的には、ＤＢへの情報の登録、更新、削除等を行う。ＤＢの管理については通常と同様であるので詳細な説明を省略する。本実施形態例においては、各ＤＢＭＳに監視部１とＤＢ−端末リスト２とが付加されている。ＤＢ−端末リスト２の概念図を図３に示す。ＤＢ−端末リスト２には、監視すべきＤＢとそのＤＢの状態変化を通知する代理端末とが対応付けられている。図３（ａ）は、ＤＢＭＳ１のＤＢ−端末リストである。このリストは、監視部の監視対象がＤＢ１であり、ＤＢ１の状態変化が代理端末A及びBに通知されることを示している。図３（ｂ）は、ＤＢＭＳ２のＤＢ−端末リストである。このリストは、監視部の監視対象がＤＢ２であり、ＤＢ２の状態変化が代理端末Ｂに通知されることを示している。なお、本実施形態例では、１つのＤＢＭＳが１つのＤＢを管理する構成を示している。必要に応じ、ＤＢＭＳが複数のＤＢを管理する構成も可能である。

監視部１は、前記ＤＢ−端末リスト２を参照し、監視するＤＢ及び通知先の代理端末を決定する。監視部１は、監視対象のＤＢについて所定時間間隔毎にＤＢＭＳのログを見に行き、前回のログと比較する。前記ログは、通常ＤＢＭＳにより作成され、ＤＢの更新履歴が書き込まれている。ログを見に行く時間間隔は、特に限定されないが、監視部１の負担とユーザへの迅速な通知とを考慮して設定すると良い。ＤＢの状態変化が生じていれば、監視部１は通知先の代理端末に状態変化を通知する。通知は、所定の情報を含み、所定のフォーマットを有する通知データを送出することにより行われる。所定の情報には、例えばＤＢ名、項目、日時、ＤＢ内の情報識別番号、情報の内容が含まれる。このような通知データとしては、例えば"DB1:更新:19990123-2019:情報ＩＤ0:titleお知らせ"を挙げることができる。代理端末への通知のプロトコルは、特に限定されないが、本実施形態例ではＩＲＣプロトプルに従って通知することが好ましい。通知部が、受け取った通知データをそのままＩＲＣのチャネルに送出できるからである。

［代理端末］
代理端末は通知部３とチャットクライアントとを有している。ただし、代理端末のチャットクライアントは、通知部３から送出される状態変化通知をチャネル内に送出する。図４は、通知部３の構成を示すブロック図である。通知部３は、通信部３１、整形部３２、バッファ３３、タイミング管理部３４、送出部３５及びチャネルリスト３６を有している。

通信部３１は、監視部１から通知データを受け取り、整形部３２に送出する。
整形部３２は、受け取った通知データを、所定の形式に変換し、バッファ３３に書き込む。例えば整形部３２は、チャットのユーザが読みやすい所定の形式に通知データを変換する。具体的には、前述の通知データ"DB1:更新:19990123-2019:情報ＩＤ0:titleお知らせ"を、"新着ニュース（２０時１９分）［情報ＩＤ０］おしらせ"に変換する。監視部１と通信部３１との間の通信プロトコルがＩＲＣに準拠していない場合には、整形部３２はＩＲＣに準拠したデータ形式への変換も行う。また、整形部３２は、必要に応じ、所定の情報をタイミング管理部３４に送出する。タイミング管理部３４に送出する情報は、後述するように、状態変化通知をチャネルに送出するタイミングをどのように制御するかに依る。

バッファ３３は、整形部３２により変換された通知データ（以下状態変化通知という）を一時的に蓄積する。本実施形態例においては、バッファ３３には状態変化通知が時系列に蓄積される。
タイミング管理部３４は、バッファ３３に蓄積された状態変化通知をチャネルに送出するタイミングを制御する。送出のタイミングは、所定の条件、例えばチャネルの状態や整形部３２からの所定の情報に基づいて決定される。チャネルの状態とは、例えば、会話の込み具合、参加者数、話題の変化、チャネル管理者の変化が挙げられる。本実施形態例及び以下の実施形態例においては、特に断りのない限り、”チャネル内の発言が過去３分間ない場合”というチャネル状態に基づいて前記タイミングが決定されるものとする。この場合、タイミング管理部３４は、整形部３２から状態変化のあったＤＢ名を受け取る。次いで、タイミング管理部３４は、後述するようにＤＢと対応するチャネルを決定し、チャットクライアントからチャネル内における会話の記録を取得する。さらに、タイミング管理部３４は、会話記録に基づいて状態変化通知を送出するか否かを決定する。送出する場合は送出部３５に対し、チャネルを指定して送出を指示する。送出しない場合は、所定時間間隔毎にチャネル内の発言記録を取得し、送出可能になるのを待機する。タイミング管理部３４からの送出の指示に応じ、バッファ３３内の最も古い状態変化通知が指定されたチャネルに送出される。

タイミング管理部３４は、前記送出のタイミングを決定する前に、前記状態変化通知を送出するチャネルを決定する。チャネルの決定は、チャネルリスト３６を参照することにより行われる。図５にチャネルリスト３６の概念図を示す。チャネルリスト３６には、どのＤＢの状態変化通知をどのチャネルに送出するかが対応付けられている。図５（ａ）は、代理端末Ａの通知部に設けられたチャネルリスト３６である。このリストは、ＤＢ１の状態変化通知がチャネル＃ＣＨ１に送出されることを示している。図５（ｂ）は、代理端末Ｂの通知部に設けられたチャネルリスト３６である。このリストは、ＤＢ１及びＤＢ２の状態変化通知がチャネル＃ＣＨ２に送出されることを示している。タイミング管理部３４は、整形部３２から通知されるＤＢ名をキーにチャネルリスト３６を参照し、状態変化通知を送出するチャネルを決定する。タイミング管理部３４は、チャネルの指定も含めて送出部３５に送出指示を行う。

送出部３５は、タイミング管理部３４からの送出の指示に従い、バッファ３３内の状態変化通知を指定されたチャネルに送出する。本実施形態例においては、状態変化通知は時系列に蓄積されているので、送出部３５は最も古い、すなわち先頭の状態変化通知を送出する。送出後、送出部３５は、送出した状態変化通知をバッファ３３から削除する。
［ユーザ端末］
図６は、ユーザ端末の構成を示すブロック図である。各ユーザ端末は、チャットクライアントを有し、さらに表示部４を有することが好ましい。表示部４は、チャネルに送出される状態変化通知を、チャネル内の通信データから抽出する。具体的には、表示部４は、整形部３２により所定の形式に変換された状態変化通知を抽出する。例えば、”ＤＢ＊：＊時＊分：ＩＤNo.＊：＊”の形式からなる発言を抽出する。ここで、”＊”は文字データを意味する。そして、表示部４は、ディスプレイに通知領域を作成し、抽出した状態変化通知を前記領域に出力する。

図７は、表示部４により表示される状態変化通知の一例を示す図である。この図は、チャネル＃ＣＨ２に参加しているユーザ端末Ｃ、Ｄの表示部４による画面例である。チャットクライアントは、チャネル選択ボタン４１、会話表示領域４２及び発言入力領域４３を画面上に表示している。表示部４は通知領域４４を表示している。チャネル＃ＣＨ２内の通常の会話は、会話表示領域４２に表示される。チャネル＃ＣＨ２内に通知されるＤＢ１及びＤＢ２の状態変化通知は、時系列順に画面右の通知領域４４に表示される。

文字による状態変化通知に代え、アイコン等視覚的手段を用いて状態変化通知を表示することも考えられる。図８に、アイコンによる状態変化通知の一例を示す。図８では、為替レートの上下変動を示すアイコンが表示されている。さらに、ユーザ端末にＤＢアクセスクライアントを持たせると好ましい。アイコンがクリックされると、表示部が情報の識別番号をＤＢアクセスクライアントに送付する。ＤＢアクセスクライアントは、識別番号で特定される情報の詳細をＤＢから取得し、画面などに出力する。

なお、図７及び８においては、状態変化通知が時系列に表示されているが、ニーズに応じて表示の順序を代えることも可能である。例えば、表示部４によりＤＢ名のアルファベット順に並べ替え、同一のＤＢに関する通知は時系列に並べて表示することが挙げられる。なお、表示部４を設けず、通常の会話と状態変化通知とをともに会話表示領域に混在して表示することももちろん可能である。

［処理の流れ］
次に、本実施形態例に係る監視部１及び通知部３が行う処理の流れについて説明する。
［１］監視部の処理
まず、監視部１が行う監視処理の流れについて説明する。図９は、監視部１が行う監視処理の流れを示すフローチャートである。

ステップＳ１では、監視部１は、監視すべきＤＢの更新履歴をＤＢＭＳのログから取得する。監視すべきＤＢは、前記ＤＢ−チャネルリスト３６を参照して決定する。
ステップＳ２では、前回ログを参照してから所定時間経過したか否かを判断する。ここでは、所定時間として６０秒を設定している。６０秒経過していると判断すると、ステップＳ３に移行する。まだ６０秒経過していないと判断すると、再びステップＳ２を繰り返す。

ステップＳ３では、監視部１は再びログを参照し、更新履歴を取得する。
ステップＳ４では、監視部１は、先に取得した更新履歴と後で取得した更新履歴とを比較し、ＤＢの状態が変化したか否かを判断する。両者が同じであれば、次の更新履歴を取得するためにステップＳ２に移行する。前者の更新履歴を取得した時刻より後に登録された情報が後者の更新履歴にあれば、ステップＳ５に移行する。

ステップＳ５では、監視部１は、後で取得した更新履歴から後に登録された情報を取り出し、所定の通知データを作成して通知部３に送出する。
［２］通知部の処理
次に、本実施形態例に係る通知部３が行う処理の流れについて説明する。通知部３は、以下に説明する受信処理と通知処理とをそれぞれ独立に行う。

（１）受信処理
図１０（ａ）は、通知部３が行う受信処理の流れを示すフローチャートである。
まず、ステップＳ１１においては、整形部３２は、監視部１からの通知データを待機している。通知データを受信すると、ステップＳ１２へ移行する。
ステップＳ１２では、整形部３２は、受け取った通知データを所定の形式に変換し、バッファ３３に時系列に書き込む。

すなわち、受信処理では、通知部３は、通知データを受信するたびに変換し、バッファ３３に格納する処理を行う。
（２）通知処理
図１０（ｂ）は、通知部３が行う通知処理の流れを示すフローチャートである。
ステップＳ２１では、整形部３２は、監視部１からの通知データを待機している。通知データを受信すると、ステップＳ２２へ移行する。

ステップＳ２２では、整形部３２は、通知データに含まれるＤＢ名をタイミング管理部３４に送出する。
ステップＳ２３では、タイミング管理部３４は、前記通知されたＤＢ名をキーにチャネルリスト３６を参照し、ＤＢに対応するチャネルを特定する。次いで、タイミング管理部３４は、特定したチャネルの会話記録をチャットクライアントから取得する。

ステップＳ２４では、タイミング管理部３４は、取得した会話記録に基づいて、状態変化通知をチャネルに送出するか否かを判断する。送出すると判断すると、後述するステップＳ２６に移行する。送出しないと判断すると、ステップＳ２５に移行する。
ステップＳ２５では、タイミング管理部３４は、所定時間T1が経過するのを待機する。所定時間が経過すると、再び前記ステップＳ２４に戻り、前記判断を繰り返す。すなわち、タイミング管理部３４は、送出できるようになるまで待機する。

ステップＳ２６では、タイミング管理部３４は、チャネルの指定とともに、状態変化通知の送出を送出部３５に指示する。
ステップＳ２７では、送出部３５が、バッファ３３に格納されている最も古い、すなわち先頭の状態変更通知を取り出す。次いで、送出部３５は、チャットクライアントを介し、指定されたチャネルに前記通知を送出する。

すなわち、通知処理では、通知部３はバッファ内の状態変化通知を、適当なタイミングで送出する処理を行う。
＜第２実施形態例＞
図１１は、第２実施形態例に係る状態変化通知システムの全体構成図である。本実施形態例は、前記第１実施形態例において、ＤＢがメールＤＢである場合の構成である。ここで、メールＤＢとは、メーリングリストに投稿される電子メールを蓄積するＤＢである。説明を容易にするため、図１１ではメールＤＢが１つの場合の構成を示している。また、メールの投稿をチャネルに通知するタイミングの決定方法は、前記第１実施形態例と同様とする。本実施形態例においては、通知部２０３がチャネルリストに代えてML-CHテーブル２３８を有することと、各ユーザ端末がチャットクライアントに加えて電子メール装置を有することを除き、前記第１実施形態例と同様の構成を有する。電子メール装置は、ユーザ端末上で電子メールの送受信を行うための装置である。

監視部２０１は、メールＤＢにいずれかのメーリングリスト宛の電子メールが到着すると、所定の通知データを通知部２０３に送出する。通知データには、メーリングリスト及びメールＩＤが含まれている。メールＩＤは、メールＤＢ内の電子メールを特定するための識別番号である。
通知部２０３は、ML-CHテーブル２３６を有する。図１２にML-CHテーブル２３６の概念図を示す。ML-CHテーブル２３６には、どのメーリングリストへの電子メールの投稿をどのチャネルに通知するかの対応付けがなされている。言い換えれば、このテーブルにより、メーリングリストのユーザグループと、チャネルに参加しているユーザグループとが対応付けられる。

整形部２３２は、ＤＢ名に代えてメーリングリストをタイミング管理部２３４に通知する。また、整形部２３２は、メーリングリスト及びメールＩＤを含む所定の形式の投稿通知に、通知データを変換する。
タイミング管理部２３４は、通知されたメーリングリストをキーにML-CHテーブル２３６を参照し、対応するチャネルを特定する。また、タイミング管理部２３４は、特定したチャネルにメールの投稿通知を送出するタイミングを管理する。さらに、送出部２３５に対し、チャネル名とともに投稿通知の送出を指示する。

送出部２３５は、特定されたチャネルに所定形式の投稿通知を送出する。整形部２３２、バッファ２３３、タイミング管理部２３４及び送出部２３５の他の動作は、前記第１実施形態例と同様である。電子メールの投稿をチャネル内に発言することにより、電子メール装置を起動させていないユーザも電子メールの投稿を知ることができる。メーリングリストに含まれるユーザと、チャネルに参加もしくは参加を許可されているユーザとは、一致していることが好ましい。

処理の流れは、第１実施形態例と同様である。
＜第３実施形態例＞
図１３は、第３実施形態例にかかる状態変化通知システムの全体構成図を示す。本実施形態例の状態変化通知システムは、代理端末にメール配送装置を、通知部にメール送出部３３７及びメール先決定部３３８を、ユーザ端末に電子メール装置を、それぞれ付加した点を除き、前記第１実施形態例の構成と同様である。メール配送装置は、メーリングリストに投稿される電子メールを受け取り、メーリングリストに含まれる各ユーザ端末に電子メールを配送する装置である。前記第１実施形態例では、チャネルに参加していないユーザには、状態変化が通知されない。本実施形態例では、チャネルに参加していないユーザに対しては、電子メールにより状態変化を通知する。

［構成］
メール配送装置は、通常ＭＬテーブルを有している。図１４にＭＬテーブルの概念図を示す。ＭＬテーブルは、メーリングリストと、そのメーリングリストに含まれる各ユーザとを対応付けている。例えば、メーリングリスト“ML-1”には、ユーザＡ（user-a@fujitsu.co.jp）及びユーザＢ（user-b@fujitsu.co.jp）が含まれている。

監視部３０１、端末リスト３０２、通信部３３１、整形部３３２、バッファ３３３、タイミング管理部３３５及び送出部３３４の動作は、前記第１実施形態例と同様である。ただし、送出部３３４は、状態変化通知を送出すると、通知を送出したチャネルをメール先決定部に通知する点で相違する。また、送出部３３４は送出した状態変化通知をバッファから削除しない点も第１実施形態例と相違する。

メール先決定部３３８は、ML-CHテーブル３３６を参照し、チャネルに対応するメーリングリストを特定する。ML-CHテーブル３３６については、前記第２実施形態例と同様であるので、説明を省略する。次いでメール先決定部３３８は、メーリングリストをキーに、メール配送装置のＭＬテーブルを参照し、特定したメーリングリストに含まれるユーザを取得する。また、メール先決定部３３８は、チャネルに参加しているユーザのリストを、チャットクライアントから取得する。メール先決定部３３８は、メーリングリストに含まれているユーザと、チャネルに参加しているユーザとを比較し、電子メールの配送先を決定する。両者を比較せず、特定したメーリングリストを配送先としてもよい。この場合は、チャットクライアントからチャネル内のユーザリストを取得する必要はない。決定した配送先は、メール送出部３３７に通知される。

メール送出部３３７は、配送先の通知に従い、バッファ３３３から最も古い状態変化通知を取り出し、配送先とともにメール配送装置に送出する。その後、メール送出部３３７は、送出した状態変化通知をバッファ３３３から削除する。
［処理の流れ］
次に、本実施形態例における処理の流れを簡単に説明する。説明を容易にするため、状態変化通知の送出タイミングは、第１実施形態例と同様に決定されるものとする。また、チャネルに参加していなかったユーザに電子メールを配送する場合を例に取る。

図１５は、本実施形態例の通知部３０３が行う処理の流れを示すフローチャートである。監視部３０１が行う監視処理は、前記第１実施形態例と同じであるので説明を省略する。前記第１実施形態例の通知処理と同様に、通知データを通知部３０３が受信することにより以下の処理が開始される。以下の処理において、ステップＳ３１からステップＳ３７までは、前述の第１実施形態例におけるステップＳ２１〜２７と同様であるので、ステップＳ３８から説明する。

ステップＳ３８では、送出部は、状態変化通知をチャネルに送出した後、通知を送出したチャネル名をメール先決定部３３８に通知する。
ステップＳ３９では、メール先決定部３３８は、ML-CHテーブル及びＭＬテーブルを参照し、メーリングリストに含まれているユーザを取得する。
ステップＳ４０では、メール先決定部３３８は、通知されたチャネルに参加しているユーザをチャットクライアントから取得する。

ステップＳ４１では、メール先決定部３３８は、メーリングリストに含まれているユーザの中でチャネルに参加していないユーザのメールアドレスを、メールの配送先に決定する。
ステップＳ４２では、メール先決定部３３８は、メール配送先があるか否かを判断する。メールの配送先がある場合は、ステップＳ４３に移行する。配送先がない場合は、後述するステップＳ４４に移行する。配送先がない場合とは、言い換えればメーリングリストに含まれているユーザの全てがチャネルに参加している場合である。

ステップＳ４３では、メール先決定部３３８は、決定した配送先をメール送出部３３７に送出し、メールの配送を指示する。メール送出部３３７は、最も古い状態変化通知をバッファ３３３から取り出し、配送先のメールアドレスと共にメール配送装置に送出する。その後、メール送出部３３７は、送出した状態変化通知をバッファ３３３から削除する。その後、ステップＳ３１に戻る。

ステップＳ４４では、メール先決定部３３８は、メール送出部３３７に対し、状態変化通知をバッファ３３３から削除するよう指示する。メール送出部３３７は、指示に従い、バッファ３３３の中で最も古い状態変化通知を削除する。その後、ステップＳ３１に戻る。
＜第４実施形態例＞
図１６は、メーリングリストに投稿された電子メールの受信をチャットシステムにより通知する状態変化通知システムの構成図を示している。第２実施形態例と異なる点は、メーリングリスト宛のメールを蓄積するメールＤＢは設けられていない点である。本実施形態例にかかる状態変化通知システムは、通知端末と、複数のユーザ端末Ａ〜Ｄとがコンピュータネットワークにより接続されて構成されている。ユーザ端末は、第２及び第３実施形態例と同様に、チャットクライアントと電子メール装置とを有している。

通知端末は、ＭＬテーブルを有するメール配送装置と、通知部と、チャットクライアントとを備えている。通知部は、整形部４３２、タイミング管理部４３４、バッファ４３３、送出部４３５、メール検知部４３６、チャネル決定部４３７及びML-CHテーブル４３８を有している。
ＭＬテーブルは、第３実施形態例と同様、メーリングリストとそのメーリングリストに含まれる各ユーザのアドレスとを対応付けている。ただし、各メーリングリストにはメール検知部４３６の電子メールアドレスが含まれている点が、第３実施形態例と異なる。従って、いずれかのメーリングリスト宛に電子メールが投稿されると、その電子メールはメーリングリストに対応する各ユーザ端末及びメール検知部４３６に配送される。

メール検知部４３６は、いずれかのメーリングリスト宛の電子メールを受け取ると、受け取った電子メールの宛先となっているメーリングリストをチャネル決定部４３７に通知する。
ML-CHテーブルには、前記第２実施形態例と同様に、メーリングリストとチャネルとが対応付けられている。チャネル決定部４３７は、メール検知部４３６から通知されるメーリングリストに対応するチャネルを、ML-CHテーブルを参照して特定する。チャネル決定部４３７は、決定したチャネルをメール検知部４３６に通知する。これを受けてメール検知部４３６は、所定の情報を含む所定形式の通知データを整形部４３２に送出する。所定の情報には、例えば、チャネル名、電子メールのコンテンツ、メーリングリスト、投稿時刻などが含まれる。

整形部４３２に送出された所定の情報は、前記と同様に所定の形に変換されてバッファ４３３に蓄積される。また、発言先のチャネルなど状態変化通知のタイミングに必要な情報部は、整形部４３２からタイミング管理部４３４に通知される。整形部４３２、タイミング管理部４３４、バッファ４３３及び送出部４３５の動作については、第１実施形態例と同様であるので詳細を省略する。

［処理の流れ］
図１７は、第４実施形態例に係る状態変化通知システムにおいて、通知端末が行う監視処理の流れを示すフローチャートである。通知データの受信処理及び状態変化通知の通知処理については、第１実施形態例と同様であるので説明を省略する。メール配送装置がいずれかのユーザからメーリングリスト宛のメールを受信することにより、以下の処理が開始される。

まずステップＳ５１では、メーリングリスト宛に送られて来た電子メールがメール検知部４３６に配送される。すなわちメール検知部４３６が電子メールの受信を検知する。メール検知部４３６は、電子メールを受信すると、チャネル決定部４３７にメーリングリストを通知する。
ステップＳ５２では、チャネル決定部４３７が、メーリングリストに対応するチャネルを決定する。これは、ML-CHテーブルを参照することにより行われる。チャネル決定部４３７は、決定したチャネルをメール検知部４３６に通知する。

ステップＳ５３では、メール検知部４３６は、メーリングリスト、投稿時刻、コンテンツ、チャネル名などの所定情報を整形部４３２に通知する。
整形部４３２に通知された情報は、前記第１実施形態例におけるステップＳ２１〜２７と同様にしてバッファに蓄積され、チャネルに送出される。ただし、整形部４３２はタイミング管理部４３４に対し、ＤＢ名でなくチャネル名を通知する点が異なる。

＜第５実施形態例＞
前述の第１〜４実施形態例では、送出タイミングの決定条件がチャネル状態に基づく場合、特に”チャネル内の発言が過去３分間ない場合”を例に取り説明したが、他の条件も考えられる。以下に、他の条件に基づく場合について、いくつかの例を挙げて説明する。
（ａ）”通知内容の時刻情報に基づいて送出時間を決定する”場合
通知部は、変化した情報にアクセス可能となる日時が含まれた通知データを受け取る。例えば、"DB1:更新:19990801-1200:情報ＩＤ0:アクセス許可:20010101-1200:title新製品情報"なる通知データである。この場合、タイミング管理部は、前記状態変化通知の送出タイミングを、2001/1/1の12:00に決定する。タイミング管理部は、決定したタイミングを記憶しておく。そして、決定した日時になると、状態変化通知の送出を送出部に指示する。従って、タイミング管理部は、所定の時間間隔で、送出すべき状態変化通知があるかどうかをチェックする必要がある。また、バッファ内のどの状態変化通知を送出するかを送出部に指示するために、状態変化通知を特定するための識別情報が必要である。例えば、状態変化通知と送出時刻とを対応付けてバッファに格納することが考えられる。

また、通知データの内容そのものに時刻情報が含まれている場合、その時刻情報に基づいて送出タイミングを決定することも可能である。また所定の時刻範囲、例えば９：００〜１７：００の間のみ送出を行うことも考えられる。例えば、スケジュールが蓄積されたスケジュールＤＢ１に、”１月１８日打ち合わせ”というスケジュールが１月７日に登録される。通知データは、“DB1:登録:19990107-10:50:情報ID0:title１月１８日打ち合わせ”である。タイミング管理部は、“１月１８日”を整形部から受け取り、送出タイミングを１月１８日９時に決定する。１月１８日の９時になると、タイミング管理部は送出部に対して情報の送出を指示する。送出部は、送出指示と共に通知される日時をキーにしてバッファから情報を取得し、チャットクライアントを介して発言する。前述と同様、タイミング管理部は、決定した日時を記憶し、常に送出タイミングになっているかどうかチェックする。また、バッファ内の状態通知を特定する識別情報も前述と同様必要である。

（ｂ）” 所定のキーワードが含まれる場合に送出する”場合
状態変化の送出タイミングを、”所定のキーワードが含まれる状態変化通知である場合”とすることも考えられる。図１８に示すように、前記チャネルリストにおいて、各チャネルのキーワードをチャネルと対応付けて登録しておく。図１８においては、チャネル＃ＣＨ２のキーワードとして”株価”が登録されている。タイミング管理部は、整形部から通知データ“title”を受け取り、“title”に“株価”が含まれている場合のみ＃ＣＨ２に状態変化通知を送出する。例えば、"DB1:更新:19990801-1200:情報ＩＤ0: title株価情報"なる通知データを受け取った場合である。

＜第６実施形態例＞
前記第１〜３実施形態例においては、監視部が所定時間各毎にＤＢＭＳ内のログをチェックしている。逆に、ＤＢＭＳから監視部に対し、ログを更新する毎に通知を送出する構成も可能である。

本発明の基本構成を示す説明図。 第１実施形態例にかかる状態変化通知システムの全体構成図。 ＤＢ−端末リストの概念説明図。 第１実施形態例に係る通知部の構成を示すブロック図。 チャネルリストの概念説明図。 ユーザ端末の構成を示すブロック図。 状態変化通知の表示例を示す説明図。 アイコンによる状態変化通知の表示例を示す説明図。 監視処理の流れを示すフローチャート。 通知部の処理の流れを示すフローチャート。（ａ）受信処理の流れを示すフローチャート。（ｂ）通知処理の流れを示すフローチャート。 第２実施形態例にかかる状態変化通知システムの全体構成図。 ＭＬ−ＣＨテーブルの概念説明図。 第３実施形態例にかかる状態変化通知システムの全体構成図。 ＭＬテーブルの概念説明図。 第３実施形態例における通知部の通知処理の流れを示すフローチャート。 第４実施形態例にかかる状態変化通知システムの全体構成図。 第４実施形態例に係る監視処理の流れを示すフローチャート。 第５実施形態例におけるチャネルリストの概念説明図。

符号の説明

１；監視部
２；端末リスト
３；通知部
３２、２３２，３３２；整形部
３３，２３３，３３３；バッファ
３４，２３４，３３４；タイミング管理部
３５，２３５，３３５；送出部

Claims (3)

1. 互いに同一の仮想空間を共有して同時に双方向通信可能な情報端末に設けられ、情報が蓄積され前記仮想空間の外部に設けられたデータベースの状態変化を知らせる所定形式の通知を、前記仮想空間内の通信データから抽出し、視覚的に出力する状態変化表示装置。
2. 互いに同一の仮想空間を共有して同時に双方向通信可能な情報端末に用いられる、状態変化表示プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   Ａ；情報が蓄積され、前記仮想空間の外部に設けられたデータベースの状態変化を知らせる所定形式の前記通知を、前記仮想空間内の通信データから抽出する段階と、
   Ｂ；前記抽出された通知を視覚的に出力する段階と、
   を実行するための状態変化表示プログラムを記録したコンピュータ読み取り可能な記録媒体。
3. 同一の仮想空間を共有して同時に双方向通信可能な情報端末群宛の電子メールを、それぞれの情報端末に配送可能な電子メール配送装置に用いられるメール通知装置であって、
   前記情報端末群に含まれ、いずれかの前記情報端末群宛に配送される電子メールを検知し、前記電子メールの宛先を特定する検知手段と、
   前記情報端末群と前記仮想空間とを対応付けるテーブルと、
   前記テーブルに基づいて、前記配送される電子メールの宛先の情報端末群に対応する仮想空間を決定する決定手段と、
   前記決定した仮想空間に対し、前記電子メールが投稿されたことを知らせる通知を送出する通知手段と、
   を備えるメール通知装置。

Images