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 Request for Continued Examination and Applicant Amendment and Arguments filed on 10 December, 2025.
Claims 1-23 are pending in this application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10 December, 2025 has been entered.
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-3, 11-13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch et al. (US Patent. 12,197,960 B1) in view of Herbert (US Pub. 2021/0326175 A1) and further in view of Karunaratne et al. (US Pub. 2020/0225972 A1), Paraschiv et al. (US Pub. 2021/0211391 A1), SHIGETA et al. (US Pub. 2010/0100881 A1) and Li et al. (US Pub. 2014/0325521 A1).
Kakovitch, Herbert, Karunaratne and Li were cited in the previous Office Action.
As per claim 1, Kakovitch teaches the invention substantially as claimed including A non-transitory computer readable medium comprising instructions which, when executed by one or more hardware processors, causes performance of operations comprising (Kakovitch, Col 27, lines 49-55, claim 1, A system comprising: a non-transitory data store configured to store computer-executable instructions; and a computing device in communication with the non-transitory data store, wherein the computer-executable instructions, when executed by the computing device, configure the computing device to):
iteratively executing a plurality of jobs by sequentially transferring control of an execution process among a plurality of virtual machines that respectively and sequentially execute the plurality of jobs at least by (Kakovitch, Abstract, lines 1-11, execution of multiple tasks associated with a set of code in an on-demand network code execution system. A user may provide a set of code that is associated with the multiple tasks. The system may generate a first virtual machine instance for execution of a first task. The system may determine that a second task is associated with the first task and may identify a location of the first virtual machine instance. The system may further identify a second virtual machine instance for execution of the second task based on the location of the first virtual machine instance; Fig. 4B, worker 402A, execute first task, worker 402B, execute second task; also see Col 22, lines 31-37, In order to provide the results of the execution of the first task to a second execution environment for execution of the second task, the worker 402A, at (11), pushes the results of the execution of the first task to the worker 402B based on the first task provided to the worker 402A. The worker 402A may push the results to the worker 402B based on the destination identifier for the second task; Col 22, lines 55-58, Based on the obtained results for the execution of the first task, the worker 402B distributes instructions to execute the second task to an execution environment 404B of the worker 402B (as iteratively executing a plurality of jobs by sequentially transferring control of an execution process among a plurality of virtual machines that respectively and sequentially)):
executing, by a first virtual machine, application code of a first job of the plurality of jobs (Kakovitch, Abstract, lines 1-11, execution of multiple tasks associated with a set of code in an on-demand network code execution system. A user may provide a set of code that is associated with the multiple tasks. The system may generate a first virtual machine instance for execution of a first task; Col 21, lines 23-25, The worker 402A can execute the first task for the set of code in the allocated execution environment 404A);
responsive to completing execution of the application code of the first job, transferring control of the execution process from the first virtual machine to a second virtual machine (Kakovitch, Col 22, lines 31-58, in order to provide the results of the execution of the first task to a second execution environment for execution of the second task, the worker 402A, at (11), pushes the results of the execution of the first task to the worker 402B based on the first task provided to the worker 402A…Therefore, the worker 402A can push the results directly to the worker 402B or indirectly to the worker 402B via a results data store. By pushing the results in this manner, peer to peer data transfer is enabled between the workers. The worker 402B may obtain the results of the execution of the first task directly from the worker 402A. The worker 402B may obtain the results of the execution of the first task directly from the worker 402A (e.g., as a push from the worker 402A)…Based on the obtained results for the execution of the first task, the worker 402B distributes instructions to execute the second task to an execution environment 404B of the worker 402B (as transferring control of the execution process from the first virtual machine to a second virtual machine for execution of second task)).
Kakovitch fails to specifically teach when transferring control of execution process, it is at least by determining, by the first virtual machine, a second job, of the plurality of jobs, to be executed subsequent to the first job, wherein the second job is determined based on an ordered sequence of the plurality of jobs specified in metadata of a metadata file; initiating, by the first virtual machine, execution of a second virtual machine to execute the second job; and subsequent to initiating execution of the second virtual machine, self-terminating the first virtual machine.
However, Herbert teaches when transferring control of execution process, it is at least by determining, by the first thread, a second job, of the plurality of jobs to be executed subsequent to the first job (Herbert, [0096] lines 6-11, After starting the first worker, the top thread calls “wait all threads”. The first thread, Thread 1, wakes up and dequeues the work in its work queue. Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline), wherein the second job is determined based on an ordered sequence of the plurality of jobs (Herbert, [0107] lines 1-5, Dependencies may be defined and enumerated. For instance, in the above example, a dependency for “IP layer accepted packet” can be defined. The set of enumerated dependencies amongst all possible protocol layers constitutes the set of dependencies in a pipeline; also see [0216] lines 3-5, The effect of the function is to commence processing of the next layer in the pipeline);
initiating, by the first thread, execution of a second thread to execute the second job (Herbert, Fig. 8, thread 1, start next layer arrow to start thread at thread 2; [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4).
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 Kakovitch with Herbert because Herbert’s teaching of transferring control of execution process based on the execution dependencies with initiating the execution of second thread by the first thread would have provided Kakovitch’s system with the advantage and capability to allow the system to easily scheduling the execution for the different tasks which improving the system performance and efficiency (see [0003] “processing of multiple stages in a serial processing pipeline…improves performance”).
Kakovitch and Herbert fail to specifically teach the thread is virtual machine, and subsequent to initiating execution of the second virtual machine, self-terminating the first virtual machine.
However, Karunaratne teaches the thread is virtual machine, and subsequent to initiating execution of the second virtual machine, self-terminating the first virtual machine (Karunaratne, Fig. 1, 15a to 15n VMs; Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 8-20, a dataset used by the virtual machine 15 in processing a workload 150 is already loaded in the memory and is automatically shared with a new virtual machine 15 when self-replicated. Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113. For instance, in a serverless compute system, when an application or other code is required to be executed, a virtual machine 15 can be spawned, if needed, to execute the code. Thereafter, the virtual machine 15 can automatically terminate, for instance, after completion of the processing; also see [0049] lines 9-10, the virtual machine 15 can self-terminate.)
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 Kakovitch and Herbert with Karunaratne because Karunaratne’s teaching of self-replicating and self-terminating of the virtual machines with processing the workload would have provided Kakovitch and Herbert’s system with the advantage and capability to allow the system to free up the computing resources once the corresponding node/thread/VM completing its job which improving the resource utilization and system performance (see Karunaratne [0047] “free up computing resources”).
Kakovitch, Herbert and Karunaratne fail to specifically teach a first virtual machine corresponding to a first set of computing resources, requesting, by the first virtual machine from a resource manager, access to a second set of computing resources for the second virtual machine; and initiating execution of the second virtual machine with access to the second set of computing resources for executing the second job.
However, Paraschiv teaches a first virtual machine corresponding to a first set of computing resources, requesting, by the first virtual machine from a resource manager, access to a second set of computing resources for the second virtual machine; and initiating execution of the second virtual machine with access to the second set of computing resources for executing the second job (Paraschiv, Fig. 8, 830 parent compute instance (As first virtual machine) accessing the resource through 822 baseline hypervisor (as resource manager), 820A hardware devices (as including first and second set of the computing resources respectively for access by parent and nested VMs), Nested child compute instance (As second virtual machine), path 871B from nested child CI to access hardware, to the second-level hypervisor 834 (as included in the first virtual machine), via 822 baseline hypervisor to the 820A; [0028] lines 1-5, nested virtualization may be used, in which a second hypervisor is set up within the parent CI (i.e., a hypervisor other than the one used to launch the parent CI), and the CCI is launched using the second hypervisor; [0075] virtualization host 810A comprises a set of hardware devices 820A and baseline hypervisor 822 which does not support custom partitioning of compute instances of the kind discussed in the context of FIG. 7. A parent compute instance 830 may be launched by the baseline hypervisor 822. In order to create a nested compute instance 832, a second-level hypervisor 834 may be instantiated within the parent compute instance 830. The second-level hypervisor 834 may for example comprise one or more processes within the address space of the parent compute instance 830 in some implementations. When a process within the parent compute instance 830 has to access a hardware device 820A, a software pathway similar to 871A may be used—an access request may be sent to the baseline hypervisor 822, and the baseline hypervisor 822 in turn may access the hardware device and provide the response obtained from the hardware device back to the process. In contrast to path 871A, which comprises two “hops”, a three-hop path similar to 871B may be traversed for a process within the nested compute instance 832 to access hardware devices 820A, with both the second-level hypervisor 834 and the baseline hypervisor 822 being included in the path; also see [0030] a specified function to be executed or implemented at a CCI (as executing second job)).
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 Kakovitch, Herbert and Karunaratne with Paraschiv because Paraschiv’s teaching of utilizing the parent virtual machine to access the resource for the nested virtual machine would have provided Kakovitch, Herbert and Karunaratne’s system with the advantage and capability to allow the system to easily managing the resource accessing for the child virtual machine in order to improving the system security and performance.
Kakovitch, Herbert, Karunaratne and Paraschiv fail to specifically teach when self-terminating the first virtual machine, it is at least by returning the first set of computing resources to a pool of available computing resources.
However, SHIGETA teaches when self-terminating the first virtual machine, it is at least by returning the first set of computing resources to a pool of available computing resources (SHIGETA, [0079] lines 1-4, The physical resource manager 42 receives the notification of the return of the physical servers from the logical system deployment unit 37, releases the allocation of the physical servers relating to the stopped virtual machines, registers the physical servers as being free into the physical server pool 5).
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 Kakovitch, Herbert, Karunaratne and Paraschiv with SHIGETA because SHIGETA’s teaching of releasing the resource once the VM is stopped/terminated would have provided Kakovitch, Herbert, Karunaratne and Paraschiv’s system with the advantage and capability to allow the system to improving the resource utilization which improving the system performance and efficiency.
Kakovitch, Herbert, Karunaratne, Paraschiv and SHIGETA fail to specifically teach wherein the second job is determined based on an ordered sequence of the plurality of jobs specified in metadata of a metadata file.
However, Li teaches wherein the second job is determined based on an ordered sequence of the plurality of jobs specified in metadata of a metadata file (Li, [0036] lines 2-3, task metadata from a build task configuration file; [0041] lines 1-4, The task metadata further comprises execution sequence data, the execution sequence data being for indicating an execution sequence of the plurality of tasks; [0041] lines 7-9, determining that the next task to be executed is the second task according to the execution sequence 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 Kakovitch, Herbert, Karunaratne, Paraschiv and SHIGETA with Li because Li’s teaching of determining the task execution sequence based on the metadata would have provided Kakovitch, Herbert, Karunaratne, Paraschiv and SHIGETA’s system with the advantage and capability to allow the system to easily determining the task dependency relationship and resource requirements based on the task metadata which improving the processing speed and resource utilization efficiency (see Li, [0007] “provide a method for allocating resources to tasks in a build process to improve resource utilization efficiency. Further embodiments of the present invention also provide a system for allocating resources to tasks in a build process”).
As per claim 2, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert further teaches wherein iteratively executing the plurality of jobs by the plurality of threads further comprises: executing, by the second thread, the second job of the plurality of jobs (Herbert, Fig.8, threads 1 to 4; Abstract, lines 5-7, identifying the various layers of the input data object (as a plurality of jobs) and dispatching worker threads to perform the processing of the various layers of the data object; [0096] lines 1-12, In cascade scheduling (FIG. 8)…After starting the first worker, the top thread calls “wait all threads”. The first thread, Thread 1, wakes up and dequeues the work in its work queue. Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4); subsequent to executing, by the second thread, the second job: determining, by the second thread, a third job, of the plurality of jobs, to be executed subsequent to the second job based on the ordered sequence of the plurality of jobs (Herbert, Fig. 8, thread 2, start next layer; [0096] lines 1-12, In cascade scheduling (FIG. 8)… Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4); [0107] lines 1-5, Dependencies may be defined and enumerated. For instance, in the above example, a dependency for “IP layer accepted packet” can be defined. The set of enumerated dependencies amongst all possible protocol layers constitutes the set of dependencies in a pipeline; also see [0216] lines 3-5, The effect of the function is to commence processing of the next layer in the pipeline); initiating, by the second thread, execution of a third thread to execute the third job (Herbert, [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4. The cascade stops at Thread 4 which does not schedule a next worker. After starting the next layer, each worker thread processes its own layer in the data object).
In addition, Karunaratne teaches the thread is virtual machine and when executing, it is executing application code of the second job, and subsequent to initiating execution of the third virtual machine, self-terminating the second virtual machine (Karunaratne, Fig. 1, 15a to 15n VMs (as including third VM); Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 8-20, a dataset used by the virtual machine 15 in processing a workload 150 is already loaded in the memory and is automatically shared with a new virtual machine 15 when self-replicated. Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113. For instance, in a serverless compute system, when an application or other code (as application code) is required to be executed, a virtual machine 15 can be spawned, if needed, to execute the code. Thereafter, the virtual machine 15 can automatically terminate, for instance, after completion of the processing; also see [0049] lines 9-10, the virtual machine 15 can self-terminate).
Further, Li teaches wherein the second job is determined based on an ordered sequence of the plurality of jobs specified in metadata (Li, [0041] lines 1-4, The task metadata further comprises execution sequence data, the execution sequence data being for indicating an execution sequence of the plurality of tasks; [0041] lines 7-9, determining that the next task to be executed is the second task according to the execution sequence data).
As per claim 3, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert further taches wherein iteratively executing the plurality of jobs by the plurality of threads further comprises: executing, by the second thread, the second job of the plurality of jobs (Herbert, [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4).
In addition, Karunaratne teaches the thread is virtual machine and when executing, it is executing application code of a second job, and subsequent to executing, by the second virtual machine, the application code of the second job: determining that no additional jobs are to be executed subsequent to the second job; and self-terminating the second virtual machine without executing any additional virtual machines (Karunaratne, Fig. 1, 15a to 15n VMs (as including second VM); Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 11-21, Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113. For instance, in a serverless compute system, when an application or other code is required to be executed, a virtual machine 15 can be spawned, if needed, to execute the code. Thereafter, the virtual machine 15 can automatically terminate, for instance, after completion of the processing; [Examiner noted: determining if there is additional workload needed to be processed, if determining that no additional workload/code need to be executed subsequent to the second job (i.e., currently executed job), then there is no need for creating additional VM, that is without executing any additional virtual machines and then self-terminating once finishing up its current workload]).
Further, Li teaches when determining that no additional jobs are to be executed, it is based on the ordered sequence of the plurality of jobs in the metadata (Li, [0041] lines 1-4, The task metadata further comprises execution sequence data, the execution sequence data being for indicating an execution sequence of the plurality of tasks; [0041] lines 7-9, determining that the next task to be executed is the second task according to the execution sequence data).
As per claim 11, it is a method claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claims 12-13, they are method claims of claims 2-3 respectively above. Therefore, they are rejected for the same reasons as claims 2-3 respectively above.
As per claim 20, it is a system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Herbert further teaches A system comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the system to perform (Herbert, Fig. 1, 110, 150 storage, 120 processors; Claim 1, lines 3-9, the system comprising one or more memory and address formats…CPU set shared memory shared amongst a cooperative set of CPUs, and CPU local memory, and one or more accelerators, when executed by the one or more computers, to cause the one or more computers to perform operations).
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claims 1 and 11 respectively above, and further in view of Fontana et al. (US Patent. 6,237,143 B1).
Fontana was cited in the previous Office Action.
As per claim 4, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert further teaches wherein determining the second job to be executed and initiating execution of the second thread (Herbert, Fig. 8, thread 1, start next layer arrow to start thread at thread 2; [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline).
In addition, Karunaratne teaches thread is virtual machine, and executing, by the first virtual machine (Karunaratne, Fig. 1, 15a to 15n VMs; Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 11-21, Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113…).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach when executing, by the first virtual machine, it is an instance of wrapper code that is ordered subsequent to the application code in job code corresponding to the first job.
However, Fontana teaches when executing, by the first virtual machine, it is an instance of wrapper code that is ordered subsequent to the application code in job code corresponding to the first job (Fontana, Fig. 3, 30 Tool wrapper; 32 tool runner (as application code in job code corresponding to the first job), 33 post processing functions (as instance of wrapper code that is ordered subsequent to the application code 32); Col 6, lines 41-47, The output file 36 serves as an input to the post-processing functions module 33, which analyses the output produced as a result of running the tool 17 in conjunction with data stored in a monitor file 37. The analysis helps the computer system to identify the file usage patterns of the tool 17 and the information is then optionally stored in the repository 20 (as executing an instance of wrapper code that is ordered subsequent to the application code in job code corresponding to the first job); also see Fig. 1, tool 16 and 17 (as different jobs); Col 5, lines 27-29, the tool 16,17 may comprise any generic software tool used inside the computer system to perform a specific function).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Fontana because Fontana’s teaching of wrapper function/tool and executing the instance of wrapper code (i.e., post processing function) subsequence to the job/tool/code would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to analyze the generated results from previous execution of the application in order to identifying the usage patterns which improving the system efficiency and performance (see Col 1, lines 41-42, “To accomplish efficient execution of any application development aid deployment” and Col 6, lines 41-47, “The analysis helps the computer system to identify the file usage patterns of the tool”).
As per claim 14, it is a method claim of claim 4 above. Therefore, it is rejected for the same reason as claim 4 above.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claims 1 and 11 respectively above, and further in view of Awan et al. (US Pub. 2019/0102279 A1), Fontana et al. (US Patent. 6,237,143 B1) and Jokinen et al. (US Pub. 2015/0355938 A1).
Awan and Fontana were cited in the previous Office Action.
As per claim 5, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Li further teaches obtaining a metadata file comprising the ordered sequence of the plurality of jobs (Li, Fig. 3, 310 obtaining task metadata, 320 obtaining execution metadata; [0036] lines 2-3, task metadata from a build task configuration file; [0041] lines 1-4, The task metadata further comprises execution sequence data, the execution sequence data being for indicating an execution sequence of the plurality of tasks; [0041] lines 7-9, determining that the next task to be executed is the second task according to the execution sequence data).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach obtaining application code corresponding to a plurality of sets of operations associated with the plurality of jobs; and generating job code corresponding to the plurality of jobs at least by attaching pre-application-code wrapper code and post-application-code wrapper code to a plurality of segments of the application code corresponding, respectively, to the plurality of jobs, wherein the pre-application-code wrapper code points to stored workflow data to be used by the plurality of jobs, and wherein the post-application-code wrapper code specifies the second job in the ordered sequence of the plurality of jobs.
However, Awan teaches obtaining application code corresponding to a plurality of sets of operations associated with the plurality of jobs (Awan, Fig. 2A, 202 obtain a software package including a set of code to be executed on an operating system;[0033] lines 6-7, The software package 102 includes code for one or more applications; [0005] lines 3-5, Multiple copies of the same software package may be instantiated and/or executed on one or more host machines; [0049] lines 5-8, Examples of software packages 102 include a container image and a virtual machine (VM) image. Examples of software package instances include a container instance and a VM instance (as obtaining application code (i.e., code within the software package) corresponding to a plurality of sets of operations (i.e., code for one or more applications) associated with the plurality of jobs (i.e., software packages)); and
generating job code corresponding to the plurality of jobs at least by attaching pre-application-code wrapper code and post-application-code wrapper code to a plurality of segments of the application code corresponding, respectively, to the plurality of jobs (Awan, Fig. 2A, 212 generating an instrumented software package including the set of code (as generating job code) and the instrumented wrapper functions; [0064] lines 1-8, An instrumented system call wrapper function includes instrumentation code. As described above with reference to FIG. 1A, instrumentation code (such as any of instrumentation code 130a-b) is configured to perform one or more of…manipulating and/or controlling execution of the set of operations associated with requesting the system call. [0066] lines 1-12, Manipulating and/or controlling execution of the set of operations associated with requesting the system call may include…adding pre-processing and/or post-processing code to the associated system call wrapper function (as attaching pre-application-code wrapper code (i.e., pre-processing code) and post-application-code wrapper code (i.e., post-processing code) to a plurality of segments of the application code (i.e., set of code for one or more applications within each instrumented software package) corresponding, respectively, to the plurality of jobs (i.e., each instrumented software package including the wrapper function which including the pre-processing and/or post-processing code); also see [0132] lines 5-6, one or more instrumented software packages executing on one or more host machines).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Awan because Awan’s teaching of adding pre-processing and/or post-processing code to the associated system call wrapper function to the respective instrumented software packages would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to easily manipulating and controlling execution of the applications which improving the system processing performance and efficiency (see Awan [0066] to [0067] and [0113] “analyzed to determine, for example, a performance level of the instrumented software package instance”).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Awan fail to specifically teach wherein the pre-application-code wrapper code points to stored workflow data to be used by the plurality of jobs, and wherein the post-application-code wrapper code specifies the second job in the ordered sequence of the plurality of jobs.
However, Fontana teaches wherein the pre-application-code wrapper code points to stored workflow data to be used by the plurality of jobs (Fontana, Fig. 3, 30 tool wrapper, 31 preprocessing function, 32 tool runner; Fig. 4, 44 execute appropriate preprocessing including repository actions; Col 6, lines 8-20, Whenever a tool is invoked inside a computer system framework having one or more tool wrappers and a repository (such as the repository 20), the pre-processing functions module 31 of that wrapper (such as the tool wrapper 30) is invoked with a respect to the file filter to monitor the tool's I/O operations. The pre-processing functions module 31 optionally communicates with the repository 20 to identify the functionalities of the category for which the tool 17 is invoked. The module 31 also retrieves the files needed for the tool 17 to operate from the database in which the files are kept, such as the database 21, (as points to stored workflow data to be used) FIG. 1. These files serve as an input to an application, which is operated upon by the tool 17; also see Fig. 1, 21 database and 20 repository; Col 5, lines 27-29, the tool 16,17 may comprise any generic software tool used inside the computer system to perform a specific function; Col 5, lines 56-58, The tool wrapper 30 includes the tool 17, as illustrated. It is noted that a tool wrapper for the tool 16 is arranged in a like manner (each tool/job with respective tool wrapper))
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Awan with Fontana because Fontana’s teaching of wrapper function/tool that including preprocessing code function, job/tool running function and the post processing code function would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Awan’s system with the advantage and capability to allow the system to obtain the data needed for processing and later analyzing the generated results from previous execution of the application in order to identifying the usage patterns which improving the system efficiency and performance (see Col 1, lines 41-42, “To accomplish efficient execution of any application development aid deployment” and Col 6, lines 41-47, “The analysis helps the computer system to identify the file usage patterns of the tool”).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Awan and Fontana fail to specifically teach wherein the post-application-code wrapper code specifies the second job in the ordered sequence of the plurality of jobs.
However, Jokinen teaches wherein the post-application-code wrapper code specifies the second job in the ordered sequence of the plurality of jobs (Jokinen, Fig. 2, 207 (as post-application-code wrapper code); [0039] lines 4-10, The ordering scopes of a task can be indicated in the task code through the use of ordering scope transition instructions that are located in the task software at an ordering scope boundary, such as at the last instruction of each ordering scope. An ordering scope transition instruction can indicate a next ordering scope of the task to be executed).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Awan and Fontana with Jokinen because Jokinen’s teaching of post-application-code wrapper code that indicating next task to be executed would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Awan and Fontana’s system with the advantage and capability to allow the system to easily determining the execution sequency of the different tasks in order to improving the processing efficiency and performance.
As per claim 15, it is a method claim of claim 5 above. Therefore, it is rejected for the same reason as claim 5 above.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claims 1 and 11 respectively above, and further in view of Fontana et al. (US Patent. 6,237,143 B1) and Brendel (US Patent. 8,811,740 B1).
Fontana and Brendel were cited in the previous Office Action.
As per claim 6, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert further teaches iteratively executing the plurality of jobs (Herbert, Fig.8, threads 1 to 4; Abstract, lines 5-7, identifying the various layers of the input data object (as a plurality of jobs) and dispatching worker threads to perform the processing of the various layers of the data object; [0096] lines 1-12, In cascade scheduling (FIG. 8)…After starting the first worker, the top thread calls “wait all threads”. The first thread, Thread 1, wakes up and dequeues the work in its work queue. Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach prior to executing the application code of the first job, executing pre-application-code wrapper code, wherein executing the pre-application-code wrapper code comprises obtaining workflow data from a shared storage shared by each of the plurality of jobs, executing the application code of the first job using the workflow data; and subsequent to executing the application code of the first job, executing post-application-code wrapper code, wherein executing the post-application-code wrapper code includes storing, in the shared storage, modified workflow data, based on modifying the workflow data by executing the application code of the first job.
However, Fontana teaches prior to executing the application code of the first job, executing pre-application-code wrapper code, wherein executing the pre-application-code wrapper code comprises obtaining workflow data from a shared storage shared by each of the plurality of jobs, executing the application code of the first job using the workflow data (Fontana, Fig. 3, 30 tool wrapper, 31 preprocessing function, 32 tool runner; Fig. 4, 44 execute appropriate preprocessing including repository actions; Col 6, lines 8-20, Whenever a tool is invoked inside a computer system framework having one or more tool wrappers and a repository (such as the repository 20), the pre-processing functions module 31 of that wrapper (such as the tool wrapper 30) is invoked with a respect to the file filter to monitor the tool's I/O operations. The pre-processing functions module 31 optionally communicates with the repository 20 to identify the functionalities of the category for which the tool 17 is invoked. The module 31 also retrieves the files needed for the tool 17 to operate from the database in which the files are kept, such as the database 21, FIG. 1. These files serve as an input to an application, which is operated upon by the tool 17; also see Fig. 1, 21 database and 20 repository (as whole as shared storage by each of the jobs (i.e., tools); Col 5, lines 27-29, the tool 16,17 may comprise any generic software tool used inside the computer system to perform a specific function; Col 5, lines 56-58, The tool wrapper 30 includes the tool 17, as illustrated. It is noted that a tool wrapper for the tool 16 is arranged in a like manner (each tool/job with respective tool wrapper) please note” application code was taught by Kakovitch); and
subsequent to executing the application code of the first job, executing post-application-code wrapper code, wherein executing the post-application-code wrapper code includes storing, in the shared storage, information based on the data by executing the application code of the first job (Fontana, Fig. 3, 32 tool runner with tool 17 (as executing the application code of the first job), 33 post processing functions (as post-application-code wrapper code); Fig. 4, 45 invoke tool through tool wrapper; Fig. 5, 48 start executing tool through tool runner; Col 6, lines 40-47, The tool 17 stores its output into one or more files called output files 36. The output file 36 serves as an input to the post-processing functions module 33, which analyses the output produced as a result of running the tool 17 in conjunction with data stored in a monitor file 37. The analysis helps the computer system to identify the file usage patterns of the tool 17 and the information is then optionally stored in the repository 20; see Fig. 3, 33 and 22 (as wherein executing the post-application-code wrapper code includes storing, in the shared storage, information based on the data by executing the application code of the first job)).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Fontana because Fontana’s teaching of wrapper function/tool that including preprocessing code function, job/tool running function and the post processing code function would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to obtain the data needed for processing and later analyzing the generated results from previous execution of the application in order to identifying the usage patterns which improving the system efficiency and performance (see Col 1, lines 41-42, “To accomplish efficient execution of any application development aid deployment” and Col 6, lines 41-47, “The analysis helps the computer system to identify the file usage patterns of the tool”).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Fontana fail to specifically teach when storing the information, the information is modified workflow data, based on modifying the workflow data.
However, Brendel teaches when storing the information, the information is modified workflow data, based on modifying the workflow data (Brendel, Col 8, lines 9-19, applying a blending transformation to each pixel in an original image. Correction blending module 208 then creates a modified image using the new pixel color values (as based on modifying the workflow data)…correction blending module 208 may save modified images in working data store 240 for subsequent processing).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Fontana with Brendel because Brendel’s teaching of storing the modified data (as workflow data) for subsequent processing would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Fontana’s system with the advantage and capability to allow the system to further storing the modified output data after finishing the respective job which enabling the subsequence job to access that results in order to improving the processing efficiency and performance.
As per claim 16, it is a method 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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel, as applied to claim 6 above, and further in view of Dvorkin et al. (US Pub. 2005/0131899 A1).
Dvorkin was cited in the previous Office Action.
As per claim 7, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel teach the invention according to claim 6 above. Fontana teaches the post-application-code wrapper code (Fontana, Fig. 3, 32 tool runner with tool 17 (as executing the application code of the first job), 33 post processing functions (as post-application-code wrapper code).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel fail to specifically teach further identifies a set of system resources required by the second job.
However, Dvorkin teaches further identifies a set of system resources required by the second job (Dvorkin, Fig. 3, 310, 316, 318 identify next resource; [0008] lines 3-5, a plurality of shared resources to perform an operation or set of related operations. [0022] lines 34-40, In step 316 it is determined whether a further resource is needed to continue to process the operation (or set of operations). If it is determined in step 316 that a further resource is needed, the process proceeds to step 318, in which the next resource needed to process the operation (or set of operations) is identified).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel with Dvorkin because Dvorkin’s teaching of determining the resources needed for the next operation after using the resource (i.e., executing the operation) would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel’s system with the advantage and capability to allow the system to further identifying the resources needed for subsequence job after executing the current job in order to improving the processing speed and system efficiency.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claims 1 and 11 respectively above, and further in view of Lynch et al. (US Pub. 2020/0356376 A1).
Lynch was cited in the previous Office Action.
As per claim 8, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert teaches wherein initiating, by the first thread, execution of the second thread to execute the second job (Herbert, Fig. 8, thread 1, start next layer arrow to start thread at thread 2; [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4).
In addition, Karunaratne teaches thread is virtual machine (Karunaratne, Fig. 1, 15a to 15n VMs; Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 11-21, Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113…).
Further, Li teaches identifying a set of system resource requirements associated with the second job based on the metadata from the metadata file (Li, Fig. 3, 310 obtaining task metadata, 320 obtaining execution metadata; [0008] lines 6-11, obtaining execution metadata, the execution metadata comprising an execution result of a first task in the plurality of tasks, wherein the second task depends on the execution result of the first task; and determining a resource required by the second task according to the task metadata and the execution metadata; [0035] lines 3-7, Resources include, for example, network resources, CPU resources, memory resources and hard disk resources, etc. In a virtual environment or cloud environment, resources include, for example, virtual network resources, virtual CPU resources; [0050] lines 2-7, a second task depending on the execution result of a first task, the resource required by the second task may be determined according to the execution result of the first task and the task type of the second task, so as to reasonably allocate resources to the second task according to the currently available resource).
Furthermore, Paraschiv teaches requesting, from the resource manager, the second set of computing resources; and responsive to receiving access to the second set of computing resources, initiating execution of the second virtual machine using the second set of computing resources (Paraschiv, Fig. 8, 830 parent compute instance (As first virtual machine) accessing the resource through 822 baseline hypervisor (as resource manager), 820A hardware devices (as including first and second set of the computing resources respectively for access by parent and nested VMs), Nested child compute instance (As second virtual machine), path 871B from nested child CI to access hardware, to the second-level hypervisor 834 (as included in the first virtual machine), via 822 baseline hypervisor to the 820A; [0028] lines 1-5, nested virtualization may be used, in which a second hypervisor is set up within the parent CI (i.e., a hypervisor other than the one used to launch the parent CI), and the CCI is launched using the second hypervisor; [0075] virtualization host 810A comprises a set of hardware devices 820A and baseline hypervisor 822 which does not support custom partitioning of compute instances of the kind discussed in the context of FIG. 7. A parent compute instance 830 may be launched by the baseline hypervisor 822. In order to create a nested compute instance 832, a second-level hypervisor 834 may be instantiated within the parent compute instance 830. The second-level hypervisor 834 may for example comprise one or more processes within the address space of the parent compute instance 830 in some implementations. When a process within the parent compute instance 830 has to access a hardware device 820A, a software pathway similar to 871A may be used—an access request may be sent to the baseline hypervisor 822, and the baseline hypervisor 822 in turn may access the hardware device and provide the response obtained from the hardware device back to the process. In contrast to path 871A, which comprises two “hops”, a three-hop path similar to 871B may be traversed for a process within the nested compute instance 832 to access hardware devices 820A, with both the second-level hypervisor 834 and the baseline hypervisor 822 being included in the path; also see [0030] a specified function to be executed or implemented at a CCI (as executing second job)).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach requesting, from the resource manager, the second set of computing resources corresponding to the set of system resource requirements.
However, Lynch teaches requesting, from the resource manager, the second set of computing resources corresponding to the set of system resource requirements. (Lynch, [0060] lines 1-14, execution system 106 prepares for executing data processing graph 200. Resource requesting module 322 analyzes the portions and components of data processing graph 200 to determine the resource requirements for each of the components. Resource requesting module 322 determines that the each instance of the first component 202 requires five units of computational resources, each instance of the second component 204 requires three units of computational resources, each instance of the third component 206 requires four units of computational resources, each instance of the fourth component 208 requires five units of computational resources, and each instance of the fifth component 210 requires two units of computational resources; [0061] lines 1-13, resource requesting module 322 interacts with resource manager 320 to allocate resources for instances 324, 326 of the first portion of data processing graph 200, where the first portion includes components 202, 204, 206. To do so, resource requesting module 322 sends a request 350 to resource manager 320 for two workspaces (i.e., one for each required instance of the portion that includes components 202, 204, 206) from hosts 336, 338, 340, each with a size of twelve computational resource units. Resource manager 320 allocates nine computational resource units on the first host 336, eight computational resource units on the second host 338 and seven computational resource units on the third host 340).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Lynch because Lynch’s teaching of allocating the resources based on the resource requirement and launching the instance based on the allocation would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to identifying the resources needs for different instances in order to allocating the necessary resources for later execution which improving the system resource utilization and performance (also see Lynch, [0007] “The techniques described herein contribute to more efficient and/or flexible usage of computational resources of a computing system executing computer programs and therefore enhance and ensure the proper internal functioning of the computing system”).
As per claim 18, it is a method claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
Claims 9-10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claims 1 and 11 respectively above, and further in view of Bauer et al. (US Pub. 2013/0326053 A1) and Lynch et al. (US Pub. 2020/0356376 A1).
Bauer and Lynch were cited in the previous Office Action.
As per claim 9, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Herbert teaches wherein initiating, by the first thread, execution of the second thread to execute the second job (Herbert, Fig. 8, thread 1, start next layer arrow to start thread at thread 2; [0096] lines 8-15, Thread 1 processes the data object to determine the next layer that is to be processed, and starts the next worker, Thread 2 in the diagram, to process the next layer in the pipeline. Similarly, Thread 2 starts Thread 3, and Thread 3 starts Thread 4).
In addition, Karunaratne teaches thread is virtual machine (Karunaratne, Fig. 1, 15a to 15n VMs; Abstract, lines 4-6, Each of the virtual machines provisioned can process a workload assigned to the at least one computing device, Lines 9-10, each of the virtual machines can cause a new virtual machine to be created; [0047] lines 11-21, Once a virtual machine 15 completes processing of an assigned workload 150, the virtual machine 15 can post its results to memory and perform the self-destruct operation to free up computing resources 113…).
Further, Li teaches identifying resource requirements associated with the second job based on metadata in the metadata file (Li, Fig. 3, 310 obtaining task metadata, 320 obtaining execution metadata; [0008] lines 6-11, obtaining execution metadata, the execution metadata comprising an execution result of a first task in the plurality of tasks, wherein the second task depends on the execution result of the first task; and determining a resource required by the second task according to the task metadata and the execution metadata; [0035] lines 3-7, Resources include, for example, network resources, CPU resources, memory resources and hard disk resources, etc. In a virtual environment or cloud environment, resources include, for example, virtual network resources, virtual CPU resources; [0050] lines 2-7, a second task depending on the execution result of a first task, the resource required by the second task may be determined according to the execution result of the first task and the task type of the second task, so as to reasonably allocate resources to the second task according to the currently available resource).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach determining that the resource requirements exceed a threshold value; responsive to determining that the resource requirements exceed the threshold value: requesting, from the resource manager, the second set of computing resources corresponding to a first portion of the resource requirements; and requesting, from the resource manager, a third set of computing resources corresponding to a second portion of the resource requirements, wherein a sum of the second set of computing resources and the third set of computing resources is at least equal to the resource requirements associated with the second job; responsive to receiving access to the second set of computing resources and the third set of computing resources: initiating execution of the second virtual machine; and initiating execution of a third virtual machine.
However, Bauer teaches determining that the resource requirements exceed a threshold value (Bauer, Fig. 3, 330 determine resource requirement; [0068] lines 1-16, In some embodiments of the step 330, the current application resource requirements are based on usage measurements. In some of these embodiments, the apparatus performing the method monitors resource usage by the application. Further to this embodiment, if a monitored resource parameter (e.g., processing, bandwidth, memory or storage parameter) grows or shrinks beyond a threshold, a trigger event may occur and new application resource requirements based on the monitored resource usage may be determined. For example, if an application currently has an allocated 10 G Bytes of storage and the monitored storage usage grows beyond a 10% spare capacity threshold, then the apparatus may determine that the current storage application resource requirement is 11 G Bytes based on a predetermined allocation policy (e.g., increase storage in 1 G Byte increments when a usage thresholds is exceeded);
responsive to determining that the resource requirements exceed the threshold value: requesting, the second set of computing resources corresponding to a first portion of the resource requirements; and requesting, a third set of computing resources corresponding to a second portion of the resource requirements, wherein a sum of the second set of computing resources and the third set of computing resources is at least equal to the resource requirements associated with the second job (Bauer, Fig. 3, 330, 350 and 360 distribute component instances; [0083] lines 1-12, In some embodiments of the step 360, the apparatus performing the method creates two or more component instances to meet the application resource requirements (as second job resource requirement). For example, a requirement to allocate 3 G Bytes of storage may be satisfied by one component instance providing 3 G Bytes of storage or one component instance providing 2 G Bytes of storage and one component instance providing 1 G Bytes of storage. In some of these embodiments, the allocation to more than one component instance is based on anti-affinity rules. In some of these embodiments, the allocation to more than one component instance is based on the capabilities or availabilities of resources in the system); execution of the second virtual machine; and execution of a third virtual machine (Bauer, [0042] lines 2-8, The term "component instance" as used herein means the properties of one or more allocated physical resource reserved to service requests from a particular client application. For example, an allocated physical resource may be processing/compute, memory, networking, storage or the like. In some embodiments, a component instance may be a virtual machine comprising processing/compute, memory and networking resources).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Bauer because Bauer’s teaching of allocating the different portion of the resources for processing in order to meet the resource requirement when the resource requirement exceeding the threshold would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to efficiently utilizing the different portion of the system resources based on the resource capacity and utilization in order to improving the system efficiency and performance.
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Bauer fail to specifically teach when requesting the first and second resources, it is requesting, from the resource manager, the second set of computing resources, and requesting, from the resource manager, a third set of computing resources, and responsive to receiving access to the second set of computing resources and the third set of computing resources: initiating execution of the second virtual machine; and initiating execution of a third virtual machine.
However, Lynch teaches requesting, from the resource manager, the second set of computing resources, and requesting, from the resource manager, a third set of computing resources (Lynch, [0060] lines 1-14, execution system 106 prepares for executing data processing graph 200. Resource requesting module 322 analyzes the portions and components of data processing graph 200 to determine the resource requirements for each of the components. Resource requesting module 322 determines that the each instance of the first component 202 requires five units of computational resources, each instance of the second component 204 requires three units of computational resources, each instance of the third component 206 requires four units of computational resources, each instance of the fourth component 208 requires five units of computational resources, and each instance of the fifth component 210 requires two units of computational resources; [0061] lines 1-13, resource requesting module 322 interacts with resource manager 320 to allocate resources for instances 324, 326 of the first portion of data processing graph 200, where the first portion includes components 202, 204, 206. To do so, resource requesting module 322 sends a request 350 to resource manager 320 for two workspaces (i.e., one for each required instance of the portion that includes components 202, 204, 206) from hosts 336, 338, 340, each with a size of twelve computational resource units. Resource manager 320 allocates nine computational resource units on the first host 336, eight computational resource units on the second host 338 and seven computational resource units on the third host 340); and
responsive to receiving access to the second set of computing resources and the third set of computing resources: initiating execution of the second virtual machine; and initiating execution of a third virtual machine (Lynch, [0061] lines 13-21, resource manager 320 responds with message 352 indicating that it was able to allocate the requested computational resources and request 350 is therefore fulfilled. With two workspaces, each including twelve computational resource units allocated for the first, second and third components 202, 204, 206, the first second and third components 202, 204, 206 are 100% fulfilled, as is required for data processing graph 200 to execute; [0063] lines 1-3, launching a plurality of instances; also see Fig. 4B (as launching second and third instances (as virtual machine, please note: VM was taught by Karunaratne) when resources are fulfilled)).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Bauer with Lynch because Lynch’s teaching of allocating the different set of resources based on the resource requirement and launching the instances based on the allocation would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li and Bauer’s system with the advantage and capability to allow the system to identifying the resources needs for different instances in order to allocating the necessary resources for later execution which improving the system resource utilization and performance (also see Lynch, [0007] “The techniques described herein contribute to more efficient and/or flexible usage of computational resources of a computing system executing computer programs and therefore enhance and ensure the proper internal functioning of the computing system”).
As per claim 10, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Bauer and Lynch teach the invention according to claim 9 above. Karunaratne further teaches wherein execution of a first portion of the second job by the second virtual machine is performed simultaneously with execution of a second portion of the second job by the third virtual machine (Karunaratne, Fig. 1, VMs (as including second and third VMs); [0010] lines 6-14, the computing environment 10 includes the multitude of virtual machines 15, as well as the corresponding virtualization hardware and software necessary to provision and operate the virtual machines 15, the computing environment 10 can be referred to as a “virtualization environment” in some examples. Each of the virtual machines 15 can process a portion of a workload to provide, for instance, virtual desktops or other service as will be discussed; [0041] lines 8-13, both the parent virtual machine 15 and the child virtual machine 15 can resume execution independently. As can be appreciated, at least a portion of the workload 150 being processed by the parent virtual machine 15 can be assigned for processing by the child virtual machine 15 (as second virtual machine is performed simultaneously with execution of a second portion of the next job by the third virtual machine).
As per claim 19, it is a method claim of claim 9 above. Therefore, it is rejected for the same reason as claim 9 above.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel, as applied to claim 16 above, and further in view of Harwood et al. (US Pub. 2022/0342899 A1).
Harwood was cited in the previous Office Action.
As per claim 17, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel teach the invention according to claim 16 above. Fontana teaches the post-application-code wrapper code (Fontana, Fig. 3, 32 tool runner with tool 17 (as executing the application code of the first job), 33 post processing functions (as post-application-code wrapper code).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel fail to specifically teach that the post-application-code wrapper code specifies a set of system resources required by the second job.
However, Harwood teaches specifies a set of system resources required by the second job (Harwood, [0056] lines 10-12, The information included in the output intent may specify the resources that will be used to further process the data at the next portion and/or subportion of the workflow).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel with Harwood because Harwood’s teaching of specifying the resources needed for subsequence portion of the workflow would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA, Li, Fontana and Brendel’s system with the advantage and capability to allow the next node/instance to easily identifying the resources needs for performing the subsequence portion of the workflow which improving the system performance and efficiency (see Harwood, [0001] “how to efficiently do so once an execution environment is determined” and [0056] “the services that use the data as inputs, domains in which the data is to be transmitted, data transformations performed in subsequent portions and subportions of the workflow”).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claim 1 above, and further in view of Luciano et al. (US Patent. 11,307,885 B1).
Luciano was cited in the previous Office Action.
As per claim 21, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach wherein a first type of a first system resource used by the first virtual machine is different from a second type of a second system resource used by the second virtual machine.
However, Luciano teaches wherein a first type of a first system resource used by the first virtual machine is different from a second type of a second system resource used by the second virtual machine (Luciano, Col 10, lines 35-39, different VM instance types may be allocated different types of computing resources, different ratios of computing resource types, different amounts of computing resources types, and/or any combination thereof).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Luciano because Luciano’s teaching of different types of resources that allocated to different virtual machines would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to processing the different types of tasks based on the types of resources in order to improving the system efficiency and performance.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claim 1 above, and further in view of Bulson et al. (US Pub. 2005/0060704 A1).
Bulson was cited in the previous Office Action.
As per claim 22, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach determining, by the first virtual machine, resource requirements for the second job; and requesting, by the first virtual machine, allocation of a resource for the second job based on the resource requirements.
However, Bulson teaches determining, by the first virtual machine, resource requirements for the second job; and requesting, by the first virtual machine, allocation of a resource for the second job based on the resource requirements (Bulson, [0024] lines 1-6, at least one of the virtual machines is a manager virtual machine 202 and at least one other virtual machine is referred to as a job virtual machine 204. The manager virtual machine is coupled to the job virtual machine and has the responsibility of managing the job virtual machine which is used to process a particular request; [0028] lines 5-6, The manager virtual machine determines its available resources; [0029] lines 1-4, the manager virtual machine activates a job virtual machine, STEP 316, and allocates the necessary and/or desired resources for the request; [0030] the manager virtual machine obtains a request to be processed, STEP 400. This request includes a description of the needed and/or desired resources to process the request. The manager virtual machine then initiates the starting of a job virtual machine to process the request; [0032] the manager virtual machine checks the resources defined for the job virtual machine to ensure that there are sufficient resources to process the request (as determining, by the first virtual machine, resource requirements for the next job (i.e., determining/ensuring the resource requirements)).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Bulson because Bulson’s teaching of determining the resource requirement with the available resource and allocation of the resource for processing the request would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to allow the system to ensuring the sufficient resources are allocated to the virtual machine for processing which improving the system performance and efficiency.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li, as applied to claim 1 above, and further in view of Pohlack et al. (US Patent. 10,698,668 B1).
Pohlack was cited in the previous Office Action.
As per claim 23, Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li teach the invention according to claim 1 above. Kakovitch teaches iteratively executing the plurality of jobs by the respective plurality of virtual machines comprises: executing, by the first virtual machine, a first portion of a first set of job code (Kakovitch, Abstract, lines 1-11, execution of multiple tasks associated with a set of code in an on-demand network code execution system. A user may provide a set of code that is associated with the multiple tasks. The system may generate a first virtual machine instance for execution of a first task. The system may determine that a second task is associated with the first task and may identify a location of the first virtual machine instance. The system may further identify a second virtual machine instance for execution of the second task based on the location of the first virtual machine instance).
Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li fail to specifically teach executing, by the first virtual machine, a first portion of a first set of job code to obtain the application code of the first job; and executing, by the first virtual machine, the application code of the first job to generate first workflow data of the first job.
However, Pohlack teaches executing, by the first virtual machine, a first portion of a first set of job code to obtain the application code of the first job, and executing, by the first virtual machine, the application code of the first job to generate first workflow data of the first job (Pohlack, Fig. 1, 120 wrapper program, 132, 122 intermediate code transformer, 140 intermediate code; Col 4, lines 54-63, the compiler 130 may contain an intermediate code generator 132 and a binary code generator 134. The intermediate code generator 132 may be used to perform a stage in the compilation process where the source code 110 is compiled to generate the intermediate code 140 (as a first portion of a first set of job code to obtain the application code of the first job), The binary code generator 134 may be used to perform another stage in the compilation process where the intermediate code 140 is compiled to generate binary code 150 (as executing the application code of the first job to generate first workflow data of the first job); please note: executing, and the first virtual machine was taught by Kakovitch); also see, Col 5, lines 1-8, a C language compiler may first perform a preprocessing stage, where the compiler 130 interprets certain preprocessor commands, which may be embedded in the source code 110, to make inline changes to the source code. For example, during this stage, # include files may be added, and defined macros will be inserted. In some embodiments, the compiler 130 may generate, from the preprocessed source code, the intermediate code 140. In some embodiments, the intermediate code 140 be assembly code that is targeted towards a processor family; Col 17, lines 26-34, the hot patch may implement a security update where certain vulnerable functions that may be exploited by guest virtual machines are patched to mitigate the vulnerability. In some embodiments, the list of functions may be provided via a previous analysis. In some embodiments, the list of functions may contain functions that are controllable or invokable by guest virtual machines).
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 Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li with Pohlack because Pohlack’s teaching of execution of wrapper code for obtaining the data at different stages for later processing would have provided Kakovitch, Herbert, Karunaratne, Paraschiv, SHIGETA and Li’s system with the advantage and capability to enable the system to generating the task data within the wrapper code for later processing in order to improving the system performance and efficiency.
Response to Arguments
Applicant’s arguments with respect to claims 1-23 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
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.
/ZUJIA XU/Examiner, Art Unit 2195