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. 102/103 rejections of claims 1-20 have been fully considered but they are moot in light of the references being applied in the current rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 1, 2, 10, 11, 19, and 20 (line numbers refer to claim 1):
Lines 12-13 recite "the provisioning task" but it is unclear which provisioning task this refers to.
Claims 3-9 and 12-18 are dependent claims of claims 1 and 10 and fail to resolve the deficiencies of claims 1 and 10, so they are rejected for the same reasons.
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-12, 14, and 16-20 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 Velentzas et al. (US 20230004437 A1 hereinafter Velentzas).
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 the provisioning task.
However, Velentzas 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 the provisioning task (Tables on page 7 of the specification; [0071] Each of the temporary registers used by a task are therefore categorised as being static or dynamic and where they are dynamic they fall within the dynamic allocation and where they are static they fall within the static allocation.).
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 Velentzas to improve performance (see Velentzas [0142] The performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and/or reduced power consumption.).
As per claim 2, Razavi and Velentzas teach the method of claim 1. Velentzas teaches further comprising: 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 a presence or lack of a race condition associated with the provisioning task, one or more timing parameters associated with the provisioning task, or any combination thereof ([0080] By allocating the static allocation and the dynamic allocations from different pools of registers, it prevents deadlock from occurring where a task from one pass (pass B) has a sequential dependency on a task from the previous pass (pass A). This is because the static allocations, which are held for the entirety of the task, cannot interfere with the dynamic allocations, which are only held for the relevant phase of the task; [0071] Each of the temporary registers used by a task are therefore categorised as being static or dynamic and where they are dynamic they fall within the dynamic allocation and where they are static they fall within the static allocation).
As per claim 3, Razavi and Velentzas 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 Velentzas 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 Velentzas 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 Velentzas 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 Velentzas 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 11, 12, 14, 16, 17, and 18, they are apparatus claims of claims 2, 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.).
As per claim 20, it is a non-transitory computer-readable medium claim of claim 1, so it is rejected for similar reasons.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Razavi and Velentzas, 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 Velentzas teach the method of claim 1.
Razavi and Velentzas 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 Velentzas 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 Velentzas, 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 Velentzas teach the method of claim 5.
Razavi and Velentzas 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 Velentzas 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.
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