DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–11 are pending for examination in the reply filed on 06/09/2026. Claims 12–19 are cancelled.
Examiner’s Remarks
3. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
4. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
5. (A) Roth, US 9,524,389 B1.
(B) Keagy et al., 8,352,608 B1 (“Keagy”).
(C) Munjal et al., US 2018/0083854 A1 (“Munjal”).
(D) Moran et al., US 10,691,547 B1 (“Moran”).
Roth, Keagy, Munjal, and Moran were cited in the previous Office action.
Notice re prior art available under both pre-AIA and AIA
6. 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 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.
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 of this title, 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.
A.
7. Claims 1–4, and 6–10 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Roth in view of (B) Keagy.
See “References Cited” section, above, for full citations of references.
8. Regarding claim 1, (A) Roth teaches/suggests the invention substantially as claimed, including:
“A method for … replacing a pool of virtual machines, wherein the virtual machines of the pool of virtual machines are implemented on a common virtualization layer and are managed by a common virtual machine management application, and wherein the method comprises:”
(Col. 6, lines 49–55: the scaling service is configured to terminate and re-launch virtual machines for security purposes. For example, each virtual machine of a set of virtual machines may be configured to expire after running for one hour, whereupon the virtual machine may be de-provisioned and a new virtual machine instantiated in its place;
Col. 6, lines 17–23: launching virtual machines, executing the virtual machines for a period of time, terminating the virtual machines, and creating new virtual machines to replace the terminated virtual machines based on a schedule, event trigger, or other scheme;
Col. 18, lines 30–35: to run in environments of virtual machines having bounded lifespans (i.e., virtual machine instances which have a fixed lifecycle and are terminated upon reaching the end of their lifecycle ), which, upon reaching the end of their lifespans, are replaced by new virtual machines also having bounded lifespans;
Col. 5, lines 37–40: The virtual machines on each host physical computing machine may be managed through a virtualization layer, such as via a hypervisor;
Col. 10, lines 58–62: The virtualization layer may be any device, software or firmware used for providing a virtual computer platform for the virtual machines 277 and configured to manage the execution of the virtual machines 277 on the host computing system 279A;
Col. 8, lines 52–55: The previously requested virtual machines 277 may be members of an auto-scaling group allocated to the customer;
Fig. 2 and Col. 9, lines 16–30: example data center 270 includes a number of physical host computing systems (host computing systems 275A-75B a scaling service manager 280 of the **scaling service**. In this environment 200, the host computing systems 275A-75B each provide multiple virtual machines 277 and have a virtual machine manager 275 to manage those virtual machines …. Each of the virtual machines provided by a host computing system may be used as a distinct computing node for the scaling service, such as to have a first virtual machine computing node on a host computing system be part of a first computing node group for a first user);
“using the virtual machine management application to create a replacement pool of virtual machines on the common virtualization layer, wherein the replacement pool of virtual machines has the same configuration and/or settings as the pool of virtual machines”
(Col. 6, lines 17–23: launching virtual machines, executing the virtual machines for a period of time, terminating the virtual machines, and creating new virtual machines to replace the terminated virtual machines based on a schedule, event trigger, or other scheme;
Col. 18, lines 30–35: to run in environments of virtual machines having bounded lifespans (i.e., virtual machine instances which have a fixed lifecycle and are terminated upon reaching the end of their lifecycle ), which, upon reaching the end of their lifespans, are replaced by new virtual machines also having bounded lifespans;
Col. 13, lines 3–18: The base image 310 may be a snapshot of a state of a computer system at an initial point in time (e.g., at a point in time early in the lifecycle of the virtual machine, such as upon completion of a bootup process, upon an initial attempt to connect to a certain network location, etc.).
For example, the BASE IMAGE may include an installation of an operating system and software for performing tasks of the customer, and the base image may further be configured with various settings, such as settings for connecting to a particular network. The base image 310 may be configured to be instantiated into one or more virtual machines ( a scaling service), such as the scaling service described in conjunction with FIG. 2, may utilize the base image 310 to instantiate the finite instances (i.e., virtual machines with bounded lifetimes) when it provisions or de-provisions its finite instances);
“using the virtual machine management application to delete the pool of virtual machines”
(Col. 18, lines 35–48: after the virtual machine is terminated and de-provisioned in 614, a new virtual machine having a bounded lifespan may be automatically instantiated from the same base image as the previous virtual machine and the system performing the process 600 may repeat the process 600 for the new virtual machine. Additionally in such environments, the new virtual machine may be launched prior to or in parallel (i.e., concurrence) with the other operations of 614. Note that one or more of the operations performed in 602-14 may be 45 performed in various orders and combinations, including in parallel).
Roth does not teach “securely erasing” and “using an erasure application to erase each virtual machine of the pool of virtual machines, wherein the erasure application is executable independently of the virtual machine management application.”
(B) Keagy, in the context of Roth’s teachings, however teaches or suggests:
“securely erasing” and “using an erasure application to erase each virtual machine of the pool of virtual machines, wherein the erasure application is executable independently of the virtual machine management application”
(Col. 49, line 59 to Col. 50, line 21: E. Secure Deletion of Virtual Machines
provide automated secure deletion for a virtual server that is removed from the node's resources. For instance, rather than simply reallocating the resources to a different virtual machine, the utility management module of some embodiments writes random data to the file system (i.e., overwrites the values stored on a physical storage) such that subsequent configurations on the file system will be unable to extract any of the previously stored data. Alternatively, some embodiments perform the secure deletion by “zeroing out” the bits of the previously allocated file system …
FIG. 28 presents a process 2800 for securely deleting a virtual machine automatically using a utility management module of some embodiments;
Col. 35, lines 35–45: the software processes executed by the utility management module are defined by a set of scripts … hypervisor management module directs each utility management module to execute one or more of the scripts at specified instances in time through the various control provisioning messages;
See Roth, Col. 18, lines 35–48, as applied above: the new virtual machine may be launched prior to or in parallel (i.e., concurrence) with the other operations of 614. Note that one or more of the operations performed in 602-14 may be 45 performed in various orders and combinations, including in parallel).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) Keagy with those of (A) Roth to provide for the secure deletion (erasure) of virtual machine in conjunction with resource de-provisioning, re-allocation, and/or removing images or other virtual machine files from persistent storage. The motivation or advantage to do so is to protect the confidentiality of personal or sensitive user data or information.
9. Regarding claim 2, Roth and Keagy teach or suggest:
“wherein using the erasure application to erase each virtual machine of the pool of virtual machines comprises erasing at least one of the following entities associated with each virtual machine of the pool of virtual machines: one or more guest operating systems; one or more system files; one or more applications; or stored data”
(Roth, Col. 13, lines 3–18: The base image may include an installation of an operating system and software for performing tasks of the customer, and the base image may further be configured with various settings, such as settings for connecting to a particular network. The base image 310 may be configured to be instantiated into one or more virtual machines;
Keagy, Col. 49, line 59 to Col. 50, line 21: provide automated secure deletion for a virtual server that is removed from the node's resources. For instance, rather than simply reallocating the resources to a different virtual machine, the utility management module of some embodiments writes random data to the file system (i.e., overwrites the values stored on a physical storage) such that subsequent configurations on the file system will be unable to extract any of the previously stored data. Alternatively, some embodiments perform the secure deletion by “zeroing out” the bits of the previously allocated file system …
To perform the secure deletion, the process writes sets of random data to the disk storage (i.e., block device) ensuring that none of the customer's data remains on the disk storage before the disk storage is allocated to another customer;
Col. 15, lines 7–28: the file system of the virtual machine is created to store all configuration files for the virtual machine operating system, application programs, and user data …. The file system thus represents a portion of a block device of a node that is set aside to store data and configuration files of a virtual machine).
10. Regarding claim 3, Roth and Keagy teach or suggest:
“wherein using the erasure application to erase each virtual machine of the pool of virtual machines comprises erasing stored data associated with each virtual machine of the pool of virtual machines and, in addition, erasing at least one of the following entities: one or more guest operating systems associated with each virtual machine of the pool of virtual machines, one or more system files associated with each virtual machine of the pool of virtual machines, or one or more applications associated with each virtual machine of the pool of virtual machines”
(Roth, Col. 13, lines 3–18; and
Keagy, Col. 49, line 59 to Col. 50, line 21; Col. 15, lines 7–28, as applied in rejecting claim 2 above).
11. Regarding claim 4, Keagy teaches or suggests:
“wherein using the erasure application to erase each virtual machine of the pool of virtual machines comprises completely erasing each virtual machine of the pool of virtual machines”
(Col. 49, line 59 to Col. 50, line 21: the utility management module of some embodiments writes random data to the file system (i.e., overwrites the values stored on a physical storage) such that subsequent configurations on the file system will be unable to extract any of the previously stored data. Alternatively, some embodiments perform the secure deletion by “zeroing out” the bits of the previously allocated file system).
12. Regarding claim 6, Roth teaches or suggests:
“wherein using the virtual machine management application to create the replacement pool of virtual machines on the common virtualization layer comprises using the virtual machine management application to DUPLICATE the pool of virtual machines on the common virtualization layer”
(Col. 13, lines 3–18: The base image 310 may be a snapshot of a state of a computer system at an initial point in time (e.g., at a point in time early in the lifecycle of the virtual machine, such as upon completion of a bootup process, upon an initial attempt to connect to a certain network location, etc.).
For example, the BASE IMAGE may include an installation of an operating system and software for performing tasks of the customer, and the base image may further be configured with various settings, such as settings for connecting to a particular network. The base image 310 may be configured to be instantiated into one or more virtual machines ( a scaling service), such as the scaling service described in conjunction with FIG. 2, may utilize the base image 310 to instantiate the finite instances (i.e., virtual machines with bounded lifetimes) when it provisions or de-provisions its finite instances);
Col. 18, lines 35–48: after the virtual machine is terminated and de-provisioned in 614, a new virtual machine having a bounded lifespan may be automatically instantiated from the same base image as the previous virtual machine and the system performing the process 600 may repeat the process 600 for the new virtual machine;
Col. 10, lines 58–62: The virtualization layer may be any device, software or firmware used for providing a virtual computer platform for the virtual machines 277 and configured to manage the execution of the virtual machines 277 on the host computing system 279A).
13. Regarding claim 7, Roth teaches or suggests:
“wherein using the virtual machine management application to create the replacement pool of virtual machines on the common virtualization layer comprises: storing the configuration and/or settings of the pool of virtual machines at a first time”
(Col. 13, lines 3–18: The base image 310 may be a snapshot of a state of a computer system at an initial point in time (e.g., at a point in time early in the lifecycle of the virtual machine, such as upon completion of a bootup process, upon an initial attempt to connect to a certain network location, etc.).
For example, the BASE IMAGE may include an installation of an operating system and software for performing tasks of the customer, and the base image may further be configured with various settings, such as settings for connecting to a particular network. The base image 310 may be configured to be instantiated into one or more virtual machines ( a scaling service), such as the scaling service described in conjunction with FIG. 2, may utilize the base image 310 to instantiate the finite instances (i.e., virtual machines with bounded lifetimes) when it provisions or de-provisions its finite instances);
“using the virtual machine management application to create the replacement pool of virtual machines on the common virtualization layer with the same configuration and/or settings as the pool of virtual machines at a second time which is later than the first time”
(Col. 13, lines 3–18: The base image 310 may be configured to be instantiated into one or more virtual machines ( a scaling service), such as the scaling service described in conjunction with FIG. 2, may utilize the base image 310 to instantiate the finite instances (i.e., virtual machines with bounded lifetimes) when it provisions or de-provisions its finite instances);
Col. 18, lines 35–48: after the virtual machine is terminated and de-provisioned in 614, a new virtual machine having a bounded lifespan may be automatically instantiated from the same base image as the previous virtual machine and the system performing the process 600 may repeat the process 600 for the new virtual machine;
Col. 10, lines 58–62: The virtualization layer may be any device, software or firmware used for providing a virtual computer platform for the virtual machines 277 and configured to manage the execution of the virtual machines 277 on the host computing system 279A).
14. Regarding claim 8, Roth and Keagy teach or suggest:
“using the virtual machine management application to disable or suspend the operation of the pool of virtual machines before using the erasure application to erase each virtual machine of the pool of virtual machines”
(Roth, Col. 6, lines 49–55: the scaling service is configured to terminate and re-launch virtual machines for security purposes. For example, each virtual machine of a set of virtual machines may be configured to expire after running for one hour, whereupon the virtual machine may be de-provisioned and a new virtual machine instantiated in its place;
Keagy, Fig. 28, step 2820: “Halt operation of the virtual machine”;
Col. 50, lines 13–21: process then stops (at 2820) the virtual machine’s operations through a set of override commands that turn-off the virtual machine. The process accesses (at 2830) the block device of the virtual machine and performs (at 2840) a secure deletion of the virtual machine configuration and data.
Col. 35, lines 35–45: the software processes executed by the utility management module are defined by a set of scripts … hypervisor management module directs each utility management module to execute one or more of the scripts at specified instances in time through the various control provisioning messages).
15. Regarding claim 9, Roth teaches or suggests:
“using the virtual machine management application to disable or suspend the operation of the pool of virtual machines before using the virtual machine management application to create the replacement pool of virtual machines on the common virtualization layer”
(Col. 6, lines 49–55: disclosure, the scaling service is configured to terminate and re-launch virtual machines for security purposes. For example, each virtual machine of a set of virtual machines may be configured to expire after running for one hour, whereupon the virtual machine may be de-provisioned and a new virtual machine instantiated in its place;
Col. 6, lines 17–23: launching virtual machines, executing the virtual machines for a period of time, terminating the virtual machines, and creating new virtual machines to replace the terminated virtual machines based on a schedule, event trigger, or other scheme;
Col. 30, claim 5: “launch one or more virtual machines that are associated with a configuration specifying that an occurrence of a predetermined event is to cause a virtual machine of the one or more virtual machines to stop running”;
Col. 3, lines 1–10: This predetermined event may be that the virtual machine has reached the end of its predetermined bounded lifetime. Other examples of predetermined events may be the receipt of a request through an application programming interface from a customer (i.e., a device operated by or on behalf of the customer), the computing resource service provider, or other authorized entity to terminate the virtual machine).
16. Regarding claim 10, Roth teaches or suggests:
“enabling or initiating the operation of the replacement pool of virtual machines”
(Col. 6, lines 49–55: disclosure, the scaling service is configured to terminate and RE-LAUNCH virtual machines for security purposes. For example, each virtual machine of a set of virtual machines may be configured to expire after running for one hour, whereupon the virtual machine may be de-provisioned and a new virtual machine instantiated in its place).
B.
17. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over (A) Roth in view of (B) Keagy, as applied to claim 1 above, and further in view of (C) Munjal.
18. Regarding claim 5, Keagy teaches or suggests “using the erasure application to erase each virtual machine of the pool of virtual machines” as applied in rejecting claim 1 above.
Roth and Keagy do not teach “generating an erasure verification report containing data indicative of the degree, extent and/or successful completion, of the erasure of each virtual machine of the pool of virtual machines once erasure of each virtual machine of the pool of virtual machines is completed.”
(C) Munjal, in the context of Roth and Keagy’s teachings, teaches or suggests “generating an erasure verification report containing data indicative of the degree, extent and/or successful completion, of the erasure of each virtual machine of the pool of virtual machines once erasure of each virtual machine of the pool of virtual machines is completed”
(¶ 45: As shown in FIG. 2B, once data erasure verification is completed, the individual computing units 104 can transmit verification report 144 to the first enclosure controller 105a via the same IPMI or other suitable interfaces. In certain embodiments, the verification report 144 can include data indicating a failure (i.e., data at least not completely erased), a successful completion, or a nonperformance ( e.g., drive not readable) of the requested data erasure verification on one or more persistent storage devices 124. In other embodiments, the verification report 144 can also include a percentage of audited data that has been erased or not erased on a particular persistent storage device 124. In further embodiments, the verification report 144 can also include data indicating a start time, an elapsed period, a complete time, an error code, an associated secure data erasure technique applied …. The first enclosure controller 105a can then aggregate the received verification report 144 from the individual computing units 104 and transmit an aggregated verification report 144' to the administrator 121 via the management network 109. Based on the received aggregated verification report 144', the administrator 121 can then identify one or more of the computing units 104 and/or persistent storage devices 124 for manual inspection, performing additional audit, or other suitable operations).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (C) Munjal with those of Roth and Keagy to verify and provide an aggregate verification report of the secure deletion (erasure) of virtual machines. The motivation or advantage to do so is to provide for the complete audit and administrative confirmation of the deletion/erasure operations before releasing and re-allocating shared resources to another user or host environment.
C.
19. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over (A) Roth in view of (B) Keagy, as applied to claim 1 above, and further in view of (D) Moran.
20. Regarding claim 11, Roth teaches or suggests “the pool of virtual machine”
Col. 8, lines 52–55: The previously requested virtual machines 277 may be members of an auto-scaling group allocated to the customer;
Fig. 2 and Col. 9, lines 16–30: example data center 270 includes a number of physical host computing systems (host computing systems 275A-75B a scaling service manager 280 of the **scaling service**. In this environment 200, the host computing systems 275A-75B each provide multiple virtual machines 277 and have a virtual machine manager 275 to manage those virtual machines …. Each of the virtual machines provided by a host computing system may be used as a distinct computing node for the scaling service, such as to have a first virtual machine computing node on a host computing system be part of a first computing node group for a first user).
Roth and Keagy do not teach “wherein the pool of virtual machines comprises a pool of virtual desktops and wherein the virtual machine management application comprises a virtual desktop management application or virtual desktop infrastructure (VDI) software.”
(D) Moran however teaches or suggests:
“wherein the pool of virtual machines comprises a pool of virtual desktops and wherein the virtual machine management application comprises a virtual desktop management application or virtual desktop infrastructure (VDI) software”
(Col. 3, lines 35–48: Embodiments are directed to a system and method for optimizing backup and restore operations in virtual desktop environments. In an embodiment, the underlying backup system may be a variable length deduplication system that stores unique daily changes while maintaining daily full backups for immediate, single-step restores to facilitate fast, daily full backups for virtual environments, remote offices, enterprise applications, network-attached storage (NAS)
servers, and desktop/laptop computers. The backup system is used with a desktop broker or desktop virtualization product that provides remote-desktop capabilities to users using virtualization technology. Examples of such desktop brokers include VMware Horizon® View;
Col. 6, lines 24–35: EUC architecture 200 typically encompasses components that require backup and recovery to protect a desktop environment, including: a virtual desktop infrastructure 202, virtual desktop 204, and user profile and data 206. The virtual desktop infrastructure includes a desktop broker and one or more servers for database functions and file/data management functions. A hypervisor interfaces with the individual VM virtual desktops (running respective agents) that comprise the virtual desktop 204. The user 201 interacts with the desktop broker interface to access the virtual desktop client agents;
Col. 6,lines 46–50: The virtual desktop infrastructure of an EUC environment comprises the desktop brokers to handle desktop LIFECYCLE MANAGEMENT and, optionally, an external database system to keep track of the broker and desktop configurations;
Col. 7, lines 33–41: desktop broker within the virtual desktop infrastructure 202 provides personalized virtual desktops to end-users. With the desktop broker (e.g., VMware Horizon View), administrators can virtualize the OS, applications, and user data while gaining control, efficiency, and security by having desktop data in a data center. FIG. 3 illustrates an example desktop broker architecture under an embodiment. The example of FIG. 3 is directed to or contains reference to the VMware Horizon View desktop broker;
Col. 7, lines 45–50: A view connection server 302 orchestrates the EUC environment 300. It assigns virtual desktops 306 to users, authenticates users, monitors the state of the virtual desktops, and starts and stops desktops based on demand and the administrative configuration).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (D) Moran with those of Roth and Keagy to incorporate a desktop broker to configure and manage (administer) a pool of virtual desktops under a virtual desktop environment or infrastructure. The motivation or advantage to do so is to provide for the centralized management of end-user computing (EUC) environments in business or IT organizations so as to optimize the sharing of common/enterprise resources.
Response to Arguments
21. Applicant’s arguments with respect to the claims have been considered but they are not persuasive. Applicant’s arguments have not overcome the § 103 rejections. Therefore, the rejections are maintained.
In the Remarks, the Applicant contends the following:
a. Regarding the 103 rejections, with respect to Roth’s teachings, Roth’s scaling service terminates virtual machines for load-balancing, lifecycle management, and forensic snapshot preservation purposes — and not for secure data erasure.
Additionally, Roth does not disclose or suggest creating a replacement pool of virtual machines before erasing the original pool using an independently executable erasure application.
b. With respect to Keagy’s teachings, Keagy’s utility management module is integrated with — not independent of the hypervisor management module.
Additionally, Keagy does not disclose, and the combination with Roth does not suggest, the claimed three-step sequenced process, in a specific order.
c. With respect to the combination of references, the action does not explain why a POSITA would (i) adopt an erasure tool that is deliberately incompatible with the VM management system, (ii) pre-create a replacement pool before running such a tool in anticipation of an unrecoverable error state, or (iii) then use the management application to delete the errored pool.
The Examiner disagrees.
As to (a),
Applicant’s argument that Roth’s termination of virtual machines is for another purpose and not for secure data erasure, and that Roth does not disclose or suggest creating a replacement pool of virtual machines before erasing the original pool, essentially amounted to attacking the Roth reference individually (because Roth does not teach secure data erasure).
However, as this rejection is based on a combination of references, one cannot show nonobviousness (of the combination) simply by attacking references individually where the rejections are based on combinations of references.
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Accordingly, as applied in the rejections, Roth’s teaching of “
A method for … REPLACING A POOL OF VIRTUAL MACHINES …
(1) create a replacement pool of virtual machines on the common virtualization layer, wherein the replacement pool of virtual machines has the same configuration and/or settings as the pool of virtual machines … and
(3) using the virtual machine management application to delete the pool of virtual machines”
must be incorporated and understood in the context of Keagy’ teachings of “securely erasing” (i.e. secure deletion) virtual machines by overwriting the values stored on a physical storage such that subsequent configurations on the file system will be unable to extract any of the previously stored data, at step 2840 (shown in applied Fig. 28).
At the next steps 2850 and 2860, Keagy’s process then “removes (at 2850) other resources allocated to the virtual machine and deletes the virtual machine from the hypervisor controlling the node's resources. The process then reports (at 2860) the released set of resources back to the hypervisor management module and the process ends.” See column 50 of Keagy.
Accordiingly, Keagy clearly teaches or suggests that the step of “securely erasing” virtual machines occurs before the “deletion” of virtual machines (from the hypervisor control), so virtual machine resources may be released back to the pool of available resources for re-allocation.
As to (b),
Applicant overall argues that Keagy’s utility management module (UVM) is integrated with — and not independent of the hypervisor management module. UVM is also not an “independently executable third-party tool.”
Thus, Keagy does not teach the feature of “the erasure application is executable independently of the virtual machine management application.”
However, as clearly applied in the rejections, Keagy teaches in Col. 35, lines 35–45, that “the software processes executed by the utility management module are defined by a set of scripts … hypervisor management module directs each utility management module to execute one or more of the scripts at specified instances in time through the various control provisioning messages.”
That is the hypervisor management module does NOT itself executes the “one or more of the scripts” that performs the secure erasure/deletion functions, but merely directs another module to invoke or execute the scripts.
Applicant here basically contests that the limitation of “the erasure application is executable independently of the virtual machine management application” should be understood as and limited to “the erasure application is CONTROLLED independently of the virtual machine management application” or free from its control or direction.
However, this specific arrangement is not in the claims. The claims merely recites “the erasure application is executable independently of the virtual machine management application” which may be broadly understood and reasonably interpreted as that the erasure application (Keagy’s scripts performing the secure deletion) may be executed as a discrete, modular process or component — separately (independently) from the software or processes executing the hypervisor management module, the utility management modules, or other scripts implementing other software processes (such as allocating resources for a VM).
Furthermore, this reasonable interpretation is also consistent with Applicant’s specification, which discloses that “The erasure application 26 is executable independently of the virtual machine management application 24 in the sense that the processing resource 20 is capable of executing the virtual machine management application 24 and the erasure application 26 independently of one another,” (see Spec. page 9, lines 30–35),
i.e. a processor executing the virtual machine management application 24 and the erasure application 26 as separate, discrete processes, functions, components or modules.
Applicant points to Keagy’s scripts performing the secure deletion as being part of the same VM management framework. However, processes running under one broad overarching management framework simply do not preclude those same processes from being executed as separate, discrete processes, functions, components or modules.
Finally, the Examiner notes that Applicant argues that Keagy does not disclose, and the combination with Roth does not suggest, the claimed three-step sequenced process. The Examiner disagrees with such assertion and notes that the combined teaching of Roth and Keagy teaches or suggests the claimed three steps as set forth in the rejections and as further explained in point (a) above, in this section.
Applicant also asserts that “neither Keagy alone nor the combination of Roth and Keagy teaches or suggests: - First creating a replacement pool with identical configuration before beginning erasure; - Then running the erasure application knowing it will cause an unrecoverable error state in the original pool; and - Then using the VM management application to delete the now-errored original pool.”
The Examiner notes however that these specific features upon which applicant relies (i.e. running the erasure application knowing it will cause an unrecoverable error state in the original pool; and using the VM management application to delete the now-errored original pool) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
As to (c),
Applicant’s assertion that a POSITA would not adopt an erasure tool that is deliberately incompatible with the VM management system is squarely at odds with Keagy’s specific teachings,
which specifically teaches automated secure deletion for a virtual server (machine) that is removed from the node's resources by writing random data to the file system (i.e., overwrites the values stored on a physical storage) such that subsequent configurations on the file system will be unable to extract any of the previously stored data (as applied in rejecting claim 1).
As applied in the rejections, this specific teaching of Keagy is combined with the teachings of Roth which specifically teaches
A method for … REPLACING A POOL OF VIRTUAL MACHINES …
(1) create a replacement pool of virtual machines on the common virtualization layer, wherein the replacement pool of virtual machines has the same configuration and/or settings as the pool of virtual machines … and
(3) using the virtual machine management application to delete the pool of virtual machines”
A person of ordinary skill in the art before the effective filing date of the claimed invention would have found it obvious to combine the teachings of Keagy with those of Roth to specifically provide for the secure deletion (erasure) of Roth’s virtual machine in conjunction with resource de-provisioning, re-allocation, and/or removing images or other virtual machine files from persistent storage, so as to protect the confidentiality of personal or sensitive user data or information. Because Roth teaches the provision and de-provisioning of different VM to different users and customers, incorporating Keagy’s teachings of automated secure deletion for a virtual server (machine) improves Roth’s VM provisioning system by “ensuring that none of the customer's data remains on the disk storage before the disk storage is allocated to another customer.”
And In response to applicant’s argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
In this instance, as Keagy clearly teaches the automated secure deletion of virtual machines to protect user data and confidentiality, the motivation to combine with Roth is firmly rooted in Keagy’s teachings.
The Applicant also further contends that the action fails to explain why a POSITA would “… (ii) pre-create a replacement pool before running such a tool in anticipation of an unrecoverable error state, or (iii) then use the management application to delete the errored pool.”
The Examiner notes however that these specific features upon which applicant relies (i.e. pre-create a replacement pool before running such a tool in anticipation of an unrecoverable error and delete the errored pool) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(a) Jones et al., US 2016/0335004 A1, teaching SECURE VIRTUAL SECTOR ERASURE.
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 extension fee 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 BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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 J. Li can be reached on (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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
August 26, 2026
Prosecution Insights