DETAILED ACTION
This action is in response to new application titled “INDEPENDENT ENCRYPTION FOR CROSS REGION DATA SET REPLICATION” filed 6/27/2024. Claims 1-20 were received for consideration.
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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/27/2024, 12/20/2024, 7/17/2025 and 10/13/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-7, 11-16 and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Peddada et al (US 11,728,975).
With respect to claim 1 Peddada teaches a system, comprising:
a plurality of computing devices, respectively comprising at least one processor and a memory, that implement a database service of a provider network (see Peddada column 7, line 66: FIG. 2 shows a diagram of an example network environment that may be used with some embodiments of the present invention. Network environment 200 includes computing system 205, which may be a mobile computing system. The computing system 205 may be connected to the network 250 via a cellular connection or via a Wi- Fi router (not shown). The network 250 may be the Internet. The computing system 205 may be coupled with one or more server computing systems 230 and 260 via the network 250);
wherein the database service is configured to: perform a write to a table (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to perform a write to a table) replicated across different regions of the provider network (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network); the write being received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the write caused by the client must always be, implicitly, received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions);
replicate the write to the table to the different regions of the provider network, (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 correspond to the different regions of the provider network; the replication targets imply replicating the write to the table to the different regions of the provider network);
wherein to replicate the write the database service is configured to: perform the write on an item of the table in the first region (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to performing the write on an item of the table; implicitly, some first region exists to perform the write);
encrypt, in the first region, the item of the table (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; The customer data being encrypted while it is at rest using asymmetric or symmetric cryptography corresponds to encrypting the item of the table);
with a payload key for the first region (see column 12, line 53: To facilitate decryption, the public key associated with the tenant identifier and an identifier for the private key managed by the key server may be stored by the security module in metadata associated with the data encrypted using the symmetric key. The identifier for the private key may be, for example, a public key associated with the private key used to generate the symmetric key, or a public key identifier associated with the public key associated with the private key used to generate the symmetric key, as described above. To perform the encryption (and, similarly, decryption, as discussed below), the security module receives a fragment payload, the symmetric key, and an initialization vector; the fragment payload used to perform the encryption corresponds to a payload key);
append the encrypted item of the table to a multi-region append-only log; (see column 15, line 41: FIG. 7 shows an exemplary block diagram of transaction log system 700, in accordance with various embodiments. Transaction log data structure 700 is an exemplary embodiment of the transactions logs block 610 in FIG. 6, and may include master log system 720 and backup log system 740, which are in communication over network connection 730. The master log system 720 and the backup log system 740 may each also be in communication with the databases within their respective servers, which may include the extents shown in transactions log system 700. Master log system 720 logs all storage transactions with the database using a daemon 723 (which may be referred to as a backend or log daemon). These transactions may be logged in log buffer 726, which in the exemplary embodiment includes exemplary transaction 727. As seen in transaction 727, each transaction may include the organization associated with the transaction (as transaction logs are examples of cross-tenanted data, as described above). After the daemon 723 has logged transactions in the log buffer 726, the daemon 723 may forward the logged transactions to the security module, which may encrypt the transactions using a system key, as described above, in block 732. The encrypted transactions may then be stored in log extent 737. Log extent 737 may include log fragments 738 and 739, each being encrypted with the system key being currently used by the security module, and may be located in a database of a database server (e.g., database 550); The encrypted transactions being stored in log extent 737 corresponds to append the encrypted item of the table to a multi-region append-only log);
decrypt, in a second region of the different regions, the encrypted item obtained from the multi-region append-only log, using the payload key for the first region, (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data. the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key corresponds to decrypting the encrypted item obtained from the multi-region append-only log; obviously, in order for the decryption to take place, the payload key must be implicitly used);
wherein the payload key for the first region was decrypted in the second region using a private key of a public- private key pair for the second region to decrypt the payload key (see column 14, line 4: Likewise, when client data is requested, the security module may read the requested data from the database 550 at block 553. The reading may include extracting metadata associated with the client data, which may include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key. A duplicate of the symmetric key may then be requested at block 555 to decrypt the requested data. This may be performed, for example, using a function such as UnwrapKey(), with the keyid being the identifier of the private key. If the duplicate symmetric key has been generated (e.g., using the process described below in FIG. 8), then the duplicate symmetric key is retrieved from the key cache 513; otherwise the duplicate symmetric key is requested from the key server 575. At block 557 the duplicate symmetric key is used to decrypt the requested client data. The decrypted data may then be stored in the block cache 515; include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key implies that the symmetric key corresponds to the public-private key pair; decrypting the requested data with the keyid being the identifier of the private key corresponds to using a private key of a public-private key pair to decrypt the payload key);
the payload key having been previously encrypted using a public key of the public-private key pair at the first region (see column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above; The public key of the system key private-public key pair being transmitted to a key server. to generate a symmetric key used to encrypt and protect the database data corresponds to the payload key having been previously encrypted using a public key of the public-private key pair); and
update the table in the second region using the decrypted item (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network).
With respect to claim 2 Peddada teaches the system of claim 1, wherein the public key is shared by the second region with the first region after generating the public-private key pair at the second region (see Peddada column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above).
With respect to claim 3 Peddada teaches the system of claim 2, wherein the public-private key pair is for a shard of the table generated based on a table key (see Peddada column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above).
With respect to claim 5 Peddada teaches a method, comprising:
performing a write to a data set (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to perform a write to a table) replicated across different regions of the provider network (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network); the write being received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the write caused by the client must always be, implicitly, received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions);
replicating the write to the table to the different regions of the provider network, (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 correspond to the different regions of the provider network; the replication targets imply replicating the write to the table to the different regions of the provider network); comprising
performing the write on an item of the table in the first region (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to performing the write on an item of the table; implicitly, some first region exists to perform the write);
encrypting, in the first region, the item of the table (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; The customer data being encrypted while it is at rest using asymmetric or symmetric cryptography corresponds to encrypting the item of the table);
with a payload key for the first region (see column 12, line 53: To facilitate decryption, the public key associated with the tenant identifier and an identifier for the private key managed by the key server may be stored by the security module in metadata associated with the data encrypted using the symmetric key. The identifier for the private key may be, for example, a public key associated with the private key used to generate the symmetric key, or a public key identifier associated with the public key associated with the private key used to generate the symmetric key, as described above. To perform the encryption (and, similarly, decryption, as discussed below), the security module receives a fragment payload, the symmetric key, and an initialization vector; the fragment payload used to perform the encryption corresponds to a payload key);
appending the encrypted item of the table to a multi-region append-only log; (see column 15, line 41: FIG. 7 shows an exemplary block diagram of transaction log system 700, in accordance with various embodiments. Transaction log data structure 700 is an exemplary embodiment of the transactions logs block 610 in FIG. 6, and may include master log system 720 and backup log system 740, which are in communication over network connection 730. The master log system 720 and the backup log system 740 may each also be in communication with the databases within their respective servers, which may include the extents shown in transactions log system 700. Master log system 720 logs all storage transactions with the database using a daemon 723 (which may be referred to as a backend or log daemon). These transactions may be logged in log buffer 726, which in the exemplary embodiment includes exemplary transaction 727. As seen in transaction 727, each transaction may include the organization associated with the transaction (as transaction logs are examples of cross-tenanted data, as described above). After the daemon 723 has logged transactions in the log buffer 726, the daemon 723 may forward the logged transactions to the security module, which may encrypt the transactions using a system key, as described above, in block 732. The encrypted transactions may then be stored in log extent 737. Log extent 737 may include log fragments 738 and 739, each being encrypted with the system key being currently used by the security module, and may be located in a database of a database server (e.g., database 550); The encrypted transactions being stored in log extent 737 corresponds to append the encrypted item of the table to a multi-region append-only log);
decrypting, in a second region of the different regions, the encrypted item obtained from the multi-region append-only log, using the payload key for the first region, (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data. the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key corresponds to decrypting the encrypted item obtained from the multi-region append-only log; obviously, in order for the decryption to take place, the payload key must be implicitly used);
wherein the payload key for the first region was decrypted in the second region using a private key of a public- private key pair for the second region to decrypt the payload key (see column 14, line 4: Likewise, when client data is requested, the security module may read the requested data from the database 550 at block 553. The reading may include extracting metadata associated with the client data, which may include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key. A duplicate of the symmetric key may then be requested at block 555 to decrypt the requested data. This may be performed, for example, using a function such as UnwrapKey(), with the keyid being the identifier of the private key. If the duplicate symmetric key has been generated (e.g., using the process described below in FIG. 8), then the duplicate symmetric key is retrieved from the key cache 513; otherwise the duplicate symmetric key is requested from the key server 575. At block 557 the duplicate symmetric key is used to decrypt the requested client data. The decrypted data may then be stored in the block cache 515; include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key implies that the symmetric key corresponds to the public-private key pair; decrypting the requested data with the keyid being the identifier of the private key corresponds to using a private key of a public-private key pair to decrypt the payload key);
the payload key having been previously encrypted using a public key of the public-private key pair at the first region (see column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above; The public key of the system key private-public key pair being transmitted to a key server. to generate a symmetric key used to encrypt and protect the database data corresponds to the payload key having been previously encrypted using a public key of the public-private key pair); and
updating the table in the second region using the decrypted item (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network).
With respect to claim 6 Peddada teaches the method of claim 5, wherein the public key is shared by the second region with the first region after generating the public-private key pair at the second region (see Peddada column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above).
With respect to claim 7 Peddada teaches the method of claim 6, wherein the public-private key pair is for a shard of the data set (see Peddada column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above).
With respect to claim 11 Peddada teaches the method of claim 5, wherein the public key is received at the first region after a key pair rotation event (see Peddada column 17, line 4: Over time, it may be a good practice for customers to rotate the keys used to encrypt their data (i.e., use a different symmetric key to encrypt their data), to provide more security for the encrypted data. To do so, the database server may simply send a new request to the key server for a different symmetric key that includes a reference to the private key used to create the original symmetric key (e.g., the public key associated with the private key used to create the original symmetric key, a public key identifier for the public key associated with the private key used to create the original symmetric key, the tenant identifier, etc.) and a different public key. This request to rotate the symmetric keys for a specific customer may be initiated by the customer, by an administrator of the security module, or automatically by the security module (e.g., after a predetermined period of time) in various embodiments. In an exemplary embodiment, the key rotation may be triggered by the security module using a command, such as "ALTER TENANT REFRESH KEY).
With respect to claim 12 Peddada teaches the method of claim 5, wherein the key pair rotation event is caused by a shard split for the data set (see Peddada column 17, line 4: Over time, it may be a good practice for customers to rotate the keys used to encrypt their data (i.e., use a different symmetric key to encrypt their data), to provide more security for the encrypted data. To do so, the database server may simply send a new request to the key server for a different symmetric key that includes a reference to the private key used to create the original symmetric key (e.g., the public key associated with the private key used to create the original symmetric key, a public key identifier for the public key associated with the private key used to create the original symmetric key, the tenant identifier, etc.) and a different public key. This request to rotate the symmetric keys for a specific customer may be initiated by the customer, by an administrator of the security module, or automatically by the security module (e.g., after a predetermined period of time) in various embodiments. In an exemplary embodiment, the key rotation may be triggered by the security module using a command, such as "ALTER TENANT REFRESH KEY).
With respect to claim 13 Peddada teaches the method of claim 5, wherein the payload key is obtained as part of record that includes the encrypted item in the multi-region append only log (see Peddada column 17, line 4: Over time, it may be a good practice for customers to rotate the keys used to encrypt their data (i.e., use a different symmetric key to encrypt their data), to provide more security for the encrypted data. To do so, the database server may simply send a new request to the key server for a different symmetric key that includes a reference to the private key used to create the original symmetric key (e.g., the public key associated with the private key used to create the original symmetric key, a public key identifier for the public key associated with the private key used to create the original symmetric key, the tenant identifier, etc.) and a different public key. This request to rotate the symmetric keys for a specific customer may be initiated by the customer, by an administrator of the security module, or automatically by the security module (e.g., after a predetermined period of time) in various embodiments. In an exemplary embodiment, the key rotation may be triggered by the security module using a command, such as "ALTER TENANT REFRESH KEY).
With respect to claim 14 Peddada teaches one or more non-transitory, computer-readable storage media, storing program instructions that when executed on or across one or more computing devices cause the one or more computing devices to implement: performing a write to a table (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to perform a write to a table) replicated across different regions of the provider network (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network); the write being received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the write caused by the client must always be, implicitly, received at a first region of the different regions, and the table being writeable via requests received at individual ones of the different regions);
replicating the write to the data set to the different regions of the provider network, (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 correspond to the different regions of the provider network; the replication targets imply replicating the write to the table to the different regions of the provider network); comprising:
performing the write on an item of the table in the first region (see column 3, line 34: As used herein, the term "multi-tenant database system" refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers; a given database table storing rows corresponds to performing the write on an item of the table; implicitly, some first region exists to perform the write);
encrypting, in the first region, the item of the table (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; The customer data being encrypted while it is at rest using asymmetric or symmetric cryptography corresponds to encrypting the item of the table);
with a payload key for the first region (see column 12, line 53: To facilitate decryption, the public key associated with the tenant identifier and an identifier for the private key managed by the key server may be stored by the security module in metadata associated with the data encrypted using the symmetric key. The identifier for the private key may be, for example, a public key associated with the private key used to generate the symmetric key, or a public key identifier associated with the public key associated with the private key used to generate the symmetric key, as described above. To perform the encryption (and, similarly, decryption, as discussed below), the security module receives a fragment payload, the symmetric key, and an initialization vector; the fragment payload used to perform the encryption corresponds to a payload key);
appending the encrypted item of the table to a multi-region append-only log; (see column 15, line 41: FIG. 7 shows an exemplary block diagram of transaction log system 700, in accordance with various embodiments. Transaction log data structure 700 is an exemplary embodiment of the transactions logs block 610 in FIG. 6, and may include master log system 720 and backup log system 740, which are in communication over network connection 730. The master log system 720 and the backup log system 740 may each also be in communication with the databases within their respective servers, which may include the extents shown in transactions log system 700. Master log system 720 logs all storage transactions with the database using a daemon 723 (which may be referred to as a backend or log daemon). These transactions may be logged in log buffer 726, which in the exemplary embodiment includes exemplary transaction 727. As seen in transaction 727, each transaction may include the organization associated with the transaction (as transaction logs are examples of cross-tenanted data, as described above). After the daemon 723 has logged transactions in the log buffer 726, the daemon 723 may forward the logged transactions to the security module, which may encrypt the transactions using a system key, as described above, in block 732. The encrypted transactions may then be stored in log extent 737. Log extent 737 may include log fragments 738 and 739, each being encrypted with the system key being currently used by the security module, and may be located in a database of a database server (e.g., database 550); The encrypted transactions being stored in log extent 737 corresponds to append the encrypted item of the table to a multi-region append-only log);
decrypting, in a second region of the different regions, the encrypted item obtained from the multi-region append-only log, using the payload key for the first region, (see column 3, line 55: In general, a multi-tenant database environment may include multiple databases configured to store data associated with organizations or customers. The data (also referred to as customer data) may be unencrypted when it is stored by the customers. The customer data may be encrypted while it is at rest using asymmetric or symmetric cryptography. The encrypted customer data protects it from being accessed by any unauthorized users. While it may be important to encrypt the customer data, it may be desirable to secure the decryption key (private key or the symmetric key). The decryption key may be stored in a storage area that only certain authorized personnel can access (e.g., a security administrator). When the customer wants to retrieve the customer data. the encrypted customer data may be decrypted using the decryption key. The decrypted customer data may then be transmitted to the customer. The encrypted customer data may be stored in any storage area associated with the multi-tenant database environment, including cloud- based storage area, non-cloud-based storage area, or other forms of storage implementations; When the customer wants to retrieve the customer data, the encrypted customer data may be decrypted using the decryption key corresponds to decrypting the encrypted item obtained from the multi-region append-only log; obviously, in order for the decryption to take place, the payload key must be implicitly used);
wherein the payload key for the first region was decrypted in the second region using a private key of a public- private key pair for the second region to decrypt the payload key (see column 14, line 4: Likewise, when client data is requested, the security module may read the requested data from the database 550 at block 553. The reading may include extracting metadata associated with the client data, which may include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key. A duplicate of the symmetric key may then be requested at block 555 to decrypt the requested data. This may be performed, for example, using a function such as UnwrapKey(), with the keyid being the identifier of the private key. If the duplicate symmetric key has been generated (e.g., using the process described below in FIG. 8), then the duplicate symmetric key is retrieved from the key cache 513; otherwise the duplicate symmetric key is requested from the key server 575. At block 557 the duplicate symmetric key is used to decrypt the requested client data. The decrypted data may then be stored in the block cache 515; include the public key used to generate the symmetric key, and an identifier of the private key used to generate the symmetric key implies that the symmetric key corresponds to the public-private key pair; decrypting the requested data with the keyid being the identifier of the private key corresponds to using a private key of a public-private key pair to decrypt the payload key);
the payload key having been previously encrypted using a public key of the public-private key pair at the first region (see column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above; The public key of the system key private-public key pair being transmitted to a key server. to generate a symmetric key used to encrypt and protect the database data corresponds to the payload key having been previously encrypted using a public key of the public-private key pair); and
updating the table in the second region using the decrypted item (see column 8, line 60: FIG. 3 illustrates an example of generating a symmetric key for a customer, in accordance with some embodiments. During operation, the client device 305 running client application 310 may call a function to create a new key for an organization that wishes to store client data on the database server 330. The function may transmit a tenant identifier tenld 315 to the key server 360. The tenant identifier tenld 315 may be created by the client application 310 in some embodiments, or it may be received from the database server 330 in response to an earlier request by the client application 310. In an exemplary embodiment, in addition to the tenant identifier tenld 315, the client application 310 may transmit an access control list, which may include backend daemons of the database server 330, and any APIs used by the security module to access the private key (for example, kms_find_key(), described below). The client application 310 may also transmit replication targets, which contain the client data a user wishes to store on the database server 330. This may include, in addition to production database data, any backup database data utilized by the customer; the replication targets, which contain the client data a user wishes to store on the database server 330 imply (writes being) replicated across different regions of the provider network).
With respect to claim 15 Peddada teaches the one or more non-transitory, computer-readable storage media of claim 14, wherein the public key is shared by the second region with the first region after generating the public-private key pair at the second region (see Peddada column 14, line 46: As stated above, different symmetric keys may be used to encrypt the data in the database 550. Customer data may be encrypted using the corresponding symmetric keys. Cross-tenanted data, meaning data that indexes or organizes data for multiple customers, may be encrypted using a system key. Examples of cross-tenanted data may include block index 630, transaction logs 610, and storage catalog 615. Non-tenanted data, such as data fragment 622 (which may include data about the data extent itself, or data relating to the database 550), may also be encrypted using the same system key as the cross-tenanted data, or using a separate key. System keys may be generated by the security module of the database server 550, using a private-public key pair generated by the security module. The public key of the system key private-public key pair may be transmitted to a key server, as described above, to generate a symmetric key specific to the database server 550, which may be used to encrypt and protect the database data as described above).
With respect to claim 16 Peddada teaches the one or more non-transitory, computer-readable storage media of claim 14, wherein the public-private key pair is for a portion of the data set (see Peddada column 12 line 53 – column 13 line 9 i.e. To facilitate decryption, the public key associated with the tenant identifier and an identifier for the private key managed by the key server may be stored by the security module in metadata associated with the data encrypted using the symmetric key. The identifier for the private key may be, for example, a public key associated with the private key used to generate the symmetric key, or a public key identifier associated with the public key associated with the private key used to generate the symmetric key, as described above. To perform the encryption (and, similarly, decryption, as discussed below), the security module receives a fragment payload, the symmetric key, and an initialization vector. The initialization vector may advantageously provide randomness to each encrypted block by being a unique value derived from information within the fragment being encoded or decoded. In an exemplary embodiment, the initialization vector may be based on a different feature, depending on the size of the data being encrypted. For extents, either an extent number or a random number may be used as an eight-byte initialization vector. For fragments, a fragment number may be used as a four-byte initialization vector. For blocks, which may be 16-byte units (the smallest unit for encryption purposes), a block counter may be used as a four-byte initialization vector).
With respect to claim 19 Peddada teaches the one or more non-transitory, computer-readable storage media of claim 14, wherein the payload key is generated after a payload key rotation event (see Peddada column 17, line 4: Over time, it may be a good practice for customers to rotate the keys used to encrypt their data (i.e., use a different symmetric key to encrypt their data), to provide more security for the encrypted data. To do so, the database server may simply send a new request to the key server for a different symmetric key that includes a reference to the private key used to create the original symmetric key (e.g., the public key associated with the private key used to create the original symmetric key, a public key identifier for the public key associated with the private key used to create the original symmetric key, the tenant identifier, etc.) and a different public key. This request to rotate the symmetric keys for a specific customer may be initiated by the customer, by an administrator of the security module, or automatically by the security module (e.g., after a predetermined period of time) in various embodiments. In an exemplary embodiment, the key rotation may be triggered by the security module using a command, such as "ALTER TENANT REFRESH KEY).
With respect to claim 20 Peddada teaches the one or more non-transitory, computer-readable storage media of claim 14, wherein the data set is hosted as part of a non-relational database service implemented as part of the provider network (see Peddada column 8 lines 8-25 i.e. The database server 230 may be in communication with a plurality of customer devices over network 250. Each client computing system, similarly to computing system 205, may be associated with a client and may include client application module 208. A user may use the client computing system 205 and the client application module 208 to connect to and communicate with the server computing system 230 (also referred to as the database server) and log into security module 235 (which may be an application running on the database server 230 that facilitates the encryption and decryption steps described herein). The user may transmit client data to the database server 230 and may make subsequent requests for the client data from the database server 230. The database server 230 may store database 270, which may store client data for multiple clients. The database server 230 may be associated with an entity (e.g., Salesforce.com®)).
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 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Peddada et al (US 11,728,975) in view of Roth et al (US 2013/0085880).
With respect to claim 8 Peddada teaches the method of claim 6 but does not disclose wherein the public key is shared using control plane communications of the provider network that cross the different regions.
Roth teaches wherein the public key is shared using control plane communications of the provider network that cross the different regions (see Roth paragraph 0031 i.e. The control plane may create a public/private key pair on behalf of the guest operating system. Using identifying information about the guest operating system and the public key, the control plane request a digital certificate be issued to the guest operating system. The control plane may then deliver the secure communication setup information, such as digital certificate, keys and other secure information to the hypervisor through a trusted network)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peddada in view of Roth to have used a control plane as a way to send the public key through a secure communication (see Roth paragraph 0031).
With respect to claim 17 Peddada teaches the one or more non-transitory, computer-readable storage media of claim 14, but does not disclose wherein the public key is shared using control plane communications of the provider network that cross the different regions.
Roth teaches wherein the public key is shared using control plane communications of the provider network that cross the different regions (see Roth paragraph 0031 i.e. The control plane may create a public/private key pair on behalf of the guest operating system. Using identifying information about the guest operating system and the public key, the control plane request a digital certificate be issued to the guest operating system. The control plane may then deliver the secure communication setup information, such as digital certificate, keys and other secure information to the hypervisor through a trusted network)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peddada in view of Roth to have used a control plane as a way to send the public key through a secure communication (see Roth paragraph 0031).
Allowable Subject Matter
Claims 4, 9, 10 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The prior art does not teach with respect to claim 4 the system of claim 1, wherein the database service is further configured to: receive, at the second region, the payload key from a record appended to the multi- region append-only log; and decrypt, the payload key using the private key of the public-private key pair; and store the decrypted payload key in a cache, wherein the payload key is obtained from the cache according to an identifier for the payload key included with the encrypted item of the data set append to the multi-region append-only log.
The prior art does not teach with respect to claim 9 the method of claim 5, further comprising: receiving, at the second region, the payload key from a record appended to the multi- region append-only log; and decrypting, the payload key using the private key of the public-private key pair; and storing the decrypted payload key in a cache, wherein the payload key is obtained from the cache according to an identifier for the payload key included with the encrypted item of the data set append to the multi-region append-only log.
Claim 10 is allowable based on is dependence from claim 10.
The prior art does not teach with respect to claim 18 the one or more non-transitory, computer-readable storage media of claim 14, storing further program instructions that when executed by the one or more computing devices, cause the one or more computing devices to further implement: receiving, at the second region, the payload key from a record appended to the multi- region append-only log; and decrypting, the payload key using the private key of the public-private key pair; and storing the decrypted payload key in a cache, wherein the payload key is obtained from the cache according to an identifier for the payload key included with the encrypted item of the data set append to the multi-region append-only log.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492
Prosecution Insights