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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 9-11, and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beda (US 2013/0263131) and further in view of Narayanan (US 9,197,702).
Regarding claim 1, Beda teaches: A method of managing an image of a virtual machine (VM) for deployment across a plurality of software-defined data centers (SDDCs) (¶ 4, “Multiple datacenters in distant regions around the globe can be coordinated through multiple cluster managers and a global database of virtual machine configuration information to manage resources of a virtual machine system”), said method comprising:
(¶ 4, “a user can upload a virtual machine image in a first region”);
downloading from the cloud storage the complete image of the VM to each of the SDDCs in which the VM is to be deployed (¶ 28, “”, “the communication process can initialize VMs on a host machine by downloading a VM image from a VM image repository 130 over a communication network” and ¶ 49, “The VM image repository 318 responds with the requested virtual machine image (325), and the cluster manager A 312 forwards the virtual machine image to cluster manager B 324 (330)” and “Cluster manager B 324 receives the virtual machine image (330) and stores the received virtual machine image in a local VM image repository 326 (335)”).
Beda does not teach, however, Narayanan teaches: separately uploading parts of a data object (col. 6:58-60, “At block 302, a sending device may determine an upload chunk size. And upload chunk size may include a portion of the total size of a file to be uploaded” and col. 7:63-65, “At block 314, the chunks that have been prepared for upload may be uploaded to the receiving server using an available HTTP connection to the receiving server”); and
in response to completion of uploading all parts of an object (col. 8:32-33, “At block 318, the sending device may determine if all chunks have been uploaded”), forming a complete object from the separately uploaded parts of the object (col. 8:44-47, “If it is determined that all chunks have been uploaded, in block 320, the sending device may execute a finalize command to facilitate consolidation of the uploaded chunks into one file on the receiving server-side”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of separately uploading parts of a data object; and in response to completion of uploading all parts of an object forming a complete object from the separately uploaded parts of the object, as taught by Narayanan, in the same way to the uploading a VM image, as taught by Beda. Both inventions are in the field of uploading objects, and combining them would have predictably resulted in “an efficient process for uploading large files,” as indicated by Narayanan (col. 1:16-17).
Regarding claim 2, Beda teaches: the parts of the image are uploaded from a repository for VM images to the cloud storage (¶ 39, “a virtual machine image being available in a region means that the VM image is either stored locally in a VM image repository in the region or is running on a host machine in that region”).
Regarding claim 3, Narayanan discloses: multiple threads are executed concurrently to separately upload respective parts of the image to the cloud storage (col. 1:61-64, “The sending device may then invoke separate threads in parallel, where the media file may be read into a byte buffer array having the size of the maximum chunk size to produce a smaller chunk”).
Claim(s) 9-11 and 17-19 recite(s) commensurate subject matter as claim(s) 1-3. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 4, 5, 12, and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beda and Narayana, as applied above, and further in view of Jones (US 9,098,345).
Regarding claim 4, Beda and Narayana do not teach; however, Jones discloses: the SDDCs in which the VM is to be deployed include a first SDDC that is provisioned in a first data center to which the complete image of the VM is downloaded from the cloud storage (col. 2:65-67 and col. 3:1-3, “The management workstation 14 is the primary system used to capture the images of dedicated servers 16 and virtual servers (cloud computing instances or CCI) 18, which form the cloud store 20 of the data center. The cloud store 20 represents the computing and data storage resource accessible to the end users”) and a second SDDC that is provisioned in a second data center to which the complete image of the VM is downloaded from the cloud storage (col. 3:30-35, “The integrated management system 12 is further in communications with the management workstation 14 at Data Center Dallas, and the cloud stores 20, 20', 20'' of Data Center Dallas, as well as secondary data centers, including Data Center Seattle, Data Center Amsterdam, and other data centers in the system”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the SDDCs in which the VM is to be deployed include a first SDDC that is provisioned in a first data center to which the complete image of the VM is downloaded from the cloud storage and a second SDDC that is provisioned in a second data center to which the complete image of the VM is downloaded from the cloud storage, as taught by Jones, in the same way to the uploading, as taught by Beda and Narayana. Both inventions are in the field of uploading VM images, and combining them would have predictably resulted in a system that enables “deployment to both dedicated and virtual servers,” as indicated by Jones (col. 1:9).
Regarding claim 5, Beda and Narayana do not teach; however, Jones discloses: the cloud storage is located in a first data center and contents of the cloud storage are auto-replicated to a replica cloud storage that is located in a second data center (col. 3:49-51, “store the captured image at any cloud store (data center) location, and deploy the captured image to any existing or new dedicated or virtual server at any data center”), and the SDDCs in which the VM is to be deployed include a first SDDC to which the complete image of the VM is downloaded from the cloud storage in the first data center and a second SDDC to which the complete image of the VM is downloaded from the replica cloud storage in the second data center (col. 4:36-38, “Continuing with FIG. 3, in block 56, the user selected image is deployed to the data center selected by the user to a dedicated or virtual server.”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the cloud storage is located in a first data center and contents of the cloud storage are auto-replicated to a replica cloud storage that is located in a second data center, and the SDDCs in which the VM is to be deployed include a first SDDC to which the complete image of the VM is downloaded from the cloud storage in the first data center and a second SDDC to which the complete image of the VM is downloaded from the replica cloud storage in the second data center, as taught by Jones, in the same way to the uploading, as taught by Beda and Narayana. Both inventions are in the field of uploading VM images, and combining them would have predictably resulted in a system that enables “deployment to both dedicated and virtual servers,” as indicated by Jones (col. 1:9).
Claims 12 and 13 recite commensurate subject matter as claims 4 and 5. Therefore, they are rejected for the same reasons.
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beda and Narayana, as applied above, and further in view of Liu (US 11,467,920).
Regarding claim 6, Beda and Narayana do not teach, however, Liu teaches: extracting metadata of the VM from the complete image of the VM (col. 5:51-56, “metadata generation logic 384 may parse VM disk data 390 and/or snapshot differencing data 391 (e.g., one or more consistent states) to extract and obtain file metadata (also referred to as file-level metadata) corresponding to content files (or data objects) of one or more VMs (e.g., VMs 409-411)”) and storing the metadata of the VM in a database that contains metadata of all VMs that have a complete image thereof stored in the cloud storage (col. 6:14-16, “Metadata generation logic 384 may store the extracted file metadata as part of metadata catalog 392 (e.g., a set of tables)”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of extracting metadata of the VM from the complete image of the VM and storing the metadata of the VM in a database that contains metadata of all VMs that have a complete image thereof stored in the cloud storage, as taught by Liu, in the same way to the completed image of the VM, as taught by Beda and Narayana. Both inventions are in the field of storing VMs in a cloud, and combining them would have predictably resulted in “index file data of virtual machine (VM) image,” as indicated by Liu (col. 1:8-9).
Claim(s) 14 recite(s) commensurate subject matter as claim(s) 6. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 7, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beda, Narayana, and Liu, as applied above, and further in view of Vembuli (US 10,574,524).
Regarding claim 7, Beda and Narayana do not teach; however, Vembuli discloses: the metadata of the VM includes a version number of the image of the VM (col. 6:66-67 and col. 7:1-2, “the metadata includes an identifier of the delta VM image, where the identifier may be a short description about the delta VM image corresponding to the changes made by the user to the state of the VM (e.g., APP v1)”), and resource requirements for running the VM (col. 4:33-36, “meta information about all of the logical networks included in the OVF package, and a collection of virtual-machine configurations which further includes hardware descriptions of each virtual machine”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the metadata of the VM includes a version number of the image of the VM, and resource requirements for running the VM, as taught by Vembuli, in the same way to the uploading, as taught by Beda, Narayana, and Liu. Both inventions are in the field of managing VM images, and combining them would have predictably resulted in “metadata information [that] makes delta VM image uniquely identifiable such that they may be searched for and used for creating VMs,” as indicated by Vembuli (abstract).
Claim(s) 15 and 20 recite(s) commensurate subject matter as claim(s) 7. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beda and Narayana, as applied above, and further in view of Vembuli (US 10,574,524).
Regarding claim 8, Beda and Narayana do not teach; however, Vembuli discloses: the image of the VM is packaged as an open virtualization format (OVF) image (col. 4:14-19, “One public standard for virtual-machine encapsulation is referred to as the “open virtualization format” (“OVF”). The OVF standard specifies a format for digitally encoding a virtual machine within one or more data files, which may be referred to as a VM image”), an open virtualization appliance (OVA) image, or an international standard organization (ISO) image.
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the image of the VM is packaged as an open virtualization format (OVF) image, as taught by Vembuli, in the same way to the uploading, as taught by Beda and Narayana. Both inventions are in the field of managing VM images, and combining them would have predictably resulted in “metadata information [that] makes delta VM image uniquely identifiable such that they may be searched for and used for creating VMs,” as indicated by Vembuli (abstract).
Claim(s) 16 recite(s) commensurate subject matter as claim(s) 8. Therefore, it/they is/are rejected for the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pierre Vital can be reached at (571) 272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights