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 filed in parent Application No. KR10-2024-0046029, filed on04/04/2024.
DETAILED ACTION
This Office Action is in response to a Non-Provisional Patent Application received on 04/03/2025. In the application, claims 1-15 have been received for consideration and have been examined.
Specification
Applicant’s submitted specification has been reviewed and found to be in compliance.
Drawings
Applicant’s submitted drawings have been reviewed and found to be in compliance.
Claim Objections
Claim 4 objected to it because of the following informalities:
Claim 4 mention double commas at the end of third limitation “in response to execution of the ESM API and the ESM,,”. This appears to be typographical mistake. Appropriate correction is required.
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.
Claim(s) 1, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Parann-Nissany., (US9660801B2) in view of Ho et al., (US7639819B2).
Regarding claim 1, Parann discloses:
a computer-implemented key-management system operating in an as-a-service environment and including servers/cloud instances communicating with applications and key-management components. Parann explains that end customers each have respective master keys and that the master keys are protected using homomorphic encryption such that they remain encrypted even while in use.
Regarding the claimed homomorphically encrypted master key corresponding to an application device, Parann teaches that customer premises include customer-scoped master keys provided in homomorphically encrypted form to the VPD library as needed, while encryption agents provide data encryption for applications and interface with the VPD library through REST API 84. Parann, Fig. 6.
More specifically, Parann teaches in connection with Fig. 7 that:
PVKM B selects an ElGamal key different for each customer and stores secret half-key SKj, wherein index j identifies the customer;
the corresponding public key PKj is provided to cloud instance i;
instance i encrypts service-provider master key K and customer master key kj; and
using Homomorphic property, the instance produces combined master key Kj, which remains homomorphically encrypted and is never revealed.
See Parann, Fig. 7, Block Steps 90–102.
Regarding “index information for the master key,” Parann expressly states:
“Instance i therefore holds a vector of combined, encrypted master-key values Kj indexed by j.”
See Parann, Fig. 7, Block Steps 98–100.
Thus, Parann teaches both a homomorphically encrypted master key and corresponding index information.
Regarding storing the master key and index information, Parann's instance maintains the vector of encrypted master-key values indexed by j, generates and stores random mask maski, performs a homomorphic operation on the encrypted master key, and communicates with the key-management server. See Fig. 7, Block Steps 98–106.
To the extent Parann does not expressly teach providing the master-key index to the application device, Ho patent teaches exactly the conventional identifier/handle mechanism for an externally maintained master key.
Ho patent teaches requesting an ESM to generate a random master key (step 202), flagging the key non-exportable (step 204), and returning to the database a handle for the master key to facilitate referencing the master key (step 206). See Fig. 2.
It would have been obvious to provide Parann's customer/key index j, or an equivalent handle as taught by Ho reference, to the requesting application so that the application could subsequently identify the appropriate protected master key when requesting cryptographic processing. Such use constitutes the known technique of identifying remotely maintained cryptographic keys by handles rather than exposing the keys themselves.
Accordingly, claim 1 is rendered obvious by Parann in view of Ho reference.
Regarding claim 14, the combination of Parann discloses:
Parann teaches customer-specific homomorphically encrypted master keys and maintains a vector of encrypted master-key values Kj indexed by j.
Ho teaches generating a random master key within an ESM and providing a handle corresponding to the master key to the requesting database/application so that the master key can subsequently be referenced. See Fig. 2, steps 202–206.
Ho further teaches subsequently receiving a wrapped subordinate key and requested data operation and using the protected master/subordinate-key hierarchy to perform the requested cryptographic processing.
It would have been obvious to use Parann’s index j in the manner of the Ho's master-key handle so that an application could identify the appropriate homomorphically protected master key when subsequently requesting cryptographic processing.
Regarding claim 15, the combination of Parann and Ho discloses:
Ho teaches randomly generating the master key → retaining the master key in ESM → generating a handle identifying the master key → returning the handle to the requesting system.
Parann teaches the corresponding master-key information maintained in homomorphically encrypted form, with encrypted master-key values indexed by j.
Bitar teaches encrypting inputs before HE processing and subsequently homomorphically decrypting encrypted results. It also teaches generating cryptographic material using a cryptographic random-number generator and generating an HE key package containing sk, pk, and ek.
Thus, it would have been obvious to protect key-generation parameters and resulting key-identification information while crossing the encrypted-processing boundary.
Claim(s) 2-13 are rejected under 35 U.S.C. 103 as being unpatentable over Parann-Nissany., (US9660801B2) in view of Ho et al., (US7639819B2) and further in view of Bitar et al., (US20240223355A1).
Regarding claim 2, the combination of Parann and Ho discloses:
The server device of claim 1 requires an encrypted security module (ESM) performing operations in homomorphically encrypted form and an ESM API through which the application device interacts with the ESM.
Ho reference expressly teaches an External Security Module (ESM) 104, wherein master key 114 remains within ESM 104. The ESM generates keys, encrypts subordinate keys using the master key, decrypts wrapped keys, and, in one operating mode, performs the actual encryption/decryption operation entirely within ESM 104. See Figs. 2–4B.
Parann modifies this conventional secure-module/key-management architecture by using homomorphic key management, expressly teaching that the master keys remain encrypted even while in use and that homomorphic operations are performed upon encrypted master-key values. See Parann Fig. 7, particularly Block Steps 97–106.
Parann additionally teaches that encryption agents for the applications interface to the VPD library through REST API 84.
Thus, Parann itself supplies strong support for the claimed API relationship.
Regarding the additional HE functionality, Bitar teaches a KMS specifically configured to manage homomorphic-encryption keys. Bitar teaches generating a key seed associated with an authenticated user, generating an HE key package containing:
secret key sk;
public key pk; and
evaluation key ek.
See Bitar, Fig. 4 and associated registration process.
Bitar further teaches that the user encrypts private data using pk, supplies the encrypted data for computation, the cloud performs the desired computation using evaluation key ek, and the resulting encrypted computation result is subsequently decrypted using secret key sk.
It would have been obvious to incorporate Bitar's known HE input/output processing into Parann's API-accessible homomorphic key-management environment and Ho patent's ESM architecture so that application data supplied to the secure processing environment remains protected during processing.
Regarding claim 3, the combination of Parann, Ho and Bitar discloses:
Ho reference expressly teaches that the system sends a request to ESM 104 to create a random key to be used as the master key, flags the key non-exportable, and returns a handle identifying the master key. See Fig. 2, steps 202–206.
Parann teaches performing master-key processing in the homomorphically encrypted domain and maintaining the resulting encrypted master keys indexed by j. See Fig. 7, Block Steps 97–106.
Bitar teaches encrypting sensitive inputs before encrypted-domain processing and decrypting encrypted computation results after the HE processing. In particular, Bitar teaches:
Ed = HEEnc(pk,data)
followed by evaluation over the encrypted data and ultimately:
mres = HEDec(sk,cres).
Bitar also teaches generating a key seed using a cryptographic random-number generator, with the key seed having a specified size (e.g., at least 256 bits), and using the seed to generate the HE key package.
It would have been obvious to protect the key-generation parameters transmitted across the HE boundary in the same manner Bitar protects other sensitive inputs and to return the generated key's identifier after processing, particularly where Parann seeks to prevent exposure of key-management information and the Ho reference already returns a handle corresponding to the generated master key.
Regarding claim 4, the combination of Parann, Ho and Bitar discloses:
requires generating a data key, identifying the master key from index information, and encrypting/wrapping the data key using the master key.
Ho teaches:
generating a random number in ESM 104 for use as a column/data key — step 302;
encrypting the column key with master key 114 inside ESM 104 — step 304;
returning the resulting wrapped column key — step 308; and
storing the wrapped key in metadata — step 310.
See Fig. 3A.
In the ESM-only implementation, the ’819 patent similarly generates a random column key within ESM 104, flags the key as sensitive/exportable, wraps the key using master key 114, and returns the wrapped key. See Fig. 3B, steps 320–326.
Ho also teaches identifying the master key by the previously returned handle. See Fig. 2, step 206.
Parann teaches maintaining corresponding master keys in homomorphically encrypted form, indexed by j.
It would therefore have been obvious to perform the ’819 patent's known master-key/data-key hierarchy using Parann's homomorphically protected master key so that the master key remains protected during the subordinate-key generation/wrapping process.
Regarding claim 5, the combination of Parann, Ho and Bitar discloses:
a different key-generation parameter/type, Ho teaches random generation of subordinate cryptographic keys by ESM 104 and protection of those keys using master key 114.
Bitar further teaches generating different cryptographic key types as part of an HE package—specifically secret key sk, public key pk, and evaluation key ek.
It would have been obvious for a secure key-generation API to accept the desired cryptographic key type as a generation parameter so that the appropriate key could be generated by the secure module.
Regarding claim 6, the combination of Parann, Ho and Bitar discloses:
Bitar directly teaches generating an HE key package comprising:
secret key sk; public key pk; and evaluation key ek.
See Bitar's registration process.
Bitar further teaches associating the HE key information with a particular authenticated user, storing the encrypted seed and public/evaluation keys, retrieving the public key associated with the user, using pk for encryption, using ek to evaluate a function over encrypted data, and regenerating sk for decryption.
Parann independently teaches indexed customer-specific cryptographic information, wherein index j denotes the corresponding end customer and encrypted master-key values are maintained indexed by j.
It would have been obvious to assign an identifier/index to Bitar's HE key package in a multi-user KMS, consistent with Parann's indexed key-management architecture, to allow retrieval of the HE key set belonging to a particular application/user.
Bitar further teaches making pk and ek available for runtime use while protecting sk; thus, transmitting appropriate public/operation-key information to the application follows directly from Bitar's intended operation.
The subject matter of claim 7 is taught by the combination of Parann, Ho and Bitar.
Regarding claim 8, the combination of Parann, Ho and Bitar discloses:
Ho expressly teaches the reverse side of the key-wrapping process. Database 102 sends the wrapped column key to ESM 104; ESM 104 decrypts the wrapped column key and either returns the clear-text column key to the database or uses the unwrapped column key internally to perform encryption/decryption. See Fig. 4A, steps 402–410, and Fig. 4B, steps 412–418.
Thus, Ho teaches:
master key → unwrap subordinate/data key → use subordinate key for cryptographic operation.
For the claimed HE secret-key embodiment, Bitar teaches recovering the encrypted key seed Es, having the KMS decrypt it to recover seed s, regenerating secret HE key sk from the recovered seed, and using sk to decrypt encrypted result cres. See Bitar, steps 432–434.
Parann supplies the teaching that the corresponding master-key/key-management information can remain homomorphically protected and be identified according to customer/index j.
It would have been obvious to combine the known subordinate-key recovery mechanism of the Ho reference with Parann/Bitar's homomorphic key-management architecture to recover the appropriate subordinate/secret key while maintaining the master-key information in protected form.
The subject matter of claim 9 is taught by the combination of Parann, Ho and Bitar.
The subject matter of claim 10 is taught by the combination of Parann, Ho and Bitar.
Regarding claim 11, the combination of Parann, Ho and Bitar discloses:
For the encryption/decryption portions, the ’819 patent expressly teaches an ESM receiving a wrapped key and data to be encrypted/decrypted, unwrapping the key, performing the encryption/decryption operation inside ESM 104, and returning the resulting encrypted/decrypted data. See Fig. 4B, steps 412–418.
Bitar teaches the corresponding HE workflow: encrypting private data using pk, performing computation over the encrypted data using evaluation key ek, receiving an encrypted computation result, regenerating secret key sk, and decrypting the result.
Parann teaches delivering a specific customer/resource key to an application server without exposing that key to the intermediate key-management components. See Parann Fig. 9; Parann explains that the specific key may be delivered to the application while the PVKM/VPD library does not learn the key.
For claim 12's electronic-signature limitation, the current combination strongly supports encryption, decryption and protected key retrieval.
The subject matter of claim 13 is taught by the combination of Parann, Ho and Bitar.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6: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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
Prosecution Insights