JP4090040B2 - 双方主導マルチモーダル対話及び関連ブラウジング機構を作成するための方法及びシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、概して云えば、情報アクセス・アプリケーション及びダイアログ・システムに関し、更に詳しく云えば、そのようなダイアログ・システムにおいて使用するために双方主導マルチモーダル対話（mixed-initiative multi-modal interactions）及び自然言語理解（natural language understanding）と関連してそのようなアプリケーションを作成する（authoring）ための技法及び会話型ブラウジング機構に関する。
【０００２】
【従来の技術】
「ダイアログ・システム」は、人間が１つ又は複数の情報アクセス・アプリケーションと対話することを可能にするコンピュータ支援（computer-based）システム又はマシンを指すために一般的に使用される用語である。「アプリケーション」は、或る機能を遂行又は提供する１つ又は複数のコンピュータ・プログラムを指すために一般的に使用される用語である。
【０００３】
「双方主導」ダイアログ・システムは、一般に、ユーザが対話するそのダイアログ・システムの動作にユーザ応答に影響させるということが知られている。即ち、双方主導は、一般に、ユーザによって部分的に又は全体的に推進されるダイアログを管理する能力を指す。例えば、ユーザが主導権を取り、アプリケーションにより求められた質問には必ずしも直接に関係のないリクエストに応えたり、或いはそのようなリクエストを行う。このような双方主導ダイアログ・システムは、一般に、アプリケーションの種々な部分相互間の非逐次的な態様でのナビゲーションも可能にする。このようなシステムの目的は、ユーザとマシンとの間の会話を速やかに完了させることである。
【０００４】
「自然言語理解（ＮＬＵ）」は、ユーザの入力の意図／意味（即ち、セマンティック上の意味 - semantic meaning）を解釈する能力に関連することも知られている。
【０００５】
そのような概念を使用するアプリケーションは、最も自然な且つ融通性のあるユーザ・インターフェースを提供し、従って、ヒューマン・マシン対話を広範に開発及び受容されるようにするためのキーである。
【０００６】
しかし、既存の方法によれば、双方主導ダイアログ又は自然言語理解を使用しようとするようなアプリケーションが、Ｃ、Ｃ++、ｊａｖａ、スクリプト、又はそれらの組み合わせのような「命令型（imperative）」プログラミング言語を使用してほとんど排他的に書かれている。知られているように、１つの命令型プログラミング言語は、伝統的なプログラミング・ロジックの作成を必要とするプログラミング言語である。
【０００７】
残念ながら、命令型プログラミング言語の使用は、そのようなダイアログ・システム及びアプリケーションの開発を、その命令型プログラミング言語における専門家である開発者に制限している。更に、アプリケーションの開発における命令型プログラミングの使用は、何ヶ月もの開発及び支援を必要とするかもしれない。
【０００８】
一方、「宣言型（declarative）」プログラミングは、命令型プログラミングが必要とする同じタイプの伝統的なプログラミング・ロジックの作成を必ずしも必要としないことが知られている。しかし、スピーチ・イネーブルド（speech-enabled）アプリケーションのための ＶoiceＸＭＬ(Voice Extensible Markup Language)のようなマークアップ言語を使用する宣言型作成は、主として、有向（directed）ダイアログ・システムに限定されていた。双方主導ダイアログ・システムとは反対に、有向ダイアログ・システムは、厳密には、マシン駆動される。即ち、ユーザは、アプリケーションがアクションを遂行することを必要とするすべての情報が収集されるまで、そのマシンによって与えられるプロンプトに逐次態様で応えなければならない。従って、有向ダイアログ・システムの場合、対話が質疑応答型セッションに制限されるので、ユーザは、自然にアプリケーションと対話することができない。
【０００９】
【発明が解決しようとする課題】
従って、ダイアログ・システムにおいて使用するための双方主導マルチモーダル対話及び自然言語理解と関連した宣言型プログラミング及び他のプログラミングを使用するアプリケーション作成技法及びそれと関連した他の情報ブラウジング機構に対する要求が存在する。
【００１０】
【課題を解決するための手段】
本発明は、ダイアログ・システムにおいて使用するための双方主導マルチモーダル対話及び自然言語理解と関連したプログラミングを使用するアプリケーション作成技法及びそれと関連した情報ブラウジング機構を提供する。
【００１１】
本発明の１つの局面では、ダイアログ・システムに従ってユーザによりアクセス可能なアプリケーションを生成する方法は、ユーザが行い得るダイアログ・システムとの対話を、１つのデータ・モデル及び１つ又は複数のユーザ対話要素として表すステップを含み、 ここで該１つ又は複数のユーザ対話要素はデータ・モデルのアプリケーション状態を移植し且つそれにバインドされる。更に、そのアプリケーション生成方法によれば、ユーザが行い得る前記ダイアログ・システムとのダイアログが双方主導ダイアログであるように、前記ユーザの意図が１つ又は複数のユーザ対話要素の解釈及びユーザ入力からのセマンティク上の意味の抽出から決定され、それによって前記アプリケーションからのナビゲーションが、非逐次的な態様で及び少なくとも部分的にユーザに推進されて実行されることができ、１つ又は複数のユーザ対話要素の少なくとも一部分は、そのアプリケーションにおける１つ又は複数のモダリティ特有のレンダリング（modality-specific rendering）に変換又は関連付け可能であり、そのレンダリングは、ユーザに提示し得るし、ダイアログ・マネージャ・アルゴリズムによって選択又は生成される。
【００１２】
本発明の別の局面では、ユーザによるアプリケーションへのアクセスを提供するための会話型ブラウザ装置が、対話マネージャと、その対話マネージャに動作可能なように結合され、ボイス・ベースのブラウザである少なくとも１つのモダリティベースのブラウザと、その対話マネージャに動作可能なように結合されたダイアログ・マネージャとを含む。ユーザ、対話マネージャ、音声ベースのブラウザ、及びダイアログ・マネージャの間の対話は、以下のようなステップを含む。
（１）対話マネージャがユーザ・リクエストに応答してサーバからアプリケーションを獲得し、そのアプリケーションの表示をダイアログ・マネージャに送る。
（２）ダイアログ・マネージャがそのアプリケーションの表示に従ってアプリケーションのフォーカス及びユーザの意図の少なくとも１つを決定し、そのアプリケーションのフォーカス及びユーザの意図の少なくとも１つを対話マネージャに知らせる。
（３）そこで、対話マネージャがボイス・ベースのブラウザに従ってユーザに提供するためのそのアプリケーションの特定の部分（例えば、断片）をそのアプリケーションのフォーカス及びユーザの意図の少なくとも１つの決定に基づいて指定する。なお、その部分は、少なくともプロンプト及び入力フィールドを含み、そのプロンプトはユーザに提示され、入力フィールドは、アプリケーションのフォーカス及びユーザの意図の少なくとも１つを再決定する場合に使用するためにそのプロンプトに応答して受領し得るユーザ入力を指定する。
【００１３】
本発明の更にもう１つの局面では、ユーザによるアプリケーションへのアクセスを提供するための会話型ブラウザ装置は、対話マネージャ機能、対話マネージャに動作可能なように結合された少なくとも１つのモダリティベースのブラウザ機能、及び対話マネージャ機能に動作可能なように結合されたダイアログ・マネージャを含む。ユーザ、対話マネージャ機能、ブラウザ機能、及びダイアログ・マネージャ機能は、以下の動作を含む。
（１）対話マネージャがユーザ・リクエストに応答してサーバからアプリケーションを取得する。そのアプリケーションは、ユーザが行い得るそのアプリケーションとの対話を、１つのデータ・モデル及び１つ又は複数のユーザ対話要素として表す。ここで１つ又は複数のユーザ対話要素はそのデータ・モデルのアプリケーション状態を移植し且つそれにバインドされる。
（２）ダイアログ・マネージャがユーザ入力から生成された属性値ペアを受け、それらの属性値ペアを処理してデータ・モデルを移植し、次の対話フォーカスを決定する。
（３）ダイアログ・マネージャによる次の対話フォーカスの決定時に、アプリケーション状態及びコンテキストが更新され、出力が対話マネージャによって生成され、ブラウザを介した対話のためにユーザに供給される。
【００１４】
本発明は、一般に、アクセス・プロトコル、モダリティ、ブラウザ、又はデバイスに関係なく、任意の情報アクセス・アプリケーションに適用可能であることは明らかである。１つの実施例では、本発明（作成局面及び（又は）アーキテクチャ局面）は、ボイス・ブラウザ及び音声拡張可能マークアップ言語（ＶoiceＸＭＬ）に直接に適用可能である。本発明の原理は、宣言型又は非宣言型対話アプリケーション（又は、宣言型及び非宣言型対話アプリケーションを混合したアプリケーション）に適用することができる。従って、本発明は、双方主導マルチモーダル（又は、ボイス・オンリ）対話及び自然言語理解／フリー・フロー概念と関連してプログラミングを提供することが望ましい任意の情報アクセス状況に更に一般的に適用可能である。
【００１５】
本発明のこれらの及び他の目的、特徴、及び利点は、添付図面に関連して読解されるべき本発明の実施例に関する以下の詳細な説明から明らかになるであろう。
【００１６】
【発明の実施の形態】
以下の記述は、本発明をよりよく理解するために、ＩＭＬ（Interaction Markup Language）の好適な仕様、望ましい対話型ブラウジング環境、及び幾つかの例示的応用を使用して本発明を説明している。しかし、本発明がこれらの特定の望ましい実施方法及び例示的応用に限定されないことは当然である。
【００１７】
「マルチモーダル」であるダイアログ・システムが、そのシステムとユーザとの間の種々なモードの対話をサポートするものであることは明らかである。そのような対話のモードは、音声、キーボード、筆跡、顔の表情、コンテキスト、感情等を含み得るが、それらに限定されない。従って、ユーザは、複数のモード（例えば、音声、テキスト等）でデータをダイアログ・システムに出力し得るけれども、そのシステムは、複数のインターフェース又はチャネル（例えば、スピーカ、グラフィカル・ユーザ・インターフェース等）を使用して複数のモードでデータをユーザに出力し得る。更に、本発明は、マルチモーダル会話型アプリケーションに関して図解的に説明されるけれども、それは、ボイス・オンリの対話に対しても実施可能であることも明らかである。
【００１８】
自然言語理解（ＮＬＵ）がユーザの特定の自然入力の背後にある意味／意図を理解する能力を指すことも理解されるべきである。文法により制約されたセンテンスを単に認識する代わりに（即ち、ユーザが、所与の時点で云うことができることに関して如何に制約されるかにより）、或いは、（例えば、確率的文法（stochastic grammar）、即ち、言語モデルを使用して）ユーザが云おうとしていることを理解／解釈することなく単に転写する代わりに、ＮＬＵの場合、システムは、一連の属性に対比してこれをマップするために及び入力の背後にある意図を特徴付ける一連の値ペアを生成するために自由形式の態様で表現されたその入力を処理する。
【００１９】
更に、双方主導は、一般に、ユーザによって部分的又は全体的に推進されるダイアログを管理するための能力を指す。ユーザは主導権を取り、アプリケーションによって求められた質問に必ずしも直接に関連しないリクエストに応えるか又はそのリクエストを表す。アプリケーションは、リクエストを理解できなければならず、それに基づいて、対応するアクションを実行する（例えば、何かを実行する（フェッチする、サブミットする、予約する等）又は、答えを表示する）か、或いは、ダイアログを継続して更なる情報を適宜収集する。アプリケーションが進行するためには、アプリケーションは、ユーザ入力を理解ために及びフォーカスを決定するために明確化（disambiguation）タスク及び正規化（canonicalization）タスクを遂行しなければならないであろうし、或いは、これまでのは解釈に関する確認及び起こり得る訂正を可能にするために追加のダイアログを開始することさえ必要とするであろう。
【００２０】
明確化タスクは、コンテキスト等に基づいた特定の入力が一義的に解釈可能であり且つ意味をなすか（例えば、１つの、しかも唯一のフライトがその時に存在するか）どうかを調べる。正規化は、異なる入力をアプリケーションにとって意味のある正規の形式にマップする（例えば、「次の火曜日」、「５月２９日」、「火曜日」は「５／２９／０２」上にマップ可能である）。これは、一般に、アプリケーションの残りにとって何が意味のあるものであるかを知っているアプリケーション（ビジネス・ロジック）特有のコードを必要とする。正規化は、レンダされるべき入力属性値ペア又はコンテキストを、そのアプリケーションにとって標準的な且つ明白なフォーマットに変換するためのアクションとして定義される。
【００２１】
従って、双方主導／フリー・フロー／会話型アプリケーションを展開するためには、ユーザが入力を供給する時、ユーザの意図を理解できることが必要である。フリー・フローが意味するように、何とかして自由がユーザに与えられなければならない。ＮＬＵは、この目的を達成するための自然な方法である。Proc. Eurospeech, 1999 誌の "Free-flow Dialog Management Using Forms" と題した K. A. Papineni 氏による論文、及び Proc. Eurospeech, Budapest, 1999 誌の"The IBM Conversational Telephony System for Financial Applications" と題した K. Davies 氏他による論文に記載されているように、ＮＬＵは、統計的な方法に従って行うことが可能である。ＮＬＵは、ユーザが自分の入力を公式化することができるあらゆる可能な方法を予測する複雑な文法を形成することによっても作成可能である。
【００２２】
参照を容易にするために、詳細な説明を次のようなセクション、即ち、
（Ｉ）宣言型アプリケーション作成技法、及び
（II）会話型ブラウザ・アーキテクチャ
に分けることにする。セクション（Ｉ）は、本発明によるＩＭＬの望ましい実施方法に関する詳細な説明を行う。セクション（II）は、本発明に従ってＩＭＬを支援、構文解析、及びレンダする望ましい会話型ブラウジング環境に関する詳細な説明を行う。
【００２３】
Ｉ．宣言型アプリケーション作成技法
詳細に後述するように、本発明は、対話マークアップ言語、即ち、ＩＭＬと呼ばれるプログラミング言語に基づいて宣言型ＸＭＬ（拡張可能マークアップ言語−Extensible Markup Language）におけるアプリケーションの作成を可能にする。ＩＭＬを使用する宣言型プログラミングが、本願において示される詳細な説明に基づいて当業者により直接に実施可能であることは明らかである。しかし、２０００年４月６日に出願された米国特許出願番号第０９/５４４,８２３号として識別され且つ「マルチモーダル・ブラウジング及び会話型マークアップ言語を実装するための方法及びシステム（Methods and Systems for Multi-Modal Browsing and Implementation of a Conversational Markup Language）」と題した米国特許出願において開示された会話型マークアップ言語（ＣＭＬ）に従ってＩＭＬが実装可能であることも明らかである。シンタックス及びセマンティクスは特定のアプリケーションに依存するので、本願において発明を教示する場合、当業者が１つ又は複数の特定のアプリケーションに対して適切なシンタックス及びセマンティクスを生成できるであろうということも更に明らかである。
【００２４】
ＩＭＬフレームワークにおけるアプリケーション作成に対して３つのコンポーネント、即ち、
（ｉ）ユーザ対話
（ii）データ・モデル
（iii）プレゼンテーション
が存在する。以下は、これらの各コンポーネント及びそれらの間の関係を説明する。
【００２５】
（ｉ）ユーザ対話：会話の基本的要素をエンコードする
本発明によれば、会話型アプリケーションが、複数のモダリティにまたがり一貫して最高レベルにおける会話を可能にするように設計された宣言型言語で書かれる。そのような言語は、本願では「会話型ジェスチャ（conversational gestures）」と呼ばれる対話ベースの要素を使用して、アプリケーション作成者がアプリケーションをプログラムすることを可能にする。会話型ジェスチャは、プログラムされるアプリケーションに関連した情報をアクセスするために使用されるモダリティ、装置、又はブラウザに関係なく、任意のダイアログを特徴付けるＩＭＬの基本的プログラミング・コンポーネント又は要素である。
【００２６】
アプリケーションの機能（behavior）を指定するために使用される原始的な一連の会話型ジェスチャは、例えば、「ダイアログ」、「メッセージ」、「入力」、「選択」、及び「サブミット（submit）」を含み得る。例えば、システムがデータを提示又は収集するために使用する各「メッセージ」又は「入力」は、ＸＰath を使用して簡単に定義され、データ・モデルにおける情報にバインド可能である。説明のために、以下は、旅行関連のダイアログ・システムのために書かれたアプリケーションからの抜粋である。
【００２７】
<dialog name="trip/air"action="submit">
<message>
Welcome<value name="trip/user/firstName"/>
<value name="trip/user/lastName"/>!
</message>
<input name="arrivalCity">
<grammar src="travel.gram"/>
<caption> Where will you be flyingto?</caption>
</input>...
<submit target="http://localhost/DB"/>
</dialog>
【００２８】
この例は、出力プレゼンテーションのための "firstName"及び "lastName" データ・モデル・インスタンス・ノードにバインドされた "Welcome" メッセージ・ジェスチャ、及び"arrivalCity" データ・モデル・インスタンス・ノードにバインドされた"arrivalCity" 入力ジェスチャを示す。メッセージは、"trip/user/firstName" のような完全なＸＰath 表現法を使用し、一方、入力は、最も近いダイアログ・ジェスチャ名＝"trip/air" におけるバインディング及び入力ジェスチャ名＝"arrivalCity"内のバインディングの両方からパス "trip/air/arrivalCity" を構成する。
【００２９】
（ii）データ・モデル仕様
望ましい実施方法では、データ・モデルはＸＭＬにおいて指定され、プレゼンテーション及びコントローラとは別個のものである。ここでは、コントローラは、対話に基づいてユーザがモデルを更新するために使われる機構を指し、例えば、これは、後述するように、ダイアログ・マネージャを含み得る。この結果、視点の更新が生じる。旅客及び飛行機旅行情報を含むデータ・モデルの一例が、次の通りに指定されうる。
【００３０】
<?xml version="1.0?">
<trip>
<user>
<firstName/>
<lastName/>
<password/>
</user>
<air>
<departureCity/>
<departureDate/>
<arrivalCity/>
<returnDate/>
</air>
</trip>
【００３１】
"firstName"及び"departureCity"のようなこのデータ・モデルにおけるスロットの各々がユーザとの対話を通して移植される。ダイアログ構造は融通性があり、ユーザが単一の対話で種々の順序で複数のスロットを満たすことを可能にする。後で説明するように、アプリケーションを実行するダイアログ・システムと関連したダイアログ・マネージャは、データ・モデルを使用して会話コンテキストを追跡し、どのスロットがユーザからの情報でもって満たされているか、及びどのスロットがフォームを完成するために提示される必要があるかを決定する。
【００３２】
（iii）プレゼンテーション・ルール
音声、テキスト、及びジェスチャはすべて同じ目的に対する手段として働くが、各々と関連したプレゼンテーション方法は本来異なる。視覚的プレゼンテーションでは、アプリケーション作成者は、情報の空間的プレゼンテーションにわたって厳密な制御を持つことを希望することがある。しかし、音声の会話では、システムは、適切に提示及び応答するためにユーザが選択するどのような情報でも受けるように適応する必要がある。従って、ＩＭＬの実施例では、ＸＳＬＴ（ＸＳＬ transformation）は、作成者が、特定のモダリティにおけるデータ・プレゼンテーションの詳細を指定することを可能にするために使用される。従って、そのような構造によって、ＩＭＬは、情報がすべてのモダリティに対して融通性のある順序でユーザから収集されることを可能にする。説明上の実施例ではＸＳＬＴ及びＩＭＬという用語が使用されるけれども、他の変換機構及びフォーマットが使用可能である。
【００３３】
例えば、ＸＳＬＴの場合、ＩＭＬアプリケーション設計者は、下記のようにＨＴＭＬ（ハイパーテキスト・マークアップ言語 - Hyper Text Markup Language）に対するＸＳＬＴルールにおいて特別なタグを含むことによって、視覚的データの正確な順序、フォント、サイズ、カラー、及び配置を指定することができる。
【００３４】
<xsl:template match="dialog[@format_key='D2']">
<p>I want the best round-trip travel:<p/>
<table><tr><td><b>From:</b></td>
<td><xsl:apply-templates select="input[@select_key='I4']"/>
</td><td><b>To:</b></td>
<td><xsl:apply-templatesselect="input[@select_key='I5']"/>
</td></tr>...</table>...
</xsl:template>
【００３５】
更に、特別な必要性を有する個々のユーザは、より大きいフォント、より大きいボタンを示すために、或いはジェスチャ又は別の入力装置を通した選択入力を可能にするために、特別なＸＳＬＴルール使用し得る。
【００３６】
プレゼンテーション・カスタム化は、対話ロジック層及びデータ・モデルとはまったく相違するものである。その結果、視覚的プレゼンテーションは、特別に配置された「From」フィールド及び「To」フィールドを出力として示し得るし、一方、ボイス・チャネルは、「どこに行きたいですか（Where would you like to go ?）」を出力として発生し得る。プレゼンテーションを基本的な対話ロジックから分離することは、ユーザの融通性が種々のモダリティを通して種々の方法で入力を表すことも可能にする。例えば、旅行のアプリケーションにおける視覚的プレゼンテーションに従って、「From」フィールドを「To」フィールドの前に示すことが可能である。それは、視覚的には、ユーザが旅行を記述した右から左への線を考え得るためである。しかし、ユーザは、依然として、そのユーザが希望するどのような順序の情報も、例えば、「私はボストンからニューヨークに飛びたい（I want a flight to New York, leaving from Boston.）」を口頭で表すことができる。ジェスチャは同期化され、ＸＰath を使用して同じデータ・モデルにバインドされるので、ユーザがこの応答を発生するとき、情報は、ＨＴＭＬディスプレイの適切なフィールドにおいて逆の順序で現れるであろう。
【００３７】
ＸＳＬ、ＸＳＬＴ、及びＸＰath のような周知の標準の仕様が、Ｗ３Ｃ（ワールド・ワイド・ウェブ・コンソーシアム -World Wide Web Consortium）において見ることができることは明らかである。しかし、本発明がＸＭＬ又はそのような関連の変形に依存しないことも更に明らかである。本発明は、単に、プレゼンテーション（又は、マルチモーダルの場合の多重プレゼンテーション）をデータ・モデル（手操作で作成された又はプレコンパイルされた）にバインドすることを意図している。フォーカスがダイアログの特定の部分にセットされるとき、対応するプレゼンテーションが対話のためにユーザに送られる。
【００３８】
代表的な例では、ＶoiceＸＭＬのスニペット（snippet）がアプリケーションにおける各フォーカス位置に関連付けられる。これは、次のものだけを含む。
（１）ダイアログ・マネージャによって決定されるプロンプト（これは、フォーカス及びコンテキストに基づいて動的に発生されることもある）、及び
（２）１つの入力だけを待つ入力フィールド。関連のデータ・ファイルがＮＬＵ文法の使用を指定する。これは、ボイス・ブラウザがＮＬＵ構文解析（及びデコーディング／転記のための言語モデル）を使用することを意味する。これは、Ｘgrammar が指定されるときにＬＭ（言語モデル - language model）及び構文解析をサポートするために、ＶoiceＸＭＬ ２.０の拡張として（そのような新しい文法のタイプを理解するために）、又はＶoiceＸＭＬの再解釈として理解されるべきである。
【００３９】
（iv）ＩＭＬアプリケーション
従って、本発明によれば、詳しく上述したように、ＩＭＬアプリケーションは、ＸＭＬスキーマを通してモデル化されたアプリケーション状態及びこのアプリケーション状態を移植するために使用されるユーザ対話要素（即ち、会話型ジェスチャ）を含む。アプリケーション状態は、リッチ・タイプの情報を捕捉する。例えば、フィールド「departureDate」の値は、タイプ「date」の値である。アプリケーションは、フィールド「arrivalDate」が「departureDate」に先行しないことを必要とする関係のような高レベルのセマンティック関係も捕捉する。ＩＭＬにおけるユーザ対話要素は、基礎的なアプリケーション状態にバインドし、アプリケーション状態によってモデル化された基礎的タイプの制約に基づいて豊富なユーザ対話をもたらす。
【００４０】
更に、詳細に後述するように、アプリケーション状態においてカプセル化されたタイプ制約及びクロス・フィールド制約は、ダイアログ・マネージャを介して適切な明確化ダイアログの作成を援助するために、自然言語理解（ＮＬＵ）エンジンに対する入力として使用される。更に、任意の所与の時点でアプリケーション状態に記憶され且つ連のモデル制約と結合された値の状態、及び入力の複数のモダリティを介して表現されたユーザの意図の解釈が、ユーザとダイアログ・システムとの間における対話の次のステージを決定するためにダイアログ・マネージャによって結合される。
【００４１】
従って、本発明に従って、双方主導ＩＭＬダイアログが次のような動作によって達成される。
（１）アプリケーション状態をそれのタイプ制約及びクロス・フィールド制約と共にモデル化する。
（２）ＩＭＬインタープリタにおいて表されたアプリケーション状態を連続的に維持し、更新する。任意の所与のダイアログ・ターン時のアプリケーション状態は、ユーザによって現在満たされているスロット及び、アプリケーション・バックエンドがある場合には、そのアプリケーション・バックエンドによって満たされたスロットを含む。
（３）セマンティック上の意味を抽出するためにユーザの発言（utterance）をＮＬＵエンジンに送る。
（４）ユーザ発言に関する豊富な文脈依存性の解釈（context-sensitive interpretation）を可能にするために、ＮＬＵエンジンによって戻されたセマンティック上の意味と共にアプリケーション状態に存在する文脈上の知識を使用する。後で説明するように、これは、アプリケーション状態及びＮＬＵエンジンの結果をダイアログ・マネージャに送ることによって達成可能である。
（５）ダイアログのどの部分が次にトラバースされるかを決定してアプリケーション状態を更新するために文脈依存性の解釈を使用する。ダイアログ・マネージャを含むアーキテクチャでは、フォーカス決定は、ダイアログ・マネージャの文脈依存性の解釈の結果であってもよい。
（６）ＮＬＵイベントを組み込むように機能強化されたＩＭＬにおける定義されたイベントのリストが、適切なイベント・ハンドラをこれらのイベントに付加するための機構をＩＭＬ作成者に提供する。このようなイベントは、パーサ・イベント（parser event）、正規化及び明確化に対するリクエスト、明確化及び正規化からの結果、ダイアログ管理正規化、明確化又は他の外部ソースからデータ・モデルに対する１つ又は複数のスロット更新、コンテキストのサブミッション、ダイアログに対する更新（例えば、確認、修正、援助等のためにサブ・ダイアログをロードする）を含む。以下では、更に多くのイベントが提供され、説明される。
（７）機能強化されたＩＭＬを通して、アプリケーション作成者はアプリケーション内部のナビゲーションを指定することができ、従って、現在のアプリケーション状態又は生成されたイベントの結果に基づいてフォーカス・シフトを強制する。
【００４２】
都合がよいことに、ＩＭＬは、アプリケーション状態及びそれの関連制約の宣言型作成を提供する。更に、ＩＭＬは、そのような制約をＮＬＵエンジンへの入力として「てこ作用」に使う（leverage）。従って、ＮＬＵエンジンは、ユーザの意図を解釈する目的で使用される、ダイアログ・システムにおける入力のもう１つのソースである。
【００４３】
本発明による宣言型プログラミングを介して実現されたこれらの及び他の特徴及び利点が、以下のセクションで示されるように、ＩＭＬをサポートし、構文解析し、及びレンダする本発明の会話型ブラウザ・アーキテクチャの実施方法の説明に基づいて更に明らかになるであろう。
【００４４】
II．会話型ブラウザ・アーキテクチャ
さて、図１を参照すると、本発明の実施例に従ってＩＭＬアプリケーションをサポートすることができるダイアログ・システムのブロック図が示される。図示のように、ユーザ１０２が対話するダイアログ・システム１００は、会話型ブラウザ１０４、アプリケーション・サーバ１０８、アプリケーション・バックエンド１１０、自動音声認識装置（ＡＳＲ）エンジン１１２、テキスト・ツー・音声（ＴＴＳ）エンジン１１４、及び自然言語理解（ＮＬＵ）エンジン１１６を含む。会話型ブラウザ１０４自体は、ダイアログ・マネージャ１０６、グラフィカル・ユーザ・インターフェース（ＧＵＩ）ブラウザ１１８、ボイス・ブラウザ１２０、ＮＬＵ属性値（ＡＶ）ペア・エクストラクタ１２２、及び対話マネージャ１２４を含む。ダイアログ・マネージャ１０６は、代替え手段としては、対話マネージャ１２４の統合部分であってもよく、或いは、会話ブラウザ自体とは別のものであってもよいことは明らかである。更に、ＧＵＩブラウザ１１８は、マルチモーダルの実施例にのみ含まれることも明らかである。更に、ＧＵＩブラウザによって与えられたモダリティの代わりに、他のモダリティが使用されてもよい。
【００４５】
ダイアログ・システム１００は、ユーザ１０２が、双方主導／フリー・フロー・ダイアログを介して、アプリケーション・サーバ１０８のようなコンテンツ・サーバと関連した１つ又は複数のアプリケーションと対話することを可能にする。ダイアログ・システムのコンポーネントが適切なネットワーク１０８を介して接続可能である。本発明は、いずれの特定なネットワークにも限定されず、従って、例えば、ワイヤレス、ハードワイヤード、ローカル・エリア、ワイドエリア等であってもよい。一実施例では、ネットワークは、ワールド・ワイド・ウェブ又はインターネットである。別の実施例では、ネットワークは、イントラネットであってもよい。また、ダイアログ・システムは、幾つかのネットワーク、例えば、
（ｉ）ワイヤレス・ネットワーク（例えば、ブロック１０２及び１２０の間、又はブロック１２０及び１２４の間）；
（ii）公衆交換電話網、即ち、ＰＳＴＮ（例えば、ブロック１０２及び１２０の間）；
（iii）インターネット（例えば、ブロック１１８及び１２４の間、又はブロック１０２及び１２０の間等）；
（iv）イントラネット（例えば、ブロック１２０及び１２４の間、及びブロック１２４の背後）
によって接続可能である。
【００４６】
会話型ブラウザ１０４は、２つの対話モダリティ、即ち、ビジョン／テキスト・エントリ（ＧＵＩブラウザ・コンポーネント１１８）及び音声（ボイス・ブラウザ・コンポーネント１２０）の使用を示すけれども、本発明がこれらのモダリティに限定されないことは明らかである。更に、用語「ブラウザ」は、一般には、ユーザがデータと対話することを可能にする１つ又は複数のコンピュータ・プログラムを指すことを意味することも理解されるべきである。従って、マイクロソフト社のインターネット・エクスプローラ（Internet Explorer）のような周知のＨＴＭＬブラウザによって提供される機能と同じ機能を提供するＧＵＩブラウザが使用可能である。使用可能なボイス又は音声ブラウザの例は、Websphere Voice Server の一部であるＩＢＭ社のＶoiceＸＭＬブラウザを含む。
【００４７】
会話型ブラウザ１０４は、ユーザ１０２のクライアント装置において全体的に又は部分的に実装されることが望ましい。例えば、クライアント装置は、パーソナル・コンピュータ、ラップトップ・コンピュータ、パーソナル・ディジタル・アシスタント、通常の電話を含むセル電話等であってもよい。しかし、会話型ブラウザ１０４は、クライアント・コンピュータ・システム及びサーバ・コンピュータ・システムの両方を含む複数の装置において実装可能であることは明らかである。
【００４８】
エンジン１１２、１１４及び１１６は、クライアント装置においても実装可能である。従って、ダイアログ・システム１００は、クライアント／サーバ・アーキテクチャの形式のものである。しかし、本発明がそのようなアーキテクチャに限定されないことは明らかである。むしろ、ダイアログ・システムの個々のコンポーネントは、適当な態様で接続された個々のコンピュータ・システムおいて実施可能である。このような構成の幾つかの例が、２０００年２月１８日に出願された出願番号第０９/５０７,５２６号として識別される米国特許出願、２０００年４月６日に出願された出願番号第０９/５４４,８２３号として識別される米国特許出願、及び２００１年１２月４日に出願された速達便番号ＥＬ７９７４１６０４２ＵＳによって識別され、２０００年１２月４日に出願された出願番号第０６/２５１,０８５号として識別される米国特許仮出願に対して優先権を主張する「モジュラＤＯＭベースのマルチモーダル・ブラウザを実装するためのシステム及び方法（Systems and Methods for Implementing Modular DOM-Based Multi-Modal Browsers）」と題した米国特許出願において開示されている。
【００４９】
概して、ユーザ１０２は、テキスト・インターフェース及び（又は）グラフィック・インターフェース（ＧＵＩベースの入出力装置、例えば、ディスプレイ、キーボード、マウス等）を介してダイアログ・システム１００とインターフェースし、そのインターフェースは、音声（オーディオ入出力装置、例えば、マイクロフォン、スピーカ等）を介してクライアント装置と関連付けられる。これらの入出力装置は、アクセスされたアプリケーションに従って生じるダイアログの過程でユーザ・データから入力を受け、出力データをユーザに与えるために、モダリティ特有のブラウザ（ＧＵＩブラウザ１１８及びボイス・ブラウザ１２０）に対する物理的メカニズムを提供する。それらの入力は、各モダリティ／装置特有の視点を通してイベントの形に抽象化される。出力イベント及び命令は、これらのブラウザによってレンダされたプレゼンテーションを通してユーザに提供される。ブラウザが明白には存在しない他のアーキテクチャを考慮することが可能であるが、入力は入力イベントになり、出力イベントは、ユーザに対する出力に変換される。
【００５０】
ユーザのリクエストに基づいて、会話型ブラウザ１０４は、特定の所望のアプリケーションに対するアクセスをリクエストするために、適切なＵＲＩ（ユニフォーム・リソース識別子 - uniform resource identifier）をアプリケーション・サーバ１０８（コンテンツ・サーバ）に送る。そこで、セクションＩにおいて説明した本発明の原理に従って作成された、アプリケーションと関連のＩＭＬコードがアプリケーション・サーバ１０８から会話型ブラウザ１０４にダウンロードされる。しかる後、会話型ブラウザ１０４は、モダリティ特有のレンダリング、例えば、ＧＵＩ表示及び（又は）音声表示を、それらがＩＭＬコードと関連した対話要素（例えば、会話型ジェスチャ）に基づいているときに生成する（又は、それらが手操作で作成又はプリコンパイルされた場合にそれらをデータ・モデルにバインドさせる）。従って、ユーザは、これらの表示を介して会話型ブラウザ１０４と対話する。
【００５１】
図１に示された説明的なアーキテクチャを仮定して、次に、ダイアログ・システムのコンポーネントと関連した種々の詳細な特徴及び対話を説明することにする。
【００５２】
（ｉ）双方主導会話型ブラウジング
会話型ブラウザ１０４は、入力を受け付け、種々のモダリティ又は装置、例えば、音声（例えば、ＶoiceＸＭＬ）、ワイヤレス・アプリケーション・プロトコル、又はＷＡＰ（例えば、拡張可能ＨＴＭＬモバイル・プロファイル - Extensible HTML Mobile Profile、即ち、ＸＨＴＭＬ-ＭＰ、及びワイヤレス・マークアップ言語 - Wireless Markup Language、即ち、ＷＭＬ）、及びＧＵＩ（例えば、ＸＨＴＭＬ）における利用可能な出力を同時に（並行して、又は逐次に）レンダする。他の装置又はモダリティが同じ方法で付加可能であることは明らかである。
【００５３】
双方主導ダイアログ・マネージャ１０６は、「従来の技術」の項において説明したように、タスクを遂行するよう及び所定の順序で情報を提供するようユーザを強制する指示ダイアログ・モード（例えば、マシン始動の発声されたダイアログ）とは反対に、アプリケーションをナビゲートする方法及びタスクを完成する順序をユーザが選択することを可能にする。対話マネージャ１２４は、ナビゲーションの自由を維持しながら、種々のモダリティにおける同時対話をスムーズにマージする更に自然な会話態様をユーザが続行することを可能にする。対話のヒストリは、ユーザの意図を理解し、明確にするよう利用される。
【００５４】
本発明によれば、対話マネージャ１２４は、ユーザの入力を抽象的に（即ち、モダリティとは無関係に）、関連のモダリティ特有の情報がある場合にはその情報と同様に、ダイアログ・マネージャ１０６に対してコミュニケーションを行う。その場合、ダイアログ・マネージャは、ユーザの対話を明確にしてそれを解釈し、必要な場合には、意図をよりよく理解することを助けるために、又は解釈を確認又は修正する可能性を提供するために、新しい対話ダイアログを開始させる。会話型ブラウザは、以下で説明されるように、ドキュメント・オブジェクト・モデル（ＤＯＭ）ベースのモデル・ビュー・コントローラ（ＭＶＣ）方法を使用することが望ましい。
【００５５】
図１に示された実施例では、対話マネージャ１２４は、ＧＵＩブラウザ１１８及びボイス・ブラウザ１２０を制御する。上述のように、会話型ブラウザ１０４の各コンポーネント又はサブコンポーネントは、局所的なものであるか、又は相互に関して分散可能である。１つの実施例では、対話マネージャ１２４は、２０００年２月１８日に出願された出願番号第０９/５０７,５２６号として識別される米国特許出願、及び２０００年４月６日に出願された出願番号第０９/５４４,８２３号として識別される米国特許出願において開示されたようなマルチモーダル・シェルとして実施可能である。
【００５６】
対話マネージャ１２４は、ＧＵＩブラウザ１１８又はボイス・ブラウザ１２０からのユーザの入力を捕捉する対話イベント（ＤＯＭイベント又は作成されたイベント）を受け取り、適切なブラウザの各々におけるプレゼンテーションを更新することによってそれぞれのブラウザへの出力を適切なモダリティでレンダする。
【００５７】
本発明によれば、アプリケーションがＩＭＬにおいて作成され、ブラウザ視点の１つにおいてレンダされるとき、適切なモダリティにコード変換される。前に説明したように、コード変換する代わりに、フォーカスの決定時に、データ・モデル（例えば、事前作成された又はコンパイルされたＶoiceＸＭＬスニペット）にバインドされたプレゼンテーションを使用することが可能である。他の作成方法がこのアーキテクチャでもって使用可能である。特に、各ターゲット・チャネルに適したプレゼンテーションが手操作で作成され、同期化情報と共にＩＭＬデータ・モデルにバインド可能である。
【００５８】
対話マネージャ１２４及びダイアログ・マネージャ１０６は、ユーザ対話及びこの対話を通してユーザにより操作されたデータ・モデルを抽象的に記述したユーザ対話ロジック層のＤＯＭツリー表示を維持する。このＤＯＭ表示は、ダイアログ・マネージャ１０６及び対話マネージャ１２４がシステムの不可欠なコンポーネントとして実装される場合、それらの間で共用可能である。ダイアログ・ジェスチャは、特定の論理的タスクに対応し、「フォーム（form）」とも呼ばれる。各フォームは、タスクを完成するために必要な情報を収集するために幾つかの「入力ジェスチャ」を含み得る。入力ジェスチャによって収集されたデータはデータ・モデルに記憶される。各入力ジェスチャは、そのフォームにおける「スロット」に対応する。ＩＭＬアプリケーションは、幾つかのフォームを含み得る。アプリケーション・コードの更なる例が以下に示される。
【００５９】
双方主導のダイアログ・マネージャ１０６は、ユーザのリクエストに従ってタスクを遂行する。コンピュータがダイアログを通して制御を維持する有向ダイアログ方式（directed dialog scheme）とは異なり、双方主導のダイアログ・マネージャ１０６は、ユーザの入力がどのタスクに向けられるかというプリオリ（priori）を知らない。ダイアログ・マネージャ１０６の主要な機能の１つは、ユーザの入力が最も適しているスロット及びフォームを推定することである。ダイアログ・マネージャ１０６は、ユーザ入力を調和させること及びトップのスコアリング・フォーム（scoring form）を見つけるために各フォームにスコアを割り当てることによってこれを行う。
【００６０】
何らかの１つのタスクを完成するために必要な情報をすべて収集するために、会話において幾つかのターンを行い得る。航空機座席予約アプリケーションでは、出発地、到着地、出発時間等のような幾つかの情報片がユーザから収集されなければならないことがある。この場合、ユーザは、自分がどこから出発しようとしているのか、何時に出発したいのか等のような欠落情報に対してプロンプト指示されなければならないであろう。ユーザは、座席予約を行うときに常連顧客飛行距離（frequent flier miles）をチェックするというようなことを種々のタスクの間をいつも切り替えることができる。従って、ダイアログ・マネージャ１０６は、ユーザの意図をモデル化し、この例では、ユーザが照会を完了することを助けるために適切なタスクに切り替わる。ユーザによって与えられた情報があいまいなことがあり、従って、ダイアログ・マネージャ１０６はダイアログを明確にする。矛盾があったり、或いは明らかに間違っているとき、ダイアログ・マネージャ１０６は、訂正、明確化、又は確認を求めるために適切なタスクに切り替わる。
【００６１】
ダイアログ・マネージャ１０６のもう１つの重要な機能は、フォーカス決定又はその会話における次のターンを指定することである。フォーカス決定は、ダイアログ・マネージャが入力をプロンプト指示し、及び（又は）入力を明確にすることを要求する。ダイアログ・マネージャ１０６は、ユーザとの前の対話に基づいて会話を知的に始動させる。ダイアログ・マネージャ１０６は、それが会話における次のターンに対するフォーカスをセットするけれども、その特定のタスク又はサブタスクにユーザを強制しない。
【００６２】
ダイアログ・マネージャ１０６のもう１つの特徴は、それがイベント駆動されるということである。即ち、ダイアログ・マネージャ１０６は、対話マネージャ１２４とコミュニケーションを行い、ＤＯＭイベントを介してアプリケーション・サーバ１０８及びそれのアプリケーション・バックエンド（ビジネス・ロジック）１１０とコミュニケーションを行う。対話マネージャ１２４及びダイアログ・マネージャ１０６の両方とも、アプリケーションのＤＯＭベースのツリー表示を維持する。ＤＯＭイベントは、ダイアログ・マネージャ１０６及び対話マネージャ１２４の間におけるツリーの変更をコミュニケートするために使用される。
【００６３】
アプリケーション・バックエンド１１０に従って、アプリケーション特有の情報がアプリケーション・サーバ１０８によって記憶及び解釈される。ダイアログ・マネージャ１０６及びアプリケーションの間のコミュニケーションもＤＯＭイベントを通して行われ、対話マネージャ１２４を介して経路指定される。そのような交換は、以下で説明されるように、正規化リクエスト及び明確化リクエストを含む。
【００６４】
ＧＵＩブラウザ１１８及びボイス・ブラウザ１２０は、入出力機能を提供する。即ち、それらは、ユーザが対話し得るプレゼンテーションをレンダする。対話マネージャ１２４は、ＧＵＩブラウザ１１８及びボイス・ブラウザ１２０の間の出力のレンダリングを同期化し、対話ロジック層の状態、即ち、対話の状態及びユーザにより操作されるデータ・モデルの状態を維持する。更に、対話マネージャ１２４は、ＸＨＴＭＬ又はＶoiceＸＭＬのような適切なモダリティにおけるＩＭＬアプリケーションをレンダするために必要なコード変換を遂行し、或いはダイアログ・マネージャ１０６によって決定され、コミュニケートされたフォーカスに従ってデータ・モデルに既にバインドされているプレゼンテーションを選択する。更に、対話マネージャ１２４は、ダイアログ・マネージャ１０６とアプリケーション・サーバ１０８に関連し且つデータベースを越えたアプリケーション・ビジネス・ロジック１１０との間のコミュニケーション・チャネルとしても働く。
【００６５】
ＡＳＲエンジン１１２は、ユーザからの入力受け取り、それを、後述のように、ＶoiceＸＭＬスニペットにおいて指定されたそれの音声データ・ファイル（音響モデル、ベースフォーム、文法、又は言語モデル）に依存したストリング（又は、テキスト）に転写する。特に、望ましい実施例では、ＡＳＲエンジン１１２は、入力（音声認識の結果）の転写を生じさせるために確率的文法（stochastic grammar）（言語モデル）に依存する。ＡＳＲ結果が付加的メタ情報（スコア、Ｎベスト・リスト等）でもって注釈される。もう１つの実施例では、音声認識の結果が、自然言語セマンティクス・マークアップ言語（Natural Language Semantics Markup Language - ＮＬＳＭＬ）において交換され得る。
【００６６】
次に、その認識されたテキストは、ＮＬデータ・モデルに基づいてその結果を呼び出しそしてタグ付けするＮＬＵパーサ１１６に送られる。このテクノロジの例が、Proc. Eurospeech, 1999 誌における K. A. Papineni 氏による「フォームを使用したフリー・フロー・ダイアログ管理（Free-flow Dialog Management Using Forms）」と題した論文、及び Proc. Eurospeech, Budapest, 1999 誌における K. Davies 氏他による「金融アプリケーションのためのＩＢＭ会話型電話システム（The IBM Conversational Telephony System for Financial Applications）」と題した論文において検討されている。
【００６７】
同様に、ボイス・プロンプトがユーザに与えられるとき、これは後述のＶoiceＸＭＬスニペットを通して行われる。スニペットは、どのようなプロンプトを実施すべきか及びどのようにしてそれを獲得すべきか規定する。スニペットは、事前記録されたプロンプトを指示するか、又は、ＴＴＳエンジン１１４を介して合成されるべきテキストを提供し得る。テキストは、音声合成（Speech Synthesis）マークアップ言語、即ち、ＳＳＭＬでもって記述可能である。ＮＬＳＭＬ及びＳＳＭＬは、Ｗ３Ｃウェブ・サイトにおいて記述される。ボイス・ブラウザは、プロンプトをフェッチして実行し、ユーザに対して再生すべき音声を発生するようＴＴＳエンジンを制御する。。
【００６８】
ボイス・ブラウザは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、エンジン１１２、１１４、及び１１６を制御する。エンジンが分散されるとき、ＡＰＩは、例えば、１９９８年１０月２日に出願された出願番号第６０/１０２,９５７号及び１９９９年１月２７日に出願された出願番号第６０/１１７,５９５号として識別される米国仮特許出願に対する優先権を主張して１９９９年１０月１日に出願されたＰＣＴ出願ＵＳ９９/２２９２５号に基づいた米国国内出願である、２００１年６月２５日に出願された出願番号第０９/８０６,４２５号として識別される米国特許出願において開示されているような遠隔制御プロトコルによって搬送され得る。
【００６９】
別のエンジンを、（例えば、話者認識に）関連付けることが可能であり、同じメカニズムが、入力又は出力（モダリティの特殊性、例えば、ビデオ処理又は手書きに適応した）を処理するためのエンジンを結果として生じる他のモダリティに対して使用可能である。ボイス・プロンプトを発生するために使用されるテキストは、一旦ダイアログ・マネージャがフォーカスを決定すると、アプリケーションによって単に指定される代わりに、コンテキスト、フォーカス、及びアプリケーションから自動的に発生可能である。そのような場合、ユーザに伝えるべき情報が、注釈可能である属性値ペアとして表示される。これらは、ＮＬＳＭＬにおいて表される交換、及び、その後、ＮＬＧ（自然言語生成 - Natural Language Generation）テクノロジを介して自然人のセンテンス又はセンテンス・セットの形にアセンブルされる交換の例でもある。
【００７０】
ＮＬＵ ＡＶペア・エクストラクタ（pair extractor）１２２は、音声入力の要素を構文解析し、それを、特定のターゲット・アプリケーション用に設計され且つデータ・モデル及びダイアログ・マネージャ１０６によって理解される属性値（ＡＶ）ペアに分類する。分類及び構文解析は、統計的クラッサ（classer）及び構文解析モデルに依存する。自然言語セマンティクス・マークアップ言語（ＮＬＳＭＬ）は、注釈されることがあり得る属性値ペアを交換するためのフォーマットとして使用可能である。
【００７１】
（ii）ＶoiceＸＭＬスニペット
本発明によれば、アプリケーションと関連したＩＭＬ制作されたアプリケーション全体（又は、その一部分）を、ボイス・ブラウザ１２０に従ってレンダするためのＶoiceＸＭＬにコード変換するのではなく、ＶoiceＸＭＬのスニペットだけが生成又は選択される。「スニペット」は、ユーザからの入力を集めるための入力フィールドをユーザに提供するためのプロンプト、及び完成したフォームを対話マネージャ１２４にサブミットするためのサブミット命令を含む。そのプロンプトは、それが事前記録されたプロンプトをプレーバックすべきか又はテキストを合成すべきか、及び、この場合には、それを行うためのＶoiceＸＭＬ命令を提供すべきかどうかを記述する。入力フィールドは、ＡＳＲを制御するように、音声入力を転記するように、及びそれをＮＬパーサに送るように、ＶoiceＸＭＬ命令と関連付けられる。これは、使用すべきＮＬパーサ・データ・ファイルを指定するＮＬ文法タグでもってＶoiceＸＭＬを拡張することによって行われる。それは、ＮＬパーサをいつも関連付けるようにＶoiceＸＭＬ実行時間を修正することによっても行われ得る。このメカニズムは、ＶoiceＸＭＬフォーム解釈アルゴリズムの制約を回避させ、それを行うためのＶoiceＸＭＬフォーム解釈アルゴリズムに依存する代わりに、対話マネージャ／ダイアログ・マネージャにアプリケーション及び次のダイアログのフォーカスを決定させる。
【００７２】
従って、対話マネージャ１２４は、次のプロンプト、よく普及した文法（例えば、言語モデル、即ち、統計的文法、又は範囲を抑制するために異なる文法に基づいて形成された文法）による入力フィールド、及びサブミット命令のみを含むＶoiceＸＭＬスニペットを生成又は選択する。対話マネージャ１２４は、プロンプト及び入力の緻密な制御を行う。ＶoiceＸＭＬスニペットの使用に関しては更に後述することにする。
【００７３】
この方法では、ボイス・ブラウザは、エンジン及びオーディオ入出力（Ｉ／Ｏ）に対するボイス・インターフェースである。しかし、ダイアログ管理は、一層後で抽象的に（しかも、恐らくモダリティに関係なく）行われる。再び、ＶoiceＸＭＬスニペットが、コード変換を通して生成可能であるか、又はＩＭＬドキュメントにバインドされた一組の事前コンパイルされた又は手操作で制作されたスニペットにおけるフォーカスに基づいて選択可能である。
【００７４】
別のモダリティでは、対話マネージャ１２４は、より大きなスニペット（即ち、フォーカスの下での直接的プロンプトよりも多くのジェスチャに対応する）を生成し得る。例えば、ＸＨＴＭＬでは、（他のフレームの上で又は他のフレーム内で）同時にアクティブになり得る種々のタスクのメニューを生成することは意味のあることであり、現在部分的に満たされたタスクが、決められたフォーカスに基づいて満たされることを期待されたプロンプト及び入力フィールド上にフォーカスと共に表示される。これは、これを行うための唯一の可能な方法である。本発明によって別の方法が考察される。
【００７５】
（iii）ＩＭＬアプリケーション及びＤＯＭ表示
前に説明したように、ＩＭＬは、アプリケーションを作成するデバイス独立型手段を提供する。対話マネージャ１２４は、適宜、ボイス・ブラウザ又はＧＵＩブラウザへの出力をコード変換し、レンダする。対話マネージャ１２４は、適応したプレゼンテーションと、対話ロジック層と、ビジネス・ロジック及びデータ層とのあいだの明瞭な分離も指定する。対話マネージャ１２４及びダイアログ・マネージャ１０６は、ユーザ対話のＤＯＭツリー表示及びユーザにより操作されたデータを維持する。
【００７６】
以下は、ＩＭＬによって表されたユーザ対話の簡単な例である。
<?xmlversion="1.0"encoding="ISO-8859-1"?>
<html name="travel"version="1.0"><head>
<model id="TravelDetails">
<trip>
<userInfo>
<name/>
</userInfo>
....more details
</trip>
</model></head><body>
<iml name="travel"version="1.0">
<iml:model-ref id="TravelDetails"src="travel_all.xml"/>
<iml:instance name="trip"type="TravelDetails"/>
<iml:instraction node_id="I1"...>
<iml:dialog node_id="D1"name="trip/userinfo"...>
<iml:message node_id="M1">
Welcome to our flight information system.
<iml:/message>
<iml:input name="name">
<iml:caption node_id="C0">
Please enter your name
</iml:caption>
</iml:input>
</iml:dialog>
</iml:interaction>
</body></html>
【００７７】
ユーザ対話から集められたデータは、ＸＨＴＭＬコンテナのヘッダにおけるデータ・モデルに記憶される。ユーザ対話ＤＯＭ及びデータ・モデルＤＯＭの間のバインディングは実行時に行われる。
【００７８】
次に、図２を参照すると、上記のサンプルＩＭＬコードに対する例示的な対話及びデータ・モデルＤＯＭツリー表示が示される。図示のように、対話ＤＯＭツリー表示２０２は、バインディング２０６を介してデータ・モデルＤＯＭ表示２０４にバインドされる。
【００７９】
（iv）イベント始動フォーム・ベースのダイアログ・マネージャ
ダイアログ・マネージャ１０６のタスクは、知的態様でユーザとの対話を始動させることである。ダイアログ・マネージャ１０６は、ターン毎にユーザの意図をモデル化し、ユーザがタスクを遂行するのを援助する。
【００８０】
ダイアログ・マネージャ１０４の主要な機能の１つは、ユーザ入力を適切なフォーム及びスロットと照合する（即ち、入力のフォーカスを決定する）ことである。会話型ブラウザ１０４が受け取ったユーザ入力は、ＮＬＵ属性値（ＡＶ）ペア・エクストラクタ１２２によって構文解析され、ユーザの発言から収集された（恐らく、他の収集された又は推定された情報でもって注釈された）セマンティック情報を含む属性値ペアを生成する。エクストラクタ１２２からの属性値ペアは、対話マネージャ１２４によって受け取られ、ダイアログ・マネージャ１０６にイベントとして送られる。ダイアログ・マネージャ１０６は、これらの属性値ペアを、「パーサ・イベント」のような会話型ブラウザ１０４からの入力として受け付ける。
【００８１】
ダイアログ・マネージャ１０６は、各フォームに対して各属性値ペアを評価（score）し、トップ・スコアリング・フォームを決定する。１つの例として、上記の K. Papineni 氏の論文において開示されているスコアリング・アルゴリズムに基づいてスコアリングが決定可能である。一般に、デフォルトの汎用アルゴリズムは、ダイアログ・マネージャによって提供される。しかし、各フォームは、新たなアルゴリズム又はそのアルゴリズムに対する新たなパラメータを指すことができる。例えば、これは、スコアリング・アルゴリズムに対するｊａｖａクラス及び（又は）ＸＭＬ引数を指すことによって行うことができる。望ましい実施例では、ダイアログ・マネージャがそのような「プラグ・イン」をサポートし、アプリケーションがデフォルト・アルゴリズム以外のスコアリング・アルゴリズムに対するポインタを各ダイアログ・フォームに関連づけることができ、或いは他のパラメータ設定を指す／含むことができる。
【００８２】
ダイアログ・マネージャ１０６は、属性値ペアからの値をトップ・スコアリング・フォームの適切なスロットに供給する。ダイアログ・マネージャ１０６は、スロットの値の変化に関する情報を、結果としてデータ・モデルの更新を生じさせる「スロット・ミューテーション・イベント（slot mutation event）」として対話マネージャ１２４に伝送する。
【００８３】
ダイアログ・マネージャ１０６のもう１つの重要な機能は、フォーカス決定（次の出力（前の説明は最後の入力に対するフォーカスに関するものであった）に対する）であり、或いはユーザとの会話を知的に始動させるために会話における次のターンを指定することである。ユーザとの前の対話に基づいて、ダイアログ・マネージャ１０６は、会話のフォーカスがどこにあるべきかを決定する。ユーザがタスクを完了するために更なる情報に対してプロンプト指示されなければならないこと、ユーザがタスク相互間で切り替えを行ったこと、従って、ユーザ対話が進行すること、又はユーザ入力の明確化、訂正、又は確認が必要であることがあり得ることである。ダイアログ・マネージャ１０６は、フォーカスがユーザ対話ではどこにあるべきかを決定し、「フォーカス・イベント」においてこの情報を対話マネージャに送る。再び、これは、ダイアログ・マネージャ・アルゴリズムによって指定されそして上書きされ得るデフォルト・アルゴリズムに基づく。後で説明するように、フォーカスは、アプリケーションによる明確化から生じる新たなサブ・ダイアログを指すことがある（明確化は、ＩＭＬアプリケーション、恐らく、データ・モデルを更新し、新たなサブ・ダイアログにおけるフォーカスをダイアログ・マネージャに供給する）。
【００８４】
望ましくは、ダイアログ・マネージャ１０６自体は、アプリケーション特有の知識を含んでいない。不明確な情報の明確化を含むアプリケーション特有の知識及び入力を明確化する（disambiguate）という判断は、アプリケーション・サーバ１０８に従って実行されるアプリケーション・ビジネス・ロジックの責任である。アプリケーション開発者は、「ジェスチャの正規化（canonicalize gesture）」を入力ジェスチャと関連付けることによってユ−ザ入力が明確化されなければならないかどうかを指定する。「ジェスチャの正規化」の存在は、データが標準的な明確なフォーマットにレンダされることをアプリケーション開発者が望んでいるということを表す。
【００８５】
ダイアログ・マネージャ１０６がユーザ入力を属性値ペアの形で受けたとき、ダイアログ・マネージャ１０６は、入力が明確化されるべきであることを対話が指定するかどうかをチェックする。それが肯定される場合、ダイアログ・マネージャ１０６は、その情報を「正規化イベント」の形で対話マネージャ１２４に送る。対話マネージャ１２４は、正規化リクエストをアプリケーション・ビジネス・ロジックに送り、明確化の結果を「正規化応答イベント」としてアプリケーションからダイアログ・マネージャ１０６に送る。ダイアログ・マネージャ１０６は、この情報を使用して、ユーザ入力が有効であるかどうか、又は更なる明確化が必要とされ、従って、フォーカスをシフトするかどうかを決定する。
【００８６】
タスクを完成するために必要なすべてのスロットが満たされたことをダイアログ・マネージャ１０６が決定するとき、ダイアログ・マネージャ１０６は、「バックエンド・サブミット・イベント」を介して対話マネージャ１２４にこれを表示する。バックエンド・リクエストの結果が、「バックエンド・サブミット応答イベント」として対話マネージャ１２４によりダイアログ・マネージャ１０６に返送される。バックエンド・リクエストが成功裏に完了する場合、ダイアログ・マネージャ１０６は、完了時にフォームにマークを付し、次のリクエストに進む。バックエンド・リクエストが失敗した場合、ダイアログ・マネージャ１０６は、エラーを処理するための対話ノード、例えば、エラー訂正ダイアログが設けられているＩＭＬユーザ・インターフェースＤＯＭにおけるノードにフォーカスをシフトする。
【００８７】
属性値ペアのリストを考察すると、その入力に最も適したフォームを決定するために、ダイアログ・マネージャ１０６が簡単なスコアリング・ストラテジを適用する。ダイアログ・マネージャ１０６は、照合した属性及びスロットの数、現在どのフォームがフォーカスを有するか、コンテキスト、及びヒストリ（長期及び短期）等を考慮する。ダイアログ・マネージャ１０６は、アプリケーション特有のスコアリング・ストラテジ及びプラグ・インされ得る新たなスコアリング・ストラテジを可能にするように設計される。ダイアログ・マネージャ１０６は、複数の独立して開発されたアプリケーションにわたってダイアログ管理も処理することができる。
【００８８】
部分的に満たされたデータ・モデル及び仮定（遅れたデータ・モデルの更新）を、知識ソースによる妥当性検査（例えば、遅い出発日に関連するトランザクションが早い場合に帰国日が妥当であるか。特定のトランザクション・タイプが存在するか）のために属性値ペアとして提示することによって、知識ソースによる明確化が達成可能である。
【００８９】
ダイアログ管理は、利用可能ないずれの情報にも依存する。属性値ペアに関する更なる情報（例えば、機密レベル、値のＮベスト・レベル、別の属性等）が有益となり得る。
【００９０】
本発明のデータ・モデルでは、ダイアログ・マネージャの単一の（又は、複数の）デフォルトであってもよく、或いはプラグ・イン・ダイアログ・マネージャ・ストラテジを指すフォームによって明確に表示されてもよい。これは、デフォルト・ストラテジ（又は、デフォルト・ストラテジの１つ）の、或いは相互に関する単なるパラメータ化であってもよい。パラメータ化は、ＸＭＬにおいて行宇ことが可能である。これを処理するために（例えば、ｊａｖａで）作成されたフォーム特有のプラグ・イン及びアプリケーション特有のプラグ・インを指すことによっても、スクリプト又は他のストラテジが無条件に導入可能である。本発明は、２パス・スコアリング・ストラテジを使用し得る。第１のパスでは、解釈された入力を使用し得るダイアログが決定される。第１のパス中に複数のダイアログが選択される場合、それらの間のアービトレーションが第２のパスにおいて行われる。本発明は、正規化／明確化のためのアプリケーション・サーブレット（例えば、図１におけるアプリケーション・サーバ１０８）とのコミュニケーションを行うための正規化サービスを提供する。ダイアログ・マネージャは、アプリケーション・サーブレットが独特の正規化された値、失敗の表示、サブ・ダイアログ又はデータ・モデル更新のいずれかを戻すようにそのアプリケーション・サーブレットに期待するであろう。
【００９１】
サブ・ダイアログは、オリジナル・アプリケーションに存在するか、又は現在のダイアログ状態が不明確であって更なる詳細、確認、又は修正を必要とすることが判明するとき、フォーカスを有するそのアプリケーションに対する更新として、ウェブ・アプリケーション・サーバによって戻される。
【００９２】
上述のように、アプリケーションはＩＭＬにおいて作成され、しかも一連の対話及びデータ・モデルから成る。サーブレットは、正規化／明確化機構を提供する。明確化を目的としたサブ・ダイアログの動的生成は次のように働く。即ち、サーブレットは、それが受け取った入力を正規化しようとするであろうが、それを行うことができなった場合、入力を明瞭にするためのサブ・ダイアログを生成するであろう。そのサブ・ダイアログがユーザ入力を受け取るとき、それは、正規化（再正規化）のためにそのサブ・ダイアログを作成したサーブレットを呼び出すであろう。正規化された入力は、ダイアログ・マネージャに戻されるであろう。
【００９３】
例：
（１）ユーザ：「私は、スプリングフィールド（Springfield）に行きたい」
（２）ダイアログ・マネージャ１０６が（arrivalCity, Springfield）に関する正規化を要求する。
（３）サーブレットは、複数のスプリングフィールドが存在することを決定し、「あなたの云うスプリングフィールドは、マサチューセッツ州のスプリングフィールドか、或いはイリノイ州のスプリングフィールドか」を尋ねるサブ・ダイアログを生成する。そのサブ・ダイアログは、「イリノイ」、「マサチューセッツ」又は「２番目のもの」のようなユーザ応答を受け付けるであろう。
（４）サブ・ダイアログは、（arrivalCity, Springfield-Mass）をサーブレットに返送するであろう。
（５）サーブレットは、（arrivalCity, Springfield-Mass）をうまく正規化し、その正規化された値をダイアログ・マネージャ（又は、経路指定方法次第で対話マネージャ）に戻すであろう。
【００９４】
サブ・ダイアログは、拘束のない入力を受けることができ、従って、それは、（arrivalCity,Springfield-Garbage）をサーブレットに送ることができる。そこで、サーブレットは正規化が失敗したことを決定し、従って、ダイアログ・マネージャに応答するであろう。
【００９５】
（v）対話マネージャ及びダイアログ・マネージャの間の対話
上述のように、ダイアログ・マネージャ１０６は、ＤＯＭイベントを介して対話マネージャ１２４とのコミュニケーションを行う。本願において説明されたＩＭＬ作成技法と整合して、アプリケーションは、一連のユーザ対話及び１つのデータ・モデルを含む。対話マネージャ１２４及びダイアログ・マネージャ１０６の両方とも、ユーザ対話のＤＯＭツリー表示及びデータを維持する。
【００９６】
ダイアログ・マネージャ１０６は、次のようなイベントを対話マネージャ１２４に送る。
（１）フォーカス・イベント（対話における次のステップを対話マネージャ１２４に知らせるため）；
（２）スロット・ミューテーション・イベント（データ・モデル変数の変更を対話マネージャ１２４に知らせるため）；
（３）正規化イベント（対話マネージャ１２４を介したアプリケーションへの明確化リクエスト）、バックエンド・サブミット・イベント（アプリケーション状態及び対話を更新するために、特定のインスタンス又はフォームがアプリケーション・サーバ１０８に送られなければならないことを対話マネージャ１２４に表示するため）。
バックエンド・サブミット・イベントは、一般的なＨＴＴＰページ・サブミットに対応する。バックエンド・サブミット・イベントは、会話型ブラウザが常駐する同じシステム上のローカル・ビジネス・ロジックへのものであることは明らかである。
【００９７】
ダイアログ・マネージャ１０６は、次のようなイベントに対するイベント・リスナとして対話ツリーにおいて登録される。
（１）ユーザ入力から取り出された属性値ペアを含むパーサ・イベント；
（２）ユーザ入力の明確化の結果を含む正規化応答イベント；
（３）バックエンド・リクエストが成功裏に完了したか否かを表すバックエンド・サブミット・イベント；
（４）フォーカスがユーザによりＧＵＩブラウザ１１８を介して明瞭にセットされたかどうかを表すＧＵＩフォーカス・イベント；
（５）対話マネージャ１２４がＧＵＩブラウザ１１８から受け取った更新されたデータ・モデル値を含むＧＵＩブラウザ１１８からのスロット・ミューテーション・イベント。
【００９８】
従って、上記の説明から明らかなように、ダイアログ・システム１００におけるアプリケーション・サーバ１０８、ダイアログ・マネージャ１０６、及び対話マネージャ１２４の間の交換は、これらのイベントのシーケンスを含む。しかし、本発明は、イベントのシーケンスを介したコミュニケーションに限定されない。
【００９９】
同様の前のリクエストから引き継がれた新たなリクエスト（例えば、航空機旅行の予約における帰りの足）に関する情報を、ダイアログ（フォーム）の再使用によってユーザに提供されることを可能にすることが可能であることにも注意してほしい。これは、データ・モデル及びＩＭＬ対話ジェスチャのインデキシングを可能にすることによって、並びに、フォーム及びデータ・モデルの２つ又は多数のバージョンの継承及び管理がどのように扱われるべきかを指定する関連の「プラグ・イン」における情報をそのフォームに加えることによって行うことが可能である。
【０１００】
図４乃至図６に関連して本発明によるダイアログ・システムのコンポーネントと関連したイベント交換の例を説明する前に、初期オペレーション・フローを示す流れ図が図３において与えられる。
【０１０１】
次に図３を参照すると、本発明の実施例に従って、ダイアログ・システムと関連した初期オペレーションの全体的なフロー３００を表す流れ図が示される。
【０１０２】
先ず、ステップ３０２において、ユーザがトランザクションを開始する（例えば、コンテンツ・サーバと関連したアプリケーションへのアクセスをリクエストする）。ユーザによって開始されたトランザクションの結果、ステップ３０４において適切なアプリケーション（ＩＭＬコード）が対話マネージャ１２４にロードされる。ダイアログ・システム１００が実行しているアプリケーションに依存した種々の方法で、ユーザ・リクエストが生成可能であることは明らかである。リクエストを開始し得る方法に関する幾つかの例は、次のようなものである。
【０１０３】
ダイアログ・システムによって実行される電話タイプのアプリケーションでは、ユーザが連絡を取ろうとしているパーティの電話番号を調べることを専用化されるアプリケーションがある。例えば、これは、ＩＶＲ（対話式音声応答 - Interactive Voice Response）アプリケーション又はボイス・ポータル（voice portal）型アプリケーションの「ウェルカム」メニューの場合である。これらの場合、ダイアログ・システムがインスタンス化されるとき、又はダイアログ・システムが電話ポートを割り当てられるとき、適切なＩＭＬアプリケーションが対話マネージャ１２４にロードされる。
【０１０４】
ボイス・ポータルを含む更に一般的な場合、ＧＵＩ及び（又は）ボイス・ブラウザが先ずインスタンス化され、ＧＵＩブラウザ又はボイス・ブラウザ内で、ユーザが会話型アプリケーションに対する特定のＵＲＩを選択する。しかる後、関連のＩＭＬページが対話マネージャ１２４にロードされる。
【０１０５】
更に、ユーザに対してＧＵＩブラウザ又はボイス・ブラウザしか存在しないこと、及び対話マネージャに対するインスタンス化及び接続がＵＲＬを介したアプリケーションの選択に起因することがユーザ・トランザクションの開始時には起こり得る。場合によっては、ユーザによって使用され又はアクセスされたデバイスにおけるショートカット／アプリケーションにも起因することがある。
【０１０６】
いずれの場合も、ステップ３０６において、ＩＭＬアプリケーションが対話マネージャ１２４によって、データ・モデル及びそのデータ・モデルにバインドされたユーザ・インターフェース（ＵＩ）プレゼンテーション（又は、上述したような「対話」）の形に構文解析される。ステップ３０８において、データ・モデル及びＵＩプレゼンテーションのそれぞれのＤＯＭ（ドキュメント・オブジェクト・モデル）ベースの表示が生成される。ＤＯＭベースの表示は、ツリー・フォーマット（例えば、図２）におけるものであることが望ましい。ＵＩプレゼンテーションのＤＯＭベースの表示は、最終的なターゲット・フォームにおいてレンダするその後のプレゼンテーションのための抽象的フォームのものであってもよく、或いは、データ・モデル、例えば、ＸＨＴＭＬ（拡張可能ＨＴＭＬ）、ＨＴＭＬ-Ｍobile、ＷＭＬ（ワイヤレス・マークアップ言語）、ＶoiceＸＭＬ、ＸＨＴＭＬ+Ｖoice 等にバインドされた最終的なターゲット・フォームにおけるプレゼンテーションであってもよい。
【０１０７】
ステップ３１０において、対話マネージャ１２４は、本願において説明されたように、データ・モデルのＤＯＭ表示の複製を、それに従って使用するために、ダイアログ・マネージャ１０６に送る。対話マネージャ及びダイアログ・マネージャが共通のコンポーネントとして実装される実施例では、それらは同じＤＯＭ表示を共用し得る。
【０１０８】
ステップ３１２において、初期フォーカスに基づき、各モダリティに対するプレゼンテーション（最終的レンダリング）が生成される。即ち、リクエストされた或る部分がＧＵＩブラウザ１１８及び（又は）ボイス・ブラウザ１２０を介してユーザに供給される。
【０１０９】
図４乃至図６を参照すると、本発明の実施例に従って、ダイアログ・システムにおけるイベントの交換を表す流れ図が示される。
【０１１０】
ステップ４０２において、対話マネージャ１２４がダイアログ・マネージャ１０６にパーサ・イベントを送る。パーサ・イベントは、ユーザの発言のセマンティック表示からＮＬＵエクストラクタ１２２によって生成された属性値ペアを含む。ステップ４０４において、ダイアログ・マネージャ１０６は、この情報を使用して適切なスロットを満たす。
【０１１１】
ステップ４０６において、ダイアログ・マネージャ１０６は、入力に対して明確化が必要であることを決定する。ダイアログ・マネージャ１０６は、対話マネージャ１２４に正規化イベントを送る。ステップ４０８において、対話マネージャ１２４は、そのイベントをアプリケーション・サーバ１０８に伝播する。
【０１１２】
ステップ４１０において、アプリケーション・サーバ１０８は、対話マネージャ１２４がダイアログ・マネージャ１０６に伝送する正規化応答イベントによって応答する。明確化が失敗した場合、ダイアログ・マネージャ１０６は、ステップ４１２において、明確化メッセージを含むユーザ対話にフォーカスをシフトする。明確化が成功した場合、ステップ４１４において、ダイアログ・マネージャ１０６は、スロット値が有効であることを決定する。ダイアログ・マネージャ１０６は、ステップ４１６において、スロット・ミューテーション・イベントを対話マネージャ１２４に送り、次のエンプティ・スロットにフォーカスをシフトするフォーカス・イベントがそれに続く。
【０１１３】
明確化が成功したものと仮定すると、ステップ４１８において、ダイアログ・マネージャ１０６は、タスクを完了するために必要なすべてのスロットが満たされたことを決定する。しかる後、ステップ４２０において、ダイアログ・マネージャ１０６は、バックエンド・サブミット・イベントを対話マネージャ１２４に送る。
【０１１４】
ステップ４２２において、対話マネージャ１２４は、そのイベントをアプリケーション・サーバ１０８に送り、応答を待つ。アプリケーション・サーバ１０８は、ステップ４２４において、バックエンド・サブミット応答イベントでもって応答する。
【０１１５】
データベース・リクエストのようなバックエンド・リクエストが成功裏に完了した場合、ステップ４２６において、更新されたデータ・モデル・インスタンスが対話マネージャ１２４に返送される。そこで、対話マネージャ１２４は、ステップ４２８において、データ・モデル更新をダイアログ・マネージャ１０６に送る。しかる後、ステップ４３０において、ダイアログ・マネージャ１０６は、そのフォームを完全なものであるとしてマークを付し、次のフォームにフォーカス・シフトする。バックエンド・リクエストが失敗した場合、ステップ４３２において、ダイアログ・マネージャ１０６は、ユーザに問題点を警報するメッセージを含むユーザ対話にフォーカスをシフトするか或いはサブ・ダイアログをロードする。
【０１１６】
対話マネージャ１２４は、それがＧＵＩブラウザ１１８から受け取ったユーザ入力もダイアログ・マネージャ１０６に知らせる。ユーザ１０２がＧＵＩブラウザ１１８を介してフォーカスを明瞭にセットする場合、対話マネージャ１２４はＧＵＩフォーカス・イベントをダイアログ・マネージャ１０６に送る。ＧＵＩブラウザ１１８からのスロット更新に応答して、スロット・ミューテーション・イベントが対話マネージャ１２４によってダイアログ・マネージャ１０６に送られる。これは、ダイアログ・マネージャ１０６がそれの状態を対話マネージャ１２４と同期化することを可能にする。
【０１１７】
次に図７を参照すると、本願において図示され且つ詳細に説明されたダイアログ・システムの種々の機能的コンポーネントを実装するに適したコンピュータ・システムの汎用ハードウェア・アーキテクチャを表すブロック図が示される。例えば、図１に示されるようなダイアログ・システムの個々のコンポーネントが、例えば、会話型ブラウザ１０４、ＡＳＲエンジン１１２、ＴＴＳエンジン１１４、及びＮＬＵエンジン１１６が図５のアーキテクチャを有する１つ又は複数のクライアント装置において実装され、アプリケーション・サーバ１０８及び関連のバックエンド１１０が、図７のアーキテクチャを有する１つ又は複数のサーバ・システムにおいて実装されるというような１つのコンピュータ・システム、望ましくは、複数のそのようなコンピュータ・システムにおいて実装可能であることは明らかである。
【０１１８】
図示のように、コンピュータ・システムは、プロセッサ５０２、メモリ５０４、及びＩ／Ｏ装置５０６に従って実装可能である。本願で使用される用語「プロセッサ」が、例えば、ＣＰＵ（中央処理装置）及び（又は）他の処理回路を含む装置のような任意の処理装置を含むように意図されていることは明らかである。本願で使用される用語「メモリ」は、例えば、ＲＡＭ、ＲＯＭ、固定メモリ装置（例えば、ハード・ドライブ）、取り外し可能メモリ装置（例えば、ディスケット）、フラッシュ・メモリ等のような、プロセッサ、即ち、ＣＰＵと関連したメモリを含むように意図される。更に、本願で使用される用語「入出力装置」又は「Ｉ／Ｏ装置」は、例えば、処理装置にデータを入力するための１つ又は複数のモダリティ特有の入力装置（例えば、カメラ、マイクロフォン、キーボード、マウス等）、及び（又は）処理装置と関連した結果を供給ための１つ又は複数のモダリティ特有の出力装置（例えば、スピーカ、ディスプレイ等）を含むように意図される。用語「プロセッサ」が複数の処理装置を対照とすること、及び処理装置と関連した種々の要素が他の処理装置によって共用可能であることも理解されるべきである。
【０１１９】
従って、本願において開示されるような本発明の方法を遂行するための命令又はコードを含むソフトウェア・コンポーネントは、１つ又は複数の関連のメモリ装置（例えば、ＲＯＭ、固定メモリ、又は取り外し可能メモリ）に記憶可能であり、利用される準備ができるとき、部分的に又は全体的に（例えば、ＲＡＭに）ロードされ、ＣＰＵによって実行可能である。
【０１２０】
本願における添付図面を参照して本発明の説明的な実施例を開示したけれども、本発明が実施例そのものに限定されないこと及び本発明の技術的範囲及び精神から逸脱することなく当業者により他の種々な変更及び修正が行われ得ることは明らかである。例えば、ＶoiceＸＭＬはフォームから外れても形成されるので、ＶoiceＸＭＬの発展したものを実装することが可能である。それは、ＶoiceＸＭＬが次の点でＩＭＬと見なされる場合である：
（１）その文法が、言語モデルをサポートするように及びＮＬパーサ＋ＡＶエクストラクタに依存するＮＬ文法をサポートするように拡張される；
（２）入力によって満たされたフィールドを選択し、次のフォーカスを決定するためのスコアリング／明確化アルゴリズムに対する参照を加える。
【０１２１】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１２２】
（１）ダイアログ・システムに従ってユーザによりアクセス可能なアプリケーションを生成する方法であって、
ユーザが行い得る前記ダイアログ・システムとの対話を、データ・モデルとして、及び該データ・モデルのアプリケーション状態を移植し且つユーザが行い得る前記ダイアログ・システムとのダイアログが双方主導ダイアログであるように該データ・モデルにバインドされる１つ又は複数のユーザ対話素子として表示するステップを含み、
前記１つ又は複数のユーザ対話素子の少なくとも一部分は、ユーザに対して表示可能であり且つダイアログ・マネージャによって選択及び生成されるものである前記アプリケーションの１つ又は複数の形態特有のレンダリングに変形可能であり又は関連付け可能である、方法。
（２）前記表示するステップは宣言的に行われる、上記（１）に記載の方法。
（３）前記変形可能であるオペレーションは、コード変換することを含む、上記（１）に記載の方法。
（４）前記関連付け可能であるオペレーションは、プリコンパイルされたプレゼンテーション・スニペットを選択することを含む、上記（１）に記載の方法。
（５）前記関連付け可能であるオペレーションは、作成されたプレゼンテーションの使用を含む、上記（１）に記載の方法。
（６）前記アプリケーション状態は、前記ダイアログ・システムとのユーザの対話に従って１つ又は複数のユーザ対話素子により移植することが可能な１つ又は複数のスロットを有する少なくとも１つのフォームとして表される、上記（１）に記載の方法。
（７）前記アプリケーション状態の１つ又は複数のスロットの少なくとも１つは、前記ダイアログ・システムと関連した自然言語理解エンジンに従ってユーザ発言から抽出されたセマンティック上の意味に応答して移植可能である、上記（６）に記載の方法。
（８）前記１つ又は複数のスロットの移植は、前記双方主導ダイアログがユーザと前記ダイアログ・システムとの間で生じるようにユーザの意図を解釈するように作用する、上記（７）に記載の方法。
（９）前記１つ又は複数の形態特有のレンダリングは、前記アプリケーション部分の音声ベースの表示を含む、上記（１）に記載の方法。
（１０）前記音声ベースの表示は、ボイス拡張可能マークアップ言語（ＶoiceＸＭＬ）に基づいている、上記（９）に記載の方法。
（１１）ＶoiceＸＭＬは、ユーザ入力の自然言語理解及びその結果生じる属性値ペアの生成をサポートするように拡張される、上記（１０）に記載の方法。
（１２）ＶoiceＸＭＬの前記拡張は、言語モデル対するサポートを含む、上記（１１）に記載の方法。
（１３）ＶoiceＸＭＬは、音声データ・ファイルとして自然言語（ＮＬ）文法の導入を通して自然言語構文解析を指定するように拡張される、上記（１０）に記載の方法。
（１４）ＶoiceＸＭＬの前記拡張は、自然言語文法タグに対するサポートを含む、上記（１３）に記載の方法。
（１５）前記１つ又は複数の形態特有のレンダリングは、前記アプリケーションの部分の視覚ベースの表示を含む、上記（１）に記載の方法。
（１６）前記視覚ベースの表示は、グラフィカル・ユーザ・インターフェースのフレーム又は一部分においてメニュー及びフォーカスの下にあるアクティブ領域を含む、上記（１５）に記載の方法。
（１７）前記視覚ベースの表示は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張可能ＨＴＭＬ（ＸＨＴＭＬ）、及びＸＨＴＭＬモバイル・プロファイルの少なくとも１つに基づいている、上記（１５）に記載の方法。
（１８）前記１つ又は複数の形態特有のレンダリングは、拡張可能ハイパーテキスト・マークアップ言語-モバイル・プロファイル（ＸＨＴＭＬ-ＭＰ）、及びワイヤレス・マークアップ言語（ＷＭＬ）の少なくとも１つに基づいている、上記（１）に記載の方法。
（１９）前記１つ又は複数のユーザ対話素子は会話型ジェスチャを表示する、上記（１）に記載の方法。
（２０）前記宣言的に行われる表示は、拡張可能マークアップ言語（ＸＭＬ）に基づいている、上記（２）に記載の方法。
（２１）前記コード変換は、ＸＳＬ変換（ＸＳＬＴ）ルールに従って遂行される、上記（３）に記載の方法。
（２２）前記表示は、ユーザに対する前記アプリケーションの１つ又は複数のスニペットのプレゼンテーションをサポートし、
前記１つ又は複数のスニペットは、少なくともプロンプト及び入力フィールドを含み、
前記プロンプトは、ユーザに対して表示され、前記入力フィールドは、前記プロンプトに応答して受け取ることができるユーザ入力を指定する、
上記（１）に記載の方法。
（２３）前記１つ又は複数のスニペットは、更にサブミット命令を含む、上記（２２）に記載の方法。
（２４）前記１つ又は複数のスニペットは、１つ又は複数の音声拡張可能マークアップ言語（ＶoiceＸＭＬ）スニペットである、上記（２２）に記載の方法。
（２５）前記１つ又は複数のＶoiceＸＭＬスニペットは、ＶoiceＸＭＬフォーム解釈アルゴリズムによって課せられたダイアログ管理を回避する、上記（２３）に記載の方法。
（２６）前記表示は、関連のタイプ及びクロス・フィールド制約に加えて前記アプリケーション状態のモデル化を可能にする、上記（１）に記載の方法。
（２７）前記表示は、前記アプリケーション状態の連続的な維持及び更新を可能にする、上記（１）に記載の方法。
（２８）前記表示は、セマンティック上の意味を抽出するためにユーザ発言を自然言語理解（ＮＬＵ）エンジンに送ることを可能にする、上記（１）に記載の方法。
（２９）前記表示は、前記ユーザ発言の文脈的解釈を可能にするために、前記ＮＬＵエンジンによって戻された前記セマンティック上の意味と共に前記アプリケーション状態に存在する文脈上の知識を使用することを可能にする、上記（２８）に記載の方法。
（３０）前記表示は、前記文脈的解釈を使用してダイアログのどの部分が次に考察されるかを決定すること及び前記アプリケーション状態を更新することを可能にする、上記（２９）に記載の方法。
（３１）前記表示は、定義されたイベント及び該イベントに適切なイベント・ハンドラを付加することを可能にする、上記（１）に記載の方法。
（３２）前記アプリケーションの内部にあるナビゲーションの表示仕様は、それによって前記アプリケーション状態の１つ及び生成されたイベントの結果に基づいてフォーカス・シフトを生じさせる、上記（３１）に記載の方法。
（３３）前記定義されたイベントは、パーサ・イベント、正規化及び明確化の少なくとも１つに対するリクエスト、正規化及び明確化の少なくとも１つからの結果、更新イベント、及びコンテキストのサブミッションの少なくとも１つを含む、上記（３１）に記載の方法。
（３４）前記表示は、ユーザが前の同様のリクエストから継承した新たなリクエストに関する情報を提供することを可能にするためにダイアログの再使用を許容する、上記（１）に記載の方法。
（３５）前記１つ又は複数のユーザ対話素子は、前記アプリケーションと関連したコンテンツ及びプレゼンテーションとは無関係である、上記（１）に記載の方法。
（３６）前記表示は、ユーザ入力から属性値ペアを抽出することを許容する、上記（１）に記載の方法。
（３７）ユーザによるアプリケーションへのアクセスを提供するためのダイアログ・システムであって、
（ｉ）前記アプリケーションをアプリケーション・サーバから獲得するように動作可能であり、前記アプリケーションは、ユーザが行う前記ダイアログ・システムとのダイアログが双方主導ダイアログになるように、ユーザが有する前記ダイアログ・システムとの対話をデータ・モデル及び該データ・モデルのアプリケーション状態を移植する１つ又は複数のユーザ対話素子として表し、
（ii）前記１つ又は複数のユーザ対話素子の少なくとも一部分を、ダイアログ・マネージャ・アルゴリズムによって生成又は選択される１つ又は複数の形態特有のレンダリングに変換又は関連付けるように動作可能である、
１つ又は複数のプロセッサと、
前記１つ又は複数のプロセッサに動作関係に結合され、前記獲得するオペレーション、変換するオペレーション、及び関連付けるオペレーションの少なくとも１つと関連した結果の少なくとも一部分を記憶するためのメモリと、
を含む、ダイアログ・システム。
（３８）ユーザによるアプリケーションへのアクセスを提供するための会話型ブラウザ装置であって、
対話マネージャと、
前記対話マネージャに動作関係に結合され、ボイス・ベースのブラウザである少なくとも１つの形態ベースのブラウザと、
前記対話マネージャに動作関係に結合されたダイアログ・マネージャと、
を含み、
ユーザ、前記対話マネージャ、前記ボイス・ベースのブラウザ、及び前記ダイアログ・マネージャの間の対話は、
（ｉ）前記対話マネージャがユーザ・リクエストに応答してサーバから前記アプリケーションを獲得し、前記アプリケーションの表示を前記ダイアログ・マネージャに送り、
（ii）前記ダイアログ・マネージャは、前記アプリケーションの表示に従って前記アプリケーションのフォーカス及び前記ユーザの意図の少なくとも１つを決定し、前記アプリケーションのフォーカス及び前記ユーザの意図の少なくとも１つを前記対話マネージャに通知し、
（iii）前記対話マネージャは、前記アプリケーションのフォーカス及び前記ユーザの意図の少なくとも１つに関する前記決定に基づいて前記ボイス・ベースのブラウザに従い前記ユーザにプレゼンテーションを行うための、前記アプリケーションにおいて少なくともプロンプト及び入力フィールドを含む特定の部分を指定し、
前記プロンプトは、前記ユーザに表示され、前記入力フィールドは、前記アプリケーションのフォーカス及び前記ユーザの意図の少なくとも１つを再決定する場合に使用するために前記プロンプトに応答して受け取り可能なユーザ入力を指定する、分散型ブラウザ装置。
（３９）前記対話マネージャは、前記アプリケーションをデータ・モデルに構文解析し、前記データ・モデルにバインドされた１つ又は複数のユーザ対話素子が少なくとも前記データ・モデルのドキュメント・オブジェクト・モデル（ＤＯＭ）表示を生成し、前記データ・モデルのＤＯＭ表示を前記ダイアログ・マネージャに送る、上記（３８）に記載の装置。
（４０）更に、前記アプリケーションのフォーカス及び前記ユーザの意図の少なくとも１つを決定する場合、前記ダイアログ・マネージャによる使用のために１つ又は複数のユーザ発言と関連したＡＶペアを抽出するための、ボイス・ベースのブラウザ及び前記対話マネージャの間に動作関係に結合された自然言語属性値（ＡＶ）ペア・エクストラクタを含む、上記（３８）に記載の装置。
（４１）前記指定された部分は、前記ユーザ入力の結果を前記対話マネージャにサブミットするためのサブミット命令を含む、上記（３８）に記載の装置。
（４２）前記指定された部分は、前記プロンプト及び前記ユーザ入力の少なくとも１つに従って遂行されるべき処理のタイプを特定する、上記（３８）に記載の装置。
（４３）前記遂行されるべき処理は、音声認識、音声合成、自然言語構文解析、及び属性値ペア抽出の少なくとも１つを含む、上記（４２）に記載の装置。
（４４）前記ボイス・ベースのブラウザは、前記プロンプト及び前記ユーザ入力の少なくとも１つに従って遂行されるべき処理に対するインターフェースとして働く、上記（４２）に記載の装置。
（４５）前記ダイアログ・マネージャは、前記ボイス・ベースのブラウザによって提供される前記処理に対するインターフェースとは別に抽象的に動作する、上記（４４）に記載の装置。
（４６）前記ダイアログ・マネージャは、形態に無関係に動作する、上記（３８）に記載の装置。
（４７）前記サーバは、それに供給されたオリジナル・ユーザ入力を明確化しようとし、それを行うのに失敗したとき、前記入力を明瞭にしようとするためのサブ・ダイアログを生成して、前記アプリケーションが、前記サブ・ダイアログに応答して前記ユーザから受け取った更なる入力に基づいて前記オリジナル・ユーザ入力を明確化するために再試行できるようにする、上記（３８）に記載の装置。
（４８）前記明確化されたユーザ入力は、前記ダイアログ・マネージャに提供される、上記（４７）に記載の装置。
（４９）前記指定された部分は、音声拡張可能マークアップ言語（ＶoiceＸＭＬ）スニペットである、上記（３８）に記載の装置。
（５０）拡張可能ハイパーテキスト・マークアップ言語（ＸＨＴＭＬ）フレームにおいて又は前記アプリケーションのページの部分としてメニューが表示される、上記（３８）に記載の装置。
（５１）前記ボイス・ベースのブラウザは、音声拡張可能マークアップ言語（ＶoiceＸＭＬ）をサポートする、上記（３８）に記載の装置。
（５２）ＶoiceＸＭＬは、ユーザ入力の自然言語理解及びその結果生じる属性値ペアの生成をサポートするように拡張される、上記（５１）に記載の装置。
（５３）ＶoiceＸＭＬの前記拡張は、言語モデルに対するサポートを含む、上記（５２）に記載の装置。
（５４）ＶoiceＸＭＬは、自然言語（ＮＬ）文法の導入を介して自然言語構文解析を音声データ・ファイルとして指定するように拡張される、上記（５１）に記載の装置。
（５５）ＶoiceＸＭＬの前記拡張は、自然言語文法タグに対するサポートを含む、上記（５１）に記載の装置。
（５６）更に、少なくとも第２の形態を介して前記アプリケーションと対話する能力をユーザに提供するための、前記対話マネージャに動作関係に結合されたグラフィカル・ユーザ・インターフェース（ＧＵＩ）ベースのブラウザを含む、上記（３８）に記載の装置。
（５７）前記対話マネージャ、前記ダイアログ・マネージャ、及び前記アプリケーション・サーバの間のコミュニケーションはイベント・ベースである、上記（３８）に記載の装置。
（５８）前記イベントは、前記ダイアログ・マネージャが対話における次のステップを前記対話マネージャに知らせるフォーカス・イベントを含む、上記（５７）に記載の装置。
（５９）前記イベントは、前記ダイアログ・マネージャがデータ・モデルと関連した変化を前記対話マネージャに知らせるスロット・ミューテーション・イベントを含む、上記（５７）に記載の装置。
（６０）前記イベントは、前記アプリケーション・サーバによって正規化が遂行されることを前記ダイアログ・マネージャがリクエストする正規化イベントを含む、上記（５７）に記載の装置。
（６１）前記イベントは、前記アプリケーション・サーバによって明確化が遂行されることを前記ダイアログ・マネージャがリクエストする明確化イベントを含む、上記（５７）に記載の装置。
（６２）前記イベントは、特定のインスタンスが前記アプリケーションと関連したビジネス・ロジックに送られることを前記ダイアログ・マネージャが前記対話マネージャに表示するバックエンド・サブミット・イベントを含む、上記（５７）に記載の装置。
（６３）前記イベントは、ユーザ入力から抽出された属性値ペアを含むパーサ・イベントを含む、上記（５７）に記載の装置。
（６４）前記イベントは、ユーザ入力の正規化の結果を含む正規化応答イベントを含む、上記（５７）に記載の装置。
（６５）前記イベントは、バックエンド・リクエストが成功裏に完了したかどうかを表すバックエンド・サブミット応答イベントを含む、上記（５７）に記載の装置。
（６６）前記イベントは、フォーカスがグラフカル・ユーザ・インターフェース（ＧＵＩ）ブラウザを通してユーザにより明確にセットされたかどうかを表すグラフィカル・ユーザ・インターフェース・フォーカス・イベントを含む、上記（５７）に記載の装置。
（６７）前記イベントは、前記対話マネージャがグラフィカル・ユーザ・インターフェース（ＧＵＩ）ブラウザから受け取った１つ又は複数の更新されたデータ・モデル値を含むスロット・ミューテーション・イベントを含む、上記（５７）に記載の装置。
（６８）前記プロンプトは、自然言語生成（ＮＬＧ）技法を介して生成される、上記（３８）に記載の装置。
（６９）前記アプリケーションはフォームを含み、前記ダイアログ・マネージャは、各フォームに対してユーザ入力から生成された属性値ペアを記録してトップ・スコアリング・フォームを決定する、上記（３８）に記載の装置。
（７０）前記ダイアログ・マネージャによって使用されるスコアリング技法は、デフォルトの汎用スコアリング・アルゴリズムに基づいている、上記（６９）に記載の装置。
（７１）前記ダイアログ・マネージャによって使用されるスコアリング技法は、フォームによって指示されたスコアリング・アルゴリズムに基づいている、上記（６９）に記載の装置。
（７２）前記フォームは、前記スコアリング・アルゴリズムのための拡張可能マークアップ言語（ＸＭＬ）引数を指示する、上記（７１）に記載の装置。
（７３）前記フォームは、１つ又は複数のフォーム及び１つのデータ・モデルを創作又は再使用するために使用されるべきアルゴリズムを指定する、上記（６９）に記載の装置。
（７４）ユーザによるアプリケーションへのアクセスを提供するための会話型ブラウザ装置であって、
対話マネージャ機能と、
前記対話マネージャ機能に動作関係に結合された少なくとも１つの形態ベースのブラウザ機能と、
前記対話マネージャ機能に動作関係に結合されたダイアログ・マネージャ機能と、
を含み、
前記ユーザ、前記対話マネージャ、前記ブラウザ、及び前記ダイアログ・マネージャ機能の間の対話は、
（ｉ）前記対話マネージャがユーザ・リクエストに応答してサーバから前記アプリケーションを獲得し、前記アプリケーションは、前記ユーザが行う前記アプリケーションとの対話をデータ・モデルとして及び、前記データ・モデルのアプリケーション状態を移植し且つそれにバインドされる１つ又は複数のユーザ対話素子として表し、
（ii）前記ダイアログ・マネージャが、ユーザ入力から生成された属性値ペアを受け取り、該属性値ペアを処理して前記データ・モデルを移植し、次の対話フォーカスを決定し、
（iii）前記ダイアログ・マネージャによる次の対話フォーカスの決定の際、前記アプリケーション状態及びコンテキストが更新され、前記対話マネージャによって出力が生成され、対話のために前記ブラウザを介して前記ユーザに供給される
ことを含む、会話型ブラウザ装置。
（７５）前記次の対話フォーカスは、対話ヒストリ及びコンテキストの少なくとも一方を使用する、上記（７４）に記載の装置。
（７６）前記対話ヒストリ及びコンテキストの少なくとも一方は、入力及び出力属性値ペアの時間順序付けられたセット及びその結果生じるデータ・モデル変化を含む、上記（７４）に記載の装置。
（７７）前記属性値ペアは、種々の装置及び形態からのものである、上記（７６）に記載の装置。
（７８）前記ダイアログ・マネージャは、詳細、確認、並びに、前記ユーザ及び知識源の少なくとも一方からの訂正、の少なくとも１つを探索することによって意図を明確化するためにデータ・モデル更新を遅らせる、上記（７４）に記載の装置。
（７９）前記ダイアログ・マネージャは、サブ・ダイアログ及び前記アプリケーションにおける他のダイアログへのジャンプの少なくとも一方を使用する、上記（７８）に記載の装置。
（８０）前記知識源は、バックエンド・データベース及びビジネス・ロジックの少なくとも一方を含む、上記（７８）に記載の装置。
（８１）前記アプリケーションは宣言的に作成される、上記（７４）に記載の装置。
（８２）前記出力生成のオペレーションは、コード変換することを含む、上記（７４）に記載の装置。
（８３）前記出力生成のオペレーションは、プリコンパイルされたプレゼンテーション・スニペットを選択することを含む、上記（７４）に記載の装置。
（８４）前記出力生成のオペレーションは、手操作で作成されたプレゼンテーションの使用を含む、上記（７４）に記載の装置。
（８５）前記ブラウザは、ボイス・ベースのブラウザである、上記（７４）に記載の装置。
（８６）前記ブラウザは、ハイパーテキスト・マークアップ言語（ＨＴＴＰ）ベースのブラウザである、上記（７４）に記載の装置。
（８７）前記対話マネージャ、前記ダイアログ・マネージャ、及び前記アプリケーション・サーバの間のコミュニケーションは、イベント・ベースのものである、上記（７４）に記載の装置。
（８８）前記対話マネージャは、少なくとも前記データ・モデルのドキュメント・オブジェクト・モデル（ＤＯＭ）表記を生成する、上記（７４）に記載の装置。
（８９）前記ブラウザは、音声拡張可能マークアップ言語（ＶoiceＸＭＬ）をサポートする、上記（７４）に記載の装置。
（９０）ＶoiceＸＭＬは、ダイアログ管理アルゴリズムの仕様を可能にするように拡張される、上記（８９）に記載の装置。
（９１）前記ダイアログ管理アルゴリズムは、スコアリング、フォーカス決定、及び明確化の少なくとも１つを遂行する、上記（９０）に記載の装置。
（９２）前記ダイアログ管理アルゴリズムは、ＶoiceＸＭＬにおけるフォーム解釈アルゴリズムを上書きする、上記（９０）に記載の装置。
（９３）前記属性値ペアは注釈付けされる、上記（７４）に記載の装置。
（９４）前記機能は、前記属性値ペアを注釈付けするためのプロトコルをサポートする、上記（７４）に記載の装置。
（９５）会話型ブラウザに従ってユーザによりアクセス可能なアプリケーションを作成する方法であって、
前記会話型ブラウザの対話マネージャがユーザ・リクエストに応答してサーバから前記アプリケーションを獲得するステップにして、前記アプリケーションは、前記ユーザが行う前記アプリケーションとの対話を、データ・モデルとして及び、前記データ・モデルのアプリケーション状態を移植し且つそれにバインドされる１つ又は複数のユーザ対話素子として表示する、ステップと、
前記会話型ブラウザのダイアログ・マネージャが、ユーザ入力から生成された属性値ペアを受け取り、該属性値ペアを処理して前記データ・モデルを移植し、次の対話フォーカスを決定するステップと、
前記ダイアログ・マネージャによる次の対話フォーカスの決定の際、前記アプリケーション状態及びコンテキストが更新され、前記対話マネージャによって出力が生成され、対話のために前記会話型ブラウザのブラウジング機構を介して前記ユーザに提供されるステップと、
を含む方法。
（９６）１つ又は複数のプログラムを含むマシン可読媒体を含む製造物であって、
前記プログラムは、実行されるとき、前記ユーザが行うダイアログ・システムとの対話をデータ・モデルとして、及び、前記データ・モデルのアプリケーション状態を移植し且つそれにバインドされる１つ又は複数のユーザ対話素子として、前記ユーザが行う前記ダイアログ・システムとのダイアログが双方主導ダイアログであってもよいように表示するステップを実施し、
前記１つ又は複数のユーザ対話素子の少なくとも一部分は、前記ユーザに表示可能であり且つダイアログ・マネージャ・アルゴリズムによって生成される前記表示と関連した１つ又は複数の形態特有のレンダリングに変換又は関連付けられる、製造物。
【図面の簡単な説明】
【図１】 本発明の実施例に従ってＩＭＬアプリケーションをサポートすることができるダイアログ・システムを示すブロック図である。
【図２】 本発明の実施例に従って対話及びデータ・モデル・ドキュメント・オブジェクト・モデル・ツリー表示を示す図である。
【図３】 本発明の実施例に従ってダイアログ・システムと関連した初期オペレーションの全体的流れを示す流れ図である。
【図４】 本発明の実施例に従ってダイアログ・システムにおけるイベントの変更を示す流れ図の一部分である。
【図５】 本発明の実施例に従ってダイアログ・システムにおけるイベントの変更を示す流れ図の他の部分である。
【図６】 本発明の実施例に従ってダイアログ・システムにおけるイベントの変更を示す流れ図の更に他の部分である。
【図７】 本発明の実施例に従ってダイアログ・システムの種々の機能的コンポーネントを実装するに適したコンピュータ・システムの汎用ハードウェア・アーキテクチャを示すブロック図である。
【符号の説明】
１００ ダイアログ・システム
２０２ 対話ＤＯＭツリー表示
２０４ データ・モデルＤＯＭ表示
２０６ バインディング

Claims (32)

1. ダイアログ・システムに従ってユーザによりアクセス可能なアプリケーションを生成する方法であって、
   ユーザが行い得る前記ダイアログ・システムとの対話を、データ・モデル及び１つ又は複数のユーザ対話要素として宣言型プログラミングに従い表すステップであって、前記１つ又は複数のユーザ対話要素は該データ・モデルのアプリケーション状態を移植し且つ該データ・モデルにバインドされ、及び前記アプリケーションは前記データ・モデル及び１つ又は複数のユーザ対話要素を含み、前記１つ又は複数のユーザ対話要素は、プログラムされるアプリケーションに関連付けられた情報をアクセスするために使用される形態、装置及びブラウザに関係なく、ダイアログを特徴付ける１以上の基本的プログラミング・コンポーネントを含む、前記表すステップ、
   を含み、
   ユーザが行い得る前記ダイアログ・システムとの対話が双方主導ダイアログであるように、前記ユーザの意図が１つ又は複数のユーザ対話要素の解釈及びユーザ入力からのセマンティク上の意味の抽出から決定され、それによって前記アプリケーションからのナビゲーションが、非逐次的な態様で及び少なくとも部分的にユーザに推進されて実行されることができ、
   前記１つ又は複数のユーザ対話要素の少なくとも一部分は、ユーザに対して表示可能であり且つダイアログ・マネージャ・アルゴリズムによって選択及び生成されるものである前記アプリケーションの１つ又は複数のモダリティ特有のレンダリングに変形可能であり又は関連付け可能である、方法。
2. 前記変形することは、コード変換することを含む、請求項１に記載の方法。
3. 前記関連付けすることは、プリコンパイルされたプレゼンテーション・スニペットを選択することを含む、請求項１に記載の方法。
4. 前記関連付けすることは、作成されたプレゼンテーションを使用することを含む、請求項１に記載の方法。
5. 前記アプリケーション状態は、前記ダイアログ・システムとのユーザの対話に従って１つ又は複数のユーザ対話要素により移植することが可能な１つ又は複数のスロットを有する少なくとも１つのフォームとして表される、請求項１に記載の方法。
6. 前記アプリケーション状態の１つ又は複数のスロットの少なくとも１つは、前記ダイアログ・システムに関連付けられた自然言語理解エンジンに従ってユーザ発言から抽出されたセマンティック上の意味に応答して移植可能である、請求項５に記載の方法。
7. 前記１つ又は複数のスロットの移植は、前記双方主導ダイアログがユーザと前記ダイアログ・システムとの間で生じるようにユーザの意図を解釈するように作用する、請求項６に記載の方法。
8. 前記１つ又は複数のモダリティ特有のレンダリングは、前記アプリケーション部分の音声ベースの表示を含む、請求項１に記載の方法。
9. 前記音声ベースの表示は、ボイス拡張可能マークアップ言語（ＶoiceＸＭＬ）に基づいている、請求項８に記載の方法。
10. ＶoiceＸＭＬは、ユーザ入力の自然言語理解及びその結果生じる属性値ペアの生成をサポートするように拡張される、請求項９に記載の方法。
11. 前記１つ又は複数のモダリティ特有のレンダリングは、前記アプリケーションの部分の視覚ベースの表示を含む、請求項１に記載の方法。
12. 前記視覚ベースの表示は、グラフィカル・ユーザ・インターフェースのフレーム又は一部分においてメニュー及びフォーカスの下にあるアクティブ領域を含む、請求項１１に記載の方法。
13. 前記視覚ベースの表示は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張可能ＨＴＭＬ（ＸＨＴＭＬ）、及びＸＨＴＭＬモバイル・プロファイルの少なくとも１つに基づいている、請求項１１に記載の方法。
14. 前記コード変換は、ＸＳＬ変換（ＸＳＬＴ）ルールに従って遂行される、請求項２に記載の方法。
15. 前記表示は、ユーザに対する前記アプリケーションの１つ又は複数のスニペットのプレゼンテーションをサポートし、
    前記１つ又は複数のスニペットは、少なくともプロンプト及び入力フィールドを含み、
    前記プロンプトは、ユーザに対して表示され、前記入力フィールドは、前記プロンプトに応答して受け取ることができるユーザ入力を指定する、
    請求項１に記載の方法。
16. 前記１つ又は複数のスニペットは、サブミット命令を更に含む、請求項１５に記載の方法。
17. 前記１つ又は複数のスニペットは、１つ又は複数の音声拡張可能マークアップ言語（ＶoiceＸＭＬ）スニペットである、請求項１５に記載の方法。
18. 前記１つ又は複数のＶoiceＸＭＬスニペットは、ＶoiceＸＭＬフォーム解釈アルゴリズムによって課せられたダイアログ管理を回避する、請求項１６に記載の方法。
19. 前記表示は、関連のタイプ及びクロス・フィールド制約に加えて前記アプリケーション状態のモデル化を可能にする、請求項１に記載の方法。
20. 前記表示は、前記アプリケーション状態の連続的な維持及び更新を可能にする、請求項１に記載の方法。
21. 前記表示は、セマンティック上の意味を抽出するためにユーザ発言を自然言語理解（ＮＬＵ）エンジンに送ることを可能にする、請求項１に記載の方法。
22. 前記表示は、前記ユーザ発言の文脈的解釈を可能にするために、前記ＮＬＵエンジンによって戻された前記セマンティック上の意味と共に前記アプリケーション状態に存在する文脈上の知識を使用することを可能にする、請求項２１に記載の方法。
23. 前記表示は、前記文脈的解釈を使用して対話のどの部分が次に考察されるかを決定すること及び前記アプリケーション状態を更新することを可能にする、請求項２２に記載の方法。
24. 前記表示は、定義されたイベント及び該イベントに適切なイベント・ハンドラを付加することを可能にする、請求項１に記載の方法。
25. 前記アプリケーションの内部にあるナビゲーションの表示仕様は、それによって前記アプリケーション状態の１つ及び生成されたイベントの結果に基づいてフォーカス・シフトを生じさせる、請求項２４に記載の方法。
26. 前記定義されたイベントは、パーサ・イベント、正規化及び明確化の少なくとも１つに対するリクエスト、正規化及び明確化の少なくとも１つからの結果、更新イベント、及びコンテキストのサブミッションの少なくとも１つを含む、請求項２４に記載の方法。
27. 前記表示は、ユーザが前の同様のリクエストから継承した新たなリクエストに関する情報を提供することを可能にするために対話の再使用を許容する、請求項１に記載の方法。
28. 前記１つ又は複数のユーザ対話要素は、前記アプリケーションに関連付けられたコンテンツ及びプレゼンテーションとは無関係である、請求項１に記載の方法。
29. 前記表示は、ユーザ入力から属性値ペアを抽出することを許容する、請求項１に記載の方法。
30. ダイアログ・システムに従ってユーザによりアクセス可能なアプリケーションを生成するコンピュータ・プログラムであって、コンピュータに、
    ユーザが行い得る前記ダイアログ・システムとの対話を、データ・モデル及び１つ又は複数のユーザ対話要素として宣言型プログラミングに従い表すステップであって、前記１つ又は複数のユーザ対話要素は該データ・モデルのアプリケーション状態を移植し且つ該データ・モデルにバインドされ、及び前記アプリケーションは前記データ・モデル及び１つ又は複数のユーザ対話要素を含み、前記１つ又は複数のユーザ対話要素は、プログラムされるアプリケーションに関連付けられた情報をアクセスするために使用される形態、装置及びブラウザに関係なく、ダイアログを特徴付ける１以上の基本的プログラミング・コンポーネントを含む、前記表すステップ、
    を実行させ、
    ユーザが行い得る前記ダイアログ・システムとの対話が双方主導ダイアログであるように、前記ユーザの意図が１つ又は複数のユーザ対話要素の解釈及びユーザ入力からのセマンティク上の意味の抽出から決定され、それによって前記アプリケーションからのナビゲーションが、非逐次的な態様で及び少なくとも部分的にユーザに推進されて実行されることができ、
    前記１つ又は複数のユーザ対話要素の少なくとも一部分は、ユーザに対して表示可能であり且つダイアログ・マネージャ・アルゴリズムによって選択及び生成されるものである前記アプリケーションの１つ又は複数のモダリティ特有のレンダリングに変形可能であり又は関連付け可能である、コンピュータ・プログラム。
31. ユーザによりアプリケーションへのアクセスを提供するためのダイアログ・システムであって、
    １つ又は複数のプロセッサであって、（ｉ）前記１つ又は複数のプロセッサは前記アプリケーションをアプリケーション・サーバから獲得するように動作可能であり、前記アプリケーションは、ユーザが行い得る前記ダイアログ・システムとの対話を、データ・モデル及び１つ又は複数のユーザ対話要素として宣言型プログラミングに従い表し、ここで前記１つ又は複数のユーザ対話要素は該データ・モデルのアプリケーション状態を移植し且つ該データ・モデルにバインドされ、前記アプリケーションは前記データ・モデル及び１つ又は複数のユーザ対話要素を含み、前記１つ又は複数のユーザ対話要素は、プログラムされるアプリケーションに関連付けられた情報をアクセスするために使用される形態、装 置及びブラウザに関係なく、ダイアログを特徴付ける１以上の基本的プログラミング・コンポーネントを含み、そしてユーザが行い得る前記ダイアログ・システムとの対話が双方主導ダイアログであるように、前記ユーザの意図が１つ又は複数のユーザ対話要素の解釈及びユーザ入力からのセマンティク上の意味の抽出から決定され、それによって前記アプリケーションからのナビゲーションが、非逐次的な態様で及び少なくとも部分的にユーザに推進されて実行されることができ、及び（ii）前記１つ又は複数のユーザ対話要素の少なくとも一部分を、ダイアログ・マネージャ・アルゴリズムによって生成又は選択される１つ又は複数のモダリティ特有のレンダリングに変換又は関連付けるように動作可能である、前記１つ又は複数のプロセッサと、
    前記１つ又は複数のプロセッサに動作可能なように結合されたメモリであって、前記獲得すること、変換すること、及び関連付けることの少なくとも１つに関連付けられた結果の少なくとも一部分を記憶するためのメモリと、
    を含む、ダイアログ・システム。
32. ユーザによるアプリケーションへのアクセスを提供するための会話型ブラウザ装置であって、
    対話マネージャ機能と、
    前記対話マネージャ機能に動作可能なように結合された少なくとも１つのモダリティベースのブラウザ機能と、
    前記対話マネージャ機能に動作可能なように結合されたダイアログ・マネージャ機能と、
    を含み、
    前記ユーザ、前記対話マネージャ、前記ブラウザ、及び前記ダイアログ・マネージャ機能の間の対話は、
    （ｉ）前記対話マネージャがユーザ・リクエストに応答してサーバから前記アプリケーションを獲得し、前記アプリケーションは、前記ユーザが行う前記アプリケーションとの対話を、データ・モデル及び１つ又は複数のユーザ対話要素として表し、ここで前記１つ又は複数のユーザ対話要素は該データ・モデルのアプリケーション状態を移植し且つ該データ・モデルにバインドされ、及び前記アプリケーションは前記データ・モデル及び１つ又は複数のユーザ対話要素を含み、前記１つ又は複数のユーザ対話要素は、プログラムされるアプリケーションに関連付けられた情報をアクセスするために使用される形態、装置及びブラウザに関係なく、ダイアログを特徴付ける１以上の基本的プログラミング・コンポーネントを含み、
    （ii）前記ダイアログ・マネージャが、ユーザ入力から生成された属性値ペアを受け取り、該属性値ペアを処理して前記データ・モデルを移植し、次の対話フォーカスを決定し、
    （iii）前記ダイアログ・マネージャによる次の対話フォーカスの決定の際、前記アプリケーション状態及びコンテキストが更新され、それによって前記アプリケーションからのナビゲーションが、非逐次的な態様で及び少なくとも部分的にユーザに推進されて実行されることができ、そして前記対話マネージャによって出力が生成され、対話のために前記ブラウザを介して前記ユーザに供給される
    ことを含む、会話型ブラウザ装置。

Images