DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 28 is objected to due to the following exemplary informalities: The claim is not terminated with a period (“.”). Applicant is respectfully reminded to review the specification/abstract/ claims/drawings for all informalities.
Appropriate correction is required.
Claim Rejections – 35 U.S.C. § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 24-43 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
At step 1: claim 24 is directed to a “method” and thus directed to a statutory category, claim 36 is directed to a “system” and thus directed to a statutory category. Claim 43 is directed to a “non-transitory computer readable storage medium” claim thus directed to a statutory category.
At step 2a prong 1: claims 24, 36 and 43 recite the limitation that is directed to an abstract idea, “generating the data pipeline based at least in part on the generated query in the standard query language, the data pipeline comprising one or more data pipeline elements, at least one data pipeline element of the one or more data pipeline elements corresponding to a query component of the generated query in the standard query language” as drafted recites a mentally perforable process as one can generate a data pipeline of elements corresponding to a query component mentally or with the aid of pencil and paper.
At step 2a prong 2: Claims 24, 36 and 43 recite the following additional elements, “receiving a natural language (NL) query” and “receiving a model result based upon the NL query”. Such language represents insignificant extra-solution activity as retrieval/receiving of data (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Additionally, claims 24, 36 and 43 recite the additional elements: “one or more processors” (claim 24), “one or mor processors” and “one or more memories” (claim 36), and “one or more processors” and a “storage medium” (claim 43). These elements are high-level recitations of generic computer components and represent mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application.
At step 2b: the conclusions for the additional elements representing mere implementation using a computer are carried over and do not provide significantly more.
The two "receiving" limitations are identified as insignificant extra-solution activity above, and when re-evaluated these elements are well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remain insignificant extra-solution activity that does not provide significantly more.
Therefore, each of these claims as a whole does not change this conclusion, and the claims are ineligible.
Claims 25-35 and 37-42 depend upon claims 24 and 36, respectively, and do not correct the issues set forth above. These claims essentially further recite data and generic/abstract processing modifications that may be performed mentally or via the aid of paper and pencil. Therefore, these claims are likewise rejected.
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 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 24-33 and 35-43 are rejected under 35 U.S.C. §103 as being unpatentable over Romero Calvo et al (US Patent No. 12,124,440, hereafter referred to as “Romero”) in view of Immanuel Haffner et al. (“Fast Compilation and Execution of SQL Queries with WebAssembly”, arXiv, Cornell University Archive, document no: arXiv:2104.15098v2 [cs.DB], 3 May 2021, downloaded from: https://arxiv.org/abs/2104.15098, pp. 1-14, hereafter referred to as “Haffner”).
Regarding independent claim 24: Romero teaches A method for generating a data pipeline, the method comprising: receiving a natural language (NL) query, the NL query including one or more constraints associated with a target dataset; (See Romero Abstract, col. 2 line 62 – col. 3 line 7, and Figures 1 and 2 teaching the reception of a NLQ [natural language query] sentence comprised of “parts” that are necessary in order to compose a final SQL query, and are ultimately replaced by “key arguments”. See also, col. 9 line 59 – col. 10 line 14 discussing the use of an NLP-SQLQ engine that provides a pipeline of different stages/processes) receiving a model result generated based on the NL query, the model result including a generated query in a standard query language, the model result being generated using one or more computing models; (See Romero Abstract and col. 2 line 62 – col. 3 line 11 discussing the use of a model in the conversion of a NLQ to a standard query language, such as SQL.) wherein the method is performed using one or more processors. (See Romero Fig. 7 and col. 11 line 66 – col. 12 line 5 teaching an exemplary computing environment including processors and storage.)
However, Romero does not explicitly teach the remaining limitations as claimed. Haffner, though, teaches and generating the data pipeline based at least in part on the generated query in the standard query language, the data pipeline comprising one or more data pipeline elements, at least one data pipeline element of the one or more data pipeline elements corresponding to a query component of the generated query in the standard query language; (See Haffner page 4 , Figure 2 showing a generated QEP pipeline comprised of three component pipelines [sub-pipelines] and generated from the SQL code of “Listing 2”.)
It 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 to apply the teachings of Haffner for the benefit of Romero, because to do so provided a designer with options for implementing a system to dissect a query execution plan into linear sequences of operators that process tuples without the need for intermediate materialization, as taught by Haffner in the 3rd paragraph of page 4. These references were all applicable to the same field of endeavor, i.e., query processing.
Regarding claim 25: Romero teaches wherein the one or more constraints associated with the target dataset include at least one selected from a group consisting of a metric associated with the target dataset, a parameter associated with the target dataset, a parameter range associated with the target dataset, a date range, and a data range. (See Romero Fig. 1, esp. #112, showing a variety of constraints associated with the data set, including a “time” metric and other parameters.)
Regarding claim 26: Romero teaches further comprising: identifying under-specified information associated with the NL query, the under- specified information including at least one selected from a group consisting of missing information, mismatched information, a missing concept, and a mismatched concept; and generating a question based on the under-specified information. (See Romero col. 2 line 62 – col. 3 line 4 discussing disambiguating drug names / health conditions into codes or other ontologies [i.e., mismatched concepts] in order to compose the final query.)
Regarding claim 27: Romero teaches wherein the receiving a model result generated based on the NL query includes: receiving an explanation associated with the generated question; generating a model query based at least in part on the NL query and the explanation; providing the model query to the one or more computing models; and receiving the model result generated using the one or more computing models based at least in part on the model query. (See Romero col. 7 lines 43-50 and col. 8 lines 6-10 teaching that edits/updates may be supplied to the system, in the context of col. 7 lines 60-66 teaching that edits/changes may be used to update a model.)
Regarding claim 28: Romero teaches further comprising: generating a model query based on at least one selected from a group consisting of the NL query, one or more input datasets, and the target dataset; and providing the model query to the one or more computing models; (See Romero col. 2 lines 29-61 teaching the selection of pre-defined SQL subquery templates, i.e., different trained models, when converting from NLQ to SQL queries, in the context of Fig. 1 #116, 118, 120 and 122.)
Regarding claim 29: Romero teaches further comprising: selecting the one or more computing models from a set of computing models based on at least one selected from a group consisting of the NL query, one or more input datasets, and the target dataset. (See Romero col. 2 lines 29-61 teaching the selection of pre-defined SQL subquery templates, i.e., different trained models, when converting from NLQ to SQL queries, in the context of Fig. 1 #116, 118, 120 and 122.)
Regarding claim 30: Romero teaches wherein the NL query is received from a user, wherein the method further comprises: identifying an access permission associated with the target dataset; receiving permission information associated with the user; and evaluating whether the user is permitted to access the target dataset based on the access permission associated with the target dataset and the permission information associated with the target dataset. (See Romero col. 8 lines 23-29 and col. 9 line 62 – col. 10 line 7 discussing a mechanism to gain access to the database via the setting/entering of access credentials information.)
Regarding claim 31: Romero teaches further comprising: in response to the user being not permitted to access the target dataset, denying a response to the NL query. (See Romero col. 8 line 62 – col. 9 line 7 discussing denial of an access request when a user is not authorized access.)
Regarding claim 32: Romero does not explicitly teach the remaining limitations as claimed. Haffner, though, teaches further comprising: generating a query execution plan based at least in part on the generated query in the standard query language, wherein the query execution plan comprises an order of query operations, wherein the data pipeline is generated based on the query execution plan. (See Haffner page 4 paragraphs 1-4 in the context of page 4 Figure 2 and Listing 2 teaching the generation of a QEP reflecting the SQL query of Listing 2 and comprised of 3 query operations/components. Each query operation is represented a sub-pipeline, and the entire [3-part] QEP results in the complete data pipeline for the SQL/code of Listing 2.)
Regarding claim 33: Romero teaches wherein the model result includes a confidence score associated with the generated query in the standard query language. (See Romero col. 4 lines 32-49 discussing the use of a confidence score in choosing argument placeholders that are to be reflected in the SQL query. See also col. 5 lines 15-25 teaching that this modified NLQ is subsequently input into an NLQ to SQL model.)
Regarding claim 35: Romero teaches wherein the data pipeline uses one or more platform-specific expressions associated with a platform. (See Romero col. 5 lines 25-60 teaching the use of templates associated with differing ontology codes that will be reflected in the final SQL query, which in turn is reflected in the resultant data pipeline.)
Claims 36-41 are substantially similar to claims 24-29, respectively, and therefore likewise rejected.
Claim 42 is substantially similar to claim 31, and therefore likewise rejected.
Claim 43 is substantially similar to claim 24, and therefore likewise rejected.
Claim 34 is rejected under 35 U.S.C. §103 as being unpatentable over Romero Calvo et al (US Patent No. 12,124,440, hereafter referred to as “Romero”) in view of Immanuel Haffner et al. (“Fast Compilation and Execution of SQL Queries with WebAssembly”, arXiv, Cornell University Archive, document no: arXiv:2104.15098v2 [cs.DB], 3 May 2021, downloaded from: https://arxiv.org/abs/2104.15098, pp. 1-14, hereafter referred to as “Haffner”) and Clark et al (US Patent No. 7,299,237, hereafter referred to as “Clark”).
Regarding claim 34: Romero in view of Haffner does not explicitly teach the remaining limitations as claimed. Clark, though, teaches further comprising: applying the data pipeline to one or more input datasets to generate an output dataset; wherein the output dataset has a data schema that is the same as a data schema of the target dataset. (See Clark Fig. 2 in the context of the Abstract, col. 2 lines 6-12 and col. 5 lines 35-51 teaching that a data pipeline converts data into that conforming to a target schema.)
It 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 to apply the teachings of Clark for the benefit of Romero in view of Haffner, because to do so provided a designee with options to implement a system to dynamically and automatically transform data into a conforming format, as taught by Clark in col. 2 lines 6-12. These references were all applicable to the same field of endeavor, i.e., data conversion mechanisms.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document.
Non-Patent Literature
Durvasula, Ramya, “An Interactive Approach to Generating SQL Queries from Natural Language”, Master of Engineering Thesis, Dept. of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Boston, MA, February 2022, downloaded from: https://dspace.mit.edu/handle/1721.1/143192, 71 pages.
Perhaps the most obvious barrier to writing an accurate SQL query is the fact that the programmer must understand quite a lot about their data: its format, its exact schema, and the precise relationships necessary to create join paths. Whereas a full-time data scientist may have all of the requisite knowledge needed for ad-hoc query writing, a business user may need help building out a data pipeline for metrics, and a developer may spend much more time than necessary gathering usage data. (page 13, 3rd paragraph of section labelled “Introduction”). The first step of the algorithm is to run the natural language descriptions through nalini’s semantic parser, which we detail further in Section 2.3.1. The parser, which we built from scratch using the SEMPRE framework [4] uses standard semantic parsing techniques to translate English descriptions into sketches of SQL columns and filters respectively. The column and filter sketches specify the shapes of the output SQL fragments (e.g. as a tree of operations) rather than specifying a complete SQL fragment. Where the eventual query will contain references to database columns or values, the parsed sketch will contain a hole annotated with the corresponding fragment of the English description. As a result, the semantic parser can operate without any knowledge of the database schema or values. The database-agnostic nature of the semantic parser is extremely valuable, as it means that the semantic parser does not have to be fine-tuned or retrained every time the user wishes to query a new database. (page 25, 1st paragraph). The last step of the synthesis process is to actually render the SQL query from all of the synthesized data structures, which we detail in Section 2.3.4. This is a deterministic process where the syntax of the SQL dialect actually comes into play. The engine then returns the completed query. (page 26, 1st full paragraph).
Haffner, Immanuel, et al., “Fast Compilation and Execution of SQL Queries with WebAssembly”, arXiv, Cornell University Archive, document no: arXiv:2104.15098v2 [cs.DB], 3 May 2021, downloaded from: https://arxiv.org/abs/2104.15098, pp. 1-14.
The tree structure of a QEP can be dissected into pipelines. A pipeline is a linear sequence of operators that does not require materialization of tuples. To identify the pipelines of a QEP, we hence must identify all operators that require materialization, named pipeline breakers. The most common pipeline breakers are grouping, join, and sorting; table scan, index seek, selection, and projection are not pipeline breakers. (page 4, 1st full paragraph).
US Patent Application Publications
Mudumba 2022/0398186
In some implementations, an analytics platform may process a data lineage configuration to identify one or more data sources storing one or more data sets associated with a data analytics use case and identify one or more data relations associated with the one or more data sets. The analytics platform may parse a source code template defining one or more functions to build a data mart and a data pipeline that enables the data analytics use case. The source code template may include one or more tokens to specify elements that define the one or more data sources, data sets, and data relations identified in the data lineage configuration. The analytics platform may automatically generate source code that is executable to build a data mart and a data pipeline to enable the data analytics use case based on the data lineage configuration and the source code template. (Abstract). Some implementations described herein relate to a lineage-driven approach to generate source code to build, test, deploy, and/or maintain a data mart and a data pipeline. For example, in some implementations, a code generation platform may programmatically (e.g., automatically) generate source code that can then be executed to build a data mart, and a data pipeline supporting the data mart, based on a data lineage configuration that identifies one or more data sources that store one or more data sets to be used to populate the data mart, one or more data relations among the data sources, and/or one or more data processing operations that are to be performed on the one or more data sets as the data sets move through the data pipeline (e.g., join operations, transformation operations, filtering operations, and/or aggregation operations, among other examples). For example, in some implementations, the code generation platform may receive a source code template that includes one or more tokens (e.g., placeholder elements) to define the data sources, data relations, data processing operations, and/or other aspects of a data mart and/or a data pipeline supporting a data analytics use case, and the code generation platform may perform a template substitution process to substitute elements in the data lineage configuration for the tokens in the source code template. (para 0012). As further shown in FIG. 1A, and by reference number 130, the code generation platform may generate source code based on the data lineage configuration and the language-specific source code template. For example, in some implementations, the functions defined in the language-specific source code template may be associated with a query execution engine (e.g., Structured Query Language (SQL), Python, Java, Scala, and/or Spark), and the source code template may include one or more tokens (e.g., placeholder elements) to represent variables, arguments, and/or other programming elements that correspond to data lineage elements. Accordingly, in some implementations, the code generation platform may perform or invoke a template substitution engine configured to substitute which elements in the data lineage configuration for the appropriate tokens in the language-specific source code template. (para 0025). Furthermore, the lineage-driven and template-driven approach may be used to automatically generate one or more test cases to validate the source code and/or the data pipeline that is configured by executing the source code. For example, the one or more test cases may include a set of inputs and a set of expected outputs that are automatically generated based on the data lineage configuration. In this way, the code generation platform may validate whether the source code that is generated from the data lineage configuration and the language-specific source code template matches an intent of the data mart. In this way, in cases where the actual outputs from executing the test case(s) deviate from the expected outputs, the data lineage configuration and the source code template can be reviewed to identify and/or correct issues that are causing the actual outputs to deviate from the expected outputs. (para 0026). The data repository 220 includes one or more storage devices capable of receiving, generating, storing, processing, and/or providing information associated with a language-agnostic data lineage configuration and a language-specific source code template that can be provided as inputs to the code generation platform 210 to generate source code for building, testing, deploying, and/or maintaining a data mart and an associated data pipeline, as described elsewhere herein. The data repository 220 may include a database engine, a database, a data center, a cloud computing resource, a table, a list, and/or a data structure. (para 0033).
Gibson 2021/0117437
Described herein are systems and methods of transforming data models, for example, creating a data warehouse. A directives model may be loaded based upon a parsed directives file. An entity model may be loaded, and tables, attributes, and foreign keys of a data warehouse model may be created based upon the directives model and the entity model. Mappings may be created between tables, columns, and foreign keys of the data warehouse model and entities, attributes, and relationships, respectively, of the entity model. Code to define a data warehouse may be generated based upon the tables, attributes, and foreign keys of the data warehouse model. Code to transfer data from the source data source can be generated based upon the created mappings. A lineage report can be generated that provides information identifying a corresponding source for each table and column in the data warehouse. (Abstract). The system 100 can receive directive information that describes how to map a source data model to a target data model (e.g., data warehouse) using one or more predefined pattern templates. The target model generation component 110
can generate code (e.g., SQL code) to create the target data model (e.g., data warehouse) based, at least in part, upon the directive information. (para 0042). The system 100 may take a source model (e.g., an entity model) that describes a data source and a set of user-defined design directives and may generate a data warehouse implementation (e.g., a complete SQL data warehouse (“SQL DW”) implementation) and parameters to configure a pipeline (e.g., Microsoft® Azure® Data Factory (ADF), Amazon® Web Services Data Pipeline, Apache® NiFi, etc.) for loading the data warehouse (“DW”). The resulting design can implement well-known data warehousing and loading patterns. (para 0044).
Zusman 2018/0239617
The techniques described herein facilitate asynchronous management of external or Big Data processing pipelines from within client-side (or local) spreadsheet applications, e.g., Microsoft Excel®. In an implementation, a method of operating a spreadsheet application service to facilitate management of big data pipelines from within a client-side spreadsheet application is disclosed. The method includes receiving a processing request initiated by a spreadsheet application. The processing request includes instructions for generating one or more big data pipelines between one or more external distributed computing systems. The method further includes translating the instruction into one or more scripts corresponding to the one or more external distributed computing systems, and executing the one or more scripts to direct the one or more external distributed computing systems to automatically generate the big data pipelines. (Abstract). The first example processing step ‘FROM table1 TO table2 TYPE COSMOS’ provides a location of the initial data, where to put the data and a type, e.g., COSMOS. In some embodiments, each step can indicate generation of a new data pipeline. A second example processing step ‘FROM table2 TO SQL table1 TYPE EXPORT’ illustrates a pipeline B being generated from a Cosmos framework to a specific table in an SQL framework. Lastly, the third processing step ‘FROM SQL table1 TO JobTable’ illustrates a pipeline C generated to put results (or output) of the data pipelines into a table associated with the job ID for temporary storage within the spreadsheet app service. FIG. 4B provides another example illustrating generation of pipelines A-E. As shown, pipelines can be processing steps within a framework, e.g., data pipeline C. (para 0039).
Allan 2018/0052898
In accordance with various embodiments, described herein is a system (Data Artificial Intelligence system, Data AI system), for use with a data integration or other computing environment, that leverages machine learning (ML, DataFlow Machine Learning, DFML), for use in managing a flow of data (dataflow, DF), and building complex dataflow software applications (dataflow applications, pipelines). In accordance with an embodiment, the system can include a software development component and graphical user interface, referred to herein in some embodiments as a pipeline editor, or Lambda Studio IDE, that provides a visual environment for use with the system, including providing real-time recommendations for performing semantic actions on data accessed from an input HUB, based on an understanding of the meaning or semantics associated with the data. (Abstract). In accordance with an embodiment, depending on the types of pipeline steps and code optimization, a data pipeline can be generated as a single Spark application for execution in a Spark cluster, as multiple SQL statements for execution in DBCS, or as a mixture of SQL and Spark code. For an orchestration pipeline, it can be generated for execution in the underlying execution engine, or in a workflow schedule component such as, e.g., Oozie. (para 0283).
Zhang 2021/0406281
The process of querying a related OLAP model by means of SQL is completed through a query execution engine; and the process mainly includes: analyzing SQL statements, generating an SQL syntax tree, analyzing the SQL syntax tree, converting the same into a query execution plan (a query execution process), confirming an OLAP model, generating a physical execution plan, extracting a pre-calculation result, combining and analyzing the pre-calculation result, and outputting a final result. (para 0005).
Mishra 2021/0064775
According to one embodiment, the present invention may allow users to connect to a common database to work collaboratively on a project and validate each user's access rights. In at least one other embodiment, the present invention may also create a pipeline of user queries by running one query at a time and validating each user's access rights repeatedly as each query is processed. The present invention may further generate query processing procedures or functions based on the generated pipeline and save in a database for the future. (para 0015).
US Patents
Morsi 9,396,037
A computer-implemented method for optimizing a data pipeline system includes processing a data pipeline configuration manifest to generate a framework of the data pipeline system and a data flow logic package of the data pipeline system. The data pipeline configuration manifest includes an object-oriented metadata model of the data pipeline system. The computer-implemented method further includes monitoring performance of the data pipeline system during execution of the data flow logic package to obtain a performance metric for the data pipeline system, and modifying, with a processor, the framework of the data pipeline system based on the data pipeline configuration manifest and the performance metric. (Abstract).
Romero Calvo 12,124,440
In embodiments, the modified natural language query may be passed to an NLQ to SQLQ model (e.g., a trained ML model) that converts the modified natural language query into an initial SQL query with argument placeholders and subquery placeholders. In various embodiments, the model is trained to use natural language queries with argument placeholders and output modified natural language queries with argument and subquery placeholders. Therefore, any changes to the ontologies will not affect the trained model. The modified natural language query may then be rendered with predefined SQL subquery templates and arguments placeholders may be detected and disambiguated, resulting in the final SQL query that may be executed. Although the HCLS domain is used as an example, in various embodiment any of the techniques described herein may apply to any other data domain/field. (col. 3 lines 12-27). This specification begins with a description of converting a natural language query to an SQL query using ontological codes and placeholders. An example user interface is presented. A system for converting a natural language query to an SQL query using ontological codes and placeholders is also discussed. A number of different methods and techniques to implement converting a natural language query to an SQL query using ontological codes and placeholders (col. 3 lines 39-46). In embodiments, a client (e.g., an administrator/developer of the client) may configure any number of different aspects of the client-specific NLQ-SQLQ engine so that the client-specific NLQ-SQLQ engine (e.g., the pipeline of different stages/processes) is tailored to the particular desire/requirements of the client (e.g., users of the client). For example, the NLQ-SQLQ service may receive (e.g., via the service interface from an administrator at a remote client network) configuration input to select a particular model, model service, or other application/software code modules/functions from among multiple different models, model services, or application/software code modules/functions that are available for use by the client-specific NLQ-SQLQ engine to perform entity detection at the pre-processor stage in order to generate the modified NLQ and/or to convert the modified NLQ to the initial SQL query and/or to perform post-processing to generate the final SQL query. Therefore, the trained model that is used to generate the initial SQL query may be selected based at least on a configuration input received by the NLQ-SQLQ service. Similarly, the predefined SQL subquery templates used to generate the final SQL query may be selected based at least on configuration input received by the NLQ-SQLQ service. (col. 9 line 59 – col. 10 line 14).
Clark 7,299,237
In accordance with one embodiment of the present invention, there is provided a technique for dynamically pipelined data migration. According to one aspect, it is determined that a source schema-conformant source data set is to be converted to a target schema-conformant target data set. A plurality of conversion mechanisms, which can be invoked in succession to convert the source data set into the target data set, is automatically determined. The plurality of conversion mechanisms comprises (a) an initial set of one or more conversion mechanisms that can be invoked in succession to convert the source data set to a final intermediate data set, and (b) a final conversion mechanism that converts the final intermediate data set to the target data set. Each conversion mechanism in the plurality of conversion mechanisms is successively invoked, in order, to convert the set of source data set to the target data set. (Abstract). In accordance with one embodiment of the present invention, there is provided a technique for dynamically pipelined data migration. Using this technique, a sequence or "pipeline" of conversion mechanisms that will transform data that conforms to a source schema into data that conforms to a target schema are dynamically and automatically determined and applied. (col. 2 lines 6-12, See also Fig. 2). In the same manner as conversion mechanisms 206A-N in the "main" pipeline, conversion mechanisms in the "sub-pipeline" collectively convert the embedded data structure so that the embedded data structure conforms to a specified target schema that differs from the source schema to which the embedded data structure originally conformed. Once the embedded data structure has been converted to conform to the specified target schema (which may differ from the target schema to which the container data structure conforms after conversion), the converted embedded data structure is "re-embedded" into the containing data structure and passed, with the rest of the containing data structure, to the next of conversion mechanisms 206A-N in the "main" pipeline. (col. 9 lines 7-19).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner ROBERT STEVENS whose telephone number is (571) 272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2:30.
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, Amy Ng can be reached on (571) 270-1698. 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.
/ROBERT STEVENS/Primary Examiner, Art Unit 2164
February 7, 2026