JP4434043B2 - コミュニティ管理装置、コミュニティ管理システム、コミュニティ管理方法およびプログラム - Google Patents

Description

本発明は、クライアントマシンだけで情報を共有する空間を形成できるコミュニティ管理装置、コミュニティ管理システム、コミュニティ管理方法およびプログラムに関する。

ビジネスにおけるプロジェクトやチームのように、参加メンバを限定した「閉じた」コミュニティで情報を共有する場合には、グループウェアに代表されるようなセンターサーバでコミュニティを集中管理する方法がある。

しかし、ファイアウォールを越えられないなどの理由でセンタサーバにアクセスできないユーザはコミュニティに加わることができなかった。

これを解決するために、特許文献１でピア・ツー・ピアで情報を共有する方式が提案されている。本方式は、各コンピュータに情報を共有するためのフォルダを用意してファイルを保存しておき、ファイルごとに誰に公開するか公開条件を記憶しておき、対象となるユーザからの検索要求があれば、該当する情報を提供するシステムであり、検索依頼、および、文書実体を含めた検索結果のやり取りを電子メールで行なっている。

このため、情報共有のためのサーバが不要であり、電子メールさえやり取りできれば、すぐに情報を共有できるとしている。

ただし、本方式は、個別のユーザに電子メールという形式で情報を公開しているだけであり、同じ情報をお互いに保有し変更したら、お互いに変更が反映されるということはできない。また、個別ユーザごとの情報共有方式であり、コミュニティを形成し、コミュニティの中で情報共有することはできない。

同様に、特許文献２では、ファイアウォールを越えてファイル管理サーバ同士で情報を同期する方式が提案されているが、ファイルの同期方法を示したものであって、コミュニティを形成することはできない。

また、特許文献３および特許文献４において、ネットワークに接続されたローカルデバイス間で共有情報を同期する方式が提案されている。本方式は、デルタと呼ばれる情報の差分を他のローカルデバイスと同期させるときに、各ローカルデバイスに存在する通信マネージャが、送信先が直接接続できるかどうかを判別し、直接接続できるならば直接デルタを送信する。直接接続できない場合は、リレーと呼ばれるサーバ（以下、「リレーサーバ」という）に送信処理を依頼する。

リレーサーバは、ローカルデバイスが通信可能か否かを管理しているプレゼンス機構を持ち、送信先が通信可能になればデルタを送信する。リレーサーバは、送信先が通信可能になるまでデルタを保持している。

本方式は、ほぼリアルタイムにコミュニティ内で共有情報を同期するためには有効な機構であるが、反面、リレーサーバと呼ばれるサーバを用意しなければならないことと、各ローカルデバイスの通信マネージャが、送受信の管理を行わなければならずシステムとして複雑になるという問題がある。

また、リレーサーバにアクセスできないユーザはコミュニティに参加できないという問題がある。

さらに、本システムのリレーサーバをメールサーバにした場合は、ユーザがリレーサーバにアクセスできないという問題は解消されるが、通信マネージャに到着した順番にデルタの処理を行なう構造になっているため、デルタ到着順と実際の更新時間の順序が異なる可能性がある電子メールを使用した場合には最新の情報を保持できないという問題がある。

ここで、複数の作業者から成るグループでの作業を支援するグループウェアシステムと複数の作業者に関する個人情報をそれぞれ管理する複数の個人情報管理システムとから構成され、グループウェアシステムを構成するグループウェア端末が保持するグループウェア情報を格納するグループウェア管理テーブルと、各個人情報管理システムを構成する個人情報端末が保持する個人情報を格納し、変更後の個人情報に基づいてグループウェア情報が変更されるときに参照される同期管理テーブルとを備えたことにより、個人情報端末の情報が変更された場合でも、同期管理テーブルがグループウェア管理テーブルのグループウェア情報と個人情報管理テーブルの個人情報との関係を示しているので、グループウェア情報と個人情報を一致させることができる技術が提案されている（例えば、特許文献５参照）。
特開２００２−２２９８３６号公報 特開２００２−１４９４６５号公報 特表２００３−５３６１２３号公報 特表２００３−５０５７６０号公報 特開２０００−１４８６９１号公報

しかしながら、上述した従来例においては次のような問題点があった。

ビジネスにおけるプロジェクトやチームのように、参加メンバを限定した「閉じた」コミュニティで情報を共有する場合には、グループウェアに代表されるようなセンターサーバでコミュニティを集中管理する方法があるが、ファイアウォールを越えられないなどの理由でセンターサーバにアクセスできないユーザはコミュニティに加わることができなかった。

また、情報を共有するためにセンターサーバを用意しなければならず、サーバが用意されていない場合、アドホックにコミュニティを形成するのは困難であった。

また、情報を共有するためのセンターサーバを用意せず、クライアント間でピア・ツー・ピア技術を利用してコミュニティを作成し情報を共有するシステムも存在するが、やはりピア・ツー・ピアで参加メンバ同士が接続できなければならないため、ファイウォールを越えられないなどの理由でお互いに通信できないユーザはコミュニティに加わることができなかった。

別の手段として、ネットワークの壁を越えてコミュニティで情報共有をするためにはメーリングリストを利用することが考えられるが、メーリングリストはコミュニティのメンバを管理し情報を配送する手段であって、メンバ間で情報を同じモデルで管理しているわけではなく、メンバ同士で同じ情報を同じように参照できなかった。

そこで、本発明は、コミュニティに参加するクライアントマシン同士で、電子メールを使ってコミュニティ属性情報とコミュニティ共有情報を保持することで、クライアントマシンだけで情報を共有する空間を形成できるコミュニティ管理装置、コミュニティ管理システム、コミュニティ管理方法およびプログラムを提供することを目的とする。

本発明のコミュニティ管理装置は、コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、コミュニティで共有している共有情報を記憶する共有情報ＤＢと、ユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換するユーザインタフェース部と、専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をするメール送受信部と、前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡す共有情報管理部と、前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティ情報ＤＢで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡すコミュニティ管理部と、を備えることを特徴とする。

本発明のコミュニティ管理方法は、コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、コミュニティで共有している共有情報を記憶する共有情報ＤＢとを備えるコミュニティ管理装置が、ユーザインタフェース部によってユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換するステップと、メール送受信部によって専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をするステップと、共有情報管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡すステップと、コミュニティ管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティ情報ＤＢで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡すステップと、を有することを特徴とする。

本発明のプログラムは、コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、コミュニティで共有している共有情報を記憶する共有情報ＤＢとを備えるコミュニティ管理装置に、ユーザインタフェース部によってユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換する処理と、メール送受信部によって専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をする処理と、共有情報管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティ情報ＤＢで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡す処理と、コミュニティ管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡す処理と、を実行させることを特徴とする。

本発明のコミュニティ管理装置、コミュニティ管理システム、コミュニティ管理方法およびプログラムによれば、クライアントマシンだけで情報を共有する空間を形成できる。

次に、本発明の一実施の形態について図を参照して詳細に説明する。

図１を参照すると、本実施の形態におけるコミュニティ管理システムは、パーソナルコンピュータ等の端末装置で動作するコミュニティ管理装置１とコミュニティ管理装置１がアクセスできるメールサーバ２を含む。

コミュニティ管理装置１は、コミュニティ管理装置１に対するコミュニティ操作のユーザインタフェースをつかさどるユーザインタフェース１−１と、コミュニティ操作命令を受け、コミュニティ情報を変更するコミュニティ管理部１−２、コミュニティ情報のうち、コミュニティで管理する共有情報を変更する共有情報管理部１−７、コミュニティ操作命令をメール形式にし他のメンバへ送信し、また、他のメンバからのメールを受信するメール送受信部１−５、コミュニティ情報を管理するための記憶装置であるコミュニティ情報ＤＢ１−６および共有情報を管理するための記憶装置である共有情報ＤＢ１−８を備える。

コミュニティ管理ＤＢ１−６は、コミュニティ管理装置１が参加しているコミュニティ一覧と、コミュニティに参加しているメンバ一覧を管理するＤＢである。

共有情報ＤＢ１−８は、コミュニティ管理装置１で管理しているコミュニティが保持している共有情報一覧を管理するＤＢである。

コミュニティ管理装置４およびコミュニティ管理装置６は、コミュニティ管理装置１と同様の構成である。

また、それぞれのコミュニティ管理装置は、メールサーバ３ないしメールサーバ５にアクセスできる。

メールサーバ２は、メール送受信部１−５からの要求にしたがって指定したメールアドレスにメールを配送し、また、他のメールサーバからメール送受信部１−５に配送されてきたメールを保持しておき、メール送受信部１の取得要求に応じて保持していたメールを返却する。同様に、メールサーバ３、５はコミュニティ管理装置４、６に対するメールの処理を行なう。

次に、図１および図２を参照して本実施の形態における処理動作について詳細に説明する。

本システムの動作の開始（図２のステップＡ０１）となるのは、コミュニティ管理装置１のユーザインタフェース１−１で利用者がコミュニティ情報、もしくは、コミュニティで共有している情報を操作したとき、および、メール送受信部１−５がメールサーバ２より別のコミュニティ管理装置からのコミュニティ操作命令を受信したときである。

メール送受信部１−５は、定期的に、もしくは、コミュニティ管理部１−２からの依頼に応じて、メールサーバ２よりメールを取得する。

図３は、ユーザインタフェースを具現化した例である。

Ｂ１にコミュニティ情報に対する操作を行なうためのメニューコマンドがあり、Ｂ２には参加しているコミュニティ一覧が表示される。

Ｂ２において一つだけコミュニティを選択でき、Ｂ３は、Ｂ２で選択したコミュニティで共有しているファイル一覧、Ｂ４は、Ｂ２で選択したコミュニティの参加者一覧が表示される。

ユーザインタフェース１−１の利用者が、メニューコマンドでコミュニティに対する操作を行なうことで動作が開始する。

図４は、メール送受信部１−５が受信するコミュニティ操作命令の例である。

コミュニティ操作命令はメール形式になっており、操作内容がメールの拡張ヘッダとして（図４のＣ１）、操作データがメールの本文（Ｃ２）に記述されている。

メール送受信部１−５がこのメールを受信することで動作が開始する。

次に、ユーザインタフェース１−１もしくは、メール送受信部１−５は、利用者もしくは、他のコミュニティ管理装置４からの操作内容を解釈し、コミュニティ管理部１−２が解釈できる形式に変換後、コミュニティ１−２に渡す（ステップＡ０２）。

例えば、コミュニティ管理部１−２が操作命令と必要な情報をＸＭＬ形式で理解する場合は、ユーザインタフェース１−１やメール送受信部１−５は、操作内容をＸＭＬ形式に変換してコミュニティ管理部１−２に渡す。

図５は、コミュニティ管理部１−２が解釈するコミュニティ操作命令の例である。Ｄ１は操作命令、Ｄ２は操作命令に付随する情報、Ｄ３はメールの拡張ヘッダに記述する操作内容を示す。

Ｄ２の情報における、コミュニティ識別子、ユーザ識別子、共有情報識別子等の識別情報は、グローバルで一意になるような文字列であり、例えば、図６のようにネットワークアダプタのＭＡＣアドレスと時間を組み合わせたものとする。

なお、ユーザ識別子（以下、「ユーザIＤ」という）は、コミュニティ管理装置ごとに一つだけ割り当てられ、初回起動時に設定された後は不変である。

コミュニティ管理部１−２は、コミュニティ操作命令を受け取ると、まず、コミュニティ情報の変更かどうかを判別する（ステップＡ０３）。コミュニティ情報の変更とは、コミュニティもしくはメンバ情報の変更を伴う操作を示す。

図５の例では、Ｎｏ１〜Ｎｏ５、Ｎｏ９、Ｎｏ１０が当てはまる。

コミュニティ情報変更の場合、コミュニティ管理部１−２は、コミュニティ情報ＤＢ１−６の内容を変更する（ステップＡ０４）。

図７、図８および図９は、コミュニティ情報ＤＢ１−６のデータモデル例である。

図７がクライアント１の参加しているコミュニティ一覧を管理するコミュニティ管理テーブル、図８がユーザ一覧を管理するユーザ管理テーブル、図９がコミュニティに参加しているユーザ一覧を管理するメンバ管理テーブルである。

コミュニティ管理部１−２は、コミュニティ操作命令を元に、これらのテーブルを変更する。

例えば、新規にコミュニティを生成した場合、コミュニティ識別子（以下、「コミュニティＩＤ」という）を生成し、コミュニティ名等のコミュニティ属性とともに、図７のコミュニティ管理テーブルに追加する（Ｅ１）。

また、コミュニティのメンバとして自分自身（コミュニティ管理装置１）を加えるため、図８のユーザ管理テーブルよりユーザＩＤ（Ｅ２）を取得して、図９のメンバ管理テーブルに登録する。

なお、ユーザ管理テーブルは、コミュニティ管理テーブルで管理しているコミュニティに参加しているメンバ全員を管理している。

コミュニティ情報変更でない場合、コミュニティ管理部１−２は、コミュニティ操作命令が共有情報の変更かどうかを判別する（ステップＡ０５）。共有情報の変更とは、コミュニティで管理している共有情報の変更を伴う操作を示す。

図５の例では、Ｎｏ６〜８、Ｎｏ１１が当てはまる。

共有情報変更の場合、コミュニティ管理部１−２は、コミュニティ操作命令をそのまま共有情報管理部１−７に渡し、共有情報管理部１−７は、共有情報ＤＢ１−７の内容を変更する（ステップＡ０６）。

図１０および図１１は、共有する情報として文書を想定し、共有情報ＤＢ１−８で管理する文書管理に必要なデータモデル例を示したものである。

図１０がクライアント１の共有している情報の実体を管理する共有情報実体管理テーブルであり、図１１がコミュニティ内の共有情報を管理しているコミュニティ共有情報管理テーブルである。

共有情報管理部１−７は、コミュニティ操作命令を元に、これらのテーブルを変更する。例えば、新規にコミュニティに情報を登録する場合、共有情報識別子（以下、「共有情報IＤ」という）を生成し、ファイル実体のパス等の共有情報属性とともに、図１０の共有情報管理テーブルに追加する（Ｆ１）。また、文書を登録したいコミュニティIＤに共有情報IＤを図１１の親子管理テーブルに追加する（Ｆ２）。

また、コミュニティ内の共有文書の親子関係はＸＭＬの構造で示す。

コミュニティ情報の変更も、共有情報の変更も行なわなかった場合は、操作命令が不正であるため終了する（ステップＡ１０）。

次に、コミュニティ情報変更、もしくは共有情報変更を行なった場合は、変更を他のメンバに伝えるかどうかを判定する（ステップＡ０７）。

まず、メール送受信部１−５が発行した操作命令は、他のメンバから伝えられた情報であるため、コミュニティ管理装置１から再度他のメンバに伝える必要はない。

次に、ユーザインタフェース１−１が発行した操作命令のうち、参加メンバが存在するコミュニティに対するコミュニティ情報ＤＢ１−６および共有情報ＤＢ１−８の変更は他のメンバに伝える必要がある。

対象となる操作例は、図５の表Ｄ４で丸数字で示した。

他のメンバに伝える必要がある場合、コミュニティ管理部１−２は、コミュニティ操作命令をメール送受信部１−５に渡し、メール送受信部１−５がメールの形式に変換してメッセージを作成する（ステップＡ０８）。

他のメンバに伝える必要がない場合は終了する（ステップＡ１０）。

メッセージの形式は、受信メッセージと同様である（図４）。

コミュニティ管理部１−２は、メール送受信部１−５に対して、コミュニティ情報ＤＢ１−６から図９のメンバ管理テーブルを検索して送信先を渡す。この際、自分自身は送信先に含めない。また、共有情報の実体は、ＵＲＬ形式にして渡す。

メール送受信部１−５がメッセージを作成するとき、メッセージの本文は、図５のＤ３で示した必要な情報を操作命令に応じてＸＭＬ形式にして付加する。共有情報の実体（例えば、ドキュメントファイル）は、コミュニティ管理部１−２から渡されたＵＲＬをもとに実体を取得し、メールの添付ファイル形式にして付加する。

メッセージを作成したら、メール送受信部１−５は、メールサーバ２に対してメッセージを送信し（ステップＡ０９）、終了する（ステップＡ１０）。

次に、複数のコミュニティ管理装置で同時に同じコミュニティ情報が変更されることを考える。

このときに第一の問題として、メール送受信部１−５がメールサーバ２に到着している操作命令を処理する前にユーザインタフェース１−１で同じ処理をしてしまうと、到着した操作命令が後回しになり、最新の情報が保持されないことである。これは、メールサーバ２に到着した操作命令はメール送受信部１−５が任意のタイミングで取得して処理をするモデルであるため、操作命令到着時に処理がすぐに行なわれないことが原因である。

第二の問題として、メールサーバ間の途中での配送遅延などの理由で、過去の操作命令がメールサーバに到着した場合、その操作命令をメール送受信部１−５で処理してしまうと、最新の情報が保持されないことである。

第一の問題を解決する動作ステップを図１２に示す。

この動作ステップは、ユーザインタフェース１−１で操作が行なわれ、コミュニティ管理部１−２に操作命令が到着したときに開始する（ステップＧ１）。

次に、コミュニティ管理部１−２は、メール送受信部１−５に対して、メールサーバ２に溜まっている処理はないかチェックを依頼する（ステップＧ２）。

メール送受信部１−５は、メールサーバ２からメールの受信を試み（ステップＧ３）、メールがあればメール内容のコミュニティ操作を行なう（ステップＧ４）。

取得したすべてのメールの処理が完了したら、ユーザインタフェース１−１で行なわれたコミュニティ操作の処理を行ない（ステップＧ５）、終了する。

これで、ユーザインタフェース１−１で行なわれた操作を実行する前の操作は事前に行なわれ、最新の情報が保持されることとなる。

第二の問題を解決する動作ステップを図１３に示す。

この動作ステップは、図２のステップＧ４、ステップＧ５が開始した時点で開始する（ステップＨ１）。

メール送受信部１−５は、メールを受信したときに、コミュニティ管理部１−２へコミュニティ情報操作命令を発行するが、そのときに、同時にメールの送信日時であるＤＡＴＥヘッダを取り出し、コミュニティ管理部１−２へ送る。

また、ユーザインタフェース１−１からコミュニティ管理部１−２へコミュニティ操作命令を発行したときは、ユーザインタフェース１−１が命令を発行した時間をコミュニティ管理部１−２へ送る（ステップＨ２）。

次に、コミュニティ管理部１−２もしくは、コミュニティ管理部１−２を通して共有情報管理部１−７が、コミュニティ情報ＤＢ１−６もしくは、共有情報ＤＢ１−８へ情報を登録するが、その際、メールのＤＡtＥヘッダに含まれていた送信日時と、ＤＢ内のデータごとに付加されている修正日時を比較する（ステップＨ３）。

図７〜図１１の各テーブルには、修正日時カラムが用意してあり、それぞれの情報に修正日時を登録しておく。

比較した結果、メールの送信日時のほうが、ＤＢの修正日時より新しければ、ＤＢのデータを更新する（ステップＨ４）。

新しくなければ登録せずに終了する（ステップＨ５）。これにより、データが到着した時点での最新の情報が保持されることになり、古い情報で上書きされることはない。

上記の実施の形態によれば、メールの送受信ができればコミュニティを形成し、メンバ間で情報共有ができる。この結果、情報共有のためのサーバや、直接他のメンバにアクセスするためのネットワーク到達性が不要となる。これは、コミュニティ情報の配信にメールの手段を利用しているからである。

また、配送先のメンバがオフラインでも確実にコミュニティ情報を配送することができる。この結果、コミュニティ情報変更時に他のメンバのオンライン、オフラインを判別し、再送する等の特別な処理が不要となる。これは、メールサーバがキャッシュの役割を果たしているからである。

また、メンバへコミュニティ情報を配送するため、メールサーバ以外の特別な装置が不要となる。この結果、コミュニティを形成するために利用者は、コミュニティ管理装置だけを用意すれば足りることとなる。

なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、上記の実施の形態におけるコミュニティ管理装置１、コミュニティ管理装置４、コミュニティ管理装置６、メールサーバ２、メールサーバ３およびメールサーバ５の機能を実現するためのプログラムを各装置等に読込ませて実行することにより本システムの機能を実現する処理を行なってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスク等を介して、または伝送媒体であるインターネット、電話回線等を介して伝送波により他のコンピュータシステムに伝送されてもよい。

また、複数の企業、個人、政府機関等の間でコミュニティを作成して情報を共有するためのシステムとして利用可能である。特に、ネットワーク到達性、サーバ構築、保守管理等の問題でメンバ間で直接もしくはサーバを介して情報を共有することが困難な場合に有効である。

本発明の実施形態におけるコミュニティ管理システムの概略構成図である。 本発明の実施形態におけるコミュニティ管理処理動作を示すフローチャートである。 ユーザインタフェースを具現化した一例を示す図である。 メール送受信部が受信するコミュニティ操作命令の一例を示す図である。 コミュニティ管理部が解釈するコミュニティ操作命令の一例を示す図である。 コミュニティ識別子、ユーザ識別子、共有情報識別子等の一例を示す図である。 コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。 コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。 コミュニティ情報ＤＢ１−６のデータモデルの一例を示す図である。 共有情報ＤＢで管理する文書管理に必要なデータモデルの一例を示す図である。 共有情報ＤＢで管理する文書管理に必要なデータモデルの一例を示す図である。 第一の問題を解決する動作ステップを示すフローチャートである。 第二の問題を解決する動作ステップを示すフローチャートである。

符号の説明

１、４、６ コミュニティ管理装置
２、３、５ メールサーバ
１−１ ユーザインタフェース
１−２ メコミュニティ管理部
１−５ メール送受信部
１−６ コミュニティ情報ＤＢ
１−７ 共有情報管理部
１−８ 共有情報ＤＢ

Claims (7)

1. コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、
   コミュニティで共有している共有情報を記憶する共有情報ＤＢと、
   ユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換するユーザインタフェース部と、
   専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をするメール送受信部と、
   前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡す共有情報管理部と、
   前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティ情報ＤＢで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡すコミュニティ管理部と、
   を備えることを特徴とするコミュニティ管理装置。
2. 操作命令を前記ユーザインタフェース部から受け取った場合に、前記メール送受信部がメール受信を行い、その後に前記ユーザインタフェース部から受け取った操作命令を実行し、前記メール送受信部によるメール受信により操作命令を受信した場合にその受信した操作命令の時刻を判定し前記時刻が前記ＤＢの修正日時より新しい場合にその受信した操作命令を実行することを特徴とする請求項１記載のコミュニティ管理装置。
3. メールサーバと、請求項１または２記載のコミュニティ管理装置がネットワークを
   介して接続されていることを特徴とするコミュニティ管理システム。
4. コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、コミュニティで共有している共有情報を記憶する共有情報ＤＢとを備えるコミュニティ管理装置が、
   ユーザインタフェース部によってユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換するステップと、
   メール送受信部によって専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をするステップと、
   共有情報管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡すステップと、
   コミュニティ管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティ情報ＤＢで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡すステップと、
   を有することを特徴とするコミュニティ管理方法。
5. 前記操作命令を前記ユーザインタフェース部から受け取った場合に、前記メール送受信部がメール受信を行い、その後に前記ユーザインタフェース部から受け取った操作命令を実行し、前記メール送受信部によるメール受信により操作命令を受信した場合にその受信した操作命令の時刻を判定し前記時刻が前記ＤＢの修正日時より新しい場合にその受信した操作命令を実行することを特徴とする請求項４記載のコミュニティ管理方法。
6. コミュニティ一覧と前記コミュニティ一覧のコミュニティメンバのアドレスから構成されるコミュニティ情報を記憶するコミュニティ情報ＤＢと、コミュニティで共有している共有情報を記憶する共有情報ＤＢとを備えるコミュニティ管理装置に、
   ユーザインタフェース部によってユーザとのインタフェースを司り、前記ユーザの自コミュニティ管理装置に対する指示を操作命令に変換する処理と、
   メール送受信部によって専用のアドレスが割り振られ、前記専用のアドレスを有するメールを送受信し、前記操作命令をメール形式に変換し他のコミュニティ管理装置へ送信し、また、他の前記コミュニティ管理装置からの前記メール形式に変換された操作命令を受信し操作命令に戻す変換をする処理と、
   共有情報管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令が共有情報操作命令の場合に前記コミュニティ情報ＤＢで管理する共有情報を変更し、前記共有情報操作命令を前記ユーザインタフェース部から受け取った場合に、前記共有情報操作命令を前記メール送受信部へ渡す処理と、
   コミュニティ管理部によって前記ユーザインタフェース部および前記メール送受信部のいずれかから受け取った前記操作命令がコミュニティ操作命令の場合に前記コミュニティで管理するコミュニティ情報を変更し、前記コミュニティ操作命令を前記ユーザインタフェース部から受け取った場合に、前記コミュニティ一覧を参照し前記コミュニティメンバが存在する場合に前記コミュニティ操作命令と前記コミュニティメンバのアドレスを前記メール送受信部へ渡す処理と、
   を実行させることを特徴とするプログラム。
7. 前記操作命令を前記ユーザインタフェース部から受け取った場合に、前記メール送受信部がメール受信を行い、その後に前記ユーザインタフェース部から受け取った操作命令を実行させ、前記メール送受信部によるメール受信により操作命令を受信した場合にその受信した操作命令の時刻を判定させ前記時刻が前記ＤＢの修正日時より新しい場合にその受信した操作命令を実行させることを特徴とする請求項６記載のプログラム。

Images