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 . In communications filed on 01/29/2026. Claims 17, 24, 31, 33, 35-36 are amended. Claims 1-16 , 18-19, 25-26, 32 are cancelled . Claims 37-41 newly added. Claims 17, 20-24, 27-31, and 33-41 are pending in this examination.
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. This examination is in response to US Patent Application No. 18/429,318.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 17, 20-24, 27-31, and 33-41 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The independent claims 17, 24, and 31 recite “cryptographic nonce”, which renders the claim indefinite because the claim does not explain what this limitation is and there is nothing in the specification defining this limitation.
The independent claims 17, 24, and 31 recite “by using the cryptographic nonce as a message authentication code (MAC) function key to generate a cryptographic hash indicative of the output and the cryptographic nonce” which renders the claim indefinite, because the claim does not explain if we are using the nonce as HMAC key to generate a hash, how the output hash indicative of nonce? Is this limitation basically indicates using HMAC key to hash the output? And furthermore, there is nothing in the specification defining this limitation.
The examiner maps the limitation based on the broadest reasonable interpretation.
Claims 20-23, 37, 40 , and 27-30, 38, 41, and 33-36, 39 do not cure the deficiency of claims 17, 24, and 31 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claim 17, 24, and 31.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 17, 20-24, 27-31, and 33-41 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The independent claims 17, 24, and 31 recite “cryptographic nonce” which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
The independent claims 17, 24, and 31 recite “by using the cryptographic nonce as a message authentication code (MAC) function key to generate a cryptographic hash indicative of the output and the cryptographic nonce”, which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 20-23, 37, 40 , and 27-30, 38, 41, and 33-36, 39 do not cure the deficiency of claims 17, 24, and 31 and are rejected under 35 USC 112, 1st paragraph, for their dependency upon claim 17, 24, and 31.
Response to Argument
Applicant’s amendment to claims 24, and 33 obviates previously raised claims 24, and 33 35 USC § 112(b) , second paragraph rejection.
Applicant’s arguments with respect to claims 17, 20-24, 27-31, and 33-41 for newly added limitations have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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 of this title, 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 17, 20-22, 24, 27-31, 33, and 35-39 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No.(2022/0019663 A1) issued to Stapleton, and in view of US Patent No. (20210390447) issued to Cheruvu.
Regarding claim 17, Stapleton discloses a computing device comprising: memory comprising instructions and processing circuitry to execute the instructions to: receive a model package from a service provider, wherein the model package is encrypted by the service provider [¶35, In various implementations, one or more ML models may be stored by AI provider system 100 in a ML model database 104. These ML models may take various forms, such as deep learning neural networks, recurrent neural networks (“RNNs”), convolutional neural networks (“CNNs”), support vector machines, decision trees, reinforcement learning models, adversarial generative networks (“GANs”), and so forth. AI provider system 100 may make these ML models available to remote computing systems 102 in various ways. In some implementations, remote computing systems 102 may download copies of ML models from database 104 and store them locally, e.g., in their own databases (e.g., 116)], and
[0008] Generally, in one aspect, a method may be implemented using one or more processors and may include: providing an encryption key that is associated with a particular entity, wherein the particular entity has access to a machine learning model that is trained to generate one or more outputs based on data applied across a plurality of inputs; encrypting one or more parameters of the trained machine learning model using the encryption key; encrypting input data to be applied as input across the trained machine learning model; applying the encrypted input data as input across the encrypted trained machine learning model to generate encrypted output; decrypting the encrypted output using a decryption key to generate decrypted output; analyzing the decrypted output using the decryption key to determine that one or more of the parameters of the trained machine learning model have been compromised]; and [¶59, Additionally or alternatively, in some embodiments, in output stage 442 (on the right in FIG. 4), encrypted input data 448 may remain encrypted, and may be employed as input across an encrypted version of FFNN 420′. In various embodiments, encrypted FFNN 220′ (indicated with the shading) may be generated, e.g., using encryption key 446 or another encryption key so that it only accepts encrypted data; unencrypted input may lead to erroneous output. Various types of encryptions may be used, such as RSA or other forms mentioned earlier. In some embodiments, encrypted FFNN 420′ may be generated using homomorphic encryption, which as noted previously is a mechanism by which mathematical operations such as those associated with encrypted FFNN 420′ can be applied to encrypted data to generate encrypted output 453. Encrypted FFNN 420′ may remain encrypted even when loaded into volatile memory for use. The encrypted output 453 can then be decrypted, e.g., using digital key 426, to yield decrypted output 454, which may constitute actual valid results due to the homomorphic nature of the encryption. Additionally, or alternatively, in some embodiments, garbled circuits may be employed]; and
decrypt the model package received from the service provider to identify a machine learning model and a model execution contract that specifies model execution conditions associated with the machine learning model as defined by the service provider [¶8, Generally, in one aspect, a method may be implemented using one or more processors and may include: providing an encryption key that is associated with a particular entity, wherein the particular entity has access to a machine learning model that is trained to generate one or more outputs based on data applied across a plurality of inputs; encrypting one or more parameters of the trained machine learning model using the encryption key; encrypting input data to be applied as input across the trained machine learning model; applying the encrypted input data as input across the encrypted trained machine learning model to generate encrypted output; decrypting the encrypted output using a decryption key to generate decrypted output; analyzing the decrypted output using the decryption key to determine that one or more of the parameters of the trained machine learning model have been compromised; and causing one or more computing devices to provide output that indicates that the one or more parameters of the trained machine learning model have been compromised], and [¶33, In various implementations, AI provider system 100 may provide, to one or more individuals (“users”), access to one or more machine learning (“ML”) models. The users may use the ML models for various purposes, such as making predictions, classifications, diagnoses (e.g., clinical decision support, or “CDS”), operating equipment (e.g., altering medical equipment parameters), performing object and/or entity recognition, handwriting recognition, and so forth. In some embodiments, AI provider system 100 may provide various levels of ML model access to different individuals and/or entities, depending on credentials provided by and/or on behalf of the individuals and/or entities], and [¶45, Various techniques may be employed, e.g., by integrity engine 108, to verify integrity of ML models. For example, and referring now to FIG. 2, an example ML model in the form of a feed-forward neural network (“FFNN”) 220 is depicted. As noted previously, FFNN 220 may be stored locally to AI provider system 100 in database 104, or remotely on one or more remote computing systems 102 (e.g., in database 116) ….], and [¶49, Known verification outputs 230 may be precomputed, e.g., in a secure environment, prior to verification of FFNN 220. For example, whenever FFNN 220 is trained or retrained, e.g., by AI provider system 100, digital key 226 may be applied across all or portion(s) of FFNN 220 to generate output. Output of various nodes and/or layers may be captured to generate known verification output 230. This known verification output 230 may then be saved, e.g., in non-volatile memory (e.g., locally to AI provider system 100 in database 104 or remotely in database 116). In some implementations known verification output 230 may be encrypted when stored in non-volatile memory, e.g., so that end users cannot access it. Additionally, or alternatively, known verification output 230 may be encrypted using a public key assigned to an entity that operates a remote computing system 102. That same entity may be provided with a private digital key, such as 226, that can be both applied across FFNN 220 for verification purposes and used to decrypt known verification data 230], and [¶55, In some embodiments, various data associated with use of a ML model may be encrypted at various stages in order to verify the model's integrity and/or to authenticate use of the ML model. In FIG. 4, for instance, there are three stages of application of a ML model depicted schematically: input stage 438, encryption of the ML model and weights in non-volatile memory stage 440, and output stage 442], and [¶59, Additionally or alternatively, in some embodiments, in output stage 442 (on the right in FIG. 4), encrypted input data 448 may remain encrypted, and may be employed as input across an encrypted version of FFNN 420′. In various embodiments, encrypted FFNN 220′ (indicated with the shading) may be generated, e.g., using encryption key 446 or another encryption key so that it only accepts encrypted data; unencrypted input may lead to erroneous output. Various types of encryptions may be used, such as RSA or other forms mentioned earlier. In some embodiments, encrypted FFNN 420′ may be generated using homomorphic encryption, which as noted previously is a mechanism by which mathematical operations such as those associated with encrypted FFNN 420′ can be applied to encrypted data to generate encrypted output 453. Encrypted FFNN 420′ may remain encrypted even when loaded into volatile memory for use. The encrypted output 453 can then be decrypted, e.g., using digital key 426, to yield decrypted output 454, which may constitute actual valid results due to the homomorphic nature of the encryption. Additionally, or alternatively, in some embodiments, garbled circuits may be employed], and [ see FIG.8 and corresponding text for more details]; and
verify that the computing device complies with the model execution contract by verifying that the computing device includes hardware components as specified by the model execution contract, verifying that the computing device includes software components as specified by the model execution contract, and verifying that the computing device is capable of supplying a data source for the machine learning model as specified by the model execution contract[¶53, In this example, license engine 106 performs computations (e.g., hash function) to map digital key 226 to a first entry of lookup table 334. This first entry specifies various information about a ML model stored, e.g., in database 104 (or remotely from AI provider system 100). In this example, the entry has a “description” of “Lung Cancer Risk AI,” which suggests it is a ML model that is trained to receive, as input, various clinical parameters associated with a patient (e.g., vital signs, digital images of the lungs, CT scans, magnetic resonance imaging (“MRI”) data, demographic data, symptoms, medications, etc.), and to generate output indicative of a risk of lung cancer. The entry has a “version” of “1.0.1,” a “date deployed” of May 3, 2018, a licensee name, a license expiration date, a “date retained” (which in this case is N/A because the ML model is still in its original form), compatible hardware, and compatible software (e.g., software that is configured to apply input data across the model)], and [¶¶55-58, In some embodiments, various data associated with use of a ML model may be encrypted at various stages in order to verify the model's integrity and/or to authenticate use of the ML model. In FIG. 4, for instance, there are three stages of application of a ML model depicted schematically: input stage 438, encryption of the ML model and weights in non-volatile memory stage 440, and output stage 442. In input stage 438, input data may be received/obtained/retrieved from a variety of sources 444. These sources may include, but are not limited to, image data 4441 obtained from medical imaging devices such as X-rays, CT scans, MRIs, EKG, etc., imaging protocol data 4442 (e.g., digital imaging and communications in medicine, or “DICOM,” picture archiving and communication systems, or “PACS,” etc.), demographic data 4443, and medical history data 4444 (e.g., obtained from EHRs).( equated to hardware and software component) .Other sources of input data are also contemplated herein. Before or during input stage 438, an encryption key 446 may be provided, e.g., by AI provider system 100 to one or more remote computing systems 102 (see FIG. 1). This encryption key 446 may be used by one or more users (114 in FIG. 1) to generate, from data provided by sources 444, encrypted data 448. When the time comes to apply the encrypted input data 448 across one or more ML models, such as FFNN 420 (which may be similar to or different from 220 in FIG. 2), various actions may be taken. In some embodiments, a unique private digital key 426 (which may be similar to digital key 226) may be used at block 450 to decrypt the decrypted data 448, e.g., so that the decrypted data can then be applied as input across an unencrypted version of FFNN 420 (as shown at 451). Up until this time, however, the input data may remain in its encrypted form 448. In these embodiments, encrypting the input data up until its use (e.g., until it is loaded into volatile memory) provides at least some security against unauthorized parties obtaining access to the potentially sensitive data. For example, some hackers may be opportunists that, when confronted with encrypted input data (i.e. while awaiting application across FFNN 420), may look elsewhere for data to exploit]; and
execute the machine learning model using data from the data source to generate an output responsive to verifying that the computing device complies with by the model execution contract [see FIG.4 and corresponding text for more details, [0060] In some embodiments, in the encryption of ML model 420 and weights in non-volatile memory stage 440 (in the middle of FIG. 4), encryption key 446 may be used at 456 to encrypt parameters and weights associated with FFNN 420 to generate encrypted model file 458 and encrypted weights file 460. Various encryption techniques may be employed, such as RSA or others mentioned previously. Later, e.g., when decrypted or encrypted input data is about to be applied across FFNN 420, digital key 426 (or another digital key) may be used at block 462 to decrypt encrypted model file 458 and encrypted weights file 460. This may occur, for instance, when FFNN 420 is loaded into volatile memory (e.g., of AI provider system 100 or remote computing system 102) for use. Thus, while FFNN 420 is stored in non-volatile memory (e.g., disk, solid state memory, etc.), it may remain encrypted and hence protected at least somewhat from malicious users. It is only when FFNN 420 is to be used and is loaded into volatile memory (e.g., RAM) that it is encrypted (e.g., at block 462 using digital key 426)], and [¶¶55-59]; and
generate an attestation certifying that the output was generated by computing device model in accordance with the model execution contract; and send the output and the attestation to the service provider[¶39, Integrity engine 108 may be configured to examine various aspects of ML models stored locally to AI provider system 100 (e.g., in database 104) and/or remotely, e.g., in database 116, to determine whether and/or how those ML models may have been compromised. For example, a malicious party may gain access to a ML model stored in database 116 and may alter one or more aspects of the ML model, such as altering or deleting one or more parameters or weights in various layers. Alternatively, a licensed entity may attempt to make changes to its locally stored model when it is not licensed to do so. In either case, integrity engine 108 may be configured to apply various techniques described herein or cause these techniques to be applied at one or more remote computing systems 102, in order to verify the integrity of a ML model and/or to take appropriate remedial action when it determines that a ML model has been compromised. In some embodiments, integrity engine 108 may verify the integrity of a ML model by applying a digital key as input across the ML model to generate output, which is then verified by integrity engine 108 as described herein], and], and [¶¶43, 47, 50, 62].
a cryptographic nonce; by using the cryptographic nonce as a message authentication code (MAC) function key to generate a cryptographic hash indicative of the output and the cryptographic nonce
while Stapleton discloses these limitations as: [¶¶52-53, FIG. 3 depicts an example of a lookup table 334 that may store information usable, e.g., by license engine 106, to determine information about ML models stored in database 104 (or ML models stored remotely, such as in database 116 or on local volatile or non-volatile memory of remote computing systems 102.sub.2, 102.sub.N, etc.). In various implementations, license engine 106 may receive, as input, digital key 226. License engine 106 may perform various types of functions to map digital key 226 to one or more records in lookup table 334. For example, in some embodiments, license engine 106 may perform various hash functions to map digital key 226 to one or more records of lookup table 334. In this example, license engine 106 performs computations (e.g., hash function) to map digital key 226 to a first entry of lookup table 334. This first entry specifies various information about a ML model stored, e.g., in database 104 (or remotely from AI provider system 100). In this example, the entry has a “description” of “Lung Cancer Risk AI,” which suggests it is a ML model that is trained to receive, as input, various clinical parameters associated with a patient (e.g., vital signs, digital images of the lungs, CT scans, magnetic resonance imaging (“MRI”) data, demographic data, symptoms, medications, etc.), and to generate output indicative of a risk of lung cancer. The entry has a “version” of “1.0.1,” a “date deployed” of May 3, 2018, a licensee name, a license expiration date, a “date retained” (which in this case is N/A because the ML model is still in its original form), compatible hardware, and compatible software (e.g., software that is configured to apply input data across the model).
Furthermore, Cheruvu discloses these limitation as:
[Abstract, an embodiment of a system includes a hardware accelerator to perform processing related to a machine learning (ML) model and one or more processors including a hash generator. In one implementation, the hash generator is to identify a global unique identifier (GUID) for the ML model, generate a digital signature for content generated by an inference stage of the ML model, the digital signature based on at least the GUID of the ML model and the content generated by the ML model], and [ ¶¶20-21, Other previous solutions may utilize machine learning models or forensic systems to predict whether text was generated by a model or a human… authenticating and verifying AI-generated output utilizing a globally unique identifier (GUID). The GUID of implementations of the disclosure is used to authenticate and validate the output of content with respect to the identity of the author or owner of the outputted content (e.g., the ML model or human author)… Implementations of the disclosure provide protection of AI and ML models, and the output data generated from such models, in addition to supporting an end-to-end ML security pipeline by helping secure the authenticity and validity of output data], and [¶37, In some implementations, the hash generator 113 and/or the verification component 132 can use a hash-based MAC (HMAC), which is a keyed hashing mechanism, as a basis for the digital signature. In the case of an HMAC, the GUID can act as key and at the same time uniquely identify the AI model that it is associated with. Other functions, such as PBKDF2, that are based on HMAC could also be used as well. As noted previously, the GUID can be sent from the sender (e.g., hash generator 113) to the verifier (e.g., verification component 132) through a secure transmission channel 150], and [¶51, In one implementation, the digital signature generated by hash generator 228 may be a hash of one or more the generated content (e.g., plaintext), the GUID 270, a ML model ID, and/or a timestamp. In some implementations, the hash generator 228 can use a HMAC to generate the digital signature. Once the digital signature is generated by hash generator 228, the publication component 224 may then transmit the digital signature, along with the content (e.g., plain text), timestamp, and model ID to the content consumer system 250], and [¶72, In the illustrated embodiment shown in FIG. 5, the flow 500 may begin at block 510. At block 510, the processor may receive, by a processor of a content consumer platform, content generated by a machine learning (ML) model and a digital signature corresponding to the content. At block 520, the processor may process the digital signature to extract, from the digital signature, a global unique identifier (GUID) of the ML model that generated the content], and [ claim 1, A system comprising: a hardware accelerator to perform processing related to a machine learning (ML) model; and one or more processors including a hash generator to: identify a global unique identifier (GUID) for the ML model; generate a digital signature for content generated by an inference stage of the ML model, the digital signature based on at least the GUID of the ML model and the content generated by the ML model; and transmit the content and the digital signature to a content consumer platform], and [claim 7, wherein the digital signature comprises a hash-based message authentication code (HMAC) of the content and the GUID].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Stapleton by incorporating “hash-based MAC (HMAC),”, as taught by Cheruvu. One could have been motivated to do so in order for supporting an end-to-end ML security pipeline by helping secure the authenticity and validity of output data [ Cheruvu, ¶¶21, 37].
Regarding claim 20, Stapleton discloses, wherein the processing circuitry is to execute the instructions to train the machine learning model based on the output to generate new weights for the machine learning model [¶45, Various techniques may be employed, e.g., by integrity engine 108, to verify integrity of ML models. For example, and referring now to FIG. 2, an example ML model in the form of a feed-forward neural network (“FFNN”) 220 is depicted. As noted previously, FFNN 220 may be stored locally to AI provider system 100 in database 104, or remotely on one or more remote computing systems 102 (e.g., in database 116). FFNN 220 includes multiple layers, including an input layer 221, two hidden layers 222.sub.1-2, two sets of weights 223.sub.1-2 between various layers, and an output layer 224. FFNN 220 is provided for illustrative purposes only, and therefore is relatively small. It should be understood that the techniques described herein are], and [¶55, In some embodiments, various data associated with use of a ML model may be encrypted at various stages in order to verify the model's integrity and/or to authenticate use of the ML model. In FIG. 4, for instance, there are three stages of application of a ML model depicted schematically: input stage 438, encryption of the ML model and weights in non-volatile memory stage 440, and output stage 442].
Regarding claim 21, Stapleton discloses, wherein the processing circuitry is to execute the instructions to generate the attestation by generating a cryptographic hash indicative of the new weights for the machine learning model [¶¶52-53, FIG. 3 depicts an example of a lookup table 334 that may store information usable, e.g., by license engine 106, to determine information about ML models stored in database 104 (or ML models stored remotely, such as in database 116 or on local volatile or non-volatile memory of remote computing systems 102.sub.2, 102.sub.N, etc.). In various implementations, license engine 106 may receive, as input, digital key 226. License engine 106 may perform various types of functions to map digital key 226 to one or more records in lookup table 334. For example, in some embodiments, license engine 106 may perform various hash functions to map digital key 226 to one or more records of lookup table 334.In this example, license engine 106 performs computations (e.g., hash function) to map digital key 226 to a first entry of lookup table 334. This first entry specifies various information about a ML model stored, e.g., in database 104 (or remotely from AI provider system 100). In this example, the entry has a “description” of “Lung Cancer Risk AI,” which suggests it is a ML model that is trained to receive, as input, various clinical parameters associated with a patient (e.g., vital signs, digital images of the lungs, CT scans, magnetic resonance imaging (“MRI”) data, demographic data, symptoms, medications, etc.), and to generate output indicative of a risk of lung cancer. The entry has a “version” of “1.0.1,” a “date deployed” of May 3, 2018, a licensee name, a license expiration date, a “date retained” (which in this case is N/A because the ML model is still in its original form), compatible hardware, and compatible software (e.g., software that is configured to apply input data across the model)].
Regarding claim 22, Stapleton discloses, wherein the data source comprises a sensor included on the computing device or an external device in communication with the computing device [see FIG 1 and corresponding text for more details].
Regarding claim 27, this claim is interpreted and rejected for the same rational set forth in claim 20.
Regarding claim 28, this claim is interpreted and rejected for the same rational set forth in claim 21.
Regarding claim 29, this claim is interpreted and rejected for the same rational set forth in claim 23.
Regarding claim 30, Stapleton discloses storing the machine learning model in a protected memory of the computing device prior to verifying that hardware components and software components for execution of the machine learning model in accordance with the model execution contract are included on the computing device [¶35, In various implementations, one or more ML models may be stored by AI provider system 100 in a ML model database 104…].
Regarding claim 31, this claim is interpreted and rejected for the same rational set forth in claim 17.
Regarding claim 33, this claim is interpreted and rejected for the same rational set forth in claim 20.
Regarding claim 35, Stapleton discloses wherein the instructions, when executed by the processing circuitry, cause the processing circuitry to: receive an encrypted data package from the service provider; and decrypt the encrypted data package from the service provider to identify the first version of the machine learning model, the model execution contract that is associated with the machine learning model, and the cryptographic nonce [¶35, In various implementations, one or more ML models may be stored by AI provider system 100 in a ML model database 104. These ML models may take various forms, such as deep learning neural networks, recurrent neural networks (“RNNs”), convolutional neural networks (“CNNs”), support vector machines, decision trees, reinforcement learning models, adversarial generative networks (“GANs”), and so forth. AI provider system 100 may make these ML models available to remote computing systems 102 in various ways. In some implementations, remote computing systems 102 may download copies of ML models from database 104 and store them locally, e.g., in their own databases (e.g., 116)], and
[¶8, Generally, in one aspect, a method may be implemented using one or more processors and may include: providing an encryption key that is associated with a particular entity, wherein the particular entity has access to a machine learning model that is trained to generate one or more outputs based on data applied across a plurality of inputs; encrypting one or more parameters of the trained machine learning model using the encryption key; encrypting input data to be applied as input across the trained machine learning model; applying the encrypted input data as input across the encrypted trained machine learning model to generate encrypted output; decrypting the encrypted output using a decryption key to generate decrypted output; analyzing the decrypted output using the decryption key to determine that one or more of the parameters of the trained machine learning model have been compromised].
Regarding claim 36, this claim is interpreted and rejected for the same rational set forth in claim 22.
Regarding claims 37-39, Stapleton discloses wherein verifying that the computing device includes hardware components as specified by the model execution contract comprises verifying that the memory comprises a protected memory.[ ¶53, compatible hardware, and compatible software], and [¶60, while FFNN 420 is stored in non-volatile memory (e.g., disk, solid state memory, etc.), it may remain encrypted and hence protected at least somewhat from malicious users].
Claims 23, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2022/0019663) issued to Stapleton , and in view of US Patent No. (20210390447) issued to Cheruvu, and further in view of US Patent No. (US2022/0067570) issued to KNOG.
Regarding claim 23, Stapleton, and Cheruvu do not explicitly disclose, however, KONG discloses wherein the processing circuitry is to execute the instructions to delete the machine learning model from the computing device after sending the output and the attestation to the service provider [¶14, The examples, implementations, and embodiments described herein may help address these issues when allowing access to training data for training machine learning models. In one embodiment, the training data is stored on a storage system which may allow only a training environment (e.g., a secure environment) to retrieve and/or access the training data. The training data may be inaccessible to all computing devices and/or machine learning models outside of the training environment and/or storage system (e.g., may be inaccessible to external devices). When a machine learning model is granted access to or is allowed to use the training data, the training data is temporarily copied to the training environment. The machine learning models is allowed to execute, run, operate, etc., using the training data. However, the secure environment may prevent the machine learning model from copying the training data outside of the training environment (e.g., prevent the training data from being transmitted to another computing device outside of the training environment). After the machine learning model is trained using the training data, the training environment may delete the training data. The examples, implementations, and embodiments described herein allow machine learning models to be trained using private, proprietary, confidential, etc., training data while prevent other computing devices from being able to see or view the actual training data. This allows the training data to be used to train other machine learning models while keeping the training data private/confidential], and [¶¶31-32, In one embodiment, the storage component 112 may provide instructions and/or an indication that the training data 111 (and/or portions of the training data 111) that is transmitted to the training environment (and used to train machine learning models) are to be deleted after a period of time. For example, storage component 112 may transmit a message indicating that the training environment 120 should delete the copy of the training data that is stored in the training environment 120. In another example, the storage component 112 may transmit a message indicating a time (e.g., a specific date and/or time) when the copy of the training data 111 that is stored in the training environment 120 should be deleted. In another embodiment, the training environment 120 may automatically delete the training data 111. For example, the training token granted to the computing device 140 may be valid for a period of time (e.g., valid for 24 hours after the training token was transmitted to the computing device 140). When the training environment 120 receives the training token from the computing device 140, the training environment 120 may determine the period of time for which the training token is valid. The training environment 120 may delete the training data after the period of time has passed, elapsed, expired, etc.], and [¶42, In one embodiment, the training data 111 may be temporarily stored within the training environment 120. For example, the training data 111 may be stored on data storage devices (or other data stores) of the training environment 120 while the machine learning model 125 is being trained. After the machine learning model 125 has been trained, the training data 111 may be deleted from the training environment 120 (e.g., deleted from the data storage devices of the training environment 120). In another example, the training token (which was used to retrieve the training data 111 from the storage system 110) may be valid for a period of time. The training component 122 may delete the training data 111 from the training environment 120 after the period of time passes/expires].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Stapleton, and Cheruvu by incorporating “deleting the training data”, as taught by KNOG. One could have been motivated to do so in order to allow machine learning models to be trained using private, proprietary, confidential, etc., training data while prevent other computing devices from being able to see or view the actual training data. This allows the training data to be used to train other machine learning models while keeping the training data private/confidential. [ KONG, Pages ¶¶14, 31-32, 42].
Regarding claim 34, this claim is interpreted and rejected for the same rational set forth in claim 23.
Claims 40-41 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No.(2022/0019663 A1) issued to Stapleton, and in view of US Patent No. (20210390447) issued to Cheruvu, and further in view of US Patent No. 2020/0184036) issued to WU.
Regarding claims 40-41, wherein verifying that the computing device includes hardware components as specified by the model execution contract comprises verifying that the computing device comprises a trusted platform module (TPM).
While Stapleton discloses [0049] Known verification outputs 230 may be precomputed, e.g., in a secure environment, prior to verification of FFNN 220. For example, whenever FFNN 220 is trained or retrained, e.g., by AI provider system 100, digital key 226 may be applied across all or portion(s) of FFNN 220 to generate output].
However, Stapleton does not explicitly disclose, and Wu discloses a trusted platform module (TPM).
[¶¶20-21 For instance, in one example embodiment, weights of the DNN model may be encrypted with traditional data encryption methods such as Rivest-Shamir-Adleman (RSA) or advanced encryption standard (AES). However, this would mean that for the DNN model to be run properly, either the DNN model needs to be put into a trusted computing platform using trusted platform modules (TPMs) so that all the encrypted model parameters can be decrypted and then securely run to provide results, or the DNN computations directly on the encrypted parameters are enabled through homomorphic encryption or other types of encrypted-domain computation tools… FIG. 1 illustrates a DNN model framework, according to an example embodiment. Certain example embodiments may maintain the main part of the DNN that can be run in a similar way as an ordinary DNN utilizing the available software-hardware platform and produce state-of-the-art results when taking in an authorized type of input. As illustrated in FIG. 1, a transformation module may be provided that provides authorized inputs at a reasonable level of computational complexity by dividing the overall system into two parts. In certain example embodiments, the two-part design makes it possible to concentrate the security resource to protect the transformation module, for example, through a trusted computing platform, and utilize such module to achieve access control and privacy protection on the learning system with valuable and/or sensitive outcomes. The design may also provide protection against insiders (e.g., theft/piracy) of the trained machine-learning model.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Stapleton, and Cheruvu by incorporating “a trusted platform module (TPM)”, as taught by WU. One could have been motivated to do so in order to through a trusted computing platform and utilize such module to achieve access control and privacy protection on the learning system with valuable and/or sensitive outcomes [ WU, ¶¶20-21].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
Harvilla ( US2019/0303790) [0017] Embodiments utilize processing resources of crypto-currency miners for performing valuable computation. For example, the processing resources of crypto-currency miners are used to train machine learning based models. Accordingly, computing devices participating in a blockchain network generate a nonce that is a numeric value associated with training of a machine learning based model.], and [0023] In an embodiment, the nonce is based on numerical byproduct value(s) generated as a result of training the machine learning model, for example, a measure of accuracy of the training model. An example of measure of accuracy used is an error metric representing an aggregate error of the results of the trained machine learning model obtained by predicting results from a labelled dataset and comparing the predicted results with known results. Examples of error metrics for machine learning models used by embodiments include r-squared error, mean squared error, F-score, cross entropy, KL divergence, and so on. A computing device 100 of the blockchain network 110 uses the numeric value of the error metric as the nonce. In some embodiments, the computing device 100 determines the nonce value based on weights of the model, for example, by determining an aggregate value based on one or more weights of the model. For example, the computing device 100 may determine the nonce as the sum of all weights, an average of all weights, or a hash value based on the weights.[0051] The processor receives 806 a trained version of the machine learning model (e.g., in accordance with the task). A nonce may be generated as a byproduct of the trained version (e.g., based on an error value associated with how well the machine learning model is trained). The processor, in response to receiving the trained version, determines 808 whether the trained version of the machine learning model satisfies an acceptance criterion (e.g., based on predictive data, as described above).
Weinzettl ( US2021/014891) [ [0026] It will therefore be appreciated that there is proposed a concept of tracking and auditing provenance across multiple steps of a software configuration or build process by building history of provenance as a chain of hashes. Every single record may comprise a hash code that proves authenticity of output data, and may also comprise a HMAC code which proves both input data (as well as a tool used in the software configuration or build process)], and [0036] In particular, referring to the example depicted in FIG. 3, the second verification value 305 (e.g., HMAC value) is calculated from the input data 310 and the secret key 315 of this process step (using a HMAC function 318), whereas the first verification value (e.g., HASH value) 320 is calculated from the output data (using a hash function 330). The first verification value (e.g., HASH value) in the last (i.e., most recent) history of the provenance data 335 (i.e., a combination of the preceding HASH, HMAC, and VHMAC), is used to generate the third verification value (e.g., VHMAC value) 340 using the current HMAC as a key and a VHMAC function 345. The resulting verification values (e.g., HASH, HMAC and VHMAC values) 350 are attached to the chain of historical provenance records], and [0038] A single verification record 400 comprises: (i) a hash value 410, that proves authenticity of output data 325; (ii) a HMAC value 415, that proves both input data 310 as well as the tool used in the process; and (iii) a VHMAC (Verifiable HMAC) value 420, that proves all the previous/preceding record in the chain of verification records, the HASH value of the verification record and the HMAC value of the verification record.
Bursell ( US2021/0374234) [0065] The program that receives the attestation data may use the attestation data to verify the capabilities of computing device 110A. The program may execute a verification function to verify the computing device 110A in view of the attestation data. The verification function may take as input the attestation data and provide output that indicates whether the computing device 110A is verified (e.g., trusted). In one example, the attestation data may include integrity data (e.g., a message authentication code (MAC)) and the verification function may analyze a portion of attestation data to generate validation data. The verification function may then compare the received integrity data with the generated validation data to perform the attestation (e.g., compare received MAC with generate MAC). In another example, the verification function may take as input data from a different source, such as source code or compiled code and generate validation data that is compared to the received attestation data to determine if the computing device 110A can be trusted to perform a particular set of operations (e.g., combine keys and execute communal operation)], [0098]
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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights