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 .
DETAILED ACTION
Status of Claim
1. Applicant's amendment dated 03/19/2026 responding to the Office Action 12/23/2025 provided in the rejection of claims 1-20.
2. Claims 1, 13 and 18 have been amended.
3. Claims 1-20 are pending in the application, of which claims 1, 13 and 18 in independent form and which have been fully considered by the examiner.
Response to Amendments
4. (A). Regarding Abstract objection: Abstract objection has been withdrawn in view of applicants’ amendment.
(B). Regarding Claim objections: Claim objections have been withdrawn in view of applicants’ amendment.
(C) Regarding art rejection: Applicants' amendment necessitated new grounds of rejections presented in the following art rejection. Please see Kumar et al. (US Pub. No. 2023/0236897 A1).
Examiner Notes
5. Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 103
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.
6. Claim(s) 1-3, 5-7, 11-13, 17-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US Pub. No. 2023/0259446 A1 – art of record --herein after Sharma) in view of Kumar et al. (US Pub. No. 2023/0236897 A1 – herein after Kumar).
Regarding claim 1.
Sharma discloses
obtaining a test script (load test script – See Fig. 1, blocks 112 and 131) that tests at least a portion of a system (before an API is released, an organization may want to test the API with a load test to determine whether the API, and the underlying infrastructure, can handle an expected number of simultaneous requests/users accessing the system via the API. The load test may also be referred to as a volume test, as the load/volume test ensures that a system can handle a pre-defined volume of traffic – See paragraphs [0012]);
initiating an execution of the test script on one or more pods of a containerized environment (The load test may execute a same or different test script repeatedly and simultaneously, where the test script includes a request to the API for data from another application/system – See paragraph [0012], the start of execution of the load test until the end of the load test execution – See paragraphs [0016-0020]. The worker nodes 110 execute the load tests 112 – See paragraph [0017]. Each worker node 110 a node-container platform 124. The node-container platform 124 include one or more pods 126. Examiner respectfully notes that execution of the load test/test script on worker node that includes pods is as execution of load test/test script on the pods), wherein the execution of the test script on the one or more pods of the containerized environment generates a load on the system (The load testing worker nodes may create the traffic/load for testing purposes. Embodiments determine a predicted number of users for an API. Then, based on that predicted number of users, the load testing master node of the load test generation module may generate a load injection pattern to repeatedly send requests from one or more concurrent load testing worker nodes to the API server in different amounts and at different times to simulate the API users. The master node determines the load needed to test a given API and then may design and generate a load injection pattern based on that determination – See paragraph [0014]. The load test generation module 102 may include an across-cluster container platform 104, meant to run across a cluster. The across-cluster container platform 104 may be a Kubernetes® platform – See paragraphs [0014-0017]);
automatically controlling an amount of the load generated by the test script on the system at a given time by adjusting a number of the [[pods]] of the containerized environment executing the test script (the load testing master node of the load test generation module may generate a load injection pattern to repeatedly send requests from one or more concurrent load testing worker nodes to the API server in different amounts and at different times to simulate the API users – See paragraph [0014]. A load test injection pattern 105 for each range 302. The load test injection pattern 105 may define a load (i.e., number of requests) that will be entered/injected into the system at particular intervals of time… the load test injection pattern 105 may be 1000 requests, 2000 requests, 5000 requests, 10000 requests, 20000 requests, 30000 requests, 40000 requests and 50000 requests, with each incremental load being triggered after a span of 180 seconds (3 minutes) – See paragraphs [0039-0040])[[to provide a corresponding adjustments to the load generated by the test script on the system]]; and
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (a memory, and at least one processor that is coupled to the memory and operative to perform exemplary method – See paragraph [0010].
Sharma discloses the load testing worker nodes may create the traffic/load for testing purposes. Embodiments determine a predicted number of users for an API. Then, based on that predicted number of users, the load testing master node of the load test generation module may generate a load injection pattern to repeatedly send requests from one or more concurrent load testing worker nodes to the API server in different amounts and at different times to simulate the API users – See paragraph [0014]. Sharma does not disclose
…adjusting a number of the pods… to provide a corresponding adjustments to the load generated by the test script on the system.
Kumar discloses
automatically controlling an amount of the load generated by the test script on the system at a given time by adjusting a number of the pods of the containerized environment executing the test script to provide a corresponding adjustments to the load generated by the test script on the system (On-demand cluster manager 406 sequences and loads scripts such as, for example, cluster configuration scripts and pod/service deployment for on-demand cluster 410. A calibration mode process 500 according to an illustrative embodiment. As shown, in step 502, ingress load balancer 404 passes all requests (regular and seasonal) to regular cluster 408. In step 504, resource usage store 412 collects data indicative of the available resources against a given time series and execution time – See paragraphs [0053-0055]. As the number of pods are increased in Kubernetes (a Kubernetes engine also adds pods when the request is more), more requests can be served – See paragraph [0065]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Kumar’s teaching into Sharma’s invention because incorporating Kumar’s teaching would enhance Sharma to enable to calibrate number of pods that are increased, more requests can be served as suggested by Kumar (paragraph [0065]).
Regarding claim 2, the method of claim 1,
Sharma discloses
wherein the system comprises one or more of a server system, a storage system and a database system (a database management system – See paragraph [0016]. Data storage system – See paragraph [0029]).
Regarding claim 3, the method of claim 1,
Kumar discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time comprises maintaining a constant number of the pods of the containerized environment executing the test script (determines the range of resources required for an on-demand application/pods (seasonal execution) to run, how much time it needs to run, and knows how many resources are available in the shared resources in an existing cluster (regular execution) during that time – See paragraphs [0051-0055] and Fig. 9 and 11).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Kumar’s teaching into Sharma’s invention because incorporating Kumar’s teaching would enhance Sharma to enable to determines the range of resources required for an on-demand application/pods (seasonal execution) to run, how much time it needs to run as suggested by Kumar (paragraph [0065]).
Regarding claim 5, the method of claim 1,
Sharma discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time (A load test injection pattern 105 for each range 302. The load test injection pattern 105 may define a load (i.e., number of requests) that will be entered/injected into the system at particular intervals of time… the load test injection pattern 105 may be 1000 requests, 2000 requests, 5000 requests, 10000 requests, 20000 requests, 30000 requests, 40000 requests and 50000 requests, with each incremental load being triggered after a span of 180 seconds (3 minutes) – See paragraphs [0039-0040]) comprises
Sharma does not disclose
one or more of increasing and decreasing the number of the pods of the containerized environment executing the test script over time.
Kumar discloses
one or more of increasing and decreasing the number of the pods of the containerized environment executing the test script over time (Kubernetes clusters, pods, and containers have also introduced new technical problems as pods/containers are scaled with a cluster using a horizontal auto-scaler (HPA) functionality wherein the pod/containers are replicated within the cluster. This type of job will be executed in an interval, e.g., hourly or x times a day. With shared compute/storage/network, the nodes are enabled and added to the Kubernetes cluster. The pod network allows identification of the pod across the network with PodIPs. With this cluster, a pod can run in any node and scale based on a replica set – See paragraphs [0040-0044]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Kumar’s teaching into Sharma’s invention because incorporating Kumar’s teaching would enhance Sharma to enable to allows identification of the pod across the network with PodIPs. With this cluster, a pod can run in any node and scale based on a replica set as suggested by Kumar (paragraphs [0040-0044]).
Regarding claim 6, the method of claim 5,
Sharma discloses
wherein the execution of the test script is stopped when a user-specified load limit is reached (Prior to the start of the process 200, a developer may define a minimum and maximum number of worker nodes 110 for the system 100, based on the resources of the system, including but not limited to the hardware parameters of the system 100. Also prior to the start of the process 200, one or more load test injection patterns 105 and pattern maps 130 may be generated and stored… Initially, at S210, the load test generation module 102 receives an API 133 from an API source 134. The received API 133 may be a whitelisted API in that the API has been accepted and approved for release to a user. In one or more embodiments, whenever an API 133 is added to the API source 134, the API is also forwarded to the load test generation module 102. In some embodiments, the load test generation module 102 may receive an indication that an API 133 has been added to the API source 134, and may then retrieve the added API. The load test generation module 102 may determine, via data analysis (e.g., a log), whether the received API 133 has been load tested. In a case the received API 133 has already been load tested, the process stops – See paragraphs [0036-0037]).
Regarding claim 7, the method of claim 5,
Sharma discloses
wherein the execution of the test script is maintained at a user-specified load limit in response to the user-specified load limit being reached (a developer may define a minimum and maximum number of worker nodes 110 for the system 100, based on the resources of the system, including but not limited to the hardware parameters of the system 100. Also prior to the start of the process 200, one or more load test injection patterns 105 and pattern maps 130 may be generated and stored – See paragraph [0036]).
Regarding claim 11, the method of claim 1,
Sharma discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time is performed according to one or more user parameters entered using an application programming interface (a developer may define a minimum and maximum number of worker nodes 110 for the system 100, based on the resources of the system, including but not limited to the hardware parameters of the system 100. Also prior to the start of the process 200, one or more load test injection patterns 105 and pattern maps 130 may be generated and stored – See paragraph [0036]. The parameters of the load test, the average response time, the highest response time, the time to complete the load test, the peak response time (e.g., at which point of execution did the response time take the longest), etc – See paragraph [0047]).
Regarding claim 12, the method of claim 1,
Kumar discloses
comprising selecting a given cluster of a plurality of clusters to execute the test script based at least in part on a resource availability of one or more of the clusters of the plurality of clusters (assume that there are seven Kubernetes clusters running in a primary cluster. Two clusters 3 and 7 reached the maximum capacity with allocated CPU 3500 m and 5000 m, respectively, and memory 12022 mi. There is no room for anymore pods here. If cluster 3 and 7 get some seasonal demands, it is challenging to execute the pod here. Hence, new cluster requests will be initiated for seasonal execution. – See paragraphs [0065]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Kumar’s teaching into Sharma’s invention because incorporating Kumar’s teaching would enhance Sharma to enable to calulate, load and individual cluster as suggested by Kumar (See paragraphs [0065-0067]).
Regarding claim 13.
Sharma and Kumar disclose
An apparatus comprising:
at least one processing device comprising a processor coupled to a memory;
the at least one processing device being configured to implement the following steps:
Regarding claim 13, recites the same limitations as rejected claim 1 above.
Regarding claim 17, recites the same limitations as rejected claim 12 above.
Regarding claim 18.
Sharma and Kumar disclose
A non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing device causes the at least one processing device to perform the following steps:
Regarding claim 18, recites the same limitations as rejected claim 1 above.
Regarding claim 20, recites the same limitations as rejected claim 12 above.
8. Claim(s) 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma and Kumar as applied to claims 1 and 13 respectively above, and further in view of Zhou et al. (CN 114281474 A – art of record --herein after Zhou).
Regarding claim 4, the method of claim 1,
Zhou discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time comprises randomly adjusting the number of the pods of the containerized environment executing the test script over time (adjust the number of Pod needed by the first application in theK8S platform to the standby Pod number when the Nth period of the first application comes; so as to reach the flexible, the target of reasonably controlling the resource on the K8S platform is actively carried out – See page 2).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Zhou’s teaching into Sharma’s and Kumar’s inventions because incorporating Zhou’s teaching would enhance Sharma and Kumar to enable to adjust the number of pod needed by the application as suggested by Zhou (page 2).
Regarding claim 14, recites the same limitations as rejected claim 4 above.
9. Claim(s) 8-10, 15-16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma and Kumar as applied to claims 5, 1 and 13 respectively above, and further in view of Krishnegowda et al. (US Patent No. 11,775,352 B1 – art of record --herein after Krishnegowda).
Regarding claim 8, the method of claim 5,
Krishnegowda discloses
wherein the execution of the test script is restored to a load level associated with the given time in response to a user-specified load limit being reached (production environment 108 may be subject to different loads or levels of transactions-per-second during specific times of day (e.g., working hours vs. non-working hours) and/or days of week (e.g., Mon.-Fri. vs. weekend). As a result, production computing environment 108 has to adjust the available computing power and resources in order to satisfy the TPS value for a given time period – See col. 6, lines 48-550) and repeating the one or more of the increasing and the decreasing the number of the pods of the containerized environment executing the test script over time ((c) repeating steps a) and b) until an optimal resource cost tolerance is reached for a first one of the one or more TPS values. In some embodiments, the computing device selects a second one of the one or more TPS values and repeating steps a) to c) until an optimal resource cost tolerance is reached for the second TPS value… modifying a configuration of at least one of the computing resources in the production computing environment based upon the generated prediction comprises one or more of: i) adjusting processing and memory resources of the virtual machine, ii) adjusting processing and memory limits of the pod or the container, iii) adjusting processing resources of the lambda function, or iv) adjusting read/write units in the database – col. 2, lines 48-67 and col. 3, lines 1-28).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Krishnegowda’s teaching into Sharma’s and Kumar’s inventions because incorporating Krishnegowda’s teaching would enhance Sharma and Kumar to enable to repeat until a tolerance value is reached as suggested by Krishnegowda (col. 2, lines 48-67 and col. 3, lines 1-28)
Regarding claim 9, the method of claim 5,
Krishnegowda discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time comprises a different one of the increasing and the decreasing the number of the pods of the containerized environment executing the test script over time in response to a user-specified load limit being reached (production environment 108 may be subject to different loads or levels of transactions-per-second during specific times of day (e.g., working hours vs. non-working hours) and/or days of week (e.g., Mon.-Fri. vs. weekend). As a result, production computing environment 108 has to adjust the available computing power and resources in order to satisfy the TPS value for a given time period – See col. 6, lines 48-55).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Krishnegowda’s teaching into Sharma’s and Kumar’s inventions because incorporating Krishnegowda’s teaching would enhance Sharma and Kumar to enable to provide different loads or levels of transactions-per-second during specific times as suggested by Krishnegowda (See col. 6, lines 48-55).
Regarding claim 10, the method of claim 1,
Krishnegowda discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time is performed using one or more of a user-specified time interval (automatically predicting load values for specific time periods and proactively adjusting the computing resources 108a, 108b, 108c allocated to production computing environment 108 so as to optimize application availability and cost tolerances for the enterprise. As can be appreciated, system 100 leverages reinforcement learning concepts to continually re-train classification model 107 based upon monitoring of environment load so that the predictions provided by model 107 are improved and allow for automatic adjustment based upon changes to traffic patterns in the future – See col. 9, lines 66-67 and col. 10, lines 1-14) and a user-specified gradient indicating how much the load changes in each user-specified time interval (performance testing and tracing module 106a is configured to periodically collect, from production computing environment, a production TPS value for each of one or more historical time periods. Module 106a can monitor the performance and load of environment 108 during a period of time and collect specific TPS values for the time period at any number of different granularities. For example, module 106a can collect production TPS value data four times a day (morning, afternoon, evening, night) or more frequently (e.g., every hour). In addition, module 106a can collect production TPS values for different days of the week and/or differentiate days of the week by, e.g., weekday and weekend. FIG. 4 is a diagram of an exemplary production TPS value dataset 400 generated by module 106a for different historical time periods. As shown in FIG. 4, dataset 400 comprises a record for each time period containing e.g., daytype (WEEKDAY, WEEKEND), daytime (morning, afternoon, evening, night), and load/TPS (1×, 2×, . . . ) – See col. 8, lines 23-41).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Krishnegowda’s teaching into Sharma’s and Kumar’s inventions because incorporating Krishnegowda’s teaching would enhance Sharma and Kumar to enable to monitor the performance and load of environment 108 during a period of time and collect specific values for the time period as suggested by Krishnegowda (See col. 6, lines 48-55).
Regarding claim 15, the apparatus of claim 13,
Krishnegowda discloses
wherein the automatically controlling the amount of the load generated by the test script at the given time comprises one or more of increasing and decreasing the number of the pods of the containerized environment executing the test script over time (production environment 108 may be subject to different loads or levels of transactions-per-second during specific times of day (e.g., working hours vs. non-working hours) and/or days of week (e.g., Mon.-Fri. vs. weekend). As a result, production computing environment 108 has to adjust the available computing power and resources in order to satisfy the TPS value for a given time period – See col. 6, lines 48-55) and wherein the execution of the test script is one or more of (a) stopped when a user-specified load limit is reached, (b) maintained at the user-specified load limit in response to the user-specified load limit being reached and (c) restored to a load level associated with the given time in response to the user-specified load limit being reached (production environment 108 may be subject to different loads or levels of transactions-per-second during specific times of day (e.g., working hours vs. non-working hours) and/or days of week (e.g., Mon.-Fri. vs. weekend). As a result, production computing environment 108 has to adjust the available computing power and resources in order to satisfy the TPS value for a given time period – See col. 6, lines 48-550) and repeating the one or more of the increasing and the decreasing the number of the pods of the containerized environment executing the test script over time ((c) repeating steps a) and b) until an optimal resource cost tolerance is reached for a first one of the one or more TPS values. In some embodiments, the computing device selects a second one of the one or more TPS values and repeating steps a) to c) until an optimal resource cost tolerance is reached for the second TPS value… modifying a configuration of at least one of the computing resources in the production computing environment based upon the generated prediction comprises one or more of: i) adjusting processing and memory resources of the virtual machine, ii) adjusting processing and memory limits of the pod or the container, iii) adjusting processing resources of the lambda function, or iv) adjusting read/write units in the database – col. 2, lines 48-67 and col. 3, lines 1-28).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Krishnegowda’s teaching into Sharma’s and Kumar’s inventions because incorporating Krishnegowda’s teaching would enhance Sharma and Kumar to enable to modifying a configuration of at least one of the computing resources as suggested by Krishnegowda (col. 2, lines 48-67 and col. 3, lines 1-28).
Regarding claim 16, recites the same limitations as rejected claim 9 above.
Regarding claim 19, recites the same limitations as rejected claim 15 above.
Conclusion
10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Devendranath et al. (US Patent No. 11,843,548 B1) discloses determining a scaling value for at least one microservice of a plurality of microservices for a cluster of a container-based computing environment based on resource utilization information associated with incoming requests to the plurality of microservices and an amount of resources allocated to the cluster; in response to the at least one microservice exceeding the scaling value, reducing a number of resources utilized by the at least one microservice by storing one or more further incoming requests associated with the at least one microservice in a queue; and releasing one or more of the further incoming requests stored in the queue in response to determining that the one or more further incoming requests can be processed without the at least one microservice exceeding the scaling value – See Abstract and specification for more details.
Miriyala et al. (US Pub. No. 2024/0095158 A1) discloses performing pre-deployment checks to ensure that a computing environment is suitably configured for deploying a containerized software-defined networking (SDN) architecture system, and for performing post-deployment checks to determine the operational state of the containerized SDN architecture system after deployment to the computing environment – see Abstract and specification for more details.
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 MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Hyung S. Sough can be reached at 571-272-6799. 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192
Prosecution Insights