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 .
Response to Amendment
The Amendment filed March 23, 2026, has been entered. Claims 1, 6, 8, 12 and 16 have been amended. Claims 1 to 20 are pending in the application.
Response to Arguments
Applicant’s arguments filed March 23, 2026, with respect to the rejection(s) of claim(s) 1-20 under 35 USC § 101 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
Applicant’s arguments with respect to the 35 U.S.C. 102 rejection of claim(s) 1-3, 7, 9-14, 16, and 18-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments with respect to the 35 U.S.C. 103 rejections of claims 4, 5, 6, 8, 15, and 17 have been fully considered but they are not persuasive.
In this case, applicant contends that the reference cited does not teach the entirety of their invention. Applicant contends that the metadata described in Arunachalam does not teach the headings for the chunks described in their invention. Reading on Arunachalam we can notice that they add multiple points of data in their metadata to identify the chunks of the documents, as described in: “Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like.” (Arunachalam [0055]). Wherein not only the title of the document identifies the chunk, but also the subtitle of the section that is chunked and the hierarchy of the chunk in the document are part of that identification embedding.
Applicant contends that the presence of metadata does not teach or suggest using a matched header derived from semantic vector similarity to retrieve the entire section of documentation. Arunachalam discloses a process that describes the operation of their invention executing the following steps of obtaining from semantic vector similarity matched vectors: “At operation 712, similar vectors are identified. For example, vector retrieving module 506 may use a similarity algorithm to identify a subset of vectors from vectors 408A by comparing the vector associated with the question to vectors 408A. In some instances, vectors in the subset of vectors may be ranked from the most similar to the least similar. ” (Arunachalam [0089]). Followed by obtaining the chunks associated with those identifiers in: “At operation 714, chunks are identified. For example, chunk retrieving module 508 may use the subset of vectors and dictionary 410A to identify the subset of chunks from chunks 404A that correspond to the subset of vectors. In some instances, chunks in the subset of chunks may be in the order of the ranked vectors in the subset of vectors. ” (Arunachalam [0090]). Where in the teachings of Arunachalam retrieve and submit the selected chunks to the LLM.
Applicant contends that the cited references does not solve the shortcomings of a sliding window chunking procedure. Arunachalam teaches: “Notably, the embodiments are directed to a technical solution that uses artificial intelligence and LLMs 210 to retrieve information included in data from various data sources. The embodiments involve LLMs 210 that include thousands of layers and billions of parameters that are trained to identify a next word in a natural language. The embodiments are further directed to a technical solution for standardizing, dividing, tagging, and embedding data into a format that aids in providing data to LLMs 210 and aids LLMs 210 to accurately retrieve information.” (Arunachalam [0099]). Where in the scope of Arunachalam disclosure is considered analogous to the scope of the invention.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
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.
Claim(s) 1 to 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mondlock (US 12020140 B1) hereinafter Mondlock in view of Arunachalam; Elavarasi et al. (US 20250211549 A1) hereinafter Arunachalam.
Regarding claim 1, Mondlock teaches:
A non-transitory computer-readable medium configured to store a computer program having logical instructions for enabling one or more processing devices to perform the steps of: in response to receiving a user query directed to subject information retrievable from documentation stored in a private database, using a section-based chunking procedure to obtain, from the private database, a relevant section of the documentation as context,
Shown in “FIG. 7B illustrates aspects of the computer-implemented method 700 involving splitting documents into text chunks, selecting relevant text chunks, and concurrently sending augmented text chunks to an LLM to extract relevant information. In some aspects, the computer-implemented method 700 may include at block 722 causing the plurality of documents to be split into a text chunks set. The plurality of documents may be split by the document/asset/expert module 122 or the LLM service 170. Splitting the plurality of documents may be performed at block 380A of the RAG pipeline 300.” (Mondlock Column 23 lines 10 to 20).
Where the private database is discussed in “The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline. The internal data store 140 may include a relational database (e.g., a PostgreSQL database), a non-relational datastore (e.g., a NoSQL database), a vector database (e.g., Pinecone), a web server, file server, and/or application server. In some aspects, the internal data store 140 may be located remotely from the server 110, such as in a public cloud environment. The internal data store 140 may store one or more data sources, such as a chat history 142, document collections 144, asset collections 146, and/or expert collections 148. Chat history 142 may include one or more records of the queries submitted by users and the responses output by server 110. Document collections 144 may include one or more sets of documents, such as web pages, PDFs, Word documents, text files, or any other suitable file containing text. Asset collections 146 may include one or more sets of databases, data sets, applications, models, knowledge graphs, or any other suitable sources of data. Expert collections 148 may include or more sets of identifying information for experts, corpora of experts' works, and/or experts' biographies for one or more subject matter experts. For example, any of the document collections 144, asset collections 146, or expert collections 148 may include data from a catalogue of documents, assets, or experts, such as a data set of assets and descriptions of the respective assets (e.g., applications or models for generating predictions or other data).” (Mondlock Column 4 line 65 to column 5 line 25).
and feeding the user query and the relevant section as context to a Large Language Model (LLM) as part of a prompt configured to cause the LLM to generate a response based on the retrieved section of the documentation.
“The computer-implemented method 600 may continue at block 622 by sending an augmented user query to an LLM to cause the LLM to obtain an answer from the LLM, such as an LLM service 170. The augmented user query may be sent by the LLM interface module 132. Sending the augmented user query may occur at block 388 of the RAG pipeline 300. The augmented user query may include the relevant information responses, the user query, and a prompt to cause the LLM to generate an answer.
“In some aspects, the LLM interface module 132 may transmit prompts to and receive answers from the LLM service 170. The LLM interface module 132 may transmit, for each relevant text chunk and relevant data chunk, a prompt that includes the user query and the relevant text chunk and/or relevant data chunk to the LLM service 170 and may receive relevant information from the relevant text chunk and/or relevant data chunk. The LLM interface module 132 may concurrently transmit a plurality of prompts to the LLM service 170. The LLM interface module 132 may transmit a prompt that includes the user query and each relevant information and may receive an answer. ” (Mondlock Column 9 line 20 to 31).
Mondlock does not teach, but Arunachalam teaches:
wherein the section-based chunking procedure obtains the relevant section based on a section header associated with semantically closest embedded content vectors stored in the private database,
“Systems, methods, and computer program products for using a generative artificial intelligence system to generate answers or summaries is provided. During the ingestion stage, the system receives documents and transcripts that include data associated with a theme. The data is converted into a common format and is divided into chunks. The chunks are associated with metadata tags that include chunk and data information. From the chunks, the system generates embedding vectors. During the inference stage, the system receives an information request. If the information request is a question, the system generates a vector from the question, and uses a similarity search to identify similar vectors. From the similar vectors, the system identifies chunks. If the information request includes a summary request, the system uses the metadata tags to identify chunks with summary information. The system generates an answer or a summary from the identified chunks.” (Arunachalam [Abstract]).
“Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like. ” (Arunachalam [0055]).
and wherein the section-based chunking procedure returns content associated with the section header as a complete section of the documentation rather than an arbitrary sliding-window portion of the documentation;
“If information request router 504 determines that the information request is a request for a summary, information request router 504 passes the information request to chunk retrieving module 510. Chunk retrieving module 510 may parse the metadata tags in dictionary 410A associated with project data 202A to determine tags that indicate that the corresponding chunk may include information that contributes to the summary. Once chunk retrieving module 510 identifies a subset of chunks from chunks 404A that may contribute to the summary, chunk retrieving module 510 may forward the chunks to LLM 110C. LLM 110C may receive and summarize the subset of chunks into a summary. In some instances, LLM 110C may summarize the subset of chunks over several iterations to refine the summary. For example, LLM 110C may receive a first chunk in the subset of chunks to generate a summary. Next, LLM 110C may receive a second chunk and a summary generated from the first chunk to generate a summary. Next, LLM 110C may receive a third chunk and the summary generated using the first and second chunks. The process may continue until LLM 110C uses all chunks in the subset of chunks or until LLM 110C determines that the content of the summary is no longer being modified.” (Arunachalam [0071]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “The generative AI system may be particularly useful in summarizing projects and generating answers to questions associated with projects. Projects, such as software projects, may involve various stages of development, including a planning stage, a development stage, a testing and quality assurance stage, and a release stage. Each of the various stages may generate various documents, transcripts, and the like. Further, as the project evolves, the documentation may also evolve and change. Accordingly, it may be difficult for a user to obtain project documentation, project requirements, various test cases, issues encountered during the projects, and the like, because this information may be scattered among multiple data sources. The generative AI system may ingest the various documentation and store the documentation as chunks tagged with metadata tags and as embedding vectors. Once ingested, the generative AI may receive information requests that may be question/answer requests or summary requests, and use various LLM models to identify chunks and/or vectors relevant to the requests, and use the relevant chunks or vectors to generate responses, such as summaries of the projects or answers to the questions in the requests.” (Arunachalam [0019]).
Regarding Claim 2, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein the section-based chunking procedure uses Retrieval-Augmented Generation (RAG) to parse the user query and retrieve the relevant section. In the following sections:
“FIG. 3B illustrates an aspect of the RAG pipeline 300 involving receiving and processing a user query. In some aspects, the RAG pipeline 300 may include at block 320 receiving a user query. The user query may be received by the input/output module 120 or any other suitable program. The user query may be received from the user device 180 or from a generative AI pipeline, such as RAG pipeline 300. User queries may be distributed among a plurality of servers 110 by the load balancer 190. The user query may comprise a question or a request. The user query may comprise a selection or deselection of one or more document collections, expert collections, or asset collections. The user query may comprise a selection of whether to provide relevant information to the LLM to assist in answering the query (i.e., use RAG) or submit the query without providing relevant information (i.e., do not use RAG).” (Mondlock Column 11 lines 23 to 38).
“FIG. 3E illustrates an aspect of the RAG pipeline 300 involving splitting documents or assets into text or data chunks and determining the most relevant text or data chunks. In some aspects, the RAG pipeline 300 may include at block 380A splitting each selected document into a plurality of text chunks and/or splitting each selected asset into a plurality of data chunks at block 380B. The selected documents and/or selected assets may be split by the document/asset/expert module 122 or any other suitable program.” (Mondlock Column 15 line 63 to column 16 line 4).
Regarding Claim 3, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein the section-based chunking procedure uses an inherent structure of the documentation to select, for the relevant section, one or more of subsections, paragraphs, bullet point lists, and tables.
“In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
Regarding claim 4, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein, before receiving the user query, the logical instructions further enable the one or more processing devices to perform a data preparation procedure to separate the documentation into sections,
“In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
Mondlock does not teach: each section including content under a respective section header. On the other hand, Arunachalam teaches: “More specifically, during an ingestion stage, a generative AI system may receive data from various sources. The data may correspond to a project and may be included in documents, transcripts, and the like. The generative AI system may convert the data into a uniform format and may also generate an identifier, such as a project identifier, for the data. Next, the generative AI system may divide the data in the uniform format into chunks having a predefined length. The generative AI system may also associate metadata tags with the chunks. There may be one metadata tag for one chunk in some embodiments. The metadata tag may include the identifier, the title of the chunk, the hierarchy of the chunk compared to other chunks, the data source (e.g., the document or transcript from where the chunk came from), and the like. From the chunks, an embedding large language model (LLM) may generate embedding vectors (or simply vectors). The vectors may include numeric embeddings that represent information in the chunks. The generative AI system may generate a dictionary for the data, where the dictionary includes or points to an identifier, chunks, metadata tags, and vectors associated with the data. The generative AI system may store the dictionary, including the identifier, chunks, metadata tags, and vectors in a vector storage, or a combination of various storage devices.” (Arunachalam [0015]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “If the request for information is a request for a summary, the generative AI system may use the identifier to identify the dictionary. From the dictionary, the generative AI system may use the metadata tags to identify a subset of chunks that may include information that may be used to generate the summary. Next, the generative AI system may use the subset of chunks to generate a summary. Notably, the generative AI system may refine the summary using the subset of chunks or retrieving additional chunks from the vectors.” (Arunachalam [0018]).
Regarding claim 5, the rejection of claim 4 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 4, wherein the data preparation procedure further includes dividing the content of each section into one or more of paragraphs, table entries, and subsections.
“In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
Regarding claim 6, the rejection of claim 4 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 4, wherein the data preparation procedure further includes embedding a content value of each paragraph or table entry within a section as a vector and storing the vector together with metadata including (i) a header identifying the section,
“Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like. ” (Arunachalam [0055]).
“At operation 606, vectors are generated. For example, an embedding LLM in LLMs 110 may generate vectors 408A from chunks 404A. Vectors 408A may include embeddings in the embedding space that correspond to the data stored in chunks 404A. There may be one chunk in chunks 404A for one vector in vectors 408A.” (Arunachalam [0080]).
“In some instances, data processing engine 114 may assign metadata tags to chunks. Typically there may be one metadata tag for each chunk. The metadata tag may include a project identifier, a title of the document, a subtitle of the document, a hierarchy of the chunk as compared to other chunks in the document or in the section of the document, a hierarchy of the chunk in the project, etc. ” (Arunachalam [0038]).
(ii) a content type identifying paragraph or table entry,
“As discussed above, data may include text, images, tables, audio and video files, etc., that may be collected from multiple data sources. Data sources may include documents, transcripts, audio and video recordings from various meetings, handwritten notes, source code, and the like. …” (Arunachalam [0027]).
“Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like. ” (Arunachalam [0055]).
and (iii) a table path identifying a stored table representation, in the private database to enable the documentation to be searched by section.
“In some embodiments, generative AI system 108 may generate a dictionary 410A. Dictionary 410A may include or be associated with a project identifier, document chunks 404A, metadata tags 406A, and vectors 408A. Alternatively dictionary 410A may include pointers to locations in data storage 120 that stores chunks 404A, metadata tags 406A, and vectors 408A. In this way, dictionary 410 may be used to identify locations of one or more document chunks 404A, metadata tags 406A, and vectors 408A associated with project data 202A. ” (Arunachalam [0057]).
“Generative AI system 108 may also include vector storage 412. Vector storage 412 may be data storage 120 discussed in FIG. 1. Vector storage 412 may store a project identifier, document chunks 404A, metadata tags 406A, and vectors 408A associated with project data 202A. ” (Arunachalam [0058]).
“Based on the similarity search, vector retrieving module 506 may retrieve the top K vectors from vectors 408A. Vector retrieving module 506 may rank the top K vectors according to similarity from the most similar vector to the least similar vector. Next, vector retrieving module 506 may pass the ranked top K vectors to a chunk retrieving module 508. The chunk retrieving module 508 may convert the ranked top K vectors into chunks. Alternatively, chunk retrieving module 508 may use dictionary 410A to access the subset of chunks from chunks 404A that correspond to the ranked top K vectors. In some embodiments, the subset of chunks may be in the same order as the ranked top K vectors. ” (Arunachalam [0067]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include information about the header, identification and location of the paragraphs and tables in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “… Additionally, the chunks may be divided according to one or more rules, such as including complete words, sentences, and paragraphs in one chunk, keeping data from one or more tables within one chunk, not dividing images between chunks, and the like. Data processing engine 114 may recursively generate chunks by dividing the available data from each document 204A or transcript 206A in half, until data processing engine 114 generates chunks that are less than a predefined chunk size.” (Arunachalam [0054]).
Regarding Claim 7, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein the logical instructions further enable the one or more processing devices to embed the user query as a query vector, wherein obtaining the relevant section of the documentation as context includes searching the private database for vectors semantically closest to the query vector. In the following sections:
“In some aspects, the document/asset/expert module 122 may include instructions for generating embeddings from each text chunk and/or data chunk. The embeddings represent the text chunks and data chunks as multi-dimensional (e.g., 768 or 1,536 dimension) vectors of numerical values. The document/asset/expert module 122 may use Word2Vec, Bidirectional Encoder Representations from Transformers (BERT), or other suitable algorithms to generate the embeddings. Alternatively, the document/asset/expert module 122 may transmit the text chunks and/or data chunks, via the LLM interface module 132, to the LLM service 170 (e.g., using the text-embedding-ada-002 model) and receive embeddings from the LLM service 170. The document/asset/expert module 122 may save the embeddings into embeddings 168 in the external data sources 160. The embeddings 168 may comprise a vector database, such as ChromaDB, Pinecone, or Milvus.” (Mondlock Column 7 lines 19 to 35).
“In some aspects, the relevant information identification module 130 may include instructions for identifying relevant text chunks and/or data chunks from the relevant documents and/or relevant assets. The relevant information identification module 130 may use a semantic search to compare the embedding of the user query to embeddings of the text chunks and/or data chunks to identify relevant text chunks and/or relevant data chunks” (Mondlock Column 9 lines 7 to 14).
“The computer-implemented method 600 may continue at block 614 by causing chunk similarity scores to be calculated. The chunk similarity scores may be calculated by the relevant information identification module 130 or the LLM service 170. Chunk similarity scores may be calculated at blocks 382A and/or 384A of the RAG pipeline 300. Chunk similarity scores may indicate semantic similarity of the user query to each text chunk of the plurality of documents. The chunk similarity scores may be calculated using various techniques, such as cosine similarity between the vectors representing the chunks.” (Mondlock Column 20 lines 5 to 12).
Regarding claim 8, the rejection of claim 7 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 7, wherein obtaining the relevant section further includes a) detecting a header of the vectors semantically closest to the query vector and
“In some aspects, the relevant information identification module 130 may include instructions for identifying relevant text chunks and/or data chunks from the relevant documents and/or relevant assets. The relevant information identification module 130 may use a semantic search to compare the embedding of the user query to embeddings of the text chunks and/or data chunks to identify relevant text chunks and/or relevant data chunks” (Mondlock Column 9 lines 7 to 14).
“In some aspects, the RAG pipeline 300 may include at block 384A identifying the top relevant text chunks and/or identifying the top relevant data chunks at block 384B. The top relevant text chunks and/or data chunks may be identified by the relevant information identification module 130 or any other suitable program. The top relevant text and data chunks may be identified by a semantic search. The semantic search may comprise performing a KNN search of the user query embedding and text chunk and/or data chunk embeddings.” (Mondlock Column 16 lines 14 to 23).
“In some aspects, the RAG pipeline 300 may include at block 366B performing a semantic search of the asset metadata from the one or more asset collections selected at block 338. The semantic search may be performed by the relevant information identification module 130 or any other suitable program. The semantic search may comprise performing a KNN search of the user query embedding and asset metadata embeddings. The asset metadata embeddings may be stored in embeddings 168. The semantic search may select one or more assets whose metadata have the highest semantic similarity to the user query.” (Mondlock Column 15 lines 1 to 13).
b) retrieving from the private database, all paragraphs and table entries having the matched header to reconstruct the entire section of the documentation for use as the context supplied to the LLM.
“If information request router 504 determines that the information request is a request for a summary, information request router 504 passes the information request to chunk retrieving module 510. Chunk retrieving module 510 may parse the metadata tags in dictionary 410A associated with project data 202A to determine tags that indicate that the corresponding chunk may include information that contributes to the summary. Once chunk retrieving module 510 identifies a subset of chunks from chunks 404A that may contribute to the summary, chunk retrieving module 510 may forward the chunks to LLM 110C. LLM 110C may receive and summarize the subset of chunks into a summary. In some instances, LLM 110C may summarize the subset of chunks over several iterations to refine the summary. For example, LLM 110C may receive a first chunk in the subset of chunks to generate a summary. Next, LLM 110C may receive a second chunk and a summary generated from the first chunk to generate a summary. Next, LLM 110C may receive a third chunk and the summary generated using the first and second chunks. The process may continue until LLM 110C uses all chunks in the subset of chunks or until LLM 110C determines that the content of the summary is no longer being modified. ” (Arunachalam [0071]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk and allow the system to retrieve the paragraph sections related to the header to feed them into an LLM. The motivation to include the respective header of the text chunk to the text chunk embedding, locate the data related to the chunk and feed them into an LLM is discussed by Arunachalam and can be found in “If the request for information is a request for a summary, the generative AI system may use the identifier to identify the dictionary. From the dictionary, the generative AI system may use the metadata tags to identify a subset of chunks that may include information that may be used to generate the summary. Next, the generative AI system may use the subset of chunks to generate a summary. Notably, the generative AI system may refine the summary using the subset of chunks or retrieving additional chunks from the vectors.” (Arunachalam [0018]).
Regarding Claim 9, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein the section-based chunking procedure obtains the relevant section of the documentation in a manner unrelated to a sliding window procedure.
“In some aspects, the RAG pipeline 300 may include at block 384A identifying the top relevant text chunks and/or identifying the top relevant data chunks at block 384B. The top relevant text chunks and/or data chunks may be identified by the relevant information identification module 130 or any other suitable program. The top relevant text and data chunks may be identified by a semantic search. The semantic search may comprise performing a KNN search of the user query embedding and text chunk and/or data chunk embeddings.” (Mondlock Column 16 lines 14 to 23).
Regarding Claim 10, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein a size of the user query and relevant section is configured to fall within an input token limit of the LLM.
“In some aspects, the query module 128 may include instructions for generating an augmented user query from the rephrased user query. The query module 128 may supplement the rephrased user query with information obtained (via the document/asset/expert module 122 and the relevant information identification module 130) from document collections 144, document collections 162, asset collections 146, asset collections 164, and/or other suitable sources to generate a prompt. For example, a rephrased user query may ask a question regarding Acme Corp.'s most recent earnings report. The query module 128 may append the contents of Acme Corp.'s earnings report when generating the augmented user query. The query module 128 may summarize an augmented user query in order to satisfy a maximum word or token limit of the LLM service 170. For example, the query module 128 may implement map reduce functionality to split Acme Corp.'s earnings report document into a plurality of text chunks and summarize each text chunk to generate a summarized output text suitable for submission to the LLM service 170.” (Mondlock Column 8 lines 19 to 38).
Regarding claim 11, the rejection of claim 1 is incorporated, furthermore Mondlock teaches:
The non-transitory computer-readable medium of claim 1, wherein the private database is a vector store.
“The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline. The internal data store 140 may include a relational database (e.g., a PostgreSQL database), a non-relational datastore (e.g., a NoSQL database), a vector database (e.g., Pinecone), a web server, file server, and/or application server.” (Mondlock Column 4 line 65 to column 5 line 4).
“In some aspects, the computer-implemented method 700 may include at block 726 saving the text chunks set and text embeddings into a data store. The text chunks set and text embeddings may be saved by the document/asset/expert module 122. The text chunks set and text embeddings may be saved at block 382A of the RAG pipeline 300. The text chunks set and text embeddings may be saved into internal data store 140.” (Mondlock Column 23 lines 28 to 35).
Regarding claim 12, Mondlock teaches:
A method comprising the steps of: in response to receiving a user query directed to subject information retrievable from documentation stored in a private database, using a section-based chunking procedure to obtain, from the private database, a relevant section of the documentation as context,
“FIG. 7B illustrates aspects of the computer-implemented method 700 involving splitting documents into text chunks, selecting relevant text chunks, and concurrently sending augmented text chunks to an LLM to extract relevant information. In some aspects, the computer-implemented method 700 may include at block 722 causing the plurality of documents to be split into a text chunks set. The plurality of documents may be split by the document/asset/expert module 122 or the LLM service 170. Splitting the plurality of documents may be performed at block 380A of the RAG pipeline 300.” (Mondlock Column 23 lines 10 to 20).
“The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline.” (Mondlock Column 4 lines 65 to 67).
and feeding the user query and the relevant section as context to a Large Language Model (LLM) as part of a prompt configured to cause the LLM to generate a response based on the retrieved section of the documentation.
“The computer-implemented method 600 may continue at block 622 by sending an augmented user query to an LLM to cause the LLM to obtain an answer from the LLM, such as an LLM service 170. The augmented user query may be sent by the LLM interface module 132. Sending the augmented user query may occur at block 388 of the RAG pipeline 300. The augmented user query may include the relevant information responses, the user query, and a prompt to cause the LLM to generate an answer.” (Mondlock Column 20 line 13 to 21).
“In some aspects, the LLM interface module 132 may transmit prompts to and receive answers from the LLM service 170. The LLM interface module 132 may transmit, for each relevant text chunk and relevant data chunk, a prompt that includes the user query and the relevant text chunk and/or relevant data chunk to the LLM service 170 and may receive relevant information from the relevant text chunk and/or relevant data chunk. The LLM interface module 132 may concurrently transmit a plurality of prompts to the LLM service 170. The LLM interface module 132 may transmit a prompt that includes the user query and each relevant information and may receive an answer. ” (Mondlock Column 9 line 20 to 31).
Mondlock does not teach, but Arunachalam teaches:
wherein the section-based chunking procedure obtains the relevant section based on a section header associated with semantically closest embedded content vectors stored in the private database,
“Systems, methods, and computer program products for using a generative artificial intelligence system to generate answers or summaries is provided. During the ingestion stage, the system receives documents and transcripts that include data associated with a theme. The data is converted into a common format and is divided into chunks. The chunks are associated with metadata tags that include chunk and data information. From the chunks, the system generates embedding vectors. During the inference stage, the system receives an information request. If the information request is a question, the system generates a vector from the question, and uses a similarity search to identify similar vectors. From the similar vectors, the system identifies chunks. If the information request includes a summary request, the system uses the metadata tags to identify chunks with summary information. The system generates an answer or a summary from the identified chunks.” (Arunachalam [Abstract]).
“Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like. ” (Arunachalam [0055]).
and wherein the section-based chunking procedure returns content associated with the section header as a complete section of the documentation rather than an arbitrary sliding-window portion of the documentation;
“If information request router 504 determines that the information request is a request for a summary, information request router 504 passes the information request to chunk retrieving module 510. Chunk retrieving module 510 may parse the metadata tags in dictionary 410A associated with project data 202A to determine tags that indicate that the corresponding chunk may include information that contributes to the summary. Once chunk retrieving module 510 identifies a subset of chunks from chunks 404A that may contribute to the summary, chunk retrieving module 510 may forward the chunks to LLM 110C. LLM 110C may receive and summarize the subset of chunks into a summary. In some instances, LLM 110C may summarize the subset of chunks over several iterations to refine the summary. For example, LLM 110C may receive a first chunk in the subset of chunks to generate a summary. Next, LLM 110C may receive a second chunk and a summary generated from the first chunk to generate a summary. Next, LLM 110C may receive a third chunk and the summary generated using the first and second chunks. The process may continue until LLM 110C uses all chunks in the subset of chunks or until LLM 110C determines that the content of the summary is no longer being modified.” (Arunachalam [0071]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “The generative AI system may be particularly useful in summarizing projects and generating answers to questions associated with projects. Projects, such as software projects, may involve various stages of development, including a planning stage, a development stage, a testing and quality assurance stage, and a release stage. Each of the various stages may generate various documents, transcripts, and the like. Further, as the project evolves, the documentation may also evolve and change. Accordingly, it may be difficult for a user to obtain project documentation, project requirements, various test cases, issues encountered during the projects, and the like, because this information may be scattered among multiple data sources. The generative AI system may ingest the various documentation and store the documentation as chunks tagged with metadata tags and as embedding vectors. Once ingested, the generative AI may receive information requests that may be question/answer requests or summary requests, and use various LLM models to identify chunks and/or vectors relevant to the requests, and use the relevant chunks or vectors to generate responses, such as summaries of the projects or answers to the questions in the requests.” (Arunachalam [0019]).
Regarding claim 13, the rejection of claim 12 is incorporated, furthermore Mondlock teaches:
The method of claim 12, wherein the section-based chunking procedure uses Retrieval-Augmented Generation (RAG) to parse the user query and retrieve the relevant section.
“FIG. 3B illustrates an aspect of the RAG pipeline 300 involving receiving and processing a user query. In some aspects, the RAG pipeline 300 may include at block 320 receiving a user query.” (Mondlock Column 11 lines 23 to 26).
“FIG. 3E illustrates an aspect of the RAG pipeline 300 involving splitting documents or assets into text or data chunks and determining the most relevant text or data chunks.” (Mondlock Column 15 lines 63 to 66).
Regarding claim 14, the rejection of claim 12 is incorporated, furthermore Mondlock teaches:
The method of claim 12, wherein the section-based chunking procedure uses an inherent structure of the documentation including, for the relevant section, one or more subsections, paragraphs, bullet point lists, and tables.
“In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
Regarding claim 15, the rejection of claim 12 is incorporated, furthermore Mondlock teaches:
dividing the content of each section into one or more of paragraphs, table entries, and subsections;
“In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
and embedding a content value of each section as vectors in the private database to enable the documentation to be searched by section.
“In some aspects, the document/asset/expert module 122 may include instructions for generating embeddings from each text chunk and/or data chunk. The embeddings represent the text chunks and data chunks as multi-dimensional (e.g., 768 or 1,536 dimension) vectors of numerical values. The document/asset/expert module 122 may use Word2Vec, Bidirectional Encoder Representations from Transformers (BERT), or other suitable algorithms to generate the embeddings. Alternatively, the document/asset/expert module 122 may transmit the text chunks and/or data chunks, via the LLM interface module 132, to the LLM service 170 (e.g., using the text-embedding-ada-002 model) and receive embeddings from the LLM service 170. The document/asset/expert module 122 may save the embeddings into embeddings 168 in the external data sources 160. The embeddings 168 may comprise a vector database, such as ChromaDB, Pinecone, or Milvus.” (Mondlock Column 7 lines 19 to 35).
“In some aspects, the relevant information identification module 130 may include instructions for identifying relevant text chunks and/or data chunks from the relevant documents and/or relevant assets. The relevant information identification module 130 may use a semantic search to compare the embedding of the user query to embeddings of the text chunks and/or data chunks to identify relevant text chunks and/or relevant data chunks” (Mondlock Column 9 lines 7 to 14).
Mondlock does not teach: The method of claim 12, wherein, before receiving the user query, the process further comprises the steps of: performing a data preparation procedure to separate the documentation into sections, each section including content under a respective section header;
In Mondlock there is no specific mention that the header of the text chunk is embedded with the text chunk as a searchable tag of the text chunk.
On the other hand, Arunachalam define sections of metadata that could be embedded in a vector with a text chunk that is being prepared for an LLM in here: “The generative AI system may also associate metadata tags with the chunks. There may be one metadata tag for one chunk in some embodiments. The metadata tag may include the identifier, the title of the chunk, the hierarchy of the chunk compared to other chunks, the data source (e.g., the document or transcript from where the chunk came from), and the like.” (Arunachalam [0015] lines 9 to 15).
Such metadata portions in the embeddings of the text chunks could modify the data preparation procedure disclosed by Mondlock in: “In some aspects, the document/asset/expert module 122 may include instructions for splitting documents or assets into chunks and generating embeddings of those chunks. The document/asset/expert module 122 may split each document of document collections 144 and document collections 162 into a plurality of text chunks and split each asset of asset collections 146 and asset collections 164 into a plurality of text chunks and/or data chunks. The text chunks may be paragraph-sized, sentence-sized, fixed-sized (e.g., 50 words) or any other appropriate size. The document/asset/expert module 122 may use a tool, such as Natural Language Toolkit (NLTK) or Sentence Splitter, to perform the splitting. In some aspects, document/asset/expert module 122 may transmit the documents and/or assets, via the LLM interface module 132, to the LLM service 170 and receive text chunks and/or asset chunks from the LLM service 170.” (Mondlock Column 7 lines 4 to 18).
Similar to claim 4 and 8, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “If the request for information is a request for a summary, the generative AI system may use the identifier to identify the dictionary. From the dictionary, the generative AI system may use the metadata tags to identify a subset of chunks that may include information that may be used to generate the summary. Next, the generative AI system may use the subset of chunks to generate a summary. Notably, the generative AI system may refine the summary using the subset of chunks or retrieving additional chunks from the vectors.” (Arunachalam [0018]).
Regarding claim 16, Mondlock teaches:
A system comprising: a processing device; and memory configured to store computer logic having instructions enabling the processing device to perform the steps of: in response to receiving a user query directed to subject information retrievable from documentation stored in a private database, using a section-based chunking procedure to obtain, from the private database, a relevant section of the documentation as context,
“FIG. 7B illustrates aspects of the computer-implemented method 700 involving splitting documents into text chunks, selecting relevant text chunks, and concurrently sending augmented text chunks to an LLM to extract relevant information. In some aspects, the computer-implemented method 700 may include at block 722 causing the plurality of documents to be split into a text chunks set. The plurality of documents may be split by the document/asset/expert module 122 or the LLM service 170. Splitting the plurality of documents may be performed at block 380A of the RAG pipeline 300.” (Mondlock Column 23 lines 10 to 20).
“The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline.” (Mondlock Column 4 lines 65 to 67).
and feeding the user query and the relevant section as context to a Large Language Model (LLM) as part of a prompt configured to cause the LLM to generate a response based on the retrieved section of the documentation.
“The computer-implemented method 600 may continue at block 622 by sending an augmented user query to an LLM to cause the LLM to obtain an answer from the LLM, such as an LLM service 170. The augmented user query may be sent by the LLM interface module 132. Sending the augmented user query may occur at block 388 of the RAG pipeline 300. The augmented user query may include the relevant information responses, the user query, and a prompt to cause the LLM to generate an answer.” (Mondlock Column 20 line 13 to 21).
“In some aspects, the LLM interface module 132 may transmit prompts to and receive answers from the LLM service 170. The LLM interface module 132 may transmit, for each relevant text chunk and relevant data chunk, a prompt that includes the user query and the relevant text chunk and/or relevant data chunk to the LLM service 170 and may receive relevant information from the relevant text chunk and/or relevant data chunk. The LLM interface module 132 may concurrently transmit a plurality of prompts to the LLM service 170. The LLM interface module 132 may transmit a prompt that includes the user query and each relevant information and may receive an answer. ” (Mondlock Column 9 line 20 to 31).
Mondlock does not teach, but Arunachalam teaches:
wherein the section-based chunking procedure obtains the relevant section based on a section header associated with semantically closest embedded content vectors stored in the private database,
“Systems, methods, and computer program products for using a generative artificial intelligence system to generate answers or summaries is provided. During the ingestion stage, the system receives documents and transcripts that include data associated with a theme. The data is converted into a common format and is divided into chunks. The chunks are associated with metadata tags that include chunk and data information. From the chunks, the system generates embedding vectors. During the inference stage, the system receives an information request. If the information request is a question, the system generates a vector from the question, and uses a similarity search to identify similar vectors. From the similar vectors, the system identifies chunks. If the information request includes a summary request, the system uses the metadata tags to identify chunks with summary information. The system generates an answer or a summary from the identified chunks.” (Arunachalam [Abstract]).
“Data processing engine 114 may also generate a metadata tags 406A, and associate each metadata tag in metadata tags 406A with each chunk in chunks 404A. Each metadata tag may include a project identifier associated with project data 202A. The metadata tag may also include a chunk identifier, a size of the chunk, a title of document 204A or transcript 206A that is included in the chunk, a subtitle corresponding to a section of document 204A or transcript 206A, a hierarchy of the chunk compared to other chunks, and the like. ” (Arunachalam [0055]).
and wherein the section-based chunking procedure returns content associated with the section header as a complete section of the documentation rather than an arbitrary sliding-window portion of the documentation;
“If information request router 504 determines that the information request is a request for a summary, information request router 504 passes the information request to chunk retrieving module 510. Chunk retrieving module 510 may parse the metadata tags in dictionary 410A associated with project data 202A to determine tags that indicate that the corresponding chunk may include information that contributes to the summary. Once chunk retrieving module 510 identifies a subset of chunks from chunks 404A that may contribute to the summary, chunk retrieving module 510 may forward the chunks to LLM 110C. LLM 110C may receive and summarize the subset of chunks into a summary. In some instances, LLM 110C may summarize the subset of chunks over several iterations to refine the summary. For example, LLM 110C may receive a first chunk in the subset of chunks to generate a summary. Next, LLM 110C may receive a second chunk and a summary generated from the first chunk to generate a summary. Next, LLM 110C may receive a third chunk and the summary generated using the first and second chunks. The process may continue until LLM 110C uses all chunks in the subset of chunks or until LLM 110C determines that the content of the summary is no longer being modified.” (Arunachalam [0071]).
It would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embeddings of the text chunk. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “The generative AI system may be particularly useful in summarizing projects and generating answers to questions associated with projects. Projects, such as software projects, may involve various stages of development, including a planning stage, a development stage, a testing and quality assurance stage, and a release stage. Each of the various stages may generate various documents, transcripts, and the like. Further, as the project evolves, the documentation may also evolve and change. Accordingly, it may be difficult for a user to obtain project documentation, project requirements, various test cases, issues encountered during the projects, and the like, because this information may be scattered among multiple data sources. The generative AI system may ingest the various documentation and store the documentation as chunks tagged with metadata tags and as embedding vectors. Once ingested, the generative AI may receive information requests that may be question/answer requests or summary requests, and use various LLM models to identify chunks and/or vectors relevant to the requests, and use the relevant chunks or vectors to generate responses, such as summaries of the projects or answers to the questions in the requests.” (Arunachalam [0019]).
Regarding claim 17, the rejection of claim 16 is incorporated, furthermore Mondlock teaches:
The system of claim 16, wherein the instructions further enable the processing device to embed the user query as a query vector, wherein obtaining the relevant section of the documentation as context includes: searching the private database for vectors semantically closest to the query vector,
“In some aspects, the document/asset/expert module 122 may include instructions for generating embeddings from each text chunk and/or data chunk. The embeddings represent the text chunks and data chunks as multi-dimensional (e.g., 768 or 1,536 dimension) vectors of numerical values. The document/asset/expert module 122 may use Word2Vec, Bidirectional Encoder Representations from Transformers (BERT), or other suitable algorithms to generate the embeddings. Alternatively, the document/asset/expert module 122 may transmit the text chunks and/or data chunks, via the LLM interface module 132, to the LLM service 170 (e.g., using the text-embedding-ada-002 model) and receive embeddings from the LLM service 170. The document/asset/expert module 122 may save the embeddings into embeddings 168 in the external data sources 160. The embeddings 168 may comprise a vector database, such as ChromaDB, Pinecone, or Milvus.” (Mondlock Column 7 lines 19 to 35).
“In some aspects, the relevant information identification module 130 may include instructions for identifying relevant text chunks and/or data chunks from the relevant documents and/or relevant assets. The relevant information identification module 130 may use a semantic search to compare the embedding of the user query to embeddings of the text chunks and/or data chunks to identify relevant text chunks and/or relevant data chunks” (Mondlock Column 9 lines 7 to 14).
Mondlock does not explicitly teach: detecting a header of the vectors semantically closest to the query vector, and searching the private database for subsections having headers that match the header of the vectors semantically closest to the query vector. Since in Mondlock there is no specific mention of the header of the text chunk being embedded with the text chunk as a searchable tag of the text chunk or any metadata embedded in a chunk.
Regarding detecting a header of the vectors semantically closest to the query vector, Mondlock discloses the use of semantic search to compare the embeddings of a user query vector and the embeddings of a text chunk. “The computer-implemented method 600 may continue at block 614 by causing chunk similarity scores to be calculated. The chunk similarity scores may be calculated by the relevant information identification module 130 or the LLM service 170. Chunk similarity scores may be calculated at blocks 382A and/or 384A of the RAG pipeline 300. Chunk similarity scores may indicate semantic similarity of the user query to each text chunk of the plurality of documents. The chunk similarity scores may be calculated using various techniques, such as cosine similarity between the vectors representing the chunks.” (Mondlock Column 19 lines 45 to 55).
On the other hand, Arunachalam describe the inclusion of such information in the embeddings of a text chunk that is being prepared for an LLM: “The generative AI system may also associate metadata tags with the chunks. There may be one metadata tag for one chunk in some embodiments. The metadata tag may include the identifier, the title of the chunk, the hierarchy of the chunk compared to other chunks, the data source (e.g., the document or transcript from where the chunk came from), and the like.” (Arunachalam [0015] lines 9 to 15).
Regarding and searching the private database for subsections having headers that match the header of the vectors semantically closest to the query vector. Mondlock discloses the use of semantic search to search in the database compare the embeddings of a user query vector and the embeddings of a text chunk.
“The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline. The internal data store 140 may include a relational database (e.g., a PostgreSQL database), a non-relational datastore (e.g., a NoSQL database), a vector database (e.g., Pinecone), a web server, file server, and/or application server. In some aspects, the internal data store 140 may be located remotely from the server 110, such as in a public cloud environment. The internal data store 140 may store one or more data sources, such as a chat history 142, document collections 144, asset collections 146, and/or expert collections 148.” (Mondlock Column 4 line 65 to column 5 line 9).
“In some aspects, the relevant information identification module 130 may include instructions for identifying one or more documents, assets, and/or experts that are relevant to the user query. The relevant information identification module 130 may use a semantic search to identify the relevant documents, assets, and experts. The semantic search may include (1) generating an embedding of the user query; and (2) compare the user query embedding to the document and asset embeddings in embeddings 168 using clustering techniques, such as k-means clustering, to identify relevant documents and/or assets. Alternatively, the relevant information identification module 130 may transmit the query embedding, the document embeddings, and/or the data embeddings, via the LLM interface module 132, to the LLM service 170 and receive semantic search scores from the LLM service 170.” (Mondlock Column 8 lines 44 to 59).
“In some aspects, the relevant information identification module 130 may include instructions for identifying relevant text chunks and/or data chunks from the relevant documents and/or relevant assets. The relevant information identification module 130 may use a semantic search to compare the embedding of the user query to embeddings of the text chunks and/or data chunks to identify relevant text chunks and/or relevant data chunks. Alternatively, the relevant information identification module 130 may transmit the query embedding, the text chunk embeddings, and/or the data chunk embeddings, via the LLM interface module 132, to the LLM service 170 and receive semantic search scores from the LLM service 170.” (Mondlock Column 9 lines 7 to 19).
On the other hand, Arunachalam describe the inclusion of such information in the embeddings of a text chunk that is being prepared for an LLM: “The generative AI system may also associate metadata tags with the chunks. There may be one metadata tag for one chunk in some embodiments. The metadata tag may include the identifier, the title of the chunk, the hierarchy of the chunk compared to other chunks, the data source (e.g., the document or transcript from where the chunk came from), and the like.” (Arunachalam [0015] lines 9 to 15).
Similar to claim 4, 8 and 15, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mondlock to incorporate the teachings of Arunachalam to include the header of the text chunk in the embedding information and use it to compare the query vector to determine which text chunks are semantically closer. The motivation to include the respective header of the text chunk to the text chunk embedding is discussed by Arunachalam and can be found in “If the request for information is a request for a summary, the generative AI system may use the identifier to identify the dictionary. From the dictionary, the generative AI system may use the metadata tags to identify a subset of chunks that may include information that may be used to generate the summary. Next, the generative AI system may use the subset of chunks to generate a summary. Notably, the generative AI system may refine the summary using the subset of chunks or retrieving additional chunks from the vectors.” (Arunachalam [0018]).
Regarding claim 18, the rejection of claim 16 is incorporated, furthermore Mondlock teaches:
The system of claim 16, wherein the section-based chunking procedure obtains the relevant section of the documentation in a manner unrelated to a sliding window procedure.
“In some aspects, the RAG pipeline 300 may include at block 384A identifying the top relevant text chunks and/or identifying the top relevant data chunks at block 384B. The top relevant text chunks and/or data chunks may be identified by the relevant information identification module 130 or any other suitable program. The top relevant text and data chunks may be identified by a semantic search. The semantic search may comprise performing a KNN search of the user query embedding and text chunk and/or data chunk embeddings.” (Mondlock Column 16 lines 14 to 23).
Regarding claim 19, the rejection of claim 16 is incorporated, furthermore Mondlock teaches:
The system of claim 16, wherein a size of the user query and relevant section is configured to fall within an input token limit of the LLM.
“In some aspects, the query module 128 may include instructions for generating an augmented user query from the rephrased user query. The query module 128 may supplement the rephrased user query with information obtained (via the document/asset/expert module 122 and the relevant information identification module 130) from document collections 144, document collections 162, asset collections 146, asset collections 164, and/or other suitable sources to generate a prompt. For example, a rephrased user query may ask a question regarding Acme Corp.'s most recent earnings report. The query module 128 may append the contents of Acme Corp.'s earnings report when generating the augmented user query. The query module 128 may summarize an augmented user query in order to satisfy a maximum word or token limit of the LLM service 170. For example, the query module 128 may implement map reduce functionality to split Acme Corp.'s earnings report document into a plurality of text chunks and summarize each text chunk to generate a summarized output text suitable for submission to the LLM service 170.” (Mondlock Column 8 lines 19 to 38).
Regarding claim 20, the rejection of claim 16 is incorporated, furthermore Mondlock teaches:
The system of claim 16, wherein the private database is a vector store, and wherein the system includes one or more of a server and a retriever.
“The internal data store 140 may be owned or operated by the same organization that owns or operates the generative AI pipeline. The internal data store 140 may include a relational database (e.g., a PostgreSQL database), a non-relational datastore (e.g., a NoSQL database), a vector database (e.g., Pinecone), a web server, file server, and/or application server.” (Mondlock Column 8 lines 19 to 38).
“In some aspects, the computer-implemented method 700 may include at block 726 saving the text chunks set and text embeddings into a data store. The text chunks set and text embeddings may be saved by the document/asset/expert module 122. The text chunks set and text embeddings may be saved at block 382A of the RAG pipeline 300. The text chunks set and text embeddings may be saved into internal data store 140.” (Mondlock Column 4 line 65 to column 5 line 4).
“The server 110 may be an individual server, a group (e.g., cluster) of multiple servers, or another suitable type of computing device or system (e.g., a collection of computing resources). The server 110 may be located within the enterprise network of an organization that owns or operates the generative AI pipeline or hosted by a third-party provider.” (Mondlock Column 4 lines 31 to 36).
“In some aspects, if the intent is to query one or more document collections, then the RAG pipeline 300 may include at block 354A retrieving the one or more documents from the one or more selected document collections. The documents may be retrieved by the document/asset/expert module 122 or any other suitable program. The retrieved documents may be stored, short term or long term, in document collections 144.” (Mondlock Column 14 lines 1 to 8).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HECTOR J. CRESPO FEBLES whose telephone number is (571)272-4512. The examiner can normally be reached Mon - Fri 7:30 - 5:00.
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, Daniel Washburn can be reached at (571) 272-5551. 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.
/H.J.C./Examiner, Art Unit 2657
/DANIEL C WASHBURN/Supervisory Patent Examiner, Art Unit 2657
Prosecution Insights