U.S. patent application number 15/594737 was filed with the patent office on 2018-11-15 for anticipatory networking.
This patent application is currently assigned to Apple Inc.. The applicant listed for this patent is Apple Inc.. Invention is credited to Franco TRAVOSTINO.
Application Number | 20180332482 15/594737 |
Document ID | / |
Family ID | 64051020 |
Filed Date | 2018-11-15 |
United States Patent
Application |
20180332482 |
Kind Code |
A1 |
TRAVOSTINO; Franco |
November 15, 2018 |
Anticipatory Networking
Abstract
Embodiments for performing an anticipatory networking are
provided. These embodiments include detecting an action taken by a
user of a wirelessly-enabled device, an automated action of the
wirelessly-enabled device, or a current condition of the device;
learning what future operations the wirelessly-enabled device will
likely need to perform in order to carry out the desired user
action or device action; creating a user profile based on the
learned information; and proactively performing, based on the user
profile, certain downstream operations before the data
corresponding to those operations is actually needed. In some
embodiments, the anticipatory networking techniques disclosed
herein essentially represent the confluence of networking concepts
and machine learning concepts, and as such, enable wireless
communications having reduced latency, while also improving network
reliability and device performance.
Inventors: |
TRAVOSTINO; Franco;
(Cupertino, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apple Inc. |
Cupertino |
CA |
US |
|
|
Assignee: |
Apple Inc.
Cupertino
CA
|
Family ID: |
64051020 |
Appl. No.: |
15/594737 |
Filed: |
May 15, 2017 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/306 20130101;
H04L 41/083 20130101; H04L 67/22 20130101; H04W 4/029 20180201;
H04L 41/0836 20130101; H04L 67/18 20130101; H04L 41/16 20130101;
H04L 41/147 20130101 |
International
Class: |
H04W 24/02 20060101
H04W024/02; H04L 29/08 20060101 H04L029/08; H04L 12/24 20060101
H04L012/24 |
Claims
1. A method, in a wirelessly-enabled device, for performing
anticipatory networking, comprising: detecting an interrupting
event; collecting first data relating to the interrupting event;
collecting second data relating to a condition of the
wirelessly-enabled device; and proactively performing one or more
downstream operations corresponding to the interrupting event,
wherein the one or more downstream operations are proactively
performed based at least in part on a combination of a likelihood
that the one or more downstream operations will be needed in order
to carry out the interrupting event and a cost of performing the
one or more downstream operation satisfying a predetermined
threshold, and wherein the one or more downstream operations are
proactively performed before third data corresponding to the one or
more downstream operations is requested.
2. The method of claim 1, wherein a user profile identifies the
likelihood that the one or more downstream operations will be
needed in order to carry out the interrupting event.
3. The method of claim 2, wherein the likelihood that the one or
more downstream operations will be needed in order to carry out the
interrupting event comprises at least one of a percentage chance of
the one or more downstream operations occurring and a total number
of times that the one or more downstream operations have
occurred.
4. The method of claim 1, further comprising: collecting fourth
data relating to downstream operations that are actually performed
in response to the interrupting event; and updating the
predetermined threshold based at least in part on the first,
second, and fourth data.
5. The method of claim 1, further comprising: collecting fourth
data relating to downstream operations that are actually performed
in response to the interrupting event; and updating a user profile
based at least in part on the first, second, and fourth data.
6. The method of claim 5, wherein the user profile is an existing
user profile.
7. The method of claim 5, wherein the user profile is a default
user profile.
8. The method of claim 1, wherein the interrupting event includes
at least one of a user action taken on the wirelessly-enabled
device, a third party action implicating the wirelessly-enabled
device, and the wirelessly-enabled device performing an automated
function.
9. The method of claim 8, wherein the one or more downstream
operations includes at least one of a DNS resolution, a VPN
establishment operation, a credential request operation, a location
request operation, a best network matching operation, a
service-edge selection operation, and a connection pre-flight
operation.
10. A wirelessly-enabled device, comprising: a processor; and
memory; the processor and memory configured to perform operations,
the operations comprising: detecting an interrupting event;
collecting first data relating to the interrupting event;
collecting second data relating to a condition of the
wirelessly-enabled device; and proactively performing one or more
downstream operations corresponding to the interrupting event,
wherein the one or more downstream operations are proactively
performed based at least in part on a combination of a likelihood
that the one or more downstream operations will be needed in order
to carry out the interrupting event and a cost of performing the
one or more downstream operation satisfying a predetermined
threshold, and wherein the one or more downstream operations are
proactively performed before third data corresponding to the one or
more downstream operations is requested.
11. The wirelessly-enabled device of claim 10, wherein the
likelihood that the one or more downstream operations will be
needed in order to carry out the interrupting event comprises at
least one of a percentage chance of the one or more downstream
operations occurring and a total number of times that the one or
more downstream operations have occurred.
12. The wirelessly-enabled device of claim 10, wherein the
operations performed by the processor and memory further comprise:
collecting fourth data relating to downstream operations that are
actually performed in response to the interrupting event; and
updating a user profile based at least in part on the first,
second, and fourth data.
13. The wirelessly-enabled device of claim 10, wherein the
interrupting event includes at least one of a user action taken on
the wirelessly-enabled device, a third party action implicating the
wirelessly-enabled device, and the wirelessly-enabled device
performing an automated function.
14. The wirelessly-enabled device of claim 10, wherein the one or
more downstream operations includes at least one of a DNS
resolution, a VPN establishment operation, a credential request
operation, a best network matching operation, a service-edge
selection operation, and a connection pre-flight operation.
15. The wirelessly-enabled device of claim 13, wherein the user
action taken on the wirelessly-enabled device includes at least one
of playing a song, initiating a phone call, launching an
application, scrolling through a list of contacts, swiping to an
alternate page of icons, and unlocking the wirelessly-enabled
device.
16. A non-transitory computer-readable medium having instructions
stored thereon that, when executed by at least one computing
device, causes the at least one computing device to perform
operations comprising: detecting an interrupting event; collecting
first data relating to the interrupting event; collecting second
data relating to a condition of a wirelessly-enabled device;
proactively performing one or more downstream operations
corresponding to the interrupting event, wherein the one or more
downstream operations are proactively performed based at least in
part on a combination of a likelihood that the one or more
downstream operations will be needed in order to carry out the
interrupting event and a cost of performing the one or more
downstream operation satisfying a predetermined threshold, and
wherein the one or more downstream operations are proactively
performed before third data corresponding to the one or more
downstream operations is requested; and updating a user profile
based at least in part on the collected first and second data.
17. The non-transitory computer-readable medium of claim 16,
wherein the user profile identifies the likelihood that the one or
more downstream operations will be needed in order to carry out the
interrupting event.
18. The non-transitory computer-readable medium of claim 17,
wherein the likelihood that the one or more downstream operations
will be needed in order to carry out the interrupting event
comprises at least one of a percentage chance of the one or more
downstream operations occurring and a total number of times that
the one or more downstream operations have occurred.
19. The non-transitory computer-readable medium of claim 16,
wherein the interrupting event includes at least one of a user
action taken on the wirelessly-enabled device, a third party action
implicating the wirelessly-enabled device, and the
wirelessly-enabled device performing an automated function.
20. The non-transitory computer-readable medium of claim 16,
wherein the one or more downstream operations includes at least one
of a DNS resolution, a VPN establishment operation, a credential
request operation, a location request operation, a best network
matching operation, a service-edge selection operation, and a
connection pre-flight operation.
Description
FIELD
[0001] This disclosure generally relates to wireless
communications, and more specifically to performing anticipatory
networking to improve network latency issues.
BACKGROUND
Related Art
[0002] Consumer electronic devices have become an important part of
people's everyday lives. These electronic devices include
everything from cellphones, laptops, tablets and smartwatches to
digital assistants and other wearables. More recently, many
consumer electronic devices have been adapted to include wireless
communication capabilities, such that these devices can communicate
and coordinate with one another, as well as with wireless access
points, cellular base stations, and end servers. For example, with
the increasingly widespread availability and use of
wirelessly-enabled electronic devices, individuals may now be able
to perform tasks, such as make and receive phone calls, stream
music and video, browse the internet, and interact with a plethora
of applications ("apps") all from the individuals' personal
wirelessly-enabled devices.
[0003] While these capabilities are certainly indicative of the
advancements made in the wireless communications industry over the
last decade, two significant issues have been, and continue to be,
the bottleneck for rapid future advancement in this industry. These
two issues can be generally categorized as bandwidth limitations,
and network latency issues. Over the past several years, various
techniques have been developed to address the first of these
issues: bandwidth limitations. These techniques include, for
example, combining communication channels to increase overall
bandwidth, implementing traffic scheduling schemes, and
implementing traffic prioritization schemes. Each of these
techniques, along with others, have to some extent helped address
the long standing bandwidth limitation issues, and have helped
ultimately usher in the past few generational advancements in the
wireless communications industry e.g., 2G to 3G, 3G to 4G, and the
impending transition from 4G to 5G.
[0004] However, the second issue that has been a constant
bottleneck for advancement in the wireless communication industry
network latency has proven to be a much more difficult problem to
solve. Network latency generally refers to the amount of time that
it takes for a packet of data to get from one point to another, and
is generally measured by calculating the time that it takes for a
packet to make one round trip from its origin point to its
destination, and back. This is generally referred to as the
packet's round trip time ("RTT"). Because network latency is tied
to the fundamental concept of how long it takes for a data packet
to travel between two points, and because that time generally
varies based on the current conditions of the air interface between
the two points (e.g., having to account for delays associated with
dropped packets), the wireless communication industry has largely
been unable to reduce these delay times, outside of minor
incremental improvements.
[0005] Moreover, network latency issues are compounded by the fact
that many actions implemented on today's wirelessly-enabled devices
require, and are dependent upon, multiple downstream operations.
For example, when a user opens a weather application on their
wirelessly-enabled device, that action may also prompt certain
downstream operations, each of which may require their own packet
transmissions, and thus their own round trip delays. Such
downstream operations can include, for example, obtaining the
wirelessly-enabled device's current location, generating targeted
advertisements for the user, and/or obtaining the user's account
information (if they have an existing account within the
application). Each of these downstream operations generally do not
begin until the data corresponding to these operations is actually
requested, and these data requests usually occur in a sequential
fashion (e.g., the data request may not occur until a corresponding
upstream action has been completed). Therefore, a delay in such a
data request (or a delay in a corresponding upstream action) will
necessarily cause a corresponding delay in completing the
downstream operation. As such, network latency issues are
particularly prevalent in today's sophisticated wirelessly-enabled
devices.
[0006] Currently, there are no existing solutions that are capable
of addressing these network latency issues, especially where the
network latency issues stem from round trip delays associated with
dependent downstream operations.
SUMMARY
[0007] The present disclosure provides system, apparatus, method,
and computer program product embodiments, and combinations and
sub-combinations thereof, for performing anticipatory networking to
improve latency issues.
[0008] In some embodiments, performing anticipatory networking may
include; detecting an action taken by a user of a
wirelessly-enabled device, an automated action of the
wirelessly-enabled device, or a current condition of the device;
learning what future operations the wirelessly-enabled device will
likely need to perform in order to carry out the desired user
action or device action; and proactively performing certain
downstream operations before the data corresponding to those
operations is actually needed. In some embodiments, the process of
performing anticipatory networking is intended to be carried out by
wirelessly-enabled devices such as cellphones and tablets, which
may be used for numerous different actions, and may be subjected to
many different conditions. However, the anticipatory networking
embodiments herein are equally applicable to any network-connected
device that could benefit from reduced network latency.
[0009] The anticipatory networking techniques disclosed herein are
advantageous because, for example, they can reduce application
start-up times and refresh times. The anticipatory networking
embodiments disclosed herein also reduce unexpected delays caused
by dropped data packets by ensuring that, if any data packets are
indeed dropped during the various downstream operations, that those
dropped packets occur during a proactive phase e.g., before the
data corresponding to those operations is actually needed. The
disclosed anticipatory networking techniques also match different
operations to advantageous networks (such as best possible networks
in some embodiments), such that each corresponding data packet can
be transmitted over the network that advantageously matches the
operation's specific needs. Indeed, some operations may be best
suited for Wi-Fi data intensive operations), while for other
operations, cellular may be a suitable communication mode (e.g.,
when minimal amounts of data need to be transmitted) when Wi-Fi is
unavailable or unreliable. However, the quality of a particular
network generally cannot be determined until data is actually
transmitted over the network. Therefore, the anticipatory
networking techniques disclosed herein allow for data corresponding
to downstream operations to be transmitted over available networks
during the proactive phase, such that advantageous or even the best
possible network(s) are identified before the data corresponding to
those operations is actually needed.
[0010] The anticipatory networking techniques disclosed herein may
be applicable to several different types of wireless technologies,
such as, without limitation, Wi-Fi, Bluetooth, radio-frequency
identification (RFID), near field communications (NFC), 60 GHz
communications, and cellular communication, as well as several
different types of wirelessly-enabled devices.
[0011] In some embodiments, the process of performing anticipatory
networking disclosed herein may include detecting an action taken
by a user of a wirelessly-enabled device. User actions can include,
for example, playing a song, initiating a phone call, or launching
an application (e.g., a weather application, a map application, or
a game). The disclosed anticipatory networking embodiments may also
include detecting an automated action of the wirelessly-enabled
device. Automated device actions can include automatically
connecting to a known wireless access point, or automatically
pinging a base station, to name just some examples. The disclosed
process of performing anticipatory networking may also include
detecting a current condition of the wirelessly-enabled device,
such as the device's current location, the time of day where the
device is located, whether the device is plugged in, or Whether the
device is in a moving vehicle.
[0012] The wirelessly-enabled device may then collect data relating
to how the user typically interacts with the device, and what the
user's preferences are for different applications running on the
device and for different actions initiated on the device. The
wirelessly-enabled device may also collect data relating to the
condition of the device when each action was initiated. Using these
pieces of data, the wirelessly-enabled device can learn how to best
meet the user's needs, and in doing so, the wirelessly-enabled
device can anticipate what future operations will likely be needed
in order to carry out the desired user actions or device actions.
Subsequently, based on this learning, the wirelessly-enabled device
may be able to proactively perform certain downstream operations
before the data corresponding to those operations is actually
needed, thereby reducing network latency.
[0013] Therefore, the anticipatory networking techniques disclosed
herein essentially represent the confluence of networking concepts
and machine learning concepts, and as such, enable wireless
communications having reduced latency, while also improving network
reliability and device performance.
BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES
[0014] Embodiments of the disclosure are described with reference
to the accompanying drawings. In the drawings, generally, like
reference numbers indicate identical or functionally similar
elements. Additionally, generally, the left most digit(s) of a
reference number identifies the drawing in which the reference
number first appears.
[0015] FIG. 1 illustrates a block diagram of a first wireless
communication environment, according to some embodiments.
[0016] FIG. 2 illustrates a block diagram of a second wireless
communication environment, according to some embodiments.
[0017] FIG. 3 is a graphical representation of an exemplary user
profile, according to some embodiments.
[0018] FIG. 4 is a flowchart of exemplary operational steps of
performing anticipatory networking, according to some
embodiments.
[0019] FIG. 5 illustrates a block diagram of a wirelessly-enabled
device, according to some embodiments.
DETAILED DESCRIPTION
[0020] FIG. 1 illustrates a block diagram of a first wireless
communication environment 100 according to some embodiments. A
wireless communication environment 100 provides wireless
communication of information and objects, such as one or more
commands and/or data, between a wirelessly-enabled device 110, a
networking element 120, and any number of servers, such as servers
130, 132, and 134. Those skilled in the relevant art(s) will
recognize that wirelessly-enabled device 110 may be configured to
communicate using any combination of Wi-Fi, Bluetooth,
radio-frequency identification (RFID), near field communications
(NFC), 60 GHz communications, cellular communication, or the like.
Additionally, in some embodiments, wirelessly-enabled device 110
may be implemented as a standalone or a discrete device or may be
incorporated within or coupled to another electrical device or host
device, such as a cellphone, smartwatch, portable computing device,
a camera, or a Global Positioning System (GPS) unit or another
computing device such as a personal digital assistant, a video
gaming device, a laptop, a desktop computer, or a tablet, a
computer peripheral such as a printer or a portable audio and/or
video player, and could also be implemented as a key fob, or a
household appliance, to name just some examples and/or any other
suitable electronic device that will be apparent to those skilled
in the relevant art(s) without departing from the spirit and scope
of the present disclosure.
[0021] In an embodiment, wirelessly-enabled device 110 may be
configured to transmit a first wireless signal 140 toward
networking element 120 using any acceptable modulation scheme.
Networking element 120 may be a component, or collection of
components, that makes it possible for wirelessly-enabled device
110 to gain network access, and to ultimately access servers
130-134. For example, networking element 120 may represent a access
point, a cellular base station (e.g., macrocell base station,
microcell base station, or femtocell base station), or the like.
Networking element 120 may be configured to receive first wireless
signal 140, process signal 140 and, if necessary, transmit a second
wireless signal 150 back to wirelessly-enabled device 110. In this
manner, wirelessly-enabled device 110 and networking element 120
exchange information ("communicate") with one another. The signals
exchanged between wirelessly-enabled device 110 and networking
element 120 may represent any number of different signals types,
including: scanning signals (e.g., "beacons"), command signals,
information requests, or data packets, to name just some
examples.
[0022] Servers 130-134 may each represent a standalone network
server, or they may represent different partitions of a single
network server. In some embodiments, servers 130-134 may each
individually, or collectively, function as a computer system that
serves as a central repository of data and programs shared by users
and/or devices in wireless communication environment 100. Servers
130-134 may represent any one of a file server, communications
server, application server, database server, and/or domain server,
to name some examples. Moreover, three servers 130-134 are shown in
FIG. 1 for illustrative purposes only. In some embodiments,
wireless communication environment 100 may include more or less
servers without departing from the spirit and scope of the present
disclosure.
[0023] As an illustrative example, wirelessly-enabled device 110
may begin in an idle state where a user of wirelessly-enabled
device 110 is not interacting with the device, where
wirelessly-enabled device 110 is not currently performing automated
functions, such as automatically connecting to a known wireless
access point, and where a third party individual or device is not
currently attempting to communicate with the user through
wirelessly-enabled device 110 (e.g., via an incoming phone call, an
incoming SMS text message, or the like). Then, at some point in
time, wirelessly-enabled device 110's idle state may be
interrupted. In some embodiments, wirelessly-enabled device 110's
idle state may be interrupted by several different events, such as:
(i) the user of wirelessly-enabled device 110 initiating an action
on the device; (ii) a third party individual or device attempting
to communicate with the user through wirelessly-enabled device 110;
and (iii) wirelessly-enabled device 110 performing an automated
function. User actions taken on wirelessly-enabled device 110 can
include, for example, playing a song, initiating a phone call, or
launching an application (e.g., a weather application, a map
application, or a game). Additionally, interrupting events
initiated by third party individuals or devices can include, for
example, an incoming phone call, an incoming SMS text message, an
incoming email, or an incoming video call. Further, automated
functions of wirelessly-enabled device 110 that can interrupt its
idle state can include, for example, automatically connecting to a
known wireless access point, or automatically pinging a base
station. The foregoing are provided solely for illustrative
purposes only, and this disclosure is not limited to those
examples.
[0024] Once wirelessly-enabled device 110 detects that one of the
above interrupting events has occurred, wirelessly-enabled device
110 then begins to collect data relating to the event and to the
current condition of device 110. Such event-related data may
include the type of event, parties involved in the event (e.g.,
automated, single user, or multiple users), device resources needed
to carry out the action(s) requested by the interrupting event,
and/or network resources needed to carry out the requested
actions(s), to name some examples. Additionally, data relating to
the current condition of wirelessly-enabled device 110 may include,
for example, the device's current location, the time of day where
the device is located, whether the device is plugged in, and/or
whether the device is in a moving vehicle, to name some
examples.
[0025] Once wirelessly-enabled device 110 collects this data
relating to the interrupting event, wirelessly-enabled device 110
generally does one of two things. For example, wirelessly-enabled
device 110 may either use the collected data to build a new user
profile relating to how the user typically interacts with
wirelessly-enabled device 110 after the detected interrupting event
has occurred, or wirelessly-enabled device 110 may compare the
collected data to an existing user profile to determine how
wirelessly-enabled device 110 should respond to the detected
interrupting event to meet the user's needs. In other words, once a
user profile has been built, wirelessly-enabled device 110 may use
the collected data to anticipate what downstream operations will
likely be needed in order to cans out the desired user action(s) or
device action(s), or to handle a third party communication request.
In some embodiments, the process of collecting data relating to
interrupting events, and building a user profile may be referred to
as machine learning. Ultimately, using these machine learning
techniques, wirelessly-enabled device 110 may be able to anticipate
and proactively perform certain downstream operations before the
data corresponding to those operations is actually needed, thereby
reducing network latency.
[0026] In some embodiments, even when a profile already exists for
the user of wirelessly-enabled device 110, the device may still use
the collected data to update (e.g., refine) the existing profile.
This updating process may help ensure that wirelessly-enabled
device 110 is able to respond properly to interrupting events even
as the user's preferences change over time.
[0027] For instances where a new user profile needs to be built, it
may take wirelessly-enabled device 110 some period of time (such as
approximately up to a week in some situations) before the user
profile becomes viable and is able to provide accurate predictions
for what downstream operations may be needed. Conversely, in
situations where a user profile already exists, it may take a
shorter period of time (such as approximately five minutes in some
situations) to update the profile to account for newly collected
data. In some embodiments, an existing user profile may be update
daily, and the updating process may be programmed to take place
overnight. It may be beneficial to have the updating process take
place overnight because the process may be relatively processor
intensive, and the late night/early morning hours may offer the
best chance for wirelessly-enabled device 110 to be plugged in and
not in use. However, the user profile updating process may take
place at other times, and at other frequencies, without departing
from the spirit and scope of the present disclosure.
[0028] Additionally, or alternatively, wirelessly-enabled device
110 may be preloaded with a default user profile, such that the
process of building a unique user profile from scratch may be
avoided. In some embodiments, a default user profile may be
preloaded on other wirelessly-enabled devices belonging to the same
user (or owner) of wirelessly-enabled device 110.
[0029] When the disclosed machine learning techniques are applied
to the wireless communication context illustrated by wireless
communication environment 100, for example then wirelessly-enabled
device 110 may then be capable of performing anticipatory
networking. In some embodiments, anticipatory networking may allow
wirelessly-enabled device 110 to reduce network latency by reducing
delays caused by downstream operations relating to the particular
interrupting event.
[0030] FIG. 2 illustrates a block diagram of a second wireless
communication environment 200 according to some embodiments. The
second wireless communication environment 200 may represent an
exemplary embodiment of wireless communication environment 100
illustrated in FIG. 1, and as such, may provide wireless
communication of information, such as one or more commands and/or
data, between a wirelessly-enabled device 210, a networking element
220, and servers 230, 232, and 234. In the example embodiment shown
in FIG. 2, wirelessly-enabled device 210 may be configured to
transmit wireless signals 240, 242, and 246 toward networking
element 220 using any acceptable communication protocol and
modulation scheme. Wirelessly-enabled device 210 may represent an
exemplary embodiment of wirelessly-enabled device 110, networking
element 220 may represent an exemplary embodiment of networking
element 120, and servers 230-234 may represent exemplary
embodiments of servers 130-134. Therefore, an extensive discussion
of the operational features that overlap between the network
elements illustrated in FIG. 1 (e.g., wirelessly-enabled device
110, networking element 120, and servers 130-134) and the
corresponding elements illustrated in FIG. 2 (e.g.,
wirelessly-enabled device 210, networking element 220, and servers
230-234) will be omitted from the discussion here. Instead,
reference will be made to the similar operational features
discussed with reference to FIG. 1, and the corresponding
discussion from FIG. 1 will apply equally to the discussion of the
elements in FIG.
[0031] As similarly discussed above, wirelessly-enabled device 210
may start out in an idle state, but in some embodiments, that idle
state may be interrupted at any point in time by an interrupting
event. The interrupting event may take several different forms,
including: (i) a user of wirelessly-enabled device 210 initiating
an action on the device; (ii) a third party individual or device
attempting to communicate with the user through wirelessly-enabled
device 210; and/or (iii) wirelessly-enabled device 210 performing
an automated function. However, for illustrative purposes, the
anticipatory networking techniques performed by wirelessly-enabled
device 210 will be discussed below in the context of the
interrupting event being a user-initiated action. Importantly,
however, the present disclosure is not so limited. Instead, the
anticipatory networking techniques disclosed herein may be used to
reduce network latency issues associated with any of the
above-referenced as well as other examples of interrupting
events.
[0032] As illustrated in FIG. 2, at a point in time (t.sub.0),
wirelessly-enabled device 210's idle state may be interrupted by a
user action 260. As an illustrative example, user action 260 may
represent a user deciding to play a song from the user's library
through wirelessly-enabled device 210. As will be apparent to
persons skilled in the relevant art(s) from the teachings herein,
numerous downstream operations may need to be performed in order
for user action 260 (e.g., playing a song using wirelessly-enabled
device 210) to be carried out. For example, the user deciding to
play a song from wirelessly-enabled device 210 may prompt
wirelessly-enabled device 210 to: verify the user's music library
credentials; check to see if new or variant songs, matching the
user's chosen song, are available; check for any local upcoming
concerts; and ultimately pull the necessary data from servers
230-234 to play the user's chosen song.
[0033] In some embodiments, these downstream operations may be
performed by daemons 250, 252, and 254 running on
wirelessly-enabled device 210. Daemons 250-254 may each represent a
type of program designed to run on wirelessly-enabled device 210's
operating system, and to run unobtrusively in the background,
rather than under the direct control of the user. Daemons 250-254
may also be configured to be idle until being activated by the
occurrence of an interrupting event. In an embodiment, daemons
250-254 may also be referred to as specialists.
[0034] The downstream options needed to carry out user action 260
may each require the retrieval of data from servers 230-234. For
example, in order to verify the user's music library credentials
(performed by daemon 250, for example), the user's credentials may
need to be retrieved from servers 230-234, Additionally, in order
to see if any local concerts are coming up (performed by daemon
252, for example), location information, concert venue information,
and band tour information may need to be retrieved from servers
230-234. Finally, daemon 254, for example, may ultimately pull the
necessary song data from servers 230-234. Because each of these
downstream operations may require retrieval of data from servers
230-234, each of these operations may contribute to the overall
network latency relating to user action 260.
[0035] As discussed above, network latency generally refers to the
amount of time that it takes for a packet of data to travel from
one point to another, and is generally measured by calculating the
time that it takes for a packet to make one round trip from its
origin point to its destination, and back. This is generally
referred to as the packet's round trip time ("RTT").
[0036] As illustrated in FIG. 2, the downstream operations
performed by daemons 250-254 may be dependent on other operations.
In other words, certain downstream operations, which may be needed
to carry out user action 260, may not begin until other operations
are completed. For example, before checking for any local upcoming
concerts (performed by daemon 252, for example), daemon 256 may
first need to acquire wirelessly-enabled device 210's current
location, and daemon 258 may need to check the user's music
preferences and/or recently played songs, such that daemon 252 has
the necessary band and location information to be able to retrieve
the appropriate data from servers 230-234.
[0037] Therefore, instead of the downstream operations performed by
daemons 250-254 being able to start at time t.sub.0 (e.g.,
immediately following user action 260), these downstream operations
may not commence until later in time (e.g., times t.sub.2, or
t.sub.4, for example). These delayed start times, therefore,
compound the overall network latency associated with user action
260. For example, if the downstream operations performed by daemons
250-254 were able to begin at time t.sub.0, then the overall
network latency for user action 260 may be approximately equal to
the longest round trip time for these downstream options. However,
due to the dependency of the downstream operations performed by
daemons 250-254, the overall network latency for user action 260
may be approximately equal to time t.sub.4 plus the round trip time
associated with acquiring the necessary song data from servers
230-234 (performed by daemon 254 beginning at time t.sub.1, for
example).
[0038] Additionally, or alternatively, even if the downstream
operations performed by daemons 250-254 were not dependent on other
operations, in some embodiments those downstream operations may
still not begin until the data corresponding to those operations is
specifically requested. Such delayed requests may also increase the
overall network latency associated with user action 260.
[0039] However, according to some embodiments, using the
anticipatory networking techniques disclosed herein, the start
times for certain downstream operations, such as those performed by
daemons 250-254, may be allowed to commence at earlier points in
time (e.g., times t.sub.0 or t.sub.1), thereby reducing the overall
network latency associated with user action 260. Indeed, utilizing
a user profile (either building a new user profile from data
collected relating to user action 260 and to the current condition
of wirelessly-enabled device 210, or using an existing user
profile), wirelessly-enabled device 210 can anticipate what
downstream operations will likely be needed to carry out user
action 260. Therefore, instead of not realizing until time t.sub.2
that the user's music library credentials are needed to carry out
user action 260, or not realizing until time t.sub.3 that a listing
of upcoming local concerts are needed, these downstream operations
can be anticipated, thereby allowing these operations to begin
earlier in time (e.g., times t.sub.0 or t.sub.1) and before the
data relating to those operations is actually needed.
[0040] In some embodiments, wirelessly-enabled device 210 may
anticipate and proactively perform certain downstream operations
based on various weighted threshold calculations. Indeed,
wirelessly-enabled device 210 may determine the likelihood of a
downstream operation being needed based on a user's existing user
profile. The likelihood of a downstream operation being needed may
represent a percentage chance of the operation occurring, or a
total number of times that the operation has occurred, to name just
some examples. The likelihood of a specific downstream operation
being needed may then be weighed against the relative cost of
performing an unnecessary downstream operation. Therefore,
wirelessly-enabled device 210 may decide to proactively perform a
downstream operation when the combination of the likelihood of the
operation being needed and the relative cost of the operation
satisfies a predetermined threshold. For example, if the likelihood
that an operation will be needed is relatively low, e.g., 60%, that
operation may still be performed if the cost of the operation is
equally low, e.g., a DNS resolution (which generally only requires
the transmission of a single data packet). However, a costly
operation, such as obtaining credentials or setting up encryption,
may require a relatively higher likelihood of occurring, e.g., 90%,
before that downstream operation is proactively performed. This
predetermined threshold may also be adjusted e.g., during the user
profile update process to reflect recent correct and incorrect
predictions.
[0041] As discussed above, in some embodiments, user action 260 may
represent other actions besides the user playing a song on
wirelessly-enabled device 210, such as opening a weather
application, playing a game, making a phone call, or connecting to
a Wi-Fi access point, to name just some examples. Additionally,
user action 260 may represent an action that is self-contained on
wirelessly-enabled device 210. For example, user action 260 may
include a user scrolling through a list of contacts or songs,
swiping to an alternate page of icons on wirelessly-enabled device
210, or unlocking wirelessly-enabled device 210. Wirelessly-enabled
device 210 may also collect data relating to these self-contained
actions to anticipate when the user might stop scrolling or
swiping, and what action is likely to follow. In doing so,
wirelessly-enabled device 210 may be able to predict what
application the user may launch, what contact the user might call,
or what playlist the user might select before those actions are
actually taken.
[0042] The downstream operations illustrated in FIG. 2 may also be
initiated by other interrupting events besides user actions
including, for example, a third party individual or device
attempting to communicate with the user through wirelessly-enabled
device 210, or wirelessly-enabled device 210 performing an
automated function. Moreover, the downstream operations discussed
herein relating to user action 260 are presented for illustrative
purposes, and are not intended to limit the scope of the present
disclosure in any way. Indeed, numerous other downstream operations
may be prompted by user action 260, and different combinations of
downstream operations may be prompted when user action 260
represents a third party action, or an automated function of
wirelessly-enabled device 210 without departing from the spirit and
scope of the present disclosure. In some embodiments, the
downstream operations illustrated in FIG. 2 may be user action
dependent, meaning that the downstream operations that are capable
of being proactively performed may vary from action to action.
[0043] Moreover, mobile applications can behave differently
depending on the user that is interacting with them. As such,
applications running on wirelessly-enabled device 210 may behave
differently than applications running on a different user's device.
Therefore, the downstream operations that are needed to carry out
user action 260 (when user action 260 represents a user interacting
with an application running on wirelessly-enabled device 210) may
be different from the downstream operations that are needed to
carry out the same action on a different user's device. Thus, the
disclosed anticipatory networking techniques may be user dependent,
and in some embodiments may be both user dependent and device
depended, such that the disclosed anticipatory networking
techniques may be adjusted to accurately reflect how a specific
user interacts with a specific device.
[0044] In some instances, the data collected relating to how the
user typically interacts with wirelessly-enabled device 210, and
what the user's preferences are for different applications running
on the device and for different actions initiated on the device may
be applied to other devices belonging to the user. In other words,
a user profile generated on wirelessly-enabled device 210 may be
applicable, at least in part, to other wirelessly-enabled devices
owned by the user. For example, information pertaining to how the
user interacts with its music library or weather application on
wirelessly-enabled device 210 (e.g., a cellphone) may be useful in
helping anticipate and proactively perform downstream operations in
response to the user playing music or opening a weather application
on a different device (e.g., a tablet or wearable). In some
embodiments, the user profile generated on wirelessly-enabled
device 210 may be shared with other devices belonging to the user
by accessing a shared cloud storage, for example.
[0045] Further, the disclosed anticipatory networking techniques
may vary based on a current condition of wirelessly-enabled device
210. Therefore, the downstream operations that are needed to carry
out user action 260 may be different depending on the current
condition of wirelessly-enabled device 210, For example, the user
of wirelessly-enabled device 210 may interact with the device
differently when the user is on vacation, when it is late at night,
or when the user is driving. Indeed, the user may want a Virtual
Private Network ("VPN") to be established for actions when the user
travels to a location that is particularly susceptible to security
breaches, and/or the user may not want advertisements, or music
related information displayed while they are driving. Therefore, as
discussed above, the user's profile also takes into account these
device conditions, and thus allows proactive performance of
downstream operations to be varied accordingly.
[0046] Other downstream operations that may be implicated by the
anticipatory networking techniques disclosed herein, and that may
be performed before the data relating to those operations is
actually needed, include, for example:
[0047] Domain Name Resolution ("DNS Resolution"): DNS resolution
refers to the task of converting domain names, in textual form, to
their corresponding IP address, generally represented by a string
of numbers and decimals points. In some instances, a DNS resolution
may include a daemon within wirelessly-enabled device 210 sending a
request to a domain server e.g., server 230) for an IP address that
corresponds to a given domain name. Using the anticipatory
networking techniques disclosed herein, wirelessly-enabled device
210 may anticipate what domain names may ultimately be implicated
by user action 260, and may perform the DNS resolutions before the
corresponding IP addresses are actually needed. In this way, the
desired IP address(es) may have already been retrieved (e.g., at
time t.sub.0) from server 130 before the IP address(es) is even
requested, which may not occur until time t.sub.1, t.sub.2, or
t.sub.3.
[0048] Virtual Private Network ("VPN") Establishment: VPN
establishment refers to the process of setting up a private network
that extends across a public network. By establishing a VPN, users
can send and receive data across shared or public networks as if
their devices were directly connected to the private network.
Applications running across the VPN may therefore benefit from the
functionality, security, and management of the private network. As
one example, a VPN may be beneficial when using wirelessly-enabled
device 210 to access a corporate email account or file server.
Using the anticipatory networking techniques disclosed herein, when
a user opens their banking application on wirelessly-enabled device
210, wirelessly-enabled device 210 may anticipate that a VPN needs
to be established. Wirelessly-enabled device 210 may then assign a
daemon to perform the VPN establishment operation at time t.sub.0
or t.sub.1, for example, before the VPN is actually needed (e.g.,
at time t.sub.4).
[0049] Best network matching: The disclosed anticipatory networking
techniques may also match different user actions and corresponding
downstream operations) to advantageous networks, such that each
corresponding data packet can be transmitted over the network that
advantageously matches the action's specific needs. Indeed, some
actions may be best suited for Wi-Fi (e.g., data intensive
operations), while for other actions, cellular may be a suitable
communication mode (e.g., when minimal amounts of data need to be
transmitted). However, the quality of a particular network
generally cannot be determined until data is actually transmitted
over the network. Therefore, the anticipatory networking techniques
disclosed herein allow for data corresponding to downstream
operations to be transmitted over available networks during a
proactive phase--e.g., before the data corresponding to those
downstream operations is actually needed--such that the best
possible network(s) are identified as early as possible.
[0050] Service-Edge Selection: Service-edge selection refers to the
process of determining the ideal server(s) to send
wirelessly-enabled device 210's various data requests. In some
embodiments, wirelessly-enabled device 210 may maintain a latency
map corresponding to various servers located across the world.
Therefore, given certain pieces of information, such as
wirelessly-enabled device 210's current location, and the detected
user action, wirelessly-enabled device 210 can use this latency map
to determine Which server(s) to send the corresponding data
requests. Again, using the anticipatory networking techniques
disclosed herein, wirelessly-enabled device 210 can identify the
ideal servers to service the necessary data requests before the
data is actually needed.
[0051] Location Refresh: Using anticipatory networking,
wirelessly-enabled device 210 may also be capable of determining
whether the device's location needs to be refreshed, and if so,
proactively performing the refresh operation. Indeed,
wirelessly-enabled device 210 may automatically determine whether
the device's last known location matches its current location, and
if not, wirelessly-enabled device 210 may request its current
latitude and longitudinal coordinates from server 130, before the
location actually becomes needed to carry out user action 260.
[0052] Credential Refresh: Wirelessly-enabled device 210 may
similarly use the anticipatory networking techniques disclosed
herein to determine whether the user's credentials needs to be
refreshed, and if so, proactively perform the refresh operation
before the new credentials actually become needed to carry out user
action 260.
[0053] Connection Pre-Flight Operations: In some embodiments,
wirelessly-enabled device 210 may be able to use the anticipatory
networking techniques disclosed herein to anticipate and
proactively perform operations associated with any of the first
five layers of the Open Systems interconnection model (OSI
model)--e.g., Physical layer, Data Link Layer, Network Layer,
Transport Layer, and/or Session Layer. For example,
wirelessly-enabled device 210 may anticipate and proactively
perform Address Resolution Protocol (ARP) operations, Transmission
Control Protocol (TCP) three-way handshake operations, and/or
Transport Layer Security (TLS) operations. As such, Connection
Pre-Flight Operations may include a variety of pre-requisite
operations that may be required before actual content can be
obtained from a particular server.
[0054] By anticipating and proactively performing certain
downstream operations, wirelessly-enabled device 210 can reduce the
risk of network failures, which in turn reduces application
start-up times and refresh times. For example, the anticipatory
networking techniques disclosed herein allow wirelessly-enabled
device 210 to anticipate a Wi-Fi network failure, thus allowing
wirelessly-enabled device 210 to switch to a cellular network
without interrupting the performance of user action 260.
Additionally, by proactively performing these downstream
operations, wirelessly-enabled device 210 can also reduce
unexpected delays caused by events such as dropped data
packets.
[0055] In some embodiments, the anticipatory networking techniques
disclosed herein can reduce overall network latency for a user
action by approximately ten milliseconds up to approximately five
to ten seconds (e.g., when wirelessly-enabled device 210 reaches
the outer limits of networking element 220's communication range,
and where data packets may be more prone to being dropped).
However, the reduction in overall network latency may be less or
more for other user actions based on the user, the device, the
device condition, the user action, etc.
[0056] FIG. 3 is a graphical representation of an exemplary user
profile 300, according to some embodiments. For illustrative
purposes, the exemplary user profile 300 of FIG. 3 is described
with reference to embodiments of FIG. 2. However, user profile 300
is not limited to these embodiments.
[0057] As discussed above, once wirelessly-enabled device 210
detects an interrupting event, the device 210 begins to collect
several pieces of data relating to the interrupting event and to
the current condition of wirelessly-enabled device 210. Such
event-related data may include the type of event, parties involved
in the event (e.g., automated or user initiated), device resources
needed to carry out the action(s) requested by the interrupting
event, and network resources needed to carry out the requested
actions(s), to name just some examples. Additionally, data relating
to the current condition of wirelessly-enabled device 210 may
include, for example, the device's current location, the time of
day Where device 210 is located, whether device 210 is plugged in,
or whether device 210 is in a moving vehicle.
[0058] After this data is collected, wirelessly-enabled device 210
may either use the collected data to build a new user profile
relating to how the user typically interacts with
wirelessly-enabled device 210 after the detecting the interrupting
event, or wirelessly-enabled device 210 may compare the collected
data to an existing user profile to determine how device 210 should
respond to the detected interrupting event to best meet the user's
needs. In other words, once a user profile has been built,
wirelessly-enabled device 210 may use the collected data to
anticipate what future operations will likely be needed in order to
carry out the desired user action(s) or device action(s), or to
handle an incoming third party communication request (e.g.,
incoming SMS text message, phone call, or video call request).
[0059] User profile 300 is an exemplary representation of an
existing user profile that may have been built by
wirelessly-enabled device 210. In some embodiments, user profile
300 may represent a relational database (e.g., depicting the
relationship between interrupting events and available downstream
operations). However, the data comprising user profile 300 may also
be stored in different ways without departing from the spirit and
scope of the present disclosure.
[0060] User profile 300 may include an entry for every interrupting
event that has taken place on wirelessly-enabled device 210.
Additionally, or alternatively, user profile 300 may include an
entry for less than all of the detected interrupting events. For
example, user profile 300 may include an entry for an interrupting
event only when that event has occurred more than a predetermined
number of times. Nonetheless, interrupting event entries may be
represented as a series of rows in a database Event 1, Event 2,
Event 3, Event 4, and Event N in FIG. 3. In some embodiments,
Events 1, 2, N may each represent an interrupting event, such as
the user playing a song on wirelessly-enabled device 210, the user
initiating a phone call, the user launching an application (e.g., a
weather application, a map application, or a game), a third party
sending an incoming phone call, SMS text message, email, or
incoming video call request, or wirelessly-enabled device 210
automatically connecting to a known wireless access point, or
automatically pinging a base station, to name just some
examples.
[0061] Moreover, user profile 300 may also include an entry for
every possible downstream operation that wirelessly-enabled device
210 may need to perform in order to carry out a particular
interrupting event. Additionally, or alternatively, user profile
300 may include an entry for less than all of the possible
downstream operations. For example, user profile 300 may include an
entry for a downstream operation only when that operation has
occurred more than a predetermined number of times. In any event,
downstream operation entries may be represented as a series of
columns in a database e.g., Op 1, Op 2, Op 3, Op 4, Op 5, Op 6, and
Op N in FIG. 3. In some embodiments, Ops 1, 2, . . . N may each
represent a downstream operation, such as a DNS resolution, a TCP
three-way handshake, a user credential request/refresh, a
wirelessly-enabled device 210 location request/refresh, a VPN
establishment, a service-edge selection, or the like.
[0062] Therefore, once an interrupting event occurs and
wirelessly-enabled device 210 collects the available event-related
data and device condition data, wirelessly-enabled device 210 may
then consult user profile 300 to determine what, if any,
anticipatory networking techniques can be implemented in order to
reduce network latency associated with the detected interrupting
event.
[0063] As an illustrative example. Event 1 may represent a user of
wirelessly-enabled device 210 launching a map application, and
Event 2 may represent wirelessly-enabled device 210 automatically
connecting to a known wireless access point. Additionally, Op 1 may
represent a location request operation, Op 2 may represent a VPN
establishment operation, Op 3 may represent credential request
operation, etc. . . . . In such a scenario, when wirelessly-enabled
device 210 detects that the user has launched the map application,
wirelessly-enabled device 210 may look up the first row in user
profile 300 (illustrated as Event 1 in FIG. 3) to see which
downstream operations are likely needed in order to successfully
launch the map application. In doing so, wirelessly-enabled device
210 may determine that Op 1 (e.g., a location request operation),
Op 3 (e.g., a credential request operation), Op 4, and Op 6 are
likely needed, Therefore, wirelessly-enabled device 210 may
initiate Ops 1, 3, 4, and 6 immediately after the interrupting
event is detected, instead of waiting an indeterminate time period
until the data corresponding to Ops 1, 3, 4, and 6 is actually
requested.
[0064] Conversely, in a scenario where wirelessly-enabled device
210 automatically connects to a known wireless access point, the
device may then look up the second row in user profile 300
(illustrated as Event 2 in FIG. 3) to see which downstream
operations are likely needed in order to successfully connect to
the access point. In doing so, wirelessly-enabled device 210 may
determine that Op 2 (e.g., a VPN establishment operation), Op 3
(e.g., a credential request operation), Op 4, and Op 5 are likely
needed. Therefore, wirelessly-enabled device 210 may initiate Ops
2-5 immediately after the interrupting event is detected, instead
of having to wait until the data corresponding to Ops 2-5 is
actually requested.
[0065] In some embodiments, to the extent possible,
wirelessly-enabled device 210 may perform each downstream operation
that is likely to be needed substantially simultaneously (e.g.,
immediately following the interrupting event), and may not have to
perform the operations sequentially. Moreover, user profile 300 may
represent a simplified version of the actual user profiles
disclosed herein. For example, in some embodiments, Ops 1-N may be
further broken down based on the current condition of
wirelessly-enabled device 210 when the interrupting event is
detected. In such instances, Op 1 may be performed in response to
Event 1 under some device conditions (e.g., during daytime hours),
but may not be performed under other device conditions (e.g.,
during nighttime hours). Therefore, user profile 300 is presented
for illustrative purposes only, and is not intended to limit the
spirit or scope of the present disclosure in anyway.
[0066] FIG. 4 is a flowchart or method 400 of exemplary operational
steps of performing anticipatory networking according some
embodiments. This disclosure is not limited to this operational
description. Rather, it will be apparent to persons skilled in the
relevant art(s) from the teachings herein that other operational
control flows are within the spirit and scope of the present
disclosure. The following discussion describes the steps in FIG. 4.
For illustrative purposes, the flowchart 400 of FIG. 4 is described
with reference to embodiments of FIG. 2. However, flowchart 400 is
not limited to these embodiments.
[0067] The method 400 begins with operation 402, where
wirelessly-enabled device 210 is in an idle state. In some
embodiments, the idle state may represent a state where a user of
wirelessly-enabled device 210 is not currently interacting with the
device, where wirelessly-enabled device 210 is not currently
performing automated functions, such as automatically connecting to
a known wireless access point, and where a third party individual
is not currently attempting to communicate with the user through
wirelessly-enabled device 210 (e.g., via an incoming phone call or
an incoming SMS text message, or the like).
[0068] In operation 404, wirelessly-enabled device 210 may detect
an interrupting event. As discussed previously herein, the
interrupting event may represent, for example: (i) the user of
wirelessly-enabled device 210 initiating an action on the device;
(ii) a third party individual or device attempting to communicate
with the user through wirelessly-enabled device 210; or (iii)
wirelessly-enabled device 210 performing an automated function.
[0069] In operation 406, wirelessly-enabled device 210 may collect
data relating to the interrupting event. Such event-related data
may include the type of event, parties involved in the event (e.g.,
automated, single user, or multiple users), device resources needed
to carry out the action(s) requested by the interrupting event, and
network resources needed to carry out the requested actions(s), to
name just some examples.
[0070] In operation 408, wirelessly-enabled device 210 may collect
data relating to the current condition of the device. In some
embodiments, the device condition data may include, for example,
the device's current location, the time of day where the device is
located, whether the device is plugged in, or whether the device is
in a moving vehicle.
[0071] In operation 410, a determination is made as to whether a
user profile already exists on wirelessly-enabled device 210. If it
is determined in operation 410 that a user profile does already
exist, then the operational flow proceeds to operation 412. In
operation 412, wirelessly-enabled device 210 performs the
anticipatory networking techniques disclosed herein in accordance
with the existing user profile. For example, wirelessly-enabled
device 210 may consult user profile 300 to determine what, if any,
downstream operations can be proactively performed in order to
reduce network latency associated with the detected interrupting
event. Indeed, by anticipating and proactively performing the
downstream operations identified in user profile 300 (e.g.,
anticipatory networking), wirelessly-enabled device 210 can reduce
the risk of network failures, which in turn reduces application
start-up times and refresh times. Additionally, by proactively
performing these downstream operations, wirelessly-enabled device
210 can also reduce unexpected delays caused by events such as
dropped data packets.
[0072] In operation 414, wirelessly-enabled device 210 may collect
data relating to what downstream operations were actually needed to
carry out the interrupting event (as opposed to what downstream
operations were anticipated by user profile 300).
[0073] In operation 416, the existing user profile is updated to
reflect the newly collected data from operation 414. For example,
wirelessly-enabled device 210 may use the collected data relating
to the interrupting event, to the condition of the device, and to
the downstream operations that were actually needed to refine the
entries in user profile 300. In some embodiments, updating user
profile 300 may include adding entries into the user profile
relating to new interrupting events, adding entries into user
profile 300 relating to new downstream operations, or adjusting
predetermined thresholds to reflect recent correct and/or incorrect
downstream operation predictions. Additionally, or alternatively,
updating user profile 300 may also include removing interrupting
event entries and/or downstream operation entries in the event that
those entries no longer accurately reflect the user's needs.
[0074] If, however, it is determined in operation 410 that a user
profile does not exist, then the operational control flow proceeds
to operation 418. In operation 418, a second determination is made
as to whether a default user profile exists on wirelessly-enabled
device 210. If it is determined in operation 418 that a default
user profile does exist, then the operational flow proceeds to
operation 420. In operation 420, wirelessly-enabled device 210
performs the anticipatory networking techniques disclosed herein in
accordance with the default user profile. Following operation 420,
the operational control flow may then proceed to operation 414
where wirelessly-enabled device 210 may collect data relating to
what downstream operations were actually needed to carry out the
interrupting event, and subsequently proceed to operation 416 where
the default user profile may be updated to reflect the newly
collected data.
[0075] If, however, it is determined in operation 418 that a
default user profile does not exist, then the operational control
flow proceeds to operation 422. In operation 422,
wirelessly-enabled device 210 may again collect data relating to
what downstream operations were actually needed to carry out the
interrupting event. However, when it is determined in operation 418
that a default user profile does not exist, then wirelessly-enabled
device 210 may be unable to perform the anticipatory networking
techniques disclosed herein. In other words, without having a user
profile (default or existing), wirelessly-enabled device 210 may
not have a basis for predicting what downstream operations will
likely be needed in order to carry out a desired user action.
[0076] In operation 424, wirelessly-enabled device 210 may then use
the newly collected data to build a new user profile to be used for
future anticipatory networking determinations.
[0077] Method 400 may therefore allow wirelessly-enabled device 210
to carry out numerous different actions, while also reducing the
network latency associated with those actions, improving network
reliability, and improving device performance.
[0078] The internal components of first and second
wirelessly-enabled devices 110 and 210 will now be described in
further detail with references to FIG. 5. FIG. 5 illustrates a
block diagram of a wireless communication device 500 according to
some embodiments. Wireless communication device 500 may represent
an exemplary embodiment of first and/or second wirelessly-enabled
devices 110 and 210. Wireless communication device 500 may include
a processing subsystem 510, a memory subsystem 512, and a wireless
subsystem 514.
[0079] Processing subsystem 510 may include one or more devices
that perform computational operations. For example, processing
subsystem 510 can include one or more microprocessors,
application-specific integrated circuits (ASICs), microcontrollers,
and/or programmable-logic devices. Processing subsystem 510 may
execute an operating system 522 (stored in memory subsystem 512)
that includes procedures (or a set of instructions) for handling
various basic system services for performing hardware-dependent
tasks.
[0080] Memory subsystem 512 may include one or more devices for
storing data and/or instructions for processing subsystem 510 and
wireless subsystem 514. For example, memory subsystem 512 can
include dynamic random access memory (DRAM), static random access
memory (SRAM), and/or other types of memory, More generally, memory
subsystem 512 may include volatile memory and/or non-volatile
memory that are configured to store information. In addition,
memory subsystem 512 can include mechanisms for controlling access
to the memory. In some embodiments, memory subsystem 512 includes a
memory hierarchy that comprises one or more caches coupled to a
memory in wireless communication device 500. Additionally or
alternatively, one or more of the caches may be located in
processing subsystem 510.
[0081] Moreover, memory subsystem 512 may be coupled to one or more
high-capacity mass-storage devices (not shown). For example, memory
subsystem 512 can be coupled to a magnetic or optical drive, a
solid-state drive, or another type of mass-storage device. In these
embodiments, memory subsystem 512 can be used by wireless
communication device 500 as fast-access storage for often-used
data, while the mass-storage device may be used to store less
frequently used data.
[0082] Wireless subsystem 514 may include processors, controllers,
radios/antennas, sockets/plugs, and/or other devices used for
engaging in wireless communication with another wireless
communication device e.g., communicating packets or frames with
another device via a wireless communication link or with wireless
access points, cellular base stations, and/or end servers. As
discussed previously, those skilled in the relevant art(s) will
recognize that wireless communication device 500 may be configured
to communicate using any one of Wi-Fi, Bluetooth, radio-frequency
identification (RFID), near field communications (NFC), 60 GHz
communications, cellular communication, or the like, to name just
some examples. Therefore, wireless subsystem 514 may be configured
to enable communication with another wireless communication device,
wireless access point, base station, or end server via any one of
these wireless protocols. The mechanisms used for coupling to,
communicating on, and handling data and events on the wireless link
may be referred to collectively as an "interface" or "wireless
interface" herein.
[0083] Within wireless communication device 500, processing
subsystem 510, memory subsystem 512, and wireless subsystem 514 may
be coupled together using bus 516. Bus 516 may be an electrical,
optical, electro-optical, etc., connection that the subsystems can
use to communicate commands and data among one another. Although
wireless communication device 500 is shown with only one bus 516, a
different number or configuration of electrical, optical,
electro-optical, etc, connections among the subsystems is possible
without departing from the spirit and scope of the present
disclosure.
[0084] Similarly, wireless communication device 500 may be
implemented as a standalone or a discrete device or may be
incorporated within or coupled to another electrical device or host
device, such as a cellphone, smartwatch, portable computing device,
a camera, or a Global Positioning System (GPS) unit or another
computing device such as a personal digital assistant, a video
gaming device, a laptop, a desktop computer, or a tablet, a
computer peripheral such as a printer or a portable audio and/or
video player to name just some examples and/or any other suitable
electronic device that will be apparent to those skilled in the
relevant art(s) without departing from the spirit and scope of the
present disclosure.
[0085] In an embodiment, wireless communication device 500 may
include one or more additional processing subsystems 510, memory
subsystems 512, and/or wireless subsystems 514. Additionally, it
may be possible for one or more of these subsystems to be omitted
from wireless communication device 500. Moreover, wireless
communication device 500 may include one or more additional
subsystems that are not shown in FIG. 5. For example, wireless
communication device 500 can include, but is not limited to: a
display subsystem for displaying information, a data collection
subsystem, an audio and/or video subsystem, an alarm subsystem, a
media processing subsystem, and/or an input/output (I/O) subsystem.
Also, although separate subsystems are shown in FIG. 5, some or all
of a given subsystem can be integrated into one or more of the
other subsystems in wireless communication device 500 and/or
positions of components in wireless communication device 500 can be
changed without departing from the spirit and scope of the present
invention.
[0086] Now turning back to wireless subsystem 514. As illustrated
in FIG. 5, wireless subsystem 514 may include radio 518, which
itself may include hardware and/or software mechanisms that can be
used for transmitting and receiving wireless signals to and from
other wireless communication devices, wireless access points,
cellular base stations, and/or end servers. Although wireless
subsystem 514 is described having only a single radio 518, those
skilled in the relevant art(s) will recognize that additional
radios could also be included.
[0087] In an embodiment, wireless communication between device 500
and other wireless communication devices may be implemented using
low-level hardware, such as in a physical layer, a link layer
and/or a network layer in a network architecture. For example,
wireless communication may, at least in part, be implemented in a
media access control layer. However, in other embodiments at least
some of the wireless communication operations are performed by one
or more programs, modules, or sets of instructions (such as
optional communication module 520 stored in memory subsystem 512),
which may be executed by processing subsystem 510. The one or more
programs may constitute a computer-program mechanism. Furthermore,
instructions in the various modules in memory subsystem 512 may be
implemented in: a high-level procedural language, an
object-oriented programming language, and/or in an assembly or
machine language. Note that the programming language may be
compiled or interpreted, e.g., configurable or configured, to be
executed by processing subsystem 510.
[0088] As discussed above; wireless communication device 500 may
represent an exemplary embodiment of first and/or second
wirelessly-enabled devices 110 and 210. In such scenarios,
processing subsystem 510 may be configured to perform at least the
following functions associated with the anticipatory networking
method illustrated in FIG. 4: placing wireless communication device
500 in an idle state; detecting an interrupting event; collecting
data relating to the interrupting event; collecting data relating
to the current condition of wireless communication device 500;
performing anticipatory networking according to a user profile 300
(processor-based aspects only); collecting data relating to what
downstream operations are actually needed to carry out the detected
interrupting event; and updating/building user profile 300 based on
the collected data.
[0089] Moreover, wireless subsystem 514 may be configured to
perform at least the following function associated with the
anticipatory networking method illustrated in FIG. 4: performing
anticipatory networking according to a user profile 300
(network-based aspects only--e.g., communications with a networking
element or end server).
[0090] The procedures set(s) of instructions) for performing the
aforementioned functions may be included in operating system 522
stored in memory subsystem 512. Additionally, memory subsystem 512
may be configured to store various other forms of information that
are used during the anticipatory networking method illustrated in
FIG. 4, such as a default user profile, an existing user profile,
and data that is locally cached to aid in the proactive performance
of certain downstream operations e.g., cached DNS resolutions,
caches user credentials, or cached location data), to name just
some examples.
[0091] In an embodiment, a tangible apparatus or article of
manufacture comprising a tangible non-transitory computer useable
or readable medium having control logic (software) stored thereon
is also referred to herein as a computer program product or program
storage device. This includes, but is not limited to, processing
subsystem 510, memory subsystem 512, operating system 522, and
communication module 520, as well as tangible articles of
manufacture embodying any combination of the foregoing. Such
control logic, when executed by one or more data processing devices
(such as processing system 510), causes such data processing
devices to operate as described herein.
[0092] Based on the teachings contained in this disclosure, it will
be apparent to persons skilled in the relevant art(s) how to make
and use embodiments of this disclosure using data processing
devices, computer systems and/or computer architectures other than
that shown in FIG. 5. In particular, embodiments may operate with
software, hardware, and/or operating system implementations other
than those described herein.
[0093] Additionally, embodiments of the disclosure may be
implemented in hardware, firmware, software, or any combination
thereof. Embodiments of the disclosure may also be implemented as
instructions stored on a non-transitory machine-readable medium,
which may be read and executed by one or more processors. A
non-transitory machine-readable medium may include any mechanism
for storing or transmitting information in a form readable by a
machine (e.g., a computing device). For example, a non-transitory
machine-readable medium may include read only memory (ROM); random
access memory (RAM); magnetic disk storage media; optical storage
media; flash memory devices; electrical, optical, acoustical or
other forms of propagated signals (e.g., carrier waves, infrared
signals, digital signals, etc.), and others. Further, firmware,
software, routines, instructions may be described herein as
performing certain actions. However, it should be appreciated that
such descriptions are merely for convenience and that such actions
in fact result from computing devices, processors, controllers, or
other devices executing the firmware, software, routines,
instructions, etc.
CONCLUSION
[0094] It is to be appreciated that the Detailed Description
section, and not any other section, is intended to be used to
interpret the claims. Other sections can set forth one or more but
not all exemplary embodiments as contemplated by the inventors, and
thus, are not intended to limit this disclosure or the appended
claims in any way.
[0095] While this disclosure describes exemplary embodiments for
exemplary fields and applications, it should be understood that the
disclosure is not limited thereto. Other embodiments and
modifications thereto are possible, and are within the scope and
spirit of this disclosure. For example, and without limiting the
generality of this paragraph, embodiments are not limited to the
software, hardware, firmware, and/or entities illustrated in the
figures and/or described herein. Further, embodiments (whether or
not explicitly described herein have significant utility to fields
and applications beyond the examples described herein.
[0096] Embodiments have been described herein with the aid of
functional building blocks illustrating the implementation of
specified functions and relationships thereof. The boundaries of
these functional building blocks have been arbitrarily defined
herein for the convenience of the description. Alternate boundaries
can be defined as long as the specified functions and relationships
(or equivalents thereof) are appropriately performed. Also,
alternative embodiments can perform functional blocks, steps,
operations, methods, etc. using orderings different than those
described herein.
[0097] References herein to "one embodiment," "an embodiment," "an
example embodiment," or similar phrases, indicate that the
embodiment described can include a particular feature, structure,
or characteristic, but every embodiment can not necessarily include
the particular feature, structure, or characteristic. Moreover,
such phrases are not necessarily referring to the same embodiment.
Further, when a particular feature, structure, or characteristic is
described in connection with an embodiment, it would be within the
knowledge of persons skilled in the relevant art(s) to incorporate
such feature, structure, or characteristic into other embodiments
whether or not explicitly mentioned or described herein.
Additionally, some embodiments can be described using the
expression "coupled" and "connected" along with their derivatives.
These terms are not necessarily intended as synonyms for each
other. For example, some embodiments can be described using the
terms "connected" and/or "coupled" to indicate that two or more
elements are in direct physical or electrical contact with each
other. The term "coupled," however, can also mean that two or more
elements are not in direct contact with each other, but yet still
co-operate or interact with each other.
[0098] The breadth and scope of this disclosure should not be
limited by any of the above-described exemplary embodiments, but
should be defined only in accordance with the following claims and
their equivalents.
* * * * *