DETAILED ACTION
This Office Action, based on application 18/933,278 filed 31 October 2024, is filed in response to applicant’s amendment and remarks filed 11 May 2026. Claims 1-20 are currently pending and have been fully considered below.
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 remarks, filed 11 May 2026 in response to the Office Action filed 12 January 2026, have been fully considered below.
Claim Rejections under 35 U.S.C. § 112
The Office withdraws the previously issued indefiniteness rejection in view of applicant’s amendment and remarks.
Claim Rejections under 35 U.S.C. § 101
The Office withdraws the previously issued rejection in view of applicant’s amendment and remarks. The Office introduces a new matter rejection responsive to applicant’s amendment based on grounds presented in the rejection of record below.
Claim Rejections under 35 U.S.C. § 103
The applicant traverses the prior art rejection to the claims alleging cited prior art fails to disclose each limitation of Claim 1 as amended. Specifically, the applicant alleges that while TARASOV teaches a manifest separate from a filesystem image that provides file-level metadata and pointers, TARASOV does not teach or suggest a filesystem image comprising a metadata portion and a data portion as recited. While the Office agrees TARASOV may not explicitly disclose a metadata portion integrated within the filesystem image, the Office asserts it would be obvious to do so in further view of the explicit teachings of CHAGANI.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 7 July 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 20 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 20 was amended to be directed to a “computer-readable storage hardware storage device”. The originally filed specification is silent with respect to the term; as such, the Office is unable to ascertain the scope of the term. Therefore, the Office is treating the introduction of the term as new matter.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1, 6, 7, 9-11, 13-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over TARASOV et al (US PGPub 2022/0147378) in further view of SORENSON et al (US Patent 12045199) and CHAGANI et al (US PGPub 2022/01348146).
With respect to Claim 1, TARASOV discloses a method implemented in a host computer system that includes a processor system, comprising:
identifying a request to start a guest context at the host computer system, the guest context relying on a filesystem image stored in a remote image repository (Abstract – “receiving a request to create a container {analogous to ‘guest context’}; retrieving a manifest for a container image {‘filesystem image’} of the container; and mounting a file system for the container, utilizing the manifest”; ¶[0104] – “a request to create a container at a host {‘host computer system’}”, “a manifest .. is retrieved from a manifest store {analogous to ‘remote image repository’}”);
fetching the metadata portion of the filesystem image from the remote image repository, the metadata portion being usable to identify the set of files and locations of the plurality of data blocks within the filesystem image (¶[0066-0067] – “method 400 may proceed with operation 404, where a manifest for a container image of the container is retrieved”, “the manifest for the container image may include metadata describing the plurality of files within the container image … the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.)”; ¶[0071] – “the manifest may be retrieved from a repository located separately from the node”);
creating a reflector disk from the metadata portion of the filesystem image, the reflector disk being configured based on the metadata portion to represent the plurality of data blocks and to service read requests using identified data blocks without storing the plurality of data blocks (Abstract – “mounting a file system for the container {‘mounting’ analogous to ‘creating a reflector disk’}, utilizing the manifest”; ¶[0072] – “the manifest may include sufficient data to create (e.g. mount) a file system for the container”, “the file system may be mounted at a node of the cluster of computing nodes”; ¶[0073] – “a file system for a container may be mounted utilizing a manifest for a container image, instead of the complete container image itself. The manifest may only include metadata needed to mount the file system, as well as pointers to additional file data included within the container image {analogous to ‘representing data blocks … without storing the data blocks …”}”);
receiving a read request at the reflector disk from a requestor (Fig 5; ¶[0076] – “method 500 may initiate with operation 502, where a request to access data within a container image of the container is identified by a file system mounted for a container”);
obtaining a set of data blocks of the plurality of data blocks from the remote image repository based on receiving the read request at the reflector disk (Fig 5; ¶[0079] – “method 500 may proceed with operation 506 , where a location of the data is determined utilizing a manifest for the container image, and the data is retrieved remotely from a content store utilizing the location of the data”); and
at the reflector disk, presenting the set of data blocks to the requestor (¶[0081] – “the retrieved data may be presented to an application running within the node, utilizing the mounted file system”).
TARASOV may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion; (2) wherein the read request specifies a read offset and a read length within the filesystem image, and (3) the set of data blocks corresponding to the read offset and the read length within the filesystem image.
However, SORENSON discloses (2) wherein the read request specifies a read offset and a read length within the filesystem image, and (3) the set of data blocks corresponding to the read offset and the read length within the filesystem image (Abstract – “Filesystem metadata may be evaluated to determine whether a portion of a data file is stored in the persistent cache according to an offset and length specified in a request … if not in the persistent cache, then the remote data store may be accessed and the data file in the immutable data object read to obtain the portion of the data file”).
TARASOV and SORENSON are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV and SORENSON before him or her, to modify the process to retrieve data remotely from a content store of TARASOV to include using location metadata as taught by SORENSON. A motivation for doing so would have been to apply a known method for determining the remote location of the requested data such that associating the metadata in a respective data block may eliminate the need to implement a directory hierarchy thus providing a storage benefit (Col 2, Lines 23-24). Therefore, it would have been obvious to combine TARASOV and SORENSON to obtain the invention as specified in the instant claims.
TARASOV and SORENSON may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion.
However, CHAGANI discloses (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion (¶[0003] – “One image format used in connection with containerization technologies is the Composite Image (CIM) format. A CIM comprises two primary types of data: (i) a metadata portion which defines a filesystem namespace (including, for example, a hierarchy of folders and files, file attributes, and the like), and (ii) a data portion which stores the actual data for files within the defined filesystem namespace”).
TARASOV, SORENSON, and CHAGANI are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, and CHAGANI before him or her, to modify the storage of the manifest and container image of the combination of TARASOV and SORENSON to include adopting the CIM format as taught by CHAGANI. A motivation for doing so would have been facilitate efficient deployment to a given guest context (¶[0003]). Therefore, it would have been obvious to combine TARASOV, SORENSON, and CHAGANI to obtain the invention as specified in the instant claims.
With respect to Claim 11, TARASOV discloses a host computer system, comprising:
a processor system (¶[0027]); and
a computer storage medium (¶[0026]) that stores computer-executable instructions that are executable by the processor system to at least:
identify a request to start a guest context at the host computer system, the guest context relying on a filesystem image stored in a remote image repository (Abstract – “receiving a request to create a container {analogous to ‘guest context’}; retrieving a manifest for a container image {‘filesystem image’} of the container; and mounting a file system for the container, utilizing the manifest”; ¶[0104] – “a request to create a container at a host {‘host computer system’}”, “a manifest .. is retrieved from a manifest store {analogous to ‘remote image repository’}”);
fetch the metadata portion of the filesystem image from the remote image repository, the metadata portion being usable to identify the set of files and locations of the plurality of data blocks within the filesystem image (¶[0066-0067] – “method 400 may proceed with operation 404, where a manifest for a container image of the container is retrieved”, “the manifest for the container image may include metadata describing the plurality of files within the container image … the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.)”; ¶[0071] – “the manifest may be retrieved from a repository located separately from the node”);
create a reflector disk from the metadata portion of the filesystem image, the reflector disk being configured based on the metadata portion to represent the plurality of data blocks and to service read request using the identified data blocks without storing the plurality of data blocks (Abstract – “mounting a file system for the container {‘mounting’ analogous to ‘creating a reflector disk’}, utilizing the manifest”; ¶[0072] – “the manifest may include sufficient data to create (e.g. mount) a file system for the container”, “the file system may be mounted at a node of the cluster of computing nodes”; ¶[0073] – “a file system for a container may be mounted utilizing a manifest for a container image, instead of the complete container image itself. The manifest may only include metadata needed to mount the file system, as well as pointers to additional file data included within the container image {analogous to ‘representing data blocks … without storing the data blocks …”}”);
receive a read request at the reflector disk (Fig 5; ¶[0076] – “method 500 may initiate with operation 502, where a request to access data within a container image of the container is identified by a file system mounted for a container”);
obtain a set of data blocks of the plurality of data blocks from the remote image repository based on receiving the read request at the reflector disk (Fig 5; ¶[0079] – “method 500 may proceed with operation 506 , where a location of the data is determined utilizing a manifest for the container image, and the data is retrieved remotely from a content store utilizing the location of the data”); and
at the reflector disk, present the set of data blocks to a requestor (¶[0081] – “the retrieved data may be presented to an application running within the node, utilizing the mounted file system”).
TARASOV may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion; (2) wherein the read request specifies a read offset and a read length within a data layer of the filesystem image, and (3) the set of data blocks corresponding to the read offset the read length within the data layer of the filesystem image.
However, SORENSON discloses (2) wherein the read request specifies a read offset and a read length within a data layer of the filesystem image, and (3) the set of data blocks corresponding to the read offset the read length within the data layer of the filesystem image (Abstract – “Filesystem metadata may be evaluated to determine whether a portion of a data file is stored in the persistent cache according to an offset and length specified in a request … if not in the persistent cache, then the remote data store may be accessed and the data file in the immutable data object read to obtain the portion of the data file”).
TARASOV and SORENSON are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV and SORENSON before him or her, to modify the process to retrieve data remotely from a content store of TARASOV to include using location metadata as taught by SORENSON. A motivation for doing so would have been to apply a known method for determining the remote location of the requested data such that associating the metadata in a respective data block may eliminate the need to implement a directory hierarchy thus providing a storage benefit (Col 2, Lines 23-24). Therefore, it would have been obvious to combine TARASOV and SORENSON to obtain the invention as specified in the instant claims.
TARASOV and SORENSON may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion.
However, CHAGANI discloses (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion (¶[0003] – “One image format used in connection with containerization technologies is the Composite Image (CIM) format. A CIM comprises two primary types of data: (i) a metadata portion which defines a filesystem namespace (including, for example, a hierarchy of folders and files, file attributes, and the like), and (ii) a data portion which stores the actual data for files within the defined filesystem namespace”).
TARASOV, SORENSON, and CHAGANI are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, and CHAGANI before him or her, to modify the storage of the manifest and container image of the combination of TARASOV and SORENSON to include adopting the CIM format as taught by CHAGANI. A motivation for doing so would have been facilitate efficient deployment to a given guest context (¶[0003]). Therefore, it would have been obvious to combine TARASOV, SORENSON, and CHAGANI to obtain the invention as specified in the instant claims.
With respect to Claim 20, TARASOV discloses a computer storage medium (¶[0026]) that stores computer-executable instructions that are executable by a processor system to at least:
identify a request to start a guest context, the guest context relying on a filesystem image stored in a remote image repository (Abstract – “receiving a request to create a container {analogous to ‘guest context’}; retrieving a manifest for a container image {‘filesystem image’} of the container; and mounting a file system for the container, utilizing the manifest”; ¶[0104] – “a request to create a container at a host {‘host computer system’}”, “a manifest .. is retrieved from a manifest store {analogous to ‘remote image repository’}”);
fetch the metadata portion of the filesystem image from the remote image repository, the metadata portion being usable to identify the set of files and locations of the plurality of data blocks within the filesystem image (¶[0066-0067] – “method 400 may proceed with operation 404, where a manifest for a container image of the container is retrieved”, “the manifest for the container image may include metadata describing the plurality of files within the container image … the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.)”; ¶[0071] – “the manifest may be retrieved from a repository located separately from the node”);
create a reflector disk from the metadata portion of the filesystem image, the reflector disk being configured based on the metadata portion to represent the plurality of data blocks and to service read requests using identified data blocks without storing the plurality of data blocks (Abstract – “mounting a file system for the container {‘mounting’ analogous to ‘creating a reflector disk’}, utilizing the manifest”; ¶[0072] – “the manifest may include sufficient data to create (e.g. mount) a file system for the container”, “the file system may be mounted at a node of the cluster of computing nodes”; ¶[0073] – “a file system for a container may be mounted utilizing a manifest for a container image, instead of the complete container image itself. The manifest may only include metadata needed to mount the file system, as well as pointers to additional file data included within the container image {analogous to ‘representing data blocks … without storing the data blocks …”}”);
associate a local cache with the plurality of reflector disks (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”);
receive a read request at a reflector disk in the plurality of reflector disks (Fig 5; ¶[0076] – “method 500 may initiate with operation 502, where a request to access data within a container image of the container is identified by a file system mounted for a container”);
obtain a set of data blocks from the remote image repository based on receiving the read request at the reflector disk (Fig 5; ¶[0079] – “method 500 may proceed with operation 506 , where a location of the data is determined utilizing a manifest for the container image, and the data is retrieved remotely from a content store utilizing the location of the data”);
cache the set of data blocks at the local cache (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”); and
at the reflector disk, present the set of data blocks to a requestor (¶[0081] – “the retrieved data may be presented to an application running within the node, utilizing the mounted file system”).
TARASOV may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion; (2) wherein the read request specifies a read offset and a read length within a data layer of the filesystem image, and (3) the set of data blocks corresponding to the read offset the read length within the data layer of the filesystem image.
However, SORENSON discloses (2) wherein the read request specifies a read offset and a read length within a data layer of the filesystem image, and (3) the set of data blocks corresponding to the read offset the read length within the data layer of the filesystem image (Abstract – “Filesystem metadata may be evaluated to determine whether a portion of a data file is stored in the persistent cache according to an offset and length specified in a request … if not in the persistent cache, then the remote data store may be accessed and the data file in the immutable data object read to obtain the portion of the data file”).
TARASOV and SORENSON are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV and SORENSON before him or her, to modify the process to retrieve data remotely from a content store of TARASOV to include using location metadata as taught by SORENSON. A motivation for doing so would have been to apply a known method for determining the remote location of the requested data such that associating the metadata in a respective data block may eliminate the need to implement a directory hierarchy thus providing a storage benefit (Col 2, Lines 23-24). Therefore, it would have been obvious to combine TARASOV and SORENSON to obtain the invention as specified in the instant claims.
TARASOV and SORENSON may not explicitly disclose (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion.
However, CHAGANI discloses (1) the filesystem image comprising: a metadata portion describing a set of files within the filesystem image and a directory hierarchy within the filesystem image, and a data portion comprising a plurality of data blocks corresponding to the set of files described in the metadata portion (¶[0003] – “One image format used in connection with containerization technologies is the Composite Image (CIM) format. A CIM comprises two primary types of data: (i) a metadata portion which defines a filesystem namespace (including, for example, a hierarchy of folders and files, file attributes, and the like), and (ii) a data portion which stores the actual data for files within the defined filesystem namespace”).
TARASOV, SORENSON, and CHAGANI are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, and CHAGANI before him or her, to modify the storage of the manifest and container image of the combination of TARASOV and SORENSON to include adopting the CIM format as taught by CHAGANI. A motivation for doing so would have been facilitate efficient deployment to a given guest context (¶[0003]). Therefore, it would have been obvious to combine TARASOV, SORENSON, and CHAGANI to obtain the invention as specified in the instant claims.
With respect to Claim 6, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
TARASOV further discloses wherein the requestor is the guest context (¶[0076] – “the request to access data may include a request from an application within the container to read data within the container image”).
With respect to Claim 7, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
SORENSON further discloses wherein the filesystem image is block-based (Col 2, Lines 14-19 – “the filesystem may divide a local persistent block-based storage device into data blocks …”).
With respect to Claim 9, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
TARASOV further discloses wherein the method further comprises logging the set of data blocks as being relevant to starting the guest context (¶[0107] – “during a startup, a user request to start a container from an image A … if the manifest is not locally present, it is retrieved from a manifest store, and the file system is mounted for the container using the manifest”).
With respect to Claim 10, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
TARASOV further discloses wherein: the read request is a first read request, and the method further comprises: receiving a second read request at the reflector disk, wherein the second read request is received from the requestor; determining that the second read request corresponds to the set of data blocks; and presenting the set of data blocks from a local cache to the requestor (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”).
With respect to Claim 13, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV further discloses wherein the requestor is the guest context (¶[0076] – “the request to access data may include a request from an application within the container to read data within the container image”).
With respect to Claim 14, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV further discloses wherein the computer-executable instructions are also executable by the processor system to: associate a local cache with the reflector disk; and cache the set of data blocks at the local cache (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”).
With respect to Claim 15, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 14.
TARASOV further discloses wherein associating the local cache with the reflector disk comprises associating a different local cache portion with each reflector disk in a plurality of reflector disks (Claim 10 – “the manifest for the container image indicates that the data is stored locally at the cache”).
With respect to Claim 16, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
SORENSON further discloses wherein the filesystem image is block-based (Col 2, Lines 14-19 – “the filesystem may divide a local persistent block-based storage device into data blocks …”).
With respect to Claim 18, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV further discloses wherein the computer-executable instructions are also executable by the processor system to log the set of data blocks as being relevant to starting the guest context (¶[0107] – “during a startup, a user request to start a container from an image A … if the manifest is not locally present, it is retrieved from a manifest store, and the file system is mounted for the container using the manifest”).
With respect to Claim 19, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV further discloses wherein: the read request is a first read request, and the computer-executable instructions are also executable by the processor system to: receive a second read request at the reflector disk, wherein the second read request is received from the requestor; determine that the second read request corresponds to the set of data blocks; and present the set of data blocks from a local cache to the requestor (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”).
Claim(s) 2-5 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over TARASOV in further view of SORENSON, CHAGANI, and STARKS et al (US PGPub 2020/0409723).
With respect to Claim 2, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
SORENSON further discloses the set of data blocks correspond to the read offset the read length within the particular data layer of the filesystem image (Abstract – “Filesystem metadata may be evaluated to determine whether a portion of a data file is stored in the persistent cache according to an offset and length specified in a request … if not in the persistent cache, then the remote data store may be accessed and the data file in the immutable data object read to obtain the portion of the data file”).
TARASOV, SORENSON, and CHAGANI may not explicitly disclose wherein: the filesystem image comprises a plurality of data layers, each data layer representing a different filesystem layer of a plurality of filesystem layers, creating the reflector disk for the filesystem image comprises creating a plurality of reflector disks for the filesystem image, each reflector disk corresponding to a different data layer in the plurality of data layers of the filesystem image, the reflector disk corresponding to a particular data layer of the filesystem image.
However, STARKS discloses wherein: the filesystem image comprises a plurality of data layers, each data layer representing a different filesystem layer of a plurality of filesystem layers, creating the reflector disk for the filesystem image comprises creating a plurality of reflector disks for the filesystem image, each reflector disk corresponding to a different data layer in the plurality of data layers of the filesystem image, the reflector disk corresponding to a particular data layer of the filesystem image (¶[0039] – “With a first composite image that already has a first set of files, a second set of files {analogous to ‘a different data layer’} can be merged to generate a second ‘layered’ composite image. The second composite image has a new set of files can be referenced to operate as a layered composite container when the second layered composite image is mounted. The added set of files can include new volumes, new files, directories, that are integrated or operate independently of the original set of files.”).
TARASOV, SORENSON, CHAGANI, and STARKS are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, CHAGANI, and STARKS before him or her, to modify the container of the combination of TARASOV, SORENSON, and CHAGANI to include layers as taught by STARKS. A motivation for doing so would have been to support portability of composite files in that new composite files do not have to be created from scratch (¶[0039]) Therefore, it would have been obvious to combine TARASOV, SORENSON, CHAGANI, and STARKS to obtain the invention as specified in the instant claims.
With respect to Claim 3, the combination of TARASOV, SORENSON, CHAGANI, and STARKS disclose the method of claim 2.
STARKS further discloses wherein the requestor is a filesystem merging component that merges the plurality of data layers on behalf of the guest context (¶[0039] – “Layering composite images includes adding more region files to an existing set of region files, which can be composited into a new layered composite image. With a first composite image that already has a first set of files, a second set of files can be merged to generate a second ‘layered’ composite image”).
With respect to Claim 4, the combination of TARASOV, SORENSON, CHAGANI, and STARKS disclose the method of claim 2.
TARASOV further discloses wherein the method further comprises: associating a local cache with the plurality of reflector disks; and caching the set of data blocks at the local cache (¶[0078] - “method 500 may proceed with operation 504, where the data is retrieved from a cache in response to determining that the data is located locally at the cache”).
With respect to Claim 5, the combination of TARASOV, SORENSON, CHAGANI, and STARKS disclose the method of claim 4.
TARASOV further discloses wherein associating the local cache with the plurality of reflector disks comprises associating a different local cache portion with each reflector disk in the plurality of reflector disks (Claim 10 – “the manifest for the container image indicates that the data is stored locally at the cache”).
With respect to Claim 12, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV, SORENSON, and CHAGANI may not explicitly disclose wherein the requestor is a filesystem merging component that merges data layers of the filesystem image on behalf of the guest context.
However, STARKS discloses wherein the requestor is a filesystem merging component that merges data layers of the filesystem image on behalf of the guest context (¶[0039] – “Layering composite images includes adding more region files to an existing set of region files, which can be composited into a new layered composite image. With a first composite image that already has a first set of files, a second set of files can be merged to generate a second ‘layered’ composite image”).
TARASOV, SORENSON, CHAGANI, and STARKS are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, CHAGANI, and STARKS before him or her, to modify the container of the combination of TARASOV, SORENSON, and CHAGANI to include layers as taught by STARKS. A motivation for doing so would have been to support portability of composite files in that new composite files do not have to be created from scratch (¶[0039]) Therefore, it would have been obvious to combine TARASOV, SORENSON, CHAGANI, and STARKS to obtain the invention as specified in the instant claims.
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over TARASOV in further view of SORENSON, CHAGANI, and FAIR (US PGPub 2005/0154825).
With respect to Claim 8, the combination of TARASOV, SORENSON, and CHAGANI disclose the method of claim 1.
TARASOV, SORENSON, and CHAGANI may not explicitly disclose wherein the set of data blocks exceeds the read length.
However, FAIR discloses wherein the set of data blocks exceeds the read length (¶[0080] – “in response to receiving a client read request in the read stream, the file system can select a number of readahead data blocks 820 to speculatively retrieve based on the amount of client-requested data 810 in the received request. By way of example, if the client requests less than 64 kB of data {analogous to ‘read length’}, then the file system sets the readahead size 614 equal to two time a predetermined number N of data blocks {analogous to ‘the set of data blocks’}, e.g. where N equals 32 data blocks”).
TARASOV, SORENSON, CHAGANI, and FAIR are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, CHAGANI, and STARKS before him or her, to modify the process of retrieving data from remote storage of the combination of TARASOV, SORENSON, and CHAGANI to include an optimized amount of readahead data as taught by STARKS. A motivation for doing so would have been to prefetch data blocks that logically extend a read stream as the data blocks are likely to be requested in the future thus improving caching (¶[0011]). Therefore, it would have been obvious to combine TARASOV, SORENSON, CHAGANI, and STARKS to obtain the invention as specified in the instant claims.
With respect to Claim 17, the combination of TARASOV, SORENSON, and CHAGANI disclose the host computer system of claim 11.
TARASOV, SORENSON, and CHAGANI may not explicitly disclose wherein the set of data blocks exceeds the read length.
However, FAIR discloses wherein the set of data blocks exceeds the read length (¶[0080] – “in response to receiving a client read request in the read stream, the file system can select a number of readahead data blocks 820 to speculatively retrieve based on the amount of client-requested data 810 in the received request. By way of example, if the client requests less than 64 kB of data {analogous to ‘read length’}, then the file system sets the readahead size 614 equal to two time a predetermined number N of data blocks {analogous to ‘the set of data blocks’}, e.g. where N equals 32 data blocks”).
TARASOV, SORENSON, CHAGANI, and FAIR are analogous art because they are from the same field of endeavor of management and application of a filesystem for remote storage caching. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of TARASOV, SORENSON, CHAGANI, and STARKS before him or her, to modify the process of retrieving data from remote storage of the combination of TARASOV, SORENSON, and CHAGANI to include an optimized amount of readahead data as taught by STARKS. A motivation for doing so would have been to prefetch data blocks that logically extend a read stream as the data blocks are likely to be requested in the future thus improving caching (¶[0011]). Therefore, it would have been obvious to combine TARASOV, SORENSON, CHAGANI, and STARKS to obtain the invention as specified in the instant claims.
Conclusion
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 ERIC T LOONAN whose telephone number is (571)272-6994. The examiner can normally be reached M-F 8am-5pm.
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, Arpan Savla can be reached at 571-272-1077. 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.
/ERIC T LOONAN/Primary Examiner, Art Unit 2137
Prosecution Insights