DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 02/28/2025. Claims 1-20 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/907,060.
Double Patenting
With regard to the rejection of Claims 1, 19, and 20 on the basis of non-statutory anticipatory Double Patenting over Application No.US11799633 (17/486457), Examiner will maintain the Double Patenting rejection is held in obeyance per applicant request until the issue becomes ripe.
RESPONSE to 35 USC 101 rejections
Applicant’s arguments see pages 6-7 of remarks, filed 05/26/2026, with respect to claims 1-8, and 11-22 rejection under U.S.C. 101, have been fully considered, however, they are not persuasive. Applicant amendment to claim is not sufficient to amount to significantly more than the judicial exception because the limitations are merely triple encrypting a data stored in the tenant database with encryption key, wrapper key and top-level-key. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. The mechanisms used are generic computing operations that do not enhance the functionality of the computer. Further, the claim does not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. The additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. So, the amendment limitations are not tied to a particular, special-purpose machine nor does it improve the functionality of the machine. A generic computer used to implement an abstract idea does not render the claim to significantly more that the abstract idea. The examiner suggest that additional limitations are necessary to recite a practical application using the determined clusters in a real-world.
Examiner maintains the 35 USC 101 abstract rejection for claims 1-8, and 11-22.
Examiner Note
Applicant’s amendment to independent claims obviates previously raised claims 1, 19, and 20 , 35 USC 112(b) , second paragraph rejection for phrases “the tenant database”, and “the instruction”.
Applicant’s arguments with respect to independent claims for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words. The form and legal phraseology often used in patent claims, being “comprise”, "means" and "said," should be avoided. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure describes," etc.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
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.).
Claims 1, 19, recite the limitation "determine a wrapper key used in connection with encrypting the key associated with the request to access data”, and “determine a top-level key used in connection with encrypting the wrapper key” , which renders the claim indefinite , because it is unclear what does it mean “used in connection”? does it mean the wrapper key and top-level key are used for encryption? Or they are somehow linked to the encryption process?
Claims 2-8, 11-18 , and 21-22 do not cure the deficiency of claims 1 and 19 are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claims 1, and 19.
Claim 20 recite the limitation "determine a wrapper key used in connection with encrypting the key associated with the request to access data”, which renders the claim indefinite , because it is unclear what does it mean “used in connection”? does it mean the wrapper key is used for encryption? Or the wrapper key somehow linked to the encryption process?
Frist Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-7, and 11-22 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by being anticipated by Hamel et al (US2018/0060600) , hereinafter, Hamel”(filed in IDS 01/10/2025).
Regarding claim 1, 19, and 20 , Hamel discloses one or more processors configured to: receive a request to access data stored within a tenant database, wherein the data is encrypted based at least in part on a key corresponding to the tenant database
[0039, the request response indicates to the user that the requested access to the secure data storage has been granted and that a version of the encryption key needed to access the secure data is available for retrieval.
determine that the key is associated with the request to access the data
[0039, the request response indicates to the user that the requested access to the secure data storage has been granted and that a version of the encryption key needed to access the secure data is available for retrieval.
determine a wrapper keys used in connection with encrypting the key associated with the request to access the data, based at least in part on metadata stored in association with the key
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
[0035] In some embodiments, the request object includes metadata identifying the requested tenant service key. Using the request object, an encrypted tenant service key and an encrypted tenant master key are retrieved. In some embodiments, the encrypted keys are stored in an encrypted key database.
wherein an encrypted version of the wrapper key is stored in a key management service
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
[0027] A system for secure storage of data is disclosed. The system comprises a key database and a processor. The processor is configured to receive a request associated with securely storing data and encrypt a tenant service key using a tenant master key. The data is encrypted using the tenant service key. The processor is further configured to encrypt the tenant master key using a customer key and store encrypted tenant service key and encrypted tenant master key in the key database
[ see FIG.2 and corresponding text for key management system 204, [0042, Encrypted Key DB 226 is a database that comprises encrypted keys used to access secure databases. In some embodiments, Encrypted Key DB 226 comprises encrypted tenant master key (Encrypted TMK) 227 and encrypted tenant service key (Encrypted TSK) 228 ].
determine a top-level key used in connection with encrypting the wrapper key:
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key).
obtain the data stored within the tenant database based at least in part on the key, the wrapper key and the top-level key and provide the data in response to the request to access the data
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
and a memory coupled to a processor of the one or more processors and configured to provide the instructions to the processor.
[0025, The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor.].
Regarding claim 2, Hamel discloses, wherein one or more keys are used to decrypt the data associated with the request.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 3, Hamel discloses, wherein the system performs a lookup to determine a wrapper associated with the key.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 4, Hamel discloses, wherein the lookup determines an identifier of the wrapper key.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 5, Hamel discloses, wherein the wrapper key comprises a wrapper key of a tenant service encryption key.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 6, Hamel discloses, wherein the wrapper key of the tenant service encryption key comprises a tenant key encryption key.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 7, Hamel discloses, wherein the wrapper key of the tenant service encryption key comprises a customer wrapper key.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claims 11, and 21, Hamel discloses wherein the top-level key is stored in a third-party key management service.
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
[0027] A system for secure storage of data is disclosed. The system comprises a key database and a processor. The processor is configured to receive a request associated with securely storing data and encrypt a tenant service key using a tenant master key. The data is encrypted using the tenant service key. The processor is further configured to encrypt the tenant master key using a customer key and store encrypted tenant service key and encrypted tenant master key in the key database
[ see FIG.2 and corresponding text for key management system 204, [0042, Encrypted Key DB 226 is a database that comprises encrypted keys used to access secure databases. In some embodiments, Encrypted Key DB 226 comprises encrypted tenant master key (Encrypted TMK) 227 and encrypted tenant service key (Encrypted TSK) 228 ].
Regarding claim 12, Hamel discloses, wherein the third-party key management service is determined along with an account identifier.
[0050, In some embodiments, the customer key is stored in a hardware security module. In some embodiments, the hardware security module is located remotely from the key database in a KRS system. In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation], and , and [0059].
Regarding claim 13, Hamel discloses, wherein the third-party key management service is determined along with a hardware security module.
[ see FIG. 2A, and corresponding text for more details, HSM (206), key management system (20)].
Regarding claim 14, Hamel discloses, wherein the third-party key management service manages the top-level key and is managed by a customer of the third-party key management service.
[ see FIG. 2A and corresponding text for more details].
Regarding claim 15, Hamel discloses, wherein the customer configures the system to use the top-level key provided by the third-party key management service
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 16, Hamel discloses, wherein the customer configures permissions for access to the top-level key managed by the customer.
This claim in not mapped because it depends on claim 15 which examiner has not chosen the customer option.
Regarding claim 17, Hamel discloses, wherein the system uses an identifier of the top-level key to look up location information of the top-level key comprising an identifier of the third-party key management service.
[ see FIG. 2A and corresponding text for more details], and
[0050, In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation], , and [0059].
Regarding claim 18, Hamel discloses, wherein the system uses an identifier of the top-level key to look up location information of the top-level key comprising account information at which the top-level key is stored.
[ see FIG. 2A and corresponding text for more details], and
[0050, In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation.], and [0059].
Regarding claim 22, Hamel discloses comprising determining the third-party key management service along with at least one of an account identifier or a hardware security module.
[ see FIG. 2A and corresponding text for more details], and
[0050, In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation.], and [0059].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. Hamel et al (US2018/0060600) , hereinafter, Hamel” (filed in IDS 01/10/2025), and in view of US Patent No. US2022/0385464 issued to Anand ( filed in IDS 01/10/2025).
Regarding claim 8, Hamel does not explicitly disclose, however, Anand discloses wherein the wrapper key of the tenant service encryption key comprises a Bring-your-own-key Tenant Wrapper Key as:
[¶2, A key management system (KMS) is a system configured to manage cryptographic keys in a cryptosystem. A KMS is generally configured to generate, rotate, store, use, destroy, and replace cryptographic keys. A data object in Object Storage, in a database, or in any other data store either in a cloud or on premise, is often encrypted at a first level with a data encryption key (e.g., DEK). In some secure data systems, a service or application that has the data object stored in encrypted form utilizes a KMS to store first level encryption keys (e.g., a data encryption key (DEK)) securely. In this type of secure data environment, the data object and the encryption keys are not stored together. In some secure data systems, a cloud service or application leverage a KMS's bring your own key (BYOK) feature, which enables a data owner to utilize their own second level keys (e.g., root of trust) to encrypt a first level encryption key and store the encrypted first level encryption key in their data storage service or application…], and [¶13].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hamel by incorporating “bring your own key (BYOK)”, as taught by Anand. One could have been motivated to do so in order provide the ability for a KMS to successfully obtain and utilize a second level key (e.g., a user-elected bring your own key (BYOK) cryptographic key) over time, despite any local or regional service or hardware outages, is referred to herein as the durability of the cryptographic key. [ Anand, ¶¶2, 13].
Second Set of Rejections:
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, and 11-22and are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al., (US2019/0173674) A1) hereinafter referred to as Agarwal( Filed in IDS 01/10/2025) and in view of Hamel et al (US2018/0060600) , hereinafter, Hamel” (filed in IDS 01/10/2025).
Regarding claims 1, 19, and 20, Agarwal discloses one or more processors configured to: receive a request to access data stored within a tenant database, wherein the data is encrypted based at least in part on a key corresponding to the tenant database
[¶35, When a tenant attempts to access encrypted data, e.g., stored credentials, passwords, etc., the tenant may issue requests to a service or process to obtain the tenant's TEK, so as to enable access to the data]; and
determine that the key is associated with the request to access the data
[¶35, When a tenant attempts to access encrypted data, e.g., stored credentials, passwords, etc., the tenant may issue requests to a service or process to obtain the tenant's TEK, so as to enable access to the data]; and
determine a wrapper keys used in connection with encrypting the key associated with the request to access the data, based at least in part on metadata stored in association with the key
[¶¶35-36, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK) (equated to wrapper key). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application. Note that while the DEKs or TEKs discussed herein are called data encryption keys, they may also act as KEKs, without departing from the scope of the present teachings. For example, a given DEK may encode various tenant credentials, software access tokens, and so on, associated with the tenant. Nevertheless, the terms DEK or TEK are used herein to facilitate distinguishing between keys used to encode tenant-related data and/or credentials, tokens, other keys, etc., from a master KEK used to encode the TEKs or DEKs for various tenants].
wherein an encrypted version of the wrapper key is stored in a key management service
[¶75, Note that the illustrated second example system 160 differs from the first example system 100 of FIG. 1 in various ways. For example, with reference to FIGS. 1 and 2, functionality provided by the KEK decrypter 122, KEK Encrypter 124, and KEK rotation scheduler 130 of FIG. 1 are incorporated into the Key Management (KM) controller 128 of FIG. 2. Furthermore, functionality of the tenant request processing module 120 of FIG. 1 may be incorporated into the tenant Key Management (KM) Application Programming Interface (API) 176 of FIG. 2. In addition, the KM administration interfacing APIs 178 shown in FIG. 2 may be implemented within the controller 118 of FIG. 1.], and ¶¶116, 120].
and a memory coupled to a processor of the one or more processors and configured to provide the instructions to the processor.
[¶21, For the purposes of the present discussion, a computing environment may be any collection of computing resources used to perform one or more tasks involving computer processing. A computer may be any processor in communication with a memory].
Agarwal does not explicitly disclose; however, Hamel discloses:
determine a top-level key used in connection with encrypting the wrapper key
[¶30, In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key)]; and
obtain the data stored within the tenant database based at least in part on the key, the wrapper key and the top-level key and provide the data in response to the request to access the data
[¶30, In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Agarwal by incorporating “ multiple keys”, as taught by Hamel. One could have been motivated to do so in order for the system stores data in a repository in a secure manner by encrypting the data using multiple keys. [ Hamel, 0030].
Regarding claim 2, Agarwal discloses wherein one or more keys are used to decrypt the data associated with the request [ ¶35, When a tenant attempts to access encrypted data, e.g., stored credentials, passwords, etc., the tenant may issue requests to a service or process to obtain the tenant's TEK, so as to enable access to the data. The tenant and/or associated computing resources may use the TEK to decrypt and access their data].
Regarding claim 3, Agarwal discloses wherein the system performs a lookup to determine a wrapper associated with the key [¶35, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application].
Regarding claim 4, Agarwal discloses, wherein the lookup determines an identifier of the wrapper key [¶35, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application].
Regarding claim 5, Agarwal discloses, wherein the wrapper key comprises a wrapper key of a tenant service encryption key [¶35, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application].
Regarding claim 6, Agarwal discloses, wherein the wrapper key of the tenant service encryption key comprises a tenant key encryption key [¶35, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application], and [0036] Note that while the DEKs or TEKs discussed herein are called data encryption keys, they may also act as KEKs, without departing from the scope of the present teachings. For example, a given DEK may encode various tenant credentials, software access tokens, and so on, associated with the tenant. Nevertheless, the terms DEK or TEK are used herein to facilitate distinguishing between keys used to encode tenant-related data and/or credentials, tokens, other keys, etc., from a master KEK used to encode the TEKs or DEKs for various tenants].
Regarding claim 7, Agarwal discloses, wherein the wrapper key of the tenant service encryption key comprises a customer wrapper key [¶35, Similarly, a key that is used to encrypt other keys is called a Key Encryption Key (KEK). In various embodiments discussed herein, a KEK is used to encode TEKs (also called Data Encryption Keys (DEKs) herein) for tenants of a multi-tenant software application], and [0036] Note that while the DEKs or TEKs discussed herein are called data encryption keys, they may also act as KEKs, without departing from the scope of the present teachings. For example, a given DEK may encode various tenant credentials, software access tokens, and so on, associated with the tenant. Nevertheless, the terms DEK or TEK are used herein to facilitate distinguishing between keys used to encode tenant-related data and/or credentials, tokens, other keys, etc., from a master KEK used to encode the TEKs or DEKs for various tenants].
Regarding claims 11, and 21 , Agarwal does not explicitly disclose, however Hamel discloses , wherein the top-level key is stored in a third-party key management service
[0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
[0027] A system for secure storage of data is disclosed. The system comprises a key database and a processor. The processor is configured to receive a request associated with securely storing data and encrypt a tenant service key using a tenant master key. The data is encrypted using the tenant service key. The processor is further configured to encrypt the tenant master key using a customer key and store encrypted tenant service key and encrypted tenant master key in the key database
[ see FIG.2 and corresponding text for key management system 204, [0042, Encrypted Key DB 226 is a database that comprises encrypted keys used to access secure databases. In some embodiments, Encrypted Key DB 226 comprises encrypted tenant master key (Encrypted TMK) 227 and encrypted tenant service key (Encrypted TSK) 228 ].
Regarding claim 12, Agarwal discloses, wherein the third-party key management service is determined along with an account identifier [¶116, An initial signal-receiving step 282 includes receiving a signal to initiate KEK rotation, i.e., the changing of a preexisting KEK (KEK 0) to a new KEK (KEK 1). With reference to FIG. 2, this signal may originate from the administrator client 168 and be routed through the administrator Key Management (KM) API 178 to the KM system 192, which receives the signal to begin KEK rotation. Similarly, in FIG. 1, this signal may originate from the administrator system 116 and/or the KEK rotation scheduler 130, where it is then received by the controller 118 of the KEK rotation system 110].
Regarding claim 13, Agarwal discloses, wherein the third-party key management service is determined along with a hardware security module[¶116, An initial signal-receiving step 282 includes receiving a signal to initiate KEK rotation, i.e., the changing of a preexisting KEK (KEK 0) to a new KEK (KEK 1). With reference to FIG. 2, this signal may originate from the administrator client 168 and be routed through the administrator Key Management (KM) API 178 to the KM system 192, which receives the signal to begin KEK rotation. Similarly, in FIG. 1, this signal may originate from the administrator system 116 and/or the KEK rotation scheduler 130, where it is then received by the controller 118 of the KEK rotation system 110].
Regarding claim 14, While Agarwal discloses, wherein the third-party key management service manages the top-level key and is managed by a customer of the third-party key management service[¶116, An initial signal-receiving step 282 includes receiving a signal to initiate KEK rotation, i.e., the changing of a preexisting KEK (KEK 0) to a new KEK (KEK 1). With reference to FIG. 2, this signal may originate from the administrator client 168 and be routed through the administrator Key Management (KM) API 178 to the KM system 192, which receives the signal to begin KEK rotation. Similarly, in FIG. 1, this signal may originate from the administrator system 116 and/or the KEK rotation scheduler 130, where it is then received by the controller 118 of the KEK rotation system 110].
Agarwal does not explicitly disclose, and Hamel discloses the limitation above as: [ see FIG. 2A and corresponding text for more details].
Regarding claim 15, Agarwal does not explicitly disclose, however, Hamel discloses wherein the customer configures the system to use the top- level key provided by the third-party key management service or by
0030] In some embodiments, the system stores data in a repository in a secure manner by encrypting the data using multiple keys. The repository data is encrypted using a tenant service key. The tenant service key is then encrypted using a tenant master key ( equated to wrapper key). The tenant master key is encrypted using a customer key ( equated to top-level key). The encrypted tenant service key and encrypted tenant master key are stored in a key repository. The customer key is stored in a remote hardware security module. Decrypting the secure repository data requires decrypting the encrypted tenant master key with the customer key, decrypting the encrypted tenant service key with the tenant master key, and finally decrypting the secure data with the tenant service key.
Regarding claim 16, wherein the customer configures permissions for access to the top-level key managed by the customer
This claim in not mapped because it depends on claim 15 which examiner has not chosen the customer option.
Regarding claim 17, Agarwal does not explicitly disclose, however, Hamel discloses, wherein the system uses an identifier of the top-level key to look up location information of the top-level key comprising an identifier of the third-party key management service.
[ see FIG. 2A and corresponding text for more details], and
[0050, In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation], , and [0059].
Regarding claim 18, Agarwal does not explicitly disclose, however, Hamel discloses, wherein the system uses an identifier of the top-level key to look up location information of the top-level key comprising account information at which the top-level key is stored
[ see FIG. 2A and corresponding text for more details], and
[0050, In some embodiments, the customer key location or identifier is logged in an audit database associated with the stored encrypted data storage location. In some embodiments, the tenant master key, the tenant service key, and the customer key or their identifiers are logged as well as their locations. Symmetric encryption keys are generated inside the customer HSM 236, possibly prior to the secure data storage request, tenant master keys or tenant service keys generation. Keys are assigned identifiers that are stored in both the customer HSM 236 and the encrypted key DB 226. The Customer encryption keys never leave the customer HSM, but the identifiers are passed along with requests to indicate which key shall be used in performing an encrypt or decrypt operation], , and [0059]
Regarding claim 22, Agarwal discloses comprising determining the third-party key management service along with at least one of an account identifier or a hardware security module.
[¶116, An initial signal-receiving step 282 includes receiving a signal to initiate KEK rotation, i.e., the changing of a preexisting KEK (KEK 0) to a new KEK (KEK 1). With reference to FIG. 2, this signal may originate from the administrator client 168 and be routed through the administrator Key Management (KM) API 178 to the KM system 192, which receives the signal to begin KEK rotation. Similarly, in FIG. 1, this signal may originate from the administrator system 116 and/or the KEK rotation scheduler 130, where it is then received by the controller 118 of the KEK rotation system 110].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2019/0173674 A1) issued to Agarwal (filed in IDS 01/10/2025), and in view of Hamel et al (US2018/0060600) , hereinafter, Hamel”. and further in view of US Patent No. US2022/0385464 issued to Anand ( filed in IDS 01/10/2025).
Regarding claim 8, While Agarwal discloses wherein the wrapper key of the tenant service encryption key comprises a Bring-your-own-key Tenant Wrapper Key as: [¶10, The one or more second encryption keys include one or more Data Encryption Keys (DEKs), also called Tenant Encryption Keys (TEKs) herein. The one or more DEKs are usable to encrypt data associated with one or more respective tenants, which may include, for example, customers of a cloud service. The one or more tenants may further include computing resources of the cloud service(s) that are allocated to different tenants. The data may include, for example, tokens, credentials, and other data used by one or more computing resources allocated for use by the one or more respective tenants], and [¶34, A key that is used to encrypt data, e.g., data for a particular tenant (i.e., tenant data), is called a Data Encryption Key (DEK), or alternatively, a Tenant Encryption Key (TEK) herein].
Agarwal , and Hamel do not explicitly disclose , and Anand discloses [¶2, A key management system (KMS) is a system configured to manage cryptographic keys in a cryptosystem. A KMS is generally configured to generate, rotate, store, use, destroy, and replace cryptographic keys. A data object in Object Storage, in a database, or in any other data store either in a cloud or on premise, is often encrypted at a first level with a data encryption key (e.g., DEK). In some secure data systems, a service or application that has the data object stored in encrypted form utilizes a KMS to store first level encryption keys (e.g., a data encryption key (DEK)) securely. In this type of secure data environment, the data object and the encryption keys are not stored together. In some secure data systems, a cloud service or application leverage a KMS's bring your own key (BYOK) feature, which enables a data owner to utilize their own second level keys (e.g., root of trust) to encrypt a first level encryption key and store the encrypted first level encryption key in their data storage service or application…], and [¶13].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Agarwal, and Hamel by incorporating “bring your own key (BYOK)”, as taught by Anand. One could have been motivated to do so in order provide the ability for a KMS to successfully obtain and utilize a second level key (e.g., a user-elected bring your own key (BYOK) cryptographic key) over time, despite any local or regional service or hardware outages, is referred to herein as the durability of the cryptographic key. [ Anand, ¶¶2, 13].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See 892 for more relevant references.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights