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, 3-10, and 12-17 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 § 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, 3-10, and 12-17 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.
The term “largest amount of input/output data” in claim 1 is a relative term which renders the claim indefinite. The term “largest amount” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Further, the term “largest” suggests relative to something else; however, the claim does not identify what input/output data is “largest” is relation to (e.g., there could be a plurality of other base VM images that producer a lesser amount of input/output data). Claims 3-10 and 12-17 recite commensurate subject matter as claim 1; therefore, they are rejected for the same reason. Appropriate correction is required.
Claim 9 recites the limitation “[t]he VM image management method of claim 2” in line 1. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, claim 9 is interpreted as depending on claim 1.
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-6, 9, 10, 12-15, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vembuli (US 2019/0140905) and further in view of Kulkarni (US 8,904,081) and further in view of Ha (US 2012/0122573).
Regarding claim 1, Vembuli teaches: A virtual machine (VM) image management method of providing high-performance virtual desktop services, which is performed by a computer, the method comprising:
receiving a request for a VM execution from a client corresponding to a user (¶ 38, “At 410, image manager 195 receives input from a user relating to a request for a VM 560”);
building a logical VM image from the user VM disk image in response to the request (¶ 40, “At 430, image manager 195 creates a virtual disk file for VM 560 that corresponds to or is a copy of base virtual disk file 556 of the base VM image”); and
providing a VM driven on the basis of the logical VM image to the client (¶ 41, “Having created the virtual disk file, VM 560 is then able to be instantiated and used by the user”),
wherein the building of the logical VM image from the user VM disk image in response to the request comprises building the logical VM image by overwriting the user VM disk image on the base VM image, wherein the base VM image has an operating system and application programs installed originally (¶ 41, “At 440, image manager 195 applies writes, previously performed to delta virtual disk file 554 of delta image 550, to the virtual disk file of VM 560 so that the virtual disk file then corresponds to the combination of base virtual disk file 556 and delta virtual disk file 554, as shown in FIG. 5”), and
the base VM image has an operating system and application programs installed originally (¶ 21, “Disk image files, such as virtual disk file 153, may be digital encodings of the contents of virtual disks and resource files may be digitally encoded content, such as operating-system images. A virtual machine or a collection of virtual machines encapsulated together within a virtual application can thus be digitally encoded as one or more flies within a VM image”).
Vembuli does not teach as clearly as Kulkarni discloses: providing a VM driven on the basis of the logical VM image to the client (col. 7:43-46, “operation 282 wherein a VM is provisioned based on a base disk image 262 and a user delta disk image 268, which is initially empty (does not contain any disk image data)”).
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 providing a VM driven on the basis of the logical VM image to the client, as taught by Kulkarni, in the same way to the method, as taught by Vembuli. Both inventions are in the field of building VM images, and combining them would have predictably resulted in “dynamically composing a virtual desktop that provides a user access to a selected application or applications in a virtualized computing environment,” as indicated by Kulkarni (col. 1:44-46).
Vembuli and Kulkarni do not teach; however, Ha teaches: the operating system and application programs of the base VM image generate a largest amount of input/output data (¶ 39, “When the user requests a virtual machine synchronization service, the distributed image server 110 transfers the virtual machine image using one of the servers, distributed over the network, which operates in the highest-performance bandwidth and has the lowest delay time”).
Regarding claim 3, Kulkarni teaches: The VM image management method of claim 2, wherein the building of the logical VM image from the user VM disk image in response to the request comprises:
loading a base VM image corresponding to the user VM disk image on a main memory (col. 7:21-23, “the virtual desktop management application 20 and/or an administrator selects base disk 262 that includes an OS installation for the virtual desktop”);
generating an empty image on a disk when there is no user VM disk image (col. 7:29-34, “The virtual desktop management application 20 and/or an administrator may also configure user delta disk image 268 to include user-specific customizations and settings 272 for the virtual desktop. Ordinarily, the user delta disk image file 268 is initially chained to the base disk image file 262 with no intervening disks, as shown in FIG. 2B,” here the VM is new and empty (no intervening disks from OS user modifications)); and
generating a link between the user VM disk image and the base VM image on the main memory (col. 6:33-35, “FIG. 2A shows delta disk 2 image 256 linked to delta disk 1 image 254 and then to base disk image 252”).
Regarding claim 4, Vembuli teaches: The VM image management method of claim 1, wherein, when a disk input/output in a kernel (¶ 45, “an abstraction layer is provided on top of the kernel of an operating system on a host computer”) of a user's VM is a write request, the building of the logical VM image from the user VM disk image in response to the request comprises:
performing a write operation on a requested block in the user VM disk image (¶ 30, “At 330, image manager 195 performs write operations to the delta virtual disk file corresponding to the changes made by the user to the state of the VM's virtual disk”); and
Kulkarni teaches: storing a block usage record for the block in the user VM disk image (col. 3:46-48, “VMM 204 receives disk I/O block requests and translates them into file-level accesses on a network datastore as described in more detail below”).
Regarding claim 5, Kulkarni teaches: The VM image management method of claim 1, wherein, when a disk input/output in a kernel of a user's VM is a read request (col. 3:51-53, “upon receiving a file system block level request to read or write data to virtual disk 220”), the building of the logical VM image from the user VM disk image in response to the read request comprises:
checking whether there is a block corresponding to the read request in the user VM disk image (col. 9:11-14, “Upon receiving a read request for data that is stored within a chained virtual disk from guest OS 208, block driver 228 in hypervisor 214, may determine the location of the requested data”); and
when there is the block corresponding to the read request, performing a read operation on a requested block in the user VM disk image (col. 9:14-16, “may determine the location of the requested data and its offset within the chained virtual disk in order to access the data”).
Regarding claim 6, Kulkarni teaches: The VM image management method of claim 5, wherein, when a result of the checking reveals that there is no block corresponding to the read request, the building of the logical VM image from the user VM disk image in response to the request comprises performing a read operation on the requested block in the base VM image loaded on the main memory (col. 6:24-28, “Reads are directed to delta disk 1 image 254, and if the requested data is not present in delta disk 1 image 254, e.g., because the data at the requested read location has not been modified since the snapshot was taken, base virtual disk image 252 is accessed to satisfy the read request”).
Regarding claim 9, Kulkarni teaches: The VM image management method of claim 2, wherein, when the request for the VM execution is made for a first time (col. 7:20-23, “To provision a new virtual desktop, the virtual desktop management application 20 and/or an administrator selects base disk 262 that includes an OS installation for the virtual desktop”), the providing of the VM driven on the basis of the logical VM image to the client comprises designating the user VM image as an unused state (col. 7:49-52, “If Agent 270 is not already present in base disk image 262 as shown in FIG. 2B, then agent 270 may at this time be installed on the VM, in which case it will be stored in the user delta disk image 268”) and linking location information of the base VM image to the user VM image (col. 9:1-3, “a base disk image 262 that includes guest OS 208 linked to one or more application delta disks images 274”).
Claims 10, 12-15, and 17 recite commensurate subject matter as claims 1-6 and 9. Therefore, they are rejected for the same reasons.
Claim(s) 7, 8, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vembuli, Kulkarni, and Ha, as applied above, and further in view of Yan (US 2011/0197053).
Regarding claim 7, Kulkarni teaches: The VM image management method of claim 2, wherein the providing of the VM driven on the basis of the logical VM image to the client comprises:
linking location information of the base VM image to the user VM image (col. 9:1-3, “a base disk image 262 that includes guest OS 208 linked to one or more application delta disks images 274”).
Vembuli, Kulkarni, and Ha do not teach; however, Yan discloses: decompressing the user VM disk image to build a user VM image (¶ 22, “the system extracts the virtual image to the target physical computer's physical data storage (e.g., a hard disk or flash drive). This may include copying files, decompressing compressed data”).
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 decompressing the user VM disk image to build a user VM image, as taught by Yan, in the same way to the user VM disk image, as taught by Vembuli, Kulkarni, and Ha. Both inventions are in the field of building VM images, and combining them would have predictably resulted in “copying, decompressing, and decrypting the virtual image contents,” as indicated by Yan (claim 6).
Regarding claim 8, Vembuli teaches: The VM image management method of claim 7, wherein the providing of the VM driven on the basis of the logical VM image to the client comprises: checking whether the base VM image corresponding to a user VM disk image built for a service of the VM is stored in the main memory (¶ 35, “all VM images (i.e., base and delta VM images etc.) created are stored in persistent storage 197 such that any user with access to server 190 is able to use the images to deploy VMs including operating systems and/or software applications that the user desires”); and when a result of the checking reveals that there is no base VM image, loading the base VM image on the main memory (¶ 42, “image manager 195 again creates a virtual disk file for the VM that corresponds to or is a copy of the base virtual disk file of the base VM image”).
Claim 16 recites commensurate subject matter as claim 18; therefore, it is 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, Lewis Bullock can be reached at 5712723759. 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 2199