U.S. patent application number 15/879221 was filed with the patent office on 2018-05-31 for mobile device detection and tracking.
The applicant listed for this patent is BlueFox, Inc.. Invention is credited to Thuong Ho, Jan Willem Korver, Amanda Mills, Philippe Morin, Guillaume Tenant de la Tour.
Application Number | 20180152818 15/879221 |
Document ID | / |
Family ID | 58721736 |
Filed Date | 2018-05-31 |
United States Patent
Application |
20180152818 |
Kind Code |
A1 |
Mills; Amanda ; et
al. |
May 31, 2018 |
MOBILE DEVICE DETECTION AND TRACKING
Abstract
Disclosed is a technique for passively monitoring the number of
guests in a rental property. Mobile device broadcasts intended for
connecting the device to a wireless network contain information
about that device. This information includes unique identifiers
such as MAC addresses. Detecting these broadcasts and filtering out
those devices that are expected enables a property owner to have a
semi-accurate number of guests within their property without
actually being at the property, or visibly observing the guests in
an obtrusive fashion. Guests are able to enjoy themselves in
privacy and the property owner is able to monitor the safety of
their property.
Inventors: |
Mills; Amanda; (Menlo Park,
CA) ; Morin; Philippe; (Sunnyvale, CA) ;
Tenant de la Tour; Guillaume; (Saratoga, CA) ; Ho;
Thuong; (San Jose, CA) ; Korver; Jan Willem;
(AC Utrecht, NL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BlueFox, Inc. |
Sunnyvale |
CA |
US |
|
|
Family ID: |
58721736 |
Appl. No.: |
15/879221 |
Filed: |
January 24, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15426945 |
Feb 7, 2017 |
9936357 |
|
|
15879221 |
|
|
|
|
15006057 |
Jan 25, 2016 |
9769625 |
|
|
15426945 |
|
|
|
|
62107193 |
Jan 23, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 12/1202 20190101;
G06Q 30/0261 20130101; G06Q 50/163 20130101; H04W 4/30 20180201;
H04W 12/00512 20190101; H04W 4/33 20180201; H04W 4/14 20130101;
H04W 12/08 20130101; H04W 4/06 20130101; H04W 4/029 20180201; H04W
4/21 20180201; G06Q 30/0267 20130101; H04W 12/12 20130101; H04L
67/24 20130101; H04L 63/1425 20130101; H04W 4/04 20130101; H04L
67/26 20130101 |
International
Class: |
H04W 4/33 20180101
H04W004/33; H04W 4/14 20090101 H04W004/14; H04L 29/08 20060101
H04L029/08; H04W 12/08 20090101 H04W012/08; H04W 4/06 20090101
H04W004/06 |
Claims
1. A method for monitoring a visitor count in a domicile and
reporting the visitor count to a user comprising: detecting, by a
wireless communicator, wireless device broadcasts from wireless
devices, the wireless device broadcasts include a device identifier
used to connect to wireless networks, wherein the device identifier
of a given wireless device broadcast identifies a particular
wireless device of the wireless devices; communicating a number of
unique device identifiers to a web server; determining, by the web
server, the number of unique device identifiers exceeds a
predetermined threshold; and transmitting, by the web server, a
notification to a user device indicating the predetermined
threshold has been exceeded.
2. The method of claim 1, further comprising: broadcasting, by the
wireless communicator, a signal causing nearby wireless devices to
emit wireless device broadcasts.
3. The method of claim 1, further comprising: identifying, from the
device identifiers, a number of resident device identifiers
associated with resident wireless devices, wherein the resident
devices identifiers are those device identifiers that exceed a
threshold for frequency of detection; and reducing the number of
unique device identifiers by the number of resident device
identifiers.
4. The method of claim 1, further comprising: receiving, by a
mobile application, resident instructions including a number of
resident devices; transmitting, by the mobile application, to the
web server the resident instructions; and reducing the number of
unique device identifiers by the number of resident devices.
5. The method of claim 1, further comprising: communicating, by the
web server, the number of unique device identifiers to the user
device; and rendering, by a client application, on the user device
the number of unique device identifiers.
6. The method of claim 1, further comprising: transmitting, by the
web server, a push notification or SMS message to the user device
when the number of unique devices is below a threshold.
7. The method of claim 1, wherein the domicile is a rental
property, and the wireless communicator is installed in the rental
property.
8. The method of claim 7, further comprising analyzing, by the web
server, a rental calendar associated with the rental property for a
current rental status; and adjusting the predetermined threshold
based on the current rental status.
9. The method of claim 1, wherein said detecting step further
comprises: determining, by the wireless communicator, a device type
for each of the wireless devices based on a comparison of each
device identifier to an identifier schema; and ignoring all
wireless devices that do not have the device type of "phone."
10. A method for monitoring a visitor count in a domicile and
reporting the visitor count to a user comprising: detecting, by a
wireless communicator, wireless device broadcasts from wireless
devices, the wireless device broadcasts include a device identifier
used to connect to wireless networks, wherein the device identifier
of a given wireless device broadcast identifies a particular
wireless device of the wireless devices; communicating a number of
unique device identifiers to a web server; and exposing, by the web
server, the number of unique device identifiers to an application
interface accessible via the Internet by an authorized device.
11. The method of claim 10, further comprising: broadcasting, by
the wireless communicator, a signal causing nearby wireless devices
to emit wireless device broadcasts.
12. The method of claim 10, wherein the application interface is a
mobile client application and the authorized device is a mobile
user device, the method further comprising: rendering, by the
mobile client application, on the mobile user device the number of
unique device identifiers.
13. The method of claim 10, wherein the domicile is a rental
property, and the wireless communicator is installed in the rental
property.
14. The method of claim 13, further comprising analyzing, by the
web server, a rental calendar associated with the rental property
for a current rental status; and adjusting the predetermined
threshold based on the current rental status.
15. A system for monitoring a visitor count in a domicile and
reporting the visitor count to a user comprising: a wireless
communicator configured to detect wireless device broadcasts from
wireless devices, the wireless device broadcasts provide
identifying data used to connect to a wireless network, wherein
each of the wireless device broadcasts include a device identifier
for a respective wireless device of the wireless devices, the
wireless communicator further configured to count a number of
unique device identifiers of wireless devices; a mobile application
including a user interface for the wireless communicator and user
account settings; a web server configured to receive the number of
unique device identifiers of wireless devices from the wireless
communicator over the Internet and compare the unique number of
device identifiers to a threshold as determined by input from the
mobile application, the web server further configured transmit data
regarding the number of unique device identifiers of wireless
devices to the mobile application.
16. The system of claim 15, wherein the mobile application is
paired with the wireless communicator on a first user account
stored at the web server.
17. A method for monitoring a visitor count across a number of
rental properties and reporting the visitor count to a user
comprising: communicating, by a web server, with a plurality of
wireless communicators over the Internet, wherein the plurality of
wireless communicators are physically dispersed throughout the
number of rental properties and each wireless communicator of the
plurality of wireless communicators is associated with a particular
rental property of the plurality of rental properties; detecting,
by a first wireless communicator, wireless device broadcasts from
wireless devices, the wireless device broadcasts provide
identifying data used to connect to a wireless network, wherein
each of the wireless device broadcasts include a device identifier
for a respective wireless device of the wireless devices, the first
wireless communicator physically located within a first rental
property; communicating, by the first wireless communicator, a
first visitor data to the web server, the first visitor data
including a first number of unique device identifiers and a first
rental property identifier; and communicating, by the web server,
the first visitor data to a user device; and rendering, by a client
application, on the user device the first number of unique device
identifiers as associated with the first rental property.
18. The method of claim 17, further comprising: communicating, by
the client application, a visitor threshold for each of the
plurality of rental properties; determining, by the web server, the
first number of unique device identifiers a first visitor threshold
associated with the first rental property; and transmitting, by the
web server, a push notification or SMS message to the user device
indicating the first threshold has been exceeded at the first
rental property.
19. The method of claim 18, further comprising analyzing, by the
web server, a first rental calendar associated with the first
rental property for a current rental status; and adjusting the
first visitor threshold based on the current rental status.
20. The method of claim 17, wherein said detecting step further
comprises: determining, by the first wireless communicator, a
device type for each of the wireless devices based on a comparison
of each device identifier to an identifier schema; and ignoring all
wireless devices that do not have the device type of "phone."
21. The method of claim 17, further comprising: identifying, by the
first wireless communicator, a first number of resident device
identifiers associated with resident wireless devices, wherein the
resident devices identifiers are those device identifiers that
exceed a threshold for frequency of detection; and reducing, by the
first wireless communicator, the first number of unique device
identifiers by the first number of resident device identifiers.
Description
CLAIM FOR PRIORITY
[0001] The presently filed application is a continuation
application of U.S. patent application Ser. No. 15/426,945,
entitled "Mobile Device Detection and Tracking," filed Feb. 7,
2017, which is a continuation-in part application of U.S. patent
application Ser. No. 15/006,057 entitled "Mobile Device Detection
and Tracking," filed Jan. 25, 2016, which claims priority to U.S.
Provisional Application No. 62/107,193, entitled "System and Method
for Managing Digital Display Systems," filed Jan. 23, 2015; and
U.S. Provisional Application No. 62/292,812, entitled "Mobile
Device Detection and Tracking," filed Feb. 8, 2016, all of which
are incorporated by reference herein in their entirety.
TECHNICAL FIELD
[0002] Teachings relate to electronic data management and more
specifically, but not exclusively, to unobtrusively tracking mobile
devices without installed applications or opt-in applications.
BACKGROUND
[0003] Bed and breakfasts, condos, time shares, and other rental
properties have an issue with unauthorized parties. Property owners
often do not have a close relationship with their guests and
renters, but in order to conduct a business must extend trust of
their property anyway. Sometimes guests take advantage of that
trust and invite unauthorized individuals to come onto the
property, causing physical damage to the property or reputational
damage with neighbors and police. Owners wish to mitigate property
damage, though in a way that respects the privacy of their guests
without overburdening management at a given property.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 is an exemplary top-level block diagram illustrating
an embodiment of a mobile detection system.
[0005] FIG. 2 is a flowchart illustrating a method of detecting a
mobile device.
[0006] FIG. 3 is a flowchart illustrating a method of tracking a
mobile device.
[0007] FIG. 4 is an exemplary sequence diagram tracking a mobile
device through a store.
[0008] FIG. 5 is an exemplary top-level block diagram illustrating
an embodiment of a mobile detection system integrated with a
security system.
[0009] FIG. 6 is an illustrative implementation of a mobile device
tracking system integrated with a security system.
[0010] FIG. 7 is a flowchart illustrating a method of tracking a
mobile device integrated with a security system.
[0011] FIG. 8 is a flowchart illustrating a method for visitor
counting.
[0012] FIG. 9 is an illustration diagram of a visitor counting
system in accordance with FIG. 8.
[0013] FIG. 10 is a flowchart illustrating a method for managing a
visitor counting system with a calendar.
[0014] FIG. 11 is an illustration of a system for managing numerous
properties with an integrated system of visitor counters.
[0015] FIG. 12 is a block schematic diagram of a system in the
exemplary form of a computer system within which a set of
instructions for causing the system to perform any one of the
foregoing methodologies and logical flows may be executed.
DETAILED DESCRIPTION
[0016] Disclosed herein is a technique to help property owners
monitor their property in a way that respects the privacy of their
guests without overburdening management. In order to achieve these
goals, the technique involves the use of a device that counts the
local number of wireless/mobile devices and reports this number to
a master device. Further, thresholds may be set up to trigger
notifications (such as push or SMS). Settings for the device can be
handled by the master device (e.g, a mobile phone including a
paired application).
[0017] Mobile devices such as cellular phones, tablets, or other
portable networked devices emit signals in Bluetooth, WiFi, and
cellular (i.e. 2G, 3G, 4G, Edge, H+, etc.). These signals attempt
to connect to paired devices, hotspots, cell towers, or other
suitable wireless connection points to greater networks
("hotspots"). In order to connect to hotspots, mobile devices send
out identifying data to establish a connection.
[0018] If the mobile device is tricked into attempting to connect
with a network transceiver disguised as a hotspot, the fake hotspot
may unobtrusively collect the identification data of the mobile
device and then reject the connection request. The fake hotspot
collects data in real-time on the mobile device, and by
association, collects data regarding the human carrying the mobile
device. This data collection occurs without alerting or impeding
the human carrier. The system uses analytical software to
determine, for example, an approaching unique ID user's presence,
history, frequency of visits, duration of presence, and so on. The
type of data available to the fake hotspots varies based on a
number of details, such as the kind of hotspot used.
[0019] FIG. 1 is an exemplary top-level block diagram illustrating
an embodiment of mobile detection system 20. The system 20 relates
to mobile devices 22 carried on a user's person. The mobile devices
22 are detected by network transceivers 24. Network transceivers 24
are detection devices or mobile stations (MS), which colloquially
can be referred to as fake hotspots or sniffers, that collect
identification data from mobile devices 22. Data collected by the
network transceivers 24 is forwarded to an application server 26
via the Internet. The application server 26 includes a processor 28
and a data storage or memory 30 for logging metrics 32 and running
application analytical software 34. The results of the analysis of
metrics 32 are displayed or rendered to a user on a display 38.
[0020] In some embodiments, a dashboard selects and controls data
that is received from the network transceivers 24 at the
application server 26. The dashboard can control, from a distance,
data captured by the network transceivers 24 as well as new visitor
characteristics, history of data used, the number of mobile devices
that can be sensed, demographics regarding a selected user, and so
on.
[0021] The network transceivers 24 may include a plurality of
sensors and communicative devices. Examples include wireless
fidelity (WiFi) sensors, cell signal 2G, and Femto sensors for 3G
and 4G for sensing a user's mobile device 22.
[0022] Mobile devices 22 emit WiFi signals automatically. WiFi
signals carry identifying data including the MAC address (unique ID
number), power of the signal, distance of mobile device 22 from the
network transceiver 24, brand of the mobile device 22, name of the
mobile device 22 (given by the user), and the network name the
mobile device 22 used to connect.
[0023] Cell signals (2G, 3G, 4G, etc.) emitted by a phone also
occur automatically. The network transceivers 24 detect this signal
with an active action on a regular basis to collect the MAC address
(unique ID number), SIM card number (IMSI), power of the signal,
distance of mobile device 22 from network transceiver 24, carrier,
nationality of the mobile device 22, list of applications which
attempt to update, and the addresses of the web pages already open
(or cached) on the mobile device 22.
[0024] Cell signal in this case refers to both CDMA and GSM type
networks. While normally CDMA networks would not necessarily use
mobile devices 22 with SIM cards, SIM cards exist in devices that
use 4G LTE signals. Additionally, in the U.S., CDMA carriers use
network-based whitelists to verify their subscribers. The mobile
device 22 will still have a unique ID for the carrier to use for
identification.
[0025] FIG. 1 includes three network transceivers 24. In order to
locate the location of a given mobile device 22, knowing the
distance between the desired location and three known locations
enables a triangulation calculation to determine the desired
location. To triangulate, a minimum of three fake hotspots is
required. In practice, a user may want additional fake hotspots
scattered throughout a given area or building to improve coverage
or accuracy. At the time of this disclosure, lower quality network
transceiver sensors have a roughly 150 foot range. As the cost of
components changes with time, the optimal density of network
transceivers 24 required to balance the effectiveness and cost
within a bounded area/building would vary.
[0026] The network transceivers may additionally include processors
28 for internal operations and/or for accepting some of the
analytical processing load from the application server 26. Network
transceivers 24 may also employ sniffer software 40. Sniffer
software 40 includes program operations of the network transceivers
24 as well as network protocol software. Examples of network
protocol software include adaptations of OpenBTS (Open Base
Transceiver System) and OpenBSC (Open Base Station Controller),
with additional features as taught herein. OpenBTS is stable, more
complete for GSM, and has a release for UMTS (Universal Mobile
Telecommunications System). OpenBTS includes the functionality to
perform complete man-in-the-middle attacks. It is worth noting that
OpenBSC makes use of OpenBTS for its BTS functionalities.
[0027] Using OpenBTS software, examples of base model hardware that
may be used for the network transceiver are adaptations of
communications platforms manufactured by Ettus Research, Fairwaves,
and Nuand.
[0028] The WiFi sniffer software 40 exists on a WiFi card. This
sniffer software 40 configures the WiFi adapter into a monitor mode
and displays continuously without any treatment or interruption.
All the MAC addresses and RSSI values of mobile devices 22 are
detected and no data is thrown away. A pattern length corresponds
to the quantity of signals captured by the WiFi adapter. The curve
representing the RSSI values of these signals is shown in FIG. 8.
There is a variation in the signal strength over a given time (less
than a second); however, when the sniffer software 40 is configured
to check every millisecond, the network transceiver 24 captures the
majority of the signal emitted by the mobile devices 22.
[0029] Some phone brands (ex: Apple) use a randomized MAC address.
They will provide a number of fake MAC addresses along with the
real one in an attempt to hide the real number. However, the random
MAC addresses change whereas the real one does not. A data filter
compares the MAC address for a given mobile device received over a
plurality of network connection requests and removes device ID
numbers which do not appear repeatedly. Consistent existence of a
particular MAC address signifies a real address.
[0030] For cellular signals, there are two distinguishable cases:
idle mode and non-idle mode. In idle mode, the mobile device 22
performs the selection and re-selection of a base station to make
sure that the mobile device 22 is attached with the best possible
channel to the carrier network. In non-idle mode, a mobile device
22, with a point-to-point active call, will perform a base station
handover to assure that the call is not dropped.
[0031] In order for the mobile device 22 to choose to identify
itself to the network transceivers 24, the mobile device 22 has to
reselect the cell managed by the network transceivers 24 and push
them to identify/authenticate. A set of criteria is defined in the
standard mobile phone regarding this selection/re-selection
procedure. A BCCH frequency scan can be described as follows: the
mobile device 22 scans a set of frequencies to detect a BCCH
frequency to camp on. Criteria for cell eligibility can be selected
or re-selected. These cells include timing information. In some
embodiments, every five seconds, the network transceiver 24
calculates the parameters for the serving cell and for non-serving
cells.
[0032] GSM, UTRAN, and/or LTE (2G, 3G, 4G) cell reselection is
feasible. Therefore, within the sniffer software 40 are programmed,
unique approaches for each. According to the network requests, a
network transceiver 24 provides specific identification parameters
to a fake network (e.g., IMSI or IMEI). The network initiates the
identification procedure by transferring an IDENTITY REQUEST
message to the network transceiver 24 and starts a timer T3270. The
IDENTITY REQUEST message specifies the requested identification
parameters in the identity type information element. The IMSI
and/or IMEI may be requested.
[0033] In some embodiments, the data network includes a wired data
network and/or any category of conventional wireless communication
networks; for example, radio, Wireless Fidelity (WiFi), cellular,
satellite, and broadcasting networks. Exemplary suitable wireless
communication technologies include, but are not limited to, Global
System for Mobile Communications (GSM), General Packet Radio
Service (GPRS), Code Division Multiple Access (CDMA), Wideband CDMA
(W-CDMA), CDMA2000, IMT Single Carrier, Enhanced Data Rates for GSM
Evolution (EDGE), Long-Term Evolution (LTE), LTE Advanced,
Time-Division LTE (TD-LTE), High Performance Radio Local Area
Network (HiperLAN), High Performance Radio Wide Area Network
(HiperWAN), High Performance Radio Metropolitan Area Network
(HiperMAN), Local Multipoint Distribution Service (LMDS), Worldwide
Interoperability for Microwave Access (WiMAX), ZigBee, Bluetooth,
Flash Orthogonal Frequency-Division Multiplexing (Flash-OFDM), High
Capacity Spatial Division Multiple Access (HC-SDMA), iBurst,
Universal Mobile Telecommunications System (UMTS), UMTS
Time-Division Duplexing (UMTS-TDD), Evolved High Speed Packet
Access (HSPA+), Time Division Synchronous Code Division Multiple
Access (TD-SCDMA), Evolution-Data Optimized (EV-DO), Digital
Enhanced Cordless Telecommunications (DECT), and others.
[0034] The sensors can acquire data on the media access control
(MAC address), signal strength, timestamp of probes received, and
so on, from the mobile device. In some embodiments, the sensors can
be integrated into the display device and/or placed as a separate
unit collecting data metrics per location and uploading them to the
central server. Additional sensors improve the accuracy of the
wireless metrics as well as cover multiple areas within a location.
Other sensors that can be used include Bluetooth, GSM/2G, and so
on.
[0035] FIG. 2 is a flowchart illustrating a method of detecting a
mobile device. In step 202, when turned on, the sniffer software 40
scans different frequencies (WiFi, Cellular, etc.) and collects the
information broadcasted from the different PLMN's (Public Land
Mobile Networks) cells, including the adjacent cells. The network
transceivers 24 will also use this phase to take the necessary
measurements to determine constants.
[0036] In step 204, the sniffer software 40 periodically catches
all the IDs of the local mobile devices 22 in the zone of activity
for the network transceiver 24. The period is identified by a
CATCHER_PERIOD and is determined based on experimental measurements
(e.g., number of active PLMNs and corresponding cell
characteristics in the zone of activity). Broadcast for a duration
CATCHER_DURATION_PER_PLMN BCCH information is on a frequency
adjacent to the GSM range. The power of transmission
CATCHER_TRANSMIT_POWER_PER_PLMN is computed with precision based on
the collected information.
[0037] In step 206, a radio resource (RR) connection with each
mobile station attached to the current PLMN requests
identification. The different mobile devices 22 respond with the
requested IDs: TMSI, IMSI, and/or IMEI. In step 208, the collected
IDs are stored, and in step 210, the IDs of mobile devices 22 are
transmitted to the application level and the application server
26.
[0038] In step 212, based on the communication between the mobile
device 22 and the network transceivers 24, the mobile device's
location is triangulated. In step 214, the network transceiver 24
terminates the RR connections requesting that mobile devices 22
return to the previous BCCH.
[0039] FIG. 3 is a flowchart illustrating a method of tracking a
mobile device. In step 302, a first data set from the method of
FIG. 2 is collected by the sniffer software 40 and/or the server's
application software 34. Then, in step 304, the software 40
determines whether or not additional locations are tracked for the
same mobile device 22 (cycling through some of the steps of FIG. 2
over again). The determination of whether or not the same device is
discovered is through comparison of the identification data
received in repeated cycles of the method of FIG. 2.
[0040] In step 306, if the given mobile device 22 is no longer
detected, the software 34 notes the loss of the mobile device. In
step 308, if the given mobile device 22 remains in contact, the
multiple locations are plotted as a path. If the mobile device 22
has not moved, the path includes a wait time or a "mill around in
substantially the same area time."
[0041] In step 310, the path is rendered on a map of the area
supported by the network transceivers 24. In step 312, a profile is
generated for that given mobile device's ID information. The
profile may include data such as: average visit duration (recent
and historical), average dwell time, bypassing traffic, path taken,
and new versus recurring visitors (recent and historical).
[0042] In some embodiments, the sensors report recent metrics 32
for the approaching user back to the central server 26.
Advantageously, movement of the approaching user can be determined,
for example, using MAC readings and calculating the distance to a
selected sensor, taking into account the signal strength of a
particular reading. Low signal strength readings can be filtered to
reduce noise.
[0043] The central server 26 can include one or more probe
controllers and/or location controllers (not shown). The probe
controllers process the aggregate information from all network
transceivers 24 and image capturing devices (not shown). The
location controllers provide analytics for backend historical data
as well as end-point data for real-time, recurring visitor
decisions. Readings can be stored in a database using any
conventional data mapping methods. For example, readings stored
include, but are not limited to, signal strength (e.g., received
signal strength indication (RSSI)), timestamp, location ID,
International Mobile Station Equipment Identity (IMEI), gender,
attention time, timestamp, age, and proximity readings.
[0044] In some embodiments, the central server 26 provides a
dashboard to enable secured access for an administrator. For
example, HTTP secure connections can be used, and transport layer
security/secure sockets layers can be used to provide authenticated
access to the administrator. Additionally and/or alternatively,
two-factor authentication can be used to provide a token and/or
password to the administrator.
[0045] Once the administrator is authorized, the dashboard allows
the administrator to select and control the data that is received
at the central server 26. The administrator can access the
dashboard at the central server 26 or through the data network.
[0046] FIG. 4 is an exemplary sequence diagram tracking a mobile
device through a store. The technology of analyzing people in
real-time can be used as an efficient communication strategy in
public environments (e.g., in corporate and campus locations). For
example, organizations can adjust advertisements through collected
metrics and analytic data.
[0047] In some embodiments, additional sensors are integrated into
the system 20 to increase the number of metrics collected. Metrics
are combined with advanced indexing and search algorithms,
aggregations, and stochastics in order to provide the most complete
insight into real-time audience demographics.
[0048] The exemplary process details providing analytics based on
the real-time analysis of the proximate audience (e.g., approaching
users, crowd, and so on). The central server 26 can determine if
the approaching user is recurring or a "new visitor" based on
aggregations of all the above-mentioned metrics. Stated in another
way, the frequency of a user's visits is determined by creating a
digital "footprint" of the user based on the metrics collected. In
some embodiments, personal data is not stored, and the digital
identifiers stored are associated with a particular MAC address.
MAC addresses and devices can be aggregated based on a time slot
(e.g., recent time slots include the last two minutes).
[0049] Each reading from the relevant time slot can be filtered by
signal strength to determine mobile devices that are in actual
proximity. These devices can be further filtered beginning from the
current time slot and extending to an N-minute period after that
(usually 24 hours in the past), which is in turn fully
configurable. This can be used to determine whether a user is a
recurring visitor. For additional security, digital identifiers can
be encrypted and/or hashed.
[0050] Displayed in FIG. 4 is a building location 42. The building
location 42 includes a number of network transceivers 24. The
sequence steps 400-410 illustrate a single person's path through
the store as mapped and rendered by the motion of their mobile
device 22.
[0051] In sequence 400, the user enters the building location 42,
goes straight past the first display 44A, and stops at the second
display 44B. The analytic data derived from this can be that this
one user of many was not interested in the display 44A. Instead,
this user's interests were elsewhere.
[0052] In sequence steps 402 through 406, the user is tracked
weaving through aisles. A marketer seeing this data can make
determinations about the traffic flow in the store to potentially
improve the natural routing of customers through the store. In
sequence 408, the user has obtained what they intend to purchase
and heads to the register, pays. In step 410 the user leaves.
[0053] The analytics also indicate how long the user spent at the
register, and if they were in line, how the line was bunching up.
This data can be used to further improve the orientation or
management of the building location 42.
[0054] FIG. 5 is an exemplary top-level block diagram illustrating
an embodiment of a mobile detection system integrated with a
security system 48. Here, the mobile device 22 further includes
installed client software 46. This embodiment differs from prior
discussed embodiments where no such software was necessary in order
for data to be collected. The client software 46 is not necessary
for the security system 48 to work, but is one embodiment. What is
necessary is that the security system is able to recognize whether
the given mobile device 22 is associated with a given person or
unknown through an IFF (identification friend or foe).
[0055] This can be done through a client application 46 programmed
to embed the IFF data in the information that the user expects the
network transceiver 24 to collect through the described "sniffing"
process. As noted, the network transceivers 24 collect application
names. The client application 46 is programmed to rename itself to
a code which will be recognized as an IFF signal. Alternatively,
the security system 48 may include a whitelist of MAC addresses,
wherein no client application 46 is necessary, and the IFF signal
is instead merely the MAC address.
[0056] Here, data collected in the application server 26 is
analyzed, and directions are sent by the application server 26 to
the security system 48 in order to cause security actions to occur
(e.g., inform law enforcement, automatically lock doors, turn on
lights, deliver messages, turn on cameras, activate traps,
etc.).
[0057] FIG. 6 is an illustrative implementation of a mobile device
tracking system integrated with a security system 48. Here, there
is a user property 50. The user property may be any number of
buildings: a domicile/house, an office building after hours, a
bank, a military installation, or other region for which ingress
and egress may be restricted. A number of sample stories are
illustrated below for the technology addressed herein.
[0058] The mobile device 22A enters the user property 50 through a
window. The velocity of the device 22A shows ingress instead of
egress, implying possible unauthorized entry. The security system
48 may first check for an IFF signal, wherein the absence of the
signal may trigger the system. In a domicile, this may be a
burglar. The security system can capture the burglar's phone data,
turn on security cameras, and call the police. Similar actions can
be taken if an unknown device 22A is milling around outside the
window.
[0059] The mobile device 22B leaves through a window. Similarly, in
a domicile, this is not generally considered normal. Potentially,
"little Timmy" is sneaking out when he should not be. In addition
to the velocity of mobile device 22B, the time of day can be taken
into account for such actions. Hypothetically, Timmy is allowed to
leave through his window to get to his tree house during daylight,
but not at 2:00 a.m. Here, even if an IFF signal is received, some
other condition may override the IFF signal. Alternatively, IFF
signals may not all be created equal. Mobile devices owned by
Timmy's parents may not trigger the security system 48, while the
mobile device 22B owned by Timmy does. In this circumstance, the
security system 48 may send a text message to Timmy's parent's
mobile devices, and the parents then head outside to confront the
little miscreant.
[0060] The mobile device 22C enters straight through the front door
of the user property 50. If the user property 50 is a business
which should not be receiving visitors at 2:00 a.m., the security
system 48 may be triggered. It is possible that the mobile device
22C has been previously tracked loitering around the user property
50 before. Upon that same device 22C approaching the main entrance,
or any other entrance, the security system 48 is triggered.
[0061] The mobile device 22D is headed towards a valued zone 52. As
before, an IFF signal may prevent the security system 48 from being
triggered. Alternatively, without an IFF signal, and given a set of
behavior/loitering in the valued zone 52, the security system 48
may trigger. Example actions include locking surrounding doors or
dropping a cage trap over the valued zone 52, thereby sealing a
thief in to await the authorities.
[0062] FIG. 7 is a flowchart illustrating a method of tracking a
mobile device integrated with a security system. Similar to FIG. 3,
the network transceivers 24 collect one or more data points about
the mobile devices 22 within range. In step 906, if a mobile device
22 suddenly vanishes from tracking that was expected to vanish
based on predetermined security profiles, a potential security
action may occur in step 712.
[0063] Alternatively, in step 710, a plotted path (both present and
historical) of a mobile device 708 is compared to danger profiles.
In step 712, if a danger profile appears to have been met, or if a
mobile device 22 mysteriously vanished that shouldn't have, the
security system 48 may trigger.
[0064] In step 714, if the security system 48 triggers, the system
must determine an appropriate action. Actions are chosen based upon
which danger profile was matched and what kind of user property 50
is being monitored. In step 716, the chosen action is executed by
the security system 48.
[0065] A simple embodiment of the technique uses a single network
transceiver 24 in a user property 50. The single transceiver 24
counts mobile devices 22 within range (and inside the user property
50). In such an embodiment, the network transceiver may alert a
user that large numbers of mobile devices are present when perhaps
they should not be. An example of such an occasion is in the rental
property market. A property owner will rent out property and guests
will come to stay in the property. In some cases, guests will
invite a number of unauthorized individuals to enter the property
(e.g., when throwing a party). Such circumstances can cause severe
damage to the property. The damage may be physical or reputational
(involving local law enforcement).
[0066] The effectiveness of tracking visitors depends largely on
the visitors being unaware they are being tracked, or at the very
least, unaware of the means employed to track them. The network
transceiver 24 may be an unobtrusive black box with little to no
markings in order to be inconspicuous. In some embodiments, the
network transceiver 24 may connect to a local network (for
communication to the application server 26) wirelessly in order to
function while placed in a locked/hidden container, closet, or
room.
[0067] FIG. 8 is a flowchart illustrating a method for visitor
counting. In step 802, the network transceiver detects connection
requests from mobile devices. This step proceeds similarly to the
detection described in FIG. 2. The network requests may come over
WiFi or other wireless networks (such as Bluetooth or cellular). In
step 804, the network transceiver identifies unique device
identifiers (such as a MAC address). In some embodiments, certain
mobile devices will be ignored based on the unique identifier. In
some embodiments, some devices with low RSSI values may also be
ignored.
[0068] In embodiments where the purpose is to track mobile phones,
MAC addresses associated with manufacturers that do not manufacture
mobile phones are ignored. Further, some manufacturers use the MAC
address schema to assign identifiers. In those cases, the scheme
may be used to determine whether or not a device is a mobile phone.
The network transceiver uses schema related to known devices in
order to interpret the identifier data being transmitted by local
mobile devices. An example where this is relevant is where a guest
brings both a mobile phone and a laptop to a rental property.
Rather than have that guest appear as "two" guests, the network
transceiver may be programmed to ignore the laptop.
[0069] For these steps, it is unnecessary for the network
transceiver to store or keep the identifiers. The most important
element of the step is to identify a number of unique guest devices
based on an identifier. In step 806, the network transceiver
ignores device identifiers associated with resident devices.
Resident devices are devices that are always or nearly always
detected by the network transceiver. There are a number of ways to
filter for resident devices. One such way is to record the resident
devices into the programming of the network transceiver (this may
be achieved through the use of user application software) in order
to generate an IFF list. Another way is to determine that a given
device (as identified by a unique identifier) is a resident device
is if that device is detected at a certain frequency (e.g., eight
or more hours a day for a week). A third manner of ignoring
resident devices is for the user to merely know how many resident
devices there are and alter a setting to reduce the total device
count by that number.
[0070] In step 808, once devices are counted and resident devices
have been filtered out of count, the network transceiver has an
accurate count of guest devices. In step 810, the network
transceiver transmits the guest count to the web server. In some
embodiments, steps 808 and 810 are reversed. Rather, the wireless
communicator transmits the device identifiers to the web server,
and the web server generates the device count. To address device
privacy concerns, the actual device identifiers may be hashed prior
to transmission to the web server such that the web server never
has the actual device identifiers. In some embodiments, only a
portion of the device identifier (MAC address) is hashed. For
example, the portion of the MAC address that identifies a
manufacturer may be left unchanged, while the unique device ID is
hashed to protect visitor privacy. The identity of the manufacturer
may be used to determine whether or not a given device is a mobile
phone or some other type of wireless device (e.g., a laptop
computer). Where a given manufacturer markets both mobile phones
and other devices, other criteria may determine device type. For
example, where a device maintains the same signal strength (RSSI)
for long periods of time, it suggests the device is not moving, and
thus is unlikely to be a mobile phone.
[0071] In step 812, the web server compares the count of guest
devices to a threshold set by a user application. In step 814,
where the threshold is exceeded, the web server sends a
notification to a user application on a user device. This
notification may include push notifications within a registered web
application or text messages. Other notifications may include a
trigger for an "internet-of-things" device such as a security
camera or a security system. There may also be more than one
threshold. For example, there may be one threshold for too many
people, and another for none. A reason for having a zero threshold
is for the owner to know when a rental property has become empty in
order to facilitate the scheduling of cleaning services.
[0072] Separate from the threshold, in step 816, the web server
transmits the guest count to a user application on a user device.
In step 816, the user application renders the guest count on the
user device. In this way, the user (property owner) may always
check in on the number of guests (or guest devices) on their
property through a GUI on a user device.
[0073] FIG. 9 is an illustration diagram of a visitor counting
system in accordance with FIG. 10. The block diagram includes a
user property 50 including a network transceiver 24. Depicted in
the figure, the user property includes three mobile devices 22G-I
and one resident device 56. The network transceiver 24 communicates
with an application server 26. The application server 26 in turn
communicates with a user's application software 58 on a user device
60.
[0074] The network transceiver 24 detects each of the three mobile
devices 22G-I, as well as the resident device 56. The resident
device 56 is ignored from the count that network transceiver 24
transmits and which eventually reaches the user device 60.
Accordingly, the visitor count of FIG. 9 is three. There may be
fewer or greater actual visitors at the user property 50, though
"three" is an acceptable approximation. The application software 58
renders this count whenever requested by the user. The count is
constantly updated as the network transceiver 24 informs the
application server 26.
[0075] Where a threshold is established at "four," the addition of
one more mobile device 22 will cause application server 26 to issue
a notification to the application software 58 that the threshold
has been exceeded. Conversely, if a threshold is established at
"zero," when mobile devices 22G-I all leave the range of the
network transceiver 24, and the network transceiver 24 informs the
application server 26 of the new count, the application server 26
will transmit a notification to the user device 60.
[0076] In some embodiments, the user property 50 would include more
than one network transceiver 24. Where the user property 50 is
excessively large, such that the range of a single network
transceiver 24 cannot service the entire user property 50,
additional network transceivers 24 may be employed. In these
embodiments, the network transceivers 24 add individually detected
mobile devices 22 and filtering for unique device identifiers
(e.g., MAC addresses) in order to determine a total visitor
count.
[0077] FIG. 10 is a flowchart illustrating a method for managing a
visitor counting system with a calendar. As previously discussed,
the technique disclosed herein may include the use of multiple
thresholds. The application software can configure each threshold
to be active at a time determined by additional user input. The
additional user input may be the use of an export calendar or an
API providing a direct interface between the application software
and rental management software. In this manner, calendar events may
be used to configure the use of each threshold.
[0078] In step 1002, the application software sets a number of
thresholds via user interaction with a GUI. The user inputs
settings and conditions as to where each threshold would apply.
Examples of calendar-based conditions include guest checking in,
guest checking out, maid service arriving, scheduled empty,
scheduled for owner use, and other suitable calendar-based
distinctions known in the art. In step 1004, the application server
examines the user inputted calendar. As previously described, the
calendar may come from an upload or a direct communications
interface between the application server of the visitor counting
technique and another application server.
[0079] In step 1006, the application server determines if a first
or second calendar condition is satisfied. In step 1008, where the
first calendar condition is satisfied, the application server
employs a first threshold. In step 1010, where the second calendar
condition is satisfied, the application server employs a second
threshold. In steps 1012 and 1014, the network transceiver
establishes a device count ignoring resident devices. The device
count occurs regardless of the threshold employed. In steps 1016
and 1018, the application server checks each respective visitor
count against the employed threshold. In step 1020, where the
threshold is exceeded, the application server forwards a
notification to the user device.
[0080] For example, a user may have an upcoming reservation of
their rental property. The property can accommodate six people. The
user sets a threshold for the reservation time of lower than
approximately six (the user may want to accommodate for multiple
devices). When that reservation time arrives, the application
server begins using the determined threshold for the reservation
(approximately six).
[0081] When the calendar has a scheduled check out day, a new
threshold may be generated. At this point, the user is interested
in scheduling a maid service. Thus, a threshold of less than one
lets the user know when the guests have cleared out. In this
manner, the user may then call the maid service to go and
clean.
[0082] A third threshold may be established based on multiple
conditions. Those conditions may be: (1) the calendar indicates a
check out day and (2) the "less than 1" threshold has already been
triggered that day. Using these two conditions, the application
server may set up a third threshold for the cleaning staff (e.g.,
greater than 3). A fourth threshold may be similarly established,
based on: (1) the calendar indicates a check out day and (2) the
"cleaning staff" threshold has already been triggered that day,
thus the application server establishes a fourth threshold for an
empty property (e.g., greater than zero) that watches for
burglars.
[0083] FIG. 11 is an illustration of a system for managing numerous
properties with an integrated system of visitor counters. Depicted
in FIG. 11 are a number of user properties 50A-G. The user
properties are divided into three groups: Group A, Group B, and
user property 50D (positioned alone). In some embodiments, a user
owns a number of rental properties. Adjusting thresholds for a
number of properties can be onerous. Thus, the application software
58 may control settings and configurations for multiple user
properties at once via the application server 26.
[0084] FIG. 12 is a block schematic diagram of a system in the
exemplary form of a computer system 1400 within which a set of
instructions for causing the system to perform any one of the
foregoing methodologies and logical flows may be executed.
[0085] The computer system 1200 includes a processor 1202, a main
memory 1204, and a static memory 1206, which communicate with each
other via a bus 1208. The computer system 1200 also includes an
output interface 1214; for example, a USB interface, a network
interface, or electrical signal connections and/or contacts;
[0086] The disk drive unit 1216 includes a machine-readable medium
1218 upon which is stored a set of executable instructions, i.e.,
software 1220, embodying any one, or all, of the methodologies
described herein. The software 1220 is also shown to reside,
completely or at least partially, within the main memory 1204
and/or within the processor 1202. The software 1220 may further be
transmitted or received over a network by means of a network
interface device 1214.
[0087] In contrast to the system 1200 discussed above, a different
embodiment uses logic circuitry instead of computer-executed
instructions to implement processing entities. Depending upon the
particular requirements of the application in the areas of speed,
expense, tooling costs, and the like, this logic may be implemented
by constructing an application-specific integrated circuit (ASIC)
having thousands of tiny integrated transistors. Such an ASIC may
be implemented with CMOS (complementary metal oxide semiconductor),
TTL (transistor-transistor logic), VLSI (very large systems
integration), or another suitable construction. Other alternatives
include a digital signal processing chip (DSP), discrete circuitry
(such as resistors, capacitors, diodes, inductors, and
transistors), field programmable gate array (FPGA), programmable
logic array (PLA), programmable logic device (PLD), and the
like.
[0088] It is to be understood that embodiments may be used as or to
support software programs or software modules executed upon some
form of processing core (such as the CPU of a computer) or
otherwise implemented or realized upon or within a system or
computer readable medium. A machine-readable medium includes any
mechanism for storing or transmitting information in a form
readable by a machine, e.g., a computer. For example, a
machine-readable medium includes read-only memory (ROM); random
access memory (RAM); magnetic disk storage media; optical storage
media; flash memory devices; electrical, optical, acoustical or
other form of propagated signals such as carrier waves, infrared
signals, digital signals, etc.; or any other type of media suitable
for storing or transmitting information.
[0089] Further, it is to be understood that embodiments may include
performing operations and using storage with cloud computing. For
the purposes of discussion herein, cloud computing may mean
executing algorithms on any network that is accessible by
internet-enabled or network-enabled devices, servers, or clients
and that do not require complex hardware configurations (e.g.,
requiring cables and complex software configurations, or requiring
a consultant to install). For example, embodiments may provide one
or more cloud computing solutions that enable users, e.g., users on
the go, to access real-time video delivery on such internet-enabled
or other network-enabled devices, servers, or clients in accordance
with embodiments herein. It further should be appreciated that one
or more cloud computing embodiments include real-time video
delivery using mobile devices, tablets, and the like, as such
devices are becoming standard consumer devices.
[0090] The described embodiments are susceptible to various
modifications and alternative forms, and specific examples thereof
have been shown by way of example in the drawings and are herein
described in detail. It should be understood, however, that the
described embodiments are not to be limited to the particular forms
or methods disclosed, but to the contrary, the present disclosure
is to cover all modifications, equivalents, and alternatives.
* * * * *