JP2022027493A - タスク実行のための方法及びシステム - Google Patents

Abstract

【課題】ＡＰＩに関係があるタスクのためのタスク実行の方法等を提供する。【解決手段】方法は、実行のための、ＡＰＩに関係があるタスクオブジェクトの選択を受け取り、タスクオブジェクトがタスクオブジェクト内のプレースホルダー値を含むかどうかを決定し、タスクオブジェクトがプレースホルダー値を含むことに基づいて、タスクオブジェクトで記述されているプレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することを含む。方法はまた、プレースホルダー値を、インターフェースを介して受け取られたユーザ入力に基づく新しい値で置換することと、新しい値を含む、ＡＰＩへのＡＰＩコールを、対象のプログラミング言語で生成することとを含む。方法はまた、実行のために、生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイし、ＡＰＩコールの結果を取得することを含む。【選択図】図８

Description

本開示の実施形態は、アプリケーションプログラミングインターフェース（Application Programming Interface，ＡＰＩ）に関係があるタスクのためのタスク生成、タスク実行、及びタスク結合に関する。

ＡＰＩは、別のコンピュータシステムの機能がアクセス及び／又は呼び出しされることを可能にする便利なメカニズムである。例えば、そのような機能は、データベースによってアクセスされたり、インターネット・オブ・シングス（Internet of Things，ＩｏＴ）デバイスによってアクセスされたり、などするソフトウェアプロジェクトに組み込まれ得る。しかし、そのようなＡＰＩは、所望の機能を実行するために常に最初にセットアップされるわけではない。

本開示の１つ以上の実施形態は、タスクオブジェクトが生成されるべきであるアプリケーションプログラミングインターフェース（ＡＰＩ）の選択を受け取ることと、タスクオブジェクトで使用されるパラメータのアレイを取得することとを含み、パラメータのアレイ内の各要素が、定数値、プレースホルダー値、又はそれらの組み合わせのうちの１つ以上を含み、プレースホルダー値が、タスクオブジェクトの実行中にプレースホルダー値を置換するユーザ入力を引き出すプログラミングを含む、方法を含んでよい。方法はまた、パラメータのアレイを、タスクオブジェクトを実行するＡＰＩのための他の情報と組み合わせて、タスクオブジェクトにすることと、タスクオブジェクトをタスクオブジェクトデータベースに格納することとを含んでもよい。

本開示の１つ以上の実施形態は、実行のための、ＡＰＩに関連したタスクオブジェクトの選択を受け取ることと、タスクオブジェクトがタスクオブジェクト内のプレースホルダー値を含むかどうかを決定することと、タスクオブジェクトがプレースホルダー値を含むことに基づいて、タスクオブジェクトで記述されているプレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することとを含む方法を含んでよい。方法はまた、プレースホルダー値を、インターフェースを介して受け取られたユーザ入力に基づく新しい値で置き換えることと、対象のプログラミング言語でＡＰＩへのＡＰＩコールを生成することとを含んでもよく、ＡＰＩコールは新しい値を含む。方法はまた、生成されたＡＰＩコールを実行のためにターゲットプラットフォーム上でデプロイすることと、ＡＰＩコールの結果を取得することとを含んでもよい。

本開示の１つ以上の実施形態は、１つ以上のタスクから成功した応答の組を取得することを含み、１つ以上のタスクがＡＰＩコールの特定の実施を含む、方法を含んでよい。方法はまた、１つ以上のタスクのうちの第１のタスクに応答する第１応答から情報を取り出すことによって、成功した応答の組のうちの第１応答の第１スキーマを生成することを含んでもよい。方法は更に、第１スキーマを、成功した応答の組のうちの第２応答の第２スキーマとともに、第１スキーマ及び第２スキーマに学習モデルを適用することによってクラスタ化することであり、クラスタ化は、少なくとも第１タスクへの入力及び第１応答に基づく、ことと、第１タスクと、第２応答が応答する第２タスクとを含む統合タスクを、第１スキーマ及び第２スキーマのクラスタ化に基づき生成することを含んでもよい。

実施形態の目的及び利点は、少なくとも、特許請求の範囲で特に指し示されている要素、特徴、及び組み合わせによって、実現及び達成される。

上記の概要及び下記の詳細な説明は両方とも、単に例示及び説明であって、限定ではないことが理解されるべきである。

添付の図面を使用して、更なる特定及び詳細をもって、例となる実施形態について記載及び説明する。

タスクの生成、実行、及び／又は結合を含み得る、ＡＰＩに関連したタスクとともに使用されるシステムの例を表す図である。 タスクのコンピュータ読み取り可能な表現の例を表す。 タスクのカテゴリを選択するためのユーザインターフェースの例を表す。 タスク生成で使用されるユーザインターフェースの例を表す。 タスク生成で使用されるユーザインターフェースの例を表す。 タスク実行で使用されるユーザインターフェースの例を表す。 タスク実行で使用されるユーザインターフェースの例を表す。 タスクの結合の例の視覚表現の例を表す。 タスクの結合の例の視覚表現の例を表す。 タスクの結合の例の視覚表現の例を表す。 タスク生成の方法の例のフローチャートの例を表す。 タスク実行の方法の例のフローチャートの例を表す。 タスク実行の方法の他の例のフローチャートの例を表す。 タスク実行の方法の更なる例のフローチャートの例を表す。 タスク結合の方法の例のフローチャートの例を表す。 成功したタスク実行の応答に基づきスキーマを生成する方法の例のフローチャートの例を表す。 例となるコンピュータシステムを表す。

本開示は、単にタスクとも呼ばれ得るタスクオブジェクトの生成、実行、及び／又は結合に関係がある。タスクは、コンピュータシステムに、特定の目的を達成すべく特定の機能を実行するようＡＰＩの特定の実施を実装させるコンピュータ読み出し可能な命令の組によって表されてよく、プロセスへのユーザ入力を含んでも又は含まなくてもよい。例えば、ユーザは、電子メールアカウントにアクセスする際にＡＰＩサービスを許可する電子メールサービスから、２５個の最近の未読メールにアクセスしたいと望むことがある。例を続けると、タスクは、取得すべき最近の未読メールのうちの何通を取得すべきかを識別し、電子メールサービスにアクセスするためにＡＰＩコールを呼び出し、ＡＰＩコールの結果を提供するプログラミングコードを含んでよい。他の例として、ユーザは、姓が「スミス」である連絡先を抜き取りたいと望むことがあり、電子メールサービスは、ユーザの関連するアドレス帳にアクセスするためにＡＰＩコールを提供してよい。例を続けると、タスクは、ＡＰＩコールを呼び出し且つ／あるいは関連する電子メールアカウントにアクセスするためにクレデンシャルを確かめるプログラミングコードを含んでよい。タスクは、追加的に、又は代替的に、姓に関するユーザ入力を受け取り、連絡先を取得するためにアドレス帳にアクセスするプログラミングコードを含んでもよい。このようなタスクの実施によって、既存のＡＰＩの上に機能が構築されてよく、それにより、ユーザが特定のＡＰＩの動作のコンピュータプログラミング知識を有していようとなかろうと、そのような機能へのアクセスがユーザに提供され得る。

タスク生成中に、アドミニストレータは、ユーザにより識別された数の最近の電子メールを取り出すことといったタスクの目的を達成すべく実行されるべきＡＰＩコールの特定の実施を識別することを可能にされる。いくつかの実施形態で、タスクは、タスクの任意のユーザ入力要素（例えば、電子メールの数又は連絡先の姓、など）のためのプレースホルダー値を含んでよい。例えば、タスク生成中に、アドミニストレータ又は他のユーザは、ユーザ入力値によって置換されるべきプレースホルダー値を提供してよい。そのようなアプローチを使用することによって、各タスクは、生成された後に、たとえデータの組の例（例えば、プレースホルダー値を使用する、など）に対してであったとしても、ＡＰＩコールが所望のタスクを達成すべく呼び出され得るコードの組を表し得る。タスクは、プレースホルダー値を置換することを容易にするようユーザ入力を取得するためにユーザインターフェースが生成されるようにするコードを含んでよい。追加的に、又は代替的に、アドミニストレータは、範囲、権限タイプ、及び／又はクレデンシャル、任意の定数値などのような、タスクに関連した様々な他の情報を含んでもよい。

タスク実行中に、ユーザは、実行のためのタスクを識別してよい。そのような実行は、ローカルで、又は対象となる環境で（例えば、特定のプログラミング言語で、クラウドベースのサービスで、などで）実行されてよい。タスクは、タスクの任意のプレースホルダー値をユーザ入力値で置換することを容易にするために、ユーザが入力を供給し得るインターフェースを実行し、ユーザに提供してよい。タスク実行の応答（例えば、ＡＰＩコールの特定の実施の結果）は、ユーザへ返されてよい。いくつかの実施形態で、応答は、他の使用のために記憶されてよい。

タスク結合中に、所与のタスクの応答のスキーマ（例えば、階層／関係データ表現）が生成されてよい。例えば、応答の様々な要素（例えば、キー値対、ディクショナリ、リスト、など）は、実行されたタスクの応答のコンピュータ読み取り可能な表現を生成するよう処理されてよい。いくつかの実施形態で、タスク及び／又はスキーマは、応答、タイトル、入力、などのような因子に基づき機械学習モデルによりクラスタ化されてよい。タスクのクラスタを用いて、複数のタスクは単一の統合されたタスクに結合され得る。例えば、統合されたタスクは、２つのタスクが統合されたタスク全体を実行するよう協働するように、一方のタスクからの応答（又は応答の部分）を、他方のタスクのプレースホルダー値のための置換として利用してよい。いくつかの実施形態で、ユーザ入力は、第１タスク内のプレースホルダーを置換するために利用されてよく、第１タスクの結果及び追加のユーザ入力の両方は、第２タスク内のプレースホルダー値を置換するために使用されてよい。

いくつかの状況で、本開示の実施形態は、本開示の教示を適用することによってコンピュータの性能の改善を助けることができる。例えば、タスクの生成、使用、及び／又は結合を提供することによって、ＡＰＩは、コンピュータデバイスが従前実行することができなかった方法で利用され得る。例えば、従前利用不可能であった機能が、既存のＡＰＩの上に加えられて達成され得る。更には、改善されたユーザ経験が取得され得、これによって、ＡＰＩの機能は、さもなければ特定の目的に近づくために使用される可能性があるコンピュータプログラミング訓練なしで、個人がアクセス可能な方法で、タスクを介して特定の目的を達成するようデプロイされ得る。例えば、アクセス可能である特定のユーザインターフェースは、プログラミング経験がなくても、提供され得る。更なる例として、特定のＡＰＩコールを介してしか従前アクセスできなかった特定のデータ、デバイス、及び／又は他のリソースは、異なった、より便利且つアクセス可能な方法でアクセスされ得る。例えば、コンピュータプログラミング訓練を有さないエンドユーザは、ＡＰＩ仕様又はＡＰＩに関する他の人間が読むことができる文書若しくはウェブサイトなどの、ＡＰＩに関連するドキュメンテーションを読むことが可能であり得るが、エンドユーザは、所望の目的を達成すべくＡＰＩを実装するために必要とされる訓練を有さなくてもよい。本開示の１つ以上の実施形態に従うタスクは、ＡＰＩにアクセスするそのようなエンドユーザがタスクを介して所望の目的を達成することを助け得る。更なる例として、ユーザは、ＡＰＩのためのコード及び入力が実行のために既に集められ結合され得るということで、実行速度の向上を観測し得る。

添付の図面を参照して、１つ以上の例となる実施形態について説明する。

図１は、本開示の１つ以上の実施形態に従って、タスク生成、タスク実行、及び／又はタスク結合を容易にするための、例となるシステム１００を表す図である。システム１００は、タスクを生成、実行、及び／又は結合するために使用されるタスクシステム１１０を含んでよい。アドミニストレータ１２０は、タスクを生成するために及び／又はタスクの結合を促すためにタスクシステム１１０と相互作用してよい。エンドユーザ１３０は、実行のためのタスクを選択するようタスクシステム１１０と相互作用してよい。１つ以上のＡＰＩ仕様１４０は、タスクシステム１１０によって、様々なＡＰＩに関する情報を取得するためにアクセスされてよい。ＡＰＩホスト１５０は、関連するＡＰＩの機能を呼び出すようタスクを実行するときにアクセスされてよい。クラウドシステム１６０（例えば、クラウドシステム１６０ａ／１６０ｂ）は、タスクによって所与のタスクを実行するよう呼び出され得るリモートシステムに相当してよい。

［タスク生成］
タスクシステム１１０は、ＡＰＩ仕様１４０の１つ以上を取得し、ＡＰＩ仕様１４０から情報をパースし、解析し、又は別なふうに取得してよい。例えば、タスクシステム１１０は、所与のＡＰＩについてのＯｐｅｎＡＰＩ仕様（OpenAPI Specification，ＯＡＳ）にアクセスしてよく、ＡＰＩがアクセスされ得るエンドポイントと、ＡＰＩコールを実行するときに使用されるハイパーテキスト転送プロトコル（ＨＴＴＰ）動詞と、ＡＰＩを呼び出すときに使用されるクエリ入力、ヘッダ入力、パス入力、及び／又は本文入力などの、ＡＰＩで使用される１つ以上の入力とを識別してよい。このような及び他の実施形態で、ＡＰＩ名、ユニフォーム・リソース・ロケータ（Uniform Resource Locator，ＵＲＬ）、又はＡＰＩを識別する他の情報などの、ＡＰＩの夫々の識別子は、ＡＰＩ仕様１４０から取得されてよい。ＯＡＳがＡＰＩ仕様１４０のフォーマットの一例として与えられている一方で、明らかなように、ウェブサービス定義言語（Web Service Definition Language，ＷＳＤＬ）などの、如何なるフォーマット又はスタイルも、ＡＰＩ仕様１４０のために使用されてよい。

いくつかの実施形態で、タスクシステム１１０は、タスクのテンプレートを生成するために、ＡＰＩ仕様１４０から取得された情報を利用してよい。例えば、ＡＰＩコールのヘッダ、本文、入力割り当て、認証プロトコル、などの側面は、ＡＰＩコールが実行されるたびに同じであってよく、そのような入力及び／又は他のコンポーネントはタスクテンプレートに含まれてよい。

いくつかの実施形態で、１つ以上のＡＰＩは、新しいタスクが生成されることと関連付けられるＡＰＩの選択のためにアドミニストレータ１２０に提示されてよい。そのような提示を説明するインターフェースの例は、図３に表されている。いくつかの実施形態で、アドミニストレータ１２０は、テンプレート（又はテンプレートとしての既存のタスク）を選択したり、タスクのために使用されるＡＰＩとしてＡＰＩを選択したり、などしてよい。使用されるＡＰＩを選択した後、アドミニストレータ１２０は、タスクの目的を達成すべくＡＰＩを実装する際に使用される様々なパラメータを選択及び／又は指定するようタスクシステム１１０と相互作用してよい。例えば、タスクシステム１１０は、可能性があるパラメータ及びパラメータを実装するためのオプションをアドミニストレータ１２０に提示するためにフォームビルダーを利用してよい。そのようなパラメータは、定数値、及び／又はユーザ入力が求められる可能性がある値を含んでよい。定数値については、アドミニストレータ１２０は、タスクが実行されるたびに使用される値を指定してよい。そのような値は、ＡＰＩが所望の目的を達成するのを助ける入力又は指示、ＡＰＩが呼び出されるパス（又はその部分）、などを含んでよい。ユーザ入力が求められる値、又はタスクを実行するときにＡＰＩコールを生成する種々のインスタンスで変化し得る値については、アドミニストレータ１２０は、タスクを実行するときに置換され得るプレースホルダー値を供給してよい。プレースホルダー値を使用することによって、タスクは、たとえこれらの値がタスクの実行時に置換されるよう構成されているとしても、プレースホルダー値内のサンプルデータでさえ、ＡＰＩを呼び出すための必要な全てのデータを含んでよい。このような及び他の実施形態で、パラメータは、タスクの望ましい特定の機能の達成を助けるようカスタマイズされた値を含んでよい。例えば、タスクは、呼び出されるべきＡＰＩに基づき構築された特定の機能を達成するよう設計されてよく、パラメータは、ＡＰＩコールへの入力の１つ以上としてパラメータを使用してＡＰＩコールが生成されるときにタスクを達成する値を含んでよい。

いくつかの実施形態で、プレースホルダー値は、セキュリティトークン又は他の認証コンポーネントを含んでよい。例えば、プレースホルダー値は、タスクの実行時に更新／置換され得るユーザ名、パスワード、ＯＡｕｔｈトークンなどを含んでよい。いくつかの実施形態で、タスクシステム１１０は、直接のユーザ入力なしで、タスクの実行時に自動的にトークンを更新してよい。

いくつかの実施形態で、タスクは、タスクを実行するときにエンドユーザ１３０へのユーザインターフェースを生成し又は別なふうに提示する要素を含んでよい。例えば、ユーザインターフェース要素は、パラメータのプレースホルダー値を置換する値を取得するためにユーザ入力を受け取ることを助けるよう生成されてよい。いくつかの実施形態で、ユーザ入力自体が、プレースホルダー値を置換するために使用される値であってもよい（エンドユーザ１３０は、彼らの最近の電子メールのうち何通を彼らが取り出したいかを入力することや、彼らのパスワードを入力すること、などを行ってよい。）。追加的に、又は代替的に、ユーザ入力は、置換値を取得するためのユーザ入力の何らかの処理又は使用によって置換値を生成するために、使用されてもよい（エンドユーザ１３０は、置換値として使用されるトークンを取得するために使用されるクレデンシャルを入力することや、スプレッドシートファイルからシートを選択すること、などを行ってよい。）。いくつかの実施形態で、パラメータの所与の値は、定数値及びパラメータ値の両方の組み合わせであってもよい。例えば（ｆｒｏｍ／ｅｍａｉｌＡｄｄｒｅｓｓ／ａｄｄｒｅｓｓ）ｅｑ‘＜？＞’の、定数値及びプレースホルダーの混合が考えられ、ユーザ入力によって置換可能である＜？＞のプレースホルダー値が、ＡＰＩコールによって入力として使用される単一パラメータとしてタスクの実行中に結合されてよい。

タスクシステム１１０は、タスクを生成するときに種々のタイプのパラメータを利用してよい。例えば、タスクシステム１１０は、タスクに関連したＡＰＩのためのＡＰＩコールのヘッダ内に埋め込まれ得るヘッダパラメータを利用してよい。他の例として、タスクシステム１１０は、ＡＰＩコールの位置を識別するためにアドレス若しくはパスの全て又は一部、あるいは、ＡＰＩコールを実行するときにＡＰＩによって使用されるリソースのパスとして使用され得るパスパラメータを利用してもよい（例えば、パス／ａｐｉ／ｖ２／｛ｕｓｅｒ＿ｉｄ｝／ｐｏｓｔ？ｍｅｓｓａｇｅ＝‘ｘｙｚ’内のフィールドｕｓｅｒ＿ｉｄ）。他の例として、タスクシステム１１０は、ＡＰＩコールを実行するときにＡＰＩによって使用され得るクエリ文字列パラメータを利用してもよい（例えば、パス／ａｐｉ／ｖ２／｛ｕｓｅｒ＿ｉｄ｝ｐｏｓｔ？ｍｅｓｓａｇｅ＝‘ＭＳＧ’内のフィールドＭＳＧ）。いくつかの実施形態で、クエリ文字列パラメータは、エンドユーザ入力によって置換されるプレースホルダー値を含んでよい。更なる例として、タスクシステム１１０は、ＡＰＩコールの本文にパラメータを加えるよう構成され得る要求本文パラメータを利用してもよい。

いくつかの実施形態で、プレースホルダー値については、各プレースホルダーは、プレースホルダーの識別子、プレースホルダーのラベル（例えば、ユーザ入力を取得するためのウェブフォーム又は他のユーザインターフェースで現れるラベル）、ユーザ入力を取得するときにエンドユーザ１３０に提示される命令の組（例えば、期待される入力のタイプ、入力の例、など）、エンドユーザ１３０が選択を行う可能性がある選択肢の組（例えば、汎用的な入力についてはゼロであってよく、あるいは、ユーザが入力を供給するときに“Ａ”と、“Ｂ”と、“Ｃ”との間で選択することができるように、“Ａ”、“Ｂ”及び“Ｃ”を含んでよい。）、及び／又はタイプ（例えば、現在のプレースホルダーがプレースホルダー値の様々な可能性があるカテゴリのうちのどれに対応しているかを識別する。）を含んでよい。いくつかの実施形態で、プレースホルダーのタイプは、トークン（例えば、ＯＡｕｔｈ２トークン、ユーザ名、などであり、ｐｌａｃｅｈｏｌｄｅｒ．ｔｏｋｅｎ．ｏａｕｔｈと指定されてよい。）、文字列（例えば、文字列がユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｓｔｒｉｎｇと指定されてよい。）、整数（例えば、整数がユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｉｎｔと指定されてよい。）、デシマル（デシマルがユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｄｅｃｉｍａｌと指定されてよい。）、数（例えば、数がユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｎｕｍｂｅｒと指定されてよい。）、電子メール（例えば、電子メールがユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｅｍａｉｌと指定されてよい。）、ＵＲＬ（ＵＲＬがユーザからの期待される入力であることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｕｒｌと指定されてよい。）、リスト（例えば、ユーザが１つの項目を選択する可能性があるリストが示されることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｌｉｓｔと指定されてよい。）（リストの要素は、選択肢の組から取得されてよい。）、マルチリスト（例えば、ユーザが複数の項目を選択する可能性があるリストが示されることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｍｕｌｔｉｌｉｓｔと指定されてよい。）（リストの要素は、選択肢の組から取得されてよい。）、及び／又はブール値（パラメータが真又は偽を入力として取得し得ることを示し、ｐｌａｃｅｈｏｌｄｅｒ．ｔｏｋｅｎ．ｂｏｏｌｅａｎと指定されてよい。）を含んでよい。いくつかの実施形態で、複数の値は、ＡＰＩコールのための単一の入力に結合されてよく（例えば、ブール値及び他の定数値又はプレースホルダー値）、リスト又は文字列プレースホルダーとして表されてよい。

いくつかの実施形態で、タスクシステム１１０は、タスクが一貫して実施され得るように、タスクを生成するときに一定のスタイル及び／又は命名規則を利用してよい。タスクオブジェクトのコンピュータ読み出し可能な実施の一例は、図２に表されている。所与のタスクは、タスクに関連したＡＰＩ仕様１４０の識別子、所与のエンドポイント及び／又はＨＴＴＰ動詞について一意であり得るタスクタイトル（例えば、同じタスクタイトルが、異なるＡＰＩベンダー／ＨＴＴＰ動詞に関連した異なるタスクに使用されてよい。）、タスクの記述的要約を与えるタスク記述、タスクによって使用されるパラメータのアレイ（例えば、タスクによって使用されるパラメータと、プレースホルダー値を含むそれらの対応する値とのリストを表すディクショナリ）、ＡＰＩコールの本文内容、ＡＰＩを使用するための及び／又はＡＰＩに関連したユーザアカウントにアクセスするための認証において使用される１つ以上のトークン、タスクを実行するために使用される任意の範囲（例えば、ＡＰＩにアクセスするために所与のクレデンシャルに認められた許可）、現在のタスクが生成された時のタイムスタンプ、タスクを生成したアドミニストレータ１２０の識別子、などのような様々な情報フィールドのうちのいずれかを含んでよい。

いくつかの実施形態で、タスクが生成された後、それは、タスクシステム１１０のタスクデータベース１１２に格納されてよい。タスクデータベース１１２は、実行のためのタスクを選択するためにエンドユーザ１３０によってアクセスされ得る生成されたタスクのリポジトリに相当し得る。追加的に、又は代替的に、アドミニストレータ１２０は、新しいタスクを生成するときにテンプレート又はサンプルとしてタスクデータベース１１２のタスクを使用してもよい。

［タスク実行］
いくつかの実施形態で、タスクシステム１１０は、エンドユーザ１３０によるタスクの実行を助けてよい。例えば、エンドユーザ１３０は、タスクシステム１１０と相互作用してよく、タスクシステム１１０は、タスクデータベース１１２のタスク（例えば、完了されているタスク）をエンドユーザ１３０に提示してよい。いくつかの実施形態で、エンドユーザ１３０は、タスクデータベース１１２からタスクを探す際にテキスト検索又は他のクエリを実行してよい。例えば、検索は、タスクタイトル、記述、ＡＰＩ仕様１４０、ＡＰＩタイトル、などの中から探し得る自然言語クエリ（Natural Language Query，ＮＬＱ）であってよい。いくつかの実施形態で、タスクシステム１１０は、タスクシステム１１０の能力、エンドユーザ１３０の他の検索、検証されたタスク、などに基づきタスクを提案してもよい。追加的に、又は代替的に、エンドユーザ１３０は、ＡＰＩホスト、タスクの目的、タスクの寿命、タスクの作成者、などのようなカテゴリによってタスクの間をナビゲートしてもよい。エンドユーザ１３０は、実行のためのタスクを選択してよい。いくつかの実施形態で、そのような選択は、タスクデータベース１１２からタスクを取り出すために、タスクに関連したＡＰＩ仕様１４０及び／又はタスク識別子を識別してよい。

エンドユーザ１３０が実行のためのタスクを選択した後、タスクシステム１１０は、タスクを実行するようコードを生成するのに必要な全ての情報を取得するための動作を実行してよい。例えば、タスクにプレースホルダー値がある場合には、タスクシステム１１０は、プレースホルダー値を置換するための値を生成するために、エンドユーザ１３０がユーザ入力を供給し得るウェブフォーム又は他のユーザインターフェースを生成してよい。他の例として、タスクシステム１１０は、トークンの寿命を確認してよく、寿命が経過している場合にはトークンをリフレッシュしてよい。如何なる収集された入力及び／又はトークンも用いて、タスクシステム１１０は、エンドユーザ１３０からのユーザ入力に基づいたあらゆるものを含む、タスクからのパラメータを用いて、タスクに関連したＡＰＩへのＡＰＩコールを実装するためのコードを生成してよい。ユーザ入力を求めるプレースホルダー値によらないタスク実行のためのユーザインターフェースの例は、図５Ａに表されており、ユーザ入力が求められるプレースホルダー値を含むタスク実行のためのユーザインターフェースの例は、図５Ｂに表されている。

いくつかの実施形態で、エンドユーザ１３０は、エンドユーザ１３０がＡＰＩコールの実施を望む特定のプログラミング言語を指定してよい。例えば、エンドユーザ１３０は、ＰＹＴＨＯＮ（登録商標）、ＪＡＶＡ（登録商標）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）、などのような言語を選択してよく、タスクシステム１１０は、対象のプログラミング言語に従ってＡＰＩコールを実装するために、対応するプログラミング言語でコードを生成してよい。いくつかの実施形態で、プログラミング言語は、対象のプログラミング言語が、ＡＰＩホスト１５０及び／又はＡＰＩコールが向けられようとしているエンドポイントとの準拠性のために使用され得るように、ＡＰＩホスト１５０によって選択されてよい。プログラミング言語を識別する一例は、図９で更に詳細に説明され得る。

いくつかの実施形態で、エンドユーザ１３０は、エンドユーザ１３０がタスクを実行したい及び／又はタスクのＡＰＩコールが実行されるべきである特定のクラウドシステム１６０を識別してよい。例えば、エンドユーザ１３０は、ＲＵＮＭＹＰＲＯＣＥＳＳ（登録商標）クラウドシステム、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（登録商標）（ＡＷＳ）クラウドシステム、ＭＩＣＲＯＳＯＦＴ（登録商標）クラウドシステム、ＧＯＯＧＬＥ（登録商標）クラウドシステム、などの中で完全に実行されるようタスクを指定してよい。いくつかの実施形態で、ユーザ入力を取得するためのユーザインターフェースの提示を含むタスク実行の全体は、クラウドシステム１６０を介して実装されてよい。例えば、タスクシステム１１０は、クラウドシステム１６０ａに、ユーザ入力を取得するようエンドユーザ１３０への提示のためのユーザインターフェースを生成させるために、クラウドシステム１６０ａのＡＰＩを呼び出してよい。タスクシステム１１０は、次いで、クラウドシステム１６０ａを介して取得されたユーザ入力を用いて完全なＡＰＩコールを生成してよく、完全なＡＰＩコールは、タスクシステム１１０を介して実行されるのではなく、クラウドシステム１６０ａを介したＡＰＩコールの実行のためにクラウドシステム１６０ａへ供給されてよい。クラウドベースのシステムでタスクを実行する一例は、図１０で更に詳細に説明され得る。クラウドシステム１６０が一例として与えられているが、エンドユーザ１３０は、ローカルサーバ（例えば、タスクシステム１１０）、リモートサーバ（例えば、ＡＰＩホスト１５０）、ローカルコンピュータ（例えば、タスクシステム１１０にアクセスするためにエンドユーザ１３０によって使用されるコンピュータデバイス）、などを識別してもよい。

いくつかの実施形態で、タスクの実行に基づくＡＰＩコールの成功した実行を示す結果に基づいて、タスクは、エンドユーザ１３０が、実行すべきタスクを捜し出すときに、あるいは、アドミニストレータ１２０が、テンプレートとしてタスクを追求するときに、どのタスクが実行に成功したかを認識し得るように、タスクデータベース１１２内で、成功と確認されたと注釈を付けられてよい。例えば、チェックマークなどの視覚的なインジケータが、確認済みのタスクを示してもよい。いくつかの実施形態で、結果の一部又は全てがタスクデータベース１１２に格納されてよい。

いくつかの実施形態で、タスクを実行するときに、タスクは、タスクを実行する１つ以上の段階で使用され得るクレデンシャルを含んでよい。例えば、プレースホルダーパラメータのためのユーザ入力を取得するときに、パラメータは、ＡＰＩホスト１５０及び／又はサードパーティコンピュータシステムにより本物であることを証明するためのユーザ名及び／又はパスワードを含んでよい。いくつかの実施形態で、プレースホルダーの１つは、ＯＡｕｔｈ及び／又はＯＡｕｔｈ２トークンなどのＡＰＩトークン、あるいは、任意の他のフォーマットを含んでよい。いくつかの実施形態で、ユーザインターフェースは、エンドユーザ１３０が、タスクシステム１１０へ直接にクレデンシャルを供給するのではなく、ＡＰＩホスト１５０へ直接にクレデンシャルを供給し得るように、ＡＰＩホスト１５０へのアクセスを供給するよう構成されてよい。例えば、サインイン又はユーザ認証のための代替のＡＰＩコールは、タスクのためのＡＰＩコールコードを生成することより前に、ユーザ入力の取得の部分として呼び出され又は使用されてよい。タスクを実行する一例は、図８で更に詳細に説明され得る。

いくつかの実施形態で、タスクシステム１１０は、ＲＥＳＴ ＡＰＩを用いて実装されてよく、且つ／あるいは、ＲＥＳＴ ＡＰＩは、サードパーティなどの他の外部及び／又は内部システムのためにタスクシステム１１０へのアクセスを供給する連絡係として動作してもよい。例えば、タスクにアクセスすること、タスクを要求すること、及びタスクを選択することは、全ての／統合されたタスクのリスト及び実行のためのタスクを取り出すＧＥＴコールなどのＡＰＩコールとして実装されてよい。ＲＥＳＴ ＡＰＩは、ＡＰＩ及び／又はそのリストを取り出すためにタスクデータベース１１２と相互作用してよい。例えば、タスクが実行のために要求される場合に、タスクシステム１１０は、プレースホルダー値を抽出してよく、プレースホルダー情報のバージョンを、入力を供給するためにエンドユーザ１３０が見ることができるフォーマット（例えば、ＨＴＭＬページ）でレンダリングされ得る第１フォーマット（例えば、ＪＳＯＮ）で供給してよい。

トークン認証のためにＲＥＳＴ ＡＰＩを使用する場合に、実行のためのＡＰＩを要求した後、トークンが失効しているか又はエンドユーザのために未だ取得されていない場合には、認証ＵＲＬがユーザに伝えられてよい。ユーザは、認証ＵＲＬによってアクセスされるサイトを介して認証システム（例えば、ＡＰＩホスト１５０）と相互作用してよく、インターフェースシステムは、コールバック認証コードを取得してよく、それを用いてＡＰＩを実行し且つ／あるいは認証システムによりトークンをリフレッシュしてよい。認証コード（例えば、ＯＡｕｔｈ２トークン）を用いて、且つ／あるいは、認証コードをリフレッシュした後、タスクシステム１１０は、認証コードを用いてコードを生成し且つ／あるいはＡＰＩコールを実行し、応答をエンドユーザ１３０へ供給してよい。

［タスク結合］
いくつかの実施形態で、タスクシステム１１０は、タスクが統合されたタスクに結合され得るようにタスクを解析するために、実行されたタスクからのＡＰＩコールの応答のうちの１つ以上を利用してよい。例えば、実行されたタスクからの応答の夫々は、タスクシステム１１０によってタスクデータベース１１２に格納されてよい。タスクシステム１１０は、応答を解析し、応答データを使用して所与の応答についてスキーマを生成してよい。スキーマは、一貫したフォーマットでその所与の応答のデータ表現を含んでよい。例えば、異なる応答は、異なるエンドポイントを使用する同じＡＰＩコールについてさえ、異なる形態又はフォーマットをとってよい。タスクの実行に対して所与の応答をとる例は、図１２で説明され得る。

いくつかの実施形態で、スキーマを生成するためにタスクの実行からの応答を解析する場合に、タスクシステム１１０は、応答のサブセットを考えてよい。例えば、タスクシステム１１０は、成功した応答（例えば、ＡＰＩコールが成功したことを示すコードを有する応答）を考えてよい。いくつかの実施形態で、タスクの実行に対する複数又は全ての成功した応答が、関連したスキーマを生成されてよい。このような及び他の実施形態では、情報応答（例えば、プロトコルレベルの情報を供給するもの）、リダイレクション応答（例えば、認証ＵＲＬがＡＰＩコールのクライアントへ送られる場合など、ＡＰＩコールのクライアントが要求を完了するためのいくつかの動作を行うべきであることを示すもの）、クライアントエラー応答（例えば、ＡＰＩコールのクライアントが関与するエラーが起きたことを示すもの）、及び／又はサーバエラー応答（ＡＰＩホスト１５０が関与するエラーが起きたことを示すもの）などのような特定の応答は、スキーマを生成するための解析から除かれてもよい。特定のＡＰＩホスト１５０については、タスクの実行に対するＡＰＩ応答は、成功したＡＰＩコールを示す２ＸＸの形式を有するコードを含んでよい。

いくつかの実施形態で、タスクシステム１１０は、機械学習モデルを用いてタスク実行の応答を表すスキーマをクラスタ化してよい。例えば、機械学習モデルは、応答（例えば、値の列、電子メールアドレスの組、スプレッドシート、ＵＲＬ又はパス、などを含む応答）のタイプ、ＡＰＩのプロバイダ、タスクの識別子、ＡＰＩの識別子などのような様々な因子のいずれかに基づき応答スキーマをクラスタ化することを学んでよい。いくつかの実施形態で、応答スキーマは、応答スキーマが応答したタスクのプレースホルダー値（例えば、タスク入力）、などに基づいて機械学習モデルによってクラスタ化されてよい。このような及び他の実施形態では、クラスタ化は、いくつか又は全ての因子にわたる単一のプロセスであってよい。追加的に、又は代替的に、タスクの出力（例えば、応答スキーマ）及びタスクへの入力（例えば、プレースホルダー値）に基づいて別個のクラスタ及び／又はクラスタ化が存在してもよい。

クラスタを用いて、タスクシステム１１０は、複数のタスクが単一の目的を実行すべく組み合わされている統合タスクを生成してよい。例えば、一連のタスクは、統合タスクの単一の目的を達成するために独立して又は協同して動作してよい。いくつかの実施形態で、１つのタスクの入力（例えば、プレースホルダー値）は、他のタスクの出力（例えば、応答）によって、両方のタスクを含む統合タスクに書き込まれてよい。そのようなタスクの結合の様々な例は、図６Ａ～６Ｃを参照して例示及び記載される。

そのような統合タスクの一例は、クラウドベースのスプレッドシートプログラムでワークシートを作成するための統合タスクを含む。ワークシートを作成するＡＰＩエンドポイントは、スプレッドシートに対してクラウドドライブ識別子のクラウドベースのシステム内で識別子を利用してよい。別のタスクは、クラウドドライブ識別子を得るために実行可能であってよい。タスクは、統合タスク内の第１タスクがクラウドドライブ識別子を取得することができ、第２タスクが、取得されたクラウドドライブ識別子を、クラウドベースのスプレッドシートプログラムのためのワークシートをどこで作成すべきかの入力として使用することができるように、統合されてよい。

他の例として、エンドユーザ１３０が、クラウドベースのスプレッドシートプログラムに関連したＡＰＩにアクセスするときに、特定のセッションを使用したいと望む場合には、第１タスクは、セッション識別子を構築し及び／又は別なふうに取得するために使用されてよく、セッション識別子は、クラウドベースのスプレッドシートプログラムによる機能を実行する第２タスクに入力として供給されてよい。

いくつかの実施形態で、タスクシステム１１０は、応答スキーマのクラスタに基づいて特定のタスク統合を予測又は示唆してよい。追加的に、又は代替的に、アドミニストレータ１２０は、統合タスクを生成するよう、第１タスクの特定のプレースホルダー値を１つ以上の他のタスクの実行からの応答の１つ以上に手動でマッピングしてよい。いくつかの実施形態で、アドミニストレータ１２０は、統合タスクを生成するようタスクを引き込み又は別なふうに一続きにするためにタスクシステム１１０のＧＵＩを利用してもよい。

本開示の範囲から逸脱せずに、システム１００に対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、システム１１０は、明示的に例示又は記載されていない場合がある他のコンポーネントをいくつでも含んでよい。

図２は、本開示の１つ以上の実施形態に従って、タスク２００のコンピュータ読み出し可能な表現の例を表す。タスク２００は、タスク２００の表現の一例を表し、如何なるそのような表現も使用されてよい。例えば、タスク２００は、タスクが一貫して構造化され得るスキーマ又はフレームワークを表してもよい。スキーマを使用するタスクの具体的な実施は、タスク仕様と呼ばれ得る。

図２に表されているように、タスク２００は、ＡＰＩコールを実行するときに使用されるエンドポイントの識別（＜ｅｎｄｐｏｉｎｔ＞）、使用されるＨＴＴＰ動詞（＜ｈｅｔｔｐ＿ｖｅｒｂ＞）、及びＡＰＩコールを実行するために使用される入力（“ｐａｒａｍｅｔｅｒｓ”：［．．．］）（例えば、ＡＰＩパラメータ）を含んでよい。タスク２００の定義部分内で、タスク２００は、ＡＰＩコールで使用され且つタスク２００によって使用されるタスクタイトル（＜ｔａｓｋ ｔｉｔｌｅ＞）、タスク記述（“ｔａｓｋ＿ｄｅｓｃ”：＜ｔａｓｋ＿ｄｅｓｃｒｉｐｔｉｏｎ＞）、及びタスクのパラメータ（“ｐａｒａｍｓ”：｛・・・）を含んでよい。図２に表されているように、タスク２００は、文字列値を入力として期待する（“ｔｙｐｅ”：“ｐｌａｃｅｈｏｌｄｅｒ．ｓｔｒｉｎｇ）プレースホルダー２１０を含む。変数名（“ｎａｍｅ”）はｃｏｕｎｔ＿ｖａｒであり、ユーザが入力を入力するために提示されるラベル（“ｌａｂｅｌ”）は、“ｅｎｔｅｒ ｔｏｔａｌ ｎｕｍｂｅｒ ｏｆ ｒｅｔｒｉｅｖｉｎｇ ｒｅｃｏｒｄｓ”（取り出す記録の総数を入力されたい）と記載する命令を含む“Ｎｕｍｂｅｒ ｏｆ ｒｅｃｏｒｄｓ”（記録の数）である。置換されるべきプレースホルダー値（“ｖａｌｕｅ”）は、最初は１である。ＡＰＩコールが実装される場合に、ＡＰＩコールで使用されるＡＰＩパラメータの１つ以上は、タスク“ｓｅａｒｃｈ”：“ｂｉｌｌ”、“ｃｏｕｎｔ”：“｛％・・・で置換される。このとき、カウント（ｃｏｕｎｔ）値は、ユーザ入力で置換され得る。

図２に表されているように、タスク２００は、期待される応答タイプ（“ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ”：＜ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＞）、ＡＰＩコールの本文内容（“ｂｏｄｙ”：＜ｂｏｄｙ＿ｃｏｎｔｅｎｔ＞）、ＡＰＩコールを生成するときに使用されるトークン（“ｔｏｋｅｎ”：＜ｔｏｋｅｎ＞）、ＡＰＩコールを生成するときに使用される範囲（“ｓｃｏｐｅ”：＜ｓｃｏｐｅｓ＞）、タスクが生成された時のタイムスタンプ（“ｔｉｍｅｓｔａｍｐ”：＜ｄａｔｅ＿ｔｉｍｅ＞）、及び／又はタスクを生成したアドミニストレータ（“ｕｓｅｒ＿ｉｄ”：＜ｕｓｅｒ＿ｉｄ＞）を更に含んでもよい。

本開示の範囲から逸脱せずに、タスク２００に対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、タスク２００は、明示的に例示又は記載されていないことがある他のコンポーネントをいくつでも含んでよい。例えば、ユーザ入力を求める単一のパラメータが表されているが、パラメータはいくつでも識別されてよく、定数値、プレースホルダー値、又はそれらの組み合わせを含んでよい。

図３は、本開示の１つ以上の実施形態に従って、タスクのカテゴリを選択するためのユーザインターフェース３００の例を表す。例えば、アドミニストレータは、タスクを生成するときにテンプレートとして使用するＡＰＩ又はサンプルタスクの選択を助けるようユーザインターフェース３００を提示されてよい。

ユーザインターフェース３００は、所与のＡＰＩを表す１つ以上のウィンドウ３１０（例えば、ウィンドウ３１０ａ、３１０ｂ、３１０ｃ及び３１０ｄ）を含んでよい。いくつかの実施形態で、ウィンドウ３１０に対応するＡＰＩの情報は、ＡＰＩ仕様（例えば、ＡＰＩのＯＡＳ）を介して取得されてよい。一例としてウィンドウ３１０ｃを使用すると、ウィンドウ３１０ｃは、タイトル３１２ｃ、バージョン３１４ｃ、記述３１６ｃ、及びボタン３１８ｃを含んでよい。ボタン３１８ｃを呼び出すことによって、アドミニストレータは、ウィンドウ３１０ｃに関連した所与のＡＰＩを用いて実行され得るタスクのリストに導かれ得る。例えば、タスクは、既に生成されたタスク、ＡＰＩに関連したタスクのテンプレート、などを含んでよい。

本開示の範囲から逸脱せずに、ユーザインターフェース３００に対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、ユーザインターフェース３００は、明示的に例示又は記載されていないことがある他のコンポーネントをいくつでも含んでよい。例えば、代表的なＡＰＩのためのウィンドウ３１０は、その代表的なＡＰＩの供給元、製造元などを識別するロゴ又は他のインジケータを含んでもよい。

図４Ａ及び４Ｂは、本開示の１つ以上の実施形態に従って、タスク生成で使用されるユーザインターフェース４００ａ及び４００ｂの例を夫々表す。

図４Ａに表されているように、生成のためにタスクを選択すると、アドミニストレータは、そのタスクの生成を助ける一連のユーザインターフェース要素を提示されてよい。例えば、アドミニストレータは、（例えば、ドロップダウンメニューから）ＡＰＩにアクセスするエンドポイント及びＡＰＩコールを実行するＨＴＴＰ動詞を選択することをプロンプトされてよい。アドミニストレータは更に、タスクのタイトル及び／又は記述、認証のタイプ、適用範囲、などについてプロンプトされてもよい。いくつかの実施形態で、認証のタイプ及び適用範囲などの特定の側面は、選択されたＡＰＩ及び／又はエンドポイントに基づいて予め入力されるか又は強制されてよい。

インターフェース４００ｂにより図４Ｂで表されているように、アドミニストレータは、ウィンドウ４１０を提示されてよく、それを介して、アドミニストレータは、定数値パラメータ及び／又はプレースホルダーパラメータに関するデータを入力してよい。例えば、アドミニストレータは、見出し「動的な値」の下にプレースホルダーパラメータを供給してよく、プレースホルダー値の名称、ラベル、記述、値、及び／又はタイプを入力してよい。

明らかなように、図４Ａ及び４Ｂは、インターフェース４００ａ及び４００ｂの例を表すが、インターフェースの変形はいくつでも、タスクの生成を助けるために使用されてよい。

本開示の範囲から逸脱せずに、ユーザインターフェース４００ａ及び４００ｂに対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、インターフェース４００ａ及び４００ｂは、明示的に例示又は記載されていないことがある他のコンポーネントをいくつでも含んでよい。

図５Ａ及び５Ｂは、本開示の１つ以上の実施形態に従って、タスク実行で使用されるユーザインターフェース５００ａ及び５００ｂの例を表す。図５Ａは、認証トークンが現下であり、他の入力がユーザから不要であるタスクが実行される例を表す。図５Ｂは、認証トークンが現下であり、入力がユーザから必要とされるタスクが実行される例を表す。

図５Ａに表されているように、実行されるべきタスクは、「マイクロソフトＯｕｔｌｏｏｋ電子メールから最新メッセージを取得する」との記述とともに、タイトル「最新のＯｕｔｌｏｏｋ電子メールの取得」を有してよい。タスクは、ＨＴＴＰ動詞ＧＥＴとともにエンドポイント／ｍｅ／ｍｅｓｓａｇｅｓを使用してよい。ＡＰＩは、ＯＡｕｔｈ２トークンを使用して、ＡＰＩホスト（例えば、ＭＩＣＲＯＳＯＦＴ）によりユーザ及び／又は彼らのアカウントを確かめてよい。しかし、認証トークンは、ユーザがＡＰＩホストにより既に本物であることを確認されていると指示され得るように、ユーザと関連付けられたものとして格納されてもよい。表されているように、更なるパラメータは、タスクが更なる入力なしでいつでも実行可能であるように、求められない。

図５Ｂに表されているように、実行されるべきタスクは、「Ｏｕｔｌｏｏｋから最新のＮ通の電子メールメッセージを取得する」との記述とともに、タイトル「最新の電子メールの取得」を有してよい。図５Ａで表されたタスクと同じエンドポイント、動詞、及び認証トークンが使用される。インターフェース５００ｂはフィールド５１０を含み、フィールド５１０を介して、ユーザは、Ｎの値を入力することをプロンプトされる。例えば、ユーザは、タスクを実行するときに、何通の電子メールを取り出すべきかを識別する整数をフィールド５１０に入力することが可能であってよい。いくつかの実施形態で、値を入力した後、ユーザは、入力が成功した、適切に形成された、などの確認メッセージを、ユーザインターフェース５００ｂを介して提示されてよい。

本開示の範囲から逸脱せずに、ユーザインターフェース５００ａ及び５００ｂに対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、インターフェース５００ａ及び５００ｂは、明示的に例示又は記載されていないことがある他のコンポーネントをいくつでも含んでよい。

図６Ａ、６Ｂ及び６Ｃは、本開示の１つ以上の実施形態に従って、統合タスク６００ａ、６００ｂ、及び６００ｃへのタスクの結合の例の視覚表現の例を夫々表す。図６Ａ、６Ｂ及び６Ｃに表されているように、ユーザ入力６１０は、１つ以上のタスク６３０を実行するときにエンドユーザによって供給されてよい。タスクは、実行中のタスク６３０のプレースホルダー値６３２及び出力６３４を含んでよい。統合タスク６００の完了後、出力６２０が実現され得る。統合タスク６００ａ、６００ｂ及び６００ｃの例は、実例にすぎない。タスク結合の如何なる組み合わせ及び／又は順序も、本開示に従って統合タスクを導出するために利用されてよい。

図６Ａに表されているように、タスク６３０ａを実行するときに、ユーザ入力６１１ａは、プレースホルダー６３２ａのための置換値を生成するために取得されてよく、ユーザ入力６１１ｂは、プレースホルダー６３２ｂのための置換値を生成するために取得されてよい。置換値を使用して、タスク６３０ａは、関連するＡＰＩコールを生成し応答６３４ａを取得するために、使用されてよい。応答６３４ａは、次いで、追加のユーザ入力を求めるのではなく、タスク６３０ｂのプレースホルダー６３２ｃのための置換値として使用されてよい。タスク６３０ｂを実行するときに、タスク６３０ｂは、入力６１１ｃに基づく置換値によるプレースホルダー６３２ｄの置換を促すようユーザ入力６１１ｃを取得してよい。タスク６３０ｂの実行は、応答６４３ａ及びユーザ入力６１１ｃに基づく置換値を使用する対応するＡＰＩコールの生成をもたらし得る。対応するＡＰＩコールは、統合タスク６００へ出力６２０として供給され得る出力６３４ｂをもたらし得る。

図６Ａから明らかなように、２つのタスクを一続きにすることによって、ユーザ入力６１１ｃと他のタスクの応答６３４ａとのハイブリッドは、タスク６３０ｂを実行することによってＡＰＩコールを生成するために使用され得る。

図６Ｂに表されているように、統合タスク内の第２タスク（タスク６３０ｄ）が、第２タスク６３０ｂのプレースホルダー６３２ｅ及び６３２ｆのための置換値を生成するために、ユーザ入力と先のタスク（タスク６３０ｃ）の出力との両方を使用するのではなく、第２タスク６３０ｄは、タスク６３０ｃの出力６３４ｃ及び６３４ｄなどの、１つ以上の先のタスクの出力６３４を使用してよい。両方ともタスク６０３ｃから来るものとして表されているが、明らかなように、先のタスクはいくつでも、タスク実行のための置換値を生成するときに後のタスクへの先のタスクの出力の１つ以上に寄与してよい。

タスク６３０ｃの出力６３４ｃ及び６３４ｄを使用して、タスク６３０ｄは、出力６２０を促し得る出力６３４ｅ及び６３４ｆを生成してよい。

図６Ｃに表されているように、いくつかの実施形態で、タスク６３０ｄ、６３０ｃ、及び６３０ｆのストリングが、統合タスク６００ｃを生成するときに使用されてよい。例えば、第１タスク６３０ｄは、タスク６３０ｄのＡＰＩコールに基づき出力６３４ｇを生成してよい。出力６３４ｇは、プレースホルダー６３２ｇのための置換値を生成するために使用されてよく、一方、タスク６３０ｅの他のプレースホルダーは、ユーザ入力に基づき生成された置換アスク（ask）有してよい。ＡＰＩコールは、出力６３４ｈをもたらす置換値に基づきタスク６３０ｅについて生成されてよい。出力６３４ｈは、タスク６３０ｆのプレースホルダー６３２ｆのための置換値を生成するために使用されてよい。タスク６３０ｆは、タスク６３０ｆに対応するＡＰＩコールを生成するときに置換値を生成するためにユーザ入力及びタスク６３０ｅの出力を用いて実行されてよい。そのようなタスク（ユーザ入力と、１つ以上の先のタスクの出力とを使用してもしなくてもよい。）はいくつでも、統合タスク６００ｃの最終的な出力６２０をもたらし得る。

本開示の範囲から逸脱せずに、統合タスク６００ａ、６００ｂ及び６００ｃに対して、変更、追加、又は削除が行われてよい。例えば、いくつかの実施形態で、統合タスク６００ａ、６００ｂ及び／又は６００ｃは、明示的に例示又は記載されていないことがある他のコンポーネントをいくつでも含んでよい。例えば、任意の構成でマッピングされた任意の数のプレースホルダー及び／又は出力を有している任意の数のタスクが、本開示内で考えられている。

図７～１２は、本開示に従う様々な例となる方法の様々なフローチャートを表す。図７～１２に表されている様々な方法の１つ以上の動作は、図１のタスクシステム１１０、及び／又は図１３のコンピュータシステム１３００などの、システム若しくはデバイス、又はそれらの組み合わせによって実行されてよい。別個のブロックとして表されているが、図７～１２に表されている方法の様々なブロックは、所望の実施に応じて、更なるブロックに分割されても、より少ないブロックにまとめられても、あるいは削除されてもよい。

図７は、本開示の１つ以上の実施形態に従って、タスク生成の例となる方法７００の例となるフローチャートを表す。

ブロック７１０で、ＡＰＩの１つ以上の仕様が取得されてよい。例えば、タスクシステム（例えば、図１のタスクシステム１１０）が１つ以上のＡＰＩ仕様（例えば、図１のＡＰＩ仕様１４０）にアクセスしてよい。いくつかの実施形態で、ＡＰＩ仕様は、ＯＡＳフォーマットであってよく、且つ／あるいは、ＡＰＩホスト（例えば、図１のＡＰＩホスト１５０）によってホストされてよい。

ブロック７２０で、ＡＰＩの夫々についての識別子が仕様から取り出されてよい。例えば、タイトル、ＵＲＬ、記述、バージョン、などがＡＰＩから取り出されてよい。このような及び他の実施形態では、ＡＰＩを呼び出すことに関連したエンドポイント、認証タイプ、ヘッダ及び／又は本文などのような追加情報も、仕様から取り出されてよい。

ブロック７３０で、ＡＰＩ識別子が提示されてよい。例えば、アドミニストレータ（例えば、図１のアドミニストレータ）は、タスクシステム（図１のタスクシステム１１０）と相互作用するときに、生成されるべきタスクの基礎を形成するために利用可能であるＡＰＩのリストを提示されてよい。そのような提示の一例は、図３に表されている。

ブロック７４０で、タスクオブジェクトが生成されるべきであるＡＰＩの選択が受け取られてよい。例えば、アドミニストレータは、特定のＡＰＩ、タスクのテンプレート、前から存在するタスク、などを選択してよい。このような及び他の実施形態では、アドミニストレータは、タスクを生成するためのＡＰＩを選択するときに、既存のタスクを編集、コピー、などすることを選択してもよい。

ブロック７５０で、グラフィカルユーザインターフェース（ＧＵＩ）が提示されてよく、それを介して、ユーザはタスクオブジェクトの側面を選択する。例えば、アドミニストレータは、タスクに関連したタイトル、記述、及び１つ以上のパラメータ又は値などの、タスクに関する情報をアドミニストレータが入力し得るＧＵＩの１つ以上の要素を提示されてよい。

ブロック７６０で、タスクオブジェクトで使用されるパラメータのアレイが取得されてよい。例えば、アドミニストレータは、１つ以上のプレースホルダー値及び／又は１つ以上の定数値をタスクでのパラメータとして識別するためにブロック７５０のＧＵＩを利用してよい。

ブロック７７０で、パラメータのアレイは、タスクオブジェクトを実行するために、他の情報及び／又はＡＰＩのための入力とともにタスクオブジェクトにまとめられてよい。そのような情報は、例えば、ブロック７２０で取り出された情報のいずれかを含んでもよい。いくつかの実施形態で、ブロック７７０の完了時、タスクオブジェクトは、ＡＰＩコールがタスクの所望の目的を達成すべく実行され得るように、全てのプログラミングコード及び／又は情報を含んでよい。

図８は、本開示の１つ以上の実施形態に従って、タスク実行の例となる方法８００の例となるフローチャートを表す。

ブロック８０５で、タスクオブジェクトの選択が供給されてよい。例えば、エンドユーザ（図１のエンドユーザ１３０）が、タスクシステム（図１のタスクシステム１１０）と相互作用して、実行されるべきタスクを選択してよい。タスクオブジェクトは、ＡＰＩ仕様（例えば、図１のＡＰＩ仕様１４０）で記述されているように特定のＡＰＩと関係づけられ得る。このような及び他の実施形態では、タスク選択は、ＡＰＩ仕様及びタスクを識別してよく、この識別は、異なるＡＰＩにわたって同じタスク名を認め得る（例えば、タスクタイトル「最新の電子メールの取得」は、複数の電子メールプロバイダＡＰＩにわたって使用されてよい。）。

ブロック８１０で、タスクオブジェクトがプレースホルダー値を含むかどうかが決定されてよい。例えば、タスクシステムは、タスクがプレースホルダー値を含むかどうかを決定するためにタスクオブジェクトパラメータを見るよう、コンピュータ読み取り可能なタスクオブジェクトのシンタックスをパースしてよい。タスクオブジェクトがプレースホルダー値を含む場合には、方法８００はブロック８１５へ進んでよい。タスクオブジェクトがプレースホルダー値を含まない場合には、方法８００は、ブロック８４０へ直接進んでよい。

ブロック８１５で、プレースホルダー値が期限付きトークンであるかどうかが決定されてよい。例えば、タスクシステムは、プレースホルダー値のいずれかがＯＡｕｔｈ２トークン又は何らかの他の期限付き認証クレデンシャル／トークンであるかどうかを確認してよい。プレースホルダートークンのいずれかが期限付きトークンを含む場合には、方法８００はブロック８２０へ進んでよい。どのプレースホルダートークンも期限付きトークンを含まない場合には、方法８００はブロック８３０へ進んでよい。いくつかの実施形態で、セキュリティトークン又は他の認証クレデンシャルはパラメータとして含まれ得るが、更新されるパラメータでなくてもよい。

ブロック８２０で、トークンが失効しているかどうかが決定されてよい。例えば、タスクシステムは、トークンのメタデータを観察してよく、それをセキュリティポリシーと比較してよい。他の例として、トークンは、トークンを照合するために認証システムへ供給されてもよい。トークンが失効している場合には、方法８００はブロック８２５へ進んでよい。トークンが失効していない場合には、方法はブロック８３０へ進んでよい。

ブロック８２５で、トークンは、ユーザ入力に基づきリフレッシュされてよい。例えば、トークンを認証するとき、サインインのためのＵＲＬが認証システムによって返されてよく、関連するページが、トークンをリフレッシュするようエンドユーザを認証するために彼らに提示されてよい。他の例として、エンドユーザは、ユーザ名／パスワード、ＰＩＮ、ローカルで記憶されたセキュリティ証明書、又は何らかの他のセキュリティクレデンシャルについてプロンプトされてもよい。いくつかの実施形態で、トークンは、ユーザ入力なしでタスクシステムによって自動的にリフレッシュされてもよい。

ブロック８３０で、プレースホルダー値に関するユーザ入力を受け取るためのインターフェースが生成されてよい。例えば、ウェブフォームが、エンドユーザに入力についてプロンプトするためにタスクシステムによって生成されてよい。他の例として、クラウドベースのシステムのＡＰＩが、クラウドベースのシステムに、エンドユーザに入力についてプロンプトするようインターフェースを生成させるために、呼び出されてもよい。更なる例として、別のページがフレーム（例えば、ｉＦｒａｍｅ）内で開かれてもよく、これを介して、エンドユーザは、クレデンシャルを供給することをプロンプトされる。

ブロック８３５で、プレースホルダー値が、ユーザ入力に基づく新しい値で置換されてよい。例えば、タスクシステムは、タスクオブジェクトのパラメータのアレイにおいてプレースホルダー値を直接にユーザ入力で置換してもよい。他の例として、タスクシステムは、プレースホルダー値を置換するための値に至るためにユーザ入力に基づき何らかの処理又は他の操作若しくはフォーマット化を実行してもよい。例えば、ユーザ入力が、リスト内の１つ以上の項目を選択するクリックである場合には、選択は、ＡＰＩコールによって使用可能なシンタックスにフォーマット化されてよい。

ブロック８４０で、最終のタスクコンテンツが、タスクオブジェクトのパラメータのアレイに基づいて生成されてよい。例えば、タスクシステムは、プレースホルダー値を置換する何らかの新たに生成された値、ＡＰＩコールのヘッダ、ＡＰＩコールの本文、コールのエンドポイント、ＡＰＩコールのＨＴＴＰ動詞、ＵＲＬクエリ、ＵＲＬパス、などを含むパラメータのアレイをコンパイルしてよい。

ブロック８４５で、ＡＰＩへのＡＰＩコールが、対象のプログラミング言語で生成されてよい。例えば、エンドユーザは、彼らがＡＰＩコールに実装したい特定のプログラミング言語を識別してよい。他の例として、エンドユーザによって（又はタスクを生成する場合にアドミニストレータによって）選択された所与のエンドポイントは、特定のプログラミング言語を利用してよく、対象のプログラミング言語は、その特定のプログラミング言語に対応してよい。いくつかの実施形態で、ＡＰＩコールのためのＨＴＴＰ要求のタイプは、タスクによって識別及び／又は指定されてよい。このような及び他の実施形態では、対象のプログラミング言語及び／又はＨＴＴＰ要求のタイプに基づいて、タスクオブジェクトのパラメータを利用してＡＰＩコールを実装するプログラミングコードが、生成され得る。例えば、ＨＴＴＰ動詞が“ＧＥＴ”である場合に、ＧＥＴ要求のＡＰＩコールは、タスクのパラメータに従う対象のプログラミング言語で生成され得る。いくつかの実施形態で、プログラミングコードは、ＡＰＩ本文、ヘッダ、ＵＲＬクエリ、などのような、最終のタスクコンテンツの各セグメントの対象に基づいて、セグメントにおいて実装されてよい。

ブロック８５０で、ＡＰＩコールは、ターゲットプラットフォーム上でデプロイされてよい。例えば、タスクシステムは、ＡＰＩコールをローカルで及び／又はクラウドベースのシステム上でデプロイしてよい。いくつかの実施形態で、ローカルシステムは、ＡＮＤＲＯＩＤ（登録商標）又はｉＯＳ（登録商標）オペレーティングシステムを使用するモバイル機器、ＷＩＮＤＯＷＳ（登録商標）又はＭａｃＯＳ（登録商標）オペレーティングシステムを使用するコンピュータデバイス、ウェブブラウザ、などのように、如何なるオペレーティングシステム又は構造も使用してよい。

ローカルでＡＰＩコールをデプロイする場合に、タスクシステムは、上述されたようにプログラミングコードを生成し、ローカルでコードを実行してよい。

クラウドベースのシステム上でＡＰＩコールをデプロイする場合に、タスクシステムは、ウェブジェネレータＡＰＩコールを利用してよく、これを介して、タスクシステムは、特定の機能を実行するようクラウドベースのシステムを呼び出してよい。コンテンツをＨＴＭＬコードで置換し、且つ／あるいは、ＨＴＭＬコードを別なふうに生成するために、スクリプトが使用されてもよい。ＨＴＭＬコードは、タスクに基づいてＡＰＩコールを用意するようタスクを実行するときに入力を生成及び／又は選択する際にユーザ及び／又はアドミニストレータとインターフェース接続するために、クラウドベースのシステムによって実行されてよい。いくつかの実施形態で、クラウドベースのシステムは、ＡＰＩコールを実行するために他の安全なクラウドベースのシステムとインターフェース接続してもよい。

いくつかの実施形態で、クラウドベースのシステムは、ユーザのトークンを取得及び／又は記憶してよく、それにより、トークンは、タスクを実行するときに使用及び／又は再利用され得る。例えば、クラウドベースのシステムがユーザを認証しようと試みる場合に、それが新しいユーザであるか、あるいは、そのユーザのトークンが失効しているならば、認証ＵＲＬが認証システムによって返されてよい。クラウドベースのシステムは、認証ＵＲＬのページをエンドユーザへ伝えてよく、ユーザが本物であることを証明するためにクレデンシャルをサブミットした後にコールバック情報をリッスンしてよい。クラウドベースのシステムは、追加的に、又は代替的に、結果を記憶するために及び／又はエンドユーザの更新されたトークンを記憶するためにＡＰＩコール及び／又は認証プロセスからの応答をモニタしてもよい。

いくつかの実施形態で、クラウドベースのシステムは、エンドユーザが、タスクシステムと相互作用するのではなく、タスクを要求、識別及び／又は実行するためにクラウドベースのシステムとインターフェース接続し得るよう、タスクのデータベースを供給及び／又は保持してよい。

ブロック８５５で、ＡＰＩコールの結果が受け取られてよい。例えば、フレーム又はブラウザウィンドウが開かれてよく、その中に結果が表示され得る。他の例として、タスクシステムとのユーザインターフェースが直接に結果を表示してもよい。いくつかの実施形態で、結果は表示されなくてもよい（タスクが電子メールを送信する場合には、表示される応答はなくてもよい。）。このような及び他の実施形態では、タスクの実行に成功したという確認が表示されてもよい。いくつかの実施形態で、ＡＰＩコールの結果は記憶されるか、又は別なふうに処理されてもよい。

図９は、本開示の１つ以上の実施形態に従って、タスク実行の他の例となる方法９００の例となるフローチャートを表す。方法９００は、図８のブロック８４５及び／又は８５０の例となる実施であってよい。

ブロック９１０で、対象のプログラミング言語が選択されてよい。例えば、エンドユーザ（例えば、図１のエンドユーザ１３０）が、ＡＰＩコールが実行されるべきである特定のプログラミング言語を識別してよい。他の例として、アドミニストレータ（例えば、図１のアドミニストレータ１２０）が、タスクを生成するときにプログラミング言語を選択してよく、その下で、タスクは実行され得る。いくつかの実施形態で、プログラミング言語は、ＡＰＩコールが向けられ得るエンドポイントの能力に基づいて選択されてもよい。

ブロック９２０で、ＨＴＴＰ要求のタイプ（例えば、ＨＴＴＰ動詞）が識別されてよい。例えば、ＡＰＩコールはＧＥＴ要求、ＰＵＴ要求、ＰＡＴＣＨ要求、などを用いてよい。いくつかの実施形態で、ＨＴＴＰ要求のタイプは、アドミニストレータによってセットされてよく、且つ／あるいは、エンドポイントの設定に基づいてもよい。他の例として、ＨＴＴＰ要求のタイプは、タスクの目的に基づいて決定されてもよい。

ブロック９３０で、対象のプログラミング言語におけるソースコードが、ＨＴＴＰ要求を呼び出すために取得されてよい。例えば、対象のプログラミング言語がＰＹＴＨＯＮであり、ＨＴＴＰ要求のタイプがＧＥＴである場合に、ＰＹＴＨＯＮを用いてＧＥＴ要求を実装するための対応するコードが取得されてよい。追加的に、又は代替的に、タスクに基づいてＡＰＩに関連した残りの入力（例えば、ＡＰＩパラメータ）、本文、ヘッダ、などは、ブロック９３０の完了後に、タスクの目的を達成するよう構成されている完全ＡＰＩコールが生成され得るように、対象のプログラミング言語でコードとともに符号化されてよい。

ブロック９４０で、ＨＴＴＰ要求は、取得されたソースコードを用いてポストされてよい。例えば、完全なＡＰＩコールは、対象のプログラミング言語を用いてＨＴＴＰ要求を実装するようポストされてよい。

図１０は、本開示の１つ以上の実施形態に従って、タスク実行の更なる例となる方法１０００の例となるフローチャートを表す。方法１０００は、図８のブロック８４５及び／又は９５０の例となる実施であってよい。

ブロック１０１０で、別のＡＰＩコールが、ユーザ入力を受け取るためのウェブフォームを生成するために、クラウドベースのコンピュータシステムと相互作用するよう呼び出されてよい。例えば、全体のタスク実行がクラウドベースのコンピュータシステム（例えば、図１のクラウドベースのシステム１６０）により実行されるべきである場合には、タスクシステム（例えば、図１のタスクシステム１１０）は、クラウドベースのコンピュータシステムに、エンドユーザ（図１のエンドユーザ１３０）がユーザ入力（例えば、タスクのプレースホルダー値のための置換値、クレデンシャル、など）を供給し得るインターフェースを生成させるよう、クラウドベースのコンピュータシステムへのＡＰＩコールを呼び出してよい。

ブロック１０２０で、クラウドコンピュータシステムは、クラウドベースのコンピュータシステムの環境内に、タスクに関連したＡＰＩコールを実装させられてよい。例えば、タスクのプレースホルダー値のためのユーザ入力を収集し、ユーザ入力に基づいてプレースホルダー値を置換し、完成したＡＰＩコールを生成するためのあらゆる他の情報を収集した後、タスクシステムは、クラウドベースのコンピュータシステムの環境内にＡＰＩコールを実装するための命令によりクラウドベースのコンピュータシステムへのＡＰＩコールを実装するようコンピュータプログラミングコードを供給してよい。

図１１は、本開示の１つ以上の実施形態に従って、タスク結合の例となる方法１１００の例となるフローチャートを表す。

ブロック１１１０で、タスクの１つ以上の成功応答が取得されてよい。例えば、タスクを実行するときに、タスクは、１つ以上の定数値及び／又はプレースホルダー値を用いてＡＰＩコールを生成してよい。ＡＰＩコールへの応答は、解析又は他の検討のためにタスクデータベースに格納されてよい。

ブロック１１２０で、第１タスクへの第１応答のスキーマが生成されてよい。例えば、第１タスクに対応するＡＰＩコールへの第１応答のデータは、一貫したフォーマットでＡＰＩ応答のデータ表現を表し得る第１応答のスキーマを生成するよう解析、パース、などされてよい。スキーマを生成する一例は、図１で更に詳細に説明され得る。

ブロック１１３０で、スキーマは、他のスキーマとともに、学習モデルをそれらのスキーマに適用することによってクラスタ化されてよい。例えば、学習モデルは、応答タイプ、ＡＰＩの名称、などに基づいてスキーマをクラスタ化してよい。追加的に、又は代替的に、学習モデルは、プレースホルダー値に基づいてスキーマをクラスタ化してもよい。このようにしてスキーマをクラスタ化することによって、タスクシステムは、１つのタスクの実行からの応答が、他のタスクでプレースホルダーのための置換値を生成するために使用され得るように、１つ以上のタスクの間の特定の接続を予測又は示唆してよい。例えば、タスクシステムは、後のタスクによって置換値を生成するために使用される入力のタイプ又は値を識別してよく、そして、タスクの実行に対する応答がその入力のタイプ又は値であるところのタスクを示唆してよい。

ブロック１１４０で、第１タスクと第２タスクとの間の１つ以上の接続を識別するユーザ入力が受け取られてよい。例えば、アドミニストレータは、２つのタスク間の示唆された接続を確認してよい。他の例として、アドミニストレータは、タスク間の接続を手動でマッピングしてもよい。

ブロック１１５０で、第１タスク及び第２タスクを含む統合タスクが生成されてよい。例えば、ブロック１１４０で受け取られたユーザ入力に基づいて、タスクシステムは、第１タスクと第２タスクとの間の接続を実装し得る対応するプログラミングコードを生成してよく、それにより、統合タスクが実行される場合に、接続は実装される。例えば、接続が、第２タスクの実行の応答が、第１タスクのプレースホルダー値の１つのための置換を生成するために使用されること、である場合には、統合タスクは、置換値のためのユーザ入力を求めるのではなく、第２タスクの実行の応答が置換値を生成するために使用され得るようなプログラミングを含んでよい。

図１２は、本開示の１つ以上の実施形態に従って、成功したタスク実行の応答に基づいてスキーマを生成する例となる方法１２００の例となるフローチャートを表す。

ブロック１２１０で、応答が取得されてよく、変数ｉが初期化されてよい。例えば、所与のタスクは、ＡＰＩコールを生成し送信するよう実行されてよい。ＡＰＩコールからの応答は記憶されてよい。追加的に、又は代替的に、そのような応答は、データベースから呼び戻されてよい。このような及び他の実施形態で、応答は１つ以上のデータオブジェクトを含んでよい。いくつかの実施形態で、応答のエンプティ（empty）スキーマは初期化されてよく、それに対して、応答のデータオブジェクトは加えられてよい。

ブロック１２２０で、応答内のｉ番目のオブジェクトがディクショナリであるかどうかに関して決定が行われてよい。ｉ番目のオブジェクトがディクショナリである場合には、方法１２００はブロック１２３０へ進んでよい。ｉ番目のオブジェクトがディクショナリでない場合には、方法１２００はブロック１２４０へ進んでよい。

ブロック１２３０で、ディクショナリは、スキーマの現在のノードに加えられてよく、ディクショナリ内のキーは、スキーマ内の子ノードとして加えられてよい。例えば、ディクショナリが一連のキー値対（又はキー複数値オブジェクト）を含む場合に、キーの夫々は取り出され、ディクショナリノードの真下にスキーマ内の子ノードとして加えられてよい。

ブロック１２４０で、応答内のｉ番目のオブジェクトがキーであるかどうかに関して決定が行われてよい。ｉ番目のオブジェクトがキーである場合には、方法１２００はブロック１２５０へ進んでよい。ｉ番目のオブジェクトがキーでない場合には、方法１２００はブロック１２６０へ進んでよい。

ブロック１２５０で、キーに関連した値が、全ての値が取り出されるまで再帰的に取り出されてよく、そして、現在のノードに加えられてよい。例えば、解析されている応答のデータオブジェクトがキーである場合に、そのキーは、それに関連した複数の値を含む可能性がある。それらの値の夫々は取り出され、キーと関連付けられている現在のノード（ディクショナリノードの真下の子ノードであってもなくてもよい。）と関連付けられてよい。

ブロック１２６０で、応答内のｉ番目のオブジェクトがリストであるかどうかに関して決定が行われてよい。ｉ番目のオブジェクトがリストである場合には、方法１２００はブロック１２７０へ進んでよい。ｉ番目のオブジェクトがリストでない場合には、方法はブロック１２８０へ進んでよい。

ブロック１２７０で、リストは、現在のノードへ加えられ、リストの各要素は、繰り返し処理されてよい。例えば、リストの各要素は、ｉがインクリメントされると、リストのオブジェクトが、スキーマに含まれるために解析されるデータオブジェクトであり得るように、応答内のデータの他のオブジェクトとして扱われてよい。

ブロック１２８０で、変数ｉはインクリメントされてよく、それにより、スキーマ内の次のデータオブジェクトは、スキーマに含まれるために解析され得る。いくつかの実施形態で、ブロック１２８０で、データオブジェクトが文字列である場合には、データ構造に対する変更はない可能性があり、それは文字列としてスキーマに加えられてよい。追加的に、又は代替的に、文字列については、文字列がスキップされるよう、又は適切な方法でスキーマに文字列を含めるようアドミニストレータに提示されるようにし得るフォーマットエラーが、返されてよい。ブロック１２８０で、応答の全てのオブジェクトが解析され且つ／あるいはスキーマに加えられた場合には、方法１２００は、ｉをインクリメントせずに終了してよい。

図１３は、本開示で記載される少なくとも１つの実施形態に従って、タスクの生成、実行、及び／又は結合を容易にするための例となるコンピュータシステム１３００を表す。コンピュータシステム１３００は、プロセッサ１３１０、メモリ１３２０、データストレージ１３３０、及び／又は通信ユニット１３４０を含んでよく、それらは全て通信可能に結合されてよい。図７～１２の方法７００～１２００の動作のいずれかは、コンピュータシステム１３００に従うコンピュータシステムによって実行されてよい。例えば、コンピュータシステム１３００は、タスクを生成及び記憶し、選択されたタスクを実行し、且つ／あるいは、複数のタスクを統合タスクに結合してよい。

一般に、プロセッサ１３１０は、様々なコンピュータハードウェア又はソフトウェアモジュールを含む如何なる適切な専用又は汎用のコンピュータ、コンピュータエンティティ、又はプロセッシングデバイスも含んでよく、如何なる適切なコンピュータ可読記憶媒体で記憶されている命令も実行するよう構成されてよい。例えば、プロセッサ１３１０は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は、プログラム命令を解釈及び／又は実行するよう且つ／あるいはデータを処理するよう構成されたあらゆる他のデジタル若しくはアナログ回路を含んでもよい。

図１３には単一のプロセッサとして表されているが、プロセッサ１３１０は、本開示で記載される任意の数の動作を個別的に又は集合的に実行するよう構成される任意数のネットワーク又は物理的位置にわたって分布する任意の数のプロセッサを含んでよい。いくつかの実施形態で、プロセッサ１３１０は、メモリ１３２０、データストレージ１３３０、又はメモリ１３３０及びデータストレージ１３３０に記憶されているプログラム命令を解釈及び／又は実行し且つ／あるいは記憶されているデータを処理してよい。いくつかの実施形態で、プロセッサ１３１０は、データストレージ１３２０からプログラム命令をフェッチし、プログラム命令をメモリ１３２０にロードしてもよい。

プログラム命令がメモリ１３２０にロードされた後、プロセッサ１３１０は、図７～１２の方法７００～１２００のいずれかを夫々実行するための命令などのプログラム命令を実行してよい。例えば、プロセッサ１３１０は、タスクを生成及び／又は記憶すること、選択されタスクを実行すること、及び／又は複数のタスクを統合されたタスクに結合することに関する命令を取得してよい。

メモリ１３２０及びデータストレージ１３３０は、コンピュータ実行可能命令又はデータ構造を搬送するか又は記憶しているコンピュータ可読記憶媒体又は１つ以上のコンピュータ可読記憶媒体を含んでよい。そのようなコンピュータ可読記憶媒体は、プロセッサ１３１０などの汎用又は専用のコンピュータによってアクセスされ得る如何なる利用可能な媒体であってもよい。いくつかの実施形態で、コンピュータシステム１３００は、メモリ１３２０及びデータストレージ１３３０のどちらも含んでも含まなくてもよい。

例として、限定としてではなく、そのようなコンピュータ可読記憶媒体は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、電気的消去可能なプログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、コンパクトディスク型リードオンリーメモリ（ＣＤ－ＲＯＭ）若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気記憶デバイス、フラッシュメモリデバイス（例えば、固体状態メモリデバイス）、又はコンピュータ実行可能命令若しくはデータ構造の形で所望のプログラムコードを搬送若しくは記憶するために使用されてよくかつ汎用若しくは専用のコンピュータによってアクセスされてよいあらゆる他の記憶媒体を含む非一時的なコンピュータ可読記憶媒体を含んでよい。上記のものの組み合わせも、コンピュータ可読記憶媒体の範囲に含まれてよい。コンピュータ実行可能命令は、例えば、プロセッサ１３１０に特定の動作又は動作のグループを実行させるよう構成された命令及びデータを含んでよい。

通信ユニット１３４０は、ネットワーク上で情報を送信又は受信するよう構成される如何なるコンポーネント、デバイス、システム、又はそれらの組み合わせも含んでよい。いくつかの実施形態で、通信ユニット１３４０は、他の位置、同じ位置、又は同じシステム内の他のコンポーネントにある他のデバイスと通信してよい。例えば、通信ユニット１３４０は、モデム、ネットワークカード（無線若しくは有線）、光通信デバイス、赤外線通信デバイス、無線通信デバイス（例えば、アンテナ）、及び／又はチップセット（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイス、８０２．６デバイス（例えば、メトロポリタンエリアネットワーク（ＭＡＮ））、ＷｉＦｉデバイス、ＷｉＭａｘデバイス、セルラー通信設備、若しくは他）、及び／又は同様のものを含んでよい。通信ユニット１３４０は、データが、本開示で記載されるネットワーク及び／又は任意の他のデバイス若しくはシステムと交換されることを可能にしてよい。例えば、通信ユニット１３４０は、システム１３００がコンピューティングデバイス及び／又は他のネットワークなどの他のシステムと通信することを可能にしてよい。

当業者は、本開示を検討した後、本開示の範囲から逸脱せずにシステム１３００に対して変更、追加、又は削除が行われてよい、と認識し得る。例えば、システム１３００は、明示的に例示又は記載されているよりも多い又は少ないコンポーネントを含んでよい。

上記の開示は、本開示を、開示されている正確な使用形態又は特定の使用分野に限定するよう意図されない。そのようなものとして、本開示に対する様々な代替の実施形態及び／又は変更は、本明細書で明示又は暗示されていようとなかろうと、本開示に照らして可能であることが企図される。このように本開示の実施形態を記載してきたが、本開示の範囲から逸脱せずに変更が形態及び詳細において行われ得る、と認識され得る。よって、本開示は、特許請求の範囲によってのみ限定される。

いくつかの実施形態で、本明細書で記載される種々のコンポーネント、モジュール、エンジン、及びサービスは、コンピュータシステムで（例えば、別々のスレッドとして）実行されるオブジェクト又はプロセスとして実装されてよい。本明細書で記載されるシステム及びプロセスのいくつかは、（汎用ハードウェアで記憶及び／又は実行される）ソフトウェアで実装されるものとして一般的に記載されているが、特定のハードウェア実施又はソフトウェアと特定のハードウェア実施との組み合わせも可能であり企図される。

本明細書で、特に添付の特許請求の範囲（例えば、添付の特許請求の本文）で使用される用語は、一般的に、“非限定的な（open）”用語として意図されている（例えば、語「含んでいる（including）」は、“～を含んでいるが、～に限定されない”との意に解釈されるべきであり、語「備えている（having）」は、「少なくとも～を備えている」との意に解釈されるべきであり、語「含む（includes）」は、“～を含むが、～に限定されない”との意に解釈されるべきである、など。）。

更に、導入されたクレーム記載（introduced claim recitation）において特定の数が意図される場合、そのような意図は当該クレーム中に明確に記載され、そのような記載がない場合は、そのような意図も存在しない。例えば、理解を促すために、後続の添付された特許請求の範囲では、「少なくとも１つの（at least one）」及び「１つ以上の（one or more）」といった導入句を使用し、クレーム記載を導入することがある。しかし、このような句を使用するからといって、「a」又は「an」といった不定冠詞によりクレーム記載を導入した場合に、たとえ同一のクレーム内に、「１つ以上の」又は「少なくとも１つの」といった導入句と「a」又は「an」といった不定冠詞との両方が含まれるとしても、当該導入されたクレーム記載を含む特定のクレームが、当該記載事項を１しか含まない例に限定されるということが示唆されると解釈されるべきではない（例えば、「a」及び／又は「an」は、「少なくとも１つの」又は「１つ以上の」を意味すると解釈されるべきである。）。定冠詞を使用してクレーム記載を導入する場合にも同様のことが当てはまる。

更には、導入されたクレーム記載において特定の数が明示されている場合であっても、そのような記載は、通常、少なくとも記載された数を意味するように解釈されるべきであることは、当業者には理解されるであろう（例えば、他に修飾語のない、単なる「２つの記載事項」という記載がある場合、この記載は、少なくとも２つの記載事項、又は２つ以上の記載事項を意味する。）。更に、「Ａ、Ｂ及びＣなどのうち少なくとも１つ」又は「Ａ、Ｂ及びＣなどのうちの１つ以上」に類する表記が使用される場合、一般的に、そのような構造は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、及び／又はＡとＢとＣの全て、などを含むよう意図される。例えば、「及び／又は」との用語の使用は、このようにして解釈されるよう意図される。

更に、２つ以上の選択可能な用語を表す如何なる離接語及び／又は離接句も、明細書、特許請求の範囲、又は図面のいずれであろうと、それら用語のうちの１つ、それらの用語のうちのいずれか、あるいは、それらの用語の両方を含む可能性を意図すると理解されるべきである。例えば、「Ａ又はＢ」という句は、「Ａ又はＢ」、あるいは、「Ａ及びＢ」の可能性を含むことが理解されるべきである。

しかし、このような句を使用するからといって、「a」又は「an」といった不定冠詞によりクレーム記載を導入した場合に、たとえ同一のクレーム内に、「１つ以上の」又は「少なくとも１つの」といった導入句と「a」又は「an」といった不定冠詞との両方が含まれるとしても、当該導入されたクレーム記載を含む特定のクレームが、当該記載事項を１しか含まない例に限定されるということが示唆されると解釈されるべきではない（例えば、「a」及び／又は「an」は、「少なくとも１つの」又は「１つ以上の」を意味すると解釈されるべきである。）。定冠詞を使用してクレーム記載を導入する場合にも同様のことが当てはまる。

更には、「第１」、「第２」、「第３」などの用語の使用は、特定の順序を暗示するために本明細書で必ずしも使用されていない。一般に、「第１」、「第２」、「第３」などの用語は、異なる要素を区別するために使用される。「第１」、「第２」、「第３」などの用語が特定の順序を暗示するという明示がなければ、これらの用語は、特定の順序を暗示すると理解されるべきではない。

本開示で挙げられている全ての例及び条件付き言語は、当該技術の促進に本発明者によって寄与される概念及び本発明を読者が理解するのを助ける教育上の目的を意図され、そのような具体的に挙げられている例及び条件に制限されないと解釈されるべきである。本開示の実施形態が詳細に記載されてきたが、様々な変更、置換、及び代替が、本開示の主旨及び適用範囲から逸脱することなしに行われてよい。

開示されている実施形態の上記の説明は、当業者が本開示を形成又は使用することを可能にするために提供されている。これらの実施形態に対する様々な変更は、当業者に容易に明らかであり、本明細書で定義されている一般原理は、本開示の精神又は範囲から逸脱せずに他の実施形態に適用されてよい。よって、本開示は、本明細書で示されている実施形態に限定されるよう意図されず、本明細書で開示されている原理及び新規の特徴に一致した最も広い範囲に従うべきである。

上記の実施形態に加えて、以下の付記を開示する。
（付記１）
実行のための、アプリケーションプログラミングインターフェース（ＡＰＩ）に関係があるタスクオブジェクトの選択を受け取ることと、
前記タスクオブジェクトが前記タスクオブジェクト内のプレースホルダー値を含むかどうかを決定することと、
前記タスクオブジェクトがプレースホルダー値を含むことに基づいて、前記タスクオブジェクトで記述されている前記プレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することと、
前記プレースホルダー値を、前記インターフェースを介して受け取られた前記ユーザ入力に基づく新しい値で置換することと、
前記新しい値を含む、前記ＡＰＩへのＡＰＩコールを、対象のプログラミング言語で生成することと、
実行のために前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることと、
前記ＡＰＩコールの結果を取得することと
を有する方法。
（付記２）
前記インターフェースを生成することは、サードパーティにより前記ユーザを認証するためのクレデンシャルを前記ユーザが入力するための前記サードパーティの承認ウェブインターフェースをユーザに提示することを含む、
付記１に記載の方法。
（付記３）
実行のための第２タスクオブジェクトの第２選択を受け取ることと、
前記第２タスクオブジェクトが何らかのプレースホルダー値を含むかどうかを決定することと、
前記第２タスクオブジェクトが如何なるプレースホルダー値も含まないことに基づいて、ユーザ入力なしで前記第２タスクオブジェクトに関連した第２ＡＰＩコールを生成することと
を更に有する、付記１に記載の方法。
（付記４）
前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、ローカルシステムで前記生成されたＡＰＩコールを実行することを含み、
当該方法は、
前記タスクオブジェクトのパラメータのアレイに基づき最終的なタスクコンテンツを生成することであり、パラメータのアレイの第１要素は、前記ユーザ入力に関係がある前記プレースホルダー値を含む、ことと、
前記ＡＰＩコールを実行すべき前記対象のプログラミング言語を選択することと、
ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求のタイプを識別することと、
前記ＨＴＴＰ要求を呼び出すための前記対象のプログラミング言語でのソースコードを取得することと、
前記取得されたソースコードと、前記パラメータのアレイの１つ以上の要素とを用いて、前記ＨＴＴＰ要求をポストすることと
を有する、
付記１に記載の方法。
（付記５）
前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、前記生成されたＡＰＩコールがクラウドベースのコンピュータシステムで実行されるようにすることを含み、
当該方法は、
前記クラウドベースのコンピュータシステムと相互作用するよう第２ＡＰＩコールを呼び出すことであり、前記ＡＰＩコールは、前記インターフェースを実装するようウェブフォームを生成する、ことと、
前記クラウドベースのコンピュータシステムに、ローカルコンピュータデバイスではなく、前記クラウドベースのコンピュータシステムの環境内で前記ＡＰＩコールを実行させることと
を有する、
付記１に記載の方法。
（付記６）
前記プレースホルダー値は、前記ＡＰＩにアクセスすることに関係があるトークンプレースホルダーである、
付記１に記載の方法。
（付記７）
前記トークンプレースホルダーは、ＡＰＩトークンを含み、前記タスクオブジェクトは、前記タスクオブジェクトを実行するときに、前記ＡＰＩにアクセスするために前記ＡＰＩトークンを利用するプログラミングを含む、
付記６に記載の方法。
（付記８）
前記ＡＰＩトークンが失効しているかどうかを決定することと、
前記ＡＰＩトークンが失効していることに基づいて、前記ユーザ入力に基づき前記ＡＰＩトークンをリフレッシュすることと
を更に有する、付記７に記載の方法。
（付記９）
前記タスクオブジェクトで使用される前記ＡＰＩトークンを利用して第２ＡＰＩを呼び出すよう第２タスクオブジェクトを実行することを更に有し、前記ＡＰＩトークンは前記ユーザに固有である、
付記８に記載の方法。
（付記１０）
前記タスクオブジェクトの成功した実行に基づきＡＰＩ応答を受け取ることに基づいて、タスクのデータベース内で確認済みとして前記タスクオブジェクトに注釈を付けることと、
前記タスクオブジェクトが確かめられていることを示す前記タスクオブジェクトの視覚インジケータを供給することと
を更に有する、付記１に記載の方法。
（付記１１）
タスクオブジェクトが検索可能である検索インターフェースを供給することと、
ユーザからクエリを受け取り、前記クエリの結果を返すことと
を更に有し、
前記タスクオブジェクトは、前記クエリの結果に含まれる、
付記１に記載の方法。
（付記１２）
１つ以上のプロセッサと、命令を含む１つ以上の非一時的なコンピュータ可読媒体とを有するシステムであって、
前記命令は、前記１つ以上のプロセッサによって実行される場合に、当該システムに、
実行のための、アプリケーションプログラミングインターフェース（ＡＰＩ）に関係があるタスクオブジェクトの選択を受け取ることと、
前記タスクオブジェクトが前記タスクオブジェクト内のプレースホルダー値を含むかどうかを決定することと、
前記タスクオブジェクトがプレースホルダー値を含むことに基づいて、前記タスクオブジェクトで記述されている前記プレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することと、
前記プレースホルダー値を、前記インターフェースを介して受け取られた前記ユーザ入力に基づく新しい値で置換することと、
前記新しい値を含む、前記ＡＰＩへのＡＰＩコールを、対象のプログラミング言語で生成することと、
実行のために前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることと、
前記ＡＰＩコールの結果を取得することと
を有する動作を実行させる、
システム。
（付記１３）
前記インターフェースを生成することは、サードパーティにより前記ユーザを認証するためのクレデンシャルを前記ユーザが入力するための前記サードパーティの承認ウェブインターフェースをユーザに提示することを含む、
付記１２に記載のシステム。
（付記１４）
前記動作は、
実行のための第２タスクオブジェクトの第２選択を受け取ることと、
前記第２タスクオブジェクトが何らかのプレースホルダー値を含むかどうかを決定することと、
前記第２タスクオブジェクトが如何なるプレースホルダー値も含まないことに基づいて、ユーザ入力なしで前記第２タスクオブジェクトに関連した第２ＡＰＩコールを生成することと
を更に有する、
付記１２に記載のシステム。
（付記１５）
前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、ローカルシステムで前記生成されたＡＰＩコールを実行することを含み、
前記動作は、
前記タスクオブジェクトのパラメータのアレイに基づき最終的なタスクコンテンツを生成することであり、パラメータのアレイの第１要素は、前記ユーザ入力に関係がある前記プレースホルダー値を含む、ことと、
前記ＡＰＩコールを実行すべき前記対象のプログラミング言語を選択することと、
ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求のタイプを識別することと、
前記ＨＴＴＰ要求を呼び出すための前記対象のプログラミング言語でのソースコードを取得することと、
前記取得されたソースコードと、前記パラメータのアレイの１つ以上の要素とを用いて、前記ＨＴＴＰ要求をポストすることと
を有する、
付記１２に記載のシステム。
（付記１６）
前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、前記生成されたＡＰＩコールがクラウドベースのコンピュータシステムで実行されるようにすることを含み、
前記動作は、
前記クラウドベースのコンピュータシステムと相互作用するよう第２ＡＰＩコールを呼び出すことであり、前記ＡＰＩコールは、前記インターフェースを実装するようウェブフォームを生成する、ことと、
前記クラウドベースのコンピュータシステムに、ローカルコンピュータデバイスではなく、前記クラウドベースのコンピュータシステムの環境内で前記ＡＰＩコールを実行させることと
を有する、
付記１２に記載のシステム。
（付記１７）
前記プレースホルダー値は、ＡＰＩトークンを含み、前記タスクオブジェクトは、前記タスクオブジェクトを実行するときに、前記ＡＰＩにアクセスするために前記ＡＰＩトークンを利用するプログラミングを含む、
付記１２に記載のシステム。
（付記１８）
前記動作は、
前記ＡＰＩトークンが失効しているかどうかを決定することと、
前記ＡＰＩトークンが失効していることに基づいて、前記ユーザ入力に基づき前記ＡＰＩトークンをリフレッシュすることと
を更に有する、
付記１７に記載のシステム。
（付記１９）
前記動作は、前記タスクオブジェクトで使用される前記ＡＰＩトークンを利用して第２ＡＰＩを呼び出すよう第２タスクオブジェクトを実行することを更に有し、前記ＡＰＩトークンは前記ユーザに固有である、
付記１８に記載のシステム。
（付記２０）
前記動作は、
前記タスクオブジェクトの成功した実行に基づきＡＰＩ応答を受け取ることに基づいて、タスクのデータベース内で確認済みとして前記タスクオブジェクトに注釈を付けることと、
前記タスクオブジェクトが確かめられていることを示す前記タスクオブジェクトの視覚インジケータを供給することと
を更に有する、
付記１２に記載のシステム。

［関連出願の相互参照］
本特許出願は、２０２０年７月３０日付けで「TASK GENERATION」と題されて出願された米国特許出願第１６／９４３６２８号と、２０２０年７月３０日付けで「TASK INTEGRATION」と題されて出願された米国特許出願第１６／９４３６５８号とに関係がある。これらの米国特許出願の夫々は、それらの全文を参照により本願に援用される。

１００ システム
１１０ タスクシステム
１１２ タスクデータベース
１２０ アドミニストレータ
１３０ エンドユーザ
１４０ ＡＰＩ仕様
１５０ ＡＰＩホスト
１６０ａ，１６０ｂ クラウドシステム
２００，６３０ タスク
２１０ プレースホルダー
６１０ ユーザ入力
６２０ 出力
１３００ コンピュータシステム
１３１０ プロセッサ
１３２０ メモリ
１３３０ データストレージ
１３４０ 通信ユニット

Claims (20)

1. 実行のための、アプリケーションプログラミングインターフェース（ＡＰＩ）に関係があるタスクオブジェクトの選択を受け取ることと、
   前記タスクオブジェクトが前記タスクオブジェクト内のプレースホルダー値を含むかどうかを決定することと、
   前記タスクオブジェクトがプレースホルダー値を含むことに基づいて、前記タスクオブジェクトで記述されている前記プレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することと、
   前記プレースホルダー値を、前記インターフェースを介して受け取られた前記ユーザ入力に基づく新しい値で置換することと、
   前記新しい値を含む、前記ＡＰＩへのＡＰＩコールを、対象のプログラミング言語で生成することと、
   実行のために前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることと、
   前記ＡＰＩコールの結果を取得することと
   を有する方法。
2. 前記インターフェースを生成することは、サードパーティにより前記ユーザを認証するためのクレデンシャルを前記ユーザが入力するための前記サードパーティの承認ウェブインターフェースをユーザに提示することを含む、
   請求項１に記載の方法。
3. 実行のための第２タスクオブジェクトの第２選択を受け取ることと、
   前記第２タスクオブジェクトが何らかのプレースホルダー値を含むかどうかを決定することと、
   前記第２タスクオブジェクトが如何なるプレースホルダー値も含まないことに基づいて、ユーザ入力なしで前記第２タスクオブジェクトに関連した第２ＡＰＩコールを生成することと
   を更に有する、請求項１に記載の方法。
4. 前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、ローカルシステムで前記生成されたＡＰＩコールを実行することを含み、
   当該方法は、
   前記タスクオブジェクトのパラメータのアレイに基づき最終的なタスクコンテンツを生成することであり、パラメータのアレイの第１要素は、前記ユーザ入力に関係がある前記プレースホルダー値を含む、ことと、
   前記ＡＰＩコールを実行すべき前記対象のプログラミング言語を選択することと、
   ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求のタイプを識別することと、
   前記ＨＴＴＰ要求を呼び出すための前記対象のプログラミング言語でのソースコードを取得することと、
   前記取得されたソースコードと、前記パラメータのアレイの１つ以上の要素とを用いて、前記ＨＴＴＰ要求をポストすることと
   を有する、
   請求項１に記載の方法。
5. 前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、前記生成されたＡＰＩコールがクラウドベースのコンピュータシステムで実行されるようにすることを含み、
   当該方法は、
   前記クラウドベースのコンピュータシステムと相互作用するよう第２ＡＰＩコールを呼び出すことであり、前記ＡＰＩコールは、前記インターフェースを実装するようウェブフォームを生成する、ことと、
   前記クラウドベースのコンピュータシステムに、ローカルコンピュータデバイスではなく、前記クラウドベースのコンピュータシステムの環境内で前記ＡＰＩコールを実行させることと
   を有する、
   請求項１に記載の方法。
6. 前記プレースホルダー値は、前記ＡＰＩにアクセスすることに関係があるトークンプレースホルダーである、
   請求項１に記載の方法。
7. 前記トークンプレースホルダーは、ＡＰＩトークンを含み、前記タスクオブジェクトは、前記タスクオブジェクトを実行するときに、前記ＡＰＩにアクセスするために前記ＡＰＩトークンを利用するプログラミングを含む、
   請求項６に記載の方法。
8. 前記ＡＰＩトークンが失効しているかどうかを決定することと、
   前記ＡＰＩトークンが失効していることに基づいて、前記ユーザ入力に基づき前記ＡＰＩトークンをリフレッシュすることと
   を更に有する、請求項７に記載の方法。
9. 前記タスクオブジェクトで使用される前記ＡＰＩトークンを利用して第２ＡＰＩを呼び出すよう第２タスクオブジェクトを実行することを更に有し、前記ＡＰＩトークンは前記ユーザに固有である、
   請求項８に記載の方法。
10. 前記タスクオブジェクトの成功した実行に基づきＡＰＩ応答を受け取ることに基づいて、タスクのデータベース内で確認済みとして前記タスクオブジェクトに注釈を付けることと、
    前記タスクオブジェクトが確かめられていることを示す前記タスクオブジェクトの視覚インジケータを供給することと
    を更に有する、請求項１に記載の方法。
11. タスクオブジェクトが検索可能である検索インターフェースを供給することと、
    ユーザからクエリを受け取り、前記クエリの結果を返すことと
    を更に有し、
    前記タスクオブジェクトは、前記クエリの結果に含まれる、
    請求項１に記載の方法。
12. １つ以上のプロセッサと、命令を含む１つ以上の非一時的なコンピュータ可読媒体とを有するシステムであって、
    前記命令は、前記１つ以上のプロセッサによって実行される場合に、当該システムに、
    実行のための、アプリケーションプログラミングインターフェース（ＡＰＩ）に関係があるタスクオブジェクトの選択を受け取ることと、
    前記タスクオブジェクトが前記タスクオブジェクト内のプレースホルダー値を含むかどうかを決定することと、
    前記タスクオブジェクトがプレースホルダー値を含むことに基づいて、前記タスクオブジェクトで記述されている前記プレースホルダー値に関するユーザ入力をユーザがサブミットするためのインターフェースを生成することと、
    前記プレースホルダー値を、前記インターフェースを介して受け取られた前記ユーザ入力に基づく新しい値で置換することと、
    前記新しい値を含む、前記ＡＰＩへのＡＰＩコールを、対象のプログラミング言語で生成することと、
    実行のために前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることと、
    前記ＡＰＩコールの結果を取得することと
    を有する動作を実行させる、
    システム。
13. 前記インターフェースを生成することは、サードパーティにより前記ユーザを認証するためのクレデンシャルを前記ユーザが入力するための前記サードパーティの承認ウェブインターフェースをユーザに提示することを含む、
    請求項１２に記載のシステム。
14. 前記動作は、
    実行のための第２タスクオブジェクトの第２選択を受け取ることと、
    前記第２タスクオブジェクトが何らかのプレースホルダー値を含むかどうかを決定することと、
    前記第２タスクオブジェクトが如何なるプレースホルダー値も含まないことに基づいて、ユーザ入力なしで前記第２タスクオブジェクトに関連した第２ＡＰＩコールを生成することと
    を更に有する、
    請求項１２に記載のシステム。
15. 前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、ローカルシステムで前記生成されたＡＰＩコールを実行することを含み、
    前記動作は、
    前記タスクオブジェクトのパラメータのアレイに基づき最終的なタスクコンテンツを生成することであり、パラメータのアレイの第１要素は、前記ユーザ入力に関係がある前記プレースホルダー値を含む、ことと、
    前記ＡＰＩコールを実行すべき前記対象のプログラミング言語を選択することと、
    ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求のタイプを識別することと、
    前記ＨＴＴＰ要求を呼び出すための前記対象のプログラミング言語でのソースコードを取得することと、
    前記取得されたソースコードと、前記パラメータのアレイの１つ以上の要素とを用いて、前記ＨＴＴＰ要求をポストすることと
    を有する、
    請求項１２に記載のシステム。
16. 前記ＡＰＩコールを生成し、前記生成されたＡＰＩコールをターゲットプラットフォーム上でデプロイすることは、前記生成されたＡＰＩコールがクラウドベースのコンピュータシステムで実行されるようにすることを含み、
    前記動作は、
    前記クラウドベースのコンピュータシステムと相互作用するよう第２ＡＰＩコールを呼び出すことであり、前記ＡＰＩコールは、前記インターフェースを実装するようウェブフォームを生成する、ことと、
    前記クラウドベースのコンピュータシステムに、ローカルコンピュータデバイスではなく、前記クラウドベースのコンピュータシステムの環境内で前記ＡＰＩコールを実行させることと
    を有する、
    請求項１２に記載のシステム。
17. 前記プレースホルダー値は、ＡＰＩトークンを含み、前記タスクオブジェクトは、前記タスクオブジェクトを実行するときに、前記ＡＰＩにアクセスするために前記ＡＰＩトークンを利用するプログラミングを含む、
    請求項１２に記載のシステム。
18. 前記動作は、
    前記ＡＰＩトークンが失効しているかどうかを決定することと、
    前記ＡＰＩトークンが失効していることに基づいて、前記ユーザ入力に基づき前記ＡＰＩトークンをリフレッシュすることと
    を更に有する、
    請求項１７に記載のシステム。
19. 前記動作は、前記タスクオブジェクトで使用される前記ＡＰＩトークンを利用して第２ＡＰＩを呼び出すよう第２タスクオブジェクトを実行することを更に有し、前記ＡＰＩトークンは前記ユーザに固有である、
    請求項１８に記載のシステム。
20. 前記動作は、
    前記タスクオブジェクトの成功した実行に基づきＡＰＩ応答を受け取ることに基づいて、タスクのデータベース内で確認済みとして前記タスクオブジェクトに注釈を付けることと、
    前記タスクオブジェクトが確かめられていることを示す前記タスクオブジェクトの視覚インジケータを供給することと
    を更に有する、
    請求項１２に記載のシステム。

Images