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 .
This action is responsive to the Application filed on April 19, 2024. Claims 1-20 are pending in the case. Claims 1, 2, and 13 are the independent claims.
This action is non-final.
Claim Rejections – 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 2, 3, 11, 13, and 14 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Wang et al. (US 20230216926 A1).
With respect to claims 2 and 13, Wang teaches one or more non-transitory, computer-readable media comprising instructions recorded thereon that, when executed by one or more processors, cause operations comprising a method (e.g. paragraph 0055, computer readable storage medium having computer readable program instructions thereon for causing processor to carry out aspects of present invention), and the method, comprising:
receiving a request for deploying a workflow from a user at a user device, wherein the request comprises (i) the workflow and (ii) one or more criteria for modification of a timeout interval for the workflow (e.g. paragraph 0025, user interacting with cloud computing environment using request-response model; user sending API requests to cloud computing environment; paragraph 0027, setting of specific idle timeout for cloud computing session of particular user based on attributes associated with the user, with the cloud computing session, etc.; paragraph 0029, receiving process attributes including any information associated with the cloud computing process/operation for the cloud computing session; for example, cloud computing session involving building and deploying machine learning pipeline of Fig. 3; paragraph 0032, also receiving user history including user history of actions from prior cloud computing sessions, from current cloud computing session, etc.; user history and process attributes provide basis for acquiring an operation time; i.e. the user may provide a request, such as for implementing a machine learning pipeline/workflow, and where additional data is also received/supplied along with the request, including process attributed data and user history data, which provide a basis/criteria for determining/adjusting a corresponding operation time/timeout interval; paragraph 0041-0042, obtaining attributes associated with user of cloud computing environment and attributes associated with cloud computing session);
initializing the workflow by executing a batch processing task that consumes data from a data store and builds a model state for a machine learning model (e.g. paragraphs 0029-0030, cloud computing session involves building and deploying machine learning pipeline of Fig. 3, which includes a source node, data transformation node, model building node, and visualization node; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; i.e. as shown in Fig. 300, the user may implement/run the machine learning pipeline, where this pipeline includes consumption and transformation of data 320 from a source 310 and building of a model 330, analogous to initializing a workflow by executing batch processing task that consumes data from a data store and builds a model state for a machine learning model);
generating a dynamic runtime workflow parameter based on the one or more criteria, wherein the dynamic runtime workflow parameter has a value configured to dynamically modify based on specific conditions of the workflow (e.g. paragraph 0027, setting specific idle timeout for each cloud computing session based on attributes associated with the user, attributes associated with the cloud computing session, etc.; idle timeout is adjustable during session based on set of actions previously performed by user and predicted set of actions likely to be performed during the cloud computing session; paragraph 0032, acquiring an operation time based on data groups; paragraph 0035, determining predicted time intervals, determining total execution time for action groups; paragraph 0036, predicting time intervales between each action group; paragraph 0038, receiving predicted time interval, action group time, etc., and generating idle timeout based on the information; paragraph 0043, determining idle timeout based on user attributes and cloud computing session attributes; i.e. the system generates an adjustable idle timeout for the specific user/computing session based on information received with the user request/interaction, (i.e. user history and process attributes), which is analogous to generating a dynamic runtime workflow parameter based on criteria with a value configured to dynamically modify based on specific conditions of the workflow);
deploying the workflow by generating a pre-determined number of compute instances, wherein each compute instance is configured with the dynamic runtime workflow parameter and a start time is recorded for each compute instance (e.g. paragraph 0023, infrastructure resources include cloud computing instances; paragraph 0025, user interacting with cloud computing environment; environment monitoring the cloud computing se3ssion to determine whether session is active or has been idle for a predetermined amount of time, referred to as idle timeout; paragraph 0027, setting specific idle timeout for each cloud computing session based on attributes associated with the user, attributes associated with the cloud computing session, etc.; idle timeout is adjustable during session based on set of actions previously performed by user and predicted set of actions likely to be performed during the cloud computing session; paragraphs 0029-0030, cloud computing session involves building and deploying machine learning pipeline of Fig. 3, which includes a source node, data transformation node, model building node, and visualization node; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; paragraph 0040, idle timeout of cloud computing session; paragraph 0043, determining idle timeout; paragraph 0064, user accessing infrastructure resources as part of cloud computing session; i.e. the workflow/ML model building pipeline (of Fig. 3) may be deployed in the cloud computing session of the user using infrastructure resources such as computing instances, where the user’s session using at least one instance also includes an associated idle timeout value, which includes a predetermined amount of time since the user’s last action, and therefore includes a start time (such as beginning at user’s last action) recorded for the compute instance);
modifying, for at least one compute instance, a value of a corresponding dynamic runtime workflow parameter based on the specific conditions of the workflow (e.g. paragraph 0027, adjusting value of idle timeout at particular points in time during the cloud computing session based on actions previously performed and likely actions; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; paragraph 0044, adjusting value of idle timeout during cloud computing session based on predicted set of action groups for user; paragraph 0048-0049, Fig. 6, during idle timeout, determining whether actions detected as part of the cloud computing session during the idle timeout; and if yes, determining action group based on detected actions and adjusting the value of the idle timeout based at least in part on the action group; i.e. during the user’s execution of various actions within the workflow (such as the model building workflow of Fig. 3), the idle timeout value is adjusted/modified based on the detected actions, analogous to modifying a value of a dynamic runtime workflow parameter (i.e. the idle timeout value) based on specific conditions of the workflow (i.e. user actions within the workflow)); and
determining, based on the dynamic runtime workflow parameter and the start time of the at least one compute instance, that the at least one compute instance has met or exceeded a time value indicated by the dynamic runtime workflow parameter (e.g. paragraph 0038, no actions detected during the idle timeout, idle timeout has expired; paragraph 0039, idle timeout expires; if no action detected, continuing until idle timeout has expired).
With respect to claims 3 and 14, Wang teaches all of the limitations of claims 2 and 13 as previously discussed, and further teaches the method further comprising: responsive to determining that the at least one compute instance has met or exceeded the time value, terminating the at least one compute instance of the workflow (e.g. paragraph 0039, if idle timeout expires, stopping the cloud computing session; paragraph 0048, after duration of idle timeout, ending/terminating the cloud computing session).
With respect to claim 11, Wang teaches all of the limitations of claim 2 as previously discussed, and further teaches wherein the one or more criteria comprises a maximum amount of time elapsed since a recorded start time of each compute instance of the workflow before termination of the at least one compute instance (e.g. paragraph 0025, predetermined amount of inactive time referred to as idle timeout; paragraph 0038, no actions detected during the idle timeout, idle timeout has expired; paragraph 0039, idle timeout expires; if no action detected, continuing until idle timeout has expired; if idle timeout expires, stopping the cloud computing session; paragraph 0048, after duration of idle timeout, ending/terminating the cloud computing session; i.e. the idle timeout consists of a predetermined (but adjustable) time range which denotes a maximum amount of time elapsed with no user action (i.e. having a recorded start time corresponding the end of the most recently detected user action) before the cloud computing session (including use of an infrastructure resource such as a computing instance) will be terminated).
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102€, (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1, 4, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Boven et al. (US 20210034581 A1).
With respect to claim 1, Wang teaches a system for continuous update of a machine learning workflow, the system comprising: one or more processors; and a non-transitory, computer-readable medium comprising instructions that, when executed by the one or more processors (e.g. paragraph 0055, computer readable storage medium having computer readable program instructions thereon for causing processor to carry out aspects of present invention), causes operations comprising:
receiving a request for deploying a workflow from a user at a user device , wherein the request comprises (i) the workflow and (ii) one or more criteria for modification of a timeout interval for the workflow (e.g. paragraph 0025, user interacting with cloud computing environment using request-response model; user sending API requests to cloud computing environment; paragraph 0027, setting of specific idle timeout for cloud computing session of particular user based on attributes associated with the user, with the cloud computing session, etc.; paragraph 0029, receiving process attributes including any information associated with the cloud computing process/operation for the cloud computing session; for example, cloud computing session involving building and deploying machine learning pipeline of Fig. 3; paragraph 0032, also receiving user history including user history of actions from prior cloud computing sessions, from current cloud computing session, etc.; user history and process attributes provide basis for acquiring an operation time; i.e. the user may provide a request, such as for implementing a machine learning pipeline/workflow, and where additional data is also received/supplied along with the request, including process attributed data and user history data, which provide a basis/criteria for determining/adjusting a corresponding operation time/timeout interval; paragraph 0041-0042, obtaining attributes associated with user of cloud computing environment and attributes associated with cloud computing session);
initializing the workflow by executing a batch processing task that consumes data from a data store and builds a model state for a machine learning model (e.g. paragraphs 0029-0030, cloud computing session involves building and deploying machine learning pipeline of Fig. 3, which includes a source node, data transformation node, model building node, and visualization node; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; i.e. as shown in Fig. 300, the user may implement/run the machine learning pipeline, where this pipeline includes consumption and transformation of data 320 from a source 310 and building of a model 330, analogous to initializing a workflow by executing batch processing task that consumes data from a data store and builds a model state for a machine learning model);
generating a dynamic runtime workflow parameter based on the one or more criteria, wherein the dynamic runtime workflow parameter has a value configured to dynamically modify based on specific conditions of the workflow (e.g. paragraph 0027, setting specific idle timeout for each cloud computing session based on attributes associated with the user, attributes associated with the cloud computing session, etc.; idle timeout is adjustable during session based on set of actions previously performed by user and predicted set of actions likely to be performed during the cloud computing session; paragraph 0032, acquiring an operation time based on data groups; paragraph 0035, determining predicted time intervals, determining total execution time for action groups; paragraph 0036, predicting time intervales between each action group; paragraph 0038, receiving predicted time interval, action group time, etc., and generating idle timeout based on the information; paragraph 0043, determining idle timeout based on user attributes and cloud computing session attributes; i.e. the system generates an adjustable idle timeout for the specific user/computing session based on information received with the user request/interaction, (i.e. user history and process attributes), which is analogous to generating a dynamic runtime workflow parameter based on criteria with a value configured to dynamically modify based on specific conditions of the workflow);
deploying the workflow by generating a pre-determined number of compute instances, wherein each compute instance is configured with the dynamic runtime workflow parameter and a start time is recorded for each compute instance (e.g. paragraph 0023, infrastructure resources include cloud computing instances; paragraph 0025, user interacting with cloud computing environment; environment monitoring the cloud computing se3ssion to determine whether session is active or has been idle for a predetermined amount of time, referred to as idle timeout; paragraph 0027, setting specific idle timeout for each cloud computing session based on attributes associated with the user, attributes associated with the cloud computing session, etc.; idle timeout is adjustable during session based on set of actions previously performed by user and predicted set of actions likely to be performed during the cloud computing session; paragraphs 0029-0030, cloud computing session involves building and deploying machine learning pipeline of Fig. 3, which includes a source node, data transformation node, model building node, and visualization node; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; paragraph 0040, idle timeout of cloud computing session; paragraph 0043, determining idle timeout; paragraph 0064, user accessing infrastructure resources as part of cloud computing session; i.e. the workflow/ML model building pipeline (of Fig. 3) may be deployed in the cloud computing session of the user using infrastructure resources such as computing instances, where the user’s session using at least one instance also includes an associated idle timeout value, which includes a predetermined amount of time since the user’s last action, and therefore includes a start time (such as beginning at user’s last action) recorded for the compute instance);
modifying, for at least one compute instance, a value of a corresponding dynamic runtime workflow parameter based on the specific conditions of the workflow (e.g. paragraph 0027, adjusting value of idle timeout at particular points in time during the cloud computing session based on actions previously performed and likely actions; paragraph 0034, actions performed (i.e. by user) including edits, views, and runs of the machine learning pipeline 300; paragraph 0044, adjusting value of idle timeout during cloud computing session based on predicted set of action groups for user; paragraph 0048-0049, Fig. 6, during idle timeout, determining whether actions detected as part of the cloud computing session during the idle timeout; and if yes, determining action group based on detected actions and adjusting the value of the idle timeout based at least in part on the action group; i.e. during the user’s execution of various actions within the workflow (such as the model building workflow of Fig. 3), the idle timeout value is adjusted/modified based on the detected actions, analogous to modifying a value of a dynamic runtime workflow parameter (i.e. the idle timeout value) based on specific conditions of the workflow (i.e. user actions within the workflow));
determining, based on the dynamic runtime workflow parameter and the start time of the at least one compute instance, that the at least one compute instance has met or exceeded a time value indicated by the dynamic runtime workflow parameter (e.g. paragraph 0038, no actions detected during the idle timeout, idle timeout has expired; paragraph 0039, idle timeout expires; if no action detected, continuing until idle timeout has expired); and
responsive to determining that the at least one compute instance has met or exceeded the time value, terminating the at least one compute instance of the workflow (e.g. paragraph 0039, if idle timeout expires, stopping the cloud computing session; paragraph 0048, after during of idle timeout, ending/terminating the cloud computing session).
Wang does not explicitly disclose that the machine learning model is configured to identify anomalous events. However, Boven teaches that the machine learning model is configured to identify anomalous events (e.g. paragraph 0113, data analytics module using machine learning techniques to create data science model; paragraphs 0172-0182, describing anomaly detection models as one type of model created by data analytics module 310; paragraph 0198, applying machine learning techniques to training data to derive data science model; paragraph 0200, machine learning techniques producing anomaly detection model; paragraph 0219, data science model configured to detect anomalies; based on output, deriving insights indicating data channels are experiencing anomalous behavior; in response, transmitting notification to appropriate personnel so that the anomaly can be rectified).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Boven in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Boven (directed to a data science platform, i.e. for users to create machine learning models and associated pipelines, including in a cloud computing environment) to include the capability for the user to build, as the machine learning model built by the workflow/pipeline, a model for identifying anomalous events. One of ordinary skill would have been motivated to perform such a modification in order to allow users to exhibit creativity when creating data science model as described in Friedrich (paragraph 0203).
With respect to claims 4 and 15, Wang teaches all of the limitations of claims 2 and 13 as previously discussed. Wang does not explicitly disclose the method further comprising: identifying an anomalous event based on an output of the machine learning model of the workflow; and transmitting, to a remote device, a notification indicative of occurrence of the anomalous event.
However, Boven teaches the method further comprising: identifying an anomalous event based on an output of the machine learning model of the workflow; and transmitting, to a remote device, a notification indicative of occurrence of the anomalous event (e.g. paragraph 0113, data analytics module using machine learning techniques to create data science model; paragraphs 0172-0182, describing anomaly detection models as one type of model created by data analytics module 310; paragraph 0198, applying machine learning techniques to training data to derive data science model; paragraph 0200, machine learning techniques producing anomaly detection model; paragraph 0219, data science model configured to detect anomalies; based on output, deriving insights indicating data channels are experiencing anomalous behavior; in response, transmitting notification to appropriate personnel so that the anomaly can be rectified).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Boven in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Boven (directed to a data science platform, i.e. for users to create machine learning models and associated pipelines, including in a cloud computing environment) to include the capability for the user to build, as the machine learning model built by the workflow/pipeline, a model for identifying anomalous events such that, upon detection/identification of an anomaly based on the model’s output, a notification of the anomaly can be transmitted to appropriate personnel (via a corresponding device). One of ordinary skill would have been motivated to perform such a modification in order to allow users to exhibit creativity when creating data science model as described in Friedrich (paragraph 0203).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Friedrich et al. (US 20210099517 A1).
With respect to claim 12, Wang teaches all of the limitations of claim 2 as previously discussed. Wang does not explicitly disclose the method further comprising receiving, from a remote device, a user input for the pre-determined number of compute instances. However, Friedrich teaches the method further comprising receiving, from a remote device, a user input for the pre-determined number of compute instances (e.g. paragraph 0024, client computing device sending requests for computing task to be performed to cloud computing system; paragraph 0053, set of compute bounds including maximum number of compute instances and minimum number of compute instances, such as a user-specified value).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Friedrich in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Friedrich (directed to using reinforcement learning to scale queue based services, such as scaling number of cloud computing compute instances within a user-defined range) to include the capability to receive, from a user at a remote device, an input setting a predetermined number of compute instances, such as a range defining minimum and maximum numbers of compute instances. One of ordinary skill would have been motivated to perform such a modification in order to more efficiently use computing resources by automatically adjusting to different types of computing tasks and load fluctuations as described in Friedrich (paragraph 0018).
Claims 5, 7-9, 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Provencher et al. (US 20140330783 A1).
With respect to claims 5 and 16, Wang teaches all of the limitations of claims 2 and 13 as previously discussed. Wang does not explicitly disclose the method further comprising: responsive to detecting that a compute instance is terminated, automatically generating a replacement compute instance; and deploying the replacement compute instance.
However, Provencher teaches the method further comprising: responsive to detecting that a compute instance is terminated, automatically generating a replacement compute instance; and deploying the replacement compute instance (e.g. paragraphs 0032-0033, restore operation including creation of new application instance that has characteristics of old application instance and also transfers entire model associated with old application instance to the new application instance; restoration performed in instances where the old application instance becomes defunct and needs to be replaced by a replacement application instance, or if the old application instance is brought down and restored later, etc.; paragraph 0040, detecting failure, such as indicated by loss of heartbeat messages from application instance, and taking proactive steps by initiating corresponding service recovery event including taking the application service offline and allocating another replacement from a pool of available services; paragraph 0060, identifying application instance as failed application instance for removal; paragraph 0061, triggering switchover event in case of failure being detected; paragraph 0062, for each failed application instance, removing association between the model and the application instance; paragraph 0063, selecting replacement application to replace the identified failed application instance; paragraph 0064, model restored to new replacement application, involving replacement with new application instance and removal of suspect application instance, including replacement of failed application instance; alternatively performing kill and restart of application instance; paragraph 0065, model restored to the new application instance).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Provencher in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Provencher (directed to stateful recovery and self-healing) to include the capability to, upon determining that an application/computing instance is terminated/killed, generate and deploy a replacement application/computing instance, including replacing/restoring a failed or otherwise suspect instance running a model with a new instance and restoring the model in the new instance. One of ordinary skill would have been motivated to perform such a modification in order to allow for autonomous self-healing to take proactive steps in response to failure conditions, as described in Provencher (paragraph 0004).
With respect to claims 7 and 18, Wang in view of Provencher teaches all of the limitations of claims 5 and 16 as previously discussed, and further teaches wherein initializing the replacement compute instance comprises refreshing the machine learning model by updating parameters of the model state using historical data (e.g. paragraph 0065, restoring model into new replacement application instance, including retrieving baseline from shared store, retrieving set of changes to the model from storage, and retrieving locally stored changes; restoring model including by restoring baseline along with additional changes to the new application instance; i.e. where restoring a model from a baseline along with additional changes made to the model appears to be analogous to refreshing the model by updating parameters of model state using historical data (i.e. the model baseline plus additional changes)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Provencher in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Provencher (directed to stateful recovery and self-healing) to include the capability to, upon determining that an application/computing instance is terminated/killed, generate and deploy a replacement application/computing instance, including replacing/restoring a failed or otherwise suspect instance running a model with a new instance and restoring the model in the new instance by restoring/refreshing the model using historical data, including a model baseline and changes made to the baseline. One of ordinary skill would have been motivated to perform such a modification in order to allow for autonomous self-healing to take proactive steps in response to failure conditions, as described in Provencher (paragraph 0004).
With respect to claims 9 and 19, Wang teaches all of the limitations of claims 2 and 13 as previously discussed. Wang does not explicitly disclose the method further comprising: receiving values indicative of performance of the machine learning model; and responsive to determining that the values do not meet a minimum threshold performance, causing the machine learning model to be refreshed by updating parameters of the model state using historical data.
However, Provencher teaches the method further comprising: receiving values indicative of performance of the machine learning model; and responsive to determining that the values do not meet a minimum threshold performance, causing the machine learning model to be refreshed by updating parameters of the model state using historical data (e.g. paragraphs 0003-0004, critical failure in simulator; detecting simulator failure conditions and taking proactive steps by assigning new simulator; paragraphs 0008-0009, model associated with the application instance; simulation model; paragraph 0030, detecting failure behavior such as stalling, slowing to a crawl, or failing outright, and adopting proactive steps; paragraphs 0032-0033, restore operation including creation of new application instance that has characteristics of old application instance and also transfers entire model associated with old application instance to the new application instance; restoration performed in instances where the old application instance becomes defunct and needs to be replaced by a replacement application instance, or if the old application instance is brought down and restored later, etc.; paragraph 0040, detecting failure, such as indicated by loss of heartbeat messages from application instance, and taking proactive steps by initiating corresponding service recovery event including taking the application service offline and allocating another replacement from a pool of available services; paragraph 0060, identifying application instance as failed application instance for removal; reasons including failover, loss or delay of heartbeat messages, proactive failure detection, other suspicious behavior; paragraph 0061, triggering switchover event in case of failure being detected; paragraph 0062, for each failed application instance, removing association between the model and the application instance; paragraph 0063, selecting replacement application to replace the identified failed application instance; paragraph 0064, model restored to new replacement application, involving replacement with new application instance and removal of suspect application instance, including replacement of failed application instance; alternatively performing kill and restart of application instance; paragraph 0065, restoring model into new replacement application instance, including retrieving baseline from shared store, retrieving set of changes to the model from storage, and retrieving locally stored changes; restoring model including by restoring baseline along with additional changes to the new application instance; i.e. where detecting that an application instance has stalled, slowed to a crawl, etc. such as indicated by loss or delay of application heartbeat message, appears to be analogous to the application/model failing to meet threshold performance, and where restoring a model from a baseline along with additional changes made to the model appears to be analogous to refreshing the model by updating parameters of model state using historical data (i.e. the model baseline plus additional changes)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Provencher in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Provencher (directed to stateful recovery and self-healing) to include the capability to, upon determining that an application/computing instance is terminated/killed, generate and deploy a replacement application/computing instance, including replacing/restoring a failed or otherwise suspect instance running a model with a new instance and restoring the model in the new instance by restoring/refreshing the model using historical data, including a model baseline and changes made to the baseline. One of ordinary skill would have been motivated to perform such a modification in order to allow for autonomous self-healing to take proactive steps in response to failure conditions, as described in Provencher (paragraph 0004).
With respect to claim 8, Wang teaches all of the limitations of claim 5 as previously discussed. Wang does not explicitly disclose wherein the workflow is preset with a desired replica count such that when one compute instance fails, the replacement compute instance is generated and deployed to maintain the desired replica count.
However, Provencher teaches wherein the workflow is preset with a desired replica count such that when one compute instance fails, the replacement compute instance is generated and deployed to maintain the desired replica count (e.g. paragraph 0011 and 0015, use of a redundant mirrored application instance to be applied as a new application instance to replace an application instance identified for removal; paragraph 0063, original application instance killed and restarted for future use; switching over to new adapter/application instance pair from the ready pool; paragraph 0064, replacement of model to new replacement application instance includes use of session mirroring/redundant mirroring for application instances including a plurality of adapter/application pairs, resulting in new application instance available which replaces the failed application instance; paragraph 0066, when adapter/application instance pair is successfully repaired or restarted it re-enters the ready pool and this is done in parallel to obtaining the new application instance; i.e. the system maintains a predetermined number of mirrored redundant application instances in a ready pool, such as at least one, such that when a currently executing instance fails and/or is terminated, a replacement instance can be deployed for continued use and the failed instance can be repaired and/or restarted and placed back into the ready pool, ensuring that the desired number of mirrored redundant instances is maintained and ready for deployment as a replacement).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Provencher in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Provencher (directed to stateful recovery and self-healing) to include the capability to, upon determining that an application/computing instance is terminated/killed, generate and deploy a replacement application/computing instance, including replacing/restoring a failed or otherwise suspect instance running a model with a new instance, where a predetermined number (i.e. at least one) of mirrored redundant instances is maintained in a ready pool such that when a given instance is terminated, it is replaced by an instance from the pool and the terminated instance is repaired and/or restarted and placed in the pool for use as a future replacement instance. One of ordinary skill would have been motivated to perform such a modification in order to allow for autonomous self-healing to take proactive steps in response to failure conditions, as described in Provencher (paragraph 0004).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Poirier et al. (US 20240202600 A1).
With respect to claims 10 and 20, Wang teaches all of the limitations of claims 2 and 13 as previously discussed. Wang does not explicitly disclose the method further comprising: receiving values indicative of performance of the machine learning model; and responsive to determining that the values do not meet a minimum threshold performance, causing the machine learning model to be retraining the machine learning model by resetting parameters of the model state.
However, Poirier teaches the method further comprising: receiving values indicative of performance of the machine learning model; and responsive to determining that the values do not meet a minimum threshold performance, causing the machine learning model to be retraining the machine learning model by resetting parameters of the model state (e.g. paragraph 0022, machine learning models trained using base set of data and then retrained or fine-tuned with premier data; retraining general case model for specific sub-use case, or with data that is more specific, specialized, confidential, etc.; multiple versions and versions of versions of models stored and managed to efficiently configure, retrain, and finetune models; paragraph 0076, using feedback captured by feedback module to retrain and/or finetune model; paragraph 0098, evaluating model performance, such as system latency, bandwidth, system utilization, etc.; evaluating model is performing poorly such as above threshold latency, providing unsatisfactory response, etc., and triggering model swapping module to swap the model for a different model or different version of the model such as a model that has been trained or fine-tuned on additional datasets; paragraph 0099, fine-tuning of models includes adjusting parameters of trained model on new dataset or during run-time; paragraph 0103, feedback module capturing feedback regarding model performance such as response time, model accuracy, system utilization, etc. and using the feedback to refine models (such as retraining as indicated in paragraph 0076)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Poirier in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Poirier (directed to machine learning model administration and optimization) to include the capability to retrain the model upon determining it does not meet a threshold performance level, including by changing/updating/resetting model parameters (e.g. weights etc.). One of ordinary skill would have been motivated to perform such a modification in order to allow for deploying trained machine learning models with support for specific use case deployments and implementations at scale with efficient processing, as described in Poirier (paragraph 0020-0021).
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Provencher, further in view of Poirier.
With respect to claims 6 and 17, Wang in view of Provencher teaches all of the limitations of claims 5 and 16 as previously discussed, and Provencher further teaches wherein initializing the replacement compute instance comprises resetting parameters of the model state (e.g. paragraph 0065, restoring model into new replacement application instance, including retrieving baseline from shared store, retrieving set of changes to the model from storage, and retrieving locally stored changes; restoring model including by restoring baseline along with additional changes to the new application instance; i.e. where restoring a model from a baseline along with additional changes made to the model appears to be analogous to resetting parameters of model state).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang and Friedrich in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions), to incorporate the teachings of Provencher (directed to stateful recovery and self-healing) to include the capability to, upon determining that an application/computing instance is terminated/killed, generate and deploy a replacement application/computing instance, including replacing/restoring a failed or otherwise suspect instance running a model with a new instance and restoring the model in the new instance by restoring/resetting the model to a previous state, including a state based on a model baseline and changes made to the baseline. One of ordinary skill would have been motivated to perform such a modification in order to allow for autonomous self-healing to take proactive steps in response to failure conditions, as described in Provencher (paragraph 0004).
Wang and Provencher do not explicitly disclose retraining the machine learning model. However, Poirier teaches retraining the machine learning model (e.g. paragraph 0022, machine learning models trained using base set of data and then retrained or fine-tuned with premier data; retraining general case model for specific sub-use case, or with data that is more specific, specialized, confidential, etc.; multiple versions and versions of versions of models stored and managed to efficiently configure, retrain, and finetune models; paragraph 0076, using feedback captured by feedback module to retrain and/or finetune model; paragraph 0098, evaluating model performance, such as system latency, bandwidth, system utilization, etc.; evaluating model is performing poorly such as above threshold latency, providing unsatisfactory response, etc., and triggering model swapping module to swap the model for a different model or different version of the model such as a model that has been trained or fine-tuned on additional datasets; paragraph 0099, fine-tuning of models includes adjusting parameters of trained model on new dataset or during run-time; paragraph 0103, feedback module capturing feedback regarding model performance such as response time, model accuracy, system utilization, etc. and using the feedback to refine models (such as retraining as indicated in paragraph 0076)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Wang, Provencher, and Poirier in front of him to have modified the teachings of Wang (directed to adjusting idle timeout for cloud computing sessions) and Provencher (directed to stateful recovery and self-healing), to incorporate the teachings of Poirier (directed to machine learning model administration and optimization) to include the capability to retrain the model upon determining it does not meet a threshold performance level, including by changing/updating/resetting model parameters (e.g. weights etc.). One of ordinary skill would have been motivated to perform such a modification in order to allow for deploying trained machine learning models with support for specific use case deployments and implementations at scale with efficient processing, as described in Poirier (paragraph 0020-0021).
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. “The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain,” In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting in re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (GCPA 1968)). Further, a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill the art, including nonpreferred embodiments. Merck & Co, v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert, denied, 493 U.S. 975 (1989). See also Upsher-Smith Labs. v. Pamlab, LLC, 412 F,3d 1319, 1323, 75 USPQ2d 1213, 1215 (Fed. Cir, 2005): Celeritas Technologies Ltd. v. Rockwell International Corp., 150 F.3d 1354, 1361, 47 USPQ2d 1516, 1522-23 (Fed. Cir. 1998).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY L STANLEY whose telephone number is (469)295-9105. The examiner can normally be reached on Monday-Friday from 9:00 AM to 5:00 PM CST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abdullah Al Kawsar, can be reached at telephone number (571) 270-3169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/JEREMY L STANLEY/
Primary Examiner, Art Unit 2127
Prosecution Insights