DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant’s Amendment and Remarks filed on 14 May 2026.
Claims 1-2, 4-15 and 17-20 are pending for examination. Claims 3 and 16 were cancelled.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-2, 4-15 and 17-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claims 1 and 14 contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. Because the specification fails to disclose how the benchmarking tools being selected based on the application execution profile.
More specifically, in claims 1 and 14, lines 9-10, it recites “the benchmarking tools being selected based on the application execution profile”. Paragraph [0050] of specification discloses “application execution profile” is meant a collection of one or more parameters concerning execution of the application. For example, the application execution profile may specify one or more of i) a CPU utilization of the application at the source node; ii) a memory footprint of the application at the source node; iii) an average cycle time of an execution engine at the source node; iv) jitter at the source node execution engine; v) a size of a state of the application; vi) execution priority; vii) a configuration of the application; viii) offset (e.g. by how many milliseconds from the start of the cycle should the start of the application be delayed). Obtaining the evaluation of available computing resources at the target node may comprise obtaining output from benchmarking tools to determine the capabilities of the target node. Suitable benchmarking tools include one or more of i) Cyclictest; ii) Jitterdebugger; iii) Tshark..” Paragraph [0019] of specification discloses “on-demand benchmarking of the target node 106-2 and the network 112 for a given control application state size and application profile are thus performed. Packages able to provide such benchmarking include, for example, Cyclictest, Jitterdebugger, Tshark.”, and [0048] of specification disclosed that “Running the one or more benchmarks may comprise one or more of the following operations: run “cyclictest” to determine max jitter; run “ping/traceroot” to determine network latency; run “upower” to determine power usage; run “dd” to determine storage performance” such embodiment is related to the benchmarking is related to given application profile and there are multiple benchmarking tools. Whereas the limitation in claims 1 and 14 is related to the benchmarking tools being selected based on the application execution profile. The specification does not have support for using the application execution profile as the basis for selecting a benchmarking tool. Thus, the specification fails to disclose how the benchmarking tools being selected based on the application execution profile.
Claims 2, 4-13 and 15, 17-20, they are depend on claims 1 and 14 and do not overcome the deficiencies thereof, therefore they are rejected for the same reason as claims 1 and 14 above.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-2, 4-15 and 17-20 are rejected under 35 U.S.C. 112(b), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
As per claims 1 and 14 (line# refers to claim 1):
Lines 4, it recites the phrase “the application”. However, prior to this phrase at line 2, the claim recites “a live containerized stateful process automation application”. Thus, it is unclear whether the second recitation of “the application” is the same or different from the first recitation of “a live containerized stateful process automation application”. If they are the same, same term name should be used. For examining purposes, examiner will interpret as the same one.
As per claims 2, 4-13 and 15, 17-20:
They are method and computing device claims that depend on rejected claims and do not resolve the deficiencies thereof and are therefore rejected for the same reasons as above.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 10-12, 14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal (US Pub. 2014/0282520 A1) in view of Makin et al. (US Pub. 2018/0074748 A1), and further in view of Branson et al. (US Pub. 2009/0083717 A1), PADALA et al. (US Pub. 2022/0276953 A1) and TSUCHIYA et al. (US Pub. 2015/0205280 A1).
Sabharwal and Makin were cited in the previous Office Action.
As per claim 1, Sabharwal teaches the invention substantially as claimed including A computer-implemented transfer management method for managing a transfer of a live virtual machine from a source node to a target node of a process control system (Sabharwal, Fig. 1, VM 107E migrated/transferred from host server 104B to host server 104C; [0027] lines 3-4, The VM 107e is thus regularly moved from one host server (104b) to another host server (104c) during the daily scheduling period, for example by means of a vMotion utility that executes live migration from one physical server to another), the method comprising:
obtaining data relating to execution of the virtual machine at the source node and deriving from the data a virtual machine execution profile (Sabharwal, Fig. 5, 522 actual usage data, 511 resource requirement attributes; [0125] lines 6-14, use past resource usage data and/or resource availability data in performing their respective functions. This information may, at least in part, be generated or discovered on a continuous basis by a data mining module 431. The data mining module 431 be configured not only to gather and collect the actual usage data, but also to parse and compile the raw data to produce daily resource usage distribution (e.g., a daily resource usage pattern) for each VM and/or each host server (as VM execution profile). [0130] lines 1-7, The system 500 also includes one or more memories, e.g. process databases, in which is stored actual usage data indicating past resource usage of a plurality of virtual machines currently hosted on the physical infrastructure, and resource requirement attributes indicating resource requirements for a target virtual machine that is to be deployed on the physical infrastructure);
obtaining an evaluation of available computing resources at the target node (Sabharwal, [0140] lines 4-12, The suitability factor may be based at least in part on a total number of continuous time units in the scheduling period for which the available resources of the relevant candidate host server satisfies the resource requirements of the target VM. In one example embodiment, favorability of the suitability factor increases with a decrease in its magnitude. The suitability factor may, for example, correspond to the product of: [0141] lines 1-4, a total number of continuous time units per scheduling period for which the available resources of the relevant candidate host server satisfies the resource requirements of the target VM; [0143] lines 1-2, available resources of the relevant candidate host server in the deployment window);
determining feasibility of the transfer by comparing the available computing resources to the virtual machine execution profile (Sabharwal, [0140] lines 1-12, the suitability calculator may calculate a suitability factor for each of the candidate host servers, a particular candidate host server being selected for deployment of the target VM based at least in part on the calculated suitability factors. The suitability factor may be based at least in part on a total number of continuous time units in the scheduling period for which the available resources of the relevant candidate host server satisfies the resource requirements of the target VM (as determining feasibility by comparing the available computing resources to the virtual machine execution profile (i.e., usage pattern/scheduling period). In one example embodiment, favorability of the suitability factor increases with a decrease in its magnitude. The suitability factor may, for example, correspond to the product of: [0141] lines 1-4, a total number of continuous time units per scheduling period for which the available resources of the relevant candidate host server satisfies the resource requirements of the target VM; [0143] lines 1-2, available resources of the relevant candidate host server in the deployment window); and
in response to the transfer being determined to be feasible, initiating the transfer of the virtual machine from the source node to the target node (Sabharwal, [0075] lines 1-4, A particular host server 104 may then be selected and reserved for each hour of the deployment window, based at least in part on the suitability factors of the respective candidate host servers 104 for the respective hours; [0027] lines 3-4, a vMotion utility that executes live migration from one physical server to another; also see Fig. 1, VM 107E migrated/transferred from host server 104B to host server 104C).
Sabharwal fails to specifically teach when transfer the live virtual machine, it is a live containerized stateful process automation application, and the virtual machine is application and the containerized application on the target node in an isolated environment.
However, Makin teaches when transfer the live virtual machine, it is a live containerized stateful process automation application, and the virtual machine is application, and the containerized application on the target node in an isolated environment (Makin, [0075] lines 1-5, As explained above in connection with FIGS. 1-4, systems described herein may live migrate a stateful application (e.g., a database application) running in a software container (e.g., OPEN CONTAINER PROJECT RUNC, LXC, DOCKER, COREOS ROCKET, etc.) from one host to another with software-defined storage for containers; [0002] Software containers may provide safe, consistent, controlled, and/or lightweight operating environments by providing resource and/or namespace isolation for applications that run within the containers).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal with Makin because Makin’s teaching of live migration of a stateful application from one host to another would have provided Sabharwal’s system with the advantage and capability to allow the system to live migrating the application along with the virtual machine/containers to meet the predetermined requirement which improving the system performance and efficiency. (see Makin, [0024] “improve the functioning of one or more computing systems may reducing the computational burden of live migration operations and/or by increasing the reliability of live migration operations”).
Sabharwal and Makin fail to specifically teach predicting one or more performance indicators for execution of the application at the target node, wherein predicting the one or more performance indicators comprises: executing one or more benchmarking tools on the target node, the benchmarking tools being selected based on the application execution profile, and wherein the benchmarking by the tools is performed while executing a copy of the containerized application on the target node.
However, Branson teaches predicting one or more performance indicators for execution of the application at the target node, wherein predicting the one or more performance indicators comprises (Branson, [0029] profiling component 112 may be configured to generate a benchmark profile, which provides a profile indicating which of one or more existing benchmarks, or portions of benchmarks, may accurately represent the runtime characteristics of job 110, and/or of subroutines 114.sub.1-6. The profile execution component 115 may use the benchmark profile to invoke the appropriate benchmarks across one or more available nodes 106 (as include target node) to predict the likely performance of the job 110);
executing one or more benchmarking tools on the target node, the benchmarking tools being selected based on the application execution profile (Branson, Fig. 2C, 215, 218 Benchmark 1, 2, 3, 4, 5 which is corresponding to different program activity (as one or more benchmarking tools); [0029] profiling component 112 may be configured to generate a benchmark profile, which provides a profile indicating which of one or more existing benchmarks, or portions of benchmarks, may accurately represent the runtime characteristics of job 110, and/or of subroutines 114.sub.1-6. The profile execution component 115 may use the benchmark profile to invoke the appropriate benchmarks across one or more available nodes 106 (as include target node) to predict the likely performance of the job 110; [0036] determining which benchmarks most accurately correspond to the program action of subroutines 214, a benchmark profile may be created that may be used to predict the performance of computing job 205 when run a particular distributed system. In one embodiment, the benchmark profile may specify which benchmarks are most representative of job 205, and further may specify different proportions for the benchmarks included in the benchmark profile. For example, for a program in which 50% of the processing activity is "reads" 25% of the activity is "stores" and 25% of the activity is "connects," (as application execution profile) a benchmark profile could include benchmark 1, benchmark 2, and benchmark 3, with a contribution for each overall benchmark weighted at 50/25/25. The benchmarks may then be executed on the computing nodes of a distributed system in a variety of different ways to predict the performance of the application represented by the benchmark profile, without having to prepare, load and execute the actual application. Thus, the preferred nodes for executing each of the subroutines 214 of a job 205 on a distributed cluster (e.g., cluster 100 of FIG. 1) may be determined quickly and efficiently using the benchmark profile and associated benchmarks as a proxy for job 205 (as selected based on the application execution profile), and
wherein the benchmarking by the tools is performed while executing the application on the target node (Branson, [0007] benchmarks include application benchmarks and synthetic benchmarks. Application benchmarks dynamically record performance metrics while a software application is executing; also see [0044] Once a benchmark profile is generated to represent the performance characteristics of a given computing job, the benchmark profile may be used to predict the performance of the application by running the benchmarks specified in the benchmark profile on a given configuration of a distributed system. In one embodiment, the user may invoke the profile execution component to predict or test performance of particular job on a particular system configuration. In turn, the profile execution component accesses the benchmark profile associated with the computing job and executes the benchmarks in the profile across the nodes of a distributed system nodes (as include target node)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal and Makin with Branson because Branson’s teaching of using the different benchmarks tools at the different nodes for predicting the performance based on the application profile would have provided Sabharwal and Makin’s system with the advantage and capability to allow the system to predicting the performance before the job actually deployed to the nodes in order to improving the system performance and efficiency (see Branson, [0029] “predict the likely performance of the job 110, given the current system state of cluster 100, without actually deploying the job 110”).
Sabharwal, Makin and Branson fail to specifically teach wherein the benchmarking by the tools is performed while executing a copy of the containerized application.
However, PADALA teaches wherein the benchmarking by the tools is performed while executing a copy of the containerized application (PADALA, [0021] test code is scalably deployed in a distributed computing environment for testing application code; [0032] After the virtual compute instances for container instances 138 are instantiated, project build system 120 can deploy the compiled test code to container instances 138 for execution. In some aspects, the same test code may be deployed to container instances 138…As tests are executed against application source code deployed in application instances 134, the test code executing in container instances 138 can collect performance data for the test. The performance data may include, for example, timing information tracking the amount of time elapsed between transmission of a transaction request to application namespace 132 and receipt of a response from one of the application instances 134 in application namespace 132; please note: Makin teaches containerized application; [Examiner noted: the same (as include copy of) test code for testing application are deployed, and performance data is collected at different location based on the same test code for testing application (as copy of testing/application is performed in order to collect different performance data)]).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin and Branson with PADALA because PADALA’s teaching of deploying the same/copy of the testing code for testing the application while performing performance data collection would have provided Sabharwal, Makin and Branson’s system with the advantage and capability to allow the system to easily identifying the different target performance data based on the same base execution in order to determining the best target node for processing the workload.
Sabharwal, Makin, Branson and PADALA fail to specifically teach by the application, controlling one or more field devices regulating an industrial process.
However, TSUCHIYA teaches by the application, controlling one or more field devices regulating an industrial process (TSUCHIYA, [0105] the application 63 controls the field device 10 necessary for controlling the industrial process. The application 63 includes periodic tasks 63a and an initializing unit 63b).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson and PADALA with TSUCHIYA because TSUCHIYA’s teaching of using application to control the field device necessary for controlling the industrial process would have provided Sabharwal, Makin, Branson and PADALA’s system with the advantage and capability to allow the system to easily controlling and managing the industrial process in order to improving the system efficiency and performance.
As per claim 4, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Branson further teaches wherein predicting the one or more performance indicators comprises running one or more benchmarks on the computing resources, on the network resources, or on both (Branson, Fig. 2C, 215, 218 Benchmark 1, 2, 3, 4, 5 which is corresponding to different program activity (as one or more benchmarking tools); [0029] profiling component 112 may be configured to generate a benchmark profile, which provides a profile indicating which of one or more existing benchmarks, or portions of benchmarks, may accurately represent the runtime characteristics of job 110, and/or of subroutines 114.sub.1-6. The profile execution component 115 may use the benchmark profile to invoke the appropriate benchmarks across one or more available nodes 106 (as include target node) to predict the likely performance of the job 110; [0036] determining which benchmarks most accurately correspond to the program action of subroutines 214, a benchmark profile may be created that may be used to predict the performance of computing job 205 when run a particular distributed system. In one embodiment, the benchmark profile may specify which benchmarks are most representative of job 205, and further may specify different proportions for the benchmarks included in the benchmark profile. For example, for a program in which 50% of the processing activity is "reads" 25% of the activity is "stores" and 25% of the activity is "connects," (as application execution profile) a benchmark profile could include benchmark 1, benchmark 2, and benchmark 3, with a contribution for each overall benchmark weighted at 50/25/25. The benchmarks may then be executed on the computing nodes of a distributed system in a variety of different ways to predict the performance of the application represented by the benchmark profile, without having to prepare, load and execute the actual application. Thus, the preferred nodes for executing each of the subroutines 214 of a job 205 on a distributed cluster (e.g., cluster 100 of FIG. 1) may be determined quickly and efficiently using the benchmark profile and associated benchmarks as a proxy for job 205 (as selected based on the application execution profile).
As per claim 10, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Makin further teaches wherein the transfer comprises transferring a state of the application (Makin, [0005] lines 7-10, a checkpoint of the process in execution, wherein the checkpoint includes a representation of a state of the process in execution, (iii) transferring the checkpoint to the target computing system).
As per claim 11, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 10 above. Makin further teaches wherein transferring the state of the application comprises introducing one or more alterations to the state during the transfer (Makin, [0004] lines 3-13, performing live migrations of software containers by creating an initial application checkpoint (e.g., based a dump operation that captures stateful properties of the application), transferring the checkpoint to a target computing system, and then creating and transferring incremental application checkpoints (e.g., based on differences in the application state information) until an incremental application checkpoint is small enough (e.g., due to relatively few changes in state) that a prediction indicates that a migration, if undertaken, would be completed within a specified time objective).
As per claim 12, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Makin further teaches wherein the transfer comprises handing over execution of the application from the source node to the target node without stopping the execution (Makin, [0024] lines 11-19, improve the functioning and/or performance of a computing system that is a target of a live migration of a software container by facilitating the target computing system to host the software container in such a way that an application within the software container can provide an uninterrupted service (as without stopping). Furthermore, the systems and methods described herein may improve the functioning and/or performance of a distributed computing system by facilitating the seamless transfer of applications from one system to another).
As per claim 14, it is a computing device claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Sabharwal further teaches A computing device comprising a processor, the processor configured to execute computer executable instructions stored in a tangible medium, wherein execution of the computer executable instructions causes execution of a transfer management method (Sabharwal, Fig. 7, 702 processor, 704 main memory, instructions; [0159] FIG. 7 shows a diagrammatic representation of a machine in the example form of a computer system 700 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed; also see [0027] lines 3-4, The VM 107e is thus regularly moved from one host server (104b) to another host server (104c) during the daily scheduling period, for example by means of a vMotion utility that executes live migration from one physical server to another).
As per claim 17, it is a computing device claim of claim 4 above. Therefore, it is rejected for the same reason as claim 4 above.
Claims 2 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claims 1 and 14 respectively above, and further in view of Abali et al. (US Pub. 2015/0169337 A1).
Abali was cited in the previous Office Action.
As per claim 2, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Sabharwal further teaches wherein determining feasibility of the transfer further comprises comparing the available network resources to the virtual machine execution profile (Sabharwal, [0023] The actual usage data may comprise time-distribution information on respective past usage parameters, for example reflecting the actual amount of processing capacity, memory usage, storage usage, and/or bandwidth consumption of each current VM 107 separately, for each time unit of the scheduling period; [0065] lines 1-5, if a two-hour deployment window applies to a candidate host server 104 having the following distribution of available resources (that is, resource capacity in excess of that which is consumed by all current VMs 107 deployed on it): see TABLE Bandwidth 1, 2). In addition, Makin teaches the virtual machine is application (Makin, [0075] lines 1-5, As explained above in connection with FIGS. 1-4, systems described herein may live migrate a stateful application (e.g., a database application) running in a software container (e.g., OPEN CONTAINER PROJECT RUNC, LXC, DOCKER, COREOS ROCKET, etc.) from one host to another with software-defined storage for containers).
Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to specifically teach obtaining an evaluation of available network resources connecting the source node to the target node; and obtaining latency and/or bandwidth measurements for communications between the source and target nodes.
However, Abali teaches obtaining an evaluation of available network resources connecting the source node to the target node; and obtaining latency and/or bandwidth measurements for communications between the source and target nodes (Abali, Abstract, determining whether or not the VM mobility cost exceeds available resources in the data communications network; [0006] moving a virtual machine (VM) from one supporting host server computer to another; [0007] due to insufficient network bandwidth required to relocate VMs from host server computer to host server computer, VM relocation as a strategy may not be possible; [0009] determining whether or not the VM mobility cost exceeds available resources in the data communications network. Finally, the method includes relocating the set of the VMs only when it is determined that the VM mobility cost does not exceed the available resources of the data communications network; [0023] determining maximum available bandwidth from a source one of the physical machines 210 to a target one of the physical machines (as an evaluation of available network resources (i.e., bandwidth) connecting the source node to the target node is obtained)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Abali because Abali’s teaching of determining the bandwidth resource availability before transferring would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to ensuring the resource availability in order to prevent potential system failure due to lacks of resources which improving the system reliability and efficiency.
As per claim 15, it is a computing device claim of claim 2 above. Therefore, it is rejected for the same reason as claim 2 above.
Claims 5 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claims 4 and 17 respectively above, and further in view of Shaw et al. (US Patent. 8,548,848 B1).
Shaw was cited in the previous Office Action.
As per claim 5, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 4 above. Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to specifically teach wherein running the one or more benchmarks comprises one or more of the following operations: run “cyclictest” to determine max jitter; run “ping/traceroot” to determine network latency; run “upower” to determine power usage; run “dd” to determine storage performance.
However, Shaw teaches wherein running the one or more benchmarks comprises one or more of the following operations: run “cyclictest” to determine max jitter; run “ping/traceroot” to determine network latency; run “upower” to determine power usage; run “dd” to determine storage performance (Shaw, Col 2, lines 5-7, detecting at least one of device type, service provider, connection type, connection speed, network congestion, and latency factors; Col 7, lines 58-65, a network information detection 2090 operation is also performed on the server side. The network information detection 2090 may include determining a connection speed associated with the data access device 2000 generating 2030 the ad request. Such a connection speed determination may be performed using known techniques such as ping tests that observe response from a site or domain with a benchmark time (as ping/traceroot” to determine network latency)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Shaw because Shaw’s teaching of using the benchmark to determining the network ping/latency would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to easily identifying the network status between different devices which improving the system performance and efficiency.
As per claim 18, it is a computing device claim of claim 5 above. Therefore, it is rejected for the same reason as claim 5 above.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claims 4 and 17 respectively above, and further in view of Thomason (US Pub. 2016/0330138 A1).
Thomason was cited in the previous Office Action.
As per claim 6, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 4 above. Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to specifically teach running the one or more benchmarks while running a copy of a container containing the application on the target node, without writing outputs from the copy to the process control system.
However, Thomason teaches running the one or more benchmarks while running a copy of a container containing the application on the target node, without writing outputs from the copy to the process control system (Thomason, [0022] lines 1-10, multiple types of applications may be packaged in multiple containers, enabling each container to execute independently of other containers. In this way, containers can be migrated from executing on hardware located at the customer's premises to executing in a cloud facility. A cloud broker may benchmark a container executing in individual cloud environments from multiple cloud providers to identify a particular cloud environment for the container that provides the performance specified by the organization at the lowest price (as running the one or more benchmarks while running a copy of a container containing the application on the target node, without writing outputs from the copy to the process control system (i.e., since the benchmark is running for container executing, and the result is not generated yet when the benchmark is just start)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Thomason because Thomason’s teaching of running the benchmark for container running in the target system would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to identify a particular cloud environment for the container that provides the performance specified by the organization at the lowest price which improving the system efficiency and performance.
As per claim 19, it is a computing device claim of claim 6 above. Therefore, it is rejected for the same reason as claim 6 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claim 1 above, and further in view of Loafman et al. (US Patent. 9,645,628 B1).
Loafman was cited in the previous Office Action.
As per claim 7, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to explicitly teach wherein the application execution profile specifies one or more of i) a CPU utilization of the application at the source node; ii) a memory footprint of the application at the source node; iii) an average cycle time of an execution engine at the source node; iv) jitter at the source node execution engine; v) a size of a state of the application; vi) execution priority; vii) a configuration of the application; viii) offset.
However, Loafman teaches wherein the application execution profile specifies one or more of i) a CPU utilization of the application at the source node; ii) a memory footprint of the application at the source node; iii) an average cycle time of an execution engine at the source node; iv) jitter at the source node execution engine; v) a size of a state of the application; vi) execution priority; vii) a configuration of the application; viii) offset (Loafman, Col 4, lines 59-63, Application profiles may comprise properties such as, CPU utilization, processor utilization, disk access rate, disk access volume, resident memory size, virtual memory size, priority, number of threads, network utilization, data access rate, data access volume, and the like; Col 4, lines 31-34, Compute guest applications may be migrated onto a computing appliance by employing hypervisor cluster management software. When determined by observation or through the operation of policy instructions; Col 5, lines 36-45, Monitoring systems may indicate that the compute guest application is not operating efficiently because it is bandwidth bound because it is trying to pull too much data across the low-latency front-side network, the operator, or the hypervisor monitor, may choose to migrate the compute guest application directly onto a node of the distributed data cluster. The operator, or a computer program executing per policy instructions, may migrate the compute application onto a computing appliance that is part of the distributed data cluster).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Loafman because Loafman’s teaching of application profile that including the CPU utilization would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to easily determining the CPU requirement associated with application for migration in order to improving the system performance and efficiency.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claims 1 and 14 respectively above, and further in view of Ward, Jr. (US Patent. 10,686,677 B1).
Ward was cited in the previous Office Action.
As per claim 8, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to specifically teach wherein initiating the transfer comprises issuing resource reservations for the transfer, wherein issuing resource reservations comprises issuing a computing resource reservation to the target node to reserve computing resources for execution of the application following the transfer and issuing a network resource reservation to a network management system to reserve network resources for the transfer.
However, Ward teaches wherein initiating the transfer comprises issuing resource reservations for the transfer, wherein issuing resource reservations comprises issuing a computing resource reservation to the target node to reserve computing resources for execution of the application following the transfer and issuing a network resource reservation to a network management system to reserve network resources for the transfer (Ward, Fig. 1 185 and 187; Col 11, lines 6-17, Resource manager 180 may be responsible for responding to resource reservation requests from clients 148 (as indicated by the arrow labeled 185) and also for responding to reservation modification requests (as indicated by the arrow labeled 187). Migration manager 181 may be responsible for migrating instances and/or applications on behalf of resource manager 180 from one resource 120 to another, as indicated by the arrow labeled 189 and as described below in further detail. In some embodiments clients 148 may be allowed to send instance migration requests and/or application migration requests to migration manager 182. Col 5, lines 50-63, a client may have to select one of the levels for a given reservation, as well as the term or duration of the reservation…A client may choose a particular capacity level or instance size based on a number of factors. For example, in some cases a client may decide on a desired capacity level based on results performance testing done using one or more compute instances, either at a client data center or using the provider network resources (as include reserving network resources). The client may also take into account estimates of the current and projected workload levels that the reserved instance may need to support; Col 9, lines 29-44, a migration manager may be responsible for migrating live applications from one platform to another. When the resource manager identifies the resources to be used after the reservation is modified, the migration manager may be informed of the target resources by the resource manager, and the migration manager may activate the applications on the target resources at the request of the resource manager (or at the request of the client). Such a migration may involve several intermediate steps in some implementations, such as saving a state of the original instance or applications, copying elements of the state (such as memory contents) to the target resource(s), and/or restarting the machine image, operating system, applications, or other components at the target resources (As including issuing resource reservations for the transfer and issuing a computing resource reservation to the target node to reserve computing resources for execution of the application following the transfer and issuing a network resource reservation to a network management system to reserve network resources for the transfer)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Ward because Ward’s teaching of reserving the resources at the target node for migrating live applications would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to ensuring the resource availability for the application when the application is live migrated in order to prevent potential interruption of the execution of the application.
As per claim 20, it is a computing device claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA, TSUCHIYA and Ward, as applied to claim 8 above, and further in view of Park et al. (US Pub. 2004/0105446 A1).
Park was cited in the previous Office Action.
As per claim 9, Sabharwal, Makin, Branson, PADALA, TSUCHIYA and Ward teach the invention according to claim 8 above. Sabharwal, Makin, Branson, PADALA, TSUCHIYA and Ward fail to specifically teach verifying that the resources have been reserved before determining that the transfer is feasible.
However, Park teaches verifying that the resources have been reserved before determining that the transfer is feasible (Park, [0038] lines 1-4, Resource reserved data is QoS guaranteed because the transmitting node 111 and in the QoS edge router repeatedly determine whether data are reserved or not. That is, before data are transferred, data are reserved to be QoS guaranteed).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA, TSUCHIYA and Ward with Park because Park’s teaching of determine whether data are reserved before transferring would have provided Sabharwal, Makin, Branson, PADALA, TSUCHIYA and Ward’s system with the advantage and capability to allow the system to ensuring the resource availability for the transferring which improving the system performance and efficiency.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Sabharwal, Makin, Branson, PADALA and TSUCHIYA, as applied to claim 1 above, and further in view of Rodriguez et al. (US Pub. 2022/0171648 A1).
Rodriguez was cited in the previous Office Action.
As per claim 13, Sabharwal, Makin, Branson, PADALA and TSUCHIYA teach the invention according to claim 1 above. Sabharwal, Makin, Branson, PADALA and TSUCHIYA fail to specifically teach wherein transferring the application comprises updating firmware of a container for executing the application at the target node.
However, Rodriguez teaches wherein transferring the application comprises updating firmware of a container for executing the application at the target node (Rodriguez, [0070] line 23, container (hardware/firmware/software); [0072] container orchestration software (e.g., Docker) can be leveraged to distribute and deploy containerized VMs and applications (including bios/firmware updates over the air), provide fluid patching and upgrading of VMs (e.g., by updating and patching the container VM stack rather than maintaining long-lived VMs), migrate VM workloads between physical nodes; [0179] initiates the transfer of an application instance or application-related state information from the one or more source MEC servers 1236 to the one or more target MEC servers 1236 (as transferring the application comprises updating the firmware of a container for executing the application at the target node).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Sabharwal, Makin, Branson, PADALA and TSUCHIYA with Rodriguez because Rodriguez’s teaching of updating the firmware of the container with migrating the VM workload between nodes would have provided Sabharwal, Makin, Branson, PADALA and TSUCHIYA’s system with the advantage and capability to allow the system to ensuring the updated container has been initiated for executing the workload which improving the system performance and efficiency.
Response to Arguments
Applicant’s arguments with respect to claims 1-2, 4-15 and 17-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Z.X./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights