DETAILED ACTION
This action responds to Application No. 19/029359, filed 01/17/2025, and to the preliminary amendment dated 01/21/2025.
At this point, claims 1, 3-8, and 10-14 have been amended. New claims 15-20 have been added. Claims 1-20 are presented for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (mathematical concepts) without significantly more. The claims recite obtaining a metadata obtaining request comprising an inode number, determining whether a first start address corresponding to that inode number exists, and if it does, obtaining key-value pairs from the start address. This is merely comparing an inode value to one or more addresses to determine a match, which is a mathematical relationship/mathematical calculation, followed by retrieving data from a memory location, which is generic computer functionality. Additional structural limitations, such as an NVM containing inodes and key-value pairs, is generic computer functionality and does not preclude the claim from reciting an abstract idea. This judicial exception is not integrated into a practical application because the claims do not impose a meaningful limit on the judicial exception – merely checking for a matching value, and retrieving data if there is a match, is not meaningfully limited by the value being an inode value and the data being key-value pairs. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the entirety of the claim appears to be directed to determining if a location exists by performing a match, and retrieving the key-value pairs if there is a match. The claims do not do anything with the retrieved key-value pairs, other than obtain them.
Claims 2 and 9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (mathematical concepts) without significantly more. The claims merely describe additional data that is in the metadata. This judicial exception is not integrated into a practical application because the claims do not impose a meaningful limit on the judicial exception – merely obtaining metadata is not meaningfully limited just because the metadata contains specific data The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the entirety of the claim appears to be directed to determining if a location exists by performing a match, and retrieving the key-value pairs if there is a match. The claims still do not do anything with the retrieved key-value pairs (and the specific data in the metadata), other than obtain them.
Appropriate correction is required.
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.
Claims 1, 8, and 15 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. The limitation “wherein i=1, …, M” (e.g. claim 1, line 12) is non-idiomatic English. Examiner is unclear whether this means that i=1, i=M, or something else. It is further unclear what the “…” in the middle of this limitation is intended to represent.
Claims 2 and 9, language “wherein in the ith key-value pair, the metadata of the ith file comprises only a name of the ith file and an inode number of the ith file” (e.g. claim 2, lines 1-2) is indefinite, as the claims are directed to a “key-value pair”, and then discloses that the key-value pair contains 3 items – an inode number of a directory, a name of the ith file, and an inode number of the ith file. It is unclear how a pair can contain 3 items, as the word “pair” means “two”;
Claims 3, 10, and 16, language “wherein the (M+1)th key-value pair comprises the inode number of the directory, a name of the (M+1)th file, and an inode number of the (M+1)th file” (e.g. claim 3, lines 4-6). See claims 2 and 9 above;
Claims 4, 11, and 17:
language “an (M+1)th file”, “an (M+1)th key-value pair” (e.g. claim 4, lines 3-4). These limitations lack sufficient antecedent basis in the claims. These claims depend on parent claims 3, 10, and 16, respectively; accordingly, it is ambiguous whether these elements refer to the same ones described in the parent claims, or to different ones;
language “wherein the (M+1)th key-value pair comprises the inode number of the directory, a name of the (M+1)th file, and an inode number of the (M+1)th file” (e.g. claim 3, lines 4-6). See claims 2 and 9 above;
language “determining a second start address of a second NVM area corresponding to the inode number of the directory does not exist; obtaining the second start address, wherein the second NVM area is a contiguous memory area in the NVM” (e.g. claim 4, lines 7-10). It is unclear how a second start address can be obtained if it does not exist;
Claims 5, 12, and 18, language “the key of the (M+1)th key-value pair comprises the inode number of the directory and the name of the (M+1)th file” (e.g. claim 5, lines 5-6). Similarly to claim 2 above, it is unclear how the key of a key-value pair, which is a single item, can contain 2 items (the name and the inode number).
Claims 6-7, 13-14, and 19-20, language “the key of the ith key-value pair comprises the inode number of the directory and the name of the ith file” (e.g. claim 5, lines 5-6). Similarly to claim 2 above, it is unclear how the key of a key-value pair, which is a single item, can contain 2 items (the name and the inode number);
Claims 2-7, 9-14, and 16-20 are rejected as dependent upon one of claims 1, 8, and 15 above, respectively.
Appropriate correction is required.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kanteti (US 2017/0316028 A1) in view of Cooney (US 20130103729 A1).
Re claim 1, Kanteti discloses the following:
A method, the method comprising: obtaining a metadata obtaining request for M files in a directory, wherein the metadata obtaining request contains an inode number of the directory (¶ 31 and 40). The directory may be managed as a container including a plurality of key-value pairs, each corresponding to the files of that directory. A lookup may be performed to access a directory or file (¶ 40). The directory is represented as an inode, which is itself a key (¶ 31);
determining whether a first [identifier] of a non-volatile memory (NVM) area corresponding to the inode number of the directory exists (¶ 29 and 40-41). Each directory and file may be associated with a unique identifier, which can be an inode number [identifier] (¶ 29). The lookup process compares a requested identifier (inode number) to file/directory identifiers (first start address) to see if there is a match; this involves determining if said identifier exists, as the only way for a match to be found is if it exists (¶ 40-41);
wherein the NVM area is a contiguous memory area in an NVM; and (¶ 6). The key-value storage may be defragmented and regrouped to provide contiguous data blocks (¶ 6), and may be implemented as a SSD (¶ 24);
responsive to the first [identifier] existing, obtaining M key-value pairs from the NVM area based on the [identifier] (¶ 47). A lookup on a file or directory looks up the key-value pair associated with the requested inode;
wherein an ith key-value pair in the M key-value pairs comprises the inode number of the directory and metadata of an ith file, and (Abstract; ¶ 29). Each key-value pair (including an ith key-value pair) comprises a name of the file (metadata of the ith file) as well as an identifier of the container (directory) of the file (Abstract). The identifier may be an inode number (¶ 29);
wherein i=1, …, M (Abstract). This limitation is indefinite, as noted above. Examiner interprets it to mean that i may be any integer value. Kanteti discloses retrieving 1 key-value pair, so Examiner interprets i to be 1.
While Kanteti discloses looking up a file, and also discloses looking up a directory (which may include multiple files), it does not explicitly disclose either requesting multiple key-value pairs of multiple files, or requesting the key-value pairs of files in a directory, and does not explicitly disclose details about how inodes correspond to addresses. Accordingly, in the interest of furthering compact prosecution, Examiner has provided Cooney.
Cooney discloses the following:
obtaining a metadata obtaining request for M files in a directory where in the metadata obtaining request comprises a [path] of the directory, and wherein M>=2 (Figs. 4 and 7; ¶ 56-58). The system obtains a request to list all key-values corresponding to files in a directory specified by a particular path (Fig. 4; ¶ 56-58). In the example given, directory 1 contains 3 files (M>=2) (Fig. 7);
determining whether a first start address of a non-volatile memory (NVM) area corresponding to the [path] of the directory exists (¶ 56-58, 70, and 75). The lookup request locates a directory based on its path (¶ 56-58), which corresponds to its address (¶ 70). If a file is successfully looked up, then it is an existing file, so the lookup determines whether it exists (¶ 75);
responsive to the first start address existing, obtaining M key-value pairs from the NVM area based on the first start address (¶ 56-58 and 75). The m key-value pairs corresponding to the files of the directory specified by the path (start address) are obtained (¶ 56-58). As noted above, if it is successfully looked up, it exists (responsive to the address existing) (¶ 75).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to modify the key-value system of Kanteti to retrieve multiple key-values associated with multiple files of a directory, as in Cooney, because it would be applying a known technique to improve a similar method in the same way. Kanteti discloses looking up key-values associated with a file or directory in a key-value store. Cooney also discloses looking up key-values associated with a file or directory in a key-value store, and has been improved in a similar way to the claimed invention, to retrieve the keys of all the files in a directory. It would have been obvious to modify the key-value retrieval of Kanteti to retrieve all the keys of files in a directory, as it would yield the predictable improvement of increasing efficiency by retrieving all the keys of a directory with a single request, rather than having to request each one individually.
It is further noted that the limitations “determining whether a first start address exists” and “responsive to the first start address existing” are contingent limitations that may or may not occur; accordingly, in claim 1, as a method claim, these limitations are considered to be optional (MPEP § 2111.04(II)). However, in the interest of compact prosecution, Examiner has chosen to interpret these limitations as having similar scope to independent claims 8 and 15, respectively; however, should claims 8 and 15 subsequently be found to be allowable, Examiner reserves the right to interpret claim 1 under the broadest reasonable interpretation allowed under MPEP § 2111.04(II).
Re claim 2, Kanteti and Cooney disclose the method of claim 1, and Kanteti further discloses that in the ith key-value pair the metadata of the ith file comprises only a name of the ith file and an inode number of the ith file (Abstract; Fig. 4 and associated text). This limitation is indefinite, as noted above. Examiner interprets it to refer to a nested key-value table, wherein a key-value of a directory includes a key-value of a nested file or directory, which includes its own key-value. In a key-value lookup, a first key-value pair corresponding to a directory (Fig. 4, 450) may include a directory inode identifier (inode number of the directory) as well as a data attribute (metadata of the ith file). The data attribute includes a name and a container identifier, which may be an inode (Fig. 4 and associated text). The container may be associated with a file, so this data attribute may be associated with a file (of the ith file)
Re claim 3, Re claim 3, Kanteti and Cooney disclose the method of claim 2, and Kanteti further discloses wherein the (M+1)th key-value pair comprises the inode number of the directory, a name of the (M+1)th file, and an inode number of the (M+1)th file (Abstract; Fig. 4 and associated text). This limitation is indefinite, as noted above. Examiner interprets it to refer to a nested key-value table, wherein a key-value of a directory includes a key-value of a nested file or directory, which includes its own key-value. In a key-value table, a first key-value pair corresponding to a directory (Fig. 4, 450) may include a directory inode identifier (inode number of the directory) as well as a data attribute (metadata of the (M+1)th file). The data attribute includes a name and a container identifier, which may be an inode (Fig. 4 and associated text). The container may be associated with a file, so this data attribute may be associated with a file (of the (M+1)th file).
Cooney further discloses the following:
obtaining a first metadata addition request for an (M+1)th file in the directory, wherein the first metadata addition request comprises an (M+1)th key-value pair (¶ 75). New files (e.g. and M+1)th file) may be added to populate a directory; in so-doing, key-value entries are added;
persistently storing the key-value pair in the NVM area based on the first start address of the NVM area (¶ 32 and 75). The data, along with its corresponding key-value pair, is written to permanent storage (persistently stored) (¶ 32); in the case of populating a directory, it is written to the directory path (first start address).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to combine Kanteti and Cooney, for the reasons noted in claim 1 above.
Re claim 4, Kanteti and Cooney disclose the method of claim 3, and Kanteti further discloses the following:
wherein the (M+1)th key-value pair comprises the inode number of the directory, a name of the (M+1)th file, and an inode number of the (M+1)th file (Abstract; Fig. 4 and associated text). This limitation is indefinite, as noted above. Examiner interprets it to refer to a nested key-value table, wherein a key-value of a directory includes a key-value of a nested file or directory, which includes its own key-value. In a key-value table, a first key-value pair corresponding to a directory (Fig. 4, 450) may include a directory inode identifier (inode number of the directory) as well as a data attribute (metadata of the (M+1)th file). The data attribute includes a name and a container identifier, which may be an inode (Fig. 4 and associated text). The container may be associated with a file, so this data attribute may be associated with a file (of the (M+1)th file).
the second NVM area is a contiguous memory area in the NVM (¶ 6). The storage may be organized into a contiguous memory area;
inode (¶ 31). See claim 1 above.
Cooney further discloses the following:
obtaining a second metadata addition request for an (M+1)th file in the directory, wherein the first metadata addition request comprises an (M+1)th key-value pair (¶ 75). See claim 3 above;
determining a second start address of a second NVM area corresponding to the [identifier] of the directory does not exist; obtaining the second start address, wherein the second NVM area is a […] memory area in the NVM (¶ 75). This limitation is indefinite, as noted above. Examiner interprets it to mean populating a new file in the directory if it does not already exist. Cooney discloses populating existing key-value directories with new files;
persistently storing the key-value pair in the second NVM area based on the second start address of the NVM area; and (¶ 32 and 75). The data, along with its corresponding key-value pair, is written to permanent storage (persistently stored) (¶ 32); in the case of populating a directory, it is written to the directory path (second start address);
constructing a correspondence between the [identifier] of the directory and the second start address (¶ 56-58 and 70). The lookup request locates a directory based on its path (¶ 56-58), which corresponds to its address (¶ 70).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to combine Kanteti and Cooney, for the reasons noted in claim 1 above.
Re claim 5, Kanteti and Cooney disclose the method of claim 3, and Kanteti further discloses wherein the (M+1)th key-value pair comprises the inode number of the directory, a name of the (M+1)th file (Abstract; Fig. 4 and associated text). This limitation is indefinite, as noted above. Examiner interprets it to refer to a nested key-value table, wherein a key-value of a directory includes a key-value of a nested file or directory, which includes its own key-value. In a key-value table, a first key-value pair corresponding to a directory (Fig. 4, 450) may include a directory inode identifier (inode number of the directory) as well as a data attribute (metadata of the (M+1)th file). The data attribute includes a name and a container identifier, which may be an inode (Fig. 4 and associated text). The container may be associated with a file, so this data attribute may be associated with a file (of the (M+1)th file).
Cooney discloses that the first NVM area comprises a second NVM area, wherein the second NVM area is for storing only the (M+1)th key-value pair, and wherein the method further comprises: constructing a correspondence between a key of the (M+1)th key-value pair and a second start address of the second NVM area (¶ 49 and 75). New entries for new files, and corresponding key-value pairs (M+1)th key-value pair), are created as new files are populated; the index maintains correspondence between the keys and locations (addresses) of the files.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to combine Kanteti and Cooney, for the reasons noted in claim 1 above.
Re claim 6, Kanteti and Cooney disclose the method of claim 2, and Kanteti further discloses the following:
obtaining a metadata obtaining request for the ith file in the directory, wherein the metadata obtaining request comprises a key of the ith key-value pair, and wherein the key of the ith key-value pair comprises the inode number of the directory and the name of the ith file (¶ 40-41). This limitation is indefinite, as noted above. Examiner interprets it to mean looking up a file in a directory using a key, which may be an inode number or name of the file;
determining a second start address of a second NVM area corresponding to the key of the ith key-value pair exists, wherein the NVM area comprises the second NVM area; and (¶ 29 and 40-41). Each directory and file may be associated with a unique identifier, which can be an inode number [identifier] (¶ 29). The lookup process compares a requested identifier (inode number) to file/directory identifiers (second start address) to see if there is a match; this involves determining if said identifier exists, as the only way for a match to be found is if it exists (¶ 40-41);
obtaining the ith key-value pair from the second NVM area based on the second start address (¶ 40-41). A lookup uses the key to look up data using an associated key-value pair, and this can be an entry to another container or a file within a container.
Re claim 7, Kanteti and Cooney disclose the method of claim 2, and Kanteti further discloses the following:
obtaining a metadata deletion request for the ith file in the directory, wherein the metadata obtaining request comprises a key of the ith key-value pair, and wherein the key of the ith key-value pair comprises the inode number of the directory and the name of the ith file (¶ 50-51). This limitation is indefinite, as noted above. Examiner interprets it to mean deleting a file in a directory using a key, which may be an inode number or name of the file. Kanteti discloses truncating (deleting) a file specified with a key;
determining a second start address of a second NVM area corresponding to the key of the ith key-value pair exists, wherein the NVM area comprises the second NVM area; and (¶ 29 and 40-41). See claim 6 above;
setting, based on the second start address, the ith key-value pair stored in the second NVM area to invalid data that cannot be obtained (¶ 50-51). A truncation (deletion requests) uses the key to look up data using an associated key-value pair, and delete it (set the area to be invalid data that cannot be obtained).
Re claims 8-14, Kanteti and Cooney disclose the methods of claims 1-7 above, respectively; accordingly, they also disclose apparatuses implementing those methods, as in claims 8-14, respectively (see Cooney, ¶ 4).
Re claims 15-20, Kanteti and Cooney disclose the methods of claims 1 and 3-7 above, respectively; accordingly, they also disclose apparatuses implementing those methods, as in claims 15-20, respectively (see Cooney, ¶ 5).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Dalton (US 2016/0321295 A1). Discloses deleting and updating files and directories in a key-value store (¶ 63-65).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRAIG S GOLDSCHMIDT whose telephone number is (571)270-3489. The examiner can normally be reached M-F 10-6.
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, Hosain Alam can be reached at 571-272-3978. 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.
/CRAIG S GOLDSCHMIDT/
Primary Examiner, Art Unit 2132
