Automatic activation and configuration of Robotic Process Automation workflows using machine learning

By integrating ML models with RPA workflows to dynamically adjust based on confidence thresholds, the solution addresses the inflexibility of deterministic RPA, enhancing adaptability and efficiency.

JP7604472B2Active Publication Date: 2024-12-23UIPATH INC
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2022520179
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2019-12-09
Filing Date
2020-08-13
Publication Date
2024-12-23
Estimated Expiration
2040-08-13

AI Technical Summary

Technical Problem

Current RPA workflows are deterministic and may not be optimal for situations that change over time, lacking flexibility and adaptability.

Method used

Implementing machine learning (ML) models to invoke probabilistic activities in RPA workflows, using confidence thresholds to dynamically turn on or off workflow sections based on ML model outputs, allowing for a hybrid of deterministic and probabilistic logic.

Benefits of technology

Enhances the adaptability and efficiency of RPA workflows by enabling them to learn and improve over time, balancing accuracy and resource provision, while reducing false positives and negatives.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007604472000001
    Figure 0007604472000001
  • Figure 0007604472000002
    Figure 0007604472000002
  • Figure 0007604472000003
    Figure 0007604472000003
Patent Text Reader

Abstract

Disclosed is an automated activation and configuration of robotic process automation (RPA) workflows that use machine learning (ML). One or more portions of an RPA workflow can be turned on or off based on one or more probabilistic ML models. The RPA robot can be configured to modify parameters, determine the amount of specific resources to provide, determine more optimal thresholds, etc. Thus, such RPA workflows that implement ML can be a hybrid of both deterministic and probabilistic logic and can learn and improve over time by retraining ML models, adjusting confidence thresholds, using local / global confidence thresholds, providing or adjusting modifiers for local confidence thresholds, implementing monitoring systems to monitor ML model performance, etc.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Nonprovisional Patent Application No. 16 / 707,814, filed December 9, 2019, and U.S. Provisional Patent Application No. 62 / 915,379, filed October 15, 2019. The subject matter of these prior applications is incorporated herein by reference in its entirety.

[0002] The present invention relates generally to robotic process automation (RPA), and more specifically to automatic activation and configuration of RPA workflows using machine learning (ML). [Background technology]

[0003] Current RPA workflows are deterministic in nature. In other words, the workflow follows a sequence of logical steps similar to a flowchart. However, this deterministic logic may not be optimal for all situations, especially those that change over time. Therefore, improved solutions could 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 the automated activation and configuration of RPA workflows using ML.

[0005] In one embodiment, a computer-implemented method includes invoking, by the RPA robot, at least one ML model when performing a probabilistic activity of an RPA workflow, and receiving, by the RPA robot, at least one confidence value from the at least one ML model. If the at least one confidence value does not exceed a confidence threshold, the computer-implemented method includes turning off, not obtaining, or logically avoiding, a workflow section following the probabilistic activity, by the RPA robot. If the at least one confidence value exceeds a confidence threshold, the computer-implemented method includes turning on, obtaining, or logically following, a workflow section following the probabilistic activity, by the RPA robot, and performing, by the RPA robot, the workflow section following the probabilistic activity.

[0006] In another embodiment, a computer program is embodied on a non-transitory computer-readable medium. The program is configured to cause at least one processor to call an ML model and receive a confidence value from the ML model when performing a probabilistic activity of an RPA workflow. If the confidence value does not exceed a confidence threshold, the program is configured to cause the at least one processor to turn off, not obtain, or logically avoid a workflow section after the probabilistic activity. If the confidence value exceeds a confidence threshold, the program is configured to cause the at least one processor to turn on, obtain, or logically follow a workflow section after the probabilistic activity and perform the workflow section after the probabilistic activity.

[0007] In yet another embodiment, a computer-implemented method includes invoking, by the RPA robot, at least one ML model when performing a probabilistic activity of an RPA workflow, and receiving, by the RPA robot, at least one confidence value from the at least one ML model. The computer-implemented method also includes comparing, by the RPA robot, the at least one confidence value to a plurality of confidence threshold ranges. If the at least one confidence value falls within the confidence threshold range, the computer-implemented method includes turning on, obtaining, or logically following, by the RPA robot, a workflow section following the probabilistic activity for that confidence threshold range, and performing, by the RPA robot, the workflow section following the probabilistic activity for that confidence threshold range. [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 be provided by reference to specific embodiments which are illustrated in the accompanying drawings, it being understood that these drawings depict only typical embodiments of the invention and therefore should not be considered as limiting its scope, but 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 an 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 relationships 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 architecture diagram illustrating a computing system configured to automatically activate and configure RPA workflows using ML, according to one embodiment of the present invention.

[0014] [Figure 6] FIG. 1 illustrates an RPA workflow using ML for auto-activation according to one embodiment of the present invention.

[0015] [Figure 7] 1 is a flowchart illustrating a process for automatically activating and configuring RPA workflows using ML in accordance with an embodiment of the present invention.

[0016] [Figure 8] 8 is a flowchart illustrating another process 800 for automatically activating and configuring RPA workflows using ML in accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Some embodiments relate to automatic activation and configuration of RPA workflows that use ML. In some embodiments, one or more portions of an RPA workflow can be turned on or off based on one or more probabilistic ML models. In certain embodiments, the ML models can be configured to modify parameters, determine the amount of a particular resource to provide (e.g., how much current to send, how much water to allow through a dam, how much to price a product, etc.), determine more optimal thresholds, etc. Thus, such RPA workflows that implement ML may be a hybrid of both deterministic and probabilistic logic and can learn and improve over time by retraining ML models, adjusting confidence thresholds, using local / global confidence thresholds, providing or adjusting modifiers for local confidence thresholds, implementing monitoring systems to monitor ML model performance, etc.

[0018] A workflow includes a sequence of activities, each of which accomplishes a finer part of a larger task. Typically, activities follow conditional branching logic that leads directly to another activity or to a section of the sequence when an associated static condition is met. However, some embodiments utilize trainable / retrainable ML models that control whether a part of the workflow is enabled (i.e., "activated") or disabled based on learned probabilistic thresholds, e.g., using confidence intervals, rather than always proceeding to the next activity or selecting an activity based on a deterministic condition. Such activation thresholds can be learned and / or reconfigured over time based on data from the robot performing the workflow. For example, an RPA robot can start with a workflow executed in a deterministic manner and then learn to turn one or more sections of the workflow on or off over time, modify activity parameters, determine the provision amount of one or more resources, change thresholds, or any combination of these.

[0019] The threshold may be set based on one or more factors such as importance, risk, cost, danger to life, etc. For example, the threshold for a mission-critical system may be very high (e.g., 99.9999%). In some embodiments, the threshold itself is learned over time. For example, in the context of an automated retail system where customer actions are monitored by cameras and other sensors rather than having a human checkout clerk, it may be desirable to balance the confidence interval so that it is high enough that products taken by a user are detected, but not so high that a significant number of false positives occur (i.e., a user is detected as picking up an item, but then returns it to another location in the store or leaves it, resulting in a charge for an item that the user did not take and leave the store with). The business objective of such a store is to detect as many items as possible that consumers have taken, but keep the false positive rate low enough that consumers are likely to return to the store again and do not avoid the store due to a negative experience or the hassle of asking for a refund for an item that they did not actually intend to purchase.

[0020] In such a scenario, the system may have an initial confidence interval of 80% (e.g., confidence that the user actually picked up the product and left the store with the product). After a period of time, data analysis may reveal that a 10% loss of non-paying products (i.e., customers leaving the store with the product undetected) occurred. Data analysis may also reveal that the reported false positive rate was 0.1%. If the company determines that a higher false positive rate is acceptable, but the product loss rate is unacceptable, the ML model's confidence interval may be increased. Alternatively, the ML model may be provided with a maximum acceptable false positive rate and product loss rate, and the ML model confidence interval may be automatically increased accordingly (e.g., up to 85%). This is done periodically until the false positive rate becomes unacceptable, and the false positive rate may be periodically ramped down, up, etc. until the false positive rate converges toward the maximum acceptable rate. For example, this may converge to a 99% confidence that the user picked up the product and a 1% false positive rate. Such a system can also detect changes in detection rates over time (e.g., decreased accuracy due to sensor degradation or failure, improved accuracy due to the implementation of new sensors, etc.) and adjust the confidence intervals accordingly.

[0021] In certain embodiments, whether to turn on a part of the workflow can be determined by computing a pseudo-random number and comparing that number to a confidence value from the ML model (e.g., if there is at least a threshold, the part of the workflow is turned on, otherwise the part of the workflow is not followed). In this case, the workflow performed by the robot may be different for each execution. This may be beneficial, for example, in swarm behavior. In scenarios where a large number of drones are deployed (e.g., 100, 1,000, etc.), it may be desirable to have different random effects. For example, if a drone swarm is being used for concert lighting and it is desirable for 70% of the drones to randomly light up blue, 20% to randomly light up yellow, and 10% to randomly light up red every time a beat occurs in a song, this can be implemented using a confidence threshold range in a probabilistic workflow. This provides a gating mechanism with multiple gates. Such an embodiment may be trained via reinforcement learning, where the system explores new states with specified constraints and a reward function is used to seek a "winning" state. For example, the reward function may include increasing the volume of applause, new patterns can be explored, and characteristics of drone patterns that increase applause can be learned.

[0022] In some embodiments, a "global" confidence value based on the "local" confidence intervals of multiple ML models may be used. For example, three different ML models 1, 2, and 3 may be used for a task such as image recognition, but the ML models may provide different results. Consider the case where ML models 1 and 3 determine that an object in an image is a dog with 90% and 80% confidence, respectively, but the ML model determines that the object is a cat with 90% confidence, and the global confidence threshold requirement for positive detection is 50%. The object is clearly identified as a dog ((0.9+0.0+0.7) / 3=0.53333), but fails to be identified as a cat ((0.0+0.8+0.0) / 3=0.26667). This is somewhat similar to transfer learning, where ML models may be applied in similar scenarios, but in different contexts.

[0023] Different ML models may also have different accuracies for a particular task. Thus, in certain embodiments, the confidence intervals of one or more models may be weighted. For example, for invoice processing, ML model 1 may be assigned a 100% modifier, ML model 2 may be assigned a 70% modifier, and ML model 3 may be assigned a 50% modifier based on the accuracy of each model. However, for image detection, the accuracies and modifiers may be different.

[0024] In certain embodiments, the ML model can be monitored by a supervisory system to ensure that a deployed robot using the ML model is operating as intended. This can be particularly beneficial for mission-critical systems. For example, aircraft operating parameters can be monitored if the robot is used in an aircraft to automatically control a flight surface under certain conditions. When reviewing data collected from an aircraft on which a deployed robot is operating, the supervisory system can determine statistically significant anomalies, such as some pilots tending to pull back on the control wheel immediately after the robot initiates flight surface control. The supervisory system can then instruct the robot to disable parts of the workflow, disable the robot entirely, provide a warning with possible corrections to the pilot of the detected condition, etc.

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

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

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

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

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

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

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

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

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

[0034] 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 the Windows session and acts as a proxy between the conductor 120 and the execution host (i.e., the computing system on which the robot 130 executes). These services are trusted with and manage the credentials of the robot 130. The console application is launched by the SCM under the local system.

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

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

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

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

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

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

[0041] The server side includes a presentation layer (web application 232, Open Data Protocol (OData) Representational State Transfer (REST) ​​Application Programming Interface (API) endpoints 234, and notifications and monitoring 236), a service layer (API implementation / business logic 238), and a persistence layer (database server 240, indexer server 250). The conductor 230 includes a web application 232, an OData REST API endpoint 234, notifications and monitoring 236, and an API implementation / business logic 238. In some embodiments, most actions that a user performs within the conductor 220 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 in a queue, scheduling a job to run unattended, etc., without departing from the scope of the invention. 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 invention. A user interacts with web pages from web application 232, in this embodiment via browser 220, to perform various actions to control conductor 230. For example, a user can create robot groups, assign packages to robots, analyze logs per robot and / or per process, start and stop robots, etc.

[0042] 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 consumed by both the web application 232 and the agent 214, which in this embodiment is the administrator of one or more robots on a client computer.

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

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

[0045] The persistence layer includes a pair of servers in this embodiment: a database server 240 (e.g., SQL Server) and an indexer server 250. The database server 240 in this embodiment stores configurations for robots, robot groups, associated processes, users, roles, schedules, etc. This information is managed in some embodiments via a 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 instead of the indexer server 250).

[0046] The indexer server 250 is optional in some embodiments and stores and indexes information logged by the robots. In certain embodiments, the indexer server 250 can be disabled through a configuration setting. In some embodiments, the 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 or line writes) may be sent via a logging REST endpoint to the indexer server 250, where they are indexed for future use.

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

[0048] UI automation activities 330 are a subset of special low-level activities that are written into lower level code (e.g., CV activities) and facilitate interactions with the screen. UI automation activities 330 facilitate these interactions via drivers 340 that allow 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.

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

[0050] 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 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 may communicate with a conductor computing system 420 via web applications executed thereon. The conductor computing system 420 may in turn communicate with a database server 430 and an optional indexer server 440.

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

[0052] FIG. 5 is an architecture diagram illustrating a computing system 500 configured to automatically activate and configure RPA workflows using ML, according to an embodiment of the present invention. In some embodiments, the computing system 500 may be one or more of the computing systems illustrated and / or described herein. The computing system 500 includes a bus 505 or other communication mechanism for communicating information and a processor 510 coupled 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), multiple instances thereof, and / or any combination thereof. The processor 510 may also have multiple processing cores, at least some of which may be configured to perform a particular function. In some embodiments, multiple parallel processing may be used. In certain embodiments, at least one of the processors 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.

[0053] The computing system 500 further includes a memory 515 for storing information and instructions executed by the processor 510. The memory 515 can be comprised of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage 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 accessible by the processor 510 and may include volatile media, non-volatile media, or both. The medium may also be removable, non-removable, or both.

[0054] Additionally, the computing system 500 includes a communications device 520, such as a transceiver for providing access to a communications network via wireless and / or wired connections. In some embodiments, the communications device 520 may be a communications device for a variety of communications networks, 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 ​​... The communication device 520 may be configured to use any of the following communication standards and / or protocols: High Speed ​​Passive Access (HSPA), Long Term Evolution (LTE), LTE Advanced (LTE-A), 802.11x, Wi-Fi, Zigbee, Ultra Wideband (UWB), 802.16x, 802.15, Home Node B (HnB), Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Near Field Communications (NFC), Fifth Generation (5G), New Radio (NR), any combination thereof, and / or any other currently existing or future implemented communication standards and / or protocols without departing from the scope of the present invention. In some embodiments, the communication device 520 may include one or more antennas that are single, array, phased, switched, beamforming, beamsteering, combinations thereof, and / or any other antenna configuration without departing from the scope of the present invention.

[0055] The processor 510 is further coupled via bus 505 to a display 525, such as a plasma display, a liquid crystal display (LCD), a light emitting diode (LED) display, a field emission display (FED), an organic light emitting diode (OLED) display, a flexible OLED display, a flexible substrate display, a projection display, a 4K display, a high definition display, a Retina® display, an in-plane switching (IPS) display, or any other suitable display for displaying information to a user. The display 525 may be configured as a touch (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.

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

[0057] 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 an automated workflow activation and configuration module 545 configured to perform all or a portion of the processes described herein or derivatives thereof. The computing system 500 may include one or more additional functional modules 550 that include additional functionality.

[0058] Those skilled in the art will appreciate that the "system" may be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the 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 provide one example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technologies, including cloud computing systems.

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

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

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

[0062] FIG. 6 illustrates an RPA workflow 600 using ML for automatic activation, according to an embodiment of the present invention. In the RPA workflow 600, deterministic activity 1 610 always results in deterministic activity 2 620, which in turn always results in probabilistic activity 630. However, probabilistic activity 630 uses ML model 640 to process data and return a confidence value. For example, if ML model 640 is trained to recognize cars in images and the confidence threshold is 70%, then RPA workflow 600 will proceed to deterministic activity 3 650 and to deterministic activity 4 660 only if this 70% confidence threshold is met. In this sense, the robot performing the RPA workflow 600 turns steps 650 and 660 on or off based on the confidence threshold and the output from ML model 640. Over time, the confidence threshold may be modified to better fit the scenario in which it is applied, the ML model may be retrained to be more accurate, etc.

[0063] In some embodiments where multiple ML models are used, the confidence values ​​from each ML model may be combined to determine a global confidence value that is compared to a confidence threshold for probabilistic activity. In certain embodiments, the global confidence value is determined by applying a respective weight to the confidence value of each ML model and combining the weighted confidence values. For example, if three ML models are used, a weight of 50% may be applied to the confidence value from the first ML model, a weight of 30% may be applied to the confidence value from the second ML model, and a weight of 20% may be applied to the confidence value from the third ML model.

[0064] FIG. 7 is a flow chart illustrating a process 700 for automatically activating and configuring an RPA workflow using ML, according to an embodiment of the present invention. The process begins with generating an RPA workflow, at 710, including a plurality of deterministic activities and at least one probabilistic activity that invokes an ML model. An RPA robot is then generated, at 720, to perform the workflow. An ML model is invoked, at 730, and a confidence value is received from the ML model. If the confidence value does not exceed a confidence threshold, at 740 (e.g., a single confidence value from the ML model, a global confidence value from multiple ML models, etc.), then the workflow section following the probabilistic activity is turned off, not taken, or logically avoided, at 750. Optionally, the confidence threshold may be raised and lowered, at 760. In certain embodiments, the system may wait to modify the confidence threshold, such as until the processes of the workflow have been executed a predetermined number of times, until a predetermined time has elapsed, etc.

[0065] If the confidence value exceeds the confidence threshold at 740, then the section of the workflow following the probabilistic activity is turned on, obtained, or logically enabled at 770, and the section of the workflow after the probabilistic activity is performed is performed at 780. Optionally, the confidence threshold may be raised and lowered at 760.

[0066] In some embodiments, modification of the confidence threshold may not achieve the desired results due to imperfections in the ML model. For example, taking the automated retail system example above, consider a case where the false positive rate remains unacceptably high (e.g., 5%) despite changes to the confidence threshold of a user to pick up an item for purchase after a predetermined number of adjustments (e.g., 20). At 790, it may be determined that at least one of the ML models is not achieving the desired results. The ML model may then be retrained at 795. If the RPA robot makes the determination, step 790 may include the RPA robot sending an indication to a server that retraining of the ML model should be performed.

[0067] 8 is a flow chart illustrating another process 800 for automatically activating and configuring an RPA workflow using ML, according to one embodiment of the present invention. The process begins at 810 with generating an RPA workflow that includes multiple deterministic activities and at least one probabilistic activity that invokes an ML model. At 820, the ML model is invoked and a confidence value is received from the ML model.

[0068] After the confidence value is received, the confidence value is compared to a plurality of confidence threshold ranges at 830. A subsequent section of the post-probabilistic activity workflow corresponding to the confidence threshold range into which the confidence value falls is then performed at 840. Optionally, one or more of the confidence ranges may be modified at 850. The alteration of the one or more confidence ranges may be repeated until a winning state is achieved.

[0069] In some embodiments, a more complex mix of deterministic and probabilistic activities may be used in the workflow. Indeed, any type and combination of deterministic and probabilistic activities may be employed without departing from the scope of the present invention. Indeed, in certain embodiments, some parts of the workflow may be similar to FIG. 7, while other parts may be similar to FIG. 8.

[0070] The process steps performed in Figures 7 and 8 may be performed by a computer program encoding instructions for a processor to perform at least a portion of the process described in Figures 7 and 8 according to an embodiment of the present invention. The computer program may be embodied on a non-transitory computer readable medium. The computer readable medium may be, but is not limited to, a hard disk drive, a flash device, 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 (e.g., processor 510 of computing system 500 of Figure 5) to perform all or a portion of the process steps described in Figures 7 and 8, which may also be stored on a computer readable medium.

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

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

[0073] 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 the embodiment is included in at least one embodiment of the invention. Thus, the 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, but rather the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

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

[0075] 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 may 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.

[0076] Those skilled in the art will readily appreciate that the invention described above may be practiced with steps in a different order and / or hardware elements in a different configuration than that 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 constructions will be apparent while remaining within the spirit and scope of the invention. Accordingly, reference should be made to the appended claims to determine the scope of the invention.

Claims

1. 1. A computer-implemented method comprising: invoking, by a robotic process automation (RPA) robot, at least one machine learning (ML) model when executing a probabilistic activity of an RPA workflow; receiving, by the RPA robot, at least one confidence value from the at least one ML model; if the at least one confidence value does not exceed a confidence threshold, turning off, not taking, or logically avoiding, by the RPA robot, a workflow section following the probabilistic activity; if the at least one confidence value exceeds the confidence threshold, by the RPA robot, turning on, obtaining, or logically following a workflow section after the probabilistic activity; and performing, by the RPA robot, the workflow section following the stochastic activity.

2. generating the RPA workflow including a plurality of deterministic activities and the at least one probabilistic activity configured to invoke the at least one ML model; generating the RPA robot that performs the generated RPA workflow; The computer-implemented method of claim 1 , further comprising:

3. The method further includes increasing or decreasing the confidence threshold by the RPA robot after a process of the workflow has been executed a predetermined number of times or after a predetermined time has elapsed.

2. The computer-implemented method of claim 1.

4. 4. The computer-implemented method of claim 3, wherein the raising or lowering of the confidence threshold by the RPA robot is repeated until a winning state is achieved.

5. determining, by the RPA robot, that the at least one ML model does not achieve a result after a predetermined number of revisions to the confidence threshold; retraining the at least one ML model; The computer-implemented method of claim 3 further comprising:

6. 2. The computer-implemented method of claim 1, wherein the RPA robot is configured to modify activity parameters, determine provision of specific resources, determine a more optimal confidence threshold, or any combination thereof.

7. 2. The computer-implemented method of claim 1, wherein the RPA robot invokes multiple ML models, and the confidence values ​​from each ML model are combined to determine a global confidence value that is compared to the confidence threshold for the probabilistic activity.

8. The computer-implemented method of claim 7 , wherein the global confidence value is determined by applying respective weights to the confidence values ​​and combining the weighted confidence values.

9. A computer program stored on a non-transitory computer readable medium, the program causing at least one processor to: Invoking a machine learning (ML) model when performing a probabilistic activity of an RPA workflow; receiving a confidence value from the ML model; causing a workflow section following the probabilistic activity to be turned off, not taken, or logically avoided if the confidence value does not exceed a confidence threshold; if the confidence value exceeds the confidence threshold, Turning on, obtaining, or logically following a workflow section following said probabilistic activity; A computer program configured to cause the workflow section to be performed following the stochastic activity.

10. The program causes the at least one processor to:

10. The computer program product of claim 9, further configured to increase or decrease the confidence threshold after a process of the workflow has been executed a predetermined number of times or after a predetermined amount of time has elapsed.

11. The computer program product of claim 10 , wherein the raising or lowering of the confidence threshold is repeated until a winning state is achieved.

12. The program causes the at least one processor to: determining that the ML model has not achieved results after a predetermined number of revisions to the confidence threshold; The computer program product of claim 10 , further configured to cause a server to provide instructions to retrain the ML model.

13. The program causes the at least one processor to:

10. The computer program product of claim 9, further configured to modify activity parameters, determine the provision of certain resources, determine a more optimal confidence threshold, or any combination thereof.

14. 1. A computer-implemented method comprising: invoking, by a robotic process automation (RPA) robot, at least one machine learning (ML) model when executing a probabilistic activity of an RPA workflow; receiving, by the RPA robot, at least one confidence value from the at least one ML model; comparing, by the RPA robot, the at least one confidence value to a plurality of confidence threshold ranges; if the at least one confidence value is within a confidence threshold range, by the RPA robot, turning on, obtaining, or logically following a workflow section after the probabilistic activity for the confidence threshold range; and performing, by the RPA robot, the workflow section following the probabilistic activity for the confidence threshold range.

15. generating the RPA workflow including a plurality of deterministic activities and the at least one probabilistic activity configured to invoke the at least one ML model; generating the RPA robot that performs the generated RPA workflow; 15. The computer-implemented method of claim 14, further comprising:

16. modifying, by the RPA robot, one or more of the confidence threshold ranges after a process of the workflow has been executed a predetermined number of times or after a predetermined time has elapsed.

15. The computer-implemented method of claim 14.

17. 17. The computer-implemented method of claim 16, wherein the modification of the one or more confidence threshold ranges by the RPA robot is repeated until a winning state is achieved.

18. determining, by the RPA robot, that the at least one ML model does not achieve a result after a predetermined number of revisions to the confidence threshold; retraining the at least one ML model; 20. The computer-implemented method of claim 16, further comprising:

19. 15. The computer-implemented method of claim 14, wherein the RPA robot is configured to modify activity parameters, determine provision of specific resources, determine a more optimal confidence threshold, or any combination thereof.

20. the RPA robot invokes a plurality of ML models, and the confidence values ​​from each ML model are combined to determine a global confidence value that is compared to the confidence threshold range of the probabilistic activity; the global confidence value is determined by applying respective weights to the confidence values ​​and combining the weighted confidence values.

15. The computer-implemented method of claim 14.

Citation Information

Patent Citations

  • Robot and voice recognition device, and method for the same

    JP2007155985A

  • Robot control system and robot control program

    JP2015150620A

  • Method and apparatus for self-evaluation and randomization for predictive models

    US20050169452A1

  • Adaptive Automatic Defect Classification

    US20170082555A1

  • Accounting processing system, accounting processing method, and accounting processing program

    WO2020255361A1