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 .
Response to Arguments
Applicant's arguments filed 29 July 2026 have been fully considered but they are not persuasive.
Regarding claim 1, Bandarupalli does not teach “calculating an up-to-date resource usage for the customer for the time period, wherein the up-to-date resource usage is an aggregated usage across a plurality of namespaces of the network computing platform associated with the customer,” because Bandarupalli’s disclosure of “generate 530, on the tenant cluster 144, one or more custom resources in the detected user namespace” does not obviate the claim limitation. Remarks at 10.
The Examiner respectfully disagrees. Bandarupalli discloses “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” (¶ 97) and “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” (¶ 45). The Examiner finds these portions of Bandarupalli teach or at least suggest “calculating an up-to-date resource usage for the customer for the time period, wherein the up-to-date resource usage is an aggregated usage across a plurality of namespaces of the network computing platform associated with the customer,” as recited in claim 1.
Regarding claim 16, Applicant contends that Baillargeon does not teach “approving resources for the time period for each of a plurality of resources types” or “denying the action if the action would cause the customer to exceed the resource allotment for the time period for any one of the plurality of resource types,” because “[t]he deadline of Baillargeon is not describes as being used to approve or deny resources for an action.” Remarks at 13-14.
The Examiner respectfully disagrees. Baillargeon discloses “[i]n some embodiments, a pod is only scheduled if all the resource ‘requests’ are satisfied including CPU, memory and extended resources” (¶ 64) and “[i]f creating or updating a resource violates a resource quota constraint, the request may fail and the hypertext transmission protocol (HTTP) status code 403 FORBIDDEN is sent with a message explaining the constraint that would have been violated” (¶ 69). The Examiner finds that Baillargeon’s disclosure of only scheduling pods when resource requests (CPU/memory) are satisfied and denying requests that violate resource quotas teaches or at least suggest the limitations of claim 16.
Regarding claim 19, Applicant contends that Yang does not teach the claim requirements. Remarks at 14-15.
The Examiner agrees and now objects to claim 19 as allowable.
Regarding claim 20, Applicant’s argument is moot, as Shotton (US 2019/0042323) is now relied on for teaching the limitations.
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, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli (US 2022/0156102) and further in view of Shotton (US 2019/0042323).
Regarding claim 1, Bandarupalli teaches: A method comprising:
receiving a custom callback from a webhook associated with 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), wherein the custom callback indicates the customer seeks to perform an action on the network computing platform (¶ 98, “The spawned application on the tenant cluster 144 can be detected 610 by the domain cluster 104 through the webhook on the tenant cluster 144”), and the custom callback is maintained, modified, and/or managed via an administrative system external to the network computing platform (¶ 66, “The application management server 108 can communicate with an API server 152 assigned to the tenant clusters 132a . . . to manage the associated tenant cluster 132a”), wherein the administrative system is separate from and not part of a control plane of the network computing platform (¶ 66, “In some implementations, each cluster can have a controller or control plane that is different from the application management server 10”);
calculating a resource requirement for the action (¶ 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”);
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”), wherein the up-to-date resource usage is an aggregated usage across a plurality of namespaces of the network computing platform associated with the customer (¶ 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”); and
Bandarupalli does not teach; however, Shotton teaches: establishing a resource allotment for a time period for a customer utilizing a network computing platform (¶ 88, “Quota period: Upon the lead world tier aggregator seeing a counter for the first time, a new reset time is computed. The reset time if the time at which the count value will be reset to zero, and thus when over quota services can begin servicing clients again”);
calculating an up-to-date resource usage for the customer for the time period (¶ 31, “the usage metric for a service is composed of a count of client requests for a particular service of a particular API during a given period”); and
approving the action, at the administrative system, in response to a sum of the resource requirement and the up-to-date resource usage being less than the resource allotment for the time period (¶ 66, “It is preferable that an API delivery server does not deny a client request unless the aggregated count received from the last synchronization plus any local requests since the synchronization exceeds the quota limit”), or denying the action, at the administrative system, in response to the sum of the resource requirement and the up-to-date resource usage being greater than the resource for the time period (¶ 17, “the enforcement of a global quota against such usage” and ¶ 45, “Quota enforcement is local. The AHEAD module in a given tier 1 aggregation server will have a list of all counters that have exceeded quota, as received from higher tiers. The HTTP proxy server application in the API delivery server can quickly determine if a counter has exceeded its quota from local information, if available”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of establishing a resource allotment for a time period for a customer utilizing a network computing platform; calculating a resource requirement for the action; calculating an up-to-date resource usage for the customer for the time period, wherein the up-to-date resource usage is an aggregated usage across a plurality of namespaces of the network computing platform associated with the customer; and approving the action, at the administrative system, in response to a sum of the resource requirement and the up-to-date resource usage being less than the resource allotment for the time period, or denying the action, at the administrative system, in response to the sum of the resource requirement and the up-to-date resource usage being greater than the resource for the time period, as taught by Shotton, 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 “enforcing global usage quotas in a distributed computing system where a client device may contact any of a large number of machines in the system to request service,” as indicated by Shotton (¶ 2).
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, Bandarupalli teaches: The method of claim 1, wherein the action comprises generating a new pod within a cluster on the network computing platform (¶ 36, “If a pod fails, the deployment may be configured to create a new pod”).
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, Bandarupalli 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 (¶ 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 that implements a RESTful API over HTTP, performs all API operations, and is responsible for storing API objects into a persistent storage backend”), and wherein the administrative system is external to the network computing platform (¶ 66, “each cluster can have a controller or control plane that is different from the application management server 108”).
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, Shotton 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 (¶ 67, “Upon timeout or exceeding the cap a configurable response can occur: respond with 503 (default), deny with 429 and rate limit headers, or allow with rate limit headers”).
Regarding claim 18, Bandarupalli teaches: The method of claim 1, further comprising tracking the customer's resource usage on the network computing platform over time (¶ 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”) by way of the custom callback established through the webhook (¶ 97, “The webhook can comprise a listener for the one or more applications 148”).
Regarding claim 20, Shotton teaches: The method of claim 1, further comprising establishing time-specific resource allocation for the customer to perform actions on the network computing platform (¶ 72, “The key id may be based one or more of: hostname, subdomain, URL path, URL query parameter, another portion of a URL, cookie value, end-user, client device id (e.g., from a certificate or otherwise), client device type, request method, request arguments, string in the request, time of day, and/or others”); and wherein approving or denying the action is further based on a desired execution time for the action (¶ 62, “the quota algorithm is enforced by an API delivery server 100 upon reading a request, including request headers, from an end-user client device. Based on the client device's request, the local AHEAD module will identify the API endpoint, the service identifier, and whether a counter and associated quota applies to the API endpoint and service identifier combination” and ¶ 72) and whether the action would exceed the time-specific resource allocation to the customer (¶ 66, “It is preferable that an API delivery server does not deny a client request unless the aggregated count received from the last synchronization plus any local requests since the synchronization exceeds the quota limit”).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bandarupalli and Shotton, as applied above, and further in view of Baillargeon (US 2023/0153162).
Regarding claim 16, Bandarupalli and Shotton 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 (¶ 64, “In some embodiments, a pod is only scheduled if all the resource “requests” are satisfied including CPU, memory and extended resources”); 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 (¶ 69, “If creating or updating a resource violates a resource quota constraint, the request may fail and the hypertext transmission protocol (HTTP) status code 403 FORBIDDEN is sent with a message explaining the constraint that would have been violated”).
It would have been obvious to a person having ordinary skill in the art, before 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 Bandarupalli and Shotton. 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).
Allowable Subject Matter
Claim 19 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 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