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 amendment filed on 12/23/2025, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Paraschiv et al. (US PGPUB 2021/0211391), in view of Unknown Author (“Kubernetes Documentation”, including child pages: kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/, kubernetes.io/docs/concepts/workloads/controllers/deployment/, and kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/, kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/, kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/, kubernetes.io/docs/concepts/extend-kubernetes/operator/, retrieved via Wayback Machine copy captured on March 15, 2023) (hereafter as “Kubernetes Documentation”).
As for claim 1, Paraschiv teaches a method for scaling workloads [instances] (Abstract, “…redistributing one or more types of resources of the …compute instance…”), the method comprising:
Obtaining, by a scaling agent, information regarding resources of one or more host machines running one or more virtual machines [virtual machine/compute instance], wherein the information indicates a utilization of one or more resource types of the one or more host machines and each of the one or more virtual machines (paragraph 16, “a compute instance such as a virtual machine …allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification …” , paragraph 18, “…collecting or obtaining metrics of various kinds (such as resource utilization levels, arrival rates….and so on…with respect to the parent compute instance and/or any child compute instances…”, paragraph 39, “….monitoring the health of various VCS resources…” and paragraph 63, “…to-be-monitored resources may include some combination for CPUs/cores, graphics processing units (GPUS), application-specific processing units …memory, persistent storage, network devices, and so on…” in view of paragraph 23, “…one or more metrics collected at one or more compute instances….that a triggering condition of the scaling policy for a resource redistribution….has been met…” Examiner note both the allocation of resources to a compute instance, and the monitoring the health of the various virtualized computing service which includes virtualization host (See, e.g., paragraph 36) can be understood as obtaining resource information of the hosts (to deploy instance on and to monitor resource for respectively) and resource usage information of the VMs.) ;
Changing, based on the information by the scaling agent, a quantity of the one or more virtual machines running on the one or more host machines (paragraph 42, “…a local instance scaling manager may perform some or all of the …….automatically initiating the types of resource redistributions indicated in the scaling policies….causing modification of the currently-allocated resource sets of one or more child compute instances or the parent compute instance…”);
Changing, based on the information by the scaling agent, a quantity of containers running or permitted to run in the one or more virtual machines (paragraph 18, “…resource redistribution indicated in the scaling policies …include….causing new child compute instances [CCI] to be launched…..causing modifications of the currently-allocated resource sets of one or more child compute instances….causing child compute instances to be terminated…” in view of paragraph 31, “…a CCI maybe set up to run a software container based on …scaling policy…” and paragraph 84, “…software containers may be used to run one or more applications within CCIs…”).
While Paraschiv uses automated scaling managers/agents to perform resource information obtaining and resource allocation for the VMs and containers, and software functionality are known to need to follow specific names for corresponding functionalities and specific inputs defined by the software functions, and Paraschiv teaches the use of API for specifying scaling policies, resource redistribution requests to be inputted generally (paragraph 38), thus, while Paraschiv does not explicitly recite using a first/second/third API call made by the scaling manager/agent explicitly, any invocation of function to perform the specific functionality would be understood as invoking the corresponding API that is the defined way to invoke the respective function to either obtain metrics or implement resource redistribution. Nevertheless, in the interest of compact prosecution, Examiner note Paraschiv does not explicitly teach the specific API call definitions themselves.
However, Kubernetes Documentation teaches a known method of obtaining resource usage information of the hosts and virtualized environments including a first application programming interface (API) call [Kubectl top/Metrics API] to obtain information regarding resources of the hosts and virtualized environments (Pg. 1, Section “Resource metrics pipeline“, “…set of metrics to support automatic scaling and similar use cases. This API makes information available about resource usage for node and pod…clients of the Kubernetes API can …query for this information…also view the resource metrics using the kubectl top command…”), and changing, via a second API call, a quantity of the one or more virtual machines [replicas] (Pg. 15, Section “Scaling a Deployment”, “…kubectl scale deployment/nginx-deployment – replicas = 10…” teaching changing the number of replicas (i.e. VM/Pods hosting containers)), and a third API call to change a quantity of containers running in the one or more pods (Pg. 26, Section - “EmphemeralContainer v1 core”, “emphemeralcontainer ….you may add to an existing Pod…args…command…env…envfrom…” teaching API for launching emphemeral container inside existing pods, thus, is a form of changing the quantity of containers running in the one or more pods). This known technique is applicable to the system of Paraschiv as they both share characteristics and capabilities, namely, they are directed to containerized environment resource usage based workload resource scaling.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Kubernetes Documentation would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kubernetes Documentation to the teachings of Paraschiv 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 VM resource allocation features into similar systems. Further, applying a first application programming interface (API) call to obtain information regarding resources of the hosts and virtualized environments, changing, via a second API call, a quantity of the one or more virtual machines, and a third API call to change the number of containers running to Paraschiv with obtaining, by a scaling agent, resource information of hosts and virtualized environments and changing the number of VMs/containers to resource scale workloads accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved auto scaling of virtualized environments executing on nodes/hosts. (Kubernetes Documentation, Pg. 1).
As for claim 2, Kubernetes Documentation also teaches wherein the first API call is directed to an API of a virtualization manager (Pg. 1, “…can query for this information…Metrics API: supporting access to CPU and memory used for workload autoscaling…need an API extension server that provides the Metrics…” and “….also view the resource metrics using the kubectl top command… Examiner note, as depicted I Fig. 1 on Pg. 1, the pipeline of API Server/Metrics-server/Kubelet/cAdvisor are all part of the pipeline for servicing the API call, it is noted because they participate in the autoscaling of pods/containers, and contain management functions, they are understood as part of the virtualization management layer of Kubernetes. In addition, “Kubectl top” where kubectl is definitionally the instruction to control the cluster management, and thus, directed to the virtualization manager of Kubernetes.). Rationale to combine same as claim 1 above.
As for claim 3, Paraschiv also teaches the virtualization manager performs hypervisor cluster balancing functions (col. 18, “…causing modifications of the currently-allocated resource sets of one or more child compute instances or the parent compute instance…” and paragraph 31, “…the container manager may receive an indication ….as part of the scaling policy, and cause the container to be run within a CCI launched …for the container…”).
As for claim 4, Paraschiv also teaches determining to change the quantity of the one or more virtual machines running on the one or more host machines is based on one or more of: a change in a number of the one or more host machines, a change in utilization of the one or more resource types of the one or more host machines, a change in a policy governing an amount of the one or more resource types assignable to the one or more virtual machines, or a change in date or time triggering a schedule based policy determining maximum utilization of the one or more resource types assignable to the one or more virtual machines (paragraph 6, “…instance scaling manager may cause the set of resources allocated for a given compute instance at a virtualization host to be automatically modified based on a scaling policy…” paragraph 23, “…LISM may determine, based at least in part on one or more metrics collected at one or more compute instances including the parent compute instance…a triggering condition of the scaling policy….has been met…” and paragraph 26, “LISM may check whether any exceptions defined in the policy applies ….(indicate that no redistributions are to be performed between the hours of 10AM and 11AM in a particular time zone…” and paragraph 63, “…one or more metrics, such as resource utilization level of one or more resources or arrival rates of various types of service requests…”).
As for claim 5, Kubernetes Documentation also teaches the scaling agent runs as part of the virtualization manager (Pg. 1, “kubectl” functionality is understood as part of the Kubernetes orchestration/management system). Rationale to combine same as claim 1 above.
As for claim 6, Paraschiv teaches before the second call, the scaling agent directs a call to a component of a distributed computational framework that is a consumer of the container orchestration platform, the call causes a capacity configuration change of the distributed computational frame work and the capacity configuration change triggers a change in the utilization (paragraph 42, “…a local instance scaling manager may perform some or all of the …….automatically initiating the types of resource redistributions indicated in the scaling policies….causing modification of the currently-allocated resource sets of one or more child compute instances or the parent compute instance…” paragraph 18, “…resource redistribution indicated in the scaling policies …include….causing new child compute instances [CCI] to be launched…..causing modifications of the currently-allocated resource sets of one or more child compute instances….causing child compute instances to be terminated…” in view of paragraph 31, “…a CCI maybe set up to run a software container based on …scaling policy…” and paragraph 84, “…software containers may be used to run one or more applications within CCIs…” Either change to resource redistribution for VM and/or for containers can reasonably read upon the claimed limitations. In addition, Examiner note because the prior art is a dynamic resource allocation/reallocation system. Any previous iteration of the same process can be understood as including the fourth call that occurred before the subsequent iteration’s first/second/third call of claim 1. Moreover, Examiner note “triggers a change in the utilization” is an intended result of the capacity configuration change, and is not itself a functional step. Thus, it is given little patentable weight. Moreover, examiner note, it would be obvious to a person of ordinary skill in the art before the effective filing date of the application to recognize changing the resources allocated to a workload would lead to changing in the utilization of resources by a workload because doing so allows the mathematical ratio of quantity of workload to amount of resources allocated to correlate using basic mathematical relationships.).
Kubernetes Documentation also teaches the one or more containers are managed by a container orchestration platform (Pg. 1. Kubernetes is a well-known container orchestration platform.); and the fourth API Call cause a capacity configuration change of the distributed computational framework (Pg. 15, Section “Scaling a Deployment”, “…kubectl scale deployment/nginx-deployment – replicas = 10…” teaching changing the number of replicas (i.e. VM/Pods hosting containers. Pg. 26, Section - “EmphemeralContainer v1 core”, “emphemeralcontainer ….you may add to an existing Pod…args…command…env…envfrom…” teaching API for launching emphemeral container inside existing pods, thus, is a form of changing the quantity of containers running in the one or more pods. Either of the above can be understood as causing a capacity configuration change.)
As for claim 7, the second API call is directed to an API server of a container control plane (Pg. 15, Section “Scaling a Deployment”, “…kubectl scale deployment/nginx-deployment – replicas = 10…” teaching changing the number of replicas (i.e. VM/Pods hosting containers. In view of Pg. 27, “…kubectl handles …..locating and authenticating to the API server…this method is recommended…no man-in-the-middle…attack is possible using this method…“ kubectl access the API/API server as the primary suggested method of accessing the API/API server in addition to use of REST interface). Rationale to combine same as claim 1 above.
As for claim 8, Kubernetes Documentation also teaches the container control plane operates as a high availability (HA)control plane (Pg. 34, “Options for Highly Available Topology…stacked control plane nodes….each control plane node runs an instance of the kube-apiserver, kube-scheduler, and kube-controller-manager…”). Rationale to combine same as claim 1 above.
As for claim 9, Kubernetes Documentation also teaches wherein the second API call is directed to an application-specific controller of a container orchestration platform (Pg. 37, “….operator….deploying an application…” and “…”Operators are clients of the Kubernetes API that acts as controllers for a custom resource…” in view of Pg. 15, teaching the Kubernetes API for changing resource allocation related to Pods/VMs.). Rationale to combine same as claim 1 above.
As for claims 10-18, they contain similar limitations as claims 1-9 above. Thus, they are rejected under the same rationales.
As for claims 19-20, they contain similar limitations as claims 1-2 above. 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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