(57)【要約】【課題】ユーザが特別な操作をすることなく、コミュニティ内でのユーザの役割に応じた記事を取得することにより、ユーザに対してより有用な情報を提示可能とする。【解決手段】ＫＬ情報ＤＢ９は、記事ＤＢ８に格納されている記事相互間の関係と関係の種類を表すＫＬレコードを格納する。ユーザ役割導出部１１は、ＫＬレコードに基づいてコミュニティ内の各ユーザの役割を導出する。ユーザ役割情報ＤＢ１２は、ユーザ役割導出部１１によって導出されたユーザの役割を示す情報を当該ユーザに対応付けて格納する。情報検索部１４は、ユーザからの記事検索または記事参照の要求に応じて当該要求に合致する記事を記事ＤＢ８から取得する。情報検索部１４は、取得された記事を要求元のユーザに提示する際の優先度を、前記要求に合致する度合い及び当該要求元のユーザに対応付けてユーザ役割情報ＤＢ１２に格納されている情報の示す役割に基づいて決定する。【選択図】      図２
2010108519.tif 000002
【特許請求の範囲】
【請求項１】
コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段を有するコミュニケーションシステムにおいて、
前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段と、
前記ナレッジリンク情報の示す関係の種類に基づいて、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するユーザ役割導出手段と、
前記ユーザ役割導出手段によって導出されたユーザの役割を示す情報を当該ユーザに対応付けて格納するユーザ役割格納手段と、
ユーザからの記事検索または記事参照の要求に応じ、当該要求に合致する記事を当該要求に合致する度合いに基づいて前記記事格納手段から取得する記事取得手段と、
前記記事取得手段によって取得された記事毎の前記要求に合致する度合いを、要求元のユーザに対応付けて前記ユーザ役割格納手段に格納されている情報の示す役割に基づいて変更する変更手段と、
前記記事取得手段によって取得された記事を前記要求元のユーザに提示する際の当該記事毎の優先度を、前記変更手段によって変更された記事毎の前記要求に合致する度合いに基づいて決定する優先度決定手段と
を具備することを特徴とするコミュニケーションシステム。
【請求項２】
前記記事格納手段に新たに第１の記事が格納される際に、当該第１の記事と当該第１の記事が関係する既に前記記事格納手段に格納されている第２の記事との関係の種類を表すナレッジリンク情報を取得して前記ナレッジリンク情報格納手段に格納するナレッジリンク格納処理手段を更に具備することを特徴とする請求項１記載のコミュニケーションシステム。
【請求項３】
前記ナレッジリンク格納処理手段は、前記記事格納手段に新たに格納される前記第１の記事がユーザによって作成される際の、前記第１の記事と前記第２の記事とを関連付ける当該ユーザの操作の種類に基づいて、前記記事相互間の関係の種類を決定し、前記決定された前記記事相互間の関係の種類を表すナレッジリンク情報を取得することを特徴とする請求項２記載のコミュニケーションシステム。
【請求項４】
前記ナレッジリンク情報は、前記記事格納手段に新たに格納される記事を先記事及び当該記事が関係する既に前記記事格納手段に格納されている記事を元記事として識別するための向きを示す情報を有し、
前記ユーザ役割導出手段は、前記向きを示す情報によって示される前記先記事を作成したユーザ及び前記元記事を作成したユーザのそれぞれに応じた役割を導出する
ことを特徴とする請求項１記載のコミュニケーションシステム。
【請求項５】
ある記事を起点として記事が連鎖的に作成される複数の記事のつながりによって示される定型的な経路に含まれる当該複数の記事相互間の関係の種類の組み合わせの特徴を示す組み合わせ情報と、前記複数の記事内において、前記定型的な経路の終端に位置する記事からの記事のまとまりのつながりの深さの各々に対応する記事を作成したユーザに対応して、役割及び重みを示す重み情報とを有するパタン情報を格納する役割パタン格納手段を更に具備し、
前記ユーザ役割導出手段は、
前記記事格納手段に格納されている記事の各々を前記定型的な経路の終端に位置する記事として、前記組み合わせ情報によって示される特徴に適合する複数の記事が存在するか否かを、前記ナレッジリンク情報格納手段に格納されているナレッジリンク情報によって示される関係の種類または向きに基づいて判定するパタン照合手段と、
前記パタン照合手段によって前記特徴に適合する複数の記事が存在すると判定された場合に、当該複数の記事を作成したユーザ毎に対応する前記重みを前記役割に加算する加算手段と、
前記加算手段によって加算された結果に基づいて、前記ユーザ毎に前記加算された重みが高い役割を当該ユーザ毎の役割として選択する役割選択手段とを含む
ことを特徴とする請求項４記載のコミュニケーションシステム。
【請求項６】
前記組み合わせ情報によって示される組み合わせの特徴は、前記つながりの深さ毎に設定される前記組み合わせに適合するための条件を含み、
前記パタン照合手段は、前記つながりの深さ毎に前記条件を満たす記事が存在した場合に、前記組み合わせ情報によって示される特徴に適合する複数の記事が存在することを判定する
ことを特徴とする請求項５記載のコミュニケーションシステム。
【請求項７】
前記優先度決定手段によって決定された優先度に基づいて前記要求元のユーザに記事を提示する際に、当該要求元のユーザに対応付けて前記ユーザ役割格納手段に格納されている情報の示す役割に応じて、当該要求元のユーザに提示する記事の要約文の長さを変える結果生成手段を更に具備することを特徴とする請求項１記載のコミュニケーションシステム。
【請求項８】
コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段を有するコミュニケーションシステムにおいて、当該システムのコンピュータによって実行されるプログラムであって、
前記コンピュータに、
前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報をナレッジリンク情報格納手段に格納するステップと、
前記ナレッジリンク情報の示す関係の種類に基づいて、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するステップと、
前記導出されたユーザの役割を示す情報を当該ユーザに対応付けてユーザ役割格納手段に格納するステップと、
前記ユーザからの記事検索または記事参照の要求に応じ、当該要求に合致する記事を当該要求に合致する度合いに基づいて前記記事格納手段から取得するステップと、
前記取得された記事毎の前記要求に合致する度合いを、要求元のユーザに対応付けて前記ユーザ役割格納手段に格納されている情報の示す役割に基づいて変更するステップと、
前記取得された記事を前記要求元のユーザに提示する際の当該記事毎の優先度を、前記変更された記事毎の前記要求に合致する度合いに基づいて決定するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のユーザが電子的にコミュニケーションを取ることが可能なコミュニケーションシステム及びプログラムに関する。
【背景技術】
【０００２】
複数のユーザが電子的にコミュニケーションを取るシステムとして、メーリングリストや電子掲示板等を利用したコミュニケーションシステムが利用されている。このようなコミュニケーションシステムでは、ユーザからの要求に応じて、コミュニティ内の記事（記事データ）の中から当該ユーザが知りたい記事、当該ユーザにとって重要と思われる記事を検索することが一般的に行われている。
【０００３】
従来の記事検索の方法として、記事の登録時に付加されたキーワードから記事を検索する方法または自然言語を用いて検索する方法等が知られている。また、記事の発言数の大小により記事を検索する方法がある。
【０００４】
しかしながら、上記したキーワードから記事を検索する方法では、検索対象記事はユーザによって指定されたキーワードによって一意に決まってしまう。単に記事内に指定されたキーワードが含まれるというだけでは、真に必要とされる文書を確実に検索することができない場合がある。したがって、信頼性の高い文書検索機能を実現することができないという問題が生じる。また、キーワードの内容、個数等によって該当記事が多数存在する場合には、その中から所望する記事を人為的な目視作業により抽出しなければならない。よって、所望する記事の検索作業に多くの時間と労力を要し、効率のよい検索作業が行えないという問題が生じる。上記した自然言語を用いて検索する方法でも、同様の問題が生じる。記事の発言数により検索した場合においても、その記事を見る人によって、検索結果として提示される記事が重要であるかそうでないかが変わってくる。そのため、検索結果に対しての信頼性は必ずしも保証されず、ユーザの要求に対して応えることができない場合がある。
【０００５】
そこで、例えば特許文献１には、大量の電子ファイルの中から検索対象を絞り込むための次のような技術（以下、先行技術とする）が開示されている。この先行技術によれば、所望の内容を含む電子ファイルの検索を実行する際、電子ファイルに対する操作の履歴に基づいて検索対象を絞り込んだ上で、ユーザによって指定されたキーワードを含む文書ファイルの検索を実行することが可能となる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−１６３４３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記したように、先行技術によれば、電子ファイルに対する操作の履歴を利用することによって、検索対象を絞り込んだ上で検索処理を実行することが可能である。
【０００８】
しかしながら、先行技術では、所望の内容を含む文書ファイルの検索を実行する場合、検索対象を絞り込むために、検索条件の１つとして、ユーザが自ら電子ファイルに対する操作の履歴等を入力する必要がある。また、コミュニティ内のユーザの役割によって、当該ユーザが重要と判断する記事は異なる。しかしながら、先行技術では、コミュニティ内のユーザの役割については考慮されていない。このため、電子ファイルに対する操作の履歴に基づいて検索対象を絞り込んだ上で検索処理を実行したとしても、検索要求元のユーザにとって有用な検索結果を提示することができるとは限らない。
【０００９】
本発明は、上記事情を考慮してなされたものでありその目的は、ユーザが特別な操作をすることなく、所定のコミュニティ内でユーザがどのような役割を持っているかを導出し、当該ユーザに対してより有用な情報を提示することができるコミュニケーションシステム及びプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの態様によれば、コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段を有するコミュニケーションシステムが提供される。このコミュニケーションシステムは、前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段と、前記ナレッジリンク情報の示す関係の種類に基づいて、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するユーザ役割導出手段と、前記ユーザ役割導出手段によって導出されたユーザの役割を示す情報を当該ユーザに対応付けて格納するユーザ役割格納手段と、ユーザからの記事検索または記事参照の要求に応じ、当該要求に合致する記事を当該要求に合致する度合いに基づいて前記記事格納手段から取得する記事取得手段と、前記記事取得手段によって取得された記事毎の前記要求に合致する度合いを、要求元のユーザに対応付けて前記ユーザ役割格納手段に格納されている情報の示す役割に基づいて変更する変更手段と、前記記事取得手段によって取得された記事を前記要求元のユーザに提示する際の当該記事毎の優先度を、前記変更手段によって変更された記事毎の前記要求に合致する度合いに基づいて決定する優先度決定手段とを具備する。
【発明の効果】
【００１１】
本発明によれば、所定のコミュニティ内でユーザがどのような役割を持っているかを導出し、当該ユーザの役割に応じた記事を取得することにより、ユーザに対してより有用な情報を提示するが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に係るコミュニケーションシステム３とユーザ端末２-1，２-2，…，２-ｎとの概略構成図。
【図２】図１のコミュニケーションシステム３の主として機能構成を示すブロック図。
【図３】図１のユーザ端末２-ｉ（ｉ＝１，２，…，ｎ）に表示される記事投稿画面の一例を示す図。
【図４】図２のユーザ役割導出部１１の構成を示すブロック図。
【図５】図２の情報検索部１４の構成を示すブロック図。
【図６】図２の記事ＤＢ８のデータ構造例を示す図。
【図７】図２のＫＬ情報ＤＢ９のデータ構造例を示す図。
【図８】ユーザ役割導出部１１の処理手順を示すフローチャート。
【図９】パタン情報の組み合わせ情報の一例を示す図。
【図１０】パタン情報の重み情報の一例を示す図。
【図１１】ユーザ毎に、役割に対する重みをポイントとして集計した結果の一例を示す図。
【図１２】パタン照合部１１ｃの処理手順を示すフローチャート。
【図１３】階層ｋに対応する条件の一例を示す図。
【図１４】図１３の条件に適合する記事を説明するための図。
【図１５】階層ｋ＋１に対応する条件の一例を示す図。
【図１６】図１５の条件に適合する記事を説明するための図。
【図１７】記事検索要求に対する情報検索部１４の処理手順を示すフローチャート。
【図１８】記事参照要求に対する情報検索部１４の処理手順を示すフローチャート。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施形態について説明する。  
まず、図１及び図２を参照して、本発明の一実施形態に係るコミュニケーションシステムの構成について説明する。
【００１４】
図１は、本発明の一実施形態に係るコミュニケーションシステムとユーザ端末との関係を示す図である。図１に示すように、ユーザによって操作されるユーザ端末２-1、２-2、…、２-ｎは、例えばインターネット或いはローカルエリアネットワークのようなネットワーク１を介してコミュニケーションシステム３と通信可能なように接続されている。コミュニケーションシステム３は、ユーザ端末２-1〜２-ｎのユーザに対して、電子掲示板のようなコミュニティを提供する。
【００１５】
コミュニケーションシステム３は、コンピュータ３１と、ハードディスクドライブのような外部記憶装置３２とを含む。外部記憶装置３２には、コミュニケーションシステム３を実現するのに必要なプログラム３２０が格納されている。
【００１６】
次に、図２を参照して、コミュニケーションシステム３の主として機能構成について説明する。  
コミュニケーションシステム３は、図２に示されるように、入力インタフェース４、情報登録管理部５、記事格納処理部６、ナレッジリンク格納処理部７、記事データベース８、ナレッジリンク情報データベース９、役割パタン辞書１０、ユーザ役割導出部１１、ユーザ役割情報データベース１２、ルールデータベース１３、情報検索部１４、結果生成部１５及び出力インタフェース１６から構成される。記事データベース８、ナレッジリンク情報データベース９、役割パタン辞書１０、ユーザ役割情報データベース１２及びルールデータベース１３は、図１に示す外部記憶装置３２に格納される。
【００１７】
入力インタフェース４は、ユーザの操作に応じてユーザ端末２-ｉ（ｉ＝１，２，…，ｎ）からネットワーク１を介して送出された例えば記事検索または記事参照の要求または記事データ（以下、単に記事と称する）をコミュニケーションシステム３に入力する。
【００１８】
図３は、ユーザが、ユーザ端末２-ｉから記事をコミュニケーションシステム３に投稿（入力）する場合に、当該ユーザ端末２-ｉに表示される記事投稿画面の一例を示す。図３（ａ）は、ある記事（ここでは、「案件情報（Ｘｘｘ殿）」）に対して返信する記事を作成する場合の記事投稿画面１７を示す。ユーザが、記事投稿画面１７に存在する関連記事を追加するための追加ボタン１７ａを押すと、図３（ｂ）に示すような別の画面１８が開かれる。この画面１８には、関連記事、例えば最近見た記事及びブックマーク記事が表示される。例えば最近見た記事は、最近見た記事を示す欄１８ｂに一覧として表示される。ブックマーク記事は、ブックマークに登録した記事を示す欄１８ｃに一覧として表示される。画面１８の欄１８ｂ及び１８ｃに表示される一覧内の各記事にはチェックボックスが付されている。ここでユーザが、例えば返信記事を作成する際に参照する記事のチェックボックスにチェックをし、追加ボタン１８ａを押したものとする。すると、チェックされた記事は関連記事として、記事投稿画面１７の関連記事欄１７ｂに追加される。記事投稿画面１７は添付欄１７ｃを含む。この欄１７ｃを用いることにより、添付ファイルが指定可能である。ユーザはユーザ端末２-ｉを操作することにより、関連記事または添付ファイルに基づいて記事投稿画面１７上でタイトル及び本文を作成し、コミュニケーションシステム３に記事を投稿する。
【００１９】
再び図２を参照すると、情報登録管理部５は、入力インタフェース４によって入力された記事を受け付ける。情報登録管理部５は、受け付けた記事を記事格納処理部６に出力する。情報登録管理部５は、後述するナレッジリンク情報（以下、ＫＬ情報と称する）を取得するための指示をナレッジリンク格納処理部（ＫＬ格納処理部）７に対して行う。また、情報登録管理部５は、新たに記事が追加されたこと、及びＫＬ情報を取得するための指示を行ったことをユーザ役割導出部１１に通知する。
【００２０】
記事格納処理部６は、情報登録管理部５によって出力された記事を記事データベース（ＤＢ）８に格納する処理を行う。この記事は、当該記事を作成したユーザを示す情報を含む。
【００２１】
ＫＬ格納処理部７は、情報登録管理部５からの指示に応じてＫＬ情報を取得する。ＫＬ情報は、ユーザによって作成されて新たに記事ＤＢ８に格納される記事（第１の記事）と、この記事が関係する既に記事ＤＢ６に格納されている記事（第２の記事）との記事相互間の関係と関係の種類を表す。また、ＫＬ情報は、第１の記事を先記事及び第２の記事を元記事として識別するための向きを示す情報を有する。ＫＬ格納処理部７は、ユーザが先記事を作成する際の、先記事と元記事とを関連付けるユーザの操作の種類に基づいて、当該記事相互間の関係の種類を決定する。
【００２２】
ここで、当該先記事と元記事とを関連付けるユーザの操作の種類とは、前述した図３の説明で述べたような、ユーザが記事を作成する際の例えば関連記事欄１７ｂに記事を追加する操作、または添付欄１７ｃに添付ファイルを指定する操作等である。ＫＬ格納処理部７は、決定された記事相互間の関係の種類を表すＫＬ情報（ＫＬレコード）を取得し、当該ＫＬ情報をナレッジリンク情報データベース（ＫＬ情報ＤＢ）９に格納する処理を行う。
【００２３】
役割パタン辞書１０には、組み合わせ情報と重み情報とを有するパタン情報が予め格納されている。組み合わせ情報は、コミュニティ内のユーザによって、ある記事を起点として連鎖的に作成される複数の記事のつながりによって示される定型的な経路に含まれる当該複数の記事相互間の関係の種類の組み合わせの特徴を示す。重み情報は、上記複数の記事内において、定型的な経路の終端に位置する記事からの記事のまとまりのつながりの深さ（以下、階層と称する）の各々に対応する記事を作成したユーザに対応して、役割及び重みを示す。
【００２４】
ユーザ役割導出部１１は、記事ＤＢ８、ＫＬ情報ＤＢ９及び役割パタン辞書１０を参照して、ＫＬ情報によって互いに関係する記事を作成したコミュニティ内のユーザの役割を導出する。ユーザ役割導出部１１は、導出されたユーザの役割を示す情報を当該ユーザに対応付けてユーザ役割情報データベース（ＤＢ）１２に格納する。ユーザ役割導出部１１によって導出される役割には、例えば後述する「実担当」、「取りまとめ」及び「管理」がある。
【００２５】
ルールデータベース（ＤＢ）１３には、ユーザ役割情報ＤＢ１２に格納されている情報の示す役割の各々に対応付けて、ユーザからの記事検索または記事参照の要求に合致する度合い（以下、合致度と称する）を当該役割の各々に基づいて変更するためのルール（ルール情報）が格納されている。なお、ルールＤＢ１３に格納されているルールには、ユーザによって記事検索が要求された場合に適用されるルールとユーザによって記事参照が要求された場合に適用されるルールとがある。
【００２６】
情報検索部１４は、ユーザからの記事検索または記事参照の要求に応じて、当該要求に合致する記事を合致度に基づいて記事ＤＢ８から取得する。ここでは、合致度が一定の値より高い記事が要求に合致した記事として取得される。また、合致度が上位の一定数の記事が要求に合致した記事として取得されても良い。合致度には、記事検索要求に対してはスコアが、記事参照要求に対しては重みが、それぞれ用いられる。情報検索部１４は、ルールＤＢ１３を参照し、記事検索要求または記事参照要求の要求元のユーザの役割に対応するルールに従って、取得された記事の合致度を変更する。
【００２７】
情報検索部１４は、取得された記事を要求元のユーザに提示する際の記事毎の優先度（提示優先度）を、ルールＤＢ１３に格納されているルールに基づいて変更された合致度に基づいて決定する。情報検索部１４は、記事ＤＢ８から取得された記事及び当該記事の各々の優先度を示す情報を結果生成部１５に出力する。
【００２８】
結果生成部１５は、情報検索部１４によって出力された記事及び優先度に基づいて、要求元のユーザに対応付けてユーザ役割情報ＤＢ１２に格納されている情報の示す役割に応じた結果画面を生成する。結果生成部１５は、生成された結果画面の情報を出力インタフェース１６に出力する。
【００２９】
結果生成部１５によって生成される結果画面には、要求元のユーザからの記事検索または記事参照の要求に対する結果としてユーザに提示する記事の一覧が表示される。この記事の一覧は、当該記事の要約文を含む。結果生成部１５は、結果画面に表示される記事の数と当該記事の要約文の長さとを、要求元のユーザの役割に応じて変える。
【００３０】
例えば要求元のユーザの役割が「実担当」の場合、結果生成部１５は、結果画面に表示される一覧中の記事の数を少なくして、当該記事の要約文を長くする。また、要求元のユーザの役割が「取りまとめ」、「管理者」となるにしたがって、結果生成部１５は、一覧中の記事の数を多くして、当該記事の要約文を短くする。
【００３１】
なお、取得された記事を要求元のユーザに提示する際の優先度の決定に従来のように当該ユーザの役割を考慮しない場合でも、結果画面に表示される一覧中の記事の要約文の長さについては当該ユーザの役割に応じて変えても良い。
【００３２】
結果生成部１５は、重み付け部１５１を有する。重み付け部１５１は、情報検索部１４によって取得された記事の内容を例えば改行と句点「。」で、段落と当該段落内の文に区切って、次のように重み付けを行う。重み付け部１５１は、情報検索部１４によって取得された記事の中の各段落に含まれる文に対し、例えば当該記事の中で前に位置する段落に含まれる文ほど重み（第１の重み）を高くする。また重み付け部１５１は、記事の中の各段落に含まれる文のうち、その段落の中の最初及び最後の文の重み（第２の重み）を高くする。更に重み付け部１５１は、記事の中の文に含まれる単語の重み、例えばＴＦ／ＩＤＦの重みを文毎に加算することによって当該文の重み（第３の重み）を計算する。単語のＴＦ／ＩＤＦ値は、当該単語が現れる程度を表す評価値として良く知られている。重み付け部１５１は、記事に含まれる文毎に取得された、第１、第２及び第３の重みに基づき、当該文毎の重みを決定する。ここでは、文毎に第１、第２及び第３の重みを加算することにより、当該文毎の重み付けが行われる。
【００３３】
結果生成部１５は、重み付け部１５１による重み付けの結果に基づいて、要求元のユーザの役割に応じて、重みの高い文を例えば２または３文組み合わせることにより要約文を作成する。
なお、ＴＦ／ＩＤＦの重みの計算が、情報検索部１４によって取得された全記事を対象に必ずしも行われる必要はない。例えば、要求元のユーザの役割が「実担当」の場合、役割が「実担当」のユーザによって作成された記事のみを対象にＴＦ／ＩＤＦの重みが計算されても良い。要求元のユーザの役割が「取りまとめ」または「管理者」の場合も同様である。この場合、役割毎に使用頻度の高い単語が異なるため、例えば、ＴＦ／ＩＤＦによる重みの計算の対象となる記事を、役割が「実担当」であるユーザによって作成された記事に限定することによって、役割が「実担当」であるユーザによって使用される頻度の高い単語の重みが、記事ＤＢ８内の全ての記事について当該重みの計算を行った場合より大きくなる。これにより、役割が「実担当」であるユーザによって使用される頻度の高い単語を含む文が、要約文に含まれやすくなるため、より役割の各々に適合する要約文が作成される。
【００３４】
出力インタフェース１６は、結果生成部１５によって出力された要求元のユーザからの記事検索または記事参照の要求に対する結果（結果画面の情報）を、当該要求元のユーザに提示するために、ユーザ端末２-ｉ（ｉ＝１，２，…，ｎ）に出力する。
【００３５】
入力インタフェース４、情報登録管理部５、記事格納処理部６、ナレッジリンク格納処理部７、ユーザ役割導出部１１、情報検索部１４、結果生成部１５及び出力インタフェース１６は、図１に示されるコンピュータ３１が外部記憶装置４０に格納されているプログラム３２０を読み込んで実行することにより実現されるものとする。このプログラム３２０は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム３２０が、ネットワーク１を介してコンピュータ３１にダウンロードされても構わない。
【００３６】
図４は、ユーザ役割導出部１１の構成を示すブロック図である。ユーザ役割導出部１１は、記事リスト作成部１１ａ、パタン情報リスト作成部１１ｂ、パタン照合部１１ｃ、加算部１１ｄ及び役割選択部１１ｅを備える。
【００３７】
記事リスト作成部１１ａは、記事ＤＢ８を参照して、後述する計算済フラグによって示される、ユーザ役割導出部１１によって処理されていない記事を取得し、当該記事のリストを作成する。
【００３８】
パタン情報リスト作成部１１ｂは、役割パタン辞書１０に格納されている全てのパタン情報を取得し、当該パタン情報のリストを作成する。
【００３９】
パタン照合部１１ｃは、記事リスト作成部１１ａによって作成されたリストの記事を、前記定型的な経路の終端に位置する記事（以下、始点と称する）とした場合に、パタン情報リスト作成部１１ｂによって作成されたリストのパタン情報の組み合わせ情報によって示される特徴に適合するか否かを判定する。パタン照合部１１ｃは、記事ｉを始点として記事が連鎖的に作成される複数の記事相互間のリンクの組み合わせと、パタン情報ｊの組み合わせ情報によって示さされる特徴とを、ＫＬ情報ＤＢを参照して照合することによって判定処理を行う。
【００４０】
加算部１１ｄは、パタン情報の重み情報に基づいて、上記組み合わせ情報によって示される特徴に適合する複数の記事のうち、上記定型的な経路における上記始点からの各階層に位置する記事を作成したユーザ毎に重みを加算する。
【００４１】
役割選択部１１ｅは、加算部１１ｃによって加算されたユーザ毎の重みに基づいて、当該ユーザ各々の役割を選択する。役割選択部１１ｄは、ユーザの各々に対応付けて、当該ユーザの役割を示す情報をユーザ役割情報ＤＢ１２に格納する。
【００４２】
図５は、情報検索部１４の構成を示すブロック図である。情報検索部１４は、ユーザ識別部２１、記事取得部２２、ＫＬ情報取得部２３、作成者認識部２４、役割取得部２５、記事スコア・重み変更部２６及びソート部２７を備える。
【００４３】
ユーザ識別部２１は、入力インタフェース４によって入力された記事検索または記事参照の要求に付加されるユーザの情報から、要求元のユーザを識別する。
【００４４】
記事取得部２２は、記事検索部２２１と記事一覧部２２２とを含む。記事検索部２２１は、ユーザからの記事検索の要求に応じて、当該要求に対する合致度を表すスコアが上位の記事を、当該要求に合致した記事として記事ＤＢ８から取得する。ここで、記事検索要求とは、例えばあるキーワードを含む記事を検索する要求である。記事検索部２２１は、取得された記事毎に、ユーザの記事検索要求に対する当該検索された記事の合致度を表すスコアを取得する。
【００４５】
記事一覧部２２２は、ユーザからの記事参照の要求に応じて、当該要求に対する合致度を表す重みが上位の記事を、当該要求に合致した記事として記事ＤＢ８から取得する。ここで、記事参照要求とは、例えばコミュニティ内の新しい記事を取得する要求である。記事一覧部２２２は、取得された記事毎に、例えば当該記事の新しさを合致度として表す重みを取得する。
【００４６】
ＫＬ情報取得部２３は、記事検索部２２１または記事一覧部２２２によって取得された記事を先記事または元記事とするＫＬ情報がＫＬ情報ＤＢ９に格納されている場合に、当該ＫＬ情報を取得する。
【００４７】
作成者認識部２４は、記事検索部２２１または記事一覧部２２２によって取得された記事に含まれるユーザを示す情報から、記事を作成したユーザを認識する。また、作成者認識部２４は、ＫＬ情報取得部２３によって取得されたＫＬ情報によって示される先記事または元記事に含まれるユーザを示す情報から、当該先記事または元記事を作成したユーザを認識する。
【００４８】
役割取得部２５は、記事検索または記事参照の要求元のユーザ及び作成者認識部２４によって認識されたユーザに対応付けて、ユーザ役割情報ＤＢ１２に格納されている情報の示す役割を取得する。
【００４９】
記事スコア・重み変更部２６は、スコア取得部２６１、重み演算部２６２及び加算部２６３を含む。スコア取得部２６１は、ＫＬ情報取得部２３によって取得されたＫＬ情報によって示される先記事または元記事のスコアを取得する。
【００５０】
重み演算部２６２は、記事検索部２２１または記事一覧部２２２によって取得された記事の各々の重みを、ルールＤＢ１３に格納されているルールに従って決定する。即ち重み演算部２６２は、ＫＬ情報取得部２３によって取得されたＫＬ情報によって表される記事相互間の関係と関係の種類と、役割取得部２５によって取得された記事検索または記事参照の要求元のユーザ及び作成者認識部２４によって認識されたユーザの役割とに基づいて、記事毎の重みを決定する。重み演算部２６２は、決定された記事毎の重みに基づいて、スコア取得部２６１によって取得された記事毎のスコアを重み付けする。ここでは、取得された記事毎のスコアに、その記事の重みを乗じる。重み演算部２６２は、記事毎の重み付けされたスコア（記事検索時）または決定された記事毎の重み（記事参照時）を加算部２６３に出力する。
【００５１】
加算部２６３は、記事検索部２２１によって取得された記事毎に、重み演算部２６３によって出力されたスコアを、記事検索部２２１によって取得された記事のスコアに加算する。また、加算部２６３は、記事一覧部２２２によって取得された記事毎に、重み演算部２６２によって出力された重みを、記事一覧部２２２によって取得された記事の重みに加算する。加算部２６３は、加算結果（記事毎のスコアまたは重み）を、記事検索または記事参照の要求に応じて取得された記事をユーザに提示する際の優先度を決定する情報として、ソート部２７に出力する。
【００５２】
ソート部２７は、加算部２６３によって出力された記事毎のスコアまたは重みに基づいて、記事検索または記事参照の要求に対する結果としてユーザに提示する記事をソートする。つまりソート部２７は、ユーザに記事の一覧を提示する際の当該一覧中の記事の優先度（提示順を表す優先度）をその記事のスコア（重み付けされたスコア）または重みに基づいて決定する優先度決定部として機能する。ソート部２７は、ソートされた（優先度が決定された）結果を示す情報を結果生成部１５に出力する。
【００５３】
図６は、記事ＤＢ８のデータ構造例を示す。記事ＤＢ８には、図６に示すように、記事単位に、各記事を一意に特定する識別子である記事ＩＤ、記事のタイトル、記事の本文、当該記事を作成したユーザ（を示す情報）及び計算済フラグを含むレコード（記事レコード）が記憶されている。図６では省略されているが、記事レコードは、対応する記事の作成日時（投稿日時）の情報も含む。計算済フラグは、対応する記事がユーザ役割導出部１１によって処理された記事であるか否かを示す。図６では、説明の簡略化のために、記事レコードが記事の本文を含むことを前提としている。しかし、記事の本文は可変長であるため、当該本文を記事レコードから切り離して記事ＤＢ８に格納し、当該本文の位置を示すポインタを当該記事レコードに設定すると良い。
【００５４】
図６に示す例では、最初の記事レコードには、「記事ＩＤ：１」、「タイトル：×××」、「本文：×××」、「ユーザ：Ａ」及び「計算済フラグ：Ｆ１」が記憶されている。
【００５５】
計算済フラグには、「Ｆ１」または「Ｆ２」が記憶されている。「Ｆ１」は、対応する記事がユーザ役割導出部１１によって処理された記事であることを示し、「Ｆ２」は、当該記事がユーザ役割導出部１１によって処理された記事でないことを示す。
【００５６】
図７は、ＫＬ情報ＤＢ９のデータ構造例を示す。ＫＬ情報ＤＢ９には、記事ＤＢ８に格納されている記事レコードによって示される記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すＫＬレコードが格納される。ＫＬレコードは、図７に示すように、元記事となる記事を示す元記事ＩＤ、先記事となる記事を示す先記事ＩＤ及び当該元記事と当該先記事との記事相互間の関係の種類を表すリンク（リンクタイプ）を含む情報（ＫＬ情報）である。
【００５７】
図７に示す例では、最初のＫＬレコードには、「元記事ＩＤ：１」、「先記事ＩＤ：２」及び「リンク：follow」が記憶されている。
【００５８】
図７に示すように、リンクには、例えば「follow」、「sum」、「create」がある。「follow」は、ある記事を受けて、それに補足、返答または反論する等、文脈的な情報を追加していくことを意味する。「sum」は、ある記事をまとめたり、要約したりする関係を意味する。「create」は、他の記事とは関係なく作成されたことを意味する。
【００５９】
また、上記した以外にも、例えば「consult」、「revise」、「describe」がある。「consult」は、ある記事を参考にしたという関係を意味する。「revise」は、ある記事を改訂して置き換えている関係を意味する。「describe」は、説明的な関係にあり、先記事と元記事とが共存しないと文脈的には理解できないほど強い結びつきを持っていることを意味する。
【００６０】
次に、図８のフローチャートを参照して、ユーザ役割導出部１１の処理手順について説明する。  
まず、記事リスト作成部１１ａは、記事ＤＢ８に格納されている記事レコードを参照して、計算済フラグが「Ｆ２」である（計算済フラグが立っていない）記事レコードで示される全ての記事を取得し、当該記事のリストを作成する（ステップＳ１）。ここでは、記事リスト作成部１１ａは、例えばｎ個の記事のリストを作成したものとする。
【００６１】
次に、パタン情報リスト作成部１１ｂは、役割パタン辞書１０に格納されている全てのパタン情報を取得して、当該パタン情報のリストを作成する（ステップＳ２）。ここでは、パタン情報リスト作成部１１ｂは、例えばｍ個のパタン情報のリストを作成したものとする。
【００６２】
ユーザ役割導出部１１では、記事リスト作成部１１ａによって作成されたリストに基づいて、ｎ個の記事のそれぞれについて後述するステップＳ４からステップＳ８までの処理が繰り返される（ステップＳ３）。ここでは、記事リスト作成部１１ａによって作成されたリスト内のｎ個の記事のうち、記事ｉ（ｉ=１，２，…，ｎ）について述べる。
【００６３】
またユーザ役割導出部１１では、パタン情報リスト作成部１１ｂによって作成されたリストに基づいて、ｍ個のパタン情報のそれぞれについて後述するステップＳ５からステップＳ７までの処理が繰り返される（ステップＳ４）。ここでは、パタン情報リスト作成部１１ｂによって作成されたリスト内のｍ個のパタン情報のうち、パタン情報ｊ（ｊ=１，２，…，ｍ）に付いて述べる。
【００６４】
パタン照合部１１ｃは、記事ｉを始点としたとき、パタン情報ｊの組み合わせ情報によって示される特徴に適合するか否かを判定するために、記事ｉを始点として記事が連鎖的に作成される複数の記事相互間のリンクの組み合わせと、パタン情報ｊの組み合わせ情報によって示される特徴とを、ＫＬ情報ＤＢ９に格納されているＫＬレコードに基づいて照合する（ステップＳ５）。
【００６５】
図９は、役割パタン辞書１０内のパタン情報を構成する組み合わせ情報の一例を示す。組み合わせ情報は、始点となる記事からの階層毎に、当該階層を識別するための番号、組み合わせ情報によって示される組み合わせに適合するための条件及び組み合わせ情報によって示される組み合わせの終端を示す情報を含む。
【００６６】
条件は、例えばリンクの向き、リンクの種類、繰り返し回数及び記事の作成者を示す情報を含む。リンクの向きには、始点となる記事から他の記事に向かってリンクが繋がっていることを示す第１の向き（ＩＮ）と、他の記事から始点となる記事に向かってリンクが繋がっていることを示す第２の向き（ＯＵＴ）がある。リンクの種類については既に詳述されているので、ここでは説明を省略する。繰り返し回数は、リンクの種類に示されるリンクを繰り返す回数を示す。記事の作成者は、リンクの種類に示されるリンクによって始点となる記事と繋がっている記事を作成したユーザを示す。
【００６７】
終端は、パタン情報の組み合わせ情報の終端か否かを示すフラグ「０」または「１」である。ここで、フラグ「０」は、そのフラグと対応する階層が組み合わせ情報の終端でない旨を示し、フラグ「１」は、そのフラグと対応する階層が組み合わせ情報の終端である旨を示す。
【００６８】
図９に示す例では、パタン情報は、３つの階層「１」、「２」及び「３」の各々に対応して、番号、リンクの向き、リンクの種類、繰り返し回数、記事の作成者及び終端の各情報を含む。具体的には「階層：１」に対応して、「番号：１-１」、「リンクの向き：ＩＮ」、「リンクの種類：follow」、「繰り返し回数：１」、「記事の作成者：＝α」及び「終端：０」が記憶されている。また、「階層：２」に対応して、「番号：２-１」、「リンクの向き：ＩＮ」、「リンクの種類：follow」、「繰り返し回数：≧０」、「記事の作成者：≠α（αでない）」及び「終端：０」が記憶されている。また、「階層：３」に対応して、「番号：３-１」、「リンクの向き：ＩＮ」、「リンクの種類：sum」、「繰り返し回数：１」、「記事の作成者：≠α」及び「終端：１」が記憶されている。
【００６９】
なお、役割パタン辞書１０内には、前述した「create」、「consult」、「revise」、「describe」等のリンクを組み合わせたパタン情報も予め格納されている。
【００７０】
さて、図８のステップＳ５で実行されるパタン照合部１１ｃによる照合の結果、記事ｉを始点として記事が連鎖的に作成される複数の記事相互間のリンクの組み合わせと、パタン情報ｊの組み合わせ情報によって示される特徴とが適合（マッチ）したものとする（ステップＳ６のＹＥＳ）。この場合、加算部１１ｄは、パタン情報ｊの重み情報に基づいて、当該パタン情報ｊに適合する記事の作成者（ユーザ）毎に、当該パタン情報ｊの重み情報に定義されている役割の重みを加算する（ステップＳ７）。
【００７１】
一方、記事ｉを始点としてパタン情報ｊと適合しない場合（ステップＳ６のＮＯ）、加算部１１ｄはステップＳ７をスキップする。
【００７２】
図１０は、役割パタン辞書１０内の前述したパタン情報を構成する重み情報の一例を示す。重み情報は、重みが加算されるユーザ毎に、当該ユーザを示す加算先、当該ユーザの役割の種類及び当該ユーザに加算する重みを示す加算値の各情報を含む。
【００７３】
図１０に示す例では、重み情報は、３つの加算先の各々に対応して、役割の種類及び加算値を含む。具体的には、「加算先：α」に対応して、「役割の種類：取りまとめ」及び「加算値：（組み合わせ情報の階層「３」を示す番号）３-１に該当するリンク数×２」が記憶されている。また、「加算先：３-１の記事の作成者」及び「加算先：２-１の記事の作成者」に対応して、「役割の種類：実担当」及び「加算値：リンク数によらず１」が記憶されている。
【００７４】
ここで、図８のステップＳ５からステップＳ７までの処理がパタン情報リスト作成部１１ｂによって作成されたリストに基づいて、ｍ個のパタン情報の全てについて繰り返し実行されたものとする。この場合、パタン情報についてのループは終了する（ステップＳ８）。
【００７５】
同様に、上記のステップＳ４からステップＳ８までの処理が、記事リスト作成部１１ａによって作成されたリストに基づいて、ｎ個の記事の全てについて繰り返し実行されたものとする。この場合、記事についてのループは終了する（ステップＳ９）。
【００７６】
役割選択部１１ｅは、ユーザ毎に、加算部１１ｄによって加算された結果に基づいて、役割に対する重みをポイントとして集計し、当該ポイントの高い役割を当該ユーザの役割として選択する（ステップＳ１０）。また、役割選択部１１ｅは、ユーザの各々に対応付けて、選択された役割をユーザ役割情報ＤＢ１２に格納する。
【００７７】
図１１は、ステップＳ１０において役割に対する重みがポイントとして集計された結果の一例をテーブル形式で示す。図１１には、コミュニティ内におけるユーザ毎に、「実担当」、「取りまとめ」及び「管理」の役割毎に、その役割に対する当該ユーザのポイントが表されている。例えば、ユーザＡについては、「実担当」のポイントは「３」であり、「取りまとめ」のポイントは「１０」であり、管理のポイントは「０」である。この場合、役割選択部１１ｄは、ユーザＡの役割として「取りまとめ」を選択する。
【００７８】
他のユーザについても同様に、役割選択部１１ｄは、ユーザＣ及びＤの役割として「実担当」を選択し、ユーザＸの役割として「管理」を選択する。また、ユーザＢの例のように、ポイントの高い役割が１つでない、またはポイントの高い役割がない場合、ユーザＢの役割は考慮せずに他の処理は実行される。
【００７９】
前述したように、ユーザの役割には、「実担当」、「取りまとめ」及び「管理」がある。「実担当」は、例えばある記事に対して返信する記事を作成したユーザまたはまとめられた記事が作成された場合の、その元となる記事を作成したユーザの役割である。「取りまとめ」は、例えばある記事をまとめた記事を作成したユーザまたはある記事に対する説明的な記事を作成したユーザの役割である。「管理」は、例えばある記事を参照して記事が作成された場合に、その参照元となる記事を作成したユーザの役割である。
【００８０】
次に、図１２のフローチャートを参照して、パタン照合部１１ｃの照合処理（図８のステップＳ５）の詳細な手順について説明する。なお、パタン照合部１１ｃは、パタン情報ｊについて照合処理を行うものとする。
【００８１】
パタン照合部１１ｃは、パタン情報ｊの組み合わせ情報に示される階層のそれぞれについて、後述するステップＳ１２からステップＳ１７の処理を繰り返す（ステップＳ１１）。ここでは、パタン情報の組み合わせ情報にｐ個の階層が記憶されているものとして、階層ｋ（ｋ=１，２，…，ｐ）について説明する。
【００８２】
パタン照合部１１ｃは、階層ｋの全ての記事についての記事リストを取得する（ステップＳ１２）。ここでは、パタン照合部１１ｃはｑ個の記事についての記事リストを取得したものとする。
【００８３】
次にパタン照合部１１ｃは、取得されたリストに基づいて、ｑ個の記事のそれぞれについてステップＳ１４からステップＳ１６の処理を繰り返す（ステップＳ１３）。ここでは、パタン照合部１１ｃによって取得されたリスト内の記事ｌ（ｌ=１，２，…，ｑ）について述べる。
【００８４】
パタン照合部１１ｃは、ＫＬ情報ＤＢ９を参照して、記事ｌを始点として、パタン情報ｊの組み合わせ情報によって示される階層ｋに対応する条件に適合（マッチ）する記事が存在するかを調べる（ステップＳ１５）。
【００８５】
階層ｋに対応する条件に適合する記事が存在する場合（ステップＳ１５のＹＥＳ）、パタン照合部１１ｃは当該条件に適合する記事全てを階層ｋ＋１の記事リストに追加する（ステップＳ１６）。
【００８６】
パタン照合部１１ｃは、記事リストに基づいて、ｑ個の記事の全てについて上記のステップＳ１４からステップＳ１６までの処理を繰り返し実行する。これにより、記事リスト内の記事のループは終了する（ステップＳ１７）。
【００８７】
同様にパタン照合部１１ｃは、パタン情報の組み合わせ情報に示されるｐ個の階層の全てについて上記のステップＳ１２からステップＳ１７までの処理を繰り返し実行する。これにより、階層についてのループは終了する（ステップＳ１８）。
【００８８】
なお、上記したように、階層ｋについてステップＳ１２からステップＳ１７の処理が実行された場合に、当該階層ｋに対応する終端フラグが「０」であるならば、次に階層ｋ＋１について同様の処理が実行される。また、階層ｋに対応する終端フラグが「１」であるならば、階層についてのループは終了する。
【００８９】
パタン照合部１１ｃは、パタン情報の組み合わせ情報に含まれている終端フラグが「１」の階層まで到達した記事が存在する場合、当該組み合わせ情報によって示される特徴に適合したことを判定し、その旨を加算部１１ｄに通知する（ステップＳ１９）。
【００９０】
次に、図１３から図１６を参照して、パタン照合部１１ｃの処理の具体例について説明する。図１３は階層ｋに対応する条件の一例を示し、図１４は図１３の条件に適合する記事を説明するための図である。図１５は階層ｋ＋１に対応する条件の一例を示し、図１６は図１５の条件に適合する記事を説明するための図である。ここでは、先の説明と同様に、階層が階層ｋであり、始点となる記事が記事ｌであるものとする。
【００９１】
図１３に示すように、階層ｋに対応する条件であるリンクの向きは「IN」であり、リンクの種類は「sum」であり、繰り返し回数は「１」であり、記事の作成者は「≠α（作成者がαでない）」である。
【００９２】
ここで、階層ｋの記事リストにある記事は、始点となる記事ｌである。パタン照合部１１ｃは、記事lを始点として、図１３に示す条件に適合する記事が存在するか否かを調べる。
【００９３】
図１４に示すように、条件であるリンクの向きは、「IN」であるから、記事ｌに向かってリンクが繋がっている記事は、記事１０１，１０２及び１０３である。したがって、記事１０４及び１０５は、階層ｋに対応する条件を満たす記事ではない。
【００９４】
また、図１４に示すように、リンクの種類は、「sum」であるから、記事１０１，１０２及び１０３の各々は、この条件を満たす。
【００９５】
このとき、記事ｌと記事１０１，１０２及び１０３との間のリンクの向き及び種類は、ＫＬ情報ＤＢ９に格納されるＫＬレコードに基づいて特定される。
【００９６】
繰り返し回数は、「１」であるから、記事１０１，１０２及び１０３の各々は、この条件を満たす。記事の作成者は、「≠α」であるから、作成者がαである記事１０３は、この条件を満たさない。
【００９７】
よって、図１４において、図１３の条件に適合する記事は、記事１０１及び１０２となる。
【００９８】
この条件に適合する記事１０１及び１０２は、階層ｋ＋１の記事リストに追加される。図１２に示すように、パタン照合部１１ｃは、階層のそれぞれについて処理を実行するため、階層ｋの次に、階層ｋ＋１の処理を実行する。
【００９９】
パタン照合部１１ｃは、階層ｋ＋１の記事リストを取得する。このとき、この記事リスト内には、階層ｋの条件に適合した記事１０１及び１０２が存在する。ここでは、記事リスト内の記事１０１について説明する。
【０１００】
まずパタン照合部１１ｃは、記事１０１を始点として、階層ｋ＋１に対応する条件に適合する記事が存在するか否かを調べる。
【０１０１】
図１５に示すように、階層ｋ＋１に対応する条件であるリンクの向きは「IN」であり、リンクの種類は「follow」であり、繰り返し回数は「≧０」であり、記事の作成者は「≠α」である。
【０１０２】
図１６に示すように、条件であるリンクの向きは「IN」であるから、この条件を満たす記事は記事１０６である。また、条件であるリンクの種類は「follow」であるから、記事１０６は、この条件も満たす。
【０１０３】
ここで、条件である繰り返し回数は、「≧０」である。「０」は、始点となる記事１０１を含むことを意味する。また、「≧０」は「０以上」を意味するので、他の条件を満たすのであれば、始点となる記事１０１からの繰り返しの数には制限がないことを意味する。
【０１０４】
よって、この場合、図１６に示される記事１０１，１０６，１０７及び１０８は、始点となる記事１０１から全て「IN」の向きに「follow」で繋がっているので、これらは全て条件を満たす。
【０１０５】
記事の作成者は、「≠α」であるから、作成者がαである記事１０８は、この条件を満たさない。
【０１０６】
したがって、図１６において、図１５に示す条件を満たす記事は、記事１０１，１０６及び１０７となる。
【０１０７】
この条件に適合する記事１０１及び１０２は、階層ｋ＋２の記事リストに追加される。階層ｋ＋１に対応して示される終端フラグが「０」の場合は、終端フラグが「１」を示す階層まで、上記したように処理が繰り返される。
【０１０８】
次に、図１７のフローチャートを参照して、ユーザによって記事検索が要求された場合の、情報検索部１４の処理手順を説明する。
【０１０９】
今、ユーザがユーザ端末２-1を用いて記事検索要求を指定する操作を行ったものとする。この場合、ユーザ端末２-1は、ユーザによって指定された記事検索要求をネットワーク１を介してコミュニケーションシステム３に送出する。この記事検索要求には、当該要求を指定したユーザ、つまり要求元のユーザの情報が付加されている。
【０１１０】
コミュニケーションシステム３の入力インタフェース４は、ユーザ端末２-1からの記事検索要求を入力する。情報検索部１４のユーザ識別部２１は、入力インタフェース４によって入力された記事検索要求に付加されているユーザの情報から、要求元のユーザを識別する（ステップＳ１１０）。
【０１１１】
記事検索部２２１は、例えばキーワードから記事を検索する方法によって、記事ＤＢ８から記事検索要求に合致する記事を検索し、検索された記事の当該要求に対する合致度を表すスコアを取得する（ステップＳ１２０）。記事検索部２２１は、検索された記事のうち、取得された記事のスコア順に例えば上位ｒ件の記事を取得する（ステップＳ１３０）。
【０１１２】
ＫＬ情報取得部２３は、取得された上位ｒ件の記事の中から記事ｈ（ｈ＝１，２，…，ｒ）を取り出し、当該記事ｈを先記事または元記事として示す全てのＫＬレコードをＫＬ情報ＤＢ９から取得する（ステップＳ１４０）。ここでは、ＫＬ情報取得部２３はｓ個のＫＬレコードを取得したとする。
【０１１３】
作成者認識部２４は、ステップＳ１４０において取得されたｓ個のＫＬレコードによって示される先記事及び元記事に含まれるユーザを示す情報から、当該先記事及び元記事を作成したユーザを認識する（ステップＳ１５０）。
【０１１４】
役割取得部２５は、記事検索要求の要求元のユーザと、取得されたｓ個のＫＬレコードによって示される先記事及び元記事を作成したユーザとのそれぞれに対応付けてユーザ役割情報ＤＢ１２に格納されている情報の示す役割を取得する（ステップＳ１６０）。
【０１１５】
スコア取得部２６１は、ステップＳ１５０において取得されたＫＬレコードのうち１つを取り出し、取り出されたＫＬレコードによって示される記事ｈの先記事または元記事である記事ｇ（ｇ＝１，２，…，ｒ）のスコアを取得する（ステップＳ１７０）。
【０１１６】
重み演算部２６２は、ルールＤＢ１３に格納されているルールに従って、ＫＬ情報取得部２３によって取得されたＫＬレコードによって表される記事相互間の関係と関係の種類、向き、役割取得部２５によって取得された記事検索の要求元のユーザ及び作成者認識部２４によって認識されたユーザの役割に基づいて重みを決定する（ステップＳ１８０）。重み演算部２６２は、スコア取得部２６１によって取得された記事ｇのスコアに決定された重みを乗じて、当該記事ｇの重み付けされたスコアを取得する（ステップＳ１８１）。
【０１１７】
ここで、ルールＤＢ１３に格納されているルールのうち、前述したユーザによって記事検索要求が指定された場合に適用されるルールの例について述べる。
【０１１８】
ルールＤＢ１３には、記事検索要求時に適用されるルールとして例えば以下に示す第１乃至第５のルールを含む複数のルールが格納されている。  
第１のルールは、要求元のユーザの役割である「実担当」に対応付けられており、記事ｈを作成したユーザの役割が「取りまとめ」であって、「consult」の元記事となっている場合、当該「consult」の先記事（ここでは、記事ｇ）のスコアを重み０．３で重み付けすることを示す。
【０１１９】
第２のルールは、第１のルールと同様に要求元のユーザの役割「実担当」に対応付けられており、記事ｈが「sum」の元記事である場合、当該「sum」の先記事（ここでは、記事ｇ）のスコアを重み０．５で重み付けすることを示す。
【０１２０】
第３のルールは、要求元のユーザの役割である「取りまとめ」に対応付けられており、記事ｈを作成したユーザの役割が「管理者」であって、「follow」の先記事である場合、当該「follow」の元記事（ここでは、記事ｇ）のスコアを重み０．３で重み付けすることを示す。
【０１２１】
第４のルールは、第３のルールと同様に、要求元のユーザの役割「取りまとめ」に対応付けられており、記事ｈが「sum」の先記事である場合、当該「sum」の元記事（ここでは、記事ｇ）のスコアを重み０．２で重み付けすることを示す。
【０１２２】
第５のルールは、要求元のユーザの役割である「管理者」に対応付けられており、記事ｈが「revise」の先記事で、かつ「consult」の先記事である場合、当該「consult」の元記事（ここでは、記事ｇ）のスコアを重み０．４で重み付けすることを示す。
【０１２３】
第１乃至第５のルール以外で記事検索要求時に適用されるルールについては説明を省略する。
【０１２４】
加算部２６３は、重み演算部２６２によって取得された記事ｇの重み付けされたスコアを、記事検索部２２１によって取得された記事ｈのスコアに加算して、当該記事ｈの新たなスコアとする（ステップＳ１８２）。つまり加算部２６３は、記事ｈのスコアを再計算する。
【０１２５】
上記のステップＳ１７０及びＳ１８０−Ｓ１８２の処理は、ステップＳ１５０において取得されたｓ個のＫＬレコードの全てについて繰り返し実行される（ステップＳ１９０）。
【０１２６】
上記ｓ個のＫＬレコードの全てについてステップＳ１７０及びＳ１８０−Ｓ１８２の処理が実行された場合、上記のステップＳ１４０以下の処理が再び実行される（ステップＳ２００のＮＯ）。このステップＳ１４０以下の処理は、ステップＳ１３０において取得されたｒ件の記事の全てについて実行される。
【０１２７】
上記ｒ件の記事の全てについて、ステップＳ１４０以下の処理が実行された場合、ソート部２７は、ステップＳ１８１において再計算されたスコアに基づいて、上記ｒ件の記事をソートする（ステップＳ２１０）。
【０１２８】
次に、図１８のフローチャートを参照して、ユーザによって記事参照が要求された場合の、情報検索部１４の処理手順を説明する。
【０１２９】
まず、ユーザによって指定された記事参照要求が入力インタフェース４によって入力されたものとする。この記事参照要求には、上記記事検索要求と同様に要求元のユーザの情報が付加されている。ユーザ識別部２１は、入力インタフェース４によって入力された記事参照の要求に付加されているユーザの情報から、要求元のユーザを識別する（ステップＳ３００）。
【０１３０】
記事取得部２２は、ユーザによって指定された記事参照要求、例えばコミュニティ内における新着記事を参照するための要求に応じて、当該要求に合致する記事を記事ＤＢ８から例えばｕ件取得する（ステップＳ３１０）。ここでは、作成日時が新しい記事ほど記事参照に対する合致度が高いものとする。本実施形態では、記事参照に対する合致度として重みが用いられる。つまり記事取得部２２は、記事の新しさによる重み順に上位ｕ件の記事を取得する。
【０１３１】
ＫＬ情報取得部２３は、取得されたｕ件の記事の中から記事ｆ（ｆ＝１，２，…，ｕ）を取り出し、当該記事ｆを先記事または元記事として示す全てのＫＬレコードをＫＬ情報ＤＢ９から取得する（ステップＳ３２０）。
【０１３２】
作成者認識部２４は、ステップＳ３２０において取得されたＫＬレコードによって示される先記事及び元記事に含まれるユーザを示す情報から、当該先記事及び元記事を作成したユーザを認識する（ステップＳ３３０）。
【０１３３】
役割取得部２５は、取得されたＫＬレコードによって示される記事ｆの先記事及び元記事を作成したユーザに対応付けてユーザ役割情報ＤＢ１２に格納されている情報の示す役割を取得する（ステップＳ３４０）。
【０１３４】
重み演算部２６２は、ステップＳ３２０において取得されたＫＬレコードのうち１つを取り出し、ルールＤＢ１３に格納されているルールに従って、当該取り出されたＫＬレコードによって表される記事相互間の関係と関係の種類、向き、役割取得部２５によって取得された記事参照の要求元のユーザ及び作成者認識部２４によって認識されたユーザの役割に基づいて、記事ｆの重みを決定する（ステップＳ３５０）。
【０１３５】
ここで、ルールＤＢ１３に格納されているルールのうち、前述したユーザによって記事参照要求が指定された場合に適用されるルールの例について述べる。
【０１３６】
ルールＤＢ１３には、記事参照要求時に適用されるルールとして例えば以下に示す第６乃至第第１１のルールを含む複数のルールが格納されている。  
第６のルールは、要求元のユーザの役割である「実担当」に対応付けられており、記事ｆを作成したユーザの役割が「取りまとめ」であって、当該記事ｆが新規に作成された記事である場合、記事ｆを優先的に表示する重み付けを行うことを示す。
【０１３７】
第７のルールは、要求元のユーザの役割である「実担当」に対応付けられており、役割が「取りまとめ」であるユーザによって作成された記事ｆが、「consult」の元記事であって、当該「consult」の先記事を作成したユーザの役割が「実担当」である場合、当該記事ｆを優先的に表示する重み付けを行うことを示す。
【０１３８】
第８のルールは、要求元のユーザの役割である「取りまとめ」に対応付けられており、記事ｆを作成したユーザの役割が「管理者」であって、当該記事ｆが新規に作成されて記事である場合、記事ｆを優先的に表示する重み付けを行うことを示す。
【０１３９】
第９のルールは、要求元のユーザの役割である「取りまとめ」に対応付けられており、役割が「管理者」であるユーザによって作成された記事ｆが、「follow」の先記事であって、当該「follow」の元記事が「sum」の先記事である場合、記事ｆを優先的に表示する重み付けを行うことを示す。
【０１４０】
第１０のルールは、要求元のユーザの役割である「取りまとめ」に対応付けられており、役割が「実担当」であるユーザによって作成された記事ｆが、「follow」の先記事であって、当該「follow」の元記事を作成したユーザの役割が「取りまとめ」の場合、記事ｆを優先的に表示する重み付けを行うことを示す。
【０１４１】
第１１のルールは、要求元のユーザの役割である「管理者」に対応付けられており、役割が「取りまとめ」であるユーザによって作成されて記事ｆが、「sum」または「revise」の先記事である場合、記事ｆを優先的に表示する重み付けを行うことを示す。
【０１４２】
第６乃至第１１のルール以外で記事参照要求時に適用されるルールについては説明を省略する。
【０１４３】
加算部２６３は、記事一覧部２２２によって取得された記事毎に、当該記事の新しさによる重みと、重み演算部２６２によって決定された重みとを加算する（ステップＳ３６０）。
【０１４４】
上記のステップＳ３５０及びＳ３６０の処理は、ステップＳ３２０において取得された全てのＫＬレコードについて繰り返し実行される（ステップＳ３７０）。
【０１４５】
ステップＳ３２０において取得された全てのＫＬレコードについてステップＳ３５０及びＳ３６０の処理が実行された場合、上記のステップＳ３２０以下の処理が再び実行される（ステップＳ３８０のＮＯ）。このステップＳ３２０以下の処理は、ステップＳ３１０において取得されたｕ件の記事の全てについて実行される。
【０１４６】
上記ｕ件の記事の全てについて、ステップＳ３２０以下の処理が実行された場合、ソート部２７は、ステップＳ３６０において加算された記事毎の重みに基づいて、上記ｕ件の記事をソートする（ステップＳ３９０）。
【０１４７】
上述したように本実施形態においては、ユーザによって記事が作成された際に、当該記事と、当該記事が関係する既に記事ＤＢ８に格納されている記事との関係の種類を表すＫＬレコードを用いてコミュニティ内の各ユーザの役割が導出される。そしてユーザからの記事検索または記事参照の要求があった場合に、当該ユーザの役割に応じた当該要求に対する結果を当該要求元のユーザに提示することによって、ユーザは特別な操作をすることなく、当該ユーザにとってより有用な情報の提示を受けることが可能となる。
【０１４８】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。  
【符号の説明】
【０１４９】
３…コミュニケーションシステム、４…入力インタフェース、５…情報登録管理部、６…記事格納処理部、７…ＫＬ格納処理部、８…記事ＤＢ、９…ＫＬ情報ＤＢ、１０…役割パタン辞書、１１…ユーザ役割導出部、１１ａ…記事リスト作成部、１１ｂ…パタン情報リスト作成部、１１ｃ…パタン照合部、１１ｄ…加算部、１１ｅ…役割選択部、１２…ユーザ役割情報ＤＢ、１３…ルールＤＢ、１４…情報検索部、１５…結果生成部、１６…出力インタフェース、２１…ユーザ識別部、２２…記事取得部、２３…ＫＬ情報取得部、２４…作成者認識部、２５…役割取得部、２６…記事スコア・重み変更部、２７…ソート部。
【図１】
2010108519.tif 000003
【図２】
2010108519.tif 000004
【図３】
2010108519.tif 000005
【図４】
2010108519.tif 000006
【図５】
2010108519.tif 000007
【図６】
2010108519.tif 000008
【図７】
2010108519.tif 000009
【図８】
2010108519.tif 000010
【図９】
2010108519.tif 000011
【図１０】
2010108519.tif 000012
【図１１】
2010108519.tif 000013
【図１２】
2010108519.tif 000014
【図１３】
2010108519.tif 000015
【図１４】
2010108519.tif 000016
【図１５】
2010108519.tif 000017
【図１６】
2010108519.tif 000018
【図１７】
2010108519.tif 000019
【図１８】
2010108519.tif 000020
【手続補正書】
【提出日】平成22年2月24日(2010.2.24)
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、複数のユーザが電子的にコミュニケーションを取ることが可能なコミュニケーションシステム、プログラム及び方法に関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
本発明は、上記事情を考慮してなされたものでありその目的は、ユーザが特別な操作をすることなく、所定のコミュニティ内でユーザがどのような役割を持っているかを導出し、当該ユーザに対してより有用な情報を提示することができるコミュニケーションシステム、プログラム及び方法を提供することにある。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
本発明の１つの態様によれば、コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段を有するコミュニケーションシステムが提供される。このコミュニケーションシステムは、前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段と、前記ナレッジリンク情報のパタンとそのパタンに対応する役割とを予め格納する役割パタン辞書格納手段と、前記記事格納手段、前記ナレッジリンク情報格納手段及び前記役割パタン辞書格納手段を参照して、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するユーザ役割導出手段と、前記導出されたユーザの役割と、当該ユーザから記事検索または記事参照が要求された場合に適用されるルールとを対応付けて格納するルールデータベース格納手段と、前記ルールデータベース格納手段を参照し、ユーザからの記事検索または記事参照の要求に合致する記事を前記導出された当該ユーザの役割に対応するルールに従って前記記事格納手段から取得する記事取得手段とを具備する。
【手続補正５】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段を有するコミュニケーションシステムにおいて、
前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段と、
前記ナレッジリンク情報のパタンとそのパタンに対応する役割とを予め格納する役割パタン辞書格納手段と、
前記記事格納手段、前記ナレッジリンク情報格納手段及び前記役割パタン辞書格納手段を参照して、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するユーザ役割導出手段と、
前記導出されたユーザの役割と、当該ユーザから記事検索または記事参照が要求された場合に適用されるルールとを対応付けて格納するルールデータベース格納手段と、
前記ルールデータベース格納手段を参照し、ユーザからの記事検索または記事参照の要求に合致する記事を前記導出された当該ユーザの役割に対応するルールに従って前記記事格納手段から取得する記事取得手段と
を具備することを特徴とするコミュニケーションシステム。
【請求項２】
前記取得された記事の一覧を画面に表示する表示手段と、
前記画面に表示される記事の数を前記ユーザの役割に応じて変える結果生成手段と
を更に具備することを特徴とする請求項１記載のコミュニケーションシステム。
【請求項３】
前記取得された記事の要約文を画面に表示する表示手段と、
前記画面に表示される記事の要約文の長さを前記ユーザの役割に応じて変える結果生成手段と
を更に具備することを特徴とする請求項１記載のコミュニケーションシステム。
【請求項４】
コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段、前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係をと関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段、前記ナレッジリンク情報のパタンとそのパタンに対応する役割とを予め格納する役割パタン辞書格納手段、及びユーザの役割と、当該ユーザから記事検索または記事参照が要求された場合に適用されるルールとを対応付けて格納するルールデータベース格納手段を有するコミュニケーションシステムにおいて、当該システムのコンピュータによって実行されるプログラムであって、
前記コンピュータに、
前記記事格納手段、前記ナレッジリンク情報格納手段及び前記役割パタン辞書格納手段を参照して、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するステップと、
前記ルールデータベース格納手段を参照し、ユーザからの記事検索または記事参照の要求に合致する記事を前記導出された当該ユーザの役割に対応するルールに従って前記記事格納手段から取得するステップと
を実行させるためのプログラム。
【請求項５】
コミュニティ内のユーザによって作成される記事であって、既に作成された記事と関係する記事を含む記事を格納する記事格納手段、前記記事格納手段に格納されている記事のうちの互いに関係する記事毎に、その記事相互間の関係と関係の種類を表すナレッジリンク情報を格納するナレッジリンク情報格納手段、前記ナレッジリンク情報のパタンとそのパタンに対応する役割とを予め格納する役割パタン辞書格納手段、及びユーザの役割と、当該ユーザから記事検索または記事参照が要求された場合に適用されるルールとを対応付けて格納するルールデータベース格納手段を有するコミュニケーションシステムが実行する方法であって、
前記記事格納手段、前記ナレッジリンク情報格納手段及び前記役割パタン辞書格納手段を参照して、当該ナレッジリンク情報の示す互いに関係する記事を作成した前記コミュニティ内のユーザの役割を導出するステップと、
前記ルールデータベース格納手段を参照し、ユーザからの記事検索または記事参照の要求に合致する記事を前記導出された当該ユーザの役割に対応するルールに従って前記記事格納手段から取得するステップと
を具備することを特徴とする方法。