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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
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 03/03/2026 has been entered. Claims 1, 10, 11 and 16 are amended. Claims 1-20 are pending.
Response to Arguments
Examiner’s Remarks - 35 USC § 112
The examiner withdraws the rejection in view of applicant’s claim amendment.
Examiner’s Remarks - 35 USC § 103
With regards to applicant’s remarks concerning applicant’s claim limitation element(s) of, “responsive to receiving the request, generating a first data asset”, the examiner notes that Li teaches in par. 0018 the following: “secure data backup and recovery is shown, in accordance with some embodiments of the present invention. At step 205, the data to be backed up is identified. As described above with reference to FIG. 1, this may be done with input from the user”. Li teaches in par. 0018 the following: “or it could be prompted by a message received by the electronic device 100 (with any selection of data perhaps having to be authorized by the trusted backup and recovery function 125).”. Li further teaches in par. 0018 the following: “At step 210, the backup data and the unique and unalterable ID 115 (hereafter called the device ID 115) are encoded for integrity and authentication using the cryptographic key 110 and an integrity function, generating a backup data set.”. The examiner notes that Li tell us that the user can make an input (i.e., request) or it’s a system related function. The examiner respectfully contends that either way a request for a backup must be made in order to start the backup process.
With regards to applicant’s remarks of, “Li’s Device ID is not “Asset List”, the examiner respectfully notes that the current claim structure of applicant’s independent claims 1, 10 and 16 does not explicitly restrict the structure of applicant’s “asset list” to a specific implementation. As such the examiner contends that there many reasonable implementations of a “asset list” that can be interpreted. First, the examiner draws attention to par. 0012 where Li teaches the following: “The electronic device 100 comprises a read/write memory 120 that is coupled to a trusted backup and recovery function 125 that can encode a portion of the data in the read/write memory 120 that has been identified as backup data, and send the encoded backup data to be stored in a backup memory 180”. Secondly, the examiner notes par. 0013 of Li where the following is disclosed: “…and the backup memory 180 is located in another electronic device that is accessed by a wireless link 170 that is established in response to the trusted backup and recovery function 125 sending the encoded data.”. The examiner notes that Li’s “backup memory” comprises a list of assets associated with devices. As such the examiner respectfully contends that in this instance Li’s backup memory maintaining the device related assets can reasonably be considered to be functionally equivalent to applicant’s “asset list”. The examiner adds that Li’s backup memory will maintain a table with device ids as keys to determine which specific image structures (i.e., assets) are associated with that particular device with that specific device id. These structures will be retrieved based on the associated saved device id.
With regards to applicant’s remarks of, “Neither Li, Timashev, nor Basu Teaches "Generating a Third Data Asset Comprising at Least One Secure Data Asset Referenced by the Asset List”, the examiner respectfully notes again that the current claim structure of applicant’s independent claims 1, 10 and 16 do not explicitly restrict the structure of applicant’s “asset list” to a specific implementation. As such the examiner contends that there many reasonable implementations of a “asset list” that can be interpreted. The examiner contends that applicant’s claim limitation(s) has been amended to read, “generating a third data asset by signing at least one secure data asset referenced by the asset list”. As such, the examiner introduces the teachings of prior art reference PARK (US Patent Publication No. 2021/0209219) to the record. The examiner notes that PARK discloses generating data structures (i.e., third data asset) by way of a signing process in conjunction with a list of image related assets (i.e., “asset list”). See rejection below. In view of the new claim amendment(s) and newly cited teachings of PARK in this instance, the examiner contends that applicant’s remarks are now mute.
With regards to applicant’s remarks pertaining to applicant’s claim limitation element of, “Timashev Does Not Teach "Responding to the Request by Sending the Verification Package Comprising the First Data Asset, the Second Data Asset, and the Third Data Asset”, the examiner notes the teachings of prior art reference AGRAWAL et al. (US Patent Publication No. 2016/0078068). The examiner notes that AGRAWAL teaches the utilization of three data structures at verification time for the purpose of verifying backup data. See rejection below.
With regards to applicant’s remarks concerning the motivation to combine, the examiner respectfully contends that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
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.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US Patent Publication No. 2005/0283662 and Li hereinafter) in view of AGRAWAL et al. (US Patent Publication No. 2016/0078068 and AGRAWAL hereinafter) and further in view of PARK (US Patent Publication No. 2021/0209219).
As to claims 1 and 16, Li teaches a method comprising:
receiving, by a first platform, a request to generate a verification package for restoring a backup image at a second platform (i.e. …teaches in figure 2 …figure element 216 …retrieve the backup data set);
responsive to receiving the request, generating a first data asset (i.e.., … Li teaches in par. 0018 the following: “secure data backup and recovery is shown, in accordance with some embodiments of the present invention. At step 205, the data to be backed up is identified. As described above with reference to FIG. 1, this may be done with input from the user,”. Teaches in par. 0018 the following: “or it could be prompted by a message received by the electronic device 100 (with any selection of data perhaps having to be authorized by the trusted backup and recovery function 125).”. Further teaches in par. 0018 the following: “At step 210, the backup data and the unique and unalterable ID 115 (hereafter called the device ID 115) are encoded for integrity and authentication using the cryptographic key 110 and an integrity function, generating a backup data set.”. The examiner notes that Li tell us that the user can make a input (i.e., request) or it’s a system related function. Either way a request for a backup must be made in order to start the backup process);
generating a second data asset based on the first data asset and an asset list associated with the backup image (i.e., Li teaches in par. 0019 the following: “generates decoded backup data and decoded device identification and an integrity value by decoding the retrieved backup data set at step 220 using the integrity function of the trusted backup and recovery function 125 and the cryptographic key 110.”. the examiner respectfully notes that the current claim structure of applicant’s independent claims 1, 10 and 16 does not explicitly restrict the structure of applicant’s “asset list” to a specific implementation. As such the examiner contends that there many reasonable implementations of a “asset list” that can be interpreted. First, the examiner draws attention to par. 0012 where Li teaches the following: “The electronic device 100 comprises a read/write memory 120 that is coupled to a trusted backup and recovery function 125 that can encode a portion of the data in the read/write memory 120 that has been identified as backup data, and send the encoded backup data to be stored in a backup memory 180”. Secondly, the examiner notes par. 0013 of Li where the following is disclosed: “…and the backup memory 180 is located in another electronic device that is accessed by a wireless link 170 that is established in response to the trusted backup and recovery function 125 sending the encoded data.”. The examiner notes that Li’s “backup memory” comprises a list of assets associated with devices. As such the examiner respectfully contends that in this instance Li’s backup memory maintaining the device related assets can reasonably be considered to be functionally equivalent to applicant’s “asset list”. The examiner adds that Li’s backup memory will maintain a table with device ids as keys to determine which specific image structures (i.e., assets) are associated with that particular device with that specific device id. These structures will be retrieved based on the associated saved device id.).
Li does not expressly teach:
and responding to the request by sending the verification package comprising the first data asset, the second data asset, and the third data asset.
In this instance the examiner notes the teachings of prior art reference AGRAWAL.
AGRAWAL teaches in par. 0012 the following: “system maintains and consults a primary table, a deduplication chunk table, and a chunk integrity table to improve data verification…”. The examiner contends that three data structures are used to verify backup data. Teaches in par. 0031 the following: “the system uses a primary table in a deduplication database to generate a deduplication chunk table and a chunk integrity table to aid in the deduplication data verification process.”. Teaches in par. 0302 the following: “the deduplication chunk table 252 is created during the data verification process”. Teaches in par. 0305 the following: “the chunk integrity table 254 is derived from the data stored in the secondary storage devices 108. As illustrated in FIG. 6, the chunk integrity table 254 includes, for each chunk in the backup that includes at least one linked data block (e.g., chunks 301-303)”. Teaches in par. 0306 the following: “the chunk integrity table 254 is created during the data verification process.”. The examiner further notes that AGRAWAL’s discloses receiving a request to verify backup data. See figure 11, figure element(s) 1102.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Li with the teachings of AGRAWAL by having their system comprise an enhanced backup verification process. One would have been motivated to do so to provide a simple and effective means to afford a more precise security system, wherein the enhanced backup verification process helps facilitate improved security and makes it easier to provide data integrity by improving the security.
The system of Li and AGRAWAL does not expressly teach:
generating a third data asset by signing at least one secure data asset referenced by the asset list.
In this instance the examiner notes the teachings of prior art reference PARK.
PARK teaches as part of his claim 24 claim limitation element(s) the following: “generating a second signed program image, the second signed program image including the second binary image and the third signature.”. The examiner notes that figure 8, figure element(s) 82 and 83 illustrates a data structure that is the functional equivalency to applicant’s asset list. The examiner notes that figure element(s) 82 and 83 list first, second, third binary image.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Li and AGRAWAL with the teachings of PARK by having their system comprise an enhanced data asset management process. One would have been motivated to do so to provide a simple and effective means to verify computer data assets, wherein the enhanced data asset management process helps facilitate system integrity and makes it easier to provide system security.
As to claim 2, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, wherein the first platform comprises a hardware security module (HSM) (i.e., …illustrates in figure 1 a security module).
As to claim 3, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, wherein the first data asset comprises a symmetric key (i.e., …teaches in par. 0024 the following: “A decryption function 1010 (FIG. 10) that is reciprocal to the encryption function 825 (FIG. 8) that was used to encrypt the backup data 805, device ID 115, and hash 820 at step 710 is performed at step 905 (FIG. 9), using the cryptographic key 110. This generates decoded backup data 1015, a decoded device ID 1020, and a decoded hash 1025. These respective decoded data sets 1015, 1020, 1025 are identical to the data sets 805, 115, 820 that formed the encoded backup data set 830 that was stored only when no data errors have occurred in, and no intentional data changes have been made to, the encoded backup data set 830 during the steps of storage 215 and retrieval 216. At step 910, the same hash function 815 used at step 705 is used on the set of data comprising the decoded backup data 1015 and the decoded device ID 1020, generating a verifying hash 1030. When the verifying hash 1030 matches the decoded hash 1025 using the comparison function 1055 at step 915, integrity of the data is established; otherwise integrity has failed. When the integrity has failed, the decoded backup data 1015 from the retrieved backup data set 1005 cannot be used to restore the original backup data 805. In these embodiments of the second type, the integrity function includes the encryption/decryption functions 825, 1010, the hash function 815, and the matching 915 of the decoded 1025 and verifying 1030 hashes. The cryptographic key 110 is a symmetric key.”).
As to claims 4 and 17, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, wherein generating the second data asset comprises:
signing the asset list using a hash function and the first data asset (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415.”),
wherein the signing of the asset list is performed via a hash-based message authentication code (HMAC) operation (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415. By this is meant that a keyed hash function is performed on a set of data that comprises both the backup data 405 and the device ID 115. The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”).
As to claims 5 and 18, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, wherein the asset list is obtained from the second platform (i.e., …illustrates in figure 4 the device ID (i.e., asset list) being obtained).
As to claims 6 and 19, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, wherein generating the third data asset comprises:
identifying a secure data asset associated with the asset list (i.e., …illustrates in figure 4 the device ID (i.e., asset list) being obtained);
and signing the secure data asset using a hash function and the first data asset (i.e., …teaches in par. 0026 the following: “At step 1105 (FIG. 11), a digital signature 1220 (FIG. 12) of the backup data 1205 and the device ID 115 is generated, using a digital signature generation and verification function 1215 and private key portion of the cryptographic key 110, which comprises a public key and a private key. By this is meant that a digital signature generation function of the digital signature generation and verification function 1215 is performed on a set of data that comprises both the backup data 1205 and the device ID 115. The digital signature 1220 may be generated by a well known function such as RSA (Rivest-Shamir-Adleman algorithm). At step 1110, the encoded backup data set 1230 is formed from the backup data 1205, the device ID 115 and the digital signature 1220.”.),
wherein signing of the secure data asset is performed via an HMAC operation (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415. By this is meant that a keyed hash function is performed on a set of data that comprises both the backup data 405 and the device ID 115. The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”).
As to claim 7, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 6, wherein the secure data asset comprises at least one private cryptographic key (i.e., …teaches in par. 0026 the following: “At step 1105 (FIG. 11), a digital signature 1220 (FIG. 12) of the backup data 1205 and the device ID 115 is generated, using a digital signature generation and verification function 1215 and private key portion of the cryptographic key 110, which comprises a public key and a private key. By this is meant that a digital signature generation function of the digital signature generation and verification function 1215 is performed on a set of data that comprises both the backup data 1205 and the device ID 115. The digital signature 1220 may be generated by a well known function such as RSA (Rivest-Shamir-Adleman algorithm). At step 1110, the encoded backup data set 1230 is formed from the backup data 1205, the device ID 115 and the digital signature 1220.”).
As to claims 8 and 20, the system of Li, AGRAWAL and PARK as applied to claim 1 above teaches backup data verification, specifically Li teaches a method of claim 1, further comprising encrypting the first data asset using a fourth data asset (i.e.., …teaches in par. 0017 the following: “The cryptographic key 110 is a set of data that is used in the electronic device 100 during generation of the encoded backup data set and during restoration of the backup data from the encoded backup data set. The cryptographic key 110 may be a symmetric key or a public and private key pair”. …The length and complexity of the cryptographic key 110 are related to the type of security used in an embodiment of the electronic device 100 and the amount of resistance to cryptanalysis that is desired.),
wherein the fourth data asset is included in the request (i.e., …figure 8, illustrates the cryptographic included as part of the request for encrypting data).
As to claim 9, the system of Li, AGRAWAL and PARK as applied to claim 8 above teaches backup data verification, specifically Li teaches a method of claim 8, wherein the fourth data asset comprises a public key of an asymmetric key pair (i.e., …teaches in par. 0017 the following: “The cryptographic key 110 is a set of data that is used in the electronic device 100 during generation of the encoded backup data set and during restoration of the backup data from the encoded backup data set. The cryptographic key 110 may be a symmetric key or a public and private key pair”. …The length and complexity of the cryptographic key 110 are related to the type of security used in an embodiment of the electronic device 100 and the amount of resistance to cryptanalysis that is desired.).
As to claim 10, Li teaches a method comprising:
performing a restore operation on the backup image (i.e., …teaches in par. 0018 the following: “use a received backup data set to restore the backup data.”);
performing a verification operation of the second data asset based on the first data asset and the asset list (i.e., …teaches in par. 0021 the following: “When the verifying keyed hash 630 matches the decoded keyed hash 625 using the comparison function 655 at step 515, integrity of the data is established; otherwise integrity has failed. When the integrity has failed, the backup data 610 from the retrieved backup data set 605 cannot be used to restore the original backup data 405.”);
performing a verification operation of the third data asset based on the asset list (i.e., …teaches in par. 0022 the following: “the decoded device ID 640 recovered from the retrieved backup data set 605 is compared to the device ID 115 at step 225 using comparison function 650, and when they match and the integrity has been established”);
and responsive to determining that the verification operation of the second data asset and the verification operation of the third data asset were successful (i.e., …teaches in par. 0021 the following: “…using the comparison function 655 at step 515, integrity of the data is established; otherwise integrity has failed. When the integrity has failed, the backup data 610 from the retrieved backup data set 605 cannot be used to restore the original backup data 405.”).
Li does not expressly teach:
receiving, by a processor, a request to restore a backup image, wherein the request comprises the backup image, a first data asset, a second data asset, an asset list,
sending a response indicating that the restore operation of the backup asset was successfully performed.
In this instance the examiner notes the teachings of prior art reference AGRAWAL.
With regards to applicant’s claim limitation element of, “receiving, by a processor, a request to restore a backup image, wherein the request comprises the backup image, a first data asset, a second data asset, a third data asset, and an asset list”, AGRAWAL teaches as part of his claim 15 claim element(s) the following: “a request to verify data in a backup…”. AGRAWAL teaches in par. 00365 the following: “the routine 1100 verifies whether the deduplication database and the SFiles are synched based on the deduplication chunk table and the generated first and second values. For example, the routine 1100 may determine a sum of PIDs for the respective chunks and a sum of squared PIDs for the respective chunks by parsing the SFiles. The determined sum of PIDs and the determined sum of squared PIDs may then be compared with the first value and the second value, respectively”.
With regards to applicant’s claim limitation element of, “sending a response indicating that the restore operation of the backup asset was successfully performed”, teaches in par. 0355 the following: “The routine 1000 may provide a notification if the SFile container did not pass data verification.”. AGRAWAL teaches in his claim 7 limitation(s) the following: “response to a notification that verification of the data in the backup is complete”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Li with the teachings of AGRAWAL by having their system comprise an enhanced backup verification process. One would have been motivated to do so to provide a simple and effective means to afford a more precise security system, wherein the enhanced backup verification process helps facilitate improved security and makes it easier to provide data integrity by improving the security.
The system of Li and AGRAWAL does not expressly teach:
a third data asset generated by signing at least one secure data asset referenced by the asset list.
In this instance the examiner notes the teachings of prior art reference PARK.
PARK teaches as part of his claim 24 claim limitation element(s) the following: “a second signed program image, the second signed program image including the second binary image and the third signature.”. The examiner notes that figure 8, figure element(s) 82 and 83 illustrates a data structure that is the functional equivalency to applicant’s asset list. The examiner notes that figure element(s) 82 and 83 list a first, second, third binary image.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Li and AGRAWAL with the teachings of PARK by having their system comprise an enhanced data asset management process. One would have been motivated to do so to provide a simple and effective means to verify computer data assets, wherein the enhanced data asset management process helps facilitate system integrity and makes it easier to provide system security.
As to claim 11, the system of Li, AGRAWAL and PARK as applied to claim 10 above teaches backup data verification, specifically Li teaches a method of claim 10, wherein performing the verification operation of the second data asset comprises:
signing the asset list using a hash function and the decrypted first data asset (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415. By this is meant that a keyed hash function is performed on a set of data that comprises both the backup data 405 and the device ID 115. The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”),
wherein the signing is performed via a hash-based message authentication code (HMAC) operation (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415. By this is meant that a keyed hash function is performed on a set of data that comprises both the backup data 405 and the device ID 115. The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”);
comparing the signed asset list with the second data asset (i.e., …teaches in par. 0022 the following: “the decoded device ID 640 recovered from the retrieved backup data set 605 is compared to the device ID 115 at step 225 using comparison function 650, and when they match and the integrity has been established”);
and determining that the signed asset list and the second data asset match (i.e., …teaches in par. 0022 the following: “the decoded device ID 640 recovered from the retrieved backup data set 605 is compared to the device ID 115 at step 225 using comparison function 650, and when they match and the integrity has been established”).
As to claim 12, the system of Li, AGRAWAL and PARK as applied to claim 10 above teaches backup data verification, specifically Li teaches a method of claim 10, wherein performing the verification operation of the third data asset comprises:
identifying a secure data asset associated with the asset list (i.e., …teaches in par. 0015 the following: “the electronic device 100 has a unique and unalterable identification (ID) 115 and a cryptographic key 110 that are coupled to the trusted backup and recovery function 125.”),
wherein the secure data asset comprises at least one cryptographic key (i.e., …teaches in par. 0015 the following: “the electronic device 100 has a unique and unalterable identification (ID) 115 and a cryptographic key 110 that are coupled to the trusted backup and recovery function 125.”),
signing the secure data asset using a hash function and the first data asset (i.e., …teaches in par. 0020 the following: “… The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”),
wherein the signing of the secure data is performed via an HMAC operation (i.e., …teaches in par. 0020 the following: “a keyed hash 420 (FIG. 4) of the backup data 405 and the device ID 115 is generated, using the cryptographic key 110 and a keyed hash function 415. By this is meant that a keyed hash function is performed on a set of data that comprises both the backup data 405 and the device ID 115. The keyed hash 420 may be generated by a well known function such as HMAC (hash-based message authentication code), using a well known hash function such as SHA-1 (secure hash algorithm--version 1). At step 310 (FIG. 3), the encoded backup data set 410 is formed from the backup data 405, the device ID 115 and the keyed hash 420.”);
comparing the signed secure data asset with the third data asset (i.e., …teaches in par. 0022 the following: “the decoded device ID 640 recovered from the retrieved backup data set 605 is compared to the device ID 115 at step 225 using comparison function 650, and when they match and the integrity has been established”);
and determining that the signed secure data asset and the third data asset match (i.e., …teaches in par. 0022 the following: “the decoded device ID 640 recovered from the retrieved backup data set 605 is compared to the device ID 115 at step 225 using comparison function 650, and when they match and the integrity has been established”).
As to claim 13, the system of Li, AGRAWAL and PARK as applied to claim 10 above teaches backup data verification, specifically Li teaches a method of claim 10, further comprising decrypting the first data asset using a fourth data asset (i.e., …teaches in par. 0024 the following: “A decryption function 1010 (FIG. 10) that is reciprocal to the encryption function 825 (FIG. 8) that was used to encrypt the backup data 805, device ID 115, and hash 820 at step 710 is performed at step 905 (FIG. 9), using the cryptographic key 110. This generates decoded backup data 1015, a decoded device ID 1020, and a decoded hash 1025).
As to claim 14, the system of Li, AGRAWAL and PARK as applied to claim 10 above teaches backup data verification, specifically Li teaches a method of claim 10, wherein the fourth data asset comprises a private key of an asymmetric key pair (i.e.., …teaches in par. 0017 the following: “The cryptographic key 110 is a set of data that is used in the electronic device 100 during generation of the encoded backup data set and during restoration of the backup data from the encoded backup data set. The cryptographic key 110 may be a symmetric key or a public and private key pair).
As to claim 15, the system of Li, AGRAWAL and PARK as applied to claim 10 above teaches backup data verification, specifically Li teaches a method of claim 10, wherein the processor is comprised by an HSM (i.e., …illustrates in figure 1 a security module).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRYAN F WRIGHT/ Examiner, Art Unit 2497