DETAILED ACTION
The action is responsive to the Application filed on 07/03/2024. Claims 1-20 are pending in the case. Claims 1, 8 and 15 are independent claims.
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 .
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.07(e) 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 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim1-18 of U.S. Patent No. 11698814 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the pending claims are an obvious variant of the claim set from the '304 patent only including minor differences in computer structure and communicating with a service provider, see chart below where bolded portions are similar. It would have been obvious to a person of ordinary skill in the art to communicate with a service provider to execute actions on a computing resource on the service provider so that the computing resources could be made more useful by allowing actions to be assigned to them..
US Application No. 18/764000
US Patent No. 11698814
1. A system comprising:
one or more processors; and
memory communicatively coupled to the one or more processors and including computer-executable instructions stored thereupon which, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
providing a first user interface to manage cloud computing resources;
receiving, via the first user interface, first user input data requesting to organize a first workload in a space, the first workload being associated with a first cloud computing service of a first entity;
based at least in part on the first user input data, importing first data associated with the first workload into the space;
receiving, via the first user interface, second user input data requesting to organize a second workload in the space, the second workload being associated with a second cloud computing service of a second entity;
based at least in part on the second user input data, importing second data associated with the second workload into the space;
receiving, via the first user interface or a second user interface, third user input data requesting to perform an action for the space; and
based at least in part on the third user input data:
determining a first workflow for the first workload;
causing the first workflow to be performed to implement the action for the first workload; and
determining a second workflow for the second workload;
causing the second workflow to be performed to implement the action for the second workload, the second workflow being different than the first workflow.
2. The system of claim 1, wherein: causing the first workflow to be performed comprises at least transmitting a first request to the first cloud computing service to alter a characteristic of a first computing resource associated with the first workload; and causing the second workflow to be performed comprises at least transmitting a second request to the second cloud computing service to alter a characteristic of a second computing resource associated with the second workload.
3. The system of claim 1, wherein: the action comprises a parking action of setting a computing resource to an inactive state; the causing the first workflow to be performed comprises causing a first computing resource of the first cloud computing service to be set to the inactive state during a first period of time; and the causing the first workflow to be performed comprises causing a second computing resource of the second cloud computing service to be set to the inactive state during a second period of time.
4. The system of claim 3, wherein the operations further comprise: receiving first data indicating a utilization of a first computing resource of the first cloud computing service; receiving second data indicating a utilization of a second computing resource of the second cloud computing service; determining that the first computing resource is underutilized based at least in part on the first data; determining that the second computing resource is underutilized based at least in part on the second data; and providing a recommendation to perform the action.
5. The system of claim 4, wherein the operations further comprise: generating a visualization that represents the underutilization of the first computing resource and the underutilization of the second computing resource.
6. The system of claim 1, wherein: the first user input data includes a request to create a new workload; and the importing the first data associated with the first workload comprises: based at least in part on the first user input data, provisioning a computing resource to implement the first workload; and associating the first data with the space.
7. The system of claim 1, wherein: the first user input data includes a request to import an existing workload; and the importing the first data associated with the first workload comprises: based at least in part on the first user input data, transmitting a request to the first cloud computing service to receive the first data associated with the first workload; and receiving, from the first cloud computing service, the first data associated with the first workload.
8. A method comprising:
presenting a service provider management interface to facilitate management of multiple service provider resources;
receiving, by one or more processors and via the service provider management interface, a first request to group a first workload and a second workload, the first workload being implemented by a first service provider of a first entity and the second workload being implemented by a second service provider of a second entity;
based at least in part on the first request, creating, by the one or more processors, a group that includes the first workload and the second workload;
receiving, by the one or more processors, a second request to perform an action for the group; and
based at least in part on second request:
causing the action to be performed for the first workload by communicating with the first service provider; and
causing the action to be performed for the second workload by communicating with the second service provider.
9. The method of claim 8, wherein: the causing the action to be performed for the first workload comprises implementing a first workflow that includes one or more first tasks; and the causing the action to be performed for the second workload comprises implementing a second workflow that includes one or more second tasks.
10. The method of claim 8, wherein: the action comprises setting a computing resource to an inactive state; the causing the action to be performed for the first workload comprises causing a first computing resource of the first service provider to be set to the inactive state; and the causing the action to be performed for the second workload comprises causing a second computing resource of the second service provider to be set to the inactive state.
11. The method of claim 10, further comprising: determining a period of time to set the first workload and the second workload to the inactive state; wherein the causing the action to be performed for the first workload comprises causing the first computing resource of the first service provider to be set to the inactive state during the period of time; and wherein the causing the action to be performed for the first workload comprises causing the first computing resource of the first service provider to be set to the inactive state during the period of time.
12. The method of claim 11, wherein the determining the period of time is based at least in part on utilization data for the first workload and utilization data for the second workload.
13. The method of claim 11, wherein the determining the period of time comprises receiving user input data indicating the period of time for inactivity.
14. The method of claim 8, further comprising: associating the group with a budget; determining an amount spent on computing resources for implementing the first workload and the second workload; and causing display of an indicating regarding the budget and the amount spent on the computing resources.
1. A system comprising:
one or more processors; and
memory communicatively coupled to the one or more processors and including computer-executable instructions stored thereupon which, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
providing a first user interface to manage cloud computing resources;
receiving, via the first user interface, first user input data requesting to organize a first workload in a space, the first workload being associated with a first group of cloud resources of a first service provider;
based at least in part on the first user input data, importing first data associated with the first workload into the space, the first data indicating at least a first operation cost for the first workload;
receiving, via the first user interface, second user input data requesting to organize a second workload in the space, the second workload being associated with a second group of cloud resources of a second service provider;
based at least in part on the second user input data, importing second data associated with the second workload into the space, the second data indicating at least a second operation cost for the second workload;
providing, via the first user interface or a second user interface, information that is based at least in part on the first data and the second data;
receiving, via the first user interface or the second user interface, third user input data requesting to perform an action for the space; and
based at least in part on the third user input data, causing the action to be performed for the first workload and the second workload by:
determining a first workflow for the first workload based at least in part on a characteristic of the first workload, the first workflow including a first set of tasks to be performed in a first order;
causing the first workflow to be performed to implement the action for the first workload;
determining a second workflow for the second workload based at least in part on a characteristic of the second workload, the second workflow including a second set of tasks to be performed in a second order; and
causing the second workflow to be performed to implement the action for the second workload, the second workflow being different than the first workflow.
2. The system of claim 1, wherein: causing the first workflow to be performed comprises at least transmitting a first request to the first service provider to alter a characteristic of a first computing resource associated with the first workload; and causing the second workflow to be performed comprises at least transmitting a second request to the second service provider to alter a characteristic of a second computing resource associated with the second workload.
3. The system of claim 1, wherein: the action comprises a parking action of setting a computing resource to an inactive state; the causing the first workflow to be performed comprises causing a cloud resource of the first group of cloud resources to be set to the inactive state during a first period of time; and the causing the second workflow to be performed comprises causing a cloud resource of the second group of cloud resources to be set to the inactive state during a second period of time.
4. The system of claim 3, wherein the operations further comprise: receiving first utilization data indicating a utilization of a first cloud resource of the first group of cloud resources; receiving second utilization data indicating a utilization of a second cloud resource of the second group of cloud resources; determining that the first cloud resource is underutilized based at least in part on the first utilization data; determining that the second cloud resource is underutilized based at least in part on the second utilization data; and providing a recommendation to perform the action.
5. The system of claim 4, wherein the operations further comprise: generating a visualization that represents the underutilization of the first cloud resource and the underutilization of the second cloud resource.
6. The system of claim 1, wherein: the first user input data includes a request to create a new workload; and the importing the first data associated with the first workload comprises: based at least in part on the first user input data, provisioning a computing resource to implement the first workload; and associating the first data with the space.
7. The system of claim 1, wherein: the first user input data includes a request to import an existing workload; and the importing the first data associated with the first workload comprises: based at least in part on the first user input data, transmitting a request to the first service provider to receive the first data associated with the first workload; and receiving, from the first service provider, the first data associated with the first workload.
8. A method comprising:
presenting a service provider management interface to facilitate management of multiple service provider resources;
receiving, by one or more processors and via the service provider management interface, a first request to group a first workload and a second workload, the first workload being implemented by a first service provider associated with a first user account and the second workload being implemented by a second service provider associated with a second user account;
based at least in part on the first request, creating, by the one or more processors, a group that includes the first workload and the second workload;
associating first data and second data with the group, the first data indicating at least a first operation cost for the first workload, the second data indicating at least a second operation cost for the second workload;
providing, via the service provider management interface, information that is based at least in part on the first data and the second data;
receiving, by the one or more processors, a second request to perform an action for the group; and
based at least in part on the second request:
causing the action to be performed for the first workload by performing a first set of tasks in a first order, the first set of tasks being based at least in part on a characteristic of the first workload; and
causing the action to be performed for the second workload by performing a second set of tasks in a second order, the second set of tasks being based at least in part on a characteristic of the second workload.
9. The method of claim 8, wherein: the action comprises setting a computing resource to an inactive state; the causing the action to be performed for the first workload comprises causing a first computing resource of the first service provider to be set to the inactive state; and the causing the action to be performed for the second workload comprises causing a second computing resource of the second service provider to be set to the inactive state.
10. The method of claim 9, further comprising: determining a period of time to set the first workload and the second workload to the inactive state; wherein the causing the action to be performed for the first workload comprises causing the first computing resource of the first service provider to be set to the inactive state during the period of time; and wherein the causing the action to be performed for the second workload comprises causing the second computing resource of the second service provider to be set to the inactive state during the period of time.
11. The method of claim 10, wherein the determining the period of time is based at least in part on utilization data for the first workload and utilization data for the second workload.
12. The method of claim 10, wherein the determining the period of time comprises receiving user input data indicating the period of time.
13. The method of claim 8, further comprising: associating the group with a budget; determining an amount spent on computing resources for implementing the first workload and the second workload; and causing display of an indication regarding the budget and the amount spent on the computing resources.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 8-12 and 15-19 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Visconti et al. (US 20200209946 A1, hereinafter Visconti).
As to claim 8, Visconti discloses a method comprising:
presenting a service provider management interface to facilitate management of multiple service provider resources (“Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components,” Visconti paragraph 0117; “Further in FIG. 4, a user 410, such as an administrator at the cloud consumer consuming the various virtual machines of cloud providers 302, 306 may apply tag base rules 412 to determine whether to provide approval of the generated power schedule and group formation predictions. As illustrated, the approval 414 may also include rule-based approval, not requiring human intervention,” Visconti paragraph 0070);
receiving, by one or more processors and via the service provider management interface, a first request to group a first workload and a second workload, the first workload being implemented by a first service provider of a first entity and the second workload being implemented by a second service provider of a second entity (“As described in detail below, any of the deployment metadata referenced above, or described in more detail below, may be used alone or in combination by the group manager 138 to define groups of virtual machines for collective on/off scheduling. For example, it may occur that the virtual machine 114 and the virtual machine 120 are utilized by the same team of software developers, and/or are deployed with the same or similar applications installed thereon. Consequently, the virtual machines 114/120 may be turned on/off together as part of a defined group, even though the virtual machines 114/120 are deployed on the different cloud providers 110/116,” Visconti paragraph 0044);
based at least in part on the first request, creating, by the one or more processors, a group that includes the first workload and the second workload (“To assist with power management in these scenarios, a group manager 138 is configured to access deployment metadata from within the virtual machine repository 126. The group manager 138 may use the deployment metadata to group virtual machines for inclusion as groups within on/off power intervals predicted by the interval predictor 134 and tested by the reliability manager 136,” Visconti paragraph 0043);
receiving, by the one or more processors, a second request to perform an action for the group (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063); and
based at least in part on second request:
causing the action to be performed for the first workload by communicating with the first service provider (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071); and
causing the action to be performed for the second workload by communicating with the second service provider (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071).
As to claim 9, Visconti further discloses the method of claim 8, wherein:
the causing the action to be performed for the first workload comprises implementing a first workflow that includes one or more first tasks (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071, instructing the VM to perform the turn off task); and
the causing the action to be performed for the second workload comprises implementing a second workflow that includes one or more second tasks (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071, instructing the VM to perform the turn off task).
As to claim 10, Visconti further discloses the method of claim 8, wherein:
the action comprises setting a computing resource to an inactive state (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; instructing the VM to turn off (i.e., move to an inactive state));
the causing the action to be performed for the first workload comprises causing a first computing resource of the first service provider to be set to the inactive state (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; instructing the VM to turn off (i.e., move to an inactive state)); and
the causing the action to be performed for the second workload comprises causing a second computing resource of the second service provider to be set to the inactive state (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; instructing the VM to turn off (i.e., move to an inactive state)).
As to claim 11, Visconti further discloses the method of claim 10, further comprising:
determining a period of time to set the first workload and the second workload to the inactive state ("Each of the plurality of virtual machines may be classified as active or idle during each time division of the observation time, based on the performance data and on idleness criteria, to thereby generate an active-idle series for each of the plurality of virtual machines (206). For example, as referenced above and described and detail below, such idleness criteria may be implemented by the idleness detector 130, for example, specified combinations of the relevant performance data characterizations of the physical resources, relative to predefined idleness threshold or arranges. The resulting active-idle series for each of the virtual machines 112/114 and 118/120 may thus be understood to be represented as a series of consecutive hourly increments, in which each hour is effectively marked active or idle," Visconti paragraph 0057; "For each active-idle series of each virtual machine of the plurality of virtual machines, at least one periodicity of recurring idle times may be determined to exist within the observation time (208). For example, the periodicity detector 132 of the usage pattern detector 128 of FIG. 1 may be configured to analyze each active-idle series and execute one or more algorithms to determine whether and to what extent a periodicity exists. For example, depending on a length of time of the observation time, the periodicity detector 132 may detect one or more periods that are daily, weekly, or monthly," Visconti paragraph 0058, determine if VMs are idle or active according to utilization data and determine a period of time to turn off the VM);
wherein the causing the action to be performed for the first workload comprises causing the first computing resource of the first service provider to be set to the inactive state during the period of time ("Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120. Accordingly, resources associated with providing those virtual machines may be conserved," Visconti paragraph 0063); and
wherein the causing the action to be performed for the first workload comprises causing the first computing resource of the first service provider to be set to the inactive state during the period of time ("Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120. Accordingly, resources associated with providing those virtual machines may be conserved," Visconti paragraph 0063).
As to claim 12, Visconti further discloses the method of claim 11, wherein the determining the period of time is based at least in part on utilization data for the first workload and utilization data for the second workload ("Each of the plurality of virtual machines may be classified as active or idle during each time division of the observation time, based on the performance data and on idleness criteria, to thereby generate an active-idle series for each of the plurality of virtual machines (206). For example, as referenced above and described and detail below, such idleness criteria may be implemented by the idleness detector 130, for example, specified combinations of the relevant performance data characterizations of the physical resources, relative to predefined idleness threshold or arranges. The resulting active-idle series for each of the virtual machines 112/114 and 118/120 may thus be understood to be represented as a series of consecutive hourly increments, in which each hour is effectively marked active or idle," Visconti paragraph 0057; "For each active-idle series of each virtual machine of the plurality of virtual machines, at least one periodicity of recurring idle times may be determined to exist within the observation time (208). For example, the periodicity detector 132 of the usage pattern detector 128 of FIG. 1 may be configured to analyze each active-idle series and execute one or more algorithms to determine whether and to what extent a periodicity exists. For example, depending on a length of time of the observation time, the periodicity detector 132 may detect one or more periods that are daily, weekly, or monthly," Visconti paragraph 0058, determine if VMs are idle or active according to utilization data and determine a period of time to turn off the VM).
As to claim 15, Visconti discloses one or more non-transitory computer-readable media storing computer executable instructions that, when executed, instruct one or more processors to perform operations comprising:
presenting a service provider management interface to facilitate management of multiple service provider resources (“Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components,” Visconti paragraph 0117; “Further in FIG. 4, a user 410, such as an administrator at the cloud consumer consuming the various virtual machines of cloud providers 302, 306 may apply tag base rules 412 to determine whether to provide approval of the generated power schedule and group formation predictions. As illustrated, the approval 414 may also include rule-based approval, not requiring human intervention,” Visconti paragraph 0070);
receiving, via the service provider management interface, a first request to group a first workload and a second workload, the first workload being implemented by a first service provider of a first entity and the second workload being implemented by a second service provider of a second entity (“As described in detail below, any of the deployment metadata referenced above, or described in more detail below, may be used alone or in combination by the group manager 138 to define groups of virtual machines for collective on/off scheduling. For example, it may occur that the virtual machine 114 and the virtual machine 120 are utilized by the same team of software developers, and/or are deployed with the same or similar applications installed thereon. Consequently, the virtual machines 114/120 may be turned on/off together as part of a defined group, even though the virtual machines 114/120 are deployed on the different cloud providers 110/116,” Visconti paragraph 0044);
based at least in part on the first request, creating, by the one or more processors, a group that includes the first workload and the second workload (“To assist with power management in these scenarios, a group manager 138 is configured to access deployment metadata from within the virtual machine repository 126. The group manager 138 may use the deployment metadata to group virtual machines for inclusion as groups within on/off power intervals predicted by the interval predictor 134 and tested by the reliability manager 136,” Visconti paragraph 0043);
receiving, by the one or more processors, a second request to perform an action for the group (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063); and
based at least in part on second request:
causing the action to be performed for the first workload by communicating with the first service provider (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071); and
causing the action to be performed for the second workload by communicating with the second service provider (“Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120,” Visconti paragraph 0063; “For example, with reference back to FIG. 1, suitable cloud provider interfaces 121 may be utilized by the power handler 140 of the power manager 102 to instruct and execute collected power cycling of the described groups of virtual machines, in accordance with the predicted power schedules,” Visconti paragraph 0071).
As to claim 16, it is substantially similar to claim 9 and is therefore rejected using the same rationale as above.
As to claim 17, it is substantially similar to claim 10 and is therefore rejected using the same rationale as above.
As to claim 18, it is substantially similar to claim 11 and is therefore rejected using the same rationale as above.
As to claim 19, it is substantially similar to claim 12 and is therefore rejected using the same rationale as above.
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.
Claims 1-4, 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Muller et al. (US 20140165060 A1, hereinafter Muller) in view of Visconti et al. (US 20200209946 A1, hereinafter Visconti).
As to claim 1, Muller discloses a system comprising:
one or more processors (“In these examples, the machine readable instructions comprise a program for execution by a processor such as the processor 2112 shown in the example processor platform 2100 discussed below in connection with FIG. 21,” Muller paragraph 0043); and
memory communicatively coupled to the one or more processors and including computer-executable instructions stored thereupon which, when executed by the one or more processors, cause the one or more processors to perform operations (“In these examples, the machine readable instructions comprise a program for execution by a processor such as the processor 2112 shown in the example processor platform 2100 discussed below in connection with FIG. 21,” Muller paragraph 0043) comprising:
providing a first user interface to manage cloud computing resources (“The user interface 302 of the illustrated example receives information from a user (e.g., the administrator 116 and/or the developer 118) indicating the assignment of skills to workflows and requests to execute workflows by DEMs,” Muller paragraph 0032);
receiving, via the first user interface, first user input data requesting to organize a first workload in a space, the first workload being associated with a first cloud computing service of a first entity (“The example cloud manager 138 of FIG. 1 interacts with the components of the system 100 (e.g., the application director 106 and the cloud provider 110) to facilitate the management of the resources of the cloud provider 110. The example cloud manager 138 includes a blueprint manager 140 to facilitate the creation and management of multi-machine blueprints and a resource manager 144 to reclaim unused cloud resources,” Muller paragraph 0022; "FIGS. 13-17 illustrate example graphical user interfaces that may be provided by the cloud manager 138 to facilitate provisioning and configuration of a provisioned multi-machine blueprint. An example graphical user interface 1300 illustrated in FIG. 13 provides a listing of available resources (including multi-machine blueprints) that may be provisioned. After selecting a resource that is a multi-machine blueprint, the cloud manager 138 displays the user interface 1400 of FIG. 14 to allow configuration of the provisioning. The example illustrated in FIG. 14 includes the same components as the multi-machine blueprint 208 illustrated in FIG. 2. The user interface 1400 includes user interface elements 1402, 1404, and 1406 for specifying the settings to be used in provisioning the components of the multi-machine blueprint. The example, user interface elements 1402, 1404, and 1406 allow a user to specify a number of machines to be provisioned, a number of CPUs to be included, an amount of memory to be included, and an amount of storage to be included in each of the components of the multi-machine blueprint," Muller paragraph 0064; machines are provisioned with a blueprint workload in a cloud computing service);
based at least in part on the first user input data, importing first data associated with the first workload into the space ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, provisioned resources have relevant applications installed (i.e., importing data associated with the workload));
receiving, via the first user interface, second user input data requesting to organize a second workload in the space, the second workload being associated with the first cloud computing service of the first entity ("FIGS. 13-17 illustrate example graphical user interfaces that may be provided by the cloud manager 138 to facilitate provisioning and configuration of a provisioned multi-machine blueprint. An example graphical user interface 1300 illustrated in FIG. 13 provides a listing of available resources (including multi-machine blueprints) that may be provisioned. After selecting a resource that is a multi-machine blueprint, the cloud manager 138 displays the user interface 1400 of FIG. 14 to allow configuration of the provisioning. The example illustrated in FIG. 14 includes the same components as the multi-machine blueprint 208 illustrated in FIG. 2. The user interface 1400 includes user interface elements 1402, 1404, and 1406 for specifying the settings to be used in provisioning the components of the multi-machine blueprint. The example, user interface elements 1402, 1404, and 1406 allow a user to specify a number of machines to be provisioned, a number of CPUs to be included, an amount of memory to be included, and an amount of storage to be included in each of the components of the multi-machine blueprint," Muller paragraph 0064; machines are provisioned with a blueprint workload in a cloud computing service);
based at least in part on the second user input data, importing second data associated with the second workload into the space ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, machines provisioned have app components that are installed on the machine (i.e., imported data associated with the workload));
receiving, via the first user interface or a second user interface, third user input data requesting to perform an action for the space ("The user interface 406 receives instructions from and conveys information to a user (e.g., the administrator 116 and/or the developer 118) of the resource manager 144. For example, the user interface 406 may provide an interface by which a user is to request that reclamation processing be performed (e.g., inactive and/or underused virtual machine resources should be identified)," Muller paragraph 0040); and
based at least in part on the third user input data:
determining a first workflow for the first workload ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, determining which VMs are unused/underused and removing the VMs);
causing the first workflow to be performed to implement the action for the first workload ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, determining which VMs are unused/underused and removing the VMs); and
determining a second workflow for the second workload ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, determining which VMs are unused/underused and removing the VMs);
causing the second workflow to be performed to implement the action for the second workload, the second workflow being different than the first workflow ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, determining which VMs are unused/underused and removing the VMs).
However Muller does not appear to explicitly disclose a second cloud computing service of a second entity.
Visconti teaches a second cloud computing service of a second entity ("FIGS. 3 and 4 are block diagrams illustrating example operational flows of the system 100 of FIG. 1 and the flowchart 200 of FIG. 2. In the example of FIG. 3, a first cloud provider 302 is illustrated as including and providing a plurality of virtual machines 304. Meanwhile, a second cloud provider 306 is illustrated as including and providing a plurality of virtual machines 308," Visconti paragraph 0065; "For example, continuing the example of FIG. 3 and FIG. 4, the first cloud provider 302 is illustrated as including a first group of virtual machines 402, the second group 404, and the third group 406. Meanwhile, the second cloud provider 306 is illustrated as including a first group 406 and a second group 408. In various implementations, groups may be formed within a single cloud provider, as shown in FIG. 4, or across multiple cloud providers," Visconti paragraph 0069; "Further in FIG. 4, a user 410, such as an administrator at the cloud consumer consuming the various virtual machines of cloud providers 302, 306 may apply tag base rules 412 to determine whether to provide approval of the generated power schedule and group formation predictions. As illustrated, the approval 414 may also include rule-based approval, not requiring human intervention," Visconti paragraph 0070).
Accordingly it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Muller to assign workflows and perform actions in multiple cloud computing services of multiple entities as taught by Visconti. One would have been motivated to make such a combination so that Muller’s management and resource reclaimer actions could be performed on all of a user’s workloads at the same time, thus resulting in greater utility for the user.
As to claim 2, Muller as modified by Visconti further discloses the system of claim 1, wherein: causing the first workflow to be performed comprises at least transmitting a first request to the first cloud computing service to alter a characteristic of a first computing resource associated with the first workload ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, resource reclaimer actions happen on all resources); and
causing the second workflow to be performed comprises at least transmitting a second request to the second cloud computing service to alter a characteristic of a second computing resource associated with the second workload ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037, resource reclaimer actions happen on all resources).
As to claim 3, Muller as modified by Visconti further discloses the system of claim 1, wherein:
the action comprises a parking action of setting a computing resource to an inactive state ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037; "Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120. Accordingly, resources associated with providing those virtual machines may be conserved," Visconti paragraph 0063);
the causing the first workflow to be performed comprises causing a first computing resource of the first cloud computing service to be set to the inactive state during a first period of time ("For each active-idle series of each virtual machine of the plurality of virtual machines, at least one periodicity of recurring idle times may be determined to exist within the observation time (208). For example, the periodicity detector 132 of the usage pattern detector 128 of FIG. 1 may be configured to analyze each active-idle series and execute one or more algorithms to determine whether and to what extent a periodicity exists. For example, depending on a length of time of the observation time, the periodicity detector 132 may detect one or more periods that are daily, weekly, or monthly," Visconti paragraph 0058; "Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120. Accordingly, resources associated with providing those virtual machines may be conserved," Visconti paragraph 0063); and
the causing the first workflow to be performed comprises causing a second computing resource of the second cloud computing service to be set to the inactive state during a second period of time ("For each active-idle series of each virtual machine of the plurality of virtual machines, at least one periodicity of recurring idle times may be determined to exist within the observation time (208). For example, the periodicity detector 132 of the usage pattern detector 128 of FIG. 1 may be configured to analyze each active-idle series and execute one or more algorithms to determine whether and to what extent a periodicity exists. For example, depending on a length of time of the observation time, the periodicity detector 132 may detect one or more periods that are daily, weekly, or monthly," Visconti paragraph 0058; "Each of the virtual machines with the at least one periodicity may be transitioned with the at least one periodicity between an on state and an off state in accordance with the predicted on/off model (212). For example, the power handler 140 may be configured to turn on, and turn off, any of the virtual machines 112/114 and 118/120. Accordingly, resources associated with providing those virtual machines may be conserved," Visconti paragraph 0063).
Accordingly it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Muller to park computing resources for a temporary period of time as taught by Visconti. One would have been motivated to make such a combination so that resources that are only periodically underutilized do not require constant user intervention to power up thus reducing the amount of work for the user.
As to claim 4, Muller as modified by Visconti further discloses the system of claim 3, wherein the operations further comprise:
receiving first data indicating a utilization of a first computing resource of the first cloud computing service ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037);
receiving second data indicating a utilization of a second computing resource of the second cloud computing service ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037);
determining that the first computing resource is underutilized based at least in part on the first data ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037);
determining that the second computing resource is underutilized based at least in part on the second data ("The resource reclaimer 402 of the illustrated example identifies potentially inactive, unused, underused, etc. resources by comparing an activity time to a threshold. For example, the resource reclaimer 402 may identify inactive resources by reviewing logs indicating the last time that a virtual machine was powered on, the last time that a virtual machine was remotely accessed, the amount of system resources consumed, etc. The information from the logs is analyzed (e.g., by comparing the information to a threshold) to determine if the virtual machine appears to be inactive and/or previsioned with excess resources (e.g., where four virtual machines are provisioned but only three are utilized). When the resource reclaimer 402 determines that a virtual machine may be inactive, the resource reclaimer 402 communicates the information to the notifier 404. Additionally or alternatively, the resource reclaimer 402 removes the virtual machine to free the computing resources currently assigned to the virtual machine (e.g., after a number of notifications have been sent and/or a user has confirmed that the virtual machine is no longer needed)," Muller paragraph 0037); and
providing a recommendation to perform the action ("The notifier 404 of the illustrated example notifies an owner of a virtual machine when the resource reclaimer 402 determines that the virtual machine is inactive. For example, the notifier 404 may send an email to the identified owner of the virtual machine. Alternatively, any other communication may be sent to the owner and/or the inactive machine may be identified on a list without sending a separate communication to the owner. The message may include information such as Machine Name, Virtual Machine Status, Reclamation Requestor, Machine Owner, Request Date, Reason for Reclamation Request, Daily Cost, Deadline to respond, etc. In example, where an email and/or other message is sent, the message may include a link or other user interface element that allows the user to indicate whether or not the identified virtual machine should remain in use," Muller paragraph 0039).
As to claim 6, Muller as modified by Visconti further discloses the system of claim 1, wherein:
the first user input data includes a request to create a new workload (“The example blueprint manager 140 of the illustrated example manages the creation of multi-machine blueprints that define the attributes of multiple virtual machines as a single container that can be provisioned, deployed, managed, etc. as a single unit,” Muller paragraph 0023; "FIGS. 13-17 illustrate example graphical user interfaces that may be provided by the cloud manager 138 to facilitate provisioning and configuration of a provisioned multi-machine blueprint. An example graphical user interface 1300 illustrated in FIG. 13 provides a listing of available resources (including multi-machine blueprints) that may be provisioned. After selecting a resource that is a multi-machine blueprint, the cloud manager 138 displays the user interface 1400 of FIG. 14 to allow configuration of the provisioning. The example illustrated in FIG. 14 includes the same components as the multi-machine blueprint 208 illustrated in FIG. 2. The user interface 1400 includes user interface elements 1402, 1404, and 1406 for specifying the settings to be used in provisioning the components of the multi-machine blueprint. The example, user interface elements 1402, 1404, and 1406 allow a user to specify a number of machines to be provisioned, a number of CPUs to be included, an amount of memory to be included, and an amount of storage to be included in each of the components of the multi-machine blueprint," Muller paragraph 0064 machines are provisioned with a blueprint workload that is newly created according to user request); and
the importing the first data associated with the first workload comprises:
based at least in part on the first user input data, provisioning a computing resource to implement the first workload ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, machines provisioned have app components that are installed on the machine (i.e., imported data associated with the workload)); and
associating the first data with the space ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, machines provisioned have app components that are installed on the machine (i.e., imported data associated with the workload)).
As to claim 7, Muller as modified by Visconti further discloses the system of claim 1, wherein:
the first user input data includes a request to import an existing workload ("FIGS. 13-17 illustrate example graphical user interfaces that may be provided by the cloud manager 138 to facilitate provisioning and configuration of a provisioned multi-machine blueprint. An example graphical user interface 1300 illustrated in FIG. 13 provides a listing of available resources (including multi-machine blueprints) that may be provisioned. After selecting a resource that is a multi-machine blueprint, the cloud manager 138 displays the user interface 1400 of FIG. 14 to allow configuration of the provisioning. The example illustrated in FIG. 14 includes the same components as the multi-machine blueprint 208 illustrated in FIG. 2. The user interface 1400 includes user interface elements 1402, 1404, and 1406 for specifying the settings to be used in provisioning the components of the multi-machine blueprint. The example, user interface elements 1402, 1404, and 1406 allow a user to specify a number of machines to be provisioned, a number of CPUs to be included, an amount of memory to be included, and an amount of storage to be included in each of the components of the multi-machine blueprint," Muller paragraph 0064 machines are provisioned with a blueprint workload from a template (i.e., an existing workload) according to user request); and
the importing the first data associated with the first workload comprises:
based at least in part on the first user input data, transmitting a request to the first cloud computing service to receive the first data associated with the first workload ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, machines provisioned have app components that are installed on the machine (i.e., imported data associated with the workload)); and
receiving, from the first cloud computing service, the first data associated with the first workload ("The example basic blueprint 126 of FIG. 1 may be assembled from items (e.g., templates) from a catalog 130, which is a listing of available virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 and available application components (e.g., software services, scripts, code components, application-specific packages) that may be installed on the provisioned virtual computing resources," Muller paragraph 0019, machines provisioned have app components that are installed on the machine (i.e., imported data associated with the workload)).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Muller et al. (US 20140165060 A1, hereinafter Muller) in view of Visconti et al. (US 20200209946 A1, hereinafter Visconti) in further view of Borthakur (US 20150347183 A1).
As to claim 5, Muller as modified by Visconti discloses the system of claim 4, however neither Muller nor Visconti appear to explicitly disclose a limitation wherein the operations further comprise:
generating a visualization that represents the underutilization of the first computing resource and the underutilization of the second computing resource.
Borthakur teaches a limitation wherein the operations further comprise:
generating a visualization that represents the underutilization of the first computing resource and the underutilization of the second computing resource (“workload 302 with resources 304 may have a resource usage graph 306 which indicates a large variation between the highest resource usage and the lowest resource usage,” Borthakur paragraph 0036; Borthakur Figure 3 306, 314, 322, 330).
Accordingly it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Muller to show underutilization visualizations as taught by Borthakur. One would have been motivated to make such a combination so that the user would have more information to use to determine whether to inactivate a resource thus resulting in greater ease of use for the user.
Claims 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Visconti et al. (US 20200209946 A1, hereinafter Visconti) in view of Honnavalli (US 20200241911 A1).
As to claim 13, Visconti discloses the method of claim 11, however Visconti does not appear to explicitly disclose a limitation wherein the determining the period of time comprises receiving user input data indicating the period of time for inactivity.
Honnavalli teaches a limitation wherein the determining the period of time comprises receiving user input data indicating the period of time for inactivity ("However, many VM instances are not required to be running when the user is not physically logged in or using the resources. In these instances, currently user can provide a schedule of when to stop and resume the VMs there by reducing the billing cost," Honnavalli paragraph 0023).
Accordingly it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Visconti to allow the user to specify the period of time through user input as taught by Honnavalli. One would have been motivated to make such a combination so that the user could specify his/her own period of time in situation where the calculated period of time is incorrect or not desired thus resulting in less frustration for the user.
As to claim 20, it is substantially similar to claim 13 and is therefore rejected using the same rationale as above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Visconti et al. (US 20200209946 A1, hereinafter Visconti) in view of Tung et al. (US 20110055712 A1).
As to claim 14, Visconti discloses the method of claim 8, however Visconti does not appear to explicitly disclose a limitation further comprising:
associating the group with a budget;
determining an amount spent on computing resources for implementing the first workload and the second workload; and
causing display of an indicating regarding the budget and the amount spent on the computing resources.
Tung teaches a limitation further comprising:
associating the group with a budget (“As shown in FIG. 26, region 2620 includes budget information associated with the usage data displayed in region 2610. For example, region 2620 may include a total budget (e.g., for the group of computing resources displayed in or selected using region 2630), total costs (e.g., based on the total usage of the provisioned computing resources by all users), and a remaining budget (e.g., determined based on the difference between the total budget and total costs),” Tung paragraph 0164”);
determining an amount spent on computing resources for implementing the first workload and the second workload (“As shown in FIG. 26, region 2620 includes budget information associated with the usage data displayed in region 2610. For example, region 2620 may include a total budget (e.g., for the group of computing resources displayed in or selected using region 2630), total costs (e.g., based on the total usage of the provisioned computing resources by all users), and a remaining budget (e.g., determined based on the difference between the total budget and total costs),” Tung paragraph 0164”); and
causing display of an indicating regarding the budget and the amount spent on the computing resources (“As shown in FIG. 26, region 2620 includes budget information associated with the usage data displayed in region 2610. For example, region 2620 may include a total budget (e.g., for the group of computing resources displayed in or selected using region 2630), total costs (e.g., based on the total usage of the provisioned computing resources by all users), and a remaining budget (e.g., determined based on the difference between the total budget and total costs),” Tung paragraph 0164”).
Accordingly it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Visconti to show the costs of a group of resources as taught by Honnavalli. One would have been motivated to make such a combination so that the user would have more information to use to determine whether to approve or deny Visconti’s power schedules thus resulting in greater ease of use for the user.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20160062780 A1 to Young et al. discloses pausing a virtual machine based on idle state where underutilization data is used to determine whether to pause a VM; and
US 20190087213 A1 to Matters et al. discloses workload management and distribution where virtual machines are parked according to underutilization.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL SAMWEL whose telephone number is (313) 446-6549. The examiner can normally be reached Monday through Thursday 8:00-6:00 EST.
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, Kieu Vu can be reached at (571) 272-4057. 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.
/DANIEL SAMWEL/Primary Examiner, Art Unit 2171
Prosecution Insights