Prosecution Insights
Last updated: April 19, 2026
Application No. 17/893,172

SECURE SYNCHRONIZATION OF DATA

Non-Final OA §103
Filed
Aug 23, 2022
Examiner
ALMEIDA, DEVIN E
Art Unit
2492
Tech Center
2400 — Computer Networks
Assignee
UAB 360 IT
OA Round
5 (Non-Final)
71%
Grant Probability
Favorable
5-6
OA Rounds
3y 9m
To Grant
82%
With Interview

Examiner Intelligence

Grants 71% — above average
71%
Career Allow Rate
421 granted / 592 resolved
+13.1% vs TC avg
Moderate +11% lift
Without
With
+11.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
35 currently pending
Career history
627
Total Applications
across all art units

Statute-Specific Performance

§101
7.7%
-32.3% vs TC avg
§103
53.4%
+13.4% vs TC avg
§102
24.6%
-15.4% vs TC avg
§112
8.1%
-31.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 592 resolved cases

Office Action

§103
DETAILED ACTION 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 12/3/2025 has been entered. Claims 1-20 are pending with claims 1, 8 and 15 having been amended. 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 received. 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, 8-10, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2014/0143548) in view of Huttunen (US 2003/0147267). With respect to claim 1 Wang teaches a method, comprising: transmitting, by a user device to an infrastructure device, an encrypted version of a file and an encrypted version of metadata that is associated with the file for storage at the infrastructure device (see Wang paragraph 0081-0082 i.e. Step 705: the client uses the key ekA to encrypt the key dkS to obtain User A's personal key kA, and submits the key kA to the server. Wherein, in one embodiment, the key dkS is calculated at the same time with the ekS based on the data X and a pre-determined algorithm. The server saves the HASH value hX, the data Y, and the key kA and paragraph 0073 i.e. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different); transmitting, by the user device from the infrastructure device, a request to receive the encrypted version of the file and the encrypted version of the metadata stored at the infrastructure device (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side;); receiving, by the user device from the infrastructure device based at least in part on transmitting the request, the encrypted version of the file in association with the encrypted version of the metadata (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side); decrypting, by the user device, the encrypted version of the metadata based at least in part on utilizing the file symmetric key to determine a synchronization key included in the metadata (see Wang paragraph 0071 i.e. Step 602: the client uses User A's decryption key dkA to decrypt the key kA to obtain the key dkS); and decrypting, by the user device, the encrypted version of the file based at least in part on utilizing the synchronization key to determine an unencrypted version of the file (see Wang paragraph 0072-0073 i.e. Step 603: the client uses the key dkS to decrypt the data Y to obtain unencrypted data X. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different. The key eKS and the key dkS can be newly-generated random key). Wang does not disclose decrypting, by the user device, an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key. Huttunem teaches disclose decrypting, by the user device, an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). With respect to claim 2 Wang teaches the method of claim 1, but does not disclose further comprising: determining the master key based at least in part on a master string of alphanumeric characters. Huttunen teaches further comprising: determining the master key based at least in part on a master string of alphanumeric characters (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunen to have generated the master key based a passphrase as one of many ways of generating a key (see Huttunem paragraph 0042). Therefore one would have been motivated to have used a passphrase to generate an encryption key. With respect to claim 3 Wang teaches the method of claim 1, but does not disclose wherein decrypting the encrypted version of the metadata includes utilizing the file symmetric key to decrypt an encrypted version of a metadata key, and utilizing the metadata key to decrypt the encrypted version of the metadata. Huttunem teaches wherein decrypting the encrypted version of the metadata includes utilizing the file symmetric key to decrypt an encrypted version of a metadata key, and utilizing the metadata key to decrypt the encrypted version of the metadata (see paragraph 0047 i.e. In addition, the KEY.sub.sym can be used to decrypt the private key KEY.sub.priv which in turn is used to decrypt the various temporary keys KEY.sub.tmp). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). With respect to claim 8 Wang teaches a user device, comprising: a memory; and a processor communicatively coupled to the memory, the memory and the processor being configured to: transmit to an infrastructure device an encrypted version of a file and an encrypted version of metadata that is associated with the file for storage at the infrastructure device (see Wang paragraph 0081-0082 i.e. Step 705: the client uses the key ekA to encrypt the key dkS to obtain User A's personal key kA, and submits the key kA to the server. Wherein, in one embodiment, the key dkS is calculated at the same time with the ekS based on the data X and a pre-determined algorithm. The server saves the HASH value hX, the data Y, and the key kA and paragraph 0073 i.e. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different); transmit from the infrastructure device, a request to receive the encrypted version of the file and the encrypted version of the metadata stored at the infrastructure device (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side;); receive from the infrastructure device based at least in part on transmitting the request, the encrypted version of the file in association with the encrypted version of the metadata (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side); decrypt an encrypted version of the metadata based at least in part on utilizing the file symmetric key to determine a synchronization key included in the metadata (see Wang paragraph 0071 i.e. Step 602: the client uses User A's decryption key dkA to decrypt the key kA to obtain the key dkS); and decrypt the encrypted version of the file based at least in part on utilizing the synchronization key to determine an unencrypted version of the file (see Wang paragraph 0072-0073 i.e. Step 603: the client uses the key dkS to decrypt the data Y to obtain unencrypted data X. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different. The key eKS and the key dkS can be newly-generated random key). Wang does not disclose decrypt an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key. Huttunem teaches disclose decrypt an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). With respect to claim 9 Wang teaches the user device of claim 8, but does not disclose wherein the memory and the processor are configured to determine the master key based at least in part on a master string of alphanumeric characters. Huttunen teaches wherein the memory and the processor are configured to determine the master key based at least in part on a master string of alphanumeric characters (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunen to have generated the master key based a passphrase as one of many ways of generating a key (see Huttunem paragraph 0042). Therefore one would have been motivated to have used a passphrase to generate an encryption key. With respect to claim 10 Wang teaches the user device of claim 8, but does not disclose wherein, to decrypt the encrypted version of the metadata, the memory and the processor are configured to utilize the file symmetric key to decrypt an encrypted version of a metadata key, and to utilize the metadata key to decrypt the encrypted version of the metadata. Huttunen teaches wherein, to decrypt the encrypted version of the metadata, the memory and the processor are configured to utilize the file symmetric key to decrypt an encrypted version of a metadata key, and to utilize the metadata key to decrypt the encrypted version of the metadata (see Huttunen paragraph 0047 i.e. In addition, the KEY.sub.sym can be used to decrypt the private key KEY.sub.priv which in turn is used to decrypt the various temporary keys KEY.sub.tmp). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). With respect to claim 15 Wang teaches a non-transitory computer-readable medium configured to store instructions, which when executed by a processor associated with a user device, configure the processor to: transmit to an infrastructure device an encrypted version of a file and an encrypted version of metadata that is associated with the file for storage at the infrastructure device (see Wang paragraph 0081-0082 i.e. Step 705: the client uses the key ekA to encrypt the key dkS to obtain User A's personal key kA, and submits the key kA to the server. Wherein, in one embodiment, the key dkS is calculated at the same time with the ekS based on the data X and a pre-determined algorithm. The server saves the HASH value hX, the data Y, and the key kA and paragraph 0073 i.e. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different); transmit from the infrastructure device, a request to receive the encrypted version of the file and the encrypted version of the metadata stored at the infrastructure device (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side;); receive from the infrastructure device based at least in part on transmitting the request, the encrypted version of the file in association with the encrypted version of the metadata (see Wang paragraph 0069-0070 i.e. When User A accessing the data X further, the method comprises of: Step 601: the server sends the encrypted data Y and User A's personal key kA to the client at User A's side); decrypt an encrypted version of the metadata based at least in part on utilizing the file symmetric key to determine a synchronization key included in the metadata (see Wang paragraph 0071 i.e. Step 602: the client uses User A's decryption key dkA to decrypt the key kA to obtain the key dkS); and decrypt the encrypted version of the file based at least in part on utilizing the synchronization key to determine an unencrypted version of the file (see Wang paragraph 0072-0073 i.e. Step 603: the client uses the key dkS to decrypt the data Y to obtain unencrypted data X. In this embodiment, the key ekA and the key dkA may be the same or different, the key ekB and the key dkB may be the same or different, the key ekS and the key dkS may be the same or different, the key ekX and the key dkX may be the same or different. The key eKS and the key dkS can be newly-generated random key). Wang does not disclose decrypting, by the user device, an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key. Huttunem teaches disclose decrypting, by the user device, an encrypted version of a file symmetric key based at least in part on utilizing a master key to determine the file symmetric key (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). With respect to claim 16 Wang teaches the non-transitory computer-readable medium of claim 15, but does not disclose wherein the processor is configured to determine the master key based at least in part on a master string of alphanumeric characters. Huttunem teaches wherein the processor is configured to determine the master key based at least in part on a master string of alphanumeric characters (see Huttunem paragraph 0042 i.e. In the first mode, the program makes use a symmetric cipher such as DES, Triple DES, or AES, and makes use of a cryptographic key KEY.sub.sym that is generated by a (pseudo) random number generator and protected using a passphrase supplied by the user, for example with the method described in PKCS#5 (RSA.sup..TM.Technologies). The passphrase is first selected by the user when the encryption application is installed into the device (or when it is first activated if the encryption application is pre-installed into the PDA 1). When the device is not being operated in the first mode or is switched off, the cryptographic key KEY.sub.sym is stored in the RAM 5, encrypted with the passphrase. When the device is switched on and operated in the first mode, the key is stored in the RAM 5 in plaintext and is freely available to the encryption program). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunen to have generated the master key based a passphrase as one of many ways of generating a key (see Huttunem paragraph 0042). Therefore one would have been motivated to have used a passphrase to generate an encryption key. With respect to claim 17 Wang teaches the non-transitory computer-readable medium of claim 15, but does not disclose wherein, to decrypt the encrypted version of the metadata, the processor is configured to utilize the file symmetric key to decrypt an encrypted version of a metadata key, and to utilize the metadata key to decrypt the encrypted version of the metadata. Huttunem teaches wherein, to decrypt the encrypted version of the metadata, the processor is configured to utilize the file symmetric key to decrypt an encrypted version of a metadata key, and to utilize the metadata key to decrypt the encrypted version of the metadata (see paragraph 0047 i.e. In addition, the KEY.sub.sym can be used to decrypt the private key KEY.sub.priv which in turn is used to decrypt the various temporary keys KEY.sub.tmp). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Huttunem to have encrypted the folder keys (claimed file symmetric key) used to decrypt the file with a master key and also encrypt the master key with a passphrase as a way to improve security of the folder keys by reducing the risk of somebody copying the keys for future unauthorized use since the folder keys are stored in encrypted form (see Huttunen paragraph 0049). Claims 4, 5, 7, 11, 12, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2014/0143548) in view of Huttunen (US 2003/0147267) in view of Toh et al (US 2002/0019932). With respect to claim 4 Wang teaches the method of claim 1, but does not disclose further comprising: determining a calculated hash of a stored version of the file stored in a memory associated with the user device, and comparing the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file. Toh teaches further comprising: determining a calculated hash of a stored version of the file stored in a memory associated with the user device, and comparing the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 5 Wang teaches the method of claim 1, but does not disclose further comprising: determining that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device. Toh teaches further comprising: determining that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 7 Wang teaches the method of claim 1, but does not disclose further comprising: determining whether the unencrypted version of the file was tampered with based at least in part on information included in the metadata. Toh teaches further comprising: determining whether the unencrypted version of the file was tampered with based at least in part on information included in the metadata (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 11 Wang teaches the user device of claim 8, but does not disclose wherein the memory and the processor are configured to determine a calculated hash of a stored version of the file stored in a memory associated with the user device, and to compare the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file. Toh teaches wherein the memory and the processor are configured to determine a calculated hash of a stored version of the file stored in a memory associated with the user device, and to compare the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 12 Wang teaches the user device of claim 8, does not disclose wherein the memory and the processor are configured to determine that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device. Toh teaches wherein the memory and the processor are configured to determine that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 14 Wang teaches the user device of claim 8, but does not disclose wherein the memory and the processor are configured to determine whether the unencrypted version of the file was tampered with based at least in part on information included in the metadata. Toh teaches wherein the memory and the processor are configured to determine whether the unencrypted version of the file was tampered with based at least in part on information included in the metadata (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 18 Wang teaches the non-transitory computer-readable medium of claim 15, but does not disclose wherein the processor is configured to determine a calculated hash of a stored version of the file stored in a memory associated with the user device, and to compare the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file. Toh teaches wherein the processor is configured to determine a calculated hash of a stored version of the file stored in a memory associated with the user device, and to compare the calculated hash with a received hash of the unencrypted version of the file included in the metadata to determine whether the stored version of the file matches the unencrypted version of the file (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 19 Wang teaches the non-transitory computer-readable medium of claim 15, but does not disclose wherein the processor is configured to determine that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device. Toh teaches wherein the processor is configured to determine that the unencrypted version of the file includes a modification based at least in part on comparing the unencrypted version of the file with a stored version of the file stored in a memory associated with the user device (see Toh paragraph 0033 i.e. A digital signature may be generated in other ways as well. For example, a sending system can digitally sign a hash or digest of a data file. A hash or digest of a data file is obtained by operating a hash algorithm on the data file. A hash algorithm is a method of transforming a variable length message, in this case the data file, into a fixed length number. This fixed length number is referred to as the hash or digest of the original data file…The hash of the data file, along with information about the hash algorithm used to generate the hash, is then encrypted with the sender's private key. The sender transmits the original data file as well as the encrypted hash to the recipient. The recipient uses the sender's public key to decrypt the hash. To verify the integrity of data file, the recipient uses the same hash algorithm on the original data file. If the hash generated by the recipient does not match the decrypted hash, this indicates a problem. The digital signature may not have been created with the sender's private key or the data may have been tampered with since it was signed by the sender. If the hashes match, the recipient can be reasonably assured that the sender sent the data and that it has not been altered). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang in view of Toh to have included a digital signature hash with the data file to verify the integrity of data file by using the same hash algorithm on the original data file and if the hashes match, it can be reasonably assured that the data file has not been altered (see Toh paragraph 0033). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2014/0143548) in view of Huttunen (US 2003/0147267) in view of Brouwer et al (US 2009/0006640) With respect to claim 6 Wang teaches the method of claim 1, but does not disclose further comprising: storing the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata. Brouwer teaches further comprising: storing the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata (see Brouwer figures 7A-B and paragraph 0050-0051 i.e. In this step, the FEK is used to decrypt the encrypted data which includes the file path concatenated with the file bytes. At step 719, the data processing device deconstructs the file path and the file data from the decrypted data…At step 721 the data processing device determines, for each file to be restored, whether the file path is in the whitelist of files maintained on the device. If not, control continues to 722 and the restore fails. If the file path is in the whitelist maintained on the data processing device, then control continues to step 723. In this step, the device saves the decrypted file data in a temporary file location, such as a sandbox. At step 725, the device sets the modification date of the file to the modification date indicated in the manifest. The device then deletes the manifest entry for the phash (file name) for each file being restored at step 727. At step 729, after all the files to be restored have been processed). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang to have used the restore method of Brouwer as a way to restore a file to the correct destination on the device in a secure fashion such that it not possible to tamper with the files, file path or destination into which the file should be placed back onto the device (See Brouwer paragraph 0052). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 13 Wang teaches the user device of claim 8, but does not disclose wherein the memory and the processor are configured to store the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata. Brouwer teaches wherein the memory and the processor are configured to store the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata (see Brouwer figures 7A-B and paragraph 0050-0051 i.e. In this step, the FEK is used to decrypt the encrypted data which includes the file path concatenated with the file bytes. At step 719, the data processing device deconstructs the file path and the file data from the decrypted data…At step 721 the data processing device determines, for each file to be restored, whether the file path is in the whitelist of files maintained on the device. If not, control continues to 722 and the restore fails. If the file path is in the whitelist maintained on the data processing device, then control continues to step 723. In this step, the device saves the decrypted file data in a temporary file location, such as a sandbox. At step 725, the device sets the modification date of the file to the modification date indicated in the manifest. The device then deletes the manifest entry for the phash (file name) for each file being restored at step 727. At step 729, after all the files to be restored have been processed). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang to have used the restore method of Brouwer as a way to restore a file to the correct destination on the device in a secure fashion such that it not possible to tamper with the files, file path or destination into which the file should be placed back onto the device (See Brouwer paragraph 0052). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. With respect to claim 20 Wang teaches the non-transitory computer-readable medium of claim 15, but dos not disclose wherein the processor is configured to store the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata. Brouwer teaches wherein the processor is configured to store the unencrypted version of the file in a folder in a memory associated with the user device based at least in part on path information included in the metadata (see Brouwer figures 7A-B and paragraph 0050-0051 i.e. In this step, the FEK is used to decrypt the encrypted data which includes the file path concatenated with the file bytes. At step 719, the data processing device deconstructs the file path and the file data from the decrypted data…At step 721 the data processing device determines, for each file to be restored, whether the file path is in the whitelist of files maintained on the device. If not, control continues to 722 and the restore fails. If the file path is in the whitelist maintained on the data processing device, then control continues to step 723. In this step, the device saves the decrypted file data in a temporary file location, such as a sandbox. At step 725, the device sets the modification date of the file to the modification date indicated in the manifest. The device then deletes the manifest entry for the phash (file name) for each file being restored at step 727. At step 729, after all the files to be restored have been processed). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang to have used the restore method of Brouwer as a way to restore a file to the correct destination on the device in a secure fashion such that it not possible to tamper with the files, file path or destination into which the file should be placed back onto the device (See Brouwer paragraph 0052). Therefore one would have been motivated to have included a digital signature hash with the data file to verify the integrity of data file. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. 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). /DEVIN E ALMEIDA/Examiner, Art Unit 2492
Read full office action

Prosecution Timeline

Aug 23, 2022
Application Filed
May 16, 2024
Non-Final Rejection — §103
Aug 15, 2024
Response Filed
Dec 10, 2024
Final Rejection — §103
Feb 06, 2025
Response after Non-Final Action
Mar 21, 2025
Non-Final Rejection — §103
Jun 25, 2025
Response Filed
Oct 03, 2025
Final Rejection — §103
Dec 03, 2025
Request for Continued Examination
Dec 08, 2025
Examiner Interview Summary
Dec 17, 2025
Response after Non-Final Action
Jan 24, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12580763
USE OF TENSILE SPHERES FOR EXTENDED SYMMETRIC CRYPTOGRAPHY
2y 5m to grant Granted Mar 17, 2026
Patent 12562886
Fast Polynomial Evaluation Under Fully Homomorphic Encryption by Products of Differences from Roots Using Rotations
2y 5m to grant Granted Feb 24, 2026
Patent 12556512
METHODS, SYSTEMS, AND COMPUTER READABLE MEDIA FOR AUTOMATIC CATEGORY 1 MESSAGE FILTERING RULES CONFIGURATION BY LEARNING TOPOLOGY INFORMATION FROM NETWORK FUNCTION (NF) REPOSITORY FUNCTION (NRF)
2y 5m to grant Granted Feb 17, 2026
Patent 12556393
SYSTEMS AND METHODS FOR REAL-TIME TRACEABILITY USING AN OBFUSCATION ARCHITECTURE
2y 5m to grant Granted Feb 17, 2026
Patent 12542682
AUTHENTICATING PACKAGED PRODUCTS
2y 5m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
71%
Grant Probability
82%
With Interview (+11.4%)
3y 9m
Median Time to Grant
High
PTA Risk
Based on 592 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month