JP2002342346A - 知識蓄積支援システムおよび同システムにおけるメッセージの要約作成方法 - Google Patents

Abstract

(57)【要約】 【課題】意見交換の場である仮想コミュニティに投稿さ
れたメッセージの要約をまとめ等として自動作成できる
ようにし、個人のノウハウなどの知識を収集してそれを
効率よく利用する。 【解決手段】コミュニティサーバ１２２は、仮想コミュ
ニティ上でユーザ同士が交わすメッセージを話題毎に分
類、蓄積する。さらに、コミュニティサーバ１２２に
は、簡易要約作成部１３１が設けられている。簡易要約
作成部１３１は、主にメッセージの総括である「まと
め」の作成支援のために用いられ、「まとめ」作成時に
簡易要約作成部１３１による要約作成機能を実行するこ
とにより、同一スレッド内の互いに関連するメッセージ
群から重複部分を除去した簡易要約を「まとめ」として
作成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はナレッジマネジメン
トシステムで用いられる知識蓄積支援システムおよび同
システムにおけるメッセージの要約作成方法に関し、特
に不特定多数の参加する仮想コミュニティを用いて知識
の蓄積を支援する知識蓄積支援システムおよび同システ
ムにおけるメッセージの要約作成方法に関する。

【０００２】

【従来の技術】近年、企業を中心に複数のユーザ間で情
報共有を行うためのグループウェアの導入が進められて
いる。代表的なグループウェアとしては、電子メールシ
ステム、ワークフローシステムなどが知られているが、
最近では知識や情報の共有支援を図るためのナレッジマ
ネジメントシステムも開発され始めている。

【０００３】ナレッジマネジメントシステムはＷｅｂ情
報や電子ファイル情報などに加え、個人のノウハウなど
を知識データベースとして蓄積・管理するためのもので
ある。自然言語検索などの検索機能と組み合わせること
により、知識、情報の効率的な活用が可能となる。

【０００４】ところで、このようなナレッジマネジメン
トシステムにおいては、個人のノウハウなどの知識をど
のように収集・蓄積するかが重要となる。個人のノウハ
ウなどの知識はいわゆる暗黙知であって、Ｗｅｂ情報や
電子ファイル情報などのように形式化されたものではな
いため、それを自動的に収集、蓄積することは困難であ
るからである。

【０００５】そこで、最近では、知識蓄積支援機能を持
つナレッジマネジメントシステムの開発が要求されてい
る。個人のノウハウなどの知識を自動的に収集・蓄積す
る仕組みを実現することにより、暗黙知としての知識を
もＷｅｂ情報や電子ファイル情報などのような形式化さ
れた形式知と同様に活用することが可能となる。

【０００６】

【発明が解決しようとする課題】ナレッジマネジメント
システムにおいて、個人のノウハウなどの知識を蓄積す
るためには、通常、多数のユーザが積極的に意見を交わ
すための場を用意し、さらにはその意見交換の場で交わ
される会話を収集した後、その内容を総括するまとめを
作成することが必要となる。しかしながら、従来では、
まとめの作成はすべて人手による編集作業のみに任され
ることが多く、まとめの作成を効率良く行うことは困難
であった。

【０００７】すなわち、従来では、まとめ作成時には、
すべてのメッセージデータをいったん画面上に表示して
ユーザがその内容を黙示確認しながら、不要なメッセー
ジを選択して削除するなどの作業を行う必要があった。
例えば、あるオリジナルのメッセージに対して誰かが返
信メッセージを投稿した場合、その返信メッセージの後
ろの部分にはオリジナルのメッセージが自動的に付加さ
れることが通常である。これはメールベースで返信をし
た場合に顕著であり、メッセージのまとめを作成する上
では、オリジナルのメッセージは不要であるし、このよ
うな返信が複数回実行されると、その回数分のネストし
た不要メッセージリストが添付されていくことになる。

【０００８】意見交換の場で交わされる会話は１つの話
題のみではなく、多数の話題について行われるので、こ
れら話題すべてについて個々にまとめを作成する場合に
は、上述した不要メッセージを削除するなどの作業をす
べての話題について人手によって行うことが必要とな
る。

【０００９】本発明は上述の事情に鑑みてなされたもの
であり、意見交換の場である仮想コミュニティに投稿さ
れたメッセージの要約をまとめ等として自動作成できる
ようにし、個人のノウハウなどの知識を収集してそれを
効率よく利用することが可能な知識蓄積支援システムお
よび同システムにおけるメッセージの要約作成方法を提
供することを目的とする。

【００１０】

【課題を解決するための手段】上述の課題を解決するた
め、本発明は、複数のクライアント端末とネットワーク
を介して接続可能に構成され、各クライアント端末から
仮想コミュニティへ投稿されたメッセージを分類、蓄積
することによって知識の蓄積を支援する知識蓄積支援シ
ステムであって、前記クライアント端末からのメッセー
ジ投稿を許可するために、アクセス要求元のクライアン
ト端末に対してユーザ認証を行うアクセス制御手段と、
複数のクライアント端末が参加可能な仮想コミュニティ
を管理し、前記アクセス制御手段によってアクセス許可
された各クライアント端末から仮想コミュニティに投稿
されるメッセージを話題毎に分類、蓄積するコミュニテ
ィ処理手段と、前記仮想コミュニティ内に蓄積されたメ
ッセージ間の重複部を取り除いた状態で前記メッセージ
それぞれを連結し、前記仮想コミュニティ内に蓄積され
たメッセージ群に対応する要約を作成する要約作成手段
とを具備することを特徴とする。

【００１１】この知識蓄積支援システムにおいては、仮
想コミュニティ上でユーザ同士が交わすメッセージは話
題毎に分類、蓄積され、これにより複数のユーザ間で交
わされる会話の中に含まれる個人の知識が自動収集され
る。さらに、要約作成手段が設けられているので、収集
・蓄積された知識に対して要約作成処理を施すことによ
り、重複部を除いた状態でメッセージ群それぞれを連結
した要約が作成される。よって、オリジナルメッセージ
に対して返信メッセージを投稿する場合に、その返信メ
ッセージにオリジナルメッセージが付加された状態で投
稿されるような仕組みであっても、無駄なメッセージ部
を効率よく取り除くことができ、有効な情報のみからな
る要約を効率よく自動作成することが可能となる。

【００１２】また特に、作成された要約を、まとめとし
て管理することで、いわゆるフロー情報としての「メッ
セージの流れ」を静的なストック情報として活用でき、
メッセージとして蓄積された個人のノウハウなどの知識
を効率よく活用することが可能となる。

【００１３】また、蓄積される知識が会話を構成するメ
ッセージであるという特徴を考慮して、要約作成手段に
は、挨拶文、シグニチャ（署名）、または空行などをメ
ッセージから削除する機能をさらに設けることが好まし
い。これにより、さらに無駄のない要約作成が可能とな
る。

【００１４】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態を説明する。図１には、本発明の一実施形態に係
る知識蓄積支援システムの構成が示されている。この知
識蓄積支援システムは知識蓄積支援を持つナレッジマネ
ジメントシステムとして利用されるものであり、複数の
クライアント端末１１が共通に利用可能な仮想コミュニ
ティを用いて、知識の分類、蓄積を行う。具体的な構成
の説明を行う前に、まず、図２乃至図５を用いて本実施
形態に係る知識蓄積支援システムの概要を説明すること
にする。

【００１５】図２に示されているように、知識には「形
式知」と「暗黙知」とが存在する。現在、文書管理シス
テムやＷｅｂサーバなど、形式化された情報（形式知）
に対する整理、管理の体系は完成されつつある。しか
し、実際のところ、それらによって「知識の蓄積」とい
う点で全てを賄えているわれではない。なぜなら、実際
には単にメールによって交わされるだけの軽い会話や、
各人の頭の中だけにある知識など、非常に不明確な情報
が存在しているからである。これが「暗黙知」と呼ばれ
るものである。この暗黙知をいかにうまく取り扱い、そ
れを共有していくかが重要である。従来のシステムでは
暗黙知の蓄積を支援することは困難であり、暗黙知を取
り扱うためのシステムが必要である。

【００１６】本実施形態の知識蓄積支援システムはこの
ような暗黙知と呼ばれる情報を形式知化し、知識の蓄積
促進を目的としたツールであり、グループにおけるディ
スカッションを電子掲示板形式の仮想コミュニティで行
い、メッセージ（投稿記事）をその話題毎に分類、蓄積
する。１つの話題（以下、スレッドと称する）に対し
て、まとめを作成することも出来る。スレッドは仮想コ
ミュニティ上における関連性のある知識の束を意味す
る。まとめは、グループにおけるディスカッションを総
括する一種の議事録としての役割を持つメッセージであ
り、スレッド毎に作成することが出来る。

【００１７】メッセージの投稿は電子メールまたはＷｅ
ｂブラウザからの入力によって行い、投稿されたメッセ
ージは知識蓄積支援システムを構成するサーバ内に蓄積
される。本知識蓄積支援システムにおいては、電子メー
ルによるメッセージの投稿も可能であり、メーリングリ
ストとしての側面も持つ。各ユーザがメールによって会
話を行うだけで、知らず知らずのうちに暗黙知が蓄積さ
れていく。この様子を図３に示す。

【００１８】図３には、スポーツに関する仮想コミュニ
ティである「スポーツコミュニティ」と、英語勉強会に
関する仮想コミュニティである「英語勉強会コミュニテ
ィ」と、ある開発メンバ同士の仮想コミュニティである
「○×開発メンバコミュニティ」とが示されている。各
ユーザからの投稿メッセージはこれら各仮想コミュニテ
ィ毎に分類・蓄積され、また各仮想コミュニティ内では
スレッド毎に分類される。図３では、「スポーツコミュ
ニティ」にはスレッド１，２，３の３種類の話題に関す
るメッセージが現在蓄積されており、また、「英語勉強
会コミュニティ」にはスレッド１，２の２種類の話題に
関するメッセージが蓄積され、「○×開発メンバコミュ
ニティ」にはスレッド１の１つの話題に関するメッセー
ジが蓄積されている場合が示されている。これら各仮想
コミュニティに投稿されたメッセージは、他の知識（Ｗ
ｅｂ、ワークフロー、ファイリングシステムなどから収
集された形式知）と同様にして、知識データベース（知
識ＤＢ）に知識情報として蓄積される。特に、各スレッ
ド毎に作成される「まとめ」を知識ＤＢに収集してそれ
を例えば全文検索や自然言語検索などの検索対象として
他のメッセージに優先して適用することにより、いわゆ
るフロー情報としての「メッセージの流れ」を静的なス
トック情報として効率よく活用することが可能となる。

【００１９】＜サイト＞本明細書においては、知識蓄積
支援システムのサーバ機能を「サイト」と呼ぶ。サイト
には管理者ユーザ（Ａｄｍｉｎｉｓｔｒａｔｏｒ）が存
在し、サイト情報を管理する。サイト情報には、以下の
ようなものがある。

【００２０】（１）ユーザ情報 サイトを利用可能なユーザに関する情報 サイト管理者によって、登録、削除、変更が可能である （２）コミュニティ作成権限情報 仮想コミュニティを作成するための権限情報 仮想コミュニティ（以下、単にコミュニティと言う）と
は、メッセージの投稿、閲覧のために複数のユーザによ
って共通に利用可能な一種の電子掲示版であり、同じ目
的を持って集まった人たちがコミュニケーションを行う
「場」のことを示す。各ユーザは、目的に見合ったテー
マのコミュニティに対してアクセスすることで、必要な
知識を得たり、メッセージ（記事）を投稿したりする。
各コミュニティには最低１名の管理者がいる（コミュニ
ティ作成者がデフォルトで管理者となるが変更可能）。
コミュニティ作成に関する権限は、以下の２つから選択
することができる。

【００２１】・登録されている全てのユーザが、コミュ
ニティを作成できる。

【００２２】・サイト管理者に承認されたユーザのみ、
コミュニティを作成できる。

【００２３】（３）コミュニティのカテゴリ情報 コミュニティを分類するためのカテゴリ情報 これは、サイト管理者によって登録、削除、変更が可能
である。

【００２４】＜コミュニティ＞次に、コミュニティにつ
いて説明する。各コミュニティを管理するためのコミュ
ニティ情報（コミュニティのプロパティ）には、以下の
ようなものがある。

【００２５】（１）名前 コミュニティの名前 （２）投稿用メールアドレス コミュニティ毎にもつメールアドレス。ユーザがこのア
ドレスにメールを送ると、その内容が自動的に新規投稿
メッセージとして該当するコミュニティに登録される。

【００２６】（３）受信メールのSubject情報 コミュニティに対する参加形態には、Ｗｅｂブラウザを
通じてメッセージの閲覧、投稿を行う「Ｗｅｂで購読」
と、Ｗｅｂブラウザを通じたメッセージの閲覧、投稿に
加え、新規投稿メッセージの自動メール配信サービスが
受けられる「メールで購読」とがある。「メールで購
読」を選択したユーザに対しては、そのコミュニティに
新規メッセージが投稿されると、自動的にその新規投稿
メッセージが電子メールにて配信される。その際、配信
される電子メールのSubject情報には、上記「受信メー
ルのSubject情報」（例えば、｛コミュニティ名，メッ
セージ番号｝等の情報）が付加される。

【００２７】（４）作成者 コミュニティを作成したユーザ名 （５）作成日 コミュニティが作成された日付 （６）コミュニティの紹介 コミュニティの簡単な紹介文 （７）コミュニティのカテゴリ 上述したようにコミュニティはその内容に応じてカテゴ
リ分けすることができ、分類先のカテゴリに関する情報
がコミュニティ毎に保持される。カテゴリは、サイト管
理者によって登録されたものを使用する。

【００２８】（８）コミュニティタイプ コミュニティの公開レベルのことを意味する。コミュニ
ティの公開レベルには、自由参加の「公開制」、承認さ
れた参加者のグループからなる「メンバ制」、承認され
た参加者以外には公開しない「非公開制」の３つがあ
る。

【００２９】（９）統計情報 各コミュニティ毎にそれに属しているユーザの数や参加
者別の発言数ランキングなどを含む。

【００３０】（１０）管理者 このコミュニティを管理する管理者名 （１１）メンバ このコミュニティに属している（アクセス可能な）ユー
ザ （１２）メッセージ削除権限 投稿済みメッセージの削除を許されているユーザ。以下
のいずれかを選択できる。

【００３１】・コミュニティ管理者のみ ・コミュニティ管理者と投稿者 ＜メッセージとスレッド＞次に、メッセージとスレッド
について説明する。メッセージとは、コミュニティ内の
会話において、やりとりされる発言（記事の投稿）一つ
一つのことである。メッセージには複数のファイルを添
付することも可能である。メッセージはＷｅｂブラウザ
からの入力またはコミュニティが持つメールアドレスへ
のメール送信によって投稿できる。

【００３２】スレッドとは、上述したようにある話題に
関するメッセージの束のことである。１つの話題に対し
て、様々な意見（メッセージ）によって会話が進んでい
き、結論を出す。この結論が「まとめ」である。本知識
蓄積支援システムにおいては「まとめ」に関する作成支
援機能も有している。この作成支援機能を利用すること
により、該当するスレッド内のメッセージや添付ファイ
ルなどを援用しつつ、話題の結論としての「まとめ」を
容易に作成することができる。

【００３３】図４には、スレッドを構成するメッセージ
の階層構造の一例が示されている。図４において、スレ
ッド１には５つのメッセージ１，２，３，４，５が含ま
れている。このスレッド１の構造は、まず、メッセージ
１が投稿され、そのメッセージ１に対する返信（応答）
メッセージとしてメッセージ２，３が投稿され、そして
メッセージ３に対する返信（応答）メッセージとしてメ
ッセージ４が投稿され、さらにメッセージ１に対する返
信（応答）メッセージとしてメッセージ５が投稿された
場合に対応している。

【００３４】また、スレッド２も５つのメッセージ１，
２，３，４，５から構成されているが、これは、最初に
投稿されたメッセージ１に対する返信（応答）メッセー
ジとしてメッセージ２，３が投稿され、そしてさらにメ
ッセージ３に対する返信（応答）メッセージとしてメッ
セージ４，５が投稿された場合に対応している。

【００３５】なお、スレッド１，２の各メッセージに対
する返信とは異なるメッセージがスレッド１，２と同一
のコミュニティに対して新たに投稿された場合には、そ
の新規投稿メッセージにはスレッド３が割り当てられる
ことになる。

【００３６】＜まとめ＞「まとめ」とは、上述したよう
に会話（スレッド）に対する「結論」のことである。職
場などの会議で言えば「議事録」に相当し、開発ならば
レビューに対する「仕様書」に相当する。図５に示すよ
うに１つのスレッドに対して、１つの「まとめ」が対応
する。つまり、ユーザまたは管理者によってスレッド毎
に、そのスレッド内のメッセージ群の総括たる「まと
め」が作成され、それが該当するスレッドを構成するメ
ッセージの１特殊形態として管理される。「まとめ」も
メッセージであるので、他の通常のメッセージと同様に
複数のファイルを添付することができる。

【００３７】また、「まとめ」は改訂することができ、
既に作成された「まとめ」を更新すること等によって新
たな「まとめ」を作成し、それを最新の「まとめ」とし
て登録することができる。「まとめ」の作成はユーザが
手作業でメッセージを編集することなどによって行うこ
とも出来るが、本システムにはまとめ作成の支援機能も
用意されており、自動的に作成することもできる。

【００３８】＜メールによるメッセージの投稿＞メール
によって、各コミュニティに投稿されたメッセージは、
以下の手順で処理される。 （１）ユーザは、投稿先のコミュニティに割り当てられ
ているメールアドレスに対してメッセージをメールにて
投稿する （２）知識蓄積支援システムのサーバは、全てのコミュ
ニティ宛に届いたメールをメールサーバから一括取得す
る （３）知識蓄積支援システムのサーバは、投稿先メール
アドレスによってどのコミュニティ宛のメッセージなの
かを判断し、振り分ける。

【００３９】（４）知識蓄積支援システムのサーバは、
取得したメールのヘッダ情報（またはタイトル）によ
り、該当するコミュニティ内のどのスレッドのどの階層
に登録するかを判別し、取得したメールの本文をそこに
メッセージとして登録する。

【００４０】メールによってコミュニティ宛に投稿され
たメッセージは上記の処理によって自動的に該当する場
所に格納されていく。ユーザは、メーリングリストへの
投稿と同じ感覚で、メッセージを投稿するだけでよい。

【００４１】＜メッセージ購読タイプ＞知識蓄積支援シ
ステムを利用するユーザは、上述したようにメッセージ
の購読タイプとして、以下の２種類を選択することがで
きる。

【００４２】・Ｗｅｂブラウザによる購読（知識蓄積支
援システムのＵＲＬ（Uniform Resource Locator）へア
クセスする） ・メールによる購読 ユーザがどちらの購読タイプを選択してもＷｅｂブラウ
ザからの購読（投稿も含む）が可能である。つまり、メ
ッセージの新規投稿が行われた際に、自動的にそのメッ
セージをメール配信するかどうかの選択である。メッセ
ージの新規投稿が行われると、メール購読を選択してい
るユーザにはメッセージのメール配信が行われる。メッ
セージ購読タイプの選択は、ユーザが属しているコミュ
ニティ毎に行うことが出来る。

【００４３】＜システム構成＞次に、図１を参照して、
本実施形態に係る知識蓄積支援システムのシステム構成
について説明する。

【００４４】本実施形態の知識蓄積支援システムは、複
数のクライアント端末１１に対してＬＡＮ等のコンピュ
ータネットワーク１３を介して相互に接続可能なサーバ
コンピュータ１２にて実現されている。サーバコンピュ
ータ１２とクライアント端末１１には、それぞれ、図示
しないが、ＣＰＵ、メインメモリ、記憶装置としての磁
気ディスク装置、及びキーボードやマウスなどの入力部
とディスプレイなどの表示部とを持つ入出力装置が設け
られている。

【００４５】上記クライアント端末１１では、Ｗｅｂブ
ラウザ１１１とメールクライアント１１２のいずれか一
方又は両方が動作している。サーバコンピュータ１２上
に構築された知識蓄積支援のためのリソースを示すＵＲ
Ｌ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏ
ｒ）をＷｅｂブラウザ１１１から指定したり、あるいは
コミュニティサーバ１２２にて管理される各コミュニテ
ィのメールアドレス宛にメールクライアント１２からメ
ール送信を行うことにより、知識蓄積支援処理を各クラ
イアント端末１１から利用することができる。

【００４６】上記サーバコンピュータ１２の知識蓄積支
援機能は、主に、制御部１２１、コミュニティサーバ１
２２、Ｗｅｂサーバ１２７、およびメールサーバ１２８
などのソフトウェアと、これらソフトフェアによるメッ
セージの投稿、閲覧の管理のために利用される管理情報
および実データとによって実現されている。管理情報に
は各クライアント端末１１に対してユーザ認証を行うた
めのログイン管理情報１２３と、各コミュニティ毎にそ
の管理を行うためのコミュニティ管理情報１２４とが存
在し、また実データとしてはメッセージデータ１２５と
添付ファイル１２６とが存在する。

【００４７】制御部１２１は知識蓄積支援に関する全体
の動作を制御するためのものであり、Ｗｅｂサーバ１２
７およびメールサーバ１２８それぞれと本知識蓄積支援
システムの中核プログラムであるコミュニティサーバ１
２２との間の仲介機能を初め、Ｗｅｂサーバ１２７およ
びメールサーバ１２８を通じて各クライアント端末１１
がコミュニティサーバ１２２にログインする際のユーザ
認証機能を持つ。このユーザ認証のために、制御部１２
１はログイン管理情報１２３を管理している。このログ
イン管理情報１２３には、本知識蓄積支援システムに参
加しているユーザそれぞれのユーザＩＤとパスワード等
が格納されている。このユーザ認証により、各クライア
ント端末１１からのメッセージ投稿等の為になされるコ
ミュニティサーバ１２２に対するアクセスの許可・禁止
の制御が行われる。

【００４８】コミュニティサーバ１２２は複数のクライ
アント端末１１が参加可能なコミュニティの管理、運用
を行うためのものであり、各クライアント端末１１から
投稿されたメッセージをコミュニティ毎、且つ話題（ス
レッド）毎に分類、蓄積する。コミュニティサーバ１２
２による各コミュニティの管理・運用は、コミュニティ
管理情報１２４、メッセージデータ１２５、および添付
ファイル１２６を用いて行われる。つまり、これらコミ
ュニティ管理情報１２４、メッセージデータ１２５、お
よび添付ファイル１２６は、コミュニティ毎にメッセー
ジの蓄積・管理を行うためのデータベースとして利用さ
れる。

【００４９】さらに、コミュニティサーバ１２２には、
ユーザ操作権限制御部１２９、検索エンジン１３０、簡
易要約作成部１３１とが設けられている。ユーザ操作権
限制御部１２９は各クライアント端末１１のユーザの操
作権限をそのアクセス先となるコミュニティ毎に決定す
る。このために、ユーザ操作権限制御部１２９はコミュ
ニティ管理情報１２４を用いてコミュニティ毎にその公
開レベルを示すコミュニティタイプとその仮想コミュニ
ティに対するユーザの参加属性を示すメンバタイプとを
管理しており、それらコミュニティタイプとメンバタイ
プとの組み合わせによって各クライアント端末１１毎に
アクセス先のコミュニティに対する操作を制限する。具
体的な制限方法については後述するが、基本的には、ア
クセス要求元のクライアント端末１１が可能な操作を決
定し、その操作のみが可能な画面をアクセス要求元のク
ライアント端末に提供するという処理によって行われ
る。

【００５０】検索エンジン１３０は全文検索や自然言語
検索によってメッセージデータ１２５として蓄積されて
いる各コミュニティのメッセージの中から該当するメッ
セージを検索する。この検索エンジン１３０によって検
索されたメッセージの一覧を検索要求元のクライアント
端末１１に送信する場合には、ユーザ操作権限制御部１
２９の制御の下、検索要求元のクライアント端末１１が
閲覧権限を持つメッセージに関する検索結果一覧のみが
検索要求元のクライアント端末１１に送られる。

【００５１】簡易要約作成部１３１は、スレッド毎にメ
ッセージ群の要約を作成するためのツールである。この
簡易要約作成部１３１は主に「まとめ」の作成支援のた
めに用いられ、「まとめ」作成時に簡易要約作成部１３
１による要約作成機能を実行することにより、同一スレ
ッド内の互いに関連するメッセージ群から重複部分を除
去した簡易要約を「まとめ」として作成することができ
る。

【００５２】次に、コミュニティ管理情報１２４を構成
する各テーブルについて説明する。

【００５３】図１に示されているように、コミュニティ
管理情報１２４は、ユーザテーブル２０１、コミュニテ
ィテーブル２０２、購読タイプテーブル２０３、メンバ
テーブル２０４、スレッドテーブル２０５、メッセージ
テーブル２０６、まとめテーブル２０７、およびユーザ
許可操作テーブル２０８などから構成されている。以
下、これら各テーブルについて説明する。

【００５４】＜ユーザテーブル＞図６はユーザを管理す
るユーザテーブル２０１の構成例を示す図である。ユー
ザテーブル２０１には、本システムに参加しているユー
ザそれぞれについてユーザＩＤ、ユーザ名、およびメー
ルアドレスが格納されている。図６においては、ユーザ
ＩＤ「Ｕ００００１」、ユーザ名「田中一郎」、メール
アドレス「ichiro.tanaka@xxx.co.jp」のユーザと、ユ
ーザＩＤ「Ｕ００００２」、ユーザ名「山田太郎」、メ
ールアドレス「taro.yamada@xxx.co.jp」のユーザが登
録されている例が示されている。

【００５５】＜コミュニティテーブル＞図７はコミュニ
ティを管理するコミュニティテーブル２０２の構成例を
示す図である。コミュニティテーブル２０２は本知識支
援システム上に作成された各コミュニティに関する情報
を管理するためのテーブルであり、ここには、本知識支
援システム上に作成されたコミュニティそれぞれについ
て、コミュニティＩＤ、コミュニティ名、コミュニティ
タイプと、そのコミュニティに参加しているメンバそれ
ぞれのメンバＩＤリストとが対応付けて格納されてい
る。図７においては、コミュニティＩＤ「Ｃ００１」、
コミュニティ名「コミュニティＡ」のコミュニティは、
コミュニティタイプが「公開」で、そこにはメンバＩＤ
「Ｍ０００００１」、「Ｍ０００００４」、…が割り当
てられたユーザが参加しており、またコミュニティＩＤ
「Ｃ００２」、コミュニティ名「コミュニティＢ」のコ
ミュニティは、コミュニティタイプが「メンバ制」で、
そこにはメンバＩＤ「Ｍ０００００２」、「Ｍ００００
０３」、…が割り当てられたユーザが参加している場合
を示している。なお、メンバＩＤは全コミュニティにわ
たってユニークであり、各ユーザには参加しているコミ
ュニティの数と同数のメンバＩＤが割り当てられる。

【００５６】＜購読タイプテーブル＞図８は購読タイプ
を管理する購読タイプテーブル２０３の構成例を示す図
である。購読タイプテーブル２０３には、本システムに
参加しているユーザそれぞれについてユーザＩＤ、ユー
ザ名、参加しているコミュニティのコミュニティＩＤ、
そのコミュニティに対する購読タイプ、および購読タイ
プがメールの場合のユーザのメールアドレスが格納され
ている。なお、ユーザテーブル２０１でメールアドレス
を管理する場合には購読タイプテーブル２０３には必ず
しもメールアドレスを登録する必要はない。

【００５７】図８においては、ユーザＩＤが「Ｕ０００
０１」で、ユーザ名が「田中一郎」のユーザが、コミュ
ニティＩＤ「Ｃ００１」と「Ｃ００２」の２つのコミュ
ニティに参加しており、コミュニティＩＤ「Ｃ００１」
のコミュニティに関する購読タイプはＷｅｂで、コミュ
ニティＩＤ「Ｃ００１」のコミュニティに関する購読タ
イプがメールであり、またユーザＩＤが「Ｕ００００
２」で、ユーザ名が「山田太郎」のユーザが、コミュニ
ティＩＤ「Ｃ００５」のコミュニティに参加しており、
そのコミュニティに関する購読タイプがＷｅｂである場
合を示している。

【００５８】＜メンバテーブル＞図９はメンバを管理す
るメンバテーブル２０４の構成例を示す図である。メン
バテーブル２０４には、メンバＩＤそれぞれについて、
それが参加しているコミュニティに関する参加属性を示
すメンバタイプと、メンバとして参加しているユーザの
ユーザ名とが格納されている。メンバタイプには、参加
が承認されている「参加者」、参加者として仮登録され
ている「仮登録者」、参加を申し込んでいるが承認され
ていない「参加希望者」、参加に関する手続きを行って
おらず一種のゲストとして参加する「匿名」とがある。

【００５９】図９においては、ユーザ名「田中一郎」の
ユーザは、メンバＩＤ「Ｍ０００００１」として参加し
ているコミュニティに対してはそのメンバタイプが「参
加者」で、またメンバＩＤ「Ｍ０００００３」として参
加しているコミュニティに対してはそのメンバタイプが
「参加希望者」であり、またユーザ名「山田太郎」のユ
ーザは、メンバＩＤ「Ｍ０００００２」として参加して
いるコミュニティに対してはそのメンバタイプが「仮登
録者」で、またメンバＩＤ「Ｍ０００００４」として参
加しているコミュニティに対してはそのメンバタイプが
「匿名」である場合を示している。

【００６０】＜スレッドテーブル＞図１０はスレッドを
管理するスレッドテーブル２０５の構成例を示す図であ
る。スレッドテーブル２０５には、コミュニティそれぞ
れについてコミュニティＩＤと、そのコミュニティ内に
生成されているスレッドそれぞれのスレッドＩＤを含む
スレッドＩＤリストとが格納されている。スレッドＩＤ
も全コミュニティについてユニークな値が用いられる。

【００６１】図１０においては、コミュニティＩＤ「Ｃ
００１」のコミュニティにはスレッドＩＤ「Ｔ０１００
１」、「Ｔ０１００２」、…のスレッドが含まれてお
り、またコミュニティＩＤ「Ｃ００２」のコミュニティ
にはスレッドＩＤ「Ｔ０２００１」、…のスレッドが含
まれている場合を示している。

【００６２】＜メッセージテーブル＞図１１はメッセー
ジを管理するメッセージテーブル２０６の構成例を示す
図である。メッセージテーブル２０６には、スレッドＩ
Ｄ毎にそれを構成するメッセージそれぞれのメッセージ
ＩＤと、メッセージデータ１２５として格納されている
該当するメッセージの実データの所在を示すＵＲＬ情報
（メッセージデータＵＲＬ）とが格納されている。な
お、このメッセージデータＵＲＬは該当するスレッドＩ
ＤとメッセージＩＤとから一義に特定できるようにして
もよく、この場合にはメッセージデータＵＲＬのフィー
ルドは不要となる。

【００６３】＜まとめテーブル＞図１２はスレッド毎に
作成される「まとめ」を管理するまとめテーブル２０７
の構成例を示す図である。まとめテーブル２０７には、
スレッドＩＤ毎に、そのスレッドの「まとめ」として作
成・登録されたメッセージのメッセージＩＤと、複数の
「まとめ」が作成・登録された場合における各メッセー
ジの版番号と、メッセージデータ１２５として格納され
ている該当する「まとめ」に関するメッセージの実デー
タの所在を示すＵＲＬ情報（メッセージデータＵＲＬ）
とが格納されている。

【００６４】メッセージテーブル２０６の場合と同様
に、まとめテーブル２０７のメッセージデータＵＲＬは
該当するスレッドＩＤとメッセージＩＤとから一義に特
定できるようにしてもよく、この場合にはメッセージデ
ータＵＲＬのフィールドは不要となる。

【００６５】＜ユーザ許可操作テーブル＞次に、ユーザ
許可操作テーブル２０８について説明する。まず、ユー
ザ許可操作テーブル２０８の構成に先立ち、コミュニテ
ィとメンバとユーザとの関係について説明することにす
る。コミュニティとメンバとユーザとの関係の一例を図
１３に示す。

【００６６】図１３においては、コミュニティＡには参
加メンバであるＭ０００００１と匿名メンバであるＭ０
００００４とが存在しており、コミュニティＢには参加
希望メンバであるＭ０００００３と仮登録メンバである
Ｍ０００００２とが存在している場合を想定している。
ユーザ名「田中一郎」のユーザはコミュニティＡの参加
メンバＭ０００００１とコミュニティＢの参加希望メン
バＭ０００００３であり、またユーザ名「山田太郎」の
ユーザはコミュニティＡの匿名メンバＭ０００００４と
コミュニティＢの仮登録メンバＭ０００００２であるこ
とを示している。

【００６７】このように、各ユーザは複数のコミュニテ
ィに参加することが出来、且つメンバタイプはその参加
コミュニティ毎に個別に設定される。

【００６８】図１４はユーザ許可操作テーブル２０８の
構成例を示す図である。ユーザ許可操作テーブル２０８
は、「公開」、「メンバ制」、「非公開」の３種類のコ
ミュニティタイプと、「参加者」、「仮登録者」、「参
加希望者」、「匿名」の４種類のメンバタイプとのマト
リックスで構成される。これら３つのコミュニティタイ
プと４つのメンバタイプの組み合わせにより、許可され
た操作やアクションが予め規定されている。

【００６９】例えば、組み合わせ操作を“×”で表すと
すると、以下のように表現され、その意味は説明の通り
である。

【００７０】 （１） 「公開」×「参加者」＝｛参照、投稿｝ これは、「公開」と「参加者」の組み合わせでは、その
コミュニティに対する参照操作と投稿操作が可能という
ことを意味している。 （２） 「公開」×「仮登録者」＝｛参照、投稿｝、
［勧誘メール］ これは、「公開」と「仮登録者」の組み合わせでは、そ
のコミュニティに対する参照操作と投稿操作が可能であ
り、さらにコミュニティサーバ１２２から「仮登録者」
のメンバに対しては「勧誘メールが当該メンバのユーザ
に配信される」ということと意味している。勧誘メール
とは、コミュニティの管理者によって「仮登録者」とし
て設定されたユーザに対して当該コミュニティに「参加
者」として参加することを促すためのメールであり、当
該コミュニティの紹介文や加入手続き画面へのリンク情
報（ＵＲＬ）などを含む勧誘メールが「仮登録者」とし
て設定された全てのユーザに対して自動送信される。

【００７１】 （３） 「公開」×「参加希望者」＝｛参照、投稿｝ これは、「公開」と「参加希望者」の組み合わせでは、
そのコミュニティに対する参照操作と投稿操作が可能と
いうことを意味している。 （４） 「公開」×「匿名」＝｛参照｝ これは、「公開」と「参加希望者」の組み合わせでは、
そのコミュニティに対する参照操作のみが可能であるこ
とを意味している。

【００７２】 （５） 「メンバ制」×「参加者」＝｛参照、投稿｝ これは、「メンバ制」と「参加者」の組み合わせでは、
そのコミュニティに対する参照操作と投稿操作が可能と
いうことを意味している。 （６） 「メンバ制」×「仮登録者」＝｛参照、投
稿｝、｛公開まとめ参照｝、［勧誘メール］、（加入→
参加者） これは、「メンバ制」と「仮登録者」の組み合わせで
は、そのコミュニティに対する参照操作と投稿操作が可
能であるが、「まとめ」のメッセージについては「公開
まとめ」として設定されたものについてのみ参照操作が
可能で、さらにコミュニティサーバ１２２から「仮登録
者」のメンバに対しては「勧誘メールが当該メンバのユ
ーザに配信される」ということと、加入手続き画面上で
「加入」の手続きを行ったユーザに対しては「仮登録
者」から「参加者」へのメンバタイプの設定変更を行う
ということを意味している。

【００７３】「公開」および「非公開」のコミュニティ
では、「まとめ」は他の通常のメッセージと全く同様に
扱われるが、「メンバ制」のコミュニティでは、図１５
に示すように、「まとめ」については、それを「参加
者」以外のメンバにも公開することを意味する「公開ま
とめ」と、「参加者」以外のメンバには公開しない「非
公開まとめ」とのいずれかに設定することが出来る。

【００７４】（７） 「メンバ制」×「参加希望者」＝
！｛参照、投稿｝、｛公開まとめ参照｝ これは、「メンバ制」と「参加希望者」の組み合わせで
は、通常のメッセージに関する参照操作と投稿操作がど
ちらも不可で、「まとめ」のメッセージについては「公
開まとめ」として設定されたものについてのみ参照操作
が可能であることを意味している。

【００７５】（８） 「メンバ制」×「匿名」＝！｛参
照、投稿｝、｛公開まとめ参照｝ これは、「メンバ制」と「匿名」の組み合わせでは、通
常のメッセージに関する参照操作と投稿操作がどちらも
不可で、「まとめ」のメッセージについては「公開まと
め」として設定されたものについてのみ参照操作が可能
であることを意味している。

【００７６】 （９） 「非公開」×「参加者」＝｛参照、投稿｝ これは、「非公開」と「参加者」の組み合わせでは、そ
のコミュニティに対する参照操作と投稿操作が可能とい
うことを意味している。 （10） 「非公開」×「仮登録者」＝！｛参照、投
稿｝、！｛まとめ参照｝、［勧誘メール］、（加入→参
加者） これは、「非公開」と「仮登録者」の組み合わせでは、
そのコミュニティに対する参照操作と投稿操作がどちら
も不可で、「まとめ」のメッセージについても「公開ま
とめ」としての概念が無いので参照が不可であり、さら
にコミュニティサーバ１２２から「仮登録者」のメンバ
に対しては「勧誘メールが当該メンバのユーザに配信さ
れる」ということと、加入手続き画面上で「加入」の手
続きを行ったユーザに対しては「仮登録者」から「参加
者」へのメンバタイプの設定変更を行うということを意
味している。

【００７７】（11） 「非公開」×「参加希望者」＝！
＜コミュニティ＞ これは、「非公開」と「参加希望者」の組み合わせは、
コミュニティの存在さえ知らないため、ありえないこと
を意味している。 （12） 「非公開」×「参加希望者」＝！＜コミュニテ
ィ＞ これは、「非公開」と「参加希望者」の組み合わせは、
コミュニティの存在さえ知らないため、ありえないこと
を意味している。

【００７８】＜簡易要約作成画面＞次に、簡易要約作成
のためのユーザインタフェースについて説明する。図１
６は、例えば「まとめ」の作成時などにおいて、コミュ
ニティサーバ１２２からＷｅｂ端末１１のＷｅｂブラウ
ザ１１１に提供される簡易要約作成画面の状態遷移の例
を示す図である。簡易要約の作成は本来はスレッド毎に
個々に行われるが、あるコミュニティに含まれる全ての
スレッドそれぞれの要約を一括して自動作成することも
できる。以下では、この場合を例に説明する。

【００７９】図１６（ａ）は例えばコミュニティ名が
“XXX”の簡易要約を作成する場合の画面表示例を示し
ている。この画面上には、作成された簡易要約のタイト
ルを入力するタイトルフィールド、簡易要約の表示・編
集を行うための本文ウィンドウ、および「簡易要約」ボ
タンなどが設けられている。「簡易要約」ボタンをクリ
ックすると、簡易要約作成部１３１による簡易要約作成
処理が自動実行され、図１６（ｂ）のように、メッセー
ジ群を重複部を排除した状態で連結した簡易要約がスレ
ッド毎に作成され、それが本文ウィンドウに表示され
る。

【００８０】図１６（ｂ）においては、スレッド１は、
最初に投稿された元のメッセージとそのメッセージに対
する返信メッセージ１１〜１ｎとから構成されている場
合に対応するものであり、通常は各返信メッセージ１１
〜１ｎの各々に元のメッセージの内容がそのまま付加さ
れているが、作成された簡易要約ではそれらは排除され
る。他のスレッドについても同様の処理がなされる。こ
のようにスレッド毎に作成された簡易要約に対して、ユ
ーザは本文ウィンドウ上でさらに編集を施すことができ
る。

【００８１】簡易要約の作成が完了し、例えば「完了」
ボタンをクリックすると、本文ウィンドウの内容がコミ
ュニティ名“XXX”の簡易要約として所定の場所に保存
される。この簡易要約作成機能を用いてあるスレッドの
「まとめ」を作成する場合には、本文ウィンドウの内容
が当該スレッドの「まとめ」メッセージとしてメッセー
ジデータ１２５に登録されると共に、それに合わせて、
まとめテーブル２０７の更新操作が実行されることにな
る。

【００８２】＜簡易要約作成方法＞次に、図１７を参照
して、簡易要約の作成方法について具体的に説明する。
図１７は簡易要約作成部１３１による簡易要約作成時に
用いられる作業用のバッファメモリの内部状態の遷移例
を示す図である。

【００８３】図１７（ａ）に示すように、バッファメモ
リには、まず、メッセージデータ１２５から読み込まれ
た各スレッドのメッセージが展開される。例えば、スレ
ッド１については、そのスレッド１に分類された最初の
投稿メッセージ（元のメッセージ）とそれに対する各返
信メッセージ１１，１２，…１ｎのリストが展開され
る。各返信メッセージ１１，１２，…１ｎには元のメッ
セージが付加されている。他のスレッドについても同様
にして、元のメッセージとそれに対する各返信メッセー
ジのリストが展開されることになる。

【００８４】図１６の「簡易要約」ボタンがクリックさ
れた時点で、簡易要約作成部１３１による簡易要約作成
処理が実行される。簡易要約作成部１３１は、まず、ス
レッド毎に各メッセージを解析し、同一スレッドに属す
るメッセージ群同士の間で重複する部分を検出する。そ
して、その重複部を取り除く処理を実行する。これによ
り、図１７（ｂ）に示すように、例えばスレッド１につ
いては各返信メッセージ１１，１２，…１ｎから元のメ
ッセージが削除され、最初の元のメッセージの後にそれ
ら返信メッセージ１１，１２，…１ｎがその順で連結さ
れる。そして、図１７（ｂ）のバッファメモリの内容が
図１６（ｂ）で説明した本文ウィンドウに簡易要約とし
て表示される。

【００８５】図１７では、説明の簡単のためにメッセー
ジネストレベルが１レベルである場合を説明したが、通
常は１つの元のメッセージに対して返信がなされ、さら
にその返信メッセージに対して返信がなされて、ｎレベ
ルのネスト構造となる。このような構造においても、各
返信メッセージからその参照元の元メッセージを除去す
ることで、不要な“ゴミ除去”を行うことが出来る。

【００８６】図１８はメッセージネストレベルが２レベ
ルである場合の処理例を示している。ここでは、図１８
（ａ）に示すように、元のメッセージ「ｘｘｘについて
教えてください」に対して、その元のメッセージ文「ｘ
ｘｘについて教えてください」が後ろに付加された返信
メッセージ１として「私は知りません …… ｘｘｘに
ついて教えてください」が投稿され、さらにその返信メ
ッセージ１に対して、その返信メッセージ１のメッセー
ジ文「私は知りません …… ｘｘｘについて教えて
ください」が後ろに付加された返信メッセージ２として
「それはＡさんが知ってます …… 私は知りません
…… ｘｘｘについて教えてください」が投稿された
場合を想定している。

【００８７】この場合、図１８（ｂ）に示すように、返
信メッセージ１からは「ｘｘｘについて教えてくださ
い」という点線で囲んだ元のメッセージ部が削除され、
本来のメッセージ部「私は知りません」のみが残され、
また返信メッセージ２からは「私は知りません ……
ｘｘｘについて教えてください」という点線で囲んだ
元のメッセージ部（返信メッセージ１）が削除され、本
来のメッセージ部「それはＡさんが知ってます」のみが
残される。

【００８８】このようなゴミ除去処理においては、実際
にはさらに、各メッセージから不要な部分を除去する処
理も行われる。例えば、各メッセージに含まれる挨拶
文、シグニチャ（署名）、空行、および引用構造を示す
引用符（図１８の例では“＜”）を検出し、その除去を
行う。つまり、ゴミ除去処理では具体的には以下の処理
が行われることになる。

【００８９】・短い挨拶文（冒頭／末尾）の判定および
除去 ・シグニチャの判定および除去 ・必要以上に多い空行の判定および除去 ・引用符による引用構造の解析および引用部（重複する
オリジナルのメッセージ部）の除去 ＜簡易要約作成処理＞次に、図１９および図２０のフロ
ーチャートを参照して、本知識蓄積支援システムにおけ
る簡易要約作成処理の手順を説明する。

【００９０】ユーザがＷｅｂブラウザ１１１によりサー
バコンピュータ１２の制御部１２１へログイン要求する
と（ステップＳ１１１）、制御部１２１は、ユーザから
入力されたユーザＩＤおよびパスワードが登録されてい
るか否かを調べるためにログイン管理情報１２３にアク
セスし（ステップＳ１１２）、このログインを許可する
かどうかを判定するためのユーザ認証を行う（ステップ
Ｓ１１３）。ユーザＩＤおよびパスワードがログイン管
理情報１２３に登録されておらず、ログインが失敗した
場合（ステップＳ１１３のＮＯ）、制御部１２１は、ロ
グイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウ
ザ１１１に返しこの処理を終了する（ステップＳ１１
４）。

【００９１】一方、ユーザＩＤおよびパスワードがログ
イン管理情報１２３に登録されており、ログインが成功
した場合（ステップＳ１１３のＹＥＳ）、コミュニティ
サーバ１２２は、指定されたコミュニティ名とユーザ名
からコミュニティ管理情報１２４のコミュニティテーブ
ル２０２を検索し、そしてスレッドテーブル２０５、メ
ッセージテーブル２０６で管理された当該コミュニティ
・当該スレッドのメッセージを検索して、Ｗｅｂブラウ
ザ１１１に返却する（ステップＳ１１５）。

【００９２】このコミュニティサーバ１２２から返され
たデータをもとにＷｅｂブラウザ１１１が図１６に示し
た簡易要約作成画面を表示する（ステップＳ１１６）。
ユーザが簡易要約作成画面上の「簡易要約」ボタンをク
リックすると（ステップＳ１１７）、Ｗｅｂブラウザ１
１１からコミュニティサーバ１２２に対して簡易要約作
成要求が送信される（ステップＳ１１８）。これを受信
したコミュニティサーバ１２２は簡易要約作成部１３１
を起動して、当該コミュニティのすべてのスレッドをメ
ッセージデータ１２５からバッファメモリに読み込んで
（ステップＳ１１９）、上述した“ゴミ除去”処理を行
い簡易要約データを作成する（ステップＳ１２０）。こ
の場合、上述したように、同じスレッドに属するメッセ
ージ間で重複する部分を削除する処理や、各メッセージ
から挨拶文、シグニチャ、引用符、空行などを削除する
処理が行われ、不要部分が除去されたメッセージ群の連
結からなる簡易要約データが１つのメッセージ文として
作成される。

【００９３】そして、この作成された簡易要約データが
コミュニティサーバ１２２からＷｅｂブラウザ１１１に
返され（ステップＳ１２１）、これを受信したＷｅｂブ
ラウザ１１１は簡易要約データを画面表示する（図２０
のステップＳ１２２）。ユーザが画面上で簡易要約の内
容を確認し、また必要な編集を行った後に「完了」ボタ
ンをクリックすると（ステップＳ１２３）、Ｗｅｂブラ
ウザ１１１は「完了」をコミュニティサーバ１２２に送
信する（ステップＳ１２４）。コミュニティサーバ１２
２は「完了」を受信するとバッファメモリ上の簡易要約
データを該当するコミュニティ内のスレッドに関する
「まとめ」としてメッセージデータ１２５にメッセージ
データ（まとめ）として追加格納する（ステップＳ１２
５）。

【００９４】以上のように、本実施形態の知識蓄積支援
システムによれば、各コミュニティに対するメッセージ
の投稿、閲覧を管理するコミュニティサーバ１２２に、
投稿されたメッセージ群に関する簡易要約を作成する仕
組みを設けたことにより、各スレッド毎の結論である
「まとめ」の作成を自動的に行うことが可能となる。特
に、作成された簡易要約ではメッセージ間の重複部や、
挨拶文などの不要な箇所が削除されているので、会話の
流れの中で必要な部分のみを「まとめ」として登録・管
理することができ、その「まとめ」を用いてメッセージ
の閲覧を効率よく行うことが可能となる。また、簡易要
約作成機能は「まとめ」の作成以外にも、例えばメッセ
ージ閲覧のための１ツールとして各ユーザに提供できる
ようにしても良い。

【００９５】なお、本実施形態の知識蓄積支援システム
の機能は全てコンピュータプログラムにより実現されて
いるので、そのコンピュータプログラムをコンピュータ
読み取り可能な記憶媒体に記憶しておき、その記憶媒体
を通じてコンピュータプログラムを、コンピュータネッ
トワーク接続可能な通常のコンピュータに導入するだけ
で、本実施形態と同様の効果を得ることができる。

【００９６】また本発明は、上記実施形態に限定される
ものではなく、実施段階ではその要旨を逸脱しない範囲
で種々に変形することが可能である。更に、上記実施形
態には種々の段階の発明が含まれており、開示される複
数の構成要件における適宜な組み合わせにより種々の発
明が抽出され得る。例えば、実施形態に示される全構成
要件から幾つかの構成要件が削除されても、発明が解決
しようとする課題の欄で述べた課題が解決でき、発明の
効果の欄で述べられている効果が得られる場合には、こ
の構成要件が削除された構成が発明として抽出され得
る。

【００９７】

【発明の効果】以上説明したように、本発明によれば、
意見交換の場である仮想コミュニティに投稿されたメッ
セージの要約をまとめ等として自動作成できるようにな
り、個人のノウハウなどの知識を収集してそれを効率よ
く利用することが可能となる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係る知識蓄積支援システ
ムのシステム構成を示すブロック図。

【図２】同実施形態の知識蓄積支援システムで扱われる
知識を説明するための図。

【図３】同実施形態の知識蓄積支援システムにおける知
識蓄積処理の原理を説明するための図。

【図４】同実施形態の知識蓄積支援システムで管理され
るメッセージとスレッドとの関係を説明するための図。

【図５】同実施形態の知識蓄積支援システムで管理され
るメッセージと「まとめ」との関係を説明するための
図。

【図６】同実施形態の知識蓄積支援システムで使用され
るユーザテーブルの一例を示す図。

【図７】同実施形態の知識蓄積支援システムで使用され
るコミュニティテーブルの一例を示す図。

【図８】同実施形態の知識蓄積支援システムで使用され
る購読タイプテーブルの一例を示す図。

【図９】同実施形態の知識蓄積支援システムで使用され
るメンバテーブルの一例を示す図。

【図１０】同実施形態の知識蓄積支援システムで使用さ
れるスレッドテーブルの一例を示す図。

【図１１】同実施形態の知識蓄積支援システムで使用さ
れるメッセージテーブルの一例を示す図。

【図１２】同実施形態の知識蓄積支援システムで使用さ
れるまとめテーブルの一例を示す図。

【図１３】同実施形態の知識蓄積支援システムで管理さ
れるコミュニティとメンバとユーザの関係の一例を示す
図。

【図１４】同実施形態の知識蓄積支援システムで使用さ
れるユーザ許可操作テーブルの一例を説明するための
図。

【図１５】同実施形態の知識蓄積支援システムのメンバ
制コミュニティ内で管理されるまとめの種類を説明する
ための図。

【図１６】同実施形態の知識蓄積支援システムにおける
簡易要約作成画面の一例を示す図。

【図１７】同実施形態の知識蓄積支援システムにおける
簡易要約作成処理の例を説明するための図。

【図１８】同実施形態の知識蓄積支援システムにおける
簡易要約作成処理の具体例を説明するための図。

【図１９】同実施形態の知識蓄積支援システムにおける
簡易要約作成処理の手順の一部を示すフローチャート。

【図２０】同実施形態の知識蓄積支援システムにおける
簡易要約作成処理の残りの手順を示すフローチャート。

【符号の説明】

１１…クライアント端末 １２…サーバコンピュータ １１１…Ｗｅｂブラウザ １１２…メールクライアント １２１…制御部 １２２…コミュニティサーバ １２３…ログイン管理情報 １２４…コミュニティ管理情報 １２５…メッセージデータ １２６…添付ファイル １２７…Ｗｅｂサーバ １２８…メールサーバ １２９…ユーザ操作権限制御部 １３０…検索エンジン １３１…簡易要約作成部 ２０１…ユーザテーブル ２０２…コミュニティテーブル ２０３…購読タイプテーブル ２０４…メンバテーブル ２０５…スレッドテーブル ２０６…メッセージテーブル ２０７…まとめテーブル ２０８…ユーザ許可操作テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 岩田 真明 東京都青梅市末広町２丁目９番地 株式会 社東芝青梅工場内 (72)発明者 島川 和典 東京都青梅市末広町２丁目９番地 株式会 社東芝青梅工場内 Ｆターム(参考） 5B075 ND20 ND23 NR02 NR12 NS01

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数のクライアント端末とネットワーク
   を介して接続可能に構成され、各クライアント端末から
   仮想コミュニティへ投稿されたメッセージを分類、蓄積
   することによって知識の蓄積を支援する知識蓄積支援シ
   ステムであって、 前記クライアント端末からのメッセージ投稿を許可する
   ために、アクセス要求元のクライアント端末に対してユ
   ーザ認証を行うアクセス制御手段と、 複数のクライアント端末が参加可能な仮想コミュニティ
   を管理し、前記アクセス制御手段によってアクセス許可
   された各クライアント端末から仮想コミュニティに投稿
   されるメッセージを話題毎に分類、蓄積するコミュニテ
   ィ処理手段と、 前記仮想コミュニティ内に蓄積されたメッセージ間の重
   複部を取り除いた状態で前記メッセージそれぞれを連結
   し、前記仮想コミュニティ内に蓄積されたメッセージ群
   に対応する要約を作成する要約作成手段とを具備するこ
   とを特徴とする知識蓄積支援システム。
2. 【請求項２】 前記コミュニティ処理手段は、前記仮想
   コミュニティ内に蓄積されているメッセージ群の結論を
   話題毎にまとめメッセージとして管理する手段をさらに
   具備し、 前記要約作成手段は、前記仮想コミュニティ内に蓄積さ
   れているメッセージ群のうち、前記まとめメッセージの
   作成対象となる話題に属するメッセージ群の要約を前記
   まとめメッセージとして作成することを特徴とする請求
   項１記載の知識蓄積支援システム。
3. 【請求項３】 前記仮想コミュニティ内に蓄積されてい
   る同一話題に関するメッセージ群は、互いに、オリジナ
   ルメッセージとその返信メッセージの関係にあるメッセ
   ージ群からなり、且つ各返信メッセージには該当するオ
   リジナルメッセージが付加されており、 前記要約作成手段は、 前記各返信メッセージからオリジナルメッセージ文を検
   出する手段と、 前記検出されたオリジナルメッセージ文を各返信メッセ
   ージから除去する手段とを含むことを特徴とする請求項
   １記載の知識蓄積支援システム。
4. 【請求項４】 前記要約作成手段は、 要約作成対象となるメッセージ群それぞれを解析して、
   各メッセージから挨拶文、シグニチャ、または空行を検
   出する手段と、 連結されたメッセージ群に挨拶文、シグニチャ、または
   空行が含まれないように、前記検出された挨拶文、シグ
   ニチャ、または空行を各メッセージから除去する手段と
   をさらに含むことを特徴とする請求項１記載の知識蓄積
   支援システム。
5. 【請求項５】 複数のクライアント端末とネットワーク
   を介して接続可能に構成され、各クライアント端末から
   仮想コミュニティへ投稿されたメッセージを分類、蓄積
   することによって知識の蓄積を支援する知識蓄積支援シ
   ステムにおけるメッセージの要約作成方法であって、 前記クライアント端末からのメッセージ投稿を許可する
   ために、アクセス要求元のクライアント端末に対してユ
   ーザ認証を行うアクセス制御ステップと、 複数のクライアント端末が参加可能な仮想コミュニティ
   を管理し、前記アクセス制御ステップによってアクセス
   許可された各クライアント端末から仮想コミュニティに
   投稿されるメッセージを話題毎に分類、蓄積するコミュ
   ニティ処理ステップと、 前記仮想コミュニティ内に蓄積されたメッセージ間の重
   複部を取り除いた状態で前記メッセージそれぞれを連結
   し、前記仮想コミュニティ内に蓄積されたメッセージ群
   の要約を作成する要約作成ステップとを具備することを
   特徴とする知識蓄積支援システムにおけるメッセージの
   要約作成方法。
6. 【請求項６】 前記コミュニティ処理ステップは、前記
   仮想コミュニティ内に蓄積されているメッセージ群の結
   論を話題毎にまとめメッセージとして管理するステップ
   をさらに具備し、 前記要約作成ステップは、前記仮想コミュニティ内に蓄
   積されているメッセージ群のうち、前記まとめメッセー
   ジの作成対象となる話題に属するメッセージ群の要約を
   前記まとめメッセージとして作成することを特徴とする
   請求項５記載の知識蓄積支援システムにおけるメッセー
   ジの要約作成方法。
7. 【請求項７】 前記仮想コミュニティ内に蓄積されてい
   る同一話題に関するメッセージ群は、互いに、オリジナ
   ルメッセージとその返信メッセージの関係にあるメッセ
   ージ群からなり、且つ各返信メッセージには該当するオ
   リジナルメッセージが付加されており、 前記要約作成ステップは、 前記各返信メッセージからオリジナルメッセージ文を検
   出するステップと、 前記検出されたオリジナルメッセージ文を各返信メッセ
   ージから除去するステップとを含むことを特徴とする請
   求項５記載の知識蓄積支援システムにおけるメッセージ
   の要約作成方法。
8. 【請求項８】 前記要約作成ステップは、 要約作成対象となるメッセージ群それぞれを解析して、
   各メッセージから挨拶文、シグニチャ、または空行を検
   出するステップと、 連結されたメッセージ群に挨拶文、シグニチャ、または
   空行が含まれないように、前記検出された挨拶文、シグ
   ニチャ、または空行を各メッセージから除去するステッ
   プとをさらに含むことを特徴とする請求項５記載の知識
   蓄積支援システムにおけるメッセージの要約作成方法。