(57)【要約】  音声アプリケーションの作成および配布システムは、音声アプリケーションを作成しかつ通信ネットワークを介してクライアントに提供する音声アプリケーションサーバと、通信ネットワークにアクセスすることができ、音声アプリケーションとのクライアント対話を容易にする少なくとも１つの音声ポータルノードと、音声アプリケーションサーバから実行可能な推論エンジンとを含む。好ましい実施形態では、推論エンジンが、進行中の音声対話における１つまたは複数の所定ポイントの間に呼び出されて、クライアントニーズの推論が、提供された音声アプリケーションのアクティブコールフロー内の所定ポイントの間に、対話に関連する既存のデータの分析に基づいて実施できるかどうかを判定し、推論が保証される場合には、どの推論ダイアログが実行され、かつコールフロー内に挿入されるかを決定する。【特許請求の範囲】
【請求項１】
音声アプリケーションを作成し、かつ通信ネットワークを介してクライアントに提供する音声アプリケーションサーバと、
通信ネットワークにアクセスすることができ、音声アプリケーションとのクライアント対話を容易にする少なくとも１つの音声ポータルノードと、
音声アプリケーションサーバから実行可能な推論エンジンとを備えた、音声アプリケーション作成および配布システムであって、
推論エンジンが、進行中の音声対話における１つまたは複数の所定ポイントの間に呼び出されて、クライアントニーズの推論が、提供された音声アプリケーションのアクティブコールフロー内の所定ポイントの間に、対話に関連する既存のデータの分析に基づいて実施できるかどうかを判定し、推論が保証される場合には、どの推論ダイアログが実行され、かつコールフロー内に挿入されるかを決定することを特徴とするシステム。
【請求項２】
通信ネットワークがインターネットネットワークである、請求項１に記載のシステム。
【請求項３】
通信ネットワークがインターネットネットワークと電話ネットワークとの組合せである、請求項１に記載のシステム。
【請求項４】
推論エンジンが、音声アプリケーションサーバ内で維持されるアプリケーションロジックの一部である、請求項１に記載のシステム。
【請求項５】
少なくとも１つの音声ポータルが、電話サーバと組み合わされた対話音声応答システムである、請求項１に記載のシステム。
【請求項６】
少なくとも１つの音声ポータルが、インターネットにアクセスできるデータネットワークに接続されたコンピュータノードである、請求項１に記載のシステム。
【請求項７】
推論エンジンが、音声アプリケーションを使用する対話のコールフロー内の所定ポイントで呼び出される、請求項１に記載のシステム。
【請求項８】
推論エンジンが、推論を実行すべきかどうかを決定するために、ある発呼者について収集されたセッション情報および／または履歴データを使用する、請求項１に記載のシステム。
【請求項９】
特定の入力から汎用文法スクリプトを生成するように構成された汎用文法アダプタをさらに含み、前記汎用文法スクリプトは、サポートされている複数のスクリプト言語の任意の１つに変換可能であり、音声テキスト変換／テキスト音声変換エンジンの仕様パラメータと呼ばれる、請求項１に記載のシステム。
【請求項１０】
推論ダイアログが、個々のダイアログのマルチパート複合体である、請求項１に記載のシステム。
【請求項１１】
関連するデータが、発呼者回線識別、発呼者番号識別、および発呼者履歴データのうちの１つまたはそれらの組合せを含む、請求項１に記載のシステム。
【請求項１２】
関連するデータが、特定の推論を決定するために推論モデルと比較される統計値のために抽出される、請求項１に記載のシステム。
【請求項１３】
オントロジセットおよびセマンティックインデックスを含む推論モデルをさらに含む、請求項１に記載のシステム。
【請求項１４】
推論エンジンによって、セマンティックスのベースから音声ダイアログが生成される、請求項１に記載のシステム。
【請求項１５】
推論エンジンによって、対話の過程で複数回の推論が実施される、請求項１に記載のシステム。
【請求項１６】
一般的な記述言語を、テキスト音声変換エンジンで使用される特定のＸＭＬベースのスクリプト言語に変換するための中間記述言語に変換する、言語アダプタシステムであって、
一般的な記述言語を規定する第１の組の構成体と、
第１の組の構成体の選択された構成体を、第２の組の中間構成体の個別の構成体に結びつけるための文法アダプタと、
アダプタ出力を所望の特定のスクリプト言語に変換するための言語変換ユーティリティとを含むシステム。
【請求項１７】
言語変換ユーティリティが、アダプタに組み込まれた拡張可能なスタイルシート変換プログラムである、請求項１６に記載のシステム。
【請求項１８】
特定のスクリプト言語が、文法仕様言語（ＧＳＬ）または文法拡張可能マークアップ言語（ＧＲＸＭＬ）のどちらか一方である、請求項１６に記載のシステム。
【請求項１９】
アダプタシステムが、音声アプリケーションの手動作成の間に手動で操作される、請求項１６に記載のシステム。
【請求項２０】
アダプタシステムが、新しい音声アプリケーションダイアログの自動生成の間に自動的に実行される、請求項１６に記載のシステム。
【請求項２１】
音声アプリケーションおよび音声エンジンを使用する音声対話の間に、複数の使用可能なダイアログのうちのどのダイアログが実行されるかを決定する方法であって、
（ａ）実行される音声アプリケーション内に１つまたは複数の検出可能なシステムポイントを設定すること、
（ｂ）アプリケーションの実行および配布の過程で前記システムポイントを順次検出すること、
（ｃ）各検出に際し、配布されたばかりのアプリケーションの一部の性質に関連する任意の使用可能なデータにアクセスすること、
（ｄ）検出された任意の使用可能なデータを参照データモデルと比較すること、および
（ｅ）比較の結果に基づいて、使用可能なダイアログから１つまたは複数のダイアログを実行のために選択することを含む、方法。
【請求項２２】
（ａ）において、検出可能なシステムポイントが、音声アプリケーションのプリトランザクションモデルおよびポストトランザクションモデルに従って設定される、請求項２１に記載の方法。
【請求項２３】
（ｃ）において、データが、クライアントセッションデータ、クライアントダイアログデータ、またはクライアント履歴活動データのうちの１つまたはそれらの組合せを含む、請求項２１に記載の方法。
【請求項２４】
（ｄ）において、参照データモデルが、オントロジおよびセマンティックインデックスを含む、請求項２１に記載の方法。
【請求項２５】
（ｄ）において、参照データモデルが、特定のシステムポイントで検出することができるデータのデータタイプとコンテキストの以前の結果だと考えられる閾値を含む、請求項２４に記載の方法。
【請求項２６】
（ｄ）において、比較が、生データからの統計値の計算を含む、請求項２１に記載の方法。
【請求項２７】
（ｅ）において、比較結果が、所定の閾値の違反であり、ダイアログが、所定の閾値を音声アプリケーションの部分に適用したときの値のクラスまたは性質に基づいて選択される、請求項２１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音声アプリケーションソフトウェアシステムの分野にあり、詳細にはプラットフォームに依存しない方法で、自動音声トランザクションを実施するための方法および装置に関する。
【０００２】
本出願は、２００３年１１月１７日に出願された米国特許仮出願第６０／５２３０４２号の優先権を主張する。本発明は、また、米国特許出願第１０／６１３８５７号の一部継続出願としての優先権も主張する。米国特許出願第１０／６１３８５７号は、２００２年７月２日に出願された「Method  and  Apparatus  for  Improving  Voice  recognition  performance  in  a  voice  application  distribution  system」と題する、米国特許出願第１０／１９００８０号の一部継続出願であり、米国特許出願第１０／１９００８０号は、２００２年６月１４日に出願された「Method  for  Automated  Harvesting  of  Data  from  A  Web  site  using  a  Voice  Portal  System」と題する米国特許出願第１０／１７３３３３号の一部継続出願であり、さらに米国特許出願第１０／１７３３３３号は、米国特許仮出願第６０／３０２７３６号の優先権を主張するものである。本出願は、上記の各出願の優先権を主張するものであり、それらの開示の全体を参照により本明細書に組み込む。
【背景技術】
【０００３】
音声アプリケーションは、通信（一般に電話）環境において開発し、配布し、維持することが最も難しいアプリケーションの１つである。実行可能なアプリケーションを開発し配布するために必要な専門知識には、コンピュータ電話統合（ＣＴＩ）ハードウェアおよびソフトウェア、音声認識ソフトウェア、テキスト音声変換ソフトウェア、ならびに音声アプリケーションロジックにおける専門知識が含まれる。
【０００４】
比較的最近のＶＸＭＬ（音声拡張マークアップ言語）の出現により、音声ソリューションを開発するために必要な専門知識が、ある程度軽減された。ＶＸＭＬは、ソフトウェア開発者が基礎になる電話コンポーネントを構成することを必要とせずに、音声アプリケーションのアプリケーションロジックに集中することを可能にする言語である。一般に、開発された音声アプリケーションは、関連する電話システム上に常駐しその上で動作するＶＸＭＬインタプリタ上で動作し、ソリューションを提供する。
【０００５】
図１Ａ（従来技術）に示されるように、ＶＸＭＬ対応電話システムの代表的なアーキテクチャは、音声アプリケーションサーバ（１１０）およびＶＸＭＬ対応電話サーバ（１３０）を含む。ＶＸＭＬ対応ＩＶＲソリューションの開発および配布の代表的なステップについて、以下で図１Ａの要素を使用して簡単に説明する。
【０００６】
最初に、ＶＸＭＬをサポートするために、新しいアプリケーションデータベース（１１３）が生成されるか、または既存のデータベースが修正される。アプリケーションロジック１１２は、ワークフローに関して構成され、ＩＶＲシステムのルーティング動作を処理するように構成される。機能アプリケーションロジックの結果であるＶＸＭＬページは、指定された生成シーケンスに基づいて、ＶＸＭＬレンダリングエンジン（１１１）によって提供される。
【０００７】
次に、サーバ１３０に対する対応するＶＸＭＬページを含むオブジェクトファサード（object  facade）が生成され、ネットワーク（１２０）を介してサーバ１３０に送信される。ネットワークは、インターネット、イントラネット、またはイーサネット（登録商標）などあってもよい。ＶＸＭＬページは、設定ワークフローにしたがってサーバ１１０で表示することができるように、レンダリングエンジン１１１に統合される。
【０００８】
第３に、ＶＸＭＬ電話サーバ１３０は、サーバ１１０内のレンダリングエンジン１１１から特定のＶＸＭＬページを適切に取り出すことができるように構成される。サーバ１１０には、トリガイベントが生じたときに、サーバ１１０から適切なアウトバウンドコールが出されるように、トリガ機構が提供される。
【０００９】
ＶＸＭＬインタプリタ（１３１）、音声認識テキスト音声変換エンジン（１３２）、および電話ハードウェア／ソフトウェア（１３３）は、サーバ１３０内に提供され、かつサーバ機能を含む。従来技術では、ＶＸＭＬインタプリタ１３１に加えて電話ハードウェア／ソフトウェア１３０は、既製のＩＶＲ対応技術としてパッケージされている。しかし、全体システムの最も重要な機能は、おそらくアプリケーションサーバ１１０である。アプリケーションロジック（１１２）は、一般にＪａｖａ（登録商標）などのプログラミング言語で作成され、エンタープライズＪａｖａ（登録商標）Ｂｅａｎアーカイブとしてパッケージされる。必要なプレゼンテーションロジックは、レンダリングエンジン１１１によって処理され、ＪＳＰまたはＰＥＲＬで作成される。
【００１０】
拡張された音声アプリケーションシステムは、本発明者には知られており、本出願が優先権を主張する「Method  and  Apparatus  for  Development  and  Deployment  of  a  Voice  Software  Application  for  Distribution  to  one  or  more  Application  Consumers」と題する米国特許出願に開示されている。このシステムは、音声アプリケーションを格納し提供するために、データネットワークに接続された音声アプリケーションサーバを使用する。音声アプリケーションサーバは、よく知られたＰＳＴＮネットワークなどの通信ネットワークに接続された、ネットワーク通信サーバへのデータ接続を備える。通信サーバは、生成された音声アプリケーションを意図した受信者に送る。
【００１１】
コンピュータステーションは、システムの一部として提供され、データネットワークに接続され、音声アプリケーションサーバにアクセスすることができる。クライアントソフトウェアアプリケーションは、コンピュータステーション上で動作し、ユーザが、アプリケーションを生成しかつアプリケーションの状態を管理することを可能にする。このシステムでは、ユーザは、コンピュータステーション上で動作するクライアントソフトウェアを操作して、オブジェクトモデリングおよびリンキングによって音声アプリケーションを作成する。アプリケーションは、作成された後で、配布のためにアプリケーションサーバに格納される。ユーザは、意図した受信者に関して、スケジュール配布または繰返し配布を含み、配布されるアプリケーションの配布および状態を制御しかつ管理することができる。
【００１２】
一実施形態では、システムは、ソースデータとしてウェブベースのデータを使用して音声アプリケーションを開発し、通信ネットワークを介して１人または複数の受信者に配布するように構成される。拡張されたシステムは、ソフトウェアおよびネットワーク接続を介して、ネットワークサーバおよびその中で動作するウェブサイトにアクセスし、そのサイトからデータを引き出すことを可能にする音声アプリケーションサーバを有する。音声アプリケーションソフトウェアを実行するコンピュータステーションは、少なくとも音声アプリケーションサーバに制御アクセスを有し、さらにネットワークサーバおよびウェブサイトにもアクセスすることができる。コンピュータステーションのオペレータは、音声アプリケーションサーバが、データ音声レンダリングにおいて使用するためのテンプレートを生成しかつ提供する。この態様では、ウェブデータは、ウェブベースのデータソースから取り込むことができ、音声に変換して、音声アプリケーションにおけるダイアログとして配信することができる。
【００１３】
他の実施形態では、上述のシステムで、ダイアログ作成が実施される前にウェブベースデータを構成し、編集し、優先順位をつける方法が使用可能である。この方法は、ウェブベースのデータソースを元の構造の形で取り込むこと、取り込んだウェブベースのデータソースの論理構造およびコンテンツタイプを表すオブジェクトツリーを生成すること、生成されたオブジェクトツリーを所望の階層構造およびコンテンツに処理すること、ＶＸＭＬの形の音声アプリケーションテンプレートを作成してそのテンプレートを処理されたオブジェクトツリーに実装すること、およびテンプレートの制約に従って、ウェブベースデータソースにアクセスできる音声アプリケーションを作成することを含む。この方法は、音声アプリケーションの配布および実行状態の合理化、ならびに音声アプリケーション開発プロセスの単純化を可能にする。
【００１４】
上述のシステムのためにセキュリティ管理が提供される。プロトコルは、ウェブサーバおよびデータと、電話ネットワークを介してユーザ端に、またＸＭＬゲートウェイを介してデータソース端にアクセス可能な音声ポータルシステムとの間のトランザクションセキュリティを提供する。この管理には、ＸＭＬゲートウェイを介してウェブサーバと音声ポータルシステムの間に設定される、プライベート接続、仮想プライベートネットワーク、またはセキュアソケットレイヤのうちの１つが含まれる。ポータルと１つまたは複数のサーバとの間で実行されるトランザクションは、データネットワークのセキュアノード間で使用可能なセキュリティと同じセキュリティを享受する。一実施形態では、この管理はさらに、ポータルの出口およびエンドユーザの電話に分配された音声翻訳システムを含み、音声ダイアログは、ユーザ言語のダイアログではない不明瞭な言語に翻訳され、次いでユーザの電話でユーザ言語に再翻訳される。
【００１５】
音声アプリケーションダイアログトランザクションを可能にするためにテンプレートが使用されるシステムでは、適切な内容解釈と応答プロトコルのために、音声アプリケーションルールと音声認識データが調べられ、その結果として、音声ポータルを介して応答ダイアログとしてユーザに提示される合成音声は、その内容が適切になり、かつ望ましくは表現上のエラーがなくなる。したがって、データベースは、多様なビジネスシナリオに対応した多様な語彙をカバーする、非常に広範囲のスピーチを可能にする語彙を用いて最適化される。
【００１６】
本発明のさらに他の態様によれば、語彙認識は、クライアントパラメータによりアクティブな音声アプリケーションに合わせて調整される。この調整は、音声ポータルを介してデータソースにアクセスするユーザとの間で進行中の、アクティブな音声アプリケーションの使用に関連するテキスト音声および音声テキストレンダリングに関連する音声認識処理を制約するように構成された、語彙管理システムによって達成される。この拡張は、音声アプリケーションサーバおよび電話サーバに接続された語彙管理サーバ、ならびに音声認識ソフトウェアのための語彙確定および管理を可能にする管理サーバ上で動作する語彙管理ソフトウェアのインスタンスを含む。拡張された語彙管理機能の実施においては、語彙管理サーバにアクセスする管理者は、語彙管理ソフトウェアを使用して、管理者の指示により内容が異なる語彙セットをソースとする、目的データに関連した語彙の選択された部分に特有の一意の語彙セットまたはリストを作成する。
【００１７】
音声アプリケーション配布アーキテクチャ分野の技術者ならば、音声ポータルに接続し対話することを競う多くのユーザにより、場合によっては、ボトルネックが生成され、音声アプリケーションコンポーネントをウェブソースおよび他のデータソースに接続するデータ回線の能力に、重い負担がかかる可能性があることが理解されよう。この問題は、通常の多くの電話環境でよく見られるピーク使用期間に特に生じる可能性がある。本発明者は、上述の潜在的な回線使用問題を軽減するために、トラフィックの最適化に関するより多くの合理化が必要であることに気付いた。
【００１８】
本発明者が認識している音声アプリケーション配布システムの特定の機能強化では、先の段落で述べたトラフィック問題が取り扱われている。アプリケーションロジックは、静的および動的ルールに基づいて、また場合によっては（動的キャッシュでは）決定に際して統計解析結果を使用して、配布用の音声アプリケーションのどの部分（ダイアログ）を、アプリケーション受信端システムでキャッシュするかを決定するために提供される。このアプリケーションロジックは、シーケンシャルダイアログファイルおよびアプリケーションのルールに従って、音声アプリケーションを処理するためのプロセッサを使用する。ロジックコンポーネントは、プロセッサに接続され静的コンテンツを含むファイルを識別するための静的コンテンツオプティマイザ、およびプロセッサに接続され動的コンテンツを含むファイルを識別するための動的コンテンツオプティマイザを含む。これらのオプティマイザは、どの終端システム装置に、どのファイルをキャッシュすべきかを決定し、その決定に従ってファイルにタグを付け、配布されたアプリケーションとの消費者対話の間のローカルな取り出しのために、選択された終端システムキャッシュ装置にそれらのファイルを配布するための準備をする。
【００１９】
ローカルキャッシュ装置から音声アプリケーションのダイアログ部分を取り出すことができるので、音声アプリケーションサーバへのネットワーク接続に関する負荷を低減させることにより、音声ポータルでの応答時間を増加させる。しかし、トラフィック要件の低減以外に、テキスト音声認識および音声テキストレンダリングが、明瞭で正確であることも重要である。発呼者に配布される合成音声の正確さは、両端で動的に対話することができる成功した音声アプリケーションを作成するためのキーポイントになる。
【００２０】
音声アプリケーション配布アーキテクチャが、地域間共通の境界（cross  regional  boundary）や文化的な境界にまで広がるので、一般に話される用語や語句を処理する音声認識ルールを標準化する見通しは、ますます困難になってきた。例えば、同一言語におけるある用語の発音は、地域によって大幅に異なる。主要道路やハイウェイの表記や呼称など一般的な標識も、大きく異なることがある。音声アプリケーション対話が、大きな地理的領域に渡る非常に大きなアーキテクチャで実施される場合には、対処すべき語句や用語の変化の例が数多く存在することになる。
【００２１】
本発明者が認識しているさらに他のシステム拡張では、テキスト音声変換前処理を使用して、予め設定された制約に従って、ある程度発呼者に合わせ込まれた合成音声を提供する。この拡張システムは、ＶＸＭＬビュー生成およびその後の音声レンダリングのために、テキスト文字列を前処理することができる。このシステムは、前処理ロジックからアクセス可能な、テキスト音声変換前処理ロジックおよびソフトウェアテーブルを備える。このテーブルは、１つまたは複数のテキストエンティティに関連するテキストダイアログオプションを提供するように構成される。
【００２２】
ルールベースが提供され、前処理ロジックからアクセス可能である。ルールベースは、特定のダイアログ部分を照合するために使用されるダイアログ選択制約を提供するように構成され、照合された特定のダイアログ部分は、次いでテキスト文字列に注釈を付けるために使用される。ダイアログオプションおよびテキストエンティティは、アクセス可能なデータストアに格納される。好ましい実施形態では、前処理ロジックは、配布された音声アプリケーションとのクライアント対話の間にソフトウェアテーブルにアクセスし、単一のテキストエンティティに関連する複数のダイアログオプションから特定のダイアログオプションを選択し、選択されたオプションを、ＶＸＭＬページレンダリング処理に挿入する。この選択は、１つまたは複数の提供された制約のリターンに従ってなされる。
【００２３】
この拡張システムは、予め設定された制約に応じて、特定のグループの発呼者に音声ダイアログのパーソナル化を提供し、このパーソナル化により、様々な産業特有の問題、および社会的、地理的、文化的な問題をカバーすることができるが、システムは、まだ大部分はロボット的であり、個別の態度や挙動には対応しない。音声アプリケーションと対話する発呼者の各瞬間の態度、雰囲気、および挙動が、対話の時点で理解される場合は、それらは一般に、顧客満足度、企業売上高、および対話プロセスの効率を向上するために活用できることに本発明者は気付いた。
【００２４】
本発明者は、挙動適応エンジン（behavioral  adaptation  engine）について認識しているが、それは音声アプリケーション作成および配布システムと一体化されたものである。この適応エンジンは、データに添付されたオーディオファイルなど、ＸＭＬベースのクライアント対話データを受信するための少なくとも１つのデータ入力ポート、外部データシステムおよびモジュールにデータを送信しそこからデータを受信するための少なくとも１つのデータポート、受信したデータを処理するためのＸＭＬリーダ、音声プレーヤ、アナライザなどのロジック処理コンポーネント、ならびに１つまたは複数の制約に対する結果データを処理するための決定ロジックコンポーネントを備えている。このエンジンは、提供される音声アプリケーションとのクライアント対話から、ダイアログなどのクライアントデータを実時間でインターセプトし、受信データおよび添付されている場合にはオーディオファイルの音声特性を処理して挙動パターンを求め、次いでエンジンは、その結果および１つまたは複数の有効な制約に従って、対話の間にクライアントに返すための１つまたは１組の可能な企業応答を識別する。
【００２５】
前の段落で説明した拡張されたシステムは、特定の雰囲気状態の検出に基づいて応答を動的に選択し、それに従ってメニューまたは応答オプションを再構成することができる。挙動適応エンジンは、一群の可能なダイアログの中から、セッションの間にどの適切な応答ダイアログを実行するかを、そのセッションの間にクライアントによってなされた音声および選択についての分析に基づいて決定する機能を有する。
【００２６】
本発明者が認識しているより拡張された音声アプリケーションシステムに加えて、従来技術のＶＸＭＬ対応音声アプリケーション配布システムがいくつか存在する。これらのシステムは、特定の音声システムだけで使用することができる音声アプリケーションを作成するための様々な独自開発の文法マークアップ言語またはスクリプト言語を使用し、次いで、標準のＶＸＭＬまたはＣＣＸＭＬとしてスクリプトを提供し、ポータル（クライアントアクセス）システムに配布することができる。独自開発の文法言語は、アプリケーションサイド（アプリケーション言語）でＶＸＭＬレンダリングエンジンへの入力として使用されることができ、出力はＷ３Ｃ標準ＶＸＭＬである。この出力は、発呼者の対話ポイントで使用可能である。次に、発呼者応答は、ＶＸＭＬとして独自開発システムに送り返されることができ、アプリケーションサーバサイトで、解釈およびダイアログサービスのためにアプリケーション言語に翻訳されることができる。
【００２７】
上述の対話性についての一例を示すと、Ｎｕａｎｃｅ（商標）社が所有するテキスト音声変換および音声テキスト変換が可能な音声合成エンジンは、Ｔｅｌｌｍｅ（商標）システムとして知られている音声アプリケーション配布システムに統合されている。Ｎｕａｎｃｅ（商標）は、音声アプリケーションを作成するためのＧＳＬ（Grammar  Specification  language）として知られている専用スクリプト言語を提供する。ＧＳＬは、ＶＸＭＬに変換され、ＶＸＭＬは、ＶＸＭＬ対応ウェブベースポータルまたは電話ＩＶＲシステムで、発呼者と対話する音声合成エンジンによって解釈される。
【００２８】
最近になって、アドレス  ｈｔｔｐ：／／ｗｗｗ．ｗ３ｃ．ｏｒｇ／によって参照されるＷ３Ｃ（Worldwide  Web）は、ＧＲＸＭＬ（grammar  extensible  mark−up  language）を開発した。ＧＲＸＭＬは、ＶＸＭＬ、および場合によってはＣＣＸＭＬをサポートする、Ｎｕａｎｃｅ（商標）、ＳｐｅｅｃｈＷｏｒｋｓ（商標）、その他の音声エンジン技術とともに使用することができる。ＣＣＸＭＬは、ＶＸＭＬによってサポートされる機能よりも、より統合された電話通話制御機能、例えばアウトバウンドコールなどを提供する。
【００２９】
図３３は、様々なコアＶＭＸＬレンダリングエンジンに入力される、様々なスクリプト言語間の従来技術における関係の概要３３００を示したものである。ＧＳＬ３３０１は、上述のようにＮｕａｎｃｅ（商標）エンジン３３０２への入力として使用される。ＧＲＸＭＬ言語３３０３は、Ｎｕａｎｃｅ（商標）エンジン、およびＳｐｅｅｃｈＷｏｒｋｓ（商標）エンジン３３０４によってサポートされる。他の既存の、または新しく開発されたＸＭＬベースのスクリプト言語３３０６は、他の専用エンジン３３０５などへの入力として使用される。
【００３０】
専用のＶＸＭＬ対応システムによって使用される様々なアプリケーション言語に関して、準標準的なＧＲＸＭＬを使用する相互運用性もいくつか存在するが、多くのシステムではＧＲＸＭＬを使用することはできない。ＧＲＸＭＬは、広く認められた大規模で最もよく知られたシステムとだけ両立することができる。顧客サイトは、複数の異なる専用システムを配備することができるが、ＧＲＸＭＬがサポートされておらず、対話の間に、あるシステムから他のシステムに移行しなければならないこともある。一例として、複数の音声アプリケーション配布サービスおよびアーキテクチャと契約している企業が考えられる。この点に関し、顧客が使用している特定のエンジンをサポートする、新しいスクリプトを作成しなければならないという点で、ある程度の困難が存在する。
【００３１】
上述の問題に加えて、クライアントシステム間の音声アプリケーション駆動セッションに関しては、明白なさらに多くの制限が存在する。音声合成は、トランザクションを完成するために通信しなければならない主題の一部を表す、いくつかの単一音声コンポーネントを利用する傾向がある。例えば、市、州、および国は、あるトランザクションを完成するために提供しなければならない位置情報の３つのコンポーネントを表す。従来技術のアプリケーションシステムでは一般に、３つの個別のプロンプト／応答動作を用いてこれらのコンポーネントを個別に処理する。本発明者が認識している挙動適応エンジンでは、クライアントが、音声アプリケーションの特定の標準プロンプトをスキップできるようにすることによって、ある程度の合理化を提供することができるが、クライアントと音声アプリケーションの間の対話をさらに合理化するために、より多くの拡張が必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【００３２】
明らかに必要とされているのは、音声アプリケーションと対話する際にクライアントの目的に関する推論を可能にする方法および装置、ならびに複数のエンドシステムをアプリケーションサーバシステムに接続することを可能にする、プラットフォームおよびシステムに依存しないスクリプト言語である。このような機能を有するシステムにより、上述の制限を低減または除去することができる。
【課題を解決するための手段】
【００３３】
音声アプリケーション作成および配布システムが提供される。このシステムは、音声アプリケーションを作成し、かつ通信ネットワークを介してクライアントに提供する音声アプリケーションサーバと、通信ネットワークにアクセスすることができ、音声アプリケーションとのクライアント対話を容易にする少なくとも１つの音声ポータルノードと、アプリケーションサーバから実行可能な推論エンジンとを備える。好ましい実施形態では、推論エンジンは、進行中の音声対話の１つまたは複数の所定のポイントの間に、呼び出されて、クライアントのニーズの推論が、提供される音声アプリケーションのアクティブなコールフロー内の所定のポイントの間に、対話に関連する既存のデータの分析に基づいて実施できるかどうかを判定し、推論が保証される場合は、どの推論ダイアログを実行され、かつコールフローに挿入されるかを決定する。
【００３４】
一実施形態では、通信ネットワークは、インターネットネットワークである。他の実施形態では、通信ネットワークは、インターネットと電話ネットワークの組合せである。一実施形態では、推論エンジンは、音声アプリケーションサーバで維持されるアプリケーションロジックの一部である。
【００３５】
一実施形態では、少なくとも１つの音声ポータルは、電話サーバと組み合わされた対話音声応答システムである。他の実施形態では、少なくとも１つの音声ポータルは、インターネットにアクセスできるデータネットワークに接続されたコンピュータ化されたノードである。
【００３６】
好ましい態様では、推論エンジンは、音声アプリケーションを使用する対話のコールフロー内の所定のポイントで呼び出される。この実施形態では、推論エンジンは、セッション情報および／または発呼者に関して収集された履歴データを使用して、推論を実行すべきかどうかを判定する。
【００３７】
本発明の他の実施形態では、このシステムは、さらに、特定の入力から汎用文法スクリプトを生成するように構成された汎用文法アダプタ（universal  grammar  adapter）を含む。このスクリプトは、サポートされている複数のスクリプト言語の任意の１つに変換可能であり、音声テキスト／テキスト音声エンジンの仕様パラメータと呼ばれる。一実施形態では、推論ダイアログは、個別のダイアログのマルチパート複合体（multi  part  composites）である。一実施形態ではまた、関連するデータは、発呼者回線識別、発呼者番号識別、および発呼者履歴データのうちの１つまたはその組合せを含む。一実施形態では、関連するデータは、推論モデルと比較され特定の推論を決定するための統計用に抽出される。
【００３８】
本発明の他の態様では、このセクションの最初のパラグラフで説明したシステムはさらに、オントロジセットおよびセマンティックインデックスを含む推論モデルを含む。この実施形態では、推論エンジンは、セマンティックスのベースから、音声ダイアログを生成させる。好ましいアプリケーションでは、推論エンジンは、対話の過程で複数回の推論を実施させる。
【００３９】
本発明の他の態様によれば、言語アダプタシステムは、一般的な記述言語を、テキスト音声変換エンジンで使用される特定のＸＭＬベースのスクリプト言語に変換するための中間記述言語に変換するために提供される。一実施形態では、アダプタシステムは、一般的な記述言語を規定する第１の組の構成体（construct）と、第１の組の構成体の選択された構成体を、第２の組の中間構成体の個々の構成体に結びつけるための文法アダプタと、アダプタ出力を所望の特定のスクリプト言語に変換する言語変換ユーティリティとを含む。
【００４０】
一態様では、言語変換ユーティリティは、アダプタに統合された拡張可能なスタイルシート変換プログラム（extensible  style  sheet  transformation  program）である。一態様ではまた、特定のスクリプト言語は、文法仕様言語（ＧＳＬ）（grammar  specification  language）または文法拡張可能マークアップ言語（ＧＲＸＭＬ）（grammar  extensible  mark−up  language）のどちらか一方である。
【００４１】
一実施形態では、アダプタシステムは、音声アプリケーションの手動作成の間に手動で操作される。他の実施形態では、アダプタシステムは、新しい音声アプリケーションダイアログの自動生成の間に自動的に実行される。
【００４２】
本発明のさらに他の態様によれば、音声アプリケーションおよび音声エンジンを使用する音声対話の間に、複数の使用可能なダイアログのうちのどのダイアログが実行されるかを決定する方法が提供される。この方法は、（ａ）実行される音声アプリケーションの内部に１つまたは複数の検出可能なシステムポイントを設定すること、（ｂ）アプリケーションの実行および配布の過程で前記システムポイントを順次検出すること、（ｃ）各検出に際し、配布されたばかりのアプリケーションの一部の性質に関連する任意の使用可能なデータにアクセスすること、（ｄ）検出された任意の使用可能なデータを参照データモデルと比較すること、および（ｅ）比較の結果に基づいて、使用可能なダイアログから実行のための１つまたは複数のダイアログを選択することを含む。
【００４３】
好ましいアプリケーションでは、（ａ）の検出可能なシステムポイントは、音声アプリケーションのプリトランザクションおよびポストトランザクションモデルに従って設定される。このアプリケーションにおいて、（ｃ）のデータは、クライアントセッションデータ、クライアントダイアログデータ、またはクライアント履歴活動データのうちの１つまたはそれらの組合せを含む。好ましいアプリケーションにおいて、（ｄ）の参照データモデルは、オントロジおよびセマンテックインデクスを含む。
【００４４】
一態様では、（ｄ）の参照データモデルは、特定のシステムポイントで検出することができるデータのデータ型とコンテキストの以前の結果であると考えられる閾値を含む。他の態様では、（ｄ）の比較には、生データからの統計値の計算を含めることができる。他の態様では、（ｅ）の比較結果は、所定の閾値の違反（breach）であり、ダイアログは、その閾値を音声アプリケーションのその部分に適用したときの値のクラスまたは性質に基づいて選択される。
【発明を実施するための最良の形態】
【００４５】
本発明の好ましい実施形態により、本発明者は、本明細書で、有効な方式で、サポートされた通信環境におけるＩＶＲおよび他の対話音声ソリューションのインバウンドまたはアウトバウンド配布を可能にする、オブジェクト指向方法による実時間の動的または静的音声アプリケーションを開発しかつ配布するための新規のシステムを教示する。
【００４６】
図１Ａは、従来技術によるＶＸＭＬ対応ＩＶＲ開発および配布環境の基本的なアーキテクチャを示すブロック図である。背景技術のセクションで説明したように、この例の従来技術のアーキテクチャについては、本発明者は承知しており使用可能である。例示の環境、この場合は電話環境において音声アプリケーションを開発し配布するためには、当技術分野における非常に高いレベルの技術が必要である。この従来技術の例における各要素については、本明細書の背景技術の部分ですでに説明済みであり、ここでは説明しないものとする。
【００４７】
この簡略化されたシナリオにおいて、音声アプリケーションサーバ１１０は、データベースまたは他のリソースのコンテンツにアクセスするためにデータベース／リソースアダプタ１１３を使用する。ＶＸＭＬスクリプト、ビジネスルール、および基礎になる電話ロジックを含むアプリケーションロジック１１２は、単一のアプリケーションが提供できるようになる前に、レンダリングエンジン１１１によって注意深く開発されかつテストされなければならない。音声アプリケーションが完成しサーバ１１０から提供可能になった後で、それらは、データネットワーク１２０を介して電話サーバ１３０に配布されることができる。電話サーバ１３０では、インタプリタ１３１およびテキスト音声変換エンジン１３２を使用して、電話ソフトウェアおよびハードウェア１３３が使用可能または再生可能な形式に、音声アプリケーションを表現して配布する。アプリケーションは、一般的なネットワーク１３４を介して、この図で装置１３５として示されている受信装置、電話などからアクセス可能である。一般的なネットワーク１３４は、この場合は、一般に、電話交換機（図示せず）を介して電話サーバを消費者（装置１３５）にリンクする公衆交換電話網（ＰＳＴＮ）である。
【００４８】
この従来技術の例に対する本発明の各実施形態における改良は、開発および配布の問題に関する、また双方向の対話ダイアログの応答機能およびオプションについての全体的な拡張に関する、アプリケーションサーバ１１０の機能に注目しかつ焦点を絞るものである。最新のアーキテクチャと見なされる既存のアーキテクチャについての説明を使用して、本発明者は、ここで、図１Ａの従来技術の例には示されていないが、図１Ｂによって示された新規のバージョンの例には示されている、追加のコンポーネントについて説明する。
【００４９】
図１Ｂは、本発明の一実施形態を示すように拡張された、図１Ａの基本アーキテクチャを示すブロック図である。図１Ａの従来技術例の要素であって、図１Ｂにも示されている要素については、それらの元の要素番号を維持し、ここでは説明しない。参照するために、音声アプリケーションを開発するエンティティ（人物）を、本明細書では以下で製作者または開発者と呼ぶものとする。
【００５０】
本発明の一実施形態による、音声アプリケーションの開発者または製作者は、この図でステーション１４０として示されるリモートのコンピュータワークステーションから操作することが好ましい。ステーション１４０は、本質的にネットワーク接続されたコンピュータステーションである。ステーション１４０は、アプリケーションサーバ１１０を収容する物理ドメイン内部に収容することができる。他の実施形態では、ステーション１４０およびアプリケーションサーバ１１０は、同一の機械内に存在させることができる。さらに他の実施形態では、開発者は、自身のホームオフィス、または任意の無線通信可能な場所など任意のネットワークアクセス可能な場所から、ステーション１４０を操作することができる。
【００５１】
ステーション１４０は、クライアントソフトウェアツール（ＣＬ）１４１を備えており、このソフトウェアツールは、開発者が、音声アプリケーションを作成し、かつそれをサーバ１１０、１３０および受信装置１３５によって示される一般のシステム全体に配布することが可能になるように構成される。この例では、ＣＬ１４１は、ウェブブラウザアプリケーションなどの、またはそれと一体化されたウェブインタフェースアプリケーションであるが、代わりに、他のネットワーク状況を適用することも可能である。ＣＬ１４１は、開発者が、本発明の実施形態による機能拡張を実現するために必要なソフトウェアツールを含む。ステーション１４０は、（インターネット、イーサネット（登録商標）、イントラネットなどの）データネットワーク上で、かつ／または電話ネットワーク１３４の内部で維持される音声ポータル１４３に接続される。この例では、ポータル１４３は、論理的に両方のネットワークに示されている。音声ポータル１４３は、開発者または音声アプリケーションの消費者が、選択された音声アプリケーション上での機能操作（アクセス、モニタ、修正など）を呼び出しかつ実施することができるように構成される。
【００５２】
アプリケーションサーバ１１０内部には、既存のコンポーネント１１１〜１１３と連動して、本発明の実施形態による動的音声アプリケーション開発および配布を提供するように構成された、音声アプリケーション開発サーバ１４２のインスタンスが存在する。
【００５３】
ポータル１４３は、ネットワーク接続を介してステーション１４０から、またネットワークブリッジを経由し電話ネットワーク１３４を介して音声アプリケーション消費者からアクセス可能である。一例では、ポータル１４３は、アプリケーションサーバ１１０の一部として維持される。ポータル１４３は、消費者のためのアクセスポイントであることに加えて、主に開発者のインタフェースサーバとして構成される。ポータル１４３は、ＣＬ１４１に対するサーバインスタンスとして構成されたＳＷインスタンス１４４によって有効にされる。電話実施形態では、ポータル１４３は、対話型音声応答（ＩＶＲ）ユニットでもよい。
【００５４】
好ましい実施形態では、音声アプリケーションの製作者または開発者は、「ウェブインタフェース」としてリモートステーション１４０を使用し、ポータル１４３およびデータネットワーク１２０を介してアプリケーションサーバ１１０にアクセスし、最初に接続先リストを作成する。代替実施形態では、ステーション１４０は、ネットワークインタフェースを介してアプリケーションサーバ１１０に直接にアクセスすることができる。連絡先とは、生成された音声アプリケーションの消費者などのことである。ＣＬ１４１は、アプリケーションサーバ１１０から起動され、かつサーバ１３０によって配布される、完成された音声アプリケーションを、設計し、修正し、インスタンス化し、かつ実行するために必要なすべての対話インタフェースを、要求に応じ必要な順に表示する。
【００５５】
本発明のソフトウェアは、開発者が複雑なコーディング操作を実施することを必要とせずに、音声アプリケーションを、パラメータとしてビジネスおよび電話（または他の通信による配布／アクセスシステム）ルールを備えた１組のダイアログオブジェクトとしてモデル化することを可能にする。ダイアログテンプレートは、ダイアログの状態をモデル化するために提供される。ダイアログテンプレートは、実際の音声ダイアログを作成し、そのダイアログの音声アプリケーション消費者(受信者)を指定し、音声アプリケーション消費者からの応答を取り込み、かつ消費者応答のシステム解釈に基づいてあらゆるフォローアップ動作を実施する。ダイアログは、再利用可能なコンポーネントであり、新しいダイログまたは既存の(格納された)ダイアログにリンクさせることができる。音声アプリケーションは、音声アプリケーション製作者によって規定された１組のビジネスルールによって、相互リンクされた１組のダイアログである。音声アプリケーションは、完成された後で、サーバ１１０によって配布され、最終的には、電話サーバ１３０を介して許可された相手（装置１３５）からアクセス可能になる。
【００５６】
好ましい実施形態では、音声アプリケーションは、ＶＸＭＬ対応電話サーバ１３０上で動作するようにＶＸＭＬの形式をとる。この処理は、ＶＸＭＬレンダリングエンジン１１１によって有効になる。エンジン１１１は、直接サーバ１３０と対話して、対象となる音声アプリケーションを配置し、そのアプリケーションの音声アプリケーションロジックを取り出し、ＶＸＭＬの形のプレゼンテーションを動的に作成し、それを処理と配布のためにサーバ１３０に転送する。インタプリタ１３１が、ＶＸＭＬプレゼンテーションを解釈した後で、それは、対話ダイアログ（この場合はＩＶＲダイアログ）の形で装置１３５に送信されるか、または装置１３５からアクセス可能になる。装置１３５からの応答はいずれも、同じ経路を辿ってアプリケーションサーバ１１０に返され、エンジン１１１によって解釈される。次に、サーバ１１０は、アダプタ１１３を介してアクセス可能なデータベースから音声アプリケーションプロファイルを取り出し、実行すべき次のビジネスルールをローカルに決定する。その決定に基づいて、そのルールに関連する対応した動作をとる。次に、（必要な場合には）次のＶＸＭＬプレゼンテーションが、レンダリングエンジン１１１に転送され、レンダリングエンジン１１１は、サーバ１３０で解釈し、処理し、かつ配布するための次のＶＸＭＬページを順に動的に生成する。ＶＸＭＬ対応電話サーバ（１３０）と音声アプリケーションサーバ（１１０）との間のこの双方向対話は、ＶＸＭＬダイアログの自動化されたロジックシーケンスの形で、音声アプリケーションが最終的に終了状態に到達するまで続けられる。
【００５７】
音声アプリケーション（１つまたは複数のダイアログの組）は、アウトバウンドまたはインバウンド方式で消費者（対象顧客）に配布されることができる。インバウンド音声アプリケーションでは、音声アプリケーションの消費者は、音声ポータル１４３を呼び出して、サーバ１３０から提供されるインバウンド音声アプリケーションにアクセスする。音声ポータルは、電話番号に直接、あるいは中央電話番号に対する内線番号としてマッピングされることができる。好ましい一実施形態では、音声ポータルは、コミュニティフォーラムとしても動作する。その場合、音声アプリケーション製作者は、アクセスし易いようにその音声アプリケーションをグループに提供し、音声アプリケーションのリンク、レポート、およびテキスト音声変換録音などの運営上の活動を実施することができる。
【００５８】
アウトバウンド音声アプリケーションについては、２つのサブタイプが存在する。すなわち、オンデマンドアウトバウンドアプリケーションとスケジュールアウトバウンドアプリケーションである。オンデマンドアウトバウンドでは、アプリケーションサーバ１１０は、音声アプリケーション製作者が、その音声アプリケーションに関するアウトバウンドコマンドを発行したとき直ちに、アウトバウンドコールを生成する。アウトバウンドコールは、対象顧客に対してなされ、そのコールの受信に際して、サーバ１３０から音声アプリケーションが起動される。スケジュールアウトバウンドアプリケーションでは、製作者が指定した日付および時間になると、スケジュールサーバ（サーバ１１０内には示されていない）が、音声アプリケーションを起動する。好ましい実施形態では、オンデマンドおよびスケジュールアウトバウンドアプリケーション配布機能はどちらも、ユニキャスト、マルチキャスト、およびブロードキャスト配信方式をサポートする。
【００５９】
上述のように、アプリケーションサーバ１１０によって作成される音声アプリケーションは、１つまたは複数のダイアログで構成される。各ダイアログのコンテンツは、静的であっても動的であってもよい。静的コンテンツは、音声アプリケーション製作者から供給されるコンテンツである。製作者は、音声アプリケーションが作成されたときにコンテンツを作成する。動的コンテンツは、サードパーティのデータソースから供給される。
【００６０】
好ましい実施形態では、開発者ツールは、対話的ダイアログ設計パネル（後で詳述する）を含み、製作者は、ＸＭＬ（extensible  Markup  Language）の形の参照リンクを、ダイアログ記述または応答フィールドに入力する。ダイアログ応答が、実行されかつアプリケーションサーバ１１０によって解釈されたとき、参照リンクは、リソースアダプタ１１３に登録されたリソースアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出す。ＡＰＩは、実時間で送られ、要求されたデータを取り出し、かつ返されたデータを既存のダイアログに統合する。その結果、生成された後続のＶＸＭＬページは、それに組み込まれた動的データを備えることになる。
【００６１】
本発明の１つの目的は、アプリケーション開発者が指定したデータソース要件にそれ自体を自動的に適合させる、高度に動的な実時間ＩＶＲシステムである。本発明の他の目的は、ＶＸＭＬまたは他の任意のプログラミング技術に関する事前知識をまったく必要とせずに、音声アプリケーションの迅速な開発と配布を可能にすることである。本発明の他の目的は、一般的な音声アプリケーション製作サイクルを短縮し、大幅に製作コストを低減することである。
【００６２】
図２は、本発明の一実施形態による、ＶＸＭＬ音声アプリケーション用の音声アプリケーションシェルまたはコンテナを作成するためのステップを示す処理フロー図である。シンクライアントとして知られるクライアントアプリケーション、例えば図１ｂに関連して説明したステーション１４０上のＣＬ１４１などを使用する開発者は、音声アプリケーションシェルまたは音声アプリケーションコンテナを作成する。ステップ２０１で、開発者は、ログインページでシステムにログインする。ステップ２０２で、開発者は、アプリケーション消費者の連絡先リストを作成する。一般に、ステップ２０２の前に、挨拶または歓迎のページが表示される。アプリケーション消費者は、音声アプリケーションにアクセスし、かつそれと対話する１つまたは複数のエンティティの顧客である。後に呼出しルーティングロジックが必要になる場合は、音声アプリケーション作成の間に、すべての意図した連絡先が使用可能になるように、連絡先リストが最初に作成される。連絡先リストは、複数の連絡先の場合には、製作者が個別に入力するか、あるいはＭｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ（商標）またはおそらくはＰＤＡ（商標）オーガナイザなど、何らかのオーガナイザ／プランナソフトウェアから設定リストとしてインポートされることができる。
【００６３】
本発明の一実施形態では、連絡先リストは、提供されるコネクタ（図示せず）によってアクセスされる外部装置に配置されることができる。提供されるコネクタは、適切に構成され、かつリストにアクセスしかつ検索するように構成される。例えば、このアプローチは、大規模な既存の顧客データベースが使用される場合になどに用いることができる。コピーを作成するのではなく、必要なデータは、オリジナルから抽出され、かつアプリケーションに提供される。
【００６４】
ステップ２０３で、音声アプリケーションヘッダが設定される。音声アプリケーションヘッダは、単なるアプリケーションのタイトルフィールドである。このフィールドは、アプリケーションの名前およびアプリケーションの説明を含む。ステップ２０４で、開発者は、音声アプリケーションにインバウンド状態またはアウトバウンド状態のどちらかを割り当てる。アウトバウンドアプリケーションは、アウトバウンドコールによって配布されるが、一方消費者は、インバウンド音声アプリケーションにアクセスする。
【００６５】
インバウンドアプリケーションの場合は、ステップ２０５で、システムは、インバウンド通信のためのデフォルトの受信者を設定する。ステップ２０６で、開発者は、構成されたリストからダイアログを選択する。この例では、ダイアログが、すでに作成されているものと想定している。ステップ２０７で、開発者は、ダイアログを実行し、そのダイアログは、自動的に配布される。
【００６６】
ステップ２０４で、アウトバウンド指定の場合は、開発者は、ステップ２０８で起動タイプを選択する。起動タイプは、オンデマンドタイプかまたはスケジュールタイプとすることができる。ステップ２０８で、開発者によってなされた選択がスケジュールの場合は、ステップ２０９で、開発者は、起動のための適切な時間および日付パラメータのすべて、例えば同一アプリケーションの繰り返し起動のためのパラメータなどを入力する。ステップ２０８で、アプリケーション起動にオンデマンドが選択された場合は、ステップ２１０で、開発者は、ステップ２０２で作成された連絡先リストから１つまたは複数の連絡先を選択する。ここで、ステップ２１０はまた、スケジュール起動の場合にも、ステップ２０９の後で開発者によって実施されることに留意されたい。ステップ２０７で、ダイアログが作成される。このステップで、対話が意図されている音声アプリケーションのための起こり得るダイアログ応答のリストを作成し、使用に備えて格納することもできる。
【００６７】
一般的なシーケンスでは、開発者は、音声アプリケーションを作成し、そのアプリケーションをバックエンドのデータソース、または必要に応じて任意のサードパーティリソースと統合し、その音声アプリケーションを配布する。次いで、アプリケーション消費者は、音声アプリケーションを使用する。システムはオプションで、必要な場合には、さらなる対話のために、音声アプリケーションによって収集された任意の消費者フィードバックを分析する。この例のステップは、すでに配置されている「ビルディングブロック」から、音声アプリケーションを生成しかつ起動することに関係している。
【００６８】
図３は、本発明の一実施形態による単純な音声アプリケーションコンテナ３００を示すブロック図である。アプリケーションコンテナ３００は、論理コンテナまたは「音声アプリケーションオブジェクト」３００である。シェルとも呼ばれるコンテナ３００は、上記図２の処理の起こり得る結果として論理的に示されている。コンテナ３００は、この例ではダイアログ１〜４と名付けられ、この図ではダイアログ３０１ａ〜ｎとして示された１つまたは複数のダイアログ状態を含む。ダイアログ３０１ａ〜ｎは、オブジェクトであり、したがってコンテナ３００は、１組のダイアログオブジェクト３０１ａ〜ｎからなる論理グループである。
【００６９】
ダイアログオブジェクト３０１ａ〜ｎの表示された組は、この例では、ルール１〜４と名付けられたビジネスルールによってリンクされている。ルール１〜４は、開発者によって規定されたルールオブジェクトである。ここで、本発明の趣旨および範囲を逸脱することなく、コンテナオブジェクト３００を構成する、より多くのまたはより少ない数のダイアログオブジェクト３０１ａ〜ｎ、およびリンクされたビジネスルールオブジェクト１〜４が存在してもよいことに留意されたい。本発明者は、４つの各エンティティを例示しているが、本発明を説明する目的にはこの表現で十分であると考える。
【００７０】
表示されたオブジェクトに加えて、音声アプリケーションシェル３００は、複数の設定オプションを含む。この例では、基本的な設定オプションは、参照用にテーブル化されており、３つのリストされた設定オプションを示す要素番号３０５ａ〜ｃが付与されている。テーブルを上から下まで読み込むと、最初の設定である起動タイプ（３０５ａ）は、通信システム中に音声アプリケーション３００のための最初のエントリポイントを規定する。図２のステップ２０４に関して上述したように、起動タイプ３０５ａの選択は、インバウンドまたはアウトバウンドである。代替実施形態では、起動タイプは、サードパーティによって規定されることが可能であり、インバウンドまたはアウトバウンド以外の他のパターンで規定されることができる。
【００７１】
アウトバウンド起動指定は、音声アプリケーションを１人または複数の受信者（顧客）に結びつける。受信者は、やはり図２（ステップ２０２）に関して上述の連絡先リストまたは配布リストによって表される単一または一群の連絡先であってもよい。この場合に、アウトバウンド音声アプリケーションが起動されると、それは、音声アプリケーションのアウトバウンド連絡先フィールド（図示せず）に指定された受信者に配信される。指定されたすべての受信者は、アウトバウンド音声アプリケーションのコピーを受信し、（許可されている場合には）音声アプリケーションダイアログ、および特定のアプリケーションで使用されている場合には、対応するバックエンドデータリソースと対話する均等な機会を有する。
【００７２】
起動タイプ３０５ａにインバウンド音声アプリケーションが指定されている場合は、システムは、アプリケーションにスタンバイ準備モードをとるように指示する。指定された音声アプリケーション消費者が、実際に音声アプリケーションへのアクセスを要求したときに、アプリケーションは起動される。代表的なコールセンタのＩＶＲシステムは、このタイプのインバウンドアプリケーションを採用する。
【００７３】
起動時間設定（３０５ｂ）は、音声アプリケーション起動タイプ設定３０５ａが、アウトバウンドに設定されている場合にだけ、オプションとして可能になる。起動時間設定は、新規のスケジュールエンジンに指示するように設定される。このスケジュールエンジンは、図１Ｂに関連して説明したアプリケーションサーバ機能の一部だと見なすことができる。スケジューリングエンジンは、音声アプリケーションを指定された受信者にいつ配布するのかについてのパラメータを制御する。時間設定は、オンデマンド、スケジュール起動、または任意の第三者規定のパターンを反映することができる。
【００７４】
オンデマンドでは、開発者に音声アプリケーションの起動時間についての全制御が与えられる。オンデマンド機能ではまた、任意の第三者システムが、音声アプリケーションを起動するためのトリガイベントを発行することもできる。ここで、第三者制御の場合は、音声アプリケーション対話が、複数の通信システムおよび／またはネットワークの境界を越えることができることに留意されたい。
【００７５】
特性設定３０５ｃは、基本的に、音声アプリケーションが一般にどのように動作しなければならないかを規定する。３０５ｃの設定に関する考えられる状態オプションは、公開（public）、永続（persistent）、共用可能（sharable）である。公開状態の設定は、最小限の権限を有する全ての消費者が、アプリケーションにアクセスできるように、音声アプリケーションが、音声ポータルドメイン内の誰からもアクセス可能である必要があることを指示する。特性３０５ｃについての永続状態の設定は、何人の消費者がアプリケーションへのアクセスを試みているかにかかわらず、音声アプリケーションのただ１つのコピーだけが常にアクティブであることを保証する。このようなシナリオの例には、タスク割振り音声アプリケーションの例がある。例えば、タスク割り振りシナリオでは、ユーザが、アプリケーションにアクセスするために使用できるいくつかのタイムスロットだけが存在する。タスクが、一群の連絡先、例えばスケジュールチャットセッションを導くカスタマサポート技術者から要求された場合、あるタイムスロットが選択済みである場合はいつでも、他の技術者は、残りのスロットだけを選択することができる。したがって、音声アプリケーションのただ１つのコピーだけが、一群の技術者の間で循環している場合には、アプリケーションは技術者の応答を先着順に取り込む。
【００７６】
特性３０５ａに対する共用可能アプリケーション状態の設定では、音声アプリケーションが永続的であるか否かにかかわらず、消費者は、対象となるダイアログにおける他の技術者の応答を「確認する」ことが可能である。音声アプリケーションシェルが作成された後で、図２のステップ２０７に関連して説明したように、製作者は次いで、音声アプリケーションの最初のダイアログを作成することができる。ここで、シェル３００が、リモートクライアントおよび好ましくはデスクトップクライアントを用いてモデル化されることを思い出されたい。このことについては本明細書の中で後ほどより詳細に説明する。
【００７７】
図４は、本発明の一実施形態によるダイアログオブジェクトモデル４００を示すブロック図である。ダイアログオブジェクトモデル４００は、図３に関して上述したダイアログオブジェクト３０１ａ〜ｎのいずれにも類似している。オブジェクト４００は、ダイアログおよびその特性のすべてをモデル化する。ダイアログオブジェクト４００の内部に示され、オブジェクト特性（４１０）と名付けられた特性オブジェクトは、ダイアログタイプ、およびダイアログに適用される挙動状態やビジネスルールなどの特性を含む。
【００７８】
例えば、あらゆるダイアログは、この例ではルートツー（Route  To）特性（４１１）として示されている送り先特性を含む。特性４１１は、ダイアログのソースにマップされそれを識別する。同様に各ダイアログは、この図でルートフロム（Route  From）特性（４１２）として示されている送り元特性を含む。ルートフロム特性４１２は、ダイアログの受信連絡先またはダイアログ消費者にマップされそれを識別する。
【００７９】
あらゆるダイアログは、この例で、ダイアログタイプと名付けられ要素番号４１３が付与された特性によって示されるダイアログの種類に分類される。ダイアログタイプ４１３は、以下のような種類のダイアログを含むことができるが、これらに限られるものではない。
１．ラジオダイアログ（Radio  Dialog）。ラジオダイアログは、音声アプリケーション消費者が、ダイアログの説明を聞いた後で、オプションリストから使用可能なオプションの１つを対話的に選択することができるものである。
２．ブリテンダイアログ（Bulletin  Dialog）。ブリテンダイアログは、音声アプリケーション消費者が、掲示板に似たフォーラムと対話することができるものである。掲示板では、複数の消費者が、非同期に音声メッセージを共有することが可能である。
３．ステートメントダイアログ（Statement  Dialog）。ステートメントダイアログは、消費者からのどのような応答も期待することなく、音声アプリケーション消費者へのステートメントを再生するものである。
４．オープンエントリダイアログ（Open  Entry  Dialog）。オープンエントリダイアログは、音声アプリケーション消費者が、ダイアログの説明を聞いた後で、予め規定された長さのメッセージを記録することができるものである。
５．サードパーティダイアログ（Third  Party  Dialog）。サードパーティダイアログは、開発者が、独自の特性および挙動を備えたオーダメイドのダイアログタイプを生成することができるモジュールコンテナ構造のことである。一例として、ＮｕａｎｃｅのＳｐｅｅｃｈＯｂｊｅｃｔ（商標）がある。
【００８０】
各ダイアログタイプには、１つまたは複数の関連するビジネスルールがタグ付けされ、そのタグを用いて、認識された状態に応じた次のステップを決定することが可能になる。ルールは、例えば、より小さい（less  than）、より大きい（greater  than）、等しい（equal  to）、または等しくない（not  equal  to）などの演算コードを用いて、アプリケーション消費者の応答とアプリケーション開発者によって規定されたオペランドとを比較する。本発明の好ましい実施形態では、ルールに関連するパラメータは、以下の通りである。
【００８１】
ユーザ応答が、予め定められた値に等しい場合は、以下のうちの１つを実施する。
Ａ．何も実施せずにダイアログ状態を終了する。
Ｂ．指定された連絡先へのライブのブリッジ転送を実施する。
Ｃ．他のダイアログを他の連絡先に送信する。
【００８２】
アウトバウンド音声アプリケーションの場合は、認識された状態に関連する例外処理ビジネスルールが存在する可能性が高い。本発明の好ましい実施形態では、例外処理ルールは、３つの異なるイベントに要約される。
１．音声アプリケーションを受信するように指定されたアプリケーション消費者が、音声アプリケーションと対話することを求める要求を拒絶する。
２．アプリケーション消費者が、音声アプリケーションの起動時点で、例えば電話の話し中信号など接続がビジー状態である。
３．アプリケーション消費者の接続が、例えば電話応答機など非人間の装置によって応答されるか、またはそれに転送される。
【００８３】
上記の各イベントに対して、認識されている状態に従って、３つのフォローアップ動作のいずれか１つが可能である。
１．何も実施せずにダイアログ状態を終了する。
２．その番号をリダイアルする。
３．他の連絡先に他のダイアログを送信する。
【００８４】
図５は、本発明の一実施形態による、ＶＸＭＬ対応音声アプリケーションの音声ダイアログ作成のための諸ステップを示す処理フロー図である。すべてのダイアログは、後続のダイアログ送信のために再使用可能である。先に説明したように、あらゆるダイアログペアおよび連絡先ペアに対して１組のビジネスルールが存在する。ダイアログは、それがルールに適合するときだけ、アクティブになり、あるダイアログ状態から他のダイアログ状態に遷移することができる。
【００８５】
ステップ５０１で、開発者は、ダイアログの説明をダイアログ記述フィールドに記入する。ダイアログ記述には、後で説明するように、ＸＭＬタグへの参照を含めることができる。ステップ５０２で、ダイアログタイプに関するパラメータが、割り当てられたダイアログのタイプに基づいて入力される。使用可能なパラメータの例については、図４に関係して説明済みである。
【００８６】
ステップ５０３で、開発者は、フォローアップルーチンも同様にカバーするダイアログタイプに適用可能なビジネスルールを設定する。一実施形態のルールでは、ステップ５０３の設定は、ステップ５０５に分岐し、適用されたルールに基づいてフォローアップルーチンを決定する。例えば、開発者は、ステップ５０５で３種類の転送のうちの１つを選択することができる。例えば、開発者は、ステップ５０６によって示されるライブ転送、ステップ５０７によって示される次のダイアログ作成への転送を設定することができ、あるいは開発者は、ステップ５０８によって示されるダイアログ終了を設定することもできる。
【００８７】
開発者が、ステップ５０５からサブルーチン５０６、５０７、または５０８の設定に分岐せずに、ステップ５０３からステップ５０４に進み、そのステップで、ダイアログのインバウンドまたはアウトバウンド指定がシステムに割り当てられている場合は、ダイアログがインバウンドかアウトバウンドかに応じて、処理は、ステップ５０４から、ステップ５０８または５０９に分岐しなければならない。ステップ５０４で、ダイアログがインバウンドの場合は、ステップ５０８でダイアログは終了する。ステップ５０４での割当てがアウトバウンドの場合は、ステップ５０９で例外ビジネスルールの呼出しを設定する。
【００８８】
ステップ５１０で、開発者は、例外を処理するシステムのための少なくとも１つのフォローアップ動作を設定する。ステップ５１０でフォローアップ動作を指定する必要がない場合は、プロセスは、ステップ５０８に分岐してダイアログを完了する。ステップ５１０で１つまたは複数のアクションが設定されている場合は、ステップ５１１で、例えばステップ５１１に例示した動作であるシステムリダイアルなど１つまたは複数の動作が実行される。
【００８９】
好ましい実施形態では、音声アプリケーションが生成された後で、それを配布することができ、電話を介してその音声アプリケーションにアクセスすることができる。もちろん、アクセスの方法は、ステップ５０４で設定された割当てに応じる。例えば、アプリケーションがインバウンドの場合は、アプリケーション消費者は、音声ポータルにアクセスしてアプリケーションにアクセスする。さらに前述のように、音声ポータルは、先に図１Ｂに関連して説明した音声アプリケーションサーバの選択された番号の機能にアクセスするための音声インタフェースである。音声ポータルは、コネクション指向交換電話網（ＣＯＳＴ）対応ポータルでも、データネットワーク電話網（ＤＮＴ）対応ポータルでもよい。ステップ５０４でアウトバウンド指定の場合には、アプリケーション消費者は、音声アプリケーションサーバから送信された消費者への着信コールによって、音声アプリケーションを受信する。好ましい実施形態では、アウトバウンドコールは、サポートされている通信環境に応じてＣＯＳＴベースまたはＤＮＴベースとすることができる。
【００９０】
図６は、本発明の一実施形態による、消費者との最初の接続の後のダイアログ遷移フローを示すブロック図である。この例に示されたいくつかの要素については、先の図１Ｂの例に関してすでに説明済みである。したがって、元の要素番号を維持するものとする。この例では、アプリケーション消費者は、アプリケーション消費者６００として論理的に示されている。アプリケーション消費者６００は、電話サーバ１３０上で動作するダイアログ６０１との対話に実際に関与している。サーバ１３０は、先に説明したように、ＶＸＭＬ対応電話サーバであり、そのように名付けられている。
【００９１】
アプリケーションサーバ１１０も、実際に対話シーケンスに関与しており、動的コンテンツを消費者６００に提供する機能を有する。アプリケーション消費者６００が、この図では電話サーバ１３０内部のダイアログ６００によって表される音声アプリケーションとの対話を開始したとき、音声アプリケーションサーバ１１０は、その状況を監視する。実際に実施されているところでは、消費者６００への配布または消費者６００によるアクセスのために処理されサーバ１３０に送信された各ダイアログは、配布され実行される特定の音声アプリケーションのアトミックユニットである。したがって、ダイアログ６０１は、論理的には複数の単一ダイアログを表すことができる。
【００９２】
この例では、複数のダイアログを想定しており、ダイアログ６０１は、対話の間に消費者６００からの応答を取得する役割を担っている。送信および応答と名付けられた矢印は、記載の対話を表す。消費者６００がダイアログコンテンツに応答するとき、その応答は、同一の元の経路に沿ってＶＸＭＬレンダリングエンジン１１１に返信される。ＶＸＭＬレンダリングエンジン１１１は、応答を解釈し、解釈したバージョンを、提供されたダイアログコントローラ６０４に転送する。コントローラ６０４は、図１Ｂに関連して説明したサーバ１１０内のアプリケーションロジック１１２の一部である。ダイアログコントローラ６０４は、テーブル検索、データ取り出し、およびデータ書込みの機能を、確立されたルールおよび設定された応答パラメータに基づいて実施する機能を有するモジュールである。
【００９３】
ダイアログコントローラ６０４が、ダイアログ応答を受信したとき、ダイアログコントローラは、対象となるダイアログ（６０１）に対応する応答を、データマイニング操作およびワークフロー監視用に提供されたデータソース６０２に格納する。次に、コントローラ６０４は、提供されたルールエンジン６０３に要求を発行して、格納された応答に対応する１つまたは複数のビジネスルールを検索する。応答に対する適切なビジネスルールが見つかると、ダイアログコントローラは解釈を開始する。アクセスされたビジネスルールが、サードパーティのデータソース（図示せず）を参照する必要がある場合は、コントローラ６０４は、そのソースから必要なデータの取り出しを実施する。コントローラ６０４によって返されるデータは、いずれもダイアログコンテキストと統合され、次のダイアログ６０１のダイアログページ生成のためにＶＸＭＬレンダリングエンジン１１１に送られる。この処理は、ダイアログ６０１が終了するまで繰り返される。
【００９４】
一実施形態では、消費者６００からの受信応答の結果として、コントローラ６０４によってアクセスされたビジネスルールは、現在のアプリケーション消費者に戻る以外のダイアログ遷移状態も有している。この場合、コントローラ６０４は、アプリケーションサーバ１１０からアウトバウンドコールを発生させ、次のまたは「生成されたダイアログ」を、指定された対象アプリケーション消費者に配布する。同時に、現在の消費者は、図５のステップ５０８に関連して説明したように、ビジネスルールで指定される既定のロジックに従って自分のダイアログ状態を終了する。
【００９５】
当業者には、ルールエンジン６０３によって提供されるルールに従い、コントローラ６０４がデータソース６０２にアクセスすることを可能にすることによって、ダイアログが、動的コンテンツを含むことができるようになることは明らかであろう。ほとんどの実施形態において、一般に２つのタイプの動的コンテンツが存在する。好ましい実施形態では、どちらのタイプも、ＸＭＬの形に構成され、次に生成されるダイアログページ中に直接組み込まれる。２つのタイプの動的コンテンツの第１のコンテンツは、非繰返しタイプと分類される。非繰返しコンテンツは、図１Ｂに関連して説明した音声アプリケーションサーバ１１０のアダプタ１１３などのリソースアダプタ内部にある、リソースアダプタレジストリ内の非繰り返しリソースラベルへの相対参照を行う。
【００９６】
上記の場合は、ダイアログコントローラ６０４がダイアログを解釈するとき、ダイアログコントローラは、最初にすべてのリソースラベルをスキャンする。一致が見つかった場合には、ダイアログコントローラ６０４は、リソースアダプタレジストリを検索し、対応するリソースＡＰＩを呼び出して、必要なデータを新しいダイアログコンテキストに取り込む。サードパーティのデータソースから生データが返されると、ダイアログコントローラ６０４は、さらなる処理のためにその生データを対応するリソースフィルタに送る。フィルタによる処理が終了したとき、ダイアログリソースラベルまたはタグは、フィルタされたデータに置き換えられ、新しいダイアログに透過的に統合される。
【００９７】
動的コンテンツの第２のタイプは繰返しタイプである。繰返しコンテンツは、通常複数の組の名前と値のペアを返す。一例は、アプリケーション消費者の株式ポートフォリオにおける株式のリストである。例えば、消費者６００が、特定の株式を機械的に繰返し指示し、その結果の相場を他のダイアログ状態によって返すことを可能にするダイアログは、繰返し動的コンテンツを使用して所望の結果を得るように実施される。繰返しコンテンツは、音声アプリケーションサーバ１１０のリソースアダプタレジストリ中の繰返しリソースラベルを相対参照する。コントローラ６０４がダイアログを解釈するとき、コントローラ６０４は、非繰返しコンテンツの処理と同一の方法でリソースを処理する。しかし、フィルタしたデータをダイアログコンテキストに単に返すのではなく、データリストをループし、リストされた各アイテムを文法対応キーワードとして設定する。このようにして、消費者６００は、最初のダイアログで再生されたリスト中のアイテム（個別の株式）の１つを機械的に繰り返し、応答を取り込み、次のダイアログ状態に返すために処理することができる。以下に示す株価情報の例は、起こり得るダイアログ／応答対話を消費者６００の観点から示したものである。
音声アプリケーション：「おはようレオ。どの株価情報が必要ですか？」
アプリケーション消費者：「オラクル」
音声アプリケーション：「オラクルは１７ドルです」
音声アプリケーション：「おはようレオ。どの株価情報が必要ですか？」
【００９８】
この特定の例は、２つのダイアログから構成される。
最初のダイアログは、「おはようレオ。どの株価情報が必要ですか？」というステートメントを再生する。ダイアログは、次に、オラクル、サン、マイクロソフトなどのキーワードを聞き取る待ちの状態に進む。ステートメントは、２つの動的非繰返しリソースラベルから構成される。最初のラベルは、１日のうちの時間、すなわち、おはよう、こんにちは、またはこんばんはである。第２の動的コンテンツは、アプリケーション消費者の名前である。この場合、消費者の名前は、音声アプリケーションサーバの内部にあり、したがってリソースラベルのタイプは、ＳＹＳＴＥＭである。実際のダイアログ記述フィールドでは、次のように記すことができる。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＡＤＡＰＴＥＲ’  ｎａｍｅ  ＝  ‘ｔｉｍｅ  ｇｒｅｅｔｉｎｇ’／＞  ＜ｒｅｓｏｕｒｃｅ
ｔｙｐｅ  ＝  ‘ＳＹＳＴＥＭ’  ｎａｍｅ  ＝  ‘ｔａｒｇｅｔ  ｃｏｎｔａｃｔ’／＞  どの株価情報が必要ですか？
【００９９】
ダイアログは、消費者が自分の既存のポートフォリオから株式を口頭で述べることを予想しているので、ダイアログのタイプは、ラジオダイアログになり、ラジオダイアログの予想される応答特性は次のようになる。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＡＤＡＰＴＥＲ’  ｎａｍｅ  ＝  ‘ｓｔｏｃｋ  ｌｉｓｔ’＞
＜ｐａｒａｍ＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＳＹＳＴＥＭ’  ｎａｍｅ  ＝  ‘ｔａｒｇｅｔ  ｃｏｎｔａｃｔ  ｉｄ’／＞
＜／ｐａｒａｍ＞
＜／ｒｅｓｏｕｒｃｅ＞
【０１００】
このＸＭＬリソースラベルは、ｓｔｏｃｋ  ｌｉｓｔと名付けられたリソースラベルを探し、パラメータとしてｔａｒｇｅｔ  ｃｏｎｔａｃｔ  ｉｄを備えた対応するＡＰＩを呼び出すように、ダイアログコントローラ６０４に指示する。データの取り出しが完了すると、株式のリストは、文法の一部としてダイアログに組み込まれる。また、株式の識別に関してユーザが応答したものは何でも、対応する（ポートフォリオ中の株式の）文法と照合され、その文法の戻り値がダイアログ応答に割り当てられる。次いで、そのダイアログ応答を、ＤＩＡＬＯＧタイプのリソースとして次のダイアログに転送することができる。
【０１０１】
製作者は、＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＤＩＡＬＯＧ’  ｎａｍｅ  ＝  ‘ｄｉａｌｏｇ  ｎａｍｅ’／＞を使用することによって、任意の後続のダイアログで任意のダイアログ戻り値を参照することができる。このルールにより、製作者は、アプリケーション消費者が以前に選択したオプションを、任意の後続のダイアログで再生することができるようになる。
【０１０２】
上で示された第２のダイアログは、第１のダイアログから選択された株価情報を再生し、次いで、フローを第１のダイアログに返す。このダイアログには、特別な分岐ロジックが含まれていないので、この場合のダイアログのタイプは、ステートメントダイアログである。このダイアログのフォローアップ動作は、単にフローを第１のダイアログに転送して戻すことである。このような場合のダイアログ記述は、以下のようになる。
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＤＩＡＬＯＧ’  ｎａｍｅ  ＝  ‘ｓｅｌｅｃｔ  ｓｔｏｃｋ  ｄｉａｌｏｇ’／＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＡＤＡＰＴＥＲ’  ｎａｍｅ  ＝  ‘ｇｅｔ  ｓｔｏｃｋ  ｑｕｏｔｅ’＞
＜ｐａｒａｍ＞
＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＤＩＡＬＯＧ’  ｎａｍｅ  ＝  ‘ｓｅｌｅｃｔ  ｓｔｏｃｋ  ｄｉａｌｏｇ’／＞
＜／ｐａｒａｍ＞
＜／ｒｅｓｏｕｒｃｅ＞
【０１０３】
ＡＤＡＰＴＥＲ、ＤＩＡＬＯＧ、およびＳＹＳＴＥＭタイプを参照する以外に、ダイアログは、ＳＯＵＮＤやＳＣＲＩＰＴなど他のリソースタイプを受け入れることができる。ＳＯＵＮＤを使用して、ダイアログ記述に音声クリップを挿入することによって、ダイアログ記述をまねることができる。例えば、株価情報の後に音声を再生するために、製作者はＡＤＡＰＴＥＲリソースタグの直後に、＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＳＯＵＮＤ’  ｎａｍｅ  ＝  ‘ｂｅｅｐ’／＞を挿入する。
【０１０４】
製作者は、＜ｒｅｓｏｕｒｃｅ  ｔｙｐｅ  ＝  ‘ＲＥＳＯＵＲＣＥ’  ｎａｍｅ  ＝  ‘ｃｏｎｆｉｒｍ’／＞を使用することによって、ダイアログ記述の中にオーダメイドのＶＸＭＬスクリプトを追加することができる。したがって、好ましい実施形態では、ダイアログコンテキストの中に任意のＶＸＭＬを、最も柔軟性と拡張性を有する形で透過的に組み込むことができる。
【０１０５】
本明細書に記載した例では、マークアップ言語およびタグとしてＶＸＭＬおよびＸＭＬを使用しているが、ここで本発明の趣旨および範囲を逸脱することなく、記載した表記法の代わりに、またはそれらと組み合わせて、他の適切なマークアップ言語を使用することができることに留意すべきであることは、当業者には明らかであろう。本発明の最初の説明は、一般にＨＴＴＰ要求および応答を使用する、電話サーバへのインタフェースを備えた音声アプリケーションサーバに関してなされているが、本発明が、任意の分散ネットワークを介して明確に規定された要求および応答を処理することができる任意のシステムにおいて実施できることに留意すべきであることも、当業者には明らかであろう。
【０１０６】
図７〜図１５は、図１Ｂのステーション１４０のＣＬ１４１などの開発者プラットフォームインタフェースの様々に表示されたブラウザフレームを示す。以下のインタフェースフレームおよびフレームコンテンツについての説明は、図１Ｂのステーション１４０などのデスクトップコンピュータホストの存在を想定しており、対話は、例えばインターネットネットワーク上での開発の場合と同様に、ＨＴＴＰ要求／応答フォーマットで可能である。しかし、プロトコル、ネットワーク、インタフェース設計、および操作の範囲は様々に変更できるので、以下の説明は、本発明の方法および装置を決して制限するものではない。
【０１０７】
図７は、本発明の一実施形態による、開発者のログイン画面を含む開発者のフレーム７００の平面図である。フレーム７００は、本発明の一実施形態による、ウェブブラウザコンテナの形で開発者に表示される。商用ウェブブラウザについてはよく知られており、任意の適切なブラウザが、このプラットフォームをサポートするはずである。フレーム７００は、戻る、進む、移動、ファイル、編集、表示など、ほとんどのウェブブラウザフレームに関連する従来のウェブオプションのすべてを含む。この例では、ナビゲーションツールバーが見えている。画面７１０はログインページである。一実施形態では、開発者は、開発者アカウントを持つことができる。他の場合には、複数の開発者が単一のアカウントを共有することができる。多くの可能性が存在する。
【０１０８】
画面７１０は、ログインＩＤを入力するためのフィールド、およびログイン個人識別番号（ＰＩＮ）を挿入するためのフィールドを含む。ログインパラメータを入力した後で、開発者は、ログインと名付けられたボタンをクリックしてデータを処理依頼する。画面７１０は、デスクトップコンピュータまたは他のいくつかのネットワーク対応装置の任意の装置上に、それらの個々の装置上で使用される指定された表示形式に従って表示されるように構成することができる。
【０１０９】
図８は、図７の開発者のプラットフォームインタフェースの、ホームページのスクリーンショットを含む開発者のフレーム８００の平面図である。フレーム８００は、全画面または表示領域を埋めるように組み合わされた、ウェルカムセクション８０１、製品識別セクション８０２、およびナビゲーションセクション８０３を含む区分された画面を含む。本発明者によって作成された音声アプリケーション開発者プラットフォームの商用名は、フォンレット（Fonelet）という名称である。ナビゲーションセクション８０３は、「ホームページ」上およびソフトウェアツールのその後のフレーム上に表示するために提供される。
【０１１０】
ナビゲーションセクション８０３には、上から下へ読めば、複数の有用なリンクが含まれる。ホームへのリンクから始まり、アドレス帳へのリンクが続く。新しいフォンレット（音声アプリケーション）を作成するためのリンクは、新規作成と名付けられている。「マイ（Ｍｙ）」フォンレットへのリンク、および「オプション」へのリンクも提供される。ログアウトへのリンクとともに、標準のヘルプリンクも示されている。セクション８０３のリンクの最後に、追加の「オプションメニュー」が示されている。セクション８０３は、この例のような表示のタイプに、従来からあるスクロールバーを用いてスクロールダウンすることで見ることができる、追加のリンクを含むこともできる。
【０１１１】
図９は、前フレームである図８のセクション８０３のオプションであるアドレスを用いた対話によってアクセス可能な、アドレス帳９１１のスクリーンショットを含む開発者のフレーム９００の平面図である。画面９１１は、個人の連絡先をリストする、および連絡先リストをリストするための対話的オプションである。連絡先リストは、音声アプリケーション消費者のリストであり、この例では、単一の連絡先は１人の消費者を表す。しかし、他の実施形態では、単一の連絡先が、複数のエンティティを意味することもある。ナビゲーション画面８０３は、画面９１１の左部に表示されている。この例では、連絡先は、名前に続いて、名字、電話番号、電子メールアドレスの順にリストされる。本発明の趣旨および範囲を逸脱することなく、他の連絡先パラメータを含めることも、削除することもできる。例えば、連絡先のウェブサイトを、リストすることもできるし、音声アプリケーションを受信するためのインタフェースをリストすることもできる。リストされた連絡先の左側には、選択および設定の目的で使用される対話的選択ボックスが配置されている。対話的オプションは、ウェブボタンの形で表示され、開発者が、連絡先を追加または削除することができるように構成される。
【０１１２】
図１０は、新しい音声アプリケーションを作成するための画面１００１を表示する開発者のフレーム１０００の平面図である。画面１００１は、本発明者によってフォンレット（Fonelet）と名付けられた新しい音声アプリケーションの作成を開始する。画面１００１の名前フィールド１００２は、アプリケーションの名前を入力するために提供される。記述フィールド１００３は、アプリケーションの説明を入力するために提供される。特性セクション１００４が、示されており、開発者が、公開、永続、および共有可能とリストされた使用可能なオプションから、適切なチェックボックスをクリックすることによって選択することができるように構成される。
【０１１３】
ダイアログフロー設定セクションが提供されており、ダイアログタイプ選択フィールド１００５、ならびに連絡先または連絡先グループを選択するための次のフィールド１００６を含む。必要な情報が、適切なフィールドに正しく設定された後で、開発者は、作成と名付けられた対話オプション１００７をクリックすることによって、ダイアログを「作成」することができる。
【０１１４】
図１１は、スクロールダウンの結果として、別のオプションを表示する図１０の画面１００１を示す開発者のフレーム１１００の平面図である。呼出しスケジュール設定セクション１１０１が、示されており、オンデマンドまたはスケジュールの対話オプションが提供される。前述のように、オンデマンドを選択すると、開発者の意思でのアプリケーション配布が可能になり、一方スケジュールを選択すると、時間／日付パラメータによるスケジュール配布の設定が開始される。入力フィールドのグループ１１０２は、タイムゾーン、および起動月を設定するように提供される。入力フィールドの次のグループ１１０３は、スケジュール起動の曜日および日付の設定のために提供される。入力フィールドの次のグループ１１０４は、スケジュール起動の時間および分を設定するために提供される。ここで、オプションにより、同じアプリケーションの繰り返し起動が可能であることに留意されたい。開発者が、音声アプリケーションシェルの指定を終了すると、開発者は、作成と名付けられたダイアログ作成ボタンをクリックして、重なって表示されるダイアログ作成用のブラウザウィンドウを表示させることができる。
【０１１５】
図１２は、本発明の一実施形態による、ダイアログ設定ページを示すダイアログ設定ウィンドウ１２００のスクリーンショットである。このウィンドウで、開発者は、音声アプリケーションまたはフォンレットがリンクすることになる第１のダイアログを構成する。ダイアログ識別セクション１２０１は、作成すべきダイアログを識別しかつ記述するために提供される。ダイアログ名を入力するためのテキスト入力フィールド、およびダイアログ記述を入力するためのテキスト入力フィールドが提供される。ダイアログ記述フィールドの内には、ＸＭＬリソースタグ（図示せず）が挿入される。ＸＭＬリソースタグは、例えば図１Ｂに関連して説明したアダプタ１１３およびアプリケーションサーバ１１０など、アプリケーションサーバ内のリソースアダプタに登録されたリソースラベルマシンコードを参照することができる。
【０１１６】
セクション１２０２は、画面１２００内部に提供され、予想される応答を開発者が設定できるように構成される。この場合、ダイアログのタイプは、ラジオダイアログである。セクション１２０２は、多肢選択式ダイアログのためのビジネスルールロジックコントロールとして機能する。セクション１２０２は、ＹｅｓまたはＮｏ応答に対する選択オプションを含む。ここで、単なるＹｅｓまたはＮｏ応答に加えて、多様な予想応答が存在し得ることに留意されたい。
【０１１７】
隣接するセクションは、ダイアログに対する実際の応答の結果として生じる、任意のフォローアップ動作を設定するために、セクション１２０２内に提供される。例えば、各予想される応答であるＹｅｓおよびＮｏに対して、無動作を選択するオプションが提供されている。フォローアップ動作の場合には、各予想される応答に対して、接続のためのオプションが提供される。図示された各接続オプションに隣接して、データフェッチなどのフォローアップ動作を選択するための選択フィールドが提供される。
【０１１８】
送信オプションは、任意の組み込まれたデータなど選択されたフォローアップ動作を送信できるように提供される。フォローアップ動作は、例えば新しいラジオダイアログを送る、マシン修理要求を送るなど、任意のタイプの設定応答であってもよい。送信オプションおよび関連する選択オプションは、フォローアップ動作の受取人を識別し、その受取人に動作を自動送信できるように提供される。例えば、最初のダイアログが、複数の内部修理技術者に送信されるマシン修理サービスの要求である場合は、最初の連絡先が、仕事を引き受けることを拒否したか、または配布の時点で電話に出られなかった場合には、フォローアップは、同じダイアログを次に使用可能な連絡先に送信することができる。
【０１１９】
上記の場合は、連絡先の１つが利用可能であり、かつ仕事を引き受けることによってダイアログと対話することを選択するまで、ダイアログは、連絡先から連絡先にリストを下方に移動することができる。この場合のフォローアップは、故障の診断データおよび修理をいつ行うべきかなど、どのマシンを修理すべきかについてのパラメータを詳述する新しいダイアログを、受け入れ連絡先に送信することであってもよい。この例では、詳細を示すオプションは、開発者の調査目的で提供される。新規のまたは追加の応答を作成するため、およびシステムから既存の応答を削除するための対話オプションも提供される。ここで、ダイアログおよびダイアログ応答が作成された後で、それらは、音声アプリケーションの全体および音声アプリケーションの任意の指定されたシーケンスで再利用できることに留意されたい。
【０１２０】
セクション１２０３は、画面１２０１の内部に提供され、送信接続例外を処理するように構成される。このセクションは、アプリケーション配布において、起こり得る各接続状態の場合に、何をすべきかを開発者が設定することを可能にする。例えば、発呼者の拒絶、回線ビジー、またはボイスメールへの接続に対して、図示のように無動作およびリダイアルのオプションが存在する。ここで、本発明の趣旨および範囲を逸脱することなく、この例で図示した以外に、より多くの例外およびフォローアップ動作タイプが存在し得ることに留意されたい。
【０１２１】
送信オプションは、同一のダイアログ、または隣接するドロップダウンメニューから選択することができる他の任意のダイアログを再送するために各種の例外に対して提供される。例えば、最初のダイアログが、修理サービスの要求であり、例えば最初にすべての連絡先がビジーであった場合には、ダイアログは、各ビジー信号の後に先ず次の連絡先に移って送信し、次いでリストの先頭から再度リダイアルを開始することによって、１つの連絡先が使用可能になるまで、すべての連絡先にわたって送信することができる。この場合、ジョン  ドゥは、使用不可能であったために前の連絡先が、ダイアログを拒絶したか、ビジーであったか、またはボイスメールにリダイレクトした後の、次の受信者を表している。セクション１２０３は、音声アプリケーションがアウトバウンドに設定されているときだけ使用可能である。開発者は、最初のダイアログを作成し使用可能にした後で、必要ならば、詳細と書かれた使用可能なボタンの１つをクリックすることによって、第２のダイアログを作成することができる。ダイアログの保存、保存および終了、および取消し変更のための対話ボタンも提供されている。
【０１２２】
図１３は、次の連絡先に対するダイアログ状態の進行を示す、図１２のダイアログ設計パネル１２００に関するスクリーンショット１３００を示す図である。図１２の例で構成されたダイアログ状態は、次に、図１２のセクション１２０１に類似したセクション１３０１の送信元にリストされた連絡先から送信先にリストされた連絡先に送信される。この場合、関連する連絡先は、ジョン  ドゥとジェーン  ドゥである。この場合、ダイアログは再使用なので、ダイアログ名と記述は同じである。開発者は、どのダイアログコンテキストも再入力する必要はない。ただし、各ダイアログは、受信者と一意の関係を有しているので、開発者は、対応するビジネスルールを設定する必要がある。
【０１２３】
この例のセクション１３０２および１３０３は、前の例である図１２のセクション１２０２および１２０３に類似している。この場合、ジョン  ドゥが、機械修理の要求を断った場合は、システムは、ジェーン  ドゥへのブリッジ転送を行う。例外処理の場合には、送信先接続例外処理の領域１３０３に示されるように、すべてのイベントは、リダイアルルーチンを対象とする。応答フィールド１３０２に「Ｙｅｓ」または「Ｎｏ」などのキーワードを挿入することに加えて、開発者は、この例には示されていないが、提供されるシソーラスアイコンをクリックすることによって、カスタムメイドのシソーラスを作成することができる。シソーラス中のすべての作成された語彙は、開発者が作成する任意の音声アプリケーションを通して、後ほど再利用することができる。
【０１２４】
図１４は、好ましい実施形態による、図１３の例から起動されたシソーラス設定ウィンドウ１４００のスクリーンショットである。シソーラスウィンドウ１４００は、語彙単語にラベルを付けるためのフィールドを含むセクション１４０１、およびラベルが付けられた単語の同義語をリストするための関連するフィールドを備える。この例では、単語、いいえ（no）は、起こり得る応答である、いいえ（no）、いいや（nope）、およびフレーズ「できません（I  can  not  make  it）」と関連している。このように、音声認識訓練（voice  recognition  regimen）は、同じ意味を持つことがある応答の多様性に対応するために、個人化された方法で訓練することができる。
【０１２５】
語彙セクション１４０２が提供されており、音声アプリケーションおよびリストされた単語の１つを選択する選択機構(この場合は選択バー)のために、作成されたすべての語彙単語をリストするように構成される。セクション１４０２内には、新しい単語と同義語のペアを作成するためのオプションも提供されている。ウィンドウ１４００内にはコントロールパネルセクション１４０３が提供されており、そのセクションは、シソーラスからの選択、シソーラスの更新、シソーラスからの削除、およびシソーラスの終了の各コントロールを提供するように構成されている。
【０１２６】
図１５は、本発明の一実施形態による、作成されたモジュールを管理するための画面１５０２を示す開発者のフレーム１５００の平面図である。
【０１２７】
すべてのダイアログウィンドウを閉じた後で、フレーム１５００は、モジュール管理オプションのための画面すなわちページ１５０２を表示する。この場合も、メニューセクション８０３が見えている。画面１５０２は、フレーム８０３のオプション「マイ（Ｍｙ）」またはマイフォンレットをクリックした結果として表示される。画面１５０２は、作成済みで使用可能なすべての音声アプリケーションをリストする。このリストでは、各音声アプリケーションは、それに隣接するチェックボックスを備えており、それを選択して、特定のアプリケーションの状態を変更することができる。画面１５０２内にはステータスとラベル付けされた列が存在し、作成済みのアプリケーションのアプリケーションリストに隣接して配置されている。
【０１２８】
ステータス列は、各音声アプリケーションの変更可能な状態をリストする。使用可能なステータスオプションには、非アクティブ、アクティブ、およびインバウンドなどがあるが、リストされた状態に限られるものではない。直接アクセスＩＤとラベル付けされた列が、ステータス列に隣接して設けられており、ＰＳＴＮネットワークの音声インタフェース、または一実施形態では、ＤＮＴ音声インタフェースを介して、開発者が直接音声アプリケーションにアクセスすることを可能にするように構成されている。ＰＳＴＮ実施形態では、直接アクセスＩＤ機能は、中央の電話番号の内線として動作する。直接アクセスＩＤ列の隣に、動作とラベル付けされた次の列が設けられており、開発者が、音声アプリケーションの状態に関係する特定の動作を選択し、かつ適用することを可能にするように構成されている。
【０１２９】
例えば、開発者が、アプリケーション識別リストの先頭にリストされているフィールドサポートセンタ（ＦＳＣ）と識別される音声アプリケーションを完成させたところだと想定する。現在、ＦＳＣのリストされた状態は非アクティブである。次に、開発者は、関連する動作のドロップダウンメニューを起動して、アプリケーションＦＳＣをオンデマンドで起動するために起動を選択する。スケジュール起動の場合には、音声アプリケーションは、音声アプリケーションシェルに規定された設定に従って自動的に起動される。
【０１３０】
起動コマンドが発行されると直ちに、オンデマンド要求は、システムのアウトバウンドアプリケーションサーバを介して配布するためにキューに入れられる。次に、例えばジョン  ドゥは、ジョンが呼出しを受ける用意があるかどうかを尋ねる音声アプリケーションサーバ（１１０）からの呼出しを受信する。ジョンが「はい」と答えた場合は、音声アプリケーションが実行される。実際の通話フローは以下のようになる。
システム：「こんにちはジョン。ジム  ドゥからフォンレット（fonelet）が届いています。この呼出しを受けますか？」
ジョン：「はい」
システム：「マシン番号００８が故障しています。修理をして頂けますか？」
ジョン：「いいえ」
システム：「フォンレットをご利用いただき有難うございました。さようなら」
システム：ジョンとの接続を終了し、データソースに呼出しフローを記録し、ジェーン  ドゥへ新しい呼出しを実行する。
システム：「こんにちはジェーン。ジム  ドゥからフォンレットが届いています。この呼出しを受けますか？」
ジェーン：「はい」
システム：「マシン番００８が故障しています。修理をして頂けますか？」
ジェーン：「できません」
システム：「しばらくお待ちください。フォンレットは、あなたをジェフ  ドウに転送します」
システム：ジェーン  ドゥとジェフ  ドゥとの間のブリッジ転送を実施する。会話が終了したときには、ジェフとの接続を終了し、データソースに呼出しフローを記録する。
【０１３１】
音声アプリケーションのデフォルトのテキストコンテンツは、電話サーバまたはＤＮＴサーバ上で動作するテキスト音声変換エンジンで生成される。しかし、音声アプリケーション製作者は、ＰＳＴＮまたはＤＮＴサーバを介して音声ポータルにアクセスし、音声アプリケーション中の任意の既存のプロンプトによって自分の音声を記録することができる。
【０１３２】
本発明の方法および装置が、ＣＴＩ対応電話環境と併せて実施できることは、当業者には明らかであろう。その場合、アプリケーション開発のための開発者アクセスは、データネットワークに接続され、かつアプリケーションおよび電話コンポーネントを提供するサーバへの接続性も備えている、コンピュータステーション上で動作するクライアントアプリケーションによって可能になる。本発明の方法および装置は、また、ＤＮＴベースのシステムでも実施することができる。その場合には、電話サーバおよびアプリケーションサーバはどちらも、よく知られているインターネットネットワークなどのデータネットワークに接続される。ＶＸＭＬおよび／または類似の目的で動作する他の適用可能なマークアップ言語に対応した任意の適切なマルチティア（multi−tier）システムなどの通信環境のあらゆる組合せについてのアプリケーションが存在する。
【０１３３】
個別のダイアログおよび応答を含む音声アプリケーションをモデル化することで、モジュール方式の既存のオブジェクトを再利用し、それによって、オブジェクトの既存の蓄積から広範で有用なアプリケーションを使用可能にすることにより、あらゆる開発者が、限りなく多様な音声アプリケーションを迅速に作成することが可能になることも、当業者には明らかであろう。
【０１３４】
ウェブデータの自動取得
本発明の一実施形態では、ＰＳＴＮベースのポータルを介して操作するユーザからアクセス可能な音声応答を生成するＶＸＭＬエンジンによって提供されるデータを、１つまたは複数のウェブサイトから自動的に取り込むことができる。このような拡張については、以下で説明する。
【０１３５】
図１６は、本発明の一実施形態による、ウェブ取込み用に拡張された図６のダイアログ遷移フローを示すブロック図である。この実施形態では、ダイアログコントローラ６０４は、ＨＴＭＬ、ＷＭＬ、またはウェブサイトで提供されるデータの場合など、他のデータソースからのデータにアクセスし、かつそれを取り込むように拡張される。この実施形態の例示的シナリオには、顧客の誰もが、音声ポータルを介してそのウェブサイトにアクセスできる金融機関のシナリオがある。
【０１３６】
この実施形態にはウェブサイト１６００が示されており、ウェブサイト１６００は、この図では２本の方向性通信ラインとして示されているネットワークアクセスライン１６０１を介して、ダイアログコントローラ６０４にアクセスすることができる。第１のラインは、格納／取込み／入力とラベル付けされており、コントローラ６０４からサイト１６００に至るものである。第２の（戻り）ラインは、データリターン／ソースフィールドとラベル付けされている。この別々に示された通信ラインは、双方向のインターネットまたは他のネットワークアクセスラインなどであることを意図したものである。図６に関連して先に説明した内部データソース（６０２）は、図１６では、説明のためだけにウェブサイト１６００に置き換えられている。サーバ１１０の内部およびサーバ１１０の外部にある複数のデータソースが、ダイアログコントローラ６０４から同時にアクセス可能であることに留意されたい。
【０１３７】
ウェブサイト１６００は、少なくとも１つの電子情報ページ（ウェブページ）を提供する。このページは、その作成と維持に使用されるマークアップ言語の既存のルールに従ってフォーマットされている。サイト１６００は、多くの情報ページが動作する１つのサイトであってもよい。情報ページのいくつかは、相互に関連づけられており、その後のナビゲーション動作によってアクセス可能である。この実施形態のコントローラ６０４は、ユーザの音声入力指示によるウェブサイトナビゲーション用に拡張されている。ユーザの音声入力指示は、ルールエンジン６０３にアクセスすることによってアクセス可能なルールによって有効にされたものである。データテンプレート（図示せず）は、サイト１６００からの論理データの取り込みを容易にするために、ダイアログコントローラ６０４によって使用されるように提供されている。ダイアログコントローラ６０４は、リターンデータであるウェブサイトソースコードとデータフィールドの両方を分析し、その情報を使用して、レンダリングエンジン１１１のためのＶＸＭＬページを生成する。
【０１３８】
ここで、通常のインターネットアクセスのためのサイトで使用されるセキュリティおよびアクセス機構はすべて、顧客が、セキュリティアクセス情報を含む音声レンダリング（応答）を提供することによってアクセスが許可されるように、顧客に基づいて推論されることに留意されたい。このことにより、顧客は、ネットワーク接続されたコンピュータからサイト１６００への通常のウェブアクセスのためだけでなく、ポータルを介した音声トランザクションのために同じセキュリティパスワードおよび／または個人識別番号（ＰＩＮ）をそのまま維持することができる。
【０１３９】
図１７は、本発明の一実施形態による、自動ウェブ取込みとデータレンダリングのために追加されたコンポーネントを示す、図１Ｂの音声アプリケーション配布環境についてのブロック図である。この例では、クライアントソフトウェア１４１が動作するワークステーション１４０は、目的のウェブサイト１６００を提供するネットワークサーバ１７０１に直接アクセスすることができる。アクセスは、インターネットアクセスライン１７０４によって提供される。
【０１４０】
ここで、本実施形態において、本発明の趣旨および範囲を逸脱することなく、多数のサーバ１７０１、ならびに複数のページからなる多数の提供されたウェブサイトが存在し得ることに留意されたい。この例では、データベースストア１７０２が提供されており、データベースストア１７０２は、データを格納するためにサーバ１７０１に接続されるように示されている。データストア１７０２は、光ストレージ、磁気ストレージ、ハードディスク、あるいはオンラインでアクセス可能なデータを格納するのに適した他の形態であってもよい。一実施形態では、データストア１７０２は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）であり、この場合、単一のアクセスに、やはりアクセス用のデータを格納する１つまたは複数の接続されたサブサーバが関係することがある。
【０１４１】
ネットワーク１７０４接続された、クライアントアプリケーション１４１、ワークステーション１４０、サーバ１７０２、ウェブサイト１６００、およびデータベース１７０２からなる構成により、サイト１６００などのウェブサイトを選択し、取り込むことが可能になる。アプリケーション１４１は、各ＨＴＭＬスクリプトまたは他のマークアップ言語のスクリプトごとに存在するすべてのデフォルト応答を、読み出し、かつ取り出すことができる。これらのデフォルト応答は、アプリケーションロジック１１２およびＶＸＭＬレンダリングエンジン１１１に組み込まれている。クライアント１４１でウェブページのコンテンツを選択し、かつ使用してレンダリングを作成した後で、ＶＸＭＬエンジン１１１は、個別のアクセスネットワーク１７０３を経由して、アプリケーションロジック１１２およびデータベース／リソースアダプタ１１３と共同して、ウェブサイトにうまくアクセスすることができる。例えば、ユーザ（図示せず）が、受信装置１３５（電話）から音声ポータル１４３を介してウェブサイト１６００にアクセスした場合は、そのユーザには、そのサイトへのアクセスを取得するためのパスワードを求める音声によるプロンプトが示される。その後で、アクセスしたサイト上のデータの音声レンダリングが、電話１３５を介してユーザに提供されることになる。
【０１４２】
一般に、音声ポータルの開発プロセスは、先に図９〜図１５に関して説明したものと同一になるはずである。いくつかの追加のスクリプト記述またはダイアログの入力が、クライアントアプリケーション１４１を用いて実施される。先に図９〜図１５に関して論じたビジネスロジックで使用されるフィールドは、アプリケーション開発者が、最初から全てのフィールドを設定するか、または以前に入力されたオプションを再度適用することが必要になるというのではなく、この場合は、サイト１６００から取り込んだ情報から作成することができる。その目的で、クライアントソフトウェア１４１にソフトウェアアダプタ（図示せず）を追加することによって、そのアダプタが、ウェブサイト１６００と通信し、フィールドやラベルなどを含むソースコード、ならびにデータパラメータやデータ変数などから情報を取り込むことが可能になる。
【０１４３】
ここで、データアクセス、取り出し、および音声レンダリングのための処理は、任意の他のオプションが選択される前に、ウェブサイト接続が確立されることを除いて、本質的に上記の図２〜図５の処理と同一であることに留意されたい。
【０１４４】
一実施形態では、サーバ１１０とサーバ１７０１との間の接続１７０３を提供することにより、通信するマシン間で実行されるセキュアソケットレイヤ（ＳＳＬ）やファイアウォールなどのセキュリティ環境を、作成された音声ソリューションにおいて顧客に適用することが可能になる。アナログ側では、盗聴等の可能性に関して、コールインラインのセキュリティとまったく同じセキュリティで、銀行業務サービスが可能になる。
【０１４５】
当業者には、本発明の方法および装置が、インターネット、イーサネット（登録商標）、または他の任意の適切なネットワークとともに実施できることは明らかであろう。サポートされるマークアップ言語には、ＨＴＭＬ、ＳＨＴＭＬ、ＷＭＬ、ＶＨＴＭＬ、ＸＭＬなどが含まれる。一実施形態では、ウェブサイトアクセスは自動アクセスも可能であり、その場合ユーザのパスワード情報は、サイト自体に保持される。多くの可能なシナリオが存在する。
【０１４６】
音声レンダリング用ウェブデータの優先順位付け
本発明の一態様によれば、取り込んだウェブサイトからどのウェブデータ提供物を音声アプリケーションのテンプレートに埋め込むのかを、選択しかつ優先順位付けする方法が提供される。
【０１４７】
図１８は、ウェブサイトの単純な階層構造ツリー１８０１、およびそのサイトの取り込まれたバージョン１８１０を示すブロック図である。画面１８０１は、ユーザインタフェースによって見ることができる、単純なウェブサイト構造ツリーを示す。データ要素を表す選択可能なアイコンは、この図では実線１８０２ａから１８０２ｎとして示されており、任意の例示的なウェブサイトに、任意の数のアイコンを提供することができることを示唆している。本明細書の目的では、アイコン１８０２ａ〜１８０２ｎは、選択可能なアイコン、ロゴ、ハイパーリンクなどを表す。各オブジェクト１８０２ａ〜１８０２ｎの分類は、この図ではテキストラベル１８０３ａから１８０３ｎとして示されている。例えば、選択可能なアイコン１８０２ａは、隣にある分類１８０３ａによって明らかなように、サイトの「ホームページ」に移動するためのものである。次のアイコン（１８０２ｂ）は、分類のログインから明らかなように、サイトのログインページ用のものである。ある場合には、アイコンと分類またはラベルは、同一物（見た目が異ならない）のことがある。
【０１４８】
この例では、階層構造はログインブロックを示している。ログインブロックは、他のオプションが提示される前に、ユーザがナビゲートに成功しなければならないブロックである。提示されたオプションである、アカウント、ステータス、履歴、検索、取引、および株価は、階層構造で配置されている。例えば、ユーザは、先ずアカウントにアクセスする必要があり、その後、オプションのステータス（アカウント／ステータス）または履歴（アカウント／ステータス／履歴）が、ユーザにとって使用可能になる。この標準の構造は、ダイアログナビゲーション用の音声アプリケーションテンプレートを作成するためのテンプレート埋め込みにとっては、不便でありかつ無駄が多くなることがある。１つの理由は、音声アプリケーションが、ウェブサイトにあるすべてのデータを使用するように試みながら作成されるからである。ウェブサイトのデータは、画像、図表などを含む可能性が高く、それらの記述が、単に翻訳され、音声ダイアログとして電話を介して話された場合は、アクセスしたユーザは理解できなくなる。もう１つの理由は、ウェブサイト構造１８０１の一般的な階層は、要求／応答フォーマットの音声ダイアログとして、レンダリングするための望ましい階層になっていない可能性があるからである。一般に、有用なデータもあれば、有用でないデータもある。したがって、ダイアログレベルでデータが提示される順序は、管理者（サービスプロバイダ）にとって重要であるばかりでなく、ユーザにとっても重要なものになる。
【０１４９】
画面１８１０は、完全に取り込まれた画面１８０１と同一の構造を表す。すなわち、サイトのソースコードで識別されたアイコンおよび各要素はすべて、起こり得るテンプレート埋め込みのために取得されている。テンプレートを用いることで、音声アプリケーションは、管理者によって設定された制約に従って更新されたデータを取得しかつレンダリングするという目標で、動作することができることに留意されたい。ウェブサイト１８１０は、テンプレート埋込みのために事前に準備される。アイコンは、１８１２ａから１８１２ｎとラベル付けされ、分類は、１８１３ａから１８１３ｎとラベル付けされる。
【０１５０】
オブジェクト１８１０は、画像、図表、ダイアログボックス、テキストリンク、データフィールド、ならびにサイトのＨＴＭＬまたは他の言語の形で提示されかつ有効にされた他の任意の提供された機能を含む、ウェブサイトの一般的な構造をエミュレートするように生成される。ダイアログを受け取るために音声ポータルにアクセスする潜在的に多くのユーザと関係する軽減要因のために、ユーザの便宜およびネットワーク負荷安定化のために、多くの合理化が必要とされている。したがって、所望の選択および階層構造に従って、音声アプリケーションテンプレートが埋められ、結果として得られる音声アプリケーションのより経済的で最適化された構成ならびに実行を容易にするように、要素のオブジェクトモデル化およびツリー階層の再構成のための中間ステップが必要になる。
【０１５１】
本発明のオブジェクトモデリングツールは、上記図１Ｂに関連して説明したクライアントアプリケーション１４１の一部として提供することができる。作成されたオブジェクトは、階層構造および所望のコンテンツによって構成され、上記図６に関連して説明したアプリケーションサーバ１１０、または音声アプリケーションサーバ１１０からアクセス可能なローカルデータベースに格納されることができる。
【０１５２】
図１９は、図１８のウェブサイト構造１８０１、およびテンプレート作成のために作成されかつ編集されるウェブサイトオブジェクトを示すブロック図である。画面１８０１は、要素およびその記述の両方に関して図１８の画面１８０１に類似している。したがって、図１８の構成１８０１に関して示された要素またはその要素についての説明は、いずれもここでは説明はしないものとする。
【０１５３】
画面１９１０は、構成１８０１から始まる、取り込まれたウェブサイトを表すが、音声アプリケーションテンプレートに最適化された方式で取り込むために、要素優先順位付けによって再構成されている。この例では、取り込まれたウェブサイトの元のコンテンツおよび構成を変更するために、重要な編集が実施されていることが分かる。アイコン１９１２ａから１９１２ｎは、取り込まれた後で保持されているアイコンを示す。１９１３ａから１９１３ｎは、それらのオブジェクトの分類を表す。最初に、構成１８０１でホームおよびログインとラベル付けされたアイコンに関する最適化に注目する。取り込まれたオブジェクト１９１０中のこれらのアイテムは、ログインとラベルされかつ要素番号１９１３ａが与えられた１つの指定されたオブジェクトに結合することによって、最適化されている。この場合、アカウントステータスおよび履歴は、最も有用な要素であり、最も一般的に要求される情報であるバランスに合理化されている。この場合にはまた、音声ダイアログとして提供された場合に理解できなくなる可能性がある、図表、グラフ、または他の視覚要素は、音声アプリケーションテンプレートから単に削除されている。テンプレート埋め込み前の構成用の中間ステップは、ウェブサイトデータを取り込むステップと、音声アプリケーションヘッダを設定するステップとの間に挿入されることになる。
【０１５４】
ログインに成功した後で、すなわちユーザが、ＰＩＮ／ユーザ名／パスワードの組合せの音声バージョンを入力し、かつ音声ポータルから音声アプリケーションへのアクセスが許可された後で、この例で次に優先すべきことは、ユーザが、自身の口座バランスまたは残高を迅速に確認できるようにすることである。２つの口座を想定して、要素番号１９１２ｂおよび１９１２ｃは２つの残高を表す。本発明の範囲を逸脱することなく、より多くのまたはより少ない数の優先順位付けられたアイコンが存在してもよい。この場合、最適化プロセスを介して提供される最初の「音声オプション」は、電話によって加入ユーザに口座残高を口頭で伝えることである。この図で要素番号１９１３ｃ〜ｆによって示された、他の提示されかつ提供されるオプションである検索、取引、および相場は、より上位のしかし同一レベルの、すなわち同じ重要性レベルが提供されているアーキテクチャまたは構造に移される。これらの３つのオプションはすべて、銘柄記号情報を含むユーザ要求または応答を使用して、任意の動作を開始することができるという点で関連している。
【０１５５】
図２０は、本発明を実施するために追加されたステップを示す処理フロー図である。ステップ２０００で、先に図１７に関連して説明したクライアントアプリケーション１４１を操作する管理者は、ソースデータおよびデータ構造のためにウェブサイトを取り込む。ステップ２００１で、管理者は、対象となるウェブサイトの既存の構造階層を表す編集可能なオブジェクトを作成する。オブジェクトツリーは、アイコンおよび関連するプロパティを含み、完成されると実行可能になる。一実施形態では、単純なドラッグアンドドロップ操作を使用してツリーを作成することができるように、多くのウェブサイトによって共有される多数の標準アイコンおよびプロパティが、管理者に提供される。開発者が、特定のオブジェクトを最初から作成しなければならない場合は、ソースマークアップ言語を使用して、オブジェクトコンポーネントを表すオブジェクトビルディングブロックからオブジェクトを構築することができる。次いで、新しいオブジェクトは、記憶装置に格納され、再使用されることができる。
【０１５６】
一実施形態では、モデリングエンジンに命令としてソース記述を提供することで、自動的にオブジェクトツリーが作成される。この場合、取り込まれたオブジェクトは、取り込まれて「直ぐに編集可能な（ready  to  edit）」ものとして管理者に提示される。その場合、ステップ２０００および２００１は、管理者には、完全ではないがほぼトランスペアレントである。他の実施形態では、管理者は、使用されるワークステーションに備えられたマウスを使用してアイコンを単にドラッグアンドドロップするだけで、モデリングを実施することができる。
【０１５７】
ステップ２００２で、管理者は、いくつかのオブジェクトを編集して、それらをＶＸＭＬ音声レンダリングの制約により完全に適合させることができる。同じステップで、管理者は、ツリーから特定のオブジェクトをすべて削除することもできる。さらに同じステップで、管理者は、レンダリングの優先順位に従ってオブジェクトを移動しかつグループ化することができる。ウェブサイトがログイン要件を含んでいる場合には、言うまでもなく、その要件は、結果として音声アプリケーションになる最優先事項または最初に実行可能なダイアログになるはずである。複雑なログインは、単純化されることができる。さらに、１つまたは複数のオブジェクトを、同じダイアログの中に組み合わせて提供することもできる。多くの可能性が存在する。
【０１５８】
他の実施形態では、オブジェクトツリーは、１レベルにまで平坦化されることができ、あるいはオブジェクトツリーは、より多くのレベルを含むように拡張されることもできる。管理者はまた、ウェブサイトで元々は使用可能でなかった（ダイアログに提供される）コンテンツを挿入することもできる。新しいコンテンツは、オブジェクトツリーの任意の場所に置くことができ、続いて音声アプリケーションの結果として生ずるダイアログにおけるしかるべき優先度の位置を占めることができる。音声アプリケーションが完成すると、そのアプリケーションの開始と実行は、サイトでの任意の新しいデータへのデータアクセスおよびその取り出しに使用できる。標準のナビゲーションテンプレートは、サイトにアクセスするために使用され、データは、オブジェクトツリー中で識別されたデータのクラスにだけ従って取り出される。このようにして、何度も繰り返し同じウェブサイトの不要なデータにアクセスすることはなくなる。
【０１５９】
ステップ２００３で、先に説明したように、音声アプリケーションテンプレートが埋められる。ステップ２００４で、管理者は、すべてのＣＴＩ連絡先パラメータの設定を含む、音声アプリケーション実行のパラメータ化を開始することができる。ステップ２００５で、管理者はダイアログを作成することができる。
【０１６０】
音声レンダリングのためのウェブ取込みコンテンツを予め構成することが、複雑さを低減し、ネットワークおよびプロセッサの負荷を低減し、さらに接続された音声ポータルシステムにアウトバウンドダイアリングの意味でアクセスまたは接続するユーザに、適切で有用な音声レンダリングだけを提供するために、非常に有用なステップであることは当業者には明らかであろう。
【０１６１】
機能拡張されたセキュリティ
図２１は、本発明の一実施形態による、音声ポータルとウェブサーバとの間のセキュアな接続性を示すブロック図である。
【０１６２】
この例に示された接続方式は、音声ポータル２１０６にアクセスするユーザ（図示せず）を、この図ではインターネット２１０８の内部に示された、そのポータル２１０６からネットワークアクセス可能なウェブベースデータ、より詳細にはデータベース２１１０に接続されたウェブサーバ２１０９に接続する。
【０１６３】
音声ポータル２１０６は、データリンク２１０５によってＸＭＬゲートウェイ２１０４に接続された音声アプリケーションサーバ（ＶＡＳ）２１０３を含む。この実施形態では、サーバ２１０９によって処理されるデータは、そこから選択され、回線２１０７を介してＸＭＬゲートウェイ２１０４に配信される。次に、アプリケーションサーバ２１０３は、音声アプリケーションを生成し、ＰＳＴＮ２１０１への電話接続を有するユーザにそれらを配布する。電話交換機、サービス制御ポイント、ルータ、および電話ネットワークに認識されたＣＴＩ対応装置は、ＰＳＴＮ２１０１内部に存在するものと想定することができる。同様に、ルータ、サーバ、およびインターネット中で認識された他のノードは、インターネット２１０８内部に存在するものと想定することができる。本発明者は、本発明の説明のためには図示の装置で十分であると考える。
【０１６４】
一般に、ＰＳＴＮ２１０１内部の任意の人から音声ポータル２１０３への音声アクセスは、インバウンド通話かアウトバンド通話かにかかわらず、保護されていないものと想定することができる。すなわち、電話回線盗聴機能を備えた誰もが、ユーザの電話と音声アプリケーションサーバとの間で実施される音声トランザクションを盗聴することができる。一般に、ソーシャルセキュリティ識別やＰＩＮ識別のＩＶＲ入力など、電話トランザクションに関する従来技術の仕様は、アカウント情報にアクセスするのには十分である。しかし、同じ情報を持つ他の誰もが、やはりそのユーザの自動アカウント回線にアクセスして、残高情報などを見つけ出すことができる。
【０１６５】
サーバ２１０９は、ウェブ証明書サービスで保護されることができる。その場合、サーバ２１０９からいずれかのデータにアクセスする（オンラインの）ユーザは、受け入れ証明とオンライン認証証明書の署名を送信しなければならない。このような管理は、ユーザのブラウザアプリケーションのオプションとして提供される。
【０１６６】
ＸＭＬゲートウェイ２１０４の地点までセキュリティを拡張する１つの方法は、完全なプライベートデータネットワークを使用することである。それほど高価でない選択肢は、この例に示されたＶＰＮネットワークである。他の方法は、ＨＴＴＰＳなどのＳＳＬ手段による。これらの方法のいずれかを使用することにより、サーバ２１０９のセキュリティ管理を音声ポータル２１０６まで拡張することができる。この実施形態では、ゲートウェイ２１０４は、一般的なセキュリティ手段によって動作するように構成されている。例えば、オンラインでサーバ２１０９に接続したユーザが、ユーザのパスワード情報を変更しかつウェブ認証証明書に署名した場合、同じ変更情報は、音声ポータルでも記録されることになる。
【０１６７】
したがって、唯一のセキュリティホールは、ＰＳＴＮ内のユーザとポータル２１０６との間に存在する。音声として任意のユーザに送信される情報、および任意のユーザから送信される応答音声は、回線２１０２を盗聴することによって取得されることができる。ある程度のプライバシーを保護するための１つの可能な解決策は、音声ポータルおよびユーザの電話に音声変換機構を使用することである。このような方法により、ポータルを出て行く音声は、不明瞭な言語またはコードにさえ変換されることができる。ユーザ端では、装置（図示せず）は、一般的な言語に変換し戻し、電話スピーカシステムによって遅れて再生する。
【０１６８】
既存のセキュリティ、ＶＰＮ、ＳＳＬなどを使用することによる追加の利点は、セキュリティシステムが、すでにテスト済みであり、絶えず改良されていることであることを当業者なら理解されよう。本発明の趣旨および範囲を逸脱することなく、多くの変形形態が提供し得ることも当業者なら理解されよう。例えば、アウトソースのウェブホスティングを使用することができる。冗長性を持たせるために、マルチサイトウェブシステムを使用することもできる。アウトソース音声サービス、またはマルチサービス／ロケーション音声サービスなども使用可能である。
【０１６９】
認識オプションのための語彙管理
本発明の他の態様により、本発明者は、音声認識ソフトウェアの最適性を増すための語彙管理システムおよび方法を提供する。この方法および装置については、以下の実施可能な開示で説明する。
【０１７０】
図２２は、本発明の一実施形態による、語彙管理サーバ２２００とソフトウェア２２０１で機能拡張された図１Ｂのアーキテクチャを示すブロック図である。
【０１７１】
この実施形態のシステムアーキテクチャは、先に図１Ｂに関して論じたアーキテクチャと非常に類似している。したがって、図１Ｂおよび図２２の両方の例に含まれる各要素については、本発明を実施するために修正されない限り、ここでは説明はしないものとする。
【０１７２】
語彙管理サーバ２２００は、音声認識テンプレートオプションを、必要な語彙に合わせ込むことによって即時の音声アプリケーションを完全に可能にするために、語彙管理ソフトウェア（ＶＭＳ）２２０１のインスタンスを用いて構成される。
【０１７３】
サーバ２２００は、それに接続されるかまたはその内部に保持され、データを格納し構成するよう構成されたデータ記憶機能を有するものと考えることができる。図１７の例に関連して先に説明したように、ウェブデータを取り込み、かつ取り込んだウェブデータを音声ダイアログのソースデータとして使用することに関して、この実施形態では、ウェブベースコンポーネントは、インターネットアクセスラインによって示されており、そのラインの１つは、ワークステーション１４０に接続され、それにウェブアクセスを提供し、もう１つは、データベース／リソースアダプタ１１３を介して音声アプリケーションサーバ１１０に接続され、それにアクセスを提供している。このような方法により、対象となる任意のウェブベースデータにウェブアクセスして、自動取込み、解釈、および音声ダイアログ変換することが想定されている。
【０１７４】
サーバ２２００は、音声アプリケーションサーバ２２０２を介して、より詳細にはデータベースリソースアダプタ１１３を経由しデータリンク２２０３を介して、クライアントアプリケーション１４１が動作するワークステーション１４０にアクセスすることができる。このようにして、管理者は、特定のオンラインまたはオフライン（内部）データソースに帰属する語彙オプションをセットアップしかつ操作することができる。
【０１７５】
ＶＭＳソフトウェア２２０１は、アクセスしたある対象データおよびその対象データに関連して許可された機能に特有の、個別で隔離された語彙のセットを可能にするように構成される。一実施形態では、ＰＳＴＮ１３４上のポータル１４３から対話によってデータにアクセスする特定のクライアントにさらに合わせ込まれた、同じ対象データソースに対する語彙の追加のサブセットを提供することができる。作成された語彙セットに特有のルールセットは、作成されかつ特定の語彙セットに付加され、アプリケーションロジック１１２に提供される。
【０１７６】
ＶＸＭＬ対応電話サーバ１３０は、図１Ｂに関して説明したエンジン１３２に置き換わる拡張エンジンとして提供された、テキスト音声変換および音声テキスト変換対応エンジン２２０５を備えている。一実施形態では、個々の機能は、個々のコンポーネントによって使用可能にすることができる。本発明者は、例示のために、２つの機能を備えた単一のエンジンを示した。エンジン２２０５は、データリンク２２０２を介して語彙管理サーバ２２００にアクセスすることができる。
【０１７７】
サーバ２２００は、データリンク２２０４を経由して音声アプリケーションサーバ１１０のアプリケーションロジック１１２にアクセス可能であり、またデータリンク２２０３を経由してデータベースリソースアダプタ１１３にアクセス可能である。一実施形態では、音声アプリケーションサーバ１００の前述のコンポーネントとサーバ２２００との間の通信を可能にするためには、単一のデータリンクだけで十分である。
【０１７８】
本発明の実施において、ウェブベースのデータソースがアクセスされる想定すると、音声認識は、前述の実施形態とは異なる方法で動作する。例えば、クライアントが、口座残高提供および株取引のオプションを含む自分の個人投資ウェブページと対話するために、電話１３５からＰＳＴＮ１３４内の音声ポータル１４３にアクセスすると想定する。ＶＭＳ２２０１によって管理されたサーバ２２００では、対象ウェブサイトに対する特定の語彙が使用可能である。おそらくは、クライアントに特有の語彙サブセットも存在し、親語彙セットの下で構成される。
【０１７９】
電話サーバ１３０は、アクセスしているユーザを認識し、既存の音声アプリケーションを起動する。音声アプリケーションサーバ２２０２は、ユーザの代わりに、データベースリソースアダプタ１１３およびインターネットアクセスラインを介してウェブサイトに接続する。音声アプリケーションテンプレートの制約に従って、データベースリソースアダプタは、ユーザが最初にまたはダイアログの開始時にそれらと通信した後で、ユーザログインおよびパスワード情報を提供し、次いでそのユーザが資格を有するアカウントデータおよび他のあらゆる更新データを取得する。音声アプリケーションからユーザに提供される最初のダイアログ応答には、そのユーザアカウントに関係する株価と、特定のシンボルに関連する現在のマネタリバランスだけを含めることができる。ユーザが使用可能なより多くの情報が存在する場合もあるが、使用可能な情報の一部は、そのユーザに関係がないか、または有用でない可能性がある。したがってＶＭＳ２２０１は、各ダイアログ提供の前に、特定のダイアログ機能のための、また場合によってはアクセスユーザに特有の適切な語彙およびルールセットを提供する。したがって、音声認識ソフトウェアは、節度なく（intemperate）提供されたＶＸＭＬページに対して、大規模な語彙を検索する必要がなくなる。この場合、ＶＸＭＬページ自体は、電話サーバ１３０に配布される前に、語彙管理機能によって制限されている。
【０１８０】
他の実施形態では、ＶＭＳ２２０１からの介入は、標準のＶＸＭＬページが提供された後で、かつサーバ１３０で音声認識が始まる前に行うことができる。この場合は、エンジン２２０５が、サーバ２２００に照会して適切な語彙制約を取得する。この例では、ＶＸＭＬから認識されないデータは、単に捨てられる。ダイアログ処理の間に、ＶＭＳ２２０１を使用して音声認識機能を合理化することができる多様なポイントが存在する。例えば、前述の最初のダイアログ応答では、ユーザに、任意の所望の取引動作を開始するよう促すことができる。ユーザがある取引を実施することを選択した場合は、エンジン２２０５の音声テキスト変換部は、クライアントに合わせ込まれた制限された取引語彙をＶＭＳ２２０１に照会することができる。このような語彙は、様々なクライアント、例えばＶＩＰであり、おそらくはより多くの許容されるオプションを持つはずのクライアントに対して拡張することができる。クライアントからの音声レンダリングで、与えられた語彙にマッチしないもの、および／またはルールに適合しないものは無視される。
【０１８１】
音声認識のための語彙オプションを個人化しかつ合理化することに加えて、管理者は、ＶＭＳを使用して新しい語彙を作成し、かつ／または同じ語彙単語と認識される複数の同義語を作成することができる。例えば、管理者はレポートを書くために、ストック（stock）、シェア（share）、およびセキュリティ（security）を同義語として構成することができる。セル（sell）、ショート（short）、およびダンプ（dump）は、すべて販売レポートのためには同義語と考えられる。多様な可能性が存在する。一般に、ＶＭＳ２２０１は、ＶＸＭＬページ上のデータをレンダリング用に制限するため、あるいはＶＸＭＬページの音声認識を制限し認識できない部分を捨てるための管理ツールとして、一通信方向（サービスからユーザ）において適用されることができる。ＶＭＳ２２０１は、サービスポリシーおよび制約に従って、ユーザまたはユーザグループに許可された音声認識オプションに合わせ込むために、逆方向（ユーザからサービス）のダイアログステップに適用されることもできる。
【０１８２】
ＶＭＳ２２０１が、ＶＸＭＬストリームだけを扱う一実施形態では、ＶＭＳ２２０１は、アプリケーションサーバ１１０内部または電話サーバ１３０内部に配置されることができる。ＶＭＳ２２０１を使用して様々な語彙セットを用いることで、単一のデータソースにアクセスする同一のクライアントに対する同一の音声アプリケーションの様々なダイアログ(最初のダイアログおよび応答ダイアログの両方)を、制約できることが理解できよう。したがって、管理機能の最適レベルは、動作／応答のレベルになる。対話の間の使用可能なあらゆるステップで、音声認識処理の作業を制限することによって、多くの処理能力と帯域幅を、他の用途のために確保することができる。
【０１８３】
ローカルキャッシュの最適化（静的、動的）
本発明のさらに他の態様では、ＶＸＭＬ配布環境でローカルキャッシュの最適化を使用して、データトラフィックを削減するための方法および装置が提供される。
【０１８４】
図２３は、本発明の一実施形態による、キャッシュ最適化コンポーネントを含むＶＸＭＬアプリケーションアーキテクチャ２３００の様々な機能コンポーネントを示すブロック図である。図２３は、更新され、追加の詳細が示されていることを除けば、図１に極めて類似している。
【０１８５】
アーキテクチャ２３００は、基本的に主要コンポーネントとして、音声アプリケーションサーバ２３０１および電話サーバ／音声ポータル２３０２を含む。ポータル２３０２は、音声ジェネレータ２３０６および電話ハードウェア／ソフトウェアインタフェース２３０５を含む。ポータル２３０２は、アプリケーションサーバ２３０１からポータルに送信されたＶＸＭＬデータを解釈するためのＶＸＭＬインタプリタ２３０７を含むことによって、ＶＸＭＬに対応している。音声ポータル２３０２は、よく知られたＰＳＴＮネットワークなどの電話ネットワークの内部でアクセセスポイントとして維持される。ただし、ポータル２３０２は、無線電話ネットワークで維持されることもできる。
【０１８６】
この例には、ウェブインタフェース２３０３が示されており、よく知られたインターネットまたは他の適用できるＤＰＮからのアクセスポイントとして機能する。音声ポータル２３０２は、ＣＴＩ拡張ＩＶＲシステム、顧客サービスポイント、または他の任意の自動音声ポータルシステムを表すことができる。ウェブベースポータルの場合は、コンポーネント２３０３は、ウェブサーバ、インターネットに接続されたコンピュータ、またはユーザインタフェースを提供する他の任意の種類のノードであってもよい。
【０１８７】
音声アプリケーションサーバ２３０１は、図２２に関連して説明した音声アプリケーション２２０２に多くの面で類似している。これに関して、音声アプリケーションサーバは、それに実装されその上で実行可能な音声アプリケーション開発ソフトウェア（ＶＡＤＳ）２３０８を備える。音声アプリケーションサーバ２３０１のドメインの内部に示されたＶＡＤＳ２３０８は、いくつかのモジュールを含む。この図では、これらのモジュールは、ラベルを使用して説明するものとし、限られた図面スペースのために、それらに要素番号は割り当てないものとする。ＶＡＤＳ２３０８に示されたモジュールには、ダイアログ受信者のパラメータを管理するための開発者ツールとして構成された、コンタクトマネージャ（Ｃｏｎｔａｃｔ  Ｍｇｒ．）インスタンスを含む。ダイアログコントローラ（Ｄｉａｌｏｇ  Ｃｔｒｌ．）は、音声アプリケーションダイアログを作成しかつ管理するとともに、ルールソースおよび内部／外部データソースに対するインタフェース動作を開始するための開発者ツールとして提供される。フォンレットコントローラ（Ｆｏｎｅｌｅｔ  Ｃｔｒｌ．）は、ＶＡＤＳ２３０８内に提供され、音声アプリケーションの後続のダイアログの配布を制御するように構成される。ＸＭＬジェネレータ（ＸＭＬ  Ｇｅｎ．）は、ＶＡＤＳ２３０８内に提供され、ＶＸＭＬページ用のＸＭＬを生成するように構成される。
【０１８８】
音声アプリケーションサーバ２３０１には、アプリケーションロジック２３０９が備えられており、このアプリケーションロジックは、アプリケーション配布、作成、および管理に関する様々な態様を制御するように構成される。アプリケーションロジック２３０９は、上述のコンタクトマネージャおよびダイアログコントローラを介したアプリケーションの作成および配布のための企業ルール、ならびに進行中のユーザおよびシステムと動作中のアプリケーションとの対話のためのルールを提供する、ルールマネージャ（Ｒｕｌｅ  Ｍｇｒ．）を含む。ダイアログランタイムプロセッサ（Ｄｉａｌｏｇ  Ｒｕｎ  Ｔ．  Ｐｒｃｓｒ．）が提供され、音声アプリケーションの完成されたダイアログを起動しフォーマットする方法を制御するように構成される。フォンレットランタイムプロセッサ（Ｆｏｎｅｌｅｔ  Ｒｕｎｔｉｍｅ  Ｐｒｃｓｒ．）は、アプリケーションロジック２３０９内に提供され、音声アプリケーション（フォンレット）が実時間でどのように実行され構成されるかについての種々様々な態様を制御する。動的文法ジェネレータ（Ｄｙｎａｍｉｃ  Ｇｒａｍｍａｒ  Ｇｅｎ．）は、アプリケーションロジック２３０９内に提供され、非繰返しのダイアログコンテンツに関連する文法キーワードを生成し、ユーザが、動的な方法で即時の結果を取り出すために、その生成されたキーワードを話すことができるように構成される。
【０１８９】
サーバ２３０１のアプリケーションロジック内にある、以前には導入されていなかった新たなコンポーネントは、静的オプティマイザ２３１２と動的オプティマイザ２３１１である。本発明の目標は、ポータル２３０２および２３０３（ウェブ対応の場合）と音声アプリケーションサーバ２３０１との間のデータトラフィックの削減を最適にすることである。音声アプリケーションサ−バと音声ポータルとの間のデータトラフィックの削減を実現することは、コンポーネントが、相互に離れ、かつ比較的細いデータパイプラインによって接続されている場合には、特に重要である。このようなパイプラインは、動作中のピークパフォーマンス期間にはデータが停滞する可能性があり、音声ポータルにおける応答時間の顕著な遅延を引き起こす結果となり得る。オプティマイザ２３１２および２３１１、ならびにダイアログランタイムプロセッサに対するそれらの関係についての詳細は、本明細書の後で提供される。
【０１９０】
サーバ２３０１は、外部および内部データソースとインタフェースするために必要なモジュールのすべてを含む、データ／リソースアダプタブロック２３１０を含む。例えば、アプリケーションマネージャ（Ａｐｐ．Ｍｇｒ．）は、アダプタ２３１０の内部に提供され、ポータル２３０２および２３０３などのユーザエンドシステムへの主インタフェースモジュールとして構成される。アプリケーションマネージャは、発生順にダイアログの適切なデータ配布を提供し、本発明の好ましい実施形態では、ユーザのエンドシステムにとってローカルな１つまたは複数のキャッシュシステムに記憶するために、(最適化によって決定された)静的および動的ダイアログピースを配布する。アプリケーションマネージャの役割の詳細については後述する。
【０１９１】
レポートマネージャ（Ｒｅｐｏｒｔ  Ｍｇｒ．）は、アダプタ２３１０内に存在し、アプリケーションマネージャとともに動作して、音声アプリケーション対話の動作に関するレポート可能な統計を提供するように構成される。レポートマネージャは、フォンレット（音声アプリケーション）が完了するかまたは終了するまで、それを追跡する。本発明の方法においては、バックグラウンド統計を使用して、音声アプリケーションのどの動的（非繰返し）ダイアログピースを、ユーザ端末にローカルにキャッシュすべきかの決定を支援することができる。
【０１９２】
サードパーティウェブサービスプロバイダ２３１３は、この例ではサーバ２３０１の外部に示されているが、通信のためにサーバにリンクされている。サードパーティサービス２３１３は、サーバ２３０１内で動作する音声アプリケーション開発および配布サービスをうまく活用するために使用できるソフトウェアを含む、任意のサードパーティサービスプロバイダを表す。ユーザによって許可されたシンソフトウェアクライアントは、従来のウェブサイトを介してユーザからアクセス可能なウェブベースサービスと同様に、サードパーティアプリケーションに分類される。サードパーティ接続機能を容易にするために、サーバ２３０１は、サードパーティ機能へのサーバインタフェースとして構成されたウェブリソースコネクタ（Ｗｅｂ．Ｒｅｓ．Ｃｏｎｎ．）を備える。フォンレットイベントキュー（Ｆｏｎｅｌｅｔ  Ｅｖｅｎｔ  Ｑｕｅｕｅ）は、アダプタ２３１０内に提供され、サーバとサードパーティ提供リソースとの間の着信および発信フォンレット（音声アプリケーション）イベントをキューに入れるように構成される。フォンレットＸＭＬインタプリタ（Ｆｏｎｌｅｔ  ＸＭＬ  Ｉｎｔ．）は、アダプタ２３１０内に提供され、フォンレットイベントキューに着信する、またはそこから発信されるＸＭＬドキュメントを解釈するように構成される。
【０１９３】
リソースマネージャ（Ｒｅｓｏｕｒｃｅ  Ｍｇｒ．）は、アダプタ２３１０内に提供され、外部および内部両方のすべてのアクセス可能なリソースへのアクセスを管理するように構成される。内部リソースは、サーバ自体の内部またはサーバのドメインの内部で維持されることができ、ドメインには、例えば、音声アプリケーションサーバを動作させるコンタクトセンタの内部にある内部データシステムなど、ドメイン内部と見なすことができる他のシステムが含まれることに留意されたい。データベースアクセスマネージャ（Ｄａｔａｂａｓｅ  Ａｃｃｅｓｓ  Ｍｇｒ．）は、アダプタ２３１０内に提供されており、サーバ２３０１のドメインの内部に提供され、かつサーバ２３０１のドメインの内部に置かれたデータストアと関連付けられた、永続データ記憶装置からのデータの取り出しを容易にするように構成される。
【０１９４】
ＶＸＭＬレンダリングエンジン２３１４は、アプリケーションサーバ２３０１内に提供され、ＶＡＤＳ２３０８内のダイアログコントローラと連動してＶＸＭＬページを提供するように構成される。レンダリングエンジン２３１４は、前述の図２２および図６に関連して説明したエンジン１１１に類似している。
【０１９５】
サーバブロック２３１０、２３０９、２３０８およびエンジン２３１４は、相互に通信しかつ協働する。通信および協働機能は、この例では、通信のためにブロックを接続する論理サーババス構造２３１５によって示されている。類似の論理バス構造２３１６が、ポータル２３０２内に示されており、通信のために内部コンポーネントを接続している。
【０１９６】
先に説明したように、音声アプリケーションは、起動された後で、静的および動的両方の結果を生成する一連の対話ダイアログピースを含む。例えば、すべての発呼者に対して再生される会社の挨拶は、各発呼者ごとにダイアログに動的な変化がないので、静的な挨拶と見なされる。しかし、株価情報を求めるユーザ要求に対するダイアログ応答は、その応答が、発呼者ごとに要求に応じて変化し得るので動的だと見なされる。同様に、応答ダイアログに組み込まれる、データベースまたは他の外部データソースから呼び出された結果のデータは、ダイアログそれ自体が動的であると見なされる。なぜならば、基本となるテンプレートは静的であるが、組み込まれた結果は、発呼者ごとに異なる可能性があるからである。
【０１９７】
静的オプティマイザ２３１２および動的オプティマイザ２３１１は、ダイアログランタイムプロセッサと協働して動作するように提供されて、関連する音声アプリケーションとの対話の間のローカルアクセスのために、エンドシステムのキャッシュ記憶装置に配布すべきダイアログのピースを識別する。オプティマイザ２３１２および２３１１は、ダイアログファイルの最初の実行の間に、または関連する音声アプリケーションが修正されたときに、ダイアログファイルを監視しかつ読み出すソフトウェアモジュールである。静的オプティマイザ２３１２は、ルールマネージャと協働し、ビジネスルールに従って、静的だとラベル付けすることができる特定のファイル、すなわち発呼者ごとに変化しない繰返しファイルにタグを付ける。動的オプティマイザ２３１１は、ルールマネージャと協働し、ビジネスルールに従って、発呼者ごとに繰り返されることはないが、関連する音声アプリケーションにアクセスするためのエンドシステムのローカルなキャッシュに、分散キャッシュすることを正当化するのに十分なほど頻繁に繰り返される特定のファイルにタグを付ける。
【０１９８】
一実施形態では、オプティマイザ２３１２および２３１１は、ダイアログランタイムプロセッサ内で動作する組み込みモジュールである。他の実施形態では、オプティマイザは、ランタイムプロセッサが特定の音声アプリケーションに関するダイアログを処理するときに、起動する別個のモジュールである。
【０１９９】
管理者が音声アプリケーションを変更するとき、または新規の音声アプリケーションが作成されるとき、アプリケーションフローからどのデータをキャッシュする必要があるかを決定するために、オプティマイザ２３１１および２３１２の最適化処理が呼び出される。タグ付けは、当技術分野で知られている様々なファイル識別方法の形をとることができる。好ましい実施形態では、標準のＨＴＴＰ１．１タグ方式が、使用される。最適化コンポーネント２３１２および２３１１は、タグ付けされていないファイルにタグを追加するか、または、場合によってはすでにタグ付けされているファイルからタグを削除することができる。この自動化された処理により、管理者は、サーバ間のデータトラフィックに関連する配布問題を心配することなしに、ダイアログを生成することができる。
【０２００】
静的ファイルについては、オプティマイザ２３１２は、エンドシステムでどのファイルをキャッシュすべきかを識別し、それらに適切にタグ付けし、タグ付けされたファイルを識別されたエンドシステムキャッシュに配布する準備をする。ポータル２３０２がエンドシステムの場合は、音声アプリケーションの静的ファイルは、ブロック２３０５のサーバキャッシュにローカルに格納されることになる。一実施形態では、配布された静的ファイルは、最近修正された音声アプリケーション、または新規の音声アプリケーションの最初の配布でキャッシュされる。最初の対話の間に静的ファイルがキャッシュされるという事実により、アプリケーションにアクセスする最初の消費者は、最適パフォーマンスが得られないことになる。しかし、ポータル２３０２からアプリケーションにアクセスするその後の消費者、またはアプリケーションの静的部分を繰り返す最初の発呼者は、パフォーマンスの向上を経験することになる。なぜならば、電話サーバは、ダイアログが要求されるたびに、アプリケーションサーバ２３０１からそのダイアログを取り出すのではなく、ローカルキャッシュにアクセスし、そこからアプリケーションの静的部分を供給するからである。ここで、好ましい実施形態では、静的および動的コンテンツのキャッシュが、一時的なものであることに留意されたい。すなわち、音声アプリケーションが、もはや企業によって使用されなくなったとき、または新しいアプリケーションと置き換えられたときは、不要になったファイルは、キャッシュシステムから削除される。
【０２０１】
音声アプリケーションの静的ダイアログが、ポータル２３０２の電話サーバ部に配布され、その内部にキャッシュされた後で、関連する音声アプリケーションとのその後の対話の間のその後の取り出しのために、それらはキャッシュ内に保持されることができる。しかし、管理者によってその後に音声アプリケーションが修正され、次いで異なるダイアログが、静的キャッシュ可能なダイアログとして識別された場合には、すでにキャッシュされているダイアログは、新規に更新された静的ダイアログで置き換えられることになる。識別および改訂方法についての任意の共通形式を使用して、適切な静的ファイルを同期させることができる。いくつかのダイアログは、修正されたアプリケーションから単に削除でき、他の静的ダイアログは、新たに追加されることができる。静的だと見なされる新規の、または削除された、または修正されたファイルの存在に関して、その後にアプリケーションを修正する場合には、これらのファイルとすでに格納されているファイルとの同期は、アプリケーションのエンドシステムへの配布予定の前に、またはアプリケーションのランタイムの間に実施することができる。
【０２０２】
本発明の好ましい実施形態では、動的ファイルのキャッシュは、ポータル２３０２の電話ソフトウェア／ハードウェアブロック２３０５内部にある音声ウェブコントローラモジュールで実施される。動的ファイルは、各実行の間および音声アプリケーションとの対話の間に取り出しを行う必要がないので、静的ファイルとは異なっている。したがって、動的取り出しは、音声アプリケーションとのユーザ対話が始まった後だけに行われる。音声アプリケーションサーバ２３０１で統計解析を使用して、どのファイルをエンドシステムキャッシュ装置に配布し続ける意味があるか、また、場合によっては動的最適化のために、すでにキャッシュされているどのファイルを削除し、その後エンドシステムのローカルアクセスから削除すべきかなど、いくつかの音声アプリケーションの配布に関する決定を行うことができる。
【０２０３】
図２４は、本発明を実施するためのステップを示す処理フロー図である。ステップ２４００ａで、「ＸＹＺ社にお電話を頂き、ありがとうございました」など、静的な挨拶メッセージが再生される。このダイアログを含む音声アプリケーションが、エンドシステムからアクセスされた後で、特定のダイアログが、静的なダイアログであると識別された場合には、このダイアログはローカルに格納される。同じ音声アプリケーションに対するその後のアクセスがなされるたびに、挨拶２４００ａは、命令されたときにステップ２４０１でローカルキャッシュから取り出される。
【０２０４】
ステップ２４００ｎで、この実施形態では、メニューメッセージを表す最後の静的メッセージが再生される。この例において、要素割当て２４００ａ〜ｎによって示された、音声アプリケーションの複数の静的ダイアログが存在してもよいことを理解されたい。音声アプリケーション実行時に、静的メッセージ２４００ａ〜ｎのいずれかが要求されるたびに、そのメッセージは、ステップ２４０１でローカルキャッシュから引き出される。ステップ２４００ｎで再生されるメッセージは、対話の準備のためのものであり、例えば「メニューを変更しました。注意深くお聞きください。あなたの通話は、トレーニングの目的で録音されることがあります。」などと再生される。
【０２０５】
メッセージ２４００ａ〜ｎは、例えばＩＶＲ対話の最初の部分で、発呼者が誰であるかにかかわらず再生されるので、それらのメッセージは、アクセスされたエンドシステムまたはアプリケーション消費者を表す電話サーバの内部に静的にキャッシュすることができる。上述のように、ＨＴＴＰ１．１標準タグを使用して、どの材料をキャッシュすべきかを指示することができる。ローカルサーバは、静的ファイルを格納しておき、呼出しが、その特定の音声アプリケーションの電話番号または内線に着信したときはいつでも、適切なアプリケーションフローに従ってそれらのファイルを使用することができる。場合によっては、単一の連絡先番号に音声アプリケーションが多数存在し、内線を用いて発呼者によるアクセスごとにそれらを分離している。
【０２０６】
静的コンテンツのローカルキャッシュがない場合は、一般に電話サーバは、ウェブコントローラに要求をすることになり、次いでウェブコントローラは、ランタイムプロセッサに要求を送信し、ダイアログランタイムプロセッサからメッセージを取り出す。音声ファイルは、プロセッサから同じネットワーク接続を介して電話サーバに返信され、即時に再生される。動的対話音声アプリケーションのダイアログ部分をローカルキャッシュすることにより、ポータルとアプリケーションサーバとの間の帯域幅が大幅に節約されることが理解されよう。エンドシステムにローカルキャッシュすることができる他の種類の静的ダイアログの例には、操作時間、位置または駆動命令、請求先アドレスなど、本質的に動的に変化しないものが含まれる。
【０２０７】
ステップ２４０２で、ユーザは、ステップ２４００ｎのメニューオプションダイアログの選択結果を起動することによって、音声アプリケーションと対話する。ステップ２４０３ａで、動的メニューオプションまたは結果が再生される。オプションまたは結果は、以前の静的ダイアログに対するユーザ起動の選択または対話の結果として取り出される。したがって、ユーザが聞く次のダイアログは、非繰返しまたは動的と見なされる。このことは、呼出しごとに結果またはメニューオプションの内容が変化し得ることを意味し、音声アプリケーションとの最初のユーザ対話によって変化が指示されることを意味する。
【０２０８】
特定の音声アプリケーションにアクセスするエンドシステムのローカルキャッシュに、ダイアログを配布すべきか否かを決定するルールは、コンテンツ、可能なオプションまたは結果の数、および場合によっては統計的確率などによって変化する可能性がある。例えば、音声アプリケーションが、金融機関向けに作成され、動的メニューが融資担当者、通常の窓口係、または自動顧客案内係に転送するオプションを含み、統計的にすべての発呼者の９０％が、自動案内係への転送を選択する場合には、自動銀行業務に関する音声アプリケーションの後続の開始ダイアログは、ローカルにキャッシュすることができる。この場合、最初の２つのオプションは、直接の接続を必要とするので音声アプリケーションは終了する。第３のオプションは、同じアプリケーションの別のダイアログ、またはまったく別のアプリケーションにリンクされる。したがって、次のダイアログは、単に発呼者に識別基準（identification  criteria）を入力するように求めるだけなので、静的にすることができる。このダイアログは、「自動案内係」を選択したすべての発呼者に対して同一のダイアログになる。
【０２０９】
動的最適化の評価基準は、様々に変化する可能性があることに留意されたい。例えば、標準ダイアログテンプレートに組み込まれる個人情報結果は、機関のデータソースから取り出す必要があり、ローカルにキャッシュすることはできない。しかし、結果的に個人情報のデータフェッチに帰着する対話を求める標準メニューは、ローカルにキャッシュすることができる。
【０２１０】
動的キャッシュに割り当てられるダイアログは、そのダイアログが選択されるたびに、ステップ２４０３でウェブコントローラから取り出される。さらに、ステップ２４０２は、動的にキャッシュされたダイアログの間で繰り返し行われる可能性がある。ステップ２４０３ｎで、音声アプリケーションシーケンス中の最後の動的メニューオプションが再生される。統計的には、ごく僅かなユーザだけが、音声アプリケーションの最後、すなわち最後のメニューまで進む可能性がある。したがって、そのメニューは、ローカルキャッシュと見なされないことがある。しかし、多くの発呼者が、そのオプションまたは結果を要求する可能性が高い場合には、多くの標準的な動的オプションおよび結果を、動的にキャッシュすることができる。
【０２１１】
おそらくは製品の所望のモデルや型など、一般的には変わらない結果も、動的な結果になる。なぜならば、対話メニューとの対話による戻りとして使用可能な他の結果が存在するからである。最も一般的な結果は、すべての発呼者が同じ結果と対話するとは限らない場合でも、ローカルに取り出すことができるダイアログとして動的にキャッシュされることができる。オプティマイザは、図２３のアプリケーションサーバに関連して説明した他のすべてのモジュールとデータベースへのアクセシビリティを共有する。したがって、完全に静的であるという訳ではないが、一般的に要求される結果を、ダイアログテンプレートの中に組み込まれ、同じアプリケーションの以前のダイアログに対する応答としてなされた、特定の選択にリンクされた音声アプリケーションダイアログとしてローカルに保存されることができる。
【０２１２】
動的キャッシュの場合は、動的な組み込まれた結果なしの標準のダイアログが存在する場合がある。この場合、プロキシとして音声アプリケーションサーバを使用して要求されたデータを取り出し、ローカルにそのデータをテンプレートに組み込むクライアントアプリケーションを、ユーザに提供することができる。その場合、ユーザが、データにアクセスしかつアプリケーションに進んだ後で、埋め込まれたデータは、次の呼出しまでテンプレートから削除される。多くの可能性が存在する。
【０２１３】
本発明の方法および装置が、内部データソースおよび外部データソースの両方のアクセスに適用可能であり、外部データソースの一部が、ウェブ上に存在するデータ、および他の種類のデジタルデータネットワーク上で使用可能なデータなど、ネットワークベースのデータソースであることは当業者には明らかであろう。
【０２１４】
テキスト音声変換の前処理
本発明の一態様では、本発明の音声アプリケーションシステムの拡張として、テキスト音声変換プリプロセッサが提供される。本発明の方法および装置については、以下で詳細に説明する。
【０２１５】
図２５は、本発明の一実施形態による、テキスト音声変換プリプロセッサ２５０１で拡張された図２３のＶＸＭＬアーキテクチャのブロック図である。この例には、ＶＸＭＬアーキテクチャ２５００が示されている。このＶＸＭＬアーキテクチャ２５００は、先に図２３に関連して説明したＶＸＭＬアーキテクチャ２３００に類似している。この例では、ＶＸＭＬアーキテクチャ２５００は、社会経済的な人口統計（demographics）、業界固有の用語、および地域的な人口統計に基づくルールに従って、語句の特殊な音声発音を提供する機能を用いて拡張されている。
【０２１６】
この例には、上記図２３に示されたすべてのコンポーネントも図示されている。したがって、本発明の結果として、先に説明済みで修正されていないコンポーネントについては、同じ要素番号を維持するものとする。音声アプリケーションサーバ２３０１は、図２３に関して説明済みのサーバ機能を提供するソフトウェア機能ブロック２３１４、２３０８、２３０９、および２３１０を含む。
【０２１７】
先に説明したように、ＶＸＭＬページが作成され、音声アプリケーションに組み込まれる。音声アプリケーションは、個々のＶＸＭＬページが、動的コンテンツを含むことができ、発呼者対話の実行中に生成されるという意味で動的である。音声アプリケーション開発ソフトウェアにより、管理者は、リモートステーションからテンプレートを用いて音声アプリケーションを作成し、それらを配布のためにスケジューリングすることができるようになる。場合によっては、消費者はプル方式でアプリケーションにアクセスすることができる。他の例では、音声アプリケーションは、プッシュされるアウトバウンドアプリケーションとして配布される。サーバ２３０１で作成された音声アプリケーションの配布には、ユニキャスト、マルチキャスト、およびブロードキャスト方式を含めることができる。
【０２１８】
好ましい実施形態では、音声アプリケーションダイアログは、電話／音声ポータル２３０２および／またはウェブポータル２３０３などのポータルに、ＶＸＭＬページの形で送信される。サーバ２３０２では、ＶＸＭＬインタプリタ２３０７が、ＶＸＭＬを合成音声に変換し、次いでその合成音声は、この場合は電話ハードウェアブロック２３０５によって発呼者に話される。同様に、発呼者からの応答は、取り込まれ、かつアプリケーションサーバでの解釈のためにＸＭＬとして表現される。アプリケーションサーバは、解釈された応答内容に従って、発呼者に対する次のダイアログとして送信される新しいＶＸＭＬページを作成する。実施されたデータフェッチはいずれも、次のＶＸＭＬレンダリングまたはダイアログに含められるフェッチデータをもたらす。
【０２１９】
テキスト音声変換（ＴＴＳ）プリプロセッサ２５０１は、アプリケーションサーバ２３０１のブロック２３０９内に提供される。ＴＴＳ２５０１は、ＶＸＭＬページまたはダイアログに含めるために、オプションのテキストレンダリングのどれを選択するのかを処理する、特殊な命令セットを含むダイアログのテキストストリームを前処理するように構成される。ＴＴＳプリプロセッサ２５０１は、方向矢印によって示されるように、ランタイムダイアログプロセッサに接続される。ダイアログランタイムプロセッサが、企業ルールに従って、通常のＶＸＭＬレンダリングのためにテキストダイアログを処理する前に、ＴＴＳプリプロセッサ２５０１は、一般に音声アプリケーションと対話する発呼者である音声アプリケーション消費者について知られている情報に従って、テキストダイアログに注釈を付ける。知られている情報は、場所、地域、好み、教育水準など、発呼者について予め知られている情報のことがある。知られている情報はまた、発呼者回線識別（ＣＬＩＤ）および他の接続識別機構によって、また発呼者との直接対話を通して対話中の発呼者の応答を分析することによって、対話時に発呼者から収集された情報のこともある。
【０２２０】
ＴＴＳプリプロセッサ２５０１は、様々なテキストレンダリングのオプションを含む、テーブル（図示せず）として実施された動的ヒットリストにアクセスすることができる。各レンダリングは、発呼者、発呼者の地域、人口統計的情報、および／またはトランザクションもしくはシナリオの種類と関連付けることができる、１つまたは複数の条件に関連付けることができ、またその条件に従って実際に作成することができる。ＴＴＳプリプロセッサ２５０１は、発呼者から収集された情報および／またはその発呼者に関して事前に知られていた情報を、１つまたは複数のルールまたはルールセットと照合し、次いでそれに従ってＸＭＬ応答ストリームに注釈を付ける。この実施形態における注釈付けとは、応答の特定のテキスト部分を、テーブル中に示された様々なテキストオプションから選択することを意味する。レンダリングの結果得られたＶＸＭＬページは、注釈が付けられたＸＭＬ命令に従って、発呼者端で音声生成を指示する。したがって、実際に発呼者が聞く合成音声は、同じ音声アプリケーションを使用する発呼者の間で異なることがあり得るという意味で動的である。
【０２２１】
ＴＴＳプリプロセッサ２５０１は、ルールマネージャ（Ｒｕｌｅ  Ｍｇｒ）にアクセスすることができる。ルールマネージャは、発呼者と企業との間の音声対話として生ずる特定のトランザクションに関連した「ヒットリスト」を提供する。例えば、発呼者が、フロリダの特定の郡に位置し、特定の州ハイウェイへの道案内を望んでおり、基本的にそのハイウェイの名前が、そのサービスによってカバーされる複数の位置で使用されている場合には、ＴＴＳプリプロセッサ２５０１は、発呼者の特定の位置を考慮して、ＶＸＭＬレンダリングのためのテキスト応答に注釈を付けることになる。次にルールは、発呼者の観点から、ローカルに使用される特定のハイウェイ名に応答を制約する。おそらく、フロリダの北部の郡では、ハイウェイ名は「州道２５号線」であり、フロリダの南部の郡では、２５号線は、主に「ビーンメモリアルフリーウェイ（Bean  Memorial  Freeway）」と呼ばれている。発呼者の位置が南部の郡だと想定すると、ＶＸＭＬインタプリタ２３０７で解釈されて生成される応答には、「州道２５号」ではなく「ビーンメモリアルフリーウェイ」と発音するための命令が含まれることになる。
【０２２２】
業界固有の用語、適切な場所の名前、道路の名前などに関連する様々なテキスト変化は、例えばサービス提供企業によって収集され、アプリケーション依存の応答オプションに集約され、上述のようにテーブル化され、次いで発呼者との音声対話の各セッションごとに情報対ルールセットのマッチングに従って動的に選択される。したがって、同一の音声アプリケーションによって、そのアプリケーションを使用する特定の発呼者ごとに合わせ込まれた動的応答を配布することが可能になる。
【０２２３】
図２６は、テキスト文字列の音声レンダリングの可能な変化を示すブロック図である。この例では、テキスト音声変換レンダリングの様々な可能性が、標準テキストブロック２６００として示された標準フリーウェイエンティティである「ＨＷＹ  １０１」に対して示されている。テキスト音声変換オプション２６００ａは、そのレンダリングを、発音上「ハイウェイワンハンドレッドアンドワン（Highway  one  hundred  and  one）」と発声するよう音声ジェネレータに指示する。テキスト音声変換オプション２６００ｂは、引用符内の各文字、「Ｈ」「Ｗ」「Ｙ」「１」「０」「１」を明確に発音するよう音声ジェネレータに指示する。これは、音声的には「エイチダブルワイワンゼロワン（aich  doubleu  why  one  zero  one）」のように聞こえるのかもしれない。
【０２２４】
テキスト音声変換レンダリング２６００ｃは、レンダリング２６００ｂに対して上で説明したのと同様に、「Ｈ」「Ｗ」「Ｙ」と明確に発音するように音声ジェネレータに指示するが、「ワンゼロワン（one  zero  one）」の代わりに「ワンハンドレッドアンドワン（one  hundred  and  one）」と異なる発音を指示する。テキスト音声変換レンダリング２６００ｄは、レンダリング２６００ａと同様に「Highway」と発音するように音声ジェネレータに指示するが、異なる形で「１  oh  １」と指示している。これは、音声的には「ワンオーワン（one  oh  one）」のように聞こえるのかもしれない。この図で示された変形は、標準のエンティティである「ＨＷＹ１０１」が、どのように原文として変形されて、発呼者に互いに異なって聞こえる様々な音声ダイアログを生成するのかを示す、単なる一例である。どのレンダリングを適用すべきかの選択は、予め知られた、または場合によっては実時間で発呼者から収集された発呼者についての情報によって決まる。
【０２２５】
本発明の一実施形態では、ダイアログオプションに対する応答である最初の音声イニシエーション（voice  initiation）の発音または「ゆっくりした話しぶり（drawl）」傾向が分析される場合がある。例えば、発呼者が、実際にひどい訛りと分類された場合は、その発呼者に対するダイアログ応答は、発呼者のアクセントまたは方言を真似るように合成されることができる。対話の間に方言を真似ることの利点は、発呼者に、システムの使用をより気楽なものに感じさせることである。例えば、ニューヨーク市のいくつかの地域では、地域住民は、その地域で知られているランドマーク（landmark）としてある種のスラングを使用する。スラングが企業によって予め知られている場合には、スラングを使用する発呼者に対するダイアログ応答にそのスラングを使用することができる。さらに、ある種の業界用語は、業界ごとに異なる意味を持つことがある。複数の業界に関連するダイアログを提供するサービスにおいて、発呼者が、ある特定の業界の発呼者であると識別された場合には、発呼者への応答において適切な用語を動的に適用することもできる。
【０２２６】
図２７は、本発明の一実施形態により構成されたマッピングテーブル２７００を示すブロック図である。テーブル２７００は、図２３のＴＴＳプロセッサ内、またはそのプロセッサからアクセス可能な外部データストア内に提供されるソフトウェアテーブルを表す。テーブル２７００は、テキスト音声変換レンダリングおよびそれらに関連して作成された音声ファイルへのリンクを含むヒットリストである。
【０２２７】
テーブル２７００は、テキスト音声変換エンティティＴＳ−１からＴＳ−５の選択を含む列２７０１を備える。テキストエンティティＴＳ−１からＴＳ−５は、構造的には先に図２６に関連して説明したエンティティ２６００に類似している。すなわち、ＴＳエンティティは、業界用語、場所名、幹線道路、州道、ランドマークなど、基本的に識別可能な用語に対応している。テーブル２７０２は、音声表現またはテキスト音声変換レンダリング１〜６をリストする列を含む。音声表現１〜６は、列２７０１に含まれているアイテム（ＴＳ−１〜５）に対応する予め準備されたテキストレンダリングである。ＨＴＴＰ１．１または他の種類の参照リンク（矢印）は、この図ではその複数が要素番号２７０３によって示されているが、列２７０１の各アイテムを列２７０２の少なくとも１つのアイテムにリンクする。
【０２２８】
この例では、テーブル２７００のＴＳエンティティの１つだけが、複数の変更テキスト音声変換レンダリングにリンクされる。ＴＳ−５は、例えば「ＨＷＹ  １０１」であり、音声表現５および音声表現６にリンクされる。音声表現５は、カリフォルニア州ロサンゼルスのエリアで使用される「ＨＷＹ  １０１」の適切な発音を指示し、一方、音声表現６は、サンフランシスコのベイエリアで使用される「ＨＷＹ  １０１」の適切な発音を指示する。もちろん、エンティティＨＷＹ  １０１が、地域によって様々に話されるものと想定されている。表現５および６は、図２６のテキストレンダリング２６００ａ〜ｄに類似したものである。したがって、表現５および６は、アプリケーション消費者または発呼者の地理的出所（geographic  origin）のルールに基づいて、選択可能なオプションであるＸＭＬテキストレンダリングである。
【０２２９】
この例では、（可聴音声ダイアログ応答を生成する）実際の音声合成は、表現５または６の一方を含むＶＸＭＬページによって提供される指示に基づいて、発呼者端（音声ポータル）で実施されることが想定されている。一実施形態では、音声ファイルは、管理者によって予め準備され、アプリケーション配布スキームの一部としてエンドシステムに配布される。この場合、予め録音された音声ファイル、この場合は５または６が、受信した表現の解釈に基づいて選択される。
【０２３０】
テーブル２７００は、一般的なテンプレートとして構成され、実行される音声アプリケーションに応じて、アプリケーション配布時に、そのアプリケーションによって使用される適切なエンティティおよびテキスト表現オプションにアクセスし、それを取り込むことができるという意味で、動的なテーブルのことがある。ユーザが音声アプリケーションと対話するとき、ＴＴＳプリプロセッサ２５０１は、取り込んだテーブルにアクセスし、アプリケーションと対話する現在の発呼者について予め知られている情報、またはその発呼者によって提供された情報に基づいて、どのＴＴＳ表現を選択すべきかを決定する。
【０２３１】
本発明の一実施形態では、ある音声アプリケーションとの対話が、関係のない内容を含む他の音声アプリケーションの配布を起動する場合は、最初のアプリケーションとの対話から収集される場合もある発呼者に関する情報は、自動的に第２のアプリケーションのドメインに送られて、新しいコンテンツオプションに関連する第２のテーブルの作成に使用される。ここで、単一の音声アプリケーションに関連するコンテンツ固有のテーブルは、処理コンポーネントからアクセスできるシステムデータベースに格納されたデータのマスタテーブルから実行時に作成することができることに留意されたい。
【０２３２】
企業によって開発された音声アプリケーションを使用して、企業から発呼者に送信される自動音声応答を個人に合わせ込む（personalize）機能により、従来の単調でユーザ同一のコンピュータ応答から機能拡張された対話経験が、発呼者に提供される。このような機能拡張は、より理解されやすい有用で実用的な「変換」を発呼者に提供するばかりでなく、このような音声アプリケーション配布システムのより頻繁な使用を促すもてなし価値を提供する。
【０２３３】
挙動状態の適応
図２８は、本発明の一実施形態による、挙動適応エンジンで拡張された図２５のＶＸＭＬアーキテクチャのブロック図である。この例には、ＶＸＭＬアプリケーション配布アーキテクチャ２８００が示されており、このアーキテクチャは、先の図２５の記載に関連して説明したＶＸＭＬアーキテクチャ２５００に類似している。前に説明した各コンポーネントについては、上記図２３および図２５の説明で導入されたそれらの元の要素番号を維持している。アーキテクチャ２８００は、アプリケーションサーバ２３０１、電話サーバ／音声ポータル２３０２、およびウェブポータル２３０３を含む。
【０２３４】
音声アプリケーションサーバ２３０１は、挙動適応エンジン２８０１で拡張されている。挙動適応エンジン２８０１は、音声アプリケーションダイアログとの対話の間のユーザ挙動状態の差異を見分け、場合によっては、感情状態の差異を見分けるように構成される。エンジン２８０１は、アプリケーションロジックブロック２３０９の一部であり、アプリケーションロジックブロック２３０９は、前述のテキスト音声変換プリプロセッサ２５０１を含む。静的オプティマイザ２３１２および動的オプティマイザ２３１１については、先に図２３の説明に関連して説明済みであり、図面スペースを確保するためにこの例には示されていないが、存在しているものと想定することができる。
【０２３５】
適応エンジン２８０１は、この図で双方向矢印によって示されるように、ダイアログランタイムプロセッサ（Ｄｉａｌｏｇ  Ｒｕｎｔｉｍｅ  Ｐｒｃｓｒ.）に直接アクセスすることができる。適応エンジン２８０１は、ロジックバス構造２３１５を介してＶＸＭＬレンダリングエンジン２３１４、音声アプリケーション開発ソフトウェア（ＶＡＤＳ）ブロック２３０８、およびデータベース／リソースアダプタブロック２３１０に通信アクセスすることもできる。
【０２３６】
対話は、本発明の音声アプリケーションソフトウェアを用いて発呼者と企業との間で行われるので、発呼者端で発呼者によって発音されるメニューオプションなどへの応答は、好ましい実施形態では、ＸＭＬベースのテキストとして提供され、音声アプリケーションサーバ２３０１で解釈されて、発呼者に配布される次の応答が決定される。この場合、企業からの応答は、発呼者ごとに異なる可能性があり、発呼者によって使用されるポータル、この場合はポータル２３０２またはウェブポータル２３０３で、音声合成するためにＶＸＭＬ（ＶＸＭＬページ）として提供される。
【０２３７】
適応エンジン２８０１は、対話の間に発呼者からのＶＸＭＬ応答をインターセプトし、応答オプションにリンクされた挙動制約セットに従って、応答を分析するように構成される。次いで、応答オプションが選択され、ＶＸＭＬ応答に組み込まれる。ＶＸＭＬ応答は、合成音声として発呼者に向けて再生される。
【０２３８】
適切かつ正確なＶＸＭＬページ応答の決定のために存在し得る挙動制約の種類に制限はない。例えば、ユーザは、繰り返し使用により音声アプリケーションメニューの特定のセットに非常に精通していることがある。このようなユーザは、メニューレンダリングの間に、メニューツリーのずっと下方にある特定のオプションを、メニュー中のそのオプションに到達する前に選択する傾向がある。したがって、この特定のユーザの挙動は、そのユーザがサービスにアクセスするたびに、ほぼ毎回特定のサブオプションを発声するということになる。この場合、適応エンジン２８０１は、提供される前に選択を認識し、この特定のユーザが、サービスおよびメニューツリーに非常に精通していると判断する。同じユーザが次回サービスを呼び出したときは、メニューナビゲーションを飛ばして、適切な結果を即座にユーザに提供することができる。上記でカバーされる挙動の種類は、メニューナビゲーション挙動である。
【０２３９】
ケースバイケースで決定することができる他の種類の挙動は、発呼者のストレスの程度である。エンジン２８０１は、応答内容を分析することによって、特定の発呼者のストレスレベルを決定することができる。好ましい実施形態では、エンジン２８０１によって、２つの形式の応答内容を分析することができる。それらは、ＶＸＭＬテキストベースの内容と、ＶＸＭＬドキュメントにアタッチメントとして添付された音声サンプリングである。例えば、音声アプリケーションと対話している間に、発呼者が特定の罵り言葉または「否定的な」言葉を発した場合は、それらを認識し提供することができる。適応エンジンは、ルールマネージャなどの外部リソース、およびアダプタブロック２３１０を介して外部データストアにアクセスすることができる。
【０２４０】
一実施形態では、適応エンジン２８０１は、ＸＭＬベースのテキストファイルとともに送信されることができる、短いＷａｖファイルまたは他のデジタル音声ファイルを分析することができる。このようにして、発呼者のストレスレベルを決定することができ、次いで決定されたレベルに基づいて応答選択を決定することができる。例えば、発呼者が、予め設定された閾値を越えるデシベルレートで発声した場合には、その発呼者は叫んでいると判断することができる。デシベルレートは、対話セグメントの始まりで録音され、次いで発呼者応答のテキストレンダリングとともにアタッチメントとして送信される、短い１〜２秒のオーディオファイルから分析されることができる。
【０２４１】
エンジン２８０１によってメニューナビゲーションの速度を測定して、発呼者が、企業の特定のシステムに関して有している経験のレベルを概略で判定することができる。その後のメニューおよびサブオプションは、特定の発呼者の「経験レベル」の判定結果に基づいて注釈を付け、削除し、または追加することができる。考慮することができる多くの挙動考慮事項が存在する。
【０２４２】
適応エンジン２８０１は、対話の間に、ＴＴＳプロセッサ２５０１および前述のオプティマイザと協働して、発呼者へのＶＸＭＬページとして後続のレンダリングのためのメニューおよびオプション選択を微調整するロジックとして提供されることができる。実施形態によっては、制約で許されている場合には、エンジン２８０１は、他のダイアログ拡張ツールをオーバライドすることができる。例えば、発呼者が非常に動揺している場合には、その後の音声アプリケーションダイアログは、ライブエージェントに直接接続するオプションを提供して、発呼者の懸案事項を即時に解決することができる。
【０２４３】
図２９は、本発明の一実施形態による、図２８のシステムとのユーザ対話を示す処理フロー図である。ステップ２９００で、ユーザは、音声アプリケーションにアクセスする。音声アプリケーションには、任意の音声対応ポータルを介してアクセスすることができる。場合によっては、ユーザが、音声アプリケーションを呼び出す。他の実施形態では、音声アプリケーションが、ユーザを呼び出し、ユーザは単にその呼出しを受信する。一部メディアサポートに応じる他のアプリケーションでは、音声アプリケーションは、ユーザへのブロードキャストまたはマルチキャストのこともある。ステップ２９００で、挨拶およびユーザ識別処理またはメニューを実行することができる。識別には、音声インプリント識別（voice  imprint  identification）などのバイオメトリック機能、またはパスワード／ＰＩＮオプションなどを含めることができる。
【０２４４】
ステップ２９０１で、ユーザに対して最初の発信メニューが再生される。このメニューは、ユーザに配布される動的音声アプリケーションに関する最初の対話メニューである。アプリケーションが、対話型音声応答（ＩＶＲ）システム上で実行される場合は、音声とタッチトーン応答の組合せを、ユーザ応答として受け取ることができるが、この例では音声応答に注目する。この例の処理では、ステップ２９０１で提供されたメニューをナビゲートする間に、ユーザのナビゲーション挙動に関連する制約が存在するものと想定する。例えば、ステップ２９０１のメニューが終了する前に、ステップ２９０２で、ユーザが、メニューまたはサブメニューオプションを音声によって応答した場合は、ステップ２９０３で、図２８に関連して説明したエンジン２８０１に類似した適応エンジンが、その応答を分析する。
【０２４５】
ステップ２９０３で、応答のインターセプトを起動することもできるし、アプリケーションの間にそれを継続することもできる。メニューが終了する前にユーザが応答した場合は、メニューのために割り当てられた時間が、終了する前に応答が着信したという事実を、適応エンジンによるインターセプトの起動要因にすることができる。ステップ２９０３で応答を分析することには、その応答を、ステップ２９０４で適切な応答オプションまたは結果と照合することを含めることができる。適応エンジンは、メニューナビゲーションによってサブオプションが使用可能になる前に、特定のサブオプションに関するユーザの選択を十分に反映する記録を作成しかつ格納することができる。この場合、エンジンは特定の発呼者を、そのシステムに「習熟している」とラベル付けすることができる。このことは、その発呼者が、特定のサブオプションを記憶しており、返す結果を迅速に処理できることを意味する。
【０２４６】
ステップ２９０５で、分析された発呼者のメニュー応答に対する応答として選択された、最もよくマッチする応答オプションが返され、ステップ２９０６で、存在する場合には、再生すべき次のメニューオプションに関する決定がなされる。企業からの選択された応答に、ユーザによって要求された、組み込まれた結果を含むダイアログが含まれている場合には、それ以上のメニュー動作または対話が存在しない場合もある。ステップ２９０２の発呼者要求が、特定のメニューに対する要求を含む場合は、ステップ２９０７で、選択されたメニューオプションが、ＶＸＭＬページレンダリングのために組み込まれる。その間に、ステップ２９０８で、通常は音声アプリケーションの一部である不要なメニューが捨てられ、ユーザには送信されない。
【０２４７】
習熟していないユーザの場合には、おそらくはステップ２９０１が最後まで再生されてから、ユーザはステップ２９０９で選択を行うことになる。ステップ２９１０で、適応エンジンは、ユーザが「習熟していない」という記録を格納することができる。いずれにしても、エンジンは、（そのように構成されている場合には）ユーザ応答をインターセプトして分析し、ステップ２９０４に記述されるように、既存の企業ルールに従ってユーザ応答を企業応答オプションと比較する。やはり上述したように、ステップ２９０５で、企業応答に最もよくマッチしたオプションが返される。ステップ２９１１で、存在する場合には、次の順序のメニューオプションを再生するか、または企業応答ダイアログに組み込まれたフェッチされた結果を、ステップ２９１１で再生することができる。
【０２４８】
上記に概説した処理において、ユーザが、メニューやサブオプション提供の前にナビゲートする場合には、挙動の制約は、中間の不要なオプションを削除するように指示する。統計的な確率を使用して、例えば同じ発呼者からの多くの同じトランザクションの記録に基づいて、それが正しい応答であるという確率を算出し、それに従って特定のメニューオプションまたはオプション結果を発呼者に再生することによって、システムによる応答をさらに機能拡張することができる。
【０２４９】
音声アプリケーション作成および配布技術分野の技術者ならば、本発明の趣旨および範囲を逸脱することなく、上述の諸ステップにサブプロセスを含めることができることが理解されよう。例えば、ステップ２９０６の後に、テキスト音声変換前処理のためのサブプロセスを置くことができる。また、最終のＶＸＭＬページが、企業からユーザへの応答としてレンダリングされる前に、静的または動的最適化を置くこともできる。場合によっては、適応エンジンの分析から生じた動作は、ある種の他の処理をオーバライドするように構成することができる。図示された対話処理ステップの目的および順序が、処理に影響を及ぼす制約の性質に従って変更することができることも、当業者には明らかであろう。
【０２５０】
図３０は、本発明の他の実施形態による、図２８のシステムとのユーザ対話を示す処理フロー図である。ステップ３０００で、音声アプリケーションにアクセスした発呼者に挨拶が再生される。挨拶は、発呼者ＩＤ、自動番号識別（ＡＮＩ）、または他の識別方法に基づいて、個別の発呼者専用にすることができる。
【０２５１】
ステップ３００１で、発呼者は、音声アプリケーションにログインする。このステップはオプションのことがある。ログインは、バイオメトリック声紋識別を含むことができる。この声紋識別は、録音されかつ添付オーディオファイルとしてＸＭＬベースのデータとともに送信された発呼者の短いオーディオ音声サンプルを分析することによって、企業で検証されることができる。
【０２５２】
ステップ３００１での発呼者のセキュリティ承認を想定すると、ステップ３００２で、音声アプリケーションの最初のメニューが発呼者に再生される。図２９に関連して示された処理に関して上述したように、発呼者がシステムに習熟している場合は、ステップ３００３ａで、発呼者は初期メニューの終了の前に応答することができる。ステップ３００３ｃで、適応エンジンは、応答分析に基づいて発呼者のシステムに対する習熟レベルを評価する。例えば、発呼者が、メニューツリーのはるか下にある、そのメニューのメニューサブオプションを認識し発声した場合は、その発呼者は、「システムフレンドリ」とラベル付けされ、音声アプリケーションは適切に合理化される。
【０２５３】
次に、この例示的対話において、ステップ３００３ａの発声が、第２のメニューまたは関連するオプションについてのものではないと判定されたと想定すると、第２の提供されるメニューおよび関連するオプションは、ステップ３００４でスキップされる。ステップ３００５で、第３の提供されるメニューもスキップされる。しかし、ステップ３００６で、第３のメニューのサブオプションの１つと一致するフェッチされた結果であるサブオプション結果は、それが、ステップ３００３ａでの発呼者の発声に「答える」認識された結果値であるので再生される。ステップ３００６で再生されるダイアログの正確な性質は、ステップ３００３ａでの発呼者の音声応答の内容に直接応じることになる。発呼者が、特定の「テュープル（tuple）」の代わりに特定のメニューを要求した場合は、適切なメニューが再生される。
【０２５４】
ここで述べたステップの順序に関連する制約は、図２９の説明に関連して先に説明したものと非常に類似している。すなわち、発呼者が、すでにオプションおよびサブオプションについて知っている場合は、システムは、音声アプリケーションのすべての不要なダイアログをスキップすることができる。
【０２５５】
示された例示的処理には、追加の制約が含まれている。例えば、ステップ３０００ｂに示されているように、発呼者が、ステップ３００２の最初のメニューに対する発呼者の応答で優柔不断な場合は、ステップ３００３ｃで、適応エンジンは、その発呼者を「システムの初心者」とラベル付けすることができる。このようなラベル付けにより、システムは、ステップ３００７で、発呼者の優柔不断な性質に密接に関連するオプションを含む動的ヘルプメニューの準備を起動する。ステップ３００８で、対話的なヘルプメニューが、発呼者に対して再生される。
【０２５６】
ヘルプメニューは、「全体ヘルプメニュー」に属するダイアログオブジェクトとして動的に構成されることができる。動的オプションは、適応エンジンによって検出された発呼者の現在の問題に最も密接に関連する対話オプションだけを含むことになる。例えば、発呼者が、どちらを選択すべきかが不明なので「オプションＡまたはオプションＢ」と発声した場合には、適応エンジンは、発呼者がより情報に基づいた決定を行うことを可能にする、適切な類似事実などの準備を起動することができる。動的ヘルプメニューは、終了したとき元のメニューにリンクバックすることができる。それによって発呼者は、必要な支援を得た後で繰り返すことが可能になる。これは、発呼者が電話を切り、かけ直すことを必要とせずに実行することができる。
【０２５７】
上記の例を使用すると、様々な個人が、その人のニーズに応じたサービスをシステムから受けることできるようになる。より速い、より習熟した人々は、より迅速なサービスのために自分の音声アプリケーションを合理化するが、一方、より遅い人々は、自分のニーズに従って各自の音声アプリケーションを機能拡張する。
【０２５８】
図３１は、本発明のさらに他の実施形態による、図８のシステムとのユーザ対話を示す処理フロー図である。前述のように、発呼者が音声アプリケーションにアクセスしたと想定して、ステップ３１００で挨拶が再生される。ステップ３１０１ａで、クライアントは、パスワード、ＰＩＮ、またはおそらくは前述の声紋識別などにより音声アプリケーションにログインする。ステップ３１０１ａの間に、挙動適応エンジンは、クライアントの声紋または他の発声をサンプリングし、発呼者の音声中の高ストレスレベルを検出する。発声を録音し、デジタルオーディオファイルとしてＸＭＬベースのデータとともに送信することができる。ストレス検出を目的とする制約は、デシベル出力閾値を含むことができる。デシベル比較は、同じクライアントによる以前のトランザクションの間にサンプルされた以前の結果を用いて実施することができる。サンプルされた以前の結果は、クライアントの音声の平均デシベル出力を測定して、クライアントの特定のデシベル閾値を設定する目的で使用される。最新のサンプリングが、平均範囲より高い場合は、クライアントはストレスを受けていると判定することができる。
【０２５９】
他の実施形態では、発せられた何らかの罵り言葉、または抑揚特性によってもまた、クライアントがストレス下にあることを指示することができる。前述のように、適応エンジンは、これらの一般的な音声特性を、最初の対話で取り込まれた短いオーディオレンダリングをサンプリングすることによって認識することができる。罵り言葉、否定的なフレーズ、および抑揚パターンは、クライアントごとに複数のトランザクションに渡って格納されかつ標準化されることができ、それによってシステムは、例えばクライアントが、平均的な心的状態と異なる状態にあることを検出することができる。さらに、クライアントによって通常発声されるある種のフレーズが欠如していることも、通常のストレスレベルよりも高いことの指示になる場合がある。例えば、クライアントが、通常は「残高をお願いします（may  I  have  my  balance  please）」と話すところが、最新のサンプリングで「お願いします（please）」という単語が欠如していると判定された場合は、システムは、クライアントが通常より高いストレスレベルにあると判断することができる。ストレス検出用の制約を構成するための多くの異なる方法が存在する。
【０２６０】
この対話例では、クライアントの高いストレスレベルを検出することにより、ステップ３１０１ｃで、対話をモニタするという決定を起動する。モニタには、クライアントと音声アプリケーションとの対話の間の適応エンジンによる定期的な音声サンプリングから、ライブエージェントまたはスーパバイザによる連続的なモニタまでを含めることができる。ステップ３１０１ｂおよび３１０１ｃは、ステップ３１０２で最初のメニューが再生される前に行うことができる。ステップ３１０３ａで、クライアントは、前のメニューから１つのオプションを発声する。クライアントが応答の間にモニタされていることに留意されたい。
【０２６１】
音声サンプリングおよび分析によって挙動適応エンジンが、モニタを指示したと想定すると、この処理例では、ステップ３１０３ｂで、適応エンジンは、クライアントの高いストレスの継続を検出する。モニタ制約の一部として、エンジンは、ステップ３１０３ｃでシステムを起動して特別メニューを準備させる。厳密なルールでは、特別メニューの準備を起動する前に、各サンプリングにおいて高いストレスレベルの２つ以上のサンプリングを要求することもできる。他の場合には、１つのサンプリングだけでも十分である。最初のサンプリングでストレスを検出した結果として、ライブモニタリングを起動することも可能であるが、その場合には、処理は、この図に示したものとは異なるものになるはずである。
【０２６２】
この処理例では、特別メニューは、ステップ３１０３ｃで準備され、配布され、ステップ３１０４で対話式音声メニューとしてクライアントに提供される。この場合、メニューは、少なくとも１つの自動メニューオプションを提供し、おそらくは検出されたストレスレベルのために、エージェントを待つ他の発呼者より前にライブエージェントに接続するためのオプションを含む。ライブエージェントとの間を仲介することを決定するか、または少なくとも結合されたメニューにそのオプションを提供することを決定するために、他の要因を使用することもできる。これらの要因には、支払履歴、企業に対するクライアントの立場、企業に出されたクライアントの注文の金銭価値などを含めることができる。
【０２６３】
本発明の一実施形態では、挙動適応エンジンは、特定のアプリケーションとの対話のすべてをインターセプトするように構成することができる。マルチタスク環境では、エンジンは、複数の同時インターセプトおよび計算処理に適合させることができる。他の実施形態では、このエンジンは、個別の機能インスタンスを生成することができ、各生成されたインスタンスは、特定のアプリケーションと対話する特定のクライアント専用にすることができる。このエンジンは、データキュー、外部リソース、および他の計算モジュールの機能を使用することができる。例えば、このエンジンは、クライアント応答をインターセプトし、可能なダイアログ応答セットの選択を含む制約ベースの決定を行うことができる。次いで、このダイアログ応答セットは、制約ベースの最適化によって静的または動的キャッシュを決定する前に、他の無関係な制約セットに基づくテキスト音声変換前処理によって、最適応答に絞り込むことができる。
【０２６４】
他の実施形態では、このエンジンは、トリガ制約に従って実行されるように構成することができる。その際、トリガ制約が、特定のユーザに対して有効である場合は、エンジンは、次のクライアント応答をインターセプトする。音声アプリケーションは、分析結果から生成された値に従って動的に注釈を付けることができる。この値は、同じアプリケーションを繰り返し使用するリピートクライアントに個人専用のサービスを提供するために、統計分析によって最適化されることができる。対話の間に、クライアントコントロールを提供し使用可能にすることによって、音声アプリケーションユーザが、統計的な動向および分析を利用して、作成されかつ提供されたある種の企業応答をオーバライドすることを可能にすることができる。例えば、クライアントが、サービスによって提供される特定の結果を繰り返し求めたことにより、クライアントがシステムにアクセスするたびに、その結果を常に最初の挨拶に組み込む場合には、クライアントが、現在のトランザクションでその結果を求めていない場合に、元の音声アプリケーションメニューを指示することができるように、結果の中に「元のメニューオプションに戻る」を含めることができる。
【０２６５】
図３２は、本発明の一実施形態による、図２８の挙動適応エンジン２８０１の基本コンポーネントを示すブロック図である。挙動適応エンジン（ＢＡＥ）２８０１は、この例では、他のモジュールおよび外部リソースと通信することができる内臓型のモジュールとして提供される。エンジン２８０１は、音声アプリケーションとのクライアント対話の結果生ずるクライアントデータ入力を受信するように構成された入力ブロック３２０２を備えている。一実施形態では、クライアントデータ入力は、先に図２８に関連して説明した、音声アプリケーションサーバ２３０１の論理通信バス構造２３１５を介してＢＡＥ２８０１に送られる。
【０２６６】
クライアントデータは、ダイアログ応答データ、クライアント履歴および／またはステータスデータ、およびクライアント音声サンプリングを含む。クライアント音声サンプリングは、デジタルオーディオファイルアタッチメントとしてクライアントデータとともに送信される。好ましい実施形態では、音声ファイル以外のクライアントデータは、クライアント音声応答からクライアントポータルでレンダリングされたＸＭＬベースのデータである。
【０２６７】
入力ブロック３２０２は、標準ポートの場合と同様に、複数の入力ポート、入力データキュー、および処理ロジックを含むことができる。一実施形態では、入力ブロック３２０２は、この例では単方向ポートであるが、双方向ポートであってもよい。対話中のクライアントに返信されるエラー通信およびダイアログ応答は、音声アプリケーションサーバのポートを介して配信される。
【０２６８】
ＢＡＥ２８０１は、その内部に提供される処理ロジックブロック３２０１を備え、処理ロジックブロック３２０１は、ＸＭＬベースのデータ、および存在する場合にはそのＸＭＬパッケージに添付された音声ファイルを処理するように構成される。処理ロジックは、短いオーディオファイルを受信し、そのデシベル特性、音声抑揚特性、およびある種の用語の包含または欠如を分析することができる、音声アナライザ３２０４を備えている。アナライザ３２０４は、分析のために音声ファイルを実行する音声ファイルプレーヤ（図示せず）を含む。
【０２６９】
処理ロジック３２０１は、その内部に提供されるＸＭＬリーダ３２０５を備え、ＸＭＬリーダ３２０５は、クライアントの音声応答からレンダリングされたＸＭＬベースのデータを識別するように構成される。ＸＭＬリーダは、また、クライアントによってなされた手動選択および識別データなどの他のクライアント入力データ、ならびにクライアントおよびクライアント対話データに関して提供することができる他の任意のデータを受信しかつ解釈する。
【０２７０】
ＢＡＥ２８０１は、その内部に提供される入／出力ブロック３２０５を備え、入／出力ブロック３２０５は、統計データベースおよびルールデータベースなどの外部データソース、ならびに内部システムモジュールと双方向で通信するように構成される。一実施形態では、ブロック３２０５と他のシステムおよびモジュールとの間の外部データ通信は、さらに上述された音声アプリケーションサーバの論理バス構造によって容易になる。外部ソースへの直接アクセスは、先に図２８に関連して説明したリソースアダプタブロック２３１０によって実施される。しかし、実施形態によっては、エンジン２８０１は、通常のサーバ通信とは無関係に、直接外部リソースにアクセスするように構成されることができる。この場合、エンジンは、提供された専用のサーバポートを備え、リモートデータラインを介して通信するように構成されることになる。
【０２７１】
入／出力ブロック３２０５は、一般にデータポートアーキテクチャに存在することが知られている、複数の入力および出力データキューならびにポート処理ロジックを含むことができる。ＢＡＥ２８０１の中心に存在する決定論理ブロック３２０３は、どの使用可能な企業ダイアログ応答または応答セットが、ＶＸＭＬページとして提供されるダイアログに組み込まれるかまたはリンクされる応答の候補として識別されるか、および音声アプリケーションと対話するクライアントに返信されるかに関する決定を行うように構成される。
【０２７２】
決定ブロック３２０３は、音声アナライザ３２０４とＸＭＬリーダ３２０５の組み合わされた結果を、１つまたは複数の企業ルールならびに、該当する場合には外部データおよび統計値に従って処理し、ＶＸＭＬページレンダリングのために提供される１つまたは１組の候補企業ダイアログ応答を識別する値を決定する。この決定値は、例えば１つまたは複数のオプションメニューまたはメニューオプション、ライブ通信介入を行うためのリンク、および任意のフェッチされた結果など他の音声アプリケーションまたはメニューもしくはその中に含まれるオプションへのリンクなどと同等と見なすことができる。
【０２７３】
この例では、ＢＡＥ２８０１は、内蔵モジュールとして示されている。しかし、他の実施形態では、ＢＡＥ２８０１の機能および能力は、本発明の目的を達成するために相互に対話できるように、音声アプリケーションサーバドメイン内に分散された複数の相互運用モジュールとして提供することができる。多くの可能性が存在する。
【０２７４】
汎用アプルケーション言語アダプタおよびマルチスロット最適化
本発明の一態様によれば、汎用アプリケーション言語アダプタは、アプリケーション作成および解釈サービスを提供する際にサードパーティの柔軟性を提供するために、汎用ソース言語を様々な専用および準標準言語にブリッジするために提供される。汎用アプリケーション言語は、一般化された質問に対する発呼者応答のマルチスロット解釈ができる。本発明の方法および装置については、以下で可能な詳細を説明する。
【０２７５】
図３３は、従来技術の相互運用性による、様々なスクリプト言語とＶＸＭＬレンダラ（renderer）との間の関係を示すブロック図である。本明細書の背景技術部分に関連して前述したように、ＧＳＬ、ＧＲＸＭＬ、および他の類似のスクリプト言語（ＸｘＬ）は、エンジン３３０２〜３３０６などのある専用の音声合成エンジンとともに使用されることができる。しかし、どの単一のスクリプト言語も、提供された任意の音声合成エンジンとともに動作するように変換することは容易にはできない。この場合、企業は、音声アプリケーションを起動するために複数のプロバイダを使用する柔軟性は有していない。むしろ、顧客と対話するために使用される特定の音声合成エンジンによってサポートされるスクリプト言語を使用して、個別の音声アプリケーションを提供されなければならない。
【０２７６】
図３４は、本発明の一実施形態による、クライアント対話において目的推論を実施し、かつマルチスロットおよびマルチモーダルダイアログスクリプト記述のために汎用文法を使用する、通信ネットワーク３４００の一例示的アーキテクチャの概要を示す。
【０２７７】
通信ネットワーク３４００は、データパケットネットワーク（ＤＰＮ）３４０１を含む。このデータパケットネットワーク３４０１は、この例では、よく知られたインターネットネットワークである。ネットワーク３４０１は、本明細書中では以後、インターネットネットワーク３４０１または単にインターネット３４０１と呼ぶことがある。
【０２７８】
公衆交換電話網（ＰＳＴＮ）３４０２は、通信ネットワーク３４００の一部であり、クライアントとサービスとの間の従来のアナログ電話サービス（ＰＯＴＳ）対話のための通信接続機能を提供する。
【０２７９】
この例示的通信アーキテクチャには、いくつかの対話プロバイダが示されている。この例には、企業３４０３が示されており、本発明の一実施形態による、汎用スクリプト機能およびクライアント対話推論機能など、本発明の対話機能を提供する会社を表している。
【０２８０】
この例には、サービスプロバイダ３４０９も示されている。サービスプロバイダ３４０９は、企業３４０３の代わりに、その企業によって生成されたサービスである音声アプリケーション対話サービスをクライアントに提供することができる。この例では、プロバイダ３４０９は、ＧＳＬをサポートするプロバイダａ、Ｗ３Ｃ標準ＧＲＸＭＬをサポートするプロバイダｃ、および音声アプリケーションを作成するために使用される他の専用スクリプト言語をサポートすることができるプロバイダｂを含む。
【０２８１】
インターネット３４０１には、全体としてインターネットネットワークを構成するネットワーク装置、接続ポイント、および回線のすべてが含まれるものと想定することができる。ネットワークバックボーン３４０５は、インターネットを規定するサブネットワークを含む、すべての装置、アクセスポイント、および回線を表し、それによって本発明の地理的範囲を制限するものではない。
【０２８２】
インターネット３４０１は、本発明の趣旨および範囲を逸脱することなく、イントラネット、イーサネット（登録商標）、または他のいくつかの公的にアクセス可能なもしくはプライベートな広域ネットワーク（ＷＡＮ）などのインターネットの代わりに、他の種類のＤＰＮであってもよい。インターネットとイーサネット（登録商標）または他の種類のサブネットワークとを分離する物理的な境界は、ドメイン固有かつ論理的に曖昧なものであり、したがって任意の方法で実施される本発明の範囲では考慮されないことを、当業者なら理解されよう。この点に関して、対話のためにインターネット３４０１に接続された任意のサブネットワークは、そのネットワークの一部と仮定されることができる。
【０２８３】
ＰＳＴＮ３４０２は、本発明の趣旨および範囲を逸脱することなく、ブロードキャリアネットワークと接続することができる無線ローカルループ（ＷＬＬ）タイプの電話システムおよび他のサブシステムなど、私的または公的な他の種類の電話ネットワークであってもよい。通信用ネットワーク統合技術分野の技術者ならば、当技術分野で知られているＳＳ−７などの通信ゲートウェイによるネットワーク間のブリッジ通信の実現可能性についても同様に理解されよう。
【０２８４】
企業３４０３は、対話において音声合成技術を使用するクライアントインタフェースシステムを介して、音声アプリケーションを使用するクライアントと対話する任意の会社を表す。一実施形態では、企業３４０３はまた、他の任意の会社に音声アプリケーションサービスを提供する任意の会社を表すこともでき、必ずしもその会社のクライアントと直接対話する訳ではない。さらに他の実施形態では、企業３４０３は、アプリケーション、またはおそらくは音声アプリケーションで使用されるダイアログを作成することはできるが、音声アプリケーション配布サービスは、この図でプロバイダ３４０９によって表される任意のフロントエンドプロバイダまたはその組合せからリースすることもできる。
【０２８５】
この例において、企業３４０３は、複数のコンピュータステーションを含む。コンピュータステーションは、この例では、コンピュータステーション３４１０、コンピュータステーション３４１１、およびコンピュータステーション３４１２として表されている。ここで述べたコンピュータステーションはすべて、この例では、企業のために提供され、かつ企業によって運営される、ローカルエリアネットワーク（ＬＡＮ）３４１４に接続されている。ステーション３４１０〜３４１２を使用するオペレータは、クライアント／企業間音声駆動トランザクションにおける配布用ダイアログなどの音声アプリケーションを作成することができる。
【０２８６】
プロバイダ３４０９を使用する一実施形態の例示として、例えばステーション３４１０のオペレータは、ＧＳＬを使用して音声スクリプトを作成するように装備しているが、プロバイダａがＧＳＬをサポートしているので、それらのスクリプトを配布するためにはプロバイダａを使用しなければならない。同様に、ステーション３４１１のオペレータは、例えばＧＲＸＭＬを使用して音声スクリプトを作成するように装備しているが、スクリプトを配布するためには、適切な配布プロバイダ、この例ではプロバイダｃを使用しなければならない。なぜならばプロバイダｃが、ＧＲＸＭＬをサポートしているからである。ステーション３４１０および３４１１はどちらも、サポートされている特定種類の言語によって、プロバイダの選択が制限されることになる。
【０２８７】
コンピュータステーション３４１２は、直前で説明したステーションとは異なり、汎用文法アダプタ（ＵＧＡ）を装備している。汎用文法アダプタ（ＵＧＡ）は、どの特定の文法言語方言とも無関係の一般的な構成体のセットから、ＸＭＬベースの入力を受け取り、その入力を、指示された適合に従って、言語変換方法を用いてプロバイダ３４０９によってサポートされる任意の言語に適用できる汎用文法スクリプト（ＵＧＳ）に変換するように構成される。このようにして、スクリプトを作成するために使用可能な言語によって、ユーザオペレーティングステーション３４１２が制限されない。
【０２８８】
アプリケーションサーバ（ＡＳ）は、企業３４０３内に提供され、ＬＡＮ３４１５に接続される。アプリケーションサーバ３４１５は、音声アプリケーションを提供または配布し、例えばＶＳ３４０８を介して接続しているユーザに関する対話状態を管理するように構成される。アプリケーション３４１７は、アクセス可能なデータリポジトリ３４１７を備え、データリポジトリ３４１７は、ＡＸＭＬ（inventor  extensible  Markup  Language）によってラベル付けされた汎用認識マークアップ言語（universally  recognized  markup  language）の形でスクリプトを表現する必要がある構成体を格納するように構成される。ＡＸＭＬは、十分に一般的なマークアップ言語なので、それを（ＸＳＬＴプログラムとして書かれた）ＵＳＧプログラムに入力して、特定の音声エンジンに適合する特定のスクリプトに容易に変換できる汎用文法スクリプトを生成することができる。
【０２８９】
サードパーティプロバイダ３４０４は、インターネット３４０１のドメインの内部に示されており、より詳細には、本発明の方法および装置によって拡張可能な一般的な対話サービスを提供することができる企業を表す。プロバイダ３４０４は、動的配信可能な音声アプリケーションを提供するように構成されたアプリケーションサーバ（ＡＳ）３４０６を含む。音声システム（ＶＳ）３４０８は、インターネット３４０１のドメインの内部に示されており、サードパーティ３４０４、企業３４０３、または任意の１つのプロバイダ３４０９で動作する任意のシステムを表すことができる。ＶＳ３４０８は、先に図２８に関連して説明した電話サーバ／音声ポータル２３０２など音声駆動のクライアントインタフェースサーバにある程度類似している。この例において、ＶＳ３４０８は、この例でエンドユーザ３４１８およびエンドユーザ３４１９として示されているクライアントに、インタフェースサービスを提供することができる。
【０２９０】
ユーザ３４１８は、例えば音声駆動対話セッションにおいて、ＶＳ３４０８と通信するためのＶｏＩＰ（Voice  over  Internet  Protocol）アプリケーションが動作するインターネット接続されたコンピュータでもよい。この例には、エンドユーザ３４１９が示されており、標準電話を使用してサービスに接続するユーザを表す。音声ポータルシステム（ＶＳ）３４２２は、ＰＳＴＮネットワーク３４０２内に示されており、クライアントがアクセス可能な音声対話用サーバとして構成されている。サーバ３４０８と３４２２の違いは、それぞれが動作するネットワークへの適合から明らかである。例えば、ＶＳ３４２２は、クライアントとの電話音声対話、例えば対話的音声応答（ＩＶＲ）システムなどに適合している。クライアントは、電話番号を呼び出すことによってＶＳ３４２２にアクセスすることができる。ＶＳ３４０８は、サーバ３４２２と同等のデータネットワーク電話（ＤＮＴ）である。
【０２９１】
ユーザは、サーバ３４０８を呼び出すかまたはナビゲートして対話することができる。ユーザ、例えば電話ユーザ３４１９は、電話ライン３４２１によってＶＳ３４２２にアクセスすることができる。音声ゲートウェイ３４２４は、ＰＳＴＮ３４０２のドメイン内に提供されており、ＰＳＴＮネットワークと、インターネットアクセスライン３４２６を使用するインターネットネットワークとの間の通信をブリッジするように構成される。エンドユーザ３４１９は、電話環境内のＶＳ３４２２、またはインターネットドメイン内で維持されているＶＳ３４０８にアクセスすることができる。必要ならば、ステーション３４１８を使用して、ＶＳ３４０８の代わりにＶＳ３４２２にアクセスすることができる。ユーザ３４１８は、ダイアルアップを経由して、またはインターネットサービスプロバイダ（ＩＳＰ）３４２３、インターネットアクセスライン３４２６、バックボーン３４０５を介した他の種類のインターネットアクセスライン３４２０を経由して、音声ポータル３４０８にアクセスすることができる。エンドユーザ３４１９は、ＰＳＴＮまたは他の接続された電話ネットワークを介して、音声ポータルシステム（ＶＳ）にアクセスする複数のユーザのいずれかを表す。エンドユーザ３４１８は、インターネットアクセス方法などのネットワークアクセス技術を使用して、音声ポータルシステムにアクセスすることができる複数のユーザのいずれかを表す。インターネットアクセス方法には、デスクトップコンピュータシステム、インターネットプロトコル電話、インターネット対応携帯電話、または任意のネットワーク対応周辺機器もしくは装置を経由したアクセスなどが含まれるが、これらに限られるものではない。
【０２９２】
アプリケーションサーバ３４０６および３４２８は、クライアントと製品／サービスプロバイダとの間のビジネスを表す実時間トランザクションに作用し完成することを目的として、クライアント／システム対話のために設計された音声アプリケーションの作成、構成、および配布を可能にするように構成された、任意のホストサーバを表す。各アプリケーションサーバは、サーバ３４０６上で実行可能な推論エンジン（ＩＥ）３４２７のインスタンス、およびサーバ３４１５上で実行可能なＩＥ３４２８のインスタンスを備える。ＩＥ３４２７およびＩＥ３４２８は、同一のソフトウェアと想定することができる。ＩＥ（３４２７、３４２８）のインスタンスは、音声セッションをモニタし、セッション時に収集された実時間データおよび／またはクライアントに関連する履歴活動の統計分析によって、クライアントが何を望むかを推論するように構成される。推論エンジンインスタンスは、この実施形態では、音声アプリケーションサーバに対して提供されているが、一実施形態では、本発明の趣旨および範囲を逸脱することなく、ＶＳ３４２２またはＶＳ３４０８などのクライアントに直接対応する音声ポータルに分散させることができる。
【０２９３】
ＩＥ３４２７および３４２８のインスタンスは、推論を保証するために十分な量の実時間データおよび／または履歴活動データが存在することによって起動することができる。推論は、企業ルールに従って、また任意の所定の音声アプリケーションに対する使用可能なダイアログオプションに関連して実施される。ＩＥインスタンス３４２７および３４２８は、システムとの音声対話を実施しているクライアントに関連する実時間データおよび履歴データにアクセスしかつ評価するように構成される。好ましい実施形態では、アクセスされたデータは、ルールベースまたは知識ベースを含むデータモデルに対して評価される。実行される音声アプリケーションは、プリトランザクションおよびポストトランザクション起動ポイントに適合しており、推論は、システムによって実施される場合には、所与のセッションのダイアログフローの中に挿入される。実行中の推論の存在により、推論分析の結果に基づいて、発呼者に再生されるシステム音声合成ダイアログを含む特別なシステム応答の実行を引き起こすことができる。
【０２９４】
アプリケーションサーバ３４１５は、音声認識用語についてのセマンティックインデックス、ならびに企業ルール、クライアント履歴データ、およびデータグループに関連する統計を含む、システムおよび企業知識を含む知識ベースを格納するように構成されたリポジトリ３４１６にアクセスすることができる。リポジトリ３４１６にはまた、企業によって提供されるディスクロージャの正式な記述を提供するオントロジ（図示せず）も含まれる。この明細書の目的では、オントロジは、クラスの記述、スロットと呼ばれることもあるクラスの特性、および役割制限（role  restriction）と呼ばれることもある属性の使用または選択に関する制限を含む。
【０２９５】
アプリケーションサーバ３４２８はまた、音声アプリケーションコンテキスト（ＡＣ）および外部コンテキスト（ＥＣ）データソースを含むように構成された、リポジトリ３４０７にアクセスすることもできる。このようなソースは、時折リフレッシュされるウェブベースのデータソースを含むこともできる。このようなソースのコンテキストは、銀行預金残高、金利、口座状況情報、および他の種類の情報などのデータを含むことができる。
【０２９６】
推論エンジンに従って汎用文法アダプタ（ＵＧＡ）を使用することにより、正常にトランザクションを完了するために、クライアントとシステムとの間で実施しなければならない対話の量を、そうでない場合と比べて大幅に削減することができる。説明のために、例えば、ユーザ３４１９が、単に音楽ＣＤを注文するために、回線３４２１を介してＶＳ３４２２にアクセスすると想定する。呼出し時に、クライアントがシステムに関する履歴を有していると判定された場合は、推論エンジンが、音声対話の間に介入し、推論を実施する。推論は、過去のＣＤの購入から、クライアントは特定のアーティストのグループを好むと推定されるということもある。クライアントが購入のためだけに呼び出しを行うことが分かる場合もある。
【０２９７】
マルチスロットダイアログアプローチおよび収集された推論データを使用することで、一群のダイアログから、ユーザの要望の理解をより容易にするダイアロググループを作成または選択することができる。従来技術のシステムでは、クライアントからの入力が毎回同じの場合でも、単に毎回すべてのメニュー選択を再生し、かつクライアントからの入力を待つ。本発明の方法は、不要なコールフローの廃棄を可能にし、それによってトランザクション処理を加速する。システムの呼出し負荷を含む、複数の発呼者に関して実施される推論は、システムの呼出し負荷および要求される処理を減少させるように機能する。
【０２９８】
ＩＥインスタンス３４２７および３４２８は、クライアントと音声アプリケーションシステムとの間の１つのコールフローの間に複数回呼び出すこと、または起動することができる。推論は、発呼者に対する最初のメッセージを再生する前に、決定されることができる。推論はまた、トランザクションが開始された後で起動されることもできる。例えば、履歴データは、あるクライアントが、常に特定のクレジットカードを用いて支払をすることを指示することができる。したがって、推論は、クライアントによって注文が出された後で、商業上受理されるクレジットカード種類の３つまたは４つの選択肢の提供後に、日付と番号を再入力する静的ダイアログではなく、単に支払として特定のカードが使用されることの確認を求めるダイアログを呼び出すことができる。アクティブな音声セッションの間の推論の詳細については、本明細書中で後に説明する。
【０２９９】
前述のサードパーティドメイン３４０４は、本発明の方法および装置をコブランド（co−branded）のサービスとして装備することができる。このような例におけるアプリケーションサーバ３４０６は、アプリケーションサーバ３４１５に関連して説明したのと同じデータリポジトリおよびそれに含まれるデータのすべてにアクセスできるものと想定することができる。
【０３００】
当業者ならば、本発明の趣旨および範囲を逸脱することなく、企業３４０３が、必要に応じて１つまたは複数のアプリケーションサーバを配備または配置することができること、またパーティ３４０４などの他のパーティのためにアプリケーションサービスを提供することができることが理解されよう。同様に、企業サイト３４０３は、ＡＸＭＬを使用して音声アプリケーションを作成することができ、またＵＧＡおよび拡張可能スタイルシート言語変換（ＸＳＬＴ）などの変換言語ユーティリティによって、テキストマークアップを、独自のアプリケーションサーバおよび音声認識エンジンを使用する特定のサービスプロバイダによって必要とされる特定のＸＭＬベース形式に変換することもできる。多くの可能性が存在する。
【０３０１】
図３５は、ＸＭＬ形式で記述された汎用文法スクリプトの一例を示す。アプリケーションまたは汎用文法スクリプト（ＵＧＳ）は、構成体のＡＸＭＬライブラリから構成され、汎用文法アダプタによって出力されるように作成される。ＸＭＬ技術分野の技術者ならば、ＸＳＬＴプログラムへの入力として使用される汎用形式が、ＵＧＳを、ＧＲＸＭＬなどアプリケーション側のスピーチエンジンで使用されるＸＭＬの特定の形またはスタイルに変換するように構成されることが理解されよう。
【０３０２】
好ましい実施形態では、スピーチエンジンに入力されて発呼者への音声出力として合成される特定の音声アプリケーションスクリプトにおいて、ある形式で必要とされる可能性があるセマンティックおよび文字のすべてを規定するために、リポジトリ中の１組の構成体が使用可能になる。本発明の例では、前述のように、本発明者は、この構成体の組をＡＸＭＬと呼ぶ。汎用文法スクリプトは、ＸＳＬＴなどの言語変換ユーティリティに入力することができる汎用スクリプト言語を規定する、１組の中間構成体の個々の構成体に対する、第１の構成体の個々の構成体の結びつきを表す。
【０３０３】
図３６は、本発明の一実施形態による、ＸＳＬＴプログラムを使用してＧＲＸＭＬ言語に翻訳される図３５のＵＧＳの一例を示す図である。この例によって示されたＧＲＸＭＬスクリプトは、Ｎｕａｎｃｅ（商標）およびＳｐｅｅｃｈ  Ｗｏｒｋｓ（商標）など、非常によく知られたスピーチエンジンの少なくとも２つへの入力として受け入れられる形式のものである。この例で示されたＧＲＸＭＬ形式は、実際にはＷ３Ｃ標準スクリプトの一部であるフォーム、タグ、およびコンテンツを保持するものとして、マークアップ言語技術分野の技術者によって理解されるべきものである。
【０３０４】
図３７Ａは、従来技術による音声システム／クライアント対話のダイアログフロー図３７００である。フロー図３７００は、代表的な音声アプリケーションを表し、この音声アプリケーションは、静的であり、かつトランザクションが完了する前に必要となる情報、この場合は位置情報をうまく配布するために、シングルスロットプロンプトおよび応答形式を利用する。
【０３０５】
ステップ３７０１で、音声スクリプトは、「どこの都市ですか？」などのフレーズを促すことによって発呼者に都市を訪ねる。ステップ３７０２で、発呼者は、問題の都市の名前、この場合はパロセドロ（Palo  Cedro）市を口頭で応える。シングルスロットアプリケーションでは、この都市を他の任意のパラメータと関連づけることができない。したがって、このアプリケーションは、ステップ３７０３で、「どこの州ですか？」などのフレーズを用いて都市パロセドロに関連する州の名前を促さなければならない。ステップ３７０４で、発呼者は、州の名前、この場合は「カリフォルニア」と口頭で応える。次に、アプリケーションは、収集された最後の２つのパラメータに関連する国名を知る必要がある。ステップ３７０５で、システムは、「どこの国ですか？」などと尋ねる。ステップ３７０６で、発呼者は「アメリカ合衆国」と口頭で応える。
【０３０６】
上記の例では、システムによって必要な３つのパラメータがうまく収集されるまでに、６つの動作、３つはシステムによる動作、３つは発呼者による動作がとられる。このシングルスロットアプローチでは、音声認識は、ロバスト（robust）でなく、要求されたパラメータの発声そのものだけを認識する。マルチスロットアプローチを用いることで、動作の数を削減することができる。この場合は、以下に詳細に示すように６動作から２動作に低減される。
【０３０７】
図３７Ｂは、本発明の一実施形態による、マルチスロット言語変換によって拡張された図３７Ａのフローと同一内容のダイアログフロー図３７０７である。フロー３７０７は、同様に発呼者の位置に関する必要なすべてのパラメータを含む発呼者からの応答を収集することができるＵＧＳスクリプトによって支援された、アプリケーションフローを表す。必要なパラメータは、やはり、パロセドロ、カリフォルニア、およびアメリカ合衆国であるが、文法スクリプトは、複合回答を、３つの必要なコンポーネントに分解する機能を備える。例えば、シングルスロットモードで動作する代わりに、スクリプトは、ステップ３７０８で、「どこから電話をかけていますか？」などの質問を発呼者に促すことによって、３つのすべてのパラメータを一度に要求することができる。システムは、応答に３つのパラメータが含まれている限り、発呼者の応答を認識することができる。この場合、発呼者は、ステップ３７０９で、パロセドロ、カリフォルニア、ＵＳＡと応える。ここで、応答の順序が、図３７Ａのシングルスロットプロンプトに従っていることに留意されたい。しかし、発呼者は、システムが認識できるように、パラメータをある特定の順序で提供する必要はない。実際、プロンプト３７０８は、特定の順序に基づいたものではない。
【０３０８】
ステップ３７０９で発呼者が応えたとき、動作中の文法スクリプトは応答を収集し、次いで、先に図３４に関連して説明したセマンティックインデックスと協働することによって、その応答をマルチスロットの回答に分解する。この場合、待ち状態のトランザクションプロセスが前に進めるように、システムがうまく発呼者の位置を知るために、２つのアクションだけが必要である。マルチスロット様式を使用することにより、大幅に時間が節約されることになる。
【０３０９】
図３８Ａは、従来技術による静的システムプロンプトを論理的に表すテキストブロック３８００である。プロンプト３８００は、代表的なトランザクションの終了に応答して、代表的なシステムから送信された代表的な音声アプリケーションダイアログを示す。この例の例示的プロンプトには、「ＡＢＣ書店を選んでいただき、有難うございました。あなたのトランザクションは終了しました。」と読み上げられる。これは、発呼者にかかわりなく、またその発呼者が何度ＡＢＣ書店に注文をしたかにかかわりなく、関連するトランザクションが終了するたびに毎回再生される静的メニュー選択である。
【０３１０】
発呼者に関する履歴活動データを編集し、そのデータを音声アプリケーションシステムが利用できるようにすることによって、上記の推論エンジンを使用して、インテリジェントな内容の動的ダイアログを生成することが可能になる。このことについては以下で説明する。
【０３１１】
図３８Ｂは、本発明の一実施形態による、推論によって生成かつ／または選択されたシステムプロンプト３８０１である。プロンプト３８０１は、特定の発呼者動作に関する知識に基づいて選択または生成された推論ダイアログである。例えば、発呼者トランザクションの終了時に、静的プロンプトを送信する代わりに、システムは、推論を実行するために十分な根拠またはクライアント活動履歴が存在することを確認し、この場合は、クライアントに他のどのサービスが提供できるか、およびクライアントがそれらのサービスを受け入れる可能性を決定しようと試みる。この場合、システムは、クライアントがもっぱら自然に関する本を購入することを知っている。
【０３１２】
これは、最近の１０件の購入品のうちの８件が、自然に関する定期刊行物、その他の出版物であった場合である。この推論の場合、トランザクションの終りまたはポストトランザクション推論ポイントで、２つの部分からなるプロンプトが発呼者に送信される。このインテリジェントな内容のプロンプト３８０１では「自然に関する本がお好きなようですね」と読み上げられる。第２の部分では、「我社の月刊野生生物ニュースサービスを定期購読されませんか？」と尋ねている。これは、ダイアログ３８０１の最初の部分が、クライアントの活動についての知識、ならびに活動の性質と利用可能なサービスとの間に形成される関係性に基づいて、実行中に生成された場合である。プロンプト３８０１の第２の部分は、サービスに関連するダイアロググループに関係するオプションから選択することができる。
【０３１３】
置換えプロンプトの実行では、クライアントの活動に基づく、そのクライアントが月刊誌の定期購読のよい候補であるという、システムによる推論が構成される。ダイアログが実行された後で、システムは、提供された定期購読のトランザクション処理について記述された適切な標準ダイアログにループすることができる。このようにして、クライアントは、追加のアイテムまたはサービスを、インテリジェントにかつ受け入れおよび成功のより強い可能性を持って提供されることができる。
【０３１４】
図３９Ａは、従来技術による、その後のクライアントアクセスの間に繰り返される静的システムプロンプトを示すフロー図３９００である。フロー図３９００は、クライアントとホスト企業とのビジネス関係の間に、同じ発呼者によって繰り返し経験される可能性がある従来技術によるシステムプロンプトの反復的で静的な性質を示す。
【０３１５】
この例の企業のコンテンツまたはディスクロージャは、銀行業務に関するものである。ステップ３９０１で、発呼者が対話を始めたと想定すると、システムは、「残高照会ですか、資金振替ですか、それとも支払いですか？」とプロンプトを出す。プロンプトには、３つのパラメータが含まれており、実行が成功するためには応答の中にそれらのうちの１つが必要である。ステップ３９０２で、発呼者は、「残高です」と応える。この場合、発呼者またはユーザは、残高情報を受け取り、セッションを終了するものと考えられる。後日発生する同じ発呼者と同じシステムとの間の別のセッションでは、ユーザがシステムにアクセスした後、ステップ３９０３で、システムはまったく同じ静的プロンプトを繰り返す。ユーザは、再び残高と応える。この場合、残高がほとんどの場合のユーザ応答であるとしても、ユーザは一般に、プロンプトが完全に実行されるのを待つことになる。
【０３１６】
図３９Ｂは、本発明の一実施形態による、過去のクライアントの活動からの推論に基づき、クライアントのために選択または生成される動的システムプロンプトを示すフロー図３９０５である。フロー３９０５は、音声アプリケーションでどのように推論が実行できるかについての他の変形例である。ステップ３９０６で、発呼者にプロンプトが送信される。ステップ３９０６のプロンプトは、上記のステップ３９０１のプロンプトと同一である。この事実により、ステップ３９０６の時点では、システムにとって推論動作を起動するために十分な情報が使用可能でないと想定される。ステップ３９０７で、発呼者は、「残高です」言うことで応える。
【０３１７】
しかし、発呼者が、提供される他のオプションではなく、残高を繰り返し求めた数回のこのようなシーケンスの後で、システムは、発呼者がパラメータに残高を選択する傾向があることを学習する。発呼者が、次にシステムにアクセスしたとき、その発呼者が、他のどの利用可能な選択よりも残高情報を多く要求したという事実によって、動的推論が起動される。推論は、ステップ３９０６の前に起動されかつ実行される。ステップ３９０６で、標準ダイアログの代わりに推論ダイアログが提示される。ステップ３９０６で、システムは、クライアントが、統計的に残高を求める傾向があったという履歴記録に基づく予測に基づいて、非応答型（non−solicited）の結果（口座残高情報）を提供する。
【０３１８】
したがって、ステップ３９０８では、「あなたの使用可能な残高は１０００ドルです」「資金振替または支払いの必要はありますか？」と読み上げられる。ここで、システムは、クライアントのニーズに適合したことになる。ステップ３９０９で、クライアントが、「不要です」と応えることによってトランザクションを終了する。この例では、推論は、任意のトランザクションが終了する前に実施される。この例では、推論を実施することが可能である。なぜならば、クライアントが他のいずれかのオプションを選択するよりも、むしろクライアントが自分の残高を求める高い統計的確率を有していることを示唆する、システムが使用可能な十分な履歴データが存在するからである。
【０３１９】
図４０Ａは、従来技術によるシステム／クライアント対話ダイアログ４０００を示すフロー図４０００である。対話ダイアログ４０００は、クライアントが、この場合はＣＤを販売する企業によって提示された音声アプリケーションにアクセスしたときに実施される、代表的な静的対話を表す。先の図３７Ａの従来技術の例と同様に、このシステムプロンプトは静的であり、正常なトランザクションを可能にするためにはシングルスロット応答が必要である。
【０３２０】
ステップ４００１で、システムは、「注文のチェックですか、それともＣＤの購入ですか？」のようなプロンプトをクライアントに出す。音声プロンプトは、注文のチェックという答えか、または購入ＣＤという答えを要求する。ステップ４００２で、発呼者は、「ＣＤの購入です」と応えることによって購入オプションを選択する。ステップ４００３で、システムは、アーティストの名前を要求する。ステップ４００４で、発呼者は、「マーシャルタッカー（Marshall  Tucker）」と応える。ステップ４００５で、システムは、アルバムタイトルを要求する。ステップ４００６で、発呼者は、「グレーテストヒット（Greatest  Hits）」と応える。この例では、注文がうまく作成される前に、３回の要求／応答対話が必要である。ＣＤが出荷できるようになるまでには、システムとクライアントは、さらに多くのステップでトランザクションの詳細を取り決める必要がある。
【０３２１】
音声認識にマルチスロット機能および豊富なセマンティックベースを提供することによって、はるかに多くの仕事が、より少ない要求／応答対話を用いて実施できるようになる。
【０３２２】
図４０Ｂは、本発明の一実施形態による、自然言語認識を用いたシステム／クライアント対話ダイアログを示すフロー図４００７である。ステップ４００８で、システムは、「本日のご用件は何ですか？」という一般的な要求に関するプロンプトを出す。図４０Ａのステップ４００１の静的なプロンプトとは異なり、システムは、クライアントの動作を指定する必要はない。また、システムは、特に「発注をチェックする」または「ＣＤを購入する」などの属性を含む応答を利用することもない。例えば、ステップ４００９で、クライアントは、システムプロンプトに応答する代わりに、「マーシャルタッカーのグレーテストヒットは有りますか？」という、システム宛てのプロンプトで返答する。ステップ４００９の自然言語プロンプトには、重要だと考えられる２つのパラメータ、アーティスト名およびＣＤのタイトルが含まれている。音声アプリケーションは、パラメータを認識することができ、また重要なパラメータが、製品の入手性に関連する問合せの中に示されるという事実も認識している。重要なパラメータは、オントロジの属性と見なすことができる。
【０３２３】
ステップ４０１０で、システムは、要求されたＣＤの在庫が有り、同日出荷できることを述べる動的ダイアログで応答する。次にユーザは、ステップ４０１１で「似た曲は有りますか？」と尋ねる。システムは、ステップ４０１０の応答にまったく関連がない場合でも、４０１１のプロンプトを認識する。システムは、最初の要求に関する情報を保存し、この場合も音楽のクラスまたはジャンルの属性で、類似の音楽を演奏する最上位ランクのアーティストを検索する。
【０３２４】
ステップ４０１２で、システムは、クライアントに「グレッグオールマン（Greg  Allman）のアコースティックライブはいかがですか？」という旨の提案を行う。この場合、第２のＣＤに関する重要なパラメータは、どちらも、クライアントへの提案としてシステムによって提供される。ステップ４０１３で、クライアントは、その会社に両方のＣＤを各１枚ずつ送付するよう依頼することによって応答し、同じダイアログで返品条件について尋ねる。システムは、両方のＣＤの在庫を有しており、ステップ４０１３の応答の最初の部分の解釈によって、そのどちらもが現在クライアントから要求されている出荷可能な製品だと見なす。システムが、応答の第２の部分「返品条件は何ですか?」を処理している間に、オーダ準備をバックグラウンドで行うことができる。
【０３２５】
クライアントが、常に自分のビザカードで支払をすることを示唆する根拠があるので、システムは、ステップ４０１４の前に推論を実行する。したがって、ステップ４１０４では２つの部分の動的応答が示される。すなわち、「開封前の返品場合は全額返金します」と読まれる部分と「ビザに請求してもよろしいか？」と読まれる部分である。動的応答は、各々がステップ４０１３の内容を個別に処理する２つの個別の応答ダイアログを集めて組み立てることができる。ダイアログを組み合わせて複雑な自然言語プロンプトまたは応答を作成する機能は、一部には豊富なセマンティックを提供することにより、また一部には履歴データ、この場合は過去に使用された支払方法を分析して、クライアントの好みを推論することによって可能になる。ステップ４０１５で、発呼者は、「はい」および「ありがとう」と応える。
【０３２６】
当業者なら、インテリジェントな自然言語ダイアログとクライアントの好みの推論とを組み合わせたこの例が、トランザクションを処理する時間、およびクライアントとシステム両方の作業を削減するように機能することが理解されよう。推論は、音声アプリケーションダイアログ中に設定された任意の推論ポイントで起動されることができる。
【０３２７】
図４１は、本発明の一実施形態による、推論エンジンのコンポーネントを示すブロック図４１００である。ブロック図４１００は、いくつかのコンポーネントの論理ビューを表す。これらのコンポーネントの一部は、ネットワーク環境内にあるホストマシン以外のマシンに分散させることができる。本発明者は、単に例示のために、ソフトウェア層に関連する各コンポーネントを１つのアーキテクチャとして示す。アーキテクチャ４１００は、実際の配備では、本発明の趣旨および範囲を逸脱することなく、様々なコンポーネントを動作させるためにいくつかのマシンを使用することができるという了解の下で、上記の図３４のＩＥ３４２７および３４２８に類似している。
【０３２８】
アーキテクチャ４１００は、プレゼンテーション層４１０１、アプリケーション層４１０２、およびデータ層４１０３を備えている。プレゼンテーション層４１０１は、ダイアログの配布を制御し、推論状態を管理し送付するように構成される。コールフローマネージャ４１０４は、層４１０１内に提供され、呼出しの過程で推論がうまく実行されたときは、通常の音声アプリケーションダイアログの代わりに推論ダイアログを配布するなど、ライブセッションの間のコールフローを管理するように構成される。推論の場合は、コールフローマネージャ４１０４は、コールフロー内に任意の推論計算を挿入する。
【０３２９】
推論マネージャ４１０５は、プレゼンテーション層１４０１内に提供され、コールフロー内の推論ターゲット、より詳細にはプリトランザクションおよびポストトランザクション推論ポイントまたはトリガポイントを管理するように構成される。各トリガポイントで、推論エンジンが呼び出され、コールフロー内のそのポイントで推論を行うために十分な情報が使用可能かどうかを判定するための計算が実施される。計算は、発呼者の活動または現在の状態についての生の履歴データおよび／またはリアルタイムのセッションデータから取得された統計結果を比較し、それらの統計を、データ層４１０３内に示された各要素を含むパッケージされた推論データモデルと比較する。推論は、セッション推論、履歴推論、または履歴クロス推論であってもよい。セッション推論は、ライブセッションの過程でシステムにとって使用可能な実時間データの収集および分析に基づく、ダイアログの生成および配布をもたらす。履歴推論は、永続履歴データの分析に基づく、ダイアログの生成および配布をもたらす。履歴クロス推論は、複数の発呼者または一群の発呼者に共通の集約された履歴データセットに基づく、ダイアログの生成および配布をもたらす。推論はまた、発呼者について知られている実時間データと履歴データの両方に基づいて生成されることもできる。
【０３３０】
データ層４１０３は、推論モデルと考えることができる。データ層４１０３は、セマンティックインデックス４１１０、およびオントロジセット４１１１を含む。オントロジセット４１１１は、この例では、推論決定プロセスおよび最終的なダイアログ生成を支配する企業ビジネスルール、ならびに配布パラメータを含む。データ層４１０３はまた、知識ベース４１１２を含む。データ層４１０３は、先の図３４のアプリケーションサーバ３４１５に接続されたリポジトリに類似している。
【０３３１】
再び、層４１０１を参照すると、推論ルータ４１０６が提供されており、ライブセッションの適切なアクティブコールフローで使用される、選択された推論ダイアログを送付するように構成される。本発明の実際の実施においては、同じ時間帯に進行中の多数のライブセッションが存在することが理解されよう。同様に、進行中の各セッションは、進行の様々なステージに存在する場合があり、音声アプリケーションの様々なダイアログシーケンスを使用することができ、場合によっては様々な音声アプリケーションを使用することもできる。
【０３３２】
アプリケーション層４１０２は、ＡＸＭＬを汎用文法スクリプト（ＵＧＳ）に変換するように構成された汎用文法アダプタ（ＵＧＡ）４１０７をサポートする。汎用文法スクリプト（ＵＧＳ）は、ＸＳＬＴなどの変換言語を使用して、いくつかの既存のスクリプト言語のうちの１つに変換することができる。本発明の一実施形態では、ＵＧＡ４１０７は、１つまたは複数のリースされたＴＴＳ／ＳＴＴエンジンで使用することができる、新しい音声アプリケーションスクリプトを作成するために使用される。
【０３３３】
アプリケーション層４１０２は、その内部に提供された１つまたは複数の内部／外部データアダプタ４１０９を含む。この内部／外部データアダプタ４１０９は、通常、単一の企業で使用される異種のプラットフォーム間で、または２つの個別の企業間に存在する異種のプラットフォーム間で、マルチモーダルの意味でデータを変換するように構成される。
【０３３４】
本発明の一実施形態では、推論エンジン機能は、先に図２８に関連して説明した挙動適応エンジン２８０１の機能と統合される。
【０３３５】
図４２は、本発明の一実施形態による、クライアント／システムセッションの間に推論動作を実行するためのステップを示す処理フロー図４２００である。ステップ４２０１で、発呼者の動作が、推論ポイントでログされる。動作は、発呼者がシステムにアクセスし、システムに識別されるという場合もある。動作は、トランザクションポイントの前または後の、コールフロー内の他のいずれかのポイントでログされることができる。１つのコールフロー内に、複数の推論ポイントが存在してもよい。ステップ４２０２で、システムは、クライアントに関するデータにアクセスしそれを集約する。ユーザに関するデータは、発呼者識別データ、呼出し目的情報、および同一のセッションで発呼者によって以前に与えられた任意の実時間セッションデータなど、音声システムから収集された履歴動作に関連する統計値または実時間データの検出およびアクセスを単に含むことができる。
【０３３６】
コールフロー内の予め決められた推論ポイントで、アプリケーションは、図３４のエンジン３４２７および３４２８に類似した推論エンジンを呼び出す。ステップ４２０４で、システムは、推論を起動するために十分なデータが存在するかどうかを判定する。好ましい実施形態では、ステップ４２０４で計算が実施され、その結果によって、推論動作が起動されるか否かが決まる。ステップ４２０４で推論を実施しないと決定した場合は、ステップ４２０５で、システムは、セッションの間に動作する音声アプリケーションの標準のダイアロググループに進む。ステップ４２０８で、システムは、次の所定の推論ポイントを決定し、処理はステップ４２０３に戻る。
【０３３７】
ステップ４２０４で、システムが、推論を実施するのに十分な根拠が存在すると判定した場合は、ステップ４２０６で、実行のための推論ダイアログまたはダイアロググループを選択する。ステップ４２０４で実施される計算は、コールフローの性質に関連するデータ統計値を検出すること、およびそのデータ値をパッケージされた推論モデルと比較することを含むことができる。この推論モデルは、例えば、ある統計値についての閾値を含むことができ、その値に違反したときに、ステップ４２０６で実際の推論ダイアログ選択が起動される。一例として、履歴データによって、クライアントが、以前のシステムプロンプトで提供された複数のオプションのうちの特定のオプションを７０％の頻度で要求していることが検出された場合などである。このデータに基づいて推論を起動する閾値は、６０％でもよい。この場合、推論が実行されることになり、システムは、セッションに送られる次の標準ダイアログの代わりに推論ダイアログを選択する。ステップ４２０２で、計算は、予定される推論が、セッション推論か、履歴推論か、または履歴クロス推論かを決定する際に、あらゆる根拠要因を考慮することもできる。
【０３３８】
推論を受け取り、ステップ４２０７で、システムは、推論ダイアログを実行し、それをコールフローに挿入する。推論ダイアログは、標準ダイアログと大きく異なることがあり、音声アプリケーションにまったく新しい指示を引き受けさせることもある。好ましい実施形態では、プリトランザクション推論ポイントとポストトランザクション推論ポイントが存在する。推論ダイアログにより、特定の目的の達成として規定されたトランザクションポイントが生ずるものと考えることができる。トランザクションは、何らかの情報パラメータを要求し、それを受信することと単に規定することもできる。トランザクションは、１つまたは複数の製品に対する購入契約書を有効にするために必要なステップを含むことができる。企業の特定の目的が実現されるときはいつでも、それは、トランザクションと見なすことができる。
【０３３９】
ステップ４２０８で、システムは、次の推論ポイントを検出し、処理はステップ４２０３に戻る。推論エンジンは、進行中のセッションのコールフロー内で検出された各推論ポイントで呼び出されることができる。一実施形態では、発呼者に関するデータは、実時間で集約して使用可能にすることができるが、推論を保証する十分なデータが揃うまでは、必ずしも推論が起動される訳ではない。
【０３４０】
本発明の一実施形態では、推論ダイアログは、コールフロー内の特定のポイントで動作する推論の性質に基づいて実行時に生成される。例えば、生成されるダイアログは、２つの既存のダイアログをつなぎ合わせたものでもよい。豊富なセマンティックベースが使用されるいくつかの場合では、ダイアログは、組み合わされたときに所望のダイアログが生成される不完全なフレーズを選択することによって構成することもできる。
【０３４１】
本発明の方法および装置は、音声テキスト変換レンダリングおよびテキスト音声変換レンダリングが可能な任意の音声対応ポータルシステムに適用することができる。音声ポータルは、電話ネットワーク上で維持されるＣＴＩ対応ＩＶＲでも、データパケットネットワーク（ＤＰＮ）上で維持される音声サーバでもよいので、本発明の適用に関してネットワークの制約は存在しない。多くのアーキテクチャ上の可能性が存在する。
【０３４２】
上記に加えて、本発明の方法および装置は、本発明の趣旨および範囲を逸脱することなく、記載したコンポーネントのすべて、またはある組合せを備えることができ、また、本明細書で参照した１つまたは複数の明細書中に記載されている他のコンポーネントと統合することもできる。
【０３４３】
本発明の方法および装置には、多くの可能な実施形態および用途を考慮して、考えられる最も広い解釈が与えられるものとする。本発明の趣旨および範囲は、特許請求の範囲によってのみ制限される。
【図面の簡単な説明】
【０３４４】
【図１Ａ】従来技術によるＶＸＭＬ対応ＩＶＲ開発および配布環境の基本的なアーキテクチャを示すブロック図である。
【図１Ｂ】本発明を実施するように拡張された、図１Ａの基本アーキテクチャを示すブロック図である。
【図２】本発明の一実施形態による、ＶＸＭＬ音声アプリケーション用の音声アプリケーションシェルまたはコンテナを作成するための諸ステップを示す処理フロー図である。
【図３】本発明の一実施形態による、単純な音声アプリケーションコンテナを示すブロック図である。
【図４】本発明の一実施形態による、ダイアログオブジェクトモデルを示すブロック図である。
【図５】本発明の一実施形態による、ＶＸＭＬ対応音声アプリケーションの音声ダイアログ作成のための諸ステップを示す処理フロー図である。
【図６】本発明の一実施形態による、消費者との最初の接続後のダイアログ遷移フローを示すブロック図である。
【図７】本発明の一実施形態による、開発者のログイン画面を含む開発者のフレームの平面図である。
【図８】図７の開発者のプラットフォームインタフェースの、ホームページのスクリーンショットを含む開発者のフレームの平面図である。
【図９】前フレームである図８のセクション８０３のオプションであるアドレスを用いた対話によってアクセス可能な、アドレス帳９１１のスクリーンショットを含む開発者のフレームの平面図である。
【図１０】新しい音声アプリケーションを作成するための画面１００１を表示する開発者のフレームの平面図である。
【図１１】スクロールダウンの結果として、別のオプションを表示する図１０の画面を示す開発者のフレームの平面図である。
【図１２】本発明の一実施形態による、ダイアログ構成ページを示すダイアログ構成ウィンドウのスクリーンショットを示す図である。
【図１３】次の連絡先に対するダイアログ状態の進行を示す、図１２のダイアログ設計パネルに関するスクリーンショット１３００を示す図である。
【図１４】好ましい実施形態による、図１３の例から起動されたシソーラス構成ウィンドウのスクリーンショットを示す図である。
【図１５】本発明の一実施形態による、作成されたモジュールを管理するための画面を示す開発者のフレームの平面図である。
【図１６】本発明の一実施形態による、ウェブ取込み用に拡張された図６のダイアログ遷移フローのブロック図である。
【図１７】本発明の一実施形態による、自動化されたウェブ取込みとデータレンダリングのために追加されたコンポーネントを示す、図１Ｂの音声アプリケーション配布環境についてのブロック図である。
【図１８】オブジェクトモデルとして取り込まれかつ作成されたウェブサイトの論理階層を示すブロック図である。
【図１９】経済的レンダリングのためにモデルを単純化するように操作された図１８のモデルを示すブロック図である。
【図２０】ウェブサイト論理ツリーの複雑さを低減するための中間ステップを示す処理フロー図である。
【図２１】本発明の一実施形態による、音声ポータルとウェブサーバとの間の安全な接続性を示すブロック図である。
【図２２】本発明の一実施形態による、語彙管理サーバとソフトウェアで機能拡張された図１Ｂのアーキテクチャを示すブロック図である。
【図２３】本発明の一実施形態による、キャッシュ最適化コンポーネントを含むＶＸＭＬアプリケーションアーキテクチャの様々な機能コンポーネントを示すブロック図である。
【図２４】本発明を実施するための諸ステップを示す処理フロー図である。
【図２５】本発明の一実施形態による、テキスト音声変換プリプロセッサで拡張された図２３のＶＸＭＬアーキテクチャのブロック図である。
【図２６】テキスト文字列の音声レンダリングの可能な変化を示すブロック図である。
【図２７】本発明の一実施形態による、構成されたマッピングテーブルを示すブロック図である。
【図２８】本発明の一実施形態による、挙動適応エンジンで拡張された図２３のＶＸＭＬアーキテクチャのブロック図である。
【図２９】本発明の一実施形態による、図２８のシステムとのユーザ対話を示す処理フロー図である。
【図３０】本発明の他の実施形態による、図２８のシステムとのユーザ対話を示す処理フロー図である。
【図３１】本発明のさらに他の実施形態による、図８のシステムとのユーザ対話を示す処理フロー図である。
【図３２】本発明の一実施形態による、図２８の挙動適応エンジンの基本コンポーネントを示すブロック図である。
【図３３】様々なコアＶＭＸＬレンダリングエンジンに入力される様々なスクリプト言語間の従来技術での関係の概要を示す図である。
【図３４】本発明の一実施形態による、クライアント対話において目的推論を実施し、かつマルチスロットおよびマルチモーダルダイアログスクリプト記述のために汎用文法を使用する、通信ネットワークの一例示的アーキテクチャの概要を示す図である。
【図３５】ＸＭＬ形式で記述された汎用文法スクリプトの一例を示す図である。
【図３６】本発明の一実施形態による、ＸＳＬＴプログラムを使用してＧＲＸＭＬ言語に翻訳された図３５のＵＧＳの一例を示す図である。
【図３７Ａ】従来技術による音声システム／クライアント対話のダイアログフロー図である。
【図３７Ｂ】本発明の一実施形態による、マルチスロット言語変換によって拡張された図３７Ａのフローと同一内容のダイアログフロー図である。
【図３８Ａ】従来技術による静的システムプロンプトを論理的に表すテキストブロックを示す図である。
【図３８Ｂ】本発明の一実施形態による、推論によって生成かつ／または選択されたシステムプロンプトを示す図である。
【図３９Ａ】従来技術による、その後のクライアントアクセスの間に繰り返される静的システムプロンプトを示すフロー図である。
【図３９Ｂ】本発明の一実施形態による、過去のクライアントの活動からの推論に基づき、クライアントのために選択または生成される動的システムプロンプトを示すフロー図である。
【図４０Ａ】従来技術によるシステム／クライアント対話ダイアログを示すフロー図４０００である。
【図４０Ｂ】本発明の一実施形態による、自然言語認識を用いたシステム／クライアント対話ダイアログを示すフロー図である。
【図４１】本発明の一実施形態による、推論エンジンのコンポーネントを示すブロック図である。
【図４２】本発明の一実施形態による、クライアント／システムセッションの間に推論動作を実行するための諸ステップを示す処理フロー図である。
【図１Ａ】
2007524928.tif 000002
【図１Ｂ】
2007524928.tif 000003
【図２】
2007524928.tif 000004
【図３】
2007524928.tif 000005
【図４】
2007524928.tif 000006
【図５】
2007524928.tif 000007
【図６】
2007524928.tif 000008
【図７】
2007524928.tif 000009
【図８】
2007524928.tif 000010
【図９】
2007524928.tif 000011
【図１０】
2007524928.tif 000012
【図１１】
2007524928.tif 000013
【図１２】
2007524928.tif 000014
【図１３】
2007524928.tif 000015
【図１４】
2007524928.tif 000016
【図１５】
2007524928.tif 000017
【図１６】
2007524928.tif 000018
【図１７】
2007524928.tif 000019
【図１８】
2007524928.tif 000020
【図１９】
2007524928.tif 000021
【図２０】
2007524928.tif 000022
【図２１】
2007524928.tif 000023
【図２２】
2007524928.tif 000024
【図２３】
2007524928.tif 000025
【図２４】
2007524928.tif 000026
【図２５】
2007524928.tif 000027
【図２６】
2007524928.tif 000028
【図２７】
2007524928.tif 000029
【図２８】
2007524928.tif 000030
【図２９】
2007524928.tif 000031
【図３０】
2007524928.tif 000032
【図３１】
2007524928.tif 000033
【図３２】
2007524928.tif 000034
【図３３】
2007524928.tif 000035
【図３４】
2007524928.tif 000036
【図３５】
2007524928.tif 000037
【図３６】
2007524928.tif 000038
【図３７Ａ】
2007524928.tif 000039
【図３７Ｂ】
2007524928.tif 000040
【図３８Ａ】
2007524928.tif 000041
【図３８Ｂ】
2007524928.tif 000042
【図３９Ａ】
2007524928.tif 000043
【図３９Ｂ】
2007524928.tif 000044
【図４０Ａ】
2007524928.tif 000045
【図４０Ｂ】
2007524928.tif 000046
【図４１】
2007524928.tif 000047
【図４２】
2007524928.tif 000048