Prosecution Insights
Last updated: October 04, 2026
Application No. 18/855,154

COMPUTER-IMPLEMENTED METHOD FOR CROSS-ACCOUNT MODEL DEPLOYMENT, COMPUTER PROGRAM ELEMENT AND COMPUTER READABLE MEDIUM

Final Rejection §103
Filed
Oct 08, 2024
Priority
Apr 08, 2022 — EU 22167444.3 +1 more
Examiner
RUSS, COREY V
Art Unit
3629
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
BASF Corporation
OA Round
2 (Final)
27%
Grant Probability
At Risk
3-4
OA Rounds
11m
Est. Remaining
66%
With Interview

Examiner Intelligence

Grants only 27% of cases
27%
Career Allowance Rate
48 granted / 177 resolved
-24.9% vs TC avg
Strong +39% interview lift
Without
With
+38.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
29 currently pending
Career history
222
Total Applications
across all art units

Statute-Specific Performance

§101
42.1%
+2.1% vs TC avg
§103
44.8%
+4.8% vs TC avg
§102
7.4%
-32.6% vs TC avg
§112
4.3%
-35.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 177 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Status of Claims The following is a final office action. Claims [1-18 and 20-21] are currently pending and have been examined based on their merits. Claims 1, 14-15 are newly amended see REMARKS June 11, 2026. Claim 19 is currently canceled see REMARKS June 11, 2026. Claim 21 is newly added see REMARKS June 11, 2026. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-2, 4-16, 18, and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anglin (US 2020/0218940) in view of Cmielowski (US 2022/0413821). Claims 1, 14, and 15: Anglin discloses (Claim 1) A computer-implemented method for cross- account model deployment, comprising: (Claim 14) a non-transitory computer program product storing a computer program element which when executed by a computing unit comprising a hardware processor is configured to carry out the method according to claim 1: (Claim 15) A non-transitory computer readable medium that generates data to control a computing unit according to the method according to claim 1: providing at least one artifact identifier of at least one to-be-deployed model artifact (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers); providing at least one account tuple, the account tuple comprising a source account identifier identifying a source account and a target account identifier identifying a target account (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified); Anglin discloses a system of creating and sharing a machine learning model in a network environment. However, Anglin does not specifically disclose the following claim limitations: and moving, the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts. In the same field of endeavor of deploying models in a network Cmielowski teaches and moving, the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts (Paragraph [0016-19]; [0032-0033]; [0040]; Fig. 5, users may need to download trained models to be able to access the trained models to do additional validation, refinery, and serving on their own infrastructure. However, machine learning models are often created using 3rd party libraries. Deployment of a machine learning model may be a process of installing the machine learning model in the client system from the training system. The deployment of the trained machine learning model may make the model available for use at the client system. The client system may be an on-premise system and the training system may be an off-premise system. The on-premise system may be a local system on the premises of a user organization for executing on-premise software. The off-premise system may be a remote system that is accessible by the user via a network and that may be owned by a third party. The client system may receive the requested information and may determine whether a local environment of the client system is incompatible with the training environment as defined in received information. The information may comprise a list of libraries and packages and their respective version. In the case the client system determines that the local environment is compatible with the training environment downloading the machine learning model may be performed. A get pipeline may be initiated at the client system in order to download the trained model). Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the system of managing the access and deployment of digital assets such as a trained machine learning model in a network as disclosed by Anglin with the system of moving, the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts as taught by Cmielowski (Cmielowski [0040]). With the motivation of helping to manage the distribution of a trained machine learning model to a client that is capable of receiving and running the model (Cmielowski [0005]). Claim 2: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the model is a machine learning model (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data). Claim 4: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the at least one to-be-deployed model artifact is at least one out of model files, sources files, scripts, binary executable files, database tables, development deliverables, word-processing documents and/or mail messages (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data). Claim 5: Modified Anglin discloses the method as per claim 1. Anglin further discloses further comprising: logging the at least one artifact identifier along with the at least one account tuple (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 6: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein a list of account tuples is provided, the list comprising at least two account tuples (Paragraph [0005-0007]; [0030-0032]; [0045]; Fig. 4, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. The system may be configured as a tool allowing multiple model owners to create trained machine learning models). Claim 7: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein at least one of the source accounts is a development account, at least one of the accounts is a testing account and/or at least one of the target accounts is a production account (Paragraph [0005-0007]; [0030-0032]; [0045-0046]; Fig. 4, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. The system may be configured as a tool allowing multiple model owners to create trained machine learning models from many data sources (e.g. training datasets) to which model owners and/or model consumers (e.g. researchers) would not normally have permission to access. In the example, access controller determines if model owner and/or model consumer has permission to access a device executing as a global model engine). Claim 8: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein at least one of the accounts is a cloud-based account (Paragraph [0025] the phrase machine learning broadly describes a function of electronic systems that learn from data. A machine learning system that can be trained such as in an external cloud environment to learn functional relationships between inputs and outputs). Claim 9: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the at least one artifact identifier and/or the at least one account tuple are provided by operator input and/or by a user interface (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0085]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. In some embodiments the computer system may further include a network interface). Claim 10: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the at least one artifact identifier and/or the at least one account tuple are provided automatically by a deployment script and, optionally, the deployment script further performs automated model training, automated model validation and/or quality assurance testing (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers). Claim 11: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the method further comprises initializing the at least one account tuple and the initialization of the account tuple is, optionally, performed upon being provided with the account tuple or right before moving the at least one to-be-deployed model artifact (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 12: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein initializing the at least one account tuple comprises: obtaining an authorization for the source account to share the at least one to- be-deployed model artifact; and obtaining an authorization for the target account to receive the at least one to-be-deployed model artifact, wherein moving the at least one to-be-deployed model artifact is performed from the source account to an intermediary and from the intermediary to the target account; and, optionally ,wherein access resources required to obtain the authorizations are provided in a set-up step (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 13: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein initializing the at least one account tuple comprises obtaining an authorization for the source account to access resources of the target account and moving the at least one to-be-deployed model artifact is performed by the source account by pushing the model artifact to the target account; and/or wherein initializing the at least one account tuple comprises obtaining an authorization for the target account to access resources of the source account and moving the at least one to-be-deployed model artifact is performed by the target account by pulling the model artifact from the source account; and, optionally ,wherein access resources required to obtain the authorizations are provided in a set-up step (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 16: Modified Anglin discloses the method as per claim 1. Anglin further discloses wherein the moving comprises copying (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 18: Modified Anglin discloses the method as per claim 6. Anglin further discloses wherein the target account of one account tuple equals the source account of the next account tuple in the list (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. When the smart contract is executed and data consumer is authenticated by its public key in the smart contract, the encrypted data can be provided to the data consumer. Whenever the data provider lists a data entity for sale, the smart contract is created that includes, for example, data signature, and access URL, or an API address for retrieval, a list of public keys that grant data access, as well as a selling price for the data access. Smart contracts can include details such as information identifying all owners, information related to data sources, among many others. Once the transaction is confirmed in the ledger, access controller authenticates the data consumer using the consumer’s private key and provides encrypted data of interest to the model engine. The data download begins once the payment is verified). Claim 20: Modified Anglin discloses the method as per claim 9. Anglin further discloses wherein the user interface is a representational state transfer application programming interface, REST API, and/or a graphical user interface (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0085]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers. A data request/purchase from any data consumer via the model engine triggers a decryption process where the access controller sends the advanced encryption standard (AES) key to a data requesting model engine. Data source selected hosts links to the encrypted testing data entities from data providers. In an embodiment, data access rights to a particular dataset is determined by a predefined agreement specified by the smart contract. In some embodiments the computer system may further include a network interface). Claim 21: Anglin discloses A computer-implemented method for cross-account model deployment, comprising: providing at least one artifact identifier of at least one to-be-deployed model artifact, wherein the model is a machine learning model (Paragraph [0005-0007]; [0030-0032]; [0046-0048]; [0064-0067]; Fig. 3, embodiments of the present invention are directed to a distributed machine learning system. The model engine is being operated in accordance with a smart contract to enable two or more entities to collaboratively produce a machine learning model based on the training data using machine learning infrastructure. Contributions of each of the two or more entities are entered into a ledger of the blockchain. The smart contract enables two or more entities to collaboratively produce the machine learning model based on the training data. In various embodiments, one or more distributed model engines may be configured to manage many modeling tasks. Thus, the number of active models could number in the hundreds or even more. Therefore, the inventive subject matter is also considered to include management apparatus or methods of a large number of model objects in the distributed system. For example, each modeling task can be assigned one or more identifiers, or other metadata, for management by the system. Identifies can include a unique model identifier, a model owner identifier, version numbers, or other types of identifiers). Anglin discloses a system of creating and sharing a machine learning model in a network environment. However, Anglin does not specifically disclose the following claim limitations: providing a list of account tuples, the list comprising at least two account tuples, each account tuple comprising a source account identifier identifying a source account and a target account identifier identifying a target account, wherein the target account of one account tuple equals the source account of the next account tuple in the list, and the account tuples in the list of account tuples are processed one after the other; and moving the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts. In the same field of endeavor of deploying models in a network Cmielowski teaches providing a list of account tuples, the list comprising at least two account tuples, each account tuple comprising a source account identifier identifying a source account and a target account identifier identifying a target account, wherein the target account of one account tuple equals the source account of the next account tuple in the list, and the account tuples in the list of account tuples are processed one after the other; and moving the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts (Paragraph [0016-19]; [0032-0033]; [0040]; Fig. 5, users may need to download trained models to be able to access the trained models to do additional validation, refinery, and serving on their own infrastructure. However, machine learning models are often created using 3rd party libraries. Deployment of a machine learning model may be a process of installing the machine learning model in the client system from the training system. The deployment of the trained machine learning model may make the model available for use at the client system. The client system may be an on-premise system and the training system may be an off-premise system. The on-premise system may be a local system on the premises of a user organization for executing on-premise software. The off-premise system may be a remote system that is accessible by the user via a network and that may be owned by a third party. The client system may receive the requested information and may determine whether a local environment of the client system is incompatible with the training environment as defined in received information. The information may comprise a list of libraries and packages and their respective version. In the case the client system determines that the local environment is compatible with the training environment, downloading the machine learning model may be performed. A get pipeline may be initiated at the client system in order to download the trained model). Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the system of providing a list of account tuples, the list comprising at least two account tuples, each account tuple comprising a source account identifier identifying a source account and a target account identifier identifying a target account, wherein the target account of one account tuple equals the source account of the next account tuple in the list, and the account tuples in the list of account tuples are processed one after the other; and moving the at least one to-be-deployed model artifact from the source account to the target account, wherein the accounts are computing accounts as taught by Cmielowski (Cmielowski [0040]). With the motivation of helping to manage the distribution of a trained machine learning model to a client that is capable of receiving and running the model (Cmielowski [0005]). Claims 3 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anglin (US 2020/0218940) in view of Cmielowski (US 2022/0413821) further in view of Hu (US 11406053) Claim 3: Modified Anglin discloses the method as per claim 1. However, Anglin does not disclose wherein the model is an agricultural management model. In the same field of endeavor of deploying a machine learning model Hu teaches wherein the model is an agricultural management model (Paragraph [Col. 4 ll. 57- Col. 5 ll. 4]; [Col. 19 ll. 18-38]; [Col 27 ll. 29-41]; [Col. 28 ll. 32-35]; Fig. 9A, in one embodiment a computer implemented method includes receiving digital field data from an agricultural field representing one or more parameter of the field; retrieving historical data for the same field; training and/or applying machine learning models to the field data to derive representation of causality of one or more agronomic processes pertaining to the field; receiving user input specifying an anomaly; automatically adjusting the treatment or experiment to create a modified treatment. In an embodiment, the agricultural intelligence computer system is programmed to create an agronomic model. A system receives model training data comprising a plurality of datasets. Within the system there may be models that suggest nitrate sampling locations and sample size recommendation for a given field). Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the system of creating and deploying a machine learning model by a plurality of users as disclosed by Anglin with the system of wherein the model is an agricultural management mode as taught by Hu (Hu [Col. 4 ll. 57- Col. 5 ll. 4]). With the motivation of being a simple substitution as Anglin discloses a system for creating and distributing machine learning models to users for various purposes that are trained on different datasets available to the users. While Hu teaches building and training a specific machine learning model for a specific purpose such as creating an agricultural model to help provide recommendations to a user. Claim 17: Modified Anglin discloses the method as per claim 3. However, Anglin does not disclose wherein the agricultural management model provides agronomic recommendations and/or agronomic control data. In the same field of endeavor of deploying a machine learning model Hu teaches wherein the agricultural management model provides agronomic recommendations and/or agronomic control data (Paragraph [Col. 4 ll. 57- Col. 5 ll. 4]; [Col. 19 ll. 18-38]; [Col 27 ll. 29-41]; [Col. 28 ll. 32-35]; Fig. 9A, in one embodiment a computer implemented method includes receiving digital field data from an agricultural field representing one or more parameter of the field; retrieving historical data for the same field; training and/or applying machine learning models to the field data to derive representation of causality of one or more agronomic processes pertaining to the field; receiving user input specifying an anomaly; automatically adjusting the treatment or experiment to create a modified treatment. In an embodiment, the agricultural intelligence computer system is programmed to create an agronomic model. A system receives model training data comprising a plurality of datasets. Within the system there may be models that suggest nitrate sampling locations and sample size recommendation for a given field). Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the system of creating and deploying a machine learning model by a plurality of users as disclosed by Anglin with the system of wherein the model is an agricultural management mode as taught by Hu (Hu [Col. 4 ll. 57- Col. 5 ll. 4]). With the motivation of being a simple substitution as Anglin discloses a system for creating and distributing machine learning models to users for various purposes that are trained on different datasets available to the users. While Hu teaches building and training a specific machine learning model for a specific purpose such as creating an agricultural model to help provide recommendations to a user. Therefore, claim 1-18 and 20-21 are rejected under U.S.C. 103. Response to arguments Applicant’s arguments, see REMARKS, filed August 05, 2026, with respect to the rejections of 1-2, 4-16, 18, and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anglin (US 2020/0218940) in view of Cmielowski (US 2022/0413821) are not persuasive as the claims were amended which required further search and consideration and new art was applied. Claims 1, 14-15, and 21: Applicant argues that the current prior art does not disclose the amended claim limitations. However, upon further search and consideration the examiner finds that Anglin can be further combined with Cmielowski to disclose the newly amended claim limitations. Anglin discloses a system of a distributed system that allows a user to share and exchange machine learning models. Anglin further teaches a distributed machine learning system that allows entities such as users to purchase and download information such as model engines from a source. Anglin can be further combined with Cmielowski, which teaches a system of managing a library of trained machine learning models that a user can access and retrieve models form, to teach the newly amended claim limitations. Cmielowski further teaches allowing a user to request a trained machine learning model from a library and initiating a pipeline to download the model to a local client system associated with the user (Cmielowski [0040]). Therefore, the examiner finds that the combination of Anglin and Cmielowski teach the newly amended claim limitations. Therefore, the examiner finds that the combination of Anglin and Cmielowski as capable of teaching the currently amended claimed limitations. Claims 1 and 14-15 are newly rejected under U.S.C. 103. Claims 2-13, 16-18, and 20 were dependent on claims 1 and 14-15. Therefore, they are also newly rejected under the same rejection as above. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Sirosh (US 2016/0148115) Easy deployment of machine learning models Kannan (US 2021/0012404) Generating a framework for prioritizing machine learning model offerings via a platform. Hathaway (US 2016/0294860) Honey user. Szeto (US 2017/0124487) Systems, methods, and apparatuses for implementing machine learning model training and deployment with a rollback mechanism. 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 COREY RUSS whose telephone number is (571)270-5902. The examiner can normally be reached on M-F 7:30-4:30. 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, Lynda Jasmin can be reached on 5712726782. 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. /COREY RUSS/Primary Examiner, Art Unit 3629
Read full office action

Prosecution Timeline

Oct 08, 2024
Application Filed
Mar 11, 2026
Non-Final Rejection mailed — §103
Jun 11, 2026
Response Filed
Sep 16, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12718256
ARTIFICIAL INTELLIGENCE-AIDED RECOMMENDATION FOR EXPLORATORY NETWORK ANALYSIS
3y 5m to grant Granted Aug 25, 2026
Patent 12688509
SYSTEM AND METHOD RELATING TO PLANNING EVENT FOR A NETWORK
3y 11m to grant Granted Jul 21, 2026
Patent 12682362
AUTOMATED DOMAIN CRAWLER AND CHECKOUT SIMULATOR FOR PROACTIVE AND REAL-TIME SCAM WEBSITE DETECTION
2y 7m to grant Granted Jul 14, 2026
Patent 12614194
Compliance Evaluation System for an Organization
2y 2m to grant Granted Apr 28, 2026
Patent 12614241
SYSTEMS AND METHODS FOR ELECTRONIC SIGNATURE TRACKING
2y 2m to grant Granted Apr 28, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
27%
Grant Probability
66%
With Interview (+38.6%)
2y 11m (~11m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 177 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month