(57)【要約】【課題】ウェブＡＰＩ仕様からチャット・ボットを生成する方法、システム、およびコンピュータ・プログラムを提供する。【解決手段】ユーザとの対話を実行し、ＡＰＩ仕様に記載されるＡＰＩコールを呼び出すための、チャット・ボットを、ＡＰＩ仕様から自動的に生成する。入力されたＡＰＩ仕様に基づいて、対話フローを表す会話ボット仕様を構築する。自然言語表現を、受け取り、会話ボット仕様に基づいて命令に変換する。命令に基づいて、ユーザに対する自然言語プロンプト、およびＡＰＩコールを呼び出すための実行可能コンピュータ・コードを生成することができる。【選択図】図８
2020532011.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのハードウェア・プロセッサによって実行される、アプリケーション・プログラミング・インタフェース（ＡＰＩ）の会話ボットを自動的に生成する方法であって、
ＡＰＩコールの呼出しに関連する情報を含むＡＰＩ仕様を受け取るステップと、
前記ＡＰＩ仕様を構文解析するステップと、
前記ＡＰＩ仕様の構文解析に基づいて、会話ボット仕様を構築するステップと、
ユーザから自然言語表現を受け取るステップと、
前記会話ボット仕様に基づいて、前記自然言語表現を命令に変換するステップと、
前記命令が前記ユーザに提示されるプロンプトを含むとの決定に応答して、前記命令に基づいて、自然言語プロンプトを生成するステップと、
前記命令が前記ＡＰＩコールの実行を含むとの決定に応答して、前記命令に基づいて、前記ＡＰＩコールを呼び出すためのコンピュータ・コードを実行するステップと、
を含む、方法。
【請求項２】
前記ユーザから前記自然言語表現を受け取る前記ステップ、前記自然言語表現を命令に変換する前記ステップ、前記自然言語プロンプトを生成する前記ステップ、および前記自然言語プロンプトを前記ユーザに対して提示するステップを、前記会話ボット仕様に基づいて反復して、前記ＡＰＩコールを呼び出す対話フローを実行する、請求項１に記載の方法。
【請求項３】
前記ＡＰＩコールを呼び出すための前記コンピュータ・コードが、前記ＡＰＩコールに関連するサービスを提供するサービス・エンドポイントへのハイパーテキスト転送プロトコル（ＨＴＴＰ）コールを含む、請求項１に記載の方法。
【請求項４】
前記ＡＰＩ仕様が、ウェブＡＰＩ仕様を含む、請求項１に記載の方法。
【請求項５】
前記自然言語プロンプトの生成に応答して、前記自然言語プロンプトを前記ユーザに対して提示するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記会話ボット仕様を構築する前記ステップが、複数の状態および状態遷移を含む有限状態機械（ＦＳＭ）を構築するステップを含み、前記有限状態機械が、前記会話ボットの対話フローを指定し、前記自然言語表現を命令に変換する前記ステップが、自然言語処理に少なくとも基づいて前記自然言語表現をシンボルに変換するステップと、前記ＦＳＭに基づいて前記シンボルを前記命令に変換するステップとを含み、シンボルが、前記自然言語表現中のオブジェクトを表すエンティティと、前記自然言語表現中の目的を表すインテントとを含む、請求項１に記載の方法。
【請求項７】
前記会話ボット仕様が、複数のＡＰＩコールを呼び出すことを含み、前記複数のＡＰＩコールが、１つの対話内で呼び出される、請求項１に記載の方法。
【請求項８】
請求項１ないし７のいずれかに記載の方法の全てのステップを実行するように適応された手段を含む、システム。
【請求項９】
コンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ・システム上で実行されたときに請求項１ないし７のいずれかに記載の方法の全てのステップを実行する命令を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、一般に、コンピュータおよびコンピュータ・アプリケーションに関し、さらに詳細には、チャット・ボット（chat bot）またはロボット、自然言語処理、およびチャット・ボットの生成に関する。
【背景技術】
【０００２】
チャット・ボット、または会話（conversation）エージェントは、自然言語対話（dialogue）を介してユーザと通信するものであり、ウェブ・ページ、電話、またはメッセージング・システムを通して動作することができる。例えば、チャット・ボットは、よくある質問に回答する、あるいはウェブ・ページをより効率的に移動する、またはオンライン・フォームを記入するのを助けるようにプログラムされる。企業は、例えば顧客および従業員などのユーザに対してサポートおよびサービスを提供するのに、ますますチャット・ボットに依拠するようになっている。
【０００３】
グラフィック・アプリケーションと同様に、チャット・ボットは、ウェブのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を呼び出すことによって、作業を実施する。これらのＡＰＩは、企業のデータベースに格納されているリソース、および企業のシステム内で実施されるアクションにユーザがアクセスできるようにする。ウェブＡＰＩを提供する手法の１つは、ＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）である。ＲＥＳＴでは、サービス提供者がリソースをホスティングし、サービス提供者と顧客とが、リソースの状態の表現（通常はＪＳＯＮ、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）を転送することによって対話する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
チャット・ボットは、構築が困難であり、チャット・ボットを正しく実施するには時間がかかる。他のソフトウェアとは異なり、チャット・ボットは、ＮＬＵ（自然言語理解）に依存しており、ＮＬＵは、完璧ではない可能性がある。一般的なＮＬＵの間違いがどのようなものであるかを予測することは難しいので、初期ボットを素早く展開し、その初期ボットによって現場で経験を収集して、初期ボットを改良することは有効である。チャット・ボット開発は、ソフトウェア開発と機械学習技能の両方を必要とするために、さらに複雑化している。また、企業がチャット・ボットを広く取り入れるようになったのはごく最近であるため、非熟練者がチャット・ボットを開発するためのプログラミング・モデルがない。
【課題を解決するための手段】
【０００５】
アプリケーション・プログラミング・インタフェース（ＡＰＩ）用の会話ボットを自動的に生成する方法、システム、およびコンピュータ・プログラムを提供する。
【０００６】
更なる特徴、ならびに様々な実施形態の構造および動作について、以下で添付の図面を参照して詳細に説明する。図面においては、同じ参照番号は、同じ、または機能的に類似している要素を示している。
【図面の簡単な説明】
【０００７】
【図１】１実施形態における例を含むボットの全体的な手法を示す図である。
【図２】１実施形態におけるボットの実行時アーキテクチャを示す図である。
【図３】１実施形態における、ボット・コンパイラが例示的なトランスレータ・アプリケーション・プログラミング・インタフェースから生成する有限状態機械の抜粋を示す図である。
【図４】１実施形態における例示的な視覚認識ウェブ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）との例示的な対話を示す図である。
【図５】１実施形態における例示的な視覚認識ウェブ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）との例示的な対話を示す図である。
【図６】１実施形態における例示的な視覚認識ウェブ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）との例示的な対話を示す図である。
【図７】１実施形態における例示的な視覚認識ウェブ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）との例示的な対話を示す図である。
【図８】１実施形態におけるアプリケーション・プログラミング・インタフェース（ＡＰＩ）の会話ボットを自動的に生成する方法を示す図である。
【図９】本開示の１実施形態における、チャット・ボット生成／コンパイル・システムを実装することができる例示的なコンピュータまたは処理システムを示す概略図である。
【発明を実施するための形態】
【０００８】
ウェブＡＰＩ仕様（API specification）を取り込み、チャット・ボットを自動的に生成してユーザとの対話を実行し、例えば対話およびＡＰＩ仕様に基づくウェブＡＰＩを呼び出すなど、その対話に基づく１回また複数回の１つまたは複数のＡＰＩコールを行うコンパイラのシステム、方法、および技術を提供する。１実施形態では、生成されるボットは、ＡＰＩ仕様の記述を使用してヘルプ要求に回答する、自己文書化型である。１実施形態におけるシステム、方法、および技術は、ウェブＡＰＩ仕様からチャット・ボットを生成する。
【０００９】
ＡＰＩ仕様は、サービスを呼び出すＡＰＩへの標準的なインタフェースを定義する。ＡＰＩ仕様の例には、ＳＷＡＧＧＥＲ仕様が含まれる。以下の説明では、ＳＷＡＧＧＥＲを例示的なＡＰＩ仕様として使用して、１実施形態におけるコンパイラの実施態様を説明する。ただし、本開示の方法は、ＡＰＩ仕様をＳＷＡＧＧＥＲのみに限定するものではない。ＳＷＡＧＧＥＲは、ＡＰＩ文書、クライアントＳＤＫ（ソフトウェア開発キット）、サーバ・スタブ、およびテストなど様々なアーチファクトを生成するためのソース言語として利用されるが、これまではチャット・ボットの生成には使用されていない。１実施形態における本開示の方法は、ＳｗａｇｇｅｒなどのＡＰＩ仕様を、エンド・ユーザが自然言語対話を介してウェブＡＰＩを呼び出すことを可能にするチャット・ボットを生成するためのソース言語として使用することができる。
【００１０】
図１は、１実施形態における例を含む全体的な手法を示す図である。ユーザ（人間を示す「Ｈ」）は、チャット・ボット（会話エージェントを表す「Ｃ」）と会話して、テキストを翻訳するように頼んでいる。この例では、ユーザは、必要なパラメータを既に把握しており、それらをバッククォート（back-quote）すればよいことを知っている。チャット・ボットは、コール・チェーニングによって、またデフォルトを介して、欠けているパラメータを埋め、次いでＨＴＴＰ  ＧＥＴメソッドを介して翻訳サービスに対してＲＥＳＴコールを行い、その結果をユーザに戻す。生成されたチャット・ボットにより、エンド・ユーザは、ウェブＡＰＩについて最初に学習しなくても、ウェブＡＰＩを呼び出すことができる。対話は、反映を使用して、エンド・ユーザに、利用可能なアクションおよびそれらのパラメータを発見させることができる。１実施形態のチャット・ボット・コンパイラは、開発者が既存のＡＰＩ仕様を再利用して、迅速に完全に動作するボットを立ち上げることを可能にする。
【００１１】
１実施形態では、ウェブＡＰＩ仕様からのチャット・ボット・コンパイラは、ＡＰＩを呼び出すための自己文書化型チャット・ボットを生成する。コンパイラ、およびメッセージング・システムにおける実現の実施態様も、提示する。１実施形態のコンパイラは、様々なＡＰＩ仕様に基づいて、様々なチャット・ボットを生成することができる。ウェブＡＰＩおよびチャット・ボットの両方のプログラミング・モデルを開示する。
【００１２】
以下、１実施形態でコンパイラによって生成されるボットとの対話のトランスクリプトを用いて、具体例を説明する。この例は、異なる自然言語間の翻訳を行うことができるが、言語を識別するなど追加の機能にも対応している、Ｌａｎｇｕａｇｅ  ＴｒａｎｓｌａｔｏｒというウェブＡＰＩに基づいている。
【００１３】
【表１】
2020532011.tif 000003
【００１４】
ボット・コンパイラへの入力は、例えばＳｗａｇｇｅｒでは、ウェブＡＰＩ仕様である。表１は、ＴｒａｎｓｌａｔｏｒのサービスのＳｗａｇｇｅｒを示している。生成されるボット（一例としてＡＰＩボットと呼ぶ）は、Ｓｗａｇｇｅｒを、ユーザと（自然言語で）話をするための、またウェブＡＰＩを（ＨＴＴＰで）呼び出すための、両方のガイダンスとして使用する。１行目から３行目は、Ｓｗａｇｇｅｒのバージョン、ＡＰＩのバージョンおよびタイトル、ならびにベース・パスを指定している。４行目から２５行目は、リソース（例えば識別可能な言語、などの名詞）およびアクション（例えば識別する、などの動詞）へのベース・パスを基準とするパスを指定している。簡潔にするために、表１は、「／ｖ２／ｉｄｅｎｔｉｆｙ」というパスが対応しているアクションのうちの１つの詳細しか示していない。このパスは、同じ名前のＨＴＴＰメソッドに対応するＧＥＴおよびＰＯＳＴという２つの動作に対応する。各動作は、概要、パラメータ、およびレスポンスを有し、これらは人間が読める記述およびスキーマの両方を有することができる。この例では、スキーマは、２６行目から３８行目に与えられるｔｙｐｅ定義への参照（＄ｒｅｆ）を含む。
【００１５】
【表２】
2020532011.tif 000004
【００１６】
表２は、生成されたＡＰＩボット会話エージェント（「Ｃ」）と人間のエンド・ユーザ（「Ｈ」）の間の、ウェブＡＰＩ  Ｔｒａｎｓｌａｔｏｒを呼び出すための対話のトランスクリプトを示している。１実施形態のコンパイラは、表１に示すＳｗａｇｇｅｒの仕様から直接チャット・ボットを生成する。４行目で、エンド・ユーザは助けを求めているが、助けの求め方を知るためにコンピュータ言語を学習する必要がなく、自然言語を使用することができることに留意されたい。ＡＰＩボットは、例を用いて訓練された機械学習分類器（machine learning classifier）を介して助けてほしいという意図を理解するように構成される。１４行目は、やはり助けてほしいという意図に分類される異なる発語を示している。５行目から１１行目は、Ｓｗａｇｇｅｒのパスから生成されたヘルプ・テキストを示している。１２行目で、エンド・ユーザは、「識別する」というアクションを選択している。その後、チャット・ボットは、「識別する」を呼び出すために必要な追加の情報を収集する。人間が動作（ｇｅｔ）およびテキスト・パラメータ（Ｌａ  ｖｉｅ  ｅｓｔ  ｂｅｌｌｅ）を与えた後で、チャット・ボットは、ウェブＡＰＩを呼び出し、その結果（フランス語を示す「ｆｒ」）を表示する。その過程で、ボットは、バッククォートを用いてアクションおよびそのパラメータも簡潔に表示する。これには２つの効果がある。第１は、ユーザと共通の基盤を確立することの確認であり、第２は、このコールをより簡単に行う方法をユーザに教えるということである。
【００１７】
以下の説明は、１実施形態においてＡＰＩボットがどのように生成されるか、また１実施形態においてＡＰＩボットがどのように機能するかを示すものである。
【００１８】
生成されたＡＰＩボット会話エージェントによって、エンド・ユーザはウェブＡＰＩを呼び出すことができる。図２は、１実施形態における実行時アーキテクチャを示す図である。１つのハードウェア・プロセッサが、これらの構成要素を実行する、または動作させることもあるし、あるいは複数のハードウェア・プロセッサが、これらの構成要素を実行する、または動作させることもある。対話コントローラ（dialogue controller）２０２は、ウェブＡＰＩを呼び出すための会話を案内する。コントローラ２０２は、ＮＬＵ（自然言語理解（natural language understander））構成要素２０６を介してユーザ２０４からの入力を受け取り、ＮＬＧ（自然言語生成器（natural language generator））構成要素１２０８を介してユーザ２０４に出力を送信する。１実施形態では、ＡＰＩボット・エージェントは、会話エージェントのＷａｔｓｏｎ  Ｃｏｎｖｅｒｓａｔｉｏｎ  Ｓｅｒｖｉｃｅ（ＷＣＳ）プラットフォームに構築される。本開示のＡＰＩチャット・ボットは、別の会話サービス・プラットフォーム上に構築することもできる。
【００１９】
ＷＣＳでは、ＮＬＵは、エンティティ抽出器（entity extractor）２１０およびインテント分類器（intent classifier）２１２を含み、これらを、ＡＰＩボットは、目下のＳｗａｇｇｅｒ用にカスタマイズする。さらに、ＡＰＩボットは、ＷＣＳまたはその他のプラットフォームで通常は見られないもう１つのＮＬＵ構成要素として、直接コール・パーサ２１４を追加する。ＷＣＳでは、コントローラ２０２は、ＦＳＭ（有限状態機械）２２０の対話指定から駆動することができる。１実施形態では、コントローラ２０２の出力は、人間用の自然言語プロンプト、およびサービス・エンドポイントへのＨＴＴＰコールを含む。ＮＬＵ構成要素２０６、ＡＰＩ指定（例えばＳｗａｇｇｅｒ）からコントローラＦＳＭ２０２へのマッピング、コントローラが維持する追加の状態２２０、出力を実施するＮＬＧ構成要素２０８およびアクチュエータ構成要素２１６について、以下でさらに詳細に説明する。
【００２０】
入力ＮＬＵ
以下、１実施形態におけるＮＬＵ構成要素２０６についてさらに詳細に説明する。ＮＬＵ構成要素２０６は、ユーザ２０４からの自然言語発語を、対話コントローラ２０２用のシンボルに変換する。ほとんどの現在のチャット・ボット・プラットフォームは、２種類のシンボル、すなわちエンティティおよびインテントを認識する。
【００２１】
エンティティは、ユーザの発語中の用語またはオブジェクトを表し、ＷＣＳは、エンティティを＠という印でマークする。例えば、表２の１８行目で、ｇｅｔという単語は、＠ｇｅｔエンティティに属する。ＮＬＵ２０６のエンティティ抽出器２１０は、１つのユーザ発語について、発見した一致する各用語に対して１つずつ、複数のエンティティを戻すこともある。エンティティ抽出器２１０は、１実施形態では、パターン・マッチング・エンジンによって実装される。目下の具体的なＡＰＩ（例えばＳｗａｇｇｅｒ）仕様とは無関係に、例えば＠ｇｅｔおよび＠ｐｏｓｔなど、全てのＡＰＩボット・エージェントに共通のエンティティがいくつかある。さらに、例えば＠ｔｅｘｔ、＠ｓｏｕｒｃｅ、および＠ｔａｒｇｅｔなど、ＡＰＩ（例えばＳｗａｇｇｅｒ）仕様に見られるパラメータから生成されるエンティティもある。
【００２２】
インテントは、目的または目標、すなわちユーザがしたいことであり、ＷＣＳは、インテントを＃という印でマークする。例えば、表２の４行目で、「助けて下さい」は、＃ｈｅｌｐインテントに属する。ＮＬＵ２０６のインテント分類器２１２は、所与の発語についての最も信頼性の高いインテントを戻すか、あるいは信頼性の高いものがない場合には、特殊な＃ｉｒｒｅｌｅｖａｎｔインテントを戻す。インテント分類器２１２は、教師付き機械学習で実装され、訓練用データは、＜例、インテント＞対を含む。インテント分類器２１２は、各インテントについて多数の例があり、異なるインテントについての例が類似しておらず、それらの例が実際のユーザ発語の表現であるときに、最もよく機能する。例えば、＃ｈｅｌｐインテントについての訓練用の例は、「助ける」、「どんなオプションがありますか」、「何ができますか」、および「何が可能ですか」を含むこともある。目下の具体的なＡＰＩ（例えばＳｗａｇｇｅｒ）仕様とは無関係に、例えば＃ｈｅｌｐ、＃ｙｅｓ、および＃ｎｏなど、全てのＡＰＩボット・エージェントに共通のインテントがいくつかある。さらに、例えば＃ｉｄｅｎｔｉｆｙ、および＃ｔｒａｎｓｌａｔｅなど、ＡＰＩ（例えばＳｗａｇｇｅｒ）仕様に見られるパスから生成されるインテントもある。
【００２３】
エンティティおよびインテントの基本的なＮＬＵ機能があれば、多くのチャット・ボットには十分であるが、ウェブＡＰＩを呼び出すための良好な会話を得るためには、それでは制限が厳しすぎることもある。１つの問題は、一部のパラメータが、既定のエンティティまたはインテントと突き合わせて容易に一致させる、または分類することができないフリーフロー（free-flow）値を有することである。さらに、一部の入力は、エンティティ抽出器およびインテント分類器から完全に非表示にする必要がある。例えば、ｉｄｅｎｔｉｆｙアクションへのｔｅｘｔパラメータは、それら自体のエンティティまたはインテントをトリガしない任意の単語を含む可能性がある。したがって、ＡＰＩボットは、このようなパラメータについてプロンプティングするときには、表２の２０行目に示すように、次の人間の発語全体を１つの値として扱う。
【００２４】
これで問題は解決するが、残念ながら、各情報ごとに別個のターンを必要とすることにより、対話が長くなる。したがって、本開示は、クォート（quoting）機能を導入する。１実施形態では、クォート機能は、バッククォート（`…`）で表される。これは、バッククォートが、逐語的テキストを描写するためのメッセージング・プラットフォームのユーザに馴染みがあるからである。ＡＰＩボットは、Ｓｌａｃｋなどのメッセージング・プラットフォームに展開することができ、また、引用符を使用して逐語的テキストを信号通信することもできる。さらに、本開示は、引用されたテキストの前の発語中のパラメータ名エンティティがパラメータを引用値に設定するための規定を導入する。この規定は、１つの発語でＡＰＩコールを描写することを可能にし、直接コール・パーサ２１４によって実施される。例えば、「Ｌａ  ｖｉｅ  ｅｓｔ  ｂｅｌｌｅというテキストを識別する」は、ｉｄｅｎｔｉｆｙアクションを呼び出して、ｔｅｘｔを「Ｌａ  ｖｉｅ  ｅｓｔ  ｂｅｌｌｅ」に設定し、ＨＴＴＰ  ＧＥＴメソッドを使用する状態に戻る。
【００２５】
コントローラおよび状態
以下、１実施形態におけるＡＰＩ仕様（例えばＳｗａｇｇｅｒ）からコントローラの有限状態機械（ＦＳＭ）２０２へのマッピング、およびコントローラが維持する追加の状態２２０について説明する。図２のコントローラ構成要素２０２は、状態を維持し、ＮＬＵ２０６からのシンボルを、ＮＬＧ２０８およびアクチュエータ２１６への命令に変換する。チャット・ボットにおいて対話フローを指定する低レベル・フォーマリズム（formalism）は、ＦＳＭである。ＷＣＳプログラミング・モデルは、他の機能の中でも特にＦＳＭに対応している。１実施形態のＡＰＩボット・コンパイラの実施態様は、ＦＳＭを、そのコード生成ターゲット（ソースはＡＰＩ仕様（例えばＳｗａｇｇｅｒ））として使用する。図３は、１実施形態における、ＡＰＩボット・コンパイラが表１に示す（例えばＳｗａｇｇｅｒの）Ｔｒａｎｓｌａｔｏｒ  ＡＰＩから生成するＦＳＭの抜粋を示す図である。以下では、最初に表記について説明し、次いで、その表記が指定する対話フローについて説明する。
【００２６】
図３において、角の丸い枠はそれぞれ、状態を表している。他の状態から出たものではない矢印でマークされている、特殊なｓｔａｒｔ状態が、１つある。最終状態はいくつかあり、それらは２重枠でマークされている。最終状態からｓｔａｒｔ状態への暗黙的な最上位のループがある。状態間の有向エッジは、遷移であり、それらのラベルは、述語である。状態ラベルは、状態名／アクションの形式であるが、ほとんどの状態名は、簡潔にするために省略してある。アクションは、遷移ではなく状態にあるので、１実施形態のＦＳＭは、（例えばミーリ・マシンではなく）ムーア・マシンである。実施態様の１実施形態では、ＷＣＳプログラミング・モデルがムーア・マシンに対応するので、ムーア・マシンがフォーマリズムとして実装される。他の状態機械の実施態様を利用してもよい。
【００２７】
遷移の述語は、ＮＬＵからのシンボル、すなわち＠および＃でそれぞれマークされたエンティティおよびインテントに基づく。いくつかの遷移は、チャット・ボットがユーザの入力を待機せずに遷移を行うことを示す、空文字列シンボルεまたはイプシロンでマークされる。最後に、いくつかの遷移は、チャット・ボットがユーザ入力を収集するが、発語全体を１つの値として扱い、遷移がその値に左右されないようにすることを示す、ｔｒｕｅ述語でマークされる。ＦＳＭの状態におけるアクションは、ＮＬＧおよびアクチュエータに対する命令である。例えば、ｐｒｉｎｔ  ｈｅｌｐ  ｔｅｘｔアクションは、ＮＬＧに対する命令であり、Ｃａｌｌ  ＡＰＩアクションは、アクチュエータに対する命令である。簡潔にするために、図３では、アクションの詳細を明記していないが、それらは文脈固有である。ｈｅｌｐ  ｔｅｘｔの文脈は、現在のＦＳＭ状態であり、ＡＰＩ  ｃａｌｌの文脈は、現在のＦＳＭ状態、ならびにその状態に至るまでの状態で収集された動作およびパラメータを含む。
【００２８】
図３の対話フローは、ｓｔａｒｔ状態から５つの遷移を示している。
【００２９】
遷移１。ｓｔａｒｔから、＃ｈｅｌｐである場合には、ボットは、Ｓｗａｇｇｅｒのパスから生成される既知のリソースおよびアクションのリストを印刷する。ＡＰＩボットは、ヒューリスティクスを実施して、Ｔｒａｎｓｌａｔｏｒ  Ｓｗａｇｇｅｒ内の共通のパス・プレフィックス「／ｖ２／」を省略する。これは、それらが有用な情報を提供せず、エンド・ユーザに無用の混乱を生じさせるからである。ｈｅｌｐ  ｔｅｘｔを表示した後で、チャット・ボットは、ε（例えばイプシロン）遷移で示されるようにユーザ入力を収集せずに、ｓｔａｒｔ状態に戻る。
【００３０】
遷移２。ｓｔａｒｔから、＃ｉｄｅｎｔｉｆｙ＾＠ｔｅｘｔである場合には、直接コール・パーサが、所要のテキスト・パラメータで「／ｖ２／ｉｄｅｎｔｉｆｙ」パスを呼び出すのに必要な全ての情報を提供している。ＨＴＴＰメソッドが指定されない場合には、メソッドは、パスがＧＥＴに対応している場合には、ＧＥＴに戻る。ＡＰＩボットは、ヒューリスティクスを実施して、この場合のａｃｃｅｐｔパラメータなど、デフォルト値を有する任意選択のパラメータを求めないことにする。さらに、ａｃｃｅｐｔパラメータは、Ｔｒａｎｓｌａｔｏｒ  ＡＰＩに特有ではなくＲＥＳＴ一般の機能である、コンテンツ・ネゴシエーションを実施する。コンテンツ・ネゴシエーションは、非専門家のエンド・ユーザから技術的により良好に隠される実施態様である。
【００３１】
遷移３。ｓｔａｒｔから、＃ｉｄｅｎｔｉｆｙであるが、直前の遷移が発火しなかった場合には、チャット・ボットは、「／ｖ２／ｉｄｅｎｔｉｆｙ」パスを呼び出すための動作およびパラメータを収集するノードのチェーンを有する。この状況では、ｈｅｌｐ  ｔｅｘｔは、この所与のパスの動作を列挙する。図３には、＠ｐｏｓｔについてのＦＳＭ状態は省略し、＠ｇｅｔについてのＦＳＭ状態のみを示す。ＦＳＭのこの部分は、ｔｅｘｔパラメータが任意の文字列であってよく、したがってＮＬＵに供さなくてもよいので、ｔｒｕｅ状態の例も含む。
【００３２】
遷移４。ｓｔａｒｔから、＃ｔｒａｎｓｌａｔｅ＾＠ｓｏｕｒｃｅ＾＠ｔａｒｇｅｔ＾＠ｔｅｘｔである場合には、直接コール・パーサが、「／ｖ２／ｔｒａｎｓｌａｔｅ」パスを呼び出すために必要な全ての情報を提供している。
【００３３】
遷移５。ｓｔａｒｔから、＃ｔｒａｎｓｌａｔｅであるが、直前の遷移が発火しなかった場合には、チャット・ボットは、「／ｖ２／ｔｒａｎｓｌａｔｅ」パスを呼び出すための動作およびパラメータを収集するノードのチェーンを有する。
【００３４】
図２の状態２２０は、ＦＳＭ状態、ならびにＡＰＩコールを行うという目的に向かって駆動する対話フローの現在の部分までに収集された部分的な情報を含む。
【００３５】
出力：ＮＬＧおよびアクチュエータ
以下、１実施形態における、出力を実施するＮＬＧ構成要素２０８およびアクチュエータ構成要素２１６について説明する。図２のＮＬＧ構成要素２０８およびアクチュエータ構成要素２１６は、対話コントローラ２０２からの命令を、ユーザ２０４に対する自然言語レスポンスに変換し、ＲＥＳＴサービス・エンドポイント２１８へのＨＴＴＰコールを行う。コントローラ２０２をクリーンなインタフェースでカプセル化するために、１実施形態のＡＰＩボットの実施態様は、これらの命令を、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）オブジェクトとして具体化する。
【００３６】
１実施形態のＡＰＩボットは、単純なＮＬＧを使用する。一般的に、ＡＰＩボットのＮＬＧ２０８は、リテラルなハードコード文字列を含み、それらのうちの一部は、例えば表２の６行目から１０行目のパスのリストなど、コンパイル時のＡＰＩ仕様（例えばＳｗａｇｇｅｒ）から生成される。いくつかの場合には、ＮＬＧ２０８は、実行時に文字列補間も使用する。この場合、文字列補間とは、実行時に一定の文字列テンプレートに動的に計算された部分文字列を挿入することを意味する。
【００３７】
アクチュエータ２１６は、ウェブＡＰＩへのＨＴＴＰコールを行う役割を担う。１実施形態におけるＡＰＩボットの例示的な実施態様は、ＪＡＶＡ（Ｒ）で書かれるものであり、単純なＨＴＴＰクライアントを使用して、サービス・エンドポイント２１８への同期コールを実行する。１実施形態では、アクチュエータ２１６は、エンド・ユーザのデバイス上にローカル・アプリケーションとして展開される。１実施形態では、ＮＬＵ２０６と、コントローラ２０２の大部分とは、Ｗａｔｓｏｎ  Ｃｏｎｖｅｒｓａｔｉｏｎ  Ｓｅｒｖｉｃｅなどのサービスでクラウド・ホスト型のアプリケーションとして展開される。別の実施形態では、アクチュエータ２１６は、パブリック・クラウド、またはサービス・エンドポイントを提供する組織のコンピュータ・インフラストラクチャをホストとすることもある。
【００３８】
１実施形態のアクチュエータ２１６は、可能であれば、欠けているパラメータのデフォルト値を埋める役割も担う。このことには、１実施形態では、２つの利点がある。すなわち、（ｉ）オリジナルのＡＰＩ仕様（例えばＳｗａｇｇｅｒ）ファイルでデフォルト値を指定することができること、および（ｉｉ）本開示によって、そのデフォルト値を埋めるために使用することができるウェブＡＰＩの他の部分へのコールバックを示すＡＰＩ仕様（例えばＳｗａｇｇｅｒ）ファイル内のＡＰＩボット注釈が可能になること、である。
【００３９】
【表３】
2020532011.tif 000005
【００４０】
表３は、Ｌａｎｇｕａｇｅ  ＴｒａｎｓｌａｔｏｒというウェブＡＰＩにおけるｔｒａｎｓｌａｔｅコールのソース言語パラメータについての対応する注釈を示している。この図は、ソース・パラメータがユーザによって提供されない場合には、入力テキストによってｉｄｅｎｔｉｆｙを呼び出すことによってデフォルトを取得することができることを示している。適当なパラメータの値が、存在する場合には、現在のコンテキストから取得される。ｃａｌｌｂａｃｋ記述は、ＡＰＩ仕様（例えばＳｗａｇｇｅｒ）ファイルと共に読み取られ、コントローラを通してアクチュエータ２１６に渡される。ｃａｌｌｂａｃｋ記述は、ＡＰＩの別の部分へのサブコールを行うために必要な全ての情報と、そのサブコールについてのパラメータを埋める方法（この例では、ｔｅｘｔパラメータのみが必要となる）とを含む。以上は、ＡＰＩ仕様から対話仕様へのコンパイルの説明である。
【００４１】
表４は、Ｔｏｎｅ  ＡｎａｌｙｚｅｒというウェブＡＰＩのＳｗａｇｇｅｒを示している。
【００４２】
【表４】
2020532011.tif 000006
【００４３】
表５は、Ｔｏｎｅ  ＡｎａｌｙｚｅｒというウェブＡＰＩとの例示的な対話を示している。
【００４４】
【表５】
2020532011.tif 000007
【００４５】
表６は、Ｖｉｓｕａｌ  ＲｅｃｏｇｎｉｔｉｏｎというウェブＡＰＩのＳｗａｇｇｅｒを示している。
【００４６】
【表６】
2020532011.tif 000008
【００４７】
図４から図７は、表６に示すＶｉｓｕａｌ  ＲｅｃｏｇｎｉｔｉｏｎというウェブＡＰＩとの例示的な対話を示す図である。
【００４８】
表４から表６、および図４から図７は、上述のＴｒａｎｓｌａｔｏｒというＡＰＩの例の補助となるウェブＡＰＩについての例示的なケース・スタディを示し、本開示のＡＰＩボットが機能するのはただ１つの特定のＡＰＩだけではないことを示すものである。本開示の１実施形態におけるＡＰＩボットは、実時間メッセージング・システムであるＳｌａｃｋメッセージング・プラットフォームなどのメッセージング・プラットフォームに一体化することもできる。
【００４９】
Ｔｏｎｅ  Ａｎａｌｙｚｅｒは、テキスト・ドキュメントを解析して、３つのもの、すなわち感情（例えば怒り、喜び、悲しみ）、スタイル（例えば確信、不確かさ）、および社会的傾向（例えば外交性、愛想のよさ）を検出する。表４は、ウェブＡＰＩ仕様の抜粋を示している。表４は、４つのパラメータ、すなわちｖｅｒｓｉｏｎ、ｔｅｘｔ、ｔｏｎｅｓ、およびｓｅｎｔｅｎｃｅｓを有する１つのパス「／ｖ３／ｔｏｎｅ」のみを示している。この４つのパラメータのうち３つは、任意選択であるか、あるいはデフォルト値を有し、ｔｅｘｔパラメータのみが、各コールごとに指定される必須情報として残る。表５は、Ｔｏｎｅ  Ａｎａｌｙｚｅｒを呼び出すためのＡＰＩボット対話のトランスクリプトを示している。人間は、ただダイレクト・コールを行って、ｔｅｘｔを「私は非常に幸せです」に設定するだけである。このコールの結果は、入力テキストが与えられたときに人が期待するものと一致する。解析器は、優勢な感情は喜びであり、スタイルは確信であり、このテキスト中に見られる最も強い社会的傾向は愛想のよさであると決定した。
【００５０】
表６に示すＶｉｓｕａｌ  Ｒｅｃｏｇｎｉｔｉｏｎ  ＡＰＩは、画像ファイルを解析して、３つのもの、すなわちシーン、オブジェクト、および顔を識別する。表６は、ウェブＡＰＩ仕様の抜粋を示している。このウェブＡＰＩ仕様の抜粋は、「／ｖ３／ｄｅｔｅｃｔ／ｆａｃｅｓ」という、パスのうちの１つのみを対象としている。１実施形態では、他のパスが同じパラメータの一部を共有するので、パラメータは、インラインではなく参照によって宣言される。３つのパラメータ、すなわちａｐｉ＿ｋｅｙ（認証に使用される数字および番号の推測しにくい文字列）、ｕｒｌ（画像ファイルのアドレス）、およびｖｅｒｓｉｏｎ（文字列として与えられるＡＰＩバージョン）がある。ｖｅｒｓｉｏｎは、デフォルト値を有する。
【００５１】
図４から図７は、Ｖｉｓｕａｌ  Ｒｅｃｏｇｎｉｔｉｏｎ  ＡＰＩを呼び出すためのＡＰＩボット対話のトランスクリプトを示している。このスクリプトは、Ｓｌａｃｋメッセージング・プラットフォームに一体化されて動作するＡＰＩボットのスクリーンショットである。Ｓｌａｃｋは、協調しているチームによる永続的なマルチ・パーティ・チャットにしばしば使用される。この場合には、２人の参加者、すなわちＡＰＩボット、およびルイスという名前の人間のエンド・ユーザがいる。この対話は、段階的コールを示しており、エンド・ユーザが助けを求め、チャット・ボットがパラメータを求めて１つずつプロンプティングしている。エンド・ユーザは、別個に取得したＡＰＩキーをコピー・アンド・ペーストする。１つのＳｌａｃｋ機能は、ユーザが統一資源ロケータ（ＵＲＬ）をペーストしたときに、その宛先のプレビューを表示するというものである。この場合には、ＵＲＬは、個人履歴であり、Ｓｌａｃｋは、その周辺のＷｉｋｉｐｅｄｉａ記事の抜粋を示す。Ｓｗａｇｇｅｒはｖｅｒｓｉｏｎパラメータについてのデフォルトを指定するので、ＡＰＩボットは、ｖｅｒｓｉｏｎパラメータについてはプロンプティングしない。ｖｅｒｓｉｏｎパラメータは、ダイレクト・コールを介して明示的に設定されることもある。
【００５２】
コールを行う前に、１実施形態のＡＰＩボットは、グラウンディング（grounding）およびティーチング（teaching）のためにこの簡潔なｖｅｒｓｉｏｎをエコーする。これは、バッククォートがＳｌａｃｋ  ｍａｒｋｄｏｗｎでどのように描写されるかを示す。１実施形態では、引用されたテキストが、通常のテキストは異なるカラー・スキームのタイプライタ・フォントで現れる。最後に、ＡＰＩボットがコールを行い、Ｖｉｓｕａｌ  Ｒｅｃｏｇｎｉｔｉｏｎ  ＡＰＩが、個人履歴のうちの年齢、性別、および識別についての推測の報告を戻す。これらの推測は、正確である。
【００５３】
フォーマット化の利点の他にも、ウェブＡＰＩを呼び出すボットをＳｌａｃｋまたは類似のメッセージング・プラットフォームに一体化することには、他の十分な理由がある。企業のユーザは、Ｓｌａｃｋを介して互いにチャットすることが多い可能性があるので、チャット・ボットをそこに入れることにより、コンテキストを切り替える必要性が減少する。呼出しの場合には、これにより、責任追跡性のための、起こったことの永続的な記録が提供される。また、これは、例えばウェブＡＰＩが一種のステータス・リポートを戻すときなどには、互いに情報を共有した状態にしておく簡単な方法でもある。また、これにより、学習の機会が増大し、あるユーザの成功したコールを他のユーザが手本にすることができる。
【００５４】
上述のように、異なるＡＰＩ仕様から、異なるＡＰＩチャット・ボットを生成することができる。ＡＰＩ仕様から生成される本開示のチャット・ボットは、会話が例えばウェブＡＰＩコールなどのアクションを駆動することを可能にする。本開示の１実施形態のチャット・ボットは、完全に自己文書化型であってもよい。例えば、ユーザは、チャット・ボットと対話することによって、ダイレクト・コールを行う方法など、チャット・ボットについて知る必要がある全てのことを学習することができる。
【００５５】
ＶｏｉｃｅＸＭＬは、ＨＴＭＬが視覚コンテンツについて果たすのと同じ役割を会話について果たすように設計された標準である。その方針は、プロバイダはＶｏｉｃｅＸＭＬを提供し、消費者はボイス・ブラウザを介してＶｏｉｃｅＸＭＬと対話し、ＶｏｉｃｅＸＭＬはハイパーリンクすることができるという会話ウェブが存在することになるというものであった。ＶｏｉｃｅＸＭＬの欠点は、プロバイダに、新たなチャット・ボットをその言語で書くことを求める点である。対照的に、本開示の１実施形態のＡＰＩボットは、Ｓｗａｇｇｅｒなど予め書かれたＡＰＩ仕様を使用して、チャット・ボットを立ち上げる。
【００５６】
Ｓｗａｇｇｅｒは、各種様々なアーチファクトを生成するためのソース言語として設計されている。Ｓｗａｇｇｅｒのユーザ・インタフェース（ＵＩ）は、文書化を視覚的に描写し、開発者にサンドボックスでウェブＡＰＩと対話させる。ただし、その対話は、自然言語会話を使用せず、エンド・ユーザを対象としておらず、生産での使用を意図していないという点で、ＡＰＩボットとは異なる。
【００５７】
データベースとの自然言語インタフェース（natural languageinterfaces to databases）（ＮＬＩＤＢ）は、データベース・スキーマからＮＬＩＤＢエージェントを生成することができる。マルチターン会話を利用するＮＬＩＤＢ作業は、ようやく最近になって行われるようになり、依然として活発な研究領域である。
【００５８】
この場合には、（ＩＦＴＴＴ）により、エンド・ユーザは簡単かつ便利にウェブＡＰＩを呼び出すことができる。ＩＦＴＴＴエコシステムの参加者は、自分のエンドポイントをトリガまたはアクションにラッピング（wrap）しなければならない。これらが生成されたら、エンド・ユーザは、それらをまとめてレシピにいれることができる。対照的に、ＡＰＩボットでは、参加者は、自分のエンドポイントをアクションにラッピングする必要がなく、その代わりに、ＡＰＩ仕様をソース言語として使用することにより、アクションがチャット・ボットにコンパイルされる。また、ＡＰＩボットとは異なり、ＩＦＴＴＴは、自然言語チャット・インタフェースを提供しない。
【００５９】
自然言語を用いたプログラミング
【００６０】
自然言語プログラミングに関係する作業は、一般に、自然言語センテンスから形式言語への変換を含むことがあるが、それらの作業は、ＡＰＩ仕様またはウェブＡＰＩ仕様からチャット・ボットを生成しない、あるいは自己文書化型のそのように生成されたチャット・ボットを生成しない。
【００６１】
１実施形態におけるシステム、方法、および技術は、ウェブＡＰＩ仕様（例えばＳｗａｇｇｅｒで書かれている）からそれらのウェブＡＰＩを呼び出すためのチャット・ボットへのコンパイラを提示する。１態様では、このコンパイラにより、顧客または従業員に提供するサービスについてＡＰＩ（例えばＳｗａｇｇｅｒ）仕様を有する企業は、それらのための初期自然言語チャット・ボットを直ちに得ることができる。これにより、企業は、チャット・ボットを改良し、チャット・ボットは、連続的なフィードバック駆動型プロセスになる傾向がある。生成されたボットは自己文書化型であるので、例えば、ボットまたはウェブＡＰＩの使い方を知らないユーザは、ボットと対話することによって、使い方を発見することができる。例えば、コンパイラは、チャット・ボットを介して呼び出しやすい洗練されたＡＰＩを描写することができる。
【００６２】
図８は、１実施形態におけるアプリケーション・プログラミング・インタフェース（ＡＰＩ）の会話ボットを自動的に生成する方法を示す図である。この方法は、例えば図２に示す構成要素を参照して説明したように、１つまたは複数のハードウェア・プロセッサによって実行される。５０２で、ＡＰＩコールの呼出しに関連する情報を含むＡＰＩ仕様を受け取る。このようなＡＰＩ仕様の一例は、Ｓｗａｇｇｅｒ仕様である。５０４で、ＡＰＩ仕様を構文解析する。５０６で、ＡＰＩ仕様の構文解析に基づいて、会話ボット仕様を構築する。例えば、有限状態機械を構築してもよい。有限状態機械は、複数の状態および状態遷移を含み、会話ボットの対話フローを指定する。有限状態機械の一例は、図３に示してある。図８を参照すると、５０８で、テキスト表現、発語、または可聴スピーチなどの自然言語表現を、ユーザから受け取る。
【００６３】
５１０で、自然言語表現を、命令に変換する。例えば、自然言語表現をシンボルに変換し、これらのシンボルを、ユーザに対する自然言語プロンプトを生成するための命令、またはＡＰＩコールを呼び出すための実行可能コンピュータ・コード、あるいはその両方に変換する。１実施形態では、シンボルは、例えば会話ボット仕様の一部として構築された有限状態機械に基づいて、命令に変換することができる。１実施形態では、シンボルは、状態遷移をトリガするために使用され、目標状態のアクションを命令として使用することによって、命令に変換される。
【００６４】
５１２で、命令に基づいて、自然言語プロンプトまたはレスポンスを生成する。自然言語プロンプトまたはレスポンスは、例えば、例えば確認または質問を求めるためにユーザに対して提示されるプロンプトを含む命令に応じて生成される。命令は、表示または発語される自然言語プロンプトを逐語的に含む文字列を含む、または指定することがある。別の実施形態では、文字列補間を実行して、自然言語プロンプトを生成することもできる。
【００６５】
５１４で、例えば５１２において自然言語プロンプトを生成したのに応答して、例えば１つまたは複数のハードウェア・プロセッサに結合されたボイス・シンセサイザなどのデバイスによるテキストまたは発語として、自然言語プロンプトを、例えばユーザに対して表示する、または発語する、あるいはその両方を行うなどして、提示する。
【００６６】
５１６で、命令がＡＰＩへのコールを含むかどうかを判定する。５１８で、命令がＡＰＩを呼び出すことを命令する場合には、ＡＰＩコールを呼び出すコンピュータ・コードを実行する。コンピュータ・コードは、例えば、ＡＰＩへのコールを含む命令に基づいて生成することができる。この方法の論理は、例えば会話ボット仕様に指定される対話フローに従って、５０８に戻り、処理を反復することもある。５１６で、命令がＡＰＩへのコールを含まない場合には、処理は、例えば、例えば有限状態機械を含む会話ボット仕様に基づいて、５０８に戻り、５０８〜５１６の処理を反復して、ＡＰＩコールを呼び出す対話フローを続行することができる。
【００６７】
ＡＰＩコールを呼び出すコンピュータ・コードの例としては、ＡＰＩコールに関連するサービスを提供するサービス・エンドポイントへのハイパーテキスト転送プロトコル（ＨＴＴＰ）コールが含まれる。例えば、ＡＰＩ仕様は、ウェブＡＰＩ仕様であることもあり、ＡＰＩコールは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒコールを含むこともある。
【００６８】
１実施形態では、ＮＬＵ構成要素を参照して上述したように、シンボルは、自然言語発語中のオブジェクトを表すエンティティと、自然言語発語中の目的を表すインテントとを、少なくとも含むことがある。１態様では、対話フローは、複数のＡＰＩコールを呼び出すことを含むこともあり、その場合、複数のＡＰＩコールは、１回の対話で呼び出される。
【００６９】
別の実施形態のコンパイラは、認証機能を含むこともある。さらに、コンパイラは、１つのＡＰＩコールの結果を別のＡＰＩコールに送ることを可能にすることもある。例えば、識別可能な言語のリストは、翻訳におけるソース言語およびターゲット言語の許容可能値を決定する助けになる。したがって、複数のコールを一続きにすることもできる。さらに、ＡＰＩ仕様の集まりからボットを生成することもできる。
【００７０】
図９は、本開示の１実施形態のチャット・ボット生成システムを実装することができる例示的なコンピュータまたは処理システムを示す概略図である。このコンピュータ・システムは、適当な処理システムの一例に過ぎず、本明細書に記載する方法の実施形態の用途または機能の範囲に関するいかなる限定を示唆するためのものでもない。図示の処理システムは、多数の他の汎用または特殊目的のコンピューティング・システム環境または構成で動作可能であることもある。図６に示す処理システムと共に使用するのに適している可能性がある周知のコンピューティング・システム、環境、または構成、あるいはそれらの組合せの例としては、これらに限定されるわけではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち型またはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ型システム、セット・トップ・ボックス、プログラマブル消費者エレクトロニクス、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスのうちのいずれかを含む分散型クラウド・コンピューティング環境などが含まれる可能性がある。
【００７１】
コンピュータ・システムは、プログラム・モジュールなどのコンピュータ・システム実行可能命令がコンピュータ・システムによって実行されているという一般的文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ・タイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、およびデータ構造などを含む可能性がある。コンピュータ・システムは、通信ネットワークを介してリンクされた複数の遠隔の処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境に実装することもできる。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスなど、ローカルのコンピュータ・システム・ストレージ媒体および遠隔のコンピュータ・システム・ストレージ媒体の両方に位置する可能性がある。
【００７２】
コンピュータ・システムの構成要素は、これらに限定されるわけではないが、１つまたは複数のプロセッサまたは処理ユニット１２、システム・メモリ１６、およびシステム・メモリ１６を含む様々なシステム構成要素をプロセッサ１２に結合するバス１４を含む可能性がある。プロセッサ１２は、本明細書に記載する方法を実行するモジュール３０を含むことがある。モジュール３０は、プロセッサ１２の集積回路にプログラムしてもよいし、メモリ１６、ストレージ・デバイス１８、またはネットワーク２４、あるいはそれらの組合せからロードしてもよい。
【００７３】
バス１４は、メモリ・バスまたはメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、および様々なバス・アーキテクチャのうちのいずれかを使用するプロセッサまたはローカル・バスなど、いくつかのタイプのバス構造のうちのいずれかのうちの１つまたは複数を表すことができる。限定ではなく例示であるが、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダード・アソシエーション（ＶＥＳＡ）ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バスを含む。
【００７４】
コンピュータ・システムは、様々なコンピュータ・システム可読媒体を含む可能性がある。このような媒体は、コンピュータ・システムがアクセス可能な任意の入手可能な媒体とすることができ、揮発性および不揮発性の媒体の両方を含み、また取外し可能および取外し不能の媒体の両方を含む可能性がある。
【００７５】
システム・メモリ１６は、ランダム・アクセス・メモリ（ＲＡＭ）もしくはキャッシュ・メモリ、またはその両方などの揮発性メモリ、あるいはその他のメモリの形態の、コンピュータ・システム可読媒体を含む可能性がある。コンピュータ・システムは、他の取外し可能／取外し不能、揮発性／不揮発性コンピュータ・システム・ストレージ媒体をさらに含む可能性もある。単なる例示であるが、ストレージ・システム１８は、取外し不能な不揮発性磁気媒体（例えば「ハード・ドライブ」）からの読取り、およびその媒体への書込みのために設けることもできる。図示していないが、取外し可能な不揮発性磁気ディスク（例えば「フロッピー（Ｒ）・ディスク」）からの読取り、およびそのディスクへの書込みのための磁気ディスク・ドライブ、ならびにＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはその他の光学媒体などの取外し可能な不揮発性光ディスクからの読取り、またはそのディスクへの書込みのための光学ディスク・ドライブを設けることもできる。そのような場合には、それぞれ、１つまたは複数のデータ媒体インタフェースによってバス１４に接続することができる。
【００７６】
コンピュータ・システムは、キーボード、ポインティング・デバイス、ディスプレイ２８などの１つまたは複数の外部デバイス２６、ユーザがコンピュータ・システムと対話することを可能にする１つまたは複数のデバイス、またはコンピュータ・システムが１つまたは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（例えばネットワーク・カード、モデムなど）、あるいはその組合せと通信することもできる。このような通信は、入出力（Ｉ／Ｏ）インタフェース２０を介して行うことができる。
【００７７】
さらに、コンピュータ・システムは、ネットワーク・アダプタ２２を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的な広域ネットワーク（ＷＡＮ）、またはパブリック・ネットワーク（例えばインターネット）、あるいはそれらの組合せなどの１つまたは複数のネットワーク２４と通信することができる。図示のように、ネットワーク・アダプタ２２は、バス１４を介してコンピュータ・システムの他の構成要素と通信する。図示していないが、他のハードウェア構成要素、またはソフトウェア構成要素、あるいはそれらの組合せを、コンピュータ・システムと共に使用することもできることを理解されたい。例としては、これらに限定されるわけではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが含まれる。
【００７８】
本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組合せである可能性がある。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有する１つまたは複数のコンピュータ可読ストレージ媒体を含む可能性がある。
【００７９】
コンピュータ可読ストレージ媒体は、命令実行デバイスが使用する命令を保持および格納することができる有形デバイスとすることもできる。コンピュータ可読ストレージ媒体は、これらに限定されるわけではないが、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、またはそれらの任意の適当な組合せである可能性がある。コンピュータ可読ストレージ媒体のさらに詳細な例を非排他的に挙げると、携帯可能コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、携帯可能コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル汎用ディスク（ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）・ディスク、命令が記録されたパンチカードまたは溝内の隆起構造などの機械符号化デバイス、およびそれらの任意の適当な組合せなどが挙げられる。本明細書で使用する「コンピュータ可読ストレージ媒体」は、電波またはその他の自由伝搬電磁波、導波路またはその他の伝送媒体中を伝搬する電磁波（例えば光ファイバ・ケーブルを通る光パルスなど）、あるいはワイヤ内を伝送される電気信号など、一過性の信号自体として解釈されないものとする。
【００８０】
本明細書に記載するコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスにダウンロードすることもできるし、あるいは例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、もしくはワイヤレス・ネットワーク、またはそれらの組合せなどのネットワークを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードすることもできる。ネットワークは、伝送銅線、伝送光ファイバ、ワイヤレス伝送、ルータ、ファイヤウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組合せを含む可能性がある。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、そのコンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。
【００８１】
本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械語命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいはＳｍａｌｌｔａｌｋ（Ｒ）もしくはＣ＋＋などのオブジェクト指向プログラミング言語、または「Ｃ」プログラミング言語もしくはそれに類するプログラミング言語などの従来の手続き型プログラミング言語などの１つまたは複数のプログラミング言語の任意の組合せで書かれたソース・コードまたはオブジェクト・コードのいずれかである可能性がある。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行されることも、部分的にユーザのコンピュータ上で実行されることも、独立型ソフトウェア・パッケージとして実行されることも、部分的にユーザのコンピュータ上で実行され、部分的に遠隔コンピュータ上で実行されることも、あるいは完全に遠隔のコンピュータまたはサーバ上で実行されることもある。最後のシナリオでは、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）など任意のタイプのネットワークを介してユーザのコンピュータに接続することができ、この接続は、（例えばインターネット・サービス・プロバイダを用いてインターネットを介して）外部のコンピュータに対して行うこともできる。いくつかの実施形態では、例えばプログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル論理アレイ（ＰＬＡ）などの電子回路が、コンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行して、本発明の様々な態様を実行することもある。
【００８２】
本明細書では、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品を示す流れ図またはブロック図、あるいはその両方を参照して、本発明の様々な態様について説明している。流れ図またはブロック図、あるいはその両方の各ブロック、および流れ図またはブロック図、あるいはその両方のブロックの様々な組合せは、コンピュータ可読プログラム命令によって実施することができることは理解されるであろう。
【００８３】
これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が、流れ図またはブロック図、あるいはその両方の１つまたは複数のブロックに指定される機能／アクションを実施する手段を生成するように、汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供されてマシンを作り出すものであってもよい。また、これらのコンピュータ可読プログラム命令は、命令を格納しているコンピュータ可読ストレージ媒体が、流れ図またはブロック図、あるいはその両方の１つまたは複数のブロックに指定される機能／アクションの様々な態様を実施する命令を含む製品を構成するように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラマブル・データ処理装置、またはその他のデバイス、あるいはそれらの組合せに特定のかたちで機能するように指示することができるものであってもよい。
【００８４】
コンピュータ可読プログラム命令は、コンピュータ、その他のプログラマブル装置、またはその他のデバイス上で実行される命令が、流れ図またはブロック図、あるいはその両方の１つまたは複数のブロックに指定される機能／アクションを実施するように、コンピュータ実施プロセスを作り出すべく、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイスにロードされ、コンピュータ、その他のプログラマブル装置、またはその他のデバイス上で一連の動作ステップを実行させるものであってもよい。
【００８５】
添付の図面の流れ図およびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実施態様のアーキテクチャ、機能、および動作を示している。これに関連して、流れ図またはブロック図の各ブロックは、指定された論理機能（１つまたは複数）を実施するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、または命令の一部分を表す可能性がある。いくつかの代替の実施態様では、ブロックに記載される機能は、図面に記載される以外の順序で発生することもある。例えば、連続して示されている２つのブロックが、実際には実質的に同時に実行されることもあり、あるいは、関係する機能によっては逆の順序で実行されることもある。また、ブロック図または流れ図、あるいはその両方の各ブロック、およびブロック図または流れ図、あるいはその両方のブロックの組合せは、指定された機能またはアクションを実行する、あるいは特殊目的のハードウェアおよびコンピュータ命令の組合せを実行する、特殊目的ハードウェア型システムによって実施することもできることに留意されたい。
【００８６】
本明細書で使用する用語は、特定の実施形態を説明することのみを目的とするものであり、本発明を限定することを意図したものではない。本明細書で使用する単数形の「ある（a）」、「１つの（an）」、および「その（the）」は、文脈からそうでないことが明らかでない限り、複数形も含むものとして意図とされている。さらに、本明細書で使用される「備える（comprises）」または「備えている（comprising）」あるいはその両方の用語は、記載される特徴、完全体、ステップ、動作、要素、または構成要素あるいはその組合せが存在することを指定するが、１つまたは複数の他の特徴、完全体、ステップ、動作、要素、構成要素、またはそれらのグループあるいはその組合せが存在すること、または追加されることを排除しない。
【００８７】
添付の特許請求の範囲にミーンズまたはステップ・プラス・ファンクション要素がある場合には、それら全ての対応する構造、材料、アクション、および均等物は、特に請求対象とする他の請求対象の要素と組み合わせて機能を実行する任意の構造、材料、またはアクションを含むものと意図されている。例示および説明を目的として本発明について説明したが、この説明は、網羅的なものでも、あるいは開示した形態の発明に限定するためのものでもない。多数の変更および変形が、本発明の範囲および趣旨を逸脱することなく、当業者には明らかになるであろう。実施形態は、本発明の原理および実際の応用例を最もよく説明し、企図される個々の用途に適した様々な変更を含む様々な実施形態について当業者が本発明を理解することを可能にするために選び、説明したものである。
【図１】
2020532011.tif 000009
【図２】
2020532011.tif 000010
【図３】
2020532011.tif 000011
【図４】
2020532011.tif 000012
【図５】
2020532011.tif 000013
【図６】
2020532011.tif 000014
【図７】
2020532011.tif 000015
【図８】
2020532011.tif 000016
【図９】
2020532011.tif 000017
【手続補正書】
【提出日】令和2年9月4日(2020.9.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのハードウェア・プロセッサによって実行される、アプリケーション・プログラミング・インタフェース（ＡＰＩ）の会話ボットを自動的に生成する方法であって、
ＡＰＩコールの呼出しに関連する情報を含むＡＰＩ仕様を受け取るステップと、
前記ＡＰＩ仕様を構文解析するステップと、
前記ＡＰＩ仕様の構文解析に基づいて、会話ボット仕様を構築するステップと、
ユーザから自然言語表現を受け取るステップと、
前記会話ボット仕様に基づいて、前記自然言語表現を命令に変換するステップと、
前記命令が前記ユーザに提示されるプロンプトを含むとの決定に応答して、前記命令に基づいて、自然言語プロンプトを生成するステップと、
前記命令が前記ＡＰＩコールの実行を含むとの決定に応答して、前記命令に基づいて、前記ＡＰＩコールを呼び出すためのコンピュータ・コードを実行するステップと、
を含む、方法。
【請求項２】
前記ユーザから前記自然言語表現を受け取る前記ステップ、前記自然言語表現を命令に変換する前記ステップ、前記自然言語プロンプトを生成する前記ステップ、および前記自然言語プロンプトを前記ユーザに対して提示するステップを、前記会話ボット仕様に基づいて反復して、前記ＡＰＩコールを呼び出す対話フローを実行する、請求項１に記載の方法。
【請求項３】
前記ＡＰＩコールを呼び出すための前記コンピュータ・コードが、前記ＡＰＩコールに関連するサービスを提供するサービス・エンドポイントへのハイパーテキスト転送プロトコル（ＨＴＴＰ）コールを含む、請求項１に記載の方法。
【請求項４】
前記ＡＰＩ仕様が、ウェブＡＰＩ仕様を含む、請求項１に記載の方法。
【請求項５】
前記自然言語プロンプトの生成に応答して、前記自然言語プロンプトを前記ユーザに対して提示するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記会話ボット仕様を構築する前記ステップが、複数の状態および状態遷移を含む有限状態機械（ＦＳＭ）を構築するステップを含み、前記有限状態機械が、前記会話ボットの対話フローを指定し、前記自然言語表現を命令に変換する前記ステップが、自然言語処理に少なくとも基づいて前記自然言語表現をシンボルに変換するステップと、前記ＦＳＭに基づいて前記シンボルを前記命令に変換するステップとを含み、シンボルが、前記自然言語表現中のオブジェクトを表すエンティティと、前記自然言語表現中の目的を表すインテントとを含む、請求項１に記載の方法。
【請求項７】
前記会話ボット仕様が、複数のＡＰＩコールを呼び出すことを含み、前記複数のＡＰＩコールが、１つの対話内で呼び出される、請求項１に記載の方法。
【請求項８】
請求項１ないし７のいずれか１項に記載の方法の各ステップをハードウェアによる手段として構成した、システム。
【請求項９】
請求項１ないし７のいずれか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項１０】
請求項９に記載の前記コンピュータ・プログラムをコンピュータ可読ストレージ媒体に記録した、ストレージ媒体。
【国際調査報告】
2020532011.tif 000018
2020532011.tif 000019
2020532011.tif 000020
2020532011.tif 000021