JP6916250B2 - 仮想アシスタントドメイン選択分析 - Google Patents

Description

背景
サウンドハウンド社のハウンド、グーグルアシスタント、アマゾンアレクサ、百度度秘、アップルシリ、ライン／ネイバークローバ、マイクロソフトコルタナ、ＫＴギガジニー、ＳＫテレコムＮＵＧＵおよびオープンソースマイクロフトなどの仮想アシスタントを使用する人が増加している。第一世代仮想アシスタントは、仮想アシスタント機能を提供する企業のブランドのコンピュータ、スマートフォンまたはホームスピーカデバイスでしか利用できなかった。それらは、設定可能ではなく、企業が社内で開発したカスタム機能のみをサポートしていた。

現行の仮想アシスタントは、テキスト対応であってもよい。それらは、書かれた自然言語テキストを理解し、書かれた自然言語応答を行うことができる。いくつかの実施形態は、音声対応である。それらは、話された自然言語を理解し、テキスト、合成音声、画像、グラフィックアニメーション、オーディオおよびビデオクリップなどの様式で応答してもよい。

概要
仮想アシスタント（「ＶＡ」）を含む自動車、ロボット、売店および機器などのアプリケーション（アプリ）またはデバイスを製造および販売する企業は、必ずしも自力で「最初から」ＶＡを作成することに投資したいと思っているわけではない。これらの企業は、自身のカスタム仮想アシスタントの一部として既存の自然言語機能を柔軟に組み入れたいと思っている。これらの企業は、特に自身の要求基準に合わせて仮想アシスタントを構成できないことがもどかしいと感じている。

ドメインは、自然言語機能の単位である。ドメインは、ドメインが解釈できる一組の文によって特徴付けられ、認識された文を解釈する際に応答および作動することができる能力によって特徴付けられる。ドメインの例としては、天気についての質問に回答する天気ドメイン、ならびに、ユーザが予定を調整して管理すること、すなわち動作を要求することおよび質問すること、を可能にするカレンダドメインが挙げられる。

たとえばサウンドハウンド社のハウンディファイ（Houndify）などのいくつかのＶＡ開発プラットフォーム（「プラットフォーム」）は、開発プラットフォームで利用可能なドメインのメニューを提供することによって仮想アシスタントの開発者（「ＶＡ開発者」）をサポートする。このようなプラットフォームでは、ＶＡ開発者は、既にプラットフォームに知られているドメインのアレイを含む、自ら設計したカスタム仮想アシスタントに含めるようにドメインを選択する。いくつかの実施形態は、このようなプラットフォームを使用して仮想アシスタントを構成することを提供する。いくつかの実施形態は、このようなプラットフォームを備える。いくつかの実施形態では、プラットフォームは、ドメインプロバイダが仮想アシスタントに一体化されるようにドメインを提供するためのインターフェイスを提供する。ドメインプロバイダによって提供される情報は、ドメインを選択する仮想アシスタントにおいてドメインの機能をサポートするのに十分である。いくつかの実施形態では、いくつかのドメインは無料である。いくつかの実施形態では、提供されたドメインは、その使用に対して関連付けられた料金を請求する。さまざまな実施形態では、支払いは、プラットフォームプロバイダによって、またはＶＡ開発者、ユーザもしくはプラットフォームプロバイダを介したＶＡ開発者などの他の関係者によって、ドメインプロバイダに対してなされる。いくつかの実施形態では、プラットフォームプロバイダは、特定のドメインを他のドメインよりもプロモーションする。

いくつかの実施形態は、ＶＡ開発者が、仮想アシスタントに対するテストクエリを入力して、これらのクエリに応答して仮想アシスタントがどのように挙動するかを調べることを提供する。いくつかの実施形態は、ドメインのメニューから選択されたさまざまなドメインのさまざまな条件下での仮想アシスタントの挙動を示して比較することを提供する。

いくつかの実施形態は、ＶＡ開発者が大きなテストクエリセットを入力することを提供する。いくつかの実施形態は、テストクエリセットおよびドメインの選択に応答して仮想アシスタントの挙動の分析のビューを表示する。いくつかの実施形態は、セット内の全てのクエリに応答することに関連付けられたコストを分析することを提供する。いくつかの実施形態は、仮想アシスタントが解釈できるセット内のテストクエリの一部を分析することを提供する。

いくつかの実施形態は、ドメインのさまざまな選択の条件下でのセット内のクエリの解釈成功率およびコストを分析するための表示ビューを提供する。いくつかの実施形態は、ドメイン結果の表形式ビューを提供する。いくつかの実施形態は、各ドメインに対して価格設定モデルを提供する。いくつかの実施形態は、各ドメインによって認識される典型的なクエリを提供する。いくつかの実施形態は、テストクエリセットと、テストクエリセットからのクエリに応答するのにかかる総コストとを提供する。いくつかの実施形態は、テストセット内のクエリに応答するのにかかるドメインごとのコストのコストスタックビューを提供する。いくつかの実施形態は、ドメイン当たり応答されるクエリのヒストグラムビューを提供する。いくつかの実施形態は、いくつかのドメインが無料であり、他のドメインがコストを請求することを示す。

いくつかの実施形態は、ポインタアイコンを有するグラフィカルユーザインターフェイスを提供する。いくつかのこのような実施形態では、ポインタが表示ビューの特定の部分上に位置しているときに、対応する情報がポップアップメッセージに表示される。

いくつかの実施形態は、有用な基準に従ってドメインのメニューをソートまたはフィルタリングすることを提供する。いくつかの実施形態は、背景色、テキストの色、フォントおよび書体などさまざまな方法でメニュー内のさまざまなドメインを表示することを提供する。

いくつかの実施形態は、線形、区分線形または式ベースの価格設定モデルなどの、ドメインのためのパラメータ化価格設定モデルを提供する。いくつかのこのような実施形態は、ＶＡ開発者が費用対効果の高いドメイン選択を行うことを手助けするためのツールを提供する。

いくつかの実施形態は、コンピュータ読取可能媒体である。いくつかの実施形態は、クラウドサーバである。いくつかの実施形態は、モバイル機器である。いくつかの実施形態は、クラウドサーバと通信するデバイスのシステムである。いくつかの実施形態は、プラットフォームによって構成される自然言語仮想アシスタントを実現する自己完結型のデバイスである。

実施形態におけるドメインプロバイダからプラットフォームプロバイダ、ＶＡ開発者を介してユーザまでの情報フローを示す。 テストクエリセットを示す。 実施形態におけるドメイン、プラットフォームおよび仮想アシスタントからなるクラウドベースのシステムを示す。 実施形態におけるドメインおよびプラットフォームから構成された仮想アシスタントからなる単一デバイスシステムを示す。 実施形態において、ユーザが、ドメインに従ってクエリを解釈して応答を提供する仮想アシスタントと対話することを示す。 実施形態において、ＶＡ開発者が、テストクエリを使用して、ドメインをプロモーションするプラットフォームを介して自然言語仮想アシスタントの構成を誘導することを示す。 実施形態における、ユーザが照会し、ＶＡ開発者が構成し、ドメインプロバイダが情報をユーザに提供する完全なシステムを示す。 実施形態における、どのドメインをイネーブルにするかを選択し、各ドメインによってどれぐらいのテストクエリセットが回答されるかを示し、価格設定モデルおよびテストセット内のクエリに応答するのにかかるドメイン当たりのコストを示すことを提供するドメインのメニューの表示を示す。 実施形態におけるテストクエリセットに対する一連のイネーブルにされたドメインのコストスタックチャートを示す。 実施形態におけるテストクエリセットに対する一連のイネーブルにされたドメインのコストスタックチャートを示す。 実施形態における一連のイネーブルにされたドメインの各々によって応答されるテストクエリセットからのクエリのヒストグラムを示す。 実施形態における、ホバリングポインタ下で強調され、ドメインに特有の情報を示すドメイン当たりのクエリ応答のヒストグラムを示す。 実施形態における、プロモーションされたドメインが目立つように示されるドメインのメニューの表示を示す。 テストクエリを入力して、このクエリに応答することができるドメインおよびそれらの応答のフィルタリングされたメニューを見るための表示を示す。 線形価格設定モデルを示す。 区分線形価格設定モデルを示す。 式ベースの価格設定モデルを示す。 回転式の非一時的なコンピュータ読取可能媒体を示す。 パッケージングされたソリッドステートの非一時的なコンピュータ読取可能媒体を示す。 サーバのラックを示す。 サーバのブロック図を示す。 パッケージングされたシステムオンチップを示す。 システムオンチップのブロック図を示す。

詳細な説明
さまざまな特徴を説明する本発明のさまざまな実施形態が以下に記載されている。一般に、実施形態では、記載されている特徴を任意の組み合わせで使用することができる。

多くの企業は、仮想アシスタントを一体化することによって向上させることができるデバイスまたはアプリを製造または販売している。多くの仮想アシスタントは、音声ベースである。音声対応デバイスの例は、自動車、ロボット、売店、機器およびスマートフォンである。それらは全て、一体化された仮想アシスタントを有することができる。ユーザは、通常は情報の要求または動作の要求のいずれかである自然言語クエリを発行することによって仮想アシスタントと通信する。クエリは、話されたクエリであってもよく、または書かれたクエリであってもよい。仮想アシスタントからの応答は、音声、テキスト、グラフィックス、オーディオまたはビデオ記録、および動作を含んでもよい。

インテリジェント多機能仮想アシスタントの開発は、複雑であり、一般的なアーキテクチャに加えて、仮想アシスタントが処理できるドメインごとに専門知識および投資を必要とする。仮想アシスタントを開発する際、開発者が仮想アシスタント開発プラットフォームプロバイダからドメインソフトウェアを購入またはインライセンスすることは道理にかなっている。これにより、プラットフォームプロバイダは、優れたプラットフォームを構築するのに十分な専門家を雇うことができ、さまざまなＶＡ開発者は、コストをシェアすることができる。

このようなエコシステムでは、仮想アシスタントを実現するための論理またはソフトウェアは、プラットフォームプロバイダによって操作されるネットワーク接続サーバ内、またはネットワークに接続しなくてもよいデバイス内のコンピュータ読取可能媒体上に格納され、デバイス論理またはソフトウェアは、プラットフォームを使用して構成されている。典型的なネットワークに接続された実施形態では、クライアントアプリまたはリモートデバイスが、アプリケーションプログラミングインターフェイス（「ＡＰＩ」）を使用してインターネットを介してサーバにアクセスする。単一デバイス仮想アシスタントの中には、自律的に動作するものもあれば、ネットワークアクセスがある場合のみ動作するものもあり、ローカル仮想アシスタント機能とリモート仮想アシスタント機能とを組み合わせることによって断続的なネットワークアクセスで動作するものもある。ネットワークに接続されていようとそうでなかろうと、仮想アシスタントは、ユーザから自然言語クエリを受信し、このクエリを解釈して、応答をユーザに提供する。ゼロ個または１つ以上のドメインが各クエリを認識してもよい。曖昧さがある場合には、仮想アシスタントは、競合するドメインのうちの１つを選択して、その応答を判断する。

仮想アシスタント開発者は、仮想アシスタントを特定のデバイスおよびアプリに一体化する企業で働く人（ほとんどの場合、訓練を受けた技術者）である。ＶＡ開発者は、プラットフォームを使用して、特定の要求基準に合わせて仮想アシスタントを構成する。仮想アシスタントは、一般に、複数のドメインをサポートする。いくつかのドメインは、天気、ニュース、トリビア、レストラン検索、簡単な計算およびウィキペディア検索などの情報を提供する。いくつかのドメインは、サーモスタットの制御または照明、音楽のストリーミング、ＳＭＳテキストメッセージの送信、およびカレンダの予定の管理などのサービスを提供する。いくつかのドメインは、単に時間を伝えるといったような単純なものであってもよい。いくつかのドメインは、旅行代理店サービスの提供などの複雑なものであってもよく、子供の居場所を突き止めることができる機能など、ユーザにとって非常に有益なものもある。多くのドメインは、ウェブＡＰＩにアクセスして、特定の情報または動的な情報にアクセスするか、または要求された動作を生じさせる。いくつかのドメインは、支払いと引き換えに第三者プロバイダからの情報およびサービスを提供する。たとえば、いくつかの天気ドメインは、国立気象局ＡＰＩにアクセスして、天気予報情報を取得する。

プラットフォームは、いくつかある機能の中で特に、仮想アシスタントに含めるようにドメインを選択する方法をＶＡ開発者に提供する。一般に、ドメインは、ドメインプロバイダエンティティによって提供される。いくつかのプラットフォームは、何千もの第三者ドメインプロバイダをサポートする。いくつかのドメインプロバイダは、小企業またはさらには個々のプログラマである。

いくつかの実施形態では、ドメインによって認識されるクエリセットは、意味文法コードによって定義される。このような文法コードは、クエリを特定の情報要求または特定の動作要求として解釈するためのルールを作成するドメイン開発者（ほとんどの場合、訓練を受けた技術者）によって各ドメインについて具体的に作成される。このような実施形態では、自然言語解釈は、ドメイン文法コードに基づく。ドメイン文法は、クエリを構文解析するために自然言語処理システムによって使用される構文規則を備える。ドメイン文法では、構文規則は、意味論的拡張によって拡張される。拡張は、ゼロ個以上の副構成要素の解釈から構成要素の解釈を構築する機能であり、副構成要素は、構文解析によって判断される。いくつかの実施形態では、ドメイン文法を使用して、ドメインに対するクエリを認識して解釈する。いくつかの実施形態では、インタプリタの少なくとも一部は、機械学習を使用して訓練されるニューラルネットワークを含む。いずれにしても、クエリの解釈は、クエリからの情報に基づいて値を意味スロットに割り当てる。いくつかの実施形態では、会議のスケジューリングまたはフライトの予約などの、クエリに対するユーザの全体的意図を表す意図スロットを符号化する。

例示的な実施形態では、天気予報を要求するための意味文法は、（１）構文成分が＜場所＞と名付けられる構成要素を有してもよく、対応する意味スロットは「場所」と名付けられ、その値がどの例においても場所と見なされなければならず、（２）構文成分が＜時間＞と名付けられる別の構成要素を有してもよく、対応する意味スロットが「時間」と名付けられ、その値が時間と見なされなければならない。「明日、ティンブクトゥはどのような天気ですか」とユーザが尋ねると、この実施形態では、＜場所＞および＜時間＞成分を有する天気ドメイン文法を使用し、意図スロットを値「天気＿情報」で埋め、場所スロットを値「ティンブクトゥ」で埋め、時間スロットを値「明日」またはおそらく対応するカレンダ日付で埋めることができる。

同様に、「少なくとも４つ星の最寄りのフレンチレストランはどこですか」とユーザが言うと、システムは、＜料理＿タイプ＞および＜格付け＞成分の構文規則を有するレストランドメイン文法を使用することができ、料理タイプおよび格付けのための対応するスロットは、「フランス料理」および「少なくとも４つ星」をそれぞれ伝える値で埋められるであろう。別の例では、「テキスト：ママ大好き」とユーザが言うと、システムは、ＳＭＳテキスティングドメイン文法を有するクエリを認識して、意図スロットを「送信＿テキスト」で埋め、「ママ」に対応するユーザの連絡先リストの中の連絡先を参照して受け手スロットを埋め、メッセージスロットを「大好き」で埋める。クエリの解釈は、これらのスロットで形成され、意図によって指定されるクエリの解釈の完了は、メッセージのテキスト内容を受け手の携帯電話に送信するというものであろう。「猫はいくつの爪を持っていますか」とユーザが言うと、システムは、知識ドメインクエリを認識して、意図スロットを「ウィキペディア検索」（と言う）で埋め、種類スロットを「猫」で埋め、属性スロットを「爪」で埋め、質問スロットを「いくつ」で埋める。他の自然言語アプローチも可能である。

いくつかのクエリは、複数のドメインによって解釈することができる。さまざまなドメインプロバイダが競合して同一のドメイン機能を提供する場合には、このような重複する文法を有することは一般的である。たとえば、プラットフォームは、ホテルを予約するための４つの競合するドメインを提供してもよく、これら４つのドメインは全て、「パリのホテルを教えてください」というクエリを解釈することができる。ＶＡ開発者がこの状況に対処することを手助けするために、プラットフォームは、機能の中に特定のドメインを含めて他のドメインを含めないように仮想アシスタントを構成することができ、または他のドメインに優先して特定のドメインを選択するように仮想アシスタントを構成することができる。このような選択は、「ハードな」方法または「ソフトな」方法で行うことができる。

ハードな選択は、構成時になされる。いくつかのドメインは、仮想アシスタントにおいてイネーブルにされ、他の全てのドメインは、ディスエーブルにされる。この構成ステップにより、ＶＡ開発者は、ランタイム時にどのドメインがクエリの解釈に関与するかを制御することができる。本稼働時、クエリ解釈は、イネーブルにされたドメインのみを考慮する。

ソフトな選択は、ランタイム時になされる。競合するドメインのクエリ解釈（それらのドメインは全てイネーブルにされている）間の選択は、一般に、スコアリングスキームに基づいて最高スコアリングの解釈を選択することによってなされる。スコアリング技術は、ドメインに優先順位をつけるために使用することができる。すなわち、イネーブルにされたドメインＡおよびＢが競合してクエリを解釈する場合、常にドメインＡをＢよりも優先することができる。また、スコアリングは、無関係なドメイン間の曖昧さの問題に対処することができるが、このような意味的衝突はそれほど頻繁ではない。たとえば、「デンバーはどれぐらいの高さですか」というクエリは、都市の標高を知っている地理的情報ドメインによって解釈することができるが、「高さ」が気温を指す天気ドメインによっても解釈することができる。２番目の解釈は、文脈がない場合にはありそうもない解釈かもしれないが、「シカゴはどのような天気ですか？」［回答：５６度］デンバーはどれぐらいの高さですか？」などの会話における天気および気温の文脈ではかなりあり得る解釈である。構文解析および解釈スコアは、文脈依存であってもよく、スコアリングは、これらのうちの全ておよびドメイン優先順位を考慮に入れることができる。

有効な構成の選択のために、プラットフォームは、ＶＡ開発者が賢明な判断を行うことをサポートすることを意図した経験的ツールを提供することができる。いくつかの実施形態では、ドメインの費用有効性は、（１）カバー範囲、すなわちクエリのどの部分がドメインによって認識されるか、（２）正確さ、すなわち認識されたクエリのどの部分がドメインによって正確に解釈されるか、および（３）コスト検討事項の観点から、クエリのテストセットに対して測定することができる。

コストに関して、いくつかの実施形態によれば、プラットフォームは、各ドメインに関連付けられた価格設定モデルを認識していて、価格設定情報をＶＡ開発者に提供することができる。多くのプラットフォームは、時間を知らせるためのドメインまたは簡単な計算を行うためのドメインなどの特定のドメインを無料で提供するであろう。しかし、多くのドメインプロバイダは、高価値のドメインを提供し、それらのデータおよびサービスの使用を補償されたいと考える。たとえば、株を取引するためのドメインは、ユーザが要求した各々の株取引の手数料を請求することができる。いくつかの仮想アシスタントでは、ユーザは、ドメインを使用するためにＶＡ開発者に支払いを行い、ＶＡ開発者は、直接またはプラットフォームを介してドメインプロバイダに支払いを行う。場合によっては、プラットフォームは、ドメインのコストを値上げして、プラットフォームが与える付加価値を回収してもよい。

実際には、プラットフォームまたはＶＡ開発者は、より多くの顧客を引き付けるために特定のドメインを割り引くかまたは補助金を支給してもよい。価格設定モデルにおいて、クエリ当たりの価格は、数量割引の対象であることが多い。全てのこのような考慮すべき事項は、ドメインの価格設定モデルの一部であり得る。

カバー範囲および正確さは、プラットフォームがＶＡ開発者から受信するテストクエリセットに基づいて測定される。イネーブルにされたドメインがクエリを認識すると、「ヒット」が登録される。テストクエリは、少なくとも１つのイネーブルにされたドメインにヒットする場合、「カバー」されている。カバー範囲は、カバーされるテストクエリの数によって（絶対的に）測定され、またはテストクエリの対応する部分によって（相対的に）測定される。正確さは、正確に処理されるテストクエリの数によって（絶対的に）測定され、またはカバーされるテストクエリの対応する部分によって（相対的に）測定される。正確さは、テストセットがクエリ解釈データを含む場合またはテストセットがクエリデータを含む場合に測定することができる。

いくつかの実施形態では、正確さをテストすることは、本稼働時にユーザクエリに対してなされるであろうテストクエリの解釈を必要とするが、テストクエリを実行（遂行）することは必要としない。正確さは、解釈（クエリの意味の内部表現である）の同等性（または、マッチング整合性）に基づく。いくつかの実施形態では、正確さをテストすることは、テストクエリの解釈も遂行も必要とする。そして、正確さは、応答の同等性（または、マッチング整合性）に基づく。

いくつかの実施形態では、ＶＡ開発者は、テストクエリを、まるでそれがユーザから受信されたかのように入力することができ、プラットフォームは、（１）どのドメインがクエリを認識することができるか、（２）クエリの解釈、（３）解釈を遂行してクエリに応答するために必要な情報、および（４）応答を提供するコスト、のうちの１つ以上をＶＡ開発者に示すことができる。

いくつかの実施形態では、ＶＡ開発者は、大きなテストクエリセットを入力し、プラットフォームは、このクエリセットがヒットするであろうドメインおよびテストセットの累積コストについての統計情報を提供する。いくつかの実施形態では、クエリは、多数のドメインにヒットしてもよい。他の実施形態では、クエリ当たり２つ以上のヒットがないことをシステムが保証する。１つのタイプの統計情報は、クエリセットにわたるドメイン当たりのヒットのヒストグラムである。別のタイプの統計情報は、ドメイン名、各ドメインが仮想アシスタントのためにイネーブルにされるか否か、各ドメインにアクセスするための価格設定モデル（単純なクエリ当たりのコストなど）、各ドメインにヒットするテストセットにおけるクエリの数、仮想アシスタントにおいてドメインをイネーブルにすることに起因する結果として生じるコスト、イネーブルにされたドメインのうちの少なくとも１つにヒットするであろうテストセットにおけるクエリの一部、およびイネーブルにされたドメインを使用してテストセットにおける全てのクエリを処理するための総コスト、のうちの１つ以上を有するテーブルである。

いくつかのクエリが２つ以上のドメインから情報を必要とすることが可能である。たとえば、「前回のスーパーボウルの試合に勝ったチームの本拠地の天気はどうですか」というクエリは、仮想アシスタントが、スポーツ情報ドメインを使用して、どのチームが前回のスーパーボウルの試合に勝ったかおよびその本拠地を突き止め、次いで都市情報を使用して、天気ドメインを用いて天気情報を調べることを必要とするであろう。したがって、テストクエリセットに応答する仮想アシスタントによってヒットされるドメインの数は、クエリの数よりも多く、クエリのコストは、各テストクエリが１つのドメインにしかヒットしない場合よりも高いであろう。

いくつかのクエリは、いかなるドメインによっても認識されない。いくつかの実施形態では、このような機能しないクエリは、ウェブ検索の結果などのデフォルト情報を用いて応答される。その結果、ヒットの数も、クエリの数よりも少ないであろう。

一般に、仮想アシスタントが有するドメインが多くなればなるほど、仮想アシスタントが満足いくように応答することができるクエリも多くなる。ユーザが仮想アシスタントに満足すればするほど、仮想アシスタントを使用するユーザが多くなる。仮想アシスタントを使用するユーザが多くなればなるほど、ドメインプロバイダはドメインを作成して改良するインセンティブが高まる。これは、日進月歩のドメインおよび仮想アシスタントの好循環を生み出し、ユーザのためになるとともに全ての参加企業に利益をもたらす。

以下は、図面に示される特定の代表的な実施形態の説明である。
関係者
図１は、仮想アシスタントエコシステムおよびその動作の図を示す。さまざまなドメインプロバイダが情報およびサービスをプラットフォーム１２に提供する。具体的には、天気情報ドメインプロバイダは、天気ドメイン１１ａをプラットフォーム１２に提供し、地図情報ドメインプロバイダは、地図ドメイン１１ｂをプラットフォーム１２に提供し、テキストメッセージングドメインプロバイダは、テキストメッセージングドメイン１１ｃをプラットフォーム１２に提供する。ドメイン文法に加えて、プラットフォームに提供される情報は、価格設定モデルおよびテストデータを含んでもよい。

ＶＡ開発者は、プラットフォーム１２を使用して、機器１３ａ、携帯電話１３ｂおよび自動車１３ｃなどの仮想アシスタントを作成し、これらの仮想アシスタントは全て、ＶＡ機能を複数のユーザ１４に配信する。何人かのユーザは、２種類以上の仮想アシスタントを使用する。情報およびサービスは、一般に、ドメインからプラットフォームを経由してＶＡを介して、左から右に流れて、ユーザに到達する。

一般に、支払いは逆方向に流れる。さまざまな実施形態では、ユーザは、ＶＡ開発者、プラットフォームプロバイダまたはドメインプロバイダに直接支払いを行う。さまざまな実施形態では、ＶＡ開発者は、プラットフォームプロバイダまたはドメインプロバイダに直接支払いを行う。いくつかの実施形態では、プラットフォームプロバイダは、ドメインプロバイダに支払いを行う。いくつかの実施形態では、プラットフォームプロバイダは、ビジネスを勝ち取るため、または総使用量を増やすために、仮想アシスタント開発者に割引を提供するか、または損をしているいくつかのドメインへのアクセスを提供する。いくつかの実施形態では、ドメインプロバイダは、プラットフォームプロバイダがドメインをプロモーションすることと引き換えにプラットフォームプロバイダに支払いを行うかまたは割引を提供する。本明細書に開示されている技術は、この枠組みを使用して可能になるビジネス関係を限定するものではない。

いくつかの実施形態では、企業は、ドメインプロバイダでもあり、仮想アシスタント開発者でもある。たとえば、自動車の仮想アシスタントは、燃料液面高さなどの自動車についての状態クエリに回答するため、またはヘッドライトをオンにするなどの動作を要求するために、それ自体のローカルドメインを必要とする。この他に、場合によっては、天気情報を有するドメインなどの外部ドメインを含む。別の例では、特定のビデオコンテンツプロバイダによって販売されるビデオプレーヤセットトップボックスは、そのカスタム仮想アシスタントの一部として、そのビデオコンテンツを取得するためのドメインにアクセスできる必要がある。このドメインは、ローカルであってもよく、または外部であってもよい。いくつかの実施形態では、いくつかのドメインは、いくつかの仮想アシスタント専用であり、他の仮想アシスタントでは利用できない。

図２は、汎用仮想アシスタントに特有のクエリセットの一例を示す。天気についてのクエリが最も頻繁であるが、他の一般的なクエリは、ローカルビジネスの検索、地図の道順および交通状況、ニュースまたはスポーツについてのクエリ、トリビア情報についてのクエリ、ならびにさまざまな他のタイプのクエリである。各クエリがテストセットの中に複数回登場することがあるので、順序は関係なく、バッグとして知られている代替表現は、各々の固有のクエリを個数と関連付けるというものである。たとえば、「天気はどうですか」というクエリは、このセットには３個ある。これをさらに発展させて、各クエリは、他のクエリに対する重要性を実験者に示す実数値重み（単なる頻度数ではない）を付与され得る。このような重みは、合計が１であるように正規化され得る。

クラウドおよびデバイス
図３は、第１のアプリ３２および第２のアプリ３３と通信するユーザ３１を示す。これらのアプリは、ネットワーク３４を介してプラットフォーム３５と通信する。アプリ開発者３６は、前もって、プラットフォーム３５を使用して、第１のアプリ３２のための第１の仮想アシスタントおよび第２のアプリ３３のための第２の仮想アシスタントを構成している。いくつかの実施形態では、さまざまな開発者が各アプリを構成する。

プラットフォーム３５上では、複数のドメインが構成の選択に利用可能である。これらの複数の利用可能なドメインは、数百個、数千個、またはさらに多くてもよい。ドメインは、ドメインプロバイダによって提供される。それらは、ドメイン登録または摂取プロセスを介してプラットフォーム上で利用可能にされる。登録中、ドメインについて供給される情報は、固有のＩＤ、単純名、説明、認識されるクエリの例、および実行可能または解釈可能な形式のドメイン（ソースコード、オブジェクトコード、ニューラルネットワークまたは意味文法など）を含んでもよい。本開示において、「文法」または「意味文法」という語は、一般に、クエリを構文解析または認識するために実行可能なソース、オブジェクト、ニューラルネットワークまたは任意のデータ構造インスタンスなどのコードの説明を表す。

開発者３６によって作成される仮想アシスタント構成は、第１のドメイン３７および第２のドメイン３８の選択を含む。ユーザ３１は、いずれかのアプリに対してクエリを行う際、そのクエリをプラットフォーム３５に送信し、プラットフォーム３５は、クエリを解釈して、第１のドメイン３７または第２のドメイン３８からウェブＡＰＩを使用して適切な情報を取得する。

図４は、プラットフォーム４５から独立して動作するデバイス４４内に一体化されたアプリ４２と通信するユーザ４１を示す。この図は、一定の比率に応じて描かれているわけではない。アプリ開発者４６は、前もって、プラットフォーム４５を使用して、アプリのための仮想アシスタントを構成している。アプリインテグレータ（app integrator）は、仮想アシスタントアプリを内部に一体化させた製品およびサービスを設計または製造または販売する企業である。プラットフォームは、アプリインテグレータが、構成された仮想アシスタントをアプリ４２に一体化するのに必要なソフトウェアを提供していた。

アプリ４２は、ユーザ４１からクエリを受信すると、一体化されたインタプリタを使用してそれらを解釈し、それに従ってローカル情報ドメイン４７から情報を要求するか、またはローカルサービスドメイン４８からサービスアクションを要求する。たとえば、自動車デバイスでは、情報ドメイン４７は、文法を有し、「電池電力がどれぐらい残っていますか」および「これはどのラジオ放送局ですか」などのクエリのための情報を提供するであろう。自動車では、サービスドメイン４８は、文法を有し、「サンルーフを開けてください」および「ラジオの音量を上げてください」などのサービスを提供するであろう。これらの例示的な情報ソースおよびサービスは、自動車にローカルであり、ネットワークへのアクセスを必要としない。

いくつかの実施形態は、ネットワークアクセスを必要とするドメインとネットワークアクセスを必要としないドメインとの組み合わせを可能にする構成を有する。このような実施形態では、ネットワークアクセスが利用可能である場合にはドメインが成功裏に応答し、ネットワークアクセスが利用不可能である場合にはドメインの応答が不成功に終わる。

情報フローおよび構成
図５は、実施形態に係るランタイム時におけるプラットフォームを介したデータフローの図を示す。ユーザ５１は、プラットフォームが処理する自然言語クエリを発行する。インタプリタ５２は、このクエリを解釈して、応答をユーザ５１に提供する。クエリによっては、応答は、インタプリタ５２がクエリを解釈できないという単純な表示であってもよい。いくつかの実施形態では、インタプリタ５２は、単独で、成功裏に解釈するクエリに対する応答を提供することができる。

ドメインプロバイダは、音楽などの自身のサーバもしくは気象センサなどの他のソースからデータを提供し、またはメッセージの送信もしくは車両の制御などのサービスを提供する。一般に、このようなデータまたはサービスは、ドメイン５３ｂとして知られている。ユーザがいつドメインを呼び出そうと思っているかを知るために、ユーザは、対応する文法コード５３ａを有することができる。文法コードは、ドメインを呼び出すフレーズと、ユーザ表現からの単語で埋めることができるスロットとを含む。たとえば、「天気はどうですか」というフレーズを有する文法コードは、天気ドメインを呼び出し、ドメインコードは、天気予報を取得する場所および時間のためのスロットを含む。天気ドメインのフレーズおよびスロットのためのコードは、「明日、ティンブクトゥはどのような天気ですか」というフレーズがティンブクトゥの明日の天気についての要求をドメインプロバイダに行うべきであることをインタプリタが認識することを可能にする。ドメインに関連付けられたコードは、多くの実施形態では、登録され、摂取され、プラットフォームによって格納される。

インタプリタ５２は、ドメイン５３ｂに関連付けられた文法コード５３ａに従ってクエリを解釈し、このクエリがドメイン５３ｂから情報を要求すると判断すると、インタプリタ５２は、複数のドメインプロバイダのうちの１つによって提供される適切なドメイン５３ｂから情報を要求する。インタプリタ５２は、この情報を使用して、ユーザ５１に対する応答を形成する。

図６は、実施形態に係る構成時におけるプラットフォームを介したデータフローの図を示す。多くのアプリインテグレータの中で、開発者６６は、１つ以上のテストクエリ入力６４をプラットフォームに提供する。開発者６６は、１つ以上のドメインの選択６５も提供する。インタプリタ６２は、選択されたドメイン６３ｂの文法コード６３ａに従ってテストクエリを解釈して、選択されたドメイン６３ｂのうちのいずれがクエリを解釈できるかを判断する。ディスプレイは、インタプリタ６２からの結果を開発者６６に表示する（６７）。多くの表示ビューは、さまざまな実施形態にとって適切であり、有用である。いくつかの表示ビューについて以下に例示し、説明する。

図６の実施形態は、インタプリタ６２の結果に基づいて１つ以上のドメインをプロモーションすること（６８）をさらに含む。たとえば、テストクエリがプロモーションドメインに従って成功裏に解釈可能である場合、プラットフォームは、プロモーションドメインがイネーブルにされた場合にインタプリタがユーザに示すであろう結果を開発者６６に示す。いくつかの実施形態では、それらがイネーブルにされなくてもプロモーションドメインの名前を示す。いくつかの実施形態では、最高ランクの代替ドメインからの情報によって生成されるであろう応答の代替案として、プロモーションドメインからの情報によって生成されるであろう応答を示す。

たとえば、より正確で詳細な情報を有する天気ドメインプロバイダは、より高い価格を請求して、それ自体をプロモーションドメインとして提供してもよい。デフォルト天気ドメインは、一般に天気クエリに回答し得る。実施形態に係るプラットフォームは、デフォルト天気ドメインからの情報に従って応答を示し、プロモーション天気ドメインからの情報によって生成されるであろう応答を示すであろう。これは、プロモーションドメインを選択するための候補、および、仮想アシスタントに含めるようにプロモーションドメインを選択するための、ボタンアイコンなどの手段と併用してなされることができる。

図７は、プラットフォームを介したデータフローの図を示す。開発者７６は、１つ以上のテストクエリ入力７４をプラットフォームに提供する。開発者７６は、１つ以上のドメインの選択７５も提供する。インタプリタ７２は、選択されたドメイン７３ｂの文法コード７３ａに従ってテストクエリを解釈して、選択されたドメインのうちのいずれがクエリを解釈できるかを判断する。ディスプレイは、インタプリタ７２の結果を開発者７６に表示する（７７）。図７の実施形態は、インタプリタ７２の結果に基づいて１つ以上のドメイン７８をプロモーションすることをさらに含む。構成時間後、ランタイム中、ユーザ７１は、インタプリタ７２が解釈するクエリを発行して、応答をユーザ７１に提供する。

図７の実施形態では、ドメイン７３から情報を受信したことに応答して、プラットフォームは、料金７９を計算する。この料金は、価格設定モデルに従って計算される。価格設定モデルは、ドメイン使用量に基づく機能である。いくつかの実施形態は、各情報アクセスに対して単一の料金などの単純な価格設定モデルを有する。このような料金は、通常、１ＵＳドルの何分の１かである。いくつかの実施形態は、ある時間窓内の以前の情報アクセスの数またはアクセスされる情報のタイプに基づく機能であるより複雑な価格設定モデルをサポートする。同等に、いくつかのドメインは、他のドメインが情報を提供するときにサービスの提供に対して課金する。

図７の実施形態では、プラットフォームは、仮想アシスタントに情報を提供してユーザに対する応答を構成する各ドメインプロバイダに支払いを行う。これは、ドメインプロバイダが開発者に仮想アシスタントに含めるようにドメインを選択したいと思わせるインセンティブ、したがってプラットフォームプロバイダが近いビジネス関係を有するドメインプロバイダのドメインをプラットフォームプロバイダがプロモーションするインセンティブを生じさせる。

ドメインテーブル
図８は、実施形態に係るドメインテーブル８０の表示ビューを示す。テーブル８０は、ドメイン当たり１行を有する。「イネーブルにされた」列は、ドメインイネーブルの状態を示す。いくつかの実施形態では、この列におけるセルは、対応するドメインをイネーブルにしたりディスエーブルにしたりするために使用することができる。クリックするためのマウス、矢印キーもしくはショートカットキーを有するキーボード、タッチスクリーン、またはユーザインターフェイス内のオブジェクトの選択を行うための他の適切な手段などの、ドメインを選択または選択解除するためのさまざまな入力手段が可能である。

多くのさまざまなグラフィックレイアウトが可能である。一般に、多数のドメインを行および比較的少数の列として視覚的に編制して、名前、ドメインがイネーブルにされているか否か、ドメインが（テストセットから）解釈できるクエリの数またはパーセンテージ、および価格設定モデル（最も単純な場合には、クエリ当たりのコストなど）などのドメインについての関連情報を表示するのに、グリッドが有用である。ドメインがグリッドに対して整列されていることを表す長方形などの、関連情報を示すビジュアルオブジェクトも機能する。パーソナルコンピュータのデスクトップ上などでオブジェクトを任意にドラッグアンドドロップすることも可能である。

テーブル８０は、ドメインのメニューからどのドメインが仮想アシスタントに含めるように選択されるかをＶＡ開発者に示すための表示ビューを有する。表示ビュー８０は、５列を有する。見出し行は、その用途によって各列に表題をつける。これらの列は、利用可能なドメインのメニューからリストアップされた各ドメインの名前、仮想アシスタントのためにドメインがイネーブルにされるか否か、ドメインが、テストセット内の各クエリを解釈することができる全てのイネーブルにされたドメインの中でインタプリタが選択するであろうドメインであるクエリ数のカウント、クエリに応答するための価格設定モデル、およびテストセット内の各クエリに応答するようにドメインが選択されたときに仮想アシスタントが応答を提供するのに必要な情報をドメインが提供するための総コストである。

見出し行に続くのは、メニュー内の各ドメインのための行である。テーブル８０は、メニュー内に７個のドメインを含んでいる。いくつかの実施形態は、はるかに多数のドメイン、可変数のドメイン、ならびに、新たなおよび既存のドメインプロバイダが提供物を作成または除去すると動的に変化するドメインをサポートする。第１の列は、メニュー内の各ドメインの名前を有するテキスト文字列を示す。示されているドメインは、天気、食べ物、スポーツ、地図、情報、タイマおよび計算である。

第２の列は、各ドメインのためのセルを有し、ドメインが仮想アシスタントに含めるように選択されるとチェック印が付けられる。図８は、タッチスクリーン上でマウスまたは指によって制御できるポインタを示す。マウスボタンをクリックもしくはダブルクリック、またはタップもしくはダブルタップ、または指を長押しすることによって、ポインタ位置におけるドメインが選択されるか否かの状態が変化する。この状態は、セル内のチェック印の有無によって示される。

第３の列は、各ドメインのためのセルを示し、このセルは、選択されたドメインが与えられた状態でドメインからの情報によって応答されるクエリ数のカウントを含む。いくつかの実施形態では、正確なクエリ応答が分かっている場合、認識されるクエリの数および正確に回答されるクエリの数に異なる列が使用される。いくつかの実施形態では、その代わりにまたはさらに他の列を使用した絶対数に加えて、パーセンテージが表示される。さらに、いくつかのクエリは、選択されたドメインセットに関して曖昧であり、すなわち２つ以上のドメインによって解釈することができる。これは、短いクエリに最もよく見られる。たとえば、「ターキー」というクエリは、天気ドメイン、食べ物ドメイン、スポーツドメイン、地図ドメイン、情報ドメインによって解釈することができる。いくつかの実施形態では、クエリの全ての曖昧な解釈に対して標識付き応答を提供することによって曖昧なクエリを処理する。

他の実施形態では、ドメイン優先順位を使用して、クエリに一致する優先順位が最も高いドメインを選択して、より強制的に曖昧さを排除する。別の変形例では、クエリ解釈スコアが使用され、対応する文法からの最高スコアリング解釈スコアを有するドメインが勝って、応答の基礎を形成する。２つのアイデアを組み合わせることができる。全ての場合において、１つまたは少数の解釈をより強制的に選択することによって曖昧さは排除され、これは、単一ドメインの数に寄与する。ドメインの選択の状態が変化すると、これは、他のドメインが応答するであろうクエリの数を変化させ得る。いくつかの実施形態では、ドメインの選択が修正されるたびにクエリカウント数を動的に再計算する。代替的にまたは図８のクエリ数の列に加えて、いくつかの実施形態では、各ドメインが情報を提供できるテストクエリの総数も、ドメインがイネーブルにされた状態で正確に回答できるテストクエリの数の増分も示す。

第４の列は、ドメインクエリを説明するための価格設定モデルを示す。テーブル８０は、クエリ当たりの固定価格に基づく単純な種類の価格設定モデルを示す。示されている価格は、クエリ当たり０（無料ドメイン）から５¢（＄．０５ＵＳドル）の範囲である。いくつかの実施形態は、ある時間窓におけるヒット数に応じた区分線形または式ベースのモデルなどのより複雑な価格設定モデルをサポートする。スライディング時間窓（たとえば、過去３０日）と同様に、循環性時間窓が使用されてもよい（たとえば、暦月）。より複雑な価格設定モデルをサポートする実施形態は、価格設定モデル列に価格設定モデル自体を示さなくてもよく、その代わりに、ドメインの価格設定モデルセルをクリックまたはタップすることによって、ドメインの価格設定モデルを示してそれを編集できるようにするポップアップウィンドウなどの異なる表示ビューへのアクセスが与えられてもよい。

第５の列は、各ドメインについて、クエリのテストセット内のあらゆるクエリに対する応答に基づいて対応するドメインプロバイダに支払われるであろう金額を示す。応答時に情報が使用されるあらゆるドメインに対して課金される。テーブル８０に示される単純な価格設定モデルでは、各ドメインのドメインコストは、クエリ数×クエリ当たりのコストである。複合クエリを可能にする実施形態では、単一のクエリが複数のドメインにヒットしてもよい。たとえば、「アメリカ合衆国大統領は何歳ですか」は、政治情報を提供するドメインにも個人情報を提供するドメインにもヒットしてもよい。応答の曖昧さを認める実施形態では、異なる理由で単一のクエリが複数のドメインにヒットしてもよい。競合する解釈に従って複数の回答が与えられる。ドメインが選択されたり選択解除されたりするたびにクエリ数が変化し得るのと同じ理由で、ドメインコストもそれに従って変化し得る。

テーブル８０における最も下の完全な行は、どのドメインにも一致しないクエリの数を表す。このようなクエリはカウントすることはできるが、他の列は該当なしである。

その下の行には、２つの数量が記載されている。第１の数量は、現在のドメインの選択で応答を受信するクエリのパーセンテージを示す。テーブル８０において、食べ物ドメインおよび地図ドメインは、イネーブルにされていない。それらは、各々がそれぞれ１９５５個のクエリおよび７６４個のクエリに応答したであろう。それらにより、いかなるドメインによっても解釈できないクエリは６３３個になり、テストクエリのうちの７３％が成功裏に応答を受信することになる。

最後の数量セルは、イネーブルにされたドメインのドメインコストの合計を表示する。この数は、ＶＡ開発者がドメインをイネーブルにしたりディスエーブルにしたりすると動的に変化する。一般に、ＶＡ開発者がイネーブルにするドメインが多くなればなるほど、クエリの成功が大きくなり、総コストが大きくなるであろう。一般に、クエリ成功率が高くなればなるほど、ユーザエクスペリエンスが満足のいくものになるので、このような動的に有益な表示ビューにより、ＶＡ開発者はユーザ満足とドメイン使用予算との間で情報に基づいて妥協することができる。

上記の方法の全てにおいて、テストクエリまたはテストクエリのグループは、重複性を付与され得る。テストクエリセットを示す図２に戻って、たとえば「天気はどうですか」というクエリが３回行われていることに留意されたい。本稼働環境では、ＶＡ開発者は、はるかに大きなデータセットにわたってフィールド統計にアクセスでき、「天気はどうですか」についての月間数は数百にもなるであろう。同一のドメインに対して多数のクエリを有することにより、妥当なビジネス取り決めに対して非線形の数量割引がなされる。これは、静的であるかまたは低頻度でしか変化しないデータについての結果をプラットフォームがキャッシュする場合に特に当てはまる。代替的に、フィールドからの本格的な統計が無い状態では、小さなテストセットは、（１）クエリの小さなサンプルからの統計、または（２）おそらく一部にはフィールドからのデータから引き出されるキュレートされたクエリセットに基づいてもよい。いずれにしても、テストセット数は、非線形の数量割引の効果を観察するためにＶＡ開発者が変更できる変数要素を乗じることができる。

いくつかの実施形態、特に多数のドメインを有する実施形態は、ＶＡ開発者が限定された表示空間内のさまざまなドメインを見ることができるようにスクロールバーを提供する。いくつかの実施形態は、ＶＡ開発者が、１つまたは任意の数の列の基準に従ってドメインのリストをソートすることを可能にする。そうするための１つの方法は、列見出しのクリックまたはタップを受信してリストをソートすることによる方法である。さらに、リストが既にソートされている列をクリックすることにより、リストは逆の順序でソートされる。いくつかの実施形態は、各ドメインがイネーブルにされているか否か、価格設定モデルの範囲およびドメインコストの範囲によるドメインのリストのフィルタリングなどのフィルタ基準をＶＡ開発者が入力するためのボックスを提供する。

あらゆる仮想アシスタントは、ＶＡ開発者にとって異なるプロジェクトである。いくつかの実施形態では、各プロジェクトは、別々に開いて閲覧され、特に特定の仮想アシスタントではドメインテーブルを表示するであろう。プラットフォームのいくつかの実施形態は、ＶＡ開発者に、アカウントを作成させてログインさせて、それらの仮想アシスタントプロジェクトを構成する。プラットフォームアドミニストレータは、さまざまなＶＡ開発者がどのドメインを見ることができるかを制御することができ、どのような制御装置およびツールによってＶＡ開発者がアカウントの条件に応じてプロジェクトに取り組むことにアクセスできるかを制御することができる。

コストスタックチャート
図９は、実施形態に係るコストスタックチャート９０の表示ビューを示す。このチャートは、「ドメイン当たり投じられる累積金額」という表題を有する。このチャートは、縦軸がコストであり、横軸がドメインである。いくつかの実施形態では、縦軸に沿ってドメインを示し、横軸に沿ってコストを示す。前者は、一般に、少数のドメインがコストの大半を占める仮想アシスタントで望ましいのに対して、後者は、一般に、多数のドメインを有する仮想アシスタントで望ましい。

視覚データを提示するための有用な方法は数多くある。たとえば、情報のエンビジョニングおよび定量的情報のビジュアルディスプレイなどのエドワード・タフテの書籍は、この主題に関して情報を提供してくれる。白黒線図面は、理想的ではないが、説明には十分であろう。図９の白黒線図面に示されている実施形態では、７個のドメインが横軸上に描かれている。単語を重複させることなく読みやすさを向上させるために、ドメインの名前は、軸とある角度をなして右揃えで書かれている。イネーブルにされたドメインの名前は、ボールドフォントで示されており、ディスエーブルにされたドメインの名前は、括弧の間に示され、より小さなフォントで書かれている。無料のドメインは、ドメイン名の後に「（ｆ）」を付して示されている。外部動的情報へのアクセスを必要としないドメインは、一般に無料である。なぜなら、プラットフォームプロバイダは、情報をキャッシュして、それを低コストで取得できるからである。

各ドメインの列において、テストクエリセットに応答するためのドメインコストに比例する高さを有するバーは、このセット内の全てのクエリに応答する総コストへのドメインの寄与を示す。各ドメインのバーの底面は、前のドメインのバーの最上部の高さに配置されている。コストを持たないドメインは、ゼロ高さのバーを有し、水平線として表示されている。縦軸は、累積コストの値で表記され、各バーの最上部の高さの水平破線は、縦軸から表示の高さのバーまで延びている。プラットフォームは、ＶＡ開発者が、名前のアルファベット順、一致するクエリの数、クエリ当たりのコスト、または総コストなどのさまざまな基準によって利用可能なドメインを自動的にソートすることによってドメインの順序を変更することを容易にする。また、プラットフォームのインターフェイスは、選択が変化し、そうでなければ順序が変化するであろう間、ユーザが特定のソートからの順序をフリーズさせることを可能にする。また、ドメインを手動で並べ替えることも可能である。また、いくつかの実施形態は、イネーブルにされたドメインまたは選択されたディスエーブルにされたドメインのみを示すなどのさまざまな基準によってドメインのリストをフィルタリングすることを提供する。

図９の表示ビューは、クリックまたはタップまたはそうでなければ適切に起動された場合にドメインがイネーブルであるか否かの状態を切り替えるポインタも備える。したがって、ＶＡ開発者は、素早くかつ容易にドメインをイネーブルにしたりディスエーブルにしたりして、テストセット内のクエリに応答するための総コストに対するその効果を見ることができる。図１０は、ポインタで（（食べ物））をクリックすることによって、ディスエーブルにされた食べ物ドメインがイネーブルにされた後の図９のものと同一の仮想アシスタントのコストスタックチャート１００の表示ビューを示す。

図１０において、ドメインは、ドメインにヒットするクエリの数によってソートされる。食べ物ドメインが天気ドメインよりも、テストセットに応答するための総コストに大きく寄与している（なぜなら、それがより高いコスト価格設定モデルを有するからである）が、このリストでは２番目に示されている。なぜなら、テストセットは、天気クエリよりも少ない食べ物クエリを有しているからである。

いくつかの実施形態では、コスト軸を線形目盛りで表示し、いくつかの実施形態では、それを対数的に示す。いくつかの実施形態では、イネーブルにされたドメインによって応答されるクエリの累積数（または、テストセットの割合またはパーセンテージ）を示す軸をチャートの右側に示す。このような軸は、コスト目盛りが規則的（線形または対数）である場合には必ず不規則な目盛りを有するであろう。代替的に、応答されるクエリの規則的な（線形または対数）表示は、不規則な間隔を有する対応する平行なコスト軸を有し得る。

クエリヒットヒストグラム
図１１は、実施形態に係るドメイン当たりのクエリヒットのヒストグラム１１０を有する表示ビューを示す。このヒストグラムは、「ドメインにヒットするクエリのヒストグラム」という表題を有し、縦軸はヒットを示し、横軸はドメインを示す。ドメインヒットは、ドメインからの情報によって応答されるクエリを指す。図１１のヒストグラム１１０は、ドメイン軸をドメインの名前で表記していない。なぜなら、名前に適合し得るドメインが多すぎるからである。代替的に、縦軸にドメインが示され、横軸にヒットが示されてもよい。ヒストグラムチャートが十分に長いか、またはＶＡ開発者が入力をスクロールすることを可能にする場合には、ドメインの名前を一覧表示してヒットの数を表示することが可能である。

ヒストグラム１１０は、平滑化された線を有するが、ドメインにわたる階段表現も機能するであろう。ヒストグラム１１０は、横軸をドメインの名前で表記していないが、閾値を超える価格設定モデルを有するドメインを示すために「＄」記号を示している。いくつかの実施形態では、（無料のドメインおよび支払い済みのドメインを示すために）閾値はゼロである。いくつかの実施形態では、ＶＡ開発者は、手頃な価格のドメイン対高価なドメインを見るために閾値を設定する。

場合によっては、少数のヒットを有するドメインでも、ユーザエクスペリエンスに対して不均衡な利益をもたらすことがある。たとえば、紛失した電話を突き止めることができる自動車仮想アシスタントで利用可能なドメインは、めったに使用されることはないが、まれに必要とされたときにはユーザによって非常に感謝されるであろう。それが、自動車での強いセールスポイントであろう。そのドメイン情報へのアクセスがＶＡ開発者にとって使用当たり非常に高価であったとしても、より多くの自動車を販売するためにはコストに十分に見合うであろう。

いくつかの実施形態は、ＶＡ開発者が、ユーザエクスペリエンスにとって特に価値が高いとして特定のドメインを星印などでタグ付けすることを可能にする。いくつかの実施形態では、図１１に見られるようなヒストグラムを、高価値のドメインが目立つ色またはアイコンで強調されるように示す。

多くのクエリが２つ以上のドメインによって解釈可能であるので、単一のドメインをイネーブルにしたりディスエーブルにしたりすることにより、全ての他のドメインからの情報によって応答されるクエリの数が変化し得る。これは、ヒストグラム内のドメインを並べ替える効果を有し得る。たとえば、２つの競合する天気ドメインがイネーブルにされ、第１のドメインが気圧を含む全ての天気情報を提供することができ、第２のドメインが全ての天気に関する質問のデフォルト情報ソースであるが気圧情報を提供できない場合、両方のドメインがイネーブルにされた状態では、第１のドメインは非常に少数のヒットを有する（ヒストグラム１１０の右側付近に示される）が、第２のドメインがディスエーブルにされた状態では、第１のドメインは非常に多数のヒットを有するであろう。

図１２は、図１１に見られるようなヒストグラム１１０であるが、ポインタを有するヒストグラム１１０の表示ビューを示す。ヒストグラム内のドメインの列の上に乗った状態で１秒間動かなければ、プラットフォームは、ドメインの名前、テストクエリセットについて有するヒットの数、およびテストセットのクエリに応答する際にドメインをイネーブルにするための総コストを示す情報ボックスをポップアップさせる。

ドメインプロモーション
図１３は、実施形態に係るドメインテーブル１３０を有する表示ビューを示す。図８のドメインテーブル８０のように、図１３のドメインテーブル１３０はドメインを一覧表示する。相違点は、ドメインテーブル１３０が２つの地図ドメインを示し、１つが「地図」と名付けられ、もう一つが「地図ＰＲＯ」と名付けられる点である。後者は、プロモーションされたドメインである。それは、少なくともテストセットの７６４個のクエリの代わりに８０５個のクエリに情報を提供できるという理由から、地図ドメインよりも優れたユーザエクスペリエンスを提供するものと思われる。プラットフォームは、地図ＰＲＯドメインおよびその線のテキストをボールドフォントで示し、そのイネーブルチェック印ボックスの周囲が強調されている。これにより、プロモーションされたドメインが目立つようにＶＡ開発者に表示されて検討対象になる。

図１３の実施形態ではボールドフォントおよび強調されたボックスを使用するが、プロモーションされたドメインを強調するための数多くの方法が可能である。たとえば、１つ以上のプロモーションされたドメインは、別々に一覧表示されてもよく、リストの最上部にくるようにソートされてもよく、異なる色もしくはシェーディングを使用して示されてもよく、星などのアイコンで示されてもよく、企業ロゴなどの画像とともに示されてもよく、または動画化されてもよい。これらのドメインを強調する手段のうちのいくつかは、組み合わせて使用されてもよい。

図１４は、実施形態に係る、特定のテストクエリを入力して結果を見るための表示ビュー１４０を示す。表示ビュー１４０は、テキスト入力ボックス１４１を備える。仮想アシスタント開発者は、物理的なキーボードまたは仮想のキーボードまたは他の適切なテキスト入力ボックスを使用してテキストを入力することができる。入力されたテキストは、カーソル位置インジケータ１４２の位置に表示される。マイクロフォンを有するユーザインターフェイスデバイスでは、ＶＡ開発者は、マイクロフォンボタン１４３をタップまたはクリックして、テストクエリを口に出して言うことができる。ガイダンスアイテムは、「クエリを口に出して言う」ことが可能であることをＶＡ開発者に知らせるために最初に呼び出されたときにディスプレイ上に表示される。

表示ビュー１４０は、アップロードボタン１４４も備える。それは、起動されると、ユーザがファイルをブラウズしてそれをプラットフォームにアップロードされるように選択するためのダイアログボックスを呼び出す。ファイルは、単一のクエリを含んでもよく、または完全なテストセットを備える任意の数のクエリの区切りリストを含んでもよい。いくつかの実施形態では、ＶＡ開発者は、グラフィカルオペレーティングシステムまたはブラウザディスプレイからクエリボックスにファイルをドラッグアンドドロップして、それをプラットフォームに自動的にアップロードさせる。アップロードボタンおよびドラッグアンドドロップアップロードのさまざまな実現例は、周知であり、JavaScript（登録商標）などの言語のブラウザクライアント側スクリプトテンプレートにおいて容易に利用できる。

表示ビュー１４０は、結果ボックス１４５をさらに備える。所与の単一の入力クエリでは、結果ボックスは、クエリに応答するのに必要とされる情報を提供することができるドメインのリストを表示し、このリストは、ドメインの名前、価格設定モデル（「コスト」と表記）、およびドメインがイネーブルにされた状態で仮想アシスタントがそのクエリについてユーザに提供するであろう応答の列を有する。いくつかの実施形態では、複数のドメインプロバイダがソース情報および文法を提供して、クエリに対する非常に異なる応答を形成することができる。結果ボックス１４５は、４個の旅行ドメインプロバイダの各々からの文法および情報を使用して仮想アシスタント応答を示す。「Trip Booker」ドメインは、コストが比較的低い（クエリ当たり１¢に過ぎない）が、自身の名前「Trip Booker」を挙げてまさに１つのホテルブランドを勧めているという点でかなり私利的な応答である。察するに、Trip Bookerドメインプロバイダおよびこのホテルブランドは、儲かるビジネス関係を有している。「Travel Mate」ドメインは、コストが中程度（クエリ当たり３¢）であるが、利用可能な多数の結果および最も興味のありそうなもののトップ５の妥当なリストを示すかなり有用な応答を提供する。「TravelHound」ドメインは、コストが高い（クエリ当たり８¢）が、特定の数のホテルが見つかったこと、いくつかのリスト、および直感的音声インターフェイスを使用してリストをソートまたはフィルタリングすることによってユーザがはるかに満足のいく結果を得るようにするための勧めを有するはるかに有用な結果を提供する。「Chee-po-tels」ドメインは、コストが安価（クエリ当たり１¢に過ぎない）であるが、その文法は、パリという単語が十中八九フランスの大都市を指していると認識する代わりに、ホテルのないアメリカのアイダホ州のとてつもなく小さな町を想定している。

ドメイン（価格設定モデル、クエリヒットの数、ＶＡ開発者によるスターセレクション、クエリ応答タイプなど）のソート順序に関わらず、プラットフォームは、２つのセクションに結果を示すことができる。「エディターズピック−協賛」と名付けられたサブ見出し１４６によって示される第１のセクションは、プラットフォームプロバイダがＶＡ開発者に選択してほしい１つ以上のドメインを示す。一般に、「エディターズピック」ドメインは、ドメインプロバイダによって協賛されるものまたはプラットフォームプロバイダによって選択されるものである。なぜなら、それらは仮想アシスタントによってより多くの使用または満足のいく結果を奨励するからである。情報を提供してテストクエリに対する応答を完全なものにすることができるドメインの残りは、「その他」と名付けられたサブ見出し１４７によって示されるセクションに示される。

価格設定モデル
上記で使用される例は、情報要求当たり１ＵＳセントまたは数ＵＳセントという線形料金の非常に単純な価格設定モデルを示す。いくつかの実施形態では、調達および配信が安価である情報の要求当たりのコストは、要求当たり１ＵＳセントよりもはるかに低いであろう。図１５Ａは、価格が要求当たり＄．０００５（要求当たり．０５¢に等しい）である線形価格設定モデルの一例を示す。

ドメインが最高解釈スコアを有するクエリの数に対して非線形である価格設定モデルを使用することは、業界では一般的である。非線形タイプの価格設定モデルの一例は、段階的価格設定モデルである。図１５Ｂは、このような価格設定モデルを示す。要求当たりのコストは、要求の数が閾値を横断すると減少する。具体的には、コストは、１ヶ月以内の最初の１０，０００個のクエリではクエリ当たり＄．００１０である。要求の数が１０，００１〜５０，０００個では、コストは要求当たり＄．０００５である。要求の数が５０，００１〜２５０，０００個では、コストは要求当たり＄．０００２である。要求の数が２５０，００１個およびその他では、コストは要求当たり＄．０００１である。クエリ数は、１ヶ月に１回リセットされる。

いくつかの実施形態では、ドメインプロバイダは、提供される情報要求の月次請求書をプラットフォームプロバイダに送信する。いくつかの実施形態では、プラットフォームプロバイダは、情報要求に先立ってクレジットを購入する。クレジットの料金は、購入される量に応じて、段階的な価格設定間隔で設定される。さまざまな実施形態では、ユーザが契約すること、アプリインテグレータがプラットフォームプロバイダまたはドメインプロバイダからクレジットを購入すること、任意の受取人が請求書によって支払いを行うこと、またはサービスの支払いを行うためのその他の適切な方法のさまざまな組み合わせがあり得る。

図１５Ｃは、非線形の式ベースの価格設定モデルを示す。要求当たりの価格設定は、多数の情報要求の段階的な間隔ではなく、式に基づく。多くの式が可能であるが、図１６における式は以下の通りである。

プラットフォームプロバイダまたはドメインプロバイダまたはそれら両方は、過去３０日間のスライディングウィンドウに対して提供された情報要求の数を維持する。要求当たりの価格は、要求当たり＄．０００１という最小値＋要求の数とともに逆対数的に変化するコストである。これは、頻繁に利用する人に対して数量割引を効果的に提供する。

ビジネス契約を交渉する人の創作性によってのみ限定されるさまざまな他の非線形価格設定モデルも可能である。

ＣＲＭ
図１６Ａは、回転式磁気ディスクである非一時的なコンピュータ読取可能媒体１６１の一例を示す。データセンタは、通常、磁気ディスクを使用して、サーバプロセッサのための命令を備えるデータおよびコードを格納する。非一時的なコンピュータ読取可能媒体１６１は、命令を備えるコードを格納し、この命令は、１つ以上のコンピュータによって実行された場合に、本明細書に記載されている方法のステップをコンピュータに実行させるであろう。回転式光ディスクおよび他の機械的に動く記憶媒体も可能である。

図１６Ｂは、フラッシュランダムアクセスメモリ（ＲＡＭ）チップである非一時的なコンピュータ読取可能媒体１６２の一例を示す。データセンタは、通常、フラッシュメモリを使用して、サーバプロセッサのためのデータおよびコードを格納する。モバイルデバイスは、通常、フラッシュメモリを使用して、システムオンチップデバイス内のプロセッサのためのデータおよびコードを格納する。非一時的なコンピュータ読取可能媒体１６２は、命令を備えるコードを格納し、この命令は、１つ以上のコンピュータによって実行された場合に、本明細書に記載されている方法のステップをコンピュータに実行させるであろう。リード線またははんだボールでパッケージングされた他の動かない記憶媒体も可能である。

いかなるタイプのコンピュータ読取可能媒体も、さまざまな実施形態に係る命令を備えるコードを格納するのに適している。

サーバ
サーバは、ＶＡ開発者に提供されるドメインのデータベースをプラットフォームメニューに格納する。また、サーバは、ドメインに関連付けられた文法のためのコードのデータベースも格納する。また、サーバは、ドメインに関連付けられた価格設定モデルのデータベースも格納する。

図１７Ａは、いくつかの実施形態に係るラックマウント式のサーバブレードマルチプロセッササーバシステム１７０を示す。それは、並行してソフトウェアを実行する多数のネットワーク接続コンピュータプロセッサを備える。

図１７Ｂは、サーバシステム１７０のブロック図を示す。それは、コンピュータプロセッサ（ＣＰＵ）コア１７１のマルチコアクラスタと、グラフィックスプロセッサ（ＧＰＵ）コア１７２のマルチコアクラスタとを備える。これらのプロセッサは、プログラムコードおよびデータの格納のために基板レベルのインターコネクト１７３を介してランダムアクセスメモリ（ＲＡＭ）デバイス１７４に接続する。サーバシステム１７０は、プロセッサがインターネットにアクセスすることを可能にするためのネットワークインターフェイス１７８も備える。ＲＡＭデバイス１７４に格納された命令を実行することによって、ＣＰＵ１７１およびＧＰＵ１７２は、本明細書に記載されている方法のステップを実行する。

ＳｏＣ
図１８Ａは、印刷回路基板への表面実装はんだ付けのためのボールグリッドアレイを有するパッケージングされたシステムオンチップデバイス１８０の底部側を示す。さまざまなパッケージ形状およびサイズがさまざまなチップ実現例で可能である。システムオンチップ（ＳｏＣ）デバイスは、本明細書に記載されている多くの埋め込みシステムおよびＩｏＴデバイスの実施形態を制御する。

図１８Ｂは、システムオンチップ１８０のブロック図を示す。それは、コンピュータプロセッサ（ＣＰＵ）コア１８１のマルチコアクラスタと、グラフィックスプロセッサ（ＧＰＵ）コア１８２のマルチコアクラスタとを備える。これらのプロセッサは、揮発性のプログラムおよびデータの格納のためにネットワークオンチップ１８３を介してオフチップダイナミックランダムアクセスメモリ（ＤＲＡＭ）インターフェイス１８４に接続し、フラッシュＲＡＭ非一時的コンピュータ読取可能媒体へのコンピュータプログラムコードの不揮発性格納のためにフラッシュインターフェイス１８５に接続する。また、ＳｏＣ１８０は、ＧＵＩを表示するための表示インターフェイス１８６と、さまざまな周辺デバイスのために必要に応じてさまざまなＩ／Ｏインターフェイスデバイスに接続するためのＩ／Ｏインターフェイスモジュール１８７とを有する。Ｉ／Ｏインターフェイスは、とりわけ、センサ（タッチスクリーンセンサなど）、ジオロケーション受信機、マイクロフォン、スピーカ、ブルートゥース（登録商標）周辺装置、ならびにＵＳＢデバイス（キーボードおよびマウスなど）をイネーブルにする。また、ＳｏＣ１８０は、プロセッサがＷｉ−Ｆｉ、３Ｇ、４Ｇロングタームエボリューション（ＬＴＥ）、５Ｇなどの有線または無線接続、ならびに他の無線インターフェイス標準無線およびイーサネット（登録商標）接続ハードウェアを介してインターネットにアクセスすることを可能にするためのネットワークインターフェイス１８８を備える。ＲＡＭデバイスに格納された命令をインターフェイス１８４を介して実行することによって、またはフラッシュデバイスに格納された命令をインターフェイス１８５を介して実行することによって、ＣＰＵ１８１およびＧＰＵ１８２は、本明細書に記載されている方法のステップを実行する。

さらに他の留意事項
当業者は、多くの変形例および変更例を認識するであろう。変形例および変更例は、開示されている特徴の任意の関連する組み合わせを含む。

さまざまな実施形態は、人間もしくは機械の挙動または人間と機械との組み合わせの挙動を使用する方法である。方法の実施形態は、大半の構成ステップが世界中のどこで行われても完全である。いくつかの実施形態は、本明細書に記載されている方法のためにこのような命令を格納するように配置された１つ以上の非一時的なコンピュータ読取可能媒体である。どんな機械が、必要なコードのうちのいずれかを備える非一時的なコンピュータ読取可能媒体を保持していても、完全な実施形態である。いくつかの実施形態は、半導体チップなどの物理的なデバイス、このようなデバイスの論理的または機能的挙動のハードウェア記述言語表現、およびこのようなハードウェア記述言語表現を格納するように配置された１つ以上の非一時的なコンピュータ読取可能媒体である。

原理、特徴および実施形態を記載する本明細書における説明は、それらの構造的等価物も機能的等価物も包含する。結合されているように本明細書に記載されている要素は、１つ以上の他の介在要素との直接接続または間接接続によって実現可能な有効な関係を有する。

示され、記載されている例では、特定の話し言葉を使用している。さまざまな実施形態は、他の言語または言語の組み合わせでも同様に動作する。示され、記載されている例では、特定の知識ドメインを使用している。さまざまな実施形態は、他のドメインまたはドメインの組み合わせでも同様に動作する。

いくつかの実施形態は、ディスプレイ画面を持たないイヤピースなどのようにスクリーンレスである。いくつかの実施形態は、自動販売機などのように据え置き型である。いくつかの実施形態は、自動車などのように移動可能である。いくつかの実施形態は、携帯電話などのように持ち運び可能である。いくつかの実施形態は、キーボードまたはタッチスクリーンなどのように手動インターフェイスを備える。いくつかの実施形態は、自然言語表現の一形態として人間の思考を使用するニューラルインターフェイスを備える。

Claims (11)

1. プラットフォームプロバイダのコンピュータによって、自然言語仮想アシスタントを構成するためのプラットフォームを提供するために実行される方法であって、
   開発者から、テストクエリの入力を受け付けるステップと、
   複数のドメインに従って前記テストクエリを解釈し、前記テストクエリを解釈することが可能なドメインのリストを決定するステップと、
   前記開発者にドメインの前記リストを提示するステップと、を備え、
   前記リストを提示するステップは、前記リスト内のプロモーションされたドメインを、前記リスト内の他のドメインよりも強調することを含む、方法。
2. 前記リストを提示するステップは、前記リスト内の各ドメインを利用するための料金を表示することを含む、請求項１に記載の方法。
3. 前記料金は、クエリ当たりの解釈のためのものである、請求項２に記載の方法。
4. 前記リストを提示するステップは、前記リストにおける各ドメインの価格設定モデルを表示することをさらに含む、請求項１に記載の方法。
5. 前記開発者から、前記テストクエリを解釈することが可能な各ドメインの状態のイネーブルとディスエーブルとの間での切替の入力を受け付けるステップをさらに備える、請求項１〜請求項４のいずれか１項に記載の方法。
6. 前記リストを提示するステップは、前記リストにおけるドメインのそれぞれを利用して前記自然言語仮想アシスタントによって提供された応答を表示することをさらに含む、請求項１〜請求項５のいずれか１項に記載の方法。
7. 前記開発者から、テストクエリのセットを受け付けるステップと、
   テストクエリの前記セットのうち、前記複数のドメインのそれぞれが解釈することができるクエリの数を表すチャートを表示するステップと、
   前記チャートにおける１つのドメインを指定する操作に応じて、指定された前記１つのドメインの情報を表示するステップと、を含む、請求項１〜請求項６のいずれか１項に記載の方法。
8. 前記１つのドメインの情報を表示するステップは、指定された前記１つのドメインの情報を示すポップアップウィンドウを表示することを含む、請求項７に記載の方法。
9. 前記１つのドメインの情報は、
   指定された前記１つのドメインの名前、
   テストクエリの前記セットのうち、指定された前記１つのドメインが応答したクエリの数、および、
   指定された前記１つのドメインがテストクエリの前記セットに応答するための料金、のうち少なくとも１つを含む、請求項７または請求項８に記載の方法。
10. サーバの少なくとも１つのプロセッサによって実行されることにより、前記サーバに、請求項１〜請求項９のいずれか１項に記載の方法を実施させる、プログラム。
11. 請求項１０に記載のプログラムを格納するメモリと、
    前記メモリに格納された前記プログラムを実行する少なくとも１つのプロセッサと、を備えるサーバ。

Images