DETAILED ACTION
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 .
Remarks
The present application having Application No. 18/601,726 filed on 03/11/2024 presents claims 1-20 (newer claim set submitted on 06/17/2024) for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
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.
Claims 1-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Suzuki et al. (US 2021/0223977 A1) (hereinafter Suzuki) in view of Zheng et al. (US 2014/0282511 A1) (hereinafter Zheng) and further in view of Cervantes et al. (US 2012/0005672 A1) (hereinafter Cervantes).
As per claim 1, Suzuki discloses A method executed by one or more processors (e.g. Suzuki: [Figs. 1, 5] [0006-0007] [0028-0029]), comprising: creating a first storage container for a first data center management server and a second storage container for a second data center management server, the first and second storage containers being associated with at least one common flexible logical storage unit in a storage system through a storage interface appliance (e.g. Suzuki: [0030-0031] The storage node 101 generates a migration group in which a virtual volume to be migrated, a first logical resource used to access the virtual volume to be migrated, and a second logical resource used to create the virtual volume to be migrated are grouped, and the logical resources of the migration group are migrated to the storage node 201. The first logical resource is, for example, a protocol endpoint (also referred to as PE) that manages access to the virtual volume. The second logical resource is, for example, a storage container that cuts out the virtual volume. Further, the storage node 101 starts migration of the logical resources of the migration group based on an instruction from the virtual machine 100, and returns a response to the virtual machine 100 when the migration of the logical resources of the migration group is completed. At this time, the storage node 101 migrates the logical resources of the migration group to the storage node 201 without interposing the virtual machine 100 between the storage nodes 101, 201. [0033] the migration processing unit, generates, based on a relationship between the virtual volume and the logical resource related to the virtual volume, a migration group. [0007] [0038] “Based on the information of the migration group transmitted from the storage node 101, the configuration changing unit 208 configures, on the storage node 201, a protocol endpoint, a virtual volume, and a storage container the same as the protocol endpoint, the virtual volume, and the storage container configured in the storage node 101”. Thus, Suzuki discloses migrating virtual volume created from a logical storage resource / storage container on first node to a second node via virtual machine.); creating a first virtual computing instance for the first data center management server and a second virtual computing instance for the second data center management server, wherein the first virtual computing instance has a virtual logical storage unit in the first storage container (e.g. Suzuki: [Figs. 1-3] [0062-0065] disclose VM 100 on storage node 101, where the VM has VVOLs in storage container 113. Suzuki discloses that “the storage node 101 is accessible from a virtual machine 100” and that “the storage node 101 can set an operation in unit of the virtual machine 100 by setting a virtual volume”. Suzuki further states that “the virtual machine 100 can access the virtual volume by corresponding virtual ID” [0028] [0035].);
detaching the virtual logical storage unit in the first storage container from the first virtual computing instance of the first data center management server (e.g. Suzuki: [0007] [0031] a migration group in which a virtual volume, logical resources used to access and create the virtual volume are grouped, and the migration group is migrated from a migration source storage to a migration destination storage. The storage node stats migration of the migration group based on instruction from the virtual machine, and return response when the migration is completed. [0042-0046] discloses the storage node receives a migration request from the VM, creates the migration group, and migrates the virtual volume / storage container resources without VM interposing. This implies removing/detaching virtual volume from a VM on source-side/node.); and after detaching the virtual logical storage unit from the first virtual computing instance, attaching the virtual logical storage unit to the second virtual computing instance of the second data center management server so that the virtual logical storage unit is moved from the first data center management server to the second data center management server without any storage level modifications in the storage system (e.g. Suzuki: [0038-0048] discloses, after migration based on the information of the migration group transmitted from the storage node 101, configuring the storage node 201 with the same protocol endpoint, a virtual volume, and a storage container the same as storage node 101 using the same virtual ID. This teaches that the detached virtual volume is moved from node 101 and attached to node 102. This is a functional equivalent of detaching a virtual volume from one storage node instance and attaching it to another.).
As discussed above, Suzuki discloses migrating a virtual volume from a source node to a destination node, implying detaching the virtual volume from the source node and later attaching the virtual volume to the destination node. Suzuki provides a source container, a destination container, source/destination storage-node environments, a common virtual volume resource, and a storage-side migration path that preserves the logical resource identity across nodes. Suzuki does not expressly disclose a second virtual computing instance; detaching the virtual logical storage unit from the first virtual computing instance; and after detaching the virtual logical storage unit from the first virtual computing instance, attaching the virtual logical storage unit to the second virtual computing instance.
However, Zheng expressly discloses detaching the virtual logical storage unit in the first storage container from the first virtual computing instance and after detaching the virtual logical storage unit from the first virtual computing instance, attaching the virtual logical storage unit to the second virtual computing instance of the second data center management server so that the virtual logical storage unit is moved from the first data center management server to the second data center management server without any storage level modifications in the storage system (e.g. Zheng: [0019] discloses cloud environment 110 includes virtual disk creator for creating virtual disk, virtual disk attacher for attaching virtual disk to virtual machines and virtual disk detacher for detaching virtual disk from virtual machines. [0036] discloses virtual disk 120 is initially attached to virtual machine 131 then the virtual disk 120 is detached from virtual machine 131 and attached to another virtual machine. [0037] discloses virtual disk may be detached from a first virtual machine and reattached to a second virtual machine. [0048-0055] discloses attaching a virtual disk to a first VM then detaching the virtual disk from the first VM, the independent virtual disk is preserved when detached from the first VM, and later can be assigned to a second VM.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Suzuki with Zheng because the combination would have amounted to the predictable use of known techniques according to their established functions, namely Suzuki’s storage-side migration framework and Zheng’s independent-disk preservation and identifier-based reattachment of virtual volume, to achieve the known benefit of maintaining the same storage object across different virtual machine instances. Zheng’s detach-preserve-reattach teaching with Suzuki’s storage migration system would improve continuity and portability of the migrated logical storage unit because Zheng expressly teaches that the virtual disk survives detachment and is reattached using an identifier, which would have been useful in Suzuki’s VVOL migration context.
The combination of Suzuki and Zheng teaches the claimed storage-container/virtual-disk movement, but does not expressly disclose a storage interface appliance that provides the intermediary storage-manager architecture and VM/storage coordination.
However, Cervantes discloses the containers being associated with at least one common flexible logical storage unit in a storage system through a storage interface appliance (e.g. Cervantes: [Abstract] [0010] discloses a storage management method and program serves as a n intermediary between storage subsystems and a virtual machine manager. The storage management provides means for handling VM images storage/retrieval, as well as management of virtual disk volumes. The storage management program/object provides uniform connectivity between the various storage consumers within centralized storage configuration management. This corresponds to “storage interface appliance” through which the storage resources are coordinated. [0025] states that “VMDs are containers that hold the content of corresponding VMs, and are managed by storage manager” including managing the virtual disk storage devices as a single unit. This supports the idea that the storage containers are associated with common logical storage object. Thus, Cervantes teaches an intermediary storage management object between storage subsystems and a VMM that unifies and controls virtual disk storage resources, thereby providing the claimed associated between storage containers and a shared logic storage unit through a storage interface layer.).
Furthermore, Cervantes also discloses creating virtual computing instances, wherein the virtual computing instance has a virtual logical storage unit; detaching the virtual logical storage unit form the virtual computing instance; and after detaching the virtual logical storage unit from the virtual computing device, attaching the virtual logical storage unit to the second virtual computing instance (e.g. Cervantes: [0027] discloses instantiating VMs with its associated virtual storage devices as needed. [Fig. 2] [0023] Each VM 32A-32C having a virtual storage (disk) device 34A-34C, one for each of the VMs. [0035-0038] “ attach VirtualMultiDisk--attaches a virtual disk within a VMD,” “unDeployVirtualMultiDisk —disassociates the virtual disk associated with a guest operation system (e.g. A VM).” “detach VirtualMultiDisk—detaches a virtual disk in a VMD from a host (a hypervisor).” [0047] deployVirtualDisks--performs operations within the host to attach the virtual disks to the virtual server. [0048] replaceVirtualDisk--replaces a virtual disk attached to a VM with another [0049] undeployVirtualDisk--detaches a virtual disk from a VM. Also see [0063-0065]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Cervantes with Suzuki and Zheng to provide a centralized storage-management intermediary that unifies virtual machine image storage, virtual disk volume management, and storage-subsystem connectivity, thereby improving the portability and manageability of the migrated logical storage objects. Cervantes supplies storage-management layer that controls association between logical storage containers and virtual storage object, making migration and reattachment across VMs more seamless and easier to administer. The combination would amount the predictable user of prior-art elements according to their established functions—Cervantes’ centralized storage manager with Suzuki’s storage-based VVOL migration and Zheng’s independent virtual disk preservation—to yield the predictable benefit of centralized, flexible, and portable virtual storage management.
As per claim 2, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein detaching the virtual logical storage unit includes using at least one application programming interface of the first data center management server to detach the virtual logical storage unit in the first storage container from the first virtual computing instance of the first data center management server (e.g. Suzuki: [0002] discloses a virtual volume (VVOL) can be managed from a VM via Application programming interface (API) on a cloud environment. [0056] discloses the storage node deletes the protocol endpoint, the virtual volume, and the storage container from the source storage node 101. Cervantes: [0028-0029] [0035-0038] discloses a storage manager having APIs including [0035] attach VirtualMultiDisk--attaches a virtual disk within a VMD to a host (e.g., a hypervisor). [0036] deploy VirtualMultiDisk--associates a virtual disk within a VMD to a guest operating system (e.g., a VM). [0037] unDeployVirtualMultiDisk--disassociates the virtual disk associated with a guest operating system (e.g., a VM). [0038] detach VirtualMultiDisk--detaches a virtual disk in a VMD from a host.).
As per claim 3, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein attaching the virtual logical storage unit includes using at least one application programming interface of the second data center management server to attach the virtual logical storage unit to the second virtual computing instance of the second data center management server (e.g. Suzuki: [0002] discloses a virtual volume (VVOL) can be managed from a VM via Application programming interface (API) on a cloud environment. [0038-0039] discloses configuring the storage node 201with the same protocol endpoint, virtual volume, and the storage container. It allocates the same virtual ID allocated by storage node 101 to each of the protocol endpoint, the virtual volume, and the storage container migrated to the storage node 201. Cervantes: [0028-0029] [0035-0038] further discloses a storage manager having APIs including [0035] attach VirtualMultiDisk--attaches a virtual disk within a VMD to a host (e.g., a hypervisor). [0036] deploy VirtualMultiDisk--associates a virtual disk within a VMD to a guest operating system (e.g., a VM). [0037] unDeployVirtualMultiDisk--disassociates the virtual disk associated with a guest operating system (e.g., a VM). [0038] detach VirtualMultiDisk--detaches a virtual disk in a VMD from a host.).
As per claim 4, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], further comprising registering both the first data center management server and the second data center management server to the storage interface appliance (e.g. Cervantes: [0028] states that “a system director…is coupled to storage manager object by set of northbound APIs” that are used to control VMDs. A storage manager object coupled to a system directory by northbound APIs and to the platform by southbound APIs, which maps to registering management servers to a storage interface appliance. [0040] “registerRepository--registers a storage area network (SAN) pool or network-attached-storage (NAS) fileshare as a repository for VMD containers.” This further supports the idea of registering storage infrastructure with the storage-management layer. Suzuki: Also see [0034] [0040].).
As per claim 5, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein the storage interface appliance includes a virtual volume storage provider and wherein the virtual logical storage unit is a virtual volume (e.g. Suzuki: [Abstract] [0031] discloses storage node generates migration group in which a virtual volume to be migrated, a first logical resource used to access the virtual volume, and a second logical resource used to create the virtual volume to be migrated. The second logical resource is a storage container that cuts out the virtual volume. Also see [Figs. 1-3] [0062] [0080-0084]. Zheng: [0020] further discloses virtual disk creator generates virtual disk, a virtual disk is a virtual logical disk or volume. Cervant: also discloses [0024-0025] storage manager manages all disk storage resources associated with VMs and their associated virtual storage devices referred as virtual multi-disks (VMDs). [0028-0039] discloses a storage manager handles virtual disks (storage volume)/virtual machine storage through APIs including creating virtual disk, attaching virtual disk and detaching virtual disk. Also see [0045-0053].).
As per claim 6, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein attaching the virtual logical storage unit to the second virtual computing instance is executed in response to a call for an application programming interface of the storage interface appliance to move the virtual logical storage unit to the second virtual computing instance (e.g. Suzuki: [0002] [0006-0008] expressly discloses a virtual volume (VVOL) can be managed from a VM via API on a cloud environment. A volume migration in VVOL environment of the VMware is implemented by a host-based storage vMotion. Also see [Abstract] [0038-0039] discloses migration processing unit performs processing of the logical resources of the migration group migrated from the storage node 101 to storage node 102. The configuration changing unit configures, on the storage node 201, a protocol endpoint, a virtual volume, and a storage container the same as the protocol endpoint, the virtual volume, and the storage container configured in the storage node 101, including the same virtual ID. Cervantes: [0028-0038] also expressly discloses attaching and detaching a virtual disk to/from guest (VM). Zheng: [0019] [0032] [0036] [0046-0049] [0054] further discloses virtual disk detacher and virtual disk attacher to detach virtual disk form a first VM and attaching the virtual disk to the second VM.).
As per claim 7, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein the first virtual computing instance is a virtual machine managed by the first data center management server and the second virtual computing instance is a virtual machine managed by the second data center management server (e.g. Suzuki: [Figs. 1-2] [0028] discloses VM 1 on storage node 101. Zheng: [Fig. 1] [0015-0016] discloses computing environment coupled to cloud environment can include a plurality of devices running virtual machines, such as virtual machines 131-133. [0036-0037] [0054] discloses virtual disk is detached from virtual machine 131 and will be attached to virtual machine 131. [0096] expressly discloses virtual machines host contains can be moved between hosts. [0104] discloses virtual infrastructure management system may manage independent virtual disk that can be attached to a virtual machine and can be migrated independent to another VM on any host. Cervantes: [Figs.1-2] [0021-0023] discloses server group includes a plurality of processing nodes 10A-10D executing VMs 32A-32C.).
As per claim 8, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein the at least one common flexible logical storage unit includes a flexible volume in a storage virtual computing instance running in the storage system (e.g. Suzuki: [Fig. 3] [0062-0065] discloses a storage 110 includes a protocol endpoint, virtual volumes associated with the protocol endpoint, and a storage container from which the virtual volumes are generated. [0007] discloses a migration group in which a virtual volume, a first logical resource used to access the virtual volume, and a second logical resource used to create the virtual volume are grouped is generated in the storage and the migration group is migrated from a migration source storage to a migration destination storage. [0030-0031] [0033] [0038-0039] Suzuki states that “a migration processing unit generates a migration group in which a virtual volume to be migrated, a protocol endpoint related to the virtual volume, and a storage container that cuts out the virtual volume are grouped.” This shows a virtual volume existing as a logical storage object within a storage controlled virtualization environment. Suzuki further states “the migration source storage allocates a virtual ID to the protocol endpoint, the virtual volume, and the storage container separately,” and that “the migration destination configures, based on information of the migration group transmitted from the migration source storage…” These quotes support that the virtual volume is a reusable logical storage unit that can be tracked and reconfigured across storage instances, not a fixed physical disk. Zheng: [0019-0020] discloses virtual disk creator generates virtual disk 120, a virtual disk is a virtual logical disk or volume. [0024-0027] [0036-0040] [0048-0054] describes creating “an independent virtual disk,” “detaching the independent virtual disk form a first VM” and “attaching the independent virtual disk to a second VM” that was initially attached to the first VM. It also states that the “virtual disk is stored in a data center after being detached from a VM” and is later “attached to VM 133 based on accessing of virtual disk 120 by its unique identifier.” That supports the “common/flexible” aspect because the storage objects are shared between VMs by detaching and attaching the virtual disk, and it survives the detachment so it can be reattached later.).
As per claim 9, the combination of Suzuki, Zheng and Cervantes discloses The method of claim 1 [See rejection to claim 1 above], wherein the at least one common flexible logical storage unit is associated with one or more protocol endpoints (e.g. Suzuki: [abstract] discloses a migration processing unit generates a migration group in which virtual volume to be migrated, a protocol endpoint related to the virtual volume, and a storage container that cuts out the virtual volume are grouped. [0031] discloses generating a migration group in which a volume to be migrated, a first logical resource used to access the virtual volume to be migrated, and a second logical resource used to create the virtual volume to be migrated are grouped. The first logical resource is a protocol endpoint (PE) that manages access to the virtual volume. The second logical resource is, for example, a storage container that cuts out the virtual volume. [0034] discloses “in the volume management table 105, information on a relationship between the virtual volume and the storage container managed by the storage node 101, and a relationship between the protocol endpoint and the virtual volume is registered as management information.” Also see [0040] [0042-0047] [0063-0065]. Thus, Suzuki expressly discloses common flexible logical storage unit is associated with one or more protocol endpoints.).
As per claims 10-18, these are computer readable storage medium claims having similar limitations as cited in method claims 1-9, respectively. Thus, claims 10-18 are also rejected under the same rationale as cited in the rejection of rejected claims 1-9, respectively.
As per claims 19 and 20, these are system claims having similar limitations as cited in method claims 1 and 5, respectively. Thus, claims 19 and 20 are also rejected under the same rationale as cited in the rejection of rejected claims 1 and 5, respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
June 24, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights