JP3610718B2 - 電子会議システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の利用者がメッセージを登録及び参照することで、討論、会議、議論、討議、意見交換、世間話などを行なう、いわゆる電子会議システムに関する。
【０００２】
【従来の技術】
電子会議システムにおいては、登録されたメッセージを親子関係をつけて管理することで、話の流れをわかりやすくしている。あるメッセージに対してコメントが付けられた場合には、もとのメッセージが親となりコメントのメッセージが子となる。一つのメッセージには複数のコメントを付けることが可能で、討論は一つの木構造を構成する。最初のメッセージをトピックメッセージ（または、単にトピック）、他のメッセージに対するコメントのメッセージをリプライメッセージと呼ぶ。
【０００３】
ところで、小規模な電子会議システムを構築する場合には、小さなネットワークで一つのサーバと数台クライアントでシステムを構築すれば十分であるが、例えば利用者が世界中に散らばっているような電子会議システムを構築する場合、一つのサーバで全てのクライアントの処理を行なうことは、サーバに対する負荷及びネットワークに対する負荷を考慮すると、あまり効率のよいものとは言えない。そこで、一つのサーバと複数のクライアントで構成される複数の小さな電子会議システムを、お互いに接続し、サーバ間で共通のデータを保持することで、全体として一つの電子会議システムを構築した。
【０００４】
このような分散型のシステムでは、ネットワークの負荷を低く押えるために、あるサーバに対してメッセージが登録された場合に、直ちにそのメッセージを他のサーバに対して送付するのではなく、ある期間の間に登録された複数のメッセージを所定時間毎に一括して他のサーバに対して送付していた。
また、サーバに登録されているメッセージを削除した場合にも、メッセージを削除した旨の情報が、直ちに他のサーバに対して通知されるのではなく、登録されたメッセージが他のサーバに送付されるのと同時にまとめて通知されていた。
【０００５】
分散型の電子会議システムのメッセージの転送はサーバ間のネットワーク構成や運用の方法により必ずしも古いメッセージが新しいメッセージよりも先に転送されてくるとは限らなかった。
また、メッセージの登録先の入れ物（例えばフォルダや会議室等と呼ばれる）を動的に作成したり削除したりする場合に、入れ物の作成の通知よりも、それに対して登録されるメッセージが先に転送される場合もあった。
【０００６】
また、電子会議システムでは利用者の利便のために、利用者履歴情報として利用者毎にどのメッセージを読んだかを記憶しておき、利用者が登録されているメッセージの一覧情報等を表示するような場合に、登録されている全てのメッセージ、もしくは、一覧対象のメッセージの個々について、既に読んだメッセージかそうでないかをチェックし、利用者が区別できるようにしていた。また利用者はこの一覧情報を参照することで、新しいメッセージが登録されているか否かを判断することができた。
【０００７】
また、電子会議システムの記憶領域は有限であるため、新規にメッセージを登録するための領域を確保するために、古くなったメッセージは必要に応じて削除されていた。
このような場合以外には、利用者からの要求などにより、メッセージが削除されることがあるが、メッセージが削除された場合、削除されたメッセージに対するコメントのメッセージがトピックメッセージとして扱われていた。
【０００８】
【発明が解決しようとする問題点】
親となるメッセージが既に削除され、もはや存在しない場合、リプライメッセージ（子となるメッセージ）を登録しようとした場合、そのメッセージは破棄される。ところで、親となるメッセージと、リプライメッセージ（子となるメッセージ）が別々のサーバから送付され、親となるメッセージよりもリプライメッセージ（子となるメッセージ）が先に送付されてくる場合、親となるメッセージが存在しない場合、リプライメッセージ（子となるメッセージ）は破棄されてしまい、サーバによってあるメッセージが存在したり存在しなかったりするという問題があった。
【０００９】
また、利用者履歴情報が大きくなり、システムの記憶領域を圧迫し、新しくメッセージの登録が出来なくなったりする問題があった。
また、新しくメッセージが登録されたか否かを知るには、利用者は登録されているメッセージの一覧を表示せざるを得なかった。登録されている全てまたは一覧対象の一つ一つのメッセージについて利用者が既に参照したか否かを判断することは、電子会議システムにとって、負荷がかかり、また、利用者にとっても新規のメッセージが登録されているか否かを判断するためだけに、一覧表示を行なうことは時間の無駄であった。
【００１０】
討論が長期間に渡って継続しているような場合、討論の始めの時期に登録されたメッセージが、電子会議システムの記憶領域の確保のために、削除されてしまうと、途中から討論に参加した利用者は、どのような経緯で討論が開始され、過去にどのような発言があったかをしることができないといった問題があった。
さらに、メッセージが古くなって削除された場合、コメントのつけられたメッセージ、即ち子のメッセージが登録されているメッセージを削除した場合に、本来一つの木構造で管理されていた討論が、複数の木構造に分割されてしまう。分割された木構造で管理されてしまい、途中から討論に参加した利用者は討論の全体象がつかみづらいという問題があった。
【００１１】
【課題を解決するための手段】
これらの問題を解決するための手段は以下の通りである。
即ち、本発明では、削除したメッセージのメッセージＩＤを記憶しておき以下の処理を行なう。
利用者毎に記憶する利用者が読んだメッセージの情報のうち、削除されたメッセージに関しては利用者毎に記憶している情報から削除する。この処理を利用者がログインする際に行なう。
【００１２】
リプライメッセージを登録する際に、親メッセージが存在しない場合、親メッセージが削除されたものであるか否かを、記憶しておいた削除したメッセージのメッセージＩＤを用いて判断する。親メッセージが削除済みである場合にのみ登録しようとするメッセージを削除する。
また、メッセージを登録する登録先の入れ物（例えば会議室やフォルダ等と呼ばれる）の作成の通知よりもその入れ物に対するメッセージの登録の通知の方が先に到着した場合には、親メッセージが存在しないリプライメッセージを登録する場合と同様に、入れ物が削除されていた場合にのみメッセージを削除する。
【００１３】
利用者毎に利用者が参照した最新のメッセージの作成日時と、電子会議システムに登録されている最新のメッセージの作成日付とをそれぞれ記憶しておく。利用者がログインした際などに、両者を比較してメッセージが新しく登録されたか否かの判断を容易にかつ高速に行う。
古くなったメッセージを削除する場合には、削除するか否かの判断をメッセージ毎に行なうのではなく、メッセージが属する討論の最新のメッセージの作成日時を基準にして有効期限を計算し、最新のメッセージの有効期限がきれている場合に討論のすべてのメッセージを削除する。
【００１４】
メッセージに対して一意に付与されるメッセージＩＤを、討論の階層番号、順序番号、討論内のパス情報で構成する。
【００１５】
【発明の実施の形態】
以下に、本発明の実施の形態を図面を用いて説明する。
図１は分散型電子会議システムの構成の一例を示す図である。
図中、１−ｎ（１−１、１−２、１−３、１−４）はサーバ、２−ｎ（２−１１、２−１２、２−２１、２−２２、２−３１、２−３２、２−４１、２−４２）はクライアント、３−ｎ（３−１、３−２、３−３、３−４）はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、４はＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ） である。
【００１６】
電子会議システムの利用者はクライアント２−ｎからＬＡＮ３−ｎ上のサーバ１−ｎにログインし、サーバにメッセージを登録したり、サーバに登録されているメッセージを参照したりすることで、会議、論議、討議、討論、世間話等を行なう。
利用者がログインできるサーバはあらかじめ決められている。クライアント２−１の利用者はサーバ１−１にのみログインすることができる。また、クライアント２−２の利用者はサーバ１−２にのみログインすることができる。
【００１７】
サーバに登録されたメッセージは定期的に他のサーバに転送される。また、あるサーバで登録されているメッセージが削除された場合には、その旨が他のサーバに通知される。
他のサーバからメッセージが転送されてきた場合には、そのメッセージを自分自身に登録し、他のサーバからメッセージの削除が通知された場合には対応するメッセージを自分自身の中から削除する。
【００１８】
他のサーバからメッセージの入れ物であるフォルダの作成が通知された場合には、そのフォルダを自分自身にそのフォルダを作成し、他のサーバからフォルダの削除が通知された場合にはそのフォルダを自分自身の中から削除する。
このようにして複数のサーバでそれぞれが、同じ内容のメッセージを保持する。
【００１９】
サーバ１−ｎは、ＣＰＵとメモリを備えた一般的な計算機上でサーバプログラムを動作させることで実現される。サーバ１−ｎには図示されない外部記憶装置が記憶され、この外部記憶装置上に記憶されているサーバプログラムが計算機上のメモリにロードされ実行されることでサーバとして機能する。クライアント２−ｎはＣＰＵとメモリを備えた一般的な計算機上でクライアントプログラムを動作させることで、クライアントとして機能する。
【００２０】
図２はサーバ１−ｎの処理のフローを示す図である。図に示す通り、サーバ１−ｎはローカル処理、グローバル処理、インターバル処理の３つの処理を行なう。サーバ１−ｎはクライアント２−ｎから、何らかのリクエストがあった場合には、ローカル処理を行なう。他のサーバからデータが送信されてきた場合にはグローバル処理を行なう。あらかじめ定められたインターバル時間を経過した場合には、インターバル処理を行なう。インターバル時間として１日（２４時間）が指定されている場合は毎日決まった時刻にインターバル処理が実行されることになる。
【００２１】
利用者が電子会議システムを利用する場合は、クライアント２−ｎからサーバ１−ｎにログインする必要がある。ログインが完了するとサーバ１−ｎに対して様々なリクエストを行なうことで、サーバ１−ｎがリクエストに応じた処理を行ない、必要に応じてクライアント２−ｎに対してデータを送信する。この電子会議システムでは、種類の異なる話題のために、メッセージを登録する対象として複数のフォルダを有する。個々のフォルダにはそれぞれ一意の名前が付与され、識別される。例えば、食事に関連したメッセージを登録するためのフォルダに対して″ＦＯＯＤ″という名前が付与され、また、スポーツに関連したメッセージを登録するフォルダに対して″ＳＰＯＲＴＳ″という名前が付与され運用される。
【００２２】
次に、本実施の形態で使用するデータについて説明する。
図１６にメッセージ管理テーブルの構成を示す。メッセージ管理テーブルは登録されたメッセージ毎に、フォルダ名、メッセージＩＤ、発言者名、作成日時、ファイル名、保留情報を管理する。メッセージＩＤはメッセージを識別ための文字列で、メッセージ毎にことなるメッセージＩＤが付与される。メッセージＩＤに関しては後でより詳細に説明する。
【００２３】
フォルダ名はメッセージが登録されるフォルダの名前である。発言者名は、メッセージの発言者、即ちメッセージを作成した利用者のサーバ１−ｎでの利用者名である。作成日時は、利用者からの要求によりサーバ１−ｎでメッセージをファイルに格納した日時である。
【００２４】
メッセージはファイルとして外部記憶装置に格納される。ファイル名はメッセージを格納したファイルのファイル名である。ファイル名はメッセージを格納する際にサーバが自動的に決定する。一つのファイルには一つのメッセージを格納する。
保留情報は、登録されているメッセージを利用者に対して参照可能にするか否かを示す情報で、″ｙｅｓ″または″ｎｏ″のいずれかの値をとる。″ｙｅｓ″の場合には利用者は参照不可能で、″ｎｏ″の場合には利用者は参照可能である。
【００２５】
図２１はメッセージの親子関係とメッセージＩＤとの関係を示す図である。討論の元となるメッセージ、即ち討論の最初のメッセージをトピックメッセージ（または、単にトピック）と呼ぶ。トピックメッセージに対するコメントとなるメッセージをリプライメッセージと呼ぶ。リプライメッセージに対するメッセージも同様にリプライメッセージと呼ぶ。
【００２６】
図２１において、２１１乃至２２２はメッセージで、メッセージ２１１がトピックメッセージである。メッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５はメッセージ２１１（トッピック）に対するリプライメッセージで、メッセージ２１１はメッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５の親メッセージと呼び、メッセージ２１２、メッセージ２１３、メッセージ２１４、メッセージ２１５はメッセージ２１１の子メッセージとも呼ぶ。同様の関係が他のメッセージに対しても同様の関係が成立する。
【００２７】
メッセージＩＤは階層番号と、順序番号と、パス情報で表される。階層番号はメッセージの親子関係の階層の何番目の階層のメッセージであるかを表す数値である。
順序番号は、あるメッセージに対して何番目のリプライメッセージであるかを表す数値である。トピックメッセージの場合は、そのメッセージが登録されるフォルダにおける何番目のメッセージであるかを表す。
【００２８】
順序番号はメッセージを登録するサーバにおいて、登録しようとするメッセージがあるフォルダにおいて何番目のトピックメッセージであるか、または親メッセージに対する何番目のリプライメッセージであるかを表している。同じメッセージに対して別々のサーバでリプライメッセージを登録する場合には、同じ順序番号が使用されるが、次に示すパス情報内のサーバ識別番号によって区別することが可能となる。
【００２９】
パス情報は、親メッセージのパス情報に対してメッセージＩＤを付与したサーバ（即ち、メッセージの登録のリクエストをクライアントから受けたサーバ）のサーバ識別番号と順序番号のペアを付加したものである。トピックメッセージの場合は、親メッセージが存在しないので、パス情報はトピックメッセージを登録したサーバの識別番号と順序番号のペアだけになる。
【００３０】
図１７は利用者履歴情報の構成を示す図である。利用者履歴情報はフォルダ名毎の作成日時情報と、参照メッセージＩＤから構成される。
フォルダに対応して記憶される作成日時は、フォルダに登録されたメッセージのなかで、利用者が参照したメッセージの最新のものの作成日時である。
参照メッセージＩＤは利用者が参照したメッセージのメッセージＩＤが複数記録される。
【００３１】
利用者履歴情報はサーバ１−ｎにログインする利用者毎に管理される。すなわち、一つのサーバに対して複数の利用者履歴情報が存在する。
図１８はフォルダ管理テーブルの構成を示す図である。フォルダ管理テーブルにはフォルダ毎にフォルダに登録されたメッセージの最新の作成日時がフォルダの最終更新日時として記録される。新しいフォルダが作成された場合はこのテーブルに新しいエントリが作成される。また、フォルダが削除された場合には該当するエントリが削除される。
【００３２】
図１９は削除テーブルの構成を示す図である。削除テーブルはクライアントからのリクエストに応じてサーバ内で削除されたメッセージのメッセージＩＤとメッセージが削除された日時とを対応付けて記憶する。また、クライアントからフォルダの削除がリクエストされ、それに応じてフォルダを削除した場合には、メッセージＩＤの代わりにフォルダ名を記憶する。
【００３３】
図２０は新規メッセージテーブルの構成を示す図である。新規メッセージテーブルはクライアントからのリクエストに応じて登録したメッセージの登録先のフォルダ名とメッセージＩＤとを対応付けて記憶する。
図３はサーバのローカル処理のフローを示す図である。サーバはクライアントからのリクエストの種別に応じて、ログイン処理、未読一覧処理、発言処理、削除処理、参照処理等の処理を行なう。
【００３４】
図４はログイン処理のフローを示す図である。ログイン処理はクライアント２−ｎからログインのリクエストがあった場合に実行される。ログイン処理においては、まずログインのリクエストを行なった利用者の利用者履歴情報に格納されているメッセージＩＤの中で、削除テーブルに登録されているメッセージＩＤと一致するものを削除する（ステップＳ４１）。
【００３５】
次に利用者がアクセス対象としているフォルダに新規のメッセージが登録されているか否かをチェックする。新規のメッセージが登録されているか否かはフォルダ管理テーブルに登録されている作成日時と利用者履歴情報内に記憶されている作成日時とを比較し、フォルダ管理テーブルに登録されている作成日時の方が利用者履歴情報内に格納されている作成日時よりも新しい場合に新規のメッセージが登録されていると判定する（ステップＳ４２、及びステップＳ４３）。
【００３６】
新規のメッセージが登録されていた場合は、その旨をクライアントに通知する。この通知により利用者は新規のメッセージが登録されているか否かを知り、登録されているメッセージを参照するか否かの決定を迅速に行なうことができる。図５は、未読一覧処理のフローを示す図である。この処理では、まずステップＳ５１において未読一覧の作成を行なう（ステップＳ５１）。未読一覧は、メッセージ管理テーブルに登録されているメッセージから、保留の値が″ｙｅｓ″となっているメッセージと未読一覧のリクエストを行なった利用者の利用者履歴情報に格納されている参照メッセージＩＤで特定されるメッセージとを取り除いたものである。
【００３７】
未読一覧の作成が終了すると、未読一覧のリクエストを行なったクライアントに対して未読一覧情報を送信する（ステップＳ５１）。図６は参照処理のフローを示す図である。クライアント２−ｎがサーバに対してメッセージの参照のリクエストを行なう場合には、参照しようとするメッセージのメッセージＩＤをサーバ１−ｎに対して通知する。
【００３８】
サーバ１−ｎでは、通知されたメッセージＩＤをキーにメッセージ管理テーブルを検索し、参照しようとするメッセージを格納しているファイルのファイル名を求め、そのファイルからメッセージを読み込み（ステップＳ６１）、参照リクエストを行なったクライアント２−ｎに対してそのメッセージを送信する（ステップＳ６２）。
【００３９】
次に、参照したメッセージの作成日時と、利用者履歴情報内で参照対象のメッセージが格納されているフォルダと対応付けて記憶されている作成日時とを比較し、メッセージの作成日時が利用者履歴情報内の作成日時よりも新しい場合は利用者履歴情報内の作成日時を更新する（ステップＳ６３，Ｓ６４）。図７は発言処理のフローを示す図である。利用者が発言する（メッセージを登録する）場合は、クライアント２−ｎからサーバ１−ｎに対してリクエストを行なうとともに登録使用とするメッセージの内容およびメッセージの登録先となるフォルダの名前をサーバ１−ｎに対して送信する。
【００４０】
クライアント２−ｎから送信されたメッセージをサーバ１−ｎが受信する（ステップＳ７１）と、そのメッセージのメッセージＩＤを生成し（ステップＳ７２）、メッセージを登録する（ステップＳ７３）。メッセージの登録処理に関しては後述する。メッセージの登録が完了すると、登録したメッセージのメッセージＩＤとメッセージを登録したフォルダの名前とを関連付けて新規メッセージテーブルに登録する（ステップＳ７４）。
【００４１】
図８はメッセージ登録処理のフローを示す図である。登録対象のメッセージの内容をファイルに書き込み（ステップＳ８１）、メッセージテーブルにメッセージのメッセージＩＤと、メッセージを登録しようとする（メッセージを作成した）利用者の名前と、メッセージを作成した日時（クライアントからの発言リクエストに起因する登録処理の場合はファイルへの書き込み日時）と、メッセージを格納したファイルのファイル名と、保留情報として″ｎｏ″を書き込む。
【００４２】
次にメッセージを登録したフォルダの最終更新日時をフォルダ管理テーブルから求め、登録したメッセージの作成日時と比較し（ステップＳ８３）、登録したメッセージの作成日時の方が新しい場合にはその作成日時をフォルダ管理テーブルに記録する（ステップＳ８４）。
さらに、討論管理テーブルに登録したメッセージに関連する情報を登録する（ステップＳ８５）。即ち、メッセージがトピックメッセージの場合には、メッセージを登録したフォルダ名と、登録したメッセージの作成日時とメッセージＩＤとを討論管理テーブルに新規に登録する。登録したメッセージがリプライメッセージの場合には討論管理テーブルに登録されている日時とメッセージの作成日時とを比較してメッセージの作成日時のほうが新しい場合は討論管理テーブルの更新日時を更新する。
【００４３】
図９は削除処理のフローを示す図である。メッセージを削除する場合には削除対象のメッセージに関する情報が登録されているエントリをメッセージ管理テーブルから削除し（ステップＳ９１）、メッセージが格納されているファイルを削除する（ステップＳ９２）。次に、削除したメッセージのメッセージＩＤを削除テーブルに登録する（ステップＳ９３）。
【００４４】
更に、削除したメッセージがそのメッセージの属していた討論で最新のものである場合（この場合には、討論管理テーブルに記憶されている討論の更新日時と削除したメッセージの作成日時が一致する）、メッセージを削除した後でのその討論の中での最新のメッセージの作成日時をその討論の更新日時として討論管理テーブルの更新日時を更新する。削除したメッセージがトピックメッセージの場合には討論管理テーブルからエントリを削除する。
【００４５】
また、フォルダの削除がリクエストされた場合には、フォルダに登録されている全てのメッセージに関して上記の削除処理を行なった後に、フォルダ管理テーブルからエントリを削除し、フォルダ名を削除管理テーブルに登録する。
図１０はグローバル処理のフローを示す図である。グローバル処理はサーバ間で保持するメッセージを一致させるために必要な処理の一部で、他のサーバから送信されてきたデータに基づいてサーバ内に新たにデータを登録したり、登録されているデータを削除したりする。
【００４６】
他のサーバから、登録済みのメッセージを削除する旨の通知があった場合、削除対象とされたメッセージを削除する（ステップＳ１００及びステップＳ １０９）。メッセージの削除に関しては図９を用いて説明したとおりである。フォルダの削除に関しても同様に処理する。
他のサーバからトピックメッセージを登録する旨の通知があった場合には、そのメッセージを登録する（ステップＳ １０１、ステップＳ １０９）。メッセージの登録に関しては、図８を用いて説明したとおりである。
【００４７】
他のサーバからリプライメッセージを登録する旨の通知があった場合には、そのリプライメッセージがサーバ内に登録されているか否かを判断し（ステップＳ１０２）、メッセージを登録する（ステップＳ１０６）。さらに、メッセージ管理テーブルの保留情報が″ｙｅｓ″となっているメッセージで、登録したメッセージを親メッセージとするメッセージの保留情報を″ｎｏ″として保留状態を解除する。保留されていたメッセージの保留状態を解除することで、さらに別のメッセージの保留状態を解除可能な場合には同様の処理を行なう（ステップＳ１０７）。
【００４８】
リプライメッセージの登録に際して、親メッセージが登録されていない場合には、親メッセージのメッセージＩＤが削除テーブルに登録されているか否かをチェックし、親メッセージが既に削除されてしまっているのか、それとも何らかの理由により他のサーバからの送信が送れているために未だ登録されていないのかを判断する（ステップＳ１０３）。
【００４９】
すでに親メッセージが削除されている場合には、他のサーバから通知されたメッセージを登録せずに破棄し（ステップＳ１０５）、親メッセージが削除済みではない場合には、通知されたメッセージを保留する（ステップＳ１０４）。
保留処理について図１１を用いて説明する。まずメッセージをファイルに書き込み（ステップＳ１１１），メッセージに関する情報をメッセージ管理テーブルに登録する。
【００５０】
メッセージＩＤ、作成者名、作成日時は他のサーバから通知されたままの値とし、保留情報は″ｙｅｓ″とする。
図１３を用いてインターバル処理について説明する。インターバル処理はサーバ間で保持するメッセージを一致させるために必要な処理の一部と、サーバで保持するデータの量を削減するための定期的な処理である。
【００５１】
まず有効期限切れのメッセージの削除を行なう（ステップＳ１３１）。有効期限切れメッセージ削除処理の詳細については図１４を用いて説明する。
有効期限切れメッセージの削除は個々のメッセージ毎に有効期限切れか否かの判定を行なうのではなく、討論毎にその判定を行なう。すなわち、まず討論の有効期限の計算を行なう（ステップＳ１４１）。討論の有効期限は討論管理テーブルに記憶されている日時に対して、予め定められた日数を加算して得られる日時である。現在の日時がこうして得られた有効期限を超えている場合には、その討論全体のメッセージを削除する（ステップＳ１４２、Ｓ１４３）。個々のメッセージの削除については、図９を用いて説明した通りである。なお、予め定められた日数とは、あるサーバで登録されたメッセージが電子会議システムの全てのサーバに転送されるまでに要する日数や、登録されたメッセージを最低何日間削除せずに残しておくか等の運用上の条件によって定められる日数である。
【００５２】
有効期限切れメッセージの削除が終ると削除情報の削除を行なう（ステップＳ１３２）。削除情報は他のサーバから通知されたメッセージの親メッセージが削除済みであるか否かを判定するため、及び、利用者がログインした際に利用者履歴情報の不要部分を削除するために必要な情報であるが、削除情報はメッセージが削除される度に登録されるため、放置しておくとサーバの資源を圧迫することになるので、不必要な情報を削除する必要がある。
【００５３】
削除情報の削除は、図１５に示す通り、削除テーブルの削除日時が、予め設定されている所定日数を超えている場合に削除テーブルからそのエントリを削除することで行なう（ステップＳ１５１、Ｓ１５２）。
以上説明したデータおよび処理により電子会議システムの効率的な運用が可能となる。
【００５４】
なお、グローバル処理において、他のサーバから受け取ったメッセージの親メッセージがメッセージ管理テーブルに登録されておらず、かつ、親メッセージが削除テーブルにも登録されていない場合に、受け取ったメッセージを保留するようにしたが、図１３に示すように保留することなく直ちに登録してもよい。
図１３に示すフローで受信したメッセージを登録すると、一時的に存在しないメッセージに対するコメントのメッセージが登録されることになるが、削除されるべきでないメッセージが削除されてしまうという問題は解決することができる。
【００５５】
また、グローバル処理において、他のサーバから受け取ったトピックメッセージを登録する場合に無条件に登録するのではなく、トピックメッセージの登録先のフォルダが削除されたものであるか否かを削除テーブルを参照して判断し、フォルダが削除されている場合にのみトピックメッセージを破棄するようにしてもよい。
【００５６】
また、インターバル処理の個々の処理について、全てを一括して行なうのではなく、それぞれの処理を別々のタイミングで実行しても構わない。
【００５７】
【発明の効果】
本発明においては、削除したメッセージのメッセージＩＤおよび削除したフォルダの名前を記憶しておくことで、親メッセージが存在しないリプライメッセージや存在しないフォルダに対するトッピックメッセージが他のサーバから通知された場合に、そのメッセージを破棄してよいか否かを正確に判断することができ、サーバ間でのメッセージの不一致の発生を抑制できる。
【００５８】
利用者履歴情報内の不要な情報は利用者のログインの際に削除するので、メッセージを削除した際には削除したメッセージのメッセージＩＤを記憶しておくだけでよく、記憶領域の効率的な利用と、高速な削除処理という相反する目的を同時に達成する。
また、古くなったメッセージの削除に関しては、討論の流れを無視してメッセージを削除するのではなく、討論の最終のメッセージの作成日時に基づいて討論に属するメッセージの削除を行なうので、討論が長期に渡った場合であっても、討論の初期のメッセージの参照を保証し、かつ、新規にメッセージが登録されない討論については自動的に削除することで、サーバの記憶領域を効率的に利用することができる。
【００５９】
また、メッセージＩＤがメッセージの討論の中での位置を表現することで、討論の中のメッセージが削除された場合であっても、削除されてしまったメッセージがあることがわかり、討論の順序関係が崩れることがない。
【図面の簡単な説明】
【図１】分散型電子会議システムの構成の一例を示す図。
【図２】サーバの処理のフローを示す図。
【図３】ローカル処理のフローを示す図。
【図４】ログイン処理のフローを示す図。
【図５】未読一覧処理のフローを示す図。
【図６】参照処理のフローを示す図。
【図７】発言処理のフローを示す図。
【図８】メッセージ登録処理のフローを示す図。
【図９】削除処理のフローを示す図。
【図１０】グローバル処理のフローを示す図。
【図１１】保留処理のフローを示す図。
【図１２】グローバル処理の第二のフローを示す図。
【図１３】インターバル処理のフローを示す図。
【図１４】有効期限切れメッセージ削除処理のフローを示す図。
【図１５】削除情報削除処理のフローを示す図。
【図１６】メッセージ管理テーブルの構成を示す図。
【図１７】利用者履歴情報の構成を示す図。
【図１８】フォルダ管理テーブルの構成を示す図。
【図１９】削除テーブルの構成を示す図。
【図２０】新規メッセージテーブルの構成を示す図。
【図２１】メッセージの階層とメッセージＩＤの関係を示す図。
【図２２】討論管理テーブルの構成を示す図。
【符合の説明】
１−ｎ：サーバ
２−ｎ：クライアント
３−ｎ：ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）
４：ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）

Claims (2)

1. 複数の利用者がメッセージを登録及び参照し、複数のサーバをお互いに接続することにより実現される分散型の電子会議システムにおいて、
   登録されているメッセージを削除し、参照不可能にするメッセージ削除手段と、
   削除されたメッセージの識別情報を記憶する削除メッセージ情報管理手段と、
   登録対象のメッセージが他のメッセージまたは入れ物に関連付けられたメッセージであって、該関連付けの対象が削除済みの場合には登録対象のメッセージを破棄する手段と、
   登録対象のメッセージが他のメッセージまたは入れ物に関連付けられたメッセージであって、該関連付けの対象が削除済みでない場合には登録対象のメッセージを登録せずに一時保留する手段と、
   関連付けの対象が登録された時点で保留されていたメッセージを登録する手段と
   を備えた電子会議システム。
2. 請求項１記載の電子会議システムであって、さらに、
   利用者毎に登録されているメッセージに関する情報を保持する利用者情報記憶手段と、
   利用者に対する当該電子会議システムによるサービス開始時点で、削除メッセージ情報管理手段に記憶されている内容に基づいて、削除済みメッセージに関する情報を前記利用者情報記憶手段から削除する利用者情報更新手段とを備えた電子会議システム。

Images