DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This Office Action is responsive to the Applicant’s amendment filed on June 19, 2026.3. Claims 1-20 are pending, of which claims presented for examination 1 and 12 are in independent form.
Response to Arguments
4. Applicant’s arguments, see “Claim Rejections – 35 U.S.C. § 101”, filed on June 19, 2026, have been carefully considered. Based on the arguments are considered to be persuasive. As a result the 35 U.S.C. § 101 rejection is withdrawn.
5. Applicant's arguments, see “Claim Rejections – 35 U.S.C. § 112”, filed on June 19, 2026, have been carefully considered. Based on the persuasive arguments the previous 35 U.S.C. § 112(b) is withdrawn.
6. Applicant’s argument, see “Claim Rejection - Art”, filed on June 19, 2026, have been carefully considered, but the arguments are not considered to be persuasive.7. Applicant’s Argument: Perumalla does not disclose “identifying, in the checkpoint, a unit entry that does not include any vertex data”. Applicant argues that Perumalla merely teaches taking a snapshot and does not disclose the claimed empty checkpoint unit entry. Applicant further argues that the node-table entry cited by the Examiner is part of data structure 200, which Applicant characterizes as an intermediary for acting on the graph, rather than an entry contained in the checkpoint. Examiner’s Response: Applicant’s argument has been considered but is not persuasive. The rejection does not rely on Perumalla as expressly reproducing the claimed. Checkpoint-entry terminology. Rather, Perumalla teaches an entry-based representation of graph information together with persistent checkpointing of that graph information. Perumalla teaches that node data structure 200 “includes at least one entry for each vector contained in a graph (index) 202” and that an entry may include a vector identifier and node-pointer fields. Perumalla further teaches embodiments having “a separate entry for each neighbor relationship in the graph” or “a separate entry for each node in the graph”. Perumalla additionally teaches that the node table may be created in “a database or other data store”, with entries corresponding to vectors of the graph. Perumalla also expressly teaches an existing graph-data entry whose node pointer is no longer populated, stating that “the entry in the node table for the deleted node has its node pointer set to null”. When adding a vector, Perumalla conversely teaches adding an entry corresponding to the vector and adding a new node-pointer value. Thus, Perumalla teaches individually addressable graph-data entries, including entries lacking a valid nod association, as well as populating entries with graph-node information. In view of Perummall’s separate teaching of persistently checkpointing the graph/index, it would have been a predictable implementation to use an available or unpopulated storage entry to receive graph/vertex information when generating the checkpoint.
8. Applicant’s Argument: Malkov and Perumalla do not teach identifying a plurality of subsets of lower-layer vertices as part of checkpoint generation. Applicant argues that Malkov teaches the HNSW graph but not checkpoint generation, while Perumalla allegedly provides only a generic snapshot disclosure and does not identify lower-layer vertex subsets as part of checkpoint generation. Examiner’s Response: Applicant’s argument has been considered but is not persuasive because it does not account for the combined teachings of Malkov and Perumalla. Malkov expressly teaches that HNSW “incrementally builds a multi-layer structure consisting of a hierarchical set of proximity graphs (layers) for nested subsets of the stored elements”. Malkov further teaches that the hierarchical search proceeds from upper layers down to the zero/lower layer.
Perumalla which expressly confabulates an HNSW nearest-neighbor implementation, teaches creating a graph/index and then “partitioning the graph or index into a plurality of shards”. Perumalla further maintains “a separate data stream for each shard” and routes update information to the stream corresponding to the shard containing the graph node representing the identified vector.
Accordingly, Malkov supplies the hierarchical lower-layer graph structure, while Perumalla expressly teaches dividing a nearest-neighbor graph/index into separately handled portions. When Perumalla’s portioning and checkpointing technique is applied to Malkov’s HNSW graph, the separately handled lower-layer graph portions reasonably correspond to the claimed plurality of subsets of vertices.
9. Applicant’s Argument: Neither reference teaches the complete claimed checkpoint-generation sequence “for each subset”.
Examiner’s Response: Applicant’s argument has been considered but is not persuasive because obviousness does not require either reference, individually, to disclose the complete-claimed sequence verbatim. The combined teachings provide a reason for the claimed organization.
Perumalla expressly teaches portioning its graph/index into multiple shards and maintain a separate stream for each shard. Those shard-specific streams forward graph-update information to an indexing service and a checkpoint service, and Perumalla explains that receiving containers “correspond to the shard of the graph containing a node representing the vector to be updated.
Perumalla then teaches that: [0029] “… the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors of the collection” and periodically: [0029] “… takes a snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B) and uploads the snapshot to a storage location.”. Perumalla separately teaches storing graph information using individual entries corresponding to vectors, nodes, or neighbor relationships.
Therefore, one of ordinary skill applying Perumalla’s shard-based checkpointing technique to Malkov’s hierarchical graph would have found it obvious to process the separately identified portions of the lower layer and serialize the corresponding vertex information into respective available checkpoint storage entries. Such an arrangement predictably preserves separately maintained portions of the graph in a form suitable for persistent checkpointing storage.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Malkov et al. “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” in view of Perumalla et al. US 2021/0173896 A1 (hereinafter Perumalla).
Regarding claim 1, Li discloses a method comprising: generating a neighbor graph vector index (Malkov [page 2, section 2.1, 3rd paragraph] e.g., “The NSW graph is constructed via consecutive insertion of elements in random order by bidirectionally connecting them to the M closest neighbors”, see also [page 5, 2nd column, Section 4.1 Influence of the construction parameters] e.g., “Network construction algorithm (alg. 1) is organized via consecutive insertions of the stored elements into the graph structure.”. This teaches generating (constructing via insertion), a graph index, where nodes correspond to vectors and edges represent neighbor relationship), wherein the neighbor graph vector index comprises an index of vertex identifiers between layers of a plurality of layers for a graph-based approximate nearest neighbor search in a vector database (Malkov [Abstract] e.g., “Hierarchical NSW incrementally builds a multi-layer structure consisting from hierarchical set of proximity graphs (layers)”, See also [page 3, 2nd column, lines 1-5] e.g., “The algorithm greedily traverses through the elements from the upper layer until a local minimum is reached (see Fig. 1 for illustration). After that, the search switches to the lower layer (which has shorter links)…”, see also [page 3, 2nd column, lines 13-15] e.g., “For every element we select an integer level l which defines the maximum layer for which the element belongs to”. These disclosures teach, plurality of layers, nodes (vertices) assigned across layers, and graph-based ANN search. The “index of vertex identifier between layers” is reasonably interpreted as: maintain node identities across layers and navigating between them during search), wherein the plurality of layers comprise a higher layer and a lower layer that includes more vertices than the higher layer (Malkov [Abstract] e.g., “The maximum layer in which an element is present is selected randomly with an exponentially decaying probability distribution” This shows that fewer nodes in higher layers and more nodes in lower layers. Thus, the claimed hierarchical relationship between layers is expressly taught); and
Malkov does not explicitly discloses: generating a checkpoint based on the neighbor graph vector index, wherein the checkpoint comprises a plurality of unit entries, wherein generating comprises:
identifying a plurality of subsets of vertices in the lower layer (Malkov [Abstract] e.g., “The maximum layer in which an element is present is selected randomly with an exponentially decaying probability distribution” This shows that fewer nodes in higher layers and more nodes in lower layers. Thus, the claimed hierarchical relationship between layers is expressly taught);
for each subset in the plurality of subsets: identifying, in the checkpoint, a unit entry that does not include any vertex data; and storing, in the unit entry, vertex data that identifies the vertices in said each subset; wherein the method is performed by one or more computing devices (Malkov [page 8, 1st column, section 5] e.g., “An implementation of the Hierarchical NSW algorithm presented in this paper is also distributed as a part of the open source nmsliblibrary1 together with an external C++ memory-efficient…”). Perumalla discloses generating a checkpoint based on the neighbor graph vector index, wherein the checkpoint comprises a plurality of unit entries (Perumalla [0029] e.g., “…updates the index and the vectors of the collection … periodically takes a snapshot (i.e., checkpoint) of the index and vector set … and uploads the snapshot to a storage location”, see also [0076] e.g., “A snapshot of the graph of the indexing service is taken and stored into persistent storage using the checkpoint service…”. These paragraphs teach: generating a checkpoint (snapshot), based on a graph index of vectors, and including stored data corresponding to nodes/vectors of the graph. The snapshot necessarily comprises a polarity of stored data entries representing portions of the graph and associated vectors, which reasonably correspond to the claimed “plurality of unit entries”) , wherein generating comprises:
identifying a plurality of subsets of vertices in the lower layer (Malkov [page 2, section 2.1, 3rd paragraph] e.g., “The NSW graph is constructed via consecutive insertion of elements in random order by bidirectionally connecting them to the M closest neighbors”, see also [Abstract] e.g., “Hierarchical NSW incrementally builds a multi-layer structure consisting from hierarchical set of proximity graphs (layers) for nested subsets of the stored elements. The maximum layer in which an element is present is selected randomly with an exponentially decaying probability distribution”. These neighbor relationships inherently define groupings of vertices (e.g., adjacency lists or neighbor sets) within the lower layer. Such groupings reasonably correspond to subsets of vertices);
for each subset in the plurality of subsets: identifying, in the checkpoint, a unit entry that does not include any vertex data (Perumalla [0029] e.g., “In an embodiment, at circle “6B,” the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors of the collection. In an embodiment, the checkpoint service 126 periodically takes a snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B) and uploads the snapshot to a storage location.”, see also [0015] e.g., “ According to embodiments described herein, the nearest neighbor search service includes an interface that enables users to create collections of searchable vectors, add and update vectors to a collection, delete vectors from a collection, and perform searches for nearest neighbors to a given vector. In one embodiment, the nearest neighbor search service enables users to add, update, and delete vectors of a collection in real-time while also enabling users to perform searches at the same time” These paragraphs shows a vector-database-like nearest neighbor service using a graph index and a checkpoint service that snapshots the index and vectors to persistent storage. See also [0066] e.g., “The entry in the node table for the deleted node has its node pointer set to null at block 608.”. Perumalla already uses entries that can be empty/cleared (null) in a graph-related table.);he checkpoint service ... takes a snapshot of the index and vector set … and uploads the snapshot to a storage location” see also [0076] e.g., “A snapshot of the graph of the indexing service is taken and stored into persistent storage…”. The snapshot necessarily involves creating and managing storage entries (e.g., records, data units, or structures) within persistent storage to hold graph and vector data) ; and storing, in the unit entry, vertex data that identifies the vertices in said each subset (Perumalla [0076] e.g., “A snapshot of the graph of the indexing service is taken and stored into persistent storage …”, see also [0036]-[0038]. Perumalla teaches storing both the graph structure and associated vector data in a checkpoint (snapshot)); It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to incorporate the incremental updates for nearest neighbor search taught by Perumalla into the efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs taught by Malkov, in order to structure the snapshot as multiple checkpoint entries , each initially empty, and to allocate an empty entry for each subset of vertex data to be serialized, a routing storage-allocation choice in view of Perumalla’ s snapshotting of graph state and its use of table entries that can be null.
Claim 12 incorporates substantively all the limitations of claim 1 in a non-transitory storage media and rejected under the same rationale.
Regarding claim 2, the proposed combination Markov and Perumalla teaches the method of claim 1, wherein storing comprises storing the vertex data for a first unit entry concurrently with storing the vertex data for a second unit entry (Perumalla [0076] e.g., “A snapshot of the graph of the indexing service is taken and stored into persistent storage using the checkpoint service…”. It would have been obvious to store multiple checkpoint units concurrently to improve performance, as parallelization of independent data writes is a well-known optimization (see [0040]-[0050]).
Regarding claim 3, the proposed combination Markov and Perumalla teaches the method of claim 2, wherein each unit entry stores each subset of vertices of the lower layer as a separate series of vertex identifiers (Malkov [Abstract] e.g., “The maximum layer in which an element is present is selected randomly with an exponentially decaying probability distribution” This shows that fewer nodes in higher layers and more nodes in lower layers. Thus, the claimed hierarchical relationship between layers is expressly taught).
Regarding claim 4, the proposed combination Markov and Perumalla teaches the method of claim 2, wherein each unit entry comprises a separate binary large object including vertex identifiers of the respective subset of vertices (Perumalla [0038] e.g., “In some embodiments, a data structure 200 includes a separate entry for each neighbor relationship in the graph 202. For example, if a node N3 has neighbors N5 and N8, then the data structure 200 may store one entry for the relationship between N3 and N5 and a separate entry for N3 and N8”, see also [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B) and uploads the snapshot to a storage location.”. Each “separate entry” corresponds to a discrete storage object. Persisting such entries as binary large objects (BLOBs) is conventional way to serialize independent state chunks. The vertex identifier (vector IDs) for each subset are explicitly stored in these entries [0037]).
Regarding claim 5, the proposed combination Markov and Perumalla teaches the method of claim 1, wherein the checkpoint comprises a plurality of vertex identifiers stored in series for each layer of the neighbor graph vector index (Malkov [page 3, 1st column, 4th paragraph] e.g., “The idea of Hierarchical NSW algorithm is to separate the links according to their length into different layers … In such structure, the search starts from the upper layer … After that, the search switches to the lower layer…”, see also [0029] e.g., “… the checkpoint service 126 periodically takes a snapshot of the index and vector set … and uploads the snapshot to a storage location.”. Malkov explicitly teaches that vertices are organized in layers; each layer contains a subset of vertices. Perumalla teaches serializing checkpoint data for storage. Storing vertex identifiers in series per layer is a predictable, conventional way to serialize the layered graph for checkpointing.
Regarding claim 6, the proposed combination Markov and Perumalla teaches the method of claim 1, wherein the checkpoint comprises a layer to layer-to-layer map for each layer of the neighbor graph vector index, where each layer-to-layer map maps higher layer vertex identifiers to lower layer vertex identifiers (Malkov [page 3, 1st column and 2nd column] e.g., “…search switches to the lower layer (which has shorter links), restarts from the element …the previous layer …”. Malkov teaches a hierarchical graph structure in which search proceeds from an upper layer to a lower layer, restarting from a node identified in the higher layer (See Malkov, Section 3 (3 Motivation). This inherently defines a mapping between higher-layer nodes and corresponding nodes in lower layers used for continued traversal. It would have been obvious to explicitly store such relationships in a checkpoint to enable reconstruction of the index structure).
Regarding claim 7, the proposed combination Markov and Perumalla teaches the method of claim 1, wherein the checkpoint comprises a vertex neighbor map for each layer of the neighbor graph vector index, where each vertex neighbor map maps vertex identifiers of vertices in a respective layer to neighbor vertex identifiers of vertices that are neighbors of the vertices in the respective layer (Markov [page 3, 2nd column 2] e.g., “…a proximity graph (i.e., a graph containing only “short” links that approximate Delaunay graph)”. Malkov further teaches that each element in the graph maintains connections to neighboring elements via proximity graph links (i.e., adjacency relationships). These connections correspond to mappings from a vertex identifier to identifiers of neighboring vertices, as recited in the claimed “vertex neighbor map”).
Regarding claim 8, the proposed combination Markov and Perumalla teaches the method of claim 1, further comprising: shutting down a database instance that stores the neighbor graph vector index (Perumalla [0029] e.g., “… the checkpoint service 126 periodically takes a snapshot of the index and vector set… and uploads the snapshot to a storage location.” This shows checkpoint creation (i.e., take snapshot) and persistence (uploads … to a storage location), see also [0028] e.g., “…the data stream…forwards … to two separate containers … indexing service … checkpoint service…”. This shows parallel architect, simultaneous data distribution, and independent services acting on same data); and reloading the neighbor graph vector index from the checkpoint when the database instance restarts (Perumalla [0029] e.g., “… the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors… periodically takes a snapshot of the index and vector set… and uploads the snapshot to a storage location.” It would have been obvious to one of ordinary skill in the art to restore or reload the index from the stored snapshot, as the snapshot contains all information needed to reconstruct the in-memory index and resume operation.).
Regarding claim 9, the proposed combination Markov and Perumalla teaches the method of claim 1, further comprising reloading the neighbor graph vector index from the checkpoint by loading each of multiple unit entries in respective parallel processes (Perumalla [0028] e.g., “In an embodiment, at circle “5,” the data stream 131A forwards the update information to two separate containers 131A, 131B running in a container service, one container running an indexing service 124 and the other container running a checkpoint service 126”, see also [0029] e.g., “ In an embodiment, at circle “6B,” the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors of the collection. In an embodiment, the checkpoint service 126 periodically takes a snapshot…and uploads the snapshot to a storage location”. The checkpoint service partitions the graph/shard data across containers and loading each unit entry in parallel process is an obvious and predictable optimization for recovery).
Regarding claim 10, the proposed combination Markov and Perumalla teaches the method of claim 1, further comprising generating a catalog table that tracks checkpoints for a plurality of different neighbor graph vector indexes (Perumalla [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set … and uploads the snapshot to a storage location., where fields of the catalog table indicate”. Multiple snapshots correspond to different indexes, tracking multiple snapshots is inherently needed. Creating a catalog table is a routine data management step), where fields of the catalog table indicate: an identifier of a particular neighbor graph vector index of a particular checkpoint (Perumalla [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set…”. Each snapshot inherently identifies which graph/index it represents, storing that in a field is a predictable implementation),
an identifier of the particular checkpoint (Perumalla [0029] e.g., “…snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B)…”. Assigning a checkpoint ID to each snapshot is obvious to organize multiple snapshot), and an identifier of whether the checkpoint is an incremental checkpoint or a full checkpoint (Perumalla [0029] e.g., “…periodically takes a snapshot of the index and vector set…”).
Regarding claim 11, the proposed combination Markov and Perumalla teaches the method of claim 1, further comprising generating an index table that tracks checkpoints of a particular neighbor graph vector index (Perumalla [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set … and uploads the snapshot to a storage location., where fields of the catalog table indicate”. Multiple snapshots correspond to different indexes, tracking multiple snapshots is inherently needed. Creating a catalog table is a routine data management step), where fields of the index table indicate: an identifier of a particular checkpoint (Perumalla [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set…”. Each snapshot inherently identifies which graph/index it represents, storing that in a field is a predictable implementation), an identifier of a neighbor graph vector index layer (Perumalla [0029] e.g., “…snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B)…”. Assigning a checkpoint ID to each snapshot is obvious to organize multiple snapshot),, serialized data (Perumalla [0029] e.g., “…snapshot to a storage location”. Stored snapshot is inherently serialized, tracking which serialized data corresponds to which layer/checkpoint is routine), and an indicator of a type of information stored in the serialized data (Perumalla [0029] e.g., “…takes a snapshot of the index and vector set …”. Identifying type of sterilized data (index vs. vectors) is obvious metadata management).
Regarding claim 13, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein storing comprises storing the vertex data for a first unit entry concurrently with storing the vertex data for a second unit entry (Perumalla [0076] e.g., “A snapshot of the graph of the indexing service is taken and stored into persistent storage using the checkpoint service…”. It would have been obvious to store multiple checkpoint units concurrently to improve performance, as parallelization of independent data writes is a well-known optimization (see [0040]-[0050]).
Regarding claim 14, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 13, wherein each unit entry stores each subset of vertices of the lower layer as a separate series of vertex identifiers (Malkov [Abstract] e.g., “The maximum layer in which an element is present is selected randomly with an exponentially decaying probability distribution” This shows that fewer nodes in higher layers and more nodes in lower layers. Thus, the claimed hierarchical relationship between layers is expressly taught).
Regarding claim 15, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 13, wherein each unit entry comprises a separate binary large object including vertex identifiers of the respective subset of vertices (Perumalla [0038] e.g., “In some embodiments, a data structure 200 includes a separate entry for each neighbor relationship in the graph 202. For example, if a node N3 has neighbors N5 and N8, then the data structure 200 may store one entry for the relationship between N3 and N5 and a separate entry for N3 and N8”, see also [0029] e.g., “…the checkpoint service 126 periodically takes a snapshot of the index and vector set (for example, as stored by the container 114A or separately the container 114B) and uploads the snapshot to a storage location.”. Each “separate entry” corresponds to a discrete storage object. Persisting such entries as binary large objects (BLOBs) is conventional way to serialize independent state chunks. The vertex identifier (vector IDs) for each subset are explicitly stored in these entries [0037]).
Regarding claim 16, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein the checkpoint comprises a plurality of vertex identifiers stored in series for each layer of the neighbor graph vector index (Malkov [page 3, 1st column, 4th paragraph] e.g., “The idea of Hierarchical NSW algorithm is to separate the links according to their length into different layers … In such structure, the search starts from the upper layer … After that, the search switches to the lower layer…”, see also [0029] e.g., “… the checkpoint service 126 periodically takes a snapshot of the index and vector set … and uploads the snapshot to a storage location.”. Malkov explicitly teaches that vertices are organized in layers; each layer contains a subset of vertices. Perumalla teaches serializing checkpoint data for storage. Storing vertex identifiers in series per layer is a predictable, conventional way to serialize the layered graph for checkpointing.
Regarding claim 17, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein the checkpoint comprises a layer to layer-to-layer map for each layer of the neighbor graph vector index, where each layer-to-layer map maps higher layer vertex identifiers to lower layer vertex identifiers (Malkov [page 3, 1st column and 2nd column] e.g., “…search switches to the lower layer (which has shorter links), restarts from the element …the previous layer …”. Malkov teaches a hierarchical graph structure in which search proceeds from an upper layer to a lower layer, restarting from a node identified in the higher layer (See Malkov, Section 3 (3 Motivation). This inherently defines a mapping between higher-layer nodes and corresponding nodes in lower layers used for continued traversal. It would have been obvious to explicitly store such relationships in a checkpoint to enable reconstruction of the index structure).
Regarding claim 18, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein the checkpoint comprises a vertex neighbor map for each layer of the neighbor graph vector index, where each vertex neighbor map maps vertex identifiers of vertices in a respective layer to neighbor vertex identifiers of vertices that are neighbors of the vertices in the respective layer (Markov [page 3, 2nd column 2] e.g., “…a proximity graph (i.e., a graph containing only “short” links that approximate Delaunay graph)”. Malkov further teaches that each element in the graph maintains connections to neighboring elements via proximity graph links (i.e., adjacency relationships). These connections correspond to mappings from a vertex identifier to identifiers of neighboring vertices, as recited in the claimed “vertex neighbor map”).
Regarding claim 19, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein the instructions include instructions for: shutting down a database instance that stores the neighbor graph vector index (Perumalla [0029] e.g., “… the checkpoint service 126 periodically takes a snapshot of the index and vector set… and uploads the snapshot to a storage location.” This shows checkpoint creation (i.e., take snapshot) and persistence (uploads … to a storage location), see also [0028] e.g., “…the data stream…forwards … to two separate containers … indexing service … checkpoint service…”. This shows parallel architect, simultaneous data distribution, and independent services acting on same data); and reloading the neighbor graph vector index from the checkpoint when the database instance restarts (Perumalla [0029] e.g., “… the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors… periodically takes a snapshot of the index and vector set… and uploads the snapshot to a storage location.” It would have been obvious to one of ordinary skill in the art to restore or reload the index from the stored snapshot, as the snapshot contains all information needed to reconstruct the in-memory index and resume operation.).
Regarding claim 20, the proposed combination Markov and Perumalla teaches the one or more non-transitory storage media of claim 12, wherein the instructions include instructions for reloading the neighbor graph vector index from the checkpoint by loading each of multiple unit entries in respective parallel processes (Perumalla [0028] e.g., “In an embodiment, at circle “5,” the data stream 131A forwards the update information to two separate containers 131A, 131B running in a container service, one container running an indexing service 124 and the other container running a checkpoint service 126”, see also [0029] e.g., “ In an embodiment, at circle “6B,” the checkpoint service 126 reads the updates from the stream 131A and updates the index and the vectors of the collection. In an embodiment, the checkpoint service 126 periodically takes a snapshot…and uploads the snapshot to a storage location”. The checkpoint service partitions the graph/shard data across containers and loading each unit entry in parallel process is an obvious and predictable optimization for recovery).
Conclusion
13. THIS ACTION IS MADE FINAL. 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.
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Monday – Friday 8:30AM – 4:00PM.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/VAISHALI SHAH/Primary Examiner, Art Unit 2156
