(57)【要約】【課題】  クライアントマシンだけで情報を共有する空間を形成できるコミュニティ管理システム、メールサーバ、コミュニティ管理装置、コミュニティ管理方法およびプログラムを提供する。【解決手段】  コミュニティに参加するコミュニティ管理装置１、４、５同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持する。【選択図】  図１
2006244423.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理システムであって、
コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理システム。
【請求項２】
ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理システムであって、
コミュニティ管理装置は、コミュニティを管理するコミュニティ情報ＤＢと、
コミュニティで共有している情報を管理する共有情報ＤＢを持ち、
専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするメール送受信手段と、
コミュニティ情報、および、コミュニティの共有情報を変更および参照するユーザインタフェース手段と、
を備えることを特徴とするコミュニティ管理システム。
【請求項３】
コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持させることを特徴とするメ−ルサ−バ。
【請求項４】
コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理装置。
【請求項５】
コミュニティを管理するコミュニティ情報ＤＢと、
コミュニティで共有している情報を管理する共有情報ＤＢを持ち、
専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするメール送受信手段と、
コミュニティ情報、および、コミュニティの共有情報を変更および参照するユーザインタフェース手段と、
を備えることを特徴とするコミュニティ管理装置。
【請求項６】
ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を利用したコミュニティ管理方法であって、
コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理方法。
【請求項７】
ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理方法であって、
コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを備えるコミュニティ管理装置が、
メール送受信手段によって専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするステップと、
ユーザインタフェース手段によってコミュニティ情報、および、コミュニティの共有情報を変更および参照するステップと、
を有することを特徴とするコミュニティ管理方法。
【請求項８】
ネットワークを介して接続されているコミュニティ管理装置と、メールサーバとに、
コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持させる処理を実行させることを特徴とするプログラム。
【請求項９】
コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを備えるコミュニティ管理装置と、ネットワークを介して接続されているメールサーバに、
メール送受信手段によって専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするステップと、
ユーザインタフェース手段によってコミュニティ情報、および、コミュニティの共有情報を変更および参照するステップと、
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントマシンだけで情報を共有する空間を形成できるコミュニティ管理システム、メールサーバ、コミュニティ管理装置、コミュニティ管理方法およびプログラムに関する。
【背景技術】
【０００２】
ビジネスにおけるプロジェクトやチームのように、参加メンバを限定した「閉じた」コミュニティで情報を共有する場合には、グループウェアに代表されるようなセンターサーバでコミュニティを集中管理する方法がある。
【０００３】
しかし、ファイアウォールを越えられないなどの理由でセンタサーバにアクセスできないユーザはコミュニティに加わることができなかった。
【０００４】
これを解決するために、特許文献１でピア・ツー・ピアで情報を共有する方式が提案されている。本方式は、各コンピュータに情報を共有するためのフォルダを用意してファイルを保存しておき、ファイルごとに誰に公開するか公開条件を記憶しておき、対象となるユーザからの検索要求があれば、該当する情報を提供するシステムであり、検索依頼、および、文書実体を含めた検索結果のやり取りを電子メールで行なっている。
【０００５】
このため、情報共有のためのサーバが不要であり、電子メールさえやり取りできれば、すぐに情報を共有できるとしている。
【０００６】
ただし、本方式は、個別のユーザに電子メールという形式で情報を公開しているだけであり、同じ情報をお互いに保有し変更したら、お互いに変更が反映されるということはできない。また、個別ユーザごとの情報共有方式であり、コミュニティを形成し、コミュニティの中で情報共有することはできない。
【０００７】
同様に、特許文献２では、ファイアウォールを越えてファイル管理サーバ同士で情報を同期する方式が提案されているが、ファイルの同期方法を示したものであって、コミュニティを形成することはできない。
【０００８】
また、特許文献３および特許文献４において、ネットワークに接続されたローカルデバイス間で共有情報を同期する方式が提案されている。本方式は、デルタと呼ばれる情報の差分を他のローカルデバイスと同期させるときに、各ローカルデバイスに存在する通信マネージャが、送信先が直接接続できるかどうかを判別し、直接接続できるならば直接デルタを送信する。直接接続できない場合は、リレーと呼ばれるサーバ（以下、「リレーサーバ」という）に送信処理を依頼する。
【０００９】
リレーサーバは、ローカルデバイスが通信可能か否かを管理しているプレゼンス機構を持ち、送信先が通信可能になればデルタを送信する。リレーサーバは、送信先が通信可能になるまでデルタを保持している。
【００１０】
本方式は、ほぼリアルタイムにコミュニティ内で共有情報を同期するためには有効な機構であるが、反面、リレーサーバと呼ばれるサーバを用意しなければならないことと、各ローカルデバイスの通信マネージャが、送受信の管理を行わなければならずシステムとして複雑になるという問題がある。
【００１１】
また、リレーサーバにアクセスできないユーザはコミュニティに参加できないという問題がある。
【００１２】
さらに、本システムのリレーサーバをメールサーバにした場合は、ユーザがリレーサーバにアクセスできないという問題は解消されるが、通信マネージャに到着した順番にデルタの処理を行なう構造になっているため、デルタ到着順と実際の更新時間の順序が異なる可能性がある電子メールを使用した場合には最新の情報を保持できないという問題がある。
【００１３】
ここで、複数の作業者から成るグループでの作業を支援するグループウェアシステムと複数の作業者に関する個人情報をそれぞれ管理する複数の個人情報管理システムとから構成され、グループウェアシステムを構成するグループウェア端末が保持するグループウェア情報を格納するグループウェア管理テーブルと、各個人情報管理システムを構成する個人情報端末が保持する個人情報を格納し、変更後の個人情報に基づいてグループウェア情報が変更されるときに参照される同期管理テーブルとを備えたことにより、個人情報端末の情報が変更された場合でも、同期管理テーブルがグループウェア管理テーブルのグループウェア情報と個人情報管理テーブルの個人情報との関係を示しているので、グループウェア情報と個人情報を一致させることができる技術が提案されている（例えば、特許文献５参照）。
【特許文献１】特開２００２−２２９８３６号公報
【特許文献２】特開２００２−１４９４６５号公報
【特許文献３】特表２００３−５３６１２３号公報
【特許文献４】特表２００３−５０５７６０号公報
【特許文献５】特開２０００−１４８６９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上述した従来例においては次のような問題点があった。
【００１５】
ビジネスにおけるプロジェクトやチームのように、参加メンバを限定した「閉じた」コミュニティで情報を共有する場合には、グループウェアに代表されるようなセンターサーバでコミュニティを集中管理する方法があるが、ファイアウォールを越えられないなどの理由でセンターサーバにアクセスできないユーザはコミュニティに加わることができなかった。
【００１６】
また、情報を共有するためにセンターサーバを用意しなければならず、サーバが用意されていない場合、アドホックにコミュニティを形成するのは困難であった。
【００１７】
また、情報を共有するためのセンターサーバを用意せず、クライアント間でピア・ツー・ピア技術を利用してコミュニティを作成し情報を共有するシステムも存在するが、やはりピア・ツー・ピアで参加メンバ同士が接続できなければならないため、ファイウォールを越えられないなどの理由でお互いに通信できないユーザはコミュニティに加わることができなかった。
【００１８】
別の手段として、ネットワークの壁を越えてコミュニティで情報共有をするためにはメーリングリストを利用することが考えられるが、メーリングリストはコミュニティのメンバを管理し情報を配送する手段であって、メンバ間で情報を同じモデルで管理しているわけではなく、メンバ同士で同じ情報を同じように参照できなかった。
【００１９】
そこで、本発明は、コミュニティに参加するクライアントマシン同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することで、クライアントマシンだけで情報を共有する空間を形成できるコミュニティ管理システム、メールサーバ、コミュニティ管理装置、コミュニティ管理方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２０】
請求項１記載の発明は、ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理システムであって、コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理システムである。
【００２１】
請求項２記載の発明は、ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理システムであって、コミュニティ管理装置は、コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを持ち、専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするメール送受信手段と、コミュニティ情報、および、コミュニティの共有情報を変更および参照するユーザインタフェース手段とを備えることを特徴とするコミュニティ管理システムである。
【００２２】
請求項３記載の発明は、コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持させることを特徴とするメールサーバである。
【００２３】
請求項４記載の発明は、コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理装置である。
【００２４】
請求項５記載の発明は、コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを持ち、専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするメール送受信手段と、コミュニティ情報、および、コミュニティの共有情報を変更および参照するユーザインタフェース手段とを備えることを特徴とするコミュニティ管理装置である。
【００２５】
請求項６記載の発明は、ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を利用したコミュニティ管理方法であって、コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することを特徴とするコミュニティ管理方法である。
【００２６】
請求項７記載の発明は、ネットワークを介して接続されているコミュニティ管理装置と、メールサーバと、を含むコミュニティ管理方法であって、コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを備えるコミュニティ管理装置が、メール送受信手段によって専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするステップと、ユーザインタフェース手段によってコミュニティ情報、および、コミュニティの共有情報を変更および参照するステップとを有することを特徴とするコミュニティ管理方法である。
【００２７】
請求項８記載の発明は、ネットワークを介して接続されているコミュニティ管理装置と、メールサーバとに、コミュニティに参加するコミュニティ管理装置同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持させる処理を実行させることを特徴とするプログラムである。
【００２８】
請求項９記載の発明は、コミュニティを管理するコミュニティ情報ＤＢと、コミュニティで共有している情報を管理する共有情報ＤＢを備えるコミュニティ管理装置と、ネットワークを介して接続されているメールサーバに、メール送受信手段によって専用のメールアドレスが割り振られて、自機に対するメッセージのみをやり取りするステップと、ユーザインタフェース手段によってコミュニティ情報、および、コミュニティの共有情報を変更および参照するステップとを実行させることを特徴とするプログラムである。
【発明の効果】
【００２９】
本発明のコミュニティ管理システム、メールサーバ、コミュニティ管理装置、コミュニティ管理方法およびプログラムによれば、クライアントマシンだけで情報を共有する空間を形成できる。
【発明を実施するための最良の形態】
【００３０】
次に、本発明の一実施の形態について図を参照して詳細に説明する。
【００３１】
図１を参照すると、本実施の形態におけるコミュニティ管理システムは、パーソナルコンピュータ等の端末装置で動作するコミュニティ管理装置１とコミュニティ管理装置１がアクセスできるメールサーバ２を含む。
【００３２】
コミュニティ管理装置１は、コミュニティ管理装置１に対するコミュニティ操作のユーザインタフェースをつかさどるユーザインタフェース１−１と、コミュニティ操作命令を受け、コミュニティ情報を変更するコミュニティ管理部１−２、コミュニティ情報のうち、コミュニティで管理する共有情報を変更する共有情報管理部１−７、コミュニティ操作命令をメール形式にし他のメンバへ送信し、また、他のメンバからのメールを受信するメール送受信部１−５、コミュニティ情報を管理するための記憶装置であるコミュニティ情報ＤＢ１−６および共有情報を管理するための記憶装置である共有情報ＤＢ１−８を備える。
【００３３】
コミュニティ管理ＤＢ１−６は、コミュニティ管理装置１が参加しているコミュニティ一覧と、コミュニティに参加しているメンバ一覧を管理するＤＢである。
【００３４】
共有情報ＤＢ１−８は、コミュニティ管理装置１で管理しているコミュニティが保持している共有情報一覧を管理するＤＢである。
【００３５】
コミュニティ管理装置４およびコミュニティ管理装置６は、コミュニティ管理装置１と同様の構成である。
【００３６】
また、それぞれのコミュニティ管理装置は、メールサーバ３ないしメールサーバ５にアクセスできる。
【００３７】
メールサーバ２は、メール送受信部１−５からの要求にしたがって指定したメールアドレスにメールを配送し、また、他のメールサーバからメール送受信部１−５に配送されてきたメールを保持しておき、メール送受信部１の取得要求に応じて保持していたメールを返却する。同様に、メールサーバ３、５はコミュニティ管理装置４、６に対するメールの処理を行なう。
【００３８】
次に、図１および図２を参照して本実施の形態における処理動作について詳細に説明する。
【００３９】
本システムの動作の開始（図２のステップＡ０１）となるのは、コミュニティ管理装置１のユーザインタフェース１−１で利用者がコミュニティ情報、もしくは、コミュニティで共有している情報を操作したとき、および、メール送受信部１−５がメールサーバ２より別のコミュニティ管理装置からのコミュニティ操作命令を受信したときである。
【００４０】
メール送受信部１−５は、定期的に、もしくは、コミュニティ管理部１−２からの依頼に応じて、メールサーバ２よりメールを取得する。
【００４１】
図３は、ユーザインタフェースを具現化した例である。
【００４２】
Ｂ１にコミュニティ情報に対する操作を行なうためのメニューコマンドがあり、Ｂ２には参加しているコミュニティ一覧が表示される。
【００４３】
Ｂ２において一つだけコミュニティを選択でき、Ｂ３は、Ｂ２で選択したコミュニティで共有しているファイル一覧、Ｂ４は、Ｂ２で選択したコミュニティの参加者一覧が表示される。
【００４４】
ユーザインタフェース１−１の利用者が、メニューコマンドでコミュニティに対する操作を行なうことで動作が開始する。
【００４５】
図４は、メール送受信部１−５が受信するコミュニティ操作命令の例である。
【００４６】
コミュニティ操作命令はメール形式になっており、操作内容がメールの拡張ヘッダとして（図４のＣ１）、操作データがメールの本文（Ｃ２）に記述されている。
【００４７】
メール送受信部１−５がこのメールを受信することで動作が開始する。
【００４８】
次に、ユーザインタフェース１−１もしくは、メール送受信部１−５は、利用者もしくは、他のコミュニティ管理装置４からの操作内容を解釈し、コミュニティ管理部１−２が解釈できる形式に変換後、コミュニティ１−２に渡す（ステップＡ０２）。
【００４９】
例えば、コミュニティ管理部１−２が操作命令と必要な情報をＸＭＬ形式で理解する場合は、ユーザインタフェース１−１やメール送受信部１−５は、操作内容をＸＭＬ形式に変換してコミュニティ管理部１−２に渡す。
【００５０】
図５は、コミュニティ管理部１−２が解釈するコミュニティ操作命令の例である。Ｄ１は操作命令、Ｄ２は操作命令に付随する情報、Ｄ３はメールの拡張ヘッダに記述する操作内容を示す。
【００５１】
Ｄ２の情報における、コミュニティ識別子、ユーザ識別子、共有情報識別子等の識別情報は、グローバルで一意になるような文字列であり、例えば、図６のようにネットワークアダプタのＭＡＣアドレスと時間を組み合わせたものとする。
【００５２】
なお、ユーザ識別子（以下、「ユーザIＤ」という）は、コミュニティ管理装置ごとに一つだけ割り当てられ、初回起動時に設定された後は不変である。
【００５３】
コミュニティ管理部１−２は、コミュニティ操作命令を受け取ると、まず、コミュニティ情報の変更かどうかを判別する（ステップＡ０３）。コミュニティ情報の変更とは、コミュニティもしくはメンバ情報の変更を伴う操作を示す。
【００５４】
図５の例では、Ｎｏ１〜Ｎｏ５、Ｎｏ９、Ｎｏ１０が当てはまる。
【００５５】
コミュニティ情報変更の場合、コミュニティ管理部１−２は、コミュニティ情報ＤＢ１−６の内容を変更する（ステップＡ０４）。
【００５６】
図７、図８および図９は、コミュニティ情報ＤＢ１−６のデータモデル例である。
【００５７】
図７がクライアント１の参加しているコミュニティ一覧を管理するコミュニティ管理テーブル、図８がユーザ一覧を管理するユーザ管理テーブル、図９がコミュニティに参加しているユーザ一覧を管理するメンバ管理テーブルである。
【００５８】
コミュニティ管理部１−２は、コミュニティ操作命令を元に、これらのテーブルを変更する。
【００５９】
例えば、新規にコミュニティを生成した場合、コミュニティ識別子（以下、「コミュニティＩＤ」という）を生成し、コミュニティ名等のコミュニティ属性とともに、図７のコミュニティ管理テーブルに追加する（Ｅ１）。
【００６０】
また、コミュニティのメンバとして自分自身（コミュニティ管理装置１）を加えるため、図８のユーザ管理テーブルよりユーザＩＤ（Ｅ２）を取得して、図９のメンバ管理テーブルに登録する。
【００６１】
なお、ユーザ管理テーブルは、コミュニティ管理テーブルで管理しているコミュニティに参加しているメンバ全員を管理している。
【００６２】
コミュニティ情報変更でない場合、コミュニティ管理部１−２は、コミュニティ操作命令が共有情報の変更かどうかを判別する（ステップＡ０５）。共有情報の変更とは、コミュニティで管理している共有情報の変更を伴う操作を示す。
【００６３】
図５の例では、Ｎｏ６〜８、Ｎｏ１１が当てはまる。
【００６４】
共有情報変更の場合、コミュニティ管理部１−２は、コミュニティ操作命令をそのまま共有情報管理部１−７に渡し、共有情報管理部１−７は、共有情報ＤＢ１−７の内容を変更する（ステップＡ０６）。
【００６５】
図１０および図１１は、共有する情報として文書を想定し、共有情報ＤＢ１−８で管理する文書管理に必要なデータモデル例を示したものである。
【００６６】
図１０がクライアント１の共有している情報の実体を管理する共有情報実体管理テーブルであり、図１１がコミュニティ内の共有情報を管理しているコミュニティ共有情報管理テーブルである。
【００６７】
共有情報管理部１−７は、コミュニティ操作命令を元に、これらのテーブルを変更する。例えば、新規にコミュニティに情報を登録する場合、共有情報識別子（以下、「共有情報IＤ」という）を生成し、ファイル実体のパス等の共有情報属性とともに、図１０の共有情報管理テーブルに追加する（Ｆ１）。また、文書を登録したいコミュニティIＤに共有情報IＤを図１１の親子管理テーブルに追加する（Ｆ２）。
【００６８】
また、コミュニティ内の共有文書の親子関係はＸＭＬの構造で示す。
【００６９】
コミュニティ情報の変更も、共有情報の変更も行なわなかった場合は、操作命令が不正であるため終了する（ステップＡ１０）。
【００７０】
次に、コミュニティ情報変更、もしくは共有情報変更を行なった場合は、変更を他のメンバに伝えるかどうかを判定する（ステップＡ０７）。
【００７１】
まず、メール送受信部１−５が発行した操作命令は、他のメンバから伝えられた情報であるため、コミュニティ管理装置１から再度他のメンバに伝える必要はない。
【００７２】
次に、ユーザインタフェース１−１が発行した操作命令のうち、参加メンバが存在するコミュニティに対するコミュニティ情報ＤＢ１−６および共有情報ＤＢ１−８の変更は他のメンバに伝える必要がある。
【００７３】
対象となる操作例は、図５の表Ｄ４で丸数字で示した。
【００７４】
他のメンバに伝える必要がある場合、コミュニティ管理部１−２は、コミュニティ操作命令をメール送受信部１−５に渡し、メール送受信部１−５がメールの形式に変換してメッセージを作成する（ステップＡ０８）。
【００７５】
他のメンバに伝える必要がない場合は終了する（ステップＡ１０）。
【００７６】
メッセージの形式は、受信メッセージと同様である（図４）。
【００７７】
コミュニティ管理部１−２は、メール送受信部１−５に対して、コミュニティ情報ＤＢ１−６から図９のメンバ管理テーブルを検索して送信先を渡す。この際、自分自身は送信先に含めない。また、共有情報の実体は、ＵＲＬ形式にして渡す。
【００７８】
メール送受信部１−５がメッセージを作成するとき、メッセージの本文は、図５のＤ３で示した必要な情報を操作命令に応じてＸＭＬ形式にして付加する。共有情報の実体（例えば、ドキュメントファイル）は、コミュニティ管理部１−２から渡されたＵＲＬをもとに実体を取得し、メールの添付ファイル形式にして付加する。
【００７９】
メッセージを作成したら、メール送受信部１−５は、メールサーバ２に対してメッセージを送信し（ステップＡ０９）、終了する（ステップＡ１０）。
【００８０】
次に、複数のコミュニティ管理装置で同時に同じコミュニティ情報が変更されることを考える。
【００８１】
このときに第一の問題として、メール送受信部１−５がメールサーバ２に到着している操作命令を処理する前にユーザインタフェース１−１で同じ処理をしてしまうと、到着した操作命令が後回しになり、最新の情報が保持されないことである。これは、メールサーバ２に到着した操作命令はメール送受信部１−５が任意のタイミングで取得して処理をするモデルであるため、操作命令到着時に処理がすぐに行なわれないことが原因である。
【００８２】
第二の問題として、メールサーバ間の途中での配送遅延などの理由で、過去の操作命令がメールサーバに到着した場合、その操作命令をメール送受信部１−５で処理してしまうと、最新の情報が保持されないことである。
【００８３】
第一の問題を解決する動作ステップを図１２に示す。
【００８４】
この動作ステップは、ユーザインタフェース１−１で操作が行なわれ、コミュニティ管理部１−２に操作命令が到着したときに開始する（ステップＧ１）。
【００８５】
次に、コミュニティ管理部１−２は、メール送受信部１−５に対して、メールサーバ２に溜まっている処理はないかチェックを依頼する（ステップＧ２）。
【００８６】
メール送受信部１−５は、メールサーバ２からメールの受信を試み（ステップＧ３）、メールがあればメール内容のコミュニティ操作を行なう（ステップＧ４）。
【００８７】
取得したすべてのメールの処理が完了したら、ユーザインタフェース１−１で行なわれたコミュニティ操作の処理を行ない（ステップＧ５）、終了する。
【００８８】
これで、ユーザインタフェース１−１で行なわれた操作を実行する前の操作は事前に行なわれ、最新の情報が保持されることとなる。
【００８９】
第二の問題を解決する動作ステップを図１３に示す。
【００９０】
この動作ステップは、図２のステップＧ４、ステップＧ５が開始した時点で開始する（ステップＨ１）。
【００９１】
メール送受信部１−５は、メールを受信したときに、コミュニティ管理部１−２へコミュニティ情報操作命令を発行するが、そのときに、同時にメールの送信日時であるＤＡＴＥヘッダを取り出し、コミュニティ管理部１−２へ送る。
【００９２】
また、ユーザインタフェース１−１からコミュニティ管理部１−２へコミュニティ操作命令を発行したときは、ユーザインタフェース１−１が命令を発行した時間をコミュニティ管理部１−２へ送る（ステップＨ２）。
【００９３】
次に、コミュニティ管理部１−２もしくは、コミュニティ管理部１−２を通して共有情報管理部１−７が、コミュニティ情報ＤＢ１−６もしくは、共有情報ＤＢ１−８へ情報を登録するが、その際、メールのＤＡtＥヘッダに含まれていた送信日時と、ＤＢ内のデータごとに付加されている修正日時を比較する（ステップＨ３）。
【００９４】
図７〜図１１の各テーブルには、修正日時カラムが用意してあり、それぞれの情報に修正日時を登録しておく。
【００９５】
比較した結果、メールの送信日時のほうが、ＤＢの修正日時より新しければ、ＤＢのデータを更新する（ステップＨ４）。
【００９６】
新しくなければ登録せずに終了する（ステップＨ５）。これにより、データが到着した時点での最新の情報が保持されることになり、古い情報で上書きされることはない。
【００９７】
上記の実施の形態によれば、メールの送受信ができればコミュニティを形成し、メンバ間で情報共有ができる。この結果、情報共有のためのサーバや、直接他のメンバにアクセスするためのネットワーク到達性が不要となる。これは、コミュニティ情報の配信にメールの手段を利用しているからである。
【００９８】
また、配送先のメンバがオフラインでも確実にコミュニティ情報を配送することができる。この結果、コミュニティ情報変更時に他のメンバのオンライン、オフラインを判別し、再送する等の特別な処理が不要となる。これは、メールサーバがキャッシュの役割を果たしているからである。
【００９９】
また、メンバへコミュニティ情報を配送するため、メールサーバ以外の特別な装置が不要となる。この結果、コミュニティを形成するために利用者は、コミュニティ管理装置だけを用意すれば足りることとなる。
【０１００】
なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、上記の実施の形態におけるコミュニティ管理装置１、コミュニティ管理装置４、コミュニティ管理装置６、メールサーバ２、メールサーバ３およびメールサーバ５の機能を実現するためのプログラムを各装置等に読込ませて実行することにより本システムの機能を実現する処理を行なってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスク等を介して、または伝送媒体であるインターネット、電話回線等を介して伝送波により他のコンピュータシステムに伝送されてもよい。
【０１０１】
また、複数の企業、個人、政府機関等の間でコミュニティを作成して情報を共有するためのシステムとして利用可能である。特に、ネットワーク到達性、サーバ構築、保守管理等の問題でメンバ間で直接もしくはサーバを介して情報を共有することが困難な場合に有効である。
【図面の簡単な説明】
【０１０２】
【図１】本発明の実施形態におけるコミュニティ管理システムの概略構成図である。
【図２】本発明の実施形態におけるコミュニティ管理処理動作を示すフローチャートである。
【図３】ユーザインタフェースを具現化した一例を示す図である。
【図４】メール送受信部が受信するコミュニティ操作命令の一例を示す図である。
【図５】コミュニティ管理部が解釈するコミュニティ操作命令の一例を示す図である。
【図６】コミュニティ識別子、ユーザ識別子、共有情報識別子等の一例を示す図である。
【図７】コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。
【図８】コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。
【図９】コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。
【図１０】共有情報ＤＢで管理する文書管理に必要なデータモデルの一例を示す図である。
【図１１】共有情報ＤＢで管理する文書管理に必要なデータモデルの一例を示す図である。
【図１２】第一の問題を解決する動作ステップを示すフローチャートである。
【図１３】第二の問題を解決する動作ステップを示すフローチャートである。
【符号の説明】
【０１０３】
１、４、６    コミュニティ管理装置
２、３、５    メールサーバ
１−１    ユーザインタフェース
１−２    メコミュニティ管理部
１−５    メール送受信部
１−６    コミュニティ情報ＤＢ
１−７    共有情報管理部
１−８    共有情報ＤＢ
【図１】
2006244423.tif 000003
【図２】
2006244423.tif 000004
【図３】
2006244423.tif 000005
【図４】
2006244423.tif 000006
【図５】
2006244423.tif 000007
【図６】
2006244423.tif 000008
【図７】
2006244423.tif 000009
【図８】
2006244423.tif 000010
【図９】
2006244423.tif 000011
【図１０】
2006244423.tif 000012
【図１１】
2006244423.tif 000013
【図１２】
2006244423.tif 000014
【図１３】
2006244423.tif 000015