DETAILED ACTION
This Office Action is in response to claims filed on 02/04/2026
Claims 1-16 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 .
Response to Arguments
Applicant’s arguments, see page 5 of applicant's remarks, filed 02/04/2026, with respect to 35 U.S.C. 112(b) rejection of claims 1-16 have been fully considered and are persuasive. The rejection of 11/05/2025 has been withdrawn.
Applicant’s arguments with respect to claims 1 and 9 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 Objections
Claims 3 and 11 objected to because of the following informalities:
Claims 3 and 11 recite “virtual machine file is owned by the first machine” instead of “virtual machine file is owned by the first virtual machine”.
Appropriate correction is required.
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 1, 2, 5, 9, 10, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Subbiah et al. Pub. No. US 2007/0011667 A1 (hereinafter Subbiah) in view of Dev et al. Patent No. US 10,620,856 (hereinafter Dev).
With regard to claim 1, Subbiah teaches a method comprising ([0018], The technology includes a computer-implemented method for controlling access to objects by different virtual machines):
identifying a virtual machine [managed objects] file in a file system that is accessed by a first virtual machine and by one or more additional virtual machines ([0063], FIG. 3A illustrates a general method for identifying and sharing managed objects among virtual machines. At block 300, an application begins its execution and at step 302 the application byte code is instrumented prior to execution of any functions on objects, as described above. At block 305, the instrumentation identifies objects of the application for which state information is to be shared. In particular, these objects are identified as root objects of an object graph (see also FIG. 4). These objects are identified based on an operator defined configuration identifying which objects should be managed objects in the cluster);
identifying that a lock on the virtual machine [managed object] file is owned by the first virtual machine ([0110], At block 1120, the central manager accesses its records to determine if the lock on the object is currently available. For example, the central manager may maintain a record listing object identifiers and associated lock status, indicating whether there is a lock, which thread in which virtual machine has the lock, and the type of lock, e.g., read, write, or concurrent), the lock preventing write access to the virtual machine file by any virtual machine not identified as a lock owner; and
in response to identifying the lock, shutting down one or more of the additional virtual machines ([0110], At block 1115, VM1 sends a request for a lock to the central manager; [0111], At decision block 1125, if the lock is not available, the central manager waits until the lock becomes available; [0125], For example, if a thread currently holds the lock on an object, it may call “object.wait()” which causes the calling thread to release that object’s lock and pause execution (Examiner notes: distributed to all VM threads contending for the object) that are executing and require access to the virtual machine file.
However, Subbiah does not explicitly teach that the managed objects are files on a filesystem and the lock preventing write access to the file by any virtual machine, and further shutting down virtual machines requiring access to such file.
In a similar field of endeavor, Dev teaches a lock on the virtual machine file is owned by the first virtual machine (Col. 4, lines 8-16, A shared disk filesystem requires a mechanism for concurrency control such that stored data is not corrupted or lost when multiple nodes issue write commands simultaneously. For example, SCSI-3 commands that support Persistent Group Reservation (PGR) are designed to facilitate a group of nodes (e.g., VMs) to work cooperatively on the ownership of a target disk and, where applicable, to coordinate cluster activities. SCSI-3 PR uses a concept of registration and reservation)
the lock preventing write access to the virtual machine file by any virtual machine (Col. 4, lines 16-23, Each node registers its own “key” with a SCSI-3-compliant system. Multiple nodes registering keys form a membership and establish reservations, such as … Write Exclusive Registrants Only (WERO)) not identified as a lock owner (Col. 4, lines 24-26, Reservation type WERO allows only one reservation holder at one time to perform media-access write operations); and
in response to identifying the lock (Col. 13, lines 45-49, I/O fencing (sometimes known as disk fencing or failure fencing) may be implemented to reduce or eliminate the risk of data corruption For example in FIG. 5, host-A 110A may perform I/O fencing to block I/O access by VM3 133 to VD 151, thereby “fencing off” VM3 133 from VD1 151), shutting down one or more of the additional virtual machines that are executing and require access to the virtual machine file (Col. 13, lines 20-25, Any write command from VM2 132 or VM3 133 will be blocked or failed. In particular, since neither VM2 132 nor VM3 133 is reservation holder based on cached PR information … VSCSI layer 120A/120B fails a write command from VM 132/133 with a reservation conflict error; Col. 16, lines 23-29, In practice, paths 810-860 may be closed or removed when respective VMs 131-133 are powered OFF. This may involve VSCSI layer 120A/120B/120C sending an IOCTL command that identifies a particular reservation key. Physical disk driver 128A/128B/128C then identifies a path associated with the reservation key (e.g., path 810 associated with KEY-AA1) and removes the path accordingly).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dev with the teachings of Subbiah in order to provide a method that teaches virtual machine file locking and file I/O fencing by virtual machine shut down. The motivation for applying Dev teaching with Subbiah teaching is to provide a method that allows for a virtual machine to temporarily have uncontested control over a shared resource, such that prevents data corruption resulting from shared access (Dev, Col. 13). Subbiah and Dev are analogous art directed towards hypervisor-specific management with respect to accessing storage apparatuses. Therefore, it would have been obvious for one of ordinary skill in the art to combine Dev with Subbiah to teach the claimed invention in order to provide uncontested control over a virtual machine file resource in order to perform safe I/O operations.
With regard to claim 9, Subbiah teaches a computing apparatus comprising ([0041], The technology described herein includes a set of integrated components that provides a common virtual machine capability for application programs running n distributed system each having its own local virtual machine):
a storage system ([0047], The processing system may include a volatile memory, a mass storage device or other non-volatile memory);
a processing system operatively coupled to the storage system ([0129], Typically, these computing devices will include one or more processors in communication with one or more processor readable storage devices); and
program instructions stored on the storage system that, when executed by the processing system, direct the computing apparatus ([0047], As used herein each server or processing system includes, for example, one or more processors capable of executing instructions provided on readable media to perform the methods and task described herein)
Claim 9 is a computing apparatus having similar limitations to claim 1. Thus, claim 9 is rejected for the same rationale as applied to claim 1.
With regard to claim 2, Subbiah teaches wherein the first virtual machine and the one or more additional virtual machines execute on a plurality of hosts (FIG. 1C, Server A 110, Server B 120, and Server C 130 all individually host Virtual Machine A 112, Virtual Machine B, 122, Virtual Machine C 132; [0048], The servers 110, 120, and 130 each include a separate instance of an application … Further, each server includes a virtual machine on which the application code executes, namely virtual machine “A” 112, virtual machine “B” 122, and virtual machine “C” 132).
With regard to claim 10, it is a computing apparatus having similar limitations to claim 2. Thus, claim 10 is rejected for the same rationale as applied to claim 2.
With regard to claim 5, Dev teaches wherein the virtual machine file comprises a virtual machine disk (VMDK), a virtual hard disk (VHD), or a virtual machine configuration file (VMX) (Col. 3, lines 34-44, In the example in FIG. 1, VMs 131-133 share access to multiple virtual disks, such as VD1 151 (“first virtual disk”) and VD2 152 (“second virtual disk”) on shared physical storage system 150 ... Opening on the desired implementation, virtual disk 151-142 may be stored as virtual machine disk (VMDK) files on a shared physical storage system 150, particularly on a filesystem such as a virtual machine filesystem (VMFS) volume, etc.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dev with the teachings of Subbiah in order to provide a method that teaches a virtual machine file comprising a virtual machine disk file. The motivation for applying Dev teaching with Subbiah teaching is to provide a method that applies combining prior art elements according to known methods to yield predictable results. Subbiah and Dev are analogous art directed towards hypervisor-specific management with respect to accessing storage apparatuses. Therefore, it would have been obvious for one of ordinary skill in the art to combine Dev with Subbiah to teach the claimed invention in order to provide a combination of using known virtual machine disk storage file structure to the known methods of file locking of virtual machines.
With regard to claim 13, it is a computing apparatus having similar limitations to claim 5. Thus, claim 13 is rejected for the same rationale as applied to claim 5.
Claims 3, 4, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Subbiah in view of Dev as applied to claims 1 and 9 respectively above, and further in view of Scales et al. Patent No. US 7,849,098 B1 (hereinafter Scales).
With regard to claim 3, the combination does not explicitly teach virtual file metadata specifying an ownership identifier.
Scales teaches wherein identifying that the lock on the virtual machine file is owned by the first machine (Col. 19, lines 12-19, In the preferred embodiment, the granularity of the locking mechanism for this invention is at the file level … When one computing entity has exclusive access to a file, no other computing entity may access the file in any manner, to read or write data to the file or to read or modify any metadata contained in the file) comprises identifying an identifier for the first virtual machine file in a metadata portion for the virtual machine file (Col. 19, lines 61-67, The file 48B contains a lock 50B. The lock 50b contains an access field 51C, which indicates whether the lock 50B is reserved for exclusive, read, and write access by a single computing entity … The lock 50B also comprises a plurality of owner data fields; Col. 21, lines 10-13, To determine the Lock State and the Access mode, the server 10 reads the locking metadata from the file 48B or 48C. In the case of the file 48B, the server 10 reads the access field 51C, the owner-1 field 51D).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Scales with the teachings of Subbiah and Chen in order to provide a method that teaches metadata as means for identification for a virtual machine file. The motivation for applying Scales teaching with Subbiah and Chen teaching is to provide file-level access management granularity of a file such that improves data coherence and data caching (Scales, Col. 19). Subbiah, Chen, and Scales are analogous art directed towards hypervisor-specific management with respect to accessing storage apparatuses. Therefore, it would have been obvious for one of ordinary skill in the art to combine Reddy with Subbiah and Dev to teach the claimed invention in order to provide a combination of using known virtual machine file metadata as identifier for identification associated with a particular lock structure accessed by a virtual machine.
With regard to claim 11, it is a computing apparatus having similar limitations to claim 3. Thus, claim 11 is rejected for the same rationale as applied to claim 3.
With regard to claim 4, Subbiah teaches wherein the file system comprises a distributed file system distributed over a plurality of hosts ([0068], A managed object is a distributed object whose state is maintained consistently at the different virtual machines in a cluster of virtual machines).
With regard to claim 12, it is a computing apparatus having similar limitations to claim 4. Thus, claim 12 is rejected for the same rationale as applied to claim 4.
Claims 6-8 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Subbiah in view of Dev as applied to claims 1 and 9 respectively above, and further in view of Arya et al. Pub. No. US 2021/0004250 (hereinafter Arya).
With regard to claim 6, the combination does not explicitly teach the limitations.
Arya teaches identifying a prioritization of a second virtual machine over a third virtual machine, wherein the third virtual machine is executing on a host (FIG. 1, HVM 120a and VMs 102a-c; [0059], First, the harvest virtual machines 120 (Examiner notes: third virtual machine) may be preemptable. That may mean that the harvest virtual machine 120a receives conditional access to resources on server 108a-2; [0063], For example purposes only, assume that the initial amount of resources include 20 processing cores. At some point later in time, a higher priority virtual machine such as virtual machine 102b (Examiner notes: second virtual machine) … may need 10 of the 20 processing cores to which the harvest virtual machine 120a originally had);
shutting down the third virtual machine ([0061], Provided here is an example of when the first resource may become unavailable. The harvest virtual machine 120a may lose access to the first resource when the host agent 110a allocates the first resource to the virtual machine 102b; [0065], The host agent 110 or the scheduler 104 may terminate harvest virtual machines 120 that receive access to an amount of resources less than their minimum size);
allocating resources of the third virtual machine on the host to the second virtual machine ([0057], The scheduler 104 or the host agent 110a may allocate a certain amount of resources on the server 108a-2 to the virtual machine 102b); and
initiating execution of the second virtual machine with the resources on the host ([0057], The virtual machine 102b may use some or all of the allocated resources to process workloads on behalf of the client device 116a).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Arya with the teachings of Subbiah and Dev in order to provide a method that teaches the reallocation of resources across virtual machine based on priority. The motivation for applying Arya teaching with Subbiah and Dev teaching is to provide a method that enables serialized file access across virtual machines with priority-based resource preemption. This combination uses known techniques to improve a known method in an expected way, such that high-priority virtual machines preempting resources from lower-priority virtual machines supports system stability in maintaining serialized file access distributed across virtual machines. Subbiah and Dev and Arya are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Arya with Subbiah and Dev to teach the claimed invention in order to provide a combination of known methods to support system stability, flexibility, and efficiency.
With regard to claim 14, it is a computing apparatus having similar limitations to claim 6. Thus, claim 14 is rejected for the same rationale as applied to claim 6.
With regard to claim 7, Arya teaches wherein the resources comprise memory resources, processing resources, or networking resources ([0131], The resources 722 may include a variety of physical computing resources, including computing cores 744, memory 746, disk space 748, and bandwidth 750).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Arya with the teachings of Subbiah and Dev in order to provide a method that teaches resources comprising memory, processing, and networking resources. The motivation for applying Arya teaching with Subbiah and Dev teaching is to provide a method that applies combining prior art elements according to known methods to yield predictable results. Subbiah and Dev and Arya are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Arya with Subbiah and Dev to teach the claimed invention in order to provide a combination of using known computational resources to the known methods of priority-based resource preemption and file locking of virtual machines.
With regard to claim 15, it is a computing apparatus having similar limitations to claim 7. Thus, claim 18 is rejected for the same rationale as applied to claim 7.
With regard to claim 8, Arya teaches identifying a resource limit satisfying one or more criteria on the host ([0042], a client device may have paid for guaranteed access to a defined amount of resources. The cloud-computing system may deploy a virtual machine on behalf of the client device and assign a priority level to the virtual machine higher than the priority level assigned to a harvest virtual machine; [0063], For example purposes only, assume … a higher priority virtual machine such as virtual machine 102b (which may be a newly deployed or an existing virtual machine) may need 10 of the 20 processing cores (Examiner notes: resource limit) to which the harvest virtual machine 120a originally had access (Examiner notes: such that would satisfy the resource guarantee criteria); and
wherein identifying the prioritization of the second virtual machine over the third virtual machine occurs in response to identifying the resource limit satisfying one or more criteria ([0063], The host agent 110a may deny the harvest virtual machine 120a access to 10 of the 20 processing cores it initially had access).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Arya with the teachings of Subbiah and Dev in order to provide a method that teaches resource fulfillment of criteria of priority-based resource preemption. The motivation for applying Arya teaching with Subbiah and Dev teaching is to provide a method that enables maximum efficiency of computational resources within a system while maintaining flexibility through priority-based preemption, ensuring that lower-priority virtual machines do not interfere with resources defined by predetermined criteria (Arya, [0043]). Subbiah and Dev and Arya are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Arya with Subbiah and Dev to teach the claimed invention in order to provide a combination of using known computational resources to the known methods of priority-based resource preemption and file locking of virtual machines.
With regard to claim 16, it is a computing apparatus having similar limitations to claim 8. Thus, claim 16 is rejected for the same rationale as applied to claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Virtual Machine File System
teaches
Abstract, A scalable and high performance symmetric clustered file system for hosting virtual machines (VMs) on shared block storage. It implements a clustered locking protocol exclusively using storage links and does not require network-based inter-node communication between hosts participating in the cluster; VMFS Architecture, VMFS models a volume as an aggregation of resources and on-disk locks
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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights