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 .
This action is responsive to application filed on 4/30/25. Claims 1-20 are presented for examination.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fozdar et al (USPN. 20250077538).
Regarding claim 1, Fozdar teaches a method of converting a data request for data under a first schema to a data request for a migrated version of the data under a second schema, the method comprising (figs. 1, par. 19 “reformulate such query”, “query”, “user request”, “data transformation” and par. 23, different schemas and LLM):
receiving a first data request targeting a subset of first data stored in a first database under a first schema, wherein second data stored in a second database under a second schema comprises a migrated version of the first data (fig. 4, par. 50, store data 416 in plurality of databases, some data already under data integration, pars. 15-16, query against source schemas using LLM with integration solutions); and
converting the first data request into a second data request targeting a subset of the second data that comprises a migrated version of the subset of the first data, wherein the converting comprises (pars. 19-20, 23, query is effectively reformulated to handle source and destination schema types):
pre-processing the first data request to obtain a modified first data request reflecting differences between the subset of the first data and the subset of the second data (fig. 1, pars. 19 and 23, activity planning phase of data integration involves preprocessing, see fig. 3B, pars. 26 and 31, pipeline and regenerate pipeline, the activity and regenerate comprises difference between data requests);
inputting the modified first data request into a large language model (LLM) to obtain, using a resulting output from the LLM, the second data request (figs. 1 and 3B, item 314, run pipeline, pars. 44-45, run pipeline includes inputting the modified pipeline and handling the request from Source1 into Folder1, via Destination 1). To the degree that Fazdar does not explicitly teach two databases with specific schemas, Fazdar teaches a plurality of databases (par. 50, databases) comprising source and destination schema types (pars. 23, “source and schema types”) and generating a query language that creates and modifies data pipelines via LLM (par. 23, “data pipelines” and “LLM”). It would have been obvious to one of ordinary skill in the field at the effective filing date to implement the Fozdar architecture of data and query processing and reformulating using LLM to obtain, preprocess and process a query into a destination format database (pars. 5, 15 and 23, Fozdar). One would have been motivated to process data using the Fozdar architecture to get the desired result in any format (pars. 20 and 28, “result”).
2. Modified Fozdar further teaches comprising executing the second data request on the subset of the second data stored in the second database (fig. 4, par. 50, store data 416 in plurality of databases, some data already under data integration, pars. 15-16, query against source schemas using LLM with integration solutions on plurality of sources).
3. Modified Fozdar further teaches, wherein the first data stored in the first database comprises relational data, the first data request comprises a query targeting a subset of the relational data, the second database comprises a flexible schema database, and the second data request targets unstructured data stored in the flexible schema database (pars. 23-24, integration applications copy data between specific source and destination locations wherein LLM learns relationships and transforms them to the relevant sequences and pipeline to process).
4. Modified Fozdar further teaches wherein the pre-processing further comprises removing fields from the first data request that are not used in the subset of the second data that is stored in the second database (fig. 1, pars. 16, 19 and 23, activity planning phase of data integration involves preprocessing, see fig. 3B, pars. 26 and 31, pipeline and regenerate pipeline, the activity and regenerate comprises difference between data requests and decomposes/compresses the queries into small tasks that are relevant).
5. Modified Fozdar further teaches wherein the pre-processing further comprises extracting data operations in a query programming language from within data operations in a general-purpose programming language (fig. 1, par. 16, ETL).
6. Modified Fozdar further teaches wherein the pre-processing further comprises identifying a largest data operation of the first data request, determining whether the largest data operation includes multiple query statements, and in response to determining that the largest data operation includes multiple query statements, separating and individually converting the multiple query statements to respective requests for corresponding data in the second database (fig. 1, par. 17, data integration system is based on transformer architecture which consists of self attention mechanisms comprising utilizing multiple sets of vectors called heads and uses different aspects of the input sequence and subspaces based on relationships. Hence, the bigger the head or relationships the larger the data operation).
7. The method of claim 1, wherein the pre-processing further comprises converting the first data request from a first query programming language of the query to a second programming query language of the modified first data request (par. 23, natural language query into executable query and forming a novel language using forming new dependencies).
8. The method of claim 7, wherein the first query language is a structured query language (SQL) and the second query language is MongoDB query language (MQL) (par. 17-19, LLM uses vectors and json to process and convert data via pipeline sequence steps).
9. The method of claim 1, wherein the pre-processing further comprises performing a depth- first search in the modified first data request to verify representation of each data operation of the first data request in the modified first data request (pars. 16, 19 and 22, determine accuracy and validity of pipeline, pipeline may be preprocessed and includes pipeline processing).
10. The method of claim 1, wherein the pre-processing further comprises replacing names of base data structures under the first schema in the subset of the first data with names of base data structures under the second schema in the second data that comprise the migrated version of the subset of the first data (fig. 3B, par. 44, Name of a source table and pipeline updating).
11. The method of claim 1, wherein: the subset of the first data comprises a first grouping of base-level data structures and a second grouping of base-level data structures under the first schema stored in the first database; the migrated version of the first data comprises a third grouping of base-level data structures under the second schema that comprises a migrated version of the first grouping and the second grouping; and pre-processing the first data request comprises transforming a data operation in the first data request to join the first grouping with the second grouping into a data operation to access the third grouping (par. 19, pipeline grouping of activities that performs a task and transformation of data with appropriate ordering, also see par. 15, schema represents various classes in which the data integration performs).
12. The method of claim 11, wherein: the first grouping of base-level data structures comprises a first table, the second grouping of base-level data structures comprises a second table, the third grouping of base-level data structures comprises a collection of documents and the collection comprises first documents corresponding to rows of the first table and further comprises second documents and/or fields in the first documents corresponding to rows of the second table (fig. 3B and par. 15, parameters Type and Name, Lookup table name1 and column name 1, number of parameters may additionally include for each lookup do copy or combine relevant documents in the workspace using data integration tools based on relationships).
13. The method of claim 11, wherein the third grouping comprises a set of base-level data structures corresponding to base-level data structures of the first grouping and further comprises at least one member selected from the group consisting of: another set of base-level data structures corresponding to base-level data structures of the second grouping; and fields within the set of base-level data structures corresponding to base-level data structures of the second grouping (fig. 3B and par. 15-16, multiple activities: parameters Type and Name, Lookup table name2 and column name 2, number of parameters may additionally include for each lookup do copy or combine relevant documents in the workspace using data integration tools based on relationships for each lookup 2 and activity 2).
14. The method of claim 13, wherein: the set of base-level data structures comprises documents corresponding to rows of a first table, the another set of base-level data structures comprises documents corresponding to rows of a second table, and the fields within the set of base-level data structures comprise fields within the documents corresponding to rows of the first table (fig. 3B and par. 15-16, multiple activities: parameters Type and Name, Lookup table for a plurality of activities).
15. The method of claim 13, wherein the fields comprise an array within a base-level data structure of the set of base-level data structures (par. 17, sequence of input and relationships of a source or query).
16. The method of claim 15, wherein the array is within a document of the set of base-level data structures (par. 17, sequence of input and relationships of a source or query may comprise embeddings).
17. The method of claim 1, further comprising post-processing the output from the LLM to obtain the second data request in a query language corresponding to the second schema (pars. 15 and 30, LLM processing and post-processing data pipeline corresponding to schema to make repairs).
18. The method of claim 17, wherein the post-processing further comprises embedding data operations of the second data request within a general-purpose programming language (pars. 17 and 30, embedding vectors/pipeline and post-processing).
19. The method of claim 17, wherein:the pre-processing further comprises determining whether each grouping of base-level data structures in the subset of the first data corresponds to a respective grouping of base-level data structures in the subset of the second data, and when a first grouping of base-level data structures in the subset of the first data does not correspond to a respective grouping of base-level data structures in the subset of the second data, the post-processing further comprises: transforming a data operation accessing the respective grouping of base-level data structures in the subset of the second data into a transformed data operation accessing base-level data structures within another grouping of base-level data structures in the subset of the second data corresponding to another respective grouping of base-level data structures in the subset of the first data (pars. 19-21, LLM is utilized to perform activity specific APIs for each activity identified in the planning phase wherein the data formatting takes place only when the schema differs. Note that each activity may perform multiple source data lookups and activities such as migration/copy or get results, see fig 3B).
20. The method of claim 19, wherein the transformed data operation accesses an array within a base-level data structure in the another grouping in the subset of the second data, the array corresponding to the first grouping of base-level data structures in the subset of the first data (par. 17, sequence of input and relationships of a source or query may comprise embeddings. Specific type of API is used for performing a relevant activity, see par. 20-21).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure in the field of data processing:
UPSN. 20250371041: pars. 67 and 69, preprocess LLM and data processing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARCIN R FILIPCZYK whose telephone number is (571)272-4019. The examiner can normally be reached M-F 7-4 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached at 571-272-8352. 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.
June 10, 2026
/MARCIN R FILIPCZYK/Primary Examiner, Art Unit 2153
Prosecution Insights