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 .
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, 6, 9, 14, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Freimuth (US 8,806,489) and further in view of Byard (US 2023/0119926).
Regarding claim 1, Freimuth teaches: A method of managing an image of a virtual machine (VM) for deployment across a plurality of software-defined data centers (SDDCs), said method comprising:
separately uploading parts of the image to a cloud storage (col. 12:66-67 and col. 13:1-5, “Process 600 begins by receiving a new virtual machine image for publication on the image distribution network (step 610)” and “Responsive to receiving the new virtual machine image, process 600 divides the virtual machine image into chunks (step 620)”);
forming a complete image of the VM from the separately uploaded parts of the image (col. 14:6-10, “Process 600 then creates a virtual machine image reassembly file (step 660). The virtual machine instance reassembly file contains the unique resource identifiers for all the chunks of the virtual machine image”); and
downloading from the cloud storage the complete image of the VM to each of the SDDCs in which the VM is to be deployed (col. 15:10-11, “Process 800 begins by receiving a request to download a virtual machine image (step 810)” and col. 15:63-66, “responsive to determining that a sufficient number of chunks has been retrieved to instantiate the virtual machine image ("yes" at step 850), process 800 instantiates and starts the virtual machine image (step 860)”).
Freimuth does not teach as expressly as Byard discloses: separately uploading parts of a data object (¶ 27, “The virtual file 435 can be a collection of chunks 433, where each chunk 433-1, 433-2, 433-3, 433-4 is an individual object (e.g., file). Each uploaded chunk 433 of the file 403 can be stored in association with a timestamp (e.g., creation time) and a data range (e.g., a quantity of bytes of the virtual file)”).
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, as taught by Byard, in the same way to the VM image divided into chunks that is received at a publishing server, as taught by Freimuth. Both inventions are in the field of reconstituting virtual files divided into chunks, and combining them would have predictably resulted in “resumption of interrupted uploads,” as indicated by Byard (¶ 3).
Regarding claim 6, Freimuth teaches: The method of claim 1, further comprising: 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 (col. 10:16-20, “A virtual machine image reassembly file is created. Each of the chunks is assigned a unique resource locator address. An image distribution network server maintains a mapping between unique resource identifier for each of the chunks and the unique resource locator address”).
Claims 9, 14, and 17 recite commensurate subject matter as claims 1 and 6. Therefore, they are rejected for the same reasons.
Claim(s) 2, 10, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Freimuth and Byard, as applied above, and further in view of Cao (US 2019/0026138).
Regarding claim 2, Freimuth and Byard do not teach; however, Cao discloses: the parts of the image are uploaded from a repository for VM images to the cloud storage (¶ 64, “A content library is a repository for consumable software items, such as virtual machine (VM) templates and virtual application (vApp) templates, as well as other software items, such as ISO files, scripts and text files, for example” and ¶ 58, “at step 736, in response to the deploy API, the user interface opens a connection to the upload URL on the intelligent deployment module for a virtual machine disk image file of the OVA file”).
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 parts of the image are uploaded from a repository for VM images to the cloud storage, as taught by Cao, in the same way to the uploading, as taught by Freimuth and Byard. Both inventions are in the field of uploading VM images, and combining them would have predictably resulted in solving the problem of prior art systems that “require significant storage to temporary store the OVA template file,” as indicated by Cao (¶ 2).
Claim(s) 10 and 18 recite(s) commensurate subject matter as claim(s) 2. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 3, 11, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Freimuth, Byard, and Cao, as applied above, and further in view of Narayanan (US 9,197,702).
Regarding claim 3, Freimuth, Byard, and Cao do not teach; however, 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”).
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 multiple threads are executed concurrently to separately upload respective parts of the image to the cloud storage, as taught by Narayanan, in the same way to the uploading, as taught by Freimuth, Byard, and Cao. Both inventions are in the field of uploading VM images, and combining them would have predictably resulted in “an efficient process for uploading large files,” as indicated by Narayanan (col. 1:16-17).
Claims 11 and 19 recite commensurate subject matter as claim 3. Therefore, they 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 Freimuth and Byard, as applied above, and further in view of Jones (US 9,098,345).
Regarding claim 4, Freimuth and Byard 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 Freimuth and Byard. 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, Freimuth and Byard 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 Freimuth and Byard. 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) 7, 8, 15, 16, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Freimuth and Byard, as applied above, and further in view of Vembuli (US 10,574,524).
Regarding claim 7, Freimuth and Byard 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 Freimuth and Byard. 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).
Regarding claim 8, Freimuth and Byard 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 Freimuth and Byard. 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).
Claims 15, 16, and 20 recite commensurate subject matter as claims 7 and 8. Therefore, they are rejected for the same reasons.
Conclusion
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