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 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.
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.
Claim(s) 1, 3-7, 8, 10-15, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Balasubramanian et al. (U. S. PGPub. No. 2022/0311757 A1) (hereinafter “Balasubramanian”) in view of Cignetti et al. (U. S. PGPub. No. 2016/0112387 A1) (hereinafter “Cignetti”).
Regarding Claim 1, Balasubramanian teach:
receiving, by a computing system, a request from a user device to transmit encryption keys stored in a first virtual vault of a plurality of virtual vaults of a first hardware security module (HSM) of a first data center to a second virtual vault of a second hardware security module (HSM) of a second data center, the request comprising an account identifier (Balasubramanian: [0032], receives a request from the user to rotate a key, the HSM micro-service 109 interacts with the HSM card 110 to obtain the key and perform the key rotation operation. [0035], information in a vault of a customer (i.e., information maintained in a primary region) is replicated to a vault in a secondary region. [0028], It is appreciated that write operations and mutation operations are permitted to be performed on keys stored in the primary vault (i.e., in the primary region). As will be described later, the modified keys (and metadata) are replicated to the secondary vault. [0059], The request may include an identifier of the second region 402.)
identifying, by the computing system, a first account-specific write-ahead log (WAL) of a plurality of account-specific write-ahead logs (WALs) based at least in part on the account identifier (Balasubramanian [0055], a write-ahead log (WAL) record in accordance with some embodiments. Each record in the WAL includes at least the following components: (1) a primary ID corresponding to an identifier of a primary region of the WAL, (2) membership IDs corresponding to identifiers of secondary regions where the WAL is replicated, (3) a type of record of the WAL—such as a data type record, an HSM record, or an infrastructure type record (i.e., infrastructure commands such as obtaining a snapshot of the WAL), (4) a checksum value, (5) a version of the record, (6) a log sequence number of the record, and (7) an entropy value of the record. [0035], Cross-regional replication of information is performed via a write-ahead log (WAL) service e.g., WAL service 111 included in region 101. The WAL service 111 maintains a write-ahead log that is a database object (e.g., a table or a ledger) that maintains an ordered sequence of operations performed by a user on information stored in the vault of the primary region 101),
each account-specific write-ahead log (WAL) of the plurality of account-specific write-ahead logs (WALs) corresponding to the first hardware security module (HSM) (Balasubramanian [0036], The HSM micro-service in the secondary region (e.g., HSM micro-service 129) polls the key-value database 127 to read the WALs stored therein and further writes the WALs to the HSM card included in the secondary region e.g., HSM card 130. Thus, operations performed by users in the primary region e.g., control plane operations and data plane operations can be executed by users via control/data plane micro-services of the secondary region via using the replicated information),
and each account-specific write-ahead log (WAL) of the plurality of account-specific write-ahead logs (WALs) configured to record changes to a respective virtual vault of the plurality of virtual vaults (Balasubramanian [0049] Each WAL included in the WAL repository 210 is associated with a unique WAL processor i.e., a node specific component that is responsible for the WAL on the node. For instance, as shown in FIG. 2, the replication system includes a plurality of processors 222. Specifically, a processor for WAL0, 222A is configured to reads entries from the corresponding WAL i.e., WAL0 224 and apply the entries to an underlying state machine e.g., HSM card. In a similar manner, processor for WAL1, 222B is configured to reads entries from the corresponding WAL i.e., WAL1 226 and apply the entries to an underlying state machine);
Balasumbramanian does not explicitly disclose:
accessing, by the computing system, the encryption keys from the first account-specific write-ahead log (WAL) of the first hardware security module (HSM);
However, in an analogous art, Cignetti teaches:
accessing, by the computing system, the encryption keys from the first account-specific write-ahead log (WAL) of the first hardware security module (HSM) (Cignetti: [0042] The hardware security module 508 may be logically separate from the other systems and services of the service provider to ensure confidentiality and protection of the keys…The keys stored in the hardware security module may only be accessed using valid credentials)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Balasumbramanian’s method of receving a request to rotate a key and identifying WAL in HSM by applying Signetti’s method of accessing, in order to access keys stored in HSM in order to provide superior security by storing keys in temper resistance hardware and prevent unauthorized access/exposed to sensitive data using keys during serialization operation (Signetti: [Abstract]).
Regarding Claim 3, Balasumbramanian in view of Signetti teach:
The method of claim 1 (see rejection of claim 1 above),
transmitting, to the second data center, a first message as to whether the second data center has a capacity to generate a second virtual vault for storing the encryption keys (Balasubramanian: [0061], The provisioning service 415 of the secondary region may respond with an acknowledgement message (=a first message) indicating that the vault replication status is in progress (step S7).),
and receiving a second message indicating that the second data center has the capacity to generate a second virtual vault for storing the encryption keys (Balasubramanian [0063], Upon receiving an acknowledgement (=second message) indicating successful completion of the vault creating process from the control plane of the secondary region (step S11), the provisioning service 415 of the secondary region 402 may indicate the same (i.e., vault ready message in step S13) to the provisioning service 405 of the primary region 401 in response to receiving a get vault message (step S12) from the provisioning service 405.);
wherein the encryption keys are accessed from the first account-specific write-ahead log (WAL) based at least in part on the second message (Balasubramanian [0069], In step 513, the second vault is updated to reflect the mutation operation performed on the first vault. For instance, the WAL service in the secondary region replicates and stores the new record in the secondary vault thereby ensuring that the mutation operation is successfully mirrored in the second vault).
Regarding Claim 4, Balasumbramanian in view of Signetti teach:
The method of claim 3 (see rejection of claim 3 above),
receiving a third message from the second data center that the second virtual vault has been generated (Balasubramanian [0064], in step S16, the provisioning service 405 included in the primary region 401 may respond with a message (=third message) indicating a ‘Replicated’ status implying that the vault in the secondary region has been created and that the WAL in the primary region can be replicated to the vault in the secondary region. [0063] Upon receiving an acknowledgement indicating successful completion of the vault creating process from the control plane of the secondary region (step S11), the provisioning service 415 of the secondary region 402 may indicate the same (i.e., vault ready message (=third message) in step S13) to the provisioning service 405 of the primary region 401 in response to receiving a get vault message (step S12) from the provisioning service 405. [0064], Upon receiving an indication that the vault is ready for replication, in step S14),
wherein the encryption keys are transmitted to the second data center based at least in part on the third message(Balasubramanian [0065] According to some embodiments, KMS replicates keys in a vault within and across regions in a realm. Customer or user mutations on their respective vaults and keys are driven by write-ahead-logs (WALs) internally, and WALs are replicated across regions to achieve cross regional replication of customer keys. [0068] In step 505, a secondary vault is created in the selected second region. The process of creating the secondary vault corresponds to an infrastructure that is set up for user access to secondary vault and for the replication process to kick off as described previously with reference to FIG. 4. Upon creation of the secondary vault in the second region of the cloud infrastructure, information is replicated from the first vault in the first region to the second vault in the second region for replication purposes.)
Regarding Claim 5, Balasumbramanian in view of Signetti teach:
The method of claim 1 (see rejection of claim 1 above),
detecting an update of the encryption keys at the first virtual vault (Balasubramanian [0034], Thus, one can identify updates to the key-value table as a stream of logical records that deal with create/update/delete operation(s) of a specific row identified by an identifier (ID).
and causing the first account-specific write-ahead log (WAL) to create a log entry describing the update (Balasubramanian [0069], performing a rotation operation of the key, or updating a display name of the first vault. By some embodiments, the mutation operation may be stored as a new record in the WAL of in the first vault. [0070], Each WAL has a first entry/record including a seed value, which indicates the primary region ID of the WALs. As shown in FIG. 6, the primary region of the WALs is region 1 (i.e., seed value of ‘1’). Further, a current state of the WALS is as follows: WAL 1 in region 1 includes six entries, WAL 2 in region 2 includes three entries, WAL 3 in region 3 includes six entries, whereas WAL 4 in region 4 includes four entries),
wherein the updated encryption keys are transmitted to the second data center (Balasubramanian [0069], The process thereafter proceeds to step 511, where information indicative of the mutation operation is transmitted to the second vault. [0071], Note that this operation is deemed valid due to correct entropy value. In this manner, replication of WAL records occurs in a uni-directional manner i.e., from primary region of the WAL to one or more secondary regions. Any operations (e.g., mutation operations) performed on the WAL in the primary region are relayed to the one or more WALS in the secondary region(s)).
Regarding Claim 6, Balasumbramanian in view of Signetti teach:
The method of claim 5 (see rejection of claim 5 above),
wherein the update comprises at least one of inserting an encryption key into the first virtual vault, modifying an encryption key at the first virtual vault, or deleting an encryption key from the first virtual vault (Balasubramanian [0031], rotate a key to obtain a new version of the key etc. [0069] The process then proceeds to step 509, where a mutation operation is executed with respect to the first vault. It is noted that mutation operation may correspond to one of: changing the metadata associated with the key, performing a rotation operation of the key, or updating a display name of the first vault. By some embodiments, the mutation operation may be stored as a new record in the WAL of in the first vault).
Regarding Claim 7, Balasumbramanian in view of Signetti teach:
The method of claim 1 (see rejection of claim 1 above),
wherein the first virtual vault maps to a physical partition of the first hardware security module (HSM) (Balasubramanian: [0028], the HSM 102 can be further divided into multiple HSM partitions 108, where each HSM partition 108 is dedicated to support key and security credential management and to perform crypto operations offloaded from a web service provider/host over a network via its corresponding HSM-VM 104 with one or more crypto acceleration units of pre-configured values, and a dedicated key store 109 discussed in details below. In some embodiments, the HSM partitions 108 are soft partitions created by the HSM managing VM 106 (discussed in details below) utilizing firmware of the HSM 102 and its hardware implementations (e.g., HSM adapter 202). [0029] In the example of FIG. 1, each HSM-VM 104 and its corresponding HSM partition 108 form an HSM service unit 107, which communicates with and offloads secured key management and crypto operations from a specific user/web service host…).
Regarding claim 8, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (System medium). For this reason the same grounds of rejection are applied to claim 8.
Regarding claim 10, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 10.
Regarding claim 11, this claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 11.
Regarding claim 12, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 12.
Regarding claim 13, this claim contains identical limitations found within that of claim 6above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 13.
Regarding claim 14, this claim contains identical limitations found within that of claim 7 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 14.
Regarding claim 15, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 15.
Regarding claim 17, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 17.
Regarding claim 18, this claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 18.
Regarding claim 19, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 19.
Regarding claim 20, this claim contains identical limitations found within that of claim 6 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 20.
Claim(s) 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Balasubramanian et al. (U. S. PGPub. No. 2022/0311757 A1) (hereinafter “Balasubramanian”) in view of Cignetti et al. (U. S. PGPub. No. 2016/0112387 A1) (hereinafter “Cignetti”), and further in view of KANCHARLA et al. (U. S. PGPub. No. 2015/0358161 A1) (hereinafter “Kancharla”)
Regarding Claim 2, Balasubramanian in view of Cignetti
The method of claim 1 (see rejection of claim 1 above),
The Balasubramanian in view of Cignetti does not explicitly disclose:
detecting generation of a first virtual partition at a virtual vault partition of the first hardware security module (HSM), the first virtual partition corresponding to the first virtual vault.
generating a masking key based at least in part on detecting the generation of the first virtual partition and encrypting the encryption keys using the masking key
wherein the encryption keys can be decrypted at the second data center using the same masking key
However, in an analogous art, Kancharla teaches:
detecting generation of a first virtual partition at a virtual vault partition of the first hardware security module (HSM), the first virtual partition corresponding to the first virtual vault (Kancharla: [0057], Specifically, the HSM managing VM 106 determines the number of active HSM partitions 108 within the HSM 102 (=detecting generation of virtual partition), [0061], the HSM managing VM 106 communicates with the HSM 102 to identify the number of active HSM partitions 108 available in the HSM 102);
generating a masking key based at least in part on detecting the generation of the first virtual partition (Kancharla: [0067], the KBK (=masking key) is securely generated via a FIPS approved key exchange mechanism during a mutually authenticated secured communication session between the HSM VM 104 and the user/web service host as discussed above);
and encrypting the encryption keys using the masking key (Kancharla: [0067], the HSM VM 104 is configured to wrap/encrypt the objects before they are imported to or exported from its corresponding HSM partition 108 [0068], the HSM VM 104 is configured to utilize a FIPS approved smartcard 132 to store the KBK (=masking key) used to encrypt/decrypt the objects in the key store 109 and to block all un-authorized access to the KBK by other VMs and/or users ),
wherein the encryption keys can be decrypted at the second data center using the same masking key (Kancharla: [0067], unwrap/decrypt the objects after they have been imported and/or exported to their destination (=second datacenter) (a key store 109 in an HSM partition 108 [0068], Keeping the KBK (=masking key) safe and secure is crucial since all objects/keys are encrypted/decrypted using the KBK).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Balasubramanian in view of Cignetti by applying the well-known technique as disclosed by Kancharla of generating KBK key in order to encrypt objects/keys and decrypt encrypted keys to their destination (=second data center). The motivation is to provide secured key management for cloud-based web services hosted at a third party data center via HSMs (Kancharla: [0007]).
Regarding Claim 9, Balasubramanian teaches:
wherein the sequence of instructions, when executed, further cause the one or more processors to (Balasubramanian: [0008] One aspect of the present disclosure provides for a computing device comprising: a processor; and a memory including instructions that, when executed with the processor, cause the computing device to, at least):
This claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (System medium). For this reason the same grounds of rejection are applied to claim 9.
Regarding Claim 16, Balasubramanian teaches:
The non-transitory computer-readable media of claim 15 (see rejection of claim 15 above),
wherein the sequence of instructions, when executed, further cause the one or more processors to (Balasubramanian: [0007] Another aspect of the present disclosure provides for a non-transitory computer readable medium storing specific computer-executable instructions that, when executed by a processor, cause a computer system to at least):
This claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 16.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Edukulla (U. S. Pat. No. 10,846,302 B1): Methods, systems, and computer-readable media for replication event ordering using an external data store are disclosed. Events are received for a key in a source data store, including a deletion event and modification events. In an external data store, a record of the deletion event is stored that includes a sequence identifier of the deletion event in a sequence. Sequence identifiers are assigned to the modification events. Some of the sequence identifiers are earlier than the deletion event in the sequence, and others of the sequence identifiers are later than the deletion event in the sequence and are assigned based at least in part on the record of the deletion event in the external data store. Individual events are replicated or not replicated to the destination data store based at least in part on their sequence identifiers.
Murali et al. (U. S. Pat. No. 9,582,524 B1): Techniques are described for migrating data from a first table to a second table while transforming at least one characteristic of the data. Characteristics transformed may include one or more of an encryption key or method, a table schema, a data structure, or a storage infrastructure. Migration may be performed in two or more phases. A first phase may migrate and transform a majority of the data, such as data that is older than a certain threshold age. A second phase may migrate and transform the remaining, newer data. A status table may indicate which tables are active and are to be written to and read from during data writing and data consuming processes. Moreover, embodiments support data replication across multiple regions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437