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 .
DETAILED ACTION
The Action is responsive to the Amendments and Remarks filed on 10/30/2025. Claims 1-30 are pending claims. Claims 1, 11, and 21 are written in independent form.
Priority
Applicant's claim for benefit of prior-filed provisional applications 63/498,916 under 35. U.S.C. 119(e) or under 35 U.S.C. 120, 121, or 365(c) is acknowledged.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 10, 20, and 30 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. Dependent Claims 10, 20, and 30 contain subject matter “wherein the feature registry stores, for each feature, metadata including an upstream lineage to source data and a downstream lineage to models or endpoints using the feature” which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
It is not clearly stated in the written description any reference to the feature registry storing upstream or downstream metadata.It is noted that while Applicant states in the Remarks dated 10/30/2025 that “Support for the claim amendments is found at, e.g., paragraphs [0042-0044], [0136], [0174- 0185], and [0202-0204] of the as-filed specification. Therefore, no new matter has been introduced by the claim amendments”, the cited paragraphs do not even recite the terms “upstream” or “downstream” or any variation of the terms. The Specification further does not even mention the term “downstream”, or any variation, at all, and only mentions the term “upstream” a single time in Para. [00161]) but not within the context of storing upstream metadata in the feature registry, as is being claimed.For purposes of compact prosecution, the claim limitation is being interpreted as “wherein the feature registry stores, for each feature, metadata” in light of Paragraph [00103] of the Specification reciting “a feature registry 518 (e.g., to store feature metadata)”.
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.
Claim(s) 1-5, 10-15, 20-25, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Neill (U.S. Pre-Grant Publication No. 2021/0374143) and further in view of Non-Patent Literature Galavan, Dan, "Snowflake in a Nutshell - The Snowpipe Streaming API & Dynamic Tables", Snowflake Builders Blog: Data Engineers, App Developers, AI/ML, & Data Science, Nov 10, 2022 (herein after referred to as Galavan) and Parkhe et al. (U.S. Pre-Grant Publication No. 2022/0374457, hereinafter referred to as Parkhe).
Regarding Claim 1:
Neill teaches a system comprising:
At least one hardware processor (Neill – Paras. [0041]-[0042]); and
At least one memory storing instructions that cause the at least one hardware processor to perform operations (Neill – Paras. [0041]-[0042]) comprising:
Obtaining, at a second computing node of the NBDS, decoded raw data based on raw data from a data source, the decoded raw data comprising streaming data and batch data;
Neill teaches that the “incoming messages are ingested by a pool or set of interfaces (e.g., transport listener processes) and transformed into individual data elements through a parallel disassembly processing network that extracts the data elements from incoming message payloads” (Para. [0014]) thereby teaching decoding the raw data, and thus receiving/obtaining the decoded raw data based on/after the decoding.
Neill further teaches “one or more listener processes…accept either real-time streaming data or interactive batch data from the adaptive window module 104 or multi-source dynamic ingestion module(s) 102 respectively” (Para. [0137]) thereby teaching that the obtained decoded raw data, as a whole, comprising pieces of “real-time streaming data or interactive batch data”.Neill teaches multiple nodes of a network-based database system (NBDS) by teaching “The overall structure can include as an undirected graph implemented as a graph database” (Para. [0009]) where “he general graph includes nodes/vertices and edges that are either directed or undirected.” (Para. [0181]) and a graph database is understood as being a network-based database system.
Performing an incremental computation of features associated with the decoded raw data;
Neill teaches “an external data source, one or more third-party connectors 103 provide similar functionality to the module 102 and are configured to incrementally process data for specialized or unique integration requirements” (Par. [0089]).
Performing an automatic refresh of the features based on detecting an inconsistency between historical feature values and real-time feature values in new streaming data or new batch data in the decoded raw data;
Neill teaches “The adaptive window module 104 configured to process real-time streaming data… As each new message or dataset arrives, the adaptive window module 104 determines (e.g., based on a weighting probability function), whether the new dataset is to be included in the reservoir” (Para. [0131]) thereby teaching an automatic refresh of the reservoir, and thus the features, based on detecting the new message or dataset.Neill further teaches detecting inconsistencies between historical and the real-time stream data by determining “whether the new dataset is to be included in the reservoir” using a “weighted probability function” which is understood as making the comparison of the new dataset to historical data. (Para. [0131]).
Executing a time-travel query to backfill the historic results using historic raw data;
Neill teaches “Another advantage enabled by the data processing system is simultaneously processing real-time streaming of multi-dimensional data, previously stored multi-dimensional data, and predicted future state or predicted multi-dimensional target variables in a fully unified and transparent manner.” (Para. [0018]) thereby teaching backfilling the historic results using historic/previously stored raw/multi-dimensional data based on a time-travel query which, given its broadest reasonable interpretation, is merely understood as accessing previously stored time-related data.
Performing training of a machine learning model using the features in the feature store, to generate a trained machine learning model; and
Neill teaches “the data processing system performs predictive machine learning (ML) methods utilizing the ingested data and system as training data to improve said heuristic and ML methods” (Para. [0077]) thereby teaching generating a trained ML model using the ingested feature data as training data.
Processing an inferencing request using the features and the trained machine learning model to generate a prediction associated with the inferencing request.
Neill teaches “the data processing system performs predictive machine learning (ML) methods utilizing the ingested data and system as training data to improve said heuristic and ML methods” (Para. [0077]) where “the definitions are inferred or learned from data-streams themselves (e.g., by heuristic processor 718) in conjunction with the ingestion, ETL labeling, and query inputs” (Para. [0172]). Therefore, Neill teaches processing an inference request using a trained ML method which generates a prediction/result associated with the inferencing request.
Neill explicitly teaches all of the elements of the claimed invention as recited above except:
Configuring a feature registry based on a plurality of feature definitions for a corresponding plurality of features,
the plurality of feature definitions received via a first user interface associated with a first application programming interface (API) executing at a first computing node of a network-based database system (NBDS);
Performing an incremental computation of features associated with the decoded raw data using a directed acyclic graph (DAG) of at least one dynamic table object and the feature registry;
Pushing the features to a latest feature storage of a feature store using at least one triggered task, the feature store comprising a historical feature storage accumulating historic results of the incremental computation; and
Controlling retrieval of a result of the incremental computation from the latest feature storage of the feature store by at least a third computing node, based on a second API executing at the third computing node.
However, in the related field of endeavor of processing streaming data, Galavan teaches:
Performing an incremental computation of features associated with the decoded raw data using a directed acyclic graph (DAG) of at least one dynamic table object and the feature registry; and
Galavan teaches “Dynamic Tables (formerly known as Materialized Tables) are used to joinDynamic Taband transform streaming data as it flows into and through the SnowflakeData Cloud” (Page 5). Galavan further teaches doing this “with e.g. reference data which is already on the platform” (Page 5).Neill teaches “In some implementations, a CPS-G includes one or more compact pattern streams (CPS) represented and embedded within a general graph topology, or complete graph, that includes Directed Acyclic Graph (DAG), or other graph topology structures that may be directed, undirected, with or without cycles” (Para. [0009]).
Therefore, Galavan and Neill together teach using a directed acyclic graph (DAG) of a dynamic table object and a feature registry as at least reference data already on the platform.
Pushing the features to a latest feature storage of a feature store using at least one triggered task, the feature store comprising a historical feature storage accumulating historic results of the incremental computation;
Galavan teaches “The Snowpipe Streaming API pushes streaming data directly to Snowflake tables, and Dynamic tables can then be used to join and aggregate the data as it streams into Snowflake” (Page 8) and “we can use the Snowflake Snowpipe Streaming API to load streaming data rowsets into Snowflake database tables. The streaming data rowsets can be consumed from various types of data stream publishers” (Page 2).Neill teaches “In addition to efficient storage and access to streaming datasets, the CPS-G enables the implementation of dynamic virtual data model structures (subsequently referred to as CPS-G slices). CPS-G slices can include a CPG-G generated from specified sub-graphs of nodes organized for efficient access or graph data processing that represent a specified subset of data of interest over dynamically configurable time-period windows, spatial domains, or other entities or feature sets of interest for implementing any of the use-case application scenarios previously described” (Para. [0012]) and “Each incoming dataset fills a time window or reservoir to a fixed sample size (e.g., of dataset elements)” where “As each new message or dataset arrives, the adaptive window module 104 determines (e.g., based on a weighting probability function), whether the new dataset is to be included in the reservoir” (Para. [0131]) thereby teaching a latest feature storage as the latest time-period window and further comprising historical/past feature storage in past time-period windows.Therefore, Galavan in combination with Neill teaches pushing the features to a latest feature storage/window of a feature storage using at least one triggered task, the feature store comprising a historical feature storage/window accumulating historic results/past windows of the incremental computation.
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Galavan and Neill at the time that the claimed invention was effectively filed, to have combined the use of Dynamic tables, as taught by Galavan, with the systems and methods for real-time processing of data streams, as taught by Neill.
One would have been motivated to make such combination because Galavan teaches “as we have seen, the up and coming Snowpipe Streaming API and Dynamic Tables will make it easier to consume the query streaming data” (Page 8).
Galavan and Neill explicitly teach all of the elements of the claimed invention as recited above except:
Configuring a feature registry based on a plurality of feature definitions for a corresponding plurality of features,
the plurality of feature definitions received via a first user interface associated with a first application programming interface (API) executing at a first computing node of a network-based database system (NBDS);
Controlling retrieval of a result of the incremental computation from the latest feature storage of the feature store by at least a third computing node, based on a second API executing at the third computing node.
However, in the related field of endeavor of a feature store with integrated tracking, Parkhe teaches:
Configuring a feature registry based on a plurality of feature definitions for a corresponding plurality of features,
Parkhe teaches “an administrator uses administrator system 140…to define and manage features and access to features at feature store service 110” (Para. [0032]) where “user interface module 250 configures one or more user interfaces via which a user controls or manages features (e.g., updating of features, creation of new features, etc.)” (Para. [0042]) and “the feature(s) are stored in feature store 422. For example, the feature is stored in a feature registry 424 of feature store 422” (Para. [0054]).
the plurality of feature definitions received via a first user interface associated with a first application programming interface (API) executing at a first computing node of a network-based database system (NBDS);
Parkhe teaches “user interface module 250 configures one or more user interfaces via which a user controls or manages features (e.g., updating of features, creation of new features, etc.)” (Para. [0042]).
Neill teaches “a computer program can be deployed for execution on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.” (Para. [0222]) where “the data processing system is also configured to access data through API structures” thereby teaching using multiple computing nodes of a network-based database system and multiple APIs executing on multiple computing nodes.
Therefore, Parkhe and Neill in combination teach receiving the plurality of feature definitions for creation of new features via an interface (Parkhe) associated with an API executing on a computing node of a network-based database system (Neill)
Controlling retrieval of a result of the incremental computation from the latest feature storage of the feature store by at least a third computing node, based on a second API executing at the third computing node.
Parkhe teaches “execute one or more queries with respect to features stored in the feature store” and “provides a set of results to a query (e.g., a set of features responsive to the query) to the user such as via user interface module 250 and/or communication module 225.” (Para. [0039]) where “a feature comprised in feature 320 is determined (e.g., computed) using one or more datasets comprised in raw data 310.” (Para. [0048]). Parkhe further teaches “The information pertaining to the feature comprises information indicating a status of a feature, an upstream lineage of a feature, a downstream lineage of a feature, a development history of the feature, an access history of the feature, a version history of the feature, etc. The feature metadata 270 comprises the one or more characteristics of a feature.” (Para. [0043]). Therefore, Parkhe teaches controlling retrieval of the latest feature results of the incremental computation from the feature store.
Neill teaches “a computer program can be deployed for execution on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.” (Para. [0222]) where “the data processing system is also configured to access data through API structures” thereby teaching using multiple computing nodes of a network-based database system and multiple APIs executing on multiple computing nodes.
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Parkhe, Galavan and Neill at the time that the claimed invention was effectively filed, to have combined the feature registry, as taught by Parkhe, with the use of Dynamic tables, as taught by Galavan, and the systems and methods for real-time processing of data streams, as taught by Neill.
One would have been motivated to make such combination because Parkhe teaches “storing the upstream lineage and/or the downstream linage in association with the corresponding feature improves the extent of information available to feature developers and feature adopters. For example, a feature developer can use information provided by the feature store to assess characteristics pertaining to the adoption of a particular feature by downstream endpoints or model, and such information can be used in connection with improving or updating the feature” (Para. [0023]).
Regarding Claim 2:
Parkhe, Galavan and Neill further teach:
Decoding the streaming data as a plurality of streaming data rows received from the data source via a streaming API.
Galavan teaches “load[ing] streaming data rowsets into Snowflake database tables. The streaming data rowsets can be consumed from various types of data stream publishers” (Page 2) where “streaming data rowsets can be automatically processed by calling the Snowflake Streaming API…Ap calls can be configured using the Java based Snowflake Ingest SDK” and “Snowpipe processes data from stages files…Snowpipe consume files from an external AWS S3 state” (Page 3).
Regarding Claim 3:
Parkhe, Galavan and Neill further teach:
Ingesting the plurality of streaming data rows in a staging table of the network-based database system, using ingesting code of the streaming API; and
Galavan teaches “load[ing] streaming data rowsets into Snowflake database tables. The streaming data rowsets can be consumed from various types of data stream publishers” (Page 2) where “streaming data rowsets can be automatically processed by calling the Snowflake Streaming API…Ap calls can be configured using the Java based Snowflake Ingest SDK” and “Snowpipe processes data from stages files…Snowpipe consume files from an external AWS S3 state” (Page 3).
Ingesting the batch data in the staging table from data files, the batch data received via an ingestion pipe of the network-based database system.
Galavan teaches “load[ing] streaming data rowsets into Snowflake database tables. The streaming data rowsets can be consumed from various types of data stream publishers” (Page 2) where “streaming data rowsets can be automatically processed by calling the Snowflake Streaming API…Ap calls can be configured using the Java based Snowflake Ingest SDK” and “Snowpipe processes data from stages files…Snowpipe consume files from an external AWS S3 state” (Page 3).
Regarding Claim 4:
Parkhe, Galavan and Neill further teach:
Configuring the streaming API as an API executing at an account of a user of the network-based database system.
Galavan teaches “We can use the Snowflake Snowpipe Streaming API to load streaming data rowsets into Snowflake database tables. The streaming data rowsets can be consumed from various types of data stream publishers.” (Page 2) and “Data streams can be published as topics. A topic is a log of events (e.g. website clicks), and provies a one-way data flow from the publisher to one or many subscribers” (Page 3).
Regarding Claim 5:
Parkhe, Galavan and Neill further teach:
Detecting availability of the streaming data rows at the account of the user of the network-based database system using the streaming API.
Neill teaches “the interactive model is based on a request-response model with push or pull where the client must ask a server process for a message explicitly” (Para. [0130]) thereby teaching detecting availability by a client using push or pull dynamics.
Regarding Claim 10:
Parkhe, Galavan and Neill further teach:
Wherein the feature registry stores, for each feature, metadata.
Parkhe teaches “feature store 550 comprises one or more characteristics of a feature (e.g., metadata associated with a feature)” (Para. [0062]).Parkhe further teaches “Feature tracking module 240 monitors for changes in the source data used with respect to a feature (e.g., as a feature is modified to use a different dataset, feature tracking module 240 determines that such a modification). In response to detecting that a change occurs with respect to the source data associated with (e.g. used as an input to) a feature, feature tracking module 240 updates metadata pertaining to an upstream lineage of the feature. Feature tracking module 240 monitors for changes in downstream applications of a feature. For example, feature tracking module 240 monitors for use of the feature such as by a model or endpoint (e.g., information pertaining to a source of a model, use of a model, etc.).” (Para. [0040]).
Regarding Claim 11:
All of the limitations herein are similar to some or all of the limitations of Claim 1.
Regarding Claim 12:
All of the limitations herein are similar to some or all of the limitations of Claim 2.
Regarding Claim 13:
All of the limitations herein are similar to some or all of the limitations of Claim 3.
Regarding Claim 14:
All of the limitations herein are similar to some or all of the limitations of Claim 4.
Regarding Claim 15:
All of the limitations herein are similar to some or all of the limitations of Claim 5.
Regarding Claim 20:
All of the limitations herein are similar to some or all of the limitations of Claim 10.
Regarding Claim 21:
Some of the limitations herein are similar to some or all of the limitations of Claim 1.
Galavan and Neill further teach:
A computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations (Neill – Paras. [0041]-[0042]).
Regarding Claim 22:
All of the limitations herein are similar to some or all of the limitations of Claim 2.
Regarding Claim 23:
All of the limitations herein are similar to some or all of the limitations of Claim 3.
Regarding Claim 24:
All of the limitations herein are similar to some or all of the limitations of Claim 4.
Regarding Claim 25:
All of the limitations herein are similar to some or all of the limitations of Claim 5.
Regarding Claim 30:
All of the limitations herein are similar to some or all of the limitations of Claim 10.
Claim(s) 6, 16, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Parkhe, Neill, and Galavan, and further in view of Akidau et al. (U.S. Patent No. 11,250,006, hereinafter referred to as Akidau).
Regarding Claim 6:
Parkhe, Neill and Galavan explicitly teach all of the elements of the claimed invention as recited above except:
Ingesting the plurality of streaming data rows in the staging table using a plurality of communication channels configured as logically named streaming connections of the network-based database system.
However, in the related field of endeavor of real-time streaming data ingestion into database tables, Akidau teaches:
Ingesting the plurality of streaming data rows in the staging table using a plurality of communication channels configured as logically named streaming connections of the network-based database system.
Akidau teaches “the client 402 may open one or more channels to the data system. A channel may be a logical connection to a particular table stored in the data system, such as in the database 410. The data system, e.g., in the database 410, may include a plurality of tables associated with an account for the client 402.” (Col. 10 Lines 48-57).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Akidau, Parkhe, Galavan, and Neill at the time that the claimed invention was effectively filed, to have combined the use of opening one or more channels by a client, as taught by Akidau, with the feature registry, as taught by Parkhe, the Dynamic tables, as taught by Galavan, and the systems and methods for real-time processing of data streams, as taught by Neill.
One would have been motivated to make such combination because Akidau teaches a “job optimizer 208 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the job” (Col 6 Lines 34-45).
Regarding Claim 16:
All of the limitations herein are similar to some or all of the limitations of Claim 6.
Regarding Claim 26:
All of the limitations herein are similar to some or all of the limitations of Claim 6.
Claim(s) 7-9,17-19, and 27-29 are rejected under 35 U.S.C. 103 as being unpatentable over Parkhe, Neill, and Galavan, and further in view of Cruanes et al. (U.S. Pre-Grant Publication No. 2020/0133937, hereinafter referred to as Cruanes).
Regarding Claim 7:
Parkhe, Neill and Galavan explicitly teach all of the elements of the claimed invention as recited above except:
Applying one or more transform operations to the staging table to generate the at least one dynamic table object.
However, in the related field of endeavor of incrementally refreshing a materialized view, Cruanes teaches:
Applying one or more transform operations to the staging table to generate the at least one dynamic table object.
It is noted that the limitation recites intended use language of “…to generate…” and is therefore not being given patentable weight. The scope of the limitation is understood as reciting “applying one or more transform operations to the staging table”. However, for purposes of compact prosecution, the limitation is being addressed below as if the intended use language was recited in a positive step.
Cruanes teaches a source table 402 undergoes a linear transformation to generate a plurality of micro-partitions…The plurality of micro partitions may generate a single micro-partition of the materialized view 404” (Para. [0059]) where “the micro-partitions of the source table constitute immutable storage objects in a database storage system” (Para. [0113]).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Cruanes, Parkhe, Galavan, and Neill at the time that the claimed invention was effectively filed, to have combined the application of transformations to generate immutable storage objects, as taught by Cruanes, with the feature registry, as taught by Parkhe, the Dynamic tables, as taught by Galavan, and the systems and methods for real-time processing of data streams, as taught by Neill.
One would have been motivated to make such combination because Cruanes teaches a “improving query performance by incrementally refreshing materialized views to ensure the materialized views are up-to-date and can provide accurate information to be used when responding to queries” (Para. [0021]).
Regarding Claim 8:
Cruanes, Galavan, and Neill further teach:
Detecting, using the at least one dynamic table object, new streaming data in the one or more source tables storing the plurality of streaming data rows.
Cruanes teaches “means for scanning the merged table to detect one or more impacted rows comprising one or more of: the new row inserted to the source table that is not present in the materialized view; or an absence of the deleted row removed from the source table that is still present in the materialized view.” (Para. [0111]) where “the update detection component 106 may detect whether any updates have occurred on the source table that are not reflected in the materialized view” (Para. [0038]).
Regarding Claim 9:
Cruanes, Galavan, and Neill further teach:
Performing a refresh of the at least one dynamic table object based on the detecting of the new streaming data.
Cruanes teaches “automatic incremental refreshing of a materialized view associated with a database source table. For example, the MV generation component 102 may generate a materialized view based on a source table. The merging component 104 may update the materialized view and the source table such that the update detection component 106 may detect whether any updates have occurred on the source table that are not reflected in the materialized view. The refresh component 108 may refresh the materialized view by adding a new row that has been added to the source table since a prior refresh of the source table. The compaction component 110 may remove a row from the materialized view that corresponds to a deleted row that was removed from the source table since a prior compaction of the source table. The statistics component 112 may generate statistics about the source table, the materialized view, and the incremental refreshing of the materialized view.” (Para. [0038]).
Regarding Claim 17:
All of the limitations herein are similar to some or all of the limitations of Claim 7.
Regarding Claim 18:
All of the limitations herein are similar to some or all of the limitations of Claim 8.
Regarding Claim 19:
All of the limitations herein are similar to some or all of the limitations of Claim 9.
Regarding Claim 27:
All of the limitations herein are similar to some or all of the limitations of Claim 7.
Regarding Claim 28:
All of the limitations herein are similar to some or all of the limitations of Claim 8.
Regarding Claim 29:
All of the limitations herein are similar to some or all of the limitations of Claim 9.
Response to Amendment
Applicant’s Amendments, filed on 10/30/2025, are acknowledged and accepted.
In light of pages 10-11 of the Remarks filed on 10/30/2025, the 35 USC 101 rejection of claims 1-2, 11-12, and 21-22 for being directed to non-statutory subject matter have been withdrawn. In particular, Applicant incorporated all of claims 10, 20, and 30, which were not previously rejected under 35 USC 101, into their respective parent claims 1, 11, and 21.
Response to Arguments
On pages 12-13 of the Remarks filed on 10/30/2024, Applicant argues that in reference to “configuring a feature registry”, Parkhe, and Neill, alone or “even when considered in combination, do not teach or suggest the recited functionality of configuring a feature registry based on a plurality of feature definitions for a corresponding plurality of features, where the plurality of feature definitions are received via a first user interface associated with a first API executing at a first computing node of a network-based database system.” because “Parkhe's disclosure is limited to general feature management and metadata storage, without addressing the architectural or operational specifics required by the claim.” and “Neill's disclosure is limited to the general concept of distributed software deployment and does not address the process of receiving feature definitions through a user interface/API at a specific node, nor the configuration of a feature registry in this context.”After further consideration of the references and Applicant’s argument, applicant’s argument was not found to be convincing because while Applicant states that “Parkhe does not address the architectural details or the distributed, node-based receipt and registration of feature definitions as recited” and Neill “does not address the specific process of receiving feature definitions through a user interface/API combination at a particular node, nor does it describe the configuration or operation of a feature registry in this context” but it is noted that Neill (Paras. [0222] & [0229]) was relied upon as teaching the argued architectural deficiency of Parkhe and Parkhe (Paras. [0032], [0042], and [0054]) teaches the argued deficiency of Neill as the process of receiving feature definitions and feature registry configuration.
On page 13 of the Remarks filed on 10/30/2025, Applicant argues that in reference to “performing an incremental computation”, “the cited portions of Galavan describe dynamic tables for joining and transforming streaming data, but do not teach or suggest the use of a directed acyclic graph (DAG) of dynamic table objects, nor the integration of a feature registry in the computation pipeline.” And “The cited portions of Neill discuss incremental processing, but not in the context of DAG orchestration or dynamic tables.”After further consideration of the references and Applicant’s argument related to the amended limitation, applicant’s argument was not found to be convincing and the amended limitation is further addressed in the rejection above.
On page 14 of the Remarks filed on 10/30/2025, Applicant argues that in reference to “performing an automatic refresh”, “the cited portion of Neill describes automatic refresh of a reservoir based on the arrival of new data, but does not teach or suggest detecting an inconsistency between historical feature values and real-time feature values, nor does it disclose using such an inconsistency as a trigger for refresh.”
After further consideration of the references and Applicant’s argument related to the amended limitation, applicant’s argument was not found to be convincing and the amended limitation is further addressed in the rejection above.
On page 14 of the Remarks filed on 10/30/2025, Applicant argues that in reference to “pushing the features of a latest feature storage”, Galavan and Neill “do not teach or suggest pushing features to a latest feature storage using triggered tasks, nor do they disclose a feature store architecture with both latest and historical storage accumulating incremental computation results” because “Galavan is limited to streaming data ingestion and aggregation, without triggered task orchestration or explicit feature store partitioning.” and “The cited portions of Neill discuss time-windowed storage, but this type of storage is not described as a feature store with triggered task-based updates”.After further consideration of the references and Applicant’s argument, applicant’s argument was not found to be convincing because Neill (Paras. [0012] & [0131]) and Galavan (Pages 2 and 8) were found to teach the argued limitation. It is further noted that the claim limitation recites “pushing…using at least one triggered task” but does not recite the scope of “triggered task-based updates” as is presented in the argument.
On page 14 of the Remarks filed on 10/30/2025, Applicant merely states that “The cited portion of Neill describes unified processing of real-time and previously stored data, but does not teach or suggest controlling retrieval from a latest feature storage and executing a time-travel query to backfill historic results using historic raw data, nor does it disclose the use of a second API at a third computing node for this purpose.”After further consideration of the references and Applicant’s statement, applicant’s statement was not found to be convincing or agreed that Neill does not teach, suggest, or disclose the stated feature(s).
On page 15 of the Remarks filed on 10/30/2025, Applicant argues that “Neill, Galavan, and Parkhe (taken individually or in combination) do not teach or suggest "the feature registry stores, for each feature, metadata including an upstream lineage to source data and a downstream lineage to models or endpoints using the feature," as recited by [amended] dependent claims 10, 20, and 30” because “Parkhe's paragraph [0043] describes storing metadata such as status, upstream lineage, downstream lineage, and version history for features. However, Parkhe does not teach or suggest a feature registry that, for each feature, stores both upstream lineage to source data and downstream lineage to models or endpoints using the feature as an integral part of the registry's configuration and operation. Parkhe's disclosure is limited to the existence of metadata fields and does not address the dynamic, automated tracking and storage of lineage for each feature as required by the claim.”After further consideration of the references and Applicant’s argument related to the amended limitation, applicant’s argument was not found to be convincing and the amended limitation is further addressed in the rejection above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thunoli et al. (U.S. Pre-Grant Publication No. 2018/0253669) teaches a method and system for creating a dynamic canonical data model. The method includes creating staging tables to analyze regulatory data collected from a plurality of heterogeneous sources. The method further includes creating a dynamic canonical ontology based on the staging tables representing the regulatory data. The dynamic canonical ontology determines a plurality of attributes associated with the regulatory data and relationships amongst the plurality of attributes. The method includes identifying automatically at least one modification associated with at least one of the plurality of attributes by applying machine learning techniques on the staging tables. The method further includes updating the dynamic canonical ontology by adding the at least one modification to create the dynamic canonical data model.
Duncan et al. (U.S. Pre-Grant Publication No. 2004/0059744) teaches a staging repository includes a message queue table corresponding to a data source to store a message queue transmitted from the data source. A mapping table corresponding to the data source stores relationship information between data fields of the message queue and data fields of at least one schema table. A core program generator retrieves the message queue stored in the message queue table and automatically generates program code in real-time based on the relationship information stored in the mapping table, the fields that are populated in the specific message being processed, and (optionally) an event code included in the message. The program code parses data to be extracted from the data fields of the message queue. A normalized staging schema stores the data extracted by the core program generator into the at least one schema table.
Tidwell et al. (U.S. Pre-Grant Publication No. 2011/0110515) teaches collection and processing of data relating to users of a content-delivery network. In one embodiment, the content delivery network is a cable or satellite or HFCu network, and the apparatus includes an architecture for routinely harvesting, parsing, processing, and storing data relating to the activities of the users (e.g., subscribers) of the network. In one variant, at least portions of the data are anonymized to protect subscriber privacy.
Harada (U.S. Patent No. 11,327,994) teaches an information processing device includes an acquiring unit, a shaping unit, and an integration unit. The acquiring unit is configured to acquire operation history information from plural systems, respectively. The shaping unit is configured to shape each operation history information acquired by the acquiring unit into operation history information in a unified format. The integration unit is configured to arrange and integrate the operation history information after being shaped by the shaping unit in chronological order.
Hoh et al. (U.S. Pre-Grant Publication No. 2021/0373914) teaches a “hand-off” operation of a feature management platform. A feature management platform can receive a request to generate feature data based on batch and streaming data. To generate such feature data, a “hand-off” occurs between a batch processing job to a stream processing job. The feature management platform can initiate the batch processing job to generate a first set of feature data. Once all of the feature data is generated by the batch processing job, the feature data is saved in an offline database. The feature data with the maximum timestamp is saved in an online database, and the maximum timestamp is saved in a persistent database. With the maximum timestamp, the feature management platform begins the stream processing job. Once feature data is generated by the stream processing job, the feature data is stored in an offline or online database.The reference further teaches “the feature management platform 102 can include feature processing component 104, a feature queue 106, an internal state 108, a workflow scheduler 110, a feature registry 112, a compliance service 114, an aggregated state 116, a fast retrieval database 118, a training data database 120, metric data 122, data sources 124, and persistent data 126.” (Para. [0040]).
Kotecha et al. (U.S. Pre-Grant Publication No. 2023/0244644) teaches embodiments map a source schema to a target schema using a feature store. Embodiments receive a file including a plurality of source schema elements and a plurality of target schema elements, the file including a plurality of unmapped elements. Embodiments retrieve rule based mappings for the unmapped elements between the source schema elements and the target schema elements. Based on semantic matching of the source schema elements, embodiments retrieve feature store based mappings from the feature store for the unmapped elements between the source schema elements and the target schema elements. Embodiments then generate one or more similarity scores for mappings of the source schema elements to the target schema elements.
Non-Patent Literature Pienaar et al, "What Is A Feature Store?", Jan. 21, 2021, <https://feast.dev/blog/what-is-a-feature-store/> (Year: 2021) teaches a comprehensive guide to feature stores, their role in machine learning operations, and how they solve key challenges in the ML lifecycle.
Wisniewski et al. (U.S. Pre-Grant Publication No. 2021/0374600) teaches techniques for operation of a feature management platform. A feature management platform is an end-to-end platform developed to manage the full lifecycle of data features. For example, to create a feature the feature management platform can receive a processing artifact (e.g., a configuration file and code fragment) from a computing device. The processing artifact defines the feature, including the data source to retrieve event data from, when to retrieve the event data, the type of transform to apply, etc. Based on the processing artifact, the feature management system generates a processing job, which when initiated generates a vector that encapsulates the feature data. The vector is transmitted to the computing device that locally hosts a model, which generates a prediction. The prediction is transmitted to the feature management platform and can be transmitted to other computing devices, upon request.The reference further teaches “the feature management platform updates the feature registry and feature store of the feature management platform, based on the prediction received. For example, the metadata of the prediction can be included in a feature registry while the value(s) of the prediction are included in a feature store (e.g., a fast retrieval database and/or a training data database).” (Para. [0107]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT F MAY whose telephone number is (571)272-3195. The examiner can normally be reached Monday-Friday 9:30am to 6pm.
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, Boris Gorney can be reached on 571-270-5626. 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.
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154
/ROBERT F MAY/Examiner, Art Unit 2154 11/26/2025