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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/13/2025 has been entered.
Status of Claims
The Amendment filed on February 13, 2025 has been entered. Claims 1, 2, 11, 12, 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 obviates the claim rejection, therefore the claim rejection under 35 USC § 112 (b) is withdrawn.
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 Pages 7-8 of remarks, based on the amendment of the independent claims 1, 11, and 20 “decrypt, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key: re-encrypt said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database”, a new ground(s) of rejection is made in view of ORTIZ et al. ( US 2019/0362083 A1).
The Applicant argues that Whaley does not address “the secure enclave transmits an attestation data object to a partner data repository, and the partner data rep the symmetric channel key based on the attestation data object.”. The claim language does not use the term “transmit” in the independent claim 1. The examiner reminds Applicant that every limitation in the argument in order to be considered and analyzed must be recited in the claim.
In regards to the amended claim limitation “upload the one or more encrypted raw data objects to said secure enclave”, the examiner is relying to ORTIZ “so the partner portal can encrypt raw data using the appropriate public key prior to transmission of encrypted data via communication channel 215. For example, Data Manager 134 can send information representative of an upper limit of data amount to be received by each destination enclave and corresponding public key (e.g. “MaxSize, PublicKeyID”), so partner portal 116 can encrypt the appropriate amount of incoming data for each destination enclave, in a manner that is consistent with the requirements of the destination enclaves”, see paragraph [0143].
Applicant’s argument regarding the cited prior arts and claims 1-20 are conclusory and are not persuasive.
The same reasons apply to dependent claims 2-10, and 12-19 at least virtue of their dependencies. Therefore, the examiner maintains the rejection under 35 USC § 103.
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, and an attestation data object that envelops the public key and the enclave quote, which can be utilized together to determine 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)).
The same reasons apply to dependent claims 11 and 20.
Further, , claim 1 recites “Decrypt, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key; re-encrypt said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements, said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database”. There is nothing in the specification to define one or more encrypted raw data objects corresponds to the data submission package. The specification refers to “The data submission package is encrypted using the session key and transmitted to VCR, and VCR decrypts package using the session key, and re-encrypted with a new data key within an always encrypted database (e.g., a secure SQL database) with secure enclaves. In some embodiments, the VCR platform manages this key as opposed to the data loader application, and the confidential sidecar writes directly to the always encrypted database.”, see paragraph [0297]). Further, nothing is the specification defines one or more new protected database elements and how one or more new protected database elements are obtained.
The same reasons apply to dependent claims 11 and 20.
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…”. 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.
Further, claim 1 recites “said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database”. The key is not used to encrypt and encrypted data base. As recited in claim 1, the second key is used to re-encrypt said one or more decrypted raw data objects. The specification does not provide adequate written-description support for the second key as recited, nor does it clearly describe a mechanism by which the second key can be released only to the secure enclave operating the encrypted database. The disclosure discusses general encryption process that certain data may be re-encrypted within a secure enclave (see, e.g., a shared-symmetric channel key (basically a session key) will be derived known only to the enclave and the client. At this point the client is ready to encrypt data and provide it to VCR as what is defined as a Submission (e.g., as a submission data object). VCR will decrypt it using this shared channel key, and re-encrypt it with a key that was released to the enclave, which is under management of the VCR platform in paragraph [0288]), those portions merely state that data may be “re-encrypt” using a key without describing what is the second key and how said second key is encrypting an encrypted database.
The same reasons apply to dependent claims 11 and 20.
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 ORTIZ et al. ( US 2019/0362083 A1), hereinafter Ortiz.
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 a processor and coupled computer memory, the processor configured to (Costa, Para. 0002):
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),
return 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 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);
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 generate, by a secure enclave, Diffie Hellman ((Costa, Fig. 5: Secure enclave container 536),
an enclave quote which includes a hash of a public key of the (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),
Costa does not explicitly teach upload the one or more encrypted raw data objects to said secure enclave; Decrypt, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key; re-encrypt said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements, said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database.
However, Ortiz teaches upload the one or more encrypted raw data objects to said secure enclave (Ortiz, Para. 0143, so the partner portal can encrypt raw data using the appropriate public key prior to transmission of encrypted data via communication channel 215. For example, Data Manager 134 can send information representative of an upper limit of data amount to be received by each destination enclave and corresponding public key (e.g. “MaxSize, PublicKeyID”), so partner portal 116 can encrypt the appropriate amount of incoming data for each destination enclave, in a manner that is consistent with the requirements of the destination enclaves); Decrypt, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key (Ortiz, Para. 0086, The user data can only be decrypted and processed in Secure Enclaves 133) and (Ortiz, Para. 0088, a secure enclave 133 can provide secure storage of sensitive data from partner systems 133, and is the only component on platform 100 capable of decrypting the encrypted data with an appropriate and secure key management system); re-encrypt said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements (Ortiz, Para. 0086, data output generated by processes within Secure Enclaves 133 are then encrypted and stored within the secure data warehouse 108) and (Para. 0194, “Storage Key” may be used to encrypt and secure data stored on local storage. Storage Keys may be stored in permanent storage using the enclave's seal key), said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database (Ortiz, Para. 0092, Enclave data on DRAM is encrypted and is only decrypted when loaded into cache using special instructions, so the enclave data are protected from administrators, OS/kernel system/processes and outside entities. Access to the decryption keys are restricted and, in some embodiments, are only available within the secure enclaves 133 without accessibility by a human analyst) and (Ortiz, Para. 0093).
Costa and Ortiz 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 Ortiz to include upload the one or more encrypted raw data objects to said secure enclave (Ortiz, Para. 0143); Decrypt, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key (Ortiz, Para. 0086) and (Ortiz, Para. 0088); re-encrypt said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements (Ortiz, Para. 0086), said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database (Ortiz, Para. 0092). Doing so would aid technical solutions adapted to overcome technical challenges associated with improved privacy and security. In particular, systems, methods, and computer readable media are described that utilize secure processing technologies, such as secure enclaves, in relation to the operation of an improved machine learning data architecture that has enhanced privacy and security measures (Ortiz, Para. 0070).
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 ORTIZ 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, the method comprising:
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),
returning 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 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 generating, by a secure enclave, an (Costa, Fig. 5: Secure enclave container 536),
an enclave quote which includes a hash of a public key of the (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),
Costa does not explicitly disclose uploading the one or more encrypted raw data objects to said secure enclave; decrypting, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key; re-encrypting said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements, said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database, segregating the new protected database elements relative to both an operating system and kernel system, wherein the operating system and the kernel system are unable to access the second key and cannot access secure blocks of memory corresponding to the secure enclave.
However, Ortiz teaches uploading the one or more encrypted raw data objects to said secure enclave (Ortiz, Para. 0143, so the partner portal can encrypt raw data using the appropriate public key prior to transmission of encrypted data via communication channel 215. For example, Data Manager 134 can send information representative of an upper limit of data amount to be received by each destination enclave and corresponding public key (e.g. “MaxSize, PublicKeyID”), so partner portal 116 can encrypt the appropriate amount of incoming data for each destination enclave, in a manner that is consistent with the requirements of the destination enclaves); decrypting, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key (Ortiz, Para. 0086, The user data can only be decrypted and processed in Secure Enclaves 133) and (Ortiz, Para. 0088, a secure enclave 133 can provide secure storage of sensitive data from partner systems 133, and is the only component on platform 100 capable of decrypting the encrypted data with an appropriate and secure key management system); re-encrypting said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements (Ortiz, Para. 0086, data output generated by processes within Secure Enclaves 133 are then encrypted and stored within the secure data warehouse 108) and (Para. 0194, “Storage Key” may be used to encrypt and secure data stored on local storage. Storage Keys may be stored in permanent storage using the enclave's seal key), said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database (Ortiz, Para. 0092, Enclave data on DRAM is encrypted and is only decrypted when loaded into cache using special instructions, so the enclave data are protected from administrators, OS/kernel system/processes and outside entities. Access to the decryption keys are restricted and, in some embodiments, are only available within the secure enclaves 133 without accessibility by a human analyst) and (Ortiz, Para. 0093), segregating the new protected database elements relative to both an operating system and kernel system (Ortiz, Para. 0074, the protected memory region of the TEE 103 (e.g., secure data warehouse 108) is isolated through the use of encryption. In this example, the encryption keys are stored within the TEE 103 itself so that it can access data as required but the underlying data is not accessible by other components, such as an operating system operating on the server or a kernel process), wherein the operating system and the kernel system are unable to access the second key and cannot access secure blocks of memory corresponding to the secure enclave(Ortiz, Para. 0074, the protected memory region of the TEE 103 (e.g., secure data warehouse 108) is isolated through the use of encryption. In this example, the encryption keys are stored within the TEE 103 itself so that it can access data as required but the underlying data is not accessible by other components, such as an operating system operating on the server or a kernel process).
Costa and Ortiz 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 Ortiz to include uploading the one or more encrypted raw data objects to said secure enclave (Ortiz, Para. 0143); decrypting, by said secure enclave, said one or more encrypted raw data objects using said symmetric channel key (Ortiz, Para. 0086) and (Ortiz, Para. 0088); re-encrypting said one or more decrypted raw data objects using a second key to obtain one or more new protected database elements (Ortiz, Para. 0086), said second key for encrypting an encrypted database which can only be released to the secure enclave operating the encrypted database (Ortiz, Para. 0092) and (Ortiz, Para. 0093), segregating the new protected database elements relative to both an operating system and kernel system (Ortiz, Para. 0074), wherein the operating system and the kernel system are unable to access the second key and cannot access secure blocks of memory corresponding to the secure enclave(Ortiz, Para. 0074). Doing so would aid technical solutions adapted to overcome technical challenges associated with improved privacy and security. In particular, systems, methods, and computer readable media are described that utilize secure processing technologies, such as secure enclaves, in relation to the operation of an improved machine learning data architecture that has enhanced privacy and security measures (Ortiz, Para. 0070).
In regards to claim 12, the method 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 ORTIZ et al. ( US 2019/0362083 A1), hereinafter Ortiz, 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 ORTIZ 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, ORTIZ 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 ORTIZ 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 ORTIZ 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 (Ortiz, Para. 0086, The user data can only be decrypted and processed in Secure Enclaves 133) and (Ortiz, Para. 0088, a secure enclave 133 can provide secure storage of sensitive data from partner systems 133, and is the only component on platform 100 capable of decrypting the encrypted data with an appropriate and secure key management system), (Ortiz, Para. 0086, data output generated by processes within Secure Enclaves 133 are then encrypted and stored within the secure data warehouse 108) and (Para. 0194, “Storage Key” may be used to encrypt and secure data stored on local storage. Storage Keys may be stored in permanent storage using the enclave's seal 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 and ORTIZ 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). 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 ORTIZ 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 ORTIZ 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 ORTIZ fails to teach the system of claim 1, wherein the processor is further configured to receive one or more query requests, and in response to the one or more query requests, validate 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 keys which can only be released to the secure enclave corresponding to the one or more protected database elements, 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, ORTIZ 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 ORTIZ 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 ORTIZ et al. ( US 2019/0362083 A1), hereinafter Ortiz 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, Ortiz 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, ORTIZ, 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, ORTIZ, 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, ORTIZ 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, Ortiz 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, Ortiz 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, Ortiz, 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, Ortiz, 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, Ortiz 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 ORTIZ et al. ( US 2019/0362083 A1), hereinafter Ortiz 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, ORTIZ 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, ORTIZ 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, ORTIZ 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
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