DETAILED ACTION
This action is in response to the application filed on 4/10/2023. Claims 1-20 are pending in the application and have been examined.
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding Independent Claims 1, 8 and 14,
Regarding Claim 1,
(Step 1): Claim 1 recites A method of generating training data for a machine learning model from a series of events, comprising, thus a process, one of the four statutory categories of patentable subject matter.
(Step 2A Prong 1): However, Claim 1 further recites assigning, to respective events from the series of events, a series of time stamps associated with a near real-time (NRT) variable; which constitutes the evaluation of the series of events to determine a series of time stamps associated with a NRT variable, thus corresponding to a mental process which can be done mentally or by pen and paper;
model an outcome of the series of events using the simulated delay latency which constitutes the evaluation of the simulated delay latency and the series of events to determine an outcome, thus corresponding to a mental process which can be done mentally or by pen and paper;
Thus, Claim 1 recites an abstract idea.
(Step 2A Prong 2): The claim does not recite any additional elements which integrate the abstract idea into a practical application because the additional elements consist of:
simulating a delay latency associated with processing the respective events … based on the series of time stamps, which is interpreted as measuring, from the series of time stamps associated with respective events, a delay latency, thus insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
via an online processing environment, which is implementing an abstract idea on generic computer components (MPEP 2106.05(f))
and providing the series of events and the simulated delay latency to a machine-learning model configured to model, which is implementing an abstract idea on generic computer components (MPEP 2106.05(f))
and thus, the claim is directed to the abstract idea of evaluating series of events to determine an associated series of time stamps and afterwards predicting an outcome of the series of events using a simulated delay latency.
(Step 2B) The additional elements, taken alone or in combination, cannot provide significantly
more than the abstract idea itself because element a) is further well-understood, routine, and conventional activity of “transmitting or receiving data over a network,” by MPEP 2106.05(d), which cannot provide significantly more than the abstract idea itself and elements b), c) (via MPEP 2106.05(f), “apply it on a computer”) cannot provide an inventive concept. Thus, Claim 1 is subject-matter ineligible.
Regarding Claim 8,
(Step 1): Claim 8 recites A method of training a machine learning model for a series of events, comprising thus a method, one of the four statutory categories of patentable subject matter.
(Step 2A Prong 1): However, Claim 8 further recites a simulation delay generated based on the series of events and the series of times, which constitutes the evaluation of the series of events and the series of times to determine a simulation delay, thus corresponding to a mental process which can be done mentally or by pen and paper;
processing … the series of events with the simulation delay to generate a series of modeled outcomes which constitutes the evaluation of the series of events and the simulation delay to determine a series of modeled outcomes, thus corresponding to a mental process which can be done mentally or by pen and paper;
and generating adjustments to adjustable parameters of the machine-learning model based on a comparison of the series of outcomes with the series of modeled outcomes which constitutes the evaluation of the series of outcomes against the series of modeled outcomes to determine adjustments to adjustable parameters of the machine-learning model, thus corresponding to a mental process which can be done mentally or by pen and paper;
Thus, Claim 8 recites an abstract idea.
(Step 2A Prong 2): The claim does not recite any additional elements which integrate the abstract idea into a practical application because the additional elements consist of:
receiving, from a datastore, a series of events, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
receiving, from the datastore, a series of times associated with the series of events, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
receiving, from the datastore, a simulation delay which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
receiving, from the datastore, a series of outcomes associated with the series of events, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
with a machine-learning model of an offline simulation module which is implementing an abstract idea on generic computer components (MPEP 2106.05(f))
and thus, the claim is directed to the abstract idea of evaluating a series of events and series of times to determine a simulation delay in order to predict modeled outcomes using the simulation delay, afterwards evaluating the modeled outcomes against the original series of outcomes to determine model parameter updates.
(Step 2B) The additional elements, taken alone or in combination, cannot provide significantly
more than the abstract idea itself because elements a), b), c) and d) are further well-understood, routine, and conventional activity of “transmitting or receiving data over a network,” by MPEP 2106.05(d), which cannot provide significantly more than the abstract idea itself and element e) (via MPEP 2106.05(f), “apply it on a computer”) cannot provide an inventive concept. Thus, Claim 8 is subject-matter ineligible.
Regarding Claim 14,
(Step 1): Claim 14 recites A computing system, comprising: one or more processors; and a computer-readable storage medium storing that, responsive to execution by the one or more processors, causes the one or more processors to perform operations, thus a machine, one of the four statutory categories of patentable subject matter.
(Step 2A Prong 1): However, Claim 14 further recites determine a delay latency from the first delay and the second delay, which constitutes the evaluation of the first and second delay to determine a delay latency, thus corresponding to a mental process which can be done mentally or by pen and paper;
determine a simulation delay to apply to the plurality of enriched events, the simulation delay being based on the delay latency which constitutes the evaluation of the delay latency to determine an appropriate simulation delay for the plurality of events, thus corresponding to a mental process which can be done mentally or by pen and paper;
Thus, Claim 14 recites an abstract idea.
(Step 2A Prong 2): The claim does not recite any additional elements which integrate the abstract idea into a practical application because the additional elements consist of:
during an online production process, for each of a plurality of enriched events: measure a first delay between a near real-time (NRT) variable state pre-persistence time and a publishing time of an associated event, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
measure a second delay between an NRT variable state post- persistence time and the NRT variable state pre-persistence time, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
record the delay latency, which is insignificant extra-solution activity of data gathering (MPEP 2106.05(g)))
and during an offline simulation process of the production process through execution of a machine-learning model, which merely recites the particular technological environment or field of use in which the abstract idea is to be performed (MPEP 2106.05(h))
and thus, the claim is directed to the abstract idea of evaluating the first and second delays to determine a delay latency and further evaluating the delay latency to determine a simulation latency.
(Step 2B) The additional elements, taken alone or in combination, cannot provide significantly
more than the abstract idea itself because elements a), b), c) are further well-understood, routine, and conventional activity of “transmitting or receiving data over a network,” by MPEP 2106.05(d), which cannot provide significantly more than the abstract idea itself and element d) (via MPEP 2106.05(h)) cannot integrate the abstract idea into a practical application or provide significantly more than the abstract idea itself. Thus, Claim 14 is subject-matter ineligible.
Regarding Dependent Claims 2-7, 9-13, 15-20,
Claims 2-3, 5-6 recite additional steps of the abstract idea (mental processes) but merely recite the particular technological environment or field of use in which the abstract idea is to be performed and thus (via MPEP 2106.05(h)) cannot integrate the abstract idea into a practical application or provide significantly more than the abstract idea itself. Thus, Claims 2-3, 5-6 are subject-matter ineligible.
Claim 4 recites additional steps of the abstract idea (mental processes) but merely recites the particular technological environment or field of use in which the abstract idea is to be performed and thus (via MPEP 2106.05(h)) cannot integrate the abstract idea into a practical application or provide significantly more than the abstract idea itself. Additionally, the claim recites insignificant extra-solution activity of data gathering (MPEP 2106.05(g))) and thus (via MPEP 2106.05(g)) cannot integrate the abstract idea into a practical application or provide significantly more than the abstract idea itself. Thus, Claim 4 is subject-matter ineligible.
Claims 7; 9-13; 15-20 merely recite the particular technological environment or field of use in which the abstract idea is to be performed and thus (via MPEP 2106.05(h)) cannot integrate the abstract idea into a practical application or provide significantly more than the abstract idea itself. Thus, Claims 7; 9-13; 15-20 are subject-matter ineligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-13 are rejected under 35 U.S.C. 103 as being unpatentable over Hargis et al. (“Build accurate ML training datasets using point-in-time queries with Amazon SageMaker Feature Store and apache spark” [2021], hereinafter “Hargis” as disclosed in IDS) in view of Liu et al. (US20230401137A1, hereinafter “Liu”).
Regarding Claim 1,
Hargis discloses A method of generating training data for a machine learning model from a series of events, comprising (Hargis [Page 3 Section “Point-in-time queries”];
PNG
media_image1.png
662
851
media_image1.png
Greyscale
Wherein the queries associated with time stamps are indicative of a series of events for dataset generation)
assigning, to respective events from the series of events, a series of time stamps associated with a near real-time (NRT) variable; (Hargis [Page 3 Section “Point-in-time queries”]; “The diagram starts with a set of automated feature pipelines that perform feature transformations and ingest feature records into Feature Store. Pipelines for individual feature groups are independent and can run on varying schedules. One feature group may be refreshed nightly, whereas another is updated hourly, and a third may have updates that are triggered as source data arrives on an input stream, such as an Apache Kafka topic or via Amazon Kinesis Data Streams. Depending on the configuration of your feature groups, the resulting features are made available in an online store, an offline store, or both with automatic synchronization. The offline store provides a secure and scalable repository of features, letting data scientists create training and validation datasets or batch scoring datasets from a set of feature groups that can be managed centrally with a full history of feature values.
PNG
media_image2.png
361
766
media_image2.png
Greyscale
”
Wherein the timestamps for the hourly updated/refreshed features stored in the Amazon SageMaker discloses timestamps associated with near real-time)
processing the respective events via an online processing environment based on the series of time stamps; (Hargis [Page 1 Paragraph 1]; “ GoDaddy is the world’s largest services platform for entrepreneurs around the globe, empowering their worldwide community of over 20 million customers—and entrepreneurs everywhere—by giving them all the help and tools they need to grow online. GoDaddy needs a robust, validated, and customizable ML feature management solution, and has chosen Amazon SageMaker Feature Store to manage thousands of features across dozens of feature groups with unique data pipelines and update schedules. Feature Store lets GoDaddy use point-in-time queries to support accurate training and deployment of machine learning (ML) models, covering everything from personalizing content, to preventing fraud, to helping customers find the perfect domain name. Feature Store lets you define groups of features, use batch ingestion and streaming ingestion, retrieve features with as low as single-digit millisecond latency for highly accurate online predictions, and extract point-in-time correct datasets for training. Instead of building and maintaining these infrastructure capabilities, you get a fully managed service that scales as your data grows, enables feature sharing across teams, and lets data scientists focus on building great ML-driven products for game-changing business use cases. Teams can now deliver robust features and reuse them in a variety of models that may be built by different teams. In this post, we (the joint team of GoDaddy and AWS architects), explain how to use Feature Store and the processing power of Apache Spark to create accurate training datasets using point-in-time queries against reusable feature groups in a scalable fashion” wherein the events are processed via the GoDaddy services platform)
and providing the series of events … to a machine- learning model configured to model an outcome of the series of events … (Hargis [Page 1 Paragraph 1]; “ Feature Store lets GoDaddy use point-in-time queries to support accurate training and deployment of machine learning (ML) models, covering everything from personalizing content, to preventing fraud, to helping customers find the perfect domain name” wherein the deployment of models for modeling event outcomes related to fraud prevention and content personalization is performed dependent on event time-series provided to the model in question)
Hargis does not explicitly disclose but Liu discloses simulating a delay latency associated with processing (Liu [0035]; “Causal inference module 320 includes latency predictor 330. Latency predictor 330 may generate a group of estimated latencies for a corresponding group of data persistence operations based on the group of records 310. For example, computing device 110 may train and verify latency predictor 330 using a machine training method and based on historical records of system 120 or a system similar to system 120 until latency predictor 330 is verified to be of sufficient quality (e.g., using actual latencies of the operations) for use in estimating the estimated latencies of the data persistence operations.”)
It would have been obvious to modify Hargis’ method of generating training data for a machine learning model by assigning series of events NRT variables and processing the respective events for modeling their outcomes by incorporating Liu’s latency predictor and its associated simulated delay latencies into predicted event outcomes. One would have been motivated to do so because “ The suggested action thus generated takes the combined influence of multiple states on the latency into consideration, thereby providing a more comprehensive guidance for performance improvement” (Liu [0042])
Hargis discloses:
processing the respective events via an online processing environment based on the series of time stamps
providing the series of events … to a machine- learning model configured to model and outcome of the series of events ...
Hargis does not explicitly disclose:
simulating a delay latency associated with processing …
providing … the simulated delay latency to a machine-learning model
model an outcome of the series of events … using the simulated delay latency
However, Liu discloses:
simulating a delay latency associated with processing
providing … the simulated delay latency to a machine-learning model
model an outcome of the series of events … using the simulated delay latency
By using the simulated delay latency of Liu in the processing and modeling of Hargis, the combination thus discloses:
simulating a delay latency associated with processing the respective events via an online processing environment based on the series of time stamps
providing the series of events and the simulated delay latency to a machine- learning model configured to model an outcome of the series of events using the simulated delay latency
Regarding Claim 2,
The combination of Hargis/Liu teaches the method of Claim 1 (and thus the rejection of Claim 1 is incorporated). Hargis/Liu already discloses wherein assigning, to the respective events from the series of events, the series of time stamps associated with the NRT variable includes: assigning, to the respective events, a first time stamp of the series of time stamps, the first time stamp associated with a publishing time of the respective events; assigning, to the respective events, a second time stamp of the series of time stamps, the second time stamp associated with generating an enriched event from the respective events (Hargis [Page 3 Paragraph 1]; “Get features as of a specific timestamp – Likewise, a query that returns all feature data as of a single timestamp produces an inappropriate training dataset, because it treats all records uniformly instead of using a distinct timestamp for each training dataset entry. So-called time travel capabilities are great for auditing and reproducing experiments. However, time travel doesn’t solve for accurate training dataset extraction, because it doesn’t account for event timestamps that vary for each training record.” wherein a plurality of timestamps associated with a plurality of events reads on assigned first and second timestamps associated with a publishing event time)
Regarding Claim 3,
The combination of Hargis/Liu teaches the method of Claim 2 (and thus the rejection of Claim 2 is incorporated). Hargis/Liu already discloses wherein generating the enriched event from the respective events includes adding, by a pre-processing module, additional data associated with the respective events to the respective events, the additional data including at least one of user information and event context information (Hargis [Page 3 Section “Point-in-time queries”];
PNG
media_image3.png
348
753
media_image3.png
Greyscale
Wherein the generated enriched events comprises additional data including both user information identifiers as well as event context information)
Regarding Claim 4,
The combination of Hargis/Liu teaches the method of Claim 2 (and thus the rejection of Claim 2 is incorporated). Hargis/Liu already discloses receiving a feature selection logic defining the NRT variable (Hargis [Page 3 Section “Point-in-time queries”]; “Although we show an Apache Spark implementation of point in time queries in this post, Amazon Athena provides another alternative. With Athena, you can create a temporary table containing your selection criteria, and then use SQL to join that criteria to your offline store feature groups. The SQL query can select the most recent feature values that are older than the targeted event time for each training dataset row.” wherein the existence of SQL queries for selection of feature values dependent on their age reads on receiving such feature selection logic queries)
wherein the simulating the delay latency associated with processing the respective events via the online processing environment based on the series of time stamps includes: measuring a first delay associated with generating the enriched event based on the first time stamp and the second time stamp (Liu [Figure 2];
PNG
media_image4.png
400
355
media_image4.png
Greyscale
Wherein the plurality of records each comprising predetermined periods by which latencies associated with event states of each record are derived thus read on a measured first delay associated with generation of the enriched event record based on at least a first and second timestamp within the predetermined period)
and inferring, via a latency delay model, the simulated delay latency associated with processing the enriched event via the online processing environment based at least on the first delay and the feature selection logic (Liu [Figure 2];
PNG
media_image4.png
400
355
media_image4.png
Greyscale
Wherein the predicted latency states associated with records reads on inferred simulated delay latencies associated with processing the record comprising an enriched event; wherein the records being associated with SHAPLEY contribution scores thus reads on the inference conducted based at least on feature selection logic)
Regarding Claim 5,
The combination of Hargis/Liu teaches the method of Claim 4 (and thus the rejection of Claim 4 is incorporated). Hargis/Liu already discloses wherein assigning, to the respective events from the series of events, the series of time stamps associated with the NRT variable further includes assigning, to the respective events, a third time stamp associated with generating an outcome via the online processing environment (Hargis [Page 3 Paragraph 1]; “Get features as of a specific timestamp – Likewise, a query that returns all feature data as of a single timestamp produces an inappropriate training dataset, because it treats all records uniformly instead of using a distinct timestamp for each training dataset entry. So-called time travel capabilities are great for auditing and reproducing experiments. However, time travel doesn’t solve for accurate training dataset extraction, because it doesn’t account for event timestamps that vary for each training record.” wherein a plurality of timestamps associated with a plurality of events reads on assigned third timestamps associated with a publishing event time for a generated outcome)
and wherein the simulated delay latency is further based on the third time stamp (Liu [Figure 2];
PNG
media_image4.png
400
355
media_image4.png
Greyscale
Wherein the plurality of records each comprising predetermined periods by which latencies associated with event states of each record are derived thus read on a measured first delay associated with generation of the enriched event record based on a plurality of time stamps comprising at least a third time stamp)
Regarding Claim 6,
The combination of Hargis/Liu teaches the method of Claim 1 (and thus the rejection of Claim 1 is incorporated). Hargis/Liu already discloses associating an outcome with the respective events of the series of events, and wherein the outcome is further provided to the machine-learning model (Hargis [Page 1 Paragraph 1]; “ Feature Store lets GoDaddy use point-in-time queries to support accurate training and deployment of machine learning (ML) models, covering everything from personalizing content, to preventing fraud, to helping customers find the perfect domain name”
Hargis [Page 3 Section “Point-in-time queries”];
PNG
media_image5.png
356
748
media_image5.png
Greyscale
Wherein the outcomes are associated with events of select times and features; wherein the outcome-comprised training dataset is provided to the machine-learning model)
Regarding Claim 7,
The combination of Hargis/Liu teaches the method of Claim 1 (and thus the rejection of Claim 1 is incorporated). Hargis/Liu already discloses wherein to model the outcome of the series of events …, the machine-learning model is configured as an offline point-in-time feature simulation (Hargis [Page 4 Section “Feature Point Timestamps”]; “ Feature Store timestamps Before we walk through how to perform point-in-time correct queries against the offline store, it’s important to understand the definition and purpose of the three different timestamps that SageMaker provides in the offline store schema for every feature group: Event time – The customer-defined timestamp associated with the feature record, such as the transaction time, the time a customer placed an order, or the time a new insurance claim was created. The specific name of this feature is specified when the feature group is created, and the customer’s ingestion code is responsible for populating this timestamp. API invocation time – The time when SageMaker receives the API call to write a feature record to the feature store. This timestamp is automatically populated by SageMaker as the api_invocation_time feature. Write time – The time when the feature record is persisted to the offline store. This timestamp is always greater than API invocation time, and is automatically populated by SageMaker as the write_time feature. Depending on your use case, you can use a combination of the timestamp fields in SageMaker to choose accurate feature values. Each instance in a training dataset has a customer-defined event time and a record identifier. When you join a list of training events against feature history in a point-in-time query, you can ignore all records that happened after the instance-specific event timestamp, and select the most recent of the remaining records. The event time field is the key to this join. In a standard use case, choosing the most recent remaining record is sufficient. However, if a feature value has been corrected or revised as part of a feature backfill, the offline store contains multiple records with the same event time and record identifier. Both the original record and the new record are available, and they each have a distinct write time. For these situations, a point-in-time query can use the write_time feature or the api_invocation_time feature as a tie-breaker, ensuring the corrected feature value is returned.” wherein the learning model is configured using offline store timestamps, thus read as offline point-in-time features and their simulation)
using the simulated delay latency (Liu [0035]; “Causal inference module 320 includes latency predictor 330. Latency predictor 330 may generate a group of estimated latencies for a corresponding group of data persistence operations based on the group of records 310. For example, computing device 110 may train and verify latency predictor 330 using a machine training method and based on historical records of system 120 or a system similar to system 120 until latency predictor 330 is verified to be of sufficient quality (e.g., using actual latencies of the operations) for use in estimating the estimated latencies of the data persistence operations.”)
Regarding Claim 8,
Hargis discloses A method of training a machine learning model for a series of events, comprising: receiving, from a datastore, a series of events; receiving, from the datastore, a series of times associated with the series of events … receiving, from the datastore, a series of outcomes associated with the series of events; (Hargis [Page 1 Paragraph 1]; “GoDaddy is the world’s largest services platform for entrepreneurs around the globe, empowering their worldwide community of over 20 million customers—and entrepreneurs everywhere—by giving them all the help and tools they need to grow online. GoDaddy needs a robust, validated, and customizable ML feature management solution, and has chosen Amazon SageMaker Feature Store to manage thousands of features across dozens of feature groups with unique data pipelines and update schedules. Feature Store lets GoDaddy use point-in-time queries to support accurate training and deployment of machine learning (ML) models, covering everything from personalizing content, to preventing fraud, to helping customers find the perfect domain name. Feature Store lets you define groups of features, use batch ingestion and streaming ingestion, retrieve features with as low as single-digit millisecond latency for highly accurate online predictions, and extract point-in-time correct datasets for training. Instead of building and maintaining these infrastructure capabilities, you get a fully managed service that scales as your data grows, enables feature sharing across teams, and lets data scientists focus on building great ML-driven products for game-changing business use cases. Teams can now deliver robust features and reuse them in a variety of models that may be built by different teams. In this post, we (the joint team of GoDaddy and AWS architects), explain how to use Feature Store and the processing power of Apache Spark to create accurate training datasets using point-in-time queries against reusable feature groups in a scalable fashion.” wherein the services provided by GoDaddy entrepreneurs discloses a series of events
Hargis [Page 2 Figure 1];
PNG
media_image6.png
405
739
media_image6.png
Greyscale
Wherein the timestamps and labels associated with the features stored in SageMaker for use with GoDaddy service platform disclose receiving a series of events, times, and outcomes associate with the series of events)
processing, with a machine-learning model of an offline simulation module, the series of events … to generate a series of modeled outcomes; and generating adjustments to adjustable parameters of the machine-learning model based on a comparison of the series of outcomes with the series of modeled outcomes (Hargis [Page 1 Paragraph 1]; “GoDaddy is the world’s largest services platform for entrepreneurs around the globe, empowering their worldwide community of over 20 million customers—and entrepreneurs everywhere—by giving them all the help and tools they need to grow online. GoDaddy needs a robust, validated, and customizable ML feature management solution, and has chosen Amazon SageMaker Feature Store to manage thousands of features across dozens of feature groups with unique data pipelines and update schedules. Feature Store lets GoDaddy use point-in-time queries to support accurate training and deployment of machine learning (ML) models, covering everything from personalizing content, to preventing fraud, to helping customers find the perfect domain name. Feature Store lets you define groups of features, use batch ingestion and streaming ingestion, retrieve features with as low as single-digit millisecond latency for highly accurate online predictions, and extract point-in-time correct datasets for training. Instead of building and maintaining these infrastructure capabilities, you get a fully managed service that scales as your data grows, enables feature sharing across teams, and lets data scientists focus on building great ML-driven products for game-changing business use cases. Teams can now deliver robust features and reuse them in a variety of models that may be built by different teams. In this post, we (the joint team of GoDaddy and AWS architects), explain how to use Feature Store and the processing power of Apache Spark to create accurate training datasets using point-in-time queries against reusable feature groups in a scalable fashion.” wherein the use of labels to train GoDaddy’s machine learning models to make predictions for a service implicitly discloses processing the series of events and adjusting the machine learning parameters based on compared modelled outcomes)
Hargis does not explicitly disclose but Liu discloses receiving, from the datastore, a simulation delay generated based on the series of events and the series of times (Liu [0035]; “Causal inference module 320 includes latency predictor 330. Latency predictor 330 may generate a group of estimated latencies for a corresponding group of data persistence operations based on the group of records 310. For example, computing device 110 may train and verify latency predictor 330 using a machine training method and based on historical records of system 120 or a system similar to system 120 until latency predictor 330 is verified to be of sufficient quality (e.g., using actual latencies of the operations) for use in estimating the estimated latencies of the data persistence operations.” wherein the simulation delay generated based on historical data and its time series being received from a causal inference module latency predictor datastore is performed)
It would have been obvious to modify Hargis’ method of generating training data for a machine learning model by assigning series of events NRT variables and processing the respective events for modeling their outcomes by incorporating Liu’s latency predictor and its associated simulated delay latencies computed through Hargis’ feature selection logic into predicted event outcomes. One would have been motivated to do so because “ The suggested action thus generated takes the combined influence of multiple states on the latency into consideration, thereby providing a more comprehensive guidance for performance improvement” (Liu [0042])
Hargis discloses processing, with a machine-learning model of an offline simulation module, the series of events … to generate a series of modeled outcomes. Hargis does not explicitly disclose processing … the series of events with the simulation delay to generate a series of modeled outcomes
However, Liu discloses the simulation delay. By using the simulated delay latency of Liu in the processing and modeling of Hargis, the combination thus discloses processing, with a machine-learning model of an offline simulation module, the series of events with the simulation delay to generate a series of modeled outcomes.
Regarding Claim 9,
The combination of Hargis/Liu teaches the method of Claim 8 (and thus the rejection of Claim 8 is incorporated). Hargis/Liu further discloses feature selection logic received via a feature engineering user interface in electronic communication with the offline simulation module (Hargis [Page 3 Section “Point-in-time queries”]; “Although we show an Apache Spark implementation of point in time queries in this post, Amazon Athena provides another alternative. With Athena, you can create a temporary table containing your selection criteria, and then use SQL to join that criteria to your offline store feature groups. The SQL query can select the most recent feature values that are older than the targeted event time for each training dataset row.” wherein the existence of SQL queries for selection of feature values dependent on their age reads on receiving such feature selection logic queries through electronic communication with the offline simulation module)
wherein the simulation delay is further generated based on feature selection logic (Liu [0038]; “ In some embodiments, latency factor analyzer 340 may use an additive model to determine the corresponding contributions. For example, the additive model may be a Shapely additive interpretation (SHAP) model. SHAP is a method of interpreting machine learning model predictions by a Shapely value. The Shapely value is a concept in the field of cooperative game theory that measures the contribution of each player to a game. In the case where n players collectively obtain a reward p, the reward p is fairly distributed to each of the n players according to the individual contributions of the players, such contributions being the Shapely value. In general, when interpreting predicted values of a model, the Shapely value is an expected marginal contribution of an instance of a feature used for prediction among all possible coalitions, reflecting the influence on the prediction of the model by the feature associated therewith.
SHAP is an additive model constructed with the inspiration of the Shapely value. The model predicts a target variable y of a sample based on k features of the sample. An ith sample in a sample set is represented as xi, a j.sup.th feature of the sample is represented as x.sub.ij, a target variable predicted value of the model for the sample is represented as y.sub.i, and a baseline of the model is represented as y.sub.base (typically, the mean of predicted target variables for all samples is used as the baseline). Then, an interpreter ƒ of the model may be determined such that the SHAP value conforms to the following equation 1:
y.sub.i=y.sub.base+ƒ(x.sub.i1)+ƒ(x.sub.i2)+ . . . +ƒ(x.sub.ik) (1)
where ƒ(x.sub.ij) is a contribution value of the j.sup.th feature in the sample x.sub.ij for the predicted value y.sub.i. The feature increases the predicted value when the value is greater than 0, and reduces the predicted value when the value is less than 0. Finally, the sum of the model baseline and the contribution values of all features will be equal to the predicted value of the sample. The SHAP value may reflect the influence of each feature of each sample and whether the influence is positive or negative.” wherein simulation delay generated based on some feature selection logic is disclosed
Liu [0031]; “By using method 200, the computing device may identify, in a complex system environment, major factors that increase the latencies of data persistence operations of the system and the degree of influence on the amount of latency by these factors, so as to provide a user with a guidance for improvement of system performance.” wherein the communication of feature influence over electronic communication to provide user guidance reads on feature selection logic received, at least in part, via a feature engineering user interface in electronic communication with the offline simulation module)
Regarding Claim 10,
The combination of Hargis/Liu teaches the method of Claim 9 (and thus the rejection of Claim 9 is incorporated). Hargis/Liu further discloses wherein the feature selection logic is configured as a domain-specific language; (Hagris [Page 3 Section “Point-in-time queries”]; “Although we show an Apache Spark implementation of point in time queries in this post, Amazon Athena provides another alternative. With Athena, you can create a temporary table containing your selection criteria, and then use SQL to join that criteria to your offline store feature groups. The SQL query can select the most recent feature values that are older than the targeted event time for each training dataset row.” wherein the existence of SQL queries for selection of feature values dependent on their age reads on receiving such feature selection logic queries; wherein the feature selection logic being SQL thus reads on domain-specific language)
Regarding Claim 11,
The combination of Hargis/Liu teaches the method of Claim 9 (and thus the rejection of Claim 9 is incorporated). Hargis/Liu further discloses wherein the feature selection logic defines a near real-time feature to simulate in the series of modeled outcomes (Hargis [Page 3 Section “Point-in-time queries”]; “The diagram starts with a set of automated feature pipelines that perform feature transformations and ingest feature records into Feature Store. Pipelines for individual feature groups are independent and can run on varying schedules. One feature group may be refreshed nightly, whereas another is updated hourly, and a third may have updates that are triggered as source data arrives on an input stream, such as an Apache Kafka topic or via Amazon Kinesis Data Streams. Depending on the configuration of your feature groups, the resulting features are made available in an online store, an offline store, or both with automatic synchronization. The offline store provides a secure and scalable repository of features, letting data scientists create training and validation datasets or batch scoring datasets from a set of feature groups that can be managed centrally with a full history of feature values.
PNG
media_image2.png
361
766
media_image2.png
Greyscale
”
Wherein the feature selection logic criteria are associated with real-time features updated hourly or as a real-time input stream)
Regarding Claim 12,
The combination of Hargis/Liu teaches the method of Claim 8 (and thus the rejection of Claim 8 is incorporated). Hargis/Liu further discloses wherein the series of times associated with the series of events include, for a given event of the series of events, a first time associated with a publishing time of the given event and a second time stamp associated with generating, via a pre-processing module, an enriched event from the given event (Hargis [Page 3 Section “Point-in-time queries”]; “The diagram starts with a set of automated feature pipelines that perform feature transformations and ingest feature records into Feature Store. Pipelines for individual feature groups are independent and can run on varying schedules. One feature group may be refreshed nightly, whereas another is updated hourly, and a third may have updates that are triggered as source data arrives on an input stream, such as an Apache Kafka topic or via Amazon Kinesis Data Streams. Depending on the configuration of your feature groups, the resulting features are made available in an online store, an offline store, or both with automatic synchronization. The offline store provides a secure and scalable repository of features, letting data scientists create training and validation datasets or batch scoring datasets from a set of feature groups that can be managed centrally with a full history of feature values.
PNG
media_image2.png
361
766
media_image2.png
Greyscale
” wherein the series of feature events all associated with their respective time series read on a first time associated with publishing time of a given feature id and its associated first event, as well as a second event time associated with publishing data of an enriched event)
Regarding Claim 13,
The combination of Hargis/Liu teaches the method of Claim 12 (and thus the rejection of Claim 12 is incorporated). Hargis/Liu further discloses wherein the series of times associated with the series of events further include a third time stamp associated with generating an outcome of the series of outcomes for the given event via online processing of the series of events (Hargis [Page 3 Section “Point-in-time queries”]; “The diagram starts with a set of automated feature pipelines that perform feature transformations and ingest feature records into Feature Store. Pipelines for individual feature groups are independent and can run on varying schedules. One feature group may be refreshed nightly, whereas another is updated hourly, and a third may have updates that are triggered as source data arrives on an input stream, such as an Apache Kafka topic or via Amazon Kinesis Data Streams. Depending on the configuration of your feature groups, the resulting features are made available in an online store, an offline store, or both with automatic synchronization. The offline store provides a secure and scalable repository of features, letting data scientists create training and validation datasets or batch scoring datasets from a set of feature groups that can be managed centrally with a full history of feature values.
PNG
media_image2.png
361
766
media_image2.png
Greyscale
” wherein the existence of a plurality of event times used for generation of the enriched events training dataset thus reads on at least a third time stamp associated with generating an outcome of the series of outcomes for a given event)
Claims 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Hargis et al. (“Build accurate ML training datasets using point-in-time queries with Amazon SageMaker Feature Store and apache spark” [2021], hereinafter “Hargis” as disclosed in IDS) in view of Liu et al. (US20230401137A1, hereinafter “Liu”) and further in view of Peng et al. (US20210258235A1, hereinafter “Peng”)
Regarding Claim 14,
Hargis discloses A computing system, comprising: one or more processors; and a computer-readable storage medium storing that, responsive to execution by the one or more processors, causes the one or more processors to perform operations including:during an online production process, for each of a plurality of enriched events: (Hargis [Page 3 Section “Point-in-time queries”];
PNG
media_image1.png
662
851
media_image1.png
Greyscale
Wherein SageMaker GoDaddy computing system performs operations for a plurality of enriched events during an online production process)
Hargis does not explicitly disclose but Liu discloses to measure a first delay between a near real-time (NRT) variable state pre-persistence time and a publishing time of an associated event; measure a second delay between an NRT variable state post- persistence time and the NRT variable state pre-persistence time (Liu [0035]; “Causal inference module 320 includes latency predictor 330. Latency predictor 330 may generate a group of estimated latencies for a corresponding group of data persistence operations based on the group of records 310. For example, computing device 110 may train and verify latency predictor 330 using a machine training method and based on historical records of system 120 or a system similar to system 120 until latency predictor 330 is verified to be of sufficient quality (e.g., using actual latencies of the operations) for use in estimating the estimated latencies of the data persistence operations.” wherein a plurality of estimated latencies for groups of data pre and post persistence operations reads on at least second measured latency delay between the NRT variables’ pre and post persistence operations since records span some predetermined period comprised of the data operations both pre and post persistence
Liu [Figure 2];
PNG
media_image4.png
400
355
media_image4.png
Greyscale
Wherein the plurality of records each comprising predetermined periods by which latencies associated with event states of each record are derived thus read on a measured first delay associated with generation of the enriched event record based on at least a first and second timestamp within the predetermined period)
It would have been obvious to modify Hargis’ method of performing operations for a plurality of enriched events in an online dataset production process by incorporating Liu’s latency predictor and its associated plurality of measured delay latencies. One would have been motivated to do so because “estimated latency corresponding to the data persistence operation when determining the corresponding contributions based on the group of records 310 and latency estimates for the group of records … will be more accurate” (Liu [0037])
Hargis/Liu fails to explicitly disclose but Peng discloses to determine a delay latency from the first delay and the second delay; record the delay latency; and during an offline simulation process of the production process through execution of a machine-learning model, determine a simulation delay to apply to the plurality of enriched events, the simulation delay being based on the delay latency (Peng [0036]; “FIG. 3 illustrates a flowchart of a method 300 of training a reinforcement learning model for use in controlling a jitter buffer delay of a streaming session according to some examples of the present disclosure. At operation 310, the simulator may read packet information from a network trace. As previously described, the network trace may be information about packets transmitted and/or received from a real streaming session. Example sessions include video streaming; audio streaming, audio/video streaming, and the like. For example, a real-time communication session such as a SKYPE® call or meeting, a TEAMS® call or meeting, and the like. The network trace may include information about the packets sent and/or received including timestamps and packet sizes; information about the network performance including lost packets, delayed packets, latency, bandwidth, loss, and the like. In some examples, the network trace may include information about the contents of the packets including contents of the packets (captured with user's permission), type of media, encoding type, encoding information such as a playback duration of the media encoded in the packet; and the like”
PNG
media_image7.png
625
469
media_image7.png
Greyscale
Wherein the jitter representing the delay between the respective first and second packet delays over network communication being computed reads on a delay latency computed and recorded between previously established first and second delays
Peng [0039]; “ At operation 360, the jitter buffer state, network state, and previous action are sent to the agent. The network state may be a simulated network state calculated based upon the packet traces. The simulated network state may be a simulated network delay. The jitter buffer state may be a current jitter buffer delay, current received frames in the jitter buffer, total delay of the next media frame, whether the next media frame is concealed or not, whether a next media frame is newly received, and a previous action taken. The agent then feeds the inputs to the first layer of the network, which then produces output according to the weights on the neurons and the output of the activation function. These outputs are then sent to the next layer and so on, until the last layer produces one or more outputs corresponding to the decision. In some examples, the outputs may be a specific decision (stretch, hold, compress). In other examples, the outputs may be probabilities—that is, a probability that each of the actions is the best action given the inputs. In these examples, the output with the highest probability may be chosen. At operation 370, the action chosen may be received from the agent.” wherein the simulated network state comprising a simulated network delay determined based on the current jitter buffer state which, in turn, is determined through the current jitter buffer delay thus reads on a simulation delay applicable to the enriched events (packets) wherein the simulation delay is based in part on the calculated delay latency (jitter buffer delay)
Peng [0045] At operation 520, one or more media frames with media data may be placed into the jitter buffer. For example, a frame may comprise media data from one or more packets. The frame may be placed into the jitter buffer as received or may be pulled from a separate packet buffer periodically to keep the jitter buffer full. If media data is not available for the next playout time period, then a concealment action may be taken. At operation 530 a current jitter-buffer state and network delay may be identified. For example, a current jitter buffer delay, current received frames in the jitter buffer, whether the current frame is newly received, whether current frame is concealed or not, network delay of the current frame, total delay of the current frame (playout time-sending time), and the action taken in the previous step.”)
It would have been obvious to modify Hargis/Liu’ method of performing operations for a plurality of enriched events in an online dataset production process using associated measured delays to additionally determine a delay latency dependent on a first and second delay. One would have been motivated to do so because “the delay between a first and second packet may be different than a delay between the second and a third packet. This is called jitter. Without compensating for jitter, audio quality issues may be perceived by the recipient ” (Liu [0037])
Regarding Claim 15,
The combination of Hargis/Liu/Peng teaches the method of Claim 14 (and thus the rejection of Claim 14 is incorporated). Hargis/Liu/Peng further discloses wherein the simulation delay includes a global constant delay for a set of enriched events and for a set of types of NRT variables. (Peng [0036]; “FIG. 3 illustrates a flowchart of a method 300 of training a reinforcement learning model for use in controlling a jitter buffer delay of a streaming session according to some examples of the present disclosure. At operation 310, the simulator may read packet information from a network trace. As previously described, the network trace may be information about packets transmitted and/or received from a real streaming session. Example sessions include video streaming; audio streaming, audio/video streaming, and the like. For example, a real-time communication session such as a SKYPE® call or meeting, a TEAMS® call or meeting, and the like. The network trace may include information about the packets sent and/or received including timestamps and packet sizes; information about the network performance including lost packets, delayed packets, latency, bandwidth, loss, and the like. In some examples, the network trace may include information about the contents of the packets including contents of the packets (captured with user's permission), type of media, encoding type, encoding information such as a playback duration of the media encoded in the packet; and the like”
PNG
media_image7.png
625
469
media_image7.png
Greyscale
Wherein the jitter representing the delay between the respective first and second packet delays over network communication being computed reads on a delay latency computed and recorded between previously established first and second delays
Peng [0045] At operation 520, one or more media frames with media data may be placed into the jitter buffer. For example, a frame may comprise media data from one or more packets. The frame may be placed into the jitter buffer as received or may be pulled from a separate packet buffer periodically to keep the jitter buffer full. If media data is not available for the next playout time period, then a concealment action may be taken. At operation 530 a current jitter-buffer state and network delay may be identified. For example, a current jitter buffer delay, current received frames in the jitter buffer, whether the current frame is newly received, whether current frame is concealed or not, network delay of the current frame, total delay of the current frame (playout time-sending time), and the action taken in the previous step.”
Peng [0039]; “ At operation 360, the jitter buffer state, network state, and previous action are sent to the agent. The network state may be a simulated network state calculated based upon the packet traces. The simulated network state may be a simulated network delay. The jitter buffer state may be a current jitter buffer delay, current received frames in the jitter buffer, total delay of the next media frame, whether the next media frame is concealed or not, whether a next media frame is newly received, and a previous action taken. The agent then feeds the inputs to the first layer of the network, which then produces output according to the weights on the neurons and the output of the activation function. These outputs are then sent to the next layer and so on, until the last layer produces one or more outputs corresponding to the decision. In some examples, the outputs may be a specific decision (stretch, hold, compress). In other examples, the outputs may be probabilities—that is, a probability that each of the actions is the best action given the inputs. In these examples, the output with the highest probability may be chosen. At operation 370, the action chosen may be received from the agent.” wherein the simulated network state comprising a simulated network delay is determined with a globally stored “current jitter buffer delay” indicative of a delay stored globally across frames marking the current delay of note, thus interpretable as a global constant delay for the current group of NRT variables (current frame))
Regarding Claim 16,
The combination of Hargis/Liu/Peng teaches the method of Claim 14 (and thus the rejection of Claim 14 is incorporated). Hargis/Liu/Peng further discloses wherein the simulation delay includes a constant delay for each enriched event type, the constant delay configured to be based on the recorded delay latency (Peng [0036]; “FIG. 3 illustrates a flowchart of a method 300 of training a reinforcement learning model for use in controlling a jitter buffer delay of a streaming session according to some examples of the present disclosure. At operation 310, the simulator may read packet information from a network trace. As previously described, the network trace may be information about packets transmitted and/or received from a real streaming session. Example sessions include video streaming; audio streaming, audio/video streaming, and the like. For example, a real-time communication session such as a SKYPE® call or meeting, a TEAMS® call or meeting, and the like. The network trace may include information about the packets sent and/or received including timestamps and packet sizes; information about the network performance including lost packets, delayed packets, latency, bandwidth, loss, and the like. In some examples, the network trace may include information about the contents of the packets including contents of the packets (captured with user's permission), type of media, encoding type, encoding information such as a playback duration of the media encoded in the packet; and the like”
PNG
media_image7.png
625
469
media_image7.png
Greyscale
Wherein the jitter representing the delay between the respective first and second packet delays over network communication being computed reads on a delay latency computed and recorded between previously established first and second delays
Peng [0039]; “ At operation 360, the jitter buffer state, network state, and previous action are sent to the agent. The network state may be a simulated network state calculated based upon the packet traces. The simulated network state may be a simulated network delay. The jitter buffer state may be a current jitter buffer delay, current received frames in the jitter buffer, total delay of the next media frame, whether the next media frame is concealed or not, whether a next media frame is newly received, and a previous action taken. The agent then feeds the inputs to the first layer of the network, which then produces output according to the weights on the neurons and the output of the activation function. These outputs are then sent to the next layer and so on, until the last layer produces one or more outputs corresponding to the decision. In some examples, the outputs may be a specific decision (stretch, hold, compress). In other examples, the outputs may be probabilities—that is, a probability that each of the actions is the best action given the inputs. In these examples, the output with the highest probability may be chosen. At operation 370, the action chosen may be received from the agent.”
Peng [0045] At operation 520, one or more media frames with media data may be placed into the jitter buffer. For example, a frame may comprise media data from one or more packets. The frame may be placed into the jitter buffer as received or may be pulled from a separate packet buffer periodically to keep the jitter buffer full. If media data is not available for the next playout time period, then a concealment action may be taken. At operation 530 a current jitter-buffer state and network delay may be identified. For example, a current jitter buffer delay, current received frames in the jitter buffer, whether the current frame is newly received, whether current frame is concealed or not, network delay of the current frame, total delay of the current frame (playout time-sending time), and the action taken in the previous step.” wherein the simulated network state comprising a simulated network delay is determined with a constant “whether current frame is concealed not” which represents a constant Boolean variable state for the jitter buffer delay state)
Regarding Claim 17,
The combination of Hargis/Liu/Peng teaches the method of Claim 14 (and thus the rejection of Claim 14 is incorporated). Hargis/Liu/Peng further discloses wherein the simulation delay includes an adaptive delay generated from a latency delay model (Peng [0036]; “FIG. 3 illustrates a flowchart of a method 300 of training a reinforcement learning model for use in controlling a jitter buffer delay of a streaming session according to some examples of the present disclosure. At operation 310, the simulator may read packet information from a network trace. As previously described, the network trace may be information about packets transmitted and/or received from a real streaming session. Example sessions include video streaming; audio streaming, audio/video streaming, and the like. For example, a real-time communication session such as a SKYPE® call or meeting, a TEAMS® call or meeting, and the like. The network trace may include information about the packets sent and/or received including timestamps and packet sizes; information about the network performance including lost packets, delayed packets, latency, bandwidth, loss, and the like. In some examples, the network trace may include information about the contents of the packets including contents of the packets (captured with user's permission), type of media, encoding type, encoding information such as a playback duration of the media encoded in the packet; and the like”
PNG
media_image7.png
625
469
media_image7.png
Greyscale
Wherein the jitter representing the delay between the respective first and second packet delays over network communication being computed reads on a delay latency computed and recorded between previously established first and second delays
Peng [0039]; “ At operation 360, the jitter buffer state, network state, and previous action are sent to the agent. The network state may be a simulated network state calculated based upon the packet traces. The simulated network state may be a simulated network delay. The jitter buffer state may be a current jitter buffer delay, current received frames in the jitter buffer, total delay of the next media frame, whether the next media frame is concealed or not, whether a next media frame is newly received, and a previous action taken. The agent then feeds the inputs to the first layer of the network, which then produces output according to the weights on the neurons and the output of the activation function. These outputs are then sent to the next layer and so on, until the last layer produces one or more outputs corresponding to the decision. In some examples, the outputs may be a specific decision (stretch, hold, compress). In other examples, the outputs may be probabilities—that is, a probability that each of the actions is the best action given the inputs. In these examples, the output with the highest probability may be chosen. At operation 370, the action chosen may be received from the agent.”
Peng [0045] At operation 520, one or more media frames with media data may be placed into the jitter buffer. For example, a frame may comprise media data from one or more packets. The frame may be placed into the jitter buffer as received or may be pulled from a separate packet buffer periodically to keep the jitter buffer full. If media data is not available for the next playout time period, then a concealment action may be taken. At operation 530 a current jitter-buffer state and network delay may be identified. For example, a current jitter buffer delay, current received frames in the jitter buffer, whether the current frame is newly received, whether current frame is concealed or not, network delay of the current frame, total delay of the current frame (playout time-sending time), and the action taken in the previous step.” wherein the simulation delay comprises in part the simulation delay)
Regarding Claim 18,
The combination of Hargis/Liu/Peng teaches the method of Claim 14 (and thus the rejection of Claim 14 is incorporated). Hargis/Liu/Peng further discloses wherein the simulation delay is based on at least a first probabilistic expectation level and a second probabilistic expectation level of the measured first delay and the measured second delay (Peng [0025]; “ Turning now to FIG. 2, a block diagram of an example agent 110 is shown according to some examples of the present disclosure. In some examples, the agent 110 may be an asynchronous actor-critic (A3C) reinforcement learning model, such as a Reinforcement Neural Network (RNN). There are two parts, an actor network that estimates a policy π(s.sub.t, a.sub.t) with a set of action probability outputs and a critic network that estimates a value function V.sup.π(s.sub.t) showing how good the state is to be in. The agent 110 will use the value estimate along with the reward calculated by the simulator to calculate a loss function that will be used to update the RNN. In some examples, both the actor network and the critic network are updated, in other examples the actor network is updated but not the critic network, and in yet other examples, the critic network is updated but not the actor network. In some examples, multiple worker agents may be used with independent experiences and synchronous network update to speed up the training process and boost the performance. FIG. 2 is one example network structure with example inputs and connections, but one of ordinary skill in the art with the benefit of the present disclosure will appreciate that other network structures may be utilized.
Agent 110 may include an actor network featuring layers 210, 212, 214, 216, and 218. In some examples, the inputs to the model (which starts at layer 210) consist of a current jitter buffer delay jb.sub.t, current received frames in jitter buffer recv.sub.t (e.g., for example, the total playout time of all frames in the buffer), whether the current frame is newly received nr.sub.t, whether current frame is concealed or not c.sub.t, network delay of the current frame n.sub.t, total delay of the current frame (playout time-sending time) b.sub.t, and the action taken in the previous step a.sub.t−1. Apart from nr.sub.t, c.sub.t and a.sub.t−1, the other four components are measured in milliseconds for conformance.” wherein the actions are determined through policies reliant on probabilistic expectations of decisions; wherein the network simulated delay dependent on action taken in the previous step thus reads on the simulation delay based on at least a first and second probabilistic expectation level of the measured first and second delays respectively)
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hargis et al. (“Build accurate ML training datasets using point-in-time queries with Amazon SageMaker Feature Store and apache spark” [2021], hereinafter “Hargis” as disclosed in IDS) in view of Liu et al. (US20230401137A1, hereinafter “Liu”) in view of Peng et al. (US20210258235A1, hereinafter “Peng”) and further in view of Sivaraj et al. (US20200195539A1, hereinafter “Sivaraj”)
Regarding Claim 19,
The combination of Hargis/Liu/Peng teaches the method of Claim 18 (and thus the rejection of Claim 18 is incorporated). Hargis/Liu/Peng fails to explicitly disclose but Sivaraj discloses wherein the first probabilistic expectation level is a 95th percentile rank (P95) (Sivaraj [0065]; “ The models described herein were used to trigger optimized RAN handovers to improve VR latency. The representative results are shown in FIGS. 10A and 10B. A topology of 4 LTE cells with different combinations of network settings was emulated, with the VR application run in this topology. Note that each phone is originally connected to a cell from which it receives the highest RSRP. The test phone streaming 360 degree video over TCP on its FoV-based player initially connects to a cell with the following setting: {RSRP: high, Cell Load: high}. Observed is a baseline MTP latency of 150 ms with a 95th percentile latency of 488 ms.” wherein one of the probabilistic expectation levels by which latency is simulated meets a 95th percentile rank latency)
It would have been obvious to specifically configure Hargis/Liu/Peng’s simulation delay to meet Sivaraj’s predefined first and second probabilistic expectation levels for the measured delays. One would have been motivated to do so because “To make the models more tractable, the latency is divided into bins to evaluate the accuracy of classification using a simple Random Forest Classification model” (Sivaraj [0060]).
Regarding Claim 20,
The combination of Hargis/Liu/Peng teaches the method of Claim 18 (and thus the rejection of Claim 18 is incorporated). Hargis/Liu/Peng fails to explicitly disclose but Sivaraj discloses wherein the second probabilistic expectation level is a 99th percentile rank (P99) (Sivaraj [0060] Turning to aspects of modeling results, machine learning models are developed to estimate and predict RAN latency for the test UE, starting with the fine-grained QXDM datasets. Described herein is the underlying RAN KPIs, impacting latency, that are affected by varying the network settings. These parameters, e.g., the average number of PRBs allocated to the UE, number of RLC PDU segments, RSRP of the UE along with the application bit-rate, are used as the input feature set for the models. To make the models more tractable, the latency is divided into bins to evaluate the accuracy of classification using a simple Random Forest Classification model. The bin boundaries were chosen as 0-10 ms, 10-50 ms, 50-100 ms and 100-200 ms corresponding to 10th, 70th, 90th and 99th percentile latency values of production network data from real-world LTE deployments as shown in FIG. 6A. These bins also correspond to typical latency requirements for VR-like applications.” wherein a bin boundary of 99th percentile latency values of simulated production network data reads on a second probabilistic expectation of a 99th percentile rank latency)
It would have been obvious to specifically configure Hargis/Liu/Peng’s simulation delay to meet Sivaraj’s predefined first and second probabilistic expectation levels for the measured delays. One would have been motivated to do so because “To make the models more tractable, the latency is divided into bins to evaluate the accuracy of classification using a simple Random Forest Classification model” (Sivaraj [0060]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
“Predicting Event Types and Time Intervals for Projects” (US11074529A1) which discloses machine learning inference of delays associated with events according to historical time-series features
“METHOD AND SYSTEM FOR SERVER ASSIGNMENT USING PREDICTED NETWORK METRICS” (US20190132422A1) which discloses a delay latency calculated based on at least first and second delays
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN J KIM whose telephone number is (571) 272-0523.
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, Kieu Vu can be reached on (571) 272-4057. 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.
/JONATHAN J KIM/Examiner, Art Unit 2141
/MATTHEW ELL/Supervisory Patent Examiner, Art Unit 2141