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 RCE filed on 3/4/2026, wherein claims 1-20 are pending.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 7-10, 14-16, and 20are rejected under 35 U.S.C. 103 as being unpatentable over Bahl et al. (US PGPUB 2021/0019194), in view of unknown author (“QuickStart: Create an Ubuntu Linux virtual machine using an ARM template”, learn.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-template, Nov 24, 2021.) (Hereafter as “Azure VM Deployment”), in view of Thomason (US PGPUB 20160330138)
As for claim 1, Bahl teaches a method comprising:
receiving a command [request] identifying a workload [application] for execution within a cluster architecture (paragraph 12, “…receive a request to deploy an application as a service mesh application…”;
selecting, based on availability of compute notes, a plurality of different runtime engines on one or more compute nodes within the cluster architecture (paragraph 12, “…partition the application into multiple microservice containers…perform a first set of actions for deploying each microservice container of the service mesh application…action can include deploying a microservice container using ….compute instance…” teaching the workload is broken into sub-applications, each sub-application/microservice is individually deployed to their own respective runtime engines. Paragraph 68 in view of 94, “…deploy one…application….that can span the multiple CSP networks 442 depending on TCOs, SLA, and other governance information for the deployed application…” (paragraph 68) in view of “provisioning module can perform…where the microservice containers 228 should be deployed…invoke…APIs…Google cloud Preemptible VM instances, Azure Low-priority VMs…and/or Google Kubernetes engine…Azure Kubernetes service, Azure container instances…” (paragraph 94) teaching the application’s sub-components/microservices are allocated resources to span multiple CSP networks 442. Thus, it is clearly capable of deploying the application to different runtime engines where each runtime engine corresponds to a compute instance inside a CSP network of the multiple CSP networks taught by the prior art. See, also, paragraph 13, “…application can include a first component deployed in a first CSP network…a second component deployed in a second CSP network…”), wherein the plurality of different runtime engines comprise a container-based runtime engine and a virtual machine (VM)-based runtime engine (Paragraph 68 in view of 94, “…deploy one…application….that can span the multiple CSP networks 442 depending on TCOs, SLA, and other governance information for the deployed application…” (paragraph 68) in view of “provisioning module can perform…where the microservice containers 228 should be deployed…invoke…APIs…Google cloud Preemptible VM instances, Azure Low-priority VMs…and/or Google Kubernetes engine…Azure Kubernetes service, Azure container instances…” (paragraph 94) teaching the application’s sub-components/microservices are allocated resources to span multiple CSP networks 442. Because Bahl teaches splitting application into multiple microservice containers, and deploying the microservice containers into plurality of different CSP networks, and CSP networks can include a container based runtime engine (e.g., Amazon Elastic Container Service/Google Kubernetes Engine/Azure Kubernetes Service/etc.) and a Virtual machine based runtime engine (e.g., Google cloud pre-emptible VM instances/Google Compute Engine/Azure Virtual Machines/etc.). Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to recognize that the system is capable of deploying different components of the workload/application to a plurality of runtime engines including a container-based runtime engine and a virtual machine (VM)-based runtime engine because doing so allows for improved distributed processing of an application workload to allow for different components of the workloads to be deployed in a different CSP that improves the performance of the specific component/microservice including both container based runtime engine CSPs and VM based runtime engine CSPs. (paragraph 12, “…governance information…TCO constraints, …SLA…governing how to provision computing resources from multiple Cloud Service Provider (CSP) networks…” and paragraph 14, “…overcome …deficiencies of the prior art by providing a …orchestration platform that can deploy …an application using compute instances provisioned from multiple CSP networks…”)
deploying, by a processing device, the workload to the container-based runtime engine and the VM-based runtime engine (Paragraph 68 in view of 94, “…deploy one…application….that can span the multiple CSP networks 442 depending on TCOs, SLA, and other governance information for the deployed application…” in view of “provisioning module can perform…where the microservice containers 228 should be deployed…invoke…APIs…Google cloud Preemptible VM instances, Azure Low-priority VMs…and/or Google Kubernetes engine…Azure Kubernetes service, Azure container instances…” (paragraph 94) teaching the application’s sub-components/microservices are allocated resources to span multiple CSP networks 442. Because Bahl teaches splitting application into multiple microservice containers, and deploying the microservice containers into plurality of different CSP networks, and CSP networks can include a container based runtime engine (e.g., Amazon Elastic Container Service/Google Kubernetes Engine/Azure Kubernetes Service/etc.) and a Virtual machine based runtime engine (e.g., Google cloud pre-emptible VM instances/Google Compute Engine/Azure Virtual Machines/etc.). Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to recognize that the system is capable of deploying different components of the workload/application to a plurality of runtime engines including a container-based runtime engine and a virtual machine (VM)-based runtime engine because doing so allows for improved distributed processing of an application workload to allow for different components of the workloads to be deployed in a different CSP that improves the performance of the specific component/microservice including both container based runtime engine CSPs and VM based runtime engine CSPs. (paragraph 12, “…governance information…TCO constraints, …SLA…governing how to provision computing resources from multiple Cloud Service Provider (CSP) networks…” and paragraph 14, “…overcome …deficiencies of the prior art by providing a …orchestration platform that can deploy …an application using compute instances provisioned from multiple CSP networks…”); and
receiving performance metrics from each of the plurality of different runtime engines corresponding to execution of the workload (paragraph 78, “…request metering module 416 can invoke the logging or monitoring APIs of the CSPs …to obtain the request metrics…capturing request metrics at various levels of granularity…” paragraph 79, “resource metering module…track the inventory of computing resources…reserved and utilized for deploying the service mesh application, including all computing resources for deploying the application, intermediate components, and the microservice containers…”. And paragraph 80, “governance metering module…monitor the service mesh application to ensure the application complies with any TCO constraints, SLA requirements, and other criteria…”).
While its known and obvious to a person of ordinary skill in the art before the effective filing date of the application that deployment of a workload into an VM runtime environment includes running of image of a VM inside the VM. However, in the interest of compact prosecution, Examiner note Bahl does not explicitly teach the disclosed Google cloud pre-emptible VM instances/Google Compute Engine/Azure Virtual Machines/etc.’s inner operational details and the use of the image of a VM.
However, Azure VM Deployment teaches a method of deploying VMs into Azure VMs including the workload comprises a configuration file [Azure Resource Manager template] that references an image of a VM [imageReference] to be utilized by the VM-based runtime engine (Page 1, “…use an Azure Resource Manager template…to deploy an ubuntu Linux virtual machine (VM) in Azure….is a …JSON file that defines the infrastructure and configuration for your project…” and Page 6, “…’imageReference’: {‘publisher’: ‘canonical’, ‘offer’: ‘UbuntuServer’, ‘sku’: “[parameters(‘ubuntoOSVersion’)]’, ‘version’: ‘latest’}…” );
It would be obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate Azure VM Deployment’s teaching of using a configuration file that references an image of a VM to be utilized by the VM-based runtime to deploy a workload to Bahl teaching at least one workload can be deployed in Azure virtual machine environment because they are directed to deployment of workload inside Azure VMs environment and because doing so allows for easy deployment of workloads into a Azure VM instance (Azure VM deployment, Pg. 1).
The present application Specification teaches in exemplary embodiments, the workload can be “…one or more benchmarks…” (paragraph 16), “workload…may contain one or more applications….applications…perform one or more tasks…” (paragraph 28), and “…benchmark application 163 may be configured to stress certain subsystems (e.g., memory, processor, storage)…indicating the performance of a particular runtime engine 170” (paragraph 53), and “…each container …and/or VM …may provide a single ….component of the application …” (paragraph 32). Thus, under the BRI, the deployment of the workload to container/VM can be understood as deploying a portion of the application to the different container/VM runtime engines. Bahl teaches deploying workload to the VM/container runtime engines where each runs a portion/component of the application as understood in view of the Specification. Examiner note Bahl and Azure VM deployment do not teach the first copy and the second copy being the same to mean the same component/portion of the application/workload is deployed to multiple different runtime engines.
However, Thomason teaches a known method of performance evaluation of workload deploying workload to different runtime environments including deploying a first copy of the workload [the container] to the first runtime engine [first cloud hosting facility] and a second copy of the workload [the container] to the second runtime engine [second cloud hosting facility], the first copy and the second copy being the same (Abstract, “….first cloud hosting facility to execute the container…a second cloud hosting facility to execute the container…” See also paragraphs 27-28. Examiner note not only the recitation of the same “the container” is deployed in multiple runtime engines/cloud hosting facilities, the prior art is directed toward comparing of performance metrics for a workload/type of workload to tell the difference between performance levels of the runtime engines, thus, it is clear the system is using the same workload to be executed at the different cloud hosting facilities in order to form a comparable/meaningful performance comparison. In addition, Examiner note the technique can be applied to both containers and VM runtime engines. See, e.g., paragraph 29, “….while the techniques and systems described herein are illustrated using examples of containers….may also be applied to other types of workloads, such as VMs…”). This known technique is applicable to the system of Bahl and Azure VM instance as they both share characteristics and capabilities, namely, they are directed to workload deployment in multiple different virtualized environments on different hardware nodes where the different virtualized environments can be containers or VMs.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Thomason would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Thomason to the teachings of Bahl and Azure VM instance would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such workload deployment features into similar systems. Further, applying deploying a first copy of the workload to the first runtime engine and a second copy of the workload to the second runtime engine, the first copy and the second copy being the same to Bahl and Azure VM instance with deployment of a workload to a VM runtime engine and a container runtime engine accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved automatic identification of optimal runtime environment to deploy a workload. (Thomason, paragraph 3).
As for claim 2, Thomason also teaches the workload comprises a performance benchmark application (paragraph 22, “….benchmark a container executing in individual cloud environments from multiple cloud providers….” Teaching the container deployed serves the functionality of benchmarking the cloud environments, thus, functionally it is a benchmark application.) Rationale to combine is same as claim 1 above.
As for claim 3, Thomason also teaches deploying the workload comprises executing the workload on each of the plurality of different runtime engines concurrently (paragraph 32, “….operations can be ….in parallel….”). Rationale to combine is same as claim 1 above.
As for claim 7, Thomason also teaches receiving the workload and a plurality of configuration options for the plurality of different runtime engines (Abstract, “first cloud hosting facility to execute the container at a performance level specified by the metadata….second cloud hosting facility to execute the container at the performance level specified by the metadata…” Here, meta data specifications are understood as configuration options.). Rationale to combine is same as claim 1 above.
As for claims 8-10 and 14, they contain similar limitations as claims 1-3 and 7 above respectively. Thus, they are rejected under the same rationales.
As for claims 15-16 and 20, they contain similar limitations as claims 1,3 and 7 above respectively. Thus, they are rejected under the same rationales.
Claim(s) 4, 11, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bahl, Azure VM Instance and Thomason, in view of Asayag et al. (US PGPUB 2021/0349767).
As for claim 4, Bahl already teaches the CSP (i.e., runtime environment) includes Kubernetes. It is well-known in the art that Kubernetes can host VMs inside containers/pods (See, e.g., google search result on “vm inside container pod”). Thus, it would be obvious the system of Bahl’s CSP implemented using Kubernetes, can include runtime engine incorporating a VM within a container. Nevertheless, in the interest of compact prosecution, Examiner note Bahl, Azure VM Instance and Thomason do not explicitly teach the Kubernetes specifically incorporates a VM within a container pod.
However, Asayag teaches a known method of workload deployment using a Kubernetes container-orchestration system inside a clustered network computing environment including deploying the workload comprises deploying the workload to a respective pod executing on the one or more compute nodes [tone or more nodes of the target computing environment] (paragraph 32, “…deploy …the virtual machine inside the container pod in accordance with the second configuration data…” in view of paragraph 23, “…one or more nodes of the target computing environment 114…”). This known technique is applicable to the system of Bahl and Azure VM Deployment as they both share characteristics and capabilities, namely, they are directed to workload deployment in a Kubernetes based container workload deployment platform.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Asayag would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Asayag to the teachings of Bahl and Azure VM Deployment would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such workload deployment features into similar systems. Further, applying a runtime engine incorporating deploying the workload to a respective pod executing on the one or more compute nodes to Bahl and Azure VM Deployment with deployment of a workload inside a Kubernetes container platform accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved flexibility of container based deployment platforms to deploy additional types of workloads such as VM based workloads. (Asavag, paragraph 7).
As for claims 11 and 17, they contain similar limitations as claim 4 above. Thus, they are rejected under the same rationales.
Claim(s) 5, 12, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bahl, Azure VM instance, and Thomason, in view of Ramtekkar et al. (US PGPUB 2022/0413941).
As for claim 5, while Bahl teaches use of historical/current workload performance metrics to help determine future deployment decisions (Abstract, “…second time steps….select and perform a second set of actions…”), and Thomason teaches performing benchmarking of multiple different workloads and selecting a destination for different workloads (Fig. 5). However, in the interest of compact prosecution, Examiner note Bahl, Azure VM instance, and Thomason do not explicitly teach the metrics are used to help determine future deployment decisions of a second/different application than the workload that generated the performance metrics.
However, Ramtekkar teaches a known method of workload/task deployment in virtualized environments including the workload is a first workload [similar computing task], and deploying a second workload [future computing task] to one of the plurality of different runtime engines based on the performance metrics (paragraph 32, “…predict the memory resource and processing resource usage for a given computing task…determine resource usage for a future computing task based on …historical logs or benchmarks for similar computing tasks…” and paragraph 17, “…schedule a computing task based on the predicted … memory resources and the processing resources…” ). This known technique is applicable to the system of Bahl, Azure VM instance, and Thomason as they both share characteristics and capabilities, namely, they are directed to workload deployment in virtualized deployment platforms including utilization of historical execution data to help future deployments.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Ramtekkar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Ramtekkar to the teachings of Bahl, Azure VM instance, and Thomason would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such workload deployment features into similar systems. Further, deployment of second workload based on performance metrics of a first workload to Bahl, Azure VM instance, and Thomason with use of first workload’s performance metrics to deploy workloads in a next time period accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow efficient load balancing. (Ramtekkar, paragraph 38).
As for claims 12 and 18, they contain similar limitations as claim 5 above. Thus. They are rejected under the same rationales.
Claim(s) 6, 13, and 19, they contain similar limitations as claims 3, 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Bahl, Azure VM Instance and Thomason, in view of De Sousa Bispo et al. (US PGPUB 20210311859).
As for claim 6, While Bahl, Azure VM Instance and Thomason teaches obtaining performance of each of the plurality of different runtime engines based on the performance metric. Bahl, Azure VM Instance and Thomason do not explicitly teach generating a heatmap that illustrates a performance of each of the different runtime engines where heatmap is understood as generating a representation of performance trend.
However, De Sousa Bispo teaches a known method of workload deployment orchestration in virtualized environments in a clustered environment (paragraph 32) including generating a heatmap that illustrates a performance of each of the plurality of different runtime engines based on the performance metrics (paragraph 40, “….time-series based analysis, performance tracking…..over time for the duration of the performance test…” and paragraph 64, “performance metric may track performance improvement or degradation between …different testing environments for a software application…” teaches tracking of trends and comparison and illustration of a performance difference of each of the different testing environments, where each testing environment is understood as corresponding to the respective runtime engine.). This known technique is applicable to the system of Bahl, Azure VM instance, and Thomason as they both share characteristics and capabilities, namely, they are directed to workload deployment in multiple different virtualized environments on different hardware nodes.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of De Sousa Bispo would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of De Sousa Bispo to the teachings of Bahl, Azure VM instance, and Thomason would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such workload deployment features into similar systems. Further, applying generating a heatmap that illustrates a performance of each of the plurality of different runtime engines based on the performance metrics to Bahl, Azure VM instance, and Thomason with deployment of a workload and tracking performance of the runtime environments running the workload accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved support for development and testing of software applications in multiple different environments. (De Sousa Bispo, paragraph 4).
As for claims 13, 19, they contain similar limitations as claims 6 above respectively. Thus, they are rejected under the same rationales.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights