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 .
Claims 21-22, 24-31, and 33-39 are presented for examination based on the amended claims in the application filed on June 24, 2026. Claims 1-20, 23, 32, and 40 have been cancelled by the applicant.
Claims 21-22, 24-31, and 33-39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 11,231,947 B2 in view of Al-Haidari, Fahd, Mohammed Sqalli, and Khaled Salah. “Impact of CPU utilization thresholds and scaling size on autoscaling cloud resources.” In 2013 IEEE 5th International Conference on Cloud Computing Technology and Science, vol. 2, pp. 256-261. IEEE, 2013.21 [herein “Al-Haidari”].
Claims 21, 29-30, and 38-39 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari in view of Fernandez, Hector, Guillaume Pierre, and Thilo Kielmann. “Autoscaling web applications in heterogeneous cloud infrastructures.” In 2014 IEEE international conference on cloud engineering, pp. 195-204. IEEE, 2014 [herein “Fernandez”].
Claims 22, 26-27, 31, and 35-36 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez as applied to claim 21, and further in view of Lorido-Botran, Tania, Jose Miguel-Alonso, and Jose A. Lozano “A review of auto-scaling techniques for elastic applications in cloud environments.” Journal of grid computing 12 (2014): 559-592 [herein “Lorido-Botran”].
Claims 24, 28, 33, and 37 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez, as applied to claim 21, and further in view of Han, Rui, Li Guo, Moustafa M. Ghanem, and Yike Guo “Lightweight resource scaling for cloud applications” In 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid 2012), pp. 644-651. IEEE, 2012 [herein “Han”].
Claims 25 and 34 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez as applied to claim 21, and further in view of US 2016/0323377 A1 Einkauf et al. [herein “Einkauf”].
This action is made Final.
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 Amendment
The amendment filed June 24, 2026 has been entered. Claims 21-22, 24-31, and 33-39 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every objection previously set forth in the Non-Final Office Action mailed March 24, 2026.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07which and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-22, 24-31, and 33-39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 11,231,947 B2 in view of Al-Haidari, Fahd, Mohammed Sqalli, and Khaled Salah. “Impact of CPU utilization thresholds and scaling size on autoscaling cloud resources.” In 2013 IEEE 5th International Conference on Cloud Computing Technology and Science, vol. 2, pp. 256-261. IEEE, 2013.21 [herein “Al-Haidari”].
As per claim 21, U.S. Patent No. 11,231,947 B2 teaches “A method comprising: initializing, by a processing device, a simulated application cluster [isolated from production traffic], the simulated application cluster comprising at least one test machine configured to process simulated online traffic”, (Claim 1, A method comprising: initializing, by a processing device, a simulated application cluster, the simulated application cluster comprising one or more testing machines, and Claim 9, the performing overall workload pressure testing on each of the test machines comprising simulating, by the processing device, online traffic to each of the test machines.)
U.S. Patent No. 11,231,947 B2 teaches “performing, by the processing device, overall workload pressure testing on each test machine in a simulated application cluster, wherein the overall workload pressure testing simulates online traffic loads across multiple test machines [simultaneously]”, (Claim 1, A method comprising: performing, by the processing device, overall workload pressure testing on each of the test machines using a preset initial workload pressure value, Claim 1, the simulated application cluster comprising one or more testing machines, and Claim 9, the performing overall workload pressure testing on each of the test machines comprising simulating, by the processing device, online traffic to each of the test machines.)
U.S. Patent No. 11,231,947 B2 teaches “adjusting, by the processing device, a preset initial workload pressure value to generate an adjusted workload pressure value”, (Claim 1, adjusting, by the processing device, the workload pressure value.)
U.S. Patent No. 11,231,947 B2 teaches “and calculating, by the processing device, an average single-machine capability of each test machine when the adjusted workload pressure value reaches a maximum value triggering a rate limit threshold of an application cluster capacity of the simulated application cluster, wherein the average single-machine capability represents a processing capacity metric for capacity planning of a production application cluster”, (Claim 1, and calculating, by the processing device, the average single-machine capability of each of the testing machines when the workload pressure value reaches a maximum value triggering a rate limit threshold of the application cluster, and Claim 6, adjusting, by the processing device, the application cluster capacity according to a planned data-handling capability of the application cluster.)
U.S. Patent No. 11,231,947 B2 teaches “wherein calculating the average single-machine capability comprises reducing, by the processing device, the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling”, (Claim 3, the calculating an average single-machine capability of each test machine comprising: reducing, by the processing device, the application cluster capacity when a load capability of the application cluster reaches a capacity reduction threshold of auto scaling.)
U.S. Patent No. 11,231,947 B2 teaches “and using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling”, (Claim 3, the calculating an average single-machine capability of each test machine comprising: using, by the processing device, an average query-per second of each of the testing machines as the average single-machine capability of the testing machines when the application cluster capacity is reduced and the load capability of the application cluster reaches a capacity expansion threshold of auto scaling.)
U.S. Patent No. 11,231,947 B2 fails to distinctly point out that the “simulated application cluster is isolated from production traffic” and “wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously”.
However, in the same field of endeavor namely optimizing resource utilization through simulating computer instances, Al-Haidari teaches “simulated application cluster is isolated from production traffic”. (Pg. 257, Para. 5, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics” [simulating]. Pg. 256, “VM instances are clustered in elastic groups” [simulated application cluster]. Pg. 257, Para. 7, “Fig. 1 shows the queuing model that we have used to simulate the cloud computing architecture. The input to the simulation is an aggregated traffic from different sources” [e.g., a simulated application cluster isolated from production traffic]. Pg. 257, Para. 7, “Regarding the load balancing (LB), we have used a Round Robin (RR) technique to implement the load balancing process in the simulation model” [test machine configured to process simulated online traffic]. Further see Sect. I-III. The examiner has interpreted that conducting a simulation experiment to evaluates CPU utilization that includes clustering VM instances into elastic groups to simulated aggregated traffic from different sources as a simulated application cluster isolated from production traffic.)
Al-Haidari also teaches “wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously”. (Pg. 257, Para. 5, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics” [performing overall workload pressure testing on each test machine]. Pg. 256, “VM instances are clustered in elastic groups” [application cluster]. Pg. 257, Para. 7, “Regarding the load balancing (LB), we have used a Round Robin (RR) technique to implement the load balancing process in the simulation model” [wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously]. Figure 1 shows that the load balancing of the network traffic across multiple test machines, e.g., simultaneously. Further see Sect. I-III. The examiner has interpreted that conducting simulation experiments that mimics the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics measured by balancing loads across the model for computing resources as wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “simulated application cluster is isolated from production traffic” and “wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously” as conceptually seen from the teaching of Al-Haidari, into that of U.S. Patent No. 11,231,947 B2 because this modification of isolating the cluster from production traffic and simulating all test machines in the cluster together simultaneously for the advantageous purpose of eliminating factors associated with instance resourcing (Pg. 256, Sect. 1) and determining the impact of utilization on cluster (Pg 257 Sect. 3), respectively. Further motivation to combine be that U.S. Patent No. 11,231,947 B2 and Al-Haidari are analogous art to the current claim are directed to optimizing resource utilization through simulating computer instances.
As per claim 22, U.S. Patent No. 11,231,947 B2 teaches “the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold”. (Claim 2, the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold.)
As per claim 24, U.S. Patent No. 11,231,947 B2 teaches “the reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio”. (Claim 4, the reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio.)
As per claim 25, U.S. Patent No. 11,231,947 B2 teaches “calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained”. (Claim 5, calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained.)
As per claim 26, U.S. Patent No. 11,231,947 B2 teaches “adjusting, by the processing device, an application cluster capacity according to a planned data-handling capability of the application cluster”. (Claim 6, adjusting, by the processing device, the application cluster capacity according to a planned data-handling capability of the application cluster.)
As per claim 27, U.S. Patent No. 11,231,947 B2 teaches “the adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster”. (Claim 7, adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to the total workload pressure value of the application cluster.)
As per claim 28, U.S. Patent No. 11,231,947 B2 teaches “initializing the simulated application cluster by: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters”, (Claim 8, initializing a simulated application cluster comprising: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters.)
U.S. Patent No. 11,231,947 B2 teaches “initializing, by the processing device, the simulated application cluster with at least two test machines if the set of application clusters comprises a single application cluster”, (Claim 8, initializing, by the processing device, the simulated application cluster with at least two testing machines if the set of application clusters comprises a single application cluster.)
U.S. Patent No. 11,231,947 B2 teaches “and initializing, by the processing device, the simulated application cluster with a single test machine if the set of application clusters comprises at least two application clusters”. (Claim 8, and initializing, by the processing device, the simulated application cluster with a single testing machine if the set of application clusters comprises at least two application clusters.)
As per claim 29, U.S. Patent No. 11,231,947 B2 teaches “the performing overall workload pressure testing on each test machine comprising simulating, by the processing device, online traffic to each test machine”. (Claim 9, the performing overall workload pressure testing on each of the test machines comprising simulating, by the processing device, online traffic to each of the test machines.)
Re Claim 30, it is an articles of manufacture claim, having similar limitations of Claim 21. Thus, Claim 30 is also rejected under the similar rationale as cited in the rejection of Claim 21.
Furthermore, regarding claim 30, U.S. Patent No. 11,231,947 B2 teaches “A non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining steps of”, (Claim 10, a storage medium for tangibly storing thereon program logic for execution by the processor, the stored program logic comprising.)
Re Claim 31, it is an articles of manufacture claim, having similar limitations of Claim 22. Thus, Claim 31 is also rejected under the similar rationale as cited in the rejection of Claim 22.
Re Claim 33, it is an articles of manufacture claim, having similar limitations of Claim 24. Thus, Claim 33 is also rejected under the similar rationale as cited in the rejection of Claim 24.
Re Claim 34, it is an articles of manufacture claim, having similar limitations of Claim 25. Thus, Claim 34 is also rejected under the similar rationale as cited in the rejection of Claim 25.
Re Claim 35, it is an articles of manufacture claim, having similar limitations of Claim 26. Thus, Claim 35 is also rejected under the similar rationale as cited in the rejection of Claim 26.
Re Claim 36, it is an articles of manufacture claim, having similar limitations of Claim 27. Thus, Claim 36 is also rejected under the similar rationale as cited in the rejection of Claim 27.
Re Claim 37, it is an articles of manufacture claim, having similar limitations of Claim 28. Thus, Claim 37 is also rejected under the similar rationale as cited in the rejection of Claim 28.
Re Claim 38, it is an articles of manufacture claim, having similar limitations of Claim 29. Thus, Claim 38 is also rejected under the similar rationale as cited in the rejection of Claim 29.
Re Claim 39, it is a system claim, having similar limitations of Claim 21. Thus, Claim 39 is also rejected under the similar rationale as cited in the rejection of Claim 21.
Furthermore, regarding claim 39, U.S. Patent No. 11,231,947 B2 teaches “A device comprising: a processor a storage medium for tangibly storing thereon program logic for execution by the processor, the stored program logic comprising”, (Claim 10, An apparatus comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor, the stored program comprising.)
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the later invention.
Claims 21, 29-30, and 38-39 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari in view of Fernandez, Hector, Guillaume Pierre, and Thilo Kielmann. “Autoscaling web applications in heterogeneous cloud infrastructures.” In 2014 IEEE international conference on cloud engineering, pp. 195-204. IEEE, 2014 [herein “Fernandez”].
As per claim 21, Al-Haidari teaches “A method comprising initializing, by a processing device, a simulated application cluster isolated from production traffic, the simulated application cluster comprising at least one test machine configured to process simulated online traffic”. (Pg. 257, Para. 5, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics” [A method to process simulated online traffic]. Pg. 256, “VM instances are clustered in elastic groups” [comprising initializing simulated application cluster comprising at least one test machine] “to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [by a processing device]. Pg. 257, Para. 7, “Fig. 1 shows the queuing model that we have used to simulate the cloud computing architecture. The input to the simulation is an aggregated traffic from different sources” [e.g., a simulated application cluster isolated from production traffic]. Pg. 257, Para. 7, “Regarding the load balancing (LB), we have used a Round Robin (RR) technique to implement the load balancing process in the simulation model” [test machine configured to process simulated online traffic]. Further see Sect. I-III. The examiner has interpreted that conducting a simulation experiment to evaluates CPU utilization that includes clustering VM instances into elastic groups to simulated aggregated traffic from different sources using load balancing techniques by a monitoring system as a method comprising: initializing, by a processing device, a simulated application cluster isolated from production traffic, the simulated application cluster comprising at least one test machine configured to process simulated online traffic.)
Al-Haidari also teaches “performing, by the processing device, overall workload pressure testing on each test machine in a simulated application cluster, wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously”. (Pg. 257, Para. 5, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics” [performing overall workload pressure testing on each test machine]. Pg. 256, “VM instances are clustered in elastic groups” [application cluster] “to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [by a processing device]. Pg. 257, Para. 7, “Regarding the load balancing (LB), we have used a Round Robin (RR) technique to implement the load balancing process in the simulation model” [in a simulated application cluster wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously]. Figure 1 shows that the load balancing of the network traffic across multiple test machines simultaneously. Further see Sect. I-III. The examiner has interpreted that conducting simulation experiments that mimics the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics measured by a monitoring system by balancing loads across the model for computing resources as performing, by the processing device, overall workload pressure testing on each test machine in a simulated application cluster, wherein the overall workload pressure testing simulates online traffic loads across multiple test machines simultaneously.)
Al-Haidari also teaches “adjusting, by the processing device, a preset initial workload pressure value to generate an adjusted workload pressure value”. (Pg. 257, Para. 8, “The arrival requests rate was assumed to be 200 Req/sec during the early periods of the simulation and then it increases to be 2400 Req/sec after 25 minutes” [adjusting a preset initial workload pressure value to generate an adjusted workload pressure value]. Pg. 256, “VM instances are clustered in elastic groups to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [by a processing device]. Further see Sect. I-III. The examiner has interpreted that setting an arrival requests rate and then increasing the rate by a monitoring system as adjusting, by the processing device, a preset initial workload pressure value to generate an adjusted workload pressure value.)
Al-Haidari also teaches “calculating, by the processing device, an average single-machine capability of each test machine when the adjusted workload pressure value reaches a maximum value triggering a rate limit threshold of an application cluster capacity of the simulated application cluster, wherein the average single-machine capability represents a processing capacity metric for capacity planning of a production application cluster”. (Pg. 257, Para. 5, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics. These metrics include response time, average CPU utilization, and number of allocated instances as an indication about the cost” [calculating an average single-machine capability of each test machine]. Pg. 258, Para. 5, “The choice of scaling size of 26, the fourth case, is based on the Eq. (1) given that the arrival rate is 2400 Req/sec, where the number of instances is 31, since the already allocated instances are 5, and the utilization threshold is 80%” [when the adjusted workload pressure value reaches a maximum value triggering a rate limit threshold of an application cluster capacity of the simulated application cluster]. Pg. 256, “VM instances are clustered in elastic groups to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [by a processing device]. Pg. 259, “To obtain the optimal upper utilization threshold that could be used with the provisioning process when considering such a high increase in the load, one has to solve an optimization problem with two objectives. These two objectives are minimizing the usage of instances and minimizing the response time” [e.g., wherein the average single-machine capability represents a processing capacity metric for capacity planning of a production application cluster] Further see Sect. 1-III and V. The examiner had interpreted that conducting simulation experiments to evaluate the impact of varying the upper threshold of the CPU utilization on average CPU utilization for given arrival rates there the utilization threshold is reached by a monitoring system to obtain an optimal utilization threshold for use with the provisioning process by minimizing the usage of instances as calculating, by the processing device, an average single-machine capability of each test machine when the adjusted workload pressure value reaches a maximum value triggering a rate limit threshold an application cluster capacity of the simulated application cluster, wherein the average single-machine capability represents a processing capacity metric for capacity planning of a production application cluster.)
Al-Haidari teaches “wherein calculating the average single-machine capability comprises reducing, by the processing device, the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling”. (Pg. 257 Col. 1, “We have conducted several simulation experiments that mimic the cloud computing service characteristics to show and evaluate the impact of varying the upper threshold of the CPU utilization on the cloud service performance metrics. These metrics include response time, average CPU utilization, and number of allocated instances as an indication about the cost” [load capability of the simulated application cluster]. Pg. 256 Col. 1, “When a particular metric indicates a value above a given upper threshold, a policy is triggered to provision more resources so as to enhance its performance with respect to this metric. On the other hand, when a metric has a value below a given lower threshold, a policy is triggered to terminate some unneeded resources” [reducing the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling]. Pg. 256, “VM instances are clustered in elastic groups to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [auto scaling by the processing device]. Further see Sect. 1-3. The examiner has interpreted that automatically scaling VM resources by a monitoring system when the response time and average CPU utilization has a value below a given lower threshold to trigger a termination of unneeded resources as wherein calculating the average single-machine capability comprises reducing, by the processing device, the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling.)
Al-Haidari does not specifically teach “using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling”.
However, in the same field of endeavor namely optimizing resource utilization through simulating computer instances, Fernandez teaches “using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling”. (Pg. 197 Sect IV, “As a central component of our autoscaling system, the Scaler is responsible for triggering the scaling actions” [auto scaling]. Pg. 197 Sect IV, “According to this technique, the Scaler evaluates whether the current performance behavior of an application requires triggering any of the following scaling actions… Scale back: Resources are released if the loaded system state exceeds a lower threshold, and the Predictor confirms that such traffic changes will remain at least during the next monitoring window” [the application cluster capacity is reduced]. Pg. 198 Sect. IV, “The Ideal_Throughputinst factor gives an estimation of the optimized performance capacity of one VM instance when processing the current workload” [calculating the single-machine capability]. Pg. 198 Sect. IV, “The Profiler classifies the different instance types depending on its computing capacity. Using the profiling smoothed data of each instance type (refer to Lines 15-17), the Profiler computes a factor, named Ideal_Throughputinst, as the amount of clocks required to serve a specific amount of requests (clocks/requests) for one instance” [clocks per requests is derivative of query-per-second]. “In Equation 1, the %CPUusageinst represents the average of percentage of CPU usage (clocks) and Num_requestsinst the average of request rate (requests) consumed during the last hour” [Since the Ideal_Throughputinst is dependent on average CPU usage and average request rate, e.g., an average using an average query-per-second of each test machine as the average single-machine capability]. Pg. 199 Sect. IV, “we calculate the expected usage of CPU of each resource i (denoted by CPU_usage_expectedi ) using its current request rate (denoted by Num_reqs_serveri) and its optimized throughput (denoted by Ideal_Throughputinst). By doing so, we are able to include into the Workloadcomplex all the degradations that affect the ideal performance of the application” [e.g., in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling]. Further see Sect. IV. The examiner has interpreted that using an auto scaler to release resources when the loaded system state exceeds a lower threshold and computes the throughput of one instance using the average clocks and number of requests to calculate the expected usage of the CPU at its current request rate when degradation affect the ideal performance as using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling” as conceptually seen from the teaching of Fernandez, into that of Al-Haidari because this modification of using the average throughput of an instance to determine the system capacity under degrading conditions for the advantageous purpose of improving the operation cost and scaling of the virtual machine cluster (Fernandez, Pg. 197 Sect. IV). Further motivation to combine be that Al-Haidari and Fernandez are analogous art to the current claim are directed to optimizing resource utilization through simulating computer instances.
As per claim 29, Al-Haidari teaches “the performing overall workload pressure testing on each test machine comprising simulating, by the processing device, online traffic to each test machine”. (Pg. 257 Col. 2, “The input to the simulation is an aggregated traffic from different sources” [simulating online traffic]. Figure 1 shows the online traffic is distributed to each test machine. Further see Sect. III. The examiner has interpreted that simulating aggregated traffic from different sources to each test machine as the performing overall workload pressure testing on each test machine comprising simulating, by the processing device, online traffic to each test machine.)
Re Claim 30, it is a system claim, having similar limitations of claim 21. Thus, claim 30 is also rejected under the similar rationale as cited in the rejection of claim 21.
Furthermore, regarding claim 30, Al-Haidari teaches “A non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining”. (Pg. 256, “VM instances are clustered in elastic groups to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [a processing device (i.e. computer containing non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor)]. Further see Sect. I-III. The examiner has interpreted that using a monitoring system such as Amazon CloudWatch web service as a non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining steps.)
Re Claim 38, it is a system claim, having similar limitations of claim 29. Thus, claim 38 is also rejected under the similar rationale as cited in the rejection of claim 29.
Re Claim 39, it is a system claim, having similar limitations of claim 30. Thus, claim 39 is also rejected under the similar rationale as cited in the rejection of claim 30.
Furthermore, Al-Haidari also teaches “A device comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor”. (Pg. 256, “VM instances are clustered in elastic groups to which users associate triggers that will automatically scale VM resources based on metrics measured by a monitoring system such as Amazon CloudWatch web service” [a processing device (i.e. a device comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor)]. The examiner has interpreted that implementing a method through a monitoring system such as Amazon CloudWatch web service as a device comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor.)
Claims 22, 26-27, 31, and 35-36 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez as applied to claim 21, and further in view of Lorido-Botran, Tania, Jose Miguel-Alonso, and Jose A. Lozano “A review of auto-scaling techniques for elastic applications in cloud environments.” Journal of grid computing 12 (2014): 559-592 [herein “Lorido-Botran”].
As per claim 22, Al-Haidari nor Fernandez specifically teach “the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold”.
However, in the same field of endeavor namely optimizing resource utilization through simulating computer instances, Lorido-Botran teaches “the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold”. (Pg. 572 Col. 1, “Queuing theory makes reference to the mathematical study of waiting lines, or queues. The basic structure of a model is depicted in Fig. 1. Requests arrive to the system at a mean arrival rate λ, and are enqueued until they are processed. As the figure shows, one or more servers may be available in the model, that will attend requests at a mean service rate μ” [reducing the workload pressure value according to a preset step length]. Pg. 572 Col. 2, “System capacity or queue length. It refers to the maximum number of customers allowed in the system including those in service. When the system is fully occupied, further arrivals are rejected” [when the initial workload pressure value triggers the rate limit threshold]. Pg. 560 Col. 1, “It would be desirable to have a system that automatically adjusts the resources to the workload handled by the application. All this with minimum human intervention or, even better, without it. This would be an auto-scaling system, the focus of this survey” [by a processing device]. Further see Sect. 1 & 5. The examiner has interpreted that enqueueing requests until the requests can be serviced at the mean service rate through an auto-scaling system as the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “the adjusting the workload pressure value comprising reducing, by the processing device, the workload pressure value according to a preset step length when the initial workload pressure value triggers the rate limit threshold” as conceptually seen from the teaching of Lorido-Botran, into that of Al-Haidari and Fernandez because this modification of altering the amount of workload for the advantageous purpose of optimizing the capacity of the application cluster by balancing and distributing the requests through the virtual machines (Lorido-Botran, Pg. 572 Col. 1). Further motivation to combine be that Al-Haidari, Fernandez, and Lorido-Botran are analogous art to the current claim are directed to optimizing resource utilization through simulating computer instances.
As per claim 26, Al-Haidari nor Fernandez specifically teach “adjusting, by the processing device, an application cluster capacity according to a planned data-handling capability of the application cluster”.
However, Lorido-Botran teaches “adjusting, by the processing device, an application cluster capacity according to a planned data-handling capability of the application cluster”. (Pg. 563 Col. 1, “The analysis phase consists of processing the metrics gathered directly from the monitoring system, obtaining from them data about current system utilization, and optionally predictions of future needs. Some auto-scalers do not perform any kind of prediction, just respond to current system status: they are reactive. However, some others use sophisticated techniques to predict future demands in order to arrange resource provisioning with enough anticipation” [adjusting an application cluster capacity according to a planned data-handling capability of the application cluster]. Pg. 560 Col. 1, “It would be desirable to have a system that automatically adjusts the resources to the workload handled by the application. All this with minimum human intervention or, even better, without it. This would be an auto-scaling system, the focus of this survey” [by a processing device]. Further see Sect. 1 & 3. The examiner has interpreted that predicting the future demands in order to arrange resource provisioning with enough anticipation through an auto-scaling systems as adjusting, by the processing device, an application cluster capacity according to a planned data-handling capability of the application cluster.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to add “adjusting, by the processing device, an application cluster capacity according to a planned data-handling capability of the application cluster” as conceptually seen from the teaching of Lorido-Botran, into that of Al-Haidari and Fernandez because this modification of planning for anticipating the fluctuating amounts of data for the advantageous purpose of optimizing the capacity of the instances by minimizing the time response of the system through auto-scaling (Lorido-Botran, Pg. 563 Col. 1). Further motivation to combine be that Al-Haidari, Fernandez, and Lorido-Botran are analogous art to the current claim are directed to optimizing resource utilization through simulating computer instances.
As per claim 27, Al-Haidari and Fernandez do not specifically teach “the adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster”.
However, Lorido-Botran teaches “the adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster”. (Pg. 563 Col. 1, “The analysis phase consists of processing the metrics gathered directly from the monitoring system, obtaining from them data about current system utilization, and optionally predictions of future needs. Some auto-scalers do not perform any kind of prediction, just respond to current system status: they are reactive. However, some others use sophisticated techniques to predict future demands in order to arrange resource provisioning with enough anticipation” [adjusting an application cluster capacity according to a planned data-handling capability of the application cluster]. Pg. 575 Col. 1, “MPCs follow a proactive approach; the future behavior (output) of the system is predicted, based on the model and the current output” [according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster]. Pg. 560 Col. 1, “It would be desirable to have a system that automatically adjusts the resources to the workload handled by the application. All this with minimum human intervention or, even better, without it. This would be an auto-scaling system, the focus of this survey” [by a processing device]. Further see Sect. 1, 3, & 5. The examiner has interpreted that predicting the future demands in order to arrange resource provisioning with enough anticipation through an auto-scaling systems based on the model and future output as the adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to add “the adjusting the application cluster capacity according to a planned data-handling capability of the application cluster comprising adjusting, by the processing device, the application cluster capacity according to a ratio of the planned data-handling capability of the application cluster to a total workload pressure value of the application cluster” as conceptually seen from the teaching of Lorido-Botran, into that of Al-Haidari and Fernandez because this modification of modifying the cluster capacity based on the planned capability and current cluster capability for the advantageous purpose of optimizing the capacity of the instances by minimizing the time response of the system through auto-scaling (Lorido-Botran, Pg. 563 Col. 1). Further motivation to combine be that Al-Haidari, Fernandez, and Lorido-Botran are analogous art to the current claim are directed to optimizing resource utilization through simulating computer instances.
Re Claim 31, it is an articles of manufacture claim, having similar limitations of Claim 22. Thus, Claim 31 is also rejected under the similar rationale as cited in the rejection of Claim 22.
Re Claim 35, it is an articles of manufacture claim, having similar limitations of Claim 26. Thus, Claim 35 is also rejected under the similar rationale as cited in the rejection of Claim 26.
Re Claim 36, it is an articles of manufacture claim, having similar limitations of Claim 27. Thus, Claim 36 is also rejected under the similar rationale as cited in the rejection of Claim 27.
Claims 24, 28, 33, and 37 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez, as applied to claim 21, and further in view of Han, Rui, Li Guo, Moustafa M. Ghanem, and Yike Guo “Lightweight resource scaling for cloud applications” In 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid 2012), pp. 644-651. IEEE, 2012 [herein “Han”].
As per claim 24, Al-Haidari and Fernandez does not specifically teach “the reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio”.
However, in the same field of endeavor namely simulating computer utilization, Han teaches “the reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio”. (Pg. 649 Col. 1, “The experimental evaluation is designed to illustrate the effectiveness of our approach in enabling fine-grained scaling up and down of applications” [gradually reducing the application cluster capacity]. “The LSD algorithm then conducts the resource-level scaling down. This scaling downs elects a resource r with the largest xr(si,r) (definition 1) and removes one unit of r from sj’s VM. The removal implies the resource with the largest available amount and the highest running cost is removed” [according to a preset capacity reduction ratio]. Pg. 649 Col.1, “In the experiment, the iSSe was implemented as a full working system and was tested in one data center running the IC-Cloud platform” [by the processing device]. Further see Sect. 6. The examiner has interpreted that fine-grained scaling down of applications to remove one resource scaled from the instance as through an IC-Cloud platform as reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to add “the reducing the application cluster capacity comprising gradually reducing, by the processing device, the application cluster capacity according to a preset capacity reduction ratio” as conceptually seen from the teaching of Han, into that of Al-Haidari because this modification of gradually reducing the cluster capacity for the advantageous purpose of saving computational resources and cost by removing imbalances in the system (Han, Pg. 645 Col. 1). Further motivation to combine be that Al-Haidari and Han are analogous art to the current claim are directed to simulating computer utilization.
As per claim 28, Al-Haidari and Fernandez do not specifically teach “initializing the simulated application cluster by: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters”, “initializing, by the processing device, the simulated application cluster with at least two test machines if the set of application clusters comprises a single application cluster”, and “initializing, by the processing device, the simulated application cluster with a single test machine if the set of application clusters comprises at least two application clusters”.
However, Han teaches “initializing the simulated application cluster by: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters”. (Pg. 645 Col.1, “overall utilisation of resources also varies across different PMs used by the application (Figure 2(c))” [the set of application clusters]. Pg. 649 Col.1, “The experimental evaluation is designed to illustrate the effectiveness of our approach in enabling fine-grained scaling up and down of applications” [identifying an application cluster to simulate]. Pg. 649 Col.1, “In the experiment, the iSSe was implemented as a full working system and was tested in one data center running the IC-Cloud platform” [by the processing device]. Further see Sect. 2 and 6. The examiner has interpreted that designing an experimental evaluation to illustrate the effectiveness of enabling fine-grained scaling up and down of applications in different PMs used by the application through an IC-Cloud platform as initializing the simulated application cluster by: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters.)
Han also teaches “initializing, by the processing device, the simulated application cluster with at least two test machines if the set of application clusters comprises a single application cluster”. (Pg. 645 Col.2, “Self-healing scaling is applicable in cases when two servers of an application are deployed on one PM,” [initializing the simulated application cluster at least two test machines if the set of application clusters comprises a single application cluster]. Pg. 649 Col.1, “In the experiment, the iSSe was implemented as a full working system and was tested in one data center running the IC-Cloud platform” [by the processing device]. Further see Sect. 2 and 6. The examiner has interpreted that deploying two servers of an application on one PM and running an experiment on the IC-Cloud platform as initializing, by the processing device, the simulated application cluster with at least two test machines if the set of application clusters comprises a single application cluster.)
Han also teaches “initializing, by the processing device, the simulated application cluster with a single test machine if the set of application clusters comprises at least two application clusters”. (Pg. 645 Col.1, “overall utilisation of resources also varies across different PMs used by the application (Figure 2(c))” [initializing the simulated application cluster if the set of application clusters comprises at least two application clusters]. Figure 2(c) shows that each cluster contains a single test machine. Pg. 649 Col.1, “In the experiment, the iSSe was implemented as a full working system and was tested in one data center running the IC-Cloud platform” [by the processing device]. Further see Sect. 2 and 6. The examiner has interpreted that implementing different PMs where each PM contains a single machine as initializing, by the processing device, the simulated application cluster with a single test machine if the set of application clusters comprises at least two application clusters.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to add “initializing the simulated application cluster by: identifying, by the processing device, an application cluster to simulate, the application cluster selected from a set of application clusters”, “initializing, by the processing device, the simulated application cluster with at least two test machines if the set of application clusters comprises a single application cluster”, and “initializing, by the processing device, the simulated application cluster with a single test machine if the set of application clusters comprises at least two application clusters” as conceptually seen from the teaching of Han, into that of Al-Haidari and Fernandez because this modification of simulating for different cluster scenarios for the advantageous purpose of saving computational resources and cost (Han, Pg. 645 Col. 1). Further motivation to combine be that Al-Haidari, Fernandez, and Han are analogous art to the current claim are directed to simulating computer utilization.
Re Claim 33, it is an articles of manufacture claim, having similar limitations of Claim 24. Thus, Claim 33 is also rejected under the similar rationale as cited in the rejection of Claim 24.
Re Claim 37, it is an articles of manufacture claim, having similar limitations of Claim 28. Thus, Claim 37 is also rejected under the similar rationale as cited in the rejection of Claim 28.
Claims 25 and 34 are rejected under 35 U.S.C. § 103 as being unpatentable over Al-Haidari and Fernandez as applied to claim 21, and further in view of US 2016/0323377 A1 Einkauf et al. [herein “Einkauf”].
As per claim 25, Al-Haidari and Fernandez does not specifically teach “calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained”.
However, in the same field of endeavor namely simulating computer utilization, Einkauf teaches “calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained”. (Para. 42, “the systems described herein may provide a framework in which programs may be executed on MapReduce clusters on behalf of clients” [set of application clusters]. Para. 60 “the trigger data may include performance or behavior metrics, storage metrics (e.g., consumption of storage, remaining capacity)” [capacity of all the application clusters are obtained]. Para. 34, “Each policy may define an expression (e.g., an auto-scaling trigger condition) to be evaluated when executing a distributed application on MapReduce cluster 120, may specify a scaling action to take when the expression evaluates true (e.g., add or remove capacity), may specify an amount or percentage by which to increase or decrease capacity, and/or may identify the cluster (and/or instance group(s) thereof), to which the policy applies” [removing capacity from a specific application cluster based on storage metrics (i.e. calculating a capacity percentage of a single application cluster)]. Para. 193, “a computing environment that implements a portion or all of the methods and apparatus described herein may include a general-purpose computer system” [by the processing device]. Further see Para. 34, 42, 60, and 193. The examiner has interpreted that adding or removing capacity by a specific percentage from a particular cluster based the storage metrics of the clusters through the use of a general purpose computer system as calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to add “calculating, by the processing device, a capacity percentage of a single application cluster within a set of application clusters after capacities of all the application clusters are obtained” as conceptually seen from the teaching of Einkauf, into that of Al-Haidari and Fernandez because this modification of determining the size of the individual clusters for the advantageous purpose of optimizing the capacity of the system based on the performance of the clusters (Einkauf, Para. 30). Further motivation to combine be that Al-Haidari, Fernandez, and Einkauf are analogous art to the current claim are directed to simulating computer utilization.
Re Claim 34, it is an articles of manufacture claim, having similar limitations of Claim 25. Thus, Claim 34 is also rejected under the similar rationale as cited in the rejection of Claim 25.
Response to Arguments
Applicant’s arguments, see Pg. 9-10, filed June 24, 2026, with respect to the rejection(s) of claims 30-31 and 33-39 under 35 U.S.C. § 101 have been fully considered and are persuasive with regards to the claims integrating the claimed invention into a practical application when viewed as a whole. Therefore, the rejection has been withdrawn.
Applicant's arguments filed June 24, 2026 have been fully considered but they are not persuasive for the following reasons:
Applicant argues that the amendment to the claims, e.g., “wherein calculating the average single-machine capability comprises reducing, by the processing device, the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling” and “and using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling” renders the rejection of the claims on the ground of nonstatutory double patenting moot (See Applicant’s response, Pg. 9).
MPEP § 2143.03 that “All words in a claim must be considered in judging the patentability of that claim against the prior art” and “Examiners must consider all claim limitations when determining patentability of an invention over the prior art.”
As provided in the rejection above, U.S. Patent No. 11,231,947 B2 teaches “wherein calculating the average single-machine capability comprises reducing, by the processing device, the application cluster capacity in response to a load capability of the simulated application cluster reaching a capacity reduction threshold of auto scaling” (Claim 3, the calculating an average single-machine capability of each test machine comprising: reducing, by the processing device, the application cluster capacity when a load capability of the application cluster reaches a capacity reduction threshold of auto scaling.) and also teaches “and using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling” (Claim 3, the calculating an average single-machine capability of each test machine comprising: using, by the processing device, an average query-per second of each of the testing machines as the average single-machine capability of the testing machines when the application cluster capacity is reduced and the load capability of the application cluster reaches a capacity expansion threshold of auto scaling.). The amended claims are not patentably distinct.
Therefore, all of the limitations of the amended claims 21 are disclosed in U.S. Patent No. 11,231,947 B2 and Al-Haidari. Therefore, applicant’s arguments are not persuasive and the rejection of claim 21 by U.S. Patent No. 11,231,947 B2 and Al-Haidari on the grounds of nonstatutory double patenting is maintained.
Applicant argues that the combination of references fail to teach amended claim 21 since they fail to teach “the system's average query-per-second is then captured in response to the resulting load crossing the auto-scaling expansion threshold. The expansion threshold crossing functions as the measurement event by which an accurate per-machine capability is obtained”, “a deliberate capacity reduction to drive the cluster across the expansion threshold and then captures average query-per-second in response to that crossing”, “it is not an average query-per-second captured in response to a reducing operation causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling”, and “the opposite of the claimed methodology, in which the reducing step is performed specifically to drive load back up across the expansion threshold” [See Applicant’s response, Pg. 10-13 (emphasis added)].
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the claim. Claim 21 recites “using an average query-per-second of each test machine as the average single-machine capability in response to the reducing causing the load capability of the simulated application cluster to reach a capacity expansion threshold of auto scaling”. The claim does not require the capturing of the average query-per-second (QPS) when the reducing is activated but only requires the mere use of the average QPS as the average single-machine capability when the capacity is reduced. Furthermore, the claim also does not require that the expansion threshold to be crossed but only requires that the threshold to be reached. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
To further address this limitation, the examiner has not relied upon Al-Haidari for teaching this limitation as argued but has relied upon Fernandez to teach this limitation. Fernandez teaches this limitation as using an auto scaler to release resources when the loaded system state exceeds a lower threshold and computes the throughput of one instance using the average clocks and number of requests to calculate the expected usage of the CPU at its current request rate when degradation affect the ideal performance. While the applicant has argued that the Ideal_Throughputinst is an offline and historical value, this does not teach away from the claimed limitation. First, claim 21 recites “a simulated application cluster isolated from production traffic, the simulated application cluster comprising at least one test machine configured to process simulated online traffic”. This is offline testing since it is isolated from production traffic to simulate online traffic. Second, as mentioned above, the claim does not require that the average QPS be captured in any sense nor as in the sense of measuring as argued; the claim only requires the use of the average QPS as the average single-machine capability when the capacity is reduced. Therefore, under the broadest reasonable interpretable, this is a historical value. Although, even in the scenario where the claims were to recite a measured average QPS, Fernandez teaches this as the historical value of Ideal_Throughputinst is only used if certain criteria is met (see Ln. 20 of Algorithm 1 on Pg. 198) otherwise the actual value is determined using the collected data as mapped above in the rejection (also see Ln. 17 of Algorithm 1).
Therefore, the applicant’s arguments are not persuasive and the rejection of claim 21 as over Al-Haidari in view of Fernandez under 35 U.S.C. § 103 is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Al-Haidari, Fahd, M. Sqalli, and Khaled Salah. "Evaluation of the impact of EDoS attacks against cloud computing services." Arabian Journal for Science and Engineering 40, no. 3 (2015): 773-785 et al. teaches using the average throughput when experiencing a higher amount of utilization authorized for an instance.
Renna, Francesco, Joseph Doyle, Vasileios Giotsas, and Yiannis Andreopoulos. "Media query processing for the Internet-of-Things: Coupling of device energy consumption and cloud infrastructure billing." IEEE Transactions on Multimedia 18, no. 12 (2016): 2537-2552 teaches using the average query data and average traffic volume to determining the average product of an application cluster.
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.
Examiner’s Note: The examiner has cited particular columns and line numbers in the reference that applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, to fully consider the references in their 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. In the case of amending the claimed invention, the applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for the proper interpretation and also to verify and ascertain the metes and bound of the claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Simeon P Drapeau whose telephone number is (571)-272-1173. The examiner can normally be reached Monday - Friday, 8 a.m. - 5 p.m. ET.
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, Ryan Pitaro can be reached on (571) 272-4071. 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.
/SIMEON P DRAPEAU/Examiner, Art Unit 2188
/RYAN F PITARO/Supervisory Patent Examiner, Art Unit 2188
Prosecution Insights