DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The Amendment filed on February 13, 2025 has been entered. Claims 1, 6, 11, 16, and 20 were amended. As a result, claims 1-20 are pending, of which claims 1, 11, and 20 are in independent form.
Response to Amendment
Applicant’s amendment regarding claims 1, 11, and 20 does not obviate the claim rejection, therefore the claim rejection under 35 USC § 112 (a) is maintained.
Applicant’s amendment regarding claims 1, 11, and 20 does not obviate the claim rejection, therefore the claim rejection under 35 USC § 112 (b) is maintained.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected, under 35 USC 103(a), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter.
On Page 8 of remarks, Applicant argues that “none of claims 1, 11 or 20 recite "which can be utilized together to determine a symmetric channel key", rendering the objection moot.”. Applicant argument is nor persuasive. The Applicant’s argument “which can be utilized together to determine a symmetric channel key” is not recited in the amended claims. The Examiner notes that the rejection is based on the functional relationship among the claimed elements such as “the ECDH keypair, the enclave quote including a hash of the public key, the attestation data object enveloping the public key and enclave quote”, as explained in the office action, the specification fails to describe how these elements are used together to support the generation of the symmetric channel key. Therefore, the rejection under 112(a) is maintained.
Further, Applicant argues that “generate, by a secure enclave, an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair", this has been addressed in that amended claim 1 recites "generate, by a secure enclave data processor of a secure enclave of the trusted execution environment", which the Applicant submits resolves any alleged ambiguity.”. the examiner disagrees. The specification fails to describe how the “an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair” are generated by a secure enclave data processor. Therefore, the rejection under 112(a) is maintained.
Furthermore, the amendment regarding the limitation “said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database" obviated the 112(b) rejection. Therefore, the 112(b) rejection is withdrawn.
In addition, on page 9 of remarks, Applicant argues that “There is no teaching or suggestion in Costa of applying one or more data protection policies to a query data object to determine whether the query data object adheres to the one or more data protection policies, nor is there any teaching or suggestion of validating that a data custodian data process is operating on the secure enclave data processor and receiving an attestation token data object from an attestation process which is transmitted to a key manager to release one or more data protection keys”. Applicant’s arguments, with respect to the rejection(s) of claim(s) 1, 11 and 20 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Wang et al. (US 2021/0097528 A1).
Therefore, the examiner maintains the rejection under 35 USC § 103.
The same reasons apply to dependent claims 2-10, and 12-19 at least virtue of their dependencies.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
claim 1 recites “an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair of the secure enclave, and an attestation data object that envelops the public key and the enclave quote”, which can be utilized together to generate … a symmetric channel key. The specification fails to describe how the claimed hash of the public key, attestation data object, and enclave quote are combined or utilized together to determine a symmetric channel key. While the disclosure describes attestation process and key exchange operations. (see, e.g., paragraphs [0287]- [0295], On the client side, the secure channel key is derived using the client's private key and the enclave's public key, and on the enclave side this same symmetric key is generated using the clients public portion of the generated ECDH key and the enclave's private ECDH key. The enclave can generate this ECDH keypair as soon as a secure channel is created. This keypair is then encrypted with a key protecting key which is released only to the enclave by AKV-MHSM)).
claim 1 recites “generate, by said a secure enclave data processor of a secure enclave of the trusted execution environment: an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair of the secure enclave, and an attestation data object that envelops the public key and the enclave quote”. The specification fails to describe how the “an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair” are generated by a secure enclave data processor (see, e.g., paragraph [0227], The data custodian is a data process that, in an embodiment, is operated within a secure enclave data processor that conducts automated policy enforcement of data protection policies to periodically or continuously ensure that privacy principles of the secured environment are being adhered to). Accordingly, the claim rejection under 112(a) is maintained.
The same reasons apply to independent claims 11 and 20 and to their independent claims.
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 1-20 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites, “the processor configured to: generate, by a secure enclave, an elliptic-curve Diffie Hellman (ECDH) keypair, an enclave quote which includes a hash of a public key of the ECDH keypair of the secure enclave…”. It is unclear whether the function of generating the keypair, returning the attestation data object, receiving the encrypted data objects, and uploading the encrypted raw data objects are performed by the processor itself or by the secure enclave. Moreover, the specification does not clearly define whether the secure enclave is a separate hardware entity, or a software module executed by the processor. Therefore, a person of ordinary skill in the art would not be able to determine, which component is responsible for executing the recited operations.
The same reasons apply to independent claims 11 and 20 and to their independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 11-12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Costa (US 2018/0212939 A1), hereinafter Costa in view of Wang et al. (US 2021/0097528 A1), hereinafter Wang.
In regards to claim 1, Costa discloses a computer implemented system for interoperating with a trusted execution environment (Costa, Para. 0002), the computer implemented system including one or more processors and coupled computer memory, the memory having a protected memory region that is encrypted such that it is inaccessible to both an operating system and kernel system (Costa, Para. 0003, Enclave systems, such as Microsoft's Virtual Secure Mode (VSM) and Intel's Software Guard Extensions (SGX) provide security in part by isolating an enclave from other code running in either user mode or kernel mode) and (Costa, Para. 0036, Enclave system 100 includes an enclave 176 (alternately called an enclave container or secure execution environment), which includes a secure isolated region of memory that contains code 180 and data 182), the protected memory region including at least a data storage region and a data processing subsystem storage region maintaining a segregated data processing subsystem (Costa, Para. 0036, Enclave system 100 includes an enclave 176 (alternately called an enclave container or secure execution environment), which includes a secure isolated region of memory that contains code 180 and data 182) and (Costa, Para. 0037, protecting the contents of the enclave 176 from untrusted software 174 (e.g., disclosure to untrusted software, modification by untrusted software, or the like) may be a goal) and a secure enclave data processor operating a data custodian data process for automated policy enforcement of one or more data protection policies (Costa, Para. 0175, once permission has been confirmed, the enclave data may be unsealed if it was sealed, and then sent to the destination enclave via a secure channel in box 2014) and (Costa, Para. 0037) and (Costa, Paras. 0020-0026), the one or more processors configured to (Costa, Para. 0002):
generate, by said secure enclave data processor of a secure enclave of the trusted execution environment (Costa, Para. 0041, an enclave, such as enclave 176, may provide an isolated execution environment which may protect code or data, such as code 180 and data 182, by providing a region of memory with restrictions on reading, writing, or executing from that protected region): an elliptic-curve Diffie Hellman (ECDH) keypair (Costa, Fig. 5: Secure enclave container 536),
an enclave quote which includes a hash of a public key of the ECDH keypair of the secure enclave (Costa, Fig. 5, Item. 536, Item. 540 and Para. 0050, Software inside the secure enclave container 536 may use an enclave private key B to compute gB using the same generator function g. Both B and gB may be stored in the enclave container in box 540),
an attestation data object that envelops the public key and the enclave quote (Costa, Para. 0215, attestation of the key vault enclave may include sending, to the vault client, an attestation report or attestation quote of the key vault enclave. The key vault client can then verify the integrity of the attestation report by verifying a signature in the attestation report with a public key associated with the native enclave platform of the key vault enclave) and (Costa, Para. 0213, The public key and the quote can then be distributed to all systems/code that wish to use the key-vault),
transmit the attestation data object to a partner data repository (Costa, Para. 0051, an attestation message 522 is sent to the enclave client 510); generate, by the partner data repository, a symmetric channel key based on the public key of said attestation data object (Costa, Para. 0050, a key exchange process that produces a shared key SK; an attestation process for attestation to enclave client 510 of the enclave on trusted platform 530) and (Costa, Para. 0052, the shared key is produced independently on each side of the communication channel in boxes 540 and 514 without either the enclave client or the enclave knowing the other's private key, it is noted that the shared key corresponds to the symmetric channel key) and (Costa, Para. 0212, he channel may be established using attestation and performing a Diffie-Hellman key exchange as described above with respect to FIGS. 5 and 6. After the communication channel is established, the request is sent securely over the channel and the response is read from the channel. The channel may provide guarantees of confidentiality and integrity of the data exchanged);
receive, from the partner data repository, one or more raw data objects encrypted using the symmetric channel key (Costa, Para. 0052, secret code and data may be securely provided by the enclave client 510 by encrypting the secret code and data with the previously established shared key SK, producing EncSK (secret code/data) before sending it in a message 524 to the trusted platform 530); and
Costa does not explicitly disclose upload the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave, segregating the new protected database elements relative to both an operating system and kernel system: receive a query data object representing a proposed query to be operated on one or more of said protected database elements; apply the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection; upon determining that the query data object adheres to the one or more data protection policies, provide a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process; transmit the attestation token data object to a key manager for attestation token verification; verify, by the key manager, said attestation token data object; release, by the key manager, one or more data protection keys after said verifying; and access the one or more protected database elements using the data protection keys and causing the execution of the proposed query.
However, Wang teaches upload the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave (Wang, Para. 0058, may send the raw blockchain transaction—for example, along with a digital signature—to secure enclave 408), segregating the new protected database elements relative to both an operating system and kernel system (Wang, Fig. 7): receive a query data object representing a proposed query to be operated on one or more of said protected database elements (Wang, Fig. 3, Para. 0049, User 302 may specify a request to execute a blockchain transaction); apply the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0049, Secure enclave 306 may evaluate the transaction semantics against one or more wallet-specific security policies, one or more global security policies, or a combination thereof. A wallet-specific security policy may have a binding that associates it to a specific wallet, whereas a global security policy may be applicable to all wallets within a blockchain network); upon determining that the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0053), provide a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process (Wang, Fig. 3, Para. 0053, If all applicable security policies are satisfied, then secure enclave 306 may use wallet private key to digitally sign the raw blockchain transaction and provide the raw blockchain transaction to hot wallet 304. Hot wallet 304 may broadcast the wallet signature and raw blockchain transaction to any suitable blockchain network such as blockchain 308, and may notify the user of the result and/or status of the broadcasted blockchain transaction); transmit the attestation token data object to a key manager for attestation token verification; verify, by the key manager, said attestation token data object (Wang, Fig. 3, Para. 0038, Secure enclave 106 may check 122 validity of approver signatures using any suitable signature verification routine. For example, the secure enclave 106 may generate a first value using the approval message as an input to a one-way function to generate a first output and generate a second output by decrypting an approver digital signature with the approver's corresponding public key. If the first value and the second value match, the digital signature is considered valid); release, by the key manager, one or more data protection keys after said verifying (Wang, Para. 0040, once a raw blockchain transaction is obtained (e.g., generated or received via enclave entry point)—and in at least some cases, validated—the secure enclave may use 126 the wallet private key to digitally sign the raw blockchain transaction); and access the one or more protected database elements using the data protection keys and causing the execution of the proposed query (Wang, Para. 0040, once a raw blockchain transaction is obtained (e.g., generated or received via enclave entry point)—and in at least some cases, validated—the secure enclave may use 126 the wallet private key to digitally sign the raw blockchain transaction. In at least some embodiments, the digital signature generated over the raw blockchain transaction is an attestation that the hot wallet 104 authorizes the raw blockchain transaction and is used by nodes of the blockchain network 108 to validate that the raw blockchain transaction should be processed).
Costa and Wang are both considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa to incorporate the teachings of Wang to include upload the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave (Wang, Para. 0058), segregating the new protected database elements relative to both an operating system and kernel system (Wang, Fig. 7): receive a query data object representing a proposed query to be operated on one or more of said protected database elements (Wang, Fig. 3, Para. 0049); apply the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0049); upon determining that the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0053), provide a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process (Wang, Fig. 3, Para. 0053); transmit the attestation token data object to a key manager for attestation token verification; verify, by the key manager, said attestation token data object (Wang, Fig. 3, Para. 0038); release, by the key manager, one or more data protection keys after said verifying (Wang, Para. 0040); and access the one or more protected database elements using the data protection keys and causing the execution of the proposed query (Wang, Para. 0040).
Doing so would aid a hot wallet with secure enclave to support global and user-specific policies that enforce a set of conditions on how the hot wallet can be used. In one embodiment, a hot wallet with secure enclave is implemented with network isolation such that a malicious user is physically and/or isolated from the hot wallet, making it difficult or impossible to perform computer-based attacks on the hot wallet (Wang, Para. 0025).
It is noted that the difference is an elliptic-curve Diffie Hellman (ECDH) is used in the instant claim. The problem to be solved by present invention may therefore be regarded as which variant of Diffie Hellman key agreement to use. Utilizing an elliptic-curve is a well-known process and is a technique that is used to accomplish the Diffie Hellman (DH) keypair generation. Accordingly, the recitation of an elliptic-curve Diffie Hellman (ECDH) in claim 1 does not constitute a novel to the stated problem since elliptic-curve Diffie Hellman (ECDH) is a commonly known and wildly used variant.
The same rational applies to a computer implemented method of claim 11 and a non-transitory computer readable medium of claim 20.
In regards to claim 2, Costa in view of Wang teaches the system of claim 1, wherein the partner data repository generates a new ECDH keypair (Costa, Para. 0050, the enclave client computes gA, stored in box 512, from the enclave client's private key A and a generator function g, for example as described below for the Diffe-Hellman key exchange (DKE) protocol of FIG. 6), and
derives the symmetric channel key using a newly generated private key and the public key that was included in the attestation data object from the secure enclave (Costa, Para. 0051, enclave client 510 can then verify attestation message by verifying the attestation signature and the enclave identity. The signature may be verified as in FIG. 3 using a public key corresponding to the attestation key AK. Verifying the signature may provide an integrity guarantee of the enclave identity in the attestation message).
In regards to claim 11, Costa discloses a computer implemented method for interoperating with a trusted execution environment including a secure enclave data processor operating a data custodian data process for automated policy enforcement of one or more data protection policies (Costa, Para. 0175, once permission has been confirmed, the enclave data may be unsealed if it was sealed, and then sent to the destination enclave via a secure channel in box 2014) and (Costa, Para. 0037) and (Costa, Paras. 0020-0026), the method comprising:
generating, by a secure enclave data processor of the trusted execution environment (Costa, Para. 0041, an enclave, such as enclave 176, may provide an isolated execution environment which may protect code or data, such as code 180 and data 182, by providing a region of memory with restrictions on reading, writing, or executing from that protected region);
an elliptic-curve Diffie Hellman (ECDH) keypair (Costa, Fig. 5: Secure enclave container 536), an enclave quote which includes a hash of a public key of the ECDH keypair of the secure enclave (Costa, Fig. 5, and Fig.7), and
an attestation data object that envelops the public key and the enclave quote (Costa, Para. 0215, attestation of the key vault enclave may include sending, to the vault client, an attestation report or attestation quote of the key vault enclave. The key vault client can then verify the integrity of the attestation report by verifying a signature in the attestation report with a public key associated with the native enclave platform of the key vault enclave) and (Costa, Para. 0213, The public key and the quote can then be distributed to all systems/code that wish to use the key-vault),
transmitting the attestation data object to a partner data repository (Costa, Para. 0051, an attestation message 522 is sent to the enclave client 510); generate, by the partner data repository, a symmetric channel key based on the public key of said attestation data object (Costa, Para. 0050, a key exchange process that produces a shared key SK; an attestation process for attestation to enclave client 510 of the enclave on trusted platform 530) and (Costa, Para. 0052, the shared key is produced independently on each side of the communication channel in boxes 540 and 514 without either the enclave client or the enclave knowing the other's private key, it is noted that the shared key corresponds to the symmetric channel key);
receiving, from the partner data repository, one or more raw data objects encrypted using the symmetric channel key (Costa, Para. 0052, secret code and data may be securely provided by the enclave client 510 by encrypting the secret code and data with the previously established shared key SK, producing EncSK (secret code/data) before sending it in a message 524 to the trusted platform 530); and
Costa does not explicitly disclose uploading the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave, segregating the new protected database elements relative to both an operating system and kernel system, receiving a query data object representing a proposed query to be operated on one or more of said protected database elements; applying the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection policies; upon determining that the query data object adheres to the one or more data protection policies, providing a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process; transmitting the attestation token data object to a key manager for attestation token verification; verifying. by the key manager, said attestation token data object; releasing, by the key manager, one or more data protection keys after said verifying; and accessing the one or more protected database elements using the data protection keys and causing the execution of the proposed query .
However, Wang teaches uploading the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave (Wang, Para. 0058, may send the raw blockchain transaction—for example, along with a digital signature—to secure enclave 408),segregating the new protected database elements relative to both an operating system and kernel system (Wang, Fig. 7), receiving a query data object representing a proposed query to be operated on one or more of said protected database elements (Wang, Fig. 3, Para. 0049, User 302 may specify a request to execute a blockchain transaction); applying the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0049, Secure enclave 306 may evaluate the transaction semantics against one or more wallet-specific security policies, one or more global security policies, or a combination thereof. A wallet-specific security policy may have a binding that associates it to a specific wallet, whereas a global security policy may be applicable to all wallets within a blockchain network); upon determining that the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0053), providing a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process (Wang, Fig. 3, Para. 0053, If all applicable security policies are satisfied, then secure enclave 306 may use wallet private key to digitally sign the raw blockchain transaction and provide the raw blockchain transaction to hot wallet 304. Hot wallet 304 may broadcast the wallet signature and raw blockchain transaction to any suitable blockchain network such as blockchain 308, and may notify the user of the result and/or status of the broadcasted blockchain transaction); transmitting the attestation token data object to a key manager for attestation token verification; verifying. by the key manager, said attestation token data object (Wang, Fig. 3, Para. 0038, Secure enclave 106 may check 122 validity of approver signatures using any suitable signature verification routine. For example, the secure enclave 106 may generate a first value using the approval message as an input to a one-way function to generate a first output and generate a second output by decrypting an approver digital signature with the approver's corresponding public key. If the first value and the second value match, the digital signature is considered valid); releasing, by the key manager, one or more data protection keys after said verifying (Wang, Para. 0040, once a raw blockchain transaction is obtained (e.g., generated or received via enclave entry point)—and in at least some cases, validated—the secure enclave may use 126 the wallet private key to digitally sign the raw blockchain transaction); and accessing the one or more protected database elements using the data protection keys and causing the execution of the proposed query (Wang, Para. 0040, once a raw blockchain transaction is obtained (e.g., generated or received via enclave entry point)—and in at least some cases, validated—the secure enclave may use 126 the wallet private key to digitally sign the raw blockchain transaction. In at least some embodiments, the digital signature generated over the raw blockchain transaction is an attestation that the hot wallet 104 authorizes the raw blockchain transaction and is used by nodes of the blockchain network 108 to validate that the raw blockchain transaction should be processed).
Costa and Wang are both considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa to incorporate the teachings of Wang to include uploading the one or more encrypted raw data objects to said secure enclave as one or more new protected database elements that are encrypted using an internal key of said secure enclave (Wang, Para. 0058),segregating the new protected database elements relative to both an operating system and kernel system (Wang, Fig. 7), receiving a query data object representing a proposed query to be operated on one or more of said protected database elements (Wang, Fig. 3, Para. 0049); applying the one or more data protection policies operable on the query data object to determine whether the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0049); upon determining that the query data object adheres to the one or more data protection policies (Wang, Fig. 3, Para. 0053), providing a control message to an attestation process to validate that the data custodian process is operating on the secure enclave data processor and to receive an attestation token data object from the attestation process (Wang, Fig. 3, Para. 0053); transmitting the attestation token data object to a key manager for attestation token verification; verifying. by the key manager, said attestation token data object (Wang, Fig. 3, Para. 0038); releasing, by the key manager, one or more data protection keys after said verifying (Wang, Para. 0040); and accessing the one or more protected database elements using the data protection keys and causing the execution of the proposed query (Wang, Para. 0040). Doing so would aid a hot wallet with secure enclave to support global and user-specific policies that enforce a set of conditions on how the hot wallet can be used. In one embodiment, a hot wallet with secure enclave is implemented with network isolation such that a malicious user is physically and/or isolated from the hot wallet, making it difficult or impossible to perform computer-based attacks on the hot wallet (Wang, Para. 0025).
In regards to claim 12, the claim 12 is similarly analyzed and rejected as system claim 2.
In regards to claim 20, the non-transitory computer readable medium claim 20 is similarly analyzed and rejected as the method claim 11.
Claims 3-6, and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Costa (US 2018/0212939 A1), hereinafter Costa in view of Wang et al. (US 2021/0097528 A1), hereinafter Wang, and further in view of Fahey et al. (US 2015/0156174 A1), hereinafter Fahey.
In regards to claim 3, the combination of Costa in view of Wang fails to teach the system of claim 2, wherein the symmetric channel key is used to encrypt the one or more raw data objects to generate a submission data object for the uploading of the one or more encrypted raw data objects.
However, Fahey teaches wherein the symmetric channel key is used to encrypt the one or more raw data objects to generate a submission data object for the uploading of the one or more encrypted raw data objects (Fahey, Para. 0053, each chunk is encrypted 504 using a symmetric key cryptographic cypher) and (Fahey, Paras. 0063-0064, Once the chunk has been encrypted 610, the process 600 may include submitting 612 an upload for the first chunk to a storage service endpoint which may be a web server of the data storage service configured to process the upload request).
Costa, Wang and Fahey are all considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa and Wang to incorporate the teachings of Fahey to include wherein the symmetric channel key is used to encrypt the one or more raw data objects to generate a submission data object for the uploading of the one or more encrypted raw data objects (Fahey, Para. 0053) and (Fahey, Paras. 0063-0064). Doing so would aid to improve transfer reliability since each transferred data chunk is a separate file transfer. Thus, a failure to transfer a chunk, which may be evidenced by a checksum failing to match, only requires attempting retransmission of the data chunk and not the complete data object. Thus, data transfer is not only faster, but more resilient (Fahey, Para. 0020).
In regards to claim 4, the combination of Costa and Wang in view of Fahey teaches the system of claim 3, wherein the submission data object is segmented into separate portions of which are uploaded one portion at a time (Fahey, Para. 0063, the process 600 may include receiving a response from the request to initiate the multi-part upload), and the secure enclave decrypts each portion using the symmetric channel key and re-encrypts the portion using the second key which can only be released to the secure enclave (Fahey, Para. 0049, the data encryption system 408 may obtain encrypted data objects from the data storage devices 412, may decrypt the encrypted data objects and transmit the decrypted data objects to the download staging system 414…data object may be re-encrypted for transmission over an SSL or other secure connection one or more times during the transmission of the data object to the user that requested the data object. In order to perform various encryption and decryption operations, the data encryption system 408 may operate in accordance with a key storage system 416 which is a system configured to store keys utilized by the data encryption system 408). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa and Wang to incorporate the teachings of Fahey to include wherein the submission data object is segmented into separate portions of which are uploaded one portion at a time (Fahey, Para. 0063) and the secure enclave decrypts each portion using the symmetric channel key and re-encrypts the portion using the second key which can only be released to the secure enclave (Fahey, Para. 0049). Doing so would aid to improve transfer reliability since each transferred data chunk is a separate file transfer. Thus, a failure to transfer a chunk, which may be evidenced by a checksum failing to match, only requires attempting retransmission of the data chunk and not the complete data object. Thus, data transfer is not only faster, but more resilient (Fahey, Para. 0020).
In regards to claim 5, the combination of Costa and Wang in view of Fahey teaches the system of claim 4, wherein the separate portions of the submission data object are decrypted using the symmetric channel key and re-encrypted using the key which can only be released to the secure enclave using a series of separate parallel enclave data processes that load encrypted submission portions in parallel to establish the one or more new protected database elements (Fahey, Para. 0049, it should be noted that once decrypted by the data encryption system 408 transmission of the data object does not necessarily occur with the data object in plaintext form. For example, data object may be re-encrypted for transmission over an SSL or other secure connection one or more times during the transmission of the data object to the user that requested the data object) and (Fahey, Para. 0056, the process 500 includes transmitting 506 the encrypted chunks to a data storage service in parallel. Transmitting 506 the encrypted chunks to the data storage service in parallel may be performed in any suitable manner. For example, in some embodiments a separate upload request is submitted to the data storage service for each of the data chunks).
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa and Wang to incorporate the teachings of Fahey to include wherein the separate portions of the submission data object are decrypted using the symmetric channel key and re-encrypted using the key which can only be released to the secure enclave using a series of separate parallel enclave data processes that load encrypted submission portions in parallel to establish the one or more new protected database elements (Fahey, Para. 0049). Doing so would aid to improve transfer reliability since each transferred data chunk is a separate file transfer. Thus, a failure to transfer a chunk, which may be evidenced by a checksum failing to match, only requires attempting retransmission of the data chunk and not the complete data object. Thus, data transfer is not only faster, but more resilient (Fahey, Para. 0020).
In regards to claim 6, the combination of Costa in view of Wang fails to teach the system of claim 1, further comprising, validating computing permissions associated with a requesting party of the one or more query requests, and upon a successful validation of the computing permissions associated with the requesting party, the processor is configured to load one or more protected database elements into a protected database by decrypting the one or more protected database elements using said Internal key of said keys, execute the one or more query requests on the protected database to generate one or more query results, output the one or more query results, and unload the one or more protected database elements from the protected database.
However, Fahey teaches wherein the processor is further configured to receive one or more query requests (Fahey, Para. 0005, receiving, by an enclave abstraction platform, a first request to use an enclave from an enclave client), and in response to the one or more query requests (Fahey, Para. 0174, Distributed Enclave Unseal may be implemented in abstraction platform 1954, and operate in response to a request from a destination enclave 1952), validate computing permissions associated with a requesting party of the one or more query requests (Fahey, Para. 0178, Once permission has been confirmed, the enclave data may be unsealed if it was sealed, and then sent to the destination enclave via a secure channel in box 2014), and upon a successful validation of the computing permissions associated with the requesting party (Fahey, Para. 0178), the processor is configured to load one or more protected database elements into a protected database by decrypting the one or more protected database elements using keys which can only be released to the secure enclave corresponding to the one or more protected database elements (Fahey, Para. 0174, the DSE may verify an identity of the requesting (destination) enclave such as by attestation, unseal the requested sealed data, and securely send the unsealed data to the requesting enclave), execute the one or more query requests on the protected database to generate one or more query results, output the one or more query results (Fahey, Para. 0222, the received encrypted data is decrypted with the derived key in box 1314, and the resulting decrypted data (in a decrypted data buffer) is sent to the vault client via the secure communications channel in box 2316), and unload the one or more protected database elements from the protected database (Fahey, Para. 0070, enclave memory isolation may prevent reading from, writing to, or executing (jumping into or out of) the enclave's isolated memory).
Costa, Wang and Fahey are all considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa and Wang to incorporate the teachings of Fahey to include wherein the processor is further configured to receive one or more query requests (Fahey, Para. 0005), and in response to the one or more query requests (Fahey, Para. 0174), validate computing permissions associated with a requesting party of the one or more query requests (Fahey, Para. 0178), and upon a successful validation of the computing permissions associated with the requesting party (Fahey, Para. 0178), the processor is configured to load one or more protected database elements into a protected database by decrypting the one or more protected database elements using keys which can only be released to the secure enclave corresponding to the one or more protected database elements (Fahey, Para. 0174), execute the one or more query requests on the protected database to generate one or more query results, output the one or more query results (Fahey, Para. 0222), and unload the one or more protected database elements from the protected database (Fahey, Para. 0070). Doing so would aid to improve transfer reliability since each transferred data chunk is a separate file transfer. Thus, a failure to transfer a chunk, which may be evidenced by a checksum failing to match, only requires attempting retransmission of the data chunk and not the complete data object. Thus, data transfer is not only faster, but more resilient (Fahey, Para. 0020).
In regards to claim 13, the method claim 13 is similarly analyzed and rejected as the system claim 3.
In regards to claim 14, the method claim 14 is similarly analyzed and rejected as the system claim 4.
In regards to claim 15, the method claim 15 is similarly analyzed and rejected as the system claim 5.
In regards to claim 16, the method claim 16 is similarly analyzed and rejected as the system claim 6.
Claims 7-9, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Costa (US 2018/0212939 A1), hereinafter Costa in view of Wang et al. (US 2021/0097528 A1), hereinafter Wang in view of Fahey et al. (US 2015/0156174), hereinafter Fahey further in view of Weinberg et al. (US 2005/0289119 A1), hereinafter Weinberg.
In regards to claim 7, the combination of Costa, Wang and Fahey fails to teach the system of claim 6, wherein the computing permissions associated with the requesting party indicate specific database records or tables of which the requesting party is permitted to access.
However, Weinberg teaches wherein the computing permissions associated with the requesting party indicate specific database records or tables of which the requesting party is permitted to access (Weinberg, Para. 0058, allowing subqueries to access one or more lookup tables to retrieve data records that satisfy a first set of conditions associated with lookup table lookups, given the rule sets associated with the field categories and the field taxonomy) and (Weinberg, Para. 0059, lookup tables are used to lookup data by accessing one or more lookup tables to retrieve data records. The system may traverse one or more lookup table hierarchies to retrieve the appropriate records. Each of the retrieved records contains a unique identifier).
Costa, Wang, Fahey and Weinberg are all considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa, Wang, and Fahey to incorporate the teachings of Weinberg to include wherein the computing permissions associated with the requesting party indicate specific database records or tables of which the requesting party is permitted to access (Weinberg, Para. 0058). Doing so would aid to utilize a flexible framework for organizing data that comprises one or more primary tables, one or more lookup tables, one or more link tables, one or more multi value tables, and one or more variable field value tables (Weinberg, Para. 0015).
In regards to claim 8, the combination of Costa, Wang and Fahey in view of Weinberg teaches the system of claim 7, wherein the specific database records or tables of which the requesting party is permitted to access are derived from two or more different partner data repositories (Weinberg, Para. 0059, lookup tables are used to lookup data by accessing one or more lookup tables to retrieve data records. The system may traverse one or more lookup table hierarchies to retrieve the appropriate records. Each of the retrieved records contains a unique identifier), and the protected database is generated from a combination of part or all of the specific database records or tables of the two or more different partner data repositories (Weinberg, Para. 0028, a qualified link table is constructed using the unique key from the primary tables and the unique key from one or more lookup tables). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa, Wang and Fahey to incorporate the teachings of Weinberg to include wherein the specific database records or tables of which the requesting party is permitted to access are derived from two or more different partner data repositories (Weinberg, Para. 0059), and the protected database is generated from a combination of part or all of the specific database records or tables of the two or more different partner data repositories (Weinberg, Para. 0028). Doing so would aid to utilize a flexible framework for organizing data that comprises one or more primary tables, one or more lookup tables, one or more link tables, one or more multi value tables, and one or more variable field value tables (Weinberg, Para. 0015).
In regards to claim 9, the combination of Costa, Wang and Fahey in view of Weinberg teaches the system of claim 8, wherein the specific database records or tables of the two or more different partner data repositories include at least one of SKU-level transaction data (Weinberg, Para. 0096, a product or some aspects of a product (e.g., a SKU) through the use of qualified lookup tables, single and multi-valued qualifier fields, qualified taxonomy tables, and single and multi-valued category dependent qualifier fields), and web search data combined using a common database primary or foreign key (Weinberg, Para. 0028, the qualified link table contains a set of qualifier fields (also referred to as qualifiers) and association record fields, wherein each of the plurality of association record fields provides an association between at least one record in the primary table and at least one record in the lookup table (e.g., sub-table). For instance, an association record links two or more records from other tables through the use of a key (e.g., a foreign key)). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa, Wang, and Fahey to incorporate the teachings of Weinberg to include wherein the specific database records or tables of the two or more different partner data repositories include at least one of SKU-level transaction data (Weinberg, Para. 0096), and web search data combined using a common database primary or foreign key (Weinberg, Para. 0028). Doing so would aid to utilize a flexible framework for organizing data that comprises one or more primary tables, one or more lookup tables, one or more link tables, one or more multi value tables, and one or more variable field value tables (Weinberg, Para. 0015).
In regards to claim 17, the method claim 17 is similarly analyzed and rejected as the system claim 7.
In regards to claim 18, the method claim 18 is similarly analyzed and rejected as the system claim 8.
In regards to claim 19, the combination of Costa, Wang and Fahey in view of Weinberg teaches the method of claim 18, wherein the specific database records or tables of the two or more different partner data repositories include at least one of SKU-level transaction data (Weinberg, Para. 0096, a product or some aspects of a product (e.g., a SKU) through the use of qualified lookup tables, single and multi-valued qualifier fields, qualified taxonomy tables, and single and multi-valued category dependent qualifier fields), and web search data (Weinberg, Para. 0028, the qualified link table contains a set of qualifier fields (also referred to as qualifiers) and association record fields, wherein each of the plurality of association record fields provides an association between at least one record in the primary table and at least one record in the lookup table (e.g., sub-table). For instance, an association record links two or more records from other tables through the use of a key (e.g., a foreign key)) and (Weinberg, Para. 0071). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa, Wang and Fahey to incorporate the teachings of Weinberg to include wherein the specific database records or tables of the two or more different partner data repositories include at least one of SKU-level transaction data (Weinberg, Para. 0096), and web search data (Weinberg, Para. 0028) and (Weinberg, Para. 0071). Doing so would aid to utilize a flexible framework for organizing data that comprises one or more primary tables, one or more lookup tables, one or more link tables, one or more multi value tables, and one or more variable field value tables (Weinberg, Para. 0015).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Costa (US 2018/0212939 A1), hereinafter Costa in view of Wang et al. (US 2021/0097528 A1), hereinafter Wang in view of Fahey et al. (US 2015/0156174 A1), hereinafter Fahey and further in view of Sheller et al. (US 2019/0042937 A1), hereinafter Sheller.
In regards to claim 10, the system of claim 6, the combination of Costa, Wang and Fahey fails to teach wherein the one or more query requests are generated periodically to provide inputs to optimize or train a machine learning model data architecture, and wherein the machine learning model data architecture is trained using the protected database without exposure of the protected database.
However, Sheller teaches wherein the one or more query requests are generated periodically to provide inputs to optimize or train a machine learning model data architecture (Sheller, Para. 0131, the input scanner is to determine whether the input data included in the query appears to be synthetic based on an amount of similarity between the input data included in the query and training data used to train the neural network), and wherein the machine learning model data architecture is trained using the protected database without exposure of the protected database (Sheller, Para. 0131, an edge device for federated training of a neural network, the edge device comprising throttling means for determining whether to allow a new local data item to be incorporated into a training process of a neural network the edge device, the neural network implemented within a trusted execution environment of the edge device).
Costa, Wang and Fahey and Sheller are all considered to be analogous to the claim invention because they are in the same field of a secure database that is used for computing and cryptographic approaches to store confidential information that can then only be accessed by the authorized party. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Costa, Wang and Fahey to incorporate the teachings of Sheller to include wherein the one or more query requests are generated periodically to provide inputs to optimize or train a machine learning model data architecture (Sheller, Para. 0131), and wherein the machine learning model data architecture is trained using the protected database without exposure of the protected database (Sheller, Para. 0131). Doing so would aid to enables a model representing a neural network to be trained using data across many edge systems without having to centralize the data used for such training. Edge devices perform local training, and provide training results to an aggregator device, which aggregates the training results among the multiple edge devices to update a centralized model, which can then be re-distributed to the edge devices for subsequent training and/or use. Such an approach facilitates many advantages such as, for example, bandwidth conservation (training data is already present at the edge device) and privacy (Sheller, Para. 0131).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
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 GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
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 L. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights