DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Remarks
The present application having Application No. 18/747,652 filed on 06/19/2024 presents claims 1-20 for examination.
The present application claims priority to foreign application (GB2406933.8) file on 05/16/2024.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statements (IDSs), submitted on 06/19/2024, 01/31/2025 and 11/07/2025, are acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 13-17, 19 and 20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2022/0050705 A1) (hereinafter Shen) in view of Harwood et al. (US 2020/0142753 A1) (hereinafter Harwood) and further in view of Kreutzer et al. (Kreutzer_6May2024.pdf: Migration of Isolated Application Across Heterogeneous Edge Systems, 2024 IEEE 8th International Conference on Fog and Edge Computing (ICFEC), pp. 64-70, Published May 6, 2024) (hereinafter Kreutzer).
As per claim 1, Shen discloses A computer implemented method of operating a computing environment to perform a live migration of a running process from a current computing node to an alternative computing node (e.g., Shen: [Abstract] [0002] discloses method for migrating executing containerized processes from one machine to another. [0004] disclose a method for migrating executing process, where the scheduler component execution on the first machine determines to migrate the containerized process to a third machine, during execution of the containerized process. [0012] discloses method and system for migrating executing containerized processes during execution of the containerized process. [Fig. 2] [0036] discloses a scheduler component determines to migrate a containerized process executing on a first machine to a third machine and directs migration during execution of that process. Also see [Figs. 1A-1D] [0013-0014] [0016] [0021] [0025] [0032] [0034] for corresponding system.), wherein the current computing node is configured for executing an application binary using a sandboxed runtime environment that comprises an application binary interface (e.g., Shen: [0016] discloses that a computing device may instantiate a container image as a containerized process. [0017] discloses that each computing device may run a sandbox. [0019-0020] disclose execution of a containerized process using a dedicated OS kernel, which may be isolated from the process or mapped as a library into the process address space. [0029] further discloses that a sandbox typically encapsulates at least one container, storage resources associated with the at least one container, and a unique identity. Also see [Figs. 1A-1C and related description] [0044]. Accordingly, Shen teaches running an application/process in an isolated sandbox execution environment.), wherein the alternative computing node is configured for executing the application binary using the sandboxed runtime environment that comprises the application binary interface (e.g., Shen: [0031-0032] disclose that an agent receives instructions to migrate a containerized process from a second computing device to a third computing device and performs migration during execution of the containerized process. [0043-0044] disclose migration of the containerized process from computing device 106b to computing device 106c, where the receiving computing device executes the migrated VM/sandbox containing the containerized process and associated agent.), wherein the application binary interface has a node hardware independent instruction set, wherein the method comprises: continually monitoring the running process on the current computing node to see if it meets a predetermined transfer criterion (e.g., Shen: [0034] discloses that the scheduler component may monitor status of the system and may trigger migration based on one or more policies, including policies for optimizing cost, minimizing latency, or increasing availability. [0036] scheduler component determines whether to migrate the containerized process to another machine. [0045] further discloses monitoring resource usage by a containerized process and identifying a machine that provides more efficient resource use; Shen also discloses that the scheduler may determine that the destination machine provides a higher level of efficiency or optimization, where threshold level of efficiency and optimization may be specified by users. [0046] further discloses migration responsive to availability and cost conditions, including when the source machine becomes unavailable when its price increases, or when another machine become available at a lower price. Thus, Shen teaches monitoring a running containerized process/system status against predetermined policy or threshold criteria to determine whether to initiate migration.); adding the running process to a workload queue if the predetermined transfer criterion is detected; and migrating the running process from the current computing node to the alternative computing node (e.g., Shen: [0036] discloses a scheduler determining to migrate a containerized process to a third machine and directing migration during execution. [0043-0044] disclose the scheduler instructing the migration of process between source computing device 106b and destination computing device 106c, including migration of the containerized process and its associated execution environment. Also see [Abstract] [0002] [0004] [0014] [0021] [0025] [0031-0032] [0040] [0045-0047].), wherein the migration of the running process comprises a transfer of stateful network connections from the current computing node to the alternative computing node (e.g., Shen: [0029-0032] disclose a shim process communicating with an agent through a proxy via a network connection, the virtualized network supporting migration. [0030] discloses that the established network connection allows the agent and shim process to communicate even if there is a migration of the containerized process and the associated agent 111 to a different machine. [0040-0041] further disclose network communication that enables transparent migration of the executing process. [0044] discloses that, after migration, the network is reconfigured so that the connection between the agent 111 and shim process is transparently maintained, and that the connection between the network, file system, and proxy persist so execution may continue substantially uninterrupted.).
Shen does not expressly disclose wherein the method comprises: continually monitoring the running process…to see if it meets a predetermined transfer criterion”; and adding the running process to a workload queue if the predetermined transfer criterion is detected.
However, Harwood discloses continually monitoring the running process on the current computing node to see if it meets a predetermined transfer criterion (e.g. Harwood: [0028] discloses a workload monitor module that monitors performance of running workload based on real-time resource-usage telemetry on a per-workload/application basis. [0029] discloses that the telemetry is continually measured/tracked and periodically reported, and includes network bandwidth usage, CPU and accelerator utilization, storage throughput, and other resource-usage information used to identify a communication overload or bottleneck. [0037-0039] discloses monitoring performance of an executing workload in real-time to detect a bottleneck condition that causes decreased workload performance. In response to detecting a bottleneck condition, the provisioning module will determine and provision a second set of resources to the executing workload to reallocate to the executing workload. The live migration is then invoked to perform a live migration process to move the executing workload to the reallocated set of resources. [0045-0046] disclose monitoring performance of an executing workload in real time to determine whether performance decreases or does not meet an expected performance level. [0012] discloses migrating live workloads to a remote computing system, to increase workload execution performance and resource utilization. Also see [0030-0031]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Shen’s scheduler-controlled transparent migration of an executing containerized process with Harwood’s real-time workload-monitoring and bottleneck-detection techniques. Shen teaches scheduler-directed migration of an executing containerized process among computing devices based on policies directed to cost, latency, availability, efficiency, and optimization. Harwood teaches continuous measurement of running-workload telemetry, real-time detection of a bottleneck or reduced-performance condition, resource allocation, and live migration of the executing workload such that workload execution continues using the reallocated resources. A POSITA would have been motivated to use Harwood’s known real-time monitoring and condition-detection techniques in Shen to automatically and dynamically determine when the executing containerized process should be migrated to improve workload/process performance and resource utilization, and avoid the predictable degradation associated with leaving the workload at an inefficient source node. The modification would have yielded the predictable result of condition-based live migration of a running containerized process.
Furthermore, Harwood discloses adding the running process to a workload queue if the predetermined transfer criterion is detected (e.g., Harwood [0014] nevertheless discloses a service controller comprising a global service scheduler and request queue module. [0032] discloses storing service requests in a request queue that is controlled by the global schedule and request queue module. A service request includes user-specified conditions and demands for executing a given job/request. [0033] discloses the service request and associated specifications are stored in the request queue. The scheduler and associated resource-allocation functionality use the application ID, constraints, policies, user-specified conditions, current topology, and current resource usage to determine and allocate suitable resources for a workload ([0027, 0032-0033]).).
Harwood additionally discloses that, in response to detection of a bottleneck condition for an executing workload, resource-allocation/provisioning functionality determines another resource set, and the live-migration module migrates the executing workload to that reallocated resource set ([0037]). Thus, Harwood teaches both an executing workload determined to require migration because of a detected performance/bottleneck condition, and a scheduler/request-queue mechanism for storing workload/request and scheduling workloads from the queue based on available system resources and policies.
It would have been obvious to one or ordinary skill in the art to modify Shen-Harwood system by adding an entry representing the running migration-eligible process, or a migration request identifying that process, to Harwood’s scheduler/request queue after the monitoring criterion is detected and before migration. Harwood already teaches a global scheduler-and-request-queue module that holds workload service requests pending scheduling and uses resource/policy information to migrate workload; Shen teaches a scheduler that manages migration of executing containerized processes. A POSITA would have been motivated to use Harwood’s request queue for the migration-eligible running process in order to queue, prioritize, defer, coordinate, and allocate a target node/resource set for migration in light of concurrently pending workload requests and the current topology/resource state. This would avoid uncoordinated direct migration decisions, permit target selection through the scheduler’s established allocation mechanisms, improve resource utilization, and make condition-responsive live migration compatible with ordinary distributed workload scheduling. The resulting sequence—detecting a transfer criterion, placing running workload into the queue, selecting destination resource/node, and live-migrating the process—would have been a predictable use of known scheduling and migration components according to their established functions.
The combination of Shen and Harwood does not expressly disclose “a sandboxed runtime environment that comprises and application binary interface, wherein the application binary interface has a node hardware independent instruction set.”
However, Kreutzer discloses wherein the current computing node is configured for executing an application binary using a sandboxed runtime environment that comprises an application binary interface, wherein the alternative computing node is configured for executing the application binary using the sandboxed runtime environment that comprises the application binary interface, wherein the application binary interface has a node hardware independent instruction set (e.g. Kreutzer: [p. 66, Sec. III, A. Isolated Application Execution Environment] discloses that its architecture for execution of isolated application is “based on Wasm,” and that “Wasm offers a cross-platform, isolated execution environment.” Kreutzer discloses that applications are connected to the system architecture through and “embedder,” which is responsible for connecting an application through communication protocols. Kreutzer further describes two application/embedder interface types: a language-binding-generator interface and a serialization interface, in which metadata and event data are transferred between the application and the embedder using application memory, pointers, and target-function information. (Kreutzer, pp.66-67).). Kreutzer further discloses “wherein the application binary interface has a node hardware independent instruction set” (e.g., Kreutzer: [p. 67, Sec. III-B. Application Migration] discloses that “the memory layout of the application is a result of only the application’s source code and the virtual instruction format, the is, WebAssembly,” and therefore “is independent of the host architecture and operating system.” Kreutzer further discloses copying the actual application, which may be transferred in “the Wasm format or as host-specific pre-compiled binary code”; transferring application state to a locally existing destination application and restarting the application “in the same state as before”; and a full migration that transfers both the application and its state.).
Kreutzer further teaches execution and migration among heterogeneous nodes (e.g., Kreutzer: [pp. 66-67, Fig. 1] identifies ARM and x96-64 hardware in connection with the WebAssembly application execution environment. Kreutzer [p. 68-69, Sec. IV] evaluates migration between a workstation and a Raspberry Pi. Kreutzer also describes migration of applications across compute nodes having different CPU architectures and a runtime environment for isolated applications migration in a distributed system with different CPU architectures.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Shen-Harwood system to execute the migration process as a Kreutzer WebAssembly application in a cross-platform, isolated execution environment. Kreutzer teaches use of WebAssembly as a portable virtual instruction format, and application-to-embedder interface, and application memory layout independent of host architecture and OS. Kreutzer also teaches migration of an application and application state across compute nodes having different CPU architectures. A POSITA would have been motivated to incorporate Kreutzer’s known portable Wasm application environment into the Shen-Harwood system so that the same application binary could be executed at the source and destination nodes despite different underlying hardware, while retaining sandboxed execution. The predictable result would be improved portability, reduced dependence on a source node’s native architecture, and more flexible placement/migration of live workload based on detected system conditions.
As per claim 2, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], Kreutzer further discloses wherein the sandboxed runtime environment is a WebAssembly runtime (e.g. Kreutzer: [Abstract] discloses a migration method for isolated applications across heterogenous nodes. The migration method enables the fast migration of sandboxed applications based on WebAssembly. Kreutzer: [p. 64, col. 2] discloses integrating WebAssembly into edge architecture, the architecture is based on applications that are executed in the WebAssembly VM. [p. 65, col. 2, C. CPU independent VM] discloses WebAssembly (Wasm) is a virtual instruction-set architecture widely used to execute applications in different execution environments in an isolated manner. [p. 66, col. 1, A. Isolated Application Execution Environment] discloses that the architecture for the execution of isolated application is based on Wasm and Wasm offers a cross-platform, isolated execution environment. Also see [p. 67, col. 2].).
As per claim 3, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], Kreutzer further discloses wherein the current computing node and the alternative computing node have mutually incompatible instruction set architectures (e.g., Kreutzer: [p. 66, Sec. III-A.] discloses that the architecture for isolated application execution is based on Wasm and that Wasm offers a cross-platform isolated execution environment. [p. 66, Fig. 1] identifies a WebAssembly application/embedding environment associated with distinct hardware architecture, including ARM and x86-64. [p. 67, Sec. III-B] further discloses that the memory layout of the application is a result of only the application’s source code and the virtual instruction format, that is, WebAssembly and is independent of the hot architecture and OS. Kreutzer further teaches that the application can be transferred in Wasp format or a host-specific precompiled binary code, and that application state may be transferred to a destination application so that it restarts in the same sate as before [p. 67, Sec. III-B]. Kreutzer also confirms that its architecture is used for migration among heterogenous computer resources [p. 65, Sec. IV; p. 69, Sec IV-B]. Kreutzer states that a runtime environment for isolated applications that can be migrated across different compute nodes of a disturbed system with different CPU architectures for edge systems [p. 70, Conclusion].).
As per claim 4, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], Kreutzer further discloses wherein the sandboxed runtime environment comprises an application memory configured for storing random access memory accessible to the running process and an executable of the running process (e.g. Kreutzer: [pp. 66-67, Sec. III-A] discloses a WebAssembly application execution environment in which the interface allocates required memory in the memory of the application and copies event data into that memory. Kreutzer further discloses that a pointer to the data in the internal memory of the application is passed to the application endpoint such that the application accesses the transferred data. [p. 66, Sec. III-A, Fig. 2] also discloses that application data are stored in Application Memory, as shown in Figs. 2 and 3. [pp. 66-67, Figs. 2-3; p. 67, Sec. III-B] further discloses that an application may be transferred in the Wasm format or as host specific pre-compiled binary code. Thus, Kreutzer teaches a sandboxed Wasm runtime having application-accessible memory and an executable application binary.), and a state memory configured for storing a runtime state of the running process (e.g., Kreutzer: [p. 67, Sec. III-B] discloses that, while idle, an application only utilizes its memory, tables, and global variables, which are all accessible from the embedder, through standard interfaces. Kreutzer further discloses a state-migration operation in which the state of an application is transferred and applied to a locally existing application and the embedder can then restart the application in the same state as before. Kreutzer additionally teaches a full migration that transfers both state and application in a single step. [p. 67, Sec. III-B; Fig. 4] which show separately identifying Application and State information for migration. Accordingly, Kreutzer teaches maintaining runtime state, including application memory, tables, and global variables, for transfer and restoration at ta destination node.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to organize the portable sandboxed runtime environment of the Shen-Harwood-Kreutzer combination such that the application-accessible memory and executable application code are maintained as an application-memory and the transferred application execution state is maintained as a state-memory. Kreutzer expressly teaches separate handling of the application and its state during copy, light-state, and full-migration operations, with the destination application restarting in the same state. Organizing the application memory and runtime state as respective logical memory components would have been a predictable implementation of Kreutzers’ disclosed state/application separation as it would facilitate independent capture, transfer, and restoration of the executable application and runtime state during live migration.
As per claim 13, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], Harwood further discloses wherein the computing environment further comprises the workload queue (e.g., Harwood: [0014] discloses the service controller comprises a global service request scheduler and request queue module 141. [0032] disclose storing received service requests in a request queue that is controlled by the global schedule and request queue module. [0033] discloses the service request and associated provisioning specifications are stored in the request queue pending scheduling by the global scheduler and request queue module.).
As per claim 14, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], wherein the computing environment further comprises a global optimizer component, wherein the global optimizer component is further configured for continually monitoring the running process on the current computing node to see if it meets the predetermined transfer criterion (e.g., Shen: [0034] provides support for the global optimization and policy-based migration aspects. Shen teaches scheduler component 121, which managers migrations, monitors system status, and triggers migration according to policies for optimizing cost, minimizing latency, and increasing availability. [0045] Shen further teaches monitoring resource usage by a containerized process and identifying and alternative/target computing device that provides higher level of efficiency or optimization for hosting the process. Harwood: [0013-0014][Fig. 1] teach a service controller 140 that performs global control and optimization functions across a distributed computing environment. The service controller includes global scheduler and request queue module, resource allocation and provisioning module, workload monitor module, live migration module, topology determination module. Harwood’s service controller, including the coordinated workload monitor, topology analysis, resource-allocation, scheduler and live migration modules teaches or at least renders obvious the claimed global optimizer component because it monitors workloads and system resources across the computing platform and determines how to reallocate workloads for improved performance and resource utilization. Harwood: [0005, 0026-0029, 0035, 0037]. [0028-0029] Harwood teaches workload monitor module monitors performance of running workloads and collects real-time telemetry on a per-application/workload basis. The telemetry is continually measured or tracked and periodically reported, for example every five seconds, and is stored in a resource-usage database associated with the Application ID of the running workload. [0005, 0037] teach monitoring the performance of an executing workload in real-time to detect a bottleneck condition causing decreased workload performance. In response to detecting the bottleneck condition, the system determines another set of resources and invokes live migration to move the workload to the reallocated resources. Also see [0045-0047]. Thus, Harwood’s bottleneck or reduced-performance condition teaches or renders obvious the claimed predetermined transfer criterion. Harwood continually monitors a running workload to determine whether the condition has occurred and initiates workload migration when that condition is satisfied.).
As per claim 15, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 14 [See rejection to claim 14 above], wherein the predetermined transfer criterion comprises any one of the following: the running process exceeds a predetermined processing capacity of the current computing node, the running process exceeds a predetermined storage capacity of the application memory, the running process on the current computing node has a latency above a predetermined latency, the running process has a predetermined code or software library dependency, and combinations thereof (e.g. Shen: [0034] teaches scheduler component monitoring system status and triggering migration based on policies including optimizing cost, minimizing latency or increasing availability. [0045-0046] further teaches monitoring resource usage by a containerized process and identifying a destination computing device offering more efficient resource usage. Harwood: [0028, 0034, 0037-0039] also teach monitoring executing workloads for bottlenecks caused by increased CPU demand. Harwood collects real-time utilization and other resource-usage telemetry, detects bottleneck that reduces workload performance, determines a different resource set or target node, and migrates the workload to that resource set or node. [0036-0039] teach monitoring communication latency and bandwidth for a workload and detecting a bottleneck when communication latency increases or bandwidth decreases. Harwood then reallocates resources and migrates the workload to improve performance.).
As per claim 16, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], wherein the current computing node is a handheld telecommunications device, and wherein the alternative computing node is a remote host (e.g. Shen: [Fig. 3A] discloses local client nodes include that is a handheld telecommunication device such as mobile phone 302n or laptop 302b; and remote machines 306a-n. [Fig. 3A] [0057-0061] discloses a network environment having clint/local machines 302a-1 in communication with remote machines/server 306a-1 through network 304. A client 302 may be a portable computer, mobile telephone, mobile smart phone, or other portable telecommunication device. The remote computing device 306 may provide functionality of web server or cloud-based web servers. Also see [0004, 0032, 0043-0044].).
As per claim 17, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 16 [See rejection to claim 16 above], wherein the remote host is any one of the following: a cloud-based server and an edge-based computing device (e.g. Shen: [Fig. 3A] [0057-0062] show client machine 302a-n communicating via network 304 with remote machine/servers 306a-n. Shen identifies the remote machine as servers or computing devices. Shen then explains that a computing device 306 may provide web-server functionality and can include cloud-based web servers where a third party hosts the hardware executing the web-server functionality. [0047] teaches migration across network and from machines maintained by one entity to machines maintained by another entity. Kreutzer: [Abstract, Title] further discloses migration of isolated application across heterogeneous edge system.).
As per claim 19, this is a computer readable storage medium claim having similar limitations as cited in method claim 1. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
As per claim 20, this is a system claim having similar limitations as cited in method claim 1. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
Claims 5-7 and 9-10 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Shen in view of Harwood and Kreutzer, and further in view of Cao et al. (US 2021/0200573 A1) (hereinafter Cao).
As per claim 5, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 4 [See rejection to claim 4 above], wherein migrating the running process from the current computing node to the alternative computing node (e.g., Shen: [Abstract] [0002] [0004] [0014] [0021] [0030-0032] [0036] expressly disclose migrating executing containerized process form source machine/device to another machine/device. Harwood: [0005] [0010] [0012] [0030] [0038-0039] also discloses dynamic live-migration of a run-time workload from a source computing device to a remote/target computing device. Kreutzer: [Abstract] also discloses migration of isolated application across heterogenous edge systems. [p. 67, Fig. 4] discloses copy, full migration and light migration methods for migrating application from a source node to a destination node.) comprises: copying contents of the application memory of the current computing node to the application memory of the alternative computing node (e.g., Shen: [0040] discloses establishing connection between a local file system and a remote file system such that, when the container makes changes to data within the remote file system, the local file system retains an up-to-date copy of the accessed data; upon migration to a different machine, the local file system retains the current data. Also see [0049]. Harwood: [0031] discloses that VMotion encapsulates the entire state of a VM, and that active memory and precise execution state” are transferred over a network so the workload switches from a source host to a destination host. Kreutzer: [p. 66, Sec. III-A, Figs. 2-3] discloses application memory in a Wasm application environment, including allocation of data in application memory and copying of event data into application memory. [p. 67, Sec. III-B] further discloses that application memory layout is independent of host architecture and OS, and that the application can be transferred in Wasm formant or as host-specific precompiled binary code.); suspending the running process on the current computing node (e.g. Kreutzer: [p. 67, Sec. III-B] discloses that in its state-migration and full migration methods, the application is stopped on the source host, whereas the application remains active on the source node during copy migration. Kreutzer thereby teaches suspension/stopping of the source application in connection with migration and transferring application state.); synchronizing the application memory of the alternative computing node with the application memory of the current computing node (e.g., Shen: [0040] discloses maintaining an up-to-date version of data modified by the executing container at a remote file system, such that, if the container is moved to another machine, the local file system retains the current copy of all accessed data. Harwood: [0031] teaches transfer of active memory and precise execution state to permit a workload to switch from source to destination with continuous service. Kreutzer: [p. 67, Sec. III-B] discloses that, for a given application receiving the same inputs events in the same order, the application’s memory content and layout will always be the same, and further describes applying transferred state to an existing destination application so it restarts in the same state as before. These disclosures support the general idea of producing a current, corresponding destination-side application-memory/state image.); transferring contents of the state memory of the current computing node to the state memory of the alternative computing node (e.g., Harwood: [0031] discloses transfer of active memory and precise execution state from source host to destination host. Kreutzer: [p.67, Sec. III-B] discloses state migration in which the state of an application is transferred and applied to locally existing application, and the destination embedder restarts the application in the same state as before. Kreutzer further teaches full migration in which both state and application are transferred in a single step. Shen: [0043-0044] discloses migration of the containerized process and associated agent/VM to the receiving machine while maintaining network communication.); and resuming the running process on the alternative computing node (e.g., Shen: [0043-0044] discloses after migration the VM executes on the receiving computing device, and its network is reconfigured so communications are maintained and execution of the containerized process may continue substantially uninterrupted. Hardwood: [0031] discloses that transfer of active memory and precise execution state allows the VM to instantaneously switch from running at the source host to the destination host; active connections are preserved, resulting in zero downtime and continuous service availability. Kreutzer: [p. 67, Sec. III-B] discloses that after the state of the application is applied to the existing destination application, the embedder can then restart the application in the same state as before.).
As discussed above, the cited prior arts individually disclose/imply “copying,” “suspending,” “synchronizing,” “transferring,” and “resuming” steps, but the combination does not expressly disclose claimed complete ordered procedure of copying, suspending, synchronizing, transferring and resuming in that sequence.
However, Cao expressly discloses Cao discloses copying contents of the application memory of the current computing node to the application memory of the alternative computing node (e.g., Cao: [0094-0098] discloses VM memory-state migration that include an iterative pre-copy phase. Cao explains that after migration begins, the VM remains running on the source server and all memory of the VM is copied to a destination server, after which changed memory data of the VM is iteratively copied to the destination server. Cao [0147-0148] states that a VM manager copies the memory data iteratively. Fig.5, step 503 “Copy memory data iteratively.”); suspending the running process on the current computing node (e.g., Cao: [0097] discloses a stop-and-copy phase in which the VM is suspended. [0178-0179] further states that the VM manager invokes a suspension procedure to suspend the first VM. Fig. 5, step 505 “A first VM is suspended.”); synchronizing the application memory of the alternative computing node with the application memory of the current computing node (e.g., Cao: [0096] discloses that, after all source VM memory is initially copied, changed memory data are iteratively copied to the destination. [0097] discloses that, after source-VM suspension, residual memory data are copied. [0147-0148] discloses iterative copying and a transition to a stop-and-copy phase when the remaining memory can be copied once. [0180-0181] further discloses that after suspending the source VM, the manager copies the memory for the last time and migrates memory not copied during the earlier iterative-copy stage to the destination. These steps update the destination memory with source-memory changes made while the source remained active, thereby synchronizing destination memory with source memory before resumption.); transferring contents of the state memory of the current computing node to the state memory of the alternative computing node (e.g., Cao: [0007] discloses that information to be migrated includes state information of the first virtual network adapter and memory data of the first VM. [0111-0118] discloses obtaining source VM memory data and virtual network adapter state information and sending both to the destination server for restoration. [0182-0187] discloses obtaining state information for the source virtual network adapter and copying/sending it to the destination VM manager, which restores that state information. [Fig. 5, steps 507-508] “Obtain state information of network adapter” and “migrate and restore the state information of the virtual network adapter.”); and resuming the running process on the alternative computing node (e.g., Cao: [0098] discloses a restoration phase in which the destination VM completes restoration processing and the destination VM is started. [0121-0130] disclose receiving state information at the destination, restoring the state information, and enabling the second VM to complete live migration. [Fig. 5, step 509] “enable a second VM.”).
It would have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the Shen-Harwood-Kreutzer migration system to use Cao’s iterative pre-copy, source-suspension, final-copy, state-restoration, and resumption procedure. Shen teaches transparent migration of an executing containerized process between computing devices. Harwood also teaches live migration of an executing workload and the transfer of active memory and precise execution state to obtain continuous service. Kreutzer teaches migrating a portable Wasm application and its state between heterogeneous nodes. Cao teaches the known technique for reducing migration interruption: copying source memory while the source remains active, suspending the source only for a stop-and-copy phase, transferring residual changed memory and state information, restoring that information at the destination, and enabling resumption of VM/process at the destination. A POSITA would have been motivated to employ Cao’s known pre-copy procedure in the Shen-Harwood-Kreutzer system to reduce the time the running sandboxed application is suspended while ensuring that the alternative node receives updated memory and execution states before resuming the operation. The resulting migration procedure would have been predictable and would have improved service continuity, migration reliability, and workload availability.
As per claim 6, the combination of Shen, Harwood, Kreutzer and Cao discloses The computer implemented method of claim 5 [See rejection to claim 5 above], wherein resuming the running process on the alternative computing node comprises any one of the following: compiling the running process to a machine instruction set of the alternative computing node before copying contents of the application memory and/or transferring contents of the state memory to the alternative computing node, and using an IP Anycast implementation to announce running of the running process on the alternative computing node to ensure client connections to the running process on the current computing node are terminated, and combinations thereof (e.g., Kreutzer: [p. 67, Sec. III-B] discloses that a migration application can be transferred in the Wasm format or as host-specific pre-compiled binary code. Kreutzer further discloses that, if both the Wasm-format application and host-specific precompiled binary code are supplied, the embedder will fall back to the-compiled format to omit the resource-intensive compilation step. Kreutzer also discloses that source-host binary code versions are identified by host triplet and CPU features, while the target embedder checks that the host triplet matches and that the CPU feature of the binary code are supported by the target. Thus, Kreutzer teaches preparing application code as host-specific binary code suitable for execution by the alternative computing node’s native machine architecture. Kreutzer’s destination-specific binary code teaching is directly relevant in view of its WebAssembly migration arrangement. The memory layout of the application results from the application source code and the WebAssembly virtual instruction format, and is independent of host architecture. Kreutzer further teaches application-state migration in which state is transferred and applied to a locally existing destination application so that the application restarts in the same state as before, as well as full migration in which both state and application are transferred together. Shen: teaches destination node preparation before transparent migration [0038]; and discloses migration of the containerized process to the prepared computing device during execution of the containerized process [0043-0044]. Cao: also teaches the claimed memory/state transfer sequence following destination preparation [0094-0098, 0147-0148, 0192-0198] [Fig. 5 and related description].).
As per claim 7, the combination of Shen, Harwood, Kreutzer and Cao discloses The computer implemented method of claim 5 [See rejection to claim 5 above], Shen further discloses wherein the current computing node and the alternative computing node comprise a respective agent configured for cooperatively migrating the running process from the current computing node to the alternative computing node (e.g., Shen: [0013] system including a source-side agent 111 and a destination-side agent 123. [Figs. 1A-1D] shows agent associated with the computing device 106b/source-side containerized process and agent 123 associated with computing device 106c/destination-side. [0030] discloses source-side modified container runtime sends configuration metadata and connection information to a worker daemon at the source/current machine so that agent 111 establishes network connection with shim process. [0031-0032] agent 111 communicates with the proxy over virtualized network that supports migration and has functionality for migrating the containerized process during execution from computing device 106b to computing device 106c. Also see [0040-0041] [0043-0044]).
As per claim 9, the combination of Shen, Harwood, Kreutzer and Cao discloses The computer implemented method of claim 7 [See rejection to claim 7 above], wherein the agent of the current computing node is configured for freezing execution of the running process if a predetermined freeze policy is met (e.g., Cao: teaches a live-migration procedure in which the running source virtual machine is frozen/suspended only after a predetermined migration-quiescence policy is satisfied. Specifically, Cao teaches first iteratively copying source VM memory while the source VM continues running. Cao then determines that the remaining memory data can be copied in one operation, locks a source task queue so that no new tasks can enter, empties the existing source task queue, and thereafter suspends the source VM before conducting the final memory copy and transferring state information to the destination. See Cao: [0013-0016] [0094-0098] [0147-0149] [0152-0157] [Fig. 5, steps 503-506; Fig. 5]. Thus, Cao teaches freezing execution of the running process if a predetermined policy is met, where the predetermined policy includes reaching the stop-and-copy stage for live migration. For example, determining that the residual memory can be copied in one pass—and quiescing the source execution environment by locking and emptying the source task queue. Cao’s source live-migration module causes the task queue to be locked and checked for emptiness, after which the source VM manager suspends the source VM. Kreutzer: [p. 67, Sec. III-B] additionally confirms that the source-side execution is stopped in connection with state or full migration. Kreutzer teaches that, for light migration and full migration, the application is stopped on the source host, while in a copy-only migration the application remains active on the source node. Thus, Kreutzer teaches selecting a source-stop operation according to the particular migration method/policy.).
As per claim 10, the combination of Shen, Harwood, Kreutzer and Cao discloses The computer implemented method of claim 9 [See rejection to claim 9 above], wherein the predetermined freeze policy comprises any one of the following: the running process exceeds a chosen processing capacity of the current computing node, the running process exceeds a chosen storage capacity of the application memory, and as the running process has dependencies on libraries or binaries which may have known security risks (e.g., Shen: [0045] teaches monitoring resource usage by a containerized process and identifying an alternate machine that provides more efficient use of resources. Shen explains that its system can transparently migrate an executing container instance/process from a machine with eight processors and two gigabytes of memory to a machine with eight processor and 100 GB of memory, or conversely to a machine with fewer resources when appropriate. Shen further teaches migrating a containerized process when resource use indicates that another machine provides greater efficiency or optimization. [0034] Shen also teaches that scheduler component 121 monitors system status and may trigger migration under policies aimed at optimizing cost, minimizing latency, or increasing availability. [0046] Shen also teaches that the scheduler may migrate containerized process when the current machine is no longer suitable or when another machine becomes available with more favorable prices or availability characteristics. Harwood: expressly teaches processing-capacity overload as a migration condition. Harwood teaches real-time monitoring of an executing workload to detect a bottleneck that reduces workload performance. Harwood identifies increased demand on a CPU resource as a source of performance bottleneck [0034]. Harwood’s workload-monitor module collects real-time telemetry including CPU utilization, accelerator-device driven utilization, network/bus bandwidth usage, and storage throughput to identify such bottlenecks [0028-0029].).
Claims 8 and 12 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Shen in view of Harwood, Kreutzer, Cao, further in view of Hsieh et al. (US 2012/0017219 A1) (hereinafter Hsieh) and further in view of Rebeja et al. (US 11,281,492 B1 ) (hereinafter Rebeja).
As per claim 8, the combination of Shen, Harwood, Kreutzer and Cao discloses The computer implemented method of claim 7 [See rejection to claim 7 above], but does not expressly disclose wherein the agent of the current computing node is configured to detect the predetermined transfer criterion, wherein the current computing node is configured to add the running process to the workload queue if the predetermined transfer criterion is detected, wherein the agent of the alternative computing node is configured for binding the running process to the alternative computing node by recording binding data descriptive of the running process in a binding database.
However, Hsieh teaches wherein the agent of the current computing node is configured to detect the predetermined transfer criterion (e.g., Hsieh: teach a first/source migration agent unit 113 within first CPU domain CPU 110. The migration agent 113 detects a task migration condition and decides whether to migrate a migratable task from low-power CPU to high-power CPU [0006-0007] [0028] [0035][Claims 1 and 13; Fig. 6, step S620]. Hsieh expressly identifies current CPU load, potential task loading, device battery capacity, and CPU temperature as detection conditions used by migration agent unit 113 to decide which tasks should be migrated and when those tasks should be migrated [0028] [claim 2]. Hsieh’s task-migration conditions are the claimed predetermined transfer criterion because the conditions are evaluated by the current/source domain agent before it determines that a running task should be transferred to alternative/destination CPU domain. Hsieh further teaches that, once migration is decided, source migration agent wakes the high-power CPU and causes destination RTOS, destination migration agent, and destination run queue to enter normal operation [0028] [Fig. 3; Fig. 6, step S620].), wherein the current computing node is configured to add the running process to the workload queue if the predetermined transfer criterion is detected (e.g., Hsieh: after migration agent 113 detects a task migration condition and selects a migratable task, the source migration agent removes the selected task from source run queue, updates the task control block for the selected task, and places the selected task into migration task list in shared memory [0030], [0036] [Fig. 4] [Fig. 6, S630]. Hsieh then teaches that migration agent 113 sends migration event 430 to event queue 160 [0031] [0037], [Fig. 4; Fig. 6, step S640]. Hsieh’s migration task list teaches or at least renders obvious the claimed workload queue. Migration task list sores the selected task after agent detects the transfer criterion and before the destination agent retrieves, reassociates, queues, schedules, and executes the task at the destination. The associated event queue provides the migration notification mechanism used to notify destination migration agent 133 that the queued task is available for processing.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Shen-Harwood-Kreutzer-Cao migration arrangement to use Hsieh’s source-agent detection, task-list queuing, and event-driven destination-agent retrieval. Shen and Hsieh both address orderly movement of running workload form one computing device to another. Hsieh supplies a known queue/list-based coordination mechanism by which a source agent selects a workload under detected condition, places the selected workload in a migration task list, and informs a destination agent so that destination agent can retrieve and schedule the workload. Applying this mechanism to Shen’s agent-based migration arrangement would predictably improve source/destination coordination and reliability of live migration.
The combination of Shen, Harwood, Kreutzer, Cao and Hsieh still does not expressly disclose for binding the running process to the alternative computing node by recording binding data descriptive of the running process in a binding database.
However, Rebeja discloses for binding the running process to the alternative computing node by recording binding data descriptive of the running process in a binding database (e.g., Rebeja: teaches configuration registry 105 in controller 102. The configuration registry stores configuration data for application containers, including network configuration information such as assigned virtual network, port, bridge, MAC address, IP address, gateway, and network type. Rebeja further teaches storage-volume data, including storage volume identifier, location, and other information usable for attaching the volume to the container. Rebeja teaches recording/storing the configuration data in configuration registry 105 and querying the registry to obtain configuration information used to configure the target node and destination container during migration. See Rebeja, [Fig, 1; Fig.2, steps 202-228; Col. 9, lines 1-35; Col. 10, lines 14-65; col. 11.]. Rebeja’s configuration registry 105 teaches the claimed binding database because it records data descriptive of the migration process/container and data that establishes the container’s association with the target node. Rebeja teaches moving/copying a currently executing container from source node 112A to target node 112M, deleting the network configuration for the container from the source node, configuring the target node using the recorded configuration, attaching the configuration to the destination container, attaching the storage volume, and starting the destination container [Fig. 2, steps 206-226].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to further modify the Shen-Harwood-Kreutzer-Cao-Hsieh combination to use Rebeja’s configuration registry as a binding database. Rebeja teaches that recording workload/container configuration data in registry allows destination-node migration functionality to restore the network, storage, and execution associations needed for the transferred container. Incorporating this known registry mechanism would predictably permit the destination-side agent to record and retrieve data that identifies the process/container and destination/alternative node association.
A POSITA would have been motivated to make this modification to preserve or restore network identity, network configuration, storage configuration, and destination execution configuration during live migration because it would reduce configuration errors at the alternative node and improve reliability and continuity after state and memory transfer.
As per claim 12, the combination of Shen, Harwood, Kreutzer, Cao, Hsieh and Rebeja discloses The computer implemented method of claim 8 [See rejection to claim 8 above], Rebeja further discloses wherein the computing environment further comprises the binding database (e.g., Rebeja: [Col. 9, lines 1-35] [Fig. 1; Fig. 2, steps 202-228; Col. 10, lines 14-65] Rebeja’s configuration registry 105 teaches the claimed binding database. The registry stores binding data descriptive of a running process/container, including assigned virtual-network information, port, bridge, MAC address, IP address, etc. These data is used when moving the container/process form source node 112A to a target node 112M.).
Claims 11 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Shen in view of Harwood and Kreutzer, and further in view of Rebeja.
As per claim 11, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], wherein the computing environment further comprises a scheduler configured to assign the running process in the workload queue to the alternative computing node using a scheduling algorithm (e.g., Shen: [0025] [0034] disclose scheduler component 121 may provide functionality for managing migration. The scheduler component may monitor a status of the system and may trigger migration based on one or more policies. [0004] discloses a scheduler component execution go the first machine determines to migrate the containerized process to a third machine and directs the migration during execution of the containerized process. [0036] discloses determining, by a scheduler component executing on the first machine, to migrate the containerized process to a third machine; directing, by the scheduler, migration of the process to the third machine, during execution of the process. [0038] also teaches scheduler-directed selection of a destination machine. Shen teaches that modified container runtime process can communicate with scheduler component to obtain instruction identifying the actual machine on which a container image is to be initiated. Shen further teaches that, when migration is determined, scheduler component establishes or identifies a new worker machine and directs the runtime process to perform the migration. [0045] Shen discloses that scheduler component 121 determines whether an alternative computing device provides higher efficiency or higher optimization for hosting the containerized process, and then directs migration to that device. [0034] [0046-0047] further teach migration policies based on system status, cost, latency, availability, resource usage, and changes in machine availability or pricing. Harwood: [0014] [0032-0033] additionally teach a service controller having a global scheduler and request queue module, resource allocation and provisioning module, work-load monitor module, and live-migration module. Harwood teaches that service request are stored in a request queue pending scheduling, and that resource allocation is performed based on application ID, constraints, policies, user-specified conditions, topology and current resource usage. [0005] [0037] Harwood further teaches monitoring an executing workload to detect a bottleneck condition and, in response, determining and provisioning another resource set for the workload, followed by live migration of the workload to that reallocated resource set. Thus, Harwood teaches or renders obvious assigning/reassigning a running workload to alternative resource/node using a scheduling/resource allocation algorithm responsive to workload conditions.).
The combination of Shen, Harwood and Kreutzer does not expressly disclose that the scheduler is configured to bind the running process to the alternative computing node by recording binding data descriptive of the running process in a binding database.
However, Rebeja discloses wherein the scheduler is further configured to bind the running process to the alternative computing node (e.g., Rebeja: teaches controller 102 that receives a migration request identifying a presently executing container and target node 112M. The controller coordinates migration tasks to copy the container from source node 112A to target node 112M, configure the target node, attach storage resources, and start the migrated container on target node 112M [Fig. 1; Fig. 2, steps 202-228]. Rebeja’s controller performs the claimed binding function because it causes the selected container/workload to be associated with and executed at the chosen target node. Rebeja teaches that the target node is identified as part of the migration request and that the destination container is configured and started at that identified node.) by recording binding data descriptive of the running process in a binding database (e.g., Rebeja: teaches configuration registry 105, which stores container configuration data. The data includes network configuration for the container, such as assigned virtual-network information, port, bridge, MAC address, IP address, gateway DNS/DHCP information, and network type. Rebeja further teaches storage-volume data, including identifier, location, or other information usable to attach storage to the container. Rebeja, Fig.1; col. 9, lines 1-35; Fig. 2, steps 202-203. The recorded Rebeja’s configuration data is descriptive of the running process/container because it identifies the container’s network, storage, and execution-relevant configuration. Such data permits the controller to recreate the container’s required environment after movement from the source node to the target node. Rebeja’s configuration registry 105 teaches the claimed binding database because it persistently stores process/container-specific information that is used to establish and maintain the container’s target-node association. Rebeja’s controller obtains the stored configuration information, deletes source-node network configuration, configures target node 112M with the stored network configuration, attaches that configuration to destination container, attaches the associated storage volume, and starts destination container. Rebeja, Fig. 2, Steps 206-226. Rebeja further teaches that destination container may retain the source container’s MAC address and obtain the IP address formerly assigned to the source container. This teaching further demonstrates that Rebeja records and uses target-binding information to preserve or recreate the migration workload’s network identity and operational association at the alternative computing node.).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the scheduler-directed system of Shen-Harwood-Kreutzer to employ Rebeja’s configuration registry for recording/storing binding data associated with container/process and an assigned destination node. Shen and Harwood teach selecting and assigning destination computing node for a running workload based on scheduling policies, workload conditions, system status, resource use, topology, and performance. Rebeja teaches recording container specific information in a registry and using that information to configure and start the migrated container at a selected target node.
A POSITA would have been motivated to incorporate Rebeja’s registry mechanism into the Shen-Harwood-Kreutzer system so that a scheduler’s destination-node assignment could be recorded and used to restore the running process/container with its necessary network, storage, and execution associations at the alternative node. The modification would predictably improve configuration continuity, destination-side deployment reliability, recovery from migration-control interruptions, and preservation of process’ network identity and resource configuration.
Claim 18 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Shen in view of Harwood and Kreutzer, and further in view of Van Sonsbeek et al. (US 2025/0259014 A1) (hereinafter Van).
As per claim 18, the combination of Shen, Harwood and Kreutzer discloses The computer implemented method of claim 1 [See rejection to claim 1 above], but does not expressly disclose wherein the running process is a large language model, wherein the predetermined criterion comprises anyone of the following: a received LLM prompt length is exceeded, a KV-cache length is exceeded, and combinations thereof.
However, Van discloses wherein the running process is a large language model, wherein the predetermined criterion comprises anyone of the following: a received LLM prompt length is exceeded, a KV-cache length is exceeded, and combinations thereof (e.g. Van: [0002-0003] Van teaches large models use hundreds of billions of machine-trained parameters and are typically implemented by server systems because local device generally lack sufficient memory and processing resources. [0036] [0070] [0074] A global language model that has more than 10 billion parameters and may have several hundred billion parameters. [0008] [0012] discloses a large multi-billion-parameter language model running on a server system compare to local language model. The local language model makes relatively efficient use of memory and processing resources. This implies that as long as the prompt size limits imposed by the local language model is not exceeded the process may be executed on a local computing device and if the prompt size limit is exceeded than a large multi-billion-parameter language model running on a server system may be utilized. [0008] [0012] [0030] [0046] [0050] Van defines a prompt as a sequence of tokens submitted to a machine trained model. Van further teaches that a local langue model has prompt-size limits and that profile information and other text-based information are compressed so that the information processed by the local language model does not exceed those prompt-size limitations. Thus, Van teaches or at least renders obvious a predetermined prompt-length criterion: the prompt is tokenized, the language model imposes a maximum prompt-size constraint, and input is compressed to prevent the prompt from exceeding the model’s prompt-size limit. A POSITA would understand that determining whether the received token sequence exceeds the LLM’s prompt-size limitation necessarily entails comparing the prompt length to the model’s permitted prompt size.).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the Shen-Harwood-Kreutzer live-migration framework so that the running process is a large language model and so that an LLM prompt-size condition is used as predetermined transfer criterion. Shen teaches live migration of a running containerized process form a current computing node to another alternative computing node. Shen’s scheduler monitors system stats and triggers migration based on predefined policies. Harwood teaches continuously monitoring a running workload to detect bottleneck, and in response to detecting the bottleneck, live migrating the workload. Kreutzer teaches portable WebAssembly application and state migration between hosts including transfer of the application and application states to a destination node; and stopping/restarting the source/destination application as appropriate for state or full migration.
A POSITA would have recognized that a prompt whose length exceeds the local LLM’s supported prompt-size limit creates a resource and processing constraint analogous to the workload-performance and resource-bottleneck conditions that Shen and Harwood use to trigger relocation of a running workload. It would therefore have been obvious to configure the Shen-Harwood-Kreutzer framework to detect that the received LLM prompt exceeds the supported prompt-size threshold of the current-node LLM and to use that condition as the predetermined criterion for migrating the running LLM process to an alternative computing node.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, Emerson Puente, can be reached at the following telephone number: (571) 272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
September 17, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights