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 .
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the YAML declaration file" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 14 recites the limitation "the data governance operation" in line 1. There is insufficient antecedent basis for this limitation in the claim.
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.
Claim(s) 1-5, 7-10, 13, 14, 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsirogiannis etal. (hereinafter Tsirogiannis) (US 20140279838 A1)1.
As to claim 1, Tsirogiannis teaches a method comprising the steps of:
at a server comprising a processor, a memory, and a network interface device connected to a network [FIG. 1D: processor 204, nonvolatile storage 216 and networking card 228],
receiving a declaration file [0080: “infer unified semi-structured (such as JSON) schema from the data,”] comprising:
a fields section defining a database table, including data attributes [0086: “A schema describes the possible structures and data types found in a data collection. This schema includes the names of the fields, the types for the corresponding values, and the nesting relationships.”];
converting the declaration file into a set of intermediate representations to produce logical representations of a data pipeline, wherein the conversion enforces data quality rules [0409: “One common transformation is to convert values from one type to another… These casting directives can either be manually specified using foreknowledge of the data or can be automatically inferred using statistics collected during schema inference.”];
generating, using the configuration section of the declaration file and the logical representation, a data pipeline comprising extracted, transformed, and loaded data from a data source into the database table [0418: “An example ETL process may be segmented into the following components: detecting new data (D); extracting data from source (S); inferring schema of source (I); optionally loading index store (L); generating cumulative schema (G); generate alter table statements (A); optionally exporting data in intermediate format (E); and copying data to destination (C).”];
deploying the data pipeline to a data processing platform for data ingestion [0417: “Individual components of an ETL process can be scheduled and executed in a distributed computing environment--either in the cloud or inside a private data center… The status of each stage of the pipeline may be stored in a metadata service to support recovery, statistics, and lineage.”];
receiving one or more jobs or workflows for execution against the generated data pipeline [0331: “A scheduling module 1544 assigns jobs to the data collector module 1512, the schema inference and statistics collection module 1516, the index store 1520, and the export module 1534. The scheduling module 1544 may schedule the jobs based on dependencies described in more detail below with respect to FIGS. 16A-16B.”]; and
executing the jobs or workflows [0331].
Tsirogiannis does not teach a configuration section defining data processing actions on the database table.
However, Tsirogiannis describes several data processing actions done by the platform [0080: “The analysis platform takes the following actions in response to data appearing in a source: (1) infer unified semi-structured (such as JSON) schema from the data, (2) create a relational view for the schema, (3) populate physical indexes with data, and (4) execute queries that leverage the indexes. Parts or all of actions 1, 2, and 3 may be pipelined to allow only a single pass through the data from the data source.”].
It would have been obvious to one of ordinary skill in the art to incorporate the data processing action to be part of the configuration section of a declaration file to achieve the same without altering functionality of the system.
As to claim 2, Tsirogiannis teaches wherein the YAML declaration file is in YAML, JSON, or XML format [0083: “There are generalizations of JSON to include more types, e.g., BSON (Binary JSON). Moreover, other semi-structured formats like XML (Extensible Markup Language), Protobuf, Thrift, etc. can all be converted to JSON.”] [0080: “infer unified semi-structured (such as JSON) schema from the data,”].
As to claim 3, Tsirogiannis teaches the method of claim 1, further comprising configuring the data pipeline to support both streaming and scheduled batch jobs [0433: “The tasks can be parallelized internally. Additionally, provided that their dependencies are met, they can also be issued asynchronously via a job scheduling system (e.g., PBS, LSF, YARN, MESOS, etc.).”].
As to claim 4, Tsirogiannis teaches wherein the data pipeline is generated to process data from multiple heterogeneous data source [0332: “We now expand the definition of an input source to the ETL process to cover object sources. These sources can include NoSQL stores, document stores such as MongoDB and Couchbase, data structure stores such as Redis, and key/multi-value stores such as Cassandra, HBase, and DynamoDB. Objects stored inside files on a file store can be treated as additional object sources. Objects stored in files can include JSON, BSON, Protobuf, Avro, Thrift, and XML.”].
As to claim 5, Tsirogiannis teaches wherein data quality is enforced at the conversion step by validating field attributes, including data type and nullability [0359: “Type polymorphism occurs when the same attribute appears multiple times in the source data with different types. The schema inference mechanism and index store described above fully support type polymorphism”] [0104: “A null type is similarly replaced by an observed type. For example, the records { "geo": null } { "geo": true } will produce the schema: {"geo": boolean}”].
As to claim 7, Tsirogiannis teaches wherein the configuration section includes a custom function for indexing, such as a row number transformation [0397; “When moving data from one datastore to another, it may be desirable to be able to trace the lineage of each datum as it moves through the system. As an example, consider a collection of files containing JSON records with each record separated by newlines. The data from those files may be loaded into the index store, and, from the index store, loaded into a data warehouse. To maintain the lineage of the records, each record can be tracked by, for example, recording the source filename and line number of each record. The lineage information can be stored in the index store as an extra column (or set of columns).”].
As to claim 8, Tsirogiannis teaches the method of claim 1, further comprising provisioning and tuning a cluster computing system based on data source metadata and the declaration file [0267: “The data objects and the schema generated by the schema inference module 312 are provided to an adornment module 316 as well as an index creation module 320. Input objects include source data as well as metadata that describes the source data. The source data is stored in index storage 324 by the index creation module 320.”].
Claims 9 and 17, Tsirogiannis teaches wherein the logical representations include definitions for identification of downstream impacts of data attribute changes, including type conversions and wherein the pipeline is configured to handle schema evolution by automatically adapting to changes in field definitions [0038: “prior to repeating the exporting, determining whether the cumulative schema has changed since a previous exporting and, in response to determining that the cumulative schema has changed, sending at least one command to the data warehouse to update a schema of the data warehouse to reflect the changes to the cumulative schema.”].
As to claim 10, Tsirogiannis teaches the method of claim 1, further comprising pushing the generated data structure to a data catalog using a push architecture [0219].
As to claim 13, Tsirogiannis teaches the method of claim 1, further comprising enabling a graphical user interface for pipeline configuration, wherein the interface allows users to visually define pipeline steps [0036].
As to claim 14, Tsirogiannis teaches wherein the data governance operations include generating audit reports for data quality compliance [0439] [0356][0436].
As to claim 16, Tsirogiannis teaches the method of claim 1, further comprising applying merge statements for integrating new data sources into the pipeline [0219].
As to claim 18, Tsirogiannis teaches wherein the generated data pipeline optionally includes a versioning mechanism to track revisions to field definitions over time [0407: “Another method for handling updates is to take the records/objects from the input and convert them into different versions of the records/objects based on some key and the transaction time recorded in the transaction register. The converted records/objects can then be appended to the index store as new records. If the destination store is temporal, then AS OF queries can be used to make queries in the past.”].
As to claim 19, it relates to system claim comprising the similar subject matters claimed in claim 1. Therefore, it is rejected under the same reasons applied to claim 1.
As to claim 20, it relates to computer-readable storage medium comprising the similar subject matters claimed in claim 1. Therefore, it is rejected under the same reasons applied to claim 1.
Claim(s) 6, 11 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsirogiannis et al. (hereinafter Tsirogiannis) (US 20140279838 A1) in view of Kannan et al. (hereinafter Kannan) (US 12086153 B1).
As to claims 6, 11 and 15, Tsirogiannis does not teach utilizing a machine learning module or LLM to optimize pipeline configuration based on the declaration file and runtime metrics, and wherein the pipeline includes a data modeling step, comprising generating transformation logic and determining field definitions using a large language model (LLM).
Kannan teaches utilizing machine learning for optimization, and data modeling in ETL machine learning pipelines [col. 2, line 34 – col. 3, line 4: “ ETL-based ML algorithms (‘ETL ML algorithms’) may be trained on a training dataset comprising a training input portion and a training output portion… When trained on training datasets manifesting ETL processes, ETL ML algorithms may draw relations between data items within the training input portion and data items within the training output portion. These relations may reflect extrapolated ETL processes based on patterns within the manifested ETL processes. The ETL ML algorithm may generate an ETL ML model comprising these drawn relations and the extrapolated ETL processes they reflect.”].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching utilizing machine learning as suggested in Kannan into Tsirogiannis to optimize pipeline configuration. One having ordinary skill in the art would have been motivated to make such modification to reduce human effort and increase productivity for large datasets.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsirogiannis et al. (hereinafter Tsirogiannis) (US 20140279838 A1) in view of Zhou et al. (hereinafter Zhou) (US 20210150665 A1).
As to claim 12, Tsirogiannis does not teach masking personally identifiable information before writing to a target database.
Zhou teaches sensible data, like personally identifiable information, can be masked before storing [0034: : Sensitive data, such as financial information and personal identification information, can be encrypted before transmission and storage to protect confidentiality and/or privacy.”].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of encrypting personal identification information as suggested in Zhou into Tsirogiannis to implement data management. One having ordinary skill in the art would have been motivated to make such modification to improve data security.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to XUXING CHEN whose telephone number is (571)270-3486. The examiner can normally be reached M-F 9-5:30PM.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/XUXING CHEN/Primary Examiner, Art Unit 2176
1 Tsirogiannis was cited in the IDS filed on 06/22/2026.
Prosecution Insights