Detailed Action
Claims 1-20 are pending and are examined.
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
Claims 1, 8, and 15 are currently amended.
Response to Remarks
35 U.S.C. § 101
Remark 1: Applicant submits that the claims are do not recite an abstract idea. . . [as] [t]he claims do not set forth an abstract related to "certain methods of organizing human activity" because the claims do not clearly relate to "fundamental economic principles or practices," "commercial or legal interactions," or "managing personal behavior or relationships or interactions between people." See MPEP 2106.04(II)(A). Instead, the claims are directed to a computing architecture that addresses specific technical challenges associated with "continuous" machine learning (ML) model training by providing for cryptographically verifiable model versioning and distribution across decentralized networks. See, e.g., Specification, [0150]. Accordingly, Applicant respectfully submits that the claims do not recite an abstract idea.” (Applicant Arguments, 2026-02-20).
Response to Remark 1: Applicant’s argument is not persuasive because the amended claims still recite the abstract idea of receiving model-version information, recording that information on a ledger, and selecting a preferred or ‘champion’ model. The use of blockchain registries, digital assets, and ML model versions does not remove the claim from the abstract idea category where the claim is directed to organizing, tracking, and selecting information within a business/governance workflow. The claim does not recite a specific improvement to blockchain operation, distributed ledger architecture, network communication, cryptographic processing, or ML training itself; rather, the blockchain is used as an environment for recording and verifying model-version information. Applicant’s reliance on the alleged technical problem of continuous ML training does not identify claim language that changes how an ML model is trained, updated, or executed.
Remark 2: Applicant argues that the claims address continuous ML training enviroments where model versions may not be discretly defined. Applicant relies on timestamps, tokens, digital signatures, and blockchain registry signatures as allegedgly defining and protecting ML model versions. Applicant further argues that these features improve security and enable distribution of authenticated model versions across decentralized networks.
Response to Remark 2: Applicant’s argument is not persuasive because the claim does not integrate the abstract idea into a practical application. The cited specification passages describe desirable results but the claim does not recite a specific technical mechanism that improves continuous ML training, improves blockchain technology, or improves computer functionality. Reciting timestamps, signatures, tokens, ledgers, and registries merely applies conventional data-identification and authentication techniques to model-version information. The claim does not require any particular training algorithm, model-state capture technique, distributed synchronization protocol, cryptographic improvement, or ledger structure that solves a technical problem in a non-generic way. Instead, the additional elements amount to using generic processors, memories, blockchain registries, and distributed ledgers as tools to receive, store, verify, and select information.
Remark 3: Applicant argues that the claims solve technical problems in continuous ML training by enabling cryptographically verifiable, timestamped model versions. Applicant asserts that these assets can identify model parameters, internal states, and training data associated with particular model versions. Applicant also argues that users can access, verify, and execute specific model versions, such as champion models, while continuous training continues. Applicant analogies the claims to Ex Parte Desjardins, asserting that the claims similarly improve ML technology by addressing continuous training challenges.
Response to Remark 3: Applicant’s reliance on Ex Parte Desjardins is not persuasive because the present claims do not recite a comparable improvement to ML technology itself. In Desjardins, as characterized by applicant, the claims addressed how a machine-learning model was trained to learn new tasks while preserving prior knowledge; here, the claims instead concern identifying, signing, recording, verifying, and selecting versions of an ML model. The claimed timestamped digital assets and signatures may assist with provenance or auditability, but they do not alter the model’s training functioning of the ML system. The ability to access or verify a particular model version during continuous training is an informational management benefit, not a claimed technological improvement to ML training or distributed computing. Nor do the claims recite a concrete implementation for capturing model weights, synchronizing model states, or technically defining model boundaries during continuous training beyond storing descriptive asset information.
35 U.S.C. § 103
Remark 1: Applicant argues “Beser, Chu, and Davis, alone or in any combination, do not disclose, teach, or suggest a system "for decentralized distribution of cryptographically verifiable machine learning (ML) models in a continuous model training environment" that can "receive, from a first blockchain registry associated with a first computing system, a first digital asset corresponding to a first version of an ML model, wherein the first digital asset is recorded in a first distributed ledger database/blockchain and comprises a first digital signature that encapsulates a first timestamp and a link to a first set of model parameters used by the first version of the ML at the first timestamp," "receive, from a second blockchain registry associated with a second computing system, a second digital asset corresponding to a second version of the ML model, wherein the second digital asset is recorded in a second distributed ledger database/blockchain and comprises a second digital signature that encapsulates a second timestamp and a link to a second set of model parameters used by the second version of the ML at the second timestamp," "record the first version and the second version of the ML model in a third distributed ledger database/blockchain," "select from the first version and the second version of the ML model a champion model of the ML model," "distribute, responsive to verification of the first digital signature or the second digital signature corresponding to the champion model selected from the first version and the second version of the ML model, a third digital asset comprising a link to the first set or the second set of model parameters corresponding to the champion model," as in amended claim 1 (emphasis added). In view of the foregoing, Beser, Chu, and Davis, alone or in any combination, do not disclose, teach, or suggest the combination of features of claim 1. Therefore, independent claim 1 is patentable over Beser, Chu, and Davis, alone or in any combination”. (id).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Beser, Chu, and Davis) still teach the currently amended independent claims, as shown at least in paragraphs 49, 30, 48 of Beser, paragraphs 2-7,113, and 199 of Davis, and as further outlined in paragraphs 38, and 42-44 of this action. Indeed, Chu teaches selecting from multiple candidate ML models/parameter sets and replacing a champion model with the best competing model, while Davis teaches applying multiple digital signatures to a data/model record that each record is cryptographically tied to a particular DID- controlled source. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1-7 are directed to a computer-implemented system (i.e., machine, and manufacture). Claims 8-14 are directed to a computer-implemented method (i.e., process). Claims 15-20 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claims 1, 8, and 15 recite (i.e., sets forth or describes) an abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. But for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Here, the claim limitations reciting the abstract idea of receiving and recording assets associated with a model, and then selecting a champion model are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they relate to the economy and commerce (e.g., cataloging, bookkeeping, accounting). More specifically, the following underlined claim elements recite the abstract idea(s) while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 1:
A system for decentralized distribution of cryptographically verifiable machine learning (ML) models in a continuous model training environment, the system, comprising:
a computing system comprising at least one processor and at least one memory coupled to the at least one processor, wherein the at least one processor is configured to:
receive, from a first blockchain registry associated with a first computing system, a first digital asset corresponding to a first version of an ML model, wherein the first digital asset is recorded in a first distributed ledger database/blockchain and comprises a first digital signature that encapsulates a first timestamp and a link to a first set of model parameters used by the first version of the ML at the first timestamp;
receive, from a second blockchain registry associated with a second computing system, a second digital asset corresponding to a second version of the ML model, wherein the second digital asset is recorded in a second distributed ledger database/blockchain and comprises a second digital signature that encapsulates a second timestamp and a link to a second set of model parameters used by the second version of the ML at the second timestamp;
record the first version and the second version of the ML model in a third distributed ledger database/blockchain; and
select from the first version and the second version of the ML model a champion model of the ML model; and
distribute, responsive to verification of the first digital signature or the second digital signature corresponding to the champion model selected from the first version and the second version of the ML model, a third digital asset comprising a link to the first set or the second set of model parameters corresponding to the champion model.
Claim 8:
A method for decentralized distribution of cryptographically verifiable machine learning (ML) models in a continuous model training environment, comprising:
receiving, from a first blockchain registry associated with a first computing system, a first digital asset corresponding to a first version of an ML model, wherein the first digital asset is recorded in a first distributed ledger database/blockchain and comprises a first digital signature that encapsulates a first timestamp and a link to a first set of model parameters used by the first version of the ML at the first timestamp;
receiving, from a second blockchain registry associated with a second computing system, a second digital asset corresponding to a second version of the ML model, wherein the second digital asset is recorded in a second distributed ledger database/blockchain and comprises a second digital signature that encapsulates a second timestamp and a link to a second set of model parameters used by the second version of the ML at the second timestamp;
recording the first version and the second version of the ML model in a third distributed ledger database/blockchain; and
selecting from the first version and the second version of the ML model a champion model of the ML model and
distributing, responsive to verification of the first digital signature or the second digital signature corresponding to the champion model selected from the first version and the second version of the ML model, a third digital asset comprising a link to the first set or the second set of model parameters corresponding to the champion model.
Claim 15:
At least one non-transitory processor-readable medium comprising processor-readable instructions such that, when executed by at least one processor, causes the at least one processor to:
receive, from a first blockchain registry associated with a first computing system, a first digital asset corresponding to a first version of an ML model, wherein the first digital asset is recorded in a first distributed ledger database/blockchain and comprises a first digital signature that encapsulates a first timestamp and a link to a first set of model parameters used by the first version of the ML at the first timestamp;
receive, from a second blockchain registry associated with a second computing system, a second digital asset corresponding to a second version of the ML model, wherein the second digital asset is recorded in a second distributed ledger database/blockchain and comprises a second digital signature that encapsulates a second timestamp and a link to a second set of model parameters used by the second version of the ML at the second timestamp;
record the first version and the second version of the ML model in a third distributed ledger database/blockchain; and
select from the first version and the second version of the ML model a champion model of the ML and
distribute, responsive to verification of the first digital signature or the second digital signature corresponding to the champion model selected from the first version and the second version of the ML model, a third digital asset comprising a link to the first set or the second set of model parameters corresponding to the champion model.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claims 1, 8, and 15 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)) and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claims 1, 8, and 15, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 2-7, 9-14, and 16-20 have also been analyzed. However, the subject matter of these claims also fail to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first version of the ML model and the second version of the ML model are updated versions of a base ML model.
Claim 3 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first digital asset comprises a token digitally signed by the first blockchain registry using a private key of the first blockchain registry; and
the second digital asset comprises a token digitally signed by the second blockchain registry using a private key of the second blockchain registry.
Claim 4 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model is digitally signed by a third blockchain registry using a private key of the third blockchain registry in response to selecting champion model.
Claim 5 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a model user of the champion model verifies the champion model by:
verifying a first signature on the digital asset of the champion model using a public key of one of the blockchain registry that provided the digital asset of the champion model; and
verifying a second signature on the digital asset of the champion model using a public key of the third blockchain registry.
Claim 6 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model comprises one or more of an identifier of a base ML model, a version name of the version of the ML model, an identifier of an entity that trained the version of the ML model, a link to codes of the version of the ML model, a link to a training dataset used in training for the version of the ML model, a time when the version of the ML model is created, or a location where the version of the ML model is created.
Claim 7 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first digital asset is identified using a first Decentralized Identifier (DID);
the second digital asset is identified using a second DID; and
the ML model is identified using a universal unique identifier generated based at least in part on the first DID and the second DID.
Claim 9 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first version of the ML model and the second version of the ML model are updated versions of a base ML model.
Claim 10 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first digital asset comprises a token digitally signed by the first blockchain registry using a private key of the first blockchain registry; and
the second digital asset comprises a token digitally signed by the second blockchain registry using a private key of the second blockchain registry.
Claim 11 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model is digitally signed by a third blockchain registry using a private key of the third blockchain registry in response to selecting champion model.
Claim 12 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a model user of the champion model verifies the champion model by:
verifying a first signature on the digital asset of the champion model using a public key of one of the blockchain registry that provided the digital asset of the champion model; and
verifying a second signature on the digital asset of the champion model using a public key of the third blockchain registry.
Claim 13 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model comprises one or more of an identifier of a base ML model, a version name of the version of the ML model, an identifier of an entity that trained the version of the ML model, a link to codes of the version of the ML model, a link to a training dataset used in training for the version of the ML model, a time when the version of the ML model is created, or a location where the version of the ML model is created.
Claim 14 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first digital asset is identified using a first Decentralized Identifier (DID);
the second digital asset is identified using a second DID; and
the ML model is identified using a universal unique identifier generated based at least in part on the first DID and the second DID.
Claim 16 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first version of the ML model and the second version of the ML model are updated versions of a base ML model.
Claim 17 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein the first digital asset comprises a token digitally signed by the first blockchain registry using a private key of the first blockchain registry; and
the second digital asset comprises a token digitally signed by the second blockchain registry using a private key of the second blockchain registry.
Claim 18 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model is digitally signed by a third blockchain registry using a private key of the third blockchain registry in response to selecting champion model.
Claim 19 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a model user of the champion model verifies the champion model by:
verifying a first signature on the digital asset of the champion model using a public key of one of the blockchain registry that provided the digital asset of the champion model; and
verifying a second signature on the digital asset of the champion model using a public key of the third blockchain registry.
Claim 20 recites the following underlined claim elements as an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea of receiving and recording assets associated with versions of a model, and then selecting a champion model. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)), and generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
wherein a digital asset of the champion model comprises one or more of an identifier of a base ML model, a version name of the version of the ML model, an identifier of an entity that trained the version of the ML model, a link to codes of the version of the ML model, a link to a training dataset used in training for the version of the ML model, a time when the version of the ML model is created, or a location where the version of the ML model is created.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beser et al. (US20190012595A1) in view of Chu et al. (US20090106178A1) (hereinafter “Chu”) in further view of Davis et al. (US20230206338A1) (hereinafter “Davis”)
As per Claim 1, 8, and 15, Beser teaches:
A system for decentralized distribution of cryptographically verifiable machine learning (ML) models in a continuous model training environment, the system comprising: a computing system comprising at least one processor and at least one memory coupled to the at least one processor, wherein the at least one processor is configured to: (“node 110 may comprise a processor 112, a memory 114, and/or a communication interface 116.” (Para. 0037); “Each node 110-1, 110-2, 110-3 and/or validation node 130-1, 130-2 may include one or more processors and/or one or more tangible, non-transitory memories and be capable of implementing logic.” (Para. 0036))
receive, (“The respective node 110-1, 110-2, 110-3 may retrieve the response transaction from model blockchain 140.” (Para. 0033); “Validation node 130 broadcasts the updated computing model to node 110 (step 322). In various embodiments, validation node 130 may broadcast the validated model update data to one or more nodes 110, instead of the updated computing model.” (Para. 0061); “Communication interface 116 may be configured to transmit and receive model update data to one or more validation nodes 130” (Para. 0039)
from a first blockchain registry associated with a first computing system, a first digital asset corresponding to a first version of an ML model, (“Validation node 130 may comprise . . . a local model blockchain 140.” (Para. 0041); “Each validation node 130 may be configured to write the model update data to its associated local model blockchain 140.” (Para. 0056)
wherein the first digital asset is recorded in a first distributed ledger database/blockchain and comprises a . . . that encapsulates a first timestamp and a link to a first set of model parameters used by the first version of the ML at the first timestamp; (“Validation node 130 writes the updated computing model to model blockchain 140 (step 318).” (Para. 0059); “Validation node 130 propagates the write to validation network 120 (step 320). For example, validation node 130 may broadcast the write data (e.g., data associated with the block written to model blockchain 140, the updated computing model, etc.) to one or more validation nodes 130 in validation network 120. Each validation node 130 may be configured to write the updating computing model to its associated local model blockchain 140.” (Para. 0060); “Each block may hold one or more of model update data, updated models, initially deployed computing models, or the like.” (Para. 0046);
receive, (“Validation node 130 broadcasts the updated computing model to node 110 (step 322). In various embodiments, validation node 130 may broadcast the validated model update data to one or more nodes 110.” (Para. 0061); “The respective node 110-1, 110-2, 110-3 may retrieve the response transaction from model blockchain 140, and may transmit a payment transaction to the corresponding validation node 130-1.” (Para. 0033);
from a second blockchain registry associated with a second computing system, (“validation node 130 may comprise a processor 132, a memory 134, a communication interface 136, and/or a local model blockchain 140.” (Para. 0041); “Each validation node 130 may be configured to write the updating computing model to its associated local model blockchain 140.” (Para. 0060)
a second digital asset corresponding to a second version of the ML model, wherein the second digital asset is recorded in a second distributed ledger database/blockchain and comprises a . . . that encapsulates a second timestamp and a link to a second set of model parameters used by the second version of the ML at the second timestamp; (“Validation node 130 writes the updated computing model to model blockchain 140 (step 318).” (Para. 0059); “validation node 130 may broadcast the write data (e.g., data associated with the block written to model blockchain 140, the updated computing model, etc.) to one or more validation nodes 130 in validation network 120.” (Para. 0060); “Each block may hold one or more of model update data, updated models, initially deployed computing models, or the like.” (Para. 0046))
record the first version and the second version of the ML model in a third distributed ledger database/blockchain; and (“Validation node 130 writes the updated computing model to model blockchain 140 (step 318).” (Para. 0059); “Validation node 130 writes the model update data to model blockchain 140 (step 310). Validation node 130 may be configured to write the model update data to model blockchain 140 together with any other suitable data, such as, for example a hash of the model update data, a date or timestamp, identifying information of the node 110 that transmitted the model update data (e.g., IP address, blockchain address, etc.), and/or any other suitable data or metadata.” (Para. 0056); “Blocks (e.g., model update data, updated models, initially deployed computing models, etc.) may be written to model blockchain 140 by establishing consensus between the blockchain nodes based on proof of work, proof of stake, practical byzantine fault tolerance, delegated proof of stake, or other suitable consensus algorithms.” (Para. 0046))
. . . from the first version and the second version of the ML model . . . of the ML model. (“Validation nodes 130 may establish consensus to the model update data using any suitable or desired consensus method or algorithm, such as, for example, proof of work, proof of stake, practical byzantine fault tolerance, delegated proof of stake, or any other suitable consensus algorithm.” (Para. 0055); “In response to receiving the model update data, validation node 130 validates the model update data (step 308). Validation node 130 may broadcast the model update data to one or more other validation nodes 130 in validation network 120. Validation nodes 130 may establish consensus to the model update data using any suitable or desired consensus method or algorithm, such as, for example, proof of work, proof of stake, practical byzantine fault tolerance, delegated proof of stake, or any other suitable consensus algorithm. Validation nodes 130 may also be configured to validate the model update data by locally testing the model update data to determine whether the model update data cures the prediction error, detects the new model requirement, or the like.” (Para. 0055).
distribute, responsive to verification of the first digital signature or the second digital signature corresponding to the champion model selected from the first version and the second version of the ML model, a third digital asset comprising a link to the first set or the second set of model parameters corresponding to the champion model (“Each node 110-1, 110-2, 110-3, and/or validation node 130-1, 130-2 may also be configured to verify digital signatures, maintain integrity of Merkle tree, verify proof of work, and/or the like, similar to typical blockchain technologies.” (Para. 0049); “Asymmetric encryption in particular may be of use in signing and verifying signatures for blockchain crypto operations.” (Para. 0030); “the public key may be shared via the peer-to-peer network to each node 110-1, 110-2, 110-3, and/or validation node 130-1, 130-2.” (Para. 0048)).
Beser does not disclose: “select . . . a champion model”.
However, as per Claim 1, Chu in the analogous art of operating predictive models in business environments, teaches: “select . . . a champion model”. (See “reiterate the model generation process by developing competing candidate models and replacing the current champion model if a competing model surpasses the current champion model with respect to the champion model performance criteria.” (Para. 0025); “A model manager compares the competing models' performance test results 330 (with respect to predicting data source 1B) with champion model 1's prediction performance 236 without using the decay indexes. Based upon the comparison, if a competing model outperforms the champion model, then a corrective action can include replacing at 270 the champion model 222 with the competing model.” (Para. 0033); “Replace Champion Model I with Best Competing Model” (Fig. 4).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser with the technique of Chu to include a step of selecting a champion model from a group of models. Therefore, the incentives of improved model risk provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Beser in view of Chu does not disclose: “a first signature [and] a second signature”.
However, as per Claim 1, Davis in the analogous art of secured payments between parties, teaches: “a first digital signature [and] a second digital signature”. (See “digitally signed by contracting party 122 a using digital signature 2010 a and asset owner 122 b using digital signature 2010 b.” (Para. 0207); “private keys 310 (a first private key 310 a and a second private key 310 b), public keys 320 (a first public key 320 a and a second public key 320 b), a DID document 510, and DID 152 a. Controller 230 of DID 152 a controls (see notation 551) private key 310 a and publishes (see notations 552) DID 152 a and public key 320 a.” (Para. 0113); “Once executed, this entire set of files may be routed back to locations specified in contracting party identifiers' DPKI metadata 162 a and 162 b and deleted from the application server.” (Para. 0199)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser in view of Chu with the technique of Davis to include two separate signatures on the same file, each tied to a different DID and difference key metadata in registries. Therefore, the incentives of establishing multi-party provenance using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, 9, and 16, Beser teaches:
The system of claim 1, wherein the first version of the ML model and the second version of the ML model are updated versions of a base ML model. (“validation node 130 generates an updated computing model (step 314) based on the model update data.” (Para. 0057); “Merging of updates to a computing model may be based on the input from multiple distributed observations.” (Para. 0022); “The smart contracts may use the initial computing models, new models, and/or model updates to determine actions to perform in system 100.” (Para. 0047))
As per Claim 3, 10, and 17, Beser teaches:
The system of claim 1, wherein the first digital asset comprises a . . . digitally signed by the first blockchain registry . . . of the first blockchain registry; and the second digital asset comprises a . . . digitally signed by the second blockchain registry . . . of the second blockchain registry. (“each node 110-1, 110-2, 110-3, and/or validation node 130-1, 130-2 may register with system 100 and/or an existing trust participant (e.g., identity provider, such as, for example a trusted certificate authority like VeriSign®, DigiCert®, etc.), and may be assigned and provided a private key and public key pair.” (Para. 0048); “each node 110-1, 110-2, 110-3 may use its associated public key to digitally sign transactions (e.g., transmissions of model update data) in system 100.” (Para. 0049); “Asymmetric encryption in particular may be of use in signing and verifying signatures for blockchain crypto operations.” (Para. 0030))
Beser in view of Chu does not disclose: “using a private key”.
However, as per Claim 3, Davis in the analogous art of secured payments between parties, teaches: “using a private key”. (See “system 100 represents a mathematically related pair of keys that includes a public key (e.g., public key 320 of FIG. 3 ) and a private key (e.g., private key 310 of FIG. 3 ) for encryption and/or decryption. In certain embodiments, the public key of asymmetric key pair 210 is used for encryption, and the related private key is used for decryption. In some embodiments, the private key of asymmetric key pair 210 is used for encryption, and the related public key is used for decryption.” (Para. 0106); “a. Public key 320 a and private key 310 a are cryptographically tied (see notation 553).” (Para. 0113); “DID 152 a is registered on a verifiable data registry (e.g., verifiable data registry 136 of FIG. 4 ) along with DID document 510 (or a location of DID document 510), which provides the binding between DID 152 a, public key 320 a, and private key 310 a.” (Para. 0113))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser in view of Chu with the technique of Davis to include a private-key digital signature for binding verifiable credentials/tokens via DID. Therefore, the incentives of strengthening the authenticity and verifiability of each transaction provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Beser in view of Chu does not disclose: “token”.
However, as per Claim 1, Davis in the analogous art of digital verifiable credentials, teaches: “token”. (See “The W3C sponsors a specification for verifiable credentials based on digitally signed attestations made by one identifier (the issuer) about another identifier (the subject) that can be cryptographically verified.” (Para. 0117); “Public key 320 a and private key 310 a are cryptographically tied (see notation 553). In certain embodiments, DID 152 a is registered on a verifiable data registry (e.g., verifiable data registry 136 of FIG. 4 ) along with DID document 510 (or a location of DID document 510), which provides the binding between DID 152 a, public key 320 a, and private key 310 a.” (Para. 0113); “Identifier 220 may certify itself by digitally signing a challenge message with the private key associated with the public key that is cryptographically bound to identifier 220. FIG. 2 illustrates these bindings (see notations 253) between controller 230, asymmetric key pair 210, and identifier 220.” (Para. 0108)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser in view of Chu with the technique of Davis to include digitally signed credential or file that identifies a model version, functioning as a token. Therefore, the incentives of improved secured settlement of approved transactions using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 4, 11, and 18 Beser teaches:
The system of claim 1, wherein a digital asset of the champion model is digitally signed by a third blockchain registry . . . of the third blockchain registry in response to selecting champion model. (“validation and/or acceptance of a new model, model update, or the like, may be controlled by smart contracts.” (Para. 0047); “asymmetric keys may be certificate-based, and issuance of the certificates may be controlled by an external or internal trust authority.” (Para. 0048); “each node 110-1, 110-2, 110-3 may use its associated public key to digitally sign transactions (e.g., transmissions of model update data) in system 100.” (Para. 0049))
Beser in view of Chu does not disclose: “using a private key”.
However, as per Claim 4, Davis in the analogous art of secured payments between parties, teaches: “using a private key”. (See “system 100 represents a mathematically related pair of keys that includes a public key (e.g., public key 320 of FIG. 3 ) and a private key (e.g., private key 310 of FIG. 3 ) for encryption and/or decryption. In certain embodiments, the public key of asymmetric key pair 210 is used for encryption, and the related private key is used for decryption. In some embodiments, the private key of asymmetric key pair 210 is used for encryption, and the related public key is used for decryption.” (Para. 0106); “a. Public key 320 a and private key 310 a are cryptographically tied (see notation 553).” (Para. 0113); “DID 152 a is registered on a verifiable data registry (e.g., verifiable data registry 136 of FIG. 4 ) along with DID document 510 (or a location of DID document 510), which provides the binding between DID 152 a, public key 320 a, and private key 310 a.” (Para. 0113))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser in view of Chu with the technique of Davis to include a private-key digital signature for binding verifiable credentials/tokens via DID. Therefore, the incentives of strengthening the authenticity and verifiability of each transaction provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 5, 12, and 19, Beser teaches:
The system of claim 4, wherein a model user of the champion model verifies the champion model by: verifying . . . on the digital asset of the champion model using a public key of one of the blockchain registry that provided the digital asset of the champion model; and verifying . . . on the digital asset of the champion model using a public key of the third blockchain registry. (“Each node 110-1, 110-2, 110-3, and/or validation node 130-1, 130-2 may also be configured to verify digital signatures, maintain integrity of Merkle tree, verify proof of work, and/or the like, similar to typical blockchain technologies.” (Para. 0049); “Asymmetric encryption in particular may be of use in signing and verifying signatures for blockchain crypto operations.” (Para. 0030); “the public key may be shared via the peer-to-peer network to each node 110-1, 110-2, 110-3, and/or validation node 130-1, 130-2.” (Para. 0048)).
Beser in view of Chu does not disclose: “a first signature [and] a second signature”.
However, as per Claim 1, Davis in the analogous art of secured payments between parties, teaches: “a first signature [and] a second signature”. (See “digitally signed by contracting party 122 a using digital signature 2010 a and asset owner 122 b using digital signature 2010 b.” (Para. 0207); “private keys 310 (a first private key 310 a and a second private key 310 b), public keys 320 (a first public key 320 a and a second public key 320 b), a DID document 510, and DID 152 a. Controller 230 of DID 152 a controls (see notation 551) private key 310 a and publishes (see notations 552) DID 152 a and public key 320 a.” (Para. 0113); “Once executed, this entire set of files may be routed back to locations specified in contracting party identifiers' DPKI metadata 162 a and 162 b and deleted from the application server.” (Para. 0199)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser in view of Chu with the technique of Davis to include two separate signatures on the same file, each tied to a different DID and difference key metadata in registries. Therefore, the incentives of establishing multi-party provenance using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 6, 13, and 20 Beser teaches:
The system of claim 1, wherein a digital asset of the champion model comprises one or more of an identifier of a base ML model, a version name of the version of the ML model, an identifier of an entity that trained the version of the ML model, a link to codes of the version of the ML model, a link to a training dataset used in training for the version of the ML model, a time when the version of the ML model is created, or a location where the version of the ML model is created. (“The request transaction may detail the desired model update (e.g., based on a model ID, model identifying data, update type, etc.), a payment amount, or the like.” (Para. 0033); “The metadata included in each block written to the blockchain may include arbitrary data about the computing model, usage and characteristics of the model, a list of differences to the model, IP addresses or identifying data from the computing node initiating the update, and/or any other suitable data.” (Para. 0021); “Validation node 130 may be configured to write the model update data to model blockchain 140 together with any other suitable data, such as, for example a hash of the model update data, a date or timestamp, identifying information of the node 110 that transmitted the model update data (e.g., IP address, blockchain address, etc.), and/or any other suitable data or metadata.” (Para. 0056)).
As per Claim 7 and 14, Beser teaches:
The system of claim 1, wherein . . .
Beser in view of Chu does not disclose:
“the first digital asset is identified using a first Decentralized Identifier (DID); the second digital asset is identified using a second DID; and the ML model is identified using a universal unique identifier generated based at least in part on the first DID and the second DID” (claim 7).
However, as per Claim 7, Davis in the analogous art of secured transactions between parties, teaches: “the first digital asset is identified using a first Decentralized Identifier (DID); the second digital asset is identified using a second DID; and the ML model is identified using a universal unique identifier generated based at least in part on the first DID and the second DID”. (See “determining that the hybrid legal document transfers ownership of an asset from the second party to the first party, wherein the asset is associated with an asset DID; populating the first party as a new controller of the asset DID; and removing the second party as a controller of the asset DID.” (Claim 18); “the operations include determining that the hybrid legal document transfers ownership of an asset from the second party to the first party, wherein the asset is associated with an asset DID, populating the first party as a new controller of the asset DID, and/or removing the second party as a controller of the asset DID.” (Para. 0042, see also Fig. 25); “The first party is associated with a first party decentralized identifier (DID), and the second party is associated with a second party DID. The method also includes receiving negotiation data from the first party and the second party and generating a data model using the first party DID, the second party DID, and the negotiation data.” (Para. 0046); “hybrid legal contract identifier 2118 (DID/Hash/UUID 2124) may be obtained directly from data model 930 or a DID generation function taking as input hybrid legal contract 154 a. The hybrid legal contract identifier may be a DID for the hybrid legal contract, simple hash values of the hybrid legal contract file, “smart contract” addresses residing on a distributed ledger, and the like.” (Para. 0218)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Beser with the technique of Davis to include a DID-based identity and a composite model UUID within the transaction system. Therefore, the incentives of ensuring cross-ledger interoperability and transaction auditability provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20210357819A1 (Levacher), discussing “various embodiments of the present invention provide for ensemble training in a distributed marketplace (e.g., a blockchain) in a computing environment. One or more ensemble machine learning models may be provided from a plurality of machine learning models competing within the distributed marketplace (e.g., a blockchain) that achieve a performance on ensemble training data equal to or greater than a selected performance threshold, wherein the distributed marketplace is a blockchain.” (Para. 0018).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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 Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights