Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/09/2026 has been entered.
Response to Amendments
Applicant’s arguments have been fully considered. However, upon further consideration, a new
ground(s) of rejection is made in view of BIRK (US 20080101610 A1) in view of Rich (US 20130044882 A1) based on the new amendments to the claims 1, 13, 17.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 6, 7, 9, 10, 13, 16, 17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over BIRK (US 20080101610 A1) in view of Copparapu (US 11671251 B1) in view of Ghafoor (US 20220343010 A1) in view of Rich (US 20130044882 A1).
Regarding claim 1, BIRK teaches generating, by a computing device, one or more managed key specifications, wherein each of the one or more managed key specifications is associated with one or more key sets (Claim 1. Para [0035]: Encryption key processor 200 comprises a key manager 202. Key manager 202 performs a variety of functions relating to the generation and management of keys. One function of key manager 202 is to associate keys with their respective attributes as specified by a system administrator. Attributes of a key include the name of the key set to which the key belongs.);
generating, based on a managed key specification for a first key set of the one or more keys, one or more data encryption keys (DEKS) for each of a plurality of users, wherein the one or more DEKS of the first key set are segregated at a user level where each user of the plurality of users utilizes a distinct key for the first key set (Claim 1. Para [0014]. Para [0035]. Para [0038]: encryption key processor 200 comprises a key manager 202. Key manager 202 performs a variety of functions relating to the generation and management of keys. Key generator 206 may comprise a first key generator for generating a secret key, and a second key generator for generating a public/private key pair. One function of key manager 202 is to associate keys with their respective attributes as specified by a system administrator. Attributes of a key include the name of the key set to which the key belongs. Based on the scope specified, the key set or key set group visibility for the purposes of isolation. );
storing the generated one or more DEK in the first key set (Para [0038]. Claim 5: Key store 204 receives the keys from key generator 206 and stores them.), wherein the first key set comprises a unique label that is used to retrieve key instances of the first key set (Para [0041]: This block of code creates or specifies a key set and identifies the key set by name. The code also specifies an alias prefix. The alias prefix prefixes a key alias. Thus, keys in the key set will be associated with the specified prefix.);
receiving, from a user device, a request to retrieve a DEK of the first key set, wherein the request comprises a key attribute (Para [0072]: The encryption key processor receives a call from the interface module to a method to get keys in a key set or key set group (element 302). For example, the interface module may call the method to get the latest keys of a key set group.);
in response to the request, sending, to the user device, a first DEK of the first key set, based on determining that one or more attributes of the first DEK match the key attribute of the request (Para [0074]-[0075]. FIG. 4: When an application program needs a key, the application program specifies the key set or key set group name to which the key belongs (element 402). The application program looks in the map provided by the key manager for the desired key(s) (element 412). Then, the application program selects the desired one or more keys from the map (element 414).).
BIRK does not disclose wherein each key set comprises a plurality of managed keys corresponding to a respective service; determining whether the request is in compliance with one or more requirements of the managed key specification for the first key set; and in response to determining that the request is in compliance with the one or more requirements of the managed key specification for the first key set (perform an action).
Copparapu teaches wherein each key set comprises a plurality of managed keys corresponding to a respective service (Col 2 lines 28- 63 and Col 11 lines 11-25: the interface of the key management service processes requests to generate data key pairs by providing data key in response. Such requests can specify a key managed by the key management service (referred to as a managed key, customer managed key, master key, or customer master key) and responses to the requests can include a copy of the private key encrypted to the customer managed key. A request can be authorized by determining that the requesting client submits credentials with associated sufficient permissions to allow the data object to be reencrypted or that the client is permitted to utilize the encryption and decryption keys.)
determining whether the request is in compliance with one or more requirements of the managed key specification for the first key set (Col 2 lines 28- 63 and Col 11 lines 11-25: the interface of the key management service processes requests to generate data key pairs by providing data key in response. Such requests can specify a key managed by the key management service (referred to as a managed key, customer managed key, master key, or customer master key) and responses to the requests can include a copy of the private key encrypted to the customer managed key. A request can be authorized by determining that the requesting client submits credentials with associated sufficient permissions to allow the data object to be reencrypted or that the client is permitted to utilize the encryption and decryption keys. In an embodiment, an identity and access management service associates access control policies with key identifiers to define permissions for use of customer managed keys and determining whether fulfillment of the request is authorized can include determining if conditions of applicable access control policies are satisfied. If the client request is not authenticated, is not valid, or the requesting client is not authorized, then the key management service denies 506 the request.);
and in response to determining that the request is in compliance with the one or more requirements of the managed key specification for the first key set (perform an action) Col 2 lines 28- 63 and Col 11 lines 11-25: the interface of the key management service processes requests to generate data key pairs by providing data key in response. Such requests can specify a key managed by the key management service (referred to as a managed key, customer managed key, master key, or customer master key) and responses to the requests can include a copy of the private key encrypted to the customer managed key. A request can be authorized by determining that the requesting client submits credentials with associated sufficient permissions to allow the data object to be reencrypted or that the client is permitted to utilize the encryption and decryption keys. In an embodiment, an identity and access management service associates access control policies with key identifiers to define permissions for use of customer managed keys and determining whether fulfillment of the request is authorized can include determining if conditions of applicable access control policies are satisfied. If the client request is not authenticated, is not valid, or the requesting client is not authorized, then the key management service denies 506 the request.)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK with the teachings of Copparapu to include wherein each key set comprises a plurality of managed keys corresponding to a respective service; determining whether the request is in compliance with one or more requirements of the managed key specification for the first key set; and in response to determining that the request is in compliance with the one or more requirements of the managed key specification for the first key set (perform an action)in order to authorize the requests by executing the roles and permissions for cryptographic information used to access secured data.
BIRK in view of Copparapu does not explicitly disclose generating one or more master key encrypting keys (KEKS); storing the one or more master KEKS in a hardware security module (HSM); generating, one or more data encryption keys (DEKS), wherein the one or more DEKS are encrypted using at least one master KEK retrieved from the H.S.M.;
Ghafoor does disclose generating one or more master key encrypting keys (KEKS) (Para [0042]: customer-controlled keys and Storage provides ability to the customer to generate and keep control over the encryption keys (data encryption keys and/or master keys.);
storing the one or more master KEKS in a hardware security module (HSM) (Para [0006]. Para [0042]: store the encryption key within the HSMs, and/or retrieve the encryption key for decryption);
wherein the one or more DEKS are encrypted using at least one master KEK retrieved from the H.S.M. (Para [0031]. Para [0039]: a “Hardware Security Module (HSM)” refers to a hardware system that encapsulates the KEK or the master key and provides encryption/decryption of DEKs. For sensitive data, the objects in the object store are encrypted using a unique data encryption key (DEK) for each object. Those DEKs are stored and are themselves encrypted using a key encryption key (KEK) usually managed by a Key Management Service or a Hardware Security Module (HSM).)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu with the teachings of Ghafoor to include a generating one or more master key encrypting keys (KEKS); storing the one or more master KEKS in a hardware security module (HSM); generating, one or more data encryption keys (DEKS), wherein the one or more DEKS are encrypted using at least one master KEK retrieved from the H.S.M. in order to store the sensitive data with their key for enhancing security (Ghafoor Para [0039]).
BIRK in view of Copparapu in view of Ghafoor does not explicitly disclose sending, to a user device, the unique label.
Rich does disclose sending, to a user device, the unique label (Para [0051]-[0053]: KMIP attributes are returned from the server to the client. Attributes contain Object Group (the name of a group to which the object belongs), Object Type (the type of object, such as public key, private key, or symmetric key)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor with the teachings of Rich to include sending, to a user device, the unique label in order to securely retrieving a key (Rich Para [0074]-[0075]).
Regarding claim 4, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 1, wherein the one or more managed key specifications comprise one or more of attributes for generation of keys, exchanges of keys, storage of keys, destruction of keys, and replacement of keys (BIRK Para [0048]: The autoGenerate attribute specifies whether a replacement key will be generated to replace a key according to a schedule.).
Regarding claim 6, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 5, wherein the is one or more DEKs are created for each user in a service's key set (BIRK Para [0035]-[0038])
Regarding claim 7, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 1, wherein the one or more DEKS are segregated at a destination level, such that each service that a user of a plurality of users calls utilizes a distinct key (BIRK Para [0035]-[0038]: Attributes of a key include the name of the key set to which the key belongs. Based on the scope specified, the key set or key set group visibility for the purposes of isolation.).
Regarding claim 9, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 1, wherein the one or more managed key specifications comprise a rotation policy (BIRK Para [0037]: New keys can be generated by calling key generator 206 according to a schedule implemented by a scheduler 208. Scheduler 208 determines a time for a next key generation event according to a frequency specification received from key manager 202. When time arrives for a key generation event, scheduler 208 causes the key generator 206 to generate new keys, and notifies key manager 202 of the event.).
Regarding claim 10, BIRK in view of Copparapu in view of Ghafoor in view of Rich and in view of Jahid teaches the computer-implemented method of claim 9, wherein the rotation policy specifies a validity period and a rotation interval (BIRK Para [0037]).
As per claim 13, the claim claiming a computing system essentially corresponding to computer-implemented method claim 1 above, and they are rejected, at least for the same reasons.
As per claim 16, the claim claiming the computing system essentially corresponding to computer-implemented method claim 4 above, and they are rejected, at least for the same reasons.
As per claim 17, the claim claiming a non-transitory computer-readable storage medium essentially corresponding to computer-implemented method claim 1 above, and they are rejected, at least for the same reasons.
As per claim 19, the claim claiming the non-transitory computer-readable storage medium essentially corresponding to computer-implemented method claim 6 above, and they are rejected, at least for the same reasons.
Claims 2, 3, 14, 15 are rejected under 35 U.S.C. 103 as being unpatentable over BIRK (US 20080101610 A1) in view of Copparapu (US 11671251 B1) in view of Ghafoor (US 20220343010 A1) in view of Rich (US 20130044882 A1) in view of Sah (US 20220179972 A1).
Regarding claim 2, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 1, further comprising:
BIRK in view of Copparapu in view of Ghafoor in view of Rich does not explicitly disclose receiving an update to one of the one or more managed key specifications; and
updating at least one of the one or more managed key specifications based on the update.
Sah does disclose receiving an update to one of the one or more managed key specifications (Para [0031]. Para [0037], a cryptography service instance can support a request to update a data key. A request to update a data key can be utilized to update one or more preferences, compute regions, and the like of an encrypted data key structure. A request to update a data key can comprise parameters such as a KeyID parameter, an updated preferences parameter, an updated compute regions parameter, and an encrypted data key structure parameter.); and
updating at least one of the one or more managed key specifications based on the update (Para [0037]. Para [0038], upon receipt of a request to update a data key, a cryptography service instance can obtain an encrypted data key structure of the request and update encrypted data keys and regions, and preferences of the encrypted data key structure based at least in part on a KeyID parameter, an updated preferences parameter, and an updated compute regions parameter of the request to determine an updated data structure (e.g., an updated encrypted data key structure) comprising updated encrypted data keys and regions and updated preferences, and provide the updated data structure in response to the request. A cryptography service instance can update preferences of an encrypted data key structure by replacing the preferences of the encrypted data key structure with preferences indicated by an updated preferences parameter.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor in view of Rich with the teachings of Sah to include receiving an update to one of the one or more managed key specifications; and updating at least one of the one or more managed key specifications based on the update in order to update preferences of an encrypted data key structure by replacing the preferences of the encrypted data key structure with preferences indicated by an updated preferences parameter.
Regarding claim 3, BIRK in view of Copparapu in view of Ghafoor in view of Rich and in view of Sah teaches the computer-implemented method of claim 2, wherein the update is received from an internal user through an internal gateway (Sah Para [0019]. Para [0021], clients can submit appropriately configured API requests to a cryptography service instance through one or more web service interfaces. Para [0037]- [0038].), wherein the internal user has access to an application programming interface (API) (Sah Para [0019]. Para [0021], clients can submit appropriately configured API requests to a cryptography service instance through one or more web service interfaces.) configured to update a key specification (Sah Para [0031]. Para [0037], a cryptography service instance can support a request to update a data key. A request to update a data key can be utilized to update one or more preferences, compute regions, and the like of an encrypted data key structure. A request to update a data key can comprise parameters such as a KeyID parameter, an updated preferences parameter, an updated compute regions parameter, and an encrypted data key structure parameter.).
As per claim 14, the claim claiming the computing system essentially corresponding to computer-implemented method claim 2 above, and they are rejected, at least for the same reasons.
As per claim 15, the claim claiming the computing system essentially corresponding to computer-implemented method claim 3 above, and they are rejected, at least for the same reasons.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over BIRK (US 20080101610 A1) in view of Copparapu (US 11671251 B1) in view of Ghafoor (US 20220343010 A1) in view of Rich (US 20130044882 A1), in view of Kim (US 20200366467 A1).
Regarding claim 8, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the computer-implemented method of claim 1.
BIRK in view of Copparapu in view of Ghafoor in view of Rich does not explicitly disclose further comprising: generating a managed key that is shared by a plurality of users, wherein the managed key is created with a plurality of access policies granting access to each respective user of the plurality of users.
Kim does disclose further comprising: generating a managed key that is shared by a plurality of users, wherein the managed key is created with a plurality of access policies granting access to each respective user of the plurality of users (Para [0007]- [0008]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor in view of Rich with the teachings of Kim to include further comprising generating a new key for each user of a plurality of users, wherein keys are segregated at a user level where each user of the plurality of users utilizes a distinct key in order to generating the share of each of the user and the plurality of other users for the secret key of the user.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over BIRK (US 20080101610 A1) in view of Copparapu (US 11671251 B1) in view of Ghafoor (US 20220343010 A1) in view of Rich (US 20130044882 A1), in view of Montilla Lugo (US 11750566 B1).
Regarding claim 11, BIRK in view of Copparapu in view of Ghafoor in view of Rich and in view of Jahid teaches the computer-implemented method of claim 9.
BIRK in view of Copparapu in view of Ghafoor in view of Rich in view of Jihad does not explicitly disclose wherein a managed key is not subject to the rotation policy conditionally based on a key attribute of the managed key
Montilla Lugo does disclose wherein a managed key is not subject to the rotation policy conditionally based on a key attribute of the managed key (Col 7 lines 53-54, DisableKeyRotation— disables automatic rotation of the key material for the specified symmetric CMK. Wherein to disable key rotation for specific key needs to specify its ID as an input for the rotation disabling function.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor in view of Rich in view of Jihad with the teachings of Montilla Lugo to include wherein a managed key is not subject to the rotation policy conditionally based on a key attribute of the managed key in order disables automatic rotation of the key material for the specified symmetric CMK.
Regarding claim 12 BIRK in view of Copparapu in view of Ghafoor in view of Rich in view of Jihad in view of Montilla Lugo teaches the computer-implemented method of claim 11, wherein the key attribute is one of a key ID, key type, or use attribute (Montilla Lugo Col 7 lines 53-54, DisableKeyRotation— disables automatic rotation of the key material for the specified symmetric CMK. Wherein to disable key rotation for specific key needs to specify its ID as an input for the rotation disabling function.).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over BIRK (US 20080101610 A1) in view of Copparapu (US 11671251 B1) in view of Ghafoor (US 20220343010 A1) in view of Rich (US 20130044882 A1), in view of Zhang (US20130275752A1), in view of Jahid (US 20180063103 A1).
Regarding claim 20, BIRK in view of Copparapu in view of Ghafoor in view of Rich teaches the non-transitory computer-readable storage medium of claim 17.
BIRK in view of Copparapu in view of Ghafoor in view of Rich does not explicitly disclose wherein keys are segregated at a destination level, such that each service that a user of a plurality of users calls utilizes a distinct key.
Zhang does disclos wherein keys are segregated at a destination level, such that each service that a user of a plurality of users calls utilizes a distinct key (Para [0005]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor in view of Rich with the teachings of Zhang to include wherein keys are segregated at a destination level, such that each service that a user of a plurality of users calls utilizes a distinct key in order to encrypt the dataset associated with a client with a corresponding plaintext dataset using a unique, client-specific encryption key.
BIRK in view of Copparapu in view of Ghafoor in view of Rich in view of Zhang does not explicitly disclose the one or more managed key specifications comprise a rotation policy, and the rotation policy specifies a validity period and a rotation interval.
Jahid does disclose the one or more managed key specifications comprise a rotation policy, and the rotation policy specifies a validity period and a rotation interval (Para [0005]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of BIRK in view of Copparapu in view of Ghafoor in view of Rich and in view of Zhang with the teachings of Jahid to include the one or more managed key specifications comprise a rotation policy, and the rotation policy specifies a validity period and a rotation interval in order to limit the risk of compromising an old key and prevent unauthorized access to the network.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUDY BAZNA whose telephone number is (703)756-1258. The examiner can normally be reached Monday - Friday 08:30 AM-05:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739. 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.
/JUDY BAZNA/Examiner, Art Unit 2495
/PONNOREAY PICH/Primary Examiner, Art Unit 2495