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). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The drawings filed on 06/06/2025 are accepted.
Specification
The specification filed on 06/06/2025 is accepted.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/06/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 9 recites, “A secure file storage system, comprising a user terminal, an interface server, a key server and a file server”. Under the broadest reasonable interpretation (BRI) consistent with the Specification, the recited “user terminal,” “interface server,” “key server,” and “file server” can all be implemented as software. The claimed invention is directed to non-statutory subject matter, software per se.
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.
Claims 1, 3-4, 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Roth et al. (hereinafter Roth) US 2015/0089244 A1 in view of Sirota et al. (hereinafter Sirota) US 11,095,620 B1.
Regarding claim 1, Roth teaches a secure file storage method [0078], performed by a user terminal, an interface server, a key server and a file server (Fig. 1, customer 102, service provider 106 and data storage system 114; Fig. 2, customer interface 202, authentication system 208 and request processing infrastructure 212 with data storage systems 214; Fig. 13 Key management system 1310 separate from the provider 1306 [0024-0026], [0032-0036])
transmitting, by the user terminal, a first request to the interface server to instruct the interface server to verify a signature in the first request by using the public signature key and then to randomly generate a plaintext file key (Fig. 2, request 204 received with signature 206 at customer interface 202 and verified by authentication system 208, the signature generated by the customer with private key of an asymmetric signature keypair; Fig. 5, steps 502-504; Fig. 7, steps 702-704 and step 10, an encryption key generated by the provider once the request is determined to be fulfilled [0033-0034], [0044-0045], [0049]);
encrypting, by the interface server, the plaintext file key with the public code key to generate a ciphertext file key (Fig. 6 request 600 carrying customer public key 602; Fig. 7, step 714, the encryption key wrapped with the customer public key so that it is decryptable only with the corresponding private key [0048-0049]);
storing, by the interface server, the ciphertext file key into the key server (the encrypted encryption key is stored by the provider, e.g., with the encrypted data [0052]; Fig. 13-14, key management system 1310 that manages cryptographic keys on behalf of the provider’s customers and to which wrapped keys are transmitted [0061-0063];
transmitting, by the interface server, the ciphertext file key to the user terminal (Fig. 7, step 718, response to the request including the encrypted encryption key [0053-0054];
using, by the user terminal, the private code key to decrypt the ciphertext file key to obtain the plaintext file key (Fig. 8 steps 802-804, the customer decrypts the wrapped key with the private key corresponding to the public key used to wrap it [0053-0054];
using, by the user terminal, a secure protocol to transmit the plaintext file key and a file to the file server (Fig. 1, request 104 carrying data 108 organized as a file together with cryptographic key 110 in plaintext form; Fig. 3, symmetric key 302 carried in the request under transport layer security; Fig. 8, steps 806-808, request generated with the decrypted encryption key [0025], [0038], [0054];
encrypting, by the file server, the file according to the plaintext file key to generate an encrypted file (Fig. 1, the provider system that receives request 104 encrypts data 108 with key 110 to produce encrypted data 112 fir the data storage system 114, which may be a separate system from the request-receiving provider, including one operated by a third party [0025-0026], [0036], [0046]);
and storing, by the file server, the encrypted file (Fig. 1, The encrypted data 112 may then be stored in a data storage system 114 [0026]).
Roth does not explicitly disclose, receiving, by the user terminal, a password, however Sirota in the same fields of endeavor teaches receiving, by the user terminal, a password (Step 130 may include, for example applying a Password-Based Key Derivation Function (such as PBKDF2) one or more times (for example n1 times, n1 being a positive integer) on concatenation of the user email with the user password to generate the user personal key [Col, 7 Lines 21-25]);
using, by the user terminal, a first asymmetric encryption technique to generate a public code key and a private code key (Step 150 includes generating public/private keys for asymmetric encryption and another pair for message signing [Col. 7, lines 43-44]);
using, by the user terminal, the initial key to encrypt the private code key to generate an encrypted private code key (Fig. 1, step 160, the user private keys encrypted with the personal key [Col. 7, Lines 45-53]);
using, by the user terminal, a second asymmetric encryption technique to generate a public signature key and a private signature key (Step 250 may include reversing the encryption process of step 160 [Col. 8, lines 57-58]);
using, by the user terminal, the initial key to encrypt the private signature key to generate an encrypted private signature key (Step 160 includes encrypting with personal key (by the user computer) the user private keys (generated in step 150) to generate an encrypted user private keys [Col. 7 lines 45-47]);
storing, by the user terminal, the public code key, the encrypted private code key, the public signature key and the encrypted private signature key into the key server via the interface server (Fig. 9-10, the sign-up program in the browser sends the unencrypted public keys to User Management and Public Keys Service 11, which stores them, and stores the private keys encrypted under the personal key in Data Storage 15 as Encrypted User Private Data 16, the browser being served by Web Application Server 12 [Col. 7, lines 54-67], [Col. 13, lines 62-67], [Col. 14, lines 1-14]);
cooperating, by the user terminal, with the interface server to generate an initial key corresponding to the password (Step 240 also includes sending the server password generated during step 230 to the server and send a request to retrieve the encrypted user private key stored in the server [Col. 8 Lines 47-49];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to provision the user terminal of Roth with a password-derived initial key, a client-generated code key pair and a client-generated signature key pair, and to store the public keys and the password-wrapped private keys at the provider’s key management system through its customer interface, as taught by Sirota, for the predictable benefit identified by Sirota of allowing the user to recover the private keys needed for decryption and request signing from any device by supplying only the password, without any local software installation and without the provider ever holding the private keys in the clear. [Col. 1, line 35-43]
Regarding claim 3, Roth in view of Sirota teaches the method of claim 1. Roth further teaches wherein interface server generates the plaintext file key only when the verification of the signature is successful (Fig. 5, steps 504-506, the request is denied if the signature is invalid; Fig. 7, steps 704-706 precede key generation at step 710 [0034], [0044-0045], [0049]).
Regarding claim 4, Roth in view of Sirota teaches the method of claim 1. Roth further teaches wherein the user terminal deletes the initial key, the private code key and the private signature key after a preset time duration expires. (Destruction of the cryptographic key 110 may be performed in various ways in accordance with various embodiments [0027]).
Regarding claim 9, Roth teaches a secure file storage system, comprising a user terminal, an interface server, a key server and a file server (Fig. 1, customer 102, service provider 106 and data storage system 114; Fig. 2, customer interface 202, authentication system 208 and request processing infrastructure 212 with data storage systems 214; Fig. 13 Key management system 1310 separate from the provider 1306 [0024-0026], [0032-0036])
transmitting, by the user terminal, a first request to the interface server to instruct the interface server to verify a signature in the first request by using the public signature key and then to randomly generate a plaintext file key (Fig. 2, request 204 received with signature 206 at customer interface 202 and verified by authentication system 208, the signature generated by the customer with private key of an asymmetric signature keypair; Fig. 5, steps 502-504; Fig. 7, steps 702-704 and step 10, an encryption key generated by the provider once the request is determined to be fulfilled [0033-0034], [0044-0045], [0049]);
encrypting, by the interface server, the plaintext file key with the public code key to generate a ciphertext file key (Fig. 6 request 600 carrying customer public key 602; Fig. 7, step 714, the encryption key wrapped with the customer public key so that it is decryptable only with the corresponding private key [0048-0049]);
storing, by the interface server, the ciphertext file key into the key server (the encrypted encryption key is stored by the provider, e.g., with the encrypted data [0052]; Fig. 13-14, key management system 1310 that manages cryptographic keys on behalf of the provider’s customers and to which wrapped keys are transmitted [0061-0063];
transmitting, by the interface server, the ciphertext file key to the user terminal (Fig. 7, step 718, response to the request including the encrypted encryption key [0053-0054];
using, by the user terminal, the private code key to decrypt the ciphertext file key to obtain the plaintext file key (Fig. 8 steps 802-804, the customer decrypts the wrapped key with the private key corresponding to the public key used to wrap it [0053-0054];
using, by the user terminal, a secure protocol to transmit the plaintext file key and a file to the file server (Fig. 1, request 104 carrying data 108 organized as a file together with cryptographic key 110 in plaintext form; Fig. 3, symmetric key 302 carried in the request under transport layer security; Fig. 8, steps 806-808, request generated with the decrypted encryption key [0025], [0038], [0054];
encrypting, by the file server, the file according to the plaintext file key to generate an encrypted file (Fig. 1, the provider system that receives request 104 encrypts data 108 with key 110 to produce encrypted data 112 fir the data storage system 114, which may be a separate system from the request-receiving provider, including one operated by a third party [0025-0026], [0036], [0046]);
and storing, by the file server, the encrypted file (Fig. 1, The encrypted data 112 may then be stored in a data storage system 114 [0026]).
Roth does not explicitly disclose, receiving, by the user terminal, a password, however Sirota in the same fields of endeavor teaches receiving, by the user terminal, a password (Step 130 may include, for example applying a Password-Based Key Derivation Function (such as PBKDF2) one or more times (for example n1 times, n1 being a positive integer) on concatenation of the user email with the user password to generate the user personal key [Col, 7 Lines 21-25]);
using, by the user terminal, a first asymmetric encryption technique to generate a public code key and a private code key (Step 150 includes generating public/private keys for asymmetric encryption and another pair for message signing [Col. 7, lines 43-44]);
using, by the user terminal, the initial key to encrypt the private code key to generate an encrypted private code key (Fig. 1, step 160, the user private keys encrypted with the personal key [Col. 7, Lines 45-53]);
using, by the user terminal, a second asymmetric encryption technique to generate a public signature key and a private signature key (Step 250 may include reversing the encryption process of step 160 [Col. 8, lines 57-58]);
using, by the user terminal, the initial key to encrypt the private signature key to generate an encrypted private signature key (Step 160 includes encrypting with personal key (by the user computer) the user private keys (generated in step 150) to generate an encrypted user private keys [Col. 7 lines 45-47]);
storing, by the user terminal, the public code key, the encrypted private code key, the public signature key and the encrypted private signature key into the key server via the interface server (Fig. 9-10, the sign-up program in the browser sends the unencrypted public keys to User Management and Public Keys Service 11, which stores them, and stores the private keys encrypted under the personal key in Data Storage 15 as Encrypted User Private Data 16, the browser being served by Web Application Server 12 [Col. 7, lines 54-67], [Col. 13, lines 62-67], [Col. 14, lines 1-14]);
cooperating, by the user terminal, with the interface server to generate an initial key corresponding to the password (Step 240 also includes sending the server password generated during step 230 to the server and send a request to retrieve the encrypted user private key stored in the server [Col. 8 Lines 47-49];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to provision the user terminal of Roth with a password-derived initial key, a client-generated code key pair and a client-generated signature key pair, and to store the public keys and the password-wrapped private keys at the provider’s key management system through its customer interface, as taught by Sirota, for the predictable benefit identified by Sirota of allowing the user to recover the private keys needed for decryption and request signing from any device by supplying only the password, without any local software installation and without the provider ever holding the private keys in the clear. [Col. 1, line 35-43]
Regarding claim 10, Roth teaches A non-transitory computer readable storage medium, storing instructions therein [0083], to execute a secure file storage method, performed by a user terminal, an interface server, a key server and a file server (Fig. 1, customer 102, service provider 106 and data storage system 114; Fig. 2, customer interface 202, authentication system 208 and request processing infrastructure 212 with data storage systems 214; Fig. 13 Key management system 1310 separate from the provider 1306 [0024-0026], [0032-0036])
transmitting, by the user terminal, a first request to the interface server to instruct the interface server to verify a signature in the first request by using the public signature key and then to randomly generate a plaintext file key (Fig. 2, request 204 received with signature 206 at customer interface 202 and verified by authentication system 208, the signature generated by the customer with private key of an asymmetric signature keypair; Fig. 5, steps 502-504; Fig. 7, steps 702-704 and step 10, an encryption key generated by the provider once the request is determined to be fulfilled [0033-0034], [0044-0045], [0049]);
encrypting, by the interface server, the plaintext file key with the public code key to generate a ciphertext file key (Fig. 6 request 600 carrying customer public key 602; Fig. 7, step 714, the encryption key wrapped with the customer public key so that it is decryptable only with the corresponding private key [0048-0049]);
storing, by the interface server, the ciphertext file key into the key server (the encrypted encryption key is stored by the provider, e.g., with the encrypted data [0052]; Fig. 13-14, key management system 1310 that manages cryptographic keys on behalf of the provider’s customers and to which wrapped keys are transmitted [0061-0063];
transmitting, by the interface server, the ciphertext file key to the user terminal (Fig. 7, step 718, response to the request including the encrypted encryption key [0053-0054];
using, by the user terminal, the private code key to decrypt the ciphertext file key to obtain the plaintext file key (Fig. 8 steps 802-804, the customer decrypts the wrapped key with the private key corresponding to the public key used to wrap it [0053-0054];
using, by the user terminal, a secure protocol to transmit the plaintext file key and a file to the file server (Fig. 1, request 104 carrying data 108 organized as a file together with cryptographic key 110 in plaintext form; Fig. 3, symmetric key 302 carried in the request under transport layer security; Fig. 8, steps 806-808, request generated with the decrypted encryption key [0025], [0038], [0054];
encrypting, by the file server, the file according to the plaintext file key to generate an encrypted file (Fig. 1, the provider system that receives request 104 encrypts data 108 with key 110 to produce encrypted data 112 fir the data storage system 114, which may be a separate system from the request-receiving provider, including one operated by a third party [0025-0026], [0036], [0046]);
and storing, by the file server, the encrypted file (Fig. 1, The encrypted data 112 may then be stored in a data storage system 114 [0026]).
Roth does not explicitly disclose, receiving, by the user terminal, a password, however Sirota in the same fields of endeavor teaches receiving, by the user terminal, a password (Step 130 may include, for example applying a Password-Based Key Derivation Function (such as PBKDF2) one or more times (for example n1 times, n1 being a positive integer) on concatenation of the user email with the user password to generate the user personal key [Col, 7 Lines 21-25]);
using, by the user terminal, a first asymmetric encryption technique to generate a public code key and a private code key (Step 150 includes generating public/private keys for asymmetric encryption and another pair for message signing [Col. 7, lines 43-44]);
using, by the user terminal, the initial key to encrypt the private code key to generate an encrypted private code key (Fig. 1, step 160, the user private keys encrypted with the personal key [Col. 7, Lines 45-53]);
using, by the user terminal, a second asymmetric encryption technique to generate a public signature key and a private signature key (Step 250 may include reversing the encryption process of step 160 [Col. 8, lines 57-58]);
using, by the user terminal, the initial key to encrypt the private signature key to generate an encrypted private signature key (Step 160 includes encrypting with personal key (by the user computer) the user private keys (generated in step 150) to generate an encrypted user private keys [Col. 7 lines 45-47]);
storing, by the user terminal, the public code key, the encrypted private code key, the public signature key and the encrypted private signature key into the key server via the interface server (Fig. 9-10, the sign-up program in the browser sends the unencrypted public keys to User Management and Public Keys Service 11, which stores them, and stores the private keys encrypted under the personal key in Data Storage 15 as Encrypted User Private Data 16, the browser being served by Web Application Server 12 [Col. 7, lines 54-67], [Col. 13, lines 62-67], [Col. 14, lines 1-14]);
cooperating, by the user terminal, with the interface server to generate an initial key corresponding to the password (Step 240 also includes sending the server password generated during step 230 to the server and send a request to retrieve the encrypted user private key stored in the server [Col. 8 Lines 47-49];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to provision the user terminal of Roth with a password-derived initial key, a client-generated code key pair and a client-generated signature key pair, and to store the public keys and the password-wrapped private keys at the provider’s key management system through its customer interface, as taught by Sirota, for the predictable benefit identified by Sirota of allowing the user to recover the private keys needed for decryption and request signing from any device by supplying only the password, without any local software installation and without the provider ever holding the private keys in the clear. [Col. 1, line 35-43]
Regarding claim 7, Roth in view of Sirota teaches all of the limitations of claim 1. Roth further discloses wherein when the user terminal uses the secure protocol to transmit the plaintext file key and the file to the file server, the user terminal further specifies an encryption algorithm to instruct the file server to use the plaintext file key and the encryption algorithm to encrypt the file to generate the encrypted file (request carrying the key to the storage service includes request parameters that specify how the request is to be fulfilled, including a parameter specifying that server-side encryption is to be performed using the key provided with the request [0030, 0038-0039, 0066] and the encryption may be performed with any of the plurality of symmetric algorithms including AES, DES, 3DES, Serpent etc. [0065])
Regarding claim 8, Roth in view of Sirota teaches all of the limitations of claim 7. Roth further discloses transmitting, by the user terminal, a second request to the file server, wherein the second request comprises the plaintext file key and specifies the encryption algorithm (Fig. 8, steps 806/808, a GET request generated with the decrypted encryption key and submitted to the provider [0054];
using, by the file server, the plaintext file key and the encryption algorithm to decrypt the encrypted file into the file(Fig. 8 discussion, the provider uses the encryption key in the request to decrypt the data that was encrypted under it; Fig 2, customer interface 202 decrypts encrypted data 210 retrieved from storage systems 214 [0037, 0054];
and transmitting, by the file server, the file to the user terminal (Fig 8, steps 810, response including the decrypted data; Fig 5, step 512 [0047,0054]. That the second request specifies the encryption algorithm and that the file server user the encryption algorithm to decrypt is obvious for the reasons given above with respect to claim 7, since the same parameters that identify the cipher for encryption identify it for decryption.
Claims 2 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Roth in view of Sirota and further in view of Resch et al. (hereinafter Resch) US 2019/0296896 A1.
Regarding claim 2, Roth in view of Sirota teach all of the limitations of claim 1. The combination fail to disclose wherein the user terminal uses an oblivious pseudo random function to cooperate with the interface server to generate the initial key, however Resch in the same fields of endeavor teaches wherein the user terminal uses an oblivious pseudo random function to cooperate with the interface server to generate the initial key (Fig 3B; Fig 5, steps 510-540; The OPRF (Oblivious Pseudo Random Function) can be viewed a key derivation that occurs on a blinded value ( e . g . , on a homomorphically encrypted cipher text ) . Note that certain examples herein are described with respect to an OPRF blinding operation that is performed using homomorphic encryption ( and a an OPRF unblinding operation that is performed using homomorphic decryption ) , in general , any OPRF blinding / OPRF unblind ing operation may be used such that the process that per forms the OPRF blinding / OPRF unblinding operation are known to client ( e . g . , user , computing device 110 such as “ Alice , ” and not to " Bob " ) [0087]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to derive Sirota’s password based personal key by the cooperative oblivious pseudo random function protocol of Resch, with the password (or a hash of it) as the user terminal’s input, for the predictable benefits identified by Resch that the provider learns neither the input nor the resulting key, that the key is regenerated on each use rather than stored, and that the security of the key does not depend on the confidentiality of the communication channel [Resch 0007, 0031].
Regarding claim 5, Roth in view of Sirota teach all of the limitations of claim 4. Sirota further teaches wherein after the preset time duration expires, the secure file storage method further comprises: obtaining, by the user terminal, the encrypted private code key and the encrypted private signature key from the key server via the interface server (Fig. 2, step 240, request to retrieve the encrypted user private keys stored in the server; Fig. 11; User Private Data discussion, Encrypted User Private Data 16 requested from Data Storage 15 [Col. 8, lines 43-49];
receiving, by the user terminal, the password (Fig. 2, step 220; Step 230 may be followed by step 240 of generating, by the user computer, a server password by applying a cryptographic hashing algorithm on at least a part of the authentication information [Col. 8, lines 39-42])
using, by the user terminal, the initial key to decrypt the encrypted private code key to obtain the private code key; and using, by the user terminal, the initial key to decrypt the encrypted private signature key to obtain the private signature key, wherein the initial key, the private code key and the private signature key are used subsequently for encryption context update, file uploading, or file downloading (Fig. 2, step 250, the encrypted user private keys decrypted with the personal key by reversing step 160 [Col. 8, lines 50-58]
The combination fails to disclose cooperating, by the user terminal, with the interface server to generate the initial key, however Resch in the same fields of endeavor teaches cooperating, by the user terminal, with the interface server to generate the initial key (Fig. 3B, Fig. 5, steps 510-540, computing devices 110 blinds an input value, transmits the blinded value to Key Management Server (KMS) service 121, receives a blinded key computed with the KMS’s OPRF secret, and unblinds it to obtain the key, the input value being an arbitrary or user-provided identifier unknown to the KMS [0006], [0036-0037], [0079-0091]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to derive Sirota’s password based personal key by the cooperative oblivious pseudo random function protocol of Resch, with the password (or a hash of it) as the user terminal’s input, for the predictable benefits identified by Resch that the provider learns neither the input nor the resulting key, that the key is regenerated on each use rather than stored, and that the security of the key does not depend on the confidentiality of the communication channel [Resch 0007, 0031].
Regarding claim 6, Roth in view of Sirota teaches all of the limitations of claim 1. Sirota further discloses receiving, by the user terminal, a new password (Private Data Recovery section, the user resets the password and a new password is supplied [Col. 16, Line 65 – Col. 17, Line 3]);
a new initial key corresponding to the new password (a new personal key created from the new user password as in step 130 [Col. 17, lines 25-31]);
using, by the user terminal, the new initial key to encrypt the private code key to generate a new encrypted private code key; using, by the user terminal, the new initial key to encrypt the private signature key to generate a new encrypted private signature key (the private key pairs encrypted with the new personal key, and the original Encrypted User Private Data…… which contains the user’s private keys…. Decrypted with the original personal key and re-encrypted with the new personal key [Col. 17 Lines 27-48]);
storing, by the user terminal, the new encrypted private code key and the new encrypted private signature key into the key server via the interface server (stored in Data storage 15 as a new Encrypted User Private Data containing the user’s private keys, [Col. 14, lines 9-10]. Because Sirota’s Encrypted User Private Date 16 contains both the encryption private key and the signature private key generated at step 150 [Col. 7, lines 43-53], re-encrypting it with the new personal key re-wraps the private code key and the private signature key together. The new initial key is generated by cooperating, by the user terminal, with the interface server to generate a new initial key corresponding to the new password which is disclosed by Resch in the same fields of endeavor (Fig. 3B, Fig. 5, steps 510-540, computing devices 110 blinds an input value, transmits the blinded value to Key Management Server (KMS) service 121, receives a blinded key computed with the KMS’s OPRF secret, and unblinds it to obtain the key, the input value being an arbitrary or user-provided identifier unknown to the KMS [0006], [0036-0037], [0079-0091]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to derive Sirota’s password based personal key by the cooperative oblivious pseudo random function protocol of Resch, with the password (or a hash of it) as the user terminal’s input, for the predictable benefits identified by Resch that the provider learns neither the input nor the resulting key, that the key is regenerated on each use rather than stored, and that the security of the key does not depend on the confidentiality of the communication channel [Resch 0007, 0031].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 2022/0321353 A1 Firestone et al. – password-derived symmetric user key used to decrypt an encrypted private key retrieved from a data persistence server; user key held only in volatile memory and purged at logoff.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDUL HAFEEZ MIRZA whose telephone number is (571)270-0784 and E-mail address is Abdul.Mirza@uspto.gov. The examiner can normally be reached Monday - Friday, 7:30 a.m. - 5 p.m. ET..
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, Shewaye Gelagay can be reached at (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 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.
/A.H.M./Examiner, Art Unit 2436
/A.C.L./ Primary Examiner, Art Unit 2436
