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 .
This action is responsive to Applicant’s Amendment filed on 3/16/2026.
Claims 1-4 and 6-21 are presented for examination. Claims 1-3 and 6-11 have been amended. Claims 12-21 have been added. Claims 5 have been cancelled. Note: according to the language used at claim 6, claim 6 is actually amended; however, Applicant indicated claim 6 as “Original”.
Applicant’s amendments to the specification and claims have overcome specification objections, claim objection and 112 rejections set forth in the non-Final Office Action mailed 12/16/2025.
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 entirely 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.
Claim Objections
Claim 6 is objected to because of the following informalities:
“(a) an entry and/or exit of compute nodes, (2) a reduction or increase of a computing capacity, and (3) a failure of at least one communication resource” at lines 5-6 of claim 6 should be: (a) an entry and/or exit of compute nodes, (b) a reduction or increase of a computing capacity, and (c) a failure of at least one communication resource.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6-7, 9-15, 17 and 19 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Werme et al. (US 20030167270 A1, hereafter Werme).
Regarding to claim 1, Werme discloses: A method for adaptive resource allocation for applications in a distributed system of heterogeneous compute nodes (see [0031]; “monitoring hosts, networks, and applications within a distributed computing environment”, “the Resource Management Architecture provides the capability of dynamically allocating, and reallocating, applications to hosts as needed in order to maintain user-specified system performance goals”. Also see [0311] and [0389]; “hosts A-N, where host A provides a video source server application A-1, host B provides a video distribution application B-1, a contract application B-2, and a host load monitor B-3, and host C provides a display broker application C-1 applying video signals to a display driver C-2” And “CD-Appendix G described a specification grammar for declaring requirements on applications in a dynamic, distributed, heterogeneous Resource pool”), the method comprising:
carrying out, by an allocation and migration unit, the adaption steps repeatedly and in an automated manner during runtime of the applications, the adaption steps including (see [0047]-[0048]; “collects extensive run-time information on host and network configuration, statuses, and performance” and “general-purpose application event reporting and event correlation capabilities. Capabilities are provided for collecting and correlating application-provided data such as application statuses, states, performance, and internally detected errors”. Also see [0183]; “the Resource Manager FG 42 receives status and failure information about hosts, networks, and applications from Program Control function FG50. This information includes both periodic status updates and immediate updates when statuses change”):
monitoring, during runtime, execution behavior of the applications and utilization of compute and communication resources of the distributed system (see [0031]; “The Resource Management Architecture, which was and is being developed by the Naval Surface Warfare Center—Dahlgren Division (NSWCDD), provides capabilities for monitoring hosts, networks, and applications within a distributed computing environment”. Also see [0047]-[0048] and [0183]; “Run-time capabilities for discovering new hosts that have been started and for determining that existing hosts have gone down are also provided” and “receives status and failure information about hosts, networks, and applications”. In addition see [0070]-[0071]; “to gather the information in as non-intrusive a manner as possible (in terms of CPU utilization, network bandwidth utilization, etc. . . . )”);
analyzing the monitored execution behavior to detect runtime variation in resource requirements of at least one application (see [0031]; “dynamically allocating, and reallocating, applications to hosts as needed in order to maintain user-specified system performance goals … what options are available for attempting to correct deficient performance, determining the proper actions that should be taken, and enacting the determined course of action”. Also see [0036]-[0042], [0053]-[0059], [0185]-[0189]; “2) whether and where failed applications should be restarted 3) based on application inter-dependencies, whether and where additional applications should to be started prior to starting a particular application 4) whether applications are meeting performance requirements and whether and where an application can be scaled up or moved to when it is necessary to improve performance 5) whether scalable applications are performing well within performance requirements and can be scaled down and which copy should be brought down; and 6) based on operator changes to application system priorities, whether and where new applications need to be started or whether and which existing applications need to be shut down”. Based on the monitored execution behavior, like failure of application, meeting performance requirements or not, changing on application system priority, to detect runtime variation in resource requirements for the applications, like starting or stopping application, scaling up or down application);
based on the detected runtime variation, updating at least one allocation determination for the application that governs subsequent assignment of the application to compute nodes, including updating an assignment basis, ranking, or heuristic used to select compute nodes for execution of the application (see [0087], [0185], [0202], [0332], Table II at page 20; “receives information on host configuration and loads (primarily CPU, memory, and network data) from History Servers FG12A-FG12N and employs this information to assign host fitness scores”, “(1) overall host fitness scores, (2) CPU-based fitness scores, (3) network-based fitness scores, and (4) memory and paging-based fitness scores, along with (5) the SPEC95™ rating of the hosts. These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications”, “The scores advantageously can be based on the status (up/down) of the applications and the percentage of potential copies of scalable applications that are currently running. Host and network readiness scores are determined based on the host loads and host fitness scores received from the Hardware Broker FG40”, “fitness scores are recalculated when new History Server host Status Response Messages are received”. Also see [0183]; “receives status and failure information about hosts, networks, and applications from Program Control function FG50. This information includes both periodic status updates and immediate updates when statuses change such as a new host being detected or an application failing”. The different scores, like overall host fitness scores, CPU-based fitness scores, network-based fitness scores, memory and paging-based fitness scores, host readiness scores, network readiness scores, i.e., claimed “an assignment basis, ranking, or heuristic used to select compute nodes for execution of the application” are updated or reallocated based on the detected decision on starting or stopping application, scaling up or down application); and
adapting a resource allocation of the applications by reallocating at least one application among the heterogenous compute nodes in accordance with the updated allocation determination (see [0185]-[0190]; “These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications” and “The Resource Manager FG42 responds to these requests by determining whether the request should be acted upon and, if so, determines the specific action to take. The Resource Manager FG42 then issues orders to Program Control FG50 to start up or shutdown specific applications on specific hosts”).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further Werme discloses: prior to runtime, ascertaining a static resource profile of the application in order to initially define the allocation determination, wherein the allocation determination is subsequently updated during runtime based on the detected runtime variation (see [0219]; “For static application-to-host mappings, an application will, by default, be started on a specified host. For dynamic application-to-host mappings, the application will have a default host to start on but the Resource Manager FG42 will be queried at run-time to determine where the application actually should be placed. The Configuration Files FG56 also contain all information on how to start, stop, and configure an application, with the exception of environment variable settings for the application which are set based on the System Specification Files FG32”. Also see [0042], [0147]; “based on recommendations from the QoS Managers, when and where scalable application should be started or stopped”, “At the application level, the hardware, operating system, and other host requirements for each application can be specified along with information describing how to start up, configure, and shutdown the application”).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further Werme discloses: wherein the updating of the allocation determination includes comparing detected heterogeneous computing capacities of the compute nodes and assigning the applications as a function of the detected runtime variation and detected heterogenous computing capacities (see [0087], [0185], [0202], [0332], Table II at page 20; “receives information on host configuration and loads (primarily CPU, memory, and network data) from History Servers FG12A-FG12N and employs this information to assign host fitness scores”, “(1) overall host fitness scores, (2) CPU-based fitness scores, (3) network-based fitness scores, and (4) memory and paging-based fitness scores, along with (5) the SPEC95™ rating of the hosts. These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications”, “The scores advantageously can be based on the status (up/down) of the applications and the percentage of potential copies of scalable applications that are currently running. Host and network readiness scores are determined based on the host loads and host fitness scores received from the Hardware Broker FG40”. Also see [0183]; “receives status and failure information about hosts, networks, and applications from Program Control function FG50. This information includes both periodic status updates and immediate updates when statuses change such as a new host being detected or an application failing”).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further Werme discloses: wherein the system includes different communication resources, the adaptation of the resource allocation including the following step: assigning the communication resources for the applications as a function of the ascertained need for changes (see [0047], [0157], [0167]; “monitors the host and network resources within the distributed environment”, “an estimate of the amount of CPU, memory, and network resources that the application will use at run-time, advantageously can be specified”, “application data flow paths can be defined including a graph of the data flow between applications along with performance requirements tied to one of more of the applications within the path. It should be mentioned that these defined requirements are named and are tied at run-time to Instrumentation”, “Based on application inter-dependencies defined in the System Specification Files, determine whether and where additional applications should to be started (or shut down) prior to starting (or shutting down) a particular application”. According to the application inter-dependencies, certain application should be started before starting a particular application, and thus the communication resources used to achieve the application data flow patch between these two applications should be assigned to these two applications).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further Werme discloses: wherein the carrying out of the monitoring of the resources of the system includes the following step: detecting, for ascertainment of the need for changes, resources of the system varying during the runtime, including detecting any one or more events of a group of events that consists of: (a) an entry and/or exit of compute nodes, (2) a reduction or increase of a computing capacity, and (3) a failure of at least one communication resource (see [0037]-[0039], [0047]; “how to respond to host and application failures”, “which applications to start up in response to the detection of a new host (host N+1)”, “Run-time capabilities for discovering new hosts that have been started and for determining that existing hosts have gone down are also provided”. Note: it is understood that detection of a new host would also cause increase of a computing capacity. Also see [0090], [0183]; “receives status and failure information about hosts, networks, and applications”. Note: it is understood that failure of an existing host would also cause reduction of a computing capacity).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further Werme discloses: wherein the monitoring and/or the adaptation of the resource allocation include at least one of the following steps, which are executed by the allocation and migration unit:
recognizing and recording a change of a resource requirement of an application of the applications and migrating the application having the changed resource requirement adaptively to one of the compute nodes which is configured to meet the changed resource requirement (see [0057], [0146]; “whether applications are meeting performance requirements and whether and where an application can be scaled up or moved to when it is necessary to improve performance” and “Each application system and subsystem can be assigned a priority which is used at run-time to determine the relative importance of applications running in the distributed environment”. Note: according to [0192]-[0198], this assigned priority discussed at [0057] and [0146] can be considered as an urgency level of requesting hardware resources for running the applications, and thus the change of such priority is reasonable to be considered as a change of a resource requirement),
recognizing and recording when a load on at least one of the compute nodes exceeds a predefined threshold value over a predefined duration, and migrating at least one of the applications, which is executed on the at least one of the compute nodes, and adapting the resource allocation on one of the compute nodes on which an application of the applications having a changed resource requirement is being executed (see [0057], [0146]; “whether applications are meeting performance requirements and whether and where an application can be scaled up or moved to when it is necessary to improve performance” and “Each application system and subsystem can be assigned a priority which is used at run-time to determine the relative importance of applications running in the distributed environment”). Note: Examiner here only rejected the “adapting” limitation without rejecting the “recognizing and recording” limitation since the language of “at least one of the following steps” at line 2 of claim 7 (due to such “at least one of the following steps”, “recognizing and recording” limitation can be considered as “one of the following steps” and “adapting” limitation can also be considered as another “one of the following steps”).
Regarding to Claim 9, the rejection of Claim 1 is incorporated and further Werme discloses: wherein the applications are configured as applications communicating with: one another of as distributed middleware; an operating system of a vehicle; an edge computing system; a cloud computing system; and/or a vehicle controller (see [0272]; “the RMComms middleware package provides object-oriented client-server services for message communication between distributed applications and function modules”).
Regarding to Claim 10, Claim 10 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 11, Claim 11 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 12, the rejection of Claim 1 is incorporated and further Werme discloses: wherein analyzing the monitored execution behavior includes detecting changes in resource requirements of the application caused by differences in data processed by the application during runtime (see [0013]; “allowing autonomous start up and shut down of application copies on host machines to accommodate changes in data processing requirements”. Also see [0146], [0185], [0189]; “Each application system and subsystem can be assigned a priority which is used at run-time to determine the relative importance of applications running in the distributed environment”, These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications when: … responding to application system (mission) priority changes which require scaling up additional applications”. The change of application system priority, i.e., importance of the application running, can also be reasonable to be considered as claimed “differences in data processed by the application” or data processing requirement discussed at [0013]).
Regarding to Claim 13, the rejection of Claim 1 is incorporated and further Werme discloses: wherein analyzing the monitored execution behavior includes detecting applications entering and/or leaving the distributed system during runtime, and updating the allocation determination based on the detected entry or exist (see [0183], [0187], [0315]-[0316] and [0331]; “In the case of application shutdown, information as to whether the application was shutdown intentionally or whether the application failed is also provided” and “These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications when: … attempting to restart failed applications”, “responding to application and host failures by determining if and what recovery actions should be taken” and “determine whether the specific application will be restarted if it fails at run-time”).
Regarding to Claim 14, the rejection of Claim 1 is incorporated and further Werme discloses: prior to runtime, ascertaining a static resource profile of the application to initially define the allocation determination, wherein the allocation determination is subsequently updated during runtime based on the detected runtime variation (see [0219]; “For static application-to-host mappings, an application will, by default, be started on a specified host. For dynamic application-to-host mappings, the application will have a default host to start on but the Resource Manager FG42 will be queried at run-time to determine where the application actually should be placed. The Configuration Files FG56 also contain all information on how to start, stop, and configure an application, with the exception of environment variable settings for the application which are set based on the System Specification Files FG32”. Also see [0042], [0147]; “based on recommendations from the QoS Managers, when and where scalable application should be started or stopped”, “At the application level, the hardware, operating system, and other host requirements for each application can be specified along with information describing how to start up, configure, and shutdown the application”).
Regarding to Claim 15, the rejection of Claim 1 is incorporated and further Werme discloses: wherein updating the allocation determination includes comparing heterogenous computing capacities of the compute nodes and assigning the application as a function of the detected runtime variation and the different computing capacities (see [0087], [0185], [0202], [0332], Table II at page 20; “receives information on host configuration and loads (primarily CPU, memory, and network data) from History Servers FG12A-FG12N and employs this information to assign host fitness scores”, “(1) overall host fitness scores, (2) CPU-based fitness scores, (3) network-based fitness scores, and (4) memory and paging-based fitness scores, along with (5) the SPEC95™ rating of the hosts. These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications”, “The scores advantageously can be based on the status (up/down) of the applications and the percentage of potential copies of scalable applications that are currently running. Host and network readiness scores are determined based on the host loads and host fitness scores received from the Hardware Broker FG40”. Also see [0183]; “receives status and failure information about hosts, networks, and applications from Program Control function FG50. This information includes both periodic status updates and immediate updates when statuses change such as a new host being detected or an application failing”).
Regarding to Claim 17, the rejection of Claim 1 is incorporated and further Werme discloses: wherein updating the allocation determination includes maintaining and updating a ranking of compute nodes best suited for execution of the application, and reallocating the application according to the updated ranking (see [0087], [0185], [0202], [0332], Table II at page 20; “receives information on host configuration and loads (primarily CPU, memory, and network data) from History Servers FG12A-FG12N and employs this information to assign host fitness scores”, “(1) overall host fitness scores, (2) CPU-based fitness scores, (3) network-based fitness scores, and (4) memory and paging-based fitness scores, along with (5) the SPEC95™ rating of the hosts. These scores are used by the Resource Manager FG42 for determining the “best” hosts for placing new applications”, “The scores advantageously can be based on the status (up/down) of the applications and the percentage of potential copies of scalable applications that are currently running. Host and network readiness scores are determined based on the host loads and host fitness scores received from the Hardware Broker FG40”, “fitness scores are recalculated when new History Server host Status Response Messages are received”. Also see [0183]; “receives status and failure information about hosts, networks, and applications from Program Control function FG50. This information includes both periodic status updates and immediate updates when statuses change such as a new host being detected or an application failing”).
Regarding to Claim 19, the rejection of Claim 1 is incorporated and further Werme discloses: wherein monitoring, analyzing, updating the allocation determination, and reallocating are performed as a continuous feedback loop during runtime of the application (see [0036]-[0042], [0047], [0268]; “how to respond to host and application failures; where (i.e., which of hosts A-N) to place new applications; which applications to start up in response to the detection of a new host (host N+1); how to resolve application dependencies; what applications should be started, stopped, or moved in response to application system priority changes” and “three real-time graphs can be produced to depict run-time performance and load metrics related to the applications in the selected data path” Also see [0385]; “determine whether or not it is safe to start an application, stop an application, or let an application continue to run”).
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.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Werme et al. (US 20030167270 A1, hereafter Werme) and in view of Podila (US 20090113434 A1).
Regarding to Claim 8, the rejection of Claim 8 is incorporated and further Werme discloses: wherein a scheduling unit is executed on at least one or each of the compute nodes, which repeatedly exchanges with the allocation and migration unit during runtime at least one piece of information, the at least one piece of information including information about:
a present availability of at least one of the resources of the system and/or the compute node on which it is executed, and/or the resource requirement, and/or the ascertained need for changes (see [0035]-[0042]; “Resource Manager 60 also receives information from the QoS managers 30 and exchanges information with program controller 70”, “based on recommendations from the QoS Managers, when and where scalable application should be started or stopped”. Also see “there are hosts available that the application can run on” from [0184] for claimed “a present availability of at least one of the resources of the system and/or the compute node on which it is executed”, “At the application level, the hardware, operating system, and other host requirements for each application can be specified along with information describing how to start up” from [0147]-[0148] for claimed “the resource requirement”, “application failures” and “the detection of a new host (host N+1)” from [0037]-[0039] for claimed “the ascertained need for changes”).
Werme does not disclose: the at least one piece of information to define an execution sequence of the applications, the at least one piece of information further include information about to define an execution sequence of the applications.
However, Podila discloses: wherein a scheduling unit is executed on at least one or each of the compute nodes, which repeatedly exchanges during the run time at least one piece of information to define an execution sequence of the jobs, the at least one piece of information including information about: a present availability of at least one of the resources of the system and/or the compute node on which it is executed, and/or the resource requirement, and/or the ascertained need for changes, to define an execution sequence of the jobs (see [0026], [0030]; “the CPU 238 of the scheduler 236 assigns the jobs 210 to the resources 245 of the compute farm 205 according to the availability of the resources 245 and the requirements of the SLAs 220, policies 225, constraints 230 and priorities 235”, “The job resource requirements of a specific signature classification 240 may correspond to all jobs 210 requiring a certain memory requirement and certain licenses, and, perhaps, having certain SLAs 220”. Also see “An example of a priority would be to identify a certain job 210 or signature classification 240 as being critical to complete as soon as possible, while another certain job 210 of signature classification 240 is less critical to complete” from [0028] for the priority discussed at Podia is reasonable to be considered as claimed “an execution sequence”. In addition, also see [0062]; “to dynamically analyze the time available in the future to schedule some jobs and not others”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the executions of the applications from Werme by including scheduling jobs based on resource availability, resource requirements and execution priority/sequence from Podila, and thus the combination of Werme and Podila would disclose the missing limitations from Werme, since it would provide a mechanism of scheduling critical jobs to be completed as soon as possible (see [0026] and [0028] from Podila).
Claims 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Werme et al. (US 20030167270 A1, hereafter Werme) and in view of Alt et al. (US 20220058060 A1, hereafter Alt).
Regarding to Claim 16, the rejection of Claim 1 is incorporated, Werme does not disclose: recording execution performance of the application on multiple compute nodes and updating the allocation determination based on the recorded performance to optimize subsequent assignment decisions.
However, Alt discloses:
recording execution performance of the application on multiple compute nodes and updating the allocation determination based on the recorded performance to optimize subsequent assignment decisions (see [0008] and [0061]; “ranking a set of available computing resources by maintaining a performance database comprising historical performance data for a large number of prior applications that have been executed on many different computer systems … the database is checked to see if the application has already been run on any of the computing systems participating in the distributed computing marketplace” and “The historical data for example may include what percentage of time the application spent bound by different performance limits such as being CPU-bound, network-bound, I/O bound, memory latency bound, memory bandwidth bound … the user's application may be configured and deployed (step 1340) to the selected computing system resource (e.g., a container with the user's application may be created and copied over to the selected computing system resource)”. Also see [0057]; “Feedback may be provided to the user by the management application for both logical topology and compute resource selections. For example, a warning may state that a particular configuration does not scale well, or that no systems exist with enough nodes to satisfy the configuration the user has created in expert mode”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the ranking score determination of each resource candidates for executing requested application from Werme by including providing feedback of executing application on certain particular resource configuration from Alt, and thus the combination of Werme and Alt would disclose the missing limitations from Werme, since it would provide feedback or recommendation on application performance on particular resource configuration to improve future compute resource selection (see [0057] from Alt).
Regarding to Claim 18, the rejection of Claim 1 is incorporated, Werme does not disclose: wherein updating the allocation determination includes applying at least one heuristic or machine-learning-based technique to evaluate alternative assignments of the application to compute nodes.
However, Alt discloses:
wherein updating the allocation determination includes applying at least one heuristic or machine-learning-based technique to evaluate alternative assignments of the application to compute nodes (see [0008] and [0061]; “ranking a set of available computing resources by maintaining a performance database comprising historical performance data for a large number of prior applications that have been executed on many different computer systems” and “The historical data for example may include what percentage of time the application spent bound by different performance limits such as being CPU-bound, network-bound, I/O bound, memory latency bound, memory bandwidth bound … the user's application may be configured and deployed (step 1340) to the selected computing system resource (e.g., a container with the user's application may be created and copied over to the selected computing system resource)”. Also see [0057]; “Feedback may be provided to the user by the management application for both logical topology and compute resource selections. For example, a warning may state that a particular configuration does not scale well, or that no systems exist with enough nodes to satisfy the configuration the user has created in expert mode. For example, the system may warn the user that a high bandwidth interconnect is needed (e.g., based on a particular producer-consumer configuration) if the user has not selected a high bandwidth link”. Applying feedback recommendation, i.e., claimed heuristic technique, to evaluate alternative resource allocations or assignments).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the ranking score determination of each resource candidates for executing requested application from Werme by including providing feedback of executing application on certain particular resource configuration from Alt, and thus the combination of Werme and Alt would disclose the missing limitations from Werme, since it would provide feedback or recommendation on application performance on particular resource configuration to improve future compute resource selection (see [0057] from Alt).
Claims 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Werme et al. (US 20030167270 A1, hereafter Werme) and in view of Ouyang et al. (US 20160134428 A1, hereafter Ouyang).
Regarding to Claim 20, the rejection of Claim 1 is incorporated, Werme does not disclose: wherein detecting the runtime variation in resource requirements includes detecting a change in a type of resource required by the application during runtime, and wherein reallocating the at least one application includes migrating the application to a compute node having a hardware functionality configured to satisfy the changed type of resource requirement.
However, Ouyang discloses: wherein detecting the runtime variation in resource requirements includes detecting a change in a type of resource required by the application during runtime, and wherein reallocating the at least one application includes migrating the application to a compute node having a hardware functionality configured to satisfy the changed type of resource requirement (see [0065], [0067], [0069]; “the user device evaluation occurs during an online meeting … a change in the meeting bandwidth requirement” and “The available network bandwidth may impact the meeting performance and user experience. As such, a change in the network bandwidth and/or connection type may be detected and meeting server 106 is notified to trigger the user device evaluation. In response, the meeting server 106 may initiate the display of a device selection window at the desktop computer 116(1) thereby providing the attendee 114 with the option and ability to directly transfer the online meeting 102 to one or more other devices”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the moving executing application to another device for further execution from Werme by including moving executing application to another device for further execution in response to detected particular type of resource requirement changes during runtime of the application from Ouyang, and thus the combination of Werme and Ouyang would disclose the missing limitations from Werme, since it would provide a mechanism to improve user’s experience in response to runtime resource requirement changes (see [0065], [0067], [0069] from Ouyang).
Regarding to Claim 21, the rejection of Claim 20 is incorporated and further the combination of Werme and Ouyang discloses: wherein the changed type of resource requirement includes a requirement for a different one of: all-purpose computing capacity, floating-point processing capacity, graphics processing capacity, acceleration capacity, communication bandwidth, or a specific hardware feature of a compute node (see [0065], [0067], [0069]; “the user device evaluation occurs during an online meeting … a change in the meeting bandwidth requirement”).
Response to Arguments
Applicant’s arguments, filed 3/16/2026, with respect to rejections of claims under 35 U.S.C. 102 or 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 10-14 are summarized as the following:
The amended independent claims require “an allocation determination that governs subsequent assignment decision is updated. The claims require that this allocation determination includes an assignment basis, ranking, or heuristic used to select compute nodes for execution of the application, and that the resource allocation is then adapted by reallocating at least one application in accordance with the updated allocation determination” (see 3rd paragraph of page 10 from the Remarks). Applicant continued stating “While Werme updates host fineness values and load metrics over time, those updates are inputs to a fixed allocation logic. The rules, scoring formulas, and policies used to decide where application should be placed are defined in advance … Runtime observations in Werme determine when those rules are trigged, not how the rules themselves evolve. Further in this regard, Werme’s updates occur only at the level of measure system state, not at the level of the decision logic used to assign application …The scoring calculation itself, i.e., the logic by which hosts are evaluated and compared, remains unchanged throughout system operation” (see last paragraph of page 11 from the Remarks and 1st paragraph of page 12 from the Remarks). “By contrast, the claims, as present herein, require … to update the allocation determination itself, including updating an assignment basis, ranking, or heuristic that governs future selection of compute nodes for the application. The claims therefore require refinement of the decision logic that governs subsequent assignment decision. Not merely execution of predefined actions in response to detected violations” (see 2nd paragraph of page 12 from the Remarks).
The examiner respectively disagrees.
First of all, Applicant is suggested to review the language used at independent claims to review whether BRI of the current claimed language support Applicant’s interpretation. Such as, Applicant kept arguing that the claimed invention requires to update or evolve the resource allocation rules or logic. However, the current related claimed limitations are “updating at least one allocation determination for the application that governs subsequent assignment of the application to compute nodes, including updating an assignment basis, ranking, or heuristic used to select compute nodes for execution of the application”. The language of “allocation determination” for example can be allocating application1 to node 1, and such allocating application1 to node 1 also “governs subsequent assignment of the application to compute node” instead of the allocation determination logic or rule. Determination itself does not represent determination logic or determination rule, otherwise Applicant would use language like determination or decision directly (at the Remarks, Applicant used language like “updating the decision logic itself” instead of updating the decision itself. From this point of view, Applicant also agrees that decision logic is different from decision itself). Similarity, “ranking” is ranking itself instead of ranking logic or ranking rule. The updating of host fitness scores from Werme is understood by one with ordinary skill in the art as updating the ranking of the host candidates to find out best host to place application for execution. Then, to one with ordinary skill in the art, the updating of host fitness scores from Wernme is reasonable to map to the amended limitations of “updating at least one allocation determination for the application that governs subsequent assignment of the application to compute nodes, including updating an assignment basis, ranking, or heuristic used to select compute nodes for execution of the application”.
Therefore, Claims 1-4 and 6-21 are rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. 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 and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights