(57)【特許請求の範囲】
【請求項１】
文書情報と、前記文書情報が指し示す文書に含まれる一つ以上の検索キーワードよりなる検索結果データから前記検索キーワードを抽出して、前記検索キーワードが格納されるキーワードフィールドよりなるキーワードリストを生成するキーワード抽出部と、
前記検索結果データから、前記文書情報が格納される文書情報フィールドと、前記検索キーワードが一つ以上格納されるキーワード列フィールドよりなる検索結果テーブルを生成するコンテキスト生成部と、
前記キーワードフィールドと、前記キーワードフィールドに格納される前記キーワードを含む前記文書情報が一つ以上格納される文書情報列フィールドと、前記文書情報列フィールドに格納される一つ以上の前記文書情報に共通する前記検索キーワードが一つ以上格納されるキーワード列フィールドと、レコード同士の直近の上下関係が一つ以上格納されるノード列フィールドとを有する概念テーブルと、
前記キーワードリストと前記検索結果テーブルから前記概念テーブルのレコードを生成する概念生成部と、
前記概念テーブルの前記ノード列フィールドに前記上下関係を記入する分岐構造生成部と、
前記文書情報列フィールドと、前記キーワード列フィールドに格納されている情報をノードとして、前記ノード列フィールドに格納されている情報をエッジとして、前記ノード同士を前記エッジで結線する画像を構成する分岐構造描画データを生成する描画処理部と
を具備する情報検索支援装置。
【請求項２】
前記分岐構造生成部は、最下位の概念を示すノードに対するエッジを生成しない、
請求項１記載の情報検索支援装置。
【請求項３】
前記概念生成部は、最下位の概念のレコードを生成しない、
請求項１記載の情報検索支援装置。
【請求項４】
前記描画処理部は、最下位の概念を示すノードを描画しない、
請求項１記載の情報検索支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報検索支援装置に適用して好適な技術に関する。
より詳細には、情報検索の結果として得られる候補を、概念で階層化した上で、見やすいグラフィック表示にて情報検索利用者に提供する、情報検索支援装置に関する。
【背景技術】
【０００２】
インターネットの普及により、ｗｅｂサイトは爆発的に増加している。Ｎｅｔｃｒａｆｔ社の調査によれば、１９９７年に１００万だった全世界のｗｅｂサイト数は、２０００年に１００万、２００６年に１億を突破し、２０１１年１２月時点で約５億５５００万に達している、とのことである。
周知の通り、膨大な情報源であるインターネットのｗｅｂサイトから所望の情報を見つけるために、検索サイトが活用されている。しかしながら、情報源の爆発的な増加によって、ユーザが所望の情報を収集することが困難になっている。特に、幾つかのキーワードによる検索にヒットするｗｅｂサイトの中には、ユーザが希望しない情報、つまりノイズが多くヒットする場合があり、この傾向は近年になって増加する傾向にある。
【０００３】
一般的に、既存の検索エンジンは検索結果として各ｗｅｂページのタイトルと概要文を、何らかの指標に基づいて一列に並べたリストとして表示する。この場合、ユーザは必要としている情報を大局的な観点で把握することができない。このため、検索結果の上位から順にページの内容を確認する場合が多い。ユーザは検索結果の上位に位置するｗｅｂサイトを幾つか見た後、所望の情報を得られない場合は検索のキーワードを追加して再検索を行うことが多い。こうして、ユーザが所望の情報を得るために時間が浪費される。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】小島秀一，高須淳宏，安達淳：Web ページ群の構造解析とグループ化，NII Journal,Vol.4, pp.23-35 (2002).［２０１２年１月２日検索］、インターネット＜URL:http://www.nii.ac.jp/journal/pdf/04/04-03.pdf＞
【非特許文献２】吉田大我，中村聡史，田中克己：ブラウジングと検索の融合: 閲覧履歴からの関連情報の検索・自動提示にもとづくウェブ閲覧，Journal of the DBSJ, Vol.7, No.1, pp.133-138(2008)［２０１２年１月２日検索］、インターネット＜URL:http://www.dbsj.org/journal/vol7/no1/papers/Taiga%20YOSHIDA.pdf＞
【非特許文献３】稲川雅之，大島裕明，小山聡，田中克己：Web からの語集合間の特定関係抽出とその可視化，日本データベース学会論文誌, Vol.7, No.1 (2008)［２０１２年１月２日検索］、インターネット＜URL:http://www.ieice.org/~de/DEWS/DEWS2008/proceedings/files/a7/a7-4.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
大量にヒットするウェブ検索の結果をより網羅的に扱いやすくするために、大局的な観点から俯瞰する研究がいくつか行われている。
非特許文献１は、サイト上のページをグループ化するという方法を提案している。非特許文献１では、意味的に関連した文書をひとまとまりにすることにより、サイトの全体像をユーザへ提示することなどが可能となる。従来の文書の自動分類などでは文書間の類似度を利用して処理が行われているが、この研究ではページ間のリンク構造に着目してサイト内のページ集合をウェブグラフとみなし、強連結成分をグループとして抽出することを試みている。また、グループは階層的な構造をしているので、その階層構造を抽出するために強連結成分の分割を行っている。
【０００６】
非特許文献２は、検索結果ページ中に現れる重要語を話題語として抽出し、それらの出現傾向をグラフを用いて可視化することにより、検索結果ページの傾向を一覧的に表示することを考案している。そして、グラフ上に表示した話題語をユーザとの対話操作によって重み付けを行い、動的にクエリ修正および再ランキングをすることで検索支援を行っている。
【０００７】
非特許文献３は、ｗｅｂから抽出した人物や作品などのオブジェクトに対して、ある語集合がオブジェクトを特定するという関係をグラフとして表現することで可視化を行っている。可視化により、オブジェクト間あるいは語集合間の関係を把握することや、入力語集合の周辺の話題を探索するといったことが直感的に可能となる。
【０００８】
これら先行技術は、何れも対象ウェブページ群を意味的な観点からグルーピングすることについては考慮していない。また、検索結果全体の俯瞰よりは、必要な一部分の情報を自動的に抽出することに重点が置かれている。つまり、これら先行技術は、人間の持つ情報の蓄積に基づく、情報の概念に基づいて整理された検索結果を提示してはくれない。このため、これら従来技術は人間の直感に沿った検索結果を提供するとはいえない。
【０００９】
本発明は係る課題に鑑みてなされたものであり、概念の広狭の観点から検索結果のウェブページを分類し、概念を階層化することにより、人間の直感に適切な形で大局的に俯瞰することができる、情報検索支援装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明の情報検索支援装置は、文書情報と、文書情報が指し示す文書に含まれる一つ以上の検索キーワードよりなる検索結果データから検索キーワードを抽出するキーワード抽出部と、検索結果データから、文書情報が格納される文書情報フィールドと、検索キーワードが一つ以上格納されるキーワード列フィールドよりなる検索結果テーブルを生成するコンテキスト生成部と、キーワードフィールドと、キーワードフィールドに格納されるキーワードを含む文書情報が一つ以上格納される文書情報列フィールドと、文書情報列フィールドに格納される一つ以上の文書情報に共通する検索キーワードが一つ以上格納されるキーワード列フィールドと、レコード同士の直近の上下関係が一つ以上格納されるノード列フィールドとを有する概念テーブルと、キーワードリストと検索結果テーブルから概念テーブルのレコードを生成する概念生成部と、概念テーブルのノード列フィールドに上下関係を記入する分岐構造生成部と、文書情報列フィールドと、キーワード列フィールドに格納されている情報をノードとして、ノード列フィールドに格納されている情報をエッジとして、ノード同士をエッジで結線する画像を構成する分岐構造描画データを生成する描画処理部とを具備する。
【００１１】
検索結果データから文書情報と検索キーワードを抜粋して、概念テーブルに書き出す。概念テーブルのレコードをノードとして、ノード同士の上下関係を導出し、直近の上下関係のみエッジとして描画する対象として残す。その際、最下位概念（内包の要素が全キーワード）のレコードは描画対象から外す。こうすることにより、最下位概念のノードが描画されず、また最下位概念のノードによって直近の上下関係にあるノードが引っ張られない。このため、最下位概念の直近のノードが全て端末の画面の周縁側に配置されるので、ノード同士の距離が適切に離れ、画面の利用効率が向上し、ノードの視認性が極めて良くなる。
【発明の効果】
【００１２】
本発明により、概念の広狭の観点から検索結果のウェブページを分類し、概念を階層化することにより、人間の直感に適切な形で大局的に俯瞰可能な、情報検索支援装置を提供できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態の例である、情報検索支援装置を有するネットワークシステムの概略図である。
【図２】情報検索支援装置が実行するデータの加工の流れを示す概略図と、端末に表示される画面イメージを示す図である。
【図３】情報検索支援装置の機能ブロック図である。
【図４】各テーブルの関係と、各テーブルのフィールド構成を示す図である。
【図５】概念生成部が実行する概念生成処理の動作の流れを示すフローチャートである。
【図６】概念生成部が実行する概念生成処理の動作の流れを示すフローチャートである。
【図７】概念生成部が実行する概念生成処理の動作の流れを示すフローチャートである。
【図８】分岐構造生成部が実行する分岐構造生成処理の動作の流れを示すフローチャートである。
【図９】分岐構造生成部が実行する分岐構造生成処理の動作の流れを示すフローチャートである。
【図１０】分岐構造生成部が実行する分岐構造生成処理の動作の流れを示すフローチャートである。
【図１１】描画処理の工夫を施す前と描画処理の工夫を施した後の画面表示例である。
【図１２】本実施形態の情報検索支援装置によって生成される表示画面の例である。
【図１３】本実施形態の情報検索支援装置によって生成される表示画面の例である。
【発明を実施するための形態】
【００１４】
［システム全体］
図１（ａ）、（ｂ）及び（ｃ）は、本発明の実施形態の例である、情報検索支援装置を有するネットワークシステムの概略図である。
図２（ａ）及び（ｂ）は、情報検索支援装置が実行するデータの加工の流れを示す概略図と、端末に表示される画面イメージを示す図である。
【００１５】
先ず、図１（ａ）は、情報検索支援装置を有するネットワークシステムの概略図である。
一般的なパソコンや携帯型無線端末等の端末１０１は、図示しないインターネットを通じて、変換サーバ１０２に接続する。端末１０１は変換サーバ１０２が提供する検索画面の入力フォームに、検索用のキーワードを入力する。すると、変換サーバ１０２は端末１０１から受信した検索用キーワードを、検索サーバ１０３に送信する。一般的なｗｅｂ検索エンジンである検索サーバ１０３は、変換サーバ１０２から与えられた検索用キーワードに基づいて図示しないデータベースに対して情報検索を実行し、検索結果を変換サーバ１０２に送信する。変換サーバ１０２は情報検索支援装置１０４を内蔵しており、情報検索支援装置１０４は検索サーバ１０３から受信した検索結果データ２０１を加工して、分岐構造描画データ２０２を作成する。そして、変換サーバ１０２は分岐構造描画データ２０２を端末１０１に送信する。端末１０１は、変換サーバ１０２から分岐構造描画データ２０２を受信すると、図２（ｂ）に示す画面イメージを端末１０１の表示部１０５に表示する。
【００１６】
図２（ｂ）は、円と円が線で結ばれている。円は概念で括られた検索結果の集合を表し、線は上位概念と下位概念の関係を表す。これ以降、円を「ノード」と、線を「エッジ」と呼ぶ。
表示画面の中心近辺にある円は、最も上位の概念である。図２（ｂ）の場合、（｛１，２，３，４｝，φ）と記されている円が再上位概念である。これは、検索結果として得られるＵＲＬ（Uniform Resource Locator）が「｛１，２，３，４｝」の四つ存在し、この四つのＵＲＬに共通する検索キーワードが空集合（「φ」で表す）、つまり存在しないことを意味する。
最上位の概念から二つのエッジが伸びて、次のノードに到達する。
（｛１，２，３｝，｛○×｝）というノードは、ＵＲＬが｛１，２，３｝の三つ存在し、この三つのＵＲＬに共通する検索キーワードが「○×」という文字列であることを意味する。
（｛３，４｝，｛案内｝）というノードは、ＵＲＬが｛３，４｝の二つ存在し、この二つのＵＲＬに共通する検索キーワードが「案内」という文字列であることを意味する。
円をマウス等のポインティングデバイスでクリックすると、概念として含められているｗｅｂページのタイトルがポップアップウィンドウとして現れ、そのタイトルに埋め込まれているＵＲＬをマウスでクリックすると、目的のｗｅｂサイトにアクセスすることができる。
【００１７】
変換サーバ１０２は、検索サーバ１０３から得られるリスト形式の検索結果データ２０１を、グラフィックイメージの分岐構造描画データ２０２に変換する、ＡＳＰ(Application Service Provider)サービスを提供する。変換サーバ１０２のＡＳＰサービスは、情報検索支援装置１０４が提供する。つまり、情報検索支援装置１０４は、図２（ａ）に示すように、リスト形式の検索結果データ２０１を、グラフィックイメージの分岐構造描画データ２０２に変換する。したがって、情報検索支援装置１０４は、分岐構造変換装置ということもできる。
【００１８】
情報検索支援装置１０４の実装形態は、ＡＳＰサービスに限定されない。
図１（ｂ）は、図１（ａ）とは異なる形態の、情報検索支援装置１０４を有するネットワークシステムの概略図である。
情報検索支援装置１０４は、検索サーバ１０６側に実装されるプログラムであってもよい。この場合、検索サーバ１０６から直接グラフィックイメージの分岐構造描画データ２０２が端末１０１へ送信される。
図１（ｃ）は、図１（ａ）及び（ｂ）とは異なる形態の、情報検索支援装置１０４を有するネットワークシステムの概略図である。
また、情報検索支援装置１０４は、端末１０７にインストールされるプログラムであってもよい。情報検索支援装置１０４を端末１０７に実装する形態としては、例えば、ｗｅｂブラウザのプラグインとして実装されるケースや、ローカル限定の極小規模のプロキシサーバとして実装されるケース等、様々な実装方法が考えられる。
【００１９】
［情報検索支援装置１０４：機能構成］
図３は、情報検索支援装置１０４の機能ブロック図である。
図４は、各テーブルの関係と、各テーブルのフィールド構成を示す図である。
キーワード抽出部３０１は、検索サーバ１０３から得た検索結果データ２０１から、検索結果データ２０１中に存在する全ての検索キーワードを抜き出し、重複を除去して、キーワードリスト３０２を生成する。
キーワードリスト３０２は、キーワードフィールドのみを有するテーブルである。
一方、コンテキスト生成部３０３は、検索結果データ２０１とキーワードリスト３０２から、ＵＲＬと検索キーワードの列の組よりなる検索結果テーブル３０４を生成する。
検索結果テーブル３０４は、ＵＲＬフィールドと、キーワード列フィールドよりなる。
【００２０】
概念生成部３０５は、キーワードリスト３０２と検索結果テーブル３０４から、一旦、キーワード対検索結果テーブル３０６を作成する。そして、キーワード対検索結果テーブル３０６と検索結果テーブル３０４から、概念テーブル３０７を生成する。
キーワード対検索結果テーブル３０６は、キーワードフィールドと、ＵＲＬ列フィールドよりなる。
概念テーブル３０７は、キーワードフィールドと、ＵＲＬ列フィールドと、キーワード列フィールドと、上下関係列フィールドと、ノード列フィールドよりなる。
概念生成部３０５は、概念テーブル３０７にレコードを生成し、生成したレコードのキーワードフィールドと、ＵＲＬ列フィールドと、キーワード列フィールドに情報を格納する。
概念生成部３０５が概念テーブル３０７を生成した後、分岐構造生成部３０８は概念テーブル３０７の上下関係列フィールドとノード列フィールドに情報を格納する。
最後に、描画処理部３０９は概念テーブル３０７のＵＲＬ列フィールドと、キーワード列フィールドと、ノード列フィールドと、描画用定数３１０を読み込み、分岐構造描画データ２０２を作成する。
【００２１】
描画処理部３０９は周知の物理演算エンジンを含んでおり、概念テーブル３０７からノードとエッジのデータを読み込ませ、描画用定数３１０を与えると、仮想空間上に所定の物理的アニメーションを実行する。本実施形態の描画処理部３０９は、仮想平面上にノードとエッジを描画する。そして、仮想平面に全てのノードに対する摩擦係数を与え、全てのノードに他のノードに対する斥力を与え、全てのエッジに等しいばね定数を与え、最上位の概念であるノードを仮想平面上の中心に固定し、その他のノードは一定の範囲内にランダムに配置する。
以上の動作条件で物理演算を実行すると、最初はバラバラに配置されていたノードがエッジに作用しているばね定数によって、本来の位置へ戻ろうとする。そして、その動作は仮想平面に与えられている摩擦係数によって減衰振動を起こし、最終的には仮想平面上の所定の範囲に、最上位の概念であるノードを中心に、ノード同士がエッジによって結ばれて分散された配置になる。
描画処理部３０９は、上述の物理的アニメーションを端末１０１の図示しないｗｅｂブラウザで実行するための分岐構造描画データ２０２を作成する。具体的には、例えば物理演算エンジンを実装したＪａｖａＳｃｒｉｐｔ（登録商標）のプログラムソースと、概念テーブル３０７から生成した描画用データ、そして描画用定数３１０を含むｈｔｍｌ文書である。
【００２２】
改めて図４を参照して、各テーブルのフィールド構成を説明する。
検索結果テーブル３０４は、ＵＲＬフィールドと、キーワード列フィールドよりなる。
ＵＲＬフィールドには、検索結果として現れるｗｅｂサイトのＵＲＬが格納される。ＵＲＬとは周知の Uniform Resource Locator である。
キーワード列フィールドには、検索結果として現れるｗｅｂサイトのＵＲＬに対応する検索キーワードが一つ以上格納される。これ以降、「列フィールド」と記述しているフィールドは、複数の値を格納し得るフィールドであることを示す。
つまり、検索結果テーブル３０４は、各レコードにおいてＵＲＬと検索キーワードが一対多の関係で格納されている。
但し、後述するが実際のＵＲＬと検索キーワードは多対多の関係である。
【００２３】
キーワードリスト３０２は、キーワードフィールドのみを有するテーブルである。
つまり、検索結果テーブル３０４の全レコードのキーワード列フィールドに存在する全ての検索キーワードを抜き出して、重複を除去しても、キーワードリスト３０２ができる。したがって、キーワード抽出部３０１は必ずしも検索結果データ２０１から生成しなくてもよい。どちらを採用するかは設計事項である。
【００２４】
キーワード対検索結果テーブル３０６は、キーワードフィールドと、ＵＲＬ列フィールドよりなる。
キーワードフィールドは、キーワードリスト３０２のキーワードフィールドと等しい。
ＵＲＬ列フィールドには、検索キーワードに対応するＵＲＬが一つ以上格納される。
つまり、キーワード対検索結果テーブル３０６は、各レコードにおいて検索キーワードとＵＲＬが一対多の関係で格納されている。
したがって、検索結果テーブル３０４とキーワード対検索結果テーブル３０６の存在から明らかなように、ＵＲＬと検索キーワードは多対多の関係である。
【００２５】
概念テーブル３０７は、キーワードフィールドと、ＵＲＬ列フィールドと、キーワード列フィールドと、上下関係列フィールドと、ノード列フィールドよりなる。
キーワードフィールドは、キーワードリスト３０２及びキーワード対検索結果テーブル３０６のキーワードフィールドと等しい。
ＵＲＬ列フィールドは、キーワード対検索結果テーブル３０６のＵＲＬ列フィールドと等しい。
キーワード列フィールドは、一見すると検索結果テーブル３０４のキーワード列フィールドと同じように見えるが、後述する処理によって異なる内容が格納される。
上下関係列フィールドには、各レコードのＵＲＬ列フィールドとキーワード列フィールドの内容を比較することによって判定した上下関係が、一つ以上格納される。
ノード列フィールドには、上下関係列フィールドと同様の上下関係が、一つ以上格納される。
なお、本来なら上下関係列フィールドは不要であるが、本実施形態の理解を容易にするために敢えて設けている。
【００２６】
実際のＵＲＬ及び検索キーワードは文字列であるが、文字列同士の比較は演算ステップ数が増えて時間が掛かるので、本実施形態の情報検索支援装置１０４は、一旦ＵＲＬや検索キーワードを番号に置換する。説明のため、これ以降、図４に示すようにＵＲＬについては「ＵＲＬ１、ＵＲＬ２、ＵＲＬ３…」と、「ＵＲＬ」に番号を付して表記し、検索キーワードについては「ＫＷ１、ＫＷ２、ＫＷ３…」と、「ＫＷ」に番号を付して表記する。
【００２７】
上下関係列フィールド及びノード列フィールドに格納される上下関係は［１，２］というように、概念テーブル３０７のレコード番号が記入される。左側の項目が上位概念に、右側の項目が下位概念に相当する。
【００２８】
［動作］
図５、図６及び図７は、概念生成部３０５が実行する概念生成処理の動作の流れを示すフローチャートである。
処理を開始すると（Ｓ５０１）、概念生成部３０５は最初にキーワードリスト３０２から各レコードの検索キーワードを用いて検索結果テーブル３０４を検索し、キーワード対検索結果テーブル３０６を作成する（Ｓ５０２）。
次に、概念生成部３０５はキーワード対検索結果テーブル３０６のＵＲＬ列フィールドに格納されているＵＲＬの数をレコード毎に数えて、そのＵＲＬの数でキーワード対検索結果テーブル３０６をソートする（Ｓ５０３）。この結果、キーワード対検索結果テーブル３０６の第一レコードは、ＵＲＬ列フィールドに格納されているＵＲＬの数が最大である。
【００２９】
次に、概念生成部３０５は概念テーブル３０７に第一レコードを追記する。具体的には、先ずステップＳ５０３でＵＲＬの数の多い順にソートしたキーワード対検索結果テーブル３０６の、最初のレコードのＵＲＬ列フィールドに含まれている、ＵＲＬの数を見る。この、一つの検索キーワードが関係するＵＲＬの最大数（最大要素数）が、検索結果テーブル３０４のレコード数、つまりＵＲＬの全数と等しいか否かを確認する（Ｓ５０４）。
もし、ＵＲＬの全数が、一つのキーワードが関係するＵＲＬの最大要素数よりも多いなら（Ｓ５０４のＹＥＳ）、概念テーブル３０７のキーワードフィールドに「φ（空集合）」、ＵＲＬ列フィールドに検索結果テーブル３０４に含まれる全てのＵＲＬよりなるＵＲＬ列を記述したレコードを追記して（Ｓ５０５）、カウンタ変数ｉを「１」に設定する（Ｓ５０６）。
もし、ＵＲＬの全数が、一つのキーワードが関係するＵＲＬの最大要素数と等しいなら（Ｓ５０４のＮＯ）、概念テーブル３０７のキーワードフィールドには該当するキーワードを、ＵＲＬ列フィールドに検索結果テーブル３０４に含まれる全てのＵＲＬよりなるＵＲＬ列を記述したレコードを追記して（Ｓ５０７）、カウンタ変数ｉを「２」に設定する（Ｓ５０８）。
次に、カウンタ変数ｊを「１」に設定する（Ｓ５０９）。
【００３０】
図６を参照してフローチャートの説明を続ける。
ここからループ処理である。
次に、概念生成部３０５はキーワード対検索結果テーブル３０６のｉ番目のレコードのＵＲＬ列フィールドを見る。このＵＲＬ列フィールドに格納されているＵＲＬ列と同じＵＲＬ列が、概念テーブル３０７の全レコードのＵＲＬ列フィールドに存在するか、探索する（Ｓ６１０）。
もし、同じＵＲＬ列が概念テーブル３０７中に存在しないのなら（Ｓ６１１のＹＥＳ）、
・概念テーブル３０７のキーワードフィールドに、キーワード対検索結果テーブル３０６のｉ番目のレコードのキーワードフィールドの検索キーワードを、
・概念テーブル３０７のＵＲＬ列フィールドに、キーワード対検索結果テーブル３０６のｉ番目のレコードのＵＲＬ列フィールドのＵＲＬ列を
追記する（Ｓ６１２）。
もし、同じＵＲＬ列が概念テーブル３０７中に存在するのなら（Ｓ６１１のＮＯ）、追記はしない。
【００３１】
次に、概念生成部３０５はキーワード対検索結果テーブル３０６のｉ番目のレコードのＵＲＬ列フィールドに格納されているＵＲＬ列と、概念テーブル３０７のｊ番目のレコードのＵＲＬ列フィールドのＵＲＬ列との積集合を導き出す（Ｓ６１３）。
もし、積集合と同じＵＲＬ列が概念テーブル３０７中に存在しないのなら（Ｓ６１４のＹＥＳ）、
・概念テーブル３０７のキーワードフィールドに、キーワード対検索結果テーブル３０６のｉ番目のレコードのキーワードフィールドのキーワードを、
・概念テーブル３０７のＵＲＬ列フィールドに、ステップＳ６１３にて導出した積集合を
追記する（Ｓ６１５）。
もし、積集合と同じＵＲＬ列が概念テーブル３０７中に存在するのなら（Ｓ６１４のＮＯ）、概念生成部３０５は追記をしない。そして、カウンタ変数ｊを１インクリメントする（Ｓ６１６）。
なお、図６のステップＳ６１６にある表記の「ｊ＋＋」の「＋＋」は、変数を１インクリメントする、という意味である。
【００３２】
図７を参照してフローチャートの説明を続ける。
次に、概念生成部３０５はカウンタ変数ｊが概念テーブル３０７のレコード数を超えたか否かを確認する（Ｓ７１７）。超えていなければ（Ｓ７１７のＮＯ）、概念生成部３０５は再びステップＳ６１３から処理を繰り返す。
つまり、概念テーブル３０７のレコード毎に積集合を導出して（Ｓ６１３）、その積集合が概念テーブル３０７に存在しなければ（Ｓ６１４のＹＥＳ）、概念テーブル３０７に新規レコードとして追記する（Ｓ６１５）処理を繰り返す。
カウンタ変数ｊが概念テーブル３０７のレコード数を超えていれば（Ｓ７１７のＹＥＳ）、概念生成部３０５はカウンタ変数ｉを１インクリメントする（Ｓ７１８）。
【００３３】
次に、概念生成部３０５はカウンタ変数ｉがキーワード対検索結果テーブル３０６のレコード数を超えたか否かを確認する（Ｓ７１９）。超えていなければ（Ｓ７１９のＮＯ）、概念生成部３０５は再びステップＳ７０９から処理を繰り返す。
つまり、キーワード対検索結果テーブル３０６のレコード毎に、ステップＳ５０９からステップＳ７１８迄の、概念テーブル３０７にレコードを追記する処理を繰り返す。
【００３４】
カウンタ変数ｉがキーワード対検索結果テーブル３０６のレコード数を超えていれば（Ｓ７１９のＹＥＳ）、概念生成部３０５はここから新たなループ処理を実行する。
先ず、概念生成部３０５はカウンタ変数ｉを１に初期化する（Ｓ７２０）。そして、概念生成部３０５は概念テーブル３０７のｉ番目のレコードのＵＲＬ列フィールドのＵＲＬ列（外延）に対応するキーワード列（内包）を導出して、当該レコードのキーワード列フィールドに格納する（Ｓ７２１）。
次に、概念生成部３０５はカウンタ変数ｉを１インクリメントして（Ｓ７２２）、カウンタ変数ｉが概念テーブル３０７のレコード数を超えたか否かを確認する（Ｓ７２３）。
カウンタ変数ｉが概念テーブル３０７のレコード数を超えていなければ（Ｓ７２３のＮＯ）、概念生成部３０５はステップＳ７２１から処理を繰り返し、全ての概念テーブル３０７のレコードのキーワード列フィールドに導出したキーワード列を格納させて、処理を終了する（Ｓ７２４）。
【００３５】
外延とは、同じ属性集合を持つオブジェクト集合を指す。本実施形態の場合、検索キーワードが属性に該当し、ＵＲＬ列が外延に該当する。これが、概念テーブル３０７のＵＲＬ列フィールドである。
内包とは、外延内の要素が共通に持つ属性集合を指す。本実施形態の場合、ＵＲＬ列に含まれるＵＲＬが共通に持つ検索キーワードの全てが、内包に該当する。これが、概念テーブル３０７のキーワード列フィールドである。
そして、外延と内包の組を、概念と呼ぶ。本実施形態の場合、概念テーブル３０７のＵＲＬ列フィールドとキーワード列フィールドの組が概念に該当する。
【００３６】
図８、図９及び図１０は、分岐構造生成部３０８が実行する分岐構造生成処理の動作の流れを示すフローチャートである。
処理を開始すると（Ｓ８０１）、分岐構造生成部３０８は最初にカウンタ変数ｉを１に初期化し（Ｓ８０２）、カウンタ変数ｊを１に初期化する（Ｓ８０３）。
次に、分岐構造生成部３０８はカウンタ変数ｉとカウンタ変数ｊが等しいか否かを確認する（Ｓ８０４）。もし等しければ（Ｓ８０４のＹＥＳ）、カウンタ変数ｊを１インクリメントする（Ｓ８０５）。しかし、もし等しくなければ（Ｓ８０４のＮＯ）、カウンタ変数ｊを１インクリメントしない。つまり、ステップＳ８０４とＳ８０５は、カウンタ変数ｉとカウンタ変数ｊが重複しないための処理である。
【００３７】
次に、分岐構造生成部３０８は概念テーブル３０７のｉ番目のレコードとｊ番目のレコードの、ＵＲＬ列フィールドとキーワード列フィールドを比較して、上下関係があるか否かを検証する（Ｓ８０６）。もし上下関係があると判定できたなら（Ｓ８０６のＹＥＳ）、次に分岐構造生成部３０８はｊ番目のレコードのキーワード列フィールド（内包）がすべての検索キーワードを含むものであるか否か、すなわち最下位の概念であるか否かを確認する（Ｓ８０７）。もしキーワード列フィールドが全ての検索キーワードでなければ（Ｓ８０７のＮＯ）、分岐構造生成部３０８は概念テーブル３０７のｉ番目のレコードの上下関係列フィールドに「［ｉ，ｊ］」という上下関係を追記録する（Ｓ８０８）。
ステップＳ８０６で上下関係がないと判定された場合（Ｓ８０６のＮＯ）、またステップＳ８０７でキーワード列フィールドが全ての検索キーワードであった場合（Ｓ８０７のＹＥＳ）は、分岐構造生成部３０８はステップＳ８０８の追記録を実行しない。
【００３８】
図９を参照してフローチャートの説明を続ける。
次に、分岐構造生成部３０８はカウンタ変数ｊを１インクリメントする（Ｓ９０９）。そして、分岐構造生成部３０８はカウンタ変数ｊが概念テーブル３０７のレコード数を超えたか否かを確認する（Ｓ９１０）。
カウンタ変数ｊが概念テーブル３０７のレコード数を超えていなければ（Ｓ９１０のＮＯ）、分岐構造生成部３０８はステップＳ８０４から処理を繰り返し、ステップＳ８０６及びＳ８０７で上下関係があると判定されたら、概念テーブル３０７のｉ番目のレコードの上下関係列フィールドに上下関係を格納する。
【００３９】
ステップＳ９１０でカウンタ変数ｊが概念テーブル３０７のレコード数を超えたら（Ｓ９１０のＹＥＳ）、分岐構造生成部３０８はカウンタ変数ｉを１インクリメントする（Ｓ９１１）。そして、分岐構造生成部３０８はカウンタ変数ｉが概念テーブル３０７のレコード数を超えたか否かを確認する（Ｓ９１２）。
カウンタ変数ｉが概念テーブル３０７のレコード数を超えていなければ（Ｓ９１２のＮＯ）、分岐構造生成部３０８はステップＳ８０３に戻り、概念テーブル３０７の全てのレコードについて、ステップＳ８０４からステップＳ９１１迄の処理を繰り返す。
【００４０】
ステップＳ９１２において、カウンタ変数ｉが概念テーブル３０７のレコード数を超えると（Ｓ９１２のＹＥＳ）、ステップＳ８０３から始まるループ処理を抜ける。
以上の説明で判るように、ステップＳ８０２からステップＳ９１２迄の処理は、概念テーブル３０７の上下関係列フィールドに上下関係を記入する処理である。この一連の処理は上下関係生成処理ともいえる。
【００４１】
上下関係生成処理が完了したら、次に概念テーブル３０７のノード列フィールドに線を結ぶべき上下関係、つまりノードを記入する処理を行う。
先ず、分岐構造生成部３０８は概念テーブル３０７の全レコードの上下関係列フィールドの内容を全てノード列フィールドに複写する（Ｓ９１３）。
次に、分岐構造生成部３０８はカウンタ変数ｉを１に初期化し（Ｓ９１４）、カウンタ変数ｊを１に初期化し（Ｓ９１５）、カウンタ変数ｋにｊ＋１を代入する（Ｓ９１６）。
【００４２】
図１０を参照してフローチャートの説明を続ける。
次に、分岐構造生成部３０８は、概念テーブル３０７のｉ番目のレコードのノード列フィールドを注目する。概念テーブル３０７のｉ番目のレコードのノード列フィールドに格納されている上下関係の、ｊ番目とｋ番目の上下関係を見る。
分岐構造生成部３０８は、ｊ番目上下関係の下位概念に該当する、概念テーブル３０７のレコード番号のＵＲＬ列フィールドとキーワード列フィールドの組（概念）と、ｋ番目上下関係の下位概念に該当する、概念テーブル３０７のレコード番号のＵＲＬ列フィールドとキーワード列フィールドの組（概念）との間に上下関係があるか否か、調べる（Ｓ１０１７）。
【００４３】
もし、ｊ番目上下関係の下位概念と、ｋ番目上下関係の下位概念との間に上下関係があるのならば（Ｓ１０１７のＹＥＳ）、分岐構造生成部３０８は更に、ｊ番目上下関係の下位概念と、ｋ番目上下関係の下位概念のどちらが上位概念なのかを確認する（Ｓ１０１８）。
ｊ番目上下関係の下位概念が上位概念であるならば（Ｓ１０１８のＹＥＳ）、ｊ番目上下関係の下位概念と、ｋ番目上下関係の下位概念との間には［ｊ，ｋ］という上下関係が存在する。この上下関係はｊ番目のレコードのノード列フィールドに存在する。そこで、ｊ番目のレコードのノード列フィールドから、この［ｊ，ｋ］という上下関係を削除する（Ｓ１０１９）。
ｋ番目上下関係の下位概念が上位概念であるならば（Ｓ１０１８のＮＯ）、ｊ番目上下関係の下位概念と、ｋ番目上下関係の下位概念との間には［ｋ，ｊ］という上下関係が存在する。この上下関係はｋ番目のレコードのノード列フィールドに存在する。そこで、ｋ番目のレコードのノード列フィールドから、この［ｋ，ｊ］という上下関係を削除する（Ｓ１０２０）。
なお、ステップＳ１０１７で、ｊ番目上下関係の下位概念と、ｋ番目上下関係の下位概念との間に上下関係がないのならば（Ｓ１０１７のＮＯ）、分岐構造生成部３０８は上下関係の削除を行わない。
【００４４】
ステップＳ１０１９及びＳ１０２０、及びステップＳ１０１７の判定結果がＮＯの場合に、分岐構造生成部３０８はカウンタ変数ｋを１インクリメントする（Ｓ１０２１）。そして、分岐構造生成部３０８はカウンタ変数ｋがｉ番目レコードのノード列フィールドに含まれている上下関係の最大要素数を超えたか否かを確認する（Ｓ１０２２）。カウンタ変数ｋが最大要素数を超えていなければ（Ｓ１０２２のＮＯ）、分岐構造生成部３０８は再びステップＳ１０１７に戻って、上下関係の有無を判定して（Ｓ１０１７）必要に応じて上下関係を削除する（Ｓ１０１９及びＳ１０２０）処理を繰り返す。
【００４５】
ステップＳ１０２２において、カウンタ変数ｋがｉ番目レコードのノード列フィールドに含まれている上下関係の最大要素数を超えていれば（Ｓ１０２２のＹＥＳ）、分岐構造生成部３０８は次にカウンタ変数ｊを１インクリメントして（Ｓ１０２３）、カウンタ変数ｊがｉ番目レコードのノード列フィールドに含まれている上下関係の最大要素数を超えたか否かを確認する（Ｓ１０２４）。カウンタ変数ｊが最大要素数を超えていなければ（Ｓ１０２４のＮＯ）、分岐構造生成部３０８は再びステップＳ９１６に戻って、カウンタ変数ｋにｊ＋１を代入した（Ｓ９１６）後、上下関係の有無を判定して（Ｓ１０１７）必要に応じて上下関係を削除する（Ｓ１０１９及びＳ１０２０）処理を繰り返す。
【００４６】
ステップＳ１０２４において、カウンタ変数ｊがｉ番目レコードのノード列フィールドに含まれている上下関係の最大要素数を超えていれば（Ｓ１０２４のＹＥＳ）、この時点でｉ番目レコードのノード列フィールドに対する上下関係検証処理（Ｓ１０１７）は終了している。そこで、分岐構造生成部３０８は次にカウンタ変数ｉを１インクリメントして（Ｓ１０２５）、カウンタ変数ｉが概念テーブル３０７の最大レコード数を超えたか否かを確認する（Ｓ１０２６）。カウンタ変数ｊが最大レコード数を超えていなければ（Ｓ１０２６のＮＯ）、分岐構造生成部３０８は再びステップＳ９１５に戻って、カウンタ変数ｊを１に初期化した（Ｓ９１５）後、ｉ番目のレコードのノード列フィールドに対し、上下関係の有無を判定して（Ｓ１０１７）必要に応じて上下関係を削除する（Ｓ１０１９及びＳ１０２０）処理を繰り返す。
ステップＳ１０２６において、カウンタ変数ｉが概念テーブル３０７の最大レコード数を超えていれば（Ｓ１０２６のＹＥＳ）、分岐構造生成部３０８は一連の処理を終了する（Ｓ１０２７）。
【００４７】
［原理］
先ず、本実施形態の情報検索支援装置１０４が取り扱う概念について説明する。
先に説明したように、外延とは、同じ属性集合を持つオブジェクト集合を指す。また、内包とは、外延内の要素が共通に持つ属性集合を指す。
外延と内包の組は、概念と定義される。この概念の定義に沿って検索サイトの検索結果を考えると、検索結果としてヒットしたＵＲＬは、共通する検索キーワードでグルーピングすることができる。「共通する検索キーワード」は一つだけではなく、複数のＵＲＬが複数のキーワードを共有することもある。こうして、共通の検索キーワードを有するＵＲＬの集合を、一つの概念と定義する。この概念が、概念テーブル３０７のＵＲＬ列フィールドとキーワード列フィールドの組に該当する。
概念生成部３０５は、この概念の生成を図５、図６及び図７のフローチャートに従って実行する。
【００４８】
以下に、概念の一例を示す。
今、以下の表１のような検索結果が得られたとする。
【００４９】
【表１】
0005831873.tif 000002
【００５０】
上記表１において、ＫＷａ、ＫＷｂ及びＫＷｃは検索キーワードであり、ＵＲＬ１、ＵＲＬ２、ＵＲＬ３及びＵＲＬ４はＵＲＬである。
ＵＲＬ１はＫＷａを含む。
ＵＲＬ２はＫＷｂとＫＷｃを含む。
ＵＲＬ３はＫＷａとＫＷｃを含む。
ＵＲＬ４はＫＷｃを含む。
概念生成部３０５は、図５、図６及び図７のフローチャートに示す処理を実行することで、表１から以下の表２に示す概念を導出する。
【００５１】
【表２】
0005831873.tif 000003
【００５２】
次に、概念の上下関係について説明する。
今、二つの概念を（Ａ１，Ｂ１）、（Ａ２，Ｂ２）とすると
【００５３】
【数１】
0005831873.tif 000004
【００５４】
という関係が成り立つ。但し、Ａ１とＡ２は外延であり、Ｂ１とＢ２は内包である。
つまり、（Ａ１，Ｂ１）の外延であるＡ１が（Ａ２，Ｂ２）の外延であるＢ２に含まれ、かつ（Ａ１，Ｂ１）の内包であるＢ１が（Ａ２、Ｂ２）の内包であるＢ２を含むとき、（Ａ１，Ｂ１）は（Ａ２，Ｂ２）の下位概念となる。
分岐構造生成部３０８は、この概念の上下関係の判定を、図８のステップＳ８０６及び図１０のステップＳ１０１７で実行する。
【００５５】
次に、エッジについて説明する。
上下関係を有する概念が三つ以上存在すると、そこには様々な上下関係が成立する。これら概念（ノード）の上下関係について全て線（エッジ）を引いてグラフィック画面に表示すると、概念の関係が極めて見難くなってしまう。そこで、不必要な上下関係を示す線は削除する。
今、（Ａ１，Ｂ１）、（Ａ２，Ｂ２）、（Ａ３，Ｂ３）という三つの概念が存在しているとする。
【００５６】
【数２】
0005831873.tif 000005
【００５７】
つまり、ノード同士をエッジで結線する際の基本的なルールとして、上位概念から下位概念へはその順序どおりにエッジで結線し、途中に存在する概念を飛ばしたエッジは削除する。
分岐構造生成部３０８は、このエッジの判定と削除を、図１０のステップＳ１０１７で実行する。
【００５８】
次に、本実施形態の情報検索支援装置１０４における、ノードとエッジを描画する際の工夫について説明する。
図１１（ａ）は描画処理の工夫を施す前の画面表示例であり、図１１（ｂ）は描画処理の工夫を施した後の画面表示例である。
概念生成処理は、内包、つまりキーワード列が全ての検索キーワードを含む概念も生成する。もし、キーワード列が全ての検索キーワードを含む概念も含めて端末１０１の画面に表示しようとすると、図１１（ａ）に示すような形状の図が出来上がる。
図１１（ａ）中、（φ，｛○×，大学，キャンパス，案内，研究｝）というノードは、ＵＲＬ列がφであり、このノードをマウス等のポインティングデバイスでクリックしても、検索結果が出力されない。つまり、意味のないノードである。この、意味のないノードが存在するために、このノードに対して直近の上下関係を有する（｛１｝，｛○×，大学｝）、（｛２｝，｛○×，キャンパス｝）、（｛３｝，｛○×，案内｝）及び（｛４｝，｛案内，研究｝）というノードは、画面内の配置の制約を受けてしまう。つまり、意味のないノードの存在によって、意味のあるノードの位置が引っ張られてしまう。
【００５９】
そこで、本実施形態の情報検索支援装置１０４は、この意味のないノードを端末１０１の画面に描画しないこととした。その結果、図１１（ｂ）のようになり、意味のないノードを描画しなくなった分だけ画面の面積が有効に活用されることが判る。この、描画を止める処理は、図８のステップＳ８０７が該当する。つまり、エッジの基となる上下関係を上下関係列フィールドに記述する際、下位概念として評価しようとする対象が最下位概念（内包の要素が全キーワード）である場合は、上下関係列フィールドに記入しない（Ｓ８０７のＮＯ）。
【００６０】
なお、描画を止める処理は、分岐構造生成部３０８の上下関係生成処理に限られない。概念生成部３０５の概念生成処理で行ってもよいし、描画処理部３０９の中で実行してもよい。このような例外処理を最も容易に実装し易い手法は、分岐構造生成部３０８の上下関係生成処理であろう。
【００６１】
以上の説明で判るように、描画の対象は概念テーブル３０７のＵＲＬ列フィールドと、キーワード列フィールドと、ノード列フィールドである。上下関係列フィールドは、ノード列フィールドを作成するための中間データであり、なくてもよい。つまり、図８のステップＳ８０８はノード列フィールドに上下関係を追記する処理にすれば、図９のステップＳ９１３はなくてもよい。
【００６２】
［画面表示の例］
図１２（ａ）及び（ｂ）、そして図１３（ｃ）は、本実施形態の情報検索支援装置１０４によって生成される表示画面の例である。但し、図１２（ａ）及び（ｂ）、そして図１３（ｃ）は、説明の便宜のためにＵＲＬ列、つまり外延を表示しているが、実際の画面は外延を表示せず、キーワード列、つまり内包のみ表示する。
図１２（ａ）及び（ｂ）、そして図１３は、全て同一の検索結果から作成した表示画面である。最上位の概念のノードは（｛１，２，３，４，５｝，φ）であり、その次に続く下位概念である（｛２，３，４，５｝，｛研究｝）と（｛１｝，｛電子，サービス，公式，紹介，教育｝）の配置とノード間距離はあまり変わらないが、これらの他のノードは常に配置が変化している。これは、乱数によってノードの初期位置を決定していることに起因する。また、各々のノードの配置も必ず固定されている訳ではなく、毎回微妙にずれている。これは、乱数の影響の他、仮想平面上の摩擦係数にも起因する。
そして、最下位概念のノードが描画されず、また最下位概念のノードによって直近の上下関係にあるノードが引っ張られない。このため、末端に位置するノードが全て画面の周縁側に配置されるので、ノード同士の距離が適切に離れ、画面の利用効率が向上し、ノードの視認性が極めて良くなる。
なお、図１２（ａ）、（ｂ）及び（ｃ）を見て判るように、本実施形態の情報検索支援装置１０４は、最上位の概念のノードがどこに存在するのかをわかりやすく示すために、再上位概念を中心とする同心円を表示している。
【００６３】
本実施形態は、以下のような応用例が考えられる。
（１）画面に表示するノードの数が多すぎる場合は、検索キーワードの数、つまり内包の要素数で画面に表示するノードを限定させることも可能である。地図アプリケーションのような縮尺ゲージを画面の隅に表示して、ゲージをマウス等のポインティングデバイスで操作し、検索キーワードの数で絞り込む。表示しないノードは透明にしてぼかすように描画すると、より視認性が向上することが期待できる。また、内包の要素数に応じてノードを色分けさせてもよい。
【００６４】
（２）また、画面に表示するノードの数が多すぎる場合に、ある特定のノードを最上位の概念として再描画させることも可能である。この場合、既に作成したノード列フィールドのデータを再利用するだけでよい。
【００６５】
（３）また、画面に表示するノードとして現れる検索結果が、ユーザにとって満足の行く内容でなかった場合に、最上位のノードに含まれる検索キーワードを間引いて再検索し、再描画させることも可能である。
【００６６】
（４）検索結果データ２０１は、インターネットのｗｅｂサイトを対象とする検索エンジンが出力するものに限られない。書籍や学術文献、或は特許公報等の文書を対象とする検索エンジンにも、本実施形態の情報検索支援装置は利用可能である。この場合、ＵＲＬの代わりに文書を示す情報が用いられる。書籍の場合はＩＳＢＮ（International Standard Book Number）が、特許公報の場合は公開特許番号等が、文書を示す情報として利用可能である。
したがって、ＵＲＬやＩＳＢＮ、公開特許番号等の情報は「文書情報」と言い換えることもできる。
【００６７】
本実施形態においては、情報検索支援装置１０４を開示した。
検索サイトから得られる検索結果からＵＲＬと検索キーワードを抜粋して、夫々の対応関係から外延と内包よりなる概念を生成する。概念をノードとして、ノード同士の上下関係を導出し、直近の上下関係のみエッジとして描画する対象として残す。その際、外延が空集合である概念は描画対象から外す。
こうすることにより、不必要なノードが描画されず、また不必要なノードによって最下位のノードが引っ張られない。このため、最下位概念の直近のノードが全て画面の周縁側に配置されるので、ノード同士の距離が適切に離れ、画面の利用効率が向上し、ノードの視認性が極めて良くなる。
【００６８】
以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
【符号の説明】
【００６９】
１０１…端末、１０２…変換サーバ、１０３…検索サーバ、１０４…情報検索支援装置、１０５…表示部、１０６…検索サーバ、１０７…端末、２０１…検索結果データ、２０２…分岐構造描画データ、３０１…キーワード抽出部、３０２…キーワードリスト、３０３…コンテキスト生成部、３０４…検索結果テーブル、３０５…概念生成部、３０６…キーワード対検索結果テーブル、３０７…概念テーブル、３０８…分岐構造生成部、３０９…描画処理部、３１０…描画用定数
【図１】
0005831873.tif 000006
【図２】
0005831873.tif 000007
【図３】
0005831873.tif 000008
【図４】
0005831873.tif 000009
【図５】
0005831873.tif 000010
【図６】
0005831873.tif 000011
【図７】
0005831873.tif 000012
【図８】
0005831873.tif 000013
【図９】
0005831873.tif 000014
【図１０】
0005831873.tif 000015
【図１１】
0005831873.tif 000016
【図１２】
0005831873.tif 000017
【図１３】
0005831873.tif 000018