(57)【要約】  ボイスアプリケーション創出および配置システムが統合された行為適応エンジンが、データに添付された音声ファイルを含むＸＭＬベースクライアント対話データを受信するための少なくとも１つのデータ入力ポートと、外部データシステムおよびモジュールにデータを受信し、かつそれからデータを受信するための少なくとも１つのデータポートと、受信されたデータを処理するためのＸＭＬ読取装置、ボイスプレーヤ、および分析装置を含む論理処理構成要素と、１つまたは複数の制約に対して結果データを処理するための決定論理構成要素とを有する。エンジンは、提供されるボイスアプリケーションとのクライアント対話からのダイアログを含むクライアントデータを実時間で傍受し、行為パターン、および添付されていれば音声ファイルのボイス特徴について受信データを処理し、その際に、エンジンは、結果および１つまたは複数の有効な制約に従って、対話中にクライアントに戻される可能な企業応答の１つまたはセットを識別する。【特許請求の範囲】
【請求項１】
ボイスアプリケーション創出および配置システムであって、
ボイスアプリケーションをデータネットワーク上でクライアントに提供するためのボイスアプリケーションサーバと、
データネットワークへのアクセスを有し、かつボイスアプリケーションとのクライアント対話を容易にするための少なくとも１つのボイスポータルノードと、
アプリケーションサーバから実行可能な行為適応エンジンとを備え、
行為適応エンジンが、提供されたアプリケーションとのボイス対話中にクライアント応答を傍受し、既存制約および受信したクライアント情報に従って、行為パターンおよびムード状態の１つまたは組合わせについてクライアント応答を分析し、クライアントに実演される次の企業応答を創出するために、連結または挿入可能選択肢を含めて可能なダイアログ応答のセットのどれが、ＶＸＭＬページレンダリングに提出されるかを決定することを特徴とするシステム。
【請求項２】
データネットワークが、インターネットネットワークである、請求項１に記載のシステム。
【請求項３】
データネットワークが、インターネットと電話ネットワークとの組合わせである、請求項１に記載のシステム。
【請求項４】
行為適応エンジンが、ボイスアプリケーションサーバのアプリケーション論理の一部である、請求項１に記載のシステム。
【請求項５】
少なくとも１つのボイスポータルが、電話サーバと組み合わされた対話ボイス応答システムである、請求項１に記載のシステム。
【請求項６】
少なくとも１つのボイスポータルが、インターネットへのアクセスを有するデータネットワークに接続された計算ノードである、請求項１に記載のシステム。
【請求項７】
行為適応エンジンが、音声ファイルを分析し、該音声ファイルが、少なくとも１つのボイスポータルにおいて記録され、かつクライアント応答に添付されたデジタル音声ファイルとしてアプリケーションサーバに送信される、請求項１に記載のシステム。
【請求項８】
行為適応エンジンが、トリガ事象を受信すると実行される、請求項１に記載のシステム。
【請求項９】
制約が、メニューナビゲーション行為、またはクライアントの知覚されたムード状態の１つまたは組合わせに関係付けられる、請求項１に記載のシステム。
【請求項１０】
ダイアログ応答および連結された選択肢が、データストアに記憶され、かつ行為適応エンジンにアクセス可能である、請求項１に記載のシステム。
【請求項１１】
受信されたクライアント情報が、線識別、番号識別、クライアント履歴データ、ボイスインプリント結果、および記録ボイスサンプルの１つまたは組合わせを含む、請求項１に記載のシステム。
【請求項１２】
ボイスサンプリングが、ムードを識別するために使用される、請求項１に記載のシステム。
【請求項１３】
受信クライアント情報が、応答を決定するために、ボイス分析と関連して使用される、請求項１に記載のシステム。
【請求項１４】
行為適応エンジンが、クライアントのムード認識を容易にするために、サンプリングされた音声のボイス抑揚変化および音量特徴を検出する、請求項１に記載のシステム。
【請求項１５】
対話の変化および音量特徴が、企業応答確率値の評価に使用される統計を展開するために、同じアプリケーションとの複数対話にわたって収集される、請求項１４に記載のシステム。
【請求項１６】
ボイスアプリケーション創出および配置システムと統合される行為適応エンジンであって、
データに添付された音声ファイルを含めてＸＭＬベースクライアント対話データを受信するための少なくとも１つのデータ入力ポートと、
外部データシステムおよびモジュールにデータを送信し、かつ外部データシステムおよびモジュールからデータを受信するための少なくとも１つの双方向データポートと、
受信データを処理するためのＸＭＬ読取装置およびボイスプレーヤならびに分析装置を含む論理処理構成要素と、
１つまたは複数の制約に対して結果データを処理するための決定論理構成要素とを備え、
行為適応エンジンが、提供されたボイスアプリケーションとのクライアント対話からのダイアログを含めて、クライアントデータを実時間で傍受し、行為パターン、および添付されていれば音声ファイルのボイス特徴について受信データを処理し、その際に、行為適応エンジンが、結果および１つまたは複数の制約に従って、対話中にクライアントに戻される可能な企業応答の１つまたはセットを識別することを特徴とするエンジン。
【請求項１７】
行為適応エンジンが、ボイスアプリケーションサーバにホストされる、請求項１６に記載のエンジン。
【請求項１８】
サーバが、インターネットネットワークにホストされる、請求項１７に記載のエンジン。
【請求項１９】
ボイスアプリケーションおよび配置システムが、ボイスアプリケーションへのクライアントアクセスを容易にするために、少なくとも１つのボイスポータルを含む、請求項１６に記載のエンジン。
【請求項２０】
行為適応エンジンが、トリガ事象を受信すると機能するように実行される、請求項１６に記載のエンジン。
【請求項２１】
制約が、メニューナビゲーション行為またはクライアントの知覚されたムード状態の１つまたは組合わせに関係付けられる、請求項１６に記載のエンジン。
【請求項２２】
外部データリソースからのデータが、決定処理のための追加の入力データとして使用される、請求項１６に記載のエンジン。
【請求項２３】
受信されたクライアントデータが、線識別、番号識別、クライアント履歴データ、およびボイスインプリント結果の１つまたは組合わせを含む、請求項１６に記載のエンジン。
【請求項２４】
ボイスサンプリングが、ムード状態を識別するために使用される、請求項１７に記載のエンジン。
【請求項２５】
ボイス分析装置が、クライアントのムード認識を容易にするために、サンプリングされた音声のボイス抑揚変化および音量特徴を検出する、請求項１６に記載のエンジン。
【請求項２６】
対話の変化および音量特徴が、企業応答確率値の評価に使用される統計を展開するために、同じアプリケーションとの複数対話にわたって収集される、請求項２５に記載のエンジン。
【請求項２７】
ボイスアプリケーションとのクライアント対話から得られるデータ入力に対する、複数のボイスアプリケーションダイアログ応答の適切な１つまたはセットを識別するための方法であって、
（ａ）ボイスアプリケーションの実行中にデータ入力を受信することと、
（ｂ）データ入力を解釈することと、
（ｃ）１つまたは複数の制約の有効性について入力を分析することと、
（ｄ）分析された結果を追加の外部データと比較することと、
（ｅ）１つまたは複数の制約の続行有効性について比較結果を分析することと、
（ｆ）有効な制約に従って、１つまたは複数の利用可能な応答選択肢を識別することとを含む方法。
【請求項２８】
ボイスアプリケーションが、ＶＸＭＬコンプライアントである、請求項２７に記載の方法。
【請求項２９】
ステップ（ａ）において、データ入力が、クライアント識別データ、クライアントダイアログデータ、およびダイアログからサンプリングされたデジタル音声を含む、請求項２７に記載の方法。
【請求項３０】
ステップ（ｄ）および（ｅ）が、随意選択ステップである、請求項２７に記載の方法。
【請求項３１】
ステップ（ｃ）において、制約の有効性が、クライアントのムード状態決定の表示となる、請求項２７に記載の方法。
【請求項３２】
ステップ（ｃ）において、制約の有効性が、クライアントの行為状態決定の表示となる、請求項２７に記載の方法。
【請求項３３】
ステップ（ｃ）において、制約の有効性が、クライアントのムード状態および行為状態の両方の表示となる、請求項２７に記載の方法。
【請求項３４】
ステップ（ｄ）において、外部データが、同じアプリケーションの同じダイアログとの過去の対話から得られる統計データを含む、請求項２７に記載の方法。
【請求項３５】
ステップ（ｆ）において、１つまたは複数の利用可能な応答選択肢の識別が、選択をさらに処理して狭めるために、１つまたは複数の応答選択肢を外部モジュールに提出することを含む、請求項２７に記載の方法。
【請求項３６】
外部モジュールが、テキストツースピーチプレプロセッサである、請求項３５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウエアアプリケーション展開の分野についてであり、具体的には、行為適応エンジンを使用するＶＸＭＬアプリケーション配置アーキテクチャに分散されるボイスアプリケーションと対話するユーザの行為特徴を認識するための方法および装置に関する。
【０００２】
本発明は、米国特許出願公開第１０／１９００８０号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｉｍｐｒｏｖｉｎｇ  Ｖｏｉｃｅ  ｒｅｃｏｇｎｉｔｉｏｎ  ｐｅｒｆｏｒｍａｎｃｅ  ｉｎ  ａ  ｖｏｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｓｙｓｔｅｍ」、２００２年７月２日出願の一部係属として優先権を主張し、これは、米国特許出願公開第１０／１７３３３３号、名称「Ｍｅｔｈｏｄ  ｆｏｒ  Ａｕｔｏｍａｔｅｄ  Ｈａｒｖｅｓｔｉｎｇ  ｏｆ  Ｄａｔａ  ｆｒｏｍ  Ａ  Ｗｅｂ  ｓｉｔｅ  ｕｓｉｎｇ  ａ  Ｖｏｉｃｅ  Ｐｏｒｔａｌ  Ｓｙｓｔｅｍ」、２００２年６月１４日出願の一部係属であり、これは、米国特許仮出願第６０／３０２７３６号に対する優先権を主張する。本出願は、参照によって上記に記述された出願全体に対する優先権を主張する。
【背景技術】
【０００３】
スピーチアプリケーションは、通信（通常は電話）環境において展開、配置、および維持することが最も課題であるアプリケーションの１つである。実現可能なアプリケーションを展開および配置するために必要な専門知識は、コンピュータ電話統合（ＣＴＩ）ハードウエアおよびソフトウエア、ボイス認識ソフトウエア、テキストツースピーチソフトウエア、およびスピーチアプリケーション論理の専門知識を含む。
【０００４】
ボイス拡張マークアップ言語（ＶＸＭＬ）が比較的最近に出現したので、スピーチソリューションを展開するために必要な専門知識は、いくらか低減されている。ＶＸＭＬは、ソフトウエアデベロッパが、基本となる電話構成要素を構成することを必要とせずに、ボイスアプリケーションのアプリケーション論理に集中することを可能にする言語である。通常、展開されたボイスアプリケーションは、ソリューションを送達するために、関連する電話システムに存在して実行されるＶＸＭＬインタプリタで実行される。
【０００５】
図１Ａ（従来の技術）に示されるように、ＶＸＭＬコンプライアント電話システムの通常のアーキテクチャが、ボイスアプリケーションサーバ（１１０）およびＶＸＭＬコンプライアント電話サーバ（１３０）を備える。ＶＸＭＬ可能ＩＶＲソリューションを展開および配置する通常のステップが、図１Ａの要素を使用して以下において簡潔に記述される。
【０００６】
第１に、新しいアプリケーションデータベース（１１３）が創出される、または既存のアプリケーションデータベースが、ＶＸＭＬを支援するように修正される。アプリケーション論理１１２が、ワークフローについて設計され、ＩＶＲシステムの経路指定オペレーションに対処するように構成される。機能しているアプリケーション論理の結果であるＶＸＭＬページが、規定された生成シーケンスに基づいて、ＶＸＭＬレンダリングエンジン（１１１）によってレンダリングされる。
【０００７】
第２に、対応するＶＸＭＬページを備えるサーバ１３０に対するオブジェクトの外見が創出され、インターネット、イントラネット、またはイーサネット（登録商標）のネットワークとすることができるネットワーク（１２０）上においてサーバ１３０に送信される。ＶＸＭＬページは、サーバ１１０において設定ワークフローに従って表示することができるように、レンダリングエンジン１１１に統合される。
【０００８】
第３に、ＶＸＭＬ電話サーバ１３０は、サーバ１１０内のレンダリングエンジン１１１から特定のＶＸＭＬページを適切に取り出すことを可能にするように構成される。トリガ事象が起きるとき、適切なアウトバウンドコールがサーバ１１０から配置されるように、トリガ機構が、サーバ１１０に提供される。
【０００９】
ＶＸＭＬインタプリタ（１３１）、ボイス認識テキストツースピーチエンジン（１３２）、および電話ハードウエア／ソフトウエア（１３３）が、サーバ１３０内に提供され、サーバ機能を備える。従来の技術では、電話ハードウエア／ソフトウエア１３０は、ＶＸＭＬインタプリタ１３１と共に、既製のＩＶＲ可能技術として実装される。しかし、おそらくは、システム全体の最も重要な特徴は、アプリケーションサーバ１１０である。アプリケーション論理（１１２）は、通常、ジャバなどのプログラミング言語で書かれ、企業ジャバビーンアーカイブとして実装される。必要なプレゼンテーション論理は、レンダリングエンジン１１１によって対処され、ＪＳＰまたはＰＥＲＬで書かれる。
【００１０】
改良ボイスアプリケーションシステムが、本発明者に知られており、本出願が優先権を主張する米国特許出願、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｅｖｅｌｏｐｍｅｎｔ  ａｎｄ  Ｄｅｐｌｏｙｍｅｎｔ  ｏｆ  ａ  Ｖｏｉｃｅ  Ｓｏｆｔｗａｒｅ  Ａｐｐｌｉｃａｔｉｏｎ  ｆｏｒ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ｔｏ  ｏｎｅ  ｏｒ  ｍｏｒｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｓｕｍｅｒｓ」において開示されている。このシステムは、ボイスアプリケーションを記憶および提供するために、データネットワークに接続されているボイスアプリケーションサーバを使用する。ボイスアプリケーションサーバは、よく知られているＰＳＴＮネットワークなどの通信ネットワークに接続されたネットワーク通信サーバへのデータ接続を有する。通信サーバは、創出されたボイスアプリケーションを意図した受信者に経路指定する。
【００１１】
コンピュータ局が、システムの一部として提供され、データネットワークに接続され、かつボイスアプリケーションサーバへのアクセスを有する。クライアントソフトウエアアプリケーションが、ユーザがアプリケーションを創出して、その状態を管理することを可能にするために、コンピュータ局にホストされる。このシステムでは、ユーザは、オブジェクトのモデリングおよび連結により、ボイスアプリケーションを創出するために、コンピュータ局にホストされるクライアントソフトウエアを動作する。アプリケーションは、創出された後、配置のためにアプリケーションサーバに記憶される。ユーザは、意図した受信者についてのスケジュールされた配置および繰返し配置を含めて、配置および配置されたアプリケーションの状態を制御し、かつ管理することができる。
【００１２】
一実施形態では、システムは、１人または複数の受信者に対して、通信ネットワーク上でウエブベースデータをソースデータとして使用して、ボイスアプリケーションを展開および配置するように構成される。改良システムは、ソフトウエアおよびネットワーク接続により、ネットワークサーバおよび内部にホストされるウエブサイトにアクセスすることができ、かつサイトからデータを取り出すためのボイスアプリケーションサーバを有する。ボイスアプリケーションソフトウエアを実行するコンピュータ局は、少なくともボイスアプリケーションサーバへの制御アクセスを有し、ネットワークサーバおよびウエブサイトにアクセスすることもできる。コンピュータ局のオペレータが、データツーボイスレンダリングにおいて使用するために、ボイスアプリケーションサーバのテンプレートを創出して提供する。この態様において、ウエブデータは、ウエブベースデータソースから取り入れることができ、ボイスアプリケーションにおいてダイアログとして送達されるようにボイスに変換されることができる。
【００１３】
他の実施形態では、ダイアログの創出が実施される前に、ウエブベースデータを組織、編集、および優先順位付けする方法が、上記で記述されたシステムにおいて利用可能である。方法は、ウエブベースデータソースを元の構造の形態で取り入れることと、取り入れられたウエブベースデータソースの論理構造および内容タイプを表すオブジェクトツリーを生成することと、生成されたオブジェクトツリーを望ましい階層構造および内容に加工することと、ボイスアプリケーションテンプレートをＶＸＭＬで創出して、テンプレートに加工されたオブジェクトツリーをポピュレートすることと、テンプレートの制約に従って、ウエブベースデータソースにアクセスすることができるボイスアプリケーションを創出することとを含む。この方法により、ボイスアプリケーション配置および実行状態の効率化、ならびにボイスアプリケーションの簡略化された展開プロセスが可能になる。
【００１４】
セキュリティ体制が、上記で記述されたシステムに提供される。プロトコルは、ウエブサーバおよびデータと、ユーザエンドの電話ネットワークおよびデータソースエンドのＸＭＬゲートウエイを経てアクセス可能であるボイスポータルシステムとの間に、トランザクションセキュリティを提供する。体制は、ＸＭＬゲートウエイを経てウエブサーバとボイスポータルシステムとの間にセットアップされる私的接続、仮想私的ネットワーク、または安全ソケット層の１つを含む。ポータルと１つまたは複数のサーバとの間において実施されるトランザクションは、データネットワークの安全ノード間において利用可能な同じセキュリティを享受する。一実施形態では、体制は、ポータルの出口およびエンドユーザの電話において分散されるボイス変換システムをさらに含み、ボイスダイアログは、ユーザ言語のあいまい言語ではないあいまい言語に変換され、次いで、ユーザの電話においてユーザ言語に再変換される。
【００１５】
ボイスアプリケーションダイアログトランザクションを可能にするために、テンプレートが使用されるようなシステムでは、ボイスポータルを経てユーザに応答ダイアログとして呈示される合成ボイスが、内容が適切であり、かつできれば表現にエラーがないように、ボイスアプリケーション規則およびボイス認識データが、適切な内容解釈および応答プロトコルについて考慮される。したがって、データベースは、多くの異なるビジネスシナリオと同様に、多くの異なる語彙ワードを網羅する非常に広範なスピーチを可能にする語彙ワードで最適化される。
【００１６】
発明の他の態様によれば、語彙認識は、クライアントパラメータに従って活動ボイスアプリケーションについて適合される。これは、ボイスポータルを経てデータソースにアクセスしているユーザ間において進行中の活動ボイスアプリケーションの使用に関連付けられた、テキストツースピーチレンダリングおよびスピーチツーテキストレンダリングに関連するボイス認識処理を制約するように構成された、語彙管理システムにより達成される。改良は、ボイスアプリケーションサーバおよび電話サーバに接続された語彙管理サーバ、ならびにボイス認識ソフトウエアの語彙確立および管理を可能にする管理サーバにおいて実行される語彙管理ソフトウエアのインスタンスを含む。改良語彙管理能力の実施では、語彙管理サーバにアクセスするアドミニストレータが、対象データソースに関連付けられた語彙の選択部分に特有である固有の語彙セットまたはリストを創出するために、語彙管理ソフトウエアを使用し、語彙セットは、アドミニストレータの指示に従って内容が異なる。
【００１７】
ボイスアプリケーション配置アーキテクチャの当業者なら、ボイスポータルに接続して対話することを競う多くのユーザが、いくつかの場合、ボトルネックを創出する可能性があることを理解するであろう。ボトルネックでは、ボイスアプリケーション構成要素をウエブソースおよび他のデータソースに接続するデータ線が、能力に対して負担となる。この問題は、多くの通常の電話環境に一般的であるように、特にピーク使用期間に生じる可能性がある。本発明者は、トラフィックの最適化の観点でいっそうの効率化が、上記で記述された潜在的な線使用の問題を軽減するために必要であると考えた。
【００１８】
本発明者に知られているボイスアプリケーション分配システムに対する具体的な改良が、上記の段落において記述されたトラフィックの課題に対処する。アプリケーション論理が、配置されるボイスアプリケーションのどの部分（ダイアログ）が、静的および動的規則に基づいてアプリケーション受信エンドシステムにおいてキャッシュされるかを判定するために提供され、いくつかの場合（動的キャッシング）、統計分析結果が、判定に使用される。アプリケーション論理は、アプリケーションの連続ダイアログファイルおよび規則に従って、ボイスアプリケーションを処理するためにプロセッサを使用する。論理構成要素が、静的内容を含むファイルを識別するためのプロセッサに接続された静的内容最適化装置、および動的内容を含むファイルを識別するためのプロセッサに接続された動的内容最適化装置を含む。最適化装置は、どのファイルが、どのエンドシステム設備においてキャッシュされるべきであるかを判定し、相応してファイルにタグ付けし、消費者が配置アプリケーションと対話している最中に局所的に取り出されるように、選択されたエンドシステムキャッシュ設備に分配するためにそれらのファイルを準備する。
【００１９】
局所キャッシュ設備からボイスアプリケーションのダイアログ部分を取り出すことができることにより、ボイスアプリケーションサーバへのネットワーク接続に対する負荷を減少させることによって、ボイスポータルにおける応答時間が増大される。しかし、トラフィック要件の低減に加えて、テキストツースピーチ認識およびスピーチツーテキストレンダリングが、明瞭かつ精確であることも重要である。発呼者に送達される合成スピーチの精度が、両端部において動的方式で対話することができる首尾よいボイスアプリケーションを創出するために重要である。
【００２０】
ボイスアプリケーション分配アーキテクチャが、交差領域境界、およびさらには文化的境界に広がるので、一般に話される用語および句に対処するスピーチ認識規則を標準化する見込みは、ますます難しくなる。たとえば、同じ言語のある用語の発音が、地域によって著しく異なる。主要道路および高速道路が書かれ、話される方式などの共通ラベルも、著しく異なることがある。ボイスアプリケーション対話が、大域的地理領域にわたるより大規模なアーキテクチャに対して実施される場合、対処される必要がある句および用語の変化の多くの例が存在する。
【００２１】
本発明者に知られている他のシステム改良では、テキストツースピーチ事前処理が、事前設定制約に従っていくらか発呼者に対して個人化されている合成ボイスをレンダリングするために使用される。改良システムは、ＶＸＭＬビュー生成およびその後のボイスレンダリングについて、テキストストリングを事前処理することができる。システムは、テキストツースピーチ事前処理論理、および事前処理論理にアクセス可能なソフトウエア表を有し、表は、１つまたは複数のテキストエンティティに関係付けられたテキストダイアログ選択肢を提供するように構成される。
【００２２】
規則のベースが提供され、事前処理論理にアクセス可能である。規則のベースは、テキストストリングに注釈を付けるために使用される特定のダイアログ部分を整合させるために使用されるダイアログ選択制約を提供するように構成される。ダイアログ選択肢およびテキストエンティティは、アクセス可能データストアに記憶される。好ましい実施形態では、事前処理論理は、クライアントの配置されたボイスアプリケーションとの対話中にソフトウエア表にアクセスして、単一テキストエンティティに関係付けられた２つ以上のダイアログ選択肢から特定のダイアログ選択肢を選択して、選択された選択肢をＶＸＭＬページレンダリングプロセスに挿入する。選択は、提供された制約の１つまたは複数のリターンに従って行われる。
【００２３】
改良システムは、広範な産業に特有の社会的、地理的、および文化的考慮事項にわたる可能性がある事前設定制約に応じて、ボイスダイアログの個人化を発呼者の特定のグループに提供するが、システムは、依然として概してロボット的であり、個々の態度および行為に応答しない。本発明者は、ボイスアプリケーションと対話する発呼者の瞬間的な態度ムードおよび行為が、対話時に理解されるならば、顧客の満足度、企業の販売数字、および対話プロセスの効率の増大を全体的に促進することができると考えた。
【発明の開示】
【発明が解決しようとする課題】
【００２４】
現在のアプリケーションでは通常は提供されない選択肢の提供、および／または現在のアプリケーションで通常提供されるある選択肢の排除を含めて、場合ごとに、ボイスアプリケーションと対話する個々のクライアントの特有の態度および行為を実時間で認識し、かつ選択ダイアログ選択肢を送達することによって対話中にそのような認識に応答するための方法および装置が、明らかに必要である。このようなシステムが、クライアントの満足度、企業の成功率、および対話の効率を増大させることができ、また配置時間にわたる対話の結果的な率も向上させることができる。
【課題を解決するための手段】
【００２５】
本発明の好ましい実施形態では、ボイスアプリケーション創出および配置システムが提供され、データネットワーク上においてボイスアプリケーションをクライアントに提供するボイスアプリケーションサーバと、データネットワークへのアクセスを有し、かつクライアントがボイスアプリケーションと対話するのを容易にするための少なくとも１つのボイスポータルノードと、アプリケーションサーバから実行可能な行為適応エンジンとを備える。システムは、行為適応エンジンが、提供されたアプリケーションとのボイス対話中にクライアント応答を傍受し、既存制約および受信クライアント情報に従って、行為パターンおよびムード状態の１つまたは組合わせについてそれらクライアント応答を分析し、連結選択肢または挿入可能選択肢を含む可能なダイアログ応答のセットのどれが、クライアントに対して実演される次の企業応答を創出するために、ＶＸＭＬページレンダリングに提出されるかを決定することを特徴とする。
【００２６】
システムのいくつかの好ましい実施形態では、データネットワークは、インターネットネットワークである。その他では、データネットワークは、インターネットおよび電話ネットワークの組合わせとすることが可能である。いくつかの場合、行為適応エンジンは、ボイスアプリケーションサーバのアプリケーション論理の一部である。他の場合、少なくとも１つのボイスポータルは、電話サーバと組み合わされた対話式ボイス応答システムである。いくつかの実施形態では、少なくとも１つのボイスポータルは、インターネットへのアクセスを有するデータネットワークに接続されたコンピュータ化ノードである。
【００２７】
いくつかの代替実施形態では、行為適応エンジンは、少なくとも１つのボイスポータルにおいて記録され、かつクライアント応答に添付されたデジタル音声ファイルとしてアプリケーションサーバに送信される音声ファイルを分析し、一方その他では、行為適応エンジンは、トリガ事象を受信すると同時に実行される。いくつかの他の実施形態では、制約は、メニューナビゲーション行為あるいはクライアントの知覚されたムード状態の１つまたは組合わせに関係する。他の実施形態では、ダイアログ応答および連結された選択肢は、データストアに記憶され、行為適応エンジンにアクセス可能である。他の実施形態では、受信されたクライアント情報は、線識別、番号識別、クライアント履歴データ、ボイスインプリント結果、および記録ボイスサンプルの１つまたは組合わせを含む。
【００２８】
他の実施形態では、ボイスサンプリングが、ムードを識別するために使用される。また、いくつかの他の実施形態では、受信クライアント情報が、応答を決定するために、ボイス分析と関連して使用される。いくつかの場合、行為適応エンジンは、クライアントのムード認識を容易にするために、ボイスの抑揚変化およびサンプリング音声の音量特徴を検出する。および他の実施形態では、対話の変化および音量特徴は、企業応答確率値の評価に使用される統計を展開するために、同じアプリケーションとの複数対話にわたって収集される。
【００２９】
本発明の他の態様では、ボイスアプリケーション創出および配置システムと統合された行為適応エンジンが提供され、行為適応エンジンは、データに添付された音声ファイルを含むＸＭＬベースクライアント対話データを受信するための少なくとも１つの入力ポートと、外部データシステムおよびモジュールとデータを送受信するための少なくとも１つの双方向データポートと、受信データを処理するためのＸＭＬ読取り装置およびボイスプレーヤならびに分析装置を含む論理処理構成要素と、１つまたは複数の制約に対して結果データを処理するための決定論理構成要素とを備える。エンジンは、行為適応エンジンが、提供されたボイスアプリケーションとのクライアント対話からのダイアログを含めてクライアントデータを実時間で傍受し、行為パターンおよび添付されていれば音声ファイルのボイス特徴について受信データを処理し、その際、エンジンは、結果および１つまたは複数の制約に従って、対話中にクライアントに戻される可能な企業応答の１つまたは１セットを識別することを特徴とする。
【００３０】
いくつかの実施形態では、エンジンは、ボイスアプリケーションサーバにホストされる。他の実施形態では、サーバは、インターネットネットワークにホストされる。いくつかの場合、ボイスアプリケーションおよび配置システムは、クライアントがボイスアプリケーションにアクセスするのを容易にするために、少なくとも１つのボイスポータルを含む。他の場合、エンジンは、トリガ事象を受信すると同時に機能にするように実行される。
【００３１】
他の場合、制約は、メニューナビゲーション行為またはクライアントの知覚されたムード状態の１つまたは組合わせに関係する。
【００３２】
いくつかの実施形態では、外部データリソースからのデータが、決定処理のための追加入力データとして使用される。その他では、受信クライアントデータは、線識別、番号識別、クライアント履歴データ、およびボイスインプリント結果の１つまたは組合わせを含む。その他では、ボイスサンプリングが、ムード状態を識別するために使用される。いくつかの場合、ボイス分析装置は、クライアントのムード認識を容易にするために、サンプリングされた音声のボイス抑揚変化および音量特徴を検出し、他の場合、対話の変化および音量特徴は、企業応答確率値の評価に使用される統計を展開するために、同じアプリケーションとの複数の対話にわたって収集される。
【００３３】
本発明の他の態様では、ボイスアプリケーションとのクライアント対話から得られるデータ入力に対する、適切な１つまたは１セットの複数のボイスアプリケーションダイアログ応答を識別する方法が、提供され、（ａ）ボイスアプリケーションの実行中にデータ入力を受信すること、（ｂ）データ入力を傍受すること、（ｃ）１つまたは複数の制約の妥当性について入力を分析すること、（ｄ）分析された結果を追加の外部データと比較すること、（ｅ）１つまたは複数の制約が引き続き妥当であるかについて比較結果を分析すること、および（ｆ）妥当な制約に従って１つまたは複数の利用可能な応答選択肢を識別することを含む。
【００３４】
この方法のいくつかの実施形態では、ボイスアプリケーションは、ＶＸＭＬコンプライアントである。他の実施形態では、ステップ（ａ）において、データ入力は、クライアント識別データ、クライアントダイアログデータ、およびダイアログからサンプリングされたデジタル音声を含む。他の実施形態では、ステップ（ｄ）および（ｅ）は、随意選択のステップである。他の実施形態では、ステップ（ｃ）において、制約の妥当性により、クライアントのムード状態の決定が示され、その他では、ステップ（ｃ）において、制約の妥当性により、クライアントの行為状態の決定が示され、いくつかのその他では、ステップ（ｃ）において、制約妥当性により、クライアントのムード状態および行為状態の両方が示される。
【００３５】
いくつかの場合、ステップ（ｄ）において、外部データは、同じアプリケーションの同じダイアログとの過去の対話から得られる統計データを含む。その他の場合、ステップ（ｆ）において、１つまたは複数の利用可能応答選択肢の識別が、選択をさらに処理して絞り込むために、１つまたは複数の応答選択肢を外部モジュールに提出することを含む。他の場合、外部モジュールは、テキストツースピーチプレプロセッサである。
【発明を実施するための最良の形態】
【００３６】
本発明の好ましい実施形態によれば、本発明者は、本明細書において、支援通信環境においてＩＶＲのインバウンドまたはアウトバウンド送達、および他の対話ボイスソリューションを可能にする、実時間の動的または静的ボイスアプリケーションをオブジェクト指向方式で展開および配置するための新規なシステムを可能にする方式で教示する。
【００３７】
図１Ａは、従来の技術による、ＶＸＭＬ可能ＩＶＲ展開および配置環境の基本的なアーキテクチャを示すブロック図である。背景セクションに関して記述されたように、この例の従来の技術のアーキテクチャは、本発明者に知られており、かつ利用可能である。この場合は電話環境である図示される環境のためのボイスアプリケーションを展開および配置することは、当技術分野の非常に高レベルの技能を必要とする。本明細書の背景セクションに関してすでに紹介されているこの従来の技術の例の要素は、再度紹介されることはない。
【００３８】
この簡略化されたシナリオでは、ボイスアプリケーションサーバ１１０は、内容についてデータベースまたは他のリソースにアクセスするために、データベース／リソースアダプタ１１３を使用する。ＶＸＭＬスクリプト、ビジネス規則、および基本電話論理を備えるアプリケーション論理１１２が、レンダリングエンジン１１１によって単一アプリケーションをレンダリングすることができるようになる前に、慎重に展開および試験されなければならない。ボイスアプリケーションが完成され、かつサーバ１１０から提供可能となった後、ボイスアプリケーションは、データネットワーク１２０を経て電話サーバ１３０に配置されることができ、電話サーバ１３０において、インタプリタ１３１およびテキストツースピーチエンジン１３２が、電話ソフトウエアおよびハードウエア１３３について使用可能または実演可能なフォーマットで、ボイスアプリケーションを形成して送達するために使用される。アプリケーションは、普及ネットワーク１３４を経て、本明細書ではデバイス１３５として示される受信デバイスである電話にアクセス可能である。普及ネットワーク１３４は、この場合、一般に電話スイッチ（図示せず）を経て、電話サーバを消費者（デバイス１３５）に連結する公衆交換電話ネットワーク（ＰＳＴＮ）である。
【００３９】
本発明の実施形態におけるこの従来の技術の例に対する改良は、展開および配置の問題に関する、ならびに双方向である対話ダイアログにおける応答能力および選択肢に対する全体的な改良に関する、アプリケーションサーバ１１０の能力を対象とし、かつそれを重点とする。最先端アーキテクチャと見なされる既存アーキテクチャの記述を使用して、本発明者は、本明細書において、図１Ａの従来の技術の例には示されていないが、図１Ｂによって本明細書において示される新規なバージョンの例には示されている、追加の構成要素を記述する。
【００４０】
図１Ｂは、本発明の一実施形態を示すように改良された図１Ａの基本的なアーキテクチャを示すブロック図である。図１Ｂにも示されている図１Ａの従来の技術の例の要素は、元の要素番号を維持し、再度紹介されることはない。参照のために、ボイスアプリケーションを展開するエンティティ（個人）は、これ以後本明細書では、プロデューサまたはデベロッパと呼ばれる。
【００４１】
本発明の一実施形態によるボイスアプリケーションのデベロッパまたはプロデューサは、本明細書では局１４０と示される遠隔コンピュータ化ワークステーションから動作されることが好ましい。局１４０は、本質的に、ネットワーク接続コンピュータ局である。局１４０は、アプリケーションサーバ１１０をも収容する物理領域内において収容されることが可能である。他の実施形態では、局１４０およびアプリケーションサーバ１１０は、同じ機械にあることが可能である。他の実施形態では、デベロッパが、自分のホームオフィスから、または任意の無線位置を含む任意のネットワークアクセス可能位置から、局１４０を動作することが可能である。
【００４２】
局１４０は、クライアントソフトウエアツール（ＣＬ）１４１を装備し、このツールは、デベロッパが、サーバ１１０、１３０によって、および受信デバイス１３５によって表される普及システムにわたって、ボイスアプリケーションを創出して配置することを可能にするように構成される。ＣＬ１４１は、この例ではウエブブラウザアプリケーションと同様のウエブインタフェースアプリケーション、またはそれと統合されたウエブインタフェースアプリケーションであるが、他のネットワーク状況が、代わりに適用されることが可能である。ＣＬ１４１は、デベロッパが、本発明の実施形態による改良を可能にするために必要なソフトウエアツールを備える。局１４０は、ボイスポータル１４３に接続され、ボイスポータル１４３は、データネットワーク（インターネット、イーサネット（登録商標）、イントラネットなど）の上、および／または電話ネットワーク１３４内において維持される。この例では、ポータル１４３は、論理的に両方のネットワークにおいて示されている。ボイスポータル１４３は、デベロッパまたはボイスアプリケーション消費者がコールインして、選択ボイスアプリケーション上において機能オペレーション（アクセス、監視、修正など）を実施することを可能にするように構成される。
【００４３】
アプリケーションサーバ１１０内において、本発明の一実施形態による動的ボイスアプリケーションの展開および配置を提供するために、既存構成要素１１１〜１１３と関連して適合されたボイスアプリケーション展開サーバ１４２のインスタンスが存在する。
【００４４】
ポータル１４３は、ネットワーク接続を介して局１４０にアクセス可能であり、また、ネットワークブリッジを介して電話ネットワーク１３４を経たボイスアプリケーション消費者にアクセス可能である。一例では、ポータル１４３は、アプリケーションサーバ１１０の一部として維持される。ポータル１４３は、消費者ためのアクセス点の他に、デベロッパのインタフェースサーバとして主に構成される。ポータル１４３は、ＣＬ１４１へのサーバインスタンスとして構成されたＳＷインスタンス１４４によって可能になる。一電話実施形態では、ポータル１４３は、対話式ボイス応答（ＩＶＲ）ユニットとすることが可能である。
【００４５】
１つの好ましい実施形態では、ボイスアプリケーションのプロデューサまたはデベロッパは、遠隔局１４０を「ウエブインタフェース」として使用して、ポータル１４３およびデータネットワーク１２０を経てアプリケーションサーバ１１０にアクセスして、まず、接点のリストを創出する。代替実施形態では、局１４０は、ネットワークインタフェースを経たアプリケーションサーバ１１０への直接アクセスを有する。接点は、創出されたボイスアプリケーションの消費者と同様である。ＣＬ１４１は、完成ボイスアプリケーションの設計、修正、インスタンス化、および実行が、アプリケーションサーバ１１０から開始され、かつサーバ１３０によって送達されるように、要求に応じて必要な順序で、必要な対話式インタフェースのすべてを表示する。
【００４６】
本発明のソフトウエアにより、デベロッパが複雑な符号化オペレーションを実施することを必要とせずに、ボイスアプリケーションが、パラメータとしてビジネスおよび電話（または他の通信送達／アクセスシステム）の規則を有する１セットのダイアログオブジェクトとしてモデリングされることが可能になる。ダイアログテンプレートが、ダイアログ状態をモデリングするために提供される。ダイアログテンプレートは、実際のスピーチダイアログを創出し、ダイアログのボイスアプリケーション消費者（受信者）を規定し、ボイスアプリケーション消費者から応答を捕獲して、消費者応答のシステム解釈に基づいて、任意の追従動作を実施する。ダイアログは、再使用可能な構成要素であり、新しいダイアログまたは既存（記憶）ダイアログに連結されることができる。ボイスアプリケーションは、ボイスアプリケーションプロデューサによって確定される１セットのビジネス規則によって、相互連結された１セットのダイアログである。ボイスアプリケーションが完成された後、ボイスアプリケーションは、サーバ１１０によって配置され、最終的には、電話サーバ１３０を経て許可パーティ（デバイス１３５）にアクセス可能である。
【００４７】
ボイスアプリケーションは、好ましい実施形態では、ＶＸＭＬコンプライアント電話サーバ１３０上で実行されるＶＸＭＬの形態にある。このプロセスは、ＶＸＭＬレンダリングエンジン１１１により可能になる。エンジン１１１は、サーバ１３０と直接相互作用し、対象のボイスアプリケーションを特定し、そのボイスアプリケーション論理を取り出し、呈示をＶＸＭＬで動的に創出し、処理および送達のためにそれをサーバ１３０に転送する。インタプリタ１３１がＶＸＭＬ呈示を解釈した後、これは、対話式ダイアログの形態（この場合はＩＶＲダイアログ）でデバイス１３５に送信される、またはデバイス１３５にアクセス可能とされる。デバイス１３５からのあらゆる応答が、エンジン１１１による解釈のために、再びアプリケーションサーバ１１０まで同じ経路をたどる。次いで、サーバ１１０は、アダプタ１１３を経てアクセス可能なデータベースからボイスアプリケーションプロファイルを取り出し、局所的に実行される次のビジネス規則を決定する。その決定に基づいて、規則に関連付けられた対応するオペレーションが行われる。次いで、次の（必要であれば）ＶＸＭＬ呈示が、レンダリングエンジン１１１に転送され、このレンダリングエンジンは、サーバ１３０において、解釈、処理、および配置のために、次のＶＸＭＬページを動的に生成する。ＶＸＭＬコンプライアント電話サーバ（１３０）とボイスアプリケーションサーバ（１１０）との間のこの両方向対話は、ボイスアプリケーションが終端状態に最終的に到達するまで、ＶＸＭＬダイアログの自動論理シーケンスの形態で続行される。
【００４８】
ボイスアプリケーション（１つまたは複数のダイアログのセット）は、アウトバウンドまたはインバウンドの方式で消費者（対象オーディエンス）に送達されることができる。インバウンドボイスアプリケーションでは、ボイスアプリケーション消費者が、サーバ１３０から提供されるインバウンドボイスアプリケーションにアクセスするために、ボイスポータル１４３にコールインする。ボイスポータルは、電話番号に直接マッピングされることができ、または拡張子として中央電話番号にマッピングされることができる。好ましい実施形態では、ボイスポータルは、コミュニティフォーラムとしても作用し、このコミュニティフォーラムにおいて、ボイスアプリケーションプロデューサは、アクセスを容易にするために、ボイスアプリケーションをグループ化して、ボイスアプリケーションの連結、報告、およびテキストツースピーチ記録などのオペレーション活動を実施することができる。
【００４９】
アウトバウンドボイスアプリケーションでは、２つの準タイプが存在する。これらは、オンデマンドアウトバウンドアプリケーションおよびスケジュール済みアウトバウンドアプリケーションである。オンデマンドアウトバウンドアプリケーションでは、ボイスアプリケーションプロデューサが、アプリケーションに関連付けられたアウトバウンドコマンドを出すとすぐに、サーバ１１０が、アウトバウンドコールを生成する。アウトバウンドコールは、対象オーディエンスに対して作成され、コールを受信するとすぐに、ボイスアプリケーションは、サーバ１３０から開始される。スケジュール済みアウトバウンドアプリケーションでは、スケジュールサーバ（サーバ１１０内には図示せず）が、プロデューサが規定した日付および時間に到達するとすぐに、ボイスアプリケーションを開始する。好ましい実施形態では、オンデマンドおよびスケジュール済みの両方のアウトバウンドアプリケーション配置機能が、ユニキャスト、マルチキャスト、およびブロードキャストの送達方式を支援する。
【００５０】
上記で記述されたように、アプリケーションサーバ１１０によって創出されるボイスアプリケーションは、１つまたは複数のダイアログからなる。各ダイアログの内容は、静的または動的とすることができる。静的内容は、ボイスアプリケーションプロデューサを源とする内容である。プロデューサは、ボイスアプリケーションが創出されるとき、内容を創出する。動的内容は、第３パーティデータソースを源とする。
【００５１】
好ましい実施形態では、デベロッパツールが、対話式ダイアログ設計パネル（以下において詳細に記述される）を含み、プロデューサが、基準リンクを、拡張可能マークアップ言語（ＸＭＬ）の形態でダイアログ記述または応答フィールドに入力する。ダイアログ応答が、アプリケーションサーバ１１０によって実行されかつ解釈されるとき、基準リンクは、リソースアダプタ１１３に登録されているリソースアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出す。ＡＰＩは、実時間で出て行き、要求されたデータを取り出し、返却されたデータを既存ダイアログに組み込む。生成された結果的な後続のＶＸＭＬページは、その上に埋め込まれた動的データを有する。
【００５２】
本発明の１つの目的は、アプリケーションデベロッパが規定したデータソース要件に自動的に自身を適合させる高度に動的な実時間ＩＶＲシステムである。本発明の他の目的は、ＶＸＭＬの任意の先行知識またはあらゆる他のプログラミング技術を必要とせずに、ボイスアプリケーションの迅速な展開および配置を可能にすることである。本発明の他の目的は、通常のボイスアプリケーション生成サイクルを低減し、また生成コストを劇的に下げることである。
【００５３】
図２は、本発明の一実施形態による、ＶＸＭＬボイスアプリケーションのためのボイスアプリケーションシェルまたはコンテナを創出するためのステップを示すプロセス流れ図である。デベロッパは、図１ｂを参照して記述された局１４０上のＣＬ１４１と同様のシンクライアントとして知られているクライアントアプリケーションを使用し、ボイスアプリケーンシェルまたはボイスアプリケーションコンテナを創出する。ステップ２０１において、デベロッパは、ログインページにおいてシステムにログインする。ステップ２０２において、デベロッパは、アプリケーション消費者の接点リストを創出する。通常、あいさつページまたはウエルカムページが、ステップ２０２の前に表示される。アプリケーション消費者は、ボイスアプリケーションへのアクセスを有し、かつボイスアプリケーションと対話する、１つまたは複数のエンティティのオーディエンスである。接点リストが第１に創出され、それにより、意図した接点のすべてが、コール経路指定論理が後に必要とされる場合、ボイスアプリケーション創出中に利用可能となる。接点リストは、プロデューサによって２つ以上の事象において個々に入ることができ、または、マイクロソフトアウトルック（登録商標）もしくはおそらくはＰＤＡ（登録商標）オーガナイザなど、いくつかのオーガナイザ／プランナソフトウエアから設定リストとしてインポートすることが可能である。
【００５４】
本発明の一実施形態では、接点リストは、適切に構成され、かつリストにアクセスして取り出すように構成される提供コネクタ（図示せず）によって、アクセスされる外部デバイス上にあることが可能である。この手法は、たとえば、大規模な既存顧客データベースが使用される場合、使用されることが可能である。コピーを創出するのではなく、必要なデータは、原型から抽出されて、アプリケーションに提供される。
【００５５】
ステップ２０３において、ボイスアプリケーションヘッダがポピュレートされる。ボイスアプリケーションヘッダは、単にアプリケーションのタイトルフィールドである。フィールドは、アプリケーションの名称およびアプリケーションの記述を含む。ステップ２０４において、デベロッパは、ボイスアプリケーションについてインバウンド状態およびアウトバウンド状態のどちらかを割り当てる。アウトバウンドアプリケーションは、アウトバウンドコールにより送達され、一方、消費者は、インバウンドボイスアプリケーションにアクセスする。
【００５６】
インバウンドアプリケーションの場合、ステップ２０５において、システムは、インバウンド通信についてデフォルト宛先人を設定する。デベロッパは、ステップ２０６において構成リストからダイアログを選択する。この例では、ダイアログはすでに創出されていると想定する。ステップ２０７において、デベロッパは、ダイアログを実行し、ダイアログは、自動的に配置される。
【００５７】
ステップ２０４においてアウトバウンドが指定される場合、デベロッパは、ステップ２０８において開始タイプを選択する。開始タイプは、オンデマンドタイプまたはスケジュール済みタイプとすることができる。ステップ２０８においてデベロッパによって行われる選択が、スケジュール済みである場合、ステップ２０９において、デベロッパは、同じアプリケーションの開始を繰り返すためのパラメータを含めて、開始のためのすべての適切な時間および日付のパラメータを入力する。ステップ２０８においてアプリケーションの開始についてオンデマンドが選択される場合、ステップ２１０において、デベロッパは、ステップ２０２において確立された接点リストから１つまたは複数の接点を選択する。本明細書では、ステップ２１０は、スケジュール済み開始の場合、ステップ２０９後にデベロッパ２０９によって行われることにも留意されたい。ステップ２０７において、ダイアログが創出される。このステップでは、対話が意図されるボイスアプリケーションの可能なダイアログ応答のリストが創出されて、使用のために記憶されることも可能である。
【００５８】
一般的な順序では、デベロッパが、ボイスアプリケーションを創出して、バックエンドデータソース、または随意選択として任意の第３パーティリソースとアプリケーションを統合して、ボイスアプリケーションを配置する。次いで、アプリケーション消費者は、ボイスアプリケーションを消費し、随意選択で、システムは、適切であればさらに対話するために、ボイスアプリケーションによって収集されたあらゆる消費者フィードバックを分析する。この例のステップは、すでに適所にある「構築ブロック」からボイスアプリケーションを生成して開始することに関する。
【００５９】
図３は、本発明の一実施形態による簡単なボイスアプリケーションコンテナ３００を示すブロック図である。アプリケーションコンテナ３００は、論理コンテナまたは「ボイスアプリケーションオブジェクト」３００である。シェルとも呼ばれるコンテナ３００は、上記の図２のプロセスの可能な結果として論理的に示される。コンテナ３００は、この例ではダイアログ１〜４と名称付けされるダイアログ３０１ａ〜ｎとして本明細書では示される、１つまたは複数のダイアログ状態を含む。ダイアログ３０１ａ〜ｎはオブジェクトであり、したがって、コンテナ３００は、ダイアログオブジェクト３０１ａ〜ｎのセットの論理グループである。
【００６０】
ダイアログオブジェクト３０１ａ〜ｎの表示されたセットは、この例では規則１〜４と名称付けされたビジネス規則によって相互連結される。規則１〜４は、デベロッパによって規定され、かつ規則オブジェクトである。本明細書では、本発明の精神および範囲から逸脱せずに、コンテナオブジェクト３００を備えるより多いまたはより少ないダイアログオブジェクト３０１ａ〜ｎならびに相互連結ビジネス規則が存在することが可能であることに留意されたい。本発明者は、４つの各エンティティを示し、この表示は本発明を説明するのに十分であると考える。
【００６１】
表示されたオブジェクトの他に、ボイスアプリケーションシェル３００は、複数のセッティング選択肢を含む。この例では、基本的なセッティング選択肢が、参照のために表にされ、３つの列挙されたセッティング選択肢を示す要素番号３０５ａ〜ｃが与えられる。表を上から下まで読むと、第１のセッティング開始タイプ（３０５ａ）が、通信システム内へのボイスアプリケーション３００の初期エントリ点を確定する。図２のステップ２０４に関して上記で記述されたように、開始タイプ３０５ａの選択は、インバウンドまたはアウトバウンドである。代替実施形態では、開始タイプが、第３パーティによって確定され、インバウンドまたはアウトバウンド以外のあるパターンにおいて確定されることが可能である。
【００６２】
アウトバウンド開始指定は、ボイスアプリケーションを１つまたは複数の宛先人（消費者）に結合する。宛先人は、やはり上記で図２を参照して記述された（ステップ２０２）接点リストまたは分布リストによって表される、単一接点または接点のグループとすることが可能である。アウトバウンドボイスアプリケーションが、この場合において開始されるとき、ボイスアプリケーションアウトバウンド接点フィールド（図示せず）上において指定される宛先人に送達される。指定されたすべての宛先人は、アウトバウンドボイスアプリケーションのコピーを受信し、ボイスアプリケーションダイアログおよび対応するバックエンドデータリソースが、特定のアプリケーションにおいて使用される場合は、ボイスアプリケーションダイアログおよび対応するバックエンドデータリソースと対話する（可能であれば）等しい機会を有する。
【００６３】
開始タイプ３０５ａについてインバウンドボイスアプリケーション指定の場合、システムは、準備完了待機モードを想定するようにアプリケーションに命令する。アプリケーションは、指定されたボイスアプリケーション消費者が、ボイスアプリケーションにアクセスすることを能動的に要求するとき、開始される。通常のコールセンタＩＶＲシステムが、このタイプのインバウンドアプリケーションを想定する。
【００６４】
開始時間セッティング（３０５ｂ）は、ボイスアプリケーション開始タイプセッティング３０５ａが、アウトバウンドに設定される場合のみ、選択肢として可能になる。開始時間セッティングは、新規なスケジュールエンジンを指示するように設定され、このスケジュールエンジンは、図１Ｂを参照して記述されたアプリケーションサーバ機能の一部として想定されることが可能である。スケジュールエンジンは、いつボイスアプリケーションを指定宛先人に送達するかのパラメータを制御する。時間セッティングは、オンデマンドスケジュール済み開始、または任意の第３パーティ確定パターンを反映することが可能である。
【００６５】
オンデマンドは、ボイスアプリケーションの開始時間に対する完全な制御をデベロッパに与える。オンデマンドの特徴により、任意の第３パーティシステムが、ボイスアプリケーションを開始するために、トリガ事象を発行することも可能になる。本明細書では、第３パーティ制御の場合、ボイスアプリケーション対話は、２つ以上の通信システムおよびまたはネットワークを超えることが可能であることに留意されたい。
【００６６】
プロパティセッティング３０５ｃが、ボイスアプリケーションが全般的にどのように行動すべきかを本質的に確定する。セッティング３０５ｃの可能な状態選択肢は、公的、永続的、または共有可能である。公的状態セッティングは、最小限の特典を有するすべての消費者が、アプリケーションにアクセスすることができるように、ボイスアプリケーションが、ボイスポータル領域内の任意の人にアクセス可能であるべきであることを示す。特性３０５ｃの永続的状態セッティングは、ボイスアプリケーションの１つのコピーのみが、アプリケーションにアクセスすることを試みる消費者の数に関係なく、常に活動していることを保証する。そのようなシナリオの例は、タスク割付けボイスアプリケーションのシナリオである。たとえば、タスク割付けシナリオでは、ユーザがアプリケーションにアクセスするために利用可能ないくつかの時間スロットのみが存在する。タスクが、スケジュール済みチャットセッションにつながるという、おそらくは顧客支援技術者などの接点のプールからの要求である場合、時間スロットが選択されているときはいつでも、他の技術者は、残っているスロットのみを選択することができる。したがって、技術者のプール内において循環するボイスアプリケーションの唯一のコピーが存在する場合、アプリケーションは、先着順で技術者の応答を捕獲する。
【００６７】
特性３０５ａのための共有可能アプリケーション状態セッティングにより、消費者は、ボイスアプリケーションが永続的であるか否かに関係なく、対象のダイアログにおいて他の技術者の応答を「見る」ことが可能になる。ボイスアプリケーションシェルが創出された後、プロデューサは、図２のステップ２０７を参照して記述されたように、ボイスアプリケーションの第１のダイアログを創出することができる。本明細書では、シェル３００は、本明細書において以下でより詳細に記述される遠隔クライアント、および好ましくはデスクトップクライアントを使用してモデリングされることを思い出されたい。
【００６８】
図４は、本発明の一実施形態による、ダイアログオブジェクトモデル４００を示すブロック図である。ダイアログオブジェクトモデル４００は、上記で図３を参照して記述されたダイアログオブジェクト３０１ａ〜ｎのいずれかと同様である。オブジェクト４００は、ダイアログおよびすべての特性をモデリングする。ダイアログオブジェクト４００内において示され、かつオブジェクト特性（４１０）と名称付けされた特性オブジェクトが、行為状態およびダイアログに適用されるビジネス規則を含めて、ダイアログのタイプおよび特性を含む。
【００６９】
たとえば、各ダイアログは、ルートツー特性（４１１）としてこの例では示されるルートツー特性を有する。特性４１１は、ダイアログのソースにマッピングされ、ダイアログのソースを識別する。同様に、各ダイアログは、本明細書ではルートフロム特性（４１２）と示されるルートフロム特性を有する。ルートフロム特性４１２は、ダイアログの受信者接点またはダイアログ消費者にマッピングされ、それを識別する。
【００７０】
各ダイアログは、ダイアログタイプと名称付けされ、かつ要素番号４１３を与えられる特性によって、この例では示されるダイアログタイプの下にある。ダイアログタイプ４１３は、以下のタイプのダイアログを含むことが可能であるが、これに限定されるものではない。
１．無線ダイアログ。無線ダイアログにより、ボイスアプリケーション消費者が、ダイアログ記述を聞いた後、選択肢リストから利用可能な選択肢の１つを対話式に選択することが可能になる。
２．掲示ダイアログ。掲示ダイアログにより、ボイスアプリケーション消費者が、複数の消費者が非同期方式でボイスメッセージを共有することができる掲示板様フォーラムと対話することが可能になる。
３．ステートメントダイアログ。ステートメントダイアログは、消費者からの応答を予期せずに、ステートメントをボイスアプリケーション消費者に実演する。
４．オープンエントリダイアログ。オープンエントリダイアログにより、ボイスアプリケーション消費者が、ダイアログ記述を聞いた後、事前確定長のメッセージを記録することが可能になる。
５．第３パーティダイアログ。第３パーティダイアログは、デベロッパが、自体の特性および行為を有する特注ダイアログタイプを創出することを可能にするモジュールコンテナ構造である。例は、ニュアンス（Ｎｕａｎｃｅ）のスピーチオブジェクト（登録商標）である。
【００７１】
各ダイアログタイプは、それにタグ付けされた１つまたは複数の関連ビジネス規則を有し、この規則は、知覚状態に応答して次のステップを決定することを可能にする。規則は、アプリケーション消費者応答を、より少ない、より多い、等しい、または等しくないなどのオペレーションコードを使用して、アプリケーションデベロッパによって確定されたオペランドと比較する。本発明の好ましい実施形態では、規則に関係するパラメータは、以下の通りである。
ユーザ応答が事前確定値に等しい場合、以下の１つを実施する。すなわち、
Ａ．何も実施せず、ダイアログ状態を終了させる、
Ｂ．規定された接点へのライブブリッジ移動を実施する、または、
Ｃ．他のダイアログを他の接点に送信する。
【００７２】
アウトバウンドボイスアプリケーションの場合、知覚状態に関連する例外対処ビジネス規則が存在する可能性が高い。本発明の好ましい実施形態では、例外対処規則は、３つの異なる事象に要約される。すなわち、
１．ボイスアプリケーションを受信するように指定されたアプリケーション消費者が、ボイスアプリケーションと対話する要求を拒否する、
２．アプリケーション消費者が、電話ビジー信号など、ボイスアプリケーションの開始時間においてビジー接続を有する、および
３．アプリケーション消費者の接続が、電話応答機械など、人ではないデバイスによって応答される、またはそれに向け直される。
【００７３】
上記の事象のそれぞれについて、３つの追従動作のいずれか１つが、知覚状態に応じて可能である。すなわち、
１．何も実施せず、ダイアログ状態を終了させる、
２．番号を再度ダイヤルする、
３．他のダイアログを他の接点に送信する。
【００７４】
図５は、本発明の一実施形態による、ＶＸＭＬ可能ボイスアプリケーションのボイスダイアログを創出するためのステップを示すプロセス流れ図である。すべてのダイアログは、後のダイアログ経路指定のために再使用されることができる。前に記述されたように、各ダイアログおよび接点の対について、１セットのビジネス規則が存在する。ダイアログは活動しており、規則で可能になるときのみ、１つのダイアログ状態から他へ移行することができる。
【００７５】
ステップ５０１において、デベロッパが、ダイアログ記述フィールドにダイアログ記述をポピュレートする。ダイアログ記述は、以下においてさらに記述されるように、ＸＭＬタグに対する参照を含むことも可能である。ステップ５０２において、ダイアログタイプのパラメータが、ダイアログの割り当てられたタイプに基づいて入力される。利用可能なパラメータの例は、上記で図４を参照して記述されている。
【００７６】
ステップ５０３において、デベロッパは、ダイアログタイプの網羅ならびに追従のルーチンについて、適用可能なビジネス規則を構成する。一実施形態では、ステップ５０３における規則構成は、適用規則に基づいて追従ルーチンを決定するためのステップ５０５になる。たとえば、デベロッパは、ステップ５０５において、３つのタイプの移行の１つを選択することが可能である。たとえば、デベロッパは、ステップ５０６によって示されるライブ移行、ステップ５０７によって示される創出のための次のダイアログへの移行について構成することが可能であり、または、デベロッパは、ステップ５０８によって示されるように、ダイアログの終了について構成することが可能である。
【００７７】
デベロッパが、ステップ５０５からサブルーチン５０６、５０７、または５０８を構成することに分岐せず、ステップ５０３からステップ５０４に続いて、ダイアログのインバウンドであるかまたはアウトバウンド指定が、システムに割り当てられる場合、プロセスは、ダイアログがインバウンドまたはアウトバウンドであるかに応じて、ステップ５０４からステップ５０８または５０８に分岐しなければならない。ステップ５０４において、ダイアログがインバウンドである場合、ステップ５０８において、ダイアログは終了する。ステップ５０４における割当てがアウトバウンドである場合、ステップ５０９において、コール例外ビジネス規則を構成する。
【００７８】
ステップ５１０において、デベロッパは、システムの例外対処について少なくとも１つの追従動作を構成する。ステップ５１０において、追従動作が規定されることが必要ない場合、プロセスは、ダイアログ終了のためにステップ５０８になる。ステップ５１０において、１つまたは複数の動作が構成される場合、ステップ５１１において、ステップ５１１に示される動作であるシステム再ダイヤルなど、１つまたは複数の動作は実行される。
【００７９】
好ましい実施形態では、ボイスアプリケーションが創出された後、ボイスアプリケーションは、配置されかつ電話を経てアクセスされることができる。アクセス方法は、当然、ステップ５０４において構成された割当てに応じる。たとえば、アプリケーションがインバウンドである場合、アプリケーション消費者は、アプリケーションにアクセスするために、ボイスポータルにアクセスする。上記でさらに記述されているように、ボイスポータルは、上記で図１Ｂを参照して記述されたボイスアプリケーションサーバの選択された数の機能にアクセスするためのボイスインタフェースである。ボイスポータルは、接続指向の切替え電話（ＣＯＳＴ）可能ポータル、またはデータネットワーク電話（ＤＮＴ）可能ポータルとすることが可能である。ステップ５０４においてアウトバウンドに指定される場合、アプリケーション消費者は、ボイスアプリケーションサーバから発信される消費者へのインカミングコールにより、ボイスアプリケーションを受信する。好ましい実施形態では、アウトバウンドコールは、支援される通信環境に応じて、ＣＯＳＴベースまたはＤＮＴベースとすることができる。
【００８０】
図６は、本発明の一実施形態による、消費者との初期接続後のダイアログ移行フローを示すブロック図である。この例に示される要素のいくつかは、上記の図１Ｂの例に関して以前に紹介されており、したがって、当初の要素番号を保持する。この例では、アプリケーション消費者は、論理的にはアプリケーション消費者６００と示され、電話サーバ１３０によってホストされるダイアログ６０１との対話に能動的に従事する。サーバ１３０は、以前に記述されたように、ＶＸＭＬコンプライアント電話サーバであり、そのように名称付けされている。
【００８１】
アプリケーションサーバ１１０も、対話シーケンスに能動的に従事し、動的内容を消費者６００に提供する能力を有する。アプリケーション消費者６００が、本明細書では電話サーバ１３０内のダイアログ６００によって表されるボイスアプリケーションとの対話を開始する際に、ボイスアプリケーションサーバ１１０は、状況を監視する。実際の実施では、処理されて、かつ消費者６００への送達、または消費者６００によるアクセスのためにサーバ１３０に送信される各ダイアログは、配置されかつ実行されている特定のボイスアプリケーションの微小ユニットである。したがって、ダイアログ６０１は、論理的に、２つ以上の単一ダイアログを表すことが可能である。
【００８２】
この例では、２つ以上のダイアログを想定し、ダイアログ６０１は、対話中に消費者６００からの応答を獲得するための役割を担う。送信および応答と名称付けされた矢印が、記述される対話を表す。消費者６００がダイアログ内容に応答するとき、応答は、同じ当初の経路に沿ってＶＸＭＬレンダリングエンジン１１１に送り返され、ＶＸＭＬレンダリングエンジン１１１は、応答を解釈して、提供されるダイアログ制御装置６０４に解釈されたバージョンを転送する。制御装置６０４は、図１Ｂを参照して記述されたサーバ１１０のアプリケーション論理１１２の一部である。ダイアログ制御装置６０４は、確立された規則および構成された応答パラメータに基づいて、表の探索、データの取出し、およびデータの書込みの機能を実施する能力を有するモジュールである。
【００８３】
ダイアログ制御装置６０４がダイアログ応答を受信するとき、対象となるダイアログ（６０１）に対応する応答を、データマイニングオペレーションおよびワークフロー監視のために提供されるデータソース６０２に記憶する。次いで、制御装置６０４は、記憶応答に対応する１つまたは複数のビジネス規則を探索する要求を、提供される規則エンジン６０３に出す。適正なビジネス規則が応答について特定された後、ダイアログ制御装置は、解釈を開始する。アクセスされたビジネス規則が、第３パーディデータソース（図示せず）を参照することを必要とする場合、制御装置６０４は、ソースから必要なデータを取り込む。制御装置６０４によって戻されたあらゆるデータが、ダイアログコンテキストに統合され、次のダイアログ６０１のダイアログページを生成するために、ＶＸＭＬレンダリングエンジン１１１に渡される。プロセスは、ダイアログ６０１が終了するまで繰り返される。
【００８４】
一実施形態では、消費者６００からの受信応答の結果として制御装置６０４によってアクセスされるビジネス規則は、現行アプリケーション消費者に戻る以外のダイアログ移行状態を所持する。この場合、制御装置６０４は、次のまたは「生成されたダイアログ」を指定対象アプリケーション消費者に送達するために、アプリケーションサーバ１１０からアウトバウンドコールを生産する。同時に、現行消費者は、ビジネス規則において規定された事前確定論理に従って、図５のステップ５０８を参照して記述されたように完成された自分のダイアログ状態を有する。
【００８５】
当業者なら、制御装置６０４が、規則エンジン６０３によって提供される規則に従ってデータソース６０２へのアクセスを有することを可能にすることによって、ダイアログが動的内容を含むことができることを理解するであろう。ほとんどの実施形態において、一般に２つのタイプの動的内容が存在する。両タイプとも、好ましい実施形態では、ＸＭＬの形態において構築され、次に生成されるダイアログページに直接埋め込まれる。２つのタイプの動的内容の第１は、非反復と分類される。非反復の内容は、図１Ｂを参照して記述されたボイスアプリケーションサーバ１１０のアダプタ１１３と同様のリソースアダプタ内にあるリソースアダプタレジストリの非反復リソースラベルを相互参照する。
【００８６】
上記の場合、ダイアログ制御装置６０４がダイアログを解釈するとき、ダイアログ制御装置６０４は、第１に、任意のリソースラベルについて走査する。整合が見つかった場合、リソースアダプタレジストリを探索して、必要なデータを新しいダイアログコンテキストに取り込むために、対応するリソースＡＰＩを呼び出す。未加工データが第３パーティデータソースから戻された後、未加工データをさらに処理するために、対応するリソースフィルタに渡す。フィルタによる処理に関して完了したとき、ダイアログリソースラベルまたはタグは、フィルタリング済みデータと置き換えられ、かつ新しいダイアログに透過的に統合される。
【００８７】
第２のタイプの動的内容は、反復である。反復の内容は、通常、２セット以上の名称および値の対を戻す。例は、アプリケーション消費者のストックポートフォリオのストックのリストである。たとえば、消費者６００が、特定のストックを機械的に繰り返して、他のダイアログ状態を経て戻されるその後のクォートを有することを可能にするダイアログが、所望の結果を達成するために、反復動的内容を使用するように作成される。反復内容は、ボイスアプリケーションサーバ１１０のリソースアダプタレジストリにある反復リソースラベルを相互参照する。制御装置６０４がダイアログを解釈するとき、非反復内容の対処と同一の方式でリソースに対処する。しかし、フィルタリング済みデータをダイアログコンテキストに単に戻す代わりに、データリストを通るループとし、グラマー可能キーワードとして各列挙項目を構成する。そのようにすることにおいて、消費者６００は、第１のダイアログにおいて行われるリストの項目（別々のストック）の１つを機械的に繰り返して、確保された応答を有し、次のダイアログ状態において戻されるように処理されることができる。以下で呈示されるストッククォートの例は、消費者６００の視点からの可能なダイアログ／応答対話を示す。
ボイスアプリケーション、「おはようございます、レオさん、どのストッククォートをご希望ですか？（Ｇｏｏｄ  ｍｏｒｎｉｎｇ  Ｌｅｏ，ｗｈａｔ  ｓｔｏｃｋ  ｑｕｏｔｅ  ｄｏ  ｙｏｕ  ｗａｎｔ？）」
アプリケーション消費者、「オラクル（Ｏｒａｃｌｅ）。」
ボイスアプリケーション、「オラクルは１７ドルです（Ｏｒａｃｌｅ  ｉｓ  ａｔ  ｓｅｖｅｎｔｅｅｎ  ｄｏｌｌａｒｓ）。」
ボイスアプリケーション、「おはようございます、レオさん、どのストッククォートをご希望ですか？（Ｇｏｏｄ  ｍｏｒｎｉｎｇ  Ｌｅｏ，ｗｈａｔ  ｓｔｏｃｋ  ｑｕｏｔｅ  ｄｏ  ｙｏｕ  ｗａｎｔ？）」。
【００８８】
この具体的な例は、２つのダイアログからなる。
【００８９】
第１のダイアログは、「おはようございます、レオさん、どのストッククォートをご希望ですか？」というステートメントを実演する。ダイアログには、オラクル、サン、マイクロソフトなどのキーワードを聞く待機時間が続く。ステートメントは、２つの動的な非反復リソースラベルからなる。第１は、１日の時間である。すなわち、おはようございます、こんにちは、またはこんばんはである。第２の動的内容は、アプリケーション消費者の名前である。この場合、消費者の名前は、ボイスアプリケーションサーバに対して内的であり、したがって、リソースラベルのタイプは、ＳＹＳＴＥＭである。実際のダイアログ記述フィールドでは、以下のようなものを見ることが可能である。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＡＤＡＰＴＥＲ’ｎａｍｅ＝’ｔｉｍｅ  ｇｒｅｅｔｉｎｇ’／＞＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＳＹＳＴＥＭ’  ｎａｍｅ＝’ｔａｒｇｅｔ＿ｃｏｎｔａｃｔ’／＞、ｗｈａｔ  ｓｔｏｃｋ  ｑｕｏｔｅ  ｄｏ  ｙｏｕ  ｗａｎｔ？
【００９０】
ダイアログは、消費者が，自分の既存のポートフォリオからストックを言うのを予期しているので、ダイアログのタイプは、無線ダイアログであり、無線ダイアログの予期される応答特性は、以下の通りである。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＡＤＡＰＴＥＲ’ｎａｍｅ＝’ｓｔｏｃｋ＿ｌｉｓｔ’＞
＜ｐａｒａｍ＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＳＹＳＴＥＭ’ｎａｍｅ＝’ｔａｒｇｅｔ＿ｃｏｎｔａｃｔ＿ｉｄ’／＞
＜／ｐａｒａｍ＞
＜／ｒｅｓｏｕｒｃｅ＞
【００９１】
このＸＭＬリソースラベルは、ダイアログ制御装置６０４に、ｓｔｏｃｋ＿ｌｉｓｔという名称のリソースラベルを調べて、パラメータとしてｔａｒｇｅｔ＿ｃｏｎｔａｃｔ＿ｉｄを有する対応するＡＰＩを呼び出すように通知する。データ取込みの終了時に、ストックのリストは、グラマーの一部としてダイアログに統合される。また、ストック識別に関してユーザが応答するものは何でも、対象のグラマーに対して整合され（ポートフォリオのストック）、ダイアログ応答に対するグラマリターン値を割り当てられる。この値は、ＤＩＡＬＯＧタイプのリソースとして次のダイアログに転送されることができる。
【００９２】
プロデューサは、＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＤＩＡＬＯＧ’ｎａｍｅ＝’ｄｉａｌｏｇ＿ｎａｍｅ’／＞を使用することによって、あらゆるその後のダイアログにおいてあらゆるダイアログリターン値を参照することができる。この規則により、プロデューサは、アプリケーション消費者が、任意の追従ダイアログにおいて以前に選択した選択肢を実演することが可能になる。
【００９３】
上記において示された第２のダイアログは、第１のダイアログから選択されたストックのクォートを実演し、次いで、フローを第１のダイアログに戻す。余分な分岐論理がこのダイアログには含まれていないので、この場合のダイアログのタイプは、ステートメントダイアログである。ダイアログの追従動作は、単に、フローを再び第１のダイアログに向けることである。そのような場合、ダイアログのステートメントは、以下のようになる。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＤＩＡＬＯＧ’ｎａｍｅ＝’ｓｅｌｅｃｔ  ｓｔｏｃｋ  ｄｉａｌｏｇ’／＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＡＤＡＰＴＥＲ’ｎａｍｅ＝’ｇｅｔ＿ｓｔｏｃｋ＿ｑｕｏｔｅ’＞
＜ｐａｒａｍ＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＤＩＡＬＯＧ’ｎａｍｅ＝’ｓｅｌｅｃｔ  ｓｔｏｃｋ  ｄｉａｌｏｇ’／＞
＜／ｐａｒａｍ＞
＜／ｒｅｓｏｕｒｃｅ＞
【００９４】
ＡＤＡＰＴＥＲ、ＤＩＡＬＯＧ、およびＳＹＳＴＥＭのタイプを参照することに加えて、ダイアログは、ＳＯＵＮＤおよびＳＣＲＩＰＴなどの他のリソースタイプも取り入れることができる。ＳＯＵＮＤは、音声クリップをダイアログ記述に挿入することによって、ダイアログ記述を擬人化するために使用することができる。たとえば、ストッククォートの後で音声を実演するために、プロデューサは、ＡＤＡＰＴＥＲリソースタグの直後に＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＳＯＵＮＤ’ｎａｍｅ＝’ｂｅｅｐ’／＞を挿入する。プロデューサは、＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ＝’ＲＥＳＯＵＲＣＥ’ｎａｍｅ＝’ｃｏｎｆｉｒｍ’／＞を使用することによって、特注ＶＸＭＬスクリプトをダイアログ記述に追加することができ、それにより、好ましい実施形態では、最大の柔軟性および拡張性を有して、任意のＶＸＭＬをダイアログコンテキストに透過的に統合することができる。
【００９５】
当業者には、本明細書において引用される例は、ＶＸＭＬおよびＸＭＬをマークアップ言語およびタグとして使用するが、本明細書では、本発明の精神および範囲から逸脱せずに、他の適切なマークアップ言語を代わりに使用することができる、または記述された慣習と統合することができることに留意されることが、明らかになるであろう。また、当業者には、本発明は、一般にＨＴＴＰ要求および応答を使用する電話サーバへのインタフェースを有するボイスアプリケーションサーバについてまず記述されているが、本発明は、任意の分散ネットワークにわたって明確な要求および応答に対処することができる任意のシステムにおいて実施することができることに留意すべきであることが、明らかになるであろう。
【００９６】
図７〜図１５は、図１Ｂの局１４０のＣＬ１４１と同様のデベロッパプラットフォームインタフェースの様々な表示ブラウザフレームを示す。以下のインタフェースフレームおよびフレーム内容の記述は、図１Ｂの局１４０と同様のデスクトップコンピュータホストの存在を想定し、対話は、たとえばインターネットネットワーク上での展開の場合のように、ＨＴＴＰ要求／応答フォーマットにおいて可能になる。しかし、以下の記述は、異なるプロトコル、ネットワーク、インタフェースの設計、およびオペレーションの範囲を変更することができるような任意の方式で、本発明の方法および装置を決して限定するべきではない。
【００９７】
図７は、本発明の一実施形態による、デベロッパのログインスクリーン７００を含むデベロッパのフレーム平面図である。フレーム７００は、本発明の一実施形態によるウエブブラウザコンテナの形態でデベロッパに呈示される。商用ウエブブラウザはよく知られており、任意の適切なウエブブラウザが、プラットフォームを支援する。フレーム７００は、バック、フォーワード、ゴー、ファイル、エディット、ビューなどを含めて、ほとんどのウエブブラウザフレームと関連付けられたすべての従来のウエブ選択肢を有する。この例では、ナビゲーションツールバーを見ることができる。スクリーン７１０は、ログインページである。デベロッパは、一実施形態では、デベロッパのアカウントを有することが可能である。他の場合、２つ以上のデベロッパが、単一のアカウントを共有することが可能である。多くの可能性が存在する。
【００９８】
スクリーン７１０は、ログインＩＤを挿入するためのフィールド、およびログイン個人識別番号（ＰＩＮ）を挿入するためのフィールドを有する。ログインパラメータが入力された後、デベロッパは、ログインと名称付けされたボタンをクリックすることによってデータを提出する。スクリーン７１０は、デスクトップコンピュータ、または、いくつかの他のネットワーク可能デバイス上で使用される表示のための規定フォーマットに従うそれらの特定のデバイスのいずれか１つにおいて表示されるように構成されることが可能である。
【００９９】
図８は、図７のデベロッパのプラットフォームインタフェースのホームページのスクリーンショットを含むデベロッパのフレーム８００の平面図である。フレーム８００は、全スクリーンまたは表示領域を埋めるように組み合わされた、ウエルカムセクション８０１、製品識別セクション８０２、およびナビゲーションセクション８０３を備えるセクション化スクリーンを含む。発明者によって作り出されたボイスアプリケーションデベロッパのプラットフォームの商用名は、名称フォンネット（Ｆｏｎｅｌｅｔ）である。ナビゲーションセクション８０３は、「ホームページ」およびソフトウエアツールの後続フレームに表示されるために提供される。
【０１００】
ナビゲーションセクション８０３は、上部から下部まで読むと、複数の有用なリンクを含む。ホームへのリンクで始まり、アドレスブックへのリンクが続く。新しいフォンネット（ボイスアプリケーション）を創出するためのリンクが、クリエートニュー（Ｃｒｅａｔｅ  Ｎｅｗ）と名称付けされる。「マイ（Ｍｙ）」フォンネットへのリンクが、「オプションズ（Ｏｐｔｉｏｎｓ）」へのリンクと共に提供される。標準的なヘルプリンクが、ログアウト（Ｌｏｇｏｕｔ）へのリンクと共に示されている。追加の「オプションズメニュー（Ｏｐｔｉｏｎｓ  Ｍｅｎｕ）」が、セクション８０３において最後のリンクとして示されている。セクション８０３は、追加のリンクを有することが可能であり、この追加のリンクは、この例の表示タイプには一般的である提供されるスクロールバーでスクロールダウンすることによって見ることができる。
【０１０１】
図９は、図８の前のフレームのセクション８０３にある選択肢アドレスとの対話によりアクセス可能であるアドレスブック９１１のスクリーンショットを含む、デベロッパのフレーム９００の平面図である。スクリーン９１１は、個々の接点を列挙し、かつ接点リストを列挙するための対話選択肢である。接点リストは、ボイスアプリケーション消費者のリストであり、この例では、単一接点が１人の消費者を表す。しかし、他の実施形態では、単一接点が、２つ以上のエンティティ意味することが可能である。ナビゲーションスクリーン８０３は、スクリーン９１１の左側に表示される。この例では、接点は、ファーストネーム（Ｆｉｒｓｔ  Ｎａｍｅ）、続いてラストネーム（Ｌａｓｔ  Ｎａｍｅ）、続いて電話番号、および電子メールアドレスが列挙される。本発明の精神および範囲から逸脱せずに、他の接点パラメータが包含または排除されることも可能である。たとえば、接点のウエブサイトが列挙されることが可能であり、ボイスアプリケーションを受けるインタフェースとすることも可能である。列挙された接点の左に、選択および構成のために使用される対話選択ボックスがある。対話選択肢は、ウエブボタンの形態で表示され、デベロッパが接点を追加または削除することを可能にするように構成される。
【０１０２】
図１０は、新しいボイスアプリケーションを創出するためのスクリーン１００１を表示するデベロッパのフレーム１０００の平面図である。スクリーン１００１は、発明者によってフォンネットと名づけられた新しいボイスアプリケーションの創出を開始する。名称フィールド１００２が、アプリケーションの名称を入力するためにスクリーン１００１において提供される。記述フィールド１００３が、アプリケーション記述を入力するために提供される。特性セクション１００４が示され、デベロッパが、適切なチェックボックスをクリックすることによって、パブリック（公的）（Ｐｕｂｌｉｃ）、パーシスタント（永続的）（Ｐｅｒｓｉｓｔｅｎｔ）、およびシェアラブル（共有可能）（Ｓｈａｒｅａｂｌｅ）と列挙された利用可能な選択肢から選択することを可能にするように構成される。
【０１０３】
ダイアログフローセットアップ（Ｄｉａｌｏｇ  Ｆｌｏｗ  Ｓｅｔｕｐ）セクションが提供され、ダイアログタイプセクションフィールド１００５、および接点または接点グループを選択するための後続フィールド１００６を含む。必要な情報が適切なフィールドに適切にポピュレートされた後、デベロッパが、クリエート（創出）（Ｃｒｅａｔｅ）と名称付けされた対話選択肢１００７をクリックすることによって、ダイアログを「創出」することが可能である。
【０１０４】
図１１は、スクロールダウンの結果としてさらに選択肢を示す図１０のスクリーン１００１を示すデベロッパのフレーム１１００の平面図である。コーリングスケジュール構成セクション１１０１が示されており、オンデマンド（Ｏｎ  Ｄｅｍａｎｄ）またはスケジュール済み（Ｓｃｈｅｄｕｌｅｄ）の対話選択肢を提供する。以前に記述されたように、オンデマンド（Ｏｎ  Ｄｅｍａｎｄ）を選択することにより、デベロッパの意思でアプリケーションを配置することが可能になり、一方、スケジュール済みを選択することにより、時間／日付けパラメータに従ってスケジュール済み配置を構成することが開始される。エントリフィールド１１０２のグループが、開始のタイムゾーン（Ｔｉｍｅ  Ｚｏｎｅ）および月（Ｍｏｎｔｈ）を構成するために提供される。エントリフィールド１００３の後続グループが、スケジュール済み開始の曜日（ｔｈｅ  Ｄａｙ  ｏｆ  Ｗｅｅｋ）および月日（ｔｈｅ  Ｄａｙ  ｏｆ  Ｍｏｎｔｈ）を構成するために提供される。エントリフィールドの後続グループ１１０４が、スケジュール済み開始の時および分を構成するために提供される。本明細書では、選択肢により、同じアプリケーションの反復開始が可能になることに留意されたい。デベロッパが、ボイスアプリケーションシェルの規定を終了した後、デベロッパは、ダイアログ創出のための重複ブラウザウィンドウを作成するために、クリエート（創出）（Ｃｒｅａｔｅ）と名称付けされたクリエートダイアログ（Ｃｒｅａｔｅ  Ｄｉａｌｏｇ）ボタンをクリックすることができる。
【０１０５】
図１２は、本発明の一実施形態による、ダイアログ構成ページを示すダイアログ構成ウィンドウ１２００のスクリーンショットである。このウィンドウにおいて、デベロッパは、ボイスアプリケーションまたはフォンレットが連結される第１のダイアログを構成する。ダイアログ識別セクション１２０１が、創出されるダイアログを識別して記述するために提供される。ダイアログ名を入力するためのテキストエントリフィールド、およびダイアログ記述を入力するためのテキストエントリフィールドが提供される。ダイアログ記述フィールド内において、ＸＭＬリソースタグ（図示せず）が挿入され、これは、たとえば、図１Ｂを参照して記述されたアダプタ１１３およびアプリケーションサーバ１１０と同様のアプリケーションサーバ内のリソースアダプタに登録された、リソースラベルマシンコードを指すことが可能である。
【０１０６】
セクション１２０２が、スクリーン１２００内において提供され、デベロッパが予期される応答について構成することを可能にするように構成される。この場合、ダイアログのタイプは、ラジオダイアログ（Ｒａｄｉｏ  Ｄｉａｌｏｇ）である。セクション１２０２は、複数選択肢様ダイアログのためのビジネス規則論理制御として作用する。セクション１２０２は、ハイまたはイイエの応答のための選択選択肢を含む。本明細書では、単一のハイまたはイイエの応答の他に、より多くの異なる予期応答が存在することが可能であることに留意されたい。
【０１０７】
隣接セクションが、ダイアログに対する実際の応答の結果として生じる、任意のフォローアップアクション（Ｆｏｌｌｏ−Ｕｐ  Ａｃｔｉｏｎ）を構成するために、セクション１２０２内において提供される。たとえば、ノーアクション（Ｎｏ  Ａｃｔｉｏｎ）を選択する選択肢が、ハイ（Ｙｅｓ）およびイイエ（Ｎｏ）の各予期応答について提供される。追従動作の場合、コネクト（接続）（Ｃｏｎｎｅｃｔ）の選択肢が、各予期応答に提供される。各示されるコネクト（接続）（Ｃｏｎｎｅｃｔ）選択肢に隣接して、セレクト（選択）（Ｓｅｌｅｃｔ）フィールドが、データの取込みを含むことが可能である追従動作を選択するために提供される。
【０１０８】
センド（送信）（Ｓｅｎｄ）選択肢が、任意の埋込みデータを含めて選択された追従動作の送信を可能にするために提供される。追従動作は、新しい無線ダイアログを送信する、マシン修理要求を送信するなど、任意のタイプの構成応答とすることが可能である。選択肢および関連選択選択肢への送信が、追従動作の受信者を識別し、かつ動作を受信者に自動的に送信することを可能にするために提供される。たとえば、第１のダイアログが、複数の内部周囲技術者に送信されるマシン修理サービスの要求である場合、追従は、第１の接点がジョブを受け取ることを拒否した事象、または第１の接点が配置時間に利用可能ではなかった事象において、同じダイアログを次の利用可能な接点に送信するとすることが可能である。
【０１０９】
上記の場合、ダイアログは、接点の１つが利用可能であり、ジョブを受け取ることによってダイアログと対話することを選択するまで、リストを下方に接点から接点へ伝播することが可能である。この場合の追従は、問題の診断データを含めてどのマシンを修理すべきか、およびいつ修理が行われるべきであるかのパラメータを詳述する、新しいダイアログを受入れ接点に送信するとすることが可能である。この例では、詳細を示す選択肢が、デベロッパがレビューするために提供される。また、新しいまたは追加の応答を創出し、かつシステムから既存の応答を削除するための対話選択肢も提供される。本明細書では、ダイアログおよびダイアログ応答が創出された後、ダイアログおよびダイアログ応答は、ボイスアプリケーション全体にわたって、かつボイスアプリケーションの任意の指定シーケンスにおいて、再使用可能であることに留意されたい。
【０１１０】
セクション１２０３が、スクリーン１２０１に提供され、ルートツー接続例外（Ｒｏｕｔｅ−Ｔｏ  Ｃｏｎｎｅｃｔｉｏｎ  Ｅｘｃｅｐｔｉｏｎ）に対処するように構成される。このセクションにより、デベロッパが、アプリケーション配置において可能性のある接続状態を経験する場合に、何をすべきかを構成することが可能になる。たとえば、発呼者拒否（Ｃａｌｌｅｒ  Ｒｅｊｅｃｔ）、ラインビジー（Ｌｉｎｅ  Ｂｕｓｙ）、またはボイスメール（Ｖｏｉｃｅ  Ｍａｉｌ）への接続について、示されるように、ノーアクション（Ｎｏ  Ａｃｔｉｏｎ）およびリダイヤル（Ｒｅｄｉａｌ）の選択肢が存在する。本明細書では、本発明の精神および範囲から逸脱せずに、この例において示されるより多くの例外（Ｅｘｃｅｐｔｉｏｎｓ）ならびに追従（Ｆｏｌｌｏｗ−ｕｐ）動作のタイプが存在することが可能であることに留意されたい。
【０１１１】
センド（送信）（Ｓｅｎｄ）選択肢が、隣接ドロップダウンメニューから選択されることが可能である、同じまたはあらゆる他のダイアログを再送信するために各タイプの例外について提供される。たとえば、第１のダイアログが修理サービスの要求であり、たとえば、すべての初期接点がビジーである場合、ダイアログは、まず各ビジー信号後に送信のための次の接点に移行し、次いで再ダイヤルの際に再びリストの上部において開始することによって、１つが利用可能になるまで、すべての接点に送信して戻されることが可能である。この場合、ジョンドウ（Ｊｏｈｎ  Ｄｏｅ）は、先行接点がダイアログを拒否した後、ビジーである後、または利用不可能であるためにボイスメールに向け直された後の次の受信者を示す。セクション１２０３は、ボイスアプリケーションがアウトバウンドに設定されるときのみ可能になる。第１のダイアログがデベロッパによって創出され、かつ可能になった後、詳細と名称付けられた利用可能なボタンの１つをクリックすることによって、第２のダイアログが、所望であれば創出されることが可能である。また、ダイアログ保存（Ｓａｖｅ  Ｄｉａｌｏｇ）、保存および閉鎖（Ｓａｖｅ  ａｎｄ  Ｃｌｏｓｅ）、ならびに変化させず（Ｕｎｄｏ  Ｃｈａｎｇｅｓ）の対話ボタンも提供される。
【０１１２】
図１３は、後続接点へのダイアログ状態の進行を示す、図１２のダイアログ設計パネル１２００のスクリーンショット１３００である。図１２の例において構成されたダイアログ状態は、ここで、図１２のセクション１２０１と同様であるセクション１３０１において、ルートフロム（Ｒｏｉｕｔｅ  Ｆｒｏｍ）において列挙される接点から、ルートツー（Ｒｏｕｔｅ  Ｔｏ）に列挙される接点に送信される。この場合、含まれる接点は、ジョンドウおよびジェーンドウ（Ｊａｎｅ  Ｄｏｅ）である。この場合、ダイアログの名称および記述は、ダイアログが再使用されているので同じである。デベロッパは、ダイアログコンテキストのいずれも再入力する必要はない。しかし、各ダイアログが受信者と固有の関係を有するので、デベロッパは、対応するビジネス規則を構成しなければならない。
【０１１３】
この例のセクション１３０２および１３０３は、図１２の以前の例のセクション１２０２および１２０３と同様である。この場合、ジョンドウが、マシンの修理の要求に対してイイエと言う場合、システムは、ジェーンドウへのブリッジ移行を実施する。ルートツー接続例外（Ｒｏｕｔｅ−Ｔｏ  Ｃｏｎｎｅｃｔｉｏｎ  Ｅｘｃｅｐｔｉｏｎｓ）領域１３０３において示される例外の場合、すべての事象は、再ダイヤルルーチンに向けられる。応答フィールド１３０２において「ハイ」または「イイエ」などのキーワードを挿入することに加えて、デベロッパは、この例では図示されていない提供されるシソーラスをクリックすることによって、特注シソーラスを創出することができる。シソーラスのすべての創出語彙は、デベロッパが創出する任意のボイスアプリケーションにわたって、後に再使用することができる。
【０１１４】
図１４は、好ましい実施形態による図１３の例から活動化されるシソーラス構成ウィンドウ１４００のスクリーンショットである。シソーラスウィンドウ１４００は、語彙ワードを名称付けするためのフィールド、および名称付きワードの類義語を列挙するための関連フィールドを含むセクション１４０１を有する。この例では、そのワードは、可能な応答ｎｏ、ｎｏｐｅ、および句「できない（Ｉ  ｃａｎ  ｎｏｔ  ｍａｋｅ  ｉｔ．）。」に関連付けられる。このようにして、ボイス認識体制は、同じ意味を所持する可能性がある応答の変形に対応するように、個人化された方式で調整されることができる。
【０１１５】
語彙セクション１４０２が提供され、列挙されたワードの１つを選択するために、ボイスアプリケーションおよび選択機構（この場合は選択バー）についてすべての創出された語彙ワードを列挙するように構成される。新しいワードおよび同義語の対を創出する選択肢も、セクション１４０２において提供される。制御パネルセクション１４０３が、ウィンドウ１４００内において提供され、シソーラスから選択する（Ｓｅｌｅｃｔ  Ｆｒｏｍ  Ｔｈｅａｓｕｒｕｓ）、シソーラスを更新する（Ｕｐｄａｔｅ  Ｔｈｅａｓｕｒｕｓ）、シソーラスから削除する（Ｄｅｌｅｔｅ  Ｆｒｏｍ  Ｔｈｅａｓｕｒｕｓ）、およびシソーラスを出る（Ｅｘｉｔ  Ｔｈｅａｓｕｒｕｓ）を制御するように構成される。
【０１１６】
図１５は、本発明の一実施形態による、創出モジュールを管理するためのスクリーン１５０２を示すデベロッパのフレーム１５００の平面図である。
【０１１７】
すべてのダイアログウィンドウを閉じた後、フレーム１５００は、モジュール管理選択肢のためのスクリーンまたはページ１５０２を表示する。メニュー選択８０３が、再び見られることが可能である。スクリーン１５０２は、フレーム８０３の「マイ（Ｍｙ）」またはマイフォンレット（Ｍｙ  Ｆｏｎｅｌｅｔ）の選択肢をクリックする結果として表示される。スクリーン１５０２は、すでに創出されかつ使用可能であるすべてのボイスアプリケーションを列挙する。このリストにおいて、各ボイスアプリケーションは、隣接するチェックボックスを有し、これは、特定のアプリケーションの状態を変化させるために選択されることができる。ステータス（Ｓｔａｔｕｓ）と名称付けされた列が、スクリーン１５０２内において提供され、アプリケーションがすでに創出したアプリケーションリストに隣接して配置される。
【０１１８】
ステータス（Ｓｔａｔｕｓ）列は、各ボイスアプリケーションの変更可能状態を列挙する。利用可能な状況選択肢は、非活動（Ｉｎａｃｉｔｖｅ）、活動化（Ａｃｔｉｖａｔｅｄ）、およびインバウンド（Ｉｎｂｏｕｎｄ）の列挙状態を含むが、これらに限定されるものではない。直接アクセス（Ｄｉｒｅｃｔ  Ａｃｃｅｓｓ）ＩＤと名称付けされた列が、ステータス（Ｓｔａｔｕｓ）列に隣接して提供され、デベロッパが、ＰＳＴＮネットワークのボイスインタフェースにより、また一実施形態ではＤＮＴボイスインタフェースから、ボイスアプリケーションに直接アクセスすることを可能にするように構成される。ＰＳＴＮ実施形態では、直接アクセスＩＤ能力は、中央電話番号の拡張子として作用する。アクション（Ａｃｔｉｏｎ）と名称付けられた次の列が、直接アクセスＩＤ列に隣接して提供され、デベロッパが、ボイスアプリケーションの状態に関して、特定の動作を選択して適用することを可能にするように構成される。
【０１１９】
たとえば、デベロッパが、アプリケーション識別リストの上部に列挙されるフィールドサポートセンタ（ＦＳＣ）として識別されるボイスアプリケーションを終了したばかりであると想定する。現在、ＦＳＣの列挙された状態は、非活動である。ここで、デベロッパは、関連付けられたアクション（Ａｃｔｉｏｎ）ドロップダウンメニューを活動化させて、アプリケーションＦＳＣをオンデマンドで開始するために、活動化（Ａｃｔｉｖａｔｅ）を選択する。スケジュール済み開始の場合、ボイスアプリケーションは、ボイスアプリケーションシェルにおいて確定されるセッティングに従って自動的に活動化される。
【０１２０】
活動化（Ａｃｔｉｖａｔｅ）コマンドが出されるとすぐに、オンデマンド要求は、システムのアウトバウンドアプリケーションサーバを経て送られるように、キューに入れられる。たとえば、ジョンドウは、次いで、ジョンはコールを受け取るのを待機しているかを質問する、ボイスアプリケーションサーバ（１１０）から発信されるコールを受信する。ジョンが「ハイ」と応答する場合、ボイスアプリケーションは実行される。実際のコールフローは、以下の通りである。すなわち、
システム、「こんにちは、ジョン。ジムドウさんからフォンレットを受信しました。このコールを受け取ることを望みますか？（Ｈｅｌｌｏ  Ｊｏｈｎ，ｙｏｕ  ｒｅｃｅｉｖｅｄ  ａ  ｆｏｎｅｌｅｔ  ｆｒｏｍ  Ｊｉｍ  Ｄｏｅ，ｗｏｕｌｄ  ｙｏｕ  ｌｉｋｅ  ｔｏ  ｔａｋｅ  ｔｈｉｓ  ｃａｌｌ？）」
ジョン、「ハイ（Ｙｅｓ．）。」
システム、「マシン番号００８は壊れています、これを修理できますか？（Ｍａｃｈｉｎｅ  ｎｕｍｂｅｒ  ００８  ｉｓ  ｂｒｏｋｅｎ，ａｒｅ  ｙｏｕ  ａｖａｉｌａｂｌｅ  ｔｏ  ｆｉｘ  ｉｔ？）」
ジェーン、「イイエ（Ｎｏ．）。」
システム、「フォンレットをご利用いただきありがとうございます、さようなら（Ｔｈａｎｋｓ  ｆｏｒ  ｕｓｉｎｇ  ｆｏｎｅｌｅｔ．Ｇｏｏｄｂｙｅ！）。」
【０１２１】
システム、ジョンとの接続を終了し、コールフローをデータソースに記録し、ジェーンドウへの新しいコールを生産する。
システム、「こんにちは、ジョン。ジムドウさんからフォンレットを受信しました。このコールを受け取ることを望みますか？（Ｈｅｌｌｏ  Ｊａｎｅ，ｙｏｕ  ｒｅｃｅｉｖｅｄ  ａ  ｆｏｎｅｌｅｔ  ｆｒｏｍ  Ｊｉｍ  Ｄｏｅ，ｗｏｕｌｄ  ｙｏｕ  ｌｉｋｅ  ｔｏ  ｔａｋｅ  ｔｈｉｓ  ｃａｌｌ？）」
ジェーン、「ハイ（Ｙｅｓ．）」
システム、「マシン番号００８は壊れています、これを修理できますか？（Ｍａｃｈｉｎｅ  ｎｕｍｂｅｒ  ００８  ｉｓ  ｂｒｏｋｅｎ，ａｒｅ  ｙｏｕ  ａｖａｉｌａｂｌｅ  ｔｏ  ｆｉｘ  ｉｔ？）
ジェーン、「できません（Ｉ  ｃａｎｎｏｔ  ｍａｋｅ  ｉｔ．）。」
システム、「フォンレットがあなたをジェフドウさんに転送する間、お待ちください（Ｐｌｅａｓｅ  ｗａｉｔ  ｗｈｉｌｅ  ｆｏｎｅｌｒｔ  ｔｒａｎｓｆｅｒｓ  ｙｏｕ  ｔｏ  Ｊｅｆｆ  Ｄｏｅ．）。」。
【０１２２】
システム、ジェーンドウとジェフドウとの間でブリッジ移行を実施する。会話が終了したとき、ジェフとの接続を終了し、コールフローをデータソースに記録する。
【０１２３】
ボイスアプリケーションのデフォルトテキスト内容は、電話またはＤＮＴサーバ上にホストされるテキストスピーチエンジンによって生成されている。しかし、ボイスアプリケーションプロデューサは、ＰＳＴＮサーバまたはＤＮＴサーバを経てボイスポータルにアクセスして、ボイスアプリケーションの任意の既存のプロンプト上においてボイスアプリケーションプロデューサのボイスを記録することができる。
【０１２４】
当業者には、本発明の方法および装置は、ＣＴＩ可能電話環境と関連して実施されることが可能であることが明らかになるであろう。この場合、アプリケーション展開のためのデベロッパのアクセスは、アプリケーションおよび電話構成要素を作成するサーバへの接続性をも有するデータネットワークに接続された計算局において実行されるクライアントアプリケーションにより可能になる。本発明の方法および装置は、ＤＮＴベースであるシステムにおいても実施されることが可能であり、この場合、電話サーバおよびアプリケーションサーバは、両方とも、よく知られているインターネットネットワークなどのデータネットワークに接続される。ＶＸＭＬおよびまたは同様の目的を果たすことが可能である他の適用可能マークアップ言語について可能にされた任意の適切な複数層システムを含めて、通信環境のすべての混合体についてアプリケーションが存在する。当業者には、個々のダイアログおよび応答を含めてボイスアプリケーションをモデリングすることにより、すべてのデベロッパが、モジュール方式で既存のオブジェクトを再使用することによって、無制限に広範なボイスアプリケーションを迅速に創出することが可能になり、それにより、オブジェクトの既存ストアから広範な有用なアプリケーションが可能になることも明らかになるであろう。
【０１２５】
ウエブデータの自動取入れ
本発明の他の実施形態では、１つまたは複数のウエブサイトは、ＰＳＴＮベースポータルにより動作するユーザによってアクセス可能なボイス応答を生成するために、ＶＸＭＬエンジンによってレンダリングされるデータについて、自動的に取り入れることができる。そのような改良が、すぐ下において記述される。
【０１２６】
図１６は、本発明の一実施形態による、ウエブ取込みについて改良された図６のダイアログ移行フローを示すブロック図である。ダイアログ制御装置６０４は、この実施形態では、ＨＴＭＬ、ＷＭＬ、またはウエブサイトにホストされるデータの場合のように他のデータソースからデータにアクセスして、データを取り入れるように改良される。この実施形態の例示的なシナリオは、すべての顧客が、ボイスポータルを経てウエブサイトにアクセスすることを可能にするバンキング状況のシナリオである。
【０１２７】
ウエブサイト１６００が、この実施形態において示され、２方向通信線として本明細書では示されるネットワークアクセス線１６０１を介して、ダイアログ制御装置６０４にアクセス可能である。第１の線は、ストア／フェッチ／インプットと名称付けされ、制御装置６０４からサイト１６００に至る。第２の（リターン）線は、データリターン／ソースフィールドと名称付けされる。別々に示される通信線は、双方向インターネットまたは他のネットワークアクセス線と同様であることを意図する。上記で図６を参照して以前に記述された内部データソース（６０２）は、図１６では説明のためにのみウエブサイト１６００によって置き換えられる。サーバ１１０の内部、およびサーバ１１０の外部の両方の複数データソースが、ダイアログ制御装置６０４に同時にアクセス可能であることに留意されたい。
【０１２８】
ウエブサイト１６００は、少なくとも１つの電子情報ページ（ウエブぺージ）を提供し、このページは、創出および保全のために使用されるマークアップ言語の既存規則に従ってフォーマットされる。サイト１６００は、多くの情報ページをホストとする１つのサイトとすることが可能であり、ページのいくつかは、相互に関係付けられ、後続ナビゲーション動作によりアクセス可能である。この実施形態の制御装置６０４は、アクセス規則エンジン６０３によってアクセス可能である規則によって可能になるユーザのボイス入力の指示で、ウエブサイトナビゲーションについて改良される。データテンプレート（図示せず）が、サイト１６００から論理データポピュレーションを容易にするために、ダイアログ制御装置６０４によって使用されるために提供される。ダイアログ制御装置６０４は、リターンデータとしてウエブサイトソースコードおよびデータフィールドの両方を分析し、レンダリングエンジン１１１のＶＸＭＬページを生成するために、情報を使用する。
【０１２９】
本明細書では、通常のインターネットアクセスのためにサイトにおいて使用されるセキュリティおよびアクセス機構のすべてが、顧客について推測され、それにより、顧客は、セキュリティアクセス情報を含むボイスレンダリング（応答）を提供することによって、アクセスを許可されることが可能であることに留意されたい。これにより、顧客は、ポータルを経たボイストランザクション、ならびにネットワーク接続コンピュータからサイト１６００への通常のウエブアクセスについて、同じセキュリティパスワードおよび／またはパーソナル識別番号（ＰＩＮ）を維持することが可能になる。
【０１３０】
図１７は、本発明の一実施形態による、自動ウエブ取入れおよびデータレンダリングのための追加構成要素を示す、図１Ｂのボイスアプリケーション分散環境のブロック図である。この例では、クライアントソフトウエア１４１を実行するワークステーション１４０は、対象ウエブサイト１６００をホストするネットワークサーバ１７０１への直接アクセスを有する。アクセスは、インターネットアクセス線１７０４によって提供される。
【０１３１】
本明細書では、本発明の精神および範囲から逸脱せずに、この実施形態では多くのサーバ１７０１、ならびに１つまたは複数のページの多くのホストされるウエブサイトが存在することが可能であることに留意されたい。データベースストア１７０２が、この例では提供され、データを記憶するためにサーバ１７０１に接続されて示されている。データストア１７０２は、光学記憶装置、磁気記憶装置、ハードディスク、またはオンラインでアクセス可能なデータを記憶するのに適切な他の形態とすることが可能である。一実施形態では、データストア１７０２は、関係データベース管理システム（ＲＤＢＭＳ）であり、単一アクセスが、やはりアクセスのためにデータを記憶する１つまたは複数の接続されたサブサーバを含むことが可能である。
【０１３２】
ネットワーク１７０４によって接続された、クライアントアプリケーション１４１、ワークステーション１４０、サーバ１７０２、ウエブサイト１６００、およびデータベース１７０２の構成により、サイト１６００と同様のウエブサイトが選択される、または取り入れられることが可能になる。アプリケーション１４１は、他のマークアップ言語の各ＨＴＭＬスクリプトまたは複数のスクリプトについて存在するすべてのデフォルト応答を読み取り、かつ取り出すことができる。これらのデフォルト応答は、アプリケーション論理１１２およびＶＸＭＬレンダリングエンジン１１１に埋め込まれる。ウエブページの内容が、レンダリングを創出するために、クライアント１４１において選択されて使用された後、ＶＸＭＬエンジン１１１は、別々のアクセスネットワーク１７０３によって、アプリケーション論理１１２およびデータベース／リソースアダプタ１１３と首尾よく組み合わされて、ウエブサイトにアクセスすることができる。たとえば、ユーザ（図示せず）が、受信デバイス１３５（電話）からボイスポータル１４３を経てウエブサイト１６００にアクセスする場合、ユーザは、サイトへのアクセスを得るために、パスワードについてボイスで促される。その後、アクセスサイトにおけるデータのボイスレンダリングが、電話１３５によりユーザに呈示される。
【０１３３】
一般的に、ボイスポータルの展開プロセスは、上記で図９〜図１５を参照して上記で記述された展開プロセスと同じである。いくつかの追加のスクリプトまたはダイアログの入力が、クライアントアプリケーション１４１を使用して実施される。アプリケーションデベロッパが、すべてのフィールドをスクラッチからポピュレートする、または以前に入力された選択肢を再適用するのではなく、図９から図１５において以前に議論されたビジネス論理によって使用されるフィールドが、この場合は、サイト１６００から取り入れられた情報から創出されることが可能である。そのために、ソフトウエアアダプタ（図示せず）が、クライアントソフトウエア１４１に追加され、クライアントソフトウエアが、ウエブサイト１６００と通信して、フィールドおよびラベルなどを備えるソースコード、ならびにデータパラメータおよびデータ変数の両方から情報を取り入れることを可能にする。
【０１３４】
本明細書では、データアクセス、取り出し、およびボイスレンダリングのプロセスは、本質的に、上記の図２〜図５のプロセスに関して同じであるが、ウエブサイト接続が、あらゆる他の選択肢が選択される前に確立される点が異なることに留意されたい。
【０１３５】
一実施形態では、サーバ１１０とサーバ１７０１との間の接続１７０３の提供により、安全ソケット層（ＳＳＬ）、ファイアウォールなどの通信機械間において実施されるセキュリティ環境が、顧客に関して創出されたボイスソリューションにおいて適用されることが可能になる。アナログ側では、セキュリティは、ワイヤタップ確率などに関してバンキングサービスを可能にする、コールイン線のセキュリティと異ならない。
【０１３６】
当業者には、本発明の方法および装置は、インターネット、イーサネット（登録商標）、またはあらゆる他の適切なネットワークと関連して実施することができることが明らかになるであろう。支援されるマークアップ言語には、ＨＴＭＬ、ＳＨＴＭＬ、ＷＭＬ、ＶＨＴＭＬ、ＸＭＬなどがある。一実施形態では、アクセスされるウエブサイトは、自動的にアクセスされることが可能であり、この場合、ユーザのパスワード情報は、サイト自体において維持される。多くの可能なシナリオが存在する。
【０１３７】
ボイスレンダリングのためのウエブデータの優先順位付け
本発明の一態様によれば、取り入れられたウエブサイトからどのウエブデータ提供が、ボイスアプリケーションのテンプレートに充填されるかを選択して、かつ優先順位を付ける方法が提供される。
【０１３８】
図１８は、ウエブサイト１８０１およびサイトの取入れバージョン１８１０の簡単な階層構造ツリーを示すブロック図である。スクリーン１８０１は、ユーザインタフェースから見ることが可能である簡単なウエブサイト構造ツリーを示す。データ要素を表す選択可能なアイコンが、本明細書では実線１８０２ａから１８０２ｎとして表され、任意の例示的なウエブサイト内において、任意の数のアイコンが提供されることが可能であることを示唆する。本明細書の目的では、アイコン１８０２ａ〜１８０２ｎは、選択可能なアイコン、ロゴ、ハイパーリンクなどを表す。各オブジェクト１８０２ａ〜１８０２ｎの分類は、本明細書では、テキストラベル１８０３ａから１８０３ｎとして示される。たとえば、選択可能なアイコン１８０２ａは、隣接分類１８０３ａによって明らかにされるサイトの「ホームページ」へナビゲートするためのアイコンである。後続アイコン（１８０２ｂ）は、分類ログインによって明らかにされるサイトのログインページである。いくつかの場合、アイコンおよび分類またはラベルは、同じとする（異なるようには見えない）ことが可能である。
【０１３９】
この例では、階層構造は、他の選択肢が呈示される前に、ユーザが首尾よくナビゲートしなければならないログインブロックを呈示する。呈示される選択肢アカウント（Ａｃｃｏｕｎｔｓ）、ステータス（Ｓｔａｔｕｓ）、ヒストリ（Ｈｉｓｔｏｒｙ）、ルックアップ（Ｌｏｏｋ−ｕｐ）、トレード（Ｔｒａｄｅ）、およびクォート（Ｑｕｏｔｅｓ）は、階層構造で構成される。たとえば、ステータス（アカウント／ステータス）またはヒストリ（アカウント／ステータス／ヒストリ）の選択肢がユーザにとって利用可能となる前に、アカウントにまずアクセスしなければならない。この標準的な構造は、ダイアログナビゲーションのボイスアプリケーションテンプレートを創出するためにテンプレートに埋め込むには、不都合で非経済的である可能性がある。１つの理由は、ボイスアプリケーションは、ウエブサイトのデータのすべてを使用することを試行して創出されるからであり、データは、記述が、簡単に変換されて、電話でボイスダイアログとして呈示される場合、アクセスユーザによって理解されないグラフィック、チャートなどを含む可能性が高いことである。他の理由は、ウエブサイト構造１８０１の一般的な階層は、要求／応答フォーマットにおいてボイスダイアログとしてレンダリングするのに望ましい階層ではない可能性があるからである。通常、あるデータは価値があり、あるデータは価値がなく、ダイアログレベルにおいて呈示される命令データは、ユーザならびにアドミニストレータ（サービスプロバイダ）にとって重要である。
【０１４０】
スクリーン１８１０は、完全に取り入れられたスクリーン１８０１の同じ構造を表し、サイトのソースコードにおいて識別されたアイコンおよび要素のすべては、可能なテンプレート充填のために得られている。テンプレートにより、ボイスアプリケーションが、アドミニストレータによって確立された制約に従って更新データを得て、かつ更新データをレンダリングする目的において動作することが可能になることに留意されたい。ウエブサイト１８１０は、テンプレート充填のために事前に準備される。アイコンが、１８１２ａから１８１２ｎまで名称付けされ、分類が、１８１３ａから１８１３ｎまで名称付けされる。
【０１４１】
オブジェクト１８１０が、グラフィック、チャート、ダイアログボックス、テキストリンク、データフィールド、およびＨＴＭＬまたはサイトの他の言語において呈示されて可能になるあらゆる他の提供特徴を含めて、ウエブサイトの一般的な構造をエミュレートするために生成される。ダイアログを受信するためにボイスポータルにアクセスする潜在的に多数のユーザに関わる軽減ファクタのために、ユーザにとって好都合であり、ならびにネットワークの負荷を安定させるように、多大な効率化が望ましい。したがって、望ましい選択および階層に従って、ボイスアプリケーションテンプレートを充填し、それにより、結果的なボイスアプリケーションのより経済的で最適化された構築および実行を容易にすることができるように、要素をオブジェクトモデリングし、ツリー階層を再組織化するための中間ステップが必要である。
【０１４２】
本発明のオブジェクトモデリングツールは、上記で図１Ｂを参照して記述されたクライアントアプリケーション１４１の一部として提供することができる。階層および所望の内容によって組織化された創出オブジェクトは、上記で図６を参照して記述されたアプリケーションサーバ１１０、またはボイスアプリケーションサーバ１１０にアクセス可能なローカルデータベースにおいて記憶することができる。
【０１４３】
図１９は、図１８のウエブサイト構造１８０１およびテンプレートを創出するために創出および編集されたウエブサイトオブジェクトを示すブロック図である。スクリーン１８０１は、要素および記述の両方について、図１８のスクリーン１８０１と同様である。したがって、図１８の構造１８０１に関して示された要素または要素の記述のいずれも再度紹介されない。
【０１４４】
スクリーン１９１０が、構造１８０１に関して記述された取入れウエブサイトを表すが、最適化方式でボイスアプリケーションテンプレートをポピュレートするために、要素優先順位付けで再組織化されている。この例では、取入れウエブサイトの当初の内容および構造を変更するために、多大な編集が実施されている。アイコン１９１２ａから１９１２ｎは、取入れ後に保持されているアイコンを示す。１９１３ａから１９１３ｎは、それらのオブジェクトの分類を表す。第１に、最適化が、構造１８０１においてホームおよびログインと名称付けされたアイコンに関して留意される。取入れオブジェクト１９１０のこれらの項目は、ログインと名称付けされ、要素番号１９１３ａを与えられる１つの指定オブジェクトに組み合わされることにより最適化されている。この場合、アカウントステータスおよびヒストリは、最も価値のある部分および最も一般的な要求情報を均衡させるように効率化される。また、この場合、ボイスダイアログとしてレンダリングされた場合に、理解されることが可能ではない、任意のチャート、グラフ、または他のビジュアルが、ボイスアプリケーションテンプレートから単に排除される。テンプレート充填前に組織化する中間ステップは、ウエブサイトデータを取り入れるステップと、ボイスアプリケーションヘッダをポピュレートするステップとの間に挿入される。
【０１４５】
ログインが成功し、ユーザが、ＰＩＮ／ユーザネーム／パスワード組合わせのボイスバージョンを入力して、ボイスポータルからボイスアプリケーションにアクセスするのを許可された後、この例の次の優先順位は、ユーザが、ユーザの１つまたは複数のアカウントバランスを迅速に決定することを可能にすることである。要素番号１９１２ｂおよび１９１２ｃは、２つのアカウントを想定する２つのバランスを表す。本発明の範囲から逸脱せずに、より多くまたはより少ない優先順位付けされたアイコンが存在することが可能である。この場合、最適化プロセスにより提供される第１の「ボイス選択肢」は、電話によって特定のユーザに呈示されるアカウントバランスを有する。本明細書において要素番号１９１３ｃから１９１３ｆによって示されるルックアップ、トレード、およびクォートの他の現在提供されている選択肢は、より高いが、同じレベルのアーキテクチャまたは構造に移行され、これは、同じ重要レベルを提供されることを意味する。すべてのこれらの選択肢の３つは、ユーザが、動作のいずれかを開始するために、ストック記号情報を含むユーザ要求または応答を使用することができるという点で、関係付けられる。
【０１４６】
図２０は、本発明を実施するための追加ステップを示すプロセス流れ図である。ステップ２０００において、上記で図１７を参照して記述されたクライアントアプリケーション１４１を動作するアドミニストレータが、ソースデータおよびデータ構造のためのウエブサイトを取り入れる。ステップ２００１において、アドミニストレータは、対象ウエブサイトの既存構造階層を表す編集可能オブジェクトを創出する。オブジェクトツリーは、アイコンおよび関連付けられた特性を有し、完成するとき実行可能である。一実施形態では、多くのウエブサイトによって共有される標準的なアイコンおよび特性の多くが、アドミニストレータに提供され、それにより、ツリーを創出するために、簡単なドラグおよびドロップ動作を使用することができる。デベロッパが、特定のオブジェクトをスクラッチから創出しなければならない場合、オブジェクト構成要素を表すオブジェクト構築ブロックからオブジェクトを構築するために、ソースマークアップ言語を使用することができる。次いで、新しいオブジェクトは、記憶装置に保存され、かつ再使用されることができる。
【０１４７】
一実施形態では、モデリングエンジンに対する命令としてソース記述をレンダリングすることにより、オブジェクトツリーが自動的に創出される。この場合、取り入れられたオブジェクトは、取り入れられて、「編集準備完了」としてアドミニストレータに呈示され、ステップ２０００および２００１は、完全ではないにしても、アドミニストレータに対してほぼ透過性である。他の実施形態では、アドミニストレータは、マウスを使用して、アイコンを簡単にドラグおよびドロップし、モデリングを実施するために使用されるワークステーションを備える。
【０１４８】
ステップ２００２において、アドミニストレータは、いくつかのオブジェクトがより完全にＶＸＭＬボイスレンダリングの制約に適合するように、それらのオブジェクトを編集することが可能である。同じステップにおいて、ユーザは、ツリーからあるオブジェクトを完全に削除することが可能である。さらに同じステップにおいて、アドミニストレータは、レンダリングの優先順位に従って、オブジェクトを移動させ、かつグループ化することが可能である。ウエブサイトがログイン要件を含む場合、それは、当然、結果的なボイスアプリケーションの最高優先順位または第１の実行可能ダイアログである。複雑なログインが、簡略化されることが可能である。さらに、１つまたは複数のオブジェクトを組み合わせて、同じダイアログにおいてレンダリングすることができる。多くの可能性が存在する。
【０１４９】
他の実施形態では、オブジェクトツリーが、１レベルに平坦化されることが可能であり、または、オブジェクトツリーが、より多くのレベルを含むように拡張されることが可能である。アドミニストレータは、ウエブサイトから当初利用可能ではなかった内容（ダイアログにレンダリングされている）を挿入することも可能である。新しい内容は、オブジェクトツリーのどこかに配置されることが可能であり、その後、ボイスアプリケーションの結果的なダイアログにおいて優先位置を取る。ボイスアプリケーションが完成した後、アプリケーションの開始および実行により、サイトにおいてデータにアクセスして、任意の新しいデータを取り出す。標準的なナビゲーションテンプレートが、サイトにアクセスするために使用され、データが、オブジェクトツリーにおいて識別されるデータのクラスのみに従って取り出される。このようにして、望ましくないデータが、同じウエブサイトから複数回繰り返してアクセスされることはない。
【０１５０】
ステップ２００３において、ボイスアプリケーションテンプレートは、上記で記述されたようにポピュレートされる。ステップ２００４において、アドミニストレータは、ＣＴＩ接点パラメータのすべての確立を含めて、ボイスアプリケーション実行のパラメータ化を開始することができる。ステップ２００５において、アドミニストレータは、ダイアログを創出することができる。
【０１５１】
当業者には、ボイスレンダリングのためにウエブ取入れ内容を事前に組織化することは、複雑さを低減し、ネットワークおよびプロセッサの負荷を低減し、また、接続されたボイスポータルシステムからアウトバウンドダイヤルする意味でアクセスしている、または接触しているユーザに適切で有用なボイスレンダリングのみを提供するための、非常に有用なステップであることが明らかになるであろう。
【０１５２】
セキュリティの改良
図２１は、本発明の一実施形態による、ボイスポータルとウエブサーバとの間の安全な接続性を示すブロック図である。
【０１５３】
この例で示される接続方式は、ボイスポータル２１０６にアクセスするユーザ（図示せず）を接続し、ポータル２１０６は、具体的にはデータベース２１１０に接続されたウエブサーバ２１０９から、本明細書ではインターネット２１０８内において示されるウエブベースデータへのネットワークアクセスを有する。
【０１５４】
ボイスポータル２１０６は、データリンク２１０５によってＸＭＬゲートウエイ２１０４に接続されたボイスアプリケーションサーバ（ＶＡＳ）２１０３を備える。この実施形態では、サーバ２１０９によってホストされるデータは、そこから取り出され、線２１０７によってＸＭＬゲートウエイ２１０４に送達される。次いで、アプリケーションサーバ２１０３が、ボイスアプリケーションを生成し、ＰＳＴＮ２１０１への電話接続を有するユーザにそれらを配信する。電話スイッチ、サービス制御点、ルータ、および電話ネットワークに知られているＣＴＩ可能機器が、ＰＳＴＮ２１０１内に存在することを想定することが可能である。同様に、ルータサーバおよびインターネットにおいて知られている他のノードが、インターネット２１０８に存在することを想定することが可能である。本発明者は、本発明の説明のために、示される機器で十分であると考える。
【０１５５】
通常、ＰＳＴＮ２１０１内の誰かからのボイスポータル２１０３へのボイスアクセスは、インバウンドコールまたはアウトバウンドコールであるかに関わらず、保護されていないと想定することが可能である。すなわち、電話線傍受能力を有する誰かが、ユーザフォンとボイスアプリケーションサーバとの間において行われているボイストランザクションを聞くことができる。通常、ソーシャルセキュリティのＩＶＲエントリおよびＰＩＮ識別など、電話トランザクションに関する従来の技術の慣習は、アカウント情報にアクセスするのに十分である。しかし、同じ情報を有する誰かが、残高情報などを見つけるために、ユーザの自動化されたアカウント線にアクセスすることもできる。
【０１５６】
サーバ２１０９は、ウエブ認証サービスで保護されることが可能であり、サーバ２１０９から任意のデータにアクセスするユーザ（オンライン）は、受容証明およびオンライン認証保証書の署名を送信しなければならない。これらの体制は、ユーザのブラウザアプリケーションにおいて選択肢として提供される。
【０１５７】
セキュリティをＸＭＬゲートウエイ２１０４の点に対して拡張する１つの方式は、完全私的なデータネットワークによる。より安価な選択肢が、この例で示されるＶＰＮネットワークである。他の方式は、ＨＴＴＰＳなどのＳＳＬ尺度による。これらの方法のいずれも、サーバ２１０９のセキュリティ体制をボイスポータル２１０６に拡張するために使用されることが可能である。この実施形態では、ゲートウエイ２１０４は、普及セキュリティ尺度に従って動作するように構成される。たとえば、ユーザが、オンラインでサーバ２１０９に行き、ユーザのパスワード情報を変更し、ウエブ認証保証書に署名する場合、同じ変更情報が、ボイスポータルにおいて記録される。
【０１５８】
したがって、唯一のセキュリティ失効が、ＰＳＴＮのユーザとポータル２１０６との間にある。ボイスとして任意のユーザの送信された情報、および任意のユーザから送信された応答ボイスは、線２１０２内に傍受することによって得ることができる。プライバシをある程度まで保護する１つの可能な解決法は、ボイスポータルおよびユーザ電話において、ボイス変換機構を使用することである。このようにして、ポータルを出るボイスは、あいまい言語、またはさらには符号に変換することができる。ユーザエンドにおいて、デバイス（図示せず）は、再び普及言語に変換され、電話スピーカシステムで遅延して実演される。
【０１５９】
当業者なら、既存セキュリティ、ＶＰＮ、ＳＳＬなどを使用する追加の利点は、セキュリティシステムがすでに試験されており、常に改良されていることであることを理解するであろう。当業者なら、本発明の精神および範囲から逸脱せずに、多くの変更を提供することができることも理解するであろう。たとえば、アウトソースウエブホスティングを使用することが可能である。マルチサイトウエブシステムを冗長性のために使用することができる。アウトソースボイスサービスまたはマルチサービス／ロケーションボイスサービスも適用されることが可能である。
【０１６０】
認識選択肢のための語彙管理
本発明の他の態様によれば、本発明者は、語彙管理システム、およびボイス認識ソフトウエアの最適化を改良する方法を提供する。方法および装置は、以下の可能にする開示において記述される。
【０１６１】
図２２は、本発明の実施形態による、語彙管理サーバ２２００およびソフトウエア２２０１で改良されている図１Ｂのアーキテクチャを示すブロック図である。
【０１６２】
この実施形態のシステムアーキテクチャは、上記で図１Ｂを参照して議論されたアーキテクチャとほぼ同様である。したがって、図１Ｂおよび図２２の両方の例に存在する要素は、本発明を実施するために修正されない限り、再度紹介されない。
【０１６３】
語彙管理サーバ２２００は、インスタントボイスアプリケーションを完全に可能にするために、ボイス認識テンプレート選択肢を必要な語彙にだけに適合させる目的で、語彙管理ソフトウエア（ＶＭＳ）２２０１のインスタンスで適合される。
【０１６４】
サーバ２２００は、データを保管および組織化する目的でサーバ２２００に接続されている、または内部に構成されて保持されているデータ記憶機器を有すると推定することが可能である。図１７の例を参照して上記でさらに記述されているように、ウエブデータを取入れ、ボイスダイアログのソースデータとして取入れたウエブデータを使用することに関して、ウエブベース構成要素は、この実施形態では、インターネットアクセス線によって表され、ワークステーション１４０から接続されている１つが、ウエブアクセスを与え、ボイスアプリケーションサーバ１１０に接続されている他が、データベース／リソースアダプタ１１３を経たアクセスを与える。このようにして、自動取入れ、解釈、およびボイスダイアログへの変換のためのあらゆる対象ウエブベースデータへのウエブアクセスが想定される。
【０１６５】
サーバ２２００は、ボイスアプリケーションサーバ２２０２を経て、またはより具体的にはデータリンク２２０３上のデータベースリソースアダプタ１１３を経て、クライアントアプリケーション１４１を実行するワークステーション１４０からアクセスされることができる。このようにして、アドミニストレータは、特定のオンラインまたはオフライン（内部）データソースに属する語彙選択肢を、セットアップして加工することができる。
【０１６６】
ＶＭＳソフトウエア２２０１は、対象データと関連して可能になる、あるアクセスされた対象データおよび機能に特定の語彙の別々で分離されたセットを可能にするように構成される。一実施形態では、同じ対象データソースの語彙の追加のサブセットを提供することができ、これは、ＰＳＴＮ１３４上においてポータル１４３から対話することにより、データにアクセスする特定のクライアントに対してさらに適合されている。創出された語彙セットに特有の規則セットが創出され、特定の語彙セットにタグ付けされて、アプリケーション論理１１２に提供される。
【０１６７】
ＶＸＭＬコンプライアント電話サーバ１３０は、テキストツースピーチおよびスピーチツーテキスト可能エンジン２２０５を有し、これは、図１Ｂを参照して記述されたエンジン１３２に置き換わる改良エンジンとして内部に提供される。一実施形態では、別々の機能が、別々の構成要素によって可能になることが可能である。本発明者は、例示のためにのみ、２つの能力を有する単一エンジンを示す。エンジン２２０５は、データリンク２２０２を経た語彙管理サーバ２２００へのアクセスを有する。
【０１６８】
サーバ２２００は、データリンク２２０４によってボイスアプリケーションサーバ１１０のアプリケーション論理１１２から、およびデータリンク２２０３によってデータリソースアダプタ１１３からアクセス可能である。一実施形態では、単一データリンクが、ボイスアプリケーションサーバ１００における直前で記述された構成要素とサーバ２２００との間の通信を可能にするのに十分である。
【０１６９】
本発明の実施において、ウエブベースデータソースにアクセスしていると想定すると、ボイス認識は、以前に記述された実施形態とは異なる方式で動作する。たとえば、クライアントが、口座残高のレンダリングおよび株式取引の選択肢を含むクライアントの個人投資ウエブページと対話するために、電話１３５からＰＳＴＮ１３４においてボイスポータル１４３にアクセスしていると想定する。対象ウエブサイトの特定の語彙が、ＶＭＳ２２０１によって管理されるサーバ２２００において利用可能である。おそらく、クライアントに特有の語彙のサブセットも存在し、親語彙セットの下で組織化される。
【０１７０】
電話サーバ１３０は、アクセスしているユーザを認識し、既存ボイスアプリケーションがトリガされる。ボイスアプリケーションサーバ２２０２は、データリソースアダプタ１１３およびインターネットアクセス線を経て、ユーザの代わりにウエブサイトに接続される。ボイスアプリケーションテンプレートの制約に従って、データベースリソースアダプタは、ユーザが、第１または開始ダイアログにおいてユーザログインおよびパスワード情報と通信し、次いで、ユーザが権利を与えられている口座データおよびあらゆる他の更新データを得た後、ユーザログインおよびパスワード情報を提供する。ボイスアプリケーションからユーザにレンダリングされた第１のダイアログ応答は、ユーザの口座に関係付けられた株式値、および特定の記号に関連付けられた既存の通貨残高のみを含むことができる。より多くの情報がユーザに利用可能である可能性があるが、利用可能な情報のいくつかは、ユーザに関係しない、または有用ではない可能性がある。したがって、各ダイアログをレンダリングする前に、ＶＭＳ２２０１は、いくつかの場合にはアクセスユーザにも特有である、特定のダイアログ機能のための適切な語彙および規則セットを提供する。したがって、ボイス認識ソフトウエアは、レンダリングされたＶＸＭＬページを解釈するために、大量の語彙を探索する必要はない。この場合、ＶＸＭＬページ自体は、電話サーバ１３０に送達される前に、語彙管理機能によって限定される。
【０１７１】
他の実施形態では、ＶＭＳ２２０１からの関与は、標準的なＶＸＭＬページがレンダリングされた後であるが、ボイス認識がサーバ１３０において開始される前に行われることが可能である。この場合、エンジン２２０５は、適切な語彙制約を得るために、サーバ２２００に情報を求める。この例では、ＶＸＭＬから認識されないデータは、単に破棄される。ＶＭＳ２２０１がボイス認識機能を効率化するために使用されることが可能である多くの異なる点が、ダイアログプロセスに沿って存在する。たとえば、上記でさらに記述されている第１のダイアログ応答では、ユーザは、任意の望ましい取引き活動を開始するように促されることが可能である。ユーザが、ある取引きをすることを選択する場合、エンジン２２０５のスピーチツーテキスト部分は、そのクライアントに適合されている限定された取引き語彙について、ＶＭＳ２２０１に情報を求めることが可能である。そのような語彙は、たとえばＶＩＰであり、おそらくはより多くの可能な選択肢を有する、異なるクライアントについて拡張されることが可能である。提供された語彙と整合しない、および／または規則に準拠しないクライアントからのボイスレンダリングは、無視される。
【０１７２】
ボイス認識のために語彙選択肢を個人化および効率化することに加えて、アドミニストレータは、新しい語彙を創出するために、および／または同じ語彙ワードとして認識される複数の同義語を創出するために、ＶＭＳを使用することができる。たとえば、アドミニストレータは、ペーパを記述するために、ストック、シェア、およびセキュリティを同義語として構成することが可能である。セール（ｓｅｌｌ）、ショート（ｓｈｏｒｔ）、およびダンプ（ｄｕｍｐ）が、すべて、ペーパを販売するための同義語として理解されることが可能である。多くの変形の可能性がある。一般に、ＶＭＳ２２０１は、レンダリングするために、またはＶＸＭＬページのボイス認識を限定して、認識されない部分を破棄するために、ＶＸＭＬページのデータを限定するための管理ツールとして、一通信方向（サーバからユーザ）において適用されることができる。ＶＭＳ２２０１は、サービスポリシおよび制約に従って、ユーザまたはユーザグループについて許可されたボイス認識選択肢を適合するために、反対方向（ユーザからサーバ）のダイアログステップにおいて適用されることができる。
【０１７３】
ＶＭＳ２２０１が、ＶＸＭＬストリームと共にのみ作用する一実施形態では、ＶＭＳ２２０１は、アプリケーションサーバ１１０内または電話サーバ１３０内にのみ配置されることが可能である。単一データソースにアクセスする同じクライアントの同じボイスアプリケーションの異なるダイアログ（初期ダイアログおよび応答ダイアログの両方）を、ＶＭＳ２２０１を使用し、異なる語彙セットを使用して制約されることができることが考慮される。したがって、管理能力の最適レベルは、動作／応答のレベルにある。対話中に各利用可能ステップにおいてボイス認識処理の作用を限定することによって、多くの処理パワーおよび帯域幅を、他のユーザについて確保することができる。
【０１７４】
ローカルキャッシュ最適化（静的、動的）
本発明の他の態様では、データトラフィックを低減する方法および装置が提供され、ＶＸＭＬ分散環境においてローカルキャッシュ最適化を使用する。
【０１７５】
図２３は、本発明の一実施形態による、キャッシュ最適化構成要素を含むＶＸＭＬアプリケーションアーキテクチャ２３００の様々な機能構成要素を示すブロック図である。図２３は、図１と極めて類似するが、更新されており、追加の詳細を示す点が異なる。
【０１７６】
アーキテクチャ２３００は、主要構成要素として、ボイスアプリケーションサーバ２３０１、および電話サーバ／ボイスポータル２３０２を基本的に備える。ポータル２３０２は、スピーチ生成装置２３０６および電話ハードウエア／ソフトウエアインタフェース２３０５を備える。ポータル２３０２は、アプリケーションサーバ２３０１から送信されたＶＸＭＬデータを解釈するためのＶＸＭＬインタプリタ２３０７を含むことによって、ＶＸＭＬコンプライアントである。ボイスポータル２３０２は、よく知られているＰＳＴＮネットワークなどの電話ネットワーク内において、アクセス点として維持される。しかし、ポータル２３０２は、無線電話ネットワーク上において維持されることも可能である。
【０１７７】
ウエブインタフェース２３０３がこの例では示され、よく知られているインターネットまたは他の適用可能なＤＰＮからアクセス点として作用する。ボイスポータル２３０２は、ＣＴＩ改良ＩＶＲシステム、顧客サービス点、またはあらゆる他の自動ボイスポータルシステムを表すことが可能である。ウエブベースポータルの場合、構成要素２３０３は、ウエブサーバ、インターネットに接続されたコンピュータ、またはユーザインタフェースを提供するあらゆる他のタイプのノードとすることが可能である。
【０１７８】
ボイスアプリケーションサーバ２３０１は、図２２を参照して記述されたボイスアプリケーション２２０２と多くの点で類似する。これに関して、ボイスアプリケーションサーバは、インストールされ、かつその上で実行可能なボイスアプリケーション展開ソフトウエア（ＶＡＤＳ）２３０８を有する。ボイスアプリケーションサーバ２３０１の領域内において示されるＶＡＤＳ２３０８は、あるモジュールを有し、これらのモジュールは、本明細書では、図面空間が限定されているので、ラベルを使用して記述され、かつモジュールに割り当てられる要素番号を有さない。ＶＡＤＳ２３０８において示されるモジュールは、ダイアログ受信者のパラメータを管理するためのデベロッパツールとして適合された接点マネジャ（Ｃｏｎｔａｃｔ  Ｍｇｒ．）インスタンスを含む。ダイアログ制御装置（Ｄｉａｌｏｇ  Ｃｔｒｌ．）が、ボイスアプリケーションダイアログを創出および管理し、かつ規則ソースおよび内部／外部データソースに対するインタフェース動作を開始するためのデベロッパツールとして提供される。フォンレット制御装置（Ｆｏｎｅｌｅｔ  Ｃｔｒｌ．）が、ＶＡＤＳ２３０８内に提供され、ボイスアプリケーションのその後のダイアログの分布を制御するように構成される。ＸＭＬ生成装置（ＸＭＬ  Ｇｅｎ．）が、ＶＡＤＳ２３０８内に提供され、ＶＸＭＬページのＸＭＬを生成するように構成される。
【０１７９】
ボイスアプリケーションサーバ２３０１は、内部において提供され、かつアプリケーションの送達、創出、および管理の様々な態様を制御するように構成されたアプリケーション論理２３０９を有する。アプリケーション論理２３０９は、規則マネジャ（Ｒｕｌｅ  Ｍｇｒ．）を含み、この規則マネジャは、上記で言及された接点マネジャおよびダイアログ制御装置を介したアプリケーション創出および配置のための企業規則と、実行アプリケーションとの進行中のユーザおよびシステム対話のための規則とを提供する。ダイアログランタイムプロセッサ（Ｄｉａｌｏｇ  Ｒｕｎ  Ｔ．Ｐｒｓｃｒ．）が提供され、ボイスアプリケーションの完成ダイアログが開始されかつフォーマットされる方式を制御するように構成される。フォンレットランタイムプロセッサ（Ｆｏｎｅｌｅｔ  Ｒｕｎｔｉｍｅ  Ｐｒｓｃｓｒ．）が、アプリケーション論理２３０９内に提供され、ボイスアプリケーション（フォンレット）が実時間でどのように実行されかつ演出されるかの種々雑多な態様を制御する。動的グラマー生成装置（Ｄｙｎａｍｉｃ  Ｇｒａｍｍａｒ  Ｇｅｎ．）が、アプリケーション論理２３０９内に提供され、非反復ダイアログ内容と関連するグラマキーワードを生成するように構成され、この場合、ユーザは、動的方式で瞬間的な結果を取り出すために、生成されたキーワードを話すことができる。
【０１８０】
サーバ２３０１において、アプリケーション論理内において以前に導入されていない新しい構成要素は、静的最適化装置２３１２および動的最適化装置２３１１である。本発明の目的は、ポータル２３０２および２３０３（ウエブ可能である場合）とボイスアプリケーションサーバ２３０１との間のデータトラフィックの低減を最適化することである。ボイスアプリケーションサーバとボイスポータルとの間におけるデータトラフィックの低減の達成は、構成要素が互いに離れており、かつ比較的狭いデータパイプラインにより接続されている場合、特に重要である。そのようなパイプラインは、動作中のピーク性能期間にデータで封鎖され、ボイスポータルにおいて応答時間が顕著に遅延することがある。最適化装置２３１２および２３１１に関するさらなる詳細、およびダイアログランタイムプロセッサに対する関係が、本明細書の以下において提供される。
【０１８１】
サーバ２３０１は、外部および内部のデータソースにインタフェースするのに必要なモジュールのすべてを含むデータ／リソースアダプタブロック２３１０を有する。たとえば、アプリケーションマネジャ（Ａｐｐ．Ｍｇｒ．）が、アダプタ２３１０内に提供され、ポータル２３０２および２３０３などのユーザエンドシステムに対する主要インタフェースモジュールとして適合される。アプリケーションマネジャは、出現順にダイアログの適切なデータ送達を提供し、本発明の好ましい実施形態では、ユーザのエンドシステムに対して局所的である１つまたは複数のキャッシュシステムを記憶するための静的および動的のダイアログ部分（最適化により決定される）を送達する。アプリケーションマネジャのさらなる役割が、以下においてさらに提供される。
【０１８２】
報告マネジャ（Ｒｅｐｏｒｔ  Ｍｇｒ．）が、アダプタ２３１０内にあり、ボイスアプリケーション対話の動作に関して報告可能な統計を提供するために、アプリケーションマネジャと共に作用するように構成される。報告マネジャは、フォンレットが完成または終了されるまで、フォンレット（ボイスアプリケーション）を追従する。ボイスアプリケーションのどの動的（非反復）ダイアログ部分が、ユーザエンドにおいて局所的にキャッシュされるべきであるかを決定するのを補助するために、本発明の方法では、背景統計を使用することができる。
【０１８３】
第３パーティウエブサービスプロバイダ２３１３が、この例では、サーバ２３０１に対して外部であるが、通信のためにそれに連結されて示されている。第３パーティサービス２３１３は、サーバ２３０１内においてホストされるボイスアプリケーション展開および展開サービスにタップするために使用することができるソフトウエアを含めて、任意の第３パーティサービスプロバイダを表す。ユーザによって聞かれたシンソフトウエアクライアントが、従来のウエブサイトを経てユーザにアクセス可能であるウエブベースサービスの場合のように、第３パーティアプリケーションの影響下にある。第３パーティ接続能力を促進するために、サーバ２３０１は、第３パーティ機能に対するサーバインタフェースとして適合されるウエブリソースコネクタ（Ｗｅｂ．Ｒｅｓ．Ｃｏｎｎ．）を有する。フォンレット事象キュー（Ｆｏｎｅｌｅｔ  Ｅｖｅｎｔ  Ｑｕｅｕｅ）が、アダプタ２３１０内に提供され、サーバと第３パーティ提供リソースとの間において入および出フォンレット（ボイスアプリケーション）事象をキューに入れるように構成される。フォンレットＸＭＬインタプリタ（Ｆｏｎｅｌｅｔ  ＸＭＬ  Ｉｎｔ．）が、アダプタ２３１０内に提供され、フォンレット事象キューに入る、またはフォンレット事象キューから出るＸＭＬドキュメントを解釈するように構成される。
【０１８４】
リソースマネジャ（Ｒｅｓｏｕｒｃｅ  Ｍｇｒ．）が、アダプタ２３１０内に提供され、外部および内部の両方のすべてのアクセス可能リソースへのアクセスを管理するように構成される。内部リソースは、サーバ自体内において、またはサーバの領域内において維持されることが可能であることに留意されたい。領域は、たとえば、ボイスアプリケーションサーバをホストする接点センタ内の内部データシステムなど、領域内において考慮することが可能である他のシステムを含む。データベースアクセスマネジャ（Ｄａｔａｂａｓｅ  Ａｃｃｅｓｓ  Ｍｇｒ．）が、アダプタ２３１０内に提供され、サーバ２３０１の領域に対して内部に位置するデータストアを備え、かつデータストアに関連付けられた永続的なデータ記憶装置からのデータ取出しを容易にするように構成される。
【０１８５】
ＶＸＭＬレンダリングエンジン２３１４が、アプリケーションサーバ２３０１内に提供され、ＶＡＤＳ２３０８のダイアログ制御装置と関連してＶＸＭＬページをレンダリングするように構成される。レンダリングエンジン２３１４は、上記で図２２および図６を参照して記述されたエンジン１１１と同様である。
【０１８６】
サーバブロック２３１０、２３０９、２３０８、およびエンジン２３１４は、互いに通信して協動する。通信および協動の能力は、この例では、通信のためにブロックを接続する論理サーババス構造２３１５によって示される。同様の論理バス構造２３１６が、ポータル２３０２内において示されており、通信のための内部構成要素を接続する。
【０１８７】
上記で以前に記述されたように、ボイスアプリケーションは、開始された後、静的結果および動的結果の両方を生成する一連の対話式ダイアログ部分を備える。たとえば、各発呼者に対して実演される会社のあいさつは、静的あいさつであると考慮されるが、その理由は、ダイアログが発呼者ごとに動的に変化しないからである。しかし、ストッククォートのユーザ要求に対するダイアログ応答は、動的と考慮されるが、その理由は、要求に応じて発呼者ごとに異なることができるからである。同様に、データベースまたは他の外部データソースから引き出されたデータ結果が、応答ダイアログに埋め込まれていることにより、ダイアログ自体は動的と考慮されるが、その理由は、基本的なテンプレートは静的であるが、埋め込まれている結果が、発呼者間において異なることがあるからである。
【０１８８】
静的最適化装置２３１２および動的最適化装置２３１１が、関連するボイスアプリケーションとの対話中に、ローカルアクセスのためにエンドシステムキャッシュ記憶装置設備に分配されるべきであるダイアログの部分を識別するために、ダイアログランタイムプロセッサと協動して作用するように提供される。最適化装置２３１２および２３１１は、ソフトウエアモジュールであり、このソフトウエアモジュールは、初期実行中、または関連するボイスアプリケーションが修正されているとき、ダイアログファイルを監視して、読取る。静的最適化装置２３１２は、規則マネジャと協動し、ビジネス規則に従って、発呼者ごとに変化しないラベル付き静的または反復ファイルとすることができるあるファイルにタグ付けする。動的最適化装置２３１１は、規則マネジャと協動し、ビジネス規則に従って、発呼者ごとには反復されないが、関連するボイスアプリケーションが介してアクセスされるエンドシステムに対して局所的であるキャッシュに分散キャッシングすることを保証するように十分頻繁に反復されるあるファイルにタグ付けする。
【０１８９】
一実施形態では、最適化装置２３１２および２３１１は、ダイアログランタイムプロセッサ内において実行される埋込みモジュールである。他の実施形態では、最適化装置は、ランタイムプロセッサが、特定のボイスアプリケーションのダイアログを処理するとき、ランタイムプロセッサによって活動化される別々のモジュールである。
【０１９０】
アドミニストレータがボイスアプリケーションを変更するとき、または、最新のボイスアプリケーションが創出されるとき、最適化装置２３１１および２３１２の最適化プロセスは、アプリケーションから出るどのデータのフローをキャッシュすることが必要であるかを判定するために呼び出される。タグ付けは、当業者において知られている様々なファイル識別体制の形態を取ることができる。好ましい実施形態では、標準的なＨＴＴＰ１．１タグ付けが使用される。最適化構成要素２３１２および２３１１は、タグをタグなしファイルに追加することができ、あるいはいくつかの場合、すでにタグ付けされているファイルからタグを除去することができる。この自動プロセスにより、アドミニストレータが、サーバ間のデータトラフィックに関連する分散の問題を心配せずに、ダイアログを創出することが可能になる。
【０１９１】
静的ファイルでは、最適化装置２３１２は、エンドシステムにおいてどのファイルをキャッシュするかを識別し、それらに適切にタグ付けし、識別されたエンドシステムキャッシュに分配されるタグ付きファイルを準備する。ポータル２３０２がエンドシステムである場合、ボイスアプリケーションの静的ファイルは、サーバキャッシュのブロック２３０５において局所的に記憶される。一実施形態では、分散静的ファイルは、最近修正された、または最新のボイスアプリケーションの第１の配置においてキャッシュされる。アプリケーションにアクセスする第１の消費者は、静的ファイルが第１の対話中にキャッシュされるということにより、最適化性能を経験しないことになる。しかし、ポータル２３０２からアプリケーションにアクセスする後続消費者、またはアプリケーションの静的部分を繰り返す第１の発呼者が、性能の向上を経験するが、その理由は、ダイアログが要求されるたびに、アプリケーションサーバ２３０１からダイアログを取り出す代わりに、電話サーバが、ローカルキャッシュからアプリケーションの静的部分にアクセスして、それを提供するからである。本明細書では、静的内容および動的内容をキャッシュすることは、好ましい実施形態では一時的であることに留意されたい。すなわち、ボイスアプリケーションが企業によってもはや使用されないとき、または、新しいアプリケーションによって置き換えられるとき、不必要なファイルは、キャッシュシステムから削除される。
【０１９２】
静的ダイアログが、ボイスアプリケーションからポータル２３０２の電話サーバ部分に分配され、かつ電話サーバ部分の内部においてキャッシュされた後、静的ダイアログは、関連っするボイスアプリケーションとのその後の対話中、後続取出しのために依然としてキャッシュにあることができる。しかし、ボイスアプリケーションが、アドミニストレータによってその後修正され、異なるダイアログが、静的キャッシュ可能ダイアログとして識別される場合、すでにキャッシュされているそれらのダイアログは、より新しい更新された静的ダイアログと置き換えられる。適切な静的ファイルを同期させるために、識別および改定方法の任意の一般的な形態を使用することができる。いくつかのダイアログは、修正されているアプリケーションから簡単にドロップすることが可能であり、一方、他の静的ダイアログは、新しく追加されることが可能である。静的と考えられる新しい、削除された、または修正されたファイルの存在に関して、アプリケーションをその後修正する場合、これらのファイルとすでに記憶されているファイルとの同期は、アプリケーションがエンドシステムに配置されるようにスケジュールされる前に、またはアプリケーションの実行時間中に、行われることができる。
【０１９３】
本発明の好ましい実施形態では、動的ファイルのキャッシングは、ポータル２３０２の電話ソフトウエア／ハードウエアブロック２３０５内のボイスウエブ制御装置モジュールにおいて実施される。動的ファイルは、静的ファイルとは異なるが、その理由は、動的ファイルは、各実行およびボイスアプリケーションとの対話中に取り出される必要がないからである。したがって、動的取出しは、ボイスアプリケーションとのユーザ対話が開始された後でのみ行われる。いくつかのボイスアプリケーション配置に対して、どのファイルが、エンドシステムキャッシュ設備に分配され続ける意味があるか、およびいくつかの場合、動的最適化のためにすでにキャッシュされているどのファイルが、エンドシステムローカルアクセスから削除され、その後除去されるべきであるかを判定するために、統計分析を、ボイスアプリケーションサーバ２３０１において使用することができる。
【０１９４】
図２４は、本発明の実施するためのステップを示すプロセス流れ図である。ステップ２４００ａにおいて、「ＸＹＺ会社にお電話をいただきありがとうございます（ｔｈａｎｋ  ｙｏｕ  ｆｏｒ  ｃａｌｌｉｎｇ  ＸＹＺ  ｃｏｒｐｏｒａｔｉｏｎ）。」などの静的あいさつメッセージが実演される。このダイアログを含むボイスアプリケーションが、エンドシステムからアクセスされた後、特定のダイアログは、静的ダイアログと識別される場合、局所的に記憶される。その後のアクセスが同じボイスアプリケーションに対して行われるたびに、あいさつ２４００ａは、命令されるときにステップ２４０１においてローカルキャッシュから引き出される。
【０１９５】
ステップ２４００ｎにおいて、この実施形態ではメニューメッセージを表す最後の静的メッセージが実演される。この例では２４００ａ〜ｎの要素割当てによって、この例では示されるボイスアプリケーションに複数の静的ダイアログが存在することが可能であることが理解されるであろう。任意の静的メッセージ２４００ａ〜ｎが、ボイスアプリケーションの実行に必要とされるたびに、ステップ２４０１においてローカルキャッシュから引き出される。ステップ２４００ｎにおいて実演されるメッセージは、「メニューを変更いたしました。慎重にお聞きください。電話は、訓練のために記録されることがあります（Ｗｅ  ｈａｖｅ  ｃｈａｎｇｅｄ  ｏｕｒ  ｍｅｎｕ．  Ｐｌｅａｓｅ  ｌｉｓｔｅｎ  ｃａｒｅｆｕｌｌｙ．  Ｙｏｕｒ  ｐｈｏｎｅ  ｃａｌｌ  ｍａｙ  ｂｅ  ｒｅｃｏｒｄｅｄ  ｆｏｒ  ｔｒａｉｎｉｎｇ  ｐｕｒｐｏｓｅｓ）。」など、対話の先行状態である。
【０１９６】
メッセージ２４００ａ〜ｎは、発呼者が誰であるかに関係なく、ＩＶＲ対話などの開始部分において実演されるので、メッセージ２４００ａ〜ｎは、アクセスされたエンドシステムまたはアプリケーション消費者を表す電話サーバ内において、静的にキャッシュされることができる。上記で以前に記述されたように、ＨＴＴＰ１．１規格タグが、どの材料をキャッシュするかを指示するために使用されることが可能である。ローカルサーバは、静的ファイルをストアに維持し、コールが、その特定のボイスアプリケーションの番号または拡張子になるときはいつでも、適切なアプリケーションに従って静的ファイルを使用する。いくつかの場合、ボイスアプリケーションは、発呼者によってアクセスされるボイスアプリケーションを分離する拡張子を用いて、単一接点番号において多数である。
【０１９７】
静的内容の局所キャッシングがない場合、電話サーバは、通常、ウエブ制御装置に要求し、ウエブ制御装置は、要求をランタイムプロセッサに送信し、かつダイアログランタイムプロセッサからメッセージを取り出す。音声ファイルは、瞬間実演のために、プロセッサから再び同じネットワーク接続で電話サーバに送信される。動的対話ボイスアプリケーションのダイアログ部分の局所キャッシングが、ポータルとアプリケーションサーバとの間において多大な帯域幅を保存することが理解されるであろう。エンドシステムに対して局所的にキャッシュされることが可能である他のタイプの静的ダイアログの例には、本質的に動的には決して変化しない、オペレーション時間、位置または駆動の命令、請求アドレスなどがある。
【０１９８】
ステップ２４０２において、ユーザが、ステップ２４００ｎのメニュー選択肢ダイアログから得られる選択を開始することによって、ボイスアプリケーションと対話する。ステップ２４０３ａにおいて、動的メニュー選択肢または結果が実演される。選択肢または結果は、先行静的ダイアログに対するユーザ開始選択または対話の結果として取り出される。したがって、ユーザが聞く次のダイアログは、非反復または動的であると見なされる。これは、結果またはメニュー選択肢の内容が、コールごとに変化することがあることを意味し、変化は、ボイスアプリケーションとの第１のユーザ対話によって命令される。
【０１９９】
特定のボイスアプリケーションが介してアクセスされるエンドシステムの局所的キャッシュにダイアログを分配するか否かを統制する規則は、内容、可能な選択肢または結果の数、およびいくつかの場合は統計的確率に応じて異なることがある。たとえば、ボイスアプリケーションが、動的メニューが融資担当者、標準的な出納係、または自動口座アテンダントに転送され、統計的にすべての発呼者の９０％が自動アテンダントへの転送を選択する選択肢を有するバンキング機関について創出される場合、自動バンキングに関連付けられたボイスアプリケーションのその後の開始ダイアログは、局所的にキャッシュされることができる。この場合、初めの２つの選択肢は、ライブ接続を要求し、それにより、ボイスアプリケーションを終端させる。第３の選択肢は、同じアプリケーションの他のダイアログ、または他のアプリケーション全体に連結される。したがって、次のダイアログは静的とすることが可能であるが、その理由は、このダイアログは、発呼者に識別基準を入力するように要求するだけであるからである。「自動アテンダント」を選択するすべての発呼者について同じダイアログである。
【０２００】
動的最適化の基準は、大きく変更することが可能であることに留意されたい。たとえば、標準的なダイアログテンプレートに埋め込まれた個人情報結果は、施設のデータソースから取り出されなければならず、局所的にキャッシュすることはできない。しかし、個人情報のデータ取込みとなる対話を請求する標準的なメニューは、局所的にキャッシュされることができる。
【０２０１】
動的キャッシングに割り当てられるダイアログが、選択されるたびに、ステップ２４０３においてウエブ制御装置から取り出される。さらに、ステップ２４０２は、動的にキャッシュされたダイアログ間において繰り返して行われることが可能である。ステップ２４０３ｎにおいて、最後の動的メニュー選択肢が、ボイスアプリケーションシーケンスにおいて実演される。これは、統計的にごくわずかのユーザのみが、ボイスアプリケーションの最後または最終メニューにナビゲートされるということである可能性がある。したがって、これは、局所キャッシングについて考慮されない可能性がある。しかし、多くの標準的な動的選択肢および結果は、多数の発呼者が選択肢または結果を要求しようとする確率が高い事象では、動的にキャッシュされることができる。
【０２０２】
おそらくは製品の望ましいモデルおよび型など、通常は流動的ではない結果は、動的な結果であるが、その理由は、対話メニューとの対話によるリターンについて利用可能な他の結果があるからである。最も一般的な結果は、ダイアログとして動的にキャッシュされることができ、これは、各発呼者が同じ結果と対話しない場合でも、局所的に取り出されることができる。最適化装置が、図２３のアプリケーションサーバに関して記述された他のモジュールのすべてと、データベースアクセス可能性を共有する。したがって、一般的に要求される結果は、完全には静的ではないが、ダイアログテンプレートに埋め込んで、同じアプリケーションの先行ダイアログに対する応答として作成されたある選択に連結されたボイスアプリケーションダイアログとして、局所的に保存されることができる。
【０２０３】
動的キャッシングのいくつかの場合、標準的なダイアログは、動的である埋込み結果を有さずに存在する。この場合、ボイスアプリケーションサーバをプロキシとして使用して要求データを取り出して、データをユーザに対して局所的にテンプレートに埋め込むクライアントアプリケーションを提供することができ、この場合、ユーザがデータにアクセスして、アプリケーションにおいて移動した後、埋込みデータは、次の呼出しまで、テンプレートから削除される。多数の可能性がある。
【０２０４】
当業者には、本発明の方法および装置は、内部データソースならびに外部データソースの両方のアクセスに適用されることができ、外部データソースのいくつかは、ウエブホストデータおよび他のタイプのデジタルデータネットワーク上において利用可能なデータと同様のネットワークベースデータソースであることが明らかになるであろう。
【０２０５】
テキストツースピーチ処理
本発明の一態様において、テキストツースピーチプレプロセッサが、本発明のボイスアプリケーションシステムに対する改良として提供される。本発明の方法および装置は、以下において詳細に記述される。
【０２０６】
図２５は、本発明の一実施形態による、テキストツースピーチプレプロセッサ２５０１で改良されている図２３のＶＸＭＬアーキテクチャのブロック図である。ＶＸＭＬアーキテクチャ２５００がこの例では示され、上記で図２３を参照して記述されたＶＸＭＬアーキテクチャ２３００と同様である。ＶＸＭＬアーキテクチャ２５００は、この例では、社会経済人口統計学、産業特有用語、および地域人口統計学に基づく規則に従って、句および用語の特別ボイス発音をレンダリングする能力で改良されている。
【０２０７】
上記の図２３に示されるすべての構成要素も、この例において示されている。したがって、本発明の結果として修正されていない以前に導入された構成要素は、同じ要素番号を保持する。ボイスアプリケーションサーバ２３０１は、図２３を参照して記述されたサーバ機能を提供する、ソフトウエア機能ブロック２３１４、２３０８、２３０９、および２３１０を有する。
【０２０８】
以前に記述されたように、ＶＸＭＬページが生成され、ボイスアプリケーションに組み込まれる。このボイスアプリケーションは、個々のＶＸＭＬページが動的内容を含むことが可能であり、また、発呼者の対話中にその場で生成されるという意味で動的である。ボイスアプリケーション展開ソフトウエアにより、アドミニストレータが、遠隔局からテンプレートを使用してボイスアプリケーションを創出し、かつ配置のためにそれらをスケジュールすることが可能になる。いくつかの場合、消費者は、引出し方式でアプリケーションにアクセスする。他の場合、ボイスアプリケーションは、プッシュされるアウトバウンドアプリケーションとして配置される。サーバ２３０１において創出されるボイスアプリケーションの分配は、ユニキャスト、マルチキャスト、およびブロードキャストの方法を含むことが可能である。
【０２０９】
ボイスアプリケーションダイアログが、好ましい実施形態では、ＶＸＭＬページの形態で、電話／ボイスポータル２３０２およびまたはウエブポータル２３０３などのポータルに送信される。サーバ２３０２において、ＶＸＭＬインタプリタ２３０７が、ＶＸＭＬを同期されたボイスにレンダリングし、これは次いで、この場合は電話ハードウエアブロック２３０５を経て、発呼者に話される。同様に、発呼者からの応答が捕獲されて、アプリケーションサーバにおいて解釈するためにＸＭＬとしてレンダリングされる。アプリケーションサーバは、解釈された応答内容に従って、発呼者の次のダイアログとして送信される新しいＶＸＭＬページを生成する。あらゆるデータが、次のＶＸＭＬレンダリングまたはダイアログに含まれる取込みデータにおいて、実施された結果を取り込む。
【０２１０】
テキストツースピーチ（ＴＴＳ）プレプロセッサ２５０１は、アプリケーションサーバ２３０１のブロック２３０９内に提供される。ＴＴＳ２５０１は、どの随意選択テキストレンダリングが、ＶＸＭＬページまたはダイアログに含まれるために選択されるかに対処する特別な命令セットで、ダイアログのテキストストリームを事前処理するように構成される。ＴＴＳプレプロセッサ２５０１は、方向矢印によって示されるように、ランタイムダイアログプロセッサに接続される。ダイアログランタイムプロセッサが、企業規則に従って通常のＶＸＭＬレンダリングのためにテキストダイアログを処理する前に、ＴＴＳプレプロセッサ２５０１は、通常はボイスアプリケーションと対話する発行者であるボイスアプリケーション消費者に関して知られている情報に従って、テキストダイアログに注釈を付ける。知られている情報は、位置、領域、好み、教育レベルなどを含めて、発呼者について事前に知られている情報とすることができる。知られている情報は、発呼者線識別（ＣＬＩＤ）および他の接続識別機構により、および対話中に発呼者の応答を分析することによって発呼者との直接対話により、対話時に発呼者から収集される情報とすることもできる。
【０２１１】
ＴＴＳプレプロセッサ２５０１は、異なるテキストレンダリングの選択肢を有する表（図示せず）として実現される動的ヒットリストへのアクセスを有する。各レンダリングは、発呼者、発呼者の領域、人口統計学的情報、および／またはトランザクションもしくはシナリオのタイプに関連付けることができる１つまたは複数の条件に関連付けられ、実際、それに従って創出されることが可能である。ＴＴＳプレプロセッサ２５０１は、発呼者から収集された、および／または発呼者に関して事前に知られている情報を、規則の１つまたは複数もしくは規則のセットに整合させ、相応してＸＭＬ応答ストリームに注釈を付ける。この実施形態の注釈は、表において呈示される様々なテキスト選択肢から応答の特定のテキスト部分を選択することを意味する。レンダリングされたその後のＶＸＭＬページは、発呼者エンドにおいて注釈されたＸＭＬ命令に従って、スピーチを生成することを命令する。したがって、発呼者が聞く実際の合成スピーチは、同じボイスアプリケーションを使用する発呼者間において異なることがあるという点で、動的である。
【０２１２】
ＴＴＳプレプロセッサ２５０１は、Ｒｕｌｅ  Ｍｇｒへのアクセスを有し、Ｒｕｌｅ  Ｍｇｒは、発呼者と企業との間のボイス対話として生じる特定のトランザクションに関連付けられる「ヒットリスト」を提供する。たとえば、発呼者が、フロリダの特定の郡に位置し、特定の州高速道路への方向を望み、高速道路名が、本質的にサービスによって網羅される２つ以上の位置において使用される場合、ＴＴＳプレプロセッサ２５０１は、発呼者の特定の位置を考慮に入れるＶＸＭＬレンダリングのテキスト応答に注釈を付ける。次いで、規則は、発呼者の視点から局所的に使用される特定の高速道路名に応答を制約する。おそらくは、フロリダの北の郡では、高速道路名は、「ステートルート（Ｓｔａｔｅ  Ｒｏｕｔｅ）２５」であり、一方、フロリダの南の郡では、ルート２５は、「ビーンメモリアルフリーウエイ（Ｂｅａｎ  Ｍｅｍｏｒｉａｌ  Ｆｒｅｅｗａｙ）」としてより一般的に知られている。発呼者の位置が南の郡にあると想定すると、ＶＸＭＬインタプリタ２３０７において解釈される生成応答は、「ステートルート２５」の代わりに、「ビーンメモリアルフリーウエイ」を発音する命令を含む。
【０２１３】
産業特有用語、適切な位置名、道路名などに関する広範なテキストの変化を、サービスホスト企業によって収集して、上記で記述されたように表にされるアプリケーションに応じる応答選択肢に統合し、次いで、発呼者とのボイス対話の各セッションに関する情報対規則セットの整合性に従って、動的に選択することができる。したがって、同じボイスアプリケーションが、アプリケーションを使用する特定の発呼者に適合された動的応答を送達することができる。
【０２１４】
図２６は、テキストストリングのスピーチレンダリングの可能な変更を示すブロック図である。この例では、テキストツースピーチレンダリングの変化の可能性が、標準的なテキストブロック２６００として示される標準的なフリーウエイエンティティ「ＨＷＹ１０１」について示されている。テキストツースピーチ選択肢２６００ａが、レンダリングが読まれる際に、レンダリングを音声的に「ハイウエイワンハンドレッドアンドワン」と発音するように、スピーチ生成装置に命令する。テキストツースピーチ選択肢２６００ｂが、各文字を引用符で表すようにスピーチ生成装置に命令し「Ｈ」「Ｗ」「Ｙ」「１」「０」「１」、これは、音声的には「エイチダブリュワイワンゼロワン」のように発音されることが可能である。
【０２１５】
テキストツースピーチレンダリング２６００ｃが、レンダリング２６００ｂについて上記で記述されたように「Ｈ」「Ｗ」「Ｙ」と表すようにスピーチ生成装置に命令するが、「ワンゼロワン」の代わりに「ワンハンドレッドアンドワン」と発音するように変更されている。テキストツースピーチレンダリング２６００ｄが、レンダリング２６００ａのように「Ｈｉｇｈｗａｙ」を発音するようにスピーチ生成装置に命令するが、「１オウ１」が変更されており、これは、音声的には「ワンオウワン」のように聞こえることが可能である。本明細書において示される変更は、標準的なエンティティ「ＨＷＹ１０１」が、発呼者に対して互いに異なって聞こえる、異なるボイスダイアログを生成するように、テキストでどのように変更されることが可能であるかの単なる一例を反映する。どのレンダリングを適用するかの選択は、事前に知られている、またはいくつかの場合では発呼者から実時間で収集される、発呼者に関する情報に応じる。
【０２１６】
本発明の一実施形態では、ダイアログ選択肢に対する応答としての第１のボイス開始が、明確な発音または「引延ばし発音（ｄｒａｗｌ）」の傾向について分析されることが可能である。たとえば、発呼者の性質がシックアクセントとして分類される場合、発呼者に対するダイアログ応答は、発呼者のアクセントまたは方言を模倣するように合成されることが可能である。対話中に方言を模倣する利点は、システムの使用に関して発呼者により気楽に感じさせることである。たとえば、ニューヨーク市のいくつかの地域では、地元民は、地域的に知られている地標についてあるスラング用語を使用する。スラング用語が企業によって事前に知られている場合、それは、スラング用語を呈示する発呼者に対するダイアログ応答において使用されることができる。さらに、ある産業特有用語が、異なる産業では異なる意味を有する可能性がある。発呼者が、２つ以上の産業に関係付けられるダイアログを提供するサービスにおいて、産業特有発呼者として識別される場合、発呼者に対する応答において、適切な用語を動的に適用することができる。
【０２１７】
図２７は、本発明の一実施形態による、組織化されたマッピング表２７００を示すブロック図である。表２７００は、図２３のＴＴＳプロセッサ内に、または、プロセッサにアクセス可能である外部データストア内に提供されるソフトウエア表を表す。表２７００は、テキストツースピーチレンダリングを含むヒットリストであり、テキストツースピーチレンダリングに関連付けられた生成スピーチファイルに連結される。
【０２１８】
表２７００は、テキストツースピーチエンティティＴＳ−１からＴＳ−５の選択を含む列２７０１を有する。テキストエンティティＴＳ−１からＴＳ−５は、上記で図２６を参照して記述されたエンティティ２６００と構造的に同様である。すなわち、ＴＳエンティティは、産業用語、位置名、高速道路、州道路、地標などを含めて、基本的な識別可能用語に対応する。表２７０２は、口語表現またはテキストツースピーチレンダリング１〜６を列挙する列を有する。口語表現１〜６は、事前に準備されたテキストレンダリングであり、列２７０１に含まれる項目（ＴＳ−１から５）に対応する。ＨＴＴＰ１．１、または複数の参照リングが要素番号２７０３によって本明細書において表される他のタイプの参照リンク（矢印）が、列２７０１の各項目を列２７０２の少なくとも１つの項目に連結する。
【０２１９】
この例では、表２７００のＴＳエンティティのただ１つが、２つ以上の変更テキストツースピーチレンダリングに連結される。たとえば「ＨＷＹ１０１」とすることが可能であるＴＳ−５は、口語表現５および口語表現６に連結される。口語表現５は、カルフォルニア州ロサンゼルスの地域において使用される「ＨＷＹ１０１」の適切な発音を命令し、一方、口語表現６は、サンフランシスコ湾地域において使用される「ＨＷＹ１０１」の適切な発音を命令する。当然、エンティティＨＷＹ１０１は、地域に応じて発音が異なると想定される。表現５および６は、図２６のテキストレンダリング２６００ａ〜ｄと同様である。したがって、表現５および６は、アプリケーション消費者または発呼者の地理的起源の規則に基づいて選択可能な選択肢であるＸＭＬテキストレンダリングである。
【０２２０】
この例では、実際のボイス合成（可聴ボイスダイアログ応答を生成する）が、表現５または６の一方を含むＶＸＭＬページによって提供される命令に基づいて、発呼者エンド（ボイスポータル）において実施されると想定される。一実施形態では、ボイスファイルは、アドミニストレータによって事前準備され、アプリケーション配置方式の一部としてエンドシステムに分配される。この場合、事前に記録されているボイスファイルが、この場合は５または６である受信表現の解釈に基づいて選択される。
【０２２１】
表２７００は、実行され、アクセスされ、アプリケーション配置時にアプリケーションによって使用される適切なエンティティおよびテキスト表現選択肢がポピュレートされているボイスアプリケーションに応じて、一般的なテンプレートとして構築されることが可能であるという意味で、動的な表とすることが可能である。ユーザがボイスアプリケーションと対話するとき、ＴＴＳプレプロセッサ２５０１は、ポピュレートされた表にアクセスし、アプリケーションと対話するインスタント発呼者について事前に知られている情報、またはそのインスタント発呼者によって提供される情報に基づいて、どのＴＴＳ表現を選択すべきかを判定する。
【０２２２】
本発明の一実施形態では、１つのボイスアプリケーションと対話することにより、無関係の内容を有する他のボイスアプリケーションの配置がトリガされる場合、いくつかの場合では第１のアプリケーションとの対話から収集される発呼者に関する情報は、新しい内容選択肢に関係付けられる第２の表の生成に使用されるために、第２のアプリケーションの領域に自動的に渡される。本明細書では、処理構成要素にアクセス可能なシステムデータベースに記憶されているデータのマスタ表から、単一ボイスアプリケーションに関連付けられた内容に特有の表を、その場で生成することができることに留意されたい。
【０２２３】
企業によって配置されたボイスアプリケーションを使用して、企業から発呼者に送信された自動ボイス応答を個人化する能力は、従来のモノトーンで同じユーザが計算した応答から改良された、対話経験を発呼者に提供する。そのような改良は、発呼者にとってより理解可能である有用で実用的な「変換」だけでなく、そのようなボイスアプリケーション分散システムのより頻繁な使用を促進するエンターテインメント価値をも提供する。
【０２２４】
行為状態適応
図２８は、本発明の一実施形態による、行為適応エンジンで改良された図２５のＶＸＭＬアーキテクチャのブロック図である。ＶＸＭＬアプリケーション配置アーキテクチャ２８００が、この例において示され、上記で図２５の記述を参照して記述されたＶＸＭＬアーキテクチャ２５００と同様である。以前に記述された構成要素は、上記で図２３および２５の記述において導入された元の要素番号を維持する。アーキテクチャ２８００は、アプリケーションサーバ２３０１、電話サーバ／ボイスポータル２３０２、およびウエブポータル２３０３を備える。
【０２２５】
ボイスアプリケーションサーバ２３０１は、行為適応エンジン２８０１で改良される。行為適応エンジン２８０１は、ボイスアプリケーションダイアログとの対話中のユーザの行為状態、およびいくつかの場合は感情状態を識別するように適合される。エンジン２８０１は、以前に記述されたテキストツースピーチプレプロセッサ２５０１を含む、アプリケーション論理ブロック２３０９の一部である。上記で図２３を参照して記述された静的最適化装置２３１２および動的最適化装置２３１１は、この例では、図面空間を保持するために示されていないが、存在すると想定されることが可能である。
【０２２６】
適応エンジン２８０１は、２重矢印によって本明細書において示されるように、ダイアログランタイムプロセッサ（Ｄｉａｌｏｇ  Ｒｕｎｔｉｍｅ  Ｐｒｃｓｒ．）への直接アクセスを有する。適応エンジン２８０１は、論理バス構造２３１５を経たＶＸＭＬレンダリングエンジン２３１４、ボイスアプリケーション配置ソフトウエア（ＶＡＤＳ）ブロック２３０８、およびデータベース／リソースアダプタブロック２３１０への通信アクセスをも有する。
【０２２７】
対話が、本発明のボイスアプリケーションソフトウエアを使用して発呼者と企業との間において行われる際に、発呼者エンドにおいて発呼者によって発音されるメニュー選択肢などに対する応答は、好ましい実施形態では、ＸＭＬベーステキストとしてレンダリングされ、かつ発呼者に送達されるその後の応答の決定のために、ボイスアプリケーションサーバ２３０１において解釈される。企業からの応答は、この場合、発呼者ごとに異なることが可能であり、この場合はポータル２３０２またはウエブポータル２３０３である発呼者によって使用されるポータルにおいて、ボイス合成のためにＶＸＭＬ（ＶＸＭＬページ）としてレンダリングされる。
【０２２８】
適応エンジン２８０１は、対話中に発呼者からのＶＸＭＬ応答を傍受して、応答選択肢に連結される１セットの行為制約に従って応答を分析するように構成され、応答選択肢は、選択され、次いで、ＶＸＭＬ応答に埋め込まれ、合成ボイスとして発呼者に実演される。
【０２２９】
適切かつ適正なＶＸＭＬページ応答を決定するために存在することが可能である様々な行為制約は、限定されない。たとえば、ユーザが、反復使用によりボイスアプリケーションメニューの特定のセットに熟知することが可能である。メニューのレンダリング中、今述べたユーザは、選択肢がメニューにおいて到達される前に、メニューツリーのさらに下にある特定の選択肢を選択するように、事前に設定されることが可能である。その場合、その特定のユーザの行為は、ほぼサービスがアクセスされるたびに、ユーザが準選択肢を発音するというものである。この場合、適応エンジン２８０１は、提供前に選択を認識し、この特定のユーザが、サービスおよびメニューツリーに非常に熟知していると判定する。次に同じユーザが、サービスにコールするとき、メニューナビゲーションをスキップして、適切な結果を瞬時にユーザに送達することができる。上記で網羅された種類の行為は、メニューナビゲーション行為である。
【０２３０】
場合ごとに決定することができる他のタイプの行為は、発呼者のストレスの程度である。エンジン２８０１は、応答内容を分析することによって、特定の発呼者のストレスレベルを判定することができる。好ましい実施形態では、エンジン２８０１によって分析することができる２つの形態の応答内容が存在する。これらは、ＶＸＭＬテキストベース内容、および添付物としてＶＸＭＬドキュメントに添付されたボイスサンプリングである。たとえば、ある間投詞、または他の「否定的な」語もしくは句を認識して、発呼者が、ボイスアプリケーションとの対話中にそれらを言葉にすることができる場合、レンダリングすることができる。適応エンジンは、Ｒｕｌｅ  Ｍｇｒ．などの外部リソース、およびアダプタブロック２３１０を経た外部データストアへのアクセスを有する。
【０２３１】
一実施形態では、適応エンジン２８０１は、ＸＭＬベーステキストファイルと共に送信することができる、ショートウエーブファイルまたは他のデジタル化ボイスファイルを分析することができる。このようにして、発呼者のストレスレベルを決定し、次いで決定レベルに基づいて、応答選択を決定することができる。たとえば、発呼者が、事前設定閾値より上のデシベルレートにおいて発音する場合、発呼者は、叫んでいると判定されることが可能である。デシベルレートは、対話セグメントの開始時に記録された短い１秒または２秒の音声ファイルから分析され、次いで、発呼者応答のテキストレンダリングと共に添付物として送信されることができる。
【０２３２】
メニューナビゲーションの速度は、発呼者が、企業の特定システムについて有する経験レベルをおおよそ決定するために、エンジン２８０１によって決定されることができる。その後のメニューおよび準選択肢が、特定の発呼者の「経験レベル」の決定結果に基づいて、注釈され、ドロップされ、または追加されることが可能である。考慮されることが可能である多くの行為考慮事項が存在する。
【０２３３】
適応エンジン２８０１は、対話中に発呼者に対するＶＸＭＬページとして、その後レンダリングするための微調整メニューおよび選択肢選択に、ＴＴＳプロセッサ２５０１および以前に記述された最適化装置と協動する論理として提供されることが可能である。いくつかの実施形態では、エンジン２８０１は、制約が可能にするのであれば、他のダイアログ改良ツールに優先することができる。たとえば、発呼者が極度に混乱している場合、その後のボイスアプリケーションダイアログが、発呼者の懸念をすぐに取り除くために、ライブ接続選択肢をライブエージェントに提供することが可能である。
【０２３４】
図２９は、本発明の一実施形態による、図２８のシステムとのユーザ対話を示すプロセス流れ図である。ステップ２９００において、ユーザが、ボイスアプリケーションにアクセスする。任意のボイス可能ポータルを経て、ボイスアプリケーションにアクセスすることができる。いくつかの場合、ユーザが、ボイスアプリケーションにコールする。他の実施形態では、ボイスアプリケーションは、ユーザにコールし、ユーザは、コールを単にピックアップする。一部にはメディアサポートに応じるさらに他のアプリケーションでは、ボイスアプリケーションは、ユーザにブロードキャストまたはマルチキャストされることが可能である。ステップ２９００において、あいさつおよびユーザ識別体制またはメニューが、実行されることが可能である。識別は、ボイスインプリント識別、またはパスワード／ピン選択肢など、バイオメトリック機能を備えることが可能である。
【０２３５】
ステップ２９０１において、第１のアウトバウンドメニューが、ユーザに対して実演される。メニューは、ユーザに送達される動的ボイスアプリケーションの第１の対話式メニューである。アプリケーションが、対話式ボイス応答（ＩＶＲ）システム上において実行される場合、ボイスおよびタッチトーン応答の組合わせが、ユーザ応答として受容されることが可能であるが、この例は、ボイス応答を対象とする。この例のプロセスでは、ステップ２９０１において送達されるメニューのナビゲーション中に、ユーザのナビゲーション行為に関する制約が存在すると想定される。たとえば、ステップ２９０１のメニューが完了する前に、ユーザが、ステップ２９０２においてメニューまたはサブメニューの選択肢を発音することによって応答する場合、ステップ２９０３において、図２８に参照して記述されたエンジン２８０１に類似する適応エンジンが、応答を分析する。
【０２３６】
ステップ２９０３の応答傍受がトリガされることが可能であり、または、アプリケーションの間に続行されることが可能である。メニューが終了する前にユーザが応答する場合、メニューに割り付けられた時間が満了する前に応答が来るということは、適応エンジンによる傍受のトリガファクタとすることができる。ステップ２９０３における応答の分析は、ステップ２９０４において、適切な応答選択肢または結果と応答を整合させることを含むことが可能である。適応エンジンは、準選択肢がメニューナビゲーションにより利用可能となるかなり前に、特定の準選択肢のユーザ選択を反映する記録を形成して記憶することが可能である。この場合、エンジンは、特定の発呼者をシステムについて「経験済み」とラベル付けすることが可能であり、これは、ユーザが、戻される結果を速めるために、特定の準選択肢を記憶したことを意味する。
【０２３７】
ステップ２９０５において、分析された発呼者のメニュー応答に対する応答して選択された最も整合性の高い応答選択肢が戻され、ステップ２９０６において、あるとすれば実演される次のメニュー選択肢に関する決定が行われる。企業からの選択された応答が、ユーザによって要求された埋込み結果を含むダイアログを備える場合、さらなるメニュー活動または対話は存在しない可能性がある。ステップ２９０２の発呼者要求が、特定のメニューに対する要求を含む場合、ステップ２９０７において、選択されたメニュー選択肢は、ＶＸＭＬページレンダリングのために埋め込まれる。一方ステップ２９０８において、通常はボイスアプリケーションの一部であるあらゆる不必要なメニューが破棄され、ユーザに送信されない。
【０２３８】
経験のないユーザの場合、ステップ２９０９においてユーザが選択する前に、ステップ２９０１が完全に実演されることが可能である。ステップ２９１０において、適応エンジンは、ユーザが「新しい」という記録を記憶することが可能である。任意の事象において、エンジンは、ユーザ応答を傍受して分析し（そのように構成される場合）、ステップ２９０４において記述された既存の企業規則に従って、ユーザ応答を企業応答選択肢と比較する。また上記で記述されたように、ステップ２９０５において、企業応答について最も整合性の高い選択肢が戻される。ステップ２９１１において、次の順番のメニュー選択肢が、存在するとすれば実演され、または、企業応答ダイアログに埋め込まれた取込み結果が、ステップ２９１１において実演されることが可能である。
【０２３９】
上記で概述されたプロセスでは、行為制約は、提供されるメニューおよび準選択肢より前にユーザがナビゲートする場合、不必要な選択肢を中間においてドロップすることを指図する。たとえば、同じ発呼者からのいくつかの同じトランザクションを記録することに基づいて適切な応答である確率を決定することに従って、特定のメニュー選択肢または選択肢結果を発呼者に実演することによって、システムによる応答をさらに改良するために、統計的確率を使用することができる。
【０２４０】
ボイスアプリケーションの創出および配置の当業者なら、上記で示されたステップが、本発明の精神および範囲から逸脱せずに、サブプロセスを含むことが可能であることを理解するであろう。たとえば、最終ＶＸＭＬページが企業からユーザへの応答としてレンダリングされる前に、テキストツースピーチ処理および静的または動的最適化のために、ステップ２９０６の後でサブプロセスが存在することが可能である。いくつかの場合、適応エンジン分析から得られる動作は、ある他のプロセスを優先するように構成することができる。当業者には、示される対話プロセスステップの目的および順序は、プロセスに影響を与える制約の性質に従って変更することが可能であることも明らかになるであろう。
【０２４１】
図３０は、本発明の他の実施形態による、図２８のシステムとのユーザ対話を示すプロセス流れ図である。ステップ３０００において、あいさつが、ボイスアプリケーションにアクセスする発呼者に対して実演される。あいさつは、発呼者ＩＤ、自動番号識別（ＡＮＩ）、または他の識別方法に基づいて、個々の発呼者に対して個人化されることができる。
【０２４２】
ステップ３００１において、発呼者は、ボイスアプリケーションにログインする。このステップは、いくつかの場合では随意選択である。ログインは、バイオメトリック声紋識別を含むことが可能であり、これは、記録されかつＸＭＬベースデータと共に添付音声ファイルとして送信される、発呼者のショート音声ボイスサンプルを分析することによって、企業において確認することができる。
【０２４３】
ステップ３００１の発呼者のセキュリティ承認を想定すると、ボイスアプリケーションの第１のメニューが、ステップ３００２において発呼者に対して実演される。発呼者が、図２９に関して示されたプロセスに関して上記で記述されたようにシステムに熟知している場合、発呼者は、ステップ３００３ａにおいて初期メニューが完了する前に応答することがある。ステップ３００３ｃにおいて、適応エンジンは、応答分析に基づいて、発呼者がシステムに関して有する熟知レベルを評価する。たとえば、発呼者が、メニューツリーのはるかに下にあるメニューの認識メニュー準選択肢を発音する場合、発呼者は、「システム熟知」とラベル付けされることが可能であり、ボイスアプリケーションの適切な効率化が確保される。
【０２４４】
この例示的な対話では、第２の提供されたメニューおよび関連する選択肢は、ステップ３００４において省略され、ステップ３００３ａの発音化は、第２のメニューまたは関係選択肢ではないと判定される。ステップ３００５において、第３の提供されたメニューも省略されるが、ステップ３００６において、第３のメニューの準選択肢の１つと等しい取込み結果とすることができる準選択肢結果が実演され、その理由は、ステップ３００３ａにおいて発呼者の発音化に「応答する」認識結果値であるからである。ステップ３００６において実演されるダイアログの厳密な性質は、ステップ３００ａにおける発呼者の発音応答の内容に直接応じる。発呼者が、特定の「テュープル」の代わりに特定のメニューを要求する場合、適切なメニューが実演される。
【０２４５】
直前で記述されたステップの順序に関連する制約は、図２９の記述に関して上記で記述されたものと非常に類似する。すなわち、発呼者が、選択肢および準選択肢をすでに知っている場合、システムは、ボイスアプリケーションのすべての不必要なダイアログを省略することが可能である。
【０２４６】
追加の制約が、示される例示的なプロセスに含まれる。たとえば、発呼者が、ステップ３００３ｂにおいて示されるように、ステップ３００２の第１のメニューに対する発呼者の応答について優柔不断である場合、ステップ３００３ｃにおいて、適応エンジンは、発呼者を「システム未熟者」とラベル付けすることが可能である。そのようなラベル付けは、ステップ３００７において動的なヘルプメニューを準備するようにシステムをトリガし、メニューは、発呼者の優柔不断な性質に密接に関係する選択肢を含む。ステップ３００８において、対話ヘルプメニューが発呼者に実演される。
【０２４７】
ヘルプメニューは、「全体ヘルプメニュー」に属するダイアログオブジェクトとして動的に構築されることができる。動的選択肢は、適応エンジンによって検出される発呼者の現在の問題に最も密接に関係する対話式選択肢のみを含む。たとえば、発呼者が、どちらに進むべきなのか確信がないので、「選択肢Ａまたは選択肢Ｂ」と発音する場合、適応エンジンは、発呼者がより情報のある決定を行うことを可能にする、適切な擬似事実の準備をトリガすることができる。動的ヘルプメニューは、完全であるとき、元のメニューに再び連結することができ、それにより、発呼者は、必要な補助を得た後、繰り返すことが可能になる。これは、発呼者がハングアップして再ダイヤルすることを必要とせずに、達成することができる。
【０２４８】
上記の例を使用すると、異なる個人の必要性に従って、システムによって異なる個人をサービスすることができる。より迅速により多く経験する個人は、より迅速なサービスのために効率化されたボイスアプリケーションを有し、一方、より緩慢な個人は、特定の必要性に従って拡張されるボイスアプリケーションを有する。
【０２４９】
図３１は、他の実施形態による、図８のシステムとのユーザ対話を示すプロセス流れ図である。ステップ３１００において、発呼者が上記でさらに記述されたボイスアプリケーションにアクセスすると想定して、あいさつが実演される。ステップ３１０１ａにおいて、クライアントは、以前に記述されたパスワード、ピン、またはおそらくは声紋識別を含むボイスアプリケーションにログインする。ステップ３１０１ａ中、行為適応エンジンは、クライアントの声紋または他の発音をサンプリングして、発呼者のボイスの高ストレスレベルを検出する。発音は、記録され、デジタル音声ファイルとしてＸＭＬベースデータと共に送信されることができる。ストレス検出に適合された制約は、デシベル出力閾値を含むことが可能である。デシベル比較は、クライアントの特有のデシベル閾値を設定する目的で、クライアントのボイスの平均デシベル出力を評価するために、同じクライアントによる以前のトランザクション中にサンプリングされた以前の結果について行うことができる。最終サンプリングが平均範囲より高い場合、クライアントがストレスを経験していると判定されることが可能である。
【０２５０】
他の実施形態では、あらゆる発音された間投詞、または抑揚の特徴も、クライアントがストレス下にあることを示すことが可能である。適応エンジンは、以前に記述されたように、第１の対話において取られたショート音声レンダリングをサンプリングすることにより、これらの全体的なボイス特徴を認識することができる。間投詞、否定句、および抑揚パターンは、記憶されて、複数トランザクションにわたってクライアントについて規格化されることが可能であり、たとえば、クライアントが平均ムードとは異なる状態にあるかをシステムが検出することを可能にする。さらに、クライアントによって通常発音されるある句が欠如していることは、通常より高いストレスレベルを示すことが可能である。たとえば、クライアントが、「ｍａｙ  Ｉ  ｈａｖｅ  ｍｙ  ｂａｌａｎｃｅ  ｐｌｅａｓｅ」と常に言い、最終サンプリングが、プリーズの語を欠如していると判定される場合、システムは、クライアントが通常より高いストレスレベルを有すると判定することが可能である。ストレス検出の制約を構成するための多くの異なる方法が存在する。
【０２５１】
クライアントについて高ストレスレベルを検出することにより、この例示的な対話では、ステップ３１０１ｃにおいて対話を監視する決定がトリガされる。監視は、クライアントが、ボイスアプリケーションと対話している最中の適応エンジンによる周期的なボイスサンプリングから、ライブエージェントまたはスーパーバイザによる連続的な監視にわたることが可能である。ステップ３０１ｂおよび３１０１ｃは、第１のメニューがステップ３１０２において実演される前に行うことができる。ステップ３１０３ａにおいて、クライアントは、以前のメニューから選択肢を発音する。クライアントは、自分の応答中監視されていることに留意されたい。
【０２５２】
行為適応エンジンは、ボイスサンプリングおよび分析により監視を実施し、次いでこの例示的なプロセスではステップ３１０３ｂにおいて、適応エンジンは、クライアントの高ストレスの連続を検出すると想定する。監視制約の一部として、ステップ３１０３ｃにおいて、エンジンは、特別なメニューを準備するようにシステムをトリガする。正確な規則は、２つ以上のサンプリングを必要とする可能性があり、ストレスは、特別メニューの準備がトリガされる前、各サンプリングにおいて高い。他の場合、１つのサンプリングで十分な可能性がある。また、ライブ監視が、第１のサンプリング検出ストレスのトリガ結果であることも可能であり、この場合、プロセスは、本明細書において示されるプロセスとは異なる。
【０２５３】
この例示的なプロセスでは、特別メニューが、ステップ３１０３ｃにおいて準備され、次いで、対話式ボイスメニューとして、ステップ３１０４においてクライアントに送信されてかつレンダリングされる。この場合、メニューは、少なくとも１つの自動メニュー選択肢を提供し、検出されたストレスレベルのために、他の発呼者がエージェントを待機するよりおそらくは前に、ライブエージェントに接続される選択肢を含む。他のファクタが、ライブエージェントに介入する、または組合わせメニューにおいて選択肢を少なくとも提供することを決定するために、使用されることも可能である。これらのファクタは、支払い履歴、企業でのクライアントの地位、企業に出されるクライアントの注文の金銭値などを含むことができる。
【０２５４】
本発明の一実施形態では、行為適応エンジンは、特定のアプリケーションとの各対話を傍受するように構成されることができる。エンジンは、マルチタスク環境の複数同時の傍受および計算について適合されることができる。他の実施形態では、エンジンは、別々の機能インスタンスを作成することができ、各作成されたインスタンスは、特定のアプリケーションと対話する特定のクライアントに専用である。エンジンは、データキュー、外部リソース、および機能している他の計算モジュールを使用することができる。たとえば、エンジンは、クライアント応答を傍受して、１セットの可能なダイアログ応答の選択を含めて、制約に基づく決定を行うことが可能である。次いで、ダイアログ応答は、静的または動的キャッシングが制約に基づく最適化により決定される前に、無関係な制約の他のセットに基づいて、テキストツースピーチ事前処理により、最適応答に狭められることが可能である。
【０２５５】
他の実施形態では、エンジンは、トリガ制約に従って実行されるように構成されることが可能であり、制約が特定のユーザについて有効である場合、エンジンは、次のクライアント応答を傍受する。ボイスアプリケーションが、分析結果から生成された値に従って、動的に注釈を付けられる。分析結果は、同じアプリケーションを繰り返して使用する繰返しユーザについて個人化サービスを提供するために、統計的分析により最適化されることができる。ボイスアプリケーションユーザが、統計的展開および分析の補助で展開されかつ提供されたある企業応答を優先することを可能にするように、クライアント制御を提供して、対話中に利用可能とすることができる。たとえば、クライアントが、クライアントがシステムにアクセスするたびに、結果が第１のあいさつに必ず埋め込まれることを、サービスによって提供される特定の結果について繰り返して要求する場合、「元のメニュー選択肢に戻る」を結果と共に提供することができ、それにより、クライアントが、現行トランザクションにおいてその結果を追求していない場合、元のボイスアプリケーションメニューを指示することができる。
【０２５６】
図３２は、本発明の一実施形態による、図２８の行為適応エンジン２８０１の基本的な構成要素を示すブロック図である。行為適応エンジン（ＢＡＥ）２８０１が、他のモジュールならびに外部リソースと通信することができる自蔵モジュールとして、この例では提供される。エンジン２８０１は、ボイスアプリケーションとのクライアント対話から得られるクライアントデータ入力を受信するように適合された入力ブロック３２０２を有する。一実施形態では、クライアントデータ入力は、上記で図２８を参照して記述されたボイスアプリケーションサーバ２３０１の論理通信バス構造２３１５上でＢＡＥ２８０１に送達される。
【０２５７】
クライアントデータは、ダイアログ応答データ、クライアント履歴および／または状況データ、ならびにデジタル音声ファイル添付物としてクライアントデータと共に送信されるクライアントボイスサンプリングを含む。好ましい実施形態では、ボイスファイル以外のクライアントデータは、クライアントボイス応答からクライアントポータルにおいてレンダリングされたＸＭＬベースデータである。
【０２５８】
入力ブロック３２０２が、標準的なポートの場合と同様に、複数入力ポート、入力データキュー、および処理論理を備えることが可能である。一実施形態では、入力ブロック３２０２は、双方向ポートとすることが可能であるが、この例では一方向ポートである。対話クライアントに再び送信されるエラー通信およびダイアログ応答が、ボイスアプリケーションサーバのポートを経て送達される。
【０２５９】
ＢＡＥ２８０１は、ＢＡＥ２８０１の内部に提供され、かつ、ＸＭＬベースデータ、および存在すればＸＭＬパッケージに添付されたボイスファイルを処理するように構成された、処理論理ブロック３２０１を有する。処理論理は、ボイス分析装置３２０４を有し、これは、ショート音声ファイルを受信して、デシベル特徴、ボイス抑揚特徴、およびある用語の包含または欠如について、それら音声ファイルを分析することができる。分析装置３２０４は、分析のためにボイスファイルを実行するボイスファイルプレーヤ（図示せず）を含む。
【０２６０】
処理論理３２０１は、処理論理３２０１の内部に提供され、かつ、クライアントのボイス応答からレンダリングされたＸＭＬベースデータを認識するように構成されたＸＭＬ読取り装置３２０５を有する。ＸＭＬ読取り装置は、クライアントによって作成されたマニュアル選択などの他のクライアント入力データ、および識別データ、ならびにクライアント対話データと共にクライアントに関して提供されることが可能であるあらゆる他のデータも受信して解釈する。
【０２６１】
ＢＡＥ２８０１は、ＢＡＥ２８０１の内部において提供され、かつ、統計および規則データベースを含む外部データソース、ならびに内部システムモジュールと双方向に通信するように構成された入力／出力ブロック３２０５を有する。一実施形態では、ブロック３２０５と他のシステムおよびモジュールとの間の外部データ通信が、上記でさらに記述されたボイスアプリケーションサーバの論理バス構造によって容易になる。外部ソースへの直接アクセスが、上記で図２８を参照して記述されたリソースアダプタブロック２３０１により達成される。しかし、エンジン２８０１は、いくつかの実施形態では、外部リソースに直接アクセスし、かつ通常のサーバ通信とは独立であるように構成されることが可能である。この場合、エンジンは、そのエンジンに提供され、かつ遠隔データ線上で通信するように構成された専用サーバポートを有する。
【０２６２】
Ｉ／Ｏブロック３２０５は、複数の入力および出力データキュー、ならびにデータポートアーキテクチャに存在することが一般に知られているポート処理論理を含むことが可能である。ＢＡＥ２８０１の中心に、決定論理ブロック３２０３があり、この決定論理ブロック３２０３は、どの利用可能企業ダイアログ応答または応答のセットが、ＶＸＭＬページとしてレンダリングされたダイアログに埋め込まれ、またはそのダイアログに連結され、かつボイスアプリケーションと対話するクライアントに再び送信される応答の候補として、識別されるかについて決定するように構成される。
【０２６３】
決定ブロック３２０３は、１つまたは複数の企業規則、ならびに利用可能であれば外部データおよび統計値に従って、ボイス分析装置３２０４およびＸＭＬ読取り装置３２０５の組合わせ結果を処理し、ＶＸＭＬページレンダリングに提出される候補企業ダイアログの１つまたは１セットを識別する値を形成する。決定値は、たとえば、１つまたは複数の随意選択メニューまたはメニュー選択肢、ライブ通信介入を確立するためのリンク、および任意の取込み結果を含めて、内部に含まれる他のボイスアプリケーションまたはメニューもしくは選択肢に対するリンクと同等であることが可能である。
【０２６４】
この例では、ＢＡＥ２８０１は、自蔵モジュールとして示される。しかし、他の実施形態では、ＢＡＥ２８０１の機能および能力は、ボイスアプリケーションサーバ領域内において分布する複数の内部動作モジュールとして提供されることが可能であり、それにより、内部動作モジュールは、本発明の目的を達成するように、互いに対話することが可能である。多くの可能性が存在する。
【０２６５】
本発明の方法および装置は、多くの可能な実施形態および使用法を考慮して、審査の際に最も広範に解釈されるように提供されるべきである。本発明の精神および範囲は、請求項によってのみ限定される。
【図面の簡単な説明】
【０２６６】
【図１Ａ】従来の技術による、ＶＸＭＬ可能ＩＶＲ展開および配置環境の基本アーキテクチャを示すブロック図である。
【図１Ｂ】本発明を実施するために改良された図１Ａの基本アーキテクチャを示すブロック図である。
【図２】本発明の一実施形態による、ＶＸＭＬボイスアプリケーションのボイスアプリケーションシェルまたはコンテナを創出するためのステップを示すプロセス流れ図である。
【図３】本発明の一実施形態による、簡単なボイスアプリケーションコンテナを示すブロック図である。
【図４】本発明の一実施形態による、ダイアログオブジェクトモデルを示すブロック図である。
【図５】本発明の一実施形態による、ＶＸＭＬ可能ボイスアプリケーションのボイスダイアログを創出するためのステップを示すプロセス流れ図である。
【図６】本発明の一実施形態による、消費者との初期接続後のダイアログ移行フローを示すブロック図である。
【図７】本発明の一実施形態による、デベロッパのログインスクリーンを含むデベロッパのフレームの平面図である。
【図８】図７のデベロッパのプラットフォームインタフェースのホームページのスクリーンショットを含むデベロッパのフレームの平面図である。
【図９】図８の先行フレームのセクション８０３における選択肢アドレスとの対話によりアクセス可能なアドレスブロック９１１のスクリーンショットを含む、デベロッパのフレームの平面図である。
【図１０】新しいボイスアプリケーションを創出するためのスクリーン１００１を表示するデベロッパのフレームの平面図である。
【図１１】スクロールダウンの結果として他の選択肢を示す図１０のスクリーンを示すデベロッパのフレームの平面図である。
【図１２】本発明の一実施形態による、ダイアログ構成ページを示すダイアログ構成ウィンドウのスクリーンショットである。
【図１３】後続接点へのダイアログ状態の進行を示す、図１２のダイアログ設計パネルのスクリーンショット１３００を示す図である。
【図１４】好ましい実施形態による、図１３の例から活動化されたシソーラス構成ウィンドウのスクリーンショットを示す図である。
【図１５】本発明の一実施形態による、創出されたモジュールを管理するためのスクリーンを示すデベロッパのフレームの平面図である。
【図１６】本発明の一実施形態による、ウエブ取入れのために改良された図６のダイアログ移行フローのブロック図である。
【図１７】本発明の一実施形態による、自動ウエブ取入れおよびデータレンダリングのための追加構成要素を示す、図１Ｂのボイスアプリケーション分散環境のブロック図である。
【図１８】オブジェクトモデルとして取り入れられかつ創出された、ウエブサイト論理階層を示すブロック図である。
【図１９】経済的なレンダリングのためにモデルを簡略するように加工されている図１８のモデルを示すブロック図である。
【図２０】ウエブサイトの論理ツリーの複雑さを低減するための中間ステップを示すプロセス流れ図である。
【図２１】本発明の一実施形態による、ボイスポータルとウエブサーバとの間の安全な接続性を示すブロック図である。
【図２２】本発明の一実施形態による、語彙管理サーバおよびソフトウエアで改良された図１Ｂのアーキテクチャを示すブロック図である。
【図２３】本発明の一実施形態による、キャッシュ最適化構成要素を含むＶＸＭＬアプリケーションアーキテクチャの様々な機能構成要素を示すブロック図である。
【図２４】本発明を実施するためのステップを示すプロセス流れ図である。
【図２５】本発明の一実施形態による、テキストツースピーチプレプロセッサで改良された、図２３のＶＸＭＬアーキテクチャのブロック図である。
【図２６】テキストストリングのスピーチレンダリングの可能な変形を示すブロック図である。
【図２７】本発明の一実施形態による、組織化マッピング表を示すブロック図である。
【図２８】本発明の一実施形態による、行為適応エンジンで改良された図２３のＶＸＭＬアーキテクチャのブロック図である。
【図２９】本発明の一実施形態による、図２８のシステムとのユーザ対話を示すプロセス流れ図である。
【図３０】本発明の他の実施形態による、図２８のシステムとのユーザ対話を示すプロセス流れ図である。
【図３１】他の実施形態による、図８のシステムとのユーザ対話を示すプロセス流れ図である。
【図３２】本発明の一実施形態による、図２８の行為適応エンジンの基本的な構成要素を示すブロック図である。
【図１Ａ】
2007527640.tif 000002
【図１Ｂ】
2007527640.tif 000003
【図２】
2007527640.tif 000004
【図３】
2007527640.tif 000005
【図４】
2007527640.tif 000006
【図５】
2007527640.tif 000007
【図６】
2007527640.tif 000008
【図７】
2007527640.tif 000009
【図８】
2007527640.tif 000010
【図９】
2007527640.tif 000011
【図１０】
2007527640.tif 000012
【図１１】
2007527640.tif 000013
【図１２】
2007527640.tif 000014
【図１３】
2007527640.tif 000015
【図１４】
2007527640.tif 000016
【図１５】
2007527640.tif 000017
【図１６】
2007527640.tif 000018
【図１７】
2007527640.tif 000019
【図１８】
2007527640.tif 000020
【図１９】
2007527640.tif 000021
【図２０】
2007527640.tif 000022
【図２１】
2007527640.tif 000023
【図２２】
2007527640.tif 000024
【図２３】
2007527640.tif 000025
【図２４】
2007527640.tif 000026
【図２５】
2007527640.tif 000027
【図２６】
2007527640.tif 000028
【図２７】
2007527640.tif 000029
【図２８】
2007527640.tif 000030
【図２９】
2007527640.tif 000031
【図３０】
2007527640.tif 000032
【図３１】
2007527640.tif 000033
【図３２】
2007527640.tif 000034
【国際調査報告】
2007527640.tif 000035