WO2021150273A1 - Apparatus and locale-based method for thwarting deceptions and/or denial of services - Google Patents

Apparatus and locale-based method for thwarting deceptions and/or denial of services Download PDF

Info

Publication number
WO2021150273A1
WO2021150273A1 PCT/US2020/047570 US2020047570W WO2021150273A1 WO 2021150273 A1 WO2021150273 A1 WO 2021150273A1 US 2020047570 W US2020047570 W US 2020047570W WO 2021150273 A1 WO2021150273 A1 WO 2021150273A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile device
server
site
service
token
Prior art date
Application number
PCT/US2020/047570
Other languages
French (fr)
Inventor
Robert Kavaler
Sophia Haoui
Todd Stiers
Original Assignee
Sensys Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/800,607 external-priority patent/US10873859B1/en
Application filed by Sensys Networks, Inc. filed Critical Sensys Networks, Inc.
Priority to US17/043,650 priority Critical patent/US11706583B2/en
Priority to EP20915164.6A priority patent/EP4094416A4/en
Publication of WO2021150273A1 publication Critical patent/WO2021150273A1/en
Priority to US17/495,680 priority patent/US11778413B2/en
Priority to US18/236,885 priority patent/US20230396951A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/104—Location integrity, e.g. secure geotagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud

Definitions

  • Embodiments adapt and/or configure the transmitting device near the site, the mobile device communicating with the transmitting device using a short haul wireless communications protocol to deliver a token based upon a key shared with the server but invisible to the mobile device.
  • the server can determine the proximity of the mobile device to the site to control actuation of the requested service or disable the service request, and possibly flushing the service request from the server.
  • a parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection.
  • some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
  • the inventors have solved the technical problems of validating the location of mobile devices near a site where one or more service may be requested.
  • This invention in its various embodiments, renders the determination of which mobile device is near a site deterministic, in effect contributing to at least partial, and in many instances, complete technical solution to these and many similar problems which may inflict harm and/or inconvenience upon lawful, cooperative inhabitants of our cities, industries, highways, and farms. It encompasses implementations which make “spoofing” the location of a mobile device difficult, and in a number of situations nearly impossible.
  • One embodiment is implemented as apparatus including a mobile device 100, a transmitting device 200 and a server 300 as shown in Fig. 3 to Fig. 14D.
  • the server 300 and the transmitting device 200 share a first key 600 they each independently use based upon an token generator 610.
  • the first key 600 is invisible to any of the mobile devices 100 which may request a service 500 that is performed no more than a third distance 510 from site 200.
  • the invention may further operate as follows:
  • the transmitting device 200 generates a token 220 using the first key 600 and the token generator 610 and generates a wireless message 230 including the token 220.
  • the transmitting device may include a short-haul transmitter to send the wireless message 230.
  • the mobile device 200 includes a short-haul receiver 140 to receive the wireless message 230 as a received wireless message 130 when, and only when, mobile device 200 is within a first distance 110 of the transmitting device 200.
  • the mobile device 100 responds to the received wireless message 130 by parsing the wireless message to generate the token 220 without wireless communicating to the transmitting device 200.
  • the mobile device sends a service request to the server to perform a service at the site.
  • the mobile device sends a message to the server including a form of the token to confirm the mobile device is no more than the first distance from the transmitting device.
  • FIG. 1A and Fig. IB show an example of a parade scheduled to cross an intersection, which a bad actor can delay and/or disrupt by spoofing the location of a large number of bicycles. These drawings also show the potential deleterious effects of many fake requests persisting in a server’s memory, potentially causing server malfunctions;
  • FIG. 2A and Fig. 2B show an example of a large number of people requesting elevator service from the 50 th floor of a high-rise building, which a bad actor may delay and/or disrupt by spoofing the location of a large number of other people;
  • FIG. 2C and Fig. 2D show an example of people requesting elevator service from the 50 th floor of a high-rise building, which a bad actor may delay and/or disrupt by spoofing a fire alert on a lower floor;
  • FIG. 2E and Fig. 2F show an example of mobile devices being used to spoof a large number of requests to a valet parking facility which clog the delivery site, where actually the number of requests is much smaller and do not clog the delivery site;
  • FIG. 3 Fig. 4, Fig. 5, Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12A, and Fig. 12B show some examples of the apparatus and their interactions in accord with the invention
  • Fig. 13 shows a first example of the distribution of the first key of the previous drawings to the transmitting device and the server which is invisible to the mobile device;
  • Fig. 14A, Fig. 14B, Fig. 14C, and Fig. 14D show a second example of the distribution of the first key of the previous drawings to the transmitting device and the server which is invisible to the mobile device;
  • Fig. 15 shows the short haul receiver included in the mobile device and the short haul transmitter included in the transmitting device of previous drawings to be compliant with a short-haul wireless protocol
  • FIG. 16A shows some examples of short-haul wireless communications protocols of Fig. 15;
  • Fig. 16B shows some examples of versions of the Bluetooth of Fig. 16A;
  • Fig. 17 shows some examples of the mobile device implementation
  • Fig. 18 shows that the mobile device, the transmitting device, the server and/or the service actuator of previous drawings may include one or more processors engaged to implement at least part of the apparatus as disclosed and/or claimed herein;
  • Fig. 19 shows the solution to the technical problem discussed regarding Fig. 1A and Fig. IB;
  • Fig. 20 shows the solution to the technical problem discussed regarding Fig. 2A and Fig. 2B;
  • Fig. 21 shows the solution to the technical problem discussed regarding Fig. 2C and Fig. 2D;
  • Fig. 22 shows the solution to the technical problem discussed regarding Fig. 2E and Fig. 2F.
  • a parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection.
  • some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
  • the inventors have solved the technical problems of validating the location of mobile devices 100 near a site 250 where one or more site related service 500 is requested.
  • This invention in its various embodiments, renders the determination of which mobile device 100 is near the site 250 deterministic, in effect contributing to at least partial, and in many instances, complete technical solution to these and many similar problems which may inflict harm and/or inconvenience upon lawful, cooperative inhabitants of our cities, industries, highways, and farms. It encompasses implementations which make “spoofing” the location of a mobile device 100 difficult, and in a number of situations nearly impossible. [040] Fig.
  • FIG. 3 shows a basic schematic of one embodiment is implemented as apparatus including a mobile device 100, a transmitting device 200 at no more than a second distance 210 from a site 250 and a server 300.
  • the server 300 and the transmitting device 200 share a first key 600 they each independently use based upon a token generator 610.
  • the first key 600 is invisible to any of the mobile devices 100 which may request a service 500 that is performed no more than a third distance 510 from site 200.
  • the token generator 610 may implement a form of a secure hash algorithm of the first key 600 to generate a token 220 shown in subsequent drawings, or alternatively, implement an encryption algorithm of the first key to generate the token 220.
  • Fig. 4 shows a progression from Fig. 3 wherein the transmitting device 200 generates a transmitter time estimate 260.
  • the first key 600 and the transmitter time estimate 260 stimulate the token generator 610 to generate the token 220.
  • the transmitter time estimate 260 also stimulates the generation of a transmitter time component 262.
  • the transmitter time component 262 represents a selection of some of the bits of the transmitter time estimate 260.
  • the transmitter time component 262 may be implemented as an offset from some observed time event, such as a timing synchronization message.
  • Fig. 5 shows a progression from Fig. 4 wherein the transmitting device 200 packages the token 220 and the transmitter time component 262 into at least part of the data payload of a wireless message 230.
  • the wireless message 230 may also include message type and/or error control components which may not be part of the data payload.
  • the short-haul receiver 140 of the mobile device 100 and the short-haul transmitter 240 of the transmitting device 200 are compliant with a short- haul wireless communication protocol 700 as shown in Fig. 15.
  • the short- haul communications protocol 700 is a version of Bluetooth 710 as shown in Fig. 16A, and that the version of Bluetooth is at least Bluetooth 4.0 712 as shown in Fig. 16B.
  • the message type of the wireless message 230 of Fig. 5 may be an advertisement, which does not require a dialog with the mobile device 100 for its short-haul receiver 140 to receive the wireless message 230 from the short-haul transmitter 240 of the transmitting device 200.
  • Fig. 6 shows a progression from Fig. 5 wherein the mobile device responds to the sending of the wireless message 230 from the short-haul transmitter 240 of the transmitting device 200, which is received by the short-haul receiver 140 to generate the received message 130.
  • the received message 130 contains a data payload including the token 220 and the transmitter time component 262.
  • Fig. 7 shows a progression from Fig. 6 wherein the mobile device 100 responds to the received message 130 to generate a message 150 containing a data payload including the transmitter time component 262, a service request 155 and a Message Integrity Check (MIC) 160.
  • the MIC 160 may be generated from the token 220, the transmitter time component 262 and the service request 155.
  • Fig. 8 shows a progression from Fig. 7 wherein the mobile device 100 sends the message 150 to the server 300.
  • the server 300 responds by generating the received message 350 which includes the transmitter time component 262, the server request 155 and the MIC 160. Also shown is the server 300 containing a server time estimate 360.
  • Sending the message 150 from mobile device 100 to the server 300 may involve multiple physical transport layer traversals. For example, suppose the mobile device 100 implements a cellular phone 800 as shown in Fig. 17. It is quite possible that the mobile device 100 sending the message 150 may first traverse a wireless physical transport to a cellular base station and/or to a wireless hot spot of some sort. Subsequently, the message 150 may traverse a wireline physical transport, such as a fiber optic network to reach the server 300.
  • a wireless physical transport such as a fiber optic network
  • the received message 350 and the server time estimate 360 may have no inherent time order to their generation.
  • the server 300 includes a processor 900 as shown in Fig. 18.
  • the processor 900 includes at least one computer 910. It is common for computers 910 to operate a real-time operating system which may collect events such as the reception of the received message 350 and the generation of the server time estimate 360. A task and/or a task thread may be queued for execution when both of these events are present, which can lead to the activities in the server 300 shown in Fig. 9.
  • Fig. 9 shows a progression from Fig. 8, wherein the server 300 reconstructs the transmitter time estimate 260 first shown in Fig. 4.
  • the server 300 may generate the transmitter time estimate 260 in response to the transmitter time component 262 and the server time estimate 360. There are some things to note.
  • the server time estimate 360 and the transmitter time estimate may be measured in the same time units or different time units.
  • the server time estimate 360 may be measured in units of a micro-second whereas the transmitter time estimate 260 may be measured in units of a milli-second.
  • both may be measured in units of a milli-second.
  • the generation of the transmitter time estimate 260 may be a form of adjustment of the server time estimate 360 to the closest time compatible the transmitter time component 262.
  • one or more of the formats may be a form of fixed point numbers and/or floating point numbers.
  • Fig. 10 shows a progression from Fig. 9 wherein the server responds to the generation of the transmitter time estimate 260 by using the transmitter time estimate 260 and the first key 600 to stimulate the token generator 610 to generate the calculated token 320.
  • Fig. 11 shows a progression from Fig. 10 wherein if the calculated token 320 is essentially the same as the token 220, then the received message 350’s payload containing the transmitter time component 262, the Message Integrity Check (MIC) 160, the service request 155 and the calculated token 320 lead the server 300 to authenticate 352 the received message 350.
  • the server 300 further responds by actuating 340 the server request 155, thereby stimulating the service actuator 520 to perform the service 500 near (within the third distance 510) of the site 250.
  • MIC Message Integrity Check
  • Fig. 12A shows a second progression from Fig. 10, in which the previously discussed data payload components of the received message 350 and the calculated token 320 are not essentially the same as the token 220.
  • the server 300 does not authenticate 354 the received message 350. For example, suppose a bad actor wants to spoof lots of bicycles as in Fig. 1 A, by using old tokens or fabricating fake tokens 220 in multiple mobile devices 100. The received messages will fail to authenticate 354.
  • Fig. 12B shows a progression of Fig. 12A wherein the server 300 responds to the received message of Fig. 12A not being authenticated 354 by generating a disable service request 340, which may include but is not limited to, removing the received message 350 and/or removing the transmitter time estimate 260 and/or removing the calculated token 320, each shown in Fig. 12A.
  • a disable service request 340 may include but is not limited to, removing the received message 350 and/or removing the transmitter time estimate 260 and/or removing the calculated token 320, each shown in Fig. 12A.
  • Fig. 13 shows a first example of distributing the first key 600 to the transmitting device 200 and the server 300 by a virtual private network 650, to which the mobile device is not a member, and therefore cannot sniff the first key 600.
  • Fig. 14A, Fig. 14B, Fig. 14C and Fig. 14D show an example of the Diffie Heilman key exchange to generate the first key 600 without the first key being visible on any connection to the mobile device 100.
  • This discussion will focus on the use of numbers n and G.
  • n is often a prime and G is a second, large prime, possibly of more than 100 bytes in length.
  • implementations n and G are groups. While these group implementations are well understood, they are less transparent and are left to the literature of those of common skill in the art.
  • Fig. 14A shows the mobile device 100, the transmitting device 200 and the server 300 all connected by an insecure network, where the mobile device 100 can sniff the communications between the transmitting device 200 and the server 300.
  • the generator G and the base n are distributed to each of the mobile device 100, the transmitting device 200, and the server 300.
  • the transmitting device generates a local key a, which is not visible on the insecure network.
  • the server 300 generates a local key b, which is also not visible on the insecure network.
  • the transmitting device 200 generate the public key n A a, which is the large number n raised to the power a, modulo G.
  • x modulo G is the remainder resulting from dividing x by G.
  • Fig. 14B shows the result of the transmitting device 200 in Fig. 14A sending the public key n A a across the insecure network, so that it is now available at the mobile device 100 and the server 300.
  • the server 300 generates the public key n A b, by performing n A b modulo G.
  • Fig. 14C shows the results of distributing the public key n A b to the transmitting device 200 and the mobile device 100, which both now include the public key n A b.
  • Fig. 14D shows the magic of mathematics in our time.
  • the mobile device 100 cannot generate the first key 600 without solving the discrete logarithm problem, which is very computationally expensive, making the first key 600 invisible to the mobile device 100
  • Fig. 15 shows the short haul receiver 140 included in the mobile device 100 and the short haul transmitter 240 included in the transmitting device 100 of previous drawings to be compliant with a short-haul wireless protocol 700.
  • Fig. 16A shows some examples of short-haul wireless communications protocols 700, which may include, but are not limited to Bluetooth® 710, Cellular V2X (C-V2X) 730, and Dedicated short-range communications (DSRC) 740.
  • short-haul wireless communications protocols 700 may include, but are not limited to Bluetooth® 710, Cellular V2X (C-V2X) 730, and Dedicated short-range communications (DSRC) 740.
  • Fig. 16B shows some examples of versions of the Bluetooth 710 which may include but are not limited to Bluetooth 4.0 712, Bluetooth 4.1 714, Bluetooth 4.2 716, Bluetooth 5.0 718, Bluetooth 5.1 720, Bluetooth 5.2 722 and Bluetooth x.y 724, where x is at least 4 and y is at least 0.
  • Bluetooth 4.0 is essentially the same as Bluetooth 4
  • Bluetooth 5.0 is essentially the same as Bluetooth 5, and so on.
  • the Bluetooth wireless protocol has incorporated a form of message sometimes referred to as an advertisement which is broadcast by a transmitting device 200 and received by a mobile device 100 without any connection dialog between these two devices.
  • the advertisement messages can be generated as the wireless message 230 including the token 220. Parsing the wireless message 130 may involve calculating a signature, which may be used by the mobile device 100 to authenticate the token 220 generated by the transmitting device 200.
  • communications between the mobile device 100 and the server 300 may employ an encryption mechanism and/or a second shared key to provide secure communications between the mobile device 100 and the server 300.
  • a signature may be incorporated in message 150, which may be used by the server 300 to authenticate the received message 350.
  • the signature may be based upon the token 220 in such a way that the token 220 itself may not be derived.
  • Fig. 17 shows some examples of the mobile device 100 implementing one or more of the following: a cellular phone 800, a wireless client device 810, an SMS messaging device 820, a vehicle mounted device 830 and/or a human mounted device 840.
  • a wireless client device 810 may be a tablet computer and/or a notebook computer.
  • a vehicle mounted device 830 may be mounted on or in a covered vehicle and/or a bicycle, which may further provide Global Positioning Service (GPS) based navigation assistance.
  • GPS Global Positioning Service
  • a human mounted device may be wrist mounted somewhat similar to a watch, forearm or arm mounted, possibly providing a small keypad. The human mounted device may also be worn about the neck, somewhat like a necklace.
  • each processor 900 may include at least one instance of a computer 910, a Finite State Machine 920, an Inference Engine 930 and/or a Neural Network 940.
  • a computer 910 includes at least one data processor and at least one instruction processor, wherein the data processor is instructed by at least one of the instruction processors.
  • the Finite State Machine 920 receives at least one input signal, maintains at least one state and generates at least one output signal based upon the value of at least one of the input signals and/or at least one of the states.
  • the Inferential Engine 930 includes at least one inferential rule and maintains at least one fact based upon at least one inference derived from at least one of the inference rules and factual stimulus and generates at least one output based upon the facts.
  • the Neural Network 940 maintains at list of synapses, each with at least one synaptic state and a list of neural connections between the synapses.
  • the Neural Network 940 may respond to stimulus of one or more of the synapses by transfers through the neural connections that in turn may alter the synaptic states of some of the synapses.
  • FIG. 19 shows the solution to the technical problem discussed regarding Fig. 1A and Fig. IB. Recall the technical problem involved:
  • a parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection.
  • some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1 A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
  • Fig. 20 shows the solution of this technical problem, where the real person, equipped with a mobile device 100 can request the elevator, but the other spoofed requests are ignored. As shown and discussed Fig. 12B above, the false service requests are disabled and removed from the server 300.
  • Fig. 21 shows the solution to the technical problem discussed regarding Fig. 2C and Fig. 2D. Recall the technical problem involved:
  • a bad actor operates a mobile device to initiate a fire alert on a lower floor while the (people) on an upper floor are leaving the building as shown in Fig. 2D.
  • These disruptive steps could have a large effect on multiple individuals and businesses in and around the building, as well as first responders and other emergency personnel.
  • Fig. 22 shows the solution to the technical problem discussed regarding Fig. 2E and Fig. 2F. Recall the technical problem involved:
  • Fig. 2E The customers of a valet parking facility can request their cars through an application on their mobile devices.
  • a bad actor impersonates a large number of these customer mobile devices, requesting that their vehicles be made ready for their use, overwhelming the valet service mechanism’s ability to recognize and service the actual customer requests as shown in Fig. 2E.
  • Fig. 2F shows the actual situation, which many fewer requests are being made and the delivered vehicles do not overwhelm the delivery site.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Technical problems and their solution are disclosed regarding the location of mobile devices requesting services near a site from a server. Embodiments adapt and/or configure the transmitting device near the site, the mobile device communicating with the transmitting device using a short haul wireless communications protocol to deliver a token based upon a key shared with the server but invisible to the mobile device. The server can determine the proximity of the mobile device to the site to control actuation of the requested service or disable the service request, and possibly flushing the service request from the server. Solutions are disclosed for traffic intersections involving one or more traffic lights, elevators in buildings, fire alarms in buildings and valet parking facilities.

Description

United States Utility Patent Application
Apparatus and Locale-Based Method for Thwarting Deceptions and/or Denial of
Services
Technical Field
[001] Technical problems and their solution are disclosed regarding the location of mobile devices requesting services near a site from a server. Embodiments adapt and/or configure the transmitting device near the site, the mobile device communicating with the transmitting device using a short haul wireless communications protocol to deliver a token based upon a key shared with the server but invisible to the mobile device. The server can determine the proximity of the mobile device to the site to control actuation of the requested service or disable the service request, and possibly flushing the service request from the server.
Background of the Invention
[002] The inventors have found a new class of technical problems which is discussed in the summary of the invention. Summary of the Invention
[003] The inventors have discovered two inter-related questionable situations, with technical problems associated with each.
[004] First, how does a server know that a user of a mobile device is where they, or their mobile device claim them to be?
[005] Second, how does the server weed through bogus requests to find one or more real requests to use a localized service, such as a traffic light, an elevator, enter a building and so on?
[006] Today, internet denial of service attacks are well known and understood regarding internet service provider systems. However, location-based denial of service attacks are not well known or understood. The inventors came across this technical form of attack by performing a simple experiment on a wireless sensor system. This is a new technical problem which can affect a wide cross section of sensor and actuator systems frequently found in cities, industrial complexes, warehouses, road way systems, and farms. This technical problem will be shown through examples of traffic lights at intersections, elevators in a high-rise building and automated requests to a valet system in a car parking facility. The example situations range from mild inconveniences to potentially life- threatening diminishment of services during an emergency, such as a real or spoofed fire in a high-rise building.
[007] Consider a first example shown in Fig. 1 A and Fig. IB, a parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection. Suppose some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
[008] Consider a second example, it is an end of shift time for workers (people) on an upper floor in a high-rise building as shown in Fig. 2A. Suppose some bad actor wants to slow or impede the workers (people) going off-shift through the abuse of cell phones requesting elevator service between lower floors as revealed in Fig. 2B. These fake requests may slow down and impede the going- off-shift workers (people) from leaving the high-rise building.
[009] Consider a third example, suppose some bad actor operates a mobile device to initiate a fire alert on a lower floor while the workers (people) on the upper floor are leaving the building at the end of their shift in Fig. 2C. This could be taken through several steps, including the impersonation of a mobile device associated with a security person for the building. These disruptive steps could have a large effect on multiple individuals and businesses in and around the building, as well as first responders and other emergency personnel. What is needed are devices and methods of their operation first shown in Fig. 2D, which can recognize a bad actor, and disregard the false alarms shown in Fig. 2C.
[010] Consider a fourth example, in which customers of a valet parking facility can request their cars through an application on their mobile devices. Suppose a bad actor impersonates a large number of these customer mobile devices, requesting that their vehicles be made ready for their use, overwhelming the valet service mechanism’s ability to recognize and service the actual customer requests as shown in Fig. 2E. Again, what is needed are devices and methods of their operation first shown in Fig. 2F, which can recognize a bad actor, and disregard the false requests shown in Fig. 2E.
[Oil] The inventors have solved the technical problems of validating the location of mobile devices near a site where one or more service may be requested. This invention, in its various embodiments, renders the determination of which mobile device is near a site deterministic, in effect contributing to at least partial, and in many instances, complete technical solution to these and many similar problems which may inflict harm and/or inconvenience upon lawful, cooperative inhabitants of our cities, industries, highways, and farms. It encompasses implementations which make “spoofing” the location of a mobile device difficult, and in a number of situations nearly impossible.
[012] One embodiment is implemented as apparatus including a mobile device 100, a transmitting device 200 and a server 300 as shown in Fig. 3 to Fig. 14D. The server 300 and the transmitting device 200 share a first key 600 they each independently use based upon an token generator 610. The first key 600 is invisible to any of the mobile devices 100 which may request a service 500 that is performed no more than a third distance 510 from site 200. The invention may further operate as follows:
[013] The transmitting device 200 generates a token 220 using the first key 600 and the token generator 610 and generates a wireless message 230 including the token 220. The transmitting device may include a short-haul transmitter to send the wireless message 230. The mobile device 200 includes a short-haul receiver 140 to receive the wireless message 230 as a received wireless message 130 when, and only when, mobile device 200 is within a first distance 110 of the transmitting device 200.
[014] The mobile device 100 responds to the received wireless message 130 by parsing the wireless message to generate the token 220 without wireless communicating to the transmitting device 200. The mobile device sends a service request to the server to perform a service at the site. The mobile device sends a message to the server including a form of the token to confirm the mobile device is no more than the first distance from the transmitting device.
Brief Description of the Drawings
[015] Fig. 1A and Fig. IB show an example of a parade scheduled to cross an intersection, which a bad actor can delay and/or disrupt by spoofing the location of a large number of bicycles. These drawings also show the potential deleterious effects of many fake requests persisting in a server’s memory, potentially causing server malfunctions;
[016] Fig. 2A and Fig. 2B show an example of a large number of people requesting elevator service from the 50th floor of a high-rise building, which a bad actor may delay and/or disrupt by spoofing the location of a large number of other people;
[017] Fig. 2C and Fig. 2D show an example of people requesting elevator service from the 50th floor of a high-rise building, which a bad actor may delay and/or disrupt by spoofing a fire alert on a lower floor;
[018] Fig. 2E and Fig. 2F show an example of mobile devices being used to spoof a large number of requests to a valet parking facility which clog the delivery site, where actually the number of requests is much smaller and do not clog the delivery site;
[019] Fig. 3, Fig. 4, Fig. 5, Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12A, and Fig. 12B show some examples of the apparatus and their interactions in accord with the invention;
[020] Fig. 13 shows a first example of the distribution of the first key of the previous drawings to the transmitting device and the server which is invisible to the mobile device;
[021] Fig. 14A, Fig. 14B, Fig. 14C, and Fig. 14D show a second example of the distribution of the first key of the previous drawings to the transmitting device and the server which is invisible to the mobile device;
[022] Fig. 15 shows the short haul receiver included in the mobile device and the short haul transmitter included in the transmitting device of previous drawings to be compliant with a short-haul wireless protocol;
[023] Fig. 16A shows some examples of short-haul wireless communications protocols of Fig. 15;
[024] Fig. 16B shows some examples of versions of the Bluetooth of Fig. 16A;
[025] Fig. 17 shows some examples of the mobile device implementation; [026] Fig. 18 shows that the mobile device, the transmitting device, the server and/or the service actuator of previous drawings may include one or more processors engaged to implement at least part of the apparatus as disclosed and/or claimed herein;
[027] Fig. 19 shows the solution to the technical problem discussed regarding Fig. 1A and Fig. IB;
[028] Fig. 20 shows the solution to the technical problem discussed regarding Fig. 2A and Fig. 2B;
[029] Fig. 21 shows the solution to the technical problem discussed regarding Fig. 2C and Fig. 2D; and
[030] Fig. 22 shows the solution to the technical problem discussed regarding Fig. 2E and Fig. 2F.
Detailed Description of the Invention
[031] The inventors have discovered two technical problems with associated, inter-related questionable situations.
[032] First, how does a server 300 know that a user of a mobile device 100 is where they, or their mobile device claim them to be?
[033] Second, how does the server 300 weed through bogus requests to find one or more real requests to use a localized service 500, such as a traffic light, an elevator, enter a building and so on?
[034] Today, internet denial of service attacks are well known and understood regarding internet service provider systems. However, location-based denial of service attacks are not well known or understood. The inventors came across this technical form of attack by performing a simple experiment on a wireless sensor system. This is a new technical problem which can affect a wide cross section of sensor and actuator systems frequently found in cities, industrial complexes, warehouses, and road way systems, and farms. This technical problem will be shown through examples involving traffic lights at intersections, elevators in a high-rise building and automated requests to a valet system in a car parking facility. The example situations range from mild inconveniences to potentially life- threatening diminishment of services during an emergency, such as a real or spoofed fire in a high-rise building.
[035] Consider a first example shown in Fig. 1 A and Fig. IB, a parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection. Suppose some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
[036] Consider a second example, it is an end of shift time for workers, more generally, people on an upper floor in a high-rise building as shown in Fig. 2A. Suppose some bad actor wants to slow or impede the workers going off-shift through the abuse of cell phones 800 requesting elevator service between lower floors as revealed in Fig. 2B. These fake requests may slow down and impede the going-off-shift workers from leaving the high-rise building. Worse yet, the fake requests could potentially flood the server 300, potentially causing it to malfunction. To avoid this further technical problem, the server 300 needs to remove the fake requests from its pending request queue(s) as shown in Fig. 2B.
[037] Consider a third example. Suppose a bad actor operates a mobile device to initiate a fire alert on a lower floor while the (people) on an upper floor are leaving the building as shown in Fig. 2D. This could include impersonation of a mobile device associated with a security person for the building, giving the impression shown in Fig. 2C of an actual fire alert. These disruptive steps could have a large effect on multiple individuals and businesses in and around the building, as well as first responders and other emergency personnel.
[038] Consider a fourth example, in which customers of a valet parking facility can request their cars through an application on their mobile devices. Suppose a bad actor impersonates a large number of these customer mobile devices, requesting that their vehicles be made ready for their use, overwhelming the valet service mechanism’s ability to recognize and service the actual customer requests as shown in Fig. 2E. Fig. 2F shows the actual situation, which many fewer requests are being made and the delivered vehicles do not overwhelm the delivery site.
[039] The inventors have solved the technical problems of validating the location of mobile devices 100 near a site 250 where one or more site related service 500 is requested. This invention, in its various embodiments, renders the determination of which mobile device 100 is near the site 250 deterministic, in effect contributing to at least partial, and in many instances, complete technical solution to these and many similar problems which may inflict harm and/or inconvenience upon lawful, cooperative inhabitants of our cities, industries, highways, and farms. It encompasses implementations which make “spoofing” the location of a mobile device 100 difficult, and in a number of situations nearly impossible. [040] Fig. 3 shows a basic schematic of one embodiment is implemented as apparatus including a mobile device 100, a transmitting device 200 at no more than a second distance 210 from a site 250 and a server 300. The server 300 and the transmitting device 200 share a first key 600 they each independently use based upon a token generator 610. The first key 600 is invisible to any of the mobile devices 100 which may request a service 500 that is performed no more than a third distance 510 from site 200. In some implementations, the token generator 610 may implement a form of a secure hash algorithm of the first key 600 to generate a token 220 shown in subsequent drawings, or alternatively, implement an encryption algorithm of the first key to generate the token 220.
[041] Fig. 4 shows a progression from Fig. 3 wherein the transmitting device 200 generates a transmitter time estimate 260. The first key 600 and the transmitter time estimate 260 stimulate the token generator 610 to generate the token 220. The transmitter time estimate 260 also stimulates the generation of a transmitter time component 262. In some implementations, the transmitter time component 262 represents a selection of some of the bits of the transmitter time estimate 260. In some implementations, the transmitter time component 262 may be implemented as an offset from some observed time event, such as a timing synchronization message.
[042] Fig. 5 shows a progression from Fig. 4 wherein the transmitting device 200 packages the token 220 and the transmitter time component 262 into at least part of the data payload of a wireless message 230. Note that the wireless message 230 may also include message type and/or error control components which may not be part of the data payload.
[043] By way of example, suppose the short-haul receiver 140 of the mobile device 100 and the short-haul transmitter 240 of the transmitting device 200 are compliant with a short- haul wireless communication protocol 700 as shown in Fig. 15. Further, suppose the short- haul communications protocol 700 is a version of Bluetooth 710 as shown in Fig. 16A, and that the version of Bluetooth is at least Bluetooth 4.0 712 as shown in Fig. 16B. In this example, the message type of the wireless message 230 of Fig. 5 may be an advertisement, which does not require a dialog with the mobile device 100 for its short-haul receiver 140 to receive the wireless message 230 from the short-haul transmitter 240 of the transmitting device 200.
[044] Fig. 6 shows a progression from Fig. 5 wherein the mobile device responds to the sending of the wireless message 230 from the short-haul transmitter 240 of the transmitting device 200, which is received by the short-haul receiver 140 to generate the received message 130. The received message 130 contains a data payload including the token 220 and the transmitter time component 262.
[045] Fig. 7 shows a progression from Fig. 6 wherein the mobile device 100 responds to the received message 130 to generate a message 150 containing a data payload including the transmitter time component 262, a service request 155 and a Message Integrity Check (MIC) 160. The MIC 160 may be generated from the token 220, the transmitter time component 262 and the service request 155.
[046] Fig. 8 shows a progression from Fig. 7 wherein the mobile device 100 sends the message 150 to the server 300. The server 300 responds by generating the received message 350 which includes the transmitter time component 262, the server request 155 and the MIC 160. Also shown is the server 300 containing a server time estimate 360. There are several points which should be noted about this drawing:
[047] Sending the message 150 from mobile device 100 to the server 300 may involve multiple physical transport layer traversals. For example, suppose the mobile device 100 implements a cellular phone 800 as shown in Fig. 17. It is quite possible that the mobile device 100 sending the message 150 may first traverse a wireless physical transport to a cellular base station and/or to a wireless hot spot of some sort. Subsequently, the message 150 may traverse a wireline physical transport, such as a fiber optic network to reach the server 300.
[048] The received message 350 and the server time estimate 360 may have no inherent time order to their generation. For example, suppose the server 300 includes a processor 900 as shown in Fig. 18. Further suppose the processor 900 includes at least one computer 910. It is common for computers 910 to operate a real-time operating system which may collect events such as the reception of the received message 350 and the generation of the server time estimate 360. A task and/or a task thread may be queued for execution when both of these events are present, which can lead to the activities in the server 300 shown in Fig. 9.
[049] Fig. 9 shows a progression from Fig. 8, wherein the server 300 reconstructs the transmitter time estimate 260 first shown in Fig. 4. The server 300 may generate the transmitter time estimate 260 in response to the transmitter time component 262 and the server time estimate 360. There are some things to note.
[050] The server time estimate 360 and the transmitter time estimate may be measured in the same time units or different time units. For example, the server time estimate 360 may be measured in units of a micro-second whereas the transmitter time estimate 260 may be measured in units of a milli-second. Alternatively, both may be measured in units of a milli-second.
[051] While in a simplified environment, assuming the same time units, the generation of the transmitter time estimate 260 may be a form of adjustment of the server time estimate 360 to the closest time compatible the transmitter time component 262. For instance, one or more of the formats may be a form of fixed point numbers and/or floating point numbers.
[052] Fig. 10 shows a progression from Fig. 9 wherein the server responds to the generation of the transmitter time estimate 260 by using the transmitter time estimate 260 and the first key 600 to stimulate the token generator 610 to generate the calculated token 320.
[053] Fig. 11 shows a progression from Fig. 10 wherein if the calculated token 320 is essentially the same as the token 220, then the received message 350’s payload containing the transmitter time component 262, the Message Integrity Check (MIC) 160, the service request 155 and the calculated token 320 lead the server 300 to authenticate 352 the received message 350. The server 300 further responds by actuating 340 the server request 155, thereby stimulating the service actuator 520 to perform the service 500 near (within the third distance 510) of the site 250.
[054] Fig. 12A shows a second progression from Fig. 10, in which the previously discussed data payload components of the received message 350 and the calculated token 320 are not essentially the same as the token 220. In this situation the server 300 does not authenticate 354 the received message 350. For example, suppose a bad actor wants to spoof lots of bicycles as in Fig. 1 A, by using old tokens or fabricating fake tokens 220 in multiple mobile devices 100. The received messages will fail to authenticate 354.
[055] Fig. 12B shows a progression of Fig. 12A wherein the server 300 responds to the received message of Fig. 12A not being authenticated 354 by generating a disable service request 340, which may include but is not limited to, removing the received message 350 and/or removing the transmitter time estimate 260 and/or removing the calculated token 320, each shown in Fig. 12A.
[056] Fig. 13 shows a first example of distributing the first key 600 to the transmitting device 200 and the server 300 by a virtual private network 650, to which the mobile device is not a member, and therefore cannot sniff the first key 600.
[057] Fig. 14A, Fig. 14B, Fig. 14C and Fig. 14D show an example of the Diffie Heilman key exchange to generate the first key 600 without the first key being visible on any connection to the mobile device 100. This discussion will focus on the use of numbers n and G. n is often a prime and G is a second, large prime, possibly of more than 100 bytes in length. In some other, implementations n and G are groups. While these group implementations are well understood, they are less transparent and are left to the literature of those of common skill in the art.
[058] Fig. 14A shows the mobile device 100, the transmitting device 200 and the server 300 all connected by an insecure network, where the mobile device 100 can sniff the communications between the transmitting device 200 and the server 300. In this situation, the generator G and the base n are distributed to each of the mobile device 100, the transmitting device 200, and the server 300. The transmitting device generates a local key a, which is not visible on the insecure network. The server 300 generates a local key b, which is also not visible on the insecure network. The transmitting device 200 generate the public key nAa, which is the large number n raised to the power a, modulo G. x modulo G is the remainder resulting from dividing x by G.
[059] Fig. 14B shows the result of the transmitting device 200 in Fig. 14A sending the public key nAa across the insecure network, so that it is now available at the mobile device 100 and the server 300. The server 300 generates the public key nAb, by performing nAb modulo G.
[060] Fig. 14C shows the results of distributing the public key nAb to the transmitting device 200 and the mobile device 100, which both now include the public key nAb.
[061] Fig. 14D shows the magic of mathematics in our time. The transmitting device generates the first key 600 by computing (nAb)Aa modulo G, from the received public key nAb, because (nAb)Aa = nA(b*a) = nA(a*b). The server 300 calculates the first key 600 by computing (nAa)Ab modulo G, from the received public key nAa, because (nAa)Ab = nA(a*b). However, the mobile device 100 cannot generate the first key 600 without solving the discrete logarithm problem, which is very computationally expensive, making the first key 600 invisible to the mobile device 100
[062] This cryptographic key exchange was named after Whitfield Diffie and Martin Heilman for their work in the late 1970’s.
[063] Fig. 15 shows the short haul receiver 140 included in the mobile device 100 and the short haul transmitter 240 included in the transmitting device 100 of previous drawings to be compliant with a short-haul wireless protocol 700. [064] Fig. 16A shows some examples of short-haul wireless communications protocols 700, which may include, but are not limited to Bluetooth® 710, Cellular V2X (C-V2X) 730, and Dedicated short-range communications (DSRC) 740.
[065] Note that one or more of these short-haul wireless communications protocols may require a version number(s).
[066] Fig. 16B shows some examples of versions of the Bluetooth 710 which may include but are not limited to Bluetooth 4.0 712, Bluetooth 4.1 714, Bluetooth 4.2 716, Bluetooth 5.0 718, Bluetooth 5.1 720, Bluetooth 5.2 722 and Bluetooth x.y 724, where x is at least 4 and y is at least 0. Note that Bluetooth 4.0 is essentially the same as Bluetooth 4, Bluetooth 5.0 is essentially the same as Bluetooth 5, and so on.
[067] One skilled in the art will recognize that since Bluetooth 4.0, the Bluetooth wireless protocol has incorporated a form of message sometimes referred to as an advertisement which is broadcast by a transmitting device 200 and received by a mobile device 100 without any connection dialog between these two devices. As such, the advertisement messages can be generated as the wireless message 230 including the token 220. Parsing the wireless message 130 may involve calculating a signature, which may be used by the mobile device 100 to authenticate the token 220 generated by the transmitting device 200.
[068] Further, communications between the mobile device 100 and the server 300 may employ an encryption mechanism and/or a second shared key to provide secure communications between the mobile device 100 and the server 300. Alternatively, rather than additional encryption, a signature may be incorporated in message 150, which may be used by the server 300 to authenticate the received message 350. In some situations, the signature may be based upon the token 220 in such a way that the token 220 itself may not be derived.
[069] Fig. 17 shows some examples of the mobile device 100 implementing one or more of the following: a cellular phone 800, a wireless client device 810, an SMS messaging device 820, a vehicle mounted device 830 and/or a human mounted device 840. For example, a wireless client device 810 may be a tablet computer and/or a notebook computer. A vehicle mounted device 830 may be mounted on or in a covered vehicle and/or a bicycle, which may further provide Global Positioning Service (GPS) based navigation assistance. A human mounted device may be wrist mounted somewhat similar to a watch, forearm or arm mounted, possibly providing a small keypad. The human mounted device may also be worn about the neck, somewhat like a necklace. [070] Fig. 18 shows that the mobile device 100, the transmitting device 200, the server 300 and/or the service actuator 520 of previous drawings may include one or more processors 900 engaged to implement at least part of the apparatus as disclosed and/or claimed herein. Each processor 900 may include at least one instance of a computer 910, a Finite State Machine 920, an Inference Engine 930 and/or a Neural Network 940.
[071] As used herein, a computer 910 includes at least one data processor and at least one instruction processor, wherein the data processor is instructed by at least one of the instruction processors.
[072] As used herein, the Finite State Machine 920 receives at least one input signal, maintains at least one state and generates at least one output signal based upon the value of at least one of the input signals and/or at least one of the states.
[073] As used herein, the Inferential Engine 930 includes at least one inferential rule and maintains at least one fact based upon at least one inference derived from at least one of the inference rules and factual stimulus and generates at least one output based upon the facts.
[074] As used herein, the Neural Network 940 maintains at list of synapses, each with at least one synaptic state and a list of neural connections between the synapses. The Neural Network 940 may respond to stimulus of one or more of the synapses by transfers through the neural connections that in turn may alter the synaptic states of some of the synapses.
[075] Fig. 19 shows the solution to the technical problem discussed regarding Fig. 1A and Fig. IB. Recall the technical problem involved:
[076] A parade is scheduled to proceed across multiple lanes of a roadway and approaches an intersection. Suppose some bad actor wants to slow down the parade by impersonating bicyclists waiting at the intersection as shown in Fig. 1 A, through the abuse of several cell phones operating traffic applications intended to recognize the cell phone users as bicyclists at the intersection. If the traffic control system cannot tell if the cell phones are actually there as revealed in Fig. IB, the parade may be disrupted.
[077] The solution of this technical problem is for the only real bicyclist to equip her mobile device 100 with the disclosed and claimed technology so that as the mobile device 100 is near enough to the site 250, their request is acknowledged, but the far larger parade is handled first. All of the spoofed devices, and their requests, are not acknowledged. So that the parade is not disrupted. [078] Fig. 20 shows the solution to the technical problem discussed regarding Fig. 2A and Fig. 2B. Recall the technical problem involved:
[079] It is an end of shift time for workers, more generally, people on an upper floor in a high-rise building shown in Fig. 2A. A bad actor wants to slow or impede the workers going off-shift through the abuse of cell phones requesting elevator service between lower floors as revealed in Fig. 2B. These fake requests may slow down and impede the going-off-shift workers from leaving the high-rise building. Worse yet, the fake requests could potentially flood the server 300, potentially causing it to malfunction. To avoid this further technical problem, the server 300 needs to remove the fake requests from its pending request queue(s) as shown in Fig. 2B.
[080] Fig. 20 shows the solution of this technical problem, where the real person, equipped with a mobile device 100 can request the elevator, but the other spoofed requests are ignored. As shown and discussed Fig. 12B above, the false service requests are disabled and removed from the server 300.
[081] Fig. 21 shows the solution to the technical problem discussed regarding Fig. 2C and Fig. 2D. Recall the technical problem involved:
[082] Suppose a bad actor operates a mobile device to initiate a fire alert on a lower floor while the (people) on an upper floor are leaving the building as shown in Fig. 2D. This could include impersonation of a mobile device associated with a security person for the building, giving the impression shown in Fig. 2C of an actual fire alert. These disruptive steps could have a large effect on multiple individuals and businesses in and around the building, as well as first responders and other emergency personnel.
[083] The solution to this technical problem is the bad actor controlled mobile device does not have a mobile device 100 as disclosed herein, consequently, as discussed and shown in Fig. 12B, the false service requests are disabled and removed from the server 300.
[084] Fig. 22 shows the solution to the technical problem discussed regarding Fig. 2E and Fig. 2F. Recall the technical problem involved:
[085] The customers of a valet parking facility can request their cars through an application on their mobile devices. Suppose a bad actor impersonates a large number of these customer mobile devices, requesting that their vehicles be made ready for their use, overwhelming the valet service mechanism’s ability to recognize and service the actual customer requests as shown in Fig. 2E. Fig. 2F shows the actual situation, which many fewer requests are being made and the delivered vehicles do not overwhelm the delivery site.
[086] The solution to this technical problem is that only the actually requesting mobile devices 100-00, 100-10 and 100-20, can trigger activation of their requests near the site 250 as shown and discussed above in Fig. 3 to Fig. 12A. As a consequence, only the actually requested vehicles are in the delivery site for these customers, and the delivery site is unlikely to be overwhelmed.

Claims

Claims What is claimed is.
1. An apparatus, comprising:
Aul) a mobile device, a transmitting device located near a site, and a server;
Bui) said mobile device adapted and configured to receive a wireless message containing a token using a short-haul wireless communication protocol from said transmitting device located within a short range of said mobile device;
Cul) said transmitting device adapted and configured to generate said token using a token generator using a first key in said wireless message and to transmit said wireless message via said short-haul wireless communication protocol to said mobile device;
Dul) said mobile device responds to said wireless message by parsing said wireless message to generate said token without wirelessly communicating to said transmitting device;
Eul) said server receives a service request from said mobile device to perform a service at said site;
Ful) said mobile device sends a message to said server including a form of said token to confirm said mobile device is near said site;
Gul) said server responds to said message received from said mobile device by determining if said form of said token proves said mobile device is near said site based upon said first key shared with said transmitting device and said first key is invisible to said mobile device; and
Hul) said server authorizes said service at said site if said form of said token proves said mobile device is within a first distance of said site.
2. The apparatus of Claim 1, wherein said server disables said service request if said form of said token proves said mobile device is not within said first distance of said site.
3. The apparatus of Claim 2, wherein said server disables said service request further comprises said server removes at least one of, said message and said service request, from said server.
4. The apparatus of Claim 1, further comprising:
Au4) wherein said message includes at least part of a mobile time estimate generated by said mobile device; and Bu4) wherein said server generates a server time estimate corresponding to a transmitter time estimate when said transmitting device generated said token.
5. The apparatus of Claim 4, further comprising at least one of:
Au5) wherein said server authorizes said service at said site in response to said server proving said mobile device is within said first distance near said server time estimate based upon said received message;
Bu5) wherein said server disables said service request in response to said server proving said mobile device is not within said first distance near said server time estimate based upon said received message.
6. The apparatus of Claim 1, further comprising at least one of
Au6) wherein said mobile device implements at least one member of a first group consisting of a cellular phone, a wireless client device, a SMS messaging device, a vehicle mounted device and a human mounted device; and
Bu6) wherein said short-haul wireless communication protocol includes at least one version of at least one member of a protocol group consisting of Bluetooth®, Dedicated short- range communications (DSRC), and Cellular V2X (C-V2X).
7. The apparatus of Claim 6, wherein said short-haul wireless communications protocol includes said version of said Bluetooth at no less than version 4[dot]0.
8. The apparatus of Claim 1, further comprising at least one of
Au8) wherein said short range is not more than a member of the group consisting of 10 meters (10 m), 50 m and 100 m; and
Bu8) wherein said second distance is not more than a member of a second group consisting of 1 meter (1 m), 3 m, and 5 m.
9. The apparatus of Claim 1, said first key is shared between said server and said transmitting device using at least one of:
Au9) a Virtual Private Network (VPN) connection and
Bu9) a Diffie Heilman key exchange to generate said first key without said first key being visible on any connection to said mobile device.
10. The apparatus of Claim 1, further comprising:
Avl l) a traffic control system adapted to regulate traffic crossing an intersection as said service at said site between at least two roadways, each adapted for vehicle and/or human traffic across said intersection;
Bvl l) wherein at least some of said vehicles and/or at least some of said humans are equipped said mobile device.
11. The apparatus of Claim 1, further comprising:
Avl2) an elevator providing said service at said site on at least two floors of transferring at least one worker between said floor and said elevator;
Bvl2) wherein at least some of said workers carry said mobile device.
12. The apparatus of Claim 1, further comprising:
Avl3) a fire alarm as said site on each of at least two floors of a building providing said service of issuing a fire alert on said floor in response to a person triggering said fire alarm; Bvl3) wherein said person carries said mobile device.
13. The apparatus of Claim 1, further comprising:
Avl4) a valet parking facility providing said service as delivery of a vehicle for a customer operating said mobile device near said site.
PCT/US2020/047570 2020-01-21 2020-08-24 Apparatus and locale-based method for thwarting deceptions and/or denial of services WO2021150273A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/043,650 US11706583B2 (en) 2020-01-21 2020-08-24 Apparatus and locale-based method for thwarting deceptions and/or denial of services
EP20915164.6A EP4094416A4 (en) 2020-01-21 2020-08-24 Apparatus and locale-based method for thwarting deceptions and/or denial of services
US17/495,680 US11778413B2 (en) 2020-01-21 2021-10-06 Apparatus and locale-based method for thwarting deceptions and/or denial of services
US18/236,885 US20230396951A1 (en) 2020-01-21 2023-08-22 Apparatus and Locale-Based Method for Thwarting Deceptions and/or Denial of Services

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202062963986P 2020-01-21 2020-01-21
US62/963,986 2020-01-21
US16/800,607 US10873859B1 (en) 2019-02-25 2020-02-25 Apparatus and locale-based method for thwarting deceptions and/or denial of services
US16/800,607 2020-02-25

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US16/800,607 Continuation-In-Part US10873859B1 (en) 2019-02-25 2020-02-25 Apparatus and locale-based method for thwarting deceptions and/or denial of services

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US17/043,650 A-371-Of-International US11706583B2 (en) 2020-01-21 2020-08-24 Apparatus and locale-based method for thwarting deceptions and/or denial of services
US17/495,680 Continuation US11778413B2 (en) 2020-01-21 2021-10-06 Apparatus and locale-based method for thwarting deceptions and/or denial of services

Publications (1)

Publication Number Publication Date
WO2021150273A1 true WO2021150273A1 (en) 2021-07-29

Family

ID=76992504

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/047570 WO2021150273A1 (en) 2020-01-21 2020-08-24 Apparatus and locale-based method for thwarting deceptions and/or denial of services

Country Status (1)

Country Link
WO (1) WO2021150273A1 (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017035138A1 (en) * 2015-08-24 2017-03-02 Ayla Networks, Inc. Linked user accounts for an internet-of-things platform
KR20170035294A (en) * 2015-09-22 2017-03-30 삼성전자주식회사 Electronic device and payment method of providing security thereof
EP3208222A1 (en) 2016-02-18 2017-08-23 Otis Elevator Company Anonymous and ephemeral tokens to authenticate elevator calls
US9769664B1 (en) * 2014-09-04 2017-09-19 Sensys Networks Nonce silent and replay resistant encryption and authentication wireless sensor network
US20180338241A1 (en) * 2013-10-04 2018-11-22 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
US20190332787A1 (en) * 2018-04-30 2019-10-31 Fiserv, Inc. Proximity-based user authentication for providing a webpage of an access-controlled application

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180338241A1 (en) * 2013-10-04 2018-11-22 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
US9769664B1 (en) * 2014-09-04 2017-09-19 Sensys Networks Nonce silent and replay resistant encryption and authentication wireless sensor network
WO2017035138A1 (en) * 2015-08-24 2017-03-02 Ayla Networks, Inc. Linked user accounts for an internet-of-things platform
KR20170035294A (en) * 2015-09-22 2017-03-30 삼성전자주식회사 Electronic device and payment method of providing security thereof
EP3208222A1 (en) 2016-02-18 2017-08-23 Otis Elevator Company Anonymous and ephemeral tokens to authenticate elevator calls
US20190332787A1 (en) * 2018-04-30 2019-10-31 Fiserv, Inc. Proximity-based user authentication for providing a webpage of an access-controlled application

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4094416A4

Similar Documents

Publication Publication Date Title
EP3701483B1 (en) Method, apparatus, system, and electronic device for cross-blockchain interaction
Kim et al. Research challenges and security threats to AI-driven 5G virtual emotion applications using autonomous vehicles, drones, and smart devices
Tang et al. Putting people in their place: an anonymous and privacy-sensitive approach to collecting sensed data in location-based applications
EP3482543B1 (en) Observation system
Kolandaisamy et al. A multivariant stream analysis approach to detect and mitigate DDoS attacks in vehicular ad hoc networks
US20220055657A1 (en) System and method to enhance autonomous vehicle operations
WO2007120462A3 (en) Method and system for phone-number discovery and phone-number authentication for mobile communications devices
Zhou et al. Arve: Augmented reality applications in vehicle to edge networks
Baig Multi-agent systems for protecting critical infrastructures: A survey
US11037450B2 (en) Using geofences to restrict vehicle operation
WO2019052022A1 (en) Alarm processing method, alarm platform, and storage medium
Maskey et al. Alicia: Applied intelligence in blockchain based vanet: Accident validation as a case study
Bhargava et al. A Systematic Approach for Attack Analysis and Mitigation in V2V Networks.
US11778413B2 (en) Apparatus and locale-based method for thwarting deceptions and/or denial of services
JP6233041B2 (en) Wireless communication apparatus and wireless communication method
US10873859B1 (en) Apparatus and locale-based method for thwarting deceptions and/or denial of services
WO2021150273A1 (en) Apparatus and locale-based method for thwarting deceptions and/or denial of services
EP4094416A1 (en) Apparatus and locale-based method for thwarting deceptions and/or denial of services
US20230161651A1 (en) Application programming interface security
Kiran et al. Cyber security and risk analysis on connected autonomous vehicles
Bharat et al. Authentication solution for security attacks in VANETs
Agarwal et al. Forecasting-based Authentication Schemes for Network Resource Management in Vehicular Communication Network
Ayoob et al. Intrusion detection system classifier for VANET based on pre-processing feature extraction
Houmer et al. A hybrid intrusion detection system against egoistic and malicious nodes in VANET
CN115623471B (en) Trust management method and device for privacy protection of vehicle-mounted network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20915164

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020915164

Country of ref document: EP

Effective date: 20220822