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 .
DETAILED ACTION
1. The pending claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 103
2. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
3. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
4. 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claims 1-3, 8-9, 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over GUO et al (US 20180069751 A1, hereinafter “GUO”) in view of Boodman et al (U.S. Patent 11030187 B1 hereinafter, “Boodman”).
7. With respect to claim 1,
GUO discloses a system, comprising:
at least one processor;
at least one storage layer configured to interface with a plurality of software applications and to receive data output from the plurality of software applications;
at least one listener configured, based on an update policy, to periodically poll (GUO [0086] – [0088], [0098] – [0101], [0108], [0150], [0170] – [0176] e.g. [0086] In one example embodiment, and as part of operating as the anchor node for the ECS 100, the anchor node 110, via the processor 250, receives one or more "keep alive" messages from other nodes (regular nodes) of the ECS 100. In one or more example embodiments, a "keep alive" message may be generated by a regular node (e.g., periodically or whenever the regular node is attempting to retrieve a file) in order to signal the regular node's active status in the ECS 100, to the anchor node 110. "Keep alive" messages will be further described below. [0088] … In one example embodiment, the processor 250 shares the global list of active nodes with each regular node upon receiving a "keep alive" message from each node. In another example embodiment, the processor 250 multicasts (e.g., periodically) the global list of active nodes over the LAN (WLAN) to all regular nodes of the ECS 100 reachable over the LAN/WLAN. … [0101] In one example embodiment and as part of operating as a regular node of the ECS 100, the node 110, via the processor 250, receives (e.g., periodically) the generated global list of active nodes from the anchor node 130, which the processor 250 utilizes in determining where to retrieve a requested file from (e.g., from another node of the ECS 100 or from the remote sever 140), as will be described below. … [0150] After the initial configuration process (the above-described manual configuration of nodes active over the remote ECS), in one example embodiment, each node on the remote ECS sends "keep alive" messages to all other nodes active on the remote ECS (e.g., periodically via multicast over the other LAN/WLAN or multiple individual messages to each of the other nodes active over the remote ECS). Upon receiving such "keep alive" messages, each node creates a list of node IDs for the nodes on the remote ECS from which a "keep alive" message is received. This process ensures that each node has list of active nodes on the remote ECS. … [0171] If at S882, the processor 250 determines that the download request has been received from the node 120 (within the time period T), then at S884, the processor 250 transmits the requested file to the node 110. Thereafter, the process reverts back to S870 until the node 110 receives another retrieval request for a file stored at the node 110. … [0176] If at S990, the processor 250 determines that the node 110 is not leaving the ECS 100, the processor 250 performs S990 (e.g., periodically) to determine if the node 110 is leaving the ECS 100 or not) for presence of a data entry newly stored within the at least one storage layer, wherein the data entry comprises at least a key and a value in a key-value pair (GUO [0063] - [0064], [0089] – [0092] e.g. [0063] In one or more example embodiments, a distributed hash table (DHT) infrastructure is used by the ECS 100 of FIG. 1. As described above with reference to FIG. 1, each device (each of the devices 105, 110, 115, 120, 125, 130 and 135) is referred to as a node in the ECS system 100 where each node has a unique logical node ID. [0064] In one or more example embodiments, content and/or data stored in the ECS 100 in the form of (key, value) pairs where the key is the unique content ID and the value is the content/data in the form of a file. Hereinafter, the term file will be used to refer to the content/data. In one or more example embodiments, the (key, value) pairs are distributed to different nodes within the ECS 100. [0089] In one example embodiment and as part of operating as the anchor node of the ECS 100, the anchor node 110, via the processor 250, receives and stores most recent retrievers of files. In one example embodiment, the most recent retriever of a file is a node that most recently retrieved the file from the remote server 140 (the conditions according to which a node retrieves a file from a remote server will be described below). In one example embodiment, the processor 250 stores the most recent retrievers of files in a form of a list of node IDs of most recent file retriever nodes, where each entry in the list is in the form of (node ID, key), with the "node ID" corresponding to the node that most recently retrieved a file and the "key" corresponding to a hash value of the file that was most recently retrieved by the node having the node ID. [0090] As will be described below with reference to FIG. 7, each regular node of the ECS 100, upon retrieving a file from the remote server 140, generates a local list of missing nodes that identify nodes of the ECS 100 that are supposed to have a copy of the retrieved files stored thereon (keeper nodes) but are not currently active in the ECS 100. In one example embodiment, each entry in the local list of missing nodes is in the form of (node ID, key), with the "node ID" corresponding to a keeper node that is supposed to have a copy of the retrieved file and the "key" corresponding to a hash value of the retrieved file. [0091] Upon creating the local list of missing nodes, each node transmits the local list of missing nodes to the anchor node 110 in order for the anchor node 110 to generate a global list of missing nodes. [0092] …. Each entry may be in the form of (node ID, key), where the "node ID" is an ID of a missing node and the "key" is the hash value of a file that is supposed to be stored at the node corresponding to the node ID.) corresponding to the data entry; and
a memory operatively coupled to the at least one processor, the at least one processor configured to perform operations comprising:
sending the key-value pair to a computer cluster, wherein the computer cluster comprises a master node (GUO [0005] – [0006], [0017], [0075], [0083], [0120] – [0124] e.g. primary anchor node) interfacing with a plurality of slave nodes (GUO [0005] – [0006], [0017], [0075], [0083], [0120] – [0124] e.g. secondary anchor node), each slave node of the plurality of slave nodes assigned to a corresponding database node based on a hash value of the key of the key-value pair being unique to the corresponding database node (GUO [0063] - [0064], [0089] – [0092] e.g. [0063] In one or more example embodiments, a distributed hash table (DHT) infrastructure is used by the ECS 100 of FIG. 1. As described above with reference to FIG. 1, each device (each of the devices 105, 110, 115, 120, 125, 130 and 135) is referred to as a node in the ECS system 100 where each node has a unique logical node ID. [0064] In one or more example embodiments, content and/or data stored in the ECS 100 in the form of (key, value) pairs where the key is the unique content ID and the value is the content/data in the form of a file. Hereinafter, the term file will be used to refer to the content/data. In one or more example embodiments, the (key, value) pairs are distributed to different nodes within the ECS 100. [0089] In one example embodiment and as part of operating as the anchor node of the ECS 100, the anchor node 110, via the processor 250, receives and stores most recent retrievers of files. In one example embodiment, the most recent retriever of a file is a node that most recently retrieved the file from the remote server 140 (the conditions according to which a node retrieves a file from a remote server will be described below). In one example embodiment, the processor 250 stores the most recent retrievers of files in a form of a list of node IDs of most recent file retriever nodes, where each entry in the list is in the form of (node ID, key), with the "node ID" corresponding to the node that most recently retrieved a file and the "key" corresponding to a hash value of the file that was most recently retrieved by the node having the node ID. [0090] As will be described below with reference to FIG. 7, each regular node of the ECS 100, upon retrieving a file from the remote server 140, generates a local list of missing nodes that identify nodes of the ECS 100 that are supposed to have a copy of the retrieved files stored thereon (keeper nodes) but are not currently active in the ECS 100. In one example embodiment, each entry in the local list of missing nodes is in the form of (node ID, key), with the "node ID" corresponding to a keeper node that is supposed to have a copy of the retrieved file and the "key" corresponding to a hash value of the retrieved file. [0091] Upon creating the local list of missing nodes, each node transmits the local list of missing nodes to the anchor node 110 in order for the anchor node 110 to generate a global list of missing nodes. [0092] In one example embodiment and as part of operating as the anchor node of the ECS 100, the anchor node 110, via the processor 250, receives one or more local list of missing nodes and based thereon, generates a global list of missing nodes. In one example embodiment, such global list of missing nodes may have one or more entries. Each entry may be in the form of (node ID, key), where the "node ID" is an ID of a missing node and the "key" is the hash value of a file that is supposed to be stored at the node corresponding to the node ID.); and
performing at least one mass insertion (e.g. transmit; copies) of the data entry from the at least one storage layer by simultaneous (GUO [0043] e.g. [0043] Although a flow chart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently or simultaneously) access and storage of the data entry to at least two of the plurality of the corresponding database nodes (GUO [0012], [0020], [0083] - [0085], [0092] - [0093], [0117] – 0119], [0122] – [0124], [0161], [0171], [0178], [0186] – [0187] e.g. [0012] In yet another example embodiment, the processor is configured to generate a local list of keeper nodes for the file based on the generated key and a duplication factor, the local list of keeper nodes including a node ID of at least one node of the cloud storage structure at which a copy of the file should be available, the duplication factor determining a number of nodes at which a copy of the file should be available, receive the global list of active nodes of the cloud storage structure from an anchor node of the cloud storage structure, determine if at least one node ID in the local list of keeper nodes matches a node ID in the global list of active nodes, and retrieve the file from at least one other regular node of the cloud storage structure if the processor determines that there is a match between the at least one node ID in the local list of keeper nodes and the node ID in the global list of active nodes, the at least one other regular having anode ID corresponding to the at least one node ID. [0085] … Furthermore, the anchor node 110 may store temporary copies of files retrieved from the remote server 140 until one or more missing nodes (that are supposed to store copies of such files) become active participants in the ECS 100. The temporary storing of copies of files and the conditions, according to which the anchor node 110 stores such temporary copies of files, will be further described below. [0092] In one example embodiment and as part of operating as the anchor node of the ECS 100, the anchor node 110, via the processor 250, receives one or more local list of missing nodes and based thereon, generates a global list of missing nodes. In one example embodiment, such global list of missing nodes may have one or more entries. Each entry may be in the form of (node ID, key), where the "node ID" is an ID of a missing node and the "key" is the hash value of a file that is supposed to be stored at the node corresponding to the node ID. [0093] In one example embodiment, the processor 250 receives one copy of a file for which there is at least one corresponding node ID in the global list of missing nodes. In one example embodiment, the processor 250 temporarily stores the received copy. As each missing node rejoins the ECS 100 (e.g., becomes an active node of the ECS 100), the processor 250 transmits a copy of the temporarily stored file at the anchor node 110, to each re-joined missing node. After all missing nodes rejoin and receive copies of the file the processor 250 deletes the temporarily stored copy of the file at the anchor node 110. [0117] At S406, the processor 250 determines whether the key has a match locally at the node 110. Each node of the ECS 100 may have a local cache where, depending on the size of a cache at each node, the node keeps copies of the files recently accessed by the node. Moreover, each node may store a table of keys for the files recently accessed by the node. Accordingly, the processor 250 determines whether the generated key has a match in the table of keys (local list of keys) at the node 110. The table of keys may be in the form of a hash table.); and
wherein at least one of the plurality of the corresponding database nodes receives a mirror (e.g. duplication; copies) of the data entry.
Although GUO substantially teaches the claimed invention, GUO does not explicitly indicate wherein each of the corresponding database nodes is configured to run as a single-threaded database.
Boodman teaches the limitations by stating wherein each of the corresponding database nodes is configured to run as a single-threaded database (Boodman col. 20 lines 28-40 e.g. chunker/thread - For example, in an embodiment, multiple iterations of blocks 1020-1035 are performed concurrently, such that two or more layers are being generated by different execution threads (i.e. "chunkers") at the same time. Hence, as a chunk identifier at a lower level is created, it is immediately fed as an input value to the execution thread for its parent layer. Also, a new execution thread may be generated for the parent layer, if this is the first time a value has been derived for the parent layer.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of GUO and Boodman, to overcome the drawback of these systems do not allow for the storage of structured data in a way which enables local read and write operations on the data to be comparable in performance to that of databases such as SQL, NoSQL, or NewSQL (Boodman col. 1 lines 29-33).
8. With respect to claim 2,
Boodman further discloses wherein the hash value of the key is within a range of hashes assigned to the corresponding node (Boodman col. 8 line 62 – col. 9 line 4 e.g. range).
9. With respect to claim 3,
GUO further discloses performing the at least one mass-insertion across the plurality of corresponding database nodes, for a quantity of the plurality of corresponding database nodes equal to a corresponding quantity of the plurality of the slave nodes (GUO [0122] – [0123], [0186] – [0187] e.g. [0122] Furthermore, the processor 250 may have a duplication factor k stored therein. The duplication factor k determines a number of nodes (in addition to the primary keeper) at which a copy of the requested file is supposed to be available. [0123] In one example embodiment, k is an integer greater than or equal to 2. Accordingly, the processor 250 generates the local list of keeper nodes as (P, key), (P(s1 ), key), (P(s2), key), ... , where P(s1) is a node ID of a node that is a successor node to node ID P, P(s2) is a node ID of the a node that is a successor node to the node ID P(s1 ), etc. In one example embodiment, a number of entries in the local list of keeper nodes is equal to k.).
10. Claims 8-9 are same as claims 1 and 3 and are rejected for the same reasons as applied hereinabove.
11. Claims 14-15 are same as claims 1 and 3 and are rejected for the same reasons as applied hereinabove.
12. With respect to claim 20,
Boodman further discloses updating at least one state indicator for a shared resource among the plurality of corresponding database nodes (Boodman col. 6 lines 12-48 e.g. shared).
GUO further discloses updating at least one state indicator for a shared resource among the plurality of corresponding database nodes (GUO [0095], [0125] e.g. shared).
13. Claims 4, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over GUO in view of Boodman, and further in view of NAKAGOE et al (WO 2014054173 A1 hereinafter, “NAKAGOE”).
14. With respect to claim 4,
Although GUO and Boodman combination substantially teaches the claimed invention, they do not explicitly indicate wherein the quantity of the plurality of corresponding database nodes and the corresponding quantity of the plurality of slave nodes excludes overprovisioned nodes corresponding to the plurality of corresponding database nodes or to the plurality of slave nodes.
NAKAGOE teaches the limitations by stating wherein the quantity of the plurality of corresponding database nodes and the corresponding quantity of the plurality of slave nodes excludes overprovisioned (NAKAGOE page 28 e.g. The core node evaluates a node allocated redundantly between the sub-overlay networks in the same hierarchy, and eliminates the redundant allocation of the node when an evaluation result that does not permit duplication is obtained; referring to the instant applicant’s spec. [0085]) nodes corresponding to the plurality of corresponding database nodes or to the plurality of slave nodes.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of GUO, Boodman and NAKAGOE, to overcome the drawback of these systems do not allow for the storage of structured data in a way which enables local read and write operations on the data to be comparable in performance to that of databases such as SQL, NoSQL, or NewSQL (Boodman col. 1 lines 29-33).
15. Claim 10 same as claim 4 and is rejected for the same reasons as applied hereinabove.
16. Claim 16 same as claim 4 and is rejected for the same reasons as applied hereinabove.
17. Claims 5, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over GUO in view of Boodman, and further in view of MI (CN 108960945 A hereinafter, “NAKAGOE”).
18. With respect to claim 5,
Although GUO and Boodman combination substantially teaches the claimed invention, they do not explicitly indicate generating or updating at least one content recommendation based at least in part on the key-value pair.
MI teaches the limitations by stating generating or updating at least one content recommendation based at least in part on the key-value pair (MI page 7 e.g. storing the mapping process step 3 stores generated query condition according to the mapping rule (mapping rule, it is a key of the query according to the found key value value). find the corresponding recommended content in the memory.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of GUO, Boodman and MI, to overcome the drawback of these systems do not allow for the storage of structured data in a way which enables local read and write operations on the data to be comparable in performance to that of databases such as SQL, NoSQL, or NewSQL (Boodman col. 1 lines 29-33).
19. Claim 11 same as claim 5 and is rejected for the same reasons as applied hereinabove.
20. Claim 17 same as claim 5 and is rejected for the same reasons as applied hereinabove.
21. Claims 6, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over GUO in view of Boodman, and further in view of SANKARAN et al (CN 110121698 A hereinafter, “SANKARAN”).
22. With respect to claim 6,
Although GUO and Boodman combination substantially teaches the claimed invention, they do not explicitly indicate wherein a function of the at least one listener comprises a wait state and a lambda function.
SANKARAN teaches the limitations by stating wherein a function of the at least one listener comprises a wait state and a lambda function (SANKARAN page 102 e.g. wait … lambda function).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of GUO, Boodman and SANKARAN, to overcome the drawback of these systems do not allow for the storage of structured data in a way which enables local read and write operations on the data to be comparable in performance to that of databases such as SQL, NoSQL, or NewSQL (Boodman col. 1 lines 29-33).
23. Claim 12 same as claim 6 and is rejected for the same reasons as applied hereinabove.
24. Claim 18 same as claim 6 and is rejected for the same reasons as applied hereinabove.
25. Claims 7, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over GUO in view of Boodman, and further in view of HUGHES et al (ES 2912265 T3 hereinafter, “HUGHES”).
26. With respect to claim 7,
Although GUO and Boodman combination substantially teaches the claimed invention, they do not explicitly indicate wherein the at least one storage layer comprises object storage further comprising distributed objects in a unified namespace.
HUGHES teaches the limitations by stating wherein the at least one storage layer comprises object storage further comprising distributed objects in a unified namespace (HUGHES [0204] e.g. namespace).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of GUO, Boodman and HUGHES, to overcome the drawback of these systems do not allow for the storage of structured data in a way which enables local read and write operations on the data to be comparable in performance to that of databases such as SQL, NoSQL, or NewSQL (Boodman col. 1 lines 29-33).
27. Claim 13 same as claim 7 and is rejected for the same reasons as applied hereinabove.
28. Claim 19 same as claim 7 and is rejected for the same reasons as applied hereinabove.
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
29. The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
30. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYLING YEN whose telephone number is (571)270-1306. The examiner can normally be reached on 8am-4:30pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. 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.
/SYLING YEN/Primary Examiner, Art Unit 2166
October 6, 2026
