U.S. patent application number 15/948415 was filed with the patent office on 2018-08-16 for systems and methods for firearms monitoring and awareness using highly dynamic wireless ad-hoc networks.
The applicant listed for this patent is Dahrwin LLC. Invention is credited to Justin Tyler Corinella.
Application Number | 20180232221 15/948415 |
Document ID | / |
Family ID | 51062036 |
Filed Date | 2018-08-16 |
United States Patent
Application |
20180232221 |
Kind Code |
A1 |
Corinella; Justin Tyler |
August 16, 2018 |
SYSTEMS AND METHODS FOR FIREARMS MONITORING AND AWARENESS USING
HIGHLY DYNAMIC WIRELESS AD-HOC NETWORKS
Abstract
Systems and methods for monitoring and accessing the status of a
firearm that are adapted to communicate via a mesh network are
disclosed. In embodiments, a method for monitoring unauthorized
access of a firearm includes receiving an electronic key that is
input to request access to the firearm, determining whether a
request to access the firearm is granted based on whether the
electronic key that is input authorizes access, and, if access is
not authorized, transmitting a notification to a destination
device, such as, for example, a destination device associated with
a user of the firearm or law enforcement, using a direct gateway
connection if available, or transmitting the notification via a
mesh network if no direct gateway connection is available.
Inventors: |
Corinella; Justin Tyler;
(Brooklyn, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Dahrwin LLC |
Wilmington |
DE |
US |
|
|
Family ID: |
51062036 |
Appl. No.: |
15/948415 |
Filed: |
April 9, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14156214 |
Jan 15, 2014 |
9940118 |
|
|
15948415 |
|
|
|
|
13403966 |
Feb 23, 2012 |
8774147 |
|
|
14156214 |
|
|
|
|
61868404 |
Aug 21, 2013 |
|
|
|
61772510 |
Mar 4, 2013 |
|
|
|
61764586 |
Feb 14, 2013 |
|
|
|
61764450 |
Feb 13, 2013 |
|
|
|
61752501 |
Jan 15, 2013 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 4/21 20180201; H04W
76/10 20180201; G06F 8/61 20130101; H04W 4/50 20180201; H04W 84/18
20130101 |
International
Class: |
G06F 8/61 20180101
G06F008/61; H04W 4/21 20180101 H04W004/21; H04W 76/10 20180101
H04W076/10; H04W 4/50 20180101 H04W004/50 |
Claims
1. A method for monitoring for an unauthorized access of a firearm,
wherein the firearm includes a transceiver, one or more processors,
and a discriminator that limits activation of the firearm to one or
more authorized users, the method comprising the steps of: (a)
receiving, by the one or more processors from a user interface that
is in communication with the firearm, a request to access the
firearm based on an input of an electronic key; (b) determining, by
the discriminator, whether or not the received request to access
the firearm is authorized based at least on whether the electronic
key that is input is authorized to access the firearm; and (c)
transmitting, by the firearm to a destination device upon a
determination by the one or more processors that an attempt to
access the firearm is not authorized, a notification via at least
one of a direct gateway or a mesh network comprising neighboring
devices or nodes to alert the destination device of the
unauthorized attempt to access the firearm; wherein the step of
transmitting the notification comprises: (i) determining, by the
one or more processors, whether the direct gateway connection is
available, (ii) transmitting, from the firearm to the destination
device via the direct gateway connection, the notification related
to the attempt for unauthorized access of the firearm when it is
determined that the direct gateway connection is available; and
(iii) transmitting, from the firearm to one or more of the
neighboring devices or nodes of the mesh network, the notification
related to the attempt for unauthorized access of the firearm when
it is determined that the direct gateway connection is
unavailable.
2. The method of claim 1, wherein the notification that is
transmitted to the destination device is transmitted via the direct
gateway connection as one of a voice call, a text message, or an
electronic fax.
3. The method of claim 1, wherein the one or more of the
neighboring devices or nodes of the mesh network is any of a mobile
phone, smart phone, personal digital assistant, wearable electronic
device, music player device, calculator device, gaming console,
wall-charging unit, DC power node, light bulb, laptop computer,
desktop computer, tablet device, interactive appliance, navigation
device, drone, and/or interactive billboard.
4. The method of claim 1, wherein the user interface that is in
communication with the firearm is implemented in or on a firearm
carrying case, a magazine clip usable with the firearm, or a
firearm accessory; and wherein the step of receiving, by the one or
more processors from the user interface that is in communication
with the firearm, a request to access the firearm based on the
input of the electronic key comprises receiving the request that is
entered at the user interface.
5. The method of claim 4, wherein the user interface comprises a
biometric scanner, and the step of receiving the request to access
the firearm comprises receiving biometric data entered at the
biometric scanner.
6. The method of claim 1, further comprising transmitting, by the
firearm to the destination device, a second notification regarding
at least one of an authorized access of the firearm, a movement of
the firearm, a loading of the firearm, and a firing of the
firearm.
7. The method of claim 1, further comprising: (d) receiving, at the
first firearm, a second notification regarding a status change
comprising at least one of an authorized access of a second
firearm, a removal of the second firearm from a carrying case
without authorization, a loading of the second firearm, and a
firing of the second firearm; and (e) transmitting, by the first
firearm to a destination device, a third notification via at least
one of the direct gateway or the mesh network to alert the
destination device of the status change.
8. The method of claim 1, wherein the destination device is
associated with an entity that monitors unauthorized access of
firearms.
9. The method of claim 1, wherein the destination device is
associated with an authorized user of the firearm of which
unauthorized access has been requested.
10. The method of claim 1, wherein the electronic key comprises at
least one of a fingerprint, a voice print, a code, and an
electronic tag.
11. The method of claim 1, wherein the authorized user of the
firearm comprises a single authorized user or a group of authorized
users.
12. The method of claim 1, wherein the electronic key uses at least
one of a fingerprint, a voice print, a code, and an electronic
tag.
13. The method of claim 1, wherein the firearm is one of a hand
gun, a rifle, a shotgun, and a machine gun.
14. A method for monitoring for an unauthorized access of a
firearm, wherein the firearm includes a first transceiver, and a
first set of one or more processors, and wherein the firearm is
associated with a second device in communication with the firearm,
wherein the second device includes a second transceiver, and a
second set of one or more processors: the method comprising the
steps of: (a) receiving, by the second set of one or more
processors at the second device from the firearm, a first
notification that the firearm has been accessed and an indication
as to whether the access was authorized or not authorized, wherein
the first notification is based at least on a determination, by the
first set of one or more processors at the firearm, as to whether
an electronic key of an authorized user was input for accessing the
firearm; and (c) transmitting, by the second device to a
destination device upon a determination by the one or more
processors that the access the firearm was not authorized, a second
notification via at least one of a direct gateway or a mesh network
comprising neighboring devices or nodes to alert the destination
device of the unauthorized access to the firearm; wherein the step
of transmitting the second notification comprises: (i) determining,
by the second set of one or more processors, whether the direct
gateway connection is available, (ii) transmitting, from the second
device to the destination device via the direct gateway connection,
the second notification related to the unauthorized access of the
firearm when it is determined that the direct gateway connection is
available; and (iii) transmitting, from the second device to one or
more of the neighboring devices or nodes of the mesh network, the
second notification related to the unauthorized access of the
firearm when it is determined that the direct gateway connection is
unavailable.
15. The method of claim 14, wherein the second device is a firearm
carrying case for the firearm.
16. The method of claim 14, wherein the second device is a magazine
clip.
17. The method of claim 14, wherein the second device is a firearm
accessory.
18. A method for monitoring a firearm status change of a first
firearm in a firearm network that comprises a plurality of
firearms, including at least the first firearm and a second
firearm, that communicate via a mesh network, wherein each of the
plurality of firearms in the firearm network includes a
transceiver, and one or more processors, the method comprising the
steps of: (a) receiving, at the first firearm via the mesh network,
a first notification regarding a firearm status change at the
second firearm; and (b) transmitting, by the first firearm to a
destination device, a second notification via at least one of a
direct gateway or the mesh network to alert the destination device
of the firearm status change; wherein the step of transmitting the
second notification comprises: (i) determining, by the respective
one or more processors at the first firearm, whether the direct
gateway connection is available, (ii) transmitting, from the first
firearm to the destination device via the direct gateway
connection, the second notification related to the firearm status
change when it is determined that the direct gateway connection is
available; and (iii) transmitting, from the first firearm to one or
more of the neighboring devices or nodes of the mesh network, the
second notification related to the firearm status change when it is
determined that the direct gateway connection is unavailable.
19. The method of claim 18, wherein the firearm status change
comprises an unauthorized access of a second firearm.
20. The method of claim 18, wherein the firearm status change
comprises an authorized access of the second firearm.
21. The method of claim 18, wherein the firearm status change
comprises a removal of the second firearm from a carrying case
without authorization.
22. The method of claim 18, wherein the firearm status change
comprises a loading of the second firearm.
23. The method of claim 18, wherein the firearm status change
comprises a firing of the second firearm in proximity to the first
firearm.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation and claims the benefit of
and priority to U.S. patent application Ser. No. 14/156,214, filed
Jan. 15, 2014, which is a continuation-in-part and claims the
benefit of and priority to U.S. patent application Ser. No.
13/403,966, filed Feb. 23, 2012, issued as U.S. Pat. No. 8,774,147
on Jul. 8, 2014, and which claims the benefit of and priority to
U.S. Provisional Patent Application No. 61/868,404, filed Aug. 21,
2013, U.S. Provisional Patent Application No. 61/772,510, filed
Mar. 4, 2013, U.S. Provisional Patent Application No. 61/764,586,
filed Feb. 14, 2013, U.S. Provisional Patent Application No.
61/764,450, filed Feb. 13, 2013, and U.S. Provisional Patent
Application No. 61/752,501, filed Jan. 15, 2013. The contents of
each of these patent applications are incorporated by reference
herein in their entirety as if fully set forth herein.
FIELD
[0002] The disclosure generally relates to systems, methods and
devices for deploying a highly dynamic wireless ad-hoc network. In
embodiments, the systems, methods and devices monitor the presence
and/or use of network compatible firearms. In embodiments, the
systems, methods and devices can function autonomously, in which
all network nodes share the same role functions based on their
capabilities. In embodiments, the disclosure also generally relates
to various applications than can be deployed on such a network.
SUMMARY
[0003] The disclosure generally relates to systems, methods and
devices for deploying a highly dynamic wireless ad-hoc network.
[0004] In exemplary embodiments, a firearm monitoring or awareness
network may be implemented using ad hoc highly dynamic mesh
networks. The firearm network may detect the presence, absence,
and/or the use of compatible firearms.
[0005] In exemplary embodiments, a wireless ad hoc mesh network may
be implemented. The wireless ad hoc mesh network may include a
plurality of nodes which can function autonomously and where each
node shares the same functionalities or capabilities. The nodes may
each act as client/server so as to be able to perform all the
routing functions of the mesh network. The mesh network may
transmit data through multiple paths. The mesh network may further
transmit data by splitting a packet stream into fragmented packets
and routing the packets through multiple alternating paths.
[0006] In exemplary embodiments, an API for participation in a mesh
network stored on a first device may be distributed without a
central provider. The distribution of such an API may propagate a
mesh network. The presence of a first device may be detected on a
second mobile device. The second mobile device may wirelessly
connect to the first device. A web browser application may be
accessed on the second mobile device. Using the web browser on the
second mobile device, a DNS implementation on the first device may
be accessed on the second mobile device. The second mobile device
may receive display data from the first device for display in the
web browser on the second mobile device. The display data may
comprise or otherwise be used to generate a splash screen or other
graphical user interface. The second mobile device may submit an
electronic request for a machine-readable API from the first
device, which may be stored in first device memory of the first
device. The machine-readable API from the first device may be
downloaded at the second mobile device and stored in second device
memory. The machine-readable API may be installed on the second
mobile device to be run on one or more processors.
[0007] In embodiments, the second mobile device, using the
installed machine-readable API, may connect via a wireless
connection to the first device.
[0008] In embodiments, the second mobile device, using the
installed machine-readable API, may connect via a wireless
connection to a third device.
[0009] In embodiments, the process can be repeated, e.g., with a
third mobile device and the second mobile device, to distribute the
API from the second device to the third device. Accordingly, the
API may be distributed to any number of available devices, such as
a third device, a fourth device, etc. The API may be distributed
from any device having the API to any device not yet having the API
or not yet having the same version of the API.
[0010] In embodiments, any device with the API installed may
communicate with any other device having the API installed and/or
within range (e.g., transmission distance) of nodes in the
resulting mesh network.
[0011] In embodiments, the second mobile device may communicate
with the first device using the installed machine-readable API.
[0012] In embodiments, the second mobile device may communicate
with a third device using the installed machine-readable API.
[0013] In embodiments, the second mobile device may receive from
the first device using the installed machine-readable API, an
advertisement.
[0014] In embodiments, the first device may be any of a mobile
phone, smart phone, personal digital assistant, wearable electronic
device, music player device, calculator device, gaming console,
television, stereo, wall-charging unit, DC power node, light bulb,
laptop computer, desktop computer, tablet device, interactive
appliance, navigation device, drone, and/or interactive
billboard.
[0015] In embodiments, the second mobile device may be a cell
phone, smartphone, personal digital assistant ("PDA"), wearable
electronic device, portable computer, laptop computer, tablet
computer, GPS device, music player device, portable video game
system, gaming console, calculator device, wall-unit node, DC power
node, special purpose device, and/or drone to name a few.
[0016] In embodiments, the wireless connection may be created via
at least one of Wi-Fi, Wi-Fi Direct, Bluetooth, Bluetooth Low
Energy, near field communication, infrared, microwave, radio wave,
and/or cellular data.
[0017] In embodiments, the application programming interface may
comprise any of a game, a communications platform, an information
access platform, an information receiving platform, an advertising
platform, a social media application, and/or a platform to access
and/or provide mesh capabilities to non-mesh third party
applications.
[0018] In embodiments, a mesh network may be propagated from a
first device having an API stored on a removable memory device. A
second device may detect a mesh network from a first device. The
second device may connect to the first device via a wireless
connection. The second device may send to the first device an
electronic request for a machine-readable API stored in removable
memory of the first device. The second device may download into
second device memory of the second device the machine-readable API
from the first device. The second device may install the
machine-readable API to be run on one or more processors of the
second device. The second device may connect to the first device
via the wireless connection using the installed machine-readable
API.
[0019] In embodiments, the first device may be a gaming console,
wall-charging unit, DC power node, light bulb, desktop computer,
interactive appliance, navigation device, drone, and/or interactive
billboard.
[0020] In embodiments, the second device may be any of a mobile
phone, smart phone, personal digital assistant, wearable electronic
device, music player device, calculator device, gaming console,
wall-charging unit, DC power node, light bulb, laptop computer,
desktop computer, tablet device, interactive appliance, navigation
device, drone, and/or interactive billboard.
[0021] In embodiments, wherein the removable memory device of the
first device can comprise any of an SD card, Micro SD card, USB
drive, flash memory device, and/or solid state memory device.
[0022] In exemplary embodiments, a node of the mesh network can
comprise an application layer, an application controller and
routing libraries, and a network controller. The application layer
may contain one or more individual applications which utilize the
mesh network. The applications can pass a set of prioritized
attributes to the application controller. The application
controller may correlate the application's set of desired
attributes, so as to implement the appropriate routing protocol
which may be contained inside of a Protocol Library. The routing
protocols implemented may include, for example, proactive,
reactive, hybrid, delay tolerant store and forward mechanisms,
neural networks, graph partitioning schemes, Redundant Dynamic
Protocol, to name a few.
[0023] In exemplary embodiments, the network controller may
actively maintain a full or partially distributed asynchronous
network topology, which may include tracking the overall state of
the network, monitoring bandwidth usage by overlying third party
applications, and providing neighbor quality evaluations (based off
connection qualities, self-evaluations, and relevant time function)
for each node.
[0024] In exemplary embodiments, the components (e.g., the
application layer, the application controller, and the network
controller) may interact with each other, and one or more third
party applications through an interface. The framework of the mesh
network allows components to be added or deleted easily. The mesh
network may be implemented as downloadable platform.
[0025] In exemplary embodiments, the network may implement
redundant and parallel gateway mechanisms by utilizing, for
example, multiple backhaul nodes concurrently.
[0026] In exemplary embodiments, the network may provide location
based services, by utilizing, for example, radio wave propagation,
GPS, and triangulation, to name a few.
[0027] In exemplary embodiments, the application-oriented virtual
subnets may be utilized to implement social profiling and
advertising, by utilizing, for example, predefined templates and/or
available social networking data.
[0028] In exemplary embodiments, the network may implement security
mechanism, including, for example, MAC Address spoofing,
public/private key encryption, and/or data transmission
thresholds.
[0029] In exemplary embodiments, the mesh network may be used in
applications, such as, for example, chatting applications, social
network/social discovery applications, multiplayer gaming, utility
applications (e.g., lighting), vehicular/automotive (e.g.,
collision avoidance), resource and media sharing, information and
activity collaboration, network gaming, personal/consumer crowd
sourcing, business social media, military, transportation,
utilities, public education, healthcare, commercial monitoring,
safety, and control systems, hospitality, wireless enterprise,
municipal networks, general bypass and extensions of mobile,
broadband, and Wi-Fi networks, to name a few.
[0030] In exemplary embodiments, the node devices may be
self-autonomous relay node devices. The nodes may include card
readers, such as one or more SD card readers, and one or more
wireless cards (e.g., SD cards). A node may include a card reader
custom built to fit and be powered by a wall socket and the like.
The card reader can read and execute the instructions of from an
inserted SD card. In some embodiments an SD card can be used that
includes a slot that accepts a separate wireless card, such as, a
wireless micro SD card. The card reader with the SD card can access
and therefore send/receive data via the radios of both the SD and
micro SD cards.
[0031] In exemplary embodiments, the nodes may be used in a variety
of settings such as an office environment to provide connectivity
between devices such as desktops, laptops, monitors, printers, and
the like, as well as function as relays in the wireless mesh
network.
DESCRIPTION OF THE DRAWINGS
[0032] The features and advantages of the present disclosure will
be more fully understood with reference to the following, detailed
description when taken in conjunction with the accompanying figure,
wherein:
[0033] FIG. 1 illustrates a diagram of an exemplary wireless
network architecture.
[0034] FIG. 2 illustrates the network-level components of a node in
a mesh network according to an exemplary embodiment of the present
disclosure.
[0035] FIGS. 3A-D illustrate changes to highly dynamic wireless ad
hoc networks according to an exemplary embodiment of the present
disclosure.
[0036] FIGS. 4A-D illustrate changes to highly dynamic wireless ad
hoc networks according to an exemplary embodiment of the present
disclosure.
[0037] FIGS. 5A and 5B are schematic diagrams of a social media
platform according to exemplary embodiments of the present
disclosure.
[0038] FIG. 6 illustrates a flow diagram describing a method for
transmitting packets in a mesh network according to an exemplary
embodiment of the present disclosure.
[0039] FIG. 7 illustrates a flow diagram describing a method for
retransmitting packets in a mesh network according to an exemplary
embodiment of the present disclosure.
[0040] FIG. 8A is a schematic diagram of an exemplary node device
according to an exemplary embodiment of the present invention.
[0041] FIGS. 8B and 8C illustrate exemplary nodes according to
exemplary embodiments of the present disclosure.
[0042] FIG. 9 illustrates exemplary components of a node according
to an exemplary embodiment of the present disclosure.
[0043] FIG. 10A is a flow chart of a process for obtaining an API
for connecting mobile devices according to an exemplary embodiment
of the present invention.
[0044] FIGS. 10B-F are schematic diagrams of devices performing a
process for distributing an API in a mesh network according to an
exemplary embodiment of the present invention.
[0045] FIGS. 11A-E are exemplary screen shots of a process to
obtain an API for connecting mobile devices according to an
exemplary embodiment of the present invention.
[0046] FIGS. 12A-D are exemplary screen shots of an application for
management of neighboring devices in a mesh network according to an
exemplary embodiment of the present invention.
[0047] FIGS. 13A-D are exemplary screen shots of an application
providing ad-hoc mesh network communications according to an
exemplary embodiment of the present invention.
[0048] FIG. 14 is an exemplary screen shot of an application for
broadcasting communications over a mesh network according to an
exemplary embodiment of the present invention.
[0049] FIG. 15 is a schematic diagram of a mesh network with an
interactive billboard as a participating node according to an
exemplary embodiment of the present invention.
[0050] FIG. 16 illustrates a diagram of components of a smart
firearm according to an exemplary embodiment of the present
disclosure.
[0051] FIG. 17 illustrates a smart firearm authentication process
according to an exemplary embodiment of the present disclosure.
[0052] FIG. 18 illustrates an exemplary communication process for a
smart firearm network according to an exemplary embodiment of the
present disclosure.
[0053] FIG. 19A illustrates smart firearms according to an
exemplary embodiment of the present disclosure.
[0054] FIG. 19B illustrates a smart firearm with an exemplary
section revealed according to an exemplary embodiment of the
present disclosure.
[0055] FIG. 20 illustrates an exemplary smart firearm case
according to an exemplary embodiment of the present disclosure.
[0056] FIGS. 21A and 21B illustrate exemplary environments
including a mesh network according to an exemplary embodiment of
the present disclosure.
[0057] FIG. 22 illustrates an exemplary method for notifying an
alert in a mesh network according to an exemplary embodiment of the
present disclosure.
DETAILED DESCRIPTION
[0058] A mesh network can comprise decentralized end-user relay
nodes which are capable of functioning autonomously from other
networks, including internet service providers, or any other third
party or subsidiary systems e.g., any type of access points or
routers. Every node in the mesh network may share identical role
functionality, allowing each device to act as both a client and a
server concurrently.
[0059] In a mesh network data may be transmitted in a multi-hop
routing scheme such as across multiple routes. Each individual node
may search for neighboring nodes and evaluate the connection
quality with each neighbor node. For each node, the connection
evaluations of each neighbor node may be stored in a node
evaluation table, which may be stored in device memory. The
evaluation table can be used in determining how to route data
through the mesh network. The evaluations may be measured based on
signal strength, connection data rate, retransmission rate, packet
loss ratio, and other factors for each neighboring node/device.
Each node can prioritize neighbors based on the evaluations stored
in the node evaluation table. Each node's evaluation table can be
shared with its neighboring nodes via communication or data
transfer protocols, such as Wi-Fi, Bluetooth, or cellular data, to
name a few.
[0060] Functional abilities of each node can be determined and
exchanged with neighbors, including, for example, the current
battery life, the wireless media that are currently in use or
available, hardware components and device capabilities, and/or
third-party resources, such as GPS, speedometers, or accelerometers
to determine position, speed, or acceleration, to name a few.
[0061] Additionally, various time functions for each node may be
determined and shared with neighbor nodes, including the total time
the node/device is connected to the mesh network, the time spent
connected to a specific neighbor, and the time spent performing
certain role functions. These functions can be analyzed for
determining the path along which to route data.
[0062] GPS-enabled nodes may use the physical location of the
destination node to determine to which neighboring nodes redundant
packets will be sent.
[0063] Data transmitted through the mesh network may be fragmented
into packets, with different packets sent along different routes
within the mesh network. The mesh network may also implement load
balancing techniques through using different backbone and different
backhaul nodes. Further data packets transmitted through the mesh
network can be encrypted.
[0064] Every node/device has a unique identification code which is
used both for identification of a device as well as to target data
to a specific destination device.
[0065] Some nodes/devices, may be connected to other networks, such
as the Internet and the like to provide the mesh network with a
gateway to such networks.
[0066] In exemplary embodiments, a dynamic wireless ad-hoc network
can function autonomously, wherein all network nodes may share the
same role functions based on their capabilities. These nodes can
isolate networking functionalities from overlying applications,
thus being able to perform many routing schemes concurrently based
on application needs, functionality of the node, and quality of
neighbor. FIG. 1 is a visual example of mesh network, where the
user devices 201 are nodes in the mesh network.
Routing
[0067] Communications in a highly dynamic distributed mesh network
may include one or more routing protocols. Some routing protocols
may be designed to optimize a very particular aspect, concurrent
utilization of multiple protocols for different applications will
allow for robust capabilities in highly mobile, asynchronous
networks with an inherently stochastic topology. For example, being
able to maintain a mesh network in Grand Central Station (or some
other heavily trafficked area), with a large amount of moving
people with mobile devices.
[0068] In exemplary embodiments, each node is client/server and
performs all routing functionalities within the network and may
allow multiple hops between nodes on the network.
[0069] In some exemplary embodiments, the network functions in an
entirely distributed communications system, and may implement a
naive topology awareness, where each node is not directly
responsible for maintaining a full table of the entire network
topology. This differs from other networks which have high overhead
caused by keeping up-to-date routing information while in a
constantly changing and unpredictable (highly dynamic and
stochastic) network. For example, the nodes in the exemplary
network may only be responsible for maintaining an up-to-date list
of their direct neighbors (single-hop) to decrease amount of
control packet overhead. This can allow for large, dense, highly
mobile networks that have constantly moving nodes.
[0070] In exemplary embodiments, the network may perform
alternating routing, wherein data is transmitted through the
network over multiple independent routes to the same destination
node. In this regard, by splitting the packet stream into
alternating packets and routing them through multiple paths, this
enables optimized throughput for large data streams, such as
multimedia for example. Further, in embodiments, the network may be
capable of fragmented packet propagation, wherein packets are split
into fragments and distributed using routing techniques including
the aforementioned alternating routing. This functionality may
provide a layer of security, ensuring that no single intermediate
node is capable of intercepting entire data streams in
communications between source and destination nodes.
[0071] In exemplary embodiments social behavior in dynamic ad-hoc
mesh networks may be exploited, for example, by implementing one or
more routing protocols using explicit knowledge of relationships
(e.g., friends on Facebook, connections on LinkedIn, followers on
Twitter, shared check-ins on Foursquare, etc.). Such protocols may
route between neighboring devices (e.g., mobile users) which can be
inferred either from contact libraries and/or explicitly declared
relationships.
[0072] Further in some embodiments routing protocols may be
implemented without knowledge of explicit relationship ties for
communication and data dissemination uses. In some embodiments, one
or more routing protocols may be implemented by utilizing store and
forward mechanisms. For example in an exemplary store and forward
mechanism, if a device (e.g., a node) loses communication to the
network, the device will store the last received packet until it
re-enters the range of communication with another qualifying device
of the network. Such store and forward mechanisms may help to
reduce partitioning issues or problems in highly dynamic networks.
In other words, nodes/devices may store one or more queued packets
for one or more periods of time until the device reconnects with
the network in a suitable manner at a later time, for example by
propagating the packet to suitable candidates devices/nodes.
Suitable candidate nodes can be nodes that are within a predefined
or threshold distance, and/or other devices (nodes) outside or
farther than the predefined or threshold distance but which are
determined to be moving towards the previously disconnected device.
In embodiments, various methods may be used for selecting candidate
nodes. An exemplary approach for selecting a good candidate device
may be based on evaluating application relevant parameters of the
candidate device by means of evaluating, for example, social
content, activities, occupation, interests, locations, and
relationships, to name a few. For example, a candidate may be
selected based on a person associated with a candidate device has
commonality with respect to check-ins, interests/hobbies, and the
like. This information may be pulled from social networks, or may
be retrieved locally from the device.
[0073] FIG. 6 shows, according to an exemplary embodiment, a method
for transmitting packets in a mesh network utilizing a store and
forward mechanism. At step S605, a first node or device, may
generate and/or create one or more packets. The packets may be
generated in accordance with a overlying application utilizing the
mesh network. After generating the packets, the first device may
select one or more forwarding parameters at step S610. For example,
the forwarding parameters may be any parameters, including, for
example, the aforementioned relevant candidate parameters which can
be used by the first device in order to set a forwarding threshold,
at S615. The forwarding threshold may be used for determining or
selecting a set of forwarding nodes to which the first device can
transmit the generated packets. Based at least on the determined
forwarding threshold or any other suitable determinant(s), the
first device may select one or more forwarding nodes at step S620.
After selection of one or more forwarding nodes, the first device
may encode the generated packets at step S625. The first device may
then transmit the encoded packets to the one or more forwarding
nodes at step S630. The first device may store transmitted packets,
for example, in a locally held library and the like, for future
reference at step S635.
[0074] FIG. 7 shows, according to an exemplary embodiment, a method
for retransmitting packets in a mesh network utilizing a store and
forward mechanism. For example, at step S705, a receiving
device/node, may obtain or receive one or more packets from a
transmitting node in an highly dynamic ad hoc wireless network. At
step S710, the receiving device may examine the received packets in
order to determine whether the receiving device is an intended
recipient of the packet. For example, the receiving device may
examine one or more identifying variables, such as, for example,
preformatted unique device identifiers ("UDIDs") located in the
packet. In this regard, the receiving device may determine whether
any of the one or more UDIDs located in the received packets
matches the receiving device's UDID. If the receiving device
determines that it is not an intended recipient for the packet
data, then at step S715, the receiving device may discard the
received packets.
[0075] If in step S710 the receiving device determines that it is
an intended recipient for the packet data, then at step S720, the
receiving device may determine whether it is the destination for
the received packets. For example, the receiving device may
evaluate the packet to make such a determination. If the receiving
device is determined to be the destination for the one or more
received packets, then at step S725, the receiving device can
decode the one or more received packets. After decoding the one or
more received packets, the receiving device may, at step S730, send
an acknowledgment that the receiving device received the one or
more packets. For example the receiving device may send an
acknowledgment that is intended for the originating device.
[0076] If in step S720 the receiving device is determined not to be
the destination for the one or more received packets, then at step
S735, the receiving device may check the forwarding threshold of
the packet. In other words, an application located on the receiving
device may process the one or more received packets to evaluate the
forwarding threshold. At step S740, the receiving device may
determine whether any neighboring devices meet the criteria of the
forwarding threshold. If no devices are determined to meet the
forwarding threshold, the one or more received packets may be
discarded in step S715.
[0077] If in step S740 at least one neighboring device is
determined to meet the forwarding threshold, then at step S745, the
receiving device may update the forwarding threshold of the packet.
For example, the receiving device may manipulate, eliminate,
remove, and/or delete from the packet data of the one or more
received packets, data identifying nodes as recipients, or criteria
which are determined not to meet the forwarding threshold. At step
S750, after updating the forwarding threshold and the like, the
receiving device may forward the one or more packets to each of the
neighboring nodes that meets the updated forwarding threshold
criteria and is an intended recipient of the one or more received
packets. After forwarding the one or more received packets to the
appropriate neighboring nodes, the receiving device, at step S755,
may store the forwarded packets locally for future reference.
Isolating Network Functionality
[0078] In exemplary embodiments, isolating networking
functionalities from any overlying applications can provide the
capability to implement multiple routing schemes concurrently for
optimization to application-specific requirements.
[0079] For example, in FIG. 2, network-level components are broken
into three distinct planes: application layer 250, application
controller 260 and routing libraries 265, and the network
controller 270.
[0080] In exemplary embodiments, the first component (application
layer 250) may contain each individual application 255 utilizing
the underlying network. These one or more applications 255 (1 to N)
can pass down to the application controller 260 a set of
prioritized attributes, specific to that individual application
255.
[0081] Based on these handed-down parameters, the application
controller 260 may correlate the application 255's set of desired
attributes so as to implement the appropriate routing protocol
contained inside of a routing protocol library 265. In this regard,
the application controller 260 may be primarily responsible for
determining various routing algorithms and performing high-level
networking functionalities. By allowing different applications to
utilize multiple routing protocols concurrently, this interface
will enable each application 255 to exist in its own virtual
subnetwork. For example, a multiplayer game between nodes in a
virtual subnetwork may continue to route traffic concurrently for
network control packets, and any additional third party application
data.
[0082] Examples of routing protocols may include proactive,
reactive, hybrid, delay tolerant store and forward mechanisms,
neural networks, graph partitioning schemes, Redundant Dynamic
Protocol, social profiling mechanisms, to name a few. In some
exemplary embodiments, the network may implement single data packet
propagation wherein the size of the packets may vary based on the
routing protocol being implemented.
[0083] In exemplary embodiments, a network controller 270 may be
primarily responsible for actively maintaining a fully distributed
asynchronous network topology, capable of providing communications
in highly dynamic and stochastic environments. Active
responsibilities may include tracking the overall state of the
network, monitoring bandwidth usage by all overlying 3rd party
applications, and/or providing neighbor quality evaluations (based
off connection qualities, self-evaluations, and relevant time
function) for each node. The network controller 270 may further
implement various graph partitioning schemes so as to provide the
capability to manage each overlying subnetwork.
[0084] In exemplary embodiments, a network map may allow higher
layer applications to track what neighbors are available without
interacting with lower level routing algorithms. For example,
control programs may use the network map to modify the way data
packets are forwarded without changes to the routing protocol.
[0085] In exemplary embodiments, communication between user devices
within a mesh network may be carried out without each user device
having information regarding a network map or a predetermined
network topology. For example, data packets may be generated by
and/or received by a user device and then transmitted to one or
more neighboring devices that satisfy criteria, such as a
connection strength threshold and/or have not already received the
data packet. The data packet may be modified as it passes through
each user device to identify which user devices have already
received the data packet. For example, a device can append its
device identifier to a list of recipient devices in an electronic
log included with the data packet to indicate that the designated
device has received the data packet. The process may be repeated to
transmit the data packet to other devices throughout the mesh
network. In embodiments, the data packet may include data which
identifies the desired recipient/recipient device (e.g., the desire
recipients' UDID or other identifier). Intermediate recipient
devices may relay the data packet (e.g., receive the data packet
and forward it to another device if not the intended recipient)
without necessarily accessing the entire packet. For example, it
may be sufficient for the user device to electronically access a
header or other log to determine if the user device is the intended
recipient, and/or to determine which, if any, neighboring devices
have already received the data packet. In embodiments, the data
packet may be transmitted to a neighboring device regardless of
whether that recipient device already received the packet.
[0086] In some exemplary embodiments, the components may interact
through a simple interface, which may allow them to be replaced or
modified without changes to the components running on other layers.
In addition, third party applications may use the interface to
interact with the network via the network controller 270,
significantly reducing the difficulty of developing applications
that use the ad hoc network.
[0087] In exemplary embodiments, the network may be implemented as
a downloadable platform, enabling ad hoc capabilities without
requiring root access to the device or any direct modification of
the underlying hardware. For example, an application 255 may be
downloaded from an application store, through a web browser, to
name a few.
Devices
[0088] In exemplary embodiments, various types of devices that may
wirelessly connect to the network, and thereby participate as a
node, include, for example, mobile phones, smart phones, PDAs,
gaming consoles, wall-charging units, DC power node, light bulbs,
laptop computers, desktop computers, tablet devices, miscellaneous
interactive appliances, navigation devices, drones, and/or
interactive billboards. In embodiments, devices participating as
nodes in a mesh network may be wearable electronic devices, such as
wrist devices, bracelets, eyewear (e.g., glasses or a monocle). In
embodiments, one or more mobile devices may participate as nodes in
a mesh network. FIG. 1 illustrates user devices 201 participating
as nodes in an exemplary mesh network. Any device participating in
a mesh network may include one or more of the features of node
devices described herein with respect to FIG. 8A. In embodiments,
an interactive appliance may be a refrigerator, which may
communicate when food will expire, communicate the amount of
available space inside the refrigerator, adjust the temperature, to
name a few. An interactive appliance may be a smoke detector or
other sensor, which may communicate the presence or concentrations
of smoke or chemicals, and/or may provide alerts, alarms, and/or
contact of emergency or other personnel, to name a few. Lights may
also participate as nodes in a mesh network. Such lights may be
turned on and/or off or otherwise programmed from another node in
the network. Heating and cooling units and/or thermostats may
participate as nodes and may communicate temperature data, adjust
temperature settings or adjust other climate control settings
(e.g., fan settings, temperature controls, to name a few), turn on
and/or off, to name a few. Other appliances, such as a washing
machine or a dryer, may indicate to other nodes the time remaining
in a cycle, may turn on/and or off (e.g., in response to
instructions from another node), to name a few. In other
embodiments, an oven, stove, microwave, and/or like appliance
participating as a node in the mesh network may be turned on and/or
off, the temperature settings or cooking modes may be adjusted, the
temperature setting may be communicated, time information (e.g., a
count-down kitchen timer, count-up kitchen timer, to name a few)
may be communicated, to name a few. In embodiments, media centers,
stereo systems, gaming consoles, televisions, and/or computers may
be accessed, communicated with, and or controlled, e.g. to power on
and/or off, to change channels or stations, to play media works on
demand, to create playlists, and/or to perform any of the native
functions of any of those or like devices.
[0089] In embodiments, drones may be autonomous and/or remote
controlled devices that may participate as nodes in a mesh network.
Drones may travel through air, water, and/or on land, either on
their own power (e.g., wheel, track, or leg-operated
transportation, boats, aircraft, spacecraft, to name a few) or in
conjunction with external transportation (e.g., a drone may be
placed in an automobile, on a blimp, in a boat, to name a few). In
embodiments, nodes may be mounted on any moving device, including
people or animals. In embodiments, drones may increase the
geographic coverage and/or available bandwidth of a mesh
network.
[0090] FIG. 15 is a schematic diagram of a mesh network 1520 with
an interactive billboard 1502 participating as a node. An
interactive billboard may include a display device 1504, which may
be a scrolling screen or television screen, to name a few. An
interactive billboard 1502 may include a networking portal 1506,
which may include hardware and/or software to handle and/or process
communications with one or more devices in a mesh network and/or
with one or more other networks (e.g., the Internet) or non-node
devices (e.g., a computer that may be used to program the
billboard). An interactive billboard 1502 may include a processor
1508, which may process and/or run one or more operating systems
and/or software applications, and/or memory 1510, which may
comprise one or more databases. Memory 1510 may store, in one or
more databases, user data, node device data, data associated with
one or more application programming interfaces ("APIs") (e.g., a
communications API 1512), advertisement data, and/or product data,
to name a few. A communications API 1512 may comprise software for
communicating with one or more nodes in a mesh network. In
embodiments, a communications API 1512 may receive and/or deliver
user data, advertisements, product data, store data, restaurant
data, data regarding services, media and/or multimedia works, to
name a few. An interactive billboard 1502 may connect to one or
more nodes 30 in a mesh network 1520 at a location 60. In
embodiments, nodes 30 may connect to the mesh network 1520 as they
enter a location 60, and nodes 30 may disconnect from the mesh
network 1520 as they leave the location 60. A location 60 may be a
store, shopping mall, certain distance from an interactive
billboard 1520, and/or other area to which the mesh network 1520
extends.
[0091] FIG. 8A is a schematic diagram of an exemplary node device
in accordance with the present invention. FIG. 8A illustrates node
device 201, although it may be representative of any node device
that may participate in a mesh network. A node device may have one
or more processors 802, which may run one or more operating systems
and/or software, such as one or more mesh network APIs 812 as well
as any native applications of the device. Memory 804 is
non-transitory computer-readable media and may also be
computer-writable media. Memory 804 may store, in one or more
databases, user settings, files, media works, and/or mesh
application data 814, to name a few. Mesh application data 814
itself may be stored in one or more databases.
[0092] Mesh application data 814 may include user preferences,
profile data, media works (e.g., pictures, videos, audio works, to
name a few), advertisements, user data (e.g., name, age, gender,
contact information, billing data, to name a few), location data,
guided tour data, data about points of interest in a geographic
area, video game data, neighbor data (e.g., data describing and/or
identifying neighboring nodes or user devices, such as device
address, connection strength, battery life, connectivity to other
networks, to name a few), communications data (e.g., messages, such
as transmitted messages and/or received messages), streaming data
(e.g., streaming audio or video works, which may be streamed in
real time or may be delayed, sports commenting, instant replays, to
name a few), product data and/or sale data (e.g., data indicating
the items, sales, promotions, inventory status, ordering info,
and/or product location info within a retail store, mobile food
cart, to name a few), restaurant data (e.g., menu data, menu
specials, price specials, restaurant or cuisine information,
nutrition information, chef information), entertainment performance
data (e.g., artist info, concert venue details, sports player
statistics or performance history information), and/or survey data
(e.g., surveys or questionnaires), to name a few. Mesh application
data 814 may be generated at a node device 201, received by a node
device 201 through non-mesh network communication, and/or received
by a node device 201 through one or more mesh networks. Mesh
application data 814 may be transmitted (e.g., either through a
mesh network or non-mesh network communication), stored, and/or
used in conjunction with one or more software applications, to name
a few.
[0093] Still referring to FIG. 8A, a node device may also include a
display device 806 and/or an input device 808, which may be a
keyboard, mouse, touchscreen, microphone, and/or camera, to name a
few. In embodiments, a microphone may be used to record audio
inputs. In embodiments, software may operate on one or more audio
inputs to convert the audio to text. A node device may include a
networking portal 810, which may comprise software and/or hardware,
such as a wireless antenna, sockets for data cables or other
cables, and/or circuitry for communications. A networking portal
810 may provide communications via Wi-Fi, Bluetooth, cellular data,
infrared, radio, microwave, other electromagnetic waves, LAN, WAN,
and/or other wired or wireless protocols. In embodiments, a node
device may connect to an external networking device for
communications. A web browser 816 may provide access to the World
Wide Web or any domain name system ("DNS"), e.g., a DNS provided by
one or more nodes in a mesh network.
[0094] In exemplary embodiments, one or more nodes of the network
may self-autonomously relay node devices, which may provide a
method of creating and/or expanding a mesh network, as described
herein. In embodiments, an application programming interface may be
stored on removable memory, such as an SD card, Micro SD card, USB
drive, flash memory device, and/or solid state memory device, to
name a few. A reader of the removable memory may include a
processor, memory (e.g., RAM, ROM, and/or EEPROM), and/or
additional wireless antennas, to name a few. The API may be
distributed from a first device (e.g., a wall-charging unit, a
smart phone, to name a few) to a second device (e.g., a second
wall-charging unit, a printer, a desktop computer, a laptop
computer, a smart phone, to name a few). In exemplary embodiments,
nodes may be implemented by one or more card readers and with one
or more wireless cards, for example a wireless SD card. Exemplary
nodes are shown in FIGS. 8B and 8C. A card reader may include
circuitry 855 to execute stored computer instructions on the card.
The card 850 (and 850'), typically a wireless SD card, may be used
to connect with other nodes of the mesh network. In embodiments,
the card 850 (and 850') may be a wireless memory card. A wireless
card may comprise an antenna, memory, I/O, and/or a modem, to name
a few.
[0095] In embodiments, a wireless SD card reader may be custom
designed to be powered by any power source, such as a wall socket,
car DC socket, external battery, to name a few. FIG. 8B shows a
wall unit 890 comprising wireless SD card reader circuitry 855
custom designed to be fit and powered by a power source that is a
wall socket 870. FIG. 8C shows a DC unit 895 comprising wireless SD
card reader circuitry 855' custom built to be fit and powered by a
power source that is a DC socket 875, as found in an automobile. A
DC power plug 880 may interface between the DC socket 875 and card
reader circuitry 855' to deliver power to the circuitry 855'. In
the embodiments of FIGS. 8B and 8C, a wireless SD card may simply
be inserted into one or more card slots 860 (and 860'). A plurality
of card slots 860 (and 860') may comprise a card bank 865 (and
865'). The card reader may then start reading and implementing the
instructions on the card 850 (and 850'). The card reader may power
the wireless card, e.g., so that the card may transmit and/or
receive data. In some embodiments, an SD or micro SD card may be
inserted into pre-existing hardware including, for example,
laptops, digital cameras, gaming consoles, mobile phones, tablet
devices, navigation devices, interactive appliances, point-of-sale
systems, to name a few. Such pre-existing hardware may read a
wireless memory card, process the data or any applications
contained thereon, and/or power the wireless card.
[0096] FIG. 9 shows a custom wireless SD card 905 that can have an
additional slot 910 for a wireless micro SD card 915. When the
wireless micro SD card 915 is inserted into the slot 910 of the
standard (first) wireless SD card 905, the resulting card
combination may support two functioning communications portals, one
from the micro SD card 915 and one from the standard SD card 905.
In embodiments, each card may have a wireless radio. The card
reader can read and execute instructions from both cards, and
thereby access to receive/send data from the radios of each card,
the SD card and the micro SD card.
[0097] The nodes with the wall-unit 890 and other mobile devices
can be used in an office environment to provide easy connectivity
throughout the office between various devices, such as desktops,
laptops, computer monitors, printers, etc., in addition to the
relay nodes, mobile devices, etc. In embodiments, nodes with the DC
unit 895 may provide communications among one or more automobiles
or other devices in a mesh network including at least one
automobile with a DC unit 895. In embodiments the wall-unit 890
and/or DC unit 895 may provide greater power and/or greater range
for an associated mesh network.
Social Media Platform
[0098] In exemplary embodiments, a social media platform may
utilize a dynamic wireless ad-hoc network (e.g., a mesh network) in
accordance with the present disclosure. In this regard, a social
media mobile application may execute on one or more nodes of the
network in order to implement features of the social media
platform. The social media platform may also be geolocation based,
and may utilize the location based services of the mesh network. In
exemplary embodiments, the social media mobile application running
on a node/device, e.g., a mobile device, laptop, etc., may interact
with other nodes or devices using the network. Therefore, unlike
traditional stagnant networks, the social media platform may
interact with nodes that may enter the mesh network in a highly
dynamic fashion.
[0099] For example, the underlying mesh network may constantly
maintain the highly dynamic behavior of the network topology by
seamlessly establishing full-mesh wireless connectivity between
each device in the mesh network. As devices enter and leave the
network, constant maintenance of the network's highly dynamic
topology may enable each other device to continue substantially
uninterrupted communications during network partitioning and
concatenations.
[0100] FIGS. 3A-D and 4A-D show, according to exemplary
embodiments, examples of the progression of network connections for
an exemplary highly dynamic network. FIGS. 3A-D provide a visual
representation of a series of wirelessly connected network devices.
In FIG. 3A, at a time T305, a single cluster of devices 201
(including device 201-E) forming a dynamic network 350 is
presented. In FIG. 3B at a later time T310, one of the devices
201-E starts to leave or move away from the established mesh
network 350. As a result, two dynamic mesh networks, 352 and 354,
start to develop at T310. In FIG. 3C, at a time T315, device 201-E
moves further from the mesh network or networks, furthering the
development of two mesh networks 352 and 354. Finally, in FIG. 3D,
at a time T320, as the device 201-E leaves, two separate dynamic
networks 352 and 354 are fully and seamlessly formed, in accordance
with exemplary embodiments.
[0101] FIGS. 4A-D, illustrate an example of a highly dynamic
network that may form from previous separate highly dynamic
networks 452 and 454. In this regard, in FIG. 4A, at a time
interval T405, a single device 201-E starts to enter or approach
the two separate networks 452 and 454. As a result, FIGS. 4B, 4C,
and 4D, show at times T410-T420, the progression as the single
device 201-E enters the networks 452 and 454 so as to form a bridge
between the two networks 452 and 454 and form a single dynamic
network 450. Of course, other variations of forming and/or dividing
highly dynamic networks may exist. For example, a plurality of
devices may enter and/or leave one or more established highly
dynamic networks, which may result in the merging and/or
subdividing of the established highly dynamic networks in
accordance with exemplary embodiments. Similarly, the same network
may grow or shrink as individual devices are added or removed as a
result of user migration into and/or out of the range of the mesh
network.
[0102] In embodiments, the application may create a local social
network for a particular environment, e.g., sports venues,
stadiums, concert venues, merchant/stores, museums, night clubs,
restaurants, bars, resorts, hotels, city centers, municipalities,
municipal buildings, airports, transportation hubs, transit
systems, buses, airplanes, trains, subways, designated areas,
schools, universities, parks, corporate parks, public squares,
amusement parks, etc. The application may provide information being
transmitted as one or more data packets to one or more nodes in the
mesh network. Such information can include advertisements, news
updates, weather reports, traffic reports, emergency alerts, other
conditions reports (e.g., ski lift reports, trail reports), menus,
statistics (e.g., sporting event scores, player statistics, trivia
statistics) and/or schedule information (e.g., a concert and/or
event line-up, train schedule, hours of operation), to name a few.
The application may provide multimedia works (e.g., sports replays,
promotional videos, songs, to name a few) to nodes through the mesh
network. In embodiments, the information could include data packets
associated with an interactive video game being played between
users of devices within the mesh network and/or with users outside
the mesh network, connected to the mesh network via an external
node. The application may provide two-way communication among nodes
and/or between nodes and devices on external networks. The
application may collect and provide information from user devices
(nodes), which the venues and/or merchants may use in order to
provide targeted information, advertisements, promotions, conduct
electronic transactions, place orders, etc. to the users or user
devices. For example, using the device, a venue may send an
advertisement to selected users to purchase a food item, which the
user may in turn accept, and charge to an electronic account. Using
geolocation information, the vendor can identify the location of
the user and deliver the item to the user, with it being fully paid
for in advance. Other variations of such scenarios are consistent
with the disclosure.
[0103] The present invention may be used to provide data and/or
communications in areas where cellular or other communications
infrastructure is unavailable and/or at least partially unreliable.
In an exemplary embodiment of the present invention, an application
for ski resorts may be provided. The application may enable
communication to or among nodes of a mesh network. Fixed or moving
nodes may be placed throughout a ski resort (e.g., mounted on ski
patrol snow mobiles, on ski lift gondolas, and/or on towers, to
name a few). In embodiments, such nodes may not be necessary to
sustain a mesh network, e.g., where there are sufficient user
devices owned and/or operated by resort patrons to form a mesh
network of a certain coverage area or transmission speed. A ski
resort mesh network may integrate with a software application,
which may provide reports and/or updates (e.g., push notifications)
for weather, trail conditions, lift conditions, and/or resort
hours, to name a few. An application may further enable
communication with other devices, e.g., to allow friends or
families to communicate while at the resort. A ski resort
application may provide emergency communication (e.g., notifying
the ski patrol of an emergency) and/or emergency location
information (e.g., geolocation of an injured person's user device).
A ski resort application may provide advertisements, ticket
purchasing, and/or menu ordering (e.g., pre-ordering food from a
ski lodge restaurant), to name a few. Other embodiments of the
present invention having similar features are possible, such as
applications for remote but highly trafficked parks (e.g., certain
national parks).
[0104] FIG. 5A shows, according to an exemplary embodiment, a
system diagram with devices for implementing a social media
platform 1. The node devices 30a, 30b, . . . 30N (individually or
collectively designated 30) may each be in wireless communication
with each other using the wireless ad hoc network, as described
herein. In embodiments, the nodes 30 may be locally situated and/or
confined to a particular location 60, though this is not necessary.
In embodiments of the present invention, a mesh network will exist
at location 60. One or more of the nodes 30 may be able to
communicate to one or more networks, designated for convenience as
network 50. The network 50 may be any WAN, LAN, Internet, and/or
suitable third party network, and can provide a gateway connection
for the one or more nodes 30. In embodiments, the network may be a
mesh network connected through wireless communications like Wi-Fi,
Bluetooth, cellular, etc.
[0105] Referring to FIG. 5B, a mesh network at a particular
location 60 may communicate directly or indirectly with one or more
other mesh networks, such as the mesh network at location 60'. In
embodiments, the connection to one or more other mesh networks may
be indirect, e.g., through network 50. For example, one or more
devices in a mesh network at location 60 may be connected to a
third party network 50, which in turn may be connected to one or
more devices in a mesh network at location 60', thereby allowing
each of the devices 30 in mesh network at location 60 to
communicate with each of the devices 30' in mesh network at
location 60'. In addition to the participants in the one or more
networks described with respect to FIG. 5A, in FIG. 5B the network
at location 60' may comprise nodes that may themselves comprise
node devices 30a' . . . 30N'.
[0106] Referring to the embodiments illustrated in both FIGS. 5A
and 5B, the nodes 30 may operatively connect, either directly or
indirectly with social media platform 1. The social media platform
1 may include one or more components (e.g., any combination of
hardware and/or software, such as processors, memory, display
devices, input devices, networking portals (e.g., antennae and/or
accompanying software), software applications, to name a few) which
implement one or more aspects of the social media network. In this
regard, the social media network 1 may include one or more
databases 20, which may be located locally and/or remotely to the
other components of the social media platform 1. Database 20 may
include electronic information, such as data related to
advertisements, user data, or any of the data associated with one
or more mesh applications or APIs 812, such as mesh application
data 814, discussed herein with respect to FIG. 8A.
[0107] Still referring to FIGS. 5A and 5B, the social media
platform 1 may include one or more components (e.g., any suitable
combination of software and/or hardware) including, for example, a
profile component 10a, analysis component 10b, an interface
component 10c, an advertising component 10d, and/or other component
10e. These components may interact with one another and/or interact
with one or more databases 20. In embodiments, the various
components may be locally or remotely located with respect to each
other.
[0108] In exemplary embodiments, the profile component 10a may
implement one or more processes with regard to creating,
maintaining, accessing, and/or retrieving profile information for
members of the platform.
[0109] In exemplary embodiments, the analysis component 10b may
implement one or more processes with regard to analyzing data
(e.g., heat maps, reports, etc.) with respect to one or more users
of the platform.
[0110] In exemplary embodiments, the interface component 10c may
implement one or more processes for interacting with nodes,
devices, and/or third party systems.
[0111] In exemplary embodiments, the advertising component 10d may
implement one or more processes with regard to retrieving,
generating, and/or providing advertisements, promotions, specials,
etc. to members of the platform 1. One or more electronic
transactions may be conducted in tandem or separate from the
advertising component 10d.
[0112] In exemplary embodiments, the other component 10e may
implement other processes used to implement other aspects of the
platform. Consistent with the disclosure, one or more of these
processes may be included in the platform, as desirable.
[0113] In exemplary embodiments, a user may create a profile for
the social media platform via the social application. In
embodiments, the social application may generate a profile using
other social media networks and/or applications (e.g., Facebook,
Foursquare, Twitter, Apple, Amazon, Google+, Tumblr, etc.). The
social application may also access some or all of the information
from one or more other social media networks using, for example,
APIs associated with such other social media networks. In this
regard the Application Controller (which has been previously
described herein), may be responsible for interacting with the
other social media applications and/or networks (e.g., querying,
accessing, and/or retrieving information in order to generate a
profile for the user). In this regard, the social application may
create a profile which may include, among other thing, the device
user's name, picture, real name, and the like. Alternatively, an
existing profile may be modified in order to create a profile for
the platform 1. The profile may also include members being tracked,
social network members tracking the user, security/privacy
settings, electronic message inbox, reward points, saved places,
etc. This information may be saved locally and/or may be remotely
stored at the platform 1. Once a user profile is generated, the
Application may use the social media network user profile and/or
access other social media network profiles as desired.
[0114] In embodiments, the social application may run or execute in
the background of a node, e.g., a user may not be required to open
the application in order for one or more processes associated with
the social application to execute.
[0115] In exemplary embodiments, the social application may
implement one or more processes for determining the amount many
nodes or devices are in a given area or vicinity (designated areas,
stores, venues, etc.). This determination may be based on the
amount of other devices/nodes the social application can connect to
that also have and/or are implementing the social application. In
this regard, the social application may cause the host device to
periodically query the other nodes in order to exchange
information. The locally determined node count, along with node's
determined location information (e.g., where is the node device is)
may be shared with other connecting nodes. In embodiments, each
nodes may create and/or store a record of the node count, and other
nodes location information over time. This information may then be
shared and/or transmitted to other systems, including the social
media platform 1 and/or third party systems 40. In some
embodiments, the records may expire and be deleted after a certain
period and/or after the information has been shared or transmitted
to one or more other systems.
[0116] In some exemplary embodiments, a node counting process may
be accomplished by identifying other nodes, for example through a
monitoring interface implemented on a wireless networking card. The
monitoring interface may monitor and/or poll the wireless channels
and monitor the received packets to identify all the distinct
devices.
[0117] In embodiments, after identification the devices, UDIDs (or
other identifying information) corresponding to the devices may be
stored in order to determine how many distinct devices there are
within a given location over a particular period of time. The
identified/determined number of devices may be stored as part of
the node count data. The packets associated with each UDID may be
analyzed to determine what type of application the device is
currently running. Based on this determination, the devices which
are running the social application can be identified as a node in
the mesh network and thus determine the amount of nodes. Therefore,
the node count may include the number of devices in a given area,
and/or include the number of nodes in a given area. For each node
identified, the user/user profile information may also be
identified and/or stored.
[0118] In exemplary embodiments, the node count information/records
may be utilized in various manners, either on a particular node,
the platform, a third party system, or combinations thereof. In one
exemplary embodiment, the node count data may be used to generate
heat maps (e.g., a color coded map of the density of nodes within a
given range).
[0119] In exemplary embodiments, heat maps may be generated with
respect to one or more locations at one or more time periods. The
heat map may use any appropriate color scheme (e.g., dark coded
areas indicating greater density/activity, light areas indicating
low density/activity). For example, a heat map corresponding a
particular location (e.g., venue, store, designated area, etc.) may
be generated to show how crowded/dense or active the particular
location is. For a large particular area, e.g., a park, certain
subareas of the heat map may be dark in order reflect the
corresponding area of the location which has a high density/area.
Data collected from such heat maps by venues can be used to monitor
traffic during different periods of time, as well as other
statistical analyses.
[0120] In embodiments, geographical density with respect to a
particular location may be determined using GPS or other geo
location information, such as, by estimating the number of hops
through neighboring devices, determined/estimated amount of
application activity, or combinations thereof.
[0121] In embodiments, the heat map may be interactive. For
example, a particular heat map may include a slider which, which
when activated and moved, causes the heat map to be updated from a
first time to one or more other times. For example the slider may
cause how a location's density changes by updating a heat map over
a plurality of time periods, e.g., over minutes, hours, day(s),
week(s), month(s), year(s), etc. A range indicator may also vary
the size of the location being illustrated by the heat map. As
previous discussed, heat maps may be generated using the node count
data. Therefore, the heat map may utilize from the node count data,
the amount of active devices and/or may use the amount of active
nodes (e.g., devices running the social application).
[0122] In embodiments, other variations of the heat maps may be
generated and filtered according to various criteria. For a
particular location, nodes (devices running the social
application), the profile information may be used in conjunction.
For example a filtered heat map may be generated to show density by
demographic/profile information (age, gender, device type,
interests, etc.) Such information may be obtained from the user's
profile information associated with each node.
[0123] As previous explained, heat maps may be generated on a
device (node), the platform 1, and/or a third party system 40. In
some embodiments, the platform 1 may provide the heat maps to users
of the platform (e.g., through the social application, through a
website, email, SMS, messaging, etc.). The platform 1 may provide
the heat maps and/or the corresponding data related to a particular
location to merchants, venues owners/representatives, or other
individuals desiring such information. The data may include user
habits, such as for example, how often a user visits particular
locations, venues, stores, etc. The data may be used by merchants,
venues, etc. in order to send to users or user devices via the
social application targeted promotions, advertisements, special
events, etc. For example, when a new patron enters a venue, the
proprietor may be notified that the individual is a new patron.
Similarly, when a previous patron enters a venue, the venue
proprietor may be alerted to the presence of the patron, and
profile information related to the patron may be provided to the
venue proprietor system. Such information may then be coordinated
with the venue proprietor's database, so that an appropriate
profile of prior purchases, desires, etc. can be generated and
provided to the proprietor.
[0124] In exemplary embodiments, the social application may be used
to search for other users (depending on their privacy settings) at
a particular location. The social user may be able to display from
another node, any one of another user's picture, contact
information, distance away, social media relationship (e.g.,
Friends on Facebook, Twitter follower, etc.). Further, while at a
particular location, the social application may indicate the level
of crowdedness (e.g., density). The social application may allow a
user to save, bookmark, and/or favorite a particular location for
future reference. The social application may allow the user to
telecast to the user's social network the fact that the user is at
the location and/or conducting certain activity related to the
venue (e.g., John is watching the Giant's play football at the
Meadowland's stadium). Further, through the social application, a
user may be able to directly communicate with other nodes.
[0125] As previous explained, the social application may also
access information from third party systems and/or other social
networks. In this regard, while at a particular location, the
social application may also provide relevant location based
information. In one example, while at a restaurant, user ratings
from Yelp!, Foursquare, Zagat's, Urban Spoon, Google Reviews,
Localmind, etc. may be retrieved and presented to the user.
[0126] In exemplary embodiments, a targeted promotion may be sent
to a node which is in a defined location. For example the node's
location may be received or determined by the platform. The
platform may use the received location of the node in order to send
the targeted promotion to the user device/node. The location may be
determined via GPS or any other method in accordance with exemplary
embodiments described herein. In another case, the node may receive
a targeted promotion directly from another device. For example,
when a node (host node) enters a venue, a node operated or owned by
the venue (venue node) may detect the node's presence and retrieve
and propagate a targeted promotion to the host node using the
social application in accordance with the mesh network
communication methods described herein. The venue's social
application may be substantially similar to the social application
running on the host node, but may include additional
functionalities for being able to communicate promotions to other
devices.
Messaging and Broadcasting
[0127] In embodiments, an application may allow users, using one or
more user devices, to communicate with one or more other user
devices participating in one or more mesh networks. For example, a
communications application may allow text messages and/or media
messages (e.g., video, pictures, audio works, and/or combinations
thereof, to name a few), and/or combinations thereof. In
embodiments, other data, such as documents and/or other files, may
be communicated through a mesh network. In embodiments, groups or
packages of data may be communicated through a mesh network. Groups
or packages of data may comprise multiple documents, multiple media
works, and/or folders containing multiple files and/or media works,
to name a few. In embodiments, an application may provide
text-to-voice and/or voice-to-text capabilities, which may be used
for messaging among user devices as described herein. In
embodiments, such communications may be performed in the context of
a stand-alone communications application or in the context of one
or more social media applications, as discussed herein.
Communication may comprise one or two-way communication, through
sending and/or receiving data packets.
[0128] FIGS. 12A-D are exemplary screen shots of a node device
running a mesh network communications application. In FIG. 12A, the
user is presented with a login screen, which requires the user to
enter a username in username box 1202 in order to log in. In
embodiments, a username may not be required. A username may be
automatically generated and assigned to a user who does not provide
a username. In embodiments, a user may select (e.g., by touching,
clicking, voice command, to name a few) a log in or sign in option
1203 to instruct the device to log the user into the API.
[0129] In embodiments, the features discussed with respect to FIGS.
12B and 12C may comprise at least part of a contacts portal 1232 of
a communications application. A contacts portal may describe and/or
enable interaction with and/or communications with neighboring
nodes in a mesh network. In embodiments, neighboring nodes may be
nodes that connect indirectly through other nodes in a mesh
network. FIG. 12B is a screen shot of a contacts portal 1232 of a
communications application. A friends list 1204 may identify online
contacts 1206 and/or offline contacts 1208 (collectively, contacts
1207). Contacts 1207 may be other nodes with which communication
has been permitted, e.g., accepted by one or both nodes (e.g., the
node of FIG. 12 and another node associated with username 1206). In
embodiments, the application may indicate online contacts 1206,
which may be nodes that are online and/or available for
communication, and/or the application may indicated offline
contacts 1208, which may be nodes that are offline and/or not
available for communication. In embodiments, message indicators
1210 may indicate when new messages, not yet read, have been
received from one or more contacts. A message indicator 1210 may
indicate the number of unread messages, e.g., "2" unread messages.
A mesh network communications application may provide a friend
request list 1212, which may list pending contact requests 1214. A
pending contact request 1214 may identify a node (e.g., by a
username or device address associated with that node) that has
requested permission to be a contact 1207. The application may
provide a confirm option 1216 for the friend request or a decline
option 1218. A mesh network communications application may also
provide an online node list 1220, which may list online nodes 1222
that are available for communication and/or to be added as contacts
1207. An add contact option 1224 may be provided to request an
online node 1222 to be a contact 1207. Referring to FIG. 12C, after
a contact request is sent (e.g. by using an add contact option
1224), a pending contact 1226 may be displayed in the friends list
1204. As shown in FIG. 12D, a contact request notifications 1226'
may be displayed in a notifications list 1228, which may be a
native feature of a node device.
[0130] FIGS. 13A-D are exemplary screen shots of a messages portal
1302 of a mesh network communications application on a node device.
As shown in FIG. 13A, the main screen of a messages portal 1302 may
comprise a conversations list 1304. A conversations list 1304 may
list one or more on-going or past conversations, such as
conversation 1306. In embodiments, a conversation list 1304 may
also indicate which conversations contain unread messages, which
indication may include an unread message count 1308. When a user
selects a conversation (e.g., conversation with user 1306) from the
conversation list 1304, the application may display the
conversation, as shown in FIG. 13B. The conversation may comprise
received messages 1310 and/or transmitted messages 1312. In
addition to the contents of a message, which may comprise text,
media works, and/or files, to name a few, a conversation may
display the time and/or date on which a message was received or
transmitted. An input device, such as a keyboard, may be used to
compose a message. In embodiments, a microphone operatively
connected to voice-to-speech recognition software may comprise an
input to compose a message. A conversation may include an
attachment option 1314, which may allow a user to transmit a file,
media work, or other data in addition to or in place of a
text-based message. A text-based message may be added by selecting
a text field location 1315, which may activate and/or display a
text input device, such as a touch screen keyboard or keypad. A
messages portal may provide the ability to add additional users to
a conversation. As shown in FIG. 13B, from within a selected
conversation, an add user option 1316 is provided. Referring to
FIG. 13C, an add user option 1316 may display available users 1318
who may be added to the conversation. In embodiments, the available
users 1318 may be a user's contacts, online contacts, any users in
the mesh network with a messaging application installed and/or
running, and/or any users in the mesh network, to name a few. In
embodiments, the number of participants in a conversation may be
limited, e.g., no more than 5 participants in any one conversation.
In embodiments, when a third participant is added to a
conversation, a group conversation or group message 1320 may be
formed, as shown in FIG. 13D. The messages portal of a
communications application may provide a participants list 1322,
which lists the users participating in a group message 1320.
[0131] FIG. 14 is an exemplary screen shot of a broadcast portal
1402 of a communications application. A broadcast portal 1402 may
display received messages 1404 and/or transmitted messages 1406. A
broadcast portal 1402 may transmit one or more messages and/or data
files to all nodes in a mesh network. In embodiments, messages
and/or data files from any node in a mesh network may be received
at a broadcast portal 1402.
Distributing an API in a Mesh Network
[0132] In embodiments, an API for participating in a mesh network
may be obtained from a central source, such as an app store (e.g.,
Google Play, iTunes App Store, Windows Store, to name a few). In
embodiments, the API may be provided through a downloadable
application, e.g., an application that may be installed on a mobile
device.
[0133] In embodiments, an API for participation in a mesh network
may be distributed through the mesh network. The API may be
distributed without a central provider. FIG. 10A illustrates a
process for using nodes in a mesh network to distribute an API for
participating as a node in the network. In embodiments, the process
described in FIG. 10A may be used to distribute an API for a game,
for an information platform (e.g., an application for receiving
and/or accessing information), and/or for a communications
platform, to name a few. At the start, at least one instance of an
API or an application embodying the API may be installed or
otherwise stored on a first device. The first device may be a
mobile device or a non-mobile device. A mobile device may be a cell
phone, smartphone, PDA, portable computer, tablet computer, GPS
device, portable video game system, calculator device, wall-unit
node, DC power node, to name a few. A non-mobile device can include
a computer, video game console, wall socket with wireless memory
card, DC socket with wireless card, and/or television, to name a
few. Although FIG. 10A describes first and second mobile devices,
in embodiments, the same process can be performed with a
combination of mobile and/or non-mobile devices.
[0134] As shown in FIG. 10A, in a step S1002, the presence of a
first device may be detected on a second mobile device. In
embodiments, the second device may detect a presence of a first
device in a network. In embodiments, the second mobile device may
detect a presence of a network from a first device. In a step
S1004, the second mobile device may wirelessly connect to the first
device. In embodiments, the devices may be connected through Wi-Fi,
Wi-Fi Direct, Bluetooth, Bluetooth Low Energy, near field
communication ("NFC"), infrared, microwave, radio wave, and/or
cellular data, to name a few. In a step S1006, a web browser
application may be accessed on the second mobile device. In a step
S1008, a DNS implementation on the first device may be accessed on
the second mobile device. In embodiments, the DNS implementation on
the first device may be accessed on the second mobile device
through or using a web browser application. In a step S1010, the
second mobile device may receive from the first device display data
for display in the web browser on the second mobile device. The
display data may comprise or may be used to generate a splash
screen or other graphical user interface. In a step S1012, the
second mobile device may submit an electronic request for a
machine-readable API from the first device. The API may be stored
in memory of the first device. In a step S1014, the
machine-readable API from the first mobile device may be downloaded
at the second mobile device. The API may be stored in device memory
of the second mobile device. In a step S1016, the machine-readable
API may be installed on the second mobile device to be run on a
processor of the second mobile device. In embodiments, the second
mobile device may include one or more processors, which may be used
to run the API. In a step S1018, the second mobile device, using
the installed machine-readable API, may connect to the first
device. In embodiments, the second mobile device may connect to any
other device participating in the mesh network. Devices may use the
installed machine-readable API to communicate with other devices in
the mesh network. In embodiments, communication, which may be a one
or two-way transfer of data packets, may occur after a connection
between devices has been established. Communication may also occur
without first establishing a connection by relaying data packets
through the mesh network, as discussed herein.
[0135] In embodiments, an API may be distributed by wall units
(e.g., wall-charging units) and/or AC/DC charging units (e.g., in
automobiles), which units may contain an API on removable memory.
For example, an API may be relayed from wall units to other wall
units, and/or from an origin wall unit to any destination device.
Such a system may create, propagate, and/or expand a mesh network
in the following manner. A second device may detect the presence of
a first device. In embodiments, the second device may detect the
presence of a first device in a mesh network or may detect the
presence of a network from a first device. The second device may
connect to the first device via a wireless connection. The second
device may send to the first device an electronic request for a
machine-readable application programming interface stored in
removable memory of the first device. In embodiments, the API may
be stored on non-removable memory. The second device may download
into second device memory the machine-readable application
programming interface from the first device. The second device may
install the machine-readable application programming interface to
be run on one or more processors of the second device. The second
device may then connect to the first device via the wireless
connection using the installed machine-readable application
programming interface.
[0136] FIGS. 10B-F are schematic diagrams of devices performing a
process for distributing an API in a mesh network in accordance
with the present invention. Referring to FIG. 10B, at a time T1002,
a first node device 201-1 may comprise at least a networking portal
810-1 and a mesh network API 812-1, and a second node device 201-2
may comprise at least a networking portal 810-2. FIG. 10C shows
that at a time T1004 the second node device 201-2 may connect to
the first node device 201-1. As shown in FIG. 10D, at a time T1006,
a web browser 816-2 may be accessed at the second node device
201-2. FIG. 10E shows that at times T1008, T1010, and T1012, the
web browser 816-2 on the second device 201-2 may access a DNS on
the first device 201-1, receive a download option for a mesh
network API, and request the API from the first device 201-1. FIG.
10F shows that at times T1014, T1016, and T1018, the second device
201-2 may download and install, at the second device 201-2, the
mesh network API 812-2. The second device 201-2 may then use the
installed mesh network API 812-2 to connect with the first device
201-1.
[0137] FIGS. 11A-E are screen shots of the implementation of a
process for distributing, using a mesh network, an API for
participation in a mesh network. In FIG. 11A, in the settings of a
second device, the Wi-Fi is enabled, which may be achieved by
switching the Wi-Fi selector 1102 to the On position. In FIG. 11B,
the available Wi-Fi networks are displayed on the second device. A
Wi-Fi network 1104 associated with a first device, e.g., the
Dahrwin network, may be selected at the second device. In FIG. 11C,
a web or Internet browser 1106 may be accessed on the second
device. In FIG. 11D, a splash screen associated with the network of
the first device may be displayed in the browser of the second
device. In embodiments, the splash screen may contain a download
option 1108, e.g., a link, to download and/or run, at the second
device, an application, which may comprise an API, from the first
device. In embodiments, statistics 1110 about the network of the
first device and/or the network status may be displayed and/or made
available, e.g. through a link. In FIG. 11E, an application from
the first device was downloaded at the second device following a
request at the second device to download the application from the
first device. A completed download notification 1112 may be
provided (e.g., using the API of a device operating system and/or
an API associated with a mesh network application, to name a few).
The application may then be installed at the second device and
used, e.g., to participate in a mesh network. In embodiments, after
installing the application at the second device, the second device
may perform the steps previously attributed to the first device,
such as providing a network and a downloadable application to other
devices (e.g., a third device, a fourth device, etc.). In this
manner, a mesh network can expand from one device to, in theory,
infinitely many devices.
[0138] In embodiments an API may be distributed via one or more
intermediary devices. For example, an API may be distributed from a
first device to a third mobile device via a first connection formed
between the first device and a second device and a second
connection formed between the second device and the third device.
The process may be performed in substantially the same manner as
illustrated in FIG. 10A, but with the intermediary devices
wirelessly relaying data packets (e.g., electronic requests,
display data, API) between the API origin device and the API
destination device.
[0139] In embodiments, one or more additional APIs may be
distributed through a mesh network. For example, additional APIs
may provide a gaming platform, advertising platform, communications
platform, platform for receiving information, platform for
accessing information, social media application, access and/or
provide mesh capabilities to any third-party non-mesh applications
(e.g., Twitter, Foursquare, Facebook, Tumblr, LinkedIn), and/or any
mesh network API 812, as discussed herein.
Firearm Network
[0140] In exemplary embodiments, a firearm awareness network or a
"firearm network" may be implemented using the mesh network
described herein (e.g., DYNAMET). While nodes and devices have been
described that may constitute the mesh network, the firearm network
may also include and/or interact with firearms that are compatible
with the firearm network, e.g., a "smart firearm" having "smartgun
technology".
[0141] FIG. 16 shows according to exemplary embodiments, various
components of a smart firearm which may include a discriminator, a
microcontroller unit (MCU), a radio frequency (RF) transceiver,
and/or a power supply, to name a few. In other words, FIG. 16,
illustrates one exemplary representation of smartgun
technology.
[0142] According to exemplary embodiments, a smart firearm can
identify one or more users. For example, the smart firearm may
identify a user using a unique identifier or a key, which may
include a fingerprint, a voice print, a code, and/or an electronic
tag (e.g., RFID), to name a few. A key used with a firearm can be
unique to a single authorized user or to a group of authorized
users. Exemplary firearms may employ a single key or multiple keys
in order to allow multiple authorized persons to use the smart
firearm, or so as to allow a single user to be authorized to use
multiple firearms. In some embodiments, some keys can be re-used or
modified/changed, while in some cases a key cannot be changed.
[0143] As shown in FIG. 16, the smartgun technology can include a
discriminator component which may be responsible for distinguishing
between the one or more distinct keys used by the smart firearm.
The discriminator may distinguish between keys so as to provide
access to the smart firearm by, for example, enabling a latch or
suitable methods.
[0144] The discriminator may authenticate a key input, for example
by comparing a received key input with stored keys associated with
authorized users. If a key input is authenticated, the
discriminator can enable the RF Transceiver.
[0145] FIG. 17, shows, according to exemplary embodiments, an
exemplary authentication process performed by the discriminator. At
step 1705, the discriminator may receive and evaluate a unique
identifier. For example, the discriminator may access and refer to
records of a discriminator record table in order to evaluate a
received unique identifier (UID). At step 1710, the discriminator
may determine whether the UID is identified. If a record for the
UID exists, in other words, if the UID is identified at step 1710,
then the discriminator may notify the MCU at step 1715. If at step
1710 the UID is not identified, then at step 1720, the
discriminator may update the record data table using the UID.
[0146] Referring to FIG. 16, the MCU may include an Operating
System, "OS" component, an Application layer "Application"
component, and any other suitable peripheral components
"Peripherals"). The MCU may be operatively connected to an RF
Transceiver, an EEPROM, and the Discriminator, in accordance with
exemplary embodiments. Please note that other elements may replace
or be added to the configuration as shown in FIG. 16 in accordance
with embodiments described herein.
[0147] The MCU may at least include a small computer implemented on
an integrated circuit, including one or more processor cores,
memory, and/or programmable input/output peripherals. The system
configuration for the smart firearm may be determined by one or
more set of instructions accessed and implemented by the MCU. For
example, the MCU can receive information from the discriminator and
determine a status of the smart firearm.
[0148] In exemplary embodiments, the smart firearm Radio Frequency
(RF) Transceiver may be used for transmitting and/or receiving
radio frequency signals. Additionally, the MCU can interact with
the RF Transceiver so as to enable the RF transceiver to operating
in a transmit and/or, receive mode.
[0149] According to exemplary embodiments, compatible firearms for
a firearm awareness network may include and/or implement active
and/or passive technologies. For example, active technologies may
require an actively connected power source, unlike passive which
can operate without a power source connected thereto. In
embodiments, active technologies implemented with the smart firearm
may utilize one or more batteries.
[0150] In embodiments, the smart firearm may be turned on (e.g.,
powered up so as to connect to the network) in response to some
action (e.g., movement) or input, such as from a user of the smart
firearm. Various technologies may be used with the smart firearm so
as to power the circuitry/technologies of the smart firearm
continuously and/or on a need-only basis.
[0151] In some exemplary embodiments, the smart firearms may
include capacitance proximity sensors. For example, a capacitance
sensor can measure the change in its stored electric charge caused
by the sensor being brought near or in contact with another object.
Thus in embodiments, one or more capacitive sensors may be
integrated with a firearm in order to indicate to the smart firearm
and/or the MCU the presence or lack thereof of an object (e.g., a
hand) so as to cause one or more components of the smart firearm
technology to turn on and/or off and thereby optimize the life span
of battery used with the smart firearm.
[0152] FIG. 18 shows, according to exemplary embodiments, an
exemplary communication process performed by the MCU. At step 1805,
the MCU may receive one or more notification messages indicating
events such as, the presence of firearm within one or more areas,
the absence of a firearm from one or more area, the movement of a
firearm within one or more areas, and the like, to name a few. At
step 1810, the MCU can access and evaluate discriminator record
table data using the notification message. After evaluating the
discriminator record table, the MCU may activate the RF transceiver
at step 1815. The RF transceiver may communicate and search for any
neighboring devices at step 1820. If at step 1825, the MCU
determines that there are no available neighbors (e.g., nodes), the
MCU may repeat step 1820. If at step 1825 the MCU does determine
that there is at least one available neighbor, then, at step 1830,
the MCU may send one or more received notification messages. These
messages may be sent and received in accordance with the protocols
and/or embodiments described herein.
[0153] FIG. 19A shows, according to an exemplary embodiment,
various smart firearms 1900a, 1900b, and 1900c which may implement
the smartgun technology. For example, as illustrated, the dark
shaded sections 1905 indicate areas where the smartgun technology
components may be integrated in accordance with embodiments
described herein.
[0154] FIG. 19B includes an illustration of an exemplary smart hand
gun in accordance with embodiments described herein with one or
more sections removed to reveal the interior. The smart hand gun,
may include, for example, one or more solenoids 1915, electronic
circuit board(s) 1920 (including e.g., a MCU(s)), one or more
rechargeable batteries 1925, one or more antennas 1930 (e.g.,
802.11, etc.), and induction coil(s) 1935. These elements are
exemplary and other elements may substitute for and/or be used with
the illustrated elements in accordance with exemplary embodiments.
The solenoid, for example, may be used in conjunction with one or
more third party smart gun technologies including, for example
trigger lock mechanisms, biometrics scanners, etc. However, one or
more of these technologies may also be implemented without the need
for a solenoid.
[0155] While a hand gun is illustrated in FIG. 19B, it is noted
that other types of firearms, such, for example, rifles, shotguns,
and machine guns, to name a few, can provide a large enough stock
and therefore provide the requisite space for the smart gun
technology.
[0156] In exemplary embodiments, the smart gun technology may
operate independently from the normal or typical operations of a
firearm, (e.g., the loading, cleaning, firing, etc. of the
firearm). In other words, if the smart gun technology were to fail
in some respect, the firearm would still be operable mechanically.
Conversely, in embodiments, the smart gun technology may operate
regardless of the performance of the firearm itself, such as
whether it is capable of being fired.
[0157] In exemplary embodiments, the smart gun technology may be
integrated and/or manufactured with new firearms, or may be
included (retrofitted) with existing firearms. Additionally, the
smart gun technology may additionally be integrated and/or
implemented with other firearms, including, for example, carrying
cases, magazine clips, firearm accessories, and the like, to name a
few. For example, the smart gun technology may be implemented in a
carrying case so as to supplement or complement the functionality
of a smart firearm. In this regard, the case may provide additional
features, such as, for example, providing power to the firearm, and
enabling ad-hoc wireless communications.
[0158] FIG. 20 shows, according to an exemplary embodiment, an
exemplary smart firearm case 900. The smart firearm case may
include, for example, an antenna 2005 (e.g., 802.11a antenna) for
communicating with the one or more of the nodes of the firearm
network. The smart firearm case may include authentication and/or
security measures 2010 for providing access to open the carrying
case. In this regard, FIG. 20 shows the case 2000 having biometric
scanners. This is merely illustrative, as other security measures
may be implemented, including, for example measuring related to
combination locks/measures, voice identification, fingerprint
identification, key pad password, and a key (electronic and/or
mechanical), to name a few.
[0159] The carrying case 2000 may include a user interface 2015 as
well as one or more displays which may indicate one or more
statuses related to the firearm, for example, whether the firearm
is detected as being inside or outside the case, whether it is
available or authorized for removal from the carrying case 2000,
and the like. A user may interact with the user interface 2015 in
order to access the firearm and/or communicate with the firearm
network. Again, the user interface 2015 may provide security
measures for authorizing the removal of the firearm. Additionally,
the user interface 2015 may receive one or more messages related to
the firearm associated with the carrying, after it has been
removed. For example, the case may receive messages from nodes
which approximate the location of the firearm in accordance with
embodiments described herein. Additionally, the user interface 2015
may allow a user to sync or register a new smart firearm with the
case and a firearm network.
[0160] As shown in FIG. 20, the smart carrying case 2000 may
include an induction coil 2025 which may be connected or integrated
with other circuitry to act a sensor and used to make an evaluation
of whether the firearm is still present in the case and/or has been
removed. While an induction coil is shown, other suitable
components may be implemented with the carrying case in order to
determine and/or detect when a firearm is placed properly in the
case or has been removed.
[0161] In an exemplary embodiment, a carrying safe with integrated
smart gun technology can notify the firearm network when a smart
firearm is removed therefrom. For example, in response to detection
of an unauthorized firearm removal, the firearm network can attempt
to notify the owner. The owner may be notified through any suitable
means, including, for example, voice calls, text messages, emails,
and alarms, to name a few, using one or more of the nodes/devices
constituting the firearm network.
[0162] In exemplary embodiments, the firearm network may rely on
pre-existing third party networks to facilitate communications
between the firearm owner and the local authorities. In some
exemplary embodiments, the firearm network may enable wireless
communications regardless of any pre-existing wireless networks, by
communicating and/or utilizing publicly accessible wireless
devices. The devices may be any network or wireless compatible
devices described herein.
[0163] In exemplary embodiments, the firearm network may be
implemented to provide virtual wireless security perimeters, in
environments, such as, for example, office buildings, public
schools, a variety of public spaces, etc.
[0164] FIGS. 21A-21B, show exemplary environments implementing a
firearm network with a wireless security perimeters.
[0165] The firearm network may determine whenever an unauthorized
firearm enters within the proximity of the firearm network.
Referring to FIG. 21A a firearm 1005 and/or firearm carrying case
2110 may provide and/or send alert regarding their presence. For
example, the alert may be received by a node device 2115, which can
forward the notification via wireless connections (e.g., cellular
connections) 2120 which in turn may send an alert to the owner's
device 2125.
[0166] Referring to FIG. 21B, when a firearm arm or firearm case
2110 is detected, for example by a node or a device 2130a, one or
more wireless notifications may be sent to each device connected or
part of the firearm network so as to create alert other people in a
reliable and timely manner. As shown in FIG. 21B, devices 2130b,
and 2130c are notified through wireless means as described herein.
Further, an alarm system or device 2140, may also be notified which
may trigger the flashing of lights, alarm sounds, etc.
[0167] FIG. 22 shows according to an exemplary embodiment, a method
for providing an alert notification in a firearm network. For
example, at step 2205, a device (e.g., a node) may receive a
notification message. For example the notification may relate to
the status of a smart firearm that has been used in some
unauthorized manner. For example, the notification may indicate
that a smart firearm has been detected as having been detected
without authorization in one or more areas of the firearm network,
has been removed without authorization from a smart carrying case,
or has been fired (without authorization) in proximity to the
firearm network.
[0168] In exemplary embodiments, other types of notifications,
which can be generated and propagated through firearm network, may
include for example, messages indicating the authorized use of a
firearm, the authorized removal of a firearm, authorized loading of
a firearm, authorized firing of a firearm, and the like, to name a
few. These messages are non-exhaustive and other types of messages
may be received indicating an important or noteworthy status of a
smart firearm.
[0169] At step 2210, the device receiving the notification may
determine the availability of network connections. For example, the
device receiving the notification may determine which if any other
devices and/or nodes constituting the firearm network it can
connect with, and determine. At step 2215, the device may also
determine, as a result of step 2210, whether the device can connect
to a gateway connection, e.g., a connection to the Internet, third
party network, LAN, WAN, cellular network, etc. In some situations,
the receiving device itself may directly and/or be able have a
gateway connection. In some situations, the receiving device may
determine that it can connect to one or more nodes/devices in the
firearm network that can provide a connection to a gateway
connection.
[0170] At step 2220, if the device can operatively connect to a
gateway connection, then the device may send an alert notification.
For example, the device may send an alert notification to local
authorities, to the one or more owners of the firearm, and/or to
any other suitable person associated with the firearm or the alert.
In some embodiments, the alert notification may be implemented as
voice call, a text message, an electronic fax, etc.
[0171] At step 2225, after sending a notification in step 2220, of
after determining there is no gateway connection available at step
2215, the receiving device determines which nodes/devices of the
firearm network are available to communicate. After determining
which node devices are available, then at step 2230 the device
sends the alert notifications. For example, referring to FIG. 21B,
each device shown may receive an alert notification. In
embodiments, the firearm network may propagate the alert
notification according to each device in the network in accordance
with exemplary embodiments described herein.
[0172] The firearm network may detect the presence, absence, and/or
the use of compatible firearms.
[0173] It will be understood that that any of the above steps
and/or elements can be combined, separated, any combination and/or
separation thereof, and/or taken in any order. For ease, the steps
are described as being sequential and/or in order. This is merely
for ease and is not in any way meant to be a limitation.
[0174] While particular embodiments of the present invention have
been shown and described in detail, it would be obvious to those
skilled in the art that various modifications and improvements
thereon may be made without departing from the spirit and scope of
the invention. It is therefore intended to cover in the appended
claims all such modifications and improvements that are within the
scope of this invention.
* * * * *