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 .
This Office action is in response to the amendments, arguments and remarks, filed on 6/18/2026, in which claim(s) 1-6 and 8-20 is/are presented for further examination.
Claim(s) 1, 6, 8, 10, 15 and 16 has/have been amended.
Claim(s) 7 and 21 has/have been cancelled or has/have been previously cancelled.
Response to Amendment
Applicant has cancelled claim(s) 21. Consequently, the objection(s) to the claim(s) for informalities is/are now moot, and, thus has/have been withdrawn.
Applicant’s amendment(s) to claim(s) 1, 6, 8, 10, 15 and 16 has/have been accepted.
The examiner thanks applicant’s representative for pointing out where s/he believes there is support for the amendment(s).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-6 and 8-20, filed on 6/18/2026, have been fully considered but they are not persuasive. Accordingly, this action has been made FINAL.
Applicant’s arguments with respect to the rejection(s) of claim(s) 1-6 and 8-20, under 35 U.S.C. 103, see the middle of page 12 to the top of page 19 of applicant’s remarks, filed on 6/18/2026, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim(s) 1, 2, 5, 6, 8, 10, 11, 14, 15, 16, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al., US 2013/0111187 A1 (hereinafter “Liu”) in view of Tankersley et al., US 2019/0095478 A1 (hereinafter “Tank”) in further view of Deshmukh et al., US 2011/0137864 A1 (hereinafter “Desh”).
Claims 1, 10 and 16
Liu discloses a method for executing data access requests in a distributed storage system, comprising:
receiving, by a router node of the distributed storage system from a service application (Liu, [0089], see the DHT [i.e., “Distributed Hash Table” see Liu, [0038]] routing library may be located in the DHT block storage driver or a storage node [i.e., “router node”] in the DHT-based Key-value storage system; and Liu, Fig. 7, see Master storage node, Backup nodes and Storage node disclosing a distributed storage system), a data access request to read data from one of a plurality of data storage nodes, the data access request comprising a key associated with the data (Liu, [0083], see step 401: A DHT block storage driver receives a request for an LBA-based [i.e., “Logical Block Addressing” see Liu, [0026]] read operation on a volume; and Liu, [0028], see converts the LBA-based operation request into a key (Key) addressing-based operation request, where the Key addressing-based operation request carries a Key corresponding to data to be operated), and the data storage nodes comprising key-value data stores (Liu, [0078], see, in this embodiment, the DHT-based Key-value storage system supports different write operation policies. For example, the write operation policy may be set as follows: if two of three copies are written successfully, the write operation succeeds, which means that, when data is stored in the DHT-based Key-value storage system, the data is written into three different storage nodes (three copies); in the write operation process, as long as the data is successfully written into two storage nodes, the whole write operation may be considered to be successful; the remaining copy may be synchronized by a daemon. …”);
by the router node (Liu, [0089], see the DHT [i.e., “Distributed Hash Table” see Liu, [0038]] routing library may be located in the DHT block storage driver or a storage node [i.e., “router node”] in the DHT-based Key-value storage system; and Liu, Fig. 7, see Master storage node, Backup nodes and Storage node disclosing a distributed storage system),
by the router node,
transmitting, by the router node to the data storage node, a request (Liu, [0091], see the DHT routing library hashes the Key of the data to be read carried in the received Key addressing-based read operation request, then determines that a storage node taking charge of a Hash region in which the hashed Key is located is the master storage node of the data to be read, and finally the DHT routing library sends the Key addressing-based read operation request to the master storage node)
receiving, by the router node, a plurality of data from the data storage node (See Liu, [0091] above and Liu, [0092], see, step 405: The master storage node reads, according to the key of the data to be read, the locally stored data to be read and a version of the data to be read),
transmitting, from the router node, the plurality of data to the service application (Liu, [0094], see, step 406: If the read operation succeeds, the master storage node returns the read data, the version of the read data, and a read success response to the DHT routing library).
Lui does not appear to explicitly disclose generating a single hash value from a partial key formed of a subset of fields of the key, wherein the subset of the key includes a time component, and wherein the partial key corresponds to a storage bucket of a set of storage buckets, each storage bucket storing a plurality of time-bounded records associated with the partial key;
determining among the plurality of data storage nodes, a storage node that can satisfy the data access request based at least in part on the single hash value generated from the partial key;
comprising a bulk get operation with the single hash value, wherein the bulk get operation is configured to receive a plurality of data from the storage node in a single request using the single hash value, wherein the plurality of data comprises the plurality of time-bounded records associated with the partial key;
the data storage node accessing each of the plurality of data using the single hash value generated from the partial key, wherein each of the plurality of data is identifiable by the data storage node by the partial key.
Tank discloses generating a single hash value from a partial key formed of a subset of fields of the key, wherein the subset of the key includes a time component, and wherein the partial key corresponds to a storage bucket of a set of storage buckets, each storage bucket storing a plurality of time-bounded records associated with the partial key (Tank, [0544], see the data intake and query system can implement policies for creating hash buckets based on primary partition keys [i.e., keys are hashed with the same hash values going into the same bucket]. For example, user-selected primary partition keys can be added to policies used at index time to create hash buckets. At index time, the data intake and query system can run a hashing algorithm to generate hash values from primary partition key values of data being ingested. Each hash value can define the scope of data written to its hash bucket. Subsequently ingested data that has the same hash values can be written to the same hash bucket; and Tank, [0547], see hash buckets can be partitioned by time in addition to one or more primary partition keys. As such, multiple hash buckets with different time range values that are associated with the same primary partition key value can coexist. For example, source-based hash buckets can be limited by a time range such that metrics data from the same source can be written to different source-based hash buckets having different time ranges);
comprising a bulk get operation with the single hash value, wherein the bulk get operation is configured to receive a plurality of data from the storage node in a single request using the single hash value, wherein the plurality of data comprises the plurality of time-bounded records associated with the partial key (Tank, [0842], see a third request 6810C may comprise a “single get” request [i.e., corresponds to the “bulk get operation”] comprising a GET operation that is specified by a particular path including a single relationship identifier [i.e., corresponds to the “single hash value”], as shown in FIG. 54. The response may comprise retrieving and displaying of the relationship definition corresponding to the specified relationship identifier; Nick, [0544], see the data intake and query system can implement policies for creating hash buckets based on primary partition keys [i.e., keys are hashed with the same hash values going into the same bucket]. For example, user-selected primary partition keys can be added to policies used at index time to create hash buckets. At index time, the data intake and query system can run a hashing algorithm to generate hash values from primary partition key values of data being ingested. Each hash value can define the scope of data written to its hash bucket. Subsequently ingested data that has the same hash values can be written to the same hash bucket; and Tank, [0547], see hash buckets can be partitioned by time in addition to one or more primary partition keys. As such, multiple hash buckets with different time range values that are associated with the same primary partition key value can coexist. For example, source-based hash buckets can be limited by a time range such that metrics data from the same source can be written to different source-based hash buckets having different time ranges);
the data storage node accessing each of the plurality of data using the single hash value generated from the partial key, wherein each of the plurality of data is identifiable by the data storage node by the partial key (Tank, [0842], see a third request 6810C may comprise a “single get” request [i.e., corresponds to the “bulk get operation”] comprising a GET operation that is specified by a particular path including a single relationship identifier [i.e., corresponds to the “single hash value”], as shown in FIG. 54. The response may comprise retrieving and displaying of the relationship definition corresponding to the specified relationship identifier; and Tank, [0541], see, during search time, a search head can search buckets of a number of indexes to retrieve query results. By organizing data into one or more indexes having one or more buckets, each spanning a certain time range and organized by age, the data intake and query system can search particular buckets while avoiding the need to search other buckets. Since queries are typically targeted at specific time ranges, having buckets partition by time ranges avoids the need to search buckets not including the specified range).
Liu and Tank are analogous art because they are from the same field of endeavor, such as storing/retrieving data in a distributed system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Liu and Tank before him/her, to modify the distributed system of Liu to include the bulk get of Tank because it would allow efficient data retrieval.
The suggestion/motivation for doing so would have been to because the data intake and query system maintains the underlying machine data and uses a late-binding schema for searching the machine data, it enables a user to continue investigating and learn valuable insights about the machine data, see Tank, [0085].
Therefore, it would have been obvious to combine Tank with Liu to obtain the invention as specified in the instant claim(s).
The combination of Liu and Tank does not appear to explicitly disclose determining among the plurality of data storage nodes, a storage node that can satisfy the data access request based at least in part on the single hash value generated from the partial key.
Desh discloses determining among the plurality of data storage nodes, a storage node (Desh, Fig. 4, step 406 “Assign one or more disjoint partitions of a log containing the selected log records to each of multiple processing instances [i.e., corresponds to the “plurality of data storage nodes” and processing instance with the requested target key corresponds to the “determined storage node”]) that can satisfy the data access request based at least in part on the single hash value generated from the partial key (Desh, [0047], see, in block 514, the log generation component 110 hashes the target key to generate a target partition identifier [i.e., where the partition is stored corresponds to the “storage node that can satisfy the data access request based at least in part on the single hash value generated from the partial key”] and adds the target partition identifier to the buffer. In certain embodiments, the number of partitions is pre-defined (“N”), and the hash used in block 514 generates a target partition identifier in the range of 0 to (N−1); and Desh, Fig. 5B, step 514 “Hash the target key to generate a target partition identifier and add targe partition identifier to the buffer”).
Liu, Tank and Desh are analogous art because they are from the same field of endeavor, such as storing/retrieving data in a distributed system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Liu, Tank and Desh before him/her, to modify the bulk get distributed system of the combination of Liu and Tank to include the retrieval of Desh because it would allow efficient data retrieval.
The suggestion/motivation for doing so would have been to provide high throughput, reliable replication of transformed data in information systems, see Desh, [0007].
Therefore, it would have been obvious to combine Desh with the combination of Liu and Tank to obtain the invention as specified in the instant claim(s).
Claim(s) 10 and 16 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale.
With respect to claim 10, Liu discloses a system, comprising:
a memory having instructions stored thereupon (Liu, [0145], see memory); and
one or more processors coupled with the memory (Liu, [0145], see central processing unit).
With respect to claim 16, Liu disclose a non-transitory computer readable storage media having instructions stored thereupon (Liu, [0145], see memory).
Claims 2, 11 and 17
With respect to claims 2, 11 and 17, the combination of Liu, Tank and Desh discloses wherein the data storage node is determined by the router node based at least in part on a relative ordering of preference of the plurality of data storage nodes (Liu, [0090]-[0101], see sending the data request to the master storage node, if that fails, sending the data request to the first backup node and, if that fails, sending to the second backup node).
Claims 5, 14 and 20
With respect to claims 5, 14 and 20, the combination of Liu, Tank and Desh discloses further comprising:
determining, by the router node, that the data storage node is unavailable (Liu, [0095], see, if the read operation fails, the master storage node returns null or another failure response to the DHT routing library);
determining, by the router node, an alternate data storage node based on the relative ordering of preference of the plurality of data storage nodes (See below); and
transmitting, by the router node, the data access request to the alternate data storage node (Liu, [0096], see, step 407: The DHT routing library determines, according to a predetermined backup policy, a first backup node of the data to be read, and sends the Key addressing-based read operation request to the first backup node).
Claims 6 and 15
With respect to claims 6 and 15, the combination of Liu, Tank and Desh discloses wherein the plurality of data storage nodes are comprised in a set of zones, and each zone in the set of zones comprises a subset of the plurality of nodes, and the method further comprises:
determining, by the router node, the alternate data storage node based on the relative ordering of preference of the plurality of data storage nodes and a zone from the set of zones to which the data storage node belongs (Liu, [0090]-[0101], see sending the data request to the master storage node [i.e., interpreted as the first zone], if that fails, sending the data request to the first backup node [i.e., interpreted as the second zone] and, if that fails, sending to the second backup node [i.e., interpreted as the third zone]).
Claim 8
With respect to claim 8, the combination of Liu, Tank and Desh discloses wherein the key is formed from a set of service system data, and the method further comprises:
receiving, by the router node of the distributed storage system from the service application (Liu, [0089], see the DHT [i.e., “Distributed Hash Table” see Liu, [0038]] routing library may be located in the DHT block storage driver or a storage node [i.e., “router node”] in the DHT-based Key-value storage system; and Liu, Fig. 7, see Master storage node, Backup nodes and Storage node disclosing a distributed storage system), a second data access request to read second data from one of a plurality of storage nodes, the second data access request comprising the key associated with the second data (Liu, [0083], see step 401: A DHT block storage driver receives a request for an LBA-based [i.e., “Logical Block Addressing” see Liu, [0026]] read operation on a volume; and Liu, [0028], see converts the LBA-based operation request into a key (Key) addressing-based operation request, where the Key addressing-based operation request carries a Key corresponding to data to be operated); and
accessing, by the router node, the second data using the single hash value generated from the partial key and based on the determination of the data storage node (Tank, [0842], see a third request 6810C may comprise a “single get” request [i.e., corresponds to the “bulk get operation”] comprising a GET operation that is specified by a particular path including a single relationship identifier [i.e., corresponds to the “single hash value”], as shown in FIG. 54. The response may comprise retrieving and displaying of the relationship definition corresponding to the specified relationship identifier; Nick, [0544], see the data intake and query system can implement policies for creating hash buckets based on primary partition keys [i.e., keys are hashed with the same hash values going into the same bucket]. For example, user-selected primary partition keys can be added to policies used at index time to create hash buckets. At index time, the data intake and query system can run a hashing algorithm to generate hash values from primary partition key values of data being ingested. Each hash value can define the scope of data written to its hash bucket. Subsequently ingested data that has the same hash values can be written to the same hash bucket; and Liu, [0091], see the DHT routing library hashes the Key of the data to be read carried in the received Key addressing-based read operation request, then determines that a storage node taking charge of a Hash region in which the hashed Key is located is the master storage node of the data to be read, and finally the DHT routing library sends the Key addressing-based read operation request to the master storage node).
Claim(s) 3, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Tank in further view of Desh in further view of Muniswamy Reddy et al., US 10,747,739 B1 (hereinafter “Muni”).
Claims 3, 12 and 18
Claims 3, 12 and 18 incorporate all of the limitations above.
The combination of Liu, Tank and Desh does not appear to explicitly disclose wherein the relative ordering of preference is defined by the service application prior to receipt of the data access request by the router node.
Muni discloses wherein the relative ordering of preference is defined by the service application prior to receipt of the data access request by the router node (Muni, Col. 7, lines 16-31, see service requests made via the API may include an indication of one or more user preferences, such as a preferred consistency model, a preferred service request throughput level, or a service request throughput level for which a guarantee is requested. … , some or all of these user preferences may be specified when a table is created, or may be client-specific, account-specific, specific to various table types, or specified by system-wide default values, rather than being specified on a per-request basis).
Liu, Tank, Desh and Muni are analogous art because they are from the same field of endeavor, such as storing/retrieving data in a distributed system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Liu, Tank, Desh and Muni before him/her, to modify the bulk get hashing distributed system of the combination of Liu, Tank and Desh to include the order preference of Muni because it would allow customized access.
The suggestion/motivation for doing so would have been to provide an alternative access schema for items, see Muni, Col. 2, lines 40-65.
Therefore, it would have been obvious to combine Muni with the combination of Liu, Tank and Desh to obtain the invention as specified in the instant claim(s).
Claim(s) 4, 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Tank in further view of Desh in further view of Moon, US 2021/0028943 A1 (hereinafter “Moon”).
Claims 4, 13 and 19
Claims 4, 13 and 19 incorporate all of the limitations above.
The combination of Liu, Tank and Desh does not appear to explicitly disclose wherein the relative ordering of preference is defined based on geographic proximity between a location of a computing system that executes the service application and geographic locations associated with each of the plurality of data storage nodes, and the data storage node is determined by the router node as having a minimal geographic proximity among the plurality of data storage nodes.
Moon discloses wherein the relative ordering of preference is defined based on geographic proximity between a location of a computing system that executes the service application and geographic locations associated with each of the plurality of data storage nodes, and the data storage node is determine by the router node as having a minimal geographic proximity among the plurality of data storage nodes (Moon, [0044], see instead of a central services storing user content and facilitating user content distribution and subsequent storing or recording, all these facilities are provided in a peer to peer social network [i.e., where each peer is a “data storage node”]; and Moon, [0082], see based on selective preferences [i.e., ordering] of one or more of the following: time-based frequency, geographic proximity, source of an update).
Liu, Tank, Desh and Moon are analogous art because they are from the same field of endeavor, such as storing/retrieving data in a distributed system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Liu, Tank, Desh and Moon before him/her, to modify the bulk get hashing distributed system of the combination of Liu, Tank and Desh to include the location searching of Moon because it would allow quicker retrieval of data.
The suggestion/motivation for doing so would have been to give priority to the dissemination of its content, see Moon, [0043].
Therefore, it would have been obvious to combine Moon with the combination of Liu, Tank and Desh to obtain the invention as specified in the instant claim(s).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Tank in further view of Desh in further view of Moon in further view of Wagner et al., US 2019/0108058 A1 (hereinafter “Wagner”).
Claim 9
Claim 9 incorporates all of the limitations above.
The combination of Liu, Tank, Desh and Moon does not appear to explicitly disclose wherein the distributed storage system stores data of a plurality of distributed service applications in cache of the plurality of data storage nodes.
Wagner discloses wherein the distributed storage system stores data of a plurality of distributed service applications in cache of the plurality of data storage nodes (Wagner, [0038], see a pool of pre-warmed (e.g., having one or more software components pre-loaded thereon, before a request is received, to service such a request) before a instances not yet assigned to any user (e.g., “warming pool”) [i.e., “cache”]).
Liu, Tank, Desh, Moon and Wagner are analogous art because they are from the same field of endeavor, such as storing/retrieving data in a distributed system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Liu, Tank, Desh, Moon and Wagner before him/her, to modify the location searching bulk get hashing distributed system of the combination of Liu, Tank, Desh and Moon to include the location searching of Wagner because it would allow quicker retrieval of data.
The suggestion/motivation for doing so would have been to allow users to take advantage of the virtual machine instances provided by service providers, see Wagner, [0013].
Therefore, it would have been obvious to combine Wagner with the combination of Liu, Tank, Desh and Moon to obtain the invention as specified in the instant claim(s).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
– Raghavan et al., 2017/0004433 for service monitoring adaptation for maintenance downtime;
– Gupta et al., 2016/0366036 for dynamic substitution of service monitoring dashboard source data;
– Faircloth et al., 2022/0329473 for enhanced simple network management protocol; and
– Xu et al., CN 114912001 for data writing.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Point of Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P EST.
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, Apu Mofiz can be reached at (571) 272-4080. 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.
HUBERT G. CHEUNG
Assistant Examiner
Art Unit 2161
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2161Date: August 10, 2026
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights