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 .
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, 3, 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over David Tchankotadze et al. (hereinafter Tchankotadze) (US 20230297878 A1, 2023-09-21) in view of Sandeep Narendra Gutpa et al. (hereinafter Gupta) (US 20240362196 A1, 2024-10-31), further in view of Simon Harrison (hereinafter Harrison) (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of Charles Cella et al. (herein after Cella) (US 20220191282 A1, 2022-06-16), further in view of Tyler Moeller et al. (hereinafter Moeller) (US 20060069702 A1, 2006-03-30), further in view of Ze-xin Ruan (hereinafter Ruan) (CN 113591130 A, 2021-11-02).
Regarding claim 1, Tchankotadze teaches;
access a feature store that stores data associated with a plurality of possible machine learning model features;
([Abstract] The method further includes using the metadata to determine the one or more features or feature sets for specified data and storing the one or more determined features or feature sets in a feature store. In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The feature store stores values of features or feature sets, where some of the features or feature sets are accessed by at least one machine learning model. Thus, the stored data of the feature store is associated with a plurality of possible machine learning features, which is accessed by machine learning models.
receive, from the feature store, a set of values associated with a composite feature
([0043] Once stored features 308 are available in the data store 302, various features and feature sets can be evaluated by personnel, such as by querying the data store 302 via an API or other mechanism and receiving selected features 308 from the data store 302. The selected features 308 identified for evaluation (or a portion of the data associated with the selected features 308) may be exported, such as to one or more machine learning models represented as clients 310 of the data store 302.)
NOTE: Teaches receiving (the client machine learning model receives the selected features), from the feature store (from the data store of the feature store), a set of values associated with a composite feature (the set of values of the selected features, which can be composite features, explained in the next limitation), by pushing model data (the features to be utilized by the model) to clients (the features are pushed/exported to the client machine learning models).
Reasoning as to why it would be obvious to receive this data using the claimed protocol will be explained further on.
wherein the composite feature is a secondary or higher feature based on one or more primary features calculated at the feature store;
PNG
media_image1.png
661
468
media_image1.png
Greyscale
NOTE: Fig. 3 details the feature store architecture. The in-memory transformations are performed in the feature store.
([0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312. These features or feature sets can similarly be materialized for storage as features 308 in the data store 302 or for storage in the feature cache 316 (for low latency processing).)
NOTE: Teaches that the feature store can generate transformed/composite features based on primary features (the primary features being the production data in this excerpt). These transformed/composite features are then stored in the feature store as features. Thus, any of the features accessed from the feature store can be composite features.
execute a machine learning model using the set of values associated with the composite feature to obtain the machine learning prediction using a result of executing the machine learning model using the set of values associated with the composite feature;
([0017] A feature may be said to be “materialized” when a transformed value for that feature is stored directly (rather than evaluating feature transformations on source data each time the data is used). A “feature store” refers to a centralized repository or other repository of materialized feature data… [0018] Feature stores routinely include two separate data storages, namely an offline storage and an online storage. The online storage is generally used for storing data related to inferencing to be performed using trained machine learning models (often referred to as “production data”))
NOTE: Teaches executing a machine learning model using the set of values associated with the composite feature to obtain the machine learning prediction because the feature values of the feature store (which includes the aforementioned transformed /composite features) are used to execute machine learning models to perform inference/prediction.
Tchankotadze fails to teach but Gupta teaches;
A device for machine learning model prediction, comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the device to: receive a request for a machine learning prediction;
[AltContent: textbox (Fig. 17)]
PNG
media_image2.png
556
495
media_image2.png
Greyscale
([0205] Further, while only a single machine 1700 is illustrated, the term “machine” shall also be taken to include a collection of machines 1700 that individually or jointly execute the instructions 1716 to perform any one or more of the methodologies discussed herein.)
NOTE: Teaches that any of the methodologies discussed in the disclosure can be implemented using one or more machines 1700, where a machine 1700 includes one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the device to performed the associated method.
([0136] inferencing service 620 uses the trained ML model 622 and features from the feature store 616 to process an inferencing request 612 and generate a prediction 624.)
NOTE: One of the disclosed methods is receiving a machine learning prediction request to be processed using an ML model, which can be implemented using the aforementioned machine 1700. Thus, Gupta teaches a device comprising: one or more memories; and one or more processors, coupled to the one or more memories (as pictured in fig. 17), configured to cause the device to receive a request for a machine learning prediction (the hardware-based ML model receives an inference request to generate a prediction).
OBVIOUSNESS TO COMBINE GUPTA:
Tchankotadze is analogous art to the present disclosure as it discloses a feature store which generates composite features, and Gupta is analogous art to the present disclosure as it discloses devices configured to receive and execute prediction requests from a data store using machine learning models. Tchankotadze already teaches client machine learning models receiving and processing composite feature data from a feature store to generate predictions. Gupta teaches devices that receive inference/prediction requests, and process feature data received from a feature store using machine learning to generate predictions. One of ordinary skill in the art, before the effective filing date of the claimed invention, would have been motivated to implement the client models of Tachankotadze using the devices of Gupta to allow for the client models to receive specific prediction requests from external sources, to guide subsequent processing of composite features received from the feature store, further improving flexibility of the system.
Tchankotadze and Gupta fail to teach but Harrison teaches;
using a protocol associated with pushing … data to subscribed client devices,
([pg. 3] The Protocol describes how your application components first contact the router (Hello) then register procedures (Register), subscribe to Topics (Subscribe), send Messages (Call and Publish), receive Messages (Invocation and Event) and then detach from the Router (GoodBye). This is done with WAMP Messages.)
NOTE: WAMP is a protocol which allows subscribed client applications to receive data from a topic of interest via messages, which teaches a protocol associated with pushing data to subscribed client devices. When used in the context of the present disclosure, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use WAMP to allow clients (the aforementioned models/devices) to subscribe to a data source of the feature store to receive model data (such as composite feature values to be processed by the models/devices), further explained below;
OBVIOUSNESS TO COMBINE HARRISON:
Harrison is analogous art to present disclosure as it pertains to a WebSockets protocol capable of transmitting remote procedure calls between applications. As preciously taught, Tchankotadze as modified by Gupta teaches client devices that access data from a feature store. Harrison teaches a protocol for processing communications such as establishing subscriptions between applications and sending data to subscribed client devices. Gupta further states that the hardware configuration of the devices include a network having coupling capable of performing any long-range protocols or data transfer technologies, thus, WAMP is compatible with the hardware disclosed by Gupta; “[0212] network 1780 or a portion of network 1780 may include a wireless or cellular network, and coupling 1782 may be a [various examples of couplings]. In this example, the coupling 1782 may implement any of a variety of types of data transfer technology, such as… other long-range protocols, or other data transfer technology.” Additionally, Harrison discloses that WAMP has many out of the box advantages; “[pg. 5] There are some advantages you get out of the box with WAMP; WAMP decouples every application you write, WAMP is language and framework agnostic, WebSockets are not the only transport this is bound to; WAMP supports many auth patterns; you get load balancing for free.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use WAMP to handle data communications and subscriptions between the feature store and the client machine learning model devices of the system because WAMP allows for decoupled messaging, language- and framework-agnostic integration, flexible authentication patterns, and built-in routing/load balancing, which improves scalability, interoperability, security, and maintainability of the system.
Tchankotadze, Gupta, and Harrison fail to teach but Cella teaches;
and output the machine learning prediction to permit the machine learning prediction to be used to perform one or more actions.
([0014] inputting the feature vector to the machine-learned model to obtain a prediction… [0252] In the event a potential issue is predicted or classified, the data processing module 522 may execute a workflow associated with the potential issue. A workflow may define the manner by which a potential issue is handled. For instance, the workflow may indicate that a notification should be transmitted to a human user, a remedial action should be initiated, and/or other suitable actions.)
NOTE: Teaches outputting the machine learning prediction (‘in the event an issue is predicted’ indicates a machine learning prediction output) to permit the machine learning prediction to be used to perform one or more actions (in response to the prediction, actions such as sending a notification to a user may be taken).
OBVIOUSNESS TO COMBINE CELLA: Cella is analogous art to the present disclosure as it involves transforming and transmitting data to be processed by machine learning systems to generate predictions. Tchankotadze and Gupta already teach generating predictions using machine learning models of the devices. Cella teaches using a machine learning prediction to guide further actions to be taken. Cella explains that, based on a potential issue identified by the machine learning model prediction, remedial action can be taken to remedy the issue; ([0252] In the event a potential issue is predicted or classified, the data processing module 522 may execute a workflow associated with the potential issue. A workflow may define the manner by which a potential issue is handled. For instance, the workflow may indicate that a notification should be transmitted to a human user, a remedial action should be initiated, and/or other suitable actions). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use predictions output by the models of the devices to perform downstream actions to remedy issues identified by the predictions.
Tchankotadze, Gupta, Harrison, and Cella fail to teach but Moeller teaches;
wherein to access
([0269] Remote Procedure Calls With Updates … [0282] The procedure can return data to the caller. Data is returned as a set of objects in the same way data is returned as a set of results from a query. Data objects of the return type are returned to the procedure caller as a list of data objects just as objects matching a data query are returned as a list of objects. A procedure's return results can be objects that already exist in the system or new objects.)
NOTE: Teaches performing a remote procedure call to generate a new data object at the system, because the data objects returned by the RPC can be new objects, meaning they were generated as a result of the RPC.
OBVIOUSNESS TO COMBINE MOELLER:
Moeller is analogous art to the present disclosure as it pertains to the generation of data objects using remote procedure calls. Tchankotadze teaches a feature store which generates data objects (the aforementioned transformed/composite features). Moeller provides a method for performing a remote procedure call to generate a new data object. Additionally, Moeller indicates that the benefit of using the RPC is that it lets the system generate/retrieve the needed data on demand instead of precomputing or continuously maintaining every possible data set for every possible consumer; ([0270] In addition to queries, the system also supports remote procedure call capabilities to retrieve data. Applications that wish to provide on-demand services to the system register "procedures" or "services" with the system. A procedure can be registered through a call on the client library's API. The client library in turn can send a procedure registration message to a management server, which creates a data object that contains information about the procedure, such as its name, the parameters (data object types) that can be provided to the procedure when invoking it, and where the procedure (which application) is located). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to access the feature store by using remote procedure calls to generate new data as needed, rather than having to precompute or continuously maintain every possible data set for every possible consumer.
Tchankotadze, Gupta, Harrison, Cella, and Moeller fail to teach but Ruan teaches; new data object having the device subscribed as a client, (taught by Tchankotadze)
([Ruan pg. 11-12] wherein the electronic device establishing long connection between the service client end can be through the stream (grpcstream, can continuously push data, grpc is high performance RPC (Remote Procedure Call, remote procedure call) frame; … when the publisher (electronic device) has a new subscribed service block generation; the service data in the service block is pushed to the subscriber (service client))
NOTE: Teaches a publisher generating a new data object (the data of the newly generated service block) having a device subscribed as a client (the service block is subscribed to by the client), where the client device receives a set of values associated with the new data object (the data/values of the new service block is pushed to the client device).
OBVIOUSNESS TO COMBINE RUAN:
Ruan is analogous art to the present disclosure as it pertains to a data processing method utilizing remote procedure calls to push data to subscribed devices. Tchankotadze already provides a feature store which generates new data objects (the aforementioned transformed/composite features) which are then sent to client devices (machine learning models). Moeller provides a method for performing a remote procedure call to generate a new data object. Ruan further provides a method for pushing values of generated data objects to subscribed client devices. Ruan further states that because the connection stays open, the server can keep pushing newly generated service data to the client as soon as it becomes available, and the client does not need to repeatedly establish and disconnect connections for each update, which reduces connection establishment and disconnection overhead; ([pg. 12] based on long connection, it can ensure the continuous sending of the real-time service data, and reduces the connection establishment and disconnection overhead, can improve the processing performance of the electronic device. Therefore, the electronic device can be represented as the RPC Server, correspondingly, the service client device can be represented as the RPC Client). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the feature-store access using the real-time RPC subscription mechanism of Ruan to allow the feature store to push newly generated composite features to the subscribed clients as soon as they become available, reducing repeated connection establishment and disconnecting overhead.
Regarding claim 3, Tchankotadze teaches;
wherein the feature store is implemented as a plurality of compute nodes across a plurality of server devices.
([0026] FIG. 1 illustrates an example system 100 supporting a metadata-driven feature store according to this disclosure. For example, the system 100 shown here can be used to support a metadata-driven feature store that is used to store metadata related to features or feature sets to be processed by one or more machine learning models as described in more detail below. As shown in FIG. 1, the system 100 includes user devices 102a-102d, one or more networks 104, one or more application servers 106, and one or more database servers 108 associated with one or more databases 110 and/or one or more file servers 111.)
NOTE: Teaches the feature store being implemented as a plurality of compute nodes (ML models, user devices, databases, etc.) across a plurality of server devices (application servers, database servers, file servers, etc.).
Regarding claim 5, Tchankotadze teaches;
([Abstract] In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The aforementioned device/model accesses one or more resources (values of features and feature sets) associated with the feature store.
Tchankotadze and Gupta fail to teach but Harrison teaches;
transmit a remote procedure call (RPC) using a WebSockets protocol
([pg. 2-3] WAMP is a WebSockets sub-protocol... exchange messages using WAMP’s two communication patterns: routed Remote Procedure Calls and Publish and Subscribe.)
NOTE: Harrison teaches WAMP, which is a WebSockets protocol capable of transmitting a remote procedure call.
OBVIOUSNESS:
Using the same reasoning from claim 1.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of Cella (US 20220191282 A1, 2022-06-16), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 1 above, and further in view of Bouadi Mohamed (hereinafter Mohamed) (EP 4198831 A1, 2023-06-21).
Regarding claim 2, Tachankotadze teaches;
A remote feature store
([0030] For example, the system 100 may be coupled to at least one external network 114, such as the Internet. This may allow at least one metadata-driven feature store for the organization associated with the system 100 to be created by a remote server 116…)
Tachankotadze, Gupta, Harrison, Cella, Moeller, and Ruan fail to teach but Mohamed teaches;
wherein the composite feature is based on an output of a
([Abstract] Systems, methods, and computer-readable media for performing feature engineering on a dataset for predictive modeling are disclosed. A dataset may comprise a plurality of features that are used for the predictive model. The dataset may be fed to a neural network to determine which features have the greatest impact on the predictive model and which features do not positively impact the predictive model. A deep reinforcement learning agent may select an action to perform on the dataset. The action may be applied to the dataset to generate new features and obtain a transformed dataset.)
NOTE: Teaches composite features (transformed features of the dataset can be considered composite features, as the transformed dataset / features are higher features based on the original dataset / features) based on an output of a machine learning model (the output of the neural network and deep learning reinforcement agent determine the action / transformation to be applied to the dataset / features).
Reasoning as to why it would have been obvious to include this model at the remote feature store of Tachankotadze will be explained below.
OBVIOUSNESS TO COMBINE MOHAMED:
Mohamad is analogous art to the present disclosure as it pertains to predictive modeling using composite / transformed data. Tachankotadze already teaches transforming feature data at the remote feature store architecture to generate transformed / composite features to be used for machine learning predictions; “[Tachankotadze, 0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312.” Mohamad provides a means for determining transformations to feature data based on the output of a machine learning model, then using the transformed data for machine learning prediction. Additionally, Mohamad teaches selecting the best transformation to be applied to the feature data, i.e., selecting the transformation which will improve the predictive model the most; “[0033] Deep reinforcement learning may provide a reward for state transformations that improve the predictive model. A cumulative reward may be maximized thus providing a set of features that maximizes the improvement in predictive models.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the neural network and deep reinforcement learning agent of Mohamed in the remote feature store of Tachankotadze to use the output to select the best transformations to be applied to the features, predictably resulting in composite features that maximize the improvement of the client predictive models.
Claim(s) 4, 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of Cella (US 20220191282 A1, 2022-06-16), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 1 above, and further in view of Sasmito Adibowo (hereinafter Adibowo) (US11461300B2, 2021-10-04).
Regarding claim 4, Tchankotadze teaches;
and access the features store via a server device, of the plurality of server devices, associated with the compute node.
([0028] In some cases, the data of each metadata-driven feature store may be physically stored in the database 110 and accessed via the database server 108 and/or physically stored in the file server 111… [0053] transformed data (features 308) retrieved from the feature store 308 by clients 310)
NOTE: The feature store is accessed via a server device (database server), of a plurality of server devices (file server, database server). Each of the compute nodes (clients) access the feature store, which is associated with the server device. Thus, any compute node is associated with the server device.
Tachankotadze, Gupta, Harrison, Cella, Moeller, Ruan fail to teach but Adibowo teaches;
select a compute node, of the plurality of compute nodes, with a particular configuration based on a characteristic of the request for the machine learning prediction;
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request)… [col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis).)
NOTE: Adibowo teaches selecting a compute node, of the plurality of compute nodes (selects an ML model of a plurality of ML models), with a particular configuration (each of the ML models is configured to perform a request-specific task), based on a characteristic of the request for the machine learning prediction (the selection is based on the type of the inference/prediction request, which can be considered a characteristic of the request)
OBVIOUSNESS TO COMBINE ADIBOWO:
Adibowo is analogous art to the present disclosure because they disclose processing inference requests using machine learning models over a plurality of server devices and compute nodes. Tchankotadze teaches a feature store 300, having machine learning models represented as clients 310, which can be considered compute nodes of the aforementioned plurality of compute nodes of the feature store configured to access the feature store and generate predictions;
PNG
media_image3.png
636
877
media_image3.png
Greyscale
([0038] FIG. 3 illustrates an example architecture 300 supporting a metadata-driven feature store according to this disclosure… [0043] one or more machine learning models represented as clients 310 of the data store 302.) Adibowo teaches a server system for selecting a machine learning model of a plurality of machine learning models based on a prediction request. Additionally, Adibowo indicates that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request; “[col. 1, ln. 9-16] ML models can be configured in the respective artificial neural networks (ANN) in order to solve a certain well-defined problem. Because the customers would have their specific set of problems to solve, the ML model of one customer might not be able to solve problem of another customer.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the method of Adibowo to select a compute node (client model of Tchankotadze) to access the feature store that has a configuration most suited for answering a prediction request based on a characteristic of the request (request type), predictably providing the compute node that is best suited for processing the request.
Regarding claim 6, Tachankotadze, Gupta, Harrison, Cella, Moeller, and Ruan fail to teach but Adibowo teaches;
wherein the request for the machine learning prediction is directed to the [model] based on a characteristic of the request for the machine learning prediction,
([col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis)
NOTE: Teaches the machine learning prediction / inference request being directed to the model (the prediction / inference request is directed to the selected ML model / device) based on a characteristic of the request for the machine learning model (the selection is made based on the type of inference request, where the type can be considered a characteristic of the request).
wherein the [model] is included in a set of [models] that is configured to process requests associated with different characteristics.
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request).)
NOTE: Teaches the ML model included in a set of models (the inference platform comprises of a plurality of specific ML models) that is configured to process request associated with different characteristics (the ML models are request-specific, indicating that they are configured to process requests associated with different characteristics / types).
OBVIOUSNESS:
Tchankotadze teaches a plurality of client machine learning models configured to process prediction requests. Gupta teaches receiving and processing a machine learning request at a device. Adibowo teaches a server system selecting a machine learning model of a plurality of machine learning models based on a prediction request. Adibowo further teaches (as stated in claim 4) that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the process of Adibowo select a device (client model device, as taught by Tchankotadze as modified by Gutpa) of a set of devices based on a characteristic of the prediction request, to direct the request to the device that is best suited for processing the request.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of Cella (US 20220191282 A1, 2022-06-16), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 1 above, and further in view of Kaushal Gandhi et al. (hereinafter Gandhi) (US 20240348263 A1, 2024-10-17).
Regarding claim 7, Tchankotadze fails to teach but Gupta teaches;
and wherein the one or more processors, when configured to cause the device to execute the machine learning model, are configured to cause the device to:
PNG
media_image2.png
556
495
media_image2.png
Greyscale
([0136] inferencing service 620 uses the trained ML model 622 and features from the feature store 616 to process an inferencing request 612 and generate a prediction … [0205] Further, while only a single machine 1700 is illustrated, the term “machine” shall also be taken to include a collection of machines 1700 that individually or jointly execute the instructions 1716 to perform any one or more of the methodologies discussed herein.)
NOTE: The machine 1700 which has one or more processors, (see fig. 17 above) is configured to at least execute any operation of the machine learning model.
Tachankotadze, Gupta, Harrison, Cella, Moeller, Ruan fail to teach but Gandhi teaches;
reconstruct the set of values using a reconstruction instruction received in connection with the set of values;
([fig. 3] transmit the compressed data from the off-chip memory to an on-chip memory of the processing array, decompress the compressed data based on metadata stored in association with the compressed data and the lookup table)
NOTE: Teaches reconstructing the set of values (decompressing compressed data) using a reconstruction instruction (decompress based on the metadata, which can be considered a decompression/reconstruction instruction since it guides the process) received in connection with the set of values (the metadata is stored in association with the compressed data).
execute the machine learning model using the reconstruction of the set of values.
([fig. 3] execute the machine learning model based on the decompressed data and with the processing array)
NOTE: Teaches executing the machine learning model using the reconstructed (decompressed) set of values.
OBVIOUSNESS TO COMBINE GANDHI:
Gandhi is analogous art to the present disclosure as it pertains to reconstructing decompressed data to be used for machine learning analysis. Tchankotadze teaches a method of receiving feature data from a feature store to be used for machine learning prediction and Gandhi teaches a method of decompressing compressed data received from a data store to be used for machine learning prediction. Additionally, Gandhi indicates that the benefit of compressing data in memory is that is reduces usage of compute resources and power; “[0026] The second data (the compressed data) may be stored in the memory to reduce a memory footprint of the data relative to uncompressed data (e.g., the first data), reduce compute resources and power. In doing so, the number of evictions and fetches is reduced to lessen the latency and compute resources while still maintaining accuracy.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to compress the data in the feature store to save resources, then reconstruct / decompress the data when it is needed by the machine learning models.
Claim(s) 8, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02).
Regarding claim 8, Tchankotadze teaches;
accessing, by the
([Abstract] The method further includes using the metadata to determine the one or more features or feature sets for specified data and storing the one or more determined features or feature sets in a feature store. In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The feature store stores values of features or feature sets, where some of the features or feature sets are accessed by at least one machine learning model. Thus, the stored data of the feature store is associated with a plurality of possible machine learning features, and the feature store is accessed by machine learning models.
receiving, by the
([0043] Once stored features 308 are available in the data store 302, various features and feature sets can be evaluated by personnel, such as by querying the data store 302 via an API or other mechanism and receiving selected features 308 from the data store 302. The selected features 308 identified for evaluation (or a portion of the data associated with the selected features 308) may be exported, such as to one or more machine learning models represented as clients 310 of the data store 302.)
NOTE: Teaches receiving, by the ML model (client machine learning models receive the features) and from the feature store (the features are exported from the feature store) in connection with the client models, a set of values associated with the composite feature (said features are associated with composite features, further explained in the following limitation).
wherein the composite feature is a secondary or higher feature based on one or more primary features calculated at the feature store;
PNG
media_image1.png
661
468
media_image1.png
Greyscale
NOTE: Fig. 3 details the feature store architecture. The in-memory transformations are performed in the feature store.
([0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312. These features or feature sets can similarly be materialized for storage as features 308 in the data store 302 or for storage in the feature cache 316 (for low latency processing).)
NOTE: Teaches that the feature store can generate transformed/composite features based on primary features (the primary features being the production data in this excerpt). These transformed/composite features are then stored in the feature store as features. Thus, any of the features accessed from the feature store can be composite features.
executing,
([0017] A feature may be said to be “materialized” when a transformed value for that feature is stored directly (rather than evaluating feature transformations on source data each time the data is used). A “feature store” refers to a centralized repository or other repository of materialized feature data… [0018] Feature stores routinely include two separate data storages, namely an offline storage and an online storage. The online storage is generally used for storing data related to inferencing to be performed using trained machine learning models (often referred to as “production data”))
NOTE: Teaches executing a machine learning model using the set of values associated with the composite feature (the transformed/composite data of the feature store is used to execute the machine learning models for inferencing); and outputting a machine learning prediction based on a result of executing the machine learning model using the set of values associated with the composite feature (executing the machine learning models on the composite features of the feature store outputs an inference / prediction).
Tchankotadze fails to teach but Gutpa teaches;
A method of machine learning model prediction, comprising: receiving, by a device, a request for a machine learning prediction;
([0136] inferencing service 620 uses the trained ML model 622 and features from the feature store 616 to process an inferencing request 612 and generate a prediction 624.)
NOTE: Teaches a method of generating a machine learning model prediction, comprising receiving a request for a machine learning prediction.
([0205] Further, while only a single machine 1700 is illustrated, the term “machine” shall also be taken to include a collection of machines 1700 that individually or jointly execute the instructions 1716 to perform any one or more of the methodologies discussed herein.)
NOTE: Teaches the aforementioned prediction model being implemented on a device (machine 1700) capable of performing any disclosed methods. Thus, teaches the aforementioned receiving of the request being performed by a device (machine 1700) implementing a ML model.
OBVIOUSNESS:
Using the same reasoning from claim 1.
Tchankotadze and Gupta fail to teach but Moeller teaches;
([0269] Remote Procedure Calls With Updates … [0282] The procedure can return data to the caller. Data is returned as a set of objects in the same way data is returned as a set of results from a query. Data objects of the return type are returned to the procedure caller as a list of data objects just as objects matching a data query are returned as a list of objects. A procedure's return results can be objects that already exist in the system or new objects.)
NOTE: Teaches performing a remote procedure call to generate a new data object at the system, because the data objects returned by the RPC can be new objects, meaning they were generated as a result of the RPC.
OBVIOUSNESS TO COMBINE MOELLER:
Moeller is analogous art to the present disclosure as it pertains to the generation of data objects using remote procedure calls. Tchankotadze already provides a feature store which generates data objects (the aforementioned transformed/composite features). Moeller provides a method for performing a remote procedure call to generate a new data object. Additionally, Moeller indicates that the benefit of using the RPC is that it lets the system generate/retrieve the needed data on demand instead of precomputing or continuously maintaining every possible data set for every possible consumer; ([0270] In addition to queries, the system also supports remote procedure call capabilities to retrieve data. Applications that wish to provide on-demand services to the system register "procedures" or "services" with the system. A procedure can be registered through a call on the client library's API. The client library in turn can send a procedure registration message to a management server, which creates a data object that contains information about the procedure, such as its name, the parameters (data object types) that can be provided to the procedure when invoking it, and where the procedure (which application) is located). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to access the feature store by using remote procedure calls to generate new data as needed, rather than having to precompute or continuously maintain every possible data set for every possible consumer.
Tchankotadze, Gupta, and Moeller fail to teach but Ruan teaches; the new data object having the device subscribed as a client, wherein the set of values is associated with the new data object,
([pg. 11-12] wherein the electronic device establishing long connection between the service client end can be through the stream (grpcstream, can continuously push data, grpc is high performance RPC (Remote Procedure Call, remote procedure call) frame; … when the publisher (electronic device) has a new subscribed service block generation; the service data in the service block is pushed to the subscriber (service client))
NOTE: Teaches a publisher generating a new data object (the data of the newly generated service block) having a device subscribed as a client (the service block is subscribed to by the client), where the client device receives a set of values associated with the new data object (the data/values of the new service block is pushed to the client device).
OBVIOUSNESS TO COMBINE RUAN:
Ruan is analogous art to the present disclosure as it pertains to a data processing method utilizing remote procedure calls to push data to subscribed devices. Tchankotadze already provides a feature store which generates data objects (the aforementioned transformed/composite features) which are then sent to client devices (machine learning models). Moeller teaches a method for performing a remote procedure call to generate a new data object. Ruan further provides a method for pushing values of generated data objects to subscribed client devices. Ruan further states that because the connection stays open, the server can keep pushing newly generated service data to the client as soon as it becomes available. The client does not need to repeatedly establish and disconnect connections for each update, which reduces connection establishment and disconnection overhead; ([pg. 12] based on long connection, it can ensure the continuous sending of the real-time service data, and reduces the connection establishment and disconnection overhead, can improve the processing performance of the electronic device. Therefore, the electronic device can be represented as the RPC Server, correspondingly, the service client device can be represented as the RPC Client). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the feature-store access using the real-time RPC subscription mechanism of Ruan to allow the feature store to push newly generated composite features to the subscribed clients as soon as they become available, reducing repeated connection establishment and disconnecting overhead.
Accordingly, the combination reasonably teaches the entire limitation;
the new data object having the device subscribed as a client (Ruan), wherein the new data object is for a composite feature (Tchankotadze); receiving, by the device (Ruan) and from the feature store in connection with the device (Tchankotadze) being subscribed to the new data object as the client, a set of values (Ruan) associated with a composite feature (Tchankotadze), wherein the set of values is associated with the new data object (Ruan),
Regarding claim 10; Tachankotadze teaches;
wherein the feature store is implemented as a plurality of compute nodes across a plurality of server devices.
([0026] FIG. 1 illustrates an example system 100 supporting a metadata-driven feature store according to this disclosure. For example, the system 100 shown here can be used to support a metadata-driven feature store that is used to store metadata related to features or feature sets to be processed by one or more machine learning models as described in more detail below. As shown in FIG. 1, the system 100 includes user devices 102a-102d, one or more networks 104, one or more application servers 106, and one or more database servers 108 associated with one or more databases 110 and/or one or more file servers 111.)
NOTE: Teaches the feature store being implemented as a plurality of compute nodes (ML models, user devices, databases, etc.) across a plurality of server devices (application servers, database servers, file servers, etc.).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 8 above, and further in view of Mohamed (EP 4198831 A1, 2023-06-21).
Regarding claim 9, Tachankotadze teaches;
A remote feature store
([0030] For example, the system 100 may be coupled to at least one external network 114, such as the Internet. This may allow at least one metadata-driven feature store for the organization associated with the system 100 to be created by a remote server 116…)
Tchankotadze, Gupta, Moeller, and Ze-xin Ruan fail to teach but Mohamed teaches;
wherein the composite feature is based on an output of a
([Abstract] Systems, methods, and computer-readable media for performing feature engineering on a dataset for predictive modeling are disclosed. A dataset may comprise a plurality of features that are used for the predictive model. The dataset may be fed to a neural network to determine which features have the greatest impact on the predictive model and which features do not positively impact the predictive model. A deep reinforcement learning agent may select an action to perform on the dataset. The action may be applied to the dataset to generate new features and obtain a transformed dataset.)
NOTE: Teaches composite features (transformed features of the dataset can be considered composite features, as the transformed dataset / features are higher features based on the original dataset / features) based on an output of a machine learning model (the output of the neural network and deep learning reinforcement agent determine the action / transformation to be applied to the dataset / features).
OBVIOUSNESS TO COMBINE MOHAMED:
Mohamad is analogous art to the present disclosure as it pertains to predictive modeling using composite / transformed data. Tachankotadze already teaches transforming feature data at the remote feature store architecture to generate transformed / composite features to be used for machine learning predictions; “[Tachankotadze, 0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312.” Mohamad provides a means for determining transformations to feature data based on the output of a machine learning model, then using the transformed data for machine learning prediction. Additionally, Mohamad teaches selecting the best transformation to be applied to the feature data, i.e., selecting the transformation which will improve the predictive model the most; “[0033] Deep reinforcement learning may provide a reward for state transformations that improve the predictive model. A cumulative reward may be maximized thus providing a set of features that maximizes the improvement in predictive models.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the neural network and deep reinforcement learning agent of Mohamed in the remote feature store of Tachankotadze to use the output to select the best transformations to be applied to the features, predictably resulting in composite features that maximize the improvement of the client predictive models.
Claim(s) 11, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 8 and 10 above, and further in view of Adibowo (US11461300B2, 2021-10-04).
Regarding claim 11, Tchankotadze teaches;
and accessing a server device, of the plurality of server devices, associated with the compute node.
([0028] In some cases, the data of each metadata-driven feature store may be physically stored in the database 110 and accessed via the database server 108 and/or physically stored in the file server 111… [0053] transformed data (features 308) retrieved from the feature store 308 by clients 310)
NOTE: The feature store is accessed via a server device (database server), of a plurality of server devices (file server, database server). Each of the compute nodes (clients) access the feature store, which is associated with the server device. Thus, any compute node is associated with the server device.
Tchankotadze, Gupta, Moeller, and Ruan fail to teach but Adibowo teaches;
select a compute node, of the plurality of compute nodes, with a particular configuration based on a characteristic of the request for the machine learning prediction;
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request)… [col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis).)
NOTE: Adibowo teaches selecting a compute node, of the plurality of compute nodes (selects an ML model of a plurality of ML models), with a particular configuration (each of the ML models is configured to perform a request-specific task), based on a characteristic of the request for the machine learning prediction (the selection is based on the type of the inference/prediction request, which can be considered a characteristic of the request)
OBVIOUSNESS TO COMBINE ADIBOWO:
Adibowo is analogous art to the present disclosure because they disclose processing inference requests using machine learning models over a plurality of server devices and compute nodes. Tchankotadze teaches a feature store 300, having machine learning models represented as clients 310, which can be considered compute nodes of the aforementioned plurality of compute nodes of the feature store configured to access the feature store and generate predictions;
PNG
media_image3.png
636
877
media_image3.png
Greyscale
([0038] FIG. 3 illustrates an example architecture 300 supporting a metadata-driven feature store according to this disclosure… [0043] one or more machine learning models represented as clients 310 of the data store 302.) Adibowo teaches a server system for selecting a machine learning model of a plurality of machine learning models based on a prediction request. Additionally, Adibowo indicates that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request; “[col. 1, ln. 9-16] ML models can be configured in the respective artificial neural networks (ANN) in order to solve a certain well-defined problem. Because the customers would have their specific set of problems to solve, the ML model of one customer might not be able to solve problem of another customer.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the method of Adibowo to select a compute node (client model of Tchankotadze) to access the feature store that has a configuration most suited for answering a prediction request based on a characteristic of the request (request type), predictably providing the compute node that is best suited for processing the request.
Regarding claim 13, Tchankotadze, Gupta, Moeller, and Ruan fail to teach but Adibowo teaches;
wherein the request for the machine learning prediction is directed to the [model] based on a characteristic of the request for the machine learning prediction,
([col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis)
NOTE: Teaches the machine learning prediction / inference request being directed to the model (the prediction / inference request is directed to the selected ML model / device) based on a characteristic of the request for the machine learning model (the selection is made based on the type of inference request, where the type can be considered a characteristic of the request).
wherein the [model] is included in a set of [models] that is configured to process requests associated with different characteristics.
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request).)
NOTE: Teaches the ML model included in a set of models (the inference platform comprises of a plurality of specific ML models) that is configured to process request associated with different characteristics (the ML models are request-specific, indicating that they are configured to process requests associated with different characteristics / types).
OBVIOUSNESS:
Tchankotadze teaches a plurality of client machine learning models configured to process prediction requests. Gupta teaches receiving and processing a machine learning request at a device. Adibowo teaches a server system selecting a machine learning model of a plurality of machine learning models based on a prediction request. Adibowo further teaches (as stated in claim 4) that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the process of Adibowo select a device (client model device, as taught by Tchankotadze as modified by Gutpa) of a set of devices based on a characteristic of the prediction request, to direct the request to the device that is best suited for processing the request.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 8 above, and further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17)
Regarding claim 12, Tchankotadze teaches;
([Abstract] In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The aforementioned client models accesses one or more resources (values of features and feature sets) associated with the feature store.
Tchankotadze, Gupta, Moeller, and Ruan fail to teach but Harrison teaches;
transmitting a remote procedure call (RPC) using a WebSockets protocol
([pg. 2-3] WAMP is a WebSockets sub-protocol... To use WAMP, your applications need a Router with a Realm (a routing namespace) to connect to and then they can exchange messages using WAMP’s two communication patterns: routed Remote Procedure Calls and Publish and Subscribe.)
NOTE: Harrison teaches WAMP, which is a WebSockets protocol capable of transmitting remote procedure calls for facilitating communication between devices.
OBVIOUSNESS:
As preciously taught, Tchankotadze as modified by Gupta teaches client devices that access data from a feature store. Harrison teaches a protocol for processing communications such as establishing subscriptions between applications and sending data to subscribed client devices. Gupta further states that the hardware configuration of the devices include a network having coupling capable of performing any long-range protocols or data transfer technologies, thus, WAMP is compatible with the hardware disclosed by Gupta; “[0212] network 1780 or a portion of network 1780 may include a wireless or cellular network, and coupling 1782 may be a [various examples of couplings]. In this example, the coupling 1782 may implement any of a variety of types of data transfer technology, such as… other long-range protocols, or other data transfer technology.” Additionally, Harrison discloses that WAMP has many out of the box advantages; “[pg. 5] There are some advantages you get out of the box with WAMP; WAMP decouples every application you write, WAMP is language and framework agnostic, WebSockets are not the only transport this is bound to; WAMP supports many auth patterns; you get load balancing for free.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use WAMP to handle data communications and subscriptions between the feature store and the client machine learning model devices of the system because WAMP allows for decoupled messaging, language- and framework-agnostic integration, flexible authentication patterns, and built-in routing/load balancing, which improves scalability, interoperability, security, and maintainability of the system.
Claim(s) 14-15, 17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of in view of Gandhi (US 20240348263 A1, 2024-10-17), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02).
Regarding claim 14, Tchankotadze teaches;
access, from the
([Abstract] The method further includes using the metadata to determine the one or more features or feature sets for specified data and storing the one or more determined features or feature sets in a feature store. In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The feature store stores values of features or feature sets, where some of the features or feature sets are accessed by at least one machine learning model. Thus, the stored data of the feature store is associated with a plurality of possible machine learning features, which is accessed by at least a machine learning model.
wherein the composite feature is a secondary or higher feature based on one or more primary features calculated at the feature store;
PNG
media_image1.png
661
468
media_image1.png
Greyscale
NOTE: Fig. 3 details the feature store architecture. The in-memory transformations are performed in the feature store.
([0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312. These features or feature sets can similarly be materialized for storage as features 308 in the data store 302 or for storage in the feature cache 316 (for low latency processing).)
NOTE: Teaches that the feature store can generate transformed/composite features based on primary features (the primary features being the production data in this excerpt). These transformed/composite features are then stored in the feature store as features. Thus, any of the features accessed from the feature store can be composite features.
transfer, at a communication interface, the set of values between the feature store and the
([0028] The application server 106 is coupled to the network 104 and is coupled to or otherwise communicates with the database server 108 and/or file server 111. The application server 106 and the database server 108, database 110, and/or file server 111 support the use of at least one metadata-driven feature store.)
NOTE: The feature store is capable of communication via at least the application server. Thus, the feature store can be considered a communication interface.
([0043] The selected features 308 identified for evaluation (or a portion of the data associated with the selected features 308) may be exported, such as to one or more machine learning models represented as clients 310 of the data store 302.)
NOTE: Teaches transferring/exporting, at a communications interface (features are transferred at the data store of the feature store / communications interface), the set of values (the feature values, which can be the aforementioned composite feature values) between the feature store and the client models.
execute, at the
([0017] A feature may be said to be “materialized” when a transformed value for that feature is stored directly (rather than evaluating feature transformations on source data each time the data is used). A “feature store” refers to a centralized repository or other repository of materialized feature data… [0018] Feature stores routinely include two separate data storages, namely an offline storage and an online storage. The online storage is generally used for storing data related to inferencing to be performed using trained machine learning models (often referred to as “production data”))
NOTE: Teaches executing a machine learning model using the set of values associated with the composite feature (the transformed/composite data of the feature store is used to execute the machine learning models/devices for inferencing); and outputting a machine learning prediction based on a result of executing the machine learning model using the set of values associated with the composite feature (executing the machine learning models on the composite features of the feature store outputs an inference / prediction).
Tchankotadze fails to teach but Gupta teaches;
A system for machine learning model generation, the system comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the system to: receive, at a server device, a request for a machine learning prediction;
PNG
media_image2.png
556
495
media_image2.png
Greyscale
([0136] inferencing service 620 uses the trained ML model 622 and features from the feature store 616 to process an inferencing request 612 and generate a prediction … [0205] machine 1700 may operate in the capacity of a server machine or a client machine in a server-client network environment … Further, while only a single machine 1700 is illustrated, the term “machine” shall also be taken to include a collection of machines 1700 that individually or jointly execute the instructions 1716 to perform any one or more of the methodologies discussed herein.)
NOTE: The machine 1700 (which can be a server machine, i.e. a server device) which has one or more memories, and one or more processors, coupled to the one or more memories, configured to cause the system to perform at least any operations of the machine learning model, including receiving, at the server device (machine 1700) a request for a machine learning prediction / inference.
OBVIOUSNESS:
Using the same reasoning from claim 1.
Tchankotadze and Gupta fail to teach but Harrison teaches;
using a WebSockets protocol;
([pg. 2-3] WAMP is a WebSockets sub-protocol... To use WAMP, your applications need a Router with a Realm (a routing namespace) to connect to and then they can exchange messages using WAMP’s two communication patterns: routed Remote Procedure Calls and Publish and Subscribe.)
NOTE: WAMP is a protocol which allows applications to send and receive data via messages.
OBVIOUSNESS:
Using the same reasoning from claim 1.
Tchankotadze, Gupta, and Harrison fail to teach but Gandhi teaches;
encode,
([fig. 3] data of the first machine learning model is compressed and stored in an off-chip memory … [0029] In some examples, the data may also include inputs, such as features and/or the characteristics of the data that are used to make predictions or classifications by the machine learning model 110.)
NOTE: Teaches encoding (compressing) a set of values associates with a feature (input feature data can be compressed)
decode, at the
([fig. 3] transmit the compressed data from the off-chip memory to an on-chip memory of the processing array, decompress the compressed data based on metadata stored in association with the compressed data and the lookup table, execute the machine learning model based on the decompressed data and with the processing array)
NOTE: Teaches decoding (decompressing), at a device (at the on-chip memory of the processing array), the set of values associated with the feature.
OBVIOUSNESS:
Gandhi is analogous art to the present disclosure as it pertains to reconstructing decompressed data to be used for machine learning analysis. Tchankotadze teaches transforming feature values including composite feature values at the feature store, which are processed using client models. Gupta teaches implementing machine learning models configured to receive and process feature data using server devices. Gandhi teaches a method of compressing and decompressing feature data to be processed by machine learning models. Additionally, Gandhi indicates that the benefit of compressing data in memory is to reduce usage of compute resources and power; “[0026] The second data (the compressed data) may be stored in the memory to reduce a memory footprint of the data relative to uncompressed data (e.g., the first data), reduce compute resources and power. In doing so, the number of evictions and fetches is reduced to lessen the latency and compute resources while still maintaining accuracy.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to compress the data in in the feature store to save resources, then reconstruct / decompress the data at the server devices when it needs to be used by the machine learning models.
Tchankotadze, Gupta, Harrison, and Gandhi fail to teach but Moeller teaches;
wherein to access
([0269] Remote Procedure Calls With Updates … [0282] The procedure can return data to the caller. Data is returned as a set of objects in the same way data is returned as a set of results from a query. Data objects of the return type are returned to the procedure caller as a list of data objects just as objects matching a data query are returned as a list of objects. A procedure's return results can be objects that already exist in the system or new objects.)
NOTE: Teaches performing a remote procedure call to generate a new data object at the system, because the data objects returned by the RPC can be new objects, meaning they were generated as a result of the RPC.
OBVIOUSNESS TO COMBINE MOELLER:
Moeller is analogous art to the present disclosure as it pertains to the generation of data objects using remote procedure calls. Tchankotadze already provides a feature store which generates data objects (the aforementioned transformed/composite features). Moeller provides a method for performing a remote procedure call to generate a new data object. Additionally, Moeller indicates that the benefit of using the RPC is that it lets the system generate/retrieve the needed data on demand instead of precomputing or continuously maintaining every possible data set for every possible consumer; ([0270] In addition to queries, the system also supports remote procedure call capabilities to retrieve data. Applications that wish to provide on-demand services to the system register "procedures" or "services" with the system. A procedure can be registered through a call on the client library's API. The client library in turn can send a procedure registration message to a management server, which creates a data object that contains information about the procedure, such as its name, the parameters (data object types) that can be provided to the procedure when invoking it, and where the procedure (which application) is located). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to access the feature store by using remote procedure calls to generate new data as needed, rather than having to precompute or continuously maintain every possible data set for every possible consumer.
Tchankotadze, Gupta, Harrison, Gandhi, and Moeller fail to teach but Ruan teaches; new data object having the server device subscribed as a client,
([pg. 11-12] wherein the electronic device establishing long connection between the service client end can be through the stream (grpcstream, can continuously push data, grpc is high performance RPC (Remote Procedure Call, remote procedure call) frame; … when the publisher (electronic device) has a new subscribed service block generation; the service data in the service block is pushed to the subscriber (service client))
NOTE: Teaches a publisher generating a new data object (the data of the newly generated service block) having a device subscribed as a client (the service block is subscribed to by the client), where the client device receives a set of values associated with the new data object (the data/values of the new service block is pushed to the client device).
OBVIOUSNESS TO COMBINE RUAN:
Ruan is analogous art to the present disclosure as it pertains to a data processing method utilizing remote procedure calls to push data to subscribed devices. Tchankotadze teaches a feature store which generates data objects (the aforementioned transformed /composite features) which are then sent to client devices (machine learning models). Moeller provides a method for performing a remote procedure call to generate a new data object. Ruan further provides a method for pushing values of generated data objects to subscribed client devices. Ruan further states that because the connection stays open, the server can keep pushing newly generated service data to the client as soon as it becomes available, and the client does not need to repeatedly establish and disconnect connections for each update, which reduces connection establishment and disconnection overhead; ([pg. 12] based on long connection, it can ensure the continuous sending of the real-time service data, and reduces the connection establishment and disconnection overhead, can improve the processing performance of the electronic device. Therefore, the electronic device can be represented as the RPC Server, correspondingly, the service client device can be represented as the RPC Client). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the feature-store access using the real-time RPC subscription mechanism of Ruan to allow the feature store to push newly generated composite features to the subscribed clients as soon as they become available, reducing repeated connection establishment and disconnecting overhead.
Regarding claim 15, Tchankotadze teaches
Client [model]
([0043] machine learning models represented as clients 310 of the data store 302.)
Tchankotadze fails to teach but Gutpa teaches;
output the machine learning prediction to a retrieval unit of a
([fig. 17] the output of the I/O component is directed to the bus of the machine 1700, … [0136] inferencing service 620 uses the trained ML model 622 and features from the feature store 616 to process an inferencing request 612 and generate a prediction 624.)
NOTE: The machine 1700 is used to implement the aforementioned client models, and the output of the machine is directed to a retrieval unit (the bus) of the client device (machine 1700). The output of the machine 1700 implementing the machine learning model is the generated prediction. Thus, Gupta teaches; outputting the machine learning prediction to a retrieval unit (bus) of a client device (the machine implementing the client model).
OBVIOUSNESS:
Using the same reasoning from claim 1.
Regarding claim 17, Tchankotadze teaches;
wherein the feature store is implemented as a plurality of compute nodes across a plurality of server devices.
([0026] FIG. 1 illustrates an example system 100 supporting a metadata-driven feature store according to this disclosure. For example, the system 100 shown here can be used to support a metadata-driven feature store that is used to store metadata related to features or feature sets to be processed by one or more machine learning models as described in more detail below. As shown in FIG. 1, the system 100 includes user devices 102a-102d, one or more networks 104, one or more application servers 106, and one or more database servers 108 associated with one or more databases 110 and/or one or more file servers 111.)
NOTE: Teaches the feature store being implemented as a plurality of compute nodes (ML models, user devices, databases, etc.) across a plurality of server devices (application servers, database servers, file servers, etc.).
Regarding claim 19, Tchankotadze teaches;
([Abstract] In addition, the method includes outputting at least some of the one or more determined features or feature sets or data associated with the at least some of the one or more determined features or feature sets from the feature store to at least one machine learning model.)
NOTE: The aforementioned device/model accesses one or more resources (values of features and feature sets) associated with the feature store (the features and feature sets are stored in the feature store).
Tchankotadze and Gupta fail to teach but Harrison teaches;
transmit a remote procedure call (RPC) using a WebSockets protocol to…
([pg. 2-3] WAMP is a WebSockets sub-protocol... To use WAMP, your applications need a Router with a Realm (a routing namespace) to connect to and then they can exchange messages using WAMP’s two communication patterns: routed Remote Procedure Calls and Publish and Subscribe.)
NOTE: Harrison teaches WAMP, which is a WebSockets protocol capable of transmitting remote procedure call for transmitting messages / data.
OBVIOUSNESS:
Using the same reasoning from claim 1,
Claim(s) 18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of in view of Gandhi (US 20240348263 A1, 2024-10-17), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 14 and 17 above, and further in view of Adibowo (US11461300B2, 2021-10-04).
Regarding claim 18, Tchankotadze teaches;
and access a resources, of the plurality of server devices, associated with the compute node.
([0028] In some cases, the data of each metadata-driven feature store may be physically stored in the database 110 and accessed via the database server 108 and/or physically stored in the file server 111… [0053] transformed data (features 308) retrieved from the feature store 308 by clients 310)
NOTE: Each of the compute nodes (clients) access resources of the feature store (transformed/composite features), the feature store being implemented using server devices of the plurality of server devices (file server, database server). Thus, any compute node is associated with the server device.
Tchankotadze, Gupta, Harrison, Gandhi, Moeller,Ruan fail to teach but Adibowo teaches;
select a compute node, of the plurality of compute nodes, with a particular configuration based on a characteristic of the request for the machine learning prediction;
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request)… [col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis).)
NOTE: Adibowo teaches selecting a compute node, of the plurality of compute nodes (selects an ML model of a plurality of ML models), with a particular configuration (each of the ML models is configured to perform a request-specific task), based on a characteristic of the request for the machine learning prediction (the selection is based on the type of the inference/prediction request, which can be considered a characteristic of the request)
OBVIOUSNESS:
Tchankotadze teaches a feature store 300, having machine learning models represented as clients 310, which can be considered compute nodes of the aforementioned plurality of compute nodes of the feature store configured to access the feature store and generate predictions;
PNG
media_image3.png
636
877
media_image3.png
Greyscale
([0038] FIG. 3 illustrates an example architecture 300 supporting a metadata-driven feature store according to this disclosure… [0043] one or more machine learning models represented as clients 310 of the data store 302.) Adibowo teaches a server system for selecting a machine learning model of a plurality of machine learning models based on a prediction request. Additionally, Adibowo indicates that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request; “[col. 1, ln. 9-16] ML models can be configured in the respective artificial neural networks (ANN) in order to solve a certain well-defined problem. Because the customers would have their specific set of problems to solve, the ML model of one customer might not be able to solve problem of another customer.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the method of Adibowo to select a compute node (client model of Tchankotadze) to access the feature store that has a configuration most suited for answering a prediction request based on a characteristic of the request (request type), predictably providing the compute node that is best suited for processing the request.
Regarding claim 20, Tchankotadze, Gupta, Harrison, Gandhi, Moeller and Ruan fail to teach but Adibowo teaches;
wherein the request for the machine learning prediction is directed to the server [model] based on a characteristic of the request for the machine learning prediction,
([Abstract] selecting, by the API server, a model server from a plurality of model servers based on the prediction request, each of the plurality of model servers including a stateful server, calling, by the API server, the model server to execute inference using a ML model loaded to memory of the model server)
NOTE: Each of the machine learning models are implemented on a server (model server).
([col. 12, ln. 12-18] In some examples, when the server system 104 receives an inference request, the server system 104 selects a ML model in response to the inference request. The selection can be made based on … the type of inference request (e.g., semantic inference, image recognition, data analysis)
NOTE: Teaches the machine learning prediction / inference request being directed to the model (the prediction / inference request is directed to the selected ML model / device) based on a characteristic of the request for the machine learning model (the selection is made based on the type of inference request, where the type can be considered a characteristic of the request).
wherein the server [model] is included in a set of server [models] of the system that is configured to process requests associated with different characteristics.
([col. 5, ln. 19-29] For example, the inference platform of the present disclosure is at least partially hosted in the server system 104. As described in further detail herein, the inference platform is able to provide client-specific inference services using client-specific and request-specific ML models (e.g., selecting a ML model specific to the client and/or the request).)
NOTE: Teaches each of the ML models of the server devices (model servers) being configured to process requests associated with different characteristics (request-specific ML models which are configured to process requests of different types). As taught above, the server device (model server) implementing the ML model is included in a set of server devices of the system (there are a plurality of model servers in the system).
OBVIOUSNESS:
Tchankotadze teaches a plurality of client machine learning models configured to process prediction requests. Gupta teaches receiving and processing a machine learning request at a device. Adibowo teaches a server system selecting a machine learning model of a plurality of machine learning models based on a prediction request. Adibowo further teaches (as stated in claim 4) that each ML model can be configured to solve a different problem. Thus, each prediction request should be routed to the model having the configuration most suited to answer the request. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to use the process of Adibowo select a device (client model device, as taught by Tchankotadze as modified by Gutpa) of a set of devices based on a characteristic of the prediction request, to direct the request to the device that is best suited for processing the request.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tchankotadze (US 20230297878 A1, 2023-09-21) in view of Gutpa (US 20240362196 A1, 2024-10-31), further in view of Harrison (“The Web Application Messaging Protocol; from a Pythonic perspective”, 2018-10-17), further in view of in view of Gandhi (US 20240348263 A1, 2024-10-17), further in view of Moeller (US 20060069702 A1, 2006-03-30), further in view of Ruan (CN 113591130 A, 2021-11-02) as applied to claim 15 above, further in view of Mohamed (EP 4198831 A1, 2023-06-21).
Regarding claim 16, Tachankotadze teaches;
A remote feature store
([0030] For example, the system 100 may be coupled to at least one external network 114, such as the Internet. This may allow at least one metadata-driven feature store for the organization associated with the system 100 to be created by a remote server 116…)
Tachankotadze, Gupta, Harrison, and Gandhi fail to teach but Mohamed teaches;
wherein the composite feature is based on an output of a
([Abstract] Systems, methods, and computer-readable media for performing feature engineering on a dataset for predictive modeling are disclosed. A dataset may comprise a plurality of features that are used for the predictive model. The dataset may be fed to a neural network to determine which features have the greatest impact on the predictive model and which features do not positively impact the predictive model. A deep reinforcement learning agent may select an action to perform on the dataset. The action may be applied to the dataset to generate new features and obtain a transformed dataset.)
NOTE: Teaches composite features (transformed features of the dataset can be considered composite features, as the transformed dataset / features are higher features based on the original dataset / features) based on an output of a machine learning model (the output of the neural network and deep learning reinforcement agent determine the action / transformation to be applied to the dataset / features).
Reasoning as to why it would have been obvious to include this model at the remote feature store of Tachankotadze will be explained below.
OBVIOUSNESS TO COMBINE MOHAMED:
Mohamad is analogous art to the present disclosure as it pertains to predictive modeling using composite / transformed data. Tachankotadze already teaches transforming feature data at the remote feature store architecture to generate transformed / composite features to be used for machine learning predictions; “[Tachankotadze, 0048] In some cases, it is also possible to perform one or more in-memory transformations 320 to at least some of the production data 312 in order to produce additional features or feature sets directly from the production data 312.” Mohamad provides a means for determining transformations to feature data based on the output of a machine learning model, then using the transformed data for machine learning prediction. Additionally, Mohamad teaches selecting the best transformation to be applied to the feature data, i.e., selecting the transformation which will improve the predictive model the most; “[0033] Deep reinforcement learning may provide a reward for state transformations that improve the predictive model. A cumulative reward may be maximized thus providing a set of features that maximizes the improvement in predictive models.” Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the neural network and deep reinforcement learning agent of Mohamed in the remote feature store of Tachankotadze to use the output to select the best transformations to be applied to the features, predictably resulting in composite features that maximize the improvement of the client predictive models.
Response to Arguments
The rejection under 35 USC 112(a) has been withdrawn in view of the present amendments.
Applicant’s arguments, filed 07/30/2026, with respect to 35 USC 112(b) have been fully considered and are persuasive. The 35 USC 112(b) rejections of claim 14 have been withdrawn.
Applicant's arguments filed 07/30/2026, with respect to 35 USC 103 have been fully considered but they are not persuasive. Starting on page 2, the applicant states that; “For at least the reasons presented in the interview and without acquiescing in the Examiner's rejection, the cited sections of the applied references, whether taken alone or in any reasonable combination, do not disclose at least: wherein to access the feature store, the one or more processors are configured to cause the device to: perform a remote procedure call (RPC) to generate, at the feature store, a new data object having the device subscribed as a client, wherein the new data object is for a composite feature as recited in claim 1, as amended. Therefore, independent claim 1, and the claims that depend thereon, are patentable over the cited sections of the applied references. Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw the rejection of claims 1, 3, and 5 under 35 U.S.C. § 103 based on TCHANKOTADZE, GUTPA, HARRISON, and CELLA.” In the interview, it was discussed that the proposed amendments do not appear to overcome all of my cited art. As reflected by the present office action, amended claims 1, 3, and 5 are now being rejected under Tchankotadze in view of Gutpa, further in view of Harrison, Cella, Moeller, and Ruan as necessitated by the amendments, where the disputed limitation of amended claim 1 is taught by the combination of Tchankotadze, Moeller, and Ruan (see pages 3-14 of the present office action). Accordingly, amended claims 1, 3, and 5 and claims that depend thereon are not patentable over the applied references in the present office action.
The applicant further states; “For at least the reasons presented in the interview and without acquiescing in the Examiner's rejection, the cited sections of the applied references, whether taken alone or in any reasonable combination, do not disclose at least: performing a remote procedure call (RPC) to generate a new data object at the feature store, the new data object having the device subscribed as a client, wherein the new data object is for a composite feature; as recited in claim 8, as amended. Therefore, independent claim 8, and the claims that depend thereon, are patentable over the cited sections of the applied references. Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw the rejection of claims 8 and 10 under 35 U.S.C. § 103 based on TCHANKOTADZE, GUTPA, MOELLER, and RUAN.” Examiner respectfully disagrees. In the interview, it was discussed that the proposed amendments do not appear to overcome all of my cited art. As reflected by the present office action, amended claim 8 and 10 are being rejected under Tchankotadze in view of Gutpa, further in view of Moeller, and Ruan, where the disputed limitation of amended claim 8 is taught by the combination of Tchankotadze, Moeller, and Ruan (see pages 27-34 of the present office action). Accordingly, amended claims 8 and 10 and claims that depend thereon are not patentable over the applied references in the present office action.
The applicant further states; “For at least the reasons presented in the interview and without acquiescing in the Examiner's rejection, the cited sections of the applied references, whether taken alone or in any reasonable combination, do not disclose at least: wherein to access the feature store, the one or more processors are configured to cause the system to: perform a remote procedure call (RPC) to generate, at the feature store, a new data object having the server device subscribed as a client, wherein the new data object is for a composite feature as recited in claim 14, as amended. Therefore, independent claim 14, and the claims that depend thereon, are patentable over the cited sections of the applied references. Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw the rejection of claims 14-17 and 19 under 35 U.S.C. § 103 based on TCHANKOTADZE, GUTPA, HARRISON, and GANDHI.” In the interview, it was discussed that the proposed amendments do not appear to overcome my cited art. As reflected by the present office action, amended claims 14-15, 17, 19 are now being rejected under Tchankotadze in view of Gutpa, further in view of Harrison, Gandhi, Moeller, and Ruan as necessitated by the amendments, where the disputed limitation of amended claim 14 is taught by the combination of Tchankotadze, Moeller, and Ruan (see pages 45-54 of the present office action). Accordingly, amended claims 14-15, 17, 19 and claims that depend thereon are not patentable over the applied references in the present office action.
Claim 16 is now being rejected under Tchankotadze in view of Gutpa, further in view of Harrison, Gandhi, Moeller, and Ruan as applied to claim 15, further in view of Adibowo, as necessitated by the amendments.
Thus, claims 1-20 stand rejected under 35 USC 103 in the present office action.
Conclusion
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 Matthew Alan Cady whose telephone number is (571) 272-7229. The examiner can normally be reached Monday - Friday, 7:30 am - 5:00 pm ET.
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, Cesar Paula can be reached on (571)272-4128. 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.
/MATTHEW ALAN CADY/ Examiner, Art Unit 2145
/CESAR B PAULA/ Supervisory Patent Examiner, Art Unit 2145
