Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 30 March 2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 30 March 2026 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.
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-15, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli (US 2022/0156102) and further in view of Gajananan (US 11,403,401) and further in view of O’Rourke (US 12,131,189).
Regarding claim 1, Bandarupalli teaches: A method comprising:
establishing a resource allotment for a time period for a customer utilizing a network computing platform (¶ 82, “the instructions for the project controller 216, when executed by processor(s), may enable the server 108 to control, on a project-by-project basis, the resource utilization based on project members and control things such as authorization of resources within a project or across other projects using a network access control list (ACL) policies”);
receiving a custom callback from a webhook associated with the network computing platform, wherein the custom callback indicates the customer seeks to perform an action on the network computing platform (¶ 97, “The domain cluster 104 can spawn 520 an HNC and a webhook on the tenant cluster 144, e.g., within or through node agent 304. The webhook can comprise a listener for the one or more applications 148. The domain cluster 104 can detect 525 an existing user namespace on the tenant cluster 144 and generate 530, on the tenant cluster 144, one or more custom resources in the detected user namespace”);
calculating a resource requirement for the action (¶ 95, “the scheduler 264 determines on which database (s) 308 the volume should be created in accordance with placement polices specified by the policy controller 228” and ¶ 45, “A project may act as an authorization target and allow administrators to set policies around sets of applications to govern resource usage, cluster access, security levels, and the like”);
calculating an up-to-date resource usage for the customer for the time period (¶ 97, “Resource utilization information for the generated one or more custom resources can then be received 540, by the domain cluster 104, from the tenant cluster 144, during execution of the one or more applications 148 on the tenant cluster 144.”).
Bandarupalli does not teach; however, Gajananan discloses: approving or denying the action based on whether the customer comprises sufficient remaining resources for the time period (col. 6:37-39, “A custom admission webhook may process the incoming request sent by the k8s API server 214 and returns its verdict (allow or deny etc.) to the k8s API based on its logic”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of approving or denying the action based on whether the customer comprises sufficient remaining resources for the time period, as taught by Gajananan, in the same way to the action, as taught by Bandarupalli. Both inventions are in the field of managing Kubernetes systems, and combining them would have predictably resulted in “preventing unauthorized helm-based application package deployment and resource changes in k8s clusters,” as indicated by Gajananan (col. 1:13-15).
Bandarupalli and Gajananan do not teach; however, O’Rourke discloses: the custom callback (col. 5:59-60, “a webhook 202 monitors requests received via a Kubernetes API Server 206, perhaps from a user 204”) is maintained, modified, and/or managed (col. 5:61-63, “The approval process is triggered by a request to the Kubernetes API Server 206 to create, modify, or delete a controlled resource, as defined in an ApprovalPolicy”) via an administrative system external to the network computing platform (col. 3:55-57, “the approval platform 102 serves as a standalone policy approval engine on a single cluster”), wherein the administrative system is separate from and not part of a control plane of the network computing platform (col. 4:7-11, “the approval platform 102 is deployed on one or more physical or virtual machines located at a location, such as at a data center, associated with the Kubernetes clusters 110”); and
approving or denying the action, at the administrative system (col. 6:26-28, “The Approver(s) 218 can be one or more users or systems that are responsible for reviewing and approving the ApprovalRequest object 212”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the custom callback is maintained, modified, and/or managed via an administrative system external to the network computing platform, wherein the administrative system is separate from and not part of a control plane of the network computing platform; and approving or denying the action, at the administrative system, as taught by O’Rourke, in the same way to the custom callback, as taught by Bandarupalli and Gajananan. Both inventions are in the field of managing requests for Kubernetes pods, and combining them would have predictably resulted in a method that “removes bottlenecks and time spent transferring approval data between service systems and a work-load deployment platform,” as indicated by O’Rourke (col. 2:35-37).
Regarding claim 2, Bandarupalli teaches: The method of claim 1, wherein the resources comprises one or more of CPU (central processing unit) usage, storage usage, disk usage, network usage, or GPU (graphics processing unit) usage (¶ 82, “The project causes grouping of resources such as memory, CPU, storage and network and quota of these resources”).
Regarding claim 3, Bandarupalli teaches: The method of claim 1, wherein establishing the resource allotment for the time period comprises establishing a customer-wide resource allotment (¶ 45, “Project may extend the namespace concept by grouping together multiple namespaces in the same cluster or across multiple clusters. Stated differently, projects can run applications on one cluster or on multiple clusters. The resources are allocated per project basis”).
Regarding claim 4, Bandarupalli teaches: The method of claim 1, wherein establishing the resource allotment for the time period comprises establishing one or more of a user-specific or a tenant group-specific resource allotment for the customer (¶ 54, “a first tenant can have a set of resources, resource capabilities, and/or resource capacities that is different from that of a second tenant. Service providers assign worker nodes to a tenant, and the tenant admin forms the clusters from the worker nodes”).
Regarding claim 5, Gajananan teaches: The method of claim 1, wherein the action comprises generating a new pod within a cluster on the network computing platform (col. 9:48, “Request 6 (Req. 6): CREATE PoD” and col. 10:53-55, “Block 732 handles requests to create internal resources such as, for example, ReplicaSet and Pod per Requests 5 and 6, respectively”).
Regarding claim 6, Bandarupalli teaches: The method of claim 5, wherein the cluster comprises a plurality of different namespaces (¶ 45, “The method of claim 5, wherein the cluster comprises a plurality of different namespaces, and wherein the customer is associated with only a portion of the plurality of different namespaces on the cluster.”), and wherein the customer is associated with only a portion of the plurality of different namespaces on the cluster (¶ 97, “The domain cluster 104 can detect 525 an existing user namespace on the tenant cluster 144 and generate 530, on the tenant cluster 144, one or more custom resources in the detected user namespace”).
Regarding claim 7, Bandarupalli teaches: The method of claim 6, wherein each of the plurality of different namespaces on the cluster comprises one or more compute nodes and persistent volumes (¶ 58, “The term “volume” may refer to an ephemeral or persistent volume of memory of a selected size that is created from a distributed storage pool of memory” and “When a volume is created, a scheduler may automatically select an optimum node on which to create the volume” and ¶ 59, “The term “worker node” may refer to the compute resources and network(s) that deploy, run, and manage containerized or VM-based applications”); and wherein each of the one or more compute nodes on each of the plurality of different namespaces comprises one or more pods for executing an application (¶ 59, “If Kubelet notices any issues with the pods running on the worker nodes then it tries to restart the pod on the same node and if the issue is with the worker node itself then the master node detects the node failure and decides to recreate the pods on the other healthy node”).
Regarding claim 8, Bandarupalli teaches: The method of claim 7, wherein the action comprises an indication of where the new pod will be located on the cluster, including which compute node will execute the new pod, and which namespace will comprise the new pod (¶ 59, “The Kubelet receives the pod specifications through an API server and executes the container associated with the pods and ensures that the containers described in the pods are running and healthy. If Kubelet notices any issues with the pods running on the worker nodes then it tries to restart the pod on the same node and if the issue is with the worker node itself then the master node detects the node failure and decides to recreate the pods on the other healthy node”).
Regarding claim 9, Bandarupalli teaches: The method of claim 1, wherein the action comprises generating a new namespace within a cluster on the network computing platform (¶ 96, “Additionally, or alternatively, one or more multi-namespace projects can be implemented on the tenant cluster 144 by the domain cluster 104”).
Regarding claim 10, Bandarupalli teaches: The method of claim 1, wherein the action comprises allocating additional storage resources to a cluster on the network computing platform (¶ 9, “The domain cluster can detect an existing user namespace on the tenant cluster and generate, on the tenant cluster, one or more custom resources in the detected user namespace” and ¶ 54, “The term “tenant” may refer to an organizational construct or logical grouping used to represent an explicit set of resources (e.g., physical infrastructure (e.g., CPUs, GPUs, memory, storage, network, and cloud clusters, people, etc.) within a domain”).
Regarding claim 11, O’Rourke teaches: The method of claim 1, wherein the webhook is a user-defined HTTP callback between the administrative system and a cluster on the network computing platform (col. 5:59-60, “a webhook 202 monitors requests received via a Kubernetes API Server 206, perhaps from a user 204” and col. 8:51-53, “Such a policy management server can include a web UI to allow requests to be approved and rejected from a central console”), and wherein the administrative system is external to the network computing platform (col. 4:7-11, “the approval platform 102 is deployed on one or more physical or virtual machines located at a location, such as at a data center, associated with the Kubernetes clusters 110”).
Regarding claim 12, Bandarupalli teaches: The method of claim 11, wherein the network computing platform is a containerized workload management system comprising: a plurality of bare metal servers (¶ 3, “A computer cluster is a set of computers that work together so that they can be viewed as a single system”); and a plurality of clusters distributed across the plurality of bare metal servers (¶ 3, “A tenant is a group of users who share a common access with specific privileges to computing resources as may be available on a cluster or across multiple clusters in a multi-clustered environment”), wherein the customer executes jobs on at least one of the plurality of clusters (¶ 3, “Multiple tenants can occupy a clustered or multi-clustered environment. Typically, when a tenant cluster is added to such an environment, existing applications executing on that cluster must be modified to execute within and be managed by the environment”).
Regarding claim 13, Bandarupalli teaches: The method of claim 12, wherein each of the plurality of clusters comprises: a control plane node (¶ 66, “each cluster can have a controller or control plane that is different from the application management server 108”) comprising an API (application program interface) server (¶ 69, “The API servers 114 and 152, which effectively act as gateways to the clusters, can be commonly each implemented as a Kubernetes API server”); a plurality of compute nodes in communication with the API server of the control plane node; and one or more pods running within each of the plurality of compute nodes (¶ 94, “The node agent 304, or Kubelet in Kubernetes, runs on each worker node and ensures that all containers are running and healthy in a pod and makes any configuration changes on the worker nodes”).
Regarding claim 14, Bandarupalli teaches: The method of claim 13, wherein the action comprises generating a new pod within one of the plurality of compute nodes (¶ 36, “The term “deployment” may refer to control of the creation, state and/or running of containerized or VM-based applications. It can specify how many replicas of a pod should run on the cluster”).
Regarding claim 15, Bandarupalli teaches: The method of claim 14, wherein calculating the resource requirement for the action comprises calculating one or more of: a CPU requirement for generating the new pod; a RAM (random access memory) requirement for generating the new pod; or a disk storage requirement for generating the new pod (¶ 95, “the placement policy can select the worker node having the least amount of storage resources consumed at that point, that is required for optimal operation of the selected application 148, or that is selected by the user”).
Regarding claim 17, Gajananan teaches: The method of claim 1, further comprising, in response to denying the action, issuing a notification to the customer indicating the action is denied for lack of remaining resources for the time period (col. 6:37-39, “A custom admission webhook may process the incoming request sent by the k8s API server 214 and returns its verdict (allow or deny etc.) to the k8s API based on its logic”).
Regarding claim 18, Gajananan teaches: The method of claim 1, further comprising tracking the customer's resource usage on the network computing platform over time by way of the custom callback established through the webhook (col. 6:33-36, “Alongside the admission controller 214C, one may use admission webhooks as part of the admission chain. K8s defines admission webhooks as HTTP callbacks and registers them based on the resource type and the request method”).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli, Gajananan, and O’Rourke, as applied above, and further in view of Baillargeon (US 2023/0153162).
Regarding claim 16, Bandarupalli, Gajananan, and O’Rourke do not teach; however, Baillargeon discloses: approving the action only if the customer comprises sufficient remaining resources for the time period for each of a plurality of resource types (¶ 62, “A pod resource “request” for a particular resource type is the sum of the resource “request” of that type for each container in the pod” and ¶ 54, “In step S86, the cluster administrator makes changes to the cluster to achieve the new resource quota target (for example, by adding or upgrading nodes in the cluster)” and ¶ 70, “The process may further include deploying a job (optionally, with an active deadline of 60 seconds, for example), in the red namespace (Step S118). The process may also include sending a watch request for a resourceQuotasAPI object in the red namespace (Step S120)”); and denying the action if the action would cause the customer to exceed the resource allotment for the time period for any one of a plurality of resource types (¶ 44, “If a resource quota is enabled in a namespace for computing resources like CPU and memory, users may specify requests or limits for those values; otherwise, the resource quota system may reject pod creation”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of approving the action only if the customer comprises sufficient remaining resources for the time period for each of a plurality of resource types; and denying the action if the action would cause the customer to exceed the resource allotment for the time period for any one of a plurality of resource types, as taught by Baillargeon, in the same way to the approving or denying, as taught by Bandarupalli, Gajananan, and O’Rourke. Both inventions are in the field of managing Kubernetes systems, and combining them would have predictably resulted in “management of resource capacity in network clouds,” as indicated by Baillargeon (¶ 1).
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli, Gajananan, and O’Rourke, as applied above, and further in view of Yang (US 10,191,778).
Regarding claim 19, Bandarupalli, Gajananan, and O’Rourke do not teach; however, Yang discloses: calculating a chargeback to the customer for their resource usage on the network computing platform (col. 13:21-25, “transferring virtual currency units from the budget for the container to a budget for the first one of the multiple computer servers based on the purchase price for the computer resource bundle determined for the first one of the multiple computer servers”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of calculating a chargeback to the customer for their resource usage on the network computing platform, as taught by Yang, in the same way to the approving or denying, as taught by Bandarupalli, Gajananan, and O’Rourke. Both inventions are in the field of managing Kubernetes systems, and combining them would have predictably resulted in “determining, for example, by a Container Manager running on a data processor in a container system, a computer resource bundle to be purchased for a container of the container system using virtual currency units,” as indicated by Yang (col. 5:11-15).
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli, Gajananan, and O’Rourke, as applied above, and further in view of Palamari (US 10,862,774).
Regarding claim 20, Bandarupalli, Gajananan, and O’Rourke do not teach; however, Palamari discloses: establishing time-specific resource allocation for the customer to perform actions on the network computing platform (col. 3:59-66, “the behavior patterns for the application information indicating time periods when the application is over-utilized (e.g., a particular hour of a day, a particular day of a week, a particular week of month, and/or the like) and a quantity of the application instances may be scaled up, time periods when the application is underutilized and the quantity of the application instances may be scaled back, and/or the like”); and wherein approving or denying the action is further based on a desired execution time for the action (col. 4:8-13, “the machine learning model may analyze the usage of the application during the different time periods (e.g., provided by the application usage information), and may determine the behavior patterns of the application based on analyzing the usage of the application during the different time periods”) and whether the action would exceed the time-specific resource allocation to the customer (col. 7:57-64, “the business rules may include rules indicating a maximum quantity of the application instances in the cloud computing environment for the entity, a maximum cost the entity will pay for the application instances, a minimum quantity of the application instances in the cloud computing environment for the entity, an availability threshold associated with the application instances”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of establishing time-specific resource allocation for the customer to perform actions on the network computing platform; and wherein approving or denying the action is further based on a desired execution time for the action and whether the action would exceed the time-specific resource allocation to the customer, as taught by Palamari, in the same way to the approving or denying, as taught by Bandarupalli, Gajananan, and O’Rourke. Both inventions are in the field of managing Kubernetes systems, and combining them would have predictably resulted in a system configured to “save costs for the entity since the entity need not purchase hardware systems and/or devices that host the services provided by the cloud computing environment,” as indicated by Palamari (col. 1:12-15).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights