Robotic access control and management for robotic process automation

Abstract

Robot access control and management for Robotic Process Automation (RPA) is disclosed. A code analyzer (such as a workflow analyzer) of an RPA designer application can read access control and management policy rules for the RPA designer application and analyze the activities of the RPA workflow of the RPA designer application according to the access control and management policy rules. When one or more analyzed activities of the RPA workflow violate the access control and management policy rules, the code analyzer will prevent the generation of an RPA robot or the release of the RPA workflow until the RPA workflow satisfies the access control and management policy rules. When the analyzed activities of the RPA workflow comply with all required access control and management policy rules, the RPA designer application can generate an RPA robot that implements the RPA workflow or release the RPA workflow.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Non-Provisional Patent Application No. 16 / 941,484, filed on July 28, 2020, which is a continuation-in-part of and claims the benefit of U.S. Non-Provisional Patent Application No. 16 / 924,499, filed on July 9, 2020. The subject matter of these prior-filed applications is incorporated herein by reference in their entirety. Technical Field

[0003] The present invention relates generally to Robotic Process Automation (RPA), and more particularly to robotic access control and management for RPA. Background Art

[0004] Certain actions taken by users of computing systems may violate laws or agreements in the United States and other countries, such as the EU General Data Protection Regulation (GDPR), the U.S. Health Insurance Portability and Accountability Act (HIPAA), and third-party terms of service. Fines for violating these laws or agreements can be significant. For example, under GDPR, lower-level violations could result in fines of €10 million or 2% of the violator's global annual revenue (not profit), whichever is greater. More serious violations could result in fines of €20 million or 4% of the violator's annual revenue, whichever is greater. These fines can be financially damaging or even fatal to a company. RPA presents unique challenges for access control and management. Therefore, improved RPA access control and management methods may 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, understood, or addressed by current RPA technology. For example, some embodiments of the present invention relate to robot access control and management for RPA.

[0006] In one embodiment, a computer program for performing robot access control and management for RPA is embodied on a non-transitory computer-readable medium. The computer program is configured to cause at least one processor to read access control and management policy rules of an RPA designer application and analyze activities of an RPA workflow of the RPA designer application based on the access control and management policy rules. When one or more analyzed activities of the RPA workflow violate the access control and management policy rules, the computer program is configured to cause at least one processor to block the generation of an RPA robot or the publication of an RPA workflow until the RPA workflow satisfies the access control and management policy rules. When the analyzed activities of the RPA workflow comply with all required access control and management policy rules, the computer program is configured to cause at least one processor to generate an RPA robot that implements the RPA workflow or publish the RPA workflow.

[0007] In another embodiment, a computer-implemented method for performing robot access control and management for RPA includes analyzing, by a code analyzer, activities of an RPA workflow applied by an RPA designer according to access control and management policy rules. When one or more analyzed activities of the RPA workflow violate the access control and management policy rules, the computer-implemented method includes preventing, by the code analyzer, the generation of an RPA robot or the publishing of the RPA workflow until the RPA workflow satisfies the access control and management policy rules.

[0008] In another embodiment, a computer program for performing robot access control and management for RPA is embodied 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 containing access control and management policy rules from a registry key of a computing system and download the file using the determined link, or download the management policy rules from a commander application. The computer program is further configured to cause the at least one processor to read the access control and management policy rules for an RPA designer application from the downloaded file and analyze the activities of an RPA workflow of the RPA designer application based on the access control and management policy rules. When one or more analyzed activities of the RPA workflow violate the access control and management policy rules, the computer program is configured to cause the at least one processor to block the generation of an RPA robot or the publication of the RPA workflow until the RPA workflow satisfies the access control and management policy rules. When the analyzed activities of the RPA workflow comply with all required access control and management policy rules, the computer program is configured to cause the at least one processor to generate an RPA robot that implements the RPA workflow or publish the RPA workflow. The access control and management 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 attribute requirements, or a combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to readily understand the advantages of certain embodiments of the present invention, 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. While it should be understood that these drawings depict only typical embodiments of the invention and, therefore, should not be considered to be limiting of the scope of the invention, the invention will be described and illustrated with additional specificity and detail through the use of the accompanying drawings, in which:

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

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

[0012] Figure 3 is an architectural diagram illustrating the relationship between designers, activities, and drivers according to an embodiment of the present invention.

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

[0014] Figure 5is an architectural diagram illustrating a computing system configured to perform robot access control and management for RPA according to an embodiment of the present invention.

[0015] Figure 6 is a diagram illustrating a method for using UiPath Studio according to an embodiment of the present invention. TM of Screen shot of the Registry Editor's folder view.

[0016] Figure 7 is a diagram showing Windows according to an embodiment of the present invention. Screenshot of a portion of the UI where the file SampleGovernanceRules.dll is installed in UiPath Studio TM in the rules folder.

[0017] Figure 8 is a screenshot illustrating a package management interface according to an embodiment of the present invention.

[0018] Figure 9 is a screenshot showing the upper right portion of the RPA designer application with the Send Feedback icon disabled according to an embodiment of the present invention.

[0019] Figure 10A -D is a screenshot showing a workflow analyzer settings interface according to an embodiment of the present invention.

[0020] Figure 11 is a screenshot showing an RPA designer application settings interface according to an embodiment of the present invention.

[0021] Figure 12A and 12B is a screenshot illustrating an RPA workflow according to an embodiment of the present invention.

[0022] Figure 13 An error list interface according to an embodiment of the present invention is shown.

[0023] Figure 14 is a screenshot illustrating a workflow analyzer interface according to an embodiment of the present invention.

[0024] Figure 15 is an architectural diagram illustrating a system for performing access control and management for RPA when a robot executes according to an embodiment of the present invention.

[0025] Figure 16 is a flow chart illustrating a process for performing robot access control and management for an RPA designer application according to an embodiment of the present invention.

[0026] Figure 17 is a flowchart illustrating a process for robot access control and management of RPA for executing an RPA robot according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] Some embodiments relate to robot access control and management for RPA. RPA management is the ability for an organization to establish policies to prevent users from developing RPA robots that could take actions that could harm the organization, such as violating GDPR, HIPAA, third-party application terms of service, etc. Because developers may create RPA robots that violate privacy laws, terms of service, etc. when performing their automations, some embodiments implement access control and management restrictions at the robot and / or robot design application level. In certain embodiments, this can provide a higher level of security and compliance for the RPA process development pipeline by preventing RPA developers from relying on unapproved software libraries that could pose a security risk or operate in a manner that violates policies, regulations, privacy laws, and / or privacy policies.

[0028] Some embodiments prevent RPA robots from taking actions that are permitted by the user but not by the robot. Traditionally, organizations can control what users can and cannot do through access controls on systems. However, in the context of RPA, and particularly attended automation, this control can break down. Robots perform tasks on behalf of users, which means backend systems cannot distinguish whether a robot or a user is accessing the system.

[0029] This can be problematic for several reasons. For example, backend systems can allow users to access data that could be misused. However, good system design generally makes it difficult for users to cause problems at any scale, as doing things they shouldn't be doing is slow and tedious. In contrast, if an RPA robot is used, the speed at which it executes can significantly increase the scale of data misuse or policy violations.

[0030] Consider the following example. An organization uses a customer relationship management (CRM) system to contact customers. The system fully supports various privacy options, such as supporting GDPR's "opt-out" and "forget me" policies and other user protection laws by checking whether the user has selected the "do not contact me" option and providing a link to the privacy policy and instructions requesting the organization to "forget them." The organization has chosen to grant most employees access to the CRM system, but has granted only a few employees permission to send emails within the system.

[0031] However, there are legitimate business purposes for a wider group of users to have access to customer profiles, including email addresses (for example, employees might create or edit erroneous information in the system, including customer email addresses, while working with them). Sending emails to customers without using the CRM system is a violation of organizational policy, but some employees want access to certain information and don't want to wait through various approval channels to obtain such permissions, or they prefer to have an appropriately authorized employee do so on their behalf. Without RPA bots, employees can still violate this policy. However, because manually copying and pasting email addresses one by one outside the system is cumbersome, even if employees violate this policy, the scale of the violation is small, mitigating the organization's risk if any violation occurs. However, RPA bots can extract this data many orders of magnitude faster than humans (e.g., thousands of times faster, tens of thousands of times faster, hundreds of thousands of times faster, millions of times faster, etc.) to create and send emails. Therefore, while a user might manually send 5-10 emails that violate policy and put the company at risk of violating GDPR customer "opt-out" requirements, a user who creates a bot for this purpose can send a large number of violating emails.

[0032] As another example, consider a healthcare organization that uses a tightly protected system to store all data in a HIPAA-compliant manner. Employees can legally access this data and use it for their jobs within the context of appropriate applications. An employee frustrated with the inefficiencies of the system might want to write a program that extracts patient data to his or her desktop computer without protection. Now, this is a violation of HIPAA and if something happens to that data, like an employee’s computer being stolen and accessed, it could expose the organization to significant financial and legal liability.

[0033] As another example, consider a situation where a third-party app or service's terms of service prohibit the use of automation for work purposes. If an employee chooses to write an RPA bot that performs work in violation of those terms of service, the company could be held legally liable.

[0034] These and other issues can pose significant risks to organizations adopting RPA robots. However, some embodiments reduce or eliminate security and compliance risks for developers by preventing them from using unapproved libraries and active references. RPA developers (whether trained RPA developers (e.g., using UiPath Studio) TM ) or untrained citizen developers (e.g., using UiPath StudioX TM))You can add references to libraries that are considered unsafe or work in a way that violates policy / regulation.

[0035] Consider the following example. Some countries do not allow the installation of technologies developed in countries that are considered unfriendly on their computing systems. However, some common libraries developed in these unfriendly countries are used in RPA (e.g. OCR engine). Although developers can choose to make these libraries unavailable on their computing systems by default, they cannot explicitly prevent users from relying on and incorporating these libraries into RPA projects. Although RPA developers' internet access may be blocked (which is undesirable for many reasons when developing software), developers can still bring unapproved libraries into computing systems through another mechanism, such as a Universal Serial Bus (USB) stick.

[0036] Another example is that many financial institutions enforce strict policies on what information can or cannot leave their internal networks and firewalls. In the modern era, many RPA libraries (called via RPA activities) work by communicating with servers on public clouds, such as Document understanding activities. These financial institutions were concerned that users wouldn't realize these activities were not allowed, potentially sending sensitive data outside the company firewall. However, there were no pre-existing effective options to prevent this from happening.

[0037] Another issue is preventing large-scale RPA from overwhelming the system. One of the reasons for the huge success of RPA is that it can automate legacy systems without having to upgrade those systems. Because legacy systems were not designed to be automated, they may be designed and configured to handle interactions at a speed at which humans can work. However, legacy applications are not always able to keep up with the speed at which RPA robots can interact with the system. Robots that are not designed to operate within these constraints can ultimately overwhelm the overwhelmed legacy system with faster requests than the legacy system can handle, essentially performing an unexpected denial of service (DoS) attack on the system. Although UiPath Studio TM Settings exist in RPA to implement delays between activities, but there is currently no centralized enforcement mechanism to ensure that developers use these settings when working on legacy systems that cannot run at the speed of RPA robots.

[0038] Another issue is ensuring that organizational policies are adhered to. Many organizations have specific rules that they want to apply to automation. Examples include enforcing that emails created by automation are sent only to internal employees and not to external recipients, enforcing that all emails created by automation are saved as drafts and not sent without human review, and so on. Without proper management, RPA robots can violate these policies.

[0039] To address access control and management issues that may occur in RPA, some embodiments provide organizations with the ability to define and implement management policies. For example, this can be achieved through a JavaScript Object Notation (JSON) file that defines what the RPA robot can and / or cannot access. In some embodiments, an organization can control which applications and / or universal resource locators (URLs) can and / or cannot be automated, which activities can and / or cannot be used, which packages (e.g., libraries) can and / or cannot be used, provide the ability to create and deploy custom rules for extending management capabilities, provide various RPA designer application settings that can control, for example, which package feeds a user can use to install a library, and so on.

[0040] In some embodiments, management can be performed at design time (i.e., when developers are building, testing, and modifying RPA robotic workflows). However, this can make it difficult or impossible to enforce certain policies. For example, it can be difficult or impossible to enforce a policy where the value to which the policy is to be applied is only known at runtime. For example, if an organization wants to have a policy that prevents access to certain websites, design-time analysis should be able to know the URLs to be marked. However, in some embodiments, the RPA program can be constructed so that values ​​are loaded from dynamic sources (such as external files or prompts asking the user). In this case, design-time analysis is not sufficient because the policy-violating values ​​are not known at design time. Another example is if an organization wants to block emails that are automatically sent to customers outside the organization, but the list of email addresses comes from a spreadsheet. In this case, the email is not known at design time, but is a dynamic input to the system that should be evaluated at runtime.

[0041] In some embodiments, management is implemented at runtime, in addition to or instead of design-time implementation. For example, this can be accomplished via a server-side application for configuring and deploying policies. For example, policies can be automatically sent to user computing systems when these computing systems connect to a server-side commander application. The RPA designer application can automatically insert code into RPA robots to force them to acquire these policies and operate according to them.

[0042] In some embodiments, controls can be defined for the RPA designer application based on organizations, roles, groups, individual developers, and so on, to control what developers can do when developing RPA bots. Policies can be defined and controls implemented to control what RPA bots can do when running automations. Such embodiments can enable organizations to better meet compliance and management requirements related to laws, regulations, agreements, and corporate policies.

[0043] In some embodiments, local files can only be modified by administrators. Therefore, non-administrator users should not be able to overwrite or change these files. Package feeds can be locked so that only the desired feed is available and no other feeds can be added. This can prevent users from using packages obtained from elsewhere. In some embodiments, the "Send Feedback" tool can be disabled as part of the policy.

[0044] As used in this article, a "package feed" is a location (remote or local) that contains access to additional libraries that developers can choose to install to gain additional functionality for their automation projects. A library, as used in this article, is a package containing computer code that provides additional functionality (e.g., activities) to a project. An example of a package feed is UiPath Connect TM Marketplace. This is an open location where community members can upload libraries containing custom activities they have written. If If an RPA developer wants to use these features, the developer can browse and add library references to their project. UiPath GSuite TM Activity is an example of a library. UiPathStudio TM The default installation does not enable RPA developers to use GSuite TM However, developers can install GSuite TM Activity Library, which now enables the project to use activities to interact with Gsuite TM Use together (for example, Sheets, Drive, etc.).

[0045] In some embodiments, a code analyzer, such as a program analyzer or an RPA workflow analyzer, is provided as an audit function for the RPA Designer application. The workflow analyzer can define the content that users are allowed to access when running the RPA Designer application and can enforce policies. For example, it can specify the URLs that users are allowed to access, restrict certain URLs, and so on.

[0046] As used herein, a "code analyzer" is computer code that runs a series of rules that check the code written by the RPA user and generates feedback (e.g., messages, warnings, errors, etc.) when the application does not meet the rules. In some embodiments, the code analyzer is provided by the vendor of the RPA application (e.g., Provided or written by customers using RPA applications. UiPath Studio TM The "App / Url Restrictions" rule in the Admin Policy is an example of a Code Analyzer rule that allows organizations to define which desktop applications and website URLs can or cannot be used in automation projects. If a user violates one of these rules, they will receive a notification with the severity specified in the management policy. In some embodiments, this is typically an error that will prevent the automation from being published or run.

[0047] Certain embodiments may be deployed for Robotic Process Automation (RPA). Figure 1 1 is an architectural diagram illustrating an RPA system 100 according to an embodiment of the present invention. The RPA system 100 includes a designer 110 that allows developers to design and implement workflows. The designer 110 can provide solutions for application integration and automation of third-party applications, managing information technology (IT) tasks, and business IT processes. The designer 110 can support the development of automation projects, which are graphical representations of business processes. In short, the designer 110 supports the development and deployment of workflows and robots.

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

[0049] Some types of workflows may include, but are not limited to, sequences, flow charts, FSMs, and / or global exception handlers. Sequences may be particularly suitable for linear processes, allowing for the flow from one activity to another without cluttering the workflow. Flow charts may be particularly suitable for more complex business logic, enabling the integration of decisions made in a more diverse manner through multiple branching logic operators and the connection of activities. FSMs may be particularly suitable for larger workflows. FSMs may use a limited number of states in their execution, which are triggered by conditions (i.e., transitions) or activities. Global exception handlers may be particularly suitable for determining workflow behavior and for debugging processes when encountering execution errors.

[0050] Once a workflow is developed in the designer 110, the execution of the business process is orchestrated by a conductor 120, which orchestrates one or more robots 130 that execute the workflow developed in the designer 110. One commercial example of an embodiment of the conductor 120 is the UiPath Orchestrator TM The director 120 supports the management of the creation, monitoring, and deployment of resources in the environment. The director 120 can serve as an integration point or one of the aggregation points with third-party solutions and applications.

[0051] The commander 120 can manage a fleet of robots 130, connecting and executing them from a centralized point. The 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 for development and testing purposes), and non-production robots (similar to attended robots 132, but 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 commander 120 to centralize process deployment and recording media. Attended robots 132 can assist human users with various tasks and can be triggered by user events. In some embodiments, processes cannot be started from the commander 120 on this type of robot and / or cannot be run from a locked screen. In some embodiments, attended robots 132 can only be started from the robot tray or from a command prompt. In some embodiments, attended robots 132 should only be operated under human supervision.

[0052] Unattended robots 134 run in an unattended manner in a virtual environment and can automate many processes. Unattended robots 134 can be responsible for remote execution, monitoring, scheduling, and providing support for work queues. In some embodiments, debugging for all robot types can be run in the designer 110. Both attended and unattended robots can automate various systems and applications, including but not limited to mainframes, web applications, VMs, enterprise applications (e.g., and computing system applications (such as desktop and notebook applications, mobile device applications, wearable computer applications, etc.).

[0053] The commander 120 may have various capabilities including, but not limited to, provisioning, deployment, versioning, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning may include creating and maintaining a connection between a robot 130 and a commander 120 (e.g., a web application). Development may include ensuring that a package version is correctly delivered to an assigned robot 130 for execution. In some embodiments, versioning may include the management of a unique instance of a process or configuration. 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 into a database (e.g., a SQL database) and / or another storage mechanism (e.g., It provides the ability to store and quickly query large data sets.) Director 120 can 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 runs the workflow built into the designer 110. One commercial example of some embodiments of the robot(s) 130 is UiPath Robots TM In some embodiments, the robot 130 is installed by default with Microsoft As a result, such robots 130 can open interactive session, and has Permissions for services.

[0055] In some embodiments, a robot 130 can be installed in user mode. This means that for such a robot 130, it has the same permissions as the user who installed the given robot 130. This feature can also be used for high-density (HD) robots, which ensure that each machine is fully utilized to its maximum potential. In some embodiments, any type of robot 130 can be deployed in an HD environment.

[0056] 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 the robot service managed by the SCM, the user mode robot service, the executor, the agent, and the command line. The SCM starts a session and acts as a delegate between the director 120 and the execution host (i.e., the computing system on which the robot 130 is executed). These services are trusted by the robot 130 and manage the credentials of the robot 130. The console application is launched by the SCM under the local system.

[0057] In some embodiments, user-mode robot services manage and monitor The user mode robot service can be trusted by the robot 130 and manage the credentials of the robot 130. In the case that the SCM managed robot service is not installed, Applications can be launched automatically.

[0058] The actuator can be The executor can execute the workflow. The executor can know the dots per inch (DPI) setting of each monitor. The agent can be A Presentation Foundation (WPF) application that displays available jobs in a system tray window. An agent can be a client of the service. The agent can request to start or stop jobs and change settings. A command line is a client of the service. The command line is a console application that can request to start jobs and wait for their output.

[0059] Keeping the components of the robot 130 generally separate as explained above helps developers, support users, and computing systems more easily run, identify, and track what each component is executing. Special behaviors can be configured on a per-component basis in this way, such as setting different firewall rules for executors and services. In some embodiments, the executor can always be aware of the DPI setting of each monitor. As a result, workflows can be executed at any DPI regardless of the configuration of the computing system that created the workflow. In some embodiments, projects from the designer 110 can also be independent of the browser zoom level. In some embodiments, DPI can be disabled for applications that are DPI unaware or intentionally marked as unaware.

[0060] Figure 2 is an architectural diagram illustrating an RPA system 200 deployed according to an embodiment of the present invention. In some embodiments, the RPA system 200 may be Figure 1The RPA system 100 may be a part of the RPA system. 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, 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 running the process. Figure 2 As shown in , several business items can be run simultaneously. In this embodiment, the agent 214 (e.g. The service) is the single point of contact for all executors 212. All messages in this embodiment are logged to the director 230, which further processes these messages via the database server 240, the indexer server 250, or both. Figure 1 As discussed, effector 212 may be a robotic component.

[0061] In some embodiments, a robot represents an association between a machine name and a user name. A robot can manage multiple executors simultaneously. In a computing system that supports multiple interactive sessions running simultaneously (e.g., Server 2012), multiple robots can run simultaneously, each with a separate In conversation. This is referred to as the HD robot above.

[0062] The agent 214 is also responsible for communicating the robot's status (e.g., periodically sending "heartbeat" messages indicating that the robot is still functioning) and downloading the required versions of packages to be executed. In some embodiments, communication between the agent 214 and the commander 230 is always initiated by the agent 214. In a notification scenario, the agent 214 can open a WebSocket channel that is later used by the commander 230 to send commands to the robot (e.g., start, stop, etc.).

[0063] On the server side, it includes a presentation layer (web application 232, Open Data Protocol (OData) Representational State Transfer (REST) ​​application programming interface (API) endpoint 234, and notification and monitoring 236), a service layer (API implementation / business logic 238), and a persistence layer (database server 240 and indexer server 250). The commander 230 includes the web application 232, the OData REST API endpoint 234, notification and monitoring 236, and the API implementation / business logic 238. In some embodiments, most actions performed by a user in the commander 220 interface (e.g., via the browser 220) are performed by calling various APIs. Without departing from the scope of the present invention, 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 unattended, etc. The web application 232 is the visual layer of the server platform. In this 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 this embodiment, a user interacts with a web page from web application 232 via browser 220 to perform various actions to control commander 230. For example, a user can create a group of robots, assign packages to robots, analyze logs for each robot and / or each process, start and stop robots, etc.

[0064] In addition to the web application 232, the director 230 also includes a service 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. In this embodiment, the agent 214 is an overseer of one or more robots on a client computer.

[0065] In this embodiment, the REST API covers configuration, logging, monitoring, and queuing functionality. In some embodiments, the configuration endpoint can be used to define and configure application users, permissions, robots, assets, releases, and environments. The logging REST endpoint can be used to log various information, such as (for example) errors, explicit messages sent by the robot, and other environment-specific information. If the start job command is used in the commander 230, the deployment REST endpoint can be used by the robot to query the package version that should be executed. The queueing REST endpoint can be responsible for queue and queue item management, such as adding data to the queue, getting transactions from the queue, setting the status of transactions, etc.

[0066] The monitoring REST endpoint can monitor the web application 232 and the agent 214. The notification and monitoring API 236 can be a REST endpoint for registering the agent 214, delivering configuration settings to the agent 214, and for sending / receiving notifications from the server and the agent 214. In some embodiments, the notification and monitoring API 236 can also use WebSocket communication.

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

[0068] In some embodiments, the optional indexer server 250 stores information logged by the robot and indexes the information. In some embodiments, the indexer server 250 can be disabled through a configuration setting. In some embodiments, the indexer server 250 uses It is an open source full-text search engine. Messages logged by the robot (e.g., using activities such as logging messages or writing lines) can be sent to the indexer server 250 via the logging REST endpoint(s), where they are indexed for future use.

[0069] Figure 33 is an architectural 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, developers use the designer 310 to develop workflows executed by robots. The workflows may include user-defined activities 320 and UI automation activities 330. Some embodiments are capable of identifying non-textual visual components in an image, referred to herein as computer vision (CV). CV activities associated with such components may include, but are not limited to, click, type, get text, hover, element presence, refresh range, highlight, and the like. In some embodiments, click uses, for example, CV, optical character recognition (OCR), fuzzy text matching, and multi-anchors to identify an element and click on the element. Type can use the aforementioned methods to identify an element and the type within the element. Get text can identify the location of specific text and scan the location using OCR. Hover can identify an element and hover over it. Element presence can use the techniques described above to check whether an element is on the screen. In some embodiments, there may be hundreds or even thousands of activities that can be implemented in the designer 310. However, any number and / or types of activities may be available without departing from the scope of the present invention.

[0070] UI automation activities 330 are a subset of special lower-level activities (e.g., CV activities) written in lower-level code and facilitate interaction with the screen. UI automation activities 330 support these interactions via drivers 340 that allow the robot to interact with the 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 can interact with the OS at a low level to find hooks, monitor keys, etc. Drivers can help For example, the “click” activity plays the same role in these different applications via the driver 340.

[0072] Figure 4 4 is an architectural diagram illustrating an RPA system 400 according to an embodiment of the present invention. In some embodiments, the RPA system 400 may be or include Figure 1 and / or Figure 2 The RPA system 100 and / or 200 of the present invention is shown. The RPA system 400 includes multiple client computing systems 410 running robots. The computing systems 410 can communicate with a commander computing system 420 via web applications running on them. The commander computing system 420 can in turn communicate with a database server 430 and an optional indexer server 440.

[0073] Relative to Figure 1 and Figure 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 director may run a server-side application that communicates with a non-web-based client software application on a client computing system.

[0074] Figure 5 is an architectural diagram illustrating a computing system 500 configured to perform robotic access control and management for RPA according to an embodiment of the present invention. In some embodiments, computing system 500 may be one or more of the computing systems depicted and / or described herein. Computing system 500 includes a bus 505 or other communication mechanism for transmitting information, and processor(s) 510 coupled to bus 505 for processing information. Processor(s) 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(s) 510 may also have multiple processing cores, and at least some of the cores may be configured to perform specific functions. In some embodiments, multi-processing may be used. In certain embodiments, at least one of processor(s) 510 may be a neuromorphic circuit including processing elements that mimic biological neurons. In some embodiments, neuromorphic circuits may not require the typical components of the von Neumann computing architecture.

[0075] The computing system 500 also includes a memory 515 for storing information and instructions to be executed by the processor(s) 510. The memory 515 can be composed 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 any combination thereof. Non-transitory computer-readable media can be any available media that can be accessed by the processor(s) 510 and can include volatile media, non-volatile media, or both. The media can also 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 communication device 520 can be configured to use frequency division multiple access (FDMA), single carrier FDMA (SC-FDMA), time division multiple access (TDMA), code division multiple access (CDMA), orthogonal frequency division multiple access (OFDM), orthogonal frequency division multiple access (OFDMA), global system for mobile (GSM) communications, general packet radio service (GPRS), universal mobile telecommunications system (UMTS), cdma2000, wideband CDMA (W-CDMA), high speed downlink packet access (HSDC), etc., without departing from the scope of the present invention. In some embodiments, the communication device 520 may include one or more antennas that are singular, array, phased, switched, beamformed, beamsteered, combinations thereof, and / or any other antenna configurations without departing from the scope of the present invention.

[0077] The processor(s) 510 are 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, 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, or the like using resistive, capacitive, surface acoustic wave (SAW) capacitive, infrared, optical imaging, dispersive signal technology, acoustic pulse recognition, frustrated total internal reflection, or the like. Any suitable display device and tactile I / O may be used without departing from the scope of the present invention.

[0078] A keyboard 530 and a cursor control device 535 (such as a computer mouse, touchpad, etc.) are further coupled to bus 505 to enable a user to interface with computing system 500. However, in some embodiments, a physical keyboard and mouse may not be present, and the user may interact with the device solely through display 525 and / or touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In some embodiments, no physical input device and / or display is present. For example, a user may interact with computing system 500 remotely via another computing system in communication therewith, or computing system 500 may operate autonomously.

[0079] Memory 515 stores software modules that provide functionality when executed by processor(s) 510. The modules include an operating system 540 for the computing system 500. The modules also include a robot access control and management module 545 configured to perform all or part 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.

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

[0081] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising a custom very large scale integrated (VLSI) circuit or gate array, or an off-the-shelf semiconductor (such as a logic chip, transistor, or other discrete component). A module can also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, or the like.

[0082] Modules may also be implemented at least in part in software for execution by various types of processors. For example, an identified unit of executable code may include one or more physical or logical blocks of computer instructions, which may be organized, for example, into objects, procedures, or functions. Nevertheless, the executable file for an identified module need not be physically located in one place, but may include disparate instructions stored in different locations which, when logically combined together, comprise the module and achieve the intended purpose of the module. Additionally, a module may be stored on a computer-readable medium, which may be, for example, a hard drive, a flash memory device, RAM, a magnetic tape, and / or any other such non-transient computer-readable medium for storing data, without departing from the scope of the present invention.

[0083] In practice, a module of executable code can be a single instruction or many instructions, and can even be distributed over several different code segments, between different programs, and across multiple memory devices. Similarly, operational data can be identified and illustrated herein as within a module, and this operational data can be implemented in any suitable form and organized within a data structure of any suitable type. Operational data can be collected as a single data set, or can be distributed over different locations included on different storage devices, and can exist at least in part only as electronic signals on a system or network.

[0084] In some embodiments, management information for the RPA designer application can be stored in files that cannot be edited by the RPA developer. For example, Figure 6 The RPA Designer application is shown Screenshot of the view of the folder 600 of the registry editor (in this case UiPath Studio TM). Under the path Computer\HKEY_CURRENT_USER\Software\UiPath, a registry key named GovernanceSource 610 is set (for example, when the RPA Designer application is installed) which points to a remote policy file available via an associated link 620. The policy available at this link can be read-only to the computing system and will be used by the RPA Designer application or RPA Robot to control certain permissions. The policy can be defined at the individual user level, group level, role level, organization level, etc. By including policies via remote links, the policy can be updated whenever needed and the updated policy will be automatically accessed by the consuming RPA Robot and / or RPA Designer application. In this example, the policy file provides the ability to define different policy groups for development profiles. In some embodiments, different policies can be set for experienced programmers and citizen developers who may not have programming knowledge, as these developers may have different needs. The following includes UiPathStudio TM This example shows a portion of a sample policy file that defines rules for development, business, and StudioPro users. In this example, the bold text indicates where additional rules or counters can be defined.

[0085]

[0086]

[0087]

[0088]

[0089]

[0090]

[0091]

[0092]

[0093]

[0094]

[0095] It should be noted that while the rules and counters shown here are the same for each user type, this is not necessarily the case, nor is it typically in actual implementations. It should also be noted that in some embodiments, while registry keys are used to obtain a file containing control and management policy rules, in some embodiments, a file or other policy information format is passed from the commander application. In some embodiments, the server UI allows the administrator to define a policy, which will be passed over the connection (e.g., as a .json payload). However, in some embodiments, the policy is not necessarily a "file" explicitly written by the administrator.

[0096] In some embodiments, custom management rules can be developed as part of the workflow analyzer process. For example, in some embodiments, an installation script of an RPA designer application can install custom management rules to a user's computing system. See, e.g. Figure 7 Screen shot 700 shows Part of the UI where the file SampleGovernanceRules.dll 710 is installed in UiPath Studio TM Because SampleGovernanceRules.dll 710 is located in the Program Files folder, only administrators can modify it. End users who do not have administrative privileges on their computers cannot. Therefore, end users without such privileges will have administrative policy and will not be able to override or change it.

[0097] Figure 8 8 is a screenshot illustrating a package management interface 800 according to an embodiment of the present invention. In this embodiment, the package feed for developers has been locked. More specifically, developers only have access to the official package feed 810, and developers cannot enable or disable the official package feed 810. Developers also cannot enter a name 820 or source 830 for a user-defined package, use the Add button 840 to add a user-defined package, or use the Save button 850 to save modified package settings. This prevents developers from acquiring active packages from anywhere the organization does not want them to.

[0098] Some organizations may be concerned that developers may leak sensitive information to the provider of the RPA designer application during the development process. Therefore, in some embodiments, as a policy issue, the send feedback function is disabled in the RPA designer application. See, for example, Figure 9 , which is a screenshot showing the upper right portion 900 of the RPA designer application with the send feedback icon disabled and a message 910 indicating that this is the case.

[0099] Figure 10A is a screenshot illustrating a workflow analyzer settings interface 1000 according to an embodiment of the present invention. In some embodiments, the workflow analyzer settings are from a policy configuration file. Figure 10A As can be seen in FIG, various rules are listed in the rule pane 1002 with corresponding codes, names, scopes, and default actions. Specific setting options for the selected rule are shown in the rule setting pane 1004.

[0100] In this embodiment, there are four types of access restrictions - application / URL restrictions 1010, package restrictions 1020, activity restrictions 1030, and activity attribute requirements 1040. However, any number and / or type of access restrictions may be used without departing from the scope of the present invention. Application / URL restrictions 1010 control which applications and / or URLs a user of the RPA designer application is allowed and / or not allowed to use. For example, referring to Figure 10B If any applications are prohibited, the prohibited applications will be shown in the prohibited applications field 1012, and the allowed applications will be shown in the allowed applications field 1014. If the user scrolls down, the prohibited URLs and allowed URLs will also be shown in the corresponding fields. Naturally, a given application or URL cannot be both prohibited (i.e., blacklisted) and allowed (i.e., whitelisted). In some embodiments, if allowed applications are specified, the user can only use those applications. In this embodiment, these fields are read-only.

[0101] Package restrictions 1020 control which packages are prohibited. For example, refer to Figure 10C , prohibited packages can be listed in prohibited packages field 1022. In some embodiments, this can limit the categories of packages that the organization does not want users to access. In some embodiments, allowed packages can be listed in addition to or instead of prohibited packages field 1022. In this embodiment, prohibited packages field 1022 is read-only.

[0102] Activity restrictions 1030 control which activities a user is allowed and / or not allowed to use. Figure 10D If any activities are prohibited, the prohibited activities will be shown in the prohibited activities field 1032; if any activities are listed as allowed, the allowed activities will be shown in the allowed activities field 1034. Thus, if restrictions are not required at the level of the entire package, but certain activities should not be allowed and / or only certain activities should be allowed, this can be specified via activity restrictions 1030. In this embodiment, these fields are read-only.

[0103] In some embodiments, if no activity is specified as allowed and / or not allowed, then all activities are allowed by default. In some embodiments, only allow or disallow are implemented, not both. For example, in such embodiments, if both allowed and disallowed activities are included, the "allow" set may take precedence and the disallow set may be ignored because the specifically specified allowed activities are considered more restrictive.

[0104] Active Attribute Requirement 1040 allows organizations to define custom rules. Return Figure 10A , the value of the rule configuration field 1042 is "Property:*Draft*,Activity:*MailX,Value:True". In this example, for TM Zhongyu For MailX activities used with this rule, the Draft property must be set to "True". As with other restriction types, the rule configuration field 1042 is read-only for users. Figure 10A As you can see with -D, some rules are set to give an error by default, while other rules are set to give a warning.

[0105] like Figure 11 As shown in the screenshot, in the RPA Designer application settings interface 1100, various settings can be implemented for RPA workflow design. In this case, workflows must pass through the Workflow Analyzer before running and before publishing. This implementation can be seen in settings 1110 and 1120, respectively. This means that for the management policy set as rules in the Workflow Analyzer settings interface 1000, the workflow must comply with all rules set to throw errors if non-compliance occurs.

[0106] Figure 12A and 12B 12 is a screenshot showing an RPA workflow 1200 according to an embodiment of the present invention. A user is trying to automate content at a link 1210 (here, "https: / / www.uipath.com / "). Consider the following scenario: based on the rules of the workflow analyzer, this is an unallowed URL. Also consider the scenario where there is a rule requiring the "Save as draft" checkbox 1220 to be selected. When the user attempts to validate the workflow, an error list interface 1300 appears in this embodiment. See Figure 13 The error list interface 1300 indicates that the "Save as Draft" property does not comply with the organization's guidelines and that https: / / www.uipath.com / is not an allowed application defined by the organization for UI Automation.

[0107] Based on the above, in some embodiments, policies can be defined based on the user's technical maturity. TM (which can be used by individuals with any programming knowledge or even lack of it) compared to UiPath Studio TM (Used by RPA developers with programming knowledge) Define more complex rules. For example, more technically sophisticated users of the RPA Designer application have access to more package feeds, the ability to disable feeds, a richer set of rules, and so on.

[0108] consider Figure 14 Workflow Analyzer interface 1400. In this case, a rich set of rules is provided to RPA developers, including custom rules. Custom package version requirement rules (Package VersionRequirements) 1410 are implemented. 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 configuration field 1412, and an error will be thrown if other versions are referenced. This requires that UiPath.Mail.Activities must only be of this version. Additionally, the Allow Pre-Release Package field (AllowPrelease Package (True / False)) 1414 is set to "True".

[0109] In light of the above, in some embodiments, management is enabled as part of the RPA Designer application's installation script. In certain embodiments, a remote policy file can be set up via a registration key so that the RPA Designer application always has the current version of the management policy. Alternatively, the policy file can be located 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.

[0110] In some embodiments, separate policies are implemented for technically savvy users and users without solid programming knowledge. In some embodiments, different policies are applied based on a given user, user role, user group, etc. In some embodiments, users are unable to run or publish non-compliant RPA workflows.

[0111] Figure 1515 is an architectural diagram illustrating a system 1500 for performing access control and management for RPA during robot execution, according to an embodiment of the present invention. System 1500 includes user computing systems, such as a desktop computer 1502, a tablet computer 1504, and a smartphone 1506. However, any desired computing system may be used without departing from the scope of the present invention, including but not limited to smartwatches, laptop computers, Internet of Things (IoT) devices, vehicle computing systems, and the like.

[0112] Each computing system 1502, 1504, and 1506 runs an RPA robot 1510 that performs one or more automations. However, in some embodiments, computing systems 1502, 1504, and 1506 may execute different robots. While executing its processes, the RPA robot requests certain information from a server 1530 (e.g., by sending a request to a commander application running on the server 1530) via a network 1520 (e.g., a local area network (LAN), a mobile communication network, a satellite communication network, the Internet, or any combination thereof). For example, without departing from the scope of the present invention, the RPA robot 1510 may communicate with the server 1530 to send or receive data (e.g., push / pull from a data queue), retrieve securely stored credentials / asset information (e.g., usernames / passwords, access tokens, etc.), log information from activities (e.g., execution logs), report "heartbeat status" (e.g., RPA robot 1510 is running correctly), check for "orchestration commands" (e.g., "Run this command," "Abort / cancel execution," etc.), or any other suitable communication. In some embodiments, server 1530 may run a director application and data may be sent periodically as part of a heartbeat message. Server 1530 retrieves access control and management rules for a given robot from one or more files 1532, database 1540, or both.

[0113] Server 1530 checks the action to be performed by Robot 1510 and / or the information requested by the RPA Robot against access control and management rules. If Robot 1510 is allowed to take the action or obtain the information, Server 1530 provides the requested information to Robot 1510 and / or sends the information to a verification application on the corresponding computing system to indicate that the action is acceptable. If not, Server 1530 does not provide the requested information to Robot 1510 and / or sends the information to the verification application on the corresponding computing system to indicate that the action attempted by Robot 1510 is unacceptable. In some embodiments, the verification application may terminate the process associated with Robot 1510.

[0114] In some embodiments, the disallowed actions may be actions that are allowed for a human user but not for an RPA robot. In some embodiments, the server 1530 may verify that the robot 1510 has been paused for a sufficient period of time with respect to one or more legacy systems and may delay obtaining information requested by the robot or accepting new information requests from the robot until the delay period expires. In some embodiments, management is implemented at runtime in addition to design-time implementation. In some embodiments, for example, when computing systems 1502, 1504, 1506 connect to a server-side commander application of server 1530, policies may be automatically sent to computing systems 1502, 1504, 1506. In some embodiments, the RPA designer application may automatically insert code into the RPA robots, forcing them to obtain these policies and operate according to these policies.

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

[0116] In some embodiments, access control and management policy rules include: controls on which applications and / or universal resource locators (URLs) can and / or cannot be automated, controls on which activities can and / or cannot be used in RPA workflows, controls on which packages can and / or cannot be used in RPA workflows, or a combination thereof. In some embodiments, access control and management policy rules are defined for the RPA designer application based on organizations, roles, groups, individual developers, or a combination thereof. In some embodiments, when the access control and management policy rules are implemented by the operating system of the computing system on which the RPA designer application is executed, they cannot be modified by a user of the RPA designer application. In some embodiments, the access control and management 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 attribute requirements, or a combination thereof.

[0117] In some embodiments, at 1620, various interfaces may be displayed, and modifications by unauthorized users may be prevented. For example, a package management interface may be displayed that includes packages accessible by RPA workflow activities, and based on access control and management policy rules, users of the RPA designer application may be prevented from modifying permitted packages or adding new, unauthorized packages. As another example, a workflow analyzer setup interface may be displayed that lists access control and management policy rules, and users of the RPA designer application may be prevented from modifying the access control and management policy rules.

[0118] At 1625, the activities of the RPA workflow of the RPA designer application are analyzed according to the access control and management policy rules. In some embodiments, the analysis of the RPA workflow activities includes verifying whether one or more libraries to be accessed in the RPA workflow activities are included in a whitelist or are not included in a blacklist. If the verification at 1630 succeeds (i.e., the RPA workflow activities comply with all required access control and management policy rules), at 1635, an RPA robot implementing the RPA workflow is generated or the RPA workflow is published. However, if the verification at 1630 fails (i.e., one or more analyzed activities of the RPA workflow violate the access control and management policy rules), the generation of the RPA robot or the publication of the RPA workflow is blocked until the RPA workflow satisfies the access control and management policy rules. In this embodiment, at 1640, the RPA workflow analyzer / RPA designer application waits for the user to modify the RPA workflow. The process then returns to step 1625 to analyze the modified activities of the RPA workflow. In some embodiments, only the modified activities are analyzed again.

[0119] Figure 17 17 is a flow chart illustrating a process 1700 for controlling and managing RPA robot access for an executing RPA robot according to an embodiment of the present invention. The process begins at 1710 by checking the actions to be performed by the RPA robot and / or the information requested by the RPA robot against access control and management rules. For example, this check can be performed by a client-side or server-side authentication application. If the RPA robot is allowed 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 authorized at 1730. The authentication application then waits at 1740 until the next RPA robot communication is received.

[0120] If the RPA robot is not permitted to take action and / or obtain information at 1720, the verification application prevents the RPA robot from obtaining information and / or taking action at 1750. In some embodiments, a notification that access to information and / or action is not permitted may be sent to the RPA robot at 1760. In some embodiments, the verification application may automatically end execution of the RPA robot (e.g., by terminating a process associated with the RPA robot) at 1770.

[0121] In some embodiments, the disallowed action may be an action that is allowed for a human user but not allowed for an RPA robot. In some embodiments, the verification application may verify that the RPA robot is paused from one or more legacy systems for a sufficient period of time and may delay obtaining information requested by the RPA robot or accepting a new information request from the RPA robot until the delay period expires.

[0122] According to an embodiment of the present invention, Figure 16 and Figure 17 The process steps performed in the embodiment of the present invention may be performed by a computer program encoded with instructions for causing a processor(s) to perform Figure 16 and Figure 17 The computer program may be implemented on a non-transitory computer readable medium. The computer readable medium may be, but is not limited to, a hard drive, a flash memory device, a RAM, a magnetic tape, and / or any other such medium or combination of media for storing data. The computer program may include a program for controlling the processor(s) of a computing system (e.g. Figure 5 (a plurality of) processors 510 of the computing system 500) to implement Figure 16 and Figure 17 The coded instructions for all or part of the process steps described in the present invention may also be stored on a computer-readable medium.

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

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

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

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

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

[0128] It will be readily understood by those skilled in the art that the invention as described above may be practiced utilizing steps in a different order and / or utilizing hardware elements in configurations different from those disclosed. Thus, while the 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 configurations will be apparent while remaining within the spirit and scope of the invention. Therefore, reference should be made to the appended claims for determining the limits and boundaries of the invention.

Claims

1. A computer-implemented method for performing runtime robotic access control and management for Robotic Process Automation (RPA), comprising: determining, based on access control and management rules, whether the RPA robot is permitted to: perform one or more actions to be performed by the RPA robot, receive information requested by the RPA robot, or both; When, based on the access control and management rules, the RPA robot is allowed to perform the one or more actions, receive the requested information, or both: authorizing the one or more actions and / or providing the requested information to the RPA robot; and When, based on the access control and management rules, the RPA robot is not permitted to perform the one or more actions, receive the requested information, or both: The RPA robot is prevented from taking the one or more actions and / or obtaining the requested information.

2. The computer-implemented method of claim 1 , wherein when the RPA robot is not permitted to perform the one or more actions, receive the requested information, or both, the method further comprises: A notification is sent to the RPA robot or client-side application indicating that the one or more actions and / or access to the information are not permitted.

3. The computer-implemented method of claim 1 , wherein when the RPA robot is not permitted to perform the one or more actions, receive the requested information, or both, the method further comprises: Automatically terminate the execution of the RPA robot. The computer-implemented method of claim 1 , wherein the method is performed by a client-side authentication application.

5. The computer-implemented method of claim 1, wherein the method is performed by a server-side authentication application.

6. The computer-implemented method of claim 1 , further comprising: When a computing system associated with the RPA robot connects to a server-side commander application, the access control and management rules are automatically sent to the computing system.

7. The computer-implemented method of claim 1 , wherein at least one of the one or more actions is allowed for a human user but is not allowed for the RPA robot.

8. The computer-implemented method of claim 1 , further comprising: Verifying that the RPA robot is paused for at least a period of time to allow one or more legacy systems to perform one or more operations; as well as When the RPA robot is not paused for at least the specified period of time: Delaying obtaining the information requested by the RPA robot or accepting a new information request from the RPA robot until the period of time expires.

9. The computer-implemented method of claim 1, wherein in addition to design-time enforcement of the access control and management rules, runtime enforcement of the access control and management rules is also performed.

10. The computer-implemented method of claim 1, wherein the RPA robot includes automatically inserted code that forces the RPA robot to obtain the access control and management rules and / or operate according to the access control and management rules.

11. The computer-implemented method of claim 1 , wherein the access control and management rules comprise 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 attribute requirements, or a combination thereof.

12. A non-transitory computer-readable medium storing a computer program for performing runtime robotic access control and management for Robotic Process Automation (RPA), the computer program configured to cause at least one processor to: determining, based on access control and management rules, whether an RPA robot is permitted to: perform one or more actions to be performed by the RPA robot, receive information requested by the RPA robot, or both; and When, based on the access control and management rules, the RPA robot is not permitted to perform the one or more actions, receive the requested information, or both: The RPA robot is prevented from taking the one or more actions and / or obtaining the requested information.

13. The non-transitory computer-readable medium of claim 12 , wherein when, based on the access control and management rules, the RPA robot is permitted to perform the one or more actions, receive the requested information, or both, the computer program is further configured to cause the at least one processor to: Authorizing the one or more actions and / or providing the requested information to the RPA robot.

14. The non-transitory computer-readable medium of claim 12 , wherein when the RPA robot is not allowed to perform the one or more actions, receive the requested information, or both, the computer program is further configured to cause the at least one processor to: A notification is sent to the RPA robot or client-side application indicating that the one or more actions and / or access to the information are not permitted. 15 . The non-transitory computer-readable medium of claim 12 , wherein at least one of the one or more actions is allowed for a human user but is not allowed for the RPA bot.

16. The non-transitory computer-readable medium of claim 12, wherein the computer program is further configured to cause the at least one processor to: Verifying that the RPA robot is paused for at least a period of time to allow one or more legacy systems to perform one or more operations; and When the RPA robot is not paused for at least the specified period of time: Delaying obtaining the information requested by the RPA robot or accepting a new information request from the RPA robot until the period of time expires.

17. The non-transitory computer-readable medium of claim 12, wherein the RPA robot includes automatically inserted code that forces the RPA robot to obtain the access control and management rules and / or operate according to the access control and management rules.

18. A non-transitory computer-readable medium storing a computer program for performing runtime robotic access control and management for Robotic Process Automation (RPA), the computer program configured to cause at least one processor to: determining, based on access control and management rules, whether an RPA robot is permitted to: perform one or more actions to be performed by the RPA robot, receive information requested by the RPA robot, or both; and When, based on the access control and management rules, the RPA robot is not permitted to perform the one or more actions, receive the requested information, or both: preventing the RPA robot from taking the one or more actions and / or obtaining the requested information, and Sending a notification to the RPA robot or client-side application indicating that the one or more actions and / or access to the information are not permitted, automatically ending execution of the RPA robot, or both.

19. The non-transitory computer-readable medium of claim 18, wherein the computer program is further configured to cause the at least one processor to: Verifying that the RPA robot is paused for at least a period of time to allow one or more legacy systems to perform one or more operations; and When the RPA robot is not paused for at least the specified period of time: Delaying obtaining the information requested by the RPA robot or accepting a new information request from the RPA robot until the period of time expires.

20. The non-transitory computer-readable medium of claim 18, wherein the RPA robot includes automatically inserted code that forces the RPA robot to obtain the access control and management rules and / or operate according to the access control and management rules.

Images