This disclosure relates generally to the field of data processing systems and more particularly to robotic process automation systems.
Robotic process automation (RPA) is the application of technology that allows workers in an organization to configure a computer software robot, “robot” or “bot”, to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems. Conventional RPA systems employ software robots to interpret the user interface of third-party applications and to execute steps identically to a human user. Increasingly, RPA systems are being used to process ever larger sets of data, and as dependence on such systems grows, the need increases for such systems to process data within certain time constraints to meet business needs. Moreover, such systems can employ a large number of devices (virtual or physical) to process the data via automation. As the volume and variety of data grows and the availability of computing devices increases it becomes increasingly difficult to manage workloads and devices to meet business needs. This problem becomes particularly acute as reliance on such systems increase. Accordingly, there is a need for improved automation and management of RPA systems in a manner that meets expectations and provides reliable and predictable processing and response times.
Computerized RPA methods and systems with task prioritization and queue orchestration are disclosed herein. Additionally, the disclosed system may also provide Service Level Agreement (SLA) automation and Quality of Service (QoS) based automation. In a certain aspect, a robotic process automation system includes data storage for storing a plurality of sets of task processing instructions where each set of task processing instructions is operable to interact at a user level with one or more designated user level application programs. The data storage also includes a plurality of sets of work items where each set of work items is stored for subsequent processing by devices executing a corresponding set of task processing instructions. Each set of the work items is characterized by a schema comprising a plurality of attributes. Moreover, each work item within a set of work items contains a value for each attribute in the corresponding schema for the set of work items. A processor is operatively coupled to the data storage and configured to execute instructions that when executed cause the processor to: respond to one or more user inputs to create a queue for processing a set of work items, respond to one or more user inputs to assign one or more of the work items to the queue, respond to one or more user inputs to identify as a prioritization attribute an attribute within a schema for the set of work items and respond to one or more user inputs to prioritize processing of work items in the queue having a value of the prioritization attribute corresponding to a user defined prioritization value or prioritization range. The processor processes the work items in the queue by executing a corresponding set of the task processing instructions to automatically process each work item in the queue with a priority corresponding to values of the prioritization attributes.
In another aspect, a robotic process automation system comprises data storage for storing a plurality of sets of task processing instructions where each set of task processing instructions is operable to interact at a user level with one or more designated user level application programs. The data storage also includes a plurality of sets of work items where each set of work items is stored for subsequent processing by devices executing a corresponding set of task processing instructions. A processor is operatively coupled to the data storage and is configured to execute instructions that when executed cause the processor to: process work items in a first queue containing a first set of items by executing a corresponding first set of the task processing instructions to automatically process each work item in the first queue, to create a first set of processed work items; determine for each work item in the first set of processed work items if one or more variable values meet a predetermined test, and if so then assigning that work item to a second queue for automatic processing by a second set of the task processing instructions to automatically process each work item in the second queue, to create a second set of processed work items.
In certain embodiments, such systems and methods process a set of robotic process automation tasks by receiving service level requirement inputs—number of transactions (work items) to be performed within a specified period of time. Each RPA task includes a set of instructions that cause a computing resource to interact with one or more user level computer applications to perform tasks provided by the one or more user level computer applications. In response to the service level requirement inputs, a number of computing resources (bot runners) required to perform the transactions by an RPA task in the specified period of time is computed. An allocated set of computing resources is generated by determining availability of computing resources from a set of computing resources. The allocated set of computing resources is manually or automatically provisioned and deployed. The status of each computing resource and automation is monitored and each computing resource is redeployed with additional work items as it completes processing a work item in its queue. This permits transparency and the ability to execute automatically within SLA bounds especially at high load volumes. Users may manually prioritize high value transactions within an automated queue management system. A built-in SLA calculator and manually or automated deployment of computing devices enables hundreds or even thousands of computing devices to come into existence to meet increased automation demand the moment it is needed. All of these features empower an enterprise to achieve the best optimization of its digital and human resources to meet highly dynamic SLA demands.
Certain other embodiments alternatively or in addition to the foregoing embodiments, provide QoS based automation by prioritizing user requests over device requests, and prioritizing certain device requests over other device requests. In addition, certain user requests may be prioritized over other user requests. The prioritization of certain requests over others helps to ensure predictable response times and ensures timely processing of priority tasks.
Additional aspects related to the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the description or may be learned by practice of the invention. Aspects of the invention may be realized and attained by means of the elements and combinations of various elements and aspects particularly pointed out in the following detailed description and the appended claims.
It is to be understood that both the foregoing and the following descriptions are exemplary and explanatory only and are not intended to limit the claimed invention or application thereof in any manner whatsoever.
The accompanying drawings, which are incorporated in and constitute a part of this specification exemplify the embodiments of the present invention and, together with the description, serve to explain and illustrate principles of the inventive techniques disclosed herein. Specifically:
In the following detailed description, reference will be made to the accompanying drawings, in which identical functional elements are designated with like numerals. The aforementioned accompanying drawings show by way of illustration, and not by way of limitation, specific embodiments and implementations consistent with principles of the present invention. These implementations are described in sufficient detail to enable those skilled in the art to practice the invention and it is to be understood that other implementations may be utilized and that structural changes and/or substitutions of various elements may be made without departing from the scope and spirit of present invention. The following detailed description is, therefore, not to be construed in a limited sense.
Users of RPA systems are increasingly relying on such systems for implementing key business processes. Any given organization will have a finite, generally limited, number of automation resources, such as physical or virtual computing devices, and such automation resources will need to be allocated against an increasing number of automation tasks in a manner that achieves service level agreements with various groups within the organization. For example, an organization may have a number of different types of tasks (task types) such as invoice processing, new hire on-boarding, and travel expense reporting. Each of these task types may at any given time consist of thousands or more tasks that need to be processed. As used herein, the processing of such tasks is performed by a “bot runner” which is a software implemented player for executing a bot (shorthand for “robot”) which is a series of instructions for performing an application level task. A bot runner is created by way of a bot creator which creates the series of instructions executed by the bot runner.
In any given organization, there may be thousands of invoices, dozens or more new hires and thousands of expense reports at any one time that require processing, and such tasks need to be processed within an agreed upon time, which is commonly referred to as a service level. The tasks will typically have different priorities in the organization for processing turnaround. For example, certain tasks may need to be rapidly performed, within the course of a day, while others may be able to be performed at a slower, or lower priority pace. Moreover, certain tasks, once performed, may lead to further downstream tasks based on the outcome. For example, in loan processing, if information obtained in initial processing of a loan application leads to a determination of a credit score above a threshold, then that application may need to be moved to a downstream task for processing approved applications.
Determining the number of automation resources to allocate for each task type can also be difficult and time consuming, particularly as the number of task types and volume of the task types increases. Also, there can be significant variation among task types in terms of the amount of time required to process each task. Moreover, deployment of tasks can be a manual and time-consuming process.
Embodiments disclosed herein address many of the aforementioned challenges by providing for prioritization of designated tasks and by providing for queue orchestration to permit automated movement of a processed task to subsequent processing.
Embodiments disclosed herein further permit smart load distribution through intelligent queue management. This permits transparency and the ability to execute automatically within SLA bounds especially at high load volumes. Users may manually prioritize high value transactions within an automated queue management system. A built-in SLA calculator and automated deployment of bot runners enables hundreds or even thousands of bots to be spun up to meet increased automation demand the moment it is needed. In addition, prioritization of certain requests over others helps to ensure predictable response times. All of these features empower an enterprise to achieve the best optimization of its digital and human resources to meet highly dynamic SLA and QoS demands.
The tasks are processed by bot runners executing on computing devices 110 which may be organized in a variety of logical or physical groups, such as shown in
Each bot runner takes the form of a player that executes, via a computing device, a bot to perform the functions encoded by the bot. Additional aspects of operation of bots may be found in the following pending patent application, which refers to bots as automation profiles, System and Method for Compliance Based Automation, filed in the U.S. Patent Office on Jan. 6, 2016, and assigned application Ser. No. 14/988,877, which is hereby incorporated by reference.
Control room module 104 includes an SLA generation automation module 112 which can be employed by user 102 in a manner shown in
QoS module 107 implements a QoS protocol to provide high operational availability for incoming requests. The requests may come from bot runners, from users and administrators of the RPA system 10 via computerized user-interfaces, such as an application accessed via a web browser, and from bot creators.
Task prioritization module 118 permits prioritization of work items by one or more attributes of the work items. Queue orchestration module 120 permits simple orchestration of complex workflows by permitting user 102 to configure a bot to process a work item from one queue and push the outcome as a work Item into another queue.
In
In
Details of operation of queue orchestration module 120 are shown in the interface of
Stager 305 moves New WorkItems 306 to Staging table 308 and Ignite MQ Cache table 310 which is preferably stored in high-speed, volatile storage. The distributor 307 distributes workitems from the Ignite MQ Cache 310 to BotRunners (devices) 110, based on round-robin or priority allocation. The stager 305 receives messages from the distributor 307 about which queues to fill and how many records to fill. The stager 305 operates irrespectively of whether round-robin or priority allocation has been selected. It merely receives a message from the distributor 307 about which queue (id) to fill in the Ignite 310 or staging 308 table. In round-robin allocation, the distributor 307 initially starts with the lowest Queue ID in the Pool, and then goes to next higher Queue ID (in that Pool) in a round robin manner.
The hardware employed by the various components of the RPA system 10 is preferably specified to certain minimum capabilities to enable proper response and functioning of the system. For example, each device 110 on which a bot runner will execute should be specified to have at least a certain processor and associated minimum transitory and non-transitory storage and be connected to the control room 104 via a network connection of certain minimum data transmission capability (eg. 1Gb or 10Gb Ethernet). Each bot creator 502, control room server 104, and the servers associated with the operations DB 509 and the analytics DB 510 will preferably have their own minimum processing, storage and data communication specifications.
Operation of the control room 104 is further shown in
The queues 601, 603, 605, 607, and 609 are shown for simplicity of illustration with 10 positions. In practice the queues will typically have many more, positions, and this will often be a function of capabilities of the hardware. The various servers in the control room 104 will process each queued request in dynamic queue 601, with the result that multiple requests may be processed concurrently. In certain embodiments, to further enhance response of the control room 104 to user requests, the number of device requests in the queue 601 that may be processed concurrently by the control room servers 104 at any given time may be limited to an administrator adjustable quantity (e.g. 10).
Uploading of information from a bot runner 110 to control room 104 is shown at 720, 722, 724. To initiate an upload of information to the control room 104, a bot runner 110 transmits an upload message to the control room 104 along with a number of chunks, representing the file to be uploaded. The control room 104 responds by initiating an upload routine 722, 724 by serially requesting from the bot runner 110, chunks for upload until the upload is completed.
As the number of bot runners 110 simultaneously downloading and uploading information to and from the repository 109 increase, the time taken for the control room 104 to start processing a chunk request increases. Preferably, a device (bot creator 502 or bot runner 110) will wait for up to a predetermined amount of time (e.g. two minutes) for a response before timing out a request to upload or download. With a default limit of parallel processed repository requests and simultaneous deployment and execution selected for a number of devices (e.g. 1000 devices), the average time to queue and process a chunk can be managed to a predetermined amount of time.
In the event that network connectivity between devices and the control room 104 is slower than a predetermined reference configuration, or if control room processors are under-utilized during deployment, the number of parallel repository 109 requests can be increased for better throughput. If the processor speed of the control room is lower than the predetermined reference configuration or network speed is higher it may be necessary to lower the number of parallel repository requests allowed to avoid loss of availability due to excessive CPU utilization throughout deployment. If a loss of availability (e.g. user requests are not processed) occurs due to excess processor usage on the control room 104, or the operations database 509, during execution the default number of parallel processed requests can be adjusted down.
To prevent overload when concurrently executing a large number of devices, the processing by the control room 104 of status update messages from bot runners 110 may preferably rate limited (i.e. process a certain number of status update messages within a certain time period) on a per-control room server basis. Messages that are rate limited are preferably discarded as they are just progress messages. Other messages, such as bot start, bot stop, and bot error are preferably not rate limited. Additionally, the rate limit may preferably be adjusted dynamically based on the number of unprocessed status update messages. If reactive rate-limiting is activated the progress reported on an activity page provided to a control room 104 user will be updated at a lower frequency than normal.
Computing system 800 may have additional features such as for example, storage 810, one or more input devices 814, one or more output devices 812, and one or more communication connections 816. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system 800. Typically, operating system software (not shown) provides an operating system for other software executing in the computing system 800, and coordinates activities of the components of the computing system 800.
The tangible storage 810 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system 800. The storage 810 stores instructions for the software implementing one or more innovations described herein.
The input device(s) 814 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system 800. For video encoding, the input device(s) 814 may be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing system 800. The output device(s) 812 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system 800.
The communication connection(s) 816 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.
The innovations can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing system on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing system.
The terms “system” and “computing device” are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on a type of computing system or computing device. In general, a computing system or computing device can be local or distributed and can include any combination of special-purpose hardware and/or general-purpose hardware with software implementing the functionality described herein. While the invention has been described in connection with a preferred embodiment, it is not intended to limit the scope of the invention to the particular form set forth, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents as may be within the spirit and scope of the invention as defined by the appended claims.
This application claims priority to and is a continuation-in-part of the following pending patent applications which are assigned to the assignee of the present application: ROBOTIC PROCESS AUTOMATION SYSTEM WITH SERVICE LEVEL AGREEMENT BASED AUTOMATION, filed in the U.S. Patent Office on Apr. 20, 2018, and assigned application Ser. No. 15/957,915; andROBOTIC PROCESS AUTOMATION SYSTEM WITH QUALITY OF SERVICE BASED AUTOMATION, filed in the U.S. Patent Office on Jun. 30, 2018, and assigned application Ser. No. 16/024,796.
Number | Name | Date | Kind |
---|---|---|---|
4980820 | Youngblood | Dec 1990 | A |
5949999 | Song et al. | Sep 1999 | A |
5983001 | Boughner et al. | Nov 1999 | A |
6133917 | Feigner et al. | Oct 2000 | A |
6389592 | Ayres et al. | May 2002 | B1 |
6427234 | Chambers et al. | Jul 2002 | B1 |
6463346 | Flockhart | Oct 2002 | B1 |
6473794 | Guheen et al. | Oct 2002 | B1 |
6496979 | Chen et al. | Dec 2002 | B1 |
6584529 | Thomas | Jun 2003 | B1 |
6640244 | Bowman-Amuah | Oct 2003 | B1 |
6704873 | Underwood | Mar 2004 | B1 |
6871011 | Rahman et al. | Mar 2005 | B1 |
6898764 | Kemp | May 2005 | B2 |
7091898 | Arling et al. | Aug 2006 | B2 |
7246128 | Jordahl | Jul 2007 | B2 |
7337248 | Rao et al. | Feb 2008 | B1 |
7441007 | Kirkpatrick et al. | Oct 2008 | B1 |
7533096 | Rice et al. | May 2009 | B2 |
7568109 | Powell et al. | Jul 2009 | B2 |
7765525 | Davidson et al. | Jul 2010 | B1 |
7805317 | Khan et al. | Sep 2010 | B2 |
7805710 | North | Sep 2010 | B2 |
7810070 | Nasuti et al. | Oct 2010 | B2 |
7846023 | Evans et al. | Dec 2010 | B2 |
8028269 | Bhatia et al. | Sep 2011 | B2 |
8056092 | Allen et al. | Nov 2011 | B2 |
8095910 | Nathan et al. | Jan 2012 | B2 |
8132156 | Malcolm | Mar 2012 | B2 |
8169916 | Pai | May 2012 | B1 |
8234622 | Meijer et al. | Jul 2012 | B2 |
8438558 | Adams | May 2013 | B1 |
8443291 | Ku et al. | May 2013 | B2 |
8464240 | Fritsch et al. | Jun 2013 | B2 |
8498473 | Chong et al. | Jul 2013 | B2 |
8504803 | Shukla | Aug 2013 | B2 |
8612522 | Sylvain | Dec 2013 | B1 |
8682083 | Kumar et al. | Mar 2014 | B2 |
8769482 | Batey et al. | Jul 2014 | B2 |
8965905 | Ashmore et al. | Feb 2015 | B2 |
9213625 | Schrage | Dec 2015 | B1 |
9278284 | Ruppert et al. | Mar 2016 | B2 |
9357069 | Ristock | May 2016 | B2 |
9444844 | Edery et al. | Sep 2016 | B2 |
9462042 | Shukla et al. | Oct 2016 | B2 |
9667702 | Wright et al. | May 2017 | B1 |
9930376 | Pikes | Mar 2018 | B2 |
9942211 | Campagna | Apr 2018 | B1 |
10380074 | Gu et al. | Aug 2019 | B1 |
20020099669 | Lauer | Jul 2002 | A1 |
20030033590 | Leherbauer | Feb 2003 | A1 |
20030101245 | Srinivasan et al. | May 2003 | A1 |
20030152212 | Burok | Aug 2003 | A1 |
20030159089 | DiJoseph | Aug 2003 | A1 |
20040083472 | Rao et al. | Apr 2004 | A1 |
20040103208 | Chung | May 2004 | A1 |
20040133724 | Chae | Jul 2004 | A1 |
20040172526 | Tann et al. | Sep 2004 | A1 |
20040177225 | Furtek | Sep 2004 | A1 |
20040210885 | Wang et al. | Oct 2004 | A1 |
20040221290 | Casey | Nov 2004 | A1 |
20040243994 | Nasu | Dec 2004 | A1 |
20050071241 | Flockhart | Mar 2005 | A1 |
20050149749 | Van Brabant | Jul 2005 | A1 |
20050188357 | Derks et al. | Aug 2005 | A1 |
20050204343 | Kisamore et al. | Sep 2005 | A1 |
20050257214 | Moshir et al. | Nov 2005 | A1 |
20060059253 | Goodman et al. | Mar 2006 | A1 |
20060064383 | Marking | Mar 2006 | A1 |
20060095276 | Axelrod et al. | May 2006 | A1 |
20060150188 | Roman et al. | Jul 2006 | A1 |
20060294045 | Suggs et al. | Dec 2006 | A1 |
20070101291 | Forstall et al. | May 2007 | A1 |
20070112574 | Greene | May 2007 | A1 |
20070133435 | Eneroth | Jun 2007 | A1 |
20070142936 | Denison | Jun 2007 | A1 |
20070201502 | Abramson | Aug 2007 | A1 |
20080005086 | Moore | Jan 2008 | A1 |
20080028392 | Chen et al. | Jan 2008 | A1 |
20080062863 | Ginde | Mar 2008 | A1 |
20080071651 | Markel | Mar 2008 | A1 |
20080165701 | Ananthanarayanan | Jul 2008 | A1 |
20080209392 | Able et al. | Aug 2008 | A1 |
20080222454 | Kelso | Sep 2008 | A1 |
20080263024 | Landschaft et al. | Oct 2008 | A1 |
20090037509 | Parekh et al. | Feb 2009 | A1 |
20090103769 | Milov et al. | Apr 2009 | A1 |
20090172814 | Khosravi et al. | Jul 2009 | A1 |
20090199160 | Vaitheeswaran et al. | Aug 2009 | A1 |
20090217309 | Grechanik et al. | Aug 2009 | A1 |
20090248693 | Sagar | Oct 2009 | A1 |
20090249297 | Doshi et al. | Oct 2009 | A1 |
20090307160 | Minh et al. | Dec 2009 | A1 |
20090313229 | Fellenstein et al. | Dec 2009 | A1 |
20090319608 | Anil | Dec 2009 | A1 |
20090320002 | Peri-Glass et al. | Dec 2009 | A1 |
20100023602 | Martone | Jan 2010 | A1 |
20100023933 | Bryant et al. | Jan 2010 | A1 |
20100061448 | Zhou | Mar 2010 | A1 |
20100100605 | Allen et al. | Apr 2010 | A1 |
20100107170 | Stehley | Apr 2010 | A1 |
20100135296 | Hwang | Jun 2010 | A1 |
20100235433 | Ansari et al. | Sep 2010 | A1 |
20100306005 | Yengulalp | Dec 2010 | A1 |
20110022578 | Fotev | Jan 2011 | A1 |
20110071841 | Fomenko | Mar 2011 | A1 |
20110099261 | Joshi | Apr 2011 | A1 |
20110145807 | Molinie et al. | Jun 2011 | A1 |
20110161943 | Bellows | Jun 2011 | A1 |
20110161976 | Alexander | Jun 2011 | A1 |
20110194684 | Ristock | Aug 2011 | A1 |
20110197121 | Kletter | Aug 2011 | A1 |
20110276568 | Fotev | Nov 2011 | A1 |
20110276946 | Pletter | Nov 2011 | A1 |
20110296528 | Shukla | Dec 2011 | A1 |
20110302570 | Kurimilla et al. | Dec 2011 | A1 |
20120011515 | Jolfaei et al. | Jan 2012 | A1 |
20120042281 | Green | Feb 2012 | A1 |
20120124062 | Macbeth et al. | May 2012 | A1 |
20120158990 | Losio et al. | Jun 2012 | A1 |
20120330940 | Caire et al. | Dec 2012 | A1 |
20130007753 | Jain | Jan 2013 | A1 |
20130085744 | Arias | Apr 2013 | A1 |
20130111470 | Bozek et al. | May 2013 | A1 |
20130173648 | Tan et al. | Jul 2013 | A1 |
20130179895 | Calder et al. | Jul 2013 | A1 |
20130254318 | Colar | Sep 2013 | A1 |
20130290318 | Shapira et al. | Oct 2013 | A1 |
20140101556 | Pinard | Apr 2014 | A1 |
20140164554 | Joshi et al. | Jun 2014 | A1 |
20140181705 | Hey et al. | Jun 2014 | A1 |
20140229582 | Liu | Aug 2014 | A1 |
20140237614 | Irvine | Aug 2014 | A1 |
20140365258 | Vestal | Dec 2014 | A1 |
20150006895 | Irvine | Jan 2015 | A1 |
20150043726 | Steiner | Feb 2015 | A1 |
20150082280 | Betak et al. | Mar 2015 | A1 |
20150120812 | Bobykin | Apr 2015 | A1 |
20150135183 | Kipp | May 2015 | A1 |
20150294258 | Hildebrand et al. | Oct 2015 | A1 |
20150347186 | Truong | Dec 2015 | A1 |
20150347284 | Hey et al. | Dec 2015 | A1 |
20160019049 | Kakhandiki et al. | Jan 2016 | A1 |
20160078368 | Kakhandiki et al. | Mar 2016 | A1 |
20160162331 | Geng | Jun 2016 | A1 |
20160170801 | Balsamo et al. | Jun 2016 | A1 |
20160226955 | Moorthi et al. | Aug 2016 | A1 |
20160246655 | Kimmel et al. | Aug 2016 | A1 |
20160292011 | Colson et al. | Oct 2016 | A1 |
20160301766 | Ionescu | Oct 2016 | A1 |
20160307127 | Katz et al. | Oct 2016 | A1 |
20160316022 | Takano et al. | Oct 2016 | A1 |
20160335069 | Dehmann et al. | Nov 2016 | A1 |
20170005940 | Haegdorens et al. | Jan 2017 | A1 |
20170060108 | Kakhandiki et al. | Mar 2017 | A1 |
20170134463 | Kim | May 2017 | A1 |
20170235504 | Susarla | Aug 2017 | A1 |
20180109587 | Spilka et al. | Apr 2018 | A1 |
20180191814 | Kinarti et al. | Jul 2018 | A1 |
20180197123 | Parimelazhagan et al. | Jul 2018 | A1 |
20180285294 | Reddy | Oct 2018 | A1 |
20180359301 | Zhao | Dec 2018 | A1 |
20190313422 | Pattan | Oct 2019 | A1 |
Entry |
---|
B. P. Kasper “Remote: A Means of Remotely Controlling and Storing Data from a HAL Quadrupole Gas Analyzer Using an IBM-PC Compatible Computer”, Nov. 15, 1995, Space and Environment Technology Center. |
Bergen et al., RPC automation: making legacy code relevant, May 2013, 6 pages. |
Hu et al., Automating GUI testing for Android applications, May 2011, 7 pages. |
Tom Yeh, Tsung-Hsiang Chang, and Robert C. Miller, Sikuli: Using GUI Screenshots for Search and Automation, Oct. 4-7, 2009, 10 pages. |
Zhifang et al., Test automation on mobile device, May 2010, 7 pages. |
Number | Date | Country | |
---|---|---|---|
Parent | 16024796 | Jun 2018 | US |
Child | 16146485 | US | |
Parent | 15957915 | Apr 2018 | US |
Child | 16024796 | US |