JP3943543B2 - マルチモーダル環境における対話管理およびアービトレーションを提供するシステムおよび方法 - Google Patents

Description

本発明は、一般には、会話型コンピューティングを提供するシステムおよび方法に関し、詳細には、複数の会話型（マルチモーダル）アプリケーション間の対話管理と自動アービトレーションとを提供するプロトコル、およびそのプロトコルをサポートするアーキテクチャに関する。

コンピューティングの分野は、何十億もの相互接続されたパーベイシブ・クライアントが高性能の情報サーバと通信する時代に向かって進化している。実際、今２１世紀は、ユビキタス情報アクセスを紛れもない事実にする多数の情報装置が利用可能になることによって特徴づけられるであろう。この進化は、インターネット、無線ネットワーク、または自発ネットワーク（ＢｌｕｅｔｏｏｔｈやＪｉｎｉなど）で相互接続された何十億ものパーベイシブ装置が、マン−マシン対話の基礎となる原理を大変革することになる。近い将来、パーソナル情報装置により、ユビキタス・アクセスが可能になり、現在の個人的ニーズや能力に最も適した対話モダリティを使用して、どのような情報でも、いつでもどこでも作成、操作、交換することができるようになる。このような装置としては、従来型電話、携帯電話、高度自動機能電話、電子手帳、ＰＤＡ、パーソナル・コンピュータなどの身近なアクセス装置などがあるが、これらの装置は、装置がユーザと情報をやり取りするために使用するインタフェース機器に大きなばらつきがある。

各ユーザが情報を操作するために利用可能な情報伝達性能の向上と共に情報が入手しやすくなり、それに伴って、マン−マシン・コミュニケーションの処理能力も向上させる必要が生じる。個人のその時々の特定の必要と能力とに合わせて設計された多種多様な機器を介して情報にアクセスすることができるということは、それらの対話がすべての利用可能な入出力（Ｉ／Ｏ）モダリティを利用してマン−マシン・コミュニケーションの処理能力を最大限にしなければならないということを必然的に意味する。実際、ユーザは、ハンズフリー、アイフリー環境における情報装置との対話を最大限にするために、そのようなマルチモーダル対話を求めるようになる。

現在の基盤は、複数の従来型アプリケーションやフレームワーク間でシームレスなマルチモーダル・アクセスを提供するようには構成されていない。実際、アクセス装置を使用し、通信ネットワークを介してサーバから夥しい量の情報（たとえば、専用ネットワークで利用可能な個人情報や企業情報や、インターネットなどの世界規模のコンピュータ・ネットワークを介してアクセス可能な公開情報）にアクセスすることができるものの、そのような情報の利用可能度は、ユーザがそのような情報を入手するための対話に使用するクライアント／アクセス装置のモダリティやプラットフォーム固有のソフトウェア・アプリケーションによって制約される場合がある。

しかし、会話型システムの導入が増えるに伴い、新たな技術的課題と制約に対処しなければならない。たとえば、様々な会話型アプリケーションの共存に対応する現在のフレームワークにおいてさえも、あらゆるモダリティ間、特に発話などの多義的なモダリティ間で、１つのアプリケーションから他のアプリケーションに自然に移行することは、そのようなアプリケーションのプログラミング・モデルと、アプリケーションを実行するプラットフォームのプログラミング・モデルに大幅な変更を加えなければ不可能である。たとえば、音声アプリケーションが一方のアプリケーションから他方のアプリケーションに移行するには、明示的（または事前作成）文法を定義する必要がある。したがって、そのようなシステム内のアービトレーションは、プラットフォームにインストールされているアプリケーションの知識なしに自動的に実行することができない。

さらに、現在の技術を使用した会話型アプリケーションの開発には、アプリケーションの目的と、ユーザとの対話をどのように定義すべきかという知識だけでなく、当該アプリケーション外部の他の多様なインタフェースとモジュールの知識が必要である。たとえば、（ｉ）入出力装置との接続（電話インタフェース、マイクロフォン、ウェブ・ブラウザ、パーム・パイロット・ディスプレイ）、（ｉｉ）様々なエンジンとの接続（音声認識、自然言語理解、音声合成、および、場合によっては言語生成）、（ｉｉｉ）資源およびネットワーク管理、（ｉｖ）マルチモーダル・アプリケーション用の様々なモダリティ間の同期などである。

したがって、複数の会話型（マルチモーダル）アプリケーション間の対話管理および自動アービトレーションを提供するシステムと、そのようなアーキテクチャをサポートするプロトコルとが必要である。
米国特許出願第０９／５４４８２３号 国際特許出願ＰＣＴ／ＵＳ９９／２２９２７ 国際特許出願ＰＣＴ／ＵＳ９９／２２９２５ 米国特許出願第０９／７０３５７４号 米国特許仮出願第６０／２５１０８５号 米国特許出願第０９／５４５０７８号

本発明は、複数の会話型アプリケーション間の自動対話管理およびアービトレーションのためのプロトコルを介した会話型コンピューティングを提供するシステムおよび方法と、そのプロトコルをサポートするフレームワークとを対象とする。

本発明の一態様では、ＤＭＡ（dialog manager andarbitrator（対話マネージャおよびアービトレータ））インタフェースが、複数のアプリケーション間のアービトレーションを行って所与のユーザ入力イベントのためのアクティブ・アプリケーションを判断するルートＤＭＡと、各アプリケーションに少なくとも１つのアプリケーションＤＭＡが関連づけられ、アプリケーション内の複数の副対話間のアービトレーションを行ってユーザ入力に関連づけられた副対話を管理するターゲット・アプリケーションＤＭＡを判断する複数のアプリケーションＤＭＡとを含む。好ましくは、ＤＭＡインタフェースは階層ツリー構造を含み、ＤＭＡインタフェースがボトムアップ手法を使用してアービトレーションを行う。ルートＤＭＡとアプリケーションＤＭＡは、ツリーの根がルートＤＭＡである階層ツリー・アーキテクチャ内で動作する。アプリケーションが起動されると、そのアプリケーションは、アプリケーションの主対話を管理するためにアプリケーションＤＭＡを生成する。このアプリケーションＤＭＡは、ルートＤＭＡに登録し、その子となる。アプリケーションは、副対話を管理するためにアプリケーションＤＭＡの１つまたは複数のインスタンスをインスタンス化する。これらのインスタンスは、アプリケーションが最初に起動されたときに生成されたａＤＭＡの子となる。子アプリケーションＤＭＡは、別個のスレッドで生成されることが好ましい。

本発明の他の態様では、１つまたは複数のアプリケーションの対話を管理する方法が、
ルートＤＭＡ（dialog manager and arbitrator（対話マネージャおよびアービトレータ））インタフェースと１つまたは複数のアプリケーションＤＭＡとを含む階層ツリー構造を含むＤＭＡインタフェースをインスタンス化するステップと、
該ルートＤＭＡによってユーザ入力イベントの通知をアプリケーションＤＭＡに送るステップと、
該アプリケーションＤＭＡが該ユーザ入力イベントの記号表現を入手するステップと、
該アプリケーションＤＭＡが該記号表現のコンテキスト解決を行うアプリケーション・メソッドを呼び出すステップと、
該アプリケーションＤＭＡが、該アプリケーションから該コンテキスト解決の結果を含む照会を受け取るステップと、
該ＤＭＡインタフェースが、該アプリケーションＤＭＡが受け取った該照会に基づいて該アプリケーションＤＭＡが現在アクティブであるか否かを判断するステップと、
該アプリケーションＤＭＡが現在アクティブであると判断された場合に、該アプリケーションＤＭＡが該照会に関連づけられたコールバック関数を起動するステップとを含む。

本発明の他の態様では、マルチモーダル入出力管理を行うシステムおよび方法が提供される。メッセージ／応答をユーザに提示するとき、Ｉ／Ｏマネージャが１つまたは複数のモダリティでメッセージを生成する。Ｉ／Ｏマネージャは、タスク・マネージャを使用して出力生成を駆動し、抽象出力イベントを生成する。Ｉ／Ｏマネージャは、抽象出力イベントを、ユーザに提示するための１つまたは複数のモダリティに変換する。

本発明の上記およびその他の態様、特徴、および利点は、添付図面と共に以下の好ましい実施形態の詳細な説明を読めば明らかになるであろう。

本明細書で使用する「会話型」および「会話型コンピューティング」という用語は、アクセス装置／チャネルの入出力機能にかかわりなく、好ましくは、オープンな相互運用可能通信プロトコルと、アプリケーション・データ・コンテンツ（層３）およびビジネス・ロジック（層２）をユーザ対話およびユーザが操作するデータ・モデルから分離する会話型プログラミング・モデル（たとえば会話型ジェスチャ・ベース・マークアップ言語）とを使用した、ユーザと機械との間、および様々なモダリティ（入出力機能）の装置またはプラットフォーム間のシームレスなマルチモーダル対話（情報交換）を指す。会話型コンピューティングは、人間と機械とが人間対人間の対話のように自然に対話を行うことができるようにする。

さらに、「会話型アプリケーション」という用語は、好ましくは（事前入出力を含む）短期および長期コンテキストを使用してユーザの意図を一義化し、把握する、アプリケーション内、および別々に開発されたアプリケーション間におけるマルチモーダルのフリーフロー対話（たとえば双方主導対話）を指す。会話型アプリケーションは、ＮＬＵ（自然言語理解）を使用することが好ましい。

マルチモーダル・インタラクティブ対話は、（たとえばＶｏｉｃｅＸＭＬで作成された）音声、映像（ＧＵＩ）（たとえばＨＴＭＬ（ハイパーテキスト・マークアップ言語（Hypertext markup language））、制約型ＧＵＩ（たとえばＷＭＬ（ワイヤレス・マークアップ言語（wirelessmarkup language））、ＣＨＴＭＬ（コンパクトＨＴＭＬ）、ＨＤＭＬ（ハンドヘルド・デバイス・マークアップ言語（handheld devicemarkup language））、およびこのようなモダリティの組合せ（たとえば音声とＧＵＩ）などのモダリティを含む。さらに、各モダリティ（またはモダリティの組合せ）は、完全ＮＬ（自然言語）ユーザ・インタフェースとして実現することもでき、その場合、汎用会話型ユーザ・インタフェース（ＣＵＩ）が得られる。上記の各例は宣言型であるが、本発明によると、いずれのモダリティも命令型にプログラムすることができ、宣言型と命令型のプログラミングの組合せによってもプログラム可能であることを理解されたい。

本発明は、複数の会話型アプリケーション間の自動対話管理およびアービトレーションのためのプロトコルと、そのプロトコルをサポートするフレームワークとを介した会話型コンピューティングを行うシステムおよび方法とを対象とする。図１は、本発明の一実施形態による会話型コンピューティングを提供するシステムの高水準ブロック図である。このシステムは、会話型アプリケーションの開発を可能にする１組の協調動作する構成要素を含む、会話型アプリケーション・フレームワーク（ＣＡＦ：conversational application framework）１１を含む。たとえば、ＣＡＦ１１は、様々なエンジンとインタフェースし、基礎にある機能を呈示する構成要素を含む。ＣＡＦ１１は、ＣＡＦ１１が配備された装置のための必要なＩ／Ｏ抽象化を提供する構成要素を含む。さらに、後述するように、本システムは、本発明による会話型アプリケーションとＣＡＦ１１との間のインタフェースを提供するＤＭＡＦ（dialogmanager and arbitrator facade（対話マネージャおよびアービトレータ・ファサード））を含む。

好ましくは、ＣＡＦ１１は、アプリケーション・コンテンツ（ビジネス・ロジックおよびバックエンド・アクセス）をユーザ対話から分離することにより、会話型コンピューティング・プログラミング・モデルをサポートする。対話ベースのプログラミング・モデルの好ましい実施形態については、たとえば、２０００年４月６日出願の「Method and System For Multi-Modal Browsing and Implementation of Aconversational Markup Language」という名称の米国特許出願第０９／５４４８２３号に記載されている。同出願は、本発明の譲受人に譲渡され、その全部が参照により本明細書に組み込まれる。

会話型アプリケーション・プラットフォーム（ＣＡＰ）１０は、ＣＡＦ１１に必要なシステム・サービス１２を特定のネイティブ・オペレーティング・システムにバインドするＣＡＦ１１の実施態様を含む。ＣＡＦ１１がＪａｖａ（Ｒ）で実施されそのサービスがＪａｖａ（Ｒ）バーチャル・マシン１３（および場合によっては追加のネイティブＯＳサービス）にバインドされている好ましい実施形態では、ＣＡＦ１１のこの実施態様を本明細書では会話型バーチャル・マシン（ＣＶＭ）と呼ぶ。本発明はＪａｖａ（Ｒ）で実施するのが好ましいが、他のオペレーティング・システム、プラットフォーム、またはバーチャル・マシンを使用して、本発明の教示および範囲により本明細書に記載のシステムおよび方法を実施することもできることを理解されたい。

ＣＶＭおよび対応する会話型プロトコルの好ましい実施形態については、１９９９年１０月１日出願の「Conversational Computing Via Conversational Virtual Machine」という名称の国際特許出願ＰＣＴ／ＵＳ９９／２２９２７（米国国内段階で出願され、米国出願番号第０９／８０６５６５号が与えられている）に記載されている。同出願は、本発明の譲受人に譲渡され、参照により本発明に組み込まれる。組み込まれる前記国際出願ＰＣＴ／ＵＳ９９／２２９２７号には、会話型ＡＰＩ（アプリケーション・プログラム・インタフェース）、会話型プロトコル、および会話型ファウンデーション・クラスをアプリケーション開発者に呈示し、異なる会話機能を有するプラットフォームおよび装置間における対話とコンテキスト、会話エンジンと資源、および会話型プロトコル／通信を管理して汎用ＣＵＩ（会話型ユーザ・インタフェース）を提供することにより会話型コンピューティングを実施する機能を果たすカーネル層を提供する、ＣＶＭ（会話型バーチャル／マシン）の様々なアーキテクチャが記載されている。ＣＶＭは、スタンドアロンＯＳ（オペレーティング／システム）として、あるいは従来のＯＳ上またはＲＴＯＳ（リアルタイム・オペレーティング・システム）上で動作するプラットフォームまたはカーネルとして実施することができ、従来のプラットフォームおよびアプリケーションとの下位互換性をもたせることもできる。

本発明の好ましい実施形態では、ＣＡＰ１０およびＣＡＦ１１は、上記の国際出願ＰＣＴ／ＵＳ９９／２２９２７号に記載されている構成要素、ＡＰＩ、および機能を含む。具体的には、本発明の好ましい実施形態は、たとえば、会話型アプリケーションとＣＡＦ１１との間の対話を仲介するＤＭＡＦ（対話マネージャおよびアービトレータ・ファサード）を実施する好ましい構成要素およびプロトコルの点で、上記の組込み国際出願ＰＣＴ／ＵＳ９９／２２９２７号の拡張である。このＤＭＡＦは、基礎にあるＣＡＦ構成要素への単一の標準接続点をアプリケーション開発者に提供するＡＰＩである。ＤＭＡＦは、アプリケーションと他のＣＡＦ構成要素との間の橋渡しをし、それによって、（ｉ）基礎にあるＣＡＦ構成要素、（ｉｉ）エンジン提供者がエンジンと装置をどのようにプラットフォームにフックするか、または（ｉｉｉ）ＣＡＦ構成要素とエンジンがどこに配置されているかに関してアプリケーション開発者が知らなくても済むようにする。したがって、ＤＭＡＦは、開発を容易にし、複数のエンジン間の相互運用性とアーキテクチャの分散可能性を向上させる。さらに、ＤＭＡＦは、ＤＭＡＦ上に構築されるアプリケーションの数、ドメイン、およびモダリティについて条件を課さない。したがって、本発明によるＤＭＡＦは、どのような会話型アプリケーションにおいても再利用可能である。

図２を参照すると、高水準ブロック図に、本発明の一実施形態によるＤＭＡＦを使用する会話型コンピューティングを実現するシステムが示されている。このシステムは、複数の外部インタフェースを備えるＣＶＭ１４を含む。外部インタフェースは、会話型アプリケーション１５と会話型アプリケーション開発者とのインタフェースを提供するＤＭＡＦ１６を含む。さらに、Ｉ／Ｏインタフェース１８は、たとえばキーボード、マウス、タッチ・スクリーン、キーパッド、音声入出力（音声入力／音声出力）を取り込む音声サブシステムなどを含む従来のＩ／Ｏ装置１７とのインタフェースを提供する。Ｉ／Ｏ ＡＰＩ１８は、装置抽象化、Ｉ／Ｏ抽象化、およびＵＩ抽象化を提供し、使用する１つまたは複数のＩ／Ｏモダリティに基づくモダリティ依存プレゼンテーションを提供する。Ｉ／Ｏマネージャの好ましい実施形態については後述する。

さらに、エンジン・インタフェース２０が、コア会話エンジン１９（たとえば音声認識、ＮＬ構文解析、ＮＬＵ、ＮＬＧ、ＴＴＳ、音声圧縮／圧縮解除エンジンなど）とそれらを使用するアプリケーションとの間のインタフェースを提供する。エンジンＡＰＩ２０は、コア・エンジンがローカルにあるかリモートにあるかを問わず、コア・エンジンと通信するプロトコルを提供する。エンジン・インタフェース２０はＪＳＡＰＩ（Ｊａｖａ（Ｒ）スピーチ（speech）ＡＰＩ）２１およびＡＰＩの拡張版を使用することが好ましい。

前述のように、本発明はＤＭＡＦ（対話マネージャおよびアービトレータ・ファサード）実装の好ましい実施形態およびプロトコルを対象とする。以下の好ましい実施形態の説明では、ＤＭＡＦが会話型バーチャル・マシン（ＣＶＭ）内に実装されるものとするが、本発明によるＤＭＡＦは、１つまた複数のアプリケーションの対話管理を行うどのようなプラットフォームにも実装することができる。さらに、ＣＶＭは（本明細書および前記の国際出願ＰＣＴ／ＵＳ９９／２２９２７号に記載の）様々な構成要素を含むが、以下では、ＤＭＡＦを含み、Ｉ／Ｏ管理に関係するＣＶＭ構成要素のみについて詳述する。さらに、ＤＭＡ構成要素がアプリケーションおよび様々な他のＣＶＭ構成要素との通信に使用するインタフェースについても説明する。

本発明によるＤＭＡＦ１６は、複数の会話機能を備える。このような機能には、
（ｉ）会話型アプリケーションにＣＡＰ（ＣＶＭ）にフックする標準方式を提供する機能、
（ｉｉ）プラットフォーム上にインストールされた複数の会話型アプリケーション間のアービトレーション、
（ｉｉｉ）同一アプリケーションに関連づけられた複数の副対話間のアービトレーション、および
（ｉｖ）アプリケーション情報の記憶と管理
が含まれる。

上記の機能を提供するために、ＤＭＡＦ１６は、アプリケーション開発者が開発した会話型アプリケーションをＣＶＭプラットフォーム１４上にインストールし、起動することができるようにする１組のインタフェースを含むことが好ましい。さらに、ＤＭＡＦ１６は、アプリケーション開発者が、フレームワークが備えるアービトレーション機能と対話管理機能にアクセスすることができるようにする１組のインタフェースを含む。

一般に、１つまたは複数の会話型アプリケーションを管理するために、ＣＶＭは、副対話マネージャ間の対話管理とアービトレーションを行う複合機能を実行する複数の対話マネージャおよびアービトレータ（ＤＭＡ）をインスタンス化する。このような管理およびアービトレーション機能を実行するために、アプリケーション開発者はＤＭＡハンドルを介してＤＭＡＦを使用する。会話型アプリケーションが初期設定され、起動されると、主対話のためのＤＭＡインスタンスが作成され、アプリケーションと関連づけられる。アプリケーションの実行中は、この関連づけられたＤＭＡがユーザ入力を管理し、ユーザ入力を適切な処理段階に渡し、最後に、そのような様々な処理段階か入手したユーザの意図の記号表現を処理する機会をアプリケーションに与える。

ユーザの意図を解釈するために、アプリケーションは、ＮＬＵによって返されるコマンド、トランザクション履歴、現在のコンテキストなどの追加情報を入手するようにＤＭＡに要求することができる。この解釈の結果は、ＤＭＡに返される。アービトレーションが完了した後、アプリケーションのＤＭＡがプラットフォーム上で動作しているすべてのアプリケーションのうちで最も確からしさの高い解釈を生成した場合、ＤＭＡはその解釈を処理するアプリケーション・メソッドを起動する。

ＤＭＡは、これらのメソッドの出力を処理のために適切な構成要素に渡すことによって管理し、（後述するように）入力の処理に使用するアルゴリズム・ストリングと同様のアルゴリズム・ストリングを使用して、適切なエンジンによる応答の処理と生成を制御する。処理後、アプリケーションの要件に従って出力応答が生成され、最終的にユーザに戻されて提示される。ユーザの意図を解釈するプロセスは、ＣＶＭまたはその目的のために設計された他の構成要素の対話管理機能によって行うこともできるものと理解されたい。さらに、このようなプロセスは、（アプリケーション提供者が提供するのではなく）プラットフォームまたは他のアプリケーションによって提供することもできる。

以下の説明では、本発明による対話管理およびアービトレーション・プロトコルを実施する、好ましい機構、構成要素、およびプロトコルについて概説する。総体的には、本発明は、（ｉ）プラットフォームに対話アプリケーションをインストールし、（ｉｉ）アプリケーション開発者がＤＭＡＦ構成要素を使用することができるようにし、（ｉｉｉ）ＤＭＡＦが他のＣＶＭ構成要素と通信することができるようにする機構を提供する。

初期設定機構およびインストール機構
好ましい実施形態では、初期設定機構およびインストール機構は、ＣＶＭプラットフォームを初期設定し、様々な構成要素がインスタンス化されてプラットフォームがアプリケーションのインストールを行う準備が整うようにする機構を含む。さらに、ＣＶＭ上に対話アプリケーションをインストールするための機構を備える。また、ＣＶＭ上でアプリケーションを動作させ、それによって、アプリケーションを音声またはＧＵＩ／コマンド行を介して起動することができるようにする機構も備える。さらに、ＣＶＭに複数のアプリケーションをインストールして実行する機構も備える。これにより、必要に応じてプラットフォーム上で動作している複数のアプリケーション間のアービトレーションとそれらのアプリケーション間の一義化を行うことができる最上位ＤＭＡが生成される。このような初期設定機構およびインストール機構の詳細については後述する。

対話管理機構およびアービトレーション機構
次に、本発明は、対話管理およびアービトレーションを実施する複数の機構を提供する。好ましくは、新しいＤＭＡインスタンスを作成し、それによって、所与のアプリケーションが最初に起動されたときにそのアプリケーションの主対話を管理する１つのＤＭＡインスタンスが常に生成されるようにする機構を備える。さらに、その所与のアプリケーションが、そのアプリケーションに関連づけられた副対話を管理するための他のＤＭＡインスタンスも生成することができる（ただし必須ではない）。

さらに、ＤＭＡＦは、副対話がある場合にそれらの副対話間のアービトレーションを行う機構を備え、それによって、所与のユーザ入力について、アービトレーション機構が、関連づけられた副対話を管理する目的ＤＭＡインスタンスを判断し、必要に応じて一義化する。

さらに、ＤＭＡＦは、ＤＭＡを介してＣＶＭにアプリケーション・プロパティを伝える機構を備える。これらのアプリケーションは、ローカルにあってもよく、また異なる装置または端末に分散していてもよい。このようなプロパティとしては、エンジン資源（音声認識、ＮＬＵなど）データ・ファイル（ＮＬＵオブジェクトや文法オブジェクトなど）などのアプリケーションが必要とする資源や、入力処理のためのアルゴリズム・ストリング（すなわちユーザ入力を処理するのに必要なエンジンのセットと順序）が含まれる。たとえば、ユーザ入力が発話（音声コマンド）を含む場合、アルゴリズム・ストリングは、フロント・エンド＋音声認識＋ＮＬＵを含む。ユーザ入力がタイプ入力コマンドである場合、アルゴリズム・ストリングはＮＬＵなどのみとなる。

１つまたは複数のアプリケーション・プロパティが変更された場合にＤＭＡ（および場合によっては他のＣＶＭ構成要素）にそれを通知する機構も備える。たとえば、アプリケーション・プロパティに加えられた変更は、（ＣＶＭ構成要素である）タスク・マネージャに通知しなければならない。後述するように、タスク・マネージャは対話エンジンと通信するＣＶＭ構成要素であり、したがって、タスク・マネージャは、ユーザ入力を処理する適切なエンジンをインスタンス化して使用することができるようにユーザ入力のアルゴリズム・ストリングを知る必要があり、そのようなストリングが変更されたときにはそれを知る必要がある。

さらに、ＤＭＡＦは、ＤＭＡにコマンド・レジストリを伝える機構を含むことが好ましい。コマンド・レジストリはコールバック関数に対する照会をマップする。アプリケーションは、所与のＤＭＡからユーザ意図の記号表現を受け取る。コンテキスト解決後、アプリケーションは、ユーザ意図の解釈を生成する。この解釈を、本明細書では「照会」と呼ぶ。コールバック関数は、ユーザ意図の解釈に関連づけられたアプリケーション・メソッドを含む。したがって、照会を受け取るＤＭＡは、それに関連づけられたメソッドを起動する。アプリケーション開発者は、コマンド・レジストリを随時更新することができる。

ＤＭＡＦが提供する他の機能として、ユーザ入力のために生成されたイベントのリストの維持と更新の機構がある。このようなイベントとしては、たとえば、入力通知、ＮＬＵの結果、生成された照会、コールバック応答などがある。さらに、所与のセッション全体を通して実行されたタスクのリストの維持と更新を行う機構も備える。タスクは、特定のアクションを行うために必要な１つまたは複数のユーザ入力を含む。したがって、すべてのタスクについて、各ユーザ入力のために生成されたイベントのサブセットが維持される。

ＤＭＡＦは、さらに、それぞれのアプリケーションで使用することができる情報を格納し、取り出すためのトランザクション履歴を、アプリケーション開発者に提供する機構を備える。この情報は、アプリケーション開発者の裁量に委ねられており、アプリケーション開発者がたとえばアクションの取消しや繰り返しの際に利用することができる、より意味論的レベルでイベントをグループ化するためのものである。好ましい実施形態では、どのような情報を格納し、取り出すかはアプリケーション開発者が指定するものとするが、本発明では、そのような決定を（たとえば、特別な履歴／コンテキスト／メタ情報マネージャ、ＣＶＭのサービス、または他のアプリケーションによって）自動的に行い、管理する適切な技法を実施することもできる。

さらに、ＤＭＡＦは、期待履歴や現在の状態などに基づくＮＬＵの結果の検証など、ユーザ入力イベントをアプリケーションと協同して一義化する機構も含む。一実施形態では、協同は、ＤＭＡによって維持されている様々な記帳コンテナへのアクセスを提供することによって行われる。その場合、アプリケーションは、コンテキスト解決を行い、その結果の照会をＤＭＡインスタンスに返すことができる。この場合も、前述のように、例示の実施形態では、コンテキスト解決はアプリケーションによって行われる（アプリケーション開発者によってプログラムされる）。ただし、コンテキスト解決は、他のサービス、マネージャ、またはＣＶＭ、または他のアプリケーションによって包括的またはアプリケーション限定的に行うこともできる。

さらにＤＭＡＦは、（アービトレーション・ヒューリスティクスに基づいて）所与のＤＭＡインスタンスが実際にユーザ入力の対象であると判断された後、最高得点の照会結果に基づいて適切なアプリケーション・メソッドを起動する機構を含む。

ディクテーション機構
ＤＭＡＦは、ディクテーションを行う複数の機構を含むことが好ましい。ディクテーション・セッション中、（ディクテーション・アプリケーションを管理する）ＤＭＡが、上位ＤＭＡにすべてのユーザ入力通知を当該ＤＭＡにのみ送るように通知できるようにする機構を備える。このディクテーション機能を提供する機構は、以下の通りであることが好ましい。

ＤＭＡが、ディクテーションを開始することを最上位ＤＭＡに通知するために使用し、最上位ＤＭＡがすべてのユーザ入力通知を当該ＤＭＡにのみ送るための通知方法を設けることが好ましい。さらに、ディクテーションを終了し、すべてのＤＭＡに対する入力通知を再開する通知機構を備えることが好ましい。一実施形態では、ユーザはＧＵＩ入力または音声コマンドを介してディクテーションを明確に停止する。ユーザがディクテーションを終了させると、ディクテーションを管理するＤＭＡが、最上位ＤＭＡにその終了を通知し、最上位ＤＭＡはすべての登録アプリケーションへのユーザ入力を再開する。

ディクテーションに関する他の機構は、ユーザがディクテーションを停止するように要求すると、ディクテーション・モードのアプリケーションが確実に入力制御を解放するようにする方法を含む。これは、好ましくは貪欲なアプリケーションがプラットフォーム上の他のアプリケーションにユーザ入力を受け取らせようとしなくなるのを防ぐためである。

他の実施形態では、プラットフォーム（サービスまたは他のアプリケーション）が、ディクテーションの開始と終了を自動的に判断する追加の機構を備えることができる。本明細書に記載の教示には、この実施形態に付随するＤＭＡおよびアプリケーションも含まれる。

コンテキスト解決機構
ＤＭＡＦは、さらに、コンテキスト解決を行う複数の機構を含む。コンテキスト解決は、現在状態、履歴、およびフォーカスに基づいて行うことが好ましく、照会を一義化するために使用される。たとえば、「open her mail（彼女のメールを開く）」という形の入力で、代名詞ｈｅｒはユーザが最後に話題にした人物を指す場合、ＤＭＡに設けられた様々な履歴内のイベントを調べ、最後に使用された名前が「メアリ（Mary）」であることを検出することによって一義化することができる。このアソシエーションが見つかった場合、以前の多義的コマンドopen_mail（sender=her）が、一義的コマンドopen_mail（sender=Mary）になる。この一義的コマンドは、それ以上の一義化対話を行わなくても、バックエンド・アプリケーションに送ったり、処理したりすることができる。

ただし、このアソシエーション処理には、アプリケーションの情報を解釈する機能が必要である。しかし、ＤＭＡは可能な限り汎用的な状態に維持し、しかも、ＤＭＡがコンテキスト解決を行うのに十分な性能を持つことができるようにすることが好ましい。

このようなコンテキスト解決機能を提供するために、ＤＭＡＦはＤＭＡによって実施される様々な方法を備える。ＤＭＡが実施する１つの方法では、ＤＭＡは様々な履歴内にアプリケーション情報を維持、管理し、アプリケーション開発者がそのような履歴にアクセスすることができるようにする。他の方法は、所与のアプリケーションが、当該所与のアプリケーションにのみ関係するイベントに変更を加えたりアクセスするようにしてコンテナの整合性を確実に維持するために必要な、セキュリティ機構を実施する。したがって、ユーザまたはアプリケーション開発者は、他のアプリケーションと共用可能な情報と、特定のアプリケーションでのみ共用すべき情報とを指定することができる。所与の情報または情報のタイプについて、このような親和アプリケーション、公用アプリケーション、または私用アプリケーションと、それに応じて使用する必要があるセキュリティ・ポリシーまたは共用ポリシーとを特定するための方法も使用することができる。

他の方法では、アプリケーションのために１つまたは複数のコンテキスト解決プロトコルを設ける。好ましいコンテキスト解決方策については詳述しない。ただし、使用する方法にかかわらず、その結果のＤＭＡＦは本発明の教示に含まれる。この場合も、これらの方法は、ＣＶＭ、アプリケーション開発者、または他のアプリケーションによって提供することができる。これらは、ＤＭＡの一部とみなすこともでき、ＤＭＡの外部にあるものとみなすことができる。アプリケーション開発者はＤＭＡＦが備える方法のいずれか１つを使用するか、または自分で実現することもできる。

ＤＭＡアーキテクチャ
本発明は、ＤＭＡインスタンスが互いに通信することができるようにする機構を提供する。実際に、好ましい実施形態では、複数のアプリケーション間、および同一アプリケーション内の様々な副対話間でアービトレーションを行うために、階層的ＤＭＡアーキテクチャを実装することが好ましい。

ロードされたアプリケーションのセキュリティ設定によって、様々なアプリケーションが、それぞれのＤＭＡ間で情報（コンテキストやユーザ入力など）を交換したりしなかったりする。アプリケーションが情報を共用することができない場合（たとえば異なる提供者によって提供されており、機密情報を含む場合など）、極端な場合には、アービトレーションを親和アプリケーションに限定する必要があることがある。１つの親和アプリケーション・クラスタ上にフォーカスがある状態から、別のクラスタに切り換えるには、プラットフォームにそのような切換えを行わせる明示的コマンドが必要になる。過去のコンテキストは失われる可能性がある。これは、後述のディクテーションに使用される機構でも同様である。

次に図３を参照すると、本発明の一実施形態によるＤＭＡＦによって実施される階層ＤＭＡストラクチャがブロック図で示されている。この実施形態では、最上位ＤＭＡ３０インスタンスが、ＣＶＭプラットフォームにインストールされている複数のアプリケーション３１、３２間のアービトレーションを行う。本明細書では、最上位ＤＭＡインスタンスを「ルートＤＭＡインスタンス」または「ｒＤＭＡ」と呼ぶ。各アプリケーション３１および３２は、ＤＭＡのインスタンスを少なくとも１つ作成してその主対話を管理する。たとえば、アプリケーション３１はＤＭＡインスタンス３３を作成し、アプリケーション３２はＤＭＡインスタンス３４を作成する。これらのＤＭＡインスタンス３３および３４は、最上位ＤＭＡインスタンス３０の子である。本明細書では、特定のアプリケーションのために作成されたＤＭＡインスタンスを「アプリケーションＤＭＡインスタンス」または「ａＤＭＡ」と呼ぶ。図３に階層アーキテクチャをさらに拡張して、（たとえばアプリケーションの副対話内に）所与のａＤＭＡの新しいインスタンスを作成することができる。たとえば、副対話を管理するために、ａＤＭＡ３３の新しいａＤＭＡインスタンス３５および３６を生成する。これらのａＤＭＡインスタンス３５および３６は、アプリケーション３１の主対話を管理するａＤＭＡ３３の子である。

したがって、図３で、ｒＤＭＡ３０はツリーの最上位にあり、プラットフォームにインストールされているすべてのアプリケーション間のアービトレーションを行う。所与のアプリケーションの主対話を管理するａＤＭＡは、ｒＤＭＡの子である。アプリケーションのために作成された後続のすべてのａＤＭＡは、主対話を管理するａＤＭＡの子孫になる。

対話管理サービスを受け取るためには、アプリケーションはｒＤＭＡ３０に登録してａＤＭＡハンドルを入手しなければならない。登録は、アプリケーションの起動時に行うことが好ましい。図３のアーキテクチャにおけるｒＤＭＡ３０は、複数のサービスを提供する。たとえば、ｒＤＭＡ３０は登録されているすべてのａＤＭＡのリストを維持し、どの登録ａＤＭＡがアクティブになっているかを追跡する。アクティブａＤＭＡは、現在「フォーカスがある」ａＤＭＡである。一実施形態では、１対話ターンについて最大で１つのアクティブａＤＭＡがある。ＤＭＡＦが１ユーザ入力当たり複数のアクションをサポートする他の実施形態では、１対話ターンについて複数のアクティブＤＭＡがあってもよい。

さらに、ｒＤＭＡ３０は、ユーザ入力にＩ／Ｏ通知イベントを関連づけ、履歴で追跡する。ｒＤＭＡ３０は、フォーカスの切換えを追跡し、子によって履歴に格納されるイベントを追跡する。イベントは、ａＤＭＡによって通常の記帳の一環として格納されることが好ましい。さらに、ｒＤＭＡ３０は、特定の子から要求された場合、履歴に格納されているイベントのために子を呼び出す。たとえば、一義化の場合、子ａＤＭＡはその親（この場合ｒＤＭＡ）に対して、一義化で使用する可能性のある何らかの情報のためにその子を呼び出すように依頼する。子、アプリケーション、または副対話のそれぞれによって設定されているセキュリティ設定に応じて、ｒＤＭＡはこのような情報の提供を受け付けたり拒否したりする。このセキュリティ設定は、初期設定時に行うことも、時間の経過と共に動的に変化することもできる。これらのプロパティは、各対話型アプリケーションとのＤＭＡＦインタフェースを介して設定することができる。アプリケーションが共用を拒否する場合、ユーザからの明示的フォーカス切換えコマンドが必要である。

ｒＤＭＡとａＤＭＡとの間では様々な情報が交換される。このような情報には、たとえば、（ｉ）ａＤＭＡをｒＤＭＡに登録／登録抹消するための情報、（ｉｉ）登録ａＤＭＡに送られるＩ／Ｏ通知イベント、（ｉｉｉ）ａＤＭＡ間のアービトレーションを行ってどのａＤＭＡが現在アクティブであるかを判断するためにｒＤＭＡがそのすべての子ａＤＭＡから受け取る最高得点照会、（ｉｖ）Ｉ／Ｏトランザクションの処理に移るようにアクティブａＤＭＡに送られる通知（およびそれと並行して、非アクティブａＤＭＡに対して処理に移らないように送られる通知）、（ｖ）コンテキストまたはフォーカスの変更の確認、（ｖｉ）次のプロンプトを求める要求、またはｒＤＭＡがプロンプトを作成するためにＮＬＧ（自然言語生成）エンジンに送る属性をその子ＤＭＡに求めることができる要求、（ｖｉｉ）子の履歴に格納されている情報を求めるための子の呼出しなどがある。

ＤＭＡが分散されている場合、上記の情報を暗号化することができる。この種の情報はきわめて機密性が高いため、ＤＭＡクライアントを信用することができない可能性がある。この問題に対処するために、様々な解決策を提供することができる。たとえば、一実施形態では、情報を交換することができる親和アプリケーションと、情報を交換することができない非親和アプリケーションとを指定する機構を設けることができる。親和アプリケーションは、同じ提供者によって開発されたものとすることができる。親和アプリケーションを指定する１つの機構は、電子認証またはその他の認証機構による認証を含む。これは、対話管理はアプリケーション内で行うことができるが、アプリケーション間のアービトレーションは、親和アプリケーションに限定されることを意味する。前述のように、他の親和アプリケーション・グループへの切換えには、ユーザによる明示的コマンドが必要である。これは、たとえば、ユーザがＣＶＭに対して明示的（「switch to ．．．（．．．に切り換えよ）など」）または暗示的（他のウィンドウのクリック）に出すコマンドである。どのアプリケーションが親和アプリケーションでどのアプリケーションが親和でないかという概念は、静的または動的な複数の基準（たとえば、現在のアプリケーションの機能、アプリケーションの状態、または、ユーザの選好を含めたその他の外部条件）を基にすることができる。

もう一つの解決策は、保全性を証明し、暗号化された情報を子または親と交換することができる「捺印済み」ａＤＭＡコードを使用することである。「捺印済み」という用語は、当該情報を、いかなるインタフェースを介してもその外部に明らかにせず、その情報をローカルで暗号化することを意味する。この「捺印済み」手法は、ＤＭＡが、解釈、対話管理、およびコンテキスト管理をすべて内部で（包括的またはアプリケーション固有に）行い、それによって情報を外部に渡す必要がない場合に適している。

他の解決策も実施可能であることを理解されたい。どのような解決策を実施した場合であっても、その結果のＤＭＡは本発明により予測されているものと理解すべきである。

ｒＤＭＡは、ボトムアップ手法を使用して複数のａＤＭＡ間のアービトレーションを行うことが好ましい。この手法では、ユーザ入力の通知がｒＤＭＡから登録されている各子ａＤＭＡに渡され、さらに、各子ａＤＭＡはそのユーザ入力を関連づけられた子に渡す。この手法の効率を向上させるために、枝刈り機構を備えることが好ましい。一実施形態では、ユーザ入力は、それまで「ｉ」ターンの間アクティブであった（すなわちフォーカスがあった）すべての登録ａＤＭＡに渡される。ただし、「ｉ」は、何らかの定義可能な数値である。どのような学習または最適化済み、またはヒューリスティックな（静的または動的）方法でも、ＤＭＡアーキテクチャおよび実行原理に変更を加えることなく使用することができる。以下の説明では枝刈りを行わず、すべての登録ａＤＭＡに実際に通知されるようにするものとする。

さらに、アービトレーションを実現するヒューリスティック、決定論的、または統計的アルゴリズムは、プラグ可能であることが好ましい。したがって、アービトレーション方策は、フレームワークの初期設定時に動的にロードされる。ＣＡＦをインストールする開発者は自分のアービトレーション方策をインストールすることができることが好ましい。この場合も、アービトレーション・アルゴリズムは、プラットフォーム、ＣＶＭサービス、または外部アプリケーションによって提供することができる。これらは、汎用的、またはロードされるアプリケーション固有のものとすることができる。これらは、ＤＭＡの一部とみなすこともＤＭＡの外部にあるものとみなすこともできる。

図４は、対話管理およびアービトレーションを行う方法の一例を示すブロック図である。具体的には、図４は、カレンダー・アプリケーション４０、投資信託アプリケーション４１、航空座席予約システム・アプリケーション４２の３つのアプリケーションの作成を示している。これらのアプリケーション４０、４１、および４２はすべて、ｒＤＭＡ４３によって管理されている。投資信託アプリケーション４１のために、主対話を管理する１つのａＤＭＡ４４が生成され、このａＤＭＡ４４からユーザ・アクセス副対話と投資信託トランザクション副対話を処理する２つのａＤＭＡがインスタンス化される。すなわち、ユーザ・アクセスを扱う副対話ａＤＭＡ４５と、投資信託トランザクションを扱う副対話ａＤＭＡ４６である。トランザクション対話はさらに細分され、２つの異なるａＤＭＡ４７および４８によって、それぞれ販売トランザクションと購入トランザクションが処理される。具体的には、投資信託の販売を扱うトランザクション対話下の副対話は、ａＤＭＡ４７によって管理され、投資信託の購入を扱うトランザクション対話下の副対話はａＤＭＡ４６によって管理される。

さらに、図４の例示の実施形態では、カレンダ・アプリケーション４０と航空座席予約アプリケーション４２の両方がそれぞれ、１つのａＤＭＡインスタンス４８および５０を生成し、対応するアプリケーションに関連づけられた主対話を扱う。

ＤＭＡ構成要素
以下の説明では、記帳サービスを行うために使用する、ＤＭＡの好ましい構成要素を扱う。図５は、本発明の実施形態により、そのような目的のために使用されるｒＤＭＡおよびａＤＭＡの好ましい構成要素を示す図である。本発明の他の実施形態では、ＤＭＡの原理に影響を与えることなく、これらの構成要素を除外したり、異なる方法で組み合わせたり、他の構成要素を組み込んだりすることができる。ｒＤＭＡ６０は、登録された子ａＤＭＡを、ａＤＭＡが扱う対応アプリケーションにマップする登録テーブル６１を含む。ａＤＭＡ６５は、子ａＤＭＡを、それらの子ａＤＭＡが扱う副対話に関連づけるために使用される登録テーブル６６を含む。ｒＤＭＡ６０は、さらに、所与のセッション全体を通してアクティブなａＤＭＡのレコードを格納するフォーカス履歴６２を含む。同様に、ａＤＭＡ６５は、所与のセッション全体を通してアクティブな子ａＤＭＡのレコードを格納するフォーカス履歴６７を含む。

さらに、ａＤＭＡ６５は、アプリケーション開発者に、完了したトランザクションを格納することができるコンテナを提供するトランザクション履歴を含む。完了したトランザクションは、何らかの意味論的意味を共有する様々なタスクをグループ化することができる。好ましい実施形態では、トランザクション履歴６８に格納される情報はすべてアプリケーション開発者の裁量に任されていることを理解されたい。このトランザクション履歴６８は、アプリケーションが、たとえばアクションの「取消し」、「繰り返し」、記憶、要約などを行うために使用することができる。たとえば、「取消し」操作をコード化するには、アプリケーションは、トランザクション履歴を使用して、特定のトランザクションを遂行するために行うすべてのステップを記録することができる。ユーザが、最後に行ったトランザクションを「取消し」したい場合、アプリケーションは、そのトランザクションについて記録されたタスクのリストを取り出し、各タスクを逆順に取り消し、それによって、アプリケーションの状態をユーザがそのトランザクションを行う前の状態に回復させることができる。

さらに、ｒＤＭＡ６０は以下の情報を維持する短期履歴ストア６３を含む。すなわち、（ｉ）Ｉ／Ｏ通知イベント、（ｉｉ）Ｉ／Ｏ通知を受け取ったａＤＭＡ（この場合も、すべての登録ａＤＭＡがＩ／Ｏ通知イベントを受け取るものとするが、枝刈り機構を使用する他の実施形態では登録ａＤＭＡのサブセットのみが通知を受け取り、そのサブセットは、何らかのヒューリスティック、学習、決定論的、または統計的最適化アルゴリズムなどによって決定することができる。ヒューリスティック・アルゴリズムの場合、Ｉ／Ｏ通知を受け取る登録ａＤＭＡのリストを維持する。）、（ｉｉｉ）「タスクの実行を開始せよ」という通知を受け取ったａＤＭＡ（すなわち現在アクティブａＤＭＡ）、（ｉｖ）出力要求通知およびそれを送ったａＤＭＡ、（ｖ）タスクが実行されたときにａＤＭＡが送ったタスク記述子（このタスク記述子は、所与のタスクのために生成されたイベントのサブセットを含む（ａＤＭＡにおけるＬＨＴを参照））などである。

ａＤＭＡ６５は、対話において特定の状態を生成したすべてのイベントを格納する短期履歴ストア７０を含む。このようなイベントには含まれるのは、（ｉ）、入力通知イベント、（ｉｉ）タスク・マネージャ通知イベント、（ｉｉｉ）ＮＬＵ結果（またはエンジンから戻される結果）、（ｉｖ）コンテキスト解決の結果（この結果はアプリケーションによって渡される。アプリケーションはＬＨＴ、ＳＴＨ、フォーカス履歴へのアクセスを入手し、実際の照会が何であるかを判断する。その結果、すでに記入された特徴／値の対のリストに変更が加えられることがある。ａＤＭＡは、アプリケーション・コンテキスト・オブジェクトを介してこの情報にアクセスすることができる）、（ｖ）親ＤＭＡ（これが主ａＤＭＡである場合は親ａＤＭＡまたはｒＤＭＡとすることができる）に返送された照会、および（ｖｉ）フォーカス計算後の親応答などである。

短期履歴は、コールバック関数が戻されるとフラッシュされる。その場合、短期履歴に格納されているもののサブセットは、後述のように記述子に入れられて長期履歴に格納される。

ｒＤＭＡ６０は、さらに、非アクティブａＤＭＡのタスク記述子を格納する長期履歴６４を含む。すなわち、対話が終了すると、特定のａＤＭＡのＳＴＨ内のタスク記述子がＬＴＨに移動される。ａＤＭＡ６５は、タスクの実行を引き起こす主イベントを格納する長期履歴７０を含む。短期履歴には、対話における各状態のレベルの情報が格納されるのに対し、長期履歴には、対話全体レベルの情報が格納される。したがって、タスクが完了し、対話が新しい状態になると、短期履歴内のイベントのサブセットが長期履歴にプッシュアウトされる。このイベントのサブセットは、記述子オブジェクトとしてグループ化することができ、それにＩ／ＯトランザクションＩＤが付与されて長期履歴にプッシュアウトされる。イベントのサブセットには、（ｉ）Ｉ／Ｏ入力通知イベント、（ｉｉ）照会オブジェクト、および（ｉｉｉ）コールバック応答が含まれる。

ＤＭＡＦとＣＡＦ構成要素との対話
ＤＭＡＦは、ＣＶＭの他の構成要素と共に動作する。図６を参照すると、本発明の一実施形態による会話型コンピューティングを行うシステムがブロック図で示されている。具体的には、図６の実施形態は、ＤＭＡＦと他のＣＡＦ構成要素との間のインタフェースを示している。このシステムは、会話型アプリケーション８０と、アプリケーションＤＭＡ８１と、ルートＤＭＡ８２と、Ｉ／Ｏマネージャ８３と、スレッドプール・マネージャ８５およびエンジン・マネージャ８６を含むタスク・マネージャ８４と、資源マネージャ８７と、複数の会話エンジン８８とを含む。アプリケーションＤＭＡ８１とルートＤＭＡ８２、および関連インタフェースは、ＤＭＡＦを含む。ＤＭＡＦは、会話型アプリケーション８０とその他のＣＡＦ構成要素８３、８４、８５、８６、８７、および８８との間のインタフェースをとる。

Ｉ／Ｏマネージャ８３は、すべての入出力装置とインタフェースするＣＡＦ構成要素である。Ｉ／Ｏマネージャ８３は、ＤＭＡＦとの内部インタフェースを介して、ｒＤＭＡ８２に入力通知イベントを送り、ｒＤＭＡ８２を介して送られる出力要求をユーザに提示する。具体的には、Ｉ／Ｏマネージャ８３は、以下の機能を実行する。すなわち、（ｉ）ｒＤＭＡにユーザ入力通知イベントを送り、（ｉｉ）ｒＤＭＡから出力通知要求を受け取り、（ｉｉｉ）子が入力を消費するときにｒＤＭＡから肯定応答を受け取り、（ｉｖ）出力を提示した後でｒＤＭＡに肯定応答を送る。したがって、ｒＤＭＡ側から見ると、Ｉ／Ｏマネージャとの対話には、入力通知イベントを受け取るメソッドと、出力生成要求を送るメソッドとが必要である。本発明によるＩ／Ｏ管理を行う好ましい実施形態およびプロトコルについては以下で詳述する。

さらに、ＤＭＡＦは、エンジンＡＰＩを介してエンジン８８（ＡＳＲ、ＮＬなど）とインタフェースするＣＡＦ構成要素であるタスク・マネージャ８４と通信する。タスク・マネージャは、たとえばエンジン８８の初期設定と構成、スレッドの登録、プロンプトの作成、出力の合成などを行う、アプリケーションＤＭＡ８１からのコマンドを処理する。タスク・マネージャ８８は、スレッドプール・マネージャ８５とエンジン・マネージャ８６の２つの構成要素を含む。スレッドプール・マネージャ８５は、プラットフォームによって作成されたスレッドを追跡する役割を果たす。ＤＭＡＦのコンテキストでは、スレッドプール・マネージャ８５は、アプリケーション８０の起動時に作成される（アプリケーションＤＭＡ８１に関連づけられた）主アプリケーション・スレッドと、アプリケーション８０の副対話を管理するために子ａＤＭＡが作成されるときに作成されるすべてのスレッドを管理する。エンジン・マネージャ８６は、エンジンＡＰＩとの一次インタフェースとして機能する。エンジン・マネージャ８６は、ＣＶＭのもう一つの構成要素である資源マネージャ８７と協同する。資源マネージャ８７は、プラットフォーム上のすべての資源を管理するが、好ましい実施形態では、資源マネージャはＤＭＡＦとは直接対話せず、タスク・マネージャがアクセスする資源を指定するだけである。

タスク・マネージャ８４の役割には以下のものが含まれる。すなわち、（ｉ）ａＤＭＡからユーザ入力通知イベントを受け取ることと、（ｉｉ）エンジンの結果（たとえばＮＬＵ特徴値の対、ＮＬＵ構文解析木、フリー・テキストなど）をＤＭＡに送ることと、（ｉｉｉ）ａＤＭＡから出力要求生成を受け取ることと、（ｉｖ）ａＤＭＡに出力結果（たとえばプロンプト）を送ることと、（ｖ）スレッドプール・マネージャを介してスレッドを管理することである。ＤＭＡが新しいスレッドを作成すると、スレッドはそれ自体をスレッドプール・マネージャ８５に登録する。スレッドプール・マネージャ８５は、ＣＶＭ構成要素によって作成されたすべてのスレッドを管理する。

好ましい実施形態では、タスク・マネージャ８４はＸＭＬベースのコード化体系を使用してエンジン８８と対話管理フレームワークとの間で情報を交換する。好ましいＸＭＬコード化は、必要になったときに新しい情報を追加することができるように拡張可能な、ＸＭＬの単純な方言を定義することを理解されたい。ＸＭＬストリームを使用して対話管理フレームワークとエンジンとを通信させることによって、このアーキテクチャは自動的に分散可能になる。その場合、対話管理フレームワークとエンジンは、互いをＸＭＬコード化ストリームの生成者／消費者とみなす。ＸＭＬコード化（たとえばＳＯＡＰなどのＸＭＬプロトコル）において制御交換を交換することができ、その際、場合によっては、たとえば１９９９年１０月１日出願の「System and Method For Providing Network Coordinated ConversationalServices」という名称の国際出願ＰＣＴ／ＵＳ９９／２２９２５号に記載されている機構と、２０００年１１月１日出願の「ConversationalNetworking Via Transport, Coding and Control Conversational Protocols」という名称の米国特許出願第０９／７０３５７４号に記載の機構を使用して、制御交換を着信または発信音声またはマルチメディア・ストリームと同期させることができる。米国特許出願第０９／７０３５７４号には、たとえば分散装置／アプリケーション間で制御情報のリアルタイム交換を行う、（ＲＴＰ（リアルタイム・プロトコル）の拡張版である）新規なリアルタイム・ストリーミング・プロトコルについて記載されている。

ＤＭＡと会話型アプリケーションとのインタフェース
以下では、ＤＭＡＦが会話型開発者に呈示する様々なインタフェースについて説明する。これらのインタフェースは、アプリケーション開発者側から見ると、ＤＭＡＦとの（したがってＣＶＭとの）完全な対話を可能にする。

好ましい実施形態では、ＣＶＭプラットフォームへのアクセスを提供するように、ＤＭＡＦを使用して会話型シェル・アプリケーション（または「ＣＶＭｓｈｅｌｌ」）を実現する。ＣＶＭｓｈｅｌｌアプリケーションは、所与のプラットフォームにＣＶＭがインストールされるとインスタンス化される。ＣＶＭｓｈｅｌｌは、プラットフォームがホストする最初のアプリケーションであることが好ましい。

ＣＶＭｓｈｅｌｌは、複数の好ましい機能を提供する特殊アプリケーションである。たとえば、シェル・アプリケーションは、すべてのＣＶＭ構成要素をインスタンス化する。ＣＶＭｓｈｅｌｌは、アプリケーション開発者が、開発した会話型アプリケーションをＣＶＭプラットフォームにインストールするために実装しなければならない「インストール・インタフェース」を提供する。ＣＶＭｓｈｅｌｌは、アプリケーション開発者が自分のアプリケーションをＣＶＭにローカルまたはリモートからダウンロードするために使用する、単純なコマンド行インタプリタを備える。さらに、ＣＶＭｓｈｅｌｌは、ユーザが、コマンド行ＧＵＩまたは音声コマンドあるいはその両方を介してプラットフォーム上でアプリケーションを実行することができるようにするインタフェースも提供する。

さらに、ＣＭＶｓｈｅｌｌは、ｒＤＭＡ、Ｉ／Ｏマネージャ、タスク・マネージャ（これらはさらに、スレッドプール・マネージャ・モジュールやエンジン・マネージャ・モジュールをインスタンス化する）、資源マネージャなどの構成要素をインスタンス化する複数のメソッドを含む。好ましくは、これらすべてのクラスのインスタンスを生成するためのクラスのファクトリを備える。

ＣＶＭｓｈｅｌｌは、シェル・プロパティ・クラスをインスタンス化し、それにシェル、データ・ファイル、およびアルゴリズム・ストリングのすべての資源を格納する関数を備える。さらに、ＣＶＭｓｈｅｌｌは、コマンド・レジストリを作成する。コマンド・レジストリ・テーブルは、ＣＶＭにアプリケーションがインストールされていないときには空であるが、最終的には、所与のアプリケーションを起動するコマンドのリストと、そのアプリケーションへの対応する入口点がコマンド・レジストリに格納される。さらに、ＣＶＭｓｈｅｌｌは、新しいａＤＭＡオブジェクトを生成し、シェルのプロパティ・クラスをそのコンストラクタに送る（コンストラクタはａＤＭＡとタスク・マネージャを当該クラスのリスナとして付加する）。

ＣＶＭｓｈｅｌｌが初期設定されると、すべてのオブジェクトがインスタンス化される。ＣＶＭｓｈｅｌｌはさらに、これらのオブジェクトにハンドルを返す静的メソッドを含む。

ＣＶＭｓｈｅｌｌによって提供される「インストール・インタフェース」は、アプリケーション開発者がプラットフォームにアプリケーションをインストールすることができるようにするインタフェースである。インストール・インタフェースは、以下のメソッドを提供することが好ましい。すなわち、（ｉ）アプリケーション名と、そのアプリケーション名を実現するクラスの指定、（ｉｉ）アプリケーションを起動するために使用することができるコマンドのリストの生成、（ｉｉｉ）それらのコマンドがエンジンによって把握されると起動するコールバック関数のリストの生成、（ｉｖ）アプリケーションの起動方式（ＧＵＩ、コマンド行など）の指定、を行うメソッドである。

インストール・プログラムを実行すると、ＣＶＭｓｈｅｌｌのコマンド・レジストリに、アプリケーションによって提供されるコールバック関数とコマンドが格納される。新しいアプリケーションがインストールされるたびに、コマンド・レジストリに新しいコマンドとコールバック関数が追加される。２つのアプリケーションが１つまたは複数の同じ起動コマンドを使用する場合、インストール・インタフェースは、選択されたコマンドによって前のアプリケーションの起動コマンドが上書きされることを２番目のアプリケーションに警告するものと理解されたい。

ＤＭＡＦはさらに、会話型アプリケーションとの対話を可能にする複数のメソッドを実装する。具体的には、ＤＭＡＦは、アプリケーションが利用することができ、次のような機能を実現するために使用されるメソッドを実装することが好ましい。すなわち、（ｉ）ＤＭＡを生成し、（タスク・マネージャに渡される）文法、言語モデル、入出力処理指定のためのアルゴリズム・ストリングなどのＤＭＡアプリケーション・プロパティを渡す、（ｉｉ）コールバック関数とそれに付随する照会を含む（ＤＭＡで使用される）コマンド・レジストリに格納する、（ｉｉｉ）（ＤＭＡで使用する）対話状態終了条件を指定する、（ｉｖ）ＤＭＡにトランザクション・レコードを格納し、取り出す（この場合も、これらのレコードは、取消し、繰り返し、または要約アクション（アプリケーションでサポートされている場合）で使用することができ、各トランザクションを構成するイベントのグループ化はアプリケーション開発者の裁量に任されている）、（ｖ）コンテキスト解決で使用するためにＤＭＡ履歴にアクセスする機能である。

さらに、会話型アプリケーションは、ＤＭＡＦとの対話を可能にする複数のメソッドを実装する。好ましい実施形態では、ＤＭＡＦは、ＤＭＡＦがアプリケーションと通信することができるように、アプリケーション開発者が１つまたは複数のメソッドを少なくとも実装することを求める。たとえば、一実施形態では、会話型アプリケーションは、コンテキスト解決を行う適切なメソッドを実装する。そのような実施形態では、ＤＭＡＦは、コンテキスト解決のために特定のプロトコルを強制しないが、ＤＭＡＦはメソッドおよび戻り型に渡される関数は強制する。たとえば、好ましい一実施形態では、contextResolverメソッドがNLResultオブジェクトを受け付け、Queryオブジェクトを返す。

ＤＭＡ情報の流れ
以下では、ユーザ入力が取り込まれてｒＤＭＡに送られた後でのＤＭＡ内部での情報の流れについて説明する。情報の流れについて説明する前に、ＤＭＡによって定義される好ましい内部クラスとその用法を以下に列挙する。
− 入力通知イベント・クラス：入力通知イベントは、Ｉ／Ｏマネージャによって生成され、ｒＤＭＡコマンド・レジストリ・クラスに送られる。
− コマンド・レジストリ・クラス：照会とそれに関連づけられたコールバック関数とを格納するテーブルを生成する。
− 登録テーブル・クラス：ＤＭＡと、アプリケーション／管理する副対話に対する参照とを格納するテーブルを生成する。
− 入力キュー・クラス：入力通知イベントを入れるキューを生成する。各ａＤＭＡは、入力イベント通知を格納する入力キュー・クラスを含む。ａＤＭＡは、親から入力通知イベントを受け取ると、その入力通知イベントを、そのすべての子の入力キューに入れ、それによってそれらの子がそのユーザ入力の処理を開始することができるようにする。この通知は、そのユーザ入力イベントがすべてのＤＭＡに通知されるまで、トップダウン方式で再帰的に行われる。
− ＮＬＵ結果クラス：ＮＬ結果、信頼値、およびＮＬＵプロセスに付随するその他のデータを格納する。
− 照会クラス：コンテキスト解決の結果を格納する。
− 照会ハッシュテーブル・クラス：照会を入れるハッシュテーブル。これは、ＤＭＡによってキー付けされたハッシュテーブルである。各ＤＭＡ（キー）には、コンテキスト解決の結果として得られた照会（値）が関連づけられている。このハッシュテーブルは、ＤＭＡの結果照会を示す。
− 短期履歴（ＳＴＨ）クラス：単一ユーザの入力に関するイベントが格納されるスタックを生成する。
− 長期履歴（ＬＴＨ）クラス：特定のタスクに関するイベントが格納されるスタックを生成する。
− トランザクション履歴（ＴＲＨ）クラス：トランザクション・オブジェクトが格納されるスタックを生成する。これらのオブジェクトは、アプリケーション開発者によって定義された意味レベルでイベントをグループ化するものである。
− フォーカス履歴（ＦＨ）クラス：現在フォーカスを追跡するスタックを作成する。

図７ないし図１０に、本発明の一態様による対話管理およびアービトレーションを行う方法を示す流れ図が示されている。具体的には、図７ないし図１０は、ＤＭＡ内の情報の流れを示し、ＤＭＡがユーザ入力をどのように扱い、それを処理のために様々な構成要素に渡し、ユーザの意図の記号表現をアプリケーションに返すかを説明する図である。以下に示すアルゴリズムでは、アプリケーションが照会をＤＭＡに返した後で、ＤＭＡがコールバック関数の出力応答をどのように管理するかを詳述する。

図７を参照すると、ユーザは、たとえば発話またはＧＵＩによる適切なコマンドを使用して１つまたは複数の会話型アプリケーションを起動する（ステップ１００）。アプリケーションが起動されると、そのアプリケーションのために１つまたは複数のａＤＭＡインスタンスが生成される（ステップ１０１）。前述のように、１つのアプリケーションによって、そのアプリケーションに関連づけられた主対話を管理する少なくとも１つのａＤＭＡインスタンス（ルートＤＭＡの子）が生成される。さらに、アプリケーションのプログラムの仕方によっては、副対話を管理するための他のａＤＭＡインスタンス（主ａＤＭＡの子）を生成することもできる。アプリケーションはｒＤＭＡに登録されて、アプリケーションによって生成されたａＤＭＡインスタンスのａＤＭＡハンドルを入手する（ステップ１０２）。ｒＤＭＡは、すべての登録ａＤＭＡのリストを維持する。この登録によって、アプリケーションはｒＤＭＡから対話管理サービスを受けることができるようになる。前述のように、対話マネージャおよびアービトレータ・アーキテクチャは、複数のアプリケーションをサポートする。したがって、以下の説明では、１つまたは複数のアプリケーションがアクティブであるものとする。

アプリケーションが初期設定されると、システムはユーザ入力イベント、たとえば音声コマンドまたはマウスのクリックを待つ（ステップ１０３）。ユーザ入力イベントを受け取ると（ステップ１０３の結果が肯定）、Ｉ／Ｏマネージャが対応するユーザ入力通知イベントをｒＤＭＡに送る（ステップ１０４）。次に、ｒＤＭＡは、ｒＤＭＡの入力キューから入力通知イベントを受け取る（ステップ１０５）。所与のアプリケーションの「終了」条件が満たされていない場合（ステップ１０６の判断が否定）で、しかも入力通知イベントが「ＥＮＤ＿ＯＦ＿ＩＮＰＵＴ」イベントでない場合（ステップ１０７の判断が否定）、ｒＤＭＡは入力通知イベントをそのＳＴＨ（短期履歴）に格納し（ステップ１０８）、次に、その入力通知イベントを登録されているすべての子の入力キューに入れる（１０９）。言い換えると、一実施形態では、ｒＤＭＡは、ｒＤＭＡに登録されている主ａＤＭＡのそれぞれに入力通知イベントを送る。各主ａＤＭＡは、トップダウン手法を使用して、子孫ａＤＭＡインスタンスがある場合はその子孫ａＤＭＡインスタンスの入力キューに入力通知イベントを入れる。このプロセスは、すべてのａＤＭＡインスタンスが入力通知イベントを受け取るまで、階層ツリーを下方にたどって繰り返される。

他の方法を使用して入力通知イベントをツリー内のａＤＭＡに送ることもできることを理解されたい。実際に、前述のように、好ましくはｒＤＭＡはどの登録ａＤＭＡがアクティブであるかを追跡するため、それまで所定数の対話ターンの間アクティブになっている（「フォーカスがある」）登録ａＤＭＡにのみユーザ入力が渡される枝刈り手法を使用することもできる。当業者なら、登録ａＤＭＡにユーザ入力を渡すための他のプロトコルも考えられるであろう。

次に図８を参照すると、各ａＤＭＡは、入力通知イベントをタスク・マネージャに送り、それ以降、現行通知イベントに対して応答を受け取るまでタスク・マネージャへの通知イベントの送信を遮断する（ステップ１１１）。タスク・マネージャは、タスク・マネージャが当該ユーザ入力通知イベントを受け取った各ａＤＭＡに、メッセージまたは結果セット（たとえば音声認識結果やＮＬＵ結果など）を返す（ステップ１１２）。エラー・メッセージが返された場合（ステップ１１３の結果が肯定）、そのエラーがしかるべく処理される（ステップ１１４）。たとえば、タスク・マネージャからエラー・メッセージが返された場合、ａＤＭＡは、アプリケーションにそのエラーを通知する。エラーには異なる重大度を付与することができ、重大度によっては、ａＤＭＡは、エラーを無視することに決め、アプリケーションにエラーを通知して次のユーザ入力に移行する（たとえばステップ１０３に戻る）か、または重大度が高い場合には、アプリケーションを終了することもできる。アプリケーションは、エラーを処理する機構を備えるか、あるいはプラットフォーム・サービス（ＣＶＭ）または他のアプリケーションにエラー処理を頼ることができ、エラー回復機構またはエラー処理対話を備えることができる。これらは、アプリケーション固有であってもよいし、汎用的なものであってもよい。

一方、結果セットが返された場合（ステップ１１３の結果が否定）、各ａＤＭＡは、その結果を各ａＤＭＡに対応するＳＴＨに格納する（ステップ１１５）。この結果セットは、エンジンによって生成されたユーザの意図の記号表現を含む。各ａＤＭＡは、結果セットを、コンテキスト解決のために各ａＤＭＡに対応するアプリケーションに送り、現行結果セットのために照会が返されるまで、アプリケーションに対するそれ以降の結果の転送を遮断する（ステップ１１６）。

アプリケーションは、関連づけられた１つまたは複数のａＤＭＡが受け取った結果に基づいてコンテキスト解決を行い、照会（すなわちユーザの意図の解釈）を生成する。コンテキスト解決のプロセスは、アプリケーションごとに異なり、同じアプリケーション内でも副対話ごとに異なることを理解されたい。したがって、各ａＤＭＡが受け取るコンテキスト解決の結果（すなわち照会）は異なる。さらに、コンテキスト解決のプロセス中、アプリケーションは、ａＤＭＡと協同して、ＮＬＵによって返されたココマンド、トランザクション履歴、現行コンテキストなど、ａＤＭＡによって維持されている付加情報を入手して照会を一義化することができる。

コンテキスト解決後、アプリケーションは、各ａＤＭＡに結果の照会を返す。各ａＤＭＡは、アプリケーションから受け取った照会をそれぞれのＳＴＨに格納する（ステップ１１６）。前述のように、対話管理、ユーザ意図の把握、およびコンテキスト解決の各機能は、モジュール（アプリケーション、ＣＶＭサービス）によって提供することもでき、各ａＤＭＡによって提供することもできる。

次に、ボトムアップ手法を使用して、階層ツリー内の各親ａＤＭＡによって任意の方法によるアービトレーションが行われる。好ましい実施形態では、適切なヒューリステック・アルゴリズムを使用して、「勝利照会」（すなわち最高得点照会結果）を決定する。具体的には、ツリー構造の最下位層から開始して、各親ａＤＭＡが、その各子ａＤＭＡがそれぞれの「勝利」照会を親の出力キューに入れるのを待つ（ステップ１１８）。ツリーの各枝の最下部にある子ａＤＭＡは、親ではないためアービトレーションを行わない（すなわち、（アプリケーションから受け取った）それぞれの照会を親に提供するだけである）ことに留意されたい。

アラーム・マネージャを使用して、所定時間後にタイムアウトをトリガし、親ａＤＭＡが各子から勝利照会を受け取るのを無限に待たないようにすることが好ましい。したがって、所定の待ち時間が経過した場合（ステップ１１９の結果が肯定）、タイムアウトが発生する（ステップ１２０）。その場合、親は所定期間内に勝利照会で応答しなかった各子ａＤＭＡを黙殺（無視）し、対応するアプリケーションにエラー・メッセージを送る（ステップ１２１）。他の実施形態では、子が特定の複雑な処理タスクについてタイムアウト延長を親に要求した場合、タイムアウトを延長することができることを理解されたい。

次に、親ａＤＭＡは、親がアプリケーションから受け取った照会と、（待ち時間中に子が受け取った）その出力キュー内のすべての勝利照会とについてアービトレーションを行い、親のレベルでの勝利照会を決定する（ステップ１２２）。図９を参照すると、次に親は勝利照会を対応するａＤＭＡの識別情報と共にそのＳＴＨに格納する（ステップ１２３）。次に、（別の親ａＤＭＡの子である）親が、勝利照会をその親のａＤＭＡの出力キューに入れ、ａＤＭＡが親から対応するアービトレーション結果を受け取るまで、それ以降の勝利照会の転送を遮断する（ステップ１２４）。

このアービトレーション・プロセス（ステップ１１８ないしステップ１２４）は、ルートＤＭＡがその子ａＤＭＡから勝利照会を受け取るまで、階層ＤＭＡツリーの最下部から最上部まで行われる。その後、ルートＤＭＡは、（所定の待ち時間内に）その子から受け取ったすべての勝利照会間のアービトレーションを行い、総合勝利照会を決定する。ｒＤＭＡは、総合勝利照会とその総合勝利照会を送った子ａＤＭＡとを含む、最終アービトレーション結果を生成する。

次に、トップダウン手法を使用して、最終アービトレーション結果が階層ＤＭＡツリーの下方に送られる。具体的には、ルートＤＭＡは、登録されている各子ａＤＭＡに最終アービトレーション結果を送り、各ａＤＭＡはアービトレーション結果をそれぞれのＳＴＨに格納する（ステップ１２５）。各親ａＤＭＡは、その親から返されたアービトレーション結果を調べ、（返されたアービトレーション結果に関連づけられた）ユーザ入力のための総合優勝照会が、親ａＤＭＡによるアービトレーションによって前に決定し（ステップ１２３）、それぞれのＳＴＨに格納された（ステップ１２６）勝利照会と一致するか否かを判断する。

返されたアービトレーション結果に基づいて、親ａＤＭＡが、親ａＤＭＡとその子のａＤＭＡのいずれも勝利者ではないと判断した場合（ステップ１２７の判断が否定）、親ａＤＭＡはそのＳＴＨをクリアし（ステップ１２８）、そのすべての子ａＤＭＡに敗者である旨を通知する（ステップ１２９）。一方、親ａＤＭＡが、総合優勝照会が、その親によって管理されている枝内のａＤＭＡに関連づけられており（ステップ１２７の判断が肯定）、親は勝者ではないがその子の１つが勝者であると判断した場合（ステップ１３０の判断が否定）、親ａＤＭＡは勝利した子ａＤＭＡに対して勝者である旨の通知を送り、他の子に対しては敗者である旨の通知を送る（ステップ１３１）。その後、親ａＤＭＡはそのＳＴＨをクリアする（ステップ１３２）。

ａＤＭＡが勝者である（すなわち、総合優勝照会を出力した）と判断した場合（ステップ１３０の判断が肯定）、そのａＤＭＡは、アプリケーションに関連づけられた、（照会をコールバック関数にマップする）コマンド・レジストリを使用して、総合優勝照会に関連づけられたコールバック関数を判断する（ステップ１３３）。次に、勝利ａＤＭＡは、コールバック関数を起動し、現行コールバックが戻されるまで、後続のコールバック関数の起動を遮断する（ステップ１３４）。

次に、図１０を参照して、コールバックが、出力応答を生成する要求を返した場合（ステップ１３５の結果が肯定）、ａＤＭＡはタスク・マネージャにgenerateOutputRequestを送り、タスク・マネージャが現行要求の結果を返すまで、それ以上の要求の送信を遮断する（ステップ１３６）。タスク・マネージャが、「OUTPUT_REQUEST_GENERATED」メッセージではない結果を返した場合（ステップ１３７の結果が否定）、そのエラーは、たとえば入力処理エラーに関して前述したように、しかるべく処理される（ステップ１３８）。一方、タスク・マネージャが「OUTPUT_REQUEST_GENERATEE」メッセージを返した場合（ステップ１３７の結果が肯定）、勝利ａＤＭＡは出力バッファの場所を親ａＤＭＡに送り、親ａＤＭＡはそれをＳＴＨに格納する（ステップ１３９）。出力バッファの場所は、その後、ツリーを遡ってルートＤＭＡに送られ、ルートＤＭＡは出力バッファ場所をＩ／Ｏマネージャに送る。

返されたコールバックが、（勝利ａＤＭＡに関連づけられた）アプリケーションがディクテーション・モードに入ることを示している場合、ディクテーション・プロセスがしかるべく処理される。ディクテーションのプロセスは、アプリケーションがどのようにプログラムされているかによって異なる。前述のように、アプリケーションの各ａＤＭＡがツリーを遡って通知を送り、ルートＤＭＡに、すべてのユーザ入力通知を勝利ａＤＭＡのみに送るように通知することが好ましい。さらに、アプリケーションは、ディクテーションを終了してすべてのＤＭＡに対する入力通知を再開する機構を備えることが好ましい。コールバック戻りが処理された後（ステップ１３９またはステップ１４２）、あるいはエラーが処理された後（ステップ１３８またはステップ１４１）、入力通知イベントに関連づけられたイベントのサブセットの記述を含むイベント記述が生成される（ステップ１４３）。前述のように、このイベントのサブセットは、たとえばＩ／Ｏ入力通知イベントと、照会オブジェクトと、親による応答とを含む。タスクが完了し、対話の新しい状態が開始すると、勝利ａＤＭＡのＳＴＨ内のイベントのサブセットが長期履歴（ＬＴＨ）内にプッシュされる。イベントのサブセットは、記述子オブジェクトの形でグループ化することができ、これにＩ／ＯトランザクションＩＤをタグとして付与して、ａＤＭＡのＬＴＨにプッシュし、その後、ａＤＭＡはそのＳＴＨをクリアする（ステップ１４４）。このＤＭＡプロセスは、次に続くユーザ入力について繰り返される（図７のステップ１０３に戻る）。

Ｉ／Ｏ管理
以下に、Ｉ／ＯマネージャおよびｒＤＭＡとの対話プロトコルの好ましい実施形態について詳述する。本発明の一実施形態では、Ｉ／Ｏはアプリケーション開発者が扱い、ＣＡＦはエンジン・アクセスとアービトレーションの制御のみを行うことを理解されたい。

他の実施形態では、Ｉ／ＯマネージャはＣＶＭ（ＣＡＦ）の構成要素であり、アプリケーション開発者は会話型アプリケーションと対話するために使用可能な装置／周辺機器の詳細を知る必要がない。好ましくは、本発明によるＩ／Ｏマネージャは、以下のような様々な検討材料に基づいて構築される。
１．アウトソーシングの容易さ：ＣＡＦ上のアプリケーションを作成するアプリケーション開発者に、アプリケーションの様々なモダリティをＣＡＦにフックする機構を提供する必要がある。一実施形態では、ＣＡＦはすべてのモダリティのための入出力マネージャを含む。他の実施形態では、ＣＡＦが指定されたタスク（すなわちアービトレーション、イベント格納など）を実行するのに必要なすべての情報を（任意のモダリティ・マネージャから）取り出すことができるように、（フォーカス更新、テキスト・フィールド値などの）エレメントの共通セットと、共通対話言語とを設けることができる。
２．アービトレーション：曖昧なユーザ入力（たとえば発話、注視など）を、アービトレーションのためにｒＤＭＡ階層に通す必要がある。本質的に曖昧でないユーザ入力モダリティ（たとえばＧＵＩ、Ｐｅｎなど）は、ユーザ入力を入力するためのフィールドが先験的に既知であるため、一般にはアービトレーションを必要としない。
３．ユーザ対話とすべてのＩ／Ｏイベントの記録：すべてのモダリティについてユーザ対話とＩ／Ｏイベントの記録を行い、ユーザ入出力のモダリティに関係なくすべてのアプリケーションにとってアクセス可能であることが好ましい。
４．基盤エンジンへのアクセス：ユーザ入力（出力生成も）がエンジン（音声認識、ペン認識、ＴＴＳなど）へのアクセスを必要とするモダリティの場合、ユーザ入力（または出力イベント）を適切なエンジンに送る機構が必要である。
５．同期：複数のモダリティを相補的に使用することができるようにする機構を備えることが好ましい。たとえば、ユーザがマウスをウィンドウに移動し、何かを発話してテキスト・フィールドに記入することがある。したがって、ＣＡＦを通る入力イベントにはタイムスタンプ（およびオリジンスタンプ）を付与し、反応を同期させる必要がある。
６．拡張性：本発明によるＣＡＦは、拡張可能なフレームワークを含む。したがって、好ましくは、ＣＡＦ（具体的にはＩ／Ｏ管理）は、フレームワークに新しいモダリティを容易に組み込むことができるようにする。
７．分散可能：ＣＡＦ構成要素（たとえばＩ／Ｏマネージャ）を分散させることができる。したがって、Ｉ／Ｏマネージャは、様々な供給源や様々なドメインまたはネットワークから発せられるユーザ対話を処理し、出力イベントを様々な装置またはモダリティに送ることができる必要がある。

本発明の一実施形態によるマルチモーダルＩ／Ｏマネージャは、一般に、ユーザ入力に作用し、入力モダリティに関係なく抽象化し、それらの抽象入力イベントを、ＣＡＦ ＤＭＡＦまたはその他のＣＡＦ構成要素（あるいは、ＣＡＦとは関係がなくてもよい他のアプリケーション）によってさらに処理するために送る。前述のように、入力イベントにはその発生元を識別する標識を付けて、そのイベントに対して行うべき処理の性質（たとえばイベントを一義化すべきか否かなど）を判断することができる。さらに、Ｉ／Ｏマネージャは、ＣＡＦ ＤＭＡＦ、他のＣＡＦ構成要素、または、ＣＡＦに関係のない他のアプリケーションから抽象出力イベントを受け取ることができる。Ｉ／Ｏマネージャは、抽象出力イベントを、１つまたは複数のチャネル（装置、モダリティなど）が認識可能かつ実行可能なコマンドに変換し、変換された抽象イベントを適切なチャネルに送る。

図１１に、本発明の一実施形態によるマルチモーダルＩ／Ｏ管理を行うシステムおよび方法を示す。マルチモーダルＩ／Ｏマネージャは、中央Ｉ／Ｏマネージャ２００と、中央Ｉ／Ｏマネージャ２００と動作可能に通信する複数のＩ／Ｏエージェント２０１、２０２（または「モダリティ・エージェント」）を含む。２つのＩ／Ｏエージェントは例示のために示すものであり、マルチモーダルＩ／Ｏマネージャは３以上のＩ／Ｏエージェントを含むことができることを理解されたい。中央Ｉ／Ｏマネージャ２００は、様々なモダリティＩ／Ｏエージェント２０１、２０２とＣＡＦ間の仲介役を果たす。各Ｉ／Ｏエージェント２０１、２０２は、中央Ｉ／Ｏマネージャ２００とのインタフェースと、サポートしている特定の装置のインタフェースの両方を実現する。各Ｉ／Ｏエージェントは、特定のモダリティを扱い、当該モダリティが認識するＡＰＩを介して当該モダリティからイベントを収集する機能を果たす。

具体的には、各Ｉ／Ｏエージェント２０１、２０２は、中央マネージャ２００と通信するためのインタフェースと、それぞれのデバイス・ドライバ２０１ｂ、２０２ｂと通信するためのインタフェース２０１ａ、２０２ａ（たとえば、ＧＵＩ用のアクセシビリティ（Accessibility）ＡＰＩ、ブラウザ用のＤＯＭ、通話用の電話ＡＰＩ）とを含む。各装置２０１ｃ、２０２ｃは、中央Ｉ／Ｏマネージャ２００に登録されて中央Ｉ／Ｏマネージャ２００と共通メッセージ交換プロトコルを使用して通信する、関連づけられたＩ／Ｏエージェント２０１、２０２を含む。中央Ｉ／Ｏマネージャ２００は他のＣＶＭ構成要素とのすべての通信を処理し、したがってＣＶＭプラットフォームは装置依存情報に対して保護されている。

各モダリティ・エージェントは、少なくとも、中央Ｉ／Ｏマネージャ２００にフォーカスの更新を送ることができることが好ましい。他のすべての送信可能イベントは、モダリティ・エージェントまたはアプリケーション開発者の裁量に委ねられていることが好ましい。これは、各イベントに付与される送信ＩＤタグについても同様である。ＩＤタグに加えて、デバイスのソケットのＩＰアドレスまたはその他のアドレス、ＵＲＩなど、その他の手段も使用することができる。さらに、ＣＡＦが中央Ｉ／Ｏマネージャ２００に送る出力イベントは、宛先アドレス（たとえばフォーカスまたはＩＤタグ）を含む。

モダリティ・エージェントと中央Ｉ／Ｏマネージャ２００との間の通信には共通交換プロトコルを使用することが好ましい。これにより、各モダリティ・エージェントは、好ましくは以下のものを送信することができる。すなわち、（ｉ）フォーカスの更新、（ｉｉ）入力通知イベント（およびストリームの場所などの付随情報）、（ｉｉｉ）ＤＭＡのスタックに格納されるＣＡＦ履歴レコードにラップされたイベント、（ｉｖ）出力通知／制御（およびストリーム場所などの付随情報）である。

各Ｉ／Ｏエージェント２０１、２０２は、中央Ｉ／Ｏマネージャ２００に登録する。通信中、中央マネージャ２００に入力イベントを送信するＩ／Ｏエージェントは、中央Ｉ／Ｏマネージャ２００に、当該入力イベントがエンジンのサポートを必要とすることを通知し、入力ストリームからデータを抽出する方法を指定することができる。さらに、出力イベントを受け取るＩ／Ｏエージェントは、エンジンのサポートを要求することができ、出力データをどのように供給する必要があるかを指定することができる。さらに、Ｉ／Ｏエージェントは、（発話の場合と同様）入力イベントのアービトレーションを要求することができ、それによって中央Ｉ／Ｏマネージャはアービトレーションのために入力通知イベントをｒＤＭＡ階層に通す。さらに、Ｉ／Ｏエージェントは、入出力を履歴に入れるように指定することができ、その場合、中央Ｉ／Ｏマネージャ２００は、対応するｒＤＭＡに特別なメッセージによって通知するか、または当該アプリケーションを扱うＤＭＡに直接通知することができる。さらに、フォーカスの更新の場合、中央Ｉ／Ｏマネージャ２００はｒＤＭＡに、フォーカスを更新して該当するＤＭＡに送るための特別な通知を送る。

中央Ｉ／Ｏマネージャ２００に送られるすべてのイベントにはタイムスタンプを付与して、複数のモダリティからのイベント間の同期をとることができるようにすることが好ましい。中央Ｉ／Ｏマネージャ２００は、ｒＤＭＡと通信し、様々なＩ／Ｏエージェントからメッセージを受け取る。新しいモダリティをサポートする必要がある場合、そのモダリティのためにモダリティ・エージェントを作成し、それ自体をＣＡＦ入出力マネージャに登録する必要がある。

さらに、Ｉ／Ｏエージェントはローカルとすることもでき、ネットワークに分散させることもできる。分散させた場合、通信と登録をサポートするために多くのプロトコルを使用することができる。たとえば、ＸＭＬプロトコル・スタックを実装することができる（たとえばＳＯＡＰ（Simple Object Access Protocol：簡易オブジェクト・アクセス・プロトコル）、ＵＤＤＩ（UniversalDescription, Discovery, and Integration：汎用的記述・発見・統合）、ＷＳＤＬ（Web ServicesDescription Language：ウェブ・サービス記述言語）など）（たとえばhttp://www.w3.org/2000/xp/参照）。さらに、前述の国際特許出願ＰＣＴ／ＵＳ９９／２２９２５号に記載されている通信プロトコルを実施して、ローカル・アプリケーションとリモート・アプリケーションの間で通信と登録を行うことができる。

本発明によるＩ／Ｏエージェントの様々な実施形態を実施することができる。たとえば、図１２は、本発明の一実施形態によるＩ／Ｏエージェントを示すブロック図である。図１２の例示の実施形態では、ＤＯＭ（ドキュメント・オブジェクト・モデル）（少なくともレベル２）インタフェースを呈示する既存のブラウザを使用してＩ／Ｏエージェントを実現している。ＤＯＭプロトコルは、当業界で周知である（http://www.w3.org/DOM/）。本発明で実施することができるモジュラＤＯＭベースのブラウザの好ましい実施形態は、２０００年１２月４日出願の米国特許仮出願第６０／２５１０８５号で開示されている。

具体的には、Ｉ／Ｏマネージャ２００は、Ｉ／Ｏマネージャ・インタフェース２０３とＤＯＭインタフェース２０４とを介して、Ｉ／Ｏエージェントとして機能する登録済みブラウザ２０５に関連づけられたＩ／Ｏイベントを受け取る。Ｉ／Ｏマネージャ２００は、ブラウザ２０５の状態と提示を更新するＤＯＭコマンドを介して、出力の変更と生成を行うことができる。この手法には、（少なくともＤＯＭレベル２に準拠していることを条件として）既存のブラウザを実装することができるという利点がある。ブラウザ２０５は、関連づけられたＩ／Ｏデバイス・ドライバ２０６およびそれに対応する周辺装置２０７とのより高レベルのインタフェースも提供する。また、ブラウザ２０５は、入出力を容易に処理することができる機能を含めて、より高レベルの抽象化も行うことができる。たとえば、音声ブラウザは、ある程度の音声認識を行い、Ｉ／Ｏマネージャにのみイベントをより高い抽象化レベルのイベントを渡すこともできる。したがって、出力コマンドもより高い抽象化レベルで生成することができ、それによって、たとえば、画面またはウィンドウを実際に描画したりテキスト−音声変換エンジンを微調整する代わりに、表示テキストまたはプロンプトが提供される。

Ｉ／ＯエージェントがＧＵＩモダリティ・エージェントを含むことを前提とすれば、Ｉ／Ｏエージェントはアプリケーションごとに１つの登録テーブルを維持することが好ましい。この場合、登録テーブルはアプリケーションがＣＡＦに登録したい各構成要素を含む。登録テーブル内の各構成要素について、ＧＵＩエージェントは、アクセシビリティ・インタフェース（accessibility interface）を使用して必要なイベントを獲得することが好ましい。開発者のアプリケーション構成要素は、アクセシビリティ・インタフェースを実現することになる。

Ｉ／Ｏエージェントがマルチモーダル・ブラウザを含むことを前提とすれば、ブラウザ・モダリティ・エージェントは、ＤＯＭインタフェースを使用して特定のイベントが発生していないかどうか監視し、そのようなイベントが発生したときに入力マネージャに通知するモジュールとして実施することが好ましい。マルチモーダル・ブラウザの場合、ブラウザがフリーフロー対話をサポートしていなければＣＡＦは不要である。そのような実施形態では、マルチモーダルＩ／Ｏマネージャを、モダリティ別のレガシー・ブラウザとマルチモーダル・シェルとの間に動作可能に接続される。ＣＡＦを使用する場合、マルチモーダルＩ／Ｏマネージャをマルチモーダル・シェルまたはＤＭＡＦに動作可能に接続することができる。Ｉ／Ｏエージェントを電話アプリケーション用に実施する場合は、電話モダリティＩ／Ｏエージェントが既存の電話ＡＰＩとインタフェースする。

さらに、Ｉ／Ｏマネージャの同じ概念を使用して、従来のＶｏｉｃｅＸＭＬブラウザからＶｏｉｃｅＸＭＬ ＤＯＭブラウザを構築することができ、その場合、Ｉ／ＯマネージャはＤＯＭインタフェースを提供し、従来のＶｏｉｃｅＸＭＬブラウザはＶｏｉｃｅエージェントである。

ブラウザを使用して上述した各実施形態は、宣言型、命令型、スクリプト型、またはこれらのハイブリッドな組合せを使用して実施することができることを理解されたい。たとえば、当技術分野で周知のＪａｖａ（Ｒ） Ａｃｃｅｓｓｉｂｉｌｉｔｙクラス／ユーティリティ（たとえばhttp://java.sun.com/products/jfc/#download-access）を使用してアプリケーションまたはアプレットをコンパイルする、Ｊａｖａ（Ｒ）を使用した命令型の場合が考えられる。ＤＯＭインタフェースの場合と同様、Ｊａｖａ（Ｒ） Ａｃｃｅｓｓｉｂｉｌｉｔｙ Ｕｔｉｌｉｔｙパッケージは、Ｊａｖａ（Ｒ）バーチャル・マシン上で動作しているＪａｖａ（Ｒ）アプリケーション内部のユーザ・インタフェース・オブジェクトの探索と照会を行う指示支援技術を提供する。また、これらのオブジェクトへの「イベント・リスナ」のインストールもサポートする。ユーティリティは、支援技術が、Ｓｗｉｎｇ構成要素に組み込まれたＡｃｃｅｓｓｉｂｉｌｉｔｙ ＡＰＩサポートと対話することができるようにする方法をハイライトした例示ツールを提供する。イベントを獲得し、ユーザ・インタフェース要素を操作することによって、同種のＩ／Ｏ管理を行うことができる。同様のユーティリティを備えるＡｃｔｉｖｅＸやＤＣＯＭなどの他のパッケージも使用可能である。

その他のどのようなインタフェース（ＤＯＭまたはアクセシビリティ）でも、新しいチャネル・タイプ（たとえば音声、手書きなど）に拡張することができる。同様の機能または能力を備えるその他のインタフェースまたはユーティリティも考えることができる。分散させた場合、ＳＯＡＰによってＤＯＭ（またはＤＯＭ同等物）の遠隔制御を実現することができる。ＳＯＡＰには、プログラム呼出しが、ファイヤウォールやゲートウェイを通過する可能性がはるかに高いというという利点がある。当然ながら、これらのインタフェースの遠隔制御を可能にするその他のプロトコルも使用可能である。

本明細書に記載の特徴および機構の全部または一部を使用して、さまざまな方式でその他の実施形態を実現可能であることを理解されたい。たとえば、２０００年４月７日出願の「A conversational Portal For Providing Conversational Browsing andMultimedia Broadcast on Demand」という名称の米国特許出願第０９／５４５０７８号に記載されているポータルのような音声または会話ポータルが考えられる。本発明の一実施形態による音声または会話ポータルを図１３に示す。この音声ポータルには、ポータル・ゲートウェイ３００を介してアクセスする。このポータルは、中央Ｉ／Ｏマネージャ３０１と、ポータルＣＡＦ３０２（ｒＤＭＡやタスク・マネージャなどのＣＡＦ構成要素を含む）と、ポータル・ブラウザ３０３と、複数のアプリケーションとを含み、各アプリケーションは、関連づけられたａＤＭＡ３０５、３０８とブラウザ３０６、３０９とを使用する。対応するアプリケーションに付随する会話サービスを提供する複数のエンジン３０４、３０７、３１０を使用する。

このポータルは、ユーザが対話したい各アプリケーションごとに１つのブラウザを含む。ポータル・アプリケーションへのアクセスは、電話番号（ポータルを介して提供される場合にアプリケーションにアクセスするための好適な番号）またはＵＲＬ（ＩＳＰまたはワイヤレス（従来のマルチチャネルまたはマルチモーダル）アクセス・プロバイダのゲートウェイ３００によってインタセプトされる）に基づくものとすることができる。ユーザは、たとえばユーザが購読しているアプリケーションのリスト、ユーザ参照またはユーザの過去の履歴、あるいは単にユーザとポータルとの対話の進展の結果に基づいてポータルによって提供される様々なアプリケーションと対話することができる。このような様々なアプリケーションおよびそれに対応するブラウザは、ポータル・サイト上のポータルによって提供されるのではなく、アプリケーション・プロバイダのサイトサイトに配置することができることを理解されたい。

アプリケーション・ブラウザ３０６、３０９がコンテキスト管理およびフリーフロー／主導権混在をサポートする場合、各ブラウザはａＤＭＡ３０５、３０８に動作可能に接続されるかまたはこれらを包含する。ブラウザが、（たとえば、現在、ＶｏｉｃｅＸＭＬ１．０（http://www.voiceXML.org）によってサポートされているような）文法ベースの対話のみをサポートする場合、アービトレーション・アルゴリズム（たとえばヒューリスティック）とａＤＭＡ機能を簡略化することができる。したがって、認識したテキストと、どの文法が高得点を挙げるかとに基づいて、ユーザ入力の宛先を判断することができる。文法が重なる場合は、何らかのヒューリスティクスを使用する必要がある（たとえばどのアプリケーションに現行フォーカスがあったかなど）。ＧＵＩチャネル（および、一般に、フォーカスが一義的なために別個の処理を必要としないチャネル）も、直接アービトレーション可能である。この場合、ユーザがクリックする場所がフォーカスのある可能性が最も高い場所である。入力が多義的な場合、ポータル・プロバイダはポータルｒＤＭＡ３０２を使用することができ、場合によっては、ポータル・ブラウザ３０３とポータルＣＡＦ３０２のａＤＭＡとを介して高レベルのサービスを提供することができる。

他の実施形態では、ユーザが（たとえば他方のアプリケーションへの明示的切換えコマンドを与えることによって）アプリケーション間の切換えをブラウザに明示的に指示しなければならないように、アプリケーション間の切換えを規制する。このコマンドは、ポータルａＤＭＡと、そのような指示を認識する、関連づけられたアプリケーションとによって管理される。たとえば、このようなコマンドは、go to financeXXXまたはtravelXXX siteのような特定のコマンドまたはキーワードとすることができる。この機構は、前述のような所与のアプリケーション内でディクテーション・モードに入るための機構と基本的に類似している。

最終的に、セキュリティ上の理由から、ポータル、ユーザ、およびアプリケーション提供者は、前述のようなサポートされているアプリケーション間でのユーザＩ／Ｏ（着信発話、発信発話）およびコンテキスト（長期および短期履歴）の共用を受け入れるか拒否するかを決定することもできる。

この例示の実施形態では、米国特許第０９／７０３５７４号に記載されているもののような適切な会話伝送プロトコルを使用して、音声（およびその他の可能なマルチモーダルまたはマルチモーダル・イベント）を各「アクティブ」ブラウザ（すべてのアクティブ・ブラウザまたは現在処理を共用しているアクティブ・ブラウザ）に転送することができる。

本明細書に記載のシステムおよび方法は、ハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、またはこれらの組合せの様々な形態で実施可能であることを理解されたい。具体的には、本発明は、プログラム記憶装置（たとえば磁気フロッピィ・ディスク、ＲＡＭ、ＲＯＭ、ＣＤ ＲＯＭなど）上に具現化され、適合するアーキテクチャを含む任意の装置または機械によって実行可能なプログラム命令を含むアプリケーションとして実施することが好ましい。さらに、添付図面に図示したシステム構成要素およびプロセス・ステップの一部はソフトウェアで実施することが好ましいため、システム・モジュール間の接続および図示されている方法の論理の流れは、本発明をプログラムする方式によって異なる場合があることを理解されたい。本明細書に記載の教示があれば、当業者は本発明の上記または類似の実施態様または構成を企図することができるであろう。

本明細書では、例示の実施形態について添付図面を参照しながら説明したが、本システムおよび方法は、これらの厳密な実施形態には限定されず、当業者なら本発明の範囲または主旨から逸脱することなく他の様々な変更および修正を加えることができるものと理解されたい。そのような変更および修正はすべて、特許請求の範囲に定義されている本発明の範囲に含まれるものとする。

本発明の一実施形態による会話型コンピューティングを提供するシステムを示す高水準ブロック図である。 本発明の一実施形態による会話型コンピューティングを提供するシステムを示す高水準ブロック図である。 本発明の一実施形態による階層的ＤＭＡ（対話マネージャおよびアービトレータ）を示すブロック図である。 本発明の一実施形態による、ＤＭＡストラクチャを使用して対話管理およびアービトレーションを行う方法の例を示すブロック図である。 本発明の一実施形態による、ＤＭＡによって維持される情報を示す図である。 本発明の一実施形態による、ＤＭＡを使用する会話型コンピューティング・システムを示す図である。 本発明の一態様による対話管理およびアービトレーションを行う方法を示す流れ図である。 本発明の一態様による対話管理およびアービトレーションを行う方法を示す流れ図である。 本発明の一態様による対話管理およびアービトレーションを行う方法を示す流れ図である。 本発明の一態様による対話管理およびアービトレーションを行う方法を示す流れ図である。 本発明の一実施形態によるマルチモーダル入出力管理を行うシステムおよび方法を示すブロック図である。 本発明の一実施形態によるマルチモーダル入出力マネージャの入出力エージェントを示すブロック図である。 本発明の一実施形態による音声ポータルを示すブロック図である。

Claims (20)

1. １つまたは複数のアプリケーションの対話を管理する方法であって、
   ルートＤＭＡ（対話マネージャおよびアービトレータ）インタフェースと１つまたは複数のアプリケーションＤＭＡとを含む階層ツリー構造を含むＤＭＡインタフェースをメモリ中に作成するステップと、
   前記ルートＤＭＡによってユーザ入力イベントの通知をアプリケーションＤＭＡに送るステップと、
   前記アプリケーションＤＭＡが前記ユーザ入力イベントの記号表現を入手するステップと、
   前記アプリケーションＤＭＡが前記記号表現のコンテキスト解決を行うアプリケーション・メソッドを呼び出すステップと、
   前記アプリケーションＤＭＡが、前記アプリケーションから前記コンテキスト解決の結果を含む照会を受け取るステップと、
   前記ＤＭＡインタフェースが、前記アプリケーションＤＭＡが受け取った前記照会に基づいて前記アプリケーションＤＭＡが現在アクティブであるか否かを判断するステップであって、ボトムアップ・アービトレーション・プロトコルを使用して、前記照会が他のアプリケーションＤＭＡが受け取ったすべての照会のうちで最高得点の照会であるか否かを判断するステップと、
   前記アプリケーションＤＭＡが現在アクティブであると判断された場合に、前記アプリケーションＤＭＡが前記照会に関連づけられたコールバック関数を起動するステップとを含む方法。
2. ＤＭＡインタフェースをメモリ中に作成する前記ステップが、アプリケーションが前記ルートＤＭＡに登録してアプリケーションＤＭＡハンドルを入手する登録ステップを含む、請求項１に記載の方法。
3. 前記登録ステップが、前記アプリケーションがユーザ入力を処理するために必要とするエンジンのセットと順序を含むアルゴリズム・ストリングを登録するステップを含む、請求項２に記載の方法。
4. ＤＭＡインタフェースをメモリ中に作成する前記ステップが、アプリケーションの主対話を管理するためにルートＤＭＡをメモリ中に作成するステップと、アプリケーション間または同一アプリケーション内の対話である前記アプリケーションの副対話を管理するために前記ルートＤＭＡの複数の子インスタンスをメモリ中に作成するステップとを含む、請求項１に記載の方法。
5. 前記アプリケーションが受け取ったセキュリティ設定に基づいて、親和アプリケーション間のアービトレーションを行う、請求項４に記載の方法。
6. ボトムアップ・アービトレーション・プロトコルを使用する前記ステップが、
   前記階層ツリー内の階層構造で上位のアプリケーションＤＭＡが、前記上位のアプリケーションＤＭＡの子であるアプリケーションＤＭＡから受け取った照会間のアービトレーションを行うステップと、
   前記ルートＤＭＡが、前記ルートＤＭＡの子であるアプリケーションＤＭＡから受け取った照会間のアービトレーションを行って最高スコアの照会があるか否かを判断するステップとを含む、請求項４に記載の方法。
7. 親ＤＭＡが、所定時間内に照会を供給しない子ＤＭＡを無視するステップと、
   子ＤＭＡからの要求に応じて前記所定の時間を延長するステップとをさらに含む、請求項６に記載の方法。
8. 前記ルートＤＭＡが前記最高スコアの照会と関連づけられたアプリケーションＤＭＡとを含むアービトレーション結果を生成するステップと、階層構造で上位のアプリケーションＤＭＡが、前記上位のアプリケーションＤＭＡの子に前記アービトレーション結果の通知を送るステップとをさらに含む、請求項６に記載の方法。
9. 前記コールバック関数を起動する前記ステップが、コマンド・レジストリを使用して、前記照会に関連づけられた前記コールバック関数を判断するステップを含む、請求項１に記載の方法。
10. 前記記号表現が、音声認識結果と自然言語理解結果とこれらの組合せとのうちの１つを含む、請求項１に記載の方法。
11. 前記ＤＭＡインタフェースがユーザ入力イベントに関連づけられたイベントを含む短期履歴を維持するステップをさらに含む、請求項１に記載の方法。
12. 前記ＤＭＡインタフェースが実行済みタスクに関連づけられたイベントの長期履歴を維持するステップをさらに含む、請求項１に記載の方法。
13. 前記ＤＭＡインタフェースが対話セッション中にアクティブなアプリケーションＤＭＡを追跡するフォーカス履歴を維持するステップをさらに含む、請求項１に記載の方法。
14. アプリケーションとアプリケーションＤＭＡとが協同して、前記短期履歴と前記長期履歴と前記フォーカス履歴の照会を一義化するステップをさらに含む、請求項１１〜１３に記載の方法。
15. 前記短期履歴と前記長期履歴と前記フォーカス履歴とこれらの組合せとのうちの１つを使用して、照会を一義化するステップをさらに含む、請求項１４に記載の方法。
16. ユーザにメッセージを提示しなければならない場合、適切なモダリティでメッセージを生成するステップをさらに含む、請求項１に記載の方法。
17. 適切なモダリティでメッセージを生成する前記ステップが、モダリティ固有Ｉ／Ｏエージェントによってモダリティ独立出力イベントをモダリティ固有出力イベントに変換するステップを含む、請求項１６に記載の方法。
18. 前記コールバック関数がディクテーション・モードを含む場合、前記ルートＤＭＡにすべての入力イベントを前記アプリケーションＤＭＡに送るように通知する、請求項１に記載の方法。
19. ユーザ入力コマンドに応答して前記ディクテーション・モードを終了させるステップをさらに含む、請求項１８に記載の方法。
20. アプリケーションの対話を管理するためのプログラムであって、該プログラムがコンピュータに、
    ルートＤＭＡ（対話マネージャおよびアービトレータ）インタフェースと１つまたは複数のアプリケーションＤＭＡとを含む階層ツリー構造を含むＤＭＡインタフェースをメモリ中に作成するステップと、
    前記ルートＤＭＡによってユーザ入力イベントの通知をアプリケーションＤＭＡに送るステップと、
    前記アプリケーションＤＭＡが前記ユーザ入力イベントの記号表現を入手するステップと、
    前記アプリケーションＤＭＡが前記記号表現のコンテキスト解決を行うアプリケーション・メソッドを呼び出すステップと、
    前記アプリケーションＤＭＡが、前記アプリケーションから前記コンテキスト解決の結果を含む照会を受け取るステップと、
    前記ＤＭＡインタフェースが、前記アプリケーションＤＭＡが受け取った前記照会に基づいて前記アプリケーションＤＭＡが現在アクティブであるか否かを判断するステップであって、ボトムアップ・アービトレーション・プロトコルを使用して、前記照会が他のアプリケーションＤＭＡが受け取ったすべての照会のうちで最高得点の照会であるか否かを判断するステップと、
    前記アプリケーションＤＭＡが現在アクティブであると判断された場合に、前記アプリケーションＤＭＡが前記照会に関連づけられたコールバック関数を起動するステップ、
    を実行させる、プログラム。

Images