(57)【特許請求の範囲】
【請求項１】
ファイルシステムを管理する複数のサーバを含んで構成され、前記ファイルシステムに保持される情報交換先のサーバを特定する宛先に基いて、前記サーバ間で蓄積交換型の通信方式を用いて情報交換を行う電子会議システムにおける宛先矛盾判定装置であって、
前記サーバ間で交換される情報には、情報送信元のサーバを特定する送信元情報が含まれると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定手段を含んで構成されたことを特徴とする電子会議システムにおける宛先矛盾判定装置。
【請求項２】
前記宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバと前記ファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生したと判定する構成である請求項１記載の電子会議システムにおける宛先矛盾判定装置。
【請求項３】
前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、
前記宛先矛盾判定手段は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成である請求項１又は請求項２に記載の電子会議システムにおける宛先矛盾判定装置。
【請求項４】
ファイルシステムを管理する複数のサーバを含んで構成され、前記ファイルシステムに保持される情報交換先のサーバを特定する宛先に基いて、前記サーバ間で蓄積交換型の通信方式を用いて情報交換を行う電子会議システムにおける宛先矛盾修正装置であって、
前記サーバ間で交換される情報には、情報送信元のサーバを特定する送信元情報が含まれると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定手段と、該宛先矛盾判定手段により宛先に矛盾が発生していると判定されたときに、受信した情報に含まれる送信元情報に基いて、前記ファイルシステムに保持される宛先を修正する宛先矛盾修正手段と、を含んで構成されたことを特徴とする電子会議システムにおける宛先矛盾修正装置。
【請求項５】
前記宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバと前記ファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生したと判定する構成である請求項４記載の電子会議システムにおける宛先矛盾修正装置。
【請求項６】
前記宛先矛盾修正手段は、前記ファイルシステムに保持される宛先に、受信した情報に含まれる送信元情報により特定されるサーバを追加する構成である請求項４又は請求項５に記載の電子会議システムにおける宛先矛盾修正装置。
【請求項７】
前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、
前記宛先矛盾判定手段は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成である請求項４〜請求項６のいずれか１つに記載の電子会議システムにおける宛先矛盾修正装置。
【請求項８】
ファイルシステムを管理する複数の管理機能を含んで構成され、コンピュータに、前記ファイルシステムに保持される情報交換先の管理機能を特定する宛先に基いて、前記管理機能間で蓄積交換型の通信方式を用いて情報交換を行わせる電子会議システムにおける宛先矛盾判定プログラムを記録したコンピュータ読取可能な記録媒体であって、
コンピュータに、前記管理機能間で交換される情報には、情報送信元の管理機能を特定する送信元情報が含まれると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能を実現するための電子会議システムにおける宛先矛盾判定プログラムを記録したコンピュータ読取可能な記録媒体。
【請求項９】
前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、
前記宛先矛盾判定機能は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成である請求項８記載の電子会議システムにおける宛先矛盾判定プログラムを記録したコンピュータ読取可能な記録媒体。
【請求項１０】
ファイルシステムを管理する複数の管理機能を含んで構成され、コンピュータに、前記ファイルシステムに保持される情報交換先の管理機能を特定する宛先に基いて、前記管理機能間で蓄積交換型の通信方式を用いて情報交換を行わせる電子会議システムにおける宛先矛盾修正プログラムを記録したコンピュータ読取可能な記録媒体であって、
コンピュータに、前記管理機能間で交換される情報には、情報送信元の管理機能を特定する送信元情報が含まれると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能と、該宛先矛盾判定機能により宛先に矛盾が発生していると判定されたときに、受信した情報に含まれる送信元情報に基いて、前記ファイルシステムに保持される宛先を修正する宛先矛盾修正機能と、を実現するための電子会議システムにおける宛先矛盾修正プログラムを記録したコンピュータ読取可能な記録媒体。
【請求項１１】
前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、
前記宛先矛盾判定機能は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成である請求項１０記載の電子会議システムにおける宛先矛盾修正プログラムを記録したコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、蓄積交換型電子会議システムに関し、特に、情報交換先を定義する宛先に矛盾が発生したときに、これを自動的に判定し或いは修正する技術に関する。
【０００２】
【従来の技術】
一般的に、電子会議システムとは、不特定多数の利用者が情報交換を行うために構築されるシステムをいう。大規模な電子会議システムでは、地理的に離れた地域（以下「サイト」という）毎に電子会議システムを利用できる利用者を登録する。そして、登録された利用者は、そのサイトのみを利用することができる。
【０００３】
かかる電子会議システムでは、一般的に、各サイト間を接続する通信回線の通信速度等を考慮して、蓄積交換型の通信方式が採用される。即ち、各サイトの利用者が発生させた情報は、送信する情報を蓄積する機構に蓄積され、所定期間毎にまとめて他のサイトに送信される。一方、他のサイトでは、受信した情報は、受信した情報を蓄積する機構に一旦蓄積され、処理能力に余裕ができたバックグラウンドで処理される。
【０００４】
電子会議システムでは、通常、フォーラムと呼ばれる入れ物で単位付けられている。また、各フォーラム毎に、情報交換を行う相手先となるサイトの宛先情報が保持される。例えば、図２８に示すように、サイトＡ、Ｂ及びＣにおけるフォーラムＡの間で相互に情報交換を行う場合、サイトＡのフォーラムＡにはサイトＢ及びＣが、サイトＢのフォーラムＡにはサイトＡ及びＣが、サイトＣのフォーラムＡにはサイトＡ及びＢが、夫々宛先情報として登録される。そして、サイトＡで情報が発生したときには、登録されている宛先情報に基づいて、情報がサイトＢ及びＣに夫々送信される。
【０００５】
【発明が解決しようとする課題】
ところで、各サイトのフォーラムに登録されている宛先情報は、情報交換先の追加或いは削除によって変更されることがある。例えば、サイトＡとサイトＢとの間で情報交換が行われていない場合に、サイトＡのフォーラムＡにおいて、サイトＢのフォーラムＡとの間で情報交換を開始したいときには、サイトＡからサイトＢにその旨が通知される。これを受け取ったサイトＢでは、フォーラムＡの宛先情報にサイトＡが追加される。一方、サイトＡとサイトＢとの間で情報交換が行われている場合に、サイトＡのフォーラムＡにおいて、サイトＢとの間の情報交換を中止したいときには、サイトＡからサイトＢにその旨が通知される。これを受け取ったサイトＢでは、フォーラムＡの宛先情報からサイトＡが削除される。
【０００６】
しかしながら、蓄積交換型の通信方式を採用しているため、各サイトのフォーラムにおける宛先情報の変更が他のサイトでリアルタイムに反映されず、宛先情報に矛盾が発生することがある。例えば、図２８の状態が正常である場合に、サイトＡにおいて、何らかの原因（例えば、停電等による電源の遮断）によって、フォーラムＡの宛先情報が消去されてしまい、リカバリディスクの内容に基づいてフォーラムＡの宛先情報を復旧したところ、リカバリディスクの内容が古いために、図２９に示すように、サイトＡのフォーラムＡにおける宛先情報がサイトＢのみとなってしまう場合が考えられる。即ち、サイトＡのフォーラムＡでは、宛先情報はサイトＢのみであるのに対し、サイトＣのフォーラムＡでは、宛先情報としてサイトＡが保持されている。このため、サイトＣからサイトＡに情報が送信されるが、サイトＡからサイトＣに情報が送信されないという矛盾が発生してしまう。
【０００７】
かかる宛先矛盾が発生しても、従来の技術では発見が難しく、電子会議システムの管理者は、長期間矛盾発生に気が付かないことが多かった。従って、各サイト間で交換される情報が大して重要でない場合には支障が少ないが、情報が極めて重要であり、或いは、迅速な処理が要求される場合には、宛先矛盾の発生によって情報が送信されないという事態は、致命的なものとなってしまうおそれがあった。
【０００８】
そこで、本発明は以上のような従来の問題点に鑑み、宛先情報に矛盾が発生したときに、これを自動的に判定し或いは自動的に修正し、送信されるべき情報が送信されないという不具合を解消することを目的とする。
【０００９】
【課題を解決するための手段】
このため、請求項１記載の発明は、ファイルシステムを管理する複数のサーバを含んで構成され、前記ファイルシステムに保持される情報交換先のサーバを特定する宛先に基いて、前記サーバ間で蓄積交換型の通信方式を用いて情報交換を行う電子会議システムにおける宛先矛盾判定装置であって、前記サーバ間で交換される情報には、情報送信元のサーバを特定する送信元情報を含ませると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定手段を含んで構成した。
【００１０】
かかる構成によれば、サーバＡとサーバＢとの間で情報交換を行う場合、サーバＡのファイルシステムには、情報交換先のサーバＢが宛先として保持される一方、サーバＢのファイルシステムには、情報交換先のサーバＡが宛先として保持される。この状態において、例えば、サーバＡにおいてファイルシステムに障害が発生し、サーバＡのファイルシステムに保持されている情報交換先の宛先が消去されると、サーバＡからサーバＢへは情報が伝達されなくなる。この場合、サーバＢからサーバＡへは情報が伝達されるので、サーバＡにおいて、宛先矛盾判定手段によって、サーバＡのファイルシステムに保持される宛先（宛先なし）と受信した情報に含まれる送信元情報（サーバＢ）とに基いて宛先に矛盾が発生したと判定される。
【００１１】
請求項２記載の発明は、前記宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバと前記ファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生したと判定する構成とした。
かかる構成によれば、宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバとファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生したと判定するので、宛先矛盾の判定が極めて簡単に行われる。
請求項３記載の発明は、前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、前記宛先矛盾判定手段は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成とした。
かかる構成によれば、情報交換を行う単位となるフォーラムごとに、宛先に矛盾が発生しているか否かが判定される。
【００１２】
請求項４記載の発明は、ファイルシステムを管理する複数のサーバを含んで構成され、前記ファイルシステムに保持される情報交換先のサーバを特定する宛先に基いて、前記サーバ間で蓄積交換型の通信方式を用いて情報交換を行う電子会議システムにおける宛先矛盾修正装置であって、前記サーバ間で交換される情報には、情報送信元のサーバを特定する送信元情報を含ませると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定手段と、該宛先矛盾判定手段により宛先に矛盾が発生していると判定されたときに、受信した情報に含まれる送信元情報に基いて、前記ファイルシステムに保持される宛先を修正する宛先矛盾修正手段と、を含んで構成した。
【００１３】
かかる構成によれば、サーバＡとサーバＢとの間で情報交換を行う場合、サーバＡのファイルシステムには、情報交換先のサーバＢが宛先として保持される一方、サーバＢのファイルシステムには、情報交換先のサーバＡが宛先として保持される。この状態において、例えば、サーバＡにおいてファイルシステムに障害が発生し、サーバＡのファイルシステムに保持されている情報交換先の宛先が消去されると、サーバＡからサーバＢへは情報が伝達されなくなる。この場合、サーバＢからサーバＡへは情報が伝達されるので、サーバＡにおいて、宛先矛盾判定手段によって、サーバＡのファイルシステムに保持される宛先（宛先なし）と受信した情報に含まれる送信元情報（サーバＢ）とに基いて宛先に矛盾が発生したと判定される。そして、宛先に矛盾が発生したと判定されると、宛先矛盾修正手段によって、受信した情報に含まれる送信元情報に基いて、ファイルシステムに保持される宛先が修正される。
【００１４】
請求項５記載の発明は、前記宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバと前記ファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生していると判定する構成とした。
かかる構成によれば、宛先矛盾判定手段は、受信した情報に含まれる送信元情報により特定されるサーバとファイルシステムに保持される宛先により特定されるサーバとが不一致のときに、宛先に矛盾が発生したと判定するので、宛先矛盾の判定が極めて簡単に行われる。
【００１５】
請求項６記載の発明は、前記宛先矛盾修正手段は、前記ファイルシステムに保持される宛先に、受信した情報に含まれる送信元情報により特定されるサーバを追加する構成とした。
かかる構成によれば、宛先矛盾修正手段は、ファイルシステムに保持される宛先に、受信した情報に含まれる送信元情報により特定されるサーバを追加するだけであるので、宛先矛盾の修正が極めて簡単に行われる。
請求項７記載の発明は、前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、前記宛先矛盾判定手段は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成とした。
かかる構成によれば、情報交換を行う単位となるフォーラムごとに、宛先に矛盾が発生しているか否かが判定される。
【００２０】
請求項８記載の発明は、ファイルシステムを管理する複数の管理機能を含んで構成され、コンピュータに、前記ファイルシステムに保持される情報交換先の管理機能を特定する宛先に基いて、前記管理機能間で蓄積交換型の通信方式を用いて情報交換を行わせる電子会議システムにおける宛先矛盾判定プログラムを記録したコンピュータ読取可能な記録媒体であって、前記管理機能間で交換される情報には、情報送信元の管理機能を特定する送信元情報を含ませると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能を含んで構成した。
請求項９記載の発明は、前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、前記宛先矛盾判定機能は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成とした。
【００２１】
ここで、「媒体」とは、各種情報を確実に記録でき、かつ、必要に応じて確実に取り出し可能なものをいい、具体的には、紙カード（パンチカード）、紙テープ、磁気テープ、磁気ディスク、磁気ドラム、ＣＤ−ＲＯＭ、ＩＣカード等がある。
かかる構成によれば、ファイルシステムを管理する複数の管理機能と、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能と、を実現するためのプログラムを媒体に記録したので、このプログラムを記録した媒体があれば、本発明に係る宛先矛盾判定装置が容易に構築される。
【００２２】
請求項１０記載の発明は、ファイルシステムを管理する複数の管理機能を含んで構成され、コンピュータに、前記ファイルシステムに保持される情報交換先の管理機能を特定する宛先に基いて、前記管理機能間で蓄積交換型の通信方式を用いて情報交換を行わせる電子会議システムにおける宛先矛盾修正プログラムを記録したコンピュータ読取可能な記録媒体であって、前記管理機能間で交換される情報には、情報送信元の管理機能を特定する送信元情報を含ませると共に、前記ファイルシステムに保持される宛先と受信した情報に含まれる送信元情報とに基いて、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能と、該宛先矛盾判定機能により宛先に矛盾が発生していると判定されたときに、受信した情報に含まれる送信元情報に基いて、前記ファイルシステムに保持される宛先を修正する宛先矛盾修正機能と、を含んで構成した。
請求項１１記載の発明は、前記ファイルシステムには、情報交換を行う単位となるフォーラムごとに情報交換を行う宛先が登録され、前記宛先矛盾判定機能は、前記フォーラムごとに宛先に矛盾が発生しているか否かを判定する構成とした。
【００２３】
かかる構成によれば、ファイルシステムを管理する複数の管理機能と、宛先に矛盾が発生しているか否かを判定する宛先矛盾判定機能と、ファイルシステムに保持される宛先を修正する宛先矛盾修正機能と、を実現するためのプログラムを媒体に記録したので、このプログラムを記録した媒体があれば、本発明に係る宛先矛盾修正装置が容易に構築される。
【００２４】
【発明の実施の形態】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明に係る電子会議システムを、地理的に離れた４つのサイトＡ，Ｂ，Ｃ及びＤ間で実現した一実施形態のシステム構成を示す。即ち、電子会議システムは、サイトＡ，Ｂ，Ｃ及びＤ間を通信回線で相互に接続したクライアント／サーバモデルで実現される。なお、サーバ及びクライアントは、少なくとも中央処理装置（ＣＰＵ）とメモリとを備え、メモリ上のプログラムを実行する計算機である。
【００２５】
各サイトは、１つのサーバ１０（管理工程、管理機能）と、少なくとも１つのクライアント３０と、を含んで夫々構成される。各サイト間は、通信回線４０を介して相互に接続され、また、通信回線４０の通信速度等を考慮して、蓄積交換型の通信方式によって情報交換が行われる。即ち、サイトＡのクライアント３０で発生した情報は、情報発生と同時にサイトＢ，Ｃ及びＤに送信されるのではなく、サイトＡで送信する情報を蓄積し、所定期間毎にまとめて送信される。
【００２６】
サーバ１０は、データベース１２（ファイルシステム）と、サーバソフト１４と、コマンドキュー１６と、送信キュー１８と、受信キュー２０と、を含んで構成される。サーバソフト１４は、データベース１２の参照及び更新等を行う。コマンドキュー１６は、サイトで発生した情報の操作内容を蓄積する。送信キュー１８は、他のサイトへ送信する情報を蓄積する。受信キュー２０は、他のサイトから受信した情報を蓄積する。コマンドキュー１６、送信キュー１８及び受信キュー２０は、ＦＩＦＯ（First In First Out）型の待ち行列を形成するファイルにより夫々構成される。
【００２７】
なお、サーバソフト１４は、宛先矛盾判定手段、宛先矛盾修正手段、宛先矛盾判定工程、宛先矛盾修正工程、宛先矛盾判定機能、宛先矛盾修正機能、としても作用する。
データベース１２には、情報交換を行う単位（入れ物）となるフォーラムが作成される。フォーラムは、図２に示すように、階層構造をとることができ、最上位のフォーラムＡは「メインフォーラム」、その他のフォーラムＢ1 ，Ｂ2 ，Ｃは「サブフォーラム」と呼ばれる。なお、サブフォーラムは、同一階層に複数設定することができ、図２においては、フォーラムＢ1 とフォーラムＢ2 とは、同一階層のフォーラムとなる。
【００２８】
各フォーラムには、図３に示すように、階層構造のメッセージが含まれる。最上位のメッセージＡは「トピック」と呼ばれ、例えば、「・・・について」のように主題（表題）が提起される。その他のメッセージＢ，Ｃ1 ，Ｃ2 ，Ｄは「リプライ」と呼ばれ、あるメッセージに対する返答が行われる。なお、あるメッセージに対する返答は、複数行うことができ、図３においては、メッセージＢに対する返答は、メッセージＣ1 及びＣ2 となる。
【００２９】
フォーラムが作成されたサイトには、フォーラムの原型（オリジナル）が格納され、他のサイトには、フォーラムの複製（レプリカ）が格納される。そして、電子会議システムにおけるフォーラムの利用者は、自分が属するサイトのフォーラム（原型か複製かを問わない）に対してメッセージの作成等の処理を行う。フォーラムに対して行った処理は、蓄積交換型の通信方式により、通信回線４０を介して他のサイトに伝達され、他のサイトのフォーラムに反映される。即ち、各サイトにおけるフォーラムの内容には、時間的なずれが生じている。
【００３０】
データベース１２の内容をさらに詳しく説明すると、図４に示すように、データベース１２には、フォーラムを定義するフォーラムオブジェクト５０と、メッセージを定義するメッセージオブジェクト５２と、電子会議システムの利用者（ユーザー）を定義するユーザーオブジェクト５４と、サイトを示すサイトオブジェクト５６と、が含まれる。各オブジェクトは、電子会議システム全体で、ユニークなオブジェクトＩＤ（識別番号）が付される。即ち、オブジェクトＩＤは、電子会議システム全体で設定されるユニークなサーバＩＤと、各サイトのオブジェクト毎に設定されるユニークなＩＤと、によって決定される。例えば、３２ビットでオブジェクトＩＤを表わす場合には、図５に示すように、上位１６ビットにサーバＩＤを、下位１６ビットに各サイトのオブジェクト毎に設定されるＩＤを、設定することで、電子会議システム全体において、オブジェクトＩＤがユニークなものとなる。
【００３１】
フォーラムオブジェクト５０には、フォーラムの名前、作成者、作成日及び説明文と、フォーラムの階層構造を定義する構造情報と、が含まれる。構造情報には、１階層上のフォーラムオブジェクトを示すオブジェクトＩＤと、最上位のメインフォーラムオブジェクトを示すオブジェクトＩＤと、が含まれる。
メッセージオブジェクト５２には、主題（表題「・・・について」）、作成者、作成日及びメッセージ本文（メッセージの内容）と、メッセージの階層構造を定義する構造情報と、が含まれる。構造情報には、どのメッセージに対する返答であるかを示す１階層上のメッセージオブジェクトのオブジェクトＩＤと、どのトピックに属するかを示すトピックオブジェクトのオブジェクトＩＤと、どのフォーラムに属するかを示すフォーラムオブジェクトのオブジェクトＩＤと、が含まれる。
【００３２】
ユーザーオブジェクト５４には、データベース１２を利用可能なクライアント３０のクライアント名と、各クライアント３０がログオンするためのパスワード等の情報と、が含まれる。従って、クライアント３０からデータベース１２の参照要求があったときには、ユーザーオブジェクト５４の内容を調べて、そのクライアント３０にはデータベース１２の参照権限があるのか等を判断することができる。
【００３３】
サイトオブジェクト５６には、データベース１２を利用可能なクライアント３０を示すクライアントＩＤと、利用可能な他のサイトを示すオブジェクトＩＤと、が含まれる。
また、各フォーラムには、どのサイトと情報交換を行うかを定義する宛先情報が登録される。例えば、図６に示すように、サイトＡとサイトＢとのフォーラムＡの間で情報交換を行う場合、サイトＡのフォーラムＡには宛先情報５８としてサイトＢが、サイトＢのフォーラムＡには宛先情報５８としてサイトＡが登録される。従って、サイトＡで発生した情報は、登録された宛先情報５８を参照することで、どのサイトに送信するかが判断され、情報はサイトＢに送信されることとなる。
【００３４】
ここで、かかる構成からなる電子会議システムの作用について説明する。
先ず、サイト間で行われる情報交換の概略について、図７の処理流れ図を参照しつつ説明する。なお、図７に示す電子会議システムでは、説明の便宜上、サイトＡとサイトＢとの間で情報交換が行われるものとする。
電子会議システムの利用者が、例えば、サイトＡのクライアント３０からフォーラムやメッセージ（以下「オブジェクト」という）の作成、削除、更新或いは移動を行うと、サイトＡのサーバソフト１４は、サイトＡのデータベース１２に対して、オブジェクトの操作に応じた登録処理を行う（処理▲１▼）。これと同時に、サーバソフト１４は、データベース１２から操作対象のオブジェクトのオブジェクトＩＤ等を検索し（処理▲２▼）、後述するコマンドオブジェクトを作成して、コマンドキュー１６にコマンドオブジェクトを登録する（処理▲３▼）。
【００３５】
なお、コマンドオブジェクトは、操作の種類（オブジェクトの作成、削除、更新或いは移動）と、情報が発生したサイトを示すオブジェクトＩＤと、情報を送信する宛先としてのサイトを示すオブジェクトＩＤと、操作対象としてのオブジェクトを示すオブジェクトＩＤと、各操作固有の情報（例えば、オブジェクトの移動の場合には、移動元と移動先を示す情報）と、を含んで構成される。
【００３６】
コマンドキュー１６に登録されたコマンドオブジェクトは、サーバ１０の処理能力に余裕ができたバックグラウンドで、コマンドキュー１６から取り出される（処理▲４▼）。そして、必要に応じて、処理対象のオブジェクトの本体（例えば、メッセージの場合には本文）がデータベース１２から検索され（処理▲５▼）、コマンドオブジェクト及び処理対象のオブジェクト本体（以下「送信情報」という）が送信キュー１８に登録される（処理▲６▼）。このとき、送信情報の最適化処理及び順番保証処理が行われる。即ち、情報の最適化処理とは、コマンドキュー１６に登録されたコマンドオブジェクトの内、実質的に何の作用も行わないコマンドオブジェクトを削除して、情報伝達量を最小にする処理である。また、情報の順番保証処理とは、蓄積交換型の通信方式に起因する情報伝達の順番に矛盾が生じないようにする処理である。
【００３７】
送信キュー１８に登録された送信情報は、所定期間毎に、送信キュー１８から取り出される。そして、取り出された送信情報に含まれる宛先としてのサイトを示すオブジェクトＩＤに基づいて送信先が決定され、送信情報は、通信回線４０を介してサイトＢに送信される（処理▲７▼）。ここで、所定期間は、電子会議システムの管理者が任意に設定でき、例えば、通信回線４０に余裕がある深夜や早朝に、送信情報が通信されるように設定される。
【００３８】
一方、サイトＡからサイトＢに送信された送信情報は、サイトＢにおいて直ぐに処理されず、受信キュー２０に一旦蓄積される。そして、受信キュー２０に蓄積された送信情報は、サイトＢのサーバ１０のバックグラウンドで、受信キュー２０から取り出され（処理▲８▼）、送信情報に応じてデータベース１２への登録処理が行われる（処理▲９▼）。このとき、情報交換先の宛先矛盾の判定及び修正処理、情報内容の矛盾判定及び修正処理、オブジェクトの移動処理等が行われる。即ち、宛先矛盾の判定及び修正処理とは、送信情報を受信したサイトで登録される宛先情報５８に矛盾が発生したとき、これを自動的に判定し或いは修正する処理である。また、情報内容の矛盾判定及び修正処理とは、送信情報を受信したサイトで登録される情報内容に矛盾が発生したとき、これを自動的に判定し或いは修正する処理である。さらに、オブジェクトの移動処理とは、情報伝達経路が異なるフォーラム間でオブジェクトの移動があった場合に、情報伝達の順番に関わらず移動処理が正しく行われるようにする処理である。
【００３９】
この他には、各サイトのサーバ１０において、何らかの原因（例えば、停電等による電源の遮断）によってシステムダウン等の障害が発生した場合に、サーバ１０を障害発生直前の状態に戻すためのリカバリディスクの作成が行われる。リカバリディスクの作成は、各サイトにおいて、受信キュー２０から送信情報を取り出して処理する際、或いは、システム管理者の明示の指示に基づいて行われる。そして、システムダウン等の障害が発生したときには、システム管理者の手動操作により、リカバリディスクの内容に基づいて、サーバ１０が障害発生直前の状態に復旧され、情報交換の支障を極力小さくする。
【００４０】
以上説明した情報交換は、サーバソフト１４がソフトウエア的に実行する処理によって実現される。
図８〜図１２は、各サイトにおいて、クライアント３０からサーバ１０に対して、オブジェクトの作成、削除、更新或いは移動の処理要求があったときに、実行される処理を示す。
【００４１】
図８は、メインルーチンである。
ステップ１（図では「Ｓ１」と略記する。以下同様) では、クライアント３０からの処理要求がオブジェクトの作成であるか否かを判断する。そして、処理要求がオブジェクトの作成であればステップ１０へと進み（Ｙｅｓ）、オブジェクトの作成処理を行うサブルーチン（図９参照）を実行する。一方、処理要求がオブジェクトの作成でなければステップ２へと進む（Ｎｏ）。
【００４２】
ステップ２では、クライアント３０からの処理要求がオブジェクトの削除であるか否かを判断する。そして、処理要求がオブジェクトの削除であればステップ２０へと進み（Ｙｅｓ）、オブジェクトの削除処理を行うサブルーチン（図１０参照）を実行する。一方、処理要求がオブジェクトの削除でなければステップ３へと進む（Ｎｏ）。
【００４３】
ステップ３では、クライアント３０からの処理要求がオブジェクトの更新であるか否かを判断する。そして、処理要求がオブジェクトの更新であればステップ３０へと進み（Ｙｅｓ）、オブジェクトの更新処理を行うサブルーチン（図１１参照）を実行する。一方、処理要求がオブジェクトの更新でなければステップ４へと進む（Ｎｏ）。
【００４４】
ステップ４では、クライアント３０からの処理要求がオブジェクトの移動であるか否かを判断する。そして、処理要求がオブジェクトの移動であればステップ４０へと進み（Ｙｅｓ）、オブジェクトの移動処理を行うサブルーチン（図１２参照）を実行する。一方、処理要求がオブジェクトの移動でなければステップ５へと進む（Ｎｏ）。
【００４５】
ステップ５では、クライアント３０からの処理要求がオブジェクトの作成、削除、更新或いは移動のいずれでもないので、処理要求はエラーであると判断し、例えば、クライアント３０を操作する利用者に、操作がエラーであるとの旨を表示する等のエラー処理を実行する。
図９は、オブジェクトの作成処理を行うサブルーチンである。
【００４６】
ステップ１１では、オブジェクトの作成要求を発生したクライアント３０が属するサイトにおいて、データベース１２にオブジェクトを作成する。
ステップ１２では、オブジェクトの作成が成功したか否かを判断する。そして、作成が成功したときにはステップ１３へと進み（Ｙｅｓ）、作成が失敗したときにはステップ１４へと進む（Ｎｏ）。
【００４７】
ステップ１３では、オブジェクトの作成を示すコマンドオブジェクトを作成し、コマンドキュー１６にコマンドオブジェクトを登録する。
ステップ１４では、オブジェクトの作成が失敗したので、例えば、クライアント３０の操作者に、オブジェクトの作成が失敗した旨を表示する等のエラー処理を実行する。
【００４８】
図１０は、オブジェクトの削除処理を行うサブルーチンである。
ステップ２１では、オブジェクトの削除要求を発生したクライアント３０が属するサイトにおいて、データベース１２からオブジェクトを削除する。
ステップ２２では、オブジェクトの削除が成功したか否かを判断する。そして、削除が成功したときにはステップ２３へと進み（Ｙｅｓ）、削除が失敗したときにはステップ２４へと進む（Ｎｏ）。
【００４９】
ステップ２３では、オブジェクトの削除を示すコマンドオブジェクトを作成し、コマンドキュー１６にコマンドオブジェクトを登録する。
ステップ２４では、オブジェクトの削除が失敗したので、例えば、クライアント３０の操作者に、オブジェクトの削除が失敗した旨を表示する等のエラー処理を実行する。
【００５０】
図１１は、オブジェクトの更新処理を行うサブルーチンである。
ステップ３１では、オブジェクトの更新要求を発生したクライアント３０が属するサイトにおいて、データベース１２のオブジェクトを更新する。
ステップ３２では、オブジェクトの更新が成功したか否かを判断する。そして、更新が成功したときにはステップ３３へと進み（Ｙｅｓ）、更新が失敗したときにはステップ３４へと進む（Ｎｏ）。
【００５１】
ステップ３３では、オブジェクトの更新を示すコマンドオブジェクトを作成し、コマンドキュー１６にコマンドオブジェクトを登録する。
ステップ３４では、オブジェクトの更新が失敗したので、例えば、クライアント３０の操作者に、オブジェクトの更新が失敗した旨を表示する等のエラー処理を実行する。
【００５２】
図１２は、オブジェクトの移動処理を行うサブルーチンである。
ステップ４１では、オブジェクトの移動要求を発生したクライアント３０が属するサイトにおいて、データベース１２のオブジェクトを移動する。
ステップ４２では、オブジェクトの移動が成功したか否かを判断する。そして、移動が成功したときにはステップ４３へと進み（Ｙｅｓ）、移動が失敗したときにはステップ４６へと進む（Ｎｏ）。
【００５３】
ステップ４３では、オブジェクトの移動は同一メインフォーラム内であるか否かを判断する。そして、同一メインフォーラム内の移動であればステップ４４へと進み（Ｙｅｓ）、同一メインフォーラム内の移動でなければステップ４５へと進む（Ｎｏ）。
ステップ４４では、オブジェクトの移動を示すコマンドオブジェクトを作成し、コマンドキュー１６にコマンドオブジェクトを登録する。
【００５４】
ステップ４５では、オブジェクトの作成及び削除を示すコマンドオブジェクトを夫々作成し、コマンドキュー１６にコマンドオブジェクトを夫々登録する。即ち、オブジェクトの移動処理を、オブジェクトの作成処理と削除処理とで代替することによって、後述する不都合を回避する。
ステップ４６では、オブジェクトの移動が失敗したので、例えば、クライアント３０の操作者に、オブジェクトの移動が失敗した旨を表示する等のエラー処理を実行する。
【００５５】
以上説明した図８〜図１２の処理によれば、クライアント３０からオブジェクトの作成、削除、更新或いは移動の処理要求があると、処理要求内容を解析して、夫々の処理を行うサブルーチンが実行される。各処理を実行するサブルーチンでは、オブジェクトの処理要求が発生したサイトにおいて、リアルタイムにオブジェクトの処理が実行される一方、処理内容を示すコマンドオブジェクトがコマンドキュー１６に登録される。
ここで、図１２に示す移動処理を行うのは、次の理由による。
【００５６】
あるサイトには、図１３に示すように、メインフォーラムＡのみからなるグループ６０と、メインフォーラムＢ及びサブフォーラムＣとからなる階層構造のグループ６２と、が存在すると仮定する。この状態において、例えば、グループ６２のサブフォーラムＣを、グループ６０のメインフォーラムＡの下層に移動する場合を考える。メインフォーラムＡの下層にサブフォーラムＣが移動するということは、グループ６０にとっては、サブフォーラムＣの作成であり、一方、グループ６２にとっては、サブフォーラムＣの削除であるに過ぎない。即ち、異なるグループ間におけるオブジェクトの移動は、必ずしもオブジェクトの移動として捉えることができず、図１２のステップ４３〜ステップ４５のように、同一メインフォーラム内の移動か否かによって、処理を分ける必要が生じるのである。
【００５７】
図１４〜図２０は、各サイトにおいて、サーバ１０のバックグラウンドでコマンドキュー１６からコマンドオブジェクトを取り出し、これを送信キュー１８に登録する際に実行される処理を示す。なお、図１５〜図１９の処理が情報の最適化処理であり、また、図２０の処理が情報の順番保証処理である。
図１４は、メインルーチンである。
【００５８】
ステップ５０では、情報の最適化処理を行うサブルーチンを実行する。
ステップ１２０では、情報の順番保証処理を行うサブルーチンを実行する。
図１５は、情報の最適化処理を行うサブルーチンである。
ステップ５１では、コマンドキュー１６に登録されているコマンドオブジェクトを読み込み、メモリ上に展開する。即ち、メモリ上にコマンドキュー１６の複製を作成する。
【００５９】
ステップ５２では、メモリ上に展開されたコマンドキュー（以下「メモリ上のコマンドキュー」という）の最新の項目（コマンドオブジェクトのことをいう。以下同様）からサーチを開始する。即ち、第１回目の処理では最新の項目に着目し、第２回目以降の処理では順次次の項目に着目する。
ステップ５３では、着目している項目がメッセージの削除を示すコマンドオブジェクトであるか否かを判断する。かかる判断（メッセージの更新、フォーラムの削除或いは更新か否かの判断も含む）は、コマンドオブジェクトに含まれる操作の種類を調べることによって行われる。そして、メッセージの削除であるときにはステップ６０へと進み（Ｙｅｓ）、メッセージの削除に係るキュー処理を行うサブルーチン（図１６）を実行する。一方、メッセージの削除でないときにはステップ５４へと進む（Ｎｏ）。
【００６０】
ステップ５４では、着目している項目がメッセージの更新を示すコマンドオブジェクトであるか否かを判断する。そして、メッセージの更新であるときにはステップ８０へと進み（Ｙｅｓ）、メッセージの更新に係るキュー処理を行うサブルーチン（図１７）を実行する。一方、メッセージの更新でないときにはステップ５５へと進む（Ｎｏ）。
【００６１】
ステップ５５では、着目している項目がフォーラムの削除を示すコマンドオブジェクトであるか否かを判断する。そして、フォーラムの削除であるときにはステップ９０へと進み（Ｙｅｓ）、フォーラムの削除に係るキュー処理を行うサブルーチン（図１８）を実行する。一方、フォーラムの削除でないときにはステップ５６へと進む（Ｎｏ）。
【００６２】
ステップ５６では、着目している項目がフォーラムの更新を示すコマンドオブジェクトであるか否かを判断する。そして、フォーラムの更新であるときにはステップ１１０へと進み（Ｙｅｓ）、フォーラムの更新に係るキュー処理を行うサブルーチン（図１９）を実行する。一方、フォーラムの更新でないときにはステップ５７へと進む（Ｎｏ）。
【００６３】
ステップ５７では、メモリ上のコマンドキューに含まれる全ての項目を処理したか否かが判断される。そして、全ての項目が処理されたときには本ルーチンを終了し（Ｙｅｓ）、全ての項目が処理されていないときにはステップ５１へと戻る（Ｎｏ）。
図１６は、情報の最適化処理において実行されるメッセージの削除に係るキュー処理を行うサブルーチンである。
【００６４】
ステップ６１では、メモリ上のコマンドキューにメッセージの作成を示すコマンドオブジェクトが登録されているか否かを示すフラグ（Ｆｌａｇ）を、「０」に設定する初期化を行う。
ステップ６２では、メモリ上のコマンドキューにおいて、削除対象のメッセージと同一のオブジェクトＩＤを有する項目を、削除対象のメッセージの次の項目からサーチする。即ち、第１回目の処理では削除対象のメッセージの次の項目に着目し、第２回目以降の処理では順次次の項目に着目する。
【００６５】
ステップ６３では、着目している項目がメッセージの作成を示すコマンドオブジェクトであるか否かを判断する。そして、メッセージの作成であるときにはステップ６４へと進み（Ｙｅｓ）、フラグを「１」に設定する。一方、メッセージの作成でないときにはステップ６５へと進む（Ｎｏ）。
ステップ６５では、着目している項目がメッセージの更新を示すコマンドオブジェクトであるか否かを判断する。そして、メッセージの更新であるときにはステップ６６へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からメッセージの更新を示すコマンドオブジェクトを削除する。一方、メッセージの更新でないときにはステップ６７へと進む（Ｎｏ）。
【００６６】
ステップ６７では、削除対象のメッセージはトピックであるか否かを判断する。かかる判断は、コマンドオブジェクトに含まれる操作対象を示すオブジェクトＩＤと、メッセージオブジェクトに含まれるトピックのオブジェクトＩＤと、が同一であるか否かを調べることで判断できる。そして、削除対象がトピックであるときにはステップ６８へと進み（Ｙｅｓ）、削除対象がトピックでないときにはステップ７１へと進む（Ｎｏ）。
【００６７】
ステップ６８では、メモリ上のコマンドキューにおいて、削除対象であるトピックの階層下のメッセージ（リプライ）をサーチする。
ステップ６９では、トピックの階層下にメッセージが見つかったか否かを判断する。そして、メッセージが見つかればステップ７０へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からメッセージを削除する。一方、メッセージが見つからなければステップ７１へと進む（Ｎｏ）。
【００６８】
ステップ７１では、メモリ上のコマンドキューの最後の項目まで処理したか否かを判断する。そして、最後の項目まで処理したならばステップ７２へと進み（Ｙｅｓ）、最後の項目まで処理していなければステップ６２へと戻る（Ｎｏ）。ステップ７２では、フラグが「１」か否か、即ち、メモリ上のコマンドキューにメッセージの作成を示すコマンドオブジェクトがあったか否かを判断する。そして、フラグが「１」であればステップ７３へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からメッセージの作成を示すコマンドオブジェクトを削除する。一方、フラグが「０」であれば本ルーチンを終了する（Ｎｏ）。
【００６９】
以上説明したステップ６１〜ステップ７３の処理によれば、ファイル上のコマンドキュー１６にメッセージの削除を示すコマンドオブジェクトがある場合、メッセージの削除を実行する前に行われるメッセージの更新処理は、実質的に何の作用も及ぼさないので、かかるメッセージの更新を示すコマンドオブジェクトを削除することで、他のサイトへ送信する情報量が削減される。また、コマンドキュー１６に、メッセージの作成を示すコマンドオブジェクトが見つからなかったときには、既にメッセージの作成が行われていると判断できるので、メッセージの削除を示すコマンドオブジェクトを削除しないようにし、不具合が生じないようにしている。さらに、削除対象のメッセージがトピックである場合、トピックの階層下のメッセージ（リプライ）を全て削除するようにしたので、他のサイトに送信する情報量をさらに低減することができる。
【００７０】
図１７は、情報の最適化処理において実行されるメッセージの更新に係るキュー処理を行うサブルーチンである。
ステップ８１では、メモリ上のコマンドキューにおいて、変更対象のメッセージと同一のオブジェクトＩＤを有し、かつ、メッセージの変更を示すコマンドオブジェクトを、変更対象のメッセージの次の項目からサーチする。即ち、第１回目の処理では更新対象のメッセージの次の項目に着目し、第２回目以降の処理では順次次の項目に着目する。
【００７１】
ステップ８２では、メッセージの変更を示すコマンドオブジェクトが見つかったか否かを判断する。そして、メッセージの変更を示すコマンドオブジェクトが見つかればステップ８３へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からメッセージの変更を示すコマンドオブジェクトを削除する。一方、メッセージの変更を示すコマンドオブジェクトが見つからなければステップ８４へと進む（Ｎｏ）。
【００７２】
ステップ８４では、メモリ上のコマンドキューの最後の項目まで処理したか否かを判断する。そして、最後の項目まで処理したならば本ルーチンを終了し（Ｙｅｓ）、最後の項目まで処理していなければステップ８１へと戻る（Ｎｏ）。
以上説明したステップ８１〜ステップ８４の処理によれば、ファイル上のコマンドキュー１６に登録されているメッセージの変更を示すコマンドオブジェクトの内、最新のコマンドオブジェクトを除き、他のコマンドオブジェクトがコマンドキュー１６から削除される。即ち、複数回のメッセージの更新が行われても、最新のコマンドオブジェクトさえあれば、フォーラムを最新の内容にすることができるので、実質的に何の作用も及ぼさないコマンドオブジェクトを削除することで、他のサイトに送信する情報量を削減することができる。
【００７３】
図１８は、情報の最適化処理において実行されるフォーラムの削除に係るキュー処理を行うサブルーチンである。
ステップ９１では、メモリ上のコマンドキューにフォーラムの作成を示すコマンドオブジェクトが登録されているか否かを示すフラグ（Ｆｌａｇ）を、「０」に設定する初期化を行う。
【００７４】
ステップ９２では、メモリ上のコマンドキューにおいて、削除対象のフォーラムと同一のオブジェクトＩＤを有する項目を、削除対象のフォーラムの次の項目からサーチする。即ち、第１回目の処理では削除対象のフォーラムの次の項目に着目し、第２回目以降の処理では順次次の項目に着目する。
ステップ９３では、着目している項目がフォーラムの作成を示すコマンドオブジェクトであるか否かを判断する。そして、フォーラムの作成であるときにはステップ９４へと進み（Ｙｅｓ）、フラグを「１」に設定する。一方、フォーラムの作成でないときにはステップ９５へと進む（Ｎｏ）。
【００７５】
ステップ９５では、着目している項目がフォーラムの更新を示すコマンドオブジェクトであるか否かを判断する。そして、フォーラムの更新であるときにはステップ９６へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からフォーラムの更新を示すコマンドオブジェクトを削除する。一方、メッセージの更新でないときにはステップ９７へと進む（Ｎｏ）。
【００７６】
ステップ９７では、メモリ上のコマンドキューにおいて、削除対象であるフォーラムに含まれるメッセージをサーチする。
ステップ９８では、削除対象のフォーラム中にメッセージが見つかったか否かを判断する。そして、メッセージが見つかればステップ９９へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からメッセージを削除する。一方、メッセージが見つからなければステップ１００へと進む（Ｎｏ）。
【００７７】
ステップ１００では、メモリ上のコマンドキューの最後の項目まで処理したか否かを判断する。そして、最後の項目まで処理したならばステップ１０１へと進み（Ｙｅｓ）、最後の項目まで処理していなければステップ９２へと戻る（Ｎｏ）。
ステップ１０１では、フラグが「１」か否か、即ち、メモリ上のコマンドキューにフォーラムの作成を示すコマンドオブジェクトがあったか否かを判断する。そして、フラグが「１」であればステップ１０２へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からフォーラムの作成を示すコマンドオブジェクトを削除する。一方、フラグが「０」であれば本ルーチンを終了する（Ｎｏ）。
【００７８】
以上説明したステップ９１〜ステップ１０２の処理によれば、ファイル上のコマンドキュー１６にフォーラムの削除を示すコマンドオブジェクトがある場合、フォーラムの削除を実行する前に行われるフォーラムの更新処理は、実質的に何の作用も及ぼさないので、かかるフォーラムの更新を示すコマンドオブジェクトを削除することで、他のサイトへ送信する情報量が削減される。また、コマンドキューに、フォーラムの作成を示すコマンドオブジェクトが見つからなかったときには、既にフォーラムの作成が行われていると判断できるので、フォーラムの削除を示すコマンドオブジェクトを削除しないようにし、不具合が生じないようにしている。さらに、フォーラムを削除することは、フォーラムに含まれるメッセージの削除をも意味するので、かかるメッセージを削除することで、他のサイトに送信する情報量をさらに低減することができる。
【００７９】
図１９は、情報の最適化処理において実行されるフォーラムの更新に係るキュー処理を行うサブルーチンである。
ステップ１１１では、メモリ上のコマンドキューにおいて、変更対象のフォーラムと同一のオブジェクトＩＤを有し、かつ、フォーラムの変更を示すコマンドオブジェクトを、変更対象のフォーラムの次の項目からサーチする。即ち、第１回目の処理では更新対象のフォーラムの次の項目に着目し、第２回目以降の処理では順次次の項目に着目する。
【００８０】
ステップ１１２では、フォーラムの変更を示すコマンドオブジェクトが見つかったか否かを判断する。そして、フォーラムの変更を示すコマンドオブジェクトが見つかればステップ１１３へと進み（Ｙｅｓ）、ファイル上のコマンドキュー１６からフォーラムの変更を示すコマンドオブジェクトを削除する。一方、フォーラムの変更を示すコマンドオブジェクトが見つからなければステップ１１４へと進む（Ｎｏ）。
【００８１】
ステップ１１４では、メモリ上のコマンドキューの最後の項目まで処理したか否かを判断する。そして、最後の項目まで処理したならば本ルーチンを終了し（Ｙｅｓ）、最後の項目まで処理していなければステップ１１１へと戻る（Ｎｏ）。
以上説明したステップ１１１〜ステップ１１４の処理によれば、ファイル上のコマンドキュー１６に登録されているフォーラムの変更を示すコマンドオブジェクトの内、最新のコマンドオブジェクトを除き、他のコマンドオブジェクトがコマンドキュー１６から削除される。即ち、複数回のフォーラムの更新が行われても、最新のコマンドオブジェクトさえあれば、フォーラムを最新の内容にすることができるので、実質的に何の作用も及ぼさないコマンドオブジェクトを削除することで、他のサイトに送信する情報量を削減することができる。
【００８２】
従って、図１５〜図１９に示す情報の最適化処理によれば、情報の送信に関して不具合を生じさせず、他のサイトに送信する情報量を大幅に低減することができ、通信効率を飛躍的に向上することができる。
図２０は、情報の順番保証処理のサブルーチンである。
ステップ１２１では、管理テーブルの初期化を行う。即ち、管理テーブルは、他のサイトに情報を送信する際に、例えば、通信回線４０の故障等により送信ができなかったサイトを登録するものである。
【００８３】
ステップ１２２では、ファイル上のコマンドキュー１６からコマンドオブジェクトを１つ読み込み、送信先を特定する宛先を取得する。
ステップ１２３では、取得した宛先が管理テーブルに登録されているか否かを判断する。そして、宛先が管理テーブルに登録されているときにはステップ１２７へと進み（Ｙｅｓ）、宛先が管理テーブルに登録されていないときにはステップ１２４へと進む（Ｎｏ）。
【００８４】
ステップ１２４では、コマンドオブジェクトから取得した宛先に、通信回線４０を介して、コマンドオブジェクト及びこれに付随する情報（以下「コマンドオブジェクト」と略記する）を送信する。
ステップ１２５では、送信が失敗したか否かを判断する。そして、送信が失敗したならばステップ１２６へと進み（Ｙｅｓ）、送信が失敗した宛先を管理テーブルに登録する。一方、送信が成功したならばステップ１２７へと進む（Ｎｏ）。なお、送信が失敗したコマンドオブジェクトは、ファイル上のコマンドキュー１６から削除せず、本ルーチンにおける次回の処理で再送信が行われる。
【００８５】
ステップ１２７では、ファイル上のコマンドキュー１６の全てのコマンドオブジェクトを処理したか否かを判断する。そして、全てのコマンドオブジェクトを処理したならば本ルーチンを終了し（Ｙｅｓ）、全てのコマンドオブジェクトを処理していなければステップ１２２へと戻る（Ｎｏ）。
以上説明したステップ１２１〜ステップ１２７の処理によれば、コマンドオブジェクトの送信に失敗した宛先は、管理テーブルに登録される。そして、コマンドオブジェクトは、管理テーブルに登録されている宛先には送信されず、かつ、ファイル上のコマンドキュー１６から削除されない。従って、通信回線４０の故障等に起因してコマンドオブジェクトが正常に送信されなかった場合であっても、通信情報の順番保証が行われ、不具合が生じない。さらに、付加的な効果であるが、通信エラーが生じた宛先には、今回の送信処理において送信が行われないので、無駄な送信が行われず、通信回線の占有時間を短縮することができる。なお、今回の処理において送信されなかったコマンドオブジェクトは、所定期間を経過した次回の送信処理で再送信が行われる。これは、所定時間経過するまでに、通信回線の故障等が直っている場合があるからである。
【００８６】
図２１〜図２５は、各サイトにおいて、サーバ１０のバックグラウンドで受信キュー２０からコマンドオブジェクトを１つ取り出し、その処理を行う際に実行される処理を示す。
図２１は、メインルーチンである。
ステップ１３０では、受信キュー２０からコマンドオブジェクトを取り出す。
【００８７】
ステップ１４０では、宛先矛盾のチェック処理を行うサブルーチン（図２２）を実行する。
ステップ１５０では、情報内容矛盾のチェック処理を行うサブルーチン（図２３）を実行する。
ステップ１７０では、データベース１２への登録処理を行うサブルーチン（図２４）を実行する。
【００８８】
ステップ１９０では、リカバリ情報の作成処理を行うサブルーチン（図２５）を実行する。
図２２は、宛先矛盾のチェック処理を行うサブルーチンである。
ステップ１４１では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析し、送信元のサイト及び処理対象となるフォーラムを取得する。
【００８９】
ステップ１４２では、データベース１２に登録されている処理対象のフォーラムにおいて、登録されている宛先情報内に、ステップ１４１で取得した送信元のサイトがあるか否かをチェックする。
ステップ１４３では、宛先情報内に送信元のサイトがあれば本ルーチンを終了し（Ｙｅｓ）、宛先情報内に送信元のサイトがなければステップ１４４へと進む（Ｎｏ）。
【００９０】
ステップ１４４では、データベース１２に登録されている処理対象のフォーラムに、その宛先情報としてステップ１４１で取得した送信元のサイトを追加登録する。この処理と共に、例えば、クライアント３０に宛先に矛盾が発生した旨を表示するようにし、電子会議システムの管理者が早期に矛盾発生を知ることができるようにしてもよい。
【００９１】
なお、ステップ１４１〜ステップ１４３の処理が、宛先矛盾判定手段、宛先矛盾判定工程、宛先矛盾判定機能に相当し、また、ステップ１４４の処理が宛先矛盾修正手段、宛先矛盾修正工程、宛先矛盾修正機能に相当する。
以上説明したステップ１４１〜ステップ１４３の処理によれば、あるサイトにおいて、リカバリディスクによるフォーラムの復旧が行われ、宛先情報に矛盾が発生しても、送信されたコマンドオブジェクトに基づいて、自動的に宛先情報の矛盾判定及び修正が行われる。従って、送信されるべき情報が送信されないという事態の発生が防止され、電子会議システムの信頼性を向上することができる。
【００９２】
図２３は、情報内容の矛盾チェック処理を行うサブルーチンである。
情報内容の矛盾は、例えば、次のような場合に発生する。先ず、サイトＡ〜サイトＥによって電子会議システムが構築され、サイトＡからサイトＢを経てサイトＣへ情報が伝達されると共に、サイトＡからサイトＤを経てサイトＥに情報が伝達される情報伝達経路を考える。この状態において、例えば、サイトＤでリカバリディスクに基づいてデータベース１２を復旧したところ、リカバリディスクが古いため、サイトＤの情報交換先としてサイトＥが登録されていない状態に戻ってしまう場合がある。すると、サイトＤからサイトＥには情報が伝達されず、サイトＥの利用者は情報が伝達されなかったことに気が付かないことが多く、結果として、重要な情報が伝達されないおそれがあった。
【００９３】
そこで、以下説明する情報内容の矛盾チェック処理により、情報内容の矛盾発生を自動的に判定し或いは修正することで、電子会議システムの信頼性を向上するようにした。
ステップ１５１では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析し、処理対象となるフォーラムのオブジェクトＩＤを取得する。即ち、取得したフォーラムのオブジェクトＩＤが示すフォーラムに対して、オブジェクトの作成、更新等の処理が行われる。
【００９４】
ステップ１５２では、データベース１２中に処理対象となるフォーラムが存在するか否かを判断する。そして、フォーラムが存在するときにはステップ１５４へと進み（Ｙｅｓ）、フォーラムが存在しないときにはステップ１５３へと進む（Ｎｏ）。
ステップ１５３では、後述する削除情報の中に、処理対象となるフォーラムが存在するか否かを判断する。そして、削除情報の中にフォーラムが存在するときには本ルーチンを終了し（Ｙｅｓ）、フォーラムが存在しないときには情報内容に矛盾が発生したと判断し、ステップ１６０へと進む（Ｎｏ）。
【００９５】
ここで、削除情報とは、あるサイトにおいて、データベース１２に対する処理によって、データベース１２中からオブジェクトが削除された場合、オブジェクトが削除されたことを登録する情報である。従って、削除情報の中に処理対象となるフォーラムが存在する場合には、他のサイトから情報が送信される前に、フォーラムが削除されたものであるから、情報には矛盾が発生していないと判断することができる。なお、処理対象がメッセージである場合にも、同様に考えることができる。
【００９６】
ステップ１５４では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析し、処理対象となるトピックのオブジェクトＩＤを取得する。
ステップ１５５では、処理対象となるフォーラムの中に、処理対象となるトピックが存在するか否かを判断する。そして、処理対象となるトピックが存在するときにはステップ１５７へと進み（Ｙｅｓ）、トピックが存在しないときにはステップ１５６へと進む（Ｎｏ）。
【００９７】
ステップ１５６では、削除情報の中に、処理対象となるトピックが存在するか否かを判断する。そして、削除情報の中にトピックが存在するときには本ルーチンを終了し（Ｙｅｓ）、トピックが存在しないときには情報内容に矛盾が発生したと判断し、ステップ１６０へと進む（Ｎｏ）。
ステップ１５７では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析し、処理対象となるメッセージの親のメッセージのＩＤを取得する。
【００９８】
ステップ１５８では、処理対象となるフォーラムの中に、取得した親メッセージのＩＤが示す親メッセージが存在するか否かを判断する。そして、親メッセージが存在するときには本ルーチンを終了し（Ｙｅｓ）、親メッセージが存在しないときにはステップ１５９へと進む（Ｎｏ）。
ステップ１５９では、削除情報の中に、親メッセージが存在するか否かを判断する。そして、削除情報の中に親メッセージが存在するときには本ルーチンを終了し（Ｙｅｓ）、親メッセージが存在しないときには情報内容に矛盾が発生したと判断し、ステップ１６０へと進む（Ｎｏ）。
【００９９】
ステップ１６０では、コマンドオブジェクトに含まれるオブジェクトＩＤを解析して送信元のサイトを示すオブジェクトＩＤを取得し、送信元のサイトから処理対象となるフォーラム全体を取得する。
ステップ１６１では、データベース１２に登録されているフォーラムと、送信元のサイトから取得したフォーラムと、をマージ（併合）しつつデータベースの更新登録を行う。
【０１００】
以上説明したステップ１５１〜ステップ１６１の処理によれば、コマンドオブジェクトが示す処理対象のオブジェクトが、データベース１２に登録されていない場合、情報内容に矛盾が発生したと判断することができる。そして、情報内容に矛盾が発生したと判断された場合、送信元からフォーラム全体を取得し、取得したフォーラムに基づきベータベースに対してマージしつつ更新処理を行い、情報内容の修正を行う。従って、情報内容の矛盾が自動的に判定及び修正されるので、電子会議システムの信頼性を向上することができる。
【０１０１】
図２４は、データベースへの登録処理を行うサブルーチンである。
ステップ１７１では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析し、操作の種類（オブジェクトの作成、削除、更新或いは移動の別をいう。以下同様）を取得する。
ステップ１７２では、操作の種類はオブジェクトの作成であるか否かを判断する。そして、オブジェクトの作成であればステップ１７３へと進み（Ｙｅｓ）、オブジェクトの作成でなければステップ１７９へと進む（Ｎｏ）。
【０１０２】
ステップ１７３では、作成対象となるオブジェクトは既に存在するか否かを判断する。そして、既に存在していればステップ１７４へと進み（Ｙｅｓ）、既に存在していなければステップ１７８へと進み（Ｎｏ）、オブジェクトの作成を行う。
ステップ１７４では、データベース１２から、作成対象となるオブジェクトの親オブジェクトＩＤを取得する。
【０１０３】
ステップ１７５では、取得した親オブジェクトＩＤと、送信されたオブジェクトコマンドに含まれる親オブジェクトＩＤと、を比較する。
ステップ１７６では、取得した親オブジェクトＩＤと送信された親オブジェクトＩＤとが同一であるか否かを判断する。そして、オブジェクトＩＤが同一であれば本ルーチンを終了し（Ｙｅｓ）、オブジェクトＩＤが同一でなければステップ１７７へと進む（Ｎｏ）。
【０１０４】
ステップ１７７では、オブジェクトの移動処理を行う。即ち、オブジェクトの移動処理は、既に存在する作成対象となるオブジェクトを、送信された作成情報中の親オブジェクトの階層下に移動する。
ステップ１７９では、操作の種類はオブジェクトの削除であるか否かを判断する。そして、オブジェクトの削除であればステップ１８０へと進み（Ｙｅｓ）、オブジェクトの削除でなければステップ１８４へと進み（Ｎｏ）、ステップ１８４で操作の種類に応じた処理を実行する。
【０１０５】
ステップ１８０では、データベース１２から、削除対象となるオブジェクトの親オブジェクトＩＤを取得する。
ステップ１８１では、取得した親オブジェクトＩＤと、送信されたオブジェクトコマンドに含まれる親オブジェクトＩＤと、を比較する。
ステップ１８２では、取得した親オブジェクトＩＤと送信された親オブジェクトＩＤとが同一であるか否かを判断する。そして、オブジェクトＩＤが同一であればステップ１８３に進み（Ｙｅｓ）、オブジェクトの削除を行う。一方、オブジェクトＩＤが同一でなければコマンドオブジェクトを無視し、本ルーチンを終了する（Ｎｏ）。
【０１０６】
以上説明したステップ１７１〜ステップ１８４の処理によれば、メインフォーラムが異なるフォーラム間でオブジェクトの移動があっても、オブジェクトの移動元においては、オブジェクトの削除が実行され、一方、オブジェクトの移動先においては、オブジェクトの作成が行われる。従って、情報伝達の順序に関わらず、結果としてオブジェクトの移動が正しく実行される。
【０１０７】
図２５は、リカバリ情報の作成処理を示すサブルーチンである。
ステップ１９１では、受信キュー２０から取り出したコマンドオブジェクトに含まれるオブジェクトＩＤを解析して、操作の種類を取得する。
ステップ１９２では、操作の種類はオブジェクトの作成であるか否かを判断する。そして、オブジェクトの作成であればステップ１９３へと進み（Ｙｅｓ）、作成対象のオブジェクトをリカバリディスクに登録する。一方、オブジェクトの作成でなければステップ１９４へと進む（Ｎｏ）。
【０１０８】
ステップ１９４では、操作の種類はオブジェクトの削除であるか否かを判断する。そして、オブジェクトの削除であればステップ１９５へと進み（Ｙｅｓ）、オブジェクトの削除でなければ本ルーチンを終了する（Ｎｏ）。
ステップ１９５では、削除対象のオブジェクトをリカバリディスクから削除する。
【０１０９】
以上説明したステップ１９１〜ステップ１９５の処理によれば、受信キュー２０からコマンドオブジェクトを取り出して処理する度に、リカバリディスクの更新が行われるので、リカバリディスクを常に最新の状態に保つことができる。従って、かかるリカバリディスクに基づいて、フォーラムの復旧を行うようにすれば、フォーラムを最新の状態に復旧できる。
【０１１０】
なお、本実施形態においては、リカバリディスクの更新は、受信キュー２０からコマンドオブジェクトを取り出す度に実行されたが、電子会議システムの管理者の操作により、リカバリディスクの更新を実行するようにしてもよい。また、リカバリディスクは、データベース１２を構築するディスクと物理的に別体のディスクによって構成することが望ましい。
【０１１１】
図２６は、電子会議システムの管理者の操作により、リカバリディスクの作成を行うメインルーチンである。
ステップ２００では、データベース１２から、登録されている全てのフォーラムをサーチする。
ステップ２０１では、サーチしたフォーラムの情報交換先であるサイトを特定する宛先をリカバリディスクに登録する。
【０１１２】
ステップ２０２では、サーチしたフォーラムを示すオブジェクトＩＤをリカバリディスクに登録する。
ステップ２０３では、サーチしたフォーラムに含まれる全てのメッセージをサーチする。
ステップ２０４では、サーチした全てのメッセージを示すオブジェクトＩＤをリカバリディスクに登録する。
【０１１３】
以上説明したステップ２００〜ステップ２０４の処理によれば、電子会議システムの管理者からリカバリディスクの作成指示があると、データベース１２に登録されているフォーラムを示す全てのオブジェクトＩＤ、及び、フォーラムに含まれるメッセージを示す全てのオブジェクトＩＤが、リカバリディスクに登録される。従って、ディスクがクラッシュしてフォーラム情報が失われても、リカバリディスクに基づいて、後述する復旧処理により、データベースに登録されているフォーラム、及び、フォーラムに含まれるメッセージが復旧される。
【０１１４】
図２７は、リカバリディスクに基づいてデータベース１２の復旧を行うメインルーチンを示している。なお、図２７の処理は、電子会議システムの管理者の指示によって実行される。
ステップ２１０では、リカバリディスクから登録されているフォーラムをサーチする。
【０１１５】
ステップ２１１では、リカバリディスクに登録されている情報交換先であるサイトを特定する宛先を読み込み、登録されているいずれかのサイトに接続する。接続先のサイトは、例えば、通信回線４０の空き状況等に応じて決定すればよい。
ステップ２１２では、接続したサイトから、ステップ２１０においてサーチしたフォーラムに含まれる全てのオブジェクトを取得する。
【０１１６】
ステップ２１３では、取得したオブジェクトからリカバリディスクに登録されていないオブジェクトを削除する。
ステップ２１４では、リカバリディスクに登録されている全てのフォーラムに対して処理を行ったか否かを判断する。そして、全てのフォーラムの処理が行われたときには本ルーチンを終了し（Ｙｅｓ）、全てのフォーラムの処理が行われていないときにはステップ２１０へと戻り（Ｎｏ）、ステップ２１０〜ステップ２１３の処理を繰り返す。
【０１１７】
以上説明したステップ２１０〜ステップ２１４の処理によれば、電子会議システムの管理者の指示があったときには、リカバリディスクに登録されているフォーラムに基いて、通信回線４０を介して他のサイトからフォーラム全体が取得される。そして、リカバリディスクに登録されていないオブジェクトが、取得されたフォーラムから削除される。このようにしたのは、蓄積交換型の通信方式を採用しているため、あるサイトにおける操作が、他のサイトに反映されていない場合があるためである。
【０１１８】
このようにすることで、データベースをリカバリディスクを作成した時点の状態に復旧することができ、障害発生直前の状態に戻すことができる。
【０１１９】
【発明の効果】
以上説明したように、請求項１記載の発明によれば、情報交換先を特定する宛先に矛盾が発生したことが自動的に判定されるので、例えば、電子会議システムの管理者が宛先矛盾の発生を早期に発見でき、電子会議システムの保守が早期に行われるので、伝達されるべき情報が伝達されないという状況が少なくなり、電子会議システムの信頼性を向上することができる。
【０１２０】
請求項２記載の発明によれば、情報交換先を特定する宛先に矛盾が発生したことを簡単に判定することができ、システム資源の負荷増大を最小にすることができる。
請求項３又は請求項７に記載の発明によれば、情報交換を行う単位となるフォーラムごとに、宛先に矛盾が発生しているか否かを判定することができる。
請求項４記載の発明によれば、請求項１記載の発明の効果に加え、情報交換先を特定する宛先に矛盾が発生したときには、宛先矛盾が自動的に修正されるので、電子会議システムの保守が容易になると共に、伝達されるべき情報が伝達されないという状況の発生を防止することができる。
【０１２１】
請求項５記載の発明によれば、情報交換先を特定する宛先に矛盾が発生したことの判定を簡単に行うことができ、システム資源の負荷増大を最小にすることができる。
請求項６記載の発明によれば、宛先矛盾の修正を簡単に行うことができ、システム資源の負荷増大を最小にすることができる。
【０１２２】
請求項８又は請求項９に記載の発明によれば、請求項１記載の発明の効果に加え、本発明に係る宛先矛盾判定プログラムを流通させることができ、かかるプログラムを記録した媒体を取得した者は、宛先矛盾判定装置を容易に構築することができる。
請求項１０又は請求項１１に記載の発明によれば、請求項４記載の発明の効果に加え、本発明に係る宛先矛盾修正プログラムを流通させることができ、かかるプログラムを記録した媒体を取得した者は、宛先矛盾修正装置を容易に構築することができる。
【図面の簡単な説明】
【図１】  本発明の電子会議システムの一実施形態を示すシステム図である。
【図２】  同上のフォーラムの階層構造を示す説明図である。
【図３】  同上のメッセージの階層構造を示す説明図である。
【図４】  同上のデータベースに登録されるオブジェクトの詳細を示す説明図である。
【図５】  同上のオブジェクトを示すオブジェクトＩＤの説明図である。
【図６】  同上の情報交換先である宛先情報の説明図である。
【図７】  同上の情報交換の流れを示す処理流れ図である。
【図８】  サーバにおける処理内容を示すメインルーチンのフローチャートである。
【図９】  同上のメインルーチンから実行されるオブジェクトの作成処理を示すサブルーチンのフローチャートである。
【図１０】  同上のメインルーチンから実行されるオブジェクトの削除処理を示すサブルーチンのフローチャートである。
【図１１】  同上のメインルーチンから実行されるオブジェクトの更新処理を示すサブルーチンのフローチャートである。
【図１２】  同上のメインルーチンから実行されるオブジェクトの移動処理を示すサブルーチンのフローチャートである。
【図１３】  同上の移動処理の必要性を示す説明図である。
【図１４】  サーバにおいて情報の送信を行うときに実行されるメインルーチンを示すフローチャートである。
【図１５】  同上のメインルーチンから実行される情報の最適化処理を示すサブルーチンのフローチャートである。
【図１６】  同上の最適化処理のサブルーチンから実行されるメッセージの削除キュー処理を示すサブルーチンのフローチャートである。
【図１７】  同上の最適化処理のサブルーチンから実行されるメッセージの更新キュー処理を示すサブルーチンのフローチャートである。
【図１８】  同上の最適化処理のサブルーチンから実行されるフォーラムの削除キュー処理を示すサブルーチンのフローチャートである。
【図１９】  同上の最適化処理のサブルーチンから実行されるフォーラムの更新キュー処理を示すサブルーチンのフローチャートである。
【図２０】  同上のメインルーチンから実行される情報の順番保証処理を示すサブルーチンのフローチャートである。
【図２１】  受信キューからコマンドオブジェクトを取り出す度に実行されるメインルーチンを示すフローチャートである。
【図２２】  同上のメインルーチンから実行される宛先矛盾のチェック処理を示すサブルーチンのフローチャートである。
【図２３】  同上のメインルーチンから実行される情報内容矛盾のチェック処理を示すサブルーチンのフローチャートである。
【図２４】  同上のメインルーチンから実行されるデータベースへの登録処理を示すサブルーチンのフローチャートである。
【図２５】  同上のメインルーチンから実行されるリカバリ情報の作成処理を示すサブルーチンのフローチャートである。
【図２６】  電子会議システムの管理者の指示により実行されるリカバリ情報の作成処理を示すフローチャートである。
【図２７】  電子会議システムの管理者の指示により実行されるリカバリ処理を示すフローチャートである。
【図２８】  従来の電子会議システムの一実施形態を示すシステム図である。
【図２９】  同上の電子会議システムにおいて宛先に矛盾が発生した状態を示すシステム図である。
【符号の説明】
１０・・・サーバ
１２・・・データベース
１４・・・サーバソフト
５８・・・宛先情報
【図１】
0003933770.tif 000002
【図２】
0003933770.tif 000003
【図３】
0003933770.tif 000004
【図４】
0003933770.tif 000005
【図５】
0003933770.tif 000006
【図６】
0003933770.tif 000007
【図７】
0003933770.tif 000008
【図８】
0003933770.tif 000009
【図９】
0003933770.tif 000010
【図１０】
0003933770.tif 000011
【図１１】
0003933770.tif 000012
【図１２】
0003933770.tif 000013
【図１３】
0003933770.tif 000014
【図１４】
0003933770.tif 000015
【図１５】
0003933770.tif 000016
【図１６】
0003933770.tif 000017
【図１７】
0003933770.tif 000018
【図１８】
0003933770.tif 000019
【図１９】
0003933770.tif 000020
【図２０】
0003933770.tif 000021
【図２１】
0003933770.tif 000022
【図２２】
0003933770.tif 000023
【図２３】
0003933770.tif 000024
【図２４】
0003933770.tif 000025
【図２５】
0003933770.tif 000026
【図２６】
0003933770.tif 000027
【図２７】
0003933770.tif 000028
【図２８】
0003933770.tif 000029
【図２９】
0003933770.tif 000030