.
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 .
DETAILED ACTION
This action is in response to the amended filing on 07/20/2026. Claims 1-20 are pending for examination.
Specification
Acknowledgment is made to the changes of the specification filed on 07/20/2026 in regards to an amendment of paragraph [0028]. The amendment to the specification is accepted.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 and 11 are rejected on the grounds of nonstatutory double patenting as being
unpatentable over claims 1 and 8 of Copending Application No. 18/318,057 and in view of Babu
et al (US 20190102700 A1, hereinafter Babu) and further in view of Khare et al. (US 11249827B2, hereinafter Khare).
This is a provisional nonstatutory patenting rejection.
Although the claims are not identical, they are not patentably distinct from each other
because the claims of the present invention are similar in scope to the claims of copending
Application No. 18/318,057. For example, the table below shown similarity and different
between the instant application and the copending application 18/318,057.
18/318,052 (Instant Application)
18/318,057
1. A method for application programming interface (API) based machine learning model publication, the method comprising: receiving, by a machine learning model management (MLMM) system from a client device through an API of the MLMM system, a request to publish a machine learning model trained using a third-party machine learning modeling application, the MLMM system having a processor and a non-transitory computer-readable medium, the request containing a machine learning model package; processing, by the MLMM system, the machine learning model package to obtain the machine learning model in a first format; converting, by the MLMM system, the machine learning model to a standard format supported by the MLMM system, the standard format being different from the first format; generating, by the MLMM system, a docker image of the machine learning model in the standard format; and posting, by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster.
8) A method for format-agnostic publishing of a machine learning model, comprising: a processor; a non-transitory computer-readable medium; and stored instructions translatable by the processor for executing: receiving an electronic request to publish a machine learning model which is trained in a source computing environment, the request comprising a machine learning model schema and a machine learning model package comprising one or more electronic files; publishing, to a target computing environment which is different from the source computing environment, the machine learning model based on the machine learning model schema and the machine learning model package, comprising: preprocessing the electronic request, the preprocessing comprising determining a validating method based at least on one of the machine learning model schema or the machine learning model package contained in the electronic request; and validating, using the validating method determined in the preprocessing, the machine learning model schema and the machine learning model package to determine whether the electronic request to publish the machine learning model is valid; wherein, if the electronic request to publish the machine learning model is valid, converting the machine learning model to a target machine learning model format for the target computing environment and deploying the converted machine learning model; and if the electronic request to publish the machine learning model is invalid, generating a response that the electronic request to publish the machine learning model is invalid.
11. A system application programming interface (API) based machine learning model publication, the system comprising: a processor; a non-transitory computer-readable medium; and instructions stored on the non-transitory computer-readable medium and translatable by the processor for: receiving, from a client device through an API of the system, a request to publish a machine learning model trained using a third-party machine learning modeling application, the request containing a machine learning model package; processing the machine learning model package to obtain the machine learning model in a first format; converting the machine learning model to a standard format supported by the MLMM system, the standard format being different from the first format; generating a docker image of the machine learning model in the standard format; and posting the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster.
1. A system for format-agnostic publishing of a machine learning model, comprising: a processor; a non-transitory computer-readable medium; and stored instructions translatable by the processor for executing: receiving an electronic request to publish a machine learning model which is trained in a source computing environment, the request comprising a machine learning model schema and a machine learning model package comprising one or more electronic files; publishing, to a target computing environment which is different from the source computing environment, the machine learning model based on the machine learning model schema and the machine learning model package, comprising: preprocessing the electronic request, the preprocessing comprising determining a validating method based at least on one of the machine learning model schema or the machine learning model package contained in the electronic request; and validating, using the validating method determined in the preprocessing, the machine learning model schema and the machine learning model package to determine whether the electronic request to publish the machine learning model is valid; wherein, if the electronic request to publish the machine learning model is valid, converting the machine learning model to a target machine learning model format for the target computing environment and deploying the converted machine learning model; and if the electronic request to publish the machine learning model is invalid, generating a response that the electronic request to publish the machine learning model is invalid.
The co-pending 18/318,057 did not teach application programming interface (API) based; machine learning model management (MLMM) system from a client device through an API of the MLMM system; generating, by the MLMM system, a docker image of the machine learning model in the standard format; and posting, by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster as recited in claims 1 and 11 of the instant application.
However, Babu teaches: application programming interface (API) based (Paragraph [0064]: Model management and scoring platform 130 may import external models through an API 132, and convert the external models that have different schema into models that share a same schema as described in detail below. The created or imported models may be managed, evaluated, deployed, and updated by model management and scoring platform 130. For example, model management and scoring platform 130 may selectively retrieve models from model store 110 and publish or deploy the selected model for analyzing online data. The scores may be feedback to model management and scoring platform 130 through a UI 134); machine learning model management (MLMM) system from a client device through an API of the MLMM system (Paragraph [0064]: For example, model management and scoring platform 130 may selectively retrieve models from model store 110 and publish or deploy the selected model for analyzing online data. The scores may be feedback to model management and scoring platform 130 through a UI 134. Paragraph [0152]: Cloud services are generally provided on an on-demand self-service basis, subscription-based, elastically scalable, reliable, highly available, and secure manner. For example, a customer, via a subscription order, may order one or more services provided by cloud infrastructure system 1702. Cloud infrastructure system 1702 then performs processing to provide the services requested in the customer's subscription order. For example, a user may request the cloud infrastructure system to register an application, as described above, and provide services to the application per the application's specified requirements. Cloud infrastructure system 1702 may be configured to provide one or even multiple cloud services.); and generating, by the MLMM system, a docker image of the machine learning model in the standard format; (Paragraph [0059]: Existing solutions to these challenges may include containerizing everything using, for example, Docker. However, unless the developers stick with this approach during the whole development process, an image-creation development and maintenance task may need to be performed. Paragraph [0061]: The machine learning platform disclosed herein may manage different machine learning models or different versions of a machine learning model, and facilitate the evaluation of the machine learning models and the selection and deployment of the machine learning model for production. The machine learning platform may also collect and report information, such as scores of the model applied to the input data or statistics about the usage of a model, which may be used to improve the model or the selection of the model by a selector. In some cases, the machine learning platform may use the selector to select an appropriate model for a give dataset from a number of available models.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have incorporated the concepts of an API based system to publish machine learning models, including generating a docker image, as suggested by the combination of Babu into the co-pending application 18/318,057 because these systems address the need for deploying machine learning models. Doing so would be beneficial to facilitate the evaluation of the machine learning models and the selection and deployment of the machine learning model for production (Babu Paragraph [0061]).
The combination of co-pending 18/318,057 and Babu did not teach posting by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster.
In the same field of endeavor, Khare teaches: posting, by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster. (Col. 2 37-59: In some embodiments, a producer provides a container to the web services model repository service 121 using a model/algorithm container registry 105. This container is shared as an image. In some embodiments, a model/algorithm container registry 105 is a fully-managed container registry that allows for storing, managing, and deploying of container images. (Col. 3 Lines 4-10: The publishing/listing agent 125 publishes received code or containers, lists containers, and responds to queries.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have incorporated the concepts of an API based system to publish machine learning models, including generating a docker image, and posting the model to a managed cluster as suggested by Khare into the combination of co-pending 18/318057 and Babu because these systems all address the need of deploying machine learning models. Doing so would be beneficial to facilitate the evaluation of the machine learning models and the selection and deployment of the machine learning model for production (Babu Paragraph [0061]), not all programmers and/or system administrators have the time or requisite knowledge to produce this content or integrate it into a pipeline of actions (Khare Col. 2, Lines 3 - 6).
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-2, 7-10, 11-12, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Babu et al (US 20190102700 A1, hereinafter Babu) in view of Khare et al (US 11249827 B2, hereinafter Khare), in further view of Majithiya et al. (US 20250371415 A1, hereinafter Majithiya).
Babu and Khare were cited in the previous office action.
Regarding Claim 1, Babu teaches A method for application programming interface (API) based machine learning model publication, the method comprising: (Paragraph [0064] Model management and scoring platform 130 may import external models through an API 132, and convert the external models that have different schema into models that share a same schema as described in detail below. The created or imported models may be managed, evaluated, deployed, and updated by model management and scoring platform 130. For example, model management and scoring platform 130 may selectively retrieve models from model store 110 and publish or deploy the selected model for analyzing online data. The scores may be feedback to model management and scoring platform 130 through a UI 134)
the MLMM system having a processor and a non-transitory computer-readable medium, (Paragraph [0013] According to certain embodiments, a non-transitory computer readable medium may store a plurality of instructions executable by one or more processors. The plurality of instructions, when executed by the one or more processors, may cause the one or more processors to perform processing including selecting a model group and a model selector for the model group, analyzing input data using the model group and the model selector, determining, during the analyzing, a score for the model group and the model selector based on the analyzing and a set of scoring metrics, and updating, during the analyzing, the model selector or the model group based upon determining that the score is below a threshold value. (The model management system operates on a processor executing machine readable code stored on a computer-readable storage medium))
converting, by the MLMM system, the machine learning model to a standard format supported by the MLMM system, the standard format being different from the first format; (Paragraph [0127] Optionally, at 1530, the computer system may convert a first ML model having a schema different from the common schema based on the common schema. For example, if the schema of the first ML model is congruent to the common schema of the model group, the datatype in the first ML model may be converted based on the datatype in the common schema. Two schemas are congruent if all feature vectors and datatypes of the feature vectors for the two models match or if the datatype of a feature in one model can be adapted to the datatype of a corresponding feature in another model. In some cases, a feature in the schema for the first ML model may be dropped based on determining that the feature has an importance level below a second threshold value. (Conversion of a machine learning model from one format to another based on the models schema. The model has an original schema different from that of the common format of the system.)).
However, Babu fails to disclose: generating, by the MLMM system, a docker image of the machine learning model in the standard format; and posting, by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, wherein the machine learning model published to the docker registry is available for deployment to a managed cluster.
In the same field of endeavor, Khare teaches: generating, by the MLMM system, a docker image of the machine learning model in the standard format; and (Col 2 Lines 51-59 In some embodiments, a producer provides a container to the web services model repository service 121 using a model/algorithm container registry 105. This container is shared as an image. In some embodiments, a model/algorithm container registry 105 is a fully-managed container registry that allows for storing, managing, and deploying of container images.)
posting, by the MLMM system, the docker image to a docker registry to thereby publish the machine learning model, (Col. 2 Lines 37-60 In some embodiments, a producer provides a container to the web services model repository service 121 using a model/algorithm container registry 105. This container is shared as an image. In some embodiments, a model/algorithm container registry 105 is a fully-managed container registry that allows for storing, managing, and deploying of container images. Col. 3 Lines 4-5 The publishing/listing agent 125 publishes received code or containers, lists containers, and responds to queries.) and
wherein the machine learning model published to the docker registry is available for deployment to a managed cluster. (Col. 3 Lines 4-5 The publishing/listing agent 125 publishes received code or containers, lists containers, and responds to queries. Col. 15 Lines 42-55 The illustrative environment includes at least one application server 1408 and a data store 1410. It should be understood that there can be several application servers, layers, or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. As used herein the term “data store” refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed or clustered environment.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have incorporated the concept of posting a machine learning model to a docker registry for publishing as suggested by Khare into Babu’s system because both of these systems are addressing the need to deploy machine learning models, as not all programmers and/or system administrators have the time or requisite knowledge to produce this content or integrate it into a pipeline of actions. (Khare Col. 2 Lines 3-18).
The combination of Babu and Khare does not teach: receiving, by a machine learning model management (MLMM) system from a client device through an API of the MLMM system, a request to publish a machine learning model trained using a third-party machine learning modeling application, the request containing a machine learning model package; processing, by the MLMM system, the machine learning model package to obtain the machine learning model in a first format;
In the same field of endeavor, Majithiya teaches: receiving, by a machine learning model management (MLMM) system from a client device through an API of the MLMM system, a request to publish a machine learning model trained using a third-party machine learning modeling application, the request containing a machine learning model package; (Paragraph [0018] According to some non-limiting embodiments or aspects, provided is a computer program product for distributed execution of a machine-learning model on a server cluster. The computer program product includes at least one non-transitory computer-readable medium including program instructions. The program instructions, when executed by at least one processor, cause the at least one processor to receive a request identifying at least one machine-learning model. The program instructions also cause the at least one processor to initiate retrieval of the at least one machine-learning model from a data repository based on the request. Paragraph [0060] A computing device may also be a desktop computer or other form of non-mobile computer. An “application” or “application program interface” (API) may refer to computer code or other data sorted on a computer-readable medium that may be executed by a processor to facilitate the interaction between software components (Receiving a request for distributed execution (publishing) of a machine learning model, wherein the model was trained elsewhere. Since the model is being distributed from a data repository (which must also include its package due to being stored in the repository) to a server cluster, it is being published from the repository to the cluster. The reference also includes a processor and computer readable instructions stored in a medium. Further, this is undergone through use of an API))
processing, by the MLMM system, the machine learning model package to obtain the machine learning model in a first format; (Paragraph [0074] The data repository 208 may include one or more computing devices for storing machine-learning models in an initial format. Paragraph [0076] The orchestration system 210 may execute an orchestration routine for each user request to evaluate a machine-learning model. The orchestration routine may include a number of additional steps to receive machine-learning models from a data repository 208 and facilitate distributed execution on a server cluster 212. First, the orchestration system 210 may infer the model type (e.g., format) of the requested machine-learning model, based on one or more parameters of the stored machine-learning model. The orchestration system 210 may fetch model binaries from a model store (e.g., the data repository 208), then execute a conversion routine using the model type as an input. (The system performs an orchestration routine in order to obtain the requested models data (from the files of the model held in the repository, which would be the models package), the model being in a first format before later being converted to another format.))
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the concepts of receiving a request to publish a machine learning model, the request containing its package, and then processing that package to obtain the models format as taught by Majithiya into the combination of Babu and Khare as all three references are in the related field of deploying machine learning models, particularly with a focus on flexibility when deploying or posting such models. This combination would be desirable in order to meet newly growing demands in regard to increasingly accurate, well-trained, and efficiently distributed machine learning models (Majithiya Paragraph [0003]).
Regarding Claim 2, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 1, including: wherein the API comprises an API wrapper, wherein the API wrapper calls a model conversion API to perform the converting and (Babu Paragraph [0063]: An ML model can be generated using model generator 120 of the ML platform by invoking a “create model” API. The data from data flow may be input into model generator 120 through a user interface (UI) 122. Feature vectors may then be extracted from the data and used to train the ML model. The trained model may be saved to model store 110. In some embodiments, model generator 120 may retrieve an existing model from model store 110, retrain the existing model using incoming data to generate a new model (e.g., a new version of a model), and save the new model to model store 110.) and
receive the machine learning model in the standard format and then calls an MLMM API with the machine learning model in the standard format to perform the generating. (Majithya Paragraph [0006] According to some non-limiting embodiments or aspects, provided is a computer-implemented method for distributed execution of a machine-learning model on a server cluster. The method includes receiving, with at least one processor, a request identifying at least one machine-learning model. The method also includes initiating retrieval, with at least one processor, of the at least one machine-learning model from a data repository based on the request. The method further includes converting, with at least one processor, the at least one machine-learning model from an initial format to an executable format compatible with distributed execution on a server cluster, to produce at least one converted machine-learning model. [0060] As used herein, the term “computing device” may refer to one or more electronic devices configured to process data. A computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and/or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and/or the like), a personal digital assistant (PDA), and/or other like devices. A computing device may also be a desktop computer or other form of non-mobile computer. An “application” or “application program interface” (API) may refer to computer code or other data sorted on a computer-readable medium that may be executed by a processor to facilitate the interaction between software components, such as a client-side front-end and/or server-side back-end for receiving data from the client. (Receiving a model in a distinct format and then performing conversion (regenerating the model in a new format) on the model using the API))
Regarding Claim 7, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 1, including: receiving requests to publish third-party machine learning models from disparate modeling applications where the machine learning models were trained, wherein the disparate modeling applications run on disparate computing environments; (Majithya Paragraph [0006] According to some non-limiting embodiments or aspects, provided is a computer-implemented method for distributed execution of a machine-learning model on a server cluster. The method includes receiving, with at least one processor, a request identifying at least one machine-learning model. The method also includes initiating retrieval, with at least one processor, of the at least one machine-learning model from a data repository based on the request. The method further includes converting, with at least one processor, the at least one machine-learning model from an initial format to an executable format compatible with distributed execution on a server cluster, to produce at least one converted machine-learning model. Paragraph [0018] According to some non-limiting embodiments or aspects, provided is a computer program product for distributed execution of a machine-learning model on a server cluster. The computer program product includes at least one non-transitory computer-readable medium including program instructions. The program instructions, when executed by at least one processor, cause the at least one processor to receive a request identifying at least one machine-learning model. The program instructions also cause the at least one processor to initiate retrieval of the at least one machine-learning model from a data repository based on the request. (Receiving requests to publish models wherein the models being acquired from a data store and then distributed (disparate environment) to a server cluster.))
validating each of the third-party machine learning models; (Babu Paragraph [0073] At 430, the ML platform may manage the models (including versions) to, for example, search models, evaluate models with various test datasets to ensure that a model is ready for publishing for wider usage, compare versions of models in various dimensions (e.g., hyper-parameters of models, metrics of models, etc.). For example, the machine learning platform may allow users to: import/export models, evaluate and compare various models (prior to deployment for scoring), manage various versions of models, deploy/un-deploy models, and transparently retrain models with recent data to prevent model drift. In some embodiments, the machine learning platform may provide API(s) for retrieving a list of models based on several search criteria, which may support name-based search. In some embodiments, the machine learning platform may manage several versions of a model.)
for each validated third-party machine learning model, converting the validated third-party machine learning model into the standard format; (Babu Paragraph [0064] Model management and scoring platform 130 may import external models through an API 132, and convert the external models that have different schema into models that share a same schema as described in detail below. The created or imported models may be managed, evaluated, deployed, and updated by model management and scoring platform 130. For example, model management and scoring platform 130 may selectively retrieve models from model store 110 and publish or deploy the selected model for analyzing online data. The scores may be feedback to model management and scoring platform 130 through a UI 134.)
generating a docker image for the third-party machine learning model in the standard format; and storing the docker image for the third-party machine learning model in the docker registry. (Khare Col 2 Lines 51-59 In some embodiments, a producer provides a container to the web services model repository service 121 using a model/algorithm container registry 105. This container is shared as an image. In some embodiments, a model/algorithm container registry 105 is a fully-managed container registry that allows for storing, managing, and deploying of container images.)
Regarding Claim 8, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 1, including: wherein the request further comprises a machine learning model input schema. (Majithiya Paragraph [0074] The data repository 208 may include one or more computing devices for storing machine-learning models in an initial format. The data repository 208 may be configured to communicate with the model development system 202, the orchestration system 210, and/or the implementation system 222. Paragraph [0078] The orchestration system 210 may cause an evaluation routine to be executed on one or more nodes of the server cluster 212 after the execution routine. The computing device may then build the model schema, which may include a model identifier, model configurations, hyperparameters, and an initial performance metrics object. The computing device may further convert the execution results from evaluation logic to the schema format and push the data to storage (e.g., in the server node). ())
Regarding Claim 9, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 1, including: wherein the machine learning model package comprises at least one of a file, a directory, or assets needed to host the machine learning model as a service. (Khare Col 6 Lines 18-22 Received code is caused to be packaged at 503. There are many ways to perform this packaging, but the end result is a package that is a compressed file (such as a zip, tar, etc.) consisting of the received code and any dependencies in some embodiments.)
Regarding Claim 10, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 1, including: wherein the managed cluster comprises at least one of an on-prem managed cluster operating in an enterprise computing environment or a cloud-based cluster operating in a cloud computing environment. (Babu Paragraph [0144] In certain examples, the functionalities described in this disclosure may be offered as services via a cloud environment. FIG. 17 is a simplified block diagram of a cloud-based system environment in which various services may be offered as cloud services in accordance with certain examples. In the example depicted in FIG. 17, cloud infrastructure system 1702 may provide one or more cloud services that may be requested by users using one or more client computing devices 1704, 1706, and 1708. Cloud infrastructure system 1702 may comprise one or more computers and/or servers that may include those described above for server 1612. The computers in cloud infrastructure system 1702 may be organized as general purpose computers, specialized server computers, server farms, server clusters, or any other appropriate arrangement and/or combination.)
Regarding Claims 11-12 and 17-20, they are system claims that corresponds to the method Claims 1-2 and 7-10 above. Therefore, they are rejected for the same reason as method claim Claims 1-2 and 7-10.
Claims 3-6 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Babu in view of Khare in additional view of Majithiya as applied in claims 2 and 12 above, and further in view of Cella et al. (US 12585231 B2, hereinafter Cella).
Cella was cited in the previous office action.
Regarding Claim 3, the combination of Babu, Khare, and Majithiya teaches all of the limitations of Claim 2 above. However, the combination of Babu and Khare does not teach: wherein, prior to the converting, the API wrapper calls a model validation API for validating the machine learning model obtained from the machine learning model package, and wherein the API wrapper calls the model conversion API responsive to the machine learning model being valid.
In the same field of endeavor, Cella teaches: wherein, prior to the converting, the API wrapper calls a model validation API for validating the machine learning model obtained from the machine learning model package, and wherein the API wrapper calls the model conversion API responsive to the machine learning model being valid. (Col. 341-342 Lines 61-9 In embodiments, the validation circuit 9426 may validate the generated model, for example by testing it against test data provided by the governance library 9452. In some cases, the selected governance standards may require certain validations (e.g., validation that the model complies with safety requirements when processing data), and thus the governance library may contain test data and/or target output(s) for validating that the model successfully complies with the corresponding governance requirement(s). Col. 345 Lines 40-53 The classification module 9510 may receive input data, isolate/extract the input data, analyze the data, and classify the data. Col. 382 Lines 22-39 Some example applications provided by the platform 10110 for value chain management include payment processors, digital format conversion, production restrictions, export restriction filtering, and so on. Col. 402 Lines 4-46 In embodiments, a distributed manufacturing marketplace as described herein, may be integrated with or within another exchange... This may include integration by APIs, connectors, ports, brokers, and other interfaces, as well as integration by extraction, transformation and loading (ETL) technologies, smart contracts, wrappers, containers, or other capabilities.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have incorporated the concept of incorporating an API wrapper to perform machine learning model validation, as suggested by Cella into the combination of references Babu, Khare, and Majithiya because these three systems are addressing the need to deploy machine learning models. Doing so would improve Babu, Khare, and Majithiya by allowing users to validate data efficiently so that they would not be overwhelmed (Cella Column 2, Lines 33-41).
Regarding Claim 4, the combination of Babu, Khare, Majithiya, and Cella teaches all of the limitations of Claim 3 above, including: wherein validation of the machine learning model comprises at least one of: determining whether the machine learning model is free of malware; (Khare Col 6 Lines 51-55 At 513, a verification is caused to be performed when so requested. In some embodiments, the publishing/listing agent 125 performs this verification. In other embodiments, publishing/listing agent 125 calls another service to perform verification.)
Regarding Claim 5, the combination of Babu, Khare, Majithiya, and Cella teaches all of the limitations of Claim 3 above, including: further comprising: responsive to the machine learning model being invalid, deleting the machine learning model from a temporary location in a file system of the MLMM system. (Babu Paragraph [0075] In some embodiments, the machine learning platform may provide API(s) for publishing a version of a model for scoring. In some embodiments, the API(s) may specify whether a given version is the default version for scoring. In some embodiments, the machine learning platform may provide API(s) for importing and/or exporting a model. In some embodiments, the machine learning platform may provide API(s) for deleting a model. In some embodiments, the machine learning platform may support periodically publishing a model at a given frequency to implement continuous learning of a model using new data in new time windows. In some embodiments, the machine learning platform may provide API(s) for suggesting a model for a given dataset. Some examples of APIs are described in the Apendix in U.S. Provisional Patent Application No. 62/568,052, filed on Oct. 4, 2017, entitled “Machine Learning Platform”.).
Regarding Claim 6, the combination of Babu, Khare, Majithiya, and Cella teaches all of the limitations of Claim 3 above, including: further comprising: responsive to the machine learning model being invalid, generating an error code or message indicating that the machine learning model is invalid. (Khare Col 6 Lines 56-62 A determination of successful verification is made at 515 (when verification was performed). When the verification was not successful, an error is generated at 509. When the verification was successful, the package is published in the source control service 107 and 517. Published packages are available to the publishing/listing agent 125 to be served as a potential result to a code or data query.)
Regarding Claims 13-16, Claims 13-16 are system claims that correspond to the method claims 3-6. Therefore, they are rejected for the same reasons as above.
Response to Arguments
Applicant’s arguments filed on 07/20/2026 on the remark (page 9) with respect to claims 1 and 11 under double patenting rejection have been considered but are moot because of the new grounds of rejection (see rejection above).
Applicant’s arguments filed 07/20/2026, pages 9-16, with respect to claims 1-20 under 35 U.S.C 101 rejection have been fully considered and are persuasive. Therefore, the rejection of claims 1-20 under 35 U.S.C 101 is withdrawn.
Applicant’s arguments filed on 07/20/2026 on the remark (pages 16-19) with respect to claim 1-20 under 35 U.S.C 103 have been considered but are moot because the new ground of rejection (see rejection above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen et al. (US-11301762-B1) teaches translating models into a common format.
Kalpatapu et al. (US-20210075701-A1) teaches virtual network package validation.
Vogeti et al. (US-20220129785-A1) teaches shared prediction engine model deployment, where a service provider hosts these models.
Hiremath et al. (US-11853272-B2) teaches data validation in machine learning models.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN A CARDOSO whose telephone number is (571)272-8512. The examiner can normally be reached M-F 7:30 - 5:00, alternate Friday's off.
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, Jennifer Welch can be reached at (571) 272-7212. 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.
/JUSTIN CARDOSO/
Patent Examiner, Art Unit 2143
/JENNIFER N WELCH/ Supervisory Patent Examiner, Art Unit 2143
Prosecution Insights