以下、添付した図面を参照して、本発明の実施形態に係る検索結果ナビゲーションシステムを詳細に説明する。
図1は、本発明に係る検索結果ナビゲーションシステムのネットワーク構成の例を示す図である。図1において、検索結果ナビゲーションサーバ101が、ネットワーク102を介して、情報の検索を行うために検索キーワードの入力を行うクライアントユーザの下に設置された複数のクライアントコンピュータ103a、103b、・・・、103n(以下、「クライアントコンピュータ103」)と通信を行うよう構成されている。
クライアントユーザは、クライアントコンピュータ103の入力インタフェースから、検索キーワードを入力することで、そのキーワードが検索結果ナビゲーションサーバ101に送信される。検索結果ナビゲーションサーバ101は当該キーワードを受信すると、そのキーワードに基づいて検索対象となる情報を検索して、クライアントコンピュータ103の入力インタフェースに表示させるために検索結果をクライアントコンピュータ103に送信するが、詳細は後述する。
なお、本実施形態は社内イントラネットでの実装を例としているが、検索結果ナビゲーションサーバ101とクライアントコンピュータ103とはインターネットを介して接続されてもよい。
次に、図2のブロック図を参照して、上述した検索結果ナビゲーションシステムの構成を詳細に説明する。検索結果ナビゲーションサーバ101は、制御部201、主記憶部203、補助記憶部204、入力部205、出力部206、ネットワークI/F207、およびデータベース208を備え、それら各要素がシステムバス202を介して接続される。
制御部201は、中央処理装置(CPU)とも呼ばれ、上記各構成要素の制御やデータの演算を行い、また、補助記憶部204に格納されている各種プログラムを主記憶部203に読み出して実行する。主記憶部203は、メインメモリとも呼ばれ、検索結果ナビゲーションサーバ101が受信した入力データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶する。
補助記憶部204は、ハードディスク(HDD)などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。主記憶部203は、補助記憶部204よりも記憶容量が相対的に小さいため、一時的なデータの記憶や演算処理などに使用されるのに対し、補助記憶部204は、必要なデータや情報の長期的な記憶・保存のために使用される。つまり、制御部201がプログラムを実行してデータの演算を行う場合には、補助記憶部204から必要なデータやプログラムを主記憶部203に読み出し、演算結果のデータを長期的に記憶・保存するには制御部201が補助記憶部204に演算結果のデータを書き込む。データベース208は、後述する質問データ記憶部500、検索結果データ記憶部600、検索履歴データ記憶部700、決定木データ記憶部900、およびカテゴリーデータ記憶部1400のデータテーブルを備える。
ネットワーク102を介して接続されたクライアントコンピュータ103は、ネットワークI/F211、および表示部212を備え、ネットワークI/F211を介して、検索結果ナビゲーションサーバ101と情報をやり取りする。表示部212には、検索結果ナビゲーションシステムにより提供される入力インタフェースが表示され、クライアントユーザはその入力インタフェースを介して検索キーワードを入力する。入力されたキーワードは、検索結果ナビゲーションサーバ101に送信され、主記憶部203または補助記憶部204に一時的に格納され、後述する図11のS1102の処理に続く。
次に、図3を参照して、検索結果ナビゲーションシステムが提供する入力インタフェースの例を示す。クライアントユーザが入力ボックス301に検索キーワードを入力し、検索ボタン302を押下すると、画面右側に検索結果が表示される。本実施形態では検索結果候補の件数が2件であり、2件の情報が表示される。検索結果には検索結果IDと情報が格納されたリンク先URLが表示される。
図4は、検索結果にナビゲートする質問の階層の例を示す図である。本発明に係る検索結果ナビゲーションシステムにおける情報の絞込みは、的確なキーワードの入力をすることができないクライアントユーザのために、予め用意された質問を階層化し、その階層をたどって目的の情報にナビゲートすることに基づいているが、図4を参照してその例を説明する。なお、図4における質問の階層表は、本発明に係る検索結果ナビゲーションシステムの要素を示すものではなく、本発明における情報の絞込みを行う考えの基となる質問の繰り返しの例を示すものであることに留意したい。
例えば、銀行の社内業務において、社内イントラネット上で、事務手続きのマニュアルを検索できるシステムを例とする。インターネット口座開設の手続きマニュアルを参照したい場合に(図4で示すNo.4、10または16のリンク先「http://aaa/koza/net/open.html」にアクセスしたい場合)、従来の情報検索システムの方式で、図4で示す階層から検索キーワード「インターネット口座」で検索すると、No.3、4、9、10、15および16が抽出されることが分かるが、このうちNo.3、9および15は目的とする情報ではない。これに対し、この階層の各質問に関する回答に従って階層をたどると適切な情報へナビゲートされる。
実際に質問をたどってみると、まず、検索キーワードが「インターネット口座」なので、階層3の質問から始まり、階層4の質問へ進む。次に階層4では、口座を開設するということは口座を持っていないことになるので、階層4の質問では「口座なし」となり、階層5へ進み、目的のリンク先にたどりつくことができる。このように、求める情報について十分な知識を有していない者であっても、図4で示すような求める情報へたどるための質問を予め用意し、その質問について回答し、その回答に従って階層をたどることで、適切な情報にナビゲートすることができることが理解できるであろう。
図5は、本発明に係る検索結果ナビゲーションシステムの質問データ記憶部500の例を示す図である。質問データ記憶部500は、後述する検索履歴データ記憶部700に含まれる各質問の内容を示すものであり、クライアントユーザが入力する検索キーワードを基に、後述する検索履歴データ記憶部700のレコードを取得する際に使用され、図4で示した階層を構成する各質問に関する情報が格納される。質問データ記憶部500は、各質問を識別する「質問ID」および質問の内容である「質問」により構成される。
図6は、本発明に係る検索結果ナビゲーションシステムの検索結果データ記憶部600の例を示す図である。検索結果データ記憶部600は、後述するクライアントユーザが入力する検索キーワードを基に、検索履歴データ記憶部700のレコードを取得する際に、および決定木から検索結果IDにたどりついて、その検索結果IDから実際のリンク先URLを取得する際に使用されるものであり、「検索結果ID」、「検索結果」、「リンク先URL」および「関連検索結果ID」により構成される。検索結果IDは、クライアントユーザが求める情報の検索結果を識別するIDであり、リンク先URLは当該検索結果に対応するURLを示すものであり、関連検索結果IDは、検索結果と関連する情報がある場合に、関連する検索結果IDが設定される。
図7は、本発明に係る検索結果ナビゲーションシステムの検索履歴データ記憶部700の例を示す図である。検索履歴データ記憶部700は、後述する決定木データ記憶部900のレコードを作成する際に使用されるものであり、クライアントユーザが過去に質問の階層をたどって検索結果にたどりついた履歴に関する情報が格納される。
図7で示す検索履歴データ記憶部700のレコードは、図4で示す質問の階層に対応する。検索履歴データ記憶部700は、レコードを識別する「検索履歴ID」、当該レコードが検索された日を示す「最終検索日」、図5で示す質問データ記憶部500の各質問についての回答を示す「質問1」乃至「質問n」、質問1乃至質問nが過去に検索された回数を示す「重み1」乃至「重みn」、および質問1乃至質問nを経由してたどりついた検索結果を示す「検索結果ID」およびその検索結果となった回数を示す「重みn+1」により構成され、階層構造となっている。
図7で示すように、「質問1」のデータ値は、例えば、「001Y」が設定されるが、これは図5の質問データ記憶部500の「質問ID」である「001」とその質問についてYESかNOを示す「Y」または「N」が組み合わされたものである。図7の検索履歴ID「0001」を例に説明すると、質問IDが「001」である「定額預金に関する問い合わせですか?」(図5参照)の質問に対してYESの回答であり(質問1)、質問IDが「004」である「申込み手続に関する問い合わせですか?」の質問に対してYESの回答であり(質問2)、質問IDが「007」である「普通口座でのお申込ですか?」の質問に対してYESの回答であり(質問3)、質問IDが「009」である「口座をお持ちですか?」の質問に対してYESの回答であり(質問4)、それらの質問への応答を繰り返して、検索結果IDが「00001」にたどりついた検索履歴を示す。
重み1は、質問1である質問ID「001」に対しYESと回答した回数を示すものであり、この質問を経由するごとに値が加算される。本実施形態における、図7に示す検索履歴データ記憶部700のデータ値は、図4の質問の階層表に対応する。なお、本実施形態では、すべてのレコードが4つの質問の階層で構成されているが、階層の数はそれらに限定されず、レコードにより様々な階層数で構成される場合もある。
図8は、図7の検索履歴データ記憶部700から所定の検索キーワードでレコードを抽出した例を示す。本実施形態では、図3で示す入力インタフェースから、クライアントユーザが検索キーワード「インターネット口座」と入力して、レコードを抽出した例である。抽出方法は後述する。図4を参照すると、キーワード「インターネット口座」が含まれるのは、No.3、4、9、10、15および16となることが分かるので、図8では検索履歴ID「0003」、「0004」、「0009」、「0010」、「0015」および「0016」のレコードが抽出される。
図9は、図8で抽出された検索履歴データ記憶部700から作成される決定木データ記憶部900の例を示す。そして、この決定木データ記憶部900を決定木として示したのが図9となる。決定木データ記憶部900は、図8の検索履歴データ記憶部700のレコードから決定木の構造に変換されたデータを格納するものであり、「決定木ID」(検索履歴データ記憶部700の検索履歴IDに対応する)、「質問1」乃至「質問n」、「重み1」乃至「重みn」、「検索結果ID」、および「重みn+1」により構成される。決定木データ記憶部900は、検索履歴データ記憶部700のレコードから作成されるが、決定木を作成することにより、検索履歴データ記憶部700の質問階層から階層数が変更される。つまり決定木データ記憶部900は可変構造のデータとなる。
検索履歴データ記憶部700からの決定木データ記憶部900の作成は以下のように行われる。まず、図8における検索履歴データ記憶部700のレコード全体Cの平均情報量M(C)を以下の式により求める。
図8の検索履歴データ記憶部700のレコード全体において、検索結果IDのとりうる値は4つ(「00001」、「00003」、「00006」および「00008」)となるので、対数の底を4とし、レコード件数が6なので、式1にあてはめると式2となり平均情報量M(C)≒0.8962となる。
次に、質問1の「001Y」のレコード件数が2、それに対する検索結果IDのとりうる値も2なので、式1にあてはめると式3となり平均情報量M(C11)≒0.5000となる。
続いて、質問1の「002Y」についても同様に平均情報量を求め、質問2乃至4までのそれぞれの平均情報量を求めて、それぞれの平均情報量をレコード全体の平均情報量M(C)から減算した値である期待値を求めると、以下のようになる。
上記表から、期待値が最も大きいのは質問4であり、その後に質問1が続くので、その期待値に基づいて、図9のような決定木データ記憶部900のレコードが作成される。図9における質問1および重み1、質問2および重み2、ならびに検索結果IDおよび重み3は、図8における質問4および重み4、質問1および重み1、ならびに検索結果IDおよび重み5にそれぞれに対応する。
図10は、図9の決定木データ記憶部900から作成された決定木を示しており、各質問がノード、回答結果がエッジ、および検索結果がリーフノードとなる。図9および図10から、決定木を作成することで図4の質問の階層数が少なくなり、より早く検索結果にたどりつくことができることが理解できるであろう。
次に、図11のフローチャートを使用して、本発明の一実施形態に係る検索結果ナビゲーションシステムが行う一連の処理を説明する。
クライアントコンピュータ103のクライアントユーザが、クライアントコンピュータ103を介して検索結果ナビゲーションサーバ101に接続し、入力インタフェース上の入力ボックス301に検索キーワード「インターネット口座」を入力して、検索ボタン302を押下して、その検索キーワードを送信したものとする。
検索結果ナビゲーションサーバ101は、検索キーワードを受信する(S1101)。受信した検索キーワードは、主記憶部203に格納される。
制御部201は、主記憶部203に格納された検索キーワードをキーとして、質問データ記憶部500からレコードを取得する(S1102)。取得した質問データ記憶部500のレコードは主記憶部203に格納される。図5を参照すると、本実施形態では、質問データ記憶部500からは質問ID「008」のレコードを取得できることが分かる。
次に、制御部201は、主記憶部203に格納された検索キーワードをキーとして、検索結果データ記憶部600からレコードを取得する(S1103)。取得した検索結果データ記憶部600のレコードは主記憶部203に格納される。図6を参照すると、本実施形態では、検索結果データ記憶部600からは検索結果ID「00003」のレコードを取得できることが分かる。
次に、制御部201は、S1102で取得した質問データ記憶部500のレコードに含まれる質問IDをキーとして、検索履歴データ記憶部700からレコードを取得する(S1104)。取得した検索履歴データ記憶部700のレコードは主記憶部203に格納される。本実施形態では、質問ID「008」をキーとするので、検索履歴データ記憶部700からは、検索履歴ID「0003」、「0004」、「0009」、「0010」、「0015」および「0016」のレコードを取得することができる。
次に、制御部201は、S1103で取得した検索結果データ記憶部600のレコードに含まれる検索結果IDをキーとして、検索履歴データ記憶部700からレコードを取得する(S1105)。取得した検索履歴データ記憶部700のレコードは主記憶部203に格納される。本実施形態では、検索結果ID「00003」をキーとするので、検索履歴データ記憶部700からは、検索履歴ID「0004」、「0010」および「0016」のレコードを取得することができる。ここで、検索履歴データ記憶部700のレコードは、S1104およびS1105の双方で取得されているので、重複レコードが発生する場合もあるが、そのレコードはマージされる。なお、S1103で取得した検索結果データ記憶部600のレコードに含まれる関連検索結果IDに値が設定されている場合は、当該IDをキーとしても検索履歴データ記憶部700からレコードを取得する。
なお、本実施形態では、検索キーワードを基に質問データ記憶部500および検索結果データ記憶部600を取得してから、その取得したレコードに含まれる質問IDおよび検索結果IDに基づいて検索履歴データ記憶部700からレコードを取得する構成となっているが、これは、検索履歴データ記憶部700は検索キーワードが含まれるデータの項目を有していないためである。これを検索履歴データ記憶部700に質問や検索結果の内容そのものの項目を含ませて、検索キーワードをキーとして直接、検索履歴データ記憶部700からレコードを取得する構成にしてもよい。また、本実施形態では、質問データ記憶部500のレコードに含まれる質問IDおよび検索結果データ記憶部600のレコードに含まれる検索結果IDのそれぞれをキーとして、検索履歴データ記憶部700からレコードを取得する構成になっているが、これを質問IDまたは検索結果IDのいずれかをキーとして、検索履歴データ記憶部700からのレコードの取得を1回のみ行う構成にしてもよい。
次に、制御部201は、主記憶部203に格納された検索履歴データ記憶部700のレコードに基づいて、決定木データ記憶部900のレコードを作成する(S1106)。決定木データ記憶部900の作成方法は上述したとおりである。作成した決定木データ記憶部900のレコードは、主記憶部203に格納される。
次に、制御部201は、主記憶部203に格納された決定木データ記憶部900のレコードを1件ずつ読み込み、検索結果候補となる検索結果IDを抽出する(S1107)。本実施形態では、重み値を使用して検索結果候補となる検索結果IDを抽出する例を示す。図9の決定木データ記憶部900を参照すると、6件のレコードの質問1に対応する重み1の重み値をすべて参照すると、3、13、29、21、4および30となることが分かる。例えば、重み値が20以上のレコードのみを判定結果の候補として抽出すると仮定した場合に、質問1では決定木ID「0009」、「0010」および「0016」の3件のレコードを抽出できる(いずれも質問1の重み値が20以上)。また、質問2に対応する重み2の重み値により抽出すると、上記3件の重み2の重み値がそれぞれ25、8および28なので、さらに、決定木ID「0009」および「0016」の2件のレコードを抽出できる。最後に、検索結果IDに対応する重み3の重み値により抽出すると、上記2件の重み3の重み値がそれぞれ38および15なので、決定木ID「0009」のレコードが抽出できる。このように、質問ごとに過去の検索回数に基づいて検索結果の候補を抽出するので、検索キーワードにより抽出された候補の中から高い確率で的確な情報を絞り込むことができる。
なお、本実施形態では、各質問の過去の検索された回数である重み値を所定値と比較することにより検索結果候補を抽出しているが、このような抽出方法に限定されず、例えば、重み値から条件付き確率を求め(例えば、ベイズの定理に基づいて、上位階層の質問の事前確率から事後確率を求める)、その確率が所定値以上であるかを基準に候補を抽出するといった構成にしてもよい。また、抽出すべき重み値を予め固定する必要はなく、例えば、上述した検索の結果、検索結果件数が所定の値以上となった場合に、クライアントユーザから入力インタフェースを介して重み値の入力を受け付けて、その受け付けた重み値以上の検索結果を抽出するように構成してもよい。例えば、検索結果候補が1000件となった場合に、入力インタフェースにはその旨を表示し、クライアントユーザからは絞り込む条件として過去の参照回数である重み値の入力を受け付けて、その受け付けた重み値に基づいて検索結果候補を抽出するといった構成になる。
次に、制御部201は、S1107で抽出した検索結果候補となる決定木データ記憶部900のレコードに含まれる検索結果ID(本実施形態では決定木IDが「0009」である検索結果ID「00006」)をキーとして、検索結果データ記憶部600からレコードを取得する(S1108)。取得したデータレコードは、主記憶部203に格納される。ここで、S1103で検索結果データ記憶部600からレコードを取得したにもかかわらず、再度、検索結果データ記憶部600からレコードを取得するのは、S1107で抽出された決定木データ記憶部900のレコードに含まれる検索結果IDを有する検索結果データ記憶部600のレコードすべてを、S1103で取得できるとは限らないからである。一方、S1107で抽出した決定木データ記憶部900のレコードに含まれる検索結果IDを有する検索結果データ記憶部600のレコードのすべてを、S1103で取得できた場合は、本ステップで再度、検索結果データ記憶部600のレコードを取得する必要はなく、主記憶部203に格納された検索結果データ記憶部600のレコードに含まれるリンク先URLを、後述するクライアントコンピュータ103に送信するような構成にしてもよい。
次に、制御部201は、S1107で抽出した決定木データ記憶部900のレコードに含まれる決定木IDをキーとして、検索履歴データ記憶部700のレコードを更新する(S1109)。ここで、決定木ID「0009」を例にして説明すると、決定木データ記憶部900は質問1、2および検索結果の階層により構成されているので、図7の検索履歴データ記憶部700の検索履歴ID「0009」のレコードに対し、質問4に対する「重み4」、質問1に対する「重み1」および検索結果に対する「重み5」のそれぞれの値に1が加算され、「最終検索日」にはタイムスタンプ等の日付に更新される。本実施形態では、S1107にて検索結果候補として抽出された決定木データ記憶部900のレコードに対応する検索履歴データ記憶部700のレコードのみを更新しているが、これに限定されず、例えば、S1104およびS1105にて取得した検索履歴データ記憶部700の全レコードについて重み値を加算し、最終検索日をタイムスタンプ等の日付に更新するように構成してもよい。この場合は、検索履歴ID「0003」、「0004」、「0009」、「0010」、「0015」および「0016」の重み1乃至重み5のぞれぞれの値に1が加算され、最終検索日はタイムスタンプ等の日付に更新される。また、加算する重み値は1である必要はなく、0.5などの任意の値であってもよい。
最後に、制御部201は、S1107で抽出した決定木データ記憶部900のレコードに含まれる検索結果ID、およびS1108で検索結果データ記憶部600から取得したレコードに含まれるリンク先URLをネットワークI/F207を介してクライアントコンピュータ103に送信する(S1110)。クライアントコンピュータ103は検索結果IDおよびリンク先URLを受信すると、それらの情報を表示部212に表示された入力インタフェースに表示する。
以上のように、本実施形態では、過去に質問を繰り返して検索結果にたどりついた質問の検索履歴に基づいて決定木を作成して、検索結果を絞り込んでいるので、情報の検索にあたって、求める情報に関する知識が十分になくても適切な検索結果を取得することができる。また、上記決定木のレコードからさらに重み値に基づいてレコードを抽出しているので、検索キーワードによる絞り込みが不十分なことにより検索結果候補が大量に抽出されるというようなことも防止することができる。
なお、本実施形態では、検索履歴データ記憶部700に「最終検索日」が含まれ、該当のレコードが検索される際に、当該日付が最新の日付に更新されるが、この日付の更新により、長期間検索がされなかった検索頻度の低いレコードを削除することが可能となる。例えば、定期的に(定期的な夜間バッチ処理)もしくはクライアントユーザの情報検索実行命令に応答して、検索履歴データ記憶部700から所定期間検索がされなかったレコード(最終検索日の値が一定の日付以前のレコード)を一括して削除するような構成にしてもよい。
次に、図12のフローチャートを使用して、本発明の別の実施形態に係る検索結果ナビゲーションシステムが行う一連の処理を説明する。
まず、図13を参照すると、本実施形態ではクライアントコンピュータ103の表示部212に表示される入力インタフェースには、カテゴリー表示ボックス1301および検索ボタン1302が設けられる。カテゴリー表示ボックス1301は、検索対象となるすべての情報がカテゴリー別に表示される表示領域であり、ユーザはその中のカテゴリーを選択するとその下の階層のカテゴリーが表示され、順にたどっていくことができる。図13はすべての検索対象となる情報から「外貨預金」のカテゴリーを選択している状態を示す。このような状態で、クライアントコンピュータ103のクライアントユーザが、クライアントコンピュータ103を介して検索結果ナビゲーションサーバ101に接続し、入力インタフェース上のカテゴリー表示ボックス1301から「外貨預金」を選択して、検索ボタン1302を押下して、その情報を送信したものとする。
検索結果ナビゲーションサーバ101は、選択されたカテゴリーを受信する(S1201)。受信したカテゴリーは、主記憶部203に格納される。
次に、制御部201は、主記憶部203に格納されたカテゴリーをキーとして、カテゴリーデータ記憶部1400からレコードを取得する(S1202)が、ここで、図14に示すカテゴリーデータ記憶部1400を説明する。
カテゴリーデータ記憶部1400は、図13で示す入力インタフェースのカテゴリー表示ボックスに対応するようにカテゴリー別に階層表示される情報が格納される。カテゴリーデータ記憶部1400は、各レコードを識別する「カテゴリーID」、そのカテゴリー名を示す「カテゴリー名」、当該カテゴリーの下位に存在するカテゴリーIDを示す「リンク先ID」および当該カテゴリーに対応する検索履歴データ記憶部700のレコードを示す「検索履歴ID」により構成される。このデータ構造を図13のカテゴリー表示を例に説明する。
図13では、カテゴリー「預金・運用商品」が第1階層であり、その下位にカテゴリー「預金共通」、「運用商品共通」、「預金」および「運用商品」と第2階層が存在する。カテゴリー「預金」の下位には、カテゴリー「定額預金」および「外貨預金」と第3階層が存在する。図14で示すカテゴリーIDが「000001」であるカテゴリー「預金・運用商品」の下位には、カテゴリーIDが「000002」(預金)、「000003」(運用商品)、「000004」(預金共通)および「000005」(運用商品共通)が存在するので、リンク先IDには「000002−000005」が設定される。カテゴリーIDが「00002」である「預金」の下位には、カテゴリーIDが「000006」(定額預金)および「000007」(外貨預金)が存在するので、リンク先IDには「000006−000007」が設定される。カテゴリー「預金」には、検索履歴データ記憶部700の検索履歴ID「0001」乃至「0012」までが対応するので、検索履歴IDには「0001−0012」が設定される。
このような仕組みの下、図12で示すフローチャートの説明に戻ると、S1202では、クライアントユーザがカテゴリー「外貨預金」を選択しているので、カテゴリーデータ記憶部1400からはカテゴリーID「000007」のレコードを取得できることになる。取得したカテゴリーデータ記憶部1400のレコードは主記憶部203に格納される。
次に、処理がS1203に進むと、制御部201は、主記憶部203に格納されたカテゴリーデータ記憶部1400のレコードに含まれる検索履歴IDをキーとして、検索履歴データ記憶部700からレコードを取得する(S1203)。取得した検索履歴データ記憶部700のレコードは主記憶部203に格納される。ここで、カテゴリーデータ記憶部1400のレコードに含まれる検索履歴IDは複数のIDが含まれるが、それらのIDを1件ずつキーとして検索履歴データ記憶部700のレコードを取得してもよく、また範囲指定で検索履歴データ記憶部700のレコードを取得してもよい。
次に、主記憶部203に格納された検索履歴データ記憶部700のレコードに基づいて決定木データ記憶部900のレコードを作成することになるが(S1204)、この決定木データのレコード作成ステップからそれ以降の処理は、図11で説明したS1106以降の処理と同様となる。S1204乃至S1208は、図11で示すS1106乃至S1110に対応するが、検索履歴データ記憶部700のレコードに基づいて、決定木データ記憶部900のレコードを作成し(S1204)、決定木データ記憶部900のレコードから重み値に基づいて検索結果候補となる検索結果IDを抽出し(S1205)、当該検索結果IDをキーとして、検索結果データ記憶部600からレコードを取得し(S1206)、抽出した決定木データ記憶部900のレコードに含まれる決定木IDをキーとして、検索履歴データ記憶部700のレコードを更新し(S1207)、抽出した決定木データ記憶部900のレコードに含まれる検索結果ID、および検索結果データ記憶部600から取得したレコードに含まれるリンク先URLをネットワークI/F207を介してクライアントコンピュータ103に送信する(S1208)。
以上、説明したように、本実施形態では、クライアントユーザからのカテゴリー選択を受け付けて、そのカテゴリーに基づいて検索履歴データ記憶部700からレコードを取得して、決定木データのレコードを作成するので、本発明の第1の実施形態と比較して、さらなる検索結果候補の絞込みを行うことができ、的確に求める情報にナビゲートできることが分かるであろう。
次に、図15のフローチャートを使用して、本発明のさらなる別の実施形態に係る検索結果ナビゲーションシステムが行う一連の処理を説明する。
まず、クライアントコンピュータ103のクライアントユーザが、入力インタフェース上の入力ボックス301に検索キーワードを入力する処理から始まるが、本実施形態のうちS1501からS1507までの処理は、図11で示したS1101からS1107までの処理にそれぞれ対応しており、検索結果ナビゲーションサーバ101が入力された検索キーワードを受信し(S1501)し、制御部201が当該検索キーワードをキーとして、質問データ記憶部500からレコードを取得し(S1502)、制御部201が当該検索キーワードをキーとして、検索結果データ記憶部600からレコードを取得し(S1503)、取得した質問データ記憶部500のレコードに含まれる質問IDをキーとして、検索履歴データ記憶部700からレコードを取得し(S1504)、取得した検索結果データ記憶部600のレコードに含まれる検索結果IDをキーとして、検索履歴データ記憶部700からレコードを取得し(S1505)、当該検索履歴データ記憶部700のレコードに基づいて、決定木データ記憶部900のレコードを作成し(S1506)、当該決定木データ記憶部900のレコードを1件ずつ読み込み、重み値に基づいて検索結果候補となる検索結果IDを抽出する処理を行う(S1507)。
S1507では、作成した決定木データ記憶部900のレコードから検索結果候補となる検索結果IDが抽出されるが、制御部201はその検索結果候補の件数が所定値の範囲内にあるか否かを判定する(S1508)。ここで、所定値の範囲内にあるか否かとは、例えば、検索結果候補の件数を100件以内に絞り込むことを前提としている場合は、検索結果候補の件数が100件以内にあるか否かを判定することである。上記判定で、検索結果候補の件数が所定値の範囲内にない場合は、後続のステップ(カテゴリーデータ記憶部レコード取得処理)に進み、そうでない場合はS1515に進む。
次に、制御部201は、S1507で抽出した決定木データ記憶部900のレコードを1件ずつ読み込み、各レコードに含まれる決定木IDをキーとして、カテゴリーデータ記憶部1400からレコードを取得する(S1509)。取得したカテゴリーデータ記憶部1400のレコードは主記憶部203に格納される。本実施形態では、カテゴリーデータ記憶部1400の検索履歴IDに上記決定木IDが含まれるレコードを取得することになる。決定木データ記憶部900のレコードは複数存在することになるが、そのレコードをすべて読み込み、1件ずつをキーとしてカテゴリーデータ記憶部1400からレコードを取得する。
次に、制御部201は、主記憶部203に格納されたカテゴリーデータ記憶部1400のレコードに基づいて、階層化カテゴリーデータを作成する(S1510)。作成した階層化カテゴリーデータは主記憶部203に格納される。階層化カテゴリーデータとは、カテゴリーデータ記憶部1400のレコードに基づいて階層構造となったカテゴリーデータを意味し、上述したカテゴリーデータ記憶部1400のリンク先IDに基づいて階層化する。
次に、制御部201は、主記憶部203に格納された階層化カテゴリーデータをネットワークI/F207を介してクライアントコンピュータ103に送信する(S1511)。クライアントコンピュータ103は、上記階層化カテゴリーデータを受信し、表示部212のカテゴリー表示ボックス1301に表示する。このような状態で、クライアントコンピュータ103のクライアントユーザは、カテゴリー表示ボックス1301から任意のカテゴリーを選択し、検索ボタン1302を押下して、選択されたカテゴリーがネットワークインタフェース212を介して検索結果ナビゲーションサーバ101に送信される。
次に、検索結果ナビゲーションサーバ101は、選択されたカテゴリーを受信する(S1512)。受信したカテゴリーは、主記憶部203に格納される。
次に、制御部201は、主記憶部203に格納されたカテゴリーをキーとして、カテゴリーデータ記憶部1400からレコードを取得する(S1513)。取得したカテゴリーデータ記憶部1400のレコードは主記憶部203に格納される。
次に、制御部201は、主記憶部203に格納されたカテゴリーデータ記憶部1400のレコードに含まれる検索履歴IDに基づいて、S1507で抽出した決定木データ記憶部900のレコードを抽出する(S1514)。決定木データ記憶部900の決定木IDは検索履歴IDに対応することは上述したとおりであり、カテゴリーデータ記憶部1400のレコードに含まれる検索履歴IDに基づいて、決定木データ記憶部900のレコードを対応づけることができる。
次に、S1508に戻り、抽出された決定木データ記憶部900の検索結果候補の件数が所定値の範囲内にあるか否かの判定が行われるが、この判定によってもさらに所定値の範囲内にないと判定される場合は、さらにS1509乃至S1514の処理が繰り返される。一方、検索結果候補が所定値の範囲内にあると判定された場合は、S1515に進むが、これ以降の処理は図11で示したS1108からS1110までの処理にそれぞれ対応するので、ここでの説明は省略する。
以上、説明したように、本実施形態では、作成した決定木データから重み値に基づいて検索結果候補を抽出した後において、検索結果候補の件数が所定の値にない場合に、クライアントユーザからのカテゴリー選択を受け付けて、そのカテゴリーに基づいてさらに決定木データを抽出して検索結果候補を絞り込むことができる。したがって、本実施形態では、本発明の第1の実施形態において検索結果を絞り込んだ結果において検索結果候補が大量に抽出されてしまうような場合でも、的確に求める情報にナビゲートすることができる。
なお、本実施形態では、重み値に基づいて抽出された決定木データの件数が所定値の範囲内にない場合に、クライアントユーザからのカテゴリー選択を受け付けて、その選択されたカテゴリーに基づいてさらに決定木データを抽出しているが、このような構成に限定されず、抽出した決定木データの件数が所定値の範囲内にない場合には、入力インタフェース上の入力ボックス301からさらなる検索キーワードの入力を受け付けて、作成した決定木データ記憶部900のレコードから入力された検索キーワードに基づいてレコードを抽出するように構成してもよい。この場合の動きを以下に説明する(図示せず)。
S1508の判定後に以下のとおりとなる。受け付けた検索キーワードをキーとして、質問データ記憶部500からレコードを取得する(S1509)。検索結果データ記憶部600からレコードを取得する(S1510)。S1509で取得した質問データ記憶部500に含まれる質問IDをキーとして、S1507で抽出した決定木データ記憶部900からレコードを取得する(S1511)。S1510で取得した検索結果データ記憶部600のレコードに含まれる検索結果IDをキーとして、1507で抽出した決定木データ記憶部900からレコードを取得する(S1512)。S1511で取得した決定木データ記憶部900のレコードとS1512で取得した決定木データ記憶部900のレコードをマージする(S1513)。次に、S1508に戻り、マージした決定木データ記憶部900の検索結果候補の件数が所定値の範囲内にあるか否かの判定が行われる。
また、S1508における検索結果候補の件数判定が所定以下の場合に、クライアントユーザからカテゴリー選択を受け付けて、そのカテゴリーを基に絞り込みを行うカテゴリー検索と、クライアントユーザから検索キーワードの入力を受け付けて、その検索キーワードを基に絞込みを行うキーワード検索を組み合わせて、いずれかで絞込みを行う構成にしてもよい。
さらに、本実施形態では、S1508における検索結果候補の件数判定が所定以下の場合に、さらなるカテゴリー検索またはさらなるキーワード検索を行うような構成にしているが、検索結果候補の件数に関わらず、クライアントユーザからの検索キーワードの入力、またはカテゴリー選択に応じて、さらなる検索を行うような構成にしてもよい。