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 RCE/amendments, arguments and remarks, filed on 12/15/2025, in which claim(s) 1-6 and 8-21 is/are presented for further examination.
Claim(s) 1, 10, 16 and 20 has/have been amended.
Claim(s) 7 has/have been cancelled.
Claim(s) 21 has/have been added.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 12/15/2025 has been entered.
Response to Amendment
Applicant’s amendment(s) to claim(s) 1, 10 and 16 has/have been accepted. The objection(s) to the claim(s) for informalities has/have been withdrawn.
Applicant’s amendment(s) to claim(s) 20 has/have been accepted.
Applicant’s addition(s) of claim(s) 21 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-21, filed on 12/15/2025, have been fully considered but they are not persuasive.
Applicant’s arguments with respect to the rejection(s) of claim(s) 1-6 and 8-21, under 35 U.S.C. 103, see the middle of page 10 to page 11 of applicant’s remarks, filed on 12/15/2025, 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 Objections
Claim(s) 21 is/are objected to because of the following informalities: in line 3, “each bucket” should be corrected to “each storage bucket”. Appropriate correction is required.
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, 20 and 21 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 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 a 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;
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;
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 storage node by the partial key.
Desh discloses generating a single hash value (Desh, [0047], see, in block 512, the log generation component 110 hashes the values of the key source properties to generate a target key [i.e., “corresponds to the “single hash value”] and adds the target key to the buffer …; and Desh, Fig. 5B, step 512 “Hash the values of the key source properties to generate a target key and add target key to the buffer”) from a partial key formed of a subset of fields of the key (Desh, [0046], see, in block 510, the log generation component 110 extracts values of the identified source properties from the source object [i.e., corresponds to the “subset of fields of the key”] and stores the extracted values in a buffer in an order specified by the map identifier in each of the rows in the selected group);
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”);
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 (Desh, [0067], see the dispatch table has a multiplicity of hash buckets each of which can be directly addressed with a key [i.e., corresponds to “partial key”, where using the key to retrieve all of the data in the bucket corresponds to the “bulk get operation”]. The key used is the log record target key value [i.e., corresponds to the “single hash value”]. A hash bucket contains a single ordered queue. Each ordered queue in a bucket is associated with a specific target key. Each ordered queue can have a multiplicity of in-memory log record entries [i.e., corresponds to a plurality of data”] all with the same target 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 storage node by the partial key (Desh, [0067], see the dispatch table has a multiplicity of hash buckets each of which can be directly addressed with a key [i.e., corresponds to “partial key”, where using the key to retrieve all of the data in the bucket corresponds to the “bulk get operation”]. The key used is the log record target key value [i.e., corresponds to the “single hash value”]. A hash bucket contains a single ordered queue. Each ordered queue in a bucket is associated with a specific target key. Each ordered queue can have a multiplicity of in-memory log record entries [i.e., corresponds to a plurality of data”] all with the same target key).
Liu 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 and Desh before him/her, to modify the distributed system of Liu to include the hashing 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 Liu 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 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 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 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 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 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 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 hash value generated from the key and based on the determination of the data storage node (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 21
With respect to claim 8, the combination of Liu and Desh discloses wherein the partial key comprises a time component to enable retrieval of records from a set of storage buckets using the time component, each bucket comprising a set of time-bounded records (Desh, [0038], see the log table 330 includes attributes for: a sequence number (which identifies the order in which transactions completed on the source system entity instance 210), a transaction identifier, operations code (i.e., insert, update or delete), source system entity modification timestamp (which indicates the last time the source object was modified), target type, target key, target partition identifier, intermediate form payload (which has values to be transmitted in intermediate form), phase value, phase timestamp, and disposition).
Claim(s) 3, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in 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 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, 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, Desh and Muni before him/her, to modify the hashing distributed system of the combination of Liu 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 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 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 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 determine 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, 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, Desh and Moon before him/her, to modify the hashing distributed system of the combination of Liu 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 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 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, 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, 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, Desh, Moon and Wagner before him/her, to modify the location searching hashing distributed system of the combination of Liu, 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, 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.
– Matsakis, 2012/0078970 for performance of hash tables.
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, Neveen Abel-Jalil can be reached at (571) 270-0474. 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 2152
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2152Date: March 19, 2026
/NEVEEN ABEL JALIL/Supervisory Patent Examiner, Art Unit 2152