DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status
This instant application No. 19/085,045 has claims 1-20 pending.
Priority / Filing Date
Applicant’s claim for priority of CHINA CN202411899919.9 (filed on December 20, 2024) is acknowledged. The effective filing date of the instant application is December 20, 2024.
Abstract
The abstract of the disclosure is objected due to the use of implied language. Note that in the abstract, the language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc… See MPEP § 608.01(b).
Note that in the abstract, Applicant recites “The present disclosure provides a method for…” on line 1. This citation clearly provokes the use of implied language. Revision and/or correction are required. One example is as follows:
“A method is provided for…”
Drawings
The drawings filed on March 20, 2025 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609(C), the Applicant’s submissions of the Information Disclosure Statements filed on 20 March 2025 and 9 January 2025 are acknowledged by the Examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P. 609 C(2), a copy of the PTOL-1449 initialed and dated by the Examiner is attached to the instant Office action.
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.
The claimed invention in claims 1-20 are directed to a judicial exception (i.e., an abstract idea) without significantly more.
Claims 1-20 pass step 1 of the 35 U.S.C. 101 analysis since each claim is directed to a method, an electronic device comprising at least one processor and a memory connected to the at least one processor (i.e., hardware components per Figure 8 and as known in the art), a distributed file system comprising a plurality of device nodes set in the electronic device; and a non-transitory computer-readable storage medium.
Claims 1, 14, and 19-20 recites, in part, elements that are directed to an abstract idea (“Courts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.” Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015)). The claims each is directed to the abstract idea of organizing and managing information by reciting a method of processing directory metadata by:
determining and loading a “first index shard” based on a request;
determining a “metadata shard” based on that index;
adjusting information in the shards (e.g., updating counts or deleting records).
The above steps are fundamental components of data management and organization. The concept of using an index to find and update a specific record in a larger database or file system is a long-standing human activity (e.g., using a library card catalog to find a book and the updating a checkout status). This falls under the “Certain Methods of Organizing Human Activity” or “Mental Processes” groupings of abstract ideas. The use of terms like index shard and metadata shard does not change the underlying nature of the process which is logical manipulation of data.
Under step 2A – prong 2 of the abstract idea analysis, the claims each recites distributed file system, device nodes, cells, and shards as generic components as a high level. The claim does not recite any specific improvement to the functioning of the computer or network itself (e.g., no new shard structures, no specific concurrency or memory mechanism). Each claim simply uses generic computer components as tools to perform the abstract data-organization idea which does not result in a transformation of a physical object or represent a specific technical solution to a technical problem. Simply using a distributed system to manage file data more efficiently is not a patent-eligible improvement to computer functionality.
Under step 2B of the abstract idea analysis, the specific steps of calculating an index code, adjusting information (by incrementing or decrementing counts), and deleting/creating records are routine, well-understood, and convention (WURC) functions of any DBMS. It is noted that applying a known organizational concept, such as sharding or indexing, to a specific type of data, such as directory metadata, does not constitute an inventive concept. The background of the limitations does not provide any indication that the computer components (e.g., a distributed file system, device node, index shard, metadata shard, index and the like) are not off-the-shelf computer components. The Symantec, TLI, and OOP Techs court decisions cited in MPEP 2106.05(d)(II) indicate that mere receiving, generating, storing, determining, identifying, and transmitting of data over a network are a well-understood, routine, and conventional functions when claimed in a merely generic manner (as it is here). Accordingly, a conclusion that the claims are WURC activities is supported under Berkheimer Option 2. For these reasons, there is no inventive concept in each claims, thus, the claims are ineligible.
Regarding claims 2 and 15, each claim is directed to the abstract idea of calculating and loading/routing data. The steps of calculating an index code based on a directory identifier and calculating a metadata code is a mathematical derivation or a mental/logic process. The claim does not represent a technical improvement to the computer’s hardware or internal functionality. Using a hash or an ID to locate a data shard is a long-standing, convention practice in database management and does not add “significantly more.” Thus, the claims are ineligible.
Regarding claims 3 and 16, each claim recites definitions for a specific type of request (i.e., deletion or creation) and the path information. Further, the remaining limitations of calculating a first index code…, determining a target parent path…, and calculating a second index code… describe a mental process or logical exercise that can be implemented in a human mind that is routine in database management and fails to add “significantly more” to the abstract idea. Thus, the claims are ineligible.
Regarding claim 4, the claim recites calculating an MD5 value of the target path; and determining the first index code according to the MD5 value… describing a mathematical operation for distributing keys among shards. Hash-based sharding is a conventional technique in distributed storage and databases. Implementing a known hashing/mapping scheme on generic hardware does not add significantly more than the abstract idea and fails to provide an inventive concept. Thus, the claim is ineligible.
Regarding claims 5 and 17, each claim recites definitions for a specific type of request (i.e., modification) and the path information…comprises an initial and final path. Further, the remaining limitations of calculating the index code…comprises: determining a first parent path…; calculating a third index…, determining a second parent path, and calculating a fourth index code… describe a mental process or logical exercise that can be implemented in a human mind. Each claim appears to narrow the abstract method and adds more mathematical calculations and determinations. The steps in each claim are still abstract since they direct to mathematical relationships and organizing directory data that are routine in database management and fail to provide an inventive concept. Thus, the claims are ineligible.
Regarding claims 6 and 18, each claim recites definition for the processing request comprises path information of the directory metadata. Further, the remaining limitations of determining the metadata shard…comprises: determining a metadata code…; determining the metadata shard… describe a mental process or logical exercise that can be implemented in a human mind. Each claim appears to recite the familiar pattern of index lookup followed by pointer dereference (i.e., index entry -> metadata code -> metadata shard) which is a standard data access pattern of the abstract data retrieval/organization. The steps in each claim do not add any specific technical improvement or unconventional implementation. Thus, the claims are ineligible.
Regarding claim 7, the claim recites determining the metadata code…comprises: determining index information…; determining the metadata code… describe a mental process or logical exercise that can be implemented in a human mind. Each claim appears to recite the familiar pattern of index lookup followed by pointer dereference (i.e., index shard -> metadata code) which is a standard data access pattern of the abstract data retrieval/organization. The steps in the claim do not add any specific technical improvement or unconventional implementation. Thus, the claim is ineligible.
Regarding claim 8, the claim recites definition for the processing requests indicates deletion of the directory metadata and the metadata shard comprises a fist/second metadata shard… Further, the remaining limitations of adjusting the information…comprises: deleting the first metadata shard; subtracting a quantity of the directory metadata… define business-rule-like logic for how directory and parent metadata are updated on delete (i.e., deleting child’s metadata and decreasing parent’s count). This logic is abstract data structure maintenance with no claimed new storage format or mechanism. It is standard file-system behavior expressed functionality and does not provide inventive concept. Thus, the claim is ineligible.
Regarding claim 9, the claim recites definition for the processing requests indicates deletion of the directory metadata and the metadata shard comprises a fist/second metadata shard… Further, the remaining limitations of adjusting the information…comprises: creating the first metadata shard; increasing a quantity of the directory metadata… define business-rule-like logic for how directory and parent metadata are updated on delete (i.e., adding child’s metadata and increasing parent’s count). This logic is abstract data structure maintenance with no claimed new storage format or mechanism. It is standard file-system behavior expressed functionality and does not provide inventive concept. Thus, the claim is ineligible.
Regarding claim 10, the claim recites definition for the processing requests indicates modification of a directory… and the metadata shard comprises a third/fourth metadata shard… Further, the remaining limitations of adjusting the information…comprises: increasing a quantity…; subtracting a quantity… define the standard logic for moving a directory between parents (i.e., increasing new parent’s count and decreasing old parent’s count). This logic recites abstract data maintenance rules with no claimed new storage format or mechanism. It is standard file-system behavior expressed functionality and does not provide inventive concept. Thus, the claim is ineligible.
Regarding claim 11, the claim recites definition for the processing requests indicates deletion of the directory metadata… Further, the remaining limitations of adjusting the index information…comprises: determining the second index shard…; deleting the index information… define basic index entry deletion based on a key or path. This logic is routine in any indexed storage system and does not provide inventive concept. Thus, the claim is ineligible.
Regarding claim 12, the claim recites definition for the processing requests indicates creation of the directory metadata… Further, the remaining limitations of adjusting the index information…comprises: determining the second index shard…; creating the index information… define basic index entry creation based on a key or path. This logic is routine in any indexed storage system and does not provide inventive concept. Thus, the claim is ineligible.
Regarding claim 13, the claim recites definition for the processing requests indicates modification…, path information…comprises a final path and an initial path. Further, the remaining limitations of adjusting the index information…comprises: upon determining the index shard contains directory metadata, determining…and deleting the index information…; determining the modified paths…; creating index information of a modified path… define update logic for index entries when directories move (i.e., find existing entries, delete them, compute modified paths, and create new entries in the appropriate shards). These steps are conventional index maintenance operations expressed logically with no particular technical improvement. Thus, the claim is ineligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-3, 6-7, 14-16, and 18-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Liu (Pub. No. US 2021/0360065, published on November 18, 2021) in view of Graham et al. (Pat. No. US 9734180, published on August 15, 2017; hereinafter Graham).
Regarding claims 1, 14, and 19-20, Liu clearly shows and discloses a method for processing directory metadata in a distributed file system (Abstract), applied to a distributed file system, wherein a device node of the distributed file system is provided with a metadata cell containing a plurality of metadata shards (the partition of the server cluster for storing metadata includes at least one node. The node may include, but is not limited to, physical server, virtual machine, and container. Each node in the partition stores the same metadata, and the metadata stored in nodes at different partitions are different. Each partition of the server cluster for storing metadata saves the metadata of the partition, [0042]) and an index cell containing a plurality of index shards (the root partition stores the area IDs of the various partitions of the server cluster for storing metadata. As the amount of metadata increases, the number of files stored in the entire distributed file system can be increased by adding new partitions. The metadata of the entire distributed file system is scattered and stored in different partitions. Each partition has a unique area ID. Correspondingly, the ID for each metadata consists of an area ID and an index ID. Optionally, each partition has a unique area ID, and each metadata includes a unique index ID, [0041]); an electronic device, applied to a distributed file system, wherein a device node of the distributed file system is provided with a metadata cell containing a plurality of metadata shards and an index cell containing a plurality of index shards ([0041]-[0042]), the electronic device comprises: at least one processor; and a memory communicatively connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor (Figure 5), and the instructions are executed by the at least one processor to enable the at least one processor to implement the method; a distributed file system, comprising a plurality of device nodes, wherein the device node is provided with a metadata cell and an index cell; the metadata cell comprises metadata shards corresponding to directory metadata in the device node, and the index cell comprises a plurality of index shards, each index shard is configured to store index information of a portion of the directory metadata; wherein the device nodes are set in the electronic device [according to claim 14] ([0041]-[0042]); and a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute (Figure 5) the following steps of the method comprising:
in response to a processing request (the execution body of the distributed metadata management method for a distributed file system (for example, the terminal device shown in FIG. 1) may directly receive a request to access the target metadata. The request is sent by a first client, [0038]),
determining and loading a first index shard corresponding to directory metadata indicated by the processing request (The request sent by the first client carries IDs of the target metadata. The IDs include an area ID of the target metadata and an index ID of the target metadata. Wherein, the area ID refers to a mark that determines a target partition in the various partitions where the target metadata is stored, [0040]. The area IDs of all the metadata are stored in the root partition, [0059]), and
determining a metadata shard corresponding to the directory metadata indicated by the processing request according to the first index shard (the root partition stores the area IDs of the various partitions of the server cluster for storing metadata. As the amount of metadata increases, the number of files stored in the entire distributed file system can be increased by adding new partitions. The metadata of the entire distributed file system is scattered and stored in different partitions. Each partition has a unique area ID. Correspondingly, the ID for each metadata consists of an area ID and an index ID, [0041]. Metadata is stored in a partition of the server cluster for storing metadata, wherein the area IDs of all the metadata are stored in the root partition, and after routing to the partition according to the area ID, the metadata is found based on the index ID of the metadata, [0059]).
Graham then discloses:
wherein the processing request represents an adjustment to directory metadata in a device node (the system further comprises a request processor to receive an updated object and object metadata properties, to write the updated model and object metadata properties to the object store, [Column 2, Lines 5-11]);
adjusting information in the determined metadata shard, and adjusting index information corresponding to the directory metadata in a second index shard related to the directory metadata indicated by the processing request (a request processor to update the secondary index based upon the updated object metadata properties. The object store and the secondary index can be updated atomically, [Column 2, Lines 5-11]. When an object is updated, if that update affects any of the metadata properties in the secondary index, the key-value entry in the secondary index table 206b is modified to reflect those changes, [Column 7, Lines 28-51]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Graham with the teachings of Liu for the purpose of managing updates to directory metadata in a manner that preserves the consistency of search and lookup operations, by atomically updating both the metadata and the associated index structures and improving the reliability and efficiency of subsequent metadata queries and retrievals.
Regarding claims 2, and 15, Liu further discloses the processing request comprises path information of the directory metadata (Upon storing metadata, the root node starts to store level by level and a multi-level tree structure is built. The root directory is stored in the root partition. Corresponding to the multi-level tree structure, a multi-level tree directory is generated for storage, and sub-directories are constructed level by level starting from the root directory, wherein the root directory is stored in the root partition, [0046]. The above execution body receives the area ID returned by the first client. The execution body can send the area ID stored in the root partition to the first number of connected clients, wherein the root partition refers to the first partition of the server cluster for storing metadata, [0047]-[0052]);
wherein determining and loading the first index shard corresponding to the directory metadata indicated by the processing request (The request sent by the first client carries IDs of the target metadata. The IDs include an area ID of the target metadata and an index ID of the target metadata. Wherein, the area ID refers to a mark that determines a target partition in the various partitions where the target metadata is stored, [0040]. The area IDs of all the metadata are stored in the root partition, [0059]).
Graham then discloses:
calculating an index code according to the path information of the directory metadata, wherein a value of the index code represents a code of the index shard (storing and retrieving object data and associated metadata. Objects can be uniquely identified within the system using an “object key” comprising one or more namespace identifiers and a unique “object id” within the identified namespace. In some embodiments, the namespace identifiers include a “tenant id” and a “bucket id,” where the tenant id uniquely identifies a tenant (i.e., a customer, a user, or any other top-level entity) within the object storage system and the bucket id uniquely identifies a collection of objects (or “bucket”) defined by and belonging to the tenant, [Column 4, Lines 1-13]);
loading the first index shard corresponding to the directory metadata indicated by the processing request according to the index code (The distributed key-value store 120 may include a “primary index” 120a for efficiently storing and retrieving object data and metadata. Thus, for example, the primary index 120a may include the mapping between object keys and storage locations utilized by the partitions service 116. The distributed key-value store 120 may also include a “secondary index” 120b for efficient object retrieval based on properties of object metadata itself, [Column 5, Lines 36-47]).
Regarding claims 3, and 16, Graham further discloses when the processing request indicates deletion or creation of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]), the path information of the directory metadata comprises a target path; the target path indicates a path of the directory metadata (the commands may be specified via HTTP requests according a REST-based API. A command is forwarded to one or more peer storage engines 108 as needed. For example, if the command is an object read command comprising an object key, the request processor 114 (using the partition service 116) determines the location of the object's data and forwards the request as needed. The appropriate storage engines 108 would read the object's data from a storage device 118, [Column 6, Lines 13-32]);
wherein calculating the index code according to the path information of the directory metadata (storing and retrieving object data and associated metadata. Objects can be uniquely identified within the system using an “object key” comprising one or more namespace identifiers and a unique “object id” within the identified namespace. In some embodiments, the namespace identifiers include a “tenant id” and a “bucket id,” where the tenant id uniquely identifies a tenant (i.e., a customer, a user, or any other top-level entity) within the object storage system and the bucket id uniquely identifies a collection of objects (or “bucket”) defined by and belonging to the tenant, [Column 4, Lines 1-13]).
Liu then discloses:
calculating a first index code according to the target path (The above-mentioned execution body is routed to the first target partition corresponding to the area ID, in each partition of the server cluster for storing metadata. The routing process is a process of directly routing to the first target partition corresponding to the area ID, in each partition of the server cluster for storing metadata, according to the area ID, [0054]);
determining a target parent path of a parent directory of the directory metadata in the target path according to the target path of the directory metadata (there is a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata. All nodes are saved as a tree structure, wherein the “user-1 (user-1)” can be the parent node of the “pic (picture)”, the “user-1 (user-1)”, “user-2 (user-2)” and “user-3 (user-3)” can be sibling nodes at the same level, [0048]);
calculating a second index code according to the target parent path (the above-mentioned execution body finds the target metadata in the first target partition based on the index ID. Determine whether the index ID includes a second area ID. In response to determining that the index ID includes a second area ID, parse the second area ID, route to the second target partition, and find the target metadata in the second target partition, [0056]).
Regarding claims 6, and 18, Liu further discloses the processing request comprises path information of the directory metadata (Upon storing metadata, the root node starts to store level by level and a multi-level tree structure is built. The root directory is stored in the root partition. Corresponding to the multi-level tree structure, a multi-level tree directory is generated for storage, and sub-directories are constructed level by level starting from the root directory, wherein the root directory is stored in the root partition, [0046]. The above execution body receives the area ID returned by the first client. The execution body can send the area ID stored in the root partition to the first number of connected clients, wherein the root partition refers to the first partition of the server cluster for storing metadata, [0047]-[0052]);
wherein determining the metadata shard corresponding to the directory metadata indicated by the processing request according to the first index shard comprises:
determining a metadata code corresponding to the directory metadata in the first index shard according to the path information of the directory metadata indicated by the processing request, wherein the metadata code represents a code of the metadata shard (the root partition stores the area IDs of the various partitions of the server cluster for storing metadata. As the amount of metadata increases, the number of files stored in the entire distributed file system can be increased by adding new partitions. The metadata of the entire distributed file system is scattered and stored in different partitions. Each partition has a unique area ID. Correspondingly, the ID for each metadata consists of an area ID and an index ID, [0041];
determining the metadata shard corresponding to the directory metadata indicated by the processing request according to the metadata code (Metadata is stored in a partition of the server cluster for storing metadata, wherein the area IDs of all the metadata are stored in the root partition, and after routing to the partition according to the area ID, the metadata is found based on the index ID of the metadata, [0059]).
Regarding claim 7, Liu further discloses determining the metadata code corresponding to the directory metadata in the first index shard according to the path information of the directory metadata indicated by the processing request (the root partition stores the area IDs of the various partitions of the server cluster for storing metadata. As the amount of metadata increases, the number of files stored in the entire distributed file system can be increased by adding new partitions. The metadata of the entire distributed file system is scattered and stored in different partitions. Each partition has a unique area ID. Correspondingly, the ID for each metadata consists of an area ID and an index ID, [0041]. Metadata is stored in a partition of the server cluster for storing metadata, wherein the area IDs of all the metadata are stored in the root partition, and after routing to the partition according to the area ID, the metadata is found based on the index ID of the metadata, [0059]) comprises:
determining index information corresponding to the path information in the first index shard according to the path information of the directory metadata indicated by the processing request (wherein the area IDs of all the metadata are stored in the root partition, and after routing to the partition according to the area ID, the metadata is found based on the index ID of the metadata, [0059]);
determining the metadata code corresponding to the index information in the first index shard (the above-mentioned execution body is routed to the first target partition corresponding to the area ID, in each partition of the server cluster for storing metadata. The routing process is a process of directly routing to the first target partition corresponding to the area ID, in each partition of the server cluster for storing metadata, according to the area ID, [0054]).
Claim 4 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Liu in view of Graham and further in view of Jacob et al. (Pub. No. US 2017/0111435, published on April 20, 2017; hereinafter Jacob).
Regarding claim 4, Jacob then discloses calculating the first index code according to the target path comprises:
calculating an MD5 value of the target path (A masking module 304 may be used to, in one embodiment, create a hash, such as an MD5 hash, of the file path, [0038]);
determining the first index code according to the MD5 value and a preset number of the index shards in the index cell (using the last log 2(totalNumMountPoints) bits of the hash, or the mod by the number of mounts, the mount 306 that matches the supplied bits may be searched using a sharding algorithm based on the entire hash. If the file is not found, the hash algorithm may be repeated by looking at the log 2(totalNumMountPoints/2) bits of the hash, [0038]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Jacob with the teachings of Liu, as modified by Graham, for the purpose of enabling clients to securely manage data files within a filesystem associated with a file path and a content identifier based on a mapped bucket associated with the host name and the content identifier.
Claim 13 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Liu in view of Graham and further in view of Opincariu et al. (Pat. No. US 12314240, filed on March 18, 2021; hereinafter Opincariu).
Regarding claim 13, Graham then discloses wherein adjusting the index information corresponding to the directory metadata in the second index shard related to the directory metadata indicated by the processing request comprises: upon determining that the index shard contains the directory metadata, determining the index shard as the second index shard and deleting the index information containing the directory metadata in the second index shard (The successful processing of the create index request is the establishment of a data structure within the object system (more specifically the index definitions 206a) such that when an object is inserted, updated, or deleted in the bucket, the secondary index table 206b can be correspondingly updated. When an object is deleted, the corresponding key-value pair is removed from the secondary index table 206b. When an object is updated, if that update affects any of the metadata properties in the secondary index, the key-value entry in the secondary index table 206b is modified to reflect those changes, [Column 7, Lines 28-51]).
Opincariu then discloses:
wherein when the processing request indicates modification of a directory of the directory metadata, path information of the directory metadata comprises a final path and an initial path (query 902 is submitted as a job, and then job is briefly paused by data discover service 904 to fetch indexes and determine updated path information based on available indexes and/or metadata that can be used to refine the execution of the query. The updated path information may be inserted into query 902 and replace the client's original query path, thereby creating updated query 908, [Column 28, Lines 31-45]);
determining modified paths of a subdirectory of the directory metadata and the directory metadata according to the final path and the initial path (a client may submit a query that specifies a path for a folder, which may be replaced by paths of only the subfolders which might include the value being queried for. In some embodiments, the query request is processed as a job, which is paused briefly (e.g., for a second or less) to allow for data discovery service 806 to determine subfolder paths and replace the path specified in the query request with subfolders where the value is or might be located, [Column 26, Lines 31-48]);
creating index information of a modified path in a corresponding second index shard according to the modified paths of the subdirectory of the directory metadata and the directory metadata (If the filter is, for example, built around a customer ID, then the data discover service will run through the index and determine whether there are any partitions that include the customer ID and return those partitions as subfolders rather than the parent folder that includes all of the subfolders. For example, if the Bloom filters for subfolder 912A and 912Z indicate that the customer ID could include the customer ID being filtered for and that subfolder 912B definitely does not include the customer ID, then the client query is updated to search subfolders 912A and 912Z but not subfolder 912B, Column 28, Lines 2-16]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Opincariu with the teachings of Liu, as modified by Graham, for the purpose of enhancing data indexing for efficient querying of the entire data set when the values of indexed fields are modified or deleted based on a workflow to perform an incremental update for the respective indexing partition.
Claims 8-12 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Liu in view of Graham and further in view of Wang et al. (Pub. No. US 2025/0068469, filed on November 8, 2024; hereinafter Wang).
Regarding claim 8, Graham then discloses when the processing request indicates deletion of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]).
Liu then discloses the metadata shard comprises a first metadata shard corresponding to the directory metadata and a second metadata shard corresponding to a parent directory of the directory metadata (there is a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata. All nodes are saved as a tree structure, wherein the “user-1 (user-1)” can be the parent node of the “pic (picture)”, the “user-1 (user-1)”, “user-2 (user-2)” and “user-3 (user-3)” can be sibling nodes at the same level. Optionally, a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata, wherein the root node of the tree may be “jfs-root (root node)”, the “1.jpg (picture 1)” may be a fourth-level node, and the “user-2 (user-1)” can be a second-level node, [0048]).
Wang then discloses wherein adjusting the information in the determined metadata shard comprises: deleting the first metadata shard; subtracting a quantity of the directory metadata from information of the second metadata shard (migrating all shards distributed in the at least one first target node to a first node other than the at least one first target node; and deleting the at least one first target node, [0020]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Wang with the teachings of Liu, as modified by Graham, for the purpose of managing a quantity of resources of nodes occupied by a plurality of shards of the target index which can be dynamically adjusted such that flexibility of data writing is effectively improved, and utilization of cluster resources is effectively improved.
Regarding claim 9, Graham further discloses when the processing request indicates creation of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]).
Liu then discloses the metadata shard comprises a first metadata shard corresponding to the directory metadata and a second metadata shard corresponding to a parent directory of the directory metadata (there is a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata. All nodes are saved as a tree structure, wherein the “user-1 (user-1)” can be the parent node of the “pic (picture)”, the “user-1 (user-1)”, “user-2 (user-2)” and “user-3 (user-3)” can be sibling nodes at the same level. Optionally, a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata, wherein the root node of the tree may be “jfs-root (root node)”, the “1.jpg (picture 1)” may be a fourth-level node, and the “user-2 (user-1)” can be a second-level node, [0048]).
Wang then discloses wherein adjusting the information in the determined metadata shard comprises: creating the first metadata shard; increasing a quantity of the directory metadata to information of the second metadata shard (After newly adding the at least one second node to the ES cluster, the resource scheduling apparatus may migrate the at least one shard of the target index to the at least one second node. Each second node may carry one or more shards of the target index, [0112]).
Regarding claim 10, Graham further discloses when the processing request indicates modification of a directory of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]).
Liu then discloses the metadata shard comprises a third metadata shard corresponding to a parent directory indicated by a final path of the directory metadata and a fourth metadata shard corresponding to a parent directory indicated by an initial path of the directory metadata (there is a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata. All nodes are saved as a tree structure, wherein the “user-1 (user-1)” can be the parent node of the “pic (picture)”, the “user-1 (user-1)”, “user-2 (user-2)” and “user-3 (user-3)” can be sibling nodes at the same level. Optionally, a multi-level tree-type directory tree in one of the partitions in the server cluster 301 for storing metadata, wherein the root node of the tree may be “jfs-root (root node)”, the “1.jpg (picture 1)” may be a fourth-level node, and the “user-2 (user-1)” can be a second-level node, [0048]).
Wang then discloses adjusting the information in the determined metadata shard comprises: increasing a quantity of the directory metadata to information of the third metadata shard; subtracting a quantity of the directory metadata from information of the fourth metadata shard (the resource scheduling apparatus may newly add the at least one third node to the ES cluster (for example, a writer cluster), so that a shard in the fourth target node is migrated to the at least one third node, [0167]).
Regarding claims 11, Graham further discloses when the processing request indicates deletion of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]), path information of the directory metadata comprises a target path (the commands may be specified via HTTP requests according a REST-based API. A command is forwarded to one or more peer storage engines 108 as needed. For example, if the command is an object read command comprising an object key, the request processor 114 (using the partition service 116) determines the location of the object's data and forwards the request as needed. The appropriate storage engines 108 would read the object's data from a storage device 118, [Column 6, Lines 13-32]).
Wang then discloses wherein adjusting the index information corresponding to the directory metadata in the second index shard related to the directory metadata indicated by the processing request comprises: determining the second index shard according to the target path of the directory metadata; deleting the index information corresponding to the target path of the directory metadata from the second index shard (newly add at least one third node to the ES cluster when remaining available duration of the spot resource used by the fourth target node is less than a duration threshold; migrate all shards distributed in the fourth target node to the at least one third node; and delete the fourth target node, [0223]).
Regarding claim 12, Graham further discloses when the processing request indicates creation of the directory metadata (It will be understood that these REST APIs generally provide at least the following commands: creating a bucket, retrieving, updating, and deleting a bucket by bucket id; retrieving a list of buckets; creating an object, retrieving, updating, and deleting an object by bucket id and object id; and retrieving a listing of objects within a bucket by bucket id (sometimes referred to as a “list bucket operation”), [Column 4, Line 40 – Column 5, Line 7]), path information of the directory metadata comprises a target path (the commands may be specified via HTTP requests according a REST-based API. A command is forwarded to one or more peer storage engines 108 as needed. For example, if the command is an object read command comprising an object key, the request processor 114 (using the partition service 116) determines the location of the object's data and forwards the request as needed. The appropriate storage engines 108 would read the object's data from a storage device 118, [Column 6, Lines 13-32]).
Wang then discloses wherein adjusting the index information corresponding to the directory metadata in the second index shard related to the directory metadata indicated by the processing request comprises: determining the second index shard according to the target path of the directory metadata; creating the index information corresponding to the target path of the directory metadata in the second index shard (newly adding at least one fifth node to the ES cluster when the data read frequency of the target index is greater than an upper limit of the target frequency range; and newly adding at least one replica of the target index to each fifth node, [0032]).
Allowable Subject Matter
Claims 5, and 17 are objected for being dependent on a respective rejected base claim but would be allowable over the prior art, given the pending 35 U.S.C. 101 rejections are also resolved, if rewritten in independent form to incorporate the limitations of the respective base claim and all intervening claim(s).
Relevant Prior Art
The following references are deemed relevant to the claims:
Tian et al. (Pub. No. US 2025/0199695) teaches the file size in the resource management node may be determined and saved before the worker node updates the file size in the first index data table. Before updating the file size in the first index data table based on the modification information, the worker node first changes, in the resource management node based on the modification information and the inode identifier, a file corresponding to the inode identifier to obtain a changed file size, so that after the worker node fails, the corresponding file size may be obtained from the resource management node based on the inode identifier.
Su et al. (Pub. No. US 2022/0129468) teaches an active layer of the index includes a first shard group, and shards in the first shard group are configured to store indexes of a part of data objects in a streaming storage system. In response to determining that the state of the first shard group meets a predetermined expansion condition, a second shard group is created in the index, and shards in the second shard group are configured to store indexes of data objects that will enter the storage system. The storage system is managed based on the shards in an active layer (where the second shard group is located) and frozen layers (where the second shard group) in the index. The number of shards in the storage system can be dynamically set to process streaming data at a relatively high speed, and it is suitable for processing streaming data that continuously enters the storage system.
Contact Information
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Son Hoang whose telephone number is (571) 270-1752. The Examiner can normally be reached on Monday – Friday (7:00 AM – 4:00 PM).
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Sherief Badawi can be reached on (571) 272-9782. 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.
/SON T HOANG/Primary Examiner, Art Unit 2169
March 7, 2026