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 .
This communication is in response to the arguments/amendments filed on 02/23/2026. Claims 1, 3-15, and 18-19 are currently pending.
Response to Arguments
Applicant's arguments filed 02/23/2026 have been fully considered. However, the allowability of the application cannot be determined because the independent claims 1 and 15 have 101 issues as a result of the amendments.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-15, and 18-19 are rejected under 35 U.S.C. 101 because the claimed invention lacks patentable utility. Independent claim 1 recites requesting by the first client the symmetric key from the first server and the encrypted private key of the first client from the second server and decryption by the first client of the encrypted private key of the first client using the symmetric key.
However, it is noted that first client has the possession of its private key and the symmetric key used to encrypt the private key was generated by the first client from its private key and public key of the first server. The encrypted private key was transmitted to the second server for storage.
One of ordinary skill in the art would find it difficult to understand the utility behind the first client requesting for the symmetric key it generated from the first server and the encrypted private from the second server. The symmetric that was sent to the first server and the private encrypted key that was transmitted to the second server were not utilized for any function. Thus, the utility of the first client merely requesting for symmetric key and encrypted private key from first and second servers respectively and used the symmetric key to decrypt its encrypted private key is not understood, moreover, the first client is in possession of those keys.
Independent claim 15 also recites similarly the same limitation as recited in claim 1 and rejected under 101. All dependent claims on either claim 1 or 15 including claim 9 that was previously allowed are also rejected under 35 U.S.C. 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 15 are rejected under 35 U.S.C. 103 as being unpatentable over USPGPub. No 20230231712 to Liu; Zhan (hereinafter Liu) in view of US. Pat. No. 10819522 to Roy et al. (hereinafter Roy) and further in view of USPGPub. No. 20220255732 to DOHERTY et al. (hereinafter DOHERTY) and further in view of US.PGPub. No. 20220014354 to VALLADOLID et al. (hereiafter VALLADOLID).
Regarding claim 15, Liu discloses a system for securing a private key of a client (¶0034, “… a private key of an ECDH key-pair can be stored securely…), comprising:
a client (FIG. 2, client),
a first server (FIG. 2, server),
wherein the client is set up to request a public key of the first server (¶0020, “…issuing, by a client device to a server, a request to establish a secure connection; receiving, by the client device, a response to the request to establish a secure connection from the server, the response including a digital certificate associated with a public key stored by the server, the public key used to establish a symmetric key…”);
wherein the first server is set up to transmit the public key of the first server to the client (¶0020, “…receiving, by the client device, a response to the request to establish a secure connection from the server, the response including a digital certificate associated with a public key stored by the server, the public key used to establish a symmetric key…”);
wherein the client is further set up to generate a symmetric key from the private key of the client and the public key of the first server based Elliptic-curve Diffie-Hellman (ECDH) and Advance Encryption Standard (AES) algorithms (¶0020, “… computing (generating), by the client device, a shared secret (symmetric key as in ¶0007) using the public key stored by the server and a private key generated by the client device.”), (¶0013, “…Specifically, a server device stores an Elliptic-Curve Diffie-Hellman (ECDH) public-private key pair and generates and/or stores a digital certificate for the ECDH key pair. When responding to a ClientHello, or similar message, the server includes the ECDH certificate instead of an ECDSA certificate (or similar certificate). The client can then use the ECDH certificate to obtain the public ECDH key of the server. The ECDH certificate can also function as a digital signature of the server. The client can then use the ECDH public key of the server to generate a symmetric key, and the server can also independently generate the same symmetric key.”)
However, Liu even though discloses Elliptic-curve Diffie-Hellman (ECDH) and Advance Encryption Standard (AES) algorithms which are used with key derivation function in ¶0013 and ¶0050, to generate key pair, does not explicitly disclose the limitation of:
generation of key based on a key derivation function,
encryption of the private key of the first client with the symmetric key, and to transmit the encrypted private key of the client to a second server;
wherein the second server is set up to store the encrypted private key of the client.
and wherein the client is further set up for requesting of the symmetric key from the first server and the encrypted private key of the client from the second server, as well as for decryption of the encrypted private key of the client by means of the symmetric key.
Roy discloses key generation based on a key derivation function (KDF) (Coln.11, lines 36-67-Coln.12, lines 1-13, “… The application may generate an encryption key (e.g., a master key) by applying a password key stretching algorithm (e.g., PBKDF2 with HMAC-SHA256) to the passphrase. Specifically, the application may apply the key stretching algorithm to the passphrase, a salt, and an iteration count to produce a 256-bit encryption key. For example, PBKDF2 may use a cryptographic hash, such as SHA-2, a longer salt (e.g. 64 bits) and a high iteration count (e.g., 1,000,000 rounds of hashing)… The encryption key derived from the passphrase may be an AES (advanced encryption standard) symmetric key…”),
encryption of the private key of the first client with the symmetric key, and transmission of the encrypted private key of the first client to a second server (Coln.11, lines 55-67-Coln.12, lines 1-34, FIG. 2, “The encryption key derived from the passphrase may be an AES (advanced encryption standard) symmetric key. The application may use the encryption key to encrypt the user's private keys (and/or any other sensitive information)…The client device may transmit the encrypted private key to the analytic server…”);
wherein the second server is set up to store the encrypted private key of the client (Coln.12, lines 14-34, “...The analytic server may also store the encrypted private key and the series of encrypted security questions into a database as a back-up retrieval system…”), (Coln.12, lines 30-56, “…The application may transform the passphrase into an encryption key and use the encryption key to encrypt a private key. The application may transmit the encrypted private key to the analytic server 110. The analytic server 110 may store the encrypted private key into the database 110A.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of Liu to include encrypting the private key of a user with a symmetric key as disclosed by Roy and be motivated in doing so in order to protect the private key from being stolen by a malicious actor and more so symmetric encryption is very efficient and easily implemented-Roy Coln.11, lines 55-67-Coln.12, lines 1-34 in parts.
However, Liu in view of Roy does not explicitly disclose the following limitation:
and wherein the client is further set up for requesting of the symmetric key from the first server and the encrypted private key of the client from the second server, as well as for decryption of the encrypted private key of the client by means of the symmetric key.
DOHERTY discloses and wherein the client is further set up for requesting of the symmetric key from the encrypted content management module and the encrypted private key of the client from the encrypted content management module (¶0033, “…The method also includes decrypting, with the client module, the user escrow key with the symmetric encryption key to obtain the user private key…The method also includes requesting and receiving, with the client module, the escrow key (encrypted user private key) from the encrypted content management module…The method also includes requesting and receiving, with the client module, the encrypted content symmetric key and the ephemeral public key from the encrypted content management module”), (¶0116, “the functionality of the module may be distributed among multiple modules that are connected via the communications system. For example, multiple modules may implement the same functionality distributed by a load balancing system…”, wherein any of the encrypted content management modules being implemented by a server 200 disclosed in ¶0065 can be labelled as first or second server), as well as for decryption of the encrypted private key of the client by means of the symmetric key (¶0011, “…The method also includes decrypting, with the client module, the user escrow key with the symmetric encryption key to obtain the user private key…”).
Thus, one of ordinary of ordinary skill in the art would have found it obvious before the effective filing date of the applicant’s claimed invention to modify the method of Liu and Roy in claim 15 to include decryption by the first client of the encrypted private key of the first client using the symmetric key as disclosed by DOHERTY and be motivated in doing so in order to obtain the user private key-DOHERTY ¶0011 in parts.
However, the combination of Liu, Roy, and DOHERTY does not explicitly disclose using plurality of servers to store different keys.
VALLADOLID discloses using plurality of servers to store different cryptographic keys (¶0109, “send a request to each of a plurality of servers, wherein each of the plurality of servers is configured to store a different share of the cryptographic key and to partially action the digital object using the stored share of the cryptographic key and provide a partially actioned digital object to the end user, the request comprising proof of predefined conditions being satisfied;”). See also ¶0105, ¶0258, and ¶0072.
Thus, one of ordinary of ordinary skill in the art would have found it obvious before the effective filing date of the applicant’s claimed invention to modify the system of Liu, Roy, and DOHERTY by implementing storing of symmetric key and encrypted private key in different servers as disclosed by VALLADOLID and be motivated in doing so in order to maximize both system performance and security through key protection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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 at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
