JP7039657B2 - 会話の応答を生成するためのコンピュータ実装方法、システム、およびコンピュータ可読記録媒体 - Google Patents

Description

本明細書は、自然言語処理に関する。

ユーザは、人間の介入なしには容易に入手できない種類の情報を収集する必要がある場合がある。たとえば、事業または組織の複数の場所からデータを検証または収集するために、ユーザは情報を収集するために事業または組織の各々に発呼する必要がある場合がある。ウェブ検索エンジンは、サービスまたは事業の連絡先情報を提供することによって、そのようなタスクでユーザを支援することができるが、ユーザは、自分自身でタスクを完了するために、依然としてサービスまたは事業に発呼する必要がある。

事業または組織の複数の場所から収集された情報のデータベースを維持するために、人間のオペレータは、データを収集するために多数の事業への自動呼を開始することができるが、手動で実行される場合、被呼者(たとえば、同じ料理を提供する、特定の町にあるすべてのレストラン)を選択して呼を発信するのに時間がかかる場合がある。さらに、いつ呼を発信するべきか、および呼を発信するかどうかを決定することは、一般に、検証、更新、または補足情報の必要性を識別するために、既存のデータの人的解析を必要とする。

ユーザはまた、予約を取る、またはサービスを依頼するなどのタスクを実行したい場合がある。しかしながら、一般に、ユーザが所望のタスクを完了するために対話しなければならない人が存在する。たとえば、ウェブサイトを持たない小規模なレストランで予約をするために、ユーザは発呼して女主人と話す必要があるかもしれない。場合によっては、ユーザが自身で呼を発信する場合でも、しばしば限られたユーザ応答のセットしか受け付けない自動電話ツリーに遭遇することがある。

システムは、システムによって受信されたデータから、特定の番号への呼を開始するかどうかを決定することによって、電話呼を通じて人間と、電話を通じて動作される自動システム(たとえば、IVR)と通信することを含む様々なタスクで、ユーザを支援することができる。呼が発信されると、システムは、情報を取得し、第三者に情報を提供し、たとえば、ユーザの代わりにアクションを実行することなどができる。特定の例では、システムは、ユーザの代わりに人間とのダイアログに参加する。このダイアログは、システムと人間との間の電話接続を介して発生することができる。いくつかの例では、システムは、完了されるべきタスクを含むクエリを提出する検索エンジンユーザのインテントに関連付けられるワークフローに続いて、検索エンジンを含んでもよく、それを動作してもよく、その一部を形成してもよい。システムは、少なくとも1つの自律または半自律ソフトウェアエージェント(「ボット(bot)」)動作を通じてユーザのタスクを実行し得る。

一般的な一態様では、方法は、呼を発信し、呼の間に呼開始システムのボットと人間の被呼者との間で会話を行うための呼開始システムの呼トリガリングモジュールによって、第1のイベントを示すデータを受信するステップと、呼トリガリングモジュールによって、および第1のイベントを示すデータを使用することによって、第1のイベントが、電話呼を開始することで開始する呼開始システムのワークフローをトリガする複数の可能なトリガイベントの特定のトリガイベントであると決定するステップと、決定されたトリガイベントに基づいて、複数の可能なワークフローから特定のワークフローを選択するステップであって、特定のワークフローが決定されたトリガイベントに対応する、ステップと、選択に応答して、i)特定のワークフローによって指定された被呼者に電話呼を開始するステップと、ii)ボットと被呼者との間の双方向の会話としてワークフローを実行するステップとを含む。

実装形態は、以下の特徴のうちの1つまたは複数を含み得る。たとえば、決定されたトリガイベントは、第1のデータソースに関連付けられる値と、第2のデータソースに関連付けられる対応する値との不一致である。第1のイベントを示すデータは、ユーザによって提供され得る。決定されたトリガイベントはユーザ要求であり得る。決定されたトリガイベントは、気象イベント、娯楽イベント、または季節イベントのうちの1つである特定のタイプのイベントであり得る。決定されたトリガイベントは、検索エンジンに提出された検索要求において検出された傾向であり得る。決定されたトリガイベントは、あらかじめ定められた時間期間の経過であり得る。

別の一般的な態様では、方法は、タスクマネージャモジュールによって、ユーザ呼要求の現在のステータスを提供するためにトリガリングイベントが発生したことを決定するステップと、タスクマネージャモジュールによって、ユーザ呼要求の現在のステータスを決定するステップと、ユーザ呼要求の現在のステータスの表現を生成するステップと、ユーザ呼要求の現在のステータスの生成された表現をユーザに提供するステップとを含む。

実装形態は、以下の特徴のうちの1つまたは複数を含み得る。たとえば、決定されたトリガイベントはステータスに対するユーザ要求であり得る。決定されたトリガイベントは、オペレータがユーザ呼要求に関連付けられるセッション情報をレビューした後に、ユーザにステータスを提供するためのオペレータ対話であり得る。決定されたトリガイベントは、ステータス更新イベントであり得る。現在のステータスの表現は、視覚的表現であり得る。現在のステータスの表現は、口頭表現であり得る。ユーザ呼要求の現在のステータスの生成された表現をユーザに提供するステップは、現在のステータスをユーザに配信するための都合の良い時間および方法を決定するステップを含み得る。

別の一般的な態様では、電話呼をボットから移行させる方法は、電話呼の第1の端の第1の人間と電話呼の第2の端のボットとの間の電話呼の間に、呼開始システムによって、第1の人間とボットとの間のリアルタイム会話を解析するステップと、リアルタイム会話の解析に基づいて、呼開始システムによって、電話呼がボットから電話呼の第2の端の第2の人間に移行されるべきかどうかを決定するステップと、電話呼の第2の端の第2の人間に電話呼が移行されるべきであるとの決定に応答して、呼開始システムによって、ボットから第2の人間へ電話呼を移行させるステップとを含む。

実装形態は、以下の特徴のうちの1つまたは複数を含み得る。たとえば、電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、第1の人間の行動、態度、声調、不快レベル、言語、または単語の選択に基づいて、電話呼の間の緊張(strain)を決定するステップを備え得る。本方法は、ボットが同じことを繰り返す、謝罪する、または明確な説明を求めるときに、電話呼の間の緊張の増加を決定するステップを含み得る。本方法は、人間がボットを正すとき、または呼の品質について不平を言うときに、電話呼の間の緊張の増加を決定するステップを含み得る。本方法は、ボットが第1の人間のダイアログに適切に応答したときに、電話呼の間の緊張の減少を決定するステップを含み得る。電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、電話呼のタスクがボットによって完了される呼開始システムの信頼レベルを決定するステップを含み得る。電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、第1の人間が、電話呼が別の人間に移行されるように要求したと決定するステップを含み得る。電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、第1の人間がボットを嘲笑した、またはボットがロボットであるかどうかを尋ねたと決定するステップを含み得る。電話呼が、ボットから第2の人間に移行されるべきかどうかを決定するステップは、緊張があらかじめ定義されたしきい値を上回っていると決定するステップと、緊張があらかじめ定義されたしきい値を上回っていることに応答して、電話呼がボットから第2の人間に移行されるべきであると決定するステップとを含み得る。電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、会話内の1つまたは複数のイベントを追跡するステップを含み得る。電話呼がボットから第2の人間に移行されるべきかどうかを決定するステップは、会話内の1つまたは複数のイベントがルールの基準を満たすかどうかを決定する特徴ベースのルールセットを使用するステップと、会話内の1つまたは複数のイベントがルールの基準を満たしているとの決定に応答して、電話呼がボットから第2の人間に移行されるべきであると決定するステップとを含み得る。

電話呼の間の第1の人間とボットとの間のリアルタイム会話を解析するステップは、会話からインテントを識別するステップと、以前の会話から過去のインテントおよび過去の結果を識別するステップとを含み得る。電話呼がボットから第2の人間に移行されるべきかどうかを決定するステップは、会話からのインテント、過去のインテント、または過去の結果を1つまたは複数の機械学習モデルに送信するステップと、インテント、過去のインテント、または過去の結果に基づいて、電話呼が移行されるべきかどうかを決定するステップとを含み得る。第2の人間は人間のオペレータであり得る。ボットは、ボットから第2の人間への移行が第1の人間にとって透過的になるように、人間のオペレータと同じ音声を使用し得る。第2の人間は、ボットが電話呼を行っているユーザであり得る。本方法は、ボットから第2の人間への電話呼の移行があらかじめ定められた時間量よりも長い時間を要するときに電話呼を終了するステップを含み得る。本方法は、電話呼を人間に移行するのではなく、電話呼を終了するステップを含み得る。

この態様および他の態様の他の実装形態は、コンピュータストレージデバイス上に符号化された方法のアクションを実行するように構成された、対応する方法、装置、およびコンピュータプログラムを含む。1つまたは複数のコンピュータプログラムは、データ処理装置によって実行されると、装置にアクションを実行させる命令を有することによって構成され得る。

本明細書に記載される主題の特定の実施形態は、以下の利点のうちの1つまたは複数を実現するように実装され得る。未確認データの複数のセットではなく、確認データの1つのセットしか記憶されないため、様々なデータソースに必要なデータストレージの量が低減される。たとえば、特定の食料品店の営業時間の3つの異なる未確認セット(たとえば、店頭から収集された1つのセット、店舗のウェブサイトから収集された1つのセット、および店舗の留守番電話から収集された1つのセット)を記憶する代わりに、データソースは、食料品店の人間の代表者への呼から取得された確認済みの店舗時間の1つのセットを記憶することができる。

呼が開始されることを呼開始システムに示すトリガイベントを自動的に検出することによって、被呼者からのデータの収集、予約のスケジューリング、または第三者への情報の提供などの動作を実行するために必要な人的入力の量が低減される。さらに、トリガイベントが発生したときにのみ呼が開始されるため、発信される呼の低減により情報のデータベースを維持するために必要なコンピュータリソースの量が低減される。システムは、特定の被呼者または被呼者のセットに自動的に呼を発信し、人間が実行しなければならない解析の量および人間が監視しなければならないデータの量を低減する。

さらに、システムは、人間のユーザの代わりに会話を行い、特定のタスクを実行するために必要な人的入力の量をさらに低減する。呼開始システムは、複数の呼を同時に調整することができる。たとえば、ユーザは、将来、30分間予約することを望む場合がある。システムは、ユーザによって指定された各レストランに発呼し、他の回線で代表者との会話を実行することができる。発呼された第1のレストランの従業員は、予約が可能であると示唆する場合があるが、客はバーに座る必要がある。発呼された第2のレストランの従業員は、20分の待ち時間があることを示唆する場合があり、発呼された第3のレストランの従業員は、第3のレストランでは客は1時間以内に食事を終了する必要があり、したがって1時間以内にテーブルの準備が整うことをシステムに通知する場合がある。システムは、3つのレストランの各々に並行して発呼し、オプションを提示して応答を受信することによってユーザに相談し、他のすべての予約を辞退しながら、彼の応答に基づいてユーザに最も適したレストランを予約することができる。自動呼開始システムは、自動システムがこれらの呼を一度に行うことができるので、人間のものよりも効率的である。人間のアシスタントは、これらのレストランへの呼のすべてを容易に並行して実行することはできない。

本明細書に記載された主題の1つまたは複数の実施形態の詳細は、添付の図面および以下の説明に記載されている。主題の他の特徴、態様、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。

呼を発信し、呼の間に呼開始システムのボットと人間との間で会話を行う呼開始システムのためのシステムの例示的なブロック図である。 呼を発信し、呼の間に呼開始システムのボットと人間との間で会話を行う呼開始システムのためのシステムの例示的なブロック図である。 ユーザが要求に関するより多くの詳細を入力し得る例示的なユーザインターフェースを示す図である。 要求を行うためにボットに話しかけているユーザの一例を示す図である。 ユーザによって割り当てられたタスクを完了するためのプロセスの一例を示す流れ図である。 ユーザによって割り当てられたタスクを完了するためのプロセスの別の例を示す流れ図である。 システムによって実行されるプロセスの例示的なワークフローを示す図である。 トリガリングモジュールのブロック図である。 電話呼を開始するためのプロセスの一例を示す流れ図である。 システムのタスクマネージャモジュールのブロック図である。 既存のタスクの進捗に関する情報を示すオペレータダッシュボードを示す図である。 ユーザが要求したタスクのうちの1つをレビューするためのオペレータレビュー画面を示す図である。 タスクのステータスを提供するためのプロセスの一例を示す流れ図である。 予約スケジューリングが進行中のときの、図1Bのヘアカット予約要求の視覚的ステータスを示す図である。 予約がうまくスケジューリングされた後の、図1Bのヘアカット予約要求の視覚的ステータスを示す図である。 図1Cのレストラン予約要求の口頭ステータス要求および更新を示す図である。 図1Cのレストラン予約要求に対してユーザによってプロンプトを表示せずにシステムによって提供される口頭ステータス更新を示す図である。 電話呼をボットから人間に移行させるための例示的なプロセス1100を示す図である。 コンピューティングデバイスおよびモバイルコンピューティングデバイスの一例を示す概略図である。

様々な図面における同様の参照番号および名称は同様の要素を示す。

本開示は、本明細書において「ボット」と呼ばれる自動または半自動システム(自動システム)が、呼を発信し、呼の間に人間との会話や独立した会話を行うことによって、人々と通信することを可能にする技術を記載する。ボットは、呼が開始されるべきであることを示すトリガイベントを検出するために、データを受信して監視する。ボットは、あらかじめ定義されたワークフロー、または実行される動作の抽象的な記述によってリンクされた反復可能な動作パターンのシーケンス、またはインテントを通じて機能する。本質的に、ボットは、ユーザにとって役立つタスクを実行するために、人間にどのように反応するか、および人間に何を伝えるかを決定するために、これらのワークフローを使用することができる。

システムは、「木曜日にYves Saint Thomasレストランで2人用のテーブルを予約する」、「シンクが漏れていて、配管業者が必要です!それは午後10時以降です!」などの、クエリとして受信される様々なタスクを処理する。

予約をスケジューリングしたり、商品を購入したり、サービスを要求したりすることを望むユーザは、達成するために設定したタスクを完了する前に、複数の検索を実行し、多くの呼を発信する必要がある場合がある。レストランのテーブルを予約する第1の使用事例では、ユーザは検索エンジンでレストランを検索する可能性がある。いくつかの例では、レストランがウェブサイトまたはアプリケーション上にある場合、クエリは、そのウェブサイトまたはアプリケーション上で(または、ウェブサイトまたはアプリケーションとの統合を通じて)実行されてもよく、ウェブサイトまたはアプリケーション上にない場合、ユーザがレストランに発呼して予約を交渉してもよい。

一例として、システムは、ユーザのために呼を発信するために使用され得る。システムは、ユーザによって要求されたタスクを完了するために、事業および他のサービスと通信する。いくつかの例では、ボットは通信の多くを実行する。いくつかの例では、人間のオペレータは、ボットによって実行される動作の成功をレビューし、検証し得る。いくつかの例では、人間のオペレータがアクションを実行し、ボットは、それらの自動コミュニケーションスキルを向上させるために、人間のオペレータのコミュニケーションから学習する。

第2の使用事例では、ユーザは通常の営業時間外に配管業者を見つけることを望む。そのようなクエリは、処理するのがより難しい場合がある。たとえば、ユーザが手動で配管業者を検索する場合、検索エンジンで配管業者を検索し、そのうちのいくつかに発呼する場合がある。ユーザは、各配管業者に時間制約、場所、および問題の性質を説明し、価格見積もりを取得する必要があり得る。これは非常に時間がかかる場合がある。

同様に、第3の使用事例では、ローカル店舗に在庫があるかどうかをチェックするために、ローカル店舗を検索し、その店舗が、探している特定の商品または製品を有するかどうかを決定するために、それぞれに発呼する必要がある場合がある。

特定のタスクでユーザを支援することに加えて、システムは、営業時間、提供されるサービスなどの情報のインデックスを更新することができる。システムは、紛失したデータ、経年変化したデータ、一貫性のないデータなどの検出に応答してデータを更新するために、自動的にトリガされ得る。一般に、そのような情報を取得するために、ユーザは、各事業またはデータソースを個別にチェックする必要があり得る。

システムは、電話呼を開始することを含む特定のタスクを完了するために必要な人的入力の量を低減することを含む多くの利点を提供する。たとえば、サロンによって提供されるサービスと第三者の予約ウェブサイトに掲載されているサービスとの間の不一致など、特定のトリガ基準が満たされているとの決定に基づいて、システムは自動的に電話呼を開始することができる。システムは、たとえば、電話呼の一端の人間の欲求不満または不快感を検出し、呼を終了するか、または会話が実行される方法を変更することによって、取引クエリの摩擦を低減することができる。システムは、開発途上国のユーザと、交通サービスや教育サービスなどのサービスとをつなぐことができる。システムはまた、ユーザと、ウェブサイトやデジタルプレゼンスのない低技術産業とをつなぐことができる。さらに、システムは、最大規模のアグリゲータと比較しても、異なるアプリケーションに対してスケーラブルである。

図1Aは、呼を発信し、呼の間に呼開始システムのボットと人間104との間で会話を行う呼開始システムのためのシステムの例示的なブロック図を示す。図1Aに示される各構成要素については、以下に詳細に説明する。

システム100は、ボットが人間104と効果的に通信することを可能にするために一緒に働く様々な構成要素およびサブシステムを含む。システム100は、通信フレームワークまたはプラットフォーム102、ダイヤラ106、サウンドシステム108、呼トリガリングモジュールまたはトリガモジュール110、オーディオパッケージ112、セッションレコーダ114、セッションストレージ116、テキスト-スピーチモジュール118、スピーチ終点検出器120、記憶されたテキスト-スピーチ結果または録音122、インテント-テキストモジュール124、スピーチ-テキストモジュール126、スピーチアプリケーションプログラムインターフェース(API)128、テキスト-インテントモジュール130、フローマネージャ132、オペレータコントローラ134、および救済モジュール136を含み得る。いくつかの実装形態では、システムはすべてのモジュールを含む。他の実装形態では、システムはこれらのモジュールの組合せを含む。たとえば、一実装形態では、テキスト-インテント層は不要であり、インテントはスピーチ合成モジュールに直接与えられる。

図1Bは、呼を発信し、呼の間に呼開始システムのボットと人間との間で会話を行う呼開始システムのためのシステムの代替の例示的なブロック図を示す。この例では、通信プラットフォーム102は、ユーザ要求のためのクライアントエントリポイントと、他の要求、すなわち事業からのインバウンド呼のための電話シグナリングサーバと置き換えられる。システムは、他方の端から呼を行うボットサービス(195)との呼を行う電話サーバ(196)に、両方のタイプの要求を送信する。いくつかの実装形態では、ボットサービス(195)は、ボットサービスが人間のような電話会話を行うことを可能にするためのダイアログモデル(198)および言語モデル(199)を含む。電話サーバ(196)は、TTSモデル(197)を含み得る。スピーチ認識装置(191)および/またはオーディオミキサ(194)は、電話サーバ(196)が電話呼(190)の他方の端の人間を理解し返答するための情報を提供し得る。オペレータ(134)は、タスクユーザインターフェース(160)およびキュレーションユーザインターフェース(170)を使用して呼を監視する。オペレータ(134)は、録音スタジオおよび評価TTS(114)からの録音された呼をレビューすることができる。呼プレイヤ(162)はオペレータ(134)に呼を再生して返す。オペレータは、電話サーバ(196)を通じて電話呼を開始するために、ローカルエージェント(175)を使用して呼をスケジューリングすることができる。

図1Aの実装形態では、通信プラットフォーム102は、呼を発信する、事業またはユーザ(104、144)からのインバウンド呼を受信する、またはターゲット事業にコンタクトするなどのタスクを実行することによって、ボットが外部アクタにコンタクトすることを可能にする。通信プラットフォーム102はまた、ボットがユーザの代わりに呼を行うためにユーザから要求を受信することを可能にする。

いくつかの実装形態では、ユーザは、ユーザインターフェースとの対話を通じて、またはスピーチ要求を通じて、別のユーザまたは事業への呼を要求する。これらのユーザ要求は、予約を取ること、レストランを予約すること、犬を散歩させる人を発見すること、またはユーザが購入したい商品を有する店舗を見つけることなどの、アシスタントタイプのタスクのためのものであり得る。

図1Cは、ユーザが要求に関するより多くの詳細を入力し得る例示的なユーザインターフェースを示す。ユーザは、「予約」ボタンをクリックするか、他の方法でユーザインターフェースと対話することによって、要求を開始し得る。たとえば、ユーザがヘアカットの予約をしたい場合、ユーザは、ユーザがヘアカットを受けたいサロンに関連付けられるウェブサイトと対話し得る。代わりに、ユーザは、検索結果における結果としてサロンを含む検索結果リストと、または、地図上にサロンを示すユーザインターフェースと対話し得る。これらのインターフェースのいずれもユーザが呼を要求することを可能にし得る。ユーザは、ユーザが会いたいと思うプロのスタイリスト、ユーザがやってほしいサービスのカテゴリ、およびサービスの日時などの、ユーザの要求の詳細を入力し得る。図1Bに示されるように、ユーザは、「予約を続ける」ボタンをクリックしてもよく、美容院の予約の要求が行われていることを示すために何らかの他のアクションを行ってもよい。

図1Dは、要求を行うためにボットに話しかけているユーザの一例を示す。ユーザがボットに要求を話した後、ボットはその要求を確認し得る。ボットはまた、ユーザからの要求に関する追加情報を要求し得る。たとえば、ユーザがヘアカットを行う要求をボットに話す場合、ボットは、ユーザがヘアカット予約を希望する場所、ヘアカット予約がスケジューリングされるべき日、およびユーザがどのようなヘアカットサービスをスケジューリングしたいかに関する情報を尋ねる場合がある。

ユーザは、タスクが実行され得ないときにシステムにタスク要求を行う場合がある。たとえば、ユーザは、すべてのヘアカットサロンが閉店された午後11時にヘアカット予約をスケジューリングするための呼を要求する場合がある。したがって、システムは、通常ならシステム100によって決定されるか、システム100によって取得される、サロンの営業時間中などの後日または後の時間に開始および完了されるように、要求をタスク情報ストレージに記憶し得る。

いくつかの実装形態では、システムは、要求を処理する際に遅延が生じるという初期フィードバックをユーザに提供する。たとえば、サロンが閉店されている午後11時に、ユーザがヘアカット予約をスケジューリングするために発呼する要求を行うと、システムは、サロンは閉店されているので、サロンが開店してからシステムがサロンに到達するまでタスクを完了する際に遅延があるという、視覚的表示、オーディオ表示、または何らかの他の表示をユーザに提供する。

いくつかの実装形態では、タスク情報ストレージ150は、タスクを要求するユーザの名前、発呼するべき1人または複数の人々または場所、要求されたタスクのタイプ、タスク要求が行われた方法、特定のタイプのタスクに関する詳細、タスクを完了するために行われたアクティビティの詳細、タスクの開始日、タスクの完了日、要求元ユーザへの最後のステータス更新の時刻、呼タスクをダブルチェックしたオペレータ、タスクの終了日を要求したユーザ、およびタスクの現在のステータスなどの各タスクに関する情報を記憶する。

いくつかの実装形態では、タスクマネージャモジュール160は、人々または事業への呼をいつスケジューリングするかを決定する。タスクマネージャモジュール160は、タスク情報ストレージ150からタスクを監視し、受信したタスクをスケジューリングするために適切な時間を決定する。特定のトリガリングイベントが発生した後に他のタスクがスケジューリングされる間、一部のタスクは直ちにスケジューリングされる。

多くの状況において、システム100によって発信された呼の他方の端には、人間104などの人間が存在する。人間104は、ボットがコンタクトしようとしている組織の代表者であり得る。いくつかの例では、事業に発呼するために通信プラットフォームが使用される。本システム100は、通信プラットフォームと統合され得る。たとえば、本システム100は、プログラム的にウェブブラウザを動作し、ウェブベースのテレビ会議サービスを使用するために、ウェブアプリケーションをテストするためのフレームワークを使用することができる。システム100は、いくつかの通信プラットフォームアカウントを作成し使用することができる。いくつかの例では、システム100は、呼の速度の抑制を回避するために、異なる通信プラットフォームアカウント間で自動的に交替することができる。

ダイヤラ106は、ボットが行う呼の開始または発信を容易にする。ダイヤラ106は、通信プラットフォーム102に通信可能に接続される。ダイヤラ106は、ダイヤラ106によって選択された特定の被呼者への電話呼を開始するために、通信プラットフォーム102に命令を提供する。たとえば、ダイヤラ106は、電話番号の数字に対応するオーディオトーンを再生することができる。呼が発信されると、システム100は、回線の他方の端にある人間の被呼者との会話を行うことができる。

ダイヤラ106は、特定の被呼者への呼を開始するための命令を受信することができる。たとえば、ダイヤラ106は、トリガモジュール110またはフローマネージャ132などのシステム100内の他のモジュールからの命令を含むデータを受信することができる。

トリガモジュール110は、トリガイベント、またはシステム100が特定の被呼者への呼を開始するべきであることを示す特定のイベントを検出する。トリガイベントは、あらかじめ定められたタイプのイベントであり得る。たとえば、システム100のユーザは、特定のタイプのトリガイベントを指定することができる。トリガイベントは、システム100のユーザによって実行される明示的なアクション、トリガモジュール110に提供されるデータの検出されたパターン、特定のイベントが発生してから経過したあらかじめ定められた時間期間、および様々な他のタイプのイベントを含むことができる。トリガイベントの検出に応答して、トリガモジュール110は、特定の被呼者への呼を開始するためにダイヤラ106に命令を提供するか、あるいは特定のワークフローのノードを選択するか、またはダイヤラ106に命令を提供するためにフローマネージャ132に命令を提供する。

サウンドシステム108は、オーディオを録音および再生するために使用される。いくつかの例では、(a)電話またはテレビ会議サービスからシステム100への着信オーディオ、(b)システム100から通信プラットフォームに戻る出力オーディオ、(c)aとbを組み合わせた混合ストリームの3つの仮想ストリームがセットアップされ、それらは呼全体を録音するために使用される。サウンドシステム108は、通信プラットフォーム102を通じて通信を実行するために、オーディオパッケージ112を使用する。

オーディオパッケージ112は、サウンドシステム108と通信するために使用される。いくつかの例では、本システム100は、オーディオパッケージ112を包み込み、着信オーディオパケットの連続ストリームを処理する、オーディオモジュールを含む。モジュールはまた、すべての着信パケットを録音し、事前録音されたオーディオファイルの再生を可能にする。本システム100は、様々なビット深度、サンプリング周波数、パケットサイズ等を使用する。

システム100は、ボットによって行われる着信および発信の会話を録音することができる。オーディオパッケージ112は、システム100がセッションレコーダ114を使用して特定のセッションまたは呼を録音することを可能にすることができる。いくつかの例では、セッションレコーダ114は、ボットのスピーチが生成されるときにそれを録音することによって、ボットによって行われた会話の一部を録音することができる。他の例では、セッションレコーダ114は、通信プラットフォーム102によって人間104に出力されるときにボットのスピーチを外部から録音することによって、ボットによって行われた会話の一部を録音することができる。セッションレコーダ114は、人間104の応答も録音することができる。

セッションレコーダ114は、録音されたセッションデータをセッションストレージ116に記憶する。録音されたセッションデータは、オーディオデータとして、またはオーディオデータを表す特徴データとして記憶され得る。たとえば、録音されたセッションデータは、セッションのオーディオデータの特定の特徴の値を記憶するベクトルとして記憶され得る。セッションストレージ116は、ローカルデータベース、遠隔サーバ、システム100内の物理メモリ、または様々な他のタイプのメモリのいずれかであり得る。

スピーチ終点検出器120は、ボットと回線の反対側の人間との間の会話を単純化する。会話を単純化するために、会話が個々の文章に分けられ、人間とボットの間で別々に切り替えられる。スピーチ終点検出器120は、オーディオパッケージ112から連続入力オーディオストリームを受信し、それを別々の文章に変換する役割を果たす。

スピーチ終点検出器120は、スピーチの終点を検出する。一実装形態では、スピーチ終点検出器120は、スピーチ待機と、無音待機との2つの状態で動作する。スピーチ終点検出器120は、以下のようにこれらの状態を順に交替させる:各オーディオパケットは、その二乗平均二乗偏差(RMSD)をあらかじめ定義されたしきい値と比較することによって検査される。RMSDがこのしきい値を下回っている場合、単一パケットは「無音」と見なされる。非無音パケットが受信されると、モジュールは「スピーチ待機」状態から「無音待機」状態に切り替わる。モジュールは、システム全体の状態に応じて、あらかじめ定義された時間期間持続する連続した無音パケットの期間が受信された後にのみ、切り替わって戻る。

いくつかの実装形態では、「サウンド待機」期間中に、スピーチ終点検出器120は、純粋な無音パケットを作成し(10個の実際のパケット当たり1つのパケットを作成)、それらをスピーチ-テキストモジュール126に送信する。作成されたパケットは、スピーチAPI128からの切断を回避することができる。「無音待機」の期間中、スピーチ終点検出器120は、あらかじめ定義された時間期間(ベースラインノイズ推定に有用)までの間ストリームから無音のパケットを送信し、次いで、すべてのオーディオパケットを送信する。

他の実装形態では、スピーチ終点検出器120は、機械学習、ニューラルネットワーク、または終点を見つけるためにイントネーションおよび言語コンテキストを観察するように訓練された何らかの形態の深層学習を使用する。

いくつかの例では、スピーチ終点検出器120は、オーディオ入力の特定のストリームをどのように構文解析するかを決定する際に、言われたこと、話者のイントネーションなどを考慮する。たとえば、スピーチ終点検出器120は、特定の人間の被呼者104が低い抑揚で文章を終了させる傾向を有すると決定することができ、スピーチ終点検出器120は、抑揚の低下が検出された場合に被呼者104によって話される文章の終わりを予測することができる。スピーチ終点検出器120は、時間フレーム内の信号対雑音比に基づいて、呼の間に動的にしきい値を調整することができる。

スピーチ-テキストモジュール126は、スピーチ終点検出器120によって解析されたオーディオデータを、ボットの次の応答を選択するために使用されるインテントのために構文解析され得るテキストに変換する。スピーチ-テキストモジュール126の出力は、スピーチオプションの順序付けられたリストであり、場合によっては、最良のオプションに対する信頼度が提供される。スピーチ認識プロセスは、音響モジュールと言語モジュールの2つの主要な構成要素を含む。音響モジュールの場合、システムは、彼らの電話機に直接話している人々の録音から訓練されたモデルを使用することができる。ニューラルネットワークは、モデルによって使用されてもよく、いくつかの例では、ニューラルネットワークの第1の層は、電話呼に存在するボコーダを説明するために再訓練されてもよい。ボコーダは、スピーチ入力の解析からサウンドを生成する音声コーデックである。ニューラルネットワークはまた、事業への呼と個人的な電話呼との間で異なるバックグラウンドノイズを説明するために再訓練され得る。言語モジュールは、システムの過去の経験に基づいて言語モジュールをバイアスするシステムを使用して構築され得る。いくつかの例では、バイアスが自動的に構成され得る。いくつかの例では、このバイアスは手動で設定される。いくつかの例では、言語バイアス構成は、業種(vertical)間で変更される。

スピーチ-テキストモジュール126は、会話の反対側の人が何を言うと予測されるかに基づいて言語モジュールをバイアスするために、呼のコンテキストを使用する。たとえば、システムのボットが、「火曜日は開店していますか?」と尋ねる。この質問に基づいて、会話の反対側の人は「いいえ、閉店しています」、または「はい、開店しています」など答えで応答する可能性が高い。ボットは、過去の呼に基づいて可能性のある応答を学習し、着信オーディオを理解するために予測を使用する。ボットは完全な文章の応答を予測できるが、ボットはまたフレーズを予測し得る。たとえば、ボットが「私たちは全部で7人います」と言った後、「あなたは7人と言いましたか?」というフレーズを予測し得る。ボットはまた、7と11の音が似ているので、「あなたは11人と言いましたか?」というフレーズを予測し得る。ボットはまた、「あなたは2人と言いましたか?」というような応答の可能性が低いと予想し得る。ボットは、その予測に基づいてフレーズごとに確率重みを割り当てることができる。

いくつかの実装形態では、スピーチ-テキストモジュール126は、オーディオデータをテキストに変換するためにスピーチAPI128を使用する。いくつかの例では、スピーチAPI128は、オーディオデータをテキストに変換するために機械学習を使用する。たとえば、スピーチAPI128は、オーディオデータを入力として受け入れるモデルを使用することができる。スピーチAPI128は、決定木、線形回帰モデル、ロジスティック回帰モデル、ニューラルネットワーク、分類器、サポートベクトルマシン、誘導論理プログラミング、モデルのアンサンブル(たとえば、バギング、ブースティング、ランダムフォレストなどの技法を使用する)、遺伝的アルゴリズム、ベイジアンネットワークなどの、様々なモデルのうちのいずれかを使用し得、深層学習、パーセプトロン、関連ルール、帰納的論理、クラスタリング、最大エントロピー分類、学習分類などの様々な手法を使用して訓練され得る。いくつかの例では、スピーチAPI128は教師付き学習を使用し得る。いくつかの例では、スピーチAPI128は教師なし学習を使用する。いくつかの例では、スピーチAPI128は、ネットワークを介してスピーチ-テキストモジュール126によってアクセスされ得る。たとえば、スピーチAPI128は、クラウドサーバ上の遠隔の第三者によって提供され得る。

ボットによる応答のための自然な機会を決定するために人が話していたコンテキストを決定するなどのダイアログの同期化に対処するために、システム100はインテントを識別することができる。インテントは、人間またはボットのいずれかによって述べられた、文章中の単一の意味論的意味の形式言語表現である。いくつかの実装形態では、システム100は、ボットが人間によって話された最新の文章に関連する応答を生成するために、受信した最後のインテントとボットの応答との間で人間から受信したあらゆるインテントを無視する。しかしながら、システム100は、将来の応答を知らせるために以前のインテントを使用することができる。たとえば、システムは、ANCIENTとして受信した最新のインテントよりも前に受信したインテントをマーク付けし、ANCIENTインテントを構文解析し、オフラインで評価するために記憶することができる。いくつかの例では、様々な他の形態の処理ロジックが使用され得る。

システム100の大部分は使用事例に依存しないが、システム100のいくつかの部分は、特定の使用事例、すなわちシステム業種のために手動で構成されるか、または完全にプログラムされる。業種は基本的にインテントのスキーマと事業ロジックコードとで構成されている。スキーマ内のインテントは、人間またはボットのいずれかによって述べられた、文章中の単一の意味論的意味の内部形式言語表現である。たとえば、営業時間抽出の業種では、「開店していますか{日付:明日}」ボットインテントと、対応する「閉店しています{日付範囲:九月}」の人間インテントとがある。人間からの着信オーディオがインテントに変換されるプロセスは、本明細書ではインテント解決と呼ばれる。反対のプロセス(ボットインテントをスピーチに変換する)は、インテント-スピーチと呼ばれる。スキーマは業種ごとに構成されるが、インテントを学習し分類するコードのほとんどは一般的なものであり、業種の間で使用される。いくつかの例では、システムの言語固有の部分のみが、インテント解決とインテント-スピーチの構成に存在する。

ロジックコードは、業種ごとにプログラムされ得(いくつかの共通コードを共有する)、着信された人間のインテントだけでなく、呼のコンテキスト(入力パラメータとそれまでに起きたこと)によって定義されるすべての可能な状況に対するボットの動作を決定する。一実装形態では、スピーチはテキストに変更され、次いで人間のインテントとして解釈される。人間のインテントは、ロボットのインテントを決定するために使用される。いくつかの業種ではボットが会話をリードし、他の事例ではボットはほとんど人間に反応する。たとえば、データ収集型の業種では、ボットは事業からいくつかの情報を抽出することを目指す。通常、ボットはすべての所望の情報が得られるまで一連の質問をしようとする。たとえば、ボットが目指す取引タイプの業種では、予約をすると、主に人間によって発せられる質問に答える(「あなたのお名前は何ですか?」...「それから、お電話番号は?」...)。そのような場合、人間が突然静かになった場合などにのみ、システムがリードする。プログラマは、変換が論理的に意味を成すように人間のインテントとロボットのインテントとの間のフローを設計することができる。いくつかの実装形態では、人間のインテントからロボットのインテントへの変換を変更または更新するために、非エンジニアが制御することが可能なフローのためのプロトコルが存在する。フローはまた、機械学習を使用して自動的に学習され得る。

別の実装形態では、入力された人間のインテント解決は隠れた層であり得、機械学習は出力されたロボットのインテントを入力テキストから直接学習するために使用され得る。人間のスピーチ入力がテキストに変更され得、次いで、このテキストからロボットのインテントが直接決定され得る。さらに別の実装形態では、システムは人間のスピーチから直接インテントを出力することができる。これらの設計の両方とも、コンテキストおよびそれぞれの入力に対応するロボットのインテントを学習するために機械学習を使用する。

テキスト-インテントモジュール130は、可能な着信インテントのスキーマ、そのようなインテントごとの例文、および言語バイアス構成を使用して構成されている。本質的に、テキスト-インテントモジュール130は、スピーチ認識プロセスにおける馴染みのないフレーズおよびエラーを考慮しながら、着信センテンスをあらかじめ定義された(または「未知」の)インテントのリストに「スナップ」する役割を果たす。たとえば、いくつかの実装形態では、テキスト-インテントモジュール130は、文章(スピーチ認識モジュールから受信された)「明日の朝11時から9時まで、ごめんなさい、9時30分まで開いています」が、知られている例「私たちは+(時間、時から)に開店し、+(時間、時まで)に閉店します、ごめんなさい」に類似していることを識別することができ、これは、インテント「私たちは時間=午前11時から、時間=9:30まで}開店しています」の例である。「時から」および「時まで」のようなフィールドは、インテントパラメータである。

テキスト-インテントモジュール130は、(1)注釈器と、(2)注釈付きテキスト-インテント分類器との2つの主要部分から構成され得る。いくつかの実装形態では、システムは、引数の分類を行う分類後段階を有する。たとえば、「月曜日から火曜日、ごめんなさい、水曜日は、閉店しています」というフレーズの場合、注釈部はテキストを「<日付:月曜日>から<日付:火曜日>、ごめんなさい、<日付:水曜日>は閉店しています"に書き換える。この例は、フレーズが応答テキスト内の注釈を指定する注釈器で書き換えられたことを示す。注釈付きテキスト-インテント分類は、注釈付きフレーズを、私たちは開店しています{日1:月曜日、日2:火曜日、日3:水曜日}に変化させる。分類後段階は、フレーズを:私たちは開店しています{日:月曜日から、日:水曜日まで、間違った日;火曜日}に書き換える。

システム100がスピーチオプションを受信するとすぐに、テキスト-インテントモジュール130を使用して、日付、時間、共通名などのためにそれぞれに注釈を付ける。これは、(1)論理モジュールのインテントパラメータを抽出することと(たとえば、「時間:午前10時」)、(2)以前に遭遇した文章との一致を単純に見つけるためにテキストを一般化することとの2つの目的のために行われる。テキスト-インテントモジュール130は、スピーチ-テキストモジュール126から出力を受信し、スピーチオプションのリストに注釈を付ける。次いで、テキスト-インテントモジュール130は、特定のワークフロー内の次のアクションを選択するためにフローマネージャ132によって使用されるインテントに最も可能性の高いオプションをマッピングするために、注釈を使用する。

呼の間の計算時間を短縮するために、システム100は、(現在の日時に対して)注釈を付けられるべき知られているテキストのライブラリを事前に構築することができる。たとえば、2015年9月1日火曜日に、「日付:(2015、9、2)」注釈の候補として、「明日」、「今週の水曜日」、「9月2日」などが記憶され得る。リアルタイムでは、システム100は、入力された文章の中の単語を順次反復し、(いくつかの正規化の後)注釈候補の最長一致を検索する。次いで、システム100は、テキストを注釈で置き換え、左から右へのすべての候補が注釈で置き換えられる編集された文字列を返す。たとえば、「午前7時に開店します」は「私たちは@(時間、午前7時)に開店します」で置き換えられる。

注釈器またはテキスト-インテントモジュール130はまた、収縮の役割を果たすことができる。たとえば、システム100は、「ええと...はい、4時、午後4時です」のような文章に遭遇する可能性がある。テキスト-インテントモジュール130は、「4時、午後4時」を単一の「@(時間、午後4時)」という注釈で置き換えることができる。さらに、テキスト-インテントモジュール130は、「私たちは10時、えーと、午後10時30分に閉店します」から、「私たちは@(時間、午後10時30分)に閉店する」などの、小さな時間修正を収縮し得る。

他の実装形態では、システムは、キュレーションされたデータに基づいてテキストに注釈を付ける方法を学習できる機械学習アルゴリズム、テキストに注釈を付けるために使用され得るプレフィックスツリー、または注釈を付けるために特別に導出され得るルールベースのパターンなどの、テキストに注釈を付けるための他の方法を使用し得る。

テキスト-インテントモジュール130は、ほとんどの呼の新しい文章を構文解析して注釈を付け、スピーチ認識は、しばしば話された単語の多くを歪める。システム100は、使用事例ごとに記憶された数千のインテントを有し、各文章を、文章のパラメータに基づいて文章に最も関連すると決定された記憶されたインテントからのインテントを有するものとして分類する。たとえば、システム100は、発呼者の名前を尋ねる質問を示唆する特定の文章中の単語を検出することに基づいて、特定の文章を、名前を尋ねるインテントを有するものとして分類することができる。いくつかの実装形態では、システム100は、文章のインテントを認識せず、その文章を未知のインテントを有するものとして分類することができる。

テキスト-インテントモジュール130は、分類を処理するために機械学習アルゴリズムを使用する。たとえば、システムは、条件付きランダムフィールドモジュールとロジスティック回帰モジュールとの組合せを使用し得る。一実装形態では、分類は文章レベルで行われ、すなわち、テキストの文字列がインテントのセットまたはインテントのリストに変換される。別の実装形態では、元の文字列内のすべてのトークンがインテントに分類され、インテント境界もまた分類される。たとえば、「私たちは、月曜日は7時に開店し、えーと...私たちは、火曜日は8時に開店します」という文章は、第1の実装形態において、GiveDailyHours+AskToWaitのインテントを含むものとして分類される。第2の実装形態では、部分文字列「月曜日は、私たちは7時に開店します」は、GiveDailyHoursインテントの境界として分類され、部分文字列「えーと...」は、AskToWait型の別のインテントとして分類され、部分文字列「私たちは、火曜日は8時に開店します」は、GiveDailyHours型の別のインテントとして分類される。

いくつかの実装形態では、テキスト-インテントモジュール130は、機械学習アルゴリズムを使用し得ず、代わりに、インテントごとに例のセットを使用し、次いで、各スピーチオプションとすべての例との間の1-最近傍(パターン認識アルゴリズム)を使用し、ここで、アルゴリズムの距離メトリックは、文章の単語の正規化された編集距離の変化(単語などの異なる2つの文字列が互いにどのように適合するかの方法)である。2つの個々の単語の間の距離はより複雑であり、音韻的距離の近似であることを目指している。いくつかの例では、意味論的距離は、注釈付きテキスト-インテントモジュール130によって決定され得る。

実際には、テキスト-インテントモジュール130はまた、クロススピーチオプション信号を使用することができる(たとえば、スピーチオプションのうちの1つにのみ存在する数字は悪い解釈である可能性が高い)。いくつかの例では、テキスト-インテントモジュール130は、システムコンテキストに基づいて注釈付きテキスト-インテントモジュールの結果を事前にバイアスする。最後に、テキスト-インテントモジュール130は、「ComplexOpeningHours」などの曖昧に定義されたインテントに対していくつかのカスタマイズされた抽出を有し、ここでシステムは営業時間の複雑なフレーズが与えられたことを識別することができるが、システムは正確にパラメータを抽出できなかった(たとえば、「...夕食は9時まで提供され、デザートはもう1時間長く注文でき、バーは2時まで開いておりますが、1時以降はお客様を受け付けません」など)。

いくつかの例では、分類に使用される例は、キュレーションされた過去の呼に基づいて自動的に推測され、また手動でも編集され得る。一般化プロセスは、テキストを注釈で置き換えることができ、不審なキュレーションを省略する。

いくつかの例では、人間は単一のインテントを話すのではなく、むしろ一連のインテントを話す。たとえば、「ヘアカットをご希望ですか?何時ですか?」。例示的なシステムは、所与のセンテンス内の任意の数のインテントをサポートする。いくつかの例では、注釈付きテキスト-インテントモジュールは、他のインテントのプレフィックスとして、具体的に正と負のインテントを決定する(たとえば、「いいえ、この日は閉店しております」=>否定+WeAreClosed)。いくつかの例では、注釈付きテキスト-インテントモジュールは、インテントの任意の連鎖をサポートする。

システムは、常識モジュール133と救済モジュール136とを含むフローマネージャ132を含む、組織ロジックの異なる機能を実行する複数のモジュールを含む。

フローマネージャ132は、各呼を追跡し、人間から受信した各インテント(または、長い無音)にどのように応答するかを決定する、業種ごとのカスタムコードを含むことができる。しかしながら、他の実装形態では、フローマネージャは、業種の間で一般的である。応答は、人間104に伝える合成インテントのリスト(ボットは無音状態を維持することも選択できる)であり、呼を終了するためのコマンドであることもある。フローマネージャ132はまた、呼の間に収集された任意の情報を含む、呼の結果を生成する役割を果たす。いくつかの例では、システム100は、人間によって最初に作成され、後で「子ども」ボットによって作成されるライブの呼に基づいて、各入力に反応する方法を学習する。システム100は、呼の間のあらゆる誤解を解消するために、できるだけ柔軟にロジックを保持する。

システム100は複数のフローを有し、その各々は、事業のために営業時間を決定すること、またはサロン予約のための予約をすることなど、特定のタイプのタスクに合わせて調整される。システム100は、異なるフロー間で共有される共通ライブラリを維持し、発信された呼の履歴からサブフローを抽出することができ、システムがタスクごとに新しい業種をジャンプスタートすることを可能にする。いくつかの例では、システム100は、手動で発信された呼に基づいて異なるタスクのフローを自動的に学習し得る。

人間は、会話の相手を混乱させることなしに、話すときにいくつかの重要な細部をスキップし得る。たとえば、人間は「私たちは10時から4時に開店しています」と言う場合がある。ボットは、事業が午前10時に開店するのか、または午後10時に開店するのか、および同様に、午後4時に閉店するのかまたは午後4時に閉店するのかを理解する必要がある。たとえば、事業がナイトクラブである場合、ボットは午後10時から午後4時までの時間であると仮定することが予想され得、事業がレストランの場合、ボットは午前10時～午後4時と仮定することなどが予想され得る。

フローマネージャ132は、受信されたスピーチ入力内のインテントを曖昧にする常識モジュール133を含む。いくつかの例では、フローマネージャ132は、たとえば、いくつかのデータセット(たとえば、ベースラインローカルデータベース)に関する統計から学習するモジュール、および手動でプログラムされるモジュールなどの、複数のタイプの常識モジュールを含む。第1のタイプのモジュールは、オプションのデータセット(たとえば、営業時間)を受け取り、各オプションおよびサブオプション(たとえば、「午前2am～午前4am」または「ちょうど午前2時?」)ごとのp値を計算する。第2のタイプのモジュールは、システムがデータセット内に存在する可能性のある「常識」の誤りをしないようにする、あらかじめ定義されたルールのセットを使用する。いくつかの変数を解釈するための複数の方法があるときはいつでも、フローマネージャ132は、最も可能性の高いオプションを決定するために2つのスコアを組み合わせることができる。いくつかの例では、フローマネージャ132は、どのオプションも十分な可能性がないと結論し、システム100は、人間がそれらの意味を明確にするように明示的に尋ねようとすることに頼る。

常識モジュール133は、最も可能性の高いオプションを選択するために、同様の被呼者からのデータを使用することができる。たとえば、フィラデルフィアのほとんどのバーが午後8時から午前2時まで営業している場合、常識モジュール133は、「私たちは10時から2時まで開店しています」という曖昧なフレーズのための最も可能性の高いオプションは、話し手が午後10時から午前2時までを意味すると決定することができる。いくつかの例では、常識モジュール133は、フローマネージャ132に対して、さらなる明確化が必要であることを示すことができる。たとえば、ミシガン州ジャクソンのほとんどの郵便局が午前10時から午後5時までの営業時間を有する場合、システム100が、被呼者が営業時間は通常の郵便局とは異なるしきい値量である「午後2時から午後6時まで」であると応答したと信じる場合、常識モジュール133はフローマネージャ132に明確な説明を求めるように指示し得る。

場合によっては、通常、高いバックグラウンドノイズ、例外的なシナリオ、強いアクセント、またはコード内のバグなどにより、呼の間に蓄積された緊張がある。緊張は、予期せぬインテントによって生じる可能性もある。たとえば、レストランに発呼すると、システムは、「それでは、プレゼンテーションをしたいですか?」または「申しあげておきますが、スーパーボウルを表示するテレビがありません」などの予期せぬ文章に遭遇することがある。システムは、以前は遭遇していなかったインテントを処理する必要がある。いずれかの当事者にとって問題のある状態を識別するために、ボットは呼の間に示されたストレスの量を定量化しようとする。救済モジュール136は、呼を監督するオペレータをまねて、手動の介入をいつ実装するかを選択することができる。

オペレータコントローラ134は、フローマネージャ132に通信可能に接続され、オペレータコントローラ134は、人間のオペレータがフローマネージャ132に直接命令を提供することを可能にする。いくつかの例では、呼が処理されるために人間のオペレータに転送されると、オペレータコントローラ134は、フローマネージャ132を保持パターンに置くか、フローマネージャ132を一時停止またはシャットダウンする。

フローマネージャ132が、テキスト-インテントモジュール130から決定されたインテントに基づいて特定のワークフロー内の次のノードを選択すると、フローマネージャ132は、インテント-テキストモジュール124に命令を提供する。フローマネージャ132によって提供される命令は、通信プラットフォーム102を通じて被呼者に伝達される次のインテントを含む。インテント-テキストモジュール124はまた、スピーチ合成のためのマークアップキューを生成し、たとえば、単語のうちのいくつかの異なる強調または韻律を定義する。インテント-テキストモジュール124は、インテントから新しいテキストを生成するために、手動で定義されたルールまたは強化学習を使用することができる。

インテント-テキストモジュール124の出力は、通信プラットフォーム102において出力するためにオーディオデータに変換されるテキストである。テキストは、テキスト-スピーチモジュール118によってオーディオに変換され、テキスト-スピーチモジュール118は、以前に記憶されたテキスト-スピーチ出力および読取り値122を使用する。テキスト-スピーチモジュール118は、記憶された出力/読取り値122から以前に記憶された出力を選択することができる。いくつかの実装形態では、システムは、呼の間にテキスト-スピーチシンセサイザを使用する。たとえば、ボットが提供するためにフローマネージャ132によって選択された共通の応答が「素晴らしい、助けてくれてありがとう!」である場合、テキスト-スピーチモジュール118は、実行時に出力を生成することなしに、以前に生成されたテキスト-スピーチ出力を選択することができる。いくつかの例では、テキスト-スピーチモジュール118は、スピーチAPI128と同様に、ネットワーク接続を通じてアクセスされる第三者APIを使用する。

上述のように、ある例では、ユーザは、ユーザに提供された検索(たとえば、ウェブ検索)結果と対話することによってシステム100のタスクを開始し得る。たとえば、ユーザは「ミシュランの星付きレストランで、今夜2人用のテーブルを予約する」と検索し得る。タスクマネージャモジュール140は、タスクを受信し、タスク情報をタスク情報ストレージ150に記憶し得る。次いで、タスクマネージャモジュール140は、いつタスクをスケジューリングし、トリガリングイベントを設定するかを決定し得る。たとえば、ミシュランの星付きレストランが開店する前にユーザがテーブルを予約することを要求した場合、タスクマネージャモジュール140は、レストランがいつ開くかを決定し、その時間のトリガリングイベントを設定し得る。タスクマネージャモジュール140が、トリガリングイベントのために処理する際に遅延があることを知っている場合、タスクマネージャモジュール140は、視覚的表示、オーディオ表示、または何らかの他の表示を提供することによって、遅延をユーザに警告し得る。いくつかの実装形態では、タスクマネージャモジュール140は、タスクを完了するためにかかる時間、タスクが開始するようにスケジューリングされる時を提供してもよく、タスクが遅延される理由に関するさらなる情報を提供してもよい。

トリガモジュール110は、特定のトリガイベント(この例では、レストランの開店時間)が発生したことを検出し得、ダイヤラ106に呼を発信するように指示する。いくつかの例では、システム100は、発呼するレストランを選択するためのオプションをユーザに提示することができる。他の例では、システム100は、一連の特性に基づいて選択された特定のレストランに自動的に呼を発信することができる。ユーザは、特定のタスクの呼を発信するためのデフォルト設定を定義することができる。たとえば、ユーザは、システム100が発呼するためにユーザの現在地に最も近いレストランを選択するべきであること、またはシステム100が発呼するために最も高評価のレストランを選択するべきであることを指定することができる。

いくつかの例では、システム100は、ユーザがタスクに対する支援の要求をシステムに提供するユーザインターフェースを含むメッセージングまたはチャットアプリケーションなどの通信アプリケーションを含むか、その一部を形成するか、それと通信するように構成される。たとえば、ユーザは、メッセージングアプリケーションを使用して、「ワイヤシティは20 AWGワイヤを赤色にしていますか?」など、要求で番号をテキスト入力することが可能であり得る。システムは、テキストメッセージを受信し、トリガイベントが発生したと決定するために要求を構文解析し、適切なアクションを実行するために呼を開始し得る。たとえば、現時点で20ゲージの赤いワイヤが在庫されているかどうか調べるために、システムは最寄りのワイヤシティに呼を発信し得る。

同様に、いくつかの例では、システム100は、それ自体が様々なサービスまたはタスクに対してユーザを支援するためのソフトウェアエージェントの集合である仮想アシスタントシステムの一部を含むか、その一部を形成するか、それと通信するように構成される。たとえば、ユーザは仮想アシスタントに(音声またはテキスト入力によって)「私のドライクリーニングは準備完了ですか?」と入力し得る。仮想アシスタントは、この入力を処理して、事業との通信がクエリを満たすために必要であると決定し得、それに従って、インテントを識別し、呼を発信し、適切なワークフローを実行するためにシステムと通信する。

特定の例では、システム100は、それぞれ複数の人間との複数のダイアログを通じてタスクを自律的に実行し、ダイアログの個々のまたは累積結果を収集し、解析し、それに対してアクションを起こし、および/または提示する。たとえば、システム100は、指定されたエリア内のいくつかのレストランについて、最も混雑する時間がいつかに関してデータを収集するためにシステム100にタスクが割り当てられる場合、システム100は、自律的に各レストランに呼を発信し、データを解析して結果を提供するために、一定の時間期間に何人の顧客が座っているか尋ねることができる。

図2Aは、ユーザによって割り当てられたタスクを完了するための例示的なプロセス200を示す。簡潔に言うと、プロセス200は、それぞれがインテントによってリンクされた、あらかじめ定義されたワークフローのセットの初期ノードに会話をマッピングするステップ(202)と、ワークフローの現在のノードに基づいて発信メッセージを選択するステップ(204)と、人間のユーザから応答を受信するステップ(206)と、あらかじめ定義されたワークフロー内のインテントに応答をマッピングするステップ(208)と、インテントに基づいてワークフロー内の現在のノードとして次のノードを選択するステップ(210)と、あらかじめ定義されたワークフロー内のリンクされたノードのセットのエンドノードに到達するまで、204～210を繰り返すステップとを含み得る。プロセス200は、システム100などの呼禁止システムによって実行され得る。

プロセス200は、それぞれがインテントによってリンクされた、あらかじめ定義されたワークフローのセットの初期ノードに会話をマッピングするステップ(202)を含み得る。たとえば、図1に関して上述したフローマネージャ132は、それぞれがインテントによってリンクされたあらかじめ定義されたワークフローのセットの初期ノードに会話をマッピングすることができる。いくつかの例では、システム100と人間の被呼者との間の会話は、ユーザによって開始され得る。いくつかの例では、会話は、あらかじめ定義されたワークフローのセットのノードにマッピングするインテントを含む。たとえば、システム100は、実行されるべきアクションを有するあらかじめ定義されたワークフローのセットを記憶し得る。いくつかの例では、システムは、識別されたインテントに基づいてあらかじめ定義されたワークフローを選択し得る。ワークフローの各々は、インテントによってリンクされ得る。いくつかの例では、システム100は、会話中にユーザによって指定された事業に電話呼を発信し得る。いくつかの例では、事業は、レストラン、サロン、医院などであり得る。いくつかの例では、システムは、人間が応答した場合にのみ呼が正常に発信されたと見なし、誰も応答しない場合、またはシステムが電話ツリーに向けられ、電話ツリーを正常にナビゲートしない場合、システムは、呼が正常に発信されなかったと決定し得る。

プロセス200は、ワークフローの現在のノードに基づいて発信メッセージを選択するステップ(204)を含み得る。たとえば、フローマネージャ132は、ワークフローの現在のノードが、ユーザがそのような予約をスケジューリングしたいと示している場合、「こんにちは、私はヘアカットの予約をスケジューリングしたいです」と言うメッセージを選択し得る。

プロセス200は、人間のユーザから応答を受信するステップ(206)を含み得る。たとえば、システム100は、「かしこまりました、どのような日時にこの予約をスケジューリングしたいですか?」などの、電話呼の他方の端の人間の被呼者からの応答を受信し得る。いくつかの例では、システム100は、(たとえば、セッションレコーダ114を使用して)応答を録音し得る。いくつかの例では、システム100は、人間のオペレータに対する応答を再生し得る。いくつかの例では、人間のオペレータが(たとえば、オペレータコントローラ134を使用して)呼を監視している場合がある。

プロセス200は、あらかじめ定義されたワークフロー内のインテントに応答をマッピングするステップ(208)を含み得る。フローマネージャ132は、あらかじめ定義されたワークフロー内のインテントへの応答をマッピングすることができる。いくつかの例では、システムは、識別されたインテントと、あらかじめ定義されたワークフローのセットがそれぞれリンクされているインテントとを比較する。

プロセス200は、インテントに基づいてワークフロー内の現在のノードとして次のノードを選択するステップ(210)を含み得る。たとえば、フローマネージャ132は、インテントを使用して、ワークフローの次のノードを決定し得る。次いで、フローマネージャ132は、現在のノードとして次のノードを指定し得る。プロセス200は、エンドノードに到達するまで204～210を繰り返すステップを含み得る。したがって、エンドノードに到達するまで次の発信メッセージを決定するために、指定された現在のノードが、204～210の各繰り返されるサイクルにおいて使用される。

図2Bは、ユーザによって割り当てられたタスクを完了するための例示的なプロセス250を示す。簡潔に言うと、プロセス250は、ユーザからインテントに関連付けられるタスクを受信するステップ(252)と、インテントを識別するステップ(254)と、インテントによってリンクされたあらかじめ定義されたワークフローのセットの中からインテントに基づいてあらかじめ定義されたワークフローを選択するステップ(256)と、あらかじめ定義されたワークフローに従うステップ(258)と、タスクを完了するステップ(260)とを含み得る。プロセス250は、システム100などの呼開始システムによって実行され得る。

プロセス250は、ユーザからインテントに関連付けられるタスクを受信するステップ(252)を含み得る。たとえば、ユーザは、ユーザインターフェースを通じて「ヘアカットの予約をする」という検索クエリをシステム100に提出し得る。いくつかの例では、検索クエリはトリガモジュール110によって受信され得、トリガモジュール110は、クエリが、特定の被呼者に呼が発信されるべきであることを示すトリガイベントであることを検出する。タスクは予約することであり得、インテントはヘアカットをすることであり得る。いくつかの例では、タスクまたはインテントは明示的に入力されない場合がある。いくつかの例では、ユーザは、検索クエリを入力することなしに、タスクおよびインテントを提出し得る。インテントに関連付けられるタスクは、タスクを支援するためにシステムによって受信され得る。

プロセス250は、インテントを識別するステップ(254)を含み得る。たとえば、システム100は、インテントに関連付けられる受信タスクを処理し、インテントを識別し得る。いくつかの例では、インテントは明示的に入力され、タスクから分離し得る。いくつかの例では、インテントはタスクの特性であり得る。いくつかの例では、入力はスピーチ入力として提供され、スピーチ終点検出器120は、スピーチ-テキストモジュール126に構文解析された出力を提供し、スピーチ-テキストモジュール126は、テキストをテキスト-インテントモジュール130に送信し、テキスト-インテントモジュール130がインテントを識別する。

プロセス250は、インテントによってリンクされたあらかじめ定義されたワークフローのセットの中からインテントに基づいてあらかじめ定義されたワークフローを選択するステップ(256)を含み得る。たとえば、システム100は、実行されるべきアクションを有するあらかじめ定義されたワークフローのセットを記憶し得る。いくつかの例では、システムは、識別されたインテント(254)に基づいてあらかじめ定義されたワークフローを選択し得る。たとえば、フローマネージャ132は、テキスト-インテントモジュール130によって識別されたインテント(254)に基づいて、あらかじめ定義されたワークフローを選択することができる。いくつかの例では、システムは、識別されたインテントと、あらかじめ定義されたワークフローのセットがそれぞれリンクされているインテントとを比較する。

プロセス250は、あらかじめ定義されたワークフローに従うステップ(258)を含み得る。たとえば、システム100は、あらかじめ定義されたワークフローに含まれる命令に従うモジュールを含み得る。いくつかの例では、システム100のボットは、あらかじめ定義されたワークフローに含まれる命令に従うことができる。たとえば、命令は、事業の人間の代表者に呼を発信して会話するために、トリガモジュール110に制御データをダイヤラ106に提供するように命令することを含み得る。

プロセス250は、タスクを完了するステップ(260)を含み得る。たとえば、システム100は、請求書の支払い、夕食の予約の変更など、割り当てられたタスク全体を完了し得る。いくつかの例では、システム100は、呼を発信したり、電話ツリーをナビゲートしたりするなどのタスクの一部を、それが人間に到達するまで完了し得る。いくつかの例では、システム100は、ユーザによって指定されたタスクの一部を完了し得る。たとえば、ユーザは、システムがすべてのタスクを完了し、検証のためにユーザに呼を転送することを指定し得る。

多くの使用事例は、事業から何かを購入したいが、取引に必要な複雑さ、メニューのナビゲーション、言語の問題、参照知識などのために購入に問題があるユーザを含む場合がある。取引クエリは、取引を完了するために、システムが成功するのを助けることを望むベンダ側の人間からの支援を蓄積し得る。いくつかの例では、システムは、開発途上国、配管や屋根葺きなどの低技術およびサービス産業に重要な支援を提供する。ワークフローは、人間のユーザがそのような取引を正常にナビゲートするのを支援するだけでなく、ベンダ側のシステムがユーザを支援することを促すためにも使用され得る。システムは、様々な使用事例に対応できるようにスケーラビリティがある。たとえば、レストラン予約アプリケーションは世界中の数千の事業と提携し得、本明細書に開示されたシステムは、必要な規模でレストラン予約を発行するように構成され得る。

図3は、システムによって実行されるプロセスの例示的なワークフロー300を示す。この特定の例では、システム100のボットによって単純なブール質問が尋ねられる。システムはより複雑性がより高い問題に応答することができ、説明の簡略化のためにワークフロー300が提示されることが理解される。

フロー300は、ボットによって提起された例示的な質問を示す。「明日は開店していますか?」人間によって提供される可能な応答がレイアウトされ、人間の応答の各々に対するボットの応答が提供される。人間の応答に応じて、システム100が導かれ得るフロー300のいくつかの段階がある。二重枠で示された段階は、システム100がフロー300を出る最終段階である。たとえば、ボットによって提起されたバイナリ質問に応答して、人間の被呼者は、明日事業が開店していることを確認することができ、フロー300を終了する。人間の被呼者は、明日は事業が開店していないことを確認し、フロー300を終了する。人間の被呼者はボットに保持を依頼し、ボットをフロー300とは別の保持フローに送り、フロー300を終了する。

ユーザへのアクセスを容易にし、システム100の伝播を促進するために、システム100は、既存のアプリケーション、プログラム、およびサービスと統合される。たとえば、システム100は、ユーザのモバイルデバイス上の既存の検索エンジンまたはアプリケーションと統合され得る。他のサービスまたは業種との統合により、ユーザはタスクが完了されるよう要求を容易に提出できるようになる。たとえば、システム100は、検索エンジン知識グラフと統合され得る。

いくつかの使用事例では、人間のリアルタイム判断が自動化され得る。たとえば、システム100は、ユーザが理髪店の予約に10分遅れて走っていることを自動的に検出し、ユーザの到着前に理髪店に警告する。

システム100は、行われている会話のコンテキスト、または知識データベース内に記憶された特定の被呼者に関するデータに基づいて、ボットの特定のパラメータを選択することができる。たとえば、システム100は、被呼者のアクセント、位置、および他のコンテキストデータに基づいて、被呼者は現在呼が行われている言語とは異なる言語の方がより快適であると決定することができる。次いで、システム100は、被呼者がより快適であるとボットが考える言語に切り替えることができ、新しい言語で呼を行うことの方を好むかどうか被呼者に尋ねる。人間の被呼者の特定のスピーチ特性を反映することによって、システム100は、正常な呼の可能性を高める。システム100は、呼の間に蓄積された緊張を低減するために、スピーチ特性による会話内の潜在的な摩擦源を低減する。これらの特性は、使用される単語の平均的な長さ、文章構造の複雑さ、フレーズ間の休止の長さ、被呼者が最も快適に話す言語、および様々な他のスピーチ特性を含むことができる。

図4は、システム100の呼トリガリングモジュールのブロック図400である。トリガモジュール110は、ダイヤラ106に通信可能に接続され、トリガイベントを検出することに基づいて、特定の被呼者または被呼者のセットへの呼を開始するようにダイヤラ106に命令を提供する。いくつかの例では、トリガモジュール110は、フローマネージャ132が特定のワークフローのノードを選択するか、またはダイヤラ106に命令を提供するために使用するトリガイベントデータを提供するために、フローマネージャ132と通信することができる。

トリガモジュール110は、不一致検出器402、第三者API404、傾向検出器406、およびイベント識別子408を含む、様々なモジュールから入力を受信する。トリガモジュール110はまた、フローマネージャ132から入力を受信することができる。いくつかの例では、モジュール402～408の各々は、システム100と一体化している。他の例では、モジュール402～408のうちの1つまたは複数は、システム100から離れており、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、インターネット、またはそれらの組合せなどのネットワークを介してトリガモジュール110に接続される。ネットワークは、モジュール402～408のうちの1つまたは複数をトリガモジュールに接続することができ、システム100の構成要素間(たとえば、スピーチAPI128とスピーチ-テキストモジュール126との間)の通信を容易にすることができる。

不一致検出器402は、複数の異なるソースからデータを受信し、第1のデータソースからのデータ値と第2のソースからの対応するデータ値との不一致を検出する。たとえば、不一致検出器402は、診療所の診療時間を示すデータを受信し、診療所のウェブサイトに掲載されている診療所の診療時間が診療所の外に掲載された診療時間と異なることを検出することができる。不一致検出器402は、競合の原因、不一致が検出されたデータ値のタイプ、競合しているデータ値、および様々な他の特性を示すデータをトリガモジュール110に提供することができる。いくつかの例では、不一致検出器402は、特定の被呼者への呼を開始するための命令をトリガモジュール110に提供する。他の例では、トリガモジュール110は、不一致検出器402から受信したデータに基づいて、コンタクトする特定の被呼者、および特定の被呼者から収集されるべきデータのフィールドを決定する。

トリガモジュール110は、不一致検出器402によって提供されるデータに基づいてトリガイベントを検出することができる。トリガイベントは、相違を示すユーザ入力を受信することを含むことができる。たとえば、トリガモジュール110は、ユーザインターフェース410を通じてユーザ入力を受信することができる。ユーザインターフェース410は、別個のアプリケーションまたはプログラムのためのインターフェースであり得る。たとえば、ユーザインターフェース410は、検索エンジンアプリケーションまたはナビゲーションアプリケーションのためのグラフィカルユーザインターフェースであり得る。

いくつかの実装形態では、ユーザインターフェース410は、ユーザに情報を提供するよう促すことができる。たとえば、店舗の広告されている閉店時間後に店舗にいるとユーザが検出された場合、システムは、店舗がまだ開いているかどうかをユーザに尋ねるか、時間を入力するようにユーザに求めることができる。ユーザは、ユーザインターフェース410を通じて要求されたデータを入力することができ、不一致検出器402は、ユーザインターフェース410を通じて入力されたデータと、知識ベース412などの第2のソースからの対応するデータとの間に相違があるかどうかを決定することができる。知識ベース412は、遠隔ストレージデバイス、ローカルサーバ、または様々な他のタイプのストレージ媒体などのストレージ媒体であり得る。不一致検出器402は、ユーザが通常の営業時間外にあらかじめ定められた時間量(たとえば20分超、特に遅い顧客のために、店は数分余分に開いたままにしておくことがあるため)店舗にいるかどうかを決定することができる。

別の例示的な状況では、不一致検出器402は、組織のウェブサイトに関する情報が古くなったと決定することができる。たとえば、不一致検出器402は、知識データベース412からのデータに基づいて、バス釣りクラブのウェブサイトが毎月第1水曜日に月例会があることを示しているが、クラブのより活発なソーシャルメディアのプロファイルはすべて、月例会が毎月第2火曜日に行われることを示していることを検出することができる。次いで、不一致検出器402は、この検出された不一致を示すデータをトリガモジュール110に出力することができる。

トリガイベントは、特定のデータのセットがあらかじめ定められた時間量にわたって更新されていないと決定することを含むことができる。たとえば、システム100のユーザは、発生した任意の他のトリガイベントに関係なく、データがリフレッシュされるべき時間量を指定することができる。不一致検出器は、特定のデータ値についての最後に更新されたタイムスタンプを比較し、タイムスタンプに基づいて、あらかじめ定められた時間量が経過したかどうかを決定することができる。タイムスタンプおよびデータ値自体を含む特定のデータフィールドの特性は、知識データベース412に記憶され得る。タイマ414は、経過した時間量を更新するために知識データベース412にデータを提供することができる。不一致検出器402は、タイマ414によって提供されるタイミングデータに基づいて、あらかじめ定められた時間期間が経過したと決定することができる。

たとえば、不一致検出器402は、知識データベース412からのデータに基づいて、ニューヨーク州イサカの小規模喫茶店の営業時間が3ヶ月間にわたって更新されていないことを決定することができる。次いで、不一致検出器402は、検出されたイベントを示す出力データをトリガモジュール110に提供することができる。

トリガイベントは、1人または複数のユーザから呼を開始する要求を受信することを含むことができる。たとえば、トリガモジュール110は、第三者API404を通じてユーザからの要求の受信を検出することができる。第三者API404は、ユーザインターフェース416などのユーザインターフェースに通信可能に接続され、これを通じて、ユーザは呼を開始する要求を示す入力を提供することができる。たとえば、ユーザインターフェース416は、呼キャンペーンがスケジューリングされて実行されることをユーザが要求することができるアプリケーションのためのグラフィカルユーザインターフェースであり得る。ユーザは、特定の被呼者または被呼者のセット、および抽出のために要求された特定のデータを示すデータを提供することができる。たとえば、ユーザは、家畜用品を販売するバージニア州の各ハードウェア店舗への呼キャンペーンが実施され、ハードウェア店舗が幼雛飼料を提供するかどうかを尋ねられることを要求することができる(たとえば、物資を運ぶ場所のインデックスが後の検索のために利用可能となるように)。

呼の間、被呼者は、システム100が被呼者にコールバックするための異なる時間をスケジューリングすることができる。たとえば、レストランのメニューに何らかの変更が加えられたかどうかについて尋ねられると、人間の被呼者は、システム100に、新しいメニューを見るチャンスを得た後、さらなるアクションのために、1時間後または翌日にコールバックするように頼むことができる。次いで、システム100は、要求された時間の呼をスケジューリングすることができる。いくつかの例では、トリガモジュール110は、将来のトリガイベントをスケジューリングすることができる。他の例では、フローマネージャ132は、呼を開始するためにダイヤラ106によって実行されるべきインテントまたは呼イベントをスケジューリングすることができる。

トリガイベントは、知識データベース内の記憶されたデータ、またはリアルタイムで提供されるデータにおいて検出された、傾向やパターンを含むことができる。たとえば、検索エンジン418から受信した検索データにおいて検出された傾向は、トリガイベントであり得る。検索エンジン418は、ユーザから検索要求を受信し、その検索要求を示すデータを傾向検出器406に提供することができる。傾向検出器406は、受信したデータを解析し、受信したデータにおける傾向を検出する。たとえば、ノースカロライナ州アシュビルにあるキューバ料理レストランの検索が過去1ヶ月に500%増加した場合、傾向検出器406は検索の増加を検出し、傾向を示すデータをトリガモジュール110に提供することができる。

傾向検出器406は、識別された傾向に基づいて、特定の被呼者または被呼者のセットを示すデータをトリガモジュール110に出力することができる。いくつかの実装形態では、傾向検出器406は、検出された傾向を示すデータを提供し、トリガモジュール110は、識別された傾向に基づいて特定の被呼者または被呼者のセットを決定する。たとえば、傾向検出器406は、「トルネードリンカーン、ネブラスカ州」の検索が40%増加したことを決定し、検索のキーワードをトリガモジュール110に提供することができる。次いで、トリガモジュール110は、(たとえば、検索エンジンのユーザによるインデックス付け、および後の検索のために)各店舗にどれくらいの必需品の在庫があるか、およびそれらの店舗の営業時間を確認するために、防災用品を提供するすべての店舗に呼が発信されるべきであると決定することができる。

トリガイベントは、事業、組織、個人などの通常の運営に影響を与えると識別された、興味のある特定のイベントを含むことができる。イベント識別子408は、第三者データベース420およびイベントデータベース422を含む、様々な第三者ソースからデータを受信する。イベント識別子408は、ローカルメモリデバイスまたはリアルタイムデータストリームなどの他のソースからデータを受信することができる。イベント識別子408は、データベース420および422から特定のイベントを識別し、識別されたイベントを示すデータをトリガモジュール110に出力する。いくつかの例では、トリガモジュール110は、イベント識別子408によって提供されるデータに基づいて、特定の被呼者または被呼者のセット、および呼の間に要求されるデータを選択する。

事業、組織、個人の運営に影響を及ぼす可能性がある特定のイベントは、極端な気象条件、連邦祝日、宗教的祝日、スポーツイベント、および様々な他の出来事を含む。

第三者データベース420は、気象サービス、政府アラートなどを含む、様々な第三者データソースからのデータをイベント識別子408に提供する。たとえば、第三者データベース420は、嵐警報をイベント識別子408に提供することができる。次いで、イベント識別子408は、冬の嵐がミネソタ州ミネアポリスの北東の角に近づいていることを決定することができ、利用可能な発電機の現在の在庫を決定するためにミネアポリスの北東の角におけるハードウェア店舗に呼が発信されるべきであると決定することができる。

イベントデータベース422は、様々なデータソースからのデータをイベント識別子408に提供し、具体的には、知られているイベントを示すデータを含む。たとえば、イベントデータベース422は、連邦祝日および州の祝日、宗教的祝日、パレード、スポーツイベント、展覧会初日、高官の訪問、および様々な他のイベントを示すデータを提供することができる。

たとえば、特定の都市がスーパーボウルをホストしている場合、イベントデータベース422は、イベント識別子408にデータを提供することができ、イベント識別子408はイベントを示すデータをトリガモジュール110に提供する。トリガモジュール110は、現在のスーパーボウルに関する知られている情報、および過去のスーパーボウルに関する記憶された情報に基づいて、空き状況と価格を確認するために、エリア内のすべてのホテルに呼が発信されるべきであると決定することができる。トリガモジュール110はまた、スーパーボウルに参加しているチームごとのジャージの可用性を決定するために、スポーツ用品店に呼が発信されるべきであると決定することができる。そのような状況では、トリガモジュール110が要求できる事業、組織、個人の運営に影響を及ぼす他の情報は、オフィスビルや学校の閉鎖、公共交通機関のスケジュールの変更、特別レストランの提供、または様々な他の情報を含む。

システム100の様々なモジュールのうちの1つまたは複数は、イベント識別子408から受信したイベント情報に基づいて、推定されるトリガイベントまたは要求する情報を決定することができる。たとえば、南米料理レストラン、具体的にはメキシコ料理レストランのDia de Muertosの場合、お祝いのために特別なメニューまたは営業時間がある場合がある。そのような例では、トリガモジュール110は、南米料理レストランに発呼して、その日の営業時間およびメニューを更新するように、ダイヤラ106に命令を提供することができる。

いくつかの実装形態では、トリガイベントは、システム100自体によって発信された呼から検出され得る。フローマネージャ132は、システム100によって行われる会話の一部に基づいて、会話中に呼が発信されるべきであることを示唆するインテントが表現されたことを決定することができる。たとえば、人間の被呼者が「はい、毎週木曜日は、私たちはまだ午後8時まで開いていますが、次週は夏期のスケジュールに切り替わり、午後9時30分まで開いています」と言う場合、フローマネージャ132は、データフィールドに関するさらなる情報を提供するインテントを識別することができる。

いくつかの実装形態では、トリガイベントは、以前に発信された呼から不満足な結果を受信することを含むことができる。たとえば、事業が独立記念日の祝日に特別な祝日営業時間を有するかどうかを決定するためにボットが事業に呼を発信し、事業の人間の代表者によって提供された回答の真実性に少なくともしきい値量の信頼度がない場合、システム100は、特別な祝日営業時間が予定されているかどうかを決定するために、7月1日などの別の特定の日または時間に呼をスケジューリングすることができる。そのような例では、トリガモジュール110は、アクションをスケジューリングするために、トリガイベントをスケジューリングするか、フローマネージャ132に情報を提供することができる。いくつかの例では、フローマネージャ132は、ダイヤラ106への命令の送信をスケジューリングすることによって、コールバックの開始をスケジューリングする。

システム100は、フローマネージャ132が特定のワークフローのノードを知的にスケジューリングおよび選択することを可能にする常識モジュール133を有する。たとえば、上記の状況において、呼の間に要求される情報の有用性の期限がある場合、常識モジュール133はまた、呼をスケジューリングする時、および要求する情報を決定することができる。いくつかの例では、常識モジュール133は、図1において説明されたように、フローマネージャ132の構成要素である。他の例では、常識モジュール133は、トリガモジュール110の構成要素であり、呼が開始されるべきかどうかについてトリガモジュール110が知的な決定をするのを容易にする。

図5は、電話呼を開始するためのプロセス500の一例を示す。簡潔に言うと、プロセス500は、呼を発信し、呼の間に呼開始システムのボットと人間の被呼者との間で会話を行うための呼開始システムの呼トリガリングモジュールによって、第1のイベントを示すデータを受信するステップ(502)と、呼トリガリングモジュールによって、および第1のイベントを示すデータを使用することによって、第1のイベントが、電話呼を開始することで開始する呼開始システムのワークフローをトリガするトリガイベントであると決定するステップ(504)と、決定されたトリガイベントに基づいて、特定のワークフローを選択するステップ(506)と、選択に応答して、特定のワークフローによって指定された被呼者に電話呼を開始するステップ(508)とを含み得る。

プロセス500は、呼を発信し、呼の間に呼開始システムのボットと人間の被呼者との間で会話を行うための呼開始システムの呼トリガリングモジュールによって、第1のイベントを示すデータを受信するステップ(502)を含み得る。たとえば、トリガモジュール110は、不一致検出器402から、店舗のウェブサイトに掲載されたSally's Sloon of Sweetsの営業時間と、その事業に関連する検索インデックスに記憶された営業時間との間の相違を示すデータを受信することができる。

プロセス500は、呼トリガリングモジュールによって、および第1のイベントを示すデータを使用することによって、第1のイベントが、電話呼を開始することで開始する呼開始システムのワークフローをトリガするトリガイベントであると決定するステップ(504)を含み得る。いくつかの例では、決定されたトリガイベントは、第1のデータソースに関連付けられる値と、第2のデータソースに関連付けられる対応する値との不一致である。たとえば、トリガモジュール110は、不一致が、Sally's Saloonの実際の営業時間が何であるかを決定するためにワークフローをトリガするトリガイベントであると決定するために、不一致検出器402から検出された不一致を使用することができる。

いくつかの例では、第1のイベントを示すデータがユーザによって提供される。たとえば、ユーザは、Sally's Saloonのウェブサイトに掲載された営業時間と、Sally's Saloonの店頭に掲示された営業時間との間に相違があると報告することができる。

いくつかの例では、決定されたトリガイベントはユーザ要求である。たとえば、ユーザは、特定の被呼者または特定の被呼者のセットへの呼のスケジューリングおよび実行を要求するために、ユーザインターフェース416などのユーザインターフェースを通じて、第三者API404などの第三者APIに入力を提供することができる。

いくつかの例では、決定されたトリガイベントは、気象イベント、スポーツイベント、娯楽イベント、または季節イベントのうちの1つである特定のタイプのイベントである。たとえば、イベント識別子408は、マサチューセッツ州ボストンでヘッドオブチャールズレガッタが行われていると決定することができ、トリガモジュール110にイベントデータを提供することができる。次いで、トリガモジュール110は、レガッタがトリガイベントであると決定することができる。

いくつかの例では、決定されたトリガイベントは、検索エンジンに提出された検索要求において検出された傾向である。たとえば、傾向検出器406は、検索エンジン418から検索エンジンデータを受信し、スペイン料理のタパスレストランが話題になっていると決定することができる。傾向検出器406は、傾向を示すデータをトリガモジュール110に提供することができ、トリガモジュール110は、傾向がトリガイベントであると決定することができる。

いくつかの例では、決定されたトリガイベントは、あらかじめ定められた時間期間の経過である。たとえば、不一致検出器402は、タイマ414からの知識データベース412内のデータに基づいて、ニューヨーク州マンハッタンのキューバ料理レストランのメニューが4ヶ月間にわたって更新されていないと決定することができる。不一致検出器402は、タイミングデータをトリガモジュール110に提供することができ、トリガモジュール110は、マンハッタンのキューバ料理レストランのメニューデータを更新しない4ヶ月の経過がトリガイベントであると決定することができる。次いで、トリガモジュール110は、マンハッタンのキューバ料理レストランが、更新されたメニュー情報を取得するために呼を発信されることを示唆するデータをフローマネージャ132に提供することができる。

プロセス500は、決定されたトリガイベントに基づいて、特定のワークフローを選択するステップ(506)を含み得る。トリガモジュール110は、特定のワークフローまたはワークフローのノードを選択する際に使用するために、トリガイベントデータをダイヤラ106またはフローマネージャ132に提供することができる。たとえば、トリガモジュール110は、Sally's Saloon for Sweetsの掲載された営業時間における不一致を示すトリガイベントデータをフローマネージャ132に提供することができ、フローマネージャ132は、相違を解決するためにSally's Saloonに発呼するために、特定のワークフローを選択するためにデータを使用する。

プロセス500は、選択に応答して、特定のワークフローによって指定された被呼者に電話呼を開始するステップ(508)を含み得る。フローマネージャ132は、コンタクトされるべき特定の被呼者を示す命令をダイヤラ106に提供することができる。たとえば、フローマネージャ132は、Sally's Saloonに発呼するためにダイヤラ106に命令を提供することができる。

本明細書で説明するシステムおよび方法によるワークフローの開始、および、より具体的には、呼の発信は、イベントをトリガすることによって比較的自動化され得るが、望ましくない呼または地方自治体の規制に違反する呼を防止するために、セーフガードがシステム100に含まれ得る。たとえば、被呼者がもはやシステムから呼を受信したくないことを示す場合、システムはこれを認識し、さらなる呼を防止するために被呼側の番号への呼の検査を構築する。

さらに、本明細書に記載されたシステムおよび方法がデータを収集する範囲で、個人を識別できる情報が削除されるか、または永久に不明瞭にされるように、データが記憶または使用される前に、データは1つまたは複数の方法で処理され得る。たとえば、個人を識別できる情報が決定され得ないように、被告の身元が永久に削除または処理されてもよく、必要に応じて、ユーザの特定の位置が決定され得ないように、位置情報が取得される場合は被呼者の地理的位置が一般化されてもよい。ワークフローの一部として要求された場合でも、被呼者によって任意に提供された場合でも、誤って受信した場合でも、呼の間に個人情報、プライベート情報、または機密情報が受信された場合、ワークフローはシステムからの情報を永久に削除または不明化するステップを含み得る。

特定の例では、システム100は、タスクの支援のための要求を実行するための努力の現在のステータスを、自動的にまたはユーザの要求によりユーザに提供し得る。たとえば、システム100は、ユーザが使用しているデバイス、たとえばコンピュータ、モバイルデバイスなどに関する通知を通じて実行されているタスクのステータスをユーザに提供し得る。いくつかの例では、システム100は、メッセージングアプリケーションなどの他の手段を通じて、電話通信を通じるなどして、進行中のタスクのステータスをユーザに通知し得る。

図6は、システム100のタスクマネージャモジュールのブロック図600である。タスクマネージャモジュール140は、通信プラットフォーム102、トリガモジュール110、タスク情報ストレージ150、およびセッションストレージ116に接続されている。ユーザが通信プラットフォームを通じてタスクを通信する場合、タスク情報はタスク情報ストレージ150に記憶され、タスクマネージャモジュール140は、タスクがいつスケジューリングされるべきかを決定する。タスクマネージャは、タスクをトリガイベントに関連付けることができる。タスクは、最初に「新規」に設定されたステータス、または要求に対する処理が行われていないことを示す何らかの他のインジケータを有し得る。トリガイベントが発生すると、トリガモジュール110は、ダイヤリングプロセスを開始する。いくつかの実装形態では、タスクマネージャモジュール140は、タスクのステータスが開始から、進行中、完了に変化したときに各タスクのステータスを更新するために、セッションストレージを監視する。

セッション情報から、タスクマネージャモジュールは各呼のステータスと結果を決定することができる。たとえば、ボットは、予約をするために誰かにつながる前に何度かレストランに発呼しようとし得る。セッションストレージは、ボットが行う各呼に関する情報を保持する。いくつかの実装形態では、タスクマネージャモジュールは、呼タスクのステータス、すなわち、呼が初期化されているか、進行中であるか、または完了したかを決定するために、セッションストレージを定期的にポーリングし得る。他の実装形態では、セッションストレージは、タスク情報ストレージ内のタスクのステータスを更新するために、タスクマネージャモジュールに呼の結果を送信し得る。

いくつかの実装形態では、呼タスクおよびタスクの進行状況に関する情報を表示するオペレータダッシュボードを通じて、オペレータによって呼がレビューされる。

図7Aは、既存の呼タスクの進捗に関する情報を示すオペレータダッシュボードを示す図である。たとえば、図7Aは、ヘアカット予約のタスクを示す。オペレータダッシュボードは、予約時間、要求者の名前、要求されたサービス、事業名、日付、および予約の時間を含む、予約に関する情報を提供し得る。オペレータは、要求された予約が適切に予約されているかどうかを決定するために、要求に関連付けられる呼から要求および関連付けられるセッション情報をレビューし得る。

図7Bは、ユーザが要求したタスクのうちの1つをレビューするためのオペレータレビュー画面を示す。画面は、タスクの現在のステータスをオペレータに示し得る。図7Bに示されるように、予約が行われてからタスクが完了する。しかしながら、場合によっては、タスクが完了されていない可能性があり、また予約が行われていない可能性がある。オペレータは、タスクに関連付けられる録音を再生するか、または呼からの他の記憶された情報、たとえば、転記、抽出されたインテントなどを見るか、タスクに関連付けられる事業に発呼するか、または将来のために自動呼をスケジューリングするオプションを有し得る。さらに、オペレータは、タスクの現在のステータスを要求元ユーザに提供するオプションを有し得る。

ユーザはまた、通信プラットフォーム102を通じてタスクのステータスを要求することができる。追加的または代替的に、タスクマネージャモジュール140は、タスクステータス変化または時間などの他のトリガリングイベントに基づいて、ユーザにステータス更新をいつ送信するかを決定することができる。

図8は、タスクのステータスを提供するためのプロセス800の一例を示す流れ図である。プロセス800は、タスクマネージャモジュールによって、ユーザ呼要求の現在のステータスを提供するためにトリガリングイベントが発生したことを決定するステップ(802)を含み得る。上述のように、トリガリングイベントは、ステータスのユーザ要求、一定の時間量の経過、または特定のタスクのステータスの変化を含み得る。次いで、プロセス800は、タスクマネージャモジュールによって、ユーザ呼要求の現在のステータスを決定するステップ(804)を含む。タスクマネージャモジュールは、タスク情報ストレージ内のステータスをチェックすることによって、現在のステータスを決定することができる。タスクのステータスは、タスクがタスク情報ストレージ150に追加されるときに初期化される。タスクに関連付けられる呼が行われ、完了すると、タスクのステータスが更新される。次いで、タスクマネージャは、ユーザ呼要求の現在のステータスの表現を生成する(806)。表現は、タスクの現在のステータスを伝える視覚的表現であってもよく、オーディオ表現であってもよい。プロセス800は、ユーザ呼要求の現在のステータスの生成された表現をユーザに提供する(808)。

図9Aは、予約スケジューリングが進行中のとき、図1Bのヘアカット予約要求の視覚的ステータスを示す。ユーザは、タスク要求のステータスをチェックするためにユーザインターフェースにアクセスすることが可能であってもよく、ステータスが、スマートフォン、スマートウォッチ、ラップトップ、パーソナルホームアシスタントデバイス、または他の電子デバイスなどのユーザデバイスに送信されてもよい。ステータスは、電子メール、SMS、または他のメカニズムによって送信され得る。

図9Bは、予約がうまくスケジューリングされた後の、図1Bのヘアカット予約要求の視覚的ステータスを示す。このステータスは、ユーザによって要求されてもよく、予約が正常に完了されたら、ユーザにプロンプトを表示せずにユーザに送信されてもよい。

図10Aは、図1Cのレストラン予約要求の口頭ステータス要求および更新を示す。図10Aに示されるように、レストランの予約が行われたかどうかをユーザが尋ねたことに応答して、システムは、レストランに2度発呼するなどの、タスクを完了するために取ったステップを説明し得る。システムはまた、次回にシステムが呼を試みるようにスケジューリングされた時をユーザに知らせることができ、呼を試みた後のステータスをユーザに通知し得る。

図10Bは、図1Cのレストラン予約要求に対してユーザによってプロンプトを表示せずにシステムによって提供される口頭ステータス更新を示す。ユーザのタスクが完了したことをシステムが認識すると、システムはユーザにステータス更新を提供することができる。いくつかの実装形態では、システムはユーザに直ちにステータス更新を提供する。他の実装形態では、システムは、ユーザに通知するための都合の良い時間または方法を決定する。たとえば、ユーザは、英国ロンドンでのディナー予約を要求し得る。しかしながら、ユーザは現在、米国カリフォルニア州マウンテンビューに位置している場合がある。システムは、ユーザが寝ているときにレストランに発呼することを試みることができる。システムがロンドンの午後12時に予約を確認した場合、システムは、午前4時(PDT)にステータス更新テキストメッセージを送信するとユーザを起こしてしまう可能性があると決定し得る。次いで、システムは、代替のステータス更新方法、すなわち電子メールを選択してもよく、ユーザにとってより都合の良い時間にステータス更新を保持してもよい。システムは、ユーザのスケジュール、時間帯、習慣、またはユーザの他の個人情報からの情報を使用して、ユーザにステータス更新を提供するための適切で都合の良い時間および方法を決定することができる。

いくつかの実装形態では、システムは、タスクの緊急性を決定し、またはタスクを完了するための努力を繰り返すかどうかを決定するために、ユーザ情報を使用し得る。たとえば、システムは、ユーザのためにカリフォルニア州マウンテンビューの特定のレストランを予約しようとしている可能性がある。マウンテンビューへのユーザの旅行は、5月15日に終了し得る。システムが5月15日にまだ成功していない場合、5月16日以降にシステムが予約を要求し続けるのは、ユーザの旅行が終了しているため意味がない。しかし、予約をするためにレストランの誰かと接触するために、5月14日にそれまでと比較して2倍の頻度で発呼することは意味がある。期限が近づくにつれてタスクはより緊急になり、期限が過ぎると緊急性が失われるか、遅過ぎるものになり得る。

いくつかの実装形態では、図1Bの救済モジュール136は、呼の進行中に呼に導入されるべき介入のタイプを決定する。救済モジュール136は、ボットの会話を手動でリアルタイムに救済することを選択し、別のものが呼を引き継ぐことを説明し得る。他の実装形態では、モジュールは、人間のオペレータが呼を静かに引き継ぐことを可能にし得る。追加的または代替的に、救済モジュール136は、手動の介入なしにボットと人間との間の電話呼を丁寧に終了することを選択し得る。

図11は、電話呼をボットから人間に移行させるための例示的なプロセス1100を示す。プロセス1100は、電話呼の第1の端の第1の人間と電話呼の第2の端のボットとの間の電話呼の間に、呼開始システムによって、第1の人間とボットとの間のリアルタイム会話を解析するステップを含み得る(1102)。次いで、呼開始システムが、リアルタイム会話の解析に基づいて、電話呼がボットから電話呼の第2の端の第2の人間に移行されるべきかどうかを決定し得る(1104)。電話呼の第2の端の第2の人間に電話呼が移行されるべきであるとの決定に応答して、呼開始システムによって、ボットから第2の人間へ電話呼を移行させる(1106)。

特定のボット電話呼に最も適切な介入のタイプを決定するために、救済モジュール136は、緊張イベントを識別してもよく、その呼が終了されるべきか、または人間のオペレータに引き渡されるべきであるという他の表示を探してもよい。

いくつかの実装形態では、救済モジュール136は、人間の質問に適切に応答するために、人間またはボットの緊張を示す緊張イベントを識別する。救済モジュール136が緊張イベントを識別するたびに、呼のローカルな緊張とグローバルな緊張の両方の記憶されたレベルが増加する。会話が再び軌道に乗るように見えるときはいつでも、救済モジュール136はローカルな緊張レベルをリセットする。たとえば、ボットが6人の予約をするためにレストランに発呼したとき、人間はボットに「子ども椅子は何脚必要ですか?」と尋ねる場合がある。ボットは、「私たちは全員椅子が必要です」と応答する場合がある。人間は、ボットの反応に基づいて少しイライラした声調になる場合があり、「はい、全員椅子が必要なのは知っていますが、赤ちゃんのための子ども椅子は何脚必要ですか?」と応答する。システムは、イントネーションパターン、すなわち、人間の発言の開始時、発言の終了時、または発言全体を通じて、より高い調子を検出し得る。いくつかの実装形態では、イントネーションパターンは、ストレスまたは苛立ちに事前に関連付けられる。システムは、事前に関連付けられたパターンを、リアルタイム会話において検出されたパターンと一致させることができる。いくつかの実装形態では、イントネーションパターンは、繰り返される単語、意図的により遅く話すこと、あるいはキーワードまたはフレーズ(「あなたは私のことを聞いていますか?」、「私はロボットと話しているのですか?」)を検出することができる。

システムは、人間の少しイライラした声調を検出すると、呼のローカルな緊張レベルを増加する。ローカルな緊張は、現在の状態に関連付けられる可能性のある緊張の量を反映するランニングスコアである。リアルタイム会話内の人間の発言に緊張インジケータのいずれかが現れた場合、緊張スコアは、スコアが介入しきい値に達するまで上昇する。ストレスインジケータが1つも表示されない場合は、システムは、ワークフローに従って呼が進行中であることを示し得、ローカルな緊張スコアは減少するか、低いままである(または0である)。ボットが、「私たちのグループには子どもはいません」などの、人間によって予想される応答を提供することによって質問に適切に応答した場合、システムはローカルな緊張を減少することができる。システムが、音声に苛立ちを含まずに人間が応答したことを検出した場合、救済モジュールは、呼が再び軌道に乗ったと決定し、ローカルな緊張をデフォルト値にリセットしてもよく、ゼロにリセットしてもよい。

電話呼のグローバルな緊張は、累積するだけである。一方、ローカルな緊張は、人間との現在の対応に緊張があるかどうかを評価しようとし、グローバルな緊張は呼全体の総緊張を評価しようとする。たとえば、ボットが人間のオペレータによって救済される前に、3つの誤解に対してしきい値が設定され得る。ボットが人間を3回連続して理解できなかった場合、ローカルな緊張が大きくなり、ボットを救済することになる。異なる呼においては、ボットがもう一方の側を2回連続して理解していないが、第3の文章を理解している場合、第3の対話でローカルな緊張がリセットされ、会話が続行される可能性がある。グローバルな緊張は、ボットと人間との間に2つの誤解があったことを示すための情報を依然として保持する。後の呼の間に、再びボットが人間を2回連続して理解しない場合、グローバルな緊張レベルがしきい値を上回り、たとえローカルな緊張が依然として設定された3つの誤解のしきい値を下回っていても、ボットが救済される。

上述のように、ローカルな緊張レベルまたはグローバルな緊張レベルのいずれかがあるしきい値に達した場合、救済モジュール136は、手動介入する時間であることをシステム100に示すか、丁寧に呼から出る。いくつかの例では、救済モジュール136は、同じことを繰り返す、謝罪する、明確な説明求めるなどの必要があるときはいつでも、また人間がシステム100を訂正したり、呼に関して苦情を言ったりする(たとえば、「私はあなたが聞こえません、あなたは私が聞こえますか?」)ときはいつでも、イベントを緊張イベントと見なす。

いくつかの例では、救済モジュール136は、人間がボットはロボットであるかどうかを尋ねたり、無意味な質問をすることによってボットを嘲笑したり、またはシステムが予想しない何らかの他の方法で行動する場合(たとえば、レストランの予約をしようとするときに、スポーツイベントについてシステムが尋ねられた場合)、イベントを緊張イベントと見なす。

いくつかの実装形態では、救済モジュール136は、システムがいつ手動介入により救済するべきかを決定する特徴ベースのルールセットである。1つの特徴ベースのルールは、2つの連続した未知の入力インテントが発生した場合、システムが救済されるべきであるというルールであり得る。異なるルールは、呼の間のどこかに4つの未知の入力インテントが発生した場合、システムは手動オペレータによって救済されるというものである。システムは、会話内で発生するイベントを追跡し、ルールの基準を満たすイベントが発生したかどうかを決定する。

他の実装形態では、救済モジュール136は、いつ人間のオペレータに救済を委ねるか(bailout to)を自動的に予測するために、機械学習を使用する。たとえば、救済モジュール136は、1つまたは複数の機械学習モデルへの入力として、人間との会話からインテントを受信することができる。機械学習モデルは、受信したインテント、ならびに過去のインテントおよび結果に基づいて、人間のオペレータに救済を委ねるかどうかを決定することができる。システムは、いつ救済措置が発生したか、または発生するべきではなかったかを示す注釈付き録音からの機能について、機械学習モデルを訓練することができる。次いで、機械学習モジュールは、入力特徴のセットが与えられた場合に、救済措置がいつ発生するかを予測することができる。

救済モジュール136は、救済措置を決定するために、人間の行為、人間の声調、人間の決定された不快レベル、人間が使用する言語、または人間の言葉の選択を含む多くの要因を使用する。

システム100は、ボットによって行われている会話を、処理するために人間のオペレータにエスカレーションすることができる。たとえば、特定の会話においてしきい値の量の緊張がある場合、救済モジュール136は、フィードバックデータをフローマネージャ132に提供することができる。フローマネージャ132は、人間の被呼者に可聴的に警告するか否かを問わず、オペレータコントローラ134を通じて入力を提供する人間のオペレータに呼をハンドオーバするようボットに指示することができる。たとえば、ボットは「もちろんです、今日はお時間をいただきありがとうございます。こちらが私の管理者です」と言うことができる。次いで、オペレータコントローラ134を通じてボットが実行しようとしていたタスクを、人間のオペレータが完了することができる。

救済モジュール136はまた、達成されている現在のタスクにおいてシステムが有する信頼度を定義する信頼レベルを決定することができる。たとえば、ボットは、ユーザのために夕食の予約をすることを任され得る。ボットがレストランに発呼し、ボットが答えを知らない複数の質問を人間がした場合、システムは、達成されている現在のタスクにおいて信頼度が低い場合がある。システムが回答を持たない質問をシステムが受信した後、タスクを達成する際のシステムの信頼レベルはより低くなる可能性がある。システムが回復し、会話がタスクを達成する方向に動いているとシステムが決定した場合、システムは信頼レベルを上げることができる。

いくつかの実装形態では、システムは呼を監視する人間のオペレータに電話会話を渡す。システムは、オペレータのユーザインターフェースまたは他の何らかの通知メカニズムを使用して、電話呼を移行させる必要性をオペレータに警告し得る。通知されると、オペレータは、システムが呼を終了することを決定する前に、電話呼を移行させるための有限の時間を有し得る。システムは、オペレータと同じ音声を使用し得る。そのような場合、音声が同じままであるので、ボットからオペレータへの移行が相手側にとって透過的になり得る。

他の実装形態では、システムは、タスクを要求した人間のユーザに電話会話を渡す。システムは、進行中の電話呼をユーザに警告することができる。システムは、タスクを完了する際に問題があるとき、またはボットが答えを知らない質問をボットが尋ねられたときにユーザに知らせることができる。ボットは、ボットがユーザ入力を必要とする会話の詳細をテキスト、電子メール、または何らかの他の方法で伝えることができる。いくつかの実装形態では、ボットは、ユーザ入力なしで会話を続行する前に、ユーザが応答するためにしきい値の時間量、すなわち5秒待機する。会話はリアルタイムで起こっているので、ボットはユーザの応答のために長い時間期間待機することができない。いくつかの実装形態では、システムは、電話呼がボットから移行される必要があるとシステムが決定したときに、電話呼を要求元ユーザに移行しようと試みることができる。上述のように、システムは、ユーザが応答して電話呼を引き継ぐためにしきい値の時間量待機し得る。いくつかの実装形態では、ユーザがしきい値の時間量内に電話呼を引き継がない場合、システムは電話呼をオペレータに移行させる。他の例では、システムは電話会話を終了する。システムはまた、ボットからユーザへの移行が会話の反対側からシームレスになるように、人間のユーザと同じ音声を使用し得る。

図12は、上述の技法を実装するために使用され得る、コンピューティングデバイス1200の例とモバイルコンピューティングデバイス1250の例とを示す。コンピューティングデバイス1200は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータなどの、様々な形態のデジタルコンピュータを表すことが意図されている。モバイルコンピューティングデバイス1250は、携帯情報端末、セルラー電話、スマートフォン、および他の同様のコンピューティングデバイスなどの、様々な形態のモバイルデバイスを表すことが意図されている。本明細書に示された構成要素、それらの接続および関係、ならびにそれらの機能は、単に例示的であることが意図されており、本明細書に記載および/または請求される本発明の実装形態を限定することが意図されるものではない。

コンピューティングデバイス1200は、プロセッサ1202、メモリ1204、ストレージデバイス1206、メモリ1204および複数の高速拡張ポート1210に接続する高速インターフェース1208、ならびに低速拡張ポート1214およびストレージデバイス1206に接続する低速インターフェース1212を含む。プロセッサ1202、メモリ1204、ストレージデバイス1206、高速インターフェース1208、高速拡張ポート1210、および低速インターフェース1212の各々は、様々なバスを使用して相互に接続されており、共通のマザーボード上に、または適切な他の方法で搭載され得る。

高速インターフェース1208に結合されたディスプレイ1216などの外部入力/出力デバイス上にGUI用のグラフィカル情報を表示するために、プロセッサ1202は、メモリ1204またはストレージデバイス1206に記憶された命令を含む命令を、コンピューティングデバイス1200内で実行するために処理することができる。他の実装形態では、複数のメモリおよび、数種のメモリとともに、適切に、複数のプロセッサおよび/または複数のバスが使用され得る。また、複数のコンピューティングデバイスが接続され得、各デバイスが必要な動作の一部を提供する(たとえば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとして)。

メモリ1204は、コンピューティングデバイス1200内に情報を記憶する。いくつかの実装形態では、メモリ1204は、揮発性メモリユニットである。いくつかの実装形態では、メモリ1204は、不揮発性メモリユニットである。メモリ1204はまた、磁気ディスクまたは光ディスクなどのコンピュータ可読媒体の別の形態であり得る。

ストレージデバイス1206は、コンピューティングデバイス1200に大容量ストレージを提供することが可能である。いくつかの実装形態では、ストレージデバイス1206は、フロッピーディスクデバイス、ハードディスクデバイス、光ディスクデバイス、またはテープデバイスなどのコンピュータ可読媒体、フラッシュメモリまたは他の類似の固体メモリデバイス、あるいはストレージエリアネットワークまたは他の構成内のデバイスを含むデバイスのアレイであってもよく、それらを含んでもよい。コンピュータプログラム製品は、情報媒体に明白に組み込まれ得る。コンピュータプログラム製品はまた、実行されると、上述されたような1つまたは複数の方法を実行する命令を含み得る。コンピュータプログラム製品はまた、メモリ1204、ストレージデバイス1206、またはプロセッサ1202上のメモリなどの、コンピュータ可読媒体または機械可読媒体に明白に組み込まれ得る。

高速インターフェース1208は、コンピューティングデバイス1200の帯域幅集約型動作を管理し、低速インターフェース1212は、低帯域幅集約型動作を管理する。そのような機能の割振りは例示に過ぎない。いくつかの実装形態では、高速インターフェース1208は、メモリ1204、ディスプレイ1216(たとえば、グラフィックスプロセッサまたはアクセラレータを通じて)、および様々な拡張カード(図示せず)を受け入れ得る高速拡張ポート1210に結合される。この実装形態では、低速インターフェース1212は、ストレージデバイス1206および低速拡張ポート1214に結合される。様々な通信ポート(たとえば、USB、ブルートゥース(登録商標)、イーサネット(登録商標)、ワイヤレス・イーサネット)を含み得る低速拡張ポート1214は、キーボード、ポインティングデバイス、スキャナ、あるいはスイッチまたはルータなどのネットワーキングデバイスなどの1つまたは複数の入力/出力デバイスに、ネットワークアダプタを通じて結合され得る。

コンピューティングデバイス1200は、図面に示されるように、いくつかの異なる形態で実装され得る。たとえば、標準的なサーバとして実装されてもよく、そのようなサーバのグループ内で複数回実装されてもよい。さらに、コンピューティングデバイス1200は、ラップトップコンピュータ1222などのパーソナルコンピュータに実装されてもよい。コンピューティングデバイス1200は、ラックサーバシステム1224の一部として実装されてもよい。あるいは、コンピューティングデバイス1200からの構成要素は、モバイルコンピューティングデバイス1250などの、モバイルデバイス内の他の構成要素(図示せず)と組み合わせられてもよい。そのようなデバイスの各々は、コンピューティングデバイス1200およびモバイルコンピューティングデバイス1250のうちの1つまたは複数を含み得、システム全体は、互いに通信する複数のコンピューティングデバイスから構成され得る。

モバイルコンピューティングデバイス1250は、他の構成要素の中でも、プロセッサ1252、メモリ1264、ディスプレイ1254などの入力/出力デバイス、通信インターフェース1266、およびトランシーバ1268を含む。モバイルコンピューティングデバイス1250はまた、追加のストレージを提供するために、マイクロドライブまたは他のデバイスなどのストレージデバイスを備えてもよい。プロセッサ1252、メモリ1264、ディスプレイ1254、通信インターフェース1266、およびトランシーバ1268の各々は、様々なバスを使用して相互接続され、構成要素のうちのいくつかは、共通のマザーボード上に、または適切な他の方法で搭載され得る。

プロセッサ1252は、メモリ1264に記憶された命令を含む、モバイルコンピューティングデバイス1250内の命令を実行することができる。プロセッサ1252は、別々の複数のアナログおよびデジタルプロセッサを含むチップのチップセットとして実装され得る。プロセッサ1252は、たとえば、ユーザインターフェースの制御、モバイルコンピューティングデバイス1250によって実行されるアプリケーション、およびモバイルコンピューティングデバイス1250によるワイヤレス通信などの、モバイルコンピューティングデバイス1250の他の構成要素の調整のために提供し得る。

プロセッサ1252は、ディスプレイ1254に結合された制御インターフェース1258およびディスプレイインターフェース1256を通じてユーザと通信し得る。ディスプレイ1254は、たとえば、TFT(薄膜トランジスタ液晶ディスプレイ)ディスプレイでもよく、OLED(有機発光ダイオード)ディスプレイでもよく、他の適切なディスプレイ技術でもよい。ディスプレイインターフェース1256は、グラフィカル情報および他の情報をユーザに提示するためにディスプレイ1254を駆動するための適切な回路を備え得る。制御インターフェース1258は、ユーザからコマンドを受信し、プロセッサ1252への提出のためにそれらを変換し得る。さらに、外部インターフェース1262は、モバイルコンピューティングデバイス1250と他のデバイスとの近距離通信を可能にするために、プロセッサ1252との通信を提供し得る。外部インターフェース1262は、たとえば、いくつかの実装形態ではワイヤード通信のために提供してもよく、他の実装形態ではワイヤレス通信のために提供してもよく、複数のインターフェースもまた使用され得る。

メモリ1264は、モバイルコンピューティングデバイス1250内に情報を記憶する。メモリ1264は、コンピュータ可読媒体または媒体、揮発性メモリユニット、あるいは不揮発性メモリユニットの1つまたは複数として実装され得る。また、拡張メモリ1274は、たとえばSIMM(シングルインラインメモリモジュール)カードインタフェースを含み得る、拡張インターフェース1272を通じてモバイルコンピューティングデバイス1250に提供および接続され得る。拡張メモリ1274は、モバイルコンピューティングデバイス1250の余分なストレージスペースを提供してもよく、またモバイルコンピューティングデバイス1250のアプリケーションまたは他の情報を記憶してもよい。具体的には、拡張メモリ1274は、上述したプロセスを実行または補足するための命令を含むことができ、安全な情報も含み得る。したがって、たとえば、拡張メモリ1274は、モバイルコンピューティングデバイス1250のセキュリティモジュールとして提供されてもよく、モバイルコンピューティングデバイス1250の安全な使用を可能にする命令でプログラムされてもよい。さらに、安全なアプリケーションは、識別情報をSIMMカード上にハッカー不可能な方法で配置するなど、追加情報とともにSIMMカードを介して提供され得る。

メモリは、たとえば、後述するように、フラッシュメモリおよび/またはNVRAMメモリ(不揮発性ランダムアクセスメモリ)を含み得る。いくつかの実装形態では、コンピュータプログラム製品は情報媒体に明白に組み込まれている。コンピュータプログラム製品は、実行されると、上述されたような1つまたは複数の方法を実行する命令を含む。コンピュータプログラム製品は、メモリ1264、拡張メモリ1274、またはプロセッサ1252上のメモリなどの、コンピュータ可読媒体または機械可読媒体であり得る。いくつかの実装形態では、コンピュータプログラム製品は、伝搬信号において、たとえば、トランシーバ1268または外部インターフェース1262を介して受信され得る。

モバイルコンピューティングデバイス1250は、必要に応じてデジタル信号処理回路を含み得る通信インターフェース1266を通じてワイヤレスに通信し得る。通信インターフェース1266は、とりわけ、GSM(登録商標)音声呼(グローバルシステムフォーモバイルコミュニケーションズ)、SMS(ショートメッセージサービス)、EMS(拡張メッセージングサービス)、またはMMSメッセージング(マルチメディアメッセージングサービス)、CDMA(符号分割多元接続)、TDMA(時分割多元接続)、PDC(パーソナルデジタルセルラー)、WCDMA(登録商標)(広帯域符号分割多元接続)、CDM252000、あるいはGPRS(汎用パケット無線サービス)などの、様々なモードまたはプロトコルの下での通信を提供し得る。そのような通信は、たとえば、無線周波数を使用してトランシーバ1268を通じて行われ得る。さらに、ブルートゥース(登録商標)、Wi-Fi、または他のそのようなトランシーバ(図示せず)を使用するなどして、短距離通信が行われ得る。さらに、GPS(全地球測位システム)受信機モジュール2570は、モバイルコンピューティングデバイス1250に追加のナビゲーションおよび位置関連ワイヤレスデータを提供し得、それらはモバイルコンピューティングデバイス1250上で実行するアプリケーションによって適切に使用され得る。

モバイルコンピューティングデバイス1250はまた、オーディオコーデック1260を使用して可聴的に通信してもよく、オーディオコーデック1260は、ユーザから音声情報を受信し、それを使用可能なデジタル情報に変換し得る。オーディオコーデック1260は、同様に、たとえばモバイルコンピューティングデバイス1250のハンドセット内のスピーカを通じるなどして、ユーザの可聴サウンドを生成し得る。そのようなサウンドは、音声電話呼からのサウンドを含み得、録音されたサウンド(たとえば、音声メッセージ、音楽ファイルなど)を含み得、またモバイルコンピューティングデバイス1250上で動作するアプリケーションによって生成されたサウンドを含み得る。

モバイルコンピューティングデバイス1250は、図面に示されるように、いくつかの異なる形態で実装され得る。たとえば、モバイルコンピューティングデバイス1250はセルラー電話1280として実装され得る。モバイルコンピューティングデバイス1250はまた、スマートフォン1282、携帯情報端末、タブレットコンピュータ、ウェアラブルコンピュータ、または他の類似のモバイルデバイスの一部として実装され得る。

いくつかの実装形態が説明されている。それにもかかわらず、本開示の趣旨および範囲から逸脱することなしに、様々な変更がなされ得ることが理解されるであろう。たとえば、ステップを並べ替え、追加し、または除去して、上記で示されたフローの様々な形態が使用され得る。

本明細書に記載されたすべての機能的動作は、本明細書において開示される構造およびそれらの構造的同等物、あるいはそれらの1つまたは複数の組合せを含む、デジタル電子回路、あるいはコンピュータソフトウェア、ファームウェア、またはハードウェアにおいて実装され得る。開示される技法は、1つまたは複数のコンピュータプログラム製品、すなわち、データ処理装置によって実行される、またはデータ処理装置の動作を制御するための、コンピュータ可読媒体上に符号化されたコンピュータプログラム命令の1つまたは複数のモジュールとして実装され得る。コンピュータ可読媒体は、機械可読ストレージデバイス、機械可読ストレージ基板、メモリデバイス、機械可読伝搬信号に影響する組成物、あるいはそれらの1つまたは複数の組合せであり得る。コンピュータ可読媒体は、非一時的コンピュータ可読媒体であり得る。「データ処理装置」という用語は、一例として、プログラム可能プロセッサ、コンピュータ、あるいは複数のプロセッサまたはコンピュータを含む、データを処理するためのすべての装置、デバイス、および機械を包含する。装置は、ハードウェアに加えて、当該のコンピュータプログラムの実行環境を生成するコード、たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、あるいはそれらの1つまたは複数の組合せを構成するコードを含み得る。伝搬信号は、人工的に生成された信号、たとえば、適切な受信装置に送信するのに情報を符号化するために生成された機械生成の電気的、光学的、または電磁的信号である。

コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる)は、コンパイラ型言語またはインタプリタ型言語を含む任意の形態のプログラミング言語で記述され得、スタンドアロンプログラムとして、またはモジュール、構成要素、サブルーチン、あるいはコンピューティング環境における使用に適した他のユニットとしてなどの、任意の形態で展開され得る。コンピュータプログラムは、必ずしもファイルシステム内のファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータ(たとえば、マークアップ言語文書に記憶された1つまたは複数のスクリプト)を保持するファイルの一部に記憶されてもよく、当該プログラム専用の単一のファイルに記憶されてもよく、複数の調整されたファイル(たとえば、1つまたは複数のモジュール、サブプログラム、あるいはコードの一部を記憶するファイル)に記憶されてもよい。コンピュータプログラムは、1つのコンピュータ上で、または1つのサイトに配置されているか、または複数のサイトにわたって分散され、通信ネットワークによって相互接続されている複数のコンピュータ上で実行されるように配置することができる。

本明細書に記載されたプロセスおよび論理フローは、入力データを動作して出力を生成することによって機能を実行するために、1つまたは複数のコンピュータプログラムを実行する1つまたは複数のプログラム可能プロセッサによって実行され得る。プロセスおよび論理フローはまた、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)などの専用論理回路によって実行され得、装置は専用論理回路として実装され得る。

コンピュータプログラムの実行に適したプロセッサは、一例として、汎用マイクロプロセッサおよび専用マイクロプロセッサの両方、および任意の種類のデジタルコンピュータの任意の1つまたは複数のプロセッサを含む。一般に、プロセッサは、読出し専用メモリまたはランダムアクセスメモリ、あるいはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための1つまたは複数のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための1つまたは複数の大容量ストレージデバイス、たとえば磁気ディスク、光磁気ディスク、または光ディスクを含むか、そこからデータを受信するか、またはそこにデータを転送するために動作可能に結合されるか、あるいはその両方である。しかしながら、コンピュータはそのようなデバイスを有する必要はない。さらに、コンピュータは、ほんの数例を挙げると、たとえばタブレットコンピュータ、モバイル電話、携帯情報端末(PDA)、モバイルオーディオプレーヤ、全地球測位システム(GPS)受信機などの別のデバイスに埋め込まれてもよい。コンピュータプログラム命令およびデータを記憶するために適したコンピュータ可読媒体は、一例として、EPROM、EEPROM、およびフラッシュメモリデバイスなどの半導体メモリデバイス、たとえば内部ハードディスクまたはリムーバブルディスクなどの磁気ディスク、光磁気ディスク、ならびにCD-ROMおよびDVD-ROMディスクを含む、すべての形態の不揮発性メモリ、メディア、およびメモリデバイスを含む。プロセッサおよびメモリは、専用論理回路によって補足されてもよいし、専用論理回路に組み込まれてもよい。

ユーザとの対話を提供するために、開示される技法は、たとえばCRT(ブラウン管)またはLCD(液晶ディスプレイ)モニタなどのユーザに情報を表示するためのディスプレイデバイスと、ユーザがコンピュータに入力を提供し得るキーボード、および、たとえば、マウスまたはトラックボールなどのポインティングデバイスとを有するコンピュータ上で実装され得る。ユーザとの対話を提供するために他の種類のデバイスも使用され得、たとえば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックであり得、ユーザからの入力は、音響、音声、または触覚入力を含む任意の形態で受信され得る。

実装形態は、たとえばデータサーバなどのバックエンド構成要素を含む、またはアプリケーションサーバなどのミドルウェア構成要素を含む、またはユーザが開示された技法の実装形態と対話し得るグラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータなどのフロントエンド構成要素を含むコンピューティングシステム、あるいは1つまたは複数のそのようなバックエンド構成要素、ミドルウェア構成要素、またはフロントエンド構成要素の任意の組合せを含み得る。システムの構成要素は、任意の形態または媒体のデジタルデータ通信、たとえば通信ネットワークによって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)およびワイドエリアネットワーク(「WAN」)、たとえばインターネットを含む。

コンピューティングシステムは、クライアントとサーバとを含み得る。クライアントとサーバとは一般に互いに遠隔であり、典型的には通信ネットワークを介して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行され、互いにクライアント-サーバ関係を有するコンピュータプログラムによりもたらされる。

本明細書は多くの詳細を含むが、これらは限定として解釈されるべきではなく、特定の実装形態に固有の機能の説明として解釈されるべきである。別個の実装形態の文脈において本明細書に記載された特定の機能はまた、単一の実装形態において組み合わせて実装され得る。逆に、単一の実装形態の文脈において説明される様々な機能はまた、別々にまたは任意の適切なサブコンビネーションで複数の実装形態において実装され得る。さらに、機能は、特定の組合せで働くものとして上述されており、当初はそのように主張されているものであっても、場合によっては、請求された組合せからの1つまたは複数の機能が組合せから切り取られてもよく、請求された組合せは、サブコンビネーションまたはサブコンビネーションのバリエーションに導かれ得る。

同様に、動作は、特定の順序で図面に示されているが、これは、そのような動作が、所望の結果を達成するために、示された特定の順序または順番どおりに実行されること、あるいは図示されたすべての動作が実行されることを必要とするものとして理解されるべきではない。特定の状況では、マルチタスク処理と並列処理が有利な場合がある。さらに、上述の実装形態における様々なシステム構成要素の分離は、すべての実装形態においてそのような分離を必要とするものとして理解されるべきではなく、記載されたプログラム構成要素およびシステムは、一般に、単一のソフトウェア製品に一緒に統合されてもよく、複数のソフトウェア製品にパッケージ化されてもよいことが理解されるべきである。

したがって、特定の実装形態が説明されている。他の実装形態は、以下の特許請求の範囲内にある。たとえば、特許請求の範囲に記載されたアクションは、異なる順序で実行され、依然として所望の結果を達成し得る。

100 システム
102 通信フレームワークまたはプラットフォーム
104 人間
106 ダイヤラ
108 サウンドシステム
110 呼トリガリングモジュールまたはトリガモジュール
112 オーディオパッケージ
114 セッションレコーダ
114 録音スタジオおよび評価TTS
116 セッションストレージ
118 テキスト-スピーチモジュール
120 スピーチ終点検出器
122 記憶されたテキスト-スピーチ結果または録音
122 テキスト-スピーチ出力および読取り値
122 記憶された出力/読取り値
124 インテント-テキストモジュール
126 スピーチ-テキストモジュール
128 スピーチアプリケーションプログラムインターフェース(API)
130 テキスト-インテントモジュール
132 フローマネージャ
133 常識モジュール
134 オペレータコントローラ
134 オペレータ
136 救済モジュール
140 タスクマネージャモジュール
150 タスク情報ストレージ
160 タスクユーザインターフェース
160 タスクマネージャモジュール
162 呼プレイヤ
170 キュレーションユーザインターフェース
175 ローカルエージェント
190 電話呼
191 スピーチ認識装置
194 オーディオミキサ
195 ボットサービス
196 電話サーバ
197 TTSモデル
198 ダイアログモデル
199 言語モデル
200 プロセス
250 プロセス
300 ワークフロー
400 ブロック図
402 不一致検出器
404 第三者API
406 傾向検出器
408 イベント識別子
410 ユーザインターフェース
412 知識ベース
412 知識データベース
414 タイマ
416 ユーザインターフェース
418 検索エンジン
420 第三者データベース
422 イベントデータベース
500 プロセス
600 ブロック図
800 プロセス
1100 プロセス
1200 コンピューティングデバイス
1202 プロセッサ
1204 メモリ
1206 ストレージデバイス
1208 高速インターフェース
1210 高速拡張ポート
1212 低速インターフェース
1214 低速拡張ポート
1216 ディスプレイ
1222 ラップトップコンピュータ
1224 ラックサーバシステム
1250 モバイルコンピューティングデバイス
1252 プロセッサ
1254 ディスプレイ
1256 ディスプレイインターフェース
1258 制御インターフェース
1260 オーディオコーデック
1262 外部インターフェース
1264 メモリ
1266 通信インターフェース
1268 トランシーバ
1274 拡張メモリ
1280 セルラー電話
1282 スマートフォン
2570 GPS(全地球測位システム)受信機モジュール

Claims (20)

1. コンピュータ実装方法であって、
   コンピューティングデバイスのボットによって、第1の人間に代わって、第2の人間との電話による会話を実行するステップと、
   前記コンピューティングデバイスによって、前記電話による会話において、前記第2の人間からダイアログを受信するステップと、
   前記コンピューティングデバイスによって、前記ダイアログの転記を生成するステップと、
   前記コンピューティングデバイスの前記ボットによって、前記ダイアログの前記転記に基づき、前記第2の人間のインテントを決定するステップと、
   前記コンピューティングデバイスの前記ボットによって、前記第2の人間の前記インテントに基づき、会話の応答を生成するステップと
   を含む、コンピュータ実装方法。
2. 前記コンピューティングデバイスによって、前記ダイアログに関連付けられるデータにアクセスするステップをさらに含み、
   前記会話の応答が、前記ダイアログの前記データに基づく、請求項1に記載のコンピュータ実装方法。
3. 前記ダイアログに関連付けられる前記データが、前記第1の人間のためのカレンダーデータである、請求項2に記載のコンピュータ実装方法。
4. 前記ダイアログに関連付けられる前記データが、タスクを実行するように前記ボットに求める、前記第1の人間による要求である、請求項2に記載のコンピュータ実装方法。
5. 前記会話の応答を生成するステップが、
   前記コンピューティングデバイスによって、前記第2の人間の前記インテントに基づき、前記会話の応答の追加の転記を生成するステップと、
   前記コンピューティングデバイスによって、前記会話の応答の前記追加の転記をスピーチシンセサイザに提供するステップと
   を含む、請求項1に記載のコンピュータ実装方法。
6. 前記コンピューティングデバイスによって、前記第2の人間から、追加のダイアログを受信するステップと、
   前記コンピューティングデバイスによって、前記追加のダイアログの追加の転記を生成するステップと、
   前記コンピューティングデバイスの前記ボットによって、前記追加の転記に基づき、追加の会話の応答を生成するステップと
   をさらに含む、請求項1に記載のコンピュータ実装方法。
7. 前記コンピューティングデバイスによって、前記会話の応答、および前記第2の人間からの前記ダイアログの概要を示すデータを、出力のために提供するステップをさらに含む、請求項1に記載のコンピュータ実装方法。
8. システムであって、
   1つまたは複数のコンピュータと1つまたは複数のストレージデバイスとを備え、前記1つまたは複数のストレージデバイスは、前記1つまたは複数のコンピュータにより実行されたときに、前記1つまたは複数のコンピュータに複数の動作を実行させるように実行可能な命令を記録し、前記複数の動作が、
   コンピューティングデバイスのボットによって、第1の人間に代わって、第2の人間との電話による会話を実行する動作と、
   前記コンピューティングデバイスによって、前記電話による会話において、前記第2の人間からダイアログを受信する動作と、
   前記コンピューティングデバイスによって、前記ダイアログの転記を生成する動作と、
   前記コンピューティングデバイスの前記ボットによって、前記ダイアログの前記転記に基づき、前記第2の人間のインテントを決定する動作と、
   前記コンピューティングデバイスの前記ボットによって、前記第2の人間の前記インテントに基づき、会話の応答を生成する動作と
   を含む、システム。
9. 前記複数の動作が、前記コンピューティングデバイスによって、前記ダイアログに関連付けられるデータにアクセスする動作をさらに含み、
   前記会話の応答が、前記ダイアログの前記データに基づく、請求項8に記載のシステム。
10. 前記ダイアログに関連付けられる前記データが、前記第1の人間のためのカレンダーデータである、請求項9に記載のシステム。
11. 前記ダイアログに関連付けられる前記データが、タスクを実行するように前記ボットに求める、前記第1の人間による要求である、請求項9に記載のシステム。
12. 前記会話の応答を生成する動作が、
    前記コンピューティングデバイスによって、前記第2の人間の前記インテントに基づき、前記会話の応答の追加の転記を生成する動作と、
    前記コンピューティングデバイスによって、前記会話の応答の前記追加の転記をスピーチシンセサイザに提供する動作と
    を含む、請求項8に記載のシステム。
13. 前記複数の動作が、
    前記コンピューティングデバイスによって、前記第2の人間から、追加のダイアログを受信する動作と、
    前記コンピューティングデバイスによって、前記追加のダイアログの追加の転記を生成する動作と、
    前記コンピューティングデバイスの前記ボットによって、前記追加の転記に基づき、追加の会話の応答を生成する動作と
    をさらに含む、請求項8に記載のシステム。
14. 前記複数の動作が、
    前記コンピューティングデバイスによって、前記会話の応答、および前記第2の人間からの前記ダイアログの概要を示すデータを、出力のために提供するステップをさらに含む、請求項8に記載のシステム。
15. ソフトウェアを記録した非一時的コンピュータ可読記録媒体であって、
    前記ソフトウェアは、実行時に1つまたは複数のコンピュータに複数の動作を実行させるように、前記1つまたは複数のコンピュータにより実行可能な命令を備え、前記複数の動作は、
    コンピューティングデバイスのボットによって、第1の人間に代わって、第2の人間との電話による会話を実行する動作と、
    前記コンピューティングデバイスによって、前記電話による会話において、前記第2の人間からダイアログを受信する動作と、
    前記コンピューティングデバイスによって、前記ダイアログの転記を生成する動作と、
    前記コンピューティングデバイスの前記ボットによって、前記ダイアログの前記転記に基づき、前記第2の人間のインテントを決定する動作と、
    前記コンピューティングデバイスの前記ボットによって、前記第2の人間の前記インテントに基づき、会話の応答を生成する動作と
    を含む、非一時的コンピュータ可読記録媒体。
16. 前記複数の動作が、前記コンピューティングデバイスによって、前記ダイアログに関連付けられるデータにアクセスする動作をさらに含み、
    前記会話の応答が、前記ダイアログの前記データに基づく、請求項15に記載の非一時的コンピュータ可読記録媒体。
17. 前記ダイアログに関連付けられる前記データが、タスクを実行するように前記ボットに求める、前記第1の人間による要求である、請求項16に記載の非一時的コンピュータ可読記録媒体。
18. 前記会話の応答を生成する動作が、
    前記コンピューティングデバイスによって、前記第2の人間の前記インテントに基づき、前記会話の応答の追加の転記を生成する動作と、
    前記コンピューティングデバイスによって、前記会話の応答の前記追加の転記をスピーチシンセサイザに提供する動作と
    を含む、請求項15に記載の非一時的コンピュータ可読記録媒体。
19. 前記複数の動作が、
    前記コンピューティングデバイスによって、前記第2の人間から、追加のダイアログを受信する動作と、
    前記コンピューティングデバイスによって、前記追加のダイアログの追加の転記を生成する動作と、
    前記コンピューティングデバイスの前記ボットによって、前記追加の転記に基づき、追加の会話の応答を生成する動作と
    をさらに含む、請求項15に記載の非一時的コンピュータ可読記録媒体。
20. 前記複数の動作が、
    前記コンピューティングデバイスによって、前記会話の応答、および前記第2の人間からの前記ダイアログの概要を示すデータを、出力のために提供するステップをさらに含む、請求項15に記載の非一時的コンピュータ可読記録媒体。

Images