DETAILED ACTION
This office action is in response to the above identified application filed on June 04, 2026. The application contains claims 1-20.
Claims 1, 3, 5, 9, 12-14, 16, and 18 are amended
Claims 1-20 are pending
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on June 04, 2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments and amendments filed on June 04, 2026, have been fully considered and the objections and rejections are updated accordingly.
Specification
In view of the amendments to the abstract, the objections to the specification are withdrawn.
Claim Objections
In view of the amendments to the claims, the claim objections are withdrawn.
Claim Rejections - 35 USC § 112
In view of the amendments to the claims, the 35 USC § 112 claim rejections are withdrawn.
Claim Rejections - 35 USC § 103
In response to Applicant’s 1st argument on page 2 of Applicant’s Arguments/Remarks Made in an Amendment that is quoted below, the examiner disagrees.
“For example, it appears the Examiner was interpreting the former phrase "including at least a first volume identifier (ID) associated with the file that is unique across the cluster and a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored" as modifying the recited "read request," whereas this phrase as intended to relate to the recited "expected set" or "first set" of "context data." In order to clarify, the recited "first volume identifier" or "first buffer tree identifier" and "current epoch value" are properly interpreted in the manner intended, the undersigned has proposed amending the independent claims to include a new wherein clause, expressly indicating "wherein the context data includes at least [a first volume identifier (ID) / first buffer tree identifier (bufftree ID)] associated with the file that is unique across the cluster and a current epoch value."”
This argument pertains to the limitation “determine an expected set of context data associated with the read request, wherein the expected set of context data includes identifier (ID) associated with the file that is unique across the cluster and a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored” recited in claim 1.
The specification discloses determining an “expected set of context data” in paragraph [0004] only, the pertinent content of which is quoted as follows:
“… An expected set of context data associated with the read request is determined in which the expected set of context data includes at least a first buffer tree identifier (bufftree ID) associated with the file that is unique across the cluster and a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored. …”
The above content discusses determining an “expected set of context data” associated with a “read request” in broad terms, providing no details at all. It never states the “expected set of context data” must be determined from data that is not included in “the read request” itself. Because under the BRI both data included in “the read request” itself and data associated with “the read request” but not literally included in “the read request” are data “associated with the read request”, any data determined from either or both in response to “the read request” reads on an “expected set of context data” as recited in claim 1.
In response to Applicant’s 2nd argument on pages 3-4 of Applicant’s Arguments/Remarks Made in an Amendment that is quoted below, the examiner disagrees.
“The Examiner appears to be making an argument that the volume ID contained in Dronamraju's read request is inherency unique across a cluster. The undersigned notes under MPEP 2112, Examiner bear the burden of proof. If the prior art does not naturally and necessarily result in a volume ID that is unique across a cluster, the inherency rejection is invalid. The undersigned respectfully submits, Dronamraju's volume ID contained within a read request is not, in fact, unique across a cluster. Given the fact that the file handle of the read request may represent an inode within the file system at issue, the volume ID need not be unique cluster-wide among multiple file systems and need only be unique within the file system identified by the file handle.”
Applicant’s above argument is based on an incorrect understanding of the key concepts in a distributed file system.
In a distributed file system, a volume ID is a unique logical number that identifies a specific storage volume, while an inode number identifies a file but it is not globally unique as two different hard drives can both have a file with the same inode number. A volume ID tells the operating system which specific drive or formatted partition contains the data while an inode identifies the file inside that partition. By combining the volume ID with the inode number, the operating system creates a globally unique identifier for every file in the system. Clearly, it is the uniqueness of a volume ID that helps disambiguate an inode number, not the other way around as argued by Applicant above. Therefore, the volume ID in Dronamraju teaches the “unique across the cluster” limitation in claim 1.
In response to Applicant’s 3rd argument on page 4 of Applicant’s Arguments/Remarks Made in an Amendment that is quoted below, the examiner disagrees.
“The Examiner is improperly relying on the same volume ID contained in Dronamraju's read request for both recited sets of context data. Meanwhile, in the context of Dronamraju, it would make no sense to compare the volume ID to itself as that serves no purpose and accomplishes nothing in terms of avoiding the return to the requestor of incorrect or stale data.”
Applicant’s above argument is false. Dronamraju in fact teaches comparing two volume IDs, not the same volume ID to itself, as set forth in the previous office action and further elaborated below:
As shown in Fig. 17 and discussed in paragraphs [0156]-[0157] of Dronamraju, the data management subsystem maps a volume identifier included in the read request (operation 1708) to a file system volume (operation 1710), during which the volume identifier in the read request is matched to the volume identifier of the file system volume.
In response to Applicant’s 4th argument on page 4 of Applicant’s Arguments/Remarks Made in an Amendment that is quoted below, the examiner disagrees.
“As an initial matter, the undersigned notes the current epoch value recited by independent claim 1, is of "a dynamically extensible file system (DEFS)" and is defined in the above-captioned patent application a "value representing a specific point in an ever-growing timeline across all DEFSs of a cluster." See, e.g., Specification at [0040]. Emphasis added. The undersigned respectfully notes a "latest modification time for a file" is a value associated with a specific file - not a value associated with a file system. Meanwhile, the portion of Park relied upon is for the purpose of a client determining whether file data cached in client memory corresponds to a requested file (e.g., stored in multiple related volumes that stem from a parent volume) based on a comparison of latest modification times for the file. See Park at Col. 9, Lines 49-62, Abstract and FIGs. 8-9. In contrast, the determination regarding whether the two recited epoch values "satisfy a cluster-wide timeline check" is performed by the distributed storage system.”
In addition to the definition in paragraph [0040], the specification provides examples of an epoch value. In paragraph [0129], a new write time indicator is an epoch value. Further, in Fig. 8A and paragraph [0133], the write time field 826 that may contain information indicative of a relative time at which the data block 800 was written/stored is an epoch value that facilitates performance of cluster-wide timeline checks. In these examples, an epoch value is a write time associated with a data block, and the comparison of these epoch values/write times associated with different data blocks facilitates the cluster-wide timeline checks. In other words, an epoch value is associated with a data block or a file, not the file system as Applicant argued, and it is the comparing of epoch values associated with each data block or file that achieves a file-system-wide timeline checks, not that the epoch value is a timeline defined for the file system. About Applicant’s last point of argument, “satisfy a cluster-wide timeline check” is a broad limitation that encompasses all types of timeline check across a cluster. Comparing the latest modification times for the file in the requested volume and the file in the other volume to determine whether the files are the same as taught by Park in Fig. 9 and Col. 9, lines 49-62 is a type of cluster-wide timeline check. Because Park solves the same problem of accessing a file stored in a clustered computing network as Dronamraju, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dronamraju to incorporate the teachings of Park to arrive at the claimed invention. Doing so would determine that the files stored in different volumes are the same if the latest modification times are the same for both files as taught by Park (Col. 9, lines 58-60).
In response to Applicant’s 5th argument on page 6 of Applicant’s Arguments/Remarks Made in an Amendment that is quoted below, the examiner disagrees.
“Notably, the above-quoted portion of Dronamraju indicates a block ID may be used to identify the location of a data block containing data to be read and that in some cases, the block ID is indicative of the location of the data block being on a node other than the node processing the read request. There is nothing in this portion of Dronamraju or elsewhere in Dronamraju that shows contemplation for volume movement of a particular volume from one file system to another file system after a file was created within the particular volume. In fact, the relied upon portion of Dronamraju makes no reference to a volume or a time at which a file was created on the volume.”
The examiner notes Applicant argued about limitations that are not recited in the claim language. Claim 5 has no recitation of any limitation about “volume movement”. Nonetheless, it is taught by Fig. 13 and paragraphs [0130]-[0136] of Dronamraju that teaches performing relocation across a distributed file system, including identifying a destination node for the relocation of a corresponding set of objects in a cluster database, relocating the corresponding set of objects to the destination node (operation 1308), and relocating the file system volume to the destination node. Relocating the file system volume to a destination node inherently teaches a volume on the source node at which the file was created on the volume.
As such, the 35 U.S.C. 103 rejections are updated and maintained. Please refer to the 35 U.S.C. 103 rejections below for details.
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dronamraju et al. (US 20220391359 A1), in view of Park et al. (US 8200630 B1).
With regard to claim 1,
Dronamraju teaches
a non-transitory machine readable medium storing instructions, which when executed by one or more processing resources of a distributed storage system (Abstract: a distributed storage management system. Fig. 1; [0160]: a processing system), cause the distributed storage system to:
receive, within a node of a plurality of nodes of a cluster representing the distributed storage system, a read request from a requestor to read data from a file (Fig. 9; [0110]: file system instance 906 may receive a read request from application 914 at data management subsystem 916 of file system instance 906, where the read request identifies a particular data block in a file. Fig. 4; [0076]: distributed file system 400 is implemented across cluster 402 of nodes 404, which include node 406, node 407, and node 408. Fig. 4; [0084]: receive a read request via application layer 422 mapped to file system volume 424 within node 406);
determine an expected set of context data associated with the read request, wherein the expected set of context data includes at least a first volume identifier (ID) associated with the file that is unique across the cluster … of a dynamically extensible file system (DEFS) in which the file is stored (Fig. 4; [0084]: the received read request may reference both metadata and data, wherein metadata reads on “context data associated with the read request”. Fig. 9; [0110]: this read request may include a volume identifier that identifies a volume, such as file system volume 918, from which data is to be read, wherein the fact that the volume identifier identifies a particular file system volume indicates its being “unique across the cluster”. “a DEFS” is taught by the combination of Fig. 1; [0042]; [0044]: a distributed file system over a cluster of nods, [0039]: the distributed file system is capable of mapping multiple file system volumes to the underlying distributed block layer, and [0039]: the distributed file system enables scaling and load balancing and the distributed block layer is capable of automatically and independently growing to accommodate the needs of the file system volume, satisfying the definition for “DEFS” in [0050] of the specification); and
avoid returning incorrect or stale data to the requestor (this is the inherent result of the following matching operation), by, prior to returning a block of data of the requested data to the requestor, verifying:
a second volume ID contained within a second set of context data associated with the block of data matches the first volume ID in the expected set of context data (Fig. 17; [0156]-[0157]: the read request including a volume identifier (operation 1708). The volume identifier is mapped to a file system volume managed by the data management subsystem (operation 1710). A data block within the file system volume is associated, by the data management subsystem, with a block identifier that corresponds to a data block of a logical block device in a distributed block layer of the distributed file system (operation 1712));
Dronamraju does not teach
determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored; and
prior to returning a block of data of the requested data to the requestor, verify:
an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check.
Park teaches
determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored; and prior to returning a block of data of the requested data to the requestor, verify: an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check (Fig. 9; Col. 9, lines 49-62: this process of determination may involve a request for metadata from the clustered computing network and compare the latest modification times for the file in the requested volume and the file in the other volume, wherein a DEFS is taught by the primary reference as discussed above, wherein the latest modification time corresponds to an “epoch value” per its definition in [0040] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dronamraju to incorporate the teachings of Park to determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored and prior to returning a block of data of the requested data to the requestor, verify an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check. Doing so would determine that the files are the same if the latest modification times are the same for both files as taught by Park (Col. 9, lines 58-60).
With regard to claim 2,
As discussed in claim 1, Dronamraju and Park teach all the limitations therein.
Park further teaches
the non-transitory machine readable medium of claim 1, wherein the cluster-wide timeline check is satisfied when the epoch value is less than or equal to the current epoch value (Fig. 9; Col. 9, lines 49-62: if the latest modification times are the same for both files, the method can assume that the files are the same, i.e., “equal to”).
With regard to claim 3,
As discussed in claim 1, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the non-transitory machine readable medium of claim 1, wherein the expected set of context data further includes a file block number (FBN) based on a starting offset specified by the read request, and wherein the instructions further cause the distributed storage system to verify the FBN matches a virtual volume block number (VVBN) of a volume used to reference the block of data or an FBN contained within the second set of context data (Fig. 9; [0111]: process the read request and use information in a tree of indirect blocks corresponding to the file to locate a block number for the data block holding the requested data, wherein a block number corresponds to a “FBN” and matching the FBNs is inherently taught, and a FBN is assigned sequentially from 0 hence “based on a starting offset is inherent).
With regard to claim 4,
As discussed in claim 1, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the non-transitory machine readable medium of claim 1, wherein the requestor is a client of the distributed storage system (Fig. 9; [0110]: file system instance 906 may receive a read request from application 914 at data management subsystem 916 of file system instance 906, wherein application 914 is “a client of the distributed storage system”).
With regard to claim 5,
As discussed in claim 4, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the non-transitory machine readable medium of claim 4, wherein a volume containing the file was hosted by a different DEFS of the node or another node of the plurality of nodes at a time at which the file was created (Dronamraju, Fig. 9; [0112]: the block identifier determines that the location of the one or more data blocks is on a node in distributed file system 900 other than node 907. The data that is read may then be sent to application 914 via data management subsystem 916) and a volume ID associated with the file was generated based on a combination of a cluster-wide, unique ID of the different DEFS and a volume counter value associated with the different DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 6,
As discussed in claim 4, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the non-transitory machine readable medium of claim 4, wherein a volume containing the file was hosted by the DEFS at a time at which the file was created (Dronamraju, Fig. 9; [0112]: block service 924 and storage manager 926 can retrieve the data to be read using the block identifier, i.e., “the file was hosted by the DEFS”) and a volume ID associated with the file was generated based on a combination of a cluster-wide, unique ID of the DEFS and a volume counter value associated with the DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 7,
As discussed in claim 1, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the non-transitory machine readable medium of claim 1, wherein the requestor is a subsystem or workflow of the distributed storage system and wherein the file comprises a metafile containing metadata used by the DEFS (Fig. 17; [0156]: this read request may be received from a client (e.g., a client node) or application, i.e., “a subsystem”. Fig. 1; [0050]: inodes are used to identify files and file attributes such as creation time, access permissions, size, and block location, etc., wherein inode reads on “a metafile containing metadata” about the file to be used by the DEFS).
With regard to claim 8,
As discussed in claim 7, Dronamraju and Park teach all the limitations therein.
Park further teaches
the non-transitory machine readable medium of claim 7, wherein during creation of the metafile, a volume ID was associated with metafile that was previously generated based on a combination of a reserved value and a fixed counter value selected based on a type of the metafile (Col. 1, lines 47-51: the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on “a reserved value” of an inode number reads on "a fixed counter value selected based on a type of the metafile").
With regard to claim 9,
Dronamraju teaches
a method (Abstract: a distributed storage management system) comprising:
receiving, by a dynamically extensible file system (DEFS) of a node of a plurality of nodes of a cluster representing a distributed storage system, a read request from a client to read data from a file contained within a volume hosted by the DEFS (Fig. 9; [0110]: file system instance 906 may receive a read request from application 914 at data management subsystem 916 of file system instance 906, where the read request identifies a particular data block in a file. Fig. 4; [0076]: distributed file system 400 is implemented across cluster 402 of nodes 404, which include node 406, node 407, and node 408. Fig. 4; [0084]: receive a read request via application layer 422 mapped to file system volume 424 within node 406. “DEFS” is taught by the combination of Fig. 1; [0042]; [0044]: a distributed file system over a cluster of nods, [0039]: the distributed file system is capable of mapping multiple file system volumes to the underlying distributed block layer, and [0039]: the distributed file system enables scaling and load balancing and the distributed block layer is capable of automatically and independently growing to accommodate the needs of the file system volume, satisfying the definition for “DEFS” in [0050] of the specification);
determining a first set of context data associated with the read request, wherein the first set of context data includes at least a first buffer tree identifier (bufftree ID) associated with the file that is unique across the cluster … (Fig. 17; [0159]; Fig. 6; [0099]: access the data in the data block using the block identifier identified in operation 1712 (operation 1714). The block identifier is stored within the filesystem volume's buffer tree in the data management subsystem and is directly mapped to the file system volume data, wherein the block identifier corresponds to the bufftree ID and the fact that the buffer tree identifier identifies the particular file system volume data indicates its being “unique across the cluster”); and
prior to returning a block of data of the requested data to the client, confirming the block of data corresponds to a correct block of data (this is the inherent result of the following matching operation) by verifying:
a second bufftree ID contained within a second set of context data associated with the block of data matches the first bufftree ID (Fig. 17; [0156]-[0157]: the read request including a volume identifier (operation 1708). The volume identifier is mapped to a file system volume managed by the data management subsystem (operation 1710). A data block within the file system volume is associated, by the data management subsystem, with a block identifier that corresponds to a data block of a logical block device in a distributed block layer of the distributed file system (operation 1712));
Dronamraju does not teach
determine a current epoch value of the DEFS; and
prior to returning a block of data of the requested data to the client, verifying:
an epoch value contained within the second set of context data and the current epoch value satisfy a cluster-wide timeline check.
Park teaches
determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored; and prior to returning a block of data of the requested data to the requestor, verify: an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check (Fig. 9; Col. 9, lines 49-62: this process of determination may involve a request for metadata from the clustered computing network and compare the latest modification times for the file in the requested volume and the file in the other volume, wherein a DEFS is taught by the primary reference as discussed above, wherein the latest modification time corresponds to an “epoch value” per its definition in [0040] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dronamraju to incorporate the teachings of Park to determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored and prior to returning a block of data of the requested data to the requestor, verify an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check. Doing so would determine that the files are the same if the latest modification times are the same for both files as taught by Park (Col. 9, lines 58-60).
With regard to claim 10,
As discussed in claim 9, Dronamraju and Park teach all the limitations therein.
Park further teaches
the method of claim 9, wherein the cluster-wide timeline check is satisfied when the epoch value is less than the current epoch value (Fig. 9; Col. 9, lines 49-62: if the latest modification times are the same for both files, the method can assume that the files are the same. In view of the “equal to” teaching of the epoch value, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified it to either less than or greater than to suit individual needs).
With regard to claim 11,
As discussed in claim 9, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the method of claim 9, wherein the first set of context data further includes a file block number (FBN) based on a starting offset specified by the read request, and wherein the method further comprises verifying the FBN matches an FBN contained within the second set of context data. (Fig. 9; [0111]: process the read request and use information in a tree of indirect blocks corresponding to the file to locate a block number for the data block holding the requested data, wherein a block number corresponds to a “FBN” and matching the FBNs is inherently taught, and a FBN is assigned sequentially from 0 hence “based on a starting offset is inherent).
With regard to claim 12,
As discussed in claim 9, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the method of claim 9, wherein a volume containing the file was hosted by a different DEFS of the node or another node of the plurality of nodes at a time at which the file was created (Dronamraju, Fig. 9; [0112]: the block identifier determines that the location of the one or more data blocks is on a node in distributed file system 900 other than node 907. The data that is read may then be sent to application 914 via data management subsystem 916) and a bufftree ID associated with the file was generated based on a combination of an ID of the different DEFS and a volume counter value associated with the different DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 13,
As discussed in claim 9, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the method of claim 9, wherein a volume containing the file was hosted by the DEFS at a time at which the file was created (Dronamraju, Fig. 9; [0112]: block service 924 and storage manager 926 can retrieve the data to be read using the block identifier, i.e., “the file was hosted by the DEFS”) and a bufftree ID associated with the file was generated based on a combination of an ID of the DEFS and a volume counter value associated with the DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 14,
Dronamraju teaches
a distributed storage system (Abstract: a distributed storage management system) comprising:
one or more processing resources (Fig. 1; [0160]: a processing system); and instructions that when executed by the one or more processing resources cause the distributed storage system to:
receive, within a node of a plurality of nodes of a cluster representing the distributed storage system, a read request from a requestor to read data from a file (Fig. 9; [0110]: file system instance 906 may receive a read request from application 914 at data management subsystem 916 of file system instance 906, where the read request identifies a particular data block in a file. Fig. 4; [0076]: distributed file system 400 is implemented across cluster 402 of nodes 404, which include node 406, node 407, and node 408. Fig. 4; [0084]: receive a read request via application layer 422 mapped to file system volume 424 within node 406);
determine an expected set of context data associated with the read request, wherein the expected set of context data includes at least a first buffer tree identifier (bufftree ID) associated with the file that is unique across the cluster … of a dynamically extensible file system (DEFS) in which the file is stored (Fig. 17; [0159]; Fig. 6; [0099]: access the data in the data block using the block identifier identified in operation 1712 (operation 1714). The block identifier is stored within the filesystem volume's buffer tree in the data management subsystem and is directly mapped to the file system volume data, wherein the block identifier corresponds to the bufftree ID and the fact that the buffer tree identifier identifies the particular file system volume data indicates its being “unique across the cluster”. “a DEFS” is taught by the combination of Fig. 1; [0042]; [0044]: a distributed file system over a cluster of nods, [0039]: the distributed file system is capable of mapping multiple file system volumes to the underlying distributed block layer, and [0039]: the distributed file system enables scaling and load balancing and the distributed block layer is capable of automatically and independently growing to accommodate the needs of the file system volume, satisfying the definition for “DEFS” in [0050] of the specification); and
prior to returning a block of data of the requested data to the requestor, confirming the block of data represents an intended block of data (this is the inherent result of the following matching operation) by verifying:
a second bufftree ID contained within a second set of context data associated with the block of data matches the first bufftree ID in the expected set of context data (Fig. 17; [0156]-[0157]: the read request including a volume identifier (operation 1708). The volume identifier is mapped to a file system volume managed by the data management subsystem (operation 1710). A data block within the file system volume is associated, by the data management subsystem, with a block identifier that corresponds to a data block of a logical block device in a distributed block layer of the distributed file system (operation 1712));
Dronamraju does not teach
determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored; and
prior to returning a block of data of the requested data to the requestor, verify:
an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check.
Park teaches
determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored; and prior to returning a block of data of the requested data to the requestor, verify: an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check (Fig. 9; Col. 9, lines 49-62: this process of determination may involve a request for metadata from the clustered computing network and compare the latest modification times for the file in the requested volume and the file in the other volume, wherein a DEFS is taught by the primary reference as discussed above, wherein the latest modification time corresponds to an “epoch value” per its definition in [0040] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dronamraju to incorporate the teachings of Park to determine a current epoch value of a dynamically extensible file system (DEFS) in which the file is stored and prior to returning a block of data of the requested data to the requestor, verify an epoch value contained within the second set of context data and the current epoch value of the expected set of context data satisfy a cluster-wide timeline check. Doing so would determine that the files are the same if the latest modification times are the same for both files as taught by Park (Col. 9, lines 58-60).
With regard to claim 15,
As discussed in claim 14, Dronamraju and Park teach all the limitations therein.
Park further teaches
the distributed storage system of claim 14, wherein the cluster-wide timeline check is satisfied when the epoch value is less than or equal to the current epoch value (Fig. 9; Col. 9, lines 49-62: if the latest modification times are the same for both files, the method can assume that the files are the same, i.e., “equal to”).
With regard to claim 16,
As discussed in claim 14, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the distributed storage system of claim 14, wherein the expected set of context data further includes a file block number (FBN) based on a starting offset specified by the read request, and wherein the instructions further cause the distributed storage system to verify the FBN matches a virtual volume block number (VVBN) of a volume used to reference the block of data or an FBN contained within the second set of context data (Fig. 9; [0111]: process the read request and use information in a tree of indirect blocks corresponding to the file to locate a block number for the data block holding the requested data, wherein a block number corresponds to a “FBN” and matching the FBNs is inherently taught, and a FBN is assigned sequentially from 0 hence “based on a starting offset is inherent).
With regard to claim 17,
As discussed in claim 14, Dronamraju and Park teach all the limitations therein.
Dronamraju further teaches
the distributed storage system of claim 14, wherein the requestor is a client of the distributed storage system (Fig. 9; [0110]: file system instance 906 may receive a read request from application 914 at data management subsystem 916 of file system instance 906, wherein application 914 is “a client of the distributed storage system”).
With regard to claim 18,
As discussed in claim 17, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the distributed storage system of claim 17, wherein a volume containing the file was hosted by a different DEFS of the node or another node of the plurality of nodes at a time at which the file was created (Dronamraju, Fig. 9; [0112]: the block identifier determines that the location of the one or more data blocks is on a node in distributed file system 900 other than node 907. The data that is read may then be sent to application 914 via data management subsystem 916) and a bufftree ID associated with the file was generated based on a combination of a cluster-wide, unique ID of the different DEFS and a volume counter value associated with the different DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 19,
As discussed in claim 17, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the distributed storage system of claim 17, wherein a volume containing the file was hosted by the DEFS at a time at which the file was created (Dronamraju, Fig. 9; [0112]: block service 924 and storage manager 926 can retrieve the data to be read using the block identifier, i.e., “the file was hosted by the DEFS”) and a bufftree ID associated with the file was generated based on a combination of a cluster-wide, unique ID of the DEFS and a volume counter value associated with the DEFS (Park, Col. 1, lines 47-51: associate the data blocks of the file with a first volume identifier corresponding to the first volume, where the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on a “unique ID” of the DEFS and generation number reads on "a volume counter value").
With regard to claim 20,
As discussed in claim 14, Dronamraju and Park teach all the limitations therein.
Dronamraju and Park further teach
the distributed storage system of claim 14, wherein the requestor is a subsystem or workflow of the distributed storage system, wherein the file comprises a metafile containing metadata used by the DEFS (Dronamraju, Fig. 17; [0156]: this read request may be received from a client (e.g., a client node) or application, i.e., “a subsystem”. Fig. 1; [0050]: inodes are used to identify files and file attributes such as creation time, access permissions, size, and block location, etc., wherein inode reads on “a metafile containing metadata” about the file to be used by the DEFS), and wherein during creation of the metafile, a volume ID was associated with metafile that was previously generated based on a combination of a reserved value and a fixed counter value selected based on a type of the metafile (Park, Col. 1, lines 47-51: the first volume identifier uniquely identifies a file via a combination of an inode number, generation number, and/or file system identifier (FSID)), wherein FSID reads on “a reserved value” of an inode number reads on "a fixed counter value selected based on a type of the metafile").
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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to XIAOQIN HU whose telephone number is (571)272-1792. The examiner can normally be reached on Monday-Friday 7:00am-3:30pm.
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, Charles Rones can be reached on (571) 272-4085. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/XIAOQIN HU/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights