(57)【特許請求の範囲】
【請求項１】
複数のメンバで構成されるグループと、複数のグループで構成される組織において、あるグループのあるメンバから送信されたメールを当該グループの他のメンバに配信するメーリングリストを有するメール配信手段と、
当該メーリングリストで受信したメールを蓄積して当該グループのメンバおよび他のグループのメンバに対して当該メールの一覧と当該メールの本文を表示するメール蓄積データベース手段と、
当該グループのメンバが作成した文書を蓄積して当該グループのメンバおよび他のグループのメンバに対して当該文書の一覧と当該文書の本文を表示する文書蓄積データベース手段と、
当該メーリングリストで受信したメールに類似した他のグループの過去の蓄積メールおよび蓄積文書を当該メール蓄積データベース手段および当該文書蓄積データベース手段から検索し、検索された類似メールおよび類似文書の属性情報を、当該受信したメールの送信者に返信する手段と
を備えたことを特徴とする、メールと文書の流通システム。
【請求項２】
複数のメンバで構成されるグループと、複数のグループで構成される組織において、あるグループのあるメンバから送信されたメールを当該グループの他のメンバに配信するメーリングリストを有するメール配信手段と、
当該メーリングリストで受信したメールを蓄積して当該グループのメンバおよび他のグループのメンバに対して当該メールの一覧と当該メールの本文を表示するメール蓄積データベース手段と、
当該グループのメンバが作成した文書を蓄積して当該グループのメンバおよび他のグループのメンバに対して当該文書の一覧と当該文書の本文を表示する文書蓄積データベース手段と、
当該メーリングリストで受信したメールに類似した、他のグループの過去の蓄積メールを当該メール蓄積データベース手段から検索し、検索された類似メールを過去に送信したメンバに対して、当該メーリングリストで受信したメールの属性情報を返信する手段と
を備えたことを特徴とする、メールと文書の流通システム。
【請求項３】
請求項２に記載のメールと文書の流通システムにおいて、
前記類似メールの送信者への前記受信したメールの情報の送信は、定期的に実行するものであることを特徴とする、メールと文書の流通システム。
【請求項４】
請求項１から３の何れか１つに記載のメールと文書の流通システムにおいて、前記受信メールを蓄積するデータベース手段は、アクセス権限の異なるメールをそれぞれ蓄積する２つ以上のデータベースを含むとともに、前記受信メールをいずれのデータベースに蓄積するかを判別する手段を備えたことを特徴とする、メールと文書の流通システム。
【請求項５】
請求項４に記載のメールと文書の流通システムにおいて、
前記受信メールをいずれのデータベースに蓄積するかを判別する手段は、受信メールの表題に基づいて判別するものであることを特徴とする、メールと文書の流通システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、メーリングリストシステムと知識共有システムとを統合し、メーリングリストに送られたメールを知識共有システムに蓄積して、複数のユーザにより知識交流を行なうことができるシステムに関する。
【０００２】
【従来の技術】
従来より、個人が持つ知識をグループで共有するシステムとして、例えば、メーリングリストシステム、メーリングリストアーカイブシステム、および知識共有システムなどが知られている。
【０００３】
メーリングリストシステムは、同一のメールを複数のユーザに配信するシステムである。メーリングリストシステムでは、あらかじめ決められたグループ（そのメーリングリストに参加しているメンバからなるグループ）の一人のメンバが送信したメールを他のメンバに配信することによって、グループ内での知識交換および知識共有を可能とする。メーリングリストシステムは、特定のカテゴリに関連する知識を持つ者など特定の知識に関心がある者からなるグループで知識を共有するためのものである。
【０００４】
メーリングリストアーカイブシステムは、メーリングリストシステムが扱う知識を蓄積し、再利用するためのシステムである。メーリングリストアーカイブシステムでは、メーリングリストシステムでやりとりされるメールの内容を、Ｗｅｂの公開データベースに蓄積する。また、グループのメンバまたはメンバ以外の者が、蓄積されたメールの内容を参照および検索する機能を提供する。
【０００５】
知識共有システムは、企業などの大規模なグループで知識を共有するためのシステムである。知識共有システムは、通常、グループウェアと検索エンジンで構成され、グループのメンバが持つ知識を蓄積する機能や、必要な知識を探し出したり、蓄積された知識の傾向を分析するための類似検索機能などの知識処理機能を提供するものである。類似検索とは、複数の文書間の類似度を計算し、類似度の高い文書を検索する方法である。代表的な検索アルゴリズムとして、ベクトル空間法がある。ベクトル空間法については、例えば、「Ｓａｌｔｏｎ，Ｇ．：  Ｔｈｅ  Ｖｅｃｔｏｒ  Ｓｐａｃｅ  Ｍｏｄｅｌ，  Ａｕｔｏｍａｔｉｃ  Ｔｅｘｔ  Ｐｒｏｃｅｓｓｉｎｇ，  Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｕｂｌｉｓｈｉｎｇ，  ｐｐ．３１２−３２５  （１９８９）」などの文献がある。
【０００６】
さらに、ユーザからの質問メールに関連する情報をメールで返信するシステムとして、特開平１１−２７５１３７号「電子メール管理支援方法およびそのプログラム記録媒体」、米国特許出願番号７８６１０９「Ｓｙｓｔｅｍ  ａｎｄ  ｍｅｔｈｏｄ  ｔｏ  ａｎｓｗｅｒ  ａ  ｑｕｅｓｔｉｏｎ」、および特開２０００−２０５４１「問題解決支援システム」などに開示されたものがある。ユーザが参照した文書を格納し、ユーザの興味に関連する文書が登録されると通知するシステムとして、例えば、特開平９−１５３０５０号「文書情報収集方法および文書情報収集装置」などがある。また、投稿されたメール同士のマッチングをおこない、類似したメールを送信者に返信するシステムとして、特開平１０−５１４８３「電子メールのマッチング方法及び装置」がある。
【０００７】
【発明が解決しようとする課題】
上述した従来の知識共有システムでは、ユーザが知識を登録する操作を行わないと知識が蓄積されない。そのため、知識の登録に積極的でないユーザの持っている知識が共有されないという問題点がある。また、ユーザが自ら知識を参照する操作を行わないと知識が参照されない。そのため、知識の参照に積極的でないユーザが共有知識を有効に活用することができないという問題点がある。さらに、従来の知識共有システムでは、言葉で表現できる客観的で理性的な知識（形式知）は共有できるが、個人が持っている言葉にできない知識（暗黙知）を共有することができない。このため、個人の暗黙知を活用した知識創造が促進されないという問題がある。形式知と暗黙知については、例えば、「野中郁次郎、竹中弘高著、梅本勝博訳：知識創造企業、東洋経済新聞社（１９９６）」などの文献がある。
【０００８】
従来のメーリングリストシステムでは、知識はユーザのメールボックスに存在するため、知識共有システムの提供する類似検索機能等の高度な検索・分析機能を利用することができない。また、カテゴリ毎にメーリングリストを運営すると、カテゴリ内（グループ内）での知識共有はできるが、異なるカテゴリの間での知識交流が阻害される。さらに、カテゴリを規定しない大人数のメーリングリストを運営すると、異なるカテゴリの知識が混在し、必要な知識が多量の知識の中に埋もれてしまうという問題がある。
【０００９】
従来のメーリングリストアーカイブシステムでは、メールはＷｅｂのデータベースに蓄積するため、知識共有システムの提供する類似検索機能等の高度な検索・分析機能を利用することができない。知識を広く共有するために、メール蓄積データベースをメーリングリストのメンバ以外に公開すると、メンバ以外に見せてはならない機密情報が漏洩するという問題がある。
【００１０】
上述したユーザからの質問メールに関連する情報をメールで返信するシステムでは、質問メールを送信したユーザは、同様の質問を誰が送信したかを知ることができない。また、ユーザは他のユーザの質問メールに対する回答メールを送信することができない。
【００１１】
上述したユーザが参照した文書を格納しユーザの興味に関連する文書が登録されると通知するシステムは、既に文書になっている知識のみ格納・通知するシステムであり、ユーザの頭の中にある知識の文書化を促進するものではない。上述した投稿されたメール同士のマッチングをおこない、類似したメールを送信者に返信するシステムは、メーリングリストの仕組みを備えていないため、特定グループのメンバ同士の情報共有ができない。また、メール送信のたびに即時に返信するため、日常的に授受されるメールを対象とすると、返信の頻度と含まれる情報量が過多となる。
【００１２】
本発明は、上述した従来技術における種々の問題点を解決することを目的とし、特に、メーリングリストシステムと知識共有システムとを統合し、メーリングリストに送られたメールを知識共有システムに蓄積して、種々のカテゴリの知識を有効に活用できるようにすることを目的とする。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、請求項１に係る知識交流システムは、複数のメンバで構成されるグループと、複数のグループで構成される組織において、あるグループのあるメンバから送信されたメールを当該グループの他のメンバに配信するメーリングリストを有するメール配信手段と、当該メーリングリストで受信したメールを蓄積して当該グループのメンバおよび他のグループのメンバに対して当該メールの一覧と当該メールの本文を表示するメール蓄積データベース手段と、当該グループのメンバが作成した文書を蓄積して当該グループのメンバおよび他のグループのメンバに対して当該文書の一覧と当該文書の本文を表示する文書蓄積データベース手段と、当該メーリングリストで受信したメールに類似した他のグループの過去の蓄積メールおよび蓄積文書を当該メール蓄積データベース手段および当該文書蓄積データベース手段から検索し、検索された類似メールおよび類似文書の表題、作成者の氏名とメールアドレス、本文の蓄積場所および本文の要約を、当該受信したメールの送信者に返信する手段とを備えたことを特徴とする。
【００１４】
請求項２に係る知識交流システムは、複数のメンバで構成されるグループと、複数のグループで構成される組織において、あるグループのあるメンバから送信されたメールを当該グループの他のメンバに配信するメーリングリストを有するメール配信手段と、当該メーリングリストで受信したメールを蓄積して当該グループのメンバおよび他のグループのメンバに対して当該メールの一覧と当該メールの本文を表示するメール蓄積データベース手段と、当該グループのメンバが作成した文書を蓄積して当該グループのメンバおよび他のグループのメンバに対して当該文書の一覧と当該文書の本文を表示する文書蓄積データベース手段と、当該メーリングリストで受信したメールに類似した、他のグループの過去の蓄積メールを当該メール蓄積データベース手段から検索し、検索された類似メールを過去に送信したメンバに対して、当該メーリングリストで受信したメールの表題、作成者のメールアドレス、本文の蓄積場所および本文の要約を返信する手段とを備えたことを特徴とする。
【００１５】
請求項３に係る発明は、請求項２において、前記類似メールの送信者への前記受信したメールの情報の送信は、定期的に、またはオペレータが要求したときに実行するものであることを特徴とする。
【００１６】
請求項４に係る発明は、請求項１〜３において、前記受信メールを蓄積するデータベース手段は、アクセス権限の異なるメールをそれぞれ蓄積する２つ以上のデータベースを含むとともに、前記受信メールをいずれのデータベースに蓄積するかを判別する手段を備えたことを特徴とする。
【００１７】
請求項５に係る発明は、請求項４において、前記受信メールをいずれのデータベースに蓄積するかを判別する手段は、受信メールの表題に基づいて判別するものであることを特徴とする。
【００１８】
【発明の実施の形態】
以下、図面を用いて、本発明の実施の形態について説明する。
【００１９】
図１は、本発明の一実施形態に係る知識交流システムのシステム構成例を示す。１０１−１は、メーリングリストの１つのグループを示し、クライアント１、クライアント２、…、およびクライアントｍがこのグループに属している。１０１−２および１０１−Ｎも同様のメーリングリストのグループを示している。これらのグループに属する各クライアントは、コンピュータネットワーク１０２に接続されている。また、コンピュータネットワーク１０２には、エージェント１０３、検索エンジン１０５、およびグループウェア１０６が接続されている。エージェント１０３は、各クライアントから送信されるメールの収集、蓄積、および配信を行うものであり、その動作の詳細は後に詳しく説明する。エージェント１０３には、メール情報データベース（ＤＢ）１０４が接続されている。メール情報ＤＢ１０４は、エージェント１０３がメールの収集、蓄積、および配信を行うために参照するＤＢである。
【００２０】
グループウェア１０６は、メールおよび共有文書を蓄積するものである。メール蓄積ＤＢ１０７はメールを蓄積するＤＢであり、共有文書ＤＢ１０８は共有文書を蓄積するＤＢである。メール蓄積ＤＢ１０７は、グループごとのメール蓄積ＤＢに分かれており、各グループのメール蓄積ＤＢは公開用ＤＢと非公開用ＤＢの２種類に分かれている。例えば、１１１−１はグループ１（１０１−１）の公開用ＤＢ、１１２−１はグループ１（１０１−１）の非公開用ＤＢ、１１１−２はグループ２（１０１−２）の公開用ＤＢ、１１２−２はグループ２（１０１−２）の非公開用ＤＢ、…、１１１−ＮはグループＮ（１０１−Ｎ）の公開用ＤＢ、１１２−ＮはグループＮ（１０１−Ｎ）の非公開用ＤＢである。検索エンジン１０５は、グループウェア１０６に対して検索を行うものである。ここでは、検索エンジン１０５は、グループウェア１０６における複数のデータベースに蓄積された文書に対して検索を行うものとし、検索キーとしては自然文をサポートするものとする。検索アルゴリズムは、ベクトル空間法を用いる。ベクトル空間法による検索の処理内容は、例えば、以下の▲１▼〜▲４▼のようなものである。
【００２１】
▲１▼新しく保存された文書において、文書内の各名詞句に対してｔｆおよびｉｄｆ（ｔｆ：文書中の単語の出現回数、ｉｄｆ：単語の出現文書数の逆数）より文書における重要度を計算し、各単語を次元とするベクトル空間における文書のベクトルを求める。このベクトルをインデックスに保存する。
▲２▼検索を行うとき、検索キーの自然文に対して▲１▼と同様の処理を行い、ベクトルを求める。
▲３▼検索キーのベクトルとインデックスにおける各文書のベクトル間の角度のコサインを求め、これを類似度とする。
▲４▼類似度の高い順に並べた文書一覧を返す。
【００２２】
図２は、図１に示した知識交流システムの実施形態の具体的なモデルケースの構成例および動作例を示す。図１の構成要素に付した番号と同じものは対応するものを示す。
【００２３】
図２の知識交流システムで具体的に実行される動作について説明する。まず図２（１）に示すように、エージェント１０３は、一定の周期（例えば、１０分程度の短い周期）でメーリングリストのメンバからメーリングリストのメールアドレスに送られてきたメールをチェックし、メールがあれば（１−１）〜（１−４）の処理を行う。
【００２４】
（１−１）では、送られてきたメールを、メール蓄積ＤＢ１０７の当該メールが回覧されるグループに対応するＤＢに蓄積する。このとき、当該メールのサブジェクトにより公開メールか非公開メールかを判断し、公開メールであるときは公開用ＤＢに蓄積し、非公開メールであるときは非公開ＤＢに蓄積する。次に、（１−２）で、送られてきたメールに類似する過去のメール（非公開のものは除く）や共有文書を検索する。（１−３）で、検索の結果得られた情報を、メールを送ってきたメンバに返信する。検索の結果得られた情報としては、例えば、当該メールに類似するメール一覧とそれぞれの要約、作成者情報、メール蓄積ＤＢにおけるメールの場所などの情報、あるいは類似する共有文書一覧とそれぞれの要約、作成者情報、共有文書蓄積ＤＢにおける文書のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）などの情報である。次に（１−４）で、送られてきたメールを当該メーリングリストのメンバに配信する。
【００２５】
さらに図２の（２）に示すように、エージェント１０３は、一定の周期（例えば、１日〜１週間程度の長い周期）で、メーリングリストのメンバから送られてきたメールの情報を、異なるメーリングリストにおいて過去に類似したメールを送信した者に配信する。この配信メールは１つのメールにまとめて、過去のメールに類似するメール一覧とそれぞれの要約、作成者情報、メール蓄積ＤＢにおけるメールの場所などの情報を配信するものである。なお、一定の周期で配信を行う代わりに、オペレータがエージェント１０３に指示を与えることにより上記の配信を実行するようにしてもよい。
【００２６】
さらに、全てのユーザは、全てのメーリングリストにおいて蓄積されたメールおよび共有文書を参照、検索、あるいは分析できる。また、自分が所属していないメーリングリストに対して意見メールを送信することができる。
【００２７】
図２のようなモデルケースでは、例えば以下のような効果が得られる。まず、営業部１０１−１の部員が営業部メーリングリストに営業報告書や顧客情報などを送信すると、通常のメーリングリストの機能により、営業部１０１−１の他の部員に配信される。このため、部員の活動内容や顧客についての知識を部内で共有できる。また、営業部メーリングリストにメールを送信した営業部１０１−１の部員には、その者が送ったメールに類似する過去のメール（公開されているもの）および文書が返信されるので、当該営業部１０１−１の部員は過去の関連情報を取得できる。
【００２８】
さらに、その営業部１０１−１の部員が送ったメールが、例えば開発部１０１−２の部員が過去に開発部メーリングリストに送信したメールと類似していた場合、その開発部１０１−２の部員にはその営業部１０１−１の部員が送ったメール情報が配信される。すなわち、開発部１０１−２の部員は、自分が過去に開発部メーリングリストに送信したメールに類似したメールの情報を受け取ることができる。このため、自分が開発している製品についての営業情報や企画情報を入手し、今後の設計開発に役立てることができる。
【００２９】
さらに、企画部１０１−Ｎの部員は、グループウェア１０６に蓄積された全メーリングリストを検索あるいは分析することができる。このため、企業の状況や市場の動向を把握して、新しい企画の作成に役立てることができる。
【００３０】
各部の部員は、自分が送信したメールに類似したメールの情報を取得できるので、自分が送信したメールに類似したメールを送信した社員が誰かを知ることにより、異なる部署の誰が自分に関連のある仕事をしているかを知ることができる。その社員に電話で問い合わせたり、直接会うことによって、部署間の知識交流が促進される。
【００３１】
図３は、メール情報ＤＢ１０４の仕様の例を示す。メール情報ＤＢ１０４は幾つかのテーブルを含むＤＢであり、図３（１）にユーザ情報テーブル、図３（２）にメーリングリスト情報テーブル、図３（３）にメーリングリストメンバ情報テーブル、図３（４）に配信メールキューテーブルを、それぞれ示す。
【００３２】
図３（１）のユーザ情報テーブルは、このシステムの全てのユーザを登録するテーブルである。ユーザ情報テーブルは、ユーザを一意に特定するＩＤであるユーザＩＤ、および当該ユーザのメールアドレスのフィールドを備える。ユーザ情報テーブルには、１人のユーザごとに、上述のフィールドの情報を持つ１レコードを登録しておく。
【００３３】
図３（２）のメーリングリスト情報テーブルは、メーリングリストに関する情報を登録するテーブルである。メーリングリスト情報テーブルは、メーリングリストを一意に特定するＩＤであるメーリングリストＩＤ、メーリングリストのメールアドレス、公開用メール蓄積ＤＢ名、非公開用メール蓄積ＤＢ名、およびメール公開ポリシーのフィールドを備える。公開用メール蓄積ＤＢ名および非公開用メール蓄積ＤＢ名は、図１，２に示したグループウェア１０６における、当該メーリングリストの公開用および非公開用のメール蓄積ＤＢの名前である。メール公開ポリシーは、当該メーリングリストに送られてきたメールの公開・非公開に関する取り扱い方を記述する欄である。ここでは、この欄が「０」のときはすべて非公開、「１」のときは原則として非公開でメールサブジェクトが”［ｐｕｂ］”を含むとき公開、「２」のときは原則として公開でメールサブジェクトが”［ｐｖｔ］”を含むとき非公開、「３」のときはすべて公開とする。メーリングリスト情報テーブルには、１つのメーリングリストごとに、上述のフィールドの情報を持つ１レコードを登録しておく。
【００３４】
図３（３）のメーリングリストメンバ情報テーブルは、各ユーザが参加しているメーリングリストに関する情報を格納するテーブルである。メーリングリストメンバ情報テーブルは、メーリングリストＩＤとユーザＩＤのフィールドを備える。あるユーザが、あるメーリングリストに参加しているとき、そのユーザＩＤとメーリングリストＩＤのペアを１レコードとして登録しておく。
【００３５】
図３（４）の配信メールキューテーブルは、図２のモデルケースの（２）で説明した類似したメールを過去に送信した者に配信する配信メールを格納するテーブルである。配信メールキューテーブルは、配信する情報を一意に特定するＩＤであるキューＩＤ、配信先のユーザのユーザＩＤである配信先ユーザＩＤ（ユーザ情報テーブルにおけるユーザＩＤ）、配信する情報に対応するメールの作成者のユーザＩＤであるメールユーザＩＤ（ユーザ情報テーブルにおけるユーザＩＤ）、配信する情報に対応するメールを一意に特定するＩＤであるメールＩＤ、配信する情報に対応するメールの表題であるメールサブジェクト、および配信する情報に対応するメールの本文の要約であるメール要約のフィールドを備える。配信するメールがあるとき、そのデータを配信メールキューテーブルに格納しておき、所定の時間間隔で配信メールキューテーブルに格納された配信メールを所定の配信先に送信する。
【００３６】
図４は、メール蓄積ＤＢ１０７の仕様の例を示す。図１および図２で説明したようにメール蓄積データベース１０７は、各グループごとの公開用および非公開用のＤＢからなる。各ＤＢは、図４（１）に示すメール情報テーブルを有する。メール情報テーブルは、メールを一意に特定するＩＤであるメールＩＤ、メールの作成者のユーザＩＤ（ユーザ情報テーブルにおけるユーザＩＤ）、メールの表題であるメールサブジェクト、およびメールの本文であるメール本文のフィールドを備える。１通のメールについて上述のフィールドの情報を持つ１レコードを登録する。
【００３７】
図５は、共有文書ＤＢ１０８の仕様の例を示す。共有文書ＤＢ１０８は、共有文書を格納するＤＢであり、図５（１）の文書情報テーブルを備える。文書情報テーブルは、文書を一意に特定するＩＤである文書ＩＤ、文書の作成者のユーザＩＤ（ユーザ情報テーブルにおけるユーザＩＤ）、文書の表題、および文書の本文のフィールドを備える。１つの共有文書について上述のフィールドの情報を持つ１レコードを登録する。
【００３８】
図６および図７は、エージェント１０３で行う処理のうち、メールの受信、蓄積、類似検索、検索結果返信、メーリングリストのメンバへの配信、および過去に類似メールを送信した者への配信情報をメール配信キューに追加する処理のフローチャートを示す。本処理は、例えば１０分程度の規定の時間間隔で起動される。
【００３９】
ステップ６０１で、メーリングリスト情報テーブル（図３（２））に、取得していないレコードがあるか、すなわちメーリングリスト情報テーブルに登録されている全てのメーリングリストについて処理を終えたか否か判別する。全てのメーリングリストについて処理が終わっていたら、本処理を終了する。処理していないメーリングリストがある場合は、ステップ６０２に進み、メーリングリスト情報テーブルからそのメーリングリストの情報を取得する。次に、ステップ６０３で、そのメーリングリストのメールアドレスに受信メールがあるか否か判別する。
【００４０】
ステップ６０３で受信メールがないときは、ステップ６０１に戻って次のメーリングリストの判別に進む。受信メールがあるときは、ステップ６０４でその受信メールから１通のメールを受信する。ここではそのメールを「メールＡ」と呼ぶものとする。ステップ６０５では、メールＡをメール蓄積ＤＢ１０７（図４）に保存する。保存の際には、メール公開ポリシーに従い、当該メーリングリストに対応する公開用または非公開用ＤＢに保存する。ステップ６０６で、検索エンジン１０５を呼び出し、メールＡの本文をキーとして類似文書（類似するメール情報および共通文書情報）を検索する。この検索を「検索Ａ」と呼ぶ。検索対象は、公開用メール蓄積ＤＢ１１１−１〜１１１−Ｎ、非公開用メール蓄積ＤＢ１１２−１〜１１２−Ｎ、および共有文書ＤＢ１０８とする。ステップ６０７で、検索の結果得られた文書一覧のうち、非公開用メール蓄積ＤＢ以外の文書の情報を、メールＡの送信者に返信する。
【００４１】
次にステップ６０８で、メーリングリストメンバ情報テーブルから、当該メーリングリストのメーリングリストＩＤを持つレコードを検索する。この検索を「検索Ｂ」と呼ぶ。ステップ７０１で、検索Ｂの結果に取得していないレコードがあるか否か、すなわち検索Ｂで得られた全てのレコードを処理したか否かを判別する。取得していないレコードがあるときは、ステップ７０２で、ユーザ情報テーブルから、検索の結果得られたユーザＩＤを持つレコードを検索し、そのメールアドレスを取得し、ステップ７０１に戻る。ステップ７０１で取得していないレコードがないとき（すなわち当該メーリングリストに参加している全てのユーザのメールアドレスが取得できたとき）は、ステップ７０３に進み、検索の結果得られた全てのメールアドレスに受信したメールを転送する。
【００４２】
次に、ステップ７０４で、メールＡが公開メールか否か判別する。公開メールでないときはステップ６０３に戻る。公開メールであるときは、ステップ７０５で検索Ａの結果に取得していないレコードがあるか否か、すなわちメールＡに類似する全ての文書について処理したか否か判別する。取得していないレコードがないときは、ステップ６０３に戻る。取得していないレコードがあるときは、ステップ７０６で、検索Ａの結果から１個の文書情報を取得する。次にステップ７０７で、取得した文書が、メール蓄積ＤＢの文書であり、メールＡと異なるメーリングリストに属するものであるか否か判別する。メールＡと異なるメーリングリストに属する文書であったときは、ステップ７０８で、メール配信キューテーブルに新しいレコードを作成し、そのレコードの配信先ユーザＩＤは取得した文書のユーザＩＤとし、メールユーザＩＤ、メールＩＤ、メールサブジェクト、およびメール要約はメールＡのそれぞれのデータを設定する。ステップ７０８の後、またはステップ７０７でメールＡと異なるメーリングリストに属しないときは、ステップ７０５に戻る。
【００４３】
図８は、エージェント１０３の処理のうち、過去に類似メールを送信した者への配信処理のフローチャートを示す。本処理は、例えば１日〜１週間程度の規定の時間間隔で起動される。
【００４４】
ステップ８０１で、配信メールキューテーブル（図３（４））に取得していないレコードがあるか否か、すなわち配信メールキューテーブル中の全てのレコードについて処理したか否か判別する。取得していないレコードがないときはそのまま処理を終了する。取得していないレコードがあるときは、ステップ８０２で、メール配信キューテーブルから１個のレコードを取得し（そのレコードをＡと呼ぶ）、該テーブルから削除する。次にステップ８０３で、配信メールキューテーブルに取得していないレコードがあるか否か判別する。あるときは、ステップ８０４で、メール配信キューテーブルから１個のレコードを取得する（そのレコードをＢと呼ぶ）。次にステップ８０５で、ステップ８０２で取得したレコードの配信先ユーザＩＤとステップ８０４で取得したレコードの配信先ユーザＩＤとが等しいか否か判別する。等しいときは、ステップ８０６でレコードＢを記憶し（前に記憶したデータに追加する形で記憶するものとし、記憶したレコード群をＢｎと呼ぶ）、ステップ８０７でメール配信キューテーブルからレコードＢを削除し、ステップ８０３に戻る。ステップ８０５で配信先ユーザＩＤが等しくないときは、ステップ８０３に戻る。
【００４５】
ステップ８０３で配信メールキューに取得していないレコードがないときは、ステップ８０８で、レコードＡと記憶してあるレコード群Ｂｎとを接続して、配信メールを作成する。ここでＢｎはクリアする。次にステップ８０９で、作成した配信メールを送信し（宛先は配信先ユーザＩＤ）、ステップ８０１に戻る。
【００４６】
次に、図９以降の図面を参照して、本実施形態の知識交流システムでの具体的な処理例を説明する。
【００４７】
図９は、図１および図２で説明した本実施形態の知識交流システムを具体化した例を示す。その構成自体は、図１および図２で説明したものと同様である。図１および図２で１００番台の番号を付けた部分と、図９で９００番台の番号を付けた部分とは、下２桁が同じものは対応する部分を示す。
【００４８】
図１０（１）〜（３）は、ユーザ情報テーブル、メーリングリスト情報テーブル、およびメーリングリストメンバ情報テーブルの初期値を示す。これにより、図９において、どのようなメーリングリストが設定され、各クライアントがどのメーリングリストに参加しているかなどが規定される。また、図１０（４）は、配信メールキューテーブルの初期値を示す。配信メールキューテーブルには、配信メールが無い状態とする。
【００４９】
図１０（５）および図１１（６）〜（１０）は、営業部、開発部、および企画部の公開用および非公開用メール蓄積ＤＢのメール情報テーブルの初期値を示す。図１１（１１）は、共有文書ＤＢにおける文書情報テーブルの初期値を示す。それぞれ、過去に送信されたメールや共有文書が蓄積されている（あるいは蓄積データが無いものもある）。
【００５０】
以上のような初期状態で、あるクライアントが公開メールを送信した具体例を説明する。営業部に属する鈴木クライアントが、営業部のメーリングリストに図１２に示すメールを送信したとする。このときの処理の流れを、図１７に示す。図１７の（１−１）が、図６のメール送信を示す。営業部のメーリングリストでは、メール公開ポリシーにより、受信メールはすべて公開メールとなる。したがって、図１７の（１−２）に示すように、当該受信メールは営業部の公開用メール蓄積ＤＢ９１１−１に保存される。図１３は、図１２のメールを＃３に格納した営業部公開用メール蓄積ＤＢの内容を示す。次に、エージェントは、図１７（１−３）に示すように、当該受信メールに類似した過去の公開メールと共有文書を検索し、検索結果を図１４のように返信メールとしてまとめて、当該メールの送信者である鈴木クライアントに返信する。次に、図１７（１−４）に示すように、当該受信メールを営業部の部員に配信する。図１５に、配信メールを示す。さらに、図１７（１−５）に示すように、他部署において過去に当該受信メールと類似したメールを送信した従業員に当該受信メールの情報を配信するため、配信メールキューテーブルに図１６の＃１〜＃４のレコードを作成する。これらのレコードの配信については後述する。
【００５１】
次に、あるクライアントが非公開メールを送信した具体例を説明する。開発部に属する林クライアントが、開発部のメーリングリストに図１８に示すメールを送信したとする。このときの処理の流れを、図２２に示す。図２２の（２−１）が、図１８のメール送信を示す。開発部のメーリングリストでは、メール公開ポリシーにより、受信メールは原則として公開メールだが、サブジェクトが［ｐｖｔ］を含む場合は非公開メールとする。したがって、図２２の（２−２）に示すように、当該受信メールは開発部の非公開用メール蓄積ＤＢ９１２−２に保存される。図１９は、図１８のメールを＃２に格納した開発部非公開用メール蓄積ＤＢの内容を示す。次に、エージェントは、図２２（２−３）に示すように、当該受信メールに類似した過去の公開メールと共有文書を検索し、検索結果を図２０のように返信メールとしてまとめて、当該メールの送信者である林クライアントに返信する。次に、図２２（２−４）に示すように、当該受信メールを開発部の部員に配信する。図２１に、配信メールを示す。当該受信メールは非公開メールであるため、他部署において過去に当該受信メールと類似したメールを送信した従業員に当該受信メールを配信することはない。
【００５２】
さらにその次に、あるクライアントが公開メールを送信した具体例を説明する。企画部に属する川本クライアントが、企画部のメーリングリストに図２３に示すメールを送信したとする。このときの処理の流れを、図２８に示す。図２８の（３−１）が、図２３のメール送信を示す。企画部のメーリングリストでは、メール公開ポリシーにより、受信メールは原則として非公開メールだが、サブジェクトが［ｐｕｂ］を含む場合は公開メールとする。したがって、図２８の（３−２）に示すように、当該受信メールは企画部の公開用メール蓄積ＤＢ９１１−３に保存される。図２４は、図２３のメールを＃２に格納した企画部公開用メール蓄積ＤＢの内容を示す。次に、エージェントは、図２８（３−３）に示すように、当該受信メールに類似した過去の公開メールと共有文書を検索し、検索結果を図２５のように返信メールとしてまとめて、当該メールの送信者である川本クライアントに返信する。次に、図２８（３−４）に示すように、当該受信メールを企画部の部員に配信する。図２６に、配信メールを示す。さらに、図２８（３−５）に示すように、他部署において過去に当該受信メールと類似したメールを送信した従業員に当該受信メールの情報を配信するため、配信メールキューテーブルに図２７の＃５のレコードを作成する。このレコードの配信については後述する。
【００５３】
次に、配信メールキューテーブルに溜まったメールの配信処理を説明する。上述したように、所定時間間隔で図８の処理が起動され、配信メールキューテーブルに溜まったメールの配信処理が実行される。図３３に、その配信処理の流れを示す。図２９〜図３２は、そのように配信されるメールの内容を示す。特に図３０のように返信先が同じレコードについては、１つのメールにまとめて返信される。
【００５４】
なお、上記実施の形態では、各グループごとに公開用ＤＢと非公開用ＤＢを設けた例を説明したが、これに限らず、アクセス権限の異なるメールをそれぞれ蓄積する２つ以上のＤＢを設け、受信メールをアクセス権限に基づいていずれかのＤＢに蓄積するようにしてもよい。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、ユーザは日常のメールによる知識交換によって自動的に知識をデータベース（知識共有システム）に登録できるので、ユーザからの知識共有システムへの知識登録を促進することができる。また、ユーザ自ら知識共有システムを見に行かなくても、ユーザが興味を持っていることに関連する知識が自動的に配信される。このため、不定期に更新される共有知識をタイムリーに手に入れ、有効活用を実現することができる。また、配信されるメールに対して返答メールを書くことにより、個人が経験により身につけた暗黙知が形式知化され、知識共有システム上で共有される。共有された形式知は、類似した問題に関わっている者に配信され、個人が直面している問題解決に活用されるので、個人の暗黙知として還元される。このような暗黙知→形式知、形式知→暗黙知の循環により、新しい知識の創造が促進されるという効果がある。
【００５６】
さらに、個人が持っている知識を共有し、検索・分析による有効活用を実現することができる。また、カテゴリ毎にメーリングリストを運営しても、ユーザが興味を持っていることに類似する知識が、異なるカテゴリのメーリングリストの間で交換されるので、異文化交流が促進される。類似するメールそのものでなく、メールについての情報を配信するので、必要なカテゴリの知識が多量な知識の中に埋もれてしまうことがない。
【００５７】
また、メールをデータベース（知識共有システム）に蓄積するので、知識共有システムの提供する類似検索機能等の高度な検索・分析機能を利用できる。メーリングリストのメンバ以外に見せてはならない知識は非公開データベースに蓄積し、メンバ以外に公開してもよい知識は公開データベースに蓄積することにより、知識の共有が促進されるとともにセキュリティが確保される。
【００５８】
質問メールを送信したユーザは、類似した質問を誰が過去に送信したかという情報をメールで受け取ることができる。ユーザは質問をするだけでなく、他のユーザが過去に行った質問の中で自分に関連する質問があるときは、これに対する回答メールを送信できる。既存の文書を蓄積するのではなく、ユーザがメールを書くことによって頭から引き出した知識を蓄積するので、知識の文書化を促進する。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る知識交流システムのシステム構成例を示す図
【図２】知識交流システムの実施形態の具体的なモデルケースの構成例および動作例を示す図
【図３】メール情報データベースの仕様の例を示す図
【図４】メール蓄積データベースの仕様の例を示す図
【図５】共有文書データベースの仕様の例を示す図
【図６】エージェントの処理フロー（その１）図
【図７】エージェントの処理フロー（その２）図
【図８】エージェントの処理フロー（その３）図
【図９】具体的な処理例での前提となるシステム構成図
【図１０】各データベースの初期値（その１）を示す図
【図１１】各データベースの初期値（その２）を示す図
【図１２】クライアントが送信した公開メールの例を示す図
【図１３】公開用メール蓄積データベースのメール情報テーブルの内容例を示す図
【図１４】エージェントからメール送信者へ返信されるメールの内容例を示す図
【図１５】エージェントからメーリングリストの各部員に配信されるメール例を示す図
【図１６】配信メールキューテーブルの内容例を示す図
【図１７】公開メールを受信した場合のメールの流れを示す図
【図１８】クライアントが送信した非公開メールの例を示す図
【図１９】非公開用メール蓄積データベースのメール情報テーブルの内容例を示す図
【図２０】エージェントからメール送信者へ返信されるメールの内容例を示す図
【図２１】エージェントからメーリングリストの各部員に配信されるメール例を示す図
【図２２】非公開メールを受信した場合のメールの流れを示す図
【図２３】クライアントが送信した公開メールの例を示す図
【図２４】公開用メール蓄積データベースのメール情報テーブルの内容例を示す図
【図２５】エージェントからメール送信者へ返信されるメールの内容例を示す図
【図２６】エージェントからメーリングリストの各部員に配信されるメール例を示す図
【図２７】配信メールキューテーブルの内容例を示す図
【図２８】公開メールを受信した場合（その２）のメールの流れを示す図
【図２９】エージェントから配信される返信メールの例（その１）を示す図
【図３０】エージェントから配信される返信メールの例（その２）を示す図
【図３１】エージェントから配信される返信メールの例（その３）を示す図
【図３２】エージェントから配信される返信メールの例（その４）を示す図
【図３３】配信メールキューに溜まったメールの配信処理のメールの流れを示す図
【符号の説明】
１０１−１〜Ｎ…メーリングリストのグループ、１０２…コンピュータネットワーク、１０３…エージェント、１０４…メール情報データベース、１０５…検索エンジン、１０６…グループウェア、１０７…メール蓄積データベース、１１１−１〜Ｎ…各グループの公開用メール蓄積データベース、１１２−１〜Ｎ…各グループの非公開用メール蓄積データベース、１０８…共有文書データベース。
【図１】
0003601783.tif 000002
【図２】
0003601783.tif 000003
【図３】
0003601783.tif 000004
【図４】
0003601783.tif 000005
【図５】
0003601783.tif 000006
【図６】
0003601783.tif 000007
【図７】
0003601783.tif 000008
【図８】
0003601783.tif 000009
【図９】
0003601783.tif 000010
【図１０】
0003601783.tif 000011
【図１１】
0003601783.tif 000012
【図１２】
0003601783.tif 000013
【図１３】
0003601783.tif 000014
【図１４】
0003601783.tif 000015
【図１５】
0003601783.tif 000016
【図１６】
0003601783.tif 000017
【図１７】
0003601783.tif 000018
【図１８】
0003601783.tif 000019
【図１９】
0003601783.tif 000020
【図２０】
0003601783.tif 000021
【図２１】
0003601783.tif 000022
【図２２】
0003601783.tif 000023
【図２３】
0003601783.tif 000024
【図２４】
0003601783.tif 000025
【図２５】
0003601783.tif 000026
【図２６】
0003601783.tif 000027
【図２７】
0003601783.tif 000028
【図２８】
0003601783.tif 000029
【図２９】
0003601783.tif 000030
【図３０】
0003601783.tif 000031
【図３１】
0003601783.tif 000032
【図３２】
0003601783.tif 000033
【図３３】
0003601783.tif 000034