U.S. patent application number 15/803187 was filed with the patent office on 2018-09-20 for wireless device detection, tracking, and authentication platform and techniques.
The applicant listed for this patent is SCRRD, Inc.. Invention is credited to Joshua Cohen, Lucas Thoresen.
Application Number | 20180270608 15/803187 |
Document ID | / |
Family ID | 63519817 |
Filed Date | 2018-09-20 |
United States Patent
Application |
20180270608 |
Kind Code |
A1 |
Thoresen; Lucas ; et
al. |
September 20, 2018 |
Wireless Device Detection, Tracking, and Authentication Platform
and Techniques
Abstract
Methods, systems, and techniques for wireless device detection,
information, tracking, and authentication within a platform are
provided. Example embodiments provide a Wireless Device Detection,
Tracking, and Authentication System and methods, which enables
users to detect wireless devices, obtain stored information about
wireless devices, and authenticate wireless devices for a variety
of purposes including determining similarity of devices based upon
prior network connections, pinpointing the location of the device,
verifying the cryptographic signature of the device, obtaining
metadata associated with the device, and controlling the device to
perform a particular action such as alerts and notifications. An
example WDDTAS platform includes a server, one or more edge sensors
communicatively connected to wireless/wired devices with or without
software to configure the device to perform as an electronic tag
and connected to electronic smart tags, and a persistent data
repository.
Inventors: |
Thoresen; Lucas;
(Minneapolis, MN) ; Cohen; Joshua; (Seattle,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SCRRD, Inc. |
Seattle |
WA |
US |
|
|
Family ID: |
63519817 |
Appl. No.: |
15/803187 |
Filed: |
November 3, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15599436 |
May 18, 2017 |
9900742 |
|
|
15803187 |
|
|
|
|
62473172 |
Mar 17, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 4/029 20180201;
H04L 67/18 20130101; H04W 4/021 20130101; H04W 84/12 20130101; H04W
84/18 20130101; H04L 67/16 20130101; G01S 13/74 20130101; G01S 5/14
20130101; G01S 5/0294 20130101; H04L 67/12 20130101; H04W 4/38
20180201; H04W 8/005 20130101; H04W 12/06 20130101; H04W 4/023
20130101; H04W 8/22 20130101 |
International
Class: |
H04W 4/02 20060101
H04W004/02; H04W 8/00 20060101 H04W008/00; H04W 12/06 20060101
H04W012/06; G01S 5/02 20060101 G01S005/02 |
Claims
1. A wireless device detection and tracking system comprising: a
sensor device comprising at least one wireless network interface
controller (NIC) configured to passively monitor wireless network
traffic from one or more wireless devices; code to, upon the NIC
receiving at least one first request for a possible connection to
at least one previously connected network from a monitored wireless
device of the one or more wireless devices through passive
monitoring and while the sensor device is at a first location,
generate first data describing the at least one first request; code
to, upon the NIC receiving at least one second request for a
possible connection to at least one previously connected network
from a monitored wireless device of the one or more wireless
devices through passive monitoring and while the sensor device is
at a second location, generate second data describing the at least
one second request; and code to determine a location of the
monitored wireless device using trilateration techniques based on
the first data describing the at least one first request and the
second data describing the at least one second request.
2. The system of claim 1, wherein the sensor device is in or on a
land based vehicle, an aerial vehicle, or a water borne vehicle
that moves from the first location to the second location.
3. The system of claim 1, further comprising: code to determine
whether the location of the monitored wireless device is within a
target geofenced zone; and code to cause a location based event to
occur based on whether the location of the monitored wireless
device is within the geofenced zone.
4. The system of claim 3, wherein the target geofenced zone is a
dynamic geofenced zone that follows a location of the sensor
device.
5. The system of claim 1, further comprising: code to generate a
similarity metric by comparing the first data describing the at
least one first request or the second data describing the at least
one first request to a stored wireless device profile; and code to
cause a location based event to occur based on the similarity
metric and the location of the monitored wireless device.
6. The system of claim 5, wherein the first data or the second data
includes a history of wireless networks the monitored wireless
device has previously connected to, and the similarity metric is
generated by comparing the history of wireless networks to wireless
networks of the stored wireless device profile.
7. The system of claim 1, further comprising: code to cause a
location based event to occur based the location of the monitored
wireless device.
8. The system of claim 1, wherein the at least one first request
for the possible connection to at least one previously connected
network from a monitored wireless device includes an 802.11 Probe
Request delivered as a 802.11 Management Frame.
9. The system of claim 1, further comprising: code to, upon the NIC
receiving at least one second request for a possible connection to
at least one previously connected network from a monitored wireless
device of the one or more wireless devices through passive
monitoring and while the sensor device is at a third location,
generate third data describing the at least one third request,
wherein the location of the monitored wireless device is determined
using trilateration techniques further based on the third data
describing the at least one third request.
10. A non-transitory computer readable medium containing
instructions for controlling a computer processor to detect and
track wireless devices by performing a method comprising:
generating first data at a sensor device, the first data describing
at least one first request for a possible connection to at least
one previously connected network from a monitored wireless device
that is passively monitored by the sensor device, the sensor device
receiving the at least one first request while the sensor device is
at a first location; generating second data at the sensor device,
the second data describing at least one second request for a
possible connection to at least one previously connected network
from the monitored wireless device that is passively monitored by
the sensor device, the sensor device receiving the at least one
second request while the sensor device is at a second location; and
determining a location of the monitored wireless device using
trilateration techniques based on the first data describing the at
least one first request and the second data describing the at least
one second request.
11. The non-transitory computer readable medium of claim 10,
wherein the sensor device is in or on a land based vehicle, an
aerial vehicle, or a water borne vehicle that moves from the first
location to the second location.
12. The non-transitory computer readable medium of claim 10, the
method further comprising: determining whether the location of the
monitored wireless device is within a target geofenced zone; and
causing a location based event to occur based on whether the
location of the monitored wireless device is within the geofenced
zone.
13. The non-transitory computer readable medium of claim 10, the
method further comprising: generating a similarity metric by
comparing the first data describing the at least one first request
or the second data describing the at least one first request to a
stored wireless device profile; and causing a location based event
to occur based on the similarity metric and the location of the
monitored wireless device.
14. The non-transitory computer readable medium of claim 13,
wherein the data describing the at least one request includes a
history of wireless networks the monitored wireless has previously
connected to, and the similarity metric is generated by comparing
the history of wireless networks to wireless networks of the stored
wireless device profile.
15. The non-transitory computer readable medium of claim 10, the
method further comprising: causing a location based event to occur
based the location of the monitored wireless device.
16. A method to detect and track wireless devices by performing a
method comprising: generating first data at a sensor device, the
first data describing at least one first request for a possible
connection to at least one previously connected network from a
monitored wireless device that is passively monitored by the sensor
device, the sensor device receiving the at least one first request
while the sensor device is at a first location; generating second
data at the sensor device, the second data describing at least one
second request for a possible connection to at least one previously
connected network from the monitored wireless device that is
passively monitored by the sensor device, the sensor device
receiving the at least one second request while the sensor device
is at a second location; and determining a location of the
monitored wireless device using trilateration techniques based on
the first data describing the at least one first request and the
second data describing the at least one second request.
17. The method of claim 16, wherein the sensor device is in or on a
land based vehicle, an aerial vehicle, or a water borne vehicle
that moves from the first location to the second location.
18. The method of claim 16, further comprising: determining whether
the location of the monitored wireless device is within a target
geofenced zone; and causing a location based event to occur based
on whether the location of the monitored wireless device is within
the geofenced zone.
19. The method of claim 16, further comprising: generating a
similarity metric by comparing the first data describing the at
least one first request or the second data describing the at least
one first request to a stored wireless device profile; and causing
a location based event to occur based on the similarity metric and
the location of the monitored wireless device.
20. The method of claim 19, wherein the first data or the second
data includes a history of wireless networks the monitored wireless
has previously connected to, and the similarity metric is generated
by comparing the history of wireless networks to wireless networks
of the stored wireless device profile.
21. The method of claim 16, further comprising: causing a location
based event to occur based the location of the monitored wireless
device.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation in part of U.S. patent
application Ser. No. 15/599,436, filed on May 18, 2017, which
claims the benefit of U.S. Provisional Patent Application No.
62/473,172, entitled "WIRELESS DEVICE DETECTION, TRACKING, AND
AUTHENTICATION PLATFORM AND METHODS," filed Mar. 17, 2017; all of
which are incorporated herein by reference in their entirety.
TECHNICAL FIELD
[0002] The present disclosure relates to methods, techniques, and
systems for detection, tracking, and authentication of wireless
devices and, in particular, to methods, techniques, and systems for
passively detecting, locating, authenticating, and storing
information relating to wireless devices useful, for example, in
security systems, financial transactions, Internet-Of-Things (IOT)
Networking, inventory tracking, advertising and the like.
BACKGROUND
[0003] With the proliferation of wireless devices, especially those
accessible via one or more networks, it has become essential be
able to locate and identify such devices for a variety of purposes.
One such categorization of purposes has been devices that
contribute to a concept known as the "Internet-Of-Things" (IOT).
IOT brings with it the idea that physical objects, such as devices,
vehicles, buildings, and other devices, that are embedded with
electronics, software, sensors, and network connectivity that
enables these objects to collect and exchange data, can cooperate
as a whole to enable an intelligent infrastructure. IOT allows
objects to be sensed and/or controlled remotely across existing
network infrastructure, creating opportunities for more direct
integration of the physical world into computer-based systems, and
resulting in improved efficiency, accuracy and economic benefit in
addition to reduced human intervention.
[0004] Traditionally, the addressability of such devices has been
based upon things like RFID-tags and identification through
(electronically scan able) product codes, IP addresses and the
like, which in some cases can be associated with a particular
location. Locations of devices may also be determined for example
using satellite based technologies, e.g., GPS, which may be
independent of internet access. However, GPS technologies are
currently limited to accurately locating a device within about 4.9
meters, which in some instances does not give a sufficient pinpoint
location. See Diggelen et. al, Proceedings of the 28.sup.th Int'l
Technical Meeting of The Satellite Division of the Institute of
Navigation, Sep. 14-18, 2015, Tampa, Fla., Abstract. In addition,
signals to satellites can be blocked such as by buildings, walls,
etc. which limit the effectiveness of using GPS technologies to
pinpoint locations within and near buildings. Elevation is also
difficult to determine using GPS technologies.
[0005] Locations of devices may also be determined using cellular
phone (cellphone) networks using the Global System for Mobile
Communications (GSM) such as 2G, 3G, and 4G networks. Again, the
precision of such determinations are limited by the density of cell
towers (base stations) located in the area as well as the power of
the signals from the cellphones. Typical precision is on the order
of 50-100 meters in dense urban areas and may be much worse in
rural areas where cell towers are more sparse. See Ibrahim et al.,
"CellSense: An Accurate Energy-Efficient GSM Positioning System,"
IEEE Trans on Vehicular Technology, Vol. 61, No. 1, pp 286-296,
2011. Several different technologies may be used including handset
based (the cellphone measures its signal strength to one or more
cell tower antennas) or network based methods such as comparing the
relative signal strength of the cellphone when the phone is roamed
from one tower to the next. In addition, some systems use SIM base
measurements or combine GPS (or other Global Navigation Satellite
System (GNSS)) technology with network information from a GSM
system. See Wikipedia, Mobile Phone Tracking.
[0006] In addition, RFID tags or other technology 1-way
transmitters, such as iBeacon or Beacon technology have been used
to provide applications running on wireless devices such as
cellphones with broadcasted tag information so that the cellphones
can determine their own locations by determining their rough
proximity to these tags using signal strength. The beacons
(whichever technology is employed) are placed at known locations
and calibrated in order for the applications on the phones to
determine proximity. See ibeaconinsider, "What is iBeacon? A Guide
to Beacons,"
http://www.ibeacon.com/what-is-ibeacon-a-guide-to-beacons, 1995.
Beacon technology can be used as an indoor positioning system,
unlike GPS technology. Beacon technology can range from 70 meters
to up to 450 meters.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is an example block diagram of components of a
Wireless Device Detection, Tracking, and Authentication System (a
WDDTAS) that illustrates an exemplary sensor installation.
[0008] FIG. 2 depicts the path cost analysis used to determine the
most efficient way to relay data to where the data is needed within
a Wireless Device Detection, Tracking, and Authentication
System.
[0009] FIG. 3 is an example block diagram of components of an edge
sensor in an example embodiment of a Wireless Device Detection,
Tracking, and Authentication System.
[0010] FIG. 4 is an example overview flow diagram of the logic for
capturing and reporting wireless station metadata using an example
edge sensor component of an example embodiment of a Wireless Device
Detection, Tracking, and Authentication System.
[0011] FIG. 5 is an example flow diagram of the monitoring logic of
an example edge sensor component of an example embodiment of a
Wireless Device Detection, Tracking, and Authentication System.
[0012] FIG. 6A is an example block diagram of Management Frame and
a Probe Request according to the 802.11 Specification.
[0013] FIGS. 6B and 6C illustrates an example capture of data from
a Probe Request of a wireless station containing metadata
applicable to an example Wireless Device Detection, Tracking, and
Authentication System.
[0014] FIG. 7 is an example flow diagram of the reporting logic of
an example edge sensor component of an example embodiment of a
Wireless Device Detection, Tracking, and Authentication System.
[0015] FIGS. 8A and 8B are examples of serialized data from a Probe
Request of a wireless station containing metadata to be reported by
an edge sensor to a server.
[0016] FIG. 9 is an example block diagram of logic components of an
example server in an exemplary Wireless Device Detection, Tracking,
and Authentication System installation.
[0017] FIG. 10 is an example flow diagram of tracking logic
executed on an example server in an example embodiment of a
Wireless Device Detection, Tracking, and Authentication System.
[0018] FIG. 10A is another example flow diagram of code executed on
an example server in an example embodiment of a wireless device
detection, tracking and authentication system.
[0019] FIGS. 11A-11E are example diagrams illustrating
trilateration and other techniques to find a location of a wireless
station using one, two, and three edge sensors or other known
locations.
[0020] FIG. 12 is an example block diagram of logic components of
an example client application for execution on a wireless station
in an example embodiment of a Wireless Device Detection, Tracking,
and Authentication System.
[0021] FIG. 13 is an example block diagram of logic components of
an example administrative application for management of an
exemplary Wireless Device Detection, Tracking, and Authentication
System installation.
[0022] FIG. 14 is an example block diagram of a computing system
for practicing embodiments of a Wireless Device Detection,
Tracking, and Authentication System.
[0023] FIG. 15 illustrates dynamic geofencing using moving edge
sensors according to an embodiment.
[0024] FIG. 16A illustrates a technique for finding a location of a
wireless device using a single moving edge sensor.
[0025] FIG. 16B illustrates a process for finding a location of a
wireless device using a single moving edge sensor.
[0026] FIG. 17 illustrates a system for payment processing,
according to an embodiment.
[0027] FIG. 18 illustrates a system for providing security,
according to an embodiment.
DETAILED DESCRIPTION
[0028] Embodiments described herein provide enhanced computer- and
network-based methods, techniques, and systems for detecting,
tracking, and authenticating wireless devices. Example embodiments
provide a Wireless Device Detection, Tracking, and Authentication
System ("WDDTAS") and methods, which enables users to detect
wireless devices, obtain stored information about wireless devices,
and authenticate wireless devices for a variety of purposes
including, for example: [0029] pinpointing the location of the
device whether outside or inside [0030] verifying the cryptographic
signature of the device [0031] obtaining metadata associated with
the device for many purposes [0032] controlling the device to
perform a particular action for example purchasing or other
transaction [0033] comparing expected device location with actual
location [0034] facilitating the device verifying the identity of
its user with a biometric or secret in addition to locating the
device
[0035] The Wireless Device Detection, Tracking, and Authentication
System, techniques, and methods (referred to as well as the WDDTAS)
allow for the tracking of WiFi or Bluetooth or other types of
wireless enabled devices without requiring those devices to run an
application, opt-in to being discoverable or tracked, without
requiring use of a GPS (or other GNSS technology), without
requiring connection to a GSM network such as 2G, 3G, 4G, and the
like, and without using a SIM card, without scanning a QR code, and
without requiring a user to engage in or initiate any interaction
with the WDDTAS system. Accordingly, the WDDTAS enables locating,
tracking, and identification of wireless devices using a passive
approach. In other embodiments, the WDDTAS may enable locating,
tracking, and identification of wireless devices using an active
approach.
[0036] It also provides multiple points of identity for those
devices that are not running an application by comparing each
device's wireless connection history and device capabilities
(factors, aspects, characteristics, and the like) in order to build
a device profile for each device. In certain scenarios, the device
profile may identify the device or the user by anonymizing the
information, thus allowing compliance with privacy laws in certain
countries and with certain organizations (such as HIIPA, the Health
Insurance Portability and Accountability Act of 1996). For example,
the system might sense multiple devices owned by two people who
have met at a particular location, (e.g. a WiFi Cafe) and can flag
those devices as related because the location is one-hop away from
either device. The owner of this system could set an alert when
anyone who has previously connected to a particular wireless
network enters the area.
[0037] Example Wireless Device Detection, Tracking, and
Authentication Systems and methods can also operate with devices
that are executing a WDDTAS client application in order to provide
enhanced operation such as turning such devices into electronic
tags, providing additional support for retail and other
transactions, and the like.
[0038] Example Wireless Device Detection, Tracking, and
Authentication Systems provide a sensor platform of "edge sensors"
that allows for the collection, storage, analysis, and sharing of
wireless signals intelligence. This includes pinpointing and
verifying the signatures of mobile wireless devices by collecting
the actual wireless frames (e.g., 802.11 and Bluetooth) that these
devices emit. Inter-networked edge sensors pass the information
between one another in order to distribute the information to a
desired destination such as the server to be stored or to another
inter-networked device. Important metadata and computed
information, such as location or cryptographic signature, are
persisted within the WDDTAS to be used for tracking and
authentication. In some example WDDTASs, derived information such
as using machine learning tools can be used for other activities or
events.
[0039] Many different kinds of users may interact with the system
having diverse needs, and thus, collected data is managed within a
domain consisting of users, groups, and remote access endpoints
(through an Application Programming Interface--"API"). By arranging
the sensor platform within or around an area, an operator of the
system can use the installation to accomplish any number of tasks
involving authentication and/or locating of devices within that
area.
[0040] For example, some entities may be interested in this system
for operational security, that is, to place sensors all around
their property and configure the system to generate alerts when
unknown devices are approaching the area. Mobile devices are now
prevalent and it makes sense to target these devices for
authentication, advertising, surveillance, and to provide many
types of service to them.
[0041] FIG. 1 is an example block diagram of components of a
Wireless Device Detection, Tracking, and Authentication System (a
WDDTAS) that illustrates an exemplary sensor installation. In one
example embodiment, the WDDTAS installation (or topology) comprises
one or more functional components/modules that work together to
provide detection (including locating), tracking, and
authentication of wireless devices. Wireless Device Detection,
Tracking, and Authentication System 100 comprises an edge sensor
platform of one or more edge sensors, e.g., edge sensors 110a-b and
111a-b, one or more servers such as server 120, one or more data
repositories such as repositories 130 and 131, and one or more
administrative applications such as application 140. In addition,
remote endpoints into the system via API (not shown) are accessible
to clients (client applications) that desire to obtain data from
the system, push information to wireless devices detected by the
system, and the like. A WDDTAS installation may not be fixed--it
may migrate based upon various parameters and the area it covers
may not be defined by fixed coordinates such as within a building
or area. For example, when the sensors are in or attached to moving
objects, they can define a dynamic geolocation zone for the
detection of wireless devices.
[0042] The edge sensors, e.g., edge sensors 110a-b and 111a-b, may
be sensor devices responsible for monitoring wireless devices
connected to the WDDTAS platform and reporting data to the servers
(e.g., server 120) to be processed and potentially persisted to the
one or more data repositories. The edge sensors may also
communicate with each other. When working with WiFi (802.11
protocol), each edge sensor is set to monitor mode to monitor
traffic and obtain information from wireless devices within the
detectable vicinity of the edge sensor. These wireless devices are
referred to under the 802.11 Specification as stations (or STA).
Some of these devices may have a WDDTAS client application
installed and others may not. For example, edge sensor 110a, a
laptop, may monitor wireless frame information from stations
102-105, which do not have the WDDTAS client application installed
or executing. Similarly edge sensor 111a, a WDDTAS hardware network
device, may be communicatively connected to edge sensor 111b
(another WDDTAS hardware network device) and may monitor
information from wireless stations 101 and 108. As shown, station
101 is not running the WDDTAS application, yet station 108 is (and
show bidirectional communication). Edge sensor 111b may be
communicatively connected to edge sensor 111a and may monitor
traffic from wireless station 109 running the WDDTAS client
application. Edge sensor 110b may monitor information from stations
106 and 107, both running the WDDTAS client application. Edge
sensor functions are described further with respect to FIGS.
3-8B.
[0043] In at least one embodiment, the edge sensors may be located
near the edge of a network topology while the server 120 represents
the center of that network topology. In at least one embodiment,
the edge sensor locations roughly determine the edge boundaries of
geofenced zones. For example, the edge sensors may be located
exactly on or near the corners of geofenced zones.
[0044] In other example WDDTAS installations (not shown), edge
sensors may monitor traffic according to other wireless protocols
such as Bluetooth (BT). The examples described with reference to
WiFi (802.11) are relevant to BT although different mechanisms for
monitoring traffic and the layout of the information varies.
[0045] The edge sensors communicate (e.g., report, transfer,
forward, send, etc.) data to the one or more servers that are part
of a WDDTAS installation. For example, server 120 is
communicatively connected to edge sensors 111a-b and 110a-b via
wired or wireless connections. The server 120 may be also
communicatively connected via wired or wireless connections,
directly or indirectly, to one or more data repositories, such as
repositories 130 and 131. In some installations, the server 120 may
be communicatively connected through a network, such as internet
150, to one or more data repositories. The one or more servers,
such as server 120, is responsible for caching or storing the data
reported by the edge sensors, providing security support for
receiving the reported data and for interacting with other clients
to the WDDTAS, post processing of the reported station metadata to
determine information such as a profile of device, API support for
remote endpoints into WDDTAS installation, and event management
including location based (e.g., surveillance) and non-location
based (e.g., retail and payment transaction support). WDDTAS server
functions are described further with respect to FIGS. 9-10.
[0046] In example WDDTAS installations, one or more administrative
management applications, such as administrative management
application 140, are communicatively connected to the one or more
servers (directly or via a network such as network 150) in order to
control various aspects of the edge sensors such as configuration
and maintenance, access to them and the data, and the like. For
example, WDDTAS administrative application may manage the uploading
and access to floor plans for aiding in user interfaces that show
or track the location of wireless stations precisely. In addition,
they provide support for defining and managing geofencing zones,
event and notification support to other applications, report
generation, and the like. WDDTAS administrative application
functions are described further with respect to FIG. 13.
[0047] The data repositories, such as repositories 130 and 131,
accessed by the one or more servers may comprise any form for
storing data persistently or temporarily depending upon the use of
the WDDTAS. For example, they may be databases, files, file
servers, etc. stored in memory. The data stored in the data
repositories 130 and 131 can be made accessible to third parties
through an API, and access managed by an WDDTAS administrative
management application such as application 140. The data
repositories may store device profiles for many wireless devices.
Each device profile is associated with a specific wireless devices
and may include information previously captured from probe requests
of the wireless device. The device profile can include, for
example, a history of wireless networks (e.g. in the form of SSID's
and other information), MAC address, and capabilities for a
specific device. In some embodiments, the device profile can
include information captured from management frames other than
probe requests.
[0048] As mentioned, a WDDTAS installation may not be fixed and may
provide dynamic geofencing. In addition, edge sensors, such as edge
sensors 110a-b and 111a-b may sometimes go offline or become
unavailable for other reasons such as when wireless devices move
out of range of one another. Generally, the edge sensors of a
WDDTAS installation route and report information via the shortest
channel to the intended destination. FIG. 2 depicts the path cost
analysis used to determine the most efficient way to relay data to
where the data is needed within a Wireless Device Detection,
Tracking, and Authentication System. Known path cost analysis (for
example using a routing metric or "link cost") may be incorporated
to determine, for example, the least costly path based for example
on the speed of the connection (cost may refer to time). For
example, in FIG. 2, the cost of sending data from edge sensor 202a
to edge sensor 202e via edge sensor 202d (a first path) is "10"
whereas the cost of sending the same data via edge sensors 202b and
202c (a second path) is "3"+"1"+"3"="16" which is greater. (Here
the numbers refer to a measurement used by the path cost analysis
algorithm.) Thus, the WDDTAS installation would prefer to send the
data via the first path. Other example WDDTAS installations may
prefer in some instances to use the high path cost.
[0049] Although the examples described herein often refer to a
mobile device, the techniques described herein can also be used by
to track, locate, identify, and authenticate any type of wireless
device including mobile and non-mobile devices, such as desktops,
embedded wireless systems, wireless SOC devices, and the like.
Essentially, the concepts and techniques described are applicable
to any wireless environment where locating, tracking,
authenticating, and or event processing can be used.
[0050] Although certain terms are used primarily herein, other
terms could be used interchangeably to yield equivalent embodiments
and examples. In addition, terms may have alternate spellings which
may or may not be explicitly mentioned, and all such variations of
terms are intended to be included.
[0051] Example embodiments described herein provide applications,
tools, data structures and other support to implement a Wireless
Device Detection, Tracking, and Authentication System and methods
to be used to detect wireless devices, obtain stored information
about wireless devices, and authenticate wireless devices for a
variety of purposes. Other embodiments of the described techniques
may be used for other purposes. In the following description,
numerous specific details are set forth, such as data formats and
code sequences, etc., in order to provide a thorough understanding
of the described techniques. The embodiments and examples described
also can be practiced without some of the specific details
described herein, or with other specific details, such as changes
with respect to the ordering of the logic, different logic, etc.
Thus, the scope of the techniques and/or functions described is not
limited by the particular order, selection, or decomposition of
aspects described with reference to any particular routine, module,
component, and the like.
[0052] As described above with reference to FIG. 1, WDDTAS edge
sensors (passively) monitor traffic from wireless devices and
communicate with other edge sensors, WDDTAS servers, wireless
devices programmed to interact with edge sensors, or electronic
tags (including wireless devices programmed to operate as
electronic tags).
[0053] FIG. 3 is an example block diagram of components of an edge
sensor in an example embodiment of a Wireless Device Detection,
Tracking, and Authentication System. For example, edge sensor 300
depicted therein may be one of the edge sensors 111a or 111b of
FIG. 1. The components displayed may be present in a general or
special purpose computer such as that described with reference to
FIG. 14 and thus other components not shown (such as other
input/output, I/O, devices) may be present in edge sensor 300.
[0054] Edge sensors are typically transceiver-bearing wireless
computers. Transceivers comprise hardware that allows for
unidirectional, bidirectional, or full-duplex communication over a
wire (wired), or over the air (wireless). For example, edge sensor
300 illustrated comprises one or more wireless antennas 301a and
301b, network interface cards (or adapters) 304 and 305, other I/O
cards or modules 306, battery 302 or other AC power source, a
wireless network controller 307 (if not part of the NIC), a
Bluetooth (BT) chipset/controller 308, (optionally) an Ethernet
(wired network) port 309, and storage/memory 310. In any particular
edge sensor implementation, one or more of these components may not
be present. For example, if the edge sensor 300 only supports the
monitoring of WiFi frames, then support for BT may not be present.
Similarly, if the edge sensor 300 is only wirelessly connected to
other edge sensors or servers, then a wired network port (such as
Ethernet port 309) may not be present. In addition, in some
example, edge sensor 300 comprises GPS hardware (not shown).
[0055] In one example edge sensor 300, the memory 310 is flash
memory containing code logic for monitoring and reporting WiFi
traffic, such as in monitoring processing module 311 and reporting
processing module 312, an operating system 313 such as a Linux
derivative, and potentially other processing modules 314. The edge
sensor 300 monitors traffic from various wireless stations within
range to collect metadata and reports or relays the metadata via
the available communications hardware (the wired and/or wireless
transceivers) to various other components of the WDDTAS such as
server 120 or the other edge sensors of FIG. 1. The metadata may
include various information about data, devices, communications,
sessions, and identify other information that is not part of the
raw unprocessed signals themselves. For example, metadata may
include a collection of past networks to which the device has
previously connected, data rates, etc. In some embodiments, the
edge sensor 300 may compute device similarity metrics that are
provided to other devices.
[0056] Signals emitted by wireless stations near or in proximity to
each edge sensor may be pre-processed by the edge sensor as they
are captured. For example, in edge sensor 300 they may be
pre-processed by monitoring processing module 311, which contains
code logic (in software, hardware, or firmware) to enumerate the
underlying protocol (e.g., the IEEE 802.11 protocol, which defines
how wireless devices communicate) in order to extract relevant
information from each frame. As an example, the underlying protocol
may indicate that an 802.11 Probe Request was generated and the
edge sensor can filter out other frames and relay only relevant
data from the Probe Request. Additionally, according to 802.11 the
Probe Request is a management frame that stores data in a
particular sequence so the edge sensor can preprocess the frame to
store only the metadata of interest. This strategy can make optimal
use of network bandwidth and can act as a filter for irrelevant
information before being passed onto another edge sensor or the
server. In some example edge sensors, the code logic that performs
such preprocessing is external to the edge sensor (e.g., running as
an application on the edge sensor computer system) or embedded on a
dedicated device used as an edge sensor
[0057] In some example edge sensors and WDDTAS platforms,
additional processing of the metadata make take place. For example,
the edge sensor 300 may contain some machine learning or
statistical logic as other processing modules 314 to post process
some of the data if the location of the wireless station is to be
pinpointed by the edge sensor. In other examples, this type of post
processing is performed by a server or at some other location so as
to minimize power consumption of the edge sensors. As another
example, edge sensor 300 may include a command interface as part of
other processing modules 314 that allows another entity such as a
server to direct the edge sensor to perform a task. For example,
the server may detect that a user's device has entered a "payment
zone" that a retailer has designated (using the server's location
processing). The server can then issue a command to the edge sensor
to initiate a payment process on the user's device (assuming the
device is running an application allowing the edge sensor to
communicate with it).
[0058] One of the primary functions of an edge sensor is to monitor
(wireless) traffic and report information (metadata or other
information) to other destinations of the WDDTAS. FIG. 4 is an
example overview flow diagram of the logic for capturing and
reporting wireless station metadata using an example edge sensor
component of an example embodiment of a Wireless Device Detection,
Tracking, and Authentication System. Edge Sensor logic 400 begins
in block 401 when the sensor boots and a WDDTAS daemon process (in
the background and continuous) begins. In block 402, the logic
enumerates the network interfaces available (e.g., Ethernet, WLAN,
and BT) using, for example, an operating system API and determines
which is the NIC to be used for monitoring and which for reporting.
In some instances these are separate NICs, but in others they are
not. In block 403, the logic begins execution of a monitor thread
to monitor traffic from the wireless signals (from, for example,
802.11 WiFi and BT bands). This thread is described further with
respect to FIG. 5. In block 404, the logic begins execution of a
reporting thread to report monitored data, for example to a server
or other computing device. In logic blocks 405 to 406, the edge
sensor performs other processing as needed until it is terminated
(for example turned off).
[0059] As described, the edge sensors based upon their placement
(relative or absolute, dynamic or fixed) in the installation define
a target area or zone. Each edge sensor is placed around the target
area, and constantly monitoring for and collecting wireless signals
on the 802.11 WiFi and Bluetooth bands. FIG. 5 is an example flow
diagram of the monitoring logic of an example edge sensor component
of an example embodiment of a Wireless Device Detection, Tracking,
and Authentication System. The monitoring thread 500 is responsible
for continuously collecting signals over the wireless networks--the
802.11 WiFi and BT bands.
[0060] In block 501, the logic places the determined monitor NIC
into wireless monitor mode. Monitoring of 802.11 management frame
traffic is performed by placing the edge sensor in "monitor" mode
(for example using Linux' "iwconfig" command) and picking
up/filtering for Probe Request management frames. In particular,
while in monitor mode, the edge sensor passively listens for
traffic and does not respond to a Probe Request with a Probe
Response so as not to begin a connection to the noticed station
(which requires authentication and association in addition to this
handshake). In addition, the edge sensor does not send out 802.11
Beacons (Beacon management frames) to let stations know of its
availability. The monitored traffic will contain a copious amount
of data and the edge sensor may preprocess the data to only
consider Probe Requests. In other embodiments, the monitoring
thread 500 can place the NIC into other modes for passively
monitoring 802.11 frame traffic such as a listening mode or a
promiscuous mode.
[0061] In block 502, the edge sensor logic changes channels
(listens to different frequencies) in various intervals, for
example 500-1500 ms intervals, searching for Probe Requests from
stations in its vicinity (and within the target zone). When these
Probe Requests are received, then in block 503 the various header
details of the Probe Request Management Frame and other relevant
data or metadata are captured into data structures stored in the
memory of the edge sensor. The metadata is intended to form a
bigger picture of the surveyed area--that is data about the data
being collected by the target zone or from an aggregate of a group
of edge sensors (or the whole WDDATS installation). In block 504,
the edge sensor logic may perform preprocessing on the collected
data to generate metadata which is then stored in block 505. The
logic then continues back to look for more Probe Requests in block
502. Of note, the preprocessing may be performed in a separate
thread once the Probe Request data is extracted. The data captured
in the data structures (including the extracted data and metadata)
generally describe the received probe requests, and may be referred
to herein as "probe request data." The probe request data can
include for example MAC Address of a wireless device, channel
number, Wifi standard type (a/b/g/n/ac), SSID (e.g. network name),
SSID length, supported link speeds, supported ciphers and
cryptographic capabilities, high throughput capabilities (HT),
aggregation support (ampdu), vendor specific capabilities,
timestamp for when the probe request was received, and signal
strength.
[0062] The 802.11 wireless network frames (or other network
equivalent) issued by wireless stations within a target zone reveal
MAC address, signal level, noise ratio, vendor info, network name,
past wireless networks, and other information. This information is
then used to compute additional details (e.g., on the server, other
computing devices, or in an edge sensor), such as device vendor
similarity metrics, device location similarity metrics, and/or a
collection of past networks. Through the collection process, and
based on the signal strengths detected at each edge sensor, and any
known obstacles between the sensor and the targeted device, the
device locations are also determined.
[0063] As noted, as part of desired metadata, the edge sensor
accumulates a history of the wireless networks to which the station
has previously connected. According to the 802.11 wireless
specification (RFC) as designated by EIFT/IEEE, wireless stations
(phones, laptops, smart television, refrigerator, and other TOT
devices, etc.) that are not currently connected to the network will
periodically scan for networks in the area, and in-particular issue
802.11 Probe Requests in an attempt to find and connect to known
wireless networks. Thus, a sequence of Probe Requests from the same
station (in a small burst of time) will reveal each of the networks
that the station is scanning for. The edge sensor logic can extract
this information from the Probe Request management frames and
populate a data structure with a history of previous wireless
connections as well as other information that can lead to metadata
that can be used to profile the device. For example, if it is known
that a particular device frequents location 1 followed by location
2 at the same time every Sunday, then a device location profile can
be established.
[0064] FIG. 6A is an example block diagram of Management Frame and
a Probe Request according to the 802.11 Specification. Management
Frame 601 contains a MAC header, which indicates the address of the
station sending the frame (field "SA" for source address,
transmitter address "TA" may be the same) and a Frame Body which,
for a management frame, contains both fixed and variable length
field. Probe Request 602 is one type of management frame. This
request includes as field "SSID" (Service Set Identity field) a
desired network that the station is scanning for. Other fields in
the frame body contain information such as supported rates,
extended supported rates, frequency hopping information, etc.
Additional information regarding the specifics of the 802.11
protocol, management frames, and probe requests in particular is
detailed in Gast, 802.11 Wireless Networks, The Definitive Guide,
O'Reilly, 2d ed., 2005, which herein incorporated by reference in
its entirety.
[0065] FIGS. 6B and 6C illustrates an example capture of data from
a Probe Request of a wireless station containing metadata
applicable to an example Wireless Device Detection, Tracking, and
Authentication System. The data has been captured through a
wireless data capture analysis tool (Wireshark). In this example
screen, line number 38 contains information regarding a Probe
Request picked up from a station named "LgElectr_ad" with a MAC
address of "34:fc:ef:ad:2e:75." Although not the case for all Probe
Requests, this particular request is being broadcast to any Access
Point that will answer it (i.e., the destination address is
ff:ff:ff:ff:ff:ff). As can be seen from the user-friendly
information (laid out by the wireless data capture analysis tool),
the SSID field contains the name "Test Network 9." The additional
capabilities (fields of the frame body) can be observed in FIG. 6C,
which lists information such as the Supported Rates 1, 2, 5.5 and
11 (Mbit/sec), the current channel ("1"), vendor specific
information such as that the station is a Broadcom device, and
other data and capabilities. If one were to view the content of
each of frames indicated by lines 35-43, one could observe that
they were all being transmitted on the same channel (microseconds
apart) and indicated different networks--the networks the station
is scanning for. The bottom portion of the display shows the actual
bits being monitored (without the user-friendly translation). Other
information is available via the radiotap wireless header (not
shown), including the channel, the frequency, the signal strength,
and a timestamp.
[0066] Accordingly, the edge sensor logic in block 503 of FIG. 5
can populate appropriate data structures with the type of
information from the management frame illustrated in FIGS. 6B and
6C and the radiotap header. The details available can be used to
further uniquely identify a station (device) not just by its MAC
address, but also via its history, hostname, time of detection,
vendor, and status. This history (and thus a profile) of a device
can be calculated (generated) from the stored names and addresses
from each frame that the device emits. The server can then
cross-reference this information with the information about the
other detected devices. This allows the platform to automatically
determine similarities between detected devices.
[0067] For example, it may be detected that the wireless devices
belonging to two people had traveled to the same house (previously
had connected to the same WiFi) In such case, the devices (and
people associated with them) are considered related entities within
the system. This abstraction makes it easier to learn whether two
devices may be related, even though the WDDTAS has not seen them
before. For example, an administrator of the platform could
configure platform to receive notifications upon arrival of probe
requests from newly detected devices within the target zone. Upon
these notifications, the administrator can compare the profile of
the newly detected device other others known and decide whether to
further act (e.g., send out surveillance alerts etc.). Also for
example, the WDDTAS might detect a laptop and a phone on opposite
sides of the target area, but be able to relate them together as a
single entity (or threat), because those devices previously had
been connected to similar wireless networks.
[0068] By providing a device similarity metric, for example as an
abstraction such as a percentage, a profile vector (e.g., a vector
containing a value for each characteristic being monitored such
that vectors can be mathematically compared), etc. a user of the
platform (e.g., an administrator, an end user, a third party
accessing data of the installation) can determine if several of the
same devices suddenly appeared within a targeted area. Further, the
user might want to receive alerts if devices similar to a targeted
(or specified) device come within range of a certain area (the
signature or profile of a device then can be used for "targeting"
similar devices). Such capabilities can provide unique defense,
security, and commercial applications. This is of course dependent
on the quality of the information emitted from the device. If a
device is running the WDDTAS client application (thus, for example,
turning a phone into a bidirectional communication device such as
an electronic tag), there will be additional data available for
collection and the quality of the profiling and/or target can be
enhanced because it contains more and more valuable
information.
[0069] Once the wireless probe request data and metadata is
captured, the edge sensor then reports (forwards, relays) it as
appropriate to other edge sensors, servers, etc. FIG. 7 is an
example flow diagram of the reporting logic of an example edge
sensor component of an example embodiment of a Wireless Device
Detection, Tracking, and Authentication System. The edge sensor
reporting thread 700 is responsible for relaying data. In block
701, the logic determines which server to which to send the data
using path cost analysis described with reference to FIG. 2 as
needed. In one example WDDTAS, a message is broadcast over the
WDDTAS distribution network to set up direct communications with a
specific server. Then in block 702, the determined server and the
edge sensor exchange public keys to begin an encrypted session to
facilitate encrypted communication (using available public/private
key encryption techniques and negotiation such as RSA with a
Diffie-Hellman key exchange). For example, in block 703 the edge
sensor receives a session key for the determined server which has
been encrypted with the sensor's public key. The edge sensor then
generates an secure session key for a specific period of time for
encrypting and sending the data to report. For example, the edge
sense can use a Blowfish cipher or SHA-512 to generate a secure
session key to encrypt the data using AES 128/256. In block 704,
the data is serialized, encrypted using the secure session key and
sent to the determined server. The logic then continues to block
703 to refresh secure session key and send encrypted data to that
server until the edge sensor needs to determine and send data to a
different server (in which case the logic continues in a new loop
in block 701). Of note other encryption and key exchange techniques
may be also incorporated.
[0070] FIGS. 8A and 8B are examples of serialized data from a Probe
Request of a wireless station containing metadata to be reported by
an edge sensor to a server. Serialized data 800 is shown with a
multitude of columns reflected the data such as that shown in FIG.
6B. For ease of readability, an excerpt of this serialized data is
displayed in table 810. The serialized data contains an indication
of a network (ESSID 812) from the device's history, channel used
813, and other information.
[0071] In addition to passively collecting wireless signals being
emitted by wireless stations such as phones and laptops, a WDDTAS
installation, such as that described with reference to FIG. 1,
supports interactions with "electronic tags" to glean information
using an active approach. These electronic tags are "smart"
electronic tags, which allow for two-way communication with an edge
sensor for the purpose of authentication and sharing data. In FIG.
1, stations 108 and 106 are example electronic tags which
communicate bidirectionally with edge sensors 111a and 110b,
respectively. A device is an electronic tag because it is running
additional (WDDTAS) code or logic that can verify the integrity of
the tag, the identity of the user, or because it can share
additional details it has about the device.
[0072] In general, a device augmented with a software application
such as the WDDTAS client application is an electronic tag because
it is running software that is causing it to act as such, emitting
a signal on some interval, and responding to requests instead of
just being passive. In this active approach, the NICs of the edge
sensors may not be in a monitoring mode. The NICs instead may be
placed into an communication mode where the edge sensors emit probe
requests addressed to specific wireless devices (e.g. 108 and 106),
and the wireless devices respond to those probes with probe
responses in the form of probe response frames. The probe responses
are received by the edge sensors and the probe responses may
include information that is similar to the information in probe
requests received via passive monitoring. The edge sensors may
generate probe response data describing these probe responses. The
contents of the probe response data may be similar to the probe
request data described herein. The probe response data can be
provided to another computing device (e.g. a server) which performs
location determination, similarity metric calculation, and causes
location based events to occur using the probe response data, which
is similar to the processes for using the probe request data
described herein.
[0073] In one or more embodiments, the probe response data can be
substituted for the probe request data in any of the embodiments
described herein. More generally speaking, probe response data and
probe request data are both examples of management frame data that
describes management frames received by an edge sensor, and the
management frame data can be substituted for the probe request data
in any of the embodiments described herein.
[0074] Electronic tags can also provide data collection from other
types of physical sensors associated with the tag (device) and
forward such data collection to an edge sensor and/or WDDTAS
server. For example, a device that serves as an electronic tag may
provide data from sensors that measure attributes of the device or
environment such as temperature, barometric pressure, magnetic
resonance, photo voltage, and the like.
[0075] Additionally, a wireless computer or phone can become an
electronic tag by installing a WDDTAS client application that
causes it to behave in this manner. This effectively turns any
smartphone into an electronic tag. Electronic tags are unique and
provide a way to reliably identify people and goods that is not
dependent, for example, on attaching physical tags such as RFID
tags. In addition, when used in security applications, the tag
software can digitally sign a message with its public-key to the
edge-sensor, and thus to the server, for verification.
[0076] As an example, this technique can be used to provide
enhanced authentication to a device, determine or pinpoint location
of a device, or collect additional data. Enhanced authentication
can provide confirmation from multiple sources about the identity
of a person using the device. Such sources might include: something
the user has in their possession, like a computer, phone, or
electronic tag; something the user is, for example one's unique
biology, fingerprint, face, heart rate, DNA, or iris scan; and/or
something the user knows, such as a password or secret used to
prove their identity.
[0077] Because mobile devices can become electronic tags by
incorporation of WDDTAS client application, tags can be used as
authentication tokens such as for consumer purchases and
transactions. For example, a customer, carrying an electronic tag
in the form of a smartphone, may walk near to a payment area,
verify their identity (to the WDDTAS application running on the
phone), and then automatically pay for goods or services using, for
example, preconfigured payment methods. Users can opt to use
multiple different factors in order to verify their identity, such
as a PIN code or fingerprint for enhanced security. This makes it
harder for a thief to use a stolen device for purchasing goods, as
the thief would also need to know the mobile device user's pin
code, password, fingerprint, facial signature, or other
authentication factor, as a secondary factor during authentication
as designated by the WDDTAS installation.
[0078] The user of an electronic tag device or device configured to
operate as an electronic tag through WDDTAS software might prefer
to cryptographically verify the tags in order to provide accurate
validation. The process generally follows the RSA large prime
public-key cryptography standard described early. In summary, the
WDDTAS software application in the device generates a public and
private key pair consisting of large prime numbers. In a multi-key
cryptographic system, the software on either side of the
communication (here the electronic tag and the rest of the
installation) sign and encrypt their messages to each other with
these keys in order to prove their identity and the integrity of
the data. This is done to prevent interception of collected data.
The public and private keys can be located on the device within the
WDDTAS client application's protected runtime. These keys can be
used to provide primary authentication. By layering authentication
strategies in addition to public/private key encryption, the
mechanism can be made more secure.
[0079] FIG. 9 is an example block diagram of logic components of an
example server in an exemplary Wireless Device Detection, Tracking,
and Authentication System installation. As described there may be
more one server in any particular WDDTAS installation, and server
120 of FIG. 1 is one such example. Servers within the WDDTAS are
responsible mainly for storing the wireless signal metadata relayed
from the edge sensors as described with reference to FIG. 7. Even
when the server is physically incapable of connecting to an
specific edge sensor, the server may glean its data from another
intermediate edge sensor that has relayed the information which
could not be sent directly because the specific edge sensor is out
of communication. For example, in FIG. 1, the data from edge sensor
111a may be relayed from edge sensor 111b if sensor 111a cannot
send the data directly to server 120.
[0080] The example server illustrated in FIG. 9 comprises: data
connection and caching 901, security support (module, component,
logic, code, etc.) 902, device data processing system 903, various
API endpoints to support edge sensors 904, clients 905, and admins
906, and event management support 907. Any of these components can
be implemented with code logic.
[0081] The database connection and caching interface 901 is
responsible for connections and communications to edge sensors,
administrators, and API users. The server can accept connections
from administrators, edge sensors and API users, while
simultaneously postprocessing relayed data, storing data in its
database, and generating events and notifications. The security
module 902 is responsible for the encrypted communication exchanges
described earlier and the maintenance of all of the keys for each
edge sensor, client, and administrator.
[0082] Database connection and caching interface 901 is also
responsible for storing or caching data in a data repository, such
as repositories 130 and 131 in FIG. 1. Users of a WDDTAS
installation may opt to use a specific database back-end to suit
the needs of their organization, so that they can authenticate
their users against another backend. Since data is being cached and
persisted in the data repository, there is a structure that
represents the state of each device as seen from each edge sensor.
In this way the relevant most recently detected signals from a
device get persisted for 30-90 seconds or for a few minutes until
they can be expired and replaced with updated data from a next time
period.
[0083] The device data processing system 903 comprises code for
performing the postprocessing of the probe request data such as
device metadata to, for example, generate similarity metrics,
identify device pinpoint locations in instances where the edge
server is not providing such support, facilitate transaction and
purchase processing, etc. It is continuously looking for new data,
extracting metadata, computing metrics across sensors, and the
like. In installations where machine learning is available, the
data processing system 903 can incorporate machine learning engines
and algorithms to learn about device behavior over time, for
example, and to improve similarity metrics using metadata from the
device profiling. It may also use machine learning to discover
common routes and paths of avoidance. For example, it may discover
a detour when devices suddenly start moving in a new path after
moving in a base path for some period of time. It may discover the
locations of items within a store as the system cross-references
purchased items with historical device paths for a number of
devices moving around an area.
[0084] The various API endpoints provide implementation for the
logic accessed through the API to administrators of the WDDTAS, to
client applications on devices that are running the WDDTAS client
application, and to various end users such as third party users of
data. The API can be used to manage and aggregate data from each
installation or from multiple WDDTAS installations as an
authentication backend.
[0085] Event management support 907 facilitates processing of
alerts and notifications. In particular, alerts and notifications
may be location sensitive/based (such as device triggers within a
target zone) or may be location independent (such as a
transaction). Location based event management 908 and Non-location
based event management 909 support for these two different types of
events respectively. A user of the WDDTAS installation can also set
up options for these alerts and notifications. Since the system is
caching a lot of data, the cached data can be compared against the
platform user's alerts and notifications to determine if there is
any cause to generate an event or push a notification to the user.
For example, the event management support can push a notification
to possibly warning the user that an item has left the sales floor,
or a person has entered the target area, or that a device user
wishes to begin an authentication transaction.
[0086] FIG. 10 is an example flow diagram of tracking logic
executed on an example server in an example embodiment of a
Wireless Device Detection, Tracking, and Authentication System. The
server logic 1000 may be performed, for example by server 120 in
FIG. 1. Server logic 1000 performs a loop in blocks 1001-1009 to
continuously process data, respond to API request, trigger events
and notifications, locate devices, etc.
[0087] Specifically, in block 1001, the server logic determines if
there is more data (e.g. probe request data) to process. If so, the
logic continues in block 1002, otherwise returns to block 1001 (to
wait for more data). In block 1002, the server logic obtains data
from the (next) device or more data from the same device. In block
1003, the server logic determines the location of the device.
Although the logic shows this calculation being performed at this
time, it can be performed at multiple or other times while
executing this process. Determining device location can be
performed using a variety of techniques. Trilateration, such as
that described with reference to FIGS. 11A-11C is preferred, and
when not available or to provide a secondary method for verifying
accuracy of location, other techniques may be incorporated such as
using GPS technology or GSM (cell network techniques). In addition,
publicly available API for geolocation (such as from GOOGLE) may
provide fallbacks. Triangulation may also be used to determine a
device location.
[0088] Once the device location is pinpointed, then the server
logic determines whether the location has changed and, if so,
continues in block 1005, otherwise continues in block 1006. In
block 1005, the server logic processes any location triggered
events such as payment processing, mapping location, returning data
to a client application regarding the location of devices, and the
like. This logic may be performed by logic module 908 in FIG.
9.
[0089] In block 1006, the server logic determines whether any other
events have been triggered and, if so, continues in block 1009,
otherwise returns to the beginning of the loop in block 1001. In
block 1009, the server logic process other triggered events and/or
notifications such as returning data to a client, changing edge
sensor settings, etc. This logic may be performed by logic module
909 in FIG. 9. The server logic then continues to the beginning of
the loop in block 1001.
[0090] FIG. 10A is another example flow diagram of code executed on
an example server in an example embodiment of a wireless device
detection, tracking and authentication system. In step 1052, probe
request data for a monitored wireless device is received from
several edge sensors. The probe request data from a given edge
sensor can include data describing one or more probe requests
received by the edge sensor from a monitored wireless device via
passive monitoring, such as data extracted from the probe requests
or generated metadata. In step 1053, the location of the monitored
wireless device is determined from the probe request data received
from several edge sensors, such as by using signal strength
information to trilaterate the wireless device's position. In step
1054, whether the location of the monitored wireless device is
within a target geofenced zone is determined. The target geofenced
zone can have a virtual perimeter defined by an administrator and
which surrounds a geographical area.
[0091] In step 1055, similarity metrics are generated by comparing
the probe request data to stored device profiles from a database of
device profiles. For example, a similarity metric can be generated
by comparing a history of wireless networks, MAC address, and
capabilities for a monitored wireless device to the history of
wireless networks, MAC address, and capabilities for a stored
device profile. Some examples of capabilities that can be used to
generate the similarity metric include channel ID, Wifi Type
(a/b/g/n/etc), supported link speeds, supported ciphers and
cryptographic capabilities and vendor specific capabilities. Each
similarity metric indicates a similarity between the wireless
device and a given stored profile. The similarity metric may be a
numerical percentage that quantifies the similarity between the
wireless device and a given stored profile.
[0092] In step 1056, the similarity metrics are compared against a
similarity threshold and it is determined if the similarity metrics
meet a similarity threshold. For example, a similarity metric (e.g.
90%) can be compared to a similarity threshold (e.g. 85%) to
determine if the similarity metric is greater than the similarity
threshold. The comparison can be repeated for each similarity
metric to determine if any of the similarity metrics meet the
similarity threshold.
[0093] In step 1057, a location based event is caused to occur in
response to whether the location of the monitored wireless device
is in the target geofenced zone, and also in response to a result
of the comparison against the similarity threshold. The specific
events can include causing a notification to be triggered, causing
an alert to be triggered, causing the location to be displayed on a
map, causing a transaction to take place, or causing payment
processing to take place, among others. In some embodiments, the
event is caused to occur if the monitored wireless device is in the
target geofenced zone, and if the similarity metric is greater than
the threshold. In other embodiments, the event is caused to occur
if the monitored wireless device is outside the target geofenced
zone. In other embodiments, the event is caused to occur of the
similarity metric is less than the threshold.
[0094] As previously described, in embodiments that use an active
tracking approach instead of a passive approach, the server may
receive data describing probe responses instead of receiving probe
request data. The server then applies the processes described
herein to the data describing the probe responses. More generally
speaking, in some embodiments, any data describing management
frames can be used in place of the probe request data.
[0095] FIGS. 11A-11D are example diagrams illustrating
trilateration and other techniques to find a location of a wireless
station using one, two, and three edge sensors or other known
locations. Trilateration can be the process of determining absolute
or relative locations of points by measurement of distances.
Trilateration algorithms may calculate a location in a two or three
dimension (2D or 3D) plane using a devices distance from preferably
three locations. It is possible to adapt these algorithms to a 3D
version, which utilizes spheres instead of circles (see 11D).
[0096] In the case where the server is locating a device with
reference to a single edge sensor (FIG. 11A), then a Free Space
Path Loss (FSPL) algorithm is used to compute distance. The FSPL
algorithm is shown in equation (1):
FSPL = 20 log 10 ( d ) + 20 log 10 ( f ) + 20 log 10 ( 4 .pi. c ) -
G t - G r ( 1 ) ##EQU00001##
FIG. 11A demonstrates the "X" (the location of the device/station)
can be determined by a simple distance (radius) r1 from an edge
sensor. According to FSPL, signal loss can be used to calculate
distance since it increases with distance. Here "G.sub.t" and
"G.sub.r" are gain (in dBs) of the transmitter and receiver
respectively and may bet set to default gain values. "c" is the
speed of light in meters/sec. The value for FSPL is obtained from
the signal strength of a probe request. The equation can then be
solved to determine the distance "d".
[0097] In the instance where the server is locating a device with
reference to two edge sensors (FIG. 11B), then trilateration can be
used to narrow the location to two possibilities, P1 and P2,
distance r1 and r2 respectively from the edge sensors. (Each edge
sensor can compute its distance "r" to the device using the FSPL
algorithm.) In this case, where possible, a secondary method may be
employed (e.g., GPS or GSM) to choose between the two possible
locations.
[0098] When three or more edge sensors can be used to locate a
device, then trilateration can be used effectively to pinpoint the
location of the device to the point at which all three circles
intersect. FIG. 11C shows this analysis logically. (The distance
from the device to each edge sensor is again computed using FSPL.)
Note that in practice, there is some error so that the logic needs
to average out the points that the server logic obtains from
multiple groups of three sensors.
[0099] Several algorithms for implementing trilateration are
available. A discussion of those currently available is described
in
"https://confluence.slac.stanford.edu/plugins/servlet/mobile#content/view-
/907686," incorporated herein by reference in its entirety. In
addition, a publicly available algorithm is described in Wikipedia,
"en.wikipedia.org/wiki/Trilateration," herein incorporated by
reference in its entirety. The essence of this algorithm is to find
a point located at (x, y, z) that satisfies the following equations
for three spheres shown in equation (2):
r.sub.1.sup.2=x.sup.2+y.sup.2+z.sup.2
r.sub.2.sup.2=(x-d).sup.2+y.sup.2+z.sup.2
r.sub.3.sup.2=(x-i).sup.2+(y-j).sup.2+z.sup.2 (2)
Where P1, P2, and P3 (referring to FIG. 11D) are the centers of
three spheres, and their sphere radii are r1, r2, and r3,
respectively. In equation (2) "d" is the x-coordinate of point P2.
It is subtracted from "x" to obtain the base of the triangle
between the intersection and r2. The trilateration solution
described therein, the x-coordinate of the point is found in
equation (3), the y-coordinate is found in equation (4), and the
z-coordinate is found in equation (5):
x = r 1 2 - r 2 2 + d 2 2 d ( 3 ) y = r 1 2 - r 3 2 - x 2 + ( x - i
) 2 + j 2 2 j = r 1 2 - r 3 2 + i 2 + j 2 2 j - i j x ( 4 ) z =
.+-. r 1 2 - x 2 - y 2 ( 5 ) ##EQU00002##
Of note, it is possible for there to be zero, one, or two solutions
to the problem because z is expressed as a positive or negative
square root. Code corresponding to this trilateration algorithm is
included in Table 1 below written in Python.
TABLE-US-00001 TABLE 1 1 import math 2 import numpy 3 4 #assuming
elevation = 0 5 earthR = 6371 6 LatA = 37.418436 7 LonA =
-121.963477 8 DistA = 0.265710701754 9 LatB = 37.417243 10 LonB =
-121.961889 11 DistB = 0.234592423446 12 LatC = 37.418692 13 LonC =
-121.960194 14 DistC = 0.0548954278262 15 16 #using authalic sphere
17 #if using an ellipsoid this step is slightly different 18
#Convert geodetic Lat/Long to ECEF xyz 19 # 1. Convert Lat/Long to
radians 20 # 2. Convert Lat/Long(radians) to ECEF 21 xA = earthR
*(math.cos(math.radians(LatA)) * math.cos(math.radians(LonA))) 22
yA = earthR *(math.cos(math.radians(LatA)) *
math.sin(math.radians(LonA))) 23 zA = earthR
*(math.sin(math.radians(LatA))) 24 25 xB = earthR
*(math.cos(math.radians(LatB)) * math.cos(math.radians(LonB))) 26
yB = earthR *(math.cos(math.radians(LatB)) *
math.sin(math.radians(LonB))) 27 zB = earthR
*(math.sin(math.radians(LatB))) 28 29 xC = earthR
*(math.cos(math.radians(LatC)) * math.cos(math.radians(LonC))) 30
yC = earthR *(math.cos(math.radians(LatC)) *
math.sin(math.radians(LonC))) 31 zC = earthR
*(math.sin(math.radians(LatC))) 32 33 P1 = numpy.array([xA, yA,
zA]) 34 P2 = numpy.array([xB, yB, zB]) 35 P3 = numpy.array([xC, yC,
zC]) 36 37 #from wikipedia 38 #transform to get circle 1 at origin
39 #transform to get circle 2 on x axis 40 ex = (P2 -
P1)/(numpy.linalg.norm(P2 - P1)) 41 i = numpy.dot(ex, P3 - P1) 42
ey = (P3 - P1 - i*ex)/(numpy.linalg.norm(P3 - P1 - i*ex)) 43 ez =
numpy.cross(ex,ey) 44 d = numpy.linalg.norm(P2 - P1) 45 j =
numpy.dot(ey, P3 - P1) 46 47 #from wikipedia 48 #plug and chug
using above values 49 x = (pow(DistA,2) - pow(DistB,2) +
pow(d,2))/(2*d) 50 y = ((pow(DistA,2) - pow(DistC,2) + pow(i,2) +
pow(j,2))/(2*j)) - ((i/j)*x) 51 52 # only one case shown here 53 z
= numpy.sqrt(pow(DistA,2) - pow(x,2) - pow(y,2)) 54 55 #triPt is an
array with ECEF x,y,z of trilateration point 56 triPt = P1 + x*ex +
y*ey + z*ez 57 58 #convert back to lat/long from ECEF 59 #convert
to degrees 60 lat = math.degrees(math.asin(triPt[2] / earthR)) 61
lon = math.degrees(math.atan2(triPt[1],triPt[0])) 62 63 print lat,
lon
Other trilateration algorithms may be similarly incorporated to
determine the location of a device.
[0100] FIG. 11E illustrates another technique for trilateration to
find a location of a wireless station using multiple edge sensors
1111. The edge sensors 1111 are located to form a square, with one
edge sensor 1111 at each corner of the square. The edge sensors are
placed at known locations and the distances e1-e4 between the edge
sensors 1111 are set to pre-determined and known distances, such as
12 feet.
[0101] The trilateration technique uses the FSPL algorithm to
compute the distance d1-d4 between each edge sensor 1111a-d and the
wireless device 1109 from the signal strength of probe requests.
The computed distances d1-d4 and the known distances e1-e4 together
form four separate triangles. The bottom triangle is e1-d2-d2, the
rightmost triangle is d2-d3-e2, the topmost triangle is d3-d4-e3,
and the leftmost triangle is d1-d4-e4. For each triangle, a
location of the wireless device 1109 is calculated from the edge
lengths of the triangle. The four calculated locations are then
combined by averaging the locations to generate the final location
for the wireless device 1109.
[0102] Referring to the bottom triangle, the location calculation
for one specific triangle can proceed as follows. Angle ang1 is
calculated with the following equation (5):
ang 1 = arccos ( d 1 2 + e 1 2 - d 2 2 2 .times. b .times. c ) ( 5
) ##EQU00003##
[0103] Distance x1 can then be computed with equation (6) and
distance y1 can be computed with equation (7):
x1=sin(ang1).times.d1 (6)
y1=cos(ang1).times.d1 (7)
[0104] Next, even though distance x1 and y1 are calculated, there
could be two possible locations for the wireless device 1109. One
possible location is the location of the wireless device 1109 shown
in FIG. 11E. The other possible location is location 1180. To
select between these two possible locations, a distance z is
determined from the perspective of the other sensor devices 711a
and 711b using trilateration. The distance z is compared to a
threshold to determine which of the two locations to select from.
For example, if a distance z greater than distance e2, this means
the wireless device must be at position 1180. If a distance z is
less than distance e2, this means the wireless device 1109 must be
at the position shown in FIG. 11E.
[0105] The location calculations from the perspective of the
remaining three triangles is similar to the computations for the
bottom triangle. The locations calculated from the perspectives of
the four triangles are then averaged into the final location for
the wireless device 1109. For example, trilateration can be used to
determine a first candidate location of the wireless device based
on probe request data from edge sensor 711c and 711d. Trilateration
can be used to determine a second candidate location of the
monitored device based on probe request data from edge sensor 711a
and 711b. Trilateration can be used to determine a third candidate
location of the wireless device based on probe request data from
edge sensor 711b and 711c. Trilateration can be used to determine a
fourth candidate location of the wireless device based on probe
request data from edge sensor 711a and 711d. The four candidate
locations are then combined into the final location for the
wireless device 1109.
[0106] When computing the location of a device using these
techniques, such as the location calculation technique in FIG. 11E
or other techniques disclosed herein, the device can be pinpointed
under certain conditions to at least 0.5 meter accuracy to enable
precise location tracking relative to the edge sensors 711. For
comparison, current GPS technology is limited to an accuracy of 4.9
meters thus the accuracy of computing the location of a device is
enhanced using these techniques. Moreover, these techniques can be
used for "indoor positioning," a concern for IoT platforms.
[0107] All of the above calculations assumed that the edge sensor
was in a known location. As mentioned above, edge sensors can
create a dynamic geofenced target zone by being placed, for
example, on a moving object such as a vehicle. In this case, the
server logic can poll (at some designated rate) a geolocation API
for an updated location of the edge sensor, or in some cases use
alternative methods to compute the area between the edge sensors.
This will be explained later in the specification by reference to
FIG. 15.
[0108] In another embodiment, the location can be calculated with
triangulation. Triangulation can involve the measurement of angles
of a triangle and one or more sides to determine the location of an
object. In one embodiment, an angle of arrival (AoA) of probe
requests from a wireless device can be measured by an edge sensor.
The edge sensor may have two or more antennas. The phases of a
received probe request signal can be measured at the two antennas.
The difference between the two phases is then used to determine the
AoA. The edge sensor can include the AoA in the probe request data
that is transmitted to the server, or to another computing device.
The AoA is obtained from multiple edge sensors. This AoA from
multiple sensors is used to triangulate a location of a wireless
device.
[0109] In another embodiment, triangulation can be used in
combination with trilateration to determine the location of a
wireless device, which further improves accuracy.
[0110] As described earlier, edge sensors may be augmented with a
WDDTAS client application to improve their functional capacity such
as to increase the amount and type of data collected, allow a user
to opt-in for certain types of payment processing and retail
applications, to provide electronic tag functionality, and the
like. FIG. 12 is an example block diagram of logic components of an
example client application for execution on a wireless station in
an example embodiment of a Wireless Device Detection, Tracking, and
Authentication System. In some WDDTAS installations, the client
application may be the same as the application described below for
administration and managements of the WDDTAS.
[0111] As illustrated in FIG. 12, WDDTAS client application
comprises electronic tag support 1201 (component, code, logic,
module, etc.), security support 1202, authentication support 1203,
payment and transaction support 1204, automatic WiFi connection
logic 1205, retail support 1206, configuration management 1207, and
API endpoints 1210. Electronic tag support 1201 turns the device
into an electronic tag for bidirectional communication with an edge
server as described above. Security support 1202 allows the client
device to generate their public keys. Authentication support 1203
facilitates providing augmented authentication, for example, using
biometric data, pins, etc. as described above.
[0112] Payment and transaction support 1204 allows users to make
payments for example, in known or permitted locations, as a result
of triggering a location-based event when entering vicinity of the
store's zone (created using edge sensors). Store here is used in a
loose sense and may refer to any establishment that accepts payment
or can conduct a transaction. This support can be run as a
background service and invoked upon trigger of the location-based
event.
[0113] Configuration management support 1207 manages privacy
settings 1208 and the user's ability to share with others through
sharing interface 1209. For example, users may desire to turn off
their WiFi when not at home and prevent being tracked (if they wish
to download the WDDTAS application) using privacy settings 1208.
Other accommodations may be implemented to enhance privacy of the
user of the wireless device. Control of privacy settings does
provide an incentive for users to download the WDDTAS application
to their wireless devices. In addition, a user may desire to
provide information or accepted shared provided information from
another user using sharing interface 1209. For example, a user
shopping in a store may wish to seek and accept help from other
users in the store.
[0114] Automatic WiFi connection logic 1205 facilitates an option
for users of the device (e.g., customers of a store) to
automatically connect to the store's WiFi according to a store's
API. Because data is continuously being collected from the device
through passive monitoring, if the privacy switch is off and the
user has opted-in to use of the data, then the user's data is
potentially reported to the store as well.
[0115] Dynamic branding support 1206 in conjunction with API
endpoints 1210 governs the ability for third parties, such as
stores, hospitals, restaurants, and the like (associated with
physical locations) to push logos, bios, backgrounds, color
schemes, etc. to the device while the device is located within the
location. In some instances, the WDDTAS may require a user to
opt-in to this push notification in some form. This may operate
like "style sheets" for the device. In some instances the dynamic
branding support may provide push notifications to assist a user,
for example, to find things or provide an immediate location-based
"virtual assistant."
[0116] As described with reference to FIG. 1, configuration and
management of a WDDTAS installation is typically controlled by one
or more administrators or someone acting in that capacity. FIG. 13
is an example block diagram of logic components of an example
administrative application for management of an exemplary Wireless
Device Detection, Tracking, and Authentication System installation.
The WDDTAS administrative application (or admin application) is
software or other code logic running on a computer, phone, or
tablet, which is used to manage the WDDTAS installation. It allows
unprivileged users and privileged administrators of the WDDTAS
installation to view information about the devices detected by the
edge sensors in the target zones (areas defined by groups of edge
sensors or other areas of interest). Depending on a user's
permission level, that user can create users and groups, delegate
roles, or manage user permissions for a WDDTAS installation.
[0117] As illustrated in FIG. 13, WDDTAS admin application
comprises floor plan support (component, module, code, logic, etc.)
1301, security support 1302, geofencing support and zone management
1303, access control 1304, event and notification support 1305,
payment processing and transaction support 1306, configuration
management 1307, API endpoints 1310, edge sensor configuration and
maintenance 1311, and report generation and statistics 1312.
[0118] Floor plan support 1301 allows the admin application to load
floor plans or a map (preloaded or dynamically) in order to overlay
computed sensor information (detected and located devices) over an
area, indoor or outdoor. This can allow users of the WDDTAS
installation or software used to access or manage the WDDTAS
installation) to designate zones (areas of interest) between or
nearby sensors. Clients of the WDDTAS installation (e.g., third
party users such as within stores, hospitals, government, etc.) can
then subscribe to events to be notified as they are generated. For
example, as a tracked device within a WDDTAS installation moves
from zone to zone, the servers (or edge sensors in some cases) can
generate notifications which are forwarded to the subscribed
parties or clients.
[0119] In addition the tracked devices can be visually located on
the map using API support. Also, WDDTAS installation subscribed
clients can search for devices near to a particular location (or
relative to a specific device) with a search interface, and be
shown a visual path to a specific targeted device or be shown that
device's path and movement history through the area. Lots of
graphical interfaces can be supported through these
capabilities.
[0120] Security support 1302 allows the admin user to generate
their public keys for communication with servers. It also allows
the admin user to revoke an edge sensor's ability to report tracked
data, etc.
[0121] Geofencing support and zone management 1303 facilitates an
admin user defining a dynamic (movable) zone of edge sensors or a
fixed position group of sensors (or a hybrid) that defines an area.
It can also determine the distance from an admin's device running
the WDDTAS admin application to any other device in the
installation. Payment areas can be treated as a specific
manifestation of a target zone. Payment processing and transaction
support 1306 can operate in conjunction with the geofencing support
1303 to configure particular payment and/or transaction methods for
a defined geofenced area. This module can also establish whether a
user of a device has paid for an item before leaving a retail
establishment.
[0122] Access control support 1304 allows an admin user to define
access for other users, groups of users, etc. as regards
configuration aspects of the WDDTAS installation, data, API access,
and the like. Domains of users/groups may be established based upon
a defined edge sensor zone (a target area).
[0123] Event and notification support 1305 can facilitate admin
users defining "watchlists" of devices and/or zones for security
applications or otherwise or defining "blacklisted" or
"whitelisted" devices or device profiles. In addition, it can allow
admin users to define events and/or notifications that are location
or non-location based as described earlier.
[0124] Report generation and statistics support 1312 facilitates
the generation of metrics regarding location of devices (such as
the percentage of time a device is in zone x), traffic percentages
in zones, downtime statistics regarding edge sensors, and other
WDDTAS installation and/or device metrics.
[0125] Edge sensor configuration and maintenance support 1311 may
monitor edge sensor traffic to determine when data is no longer
being received from an edge sensor. In that instance, a visual
interface can be provided to the admin user to facilitate
identification of the damaged or unavailable sensor.
[0126] Configuration management support 1307 can facilitate an
admin user providing or associating personalization and branding
with a zone they are responsible for administering. For example, an
admin user of a retail establishment (with limited admin privileges
vis-a-vis the WDDTAS installation) may configure logos,
backgrounds, information and the like to appear on devices that are
running the WDDTAS client application (see FIG. 12). In addition
configuration management support 1307 can define authorization to
access APIs through API access support 1309, the format for
serialized data relayed by the edge sensors to servers, etc.
Configuration management support 1307 may also define attributes
that influence choice of path (path cost) for reporting data from
edge servers.
[0127] API endpoints 1310 provide access to the administrative
support to third party applications.
[0128] Other similar or different functions for administrative
access to a WDDTAS installation are similarly contemplated and can
be made available using the capabilities and support of the WDDTAS
admin application.
Computing Systems for Implementation of WDDTAS Components:
[0129] FIG. 14 is an example block diagram of a computing system
for practicing embodiments of a Wireless Device Detection,
Tracking, and Authentication System. Of note, the computing system
shown in FIG. 14 may be used to practice embodiments of a WDDTAS
server and/or edge sensor described herein. Note as well that one
or more general purpose virtual or physical computing systems
suitably instructed or a special purpose computing system may be
used to implement an WDDTAS server/edge sensor. Further, the WDDTAS
may be implemented in software, hardware, firmware, or in some
combination to achieve the capabilities described herein.
[0130] Note that one or more general purpose or special purpose
computing systems/devices may be used to implement the described
techniques. However, just because it is possible to implement the
WDDTAS server/edge sensor on a general purpose computing system
does not mean that the techniques themselves or the operations
required to implement the techniques are conventional or well
known.
[0131] The computing system 1400 may comprise one or more server
and/or client computing systems and may span distributed locations.
In addition, each block shown may represent one or more such blocks
as appropriate to a specific embodiment or may be combined with
other blocks. Moreover, the various blocks of the WDDTAS
server/edge sensor 1410 may physically reside on one or more
machines, which use standard (e.g., TCP/IP) or proprietary
interprocess communication mechanisms to communicate with each
other.
[0132] In the embodiment shown, computer system 1400 comprises a
computer memory ("memory") 1401, a display 1402, one or more
Central Processing Units ("CPU") 1403, Input/Output devices 1404
(e.g., keyboard, mouse, CRT or LCD display, etc.), other
computer-readable media 1405, and one or more network connections
1406. The WDDTAS 1410 is shown residing in memory 1401. In other
embodiments, some portion of the contents, some of, or all of the
components of the WDDTAS 1410 may be stored on and/or transmitted
over the other computer-readable media 1405. The components of the
WDDTAS 1410 preferably execute on one or more CPUs 1403 and manage
the detection, tracking, authentication of devices, and persistence
of device information as described herein. Other code or programs
1430 and potentially other data repositories, such as data
repository 1420, also reside in the memory 1401, and preferably
execute on one or more CPUs 1403. Of note, one or more of the
components in FIG. 14 may not be present in any specific
implementation. For example, some embodiments embedded in other
software may not provide means for user input or display.
[0133] In a typical embodiment of a WDDTAS server for example, the
WDDTAS 1410 includes one or more Notification and Tracking
Processing engines 1411, one or more authentication engines 1412,
and wireless processing (and/or RFID processing, GPS, etc.) 1413.
In at least some embodiments, the notification processing 1411 is
provided external to the WDDTAS and is available, potentially, over
one or more networks 1450. Other and/or different modules may be
implemented. In addition, the WDDTAS may interact via a network
1450 with application or client code 1455 that controls
administration of a WDDTAS installation, one or more client
computing systems 1460 that use the data provided by a WDDTAS
installation, and/or one or more third-party information provider
systems 1465. Also, of note, the WDDTAS Device and Event data
repository 1416 and/or the WDDTAS installation data repository 1415
may be provided external to the WDDTAS as well, for example in a
third party database accessible over one or more networks 1450.
[0134] In an example embodiment, components/modules of the WDDTAS
1410 are implemented using standard programming techniques. For
example, the WDDTAS 1410 may be implemented as a "native"
executable running on the CPU 1403, along with one or more static
or dynamic libraries. In other embodiments, the WDDTAS 1410 may be
implemented as instructions processed by a virtual machine. A range
of programming languages known in the art may be employed for
implementing such example embodiments, including representative
implementations of various programming language paradigms,
including but not limited to, object-oriented (e.g., Java, C++, C#,
Visual Basic.NET, Smalltalk, and the like), functional (e.g., ML,
Lisp, Scheme, and the like), procedural (e.g., C, Pascal, Ada,
Modula, and the like), scripting (e.g., Perl, Ruby, Python,
JavaScript, VB Script, and the like), and declarative (e.g., SQL,
Prolog, and the like).
[0135] The embodiments described above may also use well-known or
proprietary, synchronous or asynchronous client-server computing
techniques. Also, the various components may be implemented using
more monolithic programming techniques, for example, as an
executable running on a single CPU computer system, or
alternatively decomposed using a variety of structuring techniques
known in the art, including but not limited to, multiprogramming,
multithreading, client-server, or peer-to-peer, running on one or
more computer systems each having one or more CPUs. Some
embodiments may execute concurrently and asynchronously and
communicate using message passing techniques. Equivalent
synchronous embodiments are also supported.
[0136] In addition, programming interfaces to the data stored as
part of the WDDTAS 1410 (e.g., in the data repositories 1415 or
1416) can be available by standard mechanisms such as through C,
C++, C#, and Java APIs; libraries for accessing files, databases,
or other data repositories; through scripting languages such as
XML; or through Web servers, FTP servers, or other types of servers
providing access to stored data. The data repositories 1415 and
1415 may be implemented as one or more database systems, file
systems, or any other technique for storing such information, or
any combination of the above, including implementations using
distributed computing techniques.
[0137] Also the example WDDTAS 1410 may be implemented in a
distributed environment comprising multiple, even heterogeneous,
computer systems and networks. Different configurations and
locations of programs and data are contemplated for use with
techniques of described herein. In addition, the [server and/or
client] may be physical or virtual computing systems and may reside
on the same physical system. Also, one or more of the modules may
themselves be distributed, pooled or otherwise grouped, such as for
load balancing, reliability or security reasons. A variety of
distributed computing techniques are appropriate for implementing
the components of the illustrated embodiments in a distributed
manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP,
Web Services (XML-RPC, JAX-RPC, SOAP, etc.) and the like. Other
variations are possible. Also, other functionality could be
provided by each component/module, or existing functionality could
be distributed amongst the components/modules in different ways,
yet still achieve the functions of an WDDTAS.
[0138] Furthermore, in some embodiments, some or all of the
components of the WDDTAS 1410 may be implemented or provided in
other manners, such as at least partially in firmware and/or
hardware, including, but not limited to one or more
application-specific integrated circuits (ASICs), standard
integrated circuits, controllers executing appropriate
instructions, and including microcontrollers and/or embedded
controllers, field-programmable gate arrays (FPGAs), complex
programmable logic devices (CPLDs), and the like. Some or all of
the system components and/or data structures may also be stored as
contents (e.g., as executable or other machine-readable software
instructions or structured data) on a computer-readable medium
(e.g., a hard disk; memory; network; other computer-readable
medium; or other portable media article to be read by an
appropriate drive or via an appropriate connection, such as a DVD
or flash memory device) to enable the computer-readable medium to
execute or otherwise use or provide the contents or instructions to
perform at least some of the described techniques. Some or all of
the components and/or data structures may be stored on tangible,
non-transitory storage mediums. Such computer program products may
also take other forms in other embodiments. Accordingly,
embodiments of this disclosure may be practiced with other computer
system configurations.
Example Use Cases:
[0139] 1) A customer of the WDDTAS requests to authenticate with a
sensor-equipped ATM. The WDDTAS system can determine the identity
of the person within proximity of the ATM and can verify with
additional factors (to provide secure authentication with multiple
authentication factors) that this user is authorized.
[0140] 2) A WDDTAS installation administrator might decide to use
the WDDTAS platform in a physical security operation. It might be
used to find lost devices, if those devices happen to have WiFi
turned on. It might also be used to detect and grab the signatures
of devices, building a profile for each device, in order to
retroactively determine which devices, and thus people, have been
present in the area.
[0141] 3) A WDDTAS installation administrator might decide to
install their own system for tracking precious inventory. In the
case of certain kinds of merchandise, like electronic merchandise
(e.g. phones or laptops), the merchandise can have the electronic
tag application installed, and thus can be tracked throughout the
store. Even though these devices would be detected by the WDDTAS
without the application installed, the store owner can install the
application on these devices in order to provide cryptographic
proof that the item has not been spoofed, and/or forged, by a
program that emits similar wireless traffic. If an end user (e.g.,
the store owner) has this kind of sensor platform in-store, the end
user will probably want the system to generate alerts as the
merchandise walks out the front door.
[0142] 4) A store manager might use the WDDTAS installation as a
payment system. The installation could provide instantaneous
automated purchases for customers who have an electronic tag on
their respective devices or are running the WDDTAS application on
their wireless devices. This example uses the installation's
ability to determine the location of devices within the area as
computed from fixed or determined coordinates for each edge sensor.
Once the device has been detected near to the target area, and the
device has performed an RSA cryptographic handshake with an edge
sensor, it will receive a session token that can be used to make
purchases or validate the identity of a potential consumer.
[0143] 5) In certain cases electronic tags can report additional
information such as battery status, temperature, magnetic
resonance, accelerometer state, and user presence. These tags
running the electronic tag software application can share
information back to the associated edge sensor, and from the sensor
back to the server. WDDTAS administrators could collect the current
temperature from each electronic tag in order to form a heatmap
from the data returned by the WDDTAS API. This data could then be
mined and used for a variety of purposes including for scientific
use.
[0144] 6) Some operators prefer a moving installation, and thus
edge sensors can be equipped with the ability to determine their
own location with GPS or wireless trilateration in order to provide
edge sensor location. Once the system knows the starting points at
each edge sensor and the signal distance from those edge sensors,
the actual location of a device can be plotted on a map alongside
one or many other devices.
[0145] 7) Enhanced data collection from electronic tags. Fitness
bands and devices with similar ability to measure heart rate, skin
conductivity, breathing, and footsteps (pedometer) can reveal
additional details that are reported to an associated edge sensor.
A gym trainer might use a WDDTAS installation so configured to
collect this data from many fitness devices at once in order to
provide better training. Biofeedback could also be provided. We
could use this biofeedback mechanism to help users train out their
anxiety and other psychiatric disorders. For example, learning
breathing exercises, and allowing the user to try and control their
vitals by providing continuous feedback. For example, trying to
achieve normal breathing rate, heart rate, breath duration, skin
conductivity, and blood oxygen levels.
[0146] 8) A WDDTAS installation can provide an inventory tracking
system that replaces RFIDs and can use any type of electronic tag
as a beacon recognized by an edge sensor that is part of the
installation.
[0147] 9) A WDDTAS installation can provide system for tracking
doctors and other medical professionals as they move through
handling patients so that more accurate time estimates may be
delivered to waiting patients and office personnel.
[0148] 10) More accurate locating and probing of desired targets.
Edge sensors can be placed on a drone or other vehicle and used to
define a virtual and dynamically changing "zone" (dynamic
geofencing) surrounding eventual targets.
[0149] 11) Using dynamic geofencing, a search and rescue type
operation or broadcast to find a device in a moving vehicle such as
in response to an amber alert can be aided by the dynamic
geofencing target zones provided by a WDDTAS installation.
[0150] Many other example use cases can take advantage of the
passive monitoring, accurate pinpointing of device location, and
ability to dynamically define target zones using groups of edge
sensors facilitated by a WDDTAS installation.
Additional Topic Areas for Further Claims:
[0151] 1. A mobile wide-area wireless sensor network that can be
deployed on-demand, with sensors that can route payments between
one another to reach the payment back-end.
[0152] 2. A platform that provides wireless and mobile
authentication of devices and their users optionally with automated
two factor authentication. It can verify the locations of devices
and authenticate those devices over WiFi, sending those details
back to the server.
[0153] 3. A selector-based intelligence system for detecting and
targeting 802.11 wireless devices in the area of operation by
selecting and storing their probe requests and beacons without
requiring additional electronic tag software to detect devices.
[0154] 4. A mobile wireless detection platform that can optionally
run on battery operated hardware. This mobile platform provides
device detection and other features on-the-go. As such, the system
can be mounted to vehicles and unmanned aerial vehicles (drones),
and can be controlled by a tablet operator collecting signals.
[0155] 5. A platform that provides similarity metrics and can
identify whether two monitored devices are similar or a likelihood
that the two devices have been in previous contact with each other
based upon their prior connection histories.
[0156] Other claim topic areas are contemplated based upon the
above description.
Dynamic Geofencing using Moving Edge Sensors
[0157] FIG. 15 illustrates dynamic geofencing using moving sensor
devices 1511 according to an embodiment. The sensor devices 1511
can be similar to the previously described edge edge sensors. The
sensor devices 1511a-d can be located in or on moving objects such
as vehicles 1505a-d. Examples of vehicles 1505 can be land based
vehicles, water based vehicles, or aerial vehicles such as drones.
Placing the sensor devices 1511 in or on the vehicles creates a
dynamic geofenced target zone 1554 that dynamically moves and
follows the location of the edge sensors 1511. For example, the
vehicle(s) 1505 and sensor devices 1511 move 1552 from one general
location L1 to another general location L2. The geofenced target
zone 1554 is defined relative to the location of the sensor devices
1511. Initially, the mobile device 1509 is within the geofenced
target zone 1554 at location L1. However, once the sensor devices
1511 move to location L2, the mobile device 1509 is no longer
within the geofenced target zone 1154 because the target zone 1154
has moved.
[0158] As shown in FIG. 15, the geofenced target zone 1554 between
sensor devices 1511 can start from the center point of each sensor
device 1511. The geofenced target zone 1554 scales in size as
sensor devices 1511 move closer or further away from one another.
For example, the geofenced target zone 1554 at location L1 has the
shape of a small rectangle because the vehicles 1505 are located
closer to each other. The geofenced target zone 1554 at location L2
has the shape of a larger rectangle because the vehicles 1505 are
spread further apart from each other.
[0159] In FIG. 15, the geofenced target zone 1554 is rectangular.
In other embodiments, the geofenced target zone 1554 can be a
different shape, such as being in the shape of a circle or a
triangle. The boundary of a geofenced target zone 1554 may pass
through the sensor devices 1511 as shown in FIG. 15. In other
embodiments, the boundary of the geofenced target zone 1554 may not
pass through the sensor devices 1511 and so the target zone 1554
can be smaller or larger than is shown in FIG. 15.
[0160] The location of the edge sensors 1511 in this case can be
determined using GPS or with another location based technique. The
server or some other computing device can poll (at some designated
rate) a geolocation API for an updated location of the edge sensors
1511, or in some cases use alternative methods to compute the
distance between the edge sensors. In one embodiment, a local
computing device (e.g. one of the edge sensors 1111 or another
computing device) in the vehicle 1505 can collect information from
the edge sensors 1511 and perform these calculations without
communicating with a server.
[0161] At each general location (e.g. L1, L2), the sensors 1511 can
monitor probe requests from wireless devices 1509 to generate probe
request data. The locations of the edge sensors 1511 and the probe
request data from the edge sensor 1511 are used to determine the
location of the wireless device 1509, such as with trilateration
techniques. A location based event is triggered if the mobile
device 1109 is determined to be within the dynamic geofenced target
zone 1154, and/or if a similarity metric computed for the mobile
device 1509 meets a similarity threshold.
[0162] For example, in one use case, multiple vehicles 1505 or a
small squad with sensor devices 1511 in their backpacks are
searching for a wireless device belonging to a criminal suspect or
devices known to be present at a crime scene. The area in between
the sensor devices defines a geofenced target zone 1554. As
wireless devices (e.g. 1509) enter or exit the zone 1554, the
system can generate alerts. The system may generate a similarity
metric for each wireless device by comparing probe request data for
the wireless device 1509 with the device profile associated with a
known criminal or device profiles of devices known to be present at
a crime scene. If the similarity metric meets a similarity
threshold, the system can also generate a notification the matching
device was detected.
[0163] In at least one embodiment, all of the sensor devices 1511
can be in a single vehicle. For example, the vehicle can be a
low-flying aircraft with a sensor device 1511 on each wing tip and
the tail of the aircraft.
Single Moving Sensor
[0164] FIG. 16A illustrates a technique for finding a location of a
wireless device using a single moving sensor device 1611. The
sensor device 1611 can be similar to the previously described edge
sensor. The figures illustrates a single sensor device 1611 mounted
to a moving vehicle 1605. The sensor device 1611 moves from left to
right and captures probe requests from the mobile device 1609 at
different times and while the sensor device 1611 is at different
locations. For example, at time T1, the sensor device 1611 is at a
first location L1 and receives first probe requests from the
wireless device 1609. At time T2, the sensor device 1611 is at a
second location L2 and receives second probe requests from the
wireless device 1609. At time T3, the sensor device 1611 is at a
third location L3 and receives third probe requests from the
wireless device 1609.
[0165] Like before, the NIC of a sensor device 1611 can be placed
into a monitor mode or another mode in which wireless traffic is
passively monitored. When each probe request is received by the
NIC, data about the probe request is stored in association with the
location of the sensor device 1611 when the probe request was
received. In some embodiments, management frames other than probe
request frames can be captured since they are seen more often. The
location of the sensor device 1611 can be determined, for example,
from GPS or using other location based techniques.
[0166] The location of the mobile device 1609 is then determined
from the data describing the probe requests received at the
different locations L1-L3, and also using the locations of the edge
sensor 1611 when the probe requests were received. In one
embodiment, trilateration techniques can be used to determine the
location of the wireless device 1609. For example, the distances
1650, 1651 and 1652 to the locations L1, L2 and L3 can be
determined from the signal strengths of the probe requests using
the FSPL algorithm. Trilateration can be used to determine a
candidate location of the wireless device 1609 from distances 1650
and 1651 and the locations L1 and L2. Trilateration can be used to
determine a candidate location of the wireless device 1609 from
distances 1650 and 1651 and locations L2 and L3. These two
candidate locations can combined into the final location. In some
embodiments, the sensor device 1611 can perform these calculations
to track the location of the device 1609. In other embodiments, the
data describing the probe requests and the location of the edge
sensors 1611 can be transmitted to a remote computing device (e.g.
a server) or a computing device in the vehicle which performs the
location calculations.
[0167] FIG. 16B illustrates a process for tracking and using a
location of a wireless device using a single moving edge sensor
1611. In step 1690, code of the sensor device 1611 places its NIC
into a monitor mode or other mode in which probe requests from
wireless devices can be passively monitored. In step 1691, the NIC
receives several probe requests from a wireless device while the
sensor device 1611 is at a particular location (e.g. L1, L2, L3).
In step 1692, in response to the NIC receiving the probe requests,
code of the sensor device 1611 generates probe request data
describing the probe requests and identifies the sensor device
location when those probe requests were received. Steps 1691 and
1692 can be repeated one or more times to capture additional probe
requests and generate probe request data at different sensor device
locations.
[0168] In step 1693, code of the sensor device 1611 determines the
location of the monitored wireless device from the probe request
data generated at different sensor device locations and their
associated sensor device locations. This step can use, for example,
trilateration techniques that calculate the location of the
wireless device using the signal strength of the probe requests. In
step 1694, code of the sensor device 1611 determines if the
location of the wireless device 1609 is within a predefined
geofenced zone, such as the geographic zone 1657 in FIG. 16A. The
geographic zone 1657 may be a fixed zone or it may be dynamic and
move with the sensor device 1611.
[0169] In step 1695, code of the sensor device 1611 generates
similarity metrics by comparing the probe request data to stored
device profiles from a database of device profiles. In step 1696,
code of the sensor device 1611 compares the similarity metrics
against a similarity threshold to determine if the metrics meet the
threshold. The comparison can be repeated for each similarity
metric to determine if any of the similarity metrics meet the
similarity threshold.
[0170] In step 1697, code of the sensor device 1611 causes a
location based event to occur in response to whether the location
of the monitored device is in the target geofenced zone, and also
in response to the comparison against the similarity threshold. For
example, the event can be triggered if the monitored device is in
the target geofenced zone 1657 and a similar metric is greater than
the threshold. The location based event may be any of the events
described herein.
[0171] Steps 1693-1697 can also be performed by code of another
computing device that receives the information describing the probe
requests from the sensor device 1611. Some of the steps may also be
optional. For example, some of steps 1694-1696 may be optional.
[0172] In one use case, the vehicle 1605 may a ride-sharing vehicle
being driven for a ride-sharing service such as Uber or Lyft. There
is a mobile phone (not shown) inside the vehicle 1605 that is
running tracking software, which is similar to the software found
in the server. A ride-hailing customer is holding the wireless
device 1609, and the driver of the vehicle 1605 is attempting to
locate the ride-hailing customer. As the vehicle 1605 drives down
the street, probe requests from the wireless device 1609 are
received by the moving sensor device 1611 and are used to track the
location of the wireless device 1609. The probe requests are also
used to determine a similarity metric from the wireless device's
1609 stored profile. If the similarity metric is above threshold
(indicating a match for the customer), the location for the
customer can be provided to the mobile phone of the driver (not
shown), which causes the location to be displayed on a map (e.g.
with an icon) on the mobile phone. As a result, the rider's exact
location is known to the driver and the location can be tracked
with a greater degree of accuracy than with current location based
techniques. This particular use case may not use a geofenced
zone.
Payment Zones
[0173] FIG. 17 illustrates a system for payment processing,
according to an embodiment. Several sensor devices 1711 are located
around a checkout register 1715 in a store. A geofenced payment
zone 1754 is located around a checkout register 1715. The system
includes a server 1720, which may be the server 120 of FIG. 1. The
system also includes a wireless device 1709 that can have a WDDTAS
client application installed on it, and which is adapted for
payment processing.
[0174] A customer carrying the wireless device 1709 can walk into
the geofenced payment zone 1754. The sensor devices 1711 monitor
probe requests from the wireless device 1709 and transmit
information describing the probe requests to the server 1720 (or
other computing devices). The server 1720 determines the location
of the wireless device 1709 and whether the location of the
wireless device 1709 is in the geofenced payment zone 1754. The
server 1720 also compares the probe request data for the wireless
device 1709 to a whitelist of device profiles that have been
pre-registered as payment enabled devices, and this comparison
generates similarity metrics. The similarity metrics are compared
to a similarity threshold to determine if the wireless device 1790
sufficiently matches any of the device profiles that are registered
as being payment enabled.
[0175] If one of the device profiles is matched, and the location
is within the payment zone 1754, the server 1720 causes a payment
transaction with the wireless device 1709 to occur. This can
include performing a cryptographic handshake with an application on
the wireless device 1709. The server 1720 then sends a command code
to the wireless device 1709. The command code triggers the
application to ask for additional authentication information, such
as a pin code or biometric authentication, which may be provided to
the server 1720. This secondary level of authentication is used to
prevent spoofing or duplicate devices. Once this is provided, the
wireless device 1709 can display the item to be purchased along
with buttons to cancel or confirm the transaction. If the
transaction is confirmed by the user, the wireless device 1709
provides a command code to the server 1720 that finalizes the
payment. In some embodiments, the command codes can be relayed
between the wireless device 1709 and server 1720 via a sensor
device 1711 that is determined to be closest to the wireless device
1709.
Security Zones
[0176] FIG. 18 illustrates a system for providing security,
according to an embodiment. Several sensor devices 1811 are located
in an area that is to be secured, such as a home, building, or
business. A geofenced security zone 1854 is defined to extend in a
circle around the sensor devices 1811. The system includes a server
1820 and a security computing device 1822 being monitored by a
security guard or other personnel.
[0177] A person carrying a wireless device 1809 can walk into the
geofenced security zone 1854. The sensor devices 1811 monitor probe
requests from the wireless device 1809 and transmit probe request
data to the server 1820 (or other computing devices). The server
1820 then determines the location of the wireless device 1809 and
whether the location of the wireless device 1809 is in the
geofenced security zone 1854.
[0178] If the location of the wireless device 1809 is in the
geofenced security zone 1854, the server 1820 computes one or more
similarity metrics for the device 1809 by comparing the probe
request data (e.g. which includes wireless network history) to one
or more blacklisted device profiles. The blacklisted device
profiles include profiles of devices that are known to be
suspicious, such as criminals or terrorists. The similarity metrics
are compared to a similarity threshold. If any similarity metrics
exceed the threshold, the server 1820 performs a security action,
such as transmitting a security notification or alert 1824 to the
security computing device 1822 indicating that a suspicious device
has been detected in the geofenced security zone 1854. For example,
if the wireless networks in a blacklisted device profile and the
wireless networks visited by a monitored wireless device are
substantially the same, the similarity metric will be above the
threshold. As a result, there is a good chance that a user of the
monitored wireless device is related to or the same as the user of
the blacklisted device. The security notification or alert 1824 is
thus generated to provide an alert of a suspicious user.
[0179] Alternatively or additionally, a similarity metric can be
generated by comparing the probe request data (e.g. which includes
wireless network history) to one or more whitelisted device
profiles. The whitelisted device profiles include profiles of
devices that are known to be safe, such as authorized users of the
facility associated with the security zone 1854. The similarity
metric is compared to a similarity threshold. If the similarity
metric meets a similarity threshold (e.g. 99%), this indicates that
the mobile device matches a profile on the whitelist and is safe.
As a result, the server 1820 does not need to generate a security
notification or alert 1824. If the similarity metric is below the
similarity threshold, this indicates that the mobile device does
not match anything on the whitelist and a security notification or
alert 1824 can be generated.
Other Considerations
[0180] From the foregoing it will be appreciated that, although
specific embodiments have been described herein for purposes of
illustration, various modifications may be made without deviating
from the spirit and scope of the invention. For example, the
methods, techniques, and systems for performing device detection,
tracking, and authentication discussed herein are applicable to
other architectures other than a 802.11 architecture. For example,
the methods, techniques and systems also apply (with changes to
protocols and data) to Bluetooth architectures. Also, the methods,
techniques, and systems discussed herein are applicable to
differing protocols, communication media (optical, wireless, cable,
etc.) and devices (such as wireless handsets, electronic
organizers, personal digital assistants, portable email machines,
game machines, pagers, navigation devices such as GPS receivers,
etc.).
[0181] In some embodiments, the components described as being in a
server may be included in computing devices other than a server,
and the processes described as being performed by a server may be
performed by computing devices other than a server. For example,
the functions of a server may be implemented by a non-server
computer or the functions of the server may be implemented by one
or more of the edge sensors. Additionally, any of the operations
described herein can be implemented with software code, such as
machine code/processor instructions, which are stored on one or
more non-transitory computer readable media and are executable by
at least one processor.
[0182] In some embodiments, a wireless device detection and
tracking system comprises: a plurality of edge sensors located to
form one or more geographic zones, each edge sensor comprising at
least one antenna, at least one wireless network interface
controller, monitoring code logic and reporting code logic. The
monitoring code logic is configured to place the at least one
wireless networking interface controller (NIC) into a monitor mode
to cause the NIC to monitor wireless network traffic from one or
more wireless devices passively without responding to the one or
more wireless devices and without initiating or otherwise forming a
communication connection to any one of the one or more wireless
device; upon receiving a request for a possible connection to a
previously connected network from a monitored device of the one or
more wireless devices through passive monitoring, extracting data
from the request and formulating metadata corresponding to the
monitored device; and wherein the reporting code logic is
configured to relay the extracted data and metadata corresponding
to the monitored device. A data repository is configured to
persistently store wireless device data and metadata. At least one
server computing system is communicatively coupled to the plurality
of edge sensors and the data repository, and configured to: receive
the relayed extracted data and metadata corresponding to the
monitored device; and using trilateration techniques, determine a
location of the monitored device.
[0183] In some embodiments, the request for the possible connection
to a previously connected network from a monitored device is an
802.11 Probe Request delivered as a 802.11 Management Frame. The
wireless network traffic can be monitored passively using Bluetooth
protocol.
[0184] In some embodiments, the location of the monitored device is
determined in substantially near real time by the at least one
server computing system to obtain a location of the monitored
device that is perceived to be current.
[0185] In some embodiments, the formulated metadata is used to
generate a profile of the monitored device. In some embodiments,
the generated profile of the monitored device is compared to
profiles of other devices to determine additional characteristics
regarding the monitored device.
[0186] In some embodiments, the monitoring code logic is configured
to receive a request for a possible connection to a previously
connected network from a second monitored device of the one or more
wireless devices, and wherein the generated profile of the
monitored device is used to determine a probability or likelihood
that the second monitored device has been in contact with the
monitored device when the received requests of both the second
monitored device and the monitored device indicate previous
communications with at least one network in common.
[0187] In some embodiments, at least one of the plurality of edge
sensors comprises a second wireless networking interface controller
and wherein the at least one of the plurality of edge sensors is
configured to control the at least one wireless networking
interface controller using the monitoring code logic and is
configured to control the second wireless network interface
controller using the reporting code logic.
[0188] In some embodiments, the trilateration operates by computing
distances of the monitored device from two or more of the plurality
of edge sensors without using a GPS and without using GSM cellular
network towers.
[0189] In some embodiments, at least some of the plurality of edge
sensors are mobile and dynamically located to form the one or more
geographic zones.
[0190] In some embodiments, the at least one server system further
configured to determine whether the location of the monitored
device is within one of the one or more geographic zones; and when
it is determined that the location of the monitored device is
within the one of the geographic zones, cause a notification or an
alert.
[0191] In some embodiments, the at least one server system further
configured to determine whether the location of the monitored
device is within one of the one or more geographic zones, and when
it is determined that the location of the monitored device is
within the one of the geographic zones, causing a transaction or
payment processing to take place.
[0192] In some embodiments, the at least one server system further
configured to: determine an identification of the monitored device;
and based upon the determined identification and the determined
location of the monitored device triggering an alert
notification.
[0193] In some embodiments, the formulated metadata is a history of
wireless networks the monitored device has previously connected
to.
[0194] In some embodiments, the at least one server computing
system is further configured to identify the monitored device based
upon the history of wireless networks of the monitored device.
[0195] In some embodiments, the at least one server computing
system is further configured to determine the identity of the
monitored device using the MAC address of the monitored device and
the formulated metadata.
[0196] In some embodiments, the monitored device of the one or more
wireless devices is a mobile device.
[0197] In some embodiments, at least one of the plurality of edge
sensors is a mobile device that executes a wireless device
detection and track system application.
[0198] In some embodiments, a method for wireless device detection
and tracking comprises: under control of one or more edge sensors
located to form one or more geographic zones, passively monitoring
one or more wireless devices without forming a communication
connection to any one of the one or more wireless devices; upon
receiving a request for a possible connection to a previously
connected network from a monitored device of the one or more
wireless devices, extracting data from the request and formulating
metadata corresponding to the monitored device; populating a data
structure corresponding to the monitored device with the extracted
data and the formulated metadata corresponding to the monitored
device; and forwarding the contents of the data structure to one or
more servers that are configured to use trilateration techniques to
determine a location of the monitored device.
[0199] In some embodiments, the passively monitoring one or more
wireless devices is performed without responding to the one or more
wireless devices. The method can comprise causing computation of a
similarity metric of the monitored device to one or more other
devices of the one or more wireless devices. The similarity metric
can be based upon a history of wireless connections that are
associated with the monitored device. In some embodiments, the
history of wireless connections that are associated with the
monitored device is discoverable by tracking multiple requests from
the monitored device.
[0200] In some embodiments, a computer-readable medium contains
instructions for controlling a computer processor to detect and
track wireless devices by performing a method comprises: under
control of one or more edge sensors located to form one or more
geographic zones, passively monitoring one or more wireless devices
without forming a communication connection to any one of the one or
more wireless devices; upon receiving a request for a possible
connection to a previously connected network from a monitored
device of the one or more wireless devices, extracting data from
the request and formulating metadata corresponding to the monitored
device; populating a data structure corresponding to the monitored
device with the extracted data and the formulated metadata
corresponding to the monitored device; and forwarding the contents
of the data structure to one or more servers that are configured to
use trilateration techniques to determine a location of the
monitored device.
[0201] In some embodiments, the passively monitoring one or more
wireless devices is performed without responding to the one or more
wireless devices. In some embodiments, the method comprises when it
is determined that the location of the monitored device is within
the one of the geographic zones facilitating a payment or a
transaction.
[0202] In some embodiments, a computer-readable medium contains
instructions for controlling a computer processor to detect and
track wireless devices by performing a method comprising: receiving
data relayed from a plurality of edge sensors located to form one
or more geographic zones, the relayed data containing data and
metadata extracted and/or formulated from a request for a possible
connection from a monitored wireless device passively monitored by
at least one of the plurality of edge sensors; using trilateration
techniques, determining a location of the monitored device; and
based upon determining whether the determined location of the
monitored device is within one of the one or more geographic zones,
triggering a notification and/or an alert, or facilitating a
transaction.
[0203] In some embodiments, the monitored wireless device is
monitored passively without any of the plurality of edge sensors
forming a communication connection to the monitored device. In some
embodiments, the method comprises based upon determining whether
the determined location of the monitored device is within one of
the one or more geographic zones, authenticating the user of the
device using a secondary authentication factor that is at least one
of a pin code, password, fingerprint, and/or biometric
measurement.
[0204] In some embodiments, the method further comprises
identifying the monitored device using one or more of: a MAC
address, hostname, time of detection, vendor, and status.
[0205] In some embodiments, a wireless device detection and
tracking system comprises a plurality of sensor devices associated
with one or more geofenced zones. Each sensor device comprises a
wireless network interface controller (NIC). Each sensor device
comprises code configured to: upon the wireless NIC receiving at
least one management frame, generate data describing the at least
one management frame. At least one computing device is configured
to receive the data describing the at least one management frame,
and using trilateration techniques, determine a location of the
monitored wireless device based on the data describing the at least
one management frame. For example, the data can include a signal
strength of the at least one management frame, which is used an
input for determining the location of the wireless device.
[0206] In some embodiments, a wireless device detection and
tracking system comprises a plurality of sensor devices associated
with one or more geofenced zones. Each sensor device comprises a
wireless network interface controller (NIC). Each sensor device
comprises code configured to: place the wireless NIC into a mode
that causes the wireless NIC to monitor wireless network traffic
from one or more wireless devices passively; and upon the wireless
NIC receiving at least one request for a possible connection to a
previously connected network from a monitored wireless device of
the one or more wireless devices through passive monitoring,
generate data describing the at least one request for the possible
connection. At least one computing device is configured to receive
the data describing the at least one request for the possible
connection; and using trilateration techniques, determine a
location of the monitored wireless device based on the data
describing the at least one request for the possible
connection.
[0207] In some embodiments, the at least one request for the
possible connection to a previously connected network from a
monitored wireless device includes an 802.11 Probe Request
delivered as a 802.11 Management Frame.
[0208] In some embodiments, the wireless network traffic is
monitored passively using a Bluetooth protocol.
[0209] In some embodiments, the at least one computing device is
configured to generate a similarity metric by comparing the data
describing the at least one request for the possible connection to
a stored wireless device profile; and cause a location based event
to occur based on the similarity metric and the location of the
monitored wireless device.
[0210] In some embodiments, the data describing the at least one
request includes a history of wireless networks the monitored
wireless device has previously connected to, and the similarity
metric is generated by comparing the history of wireless networks
to wireless networks of the stored wireless device profile.
[0211] In some embodiments, the similarity metric is generated by
comparing the data describing the at least one request to a
blacklisted device profile, wherein causing the location based
event to occur comprises: triggering a security notification or
alert responsive to the location of the monitored wireless device
being in one of the geofenced zones and the similarity metric
exceeding a similarity threshold.
[0212] In some embodiments, the similarity metric is generated by
comparing the data describing the at least one request to a
whitelisted device profile, wherein causing the location based
event to occur comprises: triggering a security notification or
alert responsive to the location of the monitored wireless device
being in one of the geofenced zones and the similarity metric not
exceeding a similarity threshold.
[0213] In some embodiments, the similarity metric is generated by
comparing the data describing the at least one request to a stored
device profile corresponding to a payment enabled device, and
causing the location based event to occur comprises: causing a
payment transaction to take place responsive to the location of the
monitored wireless device being in one of the geofenced zones and
responsive to the similarity metric exceeding a similarity
threshold.
[0214] In some embodiments, the sensor devices are mobile and
dynamically located such that the one or more geofenced zones are
dynamic geofenced zones that follow a location of the sensor
devices.
[0215] In some embodiments, the at least one computing device is
further configured to: determine whether the location of the
monitored wireless device is within one of the one or more
geofenced zones; and cause a location based event to occur based on
whether the location of the monitored wireless device is within the
one of the geofenced zones.
[0216] In some embodiments, causing the location based event to
occur comprises: when it is determined that the location of the
monitored wireless device is within the one of the geofenced zones,
causing a notification to be triggered, causing an alert to be
triggered, causing a transaction to take place, or causing payment
processing to take place.
[0217] In some embodiments, the at least one computing device
comprises a server or one of the sensor devices.
[0218] In some embodiments, the sensor devices include a first
sensor device, a second sensor device, a third sensor device, and a
fourth sensor device. At least one computing device is configured
to determine the location of the monitored wireless device by:
using trilateration techniques, determine a first candidate
location of the monitored wireless device based on the data
describing the at least one request received from the first sensor
device and the second sensor device; using trilateration
techniques, determine a second candidate location of the monitored
wireless device based on the data describing the at least one
request received from the third sensor device and the fourth sensor
device; and determining the location of the monitored wireless
device by combining the first candidate location of the monitored
wireless device and the second candidate location of the monitored
wireless device.
[0219] In some embodiments, the data describing the at least one
request is transferred from a corresponding sensor device to the at
least one computing device via a least cost path that includes one
or more other sensor devices of the plurality of sensor devices,
the least cost path identified with a path cost analysis
algorithm.
[0220] In some embodiments, the monitored wireless device is store
merchandise within a store.
[0221] In some embodiments, the location of the monitored wireless
device is determined using both trilateration techniques and
triangulation techniques
[0222] In some embodiments, the mode that the wireless NIC is
placed into is a monitor mode.
[0223] In some embodiments, a wireless device detection and
tracking system comprises: a sensor device comprising at least one
wireless network interface controller (NIC) configured to passively
monitor wireless network traffic from one or more wireless devices;
code to, upon the NIC receiving at least one first request for a
possible connection to at least one previously connected network
from a monitored wireless device of the one or more wireless
devices through passive monitoring and while the sensor device is
at a first location, generate first data describing the at least
one first request; code to, upon the NIC receiving at least one
second request for a possible connection to at least one previously
connected network from a monitored wireless device of the one or
more wireless devices through passive monitoring and while the
sensor device is at a second location, generate second data
describing the at least one second request; and code to determine a
location of the monitored wireless device using trilateration
techniques based on the first data describing the at least one
first request and the second data describing the at least one
second request.
[0224] In some embodiments, the sensor device is in or on a land
based vehicle, an aerial vehicle, or a water borne vehicle that
moves from the first location to the second location.
[0225] In some embodiments, the system further comprises code to
determine whether the location of the monitored wireless device is
within a target geofenced zone; and code to cause a location based
event to occur based on whether the location of the monitored
wireless device is within the geofenced zone.
[0226] In some embodiments, the target geofenced zone is a dynamic
geofenced zone that follows a location of the sensor device.
[0227] In some embodiments, the system further comprises code to
generate a similarity metric by comparing the first data describing
the at least one first request or the second data describing the at
least one first request to a stored wireless device profile; and
code to cause a location based event to occur based on the
similarity metric and the location of the monitored wireless
device.
[0228] In some embodiments, the first data or the second data
includes a history of wireless networks the monitored wireless
device has previously connected to, and the similarity metric is
generated by comparing the history of wireless networks to wireless
networks of the stored wireless device profile.
[0229] In some embodiments, the system comprises code to cause a
location based event to occur based the location of the monitored
wireless device.
[0230] In some embodiments, the at least one first request for the
possible connection to at least one previously connected network
from a monitored wireless device includes an 802.11 Probe Request
delivered as a 802.11 Management Frame.
[0231] In some embodiments, the system comprises code to, upon the
NIC receiving at least one second request for a possible connection
to at least one previously connected network from a monitored
wireless device of the one or more wireless devices through passive
monitoring and while the sensor device is at a third location,
generate third data describing the at least one third request,
wherein the location of the monitored wireless device is determined
using trilateration techniques further based on the third data
describing the at least one third request.
* * * * *
References