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 .
Detail Action
This office action is response to the application 18/694,858 on 03/22/2024. Claims 2, 18, 41, 44 & 48 have been canceled. Claims 1, 3-17, 19-40, 42, 43 and 45-47 are pending in this communication.
Priority
This application claims priority from UNITED KINGDOM 2113636.1 09/24/2021. Priority date has been accepted.
Examiner’s Note
The examiner is requesting the applicant’s representative to provide direct phone number and/or mobile phone number in next communication, which will be very helpful to advance the prosecution.
Generally the text that are italicized are claims; the text that are in bold are reference citations (with some obvious exception); the text which is neither italicized nor bolded are by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of AIA 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 7, 8, 13, 17, 31, 40, 42 & 45-47 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1).
Regarding Claim 1, SOUNDARARAJAN discloses a computer-implemented method performed by a validation device, the computer-implemented method comprising:
following transmission of a challenge message by a beacon device to each of one or more responder devices over a respective direct communication link {[0003], “FIG. 1 is a diagram illustrating an example environment that uses location beacon devices” … [0073], “Communications between client device 200 and verifier 400 may be occur over a communication network 275. Communication network 275 may comprise any communications network suitable for exchanging communications between a client device 200 and verifier 400”. Examiner’s note: cited ‘exchanging communications’ in Fig.1, the claimed ‘challenge message’ ‘TOTA-L1(B,t)’ and more challenge messages, between client device 200 via beacon device AP 276 to Blockchain verifier 400}, the challenge message inviting each of the one or more responder devices to prove an existence of a respective direct communication link by transmitting to a respective recipient device, distinct from the beacon device, a respective response message indicating knowledge of contents of the challenge message {Fig.1 & [0056] FIG. 1 is a diagram illustrating an example environment that uses location beacon devices 100-1 to 100-N (individually referred to as a location beacon 100) and a blockchain network 300 including a verifier server system 400 (“verifier 400”) to prove the presence of a user of client device 200 at a particular location and time” … [0089], “At operation 520, the client device 200 transmits the first secured representation of the location beacon device's provisioned location blockchain address to a verifier 400. At operation 530, the client device 200 receives a request from the verifier to obtain a second secured representation of a location blockchain address that is provided by a location beacon device that is in substantially the same (or the same) location as the first location beacon device. The response message received from verifier 400 may be in accordance with an interactive proving protocol by which a verifier server system asks a client device one or more questions to generate data that proves the user's presence at a particular location at a particular time”. Examiner’s note: in Fig. 1 communication link 275, there are challenges and challenge responses between the ‘client device 200’ and the Verifier server system 400};
the validation device obtaining an indication that a confirmation message from the beacon device has been received by a message store, the confirmation message indicating knowledge of the contents of the challenge message and having been transmitted by the beacon device a predetermined time period after transmission of the challenge message {Fig. 1 element 400 – ‘Verifier Server System’, [0096], “At operation 570, client device 200 receives a confirmation message from verifier 400 that the user's presence has been verified at a particular location at a particular time. In implementations, the confirmation message may identify a blockchain transaction identifier (ID) of a distributed attestation transaction stored on the blockchain of blockchain network 300. The distributed attestation transaction stored on the blockchain may be digitally signed by verifier 400 and digitally attest to the user's presence at a particular location at a particular time”. Examiner’s note: the Verifier system 400 verifies the knowledge of message contents}; and
SOUNDARARAJAN, however, does not explicitly disclose,
the validation device, responsive to obtaining the indication, comparing contents of each response message which preceded the confirmation message in time, if any, to contents of the confirmation message and inferring therefrom which of the respective responder devices, if any, received the challenge message over the respective direct communication link.
In an analogous reference FOX discloses
the validation device, responsive to obtaining the indication, comparing contents of each response message which preceded the confirmation message in time, if any, to contents of the confirmation message and inferring therefrom which of the respective responder devices, if any, received the challenge message over the respective direct communication link {Fig. 19 & [0210], “At block 1915 the CPV operator controller may compare the challenge to an operator credential stored on the drone operator controller. In certain examples, aspects of the described operations may be performed by CPV operator 110 as described with reference to FIG. 1” … [0211], “At block 1920 the CPV operator controller may prepare a cryptographic operator response based on the operator credential”. Examiner’s note: mapping: Fig. 1 element 135 – ‘Relay Node’/ Fig. 6 element 605 is functioning as BEACON generating device; Fig. 1 element 105 – CPV, a wireless client station listening to BEACON messages; the Relay Node element 610 is functioning as message confirmation device}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify SOUNDARARAJAN’s technique of ‘setting up wireless comm link after a client listen from BEACON’ for ‘validating challenge and response’, as taught by FOX. The motivation is: The primary advantage of having a client validate a challenge and response after listening for a beacon (or using an active probe process) is enhanced network security, specifically in authenticating the client and preventing unauthorized access before a full communication link is established.
All references are inventions in analogous area but each invention teaches specific claimed limitation specifically and other references mutually cure each other’s deficiencies. When all claimed techniques are combined, they teach claimed invention. The Examiner notes that this motivation applies to all dependent and/or otherwise subsequently addressed claims unless addressed separately.
Regarding Claim 3, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. The combination further discloses
further comprising the validation device inferring data relating to location, relative to the beacon device at a time the challenge message was issued, of each responder device inferred to have received the challenge message over the respective direct communication link {SOUNDARARAJAN:[0003], “FIG. 1 is a diagram illustrating an example environment that uses location beacon devices and a blockchain network including a verifier server system (“verifier”) to prove the presence of a user of client device at a particular location and time”}.
Regarding Claim 7, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. The combination further discloses
wherein each response message comprises data intended for the respective recipient device and originating from a respective sender device distinct from the respective responder device {SOUNDARARAJAN: [0003], “FIG. 1 is a diagram illustrating an example environment that uses location beacon devices” … [0073], “Communications between client device 200 and verifier 400 may be occur over a communication network 275. Communication network 275 may comprise any communications network suitable for exchanging communications between a client device 200 and verifier 400”. Examiner’s note: cited ‘exchanging communications’ in Fig.1, the claimed ‘challenge message’ ‘TOTA-L1(B,t)’ and more challenge messages, between client device 200 via beacon device AP 276 to Blockchain verifier 400}; and
the method further comprises the validation device validating the data originating from the respective sender device as having been routed via a respective responder device local to the beacon device message {SOUNDARARAJAN:Fig.1 & [0056] FIG. 1 is a diagram illustrating an example environment that uses location beacon devices 100-1 to 100-N (individually referred to as a location beacon 100) and a blockchain network 300 including a verifier server system 400 (“verifier 400”) to prove the presence of a user of client device 200 at a particular location and time”}.
Regarding Claim 8, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. The combination further discloses
further comprising the validation device generating an external device challenge message portion and transmitting the external device challenge message portion to the beacon device to cause the beacon device to generate a beacon device challenge message portion and construct the challenge message contents as a non-separable function of two or more variables, the external device challenge message portion and the beacon device challenge message portion each comprising at least one of the variables {SOUNDARARAJAN: [0167] Blockchain application 1515 may also include proving verifiable claim instructions 1511. Verifiable claim instructions 1511, when executed by a processing device 220, may cause client device 1500 to engage in an interactive proving protocol with verifier 1600 to prove a claim. Examples of interactive proving protocols are further described above with reference to FIGS. 1-14. For example, as illustrated in the environment of FIG. 15, client device 1500 may prove presence at a particular location at a particular time. As part of this interactive proving protocol, the client device may capture TOTAs (Time-based One-Time Advertisement) from location beacons 100 and its own TOTA, and present these TOTA to verifier 1600 that then communicates with blockchain address mapping server system 390 to verify the blockchain identity and location of the user of the client device. Additionally, the executed instructions 1511 may cause the client device 1500 to request to verifier 1600 that a centralized identity of a user of the client device 1500 be associated with a verified claim”. Examiner’s note: TOTA is one variable used for negotiation. Time and location of request message are two variables (Fig.2 Beacon-device) used in request-response}.
Regarding Claim 13, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. The combination further discloses
further comprising the validation device authenticating the one or more responder devices for two-way communication with the beacon device in dependence on timings of the respective response messages {[0056], “FIG. 1 is a diagram illustrating an example environment that uses location beacon devices 100-1 to 100-N (individually referred to as a location beacon 100) and a blockchain network 300 including a verifier server system 400 (“verifier 400”) to prove the presence of a user of client device 200 at a particular location and time, in accordance with implementations of the disclosure. FIG. 1 will be described in conjunction with FIGS. 2, 3, and 4, which are block diagrams respectively illustrating an example architecture of components of a location beacon 100, client device 200, and verifier 400”}.
Regarding claim 17, claim 17 is claim to a method using the method of claim 1. Therefore, claim 17 is rejected for the reasons set forth for claim 1.
Regarding Claim 31, SOUNDARARAJAN as modified by FOX discloses all the features of claim 17. The combination further discloses
wherein the direct communication links are optical fiber communication links and transmitting the challenge message comprises encoding the challenge message on an optical signal {SOUNDARARAJAN: [0065], “Although each location beacon device 100 is illustrated in FIG. 1 as transmitting beacons using radio frequency (RF) waves, it should be appreciated that, in some implementations, a location beacon device 100 may transmit a beacon using some other communication method such as a wired communication method (e.g., over coaxial and/or optical cables), a free space optical communication method (e.g., infrared, visible laser, etc.)”}.
Regarding claim 40, claim 40 is claim to a method using the method of claim 1. Therefore, claim 40 is rejected for the reasons set forth for claim 1.
Regarding claim 42, claim 42 is a dependent claim of claim 40, claim 42 is claim to method using the method of claim 8. Therefore, claim 42 is rejected for the reasons set forth for claim 8.
Regarding claim 45, claim 45 is claim to a system using the method of claim 1. Therefore, claim 45 is rejected for the reasons set forth for claim 1.
Regarding claim 46, claim 46 is claim to a computer program using the method of claim 1. Therefore, claim 40 is rejected for the reasons set forth for claim 1. Examiner’s note: claimed computer program (specification has support of patentable subject matter (Such a computer program may be encoded as executable instructions embodied in a carrier medium, non-transitory computer-readable storage device and/or a memory device in machine or device readable form).
Regarding Claim 47, SOUNDARARAJAN as modified by FOX discloses all the features of claim 46. The combination further discloses
A computer-readable data carrier having stored thereon the computer program of claim 46 {[0256], “In this document, the terms “machine readable medium,” “computer readable medium,” and similar terms are used to generally refer to non-transitory mediums, volatile or non-volatile, that store data and/or instructions that cause a machine to operate in a specific fashion”}.
Claim 4 is rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1) and further in view of GRICE; Warren P. (US 2018/0351738 A1).
Regarding Claim 4, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. However, the combination does not explicitly disclose
wherein one of the responder devices is collocated with a quantum key distribution (QKD) link terminal or QKD trusted node; and the method further comprising the validation device authenticating that one of the responder devices for participation in QKD based on the inferred data relating to the location of that one of the responder devices. relative to the beacon device.
In an analogous reference GRICE discloses
wherein one of the responder devices is collocated with a quantum key distribution (QKD) link terminal or QKD trusted node; and the method further comprising the validation device authenticating that one of the responder devices for participation in QKD based on the inferred data relating to the location of that one of the responder devices. relative to the beacon device {Figs. 1 & 3 & [0010], “The beacons are terrestrial radio beacons or ground stations and are in data communication with each other over an encrypted channel. In the current embodiment, the ground stations are connected over a fiber optic channel, and photonic quantum states are used to generate key material at both locations. If more than two ground stations are used, the timing signals are formatted such that the resulting message requires all signals, and QKD (Quantum Key Distribution) is generalized to quantum secret sharing, whereby quantum correlations are shared between three or more parties”}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to further modify SOUNDARARAJAN’s technique as modified by FOX of ‘setting up wireless comm link after a client listen from BEACON for ‘validating challenge and response’ for ‘QKD location’ by GRICE, in order to setup wireless link. The motivation is: the main advantage of using a validating challenge-and-response mechanism in QKD is to prevent a "man-in-the-middle" attack by ensuring the two communicating parties are legitimate and not being impersonated. This authentication process verifies that each party is who they claim to be, making the secure key exchange more robust.
Claims 9-11, 20 & 28 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1) and further in view of DONG; Peiliang et al. (US 2023/0073457 A1).
Regarding Claim 9, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. However, the combination does not explicitly disclose
wherein the challenge message indicates a problem for the responder devices to solve, each response message indicates a respective responder device solution to the problem and the confirmation message indicates one of the problem and a beacon device solution to the problem; and
wherein inferring which of the respective responder devices, if any, received the challenge message over the respective direct communication link comprises determining whether each responder device solution is a correct solution to the problem.
In an analogous reference DONG discloses
wherein the challenge message indicates a problem for the responder devices to solve, each response message indicates a respective responder device solution to the problem and the confirmation message indicates one of the problem and a beacon device solution to the problem {[0014], “The proposed invention relates particularly to a method of managing the timing of joining nodes to a wireless network, based on beacons transmitted by nodes of the wireless network. Such a method may reduce the risk of a large number of nodes attempting to join the network at the same time”. Examiner’s node: problem arises when too many nodes try to join a wireless network by listening to Beacon}; and
wherein inferring which of the respective responder devices, if any, received the challenge message over the respective direct communication link comprises determining whether each responder device solution is a correct solution to the problem {[0015], “Nodes attempting to join a network have no direct way of communicating with each other, which proves problematic for coordination of many nodes attempting to join a network at the same time. It is proposed that a solution to this problem can be provided by utilizing beacon messages”}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to further modify SOUNDARARAJAN’s technique as modified by FOX of ‘setting up wireless comm link after a client listen from BEACON for ‘validating challenge and response’ for ‘identifying wireless connectivity problem and subsequent solution by AP message with solution’ by DONG, in order to establish wireless channel’. The motivation is - the primary advantage of an Access Point (AP) identifying a wireless connectivity problem and communicating the solution via an automated message is rapid and automated problem resolution, which minimizes network downtime and reduces the need for manual IT intervention. This leads to significant operational efficiencies and an improved user experience.
Regarding Claim 10, SOUNDARARAJAN as modified by FOX and DONG discloses all the features of claim 9. The combination further discloses
the message store is a distributed ledger; the validation device is one of a plurality of peers which can participate in building the distributed ledger {SOUNDARARAJAN: [0075], “Machine readable medium 210 of client device 200 may include a blockchain wallet 211 and blockchain application 212. The blockchain wallet 211 may store the user's blockchain address 212, a public key 214 and private key 213 corresponding to the user's blockchain address 212”}; and
the confirmation message indicates the problem {SOUNDARARAJAN: [0014], “The proposed invention relates particularly to a method of managing the timing of joining nodes to a wireless network, based on beacons transmitted by nodes of the wireless network. Such a method may reduce the risk of a large number of nodes attempting to join the network at the same time”. Examiner’s node: problem arises when too many nodes try to join a wireless network by listening to Beacon}; and the method further comprises the validation device {SOUNDARARAJAN: [0076], “Client device 200 may utilize blockchain application 215 to interact with verifier 400 on blockchain network 300 as part of the process of proving the presence of the user of client device 200 at a particular location at a particular time”}:
determining that none of the responder devices received the challenge message over the respective direct communication link {DONG: [0014], “The proposed invention relates particularly to a method of managing the timing of joining nodes to a wireless network, based on beacons transmitted by nodes of the wireless network. Such a method may reduce the risk of a large number of nodes attempting to join the network at the same time”. Examiner’s node: problem arises when too many nodes try to join a wireless network by listening to Beacon}; and
responsive to determining that none of the responder devices received the challenge message, solving the problem and submitting a resulting validation device solution to the distributed ledger {DONG: [0015], “Nodes attempting to join a network have no direct way of communicating with each other, which proves problematic for coordination of many nodes attempting to join a network at the same time. It is proposed that a solution to this problem can be provided by utilizing beacon messages”}.
Regarding Claim 11, SOUNDARARAJAN as modified by FOX and DONG discloses all the features of claim 9. The combination further discloses
the message store is a distributed ledger {SOUNDARARAJAN: [0075], “Machine readable medium 210 of client device 200 may include a blockchain wallet 211 and blockchain application 212. The blockchain wallet 211 may store the user's blockchain address 212, a public key 214 and private key 213 corresponding to the user's blockchain address 212”}; and
the validation device is one of a plurality of peers which can participate in building the distributed ledger {SOUNDARARAJAN: [0076], “Client device 200 may utilize blockchain application 215 to interact with verifier 400 on blockchain network 300 as part of the process of proving the presence of the user of client device 200 at a particular location at a particular time”}; and
the computer-implemented method further comprises the validation device participating in adding an entry to the distributed ledger in respect of only a first solution to the problem submitted to the distributed ledger {DONG: [0015], “Nodes attempting to join a network have no direct way of communicating with each other, which proves problematic for coordination of many nodes attempting to join a network at the same time. It is proposed that a solution to this problem can be provided by utilizing beacon messages”}.
Regarding claim 20, claim 20 is a dependent claim of claim 17, claim 20 is claim to method using the method of claim 9. Therefore, claim 20 is rejected for the reasons set forth for claim 9.
Regarding Claim 28, SOUNDARARAJAN as modified by FOX & DONG discloses all the features of claim 20. The combination further discloses
wherein the direct communication links are radio communication links and transmitting the challenge message comprises encoding the challenge message on one or more radio transmissions {[0065], “Although each location beacon device 100 is illustrated in FIG. 1 as transmitting beacons using radio frequency (RF) waves”}.
Claims 12, 33 & 34 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1) and further in view of CHOI; Jinsoo et al. (US 2015/0063232 A1) and COON; Justin et al. (US 2008/0240270 A1).
Regarding Claim 12, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. The combination further discloses
the computer-implemented method further comprising the validation device {SOUNDARARAJAN: Fig.1 & [0056] FIG. 1 is a diagram illustrating an example environment that uses location beacon devices 100-1 to 100-N (individually referred to as a location beacon 100) and a blockchain network 300 including a verifier server system 400 (“verifier 400”) to prove the presence of a user of client device 200 at a particular location and time”} inferring data relating to the respective direct communication links from timing of each response message with respect to times the challenge message {SOUNDARARAJAN: [0062], “Each location beacon device 100 may include time-based hash generation instructions 114 that, when executed by processing device 120, apply a time-based cryptographic hashing algorithm to location blockchain address 113 to generate a secured representation of the location blockchain address. The secured representation of the location blockchain address may be generated by applying a one-time cryptographic hashing algorithm using a current timestamp and the location blockchain address”} …
However, the combination does not explicitly disclose
the challenge message is transmitted at a first predetermined signal-to-noise ratio (SNR); and
between transmitting the challenge message and the confirmation message, the beacon device is configured to transmit one or more SNR-incremented repetitions of the challenge message at successively higher SNRs;
the computer-implemented method further comprising the validation device inferring data relating to the respective direct communication links from timing of each response message with respect to times the challenge message and the SNR-incremented repetitions of the challenge message were transmitted.
In an analogous reference CHOI discloses
the challenge message is transmitted at a first predetermined signal-to-noise ratio (SNR) {[0094], “The authentication frame can include information on an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, an RSN (robust security network), a finite cyclic group and the like. The above-mentioned corresponds to a part of examples of information capable of being included in the authentication request/response frame only” … [0122], “Referring to FIG. 9, the HT control field can include … a bandwidth (BW) subfield and a signal to noise ratio (SNR) subfield”}; and
In an analogous reference COON discloses
between transmitting the challenge message and the confirmation message, the beacon device is configured to transmit one or more SNR-incremented repetitions of the challenge message at successively higher SNRs; … and the SNR-incremented repetitions of the challenge message were transmitted {[0081], “FIG. 10 depicts a diagram showing the probability of incorrectly identifying the interference avoidance template as a function of SNR for different channel lengths L when the proposed invention is used. The diagram shows this metric as a function of SNR for several channels with varying degrees of dispersion (indicated by L in the diagram)”}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to further modify SOUNDARARAJAN’s technique as modified by FOX of ‘setting up wireless comm link after a client listen from BEACON for ‘validating challenge and response’ for ‘using Signal to Noise Ratio (SNR)’ by CHOI & COON, in order to establish quality wireless link’. The motivation is - a higher Signal-to-Noise Ratio (SNR) improves wireless connections by ensuring greater reliability, higher data transfer rates, and a more robust connection, as it indicates the signal is significantly stronger than background noise. This minimizes data errors, reduces dropped connections, and allows for higher-quality performance, such as seamless streaming and online gaming.
Regarding Claim 33, SOUNDARARAJAN as modified by FOX discloses all the features of claim 17. However, the combination does not explicitly disclose
wherein transmitting the challenge message comprises adding noise to a signal carrying the challenge message.
COON further discloses
wherein transmitting the challenge message comprises adding noise to a signal carrying the challenge message {[0081], “FIG. 10 depicts a diagram showing the probability of incorrectly identifying the interference avoidance template as a function of SNR for different channel lengths L when the proposed invention is used. The diagram shows this metric as a function of SNR for several channels with varying degrees of dispersion (indicated by L in the diagram) … [0084], “This invention counters this problem and increases both the SNR and signal-to-interference noise ratio (SINR)”}.
Regarding claim 34, claim 34 is a dependent claim of claim 17, claim 34 is claim to method using the method of claim 12. Therefore, claim 34 is rejected for the reasons set forth for claim 12.
Claims 13, 15 & 16 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1) and further in view of HO; Jin-Meng (US 2010/0195552 A1).
Regarding Claim 13, SOUNDARARAJAN as modified by FOX discloses all the features of claim 1. However, the combination does not explicitly disclose
wherein authenticating the one or more responder devices for two-way communication with the beacon device in dependence on timings of the respective response messages comprises authenticating a responder device whose response message was earliest and denying authentication of any other responder devices.
In an analogous reference HO discloses
wherein authenticating the one or more responder devices for two-way communication with the beacon device in dependence on timings of the respective response messages comprises authenticating a responder device whose response message was earliest and denying authentication of any other responder devices {[0037], “The B+RAP1 Length field is set to the length of the random access phase (RAP), in units of allocation slots, that starts at the end of the beacon frame in the next beacon period, plus the beacon transmission time that precedes. Status Code field 406 is set to the status of the connection assignment, which indicates if the connection request was accepted or rejected and, if rejected, the reason for the rejection”. Examiner’s note: earlier Beacon responses from a wireless client gets priority and later connection requests are denied}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to further modify SOUNDARARAJAN’s technique as modified by FOX of ‘setting up wireless comm link after a client listen from BEACON for ‘validating challenge and response’ to ‘provide priority of wireless connection to client devices that responded beacon message and rejecting late requesting wireless stations’ by HO, in order to scale too many wireless connection requests by wireless stations’. The motivation is - prioritizing wireless connections for client devices that respond promptly to a beacon message, while potentially rejecting late-requesting stations, offers several advantages related to network efficiency, performance, and resource management.
Regarding Claim 15, SOUNDARARAJAN as modified by FOX and further modified by HO discloses all the features of claim 13. The combination further discloses
wherein authenticating the one or more responder devices for two-way communication with the beacon device in dependence on timings of the respective response messages comprises authenticating any responder device whose response message is before a cut-off time and denying authentication of any other responder devices {[0006], “The 1-periodic and m-periodic allocations may be used for both uplink and downlink traffic. The 1-periodic and m-periodic allocation intervals are defined as starting some time T1 after the start of the beacon frame time within a beacon period” … [0037], “The B+RAP1 Length field is set to the length of the random-access phase (RAP), in units of allocation slots, that starts at the end of the beacon frame in the next beacon period, plus the beacon transmission time that precedes. Status Code field 406 is set to the status of the connection assignment, which indicates if the connection request was accepted or rejected and, if rejected, the reason for the rejection”. Examiner’s note: earlier Beacon responses from a wireless client gets priority and later connection requests are denied}.
Regarding Claim 16, SOUNDARARAJAN as modified by FOX and further modified by HO discloses all the features of claim 13. The combination further discloses
wherein the beacon device is a network node and authenticating the one or more responder devices for two-way communication with the beacon device in dependence on timings of the respective response messages comprises authenticating the one or more responder devices for network access via the network node {[0062, “[0062] Each location beacon device 100 may include time-based hash generation instructions 114 that, when executed by processing device 120, apply a time-based cryptographic hashing algorithm to location blockchain address 113 to generate a secured representation of the location blockchain address … A suitable time-based, hash-based message authentication code (HMAC) algorithm may be utilized to generate the secured representation of the blockchain address}.
Claim 24 is rejected under AIA 35 U.S.C. 103 as being unpatentable over SOUNDARARAJAN; Abilash et al. (US 2020/0034876 A1) in view of FOX, Luke Richard et al. (US 2018/0103036 A1) and further in view of MORCHON; Oscar Garcia (US 2023/0308877 A1).
Regarding Claim 24, SOUNDARARAJAN as modified by FOX discloses all the features of claim 20. However, the combination does not explicitly disclose
wherein the problem comprises determination of a salt which, when combined with a specified input string via a specified cryptographic hash function, produces an output string comprising a specified string.
In an analogous reference MORCHON discloses
wherein the problem comprises determination of a salt which, when combined with a specified input string via a specified cryptographic hash function, produces an output string comprising a specified string {[0320], “A salt is random data that is used as an additional input to a cryptographic function that “hashes” data, such as a password or passphrase. Salts are closely related to the concept of nonce. The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack” … So, a combination string of bits of a required length is formed to be cryptographically processed”}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to further modify SOUNDARARAJAN’s technique as modified by FOX of ‘setting up wireless comm link after a client listen from BEACON for ‘addition of salt. i.e. random number with cryptographic hash’ by MORCHON, in order to establish secured wireless links. The motivation is - The main advantage of adding a random salt to a cryptographic hash for securing wireless links is to prevent attackers from using precomputed tables, such as rainbow tables, to crack credentials. This technique ensures that even if two users have the same password, their resulting hashes will be unique, significantly hindering attacks based on common passwords and password reuse. It also helps to slow down brute-force attacks and adds a crucial layer of security for authentication in wireless networks.
Allowable subject matter
Dependent claims 5, 6 & 14 will be allowable if written in independent form with base claim 1; dependent claims 19, 21,22, 25-27, 29, 30, 32 & 35-39 will be allowable if written in independent form with the base claim 17.
Independent claim 43 is allowed as filed.
Again, claims 2, 18, 41, 44 & 48 have been canceled.
Therefore, claims 5, 6 & 14, 19, 21-23, 25-27, 29, 30, 32 & 35-39 are objected.
Reasons of allowance: what is missing from the prior arts is: the beacon device uses directional transmission means to first transmit a challenge message in a predetermined direction. Before submitting the confirmation message, it transmits one or more directed repetitions of the challenge message in different further directions. The validation device then infers the location data of each responder by analyzing the timings of their response messages relative to the transmission times of the original and repeated directional challenge messages.
Conclusion
Following prior art has been consulted but is not applied:
SOUTH; John A. (US 9,980,137 B2) – Secure Beacon-based location systems and methods: “A method for secure, beacon-based emergency location is disclosed. The method includes detecting, with an app instance executing on a user device, a signal from a beacon disposed in a geographical location physically proximate to the user device, and transmitting in response to the detecting app instance verification information to the beacon” … “The database also stores the beacon public keys, which are associated with (indexed by) the beacon identifiers. In one embodiment, after the beacon identifier and beacon private keys have been stored in a beacon's memory, they may not be modified via a wireless connection to reduce the possibility of remote tampering”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUAZI FAROOQUI whose telephone number is (571) 270-1034 or Quazi.farooqui@uspto.gov. The examiner can normally be reached on Monday-Friday 9:00 am to 5:30 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amir Mehrmanesh can be reached on (571) 270-3351 or amir.mehrmanesh@USPTO.GOV. The fax phone number for Examiner Farooqui assigned is 571-270-2034.
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-flee). 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.
/QUAZI FAROOQUI/
Primary Examiner, Art Unit 2491