JP2005244647A - コミュニティ形成装置 - Google Patents

Abstract

【課題】電子メールのやりとりにより潜在的に形成されているコミュニティを顕在化し、コミュニティに対しサービスを提供する。
【解決手段】メール監視部１５２は、ＬＡＮ１００を流れる電子メールのパケットを抽出し、その中から転送された電子メールを求め、その転送の情報を蓄積する。分析部１５４は、メール監視部１５２が蓄積したメール転送の情報から、電子メールの転送が高い頻度で行われているユーザ同士を結んだネットワークを求め、そのネットワークを１つのコミュニティと判定する。サービス登録部１５６は、求められたコミュニティ用の情報交換用のウェブページを作成してウェブサーバ１３０に登録し、該コミュニティに属する各ユーザに対しそのウェブページを知らせる電子メールを送信する。
【選択図】図１

Description

本発明は、ユーザ間でやりとりされる電子メールを監視することで、ユーザ達が潜在的に形成しているコミュニティを顕在化するための装置に関する。

情報通信技術の発展に伴い、インターネット等のデータ通信ネットワーク上の社会でも、一般社会と同様、目的や関心などを共にするユーザのコミュニティが様々に形成されている。ネット社会のコミュニティは、従来より、電子掲示板やメーリングリスト、あるいはオフラインでの口コミや紹介など、様々な方法に形成されている。

しかし、従来のコミュニティ形成は、電子掲示板やメーリングリストにメンバー登録したり、あるいは友人を誘ったり等、参加したい或いはさせたい人の積極的な働きかけを駆動力としたものであるため、コミュニティの形成や成長に時間や労力が係るという問題がある。

コミュニティ形成に関する技術ではないが、ネット上のユーザ同士の通信に関する解析を利用した装置として特許文献１に示される個人プロファイル管理装置がある。この装置では、通信される情報から個人の専門の領域や興味を知るための重要な単語をプロファイルとして抽出し、当該単語の出現割合の変化の傾向に基づいて、各個人の特徴を相対的に決定するというシステムの枠組みにおいて、人間の通信関係から構築されるネットワークにおいて、近傍から広域に至るまで段階的に単語情報を収集し、ネットワーク距離の違いにより評価を行っている。

また、同様に特許文献２には、インターネット上のユーザ間で、質問者に対する適切な回答者を見つけ出し、仲介する方法が開示されている。この方法では、回答者会員は、前記利用者コンピュータを通じて前記ＷＷＷサーバーにアクセスし、回答者会員は、応答可能な質問に関する属性情報、受信可能な応答手段（電子メール、チャット、電話など）、自らの知識提供の報酬対価を回答者データベースに登録し、質問者の質問に対してこの回答者データベースを検索することで適切な回答者を見つけている。

また、特許文献３には、 電子掲示板やメーリングリストなどの電子コミュニティから取得した特徴データ及びそれに基づいて生成した分析結果を特徴データベースに蓄積し、ウェブサーバがクライアント装置から受け付けた検索条件に合致する特徴データ（分析結果を含む）に関連するコミュニティの参照情報をクライアント装置に提供するコミュニティ検索システムが開示されている。

特開２０００−０７６３０４号公報 特開２００２−０４９７８６号公報 特開２００２−２６９１１１号公報

近年、電子メールはコミュニケーション手段として非常に重要な地位を占めるようになってきている。そして、電子メールのやりとりにより情報交換のためのコミュニティが形成されている場合も少なくない。しかしながら、電子メールのやりとりによるコミュニティは、電子メールの送信、転送、返信といった個々の操作から結果として構成されるもので、電子掲示板やメーリングリストの場合と異なり、コミュニティを構成する集団やコミュニティの場は明示的には存在していない。このように明示的には見えていないが潜在的には存在するコミュニティを目に見える形に顕在化できれば、コミュニティの形成や成長に非常に役立つものと期待できる。ところが、そのような観点の技術は従来ほとんど提案されてきていない。

例えば、特許文献１は各個人の特徴を分析するためのものであり、特許文献２は質問者に対して適切な回答者を提示するものであり、特許文献３は既存のコミュニティの中から検索条件に合うものを求めるものであって、いずれもコミュニティを形成したり、潜在的に形成されているコミュニティを顕在化するものではない。

本発明は、潜在的に形成されているコミュニティを顕在化させるための手段を提供する。

本発明は、コンピュータシステムを、ユーザ間をやりとりされる電子メールを監視して、ユーザから別のユーザへと転送又は返信される電子メールを検出するメール監視手段、前記メール監視手段が検出した転送又は返信の電子メールの情報に基づき、電子メールを転送する関係にあるユーザ群を１つのコミュニティと認識し、該コミュニティを構成するユーザ群の情報を含んだコミュニティ情報を作成するコミュニティ認識手段、として機能させるためのプログラムを提供する。

本発明の好適な態様では、前記コミュニティ認識手段は、転送又は返信された電子メールが各ユーザ間を通った回数をそれぞれ計数し、その計数値が所定の閾値以上となったユーザ間の連結範囲を１つのコミュニティと認識する。

ここで「ユーザ間」とは、２人のユーザの間の電子メール転送のパスのことである。

本発明の別の好適な態様では、前記コンピュータシステムを更に、前記メール監視手段で検出された転送又は返信の電子メールの情報に基づき、該転送又は返信の電子メールが由来する最初の電子メールの重要性指標値を求める重要性判定手段、として機能させると共に、前記コミュニティ認識手段は、求められた前記最初の電子メールの重要性指標値を該最初の電子メールの発信者ごとに集計することにより各ユーザの重要情報発信スコアを計算し、該重要情報発信スコアの値に基づき前記コミュニティに含まれるユーザの中から１以上のキーパーソンを特定し、該キーパーソンの情報を含んだ前記コミュニティ情報を作成する、ことを特徴とするプログラムを提供する。

更に別の好適な態様では、前記コンピュータシステムを、更に、前記コミュニティ認識手段が作成したコミュニティごとに、該コミュニティに属するユーザ間での情報交換のためのウェブページを自動生成するウェブページ自動生成手段、前記コミュニティ認識手段が作成したコミュニティのキーパーソンに対し、該コミュニティに属するユーザ間での情報交換のためのウェブページの管理を依頼するための通知を行う管理依頼手段、として機能させるプログラムを提供する。

以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」という）を説明する。

まず、図１を参照して、本発明に係るコミュニティ形成装置が設けられたネットワークシステムの概要を説明する。

図１において、ある組織（例えば企業）に設けられたＬＡＮ(Local Area Network)１００は、ファイアウォール１０５を介してインターネット２００に接続されている。ＬＡＮ１００上には、各ユーザが使用するパーソナルコンピュータ（ＰＣと略す）１１０や、それらＰＣ１１０等に対して各種の情報処理サービスを提供するサーバ１２０が接続されている。この例では、ＬＡＮ１００上のサーバの中には、ＬＡＮ１００やインターネット２００上のユーザにウェブページを提供するウェブサーバ１３０や、ＬＡＮ１００上のＰＣ１１０を使用するユーザに対して電子メールの送受信サービスを提供するメールサーバ１４０が存在する。

このＬＡＮ１００上に、本発明に係るコミュニティ形成装置１５０が設置される。大略的に言えば、このコミュニティ形成装置１５０は、ＬＡＮ１００上のＰＣ１１０を使用するユーザがＬＡＮ１００やインターネット２００上のユーザとやりとりする電子メールを監視し、電子メールの転送関係を分析することで、電子メールのやりとりにより潜在的に形成されているコミュニティを求める（コミュニティの顕在化）。このようなコミュニティ顕在化の処理を、以下では「コミュニティ形成」と呼ぶことにする。

コミュニティ形成装置１５０は、メール監視部１５２，分析部１５４及びサービス登録部１５６を備える。

メール監視部１５２は、ＬＡＮ１００上のユーザがやりとりする電子メールを監視し、それら電子メールからコミュニティ形成に用いる情報を抽出する機能モジュールである。

本実施形態でコミュニティ形成に用いる情報の代表的なものに、電子メールの転送関係の情報がある。この転送関係の情報を得るための１つの方法として、監視により得た電子メールのヘッダにおけるResentフィールドのデータを分析するという方法がある。電子メールクライアントソフトウエアによっては、受信した電子メールを転送する場合に、その転送するメールのヘッダ中にその転送元（すなわち当該転送者自信）のメールアドレスを示したResent-From:フィールドを組み込むものがある。また、転送先のアドレスをResent-To:フィールドやResent-Cc:フィールドとしてヘッダ中に組み込むものもある。RFC2822によれば、このようなResent関係のフィールド群を実装したメールクライアントは、受け取った電子メールを転送する場合、転送の電子メールを作成してそれを送信するわけであるが、元のメール（「受け取ったメール」）のヘッダの先頭に今回の転送（再送）を示すResent関係のフィールドを追加したものを、該転送のメールのヘッダとする。このため、同じ本文の電子メールが次から次へと転送された場合、その転送の経路の情報が当該電子メールのヘッダにはResent関係のフィールド群がその転送順序の逆順に上から並ぶことになる。したがって、メール監視部１５２は、監視により取得した電子メールのヘッダ中のResent関係のフィールド群を調べることで、その電子メールが経てきた転送の経路を求めることができる。

ただし、Resent関係のフィールドを実装したメールクライアントは少ない。そこで、別の方法として、電子メール中の引用箇所の記述を解析することで転送関係を求める方法がある。より具体的には、メール転送機能を有する一般的なメールクライアントは、受け取った電子メールに対する転送の電子メールを作成する場合に、転送の電子メールの本文に対し元の「受け取った電子メール」を添付する機能を備える。また、このとき、添付する「受け取った電子メール」の内容として、該電子メールの本文だけでなく、メールヘッダ乃至その一部（例えば発信者のアドレスや発信日時、宛先のアドレス、件名など）を含めるものも多い。また、このようなメールクライアントは一般に、添付した部分の先頭に「-----original message-----」等といった区切りの記述を入れたり、添付部分の各行の行頭に「>」などの引用記号を追加したり（両方を行う場合も多い）することで、添付部分を明示する機能を持っている。したがって、何回もの転送を受けた電子メールの本文のうちの添付部分には、転送順序の逆順に上から、各々の転送の際の発信元と宛先の情報が並ぶことになる。個々の転送の際の発信元や宛先の情報は、添付の区切りの記述の直後を探すことで見つけることができる。また、電子メール本文の添付部分のうち転送を何回も受けた部分の各行頭には、転送を受けた回数と同じだけの引用記号が並ぶので、引用記号の数を調べることで個々の転送に係る部分を弁別することができる。そして、その個々の転送に係る部分の先頭に、各々転送の際の発信元や宛先の情報を見つけることができる。このように、電子メール本文の添付部分の情報を解析することで、当該電子メールがたどってきた転送の経路を求めることができる。

なお、この手法では、電子メール本文から転送関係の情報を求めるのに、区切りの記述又は引用記号を見分けなければならない。ただし、区切りの記述や引用記号としてどのようなものを用いるかは、メールクライアントによって異なることもある。また、メールクライアントによっては、区切りの記述や引用記号の候補の中からユーザが好むものを選択させるものもある。したがって、このようなバリエーションに対応するためには、使用される可能性のある区切りの記述や引用記号の情報をメール監視部１５２に登録しておき、メール監視部１５２がその情報を参照しながら区切りや引用記号を判別するようにすればよい。

以上、メール監視部１５２が電子メール中から抽出する情報としてメール転送に関する情報を説明したが、この他にも、コミュニティ分析に利用する各種の情報を抽出することができる。例えば、該電子メールの件名(Subjectフィールド）や送信日時(Dateフィールド）、宛先(Toフィールド）、控えの送信先(Ccフィールド）などといったヘッダ内の情報や、当該電子メールの本文を抽出して利用することもできる。また、その電子メールの本文において、添付部分の先頭部分には、転送の系列において当該電子メールの１つ前の電子メールのヘッダが含まれるので、そのヘッダから送信日時の情報を得ることができる。このとき得られる送信日時と、当該電子メール自体の送信日時の差分から、当該電子メールの転送までに要した転送時間を求めることもできる（詳細は後述）。

電子メールのデータからどのような情報を抽出するかは、コミュニティ形成のために利用する具体的な方法によりけりであるが、ここでは一例として、図２に示すように、転送経路情報、件名、電子メールの本文、転送元送信日時、送信日時を抽出する場合を例示する。このうち、転送経路情報は、上述のようにResentフィールドやメール本文の添付部分の解析により求めることができる。この例では転送経路情報の内容を「Ａ→Ｂ→Ｃ→Ｄ」等と記述しているが、これは当該電子メールがユーザＡ，Ｂ，Ｃ，Ｄの順に転送されたものであることを示す便宜的な記述であり、実際には転送経路情報はそれら各ユーザＡ，Ｂ，Ｃ，Ｄの識別情報（例えば電子メールアドレス）を転送の順序に従って並べたリストである。この転送経路の最後のユーザが当該メールの宛先であり、その一つ前のユーザが当該メールの発信者である。転送元送信日時は、当該電子メールの本文の添付部分の先頭部分に示されている送信日時（すなわち転送系列に置いて当該電子メールの１つ前の電子メールの送信日時）である。この例では、メール監視部１５２は、ＬＡＮ１００上を流れる各電子メールのデータから、そのような各項目の情報を抽出し、図２に示すようなデータ構造のデータベースに登録する。このデータベースでは、各行がそれぞれ１つの電子メールから抽出したデータ項目からなる転送情報レコードである。各転送情報レコードは、当該電子メールを検出した時刻の順が分かるような形態で格納される（例えば図２の例では、データベースの先頭から古い順に並んでいる）。

従来より、ネットワーク上を流れる情報から電子メール（例えばＳＭＴＰパケットの形のデータ）をフィルタリングし、その中から電子メール監視に必要な情報を抽出するツールが存在する（例えば、http://www.hammock.jp/mailwatcher/に示されるMail Watcher（登録商標）など）。この種の電子メール監視ツールは、（１）ネットワーク上を流れる通信パケットからＳＭＴＰパケットだけをフィルタリングし、電子メールとして抽出する機能や、（２）抽出した各電子メールのうちユーザが指定した検索条件（例えばキーワード）に合致するもののみを抽出する機能、あるいは（３）抽出した電子メールから送信日時や宛名、控えの送信先(Cc:)、件名等といったヘッダの項目を抽出する機能、を備えている。本実施形態のメール監視部１５２は、このような既存の電子メール監視ツールの機能に、電子メールから転送関係の情報を抽出する機能を追加することで実現できる。

再び図１に戻り、コミュニティ形成装置１５０の分析部１５４は、メール監視部１５２の監視により作成されたデータベースに基づき、メールをやりとりによりユーザ間に潜在的に形成されているコミュニティを求める（コミュニティ形成）。このコミュニティ形成の処理手順の一例を、図３を参照して説明する。

図３の手順は、例えばコミュニティ形成を管理する管理者が明示的にコミュニティ形成処理の実行を指示した場合や、例えば１ヶ月ごとなどといった所定の条件によって定まるコミュニティ更新タイミングが到来した場合に、実行される。そして、その時点で形成されているデータベースの情報に基づき、コミュニティ形成を行う。

この手順では、データベース（図２参照）に未処理の転送情報レコードが残っているかどうかを検査し（Ｓ１０）、残っていれば、そのうちもっとも古い転送情報レコード（すなわち、該転送情報が由来する電子メールの検出日時がもっとも古いもの）を１つ取り出す（Ｓ１２）。

そして、取り出した転送情報中の転送経路情報を調べ、該転送経路にマッチ（適合）するツリーがあるかどうかを判定する（Ｓ１４）。ここでの「ツリー」とは、１つの電子メール（最初（オリジナル）の電子メール）の転送系列を特定するために用いるデータであり、その最初の電子メールが次々と、時には枝分かれして転送されていく経路がツリー構造のようになるので、このように名付けた。すなわち、各ユーザがノードとなり、ユーザ間を結ぶメールの転送関係がエッジとなるツリーである。作成した各ツリーは、図示しない作業用の記憶領域に格納する。最初の転送情報レコードを取り出した時点では、作業用記憶領域にはツリーは１つも格納されていないので、Ｓ１４の判定結果は否定（Ｎ）となり、分析部１５４はこの転送情報レコードの転送経路に対応するツリーを新たに作成し、作業用記憶領域に格納する（Ｓ１６）。例えば、ユーザＢがユーザＡから受け取ったメールをユーザＣに転送した場合、その転送のメールに対応する転送情報レコードを処理すると、図４に示すように「Ａ→Ｂ→Ｃ」のツリーができる。そして、Ｓ１０に戻って次の転送情報を処理する際には、作業用記憶領域にはツリーが存在するので、Ｓ１４でのマッチングが行われる。

このＳ１４において、転送経路にマッチするツリーとは、該ツリーにおけるルート（根。すなわち最初のメールの発信者）から他のいずれかのノードまでのパスが、その転送経路に含まれるようなツリーである。すなわち、このマッチング処理では、転送情報レコードから取り出した転送経路を、該経路の最初のユーザから順に、作業用記憶領域に格納されている各ツリーのルートから下っていくパスと比較していき、もっとも深いところまで一致するツリーを、マッチするツリーとして求める。もっとも、異なる電子メールが同じ転送経路を通ることも多いので、これらを弁別するには、単なる経路のマッチングではなく、メール本文のマッチングを用いればよい。メール本文のマッチングは、もっとも簡便には、メール本文中に含まれる「転送系列の最初のメール」の比較により行うことができる。このためには、各ツリーのルートに、当該ツリーの「最初の電子メール」のデータをリンクしておく。そして、それらツリーの中から、転送情報レコードから取り出した転送経路の最初のユーザをルートに持つツリーを抽出し、抽出した各ツリーのルートにリンクされた「最初の電子メール」を調べ、転送情報レコードに含まれるメール本文中の「最初の電子メール」の部分と一致するツリーを特定すればよい。なお、メール本文中の「最初の電子メール」の部分は、転送経路の情報を求めるための電子メールの解析の際に特定できるので、これを転送情報レコードに登録しておくことも好適である。一般に、ヘッダと本文を含む内容全体が同じ電子メールが独立に作成されることは稀なので、「最初の電子メール」を調べることで目的のツリーを特定できる。ただし「最初の電子メール」だけでは特定できない場合を考慮するなら、ツリーの各ノードに、そのノードに対応する電子メール（すなわち、当該ツリーに対応する転送の経路上でそのノードのユーザが送信した電子メール）を対応づけて記憶しておき、ルートから順に転送経路にマッチするノードをたどっていく際、そのノードに対応づけられた電子メールを転送情報レコード中のメール本文と比較すればよい。

このようにして転送情報レコードの転送経路にマッチするツリーが特定されると、その転送経路をツリーに反映させる（Ｓ１８）。すなわち、Ｓ１６で特定したツリーの中の、転送経路とマッチしたパスの末端のノードに対し、その転送経路とそのパスの差分をマージする。例えば、図４の例において、作業用記憶領域内に「Ａ→Ｂ→Ｃ」のツリーが格納されているときに、「Ａ→Ｂ→Ｃ→Ｄ」の転送経路を持つ転送情報レコードを取得した場合は、後者から前者を引いた差分の「Ｃ→Ｄ」の経路をそのツリーに付け加える。

以上のような処理を、データベース中のすべての転送情報レコードについて繰り返し実行する（Ｓ１０）。最後の転送情報レコードが処理し終わった時には、作業用記憶領域には、１以上のツリーが格納されている。図５に、ユーザＡが発信したメールを起点とする転送のツリーを例示する。個々の「最初の電子メール」に対応して、このようなツリーが形成されるのである。

図３の手順では、これら各ツリーを、それぞれ１つのコミュニティと認識する（Ｓ２０）。これは、１つの電子メールの転送を受けたユーザ群（及びその１つの電子メールの発信者）を１つのコミュニティとみなすものである。ユーザは、自分が受け取った電子メールを他のユーザに知らせる必要があると考えた場合に転送を行うので、このように１つの電子メールの転送先からなる集団は、１つの情報（最初の電子メール）に対し何らかの興味を持っている人々の集団とみなすことができる。したがって、この集団をコミュニティとするのである。

以上、コミュニティ形成処理の一例を示したが、この処理では、「最初の電子メール」１つずつにつき１つのコミュニティを作成するので、余り意味のないコミュニティができたり、コミュニティの数が膨大なものになってかえって不便になったりすることも考えられる。そこで、次に、複数の電子メールの転送関係をマージしてコミュニティを形成する処理の例を説明する。この処理の手順を図６に示す。図６では、図３の手順と同様の処理を行うステップには、同一符号を付して説明を省略する。

この手順では、メール監視部１５２が作成したデータベースのすべての転送情報レコードを処理してツリー群を作成するところまで（Ｓ１０〜Ｓ１８）は、図３の手順と同じである。図３の手順ではこの後個々のツリーをそれぞれコミュニティとしたが、図６の手順では、それら各ツリーにおけるユーザ間のメール転送回数を集計する（Ｓ２２）。すなわち、例えば、Ｓ１０〜Ｓ１８の処理により図４のツリーと図５のツリーが別々に作業用記憶領域上に形成された場合、ユーザＡ−Ｂ間のパス及びＢ−Ｃ間のパスはそれぞれ２回、Ａ−Ｅ間やＡ−Ｆ間、Ｃ−Ｄ間、Ｃ−Ｇ間のパスはそれぞれ１回、電子メールが転送されたことが分かる。このようにユーザ間ごとに、そのユーザ間を含んだツリーが幾つあるかを集計するのである。集計データは、例えば図７に示すように、ユーザ２人のペア（ユーザ間パス）ごとに、両者間での転送の回数に応じたポイントを記録したものとなる。

この集計が終わると、集計データ中でポイントが所定の閾値以上となるユーザ間のパスを抽出し、抽出したパスの連結範囲（連結成分）を求める（Ｓ２４）。所定の閾値以上となるユーザ間パスを抽出するのは、突発的な転送関係を排除して、ある程度恒常的にメールの転送を行っているペアだけを抽出するためである。そして、抽出されたパス群の中で一方のユーザが一致するものを順にマージしていく処理を、これ以上マージするものがなくなるまで繰り返すことで、１つの連結成分が求められる。連結成分が求められた後、まだ集計データ中に閾値以上のポイントを持つユーザ間パスが存在すれば、同様の処理を繰り返して別の連結成分を求める。これを集計データ中から、閾値以上のポイントを持つ未処理のパスがなくなるまで繰り返す。これにより、いくつかの連結成分が形成されることになる。例えば図８には、３つ連結成分が形成された例を示す。

そして、分析部１５４は、それら求めた各連結成分を、それぞれ１つのコミュニティと認識する（Ｓ２６）。すなわち、１つの連結成分に属するユーザ群を１つのコミュニティとするのである。これにより、ある一定回数以上メールを転送しあった関係のユーザ間を結んだ関係を１つのコミュニティとすることができる。なお、このように求めた連結成分のうち、３ノードのみからなるものは、コミュニティと呼ぶには小さい、孤立的な転送関係と考えることもできるので、このようなものはコミュニティには選ばないようにすることもできる。

以上のような処理により、それぞれが複数のユーザを含んだコミュニティがいくつか形成されることになる。形成されたコミュニティは、当該コミュニティを構成するユーザの集合（例えばそれら各ユーザの電子メールアドレスのリスト）で表現することができる。

このように形成されたコミュニティの情報は、それ自体だけでも、ユーザ間の関係の分析等に有益なものであるが、本実施形態は、更にこのコミュニティの情報を、当該コミュニティを更に成長させるために役立てる仕組みを備えている。それが、図１に示したサービス登録部１５６である。

サービス登録部１５６は、形成されたコミュニティに対するサービスを、対応するサーバに対して登録する処理を行う。コミュニティに対応するサービスの一つに、コミュニティのメンバが情報交換を行うためのウェブページの提供がある。この場合のサービス登録部１５６の処理手順を図９に示す。

この手順では、サービス登録部１５６は、分析部１５４が作成したコミュニティ群のなかから１つのコミュニティを取得し（Ｓ３０）、そのコミュニティ用のウェブページ群をウェブサーバ１３０上に作成し、公開可能な状態とする（Ｓ３２）。このウェブページ群は、例えばコミュニティのメンバ間の情報交換のための電子掲示板を含めることができる。また、このウェブページ群には、コミュニティ形成の基礎データとなった電子メール群にて交わされた議論の内容を示したページを加えることもできる。このようなページとしては、例えば、該コミュニティの基礎となった転送関係のツリーに属する各電子メールを、スレッド形式に編集して配列したものを用いることができる。

このように作成するウェブページは、定型的なものなので、コミュニティ形成装置１５０内に登録されているウェブページのテンプレートデータ等に基づきサービス登録部１５６が自動生成することができる。そして、サービス登録部１５６は、このウェブページの開設を知らせる通知を、当該コミュニティの各メンバに対して、例えば電子メールで送信する（Ｓ３４）。

本実施形態では、電子メールのやりとりに基づきコミュニティを形成しているので、コミュニティのメンバの電子メールアドレスは既知である。通知の電子メールに、当該コミュニティ用のウェブページ群のトップページ等のＵＲＬを記述しておけば、これを受け取った人は、これを用いてアクセスできる。また、このコミュニティ用のウェブページ群の公開を、コミュニティのメンバのみに制限するべくアクセス制限を掛けることも可能である。これには例えば次のような仕組みを用いることができる。すなわち、ウェブサーバ１３０に対し、各ユーザの認証情報（パスワードなど）や電子メールアドレスを登録しておくとともに、サービス登録部１５６から各コミュニティの構成メンバの情報（例えば各メンバのメールアドレスのリスト）を登録しておく。そして、ウェブサーバ１３０は、ユーザがコミュニティのトップページにログインした際に、メールアドレス及び認証情報の入力を求め、これに応じ入力されたメールアドレスに基づきそのユーザが当該コミュニティに所属するかどうかを判定し、所属すると判定された場合は、更に入力された認証情報が正しいものかどうかを検証し、正しいものであった場合にログインを認める。

サービス登録部１５６は、このようなコミュニティ用ウェブページの開設及びその通知を、すべてのコミュニティについて繰り返す（Ｓ３６）。

また、形成したコミュニティに関して提供するサービスの別の例として、メーリングリスト拡張サービスがある。これは、メーリングリストサービスを行っているサーバがネットワーク上に存在しているという状況の下で、そのサーバに登録されているメーリングリストを、コミュニティの情報により拡張するものである。この例では、図１におけるメールサーバ１４０にメーリングリストの情報が登録されているものとする。

この場合のサービス登録部１５６の処理手順は図１０に示すようなものとなる。この手順では、サービス登録部１５６は、分析部１５４が形成したコミュニティ群の中から１つのコミュニティを取り出し（Ｓ４０）、そのコミュニティに属するユーザの集合を、メールサーバ１４０に登録された各メーリングリストのメンバの集合と比較し、そのコミュニティに包含されるメーリングリスト（すなわち、そのメーリングリストのメンバは、すべてそのコミュニティに属する）を探し（Ｓ４２）、そのようなメーリングリストが見つかれば、コミュニティに属するユーザ群をメンバとした拡張版のメーリングリストを作成し、メールサーバ１４０に登録する（Ｓ４４）。例えば、図１１に示すように、｛Ａ，Ｂ，Ｄ，Ｅ，Ｆ，Ｉ｝の６人のユーザが登録された「開発グループリスト」という名称のメーリングリスト２００がメールサーバ１４０に登録されている場合に、分析部１５４により｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｉ，Ｊ，Ｋ，Ｌ｝の１１人からなるコミュニティが形成された場合を考える。このコミュニティは「開発グループリスト」を包含しているので、サービス登録部１５６は、「開発グループリスト」とユーザ｛Ｃ，Ｇ，Ｊ，Ｋ，Ｌ｝とをメンバとした拡張メーリングリスト２１０を作成してサーバ１４０に登録する。この場合、拡張メーリングリスト２１０の名称は、元のメーリングリストとの関係が明確に分かるよう、元のメーリングリストの名称に対して「＋」という文字を付加したり、「拡張版」という文字列を付加するなどの方法で自動生成すればよい。また、このようにコミュニティに対応する拡張メーリングリストを登録した場合、サービス登録部１５６は、コミュニティのメンバに対してその拡張メーリングリストの宛先を知らせる電子メールを送信するようにすることもできる。

サービス登録部１５６は、このようなメーリングリスト拡張のための処理を、すべてのコミュニティについて繰り返す（Ｓ４６）。

このようなメーリングリスト拡張サービスによれば、メーリングリストを用いたコミュニケーションの広がりに追従して動的にメーリングリストを拡張していくことができる。また、あるユーザがメーリングリスト宛にメールを発信した後、そのメールの内容に修正の必要が生じた場合、そのメーリングリストの拡張メーリングリストに対して修正内容を示したメールを送信すれば、元のメールを受け取った人全員に修正内容を伝えることができる。

以上、本発明の好適な実施の形態について説明した。本実施形態によれば、メールの転送関係により潜在的に形成されている情報共有・交換の場（コミュニティ）を自動検出することができ、求めたコミュニティの情報を用い、そのコミュニティのために各種サービスを提供することができる。特に電子メールの「転送」の情報を基礎にすることで、２者の一方から他方への単発的な情報の送信の関係を基礎とするよりも、もっと情報共有の意味合いが強いコミュニティを形成することができる。

また、本実施形態によれば、今まで電子メールを直接やりとりする仲ではなかった人同士が、電子メールの転送関係という連鎖的な関係により１つのコミュニティにまとめられるので、コミュニティの各メンバは、コミュニティ用ウェブページを利用することにより、直接の知り合い関係の間の議論では得られなかった新しい知識や情報を得ることができる。これは創造性を高めるための一助となるものと期待できる。

このように、本実施形態のコミュニティ形成装置１５０の利用形態としては、例えば、この装置１５０を企業や企業グループ等の社内ネットワークに設け、社内での電子メールのやりとりに基づきコミュニティを形成し、これに基づく各種サービスを提供するという形態がある。この場合、コミュニティ形成装置１５０は、企業内の情報交換や人材交流を活発にする一種の企業活性化ツールとして利用することができる。

なお、以上では電子メールの「転送」に着目したが、電子メールの「返信」が行われた場合も、「転送」の場合と同様、単発的なメール送信の場合よりも強い情報共有の関係があるものと考えることができる。そこで、メール監視により、転送の電子メールと同様に返信の電子メールも抽出し、ユーザ間の返信のパスも転送のパスと同様に扱うことで、上述と同様のツリー（この場合は厳密にはツリーではなく、更に一般的な「グラフ」になるが、便宜上こう呼ぶ）を作成することができる。ツリーが作成できれば、上述の手法でコミュニティを形成できる。また、図６の処理手順において、更に返信のメールも考慮する場合は、Ｓ２２において、返信のメール１つにつきその返信のパスに所定のポイントを加算することで、返信パスの関係を強調することもできる。なお、返信のメールかどうかは、ヘッダ中のIn-Reply-Toフィールドにより判別できる。

以上では、ユーザ間でやりとりされる電子メールすべてを対象に分析をしてコミュニティを求めたが、この他にも、例えば特定の条件に合致する電子メール群からコミュニティを形成する構成とすることもできる。例えば、メール監視部１５２によりあるテーマについて語っている電子メール群を抽出し、それら電子メール群における転送（或いは返信）の情報からコミュニティを形成すれば、そのテーマに関係している可能性が高いコミュニティを求めることができる。これには、例えば、テーマに関するキーワードをメール監視部１５２に入力し、メール監視部１５２がそのキーワードを含むメールのみに絞り込んで抽出するようにすればよい。すなわち、メール監視部１５２は、指定されたキーワードを含み、かつ転送（乃至返信）された電子メールを抽出し、その情報をデータベースに登録するのである。その後の分析部１５４等の処理は、上記の例と同様でよい。キーワードは、件名や本文など、電子メールの構成要素単位で設定することもできる。このようなキーワードによるメールフィルタリング機能は、既存の電子メール管理ツールと同様のものを用いれば実現できる。

このような構成によれば、「コピー機」をキーワードに指定して図６のコミュニティ形成処理を行えば、「コピー機」に関する話題を取り上げているユーザのコミュニティを求めることができる。また、このように求めた「コピー機」に関連するコミュニティにつき、例えば分析者が分析を進め、そのコミュニティのあるユーザに届いた電子メール（コミュニティ形成の基礎データとなった電子メールの一つである）を見た場合、元々の電子メールの他に「楽曲コピー」について触れた電子メールが添付されていたことを発見したとする。この話題は、元々の電子メールには含まれていなかった話題であり、電子メールを用いた議論の内容が広がっていることを意味する。そこで、『「コピー機」＆「楽曲コピー」』の２つのキーワードのＡＮＤ条件を検索条件に設定して電子メールのフィルタリングを行い、これにより抽出された電子メール群からコミュニティを形成すれば、このような広がった話題を議論しているコミュニティを求めることができる。このような検索条件による絞込は、メール監視部１５２により作成したデータベースのメール本文や件名（図２参照）などの各種の項目について行うことができる。

以上ではキーワードを用いる場合を例示したが、キーワード以外の検索条件で電子メールの絞込を行う場合も同様のことができる。

また以上では、コミュニティ形成や形成したコミュニティの情報を用いたサービスの例を説明したが、次にそのようなコミュニティを管理、成長させるためのキーパーソン（鍵となる重要人物）を自動判別する機能を備えた変形例について説明する。

この変形例は、メール監視部１５２の処理については、上述の実施形態と同様でよい。分析部１５４の処理手順の例を図１２に示す。この手順のうち、図６に示した処理手順と同様のステップには同じ符号を付して説明を省略する。

この手順で特徴的なのは、Ｓ１６又はＳ１８の後にＳ５０及びＳ５２、Ｓ２６の後にＳ５４の各ステップを設けたことである。Ｓ５０では、Ｓ１２で取得した転送情報の「送信時刻」から「転送元送信時刻」（共に図２参照）を引くことで、当該転送情報に対応する転送の電子メールを発したユーザがその転送に要した時間（転送時間と呼ぶ）を計算する。この変形例では、転送時間が短いほどその電子メールの重要性が高いと考え、その電子メールの大本となった最初の電子メールに重要な情報が示されているものと判断する。そして、重要な情報を発信する人ほど、コミュニティを引っ張っていくのにふさわしいと考えられるので、ここでは、転送時間の短さに応じたポイントを、当該転送メールの元になった最初のメールの発信者のポイントに加算することとした（Ｓ５２）。例えば転送時間が３０分以内ならポイント「１」、３０分を超える場合は「０」というような、転送時間からポイントを求める規則やテーブルを作成し、分析部１５４に登録しておけばよい。また、分析部１５４は、図１３に示すように、ユーザごとのポイントを集計するテーブルを用意し、そこに監視した各電子メールから求められるポイントを集計していく。このようにしてデータベースのすべての情報についてＳ１０〜Ｓ５２の処理が終わると、図６の手順と同様にしてコミュニティを形成し（Ｓ２２〜２６）、更にユーザごとのポイント集計テーブルを参照して、各コミュニティのキーパーソンを判定する（Ｓ５４）。このキーパーソン判定では、コミュニティの各メンバのポイントを集計テーブルから求め、ポイントが上位の所定人数（この所定人数は、分析部１５４に予め登録しておく）の人をキーパーソンと判定する。このように求めたキーパーソンの情報は、例えば、コミュニティのメンバーに対して電子メール等で通知することもできる。また、キーパーソンをコミュニティ用のウェブページやその中の電子掲示板等の運営を管理する管理人に指名することで、ウェブページ運営によりコミュニティの更なる発展を目論むことができる。この場合、図９の手順で、コミュニティ用ウェブページの開設通知を行う際に、キーパーソンに対しては、管理人に指名した旨を示すメッセージも併せて通知し、ウェブサーバ１３０に対しては、そのキーパーソンに当該ウェブページの管理者権限が与えるための権限設定を行う。

この例では、コミュニティのキーパーソンを求めるための指標として、電子メールの転送時間を用いたが、これは一例に過ぎない。例えば、多くの人に対して転送されたメールは、重要なメールであると考えることができるので、ユーザごとに、その人が最初に発した電子メールが何人に転送されたかを集計し、その人数によりユーザの重要性（キーパーソン適格性）を判定してキーパーソンを決定してもよい。また、よく情報を発信するユーザほど、コミュニティの中での重要性が高いという見方ができるので、電子メールの発信回数（転送や返信のメールは除く）を集計し、それによりユーザの重要性を判断してキーパーソンを決定することもできる。もちろん、それら転送時間、転送頻度（転送人数）、発信回数などといった各種指標を総合評価した上で、キーパーソンを決定する処理を採用することもできる。

また、以上の例では、メール監視部１５２が、ネットワーク上を流れる電子メールを監視して、図２のようなデータベースを作成し、このデータベースを元に分析部１５４がコミュニティを形成したが、このようなシステム構成は一例に過ぎない。例えば別の例として次のようなものが考えられる。

この例では、メール監視部１５２は、監視により得た電子メールから図２のようなデータベースを作成する代わりに、図７に例示したような集計テーブルを直接作成する。すなわち、メール監視部１５２は、図１４に示すように、ネットワーク上を流れる電子メールを検出すると（Ｓ６０）、その電子メールが転送（又は返信）されたものか否かを判定する（Ｓ６２）。この判定で、転送（又は返信）された電子メールと判定された場合、更にそれが一度目の転送であるかを判定する（Ｓ６４）。一度目の転送であれば、当該転送のメールの元となった最初のメールの発信者とその宛先（すなわち当該転送のメール送信者）との間のユーザ間パスにポイントを加算し（Ｓ６６）、更に当該転送のメールの送信者とその宛先との間のユーザ間パスに対しポイントを加算する（Ｓ６８）。また、Ｓ６４で、一度目の転送ではないと判定された場合、当該転送のメールの送信者とその宛先との間のユーザ間パスに対しポイントを加算する（Ｓ６８）。このような電子メールを検出するたびにこのような処理を繰り返すことで、図６の手順のＳ２２で作成されるのと同様の集計テーブルを作成することができる。

分析部１５４は、コミュニティ形成を実行する場合、図１５に示すようにこの集計テーブルを取得し（Ｓ７０）、以降、図６の手順と同様、所定閾値以上のポイントを持つユーザ間パスの連結範囲を求め（Ｓ７２）、求めた各連結範囲をそれぞれコミュニティとする（Ｓ７４）。

以上に説明したコミュニティ形成装置１５０は、典型的には、コンピュータシステムに対し上記各機能モジュールの処理を記述したプログラムを実行させることにより実現される。

本発明に係るコミュニティ形成装置が設けられたネットワークシステムの概略構成を示す図である。 メール監視部が作成するデータベースのデータ内容の一例を示す図である。 コミュニティ形成処理の手順の一例を示すフローチャートである。 ツリーの一例を示す図である。 ツリーの別の一例を示す図である。 コミュニティ形成処理の手順の別の例を示すフローチャートである。 ユーザ間パスごとの転送回数のポイント集計結果のデータの一例を示す図である。 図６の処理のより形成された３つのコミュニティを例示する図である。 サービス登録部の処理の一例を示すフローチャートである。 サービス登録部の処理の別の一例を示すフローチャートである。 メーリングリスト拡張を説明するための図である。 変形例における分析部の処理手順の例を示すフローチャートである。 各ユーザのキーパーソン適格性のポイントの集計テーブルの例を示す図である。 メール監視部の別の処理手順の例を示すフローチャートである。 分析部の別の処理手順の例を示すフローチャートである。

符号の説明

１００ ＬＡＮ、１１０ パーソナルコンピュータ、１２０ サーバ、１３０ ウェブサーバ、１４０ メールサーバ、１５０ コミュニティ形成装置、１５２ メール監視部、１５４ 分析部、１５６ サービス登録部。

Claims (10)

1. コンピュータシステムを、
   ユーザ間をやりとりされる電子メールを監視して、ユーザから別のユーザへと転送又は返信される電子メールを検出するメール監視手段、
   前記メール監視手段が検出した転送又は返信の電子メールの情報に基づき、電子メールを転送する関係にあるユーザ群を１つのコミュニティと認識し、該コミュニティを構成するユーザ群の情報を含んだコミュニティ情報を作成するコミュニティ認識手段、
   として機能させるためのプログラム。
2. 前記コミュニティ認識手段は、転送又は返信された電子メールが各ユーザ間を通った回数をそれぞれ計数し、その計数値が所定の閾値以上となったユーザ間の連結範囲を１つのコミュニティと認識することを特徴とする請求項１記載のプログラム。
3. 前記コンピュータシステムを更に、前記メール監視手段で検出された転送又は返信の電子メールの情報に基づき、該転送又は返信の電子メールが由来する最初の電子メールの重要性指標値を求める重要性判定手段、として機能させると共に、
   前記コミュニティ認識手段は、求められた前記最初の電子メールの重要性指標値を該最初の電子メールの発信者ごとに集計することにより各ユーザの重要情報発信スコアを計算し、該重要情報発信スコアの値に基づき前記コミュニティに含まれるユーザの中から１以上のキーパーソンを特定し、該キーパーソンの情報を含んだ前記コミュニティ情報を作成する、
   ことを特徴とする請求項１又は２に記載のプログラム。
4. 前記重要性判定手段は、前記転送又は返信の電子メールが転送されるのに要した時間に基づき、該電子メールに対応する前記最初の電子メールの前記重要性指標値を求めることを特徴とする請求項３記載のプログラム。
5. 前記コンピュータシステムを、更に、
   前記コミュニティ認識手段が作成したコミュニティごとに、該コミュニティに属するユーザ間での情報交換のためのウェブページを自動生成するウェブページ自動生成手段、
   前記コミュニティ認識手段が作成したコミュニティのキーパーソンに対し、該コミュニティに属するユーザ間での情報交換のためのウェブページの管理を依頼するための通知を行う管理依頼手段、
   として機能させる請求項３記載のプログラム。
6. 前記コンピュータシステムを、更に、前記コミュニティ認識手段が作成したコミュニティごとに、該コミュニティに属するユーザ間での情報交換のためのウェブページを自動生成するウェブページ自動生成手段、として機能させる請求項１記載のプログラム。
7. 前記コンピュータシステムを、更に、
   メーリングリストサーバに登録されている各メーリングリストのメンバ情報を取得するメーリングリスト情報取得手段、
   前記コミュニティ認識手段が作成したコミュニティと各メーリングリストのメンバ情報とを比較し、この比較により該コミュニティがいずれかのメーリングリストのメンバをすべて含むことが判明した場合、該コミュニティに含まれるユーザ群をメンバとした拡張メーリングリストを作成して前記メーリングリストサーバに登録するメーリングリスト拡張手段、
   として機能させる請求項１記載のプログラム。
8. 前記コンピュータシステムを、更に、検索条件を取得し、ユーザ間をやりとりされる電子メール群の中から該検索条件を満足する電子メール群を抽出するメール抽出手段、として機能させると共に、
   前記コミュニティ認識手段は、前記メール抽出手段で抽出された電子メール群を対象範囲として前記コミュニティの認識を行う、ことを特徴とする請求項１記載のプログラム。
9. ユーザ間をやりとりされる電子メールを監視して、ユーザから別のユーザへと転送又は返信される電子メールを検出するメール監視手段と、
   前記メール監視手段が検出した転送又は返信の電子メールの情報に基づき、電子メールを転送する関係にあるユーザ群を１つのコミュニティと認識し、該コミュニティを構成するユーザ群の情報を含んだコミュニティ情報を作成するコミュニティ認識手段と、
   を備えるコミュニティ形成装置。
10. コンピュータシステムにより実行されるコミュニティ形成方法であって、
    該コンピュータシステムが、ユーザ間をやりとりされる電子メールを監視して、ユーザから別のユーザへと転送又は返信される電子メールを検出する監視ステップと、
    該コンピュータシステムが、前記監視ステップで検出した転送又は返信の電子メールの情報に基づき、電子メールを転送する関係にあるユーザ群を１つのコミュニティと認識し、該コミュニティを構成するユーザ群の情報を含んだコミュニティ情報を作成するコミュニティ形成ステップと、
    を含むコミュニティ形成方法。

Images