DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Response to Amendment
This Non-Final rejection is in response to Applicant’s arguments/remarks submitted on 12/22/2025. Independent claims 1, 8, and 23 have been amended, therefore claims 1-6, 8-14, and 21-27 remain pending in the application and are being considered on the merits.
Response to Arguments
Applicant’s arguments filed on 12/22/2025 have been fully considered with the following results:
Regarding the rejection under 35 U.S.C. 103, Applicant has amended independent claims 1, 8, and 23 with subject matter that is argued to not be taught/suggested in the prior art of record. Applicant argues that neither Radhakrishnan nor Wagner teach or suggest determining a difference between needed pre-launch sessions at a first time and a second time, and based on the determination deleting pre-launch sessions that are not needed. Applicant further states that Wagner merely discloses “garbage collecting” of virtual machine instances and only deletes virtual machine instances after they are used, as well as stating that Wagner does not contemplate deleting virtual machines that will not be needed at a future time.
The Examiner respectfully disagrees. The Examiner contends that Wagner teaches a predicted number of instances based on a pre-trigger notification, as well as using historical information as a prior need/usage of instances (see Wagner Col. 4 line 55 – Col. 5 Line 36 and Col. 7 Lines 10-41). Wagner then uses the predicted number of instances as well as what was being used at a prior time in a determination for initialization/de-initialization of VM instances. The Examiner would also like to draw attention to Figure 4 in which Wagner has a loop of predicting, modifying the number of VMs, then repeating and modifying again. The Examiner argues that, due to Wagner teaching at least multiple predictions through a loop shown in Fig. 4, the only way de-initialization would occur is through a prediction at a second point in time being less than a prediction at a first point in time. Therefore, it would be obvious to one of ordinary skill in the art that the Wagner reference teaches and/or renders obvious determining a difference between needed pre-launch sessions at various times and deleting the sessions that are not needed. As such, the Examiner concludes that the rejection under 35 U.S.C. 103 will be maintained. For further details please refer to the 103 section below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 8-14, and 23-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Radhakrishnan et al. (US 20140365626) in view of Wagner et al. (US 10013267).
Regarding claims 1 and 23, Radhakrishnan teaches a method/system comprising: determining a number of available virtual machine instances (determination done through auto scaling component which monitors available compute resources which can be virtual machine instances par. 0018 and 0032), wherein each available virtual machine instance contains a number of available pre-launch sessions (based on expected demand, instances are pre-launched par. 0054 – 0056); predicting a number of pre-launch sessions needed at a first time (pre-warming component estimating the needed computing capacity of instances par. 0067); based on the number of pre-launch sessions needed at the first time exceeding the number of available pre-launch sessions, initializing additional pre-launch sessions (pre-warming component setting expected target amount of pre-warmed instances, and changing demand based on various factors including resource availability and constraints, applying various statistical factors to change the expected demand par. 0068 – 0071); and hibernating the additional pre-launch sessions until the first time (keeping instance idled until request received par. 0076 – 0078).
Radhakrishnan does not explicitly teach the prediction of pre-launch sessions leading to deleting a difference in needed sessions.
However, Wagner teaches: Predicting a number of pre-launch sessions needed at a second time (predicting pre-initialized virtual machine instances to be required based on a pre-trigger notification Col. 4 Line 55 – Col. 5 Line 36); determining a difference between the number of pre-launch sessions needed at the first time and the number of pre-launch sessions needed at the second time, wherein if the number of pre-launch sessions needed at the first time exceeds the number of pre-launch sessions needed at the second time (predicted need based on pre-trigger notifications are used to determine how VM instances are de-initialized through a loop of predictions/modifications Col. 4 Line 55 – Col. 5 Line 36, Col. 7 Lines 10-41, and Fig. 4), the difference indicates a number of pre-launch sessions that are not needed at the second time and are to be deleted (determining, from historical information/prior predictions ‘x’ and predicted demand ‘y’ whether x+y virtual machine instances are maintained, the on-demand code execution environment may then determine that instances may need de-initialized or shut down Col. 4 Line 55 – Col. 5 Line 36); and based on the difference, deleting the number of pre-launch sessions that are not needed at the second time (based on determining that instances may need de-initialized, performing garbage collection on the instances Col. 4 Line 55 – Col. 5 Line 36 see also Col. 28 Line 13 – Col. 29 Line 5 wherein the initial pool is historical need at a first time and the future execution is the predicted need at a second time and the goal is to maintain adequate levels to service predicted future executions by de-initialization or otherwise removal).
Both Radhakrishnan and Wagner are in the same field of endeavor that relates to pre-warming/pre-configuring compute instances.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Radhakrishnan with the teachings of Wagner since Wagner provides and enhancement to the methods/teachings of Radhakrishnan by allowing virtual machine instances to be deleted based on whether or not they are unnecessary for task execution, thereby providing “on-demand code execution environments (Wagner Col. 4 Line 55 – Col. 5 Line 36).
Modification would allow for the pre-warmed sessions of Radhakrishnan to be modified based on need, allowing for maintaining adequate service levels for predicted future need.
Regarding claims 2 and 24, Radhakrishnan teaches: wherein the number of pre-launch sessions needed at the first time is based on historical data, wherein the historical data indicates a number of pre-launch sessions that were previously used at the first time (determination of expected available computing resources applied using historical uses of resources par. 0065 and 0071).
Regarding claims 3 and 25, Radhakrishnan teaches: generating additional virtual machine instances, wherein the additional virtual machine instances contain the additional pre-launch sessions (generation/configuration of various computing resources to launch the instances par. 0044 – 0046 with the said instances containing the needed additional pre-warmed resources par. 0067); and hibernating the additional virtual machine instances until the first time (keeping instance idled until request received par. 0076 – 0078).
Regarding claims 4 and 26, Radhakrishnan teaches: wherein the hibernating the additional virtual machine instances until the first time comprises: moving the additional virtual machine instances from a running state to a stopped state (state of instance being stopped par. 0061); and transferring processes from an additional virtual machine instance to storage associated with the additional virtual machine instance (transferring control of the instance to either user or cache par. 0014).
Regarding claims 5 and 27, Radhakrishnan teaches: resuming, at the first time, the additional virtual machine instances and the additional pre-launch sessions (resuming instance from generated snapshot par. 0061).
Regarding claim 6, Radhakrishnan teaches: prior to deleting the available virtual machine instance (removal of pre-warmed instance par. 0059), hibernating the available virtual machine instance, wherein the hibernating the available virtual machine instance comprises: predicting a number of pre-launch sessions needed at a third time (pre-warming component determining resource demand over a period of time par. 0065); determining a difference between the number of pre-launch sessions needed at the third time and the number of pre-launch sessions needed at the first time (by applying mathematical model/analysis to the considered dataset par. 0066), wherein the difference between the number of pre-launch sessions needed at the third time and the number or pre-launch sessions needed at the first time indicates a number of pre-launch sessions to be hibernated (pre-warming/idling based upon estimated need depending on if more or less is needed par. 0065 – 0066 and 0076 – 0078); and hibernating the number of pre-launch sessions to be hibernated (idling sessions based on need par. 0076 – 0078).
The Examiner would like to note that although it is not explicitly stated that there is a third time, Radhakrishnan teaches estimating demand over various timeframes, as such it would be obvious to one of ordinary skill in the art that any of these time frames could be considered a “third” time.
Regarding claim 8, Radhakrishnan teaches a method comprising: receiving, by a controller (of various controllers par. 0108), a number of pre-launch sessions needed at a first time (pre-warming component estimating the needed computing capacity of instances par. 0067); comparing, by the controller, the number of pre-launch sessions needed at the first time to a number of pre-launch sessions needed at a second time (by applying mathematical model/analysis to the considered dataset par. 0066); determining, by the controller, that the number of pre-launch sessions needed at the second time exceeds the number of pre-launch sessions needed at the first time (based upon analysis of mathematical model/estimations par. 0066); and hibernating, by the controller, a portion of the number of pre-launch sessions needed at the second time (idling sessions based on need par. 0076 – 0078).
Radhakrishnan does not explicitly teach the prediction of pre-launch sessions leading to deleting a difference in needed sessions.
However, Wagner teaches: Predicting a number of pre-launch sessions needed at a third time (predicting pre-initialized virtual machine instances to be required based on a pre-trigger notification Col. 4 Line 55 – Col. 5 Line 36); determining a difference between the number of pre-launch sessions needed at the second time and the number of pre-launch sessions needed at the third time, wherein if the number of pre-launch sessions needed at the second time exceeds the number of pre-launch sessions needed at the third time (predicted need based on pre-trigger notifications are used to determine how VM instances are de-initialized through a loop of predictions/modifications Col. 4 Line 55 – Col. 5 Line 36, Col. 7 Lines 10-41, and Fig. 4), the difference indicates a number of pre-launch sessions that are not needed at the third time and are to be deleted (determining, from historical information/prior predictions ‘x’ and predicted demand ‘y’ whether x+y virtual machine instances are maintained, the on-demand code execution environment may then determine that instances may need de-initialized or shut down Col. 4 Line 55 – Col. 5 Line 36); and based on the difference, deleting the number of pre-launch sessions that are not needed at the third time (based on determining that instances may need de-initialized, performing garbage collection on the instances Col. 4 Line 55 – Col. 5 Line 36).
Both Radhakrishnan and Wagner are in the same field of endeavor that relates to pre-warming/pre-configuring compute instances.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Radhakrishnan with the teachings of Wagner since Wagner provides and enhancement to the methods/teachings of Radhakrishnan by allowing virtual machine instances to be deleted based on whether or not they are unnecessary for task execution, thereby providing “on-demand code execution environments (Wagner Col. 4 Line 55 – Col. 5 Line 36).
Modification would allow for the pre-warmed sessions of Radhakrishnan to be modified based on need, allowing for maintaining adequate service levels for predicted future need.
Regarding claim 9, Radhakrishnan teaches: determining, by the controller, the number of pre-launch sessions needed at the first time based on historical data, wherein the historical data indicates a number of pre-launch sessions that were previously used at the first time (determination of expected available computing resources applied using historical uses of resources par. 0065 and 0071).
Regarding claim 10, Radhakrishnan teaches: determining, by the controller, the number of pre-launch sessions needed at the second time based on historical data, wherein the historical data indicates a number of pre-launch sessions that were previously used at the second time (determination of expected available computing resources applied using historical uses of resources par. 0065 and 0071).
Regarding claim 11, Radhakrishnan teaches: wherein the portion of the number of pre-launch sessions needed at the second time comprises a difference between the number of pre-launch sessions needed at the second time and the number of pre-launch sessions needed at the first time (by applying mathematical model/analysis to the considered dataset par. 0066 and based upon estimated need depending on if more or less is needed par. 0076 – 0078).
Regarding claim 12, Radhakrishnan teaches: generating, by the controller, virtual machine instances, wherein the virtual machine instances contain pre-launch sessions needed at the second time (generation/configuration of various computing resources to launch the instances par. 0044 – 0046 with the said instances containing the needed additional pre-warmed resources par. 0067).
Regarding claim 13, Radhakrishnan teaches: wherein the hibernating comprises: moving, by the controller, the virtual machine instances from a running state to a stopped state (state of instance being stopped par. 0061); and transferring, by the controller, processes from a virtual machine instance to storage associated with the virtual machine instance (transferring control of the instance to either user or cache par. 0014).
Regarding claim 14, Radhakrishnan teaches: resuming, by the controller and at the second time, the portion of the number of pre-launch sessions needed at the second time (resuming instance from generated snapshot par. 0061).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Radhakrishnan in view of Wagner and further in view of Beaty et al. (US 20080295096).
Regarding claim 21, Beaty teaches: wherein predicting the number of pre-launch sessions needed at the first time comprises applying a time series forecasting model (forecasting of demand in terms of a required number of virtual machines is done through dynamic management of resources in a virtualized server environment based on time-series of resource utilization and/or properties of the infrastructure par. 0077 – 0088 and 0030 - 0031).
Beaty and the previous combination are in the same field of endeavor that includes prediction/forecasting virtual machine demand.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Radhakrishnan and Wagner with the teachings of Beaty since the time-series forecasting of Beaty allows for computer systems to benefit from dynamic management of resources relating to performance, power management, and time-series of resource utilization and/or properties of the virtualization infrastructure (Beaty: par. 0088).
Modification would allow for the need predictions to be made through a time-series of resource utilization by dynamic management of resources in a virtualized server environment.
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Radhakrishnan in view of Wagner and further in view of Guo et al. (US 20220405134).
Regarding claim 22, Guo teaches: wherein predicting a number of pre-launch sessions needed at a first time comprises: identifying that historical data for a date associated with the first time is unavailable (cold-start module being unable to use historical time series data for new applications for predicting future workload par. 0044), wherein the historical data indicates one or more of: a first number of pre-launched sessions that were previously predicted for the date, or a second number of pre-launched sessions that were previously used on the date (historical data for similar applications for a same time series par. 0044 – 0048); and based on identifying that the historical data for the date is unavailable, predicting the number of pre-launch sessions needed at the first time based on historical data associated with a second date (performing the prediction/forecasting of need by using historical data of applications that have similar characteristics to the application that needs forecasting par. 0044 – 0052).
Guo and the previous combination are in the same field of endeavor that includes using historical data to predict future workloads through forecasting application need.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Radhakrishnan and Wagner with the teachings of Guo since using other historical data similar to the application, or relating in time series to the application whose historical data is unavailable, allows for new applications without historical data to still be used in a forecasting/prediction process which enables more accurate forecasts than existing alternatives (Guo: par. 0044 – 0046).
Modification would allow for the methods of the previous combination to work for instances in which there is no historical data to use for predictions, instead relying on forecasting/prediction through time series.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Chakrabarti et al. (US 20180183578) which describes predictive auto-scaling, based on history or trends in usage, that more, less, or the same amount of resources should be used in the upcoming future as well as dynamic scaling up/down based on events.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 AM - 4:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pierre Vital can be reached at 571-272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.S.M./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
