Patent classifications
G06F9/485
Robotic process automation system with device user impersonation
A robotic process automation system provides a capability to deploy software robots (bots) by receiving from a deployment user a bot deployment request comprising a bot identification that identifies a specific preexisting bot and an authorized class of user to execute the specific preexisting bot. Credentials of the deployment user are checked. An execution device upon which the specific preexisting bot will execute is identified from a set of available devices. An authorization token is issued for the execution device to uniquely identify the execution device and to authorize the execution device to communicate with the robotic process automation system. In response to a request by the execution device the specific preexisting bot and credentials corresponding to the authorized class of user are provided, wherein the specific preexisting bot executes on the execution device automatically without input from any individual corresponding to the authorized class of user.
System and method for appraising resource configuration
To more properly size resources in a destination to which IT resources will be migrated, a system for appraising a resource configuration estimates a source's load model representing a load of first resources in a first computer system which is the source of migration and estimates a destination's load model representing a load of second resources to be built by migrating the first resources to a second computer system based on the source's load model. The system compares performance requirements of the first resources against the destination's load model and finds the destination's load model that is conformable to the performance requirements. When determining design values of the second resources' configuration, the system corrects those design values based on the destination's load model estimated conformable to the performance requirements to decrease design margins of the resource configuration using a design correction value defined to meet a service level requested.
Signaling timeout and complete data inputs in cloud workflows
There is included a method and apparatus comprising computer code configured to cause a processor or processors to perform obtaining an input of at least one of a task and a workflow, setting a timeout for the input of the at least one of the task and the workflow, determining whether the at least one of the task and the workflow observes a lack of data of the input for a duration equal to the timeout, determining, in response to determining that the at least one of the task and the workflow observed the lack of data of the input for the duration equal to the timeout, an unavailability of further data of the input, applying an update to the at least one of the task and the workflow based on determining the unavailability, and processing the at least one of the task and the workflow.
Offloading execution of a multi-task parameter-dependent operation to a network device
A network device includes a network interface, a host interface and processing circuitry. The network interface is configured to connect to a communication network. The host interface is configured to connect to a host including a processor. The processing circuitry is configured to receive from the processor, via the host interface, a notification specifying an operation for execution by the network device, the operation including (i) multiple tasks that are executable by the network device, and (ii) execution dependencies among the tasks in response to the notification, the processing circuitry is configured to determine a schedule for executing the tasks, the schedule complying with the execution dependencies, and to execute the operation by executing the tasks of the operation is accordance with the schedule.
Hypervisor hibernation
Upon receiving a request to hibernate a hypervisor of a virtualization system running on a first computer, acts are carried out to capture a state of the hypervisor, where the state of the hypervisor comprises hypervisor logical resource parameters and an execution state of the hypervisor. After hibernating the hypervisor by quiescing the hypervisor and storing the state of the hypervisor into a data structure, the data structure is moved to a different location. At a later moment in time, the data structure is loaded onto a second computing machine and restored. The restore operation restores the hypervisor and all of its state, including all of the virtual machines of the hypervisor as well as all of the virtual disks and other virtual devices of the virtual machines. Differences between the first computing machine and the second computing machine are reconciled before execution of the hypervisor on the second machine.
Techniques for scheduling between applications on a core
A method of managing operation of a computing device is provided. The method includes (a) running a system scheduler that schedules execution of a first application and a second application on a central processing unit (CPU) core of the computing device; (b) while the first application is executing on the core, detecting, by the first application, a context-switch opportunity; and (c) issuing, by the first application in response to detecting the context-switch opportunity, a blocking operation that triggers the system scheduler to perform a rescheduling operation between the first and second applications on the CPU core. An apparatus, system, and computer program product for performing a similar method are also provided.
FAULT-TOLERANT VARIABLE REGION REPAVING DURING FIRMWARE OVER THE AIR UPDATE
Variables utilized in device firmware that provides various boot and runtime services are repaved in a fault-tolerant manner within a secure store in a durable, non-volatile device memory during an FOTA update process. A spare region in the secure store is utilized to temporarily hold a back-up of a primary region in which the firmware variables are written. Using a transaction-based fault-tolerant write (FTW) process, the variables in the primary region can be repaved with variables contained in a firmware update payload that is delivered from a remote service. In the event of a fault in the variable region repaving process, either the primary or spare region will remain valid so that firmware in a known good state can be utilized to enable the device to boot successfully and the variable region repaving in the FOTA update process may be restarted.
System and method for multi-tenant implementation of graphics processing unit
A method for graphics processing, wherein a graphics processing unit (GPU) resource is allocated among applications, such that each application is allocated a set of time slices. Commands of draw calls are loaded to rendering command buffers in order to render an image frame for a first application. The commands are processed by the GPU resource within a first time slice allocated to the first application. The method including determining at least one command has not been executed at an end of the first time slice. The method including halting execution of commands, wherein remaining one or more commands are not processed in the first time slice. A GPU configuration is preserved for the commands after processing a last executed command, the GPU configuration used when processing in a second time slice the remaining commands.
Method for migrating CPU state from an inoperable core to a spare core
An apparatus is disclosed in which the apparatus may include a plurality of cores, including a first core, a second core and a third core, and circuitry coupled to the first core. The first core may be configured to process a plurality of instructions. The circuitry may be may be configured to detect that the first core stopped committing a subset of the plurality of instructions, and to send an indication to the second core that the first core stopped committing the subset. The second core may be configured to disable the first core from further processing instructions of the subset responsive to receiving the indication, and to copy data from the first core to a third core responsive to disabling the first core. The third core may be configured to resume processing the subset dependent upon the data.
Shadow stack violation enforcement at module granularity
Enforcing shadow stack violations at module granularity, rather than at thread or process granularity. An exception is processed during execution of a thread based on code of an application binary, which is enabled for shadow stack enforcement, that calls an external module. The exception results from a mismatch between a return address popped from the thread's call stack and a return address popped from the thread's shadow stack. Processing the exception includes determining that the exception resulted from execution of an instruction in the external module, and determining whether or not the external module is enabled for shadow stack enforcement. Based at least on these determinations, execution of the thread is terminated when the external module is enabled for shadow stack enforcement, or the thread is permitted to continue executing when the external module is not enabled for shadow stack enforcement.