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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.
Applicant's submission filed on 04/01/2026 has been entered.
Examiner’s Note
Regarding 35 USC § 112(f), the Applicant amended claim 1, so the claim no longer interpreted under 35 USC § 112(f).
Response to argument
Applicant's arguments filed 04/01/2026 ("Arguments/Remarks") have been fully considered but they are not persuasive.
Argument – 1: (page: 14) Applicant contends: “Hence, Dirac fails to disclose or suggest each and every limitation as recited in claim 1. Further, none of Narayan, Mundra, or Beyer remedy the deficiencies of Dirac in describing or rendering obvious at least the features "determining that the accessed model training operation has previously been executed by a first processing worker pod", "determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed", "implementing each executing and outputting step that was not successfully completed by the first processing worker pod by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods" or "removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod", as recited in claim 1.”
Regarding the above argument, the Examiner respectfully notes that the prior art of records still teaches majority of the amended claim limitations. Such as, the amended limitation recites:
"determining that the accessed model training operation has previously been executed by a first processing worker pod" and "determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed", Mundra et al., ¶[0056] teaches determining that a previously executed operation was interrupted by detecting a system interrupt and identifying suspended workflow tasks. The temporary workflow task queue stores the state of each suspended task, including that point of execution, thereby teaching determining the last partially completed iteration or execution point of the previously executed operation.
"implementing each executing and outputting step that was not successfully completed by the first processing worker pod by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods", Mundra et al., ¶[0074] teaches resuming execution of previously suspended workflow tasks by using the stored execution states to continue from the last execution point, which shows executing the remaining steps by picking up where the previous execution left off, thereby maintaining seamless continuity between successive processing entities corresponding to the claimed transition between processing worker pods.
In addition, the amended limitation: "removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod", is not disclosed by the prior art of record. Therefore, (Kalathur et al,) is relied upon to teach this limitation, see Claim Rejections - 35 USC § 103 section.
As to the remaining dependent claims, applicant argue that they are allowable due to their respective direct and indirect dependencies upon one of the aforementioned Independent claims. The examiner respectfully disagrees, Independent claims were not allowable as stated in the paragraph above in this “Response to Arguments” section in this office action.
Claim Rejections - 35 USC § 112: New Matter
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and
of the manner and process of making and using it, in such full, clear, concise, and exact terms as to
enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to
make and use the same, and shall set forth the best mode contemplated by the inventor or joint
inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and
process of making and using it, in such full, clear, concise, and exact terms as to enable any person
skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the
same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 10, 13 – 14, 16 and 19 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AlA), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AlA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Specifically,
Claim 1 recites: … first processing worker pod;
Claim 10 recites: …. a second processing worker pod;
Claims 13 – 14 recite: … a fourth one of the plurality of processing worker pods.
Claim 16 recites: … a fifth processing worker pod;
Claims 19 – 20 recite: … a sixth one of the plurality of processing worker pods;
these amended limitations constitutes new matter because the original disclosure does not provide support for the added subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 – 4, 7, 9 – 10, 13 – 16, 19 – 20, 21 – 26 rejected under 35 U.S.C. 103 as being unpatentable over Narayan et al., "Ultron-AutoML: an open-source, distributed, scalable framework for efficient hyper-parameter optimization." in view of Dirac et al., Pub. No.: US10963810B2, Mundra et al., Pub. No.: US20220147388A1 and Kalathur et al., Pub. No.: US20200233550A1.
Regarding claim 1, Narayan teaches: A computing system for optimising a machine learning process, the computing system being implemented using a cluster computing infrastructure comprising a plurality of computing nodes, the computing system comprising at an application level:
(Narayan, page: 6, “For scalability, we rely on the Kubernetes cluster auto-scaler. The cluster [implemented using a cluster computing infrastructure] auto-scaler minimizes node underutilization and therefore compute cost by dynamically commissioning and decommissioning nodes [comprising a plurality of computing nodes,]. Kubernetes can also shift in-progress jobs out of unavailable nodes to available ones. This allows us to effectively leverage intrinsically unreliable computes like pre-emptible GPU nodes which are up to 70% more cost effective than regular nodes for training models”)
a processing master pod arranged to manage the optimisation,
(Narayan, page: 6, “E. Master and Workers The master and worker pods [a processing master pod] execute the HPO [arranged to manage the optimisation] (i.e.: hyper-parameter optimization (HPO)) Job as follows: 1) The master pod samples HP configurations and fetches their scores by calling a stub of the model’s score function as in step 5, Fig. 1. When the stub is called, the framework pushes the HP configurations into the Work queue and the master pod waits for their scores on the Results queue.”)
the processing master pod maintaining a shared work queue comprising a plurality of machine learning model training operations,
PNG
media_image1.png
536
426
media_image1.png
Greyscale
[AltContent: textbox ([the processing master pod maintaining])][AltContent: textbox ([a shared work queue])][AltContent: textbox ([comprising a plurality of machine learning model training operations])](Narayan, fig. 8)
each model training operation comprising an associated set of hyperparameter configurations to be evaluated during the training operation,
(Narayan, page: 1, “Additionally, the models need to be extensively fine-tuned for hyper-parameters such as the learning rate, regularization terms such as drop-out and architecture related choices related to the depth and width. This entails running many Deep Learning training jobs [each model training operation], each with a different hyper-parameter configuration, in parallel, or, if used in conjunction with a hyper-parameter optimization algorithm [comprising an associated set of hyperparameter configurations to be evaluated during the training operation,], sequentially with a lower degree of parallelism.”)
wherein each training operation is configured to be executed for a pre-defined number of iterations;
(Narayan, page: 3, “A. Specifying and Running an HPO Job The user submits a HPO Job via HTTP POST method. The HTTP POST payload, shown in Fig. 2, is a JSON object that fully defines the HPO Job. The JSON object values include the packaged code-base for executing a model training job, the hyper-parameter search space, the choice of hyper-parameter tuning strategy from supported strategies – Random Search, TPE [20], and REINFORCE based methods [32]. The overall computational budget, characterized in terms of number of training jobs [wherein each training operation], is set via the num iterations key [is configured to be executed for a pre-defined number of iterations].”)
a shared repository that stores a plurality of records, each record corresponding to one of the model training operations in the shared work queue; and
(Narayan, page: 7, “1) During training, inside the Data Manager, the data from the object store [a shared repository that stores a plurality of records] is incrementally streamed, passed through the shuffling-augmenting-batching operations and the output batches are pushed into the tf.data Queue. When the Data Manager API Controller receives a request for a set of training batches [each record corresponding to one of the model training operations] (i.e.: The requests from the Data Manager API Controller for training batches represent operations where these batches are dequeued and fed into the model), it dequeues them from the tf.data Queue [in the shared work queue] (i.e.: tf.data Queue (or the underlying pipeline mechanism ensuring that batches are ready for consumption) acts as the shared queue storing the records before they are retrieved for training) and serves them. The pipeline works to ensure that the tf.data Queue is always filled to capacity. The Data Manager is multi-threaded, with a pipeline running in each, all injecting data into the tf.data Queue.”)
a plurality of processing worker pods, each worker pod being in operative communication with the shared work queue and the shared repository, performing operations comprising:
(Narayan, page: 4, “4) The Job Agent acquires resources from the Resource Limiter, launches the master and creates two queues: Work queue, Results queue. 5) The master, on initialization, starts a pool of parallel worker pods [a plurality of processing worker pods]. The master and workers co-ordinate via the Work queue [each worker pod being in operative communication with the shared work queue and the shared repository] (i.e.: the Work queue is where the master enqueues hyperparameter configurations, and the worker pods dequeue these tasks, meaning they are in operative communication with the Work queue), Results queue to run the HPO algorithm to completion 6) Finally, the Completion Manager deletes the master, associated workers, Results queue and Work queue, marking the end of the HPO Job.”)
accessing, from the shared work queue, a model training operation;
(Narayan, page: 4, “4) The Job Agent acquires resources from the Resource Limiter, launches the master and creates two queues: Work queue, Results queue. 5) The master, on initialization, starts a pool of parallel worker pods. The master and workers co-ordinate via the Work queue [accessing, from the shared work queue], Results queue to run the HPO algorithm to completion [a model training operation] (i.e.: each worker pod dequeues a task (i.e., a model training operation) from the Work queue, executes the assigned training job) 6) Finally, the Completion Manager deletes the master, associated workers, Results queue and Work queue, marking the end of the HPO Job.”)
retrieving, from the shared repository, the corresponding record for the accessed model training operation;
(Narayan, page: 7, “This container can also be extended. Models can save checkpoint files within separate folders named as per the respective epochs. As soon as all checkpoint files for an epoch have been written to its corresponding folder, the model can create an indicator file inside it which commands the checkpoint syncer to upload the epoch’s checkpoint folder to the object store. During training [the corresponding record for the accessed model training operation], the checkpoint recovery container retrieves all folders from the object store [retrieving, from the shared repository], sorts them in descending order to get the checkpoint files for the latest epoch.”)
after the pre-defined number of iterations for the accessed model training operation have been executed; and
PNG
media_image3.png
315
353
media_image3.png
Greyscale
[AltContent: textbox ([after the pre-defined number of iterations for the accessed model training operation have been executed;])][AltContent: rect](Narayan, fig. 2)
Narayan does not teach:
for each executed iteration, outputting evaluation result data associated with a corresponding iteration to the shared repository for storage in the corresponding record
determining that the accessed model training operation has previously been executed by a first processing worker pod; determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed.
implementing each executing and outputting step that was not successfully completed by the first processing worker pod by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods
removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod;
Dirac teaches:
for each executed iteration, outputting evaluation result data associated with a corresponding iteration
(Dirac, (col. 48, 53:ff – col. 49. 1:ff), “If the accuracy/quality measures 2630 are satisfactory, the candidate model 2620 may be designated as an approved model 2640 in the depicted embodiment. Otherwise, any of several techniques may be employed in an attempt to improve the quality or accuracy of the model's predictions. Model tuning 2672 may comprise modifying the set of independent or input variables being used for the predictions, changing model execution parameters (such as a minimum bucket size or a maximum tree depth for tree-based classification models), and so on, and executing additional training runs 2618. Model tuning may be performed iteratively using the same training and test sets, varying some combination of input variables and parameters in each iteration [for each executed iteration] in an attempt to enhance the accuracy or quality of the results. In another approach to model improvement, changes 2674 may be made to the training and test data sets for successive training-and-evaluation iterations [outputting evaluation result data associated a corresponding iteration]. For example, the input data set may be shuffled (e.g., at the chunk level and/or at the observation record level), and a new pair of training/test sets may be obtained for the next round of training. In another approach, the quality of the data may be improved by, for example, identifying observation records whose variable values appear to be invalid or outliers, and deleting such observation records from the data set.”)
to the shared repository for storage in the corresponding record
(Dirac, (col. 25 26:ff), “In accordance with the selected distribution strategy and processing plan, a set of resources may be identified for Jk (element 957). The resources (which may include compute servers or clusters, storage devices, and the like) may be selected from the MLS-managed shared pools [to the shared repository for storage in the corresponding record], for example, and/or from customer-assigned or customer-owned pools. JK's operations may then be performed on the identified resources (element 960), and the client on whose behalf Jk was created may optionally be notified when the operations complete (or in the event of a failure that prevents completion of the operations).”)
Dirac and Narayan are related to the same field of endeavor (i.e.: distributed computing architecture). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Dirac with teachings of Narayan to efficiently manage and respond to potential data redundancy across datasets, supporting accurate and timely actions such as notifications to clients (Dirac, Abstract).
Narayan in view of Dirac do not teach:
determining that the accessed model training operation has previously been executed by a first processing worker pod; determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed.
implementing each executing and outputting step that was not successfully completed by the first processing worker pod by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods
removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod;
Mundra teaches:
determining that the accessed model training operation has previously been executed by a first processing worker pod; determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed
(Mundra, “[0056] For example, work-item executor 140 (e.g., as described in connection with FIG. 1) may execute a workflow using ‘n’ worker threads (212-1, 212-2,-212-n), each worker thread executing a workflow task of the workflow. When work-item executor 140 detects system interrupt 304, work-item executor 140 suspend execution of the workflow and stores an identification of each suspended workflow task in temporary workflow task queue 308 [determining that the accessed model training operation has previously been executed by a first processing worker pod]. Temporary workflow task queue 308 also stores the state of each suspended workflow task. The state of a workflow task indicates the point of execution of the workflow tasks including the current value of any variables. In some instances, the point of execution may refer to the last line of code of the workflow task that executed or the next line of code that is to execute [determining a last iteration of the model training operation performed by the first processing worker pod that was partially completed].”)
implementing each executing and outputting step that was not successfully completed by the first processing worker pod by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods
(Mundra, “[0074] At block 444, the client device resumes execution of the set of workflow tasks by the set of worker threads. For example, the client device may initialize execution of the set of workflow tasks stored in the temporary workflow task queue [implementing each executing and outputting step that was not successfully completed by the first processing worker pod] (i.e.: (unsuccessful) suspended workflow tasks stored in workflow task queue). The client device may then use the state information of each workflow task to resume execution the workflow task at the point of execution when the workflow task was suspended [by picking up and executing where the first processing worker pod left off while seamlessly maintaining transition between the processing worker pods] (i.e.: resuming execution of the suspended workflow tasks using the stored state information). For example, the state information may indicate the last line of code of the workflow task that executed. The worker thread may then resume executing the workflow task at the next line of code of the workflow task.”)
Mundra, Narayan and Dirac are related to the same field of endeavor (i.e.: distributed computing architecture). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Mundra with teachings of Narayan and Dirac to add dynamic resource allocation and improves fault tolerance by enabling worker threads to be repurposed during processing delays. (Mundra, Abstract).
Narayan in view of Dirac and Mundra do not teach:
removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod;
Kalathur teaches:
removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod;
(Kalathur, “[0061] Returning to decision 610, if the action is to change or terminate an application then the process determines whether the action is to change or terminate application (decision 670). If the action is to change the application, then decision 670 branches to the ‘Change’ branch which branches down to step 675 to retrieve context data for the screen or page that is displayed in the window containing the application. On the other hand, if the action is to terminate an application, then decision 670 branches to the ‘Terminate’ branch whereupon, at step 690 the process removes context data pertaining to terminated application from memory area 660 [removing all artifacts resulting from the partial completion of the model training operation performed by the first processing worker pod]. FIG. 6 processing thereafter returns to the calling routine (see FIG. 4) at 695.”)
Kalathur, Narayan, Dirac and Mundra are related to the same field of endeavor (i.e.: distributed computing architecture). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Kalathur with teachings of Narayan, Dirac and Mundra to incorporate managing stored data throughout an operation, including retrieval and removal of the data based on the operation state. (Kalathur, Abstract).
Claim 10 recites analogous limitation as claim 1, so is rejected under similar rationale.
Regarding claim 2, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 1.
Dirac further teaches: wherein each model training operation has an associated completion time period within which execution of each of the iterations is to be completed
(Dirac, (col. 18, 52:ff – col. 19. 1:ff), “At t5, the portion of J3 on which J4 depends may be complete, and the client may be notified accordingly. However, J4 also depends on the completion of J2, so J4 cannot be started until J2 completes at t6. J3 continues execution until t8. J4 completes at t7, earlier than t8. The client is notified regarding the completion of each of the jobs corresponding to the respective API invocations API1-API4 in the depicted example scenario. In some embodiments, partial dependencies between jobs may not be supported—instead, as mentioned earlier, in some cases such dependencies may be converted into full dependencies by splitting multi-phase jobs into smaller jobs. In at least one implementation, instead of or in addition to being notified when the jobs corresponding to the API invocations are complete (or when phases of the jobs are complete), clients may be able to submit queries to the MLS to determine the status (or the extent of completion) of the operations corresponding to various API calls. For example, an MLS job [wherein each model training operation] monitoring web page may be implemented, enabling clients to view the progress of their requests (e.g., via a “percent complete” indicator for each job), expected completion times [has an association completion time period within which execution of each of the iterations is to be completed], and so on. In some embodiments, a polling mechanism may be used by clients to determine the progress or completion of the jobs.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Dirac with teachings of Narayan, Mundra and Kalathur for the same reasons disclosed for claim 1.
Claim 25 recites analogous limitation as claim 2, so is rejected under similar rationale.
Regarding claim 3, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 2.
Mundra further teaches: wherein upon expiration of the completion time period, based on determining that the execution of the corresponding iteration is incomplete: the iteration is deemed to not have been successful; and
(Mundra, “[0066] For example, if a worker thread fails to execute a workflow task [the iteration is deemed to not have been successful] within the time interval of the TTL value [wherein upon expiration of the completion time period, based on determining that the execution of the corresponding iteration is incomplete:], the heartbeater may first determine if the worker thread is executing. If the worker thread is executing, then heartbeater may request to renew the token (e.g., reset the time interval of the TTL value). This gives the worker thread more time to execute the workflow task and prevents the client device from having to request the workflow task, receive the workflow task, and re-execute the workflow task from the beginning. If the worker thread has been executing beyond the time interval of the TTL value, the heartbeater thread may terminate the worker thread. The workflow task may be immediately reassigned to another worker thread so that the workflow task may execute within the time interval of the TTL.”)
the model training operation is returned to the shared work queue for access
(Mundra, “[0041]Work-item executor 140 is responsible for executing workers 112. Work-item executor 140 may also manage interrupts and delay requests received from the local execution environment of the client device (e.g., such as processor interrupt), from server host 128, user input, from other devices, and/or the like. For example, when the client device executes a client-side delay, work-item executor 140 pauses execution of workers 112 and causes the workflow tasks [the model training operation] to be transferred to the temporary workflow task queue [is returned to the shared work queue for access]. Work-item executor 140 may then execute worker threads of workers 112 that are configured for other tasks until the client-side delay terminates. Work-item executor 140 may also receive external delays from server host 128 and/or other devices. Work-item executor may follow the same process for facilitating external delays and resuming execution upon the termination of external delays. For external delays, work-item executor 140 may transmit the state information to the device requesting the delay to provide an indication of the state of the workflow execution.”)
and execution by a different one of the plurality of processing worker pods.
(Mundra, “[0066] For example, if a worker thread fails to execute a workflow task [wherein each worker pod is configured to, after executing each iteration of the model training operation] within the time interval of the TTL value, the heartbeater may first determine if the worker thread is executing. If the worker thread is executing, then heartbeater may request to renew the token (e.g., reset the time interval of the TTL value) [reset the completion time period in relation to a subsequent iteration of the model training operation]. This gives the worker thread more time to execute the workflow task and prevents the client device from having to request the workflow task, receive the workflow task, and re-execute the workflow task from the beginning. If the worker thread has been executing beyond the time interval of the TTL value, the heartbeater thread may terminate the worker thread. The workflow task may be immediately reassigned to another worker [and execution by a different one of the plurality of processing worker pods] thread so that the workflow task may execute within the time interval of the TTL.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Mundra with teachings of Narayan, Dirac and Kalathur for the same reasons disclosed for claim 1.
Claim(s) 13, 19 and 26 recite analogous limitation as claim 3, so are rejected under similar rationale.
Regarding claim 4, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 2.
Mundra further teaches: wherein each worker pod is, after executing each iteration of the model training operation, resets the completion time period in relation to a subsequent iteration of the model training operation
(Mundra, “[0066] For example, if a worker thread fails to execute a workflow task [wherein each worker pod is, after executing each iteration of the model training operation] within the time interval of the TTL value, the heartbeater may first determine if the worker thread is executing. If the worker thread is executing, then heartbeater may request to renew the token (e.g., reset the time interval of the TTL value) [resets the completion time period in relation to a subsequent iteration of the model training operation]. This gives the worker thread more time to execute the workflow task and prevents the client device from having to request the workflow task, receive the workflow task, and re-execute the workflow task from the beginning. If the worker thread has been executing beyond the time interval of the TTL value, the heartbeater thread may terminate the worker thread. The workflow task may be immediately reassigned to another worker thread so that the workflow task may execute within the time interval of the TTL.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Mundra with teachings of Narayan, Dirac and Kalathur for the same reasons disclosed for claim 1.
Claim(s) 14, 20 and 24 recite analogous limitation as claim 4, so are rejected under similar rationale.
Regarding claim 7, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 1.
Narayan further teaches: wherein the set of hyperparameter configurations for each model training operation comprises one or more of the following: (a) a combination of hyperparameter input values; [ ] and (d) a search algorithm to be used.
(Narayan, page: 3 – 4, “The user has complete control and flexibility over composing the model training [wherein the set of hyperparameter configurations for each model training operation comprises one or more of the following] code-base, including choice of dependencies. The user can specify these dependencies, including any version of popular ML frameworks such as Pytorch [13], Tensorflow or scikit-learn along with other libraries, in the setup.py file. The Ultron-AutoML framework manages the installation of these dependencies and execution of the training job as a containerized application (refer section V-B). Within the user supplied code-base, the user only needs to write a class implementation for the interface in Fig. 4. The abstract method score takes as argument, hyperparameters [(a) a combination of hyperparameter input values;] which is an HP configuration object and returns a score. B. Bring Your Own Hyperparameter Optimization Algorithm [(d) a search algorithm to be used] The user can specify a custom HPO algorithm by writing a class for the interface based on the abstraction in Fig. 5. The class needs to implement the following methods: • sample hyperparameter candidates takes as argument an integer N and returns a set of HP configurations of size N. • update state takes as argument a set of tuples, whose components comprise a HP configuration and associated ML model validation score, and updates some internal state.”)
(b) a hyperparameter search space; (c) an objective metric to be achieved as a result of the model training operation;
(Narayan, page: 2, “Hyperparameter Optimization (HPO), also referred to as AutoML in the literature, can be cast as the optimization of an unknown, possibly stochastic, objective function mapping the hyper-parameter search space [(b) a hyperparameter search space;] to a real valued scalar, the ML model’s accuracy or any other performance metric on the validation dataset. The search-space can extend beyond algorithm or architecture [(c) an objective metric to be achieved as a result of the model training operation;] specific elements to encompass the space of data pre-processing and data-augmentation techniques, feature selections, as well as choice of algorithms.”)
Claim 23 recites analogous limitation as claim 7, so is rejected under similar rationale.
Regarding claim 9, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 7.
Narayan further teaches: wherein where the set of hyperparameter configurations comprises a search algorithm to be used, this search algorithm corresponds to a random search function or a grid search function.
(Narayan, page: 2, “These techniques are flexible in that they can search over variable size architectures and have shown very promising results for NAS. Gradient based methods specify the objective function as a parametric model and proceed to optimize it with respect to the hyper-parameters via gradient-descent [35], [38], [39]. Abstractly, a generic HPO algorithm [wherein where the set of hyperparameter configurations comprises a search algorithm to be used] distinct from Random Search or Grid Search [this search algorithm corresponds to a random search function or a grid search function] maintains state and repeats steps based on a state-update procedure and a sampling procedure shown in Fig. 1. This abstraction can inform the design of a distributed framework that can support any HPO algorithm.”)
Regarding claim 15, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 10.
Narayan further teaches: wherein the machine learning model is a neural network.
(Narayan, page: 2, “Neural Architecture Search (NAS) is a special type of HPO where the focus is on algorithm driven design of neural network architecture components or cells [26]. Models [wherein the machine learning model] trained with architectures composed of these algorithmically designed neural network cells [is a neural network] have been shown to outperform their hand-crafted counterparts in image recognition, object detection [57], and semantic segmentation [21], underscoring the practical importance of this field.”)
Regarding claim 16, Narayan teaches: A computer storage medium having computer-executable instructions that, upon execution by a processor, cause the processor to at least:
(Dirac, (col. 118 20:ff), “In some embodiments, system memory 9020 may be one embodiment of a computer-accessible medium configured to store program instructions [A computer storage medium having computer-executable instructions] and data as described above for FIG. 1 through FIG. 75 for implementing embodiments of the corresponding methods and apparatus. However, in other embodiments, program instructions and/or data may be received, sent or stored upon different types of computer-accessible media.”)
The rest of the limitations are analogous to claim 1, so are rejected under similar rationale.
Regarding claim 21, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 16.
Narayan further teaches: wherein each worker pod further, upon retrieving the corresponding record for the model training operation and
(Narayan, page: 7, “This container can also be extended. Models can save checkpoint files within separate folders named as per the respective epochs. As soon as all checkpoint files for an epoch have been written to its corresponding folder, the model can create an indicator file inside it which commands the checkpoint syncer to upload the epoch’s checkpoint folder to the object store. During training, the checkpoint recovery container retrieves all folders from the object store [upon retrieving the corresponding record for the model training operation], sorts them in descending order to get the checkpoint files for the latest epoch.”)
determining that the accessed model training operation has previously been executed by a different processing worker pod, determines a last successful iteration of the model training operation;
(Mundra, “[0056] For example, work-item executor 140 (e.g., as described in connection with FIG. 1) may execute a workflow using ‘n’ worker threads (212-1, 212-2,-212-n), each worker thread executing a workflow task of the workflow. When work-item executor 140 detects system interrupt 304, work-item executor 140 suspend execution of the workflow and stores an identification of each suspended workflow task in temporary workflow task queue 308 [determining that the accessed model training operation has previously been executed by a different processing worker pod]. Temporary workflow task queue 308 also stores the state of each suspended workflow task. The state of a workflow task indicates the point of execution of the workflow tasks including the current value of any variables. In some instances, the point of execution may refer to the last line of code of the workflow task that executed or the next line of code that is to execute [determines a last successful iteration of the model training operation].”)
implements the executing and outputting steps in respect of each of the remaining iterations that are not successful, by picking up further processing from a point where the different processing worker pod left off, the transition being seamless, avoiding any duplicated processing and causing a minimization of processing time required for completion of the plurality of machine learning model training operations.
(Mundra, “[0074] At block 444, the client device resumes execution of the set of workflow tasks by the set of worker threads. For example, the client device may initialize execution of the set of workflow tasks stored in the temporary workflow task queue [implements the executing and outputting steps in respect of each of the remaining iterations that are not successful,]. The client device may then use the state information of each workflow task to resume execution the workflow task at the point of execution when the workflow task was suspended [by picking up further processing from a point where the different processing worker pod left off, the transition being seamless, avoiding any duplicated processing and causing a minimization of processing time required for completion of the plurality of machine learning model training operations]. For example, the state information may indicate the last line of code of the workflow task that executed. The worker thread may then resume executing the workflow task at the next line of code of the workflow task.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Mundra with teachings of Narayan, Dirac and Kalathur for the same reasons disclosed for claim 1.
Regarding claim 22, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 16.
Narayan further teaches: wherein the machine learning model is a neural network.
(Narayan, page: 3, “We define the following terms that will be used in the rest of the paper for describing the working and design of the system: A HPO Job refers to a user’s request to execute an HPO algorithm and return the best trained ML model within a computation budget. The user’s request will contain the code base to train an individual ML model (referred to as ML training job) [wherein the machine learning model is a neural network] as a function of a HP configuration and the training datasets. The HP configuration is a dictionary object mapping hyper-parameters to their values. Scores are validation and test metrics of the model trained using a hyper parameter configuration.”)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Narayan in view of Dirac, Mundra, Kalathur and in further view of SREENIVASAN et al., Pub. No.: US20210358638A1, (hereafter SREENIVASAN).
Regarding claim 8, Narayan in view of Dirac, Mundra and Kalathur teach the method of claim 7.
Narayan in view of Dirac, Mundra and Kalathur do not teach:
wherein where the set of hyperparameter configurations comprises a combination of hyperparameter input values, these hyperparameter values are randomly generated.
SREENIVASAN teaches:
wherein where the set of hyperparameter configurations comprises a combination of hyperparameter input values, these hyperparameter values are randomly generated.
(SREENIVASAN, “[0007] Various embodiments are described, wherein training the linear regression model uses a genetic method wherein the set of hyperparameter pairs [comprises a combination of hyperparameter input values] are randomly generated [these hyperparameter values are randomly generated].”)
SREENIVASAN, Narayan, Dirac, Mundra, Kalathur are related to the same field of endeavor (i.e.: distributed computing architecture). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of SREENIVASAN with teachings of Narayan, Dirac, Mundra and Kalathur to adds an optimized model selection process to the system by systematically evaluating multiple hyperparameter pairs to identify the best-performing adherence model. (SREENIVASAN, Abstract).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Allen et al., Pub. No.: US8375389B2.
A multiple resumption events linked to several suspended processes. Each event represents a suspended process and includes an execution time and a resumption time window..
Miller et al., US7653833B1.
A check-pointing for non-clustered workload to make room for a clustered workload that was running on a computer system that has suffered a hardware failure.
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to MATIYAS T MARU whose telephone number is (571)270-0902 or via email: matiyas.maru@uspto.gov. The examiner can normally be reached Monday 8:00am - Friday 4:00pm EST.
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,
Michelle Bechtold can be reached on (571)431-0762. The fax phone number for the organization were 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.
/M.T.M./ Examiner, Art Unit 2148 /MICHELLE T BECHTOLD/Supervisory Patent Examiner, Art Unit 2148
Prosecution Insights