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 .
Remarks
This Office Action is responsive to Applicants' Amendment filed on 03/23/2026, in which claims 1, 13, and 20 are amended. Claims 4, 5, and 14 are newly cancelled. No claims are newly added.
Claims 1-3, 6-13, and 15-20 are currently pending.
Response to Arguments
With regards to the objection to the drawings on the Office Action Summary sheet, this designation was made in error, and Examiner apologizes for the mistake. The drawings filed 03/31/2023 are approved.
With regards to the rejections of claims 1-3, 11, 13, 19, and 20 under 35 U.S.C. 102(a)(1) as anticipated by Kirchner et al. (U.S. Patent Application Publication No. 2022/0004914) (Kirchner), Examiner acknowledges that the claims as amended overcome the rejections. However, as this was done by incorporating limitations from former claims 4, 5, and 14, claims 1-3, 11, 13, 19, and 20 are now rejected under the same basis as former claim 5, that is, under 35 U.S.C. 103 as unpatentable over the combination of Kirchner, Lin et al. “MCUNet: Tiny Deep Learning on IoT Devices” (Lin), and Krishna et al. (U.S. Patent Application Publication No. 2023/0029320) (Krishna), as described below.
Applicant additionally argues that neither Kirchner, nor Lin, nor Krishna teaches the limitations determining a maximum running time for the execution of the one or more exploratory code generation tools based on the specification; controlling the execution of the one or more exploratory code generation tools based on the maximum running time; newly amended into independent claims 1, 13, and 20. Applicant notes that Krishna recites (Krishna [0073]) “In various implementations, hyperparameter computing device 102 can take into account a computational resource limitation, before implementing a second or next set of hyperparameter search operations to sample and select the first set of hyperparameters. In some examples, the computational budget can be expressed in monetarily. In other examples, the computational budget can be expressed as a predetermined number of sampling/resampling cycles”, however Applicant argues that the recited features of Krishna do not teach the aforementioned limitations amended into claims 1, 13, and 20.
Examiner respectfully disagrees. The “computational budget can be expressed as a predetermined number of sampling/resampling cycles” recited by Krishna corresponds to a maximum running time for execution of a hyperparameter generation tool. One of ordinary skill in the art understands that a cycle within a computational system has an approximately predictable running time, so a predetermined number of cycles roughly corresponds to a predetermined amount of time to run. Examiner additionally notes that the relevant limitation determining a maximum running time for the execution of the one or more exploratory code generation tools based on the specification; doesn’t set forth a number of units of time such as a maximum of seconds, minutes, hours, etc. as a metric for a maximum running time, and therefore a maximum of cycles would fall under the broadest reasonable interpretation of the limitation. It would be obvious to combine this feature of Krishna’s hyperparameter generation tool with the code generation tool of Kirchner, for reasons set forth in the rejections below.
Further, Krishna also recites “the computational budget can be expressed in monetarily”, and further recites: (Krishna [0075]) “In examples where the computational budget is expressed monetarily, hyperparameter computing device 102 can determine whether the next sampling cycle will cause the total cost of running these cycles to equal a predetermined cost threshold”. Although it is a more indirect relationship, one of ordinary skill in the art understands that the monetary cost of running a number of cycles in a computational system is correlated with the amount of time it takes to run the cycles, and so a maximum cost budget roughly corresponds to a maximum running time.
Finally, Krishna further recites: (Krishna [0074]) “hyperparameter computing device 102 can deter mine a state of computational resource limitation, such as a computational budget. In examples where the computational budget is a predetermined number of sampling/resampling cycles, hyperparameter computing device 102 can determine whether the next sampling cycle will cause the total number of sampling cycles to equal the predetermined number of sampling cycles. If so, then hyperparameter computing device 102 can prevent the next set of hyperparameter search operations from initializing. Otherwise, hyperparameter computing device 102 can continue with initializing the next hyperparameter search operation”. This corresponds to the limitation controlling the execution of the one or more exploratory code generation tools based on the maximum running time;. Krishna teaches controlling the execution of a hyperparameter generation tool based on a maximum number of cycles, which corresponds to controlling the execution of a generative tool based on a maximum running time. It would be obvious to combine this feature of Krishna’s hyperparameter generation tool with the code generation tool of Kirchner, for reasons set forth in the rejections below.
Prior Art
The following references are used for prior art claim rejections:
Kirchner et al. (U.S. Patent Application Publication No. 2022/0004914)
Lin et al. “MCUNet: Tiny Deep Learning on IoT Devices”
Krishna et al. (U.S. Patent Application Publication No. 2023/0029320)
Saha et al. “SapientML: Synthesizing Machine Learning Pipelines by Learning from Human-Written Solutions”
Langford et al. (U.S. Patent Application Publication No. 2023/0419189)
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.
Claims 1-3, 11, 13, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kirchner et al. (U.S. Patent Application Publication No. 2022/0004914), hereinafter Kirchner, in view of Lin et al. “MCUNet: Tiny Deep Learning on IoT Devices”, hereinafter Lin, further in view of Krishna et al. (U.S. Patent Application Publication No. 2023/0029320), hereinafter Krishna.
Regarding claim 1,
Kirchner teaches A method, executable by a processor of a system, comprising: ((Kirchner Abstract) “An embodiment of the invention may include a method, computer program product, and system for creating a data analysis tool. The method may include a computing device”)
receiving an input dataset ((Kirchner [0033]) “Auto-AI generation program 112 is an automated machine learning program that is capable of generating one or more AI pipelines based on a dataset, such as user data 164”) associated with a machine learning (ML) task; ((Kirchner [0029]) “User data 164 may be any type of data that a user wants to perform data analysis on using machine learning or artificial intelligence techniques”)
generating a first ML pipeline associated with the ML task by executing a generative code generation tool; ((Kirchner [0033]) “Auto-AI generation program 112 is an automated machine learning program that is capable of generating one or more AI pipelines based on a dataset, such as user data 164”, (Kirchner [0048]) “The code editor may display the editable code used in non-native format of the AI pipeline to a user…the user may confirm that the generated code is acceptable”, the Auto-AI generation program generates code, including in native and non-native formats)
determining a set of pipeline components … associated with the ML task by executing one or more exploratory code generation tools; ((Kirchner [0033]) “the internal optimization module 114 is a machine learning model trained to select components of an AI pipeline based on the type of data being evaluated, as well as statistical characteristics of the data that may lend itself to a specific element (e.g., model) or set of elements suited for the data. Internal optimization module 114 may compose a pipeline or a portion thereof by selecting from one or more libraries of transformers, feature unions, and estimators, to improve predictive performance”, the internal optimization module corresponds to an exploratory code generation tool, as it explores the libraries, feature unions, and estimates to select pipeline components to generate)
selecting a pipeline component from the set of pipeline components; ((Kirchner [0033]) “Auto-AI generation program 112 may leverage machine learning techniques to select and optimize elements of an AI pipeline based on scores of previously developed AI piplines contained in history database 30”)
modifying the first ML pipeline based on the selection ((Kirchner [0047]) “Referring to step 340, auto-AI conversion program 120 may generate an AI pipeline in the non-native format. Generation of the pipeline may be performed by ordering the constructors for each of the extracted elements based on the order used in auto-AI generation program”, an order of constructors for extracted elements corresponds to a modification of the pipeline based on the previously selected of pipeline elements (i.e. components)) to generate a second ML pipeline; ((Kirchner [0048]) “Referring to step 350, auto-AI conversion program 120 may display the non-native format to the user in a code editor using user interface 162 and user interface 155. The code editor may display the editable code used in non-native format of the AI pipeline to a user, which may allow the user to read and/or edit the code”, (Kirchner [0049]) “Referring to step 360, auto-AI conversion program 120 may determine whether a user has edited the code”, (Kirchner [0050]) “Referring to step 370, the newly created code may be evaluated similarly to each of the other AI pipelines by auto-AI generation program 112”, user modification of a generated AI pipeline corresponds to modification of a first ML pipeline to generate a second ML pipeline)
determining a first performance metric by executing the first ML pipeline on the input dataset; ((Kirchner [0042]) “The display may score each of the AI pipelines created in steps 210 through 230 and display a ranking of the pipelines in order along with their score”)
determining a second performance metric by executing the second ML pipeline on the input dataset; ((Kirchner [0050]) “Referring to step 370, the newly created code may be evaluated similarly to each of the other AI pipelines by auto-AI generation program 112. For example, the newly created code may be optimized, scored, and displayed, using the processes outlined in steps 220 through 240. This may enable the user to compare the new code with each of the other auto-AI models using similar metrics”)
and controlling an electronic device to render an ML pipeline recommendation as one of the first ML pipeline or the second ML pipeline, based on a comparison of the first performance metric with the second performance metric, ((Kirchner [0042]) “The display may score each of the AI pipelines created in steps 210 through 230 and display a ranking of the pipelines in order along with their score”, (Kirchner [0050]) “Referring to step 370, the newly created code may be evaluated similarly to each of the other AI pipelines by auto-AI generation program 112. For example, the newly created code may be optimized, scored, and displayed, using the processes outlined in steps 220 through 240. This may enable the user to compare the new code with each of the other auto-AI models using similar metrics”, a ranking of first AI pipelines, including newly created (modified) code for an AI pipeline, based on score and metrics, corresponds to a recommendation of the higher-ranking AI pipeline)
Lin teaches the following further limitations that Kirchner does not teach:
receiving a specification that includes computational resource constraints associated with the system and performance requirements associated with the ML task; (Lin Pg. 7, Table 4 shows various microcontrollers with individual resource constraints that were each used for testing, as well as corresponding performance)
PNG
media_image1.png
226
998
media_image1.png
Greyscale
determining a set of pipeline components based on the specification and being associated with the ML task … ((Lin Abstract) “TinyNAS adopts a two-stage neural architecture search approach that first optimizes the search space to fit the resource constraints, then specializes the network architecture in the optimized search space”, (Lin Pg. 4) “We train one super network that contains all the possible sub-networks through weight sharing and use it to estimate the performance of each sub-network. We then perform evolution search to find the best model within the search space that meets the on-board resource constraints while achieving the highest accuracy”, a sub-network corresponds to a pipeline component)
wherein the one or more exploratory code generation tools are executed to perform a search over an optimization space of pipeline components ((Lin Abstract) “TinyNAS adopts a two-stage neural architecture search approach that first optimizes the search space to fit the resource constraints, then specializes the network architecture in the optimized search space”) and determine the set of pipeline components based on the search ((Lin Pg. 4) “After search space optimization for each memory constraint, we perform one-shot neural architecture search [4, 18] to efficiently find a good model, reducing the search cost by 200× [6]. We train one super network that contains all the possible sub-networks through weight sharing and use it to estimate the performance of each sub-network”, a super network containing sub-networks corresponds to a set of pipeline components)
At the time of filing, one of ordinary skill in the art would have motivation to combine Kirchner and Lin by taking the method for generating ML pipelines, taught by Kirchner, and including factoring in computational resource constraints when determining possible model options, taught by Lin, as Lin teaches: (Lin Pg. 10) “Our work is expected to enable tiny-scale deep learning on microcontrollers and further democratize deep learning applications…Thanks to the low cost and large quantity (250B) of commercial microcontrollers, we can bring AI applications to every aspect of our daily life, including personalized healthcare, smart retail, precision agriculture, smart factory, etc.”, that is, that consideration of resource constraints allows for application of the model generation technique on cheaper hardware, increasing the scope of possible applications and uses. Such a combination would be obvious.
Krishna teaches the following further limitations that neither Kirchner, nor Lin teaches:
determining a maximum running time for the execution of the one or more exploratory code generation tools based on the specification; ((Krishna [0073]) “hyperparameter computing device 102 can take into account a computational resource limitation, before implementing a second or next set of hyperparameter search operations to sample and select the first set of hyperparameters…the computational budget can be expressed as a predetermined number of sampling/resampling cycles”, a maximum number of computational cycles corresponds to a maximum running time)
and controlling the execution of the one or more exploratory code generation tools based on the maximum running time; ((Krishna [0074]) “before hyperparameter computing device 102 initializes another set of hyperparameter search operations, hyperparameter computing device 102 can determine a state of computational resource limitation, such as a computational budget. In examples where the computational budget is a predetermined number of sampling/resampling cycles, hyperparameter computing device 102 can determine whether the next sampling cycle will cause the total number of sampling cycles to equal the predetermined number of sampling cycles. If so, then hyperparameter computing device 102 can prevent the next set of hyperparameter search operations from initializing”)
At the time of filing, one of ordinary skill in the art would have motivation to combine Kirchner, Lin, and Krishna by taking the method for generating ML pipelines, including a specification with computational resource constraints and searching over an optimization space for model components, taught jointly by Kirchner and Lin, and including using a maximum running time for the search in response to a computational resource limitation, taught by Krishna, as doing so allows for the search process to be made resource aware with minimally invasive changes, as a maximum execution time for a software application is well-known in the art and relatively trivial to implement. Such a combination would be obvious.
Regarding claim 2,
Kirchner, Lin, and Krishna jointly teach The method according to claim 1,
Kirchner further teaches:
wherein the first ML pipeline includes: a first plurality of pipeline components to represent a first set of transformations for the input dataset, ((Kirchner [0021]) “Such AI pipelines may include some combination of preprocessing data (e.g., ingestion of data, tagging of data, classification of data, preparation of data)”, broadest reasonable interpretation of transformations for an input dataset includes preprocessing such as preparation of data)
and a first model selection operation for the ML task ((Kirchner [0040]) “One or more models may be selected by an AI module of auto-AI generation program 112 based on the results and methods used in creating the preprocessing element from steps 210”)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, and Krishna for the parent claim of claim 2, claim 1. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claim 3,
Kirchner, Lin, and Krishna jointly teach The method according to claim 1,
Kirchner further teaches:
wherein the second ML pipeline includes: a second plurality of pipeline components to represent a second set of transformations for the input dataset, ((Kirchner [0044]) “extraction of pipelines from auto-AI generation program 112 by auto-AI conversion program 120 may occur. Extraction of the pipeline retrieves each element (e.g., data preprocessing modules, AI models, transformer modules) from the AI pipeline created in steps 210-240. In extraction of the pipeline may include the models, transformers, and data preprocessing techniques chosen by auto-AI generation program 112, as well ordering of such elements”, extraction of data preprocessing modules in the generation of the second ML pipeline corresponds to a second plurality of pipeline components that represent dataset transformations)
and a second model selection operation for the ML task ((Kirchner [0044]) “extraction of pipelines from auto-AI generation program 112 by auto-AI conversion program 120 may occur. Extraction of the pipeline retrieves each element (e.g., data preprocessing modules, AI models, transformer modules) from the AI pipeline created in steps 210-240. In extraction of the pipeline may include the models, transformers, and data preprocessing techniques chosen by auto-AI generation program 112, as well ordering of such elements”, extraction of models in the generation of the second ML pipeline corresponds to a second model selection operation)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, and Krishna for the parent claim of claim 3, claim 1. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claim 11,
Kirchner, Lin, and Krishna jointly teach The method according to claim 1,
Kirchner further teaches:
wherein the first ML pipeline is modified further based on hyperparameters of the selected pipeline ((Kirchner [0033]) “Once these elements are selected, external optimization module 116 may select additional components of the AI pipeline to provide additional optimization. External optimization module 116 may tune transformers and estimators which provide hyperparameter range information to a parameter optimizer”)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, and Krishna for the parent claim of claim 11, claim 1. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claims 13 and 19,
Claims 13 and 19 recite a non-transitory computer-readable storage medium storing instructions for performing the function of the method of claims 1 and 11, respectively. Specifically, claim 13 recites One or more non-transitory computer-readable storage media configured to store instructions that, in response to being executed, cause a system to perform operations, the operations comprising: [the method of claim 1]. Kirchner recites: (Kirchner [0086]) “The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention”.
All other limitations in claims 13 and 19 are substantially the same as those in claims 1 and 11, respectively, therefore the same rationale for rejection applies.
Regarding claim 20,
Claim 20 recites a system comprising a processor and a memory for performing the function of the method of claim 1. Specifically, claim 20 recites A system, comprising: a memory configured to store instructions; and a processor coupled to the memory and configured to execute the instructions to perform a process comprising: [the method of claim 1]. Kirchner recites: (Kirchner [0055]) “The programs…are stored in persistent storage 908 for execution by one or more of the respective computer processors 904 via one or more memories of memory 906.”.
All other limitations in claim 20 are substantially the same as those in claim 1, therefore the same rationale for rejection applies.
Claims 6-9, 12, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kirchner, in view of Lin, further in view of Krishna, further in view of Saha et al. “SapientML: Synthesizing Machine Learning Pipelines by Learning from Human-Written Solutions”, hereinafter Saha.
Regarding claim 6,
Kirchner, Lin, and Krishna jointly teach The method according to claim 1, further comprising:
Kirchner further teaches:
generating, by using the one or more exploratory code generation tools, performance data associated with the set of pipeline components; ((Kirchner [0032]) “Auto-AI scoring program 140 is a program that scores the performance of an AI pipeline. Auto-AI scoring program 140 may use any number of performance metrics to score the accuracy, precision, and any other relevant metrics in order to assess and rank each AI pipeline in comparison to each other, such as R2, F1, ROC AUC, and Precision scores”)
selecting the pipeline component from the set of pipeline components based on the performance data, ((Kirchner [0033]) “Auto-AI generation program 112 may leverage machine learning techniques to select and optimize elements of an AI pipeline based on scores of previously developed AI piplines contained in history database 30”)
Saha teaches the following further limitations that neither Kirchner, nor Lin, nor Krishna teaches:
wherein the performance data includes a performance score for each pipeline component of the set of pipeline components, ((Saha Pg. 4) “The first stage, called pipeline seeding, uses the skeleton predictor derived through meta-learning on the meta-corpus, to independently predict the suitability of each ML component to appear in an ML pipeline for the given dataset, based on the meta-features of the dataset”)
and the performance score for the pipeline component is a maximum value in the performance data ((Saha Pg. 7) “we design a learning-to-rank sub-model that considers all the meta-features Φ to rank all the model components in our corpus…SapientML first computes the set of meta-features, Φ from 𝐷 and passes it to the skeleton predictor (Λ), which returns…a ranked-list of the model components 𝐶′m…Finally SapientML selects Top-𝑘 models from 𝐶′m”, selecting the top ranked pipeline components corresponds to the performance score for the pipeline component being a maximum value)
At the time of filing, one of ordinary skill in the art would have motivation to combine Kirchner, Lin, Krishna, and Saha by taking the method for generating ML pipelines, jointly taught by Kirchner, Lin, and Krishna, and including generating scores for individual pipeline components, taught by Saha, as Saha teaches: (Saha Pg. 6) “We use the following insights to design our skeleton predictor. First, a pipeline may require several FE components and in many cases the decision of using a particular FE component can be made based on a few meta-features without depending on other FE components. Although occasionally there can be some dependencies between the ML components, our experimental results show that this design decision leads to faster generation of pipelines without sacrificing accuracy”, that is, that consideration of pipeline components based on the individual suitability of each component allows for faster pipeline generation. Such a combination would be obvious.
Regarding claim 7,
Kirchner, Lin, Krishna, and Saha jointly teach The method according to claim 6,
Saha further teaches:
wherein the set of pipeline components includes a set of function calls corresponding to a set of ML models ((Saha Pg. 5) “We primarily distinguish two types of components: feature engineering (FE) and MODEL. The automatic labeling process involves two steps: i) extracting the API name, and ii) identifying whether a particular API is an FE or a MODEL component”, (Saha Pg. 2) “A pipeline component 𝑐 ∈ C is comprised of one or more API calls”, (Saha Pg. 5) “we first heuristically identify a criteria line (𝑙𝑐𝑟), which performs the final prediction task…𝑙𝑐𝑟 is typically a call to the predict API function”, the set of model pipeline components which are API call which includes API function calls corresponds to the set of pipeline components including function calls which correspond to ML models)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, Krishna, and Saha for the parent claim of claim 7, claim 6. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claim 8,
Kirchner, Lin, Krishna, and Saha jointly teach The method according to claim 7,
Saha further teaches:
wherein the performance score measures a prediction metric or a training time of a corresponding ML model of the set of ML models for the input dataset ((Saha Pg. 6) “A pipeline skeleton (𝑆) is a (unordered) set of plausible ML components that includes zero or more FE components and one model component (Definition 4.3). To predict the ML components in 𝑆, SapientML uses a meta-learning model, called the skeleton predictor, trained during the offline meta-training phase. The skeleton predictor is architected as a set of sub-models, each of which learns a mapping between properties (meta-features) of a dataset 𝐷 and the likelihood of a specific ML component (meta-target) appearing in a pipeline for 𝐷”, a likelihood of a predicted ML component, including a model component, corresponds to a prediction metric of a corresponding ML model in a set)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, Krishna, and Saha for the parent claim of claim 8, claim 7. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claim 9,
Kirchner, Lin, Krishna, and Saha jointly teach The method according to claim 7,
Saha further teaches:
parsing content of the first ML pipeline to determine a reference to a first ML model via a function call in the content; ((Saha Pg. 5) “to remove the noise in each executable pipeline, 𝑃, we first heuristically identify a criteria line (𝑙𝑐𝑟), which performs the final prediction task. In pipelines using the popular python ML libraries such as Scikit-learn[34] and XGBoost [48], 𝑙𝑐𝑟 is typically a call to the predict API function”)
and selecting, from the set of function calls, a function call to a second ML model as the pipeline component based a comparison of a performance score for the first ML model with other ML models of the set of ML models ((Saha Pg. 5) “To improve the performance score of a denoised pipeline 𝑃𝑐𝑙𝑒𝑎𝑛 with model 𝑐𝑚, our data augmentation technique systematically replaces the model 𝑐𝑚 in 𝑃𝑐𝑙𝑒𝑎𝑛 by each viable model in the corpus, C𝑚 = {𝑐1𝑚, ..., 𝑐𝑏𝑚} one at a time, to create a set of candidate pipelines P𝑚𝑢𝑡𝑎𝑡𝑒𝑑 = {𝑃1𝑐𝑙𝑒𝑎𝑛 ... 𝑃𝑏c𝑙𝑒𝑎𝑛}…Each mutated pipeline in P𝑚𝑢𝑡𝑎𝑡𝑒𝑑 is run on the corresponding dataset, and the best mutated pipeline, 𝑃𝑏𝑒𝑠t𝑐𝑙𝑒𝑎𝑛, showing the highest improvement in the performance score replaces the original pipeline in the corpus”)
At the time of filing, one of ordinary skill in the art would have motivation to combine the method jointly taught by Kirchner, Lin, Krishna, and Saha for the parent claim of claim 9, claim 7. No new embodiments are introduced, so the reason to combine is the same as for the parent claim.
Regarding claim 12,
Kirchner, Lin, and Krishna jointly teach The method according to claim 1,
Saha teaches the following further limitations that neither Kirchner, nor Lin, nor Krishna teaches:
wherein the modification includes changes associated with a variable name, a model class, and a module path of a pipeline component of the first ML pipeline (Saha Fig. 2 shows a modified pipeline including variable names (such as __model), model class (such as CatBoostClassifier), and module path (from catboost import CatBoostClassifier))
PNG
media_image2.png
723
1080
media_image2.png
Greyscale
At the time of filing, one of ordinary skill in the art would have motivation to combine Kirchner, Lin, Krishna, and Saha by taking the method for generating ML pipelines, jointly taught by Kirchner, Lin, and Krishna, and including modifying variable names, model classes, and module paths when searching for more optimal pipelines, taught by Saha, as variables, classes, and module paths are well-known constructs in high-level programming languages for organizing code in a structured and understandable way for a user, providing the predictable benefit of making the changes to a pipeline in a manner that is understandable and customizable for a skilled user. Such a combination would be obvious.
Regarding claims 15-18,
Claims 15-18 recite a non-transitory computer-readable storage medium storing instructions for performing the function of the method of claims 6-9, respectively. All other limitations in claims 15-18 are substantially the same as those in claims 6-9, respectively, therefore the same rationale for rejection applies.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kirchner, in view of Lin, further in view of Krishna, further in view of Saha, further in view of Langford et al. (U.S. Patent Application Publication No. 2023/0419189), hereinafter Langford.
Regarding claim 10,
Kirchner, Lin, Krishna, and Saha jointly teach The method according to claim 7,
Langford teaches the following further limitations that neither Kirchner, nor Lin, nor Krishna nor Saha teaches:
wherein each ML model of the set of ML models is one of:
a single layer of an ML model with hyperparameter optimization,
a stack of two layers of the ML model,
an ensemble of a single layer of two ML models,
or an ensemble of two layers of the two ML models ((Langford [0005]) “The instructions also cause the processor to, based on the inputs, generate stacked machine learning model pipeline architectures which contain at least two layers, with each layer including multiple ones of the machine learning models that may be used and to generate possible hyperparameter values for the generated stacked machine learning model pipeline architectures”, ((Langford [0023]) “With stacked machine learning model ensembles, the ensembles have multiple layers rather than a single layer. A layer may refers to a set of machine learning models (typically greater than one model)”, a layer in a stacked machine learning model pipeline which is a set of machine learning models corresponds to an ensemble of a single layer of two ML models or an ensemble of two layers of the two ML models)
At the time of filing, one of ordinary skill in the art would have motivation to combine Kirchner, Lin, Krishna, Saha, and Langford by taking the method of claim 7, taught jointly by Kirchner, Lin, Krishna, and Saha, and including the set of machine learning models having ensembles as options, taught by Langford, as Langford teaches: (Langford [0022]) “Because a single machine learning model may not be well-suited for making predictions for a data set, machine learning ensembles that include multiple machine learning models have been developed”. Such a combination would be obvious.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rawat et al. (U.S. Patent Application Publication No. 2022/0198222) discloses a method of automatic generation of ensembles of AI pipelines.
Bansal et al. (U.S. Patent Application Publication No. 2021/0097444) discloses methods for automatic machine learning pipeline generation and exploration, including setting a maximum amount of time for pipeline exploration or training.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTOR A NAULT whose telephone number is (703) 756-5745. The examiner can normally be reached M - F, 12 - 8.
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, Miranda Huang can be reached at (571) 270-7092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/V.A.N./Examiner, Art Unit 2124
/Kevin W Figueroa/Primary Examiner, Art Unit 2124
Prosecution Insights