検索システム及び検索プログラム
【課題】ユーザの発言からユーザの意図を正確に解析し、ユーザの意図や状況に応じて、検索に必要な条件や選択基準を動的に切り替えることができるようにする。
【解決手段】本発明の検索システムは、対象データを格納する対象データ格納手段と、条件の組み合わせという次元によって重みの異なる次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、条件なしの時の重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、次元別優先度格納手段とを備え、検索する値が条件として設定されると、次元別マッチングテーブル格納手段から条件に合う各次元別マッチングテーブルを取り出し、次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして多次元マッチングテーブルを生成し、この多次元マッチングテーブルを用いてマッチングする。
【解決手段】本発明の検索システムは、対象データを格納する対象データ格納手段と、条件の組み合わせという次元によって重みの異なる次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、条件なしの時の重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、次元別優先度格納手段とを備え、検索する値が条件として設定されると、次元別マッチングテーブル格納手段から条件に合う各次元別マッチングテーブルを取り出し、次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして多次元マッチングテーブルを生成し、この多次元マッチングテーブルを用いてマッチングする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索システム及び検索プログラムに関し、例えば、対話の中で徐々に掘り下げた質問を繰り返すことにより、利用者のニーズや価値観を引き出し、多種多様でかつ大量のサービスやコンテンツの中から、利用者のニーズや価値観にマッチするものを検索する情報検索システムに適用し得るものである。
【背景技術】
【０００２】
ＩＴ（情報技術）を通じたコミュニケーションは、将来、テキスト情報から、個人の記憶する動画像や会話、放送映像や映画映像、商品情報やセンサー情報、生産履歴や交通履歴、刻一刻と変化する地理・気候情報等の様々な情報媒体に対象を広げ、その利用局面も、情報家電、車載端末、電子タグや、公共交通機関、企業の生産・流通現場、市場の店頭等の様々な局面へとダイナミック拡大していくことが予想される。
【０００３】
その契機となるのは、現在のパソコンによるホームページの中だけのテキスト中心の情報検索ではない、個人の生活、ビジネス等のあらゆる局面での新たなコミュニケーションニーズに応える次世代の情報検索・解析技術である。
【０００４】
従来の情報検索・解析技術は、キーワードの入力を受け付け、ネットワーク上の情報から入力キーワードと一致する情報を検索し、ヒット件数が多い順から紹介するというのが一般的である。この他にも、入力キーワードと一緒に使われるキーワードも表示するキーワード自動拡張技術や、多くのユーザによる口コミ情報から商品等をレコメンドする技術等もある。
【０００５】
しかしながら、上記のような技術によれば、当該利用者は入力キーワードを含む多くの情報を検索することができるが、これらの情報は、多くの他ユーザにより検索された結果を統計的にまとめた情報であって、当該利用者の真のニーズや希望する個別化された情報ではない。
【０００６】
また、情報過多の時代において、情報量の爆発的な増加に対応しきれず、情報選択基準を見失い易くなっている人が増えているという現状がある。自らの欲する情報や行動を決めきれないという問題を抱えるユーザに対して、単なる検索だけではなく、検索に至るまでの考え方をシステムが一緒に探るという情報検索・解析技術が求められている。
【０００７】
これに対して、本願発明者は、対話の中で、徐々に掘り下げた質問を繰り返すことにより、利用者のニーズや価値観を引き出すラダリング手法を活用し、利用者とシステムとが対話を繰り返すことにより、利用者が自ら表現することが困難であったサービスやコンテンツに関するニーズを引き出し、多種多様でかつ大量のサービスやコンテンツの中からこれにマッチングするものを検索する情報検索・解析技術を提案する（特願２００８−０３６３４２、特願２００８−０３６３５６）。
【０００８】
この対話型検索システムでは、ドメイン知識に基づいて質問文を生成して利用者に提示し、利用者からの回答を意図解析によって意味レベルで解釈し、その利用者から引き出した情報及び予め検索対象解析（例えば、利用者の回答から解釈したいと解析結果）と、検索対象データを解析した結果とマッチングすることにより検索を実現している。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】溝口理一郎他２名，「オントロジー工学基礎論−意味リンク、クラス、関係、ロールのオントロジー的意味論−」，人工知能学会誌，Ｖｏｌ．１４，ｐｐ．１０１９−１０３２，１９９９年
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ところで、対話型検索システムにおいて、徐々に掘り下げた質問を繰り返して利用者の真のニーズや希望を引き出すためには、（１）意思決定プロセスを支援すること、（２）ユーザ本人だけでは言語化しきれていない「気付き」の促し、（３）情報の選択基準を正確に認識することが重要となる。
【００１１】
つまり、対話型検索システムでは、利用者一人一人に応じたパーソナライズが動的に行われることや、利用者の発言に対して、寄り添い感を与える応答や対話の流れや、様々な状況変化に応じて質問すべき事柄の重要度は刻々と変化するから、これに応じて、質問文を提示することやマッチングを行うことが求められる。
【００１２】
非特許文献１には、オントロジーの意義に関して記載されている。オントロジーとは、特定の領域についての知識、複数の領域にまたがる知識、あるいは、汎用の知識を定義し、体系化したものである。ここで、知識とは、用語・語彙とその意味、他の用語・語彙との関係を示し、領域とは、医学、工学、不動産、自動車、金融などの分野を指す。
【００１３】
オントロジーは、語の概念や、語と語の関係を体系的に表現することができるので、対話型検索システムにおいては、ドメイン毎にオントロジーで記述したものを、ドメイン知識として利用することが考えられる。
【００１４】
これにより、オントロジーを利用した質問文を提示することができ、またこの質問文に対する回答を関連付けることができるので、利用者の回答（入力）を理解することができたり、それまでの対話のモデル化が簡易になる。
【００１５】
しかしながら、現行のオントロジーは、語の概念や語と語の関係を表す際、１つの観点からの語の概念や語と語の関係しか表現することができない。
【００１６】
そのため、情報の選択基準を正確に解析し、ユーザの意図や状況に応じて選択基準を切り替ていき、その切り替えた選択基準を使って正しく検索することができないという問題が生じ得る。
【００１７】
例えば、情報検索を行う者が人間であれば、ユーザからの情報を無視して、マッチングしない条件を提示することはない。例えば、求人側が求める資格・スキルに「Ｊａｖａ経験３年以上」というものがあるとする。この場合に、ユーザがプログラム言語「Ｊａｖａ」に関する保有資格を有していても、経験年数が３年以上の条件を満たしていなければ、その求人を提示することはない。
【００１８】
これは、人間が正しくユーザの意図を解析して、ユーザの意図や状況に応じて選択基準を切り替えているからである。しかし、従来の対話型検索システムは、ユーザの意図や状況に応じて動的に選択基準の切り替えることができない。
【００１９】
本発明は、上記課題に鑑みて、多次元オントロジーという考え方を利用する。ユーザの回答から対象データを検索する場合、ユーザの回答が対象データのどの検索キーに対応するか、また、その対応度の大小を記入するマッチングテーブルが必要となる。このマッチングテーブルは、語と語の関係を示すネットワークとして表現され、オントロジーで表現可能である。したがって、このマッチングテーブルをオントロジーとみなして、マッチングテーブルをユーザの意図や状況に応じて動的に切り替えることにより、ユーザの発言からユーザの意図を正確に解析し、ユーザの意図や状況に応じて、検索に必要な条件や選択基準を動的に切り替えることができる検索システム及び検索プログラムを提供する。
【課題を解決するための手段】
【００２０】
かかる課題を解決するために、第１の本発明の検索システムは、検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索システムにおいて、（１）検索対象とする１又は複数の対象データを格納する対象データ格納手段と、（２）条件の組み合わせという次元によって重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、（３）条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、（４）次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と、（５）検索する値が条件として設定されると、次元別マッチングテーブル格納手段から、条件に合う各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段と、（６）取り出された各次元別マッチングテーブルのうち、次元優先度格納手段の次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段と、（７）多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段とを備えることを特徴とする。
【００２１】
第２の本発明の検索プログラムは、検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索プログラムにおいて、（１）検索対象とする１又は複数の対象データを格納する対象データ格納手段と、（２）条件の組み合わせという次元によって重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、（３）条件なしの時の重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、（４）次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段とを備え、コンピュータを、（５）検索する値が条件として設定されると、次元別マッチングテーブル格納手段から、条件に合う各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段、（６）取り出された各次元別マッチングテーブルのうち、次元優先度格納手段の次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段、（７）多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段として機能させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、多次元オントロジーを利用することにより、ユーザの発言からユーザの意図を正確に解析し、ユーザの意図や状況に応じて、検索に必要な条件や選択基準を動的に切り替えることができる。
【図面の簡単な説明】
【００２３】
【図１】第１の実施形態の対話型検索システムの全体構成を示す全体構成図である。
【図２】多次元オントロジーの基本概念を説明する説明図である（その１）。
【図３】多次元オントロジーの基本概念を説明する説明図である（その２）。
【図４】第１の実施形態の対話制御システムの全体の流れを示すフローチャートである。
【図５】プロパティ定義（表形式）を説明する説明図である。
【図６】プロパティ定義（ネットワーク形式）を説明する説明図である。
【図７】第１の実施形態の多次元オントロジー作成処理を示すフローチャートである。
【図８】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図９】次元の優先度を示す次元リストを説明する説明図である。
【図１０】次元優先度定義テーブルを説明する説明図である。
【図１１】多次元オントロジーの生成処理を説明する説明図である。
【図１２】第１の実施形態の検索処理と連動した対話制御処理を示すフローチャートである。
【図１３】第１の実施形態の多次元オントロジーを利用したマッチング処理を示すフローチャートである。
【図１４】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図１５】ベース次元のマッチングテーブルを説明する説明図である。
【図１６】「／人間／パーソナリティ／現在の職種＝コック」次元のマッチングテーブルを説明する説明図である。
【図１７】多次元化したマッチングテーブルを説明する説明図である。
【図１８】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図１９】「／人間／パーソナリティ／現在の職種＝ＳＥ」次元のマッチングテーブルを説明する説明図である。
【図２０】多次元化したマッチングテーブルを説明する説明図である。
【図２１】マッチング処理に係る対象データ及び類似度を説明する説明図である。
【図２２】マッチング処理に係る対象データ及び類似度を説明する説明図である。
【図２３】第１の実施形態の多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係る意図解析部における処理を示すフローチャートである。
【図２４】第１の実施形態の多次元意図解析処理に係るドメイン知識管理部における処理を示すフローチャートである。
【図２５】多次元意図解析処理における意図解析結果を説明する説明図である。
【図２６】ドメイン知識辞書マネージャが取得したユーザデータを説明する説明図である。
【図２７】ドメイン知識辞書マネージャが多次元化したドメイン知識辞書を説明する説明図である。
【図２８】各次元のドメイン知識辞書を説明する説明図である。
【図２９】多次元意図解析処理による意図解析結果を説明する説明図である。
【図３０】第１の実施形態の多次元意図解析処理（解析対象文の動的切替処理）にいて、意図解析部が取得した対象データを説明する説明図である。
【図３１】ドメイン知識辞書マネージャが多次元化したドメイン知識辞書を説明する説明図である。
【図３２】各次元の多次元構文辞書を説明する説明図である。
【図３３】多次元意図解析処理による意図解析結果を説明する説明図である。
【図３４】第１の実施形態のマッチング結果と連動した対話制御処理での対話制御部の処理を示すフローチャートである。
【図３５】第１の実施形態のマッチング結果と連動した対話制御処理でのマッチング処理を示すフローチャートである。
【図３６】対話制御部が取得したユーザデータを説明する説明図である。
【図３７】マッチング部が取得した対象データを説明する説明図である。
【図３８】「／人間／現在の職種＝プログラマ」次元のマッチングテーブルを説明する説明図である。
【図３９】ユーザデータと対象データとのマッチングを説明する説明図である。
【図４０】対話制御部が取得したユーザデータを説明する説明図である。
【図４１】ユーザデータと対象データとのマッチングを説明する説明図である。
【発明を実施するための形態】
【００２４】
（Ａ）第１の実施形態
以下では、本発明の検索システム及び検索プログラムの第１の実施形態について図面を参照しながら詳細に説明する。
【００２５】
第１の実施形態では、ユーザに対して質問を繰り返してユーザの真のニーズや希望を引き出すラダリングを利用した対話型検索システムに本発明を適用した実施形態を例示して説明する。
【００２６】
（Ａ−１）多次元オントロジーの基本概念
第１の実施形態において利用するマッチングテーブルは、語と語の関係を表したネットワーク構造で表現することができるため、オントロジーとみなすことができる。したがって、第１の実施形態では、多次元オントロジーの概念をマッチングテーブルに応用する。
【００２７】
まず、この多次元オントロジーの概念を、図面を参照しながら説明する。
【００２８】
多次元オントロジーとは、多数の意味空間を多次元化して保持し、対話で得られるユーザのデータ又は対象データ／状況に応じて、使用する意味空間を瞬時に切り替えることができるオントロジーをいう。
【００２９】
上述したように、現行のオントロジーは、ある１つの観点からしか語の概念や語と語の関係を表現していないので、現行のオントロジーを対話型検索システムに利用しても、静的なデータしか得られない。
【００３０】
そこで、第１の実施形態では、オントロジーを多次元化して保持できるようし、さらにユーザから引き出した情報が変化するたびに次元間を自動的に移動する仕組みを提案する。
【００３１】
これにより、対話で得られるユーザデータや状況に応じて瞬時に、意味空間を切り替えたり、対話のための情報を切り替えることができ、対話や検索がもつダイナミック性をシステムとして実現できる。また、次元間でデータを継承できるようにすることで、記述性とその省力性（最小限の記述）を同時に実現した。多次元化の最大の特徴である記述したいところだけを詳細に記述することができる。
【００３２】
図２及び図３は、多次元オントロジーの基本概念を説明する説明図である。図２及び図３では、第１の実施形態の対話型検索・解析システム１を職業紹介システムに利用した場合を例示する。
【００３３】
図２及び図３に示すように、多次元オントロジーは、それぞれプロパティが設定されている次元が、優先度に従って位置づけされており、ベースの次元と、ベース以外の特別な次元（以下、サブ次元という）とを有して構成される。
【００３４】
ベースの次元及びサブ次元には、それぞれ様々なオントロジーが定義されている。ベースの次元とは、最も優先度が低い次元であり、サブ次元に定義される全てのクラス及びプロパティが定義されているものである。また、サブ次元は、それぞれ必要なクラス及びプロパティだけが定義されており、条件の数が多いものほど優先度が高くなる。なお、条件の数が同数の場合には、例えば、開発者により予め優先度付けしておく。
【００３５】
例えば、図２及び図３では、ベースの次元を含めて６次元オントロジーを例示する。「業種＝ＩＴ」のサブ次元、「職種＝営業」のサブ次元、「職種＝ＳＥ」のサブ次元はそれぞれ、条件が１個であり、条件数が同数であるが、「業種＝ＩＴ」のサブ次元、「職種＝営業」のサブ次元、「職種＝ＳＥ」のサブ次元の順に優先度を高く設定したものとする。
【００３６】
また「職種＝営業＆＆業種＝ＩＴ（この表記は「職種が営業であり、かつ、業種がＩＴである」ことを示す、以下同様である）」のサブ次元、「職種＝ＳＥ＆＆業種＝ＩＴ」サブ次元はそれぞれ条件が２個であり、条件数が同数であるが、「職種＝営業＆＆業種＝ＩＴ」のサブ次元、「職種＝ＳＥ＆＆業種＝ＩＴ」の順に優先度を高く設定したものとする。
【００３７】
従って、これらの次元を重ねると、「ベースの次元」は優先度が最も低いので、次元の優先度は、「ベースの次元」→「業種＝ＩＴ」のサブ次元→「職種＝営業」のサブ次元→「職種＝ＳＥ」のサブ次元→「職種＝営業＆＆業種」のサブ次元→「職種＝ＳＥ＆＆業種＝ＩＴ」サブ次元の順に高くなる。
【００３８】
また、図２及び図３において、各サブ次元上の丸は、各サブ次元で定義されているクラス及びプロパティを示す。
【００３９】
図２は、ユーザから「何も（データを）取得していない時」を示す。この場合、まだ対話が進行していない。このとき、ベース次元に定義されているクラス及びプロパティ（図２には図示しない）を用いて対話進行する。
【００４０】
対話が進行して、ユーザから「業種＝ＩＴ」とする条件を取得したとする。この場合、図３に示すように、適用される次元は「業種＝ＩＴ」のサブ次元となり、この「業種＝ＩＴ」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
【００４１】
さらに対話が進行して、ユーザから「職業＝営業かつ業種＝ＩＴ」とする条件を取得したとする。この場合、図３に示すように、適用される次元は「職種＝営業＆＆業種＝ＩＴ」のサブ次元となり、この「職種＝営業＆＆業種＝ＩＴ」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
【００４２】
ここで、対話に適用された次元は、「業種＝ＩＴ」と「職業＝営業かつ業種＝ＩＴ」の２個のサブ次元であり、適用された各サブ次元のクラス及びプロパティは、ベースの次元に上書きされて継承される。このとき、優先度の高いサブ次元のクラス及びプロパティが記憶されるように、優先度が低いサブ次元から順に継承される。つまり、ベースの次元には、「業種＝ＩＴ」のサブ次元のクラス及びプロパティが記憶されてから、「職業＝営業かつ業種＝ＩＴ」のサブ次元のクラス及びプロパティが上書きされる。
【００４３】
このように多次元オントロジーを用いることにより、次元間でデータを継承することができ、マッチングテーブルにおいても、対象データとユーザデータの対応関係や重要度などの値を次元間で継承することが可能となる。
【００４４】
（Ａ−２）第１の実施形態の構成
以下では、第１の実施形態の対話型検索システムの全体構成について、図１を参照しながら説明する。
【００４５】
図１において、第１の実施形態の対話型検索システム１は、対話管理部１０、意図解析部２０、ドメイン知識管理部３０、マッチング部４０、マッチング対象分析部５０を少なくとも有して構成される。
【００４６】
対話型検索システム１は、ユーザにデータを提供するデータ提供サーバ８０と接続しており、データ提供サーバ８０が保持する対象データを取得し、マッチング対象分析部５０の拡張対象データ５４に格納する。
【００４７】
ユーザは、ブラウザ９０を用いてＷｅｂサーバ７０にアクセスすることで、対話型検索システム１を起動させる。なお、ユーザ側のインターフェースとしては、通信機能を有するＰＣや携帯端末や専用端末など広く適用することができるが、ユーザが発した音声をテキスト変換する音声合成・認識部等を備えるようにしてもよい。
【００４８】
対話管理部１０は、検索を希望するユーザとの間の対話進行を管理するものであり、対話進行を制御する対話制御部１１を有する。
【００４９】
対話制御部１１は、ドメイン知識管理部３０から多次元オントロジーを受け取り、この多次元オントロジーに基づいて、対話進行に係る質問文（システム発話文ともいう）を作成するものである。
【００５０】
また、対話制御部１１は、質問文に対するユーザからの回答文（ユーザ発話文ともいう）を意図解析部２０に与えてユーザ発話文の内容を解析させるものである。なお、対話制御部１１は、ユーザ発話文の解析結果を受け取ると、そのユーザ発話文の解析結果をユーザデータとして、マッチング対象分析部５０の拡張ユーザデータ５３に格納する。
【００５１】
さらに、対話制御部１１は、意図解析部２０から意図解析結果を受け取ると、その意図解析結果をドメイン知識管理部３０に与えて、対話進行に利用する多次元オントロジーを生成させ、ドメイン知識管理部３０からの多次元オントロジーを利用して、次の質問文を決定して対話を進行させる。
【００５２】
また、対話制御部１１は、マッチング部４０に対してユーザのデータと対象データとのマッチングを指示するものである。このマッチングを指示するタイミングは、例えば、ユーザからのマッチング指示を受けたときや、各質問文に対する回答文が得られたときや、全ての質問項目が終了したときなどと種々のタイミングを設定することができる。
【００５３】
意図解析部２０は、対話制御部１１から取得した質問文に対してユーザが回答したユーザ発話文を受け取り、ユーザ発話文の内容を解析するものである。また、意図解析部２０は、解析した意図解析結果をオントロジー形式にして対話制御部１１に与える。さらに、意図解析部２０は、多次元意図解析処理として、ドメイン知識辞書の動的切替処理や解析対象文情報による動的切替処理を行うものである。
【００５４】
意図解析部２０は、意図解析実行部２１、意図解析用辞書２２、ドメイン知識辞書マネージャ２３を有する。
【００５５】
意図解析実行部２１は、意図解析用辞書２２を参照して、ユーザ発話文に対して形態素解析を行う形態素解析部２１１と、意図解析用辞書２２を参照して、ユーザ発話文に対して構文解析を行う構文解析部２１２を有する。
【００５６】
意図解析実行部２１は、ユーザ発話文に対して形態素解析や構文解析を行うことで、ドメイン知識ＤＢ３２のプロパティ定義に定義されるクラスを取得し、取得したクラスをドメイン知識管理部３０に与える。
【００５７】
意図解析用辞書２２は、ユーザ発話文の内容を解析するための辞書群であり、例えば、形態素辞書（例えば、日本語形態素辞書）、構文辞書（例えば、日本語構文辞書）、ベース次元及び各次元のクラス定義から自動生成されたドメイン知識辞書等が該当する。
【００５８】
ドメイン知識辞書マネージャ２３は、ユーザデータ管理から拡張ユーザデータを受け取り、この拡張ユーザデータに応じて、辞書引きする次元別ドメイン辞書の優先順位を並べ替え、その並べ替えた次元別ドメイン辞書を、意図解析辞書２２に設定するものである。
【００５９】
また、ドメイン知識辞書マネージャ２３は、データ提供サーバ８０からの対象データ（対象文情報）の解析結果を意図解析実行部２１から受け取り、対象データの内容に応じて、辞書引きする次元別構文辞書の並べ替えを行い、この並べ替えをした次元別構文辞書を、意図解析辞書２２に設定するものである。
【００６０】
ドメイン知識辞書マネージャ２３は、特徴抽出部２３１、条件並替部２３２、辞書設定部２３３を有する。
【００６１】
特徴抽出部２３１は、意図解析結果から次元の条件となる値が含まれている場合に、その次元条件の値を抽出するものである。条件並替部２３２は、特徴抽出部２３１が抽出した次元条件に対して、所定の優先順位に従って、次元別ドメイン辞書又は次元別構文辞書を並べ替えるものである。また、辞書設定部２３３は、条件並替部２３２により並べ替えられた次元別ドメイン辞書又は次元別構文辞書を意図解析用辞書２２に設定するものである。
【００６２】
ドメイン知識管理部３０は、ドメイン毎の多次元オントロジーを知識とするドメイン知識を管理するものである。ドメイン知識管理部３０は、ドメイン知識マネージャ３１、ドメイン知識ＤＢ３２を有する。
【００６３】
ドメイン知識ＤＢ３２には、多次元オントロジーを構築するためのベース次元及び各次元のプロパティ定義、クラス定義及び推論定義、多次元オントロジーを構成するための次元の条件、及び、次元の条件の優先度を定義する次元優先度定義テーブル、生成された多次元オントロジー、マッチングテーブルを格納するものである。
【００６４】
ドメイン知識マネージャ３１は、対話制御部１１から意図解析結果を受け取り、意図解析結果から特徴を抽出して、ドメイン知識ＤＢ３２のプロパティ定義及び次元優先度定義テーブルを参照しながら、多次元オントロジーを生成するものである。ドメイン知識マネージャ３１は、生成した多次元オントロジーをドメイン知識ＤＢ３２に格納するものである。
【００６５】
また、ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなし、多次元オントロジーを利用したマッチングテーブル（以下、多次元マッチングテーブルともいう）を生成するものである。マッチング部４０は、この多次元マッチングテーブルを参照しながら、マッチング処理を行う。
【００６６】
ドメイン知識管理部３０のドメイン知識マネージャ３１は、特徴抽出部３１１、条件照合部３１２、多次元オントロジー生成部３１３を有する。
【００６７】
特徴抽出部３１１は、ユーザ発話文の内容を解析した意図解析結果に、次元の条件となる特徴（次元条件にあたる値）がセットされているか否かを確認し、セットされている場合には、その特徴を抽出するものである。
【００６８】
ここで、ユーザデータ管理部５１が管理するユーザデータＤＢ５３は、対話制御部１１がユーザ発話から得られたユーザ情報を格納するものである。このユーザデータＤＢ５３には、ユーザ情報の格納場所（格納位置）を示すユーザデータパスと、ユーザ情報の値を示すユーザデータクラス名とを保持する。
【００６９】
条件照合部３１２は、特徴抽出部３１１が抽出した次元の値と次元優先度定義テーブルの内容を照合するものである。
【００７０】
多次元オントロジー生成部３１３は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ねて、多次元オントロジー又は多次元マッチングテーブルを生成するものである。
【００７１】
マッチング部４０は、ユーザデータ管理部５１に格納されるユーザデータと、対象データ管理部５０に格納される対象データとのマッチングを行い、ユーザが希望する条件のマッチングを行うものである。
【００７２】
マッチング部４０は、対話制御部１１から受け取った多次元マッチングテーブルをマッチャー４２に与えたり、マッチャー４２によりマッチングされた情報を対話制御部１１に与えたりするマッチングマネージャ４１と、ユーザデータと対象データとのマッチング処理を行うマッチャー４２とを有する。
【００７３】
マッチング対象分析部５０は、マッチング対象とするユーザデータや対象データを格納するものであり、マッチングしやすい形に拡張し、拡張したユーザデータ及び対象データを格納するものである。マッチング対象分析部５０は、ユーザデータ管理部５１、対象データ管理部５２、拡張ユーザデータ５３、拡張対象データ５４を有する。
【００７４】
（Ａ−３）第１の実施形態の動作
次に、第１の実施形態の対話型検索システム１における意図解析システムの動作について図面を参照しながら説明する。
【００７５】
（Ａ−３−１）全体動作
まず、対話型検索システム１における全体の流れについて図面を参照しながら説明する。
【００７６】
図４は、対話型検索システム１の全体の流れを示すフローチャートである。
【００７７】
対話型検索システム１を利用するユーザは、ブラウザ９０を用いて指定のＵＲＬにアクセスし、Ｗｅｂサーバ７０を通じて対話型検索システム１を起動する。
【００７８】
対話型検索システム１が起動すると、対話制御部１１が、ドメイン知識マネージャ３１を通じて、ドメイン知識ＤＢ３２に格納されるプロパティ定義を参照し、現在のポインタを定義域に持つプロパティで最も優先度が高いプロパティを選択する。
【００７９】
ここで、図５は、プロパティ定義の構成を示す構成図であり、図６は、プロパティ定義の一部をネットワーク形式で示した図である。
【００８０】
図５に示すプロパティ定義は、多次元のベースとなるプロパティ定義の例であり、例えば、「人間」を頂点として、各クラスのプロパティ関係を記述したものである。また、各プロパティが有する対話戦略やシステム発話に関するオプション情報を記述し、システムがどのような質問をどの順番でするかを規定する。
【００８１】
図５において、プロパティ定義は、定義域、プロパティ、値域、オプション情報の項目を有する。また、オプション情報には、必須の質問かどうかを決定する度合いを示す重要度、質問の順序（すなわち対話の流れ）を決定する度合いを示す優先度が設けられている。
【００８２】
さらに、オプション情報には、システム１が生成する基本質問文が定義されている。なお、図５には、オプション情報には、質問文の前に生成するつなぎ文、意図解析結果に基づき生成する各種受け止め文など、システムが円滑に対話を進行するための各種機能が定義されている。
【００８３】
また、オプション情報には、プロパティの種類が記述されており、例えば、グループ、取得対象がある。なお、ここではプロパティの種類を２種類の場合を例示したが、これに限定されることなく、設定することができる。
【００８４】
プロパティの種類が「取得対象」の場合、ドメイン知識マネージャ３１は、基本質問文の項目に設定されている基本質問文を対話制御部１１に与え、対話制御部１１が、これをシステム発話文としてＷｅｂサーバ７０を通じてユーザ側に送信する。
【００８５】
一方、プロパティの種類が「グループ」の場合、ドメイン知識マネージャ３１は、その値域クラスを定義域に持つプロパティを探索して選択する。このとき、この値域クラスを定義域とするプロパティが複数個ある場合、ドメイン知識マネージャ３１は、オプション情報の優先度を見て、最も優先度が高いプロパティを選択するようにする。そして、この選択したプロパティが「取得対象」ならば、ドメイン知識マネージャ３１は、その基本質問文を対話制御部１１に与えて、対話制御部１１が、これをシステム発話文としてユーザ側に送信する。
【００８６】
このように、プロパティの種類がグループの場合に、優先度を利用することで、値域クラスを定義域に持つプロパティへの移行を実現することができる。
【００８７】
図６は、図５に示すプロパティ定義の一部をネットワーク形式に展開した構成図である。
【００８８】
図６において、丸はクラス（すなわち、図５の定義域及び値域）を示し、クラスとクラスとの間を結ぶ線はプロパティを示す。
【００８９】
例えば、図６おいて、「人間」を頂点とし、プロパティを「パーソナリティ」とする場合の値域は「パーソナリティ」であり、プロパティを「強み」とする場合の値域は「仕事に活かせる強み」であり、プロパティを「転職をしようと思ったきっかけ」とする場合の値域は「転職理由」であり、プロパティを「仕事の経験」とする場合の値域は「現在の仕事」である。
【００９０】
また、例えば、「パーソナリティ」を定義域とする場合にも、上記と同様に、例えばプロパティを「サイト訪問目的」とする場合の値域は「サイト訪問目的」である等の関係を持つ。また、「パーソナリティ」と「サイト訪問目的」等とはｈａｓ ｐａｒｔの関係にあり、「サイト訪問目的」とユーザの回答である「適職を知りたい」とはｉｓ Ａの関係にある。
【００９１】
システム開始時の場合、プロパティ定義では、初期値として選択する定義域が設定されている。図５の第１段目の定義域クラス「人間」に対してポインタが設定されている。
【００９２】
従って、ドメイン知識マネージャ３１は、初期のポインタが指す定義域クラス「人間」のプロパティで最も優先度が高い「パーソナリティ」とする場合の値域クラス「パーソナリティ」を見る。
【００９３】
このとき、この値域クラス「パーソナリティ」のプロパティの種類は「グループ」であるから、ドメイン知識マネージャ３１は、値域クラス「パーソナリティ」を定義域とするプロパティのうち、優先度が最も高い定義域クラス「パーソナリティ」−プロパティ「サイト訪問目的」−値域クラス「サイト訪問目的」のプロパティに選択する。
【００９４】
そして、ドメイン知識マネージャ３１は、このプロパティの基本質問文である「このサイトに来た目的を教えて下さい」を対話制御部１１に与えて、対話制御部１１がこの基本質問文をシステム発話としてユーザ側に送信する。このようにして、システムからの質問を開始する（ステップＳ１０１）。
【００９５】
このシステム発話文を受信したユーザは、例えば「自分の適職が何かを知りたいので」と回答し、これを回答文としてＷｅｂサーバ７０を通じて対話制御部１１に送信する（ステップＳ１０２）。
【００９６】
対話制御部１１は、ユーザ発話文を受信すると、このユーザ発話文を意図解析部２０に与える。意図解析部２０では、意図解析実行部２１が、意図解析用辞書２２を用いて、ユーザ発話文に対して、形態素解析や構文解析を行い、その結果「適職を知りたい」というユーザの意図を解析し、その意図解析結果を対話制御部１１に与える（ステップＳ１０３）。
【００９７】
このとき、意図解析部２０の意図解析結果は、ドメイン知識マネージャ３１に与えられ、ドメイン知識マネージャ３１により多次元オントロジーが生成され、生成された多次元オントロジーがドメイン知識ＤＢ３２に記憶される。
【００９８】
対話制御部１１は、意図解析部２０からの意図解析結果を受け取ると、ドメイン知識マネージャ３１に対して次の質問の問い合わせを行い、次の質問を決定する（ステップＳ１０４）。
【００９９】
このとき、ドメイン知識マネージャ３１は、プロパティ定義を参照し、値域クラス「サイト訪問」の次に優先度が高い、定義域クラス「パーソナリティ」−プロパティ「現在の職種」−値域クラス「職種」に移行して、基本質問文「現在のあなたの職種は何ですか？」を対話制御部１１に与え、対話制御部１１がこれをシステム発話文として決定してユーザ側に送信する（ステップＳ１０５）。
【０１００】
このように、次の質問文の提示とユーザからの回答文の受信とを繰り返し行うことで、システムとユーザとの間の対話が実現される。
【０１０１】
なお、検索処理は、対話制御処理（Ｓ１０４）内で処理され、ユーザからの検索要求を対話制御部１１が受け取ると、検索結果が表示される（詳細は、Ａ−３−４に記載）。
【０１０２】
なお、ステップＳ１０４において、次の質問が決定されなかった場合、すなわち全ての質問が終了した場合、システムの動作は終了する。
【０１０３】
（Ａ−３−２）ドメイン知識マネージャ処理
次に、ドメイン知識マネージャ３１における多次元オントロジーの作成処理の詳細について図面を参照しながら説明する。
【０１０４】
ここでの例は、対話制御におけるドメイン知識マネージャ３１の処理を説明するものであるが、本動作は、マッチングテーブルをオントロジーとみなして処理する場合も基本動作は同じである。
【０１０５】
図７は、ドメイン知識マネージャ３１における多次元オントロジーの作成処理の動作を示すフローチャートである。
【０１０６】
ドメイン知識マネージャ３１は、対話制御部１１から意図解析結果を受け取る。また、ドメイン知識マネージャ３１は、当該ユーザのユーザデータをユーザデータ管理部５１から取得する（ステップＳ２０１）。
【０１０７】
例えば、対話制御部１１からの意図解析結果が、「／人間／パーソナリティ／現在の職種＝営業」とする。
【０１０８】
また、ユーザデータ管理部５１からの当該ユーザのユーザデータが、図８に示す内容であるとする。図８に示すように、ユーザデータは、オントロジー形式で記述されている。図８の場合、当該ユーザのユーザデータとしては、プロパティ「ニックネーム」のクラスがクラス「○ちゃん」であり、同様に、プロパティ「転職活動のステージ」−クラス「履歴書送付」、プロパティ「ライフイベント」−クラス「リストラ・倒産」、プロパティ「現在の業種」−クラス「医薬品」、プロパティ「現在の職種」−クラス「営業」であるとする。
【０１０９】
なお、ユーザデータは、説明便宜上のため、ユーザの回答から得られたプロパティに対するクラスをデータとする場合を示すが、例えば、ユーザの回答クラスから推論された新たなクラスをデータとする等、ユーザデータを拡張した内容であってよい。
【０１１０】
ドメイン知識マネージャ３１の特徴抽出部３１１が、ユーザデータと、ドメイン知識ＤＢ３２に登録されている全ての次元の条件と照合し、条件に合う次元条件を抽出する（ステップＳ２０２）。つまり、特徴抽出部３１１は、ユーザデータに全ての次元の条件となる値が含まれているか否かを確認し、条件となる値がある場合には、その次元の条件となる値を抽出する。
【０１１１】
例えば、ドメイン知識ＤＢ３２に格納されている次元の条件として、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」があるとする。
【０１１２】
特徴抽出部３１１は、上記のような次元の条件とマッチングして、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」という特徴をユーザデータから抽出する。
【０１１３】
次に、条件照合部３１２は、特徴抽出部３１１が抽出した次元の条件となる値を、所定の優先度の高い順に並べ替え（ステップＳ２０３）、次元の条件となる値の有無を確認して、次元優先度定義テーブルに格納する（ステップＳ２０４）。
【０１１４】
このとき、例えば、次元の条件の数が多いものを優先度が高くする。また、次元の条件の数が同じ場合には、事前に次元毎の優先度を設定しておき、この優先度に基づいて並べ替えをする。
【０１１５】
例えば、特徴抽出部３１１が抽出した次元の条件の値のうち、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」は条件数が２個であるから、最も優先度が高い。
【０１１６】
次に、「／人間／パーソナリティ／現在の職種＝営業」と「／人間／パーソナリティ／現在の業種＝医薬品」とは、次元の条件の数が１個であり、同数である。
【０１１７】
そこで、条件照合部３１２は、例えば、図９に示す次元リストを参照して、各次元の条件の値の優先度を確認し、この次元リストに従って各次元の条件の値をソートする。
【０１１８】
図９の次元リストでは、上に記述されているものほど優先度が高い。例えば、「／人間／パーソナリティ／ライフイベント」は、「／人間／パーソナリティ／現在の職種」よりも優先度が高い。また、次元を表すパスが同じ場合、「／人間／パーソナリティ／現在の職種＝営業」は、「／人間／パーソナリティ／現在の職種＝ＳＥ」よりも優先度が高い。
【０１１９】
従って、「／人間／パーソナリティ／現在の職種＝営業」と「／人間／パーソナリティ／現在の業種＝医薬品」について、条件照合部３１２は、「／人間／パーソナリティ／現在の職種＝営業」が「／人間／パーソナリティ／現在の業種＝医薬品」より優先度が高くなるように並べ替える。
【０１２０】
その結果、図１０に示すように、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」の順にソートされる。
【０１２１】
次に、多次元オントロジー生成部３１３は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ね合わせて多次元オントロジーを生成する（ステップＳ２０５）。
【０１２２】
図１１は、多次元オントロジーの生成処理を説明する説明図である。図１１（Ａ）は、ベース次元に定義されている職種クラス及びクラスオプションを示す。図１１（Ｂ）は、「業種クラス＝医薬品」の次元の職種クラス及びクラスオプションの定義を示す。
【０１２３】
多次元オントロジー生成部３１３は、図１１（Ａ）のベース次元に定義されている職種クラス及びクラスオプションに対して、図１１（Ｂ）の「業種＝医薬品」の次元の職種クラス及びクラスオプションの内容を上書きする。
【０１２４】
このとき、図１１（Ａ）のベース次元の職種クラスでは、クラス「職種」−クラス「営業」のオプションの受け止め文が「営業のお仕事をされているんですね。」定義されているが、ステップＳ２０５の上書きにより、クラス「職種」−クラス「営業」のオプションの受け止め文が「競争の激しい業界でも営業は大変でしょう。」に書き換えされる。
【０１２５】
このように、多次元オントロジーによれば、ベース次元に定義されるクラスオプション定義の内容を変更することができる。これにより、例えばユーザの職種などに応じて適切な受け止め文を出力することができる。
【０１２６】
多次元オントロジー生成部３１３は、生成した多次元オントロジーを対話制御部１１に出力する（ステップＳ２０６）。なお、この生成された多次元オントロジーは、ドメイン知識ＤＢ３２に格納される。
【０１２７】
（Ａ−３−３）対話型検索処理における対話制御処理
次に、対話型検索処理における対話制御処理ついて、図面を参照しながら詳細に説明する。
【０１２８】
対話型検索処理における対話制御処理を行う前提として、ドメイン知識マネージャ３１は、データ提供サーバ８０から取得した対象データに対して、図７で説明した多次元オントロジー作成処理を行い、対象データの意図を解析し、拡張対象データ５４に格納する。
【０１２９】
図１２は、対話型検索処理における対話制御処理を示すフローチャートである。
【０１３０】
まず、意図解析部２０において、ユーザ発話文に対する意図解析が行われ、その意図解析結果が対話制御部１１に与えられると（ステップＳ３０１）、対話制御部１１は、意図解析結果を拡張ユーザデータ５３に格納する（ステップＳ３０２）。
【０１３１】
例えば、対話制御部１１は、「／人間／パーソナリティ／現在の仕事／経験年数＝５年」とする意図解析結果を拡張個人データ５３に格納する。
【０１３２】
次に、マッチング部２０は、マッチング処理を起動する。具体的には、ドメイン知識マネージャ３１が多次元マッチングテーブルを生成し、それを用いて、拡張ユーザデータから拡張対象データを検索し、最も検索類似度の高い対象データから順に並べ替える（ステップＳ３０３）。
【０１３３】
このように、ユーザとの対話を通じて、ユーザから得た全ての情報と、全対象データとの間の類似度を計算し、類似度の高い対象データから順にユーザに提示する。
【０１３４】
このとき、ユーザ側からマッチング結果の表示要求を受けた場合（ステップＳ３０４）、対話制御部１１は、マッチング部４０からマッチング結果を受け取り、マッチング結果をユーザ側に送信する（ステップＳ３０５）。
【０１３５】
一方、ユーザ側からの表示要求がない場合には（ステップＳ３０４）、対話制御部１１は、マッチング結果の送信を行わず、ステップＳ３０６に移行する。
【０１３６】
ステップＳ３０６では、対話制御部１１は、ドメイン知識マネージャ３１から多次元オントロジーを受け取り、次の質問（プロパティ）を決定する。そして、対話制御部１１は、次の質問文をユーザ側に送信して、処理を終了する（ステップＳ３０７）。
【０１３７】
（Ａ−３−４）多次元オントロジーを利用したマッチング処理
次に、図１２のステップＳ３０３における多次元オントロジーを利用したマッチング処理の詳細な動作について図面を参照しながら説明する。
【０１３８】
図１３は、多次元オントロジーを利用したマッチング処理の動作を示すフローチャートである。ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する処理である。
【０１３９】
まず、マッチング部４０は、ドメイン知識マネージャ３１に対して、マッチングテーブルの作成要求を行い、ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する（ステップＳ４０１）。
【０１４０】
マッチングテーブル作成要求を受けると、ドメイン知識マネージャ３１は、拡張ユーザデータ５３からユーザデータを全て取得する。
【０１４１】
ドメイン知識マネージャ３１の動作フローは、図７のＳ２０４が存在しないフローで表される。ドメイン知識マネージャ３１では、特徴抽出部３１１が、ユーザデータと全てのマッチングテーブルに登録されている全ての次元の条件とを照合し、条件に合う次元条件を抽出する（Ｓ２０２）。
【０１４２】
次に、ドメイン知識マネージャ３１では、条件照合部３１２が、特徴抽出部３１１により抽出された次元条件を、一定の基準に従って優先度の高いものから順に並べて、次元優先度定義テーブルに格納する（Ｓ２０３）。
【０１４３】
そして、多次元オントロジー生成部３１３が、次元優先度定義テーブルの優先度に従って、次元別マッチングテーブルをベース次元のマッチングテーブルに重ね合わせて、多次元マッチングテーブルを生成し（Ｓ２０５）、マッチング部４０に与える（Ｓ２０６）。
【０１４４】
例えば、図１４は、現在の職種がコックであるニックネーム「○ちゃん」のユーザデータ（ネットワーク形式）である。また、図１５は、ベース次元のマッチングテーブルの構成例を示す。
【０１４５】
なお、図１５（Ａ）は、ベース次元のマッチングテーブルを表形式で示したものであり、図１５（Ｂ）は、ベース次元のマッチングテーブルをネットワーク形式で示したものである。
【０１４６】
図１５において、ベース次元のマッチングテーブルは、「ユーザデータ」、「重要度」、「対象データ」を項目とする。項目「ユーザデータ」は、ユーザデータにおけるプロパティ（条件）を示す。項目「対象データ」は、対象データにおけるプロパティ（条件）を示す。項目「重要度」は、マッチングにおけるプロパティに対する重み付けを示す。
【０１４７】
図１５の例においては、「ユーザデータ＝現在の職種」及び「対象データ＝経験職種」が対応する関係にあり、その重要度が「０．５」であることを示す。
【０１４８】
ユーザデータと対象データとの関係でプロパティ名が異なっているが、これは、転職を募集する企業の募集要項（データ）の条件名（プロパティ名）と、これに対応するユーザから抽出する条件名（プロパティ名）とが異なるからである。
【０１４９】
また、特徴抽出部３１１による特徴抽出の際に参照した次元のマッチングテーブルを図１６に示す。
【０１５０】
図１６のマッチングテーブルは、「／人間／パーソナリティ／現在の職種＝コック」次元のマッチングテーブルである。なお、図１６（Ａ）は表形式で示したものであり、図１６（Ｂ）はネットワーク形式で示したものである。
【０１５１】
図１６に示す次元のマッチングテーブルでは、「現在の職種＝コック」であるから、調理に関連する資格を所有していることが重要であるから、所有する資格の重要度が「１．０」と高く定義されている。
【０１５２】
従って、多次元オントロジー生成部３１３は、図１５に示すベース次元のマッチングテーブルに、図１６に示す次元のマッチングテーブルを上書きする。その結果、図１７に示しように、「資格の重要度」が「１．０」に変更された、多次元マッチングテーブルを生成することができる。
【０１５３】
また別の例として、図１８に示すような、現在の職種が「ＳＥ」の「△くん」のユーザデータを取得した場合を説明する。
【０１５４】
この場合、特徴抽出部３１１による特徴抽出の際に参照した次元のマッチングテーブルを図１９に示す。
【０１５５】
図１９のマッチングテーブルは、「／人間／パーソナリティ／現在の職種＝ＳＥ」次元のマッチングテーブルである。なお、図１９（Ａ）は表形式で示したものであり、図１９（Ｂ）はネットワーク形式で示したものである。
【０１５６】
図１９に示す次元のマッチングテーブルでは、「現在の職種＝コック」であるから、所有する資格は重視されないが、経験年数が重視されるため、所有する資格の重要度が「０．１」と低く定義され、経験年数の重要度が「０．８」と高く定義されている。
【０１５７】
従って、多次元オントロジー生成部３１３は、図１５に示すベース次元のマッチングテーブルに、図１９に示す次元のマッチングテーブルを上書きする。その結果、図２０に示しように、資格の重要度が「０．１」、経験年数の重要度が「０．８」に変更された、多次元マッチングテーブルを生成することができる。
【０１５８】
次に、ドメイン知識マネージャ３１から多次元マッチングテーブルを受け取ったマッチング部４０は、この多次元マッチングテーブルに基づいて、全ての対象データとの類似度を計算する（ステップＳ４０２）。
【０１５９】
このとき、マッチング部４０は、多次元マッチングテーブルを利用したマッチングテーブルに記述されている「重要度」によって重み付けを行って類似度を計算する。
【０１６０】
そして、マッチング部４０は、類似度の高いものから順に対象データを並べ替えて、これをマッチング結果とする。
【０１６１】
例えば、上記の「○ちゃん」の例において、マッチング部４０は、図１７に示す多次元マッチングテーブルを受け取り、図２１（Ａ）の「Ａ社」、「Ｂ社」の対象データとの類似度を計算する場合を説明する。
【０１６２】
「Ａ社」の条件は「経験業種＝コック」、「保有資格＝調理師免許」、「経験年数＝１年以上」であるから、「○ちゃん」は、すべての条件にマッチする。従って、マッチング部４０は、「Ａ社」との類似度を「（１×０．５）＋（１×１．０）＋（１×０．５）＝２．０」と計算する（図２１（Ｂ）参照）。
【０１６３】
同様に、「Ｂ社」の条件は「経験業種＝コック」、「保有資格＝栄養士免許」、「経験年数＝５年以上」であるから、「○ちゃん」は、「保有資格」以外の条件にマッチする。従って、マッチング部４０は、「Ｂ社」との類似度を「（１×０．５）＋（０×１．０）＋（１×０．５）＝１．０」と計算する（図２１（Ｂ）参照）。
【０１６４】
従って、マッチング部４０は、図２１（Ｃ）のように、「Ａ社」「Ｂ社」の順にしてマッチング結果を出力する。
【０１６５】
また例えば、上記の「△くん」の例において、マッチング部４０は、図１９に示す多次元マッチングテーブルを受け取り、図２２（Ａ）の「Ｃ社」、「Ｄ社」の対象データとの類似度を計算する場合を説明する。
【０１６６】
「Ｃ社」の条件は「経験業種＝ＳＥ」、「保有資格＝初級シスアド」、「経験年数＝１年以上」であるから、「△くん」は、すべての条件にマッチする。従って、マッチング部４０は、「Ａ社」との類似度を「（１×０．５）＋（１×０．１）＋（１×０．８）＝１．４」と計算する（図２２（Ｂ）参照）。
【０１６７】
同様に、「Ｄ社」の条件は「経験業種＝コック」、「保有資格＝上級シスアド」、「経験年数＝５年以上」であるから、「△くん」は、「経験年数」以外の条件にマッチする。従って、マッチング部４０は、「Ｄ社」との類似度を「（１×０．５）＋（１×０．１）＋（０×０．８）＝０．６」と計算する（図２２（Ｂ）参照）。
【０１６８】
従って、マッチング部４０は、図２２（Ｃ）のように、「Ｃ社」「Ｄ社」の順にしてマッチング結果を出力する。
【０１６９】
（Ａ−３−５）多次元意図解析処理（ドメイン知識辞書の動的切替処理）
次に、多次元意図解析処理（ドメイン知識辞書の動的切替処理）について図面を参照しながら詳細に説明する。
【０１７０】
図２３は、多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係る意図解析実行部２１の処理を示すフローチャートである。また、図２４は、多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係るドメイン知識辞書マネージャ２３の処理を示すフローチャートである。
【０１７１】
まず、図２３において、意図解析部２０は、対話制御部１１からユーザ発話文を受け取る（ステップＳ５０１）。
【０１７２】
意図解析部２０では、付属情報がある場合には、その付属情報をユーザデータとして拡張ユーザデータ５３にセットする（ステップＳ５０２）。
【０１７３】
またユーザ発話文が複数の文からなる場合、意図解析実行部２１は、一文単位に区切り（ステップＳ５０３）、形態素解析部２１１がユーザ発話文に対して形態素解析を行い（ステップＳ５０４）、構文解析部２１２が構文解析を行う（ステップＳ５０５）。
【０１７４】
さらに、意図解析実行部２１は、意図解析用辞書２２を参照して意図解析を行う。このとき、意図解析実行部２１は、ユーザデータをドメイン知識辞書マネージャ２３に与える（ステップＳ５０６）。
【０１７５】
図２４において、意図解析実行部２１からユーザデータを受け取ると（ステップＳ６０１）、ユーザドメイン知識辞書マネージャ２３は、特徴抽出部２３１が、ユーザデータと各次元の次元条件と照合し、次元条件に合う値を抽出する（ステップＳ６０２）。
【０１７６】
条件並替部２３２は、特徴抽出部３１１が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え（ステップＳ６０３）、辞書設定部２３３が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書２２にセットする（ステップＳ６０４）。
【０１７７】
そして、図２３のステップＳ５０７では、意図解析部２０は、ドメイン知識辞書マネージャ２３によりセッティングされた順序で次元別ドメイン知識辞書から辞書引きを行い、ユーザとの対話から得られた情報に応じた意図を生成する（ステップＳ５０７）。
【０１７８】
例えば、図２５〜図２９を用いて、「○ちゃん」に対する、現住所に関する質問についてのユーザ発話文が「三田です」である場合の意図解析を例示して説明する。
【０１７９】
まず、システム起動前に、「住所」クラスのクラス定義に従って、図２８（Ａ）〜図２８（Ｃ）に示すような次元別ドメイン知識辞書を自動生成しておく。
【０１８０】
例えば、図２８（Ａ）は、「／人間／パーソナリティ／勤め先住所＝大阪」次元の「住所」クラスを定義した次元別ドメイン知識辞書であり、上位の階層を「住所」クラスとした場合、「住所」クラスの配下に「大阪」クラスがあり、「大阪」クラスの配下に「高槻市」クラス、「茨木市」クラス、…がある。また、「高槻市」クラス、「茨木市」クラス、…の異表記も併記したものである。
【０１８１】
同様に、図２８（Ｂ）は、「／人間／パーソナリティ／勤め先住所＝関西」次元の「住所」クラスを定義したドメイン知識辞書であり、図２８（Ｃ）は、「／人間／パーソナリティ／勤め先住所＝東京」次元の「住所」クラスを定義したドメイン知識辞書である。
【０１８２】
図２６に示すユーザデータがドメイン知識辞書マネージャ２３に与えられると、ドメイン知識辞書マネージャ３２では、特徴抽出部２３１が、ユーザデータから特徴抽出を行い、プロパティ「勤め先場所」−クラス「大阪」を抽出する。
【０１８３】
条件並替部２３２は、特徴抽出部２３１が抽出したプロパティ「勤め先場所」−クラス「大阪」を条件に合う次元別ドメイン知識辞書を選択し、所定の優先順位に従って次元別ドメイン知識辞書の並べ替えを行う。この次元別辞書の並べ替えにより、優先順位の高い次元別ドメイン知識辞書から辞書引きできるようにする。
【０１８４】
このとき、条件並替部２３２は、特徴抽出部２３１がプロパティ「勤め先場所」−クラス「大阪」の条件に合う、図２８（Ａ）の次元別ドメイン知識辞書が一番高い優先順位とし、「大阪」クラスの上位階層のクラスである「関西」クラスのドメイン知識辞書を次に高い優先順位として並べ替える。
【０１８５】
これにより、条件並替部２３２は、図２７に示すように、特徴抽出部２３１の抽出条件から、図２８（Ａ）の「／人間／パーソナリティ／勤め先住所＝大阪」次元のドメイン知識辞書、図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書の順に並べ替えを行う。このとき、図２８（Ｃ）の「／人間／パーソナリティ／勤め先住所＝関東」次元のドメイン知識辞書は、図２６のユーザデータの条件に適合しないので使われない。
【０１８６】
そして、例えばシステム発話文「おすまいはどちらですか？」に対するユーザ発話文「三田です」を意図解析部２０が受け取る。
【０１８７】
意図解析実行部２１では、形態素解析部２１１がユーザ発話文「三田です」に対して形態素解析を行い、形態素解析結果「三田：名詞 だ：助動詞」を得て、構文解析部２１２が構文解析を行い、図２５に示すような構文解析結果を得る。
【０１８８】
そして、意図解析実行部２１は、図２７に示すように、図２８（Ａ）の「／人間／パーソナリティ／勤め先住所＝大阪」次元のドメイン知識辞書を用いて解析し、次に優先順位の高い図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書を用いて解析する。
【０１８９】
その結果、図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書を用いて、構文解析結果「住所−三田」に対応する「住所−三田市」を辞書引きして、当該ユーザの現住所が兵庫県の「三田市」であるとの意図解析結果を得て、これを出力する（図２９参照）。このようにユーザから既に与えられている条件を利用することによって、三田という言葉における、兵庫県の三田市（さんだし）と東京の三田（みた）という曖昧性を解消することができる。
【０１９０】
（Ａ−３−６）多次元意図解析処理（解析対象文情報による動的切替処理）
次に、多次元意図解析処理（解析対象文情報による動的切替処理）について図面を参照しながら説明する。
【０１９１】
解析対象文の動的切替処理とは、対象データから拡張対象データを構築する際の多次元意図解析処理である。
【０１９２】
解析対象文の動的切替処理は、図２３及び図２４に示すフローチャートを用いてできるので、ここでは、図２３及び図２４を参照しながら説明する。なお、図２３及び図２４において、「ユーザデータ」と記載は「対象データ」となる。
【０１９３】
図３０（Ａ）は、意図解析部２０に与えられる対象データを示す。意図解析部２０において、対象データには、「解析対象：対象データ」という付属情報が付される。従って、意図解析実行部２１は、対象データに「解析対象：対象データ」が付与される（ステップＳ５００１、Ｓ５０２）。
【０１９４】
また、対象データは複数の文からなるので、意図解析実行部２１は、対象データを１文単位に区切り（ステップＳ５０３）、対象データの各文に対して形態素解析を行い（ステップＳ５０４）、構文解析を行う（ステップＳ５０５）。
【０１９５】
例えば、対象データの一部である「ネットワーク設計経験者優遇。」という文については、図３０（Ｂ）に示すような構文解析結果を得る。つまり、「経験者待遇：名詞 設計：名詞 ネットワーク：名詞」という形態素解析結果から図３０（Ｂ）のような構文解析結果となる。
【０１９６】
意図解析実行部２１は、当該ユーザデータをドメイン知識辞書マネージャ２３に与える（ステップＳ５０６）。
【０１９７】
意図解析実行部２１からユーザデータを受け取ったドメイン知識辞書マネージャ２３では、特徴抽出部２３１が、ユーザデータと、次元別のマッチングテーブルに登録されている全ての次元条件と照合し、各次元条件に合う次元条件を抽出する（ステップＳ６０１、Ｓ６０２）。
【０１９８】
条件並替部２３２は、特徴抽出部２３１が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え（ステップＳ６０３）、辞書設定部２３３が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書２２にセットする（ステップＳ６０４）。
【０１９９】
例えば、ドメイン知識辞書マネージャ２３のドメイン知識ＤＢに、図３２（Ａ）及び図３２（Ｂ）に示すような多次元構文辞書がある場合、ドメイン知識辞書マネージャ２３は、特徴抽出部２３１の抽出条件から、一定の基準に従って、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書、図３２（Ｂ）のベース次元の構文辞書の順に並べ替えを行う。
【０２００】
その結果、ドメイン知識辞書マネージャ２３は、図３１に示すように、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書を一番最初に辞書引きできるようにし、一番優先度が低い位置にベース次元の構文辞書を設定する。
【０２０１】
そして、意図解析部２０は、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書から辞書引きして、「経験職種＝ネットワーク設計者」とする意図解析結果を出力する（図３３参照）。
【０２０２】
（Ａ−３−７）マッチング結果と連動した対話制御処理
次に、マッチング結果と連動した対話制御処理について、図面を参照しながら詳細に説明する。
【０２０３】
図３４は、マッチング結果と連動した対話制御処理における対話制御部１１における処理を示すフローチャートである。図３５は、マッチング結果と連動した対話制御処理におけるマッチング処理を示すフローチャートである。
【０２０４】
検索処理と連動した対話制御処理を行う前提として、ドメイン知識マネージャ３１は、データ提供サーバ８０から取得した対象データに対して、対象データの意図を解析し、拡張対象データ５４に格納する。
【０２０５】
図３４において、対話制御部１１は、意図解析部２０から意図解析結果を受け取り（ステップＳ７０３）、ユーザデータとして拡張ユーザデータ５３に格納し（ステップＳ７０２）、マッチング処理を起動する（ステップＳ７０３）。
【０２０６】
例えば、ユーザ「○ちゃん」との対話によりユーザ発話文「Ｊａｖａのプログラムを５年ほどやっています。」に対する意図解析結果が、「／人間／仕事の経験／内容＝Ｊａｖａ、／人間／仕事の経験／年数＝５年」とする。
【０２０７】
また、図３６は、「○ちゃん」のユーザデータであるとし、対話制御部１１は、図３６に示すユーザデータを拡張ユーザデータ５３に格納する。
【０２０８】
マッチング部４０は、拡張対象データ５４に格納されるユーザデータに完全にマッチする全ての拡張対象データを取り出す（ステップＳ８０１）。
【０２０９】
例えば、図３７は、ユーザデータに完全にマッチする拡張対象データの例を示し、図３７（Ａ）は、「Ａ社」の求人データ（対象データ）であり、プロパティ「社名」−クラス「Ａ社」、プロパティ「使用言語」−クラス「Ｊａｖａ」、プロパティ「経験年数」−クラス「３年以上」、…である。また、図３７（Ｂ）は、「Ｂ社」の求人データ（対象データ）であり、プロパティ「社名」−クラス「Ｂ社」、プロパティ「使用言語」−クラス「Ｊａｖａ」、…である。
【０２１０】
マッチング部４０がドメイン知識マネージャ３１に対してマッチングテーブルの作成要求を行う（ステップＳ８０２）。
【０２１１】
このとき、ドメイン知識マネージャ３１は、（Ａ−３−４）で説明した処理と同様に方法で、多次元マッチングテーブルを生成し、これをマッチング部４０に与える。
【０２１２】
ここで、図３８は、マッチング部に与えられた多次元マッチングテーブルとする。
【０２１３】
マッチング部４０は、多次元マッチングテーブルに基づいて、全ての対象データに関して、ユーザデータとの類似度を計算し（ステップＳ８０３）、類似度の高いものから順に対象データを並び替える（ステップＳ８０４）。
【０２１４】
このとき、マッチング部４０は、最も高い類似度を持つ対象データに関して曖昧なマッチングがあるか否かを確認する（ステップＳ８０５）。
【０２１５】
ここで、曖昧なマッチングとは、対象データには条件となる値が存在するが、ユーザデータには条件となる値が存在しない場合のマッチングをいう。
【０２１６】
図３９は、図３８の多次元マッチンテーブルに基づいて、図３６の「○ちゃん」のユーザデータと、図３７（Ａ）の「Ａ社」の対象データとをマッチングした場合を説明する図である。
【０２１７】
図３９では、「Ａ社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Ｊａｖａ」、「経験年数−３年以上」がある。また、「○ちゃん」のユーザデータにも、上記の条件の値に対応する「プログラマ」、「Ｊａｖａ」、「５年」が存在している。従って、「○ちゃん」のユーザデータには、曖昧なマッチングは存在しないと判断する。
【０２１８】
なお、マッチング処理が終了すると、図３４のステップＳ７０４に移行するが、次の質問文がセットされていないので、ステップＳ７０５〜Ｓ７０８の処理を行う。なお、ステップＳ７０５〜Ｓ７０８は、図１２のステップＳ３０４〜Ｓ３０７に対応するので説明を省略する。
【０２１９】
一方、ユーザ「△くん」の場合、ユーザ発話文「Ｊａｖａ経験があります。」に対する意図解析結果が、「／人間／仕事の経験／内容＝Ｊａｖａ」であるとし、「△くん」のユーザデータは、図４０に示すようものとする。
【０２２０】
そして、図３８の「／人間／現在の職種＝プログラマ」次元のマッチンテーブルに基づいて、図４０の「△くん」のユーザデータと、図３７（Ａ）の「Ａ社」の対象データとをマッチングした場合を、図４１に示す。
【０２２１】
図４１に示すように、上記同様、「Ａ社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Ｊａｖａ」、「経験年数−３年以上」がある。
【０２２２】
しかし、「△くん」のユーザデータには、上記の条件の値に対応する「職種−プログラマ」、「使用言語−Ｊａｖａ」は存在するが、「経験年数−３年以上」に相当する条件の値が存在しない。
【０２２３】
そこで、マッチング部４０は、プロパティ「経験年数」に関する深堀質問をセットし、これをドメイン知識マネージャ３１に与える（ステップＳ８０６）。
【０２２４】
そして、ドメイン知識マネージャ３１は、プロパティ「経験年数」を次の質問文とするようにし、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」を対話制御部１１に与え、次の質問文が決定する。
【０２２５】
この場合、ステップＳ７０４に移行し、対話制御部１１には、次の質問文がセットされているので、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」をユーザ側に出力する。
【０２２６】
このようにすることで、「△くん」との対話処理で、「経験年数」を質問することができ、例えば「５年です。」という回答が得られた場合、「Ａ社」の対象データとの類似度がより高くなり、「△くん」は、自分に合った会社を、より早く探すことができる。また、経験年数が「１年」であると回答を得た場合には、逆に自分が検討しても無駄な会社を、より早く候補外にすることができる。
【０２２７】
また、もし、「Ａ社」でなく、「Ｂ社」の場合には、経験年数を条件にしてないので、深堀質問はなされない。このように、検索結果となる対象データの状態に応じて、質問を自在に制御することができる。
【０２２８】
（Ａ−４）第１の実施形態の効果
以上、第１の実施形態によれば、多次元オントロジーを利用してマッチング処理を行うことにより、ユーザの意図や状況に応じて情報検索に係るマッチングの重要度を動的に変えることができるので、より的確なマッチングを行うことができる。
【０２２９】
また、第１の実施形態によれば、意図解析を多次元化することにより、ユーザの意図や状況に応じて、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。また、的確な選択基準を選択できるので、ユーザに対する質問やマッチングに係る検索対象も、ユーザの意図するものにすることができる。
【０２３０】
さらに、第１の実施形態によれば、対象データに関する情報によって、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。
【０２３１】
また、第１の実施形態によれば、マッチング結果に連動させて対話制御を行うことで、対象データとのマッチングに必要な情報を次の質問文としてユーザに提示することができるので、より迅速かつ的確なマッチング処理を提供できる。
【０２３２】
（Ｂ）他の実施形態
（Ｂ−１）意図解析の多次元化とは、ユーザから取得された値によって、解析エンジン（解析時に利用する辞書）を動的に使い分けることを意味する。解析エンジンを動的に使い分ける仕組みは、対話制御がドメイン知識マネージャを通じて、オントロジーを動的に使い分ける仕組みを応用することで実現可能である。
【０２３３】
（Ｂ−２）意図解析を多次元化することにより、以下のようなことができる。
【０２３４】
（１）関西を希望している人が、「三田がいい」と発言したら「三田市」と返すことができる。また、関東を希望している人は、「東京の三田」を返すことができる。
【０２３５】
（２）口語で入力する人には、口語解析用エンジン、関西弁の人には、関西弁エンジンを使うことで、それぞれの解析精度が向上する。
【０２３６】
（３）プロデューサを希望する人とプログラマを希望する人では、「プログラムを作る」の意味が違うことが理解できるようになる。
【０２３７】
（４）正社員を希望する人は年収（又は月収）、パートの人は時給を給与のデフォルトにして解析することができる。
【０２３８】
（５）求人データ、ユーザ発話文の解析時には、それぞれ別の解析エンジンを使うことで、解析精度が向上する
（６）求人データは、通常、情報がタグ付けされている。そのタグの値毎に、辞書を使い分けることにより、精度高く解析できる。例えば、求人職種タグの場合は、「職種」の入力を前提とした辞書で解析する。「先輩ＰＲ」タグの場合は、社員が述べるような内容の入力を前提とした辞書で解析する。
【０２３９】
（Ｂ−３）検索の多次元化とは、ユーザから取得した値によって、検索の条件を動的に使い分けることを意味する。
【０２４０】
例えば、意図解析がなくても（例えば、アンケートのようにユーザからの回答が決まっているため、意図解析する必要ながなくても）同様の処理は勿論可能である。
【０２４１】
また、提示要求は、検索後であるとは限らず、いつでも検索しても良い。
【０２４２】
さらに、第１の実施形態では、マッチング手法は、単純な例を示したが、マッチング手法は、種々の方法を広く適用することができる。例えば、完全マッチングであっても良いし、第１の実施形態のようにマッチングするものを順に並べるというものであっても良い。
【０２４３】
また、マッチングテーブルをいくつも用意して、全てのマッチングテーブルに関して計算を予め行っておいて、ユーザが指定する条件の結果のみを表示するという応用も可能である。
【０２４４】
（Ｂ−４）対話と検索の連動とは、「ユーザから取得された値によって検索し、その検索結果によって、さらに必要な情報をユーザに質問する」のように、検索結果によって、対話内容が動的に変化するような仕組みを意味する。
【０２４５】
対話と検索の連動において、オントロジー、検索、意図解析の多次元化の仕組みを導入するようにしてもよい。
【符号の説明】
【０２４６】
１…対話型検索システム、１０…対話管理部、１１…対話制御部、
２０…意図解析部、２１…意図解析実行部、２２…意図解析用辞書、
２３…ドメイン知識辞書マネージャ、２１１…形態素解析部、２１２…構文解析部、
２３１…特徴抽出部、２３２…条件並替部、２３３…辞書設定部、
３０…ドメイン知識管理部、３１…ドメイン知識マネージャ、
３１１…特徴抽出部、３１２…条件抽出部、３１３…多次元オントロジー生成部、
３２…ドメイン知識ＤＢ、
４０…マッチング部、４１…マッチングマネージャ、４２…マッチャー、
５０…マッチン対象分析部、５１…ユーザデータ管理部、５２…対象データ管理部、
５３…拡張ユーザデータ、５４…拡張対象データ、
８０…データ提供サーバ、７０…Ｗｅｂサーバ、９０…ブラウザ。
【技術分野】
【０００１】
本発明は、検索システム及び検索プログラムに関し、例えば、対話の中で徐々に掘り下げた質問を繰り返すことにより、利用者のニーズや価値観を引き出し、多種多様でかつ大量のサービスやコンテンツの中から、利用者のニーズや価値観にマッチするものを検索する情報検索システムに適用し得るものである。
【背景技術】
【０００２】
ＩＴ（情報技術）を通じたコミュニケーションは、将来、テキスト情報から、個人の記憶する動画像や会話、放送映像や映画映像、商品情報やセンサー情報、生産履歴や交通履歴、刻一刻と変化する地理・気候情報等の様々な情報媒体に対象を広げ、その利用局面も、情報家電、車載端末、電子タグや、公共交通機関、企業の生産・流通現場、市場の店頭等の様々な局面へとダイナミック拡大していくことが予想される。
【０００３】
その契機となるのは、現在のパソコンによるホームページの中だけのテキスト中心の情報検索ではない、個人の生活、ビジネス等のあらゆる局面での新たなコミュニケーションニーズに応える次世代の情報検索・解析技術である。
【０００４】
従来の情報検索・解析技術は、キーワードの入力を受け付け、ネットワーク上の情報から入力キーワードと一致する情報を検索し、ヒット件数が多い順から紹介するというのが一般的である。この他にも、入力キーワードと一緒に使われるキーワードも表示するキーワード自動拡張技術や、多くのユーザによる口コミ情報から商品等をレコメンドする技術等もある。
【０００５】
しかしながら、上記のような技術によれば、当該利用者は入力キーワードを含む多くの情報を検索することができるが、これらの情報は、多くの他ユーザにより検索された結果を統計的にまとめた情報であって、当該利用者の真のニーズや希望する個別化された情報ではない。
【０００６】
また、情報過多の時代において、情報量の爆発的な増加に対応しきれず、情報選択基準を見失い易くなっている人が増えているという現状がある。自らの欲する情報や行動を決めきれないという問題を抱えるユーザに対して、単なる検索だけではなく、検索に至るまでの考え方をシステムが一緒に探るという情報検索・解析技術が求められている。
【０００７】
これに対して、本願発明者は、対話の中で、徐々に掘り下げた質問を繰り返すことにより、利用者のニーズや価値観を引き出すラダリング手法を活用し、利用者とシステムとが対話を繰り返すことにより、利用者が自ら表現することが困難であったサービスやコンテンツに関するニーズを引き出し、多種多様でかつ大量のサービスやコンテンツの中からこれにマッチングするものを検索する情報検索・解析技術を提案する（特願２００８−０３６３４２、特願２００８−０３６３５６）。
【０００８】
この対話型検索システムでは、ドメイン知識に基づいて質問文を生成して利用者に提示し、利用者からの回答を意図解析によって意味レベルで解釈し、その利用者から引き出した情報及び予め検索対象解析（例えば、利用者の回答から解釈したいと解析結果）と、検索対象データを解析した結果とマッチングすることにより検索を実現している。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】溝口理一郎他２名，「オントロジー工学基礎論−意味リンク、クラス、関係、ロールのオントロジー的意味論−」，人工知能学会誌，Ｖｏｌ．１４，ｐｐ．１０１９−１０３２，１９９９年
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ところで、対話型検索システムにおいて、徐々に掘り下げた質問を繰り返して利用者の真のニーズや希望を引き出すためには、（１）意思決定プロセスを支援すること、（２）ユーザ本人だけでは言語化しきれていない「気付き」の促し、（３）情報の選択基準を正確に認識することが重要となる。
【００１１】
つまり、対話型検索システムでは、利用者一人一人に応じたパーソナライズが動的に行われることや、利用者の発言に対して、寄り添い感を与える応答や対話の流れや、様々な状況変化に応じて質問すべき事柄の重要度は刻々と変化するから、これに応じて、質問文を提示することやマッチングを行うことが求められる。
【００１２】
非特許文献１には、オントロジーの意義に関して記載されている。オントロジーとは、特定の領域についての知識、複数の領域にまたがる知識、あるいは、汎用の知識を定義し、体系化したものである。ここで、知識とは、用語・語彙とその意味、他の用語・語彙との関係を示し、領域とは、医学、工学、不動産、自動車、金融などの分野を指す。
【００１３】
オントロジーは、語の概念や、語と語の関係を体系的に表現することができるので、対話型検索システムにおいては、ドメイン毎にオントロジーで記述したものを、ドメイン知識として利用することが考えられる。
【００１４】
これにより、オントロジーを利用した質問文を提示することができ、またこの質問文に対する回答を関連付けることができるので、利用者の回答（入力）を理解することができたり、それまでの対話のモデル化が簡易になる。
【００１５】
しかしながら、現行のオントロジーは、語の概念や語と語の関係を表す際、１つの観点からの語の概念や語と語の関係しか表現することができない。
【００１６】
そのため、情報の選択基準を正確に解析し、ユーザの意図や状況に応じて選択基準を切り替ていき、その切り替えた選択基準を使って正しく検索することができないという問題が生じ得る。
【００１７】
例えば、情報検索を行う者が人間であれば、ユーザからの情報を無視して、マッチングしない条件を提示することはない。例えば、求人側が求める資格・スキルに「Ｊａｖａ経験３年以上」というものがあるとする。この場合に、ユーザがプログラム言語「Ｊａｖａ」に関する保有資格を有していても、経験年数が３年以上の条件を満たしていなければ、その求人を提示することはない。
【００１８】
これは、人間が正しくユーザの意図を解析して、ユーザの意図や状況に応じて選択基準を切り替えているからである。しかし、従来の対話型検索システムは、ユーザの意図や状況に応じて動的に選択基準の切り替えることができない。
【００１９】
本発明は、上記課題に鑑みて、多次元オントロジーという考え方を利用する。ユーザの回答から対象データを検索する場合、ユーザの回答が対象データのどの検索キーに対応するか、また、その対応度の大小を記入するマッチングテーブルが必要となる。このマッチングテーブルは、語と語の関係を示すネットワークとして表現され、オントロジーで表現可能である。したがって、このマッチングテーブルをオントロジーとみなして、マッチングテーブルをユーザの意図や状況に応じて動的に切り替えることにより、ユーザの発言からユーザの意図を正確に解析し、ユーザの意図や状況に応じて、検索に必要な条件や選択基準を動的に切り替えることができる検索システム及び検索プログラムを提供する。
【課題を解決するための手段】
【００２０】
かかる課題を解決するために、第１の本発明の検索システムは、検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索システムにおいて、（１）検索対象とする１又は複数の対象データを格納する対象データ格納手段と、（２）条件の組み合わせという次元によって重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、（３）条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、（４）次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と、（５）検索する値が条件として設定されると、次元別マッチングテーブル格納手段から、条件に合う各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段と、（６）取り出された各次元別マッチングテーブルのうち、次元優先度格納手段の次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段と、（７）多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段とを備えることを特徴とする。
【００２１】
第２の本発明の検索プログラムは、検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索プログラムにおいて、（１）検索対象とする１又は複数の対象データを格納する対象データ格納手段と、（２）条件の組み合わせという次元によって重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、（３）条件なしの時の重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、（４）次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段とを備え、コンピュータを、（５）検索する値が条件として設定されると、次元別マッチングテーブル格納手段から、条件に合う各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段、（６）取り出された各次元別マッチングテーブルのうち、次元優先度格納手段の次元優先度に従って次元優先度の低いものから順に、各次元別マッチングテーブルの内容を基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段、（７）多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段として機能させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、多次元オントロジーを利用することにより、ユーザの発言からユーザの意図を正確に解析し、ユーザの意図や状況に応じて、検索に必要な条件や選択基準を動的に切り替えることができる。
【図面の簡単な説明】
【００２３】
【図１】第１の実施形態の対話型検索システムの全体構成を示す全体構成図である。
【図２】多次元オントロジーの基本概念を説明する説明図である（その１）。
【図３】多次元オントロジーの基本概念を説明する説明図である（その２）。
【図４】第１の実施形態の対話制御システムの全体の流れを示すフローチャートである。
【図５】プロパティ定義（表形式）を説明する説明図である。
【図６】プロパティ定義（ネットワーク形式）を説明する説明図である。
【図７】第１の実施形態の多次元オントロジー作成処理を示すフローチャートである。
【図８】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図９】次元の優先度を示す次元リストを説明する説明図である。
【図１０】次元優先度定義テーブルを説明する説明図である。
【図１１】多次元オントロジーの生成処理を説明する説明図である。
【図１２】第１の実施形態の検索処理と連動した対話制御処理を示すフローチャートである。
【図１３】第１の実施形態の多次元オントロジーを利用したマッチング処理を示すフローチャートである。
【図１４】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図１５】ベース次元のマッチングテーブルを説明する説明図である。
【図１６】「／人間／パーソナリティ／現在の職種＝コック」次元のマッチングテーブルを説明する説明図である。
【図１７】多次元化したマッチングテーブルを説明する説明図である。
【図１８】ドメイン知識マネージャが取得したユーザデータを説明する説明図である。
【図１９】「／人間／パーソナリティ／現在の職種＝ＳＥ」次元のマッチングテーブルを説明する説明図である。
【図２０】多次元化したマッチングテーブルを説明する説明図である。
【図２１】マッチング処理に係る対象データ及び類似度を説明する説明図である。
【図２２】マッチング処理に係る対象データ及び類似度を説明する説明図である。
【図２３】第１の実施形態の多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係る意図解析部における処理を示すフローチャートである。
【図２４】第１の実施形態の多次元意図解析処理に係るドメイン知識管理部における処理を示すフローチャートである。
【図２５】多次元意図解析処理における意図解析結果を説明する説明図である。
【図２６】ドメイン知識辞書マネージャが取得したユーザデータを説明する説明図である。
【図２７】ドメイン知識辞書マネージャが多次元化したドメイン知識辞書を説明する説明図である。
【図２８】各次元のドメイン知識辞書を説明する説明図である。
【図２９】多次元意図解析処理による意図解析結果を説明する説明図である。
【図３０】第１の実施形態の多次元意図解析処理（解析対象文の動的切替処理）にいて、意図解析部が取得した対象データを説明する説明図である。
【図３１】ドメイン知識辞書マネージャが多次元化したドメイン知識辞書を説明する説明図である。
【図３２】各次元の多次元構文辞書を説明する説明図である。
【図３３】多次元意図解析処理による意図解析結果を説明する説明図である。
【図３４】第１の実施形態のマッチング結果と連動した対話制御処理での対話制御部の処理を示すフローチャートである。
【図３５】第１の実施形態のマッチング結果と連動した対話制御処理でのマッチング処理を示すフローチャートである。
【図３６】対話制御部が取得したユーザデータを説明する説明図である。
【図３７】マッチング部が取得した対象データを説明する説明図である。
【図３８】「／人間／現在の職種＝プログラマ」次元のマッチングテーブルを説明する説明図である。
【図３９】ユーザデータと対象データとのマッチングを説明する説明図である。
【図４０】対話制御部が取得したユーザデータを説明する説明図である。
【図４１】ユーザデータと対象データとのマッチングを説明する説明図である。
【発明を実施するための形態】
【００２４】
（Ａ）第１の実施形態
以下では、本発明の検索システム及び検索プログラムの第１の実施形態について図面を参照しながら詳細に説明する。
【００２５】
第１の実施形態では、ユーザに対して質問を繰り返してユーザの真のニーズや希望を引き出すラダリングを利用した対話型検索システムに本発明を適用した実施形態を例示して説明する。
【００２６】
（Ａ−１）多次元オントロジーの基本概念
第１の実施形態において利用するマッチングテーブルは、語と語の関係を表したネットワーク構造で表現することができるため、オントロジーとみなすことができる。したがって、第１の実施形態では、多次元オントロジーの概念をマッチングテーブルに応用する。
【００２７】
まず、この多次元オントロジーの概念を、図面を参照しながら説明する。
【００２８】
多次元オントロジーとは、多数の意味空間を多次元化して保持し、対話で得られるユーザのデータ又は対象データ／状況に応じて、使用する意味空間を瞬時に切り替えることができるオントロジーをいう。
【００２９】
上述したように、現行のオントロジーは、ある１つの観点からしか語の概念や語と語の関係を表現していないので、現行のオントロジーを対話型検索システムに利用しても、静的なデータしか得られない。
【００３０】
そこで、第１の実施形態では、オントロジーを多次元化して保持できるようし、さらにユーザから引き出した情報が変化するたびに次元間を自動的に移動する仕組みを提案する。
【００３１】
これにより、対話で得られるユーザデータや状況に応じて瞬時に、意味空間を切り替えたり、対話のための情報を切り替えることができ、対話や検索がもつダイナミック性をシステムとして実現できる。また、次元間でデータを継承できるようにすることで、記述性とその省力性（最小限の記述）を同時に実現した。多次元化の最大の特徴である記述したいところだけを詳細に記述することができる。
【００３２】
図２及び図３は、多次元オントロジーの基本概念を説明する説明図である。図２及び図３では、第１の実施形態の対話型検索・解析システム１を職業紹介システムに利用した場合を例示する。
【００３３】
図２及び図３に示すように、多次元オントロジーは、それぞれプロパティが設定されている次元が、優先度に従って位置づけされており、ベースの次元と、ベース以外の特別な次元（以下、サブ次元という）とを有して構成される。
【００３４】
ベースの次元及びサブ次元には、それぞれ様々なオントロジーが定義されている。ベースの次元とは、最も優先度が低い次元であり、サブ次元に定義される全てのクラス及びプロパティが定義されているものである。また、サブ次元は、それぞれ必要なクラス及びプロパティだけが定義されており、条件の数が多いものほど優先度が高くなる。なお、条件の数が同数の場合には、例えば、開発者により予め優先度付けしておく。
【００３５】
例えば、図２及び図３では、ベースの次元を含めて６次元オントロジーを例示する。「業種＝ＩＴ」のサブ次元、「職種＝営業」のサブ次元、「職種＝ＳＥ」のサブ次元はそれぞれ、条件が１個であり、条件数が同数であるが、「業種＝ＩＴ」のサブ次元、「職種＝営業」のサブ次元、「職種＝ＳＥ」のサブ次元の順に優先度を高く設定したものとする。
【００３６】
また「職種＝営業＆＆業種＝ＩＴ（この表記は「職種が営業であり、かつ、業種がＩＴである」ことを示す、以下同様である）」のサブ次元、「職種＝ＳＥ＆＆業種＝ＩＴ」サブ次元はそれぞれ条件が２個であり、条件数が同数であるが、「職種＝営業＆＆業種＝ＩＴ」のサブ次元、「職種＝ＳＥ＆＆業種＝ＩＴ」の順に優先度を高く設定したものとする。
【００３７】
従って、これらの次元を重ねると、「ベースの次元」は優先度が最も低いので、次元の優先度は、「ベースの次元」→「業種＝ＩＴ」のサブ次元→「職種＝営業」のサブ次元→「職種＝ＳＥ」のサブ次元→「職種＝営業＆＆業種」のサブ次元→「職種＝ＳＥ＆＆業種＝ＩＴ」サブ次元の順に高くなる。
【００３８】
また、図２及び図３において、各サブ次元上の丸は、各サブ次元で定義されているクラス及びプロパティを示す。
【００３９】
図２は、ユーザから「何も（データを）取得していない時」を示す。この場合、まだ対話が進行していない。このとき、ベース次元に定義されているクラス及びプロパティ（図２には図示しない）を用いて対話進行する。
【００４０】
対話が進行して、ユーザから「業種＝ＩＴ」とする条件を取得したとする。この場合、図３に示すように、適用される次元は「業種＝ＩＴ」のサブ次元となり、この「業種＝ＩＴ」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
【００４１】
さらに対話が進行して、ユーザから「職業＝営業かつ業種＝ＩＴ」とする条件を取得したとする。この場合、図３に示すように、適用される次元は「職種＝営業＆＆業種＝ＩＴ」のサブ次元となり、この「職種＝営業＆＆業種＝ＩＴ」のサブ次元に定義されているクラス及びプロパティを用いた対話に切り替る。
【００４２】
ここで、対話に適用された次元は、「業種＝ＩＴ」と「職業＝営業かつ業種＝ＩＴ」の２個のサブ次元であり、適用された各サブ次元のクラス及びプロパティは、ベースの次元に上書きされて継承される。このとき、優先度の高いサブ次元のクラス及びプロパティが記憶されるように、優先度が低いサブ次元から順に継承される。つまり、ベースの次元には、「業種＝ＩＴ」のサブ次元のクラス及びプロパティが記憶されてから、「職業＝営業かつ業種＝ＩＴ」のサブ次元のクラス及びプロパティが上書きされる。
【００４３】
このように多次元オントロジーを用いることにより、次元間でデータを継承することができ、マッチングテーブルにおいても、対象データとユーザデータの対応関係や重要度などの値を次元間で継承することが可能となる。
【００４４】
（Ａ−２）第１の実施形態の構成
以下では、第１の実施形態の対話型検索システムの全体構成について、図１を参照しながら説明する。
【００４５】
図１において、第１の実施形態の対話型検索システム１は、対話管理部１０、意図解析部２０、ドメイン知識管理部３０、マッチング部４０、マッチング対象分析部５０を少なくとも有して構成される。
【００４６】
対話型検索システム１は、ユーザにデータを提供するデータ提供サーバ８０と接続しており、データ提供サーバ８０が保持する対象データを取得し、マッチング対象分析部５０の拡張対象データ５４に格納する。
【００４７】
ユーザは、ブラウザ９０を用いてＷｅｂサーバ７０にアクセスすることで、対話型検索システム１を起動させる。なお、ユーザ側のインターフェースとしては、通信機能を有するＰＣや携帯端末や専用端末など広く適用することができるが、ユーザが発した音声をテキスト変換する音声合成・認識部等を備えるようにしてもよい。
【００４８】
対話管理部１０は、検索を希望するユーザとの間の対話進行を管理するものであり、対話進行を制御する対話制御部１１を有する。
【００４９】
対話制御部１１は、ドメイン知識管理部３０から多次元オントロジーを受け取り、この多次元オントロジーに基づいて、対話進行に係る質問文（システム発話文ともいう）を作成するものである。
【００５０】
また、対話制御部１１は、質問文に対するユーザからの回答文（ユーザ発話文ともいう）を意図解析部２０に与えてユーザ発話文の内容を解析させるものである。なお、対話制御部１１は、ユーザ発話文の解析結果を受け取ると、そのユーザ発話文の解析結果をユーザデータとして、マッチング対象分析部５０の拡張ユーザデータ５３に格納する。
【００５１】
さらに、対話制御部１１は、意図解析部２０から意図解析結果を受け取ると、その意図解析結果をドメイン知識管理部３０に与えて、対話進行に利用する多次元オントロジーを生成させ、ドメイン知識管理部３０からの多次元オントロジーを利用して、次の質問文を決定して対話を進行させる。
【００５２】
また、対話制御部１１は、マッチング部４０に対してユーザのデータと対象データとのマッチングを指示するものである。このマッチングを指示するタイミングは、例えば、ユーザからのマッチング指示を受けたときや、各質問文に対する回答文が得られたときや、全ての質問項目が終了したときなどと種々のタイミングを設定することができる。
【００５３】
意図解析部２０は、対話制御部１１から取得した質問文に対してユーザが回答したユーザ発話文を受け取り、ユーザ発話文の内容を解析するものである。また、意図解析部２０は、解析した意図解析結果をオントロジー形式にして対話制御部１１に与える。さらに、意図解析部２０は、多次元意図解析処理として、ドメイン知識辞書の動的切替処理や解析対象文情報による動的切替処理を行うものである。
【００５４】
意図解析部２０は、意図解析実行部２１、意図解析用辞書２２、ドメイン知識辞書マネージャ２３を有する。
【００５５】
意図解析実行部２１は、意図解析用辞書２２を参照して、ユーザ発話文に対して形態素解析を行う形態素解析部２１１と、意図解析用辞書２２を参照して、ユーザ発話文に対して構文解析を行う構文解析部２１２を有する。
【００５６】
意図解析実行部２１は、ユーザ発話文に対して形態素解析や構文解析を行うことで、ドメイン知識ＤＢ３２のプロパティ定義に定義されるクラスを取得し、取得したクラスをドメイン知識管理部３０に与える。
【００５７】
意図解析用辞書２２は、ユーザ発話文の内容を解析するための辞書群であり、例えば、形態素辞書（例えば、日本語形態素辞書）、構文辞書（例えば、日本語構文辞書）、ベース次元及び各次元のクラス定義から自動生成されたドメイン知識辞書等が該当する。
【００５８】
ドメイン知識辞書マネージャ２３は、ユーザデータ管理から拡張ユーザデータを受け取り、この拡張ユーザデータに応じて、辞書引きする次元別ドメイン辞書の優先順位を並べ替え、その並べ替えた次元別ドメイン辞書を、意図解析辞書２２に設定するものである。
【００５９】
また、ドメイン知識辞書マネージャ２３は、データ提供サーバ８０からの対象データ（対象文情報）の解析結果を意図解析実行部２１から受け取り、対象データの内容に応じて、辞書引きする次元別構文辞書の並べ替えを行い、この並べ替えをした次元別構文辞書を、意図解析辞書２２に設定するものである。
【００６０】
ドメイン知識辞書マネージャ２３は、特徴抽出部２３１、条件並替部２３２、辞書設定部２３３を有する。
【００６１】
特徴抽出部２３１は、意図解析結果から次元の条件となる値が含まれている場合に、その次元条件の値を抽出するものである。条件並替部２３２は、特徴抽出部２３１が抽出した次元条件に対して、所定の優先順位に従って、次元別ドメイン辞書又は次元別構文辞書を並べ替えるものである。また、辞書設定部２３３は、条件並替部２３２により並べ替えられた次元別ドメイン辞書又は次元別構文辞書を意図解析用辞書２２に設定するものである。
【００６２】
ドメイン知識管理部３０は、ドメイン毎の多次元オントロジーを知識とするドメイン知識を管理するものである。ドメイン知識管理部３０は、ドメイン知識マネージャ３１、ドメイン知識ＤＢ３２を有する。
【００６３】
ドメイン知識ＤＢ３２には、多次元オントロジーを構築するためのベース次元及び各次元のプロパティ定義、クラス定義及び推論定義、多次元オントロジーを構成するための次元の条件、及び、次元の条件の優先度を定義する次元優先度定義テーブル、生成された多次元オントロジー、マッチングテーブルを格納するものである。
【００６４】
ドメイン知識マネージャ３１は、対話制御部１１から意図解析結果を受け取り、意図解析結果から特徴を抽出して、ドメイン知識ＤＢ３２のプロパティ定義及び次元優先度定義テーブルを参照しながら、多次元オントロジーを生成するものである。ドメイン知識マネージャ３１は、生成した多次元オントロジーをドメイン知識ＤＢ３２に格納するものである。
【００６５】
また、ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなし、多次元オントロジーを利用したマッチングテーブル（以下、多次元マッチングテーブルともいう）を生成するものである。マッチング部４０は、この多次元マッチングテーブルを参照しながら、マッチング処理を行う。
【００６６】
ドメイン知識管理部３０のドメイン知識マネージャ３１は、特徴抽出部３１１、条件照合部３１２、多次元オントロジー生成部３１３を有する。
【００６７】
特徴抽出部３１１は、ユーザ発話文の内容を解析した意図解析結果に、次元の条件となる特徴（次元条件にあたる値）がセットされているか否かを確認し、セットされている場合には、その特徴を抽出するものである。
【００６８】
ここで、ユーザデータ管理部５１が管理するユーザデータＤＢ５３は、対話制御部１１がユーザ発話から得られたユーザ情報を格納するものである。このユーザデータＤＢ５３には、ユーザ情報の格納場所（格納位置）を示すユーザデータパスと、ユーザ情報の値を示すユーザデータクラス名とを保持する。
【００６９】
条件照合部３１２は、特徴抽出部３１１が抽出した次元の値と次元優先度定義テーブルの内容を照合するものである。
【００７０】
多次元オントロジー生成部３１３は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ねて、多次元オントロジー又は多次元マッチングテーブルを生成するものである。
【００７１】
マッチング部４０は、ユーザデータ管理部５１に格納されるユーザデータと、対象データ管理部５０に格納される対象データとのマッチングを行い、ユーザが希望する条件のマッチングを行うものである。
【００７２】
マッチング部４０は、対話制御部１１から受け取った多次元マッチングテーブルをマッチャー４２に与えたり、マッチャー４２によりマッチングされた情報を対話制御部１１に与えたりするマッチングマネージャ４１と、ユーザデータと対象データとのマッチング処理を行うマッチャー４２とを有する。
【００７３】
マッチング対象分析部５０は、マッチング対象とするユーザデータや対象データを格納するものであり、マッチングしやすい形に拡張し、拡張したユーザデータ及び対象データを格納するものである。マッチング対象分析部５０は、ユーザデータ管理部５１、対象データ管理部５２、拡張ユーザデータ５３、拡張対象データ５４を有する。
【００７４】
（Ａ−３）第１の実施形態の動作
次に、第１の実施形態の対話型検索システム１における意図解析システムの動作について図面を参照しながら説明する。
【００７５】
（Ａ−３−１）全体動作
まず、対話型検索システム１における全体の流れについて図面を参照しながら説明する。
【００７６】
図４は、対話型検索システム１の全体の流れを示すフローチャートである。
【００７７】
対話型検索システム１を利用するユーザは、ブラウザ９０を用いて指定のＵＲＬにアクセスし、Ｗｅｂサーバ７０を通じて対話型検索システム１を起動する。
【００７８】
対話型検索システム１が起動すると、対話制御部１１が、ドメイン知識マネージャ３１を通じて、ドメイン知識ＤＢ３２に格納されるプロパティ定義を参照し、現在のポインタを定義域に持つプロパティで最も優先度が高いプロパティを選択する。
【００７９】
ここで、図５は、プロパティ定義の構成を示す構成図であり、図６は、プロパティ定義の一部をネットワーク形式で示した図である。
【００８０】
図５に示すプロパティ定義は、多次元のベースとなるプロパティ定義の例であり、例えば、「人間」を頂点として、各クラスのプロパティ関係を記述したものである。また、各プロパティが有する対話戦略やシステム発話に関するオプション情報を記述し、システムがどのような質問をどの順番でするかを規定する。
【００８１】
図５において、プロパティ定義は、定義域、プロパティ、値域、オプション情報の項目を有する。また、オプション情報には、必須の質問かどうかを決定する度合いを示す重要度、質問の順序（すなわち対話の流れ）を決定する度合いを示す優先度が設けられている。
【００８２】
さらに、オプション情報には、システム１が生成する基本質問文が定義されている。なお、図５には、オプション情報には、質問文の前に生成するつなぎ文、意図解析結果に基づき生成する各種受け止め文など、システムが円滑に対話を進行するための各種機能が定義されている。
【００８３】
また、オプション情報には、プロパティの種類が記述されており、例えば、グループ、取得対象がある。なお、ここではプロパティの種類を２種類の場合を例示したが、これに限定されることなく、設定することができる。
【００８４】
プロパティの種類が「取得対象」の場合、ドメイン知識マネージャ３１は、基本質問文の項目に設定されている基本質問文を対話制御部１１に与え、対話制御部１１が、これをシステム発話文としてＷｅｂサーバ７０を通じてユーザ側に送信する。
【００８５】
一方、プロパティの種類が「グループ」の場合、ドメイン知識マネージャ３１は、その値域クラスを定義域に持つプロパティを探索して選択する。このとき、この値域クラスを定義域とするプロパティが複数個ある場合、ドメイン知識マネージャ３１は、オプション情報の優先度を見て、最も優先度が高いプロパティを選択するようにする。そして、この選択したプロパティが「取得対象」ならば、ドメイン知識マネージャ３１は、その基本質問文を対話制御部１１に与えて、対話制御部１１が、これをシステム発話文としてユーザ側に送信する。
【００８６】
このように、プロパティの種類がグループの場合に、優先度を利用することで、値域クラスを定義域に持つプロパティへの移行を実現することができる。
【００８７】
図６は、図５に示すプロパティ定義の一部をネットワーク形式に展開した構成図である。
【００８８】
図６において、丸はクラス（すなわち、図５の定義域及び値域）を示し、クラスとクラスとの間を結ぶ線はプロパティを示す。
【００８９】
例えば、図６おいて、「人間」を頂点とし、プロパティを「パーソナリティ」とする場合の値域は「パーソナリティ」であり、プロパティを「強み」とする場合の値域は「仕事に活かせる強み」であり、プロパティを「転職をしようと思ったきっかけ」とする場合の値域は「転職理由」であり、プロパティを「仕事の経験」とする場合の値域は「現在の仕事」である。
【００９０】
また、例えば、「パーソナリティ」を定義域とする場合にも、上記と同様に、例えばプロパティを「サイト訪問目的」とする場合の値域は「サイト訪問目的」である等の関係を持つ。また、「パーソナリティ」と「サイト訪問目的」等とはｈａｓ ｐａｒｔの関係にあり、「サイト訪問目的」とユーザの回答である「適職を知りたい」とはｉｓ Ａの関係にある。
【００９１】
システム開始時の場合、プロパティ定義では、初期値として選択する定義域が設定されている。図５の第１段目の定義域クラス「人間」に対してポインタが設定されている。
【００９２】
従って、ドメイン知識マネージャ３１は、初期のポインタが指す定義域クラス「人間」のプロパティで最も優先度が高い「パーソナリティ」とする場合の値域クラス「パーソナリティ」を見る。
【００９３】
このとき、この値域クラス「パーソナリティ」のプロパティの種類は「グループ」であるから、ドメイン知識マネージャ３１は、値域クラス「パーソナリティ」を定義域とするプロパティのうち、優先度が最も高い定義域クラス「パーソナリティ」−プロパティ「サイト訪問目的」−値域クラス「サイト訪問目的」のプロパティに選択する。
【００９４】
そして、ドメイン知識マネージャ３１は、このプロパティの基本質問文である「このサイトに来た目的を教えて下さい」を対話制御部１１に与えて、対話制御部１１がこの基本質問文をシステム発話としてユーザ側に送信する。このようにして、システムからの質問を開始する（ステップＳ１０１）。
【００９５】
このシステム発話文を受信したユーザは、例えば「自分の適職が何かを知りたいので」と回答し、これを回答文としてＷｅｂサーバ７０を通じて対話制御部１１に送信する（ステップＳ１０２）。
【００９６】
対話制御部１１は、ユーザ発話文を受信すると、このユーザ発話文を意図解析部２０に与える。意図解析部２０では、意図解析実行部２１が、意図解析用辞書２２を用いて、ユーザ発話文に対して、形態素解析や構文解析を行い、その結果「適職を知りたい」というユーザの意図を解析し、その意図解析結果を対話制御部１１に与える（ステップＳ１０３）。
【００９７】
このとき、意図解析部２０の意図解析結果は、ドメイン知識マネージャ３１に与えられ、ドメイン知識マネージャ３１により多次元オントロジーが生成され、生成された多次元オントロジーがドメイン知識ＤＢ３２に記憶される。
【００９８】
対話制御部１１は、意図解析部２０からの意図解析結果を受け取ると、ドメイン知識マネージャ３１に対して次の質問の問い合わせを行い、次の質問を決定する（ステップＳ１０４）。
【００９９】
このとき、ドメイン知識マネージャ３１は、プロパティ定義を参照し、値域クラス「サイト訪問」の次に優先度が高い、定義域クラス「パーソナリティ」−プロパティ「現在の職種」−値域クラス「職種」に移行して、基本質問文「現在のあなたの職種は何ですか？」を対話制御部１１に与え、対話制御部１１がこれをシステム発話文として決定してユーザ側に送信する（ステップＳ１０５）。
【０１００】
このように、次の質問文の提示とユーザからの回答文の受信とを繰り返し行うことで、システムとユーザとの間の対話が実現される。
【０１０１】
なお、検索処理は、対話制御処理（Ｓ１０４）内で処理され、ユーザからの検索要求を対話制御部１１が受け取ると、検索結果が表示される（詳細は、Ａ−３−４に記載）。
【０１０２】
なお、ステップＳ１０４において、次の質問が決定されなかった場合、すなわち全ての質問が終了した場合、システムの動作は終了する。
【０１０３】
（Ａ−３−２）ドメイン知識マネージャ処理
次に、ドメイン知識マネージャ３１における多次元オントロジーの作成処理の詳細について図面を参照しながら説明する。
【０１０４】
ここでの例は、対話制御におけるドメイン知識マネージャ３１の処理を説明するものであるが、本動作は、マッチングテーブルをオントロジーとみなして処理する場合も基本動作は同じである。
【０１０５】
図７は、ドメイン知識マネージャ３１における多次元オントロジーの作成処理の動作を示すフローチャートである。
【０１０６】
ドメイン知識マネージャ３１は、対話制御部１１から意図解析結果を受け取る。また、ドメイン知識マネージャ３１は、当該ユーザのユーザデータをユーザデータ管理部５１から取得する（ステップＳ２０１）。
【０１０７】
例えば、対話制御部１１からの意図解析結果が、「／人間／パーソナリティ／現在の職種＝営業」とする。
【０１０８】
また、ユーザデータ管理部５１からの当該ユーザのユーザデータが、図８に示す内容であるとする。図８に示すように、ユーザデータは、オントロジー形式で記述されている。図８の場合、当該ユーザのユーザデータとしては、プロパティ「ニックネーム」のクラスがクラス「○ちゃん」であり、同様に、プロパティ「転職活動のステージ」−クラス「履歴書送付」、プロパティ「ライフイベント」−クラス「リストラ・倒産」、プロパティ「現在の業種」−クラス「医薬品」、プロパティ「現在の職種」−クラス「営業」であるとする。
【０１０９】
なお、ユーザデータは、説明便宜上のため、ユーザの回答から得られたプロパティに対するクラスをデータとする場合を示すが、例えば、ユーザの回答クラスから推論された新たなクラスをデータとする等、ユーザデータを拡張した内容であってよい。
【０１１０】
ドメイン知識マネージャ３１の特徴抽出部３１１が、ユーザデータと、ドメイン知識ＤＢ３２に登録されている全ての次元の条件と照合し、条件に合う次元条件を抽出する（ステップＳ２０２）。つまり、特徴抽出部３１１は、ユーザデータに全ての次元の条件となる値が含まれているか否かを確認し、条件となる値がある場合には、その次元の条件となる値を抽出する。
【０１１１】
例えば、ドメイン知識ＤＢ３２に格納されている次元の条件として、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」があるとする。
【０１１２】
特徴抽出部３１１は、上記のような次元の条件とマッチングして、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」という特徴をユーザデータから抽出する。
【０１１３】
次に、条件照合部３１２は、特徴抽出部３１１が抽出した次元の条件となる値を、所定の優先度の高い順に並べ替え（ステップＳ２０３）、次元の条件となる値の有無を確認して、次元優先度定義テーブルに格納する（ステップＳ２０４）。
【０１１４】
このとき、例えば、次元の条件の数が多いものを優先度が高くする。また、次元の条件の数が同じ場合には、事前に次元毎の優先度を設定しておき、この優先度に基づいて並べ替えをする。
【０１１５】
例えば、特徴抽出部３１１が抽出した次元の条件の値のうち、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」は条件数が２個であるから、最も優先度が高い。
【０１１６】
次に、「／人間／パーソナリティ／現在の職種＝営業」と「／人間／パーソナリティ／現在の業種＝医薬品」とは、次元の条件の数が１個であり、同数である。
【０１１７】
そこで、条件照合部３１２は、例えば、図９に示す次元リストを参照して、各次元の条件の値の優先度を確認し、この次元リストに従って各次元の条件の値をソートする。
【０１１８】
図９の次元リストでは、上に記述されているものほど優先度が高い。例えば、「／人間／パーソナリティ／ライフイベント」は、「／人間／パーソナリティ／現在の職種」よりも優先度が高い。また、次元を表すパスが同じ場合、「／人間／パーソナリティ／現在の職種＝営業」は、「／人間／パーソナリティ／現在の職種＝ＳＥ」よりも優先度が高い。
【０１１９】
従って、「／人間／パーソナリティ／現在の職種＝営業」と「／人間／パーソナリティ／現在の業種＝医薬品」について、条件照合部３１２は、「／人間／パーソナリティ／現在の職種＝営業」が「／人間／パーソナリティ／現在の業種＝医薬品」より優先度が高くなるように並べ替える。
【０１２０】
その結果、図１０に示すように、「／人間／パーソナリティ／ライフイベント＝リストラ・倒産＆＆／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の職種＝営業」、「／人間／パーソナリティ／現在の業種＝医薬品」の順にソートされる。
【０１２１】
次に、多次元オントロジー生成部３１３は、次元優先度定義テーブルの優先度に従って、次元別オントロジーを基本オントロジーに重ね合わせて多次元オントロジーを生成する（ステップＳ２０５）。
【０１２２】
図１１は、多次元オントロジーの生成処理を説明する説明図である。図１１（Ａ）は、ベース次元に定義されている職種クラス及びクラスオプションを示す。図１１（Ｂ）は、「業種クラス＝医薬品」の次元の職種クラス及びクラスオプションの定義を示す。
【０１２３】
多次元オントロジー生成部３１３は、図１１（Ａ）のベース次元に定義されている職種クラス及びクラスオプションに対して、図１１（Ｂ）の「業種＝医薬品」の次元の職種クラス及びクラスオプションの内容を上書きする。
【０１２４】
このとき、図１１（Ａ）のベース次元の職種クラスでは、クラス「職種」−クラス「営業」のオプションの受け止め文が「営業のお仕事をされているんですね。」定義されているが、ステップＳ２０５の上書きにより、クラス「職種」−クラス「営業」のオプションの受け止め文が「競争の激しい業界でも営業は大変でしょう。」に書き換えされる。
【０１２５】
このように、多次元オントロジーによれば、ベース次元に定義されるクラスオプション定義の内容を変更することができる。これにより、例えばユーザの職種などに応じて適切な受け止め文を出力することができる。
【０１２６】
多次元オントロジー生成部３１３は、生成した多次元オントロジーを対話制御部１１に出力する（ステップＳ２０６）。なお、この生成された多次元オントロジーは、ドメイン知識ＤＢ３２に格納される。
【０１２７】
（Ａ−３−３）対話型検索処理における対話制御処理
次に、対話型検索処理における対話制御処理ついて、図面を参照しながら詳細に説明する。
【０１２８】
対話型検索処理における対話制御処理を行う前提として、ドメイン知識マネージャ３１は、データ提供サーバ８０から取得した対象データに対して、図７で説明した多次元オントロジー作成処理を行い、対象データの意図を解析し、拡張対象データ５４に格納する。
【０１２９】
図１２は、対話型検索処理における対話制御処理を示すフローチャートである。
【０１３０】
まず、意図解析部２０において、ユーザ発話文に対する意図解析が行われ、その意図解析結果が対話制御部１１に与えられると（ステップＳ３０１）、対話制御部１１は、意図解析結果を拡張ユーザデータ５３に格納する（ステップＳ３０２）。
【０１３１】
例えば、対話制御部１１は、「／人間／パーソナリティ／現在の仕事／経験年数＝５年」とする意図解析結果を拡張個人データ５３に格納する。
【０１３２】
次に、マッチング部２０は、マッチング処理を起動する。具体的には、ドメイン知識マネージャ３１が多次元マッチングテーブルを生成し、それを用いて、拡張ユーザデータから拡張対象データを検索し、最も検索類似度の高い対象データから順に並べ替える（ステップＳ３０３）。
【０１３３】
このように、ユーザとの対話を通じて、ユーザから得た全ての情報と、全対象データとの間の類似度を計算し、類似度の高い対象データから順にユーザに提示する。
【０１３４】
このとき、ユーザ側からマッチング結果の表示要求を受けた場合（ステップＳ３０４）、対話制御部１１は、マッチング部４０からマッチング結果を受け取り、マッチング結果をユーザ側に送信する（ステップＳ３０５）。
【０１３５】
一方、ユーザ側からの表示要求がない場合には（ステップＳ３０４）、対話制御部１１は、マッチング結果の送信を行わず、ステップＳ３０６に移行する。
【０１３６】
ステップＳ３０６では、対話制御部１１は、ドメイン知識マネージャ３１から多次元オントロジーを受け取り、次の質問（プロパティ）を決定する。そして、対話制御部１１は、次の質問文をユーザ側に送信して、処理を終了する（ステップＳ３０７）。
【０１３７】
（Ａ−３−４）多次元オントロジーを利用したマッチング処理
次に、図１２のステップＳ３０３における多次元オントロジーを利用したマッチング処理の詳細な動作について図面を参照しながら説明する。
【０１３８】
図１３は、多次元オントロジーを利用したマッチング処理の動作を示すフローチャートである。ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する処理である。
【０１３９】
まず、マッチング部４０は、ドメイン知識マネージャ３１に対して、マッチングテーブルの作成要求を行い、ドメイン知識マネージャ３１は、マッチングテーブルを一種のオントロジーとみなして、多次元マッチングテーブルを生成する（ステップＳ４０１）。
【０１４０】
マッチングテーブル作成要求を受けると、ドメイン知識マネージャ３１は、拡張ユーザデータ５３からユーザデータを全て取得する。
【０１４１】
ドメイン知識マネージャ３１の動作フローは、図７のＳ２０４が存在しないフローで表される。ドメイン知識マネージャ３１では、特徴抽出部３１１が、ユーザデータと全てのマッチングテーブルに登録されている全ての次元の条件とを照合し、条件に合う次元条件を抽出する（Ｓ２０２）。
【０１４２】
次に、ドメイン知識マネージャ３１では、条件照合部３１２が、特徴抽出部３１１により抽出された次元条件を、一定の基準に従って優先度の高いものから順に並べて、次元優先度定義テーブルに格納する（Ｓ２０３）。
【０１４３】
そして、多次元オントロジー生成部３１３が、次元優先度定義テーブルの優先度に従って、次元別マッチングテーブルをベース次元のマッチングテーブルに重ね合わせて、多次元マッチングテーブルを生成し（Ｓ２０５）、マッチング部４０に与える（Ｓ２０６）。
【０１４４】
例えば、図１４は、現在の職種がコックであるニックネーム「○ちゃん」のユーザデータ（ネットワーク形式）である。また、図１５は、ベース次元のマッチングテーブルの構成例を示す。
【０１４５】
なお、図１５（Ａ）は、ベース次元のマッチングテーブルを表形式で示したものであり、図１５（Ｂ）は、ベース次元のマッチングテーブルをネットワーク形式で示したものである。
【０１４６】
図１５において、ベース次元のマッチングテーブルは、「ユーザデータ」、「重要度」、「対象データ」を項目とする。項目「ユーザデータ」は、ユーザデータにおけるプロパティ（条件）を示す。項目「対象データ」は、対象データにおけるプロパティ（条件）を示す。項目「重要度」は、マッチングにおけるプロパティに対する重み付けを示す。
【０１４７】
図１５の例においては、「ユーザデータ＝現在の職種」及び「対象データ＝経験職種」が対応する関係にあり、その重要度が「０．５」であることを示す。
【０１４８】
ユーザデータと対象データとの関係でプロパティ名が異なっているが、これは、転職を募集する企業の募集要項（データ）の条件名（プロパティ名）と、これに対応するユーザから抽出する条件名（プロパティ名）とが異なるからである。
【０１４９】
また、特徴抽出部３１１による特徴抽出の際に参照した次元のマッチングテーブルを図１６に示す。
【０１５０】
図１６のマッチングテーブルは、「／人間／パーソナリティ／現在の職種＝コック」次元のマッチングテーブルである。なお、図１６（Ａ）は表形式で示したものであり、図１６（Ｂ）はネットワーク形式で示したものである。
【０１５１】
図１６に示す次元のマッチングテーブルでは、「現在の職種＝コック」であるから、調理に関連する資格を所有していることが重要であるから、所有する資格の重要度が「１．０」と高く定義されている。
【０１５２】
従って、多次元オントロジー生成部３１３は、図１５に示すベース次元のマッチングテーブルに、図１６に示す次元のマッチングテーブルを上書きする。その結果、図１７に示しように、「資格の重要度」が「１．０」に変更された、多次元マッチングテーブルを生成することができる。
【０１５３】
また別の例として、図１８に示すような、現在の職種が「ＳＥ」の「△くん」のユーザデータを取得した場合を説明する。
【０１５４】
この場合、特徴抽出部３１１による特徴抽出の際に参照した次元のマッチングテーブルを図１９に示す。
【０１５５】
図１９のマッチングテーブルは、「／人間／パーソナリティ／現在の職種＝ＳＥ」次元のマッチングテーブルである。なお、図１９（Ａ）は表形式で示したものであり、図１９（Ｂ）はネットワーク形式で示したものである。
【０１５６】
図１９に示す次元のマッチングテーブルでは、「現在の職種＝コック」であるから、所有する資格は重視されないが、経験年数が重視されるため、所有する資格の重要度が「０．１」と低く定義され、経験年数の重要度が「０．８」と高く定義されている。
【０１５７】
従って、多次元オントロジー生成部３１３は、図１５に示すベース次元のマッチングテーブルに、図１９に示す次元のマッチングテーブルを上書きする。その結果、図２０に示しように、資格の重要度が「０．１」、経験年数の重要度が「０．８」に変更された、多次元マッチングテーブルを生成することができる。
【０１５８】
次に、ドメイン知識マネージャ３１から多次元マッチングテーブルを受け取ったマッチング部４０は、この多次元マッチングテーブルに基づいて、全ての対象データとの類似度を計算する（ステップＳ４０２）。
【０１５９】
このとき、マッチング部４０は、多次元マッチングテーブルを利用したマッチングテーブルに記述されている「重要度」によって重み付けを行って類似度を計算する。
【０１６０】
そして、マッチング部４０は、類似度の高いものから順に対象データを並べ替えて、これをマッチング結果とする。
【０１６１】
例えば、上記の「○ちゃん」の例において、マッチング部４０は、図１７に示す多次元マッチングテーブルを受け取り、図２１（Ａ）の「Ａ社」、「Ｂ社」の対象データとの類似度を計算する場合を説明する。
【０１６２】
「Ａ社」の条件は「経験業種＝コック」、「保有資格＝調理師免許」、「経験年数＝１年以上」であるから、「○ちゃん」は、すべての条件にマッチする。従って、マッチング部４０は、「Ａ社」との類似度を「（１×０．５）＋（１×１．０）＋（１×０．５）＝２．０」と計算する（図２１（Ｂ）参照）。
【０１６３】
同様に、「Ｂ社」の条件は「経験業種＝コック」、「保有資格＝栄養士免許」、「経験年数＝５年以上」であるから、「○ちゃん」は、「保有資格」以外の条件にマッチする。従って、マッチング部４０は、「Ｂ社」との類似度を「（１×０．５）＋（０×１．０）＋（１×０．５）＝１．０」と計算する（図２１（Ｂ）参照）。
【０１６４】
従って、マッチング部４０は、図２１（Ｃ）のように、「Ａ社」「Ｂ社」の順にしてマッチング結果を出力する。
【０１６５】
また例えば、上記の「△くん」の例において、マッチング部４０は、図１９に示す多次元マッチングテーブルを受け取り、図２２（Ａ）の「Ｃ社」、「Ｄ社」の対象データとの類似度を計算する場合を説明する。
【０１６６】
「Ｃ社」の条件は「経験業種＝ＳＥ」、「保有資格＝初級シスアド」、「経験年数＝１年以上」であるから、「△くん」は、すべての条件にマッチする。従って、マッチング部４０は、「Ａ社」との類似度を「（１×０．５）＋（１×０．１）＋（１×０．８）＝１．４」と計算する（図２２（Ｂ）参照）。
【０１６７】
同様に、「Ｄ社」の条件は「経験業種＝コック」、「保有資格＝上級シスアド」、「経験年数＝５年以上」であるから、「△くん」は、「経験年数」以外の条件にマッチする。従って、マッチング部４０は、「Ｄ社」との類似度を「（１×０．５）＋（１×０．１）＋（０×０．８）＝０．６」と計算する（図２２（Ｂ）参照）。
【０１６８】
従って、マッチング部４０は、図２２（Ｃ）のように、「Ｃ社」「Ｄ社」の順にしてマッチング結果を出力する。
【０１６９】
（Ａ−３−５）多次元意図解析処理（ドメイン知識辞書の動的切替処理）
次に、多次元意図解析処理（ドメイン知識辞書の動的切替処理）について図面を参照しながら詳細に説明する。
【０１７０】
図２３は、多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係る意図解析実行部２１の処理を示すフローチャートである。また、図２４は、多次元意図解析処理（ドメイン知識辞書の動的切替処理）に係るドメイン知識辞書マネージャ２３の処理を示すフローチャートである。
【０１７１】
まず、図２３において、意図解析部２０は、対話制御部１１からユーザ発話文を受け取る（ステップＳ５０１）。
【０１７２】
意図解析部２０では、付属情報がある場合には、その付属情報をユーザデータとして拡張ユーザデータ５３にセットする（ステップＳ５０２）。
【０１７３】
またユーザ発話文が複数の文からなる場合、意図解析実行部２１は、一文単位に区切り（ステップＳ５０３）、形態素解析部２１１がユーザ発話文に対して形態素解析を行い（ステップＳ５０４）、構文解析部２１２が構文解析を行う（ステップＳ５０５）。
【０１７４】
さらに、意図解析実行部２１は、意図解析用辞書２２を参照して意図解析を行う。このとき、意図解析実行部２１は、ユーザデータをドメイン知識辞書マネージャ２３に与える（ステップＳ５０６）。
【０１７５】
図２４において、意図解析実行部２１からユーザデータを受け取ると（ステップＳ６０１）、ユーザドメイン知識辞書マネージャ２３は、特徴抽出部２３１が、ユーザデータと各次元の次元条件と照合し、次元条件に合う値を抽出する（ステップＳ６０２）。
【０１７６】
条件並替部２３２は、特徴抽出部３１１が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え（ステップＳ６０３）、辞書設定部２３３が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書２２にセットする（ステップＳ６０４）。
【０１７７】
そして、図２３のステップＳ５０７では、意図解析部２０は、ドメイン知識辞書マネージャ２３によりセッティングされた順序で次元別ドメイン知識辞書から辞書引きを行い、ユーザとの対話から得られた情報に応じた意図を生成する（ステップＳ５０７）。
【０１７８】
例えば、図２５〜図２９を用いて、「○ちゃん」に対する、現住所に関する質問についてのユーザ発話文が「三田です」である場合の意図解析を例示して説明する。
【０１７９】
まず、システム起動前に、「住所」クラスのクラス定義に従って、図２８（Ａ）〜図２８（Ｃ）に示すような次元別ドメイン知識辞書を自動生成しておく。
【０１８０】
例えば、図２８（Ａ）は、「／人間／パーソナリティ／勤め先住所＝大阪」次元の「住所」クラスを定義した次元別ドメイン知識辞書であり、上位の階層を「住所」クラスとした場合、「住所」クラスの配下に「大阪」クラスがあり、「大阪」クラスの配下に「高槻市」クラス、「茨木市」クラス、…がある。また、「高槻市」クラス、「茨木市」クラス、…の異表記も併記したものである。
【０１８１】
同様に、図２８（Ｂ）は、「／人間／パーソナリティ／勤め先住所＝関西」次元の「住所」クラスを定義したドメイン知識辞書であり、図２８（Ｃ）は、「／人間／パーソナリティ／勤め先住所＝東京」次元の「住所」クラスを定義したドメイン知識辞書である。
【０１８２】
図２６に示すユーザデータがドメイン知識辞書マネージャ２３に与えられると、ドメイン知識辞書マネージャ３２では、特徴抽出部２３１が、ユーザデータから特徴抽出を行い、プロパティ「勤め先場所」−クラス「大阪」を抽出する。
【０１８３】
条件並替部２３２は、特徴抽出部２３１が抽出したプロパティ「勤め先場所」−クラス「大阪」を条件に合う次元別ドメイン知識辞書を選択し、所定の優先順位に従って次元別ドメイン知識辞書の並べ替えを行う。この次元別辞書の並べ替えにより、優先順位の高い次元別ドメイン知識辞書から辞書引きできるようにする。
【０１８４】
このとき、条件並替部２３２は、特徴抽出部２３１がプロパティ「勤め先場所」−クラス「大阪」の条件に合う、図２８（Ａ）の次元別ドメイン知識辞書が一番高い優先順位とし、「大阪」クラスの上位階層のクラスである「関西」クラスのドメイン知識辞書を次に高い優先順位として並べ替える。
【０１８５】
これにより、条件並替部２３２は、図２７に示すように、特徴抽出部２３１の抽出条件から、図２８（Ａ）の「／人間／パーソナリティ／勤め先住所＝大阪」次元のドメイン知識辞書、図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書の順に並べ替えを行う。このとき、図２８（Ｃ）の「／人間／パーソナリティ／勤め先住所＝関東」次元のドメイン知識辞書は、図２６のユーザデータの条件に適合しないので使われない。
【０１８６】
そして、例えばシステム発話文「おすまいはどちらですか？」に対するユーザ発話文「三田です」を意図解析部２０が受け取る。
【０１８７】
意図解析実行部２１では、形態素解析部２１１がユーザ発話文「三田です」に対して形態素解析を行い、形態素解析結果「三田：名詞 だ：助動詞」を得て、構文解析部２１２が構文解析を行い、図２５に示すような構文解析結果を得る。
【０１８８】
そして、意図解析実行部２１は、図２７に示すように、図２８（Ａ）の「／人間／パーソナリティ／勤め先住所＝大阪」次元のドメイン知識辞書を用いて解析し、次に優先順位の高い図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書を用いて解析する。
【０１８９】
その結果、図２８（Ｂ）の「／人間／パーソナリティ／勤め先住所＝関西」次元のドメイン知識辞書を用いて、構文解析結果「住所−三田」に対応する「住所−三田市」を辞書引きして、当該ユーザの現住所が兵庫県の「三田市」であるとの意図解析結果を得て、これを出力する（図２９参照）。このようにユーザから既に与えられている条件を利用することによって、三田という言葉における、兵庫県の三田市（さんだし）と東京の三田（みた）という曖昧性を解消することができる。
【０１９０】
（Ａ−３−６）多次元意図解析処理（解析対象文情報による動的切替処理）
次に、多次元意図解析処理（解析対象文情報による動的切替処理）について図面を参照しながら説明する。
【０１９１】
解析対象文の動的切替処理とは、対象データから拡張対象データを構築する際の多次元意図解析処理である。
【０１９２】
解析対象文の動的切替処理は、図２３及び図２４に示すフローチャートを用いてできるので、ここでは、図２３及び図２４を参照しながら説明する。なお、図２３及び図２４において、「ユーザデータ」と記載は「対象データ」となる。
【０１９３】
図３０（Ａ）は、意図解析部２０に与えられる対象データを示す。意図解析部２０において、対象データには、「解析対象：対象データ」という付属情報が付される。従って、意図解析実行部２１は、対象データに「解析対象：対象データ」が付与される（ステップＳ５００１、Ｓ５０２）。
【０１９４】
また、対象データは複数の文からなるので、意図解析実行部２１は、対象データを１文単位に区切り（ステップＳ５０３）、対象データの各文に対して形態素解析を行い（ステップＳ５０４）、構文解析を行う（ステップＳ５０５）。
【０１９５】
例えば、対象データの一部である「ネットワーク設計経験者優遇。」という文については、図３０（Ｂ）に示すような構文解析結果を得る。つまり、「経験者待遇：名詞 設計：名詞 ネットワーク：名詞」という形態素解析結果から図３０（Ｂ）のような構文解析結果となる。
【０１９６】
意図解析実行部２１は、当該ユーザデータをドメイン知識辞書マネージャ２３に与える（ステップＳ５０６）。
【０１９７】
意図解析実行部２１からユーザデータを受け取ったドメイン知識辞書マネージャ２３では、特徴抽出部２３１が、ユーザデータと、次元別のマッチングテーブルに登録されている全ての次元条件と照合し、各次元条件に合う次元条件を抽出する（ステップＳ６０１、Ｓ６０２）。
【０１９８】
条件並替部２３２は、特徴抽出部２３１が抽出した次元条件に対して、一定の基準に従って、次元別ドメイン知識辞書を優先順位に並べ替え（ステップＳ６０３）、辞書設定部２３３が、所定の優先順位で辞書引きされるように次元別ドメイン知識辞書を意図解析用辞書２２にセットする（ステップＳ６０４）。
【０１９９】
例えば、ドメイン知識辞書マネージャ２３のドメイン知識ＤＢに、図３２（Ａ）及び図３２（Ｂ）に示すような多次元構文辞書がある場合、ドメイン知識辞書マネージャ２３は、特徴抽出部２３１の抽出条件から、一定の基準に従って、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書、図３２（Ｂ）のベース次元の構文辞書の順に並べ替えを行う。
【０２００】
その結果、ドメイン知識辞書マネージャ２３は、図３１に示すように、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書を一番最初に辞書引きできるようにし、一番優先度が低い位置にベース次元の構文辞書を設定する。
【０２０１】
そして、意図解析部２０は、図３２（Ａ）の「／解析対象＝対象データ」次元の構文辞書から辞書引きして、「経験職種＝ネットワーク設計者」とする意図解析結果を出力する（図３３参照）。
【０２０２】
（Ａ−３−７）マッチング結果と連動した対話制御処理
次に、マッチング結果と連動した対話制御処理について、図面を参照しながら詳細に説明する。
【０２０３】
図３４は、マッチング結果と連動した対話制御処理における対話制御部１１における処理を示すフローチャートである。図３５は、マッチング結果と連動した対話制御処理におけるマッチング処理を示すフローチャートである。
【０２０４】
検索処理と連動した対話制御処理を行う前提として、ドメイン知識マネージャ３１は、データ提供サーバ８０から取得した対象データに対して、対象データの意図を解析し、拡張対象データ５４に格納する。
【０２０５】
図３４において、対話制御部１１は、意図解析部２０から意図解析結果を受け取り（ステップＳ７０３）、ユーザデータとして拡張ユーザデータ５３に格納し（ステップＳ７０２）、マッチング処理を起動する（ステップＳ７０３）。
【０２０６】
例えば、ユーザ「○ちゃん」との対話によりユーザ発話文「Ｊａｖａのプログラムを５年ほどやっています。」に対する意図解析結果が、「／人間／仕事の経験／内容＝Ｊａｖａ、／人間／仕事の経験／年数＝５年」とする。
【０２０７】
また、図３６は、「○ちゃん」のユーザデータであるとし、対話制御部１１は、図３６に示すユーザデータを拡張ユーザデータ５３に格納する。
【０２０８】
マッチング部４０は、拡張対象データ５４に格納されるユーザデータに完全にマッチする全ての拡張対象データを取り出す（ステップＳ８０１）。
【０２０９】
例えば、図３７は、ユーザデータに完全にマッチする拡張対象データの例を示し、図３７（Ａ）は、「Ａ社」の求人データ（対象データ）であり、プロパティ「社名」−クラス「Ａ社」、プロパティ「使用言語」−クラス「Ｊａｖａ」、プロパティ「経験年数」−クラス「３年以上」、…である。また、図３７（Ｂ）は、「Ｂ社」の求人データ（対象データ）であり、プロパティ「社名」−クラス「Ｂ社」、プロパティ「使用言語」−クラス「Ｊａｖａ」、…である。
【０２１０】
マッチング部４０がドメイン知識マネージャ３１に対してマッチングテーブルの作成要求を行う（ステップＳ８０２）。
【０２１１】
このとき、ドメイン知識マネージャ３１は、（Ａ−３−４）で説明した処理と同様に方法で、多次元マッチングテーブルを生成し、これをマッチング部４０に与える。
【０２１２】
ここで、図３８は、マッチング部に与えられた多次元マッチングテーブルとする。
【０２１３】
マッチング部４０は、多次元マッチングテーブルに基づいて、全ての対象データに関して、ユーザデータとの類似度を計算し（ステップＳ８０３）、類似度の高いものから順に対象データを並び替える（ステップＳ８０４）。
【０２１４】
このとき、マッチング部４０は、最も高い類似度を持つ対象データに関して曖昧なマッチングがあるか否かを確認する（ステップＳ８０５）。
【０２１５】
ここで、曖昧なマッチングとは、対象データには条件となる値が存在するが、ユーザデータには条件となる値が存在しない場合のマッチングをいう。
【０２１６】
図３９は、図３８の多次元マッチンテーブルに基づいて、図３６の「○ちゃん」のユーザデータと、図３７（Ａ）の「Ａ社」の対象データとをマッチングした場合を説明する図である。
【０２１７】
図３９では、「Ａ社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Ｊａｖａ」、「経験年数−３年以上」がある。また、「○ちゃん」のユーザデータにも、上記の条件の値に対応する「プログラマ」、「Ｊａｖａ」、「５年」が存在している。従って、「○ちゃん」のユーザデータには、曖昧なマッチングは存在しないと判断する。
【０２１８】
なお、マッチング処理が終了すると、図３４のステップＳ７０４に移行するが、次の質問文がセットされていないので、ステップＳ７０５〜Ｓ７０８の処理を行う。なお、ステップＳ７０５〜Ｓ７０８は、図１２のステップＳ３０４〜Ｓ３０７に対応するので説明を省略する。
【０２１９】
一方、ユーザ「△くん」の場合、ユーザ発話文「Ｊａｖａ経験があります。」に対する意図解析結果が、「／人間／仕事の経験／内容＝Ｊａｖａ」であるとし、「△くん」のユーザデータは、図４０に示すようものとする。
【０２２０】
そして、図３８の「／人間／現在の職種＝プログラマ」次元のマッチンテーブルに基づいて、図４０の「△くん」のユーザデータと、図３７（Ａ）の「Ａ社」の対象データとをマッチングした場合を、図４１に示す。
【０２２１】
図４１に示すように、上記同様、「Ａ社」の対象データに条件する値として、「職種−プログラマ」、「使用言語−Ｊａｖａ」、「経験年数−３年以上」がある。
【０２２２】
しかし、「△くん」のユーザデータには、上記の条件の値に対応する「職種−プログラマ」、「使用言語−Ｊａｖａ」は存在するが、「経験年数−３年以上」に相当する条件の値が存在しない。
【０２２３】
そこで、マッチング部４０は、プロパティ「経験年数」に関する深堀質問をセットし、これをドメイン知識マネージャ３１に与える（ステップＳ８０６）。
【０２２４】
そして、ドメイン知識マネージャ３１は、プロパティ「経験年数」を次の質問文とするようにし、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」を対話制御部１１に与え、次の質問文が決定する。
【０２２５】
この場合、ステップＳ７０４に移行し、対話制御部１１には、次の質問文がセットされているので、プロパティ「経験年数」の基本質問文「具体的な経験年数を教えて下さい。」をユーザ側に出力する。
【０２２６】
このようにすることで、「△くん」との対話処理で、「経験年数」を質問することができ、例えば「５年です。」という回答が得られた場合、「Ａ社」の対象データとの類似度がより高くなり、「△くん」は、自分に合った会社を、より早く探すことができる。また、経験年数が「１年」であると回答を得た場合には、逆に自分が検討しても無駄な会社を、より早く候補外にすることができる。
【０２２７】
また、もし、「Ａ社」でなく、「Ｂ社」の場合には、経験年数を条件にしてないので、深堀質問はなされない。このように、検索結果となる対象データの状態に応じて、質問を自在に制御することができる。
【０２２８】
（Ａ−４）第１の実施形態の効果
以上、第１の実施形態によれば、多次元オントロジーを利用してマッチング処理を行うことにより、ユーザの意図や状況に応じて情報検索に係るマッチングの重要度を動的に変えることができるので、より的確なマッチングを行うことができる。
【０２２９】
また、第１の実施形態によれば、意図解析を多次元化することにより、ユーザの意図や状況に応じて、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。また、的確な選択基準を選択できるので、ユーザに対する質問やマッチングに係る検索対象も、ユーザの意図するものにすることができる。
【０２３０】
さらに、第１の実施形態によれば、対象データに関する情報によって、適用する辞書を動的に切り替えることができるので、的確な情報検索の選択基準を選択させることができる。
【０２３１】
また、第１の実施形態によれば、マッチング結果に連動させて対話制御を行うことで、対象データとのマッチングに必要な情報を次の質問文としてユーザに提示することができるので、より迅速かつ的確なマッチング処理を提供できる。
【０２３２】
（Ｂ）他の実施形態
（Ｂ−１）意図解析の多次元化とは、ユーザから取得された値によって、解析エンジン（解析時に利用する辞書）を動的に使い分けることを意味する。解析エンジンを動的に使い分ける仕組みは、対話制御がドメイン知識マネージャを通じて、オントロジーを動的に使い分ける仕組みを応用することで実現可能である。
【０２３３】
（Ｂ−２）意図解析を多次元化することにより、以下のようなことができる。
【０２３４】
（１）関西を希望している人が、「三田がいい」と発言したら「三田市」と返すことができる。また、関東を希望している人は、「東京の三田」を返すことができる。
【０２３５】
（２）口語で入力する人には、口語解析用エンジン、関西弁の人には、関西弁エンジンを使うことで、それぞれの解析精度が向上する。
【０２３６】
（３）プロデューサを希望する人とプログラマを希望する人では、「プログラムを作る」の意味が違うことが理解できるようになる。
【０２３７】
（４）正社員を希望する人は年収（又は月収）、パートの人は時給を給与のデフォルトにして解析することができる。
【０２３８】
（５）求人データ、ユーザ発話文の解析時には、それぞれ別の解析エンジンを使うことで、解析精度が向上する
（６）求人データは、通常、情報がタグ付けされている。そのタグの値毎に、辞書を使い分けることにより、精度高く解析できる。例えば、求人職種タグの場合は、「職種」の入力を前提とした辞書で解析する。「先輩ＰＲ」タグの場合は、社員が述べるような内容の入力を前提とした辞書で解析する。
【０２３９】
（Ｂ−３）検索の多次元化とは、ユーザから取得した値によって、検索の条件を動的に使い分けることを意味する。
【０２４０】
例えば、意図解析がなくても（例えば、アンケートのようにユーザからの回答が決まっているため、意図解析する必要ながなくても）同様の処理は勿論可能である。
【０２４１】
また、提示要求は、検索後であるとは限らず、いつでも検索しても良い。
【０２４２】
さらに、第１の実施形態では、マッチング手法は、単純な例を示したが、マッチング手法は、種々の方法を広く適用することができる。例えば、完全マッチングであっても良いし、第１の実施形態のようにマッチングするものを順に並べるというものであっても良い。
【０２４３】
また、マッチングテーブルをいくつも用意して、全てのマッチングテーブルに関して計算を予め行っておいて、ユーザが指定する条件の結果のみを表示するという応用も可能である。
【０２４４】
（Ｂ−４）対話と検索の連動とは、「ユーザから取得された値によって検索し、その検索結果によって、さらに必要な情報をユーザに質問する」のように、検索結果によって、対話内容が動的に変化するような仕組みを意味する。
【０２４５】
対話と検索の連動において、オントロジー、検索、意図解析の多次元化の仕組みを導入するようにしてもよい。
【符号の説明】
【０２４６】
１…対話型検索システム、１０…対話管理部、１１…対話制御部、
２０…意図解析部、２１…意図解析実行部、２２…意図解析用辞書、
２３…ドメイン知識辞書マネージャ、２１１…形態素解析部、２１２…構文解析部、
２３１…特徴抽出部、２３２…条件並替部、２３３…辞書設定部、
３０…ドメイン知識管理部、３１…ドメイン知識マネージャ、
３１１…特徴抽出部、３１２…条件抽出部、３１３…多次元オントロジー生成部、
３２…ドメイン知識ＤＢ、
４０…マッチング部、４１…マッチングマネージャ、４２…マッチャー、
５０…マッチン対象分析部、５１…ユーザデータ管理部、５２…対象データ管理部、
５３…拡張ユーザデータ、５４…拡張対象データ、
８０…データ提供サーバ、７０…Ｗｅｂサーバ、９０…ブラウザ。
【特許請求の範囲】
【請求項１】
検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索システムにおいて、
検索対象とする１又は複数の対象データを格納する対象データ格納手段と、
条件の組み合わせという次元によって上記重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、
条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、
上記次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と、
検索する値が条件として設定されると、上記次元別マッチングテーブル格納手段から、上記条件に合う上記各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段と、
取り出された上記各次元別マッチングテーブルのうち、上記次元優先度格納手段の上記次元優先度に従って上記次元優先度の低いものから順に、上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段と、
上記多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、上記対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段と
を備えることを特徴とする検索システム。
【請求項２】
対話に用いるドメイン知識を用いて、ユーザに対する質問を定めて質問を行い、その質問に対するユーザ回答を受け取り、上記ユーザ回答に応じた対話進行を行う対話制御手段と、
上記対話制御手段から上記ユーザ回答を受け取り、文の意図を解析する意図解析辞書を用いて、上記ユーザ回答に基づく意図解析を行う意図解析手段と
を備え、
上記次元別マッチングテーブル取出手段が、上記意図解析手段から上記ユーザ回答の意図解析結果を受け取り、上記意図解析結果が条件として設定され、この条件に合う１又は複数の上記次元別マッチングテーブルを上記次元別マッチングテーブル格納手段から取り出するものであり、
上記多次元マッチングテーブル生成手段が、取り出された上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、上記ユーザ回答の意図解析結果に応じて動的に変更された上記多次元マッチングテーブルを生成するものであり、
上記マッチング手段が、上記ユーザ回答の意図解析結果に応じて動的に変更された上記多次元マッチングテーブルを用いて、上記対象データ格納手段から、上記ユーザ回答の意図解析結果にマッチする１又は複数の対象データを検索するものである
ことを特徴とする請求項１に記載の検索システム。
【請求項３】
上記意図解析手段が、
条件の組み合わせという次元によって異なる次元別辞書を記憶する次元別辞書記憶部と、
条件なし時の基本辞書を記憶する基本辞書記憶部と、
前回までに取得した上記ユーザ回答の背景知識を条件として設定し、上記次元別辞書記憶部から上記条件に合う１又は複数の上記各次元別辞書を取り出す次元別辞書取出部と、
取り出された上記各次元別辞書のうち、上記条件に適用する順序の高いものから順に、上記各次元別辞書を並べ替える辞書並替部と、
上記辞書並替部により並べ替えられた上記各次元別辞書を意図解析用辞書として設定する辞書設定部と
を有し、
上記辞書設定部の設定した上記条件に適用する順序の高い上記次元別辞書から順に用いて、今回取得した上記ユーザ回答の意図解析を行う
ことを特徴とする請求項２に記載の検索システム。
【請求項４】
上記意図解析手段は、上記対象データについても意図解析を行い、その際に、上記ユーザ回答の背景知識を条件として設定する代わりに、解析対象のデータに存在する付属情報を予め読み込み、その付属情報を条件として設定することを特徴とする請求項２又は３に記載の検索システム。
【請求項５】
上記マッチング手段が、上記多次元マッチングテーブルを用いてマッチングを行う際に、検索する値にマッチする対象データの値うち、検索する値とのマッチングが不足している値がある場合、この不足している値を上記対話制御手段に与え、この不足している値に対するユーザ回答を取得するための深堀り質問を提示させるようにすることを特徴とする請求項２〜４のいずれかに記載の検索システム。
【請求項６】
検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索プログラムにおいて、
検索対象とする１又は複数の対象データを格納する対象データ格納手段と、
条件の組み合わせという次元によって上記重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、
条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、
上記次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と
を備え、
コンピュータを、
検索する値が条件として設定されると、上記次元別マッチングテーブル格納手段から、上記条件に合う上記各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段、
取り出された上記各次元別マッチングテーブルのうち、上記次元優先度格納手段の上記次元優先度に従って上記次元優先度の低いものから順に、上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段、
上記多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、上記対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段
として機能させることを特徴とする検索プログラム。
【請求項１】
検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索システムにおいて、
検索対象とする１又は複数の対象データを格納する対象データ格納手段と、
条件の組み合わせという次元によって上記重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、
条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、
上記次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と、
検索する値が条件として設定されると、上記次元別マッチングテーブル格納手段から、上記条件に合う上記各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段と、
取り出された上記各次元別マッチングテーブルのうち、上記次元優先度格納手段の上記次元優先度に従って上記次元優先度の低いものから順に、上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段と、
上記多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、上記対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段と
を備えることを特徴とする検索システム。
【請求項２】
対話に用いるドメイン知識を用いて、ユーザに対する質問を定めて質問を行い、その質問に対するユーザ回答を受け取り、上記ユーザ回答に応じた対話進行を行う対話制御手段と、
上記対話制御手段から上記ユーザ回答を受け取り、文の意図を解析する意図解析辞書を用いて、上記ユーザ回答に基づく意図解析を行う意図解析手段と
を備え、
上記次元別マッチングテーブル取出手段が、上記意図解析手段から上記ユーザ回答の意図解析結果を受け取り、上記意図解析結果が条件として設定され、この条件に合う１又は複数の上記次元別マッチングテーブルを上記次元別マッチングテーブル格納手段から取り出するものであり、
上記多次元マッチングテーブル生成手段が、取り出された上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、上記ユーザ回答の意図解析結果に応じて動的に変更された上記多次元マッチングテーブルを生成するものであり、
上記マッチング手段が、上記ユーザ回答の意図解析結果に応じて動的に変更された上記多次元マッチングテーブルを用いて、上記対象データ格納手段から、上記ユーザ回答の意図解析結果にマッチする１又は複数の対象データを検索するものである
ことを特徴とする請求項１に記載の検索システム。
【請求項３】
上記意図解析手段が、
条件の組み合わせという次元によって異なる次元別辞書を記憶する次元別辞書記憶部と、
条件なし時の基本辞書を記憶する基本辞書記憶部と、
前回までに取得した上記ユーザ回答の背景知識を条件として設定し、上記次元別辞書記憶部から上記条件に合う１又は複数の上記各次元別辞書を取り出す次元別辞書取出部と、
取り出された上記各次元別辞書のうち、上記条件に適用する順序の高いものから順に、上記各次元別辞書を並べ替える辞書並替部と、
上記辞書並替部により並べ替えられた上記各次元別辞書を意図解析用辞書として設定する辞書設定部と
を有し、
上記辞書設定部の設定した上記条件に適用する順序の高い上記次元別辞書から順に用いて、今回取得した上記ユーザ回答の意図解析を行う
ことを特徴とする請求項２に記載の検索システム。
【請求項４】
上記意図解析手段は、上記対象データについても意図解析を行い、その際に、上記ユーザ回答の背景知識を条件として設定する代わりに、解析対象のデータに存在する付属情報を予め読み込み、その付属情報を条件として設定することを特徴とする請求項２又は３に記載の検索システム。
【請求項５】
上記マッチング手段が、上記多次元マッチングテーブルを用いてマッチングを行う際に、検索する値にマッチする対象データの値うち、検索する値とのマッチングが不足している値がある場合、この不足している値を上記対話制御手段に与え、この不足している値に対するユーザ回答を取得するための深堀り質問を提示させるようにすることを特徴とする請求項２〜４のいずれかに記載の検索システム。
【請求項６】
検索する値と、この値に対応する対象データの値との対応関係及びその対応の重みを有するマッチングテーブルを用いて、検索対象とする対象データの中から、検索する値に対応する対象データを検索する検索プログラムにおいて、
検索対象とする１又は複数の対象データを格納する対象データ格納手段と、
条件の組み合わせという次元によって上記重みの異なる１又は複数の次元別マッチングテーブルを格納する次元別マッチングテーブル格納手段と、
条件なしの時の上記重みが設定された基本マッチングテーブルを格納する基本マッチングテーブル格納手段と、
上記次元毎の優先度を示す次元別優先度を格納する次元別優先度格納手段と
を備え、
コンピュータを、
検索する値が条件として設定されると、上記次元別マッチングテーブル格納手段から、上記条件に合う上記各次元別マッチングテーブルを取り出す次元別マッチングテーブル取出手段、
取り出された上記各次元別マッチングテーブルのうち、上記次元優先度格納手段の上記次元優先度に従って上記次元優先度の低いものから順に、上記各次元別マッチングテーブルの内容を上記基本マッチングテーブルに上書きして、入力された値から対象データを検索する多次元マッチングテーブルを生成する多次元マッチングテーブル生成手段、
上記多次元マッチングテーブル生成手段により生成された多次元マッチングテーブルを用いて、上記対象データ格納手段から検索する値にマッチする１又は複数の対象データを検索するマッチング手段
として機能させることを特徴とする検索プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【公開番号】特開２０１０−２６２３４４（Ｐ２０１０−２６２３４４Ａ）
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願番号】特願２００９−１１０６３８（Ｐ２００９−１１０６３８）
【出願日】平成２１年４月３０日（２００９．４．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成２０年度経済産業省情報大航海プロジェクト「モデルサービスの開発と実証」委託研究、産業技術力強化法第１９条の適用を受けるもの）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（０００１３９０１２）株式会社リクルート (20)
【Ｆターム（参考）】
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願日】平成２１年４月３０日（２００９．４．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成２０年度経済産業省情報大航海プロジェクト「モデルサービスの開発と実証」委託研究、産業技術力強化法第１９条の適用を受けるもの）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（０００１３９０１２）株式会社リクルート (20)
【Ｆターム（参考）】
[ Back to top ]