DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Response to Arguments
Applicant’s remarks/amendment was filed on 21 July 2026.
Applicant’s arguments have been considered but they are not persuasive.
However, the Examiner welcomes any suggestion(s) Applicants may have on moving
prosecution forward. The Examiner’s contact information is in the Conclusion of this
office action.
Applicant argues:
Stephan does not disclose a precomputed mixed index comprising segment records that associate segments with sparse-index and dense-index fields. Stephan instead stores sparse and dense embeddings of documents and chunks in a vector database with metadata referencing the original document and chunk sources. See Stephan, ¶¶[0033], [0044]. Stephan's “sparse index” is a sparse embedding or BM25-style retrieval representation computed based on term occurrence counts and inverse document frequency (IDF) weighting. See Stephan, ¶ [0042].
Stephan's "dense index" is a dense embedding or representation of textual items such as word embeddings of chunks. See Stephan, ¶ [0033]. Neither of these is a precomputed field of context-aware, semantically related terms associated with each segment, as recited in the pending claims.
In response, the Examiner submits:
Contrary to Applicant’s assertion above, the Stephan reference does teach the recited limitation of “mixed index comprising segment records that associate respective segments with (i) main entities and location data from the sparse index (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”; note: frequencies of terms that are main entities) and (ii) context-aware, semantically related terms from the dense index (Stephan: at least ¶0033; “dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning) may be indexed and a dense index may be created”).
The instant claims do not recite a “precomputed mixed index”. The recited “segment records” do not associate segments with sparse-index and dense-index fields.
Rather, the recited “segment records” associate “respective segments with (i) main entities and location data from the sparse index and (ii) context-aware, semantically related terms from the dense index”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant further argues:
Moreover, Stephan does not disclose generating the mixed index "before receiving a
request to search for information" and then retrieving information by "matching the request against at least one of the sparse-index field or the dense-index field of the plurality of segment records." Stephan's retrieval instead operates at query time by generating dense and sparse embeddings of the user's input question. See Stephan ¶¶ [0046]-[0048]. Stephan then retrieves top-k chunks based on dense embedding similarity, sparse embedding similarity (e.g., dot-product similarity), or a hybrid embedding that is a convex combination of the dense and sparse embeddings controlled by a hyperparameter a. See Stephan, ¶ [0048]. Stephan also uses LLM
prompting and LLM-based identification of relevant documents and chunks as part of answering the user's question. See Stephan, ¶¶ [0046]-[0047]. This is fundamentally different from the claimed retrieval, which matches the request against precomputed sparse-index and dense-index fields of segment records without generating query embeddings or using an LLM to select responsive segments.
In response, the Examiner submits:
While the instant claims recite “generating, before receiving a request to search for information, a mixed index… ", they do not recite “generating, before query time, a mixed index…”.
The instant claims also do not recite a “precomputed sparse-index and dense-index fields of segment records without generating query embeddings or using an LLM to select responsive segments”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Stephan teaches “generate dense embeddings and sparse embeddings of the input question” (Stephan: at least ¶0045). An input question is not the same as a request to search for information. For example, a user may enter a query into a search box of a search engine, but the query that is text input is not a request to search for information. “Generate dense embeddings and sparse embeddings of the input question” does not contradict “generating, before receiving a request to search for information, a mixed index… ".
Claim Rejections - 35 USC § 112
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.
Claims 1-11 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.
Claim 1 recites “wherein the semantic searching comprises matching the request against at least one of the sparse-index field or the dense-index field of the plurality of segment records to identify one or more responsive segment records”.
“The sparse-index field” and “the dense-index field” lack proper antecedent basis.
Claims 2-11 depend from claim 1, and are rejected for the same reason(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that
form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless —
(a)(1) the claimed invention was patented, described in a printed publication, or
in public use, on sale, or otherwise available to the public before the effective
filing date of the claimed invention.
Claims 1-2, 4-6, 8-14 and 16-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US PGPUB 2025/0053835 by Stephan et al. (“Stephan”).
As to Claim 1, Stephan teaches a computer-implemented method, the method comprising: receiving a file for input into a data storage system, the file comprising a plurality of data (Stephan: at least ¶0020; “retrieving and extracting information from a universe of construction-specific documents (e.g., raw documents). The documents processed by the system herein may be construction-specific documents or construction project data”);
determining a structure of the file (Stephan: at least ¶0024; “use metadata to contextualize the content of the documents. In some cases, the document may comprise an image. The system may extract metadata to contextualize the image of the document and provide a description of the image”; ¶0039 further discloses “utilize a custom algorithm to parse the document types. For instance, the parsing algorithm may first determine if the document is image-based document by determining whether the ratio between characters to pages is lower than a predetermined threshold. If the ratio is below the threshold, the document is image-based. Otherwise, the document is not image-based, and the algorithm may further determine whether it is table-based document by checking whether the ratio of numeric to alphabetical characters is greater than a predetermined threshold. If yes, then the document is table-based document otherwise it is text-based document”), the structure comprising one or more components, each component having a corresponding component type, wherein the component type comprises one of: table, image, raw text, list, diagram, or handwritten notes (Stephan: at least ¶0024; “documents may be, for example, PDF, raw text or html/DOCX representation and the like. The document data that are processed and searchable by the system may include text PDFs, scanned PDFs, spreadsheets, tables contained within PDFs, Word documents and the like. In some cases, documents such as PDF or image file may be converted to text data using OCR (Optical Character Recognition) techniques”);
generating, based on the structure, one or more segments of data from the plurality of data of the file (Stephan: at least ¶0006; “process construction-specific document types into a plurality of chunks with custom parsing methods”; ¶0025 further discloses “extracting information and retrieving insights from the raw documents by converting the raw document texts into structured data (e.g., document datasets, indexes, embeddings)”; ¶0033 further discloses “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups. In some cases, chunking is done based at least in part on whether a piece of a document logically belongs together (e.g., separated by subheadings). In some cases, chunking is done based at least in part on a fixed chunk size with some chunk overlap for text that is too long”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”);
for each segment of the one or more segments of data: tokenizing, using an embedding model, the segment of data (Stephan: at least ¶¶0025, 0032-0033; ““methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “tokenize the construction data when calling the OpenAI APIs to use one or more LLMs. In some cases, the OpenAI is configured to tokenize the data” and “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks” and “the document dataset may transform the raw PDFs into parsed text which may then be converted into chunks” and “a chunk may, for example, be a sentence, a section, a passage, a paragraph, a clause, or a sub-clause of a document. The chunks may be defined such that they correspond to the format of the document”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”); and
assigning a location to the segment of data indicating an original position of the segment of data within the file (Stephan: at least ¶0024; “Semi-structured text may capture a significant portion of the information in the position, layout, and format of the text”; ¶0033 further discloses “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup”);
storing, in a sparse index in the data storage system, the one or more tokenized segments of data and the location of the respective segments, the sparse index comprising a plurality of tokenized segments of data related to a plurality of files in the data storage system (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”);
comparing, using the embedding model and a similarity algorithm, the one or more tokenized segments of data in the sparse index to an electronic library to retrieve results in the library at or above a threshold of similarity to the one or more tokenized segments of data in the sparse index (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”);
storing the results in a dense index in the data storage system (Stephan: at least ¶0033; “words that are closer in the vector space are expected to be similar in meaning) may be indexed”), the dense index comprising a plurality of terms that are semantically related to the plurality of files in the data storage system (Stephan: at least ¶0033; “a dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and words that are closer in the vector space are expected to be similar in meaning);
generating, before receiving a request to search for information, a mixed index in the data storage system based on the sparse index and the dense index (Stephan: at least ¶¶0033, 0048; “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; note: receiving of a query is not the same as a request to search), the mixed index comprising segment records that associate respective segments with (i) main entities and location data from the sparse index (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”; note: frequencies of terms that are main entities) and (ii) context-aware, semantically related terms from the dense index (Stephan: at least ¶0033; “dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning) may be indexed and a dense index may be created”), and the mixed index including the one or more tokenized segments of data from the sparse index (Stephan: at least ¶0033; “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup”) and the plurality of semantically related terms from the dense index (Stephan: at least ¶0033; “dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning) may be indexed and a dense index may be created”), the one or more tokenized segments of data and the plurality of semantically related terms being searchable using a semantic search (Stephan: at least ¶0019; “allow large volume of construction project data/files (e.g., thousands of pages) to be searchable” and ¶0033 also discloses “allow users to query any piece of information via a messaging interface by inputting a question in natural language”; “semantically similar chunks that can then be embedded and use in search lookups”; ¶0046 further discloses “select all documents that may be relevant to search for the user question”);
receiving the request to search for information within the data storage system (Stephan: at least ¶0019; “allow large volume of construction project data/files (e.g., thousands of pages) to be searchable” and ¶0033 also discloses “allow users to query any piece of information via a messaging interface by inputting a question in natural language”; ¶0052-0053 further disclose “inputting a question in natural language. The system may receive user question via the messaging application and output the answer in the message application. For example, a user may send text message (SMS) to ask questions and may receive a text message containing the answer and a list of sources” and “user may send a question as text message to a specified number”); retrieving, based on the request for information, information related to the request from the mixed index using semantic searching, wherein the semantic searching comprises matching the request against at least one of the sparse-index field or the dense-index field of the plurality of segment records to identify one or more responsive segment records (Stephan: at least ¶0033; “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶¶0047-0048 further discloses “combine the documents from the two relevancy searches (i.e., search for top-k most similar chunks based on sparse embeddings 230 and dense embeddings 220)” and “method may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding controlled by a hyperparameter to perform a single relevancy search”); and
outputting the retrieved information (Stephan: at least ¶0033; “the sparse index and dense index may be built for both the raw document and input query for information retrieval”; ¶0048 also discloses “employ dot product similarity search to retrieve the top-k most relevant chunks within each document based on dense embeddings 220 and based on sparse embedding 230. The method may then concatenate the result. Alternatively, instead of conducting two relevancy searches, the method may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding controlled by a hyperparameter to perform a single relevancy search”; ¶0053 further discloses “message application may optionally respond with a receipt confirmation and begin processing the question. The message interface may respond with a message containing the question, the answer, and a list of source documents used, as well as a link to drill down into the source documents. The user may click on the link and be directed to another interface (e.g., a web page) to see the answer and a list of source documents”).
As to Claim 2, Stephan teaches the computer-implemented method of claim 1, wherein the component type of the component of the one or more components comprises an image (Stephan: at least ¶0024; “documents may be, for example, PDF, raw text or html/DOCX representation and the like. The document data that are processed and searchable by the system may include text PDFs, scanned PDFs, spreadsheets, tables contained within PDFs, Word documents and the like. In some cases, documents such as PDF or image file may be converted to text data using OCR (Optical Character Recognition) techniques”) and wherein generating the one or more segments comprises generating a textual description of the image using a vision model (Stephan: at least ¶0024; “documents such as PDF or image file may be converted to text data using OCR (Optical Character Recognition) techniques. In some cases, the systems and platforms described herein may be configured to use metadata to contextualize the content of the documents” and “extract metadata to contextualize the image of the document and provide a description of the image”).
As to Claim 4, Stephan teaches the computer-implemented method of claim 1, wherein tokenizing the one or more segments of data comprises dividing the segment of data into individual units of data understandable to the embedding model (Stephan: at least ¶¶0032-0033; “the system may use one or more tokenization methods to provide feedback data into an LLM. The system may tokenize the construction data when calling the OpenAI APIs to use one or more LLMs. In some cases, the OpenAI is configured to tokenize the data” and “the system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “The document dataset may transform the raw PDFs into parsed text which may then be converted into chunks”).
As to Claim 5, Stephan teaches the computer-implemented method of claim 1, wherein storing the one or more tokenized segments of data comprises: generating one or more embeddings of the one or more tokenized segments (Stephan: at least ¶0033; “one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded” and “… converted into chunks. The chunks are then embedded and stored”); and storing the one or more embeddings in the sparse index (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”).
As to Claim 6, Stephan teaches the computer-implemented method of claim 1, wherein the library comprises a computer-implemented catalog of words in a vector database (Stephan: at least ¶¶0036, 0044, 0048; “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180. The same embedding procedure may be applied for all chunks for any new files/documents and the embeddings may be stored in a vector database with references to the document they originate from”).
As to Claim 8, Stephan teaches the computer-implemented method of claim 1, wherein the mixed index comprises one or more of: raw information from the file extracted by a smart parser (Stephan: at least ¶¶0025, 0033, 0048; “methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; ¶0033 also discloses “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”), a description field for images, a location field, the sparse index with main entities, and the dense index with context-aware, semantically related terms.
As to Claim 9, Stephan teaches the computer-implemented method of claim 1, wherein the plurality of files in the data storage system relate to one or more of: healthcare data, customer data (Stephan: at least ¶0020; “retrieving and extracting information from a universe of construction-specific documents (e.g., raw documents). The documents processed by the system herein may be construction-specific documents or construction project data”; ¶0036 further discloses “construction files/documents stored in a customer filesystems (e.g., Box, SharePoint, Procore, etc.). The customer Filesystems may be possessed by a customer entity and in communication with the system herein”), legal document data, government data, public records, or intellectual property data.
As to Claim 10, Stephan teaches the computer-implemented method of claim 1, further comprising: receiving a new file for input into the data storage system, the new file comprising a plurality of new data (Stephan: at least ¶0020; “retrieving and extracting information from a universe of construction-specific documents (e.g., raw documents). The documents processed by the system herein may be construction-specific documents or construction project data”);
determining a current structure of the new file (Stephan: at least ¶0024; “use metadata to contextualize the content of the documents. In some cases, the document may comprise an image. The system may extract metadata to contextualize the image of the document and provide a description of the image”; ¶0039 further discloses “utilize a custom algorithm to parse the document types. For instance, the parsing algorithm may first determine if the document is image-based document by determining whether the ratio between characters to pages is lower than a predetermined threshold. If the ratio is below the threshold, the document is image-based. Otherwise, the document is not image-based, and the algorithm may further determine whether it is table-based document by checking whether the ratio of numeric to alphabetical characters is greater than a predetermined threshold. If yes, then the document is table-based document otherwise it is text-based document”), the current structure comprising one or more current components, each current component having a corresponding current component type (Stephan: at least ¶0024; “documents may be, for example, PDF, raw text or html/DOCX representation and the like. The document data that are processed and searchable by the system may include text PDFs, scanned PDFs, spreadsheets, tables contained within PDFs, Word documents and the like. In some cases, documents such as PDF or image file may be converted to text data using OCR (Optical Character Recognition) techniques”);
generating, based on the current structure, one or more current segments of data from the plurality of new data (Stephan: at least ¶0006; “process construction-specific document types into a plurality of chunks with custom parsing methods”; ¶0025 further discloses “extracting information and retrieving insights from the raw documents by converting the raw document texts into structured data (e.g., document datasets, indexes, embeddings)”; ¶0033 further discloses “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups. In some cases, chunking is done based at least in part on whether a piece of a document logically belongs together (e.g., separated by subheadings). In some cases, chunking is done based at least in part on a fixed chunk size with some chunk overlap for text that is too long”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”);
for each segment of the one or more current segments of data: tokenizing, using the embedding model, the segment of data (Stephan: at least ¶¶0025, 0032-0033; ““methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “tokenize the construction data when calling the OpenAI APIs to use one or more LLMs. In some cases, the OpenAI is configured to tokenize the data” and “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks” and “the document dataset may transform the raw PDFs into parsed text which may then be converted into chunks” and “a chunk may, for example, be a sentence, a section, a passage, a paragraph, a clause, or a sub-clause of a document. The chunks may be defined such that they correspond to the format of the document”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”); and
assigning a current location to the segment of data indicating a current position of the segment of data within the new file (Stephan: at least ¶0024; “Semi-structured text may capture a significant portion of the information in the position, layout, and format of the text”; ¶0033 further discloses “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup”);
storing, in the sparse index, the one or more tokenized current segments of data and the location of the respective segments (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”);
comparing, using the embedding model, the one or more tokenized current segments of data to the electronic library to retrieve results in the library at or above the threshold of similarity to the one or more tokenized current segments of data in the sparse index (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”);
storing the results in the dense index in the data storage system (Stephan: at least ¶0033; “words that are closer in the vector space are expected to be similar in meaning) may be indexed”); and
regenerating at least a portion of the mixed index in the data storage system based on the sparse index and the dense index (Stephan: at least ¶¶0033, 0048; “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; ¶0044 further discloses “same embedding procedure may be applied for all chunks for any new files/documents”).
As to Claim 11, Stephan teaches the computer-implemented method of claim 1, further comprising: receiving an updated file for input into the data storage system, the updated file comprising an updated plurality of data, wherein the updated plurality of data is a changed version of the plurality of data (Stephan: at least ¶0021; “the graphic user interface 400A may have an update document sync button 402 configured to allow the user to update or initiate syncing for new documents”);
determining a current structure of the updated file (Stephan: at least ¶0024; “use metadata to contextualize the content of the documents. In some cases, the document may comprise an image. The system may extract metadata to contextualize the image of the document and provide a description of the image”; ¶0039 further discloses “utilize a custom algorithm to parse the document types. For instance, the parsing algorithm may first determine if the document is image-based document by determining whether the ratio between characters to pages is lower than a predetermined threshold. If the ratio is below the threshold, the document is image-based. Otherwise, the document is not image-based, and the algorithm may further determine whether it is table-based document by checking whether the ratio of numeric to alphabetical characters is greater than a predetermined threshold. If yes, then the document is table-based document otherwise it is text-based document”), the current structure comprising one or more current components (Stephan: at least ¶0024; “documents may be, for example, PDF, raw text or html/DOCX representation and the like. The document data that are processed and searchable by the system may include text PDFs, scanned PDFs, spreadsheets, tables contained within PDFs, Word documents and the like. In some cases, documents such as PDF or image file may be converted to text data using OCR (Optical Character Recognition) techniques”);
generating, based on the current structure, one or more current segments of data from the updated plurality of data (Stephan: at least ¶0006; “process construction-specific document types into a plurality of chunks with custom parsing methods”; ¶0025 further discloses “extracting information and retrieving insights from the raw documents by converting the raw document texts into structured data (e.g., document datasets, indexes, embeddings)”; ¶0033 further discloses “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups. In some cases, chunking is done based at least in part on whether a piece of a document logically belongs together (e.g., separated by subheadings). In some cases, chunking is done based at least in part on a fixed chunk size with some chunk overlap for text that is too long”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”);
comparing the one or more current segments of data with the one or more segments of data to identify changed data between the updated file and the file (Stephan: at least ¶¶0036; “sync server may monitor and detect changes made to construction files/documents stored in a customer filesystems (e.g., Box, SharePoint, Procore, etc.)” and “upon detection of the change, the system may sync a copy of the document stored in a repository or data store of the system 120”);
based on the comparing, for each segment of the one or more current segments of data: tokenizing, using the embedding model, the segment of data (Stephan: at least ¶¶0025, 0032-0033; ““methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “tokenize the construction data when calling the OpenAI APIs to use one or more LLMs. In some cases, the OpenAI is configured to tokenize the data” and “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks” and “the document dataset may transform the raw PDFs into parsed text which may then be converted into chunks” and “a chunk may, for example, be a sentence, a section, a passage, a paragraph, a clause, or a sub-clause of a document. The chunks may be defined such that they correspond to the format of the document”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”; note: tokenizing would comprise comparison); and
reassigning the location to the segment of data indicating an updated position of the segment of data within the file (Stephan: at least ¶0021; “the graphic user interface 400A may have an update document sync button 402 configured to allow the user to update or initiate syncing for new documents”; note: when file/document updated, positions also updated);
updating, in the sparse index, the one or more tokenized segments of data with the one or more tokenized current segments of data and the location of the respective segments (Stephan: at least ¶0021; “the graphic user interface 400A may have an update document sync button 402 configured to allow the user to update or initiate syncing for new documents”; ¶0033 further discloses “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”);
comparing the one or more tokenized current segments of data to the electronic library to retrieve updated results in the library at or above the threshold of similarity to the one or more tokenized current segments of data in the sparse index (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”);
storing the results in the dense index in the data storage system (Stephan: at least ¶0033; “words that are closer in the vector space are expected to be similar in meaning) may be indexed”); and
regenerating at least a portion of the mixed index in the data storage system based on the sparse index and the dense index (Stephan: Stephan: at least ¶¶0033, 0048; “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; ¶0044 further discloses “same embedding procedure may be applied for all chunks for any new files/documents”).
As to Claim 12, Stephan teaches a system comprising: one or more computing devices associated with a processor and a memory for executing computer-executable instructions configured to: receive a file for input into a data storage system, the file comprising a plurality of data (Stephan: at least ¶0020; “retrieving and extracting information from a universe of construction-specific documents (e.g., raw documents). The documents processed by the system herein may be construction-specific documents or construction project data”);
generate one or more segments of data from the plurality of data of the file (Stephan: at least ¶0006; “process construction-specific document types into a plurality of chunks with custom parsing methods”; ¶0025 further discloses “extracting information and retrieving insights from the raw documents by converting the raw document texts into structured data (e.g., document datasets, indexes, embeddings)”; ¶0033 further discloses “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups. In some cases, chunking is done based at least in part on whether a piece of a document logically belongs together (e.g., separated by subheadings). In some cases, chunking is done based at least in part on a fixed chunk size with some chunk overlap for text that is too long”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”);
store, in a first index in the data storage system, the one or more segments of data, the first index comprising a plurality of segments of data related to a plurality of files in the data storage system (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”);
compare the one or more segments of data to an electronic library to retrieve results in the library at or above a threshold of similarity to the one or more segments of data in the first index (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”);
store the results in a second index in the data storage system (Stephan: at least ¶0033; “words that are closer in the vector space are expected to be similar in meaning) may be indexed”), the second index comprising a plurality of terms that are semantically related to the plurality of files in the data storage system (Stephan: at least ¶0033; “a dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and words that are closer in the vector space are expected to be similar in meaning); and
generating, before receiving a request to search for information, a mixed index in the data storage system based on the first index and the second index (Stephan: at least ¶¶0033, 0048; “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; note: receiving of a query is not the same as a request to search), the mixed index comprising segment records that associate respective segments with (i) main entities and location data from the first index (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”; note: frequencies of terms that are main entities) and (ii) context-aware, semantically related terms from the second index (Stephan: at least ¶0033; “dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning) may be indexed and a dense index may be created”), and the mixed index including the one or more segments of data from the first index (Stephan: at least ¶0033; “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup”) and the plurality of semantically related terms from the second index (Stephan: at least ¶0033; “dense index each may correspond to or index elements such as a representation of textual items (e.g., word embeddings of a chunk of texts)” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning) may be indexed and a dense index may be created”), the one or more segments of data and the plurality of semantically related terms being searchable using a semantic search (Stephan: at least ¶0019; “allow large volume of construction project data/files (e.g., thousands of pages) to be searchable” and ¶0033 also discloses “allow users to query any piece of information via a messaging interface by inputting a question in natural language”; “semantically similar chunks that can then be embedded and use in search lookups”; ¶0046 further discloses “select all documents that may be relevant to search for the user question”).
Claim 17 (a medium claim) corresponds in scope to Claim 12 and is similarly rejected.
As to Claim 13, Stephan teaches the system of claim 12, wherein to store the results in the second index, the computer-executable instructions are further configured to: for each segment of the one or more segments of data: tokenize, using an embedding model, the segment of data (Stephan: at least ¶¶0025, 0032-0033; ““methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “tokenize the construction data when calling the OpenAI APIs to use one or more LLMs. In some cases, the OpenAI is configured to tokenize the data” and “use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks” and “the document dataset may transform the raw PDFs into parsed text which may then be converted into chunks” and “a chunk may, for example, be a sentence, a section, a passage, a paragraph, a clause, or a sub-clause of a document. The chunks may be defined such that they correspond to the format of the document”; ¶0040 further discloses “If the document is image-based, OCR techniques may be employed to converted it to text data”); and assign a location to the segment of data indicating an original position of the segment of data within the file;
generate one or more embeddings of the one or more tokenized segments (Stephan: at least ¶0033; “one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded” and “… converted into chunks. The chunks are then embedded and stored”); and store the one or more embeddings in the first index (Stephan: at least ¶0033; “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”).
Claim 18 (a medium claim) corresponds in scope to Claim 13 and is similarly rejected.
As to Claim 14, Stephan teaches the system of claim 12, wherein the electronic library comprises a computer-implemented catalog of words in a vector database (Stephan: at least ¶¶0036, 0044, 0048; “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180. The same embedding procedure may be applied for all chunks for any new files/documents and the embeddings may be stored in a vector database with references to the document they originate from”).
Claim 19 (a medium claim) corresponds in scope to Claim 14 and is similarly rejected.
As to Claim 16, Stephan teaches the system of claim 12, wherein the mixed index comprises one or more of: raw information from the file extracted by a smart parser (Stephan: at least ¶¶0025, 0033, 0048; “methods and systems herein may process the construction-specific document/data into smaller chunks using a custom parsing algorithm” and “the term “sparse index” and “dense index” may also be referred to as “sparse embedding” or “dense embedding”” and “may use a hybrid embedding that is a convex combination of the dense embedding and sparse embedding”; ¶0033 also discloses “the indexes may comprise sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups”; ¶0042 further discloses “the sparse index may be computed based on a count of occurrences of a term in the portion of the passage and an inverse document frequency (IDF) weight. The IDF weight may represent how common or rare a word is across the sections in the corpus”), a description field for images, a location field, the first index with main entities, and the second index with context-aware, semantically related terms.
Claim 20 (a medium claim) corresponds in scope to Claim 16 and is similarly rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2025/0053835 by Stephan et al. (“Stephan”) in view of US PGPUB 2017/0052950 by Danielyan et al. (“Danielyan”).
As to Claim 3, Stephan teaches the computer-implemented method of claim 1, wherein the component type of the component of the one or more components comprises a table (Stephan: at least ¶0025; “system is configured to use parsers for tables. In non-limiting examples, the system may use PDF Table Extraction and/or texts and layout extraction packages to extract tables and then parse the tables using the parser packages or using an LLM”) and wherein generating the one or more segments comprises: extracting row values using semantic tokenization (Stephan: at least ¶0040; “tables may be converted into a text by concatenating each cell value with the name of the corresponding cell and concatenating the values within a row and finally all the rows”).
Stephan does not explicitly disclose, but Danielyan discloses wherein generating the one or more segments comprises: interpreting headers of the table using the embedding model (Danielyan: at least ¶0004; “identifying, within the table, a header and a plurality of cells organized into rows and columns” and “analyzing the header to identify a plurality of ontology classes associated with respective table columns”; ¶¶0096, 0098 further disclose “various heuristic methods may be employed to detect and parse the table header based on certain visual separators, presence of fonts that are different from the rest of the table, etc” and “set of rules 1610 may identify an ontology class (“OWNER”) referenced by a certain lexeme in the table header, and associate the corresponding table column of tables 1620, 1630, 1640 with the identified ontology class”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Danielyan’s feature of generating the one or more segments comprises: interpreting headers of the table using the embedding model (Danielyan: at least ¶¶0004, 0096, 0098) with Stephan’s method.
The suggestion/motivation for doing so would have been to extract “information from structured documents (e.g., documents comprising tables, documents having multi-level structure comprising sections and sub-sections, etc.) comprising natural language text” (Danielyan: at least ¶¶0029-0030).
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2025/0053835 by Stephan et al. (“Stephan”) in view of US PGPUB 2018/0068183 by van Rotterdamet al. (“van Rotterdamet”).
As to Claim 7, Stephan teaches the computer-implemented method of claim 6, wherein the threshold of similarity to the one or more tokenized segments of data in the sparse index is based on a similarity between the one or more tokenized segments and the catalog of words in the vector database (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”).
Stephan does not explicitly disclose, but van Rotterdamet discloses said similarity is a cosine similarity (van Rotterdamet: at least ¶0049; “vector similarity values are calculated for pairs of vectors that include a reference document vector and an archived document vector. In one or more embodiments of the technology, a vector similarity value is calculated using the cosine similarity. Using cosine similarity, the measure for similarity may be an angle between the vectors”; claim 1 also discloses “document repository including an archived document and an archived document text vector for each portion of the archived document”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate van Rotterdamet’s feature of similarity that is a cosine similarity (van Rotterdamet: at least ¶0049, claim 1) with Stephan’s method.
The suggestion/motivation for doing so would have been to identify “documents that contain content similar to the content of a reference document” and perform similarity analysis “by extracting the texts, which may include extracting text bodies of documents and metadata sections of documents, by quantifying the extracted texts, for example, using natural language processing methods, and by subsequently analyzing the quantified texts for similarities” (van Rotterdamet: at least ¶¶0009-0010).
As to Claim 15, Stephan teaches the system of claim 14, wherein the threshold of similarity to the one or more segments of data in the first index is based on a similarity between the one or more segments and the catalog of words in the vector database (Stephan: at least ¶0033; “system may use one or more chunking techniques to split up text from one or more construction documents into semantically similar chunks that can then be embedded and use in search lookups” and “sparse index each may index or correspond to an element such as a token, a chunk, a word, a passage, or other data structures for efficient lookup” and “word embedding (a real-valued vector that encodes the meaning of the word such that the words that are closer in the vector space are expected to be similar in meaning)”; ¶¶0036, 0044 further discloses “the embeddings and text chunks may be stored in a 3rd party vector database (e.g., pinecone)” and “sparse and dense embeddings of all documents may be stored in a vector database along with metadata that references the original document and references to the chunks deriving from the document 180”).
Stephan does not explicitly disclose, but van Rotterdamet discloses said similarity is a cosine similarity (van Rotterdamet: at least ¶0049; “vector similarity values are calculated for pairs of vectors that include a reference document vector and an archived document vector. In one or more embodiments of the technology, a vector similarity value is calculated using the cosine similarity. Using cosine similarity, the measure for similarity may be an angle between the vectors”; claim 1 also discloses “document repository including an archived document and an archived document text vector for each portion of the archived document”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate van Rotterdamet’s feature of similarity that is a cosine similarity (van Rotterdamet: at least ¶0049, claim 1) with Stephan’s system.
The suggestion/motivation for doing so would have been to identify “documents that contain content similar to the content of a reference document” and perform similarity analysis “by extracting the texts, which may include extracting text bodies of documents and metadata sections of documents, by quantifying the extracted texts, for example, using natural language processing methods, and by subsequently analyzing the quantified texts for similarities” (van Rotterdamet: at least ¶¶0009-0010)
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270 3426. The examiner can normally be reached on Monday - Friday (10:30AM EST -6:30PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.W/Examiner, Art Unit 2168
17 September 2026 /CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
