JP2005241952A - 知識処理装置、知識処理方法および知識処理プログラム - Google Patents

Abstract

【課題】ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答して、円滑かつ高速な対話処理を行うことを課題とする。
【解決手段】対話処理装置２０のドメイン化ＤＢ１４ｂは、ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けして記憶する。そして、対話処理装置２０は、ユーザの入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされてドメイン化ＤＢ１４ｂに記憶された流通言語語彙を、出力文に含める回答として特定する。
【選択図】 図１１

Description

この発明は、入力文を解析して当該入力文に対する出力文を出力する知識処理装置、知識処理方法および知識処理プログラムに関する。

従来より、予め定められた会話プログラムによって、人間の発した音声を音声認識によって認識した結果に基づいて、人間とコンピュータがあたかも人間同士で会話を行っているかのように対話処理を行う「音声対話」と呼ばれるものである。そして、この音声対話を利用して機械や装置を意志通りに操作するなど、その利用範囲は広く、多方面での応用研究がなされており、このような音声対話を行うために、以下に説明するように、データベースや音声認識技術等が研究されている。

例えば、音声対話に用いられるデータベースとして、リレーショナル型データベースや、オブジェクト指向型データベース、これらのデータベースを改良したデータベースが研究・開発されている（例えば、特許文献１）。これらは、例えば、一般に流布されている事例中の文章に対して単語解析および文章解析を行い、プロパティの分類名に従って、事例中の単語を分類して整理したデータベースであり、このデータベースによれば、事例中の莫大な単語を漏れなく整理することができる。

また、音声対話における音声認識としては、人間が普通に話す言葉をそのままの状態で頭から認識を行う「ディクテーション」や、人間が話した言葉の中からキーとなる単語を抽出して、その単語を認識していく「ワードスポット」など、種々の手法が用いられている。

このうち、「ディクテーション」では、まず人間が話した言葉を入力音声として音素列に変換し、その音素列を単語列に置き換えて構文解析した後に、文字列に変換する。さらに、論理解析や意味解析を行って文章を生成し、音声合成して出力する。なお、単語にも同音異義語があるので、ここでは、各単語の属性情報を付すなどして的確な認識を行うようにされている。

その一方、「ワードスポット」では、人間が話した言葉を音声としてコンピュータが分析し、その音声の特徴量を抽出した後に、特徴量の時系列を作成する。そして、予めコンピュータに備えられている音声認識辞書（各単語の特徴量の時系列を記録保存した辞書）に含まれる各単語との類似度を計算し、その中から類似度の高い単語を認識結果として出力する。

また、音声対話における音声認識には、対話に用いる莫大な数の単語を予めドメイン毎に音声認識辞書として保存しておき、その音声認識辞書中の単語と入力された単語とを照合することで音声認識を行い、入力された文書から単語を抽出する手法もある（例えば、特許文献２参照）。これは、ドメイン毎に属する単語のデータベースを一度にメモリに保存し、かかるドメインに基づいて単語の認識速度を速める方法でもある。

そして、このような音声対話には、データベース等の情報を一箇所に集中させずに分散し、一箇所に情報過多の状況を構築せず、かつ、セキュリティーに優れた情報を分散させるようにした技術もある（例えば、特許文献３参照）。

国際公開第０２／２１２７０号パンフレット 国際公開第０２／０６７２４４号パンフレット 国際公開第００／６５４４９号パンフレット

ところで、上記したような従来の技術は、単語と応答文とを対応付けた複数のルールを予め用意しておき、入力文から抽出される単語がルールにヒットした場合に対応する応答文を出力するものに過ぎず、ルールにヒットしない限りは、ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答することができないという問題点があった。

その他にも、上記の従来技術には、以下に述べるような問題点もあった。例えば、音声対話に用いられるデータベースとして、リレーショナル型データベースや、オブジェクト指向型データベースや、これらのデータベースを改良したデータベースを用いても、これらのデータベース内には事例中の無用な単語が大量に蓄積されているので、対話に用を成さない無用な単語を音声対話の音声認識で拾うことがある。このため、入力した文章から認識される単語として、全く関係のない無意味な単語が認識され、ひいては対話処理に供されることになり、結果として、円滑かつ高速な対話処理が困難であるという問題点があった。さらに、これらのデータベースは、単語等の情報を単にプロパティに従って整理しているだけであるので、データに主従関係は無く、高速で必要なデータを検索することが困難であるという問題点もあった。

また、一般に「ディクテーション」を用いる場合であっても、「ワードスポット」による場合であっても、認識率を上げるためには、音声認識に使用する音声認識辞書に予め膨大な数の単語を登録しておく必要がある。しかしながら、音声認識辞書に登録する単語の数が多いと、それだけメモリの容量が必要になるとともに、入力された音声と音声認識辞書に記録された単語とのマッチングに時間がかかり過ぎてしまう。その結果、コンピュータが応答するまでに不必要な間が空いてしまい、音声会話としての実用に耐えられなくなるという問題点があった。その上、音声認識辞書に登録された単語数が多過ぎると、検索すべき対象が多くなるので、逆に認識率が低下し、認識に要する時間もかかり過ぎるという問題点もあった。

さらに、対話のドメインごとに音声認識辞書を作成したとしても、ドメインが固定されると、メモリに音声認識のために保存されるデータは変わらないので、一定容量以上のデータを一度にメモリに保存しておかなければならないという問題点があった。

また、従来の音声認識システム、特に「ディクテーション」による場合では、意味のない単語の羅列についても認識しようとして、かえって認識率を低下させるという問題点があった。すなわち、例を挙げれば、発話者が言葉に詰まったり、言い淀んだりした場合であっても、その言葉を認識しようとする結果、意味のない言葉として認識してしまうのみならず、前後の言葉についても誤った認識を誘発するという問題点があった。

さらに、従来の音声認識システムにおいては、入力された音声と音声認識辞書に含まれる単語との類似度を計算し、音声認識辞書の中から類似度の高い単語を認識結果として出力するようになっているので、実際は正しく認識できていない場合でも、とりあえず候補の単語が出力されてしまう。このため、かえって認識率が低下し、意味不明な応答文を返すという問題点があった。

また、音声認識辞書を如何に整理しても、一つの概念またはサブドメインのもとで整理されたものではないので、対話を高速に処理するためには、莫大なデータにアクセスして音声認識処理を行いながら、対話を進めなければならない。このため、広範なデータベースを効率良く、音声対話のために利用することもできないという問題点があった。

加えて、コンピュータによって音声認識が行われる場合には、コンピュータ内のメモリやハードディスク等に蓄積されているデータが利用されるのが一般的であるが、メモリやハードディスク等の容量は有限であり、利用できるデータには制限がある。このため、入力された音声に対応するデータが、メモリやハードディスク等に無い場合には、一向にデータがマッチせず、対話が行えないという問題点があった。

なお、人間同士の会話においても相手の話を聞く気になっていない場合には、相手が何を話してもその内容を認識できず上の空である。一方、相手の話を聞く気になっている場合には、かなりの騒音下であって、また、良く聞き取れない部分が一部にあったとしても、話の内容を理解することが可能である。この相違は、相手の話を聞く気になっている場合には、聞き手としては、今話題となっているドメインを予め想定し、相手が次に話すであろう言葉（流通言語語彙）をある程度予想した上で、その認識を行っているからである。このため、いきなり話が飛んで、今話題となっている話題と違う話題に移ったような場合には、聞き手としては、これを直ぐには理解できず、聞き間違えたのかと一瞬勘違いをすることになる。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答することができ、円滑かつ高速な対話処理を行うことが可能な知識処理装置、知識処理方法および知識処理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に係る発明は、入力文を解析して当該入力文に対する出力文を出力する知識処理装置であって、ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けして記憶するドメイン化データベースと、前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定手段と、を備えたことを特徴とする

また、請求項２に係る発明は、上記の発明において、前記ドメイン化データベースは、前記ドメインが共通する複数の事例ごとに、各事例の文章から抽出された流通言語語彙を、共通するサブドメインにリンク付けして記憶するものであって、所定の事例を特定するための入力文から前記サブドメインに対応する複数の入力流通言語語彙を抽出し、当該複数の入力流通言語語彙をいずれも含んで前記ドメイン化データベースに記憶された事例を特定する事例特定手段をさらに備え、前記回答特定手段は、前記事例特定手段によって特定された事例について前記ドメイン化データベースに記憶された流通言語語彙のなかから、前記出力文に含める回答を特定することを特徴とする。

また、請求項３に係る発明は、上記の発明において、前記ドメイン化データベースは、複数のドメイン毎に区分けして、各ドメインに属する複数の事例ごとに、各事例の文章から抽出された流通言語語彙を記憶するものであって、所定のドメインを特定するための入力文から入力流通言語語彙を抽出し、当該入力流通言語語彙に対応するドメインを特定するドメイン特定手段をさらに備え、前記事例特定手段は、前記ドメイン特定手段によって特定されたドメインについて、当該ドメインのサブドメインに対応する複数の入力流通言語語彙を抽出し、当該複数の入力流通言語語彙をいずれも含んで前記ドメイン化データベースに記憶された事例を特定することを特徴とする。

また、請求項４に係る発明は、入力文を解析して当該入力文に対する出力文を出力する知識処理方法であって、ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けしてドメイン化データベースに格納する格納工程と、前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定工程と、を含んだことを特徴とする。

また、請求項５に係る発明は、入力文を解析して当該入力文に対する出力文を出力する方法をコンピュータに実行させる知識処理プログラムであって、ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けしてドメイン化データベースに格納する格納手順と、前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定手順と、をコンピュータに実行させることを特徴とする。

請求項１、４または５の発明によれば、サブドメインに対応付けられた流通言語語彙単位で応答処理を行うので、ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答することができ、円滑かつ高速な対話処理を行うことが可能になる。

また、請求項２の発明によれば、複数の事例（バリュー）について回答可能である場合でも、円滑かつ高速に事例（バリュー）を特定することができ、円滑かつ高速な対話処理を行うことが可能になる。

また、請求項３の発明によれば、複数のドメインについて回答可能である場合でも、円滑かつ高速にドメインを特定することができ、円滑かつ高速な対話処理を行うことが可能になる。

以下に添付図面を参照して、この発明に係る知識処理装置、知識処理方法および知識処理プログラムの実施例を詳細に説明する。なお、以下では、本発明をユーザとコンピュータとの対話処理に適用した場合を実施例として、この対話処理の概要および特徴を最初に説明した後に、対話処理に用いるデータの構築、ユーザとの対話処理、対話処理に用いるデータの収集、対話処理に用いるデータの共有を順に説明し、最後に本実施例に対する種々の変形例を説明する。

［１：対話処理の概要および特徴］
まず最初に、図１を用いて、本実施例に係る対話処理の概要および特徴を説明する。図１は、本実施例の概要および特徴を説明するための図である。

同図に示すように、本実施例に係る対話処理は、概略的には、入力文を解析して当該入力文に対する出力文を出力するものであるが、かかる実際の対話処理に先立って、図３に例示するような事例データから図５に例示するようなドメイン化ＤＢ（データベース）と呼ばれるものが作成される。このドメイン化ＤＢとは、ある事例の文章（例えば、「新東京寿司」の事例）から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けして記憶するものである（図５参照）。

また、このドメイン化ＤＢは、ドメインが共通する複数の事例（例えば、「食事」というドメインで共通する「新東京寿司」の事例や「四川創作亭」の事例など）ごとに、各事例の文章から抽出された流通言語語彙を、共通するサブドメインにリンク付けして記憶する（図５参照）。さらに、このドメイン化ＤＢは、図１に例示するように、「食事」や「宿泊施設」、「レジャーランド」等の複数のドメイン毎に区分けして作成される。

そして、本実施例に係る対話処理では、図１に例示するように、ドメイン特定、バリュー特定（事例特定）、回答データ特定の各処理を通じて、ユーザと対話を行う。すなわち、例を挙げれば、「食事」、「宿泊施設」および「レジャーランド」のいずれのドメインについてユーザが対話を意図しているかをユーザの入力文に基づいて特定する。続いて、例えば、「食事」というドメインが特定された後に、特定されたドメインにおけるいずれのバリュー（バリュー番号）についてユーザが対話を望んでいるかをユーザの入力文に基づいて特定する。そして、バリューが特定された後は、特定されたバリューにおいてユーザが要求している回答データ（バリューデータ）をユーザの入力文に基づいて特定する。

具体的には、かかるドメイン特定、バリュー特定および回答データ特定は、いずれの処理も、ユーザの入力文を文章解析および流通言語語彙解析して、入力流通言語語彙を抽出することで行われる。すなわち、入力文に対して意味解析までは行わず、ドメイン化ＤＢの記憶単位である「流通言語語彙」の単位で語彙解析を行う。これについて例を挙げると、端的には、「〜動かない。」という入力文に対しては、動詞・助動詞を区別せずに「動かない」という流通言語語彙の単位で分解抽出する。

そして、ドメインを特定する場面では、ドメイン特定データ（後述する語彙ＤＢ、重要語彙ＤＢ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、いずれのドメインについてユーザが対話を意図しているかを特定する。つまり、例を挙げれば、ユーザの入力文から「食事」という流通言語語彙が抽出されれば、「食事」、「宿泊施設」および「レジャーランド」という三つのドメインのなかから「食事」をドメインとして特定する。

また、バリューを特定する場面では、バリュー特定データ（後述するインデックスファイル、インデックスキャッシュ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたドメインにおけるいずれのバリュー（事例、バリュー番号）についてユーザが対話を望んでいるかを特定する。つまり、例を挙げれば、ユーザの入力文から「魚」および「日本料理」という流通言語語彙が抽出されれば、複数あるバリュー（バリュー番号）のなかからユーザが意図するバリューとしてバリュー番号「Ｔ１」のバリューを特定する（図５参照）。

さらに、回答データを特定する場面では、特定されたバリューのプロパティ（流通言語語彙としてのサブドメイン）と、ユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたバリューにおいてユーザが要求している回答データ（バリューデータ）を特定する。つまり、上記の例で言えば、ユーザの入力文から「駐車場」という流通言語語彙が抽出されれば、バリュー番号「Ｔ１」のバリューのなかから「駐車場」のサブドメインに対応する「無し」というバリューデータを回答データとして特定し、ユーザの入力文（質問文）に対する回答として、例えば、「駐車場は無いです。」という出力文を出力する。

このように、本実施例に係る対話処理では、サブドメインに対応付けられた流通言語語彙単位で応答処理を行うので、ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答することができ、円滑かつ高速な対話処理を行うことが可能になる。また、複数の事例（バリュー）について回答可能である場合でも、円滑かつ高速に事例（バリュー）を特定することができる、円滑かつ高速な対話処理を行うことが可能になる。さらに、複数のドメインについて回答可能である場合でも、円滑かつ高速にドメインを特定することができ、円滑かつ高速な対話処理を行うことが可能になる。

［２：対話処理に用いるデータの構築］
次に、図２などを用いて、本発明に係る対話処理に用いられるドメイン化ＤＢ（データベース）、バリュー特定データ（インデックスファイル、インデックスキャッシュ）、ドメイン特定データ（語彙ＤＢ、重要語彙ＤＢ）の構築手法を説明する。なお、以下では、これらのドメイン化ＤＢ、バリュー特定データ、ドメイン特定データを作成するドメイン化ＤＢ作成装置の構成を説明した後に、それぞれの構築手法を説明する。

（１）ドメイン化ＤＢ作成装置の構成
図２は、ドメイン化ＤＢ、バリュー特定データ、ドメイン特定データをそれぞれ作成するドメイン化ＤＢ作成装置１０の構成を示すブロック図である。同図に示すように、このドメイン化ＤＢ作成装置１０は、入力部１１と、出力部１２と、通信制御部１３と、記憶部１４と、制御部１５とから構成される。

このうち、入力部１１は、各種の情報の入力を受付ける入力手段であり、キーボードやマウス、マイクなどを備えて構成され、例えば、ドメイン化ＤＢ作成装置１０に対する操作指示などをユーザから受け付けて入力する。なお、後述するモニタも、マウスと協働してポインティングディバイス機能を実現する。

出力部１２は、各種の情報を出力する出力手段であり、モニタ（若しくはディスプレイ、タッチパネル）やスピーカを備えて構成され、例えば、ドメイン化ＤＢ作成装置１０の動作内容（処理過程における確認）や、記憶部１４に記憶された各種の情報などを表示出力する。

通信制御部１３は、ドメイン化ＤＢ作成装置１０と他の外部装置（ネットワーク等を介して接続される他の外部装置）の間でやり取りする各種情報に関する通信を制御する手段であり、例えば、後述する「事例」のデータや概念辞書１４ａを外部装置から入力し、また、作成したドメイン化ＤＢ、バリュー特定データ、ドメイン特定データを外部装置（例えば、後述する対話処理装置２０）に出力する。

記憶部１４は、制御部１５による各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、特に本発明に密接に関連するものとしては、概念辞書１４ａと、ドメイン化ＤＢ１４ｂと、インデックスファイル１４ｃと、インデックスキャッシュ１４ｄと、語彙ＤＢ１４ｅと、重要語彙ＤＢ１４ｆとを備える。

このうち、概念辞書１４ａは、ドメイン化ＤＢ１４ｂの作成に用いられるデータベースであり、具体的には、図４に例示するように、「事例（図３参照）」が属するドメインの専門家等が予め、当該分野に関係するシチュエーション流通言語語彙、並びに、関係すると思われるシチュエーション流通言語語彙のそれぞれに、サブドメインを対応付けて記憶して構成される。

ドメイン化ＤＢ１４ｂは、後述する制御部１５によって作成され、後述する対話処理装置とユーザとの対話に際して利用されるデータベースであり、具体的には、図５に例示するように、「事例（図３参照）」に関する流通言語語彙等を、概念辞書１４ａのサブドメインに従って整理保存して構成される。

インデックスファイル１４ｃおよびインデックスキャッシュ１４ｄは、後述する制御部１５によって作成され、後述する対話処理装置とユーザとの対話に際して、ドメイン化ＤＢ１４ｂに含まれるバリューを特定するために使用されるデータベースである。具体的には、インデックスファイル１４ｃは、図７に例示するように、ドメイン化ＤＢ１４ｂに含まれるバリューデータの全てと、それぞれのバリューデータがどのバリューに含まれているのかを示すバリュー番号とを相互に対応付けて記憶して構成される。また、インデックスキャッシュ１４ｄは、図８に例示するように、ドメイン化ＤＢ１４ｂに含まれるバリューデータの一部と、それらのバリューデータのそれぞれがドメイン化ＤＢ１４ｂのどのバリューに含まれているのかを示すバリュー番号と、それらのバリューデータの使用頻度とを相互に対応付けて記憶して構成される。

語彙ＤＢ１４ｅおよび重要語彙ＤＢ１４ｆは、後述する制御部１５によって作成され、後述する対話処理装置とユーザとの対話に際して、対話のドメインを特定するために使用されるデータベースである。具体的には、語彙ＤＢ１４ｅは、図９に例示するように、ドメイン化ＤＢ１４ｂの全てのバリューデータや、各事例（図３参照）からドメイン化ＤＢ１４ｂ内に分類格納されなかった流通言語語彙を記憶して構成される。また、重要語彙ＤＢ１４ｆは、図１０に例示するように、上記の語彙ＤＢ１４ｅに記憶された流通言語語彙のなかで出現頻度の高いもの（例えば、５０個から３００個）、または、重要度計算を行った結果として出現頻度値や重要度計算値が高いものを記憶して構成される。

制御部１５は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部であり、特に本発明に密接に関連するものとしては、データマイニング部１５ａと、バリュー特定データ作成部１５ｂと、ドメイン特定データ作成部１５ｃとを備える。

これらの各部の詳細な処理内容については、以下で後述するが、概略的には、データマイニング部１５ａは、上記のドメイン化ＤＢ１４ｂを作成する処理部であり、バリュー特定データ作成部１５ｂは、上記のインデックスファイル１４ｃおよびインデックスキャッシュ１４ｄを作成および更新する処理部であり、ドメイン特定データ作成部１５ｃは、上記の語彙ＤＢ１４ｅおよび重要語彙ＤＢ１４ｆを作成および更新する処理部である。

なお、上述してきたドメイン化ＤＢ作成装置１０は、既知のパーソナルコンピュータ、ワークステーション、携帯電話、ＰＨＳ端末、移動体通信端末またはＰＤＡなどの情報処理装置に、上記した記憶部１４および制御部１５の各機能（プログラムやデータ）を搭載することによって実現することもできる。

（２）ドメイン化ＤＢの構築
続いて、図３〜図６を用いて、図２に示したドメイン化ＤＢ作成装置１０によるドメイン化ＤＢの構築手法を説明する。図３は、事例を構成する情報の具体例を示す図であり、図４は、概念辞書１４ａに記憶される情報の構成例を示す図であり、図５は、ドメイン化ＤＢ１４ｂに記憶される情報の構成例を示す図であり、図６は、ドメイン化ＤＢ１４ｂの作成処理の流れを示すフローチャートである。

ドメイン化ＤＢ１４ｂは、ドメイン化ＤＢ作成装置１０に入力される「事例」および記憶部１４に予め記憶された概念辞書１４ａを用いて、制御部１４のデータマイニング部１５ａによって作成されるものである。そこで、以下では、かかる「事例」および概念辞書１４ａの内容を先に説明してから、ドメイン化ＤＢ１４ｂの作成手法を説明する。

ドメイン化ＤＢ作成装置１０に入力される「事例」とは、マニュアルやＦＡＱ、カタログ、パンフレットなどの知識情報である。そして、この「事例」は、例えば、図３に例示するように、インターネット等の通信回線（通信制御部１３）を通じてアクセス可能なカタログの他に、一つのタイトル毎にデータが収められているものであれば、カタログ以外にパンフレット等でもよい。また、通信回線を介して収集されるもの以外にも、一般に流布されている書面でもよく、書面の場合には、スキャナーで取り込まれて電子化処理された後、通信回線を介して収集されたものと同様に扱われる。

かかる「事例」について、より詳細に説明すると、例えば、図３に例示する「事例」は、インターネット上で取得した「食事」のドメインに関する事例の一つであるが、この事例では「新東京寿司」や「四川創作亭」という店舗名が一つのタイトルに相当し、それぞれで「新東京寿司」や「四川創作亭」を紹介する情報や概要等が記載されている。つまり、「寿司」、「日本料理」、「穴子握り」、「５台」等の意味のある流通言語語彙が記載されるとともに、寿司の「参考写真」等を含んだ店の概要が記載されている。

ドメイン化ＤＢ作成装置１０は、このような「事例」を入力してドメイン化ＤＢ１４ｂを作成するが、その作成に際して概念辞書１４ａを参照する。かかる概念辞書１４ａは、図４に例示するように、事例が属するドメインの専門家等が予め、当該分野に関係するシチュエーション流通言語語彙、並びに、関係すると思われるシチュエーション流通言語語彙のそれぞれに、サブドメインを対応付けることで、膨大な数のシチュエーション流通言語語彙を記憶して構成されるデータベースである。

ここで、シチュエーション流通言語語彙としては、業界固有の用語を編集した辞書に記載してある流通言語語彙や、業界の関係者が日常用いている用語等が記憶保存される。したがって、事例の文章を意味解析および流通言語語彙解析して得られた流通言語語彙、つまり、図３に例示するような事例から助詞や冠詞等を取り除いて分解した意味のある流通言語語彙は、全て概念辞書に含まれていることになる。

かかる概念辞書１４ａについて、より詳細に説明すると、例えば、図４に例示する概念辞書１４ａでは、「日本料理」というシチュエーション流通言語語彙に対して「ジャンル」というサブドメインが付されている。なお、原則として、サブドメインの数は一つのドメインに付き３０個程度であるが、事例が属するドメインの専門家等の判断により、１００個以上にまでサブドメインの数を増やすことも可能である。また、これらのサブドメインは、互いに従属関係を持たせておくことも可能であり、この従属関係を用いて、後述するドメイン化ＤＢ１４ｂのプロパティの階層化に反映することも可能である。

ドメイン化ＤＢ作成装置１０は、上記したような事例を概念辞書１４に基づいて分類することでドメイン化ＤＢ１４ｂを作成する。かかるドメイン化データベース１４ｂは、図５に例示するように、ドメイン毎のデータ、つまり図３に例示したような事例に関する流通言語語彙等を、概念辞書１４ａのサブドメイン（人間が入力したサブドメイン）に従って整理保存して構成されるデータベースである。つまり、ドメイン化ＤＢ１４ｂにおけるサブドメインは、概念辞書１４ａで用いているサブドメインと１対１に対応している。

かかるドメイン化ＤＢ１４ｂについて、より詳細に説明すると、サブドメインを配列したものを「プロパティ」と呼ぶことにするが、例えば、図５に例示するドメイン化ＤＢ１４ｂでは、プロパティがプロパティａ、プロパティｂ、プロパティｃの三つに分けられており、プロパティａには、「タイトル」、「ＵＲＬ」、「ジャンル」、「参考写真」、「お勧め料理」、「食材」「店舗情報」等が含まれている。さらに、このうちの「店舗情報」を細分化するサブドメインが「収容人数」、「営業時間」、「駐車場」等のサブドメインであり、「参考写真」を細分化するサブドメインが「皿の数」、「明るさ」等のサブドメインであり、これらはプロパティａに対してさらに細分化したサブドメインの集合体であるプロパティｂやプロパティｃに含まれている。

ここで、プロパティａとプロパティｂとを統合して一つのプロパティにしてもよいが、逆にプロパティａとプロパティｂとを細分化してプロパティＡ、プロパティＢ、プロパティＣ、プロパティＤにさらに細分化することもできる。このように、プロパティを階層に並べてドメインを整理することを「ドメインの階層化」と呼ぶが、ドメインの階層化はユーザの嗜好をユーザコンピュータ（ドメイン化ＤＢ作成装置１０）が伺いながら構築されるものであり、ドメイン化ＤＢ作成装置１０がユーザと対話をしながら作成する。ただし、ここで言う「ユーザ」は、ドメインに関する専門家等である必要があり、いわゆる一般ユーザ（後述する対話処理装置と対話するユーザ）がドメイン化ＤＢ１４ｂを利用して対話を行う前に、予め専門家等がドメイン化ＤＢ１４ｂを作成しておくようにしてもよい。

また、ドメイン化ＤＢ１４ｂでは、図５に例示するように、ドメイン固有の事例がそれぞれプロパティａ、プロパティｂおよびプロパティｃに従って分類されるが、事例の一つ一つを、プロパティに従って分類したものを「バリュー」と呼ぶことにする。すなわち、図５に例示するドメイン化ＤＢ１４ｂでは、「新東京寿司」、「四川創作亭」、「グラツィオーゾ」、「豚骨亭」の四つのタイトルで代表される四つの事例について、プロパティａ、プロパティｂおよびプロパティｃに従って分類したバリューをそれぞれ４つ記憶している。そして、プロパティａに従って分類したバリューには、Ｔ１、Ｔ２、Ｔ３、Ｔ４のバリュー番号を、プロパティｂに従って分類したバリューには、Ｔ１ａ、Ｔ２ａ、Ｔ３ａ、Ｔ４ａのバリュー番号を、そしてプロパティｃに従って分類したバリューには、Ｔ１ｂ、Ｔ２ｂ、Ｔ３ｂ、Ｔ４ｂのバリュー番号を付して記憶している。

また、ドメイン化ＤＢ１４ｂを構成するデータをサブドメインに基づいてまとめたものを「カラム」と呼ぶことにする。すわわち、ドメイン化ＤＢ１４ｂは、事例の一つ一つをプロパティに従って分類したものであり、バリューとカラムによって構成されている。また、ドメイン化ＤＢ１４ｂに分類され、組み込まれた流通言語語彙等のデータを「バリューデータ」と呼ぶことにする。つまり、図５に例示するドメイン化ＤＢ１４ｂ中の「寿司」や「日本料理」等の流通言語語彙等は、それぞれバリューデータである。

上述してきたようなドメイン化ＤＢ１４ｂを作成するのが、ドメイン化ＤＢ作成装置１０の制御部１５におけるデータマイニング部１５ａである。すなわち、図６に示すように、データマイニング部１５ａは、入力部１１若しくは通信制御部１３を介して事例（図３参照）の文章データが入力されると（ステップＳ６０１肯定）、事例の中に記載の文章を意味解析および流通言語語彙解析して流通言語語彙を抽出する（ステップＳ６０２）。

そして、データマイニング部１５ａは、抽出した流通言語語彙を概念辞書１４ａ中のシチュエーション流通言語語彙と照合し（ステップＳ６０３）、マッチする流通言語語彙を該当するサブドメイン（図４参照）に従ってドメイン化ＤＢ１４ｂに分類して格納する（ステップＳ６０４）。その後、データマイニング部１５ａは、事例に属する全ての流通言語語彙を抽出分類する（ステップＳ６０５肯定）まで、上記した処理（ステップＳ６０２〜Ｓ６０４）を繰り返し実行する。その結果、図５に例示したようなドメイン化ＤＢ１４ｂが作成される。

なお、データマイニング部１５ａには、事例に含まれるタイトル（例えば、「新東京寿司」）を認識する機能や、事例に含まれる写真やグラフをそれぞれ写真データやグラフデータであることを認識してドメイン化ＤＢ１４ｂに分類する機能もある。

ところで、概念辞書１４ａのサブドメインも、一般辞書（一般に流通している膨大な数の国語辞典等が該当する。）に含まれる概念を専門家等が整理したものである。そして、概念辞書１４ａの中では、流通言語語彙に概念が付されているが、これを専門家等がそれぞれのドメインに対して分類・整理したものがサブドメインである。さらに、図３に例示するような事例中の流通言語語彙は、ユーザコンピュータ（ドメイン化ＤＢ作成装置１０）によって、全て自動的に分類・整理されてドメイン化ＤＢ１４ｂが構築されるようにする場合には、一旦ドメイン化ＤＢ１４ｂを構築した後に、専門家等にユーザコンピュータが構築結果の確認を取ることで、ドメイン化ＤＢ１４ｂの完成度を上げることも可能である。つまり、一旦構築したドメイン化ＤＢ１４ｂが満足できないものであった場合には、専門家等の指示の下、プロパティを組み直すなどしてドメイン化ＤＢ１４ｂを満足のいくものに修正することも可能である。

続いて、以下に、図３に例示した「事例」からドメイン化ＤＢ１４ｂを作成する処理を具体的に説明する。まず、データマイニング部１５ａは、「新東京寿司」が事例のタイトルであることを識別する。これは、例えば、事例のファースト頁の最上段に位置する用語を、その事例のタイトルであるとするプログラムが組まれていることで行われる。そして、データマイニング部１５ａは、「新東京寿司」はタイトルであるので、ドメイン化ＤＢ１４ｂの「タイトル」のサブドメインによってまとめられたカラムの一つに「新東京寿司」を分類格納する。これによって、「タイトル」の欄に「新東京寿司」を入れた「バリュー」は、事例の「新東京寿司」に関するデータを分類・整理したものであることになる。

なお、ドメイン化ＤＢ１４ｂでは、上から順に各バリューにバリュー番号を付しており、「新東京寿司」に関する事例のデータが格納されている「バリュー」のバリュー番号は「Ｔ１」である。そして、バリュー番号は、任意に決められるものであるが、一つのバリューが重複して一つのドメインにおけるドメイン化ＤＢ１４ｂに含まれることはなく、また、バリュー番号によって事例の優劣が決定されるものでもない。

また、図３に例示したように、この事例の中には、例えば「寿司は、日本料理の一つである。」という文章が記されている。データマイニング部１５ａでは、この文章の意味解析および流通言語語彙解析を行って「寿司」および「日本料理」の二つの流通言語語彙を抽出する。一方、概念辞書１４には、図３に例示したように、「寿司：カテゴリ」、「日本料理：ジャンル」というように、「寿司」および「日本料理」のシチュエーション流通言語語彙がサブドメインを伴って保存されている。

そこで、データマイニング部１５ａは、「寿司」の流通言語語彙は「カテゴリ」のサブドメインに従って、また、「日本料理」の流通言語語彙は「ジャンル」のサブドメインに従って、Ｔ１のバリューに分類格納する（図５参照）。このような工程を、プロパティａに従って図３の事例について全て実行すると、Ｔ１のバリューがドメイン化ＤＢ１４ｂに作成格納される。そして、データマイニング部１５ａは、同様の作業を「食事」のドメインに属する他の事例（例えば、タイトル「四川創作亭」の事例）について行うことで、「食事」に関するドメイン化ＤＢ１４ｂを作成する（図５参照）。

さらに、データマイニング部１５ａは、他のドメイン（例えば、「宿泊施設」や「レジャーランド」など）に関しても同様の作業を繰り返して実行することで、他のドメインに関するドメイン化ＤＢ１４ｂを作成することもできる。すなわち、ドメイン化ＤＢ１４ｂは、ドメイン毎に作成されるデータベースである。ただし、他のドメインに対応するドメインＤＢ１４ｂを作成するためには、例えば、「宿泊施設」や「レジャーランド」など、他のドメインに対応した概念辞書１４ａが必要である。

ところで、図５に例示するように、ドメイン化ＤＢ１４ｂのプロパティａには、サブドメインとして「ＵＲＬ」や「参考写真」が含まれている。一方、このサブドメインに対応する流通言語語彙は、図４に例示する概念辞書１４ａには含まれていない。つまり、概念辞書１４ａを用いるだけでは、「ＵＲＬ」や「参考写真」のサブドメインに対応するデータを事例から抽出することはできない。そこで、データマイニング部１５ａは、「ＵＲＬ」のサブドメインに対するデータを抽出する場合には、ＵＲＬ認識プログラムを用い、同様に、「参考写真」のサブドメインに対するデータを抽出する場合には、写真やグラフを事例から認識するための認識ソフトを用いる。

例えば、図３に例示した事例は、ＨＴＭＬファイルのホームページであるので、データマイニング部１５ａのＵＲＬ認識プログラムは、このＵＲＬ、すなわち「Ａ１」を「ＵＲＬ」のサブドメインに対するＴ１のバリューの欄に分類格納する。一方、写真を事例から認識した場合には、データマイニング部１５ａは、この写真の所在位置を詳細に示すＵＲＬ等の位置情報をＴ１のバリューの欄に分類格納する。これによって、本来的には別々のデータベースに格納される文字や写真等の画像を、一つのデータベースに一緒に保存することが可能になる。

また、データマイニング部１５ａは、写真のＵＲＬ等を取り込むと同時に、写真を文章や流通言語語彙で判断できるように、画像認識プログラムを用いて写真を分解・分析することもできる。つまり、かかる画像認識プログラムは、写真を網の目状に区分けした上で、その特徴を読み取る機能を担うものであるが、これによって、例えば、店内の椅子やテーブルの配置を表した写真であれば、写真の中の特徴として、店内の椅子の数やテーブルの間隔等を文章や流通言語語彙として抽出し、ドメイン化ＤＢ１４ｂに分類格納する。

さらに、専門家等のコメント等に代表される主観を事例の中から取り出す機能を画像認識プログラムに付加しておくこともできる。つまり、この主観は、事例の中の写真の解説欄に記載の文章であり、この文章を取り出す機能が上記の付加機能である。図５に例示するように、ドメイン化ＤＢ１４ｂにおいては、サブドメイン「参考写真」のさらに下層に参考写真のデータを入れるプロパティｃが形成されているが、上記の付加機能によって、写真のデータを個別具体的にドメイン化ＤＢ１４に分類格納することが可能になる。なお、グラフについても、同様に分類格納することができる。

ただし、店舗の外観写真と料理の見本を示した写真の２種類が掲載されているような事例の場合には、「参考写真」のサブドメインに対応する写真は、料理の見本を示した写真のことである。そして、この判別は、写真を見つけるごとに、専門家等のサブドメインを導入した人やユーザに確認を取りつつ行われる。つまり、データマイニング部１５ａが店舗の外観写真を事例から抽出した場合に、専門家等のサブドメインを導入した者やユーザに「この写真を、参考写真に組み込みますか？」と尋ねるようなプログラムがデータマイニング部１５ａには組み込まれる。

ここで、かかる写真は「参考写真」に組み込みたい写真ではないので、専門家等のサブドメインを導入した者やユーザが「いいえ」と答えた場合には、データマイニング部１５ａは、抽出した店舗の外観写真をドメイン化ＤＢ１４ｂに格納することはしない。その一方、データマイニング部１５ａは、料理の見本を示した写真を事例から抽出して、「この写真を、参考写真に組み込みますか？」と尋ねる。ここで、この写真は「参考写真」に組み込みたい写真なので、「はい」と答えた場合には、データマイニング部１５ａは、この写真の所在位置を詳細に示すＵＲＬ等の位置情報をＴ１のバリューの欄に分類格納する。

上述してきたような処理をデータマイニング部１５ａで実行することで、図３に例示したような事例のデータから、図５に例示したようなドメイン化ＤＢ１４ｂが作成される。なお、写真やグラフ以外の他のバリューデータをドメイン化ＤＢ１４ｂに分類格納する際にも、個別に専門家等のサブドメインを導入した者やユーザに確認を取ることも可能であり、また、そうすることで、ドメイン化ＤＢ１４ｂもユーザ等にとって最も有効なデータベースになる。

（３）バリュー特定データの構築
続いて、図７および図８を用いて、図２に示したドメイン化ＤＢ作成装置１０によるバリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）の構築手法を説明する。図７は、インデックスファイル１４ｃに記憶される情報の構成例を示す図であり、図８は、インデックスキャッシュ１４ｄに記憶される情報の構成例を示す図である。

インデックスファイル１４ｃは、図７に例示するように、ドメイン化ＤＢ１４ｂに含まれるバリューデータの全てと、それぞれのバリューデータがどのバリューに含まれているのかを示すバリュー番号とを相互に対応付けて記憶して構成される。

そして、このインデックスファイル１４ｃは、上記したドメイン化ＤＢ１４ｂの作成後、後述するインデックスキャッシュ１４ｄの作成前に、ドメイン化ＤＢ作成装置１０の制御部１５におけるバリュー特定データ作成部１５ｂによって作成される。具体的には、バリュー特定データ作成部１５ｂは、ドメイン化ＤＢ１４ｂに格納されているバリューデータを全て集めてくることでインデックスファイル１４ｃを作成する。このため、インデックスファイル１４ｃの容量は莫大になるが、バリューデータが同一の流通言語語彙については、図７に例示するように、バリューデータを統合して、複数のバリュー番号をまとめるようにしてもよく、これによって、記憶されるデータ量を少なくし、後述する検索処理（バリュー特定のための検索処理）における重複作業を省くこともできる。

一方、インデックスキャッシュ１４ｄは、図８に例示するように、ドメイン化ＤＢ１４ｂに含まれるバリューデータの一部と、それらのバリューデータのそれぞれがドメイン化データベース２０ａのどのバリューに含まれているのかを示すバリュー番号と、それらのバリューデータの使用頻度とを相互に対応付けて記憶して構成される。

そして、このインデックスキャッシュ１４ｄは、上記したインデックスファイル１４ｃの作成後に、ドメイン化ＤＢ作成装置１０の制御部１５におけるバリュー特定データ作成部１５ｂによって作成される。具体的には、バリュー特定データ作成部１５ｂは、ドメイン化ＤＢ１４ｂに格納されているバリューデータのうちから、使用頻度が高い一部のバリューデータ（例えば、５０００個のバリューデータ）を集めてくることでインデックスキャッシュ１４ｄを作成する。なお、使用頻度数は、そのバリューデータの使用割合やアクセス回数を用いて表すことができるが、例えば、使用割合は、そのバリューデータへのアクセス回数をインデックスキャッシュ１４ｄへのアクセス回数で除して、１００を乗じた値である。

このようなインデックスキャッシュ１４ｄやインデックスファイル１４ｃは、後述する対話処理装置とユーザとの対話に際して、ドメイン化ＤＢ１４ｂに含まれるバリューを特定するために使用される。つまり、インデックスキャッシュ１４ｄやインデックスファイル１４ｃは、いずれもドメイン化ＤＢ１４ｂの中から特定のバリューを検索するための検索用ファイルであり、ドメイン化ＤＢ１４ｂを本と例えるならば、インデックスキャッシュ１４ｄおよびインデックスファイル１４ｃは共に本の索引に相当する。ただし、インデックスキャッシュ１４ｄは簡易な索引に相当し、インデックスファイル１４ｃは詳細な索引に相当する。また、インデックスキャッシュ１４ｄ内のバリューデータは、使用頻度数が多い順に配列されるが、インデックスファイル１４ｃ内のバリューデータは、例えば「あいうえお順」や「アルファベット順」等で配列される。

かかるインデックスキャッシュ１４ｄおよびインデックスファイル１４ｃについて、より詳細に説明すると、例えば、図５に例示したドメイン化ＤＢ１４ｂでは、「ジャンル」のサブドメインに対応付けて「日本料理」というバリューデータがＴ１とＴ４の二つのバリューに格納されているが、図８に例示するインデックスキャッシュ１４ｄでは、これが１行目に格納されている。つまり、「日本料理」のバリューデータと同じ行に「Ｔ１＆Ｔ４」というデータが記されている。ここで、「Ｔ１＆Ｔ４」は、「Ｔ１とＴ４のバリューにそれぞれ入っています。」ということを表している。すなわち、これらは、「「日本料理」のバリューデータは、Ｔ１のバリューとＴ４のバリューに組み込まれている。」ということを指し示しており、さらに、図８に例示するインデックスキャッシュ１４ｄでは、使用頻度数は「日本料理」が最も多いことを表している。なお、以上からも明らかなように、インデックスファイル１４ｃやインデックスキャッシュ１４ｄには、ドメイン化ＤＢ１４ｂに存在するプロパティやカラムという概念は無関係である。

ところで、図５に例示したドメイン化ＤＢ１４ｂにおけるプロパティｂのように、サブドメインの中には「駐車場」や「収容人数」と言ったものがあるが、これらのサブドメインに対して「５台」や「２０人」というバリューデータをそのままインデックスキャッシュ１４ｄに保存したのでは、そのバリューデータの意味するところが不明確になるおそれがある。そこで、バリュー特定データ作成部１５ｂでは、例えば「駐車場」のサブドメインに対するバリューデータに関しては、「駐車場有り」または「駐車場無し」と分けることで、インデックスキャッシュ１４ｄでは、駐車場があるものを「駐車場有り」というバリューデータに変換して保存するようにしている。

ただし、かかる変換保存処理は、インデックスキャッシュ１４ｄに対してのみ実行され、バリュー特定データ作成部１５ｂでは、インデックスファイル１４ｃに対しては、「５台」や「２０人」といったバリューデータであっても、そのままのバリューデータを保存する。これは、インデックスファイル１４ｃは、データ処理の高速化を目的とするというよりも、ドメイン化ＤＢ１４ｂの単なる検索用ファイルとしての側面が、インデックスキャッシュ１４ｄよりも強いからである。

これに対して、インデックスキャッシュ１４ｄは、高速で入力された流通言語語彙からバリュー、すなわち事例を特定することに主眼を置いている。そのため、検索を単純かつスマートに行うために、バリューデータそのものを一部簡潔に整理・保存している。つまり、インデックスキャッシュ１４ｄは、バリューデータの正確さよりも検索の高速化を主眼に構築され、インデックスファイル１４ｃは、インデックスキャッシュ１４ｄよりもバリューデータの正確さを主眼に構築される。なお、もちろん、インデックスキャッシュ１４ｄにインデックスファイル１４ｃからバリューデータをそのまま取り込むようにしても良い。

一方、インデックスファイル１４ｃからインデックスキャッシュ１４ｃには、バリューデータの移行が可能である。すなわち、バリューデータの特定に際して、インデックスキャッシュ１４ｃに含まれるバリューデータに検索対象の流通言語語彙がない場合には、インデックスファイル１４ｃのバリューデータを用いて検索される。そして、このような場合、バリュー特定データ作成部１５ｂでは、インデックスファイル１４ｃで検索に用いられたバリューデータを、最も高い使用頻度（例えば１００％）を付与した上で、インデックスキャッシュ１４ｄに新たに格納する。ただし、インデックスファイル１４ｃで検索に用いられたバリューデータは消去もされず、何の変化も無く保存される。それ故、保存されているバリューデータの数は、インデックスファイル１４ｃでは変化しないが、インデックスキャッシュ１４ｄでは変化する。例えば、当初５０００個のバリューデータが保存されていたインデックスキャッシュ１４でも、運用に従って５００１個、５００２個、・・・と保存数が増加する。

また、インデックスキャッシュ１４ｄは、運用開始から一定期間経過したとき、または、記憶するバリューデータ量が一定容量に達したときに整理される。すなわち、インデックスキャッシュ１４ｄには、例えば、原則として５０００個のバリューデータが保存されるように規定されているので、バリュー特定データ作成部１５ｂでは、増加したバリューデータを整理して５０００個にする。これは、瞬時に行われ、使用頻度の少ないものがインデックスキャッシュ１４ｄから消去されることで５０００個にされる。若しくは、インデックスキャッシュ１４ｄを二個設け、バリューデータを整理しているときには、一方のインデックスキャッシュ１４ｄを使用し、その後、整理された他のインデックスキャッシュ１４ｄを入れ替えることで、整理中でもインデックスキャッシュ１４ｄが円滑に機能するようにすることも可能である。

ところで、上記でも説明したが、インデックスキャッシュ１４ｄには、原則として、ドメイン化ＤＢ１４ｂ中で使用頻度の高い流通言語語彙が５０００個集められている。しかし、５０００個という数は、設定により増減可能であり、例えば、２０００個にすることも、また７０００個にすることも可能である。なお、ドメイン化ＤＢ１４ｂと、インデックスファイル１４ｃと、インデックスキャッシュ１４ｄとは、一つのドメインに付き一つずつ少なくともあり、インデックスキャッシュ１４ｄの数のみ設定により二個にすることが可能である。

さらに、バリューデータの集合からボトムアップ形式で構築した類似検索を、インデックスキャッシュ１４ｄやインデックスファイル１４ｃのバリューデータに付することも可能である。例えば、「ラーメン」と「パスタ」のバリューデータから「めん類」というように類似点を抽出し、ボトムアップ形式で新たなサブドメインをツリー状に分類・整理し、その結果として、新たに導き出された「めん類」というサブドメインを「ラーメン」や「パスタ」のバリューデータに付し、これを検索に利用することも可能である。

（４）ドメイン特定データの構築
続いて、図９および図１０を用いて、図２に示したドメイン化ＤＢ作成装置１０によるドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）の構築手法を説明する。図９は、語彙ＤＢ１４ｅに記憶される情報の構成例を示す図であり、図１０は、重要語彙ＤＢ１４ｆに記憶される情報の構成例を示す図である。

語彙ＤＢ１４ｅは、図９に例示するように、ドメイン化ＤＢ１４ｂの全てのバリューデータや、各事例（図３参照）からドメイン化ＤＢ１４ｂ内に分類格納されなかった流通言語語彙を記憶して構成されるデータベースである。そして、この語彙ＤＢ１４ｅは、上記したドメイン化ＤＢ１４ｂの作成後、ドメイン化ＤＢ作成装置１０の制御部１５におけるドメイン特定データ作成部１５ｃによってドメイン毎に作成される。

ただし、この語彙ＤＢ１４ｅは、ドメイン化ＤＢ１４ｂのような「事例やサブドメインに基づいてデータを保存したデータベース」、またはインデックスキャッシュ１４ｄやインデックスファイル１４ｃのような「バリュー番号を付してデータを保存したデータベース」とは異なり、保存形式に係る一切の規定が無く、ドメイン特定データ作成部１５ｃは、バリューデータそのものや、事例から分類格納されなかった流通言語語彙を、単に羅列して記憶させることで語彙ＤＢ１４ｅを作成する。

一方、重要語彙ＤＢ１４ｆは、図１０に例示するように、上記の語彙ＤＢ１４ｅに記憶された流通言語語彙のなかで出現頻度の高いもの（例えば、５０個から３００個）、または、重要度計算を行った結果として出現頻度値や重要度計算値が高いものを記憶して構成されるデータベースである。そして、この重要語彙ＤＢ１４ｆは、上記したドメイン化ＤＢ１４ｂの作成後、ドメイン化ＤＢ作成装置１０の制御部１５におけるドメイン特定データ作成部１５ｃによってドメイン毎に作成される。

ここで、出現頻度値とは、ドメインの中で各事例の範囲を越えて、例えば「日本料理」の流通言語語彙が何回表れたのかを示す値のことである。また、重要度計算値とは、ドメインの中で各事例の範囲を超えて、例えば「日本料理」と「寿司」の出現頻度値が高いときに、このような流通言語語彙同士の関係から導いた値のことである。つまり、出現頻度値も重要度計算値も共に、ドメインの中で、その流通言語語彙等がどれだけ不可欠な流通言語語彙等であるかを示すものであり、一般的に言うところの「キーワード」に対応している。そして、ドメイン特定データ作成部１５ｃは、これらの値を算出して重要語彙ＤＢ１４ｆに格納する。

また、ドメインの名称や、「タイトル」や「ジャンル」のサブドメイン（図５参照）で定義されるカラムに含まれる流通言語語彙は、ドメイン固有の流通言語語彙であり、ドメインを特定する際に必要不可欠であるので、ドメイン特定データ作成部１５ｃは、重要語彙ＤＢ１４ｆの作成に際して、これらの流通言語語彙を優先して重要語彙ＤＢ１４ｆに格納する。つまり、ドメインの名称等は、事例の中で出てくる回数が少なくても、優先して重要語彙データベースに格納される。なお、このような流通言語語彙は、重要度計算値が高いので、重要語彙ＤＢ１４ｆから漏れることはないと考えられる。

このような語彙ＤＢ１４ｅや重要語彙ＤＢ１４ｆは、後述する対話処理装置とユーザとの対話に際して、対話のドメインを特定するために使用される。つまり、「食事」、「宿泊施設」、「レジャーランド」等に関するドメイン化ＤＢ１４ｂが複数あるような場合に、ユーザがいずれのドメインについて対話を望んでいるか、言い換えれば、いずれのドメイン化ＤＢ１４ｂを用いてユーザと対話するかを特定するために利用される。

［３：ユーザとの対話処理］
次に、図１１などを用いて、本発明に係る対話処理を説明する。なお、以下では、ユーザとの間で対話処理を実行する対話処理装置の概略処理、各部の構成を説明した後に、これをカーナビゲーションシステムに適用した場合を例にして具体的な対話処理の流れを説明する。

（１）対話処理装置の概略処理
図１１は、ユーザとの間で対話処理を実行する対話処理装置２０の構成を示すブロック図であり、図１２は、この対話処理装置２０による対話処理の概略を説明するための図であり、図１３は、対話処理装置２０による対話処理の概略を示すフローチャートである。

図１１に示すように、この対話処理装置２０では、上記した「対話処理に用いられるデータ」で説明したドメイン化ＤＢ１４ｂ、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）およびドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）を外部記憶部２５に備える。すなわち、例を挙げれば、「食事」、「宿泊施設」、「レジャーランド」というドメイン毎に、上記した各データを備える。

そして、この対話処理装置２０では、上記した各データを用いて、ドメイン特定、バリュー特定、回答データ特定の各処理を通じて、ユーザと対話を行う。すなわち、例を挙げれば、対話処理装置２０は、「食事」、「宿泊施設」および「レジャーランド」のいずれのドメインについてユーザが対話を意図しているかをユーザの入力文に基づいて特定する。続いて、例えば、「食事」というドメインが特定された後に、対話処理装置２０は、特定されたドメインにおけるいずれのバリュー（バリュー番号）についてユーザが対話を望んでいるかをユーザの入力文に基づいて特定する。そして、バリューが特定された後に、対話処理装置２０は、特定されたバリューにおいてユーザが要求している回答データ（バリューデータ）をユーザの入力文に基づいて特定する。

そして、かかるドメイン特定、バリュー特定および回答データ特定は、いずれの処理も、図１３に示すフローチャートの流れに従って実行される。すなわち、同図に示すように、ユーザからマイク（後述する入力部２１）を通じて音声入力があると（ステップＳ１３０１肯定）、対話処理装置２０の制御部２６は、かかる音声入力された入力文に対して、文章解析および流通言語語彙解析することで、ユーザとの対話を繋げるために必要不可欠な入力流通言語語彙を抽出する（ステップＳ１３０２）。

すなわち、対話処理装置２０の制御部２６は、入力文に対して意味解析までは行わず、ドメイン化ＤＢ１４ｂ、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）およびドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）の記憶単位である「流通言語語彙」の単位で語彙解析を行う。これについて例を挙げると、端的には、「〜動かない。」という入力文に対しては、動詞・助動詞を区別せずに「動かない」という流通言語語彙の単位で分解抽出する。

対話処理装置２０の制御部２６は、抽出した流通言語語彙を用いてユーザに対する応答を検索する（ステップＳ１３０３）。すなわち、ドメインを特定する場面では、ドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、いずれのドメインについてユーザが対話を意図しているかを特定する。つまり、例を挙げれば、ユーザの入力文から「食事」という流通言語語彙が抽出されれば、「食事」、「宿泊施設」および「レジャーランド」という三つのドメインのなかから「食事」がドメインとして特定される。

また、バリューを特定する場面では、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたドメインにおけるいずれのバリュー（バリュー番号）についてユーザが対話を望んでいるかを特定する。つまり、例を挙げれば、ユーザの入力文から「魚」および「日本料理」という流通言語語彙が抽出されれば、複数あるバリュー（バリュー番号）のなかからユーザが意図するバリューとしてバリュー番号「Ｔ１」のバリューが特定される（図５参照）。

さらに、回答データを特定する場面では、特定されたバリューのプロパティ（流通言語語彙としてのサブドメイン）と、ユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたバリューにおいてユーザが要求している回答データ（バリューデータ）を特定する。つまり、上記の例で言えば、ユーザの入力文から「駐車場」という流通言語語彙が抽出されれば、バリュー番号「Ｔ１」のバリューのなかから「駐車場」のサブドメインに対応する「無し」というバリューデータが回答データとして特定される。

このようにして、ドメイン特定、バリュー特定または回答データ特定のいずれかが行われた後に、対話処理装置２０の制御部２６は、応答文を作成して、これをスピーカ（後述する出力部２２）から出力する（ステップＳ１３０４およびＳ１３０５）。すなわち、ドメインを特定した場面では、特定したドメインをユーザに確認する意味で、例えば、「食事の話ですね。」という出力文を出力する。また、バリューを特定した場面では、特定したバリューをユーザに回答する意味で、例えば、「新東京寿司はいかがですか？（出力文６）」という出力文を出力する。さらに、回答データを特定した場面では、ユーザの入力文（質問文）に対する回答として、例えば、「駐車場は無いです。」という出力文を出力する。なお、ユーザの一度の入力文によってもドメインやバリュー、回答データが特定できなかった場合には、ドメインやバリュー、回答データを特定するための質問文を対話処理装置２０から出力し、これらを特定するための流通言語語彙の入力をユーザに促す。

（２）対話処理装置の構成
続いて、上記した概略の対話処理を行う対話処理装置２０の構成を説明する。図１１に示すように、この対話処理装置２０は、入力部２１と、出力部２２と、通信制御部２３と、記憶部２４と、外部記憶部２５と、制御部２６とから構成される。

このうち、入力部２１は、各種の情報の入力を受付ける入力手段であり、マイクやキーボード、マウス、などを備えて構成され、例えば、マイクを介して対話の入力文（図１４参照）などをユーザから受け付けて入力する。

出力部２２は、各種の情報を出力する出力手段であり、スピーカやモニタ（若しくはディスプレイ、タッチパネル）を備えて構成され、例えば、スピーカを介して対話の出力文（図１４参照）などを出力する。

通信制御部２３は、対話処理装置２０と他の外部装置（ネットワーク等を介して接続される他の外部装置）の間でやり取りする各種情報に関する通信を制御する手段であり、例えば、ドメイン化ＤＢ１４ｂ、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）およびドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）の各種データを外部装置（例えば、上記したドメイン化ＤＢ作成装置１０）から入力する。

記憶部２４は、制御部２６による各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、特に本発明に密接に関連するものとしては、データアクセスの高速化を図るためのキャッシュメモリ２４ａを備え、かかるキャッシュメモリ２４ａ上に、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）やドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）を適宜記憶する。

外部記憶部２５も、制御部２６による各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、特に本発明に密接に関連するものとしては、「食事」、「宿泊施設」、「レジャーランド」等のドメイン毎に、ドメイン化ＤＢ１４ｂ、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）およびドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）を備える。なお、ここでは、記憶部２４と外部記憶部２５とを別個に構成する場合を例に挙げたが、これらを一体として構成するようにしてもよい。

制御部２６は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部であり、特に本発明に密接に関連するものとしては、音声認識部２６ａと、音素メモリ部２６ｂと、音声合成部２６ｃと、発話テンプレート部２６ｄと、対話制御部２６ｅと、ドメイン特定部２６ｆと、バリュー特定部２６ｇと、回答データ特定部２６ｈとを備える。

このうち、音声認識部２６ａは、ユーザがマイク（入力部２１）から入力した音声を認識して入力文章（入力された音声を電気的な信号に変換したもの）に変換し、この入力文章を文章解析および流通言語語彙解析することで、ユーザとの対話を繋げるために必要不可欠な入力流通言語語彙に分解する処理部である。

音素メモリ部２６ｂは、音声認識部２６ａによって分解されて抽出された入力流通言語語彙を記憶するとともに、バリューの特定後に（回答データの特定の際に）、特定されたバリューのプロパティ（サブドメイン）およびバリューデータを記憶するメモリである。なお、音素メモリ部２６ｂの記憶内容は、対話の応答に従って、頻繁にかつ即座に書き換えられる。

音声合成部２６ｃは、後述の対話制御部２６ｅによって作成された応答文を音声に変換してスピーカ（出力部２２）から出力する処理部である。発話テンプレート部２６ｄは、ユーザとの対話における所定の場面毎に、ユーザに対して出力する出力文のフォーマットを記憶するメモリである。なお、このフォーマットの具体例については後述する。

対話制御部２６ｅは、後述するドメイン特定部２６ｆやバリュー特定部２６ｇ、回答データ特定部２６ｈの処理結果に応じて、ユーザに対して出力する出力文（応答文）を作成する処理部である。具体的には、後述するが、ユーザとの対話における所定の場面毎に、いかなる応答文を作成するかについて規定した各種のプログラムが組み込まれている。

ドメイン特定部２６ｆは、ユーザとの対話に際してドメインを特定する処理部である。具体的には、ドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、いずれのドメインについてユーザが対話を意図しているかを特定する。なお、この詳細については具体例を用いて後述する。

バリュー特定部２６ｇは、ユーザとの対話に際してバリューを特定する処理部である。具体的には、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）に記憶されている流通言語語彙とユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたドメインにおけるいずれのバリュー（バリュー番号）についてユーザが対話を望んでいるかを特定する。なお、この詳細についても具体例を用いて後述する。

回答データ特定部２６ｈは、ユーザとの対話に際して回答データを特定する処理部である。具体的には、特定されたバリューのプロパティ（流通言語語彙としてのサブドメイン）と、ユーザの入力文から抽出した流通言語語彙とを照合することで、特定されたバリューにおいてユーザが要求している回答データ（バリューデータ）を特定する。なお、この詳細についても具体例を用いて後述する。

ところで、上述してきた対話処理装置２０は、既知のパーソナルコンピュータ、ワークステーション、携帯電話、ＰＨＳ端末、移動体通信端末またはＰＤＡなどの情報処理装置に、上記した記憶部２４、外部記憶部２５および制御部２６の各機能（プログラムやデータ）を搭載することによって実現することもできる。また、ここでは、上記のドメイン化ＤＢ作成装置１０と対話処理装置２０とを別個に構成する場合を例に挙げたが、これらをユーザコンピュータとして一体として構成するようにしてもよい。特に、両者を一体として構成した場合には、バリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）やドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）を簡易に更新することも可能になる。

（３）具体的な対話処理の流れ
続いて、図１４を用いて、上記の対話処理装置２０による具体的な対話処理の流れを説明するが、ここでは、対話処理装置２０による対話処理をカーナビゲーションシステムに適用した場合を具体例として説明する。つまり、この場合には、ユーザは車の運転手（または同乗者）に相当し、対話処理装置２０はカーナビゲーションシステム（いわゆるユーザコンピュータ）に相当する。図１４は、このような場合における対話処理の具体例を示す図である。

上記した対話処理装置２０において、ユーザがマイク（入力部２１）から音声を入力すると、音声認識部２６ａは、この音声を認識して入力文章（入力された音声を電気的な信号に変換したもの）に変換し、この入力文章を文章解析および流通言語語彙解析することで、ユーザとの対話を繋げるために必要不可欠な入力流通言語語彙に分解する。

すなわち、例えば、図１４に例示するように、ユーザが「聞きたいことがあるから、起きてくれる。（入力文1）」と対話処理装置２０に対して入力すると、対話処理装置２０は、この音声に反応して、「私を起動してくれてありがとう。私は食事、宿泊施設、そしてレジャーランドの三つのドメインについて話が出来ます。（出力文１）」と返答する。

このような対話が行われるのは、「対話処理装置２０が起動した際には、対話処理装置２０が対話可能な内容（つまり、ドメイン）をユーザに答える」というプログラムが対話制御部２６ｅに組み込まれているからである。すなわち、対話処理装置２０の中には、「食事」、「宿泊施設」、そして「レジャーランド」という三つのドメインに関するデータ（ドメイン化ＤＢ１４ｂなど）が保存されており、三つのうちからどのドメインの対話を行うのかをユーザに決めさせるために、上記のような出力文を対話処理装置２０は出力する。

また、対話処理装置２０では、上記のような出力文を音声合成部２６ｃによって出力すると同時に、「食事」、「宿泊施設」、「レジャーランド」の三つドメインそれぞれに対応する重要語彙ＤＢ１４ｆ内の流通言語語彙を一時的に記憶部２４のキャッシュメモリ２４ａに保存する。これは、後述するように、ドメインを特定するための準備である。

一方、ユーザが上記の出力文に対して、「そうだな、食事をしたいな。（入力文２）」と答えたとする。この場合には、対話処理装置２０の音素メモリ部２６ｂは、音声認識部２６ａによる文章解析および流通言語語彙解析を経て、入力文の中にある「食事」という入力流通言語語彙を記憶し、ドメイン特定部２６ｇは、一時的にキャッシュメモリ２４ａに蓄えた重要語彙ＤＢ１４ｆに対して照合（検索）を行う。そして、この場合には、明らかに食事のドメインだけに「食事」の流通言語語彙があるので、対話内容のドメインが「食事」であることを特定する。なお、これによって、対話の範囲が狭まり、後の対話がスムーズに行われることからも、これは最も重要な工程である。

ところで、音声認識部２６ａによる語彙解析を経て音素メモリ部２６ｂに記録された入力流通言語語彙が、複数のドメインの重要語彙ＤＢ１４ｆに重複して存在している場合には、ドメイン特定部２６ｆは、その流通言語語彙の数に、ドメイン内における当該流通言語語彙の出現頻度値や重要度計算値を乗じた数が多いドメインを、対話のドメインである可能性が高いと判断することもできる。しかしながら、その乗じた数は、相対的な数であるので、その数で絶対的に判断することには問題がある。そこで、このような場合には、対話処理装置２０では、ユーザにこのドメインで良いのかどうかを確認し、または、更なるドメイン特定のための情報入力を促すことで、ドメインを正確に特定する。

すなわち、ドメインが明らかに特定されたと思われるような場合でも、念を押してドメインを確認するために、対話制御部２６ｅは、発話テンプレート部２６ｄに記録されている以下のようなフォーマットを起動する。具体的には、発話テンプレート部３７には、ドメインが決まった場合にそれを聞き返すフォーマットとして「〜の話ですね。」が記録されているので、対話制御部２６ｅは、フォーマット内の「〜」の部分に特定されたドメインを当てはめることで、図１４に例示するように、「食事の話ですね。（出力文２）」という出力文を出力する。これによって、ユーザはドメインが特定されたことを確認し、上記の出力文に対して、「そうだよ。（入力文３）」という入力文を入力する。以上のような工程を経ることで、ドメインが確実に特定され、スムーズな対話が続けられる。

このようにしてドメインが特定されると、対話処理装置２０では、特定された「食事」のドメインに対して、どのような話をしたいのかをユーザに尋ねる工程に移行する。具体的には、対話制御部２６ｅは、「どのカテゴリのものが食べたいですか？」や「どのようなジャンルの料理が食べたいですか？」等の出力文を、発話テンプレート部２６ｄに記録されているフォーマットを起動して出力する。これによって、対話処理装置２０は、ユーザに対して、対話を続けていくための情報の入力を促すことが可能になる。

このように、対話制御部２６ｅは、サブドメインをユーザに尋ねるプログラム群でもあり、ドメインによって異なるプログラム群を形成することも可能である。つまり、対話制御部２６ｅには、ドメインが特定された後に、ユーザにサブドメインの入力を促す仕組みが設けられており、例えば、「食事」のドメインが特定されると、「食事」のドメインに関するドメイン化ＤＢ１４ｂ中のプロパティａを呼び出し、呼び出したプロパティａを用いてバリューを特定するためのプログラムが組み込まれている。

具体的には、「ジャンル」および「食材」の入力を促して、バリューを特定するというプログラムが対話制御部２６ｅに組み込まれている。しかしながら、必ずしも「ジャンル」および「食材」の入力を促す必要はなく、どのサブドメインの入力を促してもよいし、全てのサブドメインの入力を促すようにしてもよい。ただし、対話を滑らかに組み立てるためには、２個から５個程度のサブドメインの入力を促して対話を進めた方が、対話が双方向で滑らか、かつ、確実に行われているようにユーザに感じさせることができる。

さらに、ドメインが特定された後においては、キャッシュメモリ２４ａ上でインデックスキャッシュ１４ｄを用いて対話が滑らか、かつ、高速に行われる。すなわち、ドメインが特定されたと同時（または直後）に、制御部２６は、外部記憶部２５に保存されている特定されたドメイン「食事」に固有のインデックスキャッシュ１４ｄをキャッシュメモリ２４ａにコピーして記録する。

ここで、対話処理装置２０が「どのような食材を用いた料理を食べたいですか？（出力文３）」と出力したような場合には、「ジャンル」および「食材」をスムーズに特定する観点からは、ユーザとしては、「日本料理が食べたい。」や「ラーメンが食べたい。」、「中華が食べたい。」等の返事を入力することが好ましい。しかしながら、図１４に示す例では、ユーザが「海の近くに来たから、魚介類が食べたいな。（入力文４）」と応答したものとする。

かかる入力文が入力されると、対話処理装置２０の音声認識部２６ａでは、かかる入力文に対して文章解析および流通言語語彙分解を行うことで、「海」、「魚介類」という入力流通言語語彙を抽出する。そして、この段階で、音素メモリ部２６ｂは、「海」、「魚介類」の入力流通言語語彙を蓄える。

さらに、対話処理装置２０は、図１４に例示するように、「どのようなジャンルの料理が食べたいですか？（出力文４）」とユーザ１００に尋ねる。これに対して、ユーザが「日本料理がいいな。（入力文５）」と答えると、対話処理装置２０の音声認識部２６ａでは、かかる入力文に対して文章解析および流通言語語彙分解を行うことで、「日本料理」という入力流通言語語彙を抽出し、音素メモリ部２６ｂは、これを蓄える。

このようにして、ユーザに入力を促した二つのサブドメインが得られたので、これらの「海」、「魚介類」および「日本料理」の入力流通言語語彙はバリュー特定部２６ｇに送られる。そして、バリュー特定部２６ｇでは、入力された入力流通言語語彙の「海」、「魚介類」および「日本料理」と、キャッシュメモリ２４ａに一時記憶されているインデックスキャッシュ１４ｄの流通言語語彙とを照合し、照合により合致した一または複数の流通言語語彙に基づいて、さらに「食事」というドメインの中の話題（すなわち、バリュー）を特定する。

しかしながら、上記の「海」や「魚介類」という入力流通言語語彙は、インデックスキャッシュ１４ｄのバリューデータには合致しない。そこで、バリュー特定部２６ｇでは、対話処理装置２０に予め備えられた類義語辞書、同義語辞書、類推検索辞書を用いて、ユーザが意図している流通言語語彙を探索する。その結果、上記の場合には、インデックスキャッシュ１４ｄ中の「魚」が候補として浮上する。ここで、類義語辞書等を利用することで候補に挙がるバリューデータは、対話処理装置２０による検索で８０％以上の確率でユーザが意図している流通言語語彙であることが認められたものに限定され、この確率には、ドメインに関連付けられた類義語辞書、同義語辞書、類推検索辞書にそれぞれ付されている、ドメイン毎に固有の確率を用いる。

この例では、導き出した「魚」というバリューデータがユーザの意図したものと合致する可能性は、８０％以上であったが１００％ではなかったとする。この場合には、対話制御部２６ｅは、発話テンプレート部２６ｄに含まれているフォーマットを起動し、ユーザに対して、「魚の料理が食べたいのですか？（出力文５）」と確認する。これに対して、ユーザは、「そうだよ。（入力文６）」と答える。

このようにして、「食材」のサブドメインのバリューデータは「魚」であることが確定する。しかしながら、図５に例示するように、「魚」を含むバリューは複数存在する。一方、「日本料理」の入力流通言語語彙は、インデックスキャッシュ１４ｄ内のバリューデータの「日本料理」と合致した。そして、この「日本料理」のバリュー番号を見ると、Ｔ１とＴ４の二つである。

これによって、バリュー特定部２６ｇでは、インデックスキャッシュ１４ｄの「魚」と「日本料理」のバリュー番号を用いて、「魚」と「日本料理」のバリュー番号の集合を求める。つまり、「魚」のバリューデータを含んだバリューのバリュー番号と、「日本料理」のバリューデータを含んだバリューのバリュー番号とから、両方にあるバリュー番号を探す。その結果、バリュー特定部２６ｇでは、Ｔ１のバリューを特定する。

そして、対話処理装置２０の対話制御部２６ｅは、特定したバリューのタイトルをユーザに対して応答する。具体的には、図１４に例示するように、「新東京寿司はいかがですか？（出力文６）」と尋ねる。これは、「バリューが特定された場合には、プロパティａの内で「タイトル」のサブドメインに相当するものを出力する」というプログラムが対話制御部２６ｅに組まれているからである。このようにして、複数あるバリューのなかからユーザが意図するバリューＴ１が一応特定される。

このようにしてバリューが特定されると、回答データ特定部２６ｈでは、特定されたバリューのプロパティ（サブドメイン）と、特定したバリューのデータとを外部記憶部２５から呼び出し、かかるバリューの内容をいつでもユーザに答えられるように準備する。つまり、ユーザが入力する入力音声から入力流通言語語彙を抽出するために、音素メモリ部２６ｂにそれぞれのサブドメインに対するバリューデータを記録し、回答データ特定部２６ｈは、音素メモリ部２６ｂに記録されたデータ（特定したバリューの内容）を用いてユーザと対話を進めていく。

なお、音素メモリ部２６ｂに記録されるバリューデータの数が多いと照合に長い時間を要するようになる。そこで、音素メモリ部２６ｂでは、照合時間が３秒以内に収まる量のバリューデータのみが保存されるようになっている。また、回答データ特定部２６ｈでは、３秒以内に照合できない場合に、ユーザに聞き返したり、更なる質問をするなどして、対話が途切れないようにしている。

上記したように、対話処理装置２０が「新東京寿司はいかがですか？（出力文６）」と出力したのに対して、ユーザは、車を運転しているところなので、「駐車場は、あるの？（入力文７）」と対話処理装置２０に尋ねたとする。この場合、対話処理装置２０の音声認識部２６ａは、かかる入力文から「駐車場」という入力流通言語語彙を抽出して音素メモリ部２６ｂに記録する。そして、回答データ特定部２６ｈでは、音素メモリ２６ｂに記録しているプロパティａに含まれるサブドメインに、音素メモリ部２６ｂに記録された入力流通言語語彙に当てはまるものがあるかどうかが照合するが、ここでは、当てはまる流通言語語彙が無いので、他のプロパティ（具体的には、図５に例示するプロパティｂやプロパティｃ）をドメイン化ＤＢ１４ｂから呼び出す。

その結果、回答データ特定部２６ｈは、ドメイン化ＤＢ１４ｂのプロパティｂの中に「駐車場」のサブドメインを見つけるので、「駐車場」のサブドメインのバリューデータをドメイン化ＤＢ１４ｂに読みに行く。そして、この場合には、Ｔ１のバリューの「駐車場」のサブドメインには「無し」というバリューデータが入っているので、対話制御部２６ｅは、発話テンプレート部２６ｄに記録されたフォーマットを用いて「駐車場は無いです。（出力文７）」という出力文を出力する。

そして、かかる出力文に対して、ユーザが「中華料理でも良いよ。（入力文８）」と答えたとすると、上記のバリュー特定に用いた検索条件が変更されたことになるので、この場合には、対話処理装置２０では、改めてバリューを特定する。すなわち、この場合には、音素メモリ２６ｂでは、先に入力された「日本料理」に代えて、「中華料理」を、「ジャンル」のサブドメインに入れる。これを受けて、バリュー特定部２６ｇでは、「日本料理」を検索条件から外し、「魚」、「駐車場」および「中華料理」を新たな検索条件としてインデックスキャッシュ１４ｄから検索条件に合致するバリューを検索する。

その結果、Ｔ２のバリューが検索条件に合致するので、対話処理装置２０は「四川創作亭はいかがですか？（出力文８）」とユーザに応答する。これに対して、ユーザが「そこで良いよ。（入力文９）」と答えたとすると、これによって、ドメインが「食事」であり、バリューが「四川創作亭」であると決まる。このようにして複数あるバリューのなかからユーザが意図するバリューが改めて決定され、具体的な対話へと移行する。

ところで、上記した工程で特定されたバリューが一つではなく、複数である場合には、さらに対話の内容を絞るための条件を、ユーザから入力するようにするために、対話制御部２６ｅが機能する。すなわち、対話制御部２６ｅには、上記した工程（一回の工程）でバリューが特定できなかった場合には、さらに未だ特定していない「サブドメイン」の入力を促すプログラムが組み込まれている。そこで、対話処理装置２０は、「どのカテゴリの料理が良いですか？例えば、中華料理には、四川料理、広東料理、上海料理、北京料理があります。また、日本料理には、天ぷら、寿司、鍋料理等があります。どれが宜しいですか？」といった質問をユーザに行う。このようにして、バリューを特定する要素（条件）を多くすることで、ユーザが希望するバリューを確実に特定することが可能になる。

上記したような工程を経てバリューＴ２が特定されると、回答データ特定部２６ｈでは、特定されたバリューＴ２のプロパティ（サブドメイン）と、特定したバリューＴ２のデータとを外部記憶部２５から呼び出し、かかるバリューの内容をいつでもユーザに答えられるように、音素メモリ部２６ｂに記録する。

ここで、例えば、対話処理装置２０が、対話制御部２６ｅに組み込まれたプログラム（バリュー特定後に出力する出力文のプログラム）に基づいて「四川創作亭に行きますか？（出力文９）」と質問したとする。これに対して、ユーザが「四川創作亭に行こう。ところで、何がおいしいの？（入力文１０）」と尋ねたような場合には、対話処理装置２０の回答データ特定部２６ｂでは、かかる入力文を受けて、Ｔ２のバリューのプロパティにおける「お勧め料理」というサブドメインを音素メモリ部２６ｂから検索し、このサブドメインに対応する「エビチリ」というバリューデータを回答データとして特定する。その結果、対話制御部２６ｅは、「エビチリがお勧めです。（出力文１０）」と答える。

また、ユーザが「写真があれば、見たいな。（入力文１１）」と入力したような場合には、対話処理装置２０の回答データ特定部２６ｂでは、かかる入力文を受けて、Ｔ２のバリューのプロパティにおける「参考写真」というサブドメインを音素メモリ部２６ｂから検索し、このサブドメインに対応する写真データ「Ｂ２」のバリューデータを回答データとして特定する。その結果、対話制御部２６ｅは、「写真を表示します。車を止めてから見て下さい。（出力文１１）」とユーザに答える。このようにして、対話処理装置２０では、特定されたバリューのサブドメインを参照しつつ、ユーザとの対話を実行する。なお、かかる対話の途中で、ドメインやバリューが変わったような場合には、ドメイン特定部２６ｆおよびバリュー特定部２６ｇは、再度ドメインやバリューを特定し、ユーザとの対話を滑らか、かつ、高速に行う。

［４：対話処理に用いるデータの収集］
次に、図１５などを用いて、対話処理に用いられるバリューデータやドメイン化ＤＢ１４ｂ自体のデータを、新たにネットワークを介して収集するシステムを説明する。つまり、上記の対話処理装置２０では、ドメイン化ＤＢ作成装置１０によって予め作成したドメイン化ＤＢ１４ｂを外部記憶部２５に格納して対話処理を行う場合を説明したが、ここでは、かかるドメイン化ＤＢ１４ｂをネットワーク経由で補充する場合を説明する。なお、以下では、かかるバリューデータの収集処理およびドメイン化ＤＢ１４ｂの収集処理を行うバリュー収集システムの構成を説明した後に、各収集処理の流れを説明する。

（１）情報収集システムの構成
図１５は、情報収集システムの構成を示すブロック図である。同図に示すように、この情報収集システムは、上記した対話処理装置２０と、中央管理センタの情報収集共有装置３０と、複数のサイト（Ｗｅｂサイト）４０とを、ＬＡＮやインターネット等のネットワークを介して相互に通信可能にして構成される。そして、かかる情報収集システムにおいて、情報収集共有装置３０は、同図に示すように、通信制御部３１と、記憶部３２と、制御部３３とから構成される。

ここで、通信制御部３１は、情報収集共有装置３０と他の外部装置（対話処理装置２０やサイト４０）の間でやり取りする各種情報に関する通信を制御する手段であり、例えば、ユーザの入力文章を対話処理装置２０から受信し、また、ドメイン化ＤＢ１４ｂに含まれるバリューのデータをサイト４０から受信する。

記憶部３２は、制御部２６による各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、特に本発明に密接に関連するものとしては、既存プロパティ３２ａと、新規プロパティ３２ｂと、ＵＲＬ知識体３２ｃと、複数の概念辞書３２ｄとを備える。

このうち、既存プロパティ３２ａおよび新規プロパティ３２ｂは、ネットワーク上のサイト４０から収集した情報を分類する際のプロパティ（図５参照）を規定したものである。具体的には、既存プロパティ３２ａは、サブドメイン（図５参照）が対話処理装置２０から入力されない場合に、入力された入力流通言語語彙を基に集めてくる情報を整理するためのサブドメイン「５Ｗ１Ｈ」が規定されたプロパティのことである。なお、「５Ｗ１Ｈ」とは、Ｗｈｏ（だれが）・Ｗｈｅｎ（いつ）・Ｗｈｅｒｅ（どこで）・Ｗｈａｔ（なにを）・Ｗｈｙ（なぜ）・Ｈｏｗ（どうした）のことである。ただし、このサブドメインは、５Ｗ１Ｈを標準値とするが、ドメインによって固有のプロパティを任意に追加または省略することが可能である。

その一方、新規プロパティ３２ｂは、対話処理装置２０におけるユーザの意向を基に作成されるプロパティのことである。例えば、図５に例示した「プロパティａ」を用いて、入力された入力流通言語語彙を基に収集した情報を分類したいのであれば、ユーザは、対話処理装置２０を介して新規プロパティ３２ｂを「プロパティａ」とする指示を入力する。また、全く別のサブドメインに基づいて分類したいのであれば、ユーザは、その都度新規プロパティ３２ｂを作成することができる。つまり、この場合には、ユーザが複数の入力流通言語語彙を入力すると、これらの入力流通言語語彙がどのサブドメインに属するのかが概念辞書３２ｄを用いて特定され、特定されたサブドメインに基づいて新規プロパティ３２ｂが作成される。

ＵＲＬ知識体３２ｃは、膨大なドメイン（例えば、「食事」や「宿泊施設」、「レジャーランド」等のドメイン）について、各ドメイン固有の一つの事例を指し示すホームページのＵＲＬ（サイト４０のＵＲＬ）と、そのホームページ内における流通言語語彙等の複数のデータとを相互に対応付けて記憶するデータベースであり、上記の既存プロパティ３２ａおよび新規プロパティ３２ｂと同様、情報収集前に予め作成される。

概念辞書３２ｄは、上記したドメイン化ＤＢ作成装置１０における概念辞書１４ａと同様、ドメイン化ＤＢ１４ｂの作成に用いられるデータベースであり、具体的には、図４に例示したように、「事例（図３参照）」が属するドメインの専門家等が予め、当該分野に関係するシチュエーション流通言語語彙、並びに、関係すると思われるシチュエーション流通言語語彙のそれぞれに、サブドメインを対応付けて記憶して構成される。

制御部３３は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部であり、特に本発明に密接に関連するものとしては、語彙分解処理部３３ａと、語彙まとめ部３３ｂと、ＵＲＬ検索部３３ｃと、知識獲得部３３ｄと、Ｗｅｂロボット３３ｅと、動的主要意味抽出部３３ｆと、頻度プログラム部３３ｇとを備える。

このうち、語彙分解処理部３３ａは、ユーザが対話処理装置２０から入力した入力文章に対して文章解析および流通言語語彙解析を行って、意味のある流通言語語彙を抽出する処理部である。ただし、図１５に示した例では、対話処理装置２０を介してユーザと情報収集共有装置３０とが繋がっているので、この場合には、語彙分解処理部３３ａは起動していない。つまり、この場合には、対話処理装置２０において、既に文章解析および流通言語語彙解析が行われているので、あえて語彙分解処理部３３ａは起動する必要はなく、ユーザが情報収集共有装置３０に対して入力文章を直接入力するような場合に限って、語彙分解処理部３３ａは起動する。したがって、図１５に示す例では、対話処理装置２０から入力された流通言語語彙等のデータは、後述の語彙まとめ部３３ｂに伝えられる。

語彙まとめ部３３ｂは、入力された入力流通言語語彙を基に集めてくる情報を、どのようなサブドメインに従って分類するか、つまり、どのようなプロパティに従って分類するかを決定する処理部である。具体的には、後述する動的主要意味抽出部３３ｆによる処理に際して、上記した既存プロパティ３２ａおよび新規プロパティ３２ｂに基づいて決定する。

ＵＲＬ検索部３３ｃは、上記したＵＲＬ知識体３２ｃと密接に繋がっており、入力された入力流通言語語彙を基にして情報を収集する際に、どのＵＲＬを用いて、どのホームページにアクセスするのかを決定する処理部である。具体的には、入力された流通言語語彙をＵＲＬ知識体３２ｃに当てはめて、合致する流通言語語彙数の多いＵＲＬを一つ決定する。

知識獲得部３３ｄは、ＵＲＬ検索部３３ｃで決定されたＵＲＬを基にして、情報を収集する処理部である。具体的には、決定されたＵＲＬを用いて、サイト４０のホームページにアクセスし、図３に例示したようなデータ（事例データ）を収集する。

Ｗｅｂロボット３３ｅは、ＵＲＬ検索３３ｃで決定されたＵＲＬを基にして、当該ＵＲＬのデータ（ホームページ上のデータ）を取り込み、そのデータの中にあるリンク付けされたＵＲＬを取り出し、さらに、当該ＵＲＬを基にしてデータをＵＲＬ知識体３２ｃに取り込む処理部である。つまり、このＷｅｂロボット３３ｅは、自立型のロボットであり、ユーザの意志に従って動くものではなく、情報収集共有処理装置３０がユーザによってアクセスされていない場合などに、ＵＲＬ知識体３２ｃを拡張する作業を行っている。

動的主要意味抽出部３３ｆは、ネットワークを介して知識獲得部３３ｄが収集した情報を、語彙まとめ部３３ｂで決定したプロパティを基に分類し、一つのバリューを作成する処理部である。つまり、語彙まとめ部３３ｂで決定したプロパティに対して、一つの事例に関する一のバリューを作成する（図５参照）。なお、作成した一組のプロパティとバリューは、対話処理装置２０に送信されて、ドメイン化ＤＢ１４ｂに更新格納される。

頻度プログラム部３３ｇは、いわゆる時間遅延学習プログラムを有する。この時間遅延学習プログラムは、一定回数以上、ユーザから情報収集共有処理装置３０に対して同一の事例、または同一のドメインに関する情報を収集するようにアクセス要求があった場合に、起動するように設定されているプログラムである。つまり、例を挙げれば、「同一ドメインに対して一週間で５回以上アクセスがあったとき」のような設定がされている。

そして、この時間遅延学習プログラムは、ドメイン固有の概念辞書３２ｄを用いて、ドメイン固有のドメイン化ＤＢ１４ｂを作成するプログラムであり、このドメイン化ＤＢ１４ｂの作成・構築を、人間の意志に関係なく実行する。このため、ドメイン化ＤＢ１４ｂを作成した時点で、情報収集共有装置３０は、対話処理装置２０のユーザに対して、新規に構築したドメイン化ＤＢ１４ｂを対話処理装置２０の外部記憶部２５に新規に登録するか否かを質問する。そして、この質問によって始まるユーザとの対話の中で、ユーザは新規に構築したドメイン化ＤＢ１４ｂを修正することもでき、また、プロパティを修正して再構築することもできる。このようにして、対話処理装置２０は、ユーザの意向に沿って構築した新規のドメイン化ＤＢ１４ｂを構築し、これを外部記憶装置部２５に保存することができる。もちろん、新規に構築したドメイン化ＤＢ１４ｂが不要である場合には、ユーザはその旨を対話処理装置２０に入力することで、これを削除することもできる。

なお、上述してきた情報収集共有装置３０は、既知のパーソナルコンピュータ、ワークステーション、携帯電話、ＰＨＳ端末、移動体通信端末またはＰＤＡなどの情報処理装置に、上記した記憶部３２および制御部３３の各機能（プログラムやデータ）を搭載することによって実現することもできる。また、ここでは、上記の対話処理装置２０と情報収集共有装置３０とを別個に構成する場合を例に挙げたが、情報収集共有装置３０の機能を対話処理装置２０に組み込むことで、これらをユーザコンピュータとして一体として構成するようにしてもよい。

（２）バリュー収集処理
続いて、図１６を用いて、図１５に示した情報収集システムによるバリュー収集処理を説明する。図１６は、かかるバリュー収集処理の流れを示すフローチャートである。

同図に示すように、対話処理装置２０は、ある事例について情報を収集するようにユーザから要求があると、かかる要求に係る入力文章を情報収集共有装置３０に送信する（ステップＳ１６０１）。つまり、例を挙げれば、「新東京寿司の情報を収集して欲しい。」といった入力文章を送信する。

これを受けて、情報収集共有装置３０では、入力文章に対して文章解析および流通言語語彙解析を行って、意味のある流通言語語彙を抽出する（ステップＳ１６０２）。つまり、上記の例で言えば、「新東京寿司の情報を収集して欲しい。」という入力文章から「新東京寿司」という入力流通言語語彙を抽出する。なお、ここでは、情報収集共有装置３０で語彙解析を行う場合を説明したが、上記したように、対話処理装置２０で語彙解析を済ませておいてもよい。

続いて、情報収集共有装置３０は、入力された入力流通言語語彙を基にして情報を収集する際に、どのＵＲＬを用いて、どのホームページにアクセスするのかを決定し（ステップＳ１６０３）、この決定したＵＲＬを基にして情報を収集する（ステップＳ１６０４）。つまり、上記の例で言えば、「新東京寿司」のホームページ等にアクセスして、図３に例示したようなデータ（事例データ）を収集する。

さらに、情報収集共有装置３０は、上記で収集した情報を所定のプロパティを基に分類して一つのバリューを作成し（ステップＳ１６０５）、これを対話処理装置２０に送信する（ステップＳ１６０６）。つまり、上記の例で言えば、図５に例示したようなバリューを「新東京寿司」に関して作成し、作成した一組のプロパティとバリューとを対話処理装置２０に送信する。

これを受けて、対話処理装置２０では、情報収集共有装置３０から受信した一組のプロパティとバリューとをドメイン化ＤＢ１４ｂに新規に登録する（ステップＳ１６０７）。つまり、上記の例で言えば、図５に例示したような「新東京寿司」のバリューを、「食事」のドメイン化ＤＢ１４ｂに格納する。

（３）ドメイン化ＤＢ収集処理
続いて、図１７を用いて、図１５に示した情報収集システムによるドメイン化ＤＢ１４ｂの収集処理を説明する。図１７は、かかるドメイン化ＤＢ収集処理の流れを示すフローチャートである。

同図に示すように、情報収集共有装置３０は、ドメイン化ＤＢ１４ｂの作成条件を満たす状況になった場合に（ステップＳ１７０１肯定）、すなわち、例を挙げれば、一定回数以上、ユーザから情報収集共有処理装置３０に対して同一のドメインに関する情報を収集するようにアクセス要求があった場合に、かかるドメインについてドメイン化ＤＢ１４ｂを作成する（ステップＳ１７０２）。

具体的に例を挙げれば、「食事」のドメインについて作成条件を満足したような場合には、食事に関する複数のＵＲＬを基にして情報を収集した後、収集した情報を「食事」固有の概念辞書３２ｄを用いて分類することで、図５に例示したような「食事」のドメイン化ＤＢ１４ｂを作成する。

続いて、情報収集共有装置３０は、対話処理装置２０のユーザに対して、新規に構築したドメイン化ＤＢ１４ｂを対話処理装置２０の外部記憶部２５に新規に登録するか否かを質問し、新規に登録する場合には、かかるドメイン化ＤＢ１４ｂのデータを対話処理装置２０に送信する（ステップＳ１７０３）。

これを受けて、対話処理装置２０では、情報収集共有装置３０から受信した新規のドメイン化ＤＢ１４ｂを外部記憶装置部２５に格納する（ステップＳ１７０４）。また、対話処理装置２０は、ドメイン化ＤＢ１４ｂが保存されると、このドメイン化ＤＢ１４に関するバリュー特定データ（インデックスファイル１４ｃ、インデックスキャッシュ１４ｄ）およびドメイン特定データ（語彙ＤＢ１４ｅ、重要語彙ＤＢ１４ｆ）を作成し、これを外部記憶部２５に格納する（ステップＳ１７０５およびＳ１７０６）。

この作成処理は、上記したドメイン化ＤＢ作成装置１０による処理と基本的に同様である。つまり、インデックスファイル１４ｃは、ドメイン化ＤＢ１４ｂ内のバリューデータを集めたものであるので自動的に作成される。しかし、インデックスキャッシュ１４ｄはバリューデータに使用頻度が付されるので、対話処理装置２０が勝手に構築するのは不可能であり、そのため、対話処理装置２０は、ユーザに聞きながらインデックスキャッシュ１４ｄに入れるバリューデータを決定する。例えば、「サブドメイン「何々」に関するバリューデータをインデックスキャッシュに入れますか？」等と質問をして、ユーザに入力を促すことでインデックスキャッシュ１４ｄにバリューデータを入れることができる。この場合には、使用頻度は、全て最も高い値、例えば１００％にしておくように設定することが望ましい。これは、使用する度に、使用頻度が変わり、望みのインデックスキャッシュ１４ｄが形成されるからである。

なお、インデックスキャッシュ１４ｄには、当初は何のデータを入れておかないようにしてもよい。つまり、空のままでも良い。この場合には、使用される度にインデックスファイル１４ｃからインデックスキャッシュ１４ｄにバリューデータがコピーされて、インデックスキャッシュ１４ｄが成長していくので、自己成長型であるインデックスキャッシュ１４ｄの特性を利用することにつながる。

［５：対話処理に用いるデータの共有］
次に、図１８などを用いて、対話処理に用いられるドメイン化ＤＢ１４ｂを、ネットワークを介して共有するシステムを説明する。つまり、上記の対話処理装置２０では、外部記憶部２５に記憶したドメイン化ＤＢ１４ｂを用いて対話処理を行う場合を説明したが、ここでは、ネットワークを介して接続される他ユーザの対話処理装置２０におけるドメイン化ＤＢ１４ｂを用いて対話処理を行う場合を説明する。なお、以下では、かかるドメイン化ＤＢ１４ｂを共有する情報共有システムの構成を説明した後に、情報共有処理に至る流れと、具体的な情報共有処理の流れとを説明する。

（１）情報共有システムの構成
図１８は、情報共有システムの構成を示すブロック図である。同図に示すように、この情報共有システムは、複数の上記した対話処理装置２０と、中央管理センタの情報収集共有装置３０とを、ＬＡＮやインターネット等のネットワークを介して相互に通信可能にして構成される。そして、かかる情報共有システムにおいて、対話処理装置２０は、共有化処理部（ネットワークデータ）２７をさらに備える。

かかる共有化処理部２７は、各ユーザ端末、各家、会社単位で設置可能な独立した共有化技術、つまり、分散されて、または遠隔地にある自己、または他人の情報（すなわち、世の中にある複数のドメイン化ＤＢ１４ｂ）を共有化するための技術であり、各対話処理装置２０において共有化処理部２７が外部に相互に開かれて設置されている。ただし、ドメイン化ＤＢ１４ｂを、各々の対話処理装置２０で利用するためにはそれに対応したインデックスキャッシュ１４ｄが必要であり、それぞれのドメイン化ＤＢ１４ｂにはインデックスキャッシュ１４ｄが同様に設けられている。また、ドメイン化ＤＢ１４ｂからインデックスキャッシュ１４ｄを作る際に必要不可欠であるインデックスファイル１４ｃも同様に設けられているが、図１８では図示を省略している。

また、上記の情報共有システムにおいては、各ユーザのドメイン化ＤＢ１４ｂ、インデックスキャッシュ１４ｄおよびインデックスファイル１４ｃを、各ユーザが互いに直接アクセスして利用可能であるが、利用頻度が高い場合や、他の対話処理装置２０のドメイン化ＤＢ１４ｂを自己の好みに合わせて作り変えたいような場合等には、他の対話処理装置２０のドメイン化ＤＢ１４ｂをコピーして自己の対話処理装置２０にダウンロードすることも可能であり、共有化処理部２７は、かかるダウンロードの処理も実行する。

そして、このように、ドメイン化ＤＢ１４ｂをコピーすることが可能であることから、ドメイン化ＤＢ１４ｂの原本がどこにあったものなのか、または、原本がどこにあるものなのかを示す端末番号（ユーザＩＤなど）が、ドメイン化ＤＢ１４ｂ自体だけでなく、インデックスキャッシュ１４ｄおよびインデックスファイル１４ｃの全てのデータに付されている。これによって、ドメイン化ＤＢ１４ｂ等がネットワーク上でコピーされても、いつでも原本に容易に行き着くことが可能になる。

さらに、コピーしたドメイン化ＤＢ１４ｂを修正したり、改善した場合に、これに対応させて原本を更新することも可能である。すなわち、複数の対話処理装置２０（ユーザコンピュータ）を繋いで、一つのドメイン化ＤＢ１４ｂを共有する際には、それぞれの対話処理装置２０でドメイン化ＤＢ１４ｂがコピーされて使用される。そして、これが使用された結果、ドメイン化ＤＢ１４ｂにおいては、バリューデータが修正され、さらに増加され、改善される。そこで、これらの使用が終わった後、ドメイン化ＤＢ１４ｂに起動をかけるプログラムが共有化処理部２７には組み込まれており、改善されたドメイン化ＤＢ１４ｂの内容が原本のドメイン化ＤＢ１４ｂに反映される。このように、ドメイン化ＤＢ１４ｂが共有されて使用されることによって、ドメイン化ＤＢ１４ｂは進化し、時代遅れになることなく、常に最新の情報で満たされているようにすることが可能になる。

（２）情報共有処理に至る流れ
続いて、図１９を用いて、他の対話処理装置２０におけるドメイン化ＤＢ１４ｂを共有処理に至る流れを説明する。図１９は、かかる情報共有処理に至る流れを示すフローチャートである。

同図に示すように、あるユーザＡの対話処理装置２０は、あるドメインに関するドメイン化ＤＢ１４ｂの検索要求を情報収集共有装置３０に対して送信する（ステップＳ１９０１）。つまり、例を挙げると、後述するように、他のユーザの対話処理装置２０にある「地質学」のドメイン化ＤＢ１４ｂの検索要求を送信する。

これに対して、情報収集共有装置３０は、ＵＲＬ知識体３２ｃから検索要求に係るドメイン化ＤＢ１４ｂが存在している所在場所を検索する（ステップＳ１９０２）。つまり、上記の例で言えば、地質学のドメイン化ＤＢ１４ｂを有するユーザＢの対話処理装置２０のＵＲＬ情報を検索する。そして、情報収集共有装置３０は、検索されたＵＲＬ情報（ユーザＢの対話処理装置２０の所在情報）をユーザＡの対話処理装置２０に送信する（ステップＳ１９０３）。

これを受けて、ユーザＡの対話処理装置２０では、情報収集共有装置３０から受信したＵＲＬ情報（ユーザＢの対話処理装置２０の所在情報）を基にして、ユーザＢの対話処理装置２０にアクセス要求を送信する（ステップＳ１９０４）。これに対して、ユーザＢの対話処理装置２０がアクセス要求を許可することで（ステップＳ１９０５）、情報共有化が図られる。つまり、ユーザＡの対話処理装置２０は、ユーザＢの対話処理装置２０にある「地質学」のドメイン化ＤＢ１４ｂを自己のドメイン化ＤＢ１４ｂのように利用して、ユーザＡとの間で「地質学」に関する対話処理を実行する。

（３）具体的な情報共有処理の流れ
続いて、上記した情報共有システムによる具体的な情報共有処理の流れを説明するが、ここでは、図１８に例示するように、ユーザＡが、対話処理装置２０が設置されている自家用車に居る場合を具体例として説明する。すなわち、同図に例示するように、自家用車の対話処理装置２０は、他のユーザＢが居る民家の対話処理装置２０や、中央管理センタ内の情報収集共有装置３０と、ネットワークを介して接続され、各対話処理装置２０では、共有化処理部２７が外に向かって、また、内に向かって開かれている。

ユーザＡは、共有化処理部２７を介して、他のコンピュータにあるデータベースを有効に活用することが可能である。ここで、例えば、ユーザＡの対話処理装置２０には、カーナビゲーションシステムで有効に用いられる「レジャーランド」、「宿泊施設」、「食事」のドメインに関するドメイン化ＤＢ１４ｂ等のデータが保存されているとする。つまり、ユーザＡは、カーナビゲーションシステムとしてのみ、ドメイン化ＤＢ１４ｂを利用するのであれば、不自由は感じないが、ユーザＡが旅をしている途中で、フィールドワークを行ったような場合には、フィールドワークに必要な情報を旅先で利用する必要性も生じている。以下では、このような必要性が生じた場合の情報共有処理を具体的に説明する。

例えば、ユーザＡは、植生を調べるために海岸線を探索していたが、１年前には無かった崖を発見した。そして、ユーザＡは、海岸線で露出している断層を発見し、断層から地層ごとにサンプルを採取し、このサンプルを、持ち運び可能な分析器等によって分析した。しかしながら、ユーザＡは、地質学の専門家ではないため、分析結果を判断することができない。そこで、ユーザＡは、対話処理装置２０の情報共有化部２７を介して、他のユーザの対話処理装置２０にある「地質学」のドメイン化ＤＢ１４ｂを利用することを思いついた。

ここで、ユーザＢのドメイン化ＤＢ１４ｂには、地質学に関する膨大なデータが、ユーザＢが入力したサブドメインを配列したプロパティに基づいて整然と分類保存されている。また、地質調査に関して利用頻度の高い流通言語語彙が収められたインデックスキャッシュ１４ｄがドメイン化ＤＢ１４ｂの検索用に構築されている。また、これらのユーザＢのデータは、共有化処理部２７を介して外に開かれているため、ユーザＡは、自家用車のカ−ナビ（対話処理装置２０）を介して、ユーザＢのドメイン化ＤＢ１４ｂやインデックスキャッシュ１４ｄを自己のデータベースのごとく利用することができる。

しかしながら、ユーザＢのドメイン化ＤＢ１４ｂがどこにあるのかをユーザＡは知らない。そこで、ユーザＡは対話処理装置２０を介して、中央管理センタの情報収集共有装置３０にアクセスし、ＵＲＬ知識体３２ｃに地質学のドメイン化ＤＢ１４ｂがどこに存在しているのかを検索に行く。そして、このＵＲＬ知識体３２ｃには、ＵＲＬばかりでなく、そのＵＲＬを利用して作成されたドメイン化ＤＢ１４ｂの原本の所在情報が記録されている。このため、情報収集共有装置３０は、原本の所在情報を示すＵＲＬ情報（ユーザＢの対話処理装置２０の所在情報）をユーザＡの対話処理装置２０に送信する。これによって、ユーザＡは、ユーザＢの対話処理装置２０に地質学のドメイン化ＤＢ１４ｂが存在していることを確認することができる。

そして、ユーザＡの対話処理装置２０は、情報収集共有装置３０から受信したＵＲＬ情報（ユーザＢの対話処理装置２０の所在情報）を基にして、ユーザＢの対話処理装置２０にアクセスし、ユーザＢによって「地質学」のドメイン化ＤＢ１４ｂに対するアクセスが許可されれば、かかるドメイン化ＤＢ１４ｂを自己のドメイン化ＤＢ１４ｂのように利用して、ユーザＡとの間で「地質学」に関する対話処理を実行する。

かかる対話処理に際して、ユーザＢの対話処理装置２０におけるインデックスキャッシュ１４ｄは、ユーザＡから真っ先にアクセスされる入り口の役目を果たし、ユーザＡが意図する流通言語語彙からドメインを特定する。これによって、ユーザＢのドメイン化ＤＢ１４ｂからユーザＡは必要なデータを迅速に取り出して、解析結果を導き出すことができるようになる。これは、ドメイン化ＤＢ１４ｂへの高速検索を可能にするインデックスキャッシュ１４ｄが共有化処理部２７（ネットワークデータ）を介して窓口になっているからである。これによって、インターネット等の通信回線を通じて提供されるデータ量が少なく、かつ、検索が速やかに行われ、通信に要する時間が短時間で済むようになる。なお、具体的には、一つの情報を検索するために要する時間は数ｍｓ程度である。

このように、各対話処理装置２０の共有化処理部２７を介して、分散環境にある他のドメイン化ＤＢ１４ｂを自己のドメイン化ＤＢ１４ｂのように利用することが可能になる。しかしながら、特定の者にのみ利用を許して、自己のドメイン化ＤＢ１４ｂの秘密性を保つことも可能である。すなわち、各対話処理装置２０において、共有化処理部２７が一番外に設置されているので、かかる共有化処理部２７で特定のコードを有する対話処理装置２０（特定のユーザ）からのアクセスのみを受け入れるようにセキュリティーを設けることも可能である。これによって、情報の安全な運用が可能になる。

なお、図１５を用いて説明した情報収集システムにおいても、上記したようなセキュリティーを設けた共有化処理部２７を各サイト４０が備えることで、情報収集を制限することが可能である。例えば、プロパティに手を加えるためには、共有化処理部２７を介して中央管理センタにアクセスして、認可を得なければならないようにしてもよい。この場合、この認可は、共有化処理部２７の設置時の契約によって設けるだけではなく、ユーザからの要望によって設けることもできる。なぜならば、対話処理装置２０が共有に係る場合等に、他のユーザによって勝手に新規のドメイン化ＤＢ１４ｂが構築されたり、既存のドメイン化ＤＢ１４ｂ内の情報が更新されたりしないようにするためである。

上述してきたように、ドメイン化ＤＢ１４ｂを用いて、有効に情報探索を行い、かつ、セキュリティー管理を万全にしながら、人間とコンピュータとの自然な対話を実現することが可能になる。また、上記した内容を、他の領域、例えば、老人介護への適用、遠隔地医療への適用、留守宅のセキュリティーシステムへの適用、遠隔教育への適用に用いることで、地理的または時間的な差の無いサービスの提供を行うことが可能になる。

［６：他の実施例］
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

例えば、本実施例では、音声入力による入力文を処理する場合を説明したが、本発明はこれに限定されるものではなく、キーボードを介して入力されたテキストの入力文を処理する場合でも同様に適用することができる。また、本実施例では、音声出力によって出力文を出力する場合を説明したが、本発明はこれに限定されたものではなく、モニタに出力文をテキストで表示する場合にも同様に適用することができる。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（特に、図３〜図５等に例示した情報）については、特記する場合を除いて任意に変更することができる。

また、図示した各装置（ドメイン化ＤＢ作成装置１０、対話処理装置２０、情報収集共有装置３０）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置（ドメイン化ＤＢ作成装置１０、対話処理装置２０、情報収集共有装置３０）の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

なお、本実施例で説明した各種の知識処理（例えば、ドメイン化ＤＢの作成処理、対話処理、情報収集処理、情報共有処理など）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上のように、本発明に係る知識処理装置、知識処理方法および知識処理プログラムは、入力文を解析して当該入力文に対する出力文を出力する場合に有用であり、特に、ユーザの多種多様で柔軟な入力文（質問文）に対して機動的に応答して、円滑かつ高速な対話処理を行うことに適する。

本実施例の概要および特徴を説明するための図である。 ドメイン化ＤＢ作成装置の構成を示すブロック図である。 事例を構成する情報の具体例を示す図である。 概念辞書に記憶される情報の構成例を示す図である。 ドメイン化ＤＢに記憶される情報の構成例を示す図である。 ドメイン化ＤＢ作成処理の流れを示すフローチャートである。 インデックスファイルに記憶される情報の構成例を示す図である。 インデックスキャッシュに記憶される情報の構成例を示す図である。 語彙ＤＢに記憶される情報の構成例を示す図である。 重要語彙ＤＢに記憶される情報の構成例を示す図である。 対話処理装置の構成を示すブロック図である。 対話処理の概略を説明するための図である。 対話処理の概略を示すフローチャートである。 対話処理の具体例を示す図である。 情報収集システムの構成を示すブロック図である。 バリュー収集処理の流れを示すフローチャートである。 ドメイン化ＤＢ収集処理の流れを示すフローチャートである。 情報共有システムの構成を示すブロック図である。 情報共有処理に至る流れを示すフローチャートである。

符号の説明

１０ ドメイン化ＤＢ作成装置
１１ 入力部
１２ 出力部
１３ 通信制御部
１４ 記憶部
１４ａ 概念辞書
１４ｂ ドメイン化ＤＢ
１４ｃ インデックスファイル
１４ｄ インデックスキャッシュ
１４ｅ 語彙ＤＢ
１４ｆ 重要語彙ＤＢ
１５ 制御部
１５ａ データマイニング部
１５ｂ バリュー特定データ作成部
１５ｃ ドメイン特定データ作成部
２０ 対話処理装置
２１ 入力部
２２ 出力部
２３ 通信制御部
２４ 記憶部
２４ａ キャッシュメモリ
２５ 外部記憶部
２６ 制御部
２６ａ 音声認識部
２６ｂ 音素メモリ
２６ｃ 音声合成部
２６ｄ 発話テンプレート部
２６ｅ 対話制御部
２６ｆ ドメイン特定部
２６ｇ バリュー特定部
２６ｈ 回答データ特定部
２７ 共有化処理部
３０ 情報収集共有装置
３１ 通信制御部
３２ 記憶部
３２ａ 既存プロパティ
３２ｂ 新規プロパティ
３２ｃ ＵＲＬ知識体
３２ｄ 概念辞書
３３ 制御部
３３ａ 語彙分解処理部
３３ｂ 語彙まとめ部
３３ｃ ＵＲＬ検索部
３３ｄ 知識獲得部
３３ｅ Ｗｅｂロボット
３３ｆ 動的主要意味抽出部
３３ｇ 頻度プログラム
４０ サイト

Claims (5)

1. 入力文を解析して当該入力文に対する出力文を出力する知識処理装置であって、
   ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けして記憶するドメイン化データベースと、
   前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定手段と、
   を備えたことを特徴とする知識処理装置。
2. 前記ドメイン化データベースは、前記ドメインが共通する複数の事例ごとに、各事例の文章から抽出された流通言語語彙を、共通するサブドメインにリンク付けして記憶するものであって、
   所定の事例を特定するための入力文から前記サブドメインに対応する複数の入力流通言語語彙を抽出し、当該複数の入力流通言語語彙をいずれも含んで前記ドメイン化データベースに記憶された事例を特定する事例特定手段をさらに備え、
   前記回答特定手段は、前記事例特定手段によって特定された事例について前記ドメイン化データベースに記憶された流通言語語彙のなかから、前記出力文に含める回答を特定することを特徴とする請求項１に記載の知識処理装置。
3. 前記ドメイン化データベースは、複数のドメイン毎に区分けして、各ドメインに属する複数の事例ごとに、各事例の文章から抽出された流通言語語彙を記憶するものであって、
   所定のドメインを特定するための入力文から入力流通言語語彙を抽出し、当該入力流通言語語彙に対応するドメインを特定するドメイン特定手段をさらに備え、
   前記事例特定手段は、前記ドメイン特定手段によって特定されたドメインについて、当該ドメインのサブドメインに対応する複数の入力流通言語語彙を抽出し、当該複数の入力流通言語語彙をいずれも含んで前記ドメイン化データベースに記憶された事例を特定することを特徴とする請求項２に記載の知識処理装置。
4. 入力文を解析して当該入力文に対する出力文を出力する知識処理方法であって、
   ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けしてドメイン化データベースに格納する格納工程と、
   前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定工程と、
   を含んだことを特徴とする知識処理方法。
5. 入力文を解析して当該入力文に対する出力文を出力する方法をコンピュータに実行させる知識処理プログラムであって、
   ある事例の文章から、心理学的な意味を成し得る最小慣用句単位、かつ、当該事例が属するドメインの経験則に基づいたサブドメインにリンク付けされ得る単位で抽出された流通言語語彙を、各サブドメインにリンク付けしてドメイン化データベースに格納する格納手順と、
   前記入力文から抽出された入力流通言語語彙に対応するサブドメインを検索し、当該検索したサブドメインにリンク付けされて前記ドメイン化データベースに記憶された流通言語語彙を、前記出力文に含める回答として特定する回答特定手順と、
   をコンピュータに実行させることを特徴とする知識処理プログラム。

Images