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
Applicant’s Amendment, filed June 22, 2026, has been fully considered and entered. Accordingly, Claims 1-20 are pending in this application. Claim 11 has been cancelled. Claim 1, 14, and 20 are Independent Claims and have been amended.
In view of Applicant’s Amendment, the rejection of Claims 1-4, 6-10, and 12-20 under 35 U.S.C. 101 has been withdrawn.
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.
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.
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.
Claims 1-3, 14-16, and 20 are rejected under 35 U.S.C. 103 as unpatentable over GPTutorPro (“Elasticsearch for ML: Data Ingestion and Preprocessing”, https://gpttutorpro.com/elasticsearch-for-ml-data-ingestion-and-preprocessing/, January 31, 2024), and further in view of ThinkETL (“Overview of Taskflows in Informatica Cloud (IICS) – ThinkETL, https://thinketl.com/overview-of-taskflows-in-informatica-cloud-iics/, November 15, 2021).
Regarding Claim 1, GPTutorPro discloses a system comprising:
one or more processors (see GPTutorPro, Section 1, paragraph 2, where ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it [it is the position of the Examiner that a system suggests the use of one or more processors]) configured to:
receive a specification for processing target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch. An ingest node can have one or more ingest plugins installed, which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
receive the target data (see GPTutorPro, Section 1 paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it);
process the target data in accordance with the specification through a machine learning pre-processing sub-system and a search sub-system to generate processed target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
train or execute a machine learning model using the processed target data (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]); and
output the processed target data (see GPTutorPro, Section 1, paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it.).
GPTutorPro does not disclose wherein the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations in parallel using the specification. GPTutorPro in view of ThinkETL discloses the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]) in parallel using the specification (see ThinkETL, Section 2.9: Parallel Paths, where Parallel Paths step is used when you want a taskflow to run multiple items at the same time. For example, you can run three mapping tasks simultaneously. The taskflow runs all items in the Parallel Paths step and then moves to the next step; see also Section 4.1: Parallel Tasks, where Select the Parallel Tasks template if your major requirement is to run two or more data integration tasks in parallel. You start with a taskflow that contains a Start step, a Parallel Paths step, and an End step).
Both GPTutorPro and ThinkETL are directed to ETL pipeline software processing of data. Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with ThinkETL as it amounts to combining known software techniques from the same field or endeavor to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 2, GPTutorPro in view of ThinkETL discloses the system of Claim 1, wherein:
the machine learning pre-processing sub-system is configured to perform data pre-processing operations using the specification (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]); and
the search sub-system is configured to pre-process the target data using the specification, and generate a search index for the pre-processed target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]).
Regarding Claim 3, GPTutorPro in view of ThinkETL discloses the system of Claim 1, wherein:
the machine learning pre-processing sub-system is configured to execute one or more machine learning pre-processing operations using the specification (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]), and
the search sub-system is configured to execute one or more search operations different from the one or more machine learning pre-processing operations and using the specification (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding).
Regarding Claim 14, GPTutorPro discloses a method, comprising:
receiving, by the one or more processors, a specification for processing target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch. An ingest node can have one or more ingest plugins installed, which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
receiving, by the one or more processors, the target data (see GPTutorPro, Section 1 paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it);
processing, by the one or more processors, the target data in accordance with the specification through a machine learning pre-processing sub-system and a search sub-system to generate processed target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
training or executing a machine learning model using the processed target data (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]); and
outputting, by the one or more procesors, the processed target data (see GPTutorPro, Section 1, paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it.).
GPTutorPro does not disclose wherein the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations in parallel using the specification. GPTutorPro in view of ThinkETL discloses the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]) in parallel using the specification (see ThinkETL, Section 2.9: Parallel Paths, where Parallel Paths step is used when you want a taskflow to run multiple items at the same time. For example, you can run three mapping tasks simultaneously. The taskflow runs all items in the Parallel Paths step and then moves to the next step; see also Section 4.1: Parallel Tasks, where Select the Parallel Tasks template if your major requirement is to run two or more data integration tasks in parallel. You start with a taskflow that contains a Start step, a Parallel Paths step, and an End step).
Both GPTutorPro and ThinkETL are directed to ETL pipeline software processing of data. Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with ThinkETL as it amounts to combining known software techniques from the same field or endeavor to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 15, GPTutorPro in view of ThinkETL discloses the method of Claim 14, wherein the method further comprises:
when the target data is processed through the machine learning pre-processing sub-system, performing data pre-processing operations using the specification (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]); and
when the target data is processed through the search sub-system, pre-processing the target data using the specification and generating a search index for the pre-processed data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]).
Regarding Claim 16, GPTutorPro in view of ThinkETL discloses the method of Claim 15, wherein:
the machine learning pre-processing sub-system is configured to execute one or more machine learning pre-processing operations (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]), and
the search sub-system is configured to execute one or more search operations different from the one or more machine learning pre-processing operations using the specification (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding).
Regarding Claim 20, GPTutorPro discloses a one or more non-transitory computer-readable storage media storing instructions that operable when performed by one or more processors, to cause the one or more processors to perform operations comprising:
receiving a specification for processing target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch. An ingest node can have one or more ingest plugins installed, which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
receiving the target data (see GPTutorPro, Section 1 paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it);
processing the target data in accordance with the specification through a machine learning pre-processing sub-system and a search sub-system to generate processed target data (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]);
training or executing a machine learning model using the processed target data (see GPTutorPro, Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]); and
outputting the processed target data (see GPTutorPro, Section 1, paragraph 2, where Data ingestion is the process of collecting, importing, and processing data from various sources into a system that can store and analyze it.).
GPTutorPro does not disclose wherein the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations in parallel using the specification. GPTutorPro in view of ThinkETL discloses the machine learning pre-processing sub-system and the search sub-system are configured to receive the specification and execute different operations (see GPTutorPro, Section 2, paragraph 2, where an ingest node is a special type of node in an Elasticsearch cluster that can apply transformations to the data before indexing it into Elasticsearch [emphasis added by Examiner; it is the position of the Examiner that indexing is not patentably distinguishable from pre-processing input data for a search subsystem]. An ingest node can have one or more ingest plugins installed [emphasis added by Examiner; it is the position of the Examiner that one or more ingest plugins is not patentably distinguishable from executing different operations defined by a specification], which are modules that provide specific functionality for data ingestion, such as parsing, enriching, or geocoding. You can define a pipeline, which is a set of processors that specify the transformations to be applied by the ingest plugins; see also Section 1, paragraph 1, where Elasticsearch is a powerful and scalable search engine that can handle large volumes of data and perform complex queries. But did you know that Elasticsearch can also be used for machine learning purposes? In this blog, you will learn how to use Elasticsearch for data ingestion and preprocessing, two essential steps in any machine learning project [emphasis added by Examiner; it is the position of the Examiner that a user defined pipeline for processing data is not patentably distinguishable from a specification for processing target data]) in parallel using the specification (see ThinkETL, Section 2.9: Parallel Paths, where Parallel Paths step is used when you want a taskflow to run multiple items at the same time. For example, you can run three mapping tasks simultaneously. The taskflow runs all items in the Parallel Paths step and then moves to the next step; see also Section 4.1: Parallel Tasks, where Select the Parallel Tasks template if your major requirement is to run two or more data integration tasks in parallel. You start with a taskflow that contains a Start step, a Parallel Paths step, and an End step).
Both GPTutorPro and ThinkETL are directed to ETL pipeline software processing of data. Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with ThinkETL as it amounts to combining known software techniques from the same field or endeavor to yield predictable results (see MPEP 2143(I)(A)).
Claims 4-10, 13, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over GPTutorPro and ThinkETL as applied to Claims 1-3, 14-16, and 20 above, and further in view of Suhm (“Exploring vector databases: how to get the best of lexical and AI-powered search with Elastic’s vector database”, https://www.elastic.co/search-labs/blog/lexical-ai-powered-search-elastic-vector-database, Bernhard Suhm, July 3, 2023).
Regarding Claim 4, GPTutorPro in view of ThinkETL discloses the system of Claim 3, wherein:
GPTutorPro does not disclose:
the one or more machine learning pre-processing operations comprise one or more operations for performing a text vectorization of the target data, wherein the target data is vectorized in accordance with the specification; and
the one or more search operations comprise one or more operations for generating one or more tokens of text from the target data, and generating a search index for the one or more tokens of text, wherein the one or more tokens of text are generated in accordance with the specification.
Suhm discloses:
the one or more machine learning pre-processing operations comprise one or more operations for performing a text vectorization of the target data, wherein the target data is vectorized in accordance with the specification (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market: fully performant and scalable vector database functionality, including storing embeddings and efficiently searching for nearest neighbor), and
the one or more search operations comprise one or more operations for generating one or more tokens of text from the target data, and generating a search index for the one or more tokens of text, wherein the one or more tokens of text are generated in accordance with the specification (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market … a proprietary sparse retrieval model that implements semantic search out of the box; industry-leading relevance of all types – keyword, semantic, and vector; see also paragraph 20, where lexical search that made Elasticsearch popular (BM25) is an example of a sparse retrieval method. It uses a bag-of-words representation for text and achieves high relevance by modifying the basic relevance scoring method known as TF-IDF (term frequency, inverse document frequency) for factors like length of the document).
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 5, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 4, wherein the one or more processors are further configured to:
GPTutorPro does not explicitly disclose receive a search query on the target data and generate search results responsive to the search query using the generated search index. Suhm discloses receive a search query on the target data and generate search results responsive to the search query using the generated search index (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market … a proprietary sparse retrieval model that implements semantic search out of the box; industry-leading relevance of all types – keyword, semantic, and vector; see also paragraph 20, where lexical search that made Elasticsearch popular (BM25) is an example of a sparse retrieval method. It uses a bag-of-words representation for text and achieves high relevance by modifying the basic relevance scoring method known as TF-IDF (term frequency, inverse document frequency) for factors like length of the document).
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 6, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 4, wherein:
the specification comprises an analysis type parameter value, the one or more machine learning pre-processing operations comprise one or more operations for filtering the target data in accordance with the analysis type parameter value, before performing the text vectorization on the target data (see GPTutorPro, Section 3, paragraph 4, where transform is a way to create a new index from an existing one by applying transformations and aggregations on the data, such as grouping, filtering, or summarizing. A transform can help you to reshape the data into a more convenient format for machine learning purposes, such as reducing the dimensionality, creating features, or extracting insights), and
the one or more search operations comprise one or more operations for filtering the target data in accordance with the analysis type parameter value, before generating the search index (see GPTutorPro, Section 3.1, paragraph 1, where the previous section, you learned what are pipelines and processors, and how they can help you to ingest data from various sources and apply transformations to it before indexing it into Elasticsearch; see also Section 3, paragraph 4, where A transform is a way to create a new index from an existing one by applying transformations and aggregations on the data, such as grouping, filtering, or summarizing; see also Section 3.1, paragraph 2, where Data preprocessing can involve various tasks, such as removing noise, outliers, or duplicates, handling missing or inconsistent values, normalizing or scaling the data, encoding categorical variables, creating new features, or reducing the dimensionality).
Regarding Claim 7, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 6, wherein the analysis type parameter is at least one of:
a pattern recognition parameter value for executing a pattern recognition function, a normalization parameter value for normalizing the text to a common standard, format, or value (see GPTutorPro, Section 3.1, paragraph 2, where Data preprocessing can involve various tasks, such as removing noise, outliers, or duplicates, handling missing or inconsistent values, normalizing or scaling the data, encoding categorical variables, creating new features, or reducing the dimensionality), a no-op parameter value for performing no analysis or processing on the text, or a delimiter parameter value for splitting the text into tokens using one or more specified delimiters.
Regarding Claim 8, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 7, wherein the target data comprises text data (see GPTutorPro, Section 2, paragraph 2, where you can use the ingest-attachment plugin to extract metadata and content from various types of files, such as PDF, Word, or Excel), and the pattern recognition parameter value further comprises a regular expression (see GPTutorPro, Section 3, paragraph 2, where A pipeline is a set of processors that specify the transformations to be applied to the data by the ingest nodes and plugins. A processor is a component that performs a single operation on the data, such as removing a field, renaming a field, or adding a field).
Regarding Claim 9, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 4, wherein:
the specification comprises a statistical process parameter value specifying a type of statistical process, the one or more machine learning pre-processing operations comprise one or more operations for generating statistical data from the target data by performing the specified type of statistical process (see GPTutorPro, Section 3, paragraph 5, where An aggregation is a way to summarize and analyze the data by grouping it into buckets and calculating metrics, such as count, sum, average, or percentiles. An aggregation can help you to explore and understand the data, as well as to create features or extract insights for machine learning purposes).
GPTutorPro does not disclose the one or more search operations comprise one or more operations for generating the search index based on the generated statistical data. Suhm discloses the one or more search operations comprise one or more operations for generating the search index based on the generated statistical data (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market … a proprietary sparse retrieval model that implements semantic search out of the box; industry-leading relevance of all types – keyword, semantic, and vector; see also paragraph 20, where lexical search that made Elasticsearch popular (BM25) is an example of a sparse retrieval method. It uses a bag-of-words representation for text and achieves high relevance by modifying the basic relevance scoring method known as TF-IDF (term frequency, inverse document frequency) for factors like length of the document).
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 10, GPTutorPro in view of ThinkETL and Suhm discloses the system of Claim 9, wherein:
GPTutorPro does not disclose the statistical process is at least one of a bag of words frequency calculation, a term frequency-inverse document frequency (TF-IDF) calculation, a cosine distance calculation, a Euclidean distance calculation, or a Levenshtein distance calculation. Suhm discloses the statistical process is at least one of a bag of words frequency calculation, a term frequency-inverse document frequency (TF-IDF) calculation (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market … a proprietary sparse retrieval model that implements semantic search out of the box; industry-leading relevance of all types – keyword, semantic, and vector; see also paragraph 20, where lexical search that made Elasticsearch popular (BM25) is an example of a sparse retrieval method. It uses a bag-of-words representation for text and achieves high relevance by modifying the basic relevance scoring method known as TF-IDF (term frequency, inverse document frequency) for factors like length of the document), a cosine distance calculation, a Euclidean distance calculation, or a Levenshtein distance calculation.
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 13, GPTutorPro in view of ThinkETL discloses the system of Claim 1, wherein:
GPTutorPro does not disclose the machine learning pre-processing system and the search sub-system are configured to perform one or more overlapping operations. Suhm discloses the machine learning pre-processing system and the search sub-system are configured to perform one or more overlapping operations (see Suhm, paragraph 2, where If you’re looking for the best retrieval performance, hybrid approaches that combine keyword-based search (sometimes referred to as lexical search) with vector-based approaches represent the state of the art).
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 17, GPTutorPro in view of ThinkETL discloses the method of Claim 16, wherein:
GPTutorPro does not disclose:
the one or more machine learning pre-processing operations comprise one or more operations for performing a text vectorization of the target data, wherein the target data is vectorized in accordance with the specification; and
the one or more search operations comprise one or more operations for generating one or more tokens of text from the target data, and generating a search index for the one or more tokens of text, wherein the one or more tokens of text are generated in accordance with the specification.
Suhm discloses:
the one or more machine learning pre-processing operations comprise one or more operations for performing a text vectorization of the target data, wherein the target data is vectorized in accordance with the specification (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market: fully performant and scalable vector database functionality, including storing embeddings and efficiently searching for nearest neighbor), and
the one or more search operations comprise one or more operations for generating one or more tokens of text from the target data, and generating a search index for the one or more tokens of text, wherein the one or more tokens of text are generated in accordance with the specification (see Suhm, paragraph 4, where Elastic is positioned to be a leader in the rapidly evolving vector database market … a proprietary sparse retrieval model that implements semantic search out of the box; industry-leading relevance of all types – keyword, semantic, and vector; see also paragraph 20, where lexical search that made Elasticsearch popular (BM25) is an example of a sparse retrieval method. It uses a bag-of-words representation for text and achieves high relevance by modifying the basic relevance scoring method known as TF-IDF (term frequency, inverse document frequency) for factors like length of the document).
GPTutorPro and Suhm are both directed to configuring Elasticsearch. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro with Suhm as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 18, GPTutorPro in view of ThinkETL and Suhm discloses the method of Claim 17, wherein:
the specification comprises an analysis type parameter value, the one or more machine learning pre-processing operations comprise one or more operations for filtering the target data in accordance with the analysis type parameter value, before performing the text vectorization on the target data (see GPTutorPro, Section 3, paragraph 4, where transform is a way to create a new index from an existing one by applying transformations and aggregations on the data, such as grouping, filtering, or summarizing. A transform can help you to reshape the data into a more convenient format for machine learning purposes, such as reducing the dimensionality, creating features, or extracting insights), and
the one or more search operations comprise one or more operations for filtering the target data in accordance with the analysis type parameter value, before generating the search index (see GPTutorPro, Section 3.1, paragraph 1, where the previous section, you learned what are pipelines and processors, and how they can help you to ingest data from various sources and apply transformations to it before indexing it into Elasticsearch; see also Section 3, paragraph 4, where A transform is a way to create a new index from an existing one by applying transformations and aggregations on the data, such as grouping, filtering, or summarizing; see also Section 3.1, paragraph 2, where Data preprocessing can involve various tasks, such as removing noise, outliers, or duplicates, handling missing or inconsistent values, normalizing or scaling the data, encoding categorical variables, creating new features, or reducing the dimensionality).
Regarding Claim 19, GPTutorPro in view of ThinkETL and Suhm discloses the method of Claim 18, wherein the target data comprises text data (see GPTutorPro, Section 2, paragraph 2, where you can use the ingest-attachment plugin to extract metadata and content from various types of files, such as PDF, Word, or Excel), and the pattern recognition parameter value further comprises a regular expression (see GPTutorPro, Section 3, paragraph 2, where A pipeline is a set of processors that specify the transformations to be applied to the data by the ingest nodes and plugins. A processor is a component that performs a single operation on the data, such as removing a field, renaming a field, or adding a field).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over GPTutorPro and ThinkETL as applied to Claims 1-3, 14-16, and 20 above, and further in view of Raghuvansh (PG Pub. No. 2025/0014112 A1).
Regarding Claim 12, GPTutorPro in view of ThinkETL discloses the system of Claim 1, wherein:
GPTutorPro does not disclose the specification is part of a structured query language (SQL) statement . Raghuvansh discloses the specification is part of a structured query language (SQL) statement (see Raghuvansh, paragraph [0060], where once the mapping is done, the data gaps are checked and finally the data is ingested by writing the SQL ingestion query).
GPTutorPro and Raghuvansh are both directed to configuring ingestion pipelines. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine GPTutorPro and Raghuvansh as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Response to Arguments
Applicant’s Arguments, filed June 22, 2026, have been fully considered, but they are moot in light of the new groudns of rejection.
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 FARHAD AGHARAHIMI whose telephone number is (571)272-9864. The examiner can normally be reached M-F 9am - 5pm ET.
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, Apu Mofiz can be reached at 571-272-4080. 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.
/FARHAD AGHARAHIMI/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights