JP2006252553A - セマンティクスドリブンダイアログとステートドリブンダイアログとを混在させる開発フレームワーク - Google Patents

Abstract

【課題】セマンティクスドリブンダイアログとステートドリブンダイアログとを混在させるための改良された開発フレームワークを提供すること。
【解決手段】１つまたは複数のコンピュータ可読媒体上で実施されるアプリケーションプログラムインターフェースを提供する。このインターフェースは、アプリケーション内での第１のタイプのダイアログの開発を容易にするように構成された、第１のダイアログコンテナを含む。さらに、このインターフェースは、そのアプリケーション内での第２のタイプのダイアログの開発を容易にするように構成された、第２のダイアログコンテナを含む。
【選択図】図３

Description

本発明は、一般に、開発者が所与のアプリケーションの中に異種ダイアログを効率的に混在させることを可能にする開発フレームワークに関する。より詳細には、本発明は、セマンティクスドリブンダイアログとステートドリブンダイアログの両方を組み込んだアプリケーションの開発に関する。

音声ユーザインターフェース（ＶＵＩ）によるユーザ対話をサポートするアプリケーションは、当該技術分野においてよく知られている。開発プロセス中には、これらのタイプのアプリケーションを、基本リソースへのアクセスを与える下位アプリケーションプログラムインターフェース（ＡＰＩ）フレームワークの上に作成することが可能である。たとえば、電話アプリケーションは、電話インフラストラクチャ、音声認識リソース、音声合成リソースなどのリソース（ただし、これらだけに限定されるとは限らないリソース）のサポートを含む下位ＡＰＩフレームワークの上に作成されることが知られている。

アプリケーション開発者から見ると、上述の下位ＡＰＩリソースを直接扱うコードを作成する作業は、一般に、比較的退屈であり、労力のかかるものである。上位コンストラクトは、下位リソースに、より直観的なインターフェースを与えることが知られている。場合によっては、上位コンストラクトは、下位ＡＰＩリソースへのインターフェースとして動作して、アプリケーションコード生成の簡略化を可能にするＡＰＩフレームワークの形で、ダイアログオーサリングモデルを作成するためのベースとして利用されている。上位ＡＰＩフレームワークに含まれるオブジェクトは、様々に異なる開発体験をサポートするように構成されている。

開発プロセスの成果は、様々に異なる可能な形式のうちの１つにおいてユーザとシステムとのダイアログを推進するアプリケーションを作成することである。いくつかのダイアログは、システムドリブン（システム主導）ダイアログであろう。このタイプのダイアログの一例では、電話アプリケーションと対話するユーザに対し、「マイサポートアプリケーションへようこそ。お持ちの製品の識別番号を入力してください」という音声ステートメントが提示される。このケースでは、一般に、要求されたタスクが完了されるまで（すなわち、有効な製品識別番号が入力されるまで）何もアクションが実行されない。システムは、特定の情報を（ときには特定の形式で）要求する。したがって、システムドリブンダイアログは、一般に、非常に強制的である。

いくつかのダイアログは、ユーザドリブン（ユーザ主導）ダイアログであろう。このタイプのダイアログの一例では、電話アプリケーションと対話するユーザに対し、「マイサポートアプリケーションへようこそ。何かお困りですか」という音声ステートメントが提示される。このタイプのステートメントへの応答では、ユーザは一般に、「マシンの調子が悪い」や「製品を返品したい」など、なんでも言うことが可能である。これに対し、システムは、ユーザの問い合わせの本質を識別し、それに応じた応答（たとえば、「受領書はお持ちですか」）を行うように構成されている。システムは、ユーザの問い合わせの中の重要情報を特定し、それに応じて応答する。

セマンティクスドリブンダイアログをサポートする開発フレームワークは、一般に、システムドリブンよりはユーザドリブンである。セマンティクスドリブンダイアログの部分を作成する場合、開発者は一般に、複数のフィールドのうちのどのフィールドに入力してもらいたいかを、システムユーザから適切な情報を取得することによって指定する。セマンティクスドリブン形式は、いくつかの点で、ユーザが特定のフィールドに入力するグラフィカルユーザインターフェース（ＧＵＩ）アプリケーションの形式とよく似ている。あらかじめ決められたフィールドのパス（Ａ→Ｂ→Ｃなど）を指定するのではなく、他のフィールドの個々のステート（状態）に応じて動作するために、特定のダイアログノードまたはエレメントを指定する。たとえば、フィールドＣが空の場合には、ある特定のダイアログノードＡをアクティブとするように指定する。依存が複数であることも可能である。たとえば、フィールドＡ、Ｂ、Ｃが空であって、フィールドＥが入力および確認されていれば、ある特定のダイアログノードをアクティブとするように指定することが可能である。いくつかのフィールドを、その内容でよいかどうかをシステムユーザが確認することを必要とするように設定することが可能である。次にどの（１つまたは複数の）ダイアログノードをアクティブにするかについては、ユーザとマシンとのすべての対話の後に、セマンティクスドリブンダイアログフレームワークの中で決定する。

ステートドリブンダイアログをサポートする開発フレームワークは、一般に、ユーザドリブンよりはシステムドリブンである。ステートドリブンダイアログプロセス内での対話フローは、セマンティクスドリブンダイアログによる対話より多く、あらかじめ決められている。決定は、一般に、あるエレメントから次のエレメントへの、あらかじめ決められたパスに従う。たとえば、第１の特定のアイテムの情報を要求したとする。応答して、ユーザから情報を受け取る。受け取った情報が信頼できるかどうかを評価する。信頼できない場合は確認プロセスを実行する。信頼できる場合は、システムは、あらかじめ決められた第２のアイテムの情報を要求する。

ステートドリブンダイアログでは、一般に、システムによって現在要求されているより多くの情報を先回りして出す方法がない。システムは、次に何を行うかを、ステップごとにほとんど決定する。一般に、開発者は、ステートドリブンダイアログをフローチャートの形でグラフィカルに表現する。ステートドリブンダイアログは、セマンティクスドリブンダイアログと異なり、ユーザが入力した内容に応じてあちこちにジャンプすることがない。

下位ＡＰＩリソースへのインターフェースを与えるものとして前述した上位ＡＰＩフレームワークは、セマンティクスドリブンダイアログを主にサポートするように構成することが可能である。これにより、開発者は、非常に柔軟で自然なダイアログを作成することが可能である。そのような構成の弱点は、単純なシステムドリブンダイアログの作成が比較的難しい作業になることである。

代替として、上位ＡＰＩを、ステートドリブンダイアログを主にサポートするように構成することが可能である。現在では、ダイアログステートを条件にリンクさせることが容易になっている（たとえば、ステートＡを終了した後、どの条件が真かを評価し、そのパスに従って次のステートへ進むようなことが容易に可能である）。このタイプのダイアログの開発は、可視化およびオーサリングが容易である。しかしながら、得られるダイアログがアプリケーションユーザにとって自然でも柔軟でもないという弱点がある。

本発明の実施形態は、１つまたは複数のコンピュータ可読媒体において実施されるアプリケーションプログラムインターフェースに関する。このインターフェースは、アプリケーション内での第１のタイプのダイアログの開発を容易にするように構成された、第１のダイアログコンテナを含む。さらに、このインターフェースは、そのアプリケーション内での第２のタイプのダイアログの開発を容易にするように構成された、第２のダイアログコンテナを含む。

Ｉ．例示的環境
本発明の実施形態を詳細に説明するのに先立って、実施形態と関連のシステムとを実装することが可能な例示的コンピューティング環境について説明する。

図１は、本発明の実施形態と関連のシステムとを実装するのに好適なコンピューティング環境の例１００を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の用途または機能性の範囲を何ら限定するものではない。コンピューティング環境１００は、図示されたコンポーネントの任意の１つまたは組み合わせに関連する何らかの依存性または要件を有するものと解釈されてはならない。

本発明は、他の多くの、汎用または専用のコンピューティングシステム環境または構成で動作する。本発明での使用に好適であると考えられる、よく知られたコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、電話システム、これらのシステムまたは機器を任意に含む分散コンピューティング環境などがあるが、これらに限定されない。

本発明は、コンピュータによって実行される、コンピュータで実行可能な命令（プログラムモジュールなど）の一般的文脈の形で説明されることが可能である。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれ、これらは、特定のタスクを実行したり、特定の抽象データ型を実装したりする。本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境において実施されるように設計される。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方の、メモリストレージ装置を含むコンピュータストレージ媒体に配置される。以下では、プログラムおよびモジュールによって実行されるタスクについて、図面を参照しながら説明する。当業者であれば、それらの説明および図面を、任意の形式のコンピュータ可読媒体に書き込むことが可能な、プロセッサで実行可能な命令として実装することが可能であろう。

図１に示すように、本発明を実装する例示的システムは、コンピュータ１１０の形の汎用コンピューティング装置を含む。コンピュータ１１０のコンポーネントとして、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む各種システムコンポーネントを処理ユニット１２０に接続するシステムバス１２１があるが、これらに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および様々なバスアーキテクチャを任意に使用するローカルバスを含む、様々なタイプのバス構造のどれであってもよい。限定ではなく例示として、そのようなアーキテクチャには、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、Ｍｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスなどがある。

コンピュータ１１０は一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によるアクセスが可能であって、揮発性および不揮発性媒体の両方、リムーバブルおよび非リムーバブル媒体の両方を含む、任意の市販媒体であってよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータストレージ媒体および通信媒体を含むことが可能である。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、他のデータなどの情報を記憶する任意の方法またはテクノロジに実装される揮発性および不揮発性媒体の両方、リムーバブルおよび非リムーバブル媒体の両方を含む。コンピュータストレージ媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなどのメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）などの光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージなどの磁気ストレージ装置、または他の任意の、必要な情報を格納するために用いられることが可能であってコンピュータ１１０によるアクセスが可能である媒体があり、これらに限定されない。

通信媒体は、一般に、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータを、搬送波のような変調データ信号または他の伝送メカニズムの形で実現し、任意の情報配信媒体を含む。「変調データ信号」という用語は、１つまたは複数の特性が、信号に情報を符号化するように設定または変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体と、音響、ＲＦ、赤外線などの無線媒体とを含む。上述の媒体の任意の組み合わせも、コンピュータ可読媒体の範囲に含まれる。

システムメモリ１３０は、読み出し専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータストレージ媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動時などのコンピュータ１１０における要素間情報転送を支援する基本ルーチンを含み、一般にＲＯＭ １３１に格納される。ＲＡＭ １３２は、一般に、処理ユニット１２０からのアクセスがただちに可能であるか、かつ／または処理ユニット１２０によって現在操作中であるデータおよび／またはプログラムモジュールを格納する。限定ではなく例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０はさらに、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体を含むことも可能である。限定ではなく例として、図１は、非リムーバブル、不揮発性磁気媒体の読み出しおよび書き込みを行うハードディスクドライブ１４１、リムーバブル、不揮発性磁気ディスク１５２の読み出しおよび書き込みを行う磁気ディスクドライブ１５１、およびリムーバブル、不揮発性光ディスク１５６（ＣＤ−ＲＯＭや他の光媒体など）の読み出しおよび書き込みを行う光ディスクドライブ１５５を示している。例示的運用環境での使用が可能な他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体として、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあり、これらに限定されない。ハードディスクドライブ１４１は一般に、インターフェース１４０のような非リムーバブルメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェース１５０のようなリムーバブルメモリインターフェースによってシステムバス１２１に接続される。

前述の、図１に示したドライブおよび関連するコンピュータストレージ媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、および他のコンピュータ１１０用データの記憶領域を提供する。図１では、たとえば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するように示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、ここでは、少なくとも異なるコピーであることを示すために、異なる参照符号が与えられている。

ユーザは、コマンドや情報をコンピュータ１１０に入力するために、キーボード１６２、マイク１６３、ポインティングデバイス１６１（マウス、トラックボール、タッチパッドなど）のような入力装置を用いることが可能である。他の入力装置（図示せず）として、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらの入力装置や他の入力装置は、多くの場合、システムバスに接続されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、他のインターフェースやバス構造（パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など）によって接続されることも可能である。モニタ１９１や他のタイプのディスプレイ装置も、ビデオインターフェース１９０のようなインターフェースを介してシステムバス１２１に接続される。コンピュータは、モニタ以外にも、スピーカ１９７やプリンタ１９６など、他のペリフェラル出力装置を含むことが可能であり、それらは出力ペリフェラルインターフェース１９５を介して接続されることが可能である。

コンピュータ１１０は、リモートコンピュータ１８０のような１つまたは複数のリモートコンピュータとの論理接続を用いて、ネットワーク環境で動作する。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルド機器、サーバ、ルータ、ネットワークＰＣ、ピア装置、他の一般的なネットワークノードなどであることが可能であり、一般に、コンピュータ１１０に関して前述された要素のほとんどまたはすべてを含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むことも可能である。そのようなネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットではごく普通である。

コンピュータ１１０は、ＬＡＮネットワーキング環境で使用される場合には、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ １７１に接続される。コンピュータ１１０は、ＷＡＮネットワーキング環境で使用される場合には、一般に、ＷＡＮ １７３（インターネットなど）での通信を確立するためにモデム１７２または他の手段を含む。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インターフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続されることが可能である。ネットワーク環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部は、リモートメモリストレージ装置に格納されることが可能である。限定ではなく例として、図１は、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０に常駐している様子を示している。図示されたネットワーク接続は例示的であって、コンピュータ間の通信リンクを確立する他の手段も利用可能であることを理解されたい。

本発明は、図１に関連して説明したようなコンピュータシステムで実行可能であることに注意されたい。しかしながら、本発明は、サーバ、メッセージハンドリング専用コンピュータ、または本発明の様々な部分が分散コンピューティングシステムの様々な部分において実行される分散システムで実行可能である。

ＩＩ．例示的システム環境
例示を目的とするために、本発明の実施形態を、電話アプリケーションの文脈で説明する。しかしながら、本発明の範囲は狭くはなく、実施形態は、あらゆる音声指向アプリケーションの文脈に適用可能である。

電話アプリケーションは、プレゼンテーション層と論理＋データ層とを含む多層システムと見ることが可能である。プレゼンテーション層は、一般に、音声出力および音声入力を用いて最終ユーザと対話することを担当する。システムによっては、ＧＵＩのような補助出力手段や、デュアルトーンマルチ周波数（ＤＴＭＦ）入力メカニズムのような補助入力手段が組み込まれる。一般に、プレゼンテーション層は、音声ユーザインターフェース（Ｖｏｉｃｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＶＵＩ）を提供する。論理＋データ層は、一般に、基本となるビジネスルールとデータのアクセスおよび記憶を担当する。論理＋データ層は、論理＋データ層へのインターフェースとしてＡＰＩ一式を用意していることが知られているが、さらに、ＶＵＩのオーサリングのための柔軟なＡＰＩフレームワークが必要である。

図２は、システムアーキテクチャ２００の上位特性を示す概略ブロック図である。アーキテクチャ２００の最上位は、アプリケーション（ユーザコード）２０２を含む。これは、具体的には、ダイアログを実現するために開発者によって作成されるコードである。アーキテクチャ２００の最下位は、コアＡＰＩフレームワーク２０６を含む。このコアフレームワーク２０６は、具体的には、システムリソースへのアクセスを提供する。たとえば、コアフレームワークは、具体的には、電話ＡＰＩ、シグナリングＡＰＩ、ＤＴＭＦ ＡＰＩ、音声認識ＡＰＩ、音声合成ＡＰＩ、および／または他の任意のシステムリソースインターフェースを含む。

矢印２０８で示されるように、コード２０２は、コアフレームワーク２０６のコンポーネントに直接命令するように構成されることが可能である。この開発方法は、開発者から見て、比較的退屈であり、労力のかかるものである場合がある。そうした開発負担を緩和するために、ダイアログＡＰＩフレームワーク２０４が、アプリケーション２０２とコアフレームワーク２０６との間に位置している。フレームワーク２０４は、フレームワーク２０６より上位のＡＰＩアプローチを提供する。したがって、矢印２１０および２１２に示されるように、フレームワーク２０４を直接呼び出して、それに対応する、フレームワーク２０６のコンポーネントへの呼び出しが行われるようにするユーザコード２０２を作成することが可能である。このように、開発者は、より生産的な様式でダイアログを作成することが可能である。一実施形態によれば、開発者の生産性のさらなる向上を可能にするために、ダイアログＡＰＩフレームワーク２０４の上にツール（図示せず）が構築される。このツールは、上位ＡＰＩフレームワークに対する開発者のオーサリング能力を促進させ強化する。

したがって、アーキテクチャ２００は、２つの層を有するＶＵＩ開発環境を提供する。１つの層は、様々な電話シナリオのオーサリングに十分な下位音声層であり、もう１つの層は、上位抽象を作成することによって開発者の生産性を向上させるように構成された上位ダイアログ層である。

ＩＩＩ．ダイアログＡＰＩフレームワーク
図２ではさらに、ダイアログＡＰＩフレームワーク２０４が、任意の様々なタイプのダイアログをサポートするように構成されることが可能である。たとえば、フレームワーク２０４は、セマンティクスドリブンダイアログが主に組み込まれるアプリケーション２０２の作成を容易にするように構成されることが可能である。あるいは、フレームワーク２０４は、ステートドリブンダイアログが主に組み込まれるアプリケーション２０２の作成を容易にするように構成されることが可能である。しかしながら、上位開発インターフェースを提供しようとする、既知の数々の試みは、セマンティクスドリブンダイアログとステートドリブンダイアログの両方が組み込まれるアプリケーションの効率的な作成をサポートすることに、おおむね失敗している。本発明の一態様によれば、ダイアログＡＰＩフレームワーク２０４（および任意選択で、１つまたは複数の関連開発ツール）は、セマンティクスドリブンダイアログとステートドリブンダイアログとが混在するアプリケーション２０２の効率的な開発を容易にするように構成される。セマンティクスドリブンダイアログとステートドリブンダイアログの開発を混在させるための同じスキームを使用し、本発明の範囲から逸脱することなく、ダイアログタイプの任意の組み合わせを混在させる開発を可能にすることができることに留意されたい。

図３は、本発明の一態様による、ダイアログＡＰＩフレームワーク（たとえば、図２のフレームワーク２０４）の一部３０４の概略ブロック図である。ダイアログタイプが混在するオーサリングシステムをサポートする場合、図示されたフレームワーク３０４は、セマンティクスドリブンダイアログコンテナ３０６とステートドリブンダイアログコンテナ３０８とを含む。各タイプのコンテナが１つずつある場合を図示しているが、具体的な開発スキームに応じて、いずれかが複数であってもよい。複数あるダイアログコンテナおよびそれらの内容の間の機能的関係については、説明が進むにつれて明らかになるであろう。

ダイアログコンテナ３０６および３０８は、それぞれ、複数のダイアログエレメント３１０を含む。図示したダイアログエレメントのすべてを指すのに同じ参照符号を用いているが、ダイアログエレメントの性質は１つ１つ異なることが可能であることを理解されたい。一実施形態によれば、各ダイアログコンテナは、それに収容されているダイアログエレメントの起動を制御するように構成される。コンテナ３０６は、セマンティクスドリブンダイアログを収容および実現するように構成され、コンテナ３０８は、ステートドリブンダイアログを収容および実現するように構成される。

一実施形態によれば、すべてのダイアログコンテナが、ダイアログエレメントの役割も受け入れるように構成される。たとえば、ダイアログコンテナは、具体的には、別のダイアログコンテナの中でダイアログエレメントとして動作することが可能である。言い換えると、ダイアログコンテナは、ダイアログコンテナを実質的に収容することが可能である。そのような仕組みは、開発に柔軟性を与える。本発明の一態様によれば、説明されているフレームワークは、開発者の選択に応じて、セマンティクスドリブン、ステートドリブン、または両者の混在となるようにアプリケーション全体が設計されることを可能にする。一般に、ダイアログエレメントをどのように編成および接続するかは開発者の自由裁量であり、その結果として、ダイアログコンテナは、使用可能なダイアログエレメントの１つの特定の組み合わせとなる。後述するように、開発者は、広い範囲のダイアログエレメントを、特化されたＡＰＩの形で利用することが可能であり、それらに対応する様々な範囲の特化機能が得られる。

本発明の一態様によれば、上位ＡＰＩのレベルには（すなわち、図２のフレームワーク２０４のレベルには）、個々のダイアログエレメント、セマンティクスドリブンダイアログ、およびすべてのタイプのダイアログをサポートするインフラストラクチャのサポートが存在する。一実施形態では、このＡＰＩレベルはさらに、ステートドリブンダイアログのサポートを含む。しかしながら、別の実施形態では、ステートドリブンダイアログの明示的なサポートは、開発を容易にするために、ＡＰＩフレームワークの上に構築されるツールコンポーネントに組み込まれる。ツールとＡＰＩとの境界を操作して任意の様々に異なる個々の実装を可能にすることが本発明の範囲内であることに注意されたい。そのような構成はすべて、本発明の範囲内である。

説明されている開発フレームワークに関連する別の利点は、ダイアログエレメントが一般に、セマンティクスドリブンダイアログコンテナ内またはステートドリブンダイアログコンテナ内で動作するか、独立に動作するように設計されることである。様々なタイプのダイアログエレメントの詳細説明に先立って、セマンティクスドリブンダイアログとステートドリブンダイアログとを混在させるアプリケーションの開発の様子を例として紹介する。

形式が混在するダイアログの開発の一例では、開発者はまず白紙のキャンバスを用意し、そこに、順に実行される連続したダイアログコンポーネント群を表す３つのノードを加える。開発者は、第１のノードにドリルダウンし、「ようこそ」などのステートメントを挿入する。ステートメントは、セマンティクスドリブンダイアログの複雑な機能を必要としない単純なダイアログコンポーネントである。第１のノードの１つのオプションは、ステートドリブンコンテナを作成し、その中にステートメントエレメントを配置することである。一実施形態では、開発プラットフォームは、どのタイプのコンテナも作成せずにステートメントの確定を可能にするように構成される。

第２のノードは、具体的には、ユーザ情報を収集するプロセスを容易にするものとする。開発者には、収集する情報の性質に応じて様々な選択肢がある。開発者は、ステートドリブン情報収集プロセス（たとえば、「お持ちの製品のＩＤ番号をお知らせください」・・・「このアイテムの購入年月日をお知らせください」・・・など）を推進するエレメントを有するステートドリブンコンテナを作成することが可能である。あるいは、開発者は、セマンティクスドリブン情報収集プロセス（たとえば、「どちらさまでしょうか」・・・「すみません、名字をお知らせください」・・・「かしこまりました。ご用件を承ります」・・・など）を推進するエレメントを有するセマンティクスドリブンコンテナを作成することが可能である。

設計者には、第３のノード（具体的には、実行される機能をユーザが選択することを可能にするノード）をどのように設計するかについて、同様の選択肢がある。たとえば、選択するオプションのメニューのようなステートドリブンシナリオをユーザに提示することが可能である。あるいは、ユーザが自分の選択を声で伝え、システムがそれに応答するというセマンティクスドリブンの方法を用いて意志決定をさせることが可能である。

本発明の一態様によれば、ダイアログＡＰＩフレームワークは、アプリケーション開発者が利用できるように用意されたダイアログエレメントの形で複数のＡＰＩオブジェクトを含む。前述のように、ダイアログコンテナは、一種のダイアログエレメントであり、特定タイプのダイアログの開発および実行を容易にするように構成される。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、Ｓｔａｔｅｍｅｎｔエレメントがある。Ｓｔａｔｅｍｅｎｔエレメントは、具体的には、開発者によって任意のタイプのコンテナに配置されることや、コンテナの外で機能することが可能である。Ｓｔａｔｅｍｅｎｔエレメントは、ユーザからの返答を期待しないステートメントが行われることを可能にする。例として、「ようこそ」プロンプトや、「終了します」プロンプトや、「エラーが発生しました」プロンプトなどがある。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントがある。ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントは、具体的には、いずれのタイプのコンテナからでも動作可能である。ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントの一般的な機能は、ユーザからの応答を取得しようとすることである。一実施形態では、このエレメントは、やりとりが失敗した場合に再度尋ねるように構成される（たとえば、「すみません。よく聞き取れませんでした。もう一度お願いできますか」）。別の実施形態では、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントは、誤認識を扱うように装備される（たとえば、「すみません。うまく認識できませんでした。もう一度お願いできますか」）。このエレメントは、誤認識が発生した場合にユーザに対して何らかの誘導を行うように構成されることが可能である（たとえば、「すみません。１〜１０の範囲の数をお願いします」）。

一実施形態では、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントは、音声認識に続く後処理が容易になるように構成される。たとえば、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントは、セマンティクスドリブンコンテキストにおいて（たとえば、セマンティクスドリブンコンテナの中から）用いられた場合には、ユーザ応答から重要部分を抽出して、必要に応じてフィールドを埋める処理を推進する。一実施形態では、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントの後処理機能は、エレメントがセマンティクスドリブンコンテキストにおいて用いられている場合にはオプションではない。これに対し、ステートドリブンコンテキストにおいては、後処理はオプションであってもよい。

一実施形態では、後処理機能をサポートするために、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメント内でプロパティが設定されることが可能である（たとえば、フィールドＡ、Ｂ、Ｃが埋められた場合には、Ｘ後処理が行われる、など）。ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントをセマンティクスドリブンダイアログコンテキストに埋め込むためには、後処理機能を支援するいくつかのプロパティ値を入力しなければならない。一実施形態では、ステートドリブンダイアログコンテキストにＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントが埋め込まれていると、開発者が選択すれば後処理が利用可能になるが、これは必須ではない。

たとえば、ユーザが「終了」と言うとシステムが「本当に停止しますか」と応答するシナリオがあるとする。ユーザが「はい」または「いいえ」と応答した後、その応答を後で何かに利用するために保存しておくことは、おそらく必要ではない。したがって、対応するプロパティを設定し、その状況下で対応する後処理ステップを指定することは、一般に不要である。その代わりに、開発者は、ステートドリブンコンテキスト内にＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントを埋め込み、認識完了後にユーザ入力を取り込んでそれに応答するようにそのエレメントを構成することが可能である。そのようなステートドリブン対話を推進することは、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントの機能のうちである。ただし、ステートドリブンダイアログコンテキスト内であっても、後続のダイアログに利用するために入力を取り込むことは有用である場合がある。一実施形態では、そのような場合に、後処理を利用してフィールドを直接埋めるようにシステムが構成される。

一実施形態によれば、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメントは、起動時にＭａｉｎＰｒｏｐｍｐｔを再生し、音声および／またはＤＴＭＦをリスンし、複数の音声またはＤＴＭＦ文法をサポートし、プロンプト再生中にリスンし（またはリスンせず）、プロンプトの一部が再生された後にリスンを開始して標準ＤｉａｌｏｇＥｌｅｍｅｎｔ（後述）のように動作し、有効な認識結果が検出されるまでプロンプトを出し続け、ＨｅｌｐコマンドおよびＲｅｐｅａｔコマンドを処理するようにプロンプトを適合させ、無言または無認識を処理するようにプロンプトを適合させ、ＦｏｒｍＦｉｌｌｉｎｇＤｉａｌｏｇをサポートし、結果をＳｅｍａｎｔｉｃＩｔｅｍｓにバインドするメカニズムをエクスポーズし、ＳｅｍａｎｔｉｃＩｔｅｍの認識を自動化し、かつ／または、セマンティックバインディングを調べてＦｏｒｍＦｉｌｌｉｎｇＤｉａｌｏｇの起動を決定するように構成される。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、ＳｅｍａｎｔｉｃＩｔｅｍエレメントがある。ＳｅｍａｎｔｉｃＩｔｅｍエレメントは、一般にセマンティクスドリブンコンテキストにおいてフォームフィールドをサポートするクラスを提供する。これらのフォームフィールドは、セマンティクスドリブンダイアログプロセス中に埋められるフィールドである。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、ＦｏｒｍＦｉｌｌｉｎｇＤｉａｌｏｇエレメントがある。ＦｏｒｍＦｉｌｌｉｎｇＤｉａｌｏｇエレメントは、セマンティクスドリブンダイアログを駆動し、フィールドを埋める関連プロセスをサポートするコンテナである。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、ＲｅｃｏｒｄＳｏｕｎｄエレメントがある。ＲｅｃｏｒｄＳｏｕｎｄエレメントは、具体的には、いずれのタイプのコンテナからでも動作可能であり、独立でも動作可能である。ＲｅｃｏｒｄＳｏｕｎｄエレメントの一般的機能は、（たとえば、認識機能を何ら実行することなく）ユーザから録音を取得することである。そのようなエレメントは、ボイスメールや他の同様な用途の文脈において有用である。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、Ｃｏｍｍａｎｄエレメントがある。Ｃｏｍｍａｎｄエレメントは、具体的には、いずれのタイプのコンテナからでも動作可能であり、独立でも動作可能である。Ｃｏｍｍａｎｄエレメントの一般的機能は、アプリケーションのメインフローとはおおむね無関係であるユーザ入力の取り込みをサポートすることである。たとえば、Ｃｏｍｍａｎｄエレメントは、ユーザがメインダイアログから抜け出る方法として「オペレータ」などのコマンドを言うことを可能にするように実装されることが可能である。一実施形態では、コマンドは、キーを押す（たとえば、「０」キーを押す）ことのように口頭でないことが可能である。一実施形態では、Ｃｏｍｍａｎｄエレメントは、あらゆる場合に適用されるように（たとえば、「オペレータ」がダイアログ中の任意のタイミングで認識されるとエクステンション０が転送されるように）、ダイアログアプリケーションの最上位に作成される。別の実施形態では、Ｃｏｍｍａｎｄエレメントは、コンテキストにおいてアクティブであるか、範囲ごとにアクティブであるように作成されることが可能である。エレメントは、具体的には、全範囲でアクティブであるか、条件付きの範囲でアクティブ（たとえば、特定のコンテナにおいてのみアクティブ）であることが可能である。したがって、範囲は、具体的には、特定のダイアログエレメントほどに小さいことも、全アプリケーションほどに大きいことも可能である。したがって、Ｃｏｍｍａｎｄエレメントは一般に、ダイアログフローによってではなく、範囲またはダイアログ領域によって起動される。

別の実施形態によれば、フレームワーク内で与えられる新たなタイプのダイアログエレメントとして、Ａｐｐｌｉｃａｔｉｏｎエレメントがある。Ａｐｐｌｉｃａｔｉｏｎエレメントは、特定のダイアログアプリケーションの最上位コンテキストとして動作する。これは一般に、最上位コンテナのインスタンスを生成する。Ａｐｐｌｉｃａｔｉｏｎエレメントの一般的機能は、全般的に対話のための、ならびに、フレームワーク内でエレメント間に発生する下位対話のためのガイドラインを確立することである。Ａｐｐｌｉｃａｔｉｏｎエレメントの役割は非常に多岐にわたるが、それらには、自動電話応答、呼の拒否、呼の終了、呼の進行状況の追跡、特定のインバウンド呼およびアウトバウンド呼機能の専用サポート、および接続エラーの処理を含む、電話アプリケーションの様々な態様をサポートする基本ステップの実装が含まれることが可能である。

フレームワーク内には、他のダイアログ機能の実装を支援する追加ヘルパーオブジェクトがあることを理解されたい。ほとんどのエレメントは、いずれのタイプのコンテナからでも動作可能であり、独立でも動作可能である。無言、誤認識、認識不能応答（たとえば、認識不能な言語での応答）、正しくない応答などのような例外を処理するために、様々なエレメントが構成されている。そのようなエレメントは、個々の例外の性質に応じてどのようなダイアログが実行されるべきかを確定するために用いられる。

一実施形態では、システムは、対応するテキストがあらかじめ決定されている限り、プロンプト選択を自動的にサポートする（すなわち、ＰｒｏｍｐｔＳｅｌｅｃｔｉｏｎエレメントを利用する）ように構成される。ＨｉｓｔｏｒｙＩｔｅｍエレメントなどのエレメントは、実行時に何が起きているかを調べるために利用される。同様に、Ｌｏｇｇｉｎｇエレメントは、実行時に何が起きているかを追跡することを支援する（たとえば、ＡＰＩは、確立されたロギング構造体にデータを与える）。Ｈｉｓｔｏｒｙｌｔｅｍエレメントを用いると、ユーザが消えた場合（たとえば、質問を４回実行しても応答が無く無言であるか、認識不能な応答があった場合）のような異常な状況への適切な応答として、Ｂａｉｌ−Ｏｕｔエレメントの実施を推進することが可能である。

本発明のユニークな一態様によれば、ダイアログＡＰＩアプローチがコンテナレベルで実装される。説明されている子エレメントまたは他の子エレメントは、コンテナが機能を子エレメントにまかせることが可能であるように、ダイアログコンテナ内に埋め込まれたロジックをサポートする。ここまで述べてきたように、ダイアログコンテナ内のダイアログエレメントは、実質的に別のダイアログコンテナになることも可能である。所与のコンテナの内容にかかわらず、ダイアログコンテナ内のダイアログエレメントは、セマンティクスドリブンダイアログまたはステートドリブンダイアログなどであるがこれらに限定されない特定のダイアログタイプをサポートするように構成される。

コンテナには、そのダイアログエレメントを適正な順序で起動するために必要な情報が供給される。この順序は、少なくとも部分的には、セマンティクスドリブンダイアログ、ステートドリブンダイアログなどのあらかじめ決められたストラテジを適用するように構成されているか、別のストラテジを適用するように構成されているかの観点で、特定のコンテナの性質によって決定される。本発明の一実施形態では、任意のダイアログストラテジをその子ダイアログエレメントに実装するために新しいダイアログコンテナを作成することが可能である。

一実施形態によれば、説明されているダイアログＡＰＩフレームワークは、あるレベルのコーディングの自動化をサポートするツールの作成をサポートするように構成されている。ＡＰＩとツールのペアは、具体的には、（特に、下位リソースに対して直接コーディングを行う場合と比較して）開発者の生産性を強化する。

本発明の一態様によれば、説明されているダイアログＡＰＩフレームワークに従って開発されたダイアログアプリケーションは、一番上のノードがアプリケーション自体であるツリーとして見ることが可能である。アプリケーションは、一式のコンポーネントの上に構築され、それらのコンポーネント間のフローを管理する。それらのコンポーネントは、また、他のコンポーネントの上に構築されることが可能である。ツリーのリーフノードには、最小の、最も基本的なダイアログコンポーネントがある。説明されている構造は、サブダイアログの再利用と、あらかじめパッケージされたアプリケーションおよびコンポーネントの作成とを効率的にサポートする。

各コンポーネントは、その子コンポーネント間の「フロー」を管理する。フローの性質は、（セマンティクスドリブンダイアログまたはゴールドリブンダイアログにおける場合のように）比較的動的であるか、比較的手続き的である。どの場合でも、コンポーネントを起動することは、具体的には、コンポーネントに「ジョブの実行」を試行させ、ジョブが完了したか、何らかのエラーが発生した場合に呼び出し側（親）に報告させることを含む。そのとき、他の子を有するコンポーネントが、起動直後に、第１の子が起動されるのを認識し、それが完了するまで待機したり、次にどの子を動作させるかを決定したりする。

「フロー」では完全には作成できないダイアログシナリオがある場合があるが、そのようなシナリオではコンテキスト変更を直接要求する。そのような対話は、フローの割り込みとアプリケーション内の別のタスクへのジャンプであると見なすのがよいであろう。一実施形態では、それらの割り込みは、ユーザが特定のコマンドを口頭で伝えることによってトリガされる。そのコマンドが認識されると、コンテキストの変更が行われ、新しいタスクが実行される。

これまで述べてきたように、ダイアログＡＰＩフレームワークは、具体的には、２つの主要タイプのオブジェクト、すなわち、ＤｉａｌｏｇＥｌｅｍｅｎｔおよびＤｉａｌｏｇＣｏｎｔａｉｎｅｒをサポートする。主要アプリケーションは、具体的にはＤｉａｌｏｇＣｏｎｔａｉｎｅｒであり、派生によって新しいＤｉａｌｏｇＣｏｎｔａｉｎｅｒが定義され、新しいコンテナごとに新しいクラスが定義される。これらのコンテナのインスタンスが実行時に作成され、実行される。このモデル内のサブダイアログは、（サブルーチン呼び出しではなく）コンポーネントの再利用と見なすことが可能である。

一実施形態では、ＤｉａｌｏｇＣｏｎｔａｉｎｅｒは、技術的には他のＤｉａｌｏｇＣｏｎｔａｉｎｅｒを直接は含まないが、他のダイアログコンテナを「呼び出す」。これは、具体的には、ＤｉａｌｏｇＲｅｆｅｒｅｎｃｅプリミティブまたはエレメントを用いることによって達成される。ＤｉａｌｏｇＲｅｆｅｒｅｎｃｅは、具体的には、任意のＤｉａｌｏｇＣｏｎｔａｉｎｅｒを参照できるプロパティをエクスポーズするので、実行時にインスタンスを作成されることが可能である。参照されたＤｉａｌｏｇＣｏｎｔａｉｎｅｒは、その実行を完了すると、具体的には、それのインスタンスを作成したＤｉａｌｏｇＲｅｆｅｒｅｎｃｅに通知する。親ＤｉａｌｏｇＣｏｎｔａｉｎｅｒは、その後、フローを通常どおりに再開することが可能である。

一実施形態では、ＤｉａｌｏｇＥｌｅｍｅｎｔは、実行を開始するメソッドをエクスポーズし、実行を中止／キャンセルするメソッドをエクスポーズし、非同期に実行し、それ以上動作しなくなった場合はアプリケーションに通知し、動作しない理由（完了された、キャンセルされた、エラーになった、など）をアプリケーションに通知し、それらが起動された時点でアプリケーションに通知し、Ａｐｐｌｉｃａｔｉｏｎオブジェクトへのアクセス（および、それゆえに関連のシグナリングＡＰＩおよび統一されたＡＰＩへのアクセス）を有するように構成される。ＤｉａｌｏｇＥｌｅｍｅｎｔｓは、具体的には構成可能であって、構成された場合にその親へのアクセスを有する。

本発明の一態様によれば、説明されたダイアログＡＰＩフレームワークの機能性をエクスポーズするために、任意のオーサリング環境を提供することが可能である。そのようなオーサリング環境は、ＡＰＩのみ、ＡＰＩ＋ツール、ツールのみ、または他の任意の、本発明の範囲から逸脱しない実装であることが可能である。

特定の実施形態を参照しながら本発明について説明してきたが、当業者であれば、本発明の趣旨および範囲から逸脱することなく、形態および細部に変更を施すことが可能であることを理解されよう。

本発明を実施することが可能な一例示的環境のブロック図である。 システムアーキテクチャの上位特性を示す概略ブロック図である。 ＡＰＩフレームワークの一部の概略ブロック図である。

Claims (20)

1. １つまたは複数のコンピュータ可読媒体上で実行されるアプリケーションプログラムインターフェースであって、
   アプリケーション内での第１のタイプのダイアログの開発を容易にするように構成された、第１のダイアログコンテナと、
   前記アプリケーション内での第２のタイプのダイアログの開発を容易にするように構成された、第２のダイアログコンテナと
   を備えることを特徴とするアプリケーションプログラムインターフェース。
2. 前記第１および第２のダイアログコンテナ内のどちらからでも動作するように構成された少なくとも１つのダイアログエレメントをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラムインターフェース。
3. 前記第１のタイプのダイアログは、セマンティクスドリブンダイアログであるかステートドリブンダイアログであることを特徴とする請求項１に記載のアプリケーションプログラムインターフェース。
4. 下位システムリソースへのインターフェースとして動作するコアＡＰＩフレームワークをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラムインターフェース。
5. 自身と対話するための開発フレームワークを提供するツールをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラムインターフェース。
6. 前記第１および第２のダイアログコンテナには、前記コンテナに収容されるダイアログエレメントの起動をサポートする情報が供給されることを特徴とする請求項１に記載のアプリケーションプログラムインターフェース。
7. 開発者がアプリケーション内に異なるタイプのダイアログを混在させることを可能にする、コンピュータに実装される方法であって、
   前記アプリケーション内で第１のタイプのダイアログの開発を容易にするように構成された第１の開発リソースを提供すること、および
   前記アプリケーション内で第２のタイプのダイアログの開発を容易にするように構成された第２の開発リソースを提供する
   ことを含むことを特徴とする方法。
8. 前記第１および第２の開発リソースのどちらとも関連して動作するように構成された少なくとも１つの開発リソースを提供することをさらに含むことを特徴とする請求項７に記載の方法。
9. 第１の開発リソースを提供することは、セマンティクスドリブンダイアログの開発を容易にするように構成された第１のダイアログコンテナを提供することを含むことを特徴とする請求項７に記載の方法。
10. 第２の開発リソースを提供することは、ステートドリブンダイアログの開発を容易にするように構成された第２のダイアログコンテナを提供することを含むことを特徴とする請求項９に記載の方法。
11. 前記第１または第２のダイアログコンテナ内のどちらからでも動作するように構成された少なくとも１つのダイアログエレメントを提供することをさらに含むことを特徴とする請求項１０に記載の方法。
12. 前記第１のダイアログコンテナのインスタンスが前記第２のダイアログコンテナのインスタンス内から動作可能であるか、前記第２のダイアログコンテナのインスタンスが前記第１のダイアログコンテナのインスタンス内から動作可能であるように、前記第１および第２の開発リソースを構成することをさらに含むことを特徴とする請求項１０に記載の方法。
13. 前記ダイアログエレメントは、Ｓｔａｔｅｍｅｎｔエレメント、ＱｕｅｓｔｉｏｎＡｎｓｗｅｒエレメント、ＳｅｍａｎｔｉｃＩｔｅｍエレメント、ＦｏｒｍＦｉｌｌｉｎｇＤｉａｌｏｇエレメント、ＲｅｃｏｒｄＳｏｕｎｄエレメント、Ｃｏｍｍａｎｄエレメント、およびＡｐｐｌｉｃａｔｉｏｎエレメントからなる群から選択されるエレメントを含むことを特徴とする請求項１２に記載の方法。
14. 前記群から選択される少なくとも１つのエレメントは、前記第１および第２の開発リソース内のどちらからでも動作可能であることを特徴とする請求項１３に記載の方法。
15. 下位システムリソースへのインターフェースとして動作するコアＡＰＩフレームワークへのアクセスを前記第１および第２の開発リソースに提供することをさらに含むことを特徴とする請求項７に記載の方法。
16. 開発者がアプリケーション内に異なるタイプのダイアログを混在させることを可能にするダイアログシステムであって、複数のダイアログエレメントを収容するダイアログコンテナを含み、前記ダイアログコンテナが、ダイアログストラテジに従って前記複数のダイアログエレメントの処理を容易にするように構成されることを特徴とするダイアログシステム。
17. 前記第１のダイアログコンテナに収容された第２のダイアログコンテナをさらに含み、前記第２のダイアログコンテナは第２の複数のダイアログエレメントを収容し、第２のダイアログストラテジに従って前記第２の複数のダイアログエレメントの処理を容易にするように構成され、前記第２のダイアログストラテジは前記第１のダイアログストラテジと異なることを特徴とする請求項１６に記載のダイアログシステム。
18. 前記第１および第２のダイアログストラテジのうちの一方がセマンティクスドリブンダイアログであり、もう一方がステートドリブンダイアログであることを特徴とする請求項１７に記載のダイアログシステム。
19. 前記ダイアログストラテジはカスタム定義ストラテジであることを特徴とする請求項１６に記載のダイアログシステム。
20. 前記ダイアログストラテジの少なくとも一部は前記開発者によって構成されることを特徴とする請求項１６に記載のダイアログシステム。
    

Images