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 .
This office action is in response to applicant’s amendment filed on 02/18/2026.
Claims 1-7 and 9-21 are pending and examined.
Claim 8 is cancelled.
Response to Arguments
Applicant's arguments filed 02/18/2026 with respect to the claim objections for claims 5, 13, and 19 have been fully considered and are persuasive. The claim objections for claims 5, 13, and 19 have been withdrawn.
Applicant's arguments filed 02/18/2026 with respect to 35 U.S.C. 101 have been fully considered but they are not persuasive. Applicant argued that “is impossible for the human mind to power on or power off virtual host machines.” Examiner respectfully disagrees, see 35 U.S.C. 101 rejections below for a detailed analysis. Examiner interprets the limitation of “dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities” as an additional element as “apply it” that is mere instructions to apply an exception. Therefore, an argument which seems to direct to the limitation being a mental process is moot as the limitation is not being interpreted as a mental process. Examiner would like to clarify that the “determining…” step of claim 1 is interpreted as a mental process, where a human could mentally determine capacities needed to satisfy the probability at different points in time by performing calculations on a time derivative of user login data within the historical data. Therefore, the 35 U.S.C. 101 rejections for claims 1-7 and 9-21 are maintained.
Applicant's arguments filed 02/18/2026 with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive. Applicant argued that “Neither the Zhu nor Balle references, alone or in combination, disclose or suggest using a first derivative of user login data to determine needed computing capacities, as required by the claims.” Examiner respectfully disagrees, see 35 U.S.C. 103 rejections below for a detailed analysis. Examiner interprets Zhu’s spike detection mechanism using auto-scale settings referring to a number of VDAs to pre-launch for a future time frame, based on a previous historical time frame indicating a certain number of login requests, as determining capacities needed to satisfy the probability at different points in time based on a time derivative of user login data within the historical data. Applicant additionally argued that Balle’s “percentages are measurements of a running system, not a configuration value that must be met by the system as required by the claims.” Examiner would like to clarify that the probabilities discussed in Balle are not equated to the configuration value, but rather, the threshold value that the probabilities are compared to would be equated to the configuration value. For example, the probability of the overload occurring from assigned workloads correlates to a probability that there will be available capacity when new computing sessions are initiated. The predefined threshold used to compare the probability of resource overload being used as a minimum requirement for a particular workload to be processed, where the threshold can be a percentage, correlates to a configuration value being a percentage value that represents a desired, target probability that there will be available capacity for newly initiated computing sessions. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with Balle because adjustments to workload assignments based on predicted overloads occurring can improve resource utilization and avoid overloads of any components of managed nodes. Orchestrator servers can additionally determine a temporal alignment of resource utilization phases of workloads to align resource utilization peaks and troughs.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 and 9-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claims 1, 9, and 17 recite:
receiving, by a computing device, historical data for an organization having a plurality of virtual host machines that can be selectively powered on to provide capacity for hosting computing sessions;
receiving, by a computing device, a configuration value of the organization indicating a probability that there will be available capacity when new computing sessions are initiated;
determining, by the computing device, capacities needed to satisfy the probability at different points in time based on a time derivative of user login data within the historical data; and
dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 1 is a process.
Claim 9 is a machine.
Claim 17 is a manufacture.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘determining’ limitation in #3 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining capacities needed to satisfy the probability based on historical data, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #1 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘receiving’ limitation in #2 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘adjusting’ limitation in #4 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adjusting” in the context of this claim encompasses merely dynamically adjusting the capacity of available computing sessions according to the determined capacities. See MPEP 2106.05(f).
Additionally, one or more of the claims recite the following additional elements:
One or more processors (Claims 9 and 17)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than components comprising mere instructions to apply the exception. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract ideas(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Claims 6 and 14 merely further describe the computing sessions of Claims 1 and 9 respectively. The claims do not include additional elements that integrate into practical application or are sufficient to amount to significantly more than the judicial exception.
Therefore, Claims 1, 6, 9, 14, and 17 are directed to (an) abstract idea(s) without significantly more.
Claims 2, 10, and 18 recite:
receiving data about numbers of logons that occurred at the different points in time; and
receiving data about amounts of time required to power on one or more of the host machines at the different points in time.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 2 is a process.
Claim 10 is a machine.
Claim 18 is a manufacture.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #5 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘receiving’ limitation in #6 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Claims 3 and 11 merely further describe the different points in time of Claims 2 and 9 respectively. The claims do not include additional elements that integrate into practical application or are sufficient to amount to significantly more than the judicial exception.
Therefore, Claims 2-3, 10-11, and 18 are directed to (an) abstract idea(s) without significantly more.
Claims 4 and 12 recite:
wherein the receiving of the historical data includes
receiving historical data associated with multiple 24-hour periods.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 4 is a process.
Claim 12 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #7 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 4 and 12 are directed to (an) abstract idea(s) without significantly more.
Claims 5, 13, and 19 recite:
wherein the auto-scaling of the host machines at the one or more times includes:
determining a current time-of-day;
determining, from the determined capacities, a target capacity needed to satisfy the probability at the current time-of-day; and
powering on at least one of the plurality of host machines to achieve the target capacity.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 5 is a process.
Claim 13 is a machine.
Claim 19 is a manufacture.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘determining’ limitation in #8 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining a current time of day, including comparison or judgement.
The ‘determining’ limitation in #9 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining a target capacity needed to satisfy the probability, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘powering on’ limitation in #10 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “powering on” in the context of this claim encompasses merely powering on host machines to achieve the target capacity. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 5, 13, and 19 are directed to (an) abstract idea(s) without significantly more.
Claims 7 and 15 recite:
wherein the auto-scaling of the host machines at the one or more times includes:
periodically auto-scaling the host machines at one or more times according to the determined capacities.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 7 is a process.
Claim 15 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘auto-scaling’ limitation in #11 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “auto-scaling” in the context of this claim encompasses merely periodically auto-scaling host machines according to the determined capacities. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 7 and 15 are directed to (an) abstract idea(s) without significantly more.
Claims 16 and 20 recite:
wherein the determining of the capacities needed to satisfy the probability at the different points in time includes:
determining a current day-of-week,
selecting, from the historical data, data associated with the current day-of-week, and
determining the capacities needed to satisfy the probability at the different points in time based on the selected data.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 16 is a machine.
Claim 20 is a manufacture.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘determining’ limitation in #12 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining a current day of the week, including comparison or judgement.
The ‘selecting’ limitation in #13 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “selecting” in the context of this claim encompasses a person analyzing, evaluating, or determining data associated with the current day of week, including comparison or judgement.
The ‘determining’ limitation in #14 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining capacities needed to satisfy the probability, including comparison or judgement.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 16 and 20 are directed to (an) abstract idea(s) without significantly more.
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.
Claim(s) 1-7 and 9-21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (U.S. Patent No. US 20210096927 A1), hereinafter “Zhu” in view of Balle et al. (U.S. Patent No. US 20180024860 A1), hereinafter “Balle” and Singh et al. (U.S. Patent No. US 20230007092 A1), hereinafter “Singh.”
With regards to Claim 1, Zhu teaches:
A method comprising:
receiving, by a computing device, historical data for an organization having a plurality of virtual host machines that can be selectively powered on to provide capacity for hosting computing sessions (Paragraphs 54-55, 80, 82, and 85, “In embodiments, the computing environment 160 may provide client 162 with one or more resources provided by a network environment. The computing environment 162 may include one or more clients 162a-162n, in communication with a cloud 168 over one or more networks 164… The users or clients 162 can correspond to a single organization or multiple organizations… VDA can refer to the agent and the physical or virtual machine on which it is installed... The server 202 can include an auto-scaler 206 designed, constructed and operational to facilitate auto-scaling of virtual delivery agent services. The auto-scaler 206 can analyze historical data, filter the historical data, generate a fitting curve based on the filtered historical data, determine a usage metric and a safety buffer, and determine a number of VDAs to pre-launch beforehand for a time interval. For example, the auto-scaler 206 can include a consumption analyzer 208 designed, configured and operational to identify data indicating consumption of a pool of active virtual delivery agents over a plurality of previous time frames. The data can include or refer to historical data. The data, or historical data, can be stored in data repository 224 as consumption data 226… The consumption analyzer 208 can monitor session requests and detect information associated with usage of the VDAs for storage in the data repository 224 as consumption data 226. The server 202 can otherwise obtain consumption data 226 and store the consumption data 226 in data repository 224. The server 202 can access one or more remote servers or databases to obtain consumption data 226.” The multiple clients of the computing environment each corresponding to a single or multiple organizations correlates to an organization. The consumption analyzer monitoring session requests and consumption data, which includes historical consumption data, correlates to receiving historical data for an organization. The auto-scaler facilitating auto-scaling of virtual delivery agent services, which include physical or virtual machines, for clients through the consumption analyzer correlates to an organization having a plurality of virtual host machines that can be selectively powered on to provide capacity for hosting computing sessions);
determining, by the computing device, capacities needed to satisfy the probability at different points in time based on a time derivative of user login data within the historical data (Paragraphs 71 and 111, “For example, the system can execute a spike detection mechanism at 5 minute checkpoints within a 30 minute predetermined pre-launch time interval of 30 minutes. At the beginning of a 30 minute time interval, the system can be configured to prelaunch E sessions (e.g., based on the estimated safety line F.sub.t for the time frame). After the first 5 minutes of the 30 minute time interval, the system can initiate a first checkpoint. At the first checkpoint, the system can determine the number of session requests that were received in the first five minutes as Rs. Receipt of a session request can refer to or include receiving a request to initiate or establish a session that uses a VDA. Receipt of a session request for the purposes of the checkpoint can refer to or include both receiving a request to initiate or establish a session that uses a VDA, and also successfully establishing the session using the VDA… In this case, the system can determine that if this trends continues, the available VDAs in the pool of VDAs, which is configured to prelaunch E sessions, will be consumed prior to completion of the 30 minute time interval. Accordingly, the system can determine to prepare an additional sessions at this point. The number of additional sessions to prepare, a, can be set based on the safety buffer determined using the historical data… Thus, the server 202 (e.g., via one or more of auto-scaler 206, pool manager 216, and spike monitor 214) can control, responsive to an auto-scale setting of the pool 222 based on the usage metric 230, a number of active virtual delivery agents in the pool 222 for a future time frame that corresponds to the time frame of the plurality of previous time frames. The auto-scale settings can refer to a number of VDAs to pre-launch based on the safety line and safety buffer value for a future time frame that corresponds to a historical previous time frame in F.sub.t. For example, if the forecasted usage metrics 230 include a safety line indicating that 30 login requests historically occur on Mondays from 9 to 9:30 AM, then the auto-scale setting can be based on an even distribution of 30 VDAs over six 5-minute intervals.” The spike detection mechanism using auto-scale settings referring to a number of VDAs to pre-launch for a future time frame, based on a previous historical time frame indicating a certain number of login requests, correlates to determining capacities needed to satisfy the probability at different points in time based on a time derivative of user login data within the historical data);
Zhu does not explicitly teach:
receiving, by a computing device, a configuration value of the organization indicating a probability that there will be available capacity when new computing sessions are initiated;
and dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities.
However, Balle teaches:
receiving, by a computing device, a configuration value of the client indicating a probability that there will be available capacity when new computing sessions are initiated (Paragraph 73 and 76-77, “Further, in the illustrative embodiment, the orchestrator server 1240 determines probabilities of resource overload based on the assigned workloads, as indicated in block 1548. For example, if two workloads assigned to the same managed node 1260 are predicted to transition to a processor intensive phase (e.g., each workload is predicted to request over 50% of the available processor capacity) during the same time period, the orchestrator server 1240 may determine, as a function of the weights assigned to the corresponding sequences in the prefix tree, the probability of the overload occurring (e.g., by multiplying the weight of the matching sequence for the first workload, such as 0.7, by the weight of the matching sequence for the second workload, such as 0.8, for a combined weight of 0.56 and a probability of 56%)… In the illustrative embodiment, the orchestrator server 1240 limits the adjustments to the workload assignments to only those workloads having predicted resource utilization phases with a probability of occurrence (e.g., a weight) above a predefined threshold (e.g., above 0.5 or 50%). By doing so, the orchestrator server 1240 may avoid the cost of calculating adjustments for resource utilization phases that are unlikely to occur… As an example, the policy data 1404 may indicate that the power consumption is not to exceed a predefined threshold and, in view of the threshold, the orchestrator server 1240 determines to reduce the speed of the CPU 1302 to satisfy the threshold and reassign a processor-intensive workload away from the managed node 1260 because, at the reduced speed, the CPU 1302 would be unable to complete the processor-intensive workload within a predefined time period (e.g., a time period specified in a Service Level Agreement (SLA) between the user of the client device 1220 and the operator of the system 1210).” The probability of the overload occurring from assigned workloads corelates to a probability that there will be available capacity when new computing sessions are initiated. The predefined threshold used to compare the probability of resource overload being associated with an SLA of the user of the client device correlates to a configuration value of the client indicating a probability that there will be available capacity when new computing sessions are initiated);
Balle does not explicitly teach that the configuration value is for an organization. However, organizations are a popular representation of clients as evidenced by Zhu above (paragraphs 54-55).
Additionally, Singh teaches:
and dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities (Paragraphs 67-69, “Resource provisioning service 502 is configured to determine a number of scalable resource instances that need to be provisioned to service a predicted expected number of requests… Upon determining the number of scalable resource instances that need to be provisioned, resource provisioning service 502 can send respective requests to first subscription resource management service 506 and second subscription management service 508 to provision the needed number of scalable resource instances… Responsive to a request to provision a specified number of scalable resource instances, the scalable resource management service (e.g., first subscription management service 506 and second subscription management service 508) can start up the specified number of scalable resource instances. In some embodiments, the scalable resource management service can start a scalable resource instance by initiating execution of a startup function that is configured to consume the one or more processors of the started scalable resource instance for a predetermined duration, e.g., N seconds… The started scalable resource instance is available to service (e.g., process) a request or requests subsequent to the predetermined duration since, as previously described, the now provisioned scalable resource instance is maintained fora period of time (e.g., 5 minutes, 10 minutes, or 15 minutes) even after servicing the startup function.” The resource provisioning service determining the number of scalable resource instances that need to be provisioned to service an expected number of requests correlates to determining capacities. The resource provisioning service sending a request to the scalable resource management service to start up a specific number of scalable resource instances through executing a startup function on each scalable resource instance, where a scalable resource instance becomes available to service requests after the startup function, correlates to dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with receiving, by a computing device, a configuration value of the organization indicating a probability that there will be available capacity when new computing sessions are initiated as taught by Balle because adjustments to workload assignments based on predicted overloads occurring can improve resource utilization and avoid overloads of any components of managed nodes. Orchestrator servers can additionally determine a temporal alignment of resource utilization phases of workloads to align resource utilization peaks and troughs (Balle: paragraph 74).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with and dynamically adjusting the capacity of available computing sessions hosted by the selectively and automatically powering on and/or power off host machines at one or more times according to the determined capacities as taught by Singh provisioning scalable resource instances based on a prediction of a number of requests expected satisfies specified performance criteria in a cost effective manner. Multi-tenant environments where third party provider’s scalable resources are allocated to multiple customers can cause latency with issuing start up or shut down requests. Instead, using serverless functions to start up or shut down scalable resource instances through event triggers can reduce execution times of these requests (Singh: paragraphs 62-63).
With regards to Claims 9 and 17, the method of Claim 1 performs the same steps as the machine and manufacture of Claims 9 and 17 respectively, and Claims 9 and 17 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 2, Zhu in view of Balle and Singh teaches the method of Claim 1 above. Zhu further teaches:
wherein the receiving of the historical data includes:
receiving data about numbers of logons that occurred at the different points in time (Paragraph 101, “The auto-scaler 206 can determine a usage metric (e.g., a login number of the forecasting result F.sub.t 1502 of FIG. 15) for a time frame (e.g., a 30 minute window on Monday in Week 1 1110 of FIG. 15) of multiple previous time frames based on the data indicating consumption of the pool of active virtual delivery agents. This usage metric can correspond to the forecasting result F.sub.t generating using one or more fitting curves applied to raw consumption data. The usage metric can indicate a number of predicted login requests or session requests that are to occur during a time frame.” The auto-scaler predicting the number of login requests for multiple time frames based on historic consumption of active virtual delivery agents correlates to receiving data about the numbers of logons occurred at different points in time);
Singh further teaches:
and receiving data about amounts of time required to power on one or more of the host machines at the different points in time (Paragraph 72, “In some embodiments, resource provisioning service 502 can receive information from the scalable resource management service (e.g., first subscription management service 506 or second subscription management service 508) that allows resource provisioning service 502 to provision (scale out) the needed scalable resource instances in a just-in-time (JIT) manner to minimize (and ideally eliminate) the cold start problem as well as the time a started scalable resource instance is idle after being started. For example, according to one embodiment, first subscription management service 506 can maintain records of historical cold start times needed to start up the scalable resource instances under the first subscription. The recorded cold start time is the duration from when the function is initiated to start up a scalable resource instance to when the started scalable resource instance is available to service a request. As such, the cold start time includes the predetermined duration (e.g., N seconds) the executing startup function consumes the started scalable resource instance. First subscription management service 506 can then send or otherwise provide the recorded historical cold start times to resource provisioning service 502.” The resource provisioning service receiving information on historical cold start times needed to start up the scalable resource instances correlates to receiving data about the amounts of time required to power on one or more host machines at different points in time).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with receiving data about amounts of time required to power on one or more of the host machines at the different points in time as taught by Singh because historical cold start times can be used to determine an appropriate time to send requests to provision scalable resource instances in a just-in-time manner. This can be achieved by calculating the average and average deviation of cold start times for the scalable resource instances (Singh: paragraphs 73-74).
With regards to Claims 10 and 18, the method of Claim 2 performs the same steps as the machine and manufacture of Claims 10 and 18 respectively, and Claims 10 and 18 are therefore rejected using the same rationale set forth above in the rejection of Claim 2.
With regards to Claim 3, Zhu in view of Balle and Singh teaches the method of Claim 2 above. Zhu further teaches:
wherein the different points in time include times of day (Paragraphs 93 and 101, “Types of time frames can correspond to day, night, morning, afternoon, evening, types of days, days of the week, vacation days, vacation weeks, or holidays. For example, the consumption analyzer 208 can apply a filter to the raw data to remove requests that occurred in time frames that correspond to weekends (e.g., Saturdays and Sundays) and holidays (e.g., federal holidays) … The auto-scaler 206 can determine a usage metric (e.g., a login number of the forecasting result F.sub.t 1502 of FIG. 15) for a time frame (e.g., a 30 minute window on Monday in Week 1 1110 of FIG. 15) of multiple previous time frames based on the data indicating consumption of the pool of active virtual delivery agents. This usage metric can correspond to the forecasting result F.sub.t generating using one or more fitting curves applied to raw consumption data. The usage metric can indicate a number of predicted login requests or session requests that are to occur during a time frame.” The data indicating consumption of the active virtual delivery agents across multiple time frames, which include day, night, morning, afternoon and evening, as well as specific 30-minute windows on a particular day of the week, correlates to the different points in time including times of day).
With regards to Claim 4, Zhu in view of Balle and Singh teaches the method of Claim 3 above. Zhu further teaches:
wherein the receiving of the historical data includes receiving historical data associated with multiple 24-hour periods (Paragraphs 93 and 101, “Types of time frames can correspond to day, night, morning, afternoon, evening, types of days, days of the week, vacation days, vacation weeks, or holidays. For example, the consumption analyzer 208 can apply a filter to the raw data to remove requests that occurred in time frames that correspond to weekends (e.g., Saturdays and Sundays) and holidays (e.g., federal holidays) … The auto-scaler 206 can determine a usage metric (e.g., a login number of the forecasting result F.sub.t 1502 of FIG. 15) for a time frame (e.g., a 30 minute window on Monday in Week 1 1110 of FIG. 15) of multiple previous time frames based on the data indicating consumption of the pool of active virtual delivery agents. This usage metric can correspond to the forecasting result F.sub.t generating using one or more fitting curves applied to raw consumption data. The usage metric can indicate a number of predicted login requests or session requests that are to occur during a time frame.” The data indicating consumption of the active virtual delivery agents across multiple time frames, which include types of days, days of the week, or holidays, correlates to the receiving of the historical data including historical data associated with multiple 24-hour periods).
With regards to Claim 5, Zhu in view of Balle and Singh teaches the method of Claim 1 above. Zhu further teaches:
wherein the auto-scaling of the host machines at the one or more times includes:
determining a current time-of-day (Paragraph 111, “For example, if the forecasted usage metrics 230 include a safety line indicating that 30 login requests historically occur on Mondays from 9 to 9:30 AM, then the auto-scale setting can be based on an even distribution of 30 VDAs over six 5-minute intervals. The auto-scale setting can indicate to pre-launch 5 additional VDAs every 5 minutes in the 30-minute time interval. Thus, the system can begin pre-launching VDAs before 9 AM on Monday (e.g., beginning at 8:50 AM on Monday).” The system pre-launching 5 additional VDAs at a particular time such as 8:50 AM correlates to the auto-scaling including determining a current time-of-day);
determining, from the determined capacities, a target capacity needed to satisfy the probability at the current time-of-day (Paragraph 111, “Thus, the server 202 (e.g., via one or more of auto-scaler 206, pool manager 216, and spike monitor 214) can control, responsive to an auto-scale setting of the pool 222 based on the usage metric 230, a number of active virtual delivery agents in the pool 222 for a future time frame that corresponds to the time frame of the plurality of previous time frames. The auto-scale settings can refer to a number of VDAs to pre-launch based on the safety line and safety buffer value for a future time frame that corresponds to a historical previous time frame in F.sub.t. For example, if the forecasted usage metrics 230 include a safety line indicating that 30 login requests historically occur on Mondays from 9 to 9:30 AM, then the auto-scale setting can be based on an even distribution of 30 VDAs over six 5-minute intervals. The auto-scale setting can indicate to pre-launch 5 additional VDAs every 5 minutes in the 30-minute time interval. Thus, the system can begin pre-launching VDAs before 9 AM on Monday (e.g., beginning at 8:50 AM on Monday).” The auto-scale settings including the number of VDAs to pre-launch at a particular future time frame based on historical data from the same time frame correlates to determining a target capacity needed to satisfy the probability at the current time-of-day); and
powering on at least one of the plurality of host machines to achieve the target capacity (Paragraph 123, “At ACT 318, the server can control a pool of VDAs. The server can use the auto-scale settings established at ACT 316 to pre-launch VDAs and make them available in a pool of VDAs for future session requests. The server can control the number of available VDAs in the pool ahead of each time frame, and also control the number of available VDAs at checkpoints during the time frame. Controlling the pool of VDAs can refer to preparing and launching a certain number of VDAs (e.g., the estimated safety line value for the time frame) before a time frame. The server 318 can generate tokens that are used by a pool manager service to launch VDAs.” The server pre-launching the VDAs based on the auto-scale settings and making them available for future session requests ahead of each time frame correlates to powering on at least one of the plurality of host machines to achieve the target capacity).
With regards to Claims 13 and 19, the method of Claim 5 performs the same steps as the machine and manufacture of Claims 13 and 19 respectively, and Claims 13 and 19 are therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to Claim 6, Zhu in view of Balle and Singh teaches the method of Claim 1 above. Singh further teaches:
wherein the computing sessions include virtual desktop sessions (Fig. 3, paragraphs 40 and 53, “As shown, the application virtualization system may be single-server or multi-server system, or cloud system, including at least one virtualization server 301 configured to provide virtual desktops and/or virtual applications to one or more terminals 240 (FIG. 2). As used herein, a desktop refers to a graphical environment or space in which one or more applications may be hosted and/or executed. A desktop may include a graphical shell providing a user interface for an instance of an operating system in which local and/or remote applications can be integrated. Applications may include programs that execute after an instance of an operating system (and, optionally, also the desktop) has been loaded. Each instance of the operating system may be physical (e.g., one operating system per device) or virtual (e.g., many instances of an operating system running on a single device). Each application may be executed on a local device, or executed on a remotely located device (e.g., remoted)… Client computers 411-414 may connect to management server 410 via the Internet or some other communication network and may request access to one or more of the computing resources managed by management server 410. In response to client requests, management server 410 may include a resource manager configured to select and provision physical resources in the hardware layer of the cloud system based on the client requests. For example, management server 410 and additional components of the cloud system may be configured to provision, create, and manage VMs and their operating environments (e.g., hypervisors, storage resources, services offered by the network elements, etc.) for customers at client computers 411-414, over a network (e.g., the Internet), providing customers with computational resources, data storage services, networking capabilities, and computer platform and application support. Cloud systems also may be configured to provide various specific services, including security systems, development environments, user interfaces, and the like.” The management server provisioning, creating, and managing VMs or virtual desktops and their operating environments for customers correlates to the computing sessions including virtual desktop sessions).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with wherein the computing sessions include virtual desktop sessions as taught by Singh because virtual desktops and virtual applications can include graphical shells providing a user interface for an instance of an operating system that integrates local or remote applications. Each instance of the operating system can be physical or virtual, which allows one to many instances of operating systems for each device. Applications can also be executed on a local device or executed on a remotely located device (Singh: paragraph 40).
With regards to Claim 14, the method of Claim 6 performs the same steps as the machine of Claim 14, and Claim 14 is therefore rejected using the same rationale set forth above in the rejection of Claim 6.
With regards to Claim 7, Zhu in view of Balle and Singh teaches the method of Claim 1 above. Zhu further teaches:
wherein the auto-scaling of the host machines at the one or more times includes:
periodically auto-scaling the host machines at one or more times according to the determined capacities (Paragraphs 71-72, “Accordingly, the system can determine to prepare a additional sessions at this point. The number of additional sessions to prepare, a, can be set based on the safety buffer determined using the historical data. At the second checkpoint, which is five minutes after the first checkpoint or 10 minutes from the beginning of the time interval, the system can determine the number of session requests that were received in the first 10 minutes (R.sub.10). Since a additional sessions were prepared after the first checkpoint, the system can determine whether R.sub.10−a is greater than E*(10/30) + a. If R.sub.10−a is greater than E*(10/30) + a, then the system can determine to prepare a number of additional VDA sessions. Thus, the system can, after each checkpoint, maintain at least a active sessions or available VDAs in the pool of available VDAs as follows.” The system preparing additional sessions after each of the multiple checkpoints based on the number of session requests and available VDAs correlates to periodically auto-scaling the host machines at one or more times according to the determined capacities).
With regards to Claim 15, the method of Claim 7 performs the same steps as the machine of Claim 15, and Claim 15 is therefore rejected using the same rationale set forth above in the rejection of Claim 7.
With regards to Claim 11, Zhu in view of Balle and Singh teaches the system of Claim 9 above. Zhu further teaches:
wherein the different points in time include times of day (Paragraphs 93 and 101, “Types of time frames can correspond to day, night, morning, afternoon, evening, types of days, days of the week, vacation days, vacation weeks, or holidays. For example, the consumption analyzer 208 can apply a filter to the raw data to remove requests that occurred in time frames that correspond to weekends (e.g., Saturdays and Sundays) and holidays (e.g., federal holidays) … The auto-scaler 206 can determine a usage metric (e.g., a login number of the forecasting result F.sub.t 1502 of FIG. 15) for a time frame (e.g., a 30 minute window on Monday in Week 1 1110 of FIG. 15) of multiple previous time frames based on the data indicating consumption of the pool of active virtual delivery agents. This usage metric can correspond to the forecasting result F.sub.t generating using one or more fitting curves applied to raw consumption data. The usage metric can indicate a number of predicted login requests or session requests that are to occur during a time frame.” The data indicating consumption of the active virtual delivery agents across multiple time frames, which include day, night, morning, afternoon and evening, as well as specific 30-minute windows on a particular day of the week, correlates to the different points in time including times of day).
With regards to Claim 12, Zhu in view of Balle and Singh teaches the system of Claim 11 above. Zhu further teaches:
wherein the receiving of the historical data includes receiving historical data associated with multiple 24-hour periods (Paragraphs 93 and 101, “Types of time frames can correspond to day, night, morning, afternoon, evening, types of days, days of the week, vacation days, vacation weeks, or holidays. For example, the consumption analyzer 208 can apply a filter to the raw data to remove requests that occurred in time frames that correspond to weekends (e.g., Saturdays and Sundays) and holidays (e.g., federal holidays) … The auto-scaler 206 can determine a usage metric (e.g., a login number of the forecasting result F.sub.t 1502 of FIG. 15) for a time frame (e.g., a 30 minute window on Monday in Week 1 1110 of FIG. 15) of multiple previous time frames based on the data indicating consumption of the pool of active virtual delivery agents. This usage metric can correspond to the forecasting result F.sub.t generating using one or more fitting curves applied to raw consumption data. The usage metric can indicate a number of predicted login requests or session requests that are to occur during a time frame.” The data indicating consumption of the active virtual delivery agents across multiple time frames, which include types of days, days of the week, or holidays, correlates to the receiving of the historical data including historical data associated with multiple 24-hour periods).
With regards to Claim 16, Zhu in view of Balle and Singh teaches the system of Claim 9 above. Zhu further teaches:
wherein the determining of the capacities needed to satisfy the probability at the different points in time includes:
determining a current day-of-week (Paragraph 86, “For example, each time the server 202 receives, detects, or otherwise identifies a session request, the server 202 can store, in data repository 224, information associated with the session request and a timestamp (e.g., date and time in any format, such as yyyy-MM-dd hh:mm:ss am or pm, d MMM yyyy HH:mm:ss, or yyyy/MM/dd HH:mm:ss timezone) for the session request.” The server storing a timestamp including the date associated with a newly received session request correlates to determining a current day of week),
selecting, from the historical data, data associated with the current day-of-week (Paragraphs 93 and 105, “Types of time frames can correspond to day, night, morning, afternoon, evening, types of days, days of the week, vacation days, vacation weeks, or holidays… The safety buffer component 212 can set the safety buffer value based on a statistical analysis of the usage data, a default value, an initial default value, a predetermined value set by an administrator of the system, or other value. The safety buffer component 212 can update or modify the safety buffer value for each time frame or time interval based on statistical characteristics of the time frame or time interval (e.g., the standard deviation of data of the time frame). The safety buffer value can be stored in usage metrics 230 data structure. Thus, the usage metrics 230 can include safety line values and safety buffer values for multiple time frames, and the server 202 establish a safety buffer of virtual delivery agents based on the usage metric and a standard deviation of the usage metric for the previous time frames.” The safety buffer component setting a safety buffer value based on statistical analysis of usage data for each time frame or interval, which includes types of days or days of the week, correlates to selecting historical data associated with the current day of the week), and
determining the capacities needed to satisfy the probability at the different points in time based on the selected data (Paragraph 71, “For example, the system can execute a spike detection mechanism at 5 minute checkpoints within a 30 minute predetermined pre-launch time interval of 30 minutes. At the beginning of a 30 minute time interval, the system can be configured to prelaunch E sessions (e.g., based on the estimated safety line F.sub.t for the time frame). After the first 5 minutes of the 30 minute time interval, the system can initiate a first checkpoint. At the first checkpoint, the system can determine the number of session requests that were received in the first five minutes as Rs. Receipt of a session request can refer to or include receiving a request to initiate or establish a session that uses a VDA. Receipt of a session request for the purposes of the checkpoint can refer to or include both receiving a request to initiate or establish a session that uses a VDA, and also successfully establishing the session using the VDA… In this case, the system can determine that if this trends continues, the available VDAs in the pool of VDAs, which is configured to prelaunch E sessions, will be consumed prior to completion of the 30 minute time interval. Accordingly, the system can determine to prepare a additional sessions at this point. The number of additional sessions to prepare, a, can be set based on the safety buffer determined using the historical data.” The number of additional sessions to be prepared based on the safety buffer, which is determined using historical data for a particular time frame, correlates to determining capacities needed to satisfy the probability based on the selected data. The spike detection mechanism being executed at 5-minute checkpoints within a 30-minute time interval correlates to determining capacities needed to satisfy the probability at different points in time).
With regards to Claim 20, the system of Claim 16 performs the same steps as the manufacture of Claim 20, and Claim 20 is therefore rejected using the same rationale set forth above in the rejection of Claim 16.
With regards to Claim 21, Zhu in view of Balle and Singh teaches the method of Claim 1 above. Balle further teaches:
wherein the configuration value is a percentage value that represents a desired, target probability that there will be available capacity for newly initiated computing sessions (Paragraphs 73 and 76, “Further, in the illustrative embodiment, the orchestrator server 1240 determines probabilities of resource overload based on the assigned workloads, as indicated in block 1548. For example, if two workloads assigned to the same managed node 1260 are predicted to transition to a processor intensive phase (e.g., each workload is predicted to request over 50% of the available processor capacity) during the same time period, the orchestrator server 1240 may determine, as a function of the weights assigned to the corresponding sequences in the prefix tree, the probability of the overload occurring (e.g., by multiplying the weight of the matching sequence for the first workload, such as 0.7, by the weight of the matching sequence for the second workload, such as 0.8, for a combined weight of 0.56 and a probability of 56%)… In the illustrative embodiment, the orchestrator server 1240 limits the adjustments to the workload assignments to only those workloads having predicted resource utilization phases with a probability of occurrence (e.g., a weight) above a predefined threshold (e.g., above 0.5 or 50%). By doing so, the orchestrator server 1240 may avoid the cost of calculating adjustments for resource utilization phases that are unlikely to occur.” The probability of the overload occurring from assigned workloads correlates to a probability that there will be available capacity when new computing sessions are initiated. The predefined threshold used to compare the probability of resource overload being used as a minimum requirement for a particular workload to be processed correlates to a configuration value being a percentage value that represents a desired, target probability that there will be available capacity for newly initiated computing sessions).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Zhu with wherein the configuration value is a percentage value that represents a desired, target probability that there will be available capacity for newly initiated computing sessions as taught by Balle because adjustments to workload assignments based on predicted overloads occurring can improve resource utilization and avoid overloads of any components of managed nodes. Orchestrator servers can additionally determine a temporal alignment of resource utilization phases of workloads to align resource utilization peaks and troughs (Balle: paragraph 74).
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Suryanarayanan et al. (U.S. Patent No. US 9256452 B1); teaching a method of determining the time to availability for various configurations of instances for computing resources. Collected data can be utilized to provide an estimate of the expected time for a specific configuration of an instance to be available in response to receiving a request to create a new instance of the computing resource. The collected data can also include data defining actual boot times for one or more virtual machine instances and be used to determine estimated times required to boot a virtual machine instance.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
The publicPAIR and privatePAIR systems are no longer available. 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.
/SELINA ELISA HU/ Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193