CTFR 18/903,960 CTFR 98896 DETAILED ACTION This Action is responsive to the amendments filed on 03/26/2026. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Status Claims 1-20 are amended. Claims 1-20 are pending and have been examined. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claims 11-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding Claim 11, Claim 11 recites “ the processor of the second computer ” in the 12-13 th lines without providing proper antecedent basis. Therefore, the scope of Claim 11 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). Examiner recommends applicant amend Claim 11 instead to read “ a processor of the second computer ” in order to overcome this rejection. Claims 12-20 depend on Claim 11 and are therefore similarly rejected under 35 U.S.C. 112(b). Regarding Claim 16, Claim 16 recites “ the processor of the first computer ” in the 5 th line without providing proper antecedent basis. Therefore, the scope of Claim 16 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). Examiner recommends applicant amend Claim 16 instead to read “ a processor of the first computer ” in order to overcome this rejection. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries 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. 07-21-aia AIA Claim s 1-8 and 11-18 are rejected under 35 U.S.C. 103 as being unpatentable over a 2017 IEEE public disclosure authored by Cassell et al. (published December 2017)(entitled "Nessie: A Decoupled, Client-Driven Key-Value Store Using RDMA,”; cited by examiner in previous Action)(hereafter referred to as Cassell ) further in view of a 2022 online public disclosure authored by Lee et al. (published September 2022)(entitled “DINOMO: An Elastic, Scalable, High-Performance Key-Value Store for Disaggregated Persistent Memory”; co-authored by instant inventor)(hereafter referred to as Lee ) . Regarding Claim 1, Cassell discloses the following limitations: A computer system (Fig. 1) including a first computer (Node B, Fig. 1 // “machine” [3.1, pg. 4]) and a second computer (Node A, Fig. 1)(“each machine acting as a request-issuing client and as a storage node” [3.1, pg. 4]) , wherein the first and second computers each include a processor and local memory (“any workload containing collocated CPU-bound and memory-bound tasks is well-suited to Nessie. This includes web servers , which often consist of a CPU-bound process serving small amounts of pages from memory as well as an in-memory cache or storage system” [3.1, pg. 4]) – As taught in Section 3.1, nodes can correspond to web servers which including both “a CPU-bound process” (i.e., at least a CPU) in addition to “in-memory cache” (i.e., “ a processor and local memory ”) , the processors of the first and second computers executing instructions stored in the local memory of the first and second computers (“one Nessie instance per node” [4.1, pg. 5] // “a working prototype of Nessie consisting of about 4,400 lines of C++ ” [5, pg. 9]) – As taught in sections 4.1 and 5, Nessie is implemented using lines of C++ (i.e., using “ instructions ”) implemented on each node (i.e., “ stored in the local memory ” of the respective node)-- to enable the first computer to access data stored in a memory system (Node C data table, Fig. 1) that is remote from the first and second computers (Fig. 1)(“Nessie is an RDMA-enable key-value store that decouples indexing metadata, which is stored in data structures we ref to as index tables, and key-value pairs, which are stored in a data structure we refer to as data tables. Each instance of Nessie contains an index table , a data table, and a small local cache of remote key-value pairs. Fig. 1 depicts a sample Nessie deployment across three nodes, with one Nessie instance per node” [4.1, pg. 5]) – As shown in Fig. 1 and taught in Section 4.1, each node stores data within a particular “data table” data structure. In this context, data stored in a data table of Node C is “ stored … remotely ” from Nodes A and B-- , by performing the following steps: determining, by the first computer, that a first key (“the requested key” [4.2.1, pg. 6]) associated with first data (data table entry (DTE); section 4.2.1) that is stored in the memory system (Fig. 1, step (1)) , corresponds to a first reference (index table entry (ITE); section 4.2.1) to the first data that is not owned by the first computer (Fig. 1, “sample GET operation on node B ”)(“Nessie’s GET protocol consists of a forward pass … During the forward pass, Nessie computes a list of possible ITEs for the requested key … Nessie iterates over these ITEs, retrieving them using RDMA READS … used to retrieve candidate DTEs” [4.2.1, pg. 6] // “GET accepts a key and obtains its associated value ” [2.2, pg. 2]) – As taught in Section 4.2.1, a node (e.g., Node B; see Fig. 1; i.e., “ the first computer ”) receives a key from a GET operation (i.e., “ a first key ”) in order to obtain an index table entry (ITE) (i.e., “ a first reference ”) associated with received key (i.e., “ associated with first data ”) and identifying a corresponding data table entry (DTE) (i.e., “ first data ”) which is located within the memory system. As shown in Fig. 1 step (1), Node B identifies the candidate ITE within an index table which is remote to Node B (e.g., within an index table of Node A). Examiner accordingly considers a node, such as Node B, retrieving an ITE from a remote node during a GET operation as at least node A “ determining ” that the received key is “ not owned by ” node B (i.e., not stored within the index table local to Node B) . Finally, as shown in Fig. 1, the ITE retrieved by node B during step (1) is associated with a corresponding DTE located within a node C remote to both nodes A and B (i.e., the received key is “ associated with first data that is stored within the memory system ” remote to the first and second computers) ; in response to determining that the first key corresponds to the first reference that is not owned by the first computer, transmitting, by the first computer to the second computer, a request for the first reference, (Fig. 1, step (1); Sections 4.2.1 + 2.2; pgs. 2 + 6) – As discussed above with respect to step (1) of Fig. 1, node B computes a list of ITEs associated with the retrieved key and in response retrieves the ITE using an RDMA read. As shown in Fig. 1, the ITE retrieved by node B is located on node A. Examiner accordingly considers a node, such as Node B, performing an RDMA read to retrieve an ITE from a remote node A, as reading on the claimed concept of Node B “ transmitting ” “ a request ” to node A for the ITE located on node A … and reading, by the first computer, the first data directly from the memory system, using the first reference (“ITEs … are used to retrieve candidate DTEs … using an RDMA READ from a remote data table ” [4.2.1, pg. 6] // “The ITE’s DTI and DTE are used for an RDMA read from node C’s data table … The DTE is valid, and the value returned is retrieved ” [Fig. 1]) – As taught in Section 4.2.1 and shown in Fig. 1, Node B uses the ITE retrieved from Node A to perform an RDMA read (i.e., “ reading … directly ”) of the associated value from the data table of another Node C (i.e., “ from the memory system using the first reference ”)-- … to locate a memory address of the first data in the memory system. (“Taken together, a DTI and DTE identify a spatially unique portion of memory in the cluster ” [4.1.1, pg. 5] // Fig. 1 // “Communication over RDMA is performed … The contents of the sent message are passed directly into an address in the receiving application’s memory” [2.1, pg. 2]) – As detailed in Section 4.1.1 and shown in Fig. 1, ITEs include both a DTI field and a DTE field which uniquely identifies a particular entry in a particular data table. As clarified in Section 2.1, RDMA communication takes place between addresses in memory. As discussed in Cassell Section 4.2.1 and as shown in Fig. 1, during a GET operation, Node B uses an RDMA read operation to retrieve an ITE located in Node B. Cassell accordingly does not disclose an embodiment whereby Node A, in response to a request for an ITE received from Node B, identifies the requested ITE and subsequently transmits the requested ITE back to Node B. In addition, as depicted in Fig. 1, the ITE retrieved by Node B during step (1) is located within an index table local to Node A. Cassell accordingly does not disclose an embodiment whereby the ITE requested by Node B is retrieved from a memory system external to both Nodes A and B. Specifically, Cassell does not explicitly disclose the following limitations: the request for the first reference identifying the first key; in response to the request for the first reference, determining, by the processor of the second computer , the first reference by using the first key to locate a first key-reference pair in the memory system , and then reading, by the processor of the second computer , the first reference from the first key- reference pair in the memory system ; transmitting the first reference , by the second computer to the first computer reading … the first data directly from the memory system, using the first reference transmitted by the second computer However, Lee discloses a disaggregated memory architecture (“DINOMO”; see Fig. 2) including plural “KVS nodes” (KN) which service client requests using RDMA transactions on shared memory and which organizes data into both key-value pairs corresponding metadata, which examiner considers analogous to the Cassell disaggregated memory architecture (Fig. 1) including plural nodes A-C which service client requests using RDMA transaction on shared memory and which organizes data into both DTEs and corresponding ITEs. Examiner accordingly considers KN nodes 0-N depicted in Lee Fig. 2 as analogous to nodes A-C of Cassell (i.e., a KN node of Lee corresponds to one of the first or second computers). Lee discloses a disaggregated memory architecture whereby both data and corresponding metadata are stored within a disaggregated memory (DPM; Fig. 2) which is external to and shared by KVS nodes. Specifically, Lee discloses the following limitations: the request for the first reference identifying the first key; ( “ DINOMO allows applications to perform … lookup(key)… We refer to lookup operations as reads” [3, pg. 3]) – As taught in Section 3, read requests specify a key associated with the request-- in response to the request for the first reference (“a cache miss” [pg. 7]) , determining, by the processor of the second computer (“the appropriate KN” [pg. 4]) , the first reference (“the address of the value” [pg. 7]) by using the first key to locate a first key-reference pair in the memory system (Fig. 2) , (“KNs can cache not only data in the form of values but also metadata in the form of shortcuts . … A shortcut entry keeps a fixed 64-bit pointer to the value in DPM; accessing the data incurs a one-sided operation to DPM. If neither value nor shortcut are cached , accessing the value incurs significant overhead: the KN needs to traverse a metadata structure in DPM to find the value’s location and then access the value.” [3.3, pg. 5] // “A client first contacts a RN to obtain cluster membership and caches the mapping of key ranges to various KNs. The client contacts the appropriate KN that will then perform the read or write operation on its behalf” [3.1, pg. 4] // // Fig. 2) – As taught in Sections 3 and 3.1, a client contacts an “appropriate KN” caching a “shortcut” in order to perform a read operation associated with a given key, which examiner notes is analogous to step (1) of Cassell Fig. 1 whereby a client reads an ITE from a Node A which contains the ITE within its local Index Table. Accordingly, the “appropriate KN” of Lee corresponds to claimed “ the processor of the second computer ”. As clarified in Section 3.3, when a cache lookup within a KN for a shortcut misses, the KN (i.e., instead of the client) must instead retrieve the shortcut from a metadata structure located within the DPM (i.e., upon a cache miss, the appropriate KN locates “ a first key-reference pair in the memory system ”). -- and then reading (“index traversals” [pg. 7) , by the processor of the second computer, the first reference from the first key- reference pair in the memory system; (“For reads, an KN directly returns the value from its cache upon a value hit. On a shortcut hit, it performs a single one-sided operation to retrieve the value in DPM from the shortcut pointer. On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ” [3.6, pg. 7]) – As discussed above and as clarified in Section 3.6, upon a cache miss, a KN (i.e., as opposed to a client; i.e., “ the processor of the second computer ”) performs an index traversal from a structure in DPM to identify the address of the requested data (i.e., “ reading ” “ the first reference from the first key-reference pair in the memory system ”)-- Cassell and Lee are considered analogous to the claimed invention because they all relate to the same field of performing client read and write operations in KVS whereby both metadata and data are stored within a disaggregated, shared storage system and whereby plural processing nodes must share access to memory located within the disaggregated storage system. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cassell with the teachings of Lee and realize a disaggregated storage system whereby references for requested data are read from an external, shared memory. Storing references to data in an external, shared memory such as a DPM provides a ground source of truth for key-reference pairs in a disaggregated storage system, providing a globally-consistent view of data in a scalable manner as disclosed in Lee Section 3.2: “Figure 2 shows the data-plane components in DINOMO. DINOMO stores data (key-value pairs) and metadata (indexing structures) in DPM, providing durability and the source of ground truth … Thus, with such PM indexes , DINOMO provides a globally consistent view of data in a scalable manner, independent of the number of KNs.” [3.2, pg. 4] The combined teachings of Cassell and Lee render obvious the following limitations: transmitting the first reference (Cassell, ITE, Fig. 1 // Lee, shortcuts, Fig. 2) , by the second computer (Lee, Section 3.6) to the first computer (Lee, “On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ”)(Cassell, “(1) A node and ITE is determined by the key’s hash and is read with RDMA from node A’s index table” [Fig. 1]) – As discussed above and shown in Cassell Fig. 1, the ITE associated with the client request is looked up from an index table of node A (i.e., analogous to a lookup of a shortcut in a KN cache of Lee ). As clarified in Lee , in the event a shortcut is not located within the cache of a KN node, the KN node performs an index traversal to locate the reference within an external DPM. One of ordinary skill in the art would accordingly understand that in the event of a cache miss in the lookup of the index table of Node A during step (1) of Cassell , Node A would perform an index traversal to locate the ITE from an external, shared memory, such as the PM index located within a DPM of Lee Fig. 2. In such a scenario, the ITE would be “ transmit ” “ by the second computer ” (i.e., node A) “ to the first computer ” (i.e., node B) because the ITE is received by Node B (i.e., “ to ” the first computer) but the index traversal is performed by Node A (i.e., transmitting the first reference “ by ” the second computer). reading … the first data directly from the memory system, using the first reference transmitted by the second computer (Cassell, Fig. 1, step (4)) – As discussed above and shown in Cassell Fig. 1, during step (4), node B performs an RDMA read of the DTE associated with the ITE received during step (1)(i.e., first data is read “ directly from the memory system ” “ using the first reference transmitted by the second computer ”) Regarding Claim 2, The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein the steps further include: transmitting, by the first computer to the second computer, a put request (Cassell, “Nessie’s PUT protocol” [4.2.2, pg. 6]) identifying a second key-reference pair (Lee, “DINOMO allows application to perform insert (key, value) operations” [3, pg. 3]) , the second key-reference pair including a second reference to second data in the memory system (Lee, “A shortcut entry keeps a fixed 64-bit pointer to the value in DPM “ [3.3, pg. 5]) , and storing, by the second computer in response to the put request, the second key-reference pair in the memory system (Cassell, “Abstractly, Nessie’s PUT protocol performs a forward pass over a requested key’s possible ITEs to insert a new entry … During the forward pass, Nessie iterates over a requested key’s possible ITE’s searching for a candidate ITE that is empty … With a candidate ITE chosen, Nessie must allocate a DTE for the PUT’s key-value pair ” [4.2.2, pg. 6] // “Sample PUT … by a client on node B : … (5) ITE 20 on node A is valid (unused) candidate. Create a new local DTE . (6) CAS ITE 20 on node A to refer to the new DTE ” [Fig. 2] // Lee, “least frequently used shortcuts are evicted” [4, pg. 8] // “DINOMO stores … metadata (indexing structures) in DPM, providing durability and ground truth” [3.2, pg. 3]) – As taught in Cassell Section 4.2.2, a node (e.g., node B; see Fig. 2) can perform a “PUT” operation associated with a distinct key in order to place associated data into the memory system. As shown in Fig. 2, node B allocates a new ITE entry (i.e., “ a second reference for accessing second data ”) to the index table on node A which is allocated for “the PUT’s key-value pair” (i.e., “ a second key-reference pair ”). As further shown in Fig. 2, as a result of a PUT operation performed by node B, a resulting reference is stored in an index table of node A, and an associated data table entry is stored on node B (i.e., “ storing the second key-reference pair in ” an index table of node A). Finally, as taught in Lee , least-frequently-used shortcuts are evicted from the cache of a KN (i.e., into DPM; see section 3.2) to make room for other shortcuts to be cached (i.e., storing the shortcut “ by the second computer in response to the put request ” into “ the memory system ” to free up space in cache). Regarding Claim 3, The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein the steps further include: transmitting, by the first computer to the second computer, a delete request (Cassell, “DELETEs in Nessie” [4.2.4, pg. 7]) identifying a second key (Lee, “DINOMO allows applications to perform … delete(key) ” [3, pg. 3]) , the second key being part of a second key-reference pair stored in the memory system (Lee, “DINOMO stores … metadata (indexing structures) in DPM” [3.2, pg. 3]) ; and deleting, by the second computer in response to the delete request, the second key-reference pair from the memory system (Cassell, Fig. 2 “Sample PUT … by a client on node B” // “DELETEs in Nessie are identical to PUTs, but instead of inserting a DTE with a specified value, a DELETE inserts a DTE with an empty value … marking the ITE as empty” [4.2.4, pgs. 7-8] // Fig. 1)(Lee, Section 3 // Fig. 1) – As taught in Cassell Section 4.2.4, a node can perform a “DELETE” operation in a manner which is identical to a PUT operation. As clarified in Fig. 2, node B performs a PUT operation associated with a unique key (i.e., “ a second key ”) in order to insert an ITE into node A (step 6) and a corresponding DTE into node B (step 8)(i.e., “ a second key-reference pair ”). One of ordinary skill in the art would accordingly understand, in view of Cassell Section 4.2.4 and Fig. 2 that a DELETE operation performed by node B with respect to the second key would delete the associated key-reference pair by inserting an empty DTE and marking the associated ITE as empty. Finally, as taught in Lee and shown in Fig. 1, applications initiate delete requests transmit to KNs (i.e., “ transmitting ” the delete request “ by the first computer to the second computer ”; see also Cassell Fig. 1, whereby the client is located on the first computer.) Regarding Claim 4, The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein determining the first reference by the processor of the second computer includes: computing a hash of the first key (Cassell, “(1) A node and ITE is determined by the key’s hash ” [Fig. 2]) to locate a bucket in a hash table in the memory system at which the first key-reference pair is stored. (Lee, “DINOMO uses … P-CLHT … which supports lock-free reads and log-free in-place writes, as its metadata index in DPM … Each bucket in P-CLHT has the size of a single cache line” [4, pg. 7]) – As previously discussed (see Claim 1 limitation mappings above) and as shown in Cassell Fig. 2, any node (i.e., including node A) uses a hash of a received key in order to locate an associated ITE (i.e., to locate “ the first key-reference pai r”). As clarified in Lee , shortcuts are persisted in DPM (i.e., are stored “ in the memory system ”) in at hash table type structure which organizes data into buckets (i.e., “ to locate a bucket in a hash table ”). Regarding Claim 5, The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein steps further include: before determining the first reference, updating, by the second computer, a lock (Cassell, “a watermark” [4.1.1, pg. 5]) associated with the first key-reference pair to indicate that the lock is taken; and after determining the first reference, updating, by the second computer, the lock to indicate that the lock is available (Cassell, “Because RDMA operations update their bytes in address order, the last bit of an ITE is used as a watermark which clients poll on to determine if an operation has completed [6]. This provides a lower-latency alternative to RDMA-s event-raising model” [4.1.1, pg. 5] // “Like ITEs, DTEs also contain a watermark bit on which clients poll to determine whether or not an operation has completed.” [4.1.2, pg. 5] // Lee, “On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ” [3.6, pg. 7]) – As taught in Cassell Sections 4.1.1 and 2, each ITE and DTE includes a “watermark bit” which enables clients to determine whether an operation being performed on the associated ITE and DTE is complete. In this context, examiner considers the watermark associated with an ITE and DTE as “ a lock ” which is “ updat[ed] ” to indicate whether or not an associated watermark bit (and thus, whether or not the associated ITE and the associated DTE) is available. Finally, as previously discussed (see Claim 1 limitation mappings above) and as taught in Lee , upon a cache miss for a reference, a KN node (i.e., “ the second computer ”) performs the index traversal of DPM using RDMA and therefore would be the computer updating the lock when performing RDMA reads to locate the reference. Regarding Claim 6, The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1 (see Claim 1 limitation mappings above) , wherein the steps further include: receiving, by the first computer from the second computer (Cassell, node A, Fig. 1) , a request for a second reference to second data (Cassell, “one Nessie instance per node ” [4.1, pg. 5] // “Nessie’s GET protocol consists of a forward pass searching for a DTE containing the requested key” [4.2.1, pg. 6] // Fig. 1) – As previously discussed (see Claim 1 limitation mappings above) , each node (including Node A; i.e., “ the second computer ”) includes a Nessie instance and thus performs the GET protocol disclosed in Cassell Section 4.2.1 (i.e., transmits “ a request for a second reference to second data ” distinct from first data; see Claim 1 limitation mappings above.) One of ordinary skill in the art would accordingly understand that node A of Cassell Fig. 1 would also perform a GET operation for second in the same manner as node B-- , the request for the second reference identifying a second key associated with the second data (Lee, Section 3) – As previously discussed (see Claim 1 limitation mappings above) , requests for a reference identify an associated key-- ; determining, by the processor of the first computer, the second reference by using the second key to locate a second key-reference pair in the memory system, and then reading, by the processor of the first computer, the second reference from the second key-reference pair in the memory system (Lee, Sections 3-3.6) – As previously discussed (see Claim 1 limitation mappings above) , a key is used to locate and subsequently read an associated key-reference pair from DPM upon a cache miss-- ; and transmitting the second reference, by the first computer to the second computer (Cassell, Section 4.2.1) – As previously discussed (see Claim 1 limitation mappings above) , a node receives a reference after requesting the reference. Regarding Claim 7, The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein the steps further include: storing the first reference in a reference cache (Cassell, “index table” [4.1.1, pg. 5]) in the first computer; reading the first reference from the reference cache in the first computer (Cassell, “Each instance of Nessie contains an index table .. Each index table entry (ITE) … operated on by atomic RDMA CAS verbs” [4.1-4.1.1, pg. 6] // “With a candidate ITE chosen, Nessie must allocate a DTE for the PUT’s key-value pair. Nessie’s decoupled design allows this DTE to be placed on any node ” [4.2.2] // Fig. 2) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Cassell Section 4.1.1, ITEs (e.g., including “ the first reference ”) are written to and read from (via RDMA; i.e., “ storing ” and “ reading ” references) an “index table” which is deployed on each node. In this context, examiner considers an index table as “ a reference cache ”. As taught in Section 4.2.2, ITEs and corresponding data table entries (DTEs) are decoupled and thus ITEs can be located on any node. As shown in Fig. 2, an ITE (e.g., ITE 10 of node B) can be located on a same node as a requesting client (e.g., node B; i.e., on “ the first computer ”) ; and storing, by the first computer, using the first reference read from the reference cache, updated data (Cassell, Fig. 2) – As shown in Cassell Fig. 2, as part of a PUT operation, data (e.g., Val Z) belonging to a given key (e.g., key K1) and associated with a given ITE (e.g., ITE 20 of node A) expires after a predetermined expiration time (e.g., time ‘t’), after which a new value (e.g., Val X) associated with the same key is associated with the same ITE. In such an example, the new value (Val X; i.e., “ updated data ”) effectively updates the expired value (Val Z) and uses a same candidate ITE (ITE 20 of node A; i.e., “ the first reference ”). at the memory address of the first data in the memory system (Lee, “A shortcut entry keeps a fixed 64-bit pointer to the value in DPM ” [3.3, pg. 5]) – As previously discussed (see Claim 1 limitation mappings above) , references to data point to the corresponding data within the memory system. Regarding Claim 8, The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1, wherein the steps further include: storing the first data in a cache (Cassell, LRU Data Cache, Fig. 1) of the processor of the first computer (Cassell, “If a valid DTE is found containing the matching key, it is cached and the value is returned” [4.2.1, pg. 6] // “The immutable nature of valid DTEs allows them to be locally cached … Nessie uses a small least recently used (LRU) cache on each node” [4.1.3, pg. 6] // Fig. 1) – As taught Cassell Section 4.2.1, as part of the GET operation, after a node (e.g.., node B; see Fig. 1) identifies a valid data table entry (DTE) which matches the requested key, the DTE is cached locally-- ; after storing the first data in the cache of the processor of the first computer, deleting the first data from the cache of the processor in response to a request to access updated data (Cassell, “(2) Local cache lookup on key “K1” returns a match with expiration time t. This expired cache entry is evicted ” [Fig. 2]) – As shown in Cassell Fig. 2, as part of a PUT operation, data (e.g., Val Z) belonging to a given key (e.g., key K1) and associated with a given ITE (e.g., ITE 20 of node A) expires after a predetermined expiration time (e.g., time ‘t’), after which a new value (e.g., Val X) associated with the same key is associated with the same ITE. In the process, the expired data is evicted (i.e., is “ delet[ed] ”) from the LRU data cache (step (2)). In this context, a request to PUT Val X (i.e., “ a request to access updated data ”) causes a previous value associated with the same key (e.g., Val Z; i.e., “ the first data ”) to be deleted from the LRU cache after Val Z has expired.-- , the updated data being stored at the memory address of the first data in the memory system; and after deleting the first data, reading, by the first computer, the updated data directly from the memory system using the first reference to locate the memory address of the first data in the memory system (Cassell, “(4) Read the ITE determined by the second hash function on “K1” … Create a new local DTE. (6) CAS ITE 20 on node A to refer to the new DTE ” [Fig. 2]) – As discussed above and as shown in Cassell Fig. 2, after Val Z is evicted from the LRU cache, an ITE associated with Val Z (e.g., ITE 20 on node A; i.e., “ the first reference ”) is allocated to a DTE for Val X (i.e., allocated to “ the updated data ”). In such an embodiment, both Val X and Val Z (i.e., “ the updated data ” and “ the first data ”) are stored by reference at the same ITE on the same node (i.e., at a “ same memory address ”), after which ITE 20 on node A is allocated to the DTE for Val Z (i.e., “ the first reference ” is used to “ locate the memory address of the first data ”). Regarding Claim 11, Cassell discloses the following limitations: A method of enabling a first computer (Node B, Fig. 1 // “machine” [3.1, pg. 4]) to access data stored in a memory system (Node C data table, Fig. 1) that is remote from the first computer and a second computer (Node A, Fig. 1)(“each machine acting as a request-issuing client and as a storage node” [3.1, pg. 4]) , the method comprising: determining, by the first computer, that a first key (“the requested key” [4.2.1, pg. 6]) associated with first data (data table entry (DTE); section 4.2.1) that is stored in the memory system (Fig. 1, step (1)) , corresponds to a first reference (index table entry (ITE); section 4.2.1) to the first data that is not owned by the first computer (Fig. 1, “sample GET operation on node B ”)(“Nessie’s GET protocol consists of a forward pass … During the forward pass, Nessie computes a list of possible ITEs for the requested key … Nessie iterates over these ITEs, retrieving them using RDMA READS … used to retrieve candidate DTEs” [4.2.1, pg. 6] // “GET accepts a key and obtains its associated value ” [2.2, pg. 2]) – As taught in Section 4.2.1, a node (e.g., Node B; see Fig. 1; i.e., “ the first computer ”) receives a key from a GET operation (i.e., “ a first key ”) in order to obtain an index table entry (ITE) (i.e., “ a first reference ”) associated with received key (i.e., “ associated with first data ”) and identifying a corresponding data table entry (DTE) (i.e., “ first data ”) which is located within the memory system. As shown in Fig. 1 step (1), Node B identifies the candidate ITE within an index table which is remote to Node B (e.g., within an index table of Node A). Examiner accordingly considers a node, such as Node B, retrieving an ITE from a remote node during a GET operation as at least node A “ determining ” that the received key is “ not owned by ” node B (i.e., not stored within the index table local to Node B) . Finally, as shown in Fig. 1, the ITE retrieved by node B during step (1) is associated with a corresponding DTE located within a node C remote to both nodes A and B (i.e., the received key is “ associated with first data that is stored within the memory system ” remote to the first and second computers) ; in response to determining that the first key corresponds to the first reference that is not owned by the first computer, transmitting, by the first computer to the second computer, a request for the first reference, (Fig. 1, step (1); Sections 4.2.1 + 2.2; pgs. 2 + 6) – As discussed above with respect to step (1) of Fig. 1, node B computes a list of ITEs associated with the retrieved key and in response retrieves the ITE using an RDMA read. As shown in Fig. 1, the ITE retrieved by node B is located on node A. Examiner accordingly considers a node, such as Node B, performing an RDMA read to retrieve an ITE from a remote node A, as reading on the claimed concept of Node B “ transmitting ” “ a request ” to node A for the ITE located on node A-- … and reading, by the first computer, the first data directly from the memory system, using the first reference (“ITEs … are used to retrieve candidate DTEs … using an RDMA READ from a remote data table ” [4.2.1, pg. 6] // “The ITE’s DTI and DTE are used for an RDMA read from node C’s data table … The DTE is valid, and the value returned is retrieved ” [Fig. 1]) – As taught in Section 4.2.1 and shown in Fig. 1, Node B uses the ITE retrieved from Node A to perform an RDMA read (i.e., “ reading … directly ”) of the associated value from the data table of another Node C (i.e., “ from the memory system using the first reference ”)-- … to locate a memory address of the first data in the memory system. (“Taken together, a DTI and DTE identify a spatially unique portion of memory in the cluster ” [4.1.1, pg. 5] // Fig. 1 // “Communication over RDMA is performed … The contents of the sent message are passed directly into an address in the receiving application’s memory” [2.1, pg. 2]) – As detailed in Section 4.1.1 and shown in Fig. 1, ITEs include both a DTI field and a DTE field which uniquely identifies a particular entry in a particular data table. As clarified in Section 2.1, RDMA communication takes place between addresses in memory. As discussed in Cassell Section 4.2.1 and as shown in Fig. 1, during a GET operation, Node B uses an RDMA read operation to retrieve an ITE located in Node B. Cassell accordingly does not disclose an embodiment whereby Node A, in response to a request for an ITE received from Node B, identifies the requested ITE and subsequently transmits the requested ITE back to Node B. In addition, as depicted in Fig. 1, the ITE retrieved by Node B during step (1) is located within an index table local to Node A. Cassell accordingly does not disclose an embodiment whereby the ITE requested by Node B is retrieved from a memory system external to both Nodes A and B. Specifically, Cassell does not explicitly disclose the following limitations: the request for the first reference identifies the first key; in response to the request for the first reference, determining, by the processor of the second computer , the first reference by using the first key to locate a first key-reference pair in the memory system , and then reading, by the processor of the second computer , the first reference from the first key- reference pair in the memory system ; However, Lee discloses a disaggregated memory architecture (“DINOMO”; see Fig. 2) including plural “KVS nodes” (KN) which service client requests using RDMA transactions on shared memory and which organizes data into both key-value pairs corresponding metadata, which examiner considers analogous to the Cassell disaggregated memory architecture (Fig. 1) including plural nodes A-C which service client requests using RDMA transaction on shared memory and which organizes data into both DTEs and corresponding ITEs. Examiner accordingly considers KN nodes 0-N depicted in Lee Fig. 2 as analogous to nodes A-C of Cassell (i.e., a KN node of Lee corresponds to one of the first or second computers). Lee discloses a disaggregated memory architecture whereby both data and corresponding metadata are stored within a disaggregated memory (DPM; Fig. 2) which is external to and shared by KVS nodes. Specifically, Lee discloses the following limitations: the request for the first reference identifies the first key; ( “ DINOMO allows applications to perform … lookup(key)… We refer to lookup operations as reads” [3, pg. 3]) – As taught in Section 3, read requests specify a key associated with the request-- in response to the request for the first reference (“a cache miss” [pg. 7]) , determining, by the processor of the second computer (“the appropriate KN” [pg. 4]) , the first reference (“the address of the value” [pg. 7]) by using the first key to locate a first key-reference pair in the memory system (Fig. 2) , (“KNs can cache not only data in the form of values but also metadata in the form of shortcuts . … A shortcut entry keeps a fixed 64-bit pointer to the value in DPM; accessing the data incurs a one-sided operation to DPM. If neither value nor shortcut are cached , accessing the value incurs significant overhead: the KN needs to traverse a metadata structure in DPM to find the value’s location and then access the value.” [3.3, pg. 5] // “A client first contacts a RN to obtain cluster membership and caches the mapping of key ranges to various KNs. The client contacts the appropriate KN that will then perform the read or write operation on its behalf” [3.1, pg. 4] // // Fig. 2) – As taught in Sections 3 and 3.1, a client contacts an “appropriate KN” caching a “shortcut” in order to perform a read operation associated with a given key, which examiner notes is analogous to step (1) of Cassell Fig. 1 whereby a client reads an ITE from a Node A which contains the ITE within its local Index Table. Accordingly, the “appropriate KN” of Lee corresponds to claimed “ the processor of the second computer ”. As clarified in Section 3.3, when a cache lookup within a KN for a shortcut misses, the KN (i.e., instead of the client) must instead retrieve the shortcut from a metadata structure located within the DPM (i.e., upon a cache miss, the appropriate KN locates “ a first key-reference pair in the memory system ”). -- and then reading (“index traversals” [pg. 7) , by the processor of the second computer, the first reference from the first key- reference pair in the memory system; (“For reads, an KN directly returns the value from its cache upon a value hit. On a shortcut hit, it performs a single one-sided operation to retrieve the value in DPM from the shortcut pointer. On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ” [3.6, pg. 7]) – As discussed above and as clarified in Section 3.6, upon a cache miss, a KN (i.e., as opposed to a client; i.e., “ the processor of the second computer ”) performs an index traversal from a structure in DPM to identify the address of the requested data (i.e., “ reading ” “ the first reference from the first key-reference pair in the memory system ”)-- Cassell and Lee are considered analogous to the claimed invention because they all relate to the same field of performing client read and write operations in KVS whereby both metadata and data are stored within a disaggregated, shared storage system and whereby plural processing nodes must share access to memory located within the disaggregated storage system. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cassell with the teachings of Lee and realize a disaggregated storage system whereby references for requested data are read from an external, shared memory. Storing references to data in an external, shared memory such as a DPM provides a ground source of truth for key-reference pairs in a disaggregated storage system, providing a globally-consistent view of data in a scalable manner as disclosed in Lee Section 3.2: “Figure 2 shows the data-plane components in DINOMO. DINOMO stores data (key-value pairs) and metadata (indexing structures) in DPM, providing durability and the source of ground truth … Thus, with such PM indexes , DINOMO provides a globally consistent view of data in a scalable manner, independent of the number of KNs.” [3.2, pg. 4] The combined teachings of Cassell and Lee render obvious the following limitations: transmitting the first reference (Cassell, ITE, Fig. 1 // Lee, shortcuts, Fig. 2) , by the second computer (Lee, Section 3.6) to the first computer (Lee, “On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ”)(Cassell, “(1) A node and ITE is determined by the key’s hash and is read with RDMA from node A’s index table” [Fig. 1]) – As discussed above and shown in Cassell Fig. 1, the ITE associated with the client request is looked up from an index table of node A (i.e., analogous to a lookup of a shortcut in a KN cache of Lee ). As clarified in Lee , in the event a shortcut is not located within the cache of a KN node, the KN node performs an index traversal to locate the reference within an external DPM. One of ordinary skill in the art would accordingly understand that in the event of a cache miss in the lookup of the index table of Node A during step (1) of Cassell , Node A would perform an index traversal to locate the ITE from an external, shared memory, such as the PM index located within a DPM of Lee Fig. 2. In such a scenario, the ITE would be “ transmit ” “ by the second computer ” (i.e., node A) “ to the first computer ” (i.e., node B) because the ITE is received by Node B (i.e., “ to ” the first computer) but the index traversal is performed by Node A (i.e., transmitting the first reference “ by ” the second computer). reading … the first data directly from the memory system, using the first reference transmitted by the second computer (Cassell, Fig. 1, step (4)) – As discussed above and shown in Cassell Fig. 1, during step (4), node B performs an RDMA read of the DTE associated with the ITE received during step (1) (i.e., first data is read “ directly from the memory system ” “ using the first reference transmitted by the second computer ”) Regarding Claim 12, The same motivation to combine provided in Claim 11 is equally applicable to Claim 12. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11, further comprising: transmitting, by the first computer to the second computer, a put request (Cassell, “Nessie’s PUT protocol” [4.2.2, pg. 6]) identifying a second key-reference pair (Lee, “DINOMO allows application to perform insert (key, value) operations” [3, pg. 3]) , the second key-reference pair including a second reference to second data in the memory system (Lee, “A shortcut entry keeps a fixed 64-bit pointer to the value in DPM “ [3.3, pg. 5]) , and storing, by the second computer in response to the put request, the second key-reference pair in the memory system (Cassell, “Abstractly, Nessie’s PUT protocol performs a forward pass over a requested key’s possible ITEs to insert a new entry … During the forward pass, Nessie iterates over a requested key’s possible ITE’s searching for a candidate ITE that is empty … With a candidate ITE chosen, Nessie must allocate a DTE for the PUT’s key-value pair ” [4.2.2, pg. 6] // “Sample PUT … by a client on node B : … (5) ITE 20 on node A is valid (unused) candidate. Create a new local DTE . (6) CAS ITE 20 on node A to refer to the new DTE ” [Fig. 2] // Lee, “least frequently used shortcuts are evicted” [4, pg. 8] // “DINOMO stores … metadata (indexing structures) in DPM, providing durability and ground truth” [3.2, pg. 3]) – As taught in Cassell Section 4.2.2, a node (e.g., node B; see Fig. 2) can perform a “PUT” operation associated with a distinct key in order to place associated data into the memory system. As shown in Fig. 2, node B allocates a new ITE entry (i.e., “ a second reference for accessing second data ”) to the index table on node A which is allocated for “the PUT’s key-value pair” (i.e., “ a second key-reference pair ”). As further shown in Fig. 2, as a result of a PUT operation performed by node B, a resulting reference is stored in an index table of node A, and an associated data table entry is stored on node B (i.e., “ storing the second key-reference pair in ” an index table of node A). Finally, as taught in Lee , least-frequently-used shortcuts are evicted from the cache of a KN (i.e., into DPM; see section 3.2) to make room for other shortcuts to be cached (i.e., storing the shortcut “ by the second computer in response to the put request ” into “ the memory system ” to free up space in cache). Regarding Claim 13, The same motivation to combine provided in Claim 11 is equally applicable to Claim 13. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 13, further comprising: transmitting, by the first computer to the second computer, a delete request (Cassell, “DELETEs in Nessie” [4.2.4, pg. 7]) identifying a second key (Lee, “DINOMO allows applications to perform … delete(key) ” [3, pg. 3]) , wherein the second key is part of a second key-reference pair stored in the memory system (Lee, “DINOMO stores … metadata (indexing structures) in DPM” [3.2, pg. 3]) ; and deleting, by the second computer in response to the delete request, the second key-reference pair from the memory system (Cassell, Fig. 2 “Sample PUT … by a client on node B” // “DELETEs in Nessie are identical to PUTs, but instead of inserting a DTE with a specified value, a DELETE inserts a DTE with an empty value … marking the ITE as empty” [4.2.4, pgs. 7-8] // Fig. 1)(Lee, Section 3 // Fig. 1) – As taught in Cassell Section 4.2.4, a node can perform a “DELETE” operation in a manner which is identical to a PUT operation. As clarified in Fig. 2, node B performs a PUT operation associated with a unique key (i.e., “ a second key ”) in order to insert an ITE into node A (step 6) and a corresponding DTE into node B (step 8)(i.e., “ a second key-reference pair ”). One of ordinary skill in the art would accordingly understand, in view of Cassell Section 4.2.4 and Fig. 2 that a DELETE operation performed by node B with respect to the second key would delete the associated key-reference pair by inserting an empty DTE and marking the associated ITE as empty. Finally, as taught in Lee and shown in Fig. 1, applications initiate delete requests which are transmit to KNs (i.e., “ transmitting ” the delete request “ by the first computer to the second computer ”; see also Cassell Fig. 1, whereby the client is located on the first computer.) Regarding Claim 14, The same motivation to combine provided in Claim 11 is equally applicable to Claim 14. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11, wherein determining the first reference by the processor of the second computer includes: computing a hash of the first key (Cassell, “(1) A node and ITE is determined by the key’s hash ” [Fig. 2]) to locate a bucket in a hash table in the memory system at which the first key-reference pair is stored. (Lee, “DINOMO uses … P-CLHT … which supports lock-free reads and log-free in-place writes, as its metadata index in DPM … Each bucket in P-CLHT has the size of a single cache line” [4, pg. 7]) – As previously discussed (see Claim 11 limitation mappings above) and as shown in Cassell Fig. 2, any node (i.e., including node A) uses a hash of a received key in order to locate an associated ITE (i.e., to locate “ the first key-reference pai r”). As clarified in Lee , shortcuts are persisted in DPM (i.e., are stored “ in the memory system ”) in at hash table type structure which organizes data into buckets (i.e., “ to locate a bucket in a hash table ”). Regarding Claim 15, The same motivation to combine provided in Claim 11 is equally applicable to Claim 15. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11, further comprising: before determining the first reference, updating, by the second computer, a lock (Cassell, “a watermark” [4.1.1, pg. 5]) associated with the first key-reference pair to indicate that the lock is taken; and after determining the first reference, updating, by the second computer, the lock to indicate that the lock is available (Cassell, “Because RDMA operations update their bytes in address order, the last bit of an ITE is used as a watermark which clients poll on to determine if an operation has completed [6]. This provides a lower-latency alternative to RDMA-s event-raising model” [4.1.1, pg. 5] // “Like ITEs, DTEs also contain a watermark bit on which clients poll to determine whether or not an operation has completed.” [4.1.2, pg. 5] // Lee, “On a cache miss, the KN performs multiple one-sided operations to find the address of the value (index traversals) ” [3.6, pg. 7]) – As taught in Cassell Sections 4.1.1 and 2, each ITE and DTE includes a “watermark bit” which enables clients to determine whether an operation being performed on the associated ITE and DTE is complete. In this context, examiner considers the watermark associated with an ITE and DTE as “ a lock ” which is “ updat[ed] ” to indicate whether or not an associated watermark bit (and thus, whether or not the associated ITE and the associated DTE) is available. Finally, as previously discussed (see Claim 1 limitation mappings above) and as taught in Lee , upon a cache miss for a reference, a KN node (i.e., “ the second computer ”) performs the index traversal of DPM using RDMA and therefore would be the computer updating the lock when performing RDMA reads to locate the reference. Regarding Claim 16, The same motivation to combine provided in Claim 11 is equally applicable to Claim 16. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11 (see Claim 11 limitation mappings above) , further comprising: receiving, by the first computer from the second computer (Cassell, node A, Fig. 1) , a request for a second reference to second data (Cassell, “one Nessie instance per node ” [4.1, pg. 5] // “Nessie’s GET protocol consists of a forward pass searching for a DTE containing the requested key” [4.2.1, pg. 6] // Fig. 1) – As previously discussed (see Claim 11 limitation mappings above) , each node (including Node A; i.e., “ the second computer ”) includes a Nessie instance and thus performs the GET protocol disclosed in Cassell Section 4.2.1 (i.e., transmits “ a request for a second reference to second data ” distinct from first data; see Claim 11 limitation mappings above.) One of ordinary skill in the art would accordingly understand that node A of Cassell Fig. 1 would also perform a GET operation for second in the same manner as node B-- , wherein the request for the second reference identifies a second key associated with the second data (Lee, Section 3) – As previously discussed (see Claim 11 limitation mappings above) , requests for a reference identify an associated key-- ; determining, by the processor of the first computer, the second reference by using the second key to locate a second key-reference pair in the memory system, and then reading, by the processor of the first computer, the second reference from the second key-reference pair in the memory system (Lee, Sections 3-3.6) – As previously discussed (see Claim 11 limitation mappings above) , a key is used to locate and subsequently read an associated key-reference pair from DPM upon a cache miss-- ; and transmitting the second reference, by the first computer to the second computer (Cassell, Section 4.2.1) – As previously discussed (see Claim 11 limitation mappings above) , a node receives a reference after requesting the reference. Regarding Claim 17, The same motivation to combine provided in Claim 11 is equally applicable to Claim 17. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11, further comprising: storing the first reference in a reference cache (Cassell, “index table” [4.1.1, pg. 5]) in the first computer; reading the first reference from the reference cache in the first computer (Cassell, “Each instance of Nessie contains an index table .. Each index table entry (ITE) … operated on by atomic RDMA CAS verbs” [4.1-4.1.1, pg. 6] // “With a candidate ITE chosen, Nessie must allocate a DTE for the PUT’s key-value pair. Nessie’s decoupled design allows this DTE to be placed on any node ” [4.2.2] // Fig. 2) – As previously discussed (see Claim 11 limitation mappings above) and as taught in Cassell Section 4.1.1, ITEs (e.g., including “ the first reference ”) are written to and read from (via RDMA; i.e., “ storing ” and “ reading ” references) an “index table” which is deployed on each node. In this context, examiner considers an index table as “ a reference cache ”. As taught in Section 4.2.2, ITEs and corresponding data table entries (DTEs) are decoupled and thus ITEs can be located on any node. As shown in Fig. 2, an ITE (e.g., ITE 10 of node B) can be located on a same node as a requesting client (e.g., node B; i.e., on “ the first computer ”) ; and storing, by the first computer, using the first reference read from the reference cache, updated data (Cassell, Fig. 2) – As shown in Cassell Fig. 2, as part of a PUT operation, data (e.g., Val Z) belonging to a given key (e.g., key K1) and associated with a given ITE (e.g., ITE 20 of node A) expires after a predetermined expiration time (e.g., time ‘t’), after which a new value (e.g., Val X) associated with the same key is associated with the same ITE. In such an example, the new value (Val X; i.e., “ updated data ”) effectively updates the expired value (Val Z) and uses a same candidate ITE (ITE 20 of node A; i.e., “ the first reference ”). at the memory address of the first data in the memory system (Lee, “A shortcut entry keeps a fixed 64-bit pointer to the value in DPM ” [3.3, pg. 5]) – As previously discussed (see Claim 11 limitation mappings above) , references to data point to the corresponding data within the memory system. Regarding Claim 18, The same motivation to combine provided in Claim 11 is equally applicable to Claim 18. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11, further comprising: storing, by the first computer, the first data in a cache (Cassell, LRU Data Cache, Fig. 1) of a processor of the first computer (Cassell, “If a valid DTE is found containing the matching key, it is cached and the value is returned” [4.2.1, pg. 6] // “The immutable nature of valid DTEs allows them to be locally cached … Nessie uses a small least recently used (LRU) cache on each node” [4.1.3, pg. 6] // Fig. 1) – As taught Cassell Section 4.2.1, as part of the GET operation, after a node (e.g.., node B; see Fig. 1) identifies a valid data table entry (DTE) which matches the requested key, the DTE is cached locally-- ; after storing the first data in the cache of the processor of the first computer, deleting, by the first computer, the first data from the cache of the processor of the first computer in response to a request to access updated data (Cassell, “(2) Local cache lookup on key “K1” returns a match with expiration time t. This expired cache entry is evicted ” [Fig. 2]) – As shown in Cassell Fig. 2, as part of a PUT operation, data (e.g., Val Z) belonging to a given key (e.g., key K1) and associated with a given ITE (e.g., ITE 20 of node A) expires after a predetermined expiration time (e.g., time ‘t’), after which a new value (e.g., Val X) associated with the same key is associated with the same ITE. In the process, the expired data is evicted (i.e., is “ delet[ed] ”) from the LRU data cache (step (2)). In this context, a request to PUT Val X (i.e., “ a request to access updated data ”) causes a previous value associated with the same key (e.g., Val Z; i.e., “ the first data ”) to be deleted from the LRU cache after Val Z has expired.-- , wherein the updated data is stored at the memory address of the first data in the memory system; and after deleting the first data, reading, by the first computer, the updated data directly from the memory system using the first reference to locate the memory address of the first data in the memory system (Cassell, “(4) Read the ITE determined by the second hash function on “K1” … Create a new local DTE. (6) CAS ITE 20 on node A to refer to the new DTE ” [Fig. 2]) – As discussed above and as shown in Cassell Fig. 2, after Val Z is evicted from the LRU cache, an ITE associated with Val Z (e.g., ITE 20 on node A; i.e., “ the first reference ”) is allocated to a DTE for Val X (i.e., allocated to “ the updated data ”). In such an embodiment, both Val X and Val Z (i.e., “ the updated data ” and “ the first data ”) are stored by reference at the same ITE on the same node (i.e., at a “ same memory address ”), after which ITE 20 on node A is allocated to the DTE for Val Z (i.e., “ the first reference ” is used to “ locate the memory address of the first data ”) . 07-21-aia AIA Claim s 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cassell further in view of Lee and Pandit et al. (US 20160026604 A1)(hereafter referred to as Pandit) . Regarding Claim 9, The same motivation to combine provided in Claim 1 is equally applicable to Claim 9. The combined teachings of Cassell and Lee disclose the following limitations: The computer system of claim 1 (see Claim 1 limitation mappings above) , Although Cassell Section 2.1 discloses that RDMA operations involve posting events to and polling of a completion queue, Cassell does not provide specific detail regarding how nodes interface with a completion queue during RDMA transactions. Specifically, Cassell and Lee do not explicitly disclose the following limitations: transmitting the request for the first reference includes writing, by the first computer to the memory system , a request for the first reference to be read by the second computer ; and wherein transmitting the first reference includes writing, by the second computer to the memory system , a response to the request for the first reference to be read by the first computer, the response including the first reference However, Pandit Fig. 1 discloses a data center network system 110 whereby plural client devices 182 share access to memory of remote Server Devices 110 using RDMA transactions, which examiner considers analogous to the Lee Fig. 2 DINOMO system whereby plural KNs share access to memory of a remote DPM. Pandit clarifies the following details regarding data transmission using RDMA: transmitting the request for the first reference includes writing, by the first computer to the memory system, a request for the first reference to be read by the second computer; (Figs. 1A + 1B // “the adapter device RDMA completion queue (CP) (HWCQ) 175 is used in connection with the adapter send queue 171 and the adapter receive queue 172” [0041] // Fig. 5 // “At process S501, the adapter device 111 receives a first incoming packet … ( from a remote system 200 ) … At process S502, the adapter device 111 adds the first incoming packet to the adapter device receive queue (HWRQ1) 172 ” [0090-91]) – As shown in Pandit Fig. 5, when RDMA system 100 (see Fig. 1B) receives an incoming packet (S501), the packet is placed into a designated adapter device receive queue (S502) located within the RMDA system 100 (i.e., is placed into a receive queue of “ the memory system ”. One of ordinary skill in the art would accordingly understand that when a transaction originates from a remote system (e.g., such when as a node B of Cassell transmits an RDMA read request for an ITE; see Claim 1 limitation mappings above) and is received by a shared memory system (e.g., such as when the metadata index in DPM of Lee Fig. 2 is traversed by a KN upon a cache miss; see Claim 1 limitation mappings above), a packet received from the initiator would be written into a receive queue of the shared memory system (i.e., “ writing, by the first computer to the memory system, a request ”)-- and wherein transmitting the first reference includes writing, by the second computer to the memory system, a response to the request for the first reference to be read by the first computer, the response including the first reference (Fig. 9 // “At process 901, the adapter device 111 receives a fifth incoming packet … at S904, the kernel driver 118 access the fifth packet from the adapter send device receive queue 172, and determines that the incoming packet is an RDMA read packet … At process S906, the kernel driver 118 generates a read response work request that includes the data read from the source buffer 901. The kernel driver 118 posts the read response work request to the adapter device receive queue 171 ” [0128-133]) – As clarified in Fig. 9, in response to an RDMA request received from a remote system (steps S901 + S902), transmitting the requested data out from the shared memory to a remote system involves writing a response containing the data read from shared memory into a send queue of the shared memory system (i.e., “ writing, by the second computer to the memory system, a response to the request ”; whereby “ the response including ” the data read from shared memory)-- Cassell, Lee, and Pandit are all considered analogous to the claimed invention because they all relate to the same field of servicing memory transactions for remote devices in a storage environment whereby a KV database is implemented in shared memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cassell and Lee with the teachings of Pandit and realize a computer system whereby computers write requests and responses for data into shared memory queues. Doing so enables remote memory transactions to be performed without intermediary copying and without involvement from CPUs of a first and second computer, as disclosed in Pandit ¶0004: “a network communication adapter device of a first computer can use DMA to read data in a user-specified buffer in a main memory of the first computer and transmit the data as a self-contained message across a network to a receiving network communication adapter device of a second computer. The receiving communication adapter can use DMA to place the data into a user-specified buffer of a main memory of a second computer. This remote DMA process can occur without intermediary copying and without involvement of CPUs of the first computer and the second computer.” [0004] Regarding Claim 19, The same motivation to combine provided in Claim 11 is equally applicable to Claim 19. The combined teachings of Cassell and Lee disclose the following limitations: The method of claim 11 (see Claim 11 limitation mappings above) , Although Cassell Section 2.1 discloses that RDMA operations involve posting events to and polling of a completion queue, Cassell does not provide specific detail regarding how nodes interface with a completion queue during RDMA transactions. Specifically, Cassell and Lee do not explicitly disclose the following limitations: transmitting the request for the first reference includes writing, by the first computer to the memory system , a request for the first reference to be read by the second computer ; and wherein transmitting the first reference includes writing, by the second computer to the memory system , a response to the request for the first reference to be read by the first computer, the response including the first reference However, Pandit Fig. 1 discloses a data center network system 110 whereby plural client devices 182 share access to memory of remote Server Devices 110 using RDMA transactions, which examiner considers analogous to the Lee Fig. 2 DINOMO system whereby plural KNs share access to memory of a remote DPM. Pandit clarifies the following details regarding data transmission using RDMA: transmitting the request for the first reference includes writing, by the first computer to the memory system, a request for the first reference to be read by the second computer; (Figs. 1A + 1B // “the adapter device RDMA completion queue (CP) (HWCQ) 175 is used in connection with the adapter send queue 171 and the adapter receive queue 172” [0041] // Fig. 5 // “At process S501, the adapter device 111 receives a first incoming packet … ( from a remote system 200 ) … At process S502, the adapter device 111 adds the first incoming packet to the adapter device receive queue (HWRQ1) 172 ” [0090-91]) – As shown in Pandit Fig. 5, when RDMA system 100 (see Fig. 1B) receives an incoming packet (S501), the packet is placed into a designated adapter device receive queue (S502) located within the RMDA system 100 (i.e., is placed into a receive queue of “ the memory system ”. One of ordinary skill in the art would accordingly understand that when a transaction originates from a remote system (e.g., such when as a node B of Cassell transmits an RDMA read request for an ITE; see Claim 1 limitation mappings above) and is received by a shared memory system (e.g., such as when the metadata index in DPM of Lee Fig. 2 is traversed by a KN upon a cache miss; see Claim 1 limitation mappings above), a packet received from the initiator would be written into a receive queue of the shared memory system (i.e., “ writing, by the first computer to the memory system, a request ”)-- and wherein transmitting the first reference includes writing, by the second computer to the memory system, a response to the request for the first reference to be read by the first computer, the response including the first reference (Fig. 9 // “At process 901, the adapter device 111 receives a fifth incoming packet … at S904, the kernel driver 118 access the fifth packet from the adapter send device receive queue 172, and determines that the incoming packet is an RDMA read packet … At process S906, the kernel driver 118 generates a read response work request that includes the data read from the source buffer 901. The kernel driver 118 posts the read response work request to the adapter device receive queue 171 ” [0128-133]) – As clarified in Fig. 9, in response to an RDMA request received from a remote system (steps S901 + S902), transmitting the requested data out from the shared memory to a remote system involves writing a response containing the data read from shared memory into a send queue of the shared memory system (i.e., “ writing, by the second computer to the memory system, a response to the request ”; whereby “ the response including ” the data read from shared memory)-- Cassell, Lee, and Pandit are all considered analogous to the claimed invention because they all relate to the same field of servicing memory transactions for remote devices in a storage environment whereby a KV database is implemented in shared memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cassell and Lee with the teachings of Pandit and realize a computer system whereby computers write requests and responses for data into shared memory queues. Doing so enables remote memory transactions to be performed without intermediary copying and without involvement from CPUs of a first and second computer, as disclosed in Pandit ¶0004: “a network communication adapter device of a first computer can use DMA to read data in a user-specified buffer in a main memory of the first computer and transmit the data as a self-contained message across a network to a receiving network communication adapter device of a second computer. The receiving communication adapter can use DMA to place the data into a user-specified buffer of a main memory of a second computer. This remote DMA process can occur without intermediary copying and without involvement of CPUs of the first computer and the second computer.” [0004] 07-21-aia AIA Claim s 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cassell further in view of Lee and Guerin et al. (US 20150067088 A1)(cited by examiner in previous action)(hereafter referred to as Guerin ) . Regarding Claim 10, The same motivation to combine provided in Claim 1 is equally applicable to Claim 10. The combined teachings of Cassell and Lee disclose the following limitation: The computer system of claim 1 (see Claim 1 limitation mappings above) , wherein the steps further include: reading, by the first computer from a field of the first key, … to determine (Cassell, Fig. 1) that the first reference is owned by the second computer (Cassell, “Nessie computes a list of possible ITEs for the requested key using its cuckoo hashing functions” [4.2.1 pg. 6]) – As previously discussed in Cassell (see Claim 1 limitation mappings above) , a key is used by node B to determine where to read an ITE. The combined teachings of Cassell and Lee are silent regarding a key including an identifier. Specifically, the combined teachings of Cassell and Lee are silent regarding the following limitations: from … the first key, an identifier of the second computer However, Guerin discloses the following limitations: from … the first key, an identifier of the second computer (“DAG data records are loaded into the distributed key/value store observing the following model: the ID of the DAG node, a uniquely-identifiable 64-bit integer, is used as the key” [0181]) – Examiner considers the storage environment depicted in Guerin Fig. 1 as analogous to the storage environment depicted in Cassell Fig. 1. As taught in Guerin ¶0181, key-value data can be stored into a distributed key-value cache using “the ID of the DAG node” (i.e., “ an identifier ” of a computer) as a key for the data. The combined teachings of Cassell and Lee disclose a distributed remote key-value store accessible to clients via RDMA (Cassell, Fig. 1) . Guerin discloses a known method of using a unique node identifier as a key for data in a distributed key-value store (see limitation mappings above) . It would have been obvious to one of ordinary skill in the art, as taught by Guerin , to implement the known method of using a unique node identifier as a key for data in a distributed key-value store to the distributed remote key-value store accessible to clients via RDMA of Cassell . A person of ordinary skill in the art would have recognized that applying the known technique of using a unique node identifier as a key for data in a distributed key-value store to a distributed remote key-value store accessible to clients via RDMA would have yielded the predictable result of determining where to transmit a request for key-value data in the distributed remote key-value store using an identifier included within a key. Using an identifier included within a key to determine where to transmit a request for key-value data would have been expected to reduce an amount of time required to locate data in a remote key-value store by encoding a location of data within the key-value store directly into a unique identifier for data, thereby improving latency in responding to data access requests. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of using a unique node identifier as a key for data in a distributed key-value store, as taught by Guerin , to the distributed remote key-value store accessible to client via RMA of Cassell . Doing so would predictably result in determining where to transmit a request using an identifier included within a key. See MPEP 2143, Rationale D . Regarding Claim 20, The same motivation to combine provided in Claim 11 is equally applicable to Claim 20. The combined teachings of Cassell and Lee disclose the following limitation: The method of claim 11 (see Claim 11 limitation mappings above) , further comprising: reading, by the first computer from a field of the first key, … to determine (Cassell, Fig. 1) that the first reference is owned by the second computer (Cassell, “Nessie computes a list of possible ITEs for the requested key using its cuckoo hashing functions” [4.2.1 pg. 6]) – As previously discussed in Cassell (see Claim 1 limitation mappings above) , a key is used by node B to determine where to read an ITE. The combined teachings of Cassell and Lee are silent regarding a key including an identifier. Specifically, the combined teachings of Cassell and Lee are silent regarding the following limitations: from … the first key, an identifier of the second computer However, Guerin discloses the following limitations: from … the first key, an identifier of the second computer (“DAG data records are loaded into the distributed key/value store observing the following model: the ID of the DAG node, a uniquely-identifiable 64-bit integer, is used as the key” [0181]) – Examiner considers the storage environment depicted in Guerin Fig. 1 as analogous to the storage environment depicted in Cassell Fig. 1. As taught in Guerin ¶0181, key-value data can be stored into a distributed key-value cache using “the ID of the DAG node” (i.e., “ an identifier ” of a computer) as a key for the data. The combined teachings of Cassell and Lee disclose a distributed remote key-value store accessible to clients via RDMA (Cassell, Fig. 1) . Guerin discloses a known method of using a unique node identifier as a key for data in a distributed key-value store (see limitation mappings above) . It would have been obvious to one of ordinary skill in the art, as taught by Guerin , to implement the known method of using a unique node identifier as a key for data in a distributed key-value store to the distributed remote key-value store accessible to clients via RDMA of Cassell . A person of ordinary skill in the art would have recognized that applying the known technique of using a unique node identifier as a key for data in a distributed key-value store to a distributed remote key-value store accessible to clients via RDMA would have yielded the predictable result of determining where to transmit a request for key-value data in the distributed remote key-value store using an identifier included within a key. Using an identifier included within a key to determine where to transmit a request for key-value data would have been expected to reduce an amount of time required to locate data in a remote key-value store by encoding a location of data within the key-value store directly into a unique identifier for data, thereby improving latency in responding to data access requests. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of using a unique node identifier as a key for data in a distributed key-value store, as taught by Guerin , to the distributed remote key-value store accessible to client via RMA of Cassell . Doing so would predictably result in determining where to transmit a request using an identifier included within a key. See MPEP 2143, Rationale D . Response to Arguments The previous objection of Claim 16 is withdrawn. The previous 35 U.S.C. 112(b) rejections of claims 8 and 18 are withdrawn. Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of the newly-identified Lee reference 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. Conclusion 07-40 AIA 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. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm 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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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. /J.S.M./Examiner, Art Unit 2133 /ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133 Application/Control Number: 18/903,960 Page 2 Art Unit: 2133 Application/Control Number: 18/903,960 Page 3 Art Unit: 2133 Application/Control Number: 18/903,960 Page 4 Art Unit: 2133 Application/Control Number: 18/903,960 Page 5 Art Unit: 2133 Application/Control Number: 18/903,960 Page 6 Art Unit: 2133 Application/Control Number: 18/903,960 Page 7 Art Unit: 2133 Application/Control Number: 18/903,960 Page 8 Art Unit: 2133 Application/Control Number: 18/903,960 Page 9 Art Unit: 2133 Application/Control Number: 18/903,960 Page 10 Art Unit: 2133 Application/Control Number: 18/903,960 Page 11 Art Unit: 2133 Application/Control Number: 18/903,960 Page 12 Art Unit: 2133 Application/Control Number: 18/903,960 Page 13 Art Unit: 2133 Application/Control Number: 18/903,960 Page 14 Art Unit: 2133 Application/Control Number: 18/903,960 Page 15 Art Unit: 2133 Application/Control Number: 18/903,960 Page 16 Art Unit: 2133 Application/Control Number: 18/903,960 Page 17 Art Unit: 2133 Application/Control Number: 18/903,960 Page 18 Art Unit: 2133 Application/Control Number: 18/903,960 Page 19 Art Unit: 2133 Application/Control Number: 18/903,960 Page 20 Art Unit: 2133 Application/Control Number: 18/903,960 Page 21 Art Unit: 2133 Application/Control Number: 18/903,960 Page 22 Art Unit: 2133 Application/Control Number: 18/903,960 Page 23 Art Unit: 2133 Application/Control Number: 18/903,960 Page 24 Art Unit: 2133 Application/Control Number: 18/903,960 Page 25 Art Unit: 2133 Application/Control Number: 18/903,960 Page 26 Art Unit: 2133 Application/Control Number: 18/903,960 Page 27 Art Unit: 2133 Application/Control Number: 18/903,960 Page 28 Art Unit: 2133 Application/Control Number: 18/903,960 Page 29 Art Unit: 2133 Application/Control Number: 18/903,960 Page 30 Art Unit: 2133 Application/Control Number: 18/903,960 Page 31 Art Unit: 2133 Application/Control Number: 18/903,960 Page 32 Art Unit: 2133 Application/Control Number: 18/903,960 Page 33 Art Unit: 2133 Application/Control Number: 18/903,960 Page 34 Art Unit: 2133 Application/Control Number: 18/903,960 Page 35 Art Unit: 2133 Application/Control Number: 18/903,960 Page 36 Art Unit: 2133 Application/Control Number: 18/903,960 Page 37 Art Unit: 2133 Application/Control Number: 18/903,960 Page 38 Art Unit: 2133
Prosecution Insights