DETAILED ACTION
This office action is in response to claims filed 18 June 2026.
Claims 1-22 are pending.
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 .
Allowable Subject Matter
Claims 6-10 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.
Response to Arguments
Applicant's arguments filed 18 June 2026 regarding the rejections made under 35 USC § 102 have been fully considered but they are not persuasive.
On pages 7-8 of the remarks, the applicant argues:
“Santhiveeran discloses ‘[a] portable computing device comprising a first hypervisor…to…provide, via the connection, access to the first virtual machine to enable the computing system to execute the first virtual machine…Thus, the first hypervisor of Santhiveeran, which is running on a ‘portable computing device,’ can instruct a different computing system to (a) execute a virtual machine and (b) generate a snap shot of the virtual machine.”
“…First, the ‘first hypervisor’ of Santhiveeran does not execute on a ‘host computing system’ and does not ‘implement[]…the virtual machine…” Rather, the first hypervisor of Santhiveeran executes on a ‘portable computing device’ which does not host a virtual machine and therefore is not a ‘host computing system”
The examiner respectfully disagrees. SANTHIVEERAN teaches a technique of migrating an executing virtual machine from a portable computing device acting as a first host, to a computing system acting as a second host. Applicant’s cited portion of SANTHIVEERAN explicitly teaches this, but was omitted from the quotation in the argument: “A portable computing device comprising: a first hypervisor executing a first virtual machine” (Column 6, Lines 54-55, emphasis added). That the first hypervisor implements a first virtual machine executing on hardware of a host portable computing device prior to migration to a computing system is also illustrated in Fig. 1:
PNG
media_image1.png
512
802
media_image1.png
Greyscale
Thus, applicant’s argument is not persuasive.
On pages 8 of the remarks, the applicant argues:
“Second, Santhiveeran does not disclose ‘creating, by the hypervisor, a snapshot of the virtual machine.’ Rather, Santhiveeran discloses instructing a different computing system (e.g., the computing system actually hosting the virtual machine) to create a snapshot of the virtual machine. The Patent Office acknowledges this deficiency in the Office Action, and explains that the ‘first hypervisor causes the final snapshot to be generated or ‘created’ by the computing system.’ Office Action, p. 3. However, Applicant’s claim 1 does not recite causing a snapshot to be created by some other computing system. Applicant’s claim 1 recites ‘creating, by the hypervisor, a snapshot of the virtual machine’. Accordingly, Applicant respectfully submits that Santhiveeran fails to anticipate each and every limitation of Applicant’s claim 1.”
The examiner respectfully disagrees. 1) As discussed above, SANTHIVEERAN’s portable computing system is a host because it executes both a virtual machine and an underlying hypervisor that provides an interface between the virtual machine and underlying portable computing system hardware (see Fig. 1). 2) While applicant’s claim does not recite causing a snapshot to be created by some other computing system, applicant’s claim only recites that the snapshot is created “by the hypervisor” and does not specify whether the snapshot is created in the host computing system or some other system. In other words, under the broadest reasonable interpretation, so long as the hypervisor “creates” the snapshot, this limitation is met, regardless of whether the snapshot is created within a host computer system, or some other computer system. SANTHIVEERAN explicitly teaches this in Column 7, Lines 11-14, where the hypervisor executing on the portable computing system causes the portable computing system to: “In response to determining that the connection is to be disconnected, send a snap shot signal to the computing system to cause the computing system to generate a final snap shot of the virtual machine.” In other words, the hypervisor executing within the portable computing system initiates creation of, or “creates” the snap shot by sending the snap shot signal to the computing system. Since SANTHIVEERAN teaches the broadest reasonable interpretation of the claim, this argument is not persuasive.
Applicant’s additional arguments regarding the new claims are moot because they do not specifically challenge the new reference (YE, cited below) used to reject the new claims in the current rejection.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 12-13, 15-17 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by SANTHIVEERAN et al. Patent No.: US 9,052,965 B2 (hereafter SANTHIVEERAN).
SANTHIVEERAN was cited previously.
Regarding claim 1, SANTHIVEERAN teaches:
A method, comprising:
causing, by a hypervisor executing on a host computing system, an existing connection between a virtual machine implemented by the hypervisor and an entity separate from the virtual machine to close ([Column 6, Line 54-Column 7, Line 21] A portable computing device (i.e., “host system”) comprising: a first hypervisor executing a first virtual machine (i.e., first virtual machine is “implemented” by the first hypervisor on the portable computing device) according to a set of executed instructions in order to cause the portable computing device to: establish a connection with a computing system (i.e., “entity” separate from the virtual machine)…determine that the connection, between the portable computing device and the computing system, is to be disconnected…release the lock and disconnect with the computing system (i.e., first hypervisor determines to close the connection, which “causes” the connection to be closed subsequently by the first hypervisor)); and
creating, by the hypervisor, a snapshot of the virtual machine ([Column 7, Lines 11-14] In response to determining that the connection is to be disconnected, send a snap shot signal to the computing system to cause the computing system to generate a final snap shot of the first virtual machine (i.e., first hypervisor causes the final snap shot to be generated or “created” by the computing system following the determination to close the connection, which “causes” the connection to be closed)).
Regarding claim 2, SANTHIVEERAN further teaches:
prior to causing the existing connection between the virtual machine and the entity separate from the virtual machine to close, the method comprises:
determining, by the hypervisor, that the existing connection exists between the virtual machine and the entity separate from the virtual machine ([Column 6, Lines 64-65] Generate a prompt on the portable computing device that the connection is established (i.e., the prompt represents a confirmation generated by the first hypervisor that the connection “exists”)).
Regarding claim 3, SANTHIVEERAN further teaches:
determining that the existing connection exists comprises:
detecting, by the hypervisor, the existing connection between the virtual machine and the entity separate from the virtual machine ([Column 2, Line 65-Column 3, Line 1] If the connection 120 is made (i.e., the connection is “detected”) then the portable computing system 100 or the computing system 150 may prompt that the connection is made).
Regarding claim 12, SANTHIVEERAN further teaches:
causing, by the hypervisor, a second existing connection between a second virtual machine implemented by the hypervisor and an entity separate from the second virtual machine to close; and creating, by the hypervisor, a snapshot of the second virtual machine ([Column 3, Lines 53-65] The computing system 150 can include a second virtual machine 265 that may execute on the second hypervisor 160. The second hypervisor 160 can be switched between the virtual machine 115 and the second virtual machine 265. The second hypervisor 160 may suspend one of the virtual machine 115 and the second virtual machine 265 when switching to the one that was not executing. The second hypervisor 160 may be executing the virtual machine 115 and the second virtual machine 265 at the same time and the virtual machine 115 and the second virtual machine 265 may appear for example on an interface of the second hypervisor 160 to switch between the virtual machine 115 and the second virtual machine 265 (i.e., second hypervisor may execute a plurality of virtual machines, including a second virtual machine, and cause the second virtual machine to be suspended, thereby disconnecting the second virtual machine from physical devices, and creating a snapshot of the second virtual machine in the same manner as the first virtual machine)).
Regarding claim 13, SANTHIVEERAN further teaches:
determining, by the hypervisor, that a third existing connection between a third virtual machine implemented by the hypervisor and an entity separate from the third virtual machine is repeatable; and creating, by the hypervisor, a snapshot of the third virtual machine ([Column 3, Lines 53-65] The computing system 150 can include a second virtual machine 265 that may execute on the second hypervisor 160. The second hypervisor 160 can be switched between the virtual machine 115 and the second virtual machine 265. The second hypervisor 160 may suspend one of the virtual machine 115 and the second virtual machine 265 when switching to the one that was not executing. The second hypervisor 160 may be executing the virtual machine 115 and the second virtual machine 265 at the same time and the virtual machine 115 and the second virtual machine 265 may appear for example on an interface of the second hypervisor 160 to switch between the virtual machine 115 and the second virtual machine 265 (i.e., it would have been obvious to a person of ordinary skill to have understood that SANTHIVEERAN teaches a plurality of virtual machines having connections with a plurality of separate entities, and that while SANTHIVEERAN only explicitly shows two virtual machines having two connections, any number of virtual machines having any number of connections may execute on a single hypervisor, including a third virtual machine having a third connection)).
Regarding claims 15-17, they comprise limitations similar to those of claims 1-3, and are therefore rejected for similar rationale.
Regarding claim 20, it comprises limitations similar to those of claim 1, and are therefore rejected for similar rationale.
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 4-5, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over SANTHIVEERAN, as applied to claims 1, and 15 above, and in further view of TSIRKIN Pub. No.: US 2020/0326966 A1 (hereafter TSIRKIN).
TSIRKIN was cited previously.
Regarding claim 4, while SANTHIVEERAN discusses execution of virtual machines having connections with devices, SANTHIVEERAN does not explicitly teach:
receiving, by the hypervisor from the virtual machine, information indicative of the existing connection between the virtual machine and the entity separate from the virtual machine.
However, in analogous art that similarly teaches execution of virtual machines having connections with devices, TSIRKIN teaches:
receiving, by the hypervisor from the virtual machine, information indicative of the existing connection between the virtual machine and the entity separate from the virtual machine ([0024] The hypervisor 111 may determine whether the physical device 105 is available for the VM 130 to access or use, based on power state information. For example, the hypervisor 111 may determine whether any of the VMs are using or accessing the physical device 105 based on the messages from VMs requesting to transition respective virtual devices to different power states (i.e., hypervisor 111 receives messages from VM 130 comprising power state information indicative of the connection between the VM 130 and a respective physical device 105)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined TSIRKIN’s teaching of a hypervisor receiving messages from VMs comprising information related to connections with physical devices, with SANTHIVEERAN’s teaching of a hypervisor managing connections between VMs and physical devices, to realize, with a reasonable expectation of success, a system having a hypervisor that manages connections between VMs and physical devices, as in SANTHIVEERAN, which has knowledge of the connections via messages received from the VMs, as in TSIRKIN. A person having ordinary skill would have been motivated to make this combination so that Virtual machines can more efficiently share physical devices (TSIRKIN [0011]-[0012]).
Regarding claim 5, TSIRKIN further teaches:
providing, by the hypervisor to the virtual machine, information indicative of a request to report any existing connections between the virtual machine and entities separate from the virtual machine ([0019] The VM 120 may power on the virtual device 122 and the hypervisor 111 may assign the physical device 105 to the VM 122. In one embodiment, the hypervisor 111 may receive a message from the VM 120 (or guest OS 121) indicating that the VM 120 is requesting to transition the virtual device 122 to a different power state (i.e., by assigning the physical device to the VM, the hypervisor at least “indicates” that the VM should report a request to transition the virtual device to a different power state which is indicative of an active “connection” between the VM and the virtual device)).
Regarding claims 18-19, they comprise limitations similar to claims 4-5, and are therefore rejected for similar rationale.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over SANTHIVEERAN, as applied to claim 1, and in further view of LIGOURI et al. Pub. No.: US 2020/0162332 A1 (hereafter LIGOURI).
LIGOURI was cited previously.
Regarding claim 11, while SANTHIVEERAN discusses termination of connections, SANTHIVEERAN does not explicitly teach:
causing the existing connection between the virtual machine implemented by the hypervisor and the entity separate from the virtual machine to close comprises: stopping, by the hypervisor, execution of a virtual network interface module of the virtual machine.
However, in analogous art that similarly discusses termination of connections, LIGOURI teaches:
causing the existing connection between the virtual machine implemented by the hypervisor and the entity separate from the virtual machine to close comprises: stopping, by the hypervisor, execution of a virtual network interface module of the virtual machine ([0065] In some embodiments, users of the virtualized computing service of a provider network may be allowed to terminate virtual machines (VMs) programmatically. For example, a client may set up VMs, attach VNIs to the VMs, run a desired set of computations on the VMs, and then issue a request to terminate the instances when the desired computations are complete. In such embodiments, a “DeleteOnTerminate” setting 451 may be used to specify what happens to attached VNIs when a VM is terminated. If DeleteOnTerminate is set to “true” for a VNI attached to the VM being terminated, the VNI may be deleted (i.e., terminating a VM represents a closure of connections to and from that VM, and involves deleting a VNI)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LIGOURI’s teaching of deleting connections to and from a VM and terminating a VNI, with SANTHIVEERAN’s teaching of closing connections to and from a VM, to realize, with a reasonable expectation of success, a system that closes connections to and from a VM, as in SANTHIVEERAN, causing a termination of a VNI, as in LIGOURI. A person having ordinary skill would have been motivated to make this combination to enable resources used by an unneeded VNI of a terminated VM to be used elsewhere.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over SANTHIVEERAN, as applied to claim 1, and in further view of LANG et al. Pub. No.: US 2016/0048405 A1 (hereafter LANG).
LANG was cited previously.
Regarding claim 14, SANTHIVEERAN further teaches:
creating the snapshot of the virtual machine comprises: creating, by the hypervisor, the snapshot of the virtual machine, wherein the snapshot of the virtual machine is descriptive of a current state of the virtual machine ([Column 7, Lines 12-16] Send a snap shot signal to the computing system to cause the computing system to generate a final snap shot of the first virtual machine, the final snap shot identifying most recent changes made to the first virtual machine); and
While SANTHIVEERAN discusses closing a connection and saving a state of the virtual machine, SANTHIVEERAN does not explicitly teach:
wherein the method further comprises causing, by the hypervisor, the virtual machine to be restored to the current state based on the snapshot of the virtual machine
However, in analogous art that similarly teaches saving a state of a virtual machine, LANG teaches:
wherein the method further comprises causing, by the hypervisor, the virtual machine to be restored to the current state based on the snapshot of the virtual machine ([0055] In step S208 the hypervisor 20, 22 starts restoring the states (i.e., “snapshots” stored in S108 of Fig. 1) of the virtual machine 10, 14. Then in step S210 the hypervisor is starting the virtual machine 10, 14 (i.e., starting the virtual machine restores the state of the virtual machine)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LANG’s teaching of restoring virtual machines from stored state snapshots, with SANTHIVEERAN’s teaching of storing state snapshots of virtual machines, to realize, with a reasonable expectation of success, a system that stores state snapshots of virtual machines, as in SANTHIVEERAN, for use in restoring the state of the virtual machine later, as in LANG. A person having ordinary skill would have been motivated to make this combination to resume a virtual machine without loss of state.
Claims 21, and 22 is rejected under 35 U.S.C. 103 as being unpatentable over SANTHIVEERAN, as applied to claim 1, and in further view of YE et al. Pub. No.: US 2024/0004685 A1 (hereafter YE).
Regarding claim 21, while SANTHIVEERAN discusses taking snapshots of virtual machines when it is determined to close connections to the virtual machine, SANTHIVEERAN does not explicitly disclose:
subsequent to the existing connection being closed, creating, by the hypervisor, the snapshot of the virtual machine.
However, in analogous art that similarly discusses taking snapshots of virtual machines, YE teaches:
subsequent to the existing connection being closed, creating, by the hypervisor, the snapshot of the virtual machine ([0005] A user device may access one or more virtual applications (e.g., virtual desktop) executed by a virtual machine, hosted by a virtualization platform. [0060] Hypervisor 302 may be referred to as a virtual machine monitor, or platform virtualization software. [0007] A virtualization platform may monitor the computing resource usage of a virtual machine (e.g., after the virtual machine is disconnected from a previously connected user device), to determine whether the virtual machine is in an idle state. If the virtual machine is in an idle state (e.g., not implementing backend instructions from the user device), the virtual platform may take a snapshot of the virtual machine).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined YE’s teaching of a hypervisor taking a snapshot of a virtual machine subsequent to the virtual machine being disconnected from a user device, with SANTHIVEERAN’s teaching of a hypervisor taking a snapshot of a virtual machine, to realize, with a reasonable expectation of success, a system having a hypervisor that takes a snapshot of a virtual machine, as in SANTHIVEERAN, after it has been determined that the virtual machine has been disconnected from an external entity, as in YE. A person having ordinary skill would have been motivated to make this combination to better utilize computing resources during a disconnection time period (YE [0003]).
Regarding claim 22, while SANTHIVEERAN discusses taking snapshots of virtual machines when it is determined to close connections to the virtual machine, SANTHIVEERAN does not explicitly disclose:
subsequent to the existing connection being closed, creating, by the hypervisor, the snapshot of the virtual machine.
However, in analogous art that similarly discusses taking snapshots of virtual machines, YE teaches:
determining that the existing connection is closed ([0112] At step 710, the system (e.g., the delivery controller 610) may detect that the first user device 601 is disconnected from the first virtual machine 605); and
responsive to determining that the existing connection is closed, creating, by the hypervisor, the snapshot of the virtual machine ([0119] At step 735, the system may obtain, based on the determination that the first virtual machine 605 is in the idle state, a snapshot of the first virtual machine 605. [0005] A user device may access one or more virtual applications (e.g., virtual desktop) executed by a virtual machine, hosted by a virtualization platform. [0060] Hypervisor 302 may be referred to as a virtual machine monitor, or platform virtualization software. [0007] A virtualization platform may monitor the computing resource usage of a virtual machine (e.g., after the virtual machine is disconnected from a previously connected user device), to determine whether the virtual machine is in an idle state. If the virtual machine is in an idle state (e.g., not implementing backend instructions from the user device), the virtual platform may take a snapshot of the virtual machine).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined YE’s teaching of a hypervisor taking a snapshot of a virtual machine subsequent to the virtual machine being disconnected from a user device, with SANTHIVEERAN’s teaching of a hypervisor taking a snapshot of a virtual machine, to realize, with a reasonable expectation of success, a system having a hypervisor that takes a snapshot of a virtual machine, as in SANTHIVEERAN, after it has been determined that the virtual machine has been disconnected from an external entity, as in YE. A person having ordinary skill would have been motivated to make this combination to better utilize computing resources during a disconnection time period (YE [0003]).
Conclusion
THIS ACTION IS MADE FINAL. 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 MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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.
/MICHAEL W AYERS/ Primary Examiner, Art Unit 2195
Prosecution Insights