JP2015018238A - 自然言語理解のための自動音声認識プロキシシステム - Google Patents

Abstract

【課題】構成するＡＳＲコンポーネントの制限なしに、一貫して高品質な体験を提供する対話式システムを提供する。
【解決手段】対話式応答システムが、ＨＳＲサブシステムをＡＳＲサブシステムと混合して、音声ユーザインタフェースの能力全体を容易にする。システムは、不完全なＡＳＲサブシステムがそれでもなおＨＳＲサブシステムの負担を軽減できるようにする。ＡＳＲプロキシを使用してＩＶＲシステムが実行され、プロキシは、ＡＳＲの信頼性閾値や、ＨＳＲのための人間リソースの利用可能性などの要因に基づいて、いずれか特定の発話に対していくつのＡＳＲおよびＨＳＲサブシステムが認識を実行すべきかを動的に決定する。
【選択図】図１１

Description

本発明は、対話式応答通信システムの分野に関し、より詳細には、発話を自動音声認識（ＡＳＲ）プロセッサ、人間音声認識（ＨＳＲ）リソース、またはＡＳＲ機構とＨＳＲ機構の両方に、選択的にルーティングする対話式応答通信システムに関する。

関連出願
本出願は、2011年1月5日に出願された「Automated Speech Recognition System for Natural Language Understanding」という名称の米国特許出願第12/985,174号明細書の一部継続出願である、2011年3月24日に出願された「Automated Speech Recognition Proxy System For Natural Language Understanding」という名称の、本願の所有者が所有する同時係属の米国特許出願第13/070,865号明細書（現米国特許第8,484,031号明細書）の一部継続出願であり、この出願に対して米国特許法第１２０条に基づき優先権を主張する。上記で参照した出願の内容は、本明細書に完全に記載されているかのように、参照により本明細書に組み込まれる。

多くの会社は、電子的手段（最も一般的には、電話、Ｅメールおよびオンラインテキストチャット）によって顧客と対話する。このような電子システムは、必要な顧客サービスエージェントまたはサポートエージェントの数を制限することにより、会社にとって多くの金銭を節約する。しかし、これらの電子システムが提供する顧客体験は一般に、満足には及ばないものである。顧客体験は、単純なトランザクションの場合には容認できることもあるが、顧客がコンピュータに話しかけることまたはコンピュータと対話することに熟達していない場合は、辻褄が合わないかまたは全くもどかしいものであることが多い。

このような対話式応答システムは、当技術分野で周知である。例えば、対話式音声応答（ＩＶＲ）システムを使用して電話を介して顧客サービスを提供することは、このようなシステムの１つである。ＩＶＲ技術を利用した顧客サービスシステムの例が特許文献１に記載されている。ＩＶＲシステムは通常、一連の録音済みフレーズを使用して顧客と通信し、いくつかの口頭入力およびタッチトーン信号に応答し、また、電話をルーティングまたは転送することができる。このようなＩＶＲシステムの欠点は、これらが通常は「メニュー」構造を中心に構築されていることであり、この構造は、一度にわずかな有効オプションしか発信者に提示せず、また、発信者からの狭い範囲の応答を必要とする。

これらのＩＶＲシステムの多くは今や、音声認識技術を組み込んでいる。音声認識技術を組み込んだシステムの例が特許文献２に記載されている。ＩＶＲシステムによって使用される音声認識技術の頑強性は様々だが、これらが聞こうとする、かつ理解できる応答は、所定範囲の応答であることが多く、このことは、エンドユーザが日常語でシステムと対話する能力を制限する。従って、発信者はしばしば、「コンピュータに話しかけているかのように」システムに話しかけることを余儀なくされているように感じることになる。さらに、音声認識を利用するシステムと対話しているときでも、顧客入力はしばしば認識されないかまたは間違って決定され、それにより顧客は、できるだけ早く人間の顧客サービスエージェントと接触することを求める。

より入り組んだ顧客サービス要求のために、人間の顧客サービスエージェントが使用され続けている。これらのエージェントは、顧客に電話で話しかけ、顧客のＥメールに応答し、および顧客とオンラインでチャットすることができる。エージェントは通常、顧客の質問に答えるか、または顧客の要求に応答する。会社は顧客サービスグループを有するが、これらは「顧客リレーションマネジメント」を専門にする会社に外部委託されることもある。このような会社は、何百人ものエージェントがスタッフとして配置されるセンタを運営し、これらのエージェントは、１日の全勤務時間を、電話をして過ごすかまたは他の方法で顧客と対話して過ごす。このようなシステムの例が特許文献３に記載されている。

顧客サービス対話の典型的なモデルは、１人のエージェントが、顧客対話の継続時間にわたって顧客を援助するものである。時には、顧客が複数の要求について助けを必要とする場合、あるエージェント（例えば技術サポート担当者）が顧客を別のエージェント（販売担当者など）に転送することもある。しかし一般には、１人のエージェントが、顧客の電話またはチャットセッションの全継続時間にわたってこの１人の顧客の援助に自分の時間を費やすか、または、Ｅメールを介して顧客の問題を解決することに専念する。また、ほとんどのコールセンタは、エージェントが通話のログをとる（記録を残す）ために時間を割くものと考える。この重いエージェントインタフェースモデルの欠陥は、（１）エージェント離職者率が高いこと、並びに（２）通例、多くの初期および継続的なエージェントの訓練が必要であることであり、これらの全てにより、顧客サービスは結局、これらの顧客サービス提供者にとってかなりの出費になる。

エージェント関連の出費を軽減するために、組織によっては、その顧客サービスニーズを外部委託する。高速光ファイバ音声データネットワークの急増に伴う、近年の米国における傾向の１つは、より低い労働コストを利用するために顧客サービスセンタを海外に配置することである。このような外部委託は、海外の顧客サービスエージェントが英語を流暢に話すことを必要とする。これらのエージェントが電話ベースのサポートに使用される場合、エージェントが英語ではっきりと理解し話すことができることがしばしば課題になる。海外への外部委託の不幸な結果は、サービスを求める人にとっての、誤解、および、満足に及ばない顧客サービス体験である。

改良された対話式応答システムは、コンピュータによって実施される音声認識を、人間エージェントの断続的使用と一体化する。ある程度、これは何年も行われてきた。人間の係員と自動音声レコグナイザの両方を使用するシステムが扱われている（特許文献４）。同様に、ユーザの発話を人間によって解釈する必要のある通話部分のみが、人間エージェントに提示されるシステムが開示されている（特許文献５）。これらの特許の内容、並びに本明細書で言及する他の全ての技術は、本明細書に完全に記載されているかのように参照により本明細書に組み込まれる。このようなシステムの利益は、そのコストが比較的低ければ高まり、この低コストは一般に、限られた人間対話しか必要としないものである。このような限られた人間対話を達成するには、最小限の初期訓練しか必要とせず、時の経過に伴って結果が向上し続けるシステムを有することが望ましいであろう。特に、本番使用に適する「初日からの」性能をもたらし、時の経過に伴って効率が素早く向上する学習／訓練システムが、とりわけ価値があるであろう。

多くの既存のＡＳＲシステムは、システムの各特定ユーザの声を認識するように訓練される必要性、または妥当な結果を提供するために認識語彙を厳しく制限する必要性など、かなりの訓練制約を被る。このようなシステムは、ユーザによって人工的と認識されやすい。典型的な人間プロンプト「ご用件をどうぞ。」と、人工的なプロンプト「予約したい場合は「したい」と、予約状況を確認したい場合は「状況」と、予約をキャンセルするには「キャンセル」と言って下さい。」との間の相違を考察されたい。

ＡＳＲ（自動音声認識）による音声システムの目標は、「２００１年宇宙の旅」の中のＨＡＬによく似た、発信者対話を実施するための会話システムを達成することであった。ＡＳＲ機能を改善するために、音声ユーザインタフェース（ＶＵＩ）技法が開発された。これにより、より高精度の音声認識を達成するために、使用される語彙を削減しようとして、かつ発信者が話さなければならない単語に関するヒントを発信者に与えようとして、プロンプトが正確かつコンパクトに表現される。それ以来、ＡＳＲは向上し、今や自由回答式の会話認識にも対処する。しかし、このような自由回答式の会話は、より多い語彙を必要とし、その結果、音声認識エラー率はずっと高くなる。結果的に、ＩＶＲシステムに対するより多くの不満および軽蔑の念が発信者に残る。これは例えば、前に何が述べられ理解されたかを過度に確認すること、間違った選択を行うこと、および発信者を前のメニューに戻らせることに基づく。ＶＵＩ設計は、会話を一般から特定に絞り込もうとして、発信者をいわゆる「ディレクテッドダイアログ」に導こうと試みる。小さい領域は、語彙が限られ発話レパートリが相対的に著しく小さいので、ＡＳＲおよびＮＬＵは、ディレクテッドダイアログに適用されたときは、より成功してきた。ＩＶＲ業界は、音声認識による統計および「探索」を使用して知識領域を特徴付けて、理解をさらに高めることに取り組んでいる。しかし、これらの手法はなお、かなりの数の発信者、特に、個人化されたＡＳＲ音響モデルを構築するなどの複雑な技法を使用しても理解が困難な方言または発音パターンを有する発信者を、うまく扱わない。人間援助型認識の登場に伴い、今や、自動化と共に人間の理解を活用して音声、テキスト、グラフィックス、およびビデオを認識する機会があり、これにより、理解がより正確になり、ＡＳＲベースのＩＶＲシステムの弱点の多くが回避される。ＩＶＲシステムの根本的なタスクは、ユーザ要求に対応する様々な用件フォーム中の情報スロットを埋めるのを調整することである。従来のＩＶＲシステムでは、この調整は通常、あらかじめ固定された決定木に従って実施され、ユーザと対話するための限られた数の方法からの逸脱はほとんどない。ＶＵＩ設計の変形や、正確な理解をうまく識別するために最適化する種々の基準や、可能な最短の時間で理解および認識する技法を含めた、種々の認識戦略が開発されてきた。

発信者と、人間援助型認識を使用する自動システムとの間の対話をできるだけシームレスかつ自然なものにするために様々な適切な技法をシステムが使用することには、多くの理由がある。

人間は、自動音声認識（ＡＳＲ）、グラフィックスおよびビデオ処理、並びに自然言語理解（ＮＬＵ）技法よりも、ずっと高い精度で意味を認識し解釈する。自動化の精度が不十分なときに人間を用いて理解することができるならば、かなり多くのユーザ対話を自動化しながらもなお、良いユーザ体験を提供することが可能になる。しかし、コンピュータリソースは、異常な予測されないボリュームピークを満たすようにスケールすることができるが、人間リソースは、そうしたコンピュータリソースとは異なり、スケジュールされる必要があり、ピークに合うようにタイミングよく利用可能ではないことがある。従って、精度が十分でないときにはＤＴＭＦ（dual-tone multi-frequency）も使用して、システムがどんな特定の適用例での必要ＨＳＲ量にも自動的に合わせ、それによりＨＳＲの使用を最小限に抑えることが必要とされている。予定外のピーク中に人間の対話が変化することになっても、より従来式のやり方でセルフサービスを実施し続けることができる。

目標は今や、どのように人間援助と自動化を組み合わせて発信者の発話を最もよく認識および解釈すると同時に可能な最も人間らしいユーザ体験を達成するかということになるが、音声認識を整調し、認識された発話を分類して、最高の認識レベルを達成するのに使用される従来技法は、微妙だが重要な形で変化する。従って、既存のシステムによって対処されない難題は、最もうまくいくユーザ体験を提供しながら、所与の作業負荷の下における所与の状況でどのように人間と自動化との最も効率的な組合せを使用するかである。

従来、ＡＳＲシステムは、発話されるのに伴って、それを「聞く」のを開始する。認識自動化が失敗した場合は、ユーザは、完全な発話が話されるのにかかる時間長にわたって待機することになり、その後、ＨＳＲが、聞くのを開始してそれを処理することになる。そうではなく、システムがリアルタイムに近い形で対話を理解しようとすることができれば望ましいであろう。例えば、ユーザがどんどん単語を話してそれらの意味（または「意図」）を記述するのに伴い、まずＡＳＲによって処理され、次にＨＳＲによって処理される結果、発話の終わりと応答の始まりとの間にかなりの時間ギャップが生じる。この時間ギャップは、例えば、タイピング音などのオーディオ再生で埋めることもできる。これは適用例によってはうまくいく可能性があり、特に、データを収集する適用例ではうまくいく可能性がある。他の適用例では、この時間ギャップにより、システムと自然な会話を続けるのが困難になる。加えて、話が長いほど認識品質が低くなることも多い。話が長いほど、話に含まれる単語が多いだけでなく単語結合も多い。まとめると、これらにより、音声認識エラーが増加し、理解の精度が低下する。

従って、人間援助を使用する前にできるだけ早く理解してうまくいく認識を予測し、人間らしい対話を維持することのできる、自動認識システムが必要とされている。さらに、人間援助が求められる場合もあるので、この自動認識システムはまた、人間援助のスタッフ配置を監視して、システムステータス負荷および人間援助スキルセット能力に応じて、理解の信頼度を自動的に調節することおよび／または完全な自動化に進むことができることも必要とする。

自然言語理解（ＮＬＵ）システムなど、より大がかりなシステムは、使用可能な結果をより大きな文法および語彙から得るために、骨の折れる手仕事による文法記述の多大な機械学習期間を必要とする。特に、語彙が動的である可能性のある環境（新しい演劇、または新しい音楽グループによるコンサートの、チケット注文をとるシステムなど）では、学習期間は、満足のいく結果をもたらすためにはあまりにも長すぎることがある。アクセント、方言、語彙および文法の地域差などを含めると、このようなシステムが認識精度の妥当な閾値を達成できるようにシステムに教えるタスクは、さらに複雑になる。

現在利用可能なＡＳＲシステムは、数、データ並びに単純な文法（すなわち、小さい単語のセット、およびそれらからなる表現）など、単純な口頭の発話を認識するのには効果がある。しかし、今までのところ、ＡＳＲシステムは、自由に流動する会話を提供する音声インタフェースを生み出すだけの十分に高いレベルの音声認識性能を提供していない。加えて、ＡＳＲ性能は、上述したようなアクセントや方言によって劣化するだけでなく、背景雑音、子供の声よりも大人の声、および多くの場合に男性の声よりも女性の声によっても劣化する。ＡＳＲ性能は時の経過に伴って向上しており、あるシステムは、発信者からの極めて幅広い応答を認識するように意図された統計言語モデルを使用し、従って発信者は、非常に制約された話し方で話すのではなく自然に話すときでも認識されることが可能である。そうであっても、ＡＳＲ性能は依然として人間同士の実際の対話には匹敵しておらず、最高レベルの性能を提供するＡＳＲシステムは、時間がかかり、構築して特定の適用例に整調する（tune）のが高価である。

予想される様々な回答の統計的確率並びに類義語を考慮することによって文法を整調することは、ＡＳＲ性能を向上させるために使用される技法の１つである。別の技法は、統計言語モデルを作り出すことだが、これは、生のオペレータとの生の電話会話の発話の録音を文字に起こすためのかなりの労力を必要とする可能性がある。ＡＳＲ性能は、ある適用例ではかなり許容できるが、他の適用例ではまだ適さず、従って、知られているＡＳＲベースのシステムは依然として、制約されない自然な発話を理解する能力に欠ける。

従って、構成するＡＳＲコンポーネントの制限なしに、一貫して高品質な体験を提供する対話式システムが、依然として当技術分野で必要とされている。

米国特許第６，４１１，６８６号明細書 米国特許第６，４９９，０１３号明細書 米国特許第５，９８７，１１６号明細書 米国特許第５，０３３，０８８号明細書 米国特許第７，６０６，７１８号明細書

対話式応答システムが、ＨＳＲサブシステムをＡＳＲサブシステムと混合して、自然言語理解を容易にし、音声ユーザインタフェースの能力全体を改善する。このシステムは、不完全なＡＳＲサブシステムが、必要時にＨＳＲを使用でき、それでもなお、負荷がかかっているＨＳＲサブシステムの負担を軽減できるようにする。ＡＳＲプロキシを使用してＩＶＲシステムが実現され、このプロキシは、一連の規則に基づいて、発話を１つのＡＳＲのみにルーティングすること、発話を少なくとも１つのＡＳＲに加えてＨＳＲにもルーティングすること、発話を１または複数のＨＳＲサブシステムのみにルーティングすること、ＡＳＲに元々送られた発話をＨＳＲにルーティングし直すこと、ＨＳＲを使用して１または複数のＡＳＲの整調および訓練を補助すること、並びに、複数のＡＳＲを使用して結果の信頼性を高めることを決定する。

一態様では、ＡＳＲプロキシは、認識決定エンジンおよび結果決定エンジンを備える。関連する一態様では、この２つのエンジンは、様々な用件フォーム中の情報スロットを正確に埋めるために、認識性能、自然言語理解、並びに認識および文法整調を容易にする。

さらに別の態様では、ＡＳＲプロキシは、アプリケーション基準と、認識信頼度予測と、履歴結果と、特定ユーザの声で経験される認識とのうちの、１または複数に基づいて、ＡＳＲリソースおよび／またはＨＳＲリソースを選択する。

さらに別の態様では、ＡＳＲプロキシは、ＡＳＲの使用を最大限にすること、またはやりとりをより「人間らしい」若しくはより「人間らしくない」ものにすることなど、様々なパラメータに基づいて構成可能である。

さらに別の態様では、ＡＳＲプロキシは、ＨＳＲのシステムリソースキャパシティに自動的に合わせて、ＡＳＲまたはＤＴＭＦの使用を最大限にする。

さらに別の態様では、ＡＳＲプロキシは、ＡＳＲ結果を分析する評価コンポーネントの結果を使用して、長さベースのテストに対する最適な長さと、種々のプロンプトへのユーザ応答に対する最適な品質測定基準レベルと、種々のプロンプトに対する最適な分類器とのうちの、１または複数を選択する。

さらに別の態様では、ＡＳＲプロキシによるＡＳＲリソースまたはＨＳＲリソースの選択は、ＡＳＲプロキシに音声認識を要請するソフトウェアアプリケーションにはトランスペアレントである。

さらに別の態様では、このシステムは、ＨＳＲ使用時のリアルタイムに近い形で、うまくいく自動認識を予測する方法を使用して、より人間らしい体験を維持する。

本開示において対象とされる特定の構成を他の様々な方式でも実現できることは、当業者なら認識するであろう。特段に定義しない限り、本明細書で使用される全ての技術用語および科学用語は、本開示の属する技術分野の当業者によって一般に理解されるのと同じ意味を有する。

前述の特徴は、本開示の範囲を逸脱することなく、単独でまたは組み合わせて使用することができる。本明細書に開示するシステムおよび方法の他の特徴、目的および利点は、後続の詳細な記述および図から明らかになるであろう。

さらに他の特徴および様々な利点は、添付図面と共に後続の詳細な記述を読めば明らかになるであろう。図面全体を通して、同じ参照文字は同じ部分を指す。
対話式応答システムのアーキテクチャの一実施形態を示すブロック図である。 顧客と対話式応答システムと人間インタフェースとの間の通信の方法の一実施形態を示すフローチャートである。 図２のコンテキストにおける、顧客／対話式応答システムの対話の一実施形態を示すチャートである。 図２のコンテキストにおける、顧客意図およびデータをキャプチャするための一実施形態を示すコンピュータ画面ユーザインタフェースの図である。 図２のコンテキストにおける、顧客／対話式応答システムの対話の一実施形態を示すチャートである。 図２のコンテキストにおける、顧客意図およびデータをキャプチャするための一実施形態を示すコンピュータ画面ユーザインタフェースの図である。 図２のコンテキストにおける、顧客／対話式応答システムの対話の一実施形態を示すチャートである。 図２のコンテキストにおける、顧客意図およびデータをキャプチャするための一実施形態を示すコンピュータ画面ユーザインタフェースの図である。 対話式応答システムのコンテキストでＥメールを処理するフローチャートである。 訓練サブシステムを有する対話式応答システムのアーキテクチャの一実施形態を示すブロック図である。 ＡＳＲ訓練に関する例示的な処理フロー８００の図である。 本明細書で参照されるコンピュータ／プロセッサのいずれかとして使用されるコンピュータ９００の例を示す高レベルのブロック図である。 異なる意図分析者によってオーディオストリームの意図およびデータを認識することのタイムライン表現の図である。 ＡＳＲプロキシと対話するアプリケーションのブロック図であり、プロキシの主要なコンポーネントを示す図である。 ＡＳＲを使用するかＨＳＲを使用するかまたは両方を使用するかを決定するための、認識決定エンジンのプロセスおよび決定フローを示す流れ図である。 単一のＡＳＲを使用する結果決定エンジンのプロセスおよび決定フローを示す流れ図である。 複数のＡＳＲを使用する結果決定エンジンのプロセスおよび決定フローを示す流れ図である。 ＡＳＲとＨＳＲの両方を使用する結果決定エンジンのプロセスおよび決定フローを示す流れ図である。 ＨＳＲを使用する結果決定エンジンのプロセスおよび決定フローを示す流れ図である。 自動認識および人間援助認識による応答ギャップを示す時系列の図である。 アプリケーション、およびＡＳＲプロキシとの対話のブロック図であり、ＡＳＲプロキシの主要なコンポーネントを示す図である。 認識に関する統計とシステムステータスに関する情報とを用いた認識決定および結果決定のプロセスおよび決定フローを示す流れ図である。 ＡＳＲ統計とシステムステータスとを用いた認識決定および結果決定を示す流れ図である。 タイマＡＳＲ統計とシステムステータスとを用いた認識決定および結果決定を示す流れ図である。 予測器認識ＡＳＲ統計とシステムステータスとを用いた認識決定および結果決定を示す流れ図である。 統計を生み出すためのプロセスを示すフローの図である。 統計を生み出すためのいくつかの認識最適化基準の例を示す図である。

まず、図１〜図１０に従って、対話式応答システム並びに関連する機械学習システムおよびプロセスの動作についての記述を提供する。その後、図１１〜図１６に従って、ＡＳＲプロキシシステム並びにそれに関連するプロセスの動作についての記述を提供する。図１７〜図２４および対応する考察は一般に、ＡＳＲプロキシを最適化するプロセスに関し、目標は、コンピュータ認識の自動化と人間援助型認識との組合せを最適化すると同時にユーザ体験を向上させることである。特段に明白でない限り、本明細書で使用される用語「意図」および「意味」は、発話に対応するコンテキスト上の理由を指すことに留意されたい（例えば、新しいフライト予約をするという発信者の用件意図をシステムに決定させる）。対照的に、用語「認識する」およびその派生語は一般に、本明細書では、音をそれに対応する単語に変換するプロセスに使用される。

人間援助型決定エンジンを使用して、マルチチャネルおよびマルチモーダルシステムが実現される。これは、「対話」を自動化にルーティングした後で、かつ自動化からの予測結果に応じて、予測データおよびキャパシティ要因のセットに基づいて、自動認識の競合の前であってもＨＳＲの使用を決定する。ある実施形態では、システムは、「発話」または「ビデオ」を自動的に加速させ、自動化と人間援助との間の時間ギャップをさらに短縮する。

プロンプトに対する応答の解釈は、テキスト分析の２つの種類、すなわち情報抽出およびセンス分類として見ることができる。情報抽出は、顧客ＩＤ、電話番号、日時、住所、製品タイプ、問題など、用件フォームのスロットを埋めるのに不可欠な特定の情報断片を、識別、抽出および正規化することである。センス分類は、追加の２つの情報タイプ、すなわち意味（意図）および応答品質を識別することに関係する。意味（意図）は、どんな種類のフォームを埋める必要があるかということと関係がある（料金請求、予約のスケジューリング、苦情など）。応答品質は、応答自体と関係がある（不明瞭、雑音、英語ではなくスペイン語、生のエージェントと話したいという要望など）。

この応答解釈は、意図分析のみ（純粋なＨＳＲ）によって行うか、自動化（ＡＳＲおよび意図分類）によって行うか、またはＡＳＲとＨＳＲの何らかの組合せによって行うことができる。ＡＳＲ自動化の結果における信頼度測定基準を使用して、いつＡＳＲが信頼性のある結果を生成しているかを決定することで、限定的な品質損失でまたは品質損失なしに、ＡＳＲ自動化をＨＳＲに対してトレードオフすることが可能である。このことは、プロキシ処理システムにおけるこの２つの手法の組合せにより、ＨＳＲのみを使用する場合よりも大きなスループットを達成することができ、より小さい意図分析者チームでピーク需要負荷を処理できることを意味する。

図１は、対話式ルータ１０１（以下「ｉルータ」と呼ぶ）を介して対話プラットフォーム１０２を対話式応答システム１００に接続するアーキテクチャの一実施形態を示す。図１に示すように、対話プラットフォーム１０２は、通信リンク１０４を介して顧客１０３に接続される。対話プラットフォーム１０２はまた、データリンクを介してｉルータ１０１において対話式応答システム１００に接続され、データリンクは、この例示的な実施形態ではＴＣＰ／ＩＰデータリンクを含む。この例示的な実施形態における対話プラットフォーム１０２は、コンピュータサーバを含む。コンピュータサーバの正確な構成は実装形態によって異なるが、通常は、Ｄｉａｌｏｇｉｃ（登録商標）などのベンダからの音声ボードを使用してＷｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）などのオペレーティングシステムを実行するＰｅｎｔｉｕｍ（登録商標）ベースのサーバからなる。対話プラットフォーム１０２はまた、Ｅメールゲートウェイまたはウェブサーバとすることもできる。従って、顧客入力は、電話または構内通話を介して対話式応答システム１００に入り、テキストは、Ｅメールまたは対話式チャットインタフェース（例えば、ウェブページ、若しくはＹａｈｏｏ Ｍｅｓｓｅｎｇｅｒなどのスタンドアロンアプリケーション）を介して入力される。

図１のアーキテクチャでは、様々な実施形態で、いくつかの異なるタイプのデバイスを使用して対話プラットフォーム１０２および通信リンク１０４の各々が実現される。対話プラットフォーム１０２は、顧客１０３と通信できる任意のデバイスによって実現することができる。例えば、対話プラットフォーム１０２は、一実施形態では、対話式応答システム１００中の電話サーバであり、この場合、顧客は電話をかけている。電話サーバは、入来呼の応答、転送および切断を扱う。電話サーバはまた、事前録音済みオーディオクリップのための倉庫であり、従って電話サーバは、任意のウェルカムプロンプト、およびｉルータ１０１によって指示された他のオーディオクリップを再生することができる。

本実施形態による電話サーバは、オフザシェルフ（off the shelf）コンポーネントから、例えば、オペレーティングシステムとしてのＷｉｎｄｏｗｓと、Ｐｅｎｔｉｕｍプロセッサなどの中央処理装置と、Ｉｎｔｅｌ（登録商標）Ｄｉａｌｏｇｉｃ音声ボードとから組み立てられる。このアーキテクチャを使用した場合、通信リンク１０４は、顧客の電話と電話サーバの間のインタフェースを提供する任意の手段によって実現される。例えば、通信リンク１０４は、様々な実施形態で、ダイヤルアップ接続または双方向ワイヤレス通信リンクである。

別の例示的な実施形態では、対話プラットフォーム１０２は、対話式応答システム１００中のゲートウェイサーバである。この例示的な実施形態によれば、顧客は、Ｅメール、対話式テキストチャットまたはＶＯＩＰによって、対話式応答サーバと対話する。ゲートウェイサーバは、カスタマイズドオープンソースＥメール、ｗｗｗサーバソフトウェアまたはＳＩＰを実行する。さらに、この例示的な実施形態によるゲートウェイサーバは、Ｅメール、対話式テキストチャットまたはＶＯＩＰトランザクションを顧客と行うとともに、システムの他の要素とのデータ転送および受信もするように設計される。このアーキテクチャを使用した場合、通信リンク１０４は、顧客のコンピュータとゲートウェイサーバとの間のインタフェースを提供する任意の手段によって実現される。例えば、通信リンク１０４は、様々な実施形態で、専用インタフェース、単一のネットワーク、ネットワークの組合せ、ダイヤルアップ接続またはケーブルモデムである。

図１には対話プラットフォーム１０２が１つしか示されていないが、本明細書を検討した後には、複数の対話プラットフォーム１０２をこのシステム中で使用できることを当業者なら理解するであろう。対話プラットフォーム１０２が複数ある場合、対話式応答システムは、音声およびテキストデータを介して顧客と通信することができる。さらに、顧客ベースごとの専用対話プラットフォーム１０２によって、複数の顧客ベースに対応することもできる。このようにして、複数の対話プラットフォーム１０２のうちのどれが対話を開始したかを決定することによってワークフロー（後で詳述する）が選択される。

図１のアーキテクチャでは、ｉルータ１０１は、対話式応答システム１００を制御するソフトウェアを備える。ｉルータ１０１は、他のコンポーネント間のアクティビティを調整しトランザクションを管理することによって、顧客１０３との対話を始めから終わりまで「所有する」。ｉルータ１０１は、１または複数のプログラム可能スクリプト（この例示的な実施形態によれば「ワークフロー」と呼ばれる）に従って、顧客１０３との対話を管理する。一般に、ワークフローは、ワークフローを通る経路が、顧客から入力された意図に依存するような、対話フローを含む。ワークフローは、システムエンジニアによって事前にプログラムされ、有利には、顧客満足や速度や精度などを向上させるために定期的に「小改良」される。この例示的な実施形態によれば、ｉルータ１０１は、ほぼ常に、ワークフロー中の次のステップまたは経路を選択することを「受け持っている」。

ｉルータ１０１は、顧客コミュニケーションの形に応じて、オーディオクリップ、Ｅメール、テキストデータまたは他の対話タイプの形で、対話プラットフォーム１０２から入力された対話を受信する。ｉルータ１０１は、この入力を、１または複数の人間エージェント１０５（「意図分析者」すなわち「ＩＡ」と呼ばれることもある）、音声認識エンジンまたはエキスパートシステム（まとめて１０８、また「自動音声レコグナイザ」すなわち「ＡＳＲ」と呼ばれることもある）に転送し、応答を利用してその現在のワークフローを進める。入力を人間によって解釈（または翻訳）することが必要なときは、ｉルータ１０１は、現在のワークフローの適切な視覚コンテキストを表示するよう、人間エージェントのデスクトップソフトウェアに指示する。ｉルータ１０１が入力を理解すると、ｉルータ１０１は、ワークフローの中を進み、対話プラットフォーム１０２に、顧客１０３に適切に応答するよう指示する。

対話プラットフォーム１０２が電話サーバを含む例示的な一実施形態では、ｉルータ１０１は、顧客に対して再生するためのサウンドクリップを送るか、テキスト−音声クリップを送るか、またはこの両方を送る。あるいは、対話プラットフォーム１０２は、サウンドクリップを記憶することができるか、テキスト−音声機能を有することができるか、またはこの両方とすることができる。この実施形態では、ｉルータは、顧客に対して何をいつ再生するかについて、対話プラットフォーム１０２に指示する。

ｉルータ１０１は、この例示的な実施形態では、ＷｉｎｄｏｗｓやＬｉｎｕｘなどのオペレーティングシステムを実行するネットワーク化されたオフザシェルフの市販プロセッサを備える。さらに、ｉルータ１０１のソフトウェアは、特定の適用例に適したオブジェクトを組み込んだ、修正されたオープンＶｏｉｃｅＸＭＬ（ＶＸＭＬ）ブラウザおよびＶＸＭＬスクリプトを含む。本明細書を検討した後には、これらのオブジェクトをどのように構築するかを当業者なら理解するであろう。

図１の例示的なアーキテクチャによれば、対話式応答システム１００は、人間エージェント１０５の少なくとも１つのプールを含む。人間エージェント１０５のプールはしばしば、コンタクトセンタ所在地に位置する。人間エージェント１０５は、本発明のこの実施形態によれば、システム１００に特有の特殊化されたデスクトップソフトウェア（図３Ｂ、図４Ｂおよび図５Ｂに関してさらに後述する）を使用し、このソフトウェアは、可能性ある意図の集まりを、その時点までの顧客対話の履歴またはコンテキストと共に、それらの画面（それらのユーザインタフェース）上に提示する。１または複数の人間エージェント１０５は、入力を解釈し、適切な顧客意図、データ、またはこの両方を選択する。

電話対話の場合、人間エージェント１０５は、ヘッドホンを装着し、ｉルータ１０１の指示で電話サーバ１０２からストリーミングされるサウンドクリップ（「発話」）を聞く。本発明の一態様によれば、単一の人間エージェント１０５が顧客１０３に関するトランザクション全体を扱うことにはならない。そうではなく、人間エージェント１０５は、顧客１０３の発話を人間によって解釈することが必要であるものとしてワークフローデザイナによって指定された、トランザクションのいくつかの部分を扱う。ｉルータ１０１は、同じ顧客１０３対話を任意の数の人間エージェント１０５に送ることができ、所与の対話の一部を多くの異なる人間エージェント１０５に分配することができる。

本発明の例示的な実施形態によれば、人間エージェント１０５はオフサイト（Off site）であることが好ましい。さらに、人間エージェント１０５は、インド、フィリピンおよびメキシコなど、世界の種々の地理エリアに存在してよい。人間エージェント１０５は、建物内で集団になっていてもよく、または自宅から作業していてもよい。年中無休の人間エージェントサポートを必要とする適用例では、各人間エージェント１０５が適切な業務時間中に作業できるように、人間エージェント１０５を世界中に配置することができる。

本発明の対話式応答システム１００は、カスタム人間エージェントアプリケーションソフトウェアを利用する。人間エージェント１０５は、Ｊａｖａで開発され標準的なコールセンタコンピュータネットワークのワークステーション上で実行される、カスタムアプリケーションを使用する。概して言えば、対話式応答システム１００は、顧客１０３の入力の解釈に向かう人間の知能を、「意図」（顧客が何を欲するか）およびデータ（顧客が何を欲するかを決定するのに必要な任意のデータ）に適用する。解釈は通常、この例示的な実施形態では、何が言われたかについての最も正しい解釈を選択肢のリストから選択することを含む。代替の一実施形態では、コンピュータ支援型データ入力（例えば、テキスト入力またはＥメールアドレス入力のオートコンプリート）が、エージェント処理と共に使用される。

オフザシェルフコンポーネントである本発明のワークフローサーバ１０６は、対話ルータによって使用されるワークフローのアーカイブである。ワークフローサーバ１０６は、一実施形態では、標準的なサーバオペレーティングシステムを実行する市販のプロセッサを使用して、オフザシェルフハードウェアによって構築され、この例示的な実施形態では、ワークフロードキュメントはＸＭＬで書かれる。ワークフローサーバ１０６は、ｉルータ１０１の挙動を統制する業務規則のまとまりを維持する。

対話式応答システム１００は、ワークフローを策定するためにビジネス分析者またはプロセス技術者によって使用されるワークフローデザイナを利用する。ワークフローは、音声認識とのまたは人間エージェントとの所与の対話においてｉルータ１０１が従うマップとしての働きをする。ワークフローは、顧客入力に応答して、ワークフロー中の経路に沿ってｉルータ１０１の「舵をとる」。ワークフロー中の場所は、その時点までに収集されたデータと共に、「コンテキスト」と呼ばれる。

ワークフローデザイナは、人間エージェント１０５の意図解釈をガイドするために、人間エージェント１０５に対する命令をワークフローに構築する。ワークフローデザイナは、ＸＭＬドキュメントの構築に焦点を合わせるようにカスタマイズされたＥｃｌｉｐｓｅ（登録商標）ソフトウェア開発環境のバージョンを含んでよい。しかし、本明細書を検討した後には、当業者ならワークフローデザイナを開発できるであろう。

本発明の、性能および対話アーカイブ１０７は、任意の一般的なコンピュータサーバハードウェア上で維持できるデータベースを含む。性能および対話アーカイブ１０７は、顧客１０３とのシステムトランザクションのアーカイブデータ（すなわち、顧客１０３との対話からのサウンドクリップ、Ｅメール、チャットなどのリポジトリ）と、人間エージェント１０５についての性能データとの、両方を含む。

この例示的な実施形態は、対話のグループに関する統計を生成するために、または人間エージェント１０５の性能ランキングを表示するために、「リポータ」ソフトウェアを利用する。リポータソフトウェアはまた、対話アーカイブ１０７に記憶された顧客１０３のコンタクトを構成したサウンドクリップ、Ｅメール、またはチャットテキストから、顧客１０３との対話を再構築することができる。リポータソフトウェアは、一連の単純なスクリプトであり、任意の一般的なサーバハードウェア上で実行されてよい。

この例示的な実施形態はまた、マネージャ／管理者ソフトウェアも含み、このマネージャ／管理者ソフトウェアは通常、リポータソフトウェアと同じステーションから実行される。マネージャ／管理者ソフトウェアは、対話式応答システム１００についての動作パラメータを設定する。このような動作パラメータは、負荷平衡、ワークフロー中の変更のアップロード、および他の管理変更のための、業務規則を含むが、これらに限定されない。特定の一実施形態では、マネージャ／管理者ソフトウェアは、標準的なコールセンタコンピュータワークステーション上で実行される小さいカスタムＪａｖａ（登録商標）アプリケーションである。

サポートシステム１０８は、顧客１０３の要求に応答する際に利用できる多くのデータベースおよび顧客プロプライエタリシステム（Ｎｕａｎｃｅ（登録商標）などのオフザシェルフ自動音声認識（ＡＳＲ）ソフトウェアも含む）からなる。例えば、サポートシステム１０８は、顧客情報または知識ベースのためのデータベースを含んでよい。音声認識ソフトウェアは、この例示的な実施形態では、顧客１０３の発話を解釈するのに使用されるオフザシェルフコンポーネントである。サポートシステム１０８はまた、テキスト−音声機能も含んでよく、これはしばしば、顧客１０３に対してテキストを読み上げるオフザシェルフソフトウェアである。

本発明の会社エージェント１０９は、ワークフローが問い合わせをする、顧客１０３要求を扱う人間エージェントからなる。例えば、顧客１０３が会社のことで援助を得ようと意図しており、外部委託された人間エージェント１０５がこの意図を識別した場合、ワークフローは、電話を会社エージェント１０９に転送するよう、対話式応答システム１００に指示することができる。

対話式応答システム１００の要素は、この例示的な実施形態ではＴＣＰ／ＩＰネットワークを介して通信する。通信は、ｉルータ１０１が従うワークフローによって駆動される。この実施形態における「データベース」は、フラットファイルデータベース、関係データベース、オブジェクトデータベースまたはこれらの任意の組合せとすることができる。

次に図２から図５に移るが、これらの図は、顧客が電話を介して対話式応答システム１００と対話するときに、どのように対話式応答システム１００によって情報が取り出され処理されるかについての例を示す。図２に示す例は、必要な全てのハードウェア、ソフトウェア、ネットワーキングおよびシステム統合が完全であること、並びに、ビジネス分析者がグラフィックワークフローデザイナを使用して顧客対話における可能性あるステップを策定済みであることを前提とする。ビジネス分析者はまた、対話式応答システムが顧客１０３に対して言うかもしれないどんなことについても、テキストを作成済みである。これらは、最初のプロンプト（例えば「お電話ありがとうございます。今日はどんなご用件ですか？」）、顧客への応答、追加情報の要求、「口ごもる音声」（ｉルータ１０１が応答を決定している間に顧客に送られる音）および締めくくりの言葉を含むが、これらに限定されない。テキスト−音声ソフトウェアまたはボイスタレントのいずれかが、ビジネス分析者によって書かれたサーバ側音声のそれぞれを録音する。このワークフローは、対話式応答システム１００にロードされ、そこでｉルータ１０１によって利用可能である。

ブロック２０１に示すように、対話は、顧客１０３が会社の顧客サービス電話番号に電話することで開始する。対話プラットフォーム１０２（この場合は電話サーバ）が、電話に応じ、ブロック２０２に示すように、（１）発信者のＡＮＩ／ＤＮＩＳ情報、または（２）他の業務規則（例えば、電話が入来した回線または中継線）のいずれかに基づいて、ワークフローデータベースに記憶された適切なワークフローを取り出す。電話サーバは、ブロック２０３に示すように適切なウェルカムプロンプトを再生し、顧客はこのプロンプトに応答する（ブロック２０４）。

例えば、架空の航空会社であるインターエアが、本発明のコールセンタ実施形態による対話式応答システムを介して顧客サービスを提供する。従って、対話プラットフォーム１０２は電話インタフェースであり、ｉルータ１０１は、インターエアにふさわしいワークフローを選択する。

図３Ａの例証的なワークフローに、ワークフロー中の第１のポイントまたはコンテキストを示す。顧客発話はなく、従って、キャプチャすべき（かつ応答すべき）意図またはデータはない。唯一の応答は、挨拶、および顧客入力を求めるプロンプトである。

処理は図２のフローチャート中のボックス２０４に進む。電話サーバは、顧客の口頭入力をディジタル化するのを開始し、ｉルータに接続する。この時点で、ワークフローまたは業務規則は、顧客に対する対話式応答を人間エージェントによって扱う必要があるのか音声認識ソフトウェアによって扱う必要があるのかを決定する。すなわち、ｉルータは、電話のための適切なワークフローをワークフローリポジトリから選択し、ワークフロー規則に従って顧客との会話を行う。

顧客の言葉を解釈するために、ｉルータ１０１は適宜、ブロック２０５に示すように、サポートシステムからのＡＳＲを使用するか、または顧客のオーディオをコンタクトセンタ中の人間エージェント１０５にストリーミングさせる。人間エージェント１０５がワークフローによって必要とされる場合は、ｉルータ１０１は、ブロック２０７に示すように、負荷平衡アルゴリズムを適用することによって、利用可能な人間エージェントを識別し、彼らの画面上でポップアップをトリガし（図３Ｂの、最初は空のポップアップ画面に示すように）、いくつかの選択可能な意図オプションを提示し、識別された人間エージェントに顧客オーディオをストリーミングし始める。本開示が与えられれば当業者なら思いつくであろうが、この負荷平衡は、様々な時点で、様々な要因のいずれかに基づいて、発話を解釈するためのより多いかまたは少ない人間エージェントを識別することを含む。ブロック２１０および２１１に示すように、人間エージェントは、顧客の発話をヘッドホンで聞き、コンピュータソフトウェアが発話の解釈を促す。

図４Ａの例示的なワークフローによれば、１または複数の人間エージェントが聞く顧客発話は、「今日の午後のシカゴからロンドンへの自分のフライトを確認したい。」である。図４Ｂに示すように、エージェントの画面は、現在のコンテキスト（またはワークフロー中のポイント）を示す。この例証的なスクリーンショットでは、人間エージェントが選択できる、可能性ある要求（回答不能および終了を含む）が１２個ある。稼働時には、エージェントに利用可能な可能性ある解釈は数百個ある。このように選択が多種多様であることで、解釈のフレキシビリティがエージェントに与えられ、これによりｉルータは、解釈された意図に従ってそのワークフロー中で跳び回ることができる。従って、本発明の一態様によれば、ｉルータは、顧客が途中で主題を変えたとしても、適切に応答することができる。

それぞれの場合に、各エージェントは、ワークフローの現在のコンテキストで顧客発話の最もふさわしい解釈であると感じるものを選択する。図４Ｂの例では、人間エージェントは、「ＣＦＴ」（フライト時間の確認）を選択し、出発都市および到着都市（または、顧客が発話する可能性のある他の事前プログラム済み情報）を入力するかまたはドロップダウンメニューから選択する。

ブロック２０８および２０９では、人間エージェントは、任意の応答遅延を補償するために、ステーションで受け取られた顧客オーディオクリップに加速を適用することを決定できることに留意されたい（応答遅延は通常、アプリケーションセットアップにおける遅れ時間、すなわち、人間エージェントのデスクトップソフトウェアがストリーミングオーディオを受けて適切なワークフローを表示するのにかかることになる時間に起因する）。ネットワークレイテンシは０．２秒前後である場合があり、アプリケーション遅延は、１＋秒の範囲でより大きい可能性がある。アプリケーション遅延を補償するために、対話式応答システムは、ボイスクリップを加速させる（ただし歪みが認識できるところまではしない）。この目的は、顧客が応答を待つ間に目立った遅延を体験しないように、より「リアルタイムの」会話対話に向けて努力することである。加速は、言葉が電話サーバから流れてくるのに伴ってその言葉に適用される。加速は、リンク固有のレイテンシを克服することはできないが、加速により、人間エージェントは、どんなアプリケーションセットアップ時間も「回復」して、対話における遅れ時間の量を、理想的にはネットワーク中のレイテンシによって課される限度まで削減することができる。しかし、加速は任意選択であり、初心者のエージェントはよりゆっくりした再生を必要とすることがあるが、より経験を積んだエージェントは加速を適用することができる。

テスト２１３で、ｉルータは、顧客オーディオ解釈の精度をリアルタイムで評価し、各エージェントの速度／精度プロファイルを更新する。ブロック２１４で、ｉルータは、解釈を処理してワークフロー中の次のステップ（例えば、入力データに基づくデータベース検索）を実施し、次に、電話サーバを介して適切な応答を顧客に転送する（２１８）（解釈が正確であると見なされる場合）。解釈が正確であるとｉルータが判定した場合、ｉルータは、音声認識ソフトウェアの解釈に基づいて、または１若しくは複数の人間エージェントの応答にキーアルゴリズムを適用することによって、応答の再生を電話サーバから顧客に向けて送る。この例では、応答は、図４Ａの画面２の最後のブロックで与えられる。

精度を決定するために、ｉルータは、２人の人間エージェントの解釈を比較し、合意に達しない場合は、さらに解釈を求めて、第３の人間エージェントに対して顧客オーディオクリップを再生する（すなわち、「多数決規則」でどれが正確な応答かを決定する）。他の業務規則を使用して正確な解釈を決定してもよい。例えば、最も良い精度スコアを有するエージェントからの解釈を選択することができる。あるいは、解釈のうちの１つを選択して顧客に対して再生することができ（「・・・と仰っていると理解しております」）、顧客の応答が、その解釈が正しかったかどうかを決定する。さらに、既知のデータから解釈を選択することもできる（例えば、Ｅメールアドレスの２つの解釈を顧客Ｅメールアドレスのデータベースと比較することができる、クレジットカード番号の２つの解釈のうちの一方のみがチェックサムアルゴリズムをパスすることになる、など）。

対話式応答システムは、ほぼ任意の数の人間エージェントが一度に同じ顧客対話を扱うことを可能にする。即ち、対話式応答システムは、忙しい時間中は２人のエージェントが聞くようにすることができ、または、より暇な時間中は７人の人間エージェントが聞くようにすることができる。さらに、電話の量が多い時間中は、「二重チェック」規則をなくすことによって精度を低下させて速い応答時間を維持することができる。エージェントの速度／精度プロファイルに基づいて高い信用ランクが割り当てられたエージェントには、二重チェックなしで作業するよう求めることができる。より素早いシステム可用性に対して精度をトレードオフすることに加えて、オーディオクリップの途切れのない流れが各エージェントに流れており、それにより人間エージェントの「怠け」時間が低減される。

図２のフローチャートに戻り、ブロック２０４に見られるように顧客が再び応答することになるか、ブロック２１５に示されるように、電話が転送されることになるか（ワークフロー中のステップによって若しくは業務規則によってそのように指示された場合）または顧客が電話を終了する。ブロック２１３で解釈が不正確であると見なされる場合は、ｉルータ１０１は、時間稼ぎ音声を顧客に対して再生し（ブロック２１６）、別の解釈を求めてオーディオクリップを追加の人間エージェントに送り（ブロック２１７）、その精度を再評価する。

ｉルータは、ワークフローをそのガイドとして使用して、顧客との対話を電話完了まで管理する。ｉルータは、電話の中の多くの時点で、解釈を求めて顧客発話を人間エージェントにストリーミングすることができる。電話が終結すると、顧客対話のスナップショットがアーカイブデータベースに保存される。人間エージェントの速度／精度プロファイルは、常に更新され維持される。

顧客の要求を解釈するのに人間の介入が必要ない場合はブロック２０６および２１４に示すように、ＡＳＲがオーディオクリップを解釈し、ｉルータが適切な応答を決定する。

インターエアの例を続けるが、図５Ａに見られるように、キャプチャされた顧客発話は、２つの要求、すなわち食べ物および娯楽の問合せを有する。本発明の別の態様によれば、人間エージェントは、２つの意図、すなわち食事および映画を捕える。入力すべき関連のあるデータはない。というのは、対話式応答システムは、図４Ｂで入力された前のデータ（このデータは図５Ｂで見える）から、フライト情報を既に知っているからである。図５Ｂに見られるように、人間エージェントは、可能性ある意図のオンスクリーン表示から「一般」および「食事」を入力する。人間エージェントはまた「映画」も入力する。図５Ａに見られるように、対話式応答システムは適切な応答を提供する。図５Ｂに見られるように、顧客が、「どんな食事が出ますか？」、「特別食はありますか？」、「映画の年齢制限はどの区分ですか？」など、食事または映画に関するさらに他の情報を要求した場合、適切な人間エージェント解釈オプションがコンピュータ画面上で突き止められる。

図６は、顧客が電子メール（当技術分野で一般に知られているＥメール）を介して対話するときに、どのように対話式応答システムによって情報が取り出され処理されるかについての例を示す。ブロック６０１に示すように、対話は、顧客が会社の顧客サービスＥメールアドレスにＥメールを送ることで開始する。対話プラットフォーム（この例示的な実施形態ではゲートウェイサーバ）が、Ｅメールを開き、６０２に示すように、（１）顧客のｔｏ／ｆｒｏｍ情報と（２）他の業務規則とのいずれかに基づいて、ワークフローデータベースに記憶された適切なワークフローを取り出す。ゲートウェイサーバは、６０２に示すように、適切な応答承認を送る。ｉルータ１０１は、ブロック６０３に示すように、負荷平衡アルゴリズムを適用することによって、Ｅメールを扱うための利用可能な人間エージェントを識別し、彼らの画面上でポップアップをトリガして解釈のための可能性ある意図を示し、１または複数の人間エージェントにＥメールの内容を送る。人間エージェントは、ブロック６０４および６０５に示すように、Ｅメールを解釈する。テスト６０６で、ｉルータ１０１は、顧客Ｅメール解釈の精度をリアルタイムで評価し、各エージェントの速度／精度プロファイルを更新するが、このテストの後、ｉルータ１０１は、解釈を処理し、それに従ってワークフロー中の次のステップを実施する。最終的に、ｉルータ１０１は、ブロック６０７に見られるように、ゲートウェイサーバを介して適切なＥメール応答を顧客に転送する（解釈が正確であると見なされる場合）。ブロック６０８に示すように、Ｅメールは適切なデータベースにアーカイブされる。解釈が不正確であると見なされる場合は、ｉルータ１０１は、別の解釈を求めてＥメールを別の人間エージェントに送り（ブロック６０９）、その精度を再評価する。ｉルータ１０１は、ワークフローをそのガイドとして使用して、顧客との対話をＥメール応答まで管理する。

図１〜図６に関する上記の対話式応答システムおよびそれを構成するプロセスに対する考察は、１または複数の音声認識および関連サブシステム１０８の動作を含む。ＩＶＲシステム１００の実現には、実際、人間による対話の必要性を最小限に抑えるためにこのようなサブシステム１０８が顧客の発話のかなりの部分を認識できることが必要である。

次に図７を参照すると、ＩＶＲシステム１００の一部として、訓練サブシステム７１０が含まれる。稼働時には、訓練サブシステム７１０は、サブシステム１０８中のリアルタイムＡＳＲに機械学習機能を選択的に提供して、新しいまたは変更された顧客対話に対してこれらが非常に素早く適応できるようにする。例えば、ＩＶＲシステム１００が会社に対して最初にインストールされたとき、組込みＡＳＲの一般的な機能は、実際の顧客対話にはあまり使えないことがあり、特に、これらの対話が業界特有の用語を多く含む場合にはそうである（例えば、接地事故回路遮断装置を注文するために電話する電気工は通常、「ＧＦＣＩ」という頭字語を使用するであろうが、これを容易に認識するＡＳＲはほとんどないであろう）。同様に、新しい提供物が利用可能になったとき、既存のＡＳＲ機能は、前はうまくいっていたにもかかわらず障害を起こし始めることがある（例えば、過去の使用において「ｉＰｏｄ（登録商標）」を正しく識別したＡＳＲが、「ｉＰａｄ（登録商標）」など似た名称の別の製品が導入されると障害を起こし始めることがある）。これらの変更は、ある適用例では頻繁でない場合があるが、他の適用例では定期的に発生する場合がある。例えば、ロックコンサートのチケットを販売するための適用例は、バンド名に対する新しい顧客要求に定期的に適応することが必要になる。

一実施形態では、訓練は、このような訓練に対する指示された必要性に基づいて行われる。ＡＳＲの精度が容認性閾値よりも十分に高い既存のシステムの場合、訓練は、仮に行われるとしても、たまにしか行われない可能性がある。このような場合、訓練は、例えば、電話の量が極めて少ない期間中（この期間中は、ＩＡ１０５は通常なら比較的暇である）だけ行うことができる。システムが新しい場合は、またはＡＳＲの成功が容認可能限度未満に下落しているときは常に、より多くの訓練が必要とされてよく、従って訓練サブシステム７１０はより頻繁にアクティブになる。

訓練サブシステム７１０の非リアルタイム訓練ＡＳＲ７１１は、入力として、顧客の発話をｉルータ１０１から受け取り、対応する意図をＩＡ１０５から受信する。実際には、後述するように複数の訓練ＡＳＲ７１１を使用することができる。

リアルタイム本番処理の場合と同様、非リアルタイム訓練のための処理は、ある実施形態では、単一のＩＡからの入力を含み、他の実施形態では、複数のＩＡからの入力を含む。異なるＩＡによって選択された意図の違いは、多大な追加の訓練を必要とする特に微妙な発話を示す可能性があるので、これらの違いは、ＡＳＲを訓練する際に非常に役立つ。用件意図が、「はい」または「いいえ」などのごくわずかなオプションしかない小さい文法を有することができ、「はい」および「いいえ」における発話の事前パッケージ済みの理解がＡＳＲに付属しているような、最も単純な形では、訓練は、文法整調に使用できる統計モデルを構築することからなる場合がある。より複雑な訓練では、言われる可能性のある発話の統計言語モデルを構築するために、領域知識を用いてＡＳＲの単語認識が援助される。

好ましい一実施形態では、ＩＶＲシステム１００は、サポートシステム１０８中の複数の利用可能なリアルタイムＡＳＲを使用して実現される。実際には、各ＡＳＲが強みと弱みを有することが見出され、特定エリアでの成功は、特定の状況でどのＡＳＲを使用するかを決定するためにｉルータ１０１によって使用可能であり、また、特定の状況での訓練からどのＡＳＲが利益を受けることができるかを決定するために訓練サブシステム７１０によって使用可能である。現在利用可能なＡＳＲは、カーネギーメロン大学（Sphinx）、Nunance、Dragon、Loquendo（登録商標）、Lumenvox、ＡＴ＆Ｔ（登録商標）、SRI International、Nexidia、Ｍｉｃｒｏｓｏｆｔ（登録商標）およびＧｏｏｇｌｅ（登録商標）からのＡＳＲを含む。厳選されたＡＳＲのみがコストなしで利用可能（例えばオープンソースライセンスの下で）なので、経済的な考慮事項により、サポートシステム１０８に含めるＡＳＲの数が制限される場合がある。ｉルータ１０１は、いずれか特定のコンテキストでうまく機能すると予想されるＡＳＲに本番要求を選択的にルーティングすることができるので、かつ、訓練サブシステム７１０も同様に、リアルタイムＡＳＲをそれらの性能の予想される向上に基づいて選択的に訓練することができるので、相互にいくぶん直交する性能特性を有する１群のＡＳＲを選択するのがしばしば有利であろう。このようにすれば、あるＡＳＲが別のＡＳＲの弱みを埋め合わせることを期待することができる。例えば、電話の言葉を処理するのに最適化されたＡＳＲは、ディクテーション機器からの言葉を対象に設計されたＡＳＲとはかなり異なる性能特性を有する場合がある。

ＩＶＲシステム１００で使用されるリアルタイムＡＳＲの精度を高めるために、訓練サブシステム７１０は、訓練ＡＳＲ７１１の非リアルタイム動作に基づいて、受信した各発話の意味に特有の訓練をリアルタイムＡＳＲに提供することによって、機械学習を容易にする。

一般に、ＡＳＲはいくつかの異なる態様で訓練される。第１に、ＡＳＲは、オーディオストリーム、およびオーディオストリームの各部分を、話されている単語の認識に至るための助けになれる構成要素に分類できなければならない。通常、これは、「音（phone）」として知られる類似するサウンドクラスと、「ダイフォン（diphone）」として知られるサウンド移行または結合と、「セノン（senone）」と一般に呼ばれる、より複雑な場合のある波形部分とのセットを、オーディオストリーム内で識別することを伴う。一般に、発話は、沈黙期間が検出される場所ではどこでも分割される。発話フレーム（１０ミリ秒の時間フレームなど）を分割して、この時間フレーム内でオーディオの様々な異なる特徴面（振幅および周波数が増加しているか、一定であるか、または減少しているかなど）を抽出することによって、発話から特徴が導出される。カーネギーメロン大学から入手可能なＳｐｈｉｎｘ ＡＳＲでは、３９個の特徴が抽出されて、音声が「特徴ベクトル」として表される。通常、ＡＳＲエンジンには、それらの認識が固定されるというこの側面が伴い、このようなシステムのユーザは、どの特徴が分析されるか、またはどのようにそれらが分析されるかを変更することはできない。

ＡＳＲは、様々なモデルを使用して、生オーディオ波形から、発話に対応する単語の予測に進む。音響モデルは、受信したセノンに対する最も確率の高い特徴／特徴ベクトルを決定する。音声モデルは、音と単語をマッピングするが、単語は、固定辞書からくるものであるか、または、機械学習によって導出された語彙（若しくは「文法」）からくるものである。言語モデルは、前に認識された単語など、何らかのコンテキストに基づいて、候補単語選択肢を制限する。ＡＳＲは通常、これらのモデルの組合せを使用して、どの単語が発話に対応するかを予測する。以下で考察する実施形態における訓練の焦点は、後の２つのモデル、すなわち音声モデルおよび言語モデルだが、本明細書で対象とする概念は、音声認識で使用される他のモデルにも容易に適用することができる。

多くの場合、ＡＳＲの訓練は、前に認識された単語からのコンテキストを使用することによって、またはリアルタイムでない処理（すなわち、同じ顧客談話において後で認識された単語）のコンテキストを使用することによって、より効果的に達成することができる。このような訓練について以下に述べる。

まず音声モデルに目を向け、「I would like to fly roundtrip between Boston and San Diego.（ボストンとサンディエゴの間を往復して飛びたい。）」というユーザ発話を考えてみる。「オフザシェルフ」ＡＳＲは、これらの単語のいくつかを様々な話者にまたがって認識するのに、いくらか困難を有する場合がある。例えば、単語「roundtrip」を発音する際、何人かの話者は、「ｄ」と「ｔ」の子音の音を１つの音に省略する（rountrip）ことがあるが、他の話者は、これらを別々に発音する（これらが２つの単語「round」と「trip」であるかのように）ことがある。

一実施形態では、訓練サブシステム７１０は、これらの問題の各々に対処することによって、非リアルタイム訓練ＡＳＲ７１１に機械学習を提供する。まず、訓練サブシステム７１０は、発話が最初に受信されたときにＩＡ１０５によって決定された、発話に対応する用件意味に基づいて、ターゲット語彙を選択する。この場合、ＩＡは「新規予約」を用件意味として選択した可能性が高い。単語「roundtrip」は、一般的な文法においては４万個の単語のうちの１つであったかもしれず、ごく低い統計発生率を有したかもしれないが、「新規予約」の意図に特有の文法においては、たった千個の単語のうちの１つかもしれず、はるかに高い統計発生率を有するかもしれない。従って、訓練サブシステム７１０は、特徴ベクトルがこの単語の標準化モデルからかなり逸脱するとしても、適用可能な文法を変更することによって、話されたこととして単語「roundtrip」を訓練ＡＳＲ７１１が受諾する確率を大幅に上げる。さらに、「roundtrip」の追加の発話が「新規予約」の意図に関連付けられるようになるのに伴い、これらの発話は、「roundtrip」が話された既に認識済みのインスタンスの少なくともいくつかと、より近く合致することになる可能性が高い。従って、時が経つにつれて、単語「roundtrip」が「新規予約」の意図の中で発生する可能性と、この単語の発音のばらつきとの両方が、以下の２つの結果につながることになる。すなわち、（ａ）単語を認識する際の確実性がより高くなること（これは、「予約のキャンセル」の意図に関連する文法など、同じ単語を含む他の文法にも伝搬させることができる）、および、（ｂ）単語が特定の意図にどれくらい頻繁に関連付けられるかに関する精緻化された統計によって、用件意図をよりよく予測できることである。

上述した発話の例に戻るが、早口の話者は、「Boston」と後続の単語「and」との間の区別を曖昧にして、全ての音をはっきり発音できないことがあり、それにより、訓練ＡＳＲ７１１は、音「Bostonan」を分析しようとしていることがある。同様に、都市名「San Diego」が、話者によっては、むしろ「Sandy A-go」のように聞こえるようにして発音されることがある。この場合もやはり、一般化された文法ではなく「新規予約」特有の文法を選択することで、「Boston」および「San Diego」の認識が信頼度を持って達成される統計的可能性が劇的に高まる可能性が高いことになる。一層の精緻化として、訓練サブシステム７１０は、ユーザ談話全体の発話の中を通る反復的パスを利用して、訓練をさらに一層改善する。上述の例では、その後、談話中に発信者は、文の最後に、訓練ＡＳＲ７１１によって容易に認識されるようにして「Boston」と言うことがある。「Boston」に関するこの話者の音響シグネチャが、ＡＳＲのマッピングに含められ、それにより、第２のパスでは、同じ話者の「Boston」発話は、前よりもよい「Boston」に対する合致と考えられることになる。同様に、話者は、２回目に、「San」と「Diego」との間でより区別を付けるようにして「San Diego」と言うことがあり、それにより反復的に認識を試みれば１回目の曖昧な発話がうまく認識される可能性がより高まることにつながる学習が提供される。長い顧客談話の場合、システムが認識できる単語を通して発信者の声特性がよりよく理解されるようになるので、複数の反復によって認識全体のかなりの改善に至ることができる。

ここで図１０も参照するが、一実施形態では、意図分析者による実際の認識時点を使用して、オーディオストリームが、認識のための別々の発話に分解される（例えば訓練ＡＳＲ７１１によって）。具体的には、発話意図「I want to take a flight from」の認識時点（１００１、１００４）、データ部分「Boston」の認識時点（１００２、１００５）、およびデータ部分「San Diego」の認識時点（１００３、１００６）は全て、十分に異なり、従って、オーディオを認識のための別々の発話に分解するのを容易にするために、時間フレーム自体が使用可能である。場合によっては、ＩＡは、発話が完了する前（または後）に認識を提供することがあり（例えば、図１０の１００３に示すように、「San Diego」は、最後の「o」音の前にＩＡによって認識される）、従ってそのような場合は、時間フレームは、ＩＡによって提供された認識の後（または前）の適切な休止で終わるように調節される。可能性ある用件意図およびそれらを表すのに使用される典型的な単語の数は、意図認識文法を絞り込むのに使用可能であり、収集されるデータのタイプ（例えば都市名）は、データ認識文法を絞り込むのに使用可能である。

言語モデルに移るが、訓練システム７１０はやはり、用件意図を利用して訓練を援助する。例えば、ＩＡが「新規予約」の用件意図を示した場合、発話の中の単語「and」の少なくとも１つのインスタンスの前に１つの都市名がきて、後に別の都市名が続くことになる可能性が、統計的に非常に高いであろう。同様に、単語「from」または「to」が認識された場合、これらの単語の後に都市名が続く確率が統計的に非常に高いであろう。対照的に、ＩＡによって決定された用件意図が「座席指定」である場合、これらの同じ単語「from」および「to」は、隣接する都市名と相関することはめったにないが、そうではなく、近くの数字と文字の対に相関するであろう（例えば「I would like to change from seat 39B to seat 11A.（座席３９Ｂから座席１１Ａに変更したい。）」）。

このような言語モデル訓練はまた、ユーザの変化する言い回しに容易に適応することを可能にする。例えば、航空会社がイングランドへのサービスを開始した場合、航空会社は、同じ用件意図について、前に使用されていたのとは異なる言語を使用した要求を急に受け始めることがある。例えば、前の「I would like to fly roundtrip between Boston and San Diego.」の例は、英国人の顧客によって「I would like to book a return trip between Boston and London.」と話されるかもしれない。最初は、単語「book」は「新規予約」文法において高確率で現れないであろうが、この文法におけるこの単語の統計的使用は、追加の英国人顧客によってすぐに増加する。同様に、用語「return」の使用は、英国人顧客ベースの追加によって変化し、「新規予約」文法は、これを認識するように相応に調節される。

訓練サブシステム７１０はまた、用件意図と、談話の中の隣接する認識された単語との組合せに基づいて、認識候補についての統計を調節する。用件意図が「新規予約」であると決定され、また、最初、ユーザの談話の中の１つの発話のみが、使用可能な信頼度レベルでは認識できないという例を考えてみる。談話が都市名を１つだけ含んでいたと認識された場合、認識されなかった発話が別の都市名である確率が非常に高く、このシステムを使用する航空会社によって対応される都市名である確率はさらに高い。文法内の候補単語に対する確率を変更して部分的認識を行うと、いくつかの候補単語がそれ以上の考慮からうまく切り捨てられることがあり、１つの候補（おそらく都市名）だけが、使用可能な確実度レベルになることがある。この場合、機械学習は、この特定ユーザの都市の発音をＡＳＲのモデルに組み込み、それにより類似の発話の後続のインスタンスがより容易に認識されるようにする。

許容可能な用件意図ごとに別々の文法を維持することで、通常なら可能であるはずよりも迅速なＡＳＲの教授を訓練サブシステム７１０が提供するのが容易になる。例えば、発話「book」、「notebook」および「Bucharest」には、強い音声上の類似性がある。これらの意味のうちのどれがユーザの発話に対応するかの決定は、用件意図を考慮することによって大きく向上する。例えば、用件意図が「遺失物取扱所」である場合は、「book」（その名詞の意味の）および「notebook」（「notebook computer」におけるような）は、他のコンテキストの場合よりもずっと高い可能性で現れるであろう。用件意図が「新規予約」である場合は、「book」（その動詞としての意味の）もまた、非常に高い可能性で現れるであろう。同様に、用件意図が「新規予約」である場合は、「Bucharest」は、用件意図が例えば「座席選択」であった場合よりも、高い可能性で現れるであろう。

訓練ＡＳＲ７１１自体が十分に訓練された後は、用件意図と言語モデルとの間の相関を非常に頑強な方式で作り出すことができる。例えば、似たように聞こえる単語のマッピングの例示的な一部は、次のとおりとすることができる。

訓練ＡＳＲ７１１は、サポートシステム１０８からのリアルタイムＡＳＲに勝る２つの利点を有するので、言語モデル統計を作り出すのに特によく適する。第１に、本番動作に使用されないので、リアルタイムで動作する必要はなく、従って、リアルタイム処理に使用されるだけの十分な素早さで認識を実施することが少なくとも比較的中程度のコンピューティングプラットフォーム上ではできないはずの、より複雑な認識アルゴリズムを利用することができる。これにより、訓練ＡＳＲ７１１は、サポートシステム１０８中のリアルタイムＡＳＲが認識できないであろう発話を認識することができる。第２に、訓練ＡＳＲ７１１は、顧客談話からの演繹的な情報だけでなく、帰納的な情報も利用することができる。従って、対話の中の全ての発話が分析されるまで待機し、次いで認識時に複数のパスをとることができ、おそらく、後の反復では、成功する可能性がより高くなる。前述のように、「Bostonan」のように聞こえる最初のユーザ発話は、２回目の「Boston」の発話の後には、はるかに容易に認識することができる。

訓練ＡＳＲ７１１は、時の経過に伴って、関連する各用件意図と共に使用される言語要素に関係する一連の統計を構築する。一実施形態では、複数の訓練ＡＳＲ７１１が使用され、各訓練ＡＳＲ７１１は統計全体に貢献する。ある実施形態では、統計は認識に関する確実性の尺度を含み、この尺度は、単一の訓練ＡＳＲ７１１による認識の複数のインスタンスに基づくか、複数の訓練ＡＳＲ７１１間の一致に基づくか、又はこの両方に基づく。

このようにして作り出された統計は、サポートシステム１０８中のリアルタイムＡＳＲのいずれかによって使用可能である。サポートシステム中の、リアルタイム認識に使用できる種々のＡＳＲの各々は、通常、訓練のためのそれ自体のメカニズムと、どのように言語モデルを訓練のためにこのメカニズムに入力できるかに関する対応する仕様とを有する。好ましい一実施形態では、訓練サブシステム７１０は、それが作り出す統計をサポートシステム１０８中のＡＳＲごとにフォーマットし、それにより、訓練サブシステム７１０によって生成された統計をこれらのＡＳＲの各々が利用できるようにする。実際には、ＡＳＲは、それらが訓練のためにサポートするメカニズムにおいて大きく異なり、従って、訓練アルゴリズム７１２は、既存の各ＡＳＲ、並びにサポートシステム１０８に追加される可能性のある新しい各ＡＳＲに適切な方式で、訓練データを収集し、フォーマットし、ＡＳＲに提供するように、容易に構成可能である。リアルタイムＡＳＲの性能は訓練に伴って向上するので、その認識の品質は、処理２１０、２１１でリアルタイムＡＳＲがＩＡ１０５の機能に取って代わるのを可能にすることができる。

訓練サブシステム７１０はまた、各ＡＳＲの機能と共に機能して、ＡＳＲ訓練がＩＶＲシステム１００中での使用に最大限に活用されるのを確実にする。例えば、ＡＳＲは、センテンスツリーを使用するなどして、いつ十分な発話部分が統計分析の実施に使用可能と認識されるかについての閾値の決定をサポートすることができ、訓練アルゴリズム７１２は、訓練の進展を決定するためにこのような特徴に適合するように構成される。

サポートシステム１０８中のリアルタイムＡＳＲは、異なる統計処理を必要とする２つの異なる方法で使用される。第１の方式では、これらは、対応する用件意図をＩＡが決定した後で、プロセスを認識するのに使用される。例えば、１または複数のＩＡ１０５が、発信者によって話された文についての用件意図として「新規予約」を選択する場合があり、これに基づいて、サポートシステム１０８中の１または複数のリアルタイムＡＳＲが、発信者によって話された特定の単語を認識しようとすることになる。

第２の方式では、ＩＡではなくリアルタイムＡＳＲを使用して用件意図が決定される。これは、発信者によって話された特定の単語を決定するのとは異なる認識タスクである。例えば、用件意図が「新規予約」である可能性があるか「座席要求」である可能性があるかを決定することは、「新規予約」に関する単語「から」および「まで」、並びに、「座席予約」に関する単語「通路側」および「窓側」など、各意図に特有の、可能性の高い少数のキーワードを認識することを伴うことがある。サポートシステム１０８中のあるタイプのＡＳＲは、用件意図を決定することに、よりよく適する場合があり、別のタイプのＡＳＲは、その用件意図に基づいて単語を認識することに、よりよく適する場合がある。一実施形態では、訓練サブシステム７１０によって提供される、リアルタイムＡＳＲごとの訓練統計のフォーマットは、リアルタイムＡＳＲが意図の決定に最適化されることになるか、または決定された意図に基づく単語認識に最適化されることになるかに基づいて、調節される。

訓練プロセスの一部は、機械学習がサポートシステム１０８中のリアルタイムＡＳＲに対してどれ位効果的であったかを決定することを含む。これは妥当性検査と呼ばれる。好ましい一実施形態では、妥当性検査は訓練サブシステム７１０によって実施される。代替的実施形態では、妥当性検査はｉルータ１０１または専用の妥当性検査プロセッサ（図示せず）によって実施される。妥当性検査では、ＡＳＲを、相互と、およびＩＡと並列で動作させて、それらの性能がどれ位匹敵するかを決定する。各訓練インスタンスは、ＩＡによって提供される用件意味ごとに文法使用の統計モデルおよび確率を作り出すのに使用される、より多くの情報を提供する。状況によっては、ＩＡからの履歴データもまた、発話に対して利用可能な場合のある予期される自動化レベルを決定する。ＩＡが、発話に対して複数の意味をいつも決まって提供する場合、ＡＳＲは、かなりのコンテキスト訓練が可能な場合にのみ使用可能となるであろう。頑強なコンテキスト処理を有するＡＳＲは、そのような発話を正しく処理できるかもしれないが、コンテキスト的に強くないＡＳＲは、どれだけ多くの訓練が提供されるかにかかわらず、最低閾値を満たすことができないかもしれない。例えば、発話「ＩＰ」は、「インターネットプロトコル（Internet Protocol）」または「知的所有権（Intellectual Property）」を意味する可能性がある。両方の意味が一般的である適用例で使用された場合、ＡＳＲが訓練後に２つの意味のうちのどちらが適切な意味かを導出できない限り、処理精度の誤りが予想されることになる。

訓練が進むにつれて、リアルタイムＡＳＲの性能は向上する。ＩＶＲシステム１００内でこのＡＳＲを特に使用する必要性を満たすほど統計的に安定した時点で、ＡＳＲは本番動作に配置される。例えば、発話についての用件意味を決定するように意図されたＡＳＲは、その性能がＩＡの性能に達するほど十分に訓練された時点まで、非本番モードでＩＡと並列で動作することができ、十分に訓練されたとき、本番動作に切り替えられて、処理２１０、２１１におけるＩＡの負担が軽減される。

典型的な一実施形態では、リアルタイム本番処理と訓練処理の両方で、２人のＩＡからの入力が２つのＡＳＲに提供されて、精度が高められる。同じユーザ談話における同じ発話についての２人のＩＡからの入力が異なる場合、ある実施形態では、発話は、意味の決定のために第３のＩＡ（場合によってはＩＡの品質の程度に基づいて選択される）にサブミットされる。

妥当性検査を介して決定されるように、かつ環境の特質に基づいて決定されるように、ＡＳＲが一定閾値よりも高い精度レベルに達したとき、訓練処理は遷移する。例示的な一実施形態では、ＡＳＲは本番処理に使用されるが、訓練は前述のように継続する。求められるものがより厳しくない環境では、または利用可能なリソースがより少ない環境では、訓練は全て終わる。第３の環境では、訓練は継続するが、優先順位が下がる（例えば、訓練処理は、一定量の利用可能な処理キャパシティがあるときにのみ、またはＡＳＲの性能が一定程度まで劣化したことがわかったときにのみ、行われる）。

ある実施形態では、妥当性検査プロセッサが、ＡＳＲをテストしてそれらの性能レベルを決定するように構成される。妥当性検査は、ある実施形態では、訓練段階の後に続き、他の実施形態では、訓練と同時に実施される。妥当性検査からの結果に基づいて、ｉルータ１０１は、ＡＳＲおよびＩＡへのその発話割り当てを変更する。例えば、ＡＳＲが用件意味の決定においてＩＡと比較して十分にうまく機能することがわかった場合、ｉルータ１０１は発話を、ＩＡにルーティングするよりもはるかに頻繁にこのＡＳＲにルーティングする。有利にも、このようなルーティングは非常に適応可能かつ構成可能である。図３〜図５に関して使用した例に従うと、ｉルータ１０１は、性能統計に基づいて、ウェルカムメッセージの直後の応答解釈にはＩＡの方を選ぶことができ（図４Ｂ）、映画または食事についての応答解釈には第１のＡＳＲの方を選ぶことができ（図５Ａ）、座席指定や飛行機情報についての応答解釈には第２のＡＳＲの方を選んで、図５Ｂに示される他の選択肢を選択することができる。ある実施形態では、特定の解釈エリアごとに２つのＡＳＲ（２１０、２１１におけるように）が選択されて、精度が保証される。両方のＡＳＲが同じ解釈を提供する場合は、対応する応答がユーザに提供される。ＡＳＲが異なる場合は、２１７におけるように、発話はＩＡに提供されて、判決を介して意味が選択される。

結果として、人間ＩＡは、ＡＳＲが適切に機能できない特定のときだけ必要とされ、処理は、業務基準に応じてＩＡの介入の後すぐにＡＳＲに戻ることができ、ＩＡは顧客談話に接続されたままでいる必要はない。訓練がＡＳＲを向上させることができる場合、訓練は、ＩＶＲシステム１００全体に対する多くの追加コストも他のオーバヘッドも課すことなく、ＡＳＲを向上させる。適切な自動応答がユーザに提供されるように、単一のユーザ発話を聞いてユーザの意味または意図を所定オプションのドロップダウンリストから選択すること以上には、人間の対話が関与する必要はない。

図８を参照すると、ＡＳＲ訓練に関する例示的な処理フロー８００が示されている。ユーザ発話を含むディジタル化されたオーディオストリームが、１または複数のＩＡ１０５に提供され（８０１）、また、図７に関して述べたように使用可能な意図応答をＩＡが提供できる場合は、オーディオストリームは訓練ＡＳＲ７１１に提供される。訓練ＡＳＲ７１１がオーディオをそれに相当するテキストに変換するために発話を十分に認識（８０２）できない場合は、発話は廃棄され、訓練に使用されない。

ＡＳＲ７１１が発話を十分に認識（８０２）できる場合は、図７に関して上述したように、統計モデル／整調文法（例えば、ＩＡによって提供された意味およびデータに対応する文法）が構築される（８０３）。ＡＳＲ７１１によって決定された、一定信頼度閾値未満である発話のいくつかについては、ＡＳＲ７１１による意図またはデータの認識をＩＡが検証するための追加の検証ループを利用することができる。認識が確認された場合は、処理は８０３について述べたように進むが、そうでない場合は、結果は廃棄される。

次に、訓練ＡＳＲ７１１の性能が今や十分であるかどうか決定する（８０４）ためのテストが行われる。性能閾値は、適用例のクリティカル性に依存する場合がある。ヘルスケア適用例は、例えば無料旅行者情報サービスがエラーに対して耐性を有するであろうよりもずっと、エラー耐性が低い場合がある。性能閾値はまた、新しい単語または句が統計モデルに追加されるレートに依存する場合もある。性能が十分でない場合は、処理は戻って、ディジタル化（８０１）でき追加の訓練に使用できるさらに他の発話に備える。性能が十分である場合は、訓練の結果が適用されて、サポートシステム１０８のリアルタイムＡＳＲが、訓練から得られたモデルで構成され（８０５）、これらのリアルタイムＡＳＲは妥当性検査され、適切なら本番処理に使用される。

ある実施形態では、次いで訓練は完了と見なされる。ＡＳＲは、最初は暫定モードで、即ちＩＡのシャドーとして、オンラインにされる。ＡＳＲが、業務基準によって（例えば、ＡＳＲからの結果と１または複数のＩＡの結果とを比較することによって）決定されるように品質レベルを満たす場合は、ＡＳＲは、完全に本番で使用され始め、それにより処理２１０でＩＡに取って代わる。同様に、第２のＡＳＲの性能が測定され、このＡＳＲが認識において十分な品質を生む場合は、オンラインにされて、処理２１１で第２のＩＡに取って代わる。他の実施形態では、特定の環境によって決まる時点でさらにテスト８０６が行われて、ＡＳＲの性能が何らかの適用可能な最低閾値未満に下落したかどうか確認される。下落した場合は、フローは追加の訓練のために８０１に戻る。性能が容認可能である場合は、処理は８０６にループバックし、適切な時点でテストを繰り返す。多くの試行の後でも性能が容認可能閾値に達しない場合は、ある実施形態では、訓練は放棄される。

図９は、本明細書で参照されるコンピュータ／プロセッサのいずれかとして使用されるコンピュータ９００の例を示す高レベルのブロック図である。図示されているのは、チップセット９０４に結合された少なくとも１つのプロセッサ９０２である。チップセット９０４は、メモリコントローラハブ９２０および入出力（Ｉ／Ｏ）コントローラハブ９２２を備える。メモリコントローラハブ９２０にはメモリ９０６およびグラフィックスアダプタ９１２が結合され、グラフィックスアダプタ９１２には表示デバイス９１８が結合される。Ｉ／Ｏコントローラハブ９２２には、記憶デバイス９０８、キーボード９１０、ポインティングデバイス９１４およびネットワークアダプタ９１６が結合される。コンピュータ９００の他の実施形態は、異なるアーキテクチャを有する。例えば、ある実施形態では、メモリ９０６はプロセッサ９０２に直接に結合される。ある実施形態では、キーボード９１０、グラフィックスアダプタ９１２、ポインティングデバイス９１４および表示デバイス９１８などのコンポーネントは、直接人間対話を必要としないある種のコンピュータ９００（例えばある種のサーバコンピュータ）には使用されない。

記憶デバイス９０８は、ハードドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、またはソリッドステートメモリデバイスなどのコンピュータ可読記憶媒体である。メモリ９０６は、プロセッサ９０２によって使用される命令およびデータを保持する。ポインティングデバイス９１４は、マウス、トラックボールまたは他のタイプのポインティングデバイスであり、キーボード９１０と共に使用されてコンピュータシステム９００にデータを入力する。グラフィックスアダプタ９１２は、表示デバイス９１８上に画像および他の情報を表示する。ネットワークアダプタ９１６は、コンピュータシステム９００をインターネット１００１に結合する。コンピュータ９００のある実施形態は、図９に示すものとは異なるコンポーネントおよび／またはそれ以外のコンポーネントを有する。

コンピュータ９００は、本明細書に述べる機能を提供するためのコンピュータプログラムモジュールを実行するように適合される。本明細書において、用語「モジュール」とは、指定された機能を提供するのに使用されるコンピュータプログラム命令および他のロジックを指す。従って、モジュールは、ハードウェア、ファームウェアおよび／またはソフトウェアにおいて実現することができる。一実施形態では、実行可能コンピュータプログラム命令で形成されるプログラムモジュールが、記憶デバイス９０８に記憶され、メモリ９０６にロードされ、プロセッサ９０２によって実行される。

本明細書に述べるコンポーネントによって使用されるコンピュータ９００のタイプは、実施形態、およびエンティティによって使用される処理力に応じて異なる。例えば、顧客のコンピュータ１０３は通常、限られた処理力しか有さない。対照的に、ｉルータ１０１は、本明細書に記載の機能を提供するために共に働く複数のサーバを含む場合がある。ある適用例では、単一のプロセッサ（または１組のプロセッサ）が、サポートシステム１０８中のリアルタイムＡＳＲと、訓練サブシステム７１０の訓練ＡＳＲ７１１および他の機能との、両方を実現することができる。これらの適用例では、どれ位多くの訓練をいつ行うかを決定することで、比較的安価かつ適度に強力なコンピュータを、訓練と本番ＡＳＲ処理との両方に使用することができる。

前述のシステムおよび方法は、音声対話に適用可能であるだけでなく、実施形態によっては、例えばビデオ、テキスト、Ｅメール、チャット、写真および他の画像でも使用可能である。これら他の実施形態は、例えばオンラインチャット、セキュリティ監視、テーマパークコンシェルジュサービス、およびデバイスヘルプなどの適用例で使用可能である。具体的な例として、自由回答式の質問が前述のようにして解釈され処理されるヘルプ機構を、Ａｐｐｌｅ，Ｉｎｃ．によって提供されるｉＰｈｏｎｅ（登録商標）やｉＰａｄデバイスなどの消費者デバイスに提供することができる。同様に、前述の技法を使用して、ビデオストリームおよび画像の認識を容易にすることもできる。

以上の考察から明白なように、顧客対話の一部を処理するのに、ＨＳＲサブシステムよりもＡＳＲサブシステムの方が適切であることもある。可能な最良のユーザ体験を提供するためには、アプリケーションプログラム（ワークフローリポジトリ１０６に記憶されたもの等）が音声認識リソースを求める場合に、このような認識に使用されるリソースの選択（即ち、ＡＳＲまたはＨＳＲ、並びに現在の認識タスクに最もよく適する特定のＡＳＲ／ＨＳＲリソースの選択）を最適化することによって、利益を達成することができる。

図１１を参照すると、適切な処理リソースのこのような選択を達成するためのＡＳＲプロキシ１１０２の動作のブロック図が示されている。より具体的には、以下に述べる機能は、様々な実施形態で、ボイス拡張可能マークアップ言語（ＶＸＭＬ）ブラウザ内でのメディアリソース制御プロトコル（ＭＲＣＰ）におけるカプセル化と、ウェブサービスと、アプリケーションプログラミングインタフェース（ＡＰＩ、例えばＪａｖａまたはＣ＃言語で書かれたもの）とのうちの、１または複数によって実現される。特定の一実施形態では、様々なベンダからの共通ＡＳＲが、ＶＸＭＬプラットフォーム（ブラウザ）への標準インタフェースとしてＭＲＣＰを使用し、この環境では、ＡＳＲプロキシ１１０２は、ＶＸＭＬプラットフォームと共に実行されるソフトウェアアプリケーション１１０１にとってはＡＳＲエンジンに見えるように構成されるが、そうではなく、ＡＳＲサブシステムとＨＳＲサブシステムの両方からの音声認識リソースを提供することによって、ＶＸＭＬアプリケーションと音声認識機能との間のプロキシとしての働きをする。

後でより詳細に述べるように、ＡＳＲプロキシ１１０２は、１または複数のＡＳＲサブシステム１１０４（サポートシステム１０８の考察に関して上述したものなど）またはＨＳＲサブシステム１１０６（オフサイトエージェント１０５の考察に関して上述したものなど）を自由に選択するように構成される。統計のデータベースサブシステム１１０５に基づいて、ＡＳＲプロキシ１１０２は、認識決定エンジン１１０３（この動作については図１２に関してさらに述べる）および結果決定エンジン１１０７（この動作については図１３〜図１６に関してさらに述べる）と通信して、いずれか特定の時点でどのＡＳＲ／ＨＳＲリソース１１０４、１１０６を利用するかに関する決定を行う。いずれかのＨＳＲリソースが使用のために選択された場合は、オフサイトエージェント１０５に関して上述したように、対応するユーザインタフェース情報が、適切なＨＳＲデスクトップワークステーション１１０８に提供される。

ＡＳＲプロキシ１１０２は、発話がＡＳＲによって認識されるべきかまたはＨＳＲによって認識されるべきかをソフトウェアアプリケーション１１０１の開発者が考慮する必要性を軽減する。従って、このようなソフトウェア開発者は、コンピュータで従来使用されてきたものよりも人間らしい音声ユーザインタフェースを構築する（かつその利用可能性を想定する）ことができる。

図１１をより詳細に参照すると、様々な実施形態で、ソフトウェアアプリケーション１１０１は、様々な目的を果たす。一実施形態では、ソフトウェアアプリケーション１１０１は、フリーダイヤル発信者補助のためのＩＶＲシステムであり、別の実施形態では、タブレットコンピュータ上の対話式ヘルプアプリケーションである。ソフトウェアアプリケーション１１０１は、何を認識すべきかをＡＳＲプロキシ１１０２に教える（すなわち文法をＡＳＲプロキシ１１０２に提供する）こと、並びに発話（通常は、．ｗａｖファイルなどのオーディオファイル、またはリアルタイムオーディオストリーム（例えばＭＲＣＰリアルタイムプロトコルストリーム））をそれに提供することによって、ＡＳＲプロキシ１１０２に指示する。ＡＳＲプロキシ１１０２は、予想されるように、発話を正しく認識したというＡＳＲの信頼度を示す信頼度スコアと共に、認識したものの「テキスト」または意味で応答する。

ＡＳＲプロキシ１１０２は、従来のＡＳＲとは異なる機能を有することができるので、ＡＳＲプロキシ１１０２は、例えば統計および決定に関する文法メタタグ中にある追加情報を必要とする場合がある。この追加情報は、プロンプトおよび文法を識別するための固有の方式、現セッションを識別するための固有の方式、「声」またはユーザを識別するための固有の方式（話者の音響モデルの学習を継続するため）、並びに、ＡＳＲプロキシ１１０２の挙動を指定するための閾値などである。ある適用例では、文法は事前定義済みまたは組込みである。他の適用例では、文法は組込みではなく、従って、文法に関係するメタ情報（エージェントの決定を枠組みにはめたりガイドしたりするためのユーザインタフェース情報など）が提供されて、可能性ある応答がよりよく定義される（例えばＨＳＲサブシステムの場合）。

ソフトウェアアプリケーション１１０１が、発話を認識するようＡＳＲプロキシ１１０２に要求すると、ＡＳＲプロキシ１１０２は、処理を認識決定エンジン１１０３に渡す。認識決定エンジン１１０３は、どのように発話を認識するかを決定することを担う。例えば、ソフトウェアアプリケーション１１０１によって提供されるパラメータおよび信頼度閾値が、この決定に影響を及ぼすことがある。具体的な例として、極めて高い認識品質を適用例が必要とする場合、認識決定エンジン１１０３は、認識がＨＳＲリソース１１０６のみによって達成されるよう指示することができる。他方、適用例はコストが最も重要だと考える場合もあり、その結果、デフォルトではＡＳＲリソース１１０４のみが使用されるよう指示して、ＨＳＲリソース１１０６の使用は、ＡＳＲを使用するとエラーが多くなる場合のみに取っておくこともできる。

一実施形態では、認識決定エンジン１１０３は、適用例の特定の要件を満たすように適切な閾値を変動させて、同様の決定を自動的かつ動的に行う。従って、資産の多い銀行顧客には、高い品質閾値を使用することができ、一方消費者からの公共料金支払いの問合せには、より低い容認可能閾値が与えられる。この実施形態では、閾値は、過去の認識試行に基づいて計算された履歴統計に基づく。

ＡＳＲリソースの使用とＨＳＲリソースの使用との間で選択することによってだけでなく、このようなリソースの組合せを選択できるようにすることによっても、有益な結果が得られることがわかっている。例えば、あるパラメータセットは、複数のＡＳＲリソースによって認識されるように発話をサブミットすることによって最もよく満たされ、別のパラメータセットは、単一の特定ＡＳＲに発話をサブミットすることによって最もよく満たされ、さらに別のパラメータセットは、ＡＳＲリソースとＨＳＲリソースの混合に発話をサブミットすることによって最もよく満たされる場合がある。実際には、ＡＳＲが訓練または整調された程度（例えば上記の訓練に関する考察のとおり）、ＡＳＲが特定の文法について妥当性検査されたかどうか、複数の認識経路のコストが容認可能かどうか、および履歴結果などの事柄は全て、いずれか特定の状況でどのリソースを適用するかを決定する際に役立つ。

同様に、発話に関係するセキュリティメタタグも、最も適切な認識リソースを決定するのに役立つ。例えば、発話が社会保障番号であることを示すメタタグを、ＡＳＲリソースによって処理されるように送って、人物に関する個人情報を人間が入手する可能性を回避することができる。

ある実施形態で考慮される別のパラメータは、様々なシステムリソースのアクティビティのレベルである。人間のスタッフに多量の要求が溜まっている場合、この未処理要求は、ＡＳＲリソースの使用を増加させることの方を選ぶためのパラメータとして使用可能である。

ある実施形態では、同じタイプであろうと異なるタイプであろうと複数のリソースを使用して、結果の二重チェックが提供される。

さらに別の実施形態では、認識決定エンジン１１０３は、現在のオーディオストリームの長さを動的に把握しており、これを、対応する文法によって定義される予想される発話の長さと比較する。例えば、発話が、「赤（red）」、「緑（green）」、「青（blue）」の３色のうちの１つだけからなる文法を有すると予想され、実際の発話の長さが３秒である場合、発話が文法中の予想される単一音節の色のうちの１つでないという予期に基づいて、発話をＡＳＲリソースに認識させるという前の決定を変更し、ＡＳＲに加えてまたはＡＳＲに代えてＨＳＲリソースに認識させることができる。このような手法は、「意外な」発話を認識するための最終的な時間を最小限にし、従ってＡＳＲプロキシ１１０２の全体的な効率を高めることがわかっている。

上述したように、ＡＳＲプロキシ１１０２および対応するエンジン１１０３、１１０７の動作は、システムを個人化するための統計、閾値および他の固有情報を広く利用して、ソフトウェアアプリケーション１１０１のニーズに対応する。この情報は、図１１に示すように統計データベース１１０５に記憶される。例えば、ＡＳＲの動作の結果は、信頼度スコア統計としてデータベース１１０５に記憶され、このＡＳＲについての総統計は、ソフトウェアアプリケーション１１０１によって必要とされる適用可能な業務規則または他の規則の下でこのＡＳＲが使用可能かどうかに関して考慮される。さらに、話者、プロンプト、文法、適用例、認識方法（例えばＡＳＲ、ＨＳＲ、単一ＡＳＲ、複数ＡＳＲ、複数ＨＳＲ）、信頼度、合致なしまたは入力なし、および訓練／整調など、発話に関するあらゆる統計は、ＡＳＲプロキシ１１０２によってデータベース１１０５に記憶される。

前の図に関して述べたのと同様にして、発話に対する使用可能な結果をＡＳＲが提供できなかった場合は、発話は、認識／不一致解決のために、ＨＳＲリソースに送られる。統計は、ＡＳＲだけでなくＨＳＲについても維持され、統計はさらに、個別の話者ベースでも維持される。従って、ＡＳＲが特定の話者の認識において特に効果的であることがわかった場合、同じ話者からの後の発話にこのＡＳＲが使用される可能性を増大させるために、統計が維持および更新される。同様に、統計は、個別の文法ベースでも維持され、それにより、この場合もやはり、予想される文法、またはプロンプト／文法の組合せに基づいて、使用する適切なリソースを認識決定エンジンが選ぶ可能性が最大化される。例えば、「はい／いいえ」文法は、「あなたはジョンスミスですか？」など、ＡＳＲによる単純なプロンプトの認識にはより効果的であろうが、「今日は先週の同じ日に比べて気分がいいですか？」など、より複雑な質問には、効果がより低いであろう。

上記から一般化すると、統計は、様々な根拠で生成され、いつ特定のＡＳＲ／ＨＳＲリソースを使用するかについてインテリジェントな決定が行われるように維持される。信頼度レベルに基づいて、高信頼度のＡＳＲ認識が可能な文法を、より頻繁にソフトウェアアプリケーション１１０１によって使用することすらできる。例えば、「はい」または「いいえ」文法は、単純なＡＳＲリソースでは信頼度が非常に高いであろう。統計は、「あなたの電話番号を（５５５）１２３−４５６７として頂戴しておりますが正しいでしょうか？」などの単純な確認ステートメントから、「この１週間、気分がよかった場合は「はい」と言って下さい。気分が全く優れなかった場合は「いいえ」と言って下さい。」などのより複雑なコミュニケーションまでの、プロンプト／文法の組合せに関して記録される。

本明細書における文法に関する考察は、文法とプロンプトの組合せに拡張可能かつ一般化可能である。例えば、ある統計は、現在のセッションにおける現在の話者の１組の発話（すなわち複数のプロンプトにわたる）についての全体的な信頼度に関係する。ＡＳＲ認識がプロンプト／文法の組合せにかかわらず話者に対して失敗している場合、このことは、ＡＳＲプロキシ１１０２が、この話者に対してはＡＳＲを試みるどころかＨＳＲに頼る方がよいであろうことを示す。他方、特定の話者の発話が、強い信頼度をいつも決まって示している場合、ＡＳＲプロキシは、好ましい認識方法としてＡＳＲを使用する。特定のセッションを超えて一般化するために、固有の話者参照ＩＤにより、システムは、特定の話者を認識して（例えば、システムと接続するのに使用された電話番号に基づいて）、適切なＡＳＲリソースまたはＨＳＲリソースを選ぶことができる。

ソフトウェアアプリケーション１１０１は、ソフトウェア開発者が特定の状況について適切だと思うことのできる、かつ、状況によっては、前の認識経験に基づいて時の経過に伴って生成された、閾値を提供する。例えば、ＨＳＲリソースを介した二重チェックまたは確認によって統計を生成することができる場合、これらの統計は、収集されてデータベース１１０５に記憶される。このような統計からの平均、標準偏差およびモード情報が、このようなアプリケーションの全体的な目標に基づき、ソフトウェアアプリケーション１１０１のソフトウェア開発者によって決定された必要性に応じて、様々な閾値に適用される。

さらに、統計は、ＡＳＲリソースにさらに依拠することが効果的でなくなるときを決定するのにも使用可能である。例えば、ＡＳＲおよび特定の文法についてのかなりのサンプルサイズの認識品質が、性能が容認可能な認識閾値を超える可能性が低いことを示す場合、このＡＳＲは、この特定の認識タスクに対しては将来の考慮から除外される。この認識タスクはより多くの訓練（または整調）を必要とする可能性があるが、複数の訓練／整調を試みてもうまくいかないことが判明することにより、この特定の認識試行は、プロンプト／文法に対する調節や、新しいＡＳＲまたは新しいバージョンのＡＳＲの使用などの変化が生じるまで、考慮から永久に除外される。

統計はまた、ＡＳＲを整調するのにも使用可能である。文法の整調は、文法「赤、緑、または青」において「赤」が使用されるときのパーセントなど、純粋に統計的であることもあり、または、「青」に対する「ターコイズ」など、類義語を含む可能性もある。後者の場合、整調は、ＨＳＲリソースを「文法外」レコグナイザに使用することによって容易になる（例えば、特定の場合に「ターコイズ」が「青」の類義語と考えられるべきであることを確認するために）。このような整調の直後は、適用例によっては、整調されたＡＳＲを、本番ベースではなく「サイレントな」限定テストベースで導入して、性能が容認可能な閾値よりも高いことを確実にすることが望ましいであろう。一実施形態では、ＡＳＲが当該の文法を認識できることを検証するために、かつ、上述した妥当性検査の間に信頼度閾値統計を計算するために、かつ、ＡＳＲによる認識が無効な場合に信頼度閾値統計を計算するために、ＨＳＲが利用される。妥当性検査の後でも、ＡＳＲまたはＨＳＲリソースによるランダム二重チェックが、選択された認識方法の妥当性に対する継続的なチェックを提供する。このようなチェックの頻度は、一実施形態では、正しいＡＳＲ認識と間違ったＡＳＲ認識との間の統計的偏差に基づく。具体的な例として、正しい認識の平均信頼度が５６であり、間違った認識の平均信頼度が３６である状況を考えてみる。標準偏差が小さい（例えば８）場合、このことは、正しい認識と間違った認識との間には実際上の混乱はほとんどないことを示唆することになり、従って、二重チェックはあまり頻繁に使用する必要はない。しかし、標準偏差がより大きい（例えば１２）場合は、文法信頼度閾値をより細かく整調するために、より頻繁な二重チェックが必要とされるであろう。

時の経過に伴って、統計は、ＡＳＲプロキシ１１０２に、その初期動作を変更するよう提案することができる。例えば、非常によい成功が統計的に示唆される場合、このことは、２つのＡＳＲの二重チェックから、１つのＡＳＲのみのチェックへの変更を提案することができる。または、成功が乏しい場合は、特に難しい文法に対して訓練若しくは整調する試みを止めて、代わりにＨＳＲのみを使用することを提案することができる。

ＡＳＲの初期訓練と後続の整調は両方とも、共通の特性を共有し、これらは同様に実施されてよい。しかし、多くの場合、訓練は、初期整調よりも微妙な問題、大きい語彙および統計言語モデルを伴い、従って、整調ではうまく働く技法が、訓練には最適でないことがある。訓練は、かなりより大きいサンプルサイズ、ＨＳＲをより多く使用すること、および文法外ＡＳＲリソースに依拠することを必要とする場合がある。

特に複雑な文法は、異なる認識モデルを有する２つのＡＳＲ（異なるベンダからの）による一貫した二重チェックを必要とすることがあり、異なる結果がＨＳＲによって判決される。複数のＨＳＲ（例えば、２つのＨＳＲと、違いを解決するように働く第３のＨＳＲ）に依拠することは、場合によっては、さらに利益をもたらすことができる（例えば、本明細書にその内容が完全に記載されているかのように参照によりその内容が組み込まれる特許文献５参照）。ＡＳＲプロキシ１１０２は、ソフトウェアアプリケーション１１０１を介して、これらの可能性のいずれにも対処するように構成可能である。

図１２に移るが、一実施形態では、認識決定エンジン１２０１は、以下のように動作して、履歴統計（例えば、話者、セッション、文法および適用例についての）並びに他の要因に応じて、かつ様々な構成設定に基づいて、どのように発話を処理するか決定する。図１２に示す例では、最初のステップとして、認識決定エンジン１２０１は、ＡＳＲが訓練または整調されるまでＡＳＲが使用されないように指示することができる。これを決定するためにチェック１２０２が行われる。そのように指示される場合は、チェック１２０７が行われて、このような整調／訓練が既に完了したかどうか判定される。そのように指示されない場合は、クイックチェック１２０３が行われ、訓練が必要でないほど文法が十分に単純（例えば文法がごく少数の語末しか有さない）かどうか判定される。文法が単純でない場合は、処理は再びチェック１２０７に移る。文法が十分に単純である場合は、処理はチェック１２０４に移る。上述したチェック１２０７では、この文法に対するＡＳＲ成功についての記憶済み統計と、ＡＳＲが前にこの文法に対して整調／訓練されたかどうか（同じアプリケーション１１０１中であろうと、または類似の目標および対応する信頼度閾値を有する場合のある他のアプリケーション中であろうと）とを調べる。十分に訓練／整調されていることをこれらの統計が示す場合は、チェック１２０７は処理をチェック１２０４に渡す。そうでない場合は、処理はＨＳＲ処理１２１０に進む。

チェック１２０４では、データベース１１０５に記憶された信頼度統計、およびＡＳＲが特定の文法を理解できる閾値と、セッション内で話者を認識することの進行中の信頼度における第２の統計とを使用する。整調または訓練されない単純な文法の場合、ＡＳＲがどれくらいうまく認識タスクを実施しているかに関する進行中の統計が、アプリケーションによって提供される予期される認識信頼度閾値、またはプロキシによって計算された閾値と比較される。最初の認識が実施されつつある場合では、閾値は、満たされないと自動的に見なされるように設定されてよく、強制的にＨＳＲによって認識されるようにして、プロキシによって閾値を最初に計算できるようにする。ある実施形態では、閾値は、現在の文法に関する履歴情報によって増補される。追加で、ＡＳＲの話者認識能力が、閾値よりも高い信頼度を示唆する場合は、ＡＳＲ処理が使用されることになり、処理はチェック１２０５に移る。そうでない場合は、ＨＳＲ処理１２１０が使用される。例えば、閾値は、ＡＳＲ認識が信頼度（または調節済み信頼度、例えば高価値の話者）未満になる回数として設定することができる。適用例によっては、この回数は、信頼度未満のＡＳＲ認識が１回でもあれば後続の認識をＨＳＲによって実施させるように、低く設定される。

チェック１２０５で、ソフトウェアアプリケーション１１０１または別の構成要素（例えば訓練若しくは妥当性検査のための要件）により認識に二重チェックの使用が必要とされるかどうか判定する。二重チェックの使用が必要とされない場合は、処理はステップ１２０６に移り、単一のＡＳＲが認識に使用される。

二重チェックが必要とされる場合は、処理はチェック１２０８に移り、２つ以上のＡＳＲによって二重チェックを行うことができるか（例えば、訓練されたＡＳＲおよび他の形で容認可能なＡＳＲが、２つ以上利用可能なので）どうか判定する。行うことができる場合は、処理はステップ１２０９に移り、そのような複数のＡＳＲによって認識が実施される。行うことができない場合、例えばＡＳＲが認識に適さないかまたはＡＳＲ妥当性検査が実施されることになる場合は、処理はステップ１２１０および１２１１に移り、従って、認識はＡＳＲリソースとＨＳＲリソースの両方によって実施される。

ＡＳＲまたはＨＳＲが認識を完了すると、認識に関する統計が統計データベース１１０５に記憶される。

図１１に関して上述したように、ＡＳＲプロキシ１１０２はまた、結果決定エンジン１１０７と通信する。このようなエンジンの目的は、ＡＳＲ／ＨＳＲリソースによる認識プロセスの結果を評価することである。図１３を参照すると、例示的な結果決定エンジン１３０１が示されており、この動作について次のように述べる。結果決定エンジン１３０１は、１または複数のＡＳＲ／ＨＳＲリソースからの認識の結果を検討し、適切な次のステップを決定する。最初に、チェック１３０２が行われて、報告された信頼度レベルが、ソフトウェアアプリケーション１１０１によって設定されたかまたはＡＳＲプロキシ１１０２によって計算された認識閾値を満たすかどうか判定される。満たす場合は、認識成功を反映するように妥当性検査統計が更新されて（１３０３）、結果決定エンジン１３０１の動作は完了する。満たさない場合は、さらに処理が必要とされるので、「フィラー（filler）」プロンプトがユーザに提供される（１３０４）。例えば、発信者は、「まだ作業中なのでお待ち下さい。」と言われることがある。発信者に提供される特定のメッセージは、このようなデフォルトメッセージである場合もあり、または、何らかの形の参照を介してソフトウェアアプリケーション１１０１によって提供および決定されるより具体的なメッセージである場合もある。

次いで処理は、１または複数のＨＳＲリソースによる認識１３０５に移り、チェック１３０６に移って、ＨＳＲの認識がＡＳＲの認識と一致するかどうか判定される。一致する場合は、統計が再び更新される（１３０３）が、今回は、認識はＨＳＲも必要としたので、統計は比例配分される。一実施形態では、比例配分は、信頼度閾値をクリアしたとすれば提供されたはずのスコアから３分の１の差引きである。

ＨＳＲとＡＳＲとの間の認識の結果が異なる場合は、チェック１３０８が行われて、二重ＨＳＲが使用されたかどうか判定される。使用された場合は、二重ＨＳＲからの結果が使用され（１３０７）、成功したＡＳＲ認識を追跡する統計がデクリメントされる。使用されなかった場合は、追加のフィラーメッセージが再生され（１３０９）、追加のＨＳＲ認識が企てられる（１３１０）。ＨＳＲ結果が一致しない場合は、ＨＳＲを使用する第３の試みが実施される（これは、ある実施形態では行われるが、他の実施形態では行われない）。ＨＳＲ間に合意がない場合、「合致なし」という結果が返される。これは、どのレコグナイザも話者を理解しないことを示す（従ってＡＳＲへのどんな偏向も示されない）。現在の負荷条件に応じて、第２または第３のＨＳＲを実施するのが実際的でないこともあり、その場合は、単一のＨＳＲ結果が使用されるが、やはりＡＳＲへの偏向はない。このような実施形態では、図１４、図１５および図１６に関しても論じる結果決定エンジンの動作について、同様の処理が使用される。ＡＳＲがＨＳＲ認識と合致すると判定された場合は、処理は完了する。そうでない場合は、処理は１３０７に戻って、上述したように、ＨＳＲ認識を適用し統計を更新する。

一実装形態では、ＡＳＲは、認識の結果として文法から選択する必要はないことに留意されたい。ＡＳＲはまた、「合致なし」、「入力なし」または「雑音」という結果を返すこともでき、その場合は、やはりアプリケーションによって確立された基準に応じて、前述のようにさらにＨＳＲ処理が使用される。

図１４を参照すると、結果決定エンジン１４０１の一実施形態が示されており、この動作について以下のように述べる。結果決定エンジン１４０１は、２つ以上のＡＳＲリソースからの認識の結果を検討し、適切な次のステップを決定する。最初に、チェック１４０２が行われて、２つのＡＳＲリソースからの結果が一致するかどうか判定される。一致する場合は、チェック１４０３が行われて、信頼度が適切な閾値よりも高いかどうか判定される。一実施形態では、各ＡＳＲはそれ自体の閾値を有し、いずれかのＡＳＲが信頼度閾値よりも高ければ信頼度は十分であると考えられる。その場合、閾値よりも高いレコグナイザについては妥当性検査統計がインクリメントされ（１４０４）（一致するが閾値未満であるＡＳＲがあれば、それについての統計はインクリメントもデクリメントもされない）、処理は完了する。

結果が一致しない場合、または信頼度レベルが十分に高くない場合は、フィラーが発信者に対して再生され（１４０５）、１４０６で、認識を実施するようＨＳＲリソースが呼び出される。次にチェック１４０７が行われて、ＡＳＲ結果のうちの少なくとも１つがＨＳＲ結果と一致するかどうか判定される。一致しない場合、チェック１４０８が行われて、ＨＳＲが二重チェックＨＳＲであったかどうか判定される。そうでなかった場合は、再びフィラーが再生され（１４０９）、追加のＨＳＲ認識１４１０が実施される。ＨＳＲがＡＳＲと一致する場合、またはＨＳＲが二重チェックであった場合、または第２のＨＳＲ１４１０が実施された場合は、処理は移行して、一致するＨＳＲ結果を使用する（１４１１）。これは、一致しないＡＳＲからの統計をデクリメントすることを含み、また、一致するが閾値未満であるＡＳＲがあれば、それらからの統計をデクリメントする（ただし比例配分量、一実施形態では３分の１で）。次に、閾値より高い一致するＡＳＲ妥当性検査統計があれば、それらがインクリメントされ（１４１２）、処理は完了する。

図１５は、１または複数のＡＳＲリソースが１または複数のＨＳＲリソースと共に使用される場合の、結果決定エンジンの処理を示す。この場合の、特定の結果決定エンジン１５０１の動作は、結果が全て一致するかどうかチェックすること（１５０２）によって開始する。一致する場合は、上記のように、チェック１５０３が行われて、各ＡＳＲについての信頼度がその閾値よりも高いかどうか判定され、閾値よりも高い場合は、妥当性検査統計がインクリメントされる（１５０４）。上述したように、一致するが閾値未満であるＡＳＲがあれば、それらについては比例配分の差引きでインクリメントされる。次いで処理は完了する。

結果が一致しない場合、チェック１５０５が行われて、二重チェックＨＳＲが使用されたかどうか判定され、使用されなかった場合は、フィラーが再生され（１５０６）、第２のＨＳＲ認識１５０７が実施される。次いで、ＨＳＲ結果が一致すると仮定して、上述したように、ＨＳＲ結果が使用され（１５０８）、一致しないＡＳＲについての統計がデクリメントされる。ＨＳＲ結果が一致しない場合は、処理は図１３に関して上述したように継続する。一致するＡＳＲがあれば、それらについては、完全に、または上述したように比例配分方式で、妥当性検査統計がインクリメントされる（１５０９）。次いで処理は完了する。

図１６を参照すると、ＨＳＲリソースのみが使用される場合の、結果決定エンジン１６０１の一実施形態の処理が示されている。最初のチェック１６０２で、二重チェックＨＳＲが使用されたかどうか判定する（呼出し元アプリケーションによって二重チェックＨＳＲが必要とされたと仮定して）。二重チェックが使用されなかった場合は、フィラーが再生され（１６０３）、第２のＨＳＲ認識１６０４が実施されて、認識が正しいことが確実にされる。

次にチェック１６０５が行われて、ＨＳＲの結果が一致するかどうか判定される。一致しない場合は、処理は完了し、一実施形態では、呼出し元アプリケーションの要件を満たすために、第３のＨＳＲ認識（図示せず）など、このプロセスの範囲外のさらに他の処理が必要とされることになる。このような場合、第３の認識の後に収束がない場合は、「合致なし」状況が宣言され、これは、認識の試みが失敗したことを示す。収束がある場合は、少なくとも２つの一致するＨＳＲの結果が使用される。

チェック１６０５における２つのＨＳＲ結果が一致する場合は、処理は完了し、例えば認識された発話は、前述のような整調／訓練のためのグループに追加することができる。プロンプトに対する応答の解釈は、テキスト分析の２つの種類、すなわち情報抽出およびセンス分類として見ることができる。情報抽出は、顧客ＩＤ、電話番号、日時、住所、製品タイプ、問題など、用件フォームのスロットを埋めるのに不可欠な特定の情報断片を、識別、抽出および正規化することである。センス分類は、追加の２つの情報タイプ、即ち意味（意図）および応答品質を識別することに関係する。意味（意図）は、どんな種類のフォームを埋める必要があるかということと関係がある（料金請求、予約のスケジューリング、苦情など）。応答品質は、応答自体と関係がある（不明瞭、雑音、英語ではなくスペイン語、生のエージェントと話したいという要望など）。

図１７を参照するが、上述の方法およびシステムを実現して、人間らしい体験を最大限にすることができる。予測最適化１７３０およびメディア加速１７３４の結果に示すように、ＡＳＲプロキシからアプリケーションに応答し返すための全体的な認識ギャップ時間は、一例では１．２５秒に短縮することができる。図１７の具体的なグラフを詳しく検討するが、１７１０は、最適化されない典型的な認識体験を表す。認識すべきメディア（発話）は、３．７５秒の長さである（１７５０）。この場合に、ＡＳＲプロキシがメディアをリアルタイムでストリーミングするが、通常、自動認識を完了するには、メディアストリームの終わりから、１秒の数分の１だけ多くかかる（１７１２）。ＡＳＲプロキシの結果決定エンジンは、ＨＳＲ（後述する図１８の１８６０）が必要だと決定するが、メディア（発話）は始めから処理される必要があり、これにより、もう約４秒が追加され（１７１４）、ユーザから見たギャップは少なくとも４．２５秒になる。このギャップは、アプリケーション１８１０によって、業界で「フィラープロンプト」としばしば呼ばれる方式で埋めることができ、それにより、システムがまだ問題に取り組んでいることをユーザが確実に認識するようにする。このフィラープロンプトは、発信者とのより人間らしい対話を生み出す目標を達成しないのは確かである。グラフ１７１５に移ると、システムは、メディアを例えば１秒加速させることによって改善を図ることができ、それにより、人間援助による理解を３秒に短縮し（１７１９）、認識ギャップまでのメディア停止を３．２５秒に短縮することができる。これはなかなかの改善である。１７３０に示すように、自動認識が、部分認識予測器を使用して、より短い時間で結果の予測を提供する。１７３２に示すように、認識が失敗したと判定するのに２秒しかかからず、その後、ＡＳＲプロキシは、人間援助を求めてメディアをストリーミングし、メディアを加速させる。結果として、メディアの終わりから人間援助の成功までの全体的な認識ギャップは、４．２５秒から１．２５秒に大きく短縮された。これにより、ＡＳＲプロキシの認識ギャップは、人間らしい対話により近く合致する範囲に短縮される。

図１８に、ＡＳＲプロキシの主要なシステムコンポーネントを示し、図１１のいくつかの要素を詳述してＡＳＲプロキシをさらに例証する。図１１の図解の一部にはないが、本開示内にはユーザ状態管理ストア１８１３があり、明確にするためにこれを図１８に特に示す。ユーザ状態管理１８１３は、ユーザに関する情報（例えば、ユーザ識別、好ましい通信チャネルおよび所有機器）を有する。認識成功（人間援助ではなく自動化）など、ユーザの処理にとって重要な情報が、将来の使用のために統計ストア１８３０に記憶される。システムは、各対話のステータスに関する情報を維持する。この情報は、一方では、意図分析の利用可能性に関する情報からなり、他方では、提示された認識要求と、これらの要求に対する応答と、これらの応答の意味（意図）と、これらの応答から抽出された特定の内容と、プロキシが次にどんなアクションを実施することになるかとのシーケンスに関する情報からなる。

プロキシ処理システムは、特定のプロンプトと、このプロンプトに対する応答の意味（意図）と、この応答から抽出された特定の情報とに基づいて、そのアクション（すなわち、どんな追加情報をユーザに要求するか、およびその情報を用いてどんなアクションを次に実施するか）を調整する。システムステータスサブシステム１８１５は、ＨＳＲキャパシティまたはある実施形態ではシステム負荷と、これがどのように自動認識および人間認識の使用に影響を及ぼすかとを、常に把握している。図１８の残りの要素については、他の図に関して上述したとおりであり、ここでは、ＡＳＲ／ＮＬＵ１８５０は、利用できる複数のＡＳＲ／ＮＬＵインスタンスを表すように複数の円で特に示されている。

図１９に、システムステータスの評価に基づいてＡＳＲまたはＤＴＭＦの機能を場合により使用する（アプリケーションに基づいて適切なら）、決定エンジンの動作を示す。本明細書では、これらの動作は認識決定エンジン１９８０および結果決定エンジン１９９０によって処理されるものとして述べるが、様々なメモリおよびプロセッサアーキテクチャを使用してこのようなエンジンを実現できることは、当業者なら認識するであろう。認識に関する統計がない場合（１９００）は、十分なＨＳＲキャパシティがない場合にＤＴＭＦ手法を使用して自動化するようアプリケーションに知らせること以外には、自動化は使用されない。ＤＴＭＦがアプリケーションに利用可能にされることになり、アプリケーションは、業務規則によってＤＴＭＦの変形が利用可能にされることを許容する。この実施形態では、ＤＴＭＦは、アプリケーションからの第２の認識要求に基づいて使用されることになる。様々な実施形態で、アプリケーションは、利用可能であることを無視して後続の認識を試みることを選ぶこともでき、または、ある認識要求に対してはＤＴＭＦを使用し、最も難しいアイテムはＨＳＲに任せることを選ぶこともできる。例えば、電話番号のデータ収集はＤＴＭＦによって容易に行うことができるが、ＥメールアドレスはＨＳＲによってより適切に扱われる。

アプリケーションが、ある実施形態で、システムステータス１８１５および統計の利用可能性１８３０に応じて、通知し（１９００Ｒ）、いくつかの形の人間らしい対話を提供する。即ち、これらの対話は、（１）人間援助による理解のみを使用した、人間らしい対話１９２５、（２）自動化と人間援助の組合せを高品質で使用した、人間らしい対話１９３０、（３）アプリケーションが異なる品質に応答できることを必要とせずに、自動化と人間援助の組合せを負荷要因に応じて可変品質で使用した、人間らしい対話１９３０、（４）アプリケーションがより低い自動化信頼度に合わせて検証促進を増加させる、自動化１９５０と人間援助１９６０の組合せを負荷要因に応じて可変品質で使用した、人間らしい対話１９３０または１９４０、および、（５）ＤＴＭＦダイアログなど、人間らしくなることが意図されない対話１９４０である。このように、システムは、ＡＳＲプロキシの機能とシステムの負荷とに応答して、種々のタイプのプロンプトを提示する。例えば、（５）の場合では「販売については１を押して下さい。・・・については２を押して下さい・・・」となるが、同じ質問が、「どういったご用件ですか？」として言い換えられることになり、これは（１）の場合を例証する。

図２０は、図１８および図１９で主に述べたようなロジックおよびコンポーネントを含み、統計を用いたＡＳＲおよびＨＳＲ処理のフローを示す。図２１および図２２は、任意選択の同時並行フローであることに留意されたい。図２０は、認識決定エンジン２０００および結果決定エンジン２０２０を使用し、これらは、統計１８２０をシステムステータス情報１８１５と共に使用し、任意選択で、認識メディア（音声、ビデオ）を加速させて（２０１０）、自動化と人間援助との間のフェイルオーバ時間を短縮する。

図２１に、任意選択の並行フローを示すが、この場合、認識決定エンジン２１００における認識およびシステムステータス１８１５に、タイマ統計が組み合わせられる。メディアが、通常うまく認識できるもの（システム負荷に従って調節できる）よりも長い場合は、タイマイベントが発火し、認識は人間援助１８６０に移る。結果決定エンジン２１５０は、前述のように動作する。

図２２に、任意選択の並行フローを示すが、この場合、認識決定エンジン２２００中で、システム負荷予測信頼度調節に応じてメディアの一部に対する認識予測が行われ、認識が十分に成功でない場合、認識は人間援助１８６０に移る。結果決定エンジン２２５０は、やはり前述のように動作する。

図２３に、メディアおよびメディアの意味の周りでデータを収集して、意味抽出のための最適な文法および分類器を構築するための、かつ最適な認識予測器も構築するための、整調サブシステム／フローを示す。図２３では、ＡＳＲ２３１０および分類器自動化が、アプリケーション中のプロンプトの選択されたサブセット２３２０に適用される使用ケースについて述べる。アプリケーションプロンプトのセットは様々なカテゴリに入るが、これらのうちのいくつかは自動化の自明な候補であり、いくつかは自動化が困難である。例えば、はい／いいえプロンプト、および限られたオプションプロンプトの場合は通常、ユーザ発話のレパートリはごく限られ、意図ラベルはごく少数となる。これらのタイプのプロンプトを評価しモデル化するには、ＡＳＲ文法に対しても統計言語モデルに対しても機械学習分類器２３４０に対しても、比較的少量のデータしか必要でない。他方、自由回答式プロンプトでは、ユーザははるかに制約の少ない発話セットを生むことができるが、自由回答式プロンプトはより難しい。これらは、一般的と領域特有の両方の知識ベース２３３０によって増補することができる。これらのタイプのプロンプトには、比較的より多量のデータが必要である。多量のデータがあるときであっても、全てのタイプの発話または意図ラベルについての信頼できるモデルを生むには、なお多様性が大きすぎる場合もある。言い換えれば、これらの場合、プロンプトの言語的、カテゴリ的および統計的な特性を確立して、これらの特性に基づいてプロンプトの選択および策定を駆動することによって、自動化は進行する。これは、次のような１組の相関するタスクを伴う。

− 発話をそれらの特性に基づいて種々のカテゴリに分類する。
− ＡＳＲおよび分類器自動化に適した特性により、所与のアプリケーションの候補プロンプトを識別する。
− 早期認識の成功または失敗に対して予測器を決定する。
− 各プロンプトにつき、このプロンプトによって生成される発話に対するＡＳＲのための音響モデルおよび言語モデルと、このプロンプトのターゲット意図についての分類器モデルとを作り出し、整調し、記憶する。
− ＡＳＲおよび分類器自動化と、人間による意図分析とを、いつ利用またはトレードオフするかを決めるための、選択基準を決定する。

図２４は、北米電話番号を複数の認識構成要素に分割する例を用いた、どのようにタイマ統計を計算できるか、並びに非常に単純な予測器の例である。要素２４０１から２４０３は、特定の質問（プロンプト）をうまく認識した際に集められた統計を表す。要素２４０１は、長さが２秒以下の種類の発話を表す。この長さは、この例で統計を有する全ての発話の１５％を表す。ＡＳＲは、２秒以下の発話に対して９０％成功と決定された。要素２４０２は、２秒よりも長く３秒以下の種類の発話を表し、ＡＳＲ認識の成功は７５％であり、発話の２５％がこのグループに入る。要素２４０３は、３秒よりも長く４秒以下の種類の発話を表す。これは、システムステータスによって影響を受ける可能性のある使用ケースの例である。十分なＨＳＲリソースがある場合は、タイマを確立して認識を３秒（２４０２）で中断し、ＡＳＲを使用して発話の３２．３％をうまく認識することができる。または、システム負荷が増大した場合は、タイマを４秒（２４０３）に調節し、４４．３％を認識することができる。非常に高い負荷の下では、ＡＳＲプロキシは、タイマを使用しないことを決定することができることに留意されたい。但しこれは、話者にとってより長い待機時間を引き起こす。しかしこの結果、５５．３％までがうまく認識される。

要素２４０４は、３桁のエリアコードのＡＳＲ認識を表す。要素２４０５は、３桁のエリアコードのＡＳＲ認識と、それに加えて３桁の交換局の認識を表す。要素２４０６は、北米電話番号全体のＡＳＲ認識を表す。例えば、電話番号を話すのに約８秒かかる場合、各ステップ２４０４、２４０５および２４０６は、発話を処理するのにより多くの時間がかかる。第１のステップ２４０４は時間のうちの約３０％（２．４秒）かかり、ステップ２は時間のうちの６０％（４．８秒）かかり、３つの認識ステップのうちのいずれかが信頼度未満の結果を示す場合は、認識は人間援助に移る。例えば、エリアコードが正しく認識されない場合、電話番号全体が話された後で初めて失敗するのではなく、電話番号が話されている間に、ＨＳＲの使用が２．４秒以内に起こる可能性がある。

様々な実施形態および実装形態で、この応答解釈は、意図分析者のみ（純粋なＨＳＲ）によって行うか、自動化ＡＳＲ（純粋な自動音声認識および意図分類）によって行うか、またはＡＳＲとＨＳＲの何らかの組合せによって行うことができる。ＡＳＲ自動化の結果における信頼度を使用して、いつＡＳＲが信頼できる結果を生成しているかを決定することで、品質損失なしに（または制御された品質損失で）ＡＳＲ自動化をＨＳＲに対してトレードオフすることが可能である。このことは、プロキシ処理システムにおけるこの２つの手法の組合せにより、ＨＳＲのみを使用する場合よりも大きなスループットを達成することができ、より小さい意図分析者チームでピーク需要負荷をうまく満たすこともできることを意味する。

上記の主題については、可能性ある様々な実施形態に関して特に詳細に述べた。主題を他の実施形態で実践することもできることを、当業者なら理解するであろう。第１に、コンポーネントの特定の命名、用語の大文字使用、属性、データ構造またはいずれか他のプログラミング上若しくは構造上の側面は、必須でも有意でもなく、主題またはその特徴を実現するメカニズムは、異なる名称、フォーマットまたはプロトコルを有してもよい。さらに、システムは、述べたようにハードウェアとソフトウェアの組合せを介して実現されてもよく、または完全にハードウェア要素において実現されてもよい。また、本明細書で述べた、様々なシステムコンポーネント間における機能の特定の分割は、例に過ぎず、必須ではない。単一のシステムコンポーネントによって実施される機能が、代わりに複数のコンポーネントによって実施されてもよく、複数のコンポーネントによって実施される機能が、代わりに単一のコンポーネントによって実施されてもよい。

上述のいくつかの部分では、主題の特徴、プロセスステップおよび命令を、情報に対する操作のアルゴリズムおよび象徴表現で提示している。これらのアルゴリズム的記述および表現は、データ処理技術分野の当業者によって、その作業の本質を他の当業者に最も効果的に伝えるために使用される手段である。これらの操作は機能的または論理的に記述されるが、これらの操作は、ソフトウェア、ファームウェアまたはハードウェアにおいて具体化されてよく、ソフトウェアにおいて具体化されるときは、リアルタイムネットワークオペレーティングシステムによって使用される種々のプラットフォーム上に存在しこれらのプラットフォームから操作されるように、ダウンロードされてよい。

さらに、一般性を失うことなく、操作のこれらの構成をモジュールとしてまたは機能的名称によって言及することが、時として好都合であることもわかっている。

特段に明記されない限り、または上記の考察から明らかなように、この記述全体を通して、「決定する」などの用語を利用した考察は、コンピュータシステムメモリ若しくはレジスタ内で、または他のそのような情報記憶、伝送、若しくは表示デバイス内で、物理的（電子的）な量として表されるデータを操作および変換する、コンピュータシステムまたは類似の電子コンピューティングデバイスのアクションおよびプロセスを指すことを理解されたい。

主題はまた本明細書の動作を実施するための装置に関する。この装置は、必要とされる目的のために特に構築されたものであってもよく、またはコンピュータによってアクセスできコンピュータプロセッサによって実行できるコンピュータ可読媒体に記憶されたコンピュータプログラムによって選択的にアクティブ化または再構成される汎用コンピュータを含んでもよい。このようなコンピュータプログラムは、非一時的コンピュータ可読記憶媒体に記憶されてよく、この非一時的コンピュータ可読記憶媒体は、以下のものに限定されないが、フロッピー（登録商標）ディスクや光ディスクやＣＤ−ＲＯＭや光磁気ディスクを含めた任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光学カード、ＡＳＩＣまたは電子的命令を記憶するのに適した任意のタイプの媒体などであり、これらは各々コンピュータシステムバスに結合される。さらに、本明細書で言及されるコンピュータは、単一のプロセッサを備えてもよく、またはコンピューティング能力の増大のために複数プロセッサ設計を利用するアーキテクチャであってもよい。

また、主題は、いずれか特定のプログラミング言語に関して述べるものではない。様々なプログラミング言語を使用して本明細書に記載の主題の教示を実現できること、並びに、特定の言語へのどんな言及も、主題の使用可能性および最良モードのために提供するものであることを理解されたい。

主題は、多くのトポロジにまたがる幅広いコンピュータネットワークシステムによく適する。この分野内で、大きいネットワークの構成および管理は、インターネットなどのネットワークを介して異種のコンピュータおよび記憶デバイスに通信可能に結合される、記憶デバイスおよびコンピュータを含む。

最後に、本明細書で使用される言語は、主に読みやすさおよび教授目的のために選択されたものであり、主題を線引きまたは制限するために選択されたのではない場合があることに留意されたい。従って、本明細書の開示は、主題の範囲を限定するのではなく例証するものとする。

Claims (20)

1. 対話を処理するためのコンピュータ実行システムであって、前記対話は、さらなるコンピュータ実行処理に使用可能になる前に認識を必要とする発話を含み、前記システムは、
   前記発話を提供するように構成されたアプリケーションと、
   認識のために前記発話を受信するように構成された認識決定エンジンであって、前記認識決定エンジンは、第１のタイプのレコグナイザサブシステムおよび第２のタイプのレコグナイザサブシステムから１または複数のレコグナイザを動的に選択する、認識決定エンジンと、
   前記１または複数のレコグナイザと動作可能に結合され、認識結果を提供するように構成された結果決定エンジンと
   を備えることを特徴とするシステム。
2. 前記認識決定エンジンに動作可能に接続されたシステムステータスサブシステムをさらに備え、前記認識決定エンジンは、前記動的な選択において使用するために、前記システムステータスサブシステムからのシステム負荷情報を入力とすることを特徴とする請求項１に記載のシステム。
3. 前記１または複数のレコグナイザのサブセットは、前記認識決定エンジンに信頼度測定基準を提供するように構成され、前記認識決定エンジンは前記信頼度測定基準を前記動的な選択において使用することを特徴とする請求項１に記載のシステム。
4. 前記信頼度測定基準は閾値を含み、前記閾値はリソース利用可能性に基づいて変動することを特徴とする請求項３に記載のシステム。
5. 前記認識決定エンジンは、認識コスト要因に基づいて、前記第２のタイプのレコグナイザサブシステムに対して前記第１のタイプのレコグナイザサブシステムを選択することの方を選ぶように構成されたことを特徴とする請求項１に記載のシステム。
6. 前記認識決定エンジンは、人間リソース利用可能性要因に基づいて、前記第２のタイプのレコグナイザサブシステムに対して前記第１のタイプのレコグナイザサブシステムを選択することの方を選ぶように構成されたことを特徴とする請求項１に記載のシステム。
7. 前記結果決定エンジンは、前記レコグナイザサブシステムのうちの第１のレコグナイザサブシステムと、前記レコグナイザサブシステムのうちの第２のレコグナイザサブシステムとの間の結果の一致に応答して、前記レコグナイザサブシステムのうちの前記第１のレコグナイザサブシステムに関連する信頼度閾値を更新するように構成されたことを特徴とする請求項１に記載のシステム。
8. 前記認識決定エンジンは、最初に前記第１のタイプのレコグナイザサブシステムのうちの第１のレコグナイザサブシステムを選択し、前記第１のタイプのレコグナイザサブシステムのうちの前記第１のレコグナイザサブシステムによって提供された最初の結果に応答して、前記レコグナイザサブシステムのうちの第２のレコグナイザサブシステムの後続の選択を行うように構成され、前記後続の選択は、前記発話の処理が前記第１のタイプのレコグナイザサブシステムのうちの前記第１のレコグナイザサブシステムによって完了される前に行われることを特徴とする請求項１に記載のシステム。
9. 対話を処理するためのコンピュータ実行方法であって、前記対話は、さらなるコンピュータ実行処理に使用可能になる前に認識を必要とする発話を含み、前記コンピュータ実行方法は、
   発話を表すデータをコンピュータアプリケーションから受信することと、
   第１のタイプのレコグナイザおよび第２のタイプのレコグナイザから１または複数のレコグナイザを動的に選択することと、
   前記１または複数のレコグナイザによる処理の結果に応答して認識結果を提供することと
   を備えることを特徴とするコンピュータ実行方法。
10. 前記動的に選択することはシステム負荷測定基準に応答したものであることを特徴とする請求項９に記載のコンピュータ実行方法。
11. 前記動的に選択することは信頼度測定基準に応答したものであることを特徴とする請求項９に記載のコンピュータ実行方法。
12. 前記信頼度測定基準は閾値を含み、前記閾値はリソース利用可能性に基づいて変動することを特徴とする請求項１１に記載のコンピュータ実行方法。
13. 前記動的に選択することは、認識コスト要因に基づいて、前記第２のタイプのレコグナイザに対して前記第１のタイプのレコグナイザを選択することの方を選ぶことを特徴とする請求項９に記載のコンピュータ実行方法。
14. 前記動的に選択することは、人間リソース利用可能性要因に基づいて、前記第２のタイプのレコグナイザに対して前記第１のタイプのレコグナイザを選択することの方を選ぶことを特徴とする請求項９に記載のコンピュータ実行方法。
15. 前記レコグナイザのうちの第１のレコグナイザと前記レコグナイザのうちの第２のレコグナイザとの間の結果の一致に応答して、前記レコグナイザのうちの前記第１のレコグナイザに関連する信頼度閾値を更新することをさらに備えることを特徴とする請求項９に記載のコンピュータ実行方法。
16. 最初に前記第１のタイプのレコグナイザのうちの第１のレコグナイザを選択し、前記第１のタイプのレコグナイザのうちの前記第１のレコグナイザによって提供された最初の結果に応答して、前記レコグナイザのうちの第２のレコグナイザの後続の選択を行うことをさらに備え、前記後続の選択は、前記発話の処理が前記第１のタイプのレコグナイザのうちの前記第１のレコグナイザによって完了される前に行われることを特徴とする請求項９に記載のコンピュータ実行方法。
17. 対話を処理するための実行可能コンピュータプログラムコードを記憶した非一時的コンピュータ可読記憶媒体であって、前記対話は、さらなるコンピュータ実行処理に使用可能になる前に認識を必要とする発話を含み、前記コンピュータプログラムコードは、
    発話を表すデータをコンピュータアプリケーションから受信するための命令と、
    第１のタイプのレコグナイザおよび第２のタイプのレコグナイザから１または複数のレコグナイザを動的に選択するための命令と、
    前記１または複数のレコグナイザによる処理の結果に応答して認識結果を提供するための命令と
    を備えることを特徴とする非一時的コンピュータ可読記憶媒体。
18. 前記動的な選択はシステム負荷測定基準に応答したものであることを特徴とする請求項１７に記載の非一時的コンピュータ可読記憶媒体。
19. 前記動的な選択は信頼度測定基準に応答したものであることを特徴とする請求項１７に記載の非一時的コンピュータ可読記憶媒体。
20. 前記信頼度測定基準は閾値を含み、前記閾値はリソース利用可能性に基づいて変動することを特徴とする請求項１９に記載の非一時的コンピュータ可読記憶媒体。

Images