(57)【特許請求の範囲】
【請求項１】
コンピュータ・システムにおいてダイアログ・インターフェースを提供する方法であって、
ユーザ入力を受け取るステップと、
前記ユーザ入力を言語モデルに適用するステップであって、前記ユーザ入力の内容を記述する少なくとも１つの表面的意味を生成し、かつ該少なくとも１つの表面的意味の各々に対するスコアを決定し、各前記少なくとも１つの表面的意味が、少なくとも１つの表面的意味トークンを含む、ステップと、
各前記少なくとも１つの表面的意味を談話モデルに適用するステップであって、ユーザとのダイアログの現状態を記述する少なくとも１つの談話意味を生成し、かつ各該少なくとも１つの談話意味に対するスコアを決定し、各前記少なくとも１つの談話意味が、少なくとも１つの談話意味トークンを含む、ステップと、
各前記少なくとも１つの談話意味を挙動モデルに適用するステップであって、前記コンピュータ・システムがとる少なくとも１つのアクションを定め、かつ各該少なくとも１つのアクションに対するスコアを決定する、ステップと、
前記言語モデルが与える前記スコアと前記談話モデルが与える前記スコアとおよび前記挙動モデルが与える前記スコアとに部分的に基づいて、前記少なくとも１つのアクションのうちの１つを選択して行なうステップと、
を備えた方法。
【請求項２】
請求項１記載の方法であって、更に、
前記ユーザ入力を受け取るステップは、複数のモードのユーザ入力を受け取るステップを含み、
前記ユーザ入力を言語モデルに適用するステップは、
各前記モードのユーザ入力を、当該各モードのユーザ入力に対して用意された言語モデルに適用するステップであって、受け取った各前記モードのユーザ入力に対し、少なくとも１つの表面的意味を生成し、かつ各該少なくとも１つの表面的意味に対してスコアを決定する、ステップ、
を含む、方法。
【請求項３】
請求項１記載の方法において、各前記少なくとも１つの表面的意味を談話モデルに適用するステップは、更に、
談話意味が含む談話意味トークンに対する可能な置換物として、前記談話意味トークンに関連する属性と同じ属性をもつ複数のエンティティをデータベースから検索するステップと、
前記談話意味トークンの前記属性を表す子談話意味トークンとして、前記複数のエンティティを追加して、各前記エンティティに対し別個の談話意味構造を形成するステップと、
各エンティティに関連する各前記談話意味構造に対し、スコアを決定するステップと、を含む、方法。
【請求項４】
請求項１記載の方法において、各前記少なくとも１つの談話意味を挙動モデルに適用するステップは、更に、使用可能なユーザ・インターフェースの識別を前記挙動モデルに適用し、前記使用可能なユーザ・インターフェースと適合するアクションが、前記ユーザ・インターフェースと適合しないアクションよりも総合的に高いスコアを受けるようにするステップを含む、方法。
【請求項５】
請求項１記載の方法であって、
各前記少なくとも１つの談話意味を挙動モデルに適用するステップは、拡張可能スタイルシート言語を用いて設計された挙動モデルを使うことによって、マークアップ言語を用いて記述されるアクションに、マークアップ言語を用いて記述される各前記少なくとも１つの談話意味を変換するステップを含み、使用可能なユーザ・インターフェースに基づいて、前記アクションに対する前記マークアップ言語が選択される、
方法。
【請求項６】
請求項５記載の方法において、各前記少なくとも１つの談話意味の前記マークアップ言語は、拡張可能マークアップ言語であり、マークアップ言語を用いて記述されるアクションに各前記少なくとも１つの談話意味を変換することは、各前記少なくとも１つの談話意味を拡張可能スタイルシート言語変換に適用することを含む、方法。
【請求項７】
請求項６記載の方法であって、更に、
前記使用可能なユーザ・インターフェースを変更する命令をユーザから受け取るステップと、
各前記少なくとも１つの談話意味を第２の拡張可能スタイルシート言語変換に適用して、各前記少なくとも１つの談話意味を、第２マークアップ言語を用いて記述したアクションに変換するステップと、
を含む、方法。
【請求項８】
コンピュータに基づくダイアログ・インターフェースをユーザに提供するシステムであって、
ユーザから入力を受け取り、少なくとも１つのモデルを用いて、少なくとも１つの現ダイアログ状態に対するスコアを生成するダイアログ状態エンジンであって、各前記少なくとも１つの現ダイアログ状態が、談話意味構造によって表され、該談話意味構造が、特定のエンティティの一般的な表現を与える意味トークンを含み、前記スコアが、前記ユーザからの入力と以前のダイアログ状態とに基づき、前記ダイアログ状態エンジンが、
モデルを用いて、前記ユーザ入力に基づいて少なくとも１つの表面的意味に対するスコアを決定する認識エンジンと、
モデルを用いて、前記認識エンジンからの少なくとも１つの表面的意味および以前のダイアログ状態に基づいて、少なくとも１つの現ダイアログ状態に対するスコアを決定する談話エンジンと、
を含む、ダイアログ状態エンジンと、
モデルを用いて、前記少なくとも１つの現ダイアログ状態に基づいて少なくとも１つのアクションに対するスコアを特定するレンダリング・エンジンであって、前記少なくとも１つの表面的意味に対するスコアと前記少なくとも１つの現ダイアログ状態に対するスコアとおよび前記少なくとも１つのアクションに対するスコアとが、前記少なくとも１つのアクションのうちから１つを選択するために使用される、レンダリング・エンジンと、
を備えたシステム。
【請求項９】
請求項８記載のシステムにおいて、前記ダイアログ状態エンジンは、マークアップ言語を用いることによって、前記レンダリング・エンジンに対する前記現ダイアログ状態を記述し、前記レンダリング・エンジンは、前記現ダイアログ状態を記述する前記マークアップ言語を、アクションを記述する第２マークアップ言語に変換する、システム。
【請求項１０】
請求項９記載のシステムにおいて、前記現ダイアログ状態は、拡張可能マークアップ言語を用いて記述され、前記レンダリング・エンジンは、拡張可能スタイルシート言語変換を利用して、前記拡張可能マークアップ言語を前記第２マークアップ言語に変換する、システム。
【請求項１１】
請求項１０記載のシステムにおいて、前記ダイアログ状態エンジンは、更に、ユーザから、前記出力インターフェースを変更したいという指示を受け取り、前記レンダリング・エンジンは、前記出力インターフェースの変更に基づいて、前記拡張可能スタイルシート言語変換を変更して、前記現ダイアログ状態の同じ拡張可能マークアップ言語記述を、前記第２マークアップ言語とは異なる第３マークアップ言語に変換するようにした、システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ユーザ／コンピュータ双方向処理を定義し処理する方法およびシステムに関する。特に、本発明は、ダイアログ・システム(dialog system)に関する。
【０００２】
【従来の技術】
最近のコンピュータ・インターフェースは、その殆ど全てがコンピュータ駆動双方向処理を基本としており、その中ではユーザはコンピュータが設定した実行の流れに従うか、あるいはコンピュータが与える(expose)１つ以上のコマンドを習得しなければならない。言い換えると、殆どのコンピュータ・インターフェースは、ユーザが行ないたいようにコンピュータとインターフェースするようにはなっておらず、逆に特定のインターフェース・セットを通じて双方向処理するようにユーザに強制しているのである。
【０００３】
しかしながら、ダイアログ・メタファー(dialog metaphor)に基づき、ユーザおよびコンピュータ・システム双方がダイアログを導くかまたはこれに従うようなコンピュータ／ユーザ・インターフェースを有するという理念を目標とする新しい研究が行われている。このメタファーの下では、ユーザは、最初の質問またはコマンドを与えることができ、するとコンピュータ・システムは質問またはコマンドにおいて曖昧さを特定し、質問を具体化するように要求して、適正なアクションの推移を確認することができる。尚、具体化の間、ユーザは自由にダイアログを変更し、それを新たな方向に導けることを注記しておく。したがって、コンピュータ・システムは、ダイアログにおけるこれらの変更に適応的であり、反応しなければならない。システムは、ユーザが当該システムに提供した情報を認識し、その情報からユーザの意図を探り出さなければならない。加えて、システムは、ユーザの意図を、補足質問をしたり、電子メール・メッセージを送るというような、適切なアクションに変換しなければならない。
【０００４】
尚、ユーザの経験(experience)の質は、システムがユーザに尋ねる質問数、したがってユーザが目標に到達するのに要する時間量によって殆ど決まってしまうという点で、適正なアクションの選択は重要であることを注記しておく。
【０００５】
従来では、このようなダイアログ・システムは、技術の組み合わせによって作成されていた。通例では、確率的モデルを用いて、ユーザが言ったことを確認する。このようなモデルは、１組の仮説句(hypothesis phrases)の各々に対して確率を与える。次いで、確率が最も高い仮説を、ユーザが発話した可能性が最も高い句として選択する。
【０００６】
この可能性が最も高い句を自然言語解析アルゴリズムに供給し、１組の自然言語規則を適用し、特定した句の文章構造および意味構造を識別する。
次に、意味構造を計画基礎システム(plan based system)に渡し、意味(semantic meaning)、ならびにユーザおよびコンピュータが作った過去のダイアログ・ステートメントに基づいて、異なる１組の規則を適用する。これらの規則の実行に基づいて、ダイアログ・システムは、取るべきアクションを選択する。
【０００７】
システムには、言ったことから言ったことの意味への変換に、確率モデルを用いようとしたものもある。例えば、E.Souvignier et al. の"The Thoughtful Elephant: Strategies for Spoken Dialog Systems"（思慮深い象：発話ダイアログ・システムのための方針）(IEEE Transactions on Speech and Audio Processing, Vol.８, No. 1 （２０００年１月）)において、言ったことを識別するステップ、および言ったことを意味に変換するステップの双方に確率モデルを適用している。
【０００８】
別のシステムには、確率モデルを用いて、与えられた意味に対して取るべきアクションを決定するようにしたものもある。例えば、Levin et al. の"A Stochastic Model for Machine Interaction for Learning Dialog Strategies"（学習ダイアログ方式のマシン双方向処理用確率モデル）(IEEE Transactions on Speech and Audio Processing, Vol. 8, No. 1, pg. 11-23 （２０００年１月）)では、意味からアクションへの変換に、確率モデルが用いられている。
【０００９】
【発明が解決しようとする課題】
確率モデルは各段階に別個に用いられてきたが、ダイアログ・システムの全段階に確率モデルを用い、同じ目的の機能を最適化するように設計したシステムは未だ提案されていない。そのため、これらのダイアログ・システムにおけるサブシステムは、当然互いに統合し合わない。
【００１０】
現行のダイアログ・システムに伴う別の問題は、これらは分散型計算環境に余り適しておらず、サービス品質が完全でないことである。例えば、電話を基本とするダイアログ・システムでは、電話リンクに大きく依存する。通常、電話接続における切断は、ダイアログ・コンテクストおよび双方向処理内容の損失を招く。その結果、電話に基づくシステムのために開発されたダイアログ技術は、対話者(interlocutor)が常に接続を維持しないインターネット環境には、直接適用することはできない。加えて、既存のダイアログ・システムは、通例では、単一デバイス上の固定インターフェースにユーザを強制するので、ユーザがダイアログを駆動する方法が制限される。例えば、現行のダイアログ・システムは、通例では、ユーザがインターネット・ブラウザまたは電話機を用いることを要求し、双方向処理の間ユーザが動的に電話インターフェースまたはハンドヘルド・インターフェースに、またはその逆に切り替えることをユーザに許さない。このように、これらのシステムは、望まれるようなユーザ制御を提供する訳ではない。
【００１１】
【課題を解決するための手段】
本発明は、単一の技術モデルの下でサブシステムを統合した、ダイアログ・システムを提供する。即ち、サブシステムの各々は、確率モデリングを用いて、そのそれぞれの出力に対する確率を特定する。ユーザからの最新の入力および過去のダイアログ状態から、ダイアログ・システムが取るべき最も確率が高いアクションを、確率の組み合わせによって特定する。
【００１２】
具体的には、認識エンジンを設け、ユーザからの入力があると、言語モデルを用いて、表面的意味構造の確率を特定する。また、意味エンジンも設け、表面的意味構造の確率から、談話(discourse)の確率を特定する。最後に、レンダリング・エンジンを設け、挙動モデルを用いて、意味エンジンが与える１つ以上の談話構造に伴う確率から、取るべき最低コストのアクションを決定する。サブシステムの各々において確率モデルを用い、全体として単一の目的機能を最適化するように全ての段階を強制することにより、本発明は、理論的に最適化の簡便化を図った、より良い統合ダイアログ・システムを提供する。
【００１３】
本発明の別の態様は、認識エンジン、意味エンジンおよびレンダリング・エンジンがＸＭＬページを通じて互いに通信することにより、ネットワーク全体にこれらのエンジンを分散可能とする実施形態である。ＸＭＬを用いることにより、ダイアログ・システムは、インターネット用に開発された大規模なインフラストラクチャを利用することができる。
【００１４】
この実施形態では、拡張可能スタイルシート言語（ＸＳＬ：extensible stylesheet language）を用いて、挙動モデルを書くか、あるいは動的に合成する。ＸＳＬによって、挙動モデルは、意味エンジンが生成したＸＭＬページを、意味エンジンのＸＭＬページにおいて見出される談話表現に対して最低コストのアクションであるだけでなく、ユーザが選択した出力インターフェースに適した出力に変換することが可能となる。即ち、挙動エンジンが行なうＸＳＬ変換によって、意味エンジンが出力する単一のＸＭＬページを、例えば、インターネット・ブラウザ、電話システム、またはハンドヘルド・システムに適したフォーマットに変換することが可能となる。このように、この実施形態の下では、ユーザは、どのインターフェースを用いてダイアログを実行するか制御することができ、実際にダイアログの間そのインターフェースを動的に変更することができる。
【００１５】
【発明の実施の形態】
図１は、本発明を実現可能とするのに相応しい計算システム環境１００の一例である。計算システム環境１００は、相応しい計算環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる限定をも示唆しようとするのではない。更に、計算環境１００は、例示の計算環境１００に示すコンポーネントのいずれの１つまたはその組み合わせに関しても、依存性も要件も有するものとして解釈してはならない。
【００１６】
本発明は、多数のその他の汎用または特殊目的計算システム環境またはコンフィギュレーションと共に動作する。公知の計算システム、環境および／またはコンフィギュレーションで、本発明との使用に相応しい例は、限定ではなく、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルドまたはラップトップ・デバイス、マイクロプロセッサ・システム、マイクロプロセッサ系システム、セット・トップ・ボックス、プログラマブル消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、電話システム、上述のシステムまたはデバイスのいずれをも含む分散計算環境等を含む。
【００１７】
本発明の説明は、コンピュータが実行するプログラム・モジュールのようなコンピュータ実行可能命令の一般的なコンテキストで行うこととする。一般に、プログラム・モジュールは、特定のタスクを実行したり、あるいは特定の抽象的データ・タイプを使用する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。また、本発明は、分散型計算機環境において、通信ネットワークを通じてリンクしたリモート処理デバイスによってタスクを実行するという実施も可能である。ある分散型計算機環境においては、プログラム・モジュールは、メモリ記憶素子を含むローカルおよびリモート双方のコンピュータ記憶媒体に配置することができる。
【００１８】
図１を参照すると、本発明を実施するための例示のシステムは、コンピュータ１１０の形態とした汎用計算デバイスを含む。コンピュータ１１０のコンポーネントは、処理ユニット（ＣＰＵ）１２０、システム・メモリ１３０、およびシステム・メモリから処理ユニット１２０までを含む種々のシステム・コンポーネントを結合するシステム・バス１２１を含むことができるが、これらに限定される訳ではない。システム・バス１２１は、種々のバス・アーキテクチャのいずれかを用いたメモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、数種類のバス構造のいずれでもよい。限定ではなく一例として、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、改良ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカル・バス、およびＭｅｚｚａｎｉｎｅバスとしても知られている周辺素子相互接続（ＰＣＩ）バスを含む。
【００１９】
コンピュータ１１０は、通例では、種々のコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータ１１０がアクセス可能であれば、入手可能な媒体のいずれでも可能であり、揮発性および不揮発性双方の媒体、リムーバブルおよび非リムーバブル媒体を含む。一例として、そして限定ではなく、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュールまたはその他のデータのような情報の格納のためのあらゆる方法または技術において使用されている揮発性および不揮発性、リムーバブルおよび非リムーバブル双方の媒体を含む。コンピュータ記憶媒体は、限定する訳ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）、またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、またはその他の磁気記憶装置、あるいは所望の情報を格納するために使用可能であり、コンピュータ１００によってアクセス可能なその他のいずれの媒体でも含まれる。通信媒体は、通例では、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他データを、キャリア波またはその他のトランスポート機構のような変調データ信号におけるその他のデータを具体化し、あらゆる情報配信媒体を含む。「変調データ信号」という用語は、信号内に情報をエンコードするように、その１つ以上の特性を設定または変更した信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体、ならびに音響、ＲＦ、赤外線およびその他のワイヤレス媒体のようなワイヤレス媒体を含む。前述のいずれの組み合わせでも、コンピュータ読み取り可能媒体の範囲内に当然含まれるものとする。
【００２０】
システム・メモリ１３０は、リード・オンリ・メモリ（ＲＯＭ）１３１およびランダム・アクセス・メモリ（ＲＡＭ）１３２のような揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中のように、コンピュータ１１０内のエレメント間におけるデータ転送を補助する基本的なルーチンを含み、通例ではＲＯＭ１３１内に格納されている。ＲＡＭ１３２は、通例では、処理ユニット１２０が直ちにアクセス可能であるデータおよび／またはプログラム・モジュール、または現在処理ユニット１２０によって処理されているデータおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７を示す。
【００２１】
また、コンピュータ１１０は、その他のリムーバブル／非リムーバブル揮発性／不揮発性コンピュータ記憶媒体も含むことができる。一例としてのみ、図１は、非リムーバブル不揮発性磁気媒体からの読み取りおよびこれへの書き込みを行なうハード・ディスク・ドライブ１４１、リムーバブル不揮発性磁気ディスク１５２からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ１５１、ならびにＣＤ  ＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク１５６からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ１５５を示す。動作環境の一例において使用可能なその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、限定する訳ではないが、磁気テープ・カセット、フラッシュ・メモリ・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれる。ハード・ディスク・ドライブ１４１は、通例では、インターフェース１４０のような非リムーバブル・メモリ・インターフェースを介してシステム・バス１２１に接続され、磁気ディスク・ドライブ１５１および光ディスク・ドライブ１５５は、通例では、インターフェース１５０のようなリムーバブル・メモリ・インターフェースによってシステム・バス１２１に接続する。
【００２２】
先に論じ図１に示すドライブおよびそれらと連動するコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびコンピュータ１１０のその他のデータを格納する。図１では、例えば、ハード・ディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するように示されている。尚、これらのコンポーネントは、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じでも異なっていても可能であることを注記しておく。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７は、少なくともこれらが異なるコピーであることを示すために、ここでは異なる番号を与えている。
【００２３】
ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボールまたはタッチ・パッドのようなポインティング・デバイス１６１によって、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）は、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、ユーザ入力インターフェース１６０を介して、処理ユニット１２０に接続されている。ユーザ入力インターフェース１６０は、システム・バスに結合されているが、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースおよびバス構造によって接続することも可能である。モニタ１９１またはその他の形式の表示装置も、ビデオ・インターフェース１９０のようなインターフェースを介して、システム・バス１２１に接続されている。モニタに加えて、コンピュータは、スピーカ１９７およびプリンタ１９６のようなその他の周辺出力デバイスを含むこともでき、これらは出力周辺インターフェース１９０を介して接続することができる。
【００２４】
コンピュータ１１０は、リモート・コンピュータ１８０のような１つ以上のリモート・コンピュータへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピュータ１８０は、パーソナル・コンピュータ、ハンド・ヘルド・デバイス、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、通例では、コンピュータ１１０に関して先に説明したエレメントの多くまたは全てを含む。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１およびワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットにおいては、一般的である。
【００２５】
ＬＡＮネットワーキング環境で用いる場合、コンピュータ１１０は、ネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続する。ＷＡＮネットワーク環境で用いる場合、コンピュータ１１０は、通例では、モデム１７２、またはインターネットのようなＷＡＮ１７３を通じて通信を確立するその他の手段を含む。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インターフェース１６０またはその他の適切な機構を介してシステム・バス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して図示したプログラム・モジュール、またはその一部は、リモート・メモリ記憶装置に格納することもできる。一例として、そして限定ではなく、図１は、リモート・アプリケーション・プログラム１８５がメモリ素子１８１上に常駐するものとして示している。尚、図示のネットワーク接続は一例であり、コンピュータ間で通信リンクを確立する他の手段も使用可能であることは認められよう。
【００２６】
図２は、本発明のダイアログ・システムのブロック図を提示する。以下に、図３のフロー図に示すダイアログ方法と関連付けて図２について説明する。
本発明の一実施形態の下では、図２のコンポーネントは、図１に示したもののような、パーソナル・コンピュータ・システム内に位置する。他の実施形態では、分散計算環境全体にコンポーネントを分散し、ネットワーク接続およびプロトコルによって互いに接続する。例えば、コンポーネントは、イントラネットまたはインターネットを通じて分散することができる。このような分散計算環境用に設計した本発明のダイアログ・システムの具体的な実施形態について、図１３のブロック図を参照しながら以下で更に詳細に論ずることにする。
【００２７】
図２において、ダイアログ・システム２００は、ユーザから複数のユーザ・インターフェース２０２，２０４を介して入力を受け取る。このようなユーザ入力インターフェースは、ユーザのスピーチをディジタル値に変換可能なスピーチ取り込みインターフェース、キーボード、およびマウスまたはトラックボールのようなポインティング・デバイスを含む。本発明は、これら特定のユーザ入力インターフェースに限定される訳ではなく、追加のユーザ入力インターフェースまたは代わりのユーザ入力インターフェースでも、本発明と共に使用可能である。
【００２８】
各ユーザ入力インターフェースは、関連する言語モデル２１０，２１２を有する、それ自体の認識エンジン２０６，２０８に設けられている。認識エンジン２０６および２０８は、それぞれ、言語モデル２１０および２１２を用いて、可能な表面的意味構造を識別し、評点を付けてそれぞれの入力を表わす。各認識エンジン２０６，２０８は、少なくとも１つの表面的意味出力と、この意味出力の確率を表わすスコアとを与える。実施形態によっては、認識エンジン２０６，２０８の少なくとも１つが、１つよりも多い代わりの表面的意味構造に、代わりの構造毎に、関連するスコアを与えることができるようにする場合もある。意味構造および対応するスコアの各々を談話エンジン２１４に供給する。表面的意味を生成するステップは、図３においてステップ３００として示してある。
【００２９】
スピーチおよび手書き文字のような、言語系ユーザ入力では、認識エンジンが用いる言語モデルは、多数の公知の確率モデルのいずれでも可能である。例えば、入力にＮ個の連続する単語から成る１群が与えられた場合、言語モデルは、ある言語における単語の確率をモデル化するＮ−グラム・モデルとすることができる。また、言語モデルは、意味情報および／または構文情報を特定の単語および句と関連付ける自由コンテクスト文法(context free grammar)とすることも可能である。本発明の一実施形態では、Ｎ−グラム言語モデルを自由コンテクスト文法と組み合わせた統一言語モデルを用いる。この統一モデルでは、意味トークンおよび／または構文トークンは、単語に対するプレース値(place value)として扱われ、Ｎ−グラム確率は、仮説的な単語およびトークン結合毎に計算する。
【００３０】
いくつかの実施形態では、言語モデルは、階層状の表面的意味構造を生成可能である。これは、談話モデル２１６において定義され、談話エンジン２１４によって用いられる談話意味構造と同様である。双方のモデルにおいて同様の階層構造を用いることによって、認識した入力値を表面的意味構造から談話意味構造に変換することが一層容易になる。尚、多くの実施形態では、ポインティング・デバイスのような非言語入力と関連する言語モデルでも、意味トークンをポインティング・デバイスの入力に結び付けることができる。殆どの実施形態では、意味トークンは、談話意味構造において発見した１組の意味トークンから取り込まれる。したがって、ユーザがマウスを用いてあるファイル・アイコン上でクリックすると、マウスの認識エンジンは、入力として示されたファイルのＩＤを指し示しつつ、FileNameトークンをその行為と関連付けることができる。
【００３１】
図３のステップ３０２に示すように、談話エンジン２１４が認識エンジン２０６，２０８から表面的意味を受け取ると、最初に談話意味ツリーを展開する。この展開を行なうには、最初に、談話エンジン２１４に供給した表面的意味構造を試験する。談話エンジン２１４に供給した表面的意味構造が以前には見られなかった上位の意味トークン、即ち、ダイアログにおける脱線(digression)を示す場合、談話エンジン２１４において新たな談話ツリーをインスタンス化する。
【００３２】
一方、談話エンジン２１４に供給した表面的意味が低いレベルの談話トークンを含む場合、談話エンジン２１４は、最初に、この表面的意味トークンが、現在開いているいずれかの談話ツリーに調和することができるか否か注意して確かめる。意味トークンが、現在開いている談話ツリーに調和することができる場合、トークンおよびそれに関連する入力値を、談話意味構造の適切なスロットに置く。
【００３３】
意味トークンが、現在開いている談話構造のいずれにも調和しない場合、談話エンジンは、意味トークンを見つけることができる、可能な談話ツリーを探す。１つよりも多い構造、または構造内の１つよりも多いロケーションに表面的意味トークンを挿入することができる場合、意味的曖昧さとして知られる状況となり、談話エンジン２１４は、トークンを挿入することができる全ての構造を展開するが、意味トークンを挿入しない。代わりに、意味オブジェクトをどこに置くべきかに関する曖昧さが解明するまで、談話エンジン２１４は意味トークンおよびそれに関連する入力値を談話メモリ２１８に保持する。通例では、この曖昧さを解明するには、ユーザからの追加情報を要求する。これについては以下で更に論ずる。
【００３４】
殆どの実施形態では、認識エンジンは、単語自体が曖昧であっても、表面的意味トークンを１つ以上の入力単語と関連付けることができる。例えば、"send it to him"（それを彼に送れ）というような句では、認識エンジンは、"it"がメッセージの目的語であり、"him"は受取人であることを識別することができる場合もある。したがって、認識エンジンは、メッセージ・トークンを"it"と関連付け、受取人トークンを"him"と関連付けることができる。しかしながら、単語"it"および"him"からは、何のメッセージを送るべきか、またはどの人がメッセージを受け取るべきか明らかでない。
【００３５】
本発明の下では、談話エンジン２１４は、特定の意味トークン・タイプに対して過去の値を収容した談話メモリ２１８を用いることによって、このような曖昧さを明確化しようとする。このメモリの意味トークン・タイプに対する過去の参照を引用することによって、本発明のシステムは、過去の談話ステートメントに基づいて、暗示的な参照に対して値を推論することができる。このように、前述の例を用いると、特定のメッセージが論述の中で新しく現れ、この論述において特定の人が引用されている場合、談話エンジン２１４は句"it"を特定のメッセージＩＤと置換し、更に"him"を特定の人の名前と置換する。
【００３６】
本発明の一実施形態の下では、談話メモリ２１８を別個の優先順位キューに編成することによって、この推論能力が向上(facilitate)する。即ち、本発明のこの実施形態の下では、談話メモリ２１８を、現ユーザ入力からの値を収容する短期メモリと、過去のユーザ入力からの値を収容する長期メモリとに分割する。
【００３７】
短期メモリは、更に、明示メモリと暗示メモリとに分割する。明示メモリは、ユーザが供給した入力から直接解明した値を保持する。例えば、ユーザが文章の始めにおいて名称で人に言及した場合、人トークン・タイプの下でこの名称を明示メモリに置く。暗示メモリは、行頭反復（直前の単語または句から、項目がその意味を得る）、省略法（項目はないが、自然に推論することができる）、および直示（明確な冠詞または代名詞を用いることによって項目を特定する）のように、ユーザによって行われた間接的な参照から解明した値を保持する。このような暗示的参照の例は、"Send it to Jack"のようなステートメントを含み、この場合、"it"は行頭反復であり、送ることができる品目に対する以前の参照を探すことによって解明することができる。また、"Send the message to John's manager"（ジョンのマネージャにメッセージを送れ）という文章では、"John's manager"は直示であり、後述のデータベース全体を探索し、誰がJohnのマネージャであるか発見することによって解明する。次いで、この名称を暗示メモリに置き、後に使用する。
【００３８】
一実施形態の下では、３つのメモリに優先順位を付け、参照を解明しようとする場合、システムは最初に明示メモリ内を見て、次いで長期メモリ、そして最後に暗示メモリを見るようにする。したがって、ユーザからの現入力においてある人に明示的に言及している場合、その人の名称は、長期メモリ内で見つかった人の名称、または解明されて暗示メモリ内に置かれた人の名称よりも優先されることになる。
【００３９】
一実施形態の下では、談話メモリ２１８の優先順位は、より高い優先順位メモリの値に一貫性がない場合、即ち、ユーザが与えた他の入力と矛盾する場合、無視される。例えば、ユーザが"her"（彼女）に言及するが、明示メモリ内の最後の名称が男性の名称である場合、明示メモリの優先順位は無視され、長期メモリまたは暗示メモリ内の最初の女性名を優先的に探す。
【００４０】
一実施形態の下では、談話意味構造を展開する前に、談話エンジン２１４は、ユーザからの現入力における間接的参照を解明しつつ、談話メモリ２１８を更新する。即ち、談話エンジン２１４は、現入力内で発見されたあらゆる明示的用語に基づいて、明示メモリを更新し、現入力における間接的参照を解明することによって、暗示メモリを更新する。この実施形態の下では、ユーザからの入力に対して先着順に解明を行い、ユーザ入力の最初の部分にある明示的および暗示的値を用いて、ユーザ入力の後の部分で発見された間接的な参照を解明する。
【００４１】
談話メモリ２１８を用いて暗示的参照を解明した後、メモリ２１８から検索した値を、展開した談話意味構造におけるそれらの各意味トークンと関連付ける。
一旦談話エンジン２１４が談話意味構造を展開したなら、ステップ３０４においてできるだけ談話意味構造を押し潰そうとする。談話意味構造を押し潰すために、談話エンジン２１４は、各最下位トークンを見て、これが意味トークンに関して、トークンと置換可能な単一のエンティティを特定できるだけの十分な情報を有するか否か判定を行なう。このコンテクストでは、エンティティとは、１つ以上のドメイン・エキスパート(domain expert)２２２がアクセスする１組のドメイン・テーブル２２０の内の１つにあるエンティティである。ドメイン・エキスパート２２２は、どのテーブルにアクセスし更新する必要があるか特定し、テーブルにアクセスする際に伴うオーバーヘッドおよびプロトコルを処理する。
【００４２】
例えば、人の一般的表現である人的意味トークンを押し潰すには、談話エンジン２１４は、人トークンに現在関連のある属性を満たす単一の人を探そうとする。これを行なうために、談話エンジン２１４は、人の解明に特化したドメイン・エキスパート２２２に属性およびトークンを渡す。すると、ドメイン・エキスパート２２２は、人トークンと関連がある複数のドメイン・テーブルにアクセスする。この場合、ドメイン・エキスパート２２２は、人のリストを収容したドメイン・テーブルにアクセスする。
【００４３】
人ドメイン・テーブルでは、各行がエンティティ、即ち、人として識別され、各列が人の属性となる。したがって、トークンを押し潰すことができるか否かの判定は、トークンの属性が十分な情報を提供し、ドメイン・テーブル２２０内において単一のエンティティを特定することができるか否かについての判定を伴う。ドメイン・テーブル２２０において単一のエンティティを見つけることができた場合、談話意味構造内にトークンの代わりにこのエンティティを挿入する。
【００４４】
談話意味構造にツリー構造を用いる実施形態では、意味トークンは、ツリー上のノードとして現れ、そのトークンの属性はそのノードの子として現れる。このような実施形態では、談話エンジン２１４は、下から上に談話ツリーを押し潰そうとすることにより、最初に子ノードを押し潰して、ノードの解明を「沸き上げる」(bubble up)。
【００４５】
ドメイン・テーブル２２０内で１つよりも多いエンティティが有効探索基準(available search criteria)を満たすためにトークンを押し潰すことができない場合、談話エンジン２１４は、ある最大数のエンティティまで、一致するエンティティ全てを検索することを選択してもよい。また、談話エンジン２１４は、談話モデル２１６を利用して、ステップ３０４における評価プロセスを保持し、確率が低い仮説を破棄することもできる。いずれの方法でも、談話エンジン２１４は、次に、未解明トークンから展開したこれら代わりの可能性によって、談話意味構造を増大させる。
【００４６】
図３のステップ３０６において、談話エンジン２１４は、談話モデル２１６を用いて、各談話意味構造の尤度を記述するスコアを生成する。このコンテクストでは、未解明意味トークンから展開した各エンティティは、これらが共通の意味トークンを共有する場合であっても、別個の談話意味構造の一部であると見なす。したがって、談話エンジン２１４は、未解明トークンから展開した各エンティティ毎に、別個のスコアを生成する。尚、実施形態によっては、性能を考慮してステップ３０４およびステップ３０６を効果的に組み合わせて単一のステップにすることも可能であることを注記しておく。
【００４７】
一例として、ユーザが、彼らは"Send an e-mail to John"（ジョンに電子メールを送る）ことを望んでいると言ったが、ドメイン・テーブル２２０がJohn A,  John B, およびJohn Cを含む場合、談話エンジン２１４は、John A,  John B, およびJohn Cに電子メールを送るために、別個のスコアを生成する。過去において、ユーザが等しい数の電子メールをJohn A,  John B, およびJohn Cに送っていた場合、談話エンジン２１４および談話モデル２１６が生成するスコアは、各意味構造に対して等しくなる。しかしながら、ユーザがJohn Aに９０パーセントの時間、John Bに８パーセントの時間、そしてJohn Cに２パーセントの時間電子メールを送っている場合、談話モデル２１６が生成するスコアは、John Aに対して高い重み付けを行い、John BおよびJohn Cに対しては非常に低い重み付けを行なう。
【００４８】
多くの実施形態では、意味的曖昧さを解明するのと同じ機構を用いて、認識の曖昧さを解明することができる。例えば、ユーザが"Send e-mail to John A"（ジョンＡに電子メールを送れ）と言った場合、スピーチ認識部は、音素およびその他の交絡する要因に基づいて、"John A",  "John K" または"John J"に関する発声を認識することができる。多くの実施形態では、システムは、これらの競合する認識仮説を意味的曖昧さとして見なすことも選択可能である。この扱いによって、表面的意味が談話エンジンに与えられる前に認識の曖昧さを解明する場合に必要となる、余分な処理が不要となる。
【００４９】
曖昧さの解明が意味的矛盾に展開する可能性もある。これは、多数の認識エンジンの各々が互いに矛盾する表面的意味を与えるという多様式環境において発生する。例えば、ユーザが"Send e-mail to John A"（ジョンＡに電子メールを送れ）と言ったが、ディスプレイ上で"John B"の絵の上でクリックする場合である。多くの実施形態では、様式相互間における意味の曖昧さ(cross modality semantic ambiguity)は、様式相互コンフリクトを処理するために特殊な命令を実行することなく、前述と同様に対処することができる。
【００５０】
ステップ３０８において、図２のレンダリング・エンジン２２４は、談話エンジン２１４が生成した談話意味構造、およびこの構造を通過する各パスに関連するスコアを受け取る。レンダリング・エンジン２２４は、談話意味構造および関連するスコアを、挙動モデル２２６への入力として用いる。挙動モデル２２６は、使用可能なユーザ・インターフェース、および談話意味構造によって表わされるダイアログの現状態を考慮して、特定のアクションを行なう場合のコストを生成する。
【００５１】
異なるアクションのコストは、いくつかの異なる要因に基づいて計算することができる。例えば、ダイアログ・システムの使用可能性は、部分的にユーザが尋ねた質問の数に基づくので、ダイアログ方式(dialog strategy)に伴う１つのコストは、尋ねる質問の数である。したがって、一連の質問を行なうことを伴うアクションは、単一の質問を行なうアクションよりも高いコストを有する。
【００５２】
ダイアログ方式に伴う第２のコストは、ユーザが彼らに行われた質問に適正に応答しない尤度である。これは、単一の質問においてユーザに余りに多くの情報を求めた場合、または余りに広いことを述べた質問を行なった場合に、あり得ることである。
【００５３】
最後に、使用可能な出力ユーザ・インターフェースに対して、アクションは適切でなければならない。したがって、ユーザに多数の選択を与えるアクションは、出力インターフェースが電話機である場合、高いコストを有する。何故なら、ユーザは、オプションが提示されたとき、これらを暗記しなければならないからである。しかし、出力インターフェースがブラウザである場合、低いコストを有する。何故なら、ユーザは一度にオプションの全てを見ることができ、選択を行なう前にこれらを数回照会することができるからである。
【００５４】
図２の実施形態の下では、談話エンジン２１４は、インターフェース・メモリ２３０から、使用可能なユーザ・インターフェースをレンダリング・エンジン２２４に供給する。尚、他の実施形態では、インターフェース・メモリ２３０を直接レンダリング・エンジン２２４に接続してもよく、あるいはレンダリング・エンジン２２４がオペレーティング・システムの機能にアクセスし、使用可能な出力インターフェースを識別してもよいことを注記しておく。
【００５５】
アクションのコストを判定するとき、レンダリング・エンジン２２４および挙動モデル２２６は、レンダリング・エンジンが単に談話意味構造に関連するアクションを行なうことによって高い成功の尤度を有する程、意味構造が十分高いスコアを有するか否か検討する。例えば、先に記した例におけるように、ユーザが"Send this message to John"（このメッセージをジョンに送れ）と言った場合、そして、John Aに対するスコアがJohn BおよびJohn Cに対するスコアよりもはるかに高かった場合、レンダリング・エンジンは、ユーザから更なる明確化を要求することなく、単にメッセージをJohn Aに送る。このような場合、電子メールをJohn Aに送る際にエラーを起こすことのコストは、どのJohnに電子メール・メッセージを送りたいのか明確にするためにユーザに尋ねる場合のコストよりも少ない。一方、電子メールをJohn Aに送る際にエラーを起こすことのコストが高い場合、適正なアクションは、ユーザに確認の問い合わせを生成することであろう。多くの実施形態では、コストおよびスレシホルドは、挙動モデル２２６において明示的に表現することができる。
【００５６】
図３のステップ３１０において、レンダリング・エンジン２２４は、最も高いアクション・スコアを選択し、対応するアクションを行なう。多くの場合、これには、ユーザ出力インターフェース２２８を介して応答をユーザに送ることを伴う。
【００５７】
レンダリング・エンジン２２４がアクションを選択した後、実施形態によっては、１つ以上の言語モデル２１０および２１２を修正して、ユーザのそのアクションに対する応答を適正に解釈するために言語モデルを使用できるようにする場合もある。例えば、レンダリング・エンジンが３つの代替案をユーザに提示した場合、言語モデルを更新して、「最初のもの」、「２番目のもの」、のような句を特定のエンティティと関連付けるようにすることができる。これによって、認識エンジンは、その特定した句を特定のエンティティと置換することが可能となり、談話エンジン２１４は、談話意味構造の適正なスロットにそれらエンティティを挿入することが一層容易となる。
【００５８】
図２および図３において説明した談話システムの動作の更に詳しい説明として、図４ないし図１２は、表面的意味構造、およびサンプル・ダイアログに対する談話構造の例を与える。以下の論述では、表面的意味構造および談話構造にツリー構造を用いる。先に注記したように、このような構造では、ツリーにおけるノードの「子」は、当該ノードにおけるトークンの属性と見なすことができる。以下の論述では、子ノードのことを、相互交換可能に子および属性と呼ぶことにする。加えて、以下の論述の目的上、認識エンジンは、挙動が明確であり、本発明において適正に処理可能であるにしても、意味的曖昧さや認識の曖昧さの原因となる結果を生じないと仮定する。
【００５９】
談話は、ユーザが"Send it to those in the meeting on Wednesday"（水曜日のミーティングのときにこれをそれらに送る）と言ったときに開始する。この句をスピーチ認識エンジンが受け取り、言語モデルを用いて、図４に示す表面的意味構造を生成する。図４の表面的意味構造は、意味トークン<Send mail>を収容するルート・ノード４００を含む。これは、句全体"Send it to those in the meeting on Wednesday"と関連がある。<Send mail>トークンは２つの子ノード、即ち、属性４０２および４０４を有し、これらは意味トークン<Message>および<Recipient>としてそれぞれ識別される。<Message>トークン４０２には、単語"it"が関連し、<Recipient>トークン４０４には句"those in the meeting on Wednesday"が関連する。
【００６０】
<Recipient>トークン４０４は、意味トークン<Meeting attendees>を収容する、更に別の子ノード４０６を有する。意味トークン<Meeting attendees>は、句"those in the meeting on Wednesday"に関連がある。
【００６１】
<Meeting attendees>トークン４０６は、<Existing meeting>の属性を有する。これは、トークン４０８によって表わされ、句"meeting on Wednesday"に関連がある。<Existing meeting>トークン４０８は、意味トークン<Date>を収容する属性４１０を有する。意味トークン<Date>は、単語<Wednesday>に関連がある。
【００６２】
尚、図４の意味ツリー構造と関連する認識エンジンは、システム上で動作することができる唯一の認識システムであることを注記しておく。図５は、スピーチ認識エンジンと並行して動作する認識エンジンが生成する表面的意味構造を示す。即ち、図５の表面的意味構造は、ポインティング・デバイスと関連する認識エンジンによって生成する。この例では、ポインティング・デバイスは、ユーザが、"Send it to those in the meeting on Wednesday"と言いながら、特定のメッセージ上でクリックしたことを示す信号を発生する。このクリック・ジェスチャに基づいて、ポインティング・デバイスと関連する認識エンジンは、ユーザがクリックしたメッセージのメッセージＩＤと関連がある<Message>意味トークンを収容する単一のノード構造５００を生成する。
【００６３】
図４および図５の表面的意味構造を談話エンジンに供給し、談話エンジンは、最初に、現入力情報をできるだけ多くのノードに挿入することによって、談話意味構造を展開しようとする。この例では、この結果、図６に示す談話意味ツリーが得られる。
【００６４】
図６の談話意味ツリーは、<Send mail>意味トークンを有するルート・ノード６００を含む。<Send mail>トークン６００は、６つの属性を有し、これらは、<Subject>, <Attachment>, < Blind copy>, <Carbon copy>, <Message>, および<Recipient>の意味トークンをそれぞれ収容する子ノード６０２，６０４，６０６，６０８，６１０，および６１２として現れる。
【００６５】
図５および図６の表面的意味構造に基づいて、談話エンジン２１４は、<Message>トークン６１０と関連付けることができる、可能な２つの値を有する。これらの値は、"it"、およびポインティング・デバイス認識エンジンによって戻されたメッセージＩＤである。
【００６６】
<Recipient>ノード６１２は、<Person>トークン６１４、<Meeting attendees>トークン６１６、および<Work group>トークン６１８を含む、更に別の可能な受取人タイプを指し示す。これら３つのトークンの内、<Meeting attendees>６１６のみが、<Existing meeting>６２０の子ノードを含むように、更に展開されている。
【００６７】
<Existing meeting>トークン６２０は、データベース内における既存のミーティングを表わす。このような既存のミーティングは、主題、日付、ミーティングの場所、ミーティングのまとめ役、またはミーティングＩＤによって引用することができる。これらの属性の各々は、別個のトークン６２２，６２４，６２６，６２８，および６３０としてそれぞれ示されている。表面的意味に基づいて、談話エンジンは、"Wednesday"の値を<Date>トークン６２４と関連付けることができる。しかしながら、表面的意味は、<Existing meeting>トークン６２０の他の属性に対しては値を与えない。
【００６８】
属性が満たされていなくても、図６の各意味トークンに対して全ての属性が示しているが、他の実施形態では、これらの属性がより大きな談話ツリーに追加されるべきことを表面的意味が示すまで、これらの属性は談話構造のノードとしては含まれない。
【００６９】
談話意味ツリーを展開した後、次に談話エンジンはできるだけツリーを押し潰そうとする。図６のツリーを用いると、談話エンジン２１４は、最初に間接的参照"it"を解いてメッセージＩＤの直接的かつ明示的参照とし、次いでドメイン・エキスパートを通じて、このメッセージＩＤを有するメッセージは１つだけであることを確認することによって、<Message>トークン６１０を押し潰すことができる。こうして、図７に示すように、一般化した<Message>トークン６１０を具体的なメッセージＩＤエンティティと置換する。
【００７０】
次に、談話エンジン２１４は、談話構造の受取人ブランチ上にある最低のノードを押し潰そうとする。これには、<Existing meeting>トークン６２０を押し潰そうとすることが伴う。これを行なうために、談話エンジンは、ミーティング・ドメイン・エキスパート２２２を用いて、ドメイン・テーブル２２０を探索し、<Existing meeting>トークン６２０に関係する属性を有する既存のミーティングを求める。図６の例では、これには、データベースを探索して水曜日に行われたミーティングを求めることが伴う。水曜日に行われたミーティングが１つのみである場合、<Existing meeting>トークン６２０を、このミーティングの識別番号と置換する。
【００７１】
しかしながら、水曜日に行われたミーティングが１つよりも多い場合、ドメイン・エキスパートは、探索基準を満たすミーティング全てを戻す。談話エンジンは、これらのミーティングを、<Meeting ID>トークン６３０に対する可能な値として追加する。これは、<Meeting ID>トークン６３０から展開した代替選択肢８００，８０２，および８０４として、図８に示されている。
【００７２】
既存のミーティング６２０を押し潰すことができないので、談話エンジン２１４は次に談話モデル２１６を用いて、ユーザが３つの可能なミーティング８００，８０２および８０４の各々の出席者にメールを送りたい確率を判定する。したがって、談話エンジン２１４は、<Send Mail>ルート・ノードに対し、３つの別個のスコアを生成する。
【００７３】
談話モデルに基づいて、可能なミーティングに関連する構造のいずれもが高いスコアを有しておらず、詳細な質問を行なう方が電子メールを送るよりもコストがかからない場合、レンダリング・エンジン２２４は、ユーザが言及したのはどのミーティングなのか明確にするために、ユーザに質問する。一実施形態の下では、レンダリング・エンジン２２４は、更に「最初のもの」または「２番目のもの」というような入力を受け入れるように言語モデルを更新し、レンダリング・エンジンがどのようにしてオプションをユーザに与えるかに基づいて、このような入力を特定のミーティングに関連付けることができるようにする。
【００７４】
ユーザにミーティングの詳細質問を行なった後、スピーチ認識エンジンは、ユーザから「最初のもの」という句を受け取る。修正言語モデルに基づいて、認識エンジンはこの入力を、最初のミーティングの識別番号と関連のある<Meeting>のルート・トークンを有する表面的意味構造に変換することができる。このような表面的意味構造を図９に示す。
【００７５】
この新たな表面的意味構造に基づいて、談話エンジン２１４は再度送信メール談話構造を展開しようとする。この場合、提供される情報は、<Meeting ID>トークンに対するエンティティであり、したがって<Meeting ID>トークンに関連がある。
【００７６】
この小さな展開の後、談話エンジン２１４は、送信メール談話構造のノードをできるだけ多く押し潰そうとする。押し潰す最初のノードは、<Meeting ID>トークンである。これを行なうには、単に、展開の間これと関連のあったミーティングＩＤで、そのトークンを置換すればよい。
【００７７】
次に、談話エンジン２１４は、<Existing meeting>トークンを押し潰そうとする。<Existing meeting>トークンの<Meeting ID>属性は、ミーティングＩＤエンティティと置換されているので、<Existing meeting>トークンは、<Existing meeting>トークンをミーティングＩＤで置換することによって、押し潰すことができる。
【００７８】
押し潰すことができる次のトークンは、<Meeting Attendees>トークン６１８である。このトークンを押し潰すために、談話エンジン２１４は、ミーティングＩＤを、適切なドメイン・テーブルを探索するドメイン・エキスパートに渡し、そのミーティングＩＤに関連するミーティングに出席した人を特定する。次いで、ドメイン・エキスパートは、ミーティングに出席した人の各々の識別を返す。
これらの人の識別は、次に、図１１に示すように、<Meeting Attendees>トークンの代わりに入れられる。
【００７９】
次に、談話エンジン２１４は、下に掲示してある人に基づいて、<Recipient>トークンを押し潰そうとする。これを行なうために、談話エンジン２１４はこれらの人の識別をドメイン・エキスパートに渡す。ドメイン・エキスパートは、適切なドメイン・テーブルを探索し、これらの人が電子メール・アドレスを有するか否か確認する。これらの人が電子メール・アドレスを有する場合、ドメイン・エキスパートによって、電子メール・アドレスが返される。次いで、<Recipient>トークンの代わりに、電子メール・アドレスが入れられる。これを図１２に示す。
【００８０】
この段階において、談話エンジン２１４は談話モデルを用いて、スコアを送信メール談話構造全体に付与する(attribute)。このスコアは、送信メール談話構造を生成するために用いた入力に関連する認識スコア、およびユーザがメールを送りたい尤度双方を考慮する。尚、談話モデルは、曖昧さが少ない談話構造程高いスコアを付与することも注記しておく。この場合、受取人および送信するメッセージ双方が特定されているので、送信メール談話構造は非常に高い確率を有する。何故なら、ユーザはこのメッセージＩＤを、図１２の送信メール談話構造にリストしてある電子メール・アドレスに送ろうと考えている可能性が高いからである。
【００８１】
図１２の談話構造、およびそれに関係する確率をレンダリング・エンジンに渡し、レンダリング・エンジンは挙動モデルを用いて、送信メール談話構造が表わすアクションを実行できる程確率が高いか否か判定を行なう。送信メール談話構造は完全に押し潰されているので、レンダリング・エンジンが電子メールを送る可能性は非常に高い。
【００８２】
前述のように、本ダイアログ・システムのサブシステムの各々は、確率モデルを用いてパターン認識を行なう。したがって、認識エンジン２０６は、言語モデル２１０を用いて、種々の異なる表面的意味構造に対して確率を特定する。これは、数学的にＰ（Ｆ｜ｘ）として表わすことができる。ここで、ｘはユーザ入力、Ｆは特定した表面的意味構造、そしてＰ（Ｆ｜ｘ）はユーザ入力が与えられたときの表面的意味構造の確率である。
【００８３】
同様に、談話エンジンは、談話モデルを用いて、１組の可能な談話構造の各々に対して、スコアを生成する。包括的に、談話エンジンは、以前のダイアログ状態および表面的意味構造が与えられると、現ダイアログ状態の確率を与えるものとして考えることができる。数学的表現では、これはＰ（Ｓn｜Ｆ，Ｓn-1）となり、Ｓnは現ダイアログ状態であり、Ｆは現表面的意味構造であり、Ｓn-1は直前のダイアログ状態であり、Ｐ（Ｓn｜Ｆ，Ｓn-1）は現表面的意味構造および直前のダイアログ状態が与えられたときの現ダイアログ状態の確率である。尚、このコンテクストでは、直前のダイアログ状態は、談話メモリ、および談話エンジンが開いたあらゆる談話構造を含む。
【００８４】
したがって、認識エンジン２０６、言語モデル２１０、談話エンジン２１４および談話モデル２１６全てを併せて、ユーザ入力および過去のダイアログ状態に基づいて、可能な現談話状態に対するスコアを特定するダイアログ状態エンジンを表わす。ダイアログ状態エンジンが、２つのより小さなエンジンを内蔵するものとして記載されたが、別の実施形態では、ダイアログ状態エンジンは、単一のモデルを用いる単一のエンジンとして実施されることを当業者は認めよう。
【００８５】
本発明の下では、レンダリング・エンジン２２４は、挙動モデル２２６によって表わされる、確率モデルも利用する。即ち、レンダリング・エンジン２２４は、現ダイアログ状態が与えられると、最低コストのアクションを決定する。これは、現ダイアログ状態または数学的にＰ（Ａ｜Ｓn）として与えられると、各アクションの確率を判定するものとして表わすことができる。ここで、Ａはアクション、Ｓnは現ダイアログ状態である。
【００８６】
本発明の下におけるダイアログ・システムの各エレメントは確率モデルを用いているので、ダイアログ・システムのアクションは、単一の確率モデルとして表わすことができる。数式に置き換えると、ダイアログ・システムの機能は次のように表わすことができる。
【００８７】
【数１】
0005166661.tif 000002
ここで、Aoptは、取るべき最適なアクションであり、P(A|x, Sn-1)は、ユーザ入力ｘ，および以前のダイアログ状態Ｓn-1が与えられた場合のアクションＡの確率である。
【００８８】
数１によって与えられる全体的確率は、更に、認識エンジン、談話エンジン、およびレンダリング・エンジンに関連する個々の確率に分解することができる。これから次の式が得られる。
【００８９】
【数２】
0005166661.tif 000003
ここで、P(A|Sn)は、レンダリング・エンジンが生成した確率、P(Sn|F,Sn-1)は談話エンジンが生成した確率、そしてP(F|x)は認識エンジンが生成した確率である。ビタビ近似を用いると、数２を更に簡略化することができる。
【００９０】
【数３】
0005166661.tif 000004
ここで、ビタビ近似は、レンダリング・エンジンにおいて最大の確率を選択し、可能なアクション全てに対する確率の和を表わす。
【００９１】
単一の数式においてシステム性能全体を表わすことができるので、本システムを最適化するのが一層容易となる。理論的および経験的に、これは、システム全体を訓練し、種々のサブシステムを統合化して単一のシステムを生成するための、一層効率的な手段を提供することが示されている。更に、各サブシステムに関連する別個の確率は、サブシステムをモジュール状ユニットに形成する手段となり、１組の入力値が与えられた際にモジュール状ユニットが、あるスコアを、期待される出力構造に与える限り、各モジュール状ユニットの機能そのものを重視しないようにする。
【００９２】
図１３は、分散計算環境において実施可能な本発明の第２実施形態のブロック図を示す。図１４は、図１３の実施形態を用いるダイアログ方法のフロー図を示す。
【００９３】
図１３において、ユーザは、インターフェース１３００および１３０２で代表する１つ以上のユーザ入力インターフェースを通じて入力を与える。ユーザ入力は、ネットワーク１３０４および１３０６で示すように、インターネットまたはイントラネットのようなネットワークを通じて送信することができる。入力は、ＨＴＴＰおよびＦＴＰを含む種々の公知のネットワーク・プロトコルのいずれの１つに応じても送信することができる。即ち、ユーザからのスピーチ入力はwaveファイル、または特徴ベクトルの集合として送ることができる。また、ユーザ入力は、拡張可能マークアップ言語（ＸＭＬ）フォーマットで送信することも可能である。
【００９４】
図１４のステップ１４００において、認識エンジン１３０８および１３１０は、言語モデル１３１２および１３１４を用いて、ユーザ入力に基づき最も可能性が高い１組の表面的意味を特定する。本発明のこの実施形態の下では、言語モデル１３１２および１３１４は、拡張可能マークアップ言語（ＸＭＬ）フォーマットで著した(author)ものである。このＸＭＬフォーマットの下では、異なる表面的意味オブジェクトが、ＸＭＬページにおけるタグとして表わされ、意味オブジェクトの階層が、ＸＭＬネスト・タグにおいて見出される階層によって表わされる。
【００９５】
認識エンジンによってユーザ入力に関連付けられた言語モデルからのタグを、表面的意味を搬送する別個のＸＭＬ記述ページ内に置く。一実施形態の下では、意味マークアップ言語またはＳＭＬと呼ぶマークアップ言語を、ＸＭＬから展開し表面的意味を表わす。この実施形態の下では、認識エンジン１３０８および１３１０の出力は、意味マークアップ言語ページである。例えば、発声"what is the phone number for Kuansan?"（クアンサンの電話番号は何番か）に対する表面的ＳＭＬは次の通りである。
【００９６】
【表１】
0005166661.tif 000005
この例では、DirectoryQueryは、表面的意味のルート・ノードを表わし、発声において見出された意図の基本的タイプが何であるかを示す。PersonByNameは、発声の中で明示的に言及された人がいることを示し、DirecotryItemは、ユーザが住所録の項目を探していることを示す。
【００９７】
多くの実施形態では、有効なＳＭＬページを生成する命令は、動的に合成され、言語モデルに埋め込まれる。殆どの実施形態では、有効なＳＭＬページを生成する命令は、Worldwide Web Consortiumが設定したextensible stylesheet language transformations （ＸＳＬＴ：拡張可能スタイルシート言語変換）規格に従う。ＸＳＬＴ規格は、２つの統合部分、ソース文書の照合および変換文書の生成から成る。ＸＭＬページとしてフォーマット化されているユーザ入力に対して、規格の両部分が言語モデルによって用いられる。しかしながら、waveファイルのように、ＸＭＬページとしてフォーマット化されていないユーザ入力に対しては、単純なテキストまたは特徴ベクトル、変換文書を生成するための規格のみを用いることができる。
【００９８】
ＳＭＬページでは、認識スコアを、ＸＭＬ属性として、ＳＭＬノードに結び付ける。DirecotryItemに対する信頼性尺度を渡す一例を先に示した。実施形態によっては、音響モデルおよび言語モデルのスコアを同様に取り付ける場合もある。
【００９９】
認識エンジン１３０８および１３１０が生成したＳＭＬページは、談話エンジン１３１４に渡される。図１３の実施形態では、談話エンジン１３１４は、認識エンジンと同じマシン上に位置してもよく、あるいは別個のマシン上に位置してもよい。その場合、ＳＭＬページは、図１３のネットワーク１３５０のようなネットワークを通じて、談話エンジンに送信する。
【０１００】
図１４のステップ１４０２において、談話エンジン１３１４は談話モデル１３１６を用いて、表面的意味ＳＭＬページを談話意味ＳＭＬページに変換する。本発明の一実施形態の下では、これを行なう際に、特殊化したＸＭＬを用いて、談話モデルを指定する。即ち、談話モデルを意味定義言語（ＳＤＬ）で書く。意味定義言語は、ＳＭＬ文書の正当な構造を定義し、表面的意味および談話意味において見出された意味オブジェクト間の関係を特定する。ＳＤＬを用いてＳＭＬのマークアップ言語シェーマを定義することによって、システムはＳＭＬのシェーマを動的に調節することが可能となり、文書タイプ定義またはＸＭＬシェーマ・フォーマットのいずれにおいても、別個のＳＭＬシェーマ仕様の必要がなくなる。モデルのＳＬＤページは、意味推論規則も与え、談話エンジン１３１４がこれを利用して談話構造の展開および縮小を行なう。これは、談話メモリ１３１８およびドメイン・エキスパート１３２０にアクセスするための規則を含む。尚、本発明の下では、談話メモリ１３１８、ドメイン・エキスパート１３２０、およびドメイン・テーブル１３２４は、先に図２において同様に命名した項目に対して記載した場合と同様に動作することを注記しておく。談話モデル１３１６のＤＳＬに設けられた規則は、種々の談話意味に対してスコアを生成し、特定の談話意味を選択してレンダリング・エンジン１３２６に供給するためにも供する。
【０１０１】
上述の表面的意味の例を続けると、談話エンジンの出力は、次を含むＳＭＬページとなる。
【０１０２】
【表２】
0005166661.tif 000006
このＳＭＬページでは、談話エンジンが電話番号を番号エンティティに解明し、Kuansanに対する参照を特定の人Kuansan Wangに解明していることが分かる。
【０１０３】
談話エンジン１３１４によって与えられるＳＭＬページには、先に示したように、推論スコアも授けられる。前述の例は挙動が正しい認識および理解のみを実証したが、ＳＭＬプロセスのＸＭＬ順応性は、認識および意味的曖昧さが生じた場合に、これらに注釈を付ける際に十分な表現力を有することを当業者は認めよう。
【０１０４】
談話エンジン１３１４が生成したＳＭＬページは、レンダリング・エンジン１３２６に供給される。実施形態によっては、２つのエンジンを異なるコンピュータ上に配置し、図１３のネットワーク１３５２のようなネットワークで接続する場合もある。
【０１０５】
図１４のステップ１４０４において、レンダリング・エンジン１３２６は、受け取ったＳＭＬページを適切なアクションに変換する。最初に、レンダリング・エンジン１３２６が受け取ったＸＭＬページを挙動モデル１３２８に適用する。本発明の一実施形態では、挙動モデル１３２８は、拡張可能スタイルシート言語（ＸＳＬ）を用いて設計しており、特にＸＳＬ−変換（ＳＸＬＴ）を用いて設計している。ＸＳＬＴ規格を用いると、挙動モデルは、ＳＭＬ構造を別のマークアップ言語に、例えば、ハイパーテキスト・マークアップ言語（ｈｔｍｌ）、ワイヤレス・マークアップ言語（ｗｍｌ）、またはテキスト−スピーチ（ｔｔｓ）マークアップ言語に変換することができる。したがって、挙動モデル１３２８は、談話エンジンが生成する特定的なＳＭＬ構造を、ｈｔｍｌページ、ｗｍｌページ、またはその他の出力のような適切な出力ページに埋め込まれるアクションに変換するための規則を含む。
【０１０６】
別の実施形態では、挙動モデルは、ＸＳＬＴ規格の文書照合部分のみを使用することができるが、文書生成部分を使用することはできない場合もある。これは、取るべきアクションがマークアップ言語ページの生成を伴わない場合、例えば、アクションがシステム・コマンドである場合に発生する可能性がある。このような場合、挙動モデルは照合機能を実行し、次いで適切なアクションを生成する最良の手段を決定する。
【０１０７】
したがって、挙動モデルの出力は、明確化する質問をユーザに行なうスクリプト、または特定のアクションを行なうシステム・コマンドのようなものを含むアクション・ページとすることができる。このようにして、レンダリング・システム１３２６は、図２のレンダリング・システムが適切なアクションを選択した場合と同様に、適切なアクションを選択する。
【０１０８】
前述のＳＭＬテキストのテキスト−スピーチ・アクション (text-to-speech action)を生成するのに適したＸＳＬＴセクションの一例は次の通りである。
【０１０９】
【表３】
0005166661.tif 000007
このＸＳＬＴテキストから、ユーザに与える応答、"For Kuansan Wang, the phone number is +1(425)703-8377."（クアンサン・ワンの電話番号は、＋１（４２５）７０３−８３７７です）が得られる。これは、オーディオ信号としてユーザに与えられる。韻律的操作のような、進んだテキスト−スピーチ・マークアップを前述の例に容易に追加できることを当業者は認めよう。あるいは、挙動モデルはＸＳＬＴスタイルシートを選択し、応答をｔｈｍｌテーブルとすることも可能である。このようなテーブルを生成するスタイルシートの一例を以下に示す。
【０１１０】
【表４】
0005166661.tif 000008
尚、レンダリング・エンジンは、インターフェース・メモリ１３２２内のインターフェース情報、および談話意味構造を記述するＳＭＬ文書におけるタグに基づいて、適切なスタイルシート・テンプレートを動的に選択可能であることを注記しておく。
【０１１１】
談話エンジンが与えるＳＭＬ談話ページは、レンダリング・エンジン１３２６がどのアクションを行なうべきか判定する際に役立つキューを含むことができる。例えば、クエリが"Derek"という名前の人に対するものであり、データベースの中に２７個の一致がある場合、談話ＳＭＬページは次のように見える。
【０１１２】
【表５】
0005166661.tif 000009
この例では、先の例におけるDirectoryQueryおよびPersonByNameのような、談話エンジンによって押し潰すことができない意味オブジェクトには、"TBD"判定ステータス(status of to-be-determined)のフラグを立てる。また、談話ＳＭＬは、ダイアログの現フォーカスにマークし、意味評価が継続している場所を示す。例えば、DirectoryQueryタグでは、フォーカス属性を人と等しくセットし、ディレクトリ・クエリに関連する人が未だ解明されていないことを示す。これら２つのキュー(cue)は、挙動モデルが適切な応答、即ち、適切なＸＳＬＴスタイルシートを選択する際に補助となる。
【０１１３】
この例では、挙動モデルは、ディスプレイ上に２７通りの可能性全てを提示するｈｔｍｌページを生成するＸＳＬＴスタイルシートを選択することができる。しかしながら、これが適切なのは、高機能ブラウザ(full-scale browser)がユーザに使用可能な場合のみである。このようなブラウザがユーザには使用可能でない場合、システムは代わりにテキスト系スタイルシートを用いることができる。しかしながら、このようなスタイルシートは、数回のダイアログのやりとりに基づく、より精巧なダイアログ方式により、曖昧さを解明するために一連の質問をユーザに行なうことを必要とする場合がある。
【０１１４】
挙動モデル１３２８によって決定するアクションは、レンダリング・エンジン１３２６が実施し、多くの場合ユーザ出力インターフェース１３３０への出力が得られる。この出力は、直接ユーザ出力インターフェースに渡すことができ、あるいは中間ネットワーク１３３２を通じて渡すこともできる。
【０１１５】
本発明のこの実施形態の特徴の１つは、ユーザがダイアログ・セッションの最中にユーザ・インターフェースを切り替えられることである。これを行なうために、ユーザは、新たなユーザ・インターフェースに切り替えたいことを伝達する。談話エンジン１３１４は、このインターフェース情報を最新談話意味ＳＭＬページとしてレンダリング・エンジン１３２６に渡す。挙動モデルは、このＳＭＬページを、インターフェース・メモリ１３２２を更新するアクションに変換し、新たに選択したインターフェースを反映する。次いで、レンダリング・エンジン１３２６がこの新たなインターフェースを用いて、今後のＳＭＬページのために適正なスタイルシートを選択し、ＳＭＬページを、新たなインターフェースに適した出力フォーマットに変換するようにする。
【０１１６】
尚、このシステムの下では、談話自体に対する談話意味構造は変化しない。したがって、談話エンジン１３１４を再コード化したり、ユーザが出力インターフェースを変更するときにもその動作を変更する必要は全くない。これによって、新たなユーザ出力インターフェースが使用可能になったときに、これらに適合化させるのが一層容易になる。
【０１１７】
ダイアログ方式は、動的に交換可能なＸＳＬＴにおいてエンコードするので、システムもダイアログ設計者に対して、動的にダイアログ方式に適合化するための膨大な量の柔軟性を提供する。例えば、システムが経験のあるユーザに遭遇した場合、挙動モデルは、ダイアログ・フローを殆どの時間ユーザに決定させるスタイルシートを適用することを選択することができる。しかしながら、混乱が生じた場合、挙動モデルは、「システム主導」型ダイアログ・スタイルに後退し、より厳密なステップに従うように人のユーザに要求することができる。ダイアログ・セッション最中におけるダイアログ・スタイルの変更は、異なるスタイルシートを適用することと同等であり、システムの残りに対しては、言語や談話モデルの変更を必要としない。
【０１１８】
ＸＳＬＴをダイアログ・アプリケーションに適用しなかった理由の１つは、ＸＳＬＴがメモリ状態を有さないからである。このため、図１３の実施形態における挙動モデルおよびレンダリング・エンジンは、ダイアログの過去の状態を格納することができない。図１３の実施形態の下では、これは問題とならない。何故なら、談話エンジン１３１４は、ダイアログの過去の状態を管理し格納することができるからである。そして、談話エンジン１３１４は、レンダリング・エンジン１３２６および挙動モデル１３２８が必要とするあらゆるメモリ・エレメントを、ＳＭＬページの談話意味構造を通じて受け渡す。
【０１１９】
本発明は、好適な実施形態を参照しながら説明してきたが、本発明の精神および範囲から逸脱することなく、形態および詳細において変更も可能であることを当業者は認めよう。即ち、これまでツリー構造を参照しながら本発明の説明を行なってきたが、適当なデータ構造であればいずれでも使用可能であり、本発明はツリーに基づく構造に限定される訳ではない。
【０１２０】
加えて、前述の実施形態は談話意味エンジンおよび談話モデルを利用したが、他の実施形態では、これらのエレメントは含まれない。このような実施形態では、表面的意味を直接レンダリング・エンジンに供給し、次いでレンダリング・エンジンが表面的意味を直接挙動モデルに適用することによって、アクションを選択する。このような実施形態では、挙動モデルは表面的意味のみに基づき、ダイアログ状態を参照せずに、アクションのコストを決定する。
【図面の簡単な説明】
【図１】図１は、本発明を実施可能なパーソナル計算システムの全体的ブロック図である。
【図２】図２は、本発明のダイアログ・システムのブロック図である。
【図３】図３は、本発明の下におけるダイアログ方法のフロー図である。
【図４】図４は、スピーチ入力に対して認識エンジンが生成した表面的意味ツリー構造のグラフ図である。
【図５】図５は、ポインタ・デバイス入力に対して、認識エンジンが作成した表面的意味構造のグラフ図である。
【図６】図６は、本発明の談話エンジンが生成した談話ツリー構造のグラフ図である。
【図７】図７は、押し潰した後のメッセージ・ノードを示す図６の談話ツリーである。
【図８】図８は、ドメイン・テーブルに見られるミーティング・エントリを含ませるための談話ツリーの展開を示す図７の談話ツリーである。
【図９】システムの質問に対するユーザの応答に基づいて、認識エンジンが生成した表面的意味構造のグラフ図である。
【図１０】既存のミーティング・モードがユーザの回答に応答して押し潰された後の図８の談話ツリーである。
【図１１】ミーティング参加者ノードが押し潰された後の図１０の談話ツリーである。
【図１２】受信側ノードが押し潰された後の図１１の談話ツリーである。
【図１３】本発明のダイアログ・システムの第２実施形態のブロック図である。
【図１４】本発明の下におけるダイアログ・システムの、マークアップ言語に基づく実施形態のフロー図である。
【符号の説明】
１００    計算システム環境
１１０    コンピュータ
１２０    処理ユニット（ＣＰＵ）
１２１    システム・バス
１３０    システム・メモリ
１３１    リード・オンリ・メモリ（ＲＯＭ）
１３２    ランダム・アクセス・メモリ（ＲＡＭ）
１３３    基本入出力システム
１３４    オペレーティング・システム
１３５    アプリケーション・プログラム
１３６    プログラム・モジュール
１３７    プログラム・データ
１４０    インターフェース
１４１    ハード・ディスク・ドライブ
１４４    オペレーティング・システム
１４５    アプリケーション・プログラム
１４６    プログラム・モジュール
１４７    プログラム・データ
１５１    磁気ディスク・ドライブ
１５２    リムーバブル不揮発性磁気ディスク
１５５    光ディスク・ドライブ
１５６    リムーバブル不揮発性光ディスク
１６０    ユーザ入力インターフェース
１６１    ポインティング・デバイス
１６２    キーボード
１６３    マイクロフォン
１７１    ローカル・エリア・ネットワーク（ＬＡＮ）
１７２    モデム
１７３    ワイド・エリア・ネットワーク（ＷＡＮ）
１８０    リモート・コンピュータ
１８１    メモリ素子
１８５    リモート・アプリケーション・プログラム
１９０    ビデオ・インターフェース
１９１    モニタ
１９６    プリンタ
１９７    スピーカ
２００    ダイアログ・システム
２０２，２０４    ユーザ・インターフェース
２０６，２０８    認識エンジン
２１０，２１２    言語モデル
２１４    談話エンジン
２１６    談話モデル
２１８    談話メモリ
２２０    ドメイン・テーブル
２２２    ドメイン・エキスパート
２２４    レンダリング・エンジン
２２６    挙動モデル
２２８    ユーザ出力インターフェース
２３０    インターフェース・メモリ
４００    ルート・ノード
４０２〜４１０    子ノード
６００    ルート・ノード
６０２〜６３０    子ノード
８００〜８０４    選択肢
１３００，１３０２    インターフェース
１３０４，１３０６    ネットワーク
１３０８，１３１０    認識エンジン
１３１２，１３１４    言語モデル
１３１６    談話モデル
１３１８    談話メモリ
１３２０    ドメイン・エキスパート
１３２４    ドメイン・テーブル
１３２６    レンダリング・エンジン
１３２８    挙動モデル
１３３０    ユーザ出力インターフェース
１３３２    中間ネットワーク
１３５０，１３５２    ネットワーク
【図１】
0005166661.tif 000010
【図２】
0005166661.tif 000011
【図３】
0005166661.tif 000012
【図４】
0005166661.tif 000013
【図５】
0005166661.tif 000014
【図６】
0005166661.tif 000015
【図７】
0005166661.tif 000016
【図８】
0005166661.tif 000017
【図９】
0005166661.tif 000018
【図１０】
0005166661.tif 000019
【図１１】
0005166661.tif 000020
【図１２】
0005166661.tif 000021
【図１３】
0005166661.tif 000022
【図１４】
0005166661.tif 000023