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 .
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 11/24/2025, for application 17/260,445 has been entered.
This Office Action is in response to the Amendment filed on 11/24/2025. In the instant amendment: Claims 1, 9-10, and 17 have been amended and claims 1 and 17 are independent claims. Claims 11, 18-21 are cancelled. Claims 1-10, 12-17 have been examined and are pending.
Examiner’s Notes:
To promote compact prosecution, the Examiner contacted applicant’s representative, Christophe Lair (Reg. No.: 54248), for a proposed Examiner’s amendment. However, the Examiner and the applicant’s representative were able to reach an agreement.
Response to Arguments
Applicants’ arguments with respect to amended claims 1, 9-10, and 17 have been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Claim Objection
Claims 1 and 17 are objected to because of the following informalities:
Regarding claims 1, claim 1 recites both “the” and “said” while referencing a previously stated term (e.g., “said plurality of reception beacons…”). Normally, either “the” or “said” can be used, but not both.
Regarding claim 17, claim 17 recites both “the” and “said” while referencing a previously stated term (e.g., “ said calculator generating the enriched message by…”). Normally, either “the” or “said” can be used, but not both.
Appropriate correction is required.
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-5, 9-10, 12-16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Krzych et al. (“Krzych,” US 20180288563, published Oct. 4, 2018) in view of Cavendish et al. (“Cavendish,” US 20180292522, published Oct. 11, 2018) and Buldas et al. (“Buldas,” US 20200044861, filed Oct. 9, 2017).
Regarding claim 1, Krzych discloses
A method for generating a [composite] digital proof relative to the transmission of a message by a UWB radio tag to a plurality of reception beacons, said plurality of reception beacons being separated devices arranged at different positions of a predetermined detection zone, the method comprising (Krzych [0032], [0047], [0129]. [T]he mesh nodes can double as physical location identifiers (e.g., each be associated with a predetermined geographic location) or as content nodes (e.g., broadcast packets for content retrieval by recipient devices). In one example, user devices receiving advertisement packets broadcast by a node associated with a location (e.g., kitchen) can be determined to be proximal the location. In a related example, the signal quality indicator of the packet (e.g., RSSI) can be used to determine the user device distance from the node's known location. In a second example, the physical location of user devices receiving advertisement packets broadcast by multiple nodes, each with a known physical location, can be determined based on the respective known physical locations. The radios can be short-range radios (e.g., UWB, BLE, Bluetooth, radios operating on IEEE 802.15 protocols, NFC, etc. [For “digital proof,” see [0035], [0129]. In some examples, for instance, node/beacon identifiers are initially encrypted and then decrypted at the cloud. Additionally or alternatively, any data or information can be un-encrypted, encrypted, or decrypted (e.g., by the target node) at any suitable location and point in the method [with encryption keys associated with seed, timestamp, etc]. Routing the data can optionally include verifying data packet transfer. In a first variation, this includes the parent node receiving a receipt confirmation from the child node. In a second variation, this includes: receiving a beacon packet from a node that should have received the data packet, and verifying that the beacon received the data packet based on packet information (e.g., checking the firmware version number).]):
transmitting a first message by a UWB radio tag at a first instant in time (Krzych [0047], [0082]. The radios can be short-range radios (e.g., UWB, BLE, Bluetooth, radios operating on IEEE 802.15 protocols, NFC, etc.). Parameters [associated with the beacon data] preferably include … temporal parameter (e.g., time since beacon last broadcast a signal), data from a sensor associated with one or more beacons (e.g., motion sensor, temperature sensor, optical sensor, etc.), strength of a signal broadcast by a beacon (e.g., RSSI).);
for each reception beacon of the plurality of reception beacons: receiving, by the reception beacon, the first message transmitted by the UWB radio tag at the first instant in time (Krzych [0033], [0047]. Seventh, the system and method can track how assets (e.g., devices, endpoints) move within the space, based on the known physical locations of each mesh node, which mesh node the asset is connected to, has received packets from, and/or is detected, and the parameters of packet receipt (e.g., RSSI, angle of receipt, receipt time, etc.). The radios can be short-range radios (e.g., UWB, BLE, Bluetooth, radios operating on IEEE 802.15 protocols, NFC, etc.).) ;
upon receiving the first message transmitted by the UWB radio tag at the first instant in time, generating an [enriched] message from the first message, the [enriched] message comprising an identification datum of the UWB radio tag (Krzych [0033], [0057]. Seventh, the system and method can track how assets (e.g., devices, endpoints) move within the space, based on the known physical locations of each mesh node, which mesh node the asset is connected to, has received packets from, and/or is detected, and the parameters of packet receipt (e.g., RSSI, angle of receipt, receipt time, etc.). In one variation (e.g., as shown in FIG. 9), a set of one or more intermediary devices transmits data (e.g., node identifier, node telemetry) from a set of beacons to a remote data routing system (e.g., cloud-based computing system), and data (e.g., operational parameters, beacon settings, radio operation mode, routing path, routing table, etc.) from the remote data routing system to the beacon. In another specific example, at least some data (e.g., beacon identifier) transmitted to the intermediary device are encrypted. This can function to protect information (e.g., beacon identifiers, routing paths, target beacon identifier, beacon location, data collected at a beacon, etc.).).
Krzych does not explicitly disclose: an enriched message comprising:
a temporal datum and a signature;
the generating the enriched message comprising:
extracting the identification datum of the radio UWB radio tag from the first message,
time stamping, by the reception beacon, the reception of the first message transmitted by the UWB radio tag at the first instant in time to generate the temporal datum, and generating the signature,
receiving, by a calculator, the enriched messages generated by each reception beacon of the plurality of reception beacons upon receiving the first message transmitted by the UWB radio tag at the first instant in time, and generating, the by calculator, the composite digital proof from the temporal data and the signatures of the enriched messages to prove a presence of the UWB radio tag in the predetermined detection zone.
However, in an analogous art, Cavendish discloses a method, comprising the step of:
an enriched message comprising: a temporal datum and a signature (Cavendish [0040]. [O]ne particular way to implement a secure timing protocol is for messages exchanged by the responder and initiator devices to be signed by the respective legitimate peers, with every signed message including a payload data that can be signed (e.g., generate a signature with a hash function that uses the payload of the message, and a secret cryptographic key associated with the device). The payload for every exchanged message may include: a) ID of the message sender (e.g., a media access control (MAC) address), b) timing information (e.g., T1, T2, T3, and/or T4 illustrated in FIG. 2 below), and/or c) a nonce. [Note that the wireless devices (i.e., beacons) have transceivers for various communication protocols, see [0097].]),
the generating the enriched message comprising: extracting the identification datum of the radio UWB radio tag from the first message (Cavendish [0040], [0075]. [O]ne particular way to implement a secure timing protocol is for messages exchanged by the responder and initiator devices to be signed by the respective legitimate peers, with every signed message including a payload data that can be signed. The payload for every exchanged message may include: a) ID of the message sender (e.g., a media access control (MAC) address), b) timing information (e.g., T1, T2, T3, and/or T4 illustrated in FIG. 2 below), and/or c) a nonce. Upon receiving STM_1, the receiving, second, device verifies the received signature, dropping the message if it fails. If the signature is verified, the second device sends a signed ACK_1 message (or [S]ACK_1). If the message 250 or 250′ has been verified (i.e., is deemed to have originated from the responder device 202), the initiator device can determine (extract) the timing information providing in payload of the message 250 to determine T1 and T4. [For messages from RFID tags, see [0105].]),
time stamping, by the reception beacon, the reception of the first message transmitted by the UWB radio tag at the first instant in time to generate the temporal datum (Cavendish [0040], [0073], [0078]. The payload for every exchanged message may include [ ] timing information (e.g., T1, T2, T3, and/or T4 illustrated in FIG. 2 below), and/or c) a nonce. For example, the timing information may be represented as timestamps of the local clock of the responder device 202, as timestamps of some reference clock (used by some remote device), or based on some other representation of time. As noted herein, the first signed message may be part of a message exchange (e.g., where the various messages are generated and configured according to, for example, an FTM-based RTT protocol). The first payload may be constructed to include [ ] a respective nonce value. Alternatively, the nonce value may be a varying sequence number that is synchronized at specific times (e.g., outside of the RTT protocol). [Note that the wireless devices (i.e., beacons) have transceivers for various communication protocols, see [0097]; and each wireless device may utilize signature algorithms with its corresponding asymmetric keys, see [0056].] ),
and generating the signature (Cavendish [0040]. [O]ne particular way to implement a secure timing protocol is for messages exchanged by the responder and initiator devices to be signed by the respective legitimate peers, with every signed message including a payload data that can be signed (e.g., generate a signature with a hash function that uses the payload of the message, and a secret cryptographic key associated with the device). The payload for every exchanged message may include: a) ID of the message sender (e.g., a media access control (MAC) address), b) timing information (e.g., T1, T2, T3, and/or T4 illustrated in FIG. 2 below), and/or c) a nonce. [Note that the wireless devices (i.e., beacons) have transceivers for various communication protocols, see [0097].]),
receiving, by a calculator, the enriched messages generated by each reception beacon of the plurality of reception beacons upon receiving the first message transmitted by the UWB radio tag at the first instant in time (Cavendish [0051], [0073], [0076]. The initiator device (or a remote device, such as the server 150, that is configured to receive time data from the initiator device to compute the range) then computes the range as a function of the T1, T2, T3, and T4, e.g., RTT=(T2−T1)+(T4−T3). Continuing with FIG. 2, if the responder device 202 determines that the verifiable acknowledgement message 240 it received is a valid acknowledgement message (i.e., a signed confirmatory message is received within a pre-determined time period following receipt of the acknowledgement message, or the resultant hash value derived for the received acknowledgement message's hash value matches the correct expected value), the responder device 202 is configured to generate a second signed message 250 (denoted as STM_2). Additionally, in some embodiments, the range data derived through the message exchange processes described herein may also be used to determine approximate location for one or more of the communicating devices. For example, the initiator device may use multiple determined range values between itself and one or more responder devices to determine (based further on a determined location for at least one of the one or more responder device) an approximate or exact location.), and
generating, by the calculator, the [composite] digital proof from the temporal data and the signatures of the enriched messages (Cavendish [0088]. In some embodiments, at least some of the payload included in the second signed messages (and/or in any of the other messages exchanged between the devices) may be encrypted (independently of the cryptographic generation of the signatures) so as to obfuscate timing data to thus inhibit eavesdropping. For example, the data transmitted (e.g., the timing data for T1 and T4 included in the second signed message) may be encrypted using an encryption key (which may be a symmetric or asymmetric cryptographic key). For example, the sending device may use a public key associated with the destination (receiving) device to encrypt the data, to thus allow only the receiving device to be able to decrypt the encrypted data (using the private key stored at the receiving device)... Encryption of the payload may be performed using a different cryptographic key(s) than that used to generate signatures.)
to prove a presence of the UWB radio tag in the predetermined detection zone (Cavendish [0095], [0102], [0105]. Having received the second signed message, if the initiator device is able to authenticate the second signed message (e.g., based on the payload and the signature portion of the second signed message), the initiator device may determine the first time instance and the fourth time instance from the timing information included in the second signed message, and determine a correct range between the wireless device and the other wireless device based, at least in part, on the determined first time instance and the fourth time instance. Additionally, the initiator device may also determine location information (e.g., its exact or approximate position) based on the range computed via the procedure 500. As noted, at least some of the range determination and/or location determination operations may be performed at a remote device, such as the server 150 of FIG. 1, to which the initiator device may communicate the timing information used to derive the range and/or the location information. As illustrated in FIG. 6, in some embodiments, the memory 614 may include a positioning and range determination module 616, an application module 618, a received signal strength indicator (RSSI) module 620, and/or an RTT module 622 (the RTT module may be used in addition to, or in place of, the positioning and range determination module 616)…. a dedicated processing unit to process and analyze signals received and/or transmitted via the antenna(s) (e.g., to generate and process signed messages, determine signal strength of received signals, determine timing information in relation to communicated messages, etc.). Supplemental information may also include, but not be limited to, information that can be derived or based upon Bluetooth signals, beacons, radio-frequency identification (RFID) tags, and/or information derived from a map (e.g., receiving coordinates from a digital representation of a geographical map by, for example, a user interacting with a digital map).).
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 Cavendish with Krzych to include the steps of: receiving, by a calculator, the enriched messages generated by the plurality of reception beacons upon receiving the first message transmitted by the UWB radio tag at the first instant in time to generate the digital proof from the temporal data and the signatures of the enriched messages. One would have been motivated to provide users with a means for using signed messages (subject to time stamp constraints) to enable secure communication between designated wireless devices. (See Cavendish [0073].)
Krzych in view of Cavendish do not explicitly: a composite digital proof.
However, in an analogous art, Buldas discloses a method, comprising the step of: a composite digital proof (Buldas [0045]. A user of the client device 100 may desire to send a message m to the server 150 in such a way that the server 150 is able to verify that the message m originated with the client device 100. However the user of the client device 100 may also desire to receive an acknowledgement that the message m was received by the server and to be secure in the knowledge that the acknowledgement originated with the server 150 and not with an adversarial party. For such a purpose, a composite cryptographic signature may be generated using a method such as that set out below, in which the composite cryptographic signature is generated from a digital signature of the client's device 100 and a digital signature of the server 150. If the client device 100 is able to send message m and information pertaining to its digital signature to server 150, and to receive an acknowledgement, then the client's device 100 may be able to verify that the acknowledgement came from the server 150 and that the acknowledgement was created using both the digital signature of the client device 100 and the digital signature of the server 150.).
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 Buldas, Cavendish with Krzych to include the steps of: a composite digital proof. One would have been motivated to provide users with a means for varying that a message has been signed and verified by a plurality of intended senders and recipients. (See Buldas [0045].)
Regarding claim 2, Krzych, Cavendish and Buldas disclose the method of claim 1. Krzych further discloses wherein at least one reception beacon of the plurality of reception beacons is enabled to communicate to another reception beacon of the plurality of reception beacons (Krzych [0032]. [T]he mesh nodes can double as physical location identifiers (e.g., each be associated with a predetermined geographic location) or as content nodes (e.g., broadcast packets for content retrieval by recipient devices). In one example, user devices receiving advertisement packets broadcast by a node associated with a location (e.g., kitchen) can be determined to be proximal the location. In a related example, the signal quality indicator of the packet (e.g., RSSI) can be used to determine the user device distance from the node's known location. In a second example, the physical location of user devices receiving advertisement packets broadcast by multiple nodes, each with a known physical location, can be determined based on the respective known physical locations.).
Regarding claim 3, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein each reception beacon comprises a memory in which is stored a digital key making it possible to generate a signature, at least two reception beacons of the plurality of reception beacons comprising different keys (Cavendish FIG. 1, [0056], [0073]. Alternatively, the secret cryptographic key used for the verification processes described herein may be a private key of an asymmetric public-private key-pair, such as Elliptic Curve Digital Signature Algorithm (ECDSA) keys) [note that “signature” is generated by the private key and verifiable by its corresponding public key, see [0064]]. Continuing with FIG. 2, if the responder device 202 determines that the [signed, see [0072]] verifiable acknowledgement message 240 it received is a valid acknowledgement message [], the responder device 202 is configured to generate a second signed message 250 (denoted as STM_2). The second signed message 250 includes a payload. Once the payload for the message 250 is determined, the responder device 202 generates a signature portion for the message 250. For example, the responder device uses a hash function (which may be the same as, or different from the hash function used for the first signed message 230) applied to the payload and the cryptographic key of the responder device to generate a hash value, constituting the signature.).
The motivation is the same as that of claim 1 above.
Regarding claim 4, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein each reception beacon generates a signature different from the signature generated by each other reception beacon of the plurality of reception beacons (Cavendish FIG. 1, [0056], [0073]. Alternatively, the secret cryptographic key used for the verification processes described herein may be a private key of an asymmetric public-private key-pair, such as Elliptic Curve Digital Signature Algorithm (ECDSA) keys) [note that “signature” is generated by the private key and verifiable by its corresponding public key, see [0064]]. Continuing with FIG. 2, if the responder device 202 determines that the [signed, see [0072]] verifiable acknowledgement message 240 it received is a valid acknowledgement message [], the responder device 202 is configured to generate a second signed message 250 (denoted as STM_2). The second signed message 250 includes a payload. Once the payload for the message 250 is determined, the responder device 202 generates a signature portion for the message 250. For example, the responder device uses a hash function (which may be the same as, or different from the hash function used for the first signed message 230) applied to the payload and the cryptographic key of the responder device to generate a hash value, constituting the signature.).
The motivation is the same as that of claim 1 above.
Regarding claim 5, Krzych, Cavendish and Buldas disclose the method of claim 1.
Krzych discloses UWB ratio tag (Krzych [0047]. The radios can be short-range radios (e.g., UWB, BLE, Bluetooth, radios operating on IEEE 802.15 protocols, NFC, etc.).).
Cavendish further discloses determining a position of the UWB radio tag from the temporal data of the enriched messages generated by the plurality of reception beacons upon receiving the first message transmitted by the UWB radio tag at the first instant in time (Cavdneish FIGs 4, 6, [0087]. With continued reference to FIG. 4, responsive to a verification that the received acknowledgement message originated from the second wireless device (i.e., the verifiable acknowledgement message is deemed to have originated from the initiator device), the first, responder, wireless device, transmits 440 a second signed message comprising a second payload with at least timing information for the first time instance and the fourth time instance at which the first wireless device received the verifiable acknowledgement message. As with the first signed message, the second signed message is generated by producing the payload (e.g., the timing information, device identifiers, a nonce value, etc.), and deriving a hash value based on the payload and using the responder device's secret cryptographic key. The timing information in the second signed message can then be used, if received and authenticated by the initiator device, to compute the RTT for the initiator and responder devices, and based on that timing information to compute the range between the two devices (and/or to derive location estimates for the device).).
The motivation is the same as that of claim 1 above.
Regarding claim 9, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein the [composite] digital proof comprises: at least one pair of digital values, each digital value comprising at least one digital signature; or
a result of an operation aiming to correlate the temporal data of the enriched messages (Cavdneish FIGs 4, 6, [0084], [0087]. For example, if the verifiable acknowledgement message is a signed acknowledgement message, the responder device verifies that the signed acknowledgement message did in fact originate from the initiator device. With continued reference to FIG. 4, responsive to a verification that the received acknowledgement message originated from the second wireless device (i.e., the verifiable acknowledgement message is deemed to have originated from the initiator device), the first responder wireless device transmits 440 a second signed message comprising a second payload with at least timing information for the first time instance and the fourth time instance at which the first wireless device received the verifiable acknowledgement message. As with the first signed message, the second signed message is generated by producing the payload (e.g., the timing information, device identifiers, a nonce value, etc.), and deriving a hash value based on the payload and using the responder device's secret cryptographic key. The timing information in the second signed message can then be used, if received and authenticated by the initiator device, to compute the RTT for the initiator and responder devices, and based on that timing information to compute the range between the two devices (and/or to derive location estimates for the device). [For the purpose of prosecution, the Examiner interprets the term “proof” to include digital signature of messages or signed confirmation/acknowledgment of receipt messages after validating the digital signature of an incoming message.]).
Buldas discloses a composite digital proof (Buldas [0045]. A user of the client device 100 may desire to send a message m to the server 150 in such a way that the server 150 is able to verify that the message m originated with the client device 100. However the user of the client device 100 may also desire to receive an acknowledgement that the message m was received by the server and to be secure in the knowledge that the acknowledgement originated with the server 150 and not with an adversarial party. For such a purpose, a composite cryptographic signature may be generated using a method such as that set out below, in which the composite cryptographic signature is generated from a digital signature of the client's device 100 and a digital signature of the server 150. If the client device 100 is able to send message m and information pertaining to its digital signature to server 150, and to receive an acknowledgement, then the client's device 100 may be able to verify that the acknowledgement came from the server 150 and that the acknowledgement was created using both the digital signature of the client device 100 and the digital signature of the server 150.).
The motivation is the same as that of claim 1 above.
Regarding claim 10, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein a calculator carries out an operation aiming to verify the conformity of the [composite] digital proof, the operation associating the different temporal data and the signatures of each beacon for each message transmitted by a radio tag (Cavdneish FIGs 4, 6, [0084], [0087]. For example, if the verifiable acknowledgement message is a signed acknowledgement message, the responder device verifies that the signed acknowledgement message did in fact originate from the initiator device. With continued reference to FIG. 4, responsive to a verification that the received acknowledgement message originated from the second wireless device (i.e., the verifiable acknowledgement message is deemed to have originated from the initiator device), the first responder wireless device transmits 440 a second signed message comprising a second payload with at least timing information for the first time instance and the fourth time instance at which the first wireless device received the verifiable acknowledgement message. As with the first signed message, the second signed message is generated by producing the payload (e.g., the timing information, device identifiers, a nonce value, etc.), and deriving a hash value based on the payload and using the responder device's secret cryptographic key. The timing information in the second signed message can then be used, if received and authenticated by the initiator device, to compute the RTT for the initiator and responder devices, and based on that timing information to compute the range between the two devices (and/or to derive location estimates for the device). [For the purpose of prosecution, the Examiner interprets the term “proof” to include digital signature of messages or signed confirmation/acknowledgment of receipt messages after validating the digital signature of an incoming message. For UWB radio tag, see[0097].]).
Buldas discloses a composite digital proof (Buldas [0045]. A user of the client device 100 may desire to send a message m to the server 150 in such a way that the server 150 is able to verify that the message m originated with the client device 100. However the user of the client device 100 may also desire to receive an acknowledgement that the message m was received by the server and to be secure in the knowledge that the acknowledgement originated with the server 150 and not with an adversarial party. For such a purpose, a composite cryptographic signature may be generated using a method such as that set out below, in which the composite cryptographic signature is generated from a digital signature of the client's device 100 and a digital signature of the server 150. If the client device 100 is able to send message m and information pertaining to its digital signature to server 150, and to receive an acknowledgement, then the client's device 100 may be able to verify that the acknowledgement came from the server 150 and that the acknowledgement was created using both the digital signature of the client device 100 and the digital signature of the server 150.).
The motivation is the same as that of claim 1 above.
Regarding claim 12, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein a device for transmitting a clock disseminates a synchronization datum to the different reception beacons (Cavendish [0078]. As noted herein, the first signed message may be part of a message exchange (e.g., where the various messages are generated and configured according to, for example, an FTM-based RTT protocol). The first payload may be constructed to include [ ] a respective nonce value. The nonce value that may be included in the first payload (and/or subsequent payloads used with subsequent messages). Alternatively, the nonce value may be a varying sequence number that is synchronized at specific times (e.g., outside of the RTT protocol).).
The motivation is the same as that of claim 1 above.
Regarding claim 13, Krzych, Cavendish and Buldas disclose the method of claim 1. Buldas discloses further comprising a step of generation of a composite signature from the signatures of the enriched messages (Buldas [0045]. A user of the client device 100 may desire to send a message m to the server 150 in such a way that the server 150 is able to verify that the message m originated with the client device 100. However the user of the client device 100 may also desire to receive an acknowledgement that the message m was received by the server and to be secure in the knowledge that the acknowledgement originated with the server 150 and not with an adversarial party. For such a purpose, a composite cryptographic signature may be generated using a method such as that set out below, in which the composite cryptographic signature is generated from a digital signature of the client's device 100 and a digital signature of the server 150. If the client device 100 is able to send message m and information pertaining to its digital signature to server 150, and to receive an acknowledgement, then the client's device 100 may be able to verify that the acknowledgement came from the server 150 and that the acknowledgement was created using both the digital signature of the client device 100 and the digital signature of the server 150.).
Regarding claim 14, Krzych, Cavendish and Buldas disclose the method of claim 1.
Cavendish further discloses wherein the UWB radio tag is associated with an electronic equipment comprising at least one sensor, the sensor measuring a datum of a physical parameter (Cavendish FIG. 6, [0100]. As further illustrated in FIG. 6, the example device 600 includes one or more sensors 612 coupled to a processor 610 (which may also be referred to as a controller). By way of example but not limitation, the motion sensors may include an accelerometer 612 a, a gyroscope 612 b, and a geomagnetic (magnetometer) sensor 612 c (e.g., a compass), any of which may be implemented based on micro-electro-mechanical-system (MEMS), or based on some other technology.),
the datum being inserted into the first message transmitted by the UWB radio tag (Cavendish [0048]-[0049]. Accordingly, and as will be discussed in greater detail below, any of the wireless devices 114, 122, 134, 140, and/or 142, when responding to a communication exchange intended to trigger a process to derive a range (and/or a location) between that device and an initiating device, may be configured to transmit a first signed message at a first time instance, with the first signed message comprising a first payload and configured to be received by a second wireless device at a second time instance. An FTM message may also include a measurement type field, where the measurement type field can include values such as a Location Configuration Information (LCI) value (which can, in some implementations, reflect a request for, in one example, latitude/longitude coordinate values) and/or a Location Civic value. [For UWB, see [0097], see also [0105] for RFID tags.]),
the datum being associated with the signature of each reception beacon for the calculation of a proof (Cavendish [0051], [0073]. The initiator device (or a remote device, such as the server 150, that is configured to receive time data from the initiator device to compute the range) then computes the range as a function of the T1, T2, T3, and T4, e.g., RTT=(T2−T1)+(T4−T3). Continuing with FIG. 2, if the responder device 202 determines that the verifiable acknowledgement message 240 it received is a valid acknowledgement message (i.e., a signed confirmatory message is received within a pre-determined time period following receipt of the acknowledgement message, or the resultant hash value derived for the received acknowledgement message's hash value matches the correct expected value), the responder device 202 is configured to generate a second signed message 250 (denoted as STM_2). [For the purpose of prosecution, the Examiner interprets the term “proof” to include digital signature of messages or signed confirmation/acknowledgment of receipt messages after validating the digital signature of an incoming message.]).
The motivation is the same as that of claim 1 above.
Regarding claim 15, Krzych, Cavendish and Buldas disclose the method of claim 1.
Cavendish further discloses wherein each reception beacon is configured to receive a datum from an electronic equipment comprising at least one sensor, the sensor measuring a datum, the datum being inserted into a new message transmitted by the electronic equipment (Cavendish [0048]-[0049], [0100]. Accordingly, and as will be discussed in greater detail below, any of the wireless devices 114, 122, 134, 140, and/or 142, when responding to a communication exchange intended to trigger a process to derive a range (and/or a location) between that device and an initiating device, may be configured to transmit a first signed message at a first time instance, with the first signed message comprising a first payload and configured to be received by a second wireless device at a second time instance. An FTM message may also include a measurement type field, where the measurement type field can include values such as a Location Configuration Information (LCI) value (which can, in some implementations, reflect a request for, in one example, latitude/longitude coordinate values) and/or a Location Civic value. [For UWB, see [0097], see also [0105] for RFID tags.] As further illustrated in FIG. 6, the example device 600 includes one or more sensors 612 coupled to a processor 610 (which may also be referred to as a controller). By way of example but not limitation, the motion sensors may include an accelerometer 612 a, a gyroscope 612 b, and a geomagnetic (magnetometer) sensor 612 c (e.g., a compass), any of which may be implemented based on micro-electro-mechanical-system (MEMS), or based on some other technology.),
datum being associated with the signature of each beacon for the calculation of a proof (Cavendish [0051], [0073]. The initiator device (or a remote device, such as the server 150, that is configured to receive time data from the initiator device to compute the range) then computes the range as a function of the T1, T2, T3, and T4, e.g., RTT=(T2−T1)+(T4−T3). Continuing with FIG. 2, if the responder device 202 determines that the verifiable acknowledgement message 240 it received is a valid acknowledgement message (i.e., a signed confirmatory message is received within a pre-determined time period following receipt of the acknowledgement message, or the resultant hash value derived for the received acknowledgement message's hash value matches the correct expected value), the responder device 202 is configured to generate a second signed message 250 (denoted as STM_2). [For the purpose of prosecution, the Examiner interprets the term “proof” to include digital signature of messages or signed confirmation/acknowledgment of receipt messages after validating the digital signature of an incoming message.]).
The motivation is the same as that of claim 1 above.
Regarding claim 16, Krzych, Cavendish and Buldas disclose the method of claim 1. Cavendish further discloses wherein each reception beacon receives a same data stream transmitted by a data source, the method comprising a step of extraction by each reception beacon of a data portion from the data stream, the extracted data portion being integrated in an enriched message consecutively to the reception of a message by at least one reception beacon coming from the tag ET1(Cavendish [0040], [0057] – [0058]. [O]ne particular way to implement a secure timing protocol is for messages exchanged by the responder and initiator devices to be signed by the respective legitimate peers, with every signed message including a payload data that can be signed. The payload for every exchanged message may include [ ] a nonce. An example of a nonce that may be used to construct a payload is a changing sequence number that may vary (e.g., increase or decrease) for every subsequent message or RTT transaction (e.g., RTT exchange round). Thus, in every message exchange [e.g., upon validation of a signature of a payload including nonce information] a new sequence, with a corresponding sequence starting value, may be established. [For UWB or RFID tag, see [0097], [0105].]).
The motivation is the same as that of claim 1 above.
Regarding claim 17, claim 17 is directed to a system corresponding to the method of claim 1. Claim 17 is similar to claim 1 and is therefore rejected under similar rationale.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Krzych et al. (“Krzych,” US 20180288563, published Oct. 4, 2018) in view of Cavendish et al. (“Cavendish,” US 20180292522, published Oct. 11, 2018), Buldas et al. (“Buldas,” US 20200044861, filed Oct. 9, 2017) and Petersen (“Petersen,” US 20210075623, filed April 25, 2019).
Regarding claim 6, Krzych, Cavendish and Buldas disclose the method of claim 1.
Krzych, Cavendish and Buldas do not explicitly disclose: wherein the signature and the temporal data are stored in a data container forming a block of a blockchain, each block of the blockchain comprising a specific digital fingerprint.
Petersen further discloses wherein the signature and the temporal data are stored in a data container forming a block of a blockchain, each block of the blockchain comprising a specific digital fingerprint (Petersen [0071]. [A] computer-implemented method for managing a electronic health records using a distributed blockchain computing network, the method comprising: a) enabling a user or authorized third party to access and upload electronic health records. In some embodiments, the data comprises one or more log entries. In some embodiments, each entry comprises a date/timestamp, a user signature, a counter-signature by a third party, or any combination thereof. [For digital fingerprint, see [0041] regarding hash linked chain for a blockchain system, where perturbation of one set of hash values changes and entire subsequent hash values in hash-linked blocks, therefore creating an immutable record. Thus, each hash reference of a block cannot be altered for a valid chain.).
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 Petersen, Krzych, Cavendish and Buldas to include the steps of: wherein the signature data and the temporal data are stored in a data container forming a block of a blockchain, each block of the blockchain comprising a specific digital fingerprint. One would have been motivated to provide users with a means for using blockchain based system for secure storage, retrieval and release of sensitive information to an authorized party. (See Petersen [0071]].)
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Krzych et al. (“Krzych,” US 20180288563, published Oct. 4, 2018) in view of Cavendish et al. (“Cavendish,” US 20180292522, published Oct. 11, 2018), Buldas et al. (“Buldas,” US 20200044861, filed Oct. 9, 2017), Petersen (“Petersen,” US 20210075623, filed April 25, 2019) and Soundararajan et al. (“Soundararajan,” US 20200034888, filed July 30, 2018).
Regarding claim 7, Krzych, Cavendish, Buldas and Petersen disclose the method of claim 6. Soundararajan further discloses wherein the set of enriched messages generated by a beacon of at least two reception beacons of the plurality of reception beacons over a predefined time period are stored in a same blockchain (Soundararajan [0093] – [0094], [0098]. At operation 760, verifier 400 may digitally sign an attestation transaction verifying the image and embedded identities of entities appearing in the image. Verifier 400 may sign the transaction using a private key 412 associated with its blockchain address. At operation 670, verifier 400 may propagate the digitally signed attestation transaction to blockchain network 300. As such, once the verification process is complete, the verifier 400 may either i) store the image with embedded TOTAs and its attestation into a blockchain. Attestation transaction 800 may be recorded on a blockchain of blockchain network 300. Attestation transaction 800 may include a blockchain transaction ID 801, a secured representation of an entity blockchain address 802, a reference to the image 803, a timestamp 804 of the time when the picture was taken by the user, a digital signature 805 of a verifier, and other transaction data 806 (e.g., secured representation of location blockchain address, secured representation of user blockchain address, GPS coordinates, and/or public keys associated with entity, verifier, location, a timestamp of the transaction, and/or user, etc.). [Note that TOTA messages are valid only for a pre-defined time period. See [0027].]).
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 Soundararajan, Krzych, Cavendish, Buldas and Petersen to include the step of: wherein the set of enriched messages generated by a beacon over a predefined time period are stored in a same blockchain. One would have been motivated to provide users with a means for recording and storing transaction data on a secure block-chain network. (See Soundararajan [0098].)
Regarding claim 8, Krzych, Cavendish, Buldas and Petersen disclose the method of claim 6. Soundararajan further discloses wherein the set of enriched messages generated by at least two reception beacons of the plurality of reception beacons covering a same geographic zone over a predefined time period are stored in a same blockchain (Soundararajan [0093] – [0094], [0098]. At operation 760, verifier 400 may digitally sign an attestation transaction verifying the image and embedded identities of entities appearing in the image. Verifier 400 may sign the transaction using a private key 412 associated with its blockchain address. At operation 670, verifier 400 may propagate the digitally signed attestation transaction to blockchain network 300. As such, once the verification process is complete, the verifier 400 may either i) store the image with embedded TOTAs and its attestation into a blockchain. Attestation transaction 800 may be recorded on a blockchain of blockchain network 300. Attestation transaction 800 may include a blockchain transaction ID 801, a secured representation of an entity blockchain address 802, a reference to the image 803, a timestamp 804 of the time when the picture was taken by the user, a digital signature 805 of a verifier, and other transaction data 806 (e.g., secured representation of location blockchain address, secured representation of user blockchain address, GPS coordinates, and/or public keys associated with entity, verifier, location, a timestamp of the transaction, and/or user, etc.). [Note that TOTA messages are valid only for a pre-defined time period. See [0027].]).
The motivation is the same as that of claim 7 above.
Conclusion
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