DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1 and 3-20 have been examined.
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 09/23/2026 has been entered.
Response to Arguments
Applicant's arguments filed 09/23/2026 have been fully considered but they are not persuasive. As per the applicant’s arguments that prior art of record Passaglia does not teach: matching against “either the first or second local HATC”, the examiner respectfully disagrees. The examiner also disagrees with the applicant’s interpretation of authentication code 121 as the first HATC and second HATC (Remarks – page 3: The Examiner has provided no justification for interpreting a single authentication code 121 as a first HATC and a second HATC, as presented in the present claims and explained in Applicant previous response.) Passaglia teaches: column 7, lines 6-10: At block 153, a signal 131 including at least the authentication code 121 may be sent by electronic device 110. Column 8, lines 31-67: Electronic device 110 may send the signal 131 via a wireless connection such as Bluetooth, BLE, etc. At block 155, server 130 may receive all or part of the signal 131, i.e., the authentication code 121 is received by server 130 in signal 131 is equivalent to the received “peer HATC” in claim 1 and not the first and second HATC. Passaglia further teaches: column 9, lines 5-32: For each known unique identifier, server 130 may determine possible authentication codes based on different clock (counter) values. the HMAC key and counter data to determine the authentication code. The server 130 may use counter data corresponding to the current time or a known counter data to determine the authentication code. The table may alternatively, or additionally, determine counter values near the current time or known counter data. For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 13:00 and 15:00. In this manner, table 141 may be generated which may include a plurality of records having authentication codes with a corresponding unique identifier (i.e., seed value), device identifier, and counter data, i.e., the server generates authentication codes corresponding to counter data values of 13:00 and 15:00 (first and second changed A-T count values that differ from the stored current time 14:00 by a first and second amount of -1 and +1) and the authentication code corresponding to 13:00 is the first local HATC and the authentication code corresponding to 15:00 is the second local HATC. Passaglia further teaches: column 9, lines 62-67: At block 157, server 130 may determine a match in table 141 to authentication code 121, or a truncated version of authentication code 121. Specifically, server 130 may find an authentication code in table 141 matching the value of authentication code 121 in signal 131, i.e., the authentication code 121 (received peer HATC) received by the server from electronic device is compared to the local authentication codes generated by the server corresponding to counter values of 13:00 and 15:00 (first and second local HATCs). Therefore, Passaglia teaches authenticating the electronic device based on the received authentication code 121 (received peer HATC) matching either of the local authentication codes generated by the server (first and second local HATC).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3-5, 7, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over prior art of record US 20140105396 to Engelien-Lopes (hereinafter Lopes) and prior art of record US 11606687 to Passaglia et al (hereinafter Passaglia).
As per claim 1, Lopes teaches:
A method, comprising:
establishing a wireless encrypted connection (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3. As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. It was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that paired bluetooth devices establish an encrypted connection between them);
establishing a long term encryption key (LTK) and an anti-tracking (A-T) count value for a peer device (Lopes: [0058]: As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. [0021]: For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value);
storing the LTK and A-T count value in a nonvolatile memory circuit (Lopes: [0021]: The device may store a current count value in non-volatile memory. [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. [0026] The identity-resolving key may be a 128-bit number. It may be stored in a memory of the device);
receiving a communication that includes (Lopes: [0031] The device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device);
generating at least one local HATC by executing a predetermined hash function on at least the LTK and (Lopes: [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. [0047]: In one set of embodiments, the value derived from a counter in the device address may be, or may comprise, an encrypted value derived from a counter (e.g. an encrypted count value). It may be encrypted with a device-specific key, such as the identity-resolving key),
authenticating the received peer HATC if it matches (Lopes: [0031]: It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device);
in response to the peer HATC being authenticated, communicating with the peer device; and in response to the peer HATC not being authenticated, not communicating with the peer device (Lopes: [0031]: After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed).
Lopes teaches a communication that includes a peer hashed anti-tracking count but does not teach: a communication that includes an identity value corresponding to the peer device and includes a peer hashed anti-tracking count (HATC) different from the identity value. Also, Lopes teaches executing a hash on the received value and identity resolving key but does not teach: executing a predetermined hash function on at least the LTK and a changed A-T count value that varies from the stored A-T count value by a predetermined amount, including generating a first local HATC with a first changed A-T count value that varies from the stored A-T count value by a first amount, and generating a second local HATC with a second changed A-T count value that varies from the stored A-T count value by a second amount different than the first amount; authenticating the received peer HATC if it matches either the first or second local HATC. However, Passaglia teaches:
a communication that includes an identity value corresponding to the peer device and includes a peer hashed anti-tracking count (HATC) different from the identity value (Passaglia: column 6, lines 18-22 and 34-40: Unique identifier 124 and/or device identifier 127 may be or may include or be based on the MAC address or other data unique to the electronic device 110. At block 152, authentication code 121 may be determined using the hash function key and counter data. In the example where the hash function key 121 is an HMAC, an HMAC may be performed using the HMAC key and counter data to determine the authentication code 121. Column 7, lines 6-16: At block 153, a signal 131 including at least the authentication code 121 may be sent by electronic device 110. In addition to the authentication code 121, the signal 131 may further include one or more of the following, signal data, product data, counter data, and/or a payload. The signal data may include a MAC address associated with the signal);
executing a predetermined hash function on at least the LTK and a changed A-T count value that varies from the stored A-T count value by a predetermined amount, including generating a first local HATC with a first changed A-T count value that varies from the stored A-T count value by a first amount, and generating a second local HATC with a second changed A-T count value that varies from the stored A-T count value by a second amount different than the first amount (Passaglia: column 9, lines 4-36: Server 130 may maintain a table of registered electronic devices and their corresponding unique identifiers and device identifier. For each known unique identifier, server 130 may determine possible authentication codes based on different clock (counter) values, i.e., the server generates a plurality of authentication codes using different counter values for each unique identifier. As explained above with respect to electronic device 110, an authentication code may be calculated using a hash function key, which may be determined using a KDF. The authentication code may be determined using the hash function key and counter data. The server 130 may use counter data corresponding to the current time or a known counter data to determine the authentication code. The table may additionally, determine counter values near the current time or known counter data. For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records (first and second local HATC) for counter data values of 13:00 (counter data that is different by -1) and 15:00 (counter data that is different by +1). In this manner, table 141 may be generated which may include a plurality of records having authentication codes with a corresponding unique identifier (i.e., seed value), device identifier, and counter data, i.e., for every unique identifier, the server generates authentication codes for counter data values of 13:00, 14:00, and 15:00 (plurality of records) and store them in the table 141);
authenticating the received peer HATC if it matches either the first or second local HATC (Passaglia: column 9, lines 62-67: At block 157, server 130 may determine a match in table 141 to authentication code 121, or a truncated version of authentication code 121. Specifically, server 130 may find an authentication code in table 141 matching the value of authentication code 121 in signal 131, or a truncated portion thereof, i.e., the authentication code 121 sent by the electronic device and received by the server in block 155 is compared with the plurality of authentication codes in table 141 (authentication codes for counter data values of 13:00, 14:00, and 15:00) to determine if any of the authentication codes stored in table 141 matches authentication code 121).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Passaglia in the invention of Lopes to include the above limitations. The motivation to do so would be to track the electronic device (Passaglia: column 2, lines 25-27).
As per claim 3, Lopes in view of Passaglia teaches:
The method of claim 1, wherein: the first changed A-T count value is the stored A-T count value incremented by one; and the second changed A-T count value is the stored A-T count value incremented by two (Passaglia: Column 9, lines 4-36 and 62-67: For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 15:00 (counter incremented by 1). Column 10, lines 11-31: Server 130 may periodically update table 141 with new records based on updated counter data. For example, every minute, ten minutes, hour, etc., new records may be generated by table 141 using the known unique identifiers. A history of records may be maintained by table 141, i.e., updated counter data will have a counter value of 16:00 (counter increased by 2)).
The examiner provides the same rationale to combine Lopes and Passaglia as in claim 1 above.
As per claim 4, Lopes in view of Passaglia teaches:
The method of claim 1, wherein establishing the wireless encrypted connection includes establishing a connection compatible with at least one Bluetooth (BT) standard including Bluetooth Low Energy (Lopes: [0028] The device is preferably configured to operate substantially as a Bluetooth Low Energy device. [0029]-[0030]. [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3. [0070]: It also continues with any required response to the master device, such as establishing a connection with it).
As per claim 5, Lopes in view of Passaglia teaches:
The method of claim 1, wherein establishing the wireless encrypted connection includes establishing a connection compatible with at least one WiFi Aware standard (Passaglia: column 8, lines 31-34: Electronic device 110 may send the signal 131 via a wireless connection such as Wi-Fi. Also, column 7, lines 30-35).
The examiner provides the same rationale to combine Lopes and Passaglia as in claim 1 above.
As per claim 7, Lopes in view of Passaglia teaches:
The method of claim 1, further including: in response to the peer HATC being authenticated, re-establishing a wireless encrypted connection with the peer with at least the LTK (Lopes: [0070] If the checks are passed, the slave device increments the value of LocalCounter and sets RemoteCounter equal to ReceivedCounter. It updates the stored master address and its own address using the new values. It also continues with any required response to the master device, such as establishing a connection with it. [0025]: The device is preferably configured to apply a hash algorithm to the value and the identity-resolving key. [0027] The device is preferably configured to generate the address from the value derived from a counter. The address is preferably the value concatenated with the hash. A least significant octet of the hash may become the least significant octet of the address, while a most significant octet of the value may become the most significant octet of the address, i.e., the first device establishes a connection with the second device based on an address derived from the identity-resolving key. It was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that a Bluetooth connection between devices is encrypted), and in response to receiving a communication from the peer over the re-established encrypted connection, changing the stored A-T count (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0023] The device is preferably configured to increment the counter. It may be configured to do this at regular intervals, or when a particular condition is met. [0030]: Such a device may be configured to change its address by incrementing the counter after completing a connection establishment with a slave device).
As per claim 8, Lopes in view of Passaglia teaches:
The method of claim 7, wherein changing the stored A-T count includes incrementing the stored A-T count (Lopes: [0032] In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes; this may allow the local count value stored by a master device to remain approximately synchronised with a counter used by a second, slave device).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Lopes in view of Passaglia as applied to claim 1 above, and further in view of prior art of record US 20120161936 to Yoon et al (hereinafter Yoon).
As per claim 6, Lopes in view of Passaglia does not teach the limitations of claim 6. However, Yoon teaches:
wherein receiving the communication that includes the identity value and the peer HATC includes requesting the HATC from the peer (Yoon: [0050] That is, in the case where not only the keyed hash values HKm and HKi are the same but also the first and second count values C1 and C2 are the same, the RFID tag device 300 recognizes that the call message transmitted through the reception unit 310 is for the RFID tag device 300. The RFID tag device 300 certifies that the call message has been received from the reader 120 when the keyed hash values HKm and HKi are the same and the first and second count values C1 and C2 are the same. [0051] In response to the certification signal CS, the keyed hash value generating unit 330 calculates a response key value (not illustrated) according to the security value Si, the ID IDi, and the adjusted second count value C2. And, the keyed hash value generating unit 330 generates the keyed hash value HKi by using the response key value. Exemplarily, the keyed hash value generating unit 330 may generate the keyed hash value HKi by using the response key value, the ID IDi, the random number RN, and the adjusted second count value C2. The generated keyed hash value HKi is transmitted to the reader 120 (refer to FIG. 1) through the transmission unit 350, i.e., the HKi is transmitted to the reader by the tag device in response to receiving a call message from the reader).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Yoon in the invention of Lopes in view of Passaglia to include the above limitations. The motivation to do so would be to prevent leakage of communication information (Yoon: [0006]).
Claims 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lopes, Yoon and Passaglia.
As per claim 9, Lopes teaches:
A device, comprising:
a nonvolatile memory configured to store at least a long term encryption key (LTK), an anti- tracking (A-T) count, (Lopes: [0058]: As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. [0021]: For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value. The device may store a current count value in non-volatile memory. [0026] The identity-resolving key may be a 128-bit number. It may be stored in a memory of the device); and
a controller circuits configured to establish wireless encrypted connections (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10. As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. It was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that paired bluetooth devices establish an encrypted connection between them),
receive a communication from a peer device that includes a peer hashed anti-tracking count (HATC) (Lopes: [0031] The device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device.),
generate at least one local HATC by hashing at least the LTK and a (Lopes: [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. [0047]: In one set of embodiments, the value derived from a counter in the device address may be, or may comprise, an encrypted value derived from a counter (e.g. an encrypted count value). It may be encrypted with a device-specific key, such as the identity-resolving key),
authenticate the received peer HATC if it matches (Lopes: [0031]: It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device),
not communicate with the peer device if the peer HATC is not authenticated, and communicate with the peer device if the peer HATC is authenticated (Lopes: [0031]: After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed).
Lopes does not teach: store a nonce value and receive a communication from a peer device that includes a peer address. Also, Lopes teaches executing a hash on the received value and identity resolving key but does not teach: hashing at least the LTK and a changed A-T count value, the changed A-T count value varying from the stored A-T count value by a predetermined amount including a first local HATC with a first changed A-T count that is the stored A-T count value incremented by a first amount, and a second local HATC with a second changed A-T count value that is the stored A-T count value incremented by a second amount different than the first amount, authenticate the received peer HATC if it matches either the first or second local HATC. However, Yoon teaches:
store a nonce value (Yoon: [0033] The random number generating unit 230 generates a random number RN. The random number generating unit 230 provides the generated random number RN to the keyed hash value generating unit 240. [0040]: The reception unit 260 transfers the second count value C2, the keyed hash value HKi, and the random number RN to the comparison unit 270. The second count value C2 and the keyed hash value HKi constitute a response message received from one of the RFID tag devices 130. [0042] The comparison unit 270 compares the keyed hash values HKm and HKi with each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Yoon in the invention of Lopes to include the above limitations. The motivation to do so would be to prevent leakage of communication information (Yoon: [0006]).
Lopes in view of Yoon does not teach the rest of the limitations. However, Passaglia teaches:
receive a communication from a peer device that includes a peer address (Passaglia: column 6, lines 18-22 and 34-40: Unique identifier 124 and/or device identifier 127 may be or may include or be based on the MAC address or other data unique to the electronic device 110. At block 152, authentication code 121 may be determined using the hash function key and counter data. In the example where the hash function key 121 is an HMAC, an HMAC may be performed using the HMAC key and counter data to determine the authentication code 121. Column 7, lines 6-16: At block 153, a signal 131 including at least the authentication code 121 may be sent by electronic device 110. In addition to the authentication code 121, the signal 131 may further include one or more of the following, signal data, product data, counter data, and/or a payload. The signal data may include a MAC address associated with the signal);
hashing at least the LTK and a changed A-T count value, the changed A-T count value varying from the stored A-T count value by a predetermined amount including a first local HATC with a first changed A-T count that is the stored A-T count value incremented by a first amount, and a second local HATC with a second changed A-T count value that is the stored A-T count value incremented by a second amount different than the first amount (Passaglia: column 9, lines 4-36 and 62-67: Server 130 may maintain a table of registered electronic devices and their corresponding unique identifiers and device identifier. For each known unique identifier, server 130 may determine possible authentication codes based on different clock (counter) values , i.e., the server generates a plurality of authentication codes using different counter values for each unique identifier. As explained above with respect to electronic device 110, an authentication code may be calculated using a hash function key, which may be determined using a KDF. The authentication code may be determined using the hash function key and counter data. The table may alternatively, or additionally, determine counter values near the current time or known counter data (stored counter value). For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 13:00 and 15:00 (counter data that is incremented by +1). In this manner, table 141 may be generated which may include a plurality of records having authentication codes with a corresponding unique identifier (i.e., seed value), device identifier, and counter data. Column 10, lines 11-31: Server 130 may periodically update table 141 with new records based on updated counter data. For example, every minute, ten minutes, hour, etc., new records may be generated by table 141 using the known unique identifiers. A history of records may be maintained by table 141 (the updated counter data will have a counter value of 16:00 (counter increased by 2)), i.e., for every unique identifier, the server generates and stores authentication codes for counter data values incremented by a first amount and second amount in table 141),
authenticate the received peer HATC if it matches either the first or second local HATC (Passaglia: column 9, lines 62-67: At block 157, server 130 may determine a match in table 141 to authentication code 121, or a truncated version of authentication code 121. Specifically, server 130 may find an authentication code in table 141 matching the value of authentication code 121 in signal 131, or a truncated portion thereof, i.e., the authentication code 121 sent by the electronic device and received by the server in block 155 is compared with the plurality of authentication codes in table 141 (authentication codes for counter data values of 15:00 and 16:00) to determine if any of the authentication codes stored in table 141 matches authentication code 121).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Passaglia in the invention of Lopes in view of Yoon to include the above limitations. The motivation to do so would be to track the electronic device (Passaglia: column 2, lines 25-27).
As per claim 10, Lopes in view of Yoon and Passaglia teaches:
The device of claim 9, wherein the nonvolatile memory and controller circuits are formed with a same integrated circuit substrate (Lopes: [0046]: Such processing means may comprise any one or more of: … an ASIC).
As per claim 11, Lopes in view of Yoon and Passaglia teaches:
The device of claim 9, wherein: the controller circuits includes counter circuits configured to update the A-T count in the nonvolatile memory (Lopes: [0021]: For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value. The device may store a current count value in non-volatile memory), and arithmetic-logic circuits configured to execute a hash function for hashing at least the LTK and a changed A-T count value (Lopes: [0046]: It preferably comprises processing means for carrying out steps described herein. [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. Yoon: [0032]: Then, the counter 220 provides the increased first counter value C1 to the keyed hash value generating unit 240, the transmission unit 250, and the comparison unit 270. [0034] The keyed hash value generating unit 240 receives the security value Sm and the ID IDm from the memory 210, and receives the first count value C1 from the counter 220. For instance, the keyed hash value generating unit 240 uses the security value Sm, the ID IDm, and the first count value C1 as input values of a hash function to calculate the call key value. And, the keyed hash value generating unit 240 generates a keyed hash value (not illustrated) by using the call key value).
The examiner provides the same rationale to combine Lopes and Yoon as in claim 9 above.
As per claim 12, Lopes in view of Yoon and Passaglia teaches:
The device of claim 9, further including: radio circuits configured to receive packets from, and transmit packets to the peer device that are compatible with at least one wireless standard; wherein the at least one wireless standard is selected from the group of a Bluetooth standard including Bluetooth Low Energy, and a WiFi Aware standard (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3).
As per claim 13, Lopes in view of Yoon and Passaglia teaches:
The device of claim 9, wherein: the controller circuits further includes nonce generator circuits configured to generate nonce values (Yoon: [0033] The random number generating unit 230 generates a random number RN. The random number generating unit 230 provides the generated random number RN to the keyed hash value generating unit 240); and arithmetic logic circuits configured to execute the hash function on at least the changed A-T count, the LTK, and the nonce value (Yoon: [0037] The second hash function calculating block 242 receives the ID IDm, the first count value C1, and the random number RN. The second hash function calculating block 242 receives the call key value Km from the first hash function calculating block 241. The second hash function calculating block 242 uses the ID IDm, the first count value C1, the random number RN, and the call key value Km as input values of a hash function).
The examiner provides the same rationale to combine Lopes and Yoon as in claim 9 above.
As per claim 14, Lopes in view of Yoon and Passaglia teaches:
The device of claim 9, wherein: the controller circuits are configured to generate the first local HATC with a first changed A-T count that is the stored A-T count value incremented by one (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0032] In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes, i.e., the counter is increased by 1 after 1 interval. Passaglia: column 9, lines 4-36 and 62-67: The authentication code may be determined using the hash function key and counter data. The table may alternatively, or additionally, determine counter values near the current time or known counter data (stored counter value). For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 15:00 (counter data that is incremented by +1)), and generate the second local HATC with a second changed A-T count value that is the stored A-T count value incremented by two (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0032] In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes, i.e., the counter is increased by 2 after 2 intervals. Passaglia: Column 10, lines 11-31: Server 130 may periodically update table 141 with new records based on updated counter data. For example, every minute, ten minutes, hour, etc., new records may be generated by table 141 using the known unique identifiers. A history of records may be maintained by table 141, i.e., updated counter data will have a counter value of 16:00 (counter increased by 2)).
The examiner provides the same rationale to combine Lopes in view of Yoon and Passaglia as in claim 9 above.
As per claim 15, Lopes teaches:
A system, comprising:
a first wireless device that includes circuits configured to store at least a long term encryption key (LTK), an antitracking (A-T) count, (Lopes: [0058]: As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. [0021]: For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value. The device may store a current count value in non-volatile memory. [0026] The identity-resolving key may be a 128-bit number. It may be stored in a memory of the device),
establish a wireless encrypted connection with at least the LTK (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10. As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device. After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed, i.e., the connection between the first and second devices is established based on identifying the peer by the peer identity-resolving key and freshness of the count value. It was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that paired Bluetooth devices establish an encrypted connection between them, i.e., an encrypted connection is established based on identifying the peer using the peer identity-resolving key),
receive a communication from a peer device that includes a peer hashed anti- tracking count (HATC) (Lopes: [0031] The device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device.),
generate at least one local HATC by hashing at least the LTK and a (Lopes: [0031]: The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. [0047]: In one set of embodiments, the value derived from a counter in the device address may be, or may comprise, an encrypted value derived from a counter (e.g. an encrypted count value). It may be encrypted with a device-specific key, such as the identity-resolving key),
authenticate the received peer HATC if it matches (Lopes: [0031]: It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device),
not communicate with the peer device if the peer HATC is not authenticated, and communicate with the peer if the peer HATC is authenticated (Lopes: [0031]: After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed); and
an antenna system configured to transmit and receive packets according to at least one wireless standard (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6).
Lopes does not teach: store a peer nonce value for a peer device and receive a communication from a peer device that includes a peer address. Also, Lopes teaches executing a hash on the received value and identity resolving key but does not teach: hashing at least the LTK and a changed A-T count value that varies from the stored A-T count value by a predetermined amount, including, a first local HATC with a first changed A-T count that is the stored A-T count value incremented a first amount, and a second local HATC with a second changed A-T count value that is the stored A-T count value incremented by a second amount that is different than the first amount; authenticate the received peer HATC if it matches the first or second local HATC. However, Yoon teaches:
store a peer nonce value for a peer device (Yoon: [0033] The random number generating unit 230 generates a random number RN. The random number generating unit 230 provides the generated random number RN to the keyed hash value generating unit 240. [0040]: The reception unit 260 transfers the second count value C2, the keyed hash value HKi, and the random number RN to the comparison unit 270. The second count value C2 and the keyed hash value HKi constitute a response message received from one of the RFID tag devices 130. [0042] The comparison unit 270 compares the keyed hash values HKm and HKi with each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Yoon in the invention of Lopes to include the above limitations. The motivation to do so would be to prevent leakage of communication information (Yoon: [0006]).
Lopes in view of Yoon does not teach the rest of the limitations. However, Passaglia teaches:
hashing at least the LTK and a changed A-T count value that varies from the stored A-T count value by a predetermined amount, including, a first local HATC with a first changed A-T count that is the stored A-T count value incremented a first amount, and a second local HATC with a second changed A-T count value that is the stored A-T count value incremented by a second amount that is different than the first amount; (Passaglia: column 9, lines 4-36 and 62-67: Server 130 may maintain a table of registered electronic devices and their corresponding unique identifiers and device identifier. For each known unique identifier, server 130 may determine possible authentication codes based on different clock (counter) values, i.e., the server generates a plurality of authentication codes using different counter values for each unique identifier. As explained above with respect to electronic device 110, an authentication code may be calculated using a hash function key, which may be determined using a KDF. The authentication code may be determined using the hash function key and counter data. The table may alternatively, or additionally, determine counter values near the current time or known counter data (stored counter value). For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 13:00 and 15:00 (counter data that is incremented by +1). In this manner, table 141 may be generated which may include a plurality of records having authentication codes with a corresponding unique identifier (i.e., seed value), device identifier, and counter data. Column 10, lines 11-31: Server 130 may periodically update table 141 with new records based on updated counter data. For example, every minute, ten minutes, hour, etc., new records may be generated by table 141 using the known unique identifiers. A history of records may be maintained by table 141 (the updated counter data will have a counter value of 16:00 (counter increased by 2) , i.e., for every unique identifier, the server generates and stores authentication codes for counter data values incremented by a first amount and second amount in table 141);
authenticate the received peer HATC if it matches the first or second local HATC (Passaglia: column 9, lines 62-67: At block 157, server 130 may determine a match in table 141 to authentication code 121, or a truncated version of authentication code 121. Specifically, server 130 may find an authentication code in table 141 matching the value of authentication code 121 in signal 131, or a truncated portion thereof, i.e., the authentication code 121 sent by the electronic device and received by the server in block 155 is compared with the plurality of authentication codes in table 141 (authentication codes for counter data values of 15:00 and 16:00) to determine if any of the authentication codes stored in table 141 matches authentication code 121).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Passaglia in the invention of Lopes to include the above limitations. The motivation to do so would be to track the electronic device (Passaglia: column 2, lines 25-27).
As per claim 16, Lopes in view of Yoon and Passaglia teaches:
The system of claim 15, further including: a peer wireless device that includes peer circuits configured to store the LTK, the peer A-T count, and the peer nonce, generate the peer HATC by hashing at least the LTK, the peer nonce, the changed A-T count value, and transmit a packet that includes the peer HATC; and a peer antenna system configured to transmit the packet according to the at least one wireless standard (Lopes: [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3. As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9. [0031] The device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device. Yoon: [0043]. [0051] In response to the certification signal CS, the keyed hash value generating unit 330 calculates a response key value (not illustrated) according to the security value Si, the ID IDi, and the adjusted second count value C2. And, the keyed hash value generating unit 330 generates the keyed hash value HKi by using the response key value. Exemplarily, the keyed hash value generating unit 330 may generate the keyed hash value HKi by using the response key value, the ID IDi, the random number RN, and the adjusted second count value C2. The generated keyed hash value HKi is transmitted to the reader 120 (refer to FIG. 1) through the transmission unit 350).
The examiner provides the same rationale to combine Lopes and Yoon as in claim 15 above.
As per claim 17, Lopes in view of Yoon and Passaglia teaches:
The system of claim 16, further including: the first wireless device circuits are further configured to in response to the peer HATC being authenticated, reestablishing a wireless encrypted connection with at least the LTK (Lopes: [0070] If the checks are passed, the slave device increments the value of LocalCounter and sets RemoteCounter equal to ReceivedCounter. It updates the stored master address and its own address using the new values. It also continues with any required response to the master device, such as establishing a connection with it. [0025]: The device is preferably configured to apply a hash algorithm to the value and the identity-resolving key. [0027] The device is preferably configured to generate the address from the value derived from a counter. The address is preferably the value concatenated with the hash. A least significant octet of the hash may become the least significant octet of the address, while a most significant octet of the value may become the most significant octet of the address, i.e., the first device establishes a connection with the second device based on an address derived from the identity-resolving key. It was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that a Bluetooth connection between devices is encrypted), and in response to receiving a communication from the peer over the re-established wireless encrypted connection, change the stored A-T count (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0023] The device is preferably configured to increment the counter. It may be configured to do this at regular intervals, or when a particular condition is met. [0030]: Such a device may be configured to change its address by incrementing the counter after completing a connection establishment with a slave device); and the peer wireless device is configured to, in response to receiving a communication from the first device over the re-established encrypted connection, change its stored peer count value (Lopes: [0066] FIG. 5 shows steps taken by a radio device embodying the invention and acting in a slave role, in respect of a peered master device, substantially as defined in the Bluetooth Core Specification 4.0. It also stores a 22-bit variable LocalCounter. [0069] When the slave device receives a connection message which includes a resolvable private address of a master device according to an embodiment of the invention, it first verifies the identity of the master device. [0070] If the checks are passed, the slave device increments the value of LocalCounter).
As per claim 18, Lopes in view of Yoon and Passaglia teaches:
The system of claim 17, wherein: the first wireless device circuits changing the stored A-T count includes incrementing the stored A-T count (Lopes: [0021]: For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value. The device may store a current count value in non-volatile memory); and the peer wireless device changing its stored A-T count includes incrementing its stored peer A-T count (Lopes: [0066] FIG. 5 shows steps taken by a radio device embodying the invention and acting in a slave role, in respect of a peered master device, substantially as defined in the Bluetooth Core Specification 4.0. It also stores a 22-bit variable LocalCounter. [0068] Whenever the slave device is not responding to a connection request, it increments LocalCounter every 15 minutes).
As per claim 19, Lopes in view of Yoon and Passaglia teaches:
The system of claim 15, wherein: the first wireless device circuits are configured to generate the first local HATC with a first changed A-T count that is the stored A-T count value incremented by one (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0032] In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes, i.e., the counter is increased by 1 after 1 interval. Passaglia: column 9, lines 4-36 and 62-67: The authentication code may be determined using the hash function key and counter data. The table may alternatively, or additionally, determine counter values near the current time or known counter data (stored counter value). For example, if the current time is 14:00 and the counter data is truncated to the hour, server 130 may also determine records for counter data values of 15:00 (counter data that is incremented by +1)), and generate the second local HATC with a second changed A-T count value that is the stored A-T count value incremented by two (Lopes: [0022]: In preferred embodiments, it is a counter that increments through successive integer values. [0032] In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes, i.e., the counter is increased by 2 after 2 intervals. Passaglia: Column 10, lines 11-31: Server 130 may periodically update table 141 with new records based on updated counter data. For example, every minute, ten minutes, hour, etc., new records may be generated by table 141 using the known unique identifiers. A history of records may be maintained by table 141, i.e., updated counter data will have a counter value of 16:00 (counter increased by 2)).
The examiner provides the same rationale to combine Lopes in view of Yoon and Passaglia as in claim 15 above.
As per claim 20, Lopes in view of Yoon and Passaglia teaches:
The system of claim 15, wherein the wireless encrypted connection is compatible with at least one wireless standard selected from the group of: Bluetooth, including Bluetooth low energy, and WiFi Aware (Lopes: [0028] The device is preferably configured to operate substantially as a Bluetooth Low Energy device. [0029]-[0030]. [0058] FIG. 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3. [0070]: It also continues with any required response to the master device, such as establishing a connection with it).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20150074412 to Beame: The private key is incremented each time the client system calculates the hash from the private key and password, such that the next hash will be different to the one last sent to the server system. Accordingly, if the user inputs an incorrect password, the calculated hash will result in a mismatch at the server and denial of access, yet the private key on the client is still incremented. If a valid password is then input at the client system, the resulting hash sent to the server system still does not match the server-generated hash, at which the current private key has not been incremented, although it would match the hash calculated with the private key plus 1. Thus, the server system compares the hash received with a hash or hashes calculated with the next N (e.g. N=10) increments of the private key. Should the hash received match the next N-hash or -hashes, the server authenticates the client and updates its private key to the new value, thus re-synchronises with the client system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi Arani can be reached at (571)272-3787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Prosecution Insights