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 .
DETAILED ACTION
1. This action is in response to the amendment and argument field on 26 January 2026.
2. Claims 8-27 remain Pending and Rejected.
Double Patenting
3. Double patenting rejection remain rejected until the terminal declaimer approved.
Responses to the Argument
4. The applicant’s arguments filed on 26 January 2026 have been fully considered but they are not persuasive. In the Remarks, the applicant has argued in substance:
Response:
Examiner respectfully disagrees, because, based on claim limitation there are two selection process and data transmission process which are taught by the prior arts of record. First, Sha discusses selection of policy (access control policy) based on data/type and second, selection of key management server (KMS) to retrieve key from across multiple geographical regions based on API call, please see Sah. which is same as the claim. Therefore, combination of Sah and Yi teaches the claim limitation. Also, mechanism of Re-Keying clearly taught by Perlman. Please see prior rejection.
Claim Rejections - 35 USC § 103
5. 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-19 and 21-27 are rejected under 35 U.S.C §103 as being unpatentable over Sah, Divyesh. (US Publication No. 20220179972), hereinafter Sah and in view of Zhoucheng Yi (WO Publication No. 2019227557), hereinafter Yi.
Regarding claim 8:
Sah does not explicitly teaches, receiving an encryption request from a first server that includes a data type indication and an identifier for one or more users; however, in a same field of endeavor Yi discloses this limitation (Yi, page 8, para.5-6).
selecting a security management policy from a set of security management policies stored in a data structure based on the identifier and based on the data type indication (Sah, ¶28).
selecting a key management server based on the selected security management policy (Sah, ¶38, ¶94).
transmitting a request for a data encryption key to the selected key management server (Sah, ¶48-49, ¶71).
receiving a plaintext key and an encrypted key from the selected key management server (Sah, ¶81, ¶83).
and in response to the encryption request, transmitting the plaintext key to the first server (Sah, ¶18, Fig.8).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of key management of Sah with the sending encryption request to a sever disclosed in Yi to prevent key leakage and improve security of key management, stated by Yi at page 12, para. 8.
Regarding claim 9:
wherein the encryption request includes a role indication for a user associated with the identifier, and the security management policy is selected based on the role indication (Sah, ¶113).
Regarding claim 10:
wherein the encryption request includes a data label, and the security management policy is selected based on the data label (Sah, ¶14, ¶28).
Regarding claim 11:
wherein the selected key management server is a cloud server (Sah, ¶15).
Regarding claim 12:
wherein the selected key management server is a hardware security module (Sah, ¶19).
Regarding claim 13:
wherein the selected key management server is in a customer cloud (Sah, ¶41).
Regarding claim 14:
comprising executable instructions that, when executed by a processor, facilitate performance of operations, comprising: selecting a database server based on the selected security management policy; and storing encrypted data, which has been encrypted using the plaintext key, in the selected database server (Sah, ¶38, ¶94).
Regarding claim 15:
15. (Original) The non-transitory computer-readable storage medium of claim 14, wherein the selected security management policy includes a pointer and credentials that are used to select the database server and store the encrypted data in the selected database server (Sah, ¶14).
Regarding claim 16:
comprising executable instructions that, when executed by a processor, facilitate performance of operations, comprising: determining a context identifier based on the encryption request; and storing the encrypted key in a record associated with the context identifier (Sah, ¶27).
Regarding claim 17:
wherein the record associated with the context identifier includes data identifying the selected key management server (Sah, ¶38, ¶94).
Regarding claim 18:
comprising executable instructions that, when executed by a processor, facilitate performance of operations, comprising: receiving a decryption request including the context identifier; accessing the encrypted key in the record associated with the context identifier; determining the plaintext key based on the encrypted key; and transmitting the plaintext key in response to the decryption request (Sah, ¶81, ¶83).
Regarding claim 19:
wherein determining the plaintext key based on the encrypted key comprises: transmitting the encrypted key to the selected key management server; and receiving the plaintext key from the selected key management server (Sah, ¶48-49, ¶71).
Regarding claim 21:
Sah does not explicitly teaches, receiving an encryption request from a first server that includes a data type indication and an identifier for one or more users; however, in a same field of endeavor Yi discloses this limitation (Yi, page 8, para.5-6).
selecting a security management policy from a set of security management policies stored in a data structure based on the identifier and based on the data type indication (Sah, ¶28).
selecting a key management server based on the selected security management policy (Sah, ¶38, ¶94).
transmitting a request for a data encryption key to the selected key management server (Sah, ¶48-49, ¶71).
receiving a plaintext key and an encrypted key from the selected key management server (Sah, ¶81, ¶83).
and in response to the encryption request, transmitting the plaintext key to the first server (Sah, ¶18, Fig.8).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of key management of Sah with the sending encryption request to a sever disclosed in Yi to prevent key leakage and improve security of key management, stated by Yi at page 12, para. 8.
Regarding claim 22:
wherein the encryption request includes a role indication for a user associated with the identifier, and the security management policy is selected based on the role indication (Sah, ¶113).
Regarding claim 23:
wherein the encryption request includes a data label, and the security management policy is selected based on the data label (Sah, ¶14, ¶28).
Regarding claim 24:
comprising: selecting a database server based on the selected security management policy; and storing encrypted data, which has been encrypted using the plaintext key, in the selected database server (Sah, ¶38, ¶94).
Regarding claim 25:
a network interface (Sah, ¶12).
a processor, and a memory, wherein the memory stores instructions executable by the processor to (Sah, ¶41).
Sah does not explicitly teaches, receiving an encryption request from a first server that includes a data type indication and an identifier for one or more users; however, in a same field of endeavor Yi discloses this limitation (Yi, page 8, para.5-6).
selecting a security management policy from a set of security management policies stored in a data structure based on the identifier and based on the data type indication (Sah, ¶28).
selecting a key management server based on the selected security management policy (Sah, ¶38, ¶94).
transmitting a request for a data encryption key to the selected key management server (Sah, ¶48-49, ¶71).
receiving a plaintext key and an encrypted key from the selected key management server (Sah, ¶81, ¶83).
and in response to the encryption request, transmitting the plaintext key to the first server (Sah, ¶18, Fig.8).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of key management of Sah with the sending encryption request to a sever disclosed in Yi to prevent key leakage and improve security of key management, stated by Yi at page 12, para. 8.
Regarding claim 26:
wherein the encryption request includes a role indication for a user associated with the identifier, and the security management policy is selected based on the role indication (Sah, ¶113).
Regarding claim 27:
wherein the encryption request includes a data label, and the security management policy is selected based on the data label. (Sah, ¶14, ¶28).
6. Claim 20 is rejected under 35 U.S.C §103 as being unpatentable over Sah in view of Yi and in view of Perlman et al. (US Publication No. 20210377016), hereinafter Perlman.
Regarding claim 20:
Sah in view of Yi does not explicitly suggest, receiving a re-keying request; determining a set of one or more context identifiers based on the re-keying request, wherein the set of one or more context identifiers includes the context identifier ;identifying a next key management server based on the re-keying request; responsive to the re-keying request, determining the plaintext key based on the encrypted key using the selected key management server; determining a new encrypted key based on the plaintext key using the next key management server; storing the new encrypted key in a record associated with the context identifier; and deleting the encrypted key and the plaintext key; however, in a same field of endeavor Perlman discloses this limitation ( Perlman, ¶35, ¶39, ¶33, ¶63-64).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of key management of Sah in view of Yi with the use re-keying method disclosed in Perlman to generate new key version for extra layer of security, stated by Perlman at ¶31.
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (in USA or CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights