JP3961792B2 - 知識蓄積支援システムおよび同システムにおける管理者設定方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明はナレッジマネジメントシステムで用いられる知識蓄積支援システムおよび同システムにおけるコミュニティ管理者設定方法並びにメッセージ削除方法に係り、特に、不特定多数のユーザが参加する仮想コミュニティを用いて知識の蓄積を支援する知識蓄積支援システムおよび同システムにおけるコミュニティ管理者設定方法並びにメッセージ削除制御方法に関する。
【０００２】
【従来の技術】
近年、企業を中心に複数のユーザ間で情報共有を行うためのグループウェアの導入が進められている。代表的なグループウェアとしては、電子メールシステムやワークフローシステムなどが知られているが、最近では、知識や情報の共有支援を図るためのナレッジマネジメントシステムも開発され始めている。
【０００３】
このナレッジマネジメントシステムは、Ｗｅｂ情報や電子ファイル情報などに加え、個人のノウハウなどを知識データベースとして蓄積・管理するためのものであり、自然言語検索などの検索機能と組み合わせることにより、知識、情報の効率的な活用が可能となる。
【０００４】
ところで、このようなナレッジマネジメントシステムにおいては、個人のノウハウなどの知識をどのように収集・蓄積するかが重要となる。個人のノウハウなどの知識はいわゆる暗黙知であって、Ｗｅｂ情報や電子ファイル情報などのように形式化されたものではないため、それを自動的に収集、蓄積することは困難であるからである。
【０００５】
そこで、最近では、知識蓄積支援機能を持つナレッジマネジメントシステムの開発が要求されている。個人のノウハウなどの知識を自動的に収集・蓄積する仕組みを実現することにより、暗黙知としての知識をもＷｅｂ情報や電子ファイル情報などのような形式化された形式知と同様に活用することが可能となる。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来のナレッジマネジメントシステムでは、メッセージの投稿、閲覧を行うためのコミュニティの管理は、予め決められた特定の管理者にゆだねられており、例えばミュニティの削除や変更などはその管理者のみしか行うことができなかった。このため、コミュニティ管理者が例えば他部門に異動した場合などには、このコミュニティを管理維持していくことが困難となるという問題があった。
【０００７】
また、ユーザがあるコミュニティにメッセージを投稿した場合、コミュニティ管理者のみが投稿メッセージを削除できる権限を有していたため、このユーザすなわちメッセージ投稿者が投稿メッセージを削除することはできず、さらに投稿メッセージに誤り等があった場合には修正版の投稿メッセージを改めて投稿しなければならなかったといった問題があった。
【０００８】
この発明はこのような事情を考慮してなされたものであり、個人のノウハウなどの知識を効率よく収集・蓄積でき、しかもコミュニティの管理やメッセージの削除等に関して適切且つ柔軟に対応することが可能な知識蓄積支援システムおよび同システムにおけるコミュニティ管理者設定方法並びにメッセージ削除方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
前述した目的を達成するために、この発明は、複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムであって、前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御手段と、複数のクライアント端末が参加可能な仮想コミュニティ毎に投稿用メールアドレスを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から電子メールによって投稿されるメッセージのメールアドレスがどの仮想コミュニティの投稿用メールアドレスに対応するかを判別すると共に、前記メッセージに対応する電子メールのヘッダ情報またはタイトルに基づいて、前記メッセージが、前記判別された仮想コミュニティに対して既に投稿されているどのメッセージに対する返信メッセージであるかを判別することによって、前記各クライアント端末からのメッセージを、仮想コミュニティ毎に、且つ、投稿されたメッセージとそれに対する返信メッセージとの関係にある同一の話題に関するメッセージの束であるスレッド毎に、分類、蓄積するコミュニティ処理手段と、各仮想コミュニティ毎に当該仮想コミュニティの管理者ユーザを示す管理者リスト情報と、各仮想コミュニティ毎に当該仮想コミュニティのメンバを示すメンバリスト情報と、前記各メンバ毎に、当該メンバが仮想コミュニティに対して、参加が承認されている参加者として参加しているか否かを示すメンバタイプ情報とを含むコミュニティ管理情報を記憶する手段とを具備し、前記コミュニティ処理手段は、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの交代が要求された場合、前記管理者ユーザの交代が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中から前記管理者ユーザ以外のメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ交代処理手段と、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの追加が要求された場合、前記管理者ユーザの追加が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中からメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ追加処理手段と、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの削除が要求された場合、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザであるメンバそれぞれを前記管理者リスト情報から検索して前記検索されたメンバを管理者データとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記メンバの中から前記管理者ユーザ以外のメンバが選択された場合、前記選択されたメンバを、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザから削除すると共に当該削除結果を前記コミュニティ管理情報に反映し、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザからの、前記削除を要求した管理者ユーザ自身の削除を禁止する管理者ユーザ削除処理手段とを含むことを特徴とする。
【００１１】
この知識蓄積支援システムにおいては、仮想コミュニティ上でユーザ同士が交わすメッセージは話題毎に分類、蓄積され、これにより複数のユーザ間で交わされる会話の中に含まれる個人の知識が自動収集される。特に、仮想コミュニティ各仮想コミュニティ毎に当該仮想コミュニティの管理者を示す管理者リスト情報と、各仮想コミュニティ毎に当該仮想コミュニティのメンバを示すメンバリスト情報と、前記各メンバ毎に、当該メンバが仮想コミュニティに対して、参加が承認されている参加者として参加しているか否かを示すメンバタイプ情報とを含むコミュニティ管理情報を用いることによって、管理者権限の付与のみならず、各仮想コミュニティ毎に、その仮想コミュニティの参加者を対象にして、管理者の交代、追加、および削除を実行することができるので、仮想コミュニティの管理・維持に好適な仕組みが提供される。
【００１３】
【発明の実施の形態】
以下、図面を参照してこの発明の一実施形態を説明する。
図１には、この発明の一実施形態に係る知識蓄積支援システムの構成が示されている。この知識蓄積支援システムは、知識蓄積支援機能を持つナレッジマネジメントシステムとして利用されるものであり、複数のクライアント端末１１が共通に利用可能な仮想コミュニティを用いて、知識の分類、蓄積を行う。具体的な構成の説明を行う前に、まず、図２乃至図５を用いて、この実施形態に係る知識蓄積支援システムの概要を説明することにする。
【００１４】
図２に示されているように、知識には「形式知」と「暗黙知」とが存在する。現在、文書管理システムやＷｅｂサーバなど、形式化された情報（形式知）に対する整理、管理の体系は完成されつつある。しかし、実際のところ、それらによって「知識の蓄積」という点の全てを賄えているわけではない。これは、単にメールによって交わされるだけの軽い会話や、各人の頭の中だけにある知識など、非常に不明確な情報が存在しているからである。これが「暗黙知」と呼ばれるものである。この暗黙知をいかにうまく取り扱い、それを共有していくかが重要である。従来のシステムでは、暗黙知の蓄積を支援することは困難であり、暗黙知を取り扱うためのシステムが必要である。
【００１５】
この実施形態の知識蓄積支援システムは、このような暗黙知と呼ばれる情報を形式知化し、知識の蓄積促進を目的としたツールであり、グループにおけるディスカッションを電子掲示板形式の仮想コミュニティで行い、メッセージ（投稿記事）をその話題毎に分類、蓄積する。１つの話題（以下、スレッドと称する）に対して、まとめを作成することも出来る。スレッドは仮想コミュニティ上における関連性のある知識の束を意味する。まとめは、グループにおけるディスカッションを総括する一種の議事録としての役割を持つメッセージであり、スレッド毎に作成することが出来る。
【００１６】
メッセージの投稿は、電子メールまたはＷｅｂブラウザからの入力によって行い、投稿されたメッセージは知識蓄積支援システムを構成するサーバ内に蓄積される。この知識蓄積支援システムにおいては、電子メールによるメッセージの投稿も可能であり、メーリングリストとしての側面も持つ。各ユーザがメールによって会話を行うだけで、知らず知らずのうちに暗黙知が蓄積されていく。この様子を図３に示す。
【００１７】
図３には、スポーツに関する仮想コミュニティである「スポーツコミュニティ」と、英語勉強会に関する仮想コミュニティである「英語勉強会コミュニティ」と、ある開発メンバ同士の仮想コミュニティである「○×開発メンバコミュニティ」とが示されている。各ユーザからの投稿メッセージはこれら各仮想コミュニティ毎に分類・蓄積され、また各仮想コミュニティ内ではスレッド毎に分類される。図３では、「スポーツコミュニティ」にはスレッド１，２，３の３種類の話題に関するメッセージが現在蓄積されており、また、「英語勉強会コミュニティ」にはスレッド１，２の２種類の話題に関するメッセージが蓄積され、「○×開発メンバコミュニティ」にはスレッド１の１つの話題に関するメッセージが蓄積されている場合が示されている。これら各仮想コミュニティに投稿されたメッセージは、他の知識（ｗｅｂ、ワークフロー、ファイリングシステムなどから収集された形式知）と同様にして、知識データベース（知識ＤＢ）に知識情報として蓄積される。特に、各スレッド毎に作成される「まとめ」を知識ＤＢに収集してそれを例えば全文検索や自然言語検索などの検索対象として他のメッセージに優先して適用することにより、いわゆるフロー情報としての「メッセージの流れ」を静的なストック情報として効率よく活用することが可能となる。
【００１８】
＜サイト＞
本明細書においては、この知識蓄積支援システムのサーバ機能を「サイト」と呼ぶ。サイトには管理者ユーザ（Ａｄｍｉｎｉｓｔｒａｔｏｒ）が存在し、サイト情報を管理する。サイト情報には、以下のようなものがある。
【００１９】
（１）ユーザ情報
サイトを利用可能なユーザに関する情報。
サイト管理者によって、登録、削除、変更が可能である。
（２）コミュニティ作成権限情報
仮想コミュニティを作成するための権限情報。
仮想コミュニティ（以下、単にコミュニティと言う）は、メッセージの投稿、閲覧のために複数のユーザによって共通に利用可能な一種の電子掲示版であり、同じ目的を持って集まった人たちがコミュニケーションを行う「場」のことを示す。各ユーザは、目的に見合ったテーマのコミュニティに対してアクセスすることで、必要な知識を得たり、メッセージ（記事）を投稿したりする。各コミュニティには管理者がいる（コミュニティ作成者がデフォルトで管理者となる）。コミュニティ作成に関する権限は、以下の２つから選択することができる。
【００２０】
・登録されている全てのユーザが、コミュニティを作成できる。
・サイト管理者に承認されたユーザのみ、コミュニティを作成できる。
【００２１】
（３）コミュニティのカテゴリ情報
コミュニティを分類するためのカテゴリ情報。
これは、サイト管理者によって登録、削除、変更が可能である。
【００２２】
＜コミュニティ＞
次に、コミュニティについて説明する。各コミュニティを管理するためのコミュニティ情報（コミュニティのプロパティ）には、以下のようなものがある。
【００２３】
（１）名前
コミュニティの名前。
（２）投稿用メールアドレス
コミュニティ毎にもつメールアドレス。ユーザがこのアドレスにメールを送ると、その内容が自動的に新規投稿メッセージとして該当するコミュニティに登録される。
【００２４】
（３）受信メールのSubject情報
コミュニティに対する参加形態には、ｗｅｂブラウザを通じてメッセージの閲覧、投稿を行う「ｗｅｂで購読」と、このｗｅｂブラウザを通じたメッセージの閲覧、投稿に加えて、新規投稿メッセージの自動メール配信サービスが受けられる「メールで購読」とがある。「メールで購読」を選択したユーザに対しては、そのコミュニティに新規メッセージが投稿されると、自動的にその新規投稿メッセージが電子メールにて配信される。その際、配信される電子メールのSubject情報には、上記「受信メールのSubject情報」（例えば，｛コミュニティ名，メッセージ番号｝等の情報）が付加される。
【００２５】
（４）作成者
コミュニティを作成したユーザ名。
（５）作成日
コミュニティが作成された日付。
（６）コミュニティの紹介
コミュニティの簡単な紹介文。
【００２６】
（７）コミュニティのカテゴリ
上述したように、コミュニティはその内容に応じてカテゴリ分けすることができ、分類先のカテゴリに関する情報がコミュニティ毎に保持される。また、カテゴリは、サイト管理者によって登録されたものを使用する。
【００２７】
（８）コミュニティタイプ
コミュニティの公開レベルを意味する。コミュニティの公開レベルには、自由参加の「公開制」、承認された参加者のグループからなる「メンバ制」、承認された参加者以外には公開しない「非公開制」の３つがある。
【００２８】
（９）統計情報
各コミュニティ毎にそれに属しているユーザの数や参加者別の発言数ランキングなどを含む。
（１０）管理者
このコミュニティを管理する管理者名。
（１１）メンバ
このコミュニティに属している（アクセス可能な）ユーザ。
（１２）メッセージ削除権限
投稿済みメッセージの削除を許されているユーザ。以下のいずれかを選択できる。
【００２９】
・コミュニティ管理者のみ。
・コミュニティ管理者と投稿者。
【００３０】
＜メッセージとスレッド＞
次に、メッセージとスレッドについて説明する。
メッセージとは、コミュニティ内の会話において、やりとりされる発言（記事の投稿）一つ一つのことである。メッセージには、複数のファイルを添付することも可能である。メッセージは、ｗｅｂブラウザからの入力またはコミュニティが持つメールアドレスへのメール送信によって投稿できる。
【００３１】
一方、スレッドとは、上述したようにある話題に関するメッセージの束のことである。１つの話題に対して、様々な意見（メッセージ）によって会話が進んでいき、結論を出す。この結論が「まとめ」である。この知識蓄積支援システムにおいては、「まとめ」に関する作成支援機能も有している。この作成支援機能を利用することにより、該当するスレッド内のメッセージや添付ファイルなどを援用しつつ、話題の結論としての「まとめ」を容易に作成することができる。
【００３２】
図４には、スレッドを構成するメッセージの階層構造の一例が示されている。図４において、スレッド１には５つのメッセージ１，２，３，４，５が含まれている。このスレッド１の構造は、まず、メッセージ１が投稿され、そのメッセージ１に対する返信（応答）メッセージとしてメッセージ２，３が投稿され、そして、メッセージ３に対する返信（応答）メッセージとしてメッセージ４が投稿され、さらにメッセージ１に対する返信（応答）メッセージとしてメッセージ５が投稿された場合に対応している。
【００３３】
また、スレッド２も５つのメッセージ１，２，３，４，５から構成されているが、これは、最初に投稿されたメッセージ１に対する返信（応答）メッセージとしてメッセージ２，３が投稿され、さらにメッセージ３に対する返信（応答）メッセージとしてメッセージ４，５が投稿された場合に対応している。
【００３４】
なお、スレッド１，２の各メッセージに対する返信とは異なるメッセージがスレッド１，２と同一のコミュニティに対して新たに投稿された場合には、その新規投稿メッセージにはスレッド３が割り当てられることになる。
【００３５】
＜まとめ＞
「まとめ」とは、上述したように会話（スレッド）に対する「結論」のことである。職場などの会議で言えば「議事録」に相当し、例えば開発ならばレビューに対する「仕様書」に相当する。図５に示すように、１つのスレッドに対して、１つの「まとめ」が対応する。つまり、ユーザまたは管理者によってスレッド毎に総括たる「まとめ」が作成され、該当するスレッドを構成するメッセージの特殊形態として管理される。「まとめ」にも他の通常のメッセージと同様に複数のファイルを添付することができる。
【００３６】
また、「まとめ」は改訂することができ、既に作成された「まとめ」を更新すること等によって新たな「まとめ」を作成し、それを最新の「まとめ」として登録することができる。
【００３７】
＜メールによるメッセージの投稿＞
メールによって、各コミュニティに投稿されたメッセージは、以下の手順で処理される。
（１）ユーザは、投稿先のコミュニティに割り当てられているメールアドレスに対してメッセージをメールにて投稿する。
（２）知識蓄積支援システムのサーバは、全てのコミュニティ宛に届いたメールをメールサーバから一括取得する。
【００３８】
（３）知識蓄積支援システムのサーバは、投稿先メールアドレスによってどのコミュニティ宛のメッセージなのかを判断し、振り分ける。
（４）知識蓄積支援システムのサーバは、取得したメールのヘッダ情報（またはタイトル）により、該当するコミュニティ内のどのスレッドのどの階層に登録するかを判別し、取得したメールの本文をそこにメッセージとして登録する。
【００３９】
メールによってコミュニティ宛に投稿されたメッセージは、上記の処理によって自動的に該当する場所に格納されていく。ユーザは、メーリングリストへの投稿と同じ感覚で、メッセージを投稿するだけでよい。
【００４０】
＜メッセージ購読タイプ＞
知識蓄積支援システムを利用するユーザは、上述したようにメッセージの購読タイプとして、以下の２種類を選択することができる。
【００４１】
・ｗｅｂブラウザによる購読（知識蓄積支援システムのＵＲＬ（Uniform Resource Locator）へアクセスする）
・メールによる購読
ユーザがどちらの購読タイプを選択してもｗｅｂブラウザからの購読（投稿も含む）が可能である。つまり、メッセージの新規投稿が行われた際に、自動的にそのメッセージをメール配信するかどうかの選択である。メッセージの新規投稿が行われると、メール購読を選択しているユーザにはメッセージのメール配信が行われる。また、ユーザは、この配信されたメールを返信するだけで、返信メッセージを投稿することができる。この購読タイプの選択は、ユーザが属しているコミュニティ毎に行うことが可能である。
【００４２】
＜システム構成＞
次に、図１を参照して、この実施形態に係る知識蓄積支援システムのシステム構成について説明する。
【００４３】
この実施形態の知識蓄積支援システムは、複数のクライアント端末１１に対してＬＡＮ等のコンピュータネットワーク１３を介して相互に接続可能なサーバコンピュータ１２にて実現されている。サーバコンピュータ１２とクライアント端末１１には、それぞれ、図示しないが、ＣＰＵ、メインメモリ、記憶装置としての磁気ディスク装置、及びキーボードやマウスなどの入力部とディスプレイなどの表示部とを持つ入出力装置が設けられている。
【００４４】
クライアント端末１１では、Ｗｅｂブラウザ１１１とメールクライアント１１２のいずれか一方又は両方が動作している。サーバコンピュータ１２上に構築された知識蓄積支援のためのリソースを示すＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をＷｅｂブラウザ１１１から指定したり、あるいはコミュニティサーバ１２２にて管理される各コミュニティのメールアドレス宛にメールクライアント１２からメール送信を行うことにより、知識蓄積支援処理を各クライアント端末１１から利用することができる。
【００４５】
サーバコンピュータ１２の知識蓄積支援機能は、主に、制御部１２１、コミュニティサーバ１２２、Ｗｅｂサーバ１２７、およびメールサーバ１２８などのソフトウェアと、これらソフトフェアによってメッセージの投稿、閲覧のために利用される管理情報および実データとによって実現されている。管理情報には、各クライアント端末１１に対してユーザ認証を行うためのログイン管理情報１２３と、各コミュニティ毎にその管理を行うためのコミュニティ管理情報１２４とが存在し、また、実データとしては、メッセージデータ１２５と添付ファイル１２６とが存在する。
【００４６】
制御部１２１は、知識蓄積支援に関する全体の動作を制御するためのものであり、この知識蓄積支援システムの中核プログラムであるコミュニティサーバ１２２とＷｅｂサーバ１２７およびメールサーバ１２８それぞれとの間の仲介機能を初め、Ｗｅｂサーバ１２７およびメールサーバ１２８を通じて各クライアント端末１１がコミュニティサーバ１２２にログインする際のユーザ認証機能を持つ。このユーザ認証のために、制御部１２１は、ログイン管理情報１２３を管理している。このログイン管理情報１２３には、この知識蓄積支援システムに参加しているユーザそれぞれのユーザＩＤとパスワード等が格納されている。このユーザ認証により、各クライアント端末１１からのメッセージ投稿等の為になされるコミュニティサーバ１２２に対するアクセスの許可・禁止の制御が行われる。
【００４７】
コミュニティサーバ１２２は、複数のクライアント端末１１が参加可能なコミュニティの管理、運用を行うためのものであり、各クライアント端末１１から投稿されたメッセージをコミュニティ毎、且つ話題（スレッド）毎に分類、蓄積する。コミュニティサーバ１２２による各コミュニティの管理・運用は、コミュニティ管理情報１２４、メッセージデータ１２５、および添付ファイル１２６を用いて行われる。つまり、これらコミュニティ管理情報１２４、メッセージデータ１２５、および添付ファイル１２６は、コミュニティ毎にメッセージの蓄積・管理を行うためのデータベースとして利用される。
【００４８】
さらに、コミュニティサーバ１２２には、管理者設定部１２９とメッセージ削除権限設定部１３０とが設けられている。管理者設定部１２９は、コミュニティ管理情報１２４を用いて、コミュニティ毎にその作成者と参加者の中から管理者ユーザ（または単に管理者という）を設定するための支援機能を持つ。コミュニティの作成者はそのコミュニティの参加者でもあるので、厳密には、コミュニティの作成者とその作成者以外の参加者とを対象に管理者ユーザの設定が行われることになる。コミュニティの作成者がデフォルトの管理者ユーザとなる。管理者は、他のユーザに変更可能であり、また、複数のユーザを管理者として設定したり、すでに設定されている管理者を削除することもできる。
【００４９】
一方、メッセージ削除権限設定部１３０は、メッセージを削除できる権限者を「管理者のみ」か、または、「管理者と投稿者」のいずれかに設定する。「管理者と投稿者」を選択することで、コミュニティに投稿されたメッセージについてその投稿者に当該メッセージの削除権限を設定することができ、投稿者からの要求に応じて当該投稿者が投稿したメッセージを削除することが可能となる。
【００５０】
次に、コミュニティ管理情報１２４を構成する各テーブルについて説明する。
【００５１】
図１に示されているように、コミュニティ管理情報１２４は、ユーザテーブル２０１、コミュニティテーブル２０２、購読タイプテーブル２０３、メンバテーブル２０４、スレッドテーブル２０５、メッセージテーブル２０６およびまとめテーブル２０７などから構成されている。以下、これら各テーブルについて説明する。
【００５２】
＜ユーザテーブル＞
図６は、ユーザを管理するユーザテーブル２０１の構成例を示す図である。ユーザテーブル２０１には、本知識蓄積支援システムに参加しているユーザそれぞれについてユーザＩＤ、ユーザ名およびメールアドレスが格納されている。図６においては、ユーザＩＤ「Ｕ００００１」、ユーザ名「田中一郎」、メールアドレス「ichiro.tanaka@xxxx.co.jp」のユーザと、ユーザＩＤ「Ｕ００００２」、ユーザ名「山田太郎」、メールアドレス「taro.yamada@xxxx.co.jp」のユーザと、ユーザＩＤ「Ｕ００００３」、ユーザ名「斉藤次郎」、メールアドレス「jiro.saito@xxxx.co.jp」のユーザが登録されている例が示されている。
【００５３】
＜コミュニティテーブル＞
図７は、コミュニティを管理するコミュニティテーブル２０２の構成例を示す図である。コミュニティテーブル２０２は、本知識蓄積支援システム上に作成された各コミュニティと各コミュニティに参加しているユーザを管理するためのテーブルであり、ここには、本知識蓄積支援システム上に作成されたコミュニティそれぞれについてコミュニティＩＤ、コミュニティ名およびコミュニティタイプと、コミュニティの管理者となっているメンバそれぞれの（管理者もまたメンバであるため）メンバＩＤのリストである管理者ＩＤリストと、メッセージ削除権限と、そのコミュニティに参加しているメンバそれぞれのメンバＩＤリストが格納されている。ここで管理者になれるメンバタイプは「参加者」に限られる。メンバタイプの詳細は後述する。
【００５４】
図７においては、コミュニティＩＤ「Ｃ００１」、コミュニティ名「コミュニティＡ」のコミュニティについては、コミュニティタイプが「公開」であって、その管理者は管理者ＩＤリストに登録されているメンバＩＤが「Ｍ０００００１」のユーザであって、メッセージ削除権限は「管理者」に限定されており、メンバＩＤ「Ｍ０００００１」、「Ｍ０００００４」、「Ｍ０００００５」、…が割り当てられたユーザが参加している。また、コミュニティＩＤ「Ｃ００２」、コミュニティ名「コミュニティＢ」のコミュニティは、コミュニティタイプが「メンバ制」であって、その管理者は管理者ＩＤリストに登録されているメンバＩＤが「Ｍ００００２０」、「Ｍ００００３０」、…のユーザであって、メッセージ削除権限が管理者だけでなく「投稿者」にも与えられており、メンバＩＤ「Ｍ０００００２」、「Ｍ０００００３」、…が割り当てられたユーザが参加している場合を示している。なお、メンバＩＤは全コミュニティにわたってユニーク（一意）であり、各ユーザには参加しているコミュニティの数と同数のメンバＩＤが割り当てられる。
【００５５】
＜購読タイプテーブル＞
図８は、購読タイプを管理する購読タイプテーブル２０３の構成例を示す図である。購読タイプテーブル２０３には、本知識蓄積支援システムに参加しているユーザそれぞれについてユーザＩＤ、ユーザ名、参加しているコミュニティのコミュニティＩＤ、そのコミュニティに対する購読タイプおよび購読タイプがメールの場合のユーザのメールアドレスが格納されている。なお、ユーザテーブル２０１でメールアドレスを管理する場合には、この購読タイプテーブル２０３には必ずしもメールアドレスを登録する必要はなく、また逆に、ユーザテーブル２０１ではメールアドレスを管理せず、購読タイプがメールの場合のユーザのメールアドレスのみを購読タイプテーブル２０３にて管理するようにしても良い。
【００５６】
図８においては、ユーザＩＤが「Ｕ００００１」で、ユーザ名が「田中一郎」のユーザが、コミュニティＩＤ「Ｃ００１」と「Ｃ００２」の２つのコミュニティに参加しており、コミュニティＩＤ「Ｃ００１」のコミュニティに関する購読タイプはｗｅｂで、コミュニティＩＤ「Ｃ００１」のコミュニティに関する購読タイプがメールであり、またユーザＩＤが「Ｕ００００２」で、ユーザ名が「山田太郎」のユーザが、コミュニティＩＤ「Ｃ００５」のコミュニティに参加しており、そのコミュニティに関する購読タイプがｗｅｂであり、またユーザＩＤが「Ｕ００００３」で、ユーザ名が「斉藤次郎」のユーザが、コミュニティＩＤ「Ｃ００１」のコミュニティに参加しており、そのコミュニティに関する購読タイプがｗｅｂである場合を示している。
【００５７】
＜メンバテーブル＞
図９は、メンバを管理するメンバテーブル２０４の構成例を示す図である。メンバテーブル２０４には、メンバＩＤそれぞれについて、それが参加しているコミュニティに関する参加属性を示すメンバタイプと、メンバとして参加しているユーザのユーザ名とが格納されている。メンバタイプには、参加が承認されている「参加者」、参加者として仮登録されている「仮登録者」、参加を申し込んでいるが承認されていない「参加希望者」、参加に関する手続きを行っておらず一種のゲストとして参加する「匿名」とがある。上述したようにメンバタイプが「参加者」のユーザは当該コミュニティの管理者となり得るが、それ以外のメンバタイプのユーザは管理者の選定対象からは除外される。
【００５８】
図９においては、ユーザ名「田中一郎」のユーザは、メンバＩＤ「Ｍ０００００１」として参加しているコミュニティに対してはそのメンバタイプが「参加者」で、またメンバＩＤ「Ｍ０００００３」として参加しているコミュニティに対してはそのメンバタイプが「参加希望者」であり、またユーザ名「山田太郎」のユーザは、メンバＩＤ「Ｍ０００００２」として参加しているコミュニティに対してはそのメンバタイプが「仮登録者」で、またメンバＩＤ「Ｍ０００００４」として参加しているコミュニティに対してはそのメンバタイプが「匿名」で、ユーザ名「斉藤次郎」のユーザは、メンバＩＤ「Ｍ０００００５」として参加しているコミュニティに対してはそのメンバタイプが「参加者」である場合を示している。
【００５９】
＜スレッドテーブル＞
図１０は、スレッドを管理するスレッドテーブル２０５の構成例を示す図である。スレッドテーブル２０５には、コミュニティそれぞれについてコミュニティＩＤと、そのコミュニティー内に生成されているスレッドそれぞれのスレッドＩＤを含むスレッドＩＤリストとが格納されている。スレッドＩＤも全コミュニティについてユニークな値が用いられる。
【００６０】
図１０においては、コミュニティＩＤ「Ｃ００１」のコミュニティにはスレッドＩＤ「Ｔ０１００１」、「Ｔ０１００２」、…のスレッドが含まれており、またコミュニティＩＤ「Ｃ００２」のコミュニティにはスレッドＩＤ「Ｔ０２００１」、…のスレッドが含まれている場合を示している。
【００６１】
＜メッセージテーブル＞
図１１は、メッセージを管理するメッセージテーブル２０６の構成例を示す図である。メッセージテーブル２０６には、スレッドＩＤ毎にそれを構成するメッセージそれぞれのメッセージＩＤと、そのメッセージを投稿した投稿者のメンバＩＤと、メッセージデータ１２５として格納されている該当するメッセージの実データの所在を示すＵＲＬとが格納されている。なお、このＵＲＬは、該当するスレッドＩＤとメッセージＩＤとから一義に特定できるようにしてもよく、この場合には、ＵＲＬのフィールドは不要となる。
【００６２】
＜まとめテーブル＞
図１２は、スレッド毎に作成される「まとめ」を管理するまとめテーブル２０７の構成例を示す図である。まとめテーブル２０７には、スレッドＩＤ毎にそのスレッドの「まとめ」として投稿されたメッセージのメッセージＩＤと、その「まとめ」メッセージを投稿した投稿者のメンバＩＤと、複数の「まとめ」が作成・登録された場合における各メッセージの版番号と、メッセージデータ１２５として格納されている該当する「まとめ」に関するメッセージの実データの所在を示すＵＲＬとが格納されている。
【００６３】
また、メッセージテーブル２０６の場合と同様に、まとめテーブル２０７のＵＲＬは、該当するスレッドＩＤとメッセージＩＤとから一義に特定できるようにしてもよく、この場合にはＵＲＬのフィールドは不要となる。
【００６４】
ここで、コミュニティサーバ１２２の管理者設定部１２９によって実行される、この知識蓄積支援システムにおける管理者の設定処理について説明する。
【００６５】
まず、図１３乃至図１５を参照して、この知識蓄積支援システムにおいてクライアント端末１１のＷｅｂブラウザ１１１により表示される画面の状態遷移の一例を説明する。
【００６６】
図１３は、管理者ユーザの交代・追加・削除を行う際に現在の管理者ユーザのＷｅｂブラウザ画面に表示されるコミュニティ管理者設定画面の状態遷移を示す図であり、図１３（Ａ）では、「コミュニティＡの管理者設定メニュー」でコミュニティＡの管理者を現在の管理者「田中一郎」から、メンバタイプが「参加者」である他のメンバに交代するために、「管理者の交代」メニューが選択されている。コミュニティＡの現在の管理者は「田中一郎」のみであるので、この操作は「田中一郎」のみに許可される。
【００６７】
「管理者の交代」メニューが選択されると、図１３（Ｂ）のように他の参加者の一覧がプルダウンメニューに表示される。例えば「斉藤次郎」を選択すると、図１３（Ｃ）のように変更後の状態が表示される。この管理者交代の通知は、「田中一郎」のクライアント端末１１からコミュニティサーバ１２２に送信され、管理者設定部１２９によってコミュニティ管理情報１２４に反映される。これにより、コミュニティＡの管理者は「斉藤次郎」に変更される。また、次回からは図１３（Ａ）の画面を表示すると、現在の管理者として「斉藤次郎」が表示されることとなる。
【００６８】
図１４は管理者ユーザの追加を行う場合の例を示している。図１４（Ａ）では、「コミュニティＡの管理者設定メニュー」でコミュニティＡの管理者の追加を行うために、「管理者の追加」メニューが選択されている。「管理者の追加」メニューが選択されると、図１４（Ｂ）のように他の参加者の一覧がプルダウンメニューに表示される。例えば「斉藤次郎」を選択すると、図１４（Ｃ）のように追加後の管理者リストとして「田中一郎」と「斉藤次郎」が画面上に表示され、以降、コミュニティＡの管理者が「田中一郎」と「斉藤次郎」の２名となったことを示す。この追加の通知は、「田中一郎」のクライアント端末１１からコミュニティサーバ１２２に送信され、管理者設定部１２９によってコミュニティ管理情報１２４に反映される。これにより、コミュニティＡの管理者は「田中一郎」と「斉藤次郎」の２名に変更される。同様に、図１５は複数登録されている管理者の一部の削除を行う場合の例を示している。図１５（Ａ）では、「コミュニティＡの管理者設定メニュー」でコミュニティＡの管理者の削除を行うために、「管理者の削除」メニューが選択されている。「管理者の追加」メニューが選択されると、図１５（Ｂ）のように管理者リストに現在の管理者（「田中一郎」と「斉藤次郎」）が表示され、プルダウンメニューから管理者から外すべきユーザ、例えば「田中一郎」、を選択すると、図１５（Ｃ）のように削除後の管理者リストとして「斉藤次郎」が画面上に表示されると共に、管理者の変更が管理者設定部１２９によってコミュニティ管理情報１２４に反映される。
【００６９】
図１６は、管理者設定処理の流れを示した図であり、この例では、管理者を「田中一郎」から「斉藤次郎」に交代する例を示している。まず、Ｗｅｂブラウザ１１１がコミュニティのＵＲＬを指定し、表示された画面から管理者変更要求を行うと（１）、コミュニティサーバ１２２の管理者設定部１２９は、コミュニティ管理情報１２４のコミュニティテーブル２０２とメンバテーブル２０４から、該当するコミュニティに関するメンバタイプが「参加者」のメンバだけを検索し（２）、候補リストとしてＷｅｂブラウザ１１１に返信する（３）。
【００７０】
そして、その画面上でコミュニティの管理者を「田中一郎」から「斉藤次郎」に交代する操作が行われると（４）、Ｗｅｂブラウザ１１１はその変更内容をコミュニティサーバ１２２に送信し（５）、これを受信したコミュニティサーバ１２２の管理者設定部１２９は、コミュニティ管理情報１２４のコミュニティテーブル２０２に変更内容を登録する（６）。
【００７１】
図１７は、図１６で示した管理者交代処理の手順を示すフローチャートである。
【００７２】
ユーザ「田中一郎」がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＡ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＡ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＡ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＡ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＡ４）。また、ユーザ認証では、現在管理者として設定されているユーザであるか否かの管理者認証もコミュニティテーブル２０２を用いて実行される。
【００７３】
ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＡ３のＹＥＳ）、ユーザ「田中一郎」はコミュニティＡの管理者であるので、以下のように、ユーザ「田中一郎」からの要求に応じてコミュニティＡに関する管理者設定画面を提示して、管理者設定・変更を行う処理が実行される。
【００７４】
まず、コミュニティサーバ１２２の管理者設定部１２９が、管理者設定・変更の対象として指定されたコミュニティ（ここではコミュニティＡ）からコミュニティ管理情報１２４のコミュニティテーブル２０２に格納された当該ユーザ以外のメンバＩＤリストをまず検索し（ステップＡ５）、そのメンバＩＤリストのなかから１つずつメンバＩＤを取り出し、それをキーとしてメンバテーブル２０４を検索し、メンバタイプが「参加者」であるものだけをＷｅｂブラウザ１１１に返却する（ステップＡ６）。
【００７５】
そして、このコミュニティサーバ１２２から返されたデータをもとにＷｅｂブラウザ１１１によって図１３に示した管理者用画面が表示される（ステップＡ７）。表示された管理者用画面上で管理者を自分自身である「田中一郎」から「斉藤次郎」に交代させる変更操作が行われると（ステップＡ８）、Ｗｅｂブラウザ１１１が変更された管理者データをコミュニティサーバ１２２に送信する（ステップＡ９）。コミュニティサーバ１２２の管理者設定部１２９は、受信した管理者データをもとに当該コミュニティの管理者を変更してコミュニティテーブル２０２に反映する（ステップＡ１０）。その後、コミュニティサーバ１２２は、Ｗｅｂブラウザ１１１の要求に従って、コミュニティテーブル２０２の変更後の管理者を必要に応じてアクセスする（ステップＡ１１）。
【００７６】
図１８は、管理者を追加する処理の手順を示すフローチャートである。
【００７７】
ユーザ「田中一郎」がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＢ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＢ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＢ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＢ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＢ４）。また、ユーザ認証では、現在管理者として設定されているユーザであるか否かの管理者認証もコミュニティテーブル２０２を用いて実行される。
【００７８】
ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＢ３のＹＥＳ）、ユーザ「田中一郎」はコミュニティＡの管理者であるので、以下のように、ユーザ「田中一郎」からの要求に応じてコミュニティＡに関する管理者設定画面を提示して、管理者設定・変更を行う処理が実行される。
【００７９】
まず、コミュニティサーバ１２２の管理者設定部１２９が、管理者設定・変更の対象として指定されたコミュニティ（ここではコミュニティＡ）からコミュニティ管理情報１２４のコミュニティテーブル２０２に格納された当該ユーザ以外のメンバＩＤリストをまず検索し（ステップＢ５）、そのメンバＩＤリストのなかから１つずつメンバＩＤを取り出し、それをキーとしてメンバテーブル２０４を検索し、メンバタイプが「参加者」であるものだけをＷｅｂブラウザ１１１に返却する（ステップＢ６）。
【００８０】
このコミュニティサーバ１２２から返されたデータをもとにＷｅｂブラウザ１１１が図１４に示した管理者用画面を表示すると（ステップＢ７）、管理者は、表示された管理者用画面から新たな管理者として「斉藤次郎」を追加する（ステップＢ８）。また、Ｗｅｂブラウザ１１１が追加された管理者データをコミュニティサーバ１２２に送信すると（ステップＢ９）、コミュニティサーバ１２２の管理者設定部１２９は、受信した管理者データをもとに当該コミュニティの管理者を追加してコミュニティテーブル２０２に反映する（ステップＢ１０）。
【００８１】
その後、コミュニティサーバ１２２は、Ｗｅｂブラウザ１１１の要求に従って、コミュニティテーブル２０２の変更後の管理者を必要に応じてアクセスする（ステップＢ１１）。
【００８２】
また、図１９は、管理者を削除する処理の手順を示すフローチャートである。
【００８３】
ユーザ「田中一郎」がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＣ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＣ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＣ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＣ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＣ４）。また、ユーザ認証では、現在管理者として設定されているユーザであるか否かの管理者認証もコミュニティテーブル２０２を用いて実行される。
【００８４】
ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＣ３のＹＥＳ）、ユーザ「田中一郎」はコミュニティＡの管理者であるので、以下のように、ユーザ「田中一郎」からの要求に応じてコミュニティＡに関する管理者設定画面を提示して、管理者設定・変更を行う処理が実行される。
【００８５】
まず、コミュニティサーバ１２２の管理者設定部１２９が、管理者設定・変更の対象として指定されたコミュニティ（ここではコミュニティＡ）からコミュニティ管理情報１２４のコミュニティテーブル２０２に格納された管理者ＩＤリストをまず検索し（ステップＣ５）、その管理者ＩＤリストのなかから１つずつメンバＩＤを取り出し、それをキーとしてメンバテーブル２０４を検索し、ユーザ名リストを管理者データとしてＷｅｂブラウザ１１１に返却する（ステップＣ６）。
【００８６】
このコミュニティサーバ１２２から返された管理者データをもとにＷｅｂブラウザ１１１が図１５に示した管理者用画面を表示すると（ステップＣ７）、管理者は、表示された管理者用画面から自分以外の他の管理者、例えば「田中一郎」を削除する（ステップＣ８）。削除できるのは基本的には自分以外の管理者であり、自分自身を削除することは禁止される。
【００８７】
Ｗｅｂブラウザ１１１が削除された管理者データをコミュニティサーバ１２２に送信すると（ステップＣ９）、コミュニティサーバ１２２の管理者設定部１２９は、受信した管理者データをもとに当該コミュニティの管理者を削除してコミュニティテーブル２０２に反映する（ステップＣ１０）。
【００８８】
その後、コミュニティサーバ１２２は、Ｗｅｂブラウザ１１１の要求に従って、コミュニティテーブル２０２の変更後の管理者を必要に応じてアクセスする（ステップＣ１１）。
【００８９】
このように、この知識蓄積支援システムは、既存管理者が自分に代わる新たな管理者を参加者の中から選定して管理者に設定したり（管理者の交代）、参加者の中から当該コミュニティを共同して管理するユーザを選定して管理者として設定したり（管理者の追加）、さらには複数の管理者のなかから適任でないものを削除する（管理者の削除）という仕組みを備えるため、コミュニティの管理上の問題を解決できるとともに、管理の柔軟性を広げることが可能となる。
【００９０】
次に、コミュニティサーバ１２２のメッセージ削除権限設定部１３０によって実行される、この知識蓄積支援システムにおけるメッセージ削除権限設定の処理について説明する。
【００９１】
まず、図２０を参照して、この知識蓄積支援システムにおいてクライアント端末１１のＷｅｂブラウザ１１１により表示される画面の状態遷移の一例を説明する。
【００９２】
図２０はメッセージ削除権限設定を行う際に管理者のＷｅｂブラウザ画面に表示される管理者用メッセージ削除権限設定画面の状態遷移を示す図である。図２０（Ａ）では、「コミュニティＡのメッセージ削除権限設定メニュー」でコミュニティＡのメッセージ削除権限を管理者のみに設定するために、「管理者のみ」メニューを選択し、図２０（Ｂ）では、管理者のみならず、投稿者自身も自身の投稿メッセージを削除できるように設定するために「管理者および投稿者」を選択した場合を示している。
【００９３】
このメッセージ削除権限設定データは、Ｗｅｂブラウザからコミュニティサーバ１２２に送信され、メッセージ削除権限設定部１２９によってコミュニティ管理情報１２４に反映され、以降のメッセージ削除時に権限がチェックされる。「管理者および投稿者」の設定がなされている場合でも、管理者以外のユーザが削除できるのは、そのユーザが投稿したメッセージ（そのユーザが投稿したまとめメッセージも含む）のみである。削除対象のメッセージの投稿者がだれであるかは、メッセージテーブル２０６のメンバＩＤや、「まとめ」テーブル２０７のメンバＩＤから判定することができる。
なお、デフォルトのメッセージ削除権限は「管理者のみ」である。
【００９４】
図２１は、図２０で示したメッセージ削除権限の設定処理の方法を示すフローチャートである。
【００９５】
例えばユーザ「田中一郎」がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＤ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＤ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＤ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＤ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＤ４）。また、ユーザ認証では、現在管理者として設定されているユーザであるか否かの管理者認証もコミュニティテーブル２０２を用いて実行される。
【００９６】
ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＤ３のＹＥＳ）、ユーザ「田中一郎」はコミュニティＡの管理者であるので、以下のように、ユーザ「田中一郎」からの要求に応じてコミュニティＡに関するメッセージ削除権限の設定処理を行うことが出来る。
【００９７】
まず、コミュニティサーバ１２２のメッセージ削除権限設定部１２９が、メッセージ削除権限の設定対象として指定されたコミュニティ（ここではコミュニティＡ）からコミュニティ管理情報１２４のコミュニティテーブル２０２に格納された当該コミュニティに関する現在のメッセージ削除権限を検索し（ステップＤ５）、それをメッセージ削除権限データとしてＷｅｂブラウザ１１１に返却する（ステップＤ６）。
【００９８】
このコミュニティサーバ１２２から返されたメッセージ削除権限データをもとにＷｅｂブラウザ１１１が図２０に示した管理者用画面を表示すると（ステップＤ７）、管理者は、表示された管理者用画面からメッセージ削除権限を現在管理者のみのところを投稿者も可能とするため、「管理者および投稿者」を選択する（ステップＤ８）。Ｗｅｂブラウザ１１１がメッセージ削除権限データをコミュニティサーバ１２２に送信すると（ステップＤ９）、コミュニティサーバ１２２のメッセージ削除権限設定部１２９は、受信したメッセージ削除権限データをもとに当該コミュニティのメッセージ削除権限を更新してコミュニティテーブル２０２に反映する（ステップＤ１０）。
【００９９】
その後、コミュニティサーバ１２２は、Ｗｅｂブラウザ１１１の要求に従って、コミュニティテーブル２０２の変更後のメッセージ削除権限を必要に応じてアクセスする（ステップＤ１１）。
【０１００】
以降、ユーザからコミュニティＡ内のメッセージの削除が要求された場合には、コミュニティサーバ１２２は、そのユーザのメンバＩＤと、当該削除対象のメッセージの投稿者に対応するメンバＩＤとの一致の有無を判断し、一致する場合にのみメッセージの削除を実行する。
【０１０１】
このように、この知識蓄積支援システムは、メッセージ削除を投稿者自身が可能となるように権限設定する仕組みを備えるため、誤って投稿したり、内容の不適切なメッセージを投稿した場合でも、投稿者自身が削除することが可能となり、余計な混乱を招くことなく、コミュニティの運営が実現できる。
【０１０２】
なお、本実施形態の知識蓄積支援システムの機能は全てコンピュータプログラムにより実現されているので、そのコンピュータプログラムをコンピュータ読み取り可能な記憶媒体に記憶しておき、その記憶媒体を通じてコンピュータプログラムを、コンピュータネットワーク接続可能な通常のコンピュータに導入するだけで、本実施形態と同様の効果を得ることができる。
【０１０３】
また本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０１０４】
【発明の効果】
以上、詳述したように、この発明によれば、仮想コミュニティの管理を、当該コミュニティを作成したユーザに限定することなく、必要に応じてコミュニティの削除や変更などが行える管理権限を他の複数のユーザにも与えるための仕組みをもつことにより、より柔軟にコミュニティを管理することを可能とする。
【０１０５】
また、投稿メッセージの削除を管理者のみにとどめないで、投稿者自身により削除できるように権限設定するユーザインタフェースを設けることにより、より円滑なコミュニティ運営を可能とする。
【図面の簡単な説明】
【図１】この発明の実施形態に係る知識蓄積支援システムのシステム構成を示すブロック図。
【図２】同実施形態の知識蓄積支援システムで扱われる知識を説明するための図。
【図３】同実施形態の知識蓄積支援システムにおける知識蓄積処理の原理を説明するための図。
【図４】同実施形態の知識蓄積支援システムで管理されるメッセージとスレッドとの関係を説明するための図。
【図５】同実施形態の知識蓄積支援システムで管理されるメッセージと「まとめ」との関係を説明するための図。
【図６】同実施形態の知識蓄積支援システムで使用されるユーザテーブルの一例を示す図。
【図７】同実施形態の知識蓄積支援システムで使用されるコミュニティテーブルの一例を示す図。
【図８】同実施形態の知識蓄積支援システムで使用される購読タイプテーブルの一例を示す図。
【図９】同実施形態の知識蓄積支援システムで使用されるメンバテーブルの一例を示す図。
【図１０】同実施形態の知識蓄積支援システムで使用されるスレッドテーブルの一例を示す図。
【図１１】同実施形態の知識蓄積支援システムで使用されるメッセージテーブルの一例を示す図。
【図１２】同実施形態の知識蓄積支援システムで使用されるまとめテーブルの一例を示す図。
【図１３】同実施形態の知識蓄積支援システムにおいて管理者用画面での管理者の変更を行う際のＷｅｂブラウザ画面の状態遷移を示す図。
【図１４】同実施形態の知識蓄積支援システムにおいて管理者用画面での管理者の追加を行う際のＷｅｂブラウザ画面の状態遷移を示す図。
【図１５】同実施形態の知識蓄積支援システムにおいて管理者用画面での管理者の削除を行う際のＷｅｂブラウザ画面の状態遷移を示す図。
【図１６】同実施形態の知識蓄積支援システムにおける管理者設定処理の流れを示した図。
【図１７】同実施形態の知識蓄積支援システムにおける管理者交代のための手順を示すフローチャート。
【図１８】同実施形態の知識蓄積支援システムにおける管理者追加のための手順を示すフローチャート。
【図１９】同実施形態の知識蓄積支援システムにおける管理者削除のための手順を示すフローチャート。
【図２０】同実施形態の知識蓄積支援システムにおいて管理者用画面でのメッセージ削除権限の設定を行う際のＷｅｂブラウザ画面の状態遷移を示す図。
【図２１】同実施形態の知識蓄積支援システムにおけるメッセージ削除権限設定の処理の流れを示したフローチャート。
【符号の説明】
１１…クライアント端末
１２…サーバコンピュータ
１１１…Ｗｅｂブラウザ
１１２…メールクライアント
１２１…制御部
１２２…コミュニティサーバ
１２３…ログイン管理情報
１２４…コミュニティ管理情報
１２５…メッセージデータ
１２６…添付ファイル
１２７…Ｗｅｂサーバ
１２８…メールサーバ
１２９…管理者設定部
１３０…メッセージ削除権限設定部
２０１…ユーザテーブル
２０２…コミュニティテーブル
２０３…購読タイプテーブル
２０４…メンバテーブル
２０５…スレッドテーブル
２０６…メッセージテーブル
２０７…まとめテーブル

Claims (4)

1. 複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムであって、
   前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御手段と、
   複数のクライアント端末が参加可能な仮想コミュニティ毎に投稿用メールアドレスを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から電子メールによって投稿されるメッセージのメールアドレスがどの仮想コミュニティの投稿用メールアドレスに対応するかを判別すると共に、前記メッセージに対応する電子メールのヘッダ情報またはタイトルに基づいて、前記メッセージが、前記判別された仮想コミュニティに対して既に投稿されているどのメッセージに対する返信メッセージであるかを判別することによって、前記各クライアント端末からのメッセージを、仮想コミュニティ毎に、且つ、投稿されたメッセージとそれに対する返信メッセージとの関係にある同一の話題に関するメッセージの束であるスレッド毎に、分類、蓄積するコミュニティ処理手段と、
   各仮想コミュニティ毎に当該仮想コミュニティの管理者ユーザを示す管理者リスト情報と、各仮想コミュニティ毎に当該仮想コミュニティのメンバを示すメンバリスト情報と、前記各メンバ毎に、当該メンバが仮想コミュニティに対して、参加が承認されている参加者として参加しているか否かを示すメンバタイプ情報とを含むコミュニティ管理情報を記憶する手段とを具備し、
   前記コミュニティ処理手段は、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの交代が要求された場合、前記管理者ユーザの交代が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中から前記管理者ユーザ以外のメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ交代処理手段と、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの追加が要求された場合、前記管理者ユーザの追加が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中からメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ追加処理手段と、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの削除が要求された場合、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザであるメンバそれぞれを前記管理者リスト情報から検索して前記検索されたメンバを管理者データとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記メンバの中から前記管理者ユーザ以外のメンバが選択された場合、前記選択されたメンバを、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザから削除すると共に当該削除結果を前記コミュニティ管理情報に反映し、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザからの、前記削除を要求した管理者ユーザ自身の削除を禁止する管理者ユーザ削除処理手段とを含むことを特徴とする知識蓄積支援システム。
2. 前記仮想コミュニティに投稿されたメッセージについてその投稿者に当該メッセージの削除権限を設定し、前記投稿者からの要求に応じて前記仮想コミュニティに投稿されたメッセージの削除を行うメッセージ削除制御手段をさらに具備することを特徴とする請求項１記載の知識蓄積支援システム。
3. 複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムにおける管理者設定方法であって、
   前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御ステップと、
   複数のクライアント端末が参加可能な各仮想コミュニティ毎に当該仮想コミュニティの管理者ユーザを示す管理者リスト情報と、各仮想コミュニティ毎に当該仮想コミュニティのメンバを示すメンバリスト情報と、前記各メンバ毎に、当該メンバが仮想コミュニティに対して、参加が承認されている参加者として参加しているか否かを示すメンバタイプ情報とを含むコミュニティ管理情報を管理すると共に、複数のクライアント端末が参加可能な仮想コミュニティ毎に投稿用メールアドレスを管理し、前記アクセス制御ステップによってアクセス許可された各クライアント端末から電子メールによって投稿されるメッセージのメールアドレスがどの仮想コミュニティの投稿用メールアドレスに対応するかを判別すると共に、前記メッセージに対応する電子メールのヘッダ情報またはタイトルに基づいて、前記メッセージが、前記判別された仮想コミュニティに対して既に投稿されているどのメッセージに対する返信メッセージであるかを判別することによって、前記各クライアント端末からのメッセージを、仮想コミュニティ毎に、且つ、投稿されたメッセージとそれに対する返信メッセージとの関係にある同一の話題に関するメッセージの束であるスレッド毎に、分類、蓄積するコミュニティ処理ステップとを具備し、
   前記コミュニティ処理ステップは、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの交代が要求された場合、前記管理者ユーザの交代が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中から前記管理者ユーザ以外のメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ交代処理ステップと、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの追加が要求された場合、前記管理者ユーザの追加が要求された仮想コミュニティに対する参加属性が参加者であるメンバのリストを前記コミュニティ管理情報から検索して前記検索されたメンバのリストを候補者リストとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記候補リスト中からメンバが選択された場合、前記仮想コミュニティの管理者ユーザを前記現在の管理者ユーザから前記選択されたメンバに変更すると共に当該変更結果を前記コミュニティ管理情報に反映する管理者ユーザ追加処理ステップと、ある仮想コミュニティの現在の管理者ユーザのクライアント端末から管理者ユーザの削除が要求された場合、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザであるメンバそれぞれを前記管理者リスト情報から検索して前記検索されたメンバを管理者データとして前記管理者ユーザのクライアント端末に送信し、前記管理者ユーザのクライアント端末によって前記メンバの中から前記管理者ユーザ以外のメンバが選択された場合、前記選択されたメンバを、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザから削除すると共に当該削除結果を前記コミュニティ管理情報に反映し、前記管理者ユーザの削除が要求された仮想コミュニティの管理者ユーザからの、前記削除を要求した管理者ユーザ自身の削除を禁止する管理者ユーザ削除処理ステップとを含むことを特徴とする知識蓄積支援システムにおける管理者設定方法。
4. 前記仮想コミュニティに投稿されたメッセージについてその投稿者に当該メッセージの削除権限を設定し、前記投稿者からの要求に応じて前記仮想コミュニティに投稿されたメッセージの削除を行うメッセージ削除制御手段をさらに具備することを特徴とする請求項３記載の知識蓄積支援システムにおける管理者設定方法。

Images