Bring Your Own Machine (BYOM)

Abstract

A method and / or apparatus for creating and / or editing a machine pool with bring your own machine (BYOM) includes creating and / or editing a machine pool with a static list of machines. A user-inputted machine list and an existing machine list are searched and the user-inputted machine list and the existing machine list are compared to identify one or more changes between the user-inputted machine list and the existing machine list. A new machine specification is then created if one or more changes between the user-inputted machine list and the existing machine list are identified. One or more machines are then moved to the new machine specification.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Patent Application No. 17 / 233,454, filed April 17, 2021. The subject matter of this prior application is incorporated herein by reference in its entirety.

[0002] The present invention relates generally to robotic process automation (RPA), and more particularly to incorporating BYOM into RPA. [Background technology]

[0003] Prior to cloud robotics, customers manually configured physical machines and deployed robots to connect their computing systems (e.g., virtual machines) to UiPath® Orchestrator™. To connect a computing system to UiPath® Orchestrator™, a license key was provided to the user who prepared the computing system. This license key was typically transferred via email, short messaging system (SMS), Slack®, and telephone, to name a few. The method of passing this license key was insecure, and the channel, i.e., the means by which the license key was passed, was also insecure.

[0004] Therefore, an improved method for securely connecting cloud robots to Orchestrator™ would be beneficial. Summary of the Invention

[0005] Certain embodiments of the present invention may provide solutions to problems and needs in the art that have not yet been fully identified, recognized, or solved by current cloud robotics technology. For example, some embodiments of the present invention relate to connecting cloud robots to a BYOM model.

[0006] In one embodiment, a computer-implemented method for creating and / or editing a machine pool through Bring Your Own Machine (BYOM) includes creating and / or editing a machine pool with a static list of machines. The method also includes searching a user-inputted machine list and an existing machine list and comparing the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list. The method further includes creating a new machine specification if the one or more changes between the user-inputted machine list and the existing machine list are identified. The method also includes moving or importing one or more machines into the new machine specification.

[0007] In another embodiment, a computer program is embodied on a non-transitory computer-readable medium. The computer program is configured to cause one or more processors to create and / or edit a machine pool through Bring Your Own Machine (BYOM). The computer program is further configured to cause the one or more processors to create and / or edit a machine pool using a static list of machines. The computer program is further configured to cause the one or more processors to search a user-inputted machine list and an existing machine list and compare the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list. The computer program is further configured to cause the one or more processors to create a new machine specification if one or more changes between the user-inputted machine list and the existing machine list are identified. The computer program is further configured to cause the one or more processors to move or import one or more machines to the new machine specification.

[0008] In yet another embodiment, a system for creating and / or editing a machine pool through Bring Your Own Machine (BYOM) includes a memory configured to store one or more computer-executable instructions and one or more processors configured to execute the one or more instructions to create and / or edit a machine pool using a static list of machines. The one or more processors are further configured to execute the one or more instructions to perform the steps of searching a user-inputted machine list and an existing machine list and comparing the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list. The one or more processors are further configured to execute the one or more instructions to perform the steps of creating a new machine specification if one or more changes between the user-inputted machine list and the existing machine list are identified. The one or more processors are further configured to execute the one or more instructions to perform the steps of moving or importing one or more machines to the new machine specification. [Brief explanation of the drawings]

[0009] So that the advantages of particular embodiments of the present invention may be readily understood, a more particular description of the invention, briefly described above, will be rendered by reference to specific embodiments that are illustrated in the accompanying drawings. It being understood that these drawings depict only typical embodiments of the invention and therefore should not be considered limiting of its scope, but the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings.

[0010] [Figure 1] FIG. 1 is an architectural diagram illustrating an RPA system, according to one embodiment of the present invention.

[0011] [Figure 2]FIG. 1 is an architectural diagram illustrating a deployed RPA system according to one embodiment of the present invention.

[0012] [Figure 3] FIG. 2 is an architecture diagram illustrating the relationships between designers, activities, and drivers according to one embodiment of the present invention.

[0013] [Figure 4] FIG. 1 is an architectural diagram illustrating an RPA system, according to one embodiment of the present invention.

[0014] [Figure 5] FIG. 1 is an architectural diagram illustrating a computing system configured to deploy cloud robots within a BYOM, according to one embodiment of the present invention.

[0015] [Figure 6] FIG. 1 is a flow diagram illustrating a method for creating and / or editing a machine pool, according to one embodiment of the present invention.

[0016] [Figure 7] FIG. 1 is a flow diagram illustrating a method for rotating license keys according to one embodiment of the present invention.

[0017] [Figure 8] FIG. 2 is a flow diagram illustrating a method for adding a machine to a machine pool according to one embodiment of the present invention.

[0018] [Figure 9] FIG. 2 is a flow diagram illustrating a method for removing a machine from a machine pool, according to one embodiment of the present invention.

[0019] [Figure 10] 9 is a flow diagram illustrating a method 900 for Bring Your Own Machine (BYOM), according to one embodiment of the present invention.

[0020] [Figure 11] FIG. 2 illustrates a graphical user interface (GUI) through which a user creates a virtual machine, according to one embodiment of the present invention.

[0021] [Figure 12] FIG. 10 illustrates a GUI showing cloud provider connections according to one embodiment of the present invention.

[0022] [Figure 13] FIG. 10 illustrates a GUI illustrating adding a cloud machine pool, according to one embodiment of the present invention.

[0023] [Figure 14] FIG. 10 illustrates a GUI showing the configuration of a current folder according to one embodiment of the present invention.

[0024] [Figure 15] FIG. 10 illustrates a GUI showing the management of machines in a folder according to one embodiment of the present invention.

[0025] [Figure 16] FIG. 10 illustrates a GUI showing the execution of a job according to one embodiment of the present invention.

[0026] [Figure 17] FIG. 1 illustrates a flow for creating / editing machine pools and rotating license keys according to one embodiment of the present invention.

[0027] [Figure 18] FIG. 2 illustrates an architectural relationship between a hypervisor and an orchestrator entity, according to one embodiment of the present invention.

[0028] [Figure 19] FIG. 2 is a relationship diagram illustrating a machine statement machine according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0029] Some embodiments relate to a feature added to Cloud Robotics, Bring Your Own Machine (BYOM). For example, customers can port their subscription credentials and enable infrastructure changes within their subscriptions that incorporate Cloud Robotics schedules into their subscriptions.

[0030] However, note that there may be issues when making these infrastructure changes in a customer's subscription. For example, a machine may require a lot of customization, i.e., the machine may require a virtual private network (VPN) connection to communicate with the database. Another example may be a requirement that extensions be installed.

[0031] Based on these customization needs of BYOM, cloud robots customized to address these needs are installed and / or deployed.

[0032] Another problem being solved is allowing customers to get special access to their own network. This leverages the existing Cloud Robotics scenario, where machines are automatically created and scaled. However, some customers may have unique machine configurations and may not be interested in creating and scaling machines.

[0033] To address this issue, customers create machines and then provide the cloud robot developer with a unique machine configuration. The cloud robot developer can then optimize cloud cost usage for the unique machine configuration (or each machine). In this way, when a new job is received, the cloud robot developer starts the machine, and when the machine is no longer needed, the machine is turned off.

[0034] Continuing with this example, let's say a customer creates 10 machines. In this example, instead of leaving the 10 machines on and paying Azure™ or AWS™ costs, the cloud robot developer turns on one or more of the machines when needed and turns off one or more when they are not needed. With BYOM, the same kind of cloud robot goodness of autoscaling or performance optimization can be achieved. In other words, the goodness of cloud robots is brought to a custom-built BYOM.

[0035] In some embodiments, a customer can create multiple virtual machines (VMs) in the cloud, and these VMs can participate in the RPA ecosystem. For example, a customer can provide one or more VMs in the cloud, and robots can be installed on one or more VMs. These robots can automatically connect the VMs to the RPA environment and can be automatically turned on or off.

[0036] FIG. 1 is an architectural diagram illustrating an RPA system 100 according to one embodiment of the present invention. The RPA system 100 includes a designer 110 that enables developers to design and implement workflows. The designer 110 can provide application integration and solutions for automating third-party applications, management information technology (IT) tasks, and business IT processes. The designer 110 can facilitate the development of automation projects, which are graphical representations of business processes. Simply put, the designer 110 facilitates the development and deployment of workflows and robots.

[0037] Automation projects enable rule-based process automation by giving developers control over the order of execution and relationships between custom sets of steps developed in a workflow, defined herein as "activities." One commercial example of an embodiment of the designer 110 is UiPath Studio™. Each activity can include actions such as clicking a button, reading a file, writing to a log panel, etc. In some embodiments, workflows may be nested or embedded.

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

[0039] Once a workflow is developed in Designer 110, the execution of the business process is orchestrated by Conductor 120, which orchestrates one or more Robots 130 that execute the workflow developed in Designer 110. One commercial example of an embodiment of Conductor 120 is UiPath Orchestrator™. Conductor 120 facilitates the creation, monitoring, and management of deployment of resources in the environment. Conductor 120 can serve as an integration point with third-party solutions and applications.

[0040] The conductor 120 can manage all robots 130, connecting and executing them from a centralized point. Types of robots 130 that can be managed include, but are not limited to, attended robots 132, unattended robots 134, development robots (similar to unattended robots 134 but used for development and testing purposes), and non-production robots (similar to attended robots 132 but used for development and testing purposes). Attended robots 132 are triggered by user events and operate alongside humans on the same computing system. Attended robots 132 can be used with the conductor 120 for centralized process deployment and recording. Attended robots 132 can help human users accomplish various tasks and can be triggered by user events. In some embodiments, processes cannot be started from the conductor 120 for this type of robot and / or cannot run under a locked screen. In certain embodiments, attended robots 132 can only be launched from the robot tray or command prompt. In some embodiments, the attended robot 132 should operate under human supervision.

[0041] Unattended robots 134 operate unattended in virtual environments and can automate many processes. Unattended robots 134 can be responsible for providing remote execution, monitoring, scheduling, and work queue support. In some embodiments, debugging of all robot types can be performed in designer 110. Both attended and unattended robots can automate a variety of systems and applications, including, but not limited to, mainframes, web applications, VMs, enterprise applications (e.g., those manufactured by SAP®, Salesforce®, Oracle®, etc.), and computing system applications (e.g., desktop and laptop applications, mobile device applications, wearable computer applications, etc.).

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

[0043] Robots 130 are execution agents that execute workflows built in designer 110. One commercial example of some embodiments of robots 130 is UiPath Robots™. In some embodiments, robots 130 install the Microsoft Windows Service Control Manager (SCM) management service by default. As a result, such robots 130 can open interactive Windows sessions under the local system account and have the rights of a Windows service.

[0044] In some embodiments, a robot 130 can be installed in user mode. For such a robot 130, this means that a given robot 130 has the same rights as the user to which it is installed. This feature may also be available for high-density (HD) robots, ensuring full utilization of each machine to its maximum potential. In some embodiments, any type of robot 130 can be configured in an HD environment.

[0045] In some embodiments, the robot 130 is divided into several components, each dedicated to a specific automation task. In some embodiments, the robot components 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 Windows sessions and acts as a proxy between the conductor 120 and the execution host (i.e., the computing system on which the robot 130 executes). These services are trusted with and manage the credentials of the robot 130. A console application is launched by the SCM under Local System.

[0046] The user-mode robot service in some embodiments manages and monitors Windows sessions and acts as a proxy between the conductor 120 and the execution host. The user-mode robot service can trust and manage credentials for the robot 130. If the SCM management robot service is not installed, the Windows application can be launched automatically.

[0047] An Executor can run a given job under a Windows session (i.e., an Executor can execute a workflow). An Executor can be aware of per-monitor dots per inch (DPI) settings. 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 request to start or stop a job and change settings. A Command Line is a client of a Service. A Command Line is a console application that can request the start of a job and wait for its output.

[0048] Dividing the robot 130 components as described above helps developers, support users, and computing systems more easily implement, identify, and track what each component is doing. In this way, special behaviors can be configured per component, such as setting different firewall rules for executors and services. Executors, in some embodiments, can always be aware of DPI settings per monitor. As a result, workflows can be executed at any DPI, regardless of the configuration of the computing system on which they were created. In some embodiments, projects from the designer 110 may be independent of the browser zoom level. For applications that are not DPI-aware or are intentionally marked as not-aware, DPI can be disabled in some embodiments.

[0049] FIG. 2 is an architecture diagram illustrating a deployed RPA system 200 according to one embodiment of the present invention. In some embodiments, the RPA system 200 may be or be part of the RPA system 100 of FIG. 1. Note 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. On the client side, the robot application 210 includes an executor 212, an agent 214, and a designer 216. However, in some embodiments, the designer 216 may not be running on the computing system 210. The executor 212 is a running process. As shown in FIG. 2, several business projects may run simultaneously. The agent 214 (e.g., a Windows service) is a single connection point for all executors 212 in this embodiment. All messages in this embodiment are logged to the conductor 230, which further processes them via the database server 240, the indexer server 250, or both. As discussed above with respect to FIG. 1, the executor 212 may be a robotic component.

[0050] In some embodiments, a robot represents an association between a machine name and a username. A robot can manage multiple executors simultaneously. In computing systems that support multiple interactive sessions running simultaneously (e.g., Windows Server 2012), multiple robots may run simultaneously, each running in a separate Windows session using a unique username. This is referred to above as an HD robot.

[0051] The agent 214 is also responsible for transmitting the robot's status (e.g., periodically sending "heartbeat" messages indicating that the robot is still functioning) and downloading necessary versions of packages to be fulfilled. Communication between the agent 214 and the conductor 230 is always initiated by the agent 214 in some embodiments. In notification scenarios, the agent 214 can open a WebSocket channel that is later used by the conductor 230 to send commands (e.g., start, stop, etc.) to the robot.

[0052] The server side includes a presentation layer (web application 232, Open Data Protocol (OData) Representational State Transfer (REST) ​​Application Programming Interface (API) endpoint 234, and Notifications and Monitoring 236), a service layer (API implementation / business logic 238), and a persistence layer (database server 240, indexer server 250). Conductor 230 includes web application 232, OData REST API endpoint 234, Notifications and Monitoring 236, and API implementation / business logic 238. In some embodiments, most actions a user performs within the conductor 230 interface (e.g., via browser 220) are performed by calling various APIs. Such actions may include, but are not limited to, starting a job on a robot, adding / removing data from a queue, scheduling a job for unattended execution, etc., without departing from the scope of the present invention. Web application 232 is the visual layer of the server platform. In this embodiment, web application 232 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 present invention. A user interacts with web pages from web application 232, in this embodiment via browser 220, to perform various actions to control conductor 230. For example, a user can create robot groups, assign packages to robots, analyze logs per robot and / or per process, start and stop robots, etc.

[0053] In addition to the web application 232, the conductor 230 also includes a services layer that exposes an OData REST API endpoint 234. However, other endpoints may be included without departing from the scope of the present invention. The REST API is consumed by both the web application 232 and the agent 214, which in this embodiment is the administrator of one or more robots on a client computer.

[0054] The REST API in this embodiment covers configuration, logging, monitoring, and queuing functions. The configuration endpoint, in some embodiments, may be used to define and configure application users, permissions, robots, assets, releases, and environments. For example, a logging REST endpoint may be used to log various information such as errors, explicit messages sent by robots, and other environment-specific information. A deployment REST endpoint may be used by robots to query the package version that should be committed when a start job command is used within conductor 230. The queuing REST endpoint may be responsible for queue and queue item management, such as adding data to a queue, retrieving transactions from a queue, and setting the state of transactions.

[0055] Monitoring REST endpoints can monitor web applications 232 and agents 214. Notification monitoring API 236 may be a REST endpoint used to register agents 214, deliver configuration settings to agents 214, and send / receive notifications from the server and agents 214. Notification monitoring API 236 may also use WebSocket communication in some embodiments.

[0056] The persistence layer includes a pair of servers in this embodiment: database server 240 (e.g., SQL Server) and indexer server 250. Database server 240 in this embodiment stores configurations for robots, robot groups, associated processes, users, roles, schedules, etc. This information is managed in some embodiments via web application 232. Database server 240 can manage queues and queue items. In some embodiments, database server 240 can store messages logged by robots (in addition to or instead of indexer server 250).

[0057] Indexer server 250, which is optional in some embodiments, stores and indexes information logged by the robots. In certain embodiments, indexer server 250 can be disabled through a configuration setting. In some embodiments, indexer server 250 uses ElasticSearch®, a full-text search engine from an open source project. Messages logged by robots (e.g., using activities such as log messages or line writes) may be sent via a logging REST endpoint to indexer server 250, where they are indexed for future use.

[0058] FIG. 3 is an architecture diagram illustrating the relationship 300 between a designer 310, activities 320 and 330, a driver 340, and an AI / ML model 350, according to one embodiment of the present invention. Accordingly, a developer uses the designer 310 to develop a workflow to be performed by the robot. The workflow can include a user-defined activity 320 and a UI automation activity 330. The user-defined activity 320 and / or the UI automation activity 330, in some embodiments, can invoke one or more AI / ML models 350, which can be located locally and / or remotely to the computing system on which the robot is operating. Some embodiments can identify non-textual visual components within an image, referred to herein as computer vision (CV). Some CV activities related to such components may include, but are not limited to, click, type, get text, hover, element presence, refresh range, highlight, etc. In some embodiments, click identifies an element and clicks on it, for example, using CV, optical character recognition (OCR), fuzzy character matching, and multi-anchors. Type can identify an element using the above and types within elements. Text can be acquired and the location of specific text can be identified using OCR and then scanned. Hover can identify an element and hover over it. Element Presence can check whether an element is present on the screen using the techniques described above. In some embodiments, there may be hundreds or thousands of activities implemented in designer 310. However, any number and / or type of activities may be utilized without departing from the scope of the present invention.

[0059] UI automation activities 330 are a subset of specialized, low-level activities written in lower-level code (e.g., CV activities) that facilitate interactions with the screen. UI automation activities 330 facilitate these interactions via drivers 340 and / or AI / ML models 350 that enable the robot to interact with desired software. For example, drivers 340 may include OS drivers 342, browser drivers 344, VM ​​drivers 346, enterprise application drivers 348, etc. One or more of the AI / ML models 350 may be used by UI automation activities 330 to determine the execution of interactions with the computing system. In some embodiments, AI / ML models 350 may augment drivers 340 or replace them entirely. Indeed, in certain embodiments, drivers 340 are not included.

[0060] Drivers 340 can interact with the OS at a low level by looking for hooks, monitoring keys, etc. They can facilitate integration with Chrome®, IE®, Citrix®, SAP®, etc. For example, a "click" activity performs the same role in these different applications via drivers 340.

[0061] FIG. 4 is an architecture diagram illustrating an RPA system 400, according to one embodiment of the present invention. In some embodiments, RPA system 400 can be or include RPA systems 100 and / or 200 of FIGS. 1 and / or 2. RPA system 400 includes multiple client computing systems 410 that execute robots. Computing systems 410 can communicate with a conductor computing system 420 via web applications running thereon. Conductor computing system 420 can, in turn, communicate with a database server 430 and an optional indexer server 440.

[0062] 1 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 run a server-side application that communicates with a non-web-based client software application on a client computing system.

[0063] FIG. 5 is an architectural diagram illustrating a computing system 500 configured to deploy cloud robots to a BYOM, according to one embodiment of the present invention. In some embodiments, computing system 500 may be one or more of the computing systems illustrated and / or described herein. Computing system 500 includes a bus 505 or other communication mechanism for communicating information and a processor 510 coupled to bus 505 for processing information. Processor 510 may be any type of general-purpose or special-purpose 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. Processor 510 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. In certain embodiments, at least one of processors 510 may be a neuromorphic circuit including processing elements that mimic biological neurons. In some embodiments, the neuromorphic circuit may not require the typical components of a von Neumann computing architecture.

[0064] The computing system 500 further includes a memory 515 for storing information and instructions executed by the processor 510. The memory 515 may be comprised of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other type of non-transitory computer-readable medium, or a combination thereof. The non-transitory computer-readable medium may be any available medium that can be accessed by the processor 510 and may include volatile media, non-volatile media, or both. The medium may also be removable, non-removable, or both.

[0065] Additionally, the computing system 500 includes a communications device 520, such as a transceiver, for providing access to a communications network via wireless and / or wired connections. In some embodiments, the communications device 520 may be configured to support a variety of communications technologies, including Frequency Division Multiple Access (FDMA), Single Carrier FDMA (SC-FDMA), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), cdma2000, Wideband CDMA (W-CDMA), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), High Speed ​​Packet Access (HSPA), and the like. The communication device 520 may be configured to use any of the following communication standards and / or protocols: High-Speed ​​Access (HSPA), Long Term Evolution (LTE), LTE-Advanced (LTE-A), 802.11x, Wi-Fi, Zigbee, Ultra Wideband (UWB), 802.16x, 802.15, Home Node B (HnB), Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Near Field Communications (NFC), Fifth Generation (5G), New Radio (NR), any combination thereof, and / or any other currently existing or future implemented communication standards and / or protocols without departing from the scope of the present invention. In some embodiments, the communication device 520 may include one or more antennas that are single, array, phased, switched, beamforming, beamsteering, combinations thereof, and / or any other antenna configuration without departing from the scope of the present invention.

[0066] The processor 510 is further coupled via bus 505 to a display 525, such as a plasma display, a liquid crystal display (LCD), a light emitting diode (LED) display, a field emission display (FED), an organic light emitting diode (OLED) display, a flexible OLED display, a flexible substrate display, a projection display, a 4K display, a high definition display, a Retina® display, an in-plane switching (IPS) display, or any other suitable display for displaying information to a user. The display 525 may be configured as a touch (tactile) display, a three-dimensional (3D) touch display, a multi-input touch display, a multi-touch display, etc., using resistive, capacitive, surface acoustic wave (SAW) capacitive, infrared, optical imaging, dispersive signal technology, acoustic pulse recognition, frustrated total internal reflection, etc. Any suitable display device and tactile I / O may be used without departing from the scope of the invention.

[0067] A keyboard 530 and cursor control device 535, such as a computer mouse, touchpad, etc., are further coupled to bus 505 to allow a user to interface with computing system 500. However, in certain embodiments, a physical keyboard and mouse may not be present, and a user may interact with the device solely through display 525 and / or a 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 500 remotely via another computing system that communicates with it, or computing system 500 may operate autonomously.

[0068] The memory 515 stores software modules that provide functionality when executed by the processor 510. The modules include an operating system 540 for the computing system 500. The modules further include a BYOM module 545 configured to perform all or a portion of the processes described herein or derivatives thereof. The computing system 500 may include one or more additional functional modules 550 that include additional functionality.

[0069] Those skilled in the art will understand that a "system" may be embodied as a server, embedded computing system, personal computer, console, personal digital assistant (PDA), mobile phone, tablet computing device, quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present invention in any way, but rather to provide one example of many embodiments of the present invention. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technologies, including cloud computing systems. The computing system may be part of or accessible by a local area network (LAN), a mobile communications network, a satellite communications network, the Internet, a public or private cloud, a hybrid cloud, a server farm, any combination thereof, or the like. Any localized or distributed architecture may be used without departing from the scope of the present invention.

[0070] It should be noted that some of the system features described herein are presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0071] Modules may also be implemented, at least in part, in software for execution by various types of processors. An identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. Nevertheless, the executable files of identified modules need not be physically located together, but may comprise different instructions stored in different locations that, when logically combined together, comprise the module and achieve the module's stated purpose. Furthermore, modules may be stored on computer-readable media, which may be, for example, a hard disk drive, a flash device, RAM, tape, and / or any other such non-transitory computer-readable medium used to store data without departing from the scope of the present invention.

[0072] Indeed, a module of executable code may be a single instruction, or many instructions, and may be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data may be identified and illustrated herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or distributed in different locations, including different storage devices, and may exist, at least in part, solely as electronic signals on a system or network.

[0073] FIG. 6 is a flow diagram illustrating a method 600 for creating and / or editing a machine pool according to one embodiment of the present invention. Method 600 can begin at 605 with creating and / or editing a machine pool having a static list of machines. A machine pool (or cloud machine pool) can be defined as a configuration of machines, such as cloud connectivity, cloud scope (e.g., resource group in Azure™, region in AWS™), and machine parameters (e.g., image, size, VNet, etc.). At 610, a user-input machine list (UL) and an existing machine list (EL) are retrieved. In some embodiments, the user-input machine list and the existing machine list are retrieved from a user in BYOM. The user-input machine list may be defined as a desired state of a static list of cloud machine identifiers, and the existing machine list may be defined as a current state of a static list of cloud machine identifiers. The user-input machine list can include a unique identifier for each machine listed therein. Similarly, the existing machine list can include a unique identifier for each machine listed therein. The unique identifiers help avoid double-booking scenarios for customers. For example, a customer may use a cloud machine in two different BYOM machine pools at the same time, and a unique identifier may identify the same machine being used in the two different BYOM machine pools, and a determination may be made as to whether the same machine can be used by the second BYOM machine pool.

[0074] At 615, the user-inputted machine list and the existing machines are compared to determine whether the user-inputted machine list includes modifications to the existing machine list. In some embodiments, this comparison identifies one or more unique identifiers for any machines not listed in the existing machine list. In another embodiment, the user-inputted machine list and the existing machines are merged together to identify one or more unique identifiers for any machines not listed in the existing machine list.

[0075] If the user-inputted machine list and the existing machine list are identical, then the existing machine specification for each machine identified in the existing machine list is used at 620. If the user-inputted machine list and the existing machine list are different, then a new machine specification is created at 625.

[0076] In some embodiments, a new machine specification may be defined as a version of a machine pool and is immutable. For example, there may be an underlying semantic when a new machine specification is created. Specifically, when a new machine specification is created, a license key associated with the new machine specification must be found. This license key is a tool that allows a user (or machine) to reconnect to the UiPath® ecosystem (e.g., Orchestrator™). Note that a machine can belong to a machine specification, and the machine specification holds the license key that is shared by all machines when connected to the ecosystem.

[0077] A BYOM cloud machine pool can have multiple machines, and those machines can share the same license key to connect to Orchestrator™. The license key essentially indicates the amount of runtime allocated, as well as other information such as the number of endpoints in Orchestrator™. When a pool edit occurs, a change is introduced that invalidates some of the connected machines. A change can be defined as editing a machine's site, changing its resource group, etc. This is when the shared license key is rotated. For example, the rotation effectively acts to disconnect invalid connected machines, and as a side effect, other connected machines are also disabled. This causes the license key used by those machines to be rotated.

[0078] 7 is a flow diagram illustrating a method 700 for rotating a license key when a new machine specification is created, according to one embodiment of the present invention. In some embodiments, method 700 can begin with Orchestrator™ detecting at 705 that a machine needs to be rotated from the machine pool. For example, Orchestrator™ can detect that a machine's license key has expired. This can occur when a new specification is created (see below). Using the expired license key at 710, Orchestrator™ stops allocating new jobs to the machine and moves the machine to a probation state at 715. For purposes of illustration, when a machine is in a probation state, existing running jobs (if any) continue their execution, but no further jobs can be allocated to this machine.

[0079] At 720, once the machine has completed one or more remaining jobs (if any), Orchestrator™ deletes the machine or removes it from the machine pool. At 725, Orchestrator™ provisions a new machine based on the new machine specifications and assigns a new license key to the new provisioned machine at 730. In some alternative embodiments, the same machine can be provisioned and assigned a new license key. See discussion below.

[0080] A new license key is randomly generated and verified by Orchestrator™ for each version in the machine pool and notified, for example, to the hypervisor. In one example, Orchestrator™ can generate a new license key every time a license key rotation is required. In another example, Orchestrator™ can generate a new license before a license key rotation. Note that Orchestrator™ can also determine when a new job is pending. Orchestrator™ can differentiate connections based on the license key used, even if the license keys are from the same machine. Orchestrator™ identifies unique Robot connections using two properties: (1) examining the host machine name from the physical machine, and (2) examining the license key used.

[0081] It should be understood that Orchestrator (e.g., computer name) uses two elements to identify a machine: a license key, which identifies the pool, and a machine name, which identifies the machine. When you rotate the key, a new version of the machine is created in the Orchestrator™ database. The new version becomes active and the old version becomes inactive. The license key identifies which version the machine is on. Autoscaling™ is used to identify machines that are on deprecated versions. This puts the machine on probation and no more jobs can be assigned to this machine. This is to prevent additional jobs from being assigned when disconnecting a machine. This also allows the machine to be safely disconnected without dropping jobs that are already running. In the case of a BYOM embodiment, the same machine can be connected again using a new license key. However, in some cases, or most cases, a new machine using a new license key is connected.

[0082] Returning to Figure 6, at 630, once a new machine specification is created, new tasks are assigned. Note that the following operations may occur: First, new machines may be added to the new machine specification, and existing machines may be moved from the old machine specification to the new one. The movement of existing machines is to those that remain or are identified in the user-entered machine list. Machines that belong to a different pool or do not belong to the user-entered machine list are skipped. This is typically done using global identifiers.

[0083] In some alternative embodiments, rather than completely removing or deleting machines, machines not identified in the user-inputted machine list are soft-deleted. For example, rather than deleting a machine, the machine is marked as hidden, effectively removing the machine from the scope of the existing machine list. This may be applied to unresponsive machines. These unresponsive machines may be transitioned to a stopped state, for example.

[0084] 8 is a flow diagram illustrating a method 800 for adding a machine to a machine pool, according to one embodiment of the present invention. In some embodiments, no new machine specifications have been created and license keys may not need to be rotated. In these embodiments, method 800 begins with adding a machine to the machine pool, at 805. A user provides a list of cloud machine identifiers to add. Rather than creating a new machine specification, the latest (or current) machine specification is retrieved, at 810. At 815, the new machine is added to the latest machine specification and marked as inactive, making it suitable for future use. No further changes are made to other existing machines.

[0085] 9 is a flow diagram illustrating a method 900 for removing a machine from a machine pool, according to one embodiment of the present invention. Method 900 can begin at 905 with removing a machine from the machine pool. A user provides a list of cloud machine identifiers to remove. At 910, rather than creating a new machine specification, the most recent (or current) machine specification is searched. At 915, for machines that belong to the most recent machine specification and are in a stopped state with no pending tasks, the machine is soft-removed from the most recent machine specification. All other machines are skipped.

[0086] FIG. 10 is a flow diagram illustrating a method 1000 for Bring Your Own Machine (BYOM), according to one embodiment of the present invention. Method 1000 can begin at 1005 by a user provisioning one or more machines in a subscription service (e.g., Azure™ or AWS™). See FIG. 11, which illustrates a GUI 1100 through which a user creates a virtual machine, according to one embodiment of the present invention. At 1010, a user creates a cloud connection, for example, in Orchestrator™. See FIG. 12, which illustrates a GUI 1200 illustrating a cloud provider connection, according to one embodiment of the present invention.

[0087] At 1015, a user creates a cloud machine pool in Orchestrator™. See FIG. 13 , which illustrates a GUI 1300 illustrating adding a cloud machine pool, according to one embodiment of the present invention. In some embodiments, the user toggles off “Create machines automatically” and selects the machines they want to add to the machine pool. At 1020, the user configures a recent folder. A recent folder includes features not available in traditional folders. BYOM is part of these features. See FIG. 14 , which illustrates a GUI 1400 illustrating configuring a recent folder, according to one embodiment of the present invention. In some embodiments, the user configures a username and password for an unattended robot. This may be similar to the machine creation flow of step 1005 in FIG. 9 .

[0088] At 1025, the user continues to configure the latest folder, i.e., selects the BYOM machine pool in the machine sector. See FIG. 15, which illustrates a GUI 1500 showing managing machines in a folder, according to one embodiment of the present invention. At 1030, the user can run or execute automations in the latest folder. See FIG. 16, which illustrates a GUI 1600 showing job execution, according to one embodiment of the present invention.

[0089] FIG. 17 illustrates a flow 1700 for creating / editing a machine pool and rotating a license key, according to one embodiment of the present invention. In some embodiments, a user (or actor) can access a user interface 1705 to create or edit a machine pool. Using an application programming interface (API), a request to create and / or edit a machine pool is sent from the user interface 1705 to Orchestrator™ 1710. Orchestrator™ 1710 relays the request to hypervisor 1715. Hypervisor 1715 scans the request to determine whether a new machine specification is needed. Examples of new machine specifications include adding or removing a machine from a machine pool and changing the size or image of a machine, to name a few. If necessary, hypervisor 1715 creates a new machine specification and sends the new machine specification to Orchestrator™ 1710. Separately and asynchronously, hypervisor 1715 determines whether a new task is needed and, if so, creates a new task. For example, when creating a new machine specification, the hypervisor 1715 creates a task that runs asynchronously (but still within the hypervisor 1715) to import one or more new machines from the (new) user-inputted machine list into the new machine specification. See step 630 of FIG. 6. As the responding hypervisor 1715 provides the new machine specification, the Orchestrator™ rotates the license key, which is a synchronous operation. Such an operation includes creating a new version and persisting the new license key while resetting the "IsActive" bit of the previous version (see 1815). Using method 700 of FIG. 7, the Orchestrator™ can rotate the license key and license key to the user interface 1705.

[0090] Figure 18 illustrates an architectural relationship 1800 between hypervisor and orchestrator entities, according to one embodiment of the present invention. In some embodiments, on the Orchestrator™ 1805 side, a Machines module 1810 contains a table containing pool keys. Although invisible to the user, the Machines module 1810 is linked to a Machine Versions module 1815. The Machine Versions module 1815 contains license keys that may be required for rotation. When a license key is rotated, a new license key is activated in the Machine Versions module and the expired license key is revoked.

[0091] On the hypervisor 1820 side, when a machine pool 1825 is created, the machine pool 1825 is linked to a machine module 1810 and a pool key is stored. A machine specification module 1830 is also created and contains the license key associated with the machine version module 1815. This is achieved by linking the machine specification module 1830 to the machine version module 1815. A machine module 1835 is also linked to the machine pool module 1825 and the machine specification 1830.

[0092] FIG. 19 is a relationship diagram 1900 illustrating a machine's statement of purpose, according to one embodiment of the present invention. In the general case, machines are created by cloud robots and added to a machine pool. However, in some embodiments, particularly BYOM embodiments, machines are created by machine customers or users. Machines are assembled into the machine pool in the background. Machines can then connect and disconnect multiple times based on load. This applies to any type of machine pool. For example, if a machine fails (i.e., does not connect properly, does not respond to commands, etc.), it is considered failed and is removed. Strong removal in the general case versus eviction in the BYOM case.

[0093] The process steps performed in Figures 6-10 may be performed by a computer program encoding instructions for a processor to perform at least a portion of the processes described in Figures 6-10 in accordance with embodiments of the present invention. The computer program may be embodied on a non-transitory computer-readable medium. The computer-readable medium may be, but is not limited to, a hard disk drive, a flash device, RAM, tape, and / or any other such medium or combination of media used to store data. The computer program may include encoded instructions for controlling a processor of a computing system (e.g., processor 510 of computing system 500 of Figure 5) to perform all or a portion of the process steps described in Figures 6-10, which may also be stored on a computer-readable medium.

[0094] The computer program may be implemented in hardware, software, or a hybrid implementation. The computer program may be composed of modules designed to operatively communicate with each other and pass information or instructions for display. The computer program may be configured to run on a general-purpose computer, an ASIC, or any other suitable device.

[0095] It will be readily understood that the components of the various embodiments of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments of the present invention, as represented in the accompanying figures, is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments of the invention.

[0096] The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, references throughout this specification to "certain embodiments," "some embodiments," or similar language mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Thus, the appearances of "certain embodiments," "some embodiments," "other embodiments," or similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0097] It should be noted that references to features, advantages, or similar language throughout this specification do not imply that all of the features and advantages that may be realized in the present invention should be in any single embodiment of the present invention, or that any single embodiment of the present invention is. Rather, language referring to features and advantages is understood to mean that the particular feature, advantage, or characteristic described in connection with one embodiment is included in at least one embodiment of the present invention. Thus, throughout this specification, descriptions of features and advantages and similar language can, but do not necessarily, refer to the same embodiment.

[0098] Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.

[0099] Those skilled in the art will readily appreciate that the above-described invention may be practiced with steps in a different order and / or hardware elements in a different configuration than that disclosed. Thus, while the present invention has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be apparent while remaining within the spirit and scope of the invention. Accordingly, reference should be made to the appended claims to determine the scope of the invention.

Claims

1. 1. A computer-implemented method for creating and / or editing a bring-your-own-machine (BYOM) machine pool, comprising: creating and / or editing a machine pool with a static list of machines; retrieving a user-inputted machine list and an existing machine list and comparing the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list; creating a new machine specification if the one or more changes between the user-inputted machine list and the existing machine list are identified; migrating or importing one or more machines to the new machine specification.

2. and rotating an expired license key to a new license key when the new machine specification is created; the new license key facilitates connection of the one or more machines to a cloud-based ecosystem; 10. The computer-implemented method of claim 1.

3. The step of rotating the expired license key to the new license key comprises:

3. The computer-implemented method of claim 2, further comprising randomly generating the new license key for each version in the machine pool before rotating the expired license key to the new license key.

4. The step of rotating the expired license key to the new license key comprises:

3. The computer-implemented method of claim 2, further comprising identifying a machine for rotation from the machine pool when the expired license key is detected or when the new machine specification is created.

5. The step of rotating the expired license key to the new license key comprises: stopping the allocation of one or more new jobs to the identified machine; and transitioning the identified machine to a probationary state.

6. The step of rotating the expired license key to the new license key comprises:

6. The computer-implemented method of claim 5, further comprising removing the machine in the probation state from the machine pool.

7. The step of rotating the expired license key to the new license key comprises: provisioning a new machine based on the new machine specification; and assigning a new license key to the new machine based on the new machine specifications.

8. A non-transitory computer-readable medium containing a computer program configured to cause one or more processors to create and / or edit a machine pool through Bring Your Own Machine (BYOM), the computer program causing the one or more processors to: Creating and / or editing machine pools with static lists of machines; retrieving a user-inputted machine list and an existing machine list, and comparing the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list; creating a new machine specification if the one or more changes between the user-inputted machine list and the existing machine list are identified; A non-transitory computer-readable medium further configured to cause one or more machines to migrate or import the new machine specifications.

9. The computer program causes the one or more processors to: further configured to rotate an expired license key to a new license key when the new machine specification is created; 10. The non-transitory computer-readable medium of claim 8, wherein the new license key facilitates connecting the one or more machines to a cloud-based ecosystem.

10. The computer program causes the one or more processors to:

10. The non-transitory computer-readable medium of claim 9, further configured to randomly generate the new license key for each version in the machine pool before rotating the expired license key to the new license key.

11. The computer program causes the one or more processors to:

11. The non-transitory computer-readable medium of claim 10, further configured to identify a machine for rotation from the machine pool when the expired license key is detected or when the new machine specification is created.

12. The computer program causes the one or more processors to: halting the allocation of one or more new jobs to the identified machine; The non-transitory computer-readable medium of claim 11 , further configured to transition the identified machine to a probation state.

13. The computer program causes the one or more processors to: The non-transitory computer-readable medium of claim 12 , further configured to cause the machine in the probation state to be removed from the machine pool.

14. The computer program causes the one or more processors to: Provisioning a new machine based on said new machine specifications; 13. The non-transitory computer-readable medium of claim 12, further configured to cause a new license key to be assigned to the new machine based on the new machine specifications.

15. 1. A system for creating and / or editing a bring-your-own-machine (BYOM) machine pool, comprising: a memory configured to store one or more computer-executable instructions; one or more processors, wherein the one or more processors execute the one or more instructions to: creating and / or editing a machine pool with a static list of machines; retrieving a user-inputted machine list and an existing machine list and comparing the user-inputted machine list with the existing machine list to identify one or more changes between the user-inputted machine list and the existing machine list; creating a new machine specification if the one or more changes between the user-inputted machine list and the existing machine list are identified; migrating or importing one or more machines to the new machine specification.

16. The one or more processors execute the one or more instructions to: and further configured to perform the step of rotating an expired license key to a new license key when the new machine specification is created; 16. The system of claim 15, wherein the new license key facilitates connection of the one or more machines to a cloud-based ecosystem.

17. The one or more processors execute the one or more instructions to:

17. The system of claim 16, further configured to perform the step of randomly generating the new license key for each version in the machine pool before rotating the expired license key to the new license key.

18. The one or more processors execute the one or more instructions to:

20. The system of claim 17, further configured to perform the step of identifying a machine for rotation from the machine pool when the expired license key is detected or when the new machine specification is created.

19. The one or more processors execute the one or more instructions to: stopping the allocation of one or more new jobs to the identified machine; 20. The system of claim 18, further configured to perform the step of: transitioning the identified machine to a probation state.

20. The one or more processors execute the one or more instructions to: removing the machine in the probation state from the machine pool; provisioning a new machine based on the new machine specification; 20. The system of claim 19, further configured to: assign a new license key to the new machine based on the new machine specifications.

Images