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 filling on 07/06/2026. Claims 1-20 are pending for examination.
Specification
Acknowledgment is made to the changes of the specification filed on 07/06/2026 in regards to an amendment of paragraph [0028]. The amendment to the specification is accepted.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/29/2026 is being considered by the examiner.
Claim Objections
Claims 1-2, 8-9, and 15-16 are objected to because of the following informalities: the claims read “the request” in areas when they should instead read “the electronic request” to be consistent with the amendment in the independent claims and in the corresponding claims. Appropriate correction is required.
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, 8, and 15 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 4 and 14 Copending Application No. 18/318,052 and in view of Vogeti et al (US 20220129785 A1, published 04/28/2022, hereinafter Vogeti).
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,052. For example, the table below shown similarity and different between the instant application and the copending application 18/318,052.
18/318,057 (Instant Application)
18/318,052
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.
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;
converting the machine learning model to a standard format supported by the system, the standard format being different from the first format;
13) The system of claim 12, 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.
14. The system of claim 13, wherein validation of the machine learning model comprises at least one of: checking whether the machine learning model is of a valid supported model type; verifying whether the machine learning model is packaged correctly based on the valid supported model type; determining whether the machine learning model is free of malware; determining whether the machine learning model package contains any unwarranted file or system call; or where the machine learning model package is a zip file, validating a file name of the zip file.
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.
1) A method for 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;
converting the machine learning model to a standard format supported by the system, the standard format being different from the first format;
3) The system of claim 2, 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.
4) The system of claim 3, wherein validation of the machine learning model comprises at least one of: checking whether the machine learning model is of a valid supported model type; verifying whether the machine learning model is packaged correctly based on the valid supported model type; determining whether the machine learning model is free of malware; determining whether the machine learning model package contains any unwarranted file or system call; or where the machine learning model package is a zip file, validating a file name of the zip file.
18/318,057 (Instant Application)
18/318,052
15) A computer programming product comprising a non-transitory computer-readable medium storing instructions for format-agnostic publishing of a machine learning model, the instructions translatable by a processor for: 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.
1) A method for 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;
converting the machine learning model to a standard format supported by the system, the standard format being different from the first format;
3) The system of claim 2, 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.
4) The system of claim 3, wherein validation of the machine learning model comprises at least one of: checking whether the machine learning model is of a valid supported model type; verifying whether the machine learning model is packaged correctly based on the valid supported model type; determining whether the machine learning model is free of malware; determining whether the machine learning model package contains any unwarranted file or system call; or where the machine learning model package is a zip file, validating a file name of the zip file.
The co-pending 18/318,052 did not teach the request comprising a machine learning model schema, 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, 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 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. as recited in claims 1, 8 and 15 of the instant application.
However, Vogeti teaches: the request comprising a machine learning model schema (Paragraph [0018]: Thereafter, once an account or other information for an ML predictive service has been registered and/or established, a user or other client entity may request use of the ML predictive service. Initially, the user may wish to upload, register, and/or deploy one or more ML models (requesting use of the service also entails requesting use for publishing/upload. Further, the uploaded files may be in a specific format for the prediction service such that...(format analogous to schema))
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 (Paragraph [0014] A service provider may provide an artificial intelligence (AI) prediction engine, such as a generic prediction engine, that allows for uploading, verifying, and hosting AI models on an online service platform accessible by client devices for predictive services. [0015] In a first phase, the client may upload one or more files, such as a compressed folder (e.g., .zip folder) having the files and corresponding data for the ML model.(uploading/publishing is analogous) Further, the uploaded files may be in a specific format for the prediction service such that... (Publishing to an online platform (different than where the machine learning model was trained) based on the models files and format))
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 (Paragraph [0020] Thereafter, in a second phase, the service provider may implement verification processes to verify the ML model is valid and proper for deployment the ML prediction service. This may include whether the ML model can be hosted and utilized in a production computing environment (e.g., ML prediction engine) of the service provider. In order to validate and verify the ML model for deployment, an ML model deployer of the ML prediction service may perform a two-step process where the requirements of the ML model are first verified to be supported by the ML prediction service and engine, and second that the ML model is making proper or accurate predictions and decisions based on known input features and data (e.g., is holding up and consistent with expectations in the production computing environment of the ML prediction service). In this regard, the ML model deployer may utilize the requirements text file (e.g., a .txt file) to determine whether the code packages are supported by the programming code and ML frameworks of the ML prediction service. (Preprocessing the model, wherein a verification is undergone using requisite files to determine validity for deployment. The validation may also comprise a two-step process, first verifying the actual contents of the model and then verifying the models performance))
validating, using the validating method determined in the preprocessing, the machine learning model schema (Paragraph [0021] Thereafter, in a second phase, the service provider may implement verification processes to verify the ML model is valid and proper for deployment the ML prediction service. This may include whether the ML model can be hosted and utilized in a production computing environment (e.g., ML prediction engine) of the service provider..... In this regard, the ML model deployer may utilize the requirements text file (e.g., a .txt file) to determine whether the code packages are supported by the programming code and ML frameworks of the ML prediction service Paragraph [0035] The data package provided via ML model uploader 122 may further include a requirements file that designates the code packages necessary to deploy, host, and use the ML model via an ML model framework (e.g., Tensorflow, Scikit-Learn, H2O, CatBoost, XGBoost, LightGBM, etc.). The requirements file may be used to validate that the ML model can be deployed by service provider server 130. The data package may also include test data, such as test features and test input with corresponding test output values, classifications, and/or predictions. (Using the contents of the models package and its format to determine that the request for publishing is valid by validating the model))
It would have been obvious to a person have ordinary skill in the art before the effective filling date to have incorporated the concepts of having the request comprising a machine learning model schema; publishing the machine learning model based on the machine learning model schema; undergoing a preprocessing to determine a method of validation; validating the machine learning model schema; and if the request to publish the machine learning model is invalid, generating a response that the request to publish the machine learning model is invalid as suggested by Vogeti into the instant application because both of these systems are addressing the need of deploying machine learning model. Doing so would be improving the instant application by allowing the end users and client devices to upload and host ML models and request predictive services from multiple ML models (Vogeti, paragraph [0001]).
Claim Rejections - 35 USC § 112
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.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), 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-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 8 and 15 recite converting the machine learning model to a target machine learning model format for the target computing environment. However, the specification does not provide any support for converting the machine learning model to a target machine learning model format for the target computing environment. At best, the original disclosure describes the conversion step as producing one format used by the machine learning model management system itself. [Paragraph 0039] states that “the system may operate to convert the ML model to a normalized or standard ML model format such as MLflow”. [Paragraph 0057] states the capability to “convert or normalize the third-party ML model into a standard format (e.g., MLflow) that is native to or supported by the MLMM system (107).” [Paragraph 0071] states that “The model conversion standardizes or normalizes the ML model into a common format (e.g., MLflow format) that can be used by the MLM system to generate a docker image”. [Paragraph 0091] states that “If the request to publish 1105 is valid (at 1108A), system 1100 converts (at 1110) the ML model 1102 into a common ML model format”. [Paragraph 0008] states that the system converts the model into a standard format. Hence, claim 1, 8 and 15 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-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
For the purposes of examination, the examiner will interpret the claimed limitation in light of the specification as converting the machine learning model to a common machine learning model format for the target computing environment.
Regarding Claims 2-7, 9-14, and 16-20, claims 2-7, 8-14, and 16-20 are dependent claims which depend on the independent claims 1, 8, and 15. As such, they are rejected for depending on claims rejected under 35 U.S.C. 112(a).
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-8, 10-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vogeti et al. (US 20220129785 A1, hereinafter Vogeti), in view of ZHANG et al. (US 20240127111 A1, hereinafter Zhang)
Vogeti was cited in the previous office action.
Regarding Claim 1, Vogeti teaches a system for format-agnostic publishing of a machine learning model, comprising:
a processor (Paragraph [0033], one or more processors);
a non-transitory computer-readable medium (Paragraph [0033], one or more computer readable mediums); and
stored instructions translatable by the processor for executing: (Paragraph [0033]: Client device 110 and service provider server 130 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 100, and/or accessible over network 150.)
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; (Paragraph [0015] In this regard, one or more user interfaces (UIs) may be provided to users, clients, and other entities to request predictive services using one or more ML models, such as to generate and provide a prediction or decision based on input data. Paragraph [0018] Thereafter, once an account or other information for an ML predictive service has been registered and/or established, a user or other client entity may request use of the ML predictive service. Initially, the user may wish to upload, register, and/or deploy one or more ML models (requesting use of the service also entails requesting use for publishing/upload. Further, the uploaded files may be in a specific format for the prediction service such that... Paragraph [0019] The user may select to upload an ML model and provide a folder or file with the data for the ML model. Paragraph [0024]: In order to deploy the ML model, a deployment request may then be generated and issued to the ML prediction service. The deployment request may correspond to an operation to deploy and host the ML model in a live production computing environment. Paragraph [0035] This may include a data package that includes the model artifacts necessary to deploy the ML model, such as the trained layers, nodes, weights, values, and/or classifiers for the ML model (Receiving an electronic request to publish a model which has been already trained, the request including its files (package) and its format (schema)))
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: (Paragraph [0014] A service provider may provide an artificial intelligence (AI) prediction engine, such as a generic prediction engine, that allows for uploading, verifying, and hosting AI models on an online service platform accessible by client devices for predictive services. Paragraph [0015] In a first phase, the client may upload one or more files, such as a compressed folder (e.g., .zip folder) having the files and corresponding data for the ML model.(uploading/publishing is analogous) Further, the uploaded files may be in a specific format for the prediction service such that... (Publishing to an online platform (different than where the machine learning model was trained) based on the models files and format))
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 (Paragraph [0020] Thereafter, in a second phase, the service provider may implement verification processes to verify the ML model is valid and proper for deployment the ML prediction service. This may include whether the ML model can be hosted and utilized in a production computing environment (e.g., ML prediction engine) of the service provider. In order to validate and verify the ML model for deployment, an ML model deployer of the ML prediction service may perform a two-step process where the requirements of the ML model are first verified to be supported by the ML prediction service and engine, and second that the ML model is making proper or accurate predictions and decisions based on known input features and data (e.g., is holding up and consistent with expectations in the production computing environment of the ML prediction service). In this regard, the ML model deployer may utilize the requirements text file (e.g., a .txt file) to determine whether the code packages are supported by the programming code and ML frameworks of the ML prediction service. (Preprocessing the model, wherein a verification is undergone using requisite files to determine validity for deployment. The validation may also comprise a two-step process, first verify the actual contents of the model and then verify the models performance))
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; (Paragraph [0021] Thereafter, in a second phase, the service provider may implement verification processes to verify the ML model is valid and proper for deployment the ML prediction service. This may include whether the ML model can be hosted and utilized in a production computing environment (e.g., ML prediction engine) of the service provider..... In this regard, the ML model deployer may utilize the requirements text file (e.g., a .txt file) to determine whether the code packages are supported by the programming code and ML frameworks of the ML prediction service [0035] The data package provided via ML model uploader 122 may further include a requirements file that designates the code packages necessary to deploy, host, and use the ML model via an ML model framework (e.g., Tensorflow, Scikit-Learn, H2O, CatBoost, XGBoost, LightGBM, etc.). The requirements file may be used to validate that the ML model can be deployed by service provider server 130. The data package may also include test data, such as test features and test input with corresponding test output values, classifications, and/or predictions. (Using the contents of the models package and its format to determine that the request for publishing is valid by validating the 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. (Paragraph [0023]: Thus, some features may be provided as input to the ML model and the output decisions may be decided by the ML model from those input features. If the corresponding decisions match and/or are expected from the test data, the ML model deployer may validate the ML model for deployment. However, if not, the user may be alerted of the incorrect decisions and model prediction errors. (A response is received should the verification of the model fail, thus deeming the request to publish invalid))
Vogeti does not teach: 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;
In the same field of endeavor, Zhang teaches wherein, if the request to publish the machine learning model is valid, converting the machine learning model to a common machine learning model format and deploying the converted machine learning model; (Paragraph [0028] Further, a step that the machine learning model converter performs format conversion on a called machine learning model comprises: Paragraph [0029] receiving the machine learning model which depends on the given machine learning computing framework from the control plane by the machine learning model converter; and reading a template file converted into an ONNX format from the machine learning computing formwork; Paragraph [0030] if the file fails to read, writing the reading failure reason and the timestamp into a local log file by the machine learning model converter to facilitate error check performed by operating and maintaining personnel; and Paragraph [0031] if the file is successfully read, converting the machine learning model and its dependent machine learning computing framework into the ONNX format by the machine learning model converter. (Receiving a machine learning model in a format. Then performing a validation/error checking step. Should the model be deemed valid/without errors, then it is converted to the targeted ONNX format. The model is then received by computing nodes which then download an image of the model.))
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 converting a machine learning model from one format to another targeted format and then deploying the newly converted model as taught by Zhang into Vogeti as both references are in the same field of machine learning model deployment and distribution, and this combination would be desirable in order to fulfill the growing needs of the field, such as by adequately meeting users needs for real-time responses that the user may be unable to fulfil due to latency when conventionally sourcing models as opposed to downloading a converted format of these models, cutting down the time needed to download such models due to inordinate file sizes or the like (Zhang Paragraph [0004]).
Regarding Claim 3, the combination of Vogeti and Zhang teaches the invention as claimed in Claim 1, including: wherein the machine learning model schema comprises an identification of a machine learning model format of the machine learning model (Vogeti Paragraph [0024] The ML model may be deployed and hosted within a directory that includes the files and data for the ML model, such as the model artifacts, metadata, and the like. The directory may correspond to a name or file path that identifies the ML model and allows for retrieval of the ML model's artifacts for execution of the ML model and determination of predictions.).
Regarding Claim 4, the combination of Vogeti and Zhang teaches the invention as claimed in Claim 3, including: wherein the machine learning model schema comprises metadata in a JavaScript Object Notation (JSON) format. (Vogeti Paragraph [0020] Any metadata for the model may also be provided, such as a model name, type, description, entity, documentation, build, configuration, and the like. Vogeti Paragraph [0057] The metadata for the ML model may include a programming code and/or type used by the ML model, a description of the ML model, the corresponding input data and features processable by the ML model with corresponding output predictions, a model build or version number, and the like.).
Regarding Claim 5, the combination of Vogeti and Zhang teaches the invention as claimed in Claim 1, including: wherein the machine learning model package is compressed (Vogeti Paragraph [0015] In a first phase, the client may upload one or more files, such as a compressed folder (e.g., .zip folder) having the files and corresponding data for the ML model.).
Regarding Claim 6, the combination of Vogeti and Zhang teaches the invention as claimed in Claim 5, including: wherein the machine learning model package is a zip file (Vogeti Paragraph [0015] In a first phase, the client may upload one or more files, such as a compressed folder (e.g., .zip folder) having the files and corresponding data for the ML model.).
Regarding Claim 7, the combination of Vogeti and Zhang teaches the invention as claimed in Claim 1, including: wherein validating the machine learning model package comprises at least one of: validating that the package is free of malware or, validating that the package comprises at least one file and at least one file directory (Vogeti Paragraph [0048] Thereafter, in a second phase of ML model deployment, ML model deployer 142 may verify and validate the ML model package and data. This may correspond to using the requirements file to determine whether the ML frameworks used and provided by ML model platform (e.g., Tensorflow, Scikit-Learn, H2O, or the like) are capable of deploying the corresponding ML model.).
Regarding Claims 8, 10-15, and 17-20, these claims are method and product claims that correspond to the system claims 1 and 3-7 above. Therefore, they are rejected for the same reasons.
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Vogeti in view of Zhang as applied in claims 1, 8 and 15 above, and further in view of Khare et al. (US 11249827 B2, hereinafter Khare).
Vogeti and Khare were cited in the previous office action.
Regarding Claim 2, the combination of Vogeti and Zhang teaches all the limitations of Claim 1, including: wherein the request to publish the machine learning model is received from a machine learning model training application, the machine learning model schema comprising an identification of a machine learning model format, wherein: (Vogeti Paragraph [0019]: The user may select to upload an ML model and provide a folder or file with the data for the ML model. Vogeti Paragraph [0024]: In order to deploy the ML model, a deployment request may then be generated and issued to the ML prediction service. The deployment request may correspond to an operation to deploy and host the ML model in a live production computing environment. Vogeti Paragraph [0018]: Thereafter, once an account or other information for an ML predictive service has been registered and/or established, a user or other client entity may request use of the ML predictive service. Initially, the user may wish to upload, register, and/or deploy one or more ML models (requesting use of the service also entails requesting use for publishing/upload. Further, the uploaded files may be in a specific format for the prediction service such that...(format analogous to schema) (Instant application paragraph [0012], uses "upload" as a synonym for publishing: The docker images corresponding to the converted ML models can then be posted, uploaded, or published to the docker registry for deployment to a managed cluster (in a cloud and/or on-prem))).
The combination of Vogeti and Zhang fails to disclose: publishing of the machine learning model is agnostic of the identification of the machine learning model format of the machine learning model.
In the same field of endeavor, Khare teaches: (Column 2, Lines 54-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. Column 3, Lines 4-10: The publishing/listing agent 125 publishes received code or containers, lists containers, and responds to queries. Each of these actions are detailed more below. Published algorithms, models, and data are stored in algorithm/model/data store 123 (of course, this storage may be spread across many physical devices). The store 123 may also store pipelines and/or notebooks. Column 3, Lines 11-27: In some embodiments, container images include one or more layers, where each layer represents executable instructions. Some or all of the executable instructions together represent an algorithm that defines a machine learning model. The executable instructions (e.g., the algorithm) can be written in any programming language (e.g., Python, Ruby, C++, Java, etc.). In some embodiments, the virtual machine instances are utilized to containers. In some embodiments, each virtual machine instance includes an operating system (OS), a language runtime, and one or more machine learning (ML) training containers).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated format identification agnostic publishing of machine learning models as suggested by Khare into the combination of Vogeti and Cella. Doing so would be desirable because more and more users are beginning to engage with artificial intelligence systems. While the desire to use machine learning models/algorithms is high, 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, Column 2, Lines 19-26).
Regarding Claims 9 and 16, they are method and product claims that correspond to the system of claim 2 above. Therefore, they are rejected for the same reasons.
Response to Arguments
Applicant’s arguments filed on 07/06/2026 on the remark (page 2) with respect to claim(s) 1, 8 and 15 under double patenting rejection have been considered but are moot because the new grounds of rejection (see rejection above).
Applicant’s arguments filed 07/06/2026, pages 2-9, 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/06/2026 on the remark (pages 6-8) 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) discloses Machine learning models trained in different frameworks translated into a common format.
Hiremath et al. (US 11853272 B2) discloses receiving input data used to train, test, and validate machine learning models.
Tyagi et al. (S. Tyagi, A. Baghela, K. M. Dar, A. Patel, S. Kothari and S. Bhosale, "Malware Detection in PE files using Machine Learning," 2022 OPJU International Technology Conference on Emerging Technologies for Sustainable Development (OTCON), Raigarh, Chhattisgarh, India, 2023, pp. 1-6) discloses malware detection in files.
Lopez Garcia et al. (Á. López García et al., "A Cloud-Based Framework for Machine Learning Workloads and Applications," in IEEE Access, vol. 8, pp. 18681-18692, 2020) discloses the entire machine learning development lifecycle.
Jianing et al. (CN 115994584 A) discloses machine learning model construction.
Konecki et al. (M. Konecki, R. Kudelić and A. Lovrenčić, "Efficiency of lossless data compression," 2011 Proceedings of the 34th International Convention MIPRO, Opatija, Croatia, 2011, pp. 810-815).
Srisatish et al. (CN 110520872 A) discloses converting and validating machine learning models.
SRINIVASAN et al. (US 20190306237 A1) discloses JSON metadata.
Ambati et al. (CN 110520872 A) teaches converting and validation of machine learning models
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 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