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
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1, 19, and 20 of instant Application number 18907060 are non- provisionally rejected on the ground of non- statutory anticipatory double patenting as being unpatentable over Claims 1, 19, and 20 of patented Application number 11799633 . Although the conflicting claims are not identical, they are not patentably distinct from each other as explained in the table below. As shown hereafter through a claim-by-claim comparison of the independent claims of the two applications, with the differing subject matter emboldened for emphasis
There is a comparison table in which the instant application is compared with an applications filed by the same inventors: 11799633. The bolded limitations are common in both applications.
Double Patenting
Instant Application
Patent No. 11799633
Claim 1:
A system, comprising:
One or more processors configured to:
receive a request to access data;
determine a key associated with the request to access data;
determine a wrapper key used in connection with encrypting the key associated with the request to access data;
obtain the data stored within the tenant database; and provide the data in response to the request to access the data; and a memory coupled to a processor of the one or more processors and configured to provide the instructions to the processor
19. (New) A method, comprising:receiving a request to access data;determining, using one or more processors, a key associated with the request to access data;determining a wrapper key used in connection with encrypting the key associated with the request to access data;obtaining the data stored within the tenant database; andproviding the data in response to the request to access the data.
20. (New) A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for:receiving a request to access data;determining, using one or more processors, a key associated with the request to access data;determining a wrapper key used in connection with encrypting the key associated with the request to access data;obtaining the data stored within the tenant database; andproviding the data in response to the request to access the data
Claim 1:
A system, comprising:
one or more processors configured to:
receive a request to access data stored within a tenant database associated with a tenant, wherein the data is encrypted based at least in part on a tenant service encryption key (TSEK) corresponding to the tenant database;
determine a wrapper key used in connection with encrypting the TSEK based at least in part on a TSEK metadata stored in association with the TSEK, comprising determining a tenant key encryption key (TKEK) based at least in part on a mapping of TKEKs to keys used to encrypt the TSEKs, wherein: an encrypted version of the TKEK is stored in the tenant database; the tenant is associated with an entity; the wrapper key is associated with the entity; the wrapper key is determined based at least in part on a TKEK metadata stored in association with the TKEK; the TSEK metadata is stored in the tenant database; and an encrypted version of the wrapper key is stored in a key management service (KMS) that is in communication with the tenant database; determine a top-level key used in connection with encrypting the wrapper key based at least in part on wrapper key metadata stored in association with the encrypted version of the wrapper key; obtain the data stored within the tenant database, comprising decrypting at least part of the data based at least in part on (i) the TSEK, (ii) the wrapper key, and (iii) the top-level key; and provide the data in response to the request; and a memory coupled to the one or more processors and configured to provide the one or more processors with instructions.
19. (Previously Presented) A method, comprising:receiving a request to access data stored within a tenant database associated with a tenant, wherein the data is encrypted based at least in part on a tenant service encryption key (TSEK) corresponding to the tenant database; determining a wrapper key used in connection with encrypting the TSEK based at least in part on a TSEK metadata stored in association with the TSEK, comprising determining a tenant key encryption key (TKEK) based at least in part on a mapping of TKEKs to keys used to encrypt the TSEKs, wherein:an encrypted version of the TKEK is stored in the tenant database; the tenant is associated with an entity; the wrapper key is associated with the entity; the wrapper key is determined based at least in part on a TKEK metadata stored in association with the TKEK; the TSEK metadata is stored in the tenant database; and an encrypted version of the wrapper key is stored in a key management service (KMS) that is in communication with the tenant database; determining a top-level key used in connection with encrypting the wrapper key based at least in part on wrapper key metadata stored in association with the encrypted version of the wrapper key; obtaining the data stored within the tenant database, comprising decrypting at least part of the data based at least in part on (i) the TSEK, (ii) the wrapper key, and (iii) the top-level key; and providing the data in response to the request.
20. (Previously Presented) A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for:receiving a request to access data stored within a tenant database associated with a tenant, wherein the data is encrypted based at least in part on a tenant service encryption key (TSEK) corresponding to the tenant database; determining a wrapper key used in connection with encrypting the TSEK based at least in part on a TSEK metadata stored in association with the TSEK,, comprising determining a tenant key encryption key (TKEK) based at least in part on a mapping of TKEKs to keys used to encrypt the TSEKs, wherein:an encrypted version of the TKEK is stored in the tenant database; the tenant is associated with an entity; the wrapper key is associated with the entity; the wrapper key is determined based at least in part on a TKEK metadata stored in association with the TKEK; the TSEK metadata is stored in the tenant database; and an encrypted version of the wrapper key is stored in a key management service (KMS) that is in communication with the tenant database; determining a top-level key used in connection with encrypting the wrapper key based at least in part on wrapper key metadata stored in association with the encrypted version of the wrapper key; obtaining the data stored within the tenant database, comprising decrypting at least part of the data based at least in part on (i) the TSEK, (ii) the wrapper key, and (iii) the top-level key; and providing the data in response to the request.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim Interpretation: Under the broadest reasonable interpretation, the terms of the claim are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP 2111.
The claim(s) recite(s) A system, comprising: One or more processors configured to: receive a request to access data; determine a key associated with the request to access data; determine a wrapper key used in connection with encrypting the key associated with the request to access data; obtain the data stored within the tenant database; and provide the data in response to the request to access the data; and a memory coupled to a processor of the one or more processors and configured to provide the instructions to the processor. The claim does not put any limits on what the key and wrapping keys are and how they are connected to each other and how these keys are used to obtain the data from the tenant database.
The steps recited above are performed by “ a processor coupled to a memory”. The recited processor is recited at a high level of generality, specification refers the term “processor” to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions, and since the specification is devoid of adequate structure to perform the claimed steps/functions, and merely i.e., as a generic computer performing generic computer
functions.
Step 1: See MPEP 2106.03. The claim recites at least one step or act, including “receive a request to access data” , and “determine a key…”, “obtain the data…”, and provide the data…. Thus, the claim is to a process, which is one of the statutory categories of invention. (Step 1: YES).
Step 2A, Prong One: As explained in MPEP 2106.04, subsection II, a claim “recites” judicial
exception when the judicial exception is “set forth” or “described” in the claim.
The broadest reasonable interpretation of steps is that those
steps fall within the mental process groupings of abstract ideas because they cover concepts
performed in the human mind, including observation, evaluation, judgment, and opinion. See
MPEP 2106.04(a)(2), subsection III. Under its broadest reasonable interpretation
when read in light of the specification, the “receiving” and “determining” , and “providing” encompasses mental observations or evaluations that are practically performed in the human mind, for example, the claimed receiving access data request, determining a key associated with the request to access data , and using a wrapper key to encrypt the encryption key, obtaining the data and providing the data.
Step 2A, Prong Two.
See MPEP 2106.04(d). The claim recites the additional elements of “one or more processor”
This judicial exception is not integrated into a practical application because the limitations “receiving access data request, determining a key associated with the request to access data , and using a wrapper key to encrypt the encryption key, obtaining the data and providing the data, in this case a processor, is recited at a high level of generality. The device is used as a tool to perform the generic computer function of receiving data and creating data. See MPEP 2106.05(f). The limitations, the computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer. See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).
Step 2B:
See MPEP 2106.05. As explained with respect to Step 2A, Prong Two, the additional elements.
The additional element of “one or more processor” are at best mere instructions to “apply” the abstract ideas, which cannot provide an inventive concept. See MPEP 2106.05(f)
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer and insignificant extra-solution activity, which do not provide an inventive concept. (Step 2B: NO).
The claim is ineligible.
Claims 2-9, 16-18, all recites other forms keys such as : wrapper key of a tenant service encryption key, customer wrapper key, Bring-your-own-key Tenant Wrapper Key, top-level key. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more under step 2A and Sept 2B , similarly as above analyzed.
Claims 10-15, all recites : a third-party key management service. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more under step 2A and Sept 2B , similarly as above analyzed.
Claim 19 and 20, the limitations “one or more processor” and “non-transitory computer readable medium and comprising computer instructions” the same steps, in this case a computer, are recited at a high level of generality, as above noted for claim 1. In these limitations are used as a tool to perform the generic computer function of receiving data and creating data. See MPEP 2106.05(f).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1. 19, and 20 recite the limitation “the tenant database”, and claim 1 recites “the instruction”, There is insufficient antecedent basis for these limitation in the claims 1, 19, and 20.
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, and 20 , recite the limitation "determine a wrapper key used in connection with encrypting the key associated with the request to access data; obtain the data stored within the tenant database", which renders the claim indefinite because the claimed limitation does not indicate how these two limitations are related to each other and what factors are considered for obtaining the data from tenant database!
Claims 2-18 do not cure the deficiency of claim 1 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claim 1.
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 9-20 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by being anticipated by Agarwal et al., (US2019/0173674) A1) hereinafter referred to as Agarwal( Filed in IDS 01/10/2025).
Regarding claims 1, 19, and 20, Agarwal discloses a system, comprising: One or more processors configured to: receive a request to access data; determine a key associated with the request to access 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 key used in connection with encrypting the key associated with the request to access data [¶¶35-36, 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. 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].; and
obtain the data stored within the tenant database; and provide the data in response to the request to access the data [¶84, In operation, various tenant clients 162-166 access tenant resources 172, 174, which may include, for example, dedicated shares of instances of software applications, e.g., database applications, file systems, data storage, and so on. The tenant resources 172, 174 include functionality for leveraging the tenant KM APIs 176 to obtain their DEKs needed to access data and functionality allocated to the tenant resources 172, 174. The tenant resources 172, 174 may first issue requests to the KM system 192 (via the tenant KM APIs 176) to obtain their associated DEKs; before accessing data and/or functionality associated with their respective tenant resources 172, 174]; and
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]; and
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 claim 9, Agarwal discloses, wherein the one or more processors is further configured to determine a top-level key used in connection with encrypting the wrapper key [¶36, 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 10, Agarwal discloses, wherein 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].
Regarding claim 11, Agarwal discloses, wherein the top-level key is stored in a third-party 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].
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, 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].
Regarding claim 15, Agarwal discloses, wherein the customer configures the system to use the top- level key provided by the third-party key management service or by the customer[¶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 16, Agarwal discloses, wherein the customer configures permissions for access to the top-level key managed by the customer[¶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 17, Agarwal 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 2 and associated text for more details, ¶¶74- 95, 116, 120].
Regarding claim 18, Agarwal 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 [0116] 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], and [see FIG 2 and associated text for more details, ¶¶74- 95, 120].
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 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 does 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 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.
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