JP7441650B2 - エンティティベースの通信を有する、インターネットクラウドによってホストされた自然言語インタラクティブメッセージングシステム - Google Patents

Description

関連出願の相互参照
本願は、「インターネットクラウドによってホストされた自然言語インタラクティブメッセージングシステム（INTERNET CLOUD-HOSTED NATURAL LANGUAGE INTERACTIVE MESSAGING SYSTEM）」と題される２０１６年９月１６日に出願されたインド仮特許番号第２０１６４１／０３１５６９号に対する利益および優先権を主張し、その内容全体は、全ての目的で引用によって本明細書に援用される。

背景
メッセージングアプリケーション（たとえば、フェイスブック（登録商標）メッセンジャ、ＷＨＡＴＳＡＰＰ（登録商標）インスタントメッセージングソフトウェア、ＷＥＣＨＡＴ（登録商標）モバイルテキストおよびボイスメッセージング通信サービス、ＫＩＫ（登録商標）メッセンジャ、ＴＥＬＥＧＲＡＭ（登録商標）メッセンジャ、およびＳＫＹＰＥ ＭＯＢＩＬＥ（登録商標）メッセンジャ）は、モバイルデバイス、ラップトップおよびタブレットなどのインターネット接続デバイスで急速に登場してきた技術である。メッセージングアプリケーションは、高い普及率および１日当たり高い使用数を獲得している。しかし、モバイルデバイス上のエンタープライズアプリケーションは、ユーザにエンタープライズアプリケーションをダウンロードして定期的に使用してもらおうと奮闘している。

概要
本開示は、ダイアログエンジンを実現するための技術について説明する。ダイアログエンジンは、ボットサーバとの会話の流れおよび状態を管理してもよい。いくつかの例では、ダイアログエンジンは、メッセージングアプリケーションを使用してボットサーバが受信したメッセージに対する応答を決定してもよい。

たとえば、方法は、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）を有するボットサーバが、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージを受信するステップを含んでもよい。いくつかの例では、上記ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバから上記ＵＲＩに向けられてもよい。いくつかの例では、上記ＨＴＴＰポストコールメッセージは、ユーザからの内容を含んでもよい。上記内容は、１つ以上の単語を含んでもよい。

上記方法は、上記内容の意図を識別するステップと、上記識別された意図に関連付けられた１つ以上の必須エンティティを識別するステップとをさらに含んでもよい。上記意図は、上記ユーザが上記内容を上記サーバに送信した目的であってもよい。上記意図は、上記ユーザと上記サーバとの間の会話を定義してもよい。いくつかの例では、上記意図は、複数のエンティティを含んでもよく、上記複数のエンティティのうちの各エンティティは、優先順位を割り当てられ、上記優先順位は、上記エンティティが必須エンティティであるか否かを示す。上記内容の上記意図を識別するステップに応答して、上記方法は、上記サーバが上記情報にアクセスできるように、上記意図に関連付けられた上記セッションを取得するステップをさらに含んでもよい。

上記方法は、上記内容から欠落している上記１つ以上の必須エンティティのうちの１つの必須エンティティを識別するステップをさらに含んでもよい。いくつかの例では、上記意図に関連付けられたセッションは、上記サーバが上記１つ以上の必須エンティティの各々の入力を上記ユーザから受信すると完了してもよい。いくつかの例では、上記方法は、上記意図に関連付けられたセッションを格納するステップをさらに含んでもよい。上記セッションは、上記ユーザから受信される情報を含んでもよい。

上記方法は、上記ＨＴＴＰポストコールメッセージに対する応答を生成するステップをさらに含んでもよい。いくつかの例では、上記応答は、上記欠落している必須エンティティを要求してもよい。上記方法は、上記ＨＴＴＰポストコールメッセージに対する上記応答を上記メッセージングアプリケーションサーバに送信するステップをさらに含んでもよい。

用いられた用語および表現は、限定ではなく説明の用語として使用されており、このような用語および表現を使用する際に、示され記載されている特徴またはその一部のいかなる等価物も除外するつもりはない。しかし、クレームされているシステムおよび方法の範囲内でさまざまな変形が可能であるということが認識される。したがって、本システムおよび方法が例および任意の特徴によって具体的に開示されたが、本明細書に開示されている概念の変形および変更が当業者によって採用されてもよく、このような変形および変更は、添付の特許請求の範囲によって定義されるシステムおよび方法の範囲内であると考えられる、ということが理解されるべきである。

この概要は、クレームされている主題の重要なまたは必須の特徴を識別するよう意図されたものではなく、クレームされている主題の範囲を決定するために単独で使用されるよう意図されたものでもない。主題は、本特許の明細書全体、任意のまたは全ての図面、および各請求項の適切な部分を参照することによって理解されるべきである。

上記については、他の特徴および例とともに、以下の明細書、特許請求の範囲および添付の図面においてより詳細に後述する。

以下の図を参照して、例示的な例を以下で詳細に説明する。

メッセージングアプリケーションを使用してユーザと通信するためのボットサーバを実装するシステムの一例を示す。 自然言語プロセッサを使用してメッセージの意図を識別するためのシステムの一例を示す。 自然言語通信に応答するためのプロセスの一例を示すフローチャートである。 メッセージングアプリケーションを使用したモバイルデバイス上のユーザとボットサーバとの間の会話の一例を示す。 ユーザから追加情報を要求するための応答を送信するためのプロセスの一例を示すフローチャートである。 イベントデータを管理するためのシステムの一例を示す。 仮想データベースの一例を示す。 仮想データベースにアクセスするための呼び出し可能な方法を公開するためのプロセスの一例を示すフローチャートである。 サーバの一例を示す。 クラウドインフラストラクチャシステムの一例を示す。 コンピュータシステムの一例を示す。

詳細な説明
以下の記載では、本開示の例が完全に理解されるように具体的な詳細が説明の目的で示されている。しかし、これらの具体的な詳細がなくてもさまざまな例を実施できることは明らかであろう。図面および明細書は、限定的であるよう意図されるものではない。

以下の記載は、例示的な例を提供しているに過ぎず、本開示の範囲、適用範囲または構成を限定するよう意図されるものではない。むしろ、以下の例示的な例の記載は、例示的な例を実現するための実施可能な説明を当業者に提供するであろう。添付の特許請求の範囲に記載されている本開示の精神および範囲から逸脱することなく要素の機能および配置に対してさまざまな変更を行うことができるということが理解されるべきである。

例が完全に理解されるように、以下の記載では具体的な詳細が提供されている。しかし、これらの具体的な詳細がなくても例を実施できることは当業者によって理解されるであろう。たとえば、回路、システム、ネットワーク、プロセスおよび他の構成要素は、不必要なほど詳細に例を分かりにくくしないようにブロック図の形態の構成要素として示されてもよい。他の例では、例を分かりにくくすることを回避するために、周知の回路、プロセス、アルゴリズム、構造および技術は、不必要な詳細なしに示されてもよい。

また、個々の例は、フローチャート、フロー図、データフロー図、構造図またはブロック図として示されるプロセスとして記載されてもよいということに留意されたい。フローチャートは、動作をシーケンシャルなプロセスとして記載してもよいが、動作のうちの多くは、並列にまたは同時に実行されてもよい。また、動作の順序は、配列し直されてもよい。プロセスは、その動作が完了したときに終了するが、図面に含まれていないさらに他のステップを有してもよい。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合、その終了は、当該関数の呼び出し関数またはメイン関数への戻りに対応し得る。

「機械読取可能な記憶媒体」または「コンピュータ読取可能な記憶媒体」という用語は、命令および／またはデータを格納、収容または担持することができる携帯型または据え置き型記憶装置、光学式記憶装置およびさまざまな他の媒体を含むが、それらに限定されるものではない。機械読取可能な記憶媒体またはコンピュータ読取可能な記憶媒体は、データを格納することができ、かつ、無線でまたは有線接続を介して伝搬する搬送波および／または一時的な電子信号を含まない非一時的な媒体を含んでもよい。非一時的な媒体の例としては、磁気ディスクもしくはテープ、コンパクトディスク（ＣＤ）もしくはデジタル多用途ディスク（ＤＶＤ）などの光学式記憶媒体、フラッシュメモリ、メモリもしくはメモリデバイスを挙げることができるが、それらに限定されるものではない。コンピュータプログラム製品は、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造もしくはプログラムステートメントの任意の組み合わせを表し得るコードおよび／または機械によって実行可能な命令を含んでもよい。情報、データ、引数、パラメータまたは記憶内容を受け渡すおよび／または受信することによって、コードセグメントは、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージ受け渡し、トークン受け渡し、ネットワーク伝送などを含む任意の好適な手段によって受け渡されてもよく、転送されてもよく、または送信されてもよい。

さらに、例は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせによって実現されてもよい。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現される場合、必要なタスク（たとえば、コンピュータプログラム製品）を実行するためのプログラムコードまたはコードセグメントは、機械読取可能な媒体に格納されてもよい。プロセッサが必要なタスクを実行してもよい。

図面のうちのいくつかに示されるシステムは、さまざまな構成で設けられてもよい。いくつかの例では、システムは、システムの１つ以上の構成要素がクラウドコンピューティングシステムにおいて１つ以上のネットワークにわたって分散される分散システムとして構成されてもよい。

Ａ．概略
本明細書における例は、自然言語メッセージ（たとえば、質問またはコメント）を使用するメッセージングアプリケーションを介して自然言語メッセージに応答することができるボットサーバに関する。特に、例は、企業が、ユーザと通信する１つ以上のボットサーバを定義して、当該１つ以上のボットサーバをマルチテナントのクロスメッセージングプラットフォームの態様で大規模に実行することを可能にすることができる。

いくつかの例では、ボットサーバは、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）に関連付けられてもよい。ＵＲＩは、文字列を使用してボットサーバを識別してもよい。ＵＲＩは、１つ以上のメッセージングアプリケーションサーバのためのウェブフックとして使用されてもよい。ＵＲＩの形式は、ユニフォーム・リソース・ロケータ（ＵＲＬ）およびユニフォーム・リソース・ネーム（ＵＲＮ）を含んでもよい。ボットサーバは、メッセージングアプリケーションサーバからメッセージ（たとえば、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージ）を受信するように設計されてもよい。ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバからＵＲＩに向けられてもよい。いくつかの例では、メッセージは、ＨＴＴＰポストコールメッセージとは異なってもよい。たとえば、ボットサーバは、ショートメッセージサーバ（ＳＭＳ）からメッセージを受信してもよい。本明細書の記載は、ボットサーバがメッセージとして受信する通信を参照するが、メッセージは、ＨＴＴＰポストコールメッセージ、ＳＭＳメッセージ、または２つのシステム間のその他のタイプの通信であってもよいということを当業者は認識するであろう。また、ボットサーバがメッセージを１つの構成要素から別の構成要素に送信するときはいつでも、実際のメッセージが送信されなくてもよいということを当業者は認識するであろう。その代わりに、メッセージからの情報が送信されてもよい。

いくつかの例では、ボットサーバは、ボットサーバの管理者によるインタラクションなしにユーザインタラクションを処理してもよい。たとえば、ユーザは、所望の目標（意図と称される場合もある）を達成するために１つ以上のメッセージをボットサーバに送信してもよい。メッセージは、内容（たとえば、テキスト、絵文字、音声、画像、ビデオ、またはメッセージを伝える他の方法）を含んでもよい。ボットサーバは、当該内容を標準的な形式（たとえば、適切なパラメータを有するエンタープライズサービスに対するＲＥＳＴコール）に変換して、自然言語応答を生成してもよい。また、ボットサーバは、さらに他の必須パラメータをユーザに促して、追加情報を要求してもよい。また、ボットサーバは、ユーザとの通信を開始させてもよい。

図１は、メッセージングアプリケーションを使用してユーザと通信するためのボットサーバ１２０を実装するシステムの一例を示す。いくつかの例では、メッセージングアプリケーションは、電子デバイス（たとえば、デスクトップコンピュータ、ラップトップ、モバイルデバイス１１０など）にインストールされてもよい。本明細書の記載は、モバイルデバイスおよびメッセージングアプリケーションを参照するが、いかなる電子デバイスが使用されてもよく、いかなるメッセージングプラットフォームが使用されてもよい（たとえば、フェイスブック（登録商標）メッセンジャ、ＷＨＡＴＳＡＰＰ（登録商標）インスタントメッセージングソフトウェア、ＷＥＣＨＡＴ（登録商標）モバイルテキストおよびボイスメッセージング通信サービス、ＫＩＫ（登録商標）メッセンジャ、ＴＥＬＥＧＲＡＭ（登録商標）メッセンジャ、ＳＫＹＰＥ ＭＯＢＩＬＥ（登録商標）メッセンジャ、ショートメッセージサービス（ＳＭＳ））ということを当業者は認識するであろう。他の例では、メッセージングアプリケーションは、モバイルデバイス１１０上にインストールされるブラウザ（たとえば、ＧＯＯＧＬＥ ＣＨＲＯＭＥ（登録商標）ブラウザ、ＭＯＺＩＬＬＡ（登録商標）ＦＩＲＥＦＯＸ（登録商標）ブラウザおよびインターネットエクスプローラーブラウザ）を介して実行されてもよい。メッセージングアプリケーションは、フェイスブック（登録商標）メッセンジャ、ＷＨＡＴＳＡＰＰ（登録商標）インスタントメッセージングソフトウェア、ＷＥＣＨＡＴ（登録商標）モバイルテキストおよびボイスメッセージング通信サービス、ＫＩＫ（登録商標）メッセンジャ、ＴＥＬＥＧＲＡＭ（登録商標）メッセンジャ、ＳＫＹＰＥ ＭＯＢＩＬＥ（登録商標）メッセンジャ、またはユーザが通信するためのプラットフォームを提供するその他のメッセージングアプリケーションであってもよい。メッセージングアプリケーションは、メッセージングアプリケーションサーバ１１５に関連付けられてもよい。モバイルデバイス１１０は、第１のネットワーク（たとえば、インターネット）によってメッセージングアプリケーションサーバ１１５に接続されてもよい。メッセージングアプリケーションサーバ１１５は、複数のモバイルデバイスにわたってメッセージングアプリケーションを介して送受信された内容を管理してもよい。当該内容は、テキスト、絵文字、音声、メディア（たとえば、画像、ビデオ、リンク）、またはメッセージを伝える他の方法を含んでもよい。フェイスブック（登録商標）メッセンジャからボットサーバ１２０によって受信されるメッセージの一例は、以下であってもよい。

また、メッセージングアプリケーションサーバ１１５は、ボットサーバ１２０と通信してもよい。メッセージングアプリケーションサーバ１１５とボットサーバ１２０との間の通信は、第２のネットワーク（たとえば、インターネット）を介したものであってもよい。第１のネットワークおよび第２のネットワークは、同じネットワークであってもよく、または同様のもしくは全く異なったネットワークであってもよい。メッセージングアプリケーションサーバ１１５は、インターネットを使用して内容（たとえば、メッセージまたはメッセージからの情報）をモバイルデバイス１１０からボットサーバ１２０にルーティングしてもよい。内容（たとえば、ボットサーバ１２０の識別）の宛先は、名目宛先として内容に含まれてもよい。

ボットサーバ１２０は、コネクタ１３０を使用して内容を受信してもよい。コネクタ１３０は、メッセージングアプリケーションサーバ１１５とボットサーバ１２０との間のインターフェイスとしての役割を果たしてもよい。いくつかの例では、コネクタ１３０は、ボットサーバ１２０がさまざまなメッセージングアプリケーションサーバにわたって内容を分析できるようにメッセージングアプリケーションサーバ１１５からの内容を正規化してもよい。正規化は、処理するために各タイプのメッセージングアプリケーションから共通のフォーマットに内容をフォーマットすることを含んでもよい。いくつかの例では、ボットサーバ１２０は、メッセージングアプリケーション（フェイスブック（登録商標）メッセンジャ、ＷＨＡＴＳＡＰＰ（登録商標）インスタントメッセージングソフトウェア、ＷＥＣＨＡＴ（登録商標）モバイルテキストおよびボイスメッセージング通信サービス、ＫＩＫ（登録商標）メッセンジャ、ＴＥＬＥＧＲＡＭ（登録商標）メッセンジャ、ＳＫＹＰＥ ＭＯＢＩＬＥ（登録商標）メッセンジャ、ショートメッセージサービス（ＳＭＳ）など）の各々のための１つ以上のコネクタを含んでもよい。

コネクタ１３０は、内容をメッセージ受信キュー１４０にルーティングしてもよい。メッセージ受信キュー１４０は、受信された順序で内容を格納してもよい。いくつかの例では、コネクタ１３０は、１つ以上のメッセージ受信キューに関連付けられてもよい。

メッセージ受信キュー１４０は、メッセージプロセッサパイプライン１５０が利用可能になるとメッセージプロセッサパイプライン１５０に内容を送信してもよい。他の例では、メッセージプロセッサパイプライン１５０は、メッセージ受信キューから内容を引き出してもよい。メッセージプロセッサパイプライン１５０は、本明細書に記載されている革新技術のうちの１つ以上を使用して内容を分析してもよい。たとえば、メッセージプロセッサパイプライン１５０は、セッショナイザ１５２、ユーザリゾルバ１５４、自然言語プロセッサ１５６、ダイアログエンジン１５８、またはそれらの任意の組み合わせのうちの少なくとも１つ以上を含んでもよい。一般に、セッショナイザ１５２は、ユーザおよびボットサーバのためのセッションを作成して管理してもよい。一般に、ユーザリゾルバ１５４は、複数のメッセージングアプリケーションを使用する重複ユーザのために組み合わせることが可能なセッションを決定してもよい。一般に、自然言語プロセッサ１５６は、メッセージの意図を判断するためにメッセージをパーズしてもよい。当該意図は、メッセージの目的を含んでもよい。たとえば、メッセージの目的は、ピザを注文すること、コンピュータを注文すること、配達に関する質問をすることなどであってもよい。一般に、ダイアログエンジンは、ボットサーバとの会話をオーケストレートしてもよい。

内容がメッセージプロセッサパイプライン１５０によって分析された後、分析された内容は、ボットコード１６０に送信されてもよい。ボットコード１６０は、分析された内容およびセッションに基づいて実行すべきアクションを決定するために第三者によって書き込まれてもよい。いくつかの例では、当該セッションは、メッセージの意図を含んでもよい。ボットコード１６０は、アウトバウンド内容をメッセージ送信キュー１７０に送信してもよい。メッセージ送信キュー１７０は、アウトバウンド内容をコネクタ１３０に送信してもよい。次いで、コネクタ１３０は、アウトバウンド内容を、ボットコード１６０によって示されるメッセージングアプリケーションサーバに送信してもよく、当該メッセージングアプリケーションサーバは、メッセージングアプリケーションサーバ１１５と同じであってもよく、または異なってもよい。次いで、メッセージングアプリケーションサーバ１１５は、アウトバウンド内容をモバイルデバイス１１０上のメッセージングアプリケーションに転送してもよい。

ボットサーバ１２０は、さらに、１つ以上のエンタープライズサービス（たとえば、エンタープライズサービス１２５）、ボットサーバ１２０によって受信されたメッセージを格納して場合によっては分析するためのストレージサーバ（図６に図示）、または内容をボットサーバ１２０に提供するための内容サーバと通信してもよい。エンタープライズサービス１２５は、コネクタ１３０、ボットコード１６０、またはそれらの任意の組み合わせのうちの少なくとも１つ以上と通信してもよい。エンタープライズサービス１２５は、メッセージングアプリケーションサーバ１１５と同様の態様でコネクタ１３０と通信してもよい。エンタープライズサービス１２５は、１人以上のユーザに関連付けられるように内容をコネクタ１３０に送信してもよい。また、エンタープライズサービス１２５は、ユーザに関連付けられたアクションをボットサーバ１２０に実行させるように内容をコネクタ１３０に送信してもよい。ボットコード１６０は、エンタープライズサービス１２５と通信して、エンタープライズサービス１２５から情報を取得してもよく、および／または、エンタープライズサービス１２５がボットコード１６０によって識別されるアクションを取ってもよい。

いくつかの例では、ボットサーバ１２０は、１つ以上のタイマを含んでもよい。タイマは、一定時間が経過した後にコネクタ１３０およびメッセージングアプリケーションサーバ１１５を使用してボットコード１６０に内容をユーザに送信させてもよい。いくつかの例では、タイマは、ユーザまたはエンタープライズサービス１２５と同様にボットサーバ１２０に内容を送信してもよい。たとえば、タイマは、ユーザからのメッセージが分析されるように、分析対象のメッセージをボットサーバ１２０に送信してもよい。

ボットサーバ１２０を説明するために、ここで一例を記載する。ユーザは、メッセージングアプリケーションを使用してメッセージをボットサーバに送信してもよい。メッセージは、挨拶を含んでもよい。ボットサーバは、ユーザとの新たな会話が開始したことを識別してもよい。ボットサーバは、ユーザの１つ以上の特徴を識別してもよい。たとえば、ボットサーバは、メッセージングアプリケーションサーバ上のユーザに関連付けられたプロフィールを使用してユーザの名前を識別してもよい。１つ以上の特徴を使用して、ボットサーバは、メッセージングアプリケーション上のユーザに応答してもよい。応答は、ユーザから受信されたメッセージに応答するユーザへのメッセージを含んでもよい。たとえば、応答は、ユーザの名前を使用した挨拶を含んでもよい。

ボットサーバに関連付けられた企業によっては、ボットサーバは、当該企業の目標を達成するように発展してもよい。たとえば、ボットサーバがピザ配達企業に関連付けられる場合、ボットサーバは、ピザが欲しいかどうか尋ねるメッセージをユーザに送信してもよい。ボットサーバとユーザとの間の会話は、そこから続いて、ボットサーバが会話を完了するかまたはユーザがボットサーバに応答することをやめるまで行ったり来たりしてもよい。

いくつかの例では、ボットサーバは、ユーザとの会話を開始させてもよい。サーバによって開始される会話は、ユーザとの以前の会話に応答したものであってもよい。たとえば、以前の会話でユーザはピザを注文してもよい。次いで、ボットサーバは、ピザが用意できたときに会話を開始させてもよい。いくつかの例では、ボットサーバは、ボットサーバに関連付けられた企業（たとえば、ピザが用意できたというメッセージをボットサーバに送信する従業員）から指示が受信されると、ピザが用意できたと判断してもよい。会話は、ピザが用意できたことを示す、ユーザに送信されるメッセージを含んでもよい。

いくつかの例では、ボットサーバは、以前のメッセージを受信したメッセージングアプリケーションとは異なるメッセージングアプリケーション上のユーザにメッセージを送信してもよい。たとえば、ボットサーバは、フェイスブック（登録商標）メッセンジャではなくショートメッセージサービス（ＳＭＳ）を使用してメッセージを送信することにしてもよい。このような実現例では、ボットサーバは、複数のメッセージングアプリケーションを統合してもよい。

いくつかの例では、ボットサーバは、タイマに基づいて会話を開始させることにしてもよい。たとえば、ボットサーバは、ピザが注文された後に１週間タイマをユーザのために有することにしてもよい。１週間タイマが期限切れになることにより、ボットサーバは、別のピザを注文するためのユーザとの新たな会話を開始させてもよい。タイマは、企業によって構成され、ボットサーバによって実行されてもよい。

いくつかの例では、ボットサーバは、会話間の情報を維持してもよい。当該情報は、ユーザとボットサーバとの間で新たな会話が開始されるたびにボットサーバがいくつかの質問をしなくてもいいように使用されてもよい。たとえば、ボットサーバは、ユーザによるピザの以前の注文を格納してもよい。新たな会話において、ボットサーバは、ユーザが前回と同じ注文をしたいかどうか尋ねるメッセージをユーザに送信してもよい。

ボットサーバ１２０は、減速が識別されると各構成要素をスケール変更することを可能にしてもよい。たとえば、閾値を超える数のメッセージがコネクタ１３０に到着していることをボットサーバ１２０が識別する場合、さらに他の１つ以上のコネクタがコネクタ１３０に追加されてもよい。また、メッセージ受信キュー、メッセージプロセッサパイプライン、ボットコードのインスタンス、およびメッセージ送信キューの各々の数は、どこで減速が識別されるかによって増加させてもよい。このような実現例では、他の追加構成要素を追加する必要なしに、さらに他の構成要素を追加することができる。たとえば、ボットコードのさらに他のインスタンスを追加する必要なしに、コネクタを追加することができる。いくつかの実現例では、ボットサーバ１２０の１つ以上の構成要素または構成要素の一部は、仮想マシン上で実行されてもよい。仮想マシン上で実行することによって、さらに他の仮想マシンを意のままに起動することができる。

いくつかの例では、ボットサーバ１２０は、ユーザに関連付けられた情報をキャッシュに格納してもよい。キャッシュは、アウトバウンドメッセージがコネクタ１３０からメッセージングアプリケーションサーバに送信された後に情報を保存するようにデータベースに書き込んでもよい。他の例では、キャッシュは、さまざまなときに（たとえば、特定の構成要素の後に、各構成要素の後に、一定時間後に、またはいつデータベースに書き込むかを判断するためのその他のメトリックで）データに書き込んでもよい。

Ｂ．自然言語プロセッサ
上記のように、メッセージプロセッサパイプラインは、自然言語プロセッサを含んでもよい。自然言語プロセッサは、自然言語プロセッサによって処理されているメッセージの意図を判断してもよい。いくつかの例では、意図は、ユーザによって送信されるメッセージの目標、理由または目的であってもよい。たとえば、ユーザは、（１）ピザを注文する、（２）注文をキャンセルする、または（３）注文の状態を確認する意図でピザアプリケーションにメッセージを送信してもよい。

いくつかの例では、メッセージの意図は、ベクトルを使用して判断されてもよい。ベクトルは、内容（たとえば、テキスト、音声、メディアなど）の分散表現であってもよい。ベクトルは、複数の要素を含んでもよく、各要素は、モデル（たとえば、言語モデル）に従ってテキストを特徴付ける。言語モデルは、自然言語における一連の単語の分散の顕著な統計的特徴を取り込む関数またはこのような関数を学習するためのアルゴリズムであってもよい。いくつかの例では、ベクトルの要素は、言語モデルによって選択され決定されるセマンティック／シンタックス情報を表現してもよい。いくつかの例では、ベクトルは、言語モデルによって定義される連続的なベクトル空間の中にあってもよく、当該空間では、意味的に同様のテキストは近くの地点にマッピングすることができる。言語モデルを訓練してテキストのベクトルを生成する方法は数多くあるということを当業者は認識するであろう。たとえば、予測方法（たとえば、ニューラル確率論的言語モデル）を使用して、言語モデルを訓練してもよい。センテンスおよびドキュメントの分散表現（Le & Mikolov, ICML 2014）を参照されたい。これは、全文が本明細書に援用される。

いくつかの例では、自然言語プロセッサによって処理されているメッセージのために第１のベクトルが生成されてもよい。当該メッセージは、内容（たとえば、テキスト、音声、メディアなど）を含んでもよい。第１のベクトルは、１つ以上の第２のベクトルと比較されてもよい。いくつかの例では、第１のベクトルも１つ以上の第２のベクトルも、言語モデルに基づいて生成されてもよい。第２のベクトルの各々は、１つ以上の例によって定義され得る意図に関連付けられてもよい。例は、意図に関連付けられるものとして識別された内容であってもよい。いくつかの例では、ユーザは、当該例が意図に関連付けられていることを識別してもよい。他の例では、意図は、上記のように言語モデルを訓練するために、予測方法を使用して判断されてもよい。このような例では、意図が予測方法を使用して判断されると、ユーザは、判断された意図についての会話の仕方をボットサーバが理解できるように、判断された意図をボットコードに関連付けてもよい。

ベクトルを比較する際、第１のベクトルは、第１のベクトルと（意図に関連付けられた）第２のベクトルとの間の距離（たとえば、コサイン距離またはユークリッド距離）が予め定められた閾値未満である場合に意図に関連付けられるように決定されてもよい。２つのベクトル間のコサイン類似性は、２つのベクトル間の角度のコサインを計算する尺度であってもよい。

いくつかの例では、１つ以上の意図について１つ以上のエンティティが定義されてもよい。このような例では、１つ以上のエンティティは、ユーザによって定義されてもよい。他の例では、１つ以上のエンティティは、言語モデルによって定義されてもよい。たとえば、特定の表現（たとえば、１つ以上の単語）が会話の中でしばしば使用される場合、当該特定の表現は、エンティティとして識別されてもよい。別の例では、意図を反映するために特定の内容がしばしば使用される場合、当該特定の内容は、エンティティとして識別されてもよい。

意図が１つ以上のエンティティを含む場合、自然言語プロセッサ１５６は、さらに、メッセージの中のエンティティを識別してもよい。このような例では、上記の比較に加えて、当該エンティティが使用されてもよい。たとえば、意図間で比較がなされた後、２つ以上の意図は類似していてもよい。このような例では、メッセージにおいて識別された大部分のエンティティを含む２つ以上の意図のうちの意図が、メッセージの意図として選択されてもよい。いくつかの例では、特定のエンティティが他のエンティティよりも重要であると識別される。このような例では、意図選択は、メッセージの意図を判断する際に各エンティティに割り当てられる重みを考慮に入れてもよい。

いくつかの例では、自然言語プロセッサ１５６は、知識パックをインポートおよび／またはエクスポートしてもよい。知識パックは、１つ以上の業種のための１つ以上の意図、１つ以上のドメイン、または１つ以上の意図の他の論理グループを含んでもよい。１つ以上の意図のうちの意図は、１つ以上の例、１つ以上のエンティティ、および／または、意図のためのベクトルを含んでもよい。いくつかの例では、知識パックは、受信された新たなメッセージに基づいて更新されてもよい。いくつかの例では、知識パックは、ボットサーバにわたって維持されてもよく、１つのボットサーバから知識パックへの更新は、他のボットサーバの知識パックに影響を及ぼす。

図２は、自然言語プロセッサを使用してメッセージの意図を識別するためのシステムの一例を示す。メッセージは、ユーザから受信されてもよい。メッセージは、１つ以上の単語を含んでもよい。いくつかの例では、メッセージは、メッセージオブジェクト２１０として格納されてもよい。しかし、メッセージは他の態様または他のデータ構造で格納されてもよいということを当業者は認識するであろう。たとえば、自然言語処理では１つ以上の単語は必要とされないので、メッセージオブジェクト２１０は、１つ以上の単語を含まなくてもよい。

メッセージオブジェクト２１０は、メッセージベクトル２１２と、メッセージに含まれるエンティティ（たとえば、メッセージエンティティ２１４）のリストとを含んでもよい。メッセージベクトル２１２は、上記のように１つ以上の単語および言語モデルを使用してメッセージのために生成されてもよい。メッセージベクトル２１２は、１つ以上の単語の分散表現であってもよい。

上記のように、意図オブジェクト（たとえば、第１の意図オブジェクト２２０、第２の意図オブジェクト２３０および第３の意図オブジェクト２４０）は、意図に関連付けられてもよい。意図オブジェクトは、意図ベクトル（たとえば、第１の意図ベクトル２２２、第２の意図ベクトル２３２および第３の意図ベクトル２４２）を含んでもよい。意図ベクトルは、意図ベクトルに関連付けられた意図に関連付けられるものとして識別される１つ以上の単語の分散表現であってもよい。意図オブジェクトは、意図に関連付けられた１つ以上のエンティティ（たとえば、意図エンティティ）のリストをさらに含んでもよい。意図エンティティの各々は、メッセージエンティティ２１４を追加するためにメッセージの１つ以上の単語と比較されてもよい。

いくつかの例では、メッセージベクトル２１２は、第１の意図オブジェクト２２０、第２の意図オブジェクト２３０および第３の意図オブジェクト２４０の各々と比較されてもよい。このような例では、比較は、ベクトル間の距離（たとえば、コサイン距離またはユークリッド距離）を算出することによって実行されてもよい。意図オブジェクトについての算出された距離が閾値を下回る場合、意図オブジェクトに関連付けられた意図は、メッセージに関連付けられるように判断されてもよい。

いくつかの例では、２つ以上の算出された距離が閾値を下回る場合、意図オブジェクトについての算出された最低距離に関連付けられた意図は、メッセージに関連付けられるように判断されてもよい。他の例では、２つ以上の算出された距離が閾値を下回る場合、メッセージエンティティ２１４が使用されてもよい。たとえば、メッセージエンティティ２１４における大部分のエンティティを有する意図オブジェクトは、最もありそうな意図であると判断されてもよい。このような例では、大部分のエンティティを有する意図オブジェクトに関連付けられた意図は、メッセージに関連付けられるように判断されてもよい。いくつかの例では、メッセージオブジェクト２１０は、メッセージエンティティ２１４を含まなくてもよい。このような例では、メッセージにおけるエンティティは、２つ以上の算出された距離が閾値を下回る場合に識別されてもよい。

図３は、自然言語通信に応答するためのプロセス３００の一例を示すフローチャートである。いくつかの局面では、プロセス３００は、自然言語プロセッサを含むボットサーバによって実行されてもよい。ボットサーバの具体例が示されているが、他のデバイスがプロセス３００に含まれてもよいということが認識されるべきである。

プロセス３００は、論理フロー図として示されており、その動作は、ハードウェア、コンピュータ命令またはそれらの組み合わせで実現可能な一連の動作を表す。コンピュータ命令の文脈においては、動作は、１つ以上のプロセッサによって実行されると記載の動作を実行する、１つ以上のコンピュータ読取可能な記憶媒体に格納されたコンピュータによって実行可能な命令を表す。一般に、コンピュータによって実行可能な命令は、特定の機能を実行するかまたは特定のデータタイプを実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が記載されている順序は、限定的なものとして解釈されるよう意図されるものではなく、いくつもの記載の動作が任意の順序でおよび／または並列に組み合わせられて、プロセスを実現してもよい。

また、プロセス３００は、実行可能な命令で構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で一括して実行されるコード（たとえば、実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として、ハードウェアによって、またはそれらの組み合わせによって実現されてもよい。上記のように、コードは、たとえば１つ以上のプロセッサによって実行可能な複数の命令を備えるコンピュータプログラムの形態で機械読取可能な記憶媒体に格納されてもよい。機械読取可能な記憶媒体は、非一時的であってもよい。

ステップ３１０において、プロセス３００は、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）を有するボットサーバが、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージを受信するステップを含む。ボットサーバは、企業に関連付けられてもよい。いくつかの例では、ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバからＵＲＩに向けられてもよい。このような例では、ＨＴＴＰポストコールメッセージは、ユーザからの内容を含んでもよい。他の例では、内容は、ボットサーバによって、ＨＴＴＰポストコールメッセージ以外のメッセージ（たとえば、リモートサーバから送信されるパケット）の状態で受信されてもよい。いくつかの例では、内容は、１つ以上の単語を含んでもよい。

ステップ３２０において、プロセス３００は、内容のための第１のベクトルを決定するステップをさらに含む。いくつかの例では、第１のベクトルは、内容の分散表現であってもよい。このような例では、第１のベクトルは、複数の第１の要素を含んでもよく、複数の第１の要素のうちの各第１の要素は、言語モデルに従って内容を特徴付ける。いくつかの例では、第１の要素の各要素は、互いに排他的でなくてもよい。

ステップ３３０において、プロセス３００は、ボットサーバに関連付けられた企業のための第２のベクトルを識別するステップをさらに含む。いくつかの例では、第２のベクトルのうちの１つの第２のベクトルは、意図に関連付けられてもよい。このような例では、当該意図は、１つ以上の例によって定義されてもよく、各例は、当該意図に関連しているとして示される１つ以上の単語である。いくつかの例では、第２のベクトルは、１つ以上の例の分散表現であってもよい。このような例では、第２のベクトルは、複数の第２の要素を含んでもよく、複数の第２の要素のうちの各第２の要素は、言語モデルに従って１つ以上の例を特徴付ける。いくつかの例では、第２の要素の各要素は、互いに排他的でなくてもよい。

ステップ３４０において、プロセス３００は、第１のベクトルを第２のベクトルの各々と比較するステップをさらに含む。いくつかの例では、比較するステップは、第１のベクトルと第２のベクトルの各々との間の距離（たとえば、コサイン距離またはユークリッド距離）を算出することを含んでもよい。いくつかの例では、プロセス３００は、内容の中のエンティティを識別するステップをさらに含んでもよい。このような例では、エンティティは、意図に関連付けられるように予め定義されてもよい。ステップ３５０において、プロセス３００は、比較に基づいて内容の意図を判断するステップをさらに含む。いくつかの例では、判断するステップは、エンティティにさらに基づいてもよい。

ステップ３６０において、プロセス３００は、判断された内容の意図に基づいてＨＴＴＰポストコールメッセージに対する応答を送信するステップをさらに含む。たとえば、ボットサーバは、意図オブジェクトに含まれるユーザコードに基づいて応答を生成してもよい。ユーザコードは、意図オブジェクトに関連付けられた意図に関連付けられたメッセージに対する応答の仕方を定義してもよい。

いくつかの例では、プロセス３００は、パッケージを受信するステップをさらに含んでもよい。このような例では、パッケージは、１つ以上の意図を定義してもよい。いくつかの例では、１つ以上の意図のうちの１つの意図は、１つ以上のエンティティを含んでもよい。いくつかの例では、パッケージは、ドメインに関連付けられてもよく、ドメインは、１つ以上の意図を含む。

Ｃ．ダイアログエンジン
上記のように、メッセージプロセッサパイプラインは、ダイアログエンジンを含んでもよい。ダイアログエンジンは、ボットサーバとの会話をオーケストレートしてもよい。いくつかの例では、ダイアログエンジンは、メッセージに応答するためのシステムを構築する宣言的方法であってもよい。

ダイアログエンジンは、自然言語プロセッサから意図の識別を受信してもよい。意図の識別を使用して、ダイアログエンジンは、意図に関連付けられた意図オブジェクトにアクセスすることができる。意図オブジェクトは、意図に関連付けられた１つ以上のエンティティを含んでもよい。いくつかの例では、１つ以上のエンティティの各エンティティは、優先順位を割り当てられてもよい。このような例では、１つ以上のエンティティの少なくとも一部は、必須エンティティであってもよい。必須エンティティは、ダイアログエンジンがユーザとの会話を終了させ得る前にダイアログエンジンが必要とするエンティティであってもよい。

たとえば、ピザアプリケーションは、ピザのサイズおよびタイプを必要としてもよい。このような例では、ダイアログエンジンは、現在の会話の中でユーザが受信した現在のメッセージがピザのサイズおよびタイプを含むか否かを識別してもよい。ユーザが受信した現在のメッセージがピザのサイズおよびタイプを含まない場合、ダイアログエンジンは、以前のメッセージがピザのサイズおよびタイプのうちの少なくとも１つ以上を含むか否かを判断してもよい。ダイアログエンジンがピザのサイズおよび／またはタイプを受信していないと判断する場合、ダイアログエンジンは、欠落している必須エンティティを要求する現在のメッセージに対する応答を生成してもよい。いくつかの例では、欠落している必須エンティティが複数ある場合、ダイアログエンジンは、欠落している必須エンティティのうちの第１の必須エンティティに対する応答を生成し、次いで、後に、欠落している必須エンティティのうちの第２の必須エンティティのためのメッセージを生成してもよい。プロセスは、ダイアログエンジンが全ての必須エンティティを受信するまで継続してもよい。

いくつかの例では、ダイアログエンジンは、会話の終了をもたらす１人以上のユーザとの会話の部分を識別してもよい。次いで、ダイアログエンジンは、会話のターニングポイントを示す会話の識別された部分に基づいて、将来のユーザのために会話を向上させてもよい。いくつかの例では、ダイアログエンジンは、まさに終了しようとしているように思われる会話を識別してもよい（たとえば、会話の中で良くない感情が判断される）。このような例では、ダイアログシステムは、会話の流れを変更してもよく、場合によっては会話を異なるシステムまたはさらには人間にリダイレクトしてもよい。

図４は、メッセージングアプリケーションを使用したモバイルデバイス４１０上のユーザとボットサーバとの間の会話の一例を示す。左側のメッセージ（たとえば、メッセージ４２０，４４０，４６０）は、ユーザからのものであってもよく、右側のメッセージ（たとえば、メッセージ４３０，４５０）は、ボットサーバからのものであってもよい。たとえば、ユーザは、モバイルデバイス４１０にインストールされたメッセージングアプリケーションを使用して第１のメッセージ４２０をメッセージングアプリケーションシステムに送信してもよい。第１のメッセージ４２０は、「ピザをください」という言葉を含んでもよい。第１のメッセージは、メッセージングアプリケーションサーバに送信され、次いで応答のためにボットサーバに送信されてもよい。

上記のように、第１のメッセージ４２０は、ボットサーバの仕組みによってはコネクタまたはロードバランサに到達してもよい。第１のメッセージ４２０は、メッセージ受信キューに入れられ、最終的にはメッセンジャプロセッサパイプラインに送信されてもよい。メッセンジャプロセッサパイプラインでは、第１のメッセージ４２０は、自然言語プロセッサによって解釈されてもよい。自然言語プロセッサは、第１のメッセージ４２０の意図を識別してもよい。たとえば、自然言語プロセッサは、第１のメッセージ４２０がピザを注文しようとしていることを識別してもよい。当該意図は、ダイアログエンジンに送信されてもよい。ダイアログエンジンは、当該意図のための１つ以上の必須エンティティを識別してもよい。たとえば、必須エンティティは、ピザのタイプであってもよい。ダイアログエンジンは、メッセージ（または、以前のメッセージ）がユーザのためのピザのタイプを示したか否かを判断してもよい。ピザのタイプが特定されていないと判断すると、ダイアログエンジンは、ピザのタイプが欠落しているという表示をボットコードに送信してもよい。いくつかの例では、第１のメッセージ４２０は、応答を決定するためにボットコードにも送信されてもよい。

ダイアログエンジンがピザのタイプを欠いているので、ボットコードは、ピザのタイプを要求するための応答を生成してもよい。当該応答は、「どのようなピザがいいですか？」という言葉を第２のメッセージ４３０に含んでもよい。第２のメッセージ４３０は、ボットコードからメッセージ送信キューに送信され、最終的にはコネクタに送信されて、メッセージングアプリケーションサーバを使用してモバイルデバイス４１０にインストールされたメッセージングアプリケーションに戻されてもよい。モバイルデバイス４１０にインストールされたメッセージングアプリケーションは、第２のメッセージ４３０を受信して、図４に示されるように第２のメッセージ４３０を表示してもよい。

第２のメッセージ４３０を受信した後、ユーザは、モバイルデバイス４１０上のメッセージングアプリケーションを使用して第３のメッセージ４４０をボットサーバに送信してもよい。第３のメッセージ４４０は、「ピザをください」という言葉を含んでもよい。ボットサーバは、第３のメッセージの内容および第３のメッセージの文脈に基づいて、第３のメッセージ４４０が新たなセッションであることを判断してもよい。たとえば、ユーザが第２のメッセージ４３０を受信してからユーザが第３のメッセージ４４０を送信するまで時間が経過していてもよい。

自然言語プロセッサは、第３のメッセージ４４０の意図を識別してもよい。たとえば、自然言語プロセッサは、第３のメッセージ４４０がピザを注文しようとしていることを識別してもよい。当該意図は、ダイアログエンジンに送信されてもよい。ダイアログエンジンは、当該意図のための１つ以上の必須エンティティを識別してもよい。たとえば、必須エンティティは、ピザのタイプであってもよい。ダイアログエンジンは、メッセージ（または、以前のメッセージ）が現在のセッションでユーザのためのピザのタイプを示したか否かを判断してもよい。ピザのタイプが特定されていないと判断すると、ダイアログエンジンは、ピザのタイプが欠落しているという表示をボットコードに送信してもよい。いくつかの例では、第３のメッセージ４４０は、応答を決定するためにボットコードにも送信されてもよい。ボットサーバは、（たとえば、どのようなピザがいいか尋ねる第４のメッセージ４５０を送信することによって）第１のメッセージ４２０と同様に第３のメッセージ４４０に応答してもよい。

ユーザは、ユーザが望むピザのタイプを含む第５のメッセージ４６０によって第４のメッセージ４５０に応答してもよい。ボットサーバは、上記のように第５のメッセージ４６０を受信してもよい。しかし、第５のメッセージ４６０のための新たなセッションを作成するのではなく、ボットサーバは、第５のメッセージ４６０が第３のメッセージ４４０および第４のメッセージ４５０を含む会話の一部であることを判断してもよい。ボットサーバがこれら３つのメッセージをグループ化することによって、ボットサーバのボットコードは、第３、第４および第５のメッセージを一緒に分析することによって第５のメッセージ４６０に対する応答の仕方を決定してもよい。いくつかの例では、意図は、１つの必須エンティティ（たとえば、ピザのタイプ）を含んでもよい。このような例では、ピザのタイプが示された後に、ボットサーバは、ユーザとの会話を終了させてもよい。

図５は、ユーザから追加情報を要求するための応答を送信するためのプロセスの一例を示すフローチャートである。いくつかの局面では、プロセス５００は、ボットサーバによって実行されてもよい。ボットサーバの具体例が示されているが、他のデバイスがプロセス５００に含まれてもよいということが認識されるべきである。

プロセス５００は、論理フロー図として示されており、その動作は、ハードウェア、コンピュータ命令またはそれらの組み合わせで実現可能な一連の動作を表す。コンピュータ命令の文脈においては、動作は、１つ以上のプロセッサによって実行されると記載の動作を実行する、１つ以上のコンピュータ読取可能な記憶媒体に格納されたコンピュータによって実行可能な命令を表す。一般に、コンピュータによって実行可能な命令は、特定の機能を実行するかまたは特定のデータタイプを実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が記載されている順序は、限定的なものとして解釈されるよう意図されるものではなく、いくつもの記載の動作が任意の順序でおよび／または並列に組み合わせられて、プロセスを実現してもよい。

また、プロセス５００は、実行可能な命令で構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で一括して実行されるコード（たとえば、実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として、ハードウェアによって、またはそれらの組み合わせによって実現されてもよい。上記のように、コードは、たとえば１つ以上のプロセッサによって実行可能な複数の命令を備えるコンピュータプログラムの形態で機械読取可能な記憶媒体に格納されてもよい。機械読取可能な記憶媒体は、非一時的であってもよい。

ステップ５１０において、プロセス５００は、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）に関連付けられたボットサーバが、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージを受信するステップを含む。いくつかの例では、ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバからＵＲＩに向けられてもよい。このような例では、ＨＴＴＰポストコールメッセージは、ユーザからの内容（たとえば、テキスト、絵文字、音声、画像、ビデオ、またはメッセージを伝える他の方法）を含んでもよい。他の例では、内容は、ボットサーバによって、ＨＴＴＰポストコールメッセージ以外のメッセージ（たとえば、リモートサーバから送信されるパケット）の状態で受信されてもよい。いくつかの例では、内容は、複数の単語を含んでもよい。

ステップ５２０において、プロセス５００は、内容の意図を識別するステップをさらに含む。内容の意図は、上記のように識別されてもよい。ステップ５３０において、プロセス５００は、識別された意図に関連付けられた１つ以上の必須エンティティを識別するステップをさらに含む。いくつかの例では、識別された意図は、意図オブジェクトに関連付けられてもよい。意図オブジェクトは、１つ以上のエンティティを含んでもよい。１つ以上のエンティティの各々は、優先順位を含んでもよい。優先順位は、１つ以上のエンティティの１つ以上の必須エンティティを示してもよい。ステップ５４０において、プロセス５００は、内容から欠落している１つ以上の必須エンティティのうちの１つの必須エンティティを識別するステップをさらに含む。

ステップ５５０において、プロセス５００は、ＨＴＴＰポストコールメッセージに対する応答を生成するステップをさらに含む。いくつかの例では、当該応答は、欠落している必須エンティティを要求してもよい。ステップ５６０において、プロセス５００は、ＨＴＴＰポストコールメッセージに対する応答をメッセージングアプリケーションサーバに送信するステップをさらに含む。

Ｄ．イベントデータ
１．イベントデータを管理するためのシステム
ウェブページまたはモバイルアプリケーションに関連付けられたイベントデータは、ストレージサーバに送信されて格納されてもよい。イベントデータは、ウェブページおよび／またはモバイルアプリケーションに関連して実行される１つ以上のアクションを表してもよい。たとえば、イベントデータは、上記のようにボットサーバが受信するメッセージを含んでもよい。イベントデータは、メッセージに対する応答も含んでもよい。いくつかの例では、イベントデータは、使用のために処理されていない生データであってもよい。ストレージサーバのキューがイベントデータを受信してもよい。当該キューは、メッセージ受信キューに関して上記したものと同様であってもよい。いくつかの例では、イベントデータは、イベントデータに関連付けられたイベントが発生するとストリーミングの態様でキューによって受信されてもよい。

第１の実行プロセス（たとえば、スパークエグゼキュータ）は、キューからイベントデータを引き出して、それをローカルデータベースに格納してもよい。ローカルデータベースは、ストレージサーバに含まれてもよい。ローカルデータベースは、期間別に分割されるスキーマを有してもよい。たとえば、ローカルデータベースは、日別に分割されてもよい。日別の分割は、入来するイベントデータをパーティション（または、ローカルデータベース内の場所（たとえば、ファイル））に入れることができることを意味し得る。当該パーティションは、ローカルデータベースが一定量のデータのみを維持するように毎日削除されてもよい。

第１の実行プロセスは、ローカルデータベースに格納する前にイベントデータに対して１つ以上の強化動作を実行してもよい。イベントデータを強化することは、イベントデータを向上、改良、または他の態様で改善することを含んでもよい。たとえば、強化することは、スペルミスまたは誤字を修正してもよい。

第１の実行プロセスは、強化されたデータをキューに戻してもよい。他の例では、第１の実行プロセスは、強化されたデータを、第１のキューと同様であってもよい第２のキューに送信してもよい。第２の実行プロセスは、キュー（または、第２のキュー）から強化されたデータを引き出して、それをリモートファイルシステムに格納してもよい。リモートファイルシステムは、ストレージサーバとは別であってもよい。

リモートファイルシステムは、強化されたデータをデータベース（たとえば、１つ以上のハイブテーブル）に書き込んでもよい。１つ以上のハイブテーブルは、リモートファイルシステムにおいて１つ以上の外部テーブルとして具体化されてもよい。１つ以上の外部テーブルは、ローカルデータベースと結合されて、ストレージサーバが受信した全てのイベントデータを含むように仮想データベースを作成してもよい。

仮想データベースが照会されると、１つ以上の外部テーブルおよび／またはローカルデータベースは、イベントデータを受信するようにアクセスされてもよい。いくつかの例では、仮想データベースは、どこに照会すべきかを判断してもよい。このような例では、仮想データベースは、要求されるデータが別々のデータベースに含まれる場合、クエリを２つ以上のクエリに分けてもよい。いくつかの例では、仮想データベースは、仮想データベースに照会するユーザに対して、１つ以上の外部テーブルおよびローカルデータベースが１つのデータベースであるように見せてもよい。いくつかの例では、仮想データベースは、ローカルデータベース内に定義されてもよい。

図６は、イベントデータを管理するためのシステムの一例を示す。当該システムは、ストレージサーバ６３０とリモートファイルシステム６８０とを含んでもよい。ストレージサーバ６３０は、キュー６４０を含んでもよい。キュー６４０は、モバイルアプリケーション６１０および／またはウェブページ６２０のうちの１つ以上からイベントデータを受信してもよい。イベントデータは、他のソースからのものであってもよいということが認識されるべきである。

ストレージサーバ６３０は、第１の実行プロセス６５０をさらに含んでもよい。第１の実行プロセス６５０は、キュー６４０からイベントデータを引き出して、ローカルデータベース６６０に格納してもよい。いくつかの例では、第１の実行プロセス６５０は、イベントデータがローカルデータベース６６０に格納される前に、キュー６４０から引き出されたイベントデータを強化してもよい。このような例では、強化されたデータは、ローカルデータベース６６０に格納されてもよい。いくつかの例では、イベントデータを強化した後に、第１の実行プロセス６５０は、強化されたデータをキュー６４０に送信してもよい。他の例では、イベントデータを強化した後に、第１の実行プロセス６５０は、強化されたデータを第２のキュー（図示せず）に送信してもよい。

ローカルデータベース６６０は、１つ以上のパーティションを含んでもよい。各パーティションは、特徴に従ってデータを格納するために使用されてもよい。たとえば、第１のパーティションは、第１のユーザからのイベントデータを格納してもよい。このような例では、第２のパーティションは、第２のユーザからのイベントデータを格納してもよい。また、ローカルデータベース６６０は、期間別に分割されてもよい。このような例では、ローカルデータベース６６０は、スケジュールに基づいて、ローカルデータベース６６０に含まれるイベントデータを削除してもよい。たとえば、ローカルデータベース６６０は、毎日イベントデータを削除してもよい。

いくつかの例では、ストレージサーバ６３０は、第２の実行プロセス６７０をさらに含んでもよい。第２の実行プロセス６７０は、キュー６４０（または、第２のキュー）から強化されたイベントデータ（または、単なるイベントデータ）を引き出して、リモートファイルシステム６８０に格納してもよい。

リモートファイルシステム６８０は、ストレージサーバ６３０とは別であってもよい。リモートファイルシステム６８０は、イベントデータを格納するためのリモートデータベース６９０を含んでもよい。

図７は、仮想データベース７６２の一例を示す。仮想データベース７６２は、（ローカルデータベース６６０と同様の）ローカルデータベース７６０および（リモートデータベース６９０と同様の）リモートデータベースのためのインターフェイスとしての役割を果たしてもよい。仮想データベース７６２は、アプリケーションプログラムインターフェイスを公開して、仮想データベース７６２にアクセスするためのクエリ（たとえば、クエリ７６４）をユーザから受信してもよい。クエリ７６４は、まるでデータが仮想データベース７６２上にあるかのように呼び出されてもよい。いくつかの例では、仮想データベース７６２は、クエリ７６４によって要求されたデータの場所を識別して、ローカルデータベース７６０および／またはリモートデータベース７９０からのデータに対する１つ以上のクエリを作成してもよい。このような例では、仮想データベース７６２は、ローカルデータベース７６０および／またはリモートデータベース７９０からデータを受信して、当該データによってクエリ７６４に応答してもよい。

２．マテリアライズドビュー
いくつかの例では、上記のストレージサーバは、カスタマー・インサイツ・アンド・エンゲージメント・クラウド・サービス（Customer Insights & Engagement Cloud Service：ＣＩＥＣＳ）に含まれてもよい。ＣＩＥＣＳは、ストレージサーバに格納された情報を分析してもよい。いくつかの例では、ＣＩＥＣＳは、ソース（たとえば、ウェブページおよび／またはモバイルアプリケーション）のための挙動分析を実行してもよい。このような例では、挙動分析は、関与（たとえば、ユーザの活動レベル）、コホート分析（たとえば、ユーザの記憶力）、および顧客離れ予測（たとえば、戻ってこない危険性があるユーザの識別）を含むソースとのインタラクションを分析してもよい。いくつかの例では、ＣＩＥＣＳは、ａ／ｂテスト（たとえば、さまざまなユーザでのさまざまなレイアウトのテスト）、ユーザ／セッション分析（たとえば、ユーザのためのセッションに関連付けられた情報の識別）、および予測分析（たとえば、サンプルに基づく、全てのデータに関連付けられ得る推測の識別）を行ってもよい。

いくつかの例では、イベントデータに対して実行される分析は、一定時間でクエリを使用して計算されてもよい。このような例では、クエリが現在時刻の一定時間前からのデータを要求しているので、クエリ自体は変化しなくてもよい。しかし、クエリから返されるデータは変化する可能性がある。たとえば、１時間前からのデータに対するクエリは、クエリがいつ実行されるかによって異なるデータを返してもよい。

一定時間にわたってクエリを最適化するために、データベースの前に（たとえば、図６に示されるローカルデータベース６６０の前に）マテリアライズドビューが作成されてもよい。マテリアライズドビューは、ストレージサーバが受信するイベントデータを表す１つ以上の概要計算値を含んでもよい。このような例では、新たなイベントデータが受信されて当該新たなイベントデータがデータベースに追加されると、以前のイベントデータにアクセスしなくてもいいように概要計算値はインクリメンタルに更新されてもよい。その代わりに、概要計算値に使用される１つ以上の概要値、または概要計算値自体が、保存されて、新たなイベントデータが受信されるとインクリメンタルに更新されてもよい。このような例では、イベントデータは、概要計算値のために保存されない。

たとえば、概要計算値は、新たなデイリーユーザの数であってもよい。現在日からイベントデータに照会しなければならないのではなく、新たなデイリーユーザの数を示す概要値がマテリアライズドビューによって保存されてもよい。当該概要値は、新たなイベントデータが新たなユーザを示すとインクリメントされてもよい。

いくつかの例では、マテリアライズドビューの１つ以上の概要計算値は、スケジュールに従って更新されてもよい。たとえば、新たなイベントデータが受信されると概要計算値を更新するのではなく、概要計算値は毎時に更新されてもよい。スケジュールに従った更新の恩恵を受けることができる概要計算値の一例は、ファンネル認識である。ファンネルは、複数の必要なアクションが順番に起こる場合に生じてもよく、各アクションは、以前のアクションから一定時間以内に起こる。たとえば、ファンネルは、ユーザがアイテムを選択して当該アイテムを購入することを必要としてもよい。このような例では、ファンネルは、両方のアクションが一緒に起こったときにのみ、特定の時間以内に識別されるであろう。このような例では、ファンネルが生じたか否かを判断するためのクエリは、シングルユーザによる複数のイベントの検索を含んでもよい。そして、当該イベントは、個々のイベントではなくイベントのコレクションとしてアクセスされる必要があるだろう。

図８は、仮想データベースにアクセスするための呼び出し可能な方法を公開するためのプロセスの一例を示すフローチャートである。いくつかの局面では、プロセス８００は、ストレージサーバによって実行されてもよい。ストレージサーバの具体例が示されているが、他のデバイスがプロセス８００に含まれてもよいということが認識されるべきである。

プロセス８００は、論理フロー図として示されており、その動作は、ハードウェア、コンピュータ命令またはそれらの組み合わせで実現可能な一連の動作を表す。コンピュータ命令の文脈においては、動作は、１つ以上のプロセッサによって実行されると記載の動作を実行する、１つ以上のコンピュータ読取可能な記憶媒体に格納されたコンピュータによって実行可能な命令を表す。一般に、コンピュータによって実行可能な命令は、特定の機能を実行するかまたは特定のデータタイプを実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が記載されている順序は、限定的なものとして解釈されるよう意図されるものではなく、いくつもの記載の動作が任意の順序でおよび／または並列に組み合わせられて、プロセスを実現してもよい。

また、プロセス８００は、実行可能な命令で構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で一括して実行されるコード（たとえば、実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として、ハードウェアによって、またはそれらの組み合わせによって実現されてもよい。上記のように、コードは、たとえば１つ以上のプロセッサによって実行可能な複数の命令を備えるコンピュータプログラムの形態で機械読取可能な記憶媒体に格納されてもよい。機械読取可能な記憶媒体は、非一時的であってもよい。

ステップ８１０において、プロセス８００は、ストレージサーバが、ソースに関連付けられたイベントデータを受信するステップを含む。いくつかの例では、ソースは、モバイルアプリケーションまたはウェブページであってもよい。このような例では、イベントデータは、ソースに関連する１つ以上のアクションを表してもよい。

ステップ８２０において、プロセス８００は、イベントデータがストレージサーバによって受信されるとイベントデータをローカルデータベース内のある場所に格納するステップをさらに含む。いくつかの例では、ストレージサーバは、ローカルデータベースを含んでもよい。このような例では、当該場所におけるデータは、第１のスケジュールに従って削除される。第１のスケジュールの一例は、毎日であってもよい。

ステップ８３０において、プロセス８００は、第２のスケジュールに従ってイベントデータをリモートデータベースに格納するステップをさらに含む。いくつかの例では、リモートデータベースは、ストレージサーバとは別であってもよい。このような例では、第１のスケジュールは、第２のスケジュールよりも頻度が低くてもよい。第２のスケジュールの一例は、１時間ごとであってもよい。いくつかの例では、リモートファイルシステムは、リモートデータベースを含んでもよい。

ステップ８４０において、プロセス８００は、仮想データベースに照会するための第１の呼び出し可能な方法をクライアントアプリケーションに公開するステップをさらに含む。いくつかの例では、第１の呼び出し可能な方法を使用したイベントデータに対するクエリは、イベントデータがローカルデータベース内にあるときにはイベントデータをローカルデータベースから取り出してもよい。このような例では、当該クエリは、イベントデータがローカルデータベースから削除された後はイベントデータをリモートデータベースから取り出してもよい。

ステップ８５０において、プロセス８００は、イベントデータに基づいて概要計算値を計算するステップをさらに含む。いくつかの例では、概要計算値は、イベントデータがストレージサーバによって受信されるとインクリメンタルに更新されてもよい。このような例では、概要計算値は、イベントデータについてデータベースに照会する必要なしにインクリメンタルに更新されてもよい。他の例では、概要計算値は、第３のスケジュールに従ってインクリメンタルに更新されてもよい。一例では、第３のスケジュールは、１時間ごとであってもよい。概要計算値は、ローカルデータベースに現在格納されているデータおよびリモートデータベースに現在格納されているデータに基づいてもよい。概要計算値は、現在時刻の一定時間前からのデータに基づいてもよい。

図９は、サーバ９１２の一例を示す。サーバ９１２は、コンポーネント９１８，９２０，９２２を含む。サーバ９１２は、参照番号９０２，９０４，９０６，９０８と通信している。サーバ９１２は、データリポジトリ９１４およびデータリポジトリ９１６とも通信している。
図１０は、クラウドインフラストラクチャシステム１００２の一例を示す。クラウドインフラストラクチャシステムは、ユーザインターフェイスサブシステム１０１２と、オーダー管理サブシステム１０２０と、オーダープロビジョニングサブシステム１０２４と、アイデンティティ管理１０２８と、インフラストラクチャリソース１０３０と、内部共有サービス１０３２とを含む。ユーザインターフェイスサブシステム１０１２は、ウェブＵＩ１０１４と、オンラインストアＵＩ１０１６と、他のＵＩＳ１０１８とを含む。クライアントデバイス１００４は、ネットワーク１０１０を介してサービス要求（ＳＲ）１０３４をクラウドインフラストラクチャシステム１００２に送信する。クラウドインフラストラクチャシステム１００２は、応答１０４４をクライアントデバイス１００４に送信する。クライアントデバイス１００６は、ネットワーク１０１０を介してＳＲ１０３４をクラウドインフラストラクチャシステム１００２に送信する。クラウドインフラストラクチャシステム１００２は、応答１０４４をクライアントデバイス１００６に送信する。クライアントデバイス１００８は、ネットワーク１０１０を介してＳＲ１０３４をクラウドインフラストラクチャシステム１００２に送信する。クラウドインフラストラクチャシステム１００２は、応答１０４４をクライアントデバイス１００８に送信する。
図１１は、コンピュータシステム１１００の一例を示す。コンピュータシステム１１００は、処理サブシステム１１０４と、処理加速ユニット１１０６と、Ｉ／Ｏサブシステム１１０８と、ストレージサブシステム１１１８と、通信サブシステム１１２４と、データフィード１１２６と、イベントストリーム１１２８と、イベント更新情報１１３０とを含む。処理サブシステム１１０４は、処理ユニット１１３２と、処理ユニット１１３４とを含む。ストレージサブシステム１１１８は、システムメモリ１１１０と、コンピュータ読取可能記憶媒体リーダ１１２０と、コンピュータ読取可能な記憶媒体１１２２とを含む。システムメモリ１１１０は、アプリケーションプログラム１１１２と、プログラムデータ１１１４と、オペレーティングシステム１１１６とを含む。通信サブシステム１１２４は、コンピュータシステム１１００の外部と通信する。通信サブシステム１１２４は、データフィード１１２６、イベントストリーム１１２８およびイベント更新情報１１３０とも通信する。通信サブシステム１１２４は、処理サブシステム１１０４、処理加速ユニット１１０６、Ｉ／Ｏサブシステム１１０８およびストレージサブシステム１１１８とも通信する。処理サブシステム１１０４、処理加速ユニット１１０６、Ｉ／Ｏサブシステム１１０８およびストレージサブシステム１１１８および通信サブシステム１１２４は、各々が互いに通信する。
上記の明細書では、本開示の局面をその具体例を参照して説明しているが、本開示はそれに限定されるものではないということを当業者は認識するであろう。上記の例のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。さらに、明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されているものを越えるいくつもの環境および用途で例が利用されてもよい。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。

説明の目的で、方法は、ある特定の順序で記載された。代替例では当該方法は記載されている順序とは異なる順序で実行されてもよい、ということが理解されるべきである。また、上記の方法はハードウェアコンポーネントによって実行されてもよく、または機械によって実行可能な一連の命令で実施されてもよく、当該機械によって実行可能な命令を使用して、命令でプログラミングされた汎用もしくは特殊目的プロセッサまたは論理回路などの機械に方法を実行させてもよい、ということが理解されるべきである。これらの機械によって実行可能な命令は、ＣＤ－ＲＯＭもしくは他のタイプの光ディスク、フロッピー（登録商標）ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、フラッシュメモリ、または電子命令を格納するのに適した他のタイプの機械読取可能な媒体などの１つ以上の機械読取可能な媒体に格納されてもよい。代替的に、当該方法は、ハードウェアとソフトウェアとの組み合わせによって実行されてもよい。

構成要素は、特定の動作を実行するように構成されるものとして記載されているが、このような構成は、たとえば動作を実行するように電子回路もしくは他のハードウェアを設計することによって、動作を実行するようにプログラム可能な電子回路（たとえば、マイクロプロセッサまたは他の好適な電子回路）をプログラミングすることによって、またはそれらの任意の組み合わせによって、実現されてもよい。

本願の例示的な例について本明細書で詳細に説明したが、本発明の概念は、その他の態様でさまざまに実施され利用されてもよく、添付の特許請求の範囲は、先行技術によって限定されるものを除いてこのような変形例を含むものとして解釈されるよう意図される、ということが理解される。

Claims (14)

1. 自然言語通信に応答するための方法であって、
   ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）によって識別されるサーバが、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージを受信するステップを備え、前記ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバから前記ＵＲＩに向けられ、前記ＨＴＴＰポストコールメッセージは、ユーザからの内容を含み、前記サーバには、特定の企業が関連付けられ、前記方法はさらに、
   前記内容のための第１のベクトルと、前記特定の企業のために識別された複数の第２のベクトルの各々との比較に基づいて前記内容の意図を識別するステップと、
   前記識別された意図に関連付けられた１つ以上の必須エンティティを識別するステップと、
   前記内容から欠落している前記１つ以上の必須エンティティのうちの１つの必須エンティティを識別するステップと、
   前記ＨＴＴＰポストコールメッセージに対する応答を生成するステップとを備え、前記応答は、前記欠落している必須エンティティを要求し、前記方法はさらに、
   前記ＨＴＴＰポストコールメッセージに対する前記応答を前記メッセージングアプリケーションサーバに送信するステップを備え、
   前記複数の第２のベクトルの少なくとも１つは、前記識別された意図に関連付けられている、方法。
2. 前記内容は、１つ以上の単語を含む、請求項１に記載の方法。
3. 前記意図は、前記ユーザが前記内容を前記サーバに送信した目的であり、前記意図は、前記ユーザと前記サーバとの間の会話を定義する、請求項１または２に記載の方法。
4. 前記意図に関連付けられたセッションは、前記サーバが前記１つ以上の必須エンティティの各々の入力を前記ユーザから受信すると完了する、請求項１～３のいずれかに記載の方法。
5. 前記意図に関連付けられたセッションを格納するステップをさらに備え、前記セッションは、前記ユーザから受信される情報を含む、請求項１～４のいずれかに記載の方法。
6. 前記内容の前記意図を識別するステップに応答して、前記サーバが前記情報にアクセスできるように、前記意図に関連付けられた前記セッションを取得するステップをさらに備える、請求項５に記載の方法。
7. 前記意図は、複数のエンティティを含み、前記複数のエンティティのうちの各エンティティは、優先順位を割り当てられ、前記優先順位は、前記エンティティが必須エンティティであるか否かを示す、請求項１～６のいずれかに記載の方法。
8. システムであって、
   １つ以上のプロセッサと、
   命令を含む非一時的なコンピュータ読取可能な媒体とを備え、前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに動作を実行させ、前記動作は、
   ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）ポストコールメッセージを受信するステップを含み、前記システムは、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ）によって識別され、前記ＨＴＴＰポストコールメッセージは、メッセージングアプリケーションサーバから前記ＵＲＩに向けられ、前記ＨＴＴＰポストコールメッセージは、ユーザからの内容を含み、前記システムには、特定の企業が関連付けられ、前記動作はさらに、
   前記内容のための第１のベクトルと、前記特定の企業のために識別された複数の第２のベクトルの各々との比較に基づいて前記内容の意図を識別するステップと、
   前記識別された意図に関連付けられた１つ以上の必須エンティティを識別するステップと、
   前記内容から欠落している前記１つ以上の必須エンティティのうちの１つの必須エンティティを識別するステップと、
   前記ＨＴＴＰポストコールメッセージに対する応答を生成するステップとを含み、前記応答は、前記欠落している必須エンティティを要求し、前記動作はさらに、
   前記ＨＴＴＰポストコールメッセージに対する前記応答を前記メッセージングアプリケーションサーバに送信するステップを含み、
   前記複数の第２のベクトルの少なくとも１つは、前記識別された意図に関連付けられている、システム。
9. 前記内容は、１つ以上の単語を含む、請求項８に記載のシステム。
10. 前記意図は、前記ユーザが前記内容を前記システムに送信した目的であり、前記意図は、前記ユーザと前記システムとの間の会話を定義する、請求項８または９に記載のシステム。
11. 前記意図に関連付けられたセッションは、前記システムが前記１つ以上の必須エンティティの各々の入力を前記ユーザから受信すると完了する、請求項８～１０のいずれかに記載のシステム。
12. 前記非一時的なコンピュータ読取可能な媒体は、命令をさらに含み、前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに動作を実行させ、前記動作は、
    前記意図に関連付けられたセッションを格納するステップを含み、前記セッションは、前記ユーザから受信される情報を含み、前記動作はさらに、
    前記内容の前記意図を識別するステップに応答して、前記システムが前記情報にアクセスできるように、前記意図に関連付けられた前記セッションを取得するステップを含む、請求項８～１１のいずれかに記載のシステム。
13. 前記意図は、複数のエンティティを含み、前記複数のエンティティのうちの各エンティティは、優先順位を割り当てられ、前記優先順位は、前記エンティティが必須エンティティであるか否かを示す、請求項８～１２のいずれかに記載のシステム。
14. 請求項１～７のいずれかに記載の方法をコンピュータに実行させるためのコンピュータプログラム。

Images