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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in Republic of India on 10/6/2023. It is noted, however, that applicant has not filed a certified copy of the IN202341067126 application as required by 37 CFR 1.55.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 (similarly claims 8 and 15) recite: “mount the one or more volumes in the one or more containers”. The examiner is unclear how the mounting of the one or more volumes in the one or more containers is/are structured. What is the exact relationship between the volume and the container. For example, is there a 1:1, n:1 1:n or n:n relationship between the one or more volumes to the one or more containers?
Claims 2-7 and 9-14 and 16-20 are rejected based on rejection of its corresponding dependent claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chirammal et al. (Pub 20180375936) (hereafter Chirammal) in view of Antony (Pub 20160381058) (hereafter Antony)
As per claim 1, Chirammal teaches:
A method for managing container data for one or more containers running in a virtual machine (VM) having a first virtual disk backed by a first virtual disk file, the first virtual disk storing VM data for the VM, the method comprising: ([Paragraph 26], Containers may run directly on a host operating system or run within another layer of virtualization, for example, in a virtual machine… [Paragraph 29], VM 112 may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and host operating system 186A. In an example, storage container 150 and service container 160 running on VM 112 may be dependent on the underlying hardware and/or host operating system 186A. In another example, storage container 150 and/or service container 160 running on VM 112 may be independent of the underlying hardware and/or host operating system 186. [Paragraph 23], The present disclosure aims to address the performance deficiencies of network storage solutions while maintaining the security offered by the data replication features of NAS and SAN systems. In an example, an isolated guest, such as a container, may be constructed to create a virtual storage node using storage capacity directly attached to the container host. The storage container may be configured with a distributed file system to link various storage nodes across a network into a cohesive storage network. The virtual storage node would then offer the data retrieval speeds of localized DAS for any guests such as containers and VMs hosted on the same physical host as the virtual storage node. Meanwhile, files stored in the virtual storage node may be replicated to other nodes of the distributed file system on other hosts to provide security from the failure of a particular storage device. Additional efficiencies in migration and scalability may also be available due to the localized, virtualized storage architecture provided by the virtual storage nodes. By hosting the virtual storage nodes in containers, deployment of storage may also be orchestrated in conjunction with the deployment of containers hosting the services using the storage. [Paragraph 31], FIG. 2 is a block diagram illustrating data replication in a containerized high-performance network storage system according to an example of the present disclosure. Illustrated system 200 may be an extension of system 100, where VMs 112, 116, and 212 host storage containers 150, 155, and 250 respectively. In an example, each of storage containers 150, 155, and 250 may be configured to be a storage node of a distributed file system (e.g., storage nodes 152, 157, and 252). In an example, persistent storage 154 is allocated on storage node 152, and contents 270A and 275A are stored in persistent storage 154. In an example, content 270A is replicated to storage node 157 as content 270B, and content 275A is replicated to storage node 252 as content 275B over network 105.)
adding a second virtual disk to the VM, the second virtual disk backed by a second virtual disk file;
creating one or more volumes configured to store container data of the one or more containers, the one or more volumes using storage from the second virtual disk and not the first virtual disk;
mounting the one or more volumes in the one or more containers; and
backing up the second virtual disk file independent from the first virtual disk file to create a copy of the second virtual disk file. ([Paragraph 38], The first persistent storage volume is mapped to the first service container (block 335). In an example, after persistent storage 154 is initialized, persistent storage 154 may be mapped to service container 160 as a persistent storage volume. In an example, persistent storage 154 may be attached to service container 160 to create a logical connection between them. After the logical connection is established, persistent storage 154 may be mounted and/or mapped as a storage device through the operating system of service container 160, such that service container 160's operating system recognizes persistent storage 154 as a valid location to store files. In an example, persistent storage 154 may be mapped as a drive, a directory, a file system, or any other recognizable storage container in service container 160. Additionally, a content of the first persistent storage volume may be replicated to the second storage node. Replication may be performed either through a true backup, or an “exclusive or” or other algorithmic backup such that the data may be reconstructed. In the example above, content 270A stored on persistent storage 154 may be replicated to storage node 157 and/or storage node 252. In an example, mapping persistent storage 154 to service container 160 may include opening a service port 153 on storage container 150 for communications between service container 160 and persistent storage 154. In an example, content 270A may be encrypted. In an example, persistent storage 154 may remain after service container 160 exits, and persistent storage 154 may be mapped to a new service container replacing service container 160. For example, service container 160 may exit and a new version of service container 160 may replace the previous container. [Paragraph 55], In an example, storage node 752 and storage node 782 located across network 705 from storage node 752 are configured as storage nodes. In an example, contents of storage nodes 752 and 782 may be replicated to each other and other nodes of the distributed file system for data security and integrity. In an example, memory device 73013 across network 705 from guest memory 795 is associated with physical host 710B, and orchestrator 740 further executes to instantiate storage container 780 on memory 730B. In the example, storage container 780 is configured as storage node 782 and both storage nodes 752 and 782 are added to a distributed file system. In the example, orchestrator 740 creates persistent storage 784 in storage node 782 mapped to service container 775 and a contents of persistent storage 784 are replicated to the storage node 752. In an example a third storage node may be instantiated and added to the distributed file system. In the example, one or more complete copies of the contents of persistent storage 784 may be replicated between storage node 752 and the third storage node. In the example, with additional storage nodes in the distributed file system, additional replicated copies of contents such as persistent storage 784 may be distributed among the various nodes for performance and/or data security. In an example, a replicated copy of persistent storage 784 may be associated with a new instance of service container 775 launched on a host with closer network proximity (e.g., lower network latency) to a host of the replicated copy than to storage node 782.)
Although Chirammal silently discloses use of virtualized storage architecture (i.e. virtual disk) provided by virtual storage nodes and manage deployment of storage(s) in conjunction with deployment of containers. [Paragraph 23]
Chirammal does not explicitly disclose first/second virtual disk file.
Antony teaches first/second virtual disk file. ([Paragraph 23], More specifically, when a container 126 is created, storage mapper 210 creates a new container disk file 212 for that container 126. All data for container 126 is stored within its corresponding container disk file 212. Each container disk tile 212 thus includes data for a single container 126 and for no other containers 126… For example, container disk file 212-1 may contain data for container 126-1 but for no other container. Similarly, container disk file 212-2 may contain data for container 126-2 but for no other container. Each container disk file 212 is separate from, and thus not contained within, the VMDK for the VM executing container 126 associated with container disk file 212. [Paragraph 35], This disabling is done by removing the container from network fabric 217, by unmapping the container from a vNIC 208 for the VM in which the container executes. This unmapping if that communications are not transmitted to or from the unmapped container.)
It would be obvious to a person with ordinary skill in the art before the effective filing date of the invention, to combine the teachings of Chirammal wherein container data for container(s) executing on a virtual machine having a virtual disk storing VM data is/are backed up/replicated, virtual disk(s) is/are added to the VM via mount, container(s) volume(s) is/are created/mounted and virtual disk(s) is/are replicated/backed up, into teachings of Antony wherein VM virtual disk and container virtual disk/volume has a corresponding independent/separate virtual disk file, because this would enhance the teachings of Chirammal wherein by having a separate/independent virtual disk files associated with VM(s) and container(s) data, it allow independent management of each container(s)/VM(s) individually via isolation and provide individual replication/backing up of data in case of failure/security issue(s). [Antony paragraph 23, 35]
As per claim 2, rejection of claim 1 is incorporated:
Chirammal teaches further comprising configuring a cluster store of a container orchestration platform configured to manage the one or more containers to use storage from the second virtual disk and not the first virtual disk. ([Paragraph 2], In an example, a container and/or a cluster of containers may be implemented specifically to execute certain specific tasks and/or types of tasks. A scheduler may be implemented to allocate containers and clusters of containers to a host, the host being either a physical host or a virtual host such as a virtual machine. [Paragraph 26], In an example, storage container 150 and service container 160 may execute on VM 112. In an example, storage controller 140 and/or container scheduler 145 may execute either independently or within a container. [Paragraph 53], In an example, orchestrator 740 is configured to deploy a container cluster (e.g., service cluster 770) including storage container 780 and service container 775 on a single host (e.g., physical host 710B).)
As per claim 3, rejection of claim 1 is incorporated:
further comprising: creating a second VM; attaching a copy of the second virtual disk to the second VM, the copy of the second virtual disk backed by the copy of the second virtual disk file; and using the second virtual disk to create copies of the one or more containers on the second VM. ([Paragraph 34], Example method 300 may begin with instantiating a first storage container on a first host and a second storage container on a second host (block 310). In an example, storage container 150 may be instantiated on VM 112, and storage container 155 may be instantiated on VM 116 by container scheduler 145. In an example, storage controller 140 may instruct container scheduler 145 to instantiate storage containers 150 and 155. ([Paragraph 26], Containers may run directly on a host operating system or run within another layer of virtualization, for example, in a virtual machine… [Paragraph 29], VM 112 may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and host operating system 186A. In an example, storage container 150 and service container 160 running on VM 112 may be dependent on the underlying hardware and/or host operating system 186A. In another example, storage container 150 and/or service container 160 running on VM 112 may be independent of the underlying hardware and/or host operating system 186. [Paragraph 23], The present disclosure aims to address the performance deficiencies of network storage solutions while maintaining the security offered by the data replication features of NAS and SAN systems. In an example, an isolated guest, such as a container, may be constructed to create a virtual storage node using storage capacity directly attached to the container host. The storage container may be configured with a distributed file system to link various storage nodes across a network into a cohesive storage network. The virtual storage node would then offer the data retrieval speeds of localized DAS for any guests such as containers and VMs hosted on the same physical host as the virtual storage node. Meanwhile, files stored in the virtual storage node may be replicated to other nodes of the distributed file system on other hosts to provide security from the failure of a particular storage device. Additional efficiencies in migration and scalability may also be available due to the localized, virtualized storage architecture provided by the virtual storage nodes. By hosting the virtual storage nodes in containers, deployment of storage may also be orchestrated in conjunction with the deployment of containers hosting the services using the storage. [Paragraph 31], FIG. 2 is a block diagram illustrating data replication in a containerized high-performance network storage system according to an example of the present disclosure. Illustrated system 200 may be an extension of system 100, where VMs 112, 116, and 212 host storage containers 150, 155, and 250 respectively. In an example, each of storage containers 150, 155, and 250 may be configured to be a storage node of a distributed file system (e.g., storage nodes 152, 157, and 252). In an example, persistent storage 154 is allocated on storage node 152, and contents 270A and 275A are stored in persistent storage 154. In an example, content 270A is replicated to storage node 157 as content 270B, and content 275A is replicated to storage node 252 as content 275B over network 105. [Paragraph 55], In an example, storage node 752 and storage node 782 located across network 705 from storage node 752 are configured as storage nodes. In an example, contents of storage nodes 752 and 782 may be replicated to each other and other nodes of the distributed file system for data security and integrity. In an example, memory device 73013 across network 705 from guest memory 795 is associated with physical host 710B, and orchestrator 740 further executes to instantiate storage container 780 on memory 730B. In the example, storage container 780 is configured as storage node 782 and both storage nodes 752 and 782 are added to a distributed file system. In the example, orchestrator 740 creates persistent storage 784 in storage node 782 mapped to service container 775 and a contents of persistent storage 784 are replicated to the storage node 752. In an example a third storage node may be instantiated and added to the distributed file system. In the example, one or more complete copies of the contents of persistent storage 784 may be replicated between storage node 752 and the third storage node. In the example, with additional storage nodes in the distributed file system, additional replicated copies of contents such as persistent storage 784 may be distributed among the various nodes for performance and/or data security. In an example, a replicated copy of persistent storage 784 may be associated with a new instance of service container 775 launched on a host with closer network proximity (e.g., lower network latency) to a host of the replicated copy than to storage node 782.)
Antony teaches first/second virtual disk file. ([Paragraph 23], More specifically, when a container 126 is created, storage mapper 210 creates a new container disk file 212 for that container 126. All data for container 126 is stored within its corresponding container disk file 212. Each container disk tile 212 thus includes data for a single container 126 and for no other containers 126… For example, container disk file 212-1 may contain data for container 126-1 but for no other container. Similarly, container disk file 212-2 may contain data for container 126-2 but for no other container. Each container disk file 212 is separate from, and thus not contained within, the VMDK for the VM executing container 126 associated with container disk file 212. [Paragraph 35], This disabling is done by removing the container from network fabric 217, by unmapping the container from a vNIC 208 for the VM in which the container executes. This unmapping if that communications are not transmitted to or from the unmapped container.)
As per claim 4, rejection of claim 1 is incorporated:
Chirammal teaches wherein the one or more volumes using storage from the second virtual disk and not the first virtual disk comprises the one or more volumes using a partition of the second virtual disk. ([Paragraph 22], Typically, NAS and SAN storage systems require specialized hardware and networking connections to be incorporated into a data center deployment. A software alternative to physical NAS and SAN systems is distributed file systems such as GlusterFS®, With a distributed file system, artificial storage volumes may be configured from a pool of storage space networked together over a networking protocol such as transmission control protocol/internet protocol (“TCP/IP”). )
As per claim 5, rejection of claim 1 is incorporated:
Antony teaches wherein the second virtual disk does not store any VM data. [Paragraph 23], More specifically, when a container 126 is created, storage mapper 210 creates a new container disk file 212 for that container 126. All data for container 126 is stored within its corresponding container disk file 212. Each container disk tile 212 thus includes data for a single container 126 and for no other containers 126… For example, container disk file 212-1 may contain data for container 126-1 but for no other container. Similarly, container disk file 212-2 may contain data for container 126-2 but for no other container. Each container disk file 212 is separate from, and thus not contained within, the VMDK for the VM executing container 126 associated with container disk file 212. )
As per claim 6, rejection of claim 1 is incorporated:
Chirammal teaches wherein the VM data comprises one or more of: runtime data of the VM, guest operating system data of a guest operation system running on the VM, or configuration data of the VM. ([Paragraph 15], In the case of containers, oftentimes a container will be hosted on a physical host or virtual machine that already has an operating system executing, and the container may be hosted on the operating system of the physical host or VM.)
As per claim 7, rejection of claim 1 is incorporated:
wherein the container data comprises application data for one or more applications running on the one or more containers. ([Paragraph 15], Containers may enable wide spread, parallel deployment of computing power for specific tasks. In a typical example, a container may be instantiated to process a specific task and reaped after the task is complete. [Paragraph 16], Due to economies of scale, containers tend to be more advantageous in large scale hardware deployments where the relatively fast ramp-up time of containers enables for more flexibility for many different types of applications to share computing time on the same physical hardware, for example, in a private or multi-tenant cloud environment. [Paragraph 18], In a typical example, dedicated storage units may be connected to a network with hosts hosting containers executing stateful applications to store the execution states of these applications.)
As per claims 8-14, these are system claims corresponding to the method claims 1-7. Therefore, rejected based on similar rationale.
As per claims 15-20, these are non-transitory computer-readable medium claims corresponding to the method claims 1-6. Therefore, rejected based on similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights