Robot Access Control and Governance for RPA

Abstract

Robot access control and governance for robotic process automation (RPA) is disclosed. A code analyzer, such as a workflow analyzer, for an RPA designer application may read robot access control and governance policy rules for the RPA designer application and analyze activities of an RPA workflow in the RPA designer application against the robot access control and governance policy rules. If one or more analyzed activities of the RPA workflow violate an access control and governance policy rule, the code analyzer may prevent the creation of an RPA robot or the publication of the RPA workflow until the RPA workflow satisfies the access control and governance policy rules. If the analyzed activities of the RPA workflow comply with all required access control and governance policy rules, an RPA robot that executes the RPA workflow may be created or the RPA workflow may be published.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Nonprovisional Patent Application No. 16 / 924,499, filed July 9, 2020. The subject matter of this earlier filed application is incorporated herein by reference in its entirety.

[0002] The present invention relates generally to robotic process automation (RPA), and more particularly to robot access control and governance for RPA. [Background technology]

[0003] Certain actions taken by users of computing systems may violate laws or agreements in the United States and other countries, such as the EU's General Data Protection Regulation (GDPR), the U.S. Health Insurance Portability and Accountability Act (HIPAA), third-party terms of use, and so on. The penalties for violating such laws or agreements can be very severe. For example, in the case of GDPR, low-level violations can be penalized with fines of 10 million euros or 2% of the violator's worldwide annual revenue (not profits), whichever is greater. More serious violations can be penalized with fines of 20 million euros or 4% of the violator's annual revenue, whichever is greater. Such fines can be financially damaging to a company, and in some cases, can be fatal. RPA presents unique challenges to access control and governance. Therefore, improved approaches to RPA access control and governance can be beneficial. Summary of the Invention

[0004] 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 RPA technology. For example, some embodiments of the present invention relate to robot access control and governance for RPA.

[0005] In one embodiment, a computer program for performing robot access control and governance for RPA is stored on a non-transitory computer readable medium. The computer program is configured to cause at least one processor to read access control and governance policy rules for an RPA designer application and to analyze an activity of an RPA workflow of the RPA designer application against the access control and governance policy rules. The program is configured to cause the at least one processor to prevent the generation of an RPA robot or the publication of an RPA workflow until the RPA workflow satisfies the access control and governance policy rules if one or more analyzed activities of the RPA workflow violate the access control and governance policy rules. The program is configured to cause the at least one processor to generate an RPA robot that executes the RPA workflow or to publish the RPA workflow if the analyzed activities of the RPA workflow comply with all required access control and governance policy rules.

[0006] In another embodiment, a computer-implemented method for implementing robot access control and governance for RPA includes analyzing, by a code analyzer, activities of an RPA workflow of an RPA designer application against access control and governance policy rules, and if one or more analyzed activities of the RPA workflow violate the access control and governance policy rules, preventing, by the code analyzer, creation of an RPA robot or publication of the RPA workflow until the RPA workflow satisfies the access control and governance policy rules.

[0007] In yet another embodiment, a computer program for performing robot access control and governance for RPA is stored on a non-transitory computer-readable medium. The computer program is configured to cause at least one processor to determine a link to a file including access control and governance policy rules from a registry entry of a computing system and download the file using the determined link or download governance policy rules from a conductor application. The computer program is configured to cause the at least one processor to read access control and governance policy rules for an RPA designer application from the downloaded file and analyze an activity of an RPA workflow of the RPA designer application against the access control and governance policy. The computer program is configured to cause the at least one processor to prevent the creation of an RPA robot or the publication of an RPA workflow until the RPA workflow satisfies the access control and governance policy rules if one or more analyzed activities of the RPA workflow violate the access control and governance policy rules. The computer program is configured to cause the at least one processor to generate an RPA robot to execute the RPA workflow or publish the RPA workflow if the analyzed activities of the RPA workflow comply with all required access control and governance policy rules, including one or more application and / or universal resource locator (URL) restrictions, one or more package restrictions, one or more activity restrictions, one or more activity property requirements, or any combination thereof. [Brief description of the drawings]

[0008] So that the advantages of certain embodiments of the invention may be readily understood, a more particular description of the invention, briefly described above, will now be made with reference to specific embodiments thereof which are illustrated in the accompanying drawings, which are to be understood as illustrating only typical embodiments of the invention and should not be considered as limiting its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] [Figure 1] FIG. 1 is an architectural diagram illustrating a robotic process automation (RPA) system according to one embodiment of the present invention.

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

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

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

[0013] [Diagram 5] FIG. 1 is an architectural diagram illustrating a computing system configured to perform robot access control and governance for RPA, according to one embodiment of the present invention.

[0014] [Figure 6] 1 is a screenshot showing a folder view of the Windows Registry Editor for UiPath Studio™, according to one embodiment of the present invention.

[0015] [Figure 7]1 is a screenshot showing a portion of a Windows Explorer® UI where the file SampleGovernanceRules.dll is installed in the Rules folder for UiPath Studio™, according to one embodiment of the present invention.

[0016] [Figure 8] 1 is a screenshot illustrating a package management interface, according to one embodiment of the present invention.

[0017] [Figure 9] 1 is a screenshot showing the top right portion of the RPA designer application with the send feedback icon disabled, according to one embodiment of the present invention.

[0018] [Figure 10] 10A-10D are screenshots illustrating a workflow analyzer configuration interface, according to one embodiment of the present invention.

[0019] [Figure 11] 1 is a screenshot illustrating an RPA designer application configuration interface, according to one embodiment of the present invention.

[0020] [Figure 12] 12A and 12B are screenshots illustrating an RPA workflow according to one embodiment of the present invention.

[0021] [Figure 13] 1 illustrates an error list interface, according to one embodiment of the present invention.

[0022] [Figure 14] 1 is a screenshot illustrating a workflow analyzer interface, according to one embodiment of the present invention.

[0023] [Figure 15]FIG. 1 is an architectural diagram illustrating a system for enforcing access control and governance for RPA at robot runtime according to one embodiment of the present invention.

[0024] [Figure 16] 1 is a flowchart illustrating a process for implementing robot access control and governance for an RPA designer application according to one embodiment of the present invention.

[0025] [Figure 17] 1 is a flowchart illustrating a process for implementing robot access control and governance for RPA for a running RPA robot according to one embodiment of the present invention.

[0026] Unless otherwise indicated, like reference numbers denote corresponding features consistently throughout the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] Some embodiments relate to robot access control and governance for RPA. RPA governance is the ability to set policies to prevent users from developing RPA robots that have the ability to perform actions that may harm an organization, such as violating GDPR, HIPAA, or third-party application terms of use. Because developers may create robots that violate privacy laws, terms of use, etc. during automation execution, some embodiments enforce access control and governance restrictions at the robot and / or robot design application level. This may provide an additional level of security and compliance to the RPA process development pipeline in some embodiments by preventing RPA developers from relying on unauthorized software libraries that may introduce security risks or operate in a manner that violates policies, regulations, privacy laws, and / or privacy policies.

[0028] In some embodiments, the RPA robot is prevented from performing actions that are authorized by the user but not by the robot. Traditionally, an organization may control what a user can and cannot do through access control to the organization's systems. However, in the context of RPA, especially in attended automation, such control may not work. The robot performs tasks on behalf of the user, meaning that the back-end system cannot distinguish whether a robot or a user is accessing the system.

[0029] This can be problematic for several reasons. For example, back-end systems may allow users to access certain data that can be misused. However, in a good system, it is usually difficult for users to cause problems at any scale. This is because doing something they shouldn't be doing is time-consuming and tedious. In contrast, when RPA robots are used, they can greatly increase the scale of data misuse or policy violations because of the speed at which they run.

[0030] Consider the following example: An organization uses a customer relationship management (CRM) system to contact customers, fully supporting various privacy options, such as GDPR "opt-out" and "forget" policies or other user protection laws, by checking if the user selected the "do not contact me" option and providing a link to the privacy policy and instructions to request the organization to "forget" them. The organization chooses to allow most of its employees access to the CRM system, but only give permission to a select few employees to send emails through the system.

[0031] However, for legitimate business purposes, this broad range of users needs to have access to customer profiles, including customer email addresses (e.g., an employee may create or edit misinformation that includes customer email addresses in the system when working with customers). Emailing customers without using the CRM system is a violation of organizational policy, but some employees want to know the information and do not want to wait through various approval routes to get permission to do so or have a properly authorized employee do it for them. Without an RPA robot, employees could violate this policy, but it would be tedious to manually copy and paste email addresses from the system one by one. Even if an employee violates this policy, the scale of the violation would be small, so even if a violation does occur, the risk to the organization would be reduced. However, an RPA robot extracts this data and creates and sends emails orders of magnitude faster (e.g., thousands, tens of thousands, hundreds of thousands, millions, etc.) than a human. Thus, whereas a user could manually send 5-10 emails that violate policy and put the company at risk of violating a customer's GDPR "opt-out," letting a robot do this would result in a large number of violating emails.

[0032] As another example, consider a healthcare organization that uses a carefully secured system to store all data in a HIPAA compliant manner. Employees may legitimately access and work with this data in the context of the appropriate application. An employee who is frustrated with the inefficiencies of the system may want to write an RPA robot that extracts patient data into an unsecured Excel spreadsheet on his or her desktop. This is currently a HIPAA violation, and this could expose the organization to significant financial and legal liability if something were to happen to that data, for example, the employee's computer being stolen and accessed.

[0033] As yet another example, the terms of use for a third-party application or service may prohibit using automation to interact with that application or service, and if an employee chooses to write an RPA robot that operates in violation of those terms of use, the company may be exposed to legal liability.

[0034] These and other issues can pose significant risks to organizations employing RPA robots. However, some embodiments reduce or eliminate security and compliance risks from developers by preventing them from using references to unauthorized libraries and activities. RPA developers, whether trained RPA developers (e.g., using UiPath Studio™) or untrained citizen developers (e.g., using UiPath StudioX™), may add references to libraries that are deemed unsafe or that function in ways that violate policy / regulatory rules.

[0035] Consider the following example: The US government does not allow anything that uses technology developed in Russia or other countries that it considers hostile to be installed on US government computing systems. However, there are well-known libraries used in RPA developed by a Russian company (e.g., the Abbyy® OCR engine). Developers can choose to make such libraries unavailable by default on their computing systems, but they cannot explicitly prevent users from relying on such libraries to be included in their RPA projects. An RPA developer's internet access could be blocked, which is undesirable for many reasons when developing software, but the developer could bring unauthorized libraries onto the computing system via another mechanism, for example, a Universal Serial Bus (USB) stick.

[0036] As another example, many financial institutions have strict policies regarding what information may or may not leave their internal networks and firewalls. Today, many RPA libraries (called via RPA activities) operate by communicating with servers on public clouds, such as UiPath's Document Understanding activity. These financial institutions are concerned that users will not realize that they are not allowed to use such activities because they may transmit sensitive data outside the company firewall. However, there are no existing effective options to prevent this.

[0037] Yet another concern is preventing large-scale RPA from overwhelming the system. One of the reasons for RPA's huge success is its ability to automate legacy systems without the need to upgrade them. Because legacy systems were not designed to be automated, their design and performance can only handle interactions at the speed at which a human can operate them. However, legacy applications cannot always keep up with the speed at which an RPA robot can interact with the system. A robot that is not designed to work within such constraints could essentially overwhelm the legacy system with requests faster than it can handle, essentially executing an accidental denial of service (DoS) attack against the system. Although settings exist in UiPath Studio™ that allow for delays between activities, there is currently no central enforcement mechanism that ensures that developers use such settings when dealing with legacy systems that cannot operate at the speed of an RPA robot.

[0038] Yet another concern is ensuring organizational policy compliance. Many organizations have specific rules they want to enforce on automation. For example, enforcing that emails created by automation are only sent to internal employees and not external recipients, enforcing that all emails created by automation are saved as drafts and not sent without human review, to name a few. Without proper governance, such policies may be violated by RPA robots.

[0039] To address various access control and governance challenges that may arise with RPA, some embodiments provide the ability for organizations to define and enforce governance policies. For example, this may be implemented via JavaScript Object Notation (JSON) files that define what an RPA robot can and / or cannot access. In some embodiments, organizations provide various RPA Designer application settings that allow organizations to control which applications and / or Universal Resource Locators (URLs) can and / or cannot be automated, control which activities can and / or cannot be used, control which packages (e.g., libraries, etc.) can and / or cannot be used, create and deploy custom rules that extend the governance capabilities, control package feeds available for users to install libraries, etc.

[0040] In some embodiments, governance may be implemented at design time (i.e., when a developer is building, testing, and modifying an RPA robot workflow). However, this may make it difficult or impossible to enforce certain policies. For example, it may be difficult or impossible to enforce policies if the values ​​to which the policies are applied are only known at run time. For example, if an organization wants to set a policy that prevents access to certain websites, design time analysis needs to know which URLs to flag. However, in some embodiments, it is possible to build an RPA program in such a way that values ​​are loaded from dynamic sources, such as external files or prompts that ask the user. In this case, design time analysis is insufficient because the values ​​that violate the policy are not known at design time. Another example is when an organization wants to prevent automation of emails to customers outside the organization, but the list of email addresses is from a spreadsheet. In this case, email is a dynamic input to the system that is unknown at design time, but instead needs to be evaluated at run time.

[0041] In certain embodiments, governance is enforced at run time in addition to or instead of design time enforcement. This may be done, for example, via a server-side application for configuring and deploying policies. For example, policies may be automatically sent to users' computing systems when these computing systems connect to a server-side conductor application. An RPA designer application may automatically insert code into RPA robots that causes the RPA robots to retrieve such policies and act in accordance with them.

[0042] In some embodiments, controls may be defined for the RPA designer application based on organization, role, group, individual developer, etc. to control what developers can do when developing RPA robots. Policies may be defined and controls may be implemented to control what RPA robots can do when they execute automations. Such embodiments may enable organizations to better meet compliance and governance requirements with respect to laws, regulations, agreements, and corporate policies.

[0043] In some embodiments, local files may only be modified by administrators, so non-administrator users should not be able to override or modify these files. Package feeds may be locked down so that only desired feeds are available and no additional feeds can be added, preventing users from using packages obtained elsewhere. In certain embodiments, the "Send Feedback" tool may be disabled as part of a policy.

[0044] A "package feed," as used herein, is a location (remote or local) that contains access to additional libraries that a developer can optionally choose to install to obtain additional functionality for their automation projects. A library, as used herein, is a package that contains computer code that provides additional functionality (e.g., activities, etc.) to a project. An example of a package feed is the UiPath Connect™ marketplace. This is an open location where community members can upload libraries containing custom activities that they have created. If a UiPath® RPA developer wants to use such functionality, the developer may browse and add library references to their projects. An example of a library is the UiPath GSuite™ activities. The default installation of UiPath Studio™ does not give an RPA developer the ability to interact with GSuite™. However, a developer may install the GSuite™ activities library, which gives the project the ability to use activities to interact with GSuite™ (e.g., Gmail™, Google™ Spreadsheets, Google™ Drive, etc.).

[0045] In some embodiments, a code analyzer, such as a program analyzer or an RPA workflow analyzer, is provided as an auditing feature for the RPA designer application. The workflow analyzer may define what is permitted when a user executes the RPA designer application and enforce policies. For example, permitted URLs that a user can operate on are specified, certain URLs are restricted, etc.

[0046] A "code analyzer," as used herein, is computer code that executes a set of rules that inspects code written by an RPA user and generates feedback (e.g., a message, a warning, an error, etc.) if the application does not meet the rules. In some embodiments, the code analyzer is provided by the vendor of the RPA application (e.g., UiPath®, etc.) or written by a customer using the RPA application. An example of a code analyzer rule is the UiPath Studio™ "App / Url Restrictions" rule, which allows an organization to define which desktop applications and website URLs are or are not available for use in automation projects. If a user violates any of these rules, the user will receive a notification with a severity specified in the governance policy. In some embodiments, this is typically an error that prevents the automation from being published or executed.

[0047] Certain embodiments may be used for Robotic Process Automation (RPA). 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 may provide solutions for application integration and automation of third-party applications, management information technology (IT) tasks, and business IT processes. The designer 110 may facilitate the development of automation projects, which are graphical representations of business processes. In brief, the designer 110 facilitates the development and deployment of workflows and robots.

[0048] An automation project enables rule-based process automation by allowing developers to control the order of execution and relationships between a custom set 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 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.

[0049] Some types of workflows may include, but are not limited to, sequences, flowcharts, FSMs, and / or global exception handlers. Sequences may be particularly suitable for linear processes, allowing flow from one activity to another without perturbing the workflow. Flowcharts may be particularly suitable for more complex business logic, allowing for the integration of decisions and the connection of activities in more diverse ways with multiple branching logical operators. FSMs may be particularly suitable for large workflows. FSMs may use a finite number of states at run time, which are triggered by conditions (i.e., transitions) or activities. Global exception handlers may be particularly suitable for determining workflow behavior when an execution error occurs or for debugging the process.

[0050] 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 an environment. Conductor 120 may also act as one of the integration or aggregation points with third party solutions and applications.

[0051] The conductor 120 may manage all the robots 130, connecting and running them from a central 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 may be used with the conductor 120 for a centralized process deployment and logging medium. Attended robots 132 help human users accomplish various tasks and may be triggered by user events. In some embodiments, processes cannot be initiated from the conductor 120 for this type of robot and / or cannot be run under a locked screen. In certain embodiments, the attended robot 132 can only be started from the robot tray or from a command prompt. In some embodiments, the attended robot 132 should operate under human supervision.

[0052] Unattended Robots 134 run hands-free in a virtual environment and can automate many processes. Unattended Robots 134 may be responsible for providing remote execution, monitoring, scheduling, and work queue support. In some embodiments, debugging of all robot types may be performed in Designer 110. 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.).

[0053] The conductor 120 may have various functions including, but not limited to, provisioning, deployment, versioning, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning may include creating and maintaining connections between robots 130 and the conductor 120 (e.g., web applications, etc.). Deployment may include ensuring correct delivery of package versions to robots 130 assigned for execution. Versioning may include managing unique instances of a process or configuration in some embodiments. Configuration may include maintaining and delivering robot environments 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, etc.) and / or other storage mechanism (e.g., ElasticSearch, etc., which provides the ability to store and quickly query large data sets). The conductor 120 may provide interconnectivity by serving as a centralized point of communication for third-party solutions and / or applications.

[0054] The robot 130 is an execution agent that executes workflows embedded in the designer 110. One commercial example of some embodiments of the robot 130 is UiPath Robots™. In some embodiments, the robot 130 installs a service that is managed by the Microsoft Windows Service Control Manager (SCM) by default. As a result, such a robot 130 can open an interactive Windows session under the local system account and have the privileges of a Windows service.

[0055] In some embodiments, the robot 130 may be installed in user mode. For such a robot 130, this means that the robot 130 is installed under the user and has the same rights as the user. This feature may be available for high density (HD) robots and may ensure maximum utilization of each machine. In some embodiments, any kind of robot 130 may be configured in an HD environment.

[0056] The Robot 130 in some embodiments is divided into several components, each dedicated to a specific automation 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 Windows sessions to act as a proxy between the Conductor 120 and the execution host (i.e., the computing system on which the Robot 130 executes). Such a service is entrusted with and manages the credentials of the Robot 130. A console application is launched by the SCM under the local system.

[0057] 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 may be entrusted with and manage the credentials of the robot 130. If the SCM-managed robot service is not installed, a Windows application may be launched automatically.

[0058] An Executor may run a given job under a Windows session (i.e., an Executor may execute a workflow). An Executor may be aware of per-monitor dots per inch (DPI) settings. An Agent may be a Windows Presentation Foundation (WPF) application that displays available jobs in a system tray window. An Agent may be a client of this service. An Agent may request to start or stop jobs and change settings. A Command Line may be a client of the service. A Command Line is a console application that can request to start a job and wait for its output.

[0059] Splitting the robot 130 components as described above allows developers, support users, and computing systems to more easily execute, identify, and track what each component is doing. In this way, special behaviors may be configured for each component, for example, by setting different firewall rules for executors and services. In some embodiments, the executor may always be aware of per-monitor DPI settings. As a result, workflows may run 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 may be disabled in some embodiments.

[0060] FIG. 2 is an architecture diagram illustrating a deployed RPA system 200 according to an embodiment of the present invention. In some embodiments, the RPA system 200 may be or may be 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. On the client side, a 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 executes the process. As shown in FIG. 2, multiple business projects may be running simultaneously. In such an embodiment, the agent 214 (e.g., a Windows service, etc.) is the single connection point for all the executors 212. All messages in such an embodiment are logged into the conductor 230, which further processes the messages via the database server 240, the indexer server 250, or both. As described above with respect to FIG. 1, the executor 212 may be a robotic component.

[0061] 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 that supports multiple interactive sessions running simultaneously (e.g., Windows Server 2012, etc.), multiple Robots may run simultaneously, each in a separate Windows session using a unique username. This is referred to as the HD Robot above.

[0062] Agent 214 is also responsible for sending the status of the robot (e.g., periodically sending "heartbeat" messages to indicate that the robot is still functioning) and downloading the necessary versions of packages to be executed. In some embodiments, communication between agent 214 and conductor 230 is always initiated by agent 214. In notification scenarios, agent 214 may open a WebSocket channel that is later used by conductor 230 to send commands to the robot (e.g., start, stop, etc.).

[0063] On the server side, the components include a presentation layer (web application 232, Open Data Protocol (OData) Representative State Transfer (REST) ​​Application Programming Interface (API) endpoints 234, notifications and monitoring 236), a service layer (API implementation / business logic 238), and a persistence layer (database server 240 and indexer server 250). Conductor 230 includes web application 232, OData REST API endpoints 234, notifications and monitoring 236, and API implementation / business logic 238. In some embodiments, most actions performed by a user on 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 to run without touching it, etc., without departing from the scope of the invention. Web application 232 is the visual layer of the server platform. In such an embodiment, the 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. In such an embodiment, a user interacts with web pages from the web application 232 via the browser 220 to perform various actions to control the conductor 230. For example, a user may create robot groups, assign packages to robots, analyze logs per robot and / or per process, start and stop robots, etc.

[0064] 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 invention. The REST API is used by both the web application 232 and the agent 214. In such an embodiment, the agent 214 is a supervisor of one or more robots on a client computer.

[0065] The REST API in such an embodiment covers configuration, logging, monitoring, and queuing functionality. In some embodiments, a configuration endpoint may be used to define and configure application users, permissions, robots, assets, releases, and environments. A logging REST endpoint may be used to log various information, such as errors, explicit messages sent by the robot, and other environment specific information. A deployment REST endpoint may be used by a robot to query the package version that needs to be executed when a start job command is used in the conductor 230. A queuing REST endpoint may be responsible for managing queues and queue items, such as adding data to the queue, getting transactions from the queue, and setting the status of transactions.

[0066] The monitoring REST endpoint may monitor the web application 232 and the agents 214. The notification and monitoring API 236 may be a REST endpoint used to register the agents 214, deliver configuration settings to the agents 214, and send and receive notifications from the server and the agents 214. In some embodiments, the notification and monitoring API 236 may also use WebSocket communications.

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

[0068] Indexer server 250, which is optional in some embodiments, stores and indexes information logged by the robots. In certain embodiments, indexer server 250 may 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 the robots (e.g., using activities such as log messages, line writes, etc.) may be sent via a logging REST endpoint to indexer server 250, where they may be indexed for future use.

[0069] FIG. 3 is an architecture diagram illustrating the relationship 300 between a designer 310, activities 320, 330, and a driver 340, according to an embodiment of the present invention. As described above, a developer uses the designer 310 to develop a workflow to be executed by the robot. The workflow may include user-defined activities 320 and UI automation activities 330. Some embodiments may identify non-textual visual components in an image, referred to herein as computer vision (CV). Some CV activities associated with such components may include, but are not limited to, click, type, get text, hover, element exists, refresh scope, highlight, and the like. In some embodiments, click identifies an element using, for example, CV, optical character recognition (OCR), fuzzy text matching, multiple anchors, and clicks. Type may identify an element using the above and types within the element. Get text identifies the location of a particular text and may scan using OCR. Hover may identify an element and hover over it. Element exists may use the techniques described above to check if an element is present on the screen. In some embodiments, there may be hundreds or thousands of activities that can be implemented in designer 310. However, any number and / or type of activities may be utilized without departing from the scope of the invention.

[0070] UI automation activities 330 are a subset of specialized low-level activities (e.g., CV activities, etc.) written in low-level code that facilitate interaction with the screen. UI automation activities 330 facilitate such interaction via drivers 340 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.

[0071] Driver 340 may interact with the OS at a low level to look for hooks, monitor keys, etc. Driver 340 may facilitate integration with Chrome®, IE®, Citrix®, SAP®, etc. For example, a "click" activity plays the same role in such different applications via driver 340.

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

[0073] 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.

[0074] FIG. 5 is an architecture diagram illustrating a computing system 500 configured to perform robot access control and governance for RPA, according to an embodiment of the present invention. In some embodiments, the computing system 500 may be one or more computing systems illustrated and / or described in this application. The computing system 500 includes a bus 505 or other communication mechanism for communicating information and a processor 510 connected to the bus 505 for processing information. The 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), examples thereof, and / or any combination thereof. The processor 510 may also have multiple processing cores, and at least some of the cores may be configured to perform a specific function. In some embodiments, multiple parallel processing may be used. In certain embodiments, at least one processor 510 may be a neuromorphic circuit that includes processing elements that mimic biological neurons. In some embodiments, the neuromorphic circuit may not require typical components of a von Neumann computing architecture.

[0075] 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 devices such as magnetic or optical disks, or any other type of non-transitory computer readable medium, or any 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 be removable, non-removable, or both.

[0076] Additionally, the computing system 500 includes a communication device 520, such as a transceiver, to provide access to a communication network via wireless and / or wired connections. In some embodiments, the communications device 520 may be configured to support any of a variety of wireless 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) communications, 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), 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 (RF), and other wireless technologies without departing from the scope of the present invention. The communication device 520 may be configured to use 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. 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 invention.

[0077] The processor 510 is further connected 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 (haptic) display, a three-dimensional (3D) touch display, a multi-input touch display, a multi-touch display, or the like, using resistive, capacitive, surface acoustic wave (SAW) capacitive, infrared, optical imaging, dispersive signal techniques, acoustic pulse recognition, frustrated total internal reflection, or the like. Any suitable display device and haptic I / O may be used without departing from the scope of the invention.

[0078] A keyboard 530 and cursor control device 535, such as a computer mouse, touchpad, etc., are further connected 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 the 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 computing system 500, or computing system 500 may operate autonomously.

[0079] 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 robot access control and governance module 545 configured to perform all or part of the processes described herein or derivatives thereof. The computing system 500 may also include one or more additional functional modules 550 that include additional functionality.

[0080] 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, any other suitable computing device, or a combination of devices, without departing from the scope of the present invention. The depiction of the above functions as being performed by a "system" is in no way intended to limit the scope of the present invention, but is intended to illustrate one example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in a localized and distributed fashion consistent with computing technologies, including cloud computing systems.

[0081] It should be noted that some of the system functionality described herein has been illustrated as modules to further emphasize implementation independence. For example, a module may be implemented as hardware circuitry including custom very large scale integration (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, and the like.

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

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

[0084] In some embodiments, governance information for the RPA designer application may be stored in a file that is not editable by the RPA developer. For example, FIG. 6 is a screenshot showing a view of a folder 600 in the Windows Registry Editor 600 for the RPA designer application (in this case, UiPath Studio™). Under the path Computer\HKEY_CURRENT_USER\Software\UiPath, a registry key 610 named GovernanceSource is set (e.g., when the RPA designer application is installed) and points to a remote policy file available via an associated link 620. The policies available at this link are loaded only on the computing system and used by the RPA designer application or the RPA robot to manage certain permissions. The policies may be defined at an individual user level, a group level, a role level, an organization level, etc. By including the policies via the remote link, updates to the policies can be made whenever desired and the updated policies will be automatically accessed by using the PRA robot and / or the RPA designer application. In this example, the policy file provides the ability to define different policy sets for the development profile. In some embodiments, different policies may be set for experienced programmers and citizen developers who may not have programming knowledge, since these developers may have different needs. Included below is a portion of an example policy file for UiPath Studio™ that defines rules for development users, business users, and StudioPro users. The angle brackets indicate where additional rules or counters can be defined in this example. { "Metadata": { "Version": "1.0", }, "Info": { "Name": "Sample Policy Registry Key" }, "Profiles": { "Development": { "Shell": { "IsFeedbackEnabled": true, "HideGettingStartedScreen": false }, "SourceControl": { "CheckInBeforePublish": false }, "Workflow": { "DockedAnnotations": true, "AnalyzeOnPublish": false, "AnalyzeOnRun": false }, "PackageManager": { "AllowAddRemoveFeeds": false, "AllowEnableDisableFeeds": false, "AllowOrchestratorFeeds": true, "Feeds": [ { "Name": "Local", "Source": "C:\\Program Files (x86)\\UiPath\\Studio\\Packages", "IsEnabled": true }, { "Name": "Official", "Source": "https: / / www.myget.org / F / workflow / ", "IsEnabled": true }, { "Name": "Connect", "Source": "https: / / gallery.uipath.com / api / v2", "IsEnabled": true } ] }, "Analyzer": { "AllowEdit": false, "ReferencedRulesConfigFile": null, "EmbeddedRulesConfig": { "Rules": [ { "Id": "ST-NMG-001", "IsEnabled": true, "Parameters": [ { "Name": "Regex", "Value": null } ], "ErrorLevel": "Off" }, <ADDITIONAL RULES DEFINED HERE> ], "Counters": [ { "Id": "ST-NMG-001", "IsEnabled": true, "Parameters": [] }, <ADDITIONAL COUNTERS DEFINED HERE> ] } } }, "Business": { "Shell": { "IsFeedbackEnabled": true, "HideGettingStartedScreen": false }, "SourceControl": { "CheckInBeforePublish": false }, "Workflow": { "DockedAnnotations": true, "AnalyzeOnPublish": false, "AnalyzeOnRun": false }, "PackageManager": { "AllowAddRemoveFeeds": false, "AllowEnableDisableFeeds": false, "AllowOrchestratorFeeds": true, "Feeds": [ { "Name": "Local", "Source": "C:\\Program Files (x86)\\UiPath\\Studio\\Packages", "IsEnabled": true }, { "Name": "Official", "Source": "https: / / www.myget.org / F / workflow / ", "IsEnabled": true }, { "Name": "Connect", "Source": "https: / / gallery.uipath.com / api / v2", "IsEnabled": true } ] }, "Analyzer": { "AllowEdit": false, "ReferencedRulesConfigFile": null, "EmbeddedRulesConfig": { "Rules": [ { "Id": "ST-NMG-001", "IsEnabled": true, "Parameters": [ { "Name": "Regex", "Value": null } ], "ErrorLevel": "Off" }, <ADDITIONAL RULES DEFINED HERE> ], "Counters": [ { "Id": "ST-NMG-001", "IsEnabled": true, "Parameters": [] }, <ADDITIONAL COUNTERS DEFINED HERE> ] } } }, "StudioPro": { "Shell": { "IsFeedbackEnabled": true, "HideGettingStartedScreen": false }, "SourceControl": { "CheckInBeforePublish": false }, "Workflow": { "DockedAnnotations": true, "AnalyzeOnPublish": false, "AnalyzeOnRun": false }, "PackageManager": { "AllowAddRemoveFeeds": false, "AllowEnableDisableFeeds": false, "AllowOrchestratorFeeds": true, "Feeds": [ { "Name": "Local", "Source": "C:\\Program Files (x86)\\UiPath\\Studio\\Packages", "IsEnabled": true }, { "Name": "Official", "Source": "https: / / www.myget.org / F / workflow / ", "IsEnabled": true }, { "Name": "Connect", "Source": "https: / / gallery.uipath.com / api / v2", "IsEnabled": true } ] }, "Analyzer": { "AllowEdit": false, "ReferencedRulesConfigFile": null, "EmbeddedRulesConfig": { "Rules": [ { "Id": "ST-NMG-001", "IsEnabled": true, "Parameters": [ { "Name": "Regex", "Value": null } ], "ErrorLevel": "Off" }, <ADDITIONAL RULES DEFINED HERE> ], "Counters": [ { "Id": " ST-NMG-001", "IsEnabled": true, "Parameters": [] }, <ADDITIONAL RULES DEFINED HERE> ] } } } } }

[0085] Note that while the rules and counters shown here are the same for each user type, this is not necessarily the case, and typically would not be the case in an actual implementation. Note also that the file containing the control and governance policy rules is obtained using a registry entry in some embodiments, and in certain embodiments, a file or other policy information format is delivered by the conductor application. In certain embodiments, the server UI allows an administrator to define a policy that is delivered over the connection (e.g., as a .json payload). However, this policy does not have to be a "file" that the administrator explicitly creates, in some embodiments.

[0086] In some embodiments, custom governance rules may be developed as part of the workflow analyzer process. For example, in some embodiments, an installation script for an RPA designer application may install the custom governance rules on a user's computing system. For example, see screenshot 700 in FIG. 7, which shows a portion of a Windows Explorer® UI in which the file SampleGovernanceRules.dll 710 is installed in the Rules folder for UiPath Studio™. Because SampleGovernanceRules.dll 710 is in the Program Files folder, only an administrator may modify it. An end user who does not have administrative privileges on his or her machine cannot modify it. Thus, an end user who does not have such privileges would have governance policies and would not be able to override or modify them.

[0087] 8 is a screenshot showing a package management interface 800, according to one embodiment of the present invention. In this embodiment, the package feeds for developers are locked down. In particular, developers can only access the official package feed 810, and developers cannot enable or disable the official package feed 810. Developers also cannot enter names 820 or sources 830 for user-defined packages, add user-defined packages using the add button 840, or save modified package settings using the save button 850. This prevents developers from retrieving activity packages from locations that the organization does not want.

[0088] Some organizations may be concerned that developers may reveal confidential information to the provider of the RPA designer application during development. Thus, in some embodiments, the Send Feedback feature is disabled in the RPA designer application as a matter of policy. See, for example, Figure 9, which is a screenshot showing the top right portion 900 of the RPA designer application with the Send Feedback icon disabled and a message 910 indicating that this is the case.

[0089] 10A is a screenshot showing a workflow analyzer settings interface 1000, according to one embodiment of the present invention. In some embodiments, the workflow analyzer settings are obtained from a policy configuration file. Referring to FIG. 10A, various rules are listed in a rules pane 1002 with their respective codes, names, scopes, and default actions. Specific setting options for a selected rule are displayed in a rule settings pane 1004.

[0090] In this embodiment, there are four types of access restrictions: application / URL restrictions 1010, package restrictions 1020, activity restrictions 1030, and activity property requirements 1040. However, any number and / or types of access restrictions may be used without departing from the scope of the present invention. App / URL restrictions 1010 control which applications and / or URLs are and / or are not permitted to be used by a user of the RPA designer application. For example, referring to FIG. 10B, if there are any prohibited applications, they are indicated in prohibited applications field 1012, and permitted applications are displayed in permitted applications field 1014. If the user scrolls down, the prohibited and permitted URLs will be displayed in the respective fields. Of course, it is not possible to both prohibit (e.g., blacklist) and permit (e.g., whitelist) a given application or URL. In a particular embodiment, if permitted applications are specified, the user can only use those applications. In this embodiment, such fields are read-only.

[0091] Package restrictions 1020 control which packages are prohibited. For example, referring to FIG. 10C , prohibited packages may be listed in prohibited packages field 1022, which in some embodiments may restrict categories of packages that an organization does not want the user to have access to. In certain embodiments, permitted packages may be listed in addition to or instead of prohibited packages field 1022. In this embodiment, prohibited packages field 1022 is read-only.

[0092] Activity restrictions 1030 control which activities a user is permitted and / or not permitted to use. For example, referring to FIG. 10D, if there are any prohibited activities, they are displayed in prohibited activities field 1032, and if there are any activities listed as permitted, they are displayed in permitted activities field 1034. Thus, if restrictions are not desired at the package-wide level, but there are certain activities that should not be permitted and / or only certain activities should be permitted, this may be specified via activity restrictions 1030. In this embodiment, such fields are read-only.

[0093] In some embodiments, if no activities are specified as allowed and / or not allowed, this defaults to all activities being allowed. In certain embodiments, only allowed or not allowed is enforced, not both. For example, in such an embodiment, if both allowed and not allowed activities are included, the "allowed" set may take precedence and the not allowed set may be ignored, since the specific specification of allowed activities is deemed to be more restrictive.

[0094] Activity property requirements 1040 allow organizations to define custom rules. Returning to FIG. 10A, the rule configuration field 1042 includes the following fields: Property: * Draft * ,Activity: *The rule has a value of "MailX, Value: True". In this example, the Draft property should be set to True for the MailX activity in UiPath StudioX™ that handles Outlook®. As with other types of restrictions, the rule configuration field 1042 is read-only to the user. As shown in Figures 10A-10D, some rules are configured to provide an error as the default action, while others are configured to provide a warning.

[0095] As shown in the screenshot of Figure 11, in the RPA designer application configuration interface 1100, various settings may be implemented for RPA workflow design. In this case, the workflow must pass through a workflow analyzer both before execution and before publication. This implementation can be seen in settings 1110 and 1120, respectively. This means that for governance policies configured as rules in the workflow analyzer configuration interface 1000, the workflow must comply with all rules that are configured to throw an error in case of non-compliance.

[0096] 12A and 12B are screenshots showing an RPA workflow 1200 according to an embodiment of the present invention. A user is attempting to automate content at link 1210 (here, "https: / / www.uipath.com / "). Consider the case where this is not an allowed URL based on the workflow analyzer rules. Also consider the case where a rule exists that requires the "save as draft" checkbox 1220 to be selected. When the user attempts to validate the workflow, an error list interface 1300 is displayed, in this embodiment. See FIG. 13. The error list interface 1300 indicates that the "save as draft" property does not meet the organization's guidelines and that https: / / www.uipath.com / is not an allowed application defined by the organization for UI automation.

[0097] As noted above, in some embodiments, policies may be defined based on the technical sophistication of the user. For example, for UiPath Studio™, which tends to be used by RPA developers with programming knowledge, more complex rules may be defined than for UiPath StudioX™, which may be used by individuals with any level of programming knowledge or lack thereof. For example, a user of the RPA designer application with more technical sophistication may have access to more package feeds, be able to disable feeds, have a richer set of rules, etc.

[0098] Consider the Workflow Analyzer interface 1400 in Figure 14. In this case, a rich set of rules, including custom rules, is provided to the RPA developer. A custom package version requirement rule 1410 is in place. The mail activity "UiPath.Mail.Activities" must have a minimum version of 1.6.0 and a maximum version of 1.6.0 in the rule settings field 1412, and will throw an error if a different version is referenced. This requires that UiPath.Mail.Activities be at this exact version. Also, the Allow pre-release packages field 1414 is set to "True".

[0099] As noted above, in some embodiments, governance is enabled as part of the installation script for the RPA designer application. In certain embodiments, a remote policy file may be configured via a registration key so that the RPA designer application always has a current version of the governance policies. Alternatively, the policy file may reside in a protected location on the local computing system where the RPA designer application resides. In some embodiments, custom rules are deployed to a protected "rules" folder as part of the installation script.

[0100] In some embodiments, separate policies may be applied to technically savvy users and non-programming users. In certain embodiments, different policies are applied based on a given user, a user's role, a group of users, etc. In some embodiments, a user cannot execute or publish a non-compliant RPA workflow.

[0101] 15 is an architecture diagram illustrating a system 1500 for performing access control and governance for RPA at robot runtime, according to an embodiment of the present invention. The system 1500 comprises a user computing system, such as a desktop computer 1502, a tablet 1504, a smartphone 1506, etc. However, any desired computing system may be used without departing from the scope of the present invention, including, but not limited to, a smart watch, a laptop computer, an Internet of Things (IoT) device, a vehicle computing system, etc.

[0102] Each computing system 1502, 1504, 1506 has an RPA robot 1510 executing thereon that performs one or more automations. However, in certain embodiments, the computing systems 1502, 1504, 1506 may execute different robots. When the RPA robot executes its processes, it requests certain information from a server 1530 (e.g., sends a request to a conductor application executing on the server 1530) via a network 1520 (e.g., a local area network (LAN), a mobile network, a satellite network, the Internet, any combination thereof, etc.). For example, the RPA robot 1510 may communicate with the server 1530 to send and receive data (e.g., push / pull from a data queue), retrieve securely stored credential / asset information (e.g., username / password, access token, etc.), log information from activities (e.g., execution logs, etc.), report "heartbeat status" (e.g., that the RPA robot 1510 is running correctly, etc.), check "orchestration commands" (e.g., "run this", "abort / cancel execution", etc.), or any other suitable communication without departing from the scope of the invention. In some embodiments, the server 1530 may run a conductor application, and data may be sent periodically as part of a heartbeat message. The server 1530 retrieves access control and governance rules for a given robot from one or more files 1532, databases 1540, or both.

[0103] The server 1530 checks the actions performed by the robot 1510 and / or the information requested by the RPA robot against access control and governance rules. If the robot 1510 is authorized to perform the action or obtain the information, the server 1530 provides the requested information to the robot 1510 and / or sends information to a validation application on its computing system indicating that the action is acceptable. If not authorized, the server 1530 does not provide the requested information to the robot 1510 and / or sends information to a validation application on its computing system indicating that the action attempted by the robot 1510 is not acceptable. In certain embodiments, the validation application may terminate a process associated with the robot 1510.

[0104] In some embodiments, the disallowed actions may be actions that are allowed for a human user, but not for the RPA robot. In certain embodiments, the server 1530 may ensure that the robot 1510 pauses long enough for one or more legacy systems, and may delay obtaining the information requested by the robot or accepting requests for new information from the robot until the delay time expires. In certain embodiments, governance is enforced at run time in addition to being enforced at design time. In some embodiments, policies may be automatically sent to the computing systems 1502, 1504, 1506 when they connect to, for example, a server-side conductor application on the server 1530. In some embodiments, the RPA designer application may automatically insert code into the RPA robot that causes the RPA robot to obtain such policies and act in accordance with the policies.

[0105] FIG. 16 is a flow chart illustrating a process 1600 for implementing robot access control and governance for an RPA designer application according to one embodiment of the present invention. The process begins by determining a link to a file containing access control and governance policy rules from a registry entry of the computing system at 1605 and downloading the file using the determined link at 1610. In some embodiments, the access control and governance policy rules are implemented via an installation script of the RPA designer application. At 1615, the workflow analyzer reads the RPA designer application's access control and governance policy rules from the file.

[0106] In some embodiments, the access control and governance policy rules include controlling which applications and / or URLs can be automated and / or cannot be automated, which activities can be used and / or cannot be used in an RPA workflow, which packages can be used and / or cannot be used for an RPA workflow, or any combination thereof. In certain embodiments, the access control and governance policy rules are defined for the RPA designer application based on an organization, a role, a group, an individual developer, or any combination thereof. In some embodiments, the access control and governance policy rules cannot be changed by a user of the RPA designer application as enforced by the operating system of the computing system on which the RPA designer application executes. In certain embodiments, the access control and governance policy rules include one or more application and / or URL restrictions, one or more package restrictions, one or more activity restrictions, one or more activity property requirements, or any combination thereof.

[0107] In some embodiments, various interfaces may be displayed and may prevent unauthorized user changes at 1620. For example, a package management interface may be displayed that includes packages accessible by activities in the RPA workflow and may prevent a user of the RPA designer application from modifying authorized packages or adding unauthorized new packages based on access control and governance policy rules. As another example, a workflow analyzer configuration interface may be displayed that lists access control and governance policy rules and may prevent a user of the RPA designer application from modifying the access control and governance policy rules.

[0108] At 1625, the RPA workflow activity of the RPA designer application is analyzed against the access control and governance policy rules. In some embodiments, the analysis of the RPA workflow activity includes checking whether one or more libraries accessed in the RPA workflow are whitelisted or blacklisted. If the checking is successful at 1630 (i.e., the RPA workflow activity complies with all required access control and governance policy rules), then at 1635, an RPA robot is generated to execute the RPA workflow or the RPA workflow is published. However, if the checking is unsuccessful at 1630 (i.e., one or more analyzed activities of the RPA workflow violate the access control and governance policy rules), then the generation of the RPA robot or the publication of the RPA workflow is prevented until the RPA workflow satisfies the access control and governance policy rules. In this embodiment, at 1640, the RPA workflow analyzer / RPA designer application waits for the user to make changes to the RPA workflow. The process then returns to step 1625 to analyze the modified activities of the RPA workflow. In some embodiments, only the activities that have changed are reanalyzed.

[0109] 17 is a flow chart illustrating a process 1700 for performing robot access control and governance for RPA for a running RPA robot, according to an embodiment of the present invention. The process begins at 1710 by checking an action performed by the RPA robot and / or information requested by the RPA robot against access control and governance rules. This check may be performed, for example, by a client-side or server-side validation application. If the RPA robot is authorized to perform the action and / or obtain the information at 1720, the requested information is provided to the RPA robot and / or the action is approved at 1730. The validation application then waits at 1740 until the next RPA robot communication is received.

[0110] If the RPA robot is not authorized to perform the action and / or obtain the information at 1720, the validation application prevents the RPA robot from obtaining the information and / or performing the action at 1750. In some embodiments, a notification may be sent to the RPA robot that access to the information and / or the action is not authorized at 1760. In certain embodiments, the validation application may automatically terminate execution of the RPA robot at 1770 (e.g., by terminating a process associated with the RPA robot).

[0111] In some embodiments, the disallowed actions may be actions that are permitted for a human user, but not for the RPA robot. In particular embodiments, the validation application may verify that the RPA robot pauses long enough for one or more legacy systems to delay retrieving the information requested by the RPA robot or accepting a request for new information from the RPA robot until the delay time expires.

[0112] The process steps performed in Figures 16 and 17 may be executed by a computer program to encode instructions for a processor to perform at least a portion of the process described in Figures 16 and 17, according to an embodiment of the present invention. The computer program may be stored 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, a RAM, a 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 (such as, for example, processor 510 of computing system 500 of Figure 5) to perform all or a portion of the process steps described in Figures 16 and 17, which may also be stored on a computer-readable medium.

[0113] 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 to display. The computer program may be configured to run on a general purpose computer, an ASIC, or any other suitable device.

[0114] It will be readily understood that the components of the various embodiments of the present invention, as generally described and illustrated in the drawings 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 illustrated in the accompanying drawings is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments of the invention.

[0115] 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 means that the particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Thus, appearances of the phrases "in certain embodiments," "in some embodiments," "in 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.

[0116] 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 are or are included in any single embodiment of the present invention. Rather, language referring to features and advantages is understood to mean that the particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, descriptions of features, advantages, and similar language throughout this specification may, but do not necessarily, refer to the same embodiment.

[0117] 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.

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

Claims

1. 1. A computer program for performing robot access control and governance for robotic process automation (RPA), stored on a non-transitory computer readable medium, comprising: downloading access control and governance policy rules for an RPA designer application running locally on the computer system; Loading the access control and governance policy rules for the RPA designer application; Analyzing the RPA workflow activity of the RPA designer application against the access control and governance policy rules; If one or more analyzed activities of the RPA workflow violate the access control and governance policy rules, preventing the creation of an RPA robot or the publication of an RPA workflow until the RPA workflow satisfies the access control and governance policy rules; generating an RPA robot that executes the RPA workflow or publishing the RPA workflow if the analyzed activities of the RPA workflow comply with all required access control and governance policy rules; configured to cause at least one processor to execute 1. A computer program product comprising: a computer program product; and a processor; a processor that performs operations on the processor; and a processor that performs operations on the processor.

2. The computer program product of claim 1, wherein the access control and governance policy rules cannot be changed by a user of the RPA designer application as they are enforced by an operating system of a computing system on which the RPA designer application runs.

2. 2. The computer program product of claim 1, wherein the analysis of the RPA workflow activity includes verifying that one or more libraries accessed in the RPA workflow are included in a whitelist or are not included in a blacklist.

3. 2. The computer program product of claim 1, wherein the access control and governance policy rules include control over which applications and / or universal resource locators (URLs) can be automated and / or cannot be automated, control over which activities can be used and / or cannot be used in the RPA workflow, control over which packages can be used and / or cannot be used for the RPA workflow, or any combination thereof.

4. 10. The computer program product of claim 1, wherein the access control and governance policy rules are enforced at design time.

5. 2. The computer program product of claim 1 , wherein the access control and governance policy rules are defined for the RPA designer application based on organization, role, group, individual developer, or any combination thereof.

6. 2. The computer program product of claim 1, wherein the access control and governance policy rules are implemented via an installation script of the RPA designer application.

7. The computer program comprises: displaying a package management interface including packages accessible by activities of the RPA workflow; Preventing users of the RPA designer application from modifying authorized packages or adding unauthorized new packages based on the access control and governance policy rules; 2. The computer program product of claim 1, further configured to cause at least one processor to execute:

8. The computer program comprises: displaying a code analyzer configuration interface listing said access control and governance policy rules; Preventing users of the RPA designer application from modifying the access control and governance policy rules; 2. The computer program product of claim 1, further configured to cause at least one processor to execute:

9. 2. The computer program product of claim 1 , wherein the access control and governance policy rules include one or more application and / or universal resource locator (URL) restrictions, one or more package restrictions, one or more activity restrictions, one or more activity property requirements, or any combination thereof.

10. 1. A computer-implemented method for performing robot access control and governance for robotic process automation (RPA), comprising: downloading access control and governance policy rules for an RPA designer application running locally on the computer system; analyzing, by a code analyzer, an RPA workflow activity of the RPA designer application against the access control and governance policy rules; If one or more analyzed activities of the RPA workflow violate the access control and governance policy rules, preventing the creation of an RPA robot or the publication of the RPA workflow by the code analyzer until the RPA workflow satisfies the access control and governance policy rules; Including, The method, wherein the access control and governance policy rules cannot be changed by a user of the RPA designer application as enforced by an operating system of a computing system.

11. generating, by the RPA designer application, an RPA robot that executes the RPA workflow, or publishing the RPA workflow, if the analyzed activities of the RPA workflow comply with all required access control and governance policy rules. The method of claim 10 further comprising:

12. 11. The method of claim 10, wherein the access control and governance policy rules include control over which applications and / or universal resource locators (URLs) can be automated and / or cannot be automated, control over which activities can be used and / or cannot be used in the RPA workflow, control over which packages can be used and / or cannot be used for the RPA workflow, or any combination thereof.

13. displaying, by the RPA designer application, a package management interface including packages accessible by activities of the RPA workflow; preventing, by the RPA designer application, a user of the RPA designer application from modifying authorized packages or adding unauthorized new packages based on the access control and governance policy rules; The method of claim 10 further comprising:

14. displaying, by the RPA designer application, a code analyzer configuration interface listing the access control and governance policy rules; preventing, by the RPA designer application, a user of the RPA designer application from modifying the access control and governance policy rules; The method of claim 10 further comprising:

15. 11. The method of claim 10, wherein the access control and governance policy rules include one or more application and / or universal resource locator (URL) restrictions, one or more package restrictions, one or more activity restrictions, one or more activity property requirements, or any combination thereof.

16. 1. A computer program for performing robot access control and governance for robotic process automation (RPA), stored on a non-transitory computer readable medium, comprising: downloading access control and governance policy rules for an RPA designer application executing locally on the computer system from the conductor application; Loading the access control and governance policy rules for the RPA designer application; Analyzing the RPA workflow activity of the RPA designer application against the access control and governance policies; If one or more analyzed activities of the RPA workflow violate the access control and governance policy rules, preventing the creation of an RPA robot or the publication of an RPA workflow until the RPA workflow satisfies the access control and governance policy rules; generating an RPA robot that executes the RPA workflow or publishing the RPA workflow if the analyzed activities of the RPA workflow comply with all required access control and governance policy rules; configured to cause at least one processor to execute the access control and governance policy rules include one or more application and / or universal resource locator (URL) restrictions, one or more package restrictions, one or more activity restrictions, one or more activity property requirements, or any combination thereof; The access control and governance policy rules are defined for the RPA designer application based on organization, role, group, individual developer, or any combination thereof; 1. A computer program product comprising: a computer program product; and a processor; a processor that performs operations on the processor; and a processor that performs operations on the processor.

2. The computer program product of claim 1, wherein the access control and governance policy rules cannot be changed by a user of the RPA designer application as they are enforced by an operating system of a computing system on which the RPA designer application runs.

Images