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 .
Allowable Subject Matter
Claims 24-43 are allowable over the prior art. However, the claims remain rejected under 35 USC §101.
Reasons For Allowance
The cited references do not disclose generating a query in a standard query language based on the data pipeline, a query component of the generated query in the standard query language corresponding to one data pipeline element of the one or more data pipeline elements, providing the generated query in the standard query language to one or more computing models, and receiving the data pipeline description that is generated based at least in part on the generated query in the standard query language by the one or more computing models.
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.
These claims are rejected under 35 USC §101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites at a very level, producing a description of computer operations. Thus, the claims encompass the performance of the limitations in the mind, or simply with the aid of pencil and paper.
Regarding the independent claims (24, 35 and 43):
Step 1: Yes, claim 24 recites a method (therefore a process), claim 35 is directed to a system (therefore a product/machine), and claim 43 is directed to a storage medium for a series of steps executed (therefore a process embodied in a product). Thus, each of these claims is directed to a statutory category.
Step 2A, Prong 1 (Judicial Exception Recited?): Yes. Independent claims 24, 35 and 43 recite limitations directed to an abstract idea: “generating a query in a standard query language based on the data pipeline, a query component of the generated query in the standard query language corresponding to one data pipeline element of the one or more data pipeline elements; … that is generated that is generated based at least in part on the generated query in the standard query language by the one or more computing models”. As drafted, each of these limitations recites a mentally performable process as one can form query and pipeline data elements/structures via a mental process or using paper and pencil.
Step 2A, Prong 2 (Integrated into a Practical Application?): No. Claim 24 recites the following additional elements: and "one or more processors”; claim 35 recites: "one or more processors”, "one or more memories”, “data pipeline”, “computing models”; and, claim 43 recites “a storage medium”, "one or more processors”, “data pipeline”, “computing models”. Each of these elements are merely high-level recitations of generic computer components (hardware/software/data structures) and represent mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Additionally, claims 24, 35 and 43 each recite “receiving a data pipeline …”, “providing the generated query …”, and “receiving the data pipeline description …”, which represent insignificant extra-solution activity as the receiving/providing/receiving of data (i.e., mere data gathering or obtaining information) is identified in MPEP 2106.05(g) as not providing integration into a practical application. Also, see MPEP 2106.05 I. A. Limitations that the courts have found not to be enough to qualify as "significantly more" when recited in a claim with a judicial exception include: … iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)).
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application. Therefore, each claim is directed to an abstract idea.
Step 2B (Inventive Concept Provided?): No. Regarding claims 24, 35 and 43: As discussed with respect to Step 2A, the elements (i.e., steps of receiving, providing, receiving) in the claim amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception using generic computer components (e.g., storage) cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
With respect to the “receiving …”, “providing …”, and “receiving …” limitations discussed 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 remains insignificant extra-solution activity that does not provide significantly more.
Therefore, each of the claims, taken as a whole, does not change this conclusion and the claims are ineligible.
Claims 25-34 depend upon claim 24, and do not correct the issues set forth above. These claims essentially further the use of particular data/operations, including display of results. Therefore, these claims are likewise rejected.
Claims 36-42 depend upon claim 35, and do not correct the issues set forth above. These claims essentially further the use of particular data/operations, including display of results. Therefore, these claims are likewise rejected.
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
“Using Redshift Spectrum to load data pipelines”, Internet Archive Wayback Machine, captured from: https://www.dativa.com/using-amazon-redshift-spectrum-data-pipelines/, on: April 3, 2019, pp. 1-5.
A lot of our clients use AWS Redshift as the ultimate destination for their data pipeline, and when Amazon launched Redshift Spectrum, our data engineering team wondered whether we could use this technology to provide high-performance throughput without having to load the data into Redshift at all. (page 1, 1st paragraph). With Amazon's Redshift Spectrum service, we can run Redshift SQL queries against data stored in an S3 data lake. We've already used Spectrum to create one-off proof of concept systems for clients for relatively small datasets, as it allows us to quickly start the data science without the need for lots of data engineering. The trade-off is that query times are longer, but for these proof-of-concept systems, this is not a problem. (page 2, 1st paragraph of section “ELT with Redshift Spectrum”).
Raj, Aiswarya, et al., “Modelling Data Pipelines”, 2020 46th Euromicro Conf. on Software Engineering and Advanced Applications (SEAA), Portoroz, Slovenia, August 26-28, 2020, pp. 13-20.
Despite existing research on ETL (Extract-Transform-Load) and ELT (Extract-Load-Transform) pipelines, the research on this topic is limited. ETL/ELT pipelines are abstract representations of the end-to-end data pipelines. To utilize the full potential of the data pipeline, we should understand the activities in it and how they are connected in an end-to-end data pipeline. This study gives an overview of how to design a conceptual model of data pipeline which can be further used as a language of communication between different data teams. Furthermore, it can be used for automation of monitoring, fault detection, mitigation and alarming at different steps of data pipeline. (page 13, Abstract). Data pipeline has four main steps namely ingest, store, transform and aggregate. Data is generated by the source which is gathered by a special zone in the field. The data ingestion module is connected to those zones in the field and the collected data is ingested into the pipeline as batches. When new compressed files are found during periodic checks, the transaction is logged and downloads it. These new files are then loaded into the archive directory of the data cluster. The data stored in the cluster cannot be used directly by the ML applications. Moreover, the data logs collected from different devices can be of different formats. They need to be converted to a suitable format. This conversion is performed by the data transformation module. Data transformation checks for the new files in the archive directory of the data cluster and when found, it is fetched, uncompressed and processed to convert it to an appropriate format. The converted data is then given as input to the data aggregation module where the data is aggregated and summarized to form structured data which is further given as input to the ML models. (page 16, section “C. Pipeline for Machine Learning Systems”). Conceptual model of a data pipeline. (page 18, Fig. 6).
Pölöskei, István, “Continuous natural language processing pipeline”, SACI 2021, Timisoara, Romania, May 19-21, 2021, pp. 221-224.
Natural language processing (NLP) is a division of artificial intelligence. The constructed model's quality is entirely reliant on the training dataset's quality. A data streaming pipeline is an adhesive application, completing a managed connection from data sources to machine learning methods. The recommended NLP pipeline composition has well-defined procedures. The implemented message broker design is a usual apparatus for delivering events. It makes it achievable to construct a robust training dataset for machine learning use case and serve the model's input. The reconstructed dataset is a valid input for the machine learning processes. Based on the data pipeline's product, the model recreation and redeployment can be scheduled automatically. (page 221, Abstract). Tensorflow provides a state-of-the-art pipeline specification (Tensorflow Extended, TFX) [10]. This structure extends its functionality in a workflow management manner (Airflow or Kubeflow) [11]. As separated modules, the preparation actions can be utilized independently but in sequence. (page 221, 2nd paragraph of section “3) Tensorflow and Keras”).
Kacsuk, Peter, et al., “The Flowbster Cloud-Oriented Workflow System to Process Large Scientific Data Sets”, Journal of Grid Computing, Volume 16, January 11, 2018, pp. 55-83.
A Flowbster workflow works as a data pipeline enabling the exploitation of pipeline parallelism, workflow parallel branch parallelism and node scalability parallelism. The Flowbster workflow can be deployed in the target cloud on-demand based on the underlying Occopus cloud deployment and orchestrator tool. Occopus guarantees that the workflow can be deployed in several major types of IaaS clouds (OpenStack, OpenNebula, Amazon, CloudSigma). It takes care of not only deploying the nodes of the workflow but also to maintain their health by using various health-checking options. Flowbster also provides an intuitive graphical user interface for end-user scientists. This interface hides the low level cloud-oriented layers and hence users can concentrate on the business logic of their data processing applications without having detailed knowledge on the underlying cloud infrastructure. (page 55, Abstract). With the new Flowbster/Occopus concept our objective is to simplify the data pipeline (workflow) creation and operation activities. For example, instead of maintaining a science gateway the scientist herself can initiate the execution of an already developed workflow (data processing service pipeline) in a target cloud by some simple clicks and by giving the URL of the data location where the data set to be processed is stored and where the processed data should be written back. As a result, the workflow will be deployed in the target cloud and will enable the flow of data from the source data storage to the target data storage. (page 57, 3rd paragraph of section “2 Concept and Overview). The Flowbster workflow system layer defines its uniform building block (that implements the workflow tasks and will be explained in detail later in Section 4.1) and execution framework by which complex data pipelines can be built. (page 58, 2nd full paragraph).
US Patent Application Publications
Bramble 2022/0382620
In embodiments, the infrastructure 102 includes resources and services to process jobs associated with data pipelines. As illustrated, the infrastructure 102 may support any number of data pipelines 104 and jobs associated with those data pipelines 104. In embodiments, a data pipeline 104 may include jobs to process data produced by applications, devices, or humans. The data pipelines 104 further include processes that control and enable data flow between two or more systems. For example, data pipelines 104 include a set of instructions that determine how and when to move data between these systems. A data pipeline may integrate data from multiple sources or data storage for processing by a system and perform data quality checks or standardize data. A data pipeline may also apply data security-related transformations, including masking, anonymizing, or encryption, conduct match, merge, master, and make entity resolution, and sharing data with partners and customers in the required format. Consumers of a data pipeline may include data warehouses like Redshift, Snowflake, SQL data warehouses, or Teradata, reporting tools like Tableau or Power BI, and other applications in the case of application integration or application migration. Consumers may also include Data lakes on Amazon S3, Microsoft ADLS, or Hadoop—typically for further exploration, artificial intelligence algorithms, and temporary repositories or publish/subscribe queues like Kafka for consumption by a downstream data pipeline. Embodiments are not limited to these examples. In embodiments, the infrastructure 102 and data pipelines 104 may be controlled and monitored by a central system or one or more servers, such as orchestrator 106. For example, the orchestrator 106 may manage interconnections and interactions among jobs or workloads on the infrastructure 102. The orchestrator 106 may connect automated tasks into a cohesive job to accomplish a goal and produce a result, with permissions oversight and policy enforcement. (paras 0024-0025). In embodiments, the orchestrator 106 may be configured with one or more programs or services 206 that may be used to control and monitor the infrastructure 102 and data pipelines 104. For example, the services 206 may include commands or instructions to determine a status of a pipeline (GET PIPELINE STATUS), initiate a pipeline (PUT PIPELINE START), and configure the data pipelines 104 to provide status events (POST SEND STATUS EVENTS). Each of these services may be targeted and include an identifier of a particular data pipeline or may be broadcasted and communicated to all of the data pipelines 104. For example, the orchestrator 106 may initiate one or more of the services 206 to get a status of a particular pipeline by using the GET PIPELINE STATUS service and include an identifier to identify the particular pipeline. The identifier may include a name of the data pipeline, an address or subnet for the data pipeline, a job or workload identifier, a process identifier, and so forth. In another example, the orchestrator 106 may issue the POST SEND STATUS EVENTS command to get the status of all of the data pipelines 104 by broadcasting the command to all of the data pipelines 104 using a broadcast address or identifier. (para 0029).
Rajanna 2023/0385266
In a particular embodiment, a workflow pattern 120 can specify one or more input locations such as the source data 102; an input type for each of the one or more input locations; one or more data transformations or other processing logic; one or more output locations such as sink data 106 or a destination stream; an output type for each of the one or more input locations; a processing engine 112 to invoke; and one or more parameter values that identify and/or control how the process engine executes an element of a pipeline represented in the workflow pattern. Parameter values can be implemented using configuration strings. Two or more workflow patterns 120 can comprise a pipeline, or a single workflow pattern can define multiple transformations of a pipeline. The processing logic can be programmed or expressed in a general-purpose programming language and embedded in the workflow pattern 120 for parsing or interpretation at process engine 112. In some embodiments, natural language descriptions can be used to create data pipelines; in an embodiment, a workflow pattern could specify one or more natural language phrases, such as “ingest to data lake” and “land to redshift,” with specified inputs, output locations and process logic. TABLE 1 illustrates an example workflow pattern 120, and the APPENDIX to this specification provides other examples (para 0051).
Rajanna 2023/0385285
Embodiments provide computer-implemented processes and algorithms by which an end user can define a data pipeline using a descriptive language. Embodiments provide a platform-as-a-service solution to allow users with data engineering requests to efficiently create new data pipelines responsive to the request. Or, data engineers can more quickly and efficiently define data pipelines by focusing primarily on operational issues rather than engineering. With both approaches, development time and testing cycles can be dramatically reduced. A centralized platform capable of self-service to allow developers and non-developers to create data pipelines using a descriptive language can substantially reduce the software development lifecycle and open pipeline definition to a broader class of users who lack specialized engineering education or experience. (para 0022). In a particular embodiment, a workflow pattern 120 can specify one or more input locations such as the source data 102; an input type for each of the one or more input locations; one or more data transformations or other processing logic; one or more output locations such as sink data 106 or a destination stream; an output type for each of the one or more input locations; a processing engine 112 to invoke; and one or more parameter values that identify and/or control how the process engine executes an element of a pipeline represented in the workflow pattern. Parameter values can be implemented using configuration strings. Two or more workflow patterns 120 can comprise a pipeline, or a single workflow pattern can define multiple transformations of a pipeline. The processing logic can be programmed or expressed in a general-purpose programming language and embedded in the workflow pattern 120 for parsing or interpretation at process engine 112. In some embodiments, natural language descriptions can be used to create data pipelines; in an embodiment, a workflow pattern could specify one or more natural language phrases, such as “ingest to data lake” and “land to redshift,” with specified inputs, output locations and process logic. TABLE 1 illustrates an example workflow pattern 120 (para 0048).
US Patents
Thomas 12,423,615
A user can use the developer and computer environment 102 to create a pipeline workflow 104. In an embodiment, the pipeline workflow 104 is an ML pipeline workflow 104, often referred to herein as simply an ML pipeline. The ML pipeline 104 can be created using a programming language, to thereby provide a programmatically defined workflow structure. In an embodiment, the programming language provides a first representation of the ML pipeline 104. In yet another embodiment, the programming language provides a programmatic structure of the ML pipeline 104. In at least one embodiment, the developer and computer environment 102 comprises one or more templates that can be used to generate the ML pipeline workflow 104. For example, there can be a template for creating an ML pipeline that deploys a model. There can also be a template for creating an ML pipeline that trains model. In addition, in at least one embodiment, there is a template for creating an ML pipeline that trains a model and deploys the model. Each of the templates can provide pre-generated computer code that can be modified by a user that will code and debug a prepared ML pipeline. (col. 5 lines 37-57).
Wang 11,500,865
Multiple stage filtering may be implemented for natural language query processing pipelines. Natural language queries may be received at a natural language query processing system and processed through a query language processing pipeline. The query language processing pipeline may filter candidate linkages for a natural language query before performing further filtering of the candidate linkages in the natural language query processing pipeline as part of generating an intermediate representation used to execute the natural language query. (Abstract). Moreover, natural language query processing pipeline 130 may support translating the intermediate representation generated by natural language query processing pipeline 130 into different versions for different execution systems, to allow support for natural language query processing across multiple data set storage systems, in some embodiments. For example, natural language query processing pipeline 130 could be implemented as a front-end system or interface for database systems, file systems, or various other back-end storage systems which could support the operations specified in a natural language query to return a result as an intermediate representation 134 could be translated into that back-end storage system to be executed. (col. 3 lines 43-55).
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
April 2, 2026
Prosecution Insights