関連文書表示システム、関連文書表示方法およびプログラム
【課題】電子データである文書の集合を用いた調査業務等において、ユーザによる文書の閲覧時に、関連する文書を適切に表示することを課題とする。
【解決手段】本発明の関連文書表示システム１０００は、文書の集合における過去の文書の作成に基づく関連する文書同士を有効な関連リンクとして関連リンク記憶部（関連リンク管理情報５３０）に記憶する関連学習制御部２２３と、その後、ユーザによって文書の集合におけるいずれかの文書が閲覧された場合、関連リンク記憶部を参照して、閲覧された文書と有効な関連リンクを有する文書を抽出し、当該抽出した文書を、閲覧された文書に関連する文書として表示部に表示するレコメンド制御部（ｐｒｏｘｙ部２２８）と、を有する。
【解決手段】本発明の関連文書表示システム１０００は、文書の集合における過去の文書の作成に基づく関連する文書同士を有効な関連リンクとして関連リンク記憶部（関連リンク管理情報５３０）に記憶する関連学習制御部２２３と、その後、ユーザによって文書の集合におけるいずれかの文書が閲覧された場合、関連リンク記憶部を参照して、閲覧された文書と有効な関連リンクを有する文書を抽出し、当該抽出した文書を、閲覧された文書に関連する文書として表示部に表示するレコメンド制御部（ｐｒｏｘｙ部２２８）と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子データである文書の集合からユーザが文書を閲覧する際に、関連する文書を推薦（表示）するレコメンデーション機能に関する。
【背景技術】
【０００２】
あいまいな既存情報から調査をすすめて、所望する情報を得る業務がある。例えば、顧客からの問合せ内容に対してユーザ（調査者）が社内システムやインターネット等を利用して文書を調査し、調査結果を顧客に回答するテクニカルサポートセンタやヘルプデスクといった調査業務である。
【０００３】
前記調査業務において、ユーザは社内システムやインターネットでの検索やリンクを辿るなど試行錯誤して多くの参考文書を参照する。この方法では、一般に、情報提供者（Ｗｅｂページ提供者等）の観点でしか情報検索できないため、作業効率が悪い。
【０００４】
一方、利用者の観点で情報をレコメンドする技術には以下のものがある。例えば、ブラウザの検索キーワード入力欄に検索キーワードを入力すると、統計的に学習した関連のある検索キーワードを提示する技術である（特許文献１参照）。その他には、インターネット書籍販売サイトにてユーザが書籍を参照した際に、過去のユーザの購入履歴に基づき前記参照する書籍を購入した人が別途購入した書籍を提示する技術である（特許文献２参照。「書籍」が本発明における「文書」と対応）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００５／０１９８０６８号明細書
【特許文献２】米国特許第６２６６６４９号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前記した従来技術においては、以下の課題がある。
まず、特許文献１の技術では、インターネットにおける膨大な情報から適切な情報を選別することを目的にしている。つまり、扱う情報量が膨大であるため、一般に、少数の検索キーワードで検索しただけでは検索結果集合も大きなものとなり、一覧から適切な情報を選別することが困難となる。
【０００７】
これを解決するために、特許文献１の技術では、検索結果をより小さく絞り込むために、同一キーワードを多数含む膨大な検索ログを対象にキーワードの共起に着目した統計処理を行い、論理積（ＡＮＤ）条件となる検索キーワード候補を抽出する。例えば、「不況」というキーワードで検索すると、「原因」や「節約」といった検索キーワードが同時検索の候補としてレコメンド（推薦）される。
【０００８】
一方、企業内のＬＡＮ（Local Area Network）システム等を利用した業務（以下、単に「業務」という。）では、インターネットに比べて対象とする情報量および検索トラフィック密度が少ないため、論理積（ＡＮＤ）条件となる検索キーワードによる絞込検索よりも、現在の検索結果集合には必ずしも存在しないが、業務上関連の深い情報を効率良く提示することがより重要である。検索でいえば検索キーワード入力欄を一度クリアした後に入力するようなキーワード候補を提示することが重要である。しかし、特許文献１の技術では、結果集合が論理和（ＯＲ）となるような関連キーワードを提示することができない。なお、論理積（ＡＮＤ）を求めるための絞り込むキーワードの場合、検索ログを大量に得ることが困難な業務においては適切にレコメンドすることができない。
【０００９】
また、特許文献２の技術では、複数のユーザが過去に参照した情報から関連を統計的に学習し、ユーザの嗜好をパターンとして抽出して、類似の嗜好を持つ人に興味のあると思われる情報を提示する。すなわち、個人を特定しないまま人の嗜好をパターン化している。つまり、特許文献２の技術では、大量の購買履歴を商品の共起に着目して統計的に処理することで、人の嗜好のパターンを抽出している。
【００１０】
一方、業務（例えば、サポートセンタ等）は、担当する人ではなく、受け付けた問い合わせ等の業務案件によって参照すべき情報が大きく異なることが特徴である。また、業務では同時に参照すべき関連性の高い情報が存在するが、一方で同一情報の利用頻度はＢ ｔｏ Ｃ（Business to Consumer）における同一商品の購入頻度ほど高くないと考えられる。そして、特許文献２の技術では、現在の業務に関連が強いが、他の業務とは異なる可能性のある情報を業務毎にレコメンドすることができない。また、特許文献２の技術では、統計処理に向かない程度に参照回数が少ない情報同士の関連を提示することができない。
【００１１】
そこで、本発明は、前記課題に鑑みてなされたものであり、電子データである文書の集合を用いた調査業務等において、ユーザによる文書の閲覧時に、関連する文書を適切に表示することを課題とする。
【課題を解決するための手段】
【００１２】
前記課題を解決するために、本発明の関連文書表示システムは、文書の集合における過去の文書の作成に基づく関連する文書同士を有効な関連リンクとして関連リンク記憶部に記憶する関連学習制御部と、その後、ユーザによって文書の集合におけるいずれかの文書が閲覧された場合、関連リンク記憶部を参照して、閲覧された文書と有効な関連リンクを有する文書を抽出し、当該抽出した文書を、閲覧された文書に関連する文書として表示部に表示するレコメンド制御部と、を有する。その他の手段については後記する。
【発明の効果】
【００１３】
本発明によれば、電子データである文書の集合を用いた調査業務等において、ユーザによる文書の閲覧時に、関連する文書を適切に表示することができる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施形態の関連文書表示システムのハードウェア構成の一例を示す図である。
【図２】第１の実施形態の関連文書表示システムのソフトウェアおよびハードウェアの構成の一例を示す図である。
【図３】第１の実施形態の関連文書表示システムの原理の一例を示す図である。
【図４】第１の実施形態の関連イベントテーブルの一例を示す図である。
【図５】第１の実施形態の案件セッション別有効文書一覧テーブルの一例を示す図である。
【図６】第１の実施形態の関連リンク管理情報の一例を示す図である。
【図７】第１の実施形態のキーワードテーブルの一例を示す図である。
【図８】第１の実施形態の案件セッションＩＤ用Ｃｏｏｋｉｅの一例を示す図である。
【図９】第１の実施形態の文書用Ｃｏｏｋｉｅの一例を示す図である。
【図１０】第１の実施形態の作成文書テーブルの一例を示す図である。
【図１１】第１の実施形態の有効文書巡回用スタックの一例を示す図である。
【図１２】第１の実施形態の関連文書表示システムで実行される処理の全体フローの一例を示すフローチャートである。
【図１３】第１の実施形態の各構成間の関係の一例を示す図である。
【図１４ａ】第１の実施形態のクライアントで実行される案件セッション開始処理の一例を示すフローチャートである。
【図１４ｂ】第１の実施形態のコンテンツ体系化サーバで実行される案件セッションＩＤ取得処理の一例を示すフローチャートである。
【図１５】第１の実施形態のコンテンツ体系化サーバで実行されるｐｒｏｘｙ部の処理の一例を示すフローチャートである。
【図１６ａ】第１の実施形態のクライアントで実行される文書作成処理の一例を示すフローチャートである。
【図１６ｂ】第１の実施形態のクライアントで実行されるテキスト挿入処理の一例を示すフローチャートである。
【図１６ｃ】第１の実施形態のクライアントで実行されるペースト処理の一例を示すフローチャートである。
【図１６ｄ】第１の実施形態のコンテンツ体系化サーバで実行されるコピーペースト捕捉処理の一例を示すフローチャートである。
【図１７】第１の実施形態のコンテンツ体系化サーバで実行される関連リンクの生成処理の全体フローの一例を示すフローチャートである。
【図１８】第１の実施形態の案件セッション別有効文書一覧の作成処理の一例を示すフローチャートである。
【図１９】第１の実施形態の関連リンク生成処理の一例を示すフローチャートである。
【図２０ａ】第１の実施形態のクライアントで実行される検索実行時のブラウザでの処理の一例を示すフローチャートである。
【図２０ｂ】第１の実施形態のコンテンツ体系化サーバで実行される検索キーワードのレコメンド処理の一例を示すフローチャートである。
【図２１ａ】第１の実施形態の関連リンク学習時の具体事例を示す図である。
【図２１ｂ】第１の実施形態のレコメンド実行時の具体事例を示す図である。
【図２２】第２の実施形態の関連文書表示システムのソフトウェアおよびハードウェアの構成の一例を示す図である。
【図２３】第２の実施形態の関連リンクノードの一例を示す図である。
【図２４】第２の実施形態の文書ノードの一例を示す図である。
【図２５】第２の実施形態のＵＲＩ−文書ノード対応管理テーブルの一例を示す図である。
【図２６】第２の実施形態のグラフ構造の概念図の一例を示す図である。
【図２７】第２の実施形態の案件セッション別有効文書一覧テーブルおよび探索の訪問済み文書管理テーブルの一例を示す図である。
【図２８】第２の実施形態の関連リンク生成用スタックの一例を示す図である。
【図２９】第２の実施形態の関連文書表示システムで実行される処理の全体フローの一例を示す図である。
【図３０】第２の実施形態の各構成間の関係の一例を示す図である。
【図３１ａ】第２の実施形態の関連リンクの生成の処理フローの一例を示す図である。
【図３１ｂ】第２の実施形態の第１の探索の処理の一例を示す図である。
【図３１ｃ】第２の実施形態の第２の探索の処理の一例を示す図である。
【図３１ｄ】第２の実施形態の関連度の算出の処理の一例を示す図である。
【図３２】第２の実施形態のコンテンツ体系化サーバで実行される検索キーワードのレコメンド処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態（以下、「実施形態」という。）について、図面を参照（言及図以外も適宜参照）しながら、本実施形態（第１、第２の実施形態）の概要、第１の実施形態、第２の実施形態の順で説明する。
【００１６】
＜本実施形態の概要＞
最初に、図３に示した事例を用いて本実施形態の概要を説明する。本実施形態は、（ａ）関連リンク学習時と、（ｂ）レコメンド実行時とに大別できる。なお、本実施形態では、検索キーワードも一種の文書と考える。つまり、特許請求の範囲における「文書」には「検索キーワード」も含まれ、また、特許請求の範囲における「閲覧された文書」には、「（ユーザによって）入力された検索キーワード」も含まれる。さらに、以下に説明する概要では、文書−文書、検索キーワード−文書、検索キーワード−検索キーワード等の関係のうち、特に、ユーザが検索キーワードを入力した際に関連する検索キーワードを提示する場合を具体例にして説明する。
【００１７】
≪関連リンク学習時≫
まず、（ａ）関連リンク学習時について説明する。図３（ａ）に示すように、ここでは、ユーザがさまざまな検索キーワード（k1〜k3）を用いて文書の検索を実行し、文書（p0〜p3）を参照し、得た情報をまとめて文書(c1。所定の文書)を作成する状況を想定する。また、一連の文書閲覧、検索キーワード入力を行って、少なくとも一つの文書を作成する一連の作業を案件セッションと定義する。
【００１８】
まず、最初に、ユーザが案件セッションの開始操作を行い、この操作をシステム（後記する関連文書表示システム１０００）が認識する。その際、案件セッションＩＤ（IDentification）を採番する。図３の例では、案件セッションＩＤとしてs2を採番したとする。
【００１９】
次に、ユーザは検索キーワードk1を入力して、検索結果ページを閲覧し、その中から案件に関連のありそうな文書p1を参照したとする。案件セッションＩＤ（s2）、参照した文書p1を関連元（後記する探索時の探索元）および検索キーワードk1を関連先（後記する探索時の探索先）とする関連イベントを関連イベントテーブル５１０（関連イベント記憶部）に格納する。また、前記関連イベントの種別は、関連元のp1はp、また関連先のk1はkとする。この種別とは、kは検索キーワード、pは文書を表す。また後に登場する種別のcは作成文書を表す。
【００２０】
同様に、ユーザは、検索キーワードk2にて検索して文書p2を参照し、検索キーワードk3にて検索して文書p3を参照したので、これらも関連イベントテーブル５１０に同様に格納する。
【００２１】
また、ユーザが文書p1を参照し、文書p1中のリンクにより文書p0を参照したとする。この文書間の遷移として関連イベントテーブル５１０の関連元にp0、関連先にp1を格納する。
【００２２】
また、ユーザが文書c1を作成する。ここで、ユーザは文書p0の一部のテキストをコピーして、文書c1にペーストしたとする。このコピーペースト（コピー＆ペースト）の関係として、関連元としてc1を、関連先としてp0を関連イベントテーブル５１０に格納する。また、文書p2の一部のテキストを作成文書c1にコピーペーストしたので、同様に関連イベントテーブル５１０に格納する。また、ユーザは、文書p3を参照はしたが、文書c1の作成には利用しなかったとする。
【００２３】
次に、ユーザが文書c1の作成を終えて、コンテンツ体系化サーバ２００（後記）に作成文書c1を格納したとする。コンテンツ体系化サーバ２００は、この作成文書c1の格納を受けて、当該案件セッションs2で文書の作成に関係した文書の一覧を作成し、案件セッション別有効文書一覧テーブル５２０に格納する。具体的には、関連イベントテーブル５１０を参照することで、関連イベントによる木構造を図３中の矢印の様にs2の範囲で探索し、文書作成に関連を持った文書の一覧（案件セッション別有効文書一覧テーブル５２０）を作成する。ここで、k3およびp3はc1から到達できる関連イベントによる木構造の一部になっていないので案件セッション別有効文書一覧テーブル５２０には格納されず、この時点で有用な関連リンクの生成の対象から除外される。
【００２４】
次に、案件セッション別有効文書一覧テーブル５２０の案件セッションＩＤのカラムの値が当該案件セッションＩＤ（s2）であるものから任意の２つの文書間に関連リンクを生成し、この関連リンクの情報を関連リンク管理情報５３０（関連リンク記憶部）に格納する。このとき、関連リンク管理情報５３０に格納済みの内容であれば、カウンタを１つ繰り上げる。関連リンクの情報が格納されていなければ、カウンタを１として格納する。これによって、文書作成に関連した関連性の高い文書や一種の文書である検索キーワード間の関連が学習される。
【００２５】
次に、（ｂ）レコメンド実行時について説明する。図３（ｂ）に示すように、ここでは、ユーザが検索キーワードを入力したときに、関連がある検索キーワードを提示する場合を例に説明する。ユーザが検索キーワードとしてk1を入力したとする。ユーザが検索キーワードk1を入力すると、関連リンク管理情報５３０から関連元がk1であり、関連先として種別がkであるものをサーチする。図３の例では、k2がヒットする。この検索キーワードk2を含むサーチ結果をカウンタで降順にソートして上位からユーザに提示する。これによって、k1と関連があるが異なる検索キーワードk2による新たな観点でユーザは検索を行って、関連情報を参照できる。
【００２６】
＜第１の実施形態＞
（構成）
次に、第１の実施形態の関連文書表示システムのハードウェア構成について説明する。図１に示すように、第１の実施形態の関連文書表示システム１０００は、１台以上のクライアント計算機（以下、「クライアント」という。）１００（「１００」は「１００ａ」と「１００ｂ」の総称であり、以下、他の構成についても同様である。）およびコンテンツ体系化サーバ２００を備え、それらはＬＡＮ３００によって繋がって（接続されて）いる。また、ＬＡＮ３００は、検索サーバ３０１およびＷｅｂサーバ３０２（ウェブサーバ）とＷＡＮ（Wide Area Network）３０３によって繋がっている。
【００２７】
クライアント１００は、ＣＰＵ（Central Processing Unit）１１０、メモリ１２０、記憶装置１３０、入力装置１４０、出力装置１５０およびＩＦ（ネットワークインターフェース制御部）１６０を備える計算機（コンピュータ装置）である。
【００２８】
ＣＰＵ１１０は、メモリ１２０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ１１０がオペレーティングシステムおよびアプリケーションプログラム等のソフトウェアを実行することによって、所定の機能が達成（実現）される。
【００２９】
メモリ１２０には、記憶装置１３０から読み出されたオペレーティングシステムやアプリケーションプログラム等のソフトウェアや各種データが格納される。
記憶装置１３０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、オペレーティングシステムやアプリケーションプログラム等のソフトウェアや各種データを格納する。
【００３０】
入力装置１４０は、例えば、キーボードやマウス等である。入力装置１４０は、ユーザからの入力を受け付ける。
出力装置１５０はディスプレイ等であり、ＣＰＵ１１０から指示された情報を出力する。
ＩＦ１６０は、ＬＡＮ３００と接続される。クライアント１００は、複数のＩＦ１６０を備えても良い。
【００３１】
コンテンツ体系化サーバ２００は、ＣＰＵ２１０、メモリ２２０、記憶装置２３０およびＩＦ（ネットワークインターフェース制御部）２６０を備える計算機である。
ＣＰＵ２１０は、メモリ２２０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ２１０がソフトウェア等を実行することによって、関連の生成および関連情報の提示等の所定の機能が達成（実現）される。
【００３２】
メモリ２２０には、記憶装置２３０から読み出されたソフトウェア等が格納される。
記憶装置２３０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、ソフトウェア等を格納する。
ＩＦ２６０は、ＬＡＮ３００と接続される。なお、コンテンツ体系化サーバ２００は、複数のＩＦ２６０を備えても良い。
【００３３】
次に、第１の実施形態のコンテンツ体系化サーバ２００のメモリ２２０に格納される、関連生成及び関連提示処理のためのプログラム及び関連情報の一例を示すソフトウェアおよびハードウェアの構成について説明する。
【００３４】
図２に示すように、メモリ２２０には、案件セッションＩＤ採番部２２１、文書ＵＲＩ（Uniform Resource Identifier）採番部２２２、関連学習制御部２２３、コピーペースト受付部２２６、キーワードレコメンド生成部２２７およびｐｒｏｘｙ部２２８（レコメンド制御部）が格納される。さらに、関連学習制御部２２３は、有効文書一覧生成部２２４、関連生成部２２５および有効文書巡回用スタック５８０を持つ。メモリ２２０内の各部は処理プログラムであり、図１のＣＰＵ２１０によって実行されるプログラムである。これらの処理については、後記する。
【００３５】
さらに、記憶装置２３０には、作成文書格納部２１６、関連情報格納部２１７が格納される。作成文書格納部２１６には、キーワードテーブル５４０および作成文書テーブル５７０が格納される。関連情報格納部２１７には、関連イベントテーブル５１０、案件セッション別有効文書一覧テーブル５２０および関連リンク管理情報５３０が格納される。
【００３６】
次に、クライアント１００のメモリ１２０に格納されるソフトウェア構成の一例を説明する。クライアント１００のメモリ１２０には、ブラウザ１２１が格納される。ブラウザ１２１内には、案件セッションＩＤ取得部１２２、案件セッションＩＤ格納部１２３、エディタ部１２４、ＨＴＭＬ（Hyper Text Markup Language）レンダリング部１２９およびレコメンド表示部１２９１（表示部）が格納される。エディタ部１２４内には、文書ＵＲＩ取得部１２５、文書ＵＲＩ格納部１２６、作成文書保存部１２７およびコピーペースト捕捉部１２８が格納される。これらの処理については、後で詳細に説明する。
【００３７】
なお、第１の実施形態では、クライアント１００のブラウザ１２１の拡張機能としてこれらの各部を実装することを想定しているが、クライアント１００とＷｅｂサーバ３０２との通信を中継するｐｒｏｘｙ部２２８にて、Ｗｅｂサーバ３０２から受信したＷｅｂコンテンツに例えばJava（登録商標）Scriptのようなスクリプトを追記して、ブラウザ１２１上でスクリプトを実行して機能を提供する形態であっても良い。
【００３８】
次に、各データ構造について説明する。まず、関連イベントテーブル５１０について説明する。図４に示すように、関連イベントテーブル５１０は、案件セッションＩＤ５１１、関連元のＵＲＩ５１２、関連元の種別５１３、関連先のＵＲＩ５１４および関連先の種別５１５の情報の組を保持する。
【００３９】
次に、案件セッション別有効文書一覧テーブル５２０について説明する。図５に示すように、案件セッション別有効文書一覧テーブル５２０は、案件セッションＩＤ５２１、ＵＲＩ５２２および種別５２３の情報の組を保持する。
【００４０】
次に、関連リンク管理情報５３０について説明する。図６に示すように、関連リンク管理情報５３０は、関連元のＵＲＩ５３１、関連元の種別５３２、関連先のＵＲＩ５３３、関連先の種別５３４およびカウンタ５３５の情報の組を保持する。
【００４１】
次に、キーワードテーブル５４０について説明する。図７に示すように、キーワードテーブル５４０は、ＵＲＩ５４１およびキーワード５４２の情報の組を保持する。
【００４２】
次に、案件セッションＩＤ用Ｃｏｏｋｉｅ５５０について説明する。図８に示すように、案件セッションＩＤ用Ｃｏｏｋｉｅ５５０は、案件セッションＩＤ５５１の情報を保持する。図２も参照してさらに説明すると、案件セッションＩＤ格納部１２３に格納している案件セッションＩＤをもとにブラウザ１２１が案件セッションＩＤ用Ｃｏｏｋｉｅ５５０を生成し、ブラウザ１２１がコンテンツ体系化サーバ２００と通信する際にこの案件セッションＩＤ用Ｃｏｏｋｉｅ５５０を併せて送信する。これにより、コンテンツ体系化サーバ２００は、クライアント１００からの各種操作がどの案件セッションでの操作かを捕捉して、関連イベントテーブル５１０の案件セッションＩＤ５１１にその情報を格納することができる。
【００４３】
次に、文書用Ｃｏｏｋｉｅ５６０について説明する。図９に示すように、文書用Ｃｏｏｋｉｅ５６０は、文書ＵＲＩ５６１の情報を保持する。図２も参照してさらに説明すると、文書ＵＲＩ格納部１２６に格納している文書ＵＲＩをもとにブラウザ１２１が文書用Ｃｏｏｋｉｅ５６０を生成し、作成文書保存部１２７が作成文書をコンテンツ体系化サーバ２００に送付する際にこの文書用Ｃｏｏｋｉｅ５６０を併せて送信する。これにより、コンテンツ体系化サーバ２００は、当該作成文書の文書ＵＲＩを捕捉して、作成文書テーブル５７０にその情報を格納できる。
【００４４】
次に、作成文書テーブル５７０について説明する。図１０に示すように、作成文書テーブル５７０は、ＵＲＩ５７１および文書本体５７２の情報の組を保持する。
【００４５】
次に、有効文書巡回用スタック５８０について説明する。図１１に示すように、有効文書巡回用スタック５８０は、有効文書ＵＲＩ５８１の情報を保持する。
【００４６】
（処理）
以下に、関連リンク学習の処理の詳細を説明する。まず、図１２および図１３を用いて、全体フローの動作イメージ、および、クライアント１００とコンテンツ体系化サーバ２００における各構成の関係を説明する。実際には、コンテンツ体系化サーバ２００は、一般的なサーバと同じように、クライアント１００から各種要求を受けてイベントドリブンで動作する。そのため、実際には、図１２にある一連の動作は手続きとしてはこのままでは存在せず断片的に実行されるが、クライアント１００との相互作用によって関連リンク学習の処理はこの順で実行される。
【００４７】
図１２および図１３に示すように、案件セッションＩＤ取得部１２２は、案件セッションＩＤ採番部２２１から案件セッションＩＤを取得して案件セッションＩＤ格納部１２３に格納する（ステップ１００１）。
【００４８】
その後、コンテンツ体系化サーバ２００は、クライアント１００との相互作用によってユーザの操作で作り出される関連を関連イベントとして保存する（ステップ１００２）。ステップ１００２は、実際には複数の関連イベント捕捉手段に依存する処理が互いに非同期に繰り返して実行される。具体的には、関連イベントには、検索キーワード−参照ページ、リンクの遷移（リンク参照によるページ遷移）、および、コピーペーストがある。
【００４９】
まず、検索キーワード−参照ページの関連イベントは、ブラウザ１２１からの検索要求および参照をｐｒｏｘｙ部２２８へ送信し、ｐｒｏｘｙ部２２８がキーワードテーブル５４０を参照したのち関連イベントテーブル５１０に関連イベントを格納する。リンクの遷移については、ブラウザ１２１からのリンクの遷移の要求を、ｐｒｏｘｙ部２２８が受信し、ｐｒｏｘｙ部２２８がこの関連イベントを関連イベントテーブル５１０に格納する。コピーペーストは、コピーペースト捕捉部１２８が捕捉した内容をコピーペースト受付部２２６に送信し、コピーペースト受付部２２６がその内容を関連イベントテーブル５１０に格納する。これらの関連イベントに関する処理の詳細は、図１５、図１６ｃおよび図１６ｄを用いて後記する。
【００５０】
次に、作成文書保存部１２７は、作成文書、案件セッションＩＤおよび文書ＵＲＩを関連学習制御部２２３に送信し、関連学習制御部２２３はこれを受け付ける（ステップ１００３）。このステップ１００３の処理をもって当該案件セッションが終了したとする。関連学習制御部２２３は、作成文書および文書ＵＲＩを作成文書テーブル５７０に保存する（ステップ１００４）。これによって、作成した文書は登録（保存）され、文書間の関連リンク生成の契機となる。
【００５１】
作成文書の登録（ステップ１００４）後に、有効文書一覧生成部２２４は、案件セッション別有効文書一覧の作成を行う（ステップ１００５）。つまり、関連イベントテーブル５１０から、登録された作成文書を起点として現在の案件セッションの範囲で関連イベントを順に辿って文書を抽出し、有効文書巡回用スタック５８０を用いてアクセスした文書のうち当該案件セッションにおいて有効な文書の一覧を作成して案件セッション別有効文書一覧テーブル５２０に格納する。
【００５２】
続いて、関連生成部２２５は、関連リンクの生成を行う（ステップ１００６）。つまり、案件セッション別有効文書一覧テーブル５２０を参照して案件セッション別有効文書の任意の二者間に関連リンクを生成し、関連リンク管理情報５３０に格納する。これによって案件セッション毎の有効文書として、関連リンクが学習される。
【００５３】
以下、各ステップを詳細に説明する。まず、図１２のステップ１００１の案件セッションＩＤの取得処理の詳細について、図１４ａおよび図１４ｂを用いて、それぞれクライアント１００側の動作とコンテンツ体系化サーバ２００側の動作を説明する。
【００５４】
図１４ａは、第１の実施形態のクライアント１００で実行される案件セッションＩＤ取得部１２２による処理フローの一例を示す図である。
案件セッションＩＤ取得部１２２は、図１４ａに示すように、まず、コンテンツ体系化サーバ２００の案件セッションＩＤ採番部２２１に要求し、案件セッションＩＤを取得する（ステップ１１０１）。次に、案件セッションＩＤ取得部１２２は、ステップ１１０１で取得した案件セッションＩＤを案件セッションＩＤ格納部１２３に格納する（ステップ１１０２）。
【００５５】
図１４ｂは、第１の実施形態のコンテンツ体系化サーバ２００で実行される案件セッションＩＤ採番部２２１による処理フローの一例を示す図である。
案件セッションＩＤ採番部２２１は、図１４ｂに示すように、まず、図１４ａのステップ１１０１における案件セッションＩＤ取得部１２２からの要求を受け、案件セッションＩＤを採番する（ステップ１２０１）。次に、案件セッションＩＤ採番部２２１は、ステップ１２０１で採番した案件セッションＩＤを、要求元であるクライアント１００の案件セッションＩＤ取得部１２２に送信する（ステップ１２０２）。
【００５６】
次に、図１２のステップ１００２の関連イベントを関連イベントテーブル５１０に格納する処理の詳細を説明する。前記したように、関連イベントには、検索キーワード−参照ページ、リンクの遷移およびコピーペーストがある。
【００５７】
まず、検索キーワード−参照ページの関連イベント捕捉および格納ついて、図１５および図２を用いて説明する。検索キーワード−参照ページおよびリンクの遷移の関連イベントは、ｐｒｏｘｙ部２２８の処理の一部にて取得し格納する。
【００５８】
（他Ｗｅｂページからの遷移がない場合の処理）
まず、ブラウザ１２１が、アドレスバーへの直接ＵＲＬ（Uniform Resource Locator）の入力もしくはブックマークの選択などによってＷｅｂページを参照するという、他Ｗｅｂページからの遷移がない場合の処理の流れを説明する。この処理の流れの場合、関連イベントの捕捉はないが、捕捉すべき関連イベントであるリンク遷移（リンク参照によるページ遷移）のうち初期ページ遷移の前提として最初に説明する。また、以下の説明に出てくるＧＥＴ要求とは、一般的なプロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）における一般的なリクエストの一つで、ブラウザ１２１からＷｅｂサーバ３０２に対してＷｅｂページの取得を要求するものである。
【００５９】
ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求内容がＧＥＴ要求であり、かつ、参照先が検索結果ページ以外かを判定する（ステップ１３０１）。ここでは、Ｗｅｂページ参照要求はＧＥＴ要求であり、かつ、参照先が検索結果ページ以外であるので（ステップ１３０１でＹｅｓ）、ステップ１３０２に進む。
【００６０】
ステップ１３０２で、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求にリファラ（リンク元のページ）が存在するか判定する。ここで、ブラウザ１２１からの参照は他のＷｅｂページからの遷移ではないためリファラがないので（ステップ１３０２でＮｏ）、ステップ１３１２に進む。
【００６１】
次に、ｐｒｏｘｙ部２２８は、前記ＧＥＴ要求をＷｅｂサーバ３０２に転送する（ステップ１３１２）。
【００６２】
続いて、ｐｒｏｘｙ部２２８は、Ｗｅｂサーバ３０２から前記ＧＥＴ要求のレスポンスを受け取り（ステップ１３１３）、これをブラウザ１２１に送信し（ステップ１３１４）、処理を終了する。
【００６３】
（他Ｗｅｂページからの遷移がある場合の処理）
次に、関連イベントが捕捉されるページ間の遷移がある場合の処理の流れを説明する。これは、ブラウザ１２１がページ内のリンクを辿って他のページを参照した場合である。
【００６４】
この場合は、前記他Ｗｅｂページからの遷移がない場合の処理の流れと同様にステップ１３０２まで進む。ステップ１３０２で、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求にリファラが存在すると判定し（Ｙｅｓ）、ステップ１３０３に進む。
【００６５】
ステップ１３０３で、ｐｒｏｘｙ部２２８は、ブラウザ１２１のリファラが検索結果ページを示しているか判定する。ここで、ブラウザ１２１からの参照は他のＷｅｂページからの遷移なので、ステップ１３０３の判定はＮｏとなり、ステップ１３０４に進む。
【００６６】
次に、ｐｒｏｘｙ部２２８は、リファラを関連先として取得する（ステップ１３０４）。
次に、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求がいずれの案件セッションからの要求かを捕捉するために、ブラウザ１２１からの要求に含まれる案件セッションＩＤ用Ｃｏｏｋｉｅ５５０の値を取得する（ステップ１３１０）。
【００６７】
次に、ｐｒｏｘｙ部２２８は、案件セッションＩＤ、参照先のＵＲＬを関連元、前記ステップ１３０４で取得した関連先を関連先とする関連イベントを関連イベントテーブル５１０に格納する（ステップ１３１１）。また、前記関連イベントの関連元および関連先の種別はそれぞれpとする。
【００６８】
そして、ｐｒｏｘｙ部２２８は、ステップ１３１２に進む。以下、ステップ１３１２からステップ１３１４の処理は前述の動作と同じなので、説明を省略する。
【００６９】
なお、本実施形態では、リファラを用いてコンテンツ体系化サーバ２００にてページ間の遷移を取得することを想定しているが、ユーザがＷｅｂページのハイパーリンクをクリックした情報をクライアント１００のブラウザ１２１で取得する形態であっても良い。
【００７０】
（検索結果から任意のＷｅｂページを選択してページを遷移した場合の処理）
次に、ブラウザ１２１から検索サーバ３０１にて検索を実施し、前記検索の結果から任意のＷｅｂページを選択してページを遷移した場合の検索キーワード−参照文書間の関連イベントの捕捉方法について、図１５および図２を用いて説明する。
【００７１】
まず、ｐｒｏｘｙ部２２８は、ステップ１３０１に進む。ここで、ブラウザ１２１は、ユーザによる検索キーワードの入力を受け付けて検索を実行する。ブラウザ１２１は、検索キーワードをＵＲＬのパラメータに含んでＧＥＴ要求を検索ページに対して要求しているので（つまり、参照先が検索結果ページであるので）、ｐｒｏｘｙ部２２８のステップ１３０１の判定はＮｏとなり、ステップ１３１２に進む。
【００７２】
ｐｒｏｘｙ部２２８は、検索要求を検索サーバ３０１に転送し（ステップ１３１２）、検索サーバ３０１からレスポンスを受信する（ステップ１３１３）。このとき、検索サーバ３０１のレスポンスのＵＲＬは、検索キーワードをパラメータに含んでいる。次に、ｐｒｏｘｙ部２２８は、前記レスポンスをブラウザ１２１に送信する（ステップ１３１４）。この処理フローがブラウザ１２１の検索実行時の動作である。この時点でブラウザ１２１は検索結果ページを取得し、ユーザはそれを閲覧できる。この検索結果ページとは、一般的な検索ページにて検索を実行した際に、その検索結果を一覧として表示しているＷｅｂページである（不図示）。
【００７３】
（検索結果ページから任意のＷｅｂページを選択した場合の処理）
次に、ユーザがブラウザ１２１によって検索結果ページから任意のＷｅｂページを選択し、ｐｒｏｘｙ部２２８に参照要求を出したとする。ｐｒｏｘｙ部２２８は、再び図１５に示す処理を実行し、前述のとおりステップ１３０１に進む。ここで、ブラウザ１２１は検索結果ページから任意のＷｅｂページを選択しているので、ブラウザ１２１は検索結果ページ以外のＷｅｂページのＧＥＴ要求をしており（ステップ１３０１でＹｅｓ）、ｐｒｏｘｙ部２２８はステップ１３０２に進む。
【００７４】
ここで、リファラは検索結果ページを示しているので、ステップ１３０２およびステップ１３０３の判定はＹｅｓとなり、ｐｒｏｘｙ部２２８はステップ１３０５に進む。ｐｒｏｘｙ部２２８は、前記リファラのパラメータ部から検索キーワードを取得して関連先とする（ステップ１３０５）。
【００７５】
次に、ｐｒｏｘｙ部２２８は、前記取得した検索キーワードがキーワードテーブル５４０（図７参照）のキーワード５４２のいずれかに格納済みか判定する（ステップ１３０６）。前記検索キーワードがキーワード５４２に格納済みでなかった場合には（ステップ１３０６でＮｏ）、ｐｒｏｘｙ部２２８は、ステップ１３０７に進み、前記検索キーワードに対するＵＲＩを生成する。
【００７６】
ステップ１３０７の後、ｐｒｏｘｙ部２２８は、前記検索キーワードと前記生成したＵＲＩの組をキーワードテーブル５４０に格納する（ステップ１３０８）。一方、ステップ１３０６で、ｐｒｏｘｙ部２２８が当該検索キーワードは格納済みと判定した場合には（ステップ１３０６でＹｅｓ）、キーワードテーブル５４０を参照して前記検索キーワードに対応するＵＲＩを取得する（ステップ１３０９）。
【００７７】
ステップ１３０８あるいはステップ１３０９の後、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求がいずれの案件セッションからの要求かを捕捉するために、ブラウザ１２１からの要求に含まれる案件セッションＩＤ用Ｃｏｏｋｉｅ５５０の値を取得し（ステップ１３１０）、ステップ１３１１に進む。
【００７８】
ステップ１３１１において、ｐｒｏｘｙ部２２８は、案件セッションＩＤ、ユーザが参照要求を出している前記参照先ＵＲＬを関連元、および前記検索キーワードのＵＲＩを関連先とする関連イベントを関連イベントテーブル５１０に格納する。また、前記関連イベントの関連先の種別はk、関連元はpとする。以下、ステップ１３１２からステップ１３１４の処理は前記と同じなので説明を省略する。
【００７９】
（コピーペーストした場合の処理）
コピーペーストの関連イベントは、エディタ部１２４のコピーペースト捕捉部１２８が捕捉した当該関連イベントをコピーペースト受付部２２６で受信し、関連イベントテーブル５１０に格納する。このコピーペーストの関連イベントを捕捉し格納する処理の詳細を図１６ａ、１６ｂ、図１６ｃおよび図１６ｄを用いて説明する。
【００８０】
図１６ａは、クライアント１００のエディタ部１２４で文書を作成する処理フローの一例を示す図である。
まず、エディタにおける新規文書の作成、編集および格納について、コピーペーストの説明の前提として説明する。
【００８１】
最初に、エディタ部１２４は、エディタ（編集用ソフトウェア）を起動する（ステップ１４０１）。
次に、エディタ部１２４は、文書ＵＲＩ取得部１２５からコンテンツ体系化サーバ２００の文書ＵＲＩ採番部２２２に要求して、作成する文書のＵＲＩを新たに取得する（ステップ１４０２）。
【００８２】
続いて、エディタ部１２４は、文書を入力する（ステップ１４０３）。このステップ１４０３の文書の入力の処理内容の詳細は、図１６ｂおよび図１６ｃで説明する。このステップ１４０３の文書の入力の処理は、図１６ｂおよび図１６ｃで示す処理を１つもしくは複数実行する。そして、エディタ部１２４は、作成文書および文書ＵＲＩを作成文書保存部１２７からコンテンツ体系化サーバ２００へ送信し（ステップ１４０４）、処理を終了する。
【００８３】
次に、コピーペーストによる編集と関連イベントの捕捉や格納について説明する。
図１６ｃは、図１６ａのステップ１４０３の処理フローの一例を示す図である。エディタ部１２４は、ユーザからのペースト要求を受け付け（ステップ１４１１）、コピー元文書のＵＲＩとペーストの内容である選択済みテキストの内容を取得する（ステップ１４１２）。ここで、コピー元テキストの選択はマウスのドラッグ操作によって行われているものとするが、一般的なブラウザの機能なのでここでは詳細に説明しない。
【００８４】
次に、エディタ部１２４は、ユーザの指示により作成中文書に前記取得したテキストを挿入する（ステップ１４１３）。次に、エディタ部１２４は、コンテンツ体系化サーバ２００のコピーペースト受付部２２６へコピー元文書のＵＲＩと作成文書ＵＲＩを送信し（ステップ１４１４）、コピーペーストによる編集を終了する。
【００８５】
次に、図１６ｄを用いて、前記ステップ１４１４にてエディタ部１２４からコピー元文書のＵＲＩと作成文書ＵＲＩを受信したコピーペースト受付部２２６での動作を説明する。コピーペースト受付部２２６は、受信したコピー元文書のＵＲＩと作成文書ＵＲＩをそれぞれ関連イベントテーブル５１０に格納する。
【００８６】
まず、ステップ１４１７で、コピーペースト受付部２２６は、コピー元文書のＵＲＩと作成文書のＵＲＩを受信する（ステップ１４１７）。次に、コピーペースト受付部２２６は、コピー元文書のＵＲＩを関連先、また作成文書のＵＲＩを関連元とする関連イベントを関連イベントテーブル５１０格納する（ステップ１４１８）。また、前記関連イベントの関連先の種別はp、関連元はcとする。
【００８７】
次に、取得する関連イベントは無いが、エディタ部１２４の基本的な動作であるユーザのタイプインによる文書の編集の処理内容を以下に説明する。
【００８８】
図１６ｂは、図１６ａのステップ１４０３の処理フローの一例を示す図である。エディタ部１２４は、ユーザからのタイプインを受け付け（ステップ１４０７）、作成している文書に当該タイプインの内容のテキストを挿入する（ステップ１４０８）。
【００８９】
また、ここまでに説明した関連イベントの取得方法以外に、次のように作成文書中の記載内容から関連イベントを取得しても良い。例えば、作成文書中のＷｅｂページのＵＲＬや文書ＵＲＩ番号などの明示的なリンク情報をパターン認識により抽出し、作成文書を関連元、リンク先の文書を関連先とする関連イベントとして捕捉や格納をしても良い。
【００９０】
以下に、ステップ１４０４の処理を受けて動作する図１２のステップ１００３以降の関連リンクを生成する処理の詳細を説明する。
【００９１】
（関連リンクの生成処理）
まず、関連リンクの生成の処理の全体処理フローを、図１７を用いて説明する。
関連学習制御部２２３は、作成文書保存部１２７から作成文書、案件セッションＩＤおよび文書ＵＲＩを受け付ける（ステップ１００３）。
【００９２】
次に、関連学習制御部２２３は、作成文書および文書ＵＲＩを作成文書テーブル５７０に保存する（ステップ１００４）。これによって、作成した文書は登録され、文書間の関連リンク生成の契機となる。
【００９３】
次に、関連学習制御部２２３は有効文書一覧生成部２２４を起動し、有効文書一覧生成部２２４は、登録された作成文書を起点として現案件セッションの範囲で関連イベントを辿って文書を抽出することで、アクセスした文書のうち当該案件セッションにおいて有効な文書の一覧を作成する（ステップ１００５）。このステップ１００５の処理内容の詳細は、図１８を用いて後記する。
【００９４】
続いて、関連学習制御部２２３は関連生成部２２５を起動し、関連生成部２２５は、案件セッション別有効文書の任意の二者間に関連リンクを生成し（ステップ１００６）、処理を終了する。これによって、案件セッション毎の有効文書として、関連リンクが学習される。このステップ１００６の処理内容の詳細は、図１９を用いて後記する。
【００９５】
（ステップ１００５の処理）
有効文書一覧生成部２２４により実現される、案件セッション別の有効文書一覧を作成する処理（ステップ１００５の処理）について説明する。
【００９６】
図１８に示すように、まず、有効文書一覧生成部２２４は、受け付けた作成文書のＵＲＩを有効文書巡回用スタック５８０にＰＵＳＨする（入れる）（ステップ１５０１）。
【００９７】
次に、有効文書一覧生成部２２４は、有効文書巡回用スタック５８０からＵＲＩをＰＯＰし（出そうと試み）（ステップ１５０２）、ＰＯＰが成功したか判定する（ステップ１５０３）。ステップ１５０３でＰＯＰが成功した場合には（Ｙｅｓ）、有効文書一覧生成部２２４は、案件セッション別有効文書一覧テーブル５２０にステップ１５０２でＰＯＰしたＵＲＩが存在するか判定する（ステップ１５０４）。
【００９８】
ステップ１５０４で「存在しない」と判定した場合、有効文書一覧生成部２２４は、案件セッション別有効文書一覧テーブル５２０に前記ＵＲＩを挿入し（ステップ１５０５）、ステップ１５０６に進む。一方、ステップ１５０４で「存在する」と判定した場合には、ステップ１５０２に戻る。
【００９９】
ステップ１５０６で、有効文書一覧生成部２２４は、関連イベントテーブル５１０を前記案件セッションＩＤで絞り込み、関連イベントテーブル５１０の関連元ＵＲＩ５１２に対して前記ステップ１５０２でＰＯＰしたＵＲＩをサーチする。サーチでヒットするごとにステップ１５０７で当該ヒットした関連イベントテーブル５１０のレコードの関連先ＵＲＩ５１４の値を有効文書巡回用スタック５８０にＰＵＳＨする。前記サーチが完了したならばステップ１５０８からステップ１５０２に戻る。これらの処理を繰り返し、ステップ１５０３で有効文書巡回用スタック５８０からＵＲＩ５８１をＰＯＰができなった場合（Ｎｏ）、つまり、有効文書巡回用スタック５８０が空になれば処理を終了する。
【０１００】
（ステップ１００６の処理）
関連生成部２２５により実現される、案件セッション別有効文書の任意の二者間に関連リンクを生成する処理について説明する。図１９に示すように、関連生成部２２５は、ステップ１６０１で案件セッション別有効文書一覧テーブル５２０を案件セッションＩＤで絞り込み、関連元としてＵＲＩおよび種別を取得する。
【０１０１】
次に、ステップ１６０２で、関連生成部２２５は、ステップ１６０１で案件セッション別有効文書一覧テーブル５２０を案件セッションＩＤで絞り込み、関連先としてＵＲＩおよび種別を取得する。次に、関連生成部２２５は、ステップ１６０１とステップ１６０２で取得した関連元と関連先の内容（値）が等しいかを判定する（ステップ１６０３）。
【０１０２】
次に、関連生成部２２５は、ステップ１６０３でＮｏと判定した場合にはステップ１６０４に進み、関連リンク管理情報５３０に前記関連元および関連先の情報が格納済みであるか判定する。ステップ１６０４で格納済みでないと判定した場合には（Ｎｏ）、ステップ１６０５に進む。ステップ１６０５で関連生成部２２５は、関連リンク管理情報５３０に関連元および関連先の情報をカウンタ「１」で挿入する。一方、ステップ１６０４で格納済みと判定した場合には（Ｙｅｓ）、ステップ１６０６に進む。ステップ１６０６で関連生成部２２５は、関連リンク管理情報５３０の関連元および関連先と等しいレコードのカウンタの値に「１」加えて更新する。関連生成部２２５は、ステップ１６０１〜１６０８とステップ１６０２〜１６０７による２重ループで案件セッション別有効文書一覧テーブル５２０の全ての任意の二者間に関連リンクを生成する。以上が、関連リンク学習の処理詳細である。
【０１０３】
≪レコメンド実行時の処理≫
次に、本実施形態におけるレコメンド実行時の処理詳細を説明する。ここでは、クライアント１００のブラウザ１２１が検索するための検索キーワードの入力を受け付けた場合に、コンテンツ体系化サーバ２００から前記検索キーワードに関連する検索キーワードを提示する場面を想定する。
【０１０４】
（検索キーワードのレコメンドを受けるときの処理）
まず、検索キーワードのレコメンドを受けるときのクライアント１００のブラウザ１２１による処理フローを説明する。図２０ａに示すように、ブラウザ１２１は、検索サーバのＵＲＬを指定してＧＥＴを要求し（ステップ１７０１）、検索用のページを表示する（ステップ１７０２）。
【０１０５】
次に、ブラウザ１２１は、ユーザからの検索キーワードを受け付け（ステップ１７０３）、前記検索キーワードをＵＲＬのパラメータに含めてコンテンツ体系化サーバ２００に対してＧＥＴ要求を送信する（ステップ１７０４）。
【０１０６】
次に、ブラウザ１２１は、コンテンツ体系化サーバ２００から検索結果を受信し（ステップ１７０５）、ブラウザ１２１内のＨＴＭＬレンダリング部１２９が検索結果をレンダリング（データの可視化）する（ステップ１７０６）。
【０１０７】
次に、ブラウザ１２１は、コンテンツ体系化サーバ２００から検索キーワードのレコメンド内容を受信する（ステップ１７０７）。そして、ブラウザ１２１内のＨＴＭＬレンダリング部１２９は、ポップアップしたウインドウに検索キーワードのレコメンドを表示する（ステップ１７０８）。
【０１０８】
（レコメンドを実行する場合の処理）
次に、レコメンドを実行する場合のコンテンツ体系化サーバ２００の処理フローを説明する。概要を説明すると、コンテンツ体系化サーバ２００は、ｐｒｏｘｙ部２２８がクライアント１００から検索キーワードを受信し、当該検索キーワードに関連がある検索キーワードを関連リンク管理情報５３０から抽出してクライアント１００に送信する。
【０１０９】
具体的には、図２０ｂに示すように、まず、コンテンツ体系化サーバ２００のｐｒｏｘｙ部２２８がクライアント１００から検索キーワードを受信する（ステップ１８０１）。次に、ｐｒｏｘｙ部２２８は、キーワードレコメンド生成部２２７を起動し、キーワードレコメンド生成部２２７がキーワードテーブル５４０をサーチして前記検索キーワードのＵＲＩを取得できるか判定する（ステップ１８０２）。検索キーワードのＵＲＩを取得できると判定した場合には（ステップ１８０２でＹｅｓ）、キーワードレコメンド生成部２２７は、関連リンク管理情報５３０の関連元が検索キーワードのＵＲＩであり、関連先の種別がｋであるレコードをサーチする（ステップ１８０３）。
【０１１０】
次に、キーワードレコメンド生成部２２７は、サーチ結果を関連リンク管理情報５３０のカウンタ５３５（図６参照）の値でソートする（ステップ１８０４）。
【０１１１】
次に、キーワードレコメンド生成部２２７は前記ソートしたサーチ結果をｐｒｏｘｙ部２２８に受け渡し、ｐｒｏｘｙ部２２８はブラウザ１２１に前記ソートしたサーチ結果を送信する（ステップ１８０５）。こうすることでブラウザ１２１は、入力した検索キーワードに関連する検索キーワードのレコメンドを受けることができる。
【０１１２】
（具体事例）
以下に、図２１ａおよび図２１ｂを用いて、第１の実施形態の具体事例について説明する。この具体事例では、調査内容としてファイルシステムのバックアップを高速に取得する方法を調査し、調査の結果としてバックアップコマンドを使うのではなく、代替策としてスナップショットおよびＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成にするという方法をとることが適していると分かったとする。この調査の結果からそれぞれの文書間に関連リンクを学習する。これによって他のユーザが類似案件を調査する際に、検索キーワード「バックアップ」で検索するとそれぞれのマニュアルページに素早く到達する検索キーワード「スナップショット」「ＲＡＩＤ」がユーザに提示されることを想定する。以下にこの具体事例の詳細を説明する。
【０１１３】
まず、関連リンク学習時の具体事例について、図２１ａを用いて説明する。図２１ａは、（ａ）が検索キーワードとＷｅｂページと作成文書との関係を示す概念図であり、（ｂ）がキーワードテーブル、関連イベントテーブルおよび関連リンク管理情報の例を示す図である。
【０１１４】
ここで、クライアント１００を操作するユーザは、ファイルシステムのバックアップの高速化について調査していたとする。想定する状況としては、ファイルシステムのバックアップに時間がかかりすぎて業務に支障があり、より短時間でバックアップを完了させたいという状況であったとする。
【０１１５】
ユーザは、まず、「バックアップ（k1-a）」および「高速化（k1-b）」を検索キーワードに指定して検索したとする。そして、検索結果から、「バックアップ方法のマニュアル（p1-a）」を参照したとする。この参照から、バックアップコマンドの使用方法の工夫にて、バックアップの所要時間を短縮するのは不可能だと判明したとする。
【０１１６】
次に、「バックアップ（k1-a）」および「高速化（k1-b）」にて検索した結果の一覧から「ホットスタンバイに関する断片的な解説（p1-b）」を参照し、断片的な情報ではあるがホットスタンバイによりバックアップの高速化ができるかもしれないという情報を得たとする。ユーザは、ホットスタンバイの詳細ついて調査するために「ホットスタンバイ（k2）」を検索キーワードに検索し、「ホットスタンバイ設定のマニュアル（p2）」を参照したとする。ここで、ユーザは、ホットスタンバイは可用性を高め、またプロセスを多重化する方法であるという情報を得たとする。バックアップは、耐久性を高め、またデータを多重化する方法であるため、ホットスタンバイは、バックアップの代替案に成り得ないとユーザは判断した。
【０１１７】
さらに、先ほどの「バックアップ（k1-a）」および「高速化（k1-b）」にて検索した結果の一覧から「スナップショットに関する断片的な解説（p1-c）」を参照し、以下の情報を得たとする。スナップショットは、ある時点での仮想的なバックアップを取りその時点からの変更部分のみを記憶することで、ユーザの操作誤りに対する障害に対応する技術である。ただし、スナップショットの適用時に、メディア障害に対応するためには併せて冗長化が必要だと判明したとする。
【０１１８】
次に、前記ユーザは、スナップショットに関する詳細を調査するため「スナップショット（k3）」を検索キーワードに検索し、「スナップショット設定のマニュアル（p3）」を参照したとする。ここで、前記ユーザはスナップショットの取り方を理解したとする。また、冗長化について調査するために「冗長化（k4）」を検索キーワードに検索し、その検索結果から「冗長化の解説文書（p4）」を参照したとする。この参照により、ＲＡＩＤ構成をとることで、本調査における冗長化に対応できると判明したとする。よって、前記ユーザは次にＲＡＩＤの詳細について調査を進めることとしたとする。次に、ユーザは「ＲＡＩＤ（k5）」を検索キーワードに検索し、「ＲＡＩＤ構成のマニュアル（ｐ５）」を参照して、手順を理解したとする。
【０１１９】
ユーザは以上の調査の結果として、次のようにまとめた文書（c1）を作成したとする。つまり、「バックアップコマンドの工夫によりバックアップを高速化することはできないが（p1-aの文書を参照）、代替策として、スナップショット（p3の文書を参照）およびＲＡＩＤ（p5の文書を参照）を使うことでバックアップの高速化と同等のことができる」とまとめた文書（c1）を作成した。
【０１２０】
文書（c1）の作成には、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」を参照および引用している。また、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」を検索するにあたっては、それぞれ「バックアップ（k1-a）」および「高速化（k1-b）」、「スナップショット（k3）」、「ＲＡＩＤ（k5）」を検索キーワードとして検索した。
【０１２１】
これらの関連イベントは、関連イベントテーブル５１０ａに格納されている。そして、関連リンク管理情報５３０ａに示すように（一部図示を省略）、文書c1、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」、「バックアップ（k1-a）」、「高速化（k1-b）」、「スナップショット（k3）」、「ＲＡＩＤ（k5）」の任意の二文書間に関連リンクを生成する。
【０１２２】
次に、レコメンド実行時の動作の具体事例について、図２１ｂを用いて説明する。前記関連リンク学習時のユーザとは別のユーザが、類似案件の調査において「バックアップ」という言葉を検索キーワードとして検索を実行したとする。キーワードテーブル５４０ａに示すように、検索キーワード「バックアップ」は前記関連リンクの学習においてk1-aとしたものである。また、関連リンク管理情報５３０ａに示すように、検索キーワード「バックアップ（k1-a）」と関連リンクが存在する検索キーワードとしては、k3とした「スナップショット」、およびk5とした「ＲＡＩＤ」がある。ここでは、検索キーワードの入力時に、関連する検索キーワードを提示する状況を想定しているので、関連先の種別がkであるものを開示している。
【０１２３】
よって、関連リンク管理情報５３０ａからわかるように、「バックアップ」という検索キーワードにて検索するときには、「スナップショット」および「ＲＡＩＤ」という検索キーワードをユーザに提示することができる。このように、関連リンクが存在する検索キーワードの提示を受けることで、ユーザはより素早く有効な検索キーワードに到達することができる。そして、有効な検索キーワードに素早く到達することで、結果として有効な文書により素早く到達することができる。このように、ユーザが試行錯誤的に様々に検索キーワードを入力して、文書を閲覧する回数を減らすことができる。つまり、先人の検索履歴を有効に活用し、先人のノウハウを活用することができる。
【０１２４】
なお、この例の場合、従来のキーワードの共起に着目した統計処理（特許文献１参照）等を用いる技術では、「バックアップ」という検索キーワードに基づいて「スナップショット」や「ＲＡＩＤ」という検索キーワードをレコメンドできない可能性が少なからずあるが、本実施形態の手法によれば、そのようなレコメンドを確実に実現することができる。
【０１２５】
＜第２の実施形態＞
【０１２６】
次に、第２の実施形態について説明する。第２の実施形態は、関連リンクの生成およびその保存の方法が第１の実施形態とは異なる。第１の実施形態では、関連イベントテーブル５１０から一度、案件セッション別有効文書の一覧を求めた後に、これを利用して関連リンクを作成する。一方、第２の実施形態では、関連イベントテーブル５１０を用いて案件セッション別有効文書一覧テーブル５２０ａを作成するステップの中で関連リンクを作成する。また、関連リンクは第１の実施形態では関連イベントテーブル５１０の形式で関連リンクの情報を保持していたが、第２の実施形態ではオブジェクトのグラフ形式で生成する。
【０１２７】
まず、ソフトウェアの構成に関して、第１の実施形態と異なる箇所を説明する。第２の実施形態におけるソフトウェアおよびハードウェアの構成を図２２に示す。第１の実施形態と異なる箇所は、関連生成部２２５ａ、キーワードレコメンド生成部２２７ａ、関連リンク管理情報５３０ａ、案件セッション別有効文書一覧テーブル５２０ａ、探索の訪問済み文書管理テーブル６４０および関連リンク生成用スタック６５０であり、また、有効文書一覧生成部２２４がない。関連生成部２２５ａおよびキーワードレコメンド生成部２２７ａの処理内容は後記する。
【０１２８】
まず、関連リンク管理情報５３０ａに関して説明する。関連リンク管理情報５３０ａは、複数の関連リンクノード６１０（図２３参照）、複数の文書ノード６２０（図２４参照）およびＵＲＩ−文書ノード対応管理テーブル６３０（図２５参照）により構成し、これらにより関連リンクの情報を示す。
【０１２９】
関連リンクノード６１０の一例を図２３に示す。関連リンクノード６１０は、関連度６１１および文書ノード６２０へのポインタ６１２からなる情報の組を持つ。関連度６１１は、どの程度に当該関連リンクが関連付ける文書間の関連が強いかを示す指標値であり、第１の実施形態における関連リンク管理情報５３０のカウンタ５３５（図６参照）に相当（対応）するものである。
【０１３０】
文書ノード６２０の一例を図２４に示す。文書ノード６２０は、当該文書を表すＵＲＩ６２１、文書の種別６２２、および、１つもしくは複数の関連リンクノード６１０へのポインタを格納するポインタ６２３のリストからなる情報の組を持つ。ポインタ６２３のリストは配列、リンクトリスト等で実装されるが、プログラミング言語の実行環境における標準ライブラリが提供するものとして、本実施形態では詳細な説明を省略する。
【０１３１】
ＵＲＩ−文書ノード対応管理テーブル６３０の一例を図２５に示す。ＵＲＩ−文書ノード対応管理テーブル６３０は、文書のＵＲＩ６３１と文書ノードへのポインタ６３２の情報の組を保持する。
【０１３２】
次に、関連リンクノード６１０および文書ノード６２０で表す関連リンクのグラフ構造およびＵＲＩ−文書ノード対応管理テーブル６３０の一部の一例を図２６に示す。
図２６では、各文書ノードから関連リンクノード６１０をポイントして（指して）いる。また、各関連リンクノード６１０から、文書ノードをポイントしている。また、図２６において、関連リンクノード６１０中に示す値は関連度６１１を示している。このように、第２の実施形態ではグラフ構造で関連リンクの情報を持つ。
【０１３３】
案件セッション別有効文書一覧テーブル５２０ａおよび探索の訪問済み文書管理テーブル６４０の一例を図２７に示す。案件セッション別有効文書一覧テーブル５２０ａは、ＵＲＩ５２２ａの情報を持つ。探索の訪問済み文書管理テーブル６４０は、ＵＲＩ６４１の情報を持つ。この案件セッション別有効文書一覧テーブル５２０ａと探索の訪問済み文書管理テーブル６４０は、後記する探索において文書を訪問したか否かを管理するために用いる。
【０１３４】
第２の実施形態では、関連リンクノード６１０の関連度６１１の算出のために関連リンク生成用スタック６５０を用いる。関連リンク生成用スタック６５０の一例を図２８に示す。関連リンク生成用スタック６５０は、文書のＵＲＩ６５１をスタックしている。また、関連リンク生成用スタック６５０の要素の数を示す要素数６５２を持つ。関連リンク生成用スタックに要素をＰＵＳＨする際には要素数６５２の値を「１」加え、また、ＰＯＰする際には要素数６５２の値を「１」減らす。なお、この関連リンク生成用スタック６５０は、第１の実施形態における有効文書巡回用スタック５８０のような、関連イベントによるツリー構造を探索するためのものではない。
【０１３５】
次に、図２９および図３０を用いて、全体フローの動作イメージおよび各構成の関係を説明する。ステップ１００１〜ステップ１００４の処理内容は第１の実施形態と同じである。そして、第１の実施形態（図１２参照）では関連イベントテーブル５１０から案件セッション別有効文書一覧テーブル５２０を生成（ステップ１００５）して関連リンクの生成（ステップ１００６）をしていたが、第２の実施形態では関連イベントテーブル５１０から案件セッション別有効文書一覧テーブル５２０ａを作成するステップの中で関連リンクを生成する（ステップ１００６ａ）。その概要を説明すると、関連生成部２２５ａは、関連イベントテーブル５１０を参照し、案件セッション別有効文書一覧テーブル５２０ａ、探索の訪問済み文書管理テーブル６４０および関連リンク生成用スタック６５０を用いて関連リンクを生成する。そして、関連生成部２２５ａは、生成した関連リンクの情報を関連リンク管理情報５３０ａに格納する。
【０１３６】
関連リンクを生成するステップ１００６ａの処理の詳細を説明する。以下ではステップ１００４までの処理で、関連イベントテーブル５１０には関連イベントの各情報が第１の実施形態と同様に格納され、かつ、クライアント１００からコンテンツ体系化サーバ２００に作成文書が登録されたとして、それ以降の処理を説明する。
【０１３７】
関連イベントテーブル５１０の情報から関連リンクを生成する処理（ステップ１００６ａ）の詳細を、図３１ａ〜図３１ｄおよび図２２を用いて説明する。図３１ａ〜図３１ｄの処理では、関連イベントテーブル５１０に格納している情報に基づいて、作成文書を起点とする探索を２重にループすることにより、有効文書の任意の二文書間の関連リンクを生成する。
【０１３８】
図３１ａにおける関連リンクの生成の処理フローで、まず、関連生成部２２５ａは作成文書のＵＲＩを引数として第１の探索を行う（ステップ１９０１）。このステップ１９０１でいう作成文書とは、ステップ１００３（図２９参照）で関連学習制御部２２３がクライアント１００から受け付けた作成文書のことである。
【０１３９】
（第１の探索の処理）
次に、ステップ１９０１の第１の探索の処理内容の詳細を、図３１ｂおよび図２２を用いて説明する。
第１の探索（ステップ１９０１）は、文書のＵＲＩを引数として呼び出される。まず、関連生成部２２５ａは、引数で指定された文書のＵＲＩを第１の関連リンク生成用スタック６５０ａにＰＵＳＨする（ステップ１９０３）。なお、関連リンク生成用スタック６５０として、第１の関連リンク生成用スタック６５０ａと、第２の関連リンク生成用スタック６５０ｂとがあるものとする。
【０１４０】
次に、関連生成部２２５ａは、第１の探索の引数であるＵＲＩを案件セッション別有効文書一覧テーブル５２０ａに格納する（ステップ１９０４）。
次に、関連生成部２２５ａは、探索の訪問済み文書管理テーブル６４０の内容をクリアする（ステップ１９０５）。
【０１４１】
そして、関連生成部２２５ａは、第１の探索を呼び出したときの引数のＵＲＩを引数に第２の探索を呼び出す（ステップ１９０６）。この第２の探索の処理内容の詳細は後記する。
【０１４２】
関連生成部２２５ａは、引数である文書のＵＲＩを関連イベントテーブル５１０の関連元のＵＲＩ５１２（図４参照）に持つレコードに対してステップ１９０７〜１９１０の処理を繰り返す。ただし、この繰り返し処理は、前記作成文書と同じ案件セッションＩＤを関連イベントテーブル５１０の案件セッションＩＤ５１１に持つレコードに対して実施する。
【０１４３】
関連生成部２２５ａは、前記レコードにおける関連先のＵＲＩ５１４が案件セッション別有効文書一覧テーブル５２０ａ（図２７参照）に存在するか判定する（ステップ１９０８）。ステップ１９０８で「存在しない」と判定した場合、ステップ１９０９に進む。一方、ステップ１９０８で「存在する」と判定した場合、ステップ１９１０に進む。
ステップ１９０９で、関連生成部２２５ａは、前記関連先のＵＲＩを引数にして第１の探索を再帰的に呼び出す。
【０１４４】
ステップ１９０７〜１９１０の処理の終了後、関連生成部２２５ａは、ステップ１９１１で第１の関連リンク生成用スタック６５０ａから要素をＰＯＰし、処理を終了する（ステップ１９１２）。
【０１４５】
（第２の探索の処理）
次に、第２の探索（図３１ｂのステップ１９０６）の処理の内容を、図３１ｃを用いて説明する。
まず、関連生成部２２５ａは、第２の関連リンク生成用スタック６５０ｂに、第２の探索の呼び出し時に引数で指定された文書のＵＲＩをＰＵＳＨする（ステップ１９２１）。
【０１４６】
次に、関連生成部２２５ａは、第２の探索の引数であるＵＲＩを探索の訪問済み文書管理テーブル６４０に格納する（ステップ１９２２）。
次に、関連生成部２２５ａは、第２の探索の引数のＵＲＩと第２の探索を呼び出した第１の探索の引数のＵＲＩが等しいか判定する（ステップ１９２３）。同一文書への関連リンクを生成する必要はないため、このステップ１９２３の判定は、第１の探索および第２の探索で同一文書を見ているか否かを判定するための処理である。
【０１４７】
ステップ１９２３で関連生成部２２５ａがＮｏと判定した場合には、ステップ１９２４に進む。ステップ１９２４で、関連生成部２２５ａは文書間の関連度６１１を算出する。ステップ１９２４の処理の詳細は、後に図３１ｄを用いて説明する。
【０１４８】
次に、関連生成部２２５ａは、ＵＲＩ−文書ノード対応管理テーブル６３０をサーチして、第２の探索呼び出し時の引数のＵＲＩが示す文書ノードを取得する。（ステップ１９２５）。
【０１４９】
次に、関連生成部２２５ａは、第２の探索呼び出し時の第１の探索の引数のＵＲＩから第２の探索の引数のＵＲＩへの関連リンクノードが存在するか判定する（ステップ１９２６）。
関連リンクノード６１０は存在しないと判定した場合（ステップ１９２６でＮｏ）、関連生成部２２５ａは、ステップ１９２７に進む。
一方、関連リンクノード６１０は存在すると判定した場合（ステップ１９２６でＹｅｓ）、関連生成部２２５ａは、ステップ１９２８に進む。
【０１５０】
ステップ１９２７で、関連生成部２２５ａは、新たに関連リンクノード６１０を生成し、前記生成した関連リンクノード６１０に第２の探索の引数である文書のＵＲＩを持つ文書ノードへのポインタおよびステップ１９２４で算出した関連度６１１の値を格納する。また、併せて、第２の探索を呼び出した第１の探索の引数の文書のＵＲＩをＵＲＩ６２１に持つ文書ノード６２０における関連リンクノード６１０へのポインタに前記生成した関連リンクノード６１０へのポインタを追加する。
【０１５１】
一方、ステップ１９２８では、関連生成部２２５ａは、既存の関連リンクノード６１０に前記算出した関連度６１１の値を加えて更新する。
【０１５２】
次に、関連生成部２２５ａは、引数である文書のＵＲＩを関連イベントテーブル５１０の関連元のＵＲＩ５１２に持つレコードに対してステップ１９２９〜１９３２の処理を繰り返す。ただし、この繰り返し処理は、前記作成文書と同じ案件セッションＩＤを関連イベントテーブル５１０の案件セッションＩＤ５１１に持つレコードに対して実施する。
【０１５３】
関連生成部２２５ａは、前記レコードにおける関連先のＵＲＩ５１４が探索の訪問済み文書管理テーブル６４０に存在するか判定する（ステップ１９３０）。ステップ１９３０で「存在しない」と判定した場合、ステップ１９３１に進む。一方、ステップ１９３０で「存在する」と判定した場合、ステップ１９３２に進む。
【０１５４】
ステップ１９３１で、関連生成部２２５ａは、前記関連先のＵＲＩを引数にして第２の探索を再帰的に呼び出す。
【０１５５】
ステップ１９２９〜１９３２の処理の終了後、関連生成部２２５ａは、ステップ１９３３で第２の関連リンク生成用スタック６５０ｂから要素をＰＯＰし、処理を終了する。
【０１５６】
（関連度の算出処理）
次に、ステップ１９２４の関連度６１１の算出処理の詳細を、図３１ｄおよび図２２を用いて説明する。
【０１５７】
関連度６１１の算出には、まず文書間の距離を算出する。文書間の距離とは、２つの有効文書間がいくつの関連イベントで辿り着けるかというホップ数である。距離の算出は、第１の関連リンク生成用スタック６５０ａと第２の関連リンク生成用スタック６５０ｂとを比較して求める。
【０１５８】
まず、関連生成部２２５ａは、ステップ１９４１で第１の関連リンク生成用スタック６５０ａの要素の最大数になるまでの間、ステップ１９４２の処理を繰り返す。このステップ１９４２を繰り返し実行する回数をｉとしたとき、関連生成部２２５ａは第１および第２の関連リンク生成用スタック６５０ａ、６５０ｂのそれぞれ下からｉ番目の値が等しいか判定する。ただし、このｉの値は「０」からはじまるものとする。関連生成部２２５ａはステップ１９４２でＹｅｓと判定した場合には、ステップ１９４１〜ステップ１９４３の繰り返し処理を抜けてステップ１９４４に進む。
【０１５９】
次に、ステップ１９４４で、関連生成部２２５ａは、第１の関連リンク生成用スタック６５０ａの要素数６５２ａとiの値の差を算出する。
次にステップ１９４５で、関連生成部２２５ａは、第２の関連リンク生成用スタック６５０ｂの要素数６５２ｂとiの値の差を算出する。
【０１６０】
次にステップ１９４６で、関連生成部２２５ａは、ステップ１９４４とステップ１９４５で算出した値の和を求める。この和の値が、距離の値である。
【０１６１】
次に、ステップ１９４７で、関連生成部２２５ａは、ステップ１９４６で算出した距離の値の逆数を求め、この値を関連度６１１の値とする。ただし、関連度６１１の値はこのように逆数により算出する方法に限るわけでなく、他の方法により関連度６１１を算出し設定してもかまわない。
【０１６２】
第２の実施形態における関連リンクの生成に関する具体事例を、図２６を用いて説明する。図２６に示すように、ｋ１からｋ２に新たに関連リンクノード６１０を生成する場合、ｋ２を示す文書ノードへのポインタを持つ関連リンクノード６１０ａを生成する。そして、この生成した関連リンクノード６１０ａへのポインタを、ｋ１の文書ノードに加える。ここで、ｋ１からｋ２への距離は「５」だったすると、その逆数である「０．２」を関連度６１１として、前記生成した関連リンクノード６１０ａは持つ。
【０１６３】
一方、既存の関連リンクノード６１０に前記算出した関連度６１１の値を加えて更新する場合の具体事例も、同様に図２６を用いて説明する。ｐ１からｋ１に関連リンクノード６１０ｂは存在し、その関連度６１１はあるとき「２．０」だったとする。そして、新たに、ｐ１からｋ１への距離が「１」であり、距離の逆数である関連度６１１が「１」となる場合があったとする。このとき、ｐ１からｋ１への関連リンクを示す関連リンクノード６１０の関連度６１１は「３．０」となり、図２６に示すように、ｐ１からｋ１への関連リンクを示す関連リンクノード６１０ｂが更新される。ここまでが、関連リンク学習の処理詳細である。
【０１６４】
次に、第２の実施形態におけるレコメンド実行時の処理詳細を説明する。第１の実施形態におけるレコメンド実行時と同様に、クライアント１００のブラウザ１２１が検索するために検索キーワードの入力を受け付けた場合に、コンテンツ体系化サーバ２００から前記検索キーワードに関連する検索キーワードをユーザに提示する場面を想定する。また、クライアント１００側のブラウザ１２１の動作は第１の実施形態と同様なので、説明を省略する。ここでは、第１の実施形態と異なるキーワードレコメンド生成部２２７ａの処理内容を、図３２を用いて説明する。
【０１６５】
図３２は、第２の実施形態におけるレコメンド実行時のコンテンツ体系化サーバ２００の処理内容を示すフローの一例である。また、図３２のステップ１８０１およびステップ１８０２の処理内容は、それぞれ図２０ｂにおけるステップ１８０１およびステップ１８０２の処理内容と同様である。
【０１６６】
次に、キーワードレコメンド生成部２２７ａは、ステップ１８０２で取得した検索キーワードのＵＲＩを持つ文書ノード６２０をサーチする（ステップ２００１）。次に、キーワードレコメンド生成部２２７ａは、ステップ２００１で取得した文書ノード６２０における関連リンクノードへのポインタ６２３をサーチして、関連リンクノード６１０を取得する（ステップ２００２）。
【０１６７】
次に、キーワードレコメンド生成部２２７ａは、ここまでの処理で取得した関連リンクを、それぞれの関連リンクノード６１０の関連度６１１（図２３参照）の値でソートする（ステップ２００３）。次に、キーワードレコメンド生成部２２７ａは、前記ソートしたサーチ結果をｐｒｏｘｙ部２２８に受け渡し、ｐｒｏｘｙ部２２８はブラウザ１２１に前記ソートしたサーチ結果を送信し（ステップ１８０５）、処理を終了する。このようにして、ブラウザ１２１は、入力した検索キーワードに関連する検索キーワードのレコメンドを受けることができる。
【０１６８】
このように、本実施形態の関連文書表示システム１０００によれば、電子データである文書の集合を用いた調査業務等において、文書の検索時に、例えば、前記した例では、「バックアップ」という検索キーワードに基づいて「スナップショット」や「ＲＡＩＤ」という適切な検索キーワードを確実にレコメンドすることができる。
【０１６９】
つまり、従来技術とは異なり、結果集合が論理和(OR)となるような関連キーワードを提示することができる。この場合、現在の検索結果集合には必ずしも存在しないが、業務上関連の深い情報を効率良く提示できることが重要である。
また、過去の検索履歴データを案件セッションごとに解析して利用するので、一般的に統計処理に向かない程度に参照回数が少ない業務においても情報同士の関連を提示することができる。
【０１７０】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、本実施形態では、クライアント１００、コンテンツ体系化サーバ２００、検索サーバ３０１およびＷｅｂサーバ３０２を、それぞれ別々のハードウェア構成として説明したが、それらの任意の２つ以上がハードウェア的に１つのものとして構成されていても良い。
【０１７１】
また、案件セッションの開始は、ユーザが明示的に指示することによって認識しても、あるいは、ユーザによる検索キーワードの入力があったときに自動的に認識するようにしても、いずれでも良い。
また、案件セッションの開始を認識しなくても、ユーザによる検索の操作内容を常時記憶しておき、所定の文書（c1）が作成されたときに、その対応する案件セッションについて、常時記憶した操作内容に基づき、関連イベントがあった任意の二者を関連イベントテーブル５１０に記憶するようにしても良い。
【０１７２】
また、本実施形態では、レコメンド実行時の処理に関して、ユーザが検索キーワードを入力したときに関連する検索キーワードを提示する場合について説明したが、ユーザが文書を閲覧したときに関連する文書を提示する場合など、他の場面にも適用することができる。
【０１７３】
なお、関連文書表示システム１０００を構成する各コンピュータに実行させるためのプログラムを作成し、コンピュータにインストールすることにより、各コンピュータは、そのプログラムに基づいた各機能を実現することができる。
その他、ハードウェア、プログラム等の具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【０１７４】
１００ クライアント
１２１ ブラウザ
１２４ エディタ部
１２９ ＨＴＭＬレンダリング部
２００ コンテンツ体系化サーバ
２２３ 関連学習制御部
２２８ ｐｒｏｘｙ部（レコメンド制御部）
３００ ＬＡＮ
３０１ 検索サーバ
３０２ Ｗｅｂサーバ
５１０ 関連イベントテーブル（関連イベント記憶部）
５２０ 案件セッション別有効文書一覧テーブル
５３０ 関連リンク管理情報（関連リンク記憶部）
１０００ 関連文書表示システム
【技術分野】
【０００１】
本発明は、電子データである文書の集合からユーザが文書を閲覧する際に、関連する文書を推薦（表示）するレコメンデーション機能に関する。
【背景技術】
【０００２】
あいまいな既存情報から調査をすすめて、所望する情報を得る業務がある。例えば、顧客からの問合せ内容に対してユーザ（調査者）が社内システムやインターネット等を利用して文書を調査し、調査結果を顧客に回答するテクニカルサポートセンタやヘルプデスクといった調査業務である。
【０００３】
前記調査業務において、ユーザは社内システムやインターネットでの検索やリンクを辿るなど試行錯誤して多くの参考文書を参照する。この方法では、一般に、情報提供者（Ｗｅｂページ提供者等）の観点でしか情報検索できないため、作業効率が悪い。
【０００４】
一方、利用者の観点で情報をレコメンドする技術には以下のものがある。例えば、ブラウザの検索キーワード入力欄に検索キーワードを入力すると、統計的に学習した関連のある検索キーワードを提示する技術である（特許文献１参照）。その他には、インターネット書籍販売サイトにてユーザが書籍を参照した際に、過去のユーザの購入履歴に基づき前記参照する書籍を購入した人が別途購入した書籍を提示する技術である（特許文献２参照。「書籍」が本発明における「文書」と対応）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００５／０１９８０６８号明細書
【特許文献２】米国特許第６２６６６４９号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前記した従来技術においては、以下の課題がある。
まず、特許文献１の技術では、インターネットにおける膨大な情報から適切な情報を選別することを目的にしている。つまり、扱う情報量が膨大であるため、一般に、少数の検索キーワードで検索しただけでは検索結果集合も大きなものとなり、一覧から適切な情報を選別することが困難となる。
【０００７】
これを解決するために、特許文献１の技術では、検索結果をより小さく絞り込むために、同一キーワードを多数含む膨大な検索ログを対象にキーワードの共起に着目した統計処理を行い、論理積（ＡＮＤ）条件となる検索キーワード候補を抽出する。例えば、「不況」というキーワードで検索すると、「原因」や「節約」といった検索キーワードが同時検索の候補としてレコメンド（推薦）される。
【０００８】
一方、企業内のＬＡＮ（Local Area Network）システム等を利用した業務（以下、単に「業務」という。）では、インターネットに比べて対象とする情報量および検索トラフィック密度が少ないため、論理積（ＡＮＤ）条件となる検索キーワードによる絞込検索よりも、現在の検索結果集合には必ずしも存在しないが、業務上関連の深い情報を効率良く提示することがより重要である。検索でいえば検索キーワード入力欄を一度クリアした後に入力するようなキーワード候補を提示することが重要である。しかし、特許文献１の技術では、結果集合が論理和（ＯＲ）となるような関連キーワードを提示することができない。なお、論理積（ＡＮＤ）を求めるための絞り込むキーワードの場合、検索ログを大量に得ることが困難な業務においては適切にレコメンドすることができない。
【０００９】
また、特許文献２の技術では、複数のユーザが過去に参照した情報から関連を統計的に学習し、ユーザの嗜好をパターンとして抽出して、類似の嗜好を持つ人に興味のあると思われる情報を提示する。すなわち、個人を特定しないまま人の嗜好をパターン化している。つまり、特許文献２の技術では、大量の購買履歴を商品の共起に着目して統計的に処理することで、人の嗜好のパターンを抽出している。
【００１０】
一方、業務（例えば、サポートセンタ等）は、担当する人ではなく、受け付けた問い合わせ等の業務案件によって参照すべき情報が大きく異なることが特徴である。また、業務では同時に参照すべき関連性の高い情報が存在するが、一方で同一情報の利用頻度はＢ ｔｏ Ｃ（Business to Consumer）における同一商品の購入頻度ほど高くないと考えられる。そして、特許文献２の技術では、現在の業務に関連が強いが、他の業務とは異なる可能性のある情報を業務毎にレコメンドすることができない。また、特許文献２の技術では、統計処理に向かない程度に参照回数が少ない情報同士の関連を提示することができない。
【００１１】
そこで、本発明は、前記課題に鑑みてなされたものであり、電子データである文書の集合を用いた調査業務等において、ユーザによる文書の閲覧時に、関連する文書を適切に表示することを課題とする。
【課題を解決するための手段】
【００１２】
前記課題を解決するために、本発明の関連文書表示システムは、文書の集合における過去の文書の作成に基づく関連する文書同士を有効な関連リンクとして関連リンク記憶部に記憶する関連学習制御部と、その後、ユーザによって文書の集合におけるいずれかの文書が閲覧された場合、関連リンク記憶部を参照して、閲覧された文書と有効な関連リンクを有する文書を抽出し、当該抽出した文書を、閲覧された文書に関連する文書として表示部に表示するレコメンド制御部と、を有する。その他の手段については後記する。
【発明の効果】
【００１３】
本発明によれば、電子データである文書の集合を用いた調査業務等において、ユーザによる文書の閲覧時に、関連する文書を適切に表示することができる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施形態の関連文書表示システムのハードウェア構成の一例を示す図である。
【図２】第１の実施形態の関連文書表示システムのソフトウェアおよびハードウェアの構成の一例を示す図である。
【図３】第１の実施形態の関連文書表示システムの原理の一例を示す図である。
【図４】第１の実施形態の関連イベントテーブルの一例を示す図である。
【図５】第１の実施形態の案件セッション別有効文書一覧テーブルの一例を示す図である。
【図６】第１の実施形態の関連リンク管理情報の一例を示す図である。
【図７】第１の実施形態のキーワードテーブルの一例を示す図である。
【図８】第１の実施形態の案件セッションＩＤ用Ｃｏｏｋｉｅの一例を示す図である。
【図９】第１の実施形態の文書用Ｃｏｏｋｉｅの一例を示す図である。
【図１０】第１の実施形態の作成文書テーブルの一例を示す図である。
【図１１】第１の実施形態の有効文書巡回用スタックの一例を示す図である。
【図１２】第１の実施形態の関連文書表示システムで実行される処理の全体フローの一例を示すフローチャートである。
【図１３】第１の実施形態の各構成間の関係の一例を示す図である。
【図１４ａ】第１の実施形態のクライアントで実行される案件セッション開始処理の一例を示すフローチャートである。
【図１４ｂ】第１の実施形態のコンテンツ体系化サーバで実行される案件セッションＩＤ取得処理の一例を示すフローチャートである。
【図１５】第１の実施形態のコンテンツ体系化サーバで実行されるｐｒｏｘｙ部の処理の一例を示すフローチャートである。
【図１６ａ】第１の実施形態のクライアントで実行される文書作成処理の一例を示すフローチャートである。
【図１６ｂ】第１の実施形態のクライアントで実行されるテキスト挿入処理の一例を示すフローチャートである。
【図１６ｃ】第１の実施形態のクライアントで実行されるペースト処理の一例を示すフローチャートである。
【図１６ｄ】第１の実施形態のコンテンツ体系化サーバで実行されるコピーペースト捕捉処理の一例を示すフローチャートである。
【図１７】第１の実施形態のコンテンツ体系化サーバで実行される関連リンクの生成処理の全体フローの一例を示すフローチャートである。
【図１８】第１の実施形態の案件セッション別有効文書一覧の作成処理の一例を示すフローチャートである。
【図１９】第１の実施形態の関連リンク生成処理の一例を示すフローチャートである。
【図２０ａ】第１の実施形態のクライアントで実行される検索実行時のブラウザでの処理の一例を示すフローチャートである。
【図２０ｂ】第１の実施形態のコンテンツ体系化サーバで実行される検索キーワードのレコメンド処理の一例を示すフローチャートである。
【図２１ａ】第１の実施形態の関連リンク学習時の具体事例を示す図である。
【図２１ｂ】第１の実施形態のレコメンド実行時の具体事例を示す図である。
【図２２】第２の実施形態の関連文書表示システムのソフトウェアおよびハードウェアの構成の一例を示す図である。
【図２３】第２の実施形態の関連リンクノードの一例を示す図である。
【図２４】第２の実施形態の文書ノードの一例を示す図である。
【図２５】第２の実施形態のＵＲＩ−文書ノード対応管理テーブルの一例を示す図である。
【図２６】第２の実施形態のグラフ構造の概念図の一例を示す図である。
【図２７】第２の実施形態の案件セッション別有効文書一覧テーブルおよび探索の訪問済み文書管理テーブルの一例を示す図である。
【図２８】第２の実施形態の関連リンク生成用スタックの一例を示す図である。
【図２９】第２の実施形態の関連文書表示システムで実行される処理の全体フローの一例を示す図である。
【図３０】第２の実施形態の各構成間の関係の一例を示す図である。
【図３１ａ】第２の実施形態の関連リンクの生成の処理フローの一例を示す図である。
【図３１ｂ】第２の実施形態の第１の探索の処理の一例を示す図である。
【図３１ｃ】第２の実施形態の第２の探索の処理の一例を示す図である。
【図３１ｄ】第２の実施形態の関連度の算出の処理の一例を示す図である。
【図３２】第２の実施形態のコンテンツ体系化サーバで実行される検索キーワードのレコメンド処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態（以下、「実施形態」という。）について、図面を参照（言及図以外も適宜参照）しながら、本実施形態（第１、第２の実施形態）の概要、第１の実施形態、第２の実施形態の順で説明する。
【００１６】
＜本実施形態の概要＞
最初に、図３に示した事例を用いて本実施形態の概要を説明する。本実施形態は、（ａ）関連リンク学習時と、（ｂ）レコメンド実行時とに大別できる。なお、本実施形態では、検索キーワードも一種の文書と考える。つまり、特許請求の範囲における「文書」には「検索キーワード」も含まれ、また、特許請求の範囲における「閲覧された文書」には、「（ユーザによって）入力された検索キーワード」も含まれる。さらに、以下に説明する概要では、文書−文書、検索キーワード−文書、検索キーワード−検索キーワード等の関係のうち、特に、ユーザが検索キーワードを入力した際に関連する検索キーワードを提示する場合を具体例にして説明する。
【００１７】
≪関連リンク学習時≫
まず、（ａ）関連リンク学習時について説明する。図３（ａ）に示すように、ここでは、ユーザがさまざまな検索キーワード（k1〜k3）を用いて文書の検索を実行し、文書（p0〜p3）を参照し、得た情報をまとめて文書(c1。所定の文書)を作成する状況を想定する。また、一連の文書閲覧、検索キーワード入力を行って、少なくとも一つの文書を作成する一連の作業を案件セッションと定義する。
【００１８】
まず、最初に、ユーザが案件セッションの開始操作を行い、この操作をシステム（後記する関連文書表示システム１０００）が認識する。その際、案件セッションＩＤ（IDentification）を採番する。図３の例では、案件セッションＩＤとしてs2を採番したとする。
【００１９】
次に、ユーザは検索キーワードk1を入力して、検索結果ページを閲覧し、その中から案件に関連のありそうな文書p1を参照したとする。案件セッションＩＤ（s2）、参照した文書p1を関連元（後記する探索時の探索元）および検索キーワードk1を関連先（後記する探索時の探索先）とする関連イベントを関連イベントテーブル５１０（関連イベント記憶部）に格納する。また、前記関連イベントの種別は、関連元のp1はp、また関連先のk1はkとする。この種別とは、kは検索キーワード、pは文書を表す。また後に登場する種別のcは作成文書を表す。
【００２０】
同様に、ユーザは、検索キーワードk2にて検索して文書p2を参照し、検索キーワードk3にて検索して文書p3を参照したので、これらも関連イベントテーブル５１０に同様に格納する。
【００２１】
また、ユーザが文書p1を参照し、文書p1中のリンクにより文書p0を参照したとする。この文書間の遷移として関連イベントテーブル５１０の関連元にp0、関連先にp1を格納する。
【００２２】
また、ユーザが文書c1を作成する。ここで、ユーザは文書p0の一部のテキストをコピーして、文書c1にペーストしたとする。このコピーペースト（コピー＆ペースト）の関係として、関連元としてc1を、関連先としてp0を関連イベントテーブル５１０に格納する。また、文書p2の一部のテキストを作成文書c1にコピーペーストしたので、同様に関連イベントテーブル５１０に格納する。また、ユーザは、文書p3を参照はしたが、文書c1の作成には利用しなかったとする。
【００２３】
次に、ユーザが文書c1の作成を終えて、コンテンツ体系化サーバ２００（後記）に作成文書c1を格納したとする。コンテンツ体系化サーバ２００は、この作成文書c1の格納を受けて、当該案件セッションs2で文書の作成に関係した文書の一覧を作成し、案件セッション別有効文書一覧テーブル５２０に格納する。具体的には、関連イベントテーブル５１０を参照することで、関連イベントによる木構造を図３中の矢印の様にs2の範囲で探索し、文書作成に関連を持った文書の一覧（案件セッション別有効文書一覧テーブル５２０）を作成する。ここで、k3およびp3はc1から到達できる関連イベントによる木構造の一部になっていないので案件セッション別有効文書一覧テーブル５２０には格納されず、この時点で有用な関連リンクの生成の対象から除外される。
【００２４】
次に、案件セッション別有効文書一覧テーブル５２０の案件セッションＩＤのカラムの値が当該案件セッションＩＤ（s2）であるものから任意の２つの文書間に関連リンクを生成し、この関連リンクの情報を関連リンク管理情報５３０（関連リンク記憶部）に格納する。このとき、関連リンク管理情報５３０に格納済みの内容であれば、カウンタを１つ繰り上げる。関連リンクの情報が格納されていなければ、カウンタを１として格納する。これによって、文書作成に関連した関連性の高い文書や一種の文書である検索キーワード間の関連が学習される。
【００２５】
次に、（ｂ）レコメンド実行時について説明する。図３（ｂ）に示すように、ここでは、ユーザが検索キーワードを入力したときに、関連がある検索キーワードを提示する場合を例に説明する。ユーザが検索キーワードとしてk1を入力したとする。ユーザが検索キーワードk1を入力すると、関連リンク管理情報５３０から関連元がk1であり、関連先として種別がkであるものをサーチする。図３の例では、k2がヒットする。この検索キーワードk2を含むサーチ結果をカウンタで降順にソートして上位からユーザに提示する。これによって、k1と関連があるが異なる検索キーワードk2による新たな観点でユーザは検索を行って、関連情報を参照できる。
【００２６】
＜第１の実施形態＞
（構成）
次に、第１の実施形態の関連文書表示システムのハードウェア構成について説明する。図１に示すように、第１の実施形態の関連文書表示システム１０００は、１台以上のクライアント計算機（以下、「クライアント」という。）１００（「１００」は「１００ａ」と「１００ｂ」の総称であり、以下、他の構成についても同様である。）およびコンテンツ体系化サーバ２００を備え、それらはＬＡＮ３００によって繋がって（接続されて）いる。また、ＬＡＮ３００は、検索サーバ３０１およびＷｅｂサーバ３０２（ウェブサーバ）とＷＡＮ（Wide Area Network）３０３によって繋がっている。
【００２７】
クライアント１００は、ＣＰＵ（Central Processing Unit）１１０、メモリ１２０、記憶装置１３０、入力装置１４０、出力装置１５０およびＩＦ（ネットワークインターフェース制御部）１６０を備える計算機（コンピュータ装置）である。
【００２８】
ＣＰＵ１１０は、メモリ１２０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ１１０がオペレーティングシステムおよびアプリケーションプログラム等のソフトウェアを実行することによって、所定の機能が達成（実現）される。
【００２９】
メモリ１２０には、記憶装置１３０から読み出されたオペレーティングシステムやアプリケーションプログラム等のソフトウェアや各種データが格納される。
記憶装置１３０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、オペレーティングシステムやアプリケーションプログラム等のソフトウェアや各種データを格納する。
【００３０】
入力装置１４０は、例えば、キーボードやマウス等である。入力装置１４０は、ユーザからの入力を受け付ける。
出力装置１５０はディスプレイ等であり、ＣＰＵ１１０から指示された情報を出力する。
ＩＦ１６０は、ＬＡＮ３００と接続される。クライアント１００は、複数のＩＦ１６０を備えても良い。
【００３１】
コンテンツ体系化サーバ２００は、ＣＰＵ２１０、メモリ２２０、記憶装置２３０およびＩＦ（ネットワークインターフェース制御部）２６０を備える計算機である。
ＣＰＵ２１０は、メモリ２２０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ２１０がソフトウェア等を実行することによって、関連の生成および関連情報の提示等の所定の機能が達成（実現）される。
【００３２】
メモリ２２０には、記憶装置２３０から読み出されたソフトウェア等が格納される。
記憶装置２３０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、ソフトウェア等を格納する。
ＩＦ２６０は、ＬＡＮ３００と接続される。なお、コンテンツ体系化サーバ２００は、複数のＩＦ２６０を備えても良い。
【００３３】
次に、第１の実施形態のコンテンツ体系化サーバ２００のメモリ２２０に格納される、関連生成及び関連提示処理のためのプログラム及び関連情報の一例を示すソフトウェアおよびハードウェアの構成について説明する。
【００３４】
図２に示すように、メモリ２２０には、案件セッションＩＤ採番部２２１、文書ＵＲＩ（Uniform Resource Identifier）採番部２２２、関連学習制御部２２３、コピーペースト受付部２２６、キーワードレコメンド生成部２２７およびｐｒｏｘｙ部２２８（レコメンド制御部）が格納される。さらに、関連学習制御部２２３は、有効文書一覧生成部２２４、関連生成部２２５および有効文書巡回用スタック５８０を持つ。メモリ２２０内の各部は処理プログラムであり、図１のＣＰＵ２１０によって実行されるプログラムである。これらの処理については、後記する。
【００３５】
さらに、記憶装置２３０には、作成文書格納部２１６、関連情報格納部２１７が格納される。作成文書格納部２１６には、キーワードテーブル５４０および作成文書テーブル５７０が格納される。関連情報格納部２１７には、関連イベントテーブル５１０、案件セッション別有効文書一覧テーブル５２０および関連リンク管理情報５３０が格納される。
【００３６】
次に、クライアント１００のメモリ１２０に格納されるソフトウェア構成の一例を説明する。クライアント１００のメモリ１２０には、ブラウザ１２１が格納される。ブラウザ１２１内には、案件セッションＩＤ取得部１２２、案件セッションＩＤ格納部１２３、エディタ部１２４、ＨＴＭＬ（Hyper Text Markup Language）レンダリング部１２９およびレコメンド表示部１２９１（表示部）が格納される。エディタ部１２４内には、文書ＵＲＩ取得部１２５、文書ＵＲＩ格納部１２６、作成文書保存部１２７およびコピーペースト捕捉部１２８が格納される。これらの処理については、後で詳細に説明する。
【００３７】
なお、第１の実施形態では、クライアント１００のブラウザ１２１の拡張機能としてこれらの各部を実装することを想定しているが、クライアント１００とＷｅｂサーバ３０２との通信を中継するｐｒｏｘｙ部２２８にて、Ｗｅｂサーバ３０２から受信したＷｅｂコンテンツに例えばJava（登録商標）Scriptのようなスクリプトを追記して、ブラウザ１２１上でスクリプトを実行して機能を提供する形態であっても良い。
【００３８】
次に、各データ構造について説明する。まず、関連イベントテーブル５１０について説明する。図４に示すように、関連イベントテーブル５１０は、案件セッションＩＤ５１１、関連元のＵＲＩ５１２、関連元の種別５１３、関連先のＵＲＩ５１４および関連先の種別５１５の情報の組を保持する。
【００３９】
次に、案件セッション別有効文書一覧テーブル５２０について説明する。図５に示すように、案件セッション別有効文書一覧テーブル５２０は、案件セッションＩＤ５２１、ＵＲＩ５２２および種別５２３の情報の組を保持する。
【００４０】
次に、関連リンク管理情報５３０について説明する。図６に示すように、関連リンク管理情報５３０は、関連元のＵＲＩ５３１、関連元の種別５３２、関連先のＵＲＩ５３３、関連先の種別５３４およびカウンタ５３５の情報の組を保持する。
【００４１】
次に、キーワードテーブル５４０について説明する。図７に示すように、キーワードテーブル５４０は、ＵＲＩ５４１およびキーワード５４２の情報の組を保持する。
【００４２】
次に、案件セッションＩＤ用Ｃｏｏｋｉｅ５５０について説明する。図８に示すように、案件セッションＩＤ用Ｃｏｏｋｉｅ５５０は、案件セッションＩＤ５５１の情報を保持する。図２も参照してさらに説明すると、案件セッションＩＤ格納部１２３に格納している案件セッションＩＤをもとにブラウザ１２１が案件セッションＩＤ用Ｃｏｏｋｉｅ５５０を生成し、ブラウザ１２１がコンテンツ体系化サーバ２００と通信する際にこの案件セッションＩＤ用Ｃｏｏｋｉｅ５５０を併せて送信する。これにより、コンテンツ体系化サーバ２００は、クライアント１００からの各種操作がどの案件セッションでの操作かを捕捉して、関連イベントテーブル５１０の案件セッションＩＤ５１１にその情報を格納することができる。
【００４３】
次に、文書用Ｃｏｏｋｉｅ５６０について説明する。図９に示すように、文書用Ｃｏｏｋｉｅ５６０は、文書ＵＲＩ５６１の情報を保持する。図２も参照してさらに説明すると、文書ＵＲＩ格納部１２６に格納している文書ＵＲＩをもとにブラウザ１２１が文書用Ｃｏｏｋｉｅ５６０を生成し、作成文書保存部１２７が作成文書をコンテンツ体系化サーバ２００に送付する際にこの文書用Ｃｏｏｋｉｅ５６０を併せて送信する。これにより、コンテンツ体系化サーバ２００は、当該作成文書の文書ＵＲＩを捕捉して、作成文書テーブル５７０にその情報を格納できる。
【００４４】
次に、作成文書テーブル５７０について説明する。図１０に示すように、作成文書テーブル５７０は、ＵＲＩ５７１および文書本体５７２の情報の組を保持する。
【００４５】
次に、有効文書巡回用スタック５８０について説明する。図１１に示すように、有効文書巡回用スタック５８０は、有効文書ＵＲＩ５８１の情報を保持する。
【００４６】
（処理）
以下に、関連リンク学習の処理の詳細を説明する。まず、図１２および図１３を用いて、全体フローの動作イメージ、および、クライアント１００とコンテンツ体系化サーバ２００における各構成の関係を説明する。実際には、コンテンツ体系化サーバ２００は、一般的なサーバと同じように、クライアント１００から各種要求を受けてイベントドリブンで動作する。そのため、実際には、図１２にある一連の動作は手続きとしてはこのままでは存在せず断片的に実行されるが、クライアント１００との相互作用によって関連リンク学習の処理はこの順で実行される。
【００４７】
図１２および図１３に示すように、案件セッションＩＤ取得部１２２は、案件セッションＩＤ採番部２２１から案件セッションＩＤを取得して案件セッションＩＤ格納部１２３に格納する（ステップ１００１）。
【００４８】
その後、コンテンツ体系化サーバ２００は、クライアント１００との相互作用によってユーザの操作で作り出される関連を関連イベントとして保存する（ステップ１００２）。ステップ１００２は、実際には複数の関連イベント捕捉手段に依存する処理が互いに非同期に繰り返して実行される。具体的には、関連イベントには、検索キーワード−参照ページ、リンクの遷移（リンク参照によるページ遷移）、および、コピーペーストがある。
【００４９】
まず、検索キーワード−参照ページの関連イベントは、ブラウザ１２１からの検索要求および参照をｐｒｏｘｙ部２２８へ送信し、ｐｒｏｘｙ部２２８がキーワードテーブル５４０を参照したのち関連イベントテーブル５１０に関連イベントを格納する。リンクの遷移については、ブラウザ１２１からのリンクの遷移の要求を、ｐｒｏｘｙ部２２８が受信し、ｐｒｏｘｙ部２２８がこの関連イベントを関連イベントテーブル５１０に格納する。コピーペーストは、コピーペースト捕捉部１２８が捕捉した内容をコピーペースト受付部２２６に送信し、コピーペースト受付部２２６がその内容を関連イベントテーブル５１０に格納する。これらの関連イベントに関する処理の詳細は、図１５、図１６ｃおよび図１６ｄを用いて後記する。
【００５０】
次に、作成文書保存部１２７は、作成文書、案件セッションＩＤおよび文書ＵＲＩを関連学習制御部２２３に送信し、関連学習制御部２２３はこれを受け付ける（ステップ１００３）。このステップ１００３の処理をもって当該案件セッションが終了したとする。関連学習制御部２２３は、作成文書および文書ＵＲＩを作成文書テーブル５７０に保存する（ステップ１００４）。これによって、作成した文書は登録（保存）され、文書間の関連リンク生成の契機となる。
【００５１】
作成文書の登録（ステップ１００４）後に、有効文書一覧生成部２２４は、案件セッション別有効文書一覧の作成を行う（ステップ１００５）。つまり、関連イベントテーブル５１０から、登録された作成文書を起点として現在の案件セッションの範囲で関連イベントを順に辿って文書を抽出し、有効文書巡回用スタック５８０を用いてアクセスした文書のうち当該案件セッションにおいて有効な文書の一覧を作成して案件セッション別有効文書一覧テーブル５２０に格納する。
【００５２】
続いて、関連生成部２２５は、関連リンクの生成を行う（ステップ１００６）。つまり、案件セッション別有効文書一覧テーブル５２０を参照して案件セッション別有効文書の任意の二者間に関連リンクを生成し、関連リンク管理情報５３０に格納する。これによって案件セッション毎の有効文書として、関連リンクが学習される。
【００５３】
以下、各ステップを詳細に説明する。まず、図１２のステップ１００１の案件セッションＩＤの取得処理の詳細について、図１４ａおよび図１４ｂを用いて、それぞれクライアント１００側の動作とコンテンツ体系化サーバ２００側の動作を説明する。
【００５４】
図１４ａは、第１の実施形態のクライアント１００で実行される案件セッションＩＤ取得部１２２による処理フローの一例を示す図である。
案件セッションＩＤ取得部１２２は、図１４ａに示すように、まず、コンテンツ体系化サーバ２００の案件セッションＩＤ採番部２２１に要求し、案件セッションＩＤを取得する（ステップ１１０１）。次に、案件セッションＩＤ取得部１２２は、ステップ１１０１で取得した案件セッションＩＤを案件セッションＩＤ格納部１２３に格納する（ステップ１１０２）。
【００５５】
図１４ｂは、第１の実施形態のコンテンツ体系化サーバ２００で実行される案件セッションＩＤ採番部２２１による処理フローの一例を示す図である。
案件セッションＩＤ採番部２２１は、図１４ｂに示すように、まず、図１４ａのステップ１１０１における案件セッションＩＤ取得部１２２からの要求を受け、案件セッションＩＤを採番する（ステップ１２０１）。次に、案件セッションＩＤ採番部２２１は、ステップ１２０１で採番した案件セッションＩＤを、要求元であるクライアント１００の案件セッションＩＤ取得部１２２に送信する（ステップ１２０２）。
【００５６】
次に、図１２のステップ１００２の関連イベントを関連イベントテーブル５１０に格納する処理の詳細を説明する。前記したように、関連イベントには、検索キーワード−参照ページ、リンクの遷移およびコピーペーストがある。
【００５７】
まず、検索キーワード−参照ページの関連イベント捕捉および格納ついて、図１５および図２を用いて説明する。検索キーワード−参照ページおよびリンクの遷移の関連イベントは、ｐｒｏｘｙ部２２８の処理の一部にて取得し格納する。
【００５８】
（他Ｗｅｂページからの遷移がない場合の処理）
まず、ブラウザ１２１が、アドレスバーへの直接ＵＲＬ（Uniform Resource Locator）の入力もしくはブックマークの選択などによってＷｅｂページを参照するという、他Ｗｅｂページからの遷移がない場合の処理の流れを説明する。この処理の流れの場合、関連イベントの捕捉はないが、捕捉すべき関連イベントであるリンク遷移（リンク参照によるページ遷移）のうち初期ページ遷移の前提として最初に説明する。また、以下の説明に出てくるＧＥＴ要求とは、一般的なプロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）における一般的なリクエストの一つで、ブラウザ１２１からＷｅｂサーバ３０２に対してＷｅｂページの取得を要求するものである。
【００５９】
ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求内容がＧＥＴ要求であり、かつ、参照先が検索結果ページ以外かを判定する（ステップ１３０１）。ここでは、Ｗｅｂページ参照要求はＧＥＴ要求であり、かつ、参照先が検索結果ページ以外であるので（ステップ１３０１でＹｅｓ）、ステップ１３０２に進む。
【００６０】
ステップ１３０２で、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求にリファラ（リンク元のページ）が存在するか判定する。ここで、ブラウザ１２１からの参照は他のＷｅｂページからの遷移ではないためリファラがないので（ステップ１３０２でＮｏ）、ステップ１３１２に進む。
【００６１】
次に、ｐｒｏｘｙ部２２８は、前記ＧＥＴ要求をＷｅｂサーバ３０２に転送する（ステップ１３１２）。
【００６２】
続いて、ｐｒｏｘｙ部２２８は、Ｗｅｂサーバ３０２から前記ＧＥＴ要求のレスポンスを受け取り（ステップ１３１３）、これをブラウザ１２１に送信し（ステップ１３１４）、処理を終了する。
【００６３】
（他Ｗｅｂページからの遷移がある場合の処理）
次に、関連イベントが捕捉されるページ間の遷移がある場合の処理の流れを説明する。これは、ブラウザ１２１がページ内のリンクを辿って他のページを参照した場合である。
【００６４】
この場合は、前記他Ｗｅｂページからの遷移がない場合の処理の流れと同様にステップ１３０２まで進む。ステップ１３０２で、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求にリファラが存在すると判定し（Ｙｅｓ）、ステップ１３０３に進む。
【００６５】
ステップ１３０３で、ｐｒｏｘｙ部２２８は、ブラウザ１２１のリファラが検索結果ページを示しているか判定する。ここで、ブラウザ１２１からの参照は他のＷｅｂページからの遷移なので、ステップ１３０３の判定はＮｏとなり、ステップ１３０４に進む。
【００６６】
次に、ｐｒｏｘｙ部２２８は、リファラを関連先として取得する（ステップ１３０４）。
次に、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求がいずれの案件セッションからの要求かを捕捉するために、ブラウザ１２１からの要求に含まれる案件セッションＩＤ用Ｃｏｏｋｉｅ５５０の値を取得する（ステップ１３１０）。
【００６７】
次に、ｐｒｏｘｙ部２２８は、案件セッションＩＤ、参照先のＵＲＬを関連元、前記ステップ１３０４で取得した関連先を関連先とする関連イベントを関連イベントテーブル５１０に格納する（ステップ１３１１）。また、前記関連イベントの関連元および関連先の種別はそれぞれpとする。
【００６８】
そして、ｐｒｏｘｙ部２２８は、ステップ１３１２に進む。以下、ステップ１３１２からステップ１３１４の処理は前述の動作と同じなので、説明を省略する。
【００６９】
なお、本実施形態では、リファラを用いてコンテンツ体系化サーバ２００にてページ間の遷移を取得することを想定しているが、ユーザがＷｅｂページのハイパーリンクをクリックした情報をクライアント１００のブラウザ１２１で取得する形態であっても良い。
【００７０】
（検索結果から任意のＷｅｂページを選択してページを遷移した場合の処理）
次に、ブラウザ１２１から検索サーバ３０１にて検索を実施し、前記検索の結果から任意のＷｅｂページを選択してページを遷移した場合の検索キーワード−参照文書間の関連イベントの捕捉方法について、図１５および図２を用いて説明する。
【００７１】
まず、ｐｒｏｘｙ部２２８は、ステップ１３０１に進む。ここで、ブラウザ１２１は、ユーザによる検索キーワードの入力を受け付けて検索を実行する。ブラウザ１２１は、検索キーワードをＵＲＬのパラメータに含んでＧＥＴ要求を検索ページに対して要求しているので（つまり、参照先が検索結果ページであるので）、ｐｒｏｘｙ部２２８のステップ１３０１の判定はＮｏとなり、ステップ１３１２に進む。
【００７２】
ｐｒｏｘｙ部２２８は、検索要求を検索サーバ３０１に転送し（ステップ１３１２）、検索サーバ３０１からレスポンスを受信する（ステップ１３１３）。このとき、検索サーバ３０１のレスポンスのＵＲＬは、検索キーワードをパラメータに含んでいる。次に、ｐｒｏｘｙ部２２８は、前記レスポンスをブラウザ１２１に送信する（ステップ１３１４）。この処理フローがブラウザ１２１の検索実行時の動作である。この時点でブラウザ１２１は検索結果ページを取得し、ユーザはそれを閲覧できる。この検索結果ページとは、一般的な検索ページにて検索を実行した際に、その検索結果を一覧として表示しているＷｅｂページである（不図示）。
【００７３】
（検索結果ページから任意のＷｅｂページを選択した場合の処理）
次に、ユーザがブラウザ１２１によって検索結果ページから任意のＷｅｂページを選択し、ｐｒｏｘｙ部２２８に参照要求を出したとする。ｐｒｏｘｙ部２２８は、再び図１５に示す処理を実行し、前述のとおりステップ１３０１に進む。ここで、ブラウザ１２１は検索結果ページから任意のＷｅｂページを選択しているので、ブラウザ１２１は検索結果ページ以外のＷｅｂページのＧＥＴ要求をしており（ステップ１３０１でＹｅｓ）、ｐｒｏｘｙ部２２８はステップ１３０２に進む。
【００７４】
ここで、リファラは検索結果ページを示しているので、ステップ１３０２およびステップ１３０３の判定はＹｅｓとなり、ｐｒｏｘｙ部２２８はステップ１３０５に進む。ｐｒｏｘｙ部２２８は、前記リファラのパラメータ部から検索キーワードを取得して関連先とする（ステップ１３０５）。
【００７５】
次に、ｐｒｏｘｙ部２２８は、前記取得した検索キーワードがキーワードテーブル５４０（図７参照）のキーワード５４２のいずれかに格納済みか判定する（ステップ１３０６）。前記検索キーワードがキーワード５４２に格納済みでなかった場合には（ステップ１３０６でＮｏ）、ｐｒｏｘｙ部２２８は、ステップ１３０７に進み、前記検索キーワードに対するＵＲＩを生成する。
【００７６】
ステップ１３０７の後、ｐｒｏｘｙ部２２８は、前記検索キーワードと前記生成したＵＲＩの組をキーワードテーブル５４０に格納する（ステップ１３０８）。一方、ステップ１３０６で、ｐｒｏｘｙ部２２８が当該検索キーワードは格納済みと判定した場合には（ステップ１３０６でＹｅｓ）、キーワードテーブル５４０を参照して前記検索キーワードに対応するＵＲＩを取得する（ステップ１３０９）。
【００７７】
ステップ１３０８あるいはステップ１３０９の後、ｐｒｏｘｙ部２２８は、ブラウザ１２１からの要求がいずれの案件セッションからの要求かを捕捉するために、ブラウザ１２１からの要求に含まれる案件セッションＩＤ用Ｃｏｏｋｉｅ５５０の値を取得し（ステップ１３１０）、ステップ１３１１に進む。
【００７８】
ステップ１３１１において、ｐｒｏｘｙ部２２８は、案件セッションＩＤ、ユーザが参照要求を出している前記参照先ＵＲＬを関連元、および前記検索キーワードのＵＲＩを関連先とする関連イベントを関連イベントテーブル５１０に格納する。また、前記関連イベントの関連先の種別はk、関連元はpとする。以下、ステップ１３１２からステップ１３１４の処理は前記と同じなので説明を省略する。
【００７９】
（コピーペーストした場合の処理）
コピーペーストの関連イベントは、エディタ部１２４のコピーペースト捕捉部１２８が捕捉した当該関連イベントをコピーペースト受付部２２６で受信し、関連イベントテーブル５１０に格納する。このコピーペーストの関連イベントを捕捉し格納する処理の詳細を図１６ａ、１６ｂ、図１６ｃおよび図１６ｄを用いて説明する。
【００８０】
図１６ａは、クライアント１００のエディタ部１２４で文書を作成する処理フローの一例を示す図である。
まず、エディタにおける新規文書の作成、編集および格納について、コピーペーストの説明の前提として説明する。
【００８１】
最初に、エディタ部１２４は、エディタ（編集用ソフトウェア）を起動する（ステップ１４０１）。
次に、エディタ部１２４は、文書ＵＲＩ取得部１２５からコンテンツ体系化サーバ２００の文書ＵＲＩ採番部２２２に要求して、作成する文書のＵＲＩを新たに取得する（ステップ１４０２）。
【００８２】
続いて、エディタ部１２４は、文書を入力する（ステップ１４０３）。このステップ１４０３の文書の入力の処理内容の詳細は、図１６ｂおよび図１６ｃで説明する。このステップ１４０３の文書の入力の処理は、図１６ｂおよび図１６ｃで示す処理を１つもしくは複数実行する。そして、エディタ部１２４は、作成文書および文書ＵＲＩを作成文書保存部１２７からコンテンツ体系化サーバ２００へ送信し（ステップ１４０４）、処理を終了する。
【００８３】
次に、コピーペーストによる編集と関連イベントの捕捉や格納について説明する。
図１６ｃは、図１６ａのステップ１４０３の処理フローの一例を示す図である。エディタ部１２４は、ユーザからのペースト要求を受け付け（ステップ１４１１）、コピー元文書のＵＲＩとペーストの内容である選択済みテキストの内容を取得する（ステップ１４１２）。ここで、コピー元テキストの選択はマウスのドラッグ操作によって行われているものとするが、一般的なブラウザの機能なのでここでは詳細に説明しない。
【００８４】
次に、エディタ部１２４は、ユーザの指示により作成中文書に前記取得したテキストを挿入する（ステップ１４１３）。次に、エディタ部１２４は、コンテンツ体系化サーバ２００のコピーペースト受付部２２６へコピー元文書のＵＲＩと作成文書ＵＲＩを送信し（ステップ１４１４）、コピーペーストによる編集を終了する。
【００８５】
次に、図１６ｄを用いて、前記ステップ１４１４にてエディタ部１２４からコピー元文書のＵＲＩと作成文書ＵＲＩを受信したコピーペースト受付部２２６での動作を説明する。コピーペースト受付部２２６は、受信したコピー元文書のＵＲＩと作成文書ＵＲＩをそれぞれ関連イベントテーブル５１０に格納する。
【００８６】
まず、ステップ１４１７で、コピーペースト受付部２２６は、コピー元文書のＵＲＩと作成文書のＵＲＩを受信する（ステップ１４１７）。次に、コピーペースト受付部２２６は、コピー元文書のＵＲＩを関連先、また作成文書のＵＲＩを関連元とする関連イベントを関連イベントテーブル５１０格納する（ステップ１４１８）。また、前記関連イベントの関連先の種別はp、関連元はcとする。
【００８７】
次に、取得する関連イベントは無いが、エディタ部１２４の基本的な動作であるユーザのタイプインによる文書の編集の処理内容を以下に説明する。
【００８８】
図１６ｂは、図１６ａのステップ１４０３の処理フローの一例を示す図である。エディタ部１２４は、ユーザからのタイプインを受け付け（ステップ１４０７）、作成している文書に当該タイプインの内容のテキストを挿入する（ステップ１４０８）。
【００８９】
また、ここまでに説明した関連イベントの取得方法以外に、次のように作成文書中の記載内容から関連イベントを取得しても良い。例えば、作成文書中のＷｅｂページのＵＲＬや文書ＵＲＩ番号などの明示的なリンク情報をパターン認識により抽出し、作成文書を関連元、リンク先の文書を関連先とする関連イベントとして捕捉や格納をしても良い。
【００９０】
以下に、ステップ１４０４の処理を受けて動作する図１２のステップ１００３以降の関連リンクを生成する処理の詳細を説明する。
【００９１】
（関連リンクの生成処理）
まず、関連リンクの生成の処理の全体処理フローを、図１７を用いて説明する。
関連学習制御部２２３は、作成文書保存部１２７から作成文書、案件セッションＩＤおよび文書ＵＲＩを受け付ける（ステップ１００３）。
【００９２】
次に、関連学習制御部２２３は、作成文書および文書ＵＲＩを作成文書テーブル５７０に保存する（ステップ１００４）。これによって、作成した文書は登録され、文書間の関連リンク生成の契機となる。
【００９３】
次に、関連学習制御部２２３は有効文書一覧生成部２２４を起動し、有効文書一覧生成部２２４は、登録された作成文書を起点として現案件セッションの範囲で関連イベントを辿って文書を抽出することで、アクセスした文書のうち当該案件セッションにおいて有効な文書の一覧を作成する（ステップ１００５）。このステップ１００５の処理内容の詳細は、図１８を用いて後記する。
【００９４】
続いて、関連学習制御部２２３は関連生成部２２５を起動し、関連生成部２２５は、案件セッション別有効文書の任意の二者間に関連リンクを生成し（ステップ１００６）、処理を終了する。これによって、案件セッション毎の有効文書として、関連リンクが学習される。このステップ１００６の処理内容の詳細は、図１９を用いて後記する。
【００９５】
（ステップ１００５の処理）
有効文書一覧生成部２２４により実現される、案件セッション別の有効文書一覧を作成する処理（ステップ１００５の処理）について説明する。
【００９６】
図１８に示すように、まず、有効文書一覧生成部２２４は、受け付けた作成文書のＵＲＩを有効文書巡回用スタック５８０にＰＵＳＨする（入れる）（ステップ１５０１）。
【００９７】
次に、有効文書一覧生成部２２４は、有効文書巡回用スタック５８０からＵＲＩをＰＯＰし（出そうと試み）（ステップ１５０２）、ＰＯＰが成功したか判定する（ステップ１５０３）。ステップ１５０３でＰＯＰが成功した場合には（Ｙｅｓ）、有効文書一覧生成部２２４は、案件セッション別有効文書一覧テーブル５２０にステップ１５０２でＰＯＰしたＵＲＩが存在するか判定する（ステップ１５０４）。
【００９８】
ステップ１５０４で「存在しない」と判定した場合、有効文書一覧生成部２２４は、案件セッション別有効文書一覧テーブル５２０に前記ＵＲＩを挿入し（ステップ１５０５）、ステップ１５０６に進む。一方、ステップ１５０４で「存在する」と判定した場合には、ステップ１５０２に戻る。
【００９９】
ステップ１５０６で、有効文書一覧生成部２２４は、関連イベントテーブル５１０を前記案件セッションＩＤで絞り込み、関連イベントテーブル５１０の関連元ＵＲＩ５１２に対して前記ステップ１５０２でＰＯＰしたＵＲＩをサーチする。サーチでヒットするごとにステップ１５０７で当該ヒットした関連イベントテーブル５１０のレコードの関連先ＵＲＩ５１４の値を有効文書巡回用スタック５８０にＰＵＳＨする。前記サーチが完了したならばステップ１５０８からステップ１５０２に戻る。これらの処理を繰り返し、ステップ１５０３で有効文書巡回用スタック５８０からＵＲＩ５８１をＰＯＰができなった場合（Ｎｏ）、つまり、有効文書巡回用スタック５８０が空になれば処理を終了する。
【０１００】
（ステップ１００６の処理）
関連生成部２２５により実現される、案件セッション別有効文書の任意の二者間に関連リンクを生成する処理について説明する。図１９に示すように、関連生成部２２５は、ステップ１６０１で案件セッション別有効文書一覧テーブル５２０を案件セッションＩＤで絞り込み、関連元としてＵＲＩおよび種別を取得する。
【０１０１】
次に、ステップ１６０２で、関連生成部２２５は、ステップ１６０１で案件セッション別有効文書一覧テーブル５２０を案件セッションＩＤで絞り込み、関連先としてＵＲＩおよび種別を取得する。次に、関連生成部２２５は、ステップ１６０１とステップ１６０２で取得した関連元と関連先の内容（値）が等しいかを判定する（ステップ１６０３）。
【０１０２】
次に、関連生成部２２５は、ステップ１６０３でＮｏと判定した場合にはステップ１６０４に進み、関連リンク管理情報５３０に前記関連元および関連先の情報が格納済みであるか判定する。ステップ１６０４で格納済みでないと判定した場合には（Ｎｏ）、ステップ１６０５に進む。ステップ１６０５で関連生成部２２５は、関連リンク管理情報５３０に関連元および関連先の情報をカウンタ「１」で挿入する。一方、ステップ１６０４で格納済みと判定した場合には（Ｙｅｓ）、ステップ１６０６に進む。ステップ１６０６で関連生成部２２５は、関連リンク管理情報５３０の関連元および関連先と等しいレコードのカウンタの値に「１」加えて更新する。関連生成部２２５は、ステップ１６０１〜１６０８とステップ１６０２〜１６０７による２重ループで案件セッション別有効文書一覧テーブル５２０の全ての任意の二者間に関連リンクを生成する。以上が、関連リンク学習の処理詳細である。
【０１０３】
≪レコメンド実行時の処理≫
次に、本実施形態におけるレコメンド実行時の処理詳細を説明する。ここでは、クライアント１００のブラウザ１２１が検索するための検索キーワードの入力を受け付けた場合に、コンテンツ体系化サーバ２００から前記検索キーワードに関連する検索キーワードを提示する場面を想定する。
【０１０４】
（検索キーワードのレコメンドを受けるときの処理）
まず、検索キーワードのレコメンドを受けるときのクライアント１００のブラウザ１２１による処理フローを説明する。図２０ａに示すように、ブラウザ１２１は、検索サーバのＵＲＬを指定してＧＥＴを要求し（ステップ１７０１）、検索用のページを表示する（ステップ１７０２）。
【０１０５】
次に、ブラウザ１２１は、ユーザからの検索キーワードを受け付け（ステップ１７０３）、前記検索キーワードをＵＲＬのパラメータに含めてコンテンツ体系化サーバ２００に対してＧＥＴ要求を送信する（ステップ１７０４）。
【０１０６】
次に、ブラウザ１２１は、コンテンツ体系化サーバ２００から検索結果を受信し（ステップ１７０５）、ブラウザ１２１内のＨＴＭＬレンダリング部１２９が検索結果をレンダリング（データの可視化）する（ステップ１７０６）。
【０１０７】
次に、ブラウザ１２１は、コンテンツ体系化サーバ２００から検索キーワードのレコメンド内容を受信する（ステップ１７０７）。そして、ブラウザ１２１内のＨＴＭＬレンダリング部１２９は、ポップアップしたウインドウに検索キーワードのレコメンドを表示する（ステップ１７０８）。
【０１０８】
（レコメンドを実行する場合の処理）
次に、レコメンドを実行する場合のコンテンツ体系化サーバ２００の処理フローを説明する。概要を説明すると、コンテンツ体系化サーバ２００は、ｐｒｏｘｙ部２２８がクライアント１００から検索キーワードを受信し、当該検索キーワードに関連がある検索キーワードを関連リンク管理情報５３０から抽出してクライアント１００に送信する。
【０１０９】
具体的には、図２０ｂに示すように、まず、コンテンツ体系化サーバ２００のｐｒｏｘｙ部２２８がクライアント１００から検索キーワードを受信する（ステップ１８０１）。次に、ｐｒｏｘｙ部２２８は、キーワードレコメンド生成部２２７を起動し、キーワードレコメンド生成部２２７がキーワードテーブル５４０をサーチして前記検索キーワードのＵＲＩを取得できるか判定する（ステップ１８０２）。検索キーワードのＵＲＩを取得できると判定した場合には（ステップ１８０２でＹｅｓ）、キーワードレコメンド生成部２２７は、関連リンク管理情報５３０の関連元が検索キーワードのＵＲＩであり、関連先の種別がｋであるレコードをサーチする（ステップ１８０３）。
【０１１０】
次に、キーワードレコメンド生成部２２７は、サーチ結果を関連リンク管理情報５３０のカウンタ５３５（図６参照）の値でソートする（ステップ１８０４）。
【０１１１】
次に、キーワードレコメンド生成部２２７は前記ソートしたサーチ結果をｐｒｏｘｙ部２２８に受け渡し、ｐｒｏｘｙ部２２８はブラウザ１２１に前記ソートしたサーチ結果を送信する（ステップ１８０５）。こうすることでブラウザ１２１は、入力した検索キーワードに関連する検索キーワードのレコメンドを受けることができる。
【０１１２】
（具体事例）
以下に、図２１ａおよび図２１ｂを用いて、第１の実施形態の具体事例について説明する。この具体事例では、調査内容としてファイルシステムのバックアップを高速に取得する方法を調査し、調査の結果としてバックアップコマンドを使うのではなく、代替策としてスナップショットおよびＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成にするという方法をとることが適していると分かったとする。この調査の結果からそれぞれの文書間に関連リンクを学習する。これによって他のユーザが類似案件を調査する際に、検索キーワード「バックアップ」で検索するとそれぞれのマニュアルページに素早く到達する検索キーワード「スナップショット」「ＲＡＩＤ」がユーザに提示されることを想定する。以下にこの具体事例の詳細を説明する。
【０１１３】
まず、関連リンク学習時の具体事例について、図２１ａを用いて説明する。図２１ａは、（ａ）が検索キーワードとＷｅｂページと作成文書との関係を示す概念図であり、（ｂ）がキーワードテーブル、関連イベントテーブルおよび関連リンク管理情報の例を示す図である。
【０１１４】
ここで、クライアント１００を操作するユーザは、ファイルシステムのバックアップの高速化について調査していたとする。想定する状況としては、ファイルシステムのバックアップに時間がかかりすぎて業務に支障があり、より短時間でバックアップを完了させたいという状況であったとする。
【０１１５】
ユーザは、まず、「バックアップ（k1-a）」および「高速化（k1-b）」を検索キーワードに指定して検索したとする。そして、検索結果から、「バックアップ方法のマニュアル（p1-a）」を参照したとする。この参照から、バックアップコマンドの使用方法の工夫にて、バックアップの所要時間を短縮するのは不可能だと判明したとする。
【０１１６】
次に、「バックアップ（k1-a）」および「高速化（k1-b）」にて検索した結果の一覧から「ホットスタンバイに関する断片的な解説（p1-b）」を参照し、断片的な情報ではあるがホットスタンバイによりバックアップの高速化ができるかもしれないという情報を得たとする。ユーザは、ホットスタンバイの詳細ついて調査するために「ホットスタンバイ（k2）」を検索キーワードに検索し、「ホットスタンバイ設定のマニュアル（p2）」を参照したとする。ここで、ユーザは、ホットスタンバイは可用性を高め、またプロセスを多重化する方法であるという情報を得たとする。バックアップは、耐久性を高め、またデータを多重化する方法であるため、ホットスタンバイは、バックアップの代替案に成り得ないとユーザは判断した。
【０１１７】
さらに、先ほどの「バックアップ（k1-a）」および「高速化（k1-b）」にて検索した結果の一覧から「スナップショットに関する断片的な解説（p1-c）」を参照し、以下の情報を得たとする。スナップショットは、ある時点での仮想的なバックアップを取りその時点からの変更部分のみを記憶することで、ユーザの操作誤りに対する障害に対応する技術である。ただし、スナップショットの適用時に、メディア障害に対応するためには併せて冗長化が必要だと判明したとする。
【０１１８】
次に、前記ユーザは、スナップショットに関する詳細を調査するため「スナップショット（k3）」を検索キーワードに検索し、「スナップショット設定のマニュアル（p3）」を参照したとする。ここで、前記ユーザはスナップショットの取り方を理解したとする。また、冗長化について調査するために「冗長化（k4）」を検索キーワードに検索し、その検索結果から「冗長化の解説文書（p4）」を参照したとする。この参照により、ＲＡＩＤ構成をとることで、本調査における冗長化に対応できると判明したとする。よって、前記ユーザは次にＲＡＩＤの詳細について調査を進めることとしたとする。次に、ユーザは「ＲＡＩＤ（k5）」を検索キーワードに検索し、「ＲＡＩＤ構成のマニュアル（ｐ５）」を参照して、手順を理解したとする。
【０１１９】
ユーザは以上の調査の結果として、次のようにまとめた文書（c1）を作成したとする。つまり、「バックアップコマンドの工夫によりバックアップを高速化することはできないが（p1-aの文書を参照）、代替策として、スナップショット（p3の文書を参照）およびＲＡＩＤ（p5の文書を参照）を使うことでバックアップの高速化と同等のことができる」とまとめた文書（c1）を作成した。
【０１２０】
文書（c1）の作成には、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」を参照および引用している。また、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」を検索するにあたっては、それぞれ「バックアップ（k1-a）」および「高速化（k1-b）」、「スナップショット（k3）」、「ＲＡＩＤ（k5）」を検索キーワードとして検索した。
【０１２１】
これらの関連イベントは、関連イベントテーブル５１０ａに格納されている。そして、関連リンク管理情報５３０ａに示すように（一部図示を省略）、文書c1、「バックアップ方法のマニュアル（p1-a）」、「スナップショット設定のマニュアル（p3）」、「ＲＡＩＤ構成のマニュアル（p5）」、「バックアップ（k1-a）」、「高速化（k1-b）」、「スナップショット（k3）」、「ＲＡＩＤ（k5）」の任意の二文書間に関連リンクを生成する。
【０１２２】
次に、レコメンド実行時の動作の具体事例について、図２１ｂを用いて説明する。前記関連リンク学習時のユーザとは別のユーザが、類似案件の調査において「バックアップ」という言葉を検索キーワードとして検索を実行したとする。キーワードテーブル５４０ａに示すように、検索キーワード「バックアップ」は前記関連リンクの学習においてk1-aとしたものである。また、関連リンク管理情報５３０ａに示すように、検索キーワード「バックアップ（k1-a）」と関連リンクが存在する検索キーワードとしては、k3とした「スナップショット」、およびk5とした「ＲＡＩＤ」がある。ここでは、検索キーワードの入力時に、関連する検索キーワードを提示する状況を想定しているので、関連先の種別がkであるものを開示している。
【０１２３】
よって、関連リンク管理情報５３０ａからわかるように、「バックアップ」という検索キーワードにて検索するときには、「スナップショット」および「ＲＡＩＤ」という検索キーワードをユーザに提示することができる。このように、関連リンクが存在する検索キーワードの提示を受けることで、ユーザはより素早く有効な検索キーワードに到達することができる。そして、有効な検索キーワードに素早く到達することで、結果として有効な文書により素早く到達することができる。このように、ユーザが試行錯誤的に様々に検索キーワードを入力して、文書を閲覧する回数を減らすことができる。つまり、先人の検索履歴を有効に活用し、先人のノウハウを活用することができる。
【０１２４】
なお、この例の場合、従来のキーワードの共起に着目した統計処理（特許文献１参照）等を用いる技術では、「バックアップ」という検索キーワードに基づいて「スナップショット」や「ＲＡＩＤ」という検索キーワードをレコメンドできない可能性が少なからずあるが、本実施形態の手法によれば、そのようなレコメンドを確実に実現することができる。
【０１２５】
＜第２の実施形態＞
【０１２６】
次に、第２の実施形態について説明する。第２の実施形態は、関連リンクの生成およびその保存の方法が第１の実施形態とは異なる。第１の実施形態では、関連イベントテーブル５１０から一度、案件セッション別有効文書の一覧を求めた後に、これを利用して関連リンクを作成する。一方、第２の実施形態では、関連イベントテーブル５１０を用いて案件セッション別有効文書一覧テーブル５２０ａを作成するステップの中で関連リンクを作成する。また、関連リンクは第１の実施形態では関連イベントテーブル５１０の形式で関連リンクの情報を保持していたが、第２の実施形態ではオブジェクトのグラフ形式で生成する。
【０１２７】
まず、ソフトウェアの構成に関して、第１の実施形態と異なる箇所を説明する。第２の実施形態におけるソフトウェアおよびハードウェアの構成を図２２に示す。第１の実施形態と異なる箇所は、関連生成部２２５ａ、キーワードレコメンド生成部２２７ａ、関連リンク管理情報５３０ａ、案件セッション別有効文書一覧テーブル５２０ａ、探索の訪問済み文書管理テーブル６４０および関連リンク生成用スタック６５０であり、また、有効文書一覧生成部２２４がない。関連生成部２２５ａおよびキーワードレコメンド生成部２２７ａの処理内容は後記する。
【０１２８】
まず、関連リンク管理情報５３０ａに関して説明する。関連リンク管理情報５３０ａは、複数の関連リンクノード６１０（図２３参照）、複数の文書ノード６２０（図２４参照）およびＵＲＩ−文書ノード対応管理テーブル６３０（図２５参照）により構成し、これらにより関連リンクの情報を示す。
【０１２９】
関連リンクノード６１０の一例を図２３に示す。関連リンクノード６１０は、関連度６１１および文書ノード６２０へのポインタ６１２からなる情報の組を持つ。関連度６１１は、どの程度に当該関連リンクが関連付ける文書間の関連が強いかを示す指標値であり、第１の実施形態における関連リンク管理情報５３０のカウンタ５３５（図６参照）に相当（対応）するものである。
【０１３０】
文書ノード６２０の一例を図２４に示す。文書ノード６２０は、当該文書を表すＵＲＩ６２１、文書の種別６２２、および、１つもしくは複数の関連リンクノード６１０へのポインタを格納するポインタ６２３のリストからなる情報の組を持つ。ポインタ６２３のリストは配列、リンクトリスト等で実装されるが、プログラミング言語の実行環境における標準ライブラリが提供するものとして、本実施形態では詳細な説明を省略する。
【０１３１】
ＵＲＩ−文書ノード対応管理テーブル６３０の一例を図２５に示す。ＵＲＩ−文書ノード対応管理テーブル６３０は、文書のＵＲＩ６３１と文書ノードへのポインタ６３２の情報の組を保持する。
【０１３２】
次に、関連リンクノード６１０および文書ノード６２０で表す関連リンクのグラフ構造およびＵＲＩ−文書ノード対応管理テーブル６３０の一部の一例を図２６に示す。
図２６では、各文書ノードから関連リンクノード６１０をポイントして（指して）いる。また、各関連リンクノード６１０から、文書ノードをポイントしている。また、図２６において、関連リンクノード６１０中に示す値は関連度６１１を示している。このように、第２の実施形態ではグラフ構造で関連リンクの情報を持つ。
【０１３３】
案件セッション別有効文書一覧テーブル５２０ａおよび探索の訪問済み文書管理テーブル６４０の一例を図２７に示す。案件セッション別有効文書一覧テーブル５２０ａは、ＵＲＩ５２２ａの情報を持つ。探索の訪問済み文書管理テーブル６４０は、ＵＲＩ６４１の情報を持つ。この案件セッション別有効文書一覧テーブル５２０ａと探索の訪問済み文書管理テーブル６４０は、後記する探索において文書を訪問したか否かを管理するために用いる。
【０１３４】
第２の実施形態では、関連リンクノード６１０の関連度６１１の算出のために関連リンク生成用スタック６５０を用いる。関連リンク生成用スタック６５０の一例を図２８に示す。関連リンク生成用スタック６５０は、文書のＵＲＩ６５１をスタックしている。また、関連リンク生成用スタック６５０の要素の数を示す要素数６５２を持つ。関連リンク生成用スタックに要素をＰＵＳＨする際には要素数６５２の値を「１」加え、また、ＰＯＰする際には要素数６５２の値を「１」減らす。なお、この関連リンク生成用スタック６５０は、第１の実施形態における有効文書巡回用スタック５８０のような、関連イベントによるツリー構造を探索するためのものではない。
【０１３５】
次に、図２９および図３０を用いて、全体フローの動作イメージおよび各構成の関係を説明する。ステップ１００１〜ステップ１００４の処理内容は第１の実施形態と同じである。そして、第１の実施形態（図１２参照）では関連イベントテーブル５１０から案件セッション別有効文書一覧テーブル５２０を生成（ステップ１００５）して関連リンクの生成（ステップ１００６）をしていたが、第２の実施形態では関連イベントテーブル５１０から案件セッション別有効文書一覧テーブル５２０ａを作成するステップの中で関連リンクを生成する（ステップ１００６ａ）。その概要を説明すると、関連生成部２２５ａは、関連イベントテーブル５１０を参照し、案件セッション別有効文書一覧テーブル５２０ａ、探索の訪問済み文書管理テーブル６４０および関連リンク生成用スタック６５０を用いて関連リンクを生成する。そして、関連生成部２２５ａは、生成した関連リンクの情報を関連リンク管理情報５３０ａに格納する。
【０１３６】
関連リンクを生成するステップ１００６ａの処理の詳細を説明する。以下ではステップ１００４までの処理で、関連イベントテーブル５１０には関連イベントの各情報が第１の実施形態と同様に格納され、かつ、クライアント１００からコンテンツ体系化サーバ２００に作成文書が登録されたとして、それ以降の処理を説明する。
【０１３７】
関連イベントテーブル５１０の情報から関連リンクを生成する処理（ステップ１００６ａ）の詳細を、図３１ａ〜図３１ｄおよび図２２を用いて説明する。図３１ａ〜図３１ｄの処理では、関連イベントテーブル５１０に格納している情報に基づいて、作成文書を起点とする探索を２重にループすることにより、有効文書の任意の二文書間の関連リンクを生成する。
【０１３８】
図３１ａにおける関連リンクの生成の処理フローで、まず、関連生成部２２５ａは作成文書のＵＲＩを引数として第１の探索を行う（ステップ１９０１）。このステップ１９０１でいう作成文書とは、ステップ１００３（図２９参照）で関連学習制御部２２３がクライアント１００から受け付けた作成文書のことである。
【０１３９】
（第１の探索の処理）
次に、ステップ１９０１の第１の探索の処理内容の詳細を、図３１ｂおよび図２２を用いて説明する。
第１の探索（ステップ１９０１）は、文書のＵＲＩを引数として呼び出される。まず、関連生成部２２５ａは、引数で指定された文書のＵＲＩを第１の関連リンク生成用スタック６５０ａにＰＵＳＨする（ステップ１９０３）。なお、関連リンク生成用スタック６５０として、第１の関連リンク生成用スタック６５０ａと、第２の関連リンク生成用スタック６５０ｂとがあるものとする。
【０１４０】
次に、関連生成部２２５ａは、第１の探索の引数であるＵＲＩを案件セッション別有効文書一覧テーブル５２０ａに格納する（ステップ１９０４）。
次に、関連生成部２２５ａは、探索の訪問済み文書管理テーブル６４０の内容をクリアする（ステップ１９０５）。
【０１４１】
そして、関連生成部２２５ａは、第１の探索を呼び出したときの引数のＵＲＩを引数に第２の探索を呼び出す（ステップ１９０６）。この第２の探索の処理内容の詳細は後記する。
【０１４２】
関連生成部２２５ａは、引数である文書のＵＲＩを関連イベントテーブル５１０の関連元のＵＲＩ５１２（図４参照）に持つレコードに対してステップ１９０７〜１９１０の処理を繰り返す。ただし、この繰り返し処理は、前記作成文書と同じ案件セッションＩＤを関連イベントテーブル５１０の案件セッションＩＤ５１１に持つレコードに対して実施する。
【０１４３】
関連生成部２２５ａは、前記レコードにおける関連先のＵＲＩ５１４が案件セッション別有効文書一覧テーブル５２０ａ（図２７参照）に存在するか判定する（ステップ１９０８）。ステップ１９０８で「存在しない」と判定した場合、ステップ１９０９に進む。一方、ステップ１９０８で「存在する」と判定した場合、ステップ１９１０に進む。
ステップ１９０９で、関連生成部２２５ａは、前記関連先のＵＲＩを引数にして第１の探索を再帰的に呼び出す。
【０１４４】
ステップ１９０７〜１９１０の処理の終了後、関連生成部２２５ａは、ステップ１９１１で第１の関連リンク生成用スタック６５０ａから要素をＰＯＰし、処理を終了する（ステップ１９１２）。
【０１４５】
（第２の探索の処理）
次に、第２の探索（図３１ｂのステップ１９０６）の処理の内容を、図３１ｃを用いて説明する。
まず、関連生成部２２５ａは、第２の関連リンク生成用スタック６５０ｂに、第２の探索の呼び出し時に引数で指定された文書のＵＲＩをＰＵＳＨする（ステップ１９２１）。
【０１４６】
次に、関連生成部２２５ａは、第２の探索の引数であるＵＲＩを探索の訪問済み文書管理テーブル６４０に格納する（ステップ１９２２）。
次に、関連生成部２２５ａは、第２の探索の引数のＵＲＩと第２の探索を呼び出した第１の探索の引数のＵＲＩが等しいか判定する（ステップ１９２３）。同一文書への関連リンクを生成する必要はないため、このステップ１９２３の判定は、第１の探索および第２の探索で同一文書を見ているか否かを判定するための処理である。
【０１４７】
ステップ１９２３で関連生成部２２５ａがＮｏと判定した場合には、ステップ１９２４に進む。ステップ１９２４で、関連生成部２２５ａは文書間の関連度６１１を算出する。ステップ１９２４の処理の詳細は、後に図３１ｄを用いて説明する。
【０１４８】
次に、関連生成部２２５ａは、ＵＲＩ−文書ノード対応管理テーブル６３０をサーチして、第２の探索呼び出し時の引数のＵＲＩが示す文書ノードを取得する。（ステップ１９２５）。
【０１４９】
次に、関連生成部２２５ａは、第２の探索呼び出し時の第１の探索の引数のＵＲＩから第２の探索の引数のＵＲＩへの関連リンクノードが存在するか判定する（ステップ１９２６）。
関連リンクノード６１０は存在しないと判定した場合（ステップ１９２６でＮｏ）、関連生成部２２５ａは、ステップ１９２７に進む。
一方、関連リンクノード６１０は存在すると判定した場合（ステップ１９２６でＹｅｓ）、関連生成部２２５ａは、ステップ１９２８に進む。
【０１５０】
ステップ１９２７で、関連生成部２２５ａは、新たに関連リンクノード６１０を生成し、前記生成した関連リンクノード６１０に第２の探索の引数である文書のＵＲＩを持つ文書ノードへのポインタおよびステップ１９２４で算出した関連度６１１の値を格納する。また、併せて、第２の探索を呼び出した第１の探索の引数の文書のＵＲＩをＵＲＩ６２１に持つ文書ノード６２０における関連リンクノード６１０へのポインタに前記生成した関連リンクノード６１０へのポインタを追加する。
【０１５１】
一方、ステップ１９２８では、関連生成部２２５ａは、既存の関連リンクノード６１０に前記算出した関連度６１１の値を加えて更新する。
【０１５２】
次に、関連生成部２２５ａは、引数である文書のＵＲＩを関連イベントテーブル５１０の関連元のＵＲＩ５１２に持つレコードに対してステップ１９２９〜１９３２の処理を繰り返す。ただし、この繰り返し処理は、前記作成文書と同じ案件セッションＩＤを関連イベントテーブル５１０の案件セッションＩＤ５１１に持つレコードに対して実施する。
【０１５３】
関連生成部２２５ａは、前記レコードにおける関連先のＵＲＩ５１４が探索の訪問済み文書管理テーブル６４０に存在するか判定する（ステップ１９３０）。ステップ１９３０で「存在しない」と判定した場合、ステップ１９３１に進む。一方、ステップ１９３０で「存在する」と判定した場合、ステップ１９３２に進む。
【０１５４】
ステップ１９３１で、関連生成部２２５ａは、前記関連先のＵＲＩを引数にして第２の探索を再帰的に呼び出す。
【０１５５】
ステップ１９２９〜１９３２の処理の終了後、関連生成部２２５ａは、ステップ１９３３で第２の関連リンク生成用スタック６５０ｂから要素をＰＯＰし、処理を終了する。
【０１５６】
（関連度の算出処理）
次に、ステップ１９２４の関連度６１１の算出処理の詳細を、図３１ｄおよび図２２を用いて説明する。
【０１５７】
関連度６１１の算出には、まず文書間の距離を算出する。文書間の距離とは、２つの有効文書間がいくつの関連イベントで辿り着けるかというホップ数である。距離の算出は、第１の関連リンク生成用スタック６５０ａと第２の関連リンク生成用スタック６５０ｂとを比較して求める。
【０１５８】
まず、関連生成部２２５ａは、ステップ１９４１で第１の関連リンク生成用スタック６５０ａの要素の最大数になるまでの間、ステップ１９４２の処理を繰り返す。このステップ１９４２を繰り返し実行する回数をｉとしたとき、関連生成部２２５ａは第１および第２の関連リンク生成用スタック６５０ａ、６５０ｂのそれぞれ下からｉ番目の値が等しいか判定する。ただし、このｉの値は「０」からはじまるものとする。関連生成部２２５ａはステップ１９４２でＹｅｓと判定した場合には、ステップ１９４１〜ステップ１９４３の繰り返し処理を抜けてステップ１９４４に進む。
【０１５９】
次に、ステップ１９４４で、関連生成部２２５ａは、第１の関連リンク生成用スタック６５０ａの要素数６５２ａとiの値の差を算出する。
次にステップ１９４５で、関連生成部２２５ａは、第２の関連リンク生成用スタック６５０ｂの要素数６５２ｂとiの値の差を算出する。
【０１６０】
次にステップ１９４６で、関連生成部２２５ａは、ステップ１９４４とステップ１９４５で算出した値の和を求める。この和の値が、距離の値である。
【０１６１】
次に、ステップ１９４７で、関連生成部２２５ａは、ステップ１９４６で算出した距離の値の逆数を求め、この値を関連度６１１の値とする。ただし、関連度６１１の値はこのように逆数により算出する方法に限るわけでなく、他の方法により関連度６１１を算出し設定してもかまわない。
【０１６２】
第２の実施形態における関連リンクの生成に関する具体事例を、図２６を用いて説明する。図２６に示すように、ｋ１からｋ２に新たに関連リンクノード６１０を生成する場合、ｋ２を示す文書ノードへのポインタを持つ関連リンクノード６１０ａを生成する。そして、この生成した関連リンクノード６１０ａへのポインタを、ｋ１の文書ノードに加える。ここで、ｋ１からｋ２への距離は「５」だったすると、その逆数である「０．２」を関連度６１１として、前記生成した関連リンクノード６１０ａは持つ。
【０１６３】
一方、既存の関連リンクノード６１０に前記算出した関連度６１１の値を加えて更新する場合の具体事例も、同様に図２６を用いて説明する。ｐ１からｋ１に関連リンクノード６１０ｂは存在し、その関連度６１１はあるとき「２．０」だったとする。そして、新たに、ｐ１からｋ１への距離が「１」であり、距離の逆数である関連度６１１が「１」となる場合があったとする。このとき、ｐ１からｋ１への関連リンクを示す関連リンクノード６１０の関連度６１１は「３．０」となり、図２６に示すように、ｐ１からｋ１への関連リンクを示す関連リンクノード６１０ｂが更新される。ここまでが、関連リンク学習の処理詳細である。
【０１６４】
次に、第２の実施形態におけるレコメンド実行時の処理詳細を説明する。第１の実施形態におけるレコメンド実行時と同様に、クライアント１００のブラウザ１２１が検索するために検索キーワードの入力を受け付けた場合に、コンテンツ体系化サーバ２００から前記検索キーワードに関連する検索キーワードをユーザに提示する場面を想定する。また、クライアント１００側のブラウザ１２１の動作は第１の実施形態と同様なので、説明を省略する。ここでは、第１の実施形態と異なるキーワードレコメンド生成部２２７ａの処理内容を、図３２を用いて説明する。
【０１６５】
図３２は、第２の実施形態におけるレコメンド実行時のコンテンツ体系化サーバ２００の処理内容を示すフローの一例である。また、図３２のステップ１８０１およびステップ１８０２の処理内容は、それぞれ図２０ｂにおけるステップ１８０１およびステップ１８０２の処理内容と同様である。
【０１６６】
次に、キーワードレコメンド生成部２２７ａは、ステップ１８０２で取得した検索キーワードのＵＲＩを持つ文書ノード６２０をサーチする（ステップ２００１）。次に、キーワードレコメンド生成部２２７ａは、ステップ２００１で取得した文書ノード６２０における関連リンクノードへのポインタ６２３をサーチして、関連リンクノード６１０を取得する（ステップ２００２）。
【０１６７】
次に、キーワードレコメンド生成部２２７ａは、ここまでの処理で取得した関連リンクを、それぞれの関連リンクノード６１０の関連度６１１（図２３参照）の値でソートする（ステップ２００３）。次に、キーワードレコメンド生成部２２７ａは、前記ソートしたサーチ結果をｐｒｏｘｙ部２２８に受け渡し、ｐｒｏｘｙ部２２８はブラウザ１２１に前記ソートしたサーチ結果を送信し（ステップ１８０５）、処理を終了する。このようにして、ブラウザ１２１は、入力した検索キーワードに関連する検索キーワードのレコメンドを受けることができる。
【０１６８】
このように、本実施形態の関連文書表示システム１０００によれば、電子データである文書の集合を用いた調査業務等において、文書の検索時に、例えば、前記した例では、「バックアップ」という検索キーワードに基づいて「スナップショット」や「ＲＡＩＤ」という適切な検索キーワードを確実にレコメンドすることができる。
【０１６９】
つまり、従来技術とは異なり、結果集合が論理和(OR)となるような関連キーワードを提示することができる。この場合、現在の検索結果集合には必ずしも存在しないが、業務上関連の深い情報を効率良く提示できることが重要である。
また、過去の検索履歴データを案件セッションごとに解析して利用するので、一般的に統計処理に向かない程度に参照回数が少ない業務においても情報同士の関連を提示することができる。
【０１７０】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、本実施形態では、クライアント１００、コンテンツ体系化サーバ２００、検索サーバ３０１およびＷｅｂサーバ３０２を、それぞれ別々のハードウェア構成として説明したが、それらの任意の２つ以上がハードウェア的に１つのものとして構成されていても良い。
【０１７１】
また、案件セッションの開始は、ユーザが明示的に指示することによって認識しても、あるいは、ユーザによる検索キーワードの入力があったときに自動的に認識するようにしても、いずれでも良い。
また、案件セッションの開始を認識しなくても、ユーザによる検索の操作内容を常時記憶しておき、所定の文書（c1）が作成されたときに、その対応する案件セッションについて、常時記憶した操作内容に基づき、関連イベントがあった任意の二者を関連イベントテーブル５１０に記憶するようにしても良い。
【０１７２】
また、本実施形態では、レコメンド実行時の処理に関して、ユーザが検索キーワードを入力したときに関連する検索キーワードを提示する場合について説明したが、ユーザが文書を閲覧したときに関連する文書を提示する場合など、他の場面にも適用することができる。
【０１７３】
なお、関連文書表示システム１０００を構成する各コンピュータに実行させるためのプログラムを作成し、コンピュータにインストールすることにより、各コンピュータは、そのプログラムに基づいた各機能を実現することができる。
その他、ハードウェア、プログラム等の具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【０１７４】
１００ クライアント
１２１ ブラウザ
１２４ エディタ部
１２９ ＨＴＭＬレンダリング部
２００ コンテンツ体系化サーバ
２２３ 関連学習制御部
２２８ ｐｒｏｘｙ部（レコメンド制御部）
３００ ＬＡＮ
３０１ 検索サーバ
３０２ Ｗｅｂサーバ
５１０ 関連イベントテーブル（関連イベント記憶部）
５２０ 案件セッション別有効文書一覧テーブル
５３０ 関連リンク管理情報（関連リンク記憶部）
１０００ 関連文書表示システム
【特許請求の範囲】
【請求項１】
電子データである文書の集合の中から、ユーザによって閲覧された文書に関連する文書を前記ユーザに対して表示する関連文書表示システムであって、
前記文書の集合を使用するユーザによって新たな文書が作成されるとき、前記新たな文書の作成の開始から終了までのユーザによる一連の前記文書の集合へのアクセスをひとまとまりの案件セッションとして管理し、
前記案件セッションごとに、ユーザによる前記文書の集合へのアクセス時の操作内容を捕捉し、前記操作内容に基づいて、前記文書の集合における関連のある文書同士を、関連イベントがあったものとして、関連イベント記憶部に記憶し、
前記関連イベント記憶部を参照し、前記文書の集合において、前記作成した文書を始点として、前記関連イベントに基づいて、関連のある文書を順に辿り、辿ったうちの任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶する関連学習制御部と、
その後、ユーザによって前記文書の集合におけるいずれかの文書が閲覧された場合、
前記関連リンク記憶部を参照して、前記閲覧された文書と有効な関連リンクを有する文書を抽出し、
当該抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するレコメンド制御部と、
を有することを特徴とする関連文書表示システム。
【請求項２】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成を開始する旨の入力によって認識する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項３】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成のための操作の入力によって認識する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項４】
前記関連学習制御部は、ユーザによる前記操作内容を常時記憶しておき、前記文書の作成が行われたとき、その対応する案件セッションについて、前記常時記憶した操作内容に基づき、関連イベントがあった任意の２つの文書を前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項５】
前記関連学習制御部は、ユーザによって、文書であるウェブページのハイパーリンクが辿られ、別の文書であるウェブページに遷移したことを、関連イベントがあったものとして認識し、当該２つの文書を有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項６】
前記関連学習制御部は、文書の少なくとも一部のテキストデータがコピーされて前記作成される文書にペーストされたことを、関連イベントがあったものとして認識し、当該コピーされた文書と当該ペーストされた文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項７】
前記関連学習制御部は、検索キーワードを用いた検索により得られた文書を参照したことを、関連イベントがあったものとして認識し、当該検索キーワードと当該参照された文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項８】
前記関連学習制御部は、
前記任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶するとき、前記関連リンクごとに、当該任意の２つの文書の間に辿るべく介在する検索キーワードおよび文書の数が少ないほど大きな関連度の情報を併せて前記関連リンク記憶部に記憶し、
前記レコメンド制御部は、
前記抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するとき、前記関連度に応じてソートして表示する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項９】
電子データである文書の集合の中から、ユーザによって閲覧された文書に関連する文書を前記ユーザに対して表示する関連文書表示システムによる関連文書表示方法であって、
前記関連文書表示システムは、関連イベント記憶部と、関連リンク記憶部と、関連学習制御部と、レコメンド制御部と、を備えており、
前記関連学習制御部は、
前記文書の集合を使用するユーザによって新たな文書が作成されるとき、前記新たな文書の作成の開始から終了までのユーザによる一連の前記文書の集合へのアクセスをひとまとまりの案件セッションとして管理し、
前記案件セッションごとに、ユーザによる前記文書の集合へのアクセス時の操作内容を捕捉し、前記操作内容に基づいて、前記文書の集合における関連のある文書同士を、関連イベントがあったものとして、関連イベント記憶部に記憶し、
前記関連イベント記憶部を参照し、前記文書の集合において、前記作成した文書を始点として、前記関連イベントに基づいて、関連のある文書を順に辿り、辿ったうちの任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶し、
その後、ユーザによって前記文書の集合におけるいずれかの文書が閲覧された場合、
前記レコメンド制御部は、
前記関連リンク記憶部を参照して、前記閲覧された文書と有効な関連リンクを有する文書を抽出し、
当該抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示する
ことを特徴とする関連文書表示方法。
【請求項１０】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成を開始する旨の入力によって認識する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１１】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成のための操作の入力によって認識する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１２】
前記関連学習制御部は、ユーザによる前記操作内容を常時記憶しておき、前記文書の作成が行われたとき、その対応する案件セッションについて、前記常時記憶した操作内容に基づき、関連イベントがあった任意の２つの文書を前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１３】
前記関連学習制御部は、ユーザによって、文書であるウェブページのハイパーリンクが辿られ、別の文書であるウェブページに遷移したことを、関連イベントがあったものとして認識し、当該２つの文書を有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１４】
前記関連学習制御部は、文書の少なくとも一部のテキストデータがコピーされて前記作成される文書にペーストされたことを、関連イベントがあったものとして認識し、当該コピーされた文書と当該ペーストされた文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１５】
前記関連学習制御部は、検索キーワードを用いた検索により得られた文書を参照したことを、関連イベントがあったものとして認識し、当該検索キーワードと当該参照された文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１６】
前記関連学習制御部は、
前記任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶するとき、前記関連リンクごとに、当該任意の２つの文書の間に辿るべく介在する検索キーワードおよび文書の数が少ないほど大きな関連度の情報を併せて前記関連リンク記憶部に記憶し、
前記レコメンド制御部は、
前記抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するとき、前記関連度に応じてソートして表示する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１７】
請求項１から請求項８のいずれか１項に記載の関連文書表示システムとしてコンピュータを機能させるためのプログラム。
【請求項１】
電子データである文書の集合の中から、ユーザによって閲覧された文書に関連する文書を前記ユーザに対して表示する関連文書表示システムであって、
前記文書の集合を使用するユーザによって新たな文書が作成されるとき、前記新たな文書の作成の開始から終了までのユーザによる一連の前記文書の集合へのアクセスをひとまとまりの案件セッションとして管理し、
前記案件セッションごとに、ユーザによる前記文書の集合へのアクセス時の操作内容を捕捉し、前記操作内容に基づいて、前記文書の集合における関連のある文書同士を、関連イベントがあったものとして、関連イベント記憶部に記憶し、
前記関連イベント記憶部を参照し、前記文書の集合において、前記作成した文書を始点として、前記関連イベントに基づいて、関連のある文書を順に辿り、辿ったうちの任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶する関連学習制御部と、
その後、ユーザによって前記文書の集合におけるいずれかの文書が閲覧された場合、
前記関連リンク記憶部を参照して、前記閲覧された文書と有効な関連リンクを有する文書を抽出し、
当該抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するレコメンド制御部と、
を有することを特徴とする関連文書表示システム。
【請求項２】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成を開始する旨の入力によって認識する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項３】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成のための操作の入力によって認識する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項４】
前記関連学習制御部は、ユーザによる前記操作内容を常時記憶しておき、前記文書の作成が行われたとき、その対応する案件セッションについて、前記常時記憶した操作内容に基づき、関連イベントがあった任意の２つの文書を前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項５】
前記関連学習制御部は、ユーザによって、文書であるウェブページのハイパーリンクが辿られ、別の文書であるウェブページに遷移したことを、関連イベントがあったものとして認識し、当該２つの文書を有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項６】
前記関連学習制御部は、文書の少なくとも一部のテキストデータがコピーされて前記作成される文書にペーストされたことを、関連イベントがあったものとして認識し、当該コピーされた文書と当該ペーストされた文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項７】
前記関連学習制御部は、検索キーワードを用いた検索により得られた文書を参照したことを、関連イベントがあったものとして認識し、当該検索キーワードと当該参照された文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項８】
前記関連学習制御部は、
前記任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶するとき、前記関連リンクごとに、当該任意の２つの文書の間に辿るべく介在する検索キーワードおよび文書の数が少ないほど大きな関連度の情報を併せて前記関連リンク記憶部に記憶し、
前記レコメンド制御部は、
前記抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するとき、前記関連度に応じてソートして表示する
ことを特徴とする請求項１に記載の関連文書表示システム。
【請求項９】
電子データである文書の集合の中から、ユーザによって閲覧された文書に関連する文書を前記ユーザに対して表示する関連文書表示システムによる関連文書表示方法であって、
前記関連文書表示システムは、関連イベント記憶部と、関連リンク記憶部と、関連学習制御部と、レコメンド制御部と、を備えており、
前記関連学習制御部は、
前記文書の集合を使用するユーザによって新たな文書が作成されるとき、前記新たな文書の作成の開始から終了までのユーザによる一連の前記文書の集合へのアクセスをひとまとまりの案件セッションとして管理し、
前記案件セッションごとに、ユーザによる前記文書の集合へのアクセス時の操作内容を捕捉し、前記操作内容に基づいて、前記文書の集合における関連のある文書同士を、関連イベントがあったものとして、関連イベント記憶部に記憶し、
前記関連イベント記憶部を参照し、前記文書の集合において、前記作成した文書を始点として、前記関連イベントに基づいて、関連のある文書を順に辿り、辿ったうちの任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶し、
その後、ユーザによって前記文書の集合におけるいずれかの文書が閲覧された場合、
前記レコメンド制御部は、
前記関連リンク記憶部を参照して、前記閲覧された文書と有効な関連リンクを有する文書を抽出し、
当該抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示する
ことを特徴とする関連文書表示方法。
【請求項１０】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成を開始する旨の入力によって認識する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１１】
前記関連学習制御部は、前記案件セッションの開始を、ユーザによる文書の作成のための操作の入力によって認識する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１２】
前記関連学習制御部は、ユーザによる前記操作内容を常時記憶しておき、前記文書の作成が行われたとき、その対応する案件セッションについて、前記常時記憶した操作内容に基づき、関連イベントがあった任意の２つの文書を前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１３】
前記関連学習制御部は、ユーザによって、文書であるウェブページのハイパーリンクが辿られ、別の文書であるウェブページに遷移したことを、関連イベントがあったものとして認識し、当該２つの文書を有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１４】
前記関連学習制御部は、文書の少なくとも一部のテキストデータがコピーされて前記作成される文書にペーストされたことを、関連イベントがあったものとして認識し、当該コピーされた文書と当該ペーストされた文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１５】
前記関連学習制御部は、検索キーワードを用いた検索により得られた文書を参照したことを、関連イベントがあったものとして認識し、当該検索キーワードと当該参照された文書とを有効な関連リンクとして前記関連イベント記憶部に記憶する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１６】
前記関連学習制御部は、
前記任意の２つの文書を有効な関連リンクとして関連リンク記憶部に記憶するとき、前記関連リンクごとに、当該任意の２つの文書の間に辿るべく介在する検索キーワードおよび文書の数が少ないほど大きな関連度の情報を併せて前記関連リンク記憶部に記憶し、
前記レコメンド制御部は、
前記抽出した文書を、前記閲覧された文書に関連する文書として表示部に表示するとき、前記関連度に応じてソートして表示する
ことを特徴とする請求項９に記載の関連文書表示方法。
【請求項１７】
請求項１から請求項８のいずれか１項に記載の関連文書表示システムとしてコンピュータを機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４ａ】
【図１４ｂ】
【図１５】
【図１６ａ】
【図１６ｂ】
【図１６ｃ】
【図１６ｄ】
【図１７】
【図１８】
【図１９】
【図２０ａ】
【図２０ｂ】
【図２１ａ】
【図２１ｂ】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１ａ】
【図３１ｂ】
【図３１ｃ】
【図３１ｄ】
【図３２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４ａ】
【図１４ｂ】
【図１５】
【図１６ａ】
【図１６ｂ】
【図１６ｃ】
【図１６ｄ】
【図１７】
【図１８】
【図１９】
【図２０ａ】
【図２０ｂ】
【図２１ａ】
【図２１ｂ】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１ａ】
【図３１ｂ】
【図３１ｃ】
【図３１ｄ】
【図３２】
【公開番号】特開２０１１−２８４４７（Ｐ２０１１−２８４４７Ａ）
【公開日】平成２３年２月１０日（２０１１．２．１０）
【国際特許分類】
【出願番号】特願２００９−１７２３８７（Ｐ２００９−１７２３８７）
【出願日】平成２１年７月２３日（２００９．７．２３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年２月１０日（２０１１．２．１０）
【国際特許分類】
【出願日】平成２１年７月２３日（２００９．７．２３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]