JP2011034399A - Ｗｅｂページの関連性抽出方法、装置、及びプログラム - Google Patents

Abstract

【課題】Ｗｅｂページ参照や検索の操作が不連続、暗黙的であっても、Ｗｅｂページ間の関連性を抽出する。
【解決手段】レコメンド装置１１０の処理部でプログラムとして実行されるＷｅｂ関連性抽出部２０４は、Ｗｅｂページに関連する検索キーワードを軸にＷｅｂページ間の関連性を抽出し、更にＷｅｂページ間のアクセス過程を基に、ユーザの情報探索モデルを考慮し、関連性の強さを表す関連度を定量的に評価することで、Ｗｅｂページ間の関連性を抽出する。
【選択図】図２

Description

本発明は、ある事案に対して一つ以上のＷｅｂページを参照しながら調査を行う業務において、参照したＷｅｂページ間の暗黙的な関連性を抽出、更に抽出した関連性を基にＷｅｂページをレコメンドし、Ｗｅｂページ参照のためのナビゲーション情報を提供する技術に関する。

昨今、多様な情報がＷｅｂ（World Wide Web）を通じて簡単に入手できるようになってきている。一方でＷｅｂ上には大量の情報が公開されているため、必要な情報に効率良く辿りつく事が難しくなってきている。

企業内においても必要な情報に効率良く辿りつく事が重要である。顧客からの問合せ内容対して、複数のリファレンス情報を基に調査、回答を行うテクニカルサポートセンタやヘルプデスク業務では、問合せ内容に関係するリファレンス情報を如何に効率良く見つけられるかが重要である。このようなニーズに対して、Ｗｅｂページ参照時に、そのＷｅｂページに関連する情報をレコメンドし、必要とする情報に素早く辿り着けるよう支援するシステムが提供されてきている。

従来技術として、検索キーワードの入力とＷｅｂページの遷移を捕捉しておくことにより、同様なページ遷移を経たユーザに対して、Ｗｅｂページ間遷移情報を基に次に参照すべきＷｅｂページをレコメンドする技術（例えば特許文献１）、検索目的とレコメンドする検索キーワードの組を格納したデータベースを事前に準備し、ユーザの検索キーワードから検索目的を推定し、前記データベースからレコメンドする検索キーワードを取得し、検索キーワードをレコメンドする技術（例えば特許文献２）や、情報の整理体系化を支援する技術（例えば特許文献３）がなどある。

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

特許文献１記載の従来技術は、Ｗｅｂページの表示とＷｅｂページの検索を実行できるＵＩ（User Interface）手段によりＷｅｂページ参照やＷｅｂページ検索の履歴を記録する。本ＵＩ手段は、Ｗｅｂページ内に含まれる他のＷｅｂページへのリンクをクリックした場合にＷｅｂページの遷移を記録する。また、本ＵＩ手段は、Ｗｅｂページ内の特定のキーワードを選択し、選択したキーワードによりＷｅｂページの検索が可能である。本ＵＩ手段には、検索結果一覧が表示され、更にユーザがその一覧中からＷｅｂページを選択して表示した場合、Ｗｅｂページ間の遷移情報と共に、どんな、検索キーワードで遷移したかも合わせて捕捉することが出来る。このように、本従来技術では、Ｗｅｂページ内のリンクをクリックして別のＷｅｂページを参照する、Ｗｅｂページ内キーワードを検索して、キーワードに関連するＷｅｂページ参照するなど、Ｗｅｂページの遷移や検索が連続的、明示的に行われる場合、Ｗｅｂページ間の関連を把握することが可能である。

しかしながら、情報検索は試行錯誤の繰り返しを行うことが多い。例えば、テクニカルサポートセンタにおいて、「IME(Input Method Editor)辞書のドメイン内一括登録の方法はありますか？」など、複雑不明確な問合せの場合について考えてみる。この場合、（ステップ１）問い合わせ内容に関係するキーワードで検索を実行し、得られた検索結果から幾つかＷｅｂページを参照し、有用そうなＷｅｂページやＷｅｂページ内の情報を洗い出す。（ステップ２）洗い出したＷｅｂページやＷｅｂページ内の情報と、問い合わせ内容を比較検討し、より問い合わせ内容に関連しそうなＷｅｂページや、Ｗｅｂページ内の情報について更に深く掘り下げて調査する。このように、ステップ１として広く浅い探索、ステップ２として狭く深い探索、の２つの作業を繰り返すことが多い。ここで、ステップ１では、ステップ２での深堀調査の候補となる情報をメモ書きやユーザ自身の記憶に記録しておき、ステップ２では、前記記録した情報の内、より本命と思われる情報について、新規に検索作業を開始する。

上記のような試行錯誤による情報検索を行った場合、ステップ１とステップ２の間のＷｅｂブラウザの操作が、不連続、暗黙的となってしまい、本従来技術では、Ｗｅｂページ間の関連性を捕捉することが出来なくなるという課題があった。

一方、特許文献２記載の従来技術は、検索目的とレコメンドする検索キーワードの整備を行う必要がある。また、特許文献３記載の従来技術は、情報（知識）の整理体系化を支援する技術であるが、情報群の上下関係（抽象度など）を人手で判断する必要があり、特定の環境では有効であるが、一般的にはコストの問題が発生する。

これら従来技術のようにある程度高度なレコメンドや体系化を行う場合、捕捉する情報の管理の手間が発生する。この手間が効果より小さい業務では有効だが、大きい業務では適用が困難という課題があった。

本発明は、上述した２つの課題を考慮したものであって、情報検索による業務を行うユーザに対して、不連続、暗黙的なＷｅｂページの参照の場合においても、Ｗｅｂページ間の関連性を抽出し、抽出した関連性を基にＷｅｂページのレコメンドを行うなど、情報検索の効率化を支援するシステムを提供することを目的とする。この際、人手でのメンテナンス作業を排除することで、様々な業務に適用可能とする。

先に説明した２つの情報探索ステップは、ステップ１で下調べした情報を、ステップ２で深く調査する、という特徴がある。従って、ステップ２で参照した第１のＷｅｂページに関連する検索キーワードが、ステップ１中のある第２のＷｅｂページに含まれていた場合、第２のＷｅｂページ中の情報（検索キーワード）を、第１のＷｅｂページで詳細調査を行っている、と考えることができる。

そこで本発明は、上記の情報探索の特徴に基づき、検索キーワードを軸にＷｅｂページ間の関連性を抽出し、更にＷｅｂページ間のアクセス過程を基に、ユーザの情報探索モデルを考慮し、関連性の強さを表す関連度を定量的に評価することで、Ｗｅｂページ間の関連性を抽出する。

より具体的には、調査担当者の調査案件の開始、終了の範囲（事案の範囲）を捕捉する手段と、Ｗｅｂ検索サーバに対する検索キーワードとＷｅｂページのアクセス過程を記録する手段と、調査案件の範囲で参照した第１のＷｅｂページがＷｅｂ検索サーバの検索結果から遷移したＷｅｂページであり、その検索キーワードが、事案の範囲で参照した第２のＷｅｂページに含まれているかを検出する手段と、含まれている場合に、Ｗｅｂページ間の関連性があると仮定し、更に第１のＷｅｂページと第２のＷｅｂページ間のアクセス過程を基にＷｅｂページ間の関連性の強さを示す関連度を定量的に評価する手段により、関連性を抽出する。

すなわち、上記の目的を達成するため、本発明においては、ある事案に対して一つ以上のＷｅｂページを参照しながら調査を行う際のＷｅｂページ間の関連性を抽出する、処理部によるＷｅｂページの関連性抽出方法であって、この処理部は、調査案件の開始、終了の範囲である事案の範囲を捕捉する手順と、Ｗｅｂ検索サーバに対する検索キーワードとＷｅｂページのアクセス過程を記録する手順と、事案の範囲で参照した第１のＷｅｂページがＷｅｂ検索サーバの検索結果から遷移したものであり、その検索キーワードが、事案の範囲で参照した第２のＷｅｂページに含まれているかを検出する手順と、検索キーワードが第２のＷｅｂページに含まれている場合に、これら第１、第２のＷｅｂページ間の関連性があるとし、第１、第２のＷｅｂページ間のアクセス過程を基に、第１、第２のＷｅｂページ間の関連性の強さを示す関連度を評価する関連性抽出手順とを実行することを特徴とするＷｅｂページの関連性抽出方法、装置、及びプログラムを提供する。

本発明によれば、従来、関連性を見出すことが困難であった、Ｗｅｂページの遷移が不連続、暗黙的なケースにおいても、Ｗｅｂページ間の関連性を見出すことで、より実用的なレコメンドを提供可能とする。関連する情報を的確に提供することによって情報検索の効率を改善させることが可能となる。また、関連性を元にした情報の整理体系化により社内に存在する資産の活用、共有を実現することが可能となる。更に、ユーザの通常業務を基にＷｅｂページの関連性を抽出するので、人手によるメンテナンス作業も必要としない。

第１の実施例の計算機システムの構成の一例を示すブロック図である。 第１の実施例に係わる、レコメンド装置の機能構成の一例を示すブロック図である。 第１の実施例が想定する業務の一例の説明図である。 第１の実施例に係わる、レコメンド装置のＰｒｏｘｙ部の処理の一例を説明するフローチャートを示す図である。 第１の実施例に係わる、レコメンド装置が具備する案件セッション管理テーブルの一例を示す構成図である。 本第１の実施例に係わる、レコメンド装置の案件セッション管理部の処理の一例を説明するフローチャートを示す図である。 第１の実施例に係わる、レコメンド装置の案件管理画面の入力画面の一例を示す説明図である。 第１の実施例に係わる、Ｗｅｂページ検索時に表示される案件情報の一例を示す説明図である。 第１の実施例に係わる、Ｗｅｂページ参照時に表示されるレコメンド情報、案件情報の一例を示す説明図である。 第１の実施例に係わる、レコメンド装置のＷｅｂアクセス記録部の処理の一例を説明するフローチャートを示す図である。 第１の実施例に係わる、レコメンド装置が具備する検索エンジン定義テーブルの一例を示す構成図である。 第１の実施例に係わる、ある案件調査におけるＷｅｂ検索、Ｗｅｂページ参照の一連の過程の一例を示したシーケンス図である。 第１の実施例に係わる、レコメンド装置が具備するアクセス履歴管理テーブルの一例を示す構成図である。 第１の実施例に係わる、レコメンド装置の有用Ｗｅｂページ捕捉モジュールの処理の一例を説明するフローチャートを示す図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ有用度計算部の処理の一例を説明するフローチャートを示す図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ関連性抽出部のＷｅｂページのアクセス過程情報を生成する処理の一例を示すフローチャート図である。 第１の実施例に係わる、レコメンド装置が具備するアクセス過程管理テーブル一例を示す構成図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ関連性抽出部の関連性抽出処理の一例を示すフローチャート図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ関連性抽出部の関連性抽出処理の関連度計算の詳細処理の一例を示すフローチャート図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ関連性抽出部の関連性抽出処理の関連度計算において各評価要素と関連度の一例を示す説明図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページ関連性抽出部の関連性抽出処理の関連度計算において評価要素のバリエーション例を示す説明図である。 第１の実施例に係わる、レコメンド装置が具備するＷｅｂページ関連テーブルの一例を示す構成図である 第１の実施例に係わる、レコメンド装置の関連度調整部の入力画面の一例を示す説明図である。 第１の実施例に係わる、レコメンド装置のＷｅｂページレコメンド部の処理の一例を示すフローチャートである。 第１の実施例に係わる、レコメンド装置が生成したレコメンド情報の一例を示す説明図である。 第２の実施例に係わる、整理体系化装置の機能構成の一例を示すブロック図である 第２の実施例に係わる、Ｗｅｂページの関連性を有効グラフとして表現した場合の一例を示す説明図である。 第２の実施例に係わる、整理体系化装置のナビゲーション生成部の処理の一例を示すフローチャート図である。 第２の実施例に係わる、整理体系化装置が生成したコンテンツナビゲーション情報の一例を示す説明図である。

以下、本発明の実施の形態について図面を参照して説明する。なお、本明細書において、計算機（コンピュータ）システムの処理部で実行される各プログラムを「部」、「手段」、「手順」、あるいは「機能」等と表現する場合がある点、留意されたい。

第１の実施例は、テクニカルサポートセンタ内での情報検索業務に本レコメンドシステムを適用したものである。

初めに図３を参照して、テクニカルサポートセンタにおけるサポート業務の大まかな流れについて説明する。テクニカルサポートセンタでは、顧客から問い合わせを受け付け（問合せ受付３００）、問い合わせ内容に対する調査３０１を行いつつ、定期的に顧客に対する中間回答３０２を実施し、最終的に、最終回答３０３として問い合わせに対する回答を顧客に対して行う。この一連の流れを案件３０５と呼ぶ単位で管理し、担当者は同時に複数の案件を対応する。調査３０１の作業では、製品ベンダがＷｅｂで公開しているナレッジデータベースやテクニカルサポートセンタで蓄積した事例を検索、参照する。本発明ではこの調査３０１の調査作業の効率化を狙ったものである。

以下、図１から図２５を参照して本実施例について説明する。

≪全体構成≫
図１は、本実施例のレコメンドシステムの全体構成である。本システムは、一つ以上の業務ＰＣ（Personal Computer）１００、一つ以上のＷｅｂ検索サーバ１２０、一つ以上のＷｅｂコンテンツサーバ１３０、ＣＲＭ（Customer Relationship Management）システム１４０、レコメンド装置１１０および前記計算機システムを相互に接続するネットワーク１５０を含む。

業務ＰＣ１００は、テクニカルサポートセンタの担当者によって操作され、Ｗｅｂ検索サーバ１２０やＷｅｂコンテンツサーバ１３０を用いた情報の調査に利用される。業務ＰＣ１００は、処理部であるＣＰＵ（Central Processing Unit）１０２、記憶部であるメモリ１０１、インターフェイス（Ｉ／Ｆ）１０３、ディスプレイ１０４、入力装置１０５を備える。ＣＰＵ１０２は、内部のバス等で接続されたメモリ１０１に記憶されるプログラムを実行する。メモリ１０１は、ＣＰＵ１０２によって実行されるプログラムや必要となるデータを一時的に記憶する。プログラムは具体的には、オペレーティングシステム（ＯＳ）やＷｅｂブラウザなどである。内部のバス等でＣＰＵ１０２に接続されたインターフェイス１０３は、ディスプレイ１０４、入力装置１０５やネットワーク１５０などの外部機器とのデータ入出力を行う。ディスプレイ１０４はＣＰＵ１０２によって計算された情報を表示する。入力装置１０５はキーボードやマウスなど担当者からの入力を受け付ける。本図には記載していないが、業務用ＰＣ１００には更に外部記憶装置などを含んでも良い。

Ｗｅｂコンテンツサーバ１３０は、業務ＰＣ１００やＷｅｂ検索サーバ１２０に情報（以下Ｗｅｂページ）を公開するためのサーバである。Ｗｅｂコンテンツサーバ１３０は、業務ＰＣ１００と同様にＣＰＵ１３２、メモリ１３１、インターフェイス１３３、外部記憶装置１３４などから構成される。外部記憶装置１３４には公開するＷｅｂページが格納されている。ＷｅｂページはＨＴＭＬ（Hyper Text Markup Language）言語など、業務ＰＣ１００やＷｅｂ検索サーバ１２０上で動くＷｅｂクライアントプログラムが解釈可能な言語で記述されている。また、Ｗｅｂページを特定するための識別子としてＵＲＬ（Uniform Resource Locator）が関連付けられている。

Ｗｅｂコンテンツサーバ１３０は、ＷｅｂクライアントプログラムからＵＲＬを含むＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを受信する。Ｗｅｂコンテンツサーバ１３０は、前記ＵＲＬに関連付いているＷｅｂページを外部記憶装置１３４から取得し、ＷｅｂクライアントプルグラムにＨＴＴＰレスポンスとして送信する。Ｗｅｂページの送受信は、ＨＴＴＰなどの通信プロトコルを用いて、ネットワーク１５０を介して実行される。Ｗｅｂコンテンツサーバ１３０は、外部記憶装置１２４に格納された静的なＷｅｂページの提供以外に、Ｗｅｂアプリケーションサーバ、ＣＧＩ（Common Gateway Interface）システムやデータベースシステムなどを用いて動的にＷｅｂページを生成して提供する場合もある。

Ｗｅｂ検索サーバ１２０は、Ｗｅｂコンテンツサーバ１３０が公開するＷｅｂページに対する検索サービスを提供するサーバである。業務ＰＣ１００と同様にＣＰＵ１２２、メモリ１２１、インターフェイス１２３、外部記憶装置１２４などから構成される。Ｗｅｂ検索サーバ１２０は、クローラ（Crawler）と呼ばれるＷｅｂクライアントプログラムによりネットワーク１５０に接続されるＷｅｂコンテンツサーバ１３０が公開しているＷｅｂページを周期的に取得し、検索のためのデータベースを構築する。Ｗｅｂ検索サーバ１２０は、業務ＰＣ１００から検索要求を受け付け、検索要求に適合したＷｅｂページのＵＲＬを含むリストを応答する。

ＣＲＭシステム１４０は、顧客からの問い合わせ案件を管理するサーバである。業務ＰＣ１００と同様にＣＰＵ１４２、メモリ１４１、インターフェイス１４３、外部記憶装置１４４などから構成される。

レコメンド装置１１０は、本実施例が提供する関連性の抽出、情報のレコメンドを行う装置である。業務ＰＣ１００と同様にＣＰＵ１１２、メモリ１１１、インターフェイス１１３、外部記憶装置１１４などから構成されるコンピュータシステムである。レコメンド装置で動作するプログラムの詳細について、図２から図２５を参照して説明する。

ネットワーク１５０は、上記の計算機システムを相互に接続する。ネットワーク１５０は、企業内のＬＡＮ（Local Area Network）や、ＬＡＮ間を接続するＷＡＮ（Wide Area Network）、ＩＳＰ（Internet Service Provider）が提供するネットワークである。

≪レコメンドシステムの概要≫
図２は、図１に示したシステム全体のうち本実施例の特徴に関する業務ＰＣ１００、レコメンド装置１１０内の処理部、即ちＣＰＵで動作するプログラムの機能要素を示すブロック図である。図２を用いて本実施例の処理の概要を説明する。

業務ＰＣ１００のＣＰＵ１０２上では、ＷｅｂクライアントプログラムとしてＷｅｂブラウザ２１０が動作する。これらプログラムはメモリ１０１等の記憶部に記憶されている。担当者の情報検索はこのＷｅｂブラウザ２１０を用いて実施される。Ｗｅｂブラウザ２１０は、ユーザ操作受付部２１１、ＨＴＴＰ通信部２１２、Ｗｅｂページ表示部２１３、更には有用Ｗｅｂページ捕捉モジュールなどから構成される。操作受付部２１１は、担当者からＵＲＬの入力を受け付け、ＨＴＴＰ通信部２１２にＷｅｂページの取得を要求する。ＨＴＴＰ通信部２１２は、ＵＲＬを解析し、Ｗｅｂ検索サーバ１２０またはＷｅｂコンテンツサーバ１３０にＨＴＴＰリクエストを送信する。ＨＴＴＰ通信部２１２は、Ｗｅｂページを含むＨＴＴＰレスポンスを受信すると、Ｗｅｂページ表示部２１３にＷｅｂページの表示を要求する。Ｗｅｂページ表示部２１３は、Ｗｅｂページを解析し、Ｗｅｂブラウザの表示領域に表示する。上記ではＷｅｂブラウザ２１０のプログラム構成の一例を示したが、Ｗｅｂクライアントとして動作できれば、どのようなプログラム構成になっていても良い。

レコメンド装置１１０のＣＰＵ１１２上で実行されるプログラムは、プロキシ（Ｐｒｏｘｙ）部２００、Ｗｅｂアクセス記録部２０１、Ｗｅｂページレコメンド部２０２、案件セッション管理部２０３、Ｗｅｂページ関連性抽出部２０４、関連度調整部２１５、Ｗｅｂページ有用度計算部２１４からなる。これらは、メモリ１１１や外部記憶装置１１４などの記憶部に記憶される。メモリ１１１や外部記憶装置１１４などの記憶部には、アクセス過程管理テーブル２０５、Ｗｅｂページ関連テーブル２０６、案件セッション管理テーブル２０７、アクセス履歴管理テーブル２０８が形成される。

Ｐｒｏｘｙ部２００は、一般的なＰｒｏｘｙサーバと同様にＷｅｂブラウザ２１０と、Ｗｅｂ検索サーバ１２０やＷｅｂコンテンツサーバ１３０との間のＨＴＴＰ通信を仲介すると共に、レコメンド装置１１０内の各種機能を呼び出す。Ｗｅｂアクセス記録部２０１は、ＨＴＴＰ通信の仲介中にＰｒｏｘｙ部２００から呼び出され、Ｗｅｂブラウザ２１０のＷｅｂ検索、Ｗｅｂページ参照の履歴を記録する。案件セッション管理部２０３は、担当者によるＷｅｂ検索、Ｗｅｂページ参照が、どの問い合わせ案件に対応する調査作業なのかを把握する。有用Ｗｅｂページ捕捉モジュール２０９は、担当者の業務ＰＣ１００上のＷｅｂブラウザ２１０または図示を省略した業務ＰＣ１００のＯＳ（Operating System）上で動作し、Ｗｅｂブラウザ２１０を利用したＷｅｂページの参照状況を捕捉する。

Ｗｅｂページ有用度計算部２１４は、有用Ｗｅｂページ捕捉モジュール２０９が捕捉したＷｅｂページの参照状況を基に、該Ｗｅｂページの有用度を計算する。Ｗｅｂページ関連性抽出部２０４は、Ｗｅｂアクセス記録部２０１が記録したＷｅｂ検索、Ｗｅｂページ参照の履歴を基に、参照したＷｅｂページにヒットした検索キーワードを軸にＷｅｂページ間の関連性を抽出する。関連性の抽出にあたっては、Ｗｅｂページ間の参照過程における様々な要素を基に関連度を定量的に評価する。関連度調整部２１５は、Ｗｅｂページ関連性抽出部２０４における関連度評価で用いる各種要素の重みを調整する。重み付けは業務によって異なるため、業務に合わせたチューニングを可能とする。Ｗｅｂページレコメンド部２０２は、Ｗｅｂページ関連性抽出部２０４が抽出したＷｅｂページの関連性を基に、Ｗｅｂページのレコメンド情報を生成し、Ｗｅｂページ中にレコメンド情報を追加する。

なお、本実施例では、レコメンド装置１１０、Ｗｅｂ検索サーバ１２０、Ｗｅｂコンテンツサーバ１３０が、それぞれ別の装置として提供しているが、Ｗｅｂ検索サーバ１２０がレコメンド装置１１０を兼ねても良い。また、レコメンド装置１１０は業務ＰＣ１００にアプリケーションとしてインストールされる形態もでも良い。また、Ｗｅｂブラウザ２１０のアドオンソフトウェアとして動作しても良い。また、レコメンド装置１１０は、Ｐｒｏｘｙ動作としているが、リバースＰｒｏｘｙ型の検索ポータルサービスとして外部のＷｅｂシステムを画面ラッピングしても良い。

次にレコメンド装置１１０のプログラムである各部について詳細に説明する。

≪Ｐｒｏｘｙ部≫
Ｐｒｏｘｙ部２００は、Ｗｅｂブラウザ２１０とＷｅｂ検索サーバ１２０、Ｗｅｂコンテンツサーバ１３０の間のＨＴＴＰ通信を仲介しつつ、必要に応じてレコメンド装置内の機能を呼び出す。図４は、Ｐｒｏｘｙ部２００の処理を示すフローチャートである。

Ｐｒｏｘｙ部２００は、ＷｅｂブラウザからのＨＴＴＰリクエストを受信４００する（Ｓ４００）。次いで、案件セッション管理部２０３を呼び出す（Ｓ４０１）。次いで、受信したリクエスト中のＵＲＬを参照し、ＨＴＴＰリクエストがレコメンド装置内機能に対するリクエストか否かを判定する（Ｓ４０２）。ＨＴＴＰリクエストがレコメンド装置内機能に対する要求であった場合、ＨＴＴＰリクエスト中のＵＲＬを参照し、該当する内部機能を呼び出す（Ｓ４０８）。次いで、呼び出した内部機能の処理結果ＨＴＭＬを取得する（Ｓ４０９）。その後、ステップ４１０に遷移する。

ＨＴＴＰリクエストがＷｅｂ検索サーバまたはＷｅｂコンテンツサーバに対する要求であった場合（Ｓ４０２のＮｏ）、Ｗｅｂ検索サーバまたはＷｅｂコンテンツサーバにＨＴＴＰリクエストを代理送信する（Ｓ４０３）。次いで、前記送信したサーバからのＨＴＴＰレスポンスを受信する（Ｓ４０４）。次いで、Ｗｅｂアクセス記録部２０１を呼び出す（Ｓ４０５）。次いで、Ｗｅｂページレコメンド部２０２を呼び出す（Ｓ４０６）。次いで、ＨＴＴＰレスポンス中のＨＴＭＬにレコメンド情報などを表示するレコメンドパネル８００のＨＴＭＬ断片、有用Ｗｅｂページ捕捉モジュール２０９を追加する（Ｓ４０７）。最後にＷｅｂブラウザ２１０にＨＴＴＰレスポンスを送信する（Ｓ４１０）。

≪案件セッション管理部≫
案件セッション管理部２０３は、Ｗｅｂブラウザ２１０を用いたＷｅｂ検索、Ｗｅｂページ参照がどの問い合わせ案件に対する調査作業なのかを捕捉する。図５は、案件の管理情報を格納する案件セッション管理テーブル２０７の構成を示した図である。案件セッション管理テーブル２０７は、案件の担当者を識別する担当者ＩＤ５０２、案件を識別する案件ＩＤ５０３、および、担当者がどの案件の調査を行っているかを示す案件状態５０４から構成される。図５に示すように担当者は複数の案件を受け持つが、任意の時刻においては、任意の１件の案件を対応している。

図６は、案件セッション管理部２０３の処理を示すフローチャートである。案件セッション管理部２０３の処理は大きく分けて３つある。第１にＣＲＭシステムから案件情報を取得する処理（Ｓ６０２からＳ６０５）。第２に対応案件を明示的に受け付けるための案件管理画面７００を生成する処理（Ｓ６０７）。第３に第２の処理で生成した案件管理画面７００を用いて担当者が選択した案件を受け付ける処理（Ｓ６０９）である。以下、図６を参照して各処理を説明する。

案件セッション管理部２０３は、初めに、Ｗｅｂブラウザ２１０からのＨＴＴＰリクエスト情報を基にＷｅｂブラウザ２１０を利用して調査している担当者の担当者ＩＤを取得し、一時変数useridに代入する（Ｓ６００）。ここで、担当者ＩＤの取得は、例えば、業務ＰＣ１００のＩＰアドレスと担当者ＩＤの対応テーブルを用意することで実現することができる。また、本レコメンドシステムが、ＨＴＴＰ Ｂａｓｉｃ認証やＨＴＭＬ Ｆｒｏｍ認証など、Ｗｅｂアプリケーションで一般的に用いられるユーザ管理機能を備えていても良く、その場合、ユーザ管理機能から担当者ＩＤを取得すれば良い。

次いで、案件セッション管理テーブル２０７について、担当者ＩＤがuseridの案件ＩＤの一覧が、ＣＲＭシステム１４０の情報と比較して最新か否かを判定する（Ｓ６０１）。この判定は、ＣＲＭシステム１４０が提供する外部連携用のＡＰＩ（Application Program Interface）の利用、または、ＣＲＭシステム１４０のデータベースを直接参照することで実現すれば良い。

案件ＩＤ一覧が最新でない場合、ステップＳ６０２からステップＳ６０５の処理により案件情報を更新する。まず初めに、案件セッション管理テーブル２０７から担当者ＩＤがuseridで案件状態が"対応中"の案件ＩＤを取得し、一時変数taskidに代入する（Ｓ６０２）。次いで、ＣＲＭシステム１４０から担当者ＩＤがuseridである対応中案件の案件ＩＤ一覧を取得し、一時変数tasklistに代入する（Ｓ６０３）。案件ＩＤ一覧の取得は、前述したとおり、連携用ＡＰＩを利用、または、データベースの参照により実現すれば良い。次いで、取得した案件一覧（tasklist）を基にセッション管理テーブル２０７を更新する（Ｓ６０４）。この際、終了した案件があれば、Ｗｅｂページ関連性抽出部２０４を呼び出す。次いで、担当者ＩＤがuserid、案件ＩＤがtaskidの案件状態を"対応中"に設定し（Ｓ６０５）、ステップＳ６０６に遷移する。

前記処理ブロック終了後、ＨＴＴＰリクエストが案件管理画面７００の呼び出し要求か否か判定する（Ｓ６０６）。案件管理画面７００の呼び出し要求の場合、案件管理画面ＨＴＭＬを生成し、Ｗｅｂブラウザ２１０にＨＴＴＰレスポンスを送信し、Ｐｒｏｘｙ部２００の処理を終了する（Ｓ６０７）。

前記処理ブロック終了後、ＨＴＴＰリクエストが"対応案件選択"要求か否か判定する（Ｓ６０８）。"対応案件選択"要求の場合、案件セッション管理テーブル２０７中の担当者ＩＤがuseridの案件状態をリセットし、新たに選択された案件の案件状態を"対応中"に設定する（Ｓ６０９）。ここで、選択されている案件はＨＴＴＰリクエスト中から取得する。

図７は案件管理画面の一例である。案件管理画面７００は担当者が対応中の案件一覧（７０１）と案件選択のためのインターフェイス（７０２）を少なくとも含む。案件の一覧は、案件セッション管理テーブル２０７から担当者の情報を選択することで実現できる。担当者が別の案件の調査に入る場合、担当者は、案件管理画面７００で、案件一覧７０１から調査を行う案件を選択し、対応案件選択ボタン７０２を押下する。Ｗｅｂブラウザ２１０は、対応案件選択ボタン７０２の押下された場合、Ｐｒｏｘｙ部２００に選択された案件ＩＤを含むＨＴＴＰリクエストを送信する。案件セッション管理部２０３は、上記で説明した図４、図６のフローチャートに沿って、ステップＳ６０９に遷移し、案件変更の情報を捕捉する。

図８は、Ｗｅｂ検索画面の一例である。通常のＷｅｂ検索画面８０２に、レレコメンド情報表示エリア８００が追加される。Ｗｅｂ検索画面において、レコメンド情報表示エリア８００には、現在対応中の案件８０１、案件管理画面７００へのリンクが含まれる。図９は、Ｗｅｂページ表示画面の一例である。通常のＷｅｂページ９０１に、レコメンド情報表示エリア８００が追加される。Ｗｅｂページ表示画面において、レコメンド情報表示エリア８００には、現在対応中の案件８０１、案件冠画面へのリンク、および、各種レコメンド情報９００が含まれる。レコメンド情報表示エリア８００は図４、図６のフローチャートに沿って、ステップＳ４０７でＨＴＴＰレスポンスに挿入される。

本実施例では、レコメンド情報表示エリア８００をＷｅｂ検索画面８０２やＷｅｂページ９０１に埋め込む形で例示しているが、レコメンド情報表示エリア８００を別ウインドウとして表示したり、Ｗｅｂブラウザのアドオンプログラムを別途用意して表示したりするなど、上記表示項目が含まれて入ればどのような表示手段を用いても良い。

≪Ｗｅｂアクセス記録部≫
図１０はＷｅｂアクセス記録部２０１の処理を示すフローチャートである。Ｗｅｂアクセス記録部は、Ｐｒｏｘｙ部２００から呼び出され、Ｗｅｂページ参照、Ｗｅｂ検索の履歴を記録する。初めに、現在時刻を取得し一時変数timeに代入する（Ｓ１０００）。次いで、案件セッション管理部２０３から案件ＩＤを取得し、一時変数taskidに代入する（Ｓ１００１）。次いで、ＨＴＴＰリクエストに含まれるＵＲＬ、すなわちアクセス先がＷｅｂ検索サーバ１２０宛か否かを判定する（Ｓ１００２）。アクセス先の判定は、図１１に示す検索エンジン定義テーブル１１００を参照して行う。検索エンジン定義テーブル１１００は、Ｗｅｂ検索サーバのベースＵＲＬ１１０１、検索キーワードの変数名１１０２、検索キーワードの文字コード１１０３を定義している。ＨＴＴＰリクエスト中のＵＲＬがベースＵＲＬ１１０１に含まれる場合、Ｗｅｂ検索サーバへのアクセスと判定する。なお、検索エンジン定義テーブル１１００は、データベースやファイルなどＷｅｂアクセス記録部２０１が参照できる形式であればどのような形式でも良い。また、予め判定のためのロジックをプログラムに組み込んでおく形でも良い。

アクセス先がＷｅｂ検索サーバ１２０の場合、ＨＴＴＰリクエストからアクセス先ＵＲＬ、検索キーワードを取得し、それぞれ一時変数url、keywordに代入する（Ｓ１００３）。検索キーワードは検索エンジン定義テーブル１１００の変数名１１０２、文字コード１１０３の定義を基にリクエストパラメータまたはＰＯＳＴデータから抽出する。次いで、時刻（time）、案件ＩＤ（taskid）、アクセス先ＵＲＬ（url）、検索キーワード（keyword）をアクセス履歴管理テーブル２０８に記録する（Ｓ１００４）。

アクセス先がＷｅｂ検索サーバ１２０以外、すなわち、Ｗｅｂコンテンツサーバ１３０の場合、ＨＴＴＰリクエストからアクセス先ＵＲＬ、Ｒｅｆｅｒｅｒヘッダ値を取得し、それぞれ一時変数url、refに代入する（Ｓ１００５）。次いで、時刻（time）、案件ＩＤ（taskid）、アクセス先ＵＲＬ（url）、Ｒｅｆｅｒｅｒヘッダ値（ref）をアクセス履歴管理テーブル２０８に記録する（Ｓ１００６）。

図１２は、案件調査におけるＷｅｂ検索、Ｗｅｂページ参照の一連の過程の一例を示したシーケンス図である。

本例では、まず、担当者は、検索キーワードとして"K1 K2"の観点で調査を進めている（ステップＳ１２０１からステップＳ１２０８）。担当者は、検索結果の一覧表示から始まり、info1.htmlの表示（Ｓ１２０４）、検索結果の一覧再表示（Ｓ１２０５）、info2.htmlの表示（Ｓ１２０６）、検索結果の一覧再表示（Ｓ１２０７）、info3.htmlの表示（Ｓ１２０８）と、検索結果とＷｅｂページの参照を繰り返しつつ、３つのＷｅｂページを参照している。ここで、Ｗｅｂブラウザ２１０の戻るボタンを押して、検索結果の一覧を再表示するケースでは、Ｗｅｂブラウザ２１０のキャッシュが利用され、Ｗｅｂ検索サーバ１２０に検索要求が再度送信されないと仮定している。

次いで、Ｗｅｂページinfo1中に含まれていたキーワードK3について、詳細調査を行っている（ステップＳ１２０９からステップＳ１２１３）。担当者は、検索キーワード"K3"で検索を実施し（ステップＳ１２１０）、Ｗｅｂページinfo4.htmlを参照し（Ｓ１２１２）、次いで、info4.htmlに含まれるリンクをクリックしてＷｅｂページinfo5.htmlを参照している。

図１３は、図１２に示したＷｅｂ検索、Ｗｅｂページ参照の一連の過程を行った場合の、アクセス履歴管理テーブル２０８の結果である。アクセス履歴管理テーブル２０８は、時刻１３０１、案件ＩＤ１３０２、アクセスＵＲＬ１３０３、Ｒｅｆｅｒｅｒ１３０４、検索キーワード１３０５、Ｗｅｂページ有用度１３０５から構成される。ここで、Ｗｅｂページ有用度１３０５は、下記で説明する有用Ｗｅｂページ捕捉モジュール２０９、Ｗｅｂページ有用度計算部２１４により計算する。

≪有用Ｗｅｂページ捕捉モジュール、Ｗｅｂページ有用度計算部≫
有用Ｗｅｂページ捕捉モジュール２０９は、担当者のＷｅｂブラウザ２１０または業務ＰＣ１００のＯＳの上で動作し、Ｗｅｂブラウザ２１０を利用したＷｅｂページの参照状況を捕捉する。有用Ｗｅｂページ捕捉モジュール２０９が捕捉したＷｅｂページの参照状況を基に、レコメンド装置１１０のＣＰＵ１１２で動作するＷｅｂページ有用度計算部２１４が、該Ｗｅｂページの有用度を計算する。

図１４は、有用Ｗｅｂページ捕捉モジュール２０９の処理フローの概要を示した図である。有用Ｗｅｂページ捕捉モジュール２０９は、Ｗｅｂブラウザ２１０やＯＳ（例えばＭｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）ＯＳ）のイベントハンドラとして動作する。本イベントハンドラはイベント種別に応じて各種処理を行う（Ｓ１４００）。Ｗｅｂブラウザ２１０上に表示されているＷｅｂページ中のテキストに対するコピー操作を検出した場合、テキストコピーの回数を積算する（Ｓ１４０２）。Ｗｅｂブラウザ２１０上に表示されているＷｅｂページ中のテキストに対する選択操作を検出した場合、テキスト選択の回数を積算する（Ｓ１４０３）。Ｗｅｂページがアクティブになった場合、その回数を積算する（Ｓ１４０４）。

Ｗｅｂページのアンロードイベントを検出した場合、上記で取得したイベントログをＰｒｏｘｙ部２００に送信する（Ｓ１４０１）。上記Ｐｒｏｘｙ部２００は、ステップＳ４０２で、内部機能の呼び出しと判断し、ステップＳ４０８でＷｅｂページ有用度計算部２１４を呼び出す。

図１５はＷｅｂページ有用度計算部２１４の処理を示すフローチャートである。Ｗｅｂページの有用度は、有用Ｗｅｂページ捕捉モジュール２０９が捕捉した担当者のＷｅｂブラウザ２１０の各種操作について、テーブル１５０１に示す操作有用度係数を用いて重み付けを行い計算する（Ｓ１５００）。

本例では、担当者はinfo1.html、info3.html、info4.html、info5.htmlについて、有用な箇所を選択してコピー、メモ帳アプリケーションにペーストしたと想定する。従って、該4つのＷｅｂページは、コピー回数1回、選択回数1回、アクティブ回数1回となり、有用度は２５となる。また、info2.htmlは、アクティブ回数1回であり、有用度は５となる。

上記図１４、図１５による有用度の計算は、単純にＷｅｂページの閲覧時間や、Ｗｅｂページ上でのマウスの移動量、スクロール量、Ｗｅｂブラウザウインドウの複製操作などのＷｅｂブラウザの操作状況を反映してもよい。また、他のシステムの情報を参照してＷｅｂページの有用度を判断してもよい。例えば、Ｗｅｂページに対するＷｅｂ付箋紙（アノテーションツール）の貼り付けを検知した場合、調査過程における補足情報を入力している可能性が高いので、有用度が高いと判断しても良い。Ｗｅｂ付箋紙の貼り付けの状態は、アノテーションツールの管理インターフェイスと連携することでＷｅｂページへの貼り付け状態を取得する実現できる。同様にブックマークに当該Ｗｅｂページの追加を検知した場合、担当者が価値ある情報と判断している可能性が高いので、有用度が高いと判断しても良い。ブックマークの状態は、ブックマークツールの管理インターフェイスと連携することでＷｅｂページがブックマークされたか否かを取得することができる。

また、処理経過を記録しているＣＲＭシステム１４０に当該ＷｅｂページのＵＲＬや当該Ｗｅｂページのテキストのコピーされた場合、有用度が高いと判断しても良い。ＣＲＭシステム１４０に情報が記載されているか否かは、ＷｅｂページのＵＲＬ、テキストと、ＣＲＭシステム１４０中の当該案件の内容の文字列マッチングを取ることで実現できる。

上記他システムとの連携は、操作ログ取得ツール（株式会社日立システムアンドサービス、PC業務効率分析システム BM1（http://www.hitachi-system.co.jp/bm1/）など）と連携して実現しても良い。

≪Ｗｅｂページ関連性抽出部≫
Ｗｅｂページ関連性抽出部２０４は、前述のステップＳ６０４から問い合わせ案件の処理が終了したタイミングで呼び出される。Ｗｅｂページ関連性抽出部は、まず前処理として、アクセス履歴管理テーブル２０８に記録されている履歴情報を基に、Ｗｅｂページのアクセス過程情報を生成し、アクセス過程管理テーブル２０５に一時記録する。次いで、前記Ｗｅｂページのアクセス過程管理テーブル２０５を基に、Ｗｅｂページの関連性を抽出し、Ｗｅｂページ関連テーブル２０６に記録する。

図１６は、Ｗｅｂページのアクセス過程情報を格納するアクセス過程管理テーブル２０５を生成するためのフローチャートである。Ｗｅｂページのアクセス過程情報とは、（１）Ｗｅｂページの遷移元のＷｅｂページ、（２）遷移元Ｗｅｂページが検索結果だった場合、その検索キーワード、である。特に検索キーワードは、対応中の案件において、Ｗｅｂページの特徴を最も表しているキーワードとも言える。アクセス過程は、基本的にはＷｅｂページのＲｅｆｅｒｅｒ情報を基に生成する。以下、図１６を参照して詳細を説明する。

初めに、Ｗｅｂページ関連性抽出対象となる案件の案件ＩＤを取得し、一時変数taskidに代入する（Ｓ１６００）。次いで、アクセス履歴管理テーブル２０８から案件ＩＤがtaskidの値と一致するレコードを全て取得し、一時変数recordsに代入する（Ｓ１６０１）。前記取得したrecordsについて、以下の処理を行う（Ｓ１６０２）。その際、カレントの処理レコードは一時変数r1に代入する。

レコードr1のＵＲＬがＷｅｂ検索サーバ以外の場合、以下の処理を行う（Ｓ１６０３）。レコードr1のＲｅｆｅｒｅｒを一時変数refに代入する（Ｓ１６０４）。次いで、refの有無により処理を分岐する（Ｓ１６０５）。refが空の場合、r1より前の履歴、かつ、最もr1の時刻に近い、Ｗｅｂ検索サーバの履歴レコードを検索し、一時変数r2に代入する（Ｓ１６０６）。refが空以外の場合、r1より前の履歴、かつ、最もr1の時刻に近い、かつ、refと一致するＵＲＬを持つレコードを検索し、一時変数r2に代入する（Ｓ１６０７）。

次いで、レコードr2のＵＲＬがＷｅｂ検索サーバか否かで処理を分岐する（Ｓ１６０８）。レコードr2がＷｅｂ検索サーバの場合、アクセス過程管理テーブル２０５に、（時刻＝r1の時刻、ＵＲＬ＝r1のＵＲＬ、遷移元＝“検索結果”、検索キーワード＝r2の検索キーワード、Webページ有用度＝r1のWebページ有用度）の値からなるレコードを追加する（Ｓ１６０９）。レコードr2がＷｅｂ検索サーバ以外の場合、アクセス過程管理テーブル２０５に、（時刻＝r1の時刻、ＵＲＬ＝r1のＵＲＬ、遷移元＝ref、検索キーワード＝空文字、Webページ有用度＝r1のWebページ有用度）の値からなるレコードを追加する（Ｓ１６１０）。

図１７は、図１３で示したアクセス履歴管理テーブル２０８について、上記処理を実施した後の、アクセス過程管理テーブル２０５の内容を示した図である。アクセス過程管理テーブル２０５は、参照したＷｅｂページについて、参照時刻１７００、ＵＲＬ１７０１、遷移元１７０２、検索キーワード１７０３、Ｗｅｂページ有用度１７０４から構成される。ここで、検索キーワード１７０３は上記で説明した通り、本Ｗｅｂページに辿り着くきっかけとなったキーワードである。

図１６のフローチャートでは同一のＵＲＬに対して複数回のアクセスがあった場合に、複数個のレコードが生成されるが、単一のレコードとして集計しても良い。集計は最も古いアクセス時刻のレコードに集計しても良いし、最も新しいアクセス時刻のレコードに集計しても良い。

次いで、アクセス過程管理テーブル２０５に格納されているＷｅｂページのアクセス過程情報を基に、Ｗｅｂページの関連性を抽出する。図１８は、Ｗｅｂページ関連性抽出部２０４の処理を示したフローチャートである。関連性抽出の際には、有用度が一定値以上のＷｅｂページについて、関連性抽出の対象とする。これによりＷｅｂページレコメンドのノイズを減らすことができる。本実施例においては、この閾値をステップＳ１８００で１５に設定しているが、後述の関連度調整部により、この値は調整することが可能である。

初めに、Ｗｅｂページ有用度の閾値RMに15を代入する（Ｓ１８００）。このRMは、関連性抽出対象とするＷｅｂページの有用度の閾値を示す。次いで、アクセス過程管理テーブル２０５の全てのレコードについて順に以下の処理を行う（Ｓ１８０１）。その際、カレントの処理レコードは一時変数r1に代入する。次いで、r1の検索キーワードを一時変数kに代入する（Ｓ１８０２）。次いで、kが空以外、かつ、r1の有用度がRM以上の場合、ステップＳ１８０４からステップＳ１８０８の処理を行い、それ以外の場合は次のレコードの処理に移る（Ｓ１８０３）。

kが空以外、かつ、r1の有用度がRM以上の場合、r1以外の全てのレコードについて順に処理を実施する（Ｓ１８０４）。ここで、カレントの処理レコードを一時変数r2に代入する。次いで、r2の有用度がRM以上、かつ、r2のＵＲＬに対応するＷｅｂページ中にキーワードkが含まれる場合、r1とr2のＷｅｂページ同士に関連があると仮定して、ステップＳ１８０６に遷移、本条件を満たしていない場合は、次のレコードの処理に移る（Ｓ１８０５）。

ここで、Ｗｅｂページ中にキーワードが含まれるかの処理は、該ＷｅｂページをＨＴＴＰ通信により取得し、Ｗｅｂページに全文検索を実施することで実現できる。あるいはＷｅｂページのアクセス過程を記録するタイミングで、キーワードのインデックスを作成しておき、このインデックスに検索を行うことで、実施することも可能である。検索キーワードが複数のキーワードからなる場合、それぞれのキーワードについて検索処理を行って、ひとつでもキーワードが見つかれば含まれるとして判断しても良い。あるいは、複数キーワードをまとめた検索式として検索処理を行って、検索式に一致した場合、すなわち全てのキーワードが見つかれば含まれると判断しても良い。また、上記の検索処理は、キーワードの一致によらず、類似なキーワードを検索しても良い。類似なキーワードの検索は類義語辞書などを組み合わせることで実現できる。

r2の有用度がRM以上、かつ、r2のＵＲＬに対応するＷｅｂページ中にキーワードkが含まれる場合、アクセス過程情報を基に関連度を計算し、一時変数rankに代入する（Ｓ１８０６）。関連度計算の詳細については、本フローチャートの説明の後に説明する。次いで、Ｗｅｂページ関連テーブル２０６に（関連元＝r1のＵＲＬ、関連先＝r2のＵＲＬ、検索キーワード＝k、関連度＝rank）の値からなるレコードを追加する（Ｓ１８０７）。以上によりＷｅｂページの関連性を抽出できる。

図１９は上記ステップ１８０６で示した関連度計算の詳細を示したフローチャートである。関連度はr1とr2の参照過程を基に計算する。r1の検索キーワードがr2のページ内の情報についての詳細調査と想定できる場合、関連度をより高く設定する。

図２０に評価要素と関連度の一例を示す。#1は、Ｗｅｂページに辿り着いた際の検索キーワードが完全一致の場合、Ｗｅｂページ間の関連性が高いと想定できる。#1のバリエーションとして、キーワードの完全一致ではなく、キーワードの類似性に基づいて関連度を算出する方法でも良い。類似なキーワードの検索は類義語辞書などを組み合わせることで実現できる。#2は、r2がr1以前に参照している、すなわち、r2内に含まれる内容（r1の検索キーワード）をr1で詳細調査していると考えられ、r1とr2の関連度が高いと想定できる。#3は、末端Ｗｅｂページは、別途r1の検索キーワードの詳細を行うために一端調査を打ち切ったページと考えられ、r1とr2の関連度が高いと想定できる。#は、Ｗｅｂページのアクセス過程中の位置関係を基に関連度を算出している。末端の関連度を高くするだけでなく、末端に近いほど高くするなど、末端からの位置関係で関連度を高くしてもよい。

上記以外に、図２１に示すような観点も考えられる。例えば、操作履歴に着目して、（１）有用Ｗｅｂページ捕捉モジュール２０９により、Ｗｅｂページ（r2）のテキストコピーイベントを検出した際に、コピーしたテキスト内容を保存しておき、r1の検索キーワードが含まれる場合、関連度を加算、（２）r1とr2を同時に開いている場合、関連度を加算、といった関連度を加算しても良い。（１）（２）はＷｅｂページ参照時のユーザのＷｅｂブラウザの捜査状況を基に関連度の評価を行っている。また、担当者の属性に着目して、（３）担当者の属性により関連度の寄与率を修正（ベテランほど重みを高くするなど）、といった関連度を加算しても良い。また、それ以外に、（４）r1→r2の関係があった場合に、r2→r1に逆の関係があると仮定して、この逆の関係をＷｅｂページ関連テーブル２０６にレコードとして追加しても良い。関連度はr1→r2の関連度を基に計算することができる（例えば半分を設定するなど）。（５）リンクをクリックして辿り着いたＷｅｂページについては、遷移元のＷｅｂページの何れかに関連性があった場合、同様な関連があると仮定して、Ｗｅｂページ関連テーブル２０６にレコードを追加しても良い。関連度は、ホップ数に応じて減算するなどして計算することができる（例えば0.7倍/ホップ）。

図２２は、上記処理の結果、生成したＷｅｂページ関連テーブル２０６を示すテーブルである。本例では、図２０に示す関連度計算のみ反映したものである。

≪関連度調整部≫
図２３は関連度調整部のインターフェイスの一例を示した図である。図２０や図２１で示した関連度計算のための評価要素と関連度は、対象業務や対象とするＷｅｂページのセットによって、評価要素の重点の置き方が異なる。評価要素の関連度を、本インターフェイスを用いて変更可能とすることで、多様な環境への対応が可能となる。関連度調整部２１５は、Ｐｒｏｘｙ部２００経由でＷｅｂブラウザ２１０から呼び出されると、図２３に示す調整インターフェイスを生成する。本画面は、評価要素２３００と関連度２３０１のリストからなる。関連度の値を修正して、完了ボタンを押した場合、Ｐｒｏｘｙ部２００経由で関連度調整部２１５が呼び出される。関連度調整部２１５では、関連度の変更分を取得し、Ｗｅｂページ関連性抽出部２０４の関連度計算部分（図１８）に反映する。

上記では、Ｗｅｂインターフェイスによる関連度調整のインターフェイスの一例を示したが、評価要素２３００の関連度２３０１の設定が変更できれば、設定ファイルの修正や、ＲＤＢ更新など、どのようなインターフェイスを用いても良い。

関連度調整は、システムで単一の値を設定したり、ユーザごとに設定したりしても良い。また、複数ユーザをグループとして管理し、グループ単位で設定しても良い。

≪Ｗｅｂページレコメンド部≫
図２４は、Ｗｅｂページレコメンド部２０２の処理を示すフローチャートである。Ｗｅｂページレコメンド部２０２は、Ｗｅｂページ関連性抽出部２０４により抽出したＷｅｂページ関連テーブル２０６を参照して、Ｗｅｂページ参照時に関連するＷｅｂページをレコメンドする。Ｗｅｂページレコメンド部２０２は、図４を参照して説明したとおり、Ｐｒｏｘｙ部２００の処理の延長（Ｓ４０６）で呼び出される。

初めに、ＨＴＴＰリクエストからＵＲＬを取得し、一時変数urlに代入する（Ｓ２４００）。次いで、ＨＴＴＰリクエストからＲｅｆｅｒｅｒヘッダ値を取得し、一時変数refに代入する（Ｓ２４０１）。次いで、refがＷｅｂ検索サーバ１２０に対するリクエストか判断する（Ｓ２４０２）。refがＷｅｂ検索サーバの場合、ステップＳ２４０３からステップＳ２４０５の処理を行う。まず、refから検索キーワードを取得し、一時変数kに代入する（Ｓ２４０３）。次いで、Ｗｅｂページ関連テーブル２０６から、対象Ｗｅｂページ２２００がurl、関連キーワード２２０２がkと一致するレコードを全て取得し、一時変数recordsに代入する（Ｓ２４０４）。次いで、全recordsについて、関連度２２０３の降順で、（関連Ｗｅｂページ２２０１、関連キーワード２２０２）の組をレコメンド情報として持つレコメンドパネル９００用ＨＴＭＬを生成する（Ｓ２４０５）。

上記で生成したレコメンドパネル９００用ＨＴＭＬは、図４のステップＳ４０７でＨＴＴＰレスポンスに埋め込まれ、Ｐｒｏｘｙ部２００によりＷｅｂブラウザ２１０に送信される。

図２５は、Ｗｅｂページレコメンド部２０２により生成されたレコメンド情報の一例を示す図である。本例では、Ｗｅｂ検索サーバで、キーワード"K1 K2"で検索し、その検索結果一覧からhttp://content/info1.htmlをクリックし、info1.htmlを参照した場合のレコメンドの結果を示している。本例で示すように、info1.htmlに関連するＷｅｂページとして、info3.html、info4.htmlをレコメンドしている。レコメンドの際には、単に関連のあるＷｅｂページをレコメンドするのではなく、関連の基情報となった検索キーワードを、レコメンドの観点として同時に表示することで、レコメンドの情報の有用性を高めている。担当者は、観点情報（検索キーワード）を参照することで、現在の対応案件に関連性の高いレコメンド情報か事前にある程度予測することが可能となる。

なお、上記処理においては、キーワードの完全一致を前提して説明していたが、辞書などを用いてキーワードの類似度を判定し、類似なキーワードについても同様な処理を行っても良い。

上記実施例では、案件の範囲捕捉のために、Ｗｅｂインターフェイスを用いて案件の開始、終了の情報を担当者から取得しているが、Ｗｅｂブラウザのアドオンソフトウェアや専用のクライアントアプリケーションなど、Ｗｅｂ以外のインターフェイスにより開始、終了を捕捉しても良い。また、ＣＲＭなど他のシステムの情報を利用して案件の範囲を捕捉しても良い。また、厳密に案件を管理するのではなく、単位時間内（例えば1日単位など）の調査を一つの案件に対する調査と見なしてもよい。また、ブラウザの起動、終了と連動して案件の調査と判断しても良い。ここで、ブラウザの起動、終了の捕捉は業務ＰＣにＰＣの稼動をモニタリングするソフトウェアを別途導入することで実現できる。

以上が第一の実施例の処理の一例である。

第２の実施例は、社内外に存在する情報の整理体系化に適用したものである。図２６は整理体系化装置２６００で動作するプログラムの機能要素を示すブロック図である。整理体系化装置２６００は、上記第１の実施例のレコメンド装置１１０と同様にＷｅｂページの関連性を抽出する。よって、この整理体系化装置２６００は、図１に示したレコメンド装置１１０と同様のコンピュータシステムで構成され、図示を省略したＣＰＵ、メモリ、Ｉ／Ｆ、外部記憶装置からなる。ここで、ＣＰＵで実行されるプログラムの内、Ｗｅｂページレコメンド部２０２に変え、ナビゲーション生成部２６０１が用いられる。

本実施例においては、抽出したＷｅｂページの関連性は、有効グラフの構造をしている。例えば、図２２で示したＷｅｂページ関連テーブル２０６は、図２７で示した有効グラフと考えることが出来る。この有効グラフの形を利用し、社内外に存在する情報を仮想的に整理体系化し、情報のナビゲーション用の機能を提供する。情報ナビゲーション用の有効グラフは、ナビゲーション生成部２６０１が生成する。

図２８は、ナビゲーション生成部２６０１によるコンテンツナビゲーション用のビューを生成するためのフローチャートである。本処理は、図２４で示したＷｅｂページレコメンド部２０２の処理フローを拡張したものである。

ナビゲーション生成部２６０１は、Ｗｅｂページ関連性抽出部２０４により抽出したＷｅｂページ関連テーブル２０６を参照して、Ｗｅｂページ参照時に関連する参照したＷｅｂページを基点とするＷｅｂページのナビゲーション情報を表示する。ナビゲーション生成部２６０１は、第１の実施例と同様に、Ｐｒｏｘｙ部２００の処理の延長（Ｓ４０６）で呼び出される。

初めに、ＨＴＴＰリクエストからＵＲＬを取得し、一時変数urlに代入する（Ｓ２８００）。次いで、ＨＴＴＰリクエストからＲｅｆｅｒｅｒヘッダ値を取得し、一時変数refに代入する（Ｓ２８０１）。次いで、refがＷｅｂ検索サーバ１２０に対するリクエストか判断する（Ｓ２８０２）。refがＷｅｂ検索サーバの場合、ステップＳ２８０３からステップＳ２８０６の処理を行う。まず、refから検索キーワードを取得し、一時変数kに代入する（Ｓ２８０３）。次いで、Ｗｅｂページ関連テーブル２０６から、対象Ｗｅｂページ２２００がurl、関連キーワード２２０２がkと一致するレコードを全て取得し、一時変数recordsに代入する（Ｓ２８０４）。次いで、全recordsについて、再帰的に、関連Ｗｅｂページ２２０１が、対象Ｗｅｂページ２０００となっているレコードをＷｅｂページ関連テーブル２０６から取得する（Ｓ２８０５）。次いで、ステップＳ２８０５で取得した全てのレコードから、ノードがＷｅｂページ、アークに検索キーワードを関連付けた有効グラフ図を生成する（Ｓ２８０６）。

上記で生成した有効グラフ図は、第１の実施例と同様に、Ｐｒｏｘｙ部により、ＨＴＴＰレスポンスに埋め込まれ、Ｗｅｂブラウザ２１０に送信される。
図２９は、ナビゲーション生成部２６０１により生成されたコンテンツナビゲーション情報の一例を示す図である。本例では、Ｗｅｂ検索サーバで、キーワード"K1 K2"で検索し、その検索結果一覧からhttp://content/info1.htmlをクリックし、info1.htmlを参照した場合のコンテンツナビゲーション情報の結果を示している。本例で示すように、info1.htmlを基点としがＷｅｂページの有効グラフによるコンテンツナビゲーション情報を提示可能となる。本ナビゲーション情報により、コンテンツ全体を体系的に見渡すことが可能となり、無駄な情報の探索が削減でき、また、有効な情報への探索をより効率良く行うことが可能になる。

以上詳述した本発明は、Ｗｅｂページを参照しながら調査を行う業務において、参照したＷｅｂページ間の暗黙的な関連性を抽出し、抽出した関連性を基にＷｅｂページをレコメンド、或いはＷｅｂページ参照のためのナビゲーション情報を提供する際に有用である。

１００…業務ＰＣ
１１０…レコメンド装置
１２０…Ｗｅｂ検索サーバ
１３０…Ｗｅｂコンテンツサーバ
１４０…ＣＲＭシステム
２００…Ｐｒｏｘｙ部
２０１…Ｗｅｂアクセス記録部
２０２…Ｗｅｂページレコメンド部
２０３…案件セッション管理部
２０４…Ｗｅｂページ有用度計算部
２０５…アクセス過程管理テーブル
２０６…Ｗｅｂページ関連テーブル
２０７…案件セッション管理テーブル
２０８…アクセス履歴管理テーブル
２０９…有用Ｗｅｂページ捕捉モジュール
２１０…Ｗｅｂブラウザ
２１１…ユーザ操作受付部
２１２…ＨＴＴＰ通信部
２１３…Ｗｅｂページ表示部
２１４…Ｗｅｂページ有用度計算部
２１５…関連度調整部
２６００…整理体系化装置
２６０１…ナビゲーション生成部。

Claims (15)

1. ある事案に対して一つ以上のＷｅｂページを参照しながら調査を行う際、処理部により前記Ｗｅｂページ間の関連性を抽出するＷｅｂページの関連性抽出方法であって、
   前記処理部は、
   Ｗｅｂ検索サーバに対する検索キーワードとＷｅｂページのアクセス過程を記録する手順と、
   前記記録したＷｅｂページの範囲で参照した第１のＷｅｂページが前記Ｗｅｂ検索サーバの検索結果から遷移したものであり、前記検索キーワードが、前記記録したＷｅｂページの範囲で参照した第２のＷｅｂページに含まれているかを検索キーワードで検索して検出する検出手順と、
   前記検索キーワードが前記第２のＷｅｂページに含まれている場合に、前記第１、第２のＷｅｂページ間の関連性があるとし、前記第１、第２のＷｅｂページ間のアクセス過程を基に、前記第１、第２のＷｅｂページ間の関連性の強さを示す関連度を評価する関連性抽出手順とを実行することを特徴とするＷｅｂページの関連性抽出方法。
2. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記処理部は、
   参照しているＷｅｂページを有用と判断するユーザの行動を捕捉し、前記Ｗｅｂページの有用度を評価する有用度評価手順を更に実行し、
   前記関連性抽出手順は、評価した前記有用度を基に前記関連度を抽出することを特徴するＷｅｂページの関連性抽出方法。
3. 請求項２記載のＷｅｂページの関連性抽出方法であって、
   前記関連性抽出手順は、前記有用度の高い前記Ｗｅｂページ参照時のユーザのＷｅｂブラウザ操作状況を基に前記関連度を評価することを特徴とするＷｅｂページの関連性抽出方法。
4. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記関連性抽出手順は、一連のＷｅｂページのアクセス過程中の位置関係を基に前記関連度の評価を行うことを特徴とするＷｅｂページの関連性抽出方法。
5. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記関連性抽出手順は、Ｗｅｂページ間の参照時間の関係を基に前記関連度の評価を行うことを特徴とするＷｅｂページの関連性抽出方法。
6. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記処理部は、ユーザの識別と属性を管理する手順を更に含み、前記関連性抽出手順は、前記ユーザの属性により前記関連度の評価を行うことを特徴とするＷｅｂページの関連性抽出方法。
7. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記処理部は、事案の範囲を捕捉する手順を更に含み、
   前記関連性抽出手順は、前記捕捉した事案の範囲のＷｅｂページ間について関連性抽出を行うことを特徴とするＷｅｂページの関連性抽出方法。
8. 請求項３記載のＷｅｂページの関連性抽出方法であって、
   前記処理部は、ユーザが設定する前記関連度の評価項目の重み付けに従い、
   前記関連度の評価を行うことを特徴とするＷｅｂページの関連性抽出方法。
9. 請求項１記載のＷｅｂページの関連性抽出方法であって、
   前記処理部は、前記関連性抽出手順により評価した前記関連度に基づき、Ｗｅｂページをレコメンドすることを特徴とするＷｅｂページの関連性抽出方法。
10. 請求項９記載のＷｅｂページの関連性抽出方法であって、
    前記処理部は、Ｗｅｂページをレコメンドする際に、レコメンドする前記Ｗｅｂページの検索キーワードをレコメンドの観点情報として、前記Ｗｅｂページと合わせてレコメンドすることを特徴とするＷｅｂページの関連性抽出方法。
11. ある事案に対して一つ以上のＷｅｂページを参照しながら調査を行う業務における前記Ｗｅｂページ間の関連性を抽出する、処理部と記憶部とを有するＷｅｂページの関連性抽出装置であって、
    前記処理部は、
    Ｗｅｂ検索サーバに対する検索キーワードとＷｅｂページのアクセス過程を記録するＷｅｂアクセス記録部と、
    前記記録したＷｅｂページの範囲で参照した第１のＷｅｂページが前記Ｗｅｂ検索サーバの検索結果から遷移したものであり、検索キーワードが、前記記録したＷｅｂページの範囲で参照した第２のＷｅｂページに含まれているかを検索キーワードで検索して検出し、含まれている場合に、前記第１、第２のＷｅｂページ間の関連性があるとし、前記第１のＷｅｂページと前記第２のＷｅｂページ間のアクセス過程を基に前記第１、第２のＷｅｂページ間の関連性の強さを示す関連度を評価するＷｅｂページ関連性抽出部とを有し、
    前記記憶部は、
    前記第１、第２のＷｅｂページ、関連性のキーとなった前記検索キーワード、及び前記関連度からなるＷｅｂページ関連テーブルを有する、
    ことを特徴とするＷｅｂページの関連性抽出装置。
12. 請求項１１記載の関連性抽出装置であって、
    前記処理部は、参照しているＷｅｂページを有用と判断するユーザの行動を定量的に評価して前記Ｗｅｂページの有用度を得るＷｅｂページ有用度計算部を更に備え、
    前記Ｗｅｂページ関連性抽出部は、前記Ｗｅｂページの有用度を基に前記関連度を抽出することを特徴する関連性抽出装置
13. 請求項１１記載の関連性抽出装置であって、
    前記処理部は、前記関連度の評価項目の重み付けをユーザが設定するための関連度調整部を更に備えることを特徴とする関連性抽出装置。
14. ある事案に対して一つ以上のＷｅｂページを参照しながら調査を行う業務における前記Ｗｅｂページ間の関連性を抽出する、処理部と記憶部とを有するＷｅｂページの関連性抽出装置の処理部で実行されるＷｅｂページの関連性抽出プログラムであって、
    Ｗｅｂ検索サーバに対する検索キーワードとＷｅｂページのアクセス過程を記録する手順と、
    前記記録したＷｅｂページの範囲で参照した第１のＷｅｂページが前記Ｗｅｂ検索サーバの検索結果から遷移したものであり、前記検索キーワードが、前記記録したＷｅｂページの範囲で参照した第２のＷｅｂページに含まれているかを検索キーワードで検索して検出する手順と、
    前記検索キーワードが前記第２のＷｅｂページに含まれている場合に、前記第１、第２のＷｅｂページ間の関連性があるとし、前記第１、第２のＷｅｂページ間のアクセス過程を基に、前記第１、第２のＷｅｂページ間の関連性の強さを示す関連度を評価する手順と、
    からなることを特徴とするＷｅｂページの関連性抽出プログラム。
15. 請求項１４記載のＷｅｂページの関連性抽出プログラムであって、
    前記関連性を基にＷｅｂページをレコメンドする際に、前記レコメンドするＷｅｂページの前記検索キーワードをレコメンドの観点情報として、前記Ｗｅｂページと合わせてレコメンドする手順を更に含むことを特徴とするＷｅｂページの関連性抽出プログラム。

Images