JP4348357B2 - 関連文書表示装置 - Google Patents

Description

本発明は、参照関係にある文書群を整理し、その文書群をいろいろな観点から表示することによって、ユーザによる必要な情報へのアクセスを支援する技術に関する。

パソコン通信又はコンピュータネットワーク上で運用される電子会議室や電子ニュース等において、順次蓄積される文書集合の中から必要な文書をより迅速かつ簡単に見つけ出したいという要請が、従来からある。

このような要請に対して、文書集合中の各文書のタイトルを作成日順に並び替え、その結果得られるタイトルリストをユーザに掲示するという従来技術が知られている。
また、文書集合を互いに参照関係のある文書から構成される文書群に分類し、文書群中の各文書のタイトルをインデントして表示することにより、各文書の参照関係を掲示する従来技術や、文書群中の各文書の番号をツリーで表示することにより各文書の参照関係を掲示する従来技術も知られている。

更に、文書集合の中から、特定のキーワードを含む文書を全文検索し、その検索結果を羅列的に掲示する従来技術も知られている。

しかし、これらの従来技術におけるような限定された情報表示のみでは、以下に示される問題点を解決することができなかった。
１．雑多な文書集合の中から必要な文書又は必要な文書が含まれているであろう文書群を見つけ出すためには、掲示される文書のタイトルに頼るしかない。タイトルは、必ずしも文書内容を正確に表わしているとは限らないため、正確な検索が困難である。

２．タイトルのインデント表示や文書番号のツリー表示だけでは、文書群全体の構造を把握すること、及び文書群における話題の推移を把握することが困難である。
３．種々の観点から必要な文書にアクセスすることができない。

４．検索結果が多数件ある場合に、更に絞り込み検索を実行するか検索結果のリストを１件１件チェックしなければ、必要な文書にアクセスすることができない。
一方、複数の特定の文書からキーワードを抽出し、共通のキーワードを含む各文書に対し自動的に他の文書へのリンクを設定する技術が、知られている。この従来技術は、特許の公知例や研究論文等の特定文書中で互いの文献を相互参照することを可能にすることによって、関連する複数の文書を効率的に読み広げることを可能にする。

しかし、このような従来技術は、関連する文書の参照を容易にすることを目的としており、電子会議室や電子ニュース等の文書集合からの、必要な文書又は必要な文書が含まれているであろう文書群の検索の支援に、適用することはできなかった。

本発明の課題は、大量の文書が含まれる文書集合からの、必要な文書又は必要な文書が含まれているであろう文書群の検索を、支援することにある。

本発明は、上記課題を解決するため、参照関係を有する文書からなる文書群を表示する関連文書表示装置であって、参照関係を有する文書群が管理される文書データベースと、文書、および、該文書を作成した作成者が管理される管理データベースと、前記参照関係にある文書群を構成する文書数が所定値に達するか否かを判定するスレッド長判定手段と、前記スレッド長判定手段で前記文書群の前記文書数が所定値に達していると判断された場合は、前記管理データベースを参照し、該文書群の各文書を作成した作成者を識別し、該文書群に係わる作成者数を算出する作成者算出手段と、前記文書群の文書数に対する前記作成者の比率を算出し、該比率が所定値に達するか否かを判定し、該判定の結果に基づき該文書群の特徴を特定する内容特定手段と、前記文書群について前記特定した特徴に関する情報を出力装置に出力する出力手段と、を含むことを特徴とするものである。

なお、本発明は、コンピュータにより使用されたときに、上述の本発明の構成によって実現される機能と同様の機能をコンピュータに行わせるためのコンピュータ読出し可能記録媒体として構成することもできる。

本発明によれば、自動的に推定された話題と共に検索結果が表示されるため、検索結果のスレッド数が多い場合でも、利用者は検索結果の概要を容易に把握することが可能となる。

また、スレッド中の文書量が多くても、同じ作者が何度も投稿している場合がある。本発明によれば、作者を中心に見せるビユーが提供されることにより、スレッド内のキーパーソンが把握可能となるだけでなく、スレッドの全体構造もコンパクトに表示することが可能となる。

このように、本発明によれば、文書群に対して種々の観点からアクセスすることが可能となる。

以下、図面を参照しながら本発明の実施の形態について詳細に説明する。
〔全体構成〕
図１は、本発明の実施の形態が対象とする、文書集合及び文書群の例を示す図である。

この例では、コンピュータネットワーク上に、ユーザが話題別に議論を行うフォーラムと呼ばれる仮想的な公開討論会場が設けられており、各フォーラムは、会議室と呼ばれる、更に細分化された話題を扱う複数の仮想的な会場に分類されている。ユーザがこの会議室に、発言文書を投稿（アップロード）することによって、議論が進行する。フォーラム及び会議室とも、サーバコンピュータ上のストレージエリアとして構成され、それらには、上述した分類基準に従って、文書が蓄積される。また、各会議室において、互いに参照関係を有する複数の文書からなる文書群がスレッドを構成する。

ユーザが投稿する文書は、例えば、図２に示されるデータ構造を有しており、その文書の番号を示す文書番号、日付、タイトル、その文書が参照する文書の番号である参照文書番号、作者名（発言者名）等の文書の属性フィールドが記載されるヘッダ部と、文書の本体が記載される内容部とから構成されている。

本発明の実施の形態では、以下のような表示形態が可能となる。
１．キーワードビユー：会議室を構成する文書集合において、その文書集合中の各スレッド毎に、そのスレッドを構成する文書群からキーワードが抽出され、それらのキーワードが、それらの文書数及びそれらが含まれるスレッドのタイトルと合わせて、図２５に示される表示形態で表示される。

キーワードビユーによって、ユーザは、キーワードを頼りにして、雑多な文書集合の中から必要な文書が含まれているであろうスレッド（文書群）を容易に見つけ出すことが可能となる。

２．スレッドビュー：文書の参照関係、タイトル、作者名、及び行数が一目にわかる図２６に示される表示形態で、各スレッドを構成する文書群が表示される。
スレッドビューにより、スレッド全体の構造を把握し話題の推移を容易に把握することが可能となる。

３．発言者ビュー：各文書のタイトルが、発言者（作者）毎に分類され、かつ発言者が発言の多い順にソートされ、同一発言者内では日付順で、図２７に示される表示形態で、表示される。

発言者及び発言日付という観点から、文書集合（会議室）内の文書を参照することが可能となる。
４．各ビューへの検索結果の反映：ユーザが指定した検索キーワードに関連する文書が、図３２又は図３３に示される表示形態で、キーワードビユー、スレッドビュー等の表示中で強調表示される。

この結果、より正確な文書の把握が可能となる。
５．各ビューの切替え機能：上述のキーワードビユー、スレッドビュー、及び発言者ビューが任意に切替え可能とされることにより、種々の観点から必要な文書にアクセス可能となる。

以上のような表示形態を可能とする本発明の実施の形態について、詳細に説明する。
図３及び図４は、本発明の実施の形態のシステム構成図である。
フォーラム／会議室内の文書群は、所定のサーバコンピュータ上の文書群データベース３０１として、蓄積される。

文書群解析装置３０２は、文書群データベース３０１内の各会議室に対応する文書集合毎に、それに含まれる文書群の解析を行う。
集計装置３０３は、文書群解析装置３０２による解析結果に基づいて、メタインデックス３０４、スレッドインデックス３０５、及び索引ファイル４０４を生成する。

表示装置３０６は、メタインデックス３０４とスレッドインデックス３０５を用いて、キーワードビユー、スレッドビュー、又は発言者ビューの何れかの表示形態で、文書群を表示する。

また、文字列検索装置４０５は、ユーザによる検索語の指定に基づいて、索引ファイル４０４を用いながら文書群データベース３０１内の文書集合を構成する各文書に対して検索を実行する。表示装置３０６は、その検索結果を、キーワードビユー又はスレッドビューに反映させて表示する。

表示装置３０６は、メタインデックス３０４とスレッドインデックス３０５を用いて、キーワードビユー、スレッドビュー、又は発言者ビューの何れかの表示形態で、文書群を表示する。

文書群解析装置３０２は、書式解析部４０１、構造解析部４０２、及び内容解析部４０３とから構成される。
書式解析部４０１は、文書群データベース３０１内の文書集合を構成する図２のデータ構造を有する各文書のヘッダ部から、文書番号、タイトル、作者名、日付、及び参照文書番号を抽出し、また、各文書の内容部の行数を算出し、それらを、集計装置３０３を経由して、図５に示されるデータ構造を有するメタインデックス３０４に登録する。

構造解析部４０２は、書式解析部４０１が各文書から抽出した文書番号と参照文書番号に基づいて、各文書をスレッドを単位とする文書群に分類し、集計装置３０３を経由して、スレッド毎に、それを構成する文書の参照関係のリストであるスレッドインデックス３０５を作成する。

図６は、スレッドインデックス３０５のデータ構造を示す図である。各スレッド毎に、ルート文書番号と、文書数と、スレッドの構造を示すリストとが登録される。リストは、
（親文書番号 子文書番号／サブツリー子文書番号／サブツリー....）
という記述形式によって記述され、”子文書番号／サブツリー”の部分には、更に再帰的（リカーシブ）に、子リストを記述することができる。

図６に例示される２つのスレッドの各リストにより表現される各参照関係は、同図の表の右側に示される如くである。
また、構造解析部４０２は、解析したスレッドを構成する文書群を、更にタイトルを同一とするサブ文書群に分類し、各サブ文書群に色番号を付与し、各サブ文書群に含まれる文書に対応する図５のデータ構造を有するメタインデックス３０４内のエントリに、その文書が属するサブ文書群に付与された色番号を登録する。

内容解析部４０３は、構造解析部４０２によって分類されたスレッド毎に、そのスレッドを構成する文書群を１つの結合文書ファイルにまとめ、その結合文書からキーワードを抽出する。日本語文書からキーワードを抽出する技術としては、種々の公知技術を採用することができる。この場合に、キーワード抽出の精度を向上させるために、ノイズとなる文字がパターンマッチングによって除去される。また、例えば、上位所定個数のキーワードのみが抽出される。

内容解析部４０３によって抽出された各スレッドのキーワードは、集計装置３０３を経由して、そのスレッドのルート文書に対応する図５のデータ構造を有するメタインデックス３０４のエントリに、登録される。

また、内容解析部４０３は、スレッド毎に抽出したキーワードから、そのキーワードに含まれる索引語を抽出し、集計装置３０３を経由して、図７に示されるデータ構造を有する索引ファイル４０４を生成する。

この索引ファイル４０４は、前述したように、文字列検索装置４０５によって参照される。
〔文書群解析装置３０２の詳細説明〕
図８は、図４の文書群解析装置３０２内の書式解析部４０１及び構造解析部４０２が実現する制御動作を示す動作フローチャートである。

まず、書式解析部４０１は、文書群データベース３０１から新たに登録された新規文書ファイルから文書データを１行ずつ読み込みながら、その文書ファイルのヘッダ部（図２参照）から、文書番号、タイトル、作者名、日付、及び参照文書番号を抽出する（ステップ８０１→８０２→８０３→８０１のループ）。

書式解析部４０１は、ヘッダ部の抽出を終了すると、集計装置３０３を経由して、図５のデータ構造を有するメタインデックス３０４において新規エントリを生成し、そのエントリに、抽出した文書番号、タイトル、作者名、日付、及び参照文書番号を登録する（ステップ８０２→８０４）。

次に、書式解析部４０１は、上記新規文書ファイル内のヘッダ部以降の内容部（図２参照）から文書データを１行ずつ読み込みながら、文書末尾（ＥＯＦ：エンドオブファイル）が検出されるまで、内容部の行数をカウントする（ステップ８０５→８０６→８０７→８０５のループ）。

書式解析部４０１は、文書末尾を検出すると、集計装置３０３を経由して、それまでにカウントした内容部の行数を、図５のデータ構造を有するメタインデックス３０４の、現在処理中の新規文書の文書番号に対応するエントリに、登録する（ステップ８０６→８０８）。

なお、上述の行数のカウント処理において、他の文書から引用している行（例えば”> ”で始まる行）については、行数のカウントには算入しないことによって、その文書が実質的に発言している行数をカウントするように構成されてもよい。

続いて、構造解析部４０２に制御が移り、構造解析部４０２は、まず、現在処理中の新規文書の文書番号を、集計装置３０３を経由して、図６のデータ構造を有するスレッドインデックス３０５に登録する（ステップ８０９）。

図９は、上記ステップ８０９の登録動作を示す動作フローチャートである。
まず、構造解析部４０２は、現在処理中の新規文書が、或るスレッドのルート文書であるか否かを判定する（ステップ９０１）。具体的には、構造解析部４０２は、図８のステップ８０１〜８０３のループにおいて、現在処理中の新規文書から参照文書番号が検出されなかった場合に、その文書はルート文書であると判定する。

構造解析部４０２は、現在処理中の新規文書が或るスレッドのルート文書であると判定した場合には、集計装置３０３を経由して、スレッドインデックス３０５において新規エントリを生成し、そのエントリに現在処理中の新規文書の文書番号をルート文書番号として登録する（ステップ９０１→９０２）。

構造解析部４０２は、ステップ９０２の処理の後、上記エントリの文書数を１に初期設定し（ステップ９０６）、図８のステップ８０９の処理を終了する。
一方、構造解析部４０２は、現在処理中の新規文書が或るスレッドのルート文書ではないと判定した場合には、現在処理中の新規文書のヘッダ部から抽出されている参照文書番号が含まれるスレッドインデックス３０５中のエントリに、その参照文書番号を親文書番号とするリストが存在するか否かを判定する（ステップ９０１→９０３）。

構造解析部４０２は、上述のエントリに、現在処理中の新規文書のヘッダ部から抽出されている参照文書番号を親文書番号とするリストが存在すると判定した場合には、現在処理中の新規文書のヘッダ部から抽出されている文書番号を、そのリストの子文書番号として登録する（ステップ９０３→９０５）。

一方、構造解析部４０２は、上述のエントリに、現在処理中の新規文書のヘッダ部から抽出されている参照文書番号を親文書番号とするリストが存在しないと判定した場合には、そのエントリに、その参照文書番号を親文書番号とするリストを生成した上で、現在処理中の新規文書のヘッダ部から抽出されている文書番号を、そのリストの子文書番号として登録する（ステップ９０３→９０４→９０５）。

構造解析部４０２は、ステップ９０５の処理の後、上述のエントリの文書数を更新（プラス１）し（ステップ９０６）、図８のステップ８０９の処理を終了する。
上記図９の動作フローチャートによって実現される制御動作の具体例につき、図１０の説明図を用いて説明する。この図は、図６のスレッドインデックス３０５において、ルート文書番号が”００１”であるスレッドのエントリのリストが生成される過程を示すものである。

まず、文書番号”００１”のルート文書が処理される時点で、図９のステップ９０１→９０２が実行されることにより、スレッドインデックス３０５において新規エントリが生成され、そのエントリに文書番号”００１”がルート文書番号として登録され（図１０の（１））、上記エントリの文書数が１に初期設定される。

次に、文書番号”００２”の文書が処理される時点で、図９のステップ９０１→９０３→９０４→９０５→９０６が実行されることにより、スレッドインデックス３０５内のルート文書番号”００１”のエントリにおいて、文書番号”００２”の文書から抽出された参照文書番号”００１”を親文書番号とするリストが生成された後（図１０の（２））、文書番号”００２”がそのリストの子文書番号として登録され（図１０の（３）の下線部）、上記エントリの文書数が２に更新される。

次に、文書番号”００３”の文書が処理される時点で、図９のステップ９０１→９０３→９０４→９０５→９０６が実行されることにより、スレッドインデックス３０５内のルート文書番号”００１”のエントリにおいて、文書番号”００３”の文書から抽出された参照文書番号”００２”を親文書番号とするリストが生成された後（図１０の（４）の下線部）、文書番号”００３”がそのリストの子文書番号として登録され（図１０の（５）の下線部）、上記エントリの文書数が３に更新される。

次に、文書番号”００４”の文書が処理される時点で、図９のステップ９０１→９０３→９０５→９０６が実行されることにより、スレッドインデックス３０５内のルート文書番号”００１”のエントリにおいて、文書番号”００４”の文書から抽出された参照文書番号”００１”を親文書番号とするリストの子文書番号として、文書番号”００４”が登録され（図１０の（６）の下線部）、上記エントリの文書数が４に更新される。

次に、文書番号”００５”の文書が処理される時点で、図９のステップ９０１→９０３→９０４→９０５→９０６が実行されることにより、スレッドインデックス３０５内のルート文書番号”００１”のエントリにおいて、文書番号”００５”の文書から抽出された参照文書番号”００４”を親文書番号とするリストが生成された後（図１０の（７）の下線部）、文書番号”００５”がそのリストの子文書番号として登録され（図１０の（８）の下線部）、上記エントリの文書数が５に更新される。

最後に、文書番号”００６”の文書が処理される時点で、図９のステップ９０１→９０３→９０４→９０５→９０６が実行されることにより、スレッドインデックス３０５内のルート文書番号”００１”のエントリにおいて、文書番号”００６”の文書から抽出された参照文書番号”００５”を親文書番号とするリストが生成された後（図１０の（９）の下線部）、文書番号”００６”がそのリストの子文書番号として登録され（図１０の（１０）の下線部）、上記エントリの文書数が６に更新される。

以上説明した図８のステップ８０９の処理の後、構造解析部４０２は、現在処理中の新規文書について色番号を決定し、その色番号を図５のデータ構造を有するメタインデックス３０４中の上記新規文書の文書番号に対応するエントリに登録する処理を実行する（図８のステップ８１０）。

図１１は上記ステップ８１０の登録動作を示す動作フローチャートである。なお、この登録動作では、図１２に示されるデータ構造を有するカラーテーブルが使用される。このテーブルは、特には図示しない記憶装置に記憶される。

まず、構造解析部４０２は、現在処理中の新規文書が、或るスレッドのルート文書であるか否かを判定する（ステップ１１０１）。具体的には、構造解析部４０２は、図８のステップ８０１〜８０３のループにおいて、現在処理中の新規文書から参照文書番号が検出されなかった場合に、その文書はルート文書であると判定する。

構造解析部４０２は、現在処理中の新規文書が或るスレッドのルート文書であると判定した場合は、そのルート文書の文書番号に対応するエントリを、図１２のデータ構造を有するカラーテーブルに登録し、そのエントリに現在処理中の新規文書から抽出された文書番号及びタイトル（図８のステップ８０４参照）と、初期色番号を登録する（ステップ１１０１→１１０２→１１０３）。図１２の例では、ルート文書番号”００１”の色番号”＃１”に対応するエントリが登録され、そのタイトルはメイントピックとなり、また、そのエントリの文書番号フィールドには、当初はルート文書番号”００１”のみが登録される。

その後、構造解析部４０２は、図５のデータ構造を有するメタインデックス３０４中の上記新規文書の文書番号に対応するエントリに、ステップ１１０３で登録した初期色番号を登録し（ステップ１１０３→１１１０）、図８のステップ８１０の処理を終了する。

一方、構造解析部４０２は、現在処理中の新規文書が或るスレッドのルート文書ではないと判定した場合には、現在処理中の新規文書から抽出されたタイトル（図８のステップ８０４参照）が、”Ｒｅ：”等の参照記号を含んでいるか否かを判定する（ステップ１１０１→１１０４）。

構造解析部４０２は、現在処理中の新規文書から抽出されたタイトルが参照記号を含んでいると判定した場合はそのタイトルから参照記号を削除し（ステップ１１０４→１１０５）、現在処理中の新規文書から抽出されたタイトルが参照記号を含んではいないと判定した場合にはステップ１１０５は実行しない。

その後、構造解析部４０２は、図１２のデータ構造を有するカラーテーブル中の現在処理中の新規文書が属するスレッドに対応する何れかのエントリに、現在処理中の新規文書から抽出され参照記号を含まないタイトルと同じタイトルが登録されているか否かを判定する（ステップ１１０６）。現在処理中の新規文書が属するスレッドとそのルート文書番号は、図８のステップ８０９の処理において図６のデータ構造を有するスレッドインデックス３０５のエントリが決定される際に検出されるため、そのルート文書番号からカラーテーブル中のエントリが決定される。例えば、現在処理中の新規文書が文書番号”００２”の文書である場合には、図１２に示されるカラーテーブルにおいて、ルート文書番号”００１”に属するエントリが検出される。

構造解析部４０２は、図１２のデータ構造を有するカラーテーブル中の現在処理中の新規文書が属するスレッドに対応する何れかのエントリに、現在処理中の新規文書から抽出され参照記号を含まないタイトルと同じタイトルが登録されていると判定した場合には、そのエントリの文書番号フィールドに、現在処理中の新規文書の文書番号を登録する（ステップ１１０６→１１０７）。例えば、現在処理中の新規文書が文書番号”００２”の文書である場合には、図１２に示されるカラーテーブルにおいて、ルート文書番号”００１”に属し色番号”＃１”が登録されているエントリの文書番号フィールドに、文書番号”００２”が登録される。

その後、構造解析部４０２は、図５のデータ構造を有するメタインデックス３０４中の上記新規文書の文書番号に対応するエントリに、ステップ１１０７で登録が行われたカラーテーブル中のエントリに設定されている色番号を登録し（ステップ１１０７→１１１０）、図８のステップ８１０の処理を終了する。

一方、構造解析部４０２は、図１２のデータ構造を有するカラーテーブル中の現在処理中の新規文書が属するスレッドに対応する何れのエントリにも、現在処理中の新規文書から抽出され参照記号を含まないタイトルと同じタイトルが登録されてはいないと判定した場合は、カラーテーブルにおいて上記スレッドに対応する新たなエントリを作成し（ステップ１１０８）、その作成したエントリに、そのスレッド内で新たな色番号と、現在処理中の新規文書から抽出された文書番号及びタイトル（図８のステップ８０４参照）を登録する（ステップ１１０６→１１０８→１１０９）。例えば、現在処理中の新規文書が文書番号”００３”の文書である場合には、図１２のカラーテーブルにおいて、ルート文書番号”００１”に属する新たなエントリが作成され、そのエントリに、色番号”＃２”と、文書番号”００３”の文書のタイトルと、文書番号”００３”とが登録される。このタイトルは、ルート文書番号”００１”のタイトルであるメイントピックに対して、サブトピック１となる。

その後、構造解析部４０２は、図５のデータ構造を有するメタインデックス３０４中の上記新規文書の文書番号に対応するエントリに、ステップ１１０９でカラーテーブル中の新たなエントリに設定された新たな色番号を登録し（ステップ１１０９→１１１０）、図８のステップ８１０の処理を終了する。

内容解析部４０３は、図６のデータ構造を有するスレッドインデックス３０５を参照することにより、前述したように、スレッド毎に、そのスレッドを構成する文書群を１つの結合文書ファイルにまとめ、その結合文書からキーワードを抽出する。この結果、抽出された各スレッドのキーワードは、そのスレッドのルート文書に対応する図５のデータ構造を有するメタインデックス３０４のエントリに、登録される。

〔表示装置３０６の詳細説明〕
表示装置３０６は、前述したように、図５のデータ構造を有するメタインデックス３０４と図６のデータ構造を有するスレッドインデックス３０５を用いて、キーワードビユー、スレッドビュー、又は発言者ビューの何れかの表示形態で、文書群を表示することができる。

ここで例えば、図４のシステムが、ホームページの表示を制御するＷｅｂサーバに接続されるように構成されれば、ユーザは、パーソナルコンピュータ等の手元の端末上のＷｅｂブラウザアプリケーションから上記Ｗｅｂサーバに接続して特定のフォーラムの特定の会議室にログインした後に、所定の各ＧＵＩ（グラフィックユーザインタフェース）ボタンをマウス装置等でクリックすることによって、キーワードビユー、スレッドビュー、又は発言者ビューを切り替えて表示させることができる。

より具体的には、表示装置３０６は、Ｗｅｂサーバに対して例えばＣＧＩ（コモンゲートウエイインタフェース）アプリケーションとして機能し、Ｗｅｂサーバから引き渡されたユーザからのリクエストに応答して、キーワードビユー、スレッドビュー、又は発言者ビュー等の各ビューを表現するＨＴＭＬ（ハイパーテキストマークアップ言語）による文書データを生成し、それをＷｅｂサーバに引き渡す。そして、これらのＨＴＭＬ文書データをＷｅｂサーバがユーザにインターネット等のコンピュータネットワークを経由して返信することにより、ユーザの端末上のＷｅｂブラウザアプリケーションに、上記ビューが表示される。

まず、表示装置３０６が実現するキーワードビユーの表示動作について説明する。
前述したようにキーワードビユーにおいては、スレッド毎に、そのスレッドを構成する文書群から抽出されているキーワードが、その文書群の文書数及びそのスレッドのタイトルと合わせて、図２５に示される表示形態で表示される。

図１３は、表示装置３０６が実行するキーワードビユーの表示動作を示す動作フローチャートである。。まず、表示装置３０６は、図５のデータ構造を有するメタインデックス３０４のファイルを読み込む（ステップ１３０１）。

次に、表示装置３０６は、メタインデックス３０４のファイルから１エントリずつデータを読み込みながら、ルート文書が登録されているエントリを検索する（ステップ１３０１→１３０２→１３０１のループ）。各エントリがルート文書が登録されているエントリであるか否かは、各エントリの参照文書番号フィールドの値が無効なデータ値であるか否かによって判定することができる。

表示装置３０６は、ルート文書が登録されているエントリを検出すると、そのルート文書番号を、そのルート文書番号に対応する文書群データベース３０１内のルート文書を表示するためのアプリケーションへの統一されたアドレス情報であるＵＲＬ（Uniform Resource Locator）がＨＲＥＦ属性の値として指定されるアンカータグに変換する（ステップ１３０２→１３０３）。

次に表示装置３０６は、図６のデータ構造を有するスレッドインデックス３０５において、上記ルート文書番号に対応するエントリを参照することにより、そのスレッドに含まれる文書数（子文書数）を取得する（ステップ１３０４）。

そして、表示装置３０６は、図５のデータ構造を有するメタインデックス３０４において、上記ルート文書が登録されているエントリから、タイトル（メイントピック）と、キーワードとを抽出し、それらと、ステップ１３０３で変換されたアンカータグ形式のルート文書番号、及びステップ１３０４で取得した子文書数からなるデータ列を１テーブルレコードとして含むＨＴＭＬテーブル文書データを作成する（ステップ１３０５）。

続いて、表示装置３０６は、メタインデックス３０４のファイルから文書末尾（ＥＯＦ）を検出するまで、上記ステップ１３０１〜１３０５の一連の処理を繰り返し実行することにより、各スレッド毎のＨＴＭＬテーブル文書データを作成する（ステップ１３０６→１３０１）。

表示装置３０６は、メタインデックス３０４のファイルから文書末尾を検出すると（ステップ１３０６の判定がＹＥＳ）、最終的に得られたＨＴＭＬテーブル文書データをＷｅｂサーバに引き渡して、キーワードビユーの表示動作を終了する。この結果、ユーザの端末のＷｅｂブラウザアプリケーション上に、図２５に例示されるようなテーブル形式で、キーワードビユーが表示される。

ユーザは、キーワードビユー上の各スレッド毎のキーワードを頼りにして、雑多な文書集合の中から必要な文書が含まれているであろうスレッドを容易に見つけ出すことが可能となる。

また、ユーザは、ルート文書に対応するアンカーをマウス装置等でクリックすることによって、所望のスレッドのルート文書に即座にアクセスすることができる。
上述のキーワードビユーの表示動作において、子文書数に応じて、各スレッドのテーブルレコードを色分けして表示するように構成されてもよい。これによって、ユーザは、スレッド毎の発言数を一目で判別することができる。

続いて、表示装置３０６が実現するスレッドビューの表示動作について説明する。
前述したように、スレッドビューにおいては、文書の参照関係、タイトル、作者名、及び行数が一目にわかる図２６に示される表示形態で、各スレッドを構成する文書群が表示される。

図２６において、スレッドの参照関係及び話題の推移が色付きツリーによって表示される。各ツリーのノードは、各文書に対応し、その文書の作者名の先頭文字（２バイト）とその文書の行数を用いて、作者名［行数］の形式で表示される。また、各ノードの前後には、”＊”、”＋”、”＝”、又は”．”等の記号が付される。これらの記号の意味は、下記の通りである。

”＊” この記号が付される文書がルート文書である。
”＋” この記号が付される文書が参照している文書が他の文書によっても参照されている。

”＝” この記号が付される文書を参照している文書が存在する。
”．” この記号が付される文書を参照している文書が存在しない。また、図２６において、”Ｍａｉｎ Ｔｏｐｉｃ：”に続いてそのスレッドのルート文書のタイトルが表示され、”Ｓｕｂ Ｔｏｐｉｃ：”に続いてそのスレッド中に現れるルート文書のタイトル以外のタイトルが表示される。そして、各タイトルは色分けされ、各タイトルと同じタイトル（参照記号を除く）を有する文書に対応するノードは、そのタイトルの色と同じ色で表示される。

これによって、ユーザは、スレッド全体の構造を把握しスレッド内の話題の推移を一目で把握することが可能となる。
更に、各ノードはアンカーとして表示される。これにより、ユーザは、各ノードをマウス装置等によってクリックすることにより、そのノードに対応する文書に即座にアクセスすることができる。

図１４は、表示装置３０６が実行するスレッドビユーの表示動作を示す動作フローチャートである。
まず、表示装置３０６は、図６のデータ構造を有するスレッドインデックス３０５のファイルから、１つのスレッドに対応する１つのエントリ（１行）のリストと、そのスレッドに含まれる文書数を、読み込む（ステップ１４０１）。例えば、図６のデータ構造を有するスレッドインデックス３０５において、ルート文書番号”００１”に対応するリストとして、
(001 (002 003) (004 (005 006)))
が読み込まれ、文書数として”６”が読み込まれる。

次に、表示装置３０６は、読み込んだリストから、例えば図６の表の右側に示されるスレッドのツリー構造を復元する（ステップ１４０２）。このツリー構造を表現するために、表示装置３０６は、例えば図１５に示されるような配列データを生成する。

次に、表示装置３０６は、読み込んだリストの各ノードを構成する文書番号毎に、その文書番号に対応する図５のデータ構造を有するメタインデックス３０４のエントリを抽出し、そのエントリから、作者名、行数、色番号、及びタイトルを抽出する（ステップ１４０３）。これらの抽出されたデータは、上記各ノードに対応付けて記憶される。

次に、表示装置３０６は、ステップ１４０１で読み込んだ文書数と、ステップ１４０３で抽出した各ノードの色番号とから、スレッドビューの先頭で表示される各タイトルの色を決定する（ステップ１４０４）。この動作は、各色番号に実際の色をマッピングする動作として実現される。

次に、表示装置３０６は、スレッドに含まれるルート文書のタイトルとその他のタイトルを、”Ｍａｉｎ Ｔｏｐｉｃ：”及び”Ｓｕｂ Ｔｏｐｉｃ：”に続けて表示するためのＨＴＭＬ文書を作成する。この場合に、各タイトルは、前述した構造解析部４０２が管理する図１２に示されるカラーテーブルの上記スレッドに属する各エントリから順次読み出され、同時に順次読み出される各色番号からステップ１４０４で決定された各色が算出され、その各色での表示が順次指定される。各色は、ＨＴＭＬ文書の色指定命令（ <font color= > タグ等）によって指定される。

最後に、表示装置３０６は、ステップ１４０２で復元したスレッドのツリー構造を示す配列データを構成する左端のノードの文書番号から順に処理することにより、そのツリー構造を表示するためのＨＴＭＬ文書を作成する（ステップ１４０６）。この場合、前述したように、表示装置３０６は、ステップ１４０３で抽出した各ノードの作者名、行数、及び色番号に基づいて、ツリー構造の各ノードの文書番号を、そのノードに対応する文書の作者名の先頭文字（２バイト）とその文書の行数とからなる表示データ、
作者名［行数］
に変換し、更に、その表示データをそのノードの色番号に対応する色で表示させるためのＨＴＭＬ文書データを生成する。色番号と実際の色との対応関係は、ステップ１４０４で決定された対応関係に従う。また、前述したように、表示装置３０６は、各ノードに対応する上記表示データの前後に、その接続関係に基づいて、”＊”、”＋”、”＝”、又は”．”等の記号を表示するためのＨＴＭＬ文書データを生成する。ここで、ツリー構造をそのままの形式で表示可能とするために、例えば、ＨＴＭＬにおける制御用タグであるプリフォーマットタグ <PRE>が使用される。更に、上記ノード毎の表示データは、そのノードに対応する文書群データベース３０１内の文書データを表示するためのアプリケーションへのＵＲＬがＨＲＥＦ属性の値として指定されるアンカータグとして生成される。

続いて、表示装置３０６は、スレッドインデックス３０５のファイルから文書末尾（ＥＯＦ）を検出するまで、上記ステップ１４０１〜１４０６の一連の処理を繰り返し実行することにより、各スレッド毎のビューデータを作成する（ステップ１４０７→１４０１）。

表示装置３０６は、スレッドインデックス３０５のファイルから文書末尾を検出すると（ステップ１４０７の判定がＹＥＳ）、最終的に得られたＨＴＭＬテーブル文書データをＷｅｂサーバに引き渡して、スレッドビユーの表示動作を終了する。この結果、ユーザの端末のＷｅｂブラウザアプリケーション上に、図２６に例示されるような形式で、スレッドビユーが表示される。

次に、表示装置３０６が実現する発言者ビューの表示動作につき説明する。前述したように、発言者ビューにおいては、各文書のタイトルが、発言者（作者）毎に分類され、かつ発言者が発言の多い順にソートされ、同一発言者内では日付順で、図２７に示される表示形態で、表示される。

図１６は、表示装置３０６が実行する発言者ビユーの表示動作を示す動作フローチャートである。
表示装置３０６は、発言者ビューを実現するために、図１７のデータ構造を有する作者配列データを使用する。そして、表示装置３０６は、発言者ビューの表示開始時に、この作者配列データを初期化する（ステップ１６０１）。

次に、表示装置３０６は、図５のデータ構造を有するメタインデックス３０４のファイルから１つのエントリのデータを読み込む（ステップ１６０２）。
次に、表示装置３０６は、このエントリから抽出される作者名の作者が、作者配列データに含まれていない作者であるか否かを判定する（ステップ１６０３）。

表示装置３０６は、上記エントリから抽出される作者名の作者が、作者配列データに含まれていない作者である場合には、作者配列データに新しい作者項目を追加する（ステップ１６０３→１６０４）。表示装置３０６は、上記エントリから抽出される作者名の作者が、作者配列データに含まれている作者である場合には、ステップ１６０４の処理は実行しない。

次に、表示装置３０６は、作者配列データ中の該当する作者項目に、上記エントリから抽出される文書番号を登録する（ステップ１６０５）。
続いて、表示装置３０６は、メタインデックス３０４のファイルから文書末尾（ＥＯＦ）を検出するまで、上記ステップ１６０２〜１６０５の一連の処理を繰り返し実行することにより、メタインデックス３０４に登録されている全ての文書番号を、作者別に作者配列データに登録する。

表示装置３０６は、メタインデックス３０４のファイルから文書末尾を検出すると（ステップ１６０６の判定がＮＯ）、作者配列データ中の各作者項目を、それぞれの項目に登録されている文書番号の数、即ち各作者毎の発言文書数に基づいてソートする（ステップ１６０７）。

続いて、表示装置３０６は、作者配列データ中の同一作者項目内で、文書番号を、それに対応するメタインデックス３０４中のエントリから抽出される日付に基づいてソートする（ステップ１６０８）。

最後に、表示装置３０６は、上記ステップ１６０７及び１６０８でのソートの結果得られる作者配列データの各作者項目毎に、作者名と、その項目内の各文書番号に対応するメタインデックス３０４中のエントリから抽出される日付及びタイトルを表示するためのＨＴＭＬテーブル文書データを生成し、それをＷｅｂサーバに引き渡して、発言者ビューの表示動作を終了する。この結果、ユーザの端末のＷｅｂブラウザアプリケーション上に、図２７に例示されるようなテーブル形式で、発言者ビューが表示される。

ユーザは、発言者ビュー上で、発言者及び発言日付という観点から、文書集合（会議室）内の文書を参照することが可能となる。
また、或る発言者の発言を時間を追って参照したり、会議室内で多くの発言をするリーダー的な発言者を一目で確認することができる。

〔表示装置３０６の他の表示態様〕
次に、上記各ビューの表示動作以外に表示装置３０６が実現する各表示動作の態様について説明する。

まず、表示装置３０６が実現する発言内容表示の動作につき説明する。前述したように、ユーザは、キーワードビユーにおけるそれぞれのスレッド上のアンカー又はスレッドビューにおける各ノード上のアンカーを、マウス装置等でクリックすることにより、各スレッドのルート文書又は各ノードに対応する文書等に、即座にアクセスすることができる。

ユーザによってこれらの操作が実行された場合には、Ｗｅｂサーバから指示によって、表示装置３０６によって実行される図１８に示される動作フローチャートの処理が例えばＣＧＩとして起動される。この場合、この処理には、ユーザによって指定されたアンカータグに含まれる文書番号の情報が引き渡される。

この結果まず、表示装置３０６は、上記文書番号の情報を読み込んだ後（ステップ１８０１）、ヘッダ部に上記読み込んだ文書番号と同じ文書番号を含んでいる文書ファイルを読み込むまで、文書群データベース３０１からの文書ファイルの読込みを行う（ステップ１８０２→１８０３→１８０２のループ）。

表示装置３０６は、ヘッダ部に上記読み込んだ文書番号と同じ文書番号を含んでいる文書ファイルを読み込むと（ステップ１８０３の判定がＹＥＳ）、新しい文書のヘッダ部を読み込むまで、ステップ１８０４〜１８０９のループにより、上記文書ファイルから１行ずつデータを読み込み、そのデータを１行分のＨＴＭＬ文書データに変換し、そのＨＴＭＬ文書データをＷｅｂサーバに出力する（ステップ１８０８）。

この場合に、各行のデータが他の文書等へのＵＲＬを含んでいる場合には、表示装置３０６は、そのデータを上記ＵＲＬがＨＲＥＦ属性の値として指定されるアンカータグに変換した上で出力する（ステップ１８０４→１８０５）。

この結果、ユーザは、発言内容の表示中のアンカーを更にマウス装置等によってクリックすることにより、更に他のリソースにジャンプすることができる。
また、各行のデータが他の文書の行を引用したコメント行である場合には、表示装置３０６は、そのデータの色を変換するタグを追加した上で出力する（ステップ１８０６→１８０７）。

この結果、ユーザは、コメント行を一目で判別することができる。表示装置３０６は、該当する文書データの出力処理を終了すると、上記文書を含むスレッドのツリー構造を表示するＨＴＭＬ文書データを生成し出力して、発言内容表示の動作を終了する（ステップ１８０９→１８１０）。この処理は、前述した図１４の動作フローチャートで示されるスレッドビューの表示動作と同様にして実現できる。

以上の表示動作の結果、ユーザの端末のＷｅｂブラウザアプリケーション上には、例えば図２８に示されるように、表示画面の上半分に発言内容が表示され、表示画面の下半分にはその発言内容の文書を含むスレッドのツリー構造が表示される。なお、この表示画面には、図２８に示されるように、キーワードビユーやスレッドビューを表示させるためのアンカーや、検索を実行するためのアンカー等を同時に表示させることもできる。

これらのビューの切替え機能により、例えば、キーワードビユー → スレッドビュー → 発言内容表示 → 発言者ビュー 発言内容表示 → スレッドビュー → ・・・ というように、会議室内の文書（発言）をユーザの嗜好に応じて横断的に参照してゆくことが可能となる。

次に、表示装置３０６が実現する作者別／日付別色分け表示の動作につき説明する。図１９は、その動作を示す動作フローチャートである。
まず、表示装置３０６は、メタインデックス３０４及びスレッドインデックス３０５に基づいて、図２０(a) に示されるように作者項目毎に文書番号が分類された作者配列データと、図２０(b) に示されるように日付項目毎に文書番号が分類された日付配列データとを予め作成する。これらの作成処理の詳細は省略するが、前述した図１６の動作フローチャートと同様の処理によって実現できる。そして、作者配列データ中の各作者項目又は日付配列データ中の各日付項目に、それぞれ異なる色が割り当てられる。この色の割当ては、作者項目毎の作者の総数又は日付項目毎の日付の総数から決定される。

次に、表示装置３０６は、ユーザの指定に基づく項目選択ボタン情報をＷｅｂサーバを経由して取得し、作者ボタンが押されたか日付選択ボタンが押されたかを判定する（ステップ１９０２、１９０４、図２９参照）。

表示装置３０６は、作者ボタンが押されたと判定した場合には、図２０(a) に示される作者配列データを参照することにより、スレッドツリーの表示データを作成し出力する（ステップ１９０２→１９０３）。この処理は、前述した図１４の動作フローチャートと同様の処理によって実現されるが、この場合に、ツリーの各ノードは、そのノードに対応する作者名に対応する作者配列データ中の作者項目に割当てられている色で表示される。

一方、表示装置３０６は、日付選択ボタンが押されたと判定した場合には、図２０(b) に示される日付配列データを参照することにより、スレッドツリーの表示データを作成し出力する（ステップ１９０４→１９０５）。この処理も、前述した図１４の動作フローチャートと同様の処理によって実現されるが、この場合に、ツリーの各ノードは、そのノードに対応する日付に対応する日付配列データ中の日付項目に割当てられている色で表示される。

以上の表示動作の結果、例えばユーザが作者ボタンを押した場合には、ユーザの端末のＷｅｂブラウザアプリケーション上には、例えば図２９に示されるように、作者別に色分けされたスレッドのツリーが表示され、ユーザは同一の作者の文書を一目で確認することができる。

次に、表示装置３０６が実現するスレッドビューを使った検索結果の強調表示の動作につき説明する。図２１はその動作を示す動作フローチャートである。
まず、表示装置３０６は、検索後入力フォーム画面を表示するためのＨＴＭＬ文書データを生成し出力する（ステップ２１０１）。この結果、ユーザの端末のＷｅｂブラウザアプリケーション上には、例えば図３０に示されるような検索入力フォーム画面が表示される。ユーザは、この検索入力フォームに検索語を入力して検索の実行を指定する。

上記検索入力フォームに入力された検索語は、Ｗｅｂサーバを経由して文字列検索装置４０５（図４）に引き渡される。文字列検索装置４０５は、ユーザによる検索語の指定に基づいて、索引ファイル４０４を用いながら文書群データベース３０１内の指定されたスレッドを構成する各文書に対して全文検索を実行し、その検索語を含む文書番号を出力する（ステップ２１０２、２１０３）。

表示装置３０６は、上記検索語を含む文書番号を受け取ると、その文書番号を含むスレッドのツリー構造を表示するＨＴＭＬ文書データを、前述した図１４の動作フローチャートと同様の処理によって表示する。この場合に、表示装置３０６は、上記文書番号を含むノードの色を強調色に指定する（ステップ２１０４、２１０５）。

この結果、ユーザの端末のＷｅｂブラウザアプリケーション上において、例えば図３１に示されるような検索結果に基づくスレッドビューの強調表示が実現される。これにより、ユーザは、スレッドの構造を把握しつつ、検索を実行することができる。

次に表示装置３０６が実現するキーワードビユーを使った検索結果の強調表示の動作につき説明する。図２２はその動作を示す動作フローチャートである。
まず、表示装置３０６は、図２１のステップ２１０１の場合と同様に、検索後入力フォーム画面を表示するためのＨＴＭＬ文書データを生成し出力する（ステップ２２０１）。ユーザは、この検索入力フォームに検索語を入力して検索の実行を指定する。

上記検索入力フォームに入力された検索語は、Ｗｅｂサーバを経由して文字列検索装置４０５（図４）に引き渡される。文字列検索装置４０５は、ユーザによる検索語の指定に基づいて、索引ファイル４０４を用いながら文書群データベース３０１内の指定された会議室を構成する各文書に対して全文検索を実行し、その検索語を含む文書番号を出力する（ステップ２２０２、２２０３）。

表示装置３０６は、上記検索語を含む文書番号を受け取ると、まず、図６のデータ構造を有するスレッドインデックス３０５を参照して、上記文書番号を含むエントリに対応するルート文書番号を抽出する（ステップ２２０４）。

続いて、表示装置３０６は、指定された会議室に関するキーワードビユーを表示するＨＴＭＬ文書データを、前述した図１３の動作フローチャートと同様の処理によって表示する。この場合に、表示装置３０６は、ステップ２２０４で抽出されたルート文書番号に対応するスレッドのタイトル又はその表示エリア全体の色を強調色に指定し、更に、表示されるキーワード中に検索語が含まれている場合には、そのキーワードも強調色に指定する（ステップ２２０５、２２０６、２２０７）。

この結果、ユーザの端末のＷｅｂブラウザアプリケーション上において、例えば図３２に示されるような検索結果に基づくキーワードビユーの強調表示が実現される。これにより、ユーザは、検索語を含むスレッドを一目で把握することができる。

なお、表示装置３０６は、検索結果の文書番号とそれに対応するタイトルを、例えば図３３に示されるように羅列して表示するように構成することも可能である。
最後に、表示装置３０６が実現するサブトピック毎のキーワードビユーの表示動作について説明する。

前述したキーワードビユーは、スレッド毎にキーワードを表示するものであった。これに対して、サブトピック毎のキーワードビユーでは、１つのスレッド内のサブトピック毎に、キーワードを抽出して表示することができる。

この動作において、表示装置３０６は、図２４のデータ構造を有するサブトピックインデックスを使用する。サブトピックインデックスは、図１２に示されるカラーテーブルのデータ構造に対して、キーワードフィールドが追加されたデータ構造を有する。

サブトピックインデックスは、実質的には前述したカラーテーブルを置き換えるものであるため、サブトピックインデックスにおけるキーワードフィールド以外のフィールドの内容は、構造解析部４０２による前述した図８のステップ８１０の処理によって予め登録されている。この場合、図８のステップ８１０の処理の説明において前述したように、カラーテーブルであるサブトピックインデックスには、ルート文書番号毎（スレッド毎）に、それに含まれるルート文書のタイトルを示すメイントピックと、それ以外の文書のタイトルを示すサブトピックのそれぞれに対応するエントリが得られる。表示装置３０６は、この登録内容を利用する。

図２３は、表示装置３０６が実現するサブトピックからのキーワード抽出の制御を示す動作フローチャートである。
まず、表示装置３０６は、各スレッドについて、サブトピックインデックス内のそのスレッドに含まれる各エントリに登録されている文書番号に基づいて、メイントピック及びサブトピック単位で、それぞれに属する文書群を各結合文書ファイルにまとめ（ステップ２３０１）、その結果得られる各結合文書ファイルを内容解析部４０３（図４）に入力する（ステップ２３０２）。

内容解析部４０３は、各結合文書ファイル別にキーワードを抽出し、その結果を表示装置３０６に返す。表示装置３０６は、内容解析部４０３から返された各結合文書ファイル別のキーワードを、サブトピックインデックス内の上記各結合文書ファイルに対応するエントリのキーワードフィールドに登録する（ステップ２３０３）。

以上のようにして、各スレッドについて、メイントピック及びサブトピック単位で、それぞれに属する文書群からキーワードが抽出される。
その後は、表示装置３０６は、サブトピックインデックスの内容に基づいて、ユーザにより指定されたスレッドに関して、そのスレッドのメイントピック及びサブトピック単位で、それぞれのタイトルとそれぞれに属するキーワードを表示するためのＨＴＭＬ文書データを生成し出力する。

この結果、ユーザの端末のＷｅｂブラウザアプリケーション上には、例えば、図３４に示されるような形式で、サブトピック毎のキーワードビユーが表示される。これにより、ユーザは、キーワードによるより精密なトピックの絞込みを行うことができる。

〔本発明の他の実施の形態（第２の実施の形態）〕
次に、本発明の他の実施の形態（以下、第２の実施の形態という）について説明する。
〔本発明の第２の実施の形態が実現する機能〕
まず、第２の実施の形態では、以下の３つの機能が実現される。

１．狭い画面の中でのスレッドの全体構造の把握機能：
スレッドのツリーが縮退（curtail ）させられることにより、ある大きさの画面内でツリー構造の全体表示が可能となる。第２の実施の形態では、ＴＴＹキャラクタ端末上での表示を例に説明する。

キャラクタ端末では、１行に１ノードが表示されるため、ｎ行の画面内にはｎ個のノードを描画することができる。描画されるノードの選択基準としては、以下のものがある。
・そのノードを参照している子ノードの個数。

・検索結果として得られる、そのノードを参照している子ノードの個数。
・ルートノード又は親ノードと異なるタイトルを持つノード。
２．スレッド内の話題の進行の推測機能：
「質問−答−お礼」といった特定の会話パターンが検出され、その情報が表示・検索に使用されることにより、効率の良い情報アクセスが可能となる。

より具体的には、第２の実施の形態では、文書の属性情報（タイトル、作者、参照関係）と、文書の内容を特徴づける特定の文章パターンが推測されることにより、スレッド内の話題パターンが抽出される。

３．利用者の発言パターンの視覚化：
ネットワークニュースでは、読んでいる人に対して発言する人の割合は非常に少ない。大きなスレッドであっても実は数人の人が論争しているだけという場合も少なくない。また、特定のニュースグループにおいて、有用な情報を発信する人が決まっている場合も多い。そこで、第２の実施の形態では、記事を投稿する利用者の観点から、ニュースやスレッドが整理されることにより、新たなビューが提供される。

より具体的には、第２の実施の形態では、ニュースグループ内の投稿履歴と、前述の話題推測機能に基づいて、利用者を観点とするビューが提供される。
〔本発明の第２の実施の形態の全体構成〕
図３５は、本発明の第２の実施の形態の構成図である。

まず、検索フェーズの前の準備フェーズにおいては、以下の動作が実行される。
処理装置３５０１内の文書取得部３５０２は、ネットワークを通じて、参照関係のある文書群を取得し、二次記憶装置３５０３内に格納する。

内容推定部３５０４は、二次記憶装置３５０３に格納されている文書群の文書内容、文書付随情報、文書間の参照関係に基づいて、表示用インデックス３５０５を作成する。
検索エンジン３５０６は、二次記憶装置３５０３に格納されている文書群の文書内容に基づいて、検索用インデックス３５０７を作成する。

例えばネットワークニュースサービスでは、文書が随時投稿されてゆく。そのため、上記の準備フェーズは、例えば一日に一度のように定期的に実行され、二次記憶装置３５０３には、常に最新の文書群が格納される。

検索フェーズの実行時には、以下の動作が実行される。
利用者は、入力装置３５０９から入力指示を行う。入力される情報には、検索キーワードと、検索結果を表示させるためのビューの種類、ビューの表示領域の大きさが含まれる。

ビュー生成部３５０８は、入力装置３５０９からの入力指示に基づいて、検索エンジン３５０６を呼び出し、それに対して二次記憶装置３５０３に格納されている文書群の中から上記入力指示に対応する文書群を検索させる。

ビュー生成部３５０８は、表示用インデックス３５０５を利用して、検索エンジン３５０６が検索した文書群を表示するための結果ビューを作成し、それを表示装置３５１０に出力する。この場合に、後述するスレッド木の縮退処理が実行される。

以上の動作は、利用者との間の対話処理に基づいて実行される。つまり、利用者は、結果表示を見て、検索キーワードを追加又は変更し、或いは、結果ビューを切り替える。
〔表示用インデックス３５０５の構造〕
第２の実施の形態において、検索前の準備フェーズでは、以下の種類のインデックスが作成される。

１．ユーザインデックス：
このインデックスは、ユーザの管理を行うためのインデックスであり、図３６に示されるように、エントリ毎に、下記情報を保持する。

・ユーザＩＤ（ＵｓｅｒＩＤ）：そのエントリに対応するユーザのＩＤ（キー）である。
・名前：そのエントリに対応するユーザの名前である。

・略称：そのエントリに対応するユーザの略称である。
・発言数（回答数）：そのエントリに対応するユーザの、会議室内における発言の総数と、Ｑ and Ａパターンにおける回答文書の数である。

２．文書インデックス：
このインデックスは、文書毎の情報管理を行うためのインデックスであり、図３７に示されるように、エントリ毎に、下記情報を保持する。

・文書ＩＤ：そのエントリに対応する文書のＩＤ（キー）である。
・ユーザＩＤ（ＵｓｅｒＩＤ）：そのエントリに対応する文書を作成したユーザのＩＤ（キー）である。

・タイトル：そのエントリに対応する文書のタイトルである。
・日付：そのエントリに対応する文書の作成日である。
・参照子孫数：そのエントリに対応する文書を参照する文書の総数である。

・ルートまでのパス：そのエントリに対応する文書が参照する先頭記事からその文書までのパスである。
・タイトルの識別番号：そのエントリに対応する文書のタイトルが、その文書が含まれるスレッド（文書群）中の何番目のタイトルであるかを示す番号である。

・記事種別：そのエントリに対応する文書が、Ｑand Ａパターンに含まれる場合に、その文書がＱ（質問）文書、Ａ（答）文書、又はＴ（お礼）文書の何れにあたるかを示す情報である。

３．スレッドインデックス：
このインデックスは、スレッド毎の情報管理を行うためのインデックスであり、図３８に示されるように、エントリ毎に、下記情報を保持する。

・スレッドＩＤ：そのエントリに対応するスレッドのＩＤ（キー）である。
・スレッドの木構造：そのエントリに対応するスレッド内の文書の参照関係を文書ＩＤのリストで表現したものである。

・文書数：そのエントリに対応するスレッド内の文書の総数である。
・作者数：そのエントリに対応するスレッド内の文書の作者の数である。
・最多発言ＵＩＤ：そのエントリに対応するスレッド内で最も多く発言した作者のユーザＩＤである。

・内容リスト：そのエントリに対応するスレッドに含まれるＱ and Ａパターン、論争（Ｄｉｓｃｕｓｓｉｏｎ）パターン、又は雑談（Ｃｈａｔ）パターンのパターンＩＤのリストである。Ｑ and ＡパターンのパターンＩＤであるＱＡ＿ＩＤは、後述するＱＡインデックス内のいずれかのエントリに登録されている。ＤｉｓｃｕｓｓｉｏｎパターンのパターンＩＤであるＤＳ−ＩＤは、後述するＤＩＳＣＵＳＳインデックス内のいずれかのエントリに登録されている。ＣｈａｔパターンのパターンＩＤであるＣＴ＿ＩＤは、後述するＣＨＡＴインデックス内のいずれかのエントリに登録されている。

４．ＱＡインデックス：
このインデックスは、Ｑ and Ａパターンの情報管理を行うためのインデックスであり、図３９に示されるように、エントリ毎に、下記情報を保持する。

・ＱＡ＿ＩＤ：そのエントリに対応するＱ and ＡパターンのＩＤ（キー）である。
・Ｑｕｅｓｔｉｏｎ：そのエントリに対応するＱand Ａパターンを構成するＱ（質問）文書に対応する文書ＩＤを格納するフィールドである。

・Ａｎｓｗｅｒ：そのエントリに対応するＱand Ａパターンを構成するＡ（答え）文書群に対応する文書ＩＤ列を格納するフィールドである。
・Ｔｈａｎｋｓ：そのエントリに対応するＱand Ａパターンを構成するＴ（お礼）文書に対応する文書ＩＤを格納するフィールドである。

・ＭａｘＡｎｓｗｅｒＵＩＤ：そのエントリに対応するＱ and Ａパターンを構成する各Ａ（答え）文書の作者、すなわち、そのエントリ内の「Ａｎｓｗｅｒ」フィールドに登録されている文書ＩＤ列中の各文書ＩＤに対応する文書の作者うち、もっとも登場回数が多い人（又は人達）のユーザＩＤ（又はユーザＩＤ列）を格納するフィールドである。

・ＴｈｒｅａｄＩＤ：そのエントリに対応するＱand Ａパターンが存在するスレッドのＩＤである。このスレッドＩＤは、スレッドインデックス内のいずれかのエントリに登録されている。

５．ＤＩＳＣＵＳＳインデックス：
このインデックスは、Ｄｉｓｃｕｓｓｉｏｎパターンの情報管理を行うためのインデックスであり、図４０に示されるように、エントリ毎に、下記情報を保持する。

・ＤＳ＿ＩＤ：そのエントリに対応するＤｉｓｃｕｓｓｉｏｎパターンのＩＤ（キー）である。
・記事ＩＤリスト：そのエントリに対応するＤｉｓｃｕｓｓｉｏｎパターンを構成する文書群の文書ＩＤ列を格納するフィールドである。

・ＵＩＤ：そのエントリに対応するＤｉｓｃｕｓｓｉｏｎパターンを構成する文書群のユーザＩＤ列である。
・ＴｈｒｅａｄＩＤ：そのエントリに対応するＤｉｓｃｕｓｓｉｏｎパターンが存在するスレッドのＩＤである。このスレッドＩＤは、スレッドインデックス内のいずれかのエントリに登録されている。

６．ＣＨＡＴインデックス：
このインデックスは、Ｃｈａｔパターンの情報管理を行うためのインデックスであり、図４１に示されるように、エントリ毎に、下記情報を保持する。

・ＣＴ＿ＩＤ：そのエントリに対応するＣｈａｔパターンのＩＤ（キー）である。
・Ｃｈａｔリスト：そのエントリに対応するＣｈａｔパターンを構成する文書群の文書ＩＤ列を格納するフィールドである。

・ＴｈｒｅａｄＩＤ：そのエントリに対応するＣｈａｔパターンが存在するスレッドのＩＤである。このスレッドＩＤは、スレッドインデックス内のいずれかのエントリに登録されている。

〔内容推定部３５０４の構成及び動作〕
図３５に示される第２の実施の形態における内容推定部３５０４の動作について、以下に詳細に説明する。

前述したように、内容推定部３５０４は、二次記憶装置３５０３に格納されている文書群の文書内容、文書付随情報、文書間の参照関係に基づいて、表示用インデックス３５０５であるユーザインデックス、文書インデックス、スレッドインデックス、ＱＡインデックス、ＤＩＳＣＵＳＳインデックス、及びＣＨＡＴインデックスを作成する。

図４２は、内容推定部３５０４が実行する動作を示す動作フローチャートである。
まず、図３７に示されるデータ構成を有する文書インデックスと図３８に示されるデータ構成を有するスレッドインデックスが作成される（ステップ４２０１）。これらの詳細は省略するが、基本的に、前述した図８及び図９に示される動作フローチャートと同様の動作によって実現できる。この場合には、前述したメタインデックスが文書インデックスに対応する。このとき同時に、各文書中に現れる作成ユーザ名とユーザＩＤ、略称、及び発言数（回答数）を対応づけるための図３６に示されるデータ構成を有するユーザインデックスも作成される。

次に、スレッドインデックス内の各エントリが参照されることにより、各エントリに対応するスレッド文書群が読み込まれ（ステップ４２０２）、全てのエントリに対するスレッド文書群の処理が終了したと判定されるまで（ステップ４２０６）、読み込まれたスレッド文書群毎に、Ｑ and Ａパターンの判定処理（ステップ４２０３）、Ｄｉｓｃｕｓｓｉｏｎパターンの判定処理（ステップ４２０４）、及びＣｈａｔパターンの判定処理（ステップ４２０５）が実行される。

図４３は、図４２のステップ４２０３のＱ and Ａパターンの判定処理の動作フローチャートである。この動作フローチャートでは、スレッド文書群内の各参照パス毎に、Ｑ and Ａパターンが推測される。

まず、スレッドインデックス内の該当エントリの「スレッドの木構造」フィールドが参照されることによって、リーフ文書（パスの末端の文書）に対応する文書ＩＤが１つ選択される（ステップ４３０１）。

次に、文書インデックスにおいて、ステップ４３０１で選択された文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「ルートまでのパス」フィールドから、下記条件を満たす文書ＩＤが検索される（ステップ４３０２）。

（条件）文書インデックスにおいて、その文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「記事種別」フィールドが未登録である。
続いて、上記条件を満たす文書ＩＤが見つかったか否かが判定される（ステップ４３０３）。

上記条件を満たす文書ＩＤ（以下、処理文書ＩＤという）が見つかりステップ４３０３の判定がＹＥＳとなった場合には、その処理文書ＩＤに対応する文書が二次記憶装置３５０３（図３５）から読み出され、その文書中に、図４４に示されるような、センテンスパターンが存在するか否かが判定される（ステップ４３０４）。

ステップ４３０４の判定がＮＯならば、ステップ４３０８にジャンプする。
ステップ４３０４の判定がＹＥＳならば、文書インデックスのステップ４３０２で参照されたエントリ内の「ルートまでのパス」フィールドに登録されている文書ＩＤのうち、下記条件を満たす文書ＩＤが存在するか否かが判定される（ステップ４３０５）。

（条件）その文書ＩＤに対応する文書は、処理文書ＩＤの作者によって作成されたものであって、かつその文書ＩＤは、図３９に示されるデータ構成を有するＱＡインデックス内のいずれかのエントリ内の「Ｔｈａｎｋｓ」フィールドに登録されている。

ステップ４３０５の判定がＹＥＳなら、ステップ４３０５で参照されたＱＡインデックス内のエントリの「Ｑｕｅｓｔｉｏｎ」フィールドに、処理文書ＩＤが追加される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、処理文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「記事種別」フィールドに、記号「Ｑ」が追加される（ステップ４３０６）。

更に、文書インデックスのステップ４３０２で参照されたエントリ内の「ルートまでのパス」フィールドに登録されている文書ＩＤ群のうち、ステップ４３０５で参照されたＱＡインデックス内のエントリの「Ｑｕｅｓｔｉｏｎ」フィールドに登録された処理文書ＩＤとそのエントリの「Ｔｈａｎｋｓ」フィールドに登録された文書ＩＤに挟まれた文書ＩＤ群が、そのエントリの「Ａｎｓｗｅｒ」フィールドに追加される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、上記登録が行われた各文書ＩＤを各「文書ＩＤ」フィールドに含む各エントリ内の「記事種別」フィールドに、それぞれ記号「Ａ」が追加される（ステップ４３０６）。

一方、ステップ４３０６の判定がＮＯなら、ＱＡインデックスにおいて、｛（そのインデックス内のＱＡ＿ＩＤの最大値）＋１｝の値を「ＱＡ＿ＩＤ」フィールドの値として有するエントリが作成され、そのエントリ内の「Ｑｕｅｓｔｉｏｎ」フィールドに、処理文書ＩＤが登録される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、処理文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「記事種別」フィールドに、記号「Ｑ」が登録される（ステップ４３０７）。

上記ステップ４３０６又は４３０７の処理の後、又はステップ４３０４の判定がＮＯとなった場合には、二次記憶装置３５０３から読み出されている処理文書ＩＤに対応する文書中に、図４５に示されるような、センテンスパターンが存在するか否かが判定される（ステップ４３０８）。

ステップ４３０８の判定がＮＯならば、ステップ４３０２に戻る。
ステップ４３０８の判定がＹＥＳならば、文書インデックスのステップ４３０２で参照されたエントリ内の「ルートまでのパス」フィールドに登録されている文書ＩＤのうち、下記条件を満たす文書ＩＤが存在するか否かが判定される（ステップ４３０９）。

（条件）その文書ＩＤに対応する文書は、処理文書ＩＤの作者によって作成されたものであって、かつその文書ＩＤは、図３９に示されるデータ構成を有するＱＡインデックス内のいずれかのエントリ内の「Ｑｕｅｓｔｉｏｎ」フィールドに登録されている。

ステップ４３０９の判定がＹＥＳなら、ステップ４３０９で参照されたＱＡインデックス内のエントリの「Ｔｈａｎｋｓ」フィールドに、処理文書ＩＤが追加される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、処理文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「記事種別」フィールドに、記号「Ｔ」が追加される（ステップ４３１０）。

更に、文書インデックスのステップ４３０２で参照されたエントリ内の「ルートまでのパス」フィールドに登録されている文書ＩＤ群のうち、ステップ４３０９で参照されたＱＡインデックス内のエントリの「Ｔｈａｎｋｓ」フィールドに登録された処理文書ＩＤとそのエントリの「Ｑｕｅｓｔｉｏｎ」フィールドに登録された文書ＩＤに挟まれた文書ＩＤ群が、そのエントリの「Ａｎｓｗｅｒ」フィールドに追加される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、上記登録が行われた各文書ＩＤを各「文書ＩＤ」フィールドに含む各エントリ内の「記事種別」フィールドに、それぞれ記号「Ａ」が追加される（ステップ４３１０）。

一方、ステップ４３０９の判定がＮＯなら、ＱＡインデックスにおいて、｛（そのインデックス内のＱＡ＿ＩＤの最大値）＋１｝の値を「ＱＡ＿ＩＤ」フィールドの値として有するエントリが作成され、そのエントリ内の「Ｔｈａｎｋｓ」フィールドに、処理文書ＩＤが登録される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、処理文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「記事種別」フィールドに、記号「Ｔ」が登録される（ステップ４３１１）。

上記ステップ４３１０又は４３１１の処理の後、ステップ４３０２に戻り、次の文書ＩＤの検索が実行される。
上記ステップ４３０２〜４３１１の処理が繰り返された結果、ステップ４３０３で、ステップ４３０２における条件を満たす文書ＩＤが見つからなかったと判定された場合には、スレッドインデックス内の現在処理中のエントリの「スレッドの木構造」フィールドが参照されることによって、全てのリーフ文書に対応する文書ＩＤに対する処理が試行されたか否かが判定される（ステップ４３１２）。

全てのリーフ文書に対応する文書ＩＤに対する処理が試行されてはおらずステップ４３１２の判定がＮＯの場合には、ステップ４３０１に戻り、次のパスに対応する話題パターンの推測処理が繰り返される。

全てのリーフ文書に対応する文書ＩＤに対する処理が試行されステップ４３１２の判定がＹＥＳとなった場合には、図４２のステップ４２０３のＱ and Ａパターンの判定処理を終了する。

図４６及び図４７に、上述のＱ and Ａパターンの判定処理によって抽出されるスレッド構造とそれに対応する文書群の例を示す。
なお、文書インデックスの「記事種別」フィールドに記号「Ａ」が付与されたエントリの文書ＩＤに対応する文書の作者について、それに対応するユーザインデックス（図３６参照）のエントリが参照され、そのエントリ内の「発言数（回答数）」フィールドの内容が更新される。

図４８は、図４２のステップ４２０４のＤｉｓｃｕｓｓｉｏｎパターンの判定処理の動作フローチャートである。この動作フローチャートでは、スレッド文書群内の各参照パス毎に、Ｄｉｓｃｕｓｓｉｏｎパターンが推測される。

まず、スレッドインデックス内の該当エントリの「スレッドの木構造」フィールドが参照されることによって、リーフ文書（パスの末端の文書）に対応する文書ＩＤが検索される（ステップ４８０１）。

次に、上記検索の結果、全てのリーフ文書に対応する文書ＩＤに対する処理が試行されたか否かが判定される（ステップ４８０２）。
全てのリーフ文書に対応する文書ＩＤに対する処理が試行されてはおらずステップ４８０２の判定がＮＯの場合には、文書インデックスにおいて、ステップ４８０１で検索された文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「ルートまでのパス」フィールドが参照され、上記リーフ文書に対応する文書ＩＤからルート文書までの長さ（文書ＩＤの数）が６以上であるか否かが判定される（ステップ４８０３）。

上記長さが６以上ではなくステップ４８０３の判定がＮＯの場合には、その参照パスの話題パターンはＤｉｓｃｕｓｓｉｏｎパターンではないと推測され、ステップ４８０１に戻って次のリーフ文書に対する処理が実行される。

上記長さが６以上であってステップ４８０３の判定がＹＥＳの場合には、ステップ４８０３で参照された「ルートまでのパス」フィールドに含まれる文書ＩＤ群に対応する文書群において、相異なるユーザＩＤの数がカウントされる（ステップ４８０４）。

次に、｛上記「ルートまでのパス」フィールドに含まれる文書ＩＤの数（総文書数）｝に対する｛上記相異なるユーザＩＤの数｝の割合が、０．３より小さいか否かが判定される（ステップ４８０５）。

この判定がＮＯの場合には、特定の少数のユーザによる論争が行われてはいないと推測され、ステップ４８０１に戻って次のリーフ文書に対する処理が実行される。
一方、ステップ４８０５の判定がＹＥＳの場合には、特定の少数のユーザによる論争が行われていると推測され、図４０に示されるデータ構成を有するＤＩＳＣＵＳＳインデックスにおいて、｛（そのインデックス内のＤＳ＿ＩＤの最大値）＋１｝の値を「ＤＳ＿ＩＤ」フィールドの値として有するエントリが作成される。そして、そのエントリ内の「記事ＩＤ」フィールドに、ステップ４８０３で参照された「ルートまでのパス」フィールドに含まれる文書ＩＤ群がリストとして登録され、その登録内容に基づいて、「ＵＩＤ」フィールド及び「ＴｈｒｅａｄＩＤ」フィールドの内容が登録される。また、図３７に示されるデータ構成を有する文書インデックスにおいて、上記各文書ＩＤ群を各「文書ＩＤ」フィールドに含む各エントリ内の「記事種別」フィールドに、記号「Ｄ」が登録される（ステップ４８０６）。その後、ステップ４８０１に戻って次のリーフ文書に対する処理が実行される。

全てのリーフ文書に対応する文書ＩＤに対する処理が試行されステップ４８０２の判定がＹＥＳとなった場合には、図４２のステップ４２０４のＤｉｓｃｕｓｓｉｏｎパターンの判定処理を終了する。

図４９に、上述のＤｉｓｃｕｓｓｉｏｎパターンの判定処理によって抽出されるスレッド構造の例を示す。少数のユーザの頭文字のみが多く現れていることがわかり、このスレッドにおいては論争が行われていると推測できる。

図５０は、図４２のステップ４２０５のＣｈａｔパターンの判定処理の動作フローチャートである。この動作フローチャートでは、スレッド文書群内の各参照パス毎に、Ｃｈａｔパターンが推測される。

まず、スレッドインデックス内の該当エントリの「スレッドの木構造」フィールドが参照されることによって、リーフ文書（パスの末端の文書）に対応する文書ＩＤが検索される（ステップ５００１）。

次に、上記検索の結果、全てのリーフ文書に対応する文書ＩＤに対する処理が試行されたか否かが判定される（ステップ５００２）。
全てのリーフ文書に対応する文書ＩＤに対する処理が試行されてはおらずステップ５００２の判定がＮＯの場合には、文書インデックスにおいて、ステップ５００１で検索された文書ＩＤを「文書ＩＤ」フィールドに含むエントリ内の「ルートまでのパス」フィールドが参照され、上記リーフ文書に対応する文書ＩＤからルート文書までの長さ（文書ＩＤの数）が６以上であるか否かが判定される（ステップ５００３）。

上記長さが６以上ではなくステップ５００３の判定がＮＯの場合には、その参照パスの話題パターンはＣｈａｔパターンではないと推測され、ステップ５００１に戻って次のリーフ文書に対する処理が実行される。

上記長さが６以上であってステップ５００３の判定がＹＥＳの場合には、ステップ５００３で参照された「ルートまでのパス」フィールドに含まれる文書ＩＤ群に対応する文書群において、相異なるユーザＩＤの数がカウントされる（ステップ５００４）。

次に、｛上記「ルートまでのパス」フィールドに含まれる文書ＩＤの数（総文書数）｝に対する｛上記相異なるユーザＩＤの数｝の割合が、０．６より大きいか否かが判定される（ステップ５００５）。

この判定がＮＯの場合には、多数のユーザによる雑談（チャット）が行われてはいないと推測され、ステップ５００１に戻って次のリーフ文書に対する処理が実行される。
一方、ステップ５００５の判定がＹＥＳの場合には、多数のユーザによる雑談が行われていると推測され、図４１に示されるデータ構成を有するＣＨＡＴインデックスにおいて、｛（そのインデックス内のＣＴ＿ＩＤの最大値）＋１｝の値を「ＣＴ＿ＩＤ」フィールドの値として有するエントリが作成される。そして、そのエントリ内の「Ｃｈａｔリスト」フィールドに、ステップ５００３で参照された「ルートまでのパス」フィールドに含まれる文書ＩＤ群がリストとして登録され、その登録内容に基づいて、「ＵＩＤ」フィールド及び「ＴｈｒｅａｄＩＤ」フィールドの内容が登録される（ステップ４８０６）。その後、ステップ５００１に戻って次のリーフ文書に対する処理が実行される。

全てのリーフ文書に対応する文書ＩＤに対する処理が試行されステップ５００２の判定がＹＥＳとなった場合には、図４２のステップ４２０５のＣｈａｔパターンの判定処理を終了する。

図５１に、上述のＣｈａｔパターンの判定処理によって抽出されるスレッド構造の例を示す。多数のユーザの頭文字が雑多に現れていることがわかり、このスレッドにおいては雑談が行われていると推測できる。

〔スレッド木の縮退処理の原理〕
次に、第２の実施の形態におけるスレッド木の縮退処理の原理について説明する。
図５２及び図５３は、スレッド構造の表示例を示す図である。図５２は、従来の伝統的なニュースリーダにおける表示例、図５３は、前述した図１４のスレッドビューの表示処理に基づく表示例である。

わずか１７本の記事からなるスレッドにおいても、図５２に示されるように行数が増えたり、図５３に示されるように横方向にはみだしたりして、スレッド全体を見るのに画面のスクロールが必要となり、全体構造の把握が難しいことがわかる。

図５４は、スレッド内の上位ｎ個の子孫ノード（図５４の例ではｎ＝６）に対する表示例である。行頭の“＋”記号は子ノードが省略されていることを表し、行末のかっこ付き数字は子孫ノードの個数（図３７に示される文書インデックスにおける参照子孫数）を表す。画面やウインドウサイズに合わせて値ｎを調整することにより、必要な部分のみを表示することが可能となる。

図５５は、子孫ノードのうち、同一タイトル（先頭の“Re: ”は除く）を持つノードが省略された表示例である。行頭の“＋”記号は子ノードが省略されていることを表す。同一スレッドの文書においては、デフォルトではタイトルは、親ノードと同じであるか、又は、最初にフォローを表す“Re: ”が付加されるかである。作者が意図的にタイトルを変えたというのは、そこで話題が変わったことを明示している。このビューにより、スレッド内にどのような話題の変化があったかを容易に把握することができる。

図５６は、１０／１から１０／５という時間区間に作成された文書のスレッド構造の表示例である。ノードは、作者のイニシャルを表す。このビューでは、スレッドの時間的展開と一定区間内の情報だけを見ることができる。また、パソコンの画面上でスケジューラなどの時間的情報のあるアプリケーションと並べて見ることによって、自分のスケジュールや世の中の出来事と関連づけて文書情報を見ることができる。

図５７は、スレッドの作者をノードとしたグラフ構造である。ノードは、作者のイニシャルである。二重丸で表されたノードは、スレッドの最初の記事の発言者を表す。リンクの濃さにより作者間のやりとりの回数が表される。更に、図３８に示されるスレッドインデックス中の該当エントリの最多発言ＵＩＤに登録されているユーザＩＤに対応するユーザのノードは、例えば強調表示される。このスレッドが、小川さん（小）とパーツィバルさん（パ）とのやりとりが中心であることが容易に理解できる。

〔検索フェーズの実行時の動作〕
次に、上述のスレッド木の縮退処理を含む検索フェーズの実行時の動作について説明する。

検索時には、利用者は、入力装置３５０９から検索要求を指示する。
図５８は、検索要求の入力画面である。入力項目としては、下記に示されるものがある。

・探したい記事に含まれるキーワード列（必須）。
・探したい記事が含んではいけないキーワード列。
・検索対象の記事の種別として、全ての記事か、Ｑand Ａパターンに相当する記事だけか。省略時は全ての記事。

・検索対象の記事の日付として、全区間か、一ヶ月以内か、一週間以内か。省略時は、全区間。
図５８に示される入力画面の下部には、検索前の準備フェーズにおいて記事が二次記憶装置３５０３に格納（ダウンロード）された最新の日時が表示されている。

検索結果としては、下記に示されるものがある。
・スレッド一覧（図６０参照）。
・スレッド構造表示（参照数による縮退表示、同一タイトルによる縮退表示を含む）（図６１参照）。

・時間区間スレッド表示（図６２参照）。
・Ｑ and Ａ対照表示。
・作者ノードグラフ表示（図５７参照）。

・作者投稿一覧表示。
・記事本文表示。
これらの表示画面は、図５９に示されるように相互に切り替えることができる。これらの表示画面のうち、代表的なものについて以下に説明する。

〔出力結果１：スレッド一覧〕
例えば、検索キーワードとして「エンジン」が入力された場合、図６０に示されるようなスレッド一覧画面が表示される。図６０で表示される検索結果は、下記に示されるものである。

・スレッドのトップ記事のタイトル。
・作者の名前。
・日付。

・サイズ（スレッドの記事数、全体の記事サイズ）。
・スレッドの内容（ＱＡ：Ｑ and Ａパターン、ＤＣ：Ｄｉｓｃｕｓｓｉｏｎパターン、ＣＴ：Ｃｈａｔパターン）。

検索時にはスレッドのサイズに基づくソーティング処理が実行され、上位１０スレッドが表示される。ユーザが「次の１０スレッド」をクリックすると、次の１０スレッドが表示される。

また、結果が多い場合には、更にキーワードを追加することにより絞り込み検索を実行させることも可能である。
他の画面へは、次の方法で移動することができる。

・タイトルをクリックすると、スレッド構造が表示される。
・作者の名前をクリックすると、作者ノードグラフが表示される。
・日付をクリックすると、時間区間スレッド表示が表示される。

・スレッドの内容のＱＡをクリックすると、ＱＡの対が表示される。
〔出力結果２：スレッド構造表示〕
図６１は、スレッド構造の表示例である。

図５４に示されるように、スレッド構造が、参照ノード数に基づいて縮退された木構造として表示される。表示領域の行数（縦方向の長さ）に応じて、参照ノード数の少ないノードは省略して表示される。ノードの表示内容は、下記のとおりである。表示領域の桁数（横方向の長さ）に応じて、各ノードにおいて表示される項目も適宜省略される。

・行頭の“＋”記号は、省略された子ノードがある場合に付加される。
・ユーザが入力したキーワードを含む記事は、タイトルと作者部分が強調表示される（図６１では、矩形によって囲まれた部分）。

・記事タイトル。フォロー記事には“Re: ”記号が付加される。
・記事の作者名。
・記事の種別。内容推定部３５０４（図３５）によって推定された話題パターンに応じて、Ｑ（質問）、Ａ（答）、Ｄ（論争）が付加される。

・自ノードの子孫ノードの数。“＋”記号が付加されたノードに対してのみ付加される。
また、このスレッド内において、更にキーワードを指定して絞り込み検索を実行することも可能である。

他の画面へは、次の方法で移動することができる。
・タイトルをクリックすると、記事本文が表示される。
・作者の名前をクリックすると、作者ノードグラフが表示される。

・「タイトル一覧」をクリックすると、スレッド構造が、同一タイトルに基づいて縮退された木構造として表示される（図５５参照）。
〔出力結果３：時間区間スレッド表示〕
図６２(a) は、一定の時間区間におけるスレッドの表示例である。キーワードが含まれる記事は黒丸によって、そうでない記事は灰色の丸によって表示されている。また、作者のイニシャルが各ノードの下に付加される。

この画面では、日付の表示区間、日付の縦横表示、ウインドウのサイズ、セルの幅などが可変である。そこで、例えば他のスケジューラとサイズを合わせることが可能である。例えば、図６２(b) は、他のスケジューラであり、それと図６２(a) に示される時間区間スレッド表示とで、各セル幅が合わせられている。

他の画面へは、次の方法で移動することができる。
・黒丸又は灰色の丸をクリックすると、記事本文が表示される。
・作者のイニシャルをクリックすると、作者ノードグラフが表示される。

〔出力結果４：ＱＡ対表示〕
ＱＡ対表示とは、内容推定部３５０４（図３５）によって推測されたＱ andＡパターンに対応する質問と回答の対が、テーブルとして表示されたものである。テーブルの一行には、下記の情報が表示される。

・タイトル。
・質問者。
・回答者（複数）。
他の画面へは、次の方法で移動することができる。

・タイトルをクリックすると、スレッド構造が表示される。
・作者の名前をクリックすると、作者ノードグラフが表示される。
〔出力結果５：作者ノードグラフ〕
作者ノードグラフは、そのスレッド内の各記事の作者間の会話関係がグラフ化されたものである。前述の図５７がその表示例である。

他の画面へは、次の方法で移動することができる。
・作者をクリックすると、その作者の投稿一覧が表示される。
・リンクをクリックすると、スレッド構造が表示される。

〔出力結果６：作者の投稿一覧〕
作者の投稿一覧は、各作者が投稿した記事の一覧を見るための画面である。日付、タイトル、記事の種別（Ｑ、Ａ、Ｄ）が日付順に表示される。

他の画面へは、次の方法で移動することができる。
・タイトルをクリックすると、記事本文が表示される。
〔出力結果７：記事本文〕
これは、記事の本文である。他に、作者名、タイトル、日付、親記事へのリンクが表示される。

他の画面へは、次の方法で移動することができる。
・タイトルをクリックすると、スレッド構造が表示される。
・日付をクリックすると、時間区間スレッド表示が表示される。

・作者の名前をクリックすると、作者ノードグラフが表示される。
〔時間区間スレッド表示の動作〕
図６３は、ビュー生成部３５０８（図３５）が実行する時間区間スレッド表示の動作フローチャートである。

まず、図３８に示されるデータ構成を有するスレッドインデックスにおいて、表示対象スレッドに対応するエントリ内の「スレッドの木構造」フィールドが参照されることにより、そのスレッドに含まれる文書ＩＤが１つ選択される（ステップ６３０１）。

次に、図３７に示されるデータ構成を有する文書インデックスにおいて、上記選択された文書ＩＤに対応するエントリ内の「日付」フィールドが参照され、その日付が図６４に示されるデータ構成を有するカレンダインデックスに登録される（ステップ６３０２）。

次に、スレッドインデックスの表示対象スレッドに対応するエントリ内の「スレッドの木構造」フィールド内の全ての文書ＩＤに対する処理が試行されたか否かが判定される（ステップ６３０３）。

全ての文書ＩＤに対する処理が試行されてはおらずステップ６３０３の判定がＮＯの場合には、ステップ６３０１に戻り、次の文書ＩＤに対する処理が繰り返される。
全ての文書ＩＤに対する処理が試行されステップ６３０３の判定がＹＥＳとなった場合には、図６４に示されるデータ構成を有するカレンダインデックスが参照されることにより、カレンダに文書ノードがマッピングされる。参照関係のエッジは、スレッドインデックスを参照して表示される。

〔作者ノードグラフの表示動作〕
図６５は、ビュー生成部３５０８（図３５）が実行する作者ノードグラフの表示動作を示す動作フローチャートである。

まず、図３８に示されるデータ構成を有するスレッドインデックスにおいて、表示対象スレッドに対応するエントリ内の「スレッドの木構造」フィールドが参照されることにより、そのスレッドに含まれる文書ＩＤが１つ選択される。次に、図３７に示されるデータ構成を有する文書インデックスと図３６に示されるデータ構成を有するユーザインデックスとが参照されることにより、上記選択された文書ＩＤに対応する文書の親文書（親発言）のユーザＩＤが取得される（ステップ６５０１）。

次に、図６６に示されるデータ構成を有する発言者配列内に、上記親子関係に対応するエントリが存在するか否かが判定される（ステップ６５０２）。
そのエントリが存在するなら、ステップ６５０４の処理に進む。

そのエントリが存在しないなら、発言者配列の横軸又は縦軸のエントリが追加される（ステップ６５０３）。
その後、上記エントリの数字が１だけインクリメントされる（ステップ６５０４）。

次に、スレッドインデックスの表示対象スレッドに対応するエントリ内の「スレッドの木構造」フィールド内の全ての文書ＩＤに対する処理が試行されたか否かが判定される（ステップ６５０５）。

全ての文書ＩＤに対する処理が試行されてはおらずステップ６５０５の判定がＮＯの場合には、ステップ６５０１に戻り、次の文書ＩＤに対する処理が繰り返される。
全ての文書ＩＤに対する処理が試行されステップ６５０５の判定がＹＥＳとなった場合には、図６７に示されるように、図６６に示されるデータ構成を有する発言者配列のエントリの数だけノードが描画され、親から子供に向かって“→”線が描画される。この線の太さは、その親子間の会話の度数に応じて決定される（ステップ６５０６）。

以上説明した第２の実施の形態において、スレッドの木構造が縮退されることにより、画面の表示範囲に応じたスレッドの表示可能となる。
また、自動的に推定された話題と共に検索結果が表示されるため、検索結果のスレッド数が多い場合でも、利用者は検索結果の概要を容易に把握することが可能となる。

更に、スレッド中の文書量が多くても、同じ作者が何度も投稿している場合がある。作者を中心に見せるビユーが提供されることにより、スレッド内のキーパーソンが把握可能となるだけでなく、スレッドの全体構造もコンパクトに表示することが可能となる。

〔各実施の形態を実現するプログラムが記録された記録媒体についての補足〕
本発明は、計算機により使用されたときに、上述の本発明の各実施の形態の各構成によって実現される機能と同様の機能を計算機に行わせるための計算機読出し可能記憶媒体として構成することもできる。

この場合に、図６８に示されるように、例えばフロッピィディスク、ＣＤ−ＲＯＭディスク、光ディスク、リムーバブルハードディスク等の可搬型記憶媒体６８０２や、ネットワーク回線６８０３経由で、本発明の好適実施例の各種機能を実現するプログラムが、コンピュータ６８０１の本体６８０４内のメモリ（ＲＡＭ又はハードディスク等）６８０５にロードされて、実行される。

参照関係を有する文書群の例を示す図である。 文書のデータ構造の例を示す図である。 本発明の実施の形態のシステム構成図（その１）である。 本発明の実施の形態のシステム構成図（その２）である。 メタインデックスのデータ構造を示す図である。 スレッドインデックスのデータ構造を示す図である。 索引ファイルのデータ構造を示す図である。 書式解析部と構造解析部の動作フローチャートである。 文書番号のスレッドインデックスへの登録の動作フローチャートである。 文書番号のスレッドインデックスへの登録の動作説明図である。 色番号登録の動作フローチャートである。 カラーテーブルの例を示す図である。 キーワードビユーの動作フローチャートである。 スレッドビューの動作フローチャートである。 スレッドビューの制御用配列の例を示す図である。 発言者ビューの動作フローチャートである。 発言者ビューの制御用配列の例を示す図である。 発言内容表示の動作フローチャートである。 作者別／日付別色分け表示の動作フローチャートである。 作者別／日付別色分け表示用配列の例を示す図である。 スレッドビューを使った検索結果の強調表示の動作フローチャートである。 キーワードビユーを使った検索結果の強調表示の動作フローチャートである。 サブトピックからのキーワード抽出の制御動作フローチャートである。 サブトピックインデックスの例を示す図である。 キーワードビユーの表示例を示す図である。 スレッドビューの表示例を示す図である。 発言者ビューの表示例を示す図である。 発言内容の表示例を示す図である。 スレッドビューを用いた文書属性「作者」の強調（色別）表示の例を示す図である。 会議室内の全発言の検索（入力）表示例を示す図である。 スレッドビューを用いた文字列「プロトコル」を含むノードの強調表示の例を示す図である。 キーワードビユーを用いた文字列「プロトコル」を含むスレッドの強調表示の例を示す図である。 会議室内の全発言の検索（結果出力）表示例を示す図である。 サブトピックから抽出したキーワードの表示例を示す図である。 本発明の他の実施の形態（第２の実施の形態）の構成図である。 ユーザインデックスの構成図である。 文書インデックスの構成図である。 スレッドインデックスの構成図である。 ＱＡインデックスの構成図である。 ＤＩＳＣＵＳＳインデックスの構成図である。 ＣＨＡＴインデックスの構成図である。 内容推定部の動作フローチャートである。 Ｑ and Ａパターン判定処理の動作フローチャートである。 Ｑ（質問）文書に含まれるパターンの例を示す図である。 お礼文書に含まれるパターンの例を示す図である。 Ｑ and Ａパターンの判定処理が推測するスレッド構造の例を示す図である。 Ｑ and Ａパターンの判定処理が推測するスレッド文書群の例を示す図である。 論争パターンの判定処理の動作フローチャートである。 Ｄｉｓｃｕｓｓｉｏｎパターンの判定処理が推測するスレッド構造の例を示す図である。 雑談パターンの判定処理の動作フローチャートである。 Ｃｈａｔパターンの判定処理が推測するスレッド構造の例を示す図である。 オリジナルのスレッド構造の表示例を示す図である。 オリジナルのスレッド構造の表示例を示す図である。 参照ノード数により縮退したスレッド構造の表示例を示す図である。 同一タイトル文書を縮退したスレッド構造の表示例を示す図である。 時間区間で取り出したスレッド構造の表示例を示す図である。 作者をノードとしたグラフ構造を示す図である。 ネットワークニュース検索システムの表示例を示す図である。 検索画面の一覧を示す図である。 出力結果１：スレッド一覧を示す図である。 出力結果２：スレッド構造表示を示す図である。 出力結果３：時間区間スレッド表示を示す図である。 時間区間スレッド表示の作成フローを示す図である。 カレンダインデックスのデータ構成図である。 作者ノードグラフの作成フローを示す図である。 発言者配列のデータ構成図である。 作者ノードグラフの作成説明図である。 本実施の形態を実現するプログラムが記録された記録媒体の説明図である。

符号の説明

３０１ 文書群データベース
３０２ 文書群解析装置
３０３ 集計装置
３０４ メタインデックス
３０５ スレッドインデックス
３０６ 表示装置
４０１ 書式解析部
４０２ 構造解析部
４０３ 内容解析部
４０４ 索引ファイル
４０５ 文字列検索装置
３５０１ 処理装置
３５０２ 文書取得部
３５０３ 二次記憶装置
３５０４ 内容推定部
３５０５ 表示用インデックス
３５０６ 検索エンジン
３５０７ 検索用インデックス
３５０８ ビュー生成部
３５０９ 入力装置
３５１０ 表示装置

Claims (4)

1. 参照関係を有する文書からなる文書群を表示する関連文書表示装置であって、
   参照関係を有する文書群が管理される文書データベースと、
   文書、および、該文書を作成した作成者が管理される管理データベースと、
   前記参照関係にある文書群を構成する文書数が所定値に達するか否かを判定するスレッド長判定手段と、
   前記スレッド長判定手段で前記文書群の前記文書数が所定値に達していると判断された場合は、前記管理データベースを参照し、該文書群の各文書を作成した作成者を識別し、該文書群に係わる作成者数を算出する作成者算出手段と、
   前記文書群の文書数に対する前記作成者数の比率を算出し、該比率が所定値に達するか否かを判定し、該判定の結果に基づき該文書群の特徴を特定する内容特定手段と、
   前記文書群について前記特定した特徴に関する情報を出力装置に出力する出力手段と、
   を含むことを特徴とする関連文書表示装置。
2. 前記内容特定手段は、前記文書群の文書数に対する前記作成者数の比率が所定値に達しない場合は、少数のユーザが関与したことを該文書群の特徴として特定することを特徴とする請求項１に記載の関連文書表示装置。
3. 前記内容特定手段は、前記文書群の文書数に対する前記作成者数の比率が所定値に達した場合は、多数のユーザが関与したことを該文書群の特徴として特定することを特徴とする請求項１に記載の関連文書表示装置。
4. 前記文書群の各文書は、参照関係に基づいて他文書との前後関係が規定され、
   さらに、
   質問を意味する質問文字情報、および、謝辞を意味する謝辞文字情報が管理された文字情報データベースと、
   前記文章群に含まれる文書を順次抽出し、前記文字情報データベースを参照し、抽出した文書に前記質問文字情報あるいは謝辞文字情報が含まれるか否かを判定する文字識別手段と、
   前記文字識別手段で前記質問文字情報あるいは謝辞文字情報を含むと判定された文書については、質問文字情報を含む場合は、該文書に対して質問文書を示す質問フラグを付与し、一方、前記謝辞文字情報を含む場合は、該文書に対して謝辞文書を示す謝辞フラグを付与した上で、該文書を含む文書群の中に、質問フラグが付与された文書と謝辞フラグが付与された文書のいずれもが存在するか否かを判定し、いずれの文書も存在する場合は、参照関係において質問フラグが付与された文書と謝辞フラグが付与された文書に挟まれた文書に対して、該質問文書への回答文書を示す回答フラグを付与するフラグ付与手段と、
   を備え、
   前記出力手段は、前記フラグ付与手段が付与したフラグに基づいて、前記文書の特徴を示す情報を前記出力装置に出力する
   ことを特徴とする請求項１に記載の関連文書表示装置。

Images