# US 12,117,894 B2 · Third-party software isolation using an actor-based model > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,117,894 B2 - Document ID: US12117894B2 - Status: Granted - Kind: B2 - Application number: 17/651,855 - Filed: 2022-02-21 - Published: 2022-08-25 - Granted: 2024-10-15 - Earliest claimed: 2021-02-22 - Assignees: Biosero Inc. - Applicants: Biosero Inc. - Inventors: Prabhakar Henry; William Berg; Corey McCoy; Lloyd A. Corkan; Andrew St. Yves; Jonathan David Dambman - Web page: https://patentgrep.com/patent/US12117894B2 ## CPC - G06F 9/4881: {Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues} - G06F 11/0793: {Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40)} - G06F 9/485: {Task life-cycle, e.g. stopping, restarting, resuming execution (G06F9/4881 takes precedence)} - G06F 9/541: {via adapters, e.g. between incompatible applications} - G06F 11/0721: {within a central processing unit [CPU]} - G06F 2209/481: Exception handling - G06F 2209/547: Messaging middleware - G06F 2209/548: Queue - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract A software framework for implementation in the performance of automated robotic workflows imparts a hierarchical communications command structure, utilizing an actor-based model to run driver software isolated from scheduling software, by instantiating a message-based abstraction layer that acts as an intermediary between the scheduling software and the third-party driver software. The actor-based model is used within the message-based abstraction layer to isolate the third-party software controlling third party instruments from scheduling software, where such scheduling software and third-party instruments are operating on a common computing platform. This framework prevents scheduling applications from entering an error state, or crashing, where the third-party software component also crashes, and allows the scheduling software to restart the third-party software to continue with the processes controlled by the scheduling software, without interruption to the automated workflow environment. ## Claims ### Claim 1 A method, comprising: receiving, as input data, scheduling information from a scheduling application for executing one or more workflow steps in an automated workflow environment, and device-related information from at least one third-party software application governing operation of a third-party instrument in response to the scheduling application to execute the one or more workflow steps, the scheduling application and the at least one third-party software application operating within a common computing platform; integrating the input data in a plurality of data processing elements within a computing environment that includes one or more processors and at least one computer-readable non-transitory storage medium having program instructions stored therein which, when executed by the one or more processors, cause the one or more processors to execute the plurality of data processing elements to implement an actor-based model that represents the at least one third-party software application as a recursive exception handling structure independent of the scheduling application to protect scheduling application integrity, by instantiating a message-based abstraction layer that includes an actor assigned to each third-party software application, to containerize the at least one third-party software application and isolate the scheduling application from each third-party software application within the common computing platform, each actor configured to act as a device software supervisor and communications interface by queueing one or more messages received from the scheduling application, and monitoring an event state of the third-party instrument to which the actor is assigned, and communicating event state information where the third-party instrument enters an exception state, the event state information indicative of an instruction that the at least one third-party software application cannot continue, by generating a notification to the at least one third-party software application representing the exception state of the third-party instrument; and either halting the failed actor, or restarting the failed actor, in response to an instruction from the scheduling application, and a generating a subsequent instruction to the third-party instrument entering the exception state, wherein the message-based abstraction layer replaces direct interface-based method calls in which messages and event state information are communicated between the scheduling application and each third-party software application, so that the at least one third-party software application is responsive only to messages from the actor when the third-party instrument is in the exception state to prevent the at least one third-party software application from crashing due to exception state. ### Claim 2 (depends on 1) The method of claim 1, wherein the exception state represents a failure of one or both of the at least one third-party software application and the third-party instrument. ### Claim 3 (depends on 1) The method of claim 1, wherein the at least one third-party software application is at least one of a driver application, a firmware application, a middleware application, or an operating system application. ### Claim 4 (depends on 1) The method of claim 1, wherein the monitoring an event state of the third-party instrument to which the actor is assigned further comprises communicating messages from each actor to the at least one third-party software application, and receiving responsive messages from the at least one third-party software application by each actor. ### Claim 5 (depends on 1) The method of claim 1, further comprising restarting the third-party instrument in response to the instruction communicated from the scheduling application after the at least one third-party software application enters a fail state. ### Claim 6 (depends on 1) The method of claim 1, wherein each actor replaces a component-based object model utilizing one or more application programming interfaces for communication between the scheduling application and the least one third-party software application as a separate process. ### Claim 7 (depends on 1) The method of claim 1, wherein the scheduling information includes operational data, the operational data including information representing an identification of one or more tasks in performing the one or more workflow steps, and defining the third-party party instrument responsible for performing the one or more tasks. ### Claim 8 A system comprising: one or more processors; a data collection engine configured to receive input data comprised of scheduling information from a scheduling application for executing one or more workflow steps in an automated workflow environment, and device-related information from at least one third-party software application governing operation of a third-party instrument in response to the scheduling application to execute the one or more workflow steps, the scheduling application and the at least one third-party software application operating within a common computing platform; and an actor instantiation engine configured to implement an actor-based model that represents the at least one third-party software application as a recursive exception handling structure independent of the at least one third-party software application to protect scheduling application integrity, within a message-based abstraction layer instantiated between the scheduling application and the at least one third-party software application, the message-based abstraction layer including an actor assigned to each third-party software application, to containerize the at least one third-party software application and isolate the scheduling application from each third-party software application within the common computing platform, wherein each actor is configured to act as a device software supervisor and communications interface by queuing one or more messages received from the scheduling application, monitoring an event state of the third party instrument to which the actor is assigned, communicating event state information where the third-party instrument enters an exception state, the event state information indicative of an instruction that the at least one third-party software application cannot continue by generating a notification to the scheduling application representing the exception state of the third-party instrument, receiving an instruction to either halt the failed actor, or restart the failed actor, from the scheduling application, and generating a subsequent instruction to the third-party instrument entering the exception state, wherein the message-based abstraction layer replaces direct interface-based method calls in which messages and event state information are communicated between the scheduling application and each third-party software application, so that the third-party software application is responsive only to messages from the actor when the third-party instrument is in the exception state to prevent the scheduling application from crashing due to exception state. ### Claim 9 (depends on 8) The system of claim 8, wherein the exception state represents a failure of one or both of the at least one third-party software application and the third-party instrument. ### Claim 10 (depends on 8) The system of claim 8, wherein the at least one third-party software application is at least one of a driver application, a firmware application, a middleware application, or an operating system application. ### Claim 11 (depends on 8) The system of claim 8, wherein the actor-based model is further configured to communicate messages from each actor to the at least one third-party software application, and receiving responsive messages from the at least one third-party software application by each actor. ### Claim 12 (depends on 8) The system of claim 8, wherein a third-party instrument is restarted in response to the instruction communicated from the scheduling application after the at least one third-party software application enters a fail state. ### Claim 13 (depends on 8) The system of claim 8, wherein each actor replaces a component-based object model utilizing one or more application programming interfaces for communication between the scheduling application and the least one third-party software application as a separate process. ### Claim 14 A method of isolating scheduling software from third-party software in an automated workflow environment, comprising: instantiating a message-based abstraction layer between a scheduling application and at least one third-party software application operating within a common computing platform, the at least one third-party software application governing operation of a third-party instrument in response to the scheduling application to execute one or more workflow steps within an automated workflow environment, in an actor-based model that represents the at least one third-party software application as a recursive exception handling structure independent of the scheduling application to protect scheduling application integrity, wherein the actor-based model includes an actor assigned to each third-party software application, and each actor is configured to act as a device software supervisor and communications interface; applying the actor-based model to containerize the at least one third-party software application and isolate the scheduling application from each third-party software application within the common computing platform, by queueing one or more messages received from the scheduling application, and monitoring an event state of the third-party instrument to which the actor is assigned, communicating event state information where the third-party instrument enters an exception state, the event state information indicative of an instruction that the at least one third-party software application cannot continue, by generating a notification to the scheduling application representing the exception state of the third-party instrument; and either halting the failed actor, or restarting the failed actor, based on one or more messages communicated from the scheduling application, and a generating subsequent instruction to the actor assigned to the third-party instrument entering the exception state, wherein the message-based abstraction layer replaces direct interface-based method calls in which messages and event state information are communicated between the scheduling application and each third-party software application, so that the at least one third-party software application is responsive only to messages from the actor when the third-party instrument is in the exception state to prevent the scheduling application from crashing due to exception state. ### Claim 15 (depends on 14) The method of claim 14, wherein the scheduling application provides system-level scheduling information for executing the one or more workflow steps in the automated workflow environment, and the one or more third-party software applications provide device-level information related to each third-party instrument in the automated workflow environment. ### Claim 16 (depends on 14) The method of claim 14, wherein the exception state represents a failure of one or both of the at least one third-party software application and the third-party instrument. ### Claim 17 (depends on 14) The method of claim 14, wherein the at least one third-party software application is at least one of a driver application, a firmware application, a middleware application, or an operating system application. ### Claim 18 (depends on 14) The method of claim 14, wherein the monitoring an event state of the third-party instrument to which the actor is assigned further comprises communicating messages from each actor to the at least one third-party software application, and receiving responsive messages from the at least one third-party software application by each actor. ### Claim 19 (depends on 14) The method of claim 14, further comprising restarting the third-party instrument in response to the instruction communicated from the scheduling application after the at least one third-party software application enters a fail state. ### Claim 20 (depends on 14) The method of claim 14, wherein each actor replaces a component-based object model utilizing one or more application programming interfaces for communication between the scheduling application and the at least one third-party software application as a separate process.