DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 01/20/2026.
In the instant Amendment: Claims 1, 8-9, 16-17 have been amended. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants' arguments in the instant Amendment, filed on 01/20/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Roth and Liu fail to disclose “storing the security context on a volatile memory of the second device” and “determining a second digest using the data structure, the nonce value, and the public key.” See Remarks at 7-8 (emphasis added).
The examiner respectfully disagrees because these arguments are not persuasive.
Applicant first alleges that Roth in view of Liu fails to disclose the claimed “storing the security context on a volatile memory of the second device” on the basis that Liu’s “generic statement does not teach or suggest storing security context or operating system in the volatile memory.” Id. at 8 (emphasis added). Liu explains that “[a] memory device 130 may include one or more memory arrays of any type of memory cells (e.g., non-volatile memory cells, volatile memory cells, or any combination thereof). Furthermore, security information (e.g., hashes, digital signatures) can be stored in a write-protected part of the memory device. See Liu ¶¶ [0019], [0070]. Because the memory device comprises volatile and non-volatile components, and both components can be indispensable during a computing operation (e.g., data processing, storing of data during data processing or long term), Liu teaches “storing the security context on a volatile memory of the second device” of amended claim 1.
In regards to, “determining a second digest using the data structure, the nonce value, and the public key,” Roth teaches generating a digital signature from a hash of a public key (i.e., signing the hash of a public key with a signing key). See Ross FIG. 58, col. 9: 1-4; col. 12: 44-49. Liu further teaches generating hash value associated with a device nonce. See Liu ¶¶ [0065], [0067], [0070]. Thus, Ross in combination with Liu teaches “determining a second digest using the data structure, the nonce value, and the public key” of claim 1.
In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejection of claims 9 and 17, which recite similar matters, is similarly maintained.
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 discloses as set forth in section 102 of this title, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Roths et al. (“Roths,” US 10547613, patented Jan. 28, 2020) in view of Liu (“Liu,” US 20230325507, filed April 22, 2022).
Regarding claim 1, Roths discloses A method comprising:
receiving, by a first device from a second device, a request to provision a security context for the second device (Roths FIG. 5, col. 12: 24-36, 36-41. As shown in FIG. 5, the process begins when the new device sends a provisioning request, which might be in the form of a Bluetooth™ advertisement message. The process might be driven by program code stored in the new device and executed by a processor in the new device. In a first step, the new device powers up and determines that it needs to be provisioned. It then sends a provisioning request message or advertisement out to any listening ZTS-aware provisioning devices. The ZTS-aware provisioning device simply forwards the request to the DPS and the request includes a client nonce and a unique identifier of the new device. In response, the DPS sends a message to the ZTS-aware provisioning device that includes the client nonce, the DHA public key, and the Side A values, all signed by the DPS private key held by the DPS. The ZTS-aware provisioning device forwards the request to the new device.);
transmitting a nonce value to the second device (Roths FIG. 5, col. 12: 37-41. In response, the DPS sends a message to the ZTS-aware provisioning device that includes the client nonce, the DHA public key, and the Side A values, all signed by the DPS private key held by the DPS. The ZTS-aware provisioning device forwards the request to the new device. At this point, no private information has been conveyed.);
receiving, from the second device, a data structure encoding the security context and a cryptographically signed digest of a combination of the data structure, [the nonce value], and a public key (Roths FIG. 5, col. 9: 1-4; col. 12: 44-49. The hash of the public key of the device might be signed using a private key of the manufacturer. This allows the DPS to validate that the device is not a counterfeit device during the provisioning process. Once the new device has verified the DPS signature, it generates the Side B Diffie-Hellman values and sends a reply that contains the new device's copy of the DHA public key, a certificate chain of the device manufacturer, the Side A values, and the Side B values, where the Side A/B values are signed by the DHA private key.).
Roths does not explicitly disclose: a cryptographically signed digest of a combination of…the nonce value;
determining a first digest using the nonce value and cryptographically signed digest; determining a second digest using the data structure, the nonce value, and the public key; and
responsive to determining that the first digest matches the second digest, provisioning the security context for the second device by storing the security context on the volatile memory of the second device.
However, in an analogous art, Liu discloses a method comprising the step of:
a cryptographically signed digest of a combination of…the nonce value (Liu FIG. 3, [0061], [0064], [0068]. In other examples, a nonce generator within the device 302 may be used to generate the unique value. At 325, a request for the operating system information may be transmitted from the device 302 to the server 304. The request for the operating system information may identify the particular operating system information being requested (e.g., the specific operating system, the specific operating system release, the specific operating system update). The request for the operating system information may also include the unique value generated at the device 302. The security-elevated write command may include the command identification code, the unique value generated by the device, the server-generated nonce, the operating system information, and the signature. The transmission of the security-elevated write command may be represented as cmd_id∥valueunq∥noncesvr∥OS_Info∥s. If a monotonic counter at the device 302 is used to generate the unique value, then valueunq may be replaced by the variable counter. If a nonce generator at the device 302 is used to generate the unique value, then valueunq may be replaced by the variable noncedev.);
determining a first digest using the nonce value and cryptographically signed digest; determining a second digest using the data structure, the nonce value, and the public key (Liu [0065], [0067], [0070]. To generate the security-elevated write command and to obtain a server hash value (hsvr), the server 304 may calculate the hash of a combined set of data generated at the server 304. The combined set of data may include a command identification code used to identify the security-elevated write command (e.g., 0x12); the unique value received from the device 302; a nonce generated (e.g., randomly) by the server 304 (which may be referred to as a server-generated nonce); and the operating system information. After calculating the server hash value hsvr, the server 304 may sign the server hash value using a private key of the server 304 (that is paired with the public key of the server 304 stored at the device 302) to obtain a signature (ssvr). In some examples, the unique value may be a monotonic value generated at the device 302. In other examples, the unique value may be a nonce generated at the device 302. Validating the security-elevated write command may further include calculating, by the device cryptography component, a hash of the received information to obtain a device hash value (hdev). An equation for calculating the device hash value may be represented as hdev=hash(cmd_id∥valueunq∥noncesvr∥OS_Info). After calculating the device hash value, the device 202 may use the public key of the server 304 to determine whether the device hash value matches the signature of the server 304.). ; and
responsive to determining that the first digest matches the second digest, provisioning the security context for the second device by storing the security context on the volatile memory of the second device (Liu [0070]. Validating the security-elevated write command may further include calculating, by the device cryptography component, a hash of the received information to obtain a device hash value (hdev). An equation for calculating the device hash value may be represented as hdev=hash(cmd_id∥valueunq∥noncesvr∥OS_Info). After calculating the device hash value, the device 202 may use the public key of the server 304 to determine whether the device hash value matches the signature of the server 304. Otherwise, if the device hash value and the signature of the server 304 match and the transmitted and received unique values match, the write operation to the write-protected are of memory in device 302 may proceed. At 345, the operating system information may be written (e.g., by the memory system controller of the device 302) to the write-protected area of memory—e.g., based on the security-elevated write command being validated [for volatile memory, see [0019], [0033]].).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Roths and Liu to include the step of: responsive to determining that the first digest matches the second digest, provisioning the security context for the second device by storing the security context on the volatile memory. One would have been motivated to provide users with a means for validating the signature of software/OS security information before provisioning a new or updated version of software/OS to a device. (See Liu [0070].)
Regarding claim 2, Roths and Liu disclose the method of claim 1.
Roths further discloses controlling, using the security context, access of an application executing on the first device to a resource (Roths FIG. 5, col. 13: 8-21; col. 19: 45-50. With the network credentials, the new device will try to connect to the network and optionally report back the results to the DPS, via the ZTS-aware provisioning device, encrypted using the Diffie-Hellman shared secret. Once confirmed, the DPS can record in its device database (or send a message to a system that maintains the device database) that the particular device is provisioned. Then, if the device appears subsequently for provisioning the DPS can require additional confirmation steps from the end user or a new owner of the device. In this manner, the manufacturer registration is also seamlessly handled. The DPS may validate device details in response to a validation request from the companion application, authenticate the companion application to determine that the new device is authorized to have network credentials of the target wireless network, and send the network credentials to the companion application for forwarding to the new device or send them to the new device through another channel.).
Regarding claim 3, Roths and Liu disclose the method of claim 1. Liu further discloses generating the nonce value and storing the nonce value in the volatile memory (Liu [0019], [0061]. A memory device 130 may include one or more memory arrays of any type of memory cells (e.g., non-volatile memory cells, volatile memory cells, or any combination thereof). In other examples, a nonce generator within the device 302 may be used to generate the unique value.).
The motivation is the same as that of claim 1 above.
Regarding claim 4, Roths and Liu disclose the method of claim 1. Liu further discloses obtaining the nonce value from the volatile memory (Liu [0019], [0061]. A memory device 130 may include one or more memory arrays of any type of memory cells (e.g., non-volatile memory cells, volatile memory cells, or any combination thereof). In other examples, a nonce generator within the device 302 may be used to generate the unique value. The combined set of data may include a command identification code used to identify the security-elevated write command (e.g., 0x12); the unique value received from the device 302; a nonce generated (e.g., randomly) by the server 304 (which may be referred to as a server-generated nonce); and the operating system information.).
The motivation is the same as that of claim 1 above.
Regarding claim 5, Roths and Liu disclose the method of claim 1.
Roths further discloses receiving, from the second device, the public key (Roths FIG. 5, col. 9: 1-4. The hash of the public key of the device might be signed using a private key of the manufacturer. This allows the DPS to validate that the device is not a counterfeit device during the provisioning process.).
Liu further discloses wherein the first digest is determined by decrypting the cryptographically signed digest using the public key (Liu [0070]. Validating the security-elevated write command may further include calculating, by the device cryptography component, a hash of the received information to obtain a device hash value (hdev). An equation for calculating the device hash value may be represented as hdev=hash(cmd_id∥valueunq∥noncesvr∥OS_Info). After calculating the device hash value, the device 202 may use the public key of the server 304 to determine whether the device hash value matches the signature of the server 304. Otherwise, if the device hash value and the signature of the server 304 match and the transmitted and received unique values match, the write operation to the write-protected are of memory in device 302 may proceed. At 345, the operating system information may be written (e.g., by the memory system controller of the device 302) to the write-protected area of memory—e.g., based on the security-elevated write command being validated [for volatile memory, see [0019], [0033]].).
The motivation is the same as that of claim 1 above.
Regarding claim 6, Roths and Liu disclose the method of claim 1. Roths further discloses wherein the cryptographically signed digest is obtained using a private key corresponding to the public key (Roths col. 12: 37-41. n response, the DPS sends a message to the ZTS-aware provisioning device that includes the client nonce, the DHA public key, and the Side A values, all signed by the DPS private key held by the DPS. The ZTS-aware provisioning device forwards the request to the new device.).
Regarding claim 7, Roths and Liu disclose the method of claim 6. Roths further discloses wherein the private key and the public key are associated with an application executing on the second device (Roths FIG. 15, col. 19: 35-40. FIG. 15 is a swim diagram illustrating a process using an Elliptic Curve Diffie-Hellman (ECDH) protocol. In this process, a companion application, such as the DPS app, runs on a smartphone or other device of the end user and is able to communicate with the unprovisioned device. The companion application makes an ECDH request and the unprovisioned device provides an ECDH response [Note the ECDH protocol uses public/private keys for establishing a shared secret over an insecure channel].).
Regarding claim 8, Roths and Liu disclose the method of claim 1. Liu further discloses wherein the data structure comprises an identifier associated with the application, one or more context identifiers and at least one access state for each of the one or more context identifiers (Liu [0070]. Validating the security-elevated write command may further include calculating, by the device cryptography component, a hash of the received information to obtain a device hash value (hdev). An equation for calculating the device hash value may be represented as hdev=hash(cmd_id∥valueunq∥noncesvr∥OS_Info). After calculating the device hash value, the device 202 may use the public key of the server 304 to determine whether the device hash value matches the signature of the server 304. Otherwise, if the device hash value and the signature of the server 304 match and the transmitted and received unique values match, the write operation to the write-protected are of memory in device 302 may proceed. At 345, the operating system information may be written (e.g., by the memory system controller of the device 302) to the write-protected area of memory—e.g., based on the security-elevated write command being validated [for volatile memory, see [0019], [0033]].).
The motivation is the same as that of claim 1 above.
Regarding claim 9, claim 9 is directed to a system corresponding to the method of claim 1. Claim 9 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed toa a system corresponding to the method of claim 2. Claim 10 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed toa a system corresponding to the method of claim 3. Claim 11 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed toa a system corresponding to the method of claim 4. Claim 12 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed toa a system corresponding to the method of claim 5. Claim 13 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed toa a system corresponding to the method of claim 6. Claim 14 is similar to claim 6 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed toa a system corresponding to the method of claim 7. Claim 15 is similar to claim 7 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed toa a system corresponding to the method of claim 8. Claim 16 is similar to claim 8 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 1. Claim 17 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 2. Claim 18 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 3. Claim 19 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 4. Claim 20 is similar to claim 4 and is therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. 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.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439