JP2023070148A - ロボティックプロセスオートメーション（ｒｐａ）ロボットをリソースへ動的にバインドさせるためのシステムおよび方法 - Google Patents

Abstract

【課題】よりロバストかつユーザーフレンドリーなＲＰＡロボットの開発が可能な方法、コンピュータシステム及び媒体を提供する。【解決手段】ワークフロー仕様は、各ワークフローの実行のタスクが付与されたロボティックプロセスオートメーション（ＲＰＡ）ロボットに必要なリソースの１組のデフォルト特性を含む。ユーザーが各デフォルト特性の変更（例えば、ファイルの再配置および／または再度名前付け）の変更をワークフロー仕様自体の変更無く行うことが可能になる。このような変更は、複数のＲＰＡロボットの実行を管理するＲＰＡオーケストレータのユーザインターフェースを介して行われる。【選択図】図２

Description

本発明は、ロボティックプロセスオートメーション（ＲＰＡ）に関し、詳細には、ソフトウェアロボットの実行の管理に関する。

ＲＰＡは、情報技術の新興分野であり、その目的は、反復的なコンピューティングタスクの自動化による生産性向上により、人間のオペレータをより知的に高度でありかつ／または創造的なアクティビティの実行のために解放することである。自動化の対象となる代表的なタスクを挙げると、文書（例えば、請求書、ウェブページ）からの構造化データの抽出、（例えば用紙記入のための）ユーザインターフェースとの対話、ｅメールの送信、ソーシャルメディアのサイトへのメッセージ公開などがある。

ＲＰＡ開発の明確な先端は、ソフトウェアロボットのプログラミングおよび管理の簡素化に向けられており、究極の目的は、ＲＰＡ技術において開発者および産業の対象ユーザーを広げることである。現在、従来のＲＰＡにおいて行われる１つの方法は、ＲＰＡ設計ツールを用いて１組のロボットアクティビティをプログラムすることを含む。その後、その結果得られたロボットコードまたは仕様は、実行環境（クライアントのマシン）へ送信される。より高度なアプリケーションにおいて、複数のロボットが、複数のマシン上において同時に実行し得、多様な自動化タスクを行う。このようなロボットの実行は、管理コンソールから中心的に管理および調整され得る。

ＲＰＡロボットの設計および利用は、本質的に別個のアクティビティであり、典型的には別個のエンティティ（ユーザー、企業）によって行われる。そのため、従来のＲＰＡアーキテクチャにおいてスムーズなオペレーションを行うためには、複数のエンティティおよびオペレータ間の協働が必要になり得る。例えば、クライアントは、自身のロボットの問題解決をできない場合があり得、実行時の不具合によっては、ロボット設計者による支援が必要になり得る。このような状況があると、生産性の悪影響に繋がり得、クライアントがＲＰＡ技術を採用する意欲を削ぐことにもなり得る。

上記を鑑みて、よりロバストかつユーザーフレンドリーなＲＰＡロボットの開発について、強い関心が存在している。

１つの態様によれば、方法は、コンピュータシステムの少なくとも１つのハードウェアプロセッサを用いて、複数のソフトウェアロボットを管理するように構成されたロボティックプロセスオートメーション（ＲＰＡ）オーケストレータを実行することを含む。上記ＲＰＡオーケストレータは、ＲＰＡパッケージを受信するようにさらに構成され、上記ＲＰＡパッケージは、ＲＰＡワークフローの符号化と、上記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含み、上記ＲＰＡリソースは、コンピュータファイル、キューおよびデータベースからなる群から選択されたアイテムを含む。上記ＲＰＡオーケストレータは、上記ＲＰＡワークフローを実行対象として上記複数のソフトウェアロボットのうち選択されたロボットに割り当てるようにさらに構成される。上記ＲＰＡワークフローを上記選択されたロボットに割り当てることは、上記ＲＰＡワークフローの実行の準備のために、上記ＲＰＡリソースの実行時インスタンスが上記デフォルトロケーションにおいて利用可能であるかを決定することと、オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することとを含む。上記オーケストレータＵＩは、上記決定の結果に従って選択されたリソース利用可能性インジケータを表示する。

別の態様によれば、コンピュータシステムは、複数のソフトウェアロボットを管理するように構成されたＲＰＡオーケストレータを実行するように構成された少なくとも１つのハードウェアプロセッサを含む。ＲＰＡオーケストレータは、ＲＰＡワークフローの符号化と、上記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含むＲＰＡパッケージを受信するようにさらに構成される。上記ＲＰＡリソースは、コンピュータファイル、キューおよびデータベースからなる群から選択されたアイテムを含む。ＲＰＡオーケストレータは、上記ＲＰＡワークフローを実行対象として上記複数のソフトウェアロボットのうち選択されたロボットに割り当てるようにさらに構成される。上記ＲＰＡワークフローを上記選択されたロボットに割り当てることは、上記ＲＰＡワークフローの実行の準備のために、上記ＲＰＡリソースの実行時インスタンスが上記デフォルトロケーションにおいて利用可能であるかを決定することと、オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することとを含む。上記オーケストレータＵＩにより、上記決定の結果に従って選択されたリソース利用可能性インジケータが表示される。

別の態様によれば、非一時的なコンピュータにより読み出し可能な媒体は、命令を保存する。上記命令がコンピュータシステムの少なくとも１つのハードウェアプロセッサによって実行されると、上記コンピュータシステムは、複数のソフトウェアロボットを管理するように構成されたＲＰＡオーケストレータを実行する。上記ＲＰＡオーケストレータは、ＲＰＡパッケージを受信するようにさらに構成される。このＲＰＡパッケージは、ＲＰＡワークフローの符号化と、上記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含む。上記ＲＰＡリソースは、コンピュータファイル、キューおよびデータベースからなる群から選択されたアイテムを含む。上記ＲＰＡオーケストレータは、上記ＲＰＡワークフローを実行対象として上記複数のソフトウェアロボットのうち選択されたロボットに割り当てるようにさらに構成される。上記ＲＰＡワークフローを上記選択されたロボットに割り当てることは、上記ＲＰＡワークフローの実行の準備のために、上記ＲＰＡリソースの実行時インスタンスが上記デフォルトロケーションにおいて利用可能であるかを決定することと、オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することとを含む。上記オーケストレータＵＩは、上記決定の結果に従って選択されたリソース利用可能性インジケータを表示する。

本発明の上記の態様および利点は、以下の詳細な説明を図面を参照しつつ読めば、より深く理解される。

本発明のいくつかの実施形態による例示的なロボティックプロセスオートメーション（ＲＰＡ）環境を示す。

本発明のいくつかの実施形態による、ＲＰＡロボットおよびオーケストレータの例示的なコンポーネントおよびオペレーションを示す。

本発明のいくつかの実施形態による、ＲＰＡパッケージの例示的なコンポーネントを示す。

本発明のいくつかの実施形態による多様なＲＰＡホストシステムを示す。

本発明のいくつかの実施形態による、オーケストレータユーザインターフェース（ＵＩ）によって公開される例示的なビューを示す。

本発明のいくつかの実施形態による、オーケストレータＵＩによって公開される別の例示的なビューを示す。

本発明のいくつかの実施形態による、オーケストレータＵＩによって公開されるさらに別の例示的なビューを示す。

本発明のいくつかの実施形態による、例示的なリソース編集ＵＩを示す。

本発明のいくつかの実施形態による、ユーザーに対して警告を表示する別の例示的なリソース編集ＵＩを示す。

本発明のいくつかの実施形態による、オーケストレータによって行われるステップの例示的シークエンスを示す。

本発明のいくつかの実施形態による、１組のリソースメタデータと、デフォルト属性値および実行時属性値の間の例示的なマッピングとを示す。

本発明のいくつかの実施形態による、オーケストレータによって行われるステップの別の例示的シークエンスを示す。

本発明のいくつかの実施形態による、リソースメタデータの更新のためにオーケストレータによって行われるステップの別の例示的シークエンスを示す。

本発明のいくつかの実施形態による、ＲＰＡロボットによって行われるステップの例示的シークエンスを示す。

本明細書中に記載の方法のうちいくつかを実行するようにプログラムされたコンピューティング装置の例示的ハードウェア構成を示す。

以下の記載において、構造間の記載の接続は全て、直接的動作接続または中間構造を通じた間接的動作接続であり得ることが理解される。１組の要素は、１つ以上の要素を示す。１つの要素に言及する場合、常に少なくとも１つの要素を指すものとして理解される。複数の要素は、少なくとも２つの要素を含む。「または」という文言が用いられる場合、非排他的な「または」を常に意味する。他に明記無き限り、任意の記載の方法ステップを特定の例示された順序で行う必要は無い。第２の要素から導出された第１の要素（例えば、データ）は、第２の要素に等しい第１の要素と、第２の要素および任意選択的に他のデータの処理によって生成された第１の要素とを包含する。決定または判定をパラメータに従って行うことは、決定または判定をパラメータに従ってかつ任意選択的に他のデータに従って行うことを包含する。他に明記無き限り、或る数量／データインジケータは、数量／データそのものであり得るか、または、数量／データそのものと異なるインジケータであり得る。コンピュータプログラムは、タスクを実行するプロセッサ命令のシークエンスである。本発明のいくつかの実施形態において記載されるコンピュータプログラムは、他のコンピュータプログラムのスタンドアロンのソフトウェアエンティティまたはサブエンティティ（例えば、サブルーチン、ライブラリ）であり得る。本明細書中、「データベース」という用語は、組織的かつ検索可能なデータ集合全てを指すものとして用いられる。本明細書中のメタデータは、オブジェクトについての情報（オブジェクトそのものを除く）を提供するデータ全てを包含する。例えば、画像メタデータは、各画像のサイズ、ファイル名およびロケーションを含み得るが、画像そのものは含み得ない。コンピュータにより読み出し可能な媒体は、非一時的な媒体（例えば、磁気記憶媒体、光学記憶媒体および半導体記憶媒体（例えば、ハードドライブ、光ディスク、フラッシュメモリ、ＤＲＡＭ））と、通信リンク（例えば、導電性ケーブルおよび光ファイバーリンク）とを包含する。いくつかの実施形態によれば、本発明によれば、特に、本明細書中に記載の方法と、本明細書中に記載の方法の実行のためのコンピュータにより読み出し可能な媒体符号化命令とを実行するようにプログラムされたハードウェア（例えば、１つ以上のプロセッサ）を含むコンピュータシステムが提供される。

以下の記載において、本発明の実施形態を、例示目的のために、必ずしも制限を伴うこと無く例示する。

図１は、本発明のいくつかの実施形態による、例示的なロボティックプロセスオートメーション（ＲＰＡ）環境１０を示す。環境１０に含まれる多様なソフトウェアコンポーネントは、特定のタスクの自動化の達成のために協働する。例示的なＲＰＡシナリオにおいて、企業の従業員は、反復的なタスク（例えば、多様なクライアントへの請求書の発行）を行う際、ビジネスアプリケーション（例えば、ワードプロセッサ、スプレッドシートエディタ、ブラウザ、ｅメールアプリケーション）を使用する。各タスクを実際に行う際、従業員は、オペレーション／アクションのシークエンスを行う（例えば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）スプレッドシートを開く、クライアントの企業詳細をルックアップする、各詳細を請求書テンプレート内へコピーする、購入アイテムを示す請求書フィールドに書き込む、ｅメールアプリケーションへ移行する、各クライアントへのｅメールメッセージを構成する、新規生成された請求書を各ｅメールメッセージに添付する、「送信」ボタンをクリックする）。それぞれの人間のオペレータが各タスクを実行する際に行う１組のオペレーションの模倣により、ＲＰＡ環境１０の多様な要素により、各プロセスが自動化され得る。

本明細書中、人間オペレーション／アクションの模倣は、人間のオペレータが各オペレーション／アクションをコンピュータに行う際に発生するコンピューティングイベントのシークエンスを再生することと、人間のオペレータが各オペレーションをコンピュータに行った結果を再生することとを包含するものとして理解される。例えば、グラフィカルユーザインターフェース（ＧＵＩ）のボタンをクリックするアクションを模倣することは、オペレーティングシステムによりマウスポインターを各ボタンまで移動させることと、マウスクリックイベントを生成することとを含み得るか、または、あるいは各ＧＵＩボタンそのものをクリックされた状態までトグルさせることを含み得る。

ＲＰＡ自動化の対象となるアクティビティのうち典型的なものを挙げると、支払いのい処理、代金請求、ビジネスクライアントとの通信（例えば、ニュースレターおよび／または商品提供の配信）、内部連絡（例えば、メモ、ミーティングおよび／またはタスクのスケジューリング）、監査、および賃金支払処理などがある。いくつかの実施形態において、専用ＲＰＡ設計アプリケーション３０（図２）により、人間のアクションのシークエンスを有効に自動化させるワークフローを実行するソフトウェアロボットを人間の開発者が設計することが可能になる。本明細書中、ワークフローとは、カスタム自動化ステップ（本明細書中、ＲＰＡアクティビティとみなされる）のシークエンスを指す。各ＲＰＡアクティビティは、ロボットによって行われる少なくとも１つのアクションを含む（例えば、ボタンのクリック、ファイルの読み出し、スプレッドシートセルへの書き込み）。アクティビティは、ネスト化および／または埋設され得る。いくつかの実施形態において、ＲＰＡ設計アプリケーション３０は、ユーザインターフェースと、実行順序およびワークフローのＲＰＡアクティビティ間の関係の制御を開発者に付与する１組のツールとを公開する。ＲＰＡ設計アプリケーション３０の実施形態の１つの商業的例として、ＵｉＰａｔｈＳｔｕｄｉｏＸ（登録商標）がある。

いくつかのタイプのワークフローを非限定的に挙げると、シークエンス、フローチャート、有限状態機械（ＦＳＭ）および／またはグローバル例外ハンドラがある。シークエンスは、特に線形プロセスに適切であり得、これにより、１つのアクティビティから別のアクティビティへの流れがワークフローのクラッタリング無しに可能になる。フローチャートは、より複雑なビジネスロジックに特に適切であり得、判定の統合およびアクティビティの接続が複数の分岐論理演算子を通じてより多様な様態で可能になる。ＦＳＭは、大型ワークフローに特に適切であり得る。ＦＳＭは、有限数の状態を自身の実行時において用い得、これらの状態は、状態（すなわち、移行）またはアクティビティによってトリガされ得る。グローバル例外ハンドラは、実行エラーに遭遇したときのワークフロー挙動の決定と、デバッギングプロセスとに特に適切であり得る。

ＲＰＡワークフローは、開発された後、コンピュータによりも読みだし可能な形態に符号化され得、ＲＰＡパッケージ４０としてエクスポートされ得る（図２）。図３に示すようないくつかの実施形態において、ＲＰＡパッケージ４０は、ソフトウェアロボットに対する１組の命令を含む１組のＲＰＡスクリプト４２を含む。ＲＰＡスクリプト（複数可）４２は、当該分野において公知である任意のデータ仕様に従って定式化され得、例えば拡張マークアップ言語（ＸＭＬ）、Ｊａｖａスクリプト（登録商標）Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）またはプログラミング言語（例えば、Ｃ＃、視覚Ｂａｓｉｃ（登録商標）、Ｊａｖａ（登録商標））のバージョンとして定式化され得る。あるいは、ＲＰＡスクリプト（複数可）４２は、ＲＰＡ特有のバージョンのバイトコードとしてまたはさらには自然言語（例えば、英語、スペイン語、日本語）で定式化された命令のシークエンスとして定式化され得る。いくつかの実施形態において、ＲＰＡスクリプト（複数可）４２は、１組のネイティブプロセッサ命令（例えば、マシンコード）としてプリコンパイルされる。

いくつかの実施形態において、ＲＰＡパッケージ４０は、実行時において各ロボットによって用いられる１組のプロセスリソースを示すリソース仕様４４をさらに含む。例示的なプロセスリソースは、１組の資格情報、コンピュータファイル、キュー、データベースおよびネットワーク接続／通信リンクなどを含む。本明細書中、資格情報は、特定のＲＰＡホストマシンへのアクセスおよび／または特定のソフトウェアコンポーネントの実行に必要なプライベートデータ（例えば、ユーザー名、パスワード）を包括的に示す。資格情報は、暗号化されたデータを含み得る。このような状況において、実行側のロボットは、各データの復号のための暗号鍵を所有し得る。いくつかの実施形態において、資格情報リソースは、コンピュータファイルの形態をとり得る。あるいは、例示的な資格情報リソースは、ルックアップキー（例えば、ハッシュ索引）を実際の資格情報を保持しているデータベース中に含み得る。このようなデータベースは、当該分野において資格情報ボールトとして公知である場合がある。本明細書中、キューは、同一タイプのアイテム（例えば、コンピュータファイル、構造化データオブジェクト）の順番付き集合を保持するコンテナを指す。例示的なキューを挙げると、請求書の集合、ｅメール受信トレイのコンテンツなどがある。キューアイテムの順序は、実行側のロボットによって処理されるべき各アイテムの順序を示し得る。

いくつかの実施形態において、各プロセスリソースについて、仕様４４は、各リソースを特徴付ける１組のメタデータを含む。例示的なリソース特性／メタデータを挙げると、例えば、各リソースのリソースタイプのインジケータ、ファイル名、各リソースへのアクセスのためのファイルシステム経路および／または他のロケーションインジケータ、サイズ、および各リソースのバージョンインジケータがある。リソース仕様４４は、当該分野において公知の任意のデータ形式に従って、例えばＸＭＬスクリプトまたはＪＳＯＮスクリプト、リレーショナルデータベースとして定式化され得る。リソースメタデータについて、図８に関連してさら以下に述べる。

当業者であれば、ＲＰＡ設計アプリケーション３０は、別個の物理的マシンを実行し得る複数のコンポーネント／モジュールを含み得ることを理解する。一例において、ＲＰＡ設計アプリケーション３０は、クライアント／サーバー構成において実行し得る。この構成において、アプリケーション３０の１つのコンポーネントは、ロボット設計インターフェースをクライアントコンピュータのユーザーへ公開し得、サーバーコンピュータ上において実行するアプリケーション３０の別のコンポーネントは、ロボットワークフローのアセンブルと、ＲＰＡパッケージ４０の定式化／出力とを行い得る。例えば、開発者は、クライアントコンピュータ上において実行するウェブブラウザを介してロボット設計インターフェースへアクセスし得、クライアントコンピュータにおいて受信されたユーザー入力を処理するソフトウェアは、実際にサーバーコンピュータ上において実行する。

定式化された後、ＲＰＡスクリプト（複数可）４２は、１組のロボット１２ａ～１２ｃ（図１）によって実行され得、ロボット１２ａ～１２ｃ（図１）は、オーケストレータ１４によってさらに制御および調整され得る。ロボット１２ａ～１２ｃおよびオーケストレータ１４それぞれに含まれ得る複数のコンピュータプログラムは、同一の物理的マシン上において実行し得るかまたは実行し得ない。ロボット１２ａ～１２ｃおよびオーケストレータ１４の例示的な商業的実施形態を挙げると、ＵｉＰａｔｈロボット（登録商標）およびＵｉＰａｔｈオーケストレータ（登録商標）がそれぞれある。ロボット１２ａ～１２ｃのタイプを非限定的に挙げると、アテンディッドロボット、アンアテンディッドロボット、開発ロボット（アンアテンディッドロボットに類似するが、開発目的および試験目的のために用いられる）、非本番環境ロボット（アテンディッドロボットに類似するが、開発目的および試験目的のために用いられる）がある。

アテンディッドロボットは、ユーザーイベントおよび／またはコマンドによってトリガされ、同一コンピューティングシステム上の人間のオペレータと共に動作する。いくつかの実施形態において、アテンディッドロボットの起動は、ロボットトレイまたはコマンドプロンプトのみからしか行えないため、オーケストレータ１４からは制御することはできず、例えばロックされた画面下においては実行できない。アンアテンディッドロボットは、遠隔バーチャル環境において無人で実行し得、リモートの実行、監視、スケジューリングおよびワークキューへのサポート提供を担当し得る。

オーケストレータ１４は、複数のロボット１２ａ～１２ｃの実行を制御および調整する。よって、オーケストレータ１４が有し得る多様な能力を非限定的に挙げると、プロビジョニング、デプロイメント、構成、スケジューリング、キューイング、監視、ロギングおよび／またはロボット１２ａ～１２ｃのインターコネクティビティの提供がある。プロビジョニングは、ロボット１２ａ～１２ｃとオーケストレータ１４との間の接続の生成および維持を含み得る。デプロイメントは、ソフトウェア（例えば、ＲＰＡスクリプト４２）が実行対象としてロボット１２ａ～１２ｃへ正しく送達されることを確保することを含み得る。構成は、ロボット環境、リソースおよびワークフロー構成のメンテナンスおよび送達を含み得る。スケジューリングは、多様なタスクを特定のスケジュール（例えば、１日の特定の時間、特定の日付、毎日）に従って実行するようにロボット１２ａ～１２ｃを構成することを含み得る。キューイングは、ジョブキューの管理を提供することを含み得る。監視は、ロボット状態を追跡することと、ユーザー権限を維持することとを含み得る。ロギングは、データベースおよび／または別の保存機構（例えば、ＳＱＬ、ＥｌａｓｔｉｃＳｅａｒｃｈ（登録商標）、Ｒｅｄｉｓ（登録商標））に対する保存および索引付けログを含み得る。オーケストレータ１４は、サードパーティのソリューションおよび／またはアプリケーションに対する通信の集中点としてさらに機能し得る。

図２は、本発明のいくつかの実施形態による、ロボット１２およびオーケストレータ１４例示的なコンポーネントを示す。例示的なＲＰＡロボット１２は、Ｍｉｃｒｏｓｏｆｔ，Ｉｎｃ．からのＷｉｎｄｏｗｓ（登録商標）ワークフローファンデーションアプリケーションプログラミングインターフェースを用いて構築される。ロボット１２は、１組のエグゼキュータ２２およびＲＰＡエージェント２４を含み得る。ロボットエグゼキュータ２２は、人間のオペレータのアクションを模倣するＲＰＡアクティビティのシークエンスを示すＲＰＡスクリプト（複数可）４２を受信することと、各クライアントマシン上におけるアクティビティの各シークエンスを自動的に行うように構成される。いくつかの実施形態において、ロボットエグゼキュータ（複数可）２２に含まれるインタープリター（例えば、ジャストインタイムインタープリターまたはコンパイラ）は、ＲＰＡスクリプト（複数可）４２を各スクリプト（複数可）中に符号化されたＲＰＡアクティビティの実行のためのプロセッサ命令を含む実行時のオブジェクトに翻訳するように構成される。よって、スクリプト（複数可）４２を実行することは、エグゼキュータ（複数可）２２をＲＰＡスクリプト（複数可）４２を翻訳することと、各ホストマシンのプロセッサに命令して、その結果得られた実行時のパッケージをメモリ中にロードさせることと、実行時のパッケージの実行を開始させることとを含み得る。

ＲＰＡエージェント２４は、ロボットエグゼキュータ（複数可）２２オペレーションを管理し得る。例えば、ＲＰＡエージェント２４は、ロボットエグゼキュータ（複数可）２２による実行の対象となるタスク／スクリプトを、人間のオペレータからの入力に従っておよび／またはスケジュールに従って選択し得る。エージェント２４は、ジョブを開始および停止させ得、エグゼキュータ（複数可）２２の多様な動作パラメータを構成し得る。ロボット１２が複数のエグゼキュータ２２を含む場合、エージェント２４は、自身のアクティビティおよび／またはプロセス間通信を調整し得る。ＲＰＡエージェント２４は、ＲＰＡロボット１２、オーケストレータ１４および／または他のエンティティアイ間の通信をさらに管理し得る。

Ｗｉｎｄｏｗｓ（登録商標）環境で実行されるいくつかの実施形態において、ロボット１２は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）サービスコントロールマネージャ（ＳＣＭ）によって管理されるサービスをデフォルトでにストールする。その結果、このようなロボットは、相互作用のＷｉｎｄｏｗｓ（登録商標）セッションをローカルシステムアカウントの下において開かせ得、Ｗｉｎｄｏｗｓ（登録商標）サービスのプロセッサ特権を有し得る。例えば、コンソールアプリケーションが、ＳＣＭによって管理されたロボットによって起動され得る。いくつかの実施形態において、ロボット１２は、プロセッサ特権（ユーザーモード、リング３）のユーザレベルにおいてインストールされ得る。このようなロボットは、各ロボットがインストールされる際にユーザーが有する権利と同じ権利を有する。例えば、このようなロボットは、各ユーザーが起動させることが可能な任意のアプリケーションを起動させることができる。複数の同時発生の相互作用のセッション（例えば、Ｗｉｎｄｏｗｓ（登録商標）サーバー２０１２）をサポートするコンピューティングシステム上において、複数のロボットが同時に実行し得、各ロボットは、別個のＷｉｎｄｏｗｓ（登録商標）セッションにおいて異なる資格情報を用いる。このような資格情報は、ＲＰＡリソース仕様４４を介して供給され得る（図３に関連して上記を参照）。

いくつかの実施形態において、ロボット１２およびオーケストレータ１４は、クライアント／サーバー構成において実行し得る。クライアント側、サーバー側または双方は、任意の所望の数のコンピューティングシステム（例えば、物理的マシンまたは仮想マシン）を本発明の範囲から逸脱すること無く含み得る点に留意されたい。このような構成において、エグゼキュータ（複数可）２２およびＲＰＡエージェント２４を含むロボット１２は、クライアント側において実行し得る。ロボット１２は、いくつかのジョブ／ワークフローを同時に実行させ得る。ＲＰＡエージェント２４（例えば、Ｗｉｎｄｏｗｓ（登録商標）サービス）は、エグゼキュータ２２の単一のクライアント側の接触点として機能し得る。エージェント２４は、ロボット１２とオーケストレータ１４との間の通信をさらに管理し得る。いくつかの実施形態において、通信がエージェント２４によってインストールされると、ＷｅｂＳｏｃｋｅｔチャンネルがオーケストレータ１４に対して開かれ得る。その後、エージェント２４は、このチャンネルを用いて、各エグゼキュータ２２の状態についての通知を（例えばハートビート信号として）オーケストレータ１４へ送信し得る。次に、オーケストレータ１４は、このチャンネルを用いて、肯定応答、ジョブリクエストおよび他のデータ（例えば、ＲＰＡスクリプト（複数可）４２およびリソースメタデータをロボット１２）へ送信し得る。

オーケストレータ１４は、恐らくは複数の物理的マシンおよび／または仮想マシンにわたって分散されたサーバー側において実行し得る。１つのこのような実施形態において、オーケストレータ１４は、ウェブアプリケーションであり得るオーケストレータユーザインターフェース（ＵＩ）１７と、１組のサービスモジュール１９とを含み得る。オーケストレータＵＩのいくつかの例について、以下に説明する。サービスモジュール１９は、１組のオープンデータプロトコル（ＯＤａｔａ）Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）アプリケーションプログラミングインターフェース（ＡＰＩ）エンドポイント、および１組のサービスＡＰＩ／ビジネスロジックを含み得る。ユーザーは、オーケストレータ１４との対話を（例えば、ブラウザ上の専用オーケストレータインターフェースを開くことにより）オーケストレータＵＩ１７を介して行い得、オーケストレータ１４に対して多様なアクションを実行するよう命令し得る（例を挙げると、選択されたロボット１２上のジョブの開始、ロボットグループ／プールの生成、ワークフローのロボットへの割り当て、キューに対するデータの追加／削除、無人実行のためのジョブのスケジューリング、ロボットまたはワークフロー毎のログの分析）。オーケストレータＵＩ１７は、ハイパーテキストマークアップ言語（ＨＴＭＬ）、Ｊａｖａスクリプト（ＪＳ）または当該分野において公知の他の任意のデータフォーマットを用い得る。

オーケストレータ１４は、サービスＡＰＩ／ビジネスロジックの選択的呼び出しにより、ユーザーからリクエストされたアクションを実行し得る。加えて、オーケストレータ１４は、ロボット１２との通信のためにＲＥＳＴ ＡＰＩエンドポイントを用い得る。ＲＥＳＴ ＡＰＩは、構成、ロギング、監視およびキューイング機能を含み得る。構成エンドポイントが、ユーザー、ロボット、権限、資格情報および／または他のプロセスリソースなどの定義および／または構成のために用いられ得る。ロギングＲＥＳＴエンドポイントが、異なる情報（例えば、エラー、ロボットから送信された明示的メッセージ、および他の環境別情報）をログするために用いられ得る。デプロイメントＲＥＳＴエンドポイントは、ロボットが実行対象のＲＰＡスクリプト（複数可）４２のバージョンについて問い合わせる際に用いられ得る。キューイングＲＥＳＴエンドポイントは、キューおよびキューアイテム管理（例えば、キューへのデータ追加）、キューからのトランザクション取得、トランザクションのステータス設定などを担当し得る。ＲＥＳＴエンドポイントの監視により、オーケストレータ１４のｗｅｂアプリケーションコンポーネントおよびＲＰＡエージェント２４が監視され得る。

いくつかの実施形態において、ＲＰＡ環境１０（図１）は、ＲＰＡデータベース１８へ接続されたデータベースサーバー１６をさらに含む。サーバー１６がクラウドコンピューティングプラットフォーム上に設けられた実施形態において、サーバー１６は、データベースサービスとして（例えば、１組のデータベースコネクタを有するクライアントとして）埋設され得る。データベースサーバー１６は、ＲＰＡ環境１０に関連するデータを選択的にデータベース１８内に保存および／またはデータベース１８から取り出すように構成される。このようなデータを挙げると、多様な個々のロボットまたはロボットプールの構成パラメータ、多様なロボットによって実行されるワークフローを特徴付けるデータ、ワークフローと当該ワークフローをタスク付与されるロボットとを関連付けるデータ、ユーザーを特徴付けるデータ、役割、スケジュール、キューなどがある。データベースサーバー１６によって保存および／または取り出される別の例示的なデータカテゴリを挙げると、各実行側のロボットの現在の状態を特徴付けるデータがある。データベースサーバー１６によって保存および／または取り出される別の例示的なデータカテゴリを挙げると、多様なワークフローに必要なＲＰＡリソースを特徴付けるＲＰＡリソースメタデータがある（例えば、多様なリソース属性（例えば、ファイル名、ロケーション、資格情報）のデフォルト値および／または実行時の値）。さらに別の例示的なデータカテゴリを挙げると、実行時において多様なロボットによってログされるメッセージがある。データベースサーバー１６およびデータベース１８は、当該分野において公知の任意のデータ格納プロトコルおよびフォーマットを用い得る（例えば、ストラクチャードクエリ言語（ＳＱＬ）、ＥｌａｓｔｉｃＳｅａｒｃｈ（登録商標）およびＲｅｄｉｓ（登録商標））。いくつかの実施形態において、データの収集および管理は、オーケストレータ１４によって（例えばＲＥＳＴエンドポイントのロギングを介して）行われる。オーケストレータ１４は、ストラクチャードクエリをデータベースサーバー１６へさらに発行し得る。

いくつかの実施形態において、ＲＰＡ環境１０（図１）は、環境１０の多様な部材を相互接続させる通信チャンネル／リンク１５ａ～１５ｅをさらに含む。このようなリンクは、当該分野において公知の任意の方法（例えば、仮想ネットワークリンク、仮想プライベートネットワーク（ＶＰＮ）またはエンドツーエントトンネル）に従って実行され得る。いくつかの実施形態において、リンク１５ａ～１５ｅの一部または全てを介して循環されるデータがさらに暗号化される。

当業者であれば、ＲＰＡ環境１０の多様なコンポーネントは、別個のホストコンピュータシステム（物理的機器および／または仮想マシン）上において実行され得かつ／または実行し得ることを理解する。図４は、本発明のいくつかの実施形態多様なこのようなＲＰＡホストシステム２０ａ～２０ｅを示す。各ホストシステム２０ａ～２０ｅは、ハードウェアプロセッサと、プロセッサ命令および／またはデータを保存するメモリユニットとを少なくとも有するコンピューティングシステム（個々のコンピューティング装置または１組の相互接続されたコンピュータ）を示す。例示的なＲＰＡホスト２０ａ～２０ｃは、企業メインフレームコンピュータ、パーソナルコンピュータ、ラップトップコンピュータおよびタブレットコンピュータ、移動通信デバイス（例えば、スマートフォン）および電子ブックリーダーなどを含む。アイテム２０ｄ～２０ｅとして図示される他の例示的なＲＰＡホストを挙げると、プラットフォーム別のプロトコルに従って中心的に管理される複数の相互接続されたサーバーコンピュータシステムを含むクラウドコンピューティングプラットフォームがある。クライアントは、このようなクラウドコンピューティングプラットフォームとの対話を、プラットフォーム別のインターフェース／ソフトウェア層／ライブラリ（例えば、ソフトウェア開発キット－ＳＤＫ、プラグインなど）および／またはプラットフォーム別のコマンド構文を用いて行い得る。例示的なプラットフォーム別のインターフェースを挙げると、Ａｚｕｒｅ（登録商標）ＳＤＫおよびＡＷＳ（登録商標）ＳＤＫなどがある。ＲＰＡホスト２０ａ～２０ｅは、通信ネットワーク１３（例えば、インターネット）によって通信可能に連結され得る。

図５は、本発明のいくつかの実施形態によるオーケストレータＵＩ１７によって公開される例示的なビューを示す。ＵＩ１７は、ユーザーによるＲＰＡの多様な態様の設定および構成を可能にするメニュー領域３２を含み得る（例えば、ロボット１２ａ～１２ｃの個々のインスタンスの管理、ロボット１２ａ～１２ｃの特定のマシン（図４中のＲＰＡホスト２０ａ～２０ｅ）への割り当て、ＲＰＡパッケージ４０のアップロードおよび構成、多様なプロセスリソースのロケートまたは生成など）。図５に示す例示的ビューは、パッケージ管理のために構成される。いくつかの実施形態において、ＲＰＡパッケージ４０（例えば図２および図３も参照されたい）は、各パッケージの開発者によってかつ／またはオーケストレータ１４の管理者によってオーケストレータ１４へアップロードされる。例示的なＵＩ１７は、アップロードされたパッケージ４０をリスト化し得、さらなるパッケージのアップロードの制御を公開し得る。いくつかの実施形態において、個々のパッケージ名／アイコンをクリックするとユーザーが各パッケージのコンテンツをさらに調査および／または各パッケージを構成することが可能になり得る。１つのこのような例において、パッケージ名（例えば、図５中の「週次請求書」）をクリックすると、サブメニューおよび／または各ワークフローに必要なリソースをリスト化するさらなるユーザインターフェースが公開され、各リソースを特徴付ける多様なメタデータ（例えば、デフォルトおよび／または各リソースの実行時ロケーション）がさらに示される。

図６は、本発明のいくつかの実施形態による、オーケストレータＵＩ１７によって公開される別の例示的なビューを示す。図示のビューにより、ＲＰＡリソースの（すなわち、多様なワークフローの実行に必要なリソースの）管理が可能になる。ＵＩ１７により、ユーザーがリソースをタイプ毎（例えば、キュー、ファイル、資格情報）にリスト化することを可能にするメニュー３４および／またはユーザーがリソースをロケーション毎にリスト化することを可能にする別のメニュー３６が公開され得る。ロケーションメニュー３６は、１組のアイコンおよび／またはユーザー用ロケーション名を含み得る（例えば、図６に示すようなフォルダおよびサブフォルダを含むファイルシステムとして配置されたもの）。本明細書中、「ユーザー用名」という用語は、実際のファイル名または保存／ネットワークのロケーションと対照的に、画面上の名前（別名はユーザーへ表示されるラベル）を示す。いくつかのユーザー用名は、実際のファイル名、ファイルシステム経路またはネットワークアドレスと一致し得る。ロケーションメニュー３６の各メニューアイテム（例えば、「請求書日本」というユーザー用名によって特定されるフォルダ）は、別個の保存場所を示し得る（例えば、ローカルのファイルシステムまたはリモートのファイルシステムの別個のフォルダあるいはアドレス可能な単位のメモリまたは保存媒体）。上記保存場所は、（現在各ワークフローの実行がタスク付与されているロボットを実行する）ＲＰＡホストシステムの一部であり得るかまたはそのようなＲＰＡホストシステムへ通信可能に連結され得る。

いくつかの実施形態において、メニュー３６によって表示されるロケーション名は、各リソース（複数可）のデフォルトロケーション名を示し得る（すなわち、設計時に各ＲＰＡワークフロー開発者によって示されかつリソース仕様４４中に含まれるロケーション名）。他の実施形態において、表示されるロケーション名は、実行時ロケーション名を示し得る（すなわち、各ワークフローの実行時に各リソースが実際に存在する場所のロケーションのユーザー用名）。以下にさらに述べるように、リソースの実行時ロケーションは、開発者によって示されるデフォルトロケーションと一致していてもよいし、一致していなくてもよい。いくつかの実施形態において、リソースは、以下に詳細を示すように、オーケストレータＵＩ１７のユーザーによって再度名前付けおよび／または再配置され得る。さらに別の例示的な実施形態において、メニュー３６は、デフォルトのロケーションおよび実行時ロケーション双方を各リソースについて表示し得る。

各リストされたリソース５０について、ＵＩ１７は、各リソースの複数の特性を表示し得る。キューの例示的な例において、特徴付けの属性を挙げると、各キューのユーザー用名（図６中の「Ｑ１」）、多様なリソース利用状況データ（例えば、各キューを用いるロボット／プロセスのリスト）、デフォルトおよび／または各キューの実行時ロケーション、各キュー中のキューアイテムのトータルカウント、今まで処理が成功しているキューアイテムのカウントなどがある。表示された情報の一部は、関連付けられたＲＰＡパッケージのリソース仕様４４中に定義されたリソースメタデータに従って決定され得る。

いくつかの実施形態において、図６中に示す例示的ビュー中の選択されたリソースがクリックされるか、タップされるか（または他の様態でアクティベートされる）と、サブメニューまたはさらなるユーザインターフェースが公開され得、ユーザーが各リソースの多様な態様を構成することが可能になる。このようなリソース編集ＵＩの例を以下に示す。

図７は、本発明のいくつかの実施形態による、オーケストレータＵＩ１７によって表示されるさらに別の例示的なビューを示す。図示のビューは、実行のために（例えば、新規ＲＰＡプロセスの生成時に）ロボットを構成するステップのシークエンスの一部として表示され得る。本明細書中、「ＲＰＡプロセス」という用語は、選択されたＲＰＡロボット（またはその上で実行されるＲＰＡホスト２０ａ～２０ｅ）と、選択されたワークフローとの間の関連付けを示す。換言すると、ＲＰＡプロセスを生成することは、選択されたワークフローを選択されたロボットまたはマシンへ割り当てることを含む。

いくつかの実施形態において、ＲＰＡパッケージの受信に応答して、オーケストレータ１４は、各パッケージのリソース仕様４４をパースして、各ワークフローの実行の成功に必要なリソースを特定し得る。請求書からデータ抽出を行うように設計されたワークフローの一例において、ロボットは、請求書のキューが所定のロケーションに存在することを必要とし得る。そうしないと、各ロボット／ワークフローの実行試行がエラーに繋がることが多くなる。そのため、各キューは、各ワークフローまたはロボットの必要なリソースとしてみなされる。図７に示すような実施形態において、オーケストレータＵＩ１７は、現在構成されている各ワークフロー／ＲＰＡプロセスと関連付けられたＲＰＡパッケージのリソース仕様４４に従って決定された必要なリソースのリストをユーザへ表示するように構成され得る。この表示は表形式をとり得、各リソースは、各リソースを特徴付ける属性値／メタデータ５２が１行内に示され得る。リソースを特徴付けるメタデータの表示例を挙げると、例えば、リソースタイプ、ユーザー用リソース名、および各リソースのロケーションがある。例示的な実施形態において、表示されたリソースメタデータ５２は、各リソースのデフォルトロケーション、各リソースの実行時ロケーションまたはこれら双方を含み得る。

いくつかの実施形態において、オーケストレータＵＩ１７は、各リソースのインスタンスが実行時ロケーションにおいて現在利用可能であるかを示す利用可能性インジケータ５４をさらに表示する。利用可能性インジケータ５４を挙げると、テキストラベル、記号（例えば、チェックマーク、クエスチョンマーク）または各状況（例えば、利用可能なリソース、紛失、不明）を示すアイコン（例えば、絵文字）がある。別の実施形態において、手旗信号のようなグラフィックまたは記号が各状況を示すために用いられ得る。例えば、紛失しているリソースが赤点によって示され得る一方、利用可能なリソースが緑点によって示され得る。

オーケストレータＵＩ１７のいくつかの実施形態においてさらに実行されるリソース編集機構により、ＵＩ１７のユーザーがプロセスリソースに対する選択された変更を作用させることが可能になる。図７に示すような一例において、各リストされたリソースについて、ＵＩ１７に含まれるリソース編集制御は、専用視覚要素５６（例えば、クリック可能なアイコンまたはテキスト要素）を介してアクティベートされる。いくつかの実施形態において、選択されたリソースタイプについてかつ／または選択された状況において（例えば、各リソースが紛失しているかまたは不完全に構成された場合に）のみ、要素５６を表示し得る。別の例示的な実施形態において、リソース編集機構（および／または視覚要素５６の関連付けられた表示）は、選択されたリソース、選択されたワークフローおよび／または選択されたロボット／ＲＰＡホストのみについてアクティベートされ得る。

いくつかの実施形態において、リソース編集制御がアクティベートされると、ＵＩ１７は、図８－Ａ～図８－Ｂに示すような別個のリソース編集ＵＩを表示させ得る。図８－Ａに示すリソース編集メニュー６０ａは、各プロセスリソースに関連してユーザが多様なアクティビティを行うことを可能にする１組のメニューアイテムを有する。キューの図示の例において、メニューは、例えば、キューオブジェクトを必要な特性と共に生成する選択肢と、アイテムをキューへアップロードする選択肢と、複製する選択肢と、各キューオブジェクトを削除する選択肢とを含む。図８－Ａは、各リソースの構成のために例示的なメニューアイテムを選択すると、さらなるサブメニューが開かれ得、その結果、ユーザーが例えば各リソースの再度名前付けおよび／または各リソースの再配置を行うことが可能になる様子をさらに示す。この文脈において、「リソースを再配置する」とは、（各リソースを新規のロケーションに実際に移動させるのではなく）実行側のロボットを新規のロケーションにおける各リソースの探索のためにリダイレクトさせることを指す。いくつかの実施形態において、再配置は、リソースメタデータ（例えば、ファイル名および／またはロケーションインジケータ（例えば、ファイルシステム経路））を新規の実行時ロケーションの方向へ変更することを含む。

図８－Ｂに示す例示的なリソース編集ＵＩ６０ｂにより、選択されたプロセスリソースのユーザーによる再配置が可能になる。ＵＩ６０ｂは、各リソースの多様なデフォルト特性（すなわち、設計時にＲＰＡパッケージ４０中に指定されたデフォルト値）（例えば、デフォルトリソース名およびデフォルトロケーション）を表示し得、フォームフィールド６２などの制御をさらに表示し得る。このフィールド内において、ユーザーは、実行時ロケーションインジケータを各リソースについて入力し得る。図８－Ｂに示すようないくつかの実施形態において、プロセスリソースの編集が試行されると、ＵＩ１７は、警告ダイアログ６４をユーザーに対して表示し得る。警告ダイアログ６４は、他の現在構成されているＲＰＡプロセスが当該変更によって影響を受けるかを示し得、この変更を行うかについてユーザに確認を要求する。いくつかの実施形態において、例えば、影響を受けるプロセスの識別用データ（例えば、プロセスＩＤ、名前など）がさらに表示され得、さらなる多様な情報が表示され得、ヘルプまたはガイダンスが提供され得る。

ファイルリソースの場合の例示的なリソース編集オペレーションを挙げると、例えば、デフォルトロケーションの各ファイルのインスタンスの生成、各ファイルの再度の名前付け、ファイルの再配置（すなわち、ロボットを新規のロケーションへリダイレクトすること）、当該ファイルの複製、およびファイルの削除がある。他のリソースタイプ（例えば、ネットワーク接続／通信リンク）の場合、リソース編集オペレーションを挙げると、各接続の生成および多様なパラメータ（例えば、リモート接続ピアの識別子、ＶＰＮ資格情報）の再構成がある。

リソース編集機構の他の例示的実行を挙げると、ユーザーが（現在表示されている値のクリック／タップおよびその値の上書きにより）テキスト属性値（例えば、ユーザー用名）を変更することを可能にすることがある。別の例において、ＵＩ１７により、ユーザーが（リソースのユーザー用名のクリック／タップおよびロケーションメニュー３６（図６）から選択されたアイテム（例えば、フォルダ）へのドラッグにより）当該リソースを再配置することが可能になり得る。このような例において、リソース名を表示するＵＩ要素は、リソース編集制御を構成し得る。

図９は、本発明のいくつかの実施形態による、オーケストレータによって行われるステップの例示的シークエンスを示す。典型的なＲＰＡデプロイメントシナリオにおいて、開発者は、ワークフロー（例えば、請求書のキューから特定のデータを抽出するロボットアクティビティのシークエンス）を設計するために、ＲＰＡ設計アプリケーション３０を用いる。いくつかの実施形態において、設計アプリケーションは、図３に示すように、各ロボットアクティビティ（ＲＰＡスクリプト４２）の符号化およびリソース仕様４４を含むＲＰＡパッケージ４０を出力する。次に、ＲＰＡパッケージ４０は典型的には、オーケストレータ１４および／またはＲＰＡロボット（複数可）１２を実行するＲＰＡホストシステム２０ａ～２０ｅへアップロードされる。

パッケージ４０（ステップ１０２）の受信に応答して、ステップ１０４において、オーケストレータ１４は、仕様４４をパースして、ＲＰＡリソース（すなわち、各ワークフローの実行の成功のためにＲＰＡロボットに必要なリソース）を特定し得る。選択された例において、必要なＲＰＡリソースを挙げると、キューオブジェクトまたは処理すべき請求書を保存するロケーションのインジケータ（例えば、ファイルシステムフォルダ）がある。次に、オーケストレータ１４は、全ての特定されたリソース（ステップ１０６～１０８～１１０）を通じて、多様なデータ構造を設定し得る。その後、このデータ構造は、各リソースの管理のためにオーケストレータ１４および／または実行側のロボットによって用いられる。

いくつかの実施形態において、ステップ１１０は、１組のリソース特性（すなわち、各リソースを特徴付けるメタデータ（例えば、各リソースの名前およびロケーション））を決定することを含む。一部のこのようなメタデータは、仕様４４内に含まれ、他のアイテムは、リソース仕様４４中に含まれる情報から恐らくは他のデータに従って抽出され得る。図１０は、本発明のいくつかの実施形態による、例示的なリソースメタデータ５２を示す。メタデータ５２は、１組のデフォルトの（または設計時の）メタデータと、１組の実行時のメタデータとを含み得る。設計時のメタデータは、設計時に（すなわち、各ワークフローの生成時に）設定された各リソースの特性を含む。本明細書中、設計時のメタデータは、デフォルトメタデータとしてもみなされる。例えば、開発者は、リソースのデフォルト名（例えば、図６～図７において「Ｑ１」と呼ばれるキュー）および／または各リソースのデフォルトロケーションを示し得る。ここでも、図６～図７に示す例を参照して、キューＱ１のデフォルトロケーションは、「請求書日本」フォルダ中にあり得る。

リソース仕様４４に含まれるこのようなデフォルト特性と対照的に、実行時のリソースメタデータは、各リソースの実行時インスタンスを特徴付ける。例えば、実行時インスタンスの名前および／またはロケーションは、以下にさらに概要を示す多様な理由により、デフォルトのものと異なり得る。いくつかの実施形態において、オーケストレータ１４は、１組の実行時のメタデータを生成し得、各属性値の初期値を対応するデフォルト値／設計時の値と等しくなるように設定し得る。例えば、初期実行時ロケーションは、デフォルトロケーションと同一であり得る。次に、いくつかの実施形態により、オーケストレータＵＩ１７のユーザーが実行時の値を後で（例えば、本明細書中に記載のようなリソース編集ＵＩ制御を介して）変更することが可能になる。

いくつかの実施形態において、ステップ１１０において、各リソースと関連付けられた１組のデータベース入力がさらに生成され得、この入力（複数可）は、ＲＰＡデータベース１８（図１～図２）中に保存され、リソースメタデータ５２を示す。オーケストレータ１４は、対応するデフォルト属性値と実行時属性値との間のマッピングをさらに設定し得、これにより、各実行時の値の解読をデフォルト値に基づいて行うことまたはこの逆の各ワークフローを実行するタスクをオーケストレータ１４および／またはＲＰＡロボットへ付与することが可能になる。本明細書中、マッピングは、選択された属性のデフォルト値を対応する実行時の値と関連付ける任意の手段（例えば、リソースのデフォルトロケーションと、各リソースの実行時ロケーションとの関連付け）を主に意味する。例示的なマッピングは、データベース入力（例えば、表の１行）を含み得、デフォルト属性値および実行時属性値は、同一のルックアップインデックス（例えば、行ラベル、リソース名）によって接続される。当業者であれば、このようなマッピングを技術的に達成する方法は多数存在し得、記載の例は限定的なものを意図していないことを理解する。

パッケージ４０中に示されるリソース全てについてリソース管理データが生成されたのに応答して、ステップ１１２において、オーケストレータ１４は、他の構成アクティビティに進み得る（例えば、選択されたロボットを各ワークフローの実行（よってＲＰＡプロセスの定義）に割り当てること、ジョブをスケジュールすることおよびプロセス評価アクティビティ／監視アクティビティを行うこと）。さらなるステップ１１４において、オーケストレータ１４は、各ワークフローの実行をタスク付与されたＲＰＡロボットに対してかつ／またはＲＰＡパッケージ４０中に指定された少なくとも１つのリソースへのアクセスを必要とし得る任意のロボットに対して、リソースメタデータを利用可能とし得る。ステップ１１４は、任意のデータ通信方法を含み得る（例えば、図２に関連して上記したようなクライアントメッセージ／サーバーメッセージの交換を介したもの）。

図１１は、本発明のいくつかの実施形態による、オーケストレータ１４によって行われるステップの例示的シークエンスを示す。図示のステップのシークエンスは、例えば初期プロセス構成の一部（すなわち、選択されたロボット上における実行対象として選択されたワークフローの割り当て）として実施してもよいし、あるいは、ユーザーが既存のＲＰＡプロセスの再構成を決心した際に後で実施してもよい。選択されたプロセスの構成の意図を示すユーザー入力が受信されたこと（ステップ１２２）に応答して、ステップ１２４において、オーケストレータ１４は、リソース管理インターフェース（例えば、図７に示す例示的なＧＵＩ）を公開し得る。次に、オーケストレータ１４は、ステップ１３０～１３２～１３４～１３６のシークエンスを各ワークフローに必要な各ＲＰＡリソースについて繰り返し得る。リソースの選択（ステップ１３０）に応答して、ステップ１３２において、各リソースの必要な実行時特性を備えたオブジェクトが、各ワークフローの実行がタスク付与されたロボットにとって現在利用可能であるかを決定し得る。各リソースがファイルを含む例において、ステップ１３２は、各リソースの実行時のファイル名を有するファイルが各リソースの実行時ロケーションにおいて存在するかを決定し得る。各リソースの多様なデフォルト特性および／または実行時特性の決定のために、ステップ１３２は、ＲＰＡデータベース１８中の各リソースと関連付けられた選択された入力をルックアップすることを含み得る。

各現在選択されているＲＰＡリソースについて、ステップ１３４は、利用可能性インジケータ（例えば、図７に示すようなアイテム５４）を表示し得る。さらなるステップ１３６において、ユーザーが選択されたリソースの多様な特性を変更することを可能にするリソース編集ＵＩ制御を表示し得る。例えば、図７中の制御５６および関連付けられた上記記載を参照されたい。

図１２は、本発明のいくつかの実施形態に従ってユーザーがこのような変更を行うことを可能にする、オーケストレータ１４によって実施されるステップの例示的シークエンスを示す。ステップ１５２において、オーケストレータ１４は、リソース編集ＵＩ制御をアクティベートさせるユーザー入力（例えば、図７中のユーザークリック／タップ制御５６）を受信し得る。これに応答して、いくつかの実施形態において、リソース編集インターフェース（例えば、図８－Ａ～図８－Ｂに示す例示的なインターフェース）が公開され得る。いくつかのこのような実施形態において、ステップ１５６～１５８のシークエンスにおいて、選択されたリソースの編集が他のＲＰＡプロセスに影響を与えるかが決定され得、「はい」の場合、警告が表示され得る。ステップ１５６は、他のプロセスまたは各ＲＰＡリソースを使用するように構成されたロボットの特定のためにワークフローおよび／またはＲＰＡリソースをロボットと関連付ける特定の入力について、ＲＰＡデータベース１８をルックアップすることを含み得る。ステップ１５８において、警告（例えば、図８－Ｂ中のダイアログウィンドウ６４）および／またはステップ１５６において特定されたこのような入力についての記述情報がユーザに対して表示され得る。

ステップ１６０において各リソースの編集による作用について肯定応答するユーザー入力の受信に応答して（例えば、ダイアログウィンドウ６４内においてユーザーが「はい」をクリック／タップするのに応答して）、ステップ１６２において、様な特性（例えば、ユーザー用名、ファイル名、ロケーション、および各リソースバージョン）についてユーザーから提供された実行時属性値が受信され得る。さらなるステップ１６４において、オーケストレータ１４は、ＲＰＡデータベース１８中の各リソースと関連付けられた実行時のメタデータを更新し得る。

図１３は、本発明のいくつかの実施形態による、選択されたＲＰＡワークフローの実行についてタスク付与されたＲＰＡロボット１２（図２）によって行われるステップの例示的シークエンスを示す。ロボット１２は、各ワークフローを構成するＲＰＡアクティビティ全てを繰り返し得る。ステップ１７６において選択された各アクティビティについて、ステップ１７８において、現在のアクティビティにおいてＲＰＡリソースへのアクセスが必要であるかが決定され得る。例示目的のため、以下の段落において、現在のアクティビティにファイルへのアクセスが含まれる例について説明する。各ファイルは、デフォルトメタデータに従ったファイルＸおよび実行時のメタデータに従ったファイルＹとして特徴付けられる（例えば、各ファイルのファイル名および／またはロケーションは、オーケストレータ１４のユーザーによって上記したように変更されている）。

ステップ１７８の結果が「はい」である場合、ステップ１８０において、ロボット１２は、オーケストレータ１４（例えば、図２中のサービスＡＰＩ（複数可）１９）に対して、各リソースを特徴付けるデータについて問い合わせをし得る。さらなるステップ１８２において、各リソースの実行時特性／メタデータが決定され得る。当業者であれば、ステップ１８０～１８２は、各実行時のメタデータを実際に決定するパーティに応じて多様な様態で実施可能であり得ることを理解する。好適な実施形態において、オーケストレータ１４は、各リソースについてデフォルト属性値と実行時属性値との間のマッピングをロボット１２に対して公開し得る。次に、ロボット１２は、各マッピングを積極的に用いて、ＲＰＡスクリプト４２および／または仕様４４において規定されるような各リソースのデフォルト特性に従って実行時のメタデータを決定し得る。換言すると、このような実施形態において、ロボット１２は、ファイルＹについて（すなわち、各リソースの実行時特性を用いて）オーケストレータ１４に問い合わせし得る。このような運用方法は、ロボット１２およびオーケストレータ１４の従来のクライアント／サーバーの役割が維持されかつメタデータの翻訳というさらなる負担をオーケストレータ１４にかけないため、好適であり得る。

別の実施形態において、ロボット１２は、各リソースのデフォルト特性（例えば、デフォルトファイル名、デフォルトロケーション）に従って、オーケストレータ１４への問い合わせを定式化し得る。これに応答して、オーケストレータ１４は、デフォルトから実行時のマッピングを用いて、各リソースの実行時特性を決定し得、実行時のメタデータと共にロボット１２に対して応答し得る。換言すると、このような実施形態において、ロボット１２は、ファイルＸを特徴付けるデータをリクエストし得るが、ファイルＹを特徴付けるデータを受信し得る。

ステップ１８４において、ロボット１２は、現在のＲＰＡアクティビティを実行し得る。この現在のＲＰＡアクティビティは、各ＲＰＡリソースへアクセスすること（例えば、各Ｅｘｃｅｌ（登録商標）ファイルを開くこと）を含み得る。ステップ１８６において、現在のアクティビティが成功裏に完了したかが決定され得、結果が「はい」である場合、ロボット１２は、ステップ１７２～１７４に戻って、ワークフロー中の次のアクティビティへ前進し得る。各ワークフロー中に任意のさらなるアクティビティが含まれないという結論にステップ１７２において至った場合、ロボット１２は、各ジョブのステータスを示すレポートをオーケストレータ１４へ送信し得る。いくつかの実施形態において、エラーが発生したことがステップ１８６において決定された場合（例えば、ロボット１２が特定のＲＰＡリソースにアクセスできなかった場合）も、レポートがオーケストレータ１４へ送られる。次に、オーケストレータ１４は、多様なプロセスおよび／またはリソース管理数量／統計の計算をこのようなレポートのコンテンツに従って行い得、このような情報をオーケストレータＵＩ１７内に表示し得る（例えば、図６に示すリソース利用状況データを参照）。

図１４は、本明細書中に記載の方法のうちいくつかを実行するようにプログラムされたコンピューティング装置８０の例示的ハードウェア構成を示す。機器８０は、ロボット１２ａ～１２ｃおよび／またはオーケストレータ１４（図１）を実行するように構成されたＲＰＡホストプラットフォーム２０ａ～２０ｅ（図４）のうちいずれかを含み得る。図示の機器８０は、パーソナルコンピュータ、他のコンピューティングデバイス（例えば、サーバー、携帯電話、タブレットコンピュータ）であり、ウエアラブルコンピューティングデバイスの場合、構成が若干異なり得る。プロセッサ（複数可）８２は、１組の信号および／またはデータと共に計算的オペレーションおよび／またはロジック的オペレーションを実行するように構成された物理的デバイス（例えば、マイクロプロセッサ、半導体基板上に形成されたマルチコア集積回路）を含む。このような信号またはデータは、符号化され得、プロセッサ命令（例えば、マシンコード）の形態でプロセッサ（複数可）８２へ送達され得る。プロセッサ（複数可）８２は、中央処理装置（ＣＰＵ）および／またはグラフィックスプロセッシングユニット（ＧＰＵ）のアレイを含み得る。

メモリユニット８３に含まれ得る揮発性のコンピュータにより読み出し可能な媒体（例えば、ダイナミックランダムアクセスメモリ－ＤＲＡＭ）は、オペレーション実行時においてプロセッサ（複数可）８２によってアクセスまたは生成されるデータおよび／または命令符号化を保存する。入力デバイス８４を挙げると、コンピュータキーボード、マウス、トラックパッドおよびマイクロフォンなどがある（例えば、ユーザーがデータおよびおよび／または命令を機器８０中へ導入することを可能にする各ハードウェアインターフェースおよび／またはアダプタ）。出力デバイス８５を挙げると、表示デバイス（例えば、モニターおよびスピーカー）ならびにハードウェアインターフェース／アダプタ（例えば、グラフィックカード）があり、各コンピューティングデバイスがデータをユーザーへ通信させることを可能にする。いくつかの実施形態において、入力デバイスおよび出力デバイス８４～８５は、共通するハードウェア（例えば、タッチスクリーン）を共有する。保存デバイス８６は、ソフトウェア命令および／またはデータの不揮発性の保存、読み出しおよび書き込みを可能にするコンピュータにより読み出し可能な媒体を含む。例示的な保存デバイスを挙げると、磁気ディスクおよび光ディスクならびにフラッシュメモリデバイスや、取り外し可能な媒体（例えば、ＣＤディスクおよびドライブおよび／またはＤＶＤディスクおよびドライブ）がある。ネットワークアダプタ（複数可）８７は、電気通信ネットワーク（例えば、図４中のネットワーク１３）へ連結された物理リンクを介しておよび／または他のデバイス／コンピュータシステムへデータを通信する機械信号、電気信号およびシグナリング回路を含む。アダプタ（複数可）８７は、データの送信および／または受信を多様な通信プロトコルを用いて行うように構成され得る。

コントローラハブ９０は、複数のシステム、周辺バスおよび／またはチップセットバス、ならびに／あるいはプロセッサ（複数可）８２と機器８０のハードウェアコンポーネントの残りとの間の通信を可能にする他の全ての回路を一般的に示す。例えば、コントローラハブ９０は、メモリコントローラ、入力／出力（Ｉ／Ｏ）コントローラおよび割り込みコントローラを含み得る。ハードウェア製造業者に応じて、いくつかのこのようなコントローラは、単一の集積回路内へ設けられ得、かつ／または、プロセッサ（複数可）８２と一体化され得る。別の例において、コントローラハブ９０は、プロセッサ８２をメモリ８３へ接続させるノースブリッジおよび／またはプロセッサ８２をデバイス８４、８５、８６および８７へ接続させるサウスブリッジを含み得る。

上記した例示的なシステムおよび方法によれば、（ＲＰＡリソース（例えば、ファイル、キュー、データベース、資格情報一式）のデフォルト特性の変更をいつでも仮想的に行うための）ユーザーフレンドリーなインターフェースの提供により、ＲＰＡロボットの管理が促進される。編集可能な特性を挙げると、例えば、名前、ロケーション、および各リソースのバージョンがある。次に、このような変更は、各リソースへのアクセスを必要とするワークフローを実行するロボット全てへ伝播される。重大なことは、いくつかの実施形態によれば、ユーザーが（各リソースを使用するワークフローの仕様の変更する必要無しに）上記各変更を適用することが可能であることである。

典型的なＲＰＡシナリオにおいて、ＲＰＡ開発者は、ロボット設計アプリケーションを用いて、アクティビティのシークエンス（例えば、請求書の集合から構造化データを抽出すること、入来するｅメールのパースおよび分類を行うこと）を実行するように構成されたソフトウェアロボットを構築する。次に、各ロボットの仕様が、各ＲＰＡクライアントへ送信される。各ＲＰＡクライアントは、複雑なコンピューティング内部構造を備えた大企業であり得る。各ＲＰＡクライアントは、複数のロボットおよびワークフローの実行を管理するように構成されたロボットオーケストレータを操作することが多い。ＲＰＡワークフローによっては、多様なリソース（例えば、ファイル、キュー、資格情報）へのアクセスが必要になる。しかし、各ロボットの開発者は、クライアントのファイルのロケーションを知らないかまたは知るべきではなく、あるいは、そのようなファイルへのアクセスのための資格情報も持たないかまたは持つべきではない。そのため、従来のＲＰＡの場合、クライアント側のＩＴ専門家（例えば、オーケストレータ管理者）は典型的には、受信されたロボット仕様をローカル内部構造に適合させるというタスクが付与される。

しかし、ロボット仕様を変更するためには、ＲＰＡ（特にロボット設計ソフトウェア）についての社内知識（すなわち、平均的なＩＴ専門家のスキルをはるかに超えたスキル）が実質的に必要なることが多い。あるいは、ロボットを変更するためには、ロボット開発者との協働が必要になり得、プロセスが緩慢かつ非実際的になり得る。

いくつかの実施形態によれば、クライアント側のユーザーがロボット仕様から独立してＲＰＡリソースを管理することを可能にすることと、クライアント側の管理またはＲＰＡリソースのためのユーザーフレンドリーなユーザインターフェースを提供することにより、ソフトウェアロボットのクライアント側の管理が促進される。いくつかの実施形態によれば、オーケストレータＵＩへ新規の機能が付加されて、ＲＰＡリソース管理がロボット管理の他の態様（例えば、スケジューリングおよび監視）と簡便に集約化される。

従来のＲＰＡの場合、ロボットワークフロー実行を「アウトオブボックスで」実行しようとすると、実行に必要なリソースの紛失または誤構成に起因して実行できない場合がある。さらに、クライアント側のＲＰＡユーザインターフェースの場合、このような不具合の理由に気づかないことが多く、これを超えた場合、「ファイルがみつかりません」などの一般的なエラーメッセージが表示され得る。ロボットは、特定のリソース（例えば、ファイル、キュー）を（設計時に開発者が設定したデフォルトロケーションにおいて）探索するように事前構成された状態で到着し得るが、従来の実行時のインターフェースの場合、このような情報をユーザーに表示しない場合がある。そのため、クライアント側のオペレータが記各ワークフローをローカルコンピューティング環境の特殊性に適合させようとすると、各ワークフローに必要なリソースのタイプと、オペレーションの成功のために当該リソースをどのように構成すべきかとを発見するのに難儀し得る。

このような従来のＲＰＡと対照的に、いくつかの実施形態によれば、選択されたワークフローに必要なリソース全てをリスト化したリソース管理インターフェースが提供され、各リソースの実行時インスタンスが現在利用可能であるかを示す利用可能性インジケータがさらに表示される。このような情報により、各ワークフローの要件および構成選択肢についての理解がさらなる文書の必要無しに促進される。さらに、このリソース利用可能性情報は、各ワークフローの実行の準備時に表示され得るため、クライアント側のユーザーは、不具合に反応する代わりに、潜在的問題の予期および対処を先を見据えつつ行うことが可能になる。

いくつかの実施形態において、リソース管理インターフェースは、紛失しているリソースを生成するための１組の制御をさらに公開する（例えば、必要なファイルをデフォルトロケーションへアップロードすること、キューおよび／または資格情報オブジェクトを生成すること、ＶＰＮチャンネルをリモートリソースに対して構成すること）。いくつかの実施形態において、選択されたＲＰＡリソースの多様な特性（例えば、ファイル名、ユーザー用名（すなわち、各ＵＩ内に表示されるようなリソースのラベル／名称）および各リソースのロケーション）のクライアント側ユーザーによる変更を可能にするリソース編集ＵＩ制御がさらに公開される。ユーザーは、例えば、開発者が設計時に選択した名称よりもより情報価値のある名称を用いてリソースを再度名前付けし得る。各リソースの再配置により、各ワークフローのローカルコンピューティング環境への適合が実質的に促進され得る。すなわち、クライアント側のユーザーは、開発者が設計時において選択したデフォルトロケーション（複数可）の仕様する必要無く、ロボットを任意の保存場所へ仮想的にリダイレクトするだけで済む。このようなユーザーフレンドリーなリソース再配置機構により、例えば、同一ワークフローの別個のインスタンスを別個の目標ファイル／フォルダに対して実行することが可能になり得、各ワークフローの仕様の必要は全く無くなる。

いくつかの実施形態において、各リソースのデフォルト特性（すなわち、特性（例えば、開発者が設計時に選択したファイル名およびロケーション））と各リソースの実行時特性（すなわち、（クライアント側ユーザーによって編集され得る）各インスタンスの実行時インスタンス特性）との間のマッピングの維持により、リソース編集機構を実行し得る。いくつかの実施形態において、実行側のロボットは、オーケストレータとの通信をメッセージ交換を介して行い得、ここで、ロボットは、選択されたリソースのデフォルト特性に従って記述されたリクエストを送信する。これに応答して、オーケストレータは、マッピングをロボットに公開し得、これにより、ロボットが各リソースの実行時特性を決定することが可能になる。

上記実施形態は、本発明の範囲から逸脱すること無く多数の様態において変更され得ることが当業者にとって明らかである。よって、本発明の範囲は、以下の特許請求の範囲およびその法律的同等物によって決定されるべきである。

Claims (19)

1. コンピュータシステムの少なくとも１つのハードウェアプロセッサを用いて、複数のソフトウェアロボットを管理するように構成されたロボティックプロセスオートメーション（ＲＰＡ）オーケストレータを実行することを含む方法であって、
   ＲＰＡワークフローの符号化と、前記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含むＲＰＡパッケージを受信することであって、前記ＲＰＡリソースは、コンピュータファイル、キュー、およびデータベースからなる群から選択されたアイテムを含む、ことと、
   前記ＲＰＡワークフローを実行対象として前記複数のソフトウェアロボットのうち選択されたロボットに割り当てることであって、前記ＲＰＡワークフローを前記選択されたロボットに割り当てることは、前記ＲＰＡワークフローの実行の準備のために、
   前記ＲＰＡリソースの実行時インスタンスが前記デフォルトロケーションにおいて利用可能であるかを決定すること、および、
   オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することであって、前記オーケストレータＵＩは、前記決定の結果に従って選択されたリソース利用可能性インジケータを表示する、こと、
   を含む、割り当てることと、
   を行うようにさらに構成される、方法。
2. 前記ＲＰＡオーケストレータは、前記ＲＰＡリソースの１組のデフォルト特性と前記ＲＰＡリソースの１組の実行時特性との間のマッピングを維持するようにさらに構成され、
   デフォルト特性は、前記ＲＰＡパッケージの内容に従って決定され、前記ＲＰＡリソースのデフォルトロケーションを含み、
   実行時特性は、前記ＲＰＡリソースの実行時インスタンスを特徴付け、前記実行時インスタンスのロケーションを含み、
   前記マッピングにより、前記デフォルトロケーションが前記実行時インスタンスのロケーションと関連付けられる、
   請求項１に記載の方法。
3. 前記ＲＰＡオーケストレータは、
   前記ＲＰＡリソースの実行時インスタンスのロケーションを前記マッピングに従って決定することと、
   前記実行時インスタンスのロケーションのインジケータを前記選択されたロボットへ送信することと、
   を行うようにさらに構成される、
   請求項２に記載の方法。
4. 前記ＲＰＡオーケストレータは、
   他方のロボットへ実行対象として割り当てられた別のワークフローに前記ＲＰＡリソースが必要かに従って、前記複数のソフトウェアロボットのうち別のロボットを特定することと、
   上記に応答して、前記実行時インスタンスのロケーションのインジケータを他方のロボットへ送信することと、
   を行うようにさらに構成される、
   請求項３に記載の方法。
5. 前記ＲＰＡオーケストレータは、前記マッピングを前記選択されたロボットへ公開するようにさらに構成される、請求項２に記載の方法。
6. 前記オーケストレータＵＩは、前記ユーザーが前記ＲＰＡリソースの実行時インスタンスのロケーションを入力することを可能にするリソース編集制御を表示するようにさらに構成される、請求項２に記載の方法。
7. 前記リソース編集制御がアクティベートされると、前記ＲＰＡオーケストレータは、
   他方のロボットへ実行対象として割り当てられた別のワークフローに前記ＲＰＡリソースが必要かに従って、前記複数のソフトウェアロボットのうち別のロボットを特定することと、
   上記に応答して、警告メッセージを前記ユーザーに表示することであって、前記メッセージは、他方のワークフローの識別子または他方のロボットの識別子を含む、ことと、
   を行う、
   請求項６に記載の方法。
8. デフォルト特性は、前記ＲＰＡリソースのデフォルトファイル名をさらに含み、
   実行時特性は、前記ＲＰＡリソースの実行時インスタンスのファイル名をさらに含み、
   前記マッピングにより、デフォルトロケーションファイル名が前記実行時インスタンスのファイル名と関連付けられ、
   前記オーケストレータＵＩは、前記ユーザーが前記実行時インスタンスのファイル名を入力することを可能にするリソース編集制御を表示するようにさらに構成される、
   請求項２に記載の方法。
9. 前記オーケストレータＵＩは、前記ユーザーが前記ＲＰＡリソースのコピーを前記実行時インスタンスのロケーションにアップロードすることを可能にするリソース編集制御を表示するようにさらに構成される、請求項２に記載の方法。
10. 複数のソフトウェアロボットを管理するように構成されたＲＰＡオーケストレータを実行するように構成された少なくとも１つのハードウェアプロセッサを含むコンピュータシステムであって、
    ＲＰＡワークフローの符号化と、前記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含むＲＰＡパッケージを受信することであって、前記ＲＰＡリソースは、コンピュータファイル、キュー、およびデータベースからなる群から選択されたアイテムを含む、ことと、
    前記ＲＰＡワークフローを実行対象として前記複数のソフトウェアロボットのうち選択されたロボットに割り当てることであって、前記ＲＰＡワークフローを前記選択されたロボットに割り当てることは、前記ＲＰＡワークフローの実行の準備のために、
    前記ＲＰＡリソースの実行時インスタンスが前記デフォルトロケーションにおいて利用可能であるかを決定すること、および
    オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することであって、前記オーケストレータＵＩは、前記決定の結果に従って選択されたリソース利用可能性インジケータを表示することを含む、
    ことと、
    を行うようにさらに構成される、コンピュータシステム。
11. 前記ＲＰＡオーケストレータは、前記ＲＰＡリソースの１組のデフォルト特性と前記ＲＰＡリソースの１組の実行時特性との間のマッピングを維持するようにさらに構成され、
    デフォルト特性は、前記ＲＰＡパッケージの内容に従って決定され、前記ＲＰＡリソースのデフォルトロケーションを含み、
    実行時特性は、前記ＲＰＡリソースの実行時インスタンスを特徴付け、前記実行時インスタンスのロケーションを含み、
    前記マッピングにより、前記デフォルトロケーションは前記実行時インスタンスのロケーションと関連付けられる、
    請求項１０に記載のコンピュータシステム。
12. 前記ＲＰＡオーケストレータは、
    前記ＲＰＡリソースの実行時インスタンスのロケーションを前記マッピングに従って決定することと、
    前記実行時インスタンスのロケーションのインジケータを前記選択されたロボットへ送信することと、
    を行うようにさらに構成される、
    請求項１１に記載のコンピュータシステム。
13. 前記ＲＰＡオーケストレータは、
    他方のロボットへ実行対象として割り当てられた別のワークフローに前記ＲＰＡリソースが必要かに従って、前記複数のソフトウェアロボットのうち別のロボットを特定することと、
    上記に応答して、前記実行時インスタンスのロケーションのインジケータを他方のロボットへ送信することと、
    を行うようにさらに構成される、
    請求項１２に記載のコンピュータシステム。
14. 前記ＲＰＡオーケストレータは、前記マッピングを前記選択されたロボットへ公開するようにさらに構成される、請求項１１に記載のコンピュータシステム。
15. 前記オーケストレータＵＩは、前記ユーザーが前記ＲＰＡリソースの実行時インスタンスのロケーションを入力することを可能にするリソース編集制御を表示するようにさらに構成される、請求項１１に記載のコンピュータシステム。
16. 前記リソース編集制御がアクティベートされると、前記ＲＰＡオーケストレータは、
    他方のロボットへ実行対象として割り当てられた別のワークフローに前記ＲＰＡリソースが必要かに従って、前記複数のソフトウェアロボットのうち別のロボットを特定することと、
    上記に応答して、警告メッセージを前記ユーザーへ表示することであって、前記メッセージは、他方のワークフローの識別子または他方のロボットの識別子を含む、ことと、
    を行う、
    請求項１５に記載のコンピュータシステム。
17. デフォルト特性は、前記ＲＰＡリソースのデフォルトファイル名をさらに含み、
    実行時特性は、前記ＲＰＡリソースの実行時インスタンスのファイル名をさらに含み、
    前記マッピングにより、デフォルトロケーションファイル名が前記実行時インスタンスのファイル名と関連付けられ、
    前記オーケストレータＵＩは、前記ユーザーが前記実行時インスタンスのファイル名を入力することを可能にするリソース編集制御を表示するようにさらに構成される、
    請求項１１に記載のコンピュータシステム。
18. 前記オーケストレータＵＩは、前記ユーザーが前記ＲＰＡリソースのコピーを前記実行時インスタンスのロケーションにアップロードすることを可能にするリソース編集制御を表示するようにさらに構成される、
    請求項１１に記載のコンピュータシステム。
19. 命令を保存する非一時的なコンピュータにより読み出し可能な媒体であって、前記命令がコンピュータシステムの少なくとも１つのハードウェアプロセッサによって実行されると、前記コンピュータシステムは、複数のソフトウェアロボットを管理するように構成されたＲＰＡオーケストレータを実行し、前記ＲＰＡオーケストレータは、
    ＲＰＡワークフローの符号化と、前記ＲＰＡワークフローに必要なＲＰＡリソースのデフォルトロケーションのインジケータとを含むＲＰＡパッケージを受信することであって、前記ＲＰＡリソースは、コンピュータファイル、キュー、およびデータベースからなる群から選択されたアイテムを含む、ことと、
    前記ＲＰＡワークフローを実行対象として前記複数のソフトウェアロボットのうち選択されたロボットに割り当てることであって、前記ＲＰＡワークフローを前記選択されたロボットに割り当てることは、前記ＲＰＡワークフローの実行の準備のために、
    前記ＲＰＡリソースの実行時インスタンスが前記デフォルトロケーションにおいて利用可能であるかを決定すること、および、
    オーケストレータユーザインターフェース（ＵＩ）をユーザーへ公開することであって、前記オーケストレータＵＩは、前記決定の結果に従って選択されたリソース利用可能性インジケータを表示する、こと、
    を含む、こと、
    を行うようにさらに構成される、非一時的なコンピュータにより読み出し可能な媒体。

Images