DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Response to Arguments
Applicant's arguments regarding the 35 U.S.C. 112b rejections of claims 1-20 have been fully considered and are persuasive. The rejections have been withdrawn.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of claims 1-20 have been fully considered but they are moot.
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, 3, 5, 7, 10, 12, 14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Razavi et al. (Prebaked µVMs: Scalable, Instant VM Startup for IaaS Clouds hereinafter Razavi) in view of Yang et al. (US 20070118636 A1 hereinafter Yang).
Razavi was cited in a prior office action.
As per claim 1, Razavi teaches a method for instantiating a software instance in a multi-phase provisioning procedure comprising a plurality of provisioning tasks (Fig. 2; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup; Section I paragraph 5 To avoid such combinatorial explosion, we propose to use prebaked μVMs instead. A μVM is a snapshot of a booted VM with minimal hardware resources, in our case a single CPU core and 512 MB of RAM. μVMs are relatively small, lowering storage requirements. We are using hardware hot-plugging for adding resources of larger machine types (CPU cores and memory) as part of the resume process, at the actual VM Startup time.), comprising:
identifying a first subset of provisioning tasks of the plurality of provisioning tasks associated with a first phase of the multi-phase provisioning procedure and a second subset of provisioning tasks of the plurality of provisioning tasks associated with a second phase of the multi-phase provisioning procedure, wherein the plurality of provisioning tasks configure features and metadata of the software instance (Fig. 2; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources; Section I paragraph 5 To avoid such combinatorial explosion, we propose to use prebaked μVMs instead. A μVM is a snapshot of a booted VM with minimal hardware resources, in our case a single CPU core and 512 MB of RAM. μVMs are relatively small, lowering storage requirements. We are using hardware hot-plugging for adding resources of larger machine types (CPU cores and memory) as part of the resume process, at the actual VM Startup time; Section V.A. paragraph 2 Figure 7 shows the startup times using μVMs stored on the local ext4 drive, and hot-plugging up to 7 cores (total: 8 cores), and 15.5 GB (total: 16 GB) of memory; Section V.A. paragraph 3 The information on the final number of cores and amount of memory is made available as part of contextualization in case user applications need it; Section IV.C. paragraph 2 For this purpose, we decided to contextualize our μVMs using a hot-pluggable hard disk. In parallel to resuming the VM, we create a file with the required contextualization information, and attach it to the μVM.), and
wherein each provisioning task of the plurality of provisioning tasks is associated with a respective one or more dynamicity characteristics; the first subset of provisioning tasks or the second subset of provisioning tasks (Fig. 2; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources; Section III.B. paragraph 2 it also allows for more dynamic “physical” resource allocation to guest OSes, termed resource hot-plugging; Section IV.E. paragraph 3 we decided to contextualize our μVMs using disk hot-plugging; Section I paragraph 5 To avoid such combinatorial explosion, we propose to use prebaked μVMs instead. A μVM is a snapshot of a booted VM with minimal hardware resources, in our case a single CPU core and 512 MB of RAM);
running the first subset of provisioning tasks on a plurality of software instances of a pool of software instances prior to a provisioning request for the software instance (Fig. 2; Section VII paragraph 2 we introduce prebaked μVMs, booted VMs with minimal resources (a single CPU core and 512 MB memory); Section III.B. paragraph 3We have implemented a service, called the VM Bakery, that runs on the hosts, and employs resource hot-plugging to extend a μVM to the tenant-requested size. Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources);
receiving, from a user, the provisioning request (Section I paragraph 4 a user wishes to start one or more VMs from this image; Section III.B. paragraph 3 We have implemented a service, called the VM Bakery, that runs on the hosts, and employs resource hot-plugging to extend a μVM to the tenant-requested size; Section III paragraph 1 takes as input a μVM, and outputs a VM according to the requested user configuration);
running, based at least in part on the provisioning request and on the software instance from the pool of software instances, the second subset of provisioning tasks, wherein the second subset of provisioning tasks are specific to the user (Section III.B. paragraph 1 μVMs by themselves are not suited for running user applications as they lack resources. We hence need a mechanism for adding resources to μVMs; Section IV.C. paragraph 3 Right after contextualization, depending on the requested instance type, VM bakery starts hot-plugging CPU cores, and a memory device with the necessary size; Section III.B. paragraph 3We have implemented a service, called the VM Bakery, that runs on the hosts, and employs resource hot-plugging to extend a μVM to the tenant-requested size. Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources; Section IV paragraph 1 Our Implementation of μVMs allows providers to reuse the precomputed (“prebaked”) OS state by several, concurrently started VMs during the VM Startup process based on VM resume); and
provisioning the software instance to the user (Section III paragraph 1 outputs a VM according to the requested user configuration; Section III.B. paragraph 3 make the VM available to the user).
Razavi fails to teach assigning each provisioning task of the plurality of provisioning tasks to the first subset of provisioning tasks or the second subset of provisioning tasks based at least in part on the respective one or more dynamicity characteristics of each provisioning task.
However, Yang teaches assigning each provisioning task of the plurality of provisioning tasks to the first subset of provisioning tasks or the second subset of provisioning tasks based at least in part on the respective one or more dynamicity characteristics of each provisioning task ([0009] Methods of provisioning network resources using a bandwidth broker are broadly categorized into a static provisioning method and a dynamic provisioning method. ).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Razavi with the teachings of Yang to improve efficiency (see Yang [0071] Referring to FIG. 5A, regarding the efficiency of bandwidth resource utilization, a provisioning method 502 according to an embodiment of the present invention uses bandwidth resources more stably and efficiently than a conventional static provisioning method 501.).
As per claim 3, Razavi and Yang teach the method of claim 1. Razavi teaches further comprising: dividing a first provisioning task into a first provisioning subtask and a second provisioning subtask based at least in part on one or more dynamicity characteristics of the first provisioning task, a presence or lack of a race condition associated with the first provisioning task, or both; assigning the first provisioning subtask to the first subset of provisioning tasks; and assigning the second provisioning subtask to the second subset of provisioning tasks (Fig. 2; Section III.B. paragraph 2 it also allows for more dynamic “physical” resource allocation to guest OSes, termed resource hot-plugging; Section II. Paragraph 3 Contextualization makes the VM unique from other VMs that have started from the same base VM image; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources by interacting with the VMM process in control of the μVM. Effectively, the VM bakery moves the device assignment to the very end of the VM Startup process, making it possible to reuse the precomputed OS state of μVMs.).
As per claim 5, Razavi and Yang teach the method of claim 1. Razavi teaches further comprising: running the first subset of provisioning tasks based at least in part on one or more provisioning templates stored in a provisioning template database (Fig. 2; Section I paragraph 4 We propose to pre-boot a VM image in advance and to take a snapshot that can be resumed from whenever a user wishes to start one or more VMs from this image; μVMs are small; Section V.B. paragraph 1 The average size of a μVM from our Windows Azure repository is only 275 MB; Abstract store uVMs for large numbers of VM images on the hosts of a data center.).
As per claim 7, Razavi and Yang teach the method of claim 1. Razavi teaches further comprising: updating one or more aspects of the software instance associated with the second subset of provisioning tasks based at least in part on receiving an update command (Fig. 2; Section III.B. paragraph 3We have implemented a service, called the VM Bakery, that runs on the hosts, and employs resource hot-plugging to extend a μVM to the tenant-requested size. Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources).
As per claim 8, Razavi and Yang teach the method of claim 1. Razavi teaches wherein the plurality of provisioning tasks comprise one or more software instance setting configuration tasks, one or more software instance layout tasks, one or more software instance metadata tasks, or any combination thereof (Fig. 2; Section II paragraph 3After the VM passes through BIOS that detects some of the available hardware, specially bootable storage, the appropriate bootloader starts. After a configurable timeout, the OS kernel is loaded into memory, and starts initialization of various devices such as cores, memory, disk drives, and so on. After that, the OS starts the configured services such as SSH (or RDP on Windows).).
As per claim 9, Razavi and Yang teach the method of claim 1. Razavi teaches further comprising: receiving a user survey report indicating one or more configuration preferences associated with the second subset of provisioning tasks, wherein running the second subset of provisioning tasks is based at least in part on the user survey report (Section III paragraph 1 We introduce μVM, a building block for reusable OS state in Section III-A. We then describe VM bakery in Section III-B, a service that runs on the hosts, and takes as input a μVM, and outputs a VM according to the requested user configuration; Section III.B. paragraph 3We have implemented a service, called the VM Bakery, that runs on the hosts, and employs resource hot-plugging to extend a μVM to the tenant-requested size. Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup. Upon a VM Startup request, the VM bakery resumes the μVM and contextualizes it. Immediately after contextualization, the VM bakery starts hot-plugging core and memory resources).
As per claim 10, it is an apparatus claim of claim 1, so it is rejected for similar reasons. Additionally, Razavi teaches an apparatus for instantiating a software instance in a multi-phase provisioning procedure comprising a plurality of provisioning tasks, comprising: a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to (Fig. 2; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup; Section I paragraph 5 To avoid such combinatorial explosion, we propose to use prebaked μVMs instead. A μVM is a snapshot of a booted VM with minimal hardware resources, in our case a single CPU core and 512 MB of RAM. μVMs are relatively small, lowering storage requirements. We are using hardware hot-plugging for adding resources of larger machine types (CPU cores and memory) as part of the resume process, at the actual VM Startup time; Abstract To serve uVMs, we extend our VM boot cache service, Squirrel, allowing to store uVMs for large numbers of VM images on the hosts of a data center; Section III paragraph 1 We introduce μVM, a building block for reusable OS state in Section III-A. We then describe VM bakery in Section III-B, a service that runs on the hosts, and takes as input a μVM, and outputs a VM according to the requested user configuration; Hosts in a data center include a processor and memory coupled with the processor that includes instructions.).
As per claims 12, 14, 16, 17, and 18, they are apparatus claims of claims 3, 5, 7, 8, and 9, so they are rejected for similar reasons.
As per claim 19, it is a non-transitory computer-readable medium claim of claim 1, so it is rejected for similar reasons. Additionally, Razavi teaches a non-transitory computer-readable medium storing code for instantiating a software instance in a multi-phase provisioning procedure comprising a plurality of provisioning tasks, the code comprising instructions executable by a processor (Fig. 2; Section III.B. paragraph 3 Figure 2 shows how VM Startup looks like with VM bakery. The blue steps are precomputed and are what constitutes a μVM, and the red steps happen during the actual VM Startup; Section I paragraph 5 To avoid such combinatorial explosion, we propose to use prebaked μVMs instead. A μVM is a snapshot of a booted VM with minimal hardware resources, in our case a single CPU core and 512 MB of RAM. μVMs are relatively small, lowering storage requirements. We are using hardware hot-plugging for adding resources of larger machine types (CPU cores and memory) as part of the resume process, at the actual VM Startup time; Abstract To serve uVMs, we extend our VM boot cache service, Squirrel, allowing to store uVMs for large numbers of VM images on the hosts of a data center; Section III paragraph 1 We introduce μVM, a building block for reusable OS state in Section III-A. We then describe VM bakery in Section III-B, a service that runs on the hosts, and takes as input a μVM, and outputs a VM according to the requested user configuration; Hosts in a data center include a processor and a non-transitory computer-readable medium storing code.).
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Razavi and Yang, as applied to claims 1 and 10 above, in view of Otto et al. (US 11765651 B1 hereinafter Otto).
Otto was cited in a prior office action.
As per claim 4, Razavi and Yang teach the method of claim 1.
Razavi and Yang fail to teach further comprising: determining that a first attempt to run a first provisioning task of the first subset of provisioning tasks has failed or was not performed; and assigning the first provisioning task to the second subset of provisioning tasks; wherein running the second subset of provisioning tasks comprises running a second attempt to run the first provisioning task.
However, Otto teaches further comprising: determining that a first attempt to run a first provisioning task of the first subset of provisioning tasks has failed or was not performed; and assigning the first provisioning task to the second subset of provisioning tasks; wherein running the second subset of provisioning tasks comprises running a second attempt to run the first provisioning task (Col. 12 lines 3-15 After the iteration has finished, the hierarchical provisioning connector 304 may rank the stored response types by severity and return the most severe response type to the provisioning service. That is, if one or more single provisioning connectors returned a fatal error, then the hierarchical provisioning connector 304 may return a fatal error, while if and only if all single provisioning connectors returned success, the hierarchical provisioning connector 304 may return success. This behavior causes the provisioning service to retry the provisioning request in the manner needed to correct the most severe provisioning failure; Col. 17 lines 55-58 invoke each single provisioning connector, and store responses in a map which is indexed by response type; and return the most severe provisioning failure to the provisioning service).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Razavi and Yang with the teachings of Otto to retry provisioning failures (see Otto Col. 12 lines 12-15 This behavior causes the provisioning service to retry the provisioning request in the manner needed to correct the most severe provisioning failure).
As per claim 13, it is an apparatus claim of claim 4, so it is rejected for similar reasons.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Razavi and Yang, as applied to claims 5 and 14 above, in view of Pei et al. (US 20210029222 A1 hereinafter Pei).
Pei was cited in a prior office action.
As per claim 6, Razavi and Yang teach the method of claim 5.
Razavi and Yang fail to teach further comprising: storing an indication of the first subset of provisioning tasks in an additional provisioning template in the provisioning template database based at least in part on running the first subset of provisioning tasks and determining that the first subset of provisioning tasks is not included in any of the one or more provisioning templates.
However, Pei teaches further comprising: storing an indication of the first subset of provisioning tasks in an additional provisioning template in the provisioning template database based at least in part on running the first subset of provisioning tasks and determining that the first subset of provisioning tasks is not included in any of the one or more provisioning templates ([0014] In another example, a method comprising storing, by a memory of a first network device, a seed image, wherein the seed image includes instructions to communicate with devices of a predetermined device type, and wherein the seed image excludes instructions to provision the first network device to be fully operational in a network environment… replacing, by the processor, the seed image with the full version of the product image; and provisioning, by the processor, the first network device to a particular device type corresponding to the network environment that includes the at least one device of the predetermined device type using the full version of the product image; [0015] In another example, a non-transitory computer readable storage medium storing a seed image; [0025] a full version of the product image of various network devices of the predetermined device type may be released and uploaded to a cloud server and/or a local server).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Razavi and Yang with the teachings of Pei so that an image (template) allows a device to be fully operational (see Pei [0009] Full version of the product image (i.e.; software) can provision the device to be fully operational).
As per claim 15, it is an apparatus claim of claim 6, so it is rejected for similar reasons.
Allowable Subject Matter
Claim 2, 11, 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights