On-Demand Cloud Robots for Robotic Process Automation

Abstract

A system and method for implementing robotic process automation (RPA) in the cloud is provided, wherein an orchestrator in a cloud computing environment receives instructions from a user in a local computing environment to manage an RPA robot, and in response to receiving the instructions, executes the instructions to manage the RPA robot.

Description

[Technical field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 16 / 725,706, filed December 23, 2019, the disclosure of which is incorporated herein by reference in its entirety.

[0002] The present invention relates generally to robotic process automation, and more particularly to on-demand cloud robots for robotic process automation. [Background technology]

[0003] Robotic Process Automation (RPA) is a form of process automation that uses software robots to automate workflows. Typically, RPA is implemented for enterprises on local computing infrastructure managed by the enterprise. However, such local implementations of RPA require maintaining a large computing infrastructure to provision continuously running servers. Recently, it has become possible to leverage cloud computing technology to implement robots on the cloud. However, the cost of maintaining continuously running robots on the cloud is prohibitive. Summary of the Invention

[0004] BRIEF SUMMARY OF EMBODIMENTS One or more embodiments provide a system and method for cloud-based management of a robotic process automation (RPA) robot. An instruction to manage the RPA robot is received at an orchestrator of a cloud computing environment from a user in a local computing environment. The instruction may include an instruction to create the RPA robot, provision the RPA robot, schedule a task on the RPA robot, or decommission the RPA robot. In response to receiving the instruction, the instruction to manage the RPA robot is executed.

[0005] In one embodiment, if the instructions to manage an RPA robot are instructions to create an RPA robot, the instructions are executed by creating the RPA robot for running on a cloud network managed by a user in a cloud computing environment, creating the RPA robot for running on a cloud network managed by a cloud service provider (associated with an orchestrator) in a cloud computing environment, or creating the RPA robot for running on a local network managed by a user in a local computing environment.

[0006] In one embodiment, the RPA robot is for performing tasks in a cloud computing environment and transmitting the results of the tasks to a local computing environment. When the RPA robot is not performing tasks, the RPA robot is in a standby mode to reduce operating costs.

[0007] According to one embodiment, a system and method are provided for cloud-based management of Robotic Process Automation (RPA) robots. A cloud robot pool is maintained in a cloud computing environment. The cloud robot pool includes one or more cloud RPA robots for executing tasks in the cloud computing environment for users of the local computing environment. The cloud robot pool is managed using a cloud orchestrator implemented in the cloud computing environment.

[0008] In one embodiment, managing the cloud robot pool includes one or more of creating a new cloud RPA robot in the cloud robot pool, provisioning one or more cloud RPA robots, scheduling tasks for one or more cloud RPA robots, or decommissioning one or more cloud RPA robots.

[0009] In one embodiment, the cloud robot pool includes a cloud managed robot pool including one or more cloud managed RPA robots running on a cloud network managed by a user, or a cloud service robot pool including one or more cloud service RPA robots running on a cloud network managed by a cloud service provider. When the one or more cloud RPA robots are not performing tasks, the one or more cloud RPA robots are in a standby mode to reduce operating costs. In one embodiment, a local robot pool is also maintained including one or more local RPA robots running on a local network managed by a user.

[0010] Detailed Description of the Embodiments These and other advantages of the present invention will become apparent to those skilled in the art from the following detailed description and accompanying drawings. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is an architectural diagram illustrating a robotic process automation system in accordance with an embodiment of the present invention.

[0012] [Diagram 2] FIG. 1 is an architectural diagram illustrating an example of a deployed robotic process automation system in accordance with an embodiment of the present invention.

[0013] [Diagram 3] FIG. 1 is an architectural diagram illustrating an example of a simplified deployment of a robotic process automation system in accordance with an embodiment of the present invention.

[0014] [Figure 4] 1 illustrates a network architecture for implementing cloud-based management of robotic process automation robots, according to an embodiment of the present invention.

[0015] [Diagram 5] 1 illustrates a method for cloud-based management of robotic process automation robots according to an embodiment of the present invention.

[0016] [Figure 6] 1 is a block diagram of a computing system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] (Detailed Description) Robotic Process Automation (RPA) is used to automate various tasks and workflows. FIG. 1 is an architecture diagram of an RPA system 100 according to one or more embodiments. As shown in FIG. 1, the RPA system 100 includes a designer 102 to enable developers to design automation processes using workflows. More specifically, the designer 102 facilitates the development and deployment of workflows and robots to execute activities within the workflows. The designer 102 provides solutions for application integration and automating business processes of third-party applications, management information technology (IT) tasks, and contact center operations. One commercial example of an embodiment of the designer 102 is UiPath Studio™.

[0018] When designing automation of rule-based processes, developers control the order of execution and the relationships between a custom set of steps developed in a workflow, defined herein as "activities." Each activity may include an action such as clicking a button, reading a file, writing to a log panel, etc. In some embodiments, workflows may be nested or embedded.

[0019] Some types of workflows may include, but are not limited to, sequences, flowcharts, finite state machines (FSMs), and / or global exception handlers. Sequences may be particularly suitable for linear processes, allowing flow from one activity to another without cluttering the workflow. Flowcharts may be particularly suitable for more complex business logic, allowing for decision integration and connection of activities in more diverse ways via multiple branching logic operators. FSMs may be particularly suitable for large workflows. FSMs may use a finite number of states triggered by conditions (i.e., transitions) or activities during their execution. Global exception handlers may be particularly suitable for determining the behavior of a workflow when an execution error is encountered, or for debugging a process.

[0020] Once a workflow is developed in Designer 102, the execution of the business process is orchestrated by Conductor 104, which coordinates one or more Robots 106 that execute the workflow developed in Designer 102. One commercial example of an embodiment of Conductor 104 is UiPath Orchestrator™. Conductor 220 facilitates management of the creation, monitoring, and deployment of resources in an RPA environment. In one example, Conductor 104 is a web application. Conductor 104 can also serve as an integration point with third party solutions and applications.

[0021] The conductor 104 may manage all the robots 106 by connecting and executing them from a centralized point. The conductor 104 may have various capabilities including, but not limited to, provisioning, deployment, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning may include creating and maintaining connections between the robots 106 and the conductor 104 (e.g., web applications). Deployment may include ensuring correct delivery of package versions to the robots 106 assigned for execution. Configuration may include maintaining and delivering robot environment and process configurations. Queuing may include providing management of queues and queue items. Monitoring may include tracking robot identification data and maintaining user permissions. Logging may include storing and indexing logs in a database (e.g., an SQL database) and / or another storage mechanism (e.g., ElasticSearch®, which provides the ability to store large data sets and perform queries quickly. The conductor 104 may provide interconnectivity by acting as a centralized point of communication for third-party solutions and / or applications.

[0022] The robot 106 is an execution agent that executes the workflow built in the designer 102. One commercial example of some embodiments of the robot 106 is UiPath Robots™. Types of robots 106 may include, but are not limited to, attended robots 108 and unattended robots 110. Attended robots 108 are triggered by a user or user events and operate side-by-side with a human user on the same computing system. Attended robots 108 may assist a human user in accomplishing various tasks and may be triggered directly by a human user and / or user events. For attended robots, the conductor 104 may provide a centralized process deployment and logging medium. In certain embodiments, attended robots 108 may only be launched from the robot tray of a web application or from a command prompt. Unattended robots 110 operate in an unattended mode within a virtual environment and can be used to automate many processes, for example, high volume processes, back-end processes, etc. The unattended robot 110 may be responsible for providing remote execution, monitoring, scheduling, and work queue support. Both attended and unattended robots may automate a variety of systems and applications, including, but not limited to, mainframes, web applications, VMs, enterprise applications (e.g., those produced by SAP®, SalesForce®, Oracle®, etc.), and computing system applications (e.g., desktop and laptop applications, mobile device applications, wearable computer applications, etc.).

[0023] In some embodiments, the robot 106 installs the Microsoft Windows Service Control Manager (SCM) management service by default. As a result, such a robot 106 can open an interactive Windows session under the local system account and may have Windows service rights. In some embodiments, the robot 106 may be installed in user mode with the same rights as the user under which a given robot 106 is installed.

[0024] The robot 106 in some embodiments is divided into multiple components, each specialized for a particular task. The robot components in some embodiments include, but are not limited to, an SCM managed robot service, a user mode robot service, an executor, an agent, and a command line. The SCM managed robot service manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host (i.e., the computing system on which the robot 106 executes). These services are responsible for managing the credentials of the robot 106. The console application is launched by the SCM under the local system. The user mode robot service in some embodiments manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host. The user mode robot service may be responsible for managing the credentials of the robot 106. If the SCM managed robot service is not installed, a Windows application may be launched automatically. The executors may execute a given job under a Windows session (e.g., they may execute a workflow), and they may be aware of the dots per inch (DPI) settings per monitor. An agent can be a Windows Presentation Foundation (WPF) application that displays available jobs in a system tray window. An agent can be a client of a service. An agent can ask to start or stop jobs, or change settings. A command line is a console application that is a client of a service and can request jobs to be started and wait for their output. Splitting up robot components can help developers, support users, and make computing systems easier to run, and identify and track what each robot component is doing. Special behavior can be configured for each robot component, for example, different firewall rules for executors and services.As a further example, in some embodiments, the executor may be aware of per-monitor DPI settings, so that workflows can be executed at any DPI, regardless of the configuration of the computing system on which they were created.

[0025] 2 illustrates an RPA system 200 according to one or more embodiments. The RPA system 200 may be or may be a part of the RPA system 100 of FIG 1. It should be noted that the "client side," the "server side," or both may include any desired number of computing systems without departing from the scope of the present invention.

[0026] As shown on the client side of this embodiment, a computing system 202 includes one or more executors 204, an agent 206, and a designer 208. In other embodiments, the designer 208 may not be running on the same computing system 202. The executor 204 (which may be a robotic component as described above) executes the process, and in some embodiments, multiple business processes may be executed simultaneously. In this example, the agent 206 (e.g., a Windows service) is the single point of contact for managing the executor 204.

[0027] In some embodiments, a robot represents an association between a machine name and a username. A robot may manage multiple executors simultaneously. In a computing system (such as Windows Server 2012) that supports multiple interactive sessions running simultaneously (e.g., in a high density (HD) environment), multiple robots may run simultaneously, each running in a separate Windows session using a unique username.

[0028] The agent 206 is also responsible for transmitting the robot's status (e.g., periodically sending "heartbeat" messages to indicate that the robot is still functioning) and downloading necessary versions of packages to be executed. Communication between the agent 206 and the conductor 212 is, in some embodiments, initiated by the agent 206. In an example notification scenario, the agent 206 may open a WebSocket channel that is later used by the conductor 212 to send commands (e.g., start, stop, etc.) to the robot.

[0029] As shown on the server side of this embodiment, the presentation layer includes web application 214, Open Data Protocol (OData) Representative State Transfer (REST) ​​application programming interface (API) endpoints 216, and notification and monitoring API 218. The server-side service layer includes API implementation / business logic 220. The server-side persistence layer includes database server 222 and indexer server 224. The conductor 212 includes web application 214, OData REST API endpoints 216, notification and monitoring API 218, and API implementation / business logic 220.

[0030] In various embodiments, most actions that a user performs in the conductor 212 interface (e.g., via browser 210) are performed by calling various APIs. Such operations may include, but are not limited to, launching jobs on robots, adding / removing data in a queue, scheduling jobs to run unattended, etc. Web application 214 is the visual layer of the server platform. In this embodiment, web application 214 uses Hypertext Markup Language (HTML) and JavaScript (JS). However, any desired markup language, scripting language, or any other format may be used without departing from the scope of the invention. A user interacts with web pages from web application 214, in this embodiment, via browser 210, to perform various operations to control conductor 212. For example, a user may create robot groups, assign packages to robots, analyze per-robot and / or per-process logs, start and stop robots, etc.

[0031] In addition to the web application 214, the conductor 212 also includes a services layer that exposes an OData REST API endpoint 216 (or other endpoints may be implemented without departing from the scope of the present invention). The REST API is consumed by both the web application 214 and the agent 206, which in this exemplary configuration is a supervisor of one or more robots on a client computer.

[0032] The REST API of the present embodiment covers configuration, logging, monitoring, and queuing functionality. The configuration REST endpoint may be used in some embodiments to define and configure users, permissions, robots, assets, releases, and environments of the application. The logging REST endpoint may be useful to log various information, such as errors, explicit messages sent by the robot, and other environment specific information. The deployment REST endpoint may be used by the robot to query the version of the package that should be executed when the start job command is used in the conductor 212. The queuing REST endpoint may be responsible for managing the queue and queue items, such as adding data to the queue, retrieving transactions from the queue, and setting the status of transactions. The monitoring REST endpoint monitors the web application 214 and the agent 206. The notification and monitoring API 218 may be a REST endpoint used to register the agent 206, deliver configuration settings to the agent 206, and send and receive notifications between the server and the agent 206. The notification and monitoring API 218 may use WebSocket communication in some embodiments.

[0033] The server-side persistence layer, in this exemplary embodiment, includes a pair of servers - a database server 222 (e.g., SQL Server) and an indexer server 224. The database server 222 in this embodiment stores configurations for robots, robot groups, associated processes, users, roles, schedules, etc. This information is managed, in some embodiments, via a web application 214. The database server 222 may also manage queues and queue items. In some embodiments, the database server 222 may store messages logged by the robots (in addition to the indexer server 224 or instead of the indexer server 250). Optional in some embodiments, the indexer server 224 stores and indexes information logged by the robots. In certain embodiments, the indexer server 224 may be disabled via a configuration setting. In some embodiments, the indexer server 224 uses ElasticSearch, a full-text search engine from an open source project. Messages logged by the robot (e.g., using activities such as log messages or line writes) may be sent via a logging REST endpoint(s) to the indexer server 224, where they are indexed for future use.

[0034] FIG. 3 is an architecture diagram illustrating an example of a simplified deployment of an RPA system 300 according to one or more embodiments. In some embodiments, the RPA system 300 may be or may include the RPA systems 100 and / or 200 of FIGS. 1 and 2, respectively. The RPA system 300 includes multiple client computing systems 302 that execute robots. The computing systems 302 may communicate with a conductor computing system 304 via web applications executed thereon. The conductor computing system 304, in turn, communicates with a database server 306 and an optional indexer server 308. With respect to FIGS. 2 and 3, it should be noted that although web applications are used in these embodiments, any suitable client / server software may be used without departing from the scope of the present invention. For example, the conductor may execute a server-side application on the client computing system that communicates with a non-web-based client software application.

[0035] In one embodiment, the RPA system 300 may be implemented for cloud-based management of RPA robots. Such cloud-based management of RPA robots allows RPA to be offered as Software as a Service (SaaS). Thus, the conductor 304 is implemented in the cloud for cloud-based management of RPA robots, for example, to create the RPA robots, provision the RPA robots, schedule tasks on the RPA robots, decommission the RPA robots, or perform any other orchestration tasks for managing the RPA robots.

[0036] FIG. 4 illustrates a network architecture 400 for implementing cloud-based management of RPA robots according to one or more embodiments. The network architecture 400 includes a cloud computing environment 402 and a local computing environment 404. The local computing environment 404 represents a local network architecture of a user or any other entity or entities (e.g., a business, a corporation, etc.). The local computing environment 404 includes a local network 406. The cloud computing environment 402 represents a cloud computing network architecture that provides services or processing of workloads remote from a user in the local computing environment 404. The cloud computing environment 402 includes various cloud networks including the Internet 414, a user cloud network 418 that represents a cloud network managed (or controlled) by a user and hosted by a cloud platform provider, and a cloud service provider cloud network 420 that represents a cloud network managed by a cloud service provider and hosted by a cloud platform provider. A cloud service provider is an entity that provides services (e.g., RPA) via a cloud. A cloud platform provider is an entity that maintains the infrastructure of cloud computing. The local network 406 of the local computing environment 404 is communicatively coupled to the Internet 414 of the cloud computing environment 402 to facilitate communications between the local computing environment 404 and the cloud computing environment 402 .

[0037] 4, cloud orchestrator 430 is implemented in cloud computing environment 402 and enables cloud-based management of RPA robots. In particular, cloud orchestrator 430 is managed by a cloud service provider and hosted in a cloud service provider cloud network 420 within cloud computing environment 402. In one embodiment, the cloud service provider offers RPA to users in local computing environment 404.

[0038] The cloud orchestrator 430 manages the RPA robot in the cloud computing environment 402. In particular, a user interacts with a computing device 412 in the local computing environment 404 to send instructions to the cloud orchestrator 430 in the cloud computing environment 402 to manage the RPA robot. Alternatively, a user interacts with a computing device 412 in the local computing environment 404 to schedule the cloud orchestrator 430 to automatically send instructions to manage the RPA robot on the user's behalf. Exemplary instructions for managing the RPA robot include instructions for creating an RPA robot, provisioning an RPA robot, scheduling a task on the RPA robot (e.g., scheduling a time to perform a task and a type of robot to perform the task), decommissioning an RPA robot, or any other orchestration instructions for an RPA robot. In response to receiving the instruction, the cloud orchestrator 430 executes the instruction by, for example, creating an RPA robot, provisioning an RPA robot, scheduling a task for the RPA robot, decommissioning an RPA robot, etc. In one embodiment, cloud orchestrator 430 also facilitates secure access control and manages robot licenses. In one embodiment, cloud orchestrator 430 may be similar to conductor 104 of Figure 1, conductor 212 of Figure 2, or conductor 304 of Figure 3, but is implemented within cloud service provider cloud network 420 in cloud computing environment 402.

[0039] The RPA robots managed by the cloud orchestrator 430 may include a pool of cloud robots deployed and maintained in the cloud computing environment 402. Such cloud robots may include one or more cloud service robots 428-A, ..., 428-X (hereafter referred to as cloud service robots 428) from a cloud service robot pool 426 and one or more cloud managed robots 424-A, ..., 424-Y (hereafter referred to as cloud managed robots 424) from a cloud managed robot pool 422. Such cloud robots execute (i.e., process) tasks in the cloud computing environment 402 and transmit the results of the tasks to a user in the local computing environment 404. Additionally or alternatively, the RPA robots managed by the cloud orchestrator 430 may include one or more local robots 410-A, ..., 410-Z (hereafter collectively referred to as local robots 410) from a local robot pool 408.

[0040] The cloud service robot 428 is maintained by the cloud service provider in the cloud service provider cloud network 420 to execute RPA tasks in the cloud computing environment 402 for a user in the local network environment 404. The cloud service robot 428 is created on demand by a user sending an instruction from the computing device 412 to the cloud orchestrator 430. Once created, the cloud service robot 428 goes into a standby mode while waiting to execute a task (or workflow). During the standby mode, the cost of operating the cloud service robot 428 is minimized or otherwise reduced. Tasks are scheduled on the cloud service robot 428 by a user sending an instruction from the computing device 412 to the cloud orchestrator 430. The task scheduling instruction defines the time to execute the task and the type of robot to execute the task. The cloud service robot 428 wakes up from the standby mode to execute the task and returns to the standby mode when the task is completed. Thus, the cloud service robot 428 executes tasks on the cloud service provider cloud network 420 for a user in the local computing environment 404.

[0041] The cloud service robot pool 426 is maintained by the cloud service provider in the cloud service provider cloud network 420 to include different types of cloud service robots. For example, the cloud service robot pool 426 may include standard robots or custom robots. Standard robots are defined by the user using standard machine templates to provide the robot with a standard set of predefined software. A standard robot can be, for example, a machine with only a standard browser used for web automation, a machine with an operating system installed to perform virtual desktop infrastructure (VDI) automation, a machine with standard applications to perform desktop automation, or a combination thereof. Custom robots are defined by the user using custom machine templates to provide the robot with a custom set of software. Custom machine templates can be uploaded by the user as machine images that the cloud service provider uses in creating custom robots. Custom machine images can include proprietary software owned by the user or specially licensed applications purchased by the user. Standard and custom robots are used to execute automations (processes) sent to the cloud orchestrator 430. The cloud orchestrator 430 waits for instructions to execute an automation, either a) directly via a manual invocation by a user, or b) via a previously scheduled periodic automation. When the cloud orchestrator 430 is ready to execute an automation, it inspects the type of process and identifies whether a standard or custom robot is required to execute that automation. Once the robot type is identified, the cloud orchestrator 430 inspects the available robot pool for that robot type to find an already running or available robot whose job is nearing completion.If a robot of that type is already running, the cloud orchestrator 430 utilizes it to avoid unnecessarily starting a new robot to minimize costs, and if there is no running robot, it starts a standby robot and sends the job request to it.

[0042] In one embodiment, algorithms may be applied to maximize utilization of robots in the cloud service robot pool 426 and reduce operating costs for users. The cloud orchestrator 430 looks ahead at future planned schedules of automations and optimizes plans of how to parallelize and queue automations so that they are executed on a minimum number of robots. Once a schedule is defined, the cloud orchestrator 430 will execute the automations using the schedule. Additionally, the cloud orchestrator 430 constantly monitors the state of running robots and modifies the planned schedule based on the actual execution of the robots. As a result, the utilization rate of running robots may be maximized and the cost of running additional robots may be reduced.

[0043] In one embodiment, the cloud services robot pool 426 may provide services to multiple users in a multi-tenant environment.

[0044] The cloud managed robot 424 is maintained by a user in a user cloud network 418 to perform RPA tasks in the cloud computing environment 402 for a user of the local network environment 404. The cloud managed robot 424 has similar functionality as the cloud service robot 428 and is also hosted in the cloud computing environment 402. However, the user cloud network 418 on which the cloud managed robot 424 is hosted is managed by the user, while the cloud service provider cloud network 420 on which the cloud service robot 428 is hosted is managed by the cloud service provider and hosted by the cloud platform provider. The cloud orchestrator 430 manages the cloud managed robot 424 by establishing a connection between the cloud service provider cloud network 420 and the user cloud network 418. The user cloud network 418 can be established by the user utilizing cloud provider technology to tunnel back to the local network 406. The user can establish a dedicated network connection from the local network 406 to the cloud service provider cloud network 420. The connections are typically in the form of, for example, any-to-any (e.g., Internet Protocol Virtual Private Network) networks, point-to-point Ethernet networks, or virtual cross-connections through a connectivity provider at a colocation facility. These connections do not traverse the public Internet. This allows for greater reliability, faster speeds, more consistent latency, and greater security than typical connections over the Internet. The user cloud network 418 remains fully controlled and managed by the user, thereby providing the user with tight control over their data.

[0045] Once a connection between the cloud service provider cloud network 420 and the user cloud network 418 is established, a cloud managed robot 424 is created in response to a request from a user interacting with the cloud orchestrator 430 via the computing device 412. The cloud managed robot 424 is created on the user cloud network 418. Thus, the cloud managed robot 424 executes tasks on the user cloud network 418 for the user in the local computing environment 404. Algorithms may be applied to maximize utilization of the robots in the cloud managed robot pool 422 and reduce the operating costs for the user.

[0046] The local robot 410 is maintained by the user in the local network 406 to perform RPA tasks for the user in the local network environment 404. The local network 406 is controlled or managed by the user. The cloud orchestrator 430 maintains a connection with the local robot 410 via a standard HTTPS connection. The local robot 410 is configured with a secure network key that the user extracts from the cloud orchestrator 430 user interface. Using that secure key, the local robot 410 reaches out to the cloud orchestrator 430 and establishes a secure connection. All traffic occurs as an outbound request from the local robot 410. This minimizes the need for inbound connections from the cloud to the local network 406, thereby improving security.

[0047] 5 illustrates a method 500 for cloud-based management of RPA robots in accordance with one or more embodiments. Method 500 is described with continued reference to network architecture 400 of FIG. 4. In one embodiment, steps of method 500 are performed by cloud orchestrator 430.

[0048] In step 502, instructions to manage an RPA robot are received at the orchestrator 430 of the cloud computing environment 402 from a user of the local computing environment 404. The instructions to manage an RPA robot may include, for example, instructions to create an RPA robot, provision an RPA robot, schedule tasks on an RPA robot, and / or decommission an RPA robot. The RPA robot may include a local robot 410, a cloud managed robot 424, or a cloud service robot 428. The cloud managed robot 424 and the cloud service robot 428 are for executing RPA tasks in the cloud computing environment and sending the results of the RPA tasks to a user in the local computing environment 404. While not executing tasks, the RPA robot is in a standby mode to reduce operating costs.

[0049] In response to receiving the instructions, instructions to manage the RPA robot are executed at step 504. In one embodiment, if the instructions to manage the RPA robot are instructions to create an RPA robot, the instructions are executed by creating the RPA robot for running on a cloud network 418 managed by a user in the cloud computing environment 402, by creating the RPA robot for running on a cloud network 420 managed by a cloud service provider (associated with cloud orchestrator 430) in the cloud computing environment 402, or by creating the RPA robot for running on a local network 406 managed by a user in the local computing environment 404.

[0050] Advantageously, embodiments of the present invention enable RPA as SaaS. Such SaaS RPA allows users to create and scale the number of robots on demand to automate tasks using the cloud, for example during peak usage times. Such SaaS RPA can lower the total cost of ownership for users by reducing the cost of running the cloud, simplify the network infrastructure required to implement RPA, and enable a secure cloud-based infrastructure for implementing RPA.

[0051] One exemplary application of an embodiment of the present invention will be described with reference to FIG. 4. An airline may utilize RPA robots for customer service to modify flight reservations. The airline provisions 10 RPA robots as local robots 410 on a local computing environment 404 that are sufficient to handle customer service under normal load. Occasionally, the airline will have an emergency, for example, a thunderstorm at one of its hubs that requires hundreds of planes to be grounded within a few hours, resulting in tens of thousands of customers being stranded at the airport and trying to reschedule their flights. The airport customer service representatives and the 10 RPA robots cannot handle this additional load. Advantageously, an embodiment of the present invention allows the airline to scale up the number of RPA robots as cloud service robots 428 to hundreds to help immediately provide service to stranded customers. The airline may scale up the number of RPA robots without having to manage infrastructure for additional RPA robots or provision RPA robots for peak capacity during normal operating hours. Additionally, airlines could reduce costs by only paying for additional RPA robots during peak usage.

[0052] Figure 6 is a block diagram illustrating a computing system 600 configured to perform the method described with reference to Figure 5 according to an embodiment of the present invention. In some embodiments, the computing system 600 may be one or more of the computing systems depicted and / or described herein, such as the conductor 104, the robot 106, the unattended robot 110, and the attended robot 108 of Figure 1, the conductor 212 of Figure 2, the robot 302 and the conductor 304 of Figure 3, and the local robot 410, the computing device 412, the cloud management robot 424, the cloud service robot 428, and the cloud orchestrator 430 of Figure 4. The computing system 600 includes a bus 602 or other communication mechanism for communicating information and a processor(s) 604 coupled to the bus 602 for processing information. The processor(s) 604 may be any type of general or application-specific processor, including a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a graphics processing unit (GPU), multiple instances thereof, and / or any combination thereof. The processor(s) 604 may also have multiple processing cores, at least some of which may be configured to perform specific functions. In some embodiments, multiple parallel processing may be used.

[0053] The computing system 600 further includes a memory 606 for storing information and instructions executed by the processor(s) 604. The memory 606 may be comprised of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage devices such as magnetic or optical disks, or other types of non-transitory computer-readable media, or any combination thereof. The non-transitory computer-readable media may be any available media accessible by the processor(s) 604 and may include volatile media, non-volatile media, or both. Additionally, the media may be removable, non-removable, or both.

[0054] Additionally, the computing system 600 includes a communications device 608, such as a transceiver, to provide access to communications networks via wireless and / or wired connections according to currently existing or future implemented communications standards and / or protocols.

[0055] The processor(s) 604 are further coupled via bus 602 to a display 610 suitable for displaying information to a user. The display 610 may also be configured as a touch display and / or any suitable tactile I / O device.

[0056] A keyboard 612 and cursor control device 614, such as a computer mouse, touchpad, and the like, are further coupled to the bus 602 to allow a user to interface with the computing system. However, in certain embodiments, a physical keyboard and mouse may not be present and the user may interact with the device solely through the display 610 and / or touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In certain embodiments, no physical input devices and / or displays are present. For example, a user may interact with computing system 600 remotely via another computing system in communication with computing system 600, or computing system 600 may operate autonomously.

[0057] The memory 606 stores software modules that provide functionality when executed by the processor(s) 604. The modules include an operating system 616 for the computing system 600 and one or more additional functionality modules 618 configured to perform all or a portion of the processes described herein, or derivatives thereof.

[0058] Those skilled in the art will appreciate that the "system" may be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the functions described above as being performed by a "system" is not intended to limit the scope of the present invention in any way, but rather to provide an example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technologies, including cloud computing systems.

[0059] It should be noted that some of the system features described herein are presented as modules to better emphasize implementation independence. For example, the modules may be implemented as hardware circuits including custom Very Large Scale Integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Also, the modules may be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like. The modules may also be implemented at least in part in software for execution by various types of processors. For example, an identified unit of executable code may include one or more physical or logical blocks of computer instructions that may be organized as, for example, an object, procedure, or function. Nevertheless, executable identified modules need not be physically located together, but may include separate instructions stored in different locations that, when logically combined, comprise the modules and accomplish the purpose stated for the modules. Furthermore, the modules may be stored on a computer readable medium such as, for example, a hard disk drive, a flash device, a RAM, a tape, and / or any other non-transitory computer readable medium used to store data without departing from the scope of the present invention. Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within a module, and may be embodied and organized in any suitable form within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed in different locations across different storage devices, or may exist, at least in part, simply as electronic signals on a system or network.

[0060] The foregoing merely illustrates the principles of the disclosure. Thus, it will be understood that those skilled in the art can devise various arrangements that embody the principles of the disclosure and are included within its spirit and scope, although not expressly described or shown herein. Furthermore, all examples and conditional language cited herein are intended primarily for educational purposes only to aid the reader in understanding the principles of the disclosure and the concepts that the inventors have contributed to the development of the technology, and should be construed as not being limited to such specifically cited examples and conditions. Furthermore, all statements herein that refer to the principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass their structural and functional equivalents. Furthermore, such equivalents are intended to include not only currently known equivalents, but also equivalents developed in the future.

Claims

1. A method for managing a robotic process automation (RPA) robot, comprising: receiving, at an orchestrator in a provider cloud network, instructions from a computing device in a local computing environment using a connection established between the provider cloud network and the local computing environment via a user cloud network; and executing, by the orchestrator, in response to receiving the instructions, the instructions for managing the RPA robot.

2. 2. The computer-implemented method of claim 1, wherein the instructions for managing the RPA robot include one or more instructions for creating the RPA robot, provisioning the RPA robot, scheduling tasks on the RPA robot, or decommissioning the RPA robot.

3. The instructions for managing the RPA robot include instructions for creating the RPA robot, and executing the instructions for managing the RPA robot 2. The computer-implemented method of claim 1, further comprising creating the RPA robot in a user cloud network, the user cloud network being managed by a user.

4. The instructions for managing the RPA robot include instructions for creating the RPA robot, and executing the instructions for managing the RPA robot 2. The computer-implemented method of claim 1, further comprising creating the RPA robot in a provider cloud network, the provider cloud network being managed by a cloud service provider.

5. Performing a task performed by the RPA robot in at least one of the provider cloud network or the user cloud network; 2. The computer-implemented method of claim 1, further comprising: transmitting results of the task from the RPA robot performing in at least one of the provider cloud network or the user cloud network to the computing device.

6. 2. The computer-implemented method of claim 1, wherein the RPA robot is in a standby mode to reduce operating costs when the RPA robot is not performing a task.

7. A processor; Memory, a cloud robot pool including one or more robotic process automation (RPA) robots; 1. A cloud orchestrator operating on a provider cloud network, comprising: receiving instructions from a computing device of a local computing environment using a connection established between the provider cloud network and the local computing environment via a user cloud network for managing the cloud robot pool; a cloud orchestrator configured to, in response to receiving the instructions, execute the instructions to manage the cloud robot pool.

8. 8. The cloud computing environment of claim 7, wherein the instructions for managing the cloud robot pool include one or more instructions for creating the one or more RPA robots, provisioning the one or more RPA robots, scheduling tasks for the one or more RPA robots, or decommissioning the one or more RPA robots.

9. The instructions for managing the cloud robot pool include instructions for creating the one or more RPA robots, and executing the instructions for managing the cloud robot pool comprises:

8. The cloud computing environment of claim 7, further comprising creating the one or more RPA robots in a user cloud network, the user cloud network being managed by a user.

10. The instructions for managing the cloud robot pool include instructions for creating the one or more RPA robots, and executing the instructions for managing the cloud robot pool comprises:

8. The cloud computing environment of claim 7, further comprising creating the one or more RPA robots in a provider cloud network, the provider cloud network being managed by a cloud service provider.

11. The one or more RPA robots, Performing tasks in at least one of the provider cloud network or the user cloud network; The cloud computing environment of claim 7 , configured to transmit results of the task to the computing device.

12. 8. The cloud computing environment of claim 7, wherein the one or more cloud RPA robots are in a standby mode to reduce operating costs when the one or more cloud RPA robots are not performing tasks.

13. Maintaining a cloud robot pool including one or more robotic process automation (RPA) robots; and managing the cloud robot pool using a cloud orchestrator implemented in a provider cloud network, the cloud orchestrator comprising: receiving instructions from a computing device of a local computing environment using a connection established between the provider cloud network and the local computing environment via a user cloud network for managing the cloud robot pool; In response to receiving the instructions, a computer-implemented method executes the instructions to manage the cloud robot pool.

14. 14. The computer-implemented method of claim 13, wherein the instructions include one or more of: creating the one or more RPA robots, provisioning the one or more RPA robots, scheduling tasks for the one or more RPA robots, or decommissioning the one or more RPA robots.

15. The computer-implemented method of claim 13, wherein the instructions for managing the one or more RPA robots include instructions for creating the one or more RPA robots, and executing the instructions for managing the cloud robot pool includes creating the one or more RPA robots in the user cloud network, the user cloud network being managed by a user.

16. The computer-implemented method of claim 13, wherein the instructions for managing the one or more RPA robots include instructions for creating the one or more RPA robots, and executing the instructions for managing the cloud robot pool includes creating the one or more RPA robots in the provider cloud network, the provider cloud network being managed by a cloud service provider.

17. The one or more RPA robots, Performing tasks in at least one of the provider cloud network or the user cloud network; The computer-implemented method of claim 13 , configured to transmit results of the task to the computing device.

18. 14. The computer-implemented method of claim 13, wherein when the one or more cloud RPA robots are not performing tasks, the one or more cloud RPA robots are in a standby mode to reduce operating costs.

Images