Delay tolerant decentralized network

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 16/653,976, filed Oct. 15, 2019, which is a continuation of U.S. patent application Ser. No. 16/003,024, filed Jun. 7, 2018, which claims priority to U.S. Provisional Application No. 62/516,590, filed Jun. 7, 2017, titled System for Crowdsourcing Data Using Wireless Radios, each of which are incorporated herein by reference in their entirety.

FIELD

The embodiments discussed herein are related to decentralized networking.

BACKGROUND

The Internet of Things (IoT)—the network of connected “smart” devices that communicate seamlessly over the Internet—is expanding into every aspect of human life. Increasingly, IoT devices are being used for healthcare at hospitals, and in medical device and pharmaceutical manufacturing. In cities, IoT devices help track and monitor pollution. IoT devices can also be used by governments, militaries, companies, and individuals for asset tracking and management. Although these applications serve different purposes, they all share one characteristic-a dependence on strong connectivity. Soon, conventional networks will be unable to handle the bandwidth requirements of billions of IoT devices.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.

SUMMARY

According to an aspect of an embodiment, a method may include receiving a beacon from a first intermediate device via a first network. The beacon may have been received by the first intermediate device from an endpoint device via a second network. The method may also include identifying a characteristic of the beacon. The method may include identifying, based on the characteristic of the beacon, a server that is associated with the beacon. The method may also include sending a beacon message to the server via a third network, the beacon message including at least one of the beacons, or information pertaining to the beacon. The method may further include receiving, from the server, a response message pertaining to the beacon message. The method may include processing the response message.

According to another aspect, a method may include detecting movement of a first intermediate device from a first geographic location to a second geographic location. The method may also include receiving a beacon from an endpoint device responsive to the first intermediate device moving to the second geographic location. The method may further include identifying a relay server to send a beacon message. The beacon message may include at least one of: the beacon, or information pertaining to the beacon. The method may include sending the beacon message from the endpoint device to the relay server.

The object and advantages of the embodiments will be realized and achieved at least by the elements, features, and combinations particularly pointed out in the claims.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates an example network architecture;

<figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates an example network architecture;

<figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates an example network architecture;

<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates an example network architecture;

<figref idref="DRAWINGS">FIG. <b>5</b></figref> illustrates a flow diagram of an example method to handle communications between devices;

<figref idref="DRAWINGS">FIG. <b>6</b></figref> illustrates a flow diagram of an example method to handle communications between an endpoint device and other device;

<figref idref="DRAWINGS">FIG. <b>7</b></figref> illustrates a flow diagram of an example method to handle communications between an endpoint device and other devices; and

<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates a diagrammatic representation of a machine in the example form of a computing device within which a set of instructions, for causing the machine to perform any one or more of the methods discussed herein, may be executed, and all arranged in accordance with at least one embodiment described herein.

DESCRIPTION OF EMBODIMENTS

The Internet of Things (IoT) is expanding into every aspect of human life. With over 75 Billion IoT devices expected to be deployed by 2025, a more efficient new network infrastructure is needed to bring these devices online and connect them to each other.

Many connectivity solutions exist for IoT devices. Unfortunately, all suffer problems of limited bandwidth, decreased connectivity, high power consumption, and/or high cost. For example, cellular connections may consume significant power in a device and may also be expensive. Low power solutions, such as a Low-Power Wide-Area Network (LPWAN) may consume less power than cellular connections. LPWANs, however, may be constrained by limited bandwidth and may not be able to transmit enough data to fully serve the needs of distributed networks. Conventional systems may not consume a relatively low amount of power while still providing high bandwidth.

Specifically, to connect a small device to the Internet today, existing solutions include: (a) using an existing wireless network, for example, by incorporating a cellular module with a subscriber identification module (SIM) card or software SIM into the device to give it a cellular connection, (b) building a new alternative wireless network by incorporating a custom radio chipset and building fixed infrastructure to support this network, and (c) using long range network technology such as LoRa Alliance Technology. LoRa uses a complex “star-of-stars” topology of gateways and bridges between IoT devices and a “central network server” on the industrial, scientific and medical (ISM) spectrum band.

Each of these approaches have significant drawbacks. For example, each of these approaches require a significant amount of power which often is a major contributor to battery drain in mobile devices. Further, approach (a) requires expensive cellular modules and, in addition, a monthly fee for wireless cellular service for both, service subscription and data to a wireless carrier. Approaches (b) and (c) are also expensive, because they require building new, fixed infrastructure, and often require purchasing a chipset for radio transmission in addition to the popular Bluetooth® chipsets. The longer the transmission range, the greater the power requirement, so each of these approaches require significant power. Similarly, cellular devices and Global Positioning System (GPS) enabled devices require high power to communicate with a cell tower or satellites because of longer distances.

Aspects of the present disclosure address these and other problems with conventional networking by providing a new decentralized network. In some aspects, a decentralized network may connect numerous devices using low-power while providing higher connectivity and/or bandwidth. An embodiment includes a crowd-source based method for sending data from an IoT device to a server that does not rely on a fixed infrastructure. Another embodiment includes a crowd-source method for a cloud server to send data to an IoT device that does not rely on a fixed infrastructure. A further embodiment includes a method for routing data in beacons from multiple services on multiple IoT devices to the appropriate device manufacturer servers. Yet another embodiment includes a method to reduce energy consumption on mobile devices used to collect or exchange data with remote IoT devices.

In one aspect, the present disclosure describes systems and techniques to improve upon existing technologies by obviating the need for separate, fixed infrastructure by using crowd-sourcing techniques. Some aspects provide a methodology for IoT device-to-server communication that has a low power consumption profile and does not require massive fixed hardware infrastructure. Other benefits of the present disclosure is in its ability to lower the cost of Internet access and to create a platform for new innovations in the field of IoT.

The present disclosure may be useful to virtually every field that uses network-based communications. Example parties that may benefit from this disclosure include, but are not limited to, smartphone manufacturers, bike and ride sharing companies, outdoor advertisers, environmental analytics companies, etc. Example applications may include use for pollution tracking, asset tracking, finding lost devices, industrial predictive maintenance, etc. Further, aspects of the present disclosure may not rely on connectivity using SIM or LPWAN modems, which enables devices to be smaller and more efficient.

For example, in location tracking of devices and assets scenarios, most low cost tracking device makers rely on app users to locate devices, and do not have sufficient app density to provide global coverage. Adding a cellular module and a GPS module is expensive and power hungry. Aspects of the present disclosure may provide a solution that does not require endpoint devices to include cellular or GPS modules which interoperates globally, and lowers costs.

In an example of low power sensor connectivity, the cost of some sensors is so low that adding cellular or GPS connectivity can be an order of magnitude more expensive than the cost of the sensor. Aspects of the present disclosure may provide a connectivity service at a radically lower cost.

Some aspects may also be used for firmware updates, updating date and time of devices, creating a wearable device network, data IP connectivity, measuring population density (such as by detecting the number of Bluetooth® devices in a given location), checking the presence of a specific device for insurance companies, detecting trends of sales of a specific device for market analytics companies, hedge funds and private equity companies, etc.

Moreover, delay tolerant use cases, such as location updates and environmental/health data, may also benefit from the present disclosure. For example, many use cases do not require immediate cloud or Internet connectivity. In this context, the present disclosure leverages smartphones' Bluetooth® connectivity, and their Wi-Fi offloading capabilities to offer a significantly enhanced bandwidth compared to LPWANs.

<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates an example network architecture <b>100</b> in which embodiments of the present disclosure may be implemented. The network architecture <b>100</b> may include one or more endpoint devices <b>105</b>, one or more intermediate devices <b>115</b>, one or more relay servers <b>125</b>, and one or more endpoint manager servers <b>135</b>. In some embodiments, the network architecture <b>100</b> may be capable to move data between one or more endpoint devices <b>105</b> and various endpoint manager servers <b>135</b> by way of crowd-sourced intermediate devices <b>115</b>, which may function act as network clients, and one or more relay servers <b>125</b>.

An endpoint device <b>105</b> may include one or more IoT devices. The endpoint device <b>105</b> may include a power supply, a data collection device (e.g., a sensor), and a network device. The power supply may include a battery or a connection to a power grid. Additionally or alternatively, the power supply may include an energy harvesting apparatus, such as a solar panel, solar cell, solar photovoltaic, electromagnetic, etc. In at least some embodiments, the endpoint device <b>105</b> may not include a power supply and may instead use ambient backscatter techniques. The endpoint device <b>105</b> may also include one or more sensors. The one or more sensors may be configured to detect any type of condition, and generate electronic data based on a detected condition. For example, the endpoint device <b>105</b> may include a smart watch with a heart rate monitor that is configured to generate heart rate data using heart rate conditions collected by the heart rate monitor. In at least one embodiment, the endpoint device <b>105</b> does not have capability to communicate over the Internet and only includes hardware and/or software capable of communicating with nearby devices, such as a nearby intermediate device <b>115</b>.

The network device of the endpoint device <b>105</b> may include any hardware, software, or combination thereof that is capable to communicate with another device via a network. In at least one embodiment, the network device may include any network controller configured to communicate via a short-range network, such as Bluetooth® or any other short-range network. In at least one embodiment, the network device may include any network controller configured to communicate via a low-power network. Example endpoint devices <b>105</b> include, but are not limited to, industrial devices, residential appliances, commercial equipment, inventory trackers, smart watches, wearables, heart rate monitors, logistics trackers, environmental sensors, cash registers, credit card readers, point-of-sale (POS), bikes, electric scooters, electric skate boards, cars, electric cars, satellites, or any device (mobile and not mobile that includes a wireless radio interface. The network architecture <b>100</b> may include any number of endpoint devices <b>105</b> and the endpoint devices <b>105</b> in the network architecture <b>100</b> may be any type of endpoint device <b>105</b>, including any type of network-capable device. The endpoint devices <b>105</b> may be fixed or relatively stationary in the network architecture <b>100</b>, such as a POS or a pollution sensor. Additionally or alternatively, the endpoint devices <b>105</b> may be mobile, such as a smart watch, or any car or vehicle.

The one or more endpoint devices <b>105</b> may be configured to communicate with other devices via at least one wireless network <b>110</b>. For example, a first endpoint device <b>105</b><i>a </i>may be in electronic communication with a first intermediate device <b>115</b><i>a </i>via a wireless network <b>110</b><i>a</i>. The one or more intermediate devices <b>115</b> may include any type of device capable of communicating with an endpoint device <b>105</b> via the wireless network <b>110</b> and with a relay server <b>125</b> via a second network <b>120</b>. In at least one embodiment, an intermediate device <b>115</b> may include two network controllers-a first network controller to communicate via the wireless network <b>110</b> and a second network controller to communicate via the second network <b>120</b>. Example intermediate devices <b>115</b> include personal computers (PC), laptops, smart phones, netbooks, e-readers, personal digital assistants (PDA), cellular phones, mobile phones, tablets, vehicles, drones, cars, trucks, wearable devices, routers, televisions, or set top boxes, etc.

As illustrated, the first endpoint device <b>105</b><i>a </i>may be in electronic communication with the first intermediate device <b>115</b><i>a </i>via the wireless network <b>110</b><i>a </i>(e.g., a short-range network). Further, a second endpoint device <b>105</b><i>b </i>may be in electronic communication with a second intermediate device <b>115</b><i>b </i>via another wireless network <b>110</b><i>b </i>(e.g., a low-power network). A third endpoint device <b>105</b><i>c </i>may be in electronic communication with a third intermediate device <b>115</b><i>c </i>via another wireless network <b>110</b><i>c</i>. A fourth endpoint device <b>105</b><i>d </i>may be in electronic communication with a fourth intermediate device <b>115</b><i>d </i>via another wireless network <b>110</b><i>d. </i>

In some embodiments, the wireless network <b>110</b> may be any network that uses a relatively low amount of power. Example wireless networks <b>110</b> may include any Bluetooth® network type (e.g., Bluetooth Low Energy (BLE), Bluetooth 4.0, Bluetooth 5.0, Bluetooth Long Range), NB-IoT, LTE Direct, LTE-M, LTE M2M, 5G, Wi-Fi, Wi-Fi Aware or any low-power network. The one or more endpoint devices <b>105</b> may connect to various intermediate devices <b>115</b> using different types of wireless networks <b>110</b>. For example, the first endpoint device <b>105</b><i>a </i>may be in electronic communication with the first intermediate device <b>115</b><i>a </i>via a first short-range wireless network <b>110</b><i>a </i>and the second endpoint device <b>105</b><i>b </i>may be in electronic communication with the second intermediate device <b>115</b><i>b </i>via a second short-range wireless network <b>110</b><i>b. </i>

Endpoint devices <b>105</b>, intermediate devices <b>115</b>, or both, may be fixed, relatively stationary or moveable. When an endpoint device <b>105</b> and an intermediate device <b>115</b> come into wireless range of each other, the endpoint device <b>105</b> and the intermediate device <b>115</b> may perform a handshake and/or authentication to initiate data exchange between the endpoint device <b>105</b> and the intermediate device <b>115</b>.

In some embodiments, the endpoint device <b>105</b> may periodically send beacons that include data via the wireless network <b>110</b>. The endpoint devices <b>105</b> may include various services that may run on the endpoint devices <b>105</b>. For example, a smart watch may include a clock service, a heart rate monitor service, a motion detection service, a music service, etc. Beacons may be generated for each of these services or a single beacon may be generated to include data for some or all of the services.

An intermediate device <b>115</b> may listen for such beacons from endpoint devices. Responsive to receiving a beacon, the intermediate device <b>115</b> may send the beacon to a relay server <b>125</b> via a second network <b>120</b>. In at least one embodiment, the wireless network <b>110</b> and the second network <b>120</b> are different types of networks. For example, the wireless network <b>110</b> may be a Bluetooth® network and the second network <b>120</b> may be a cellular network, Wi-Fi, or the Internet.

The second network <b>120</b> may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), a wired network (e.g., Ethernet network), a wireless network (e.g., an 802.xx network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE-Advanced network, 1G, 2G, 3G, 4G, 5G, etc.), routers, hubs, switches, server computers, and/or a combination thereof.

The relay server <b>125</b> may send the beacon, or information related to the beacon, to an endpoint manager server <b>135</b> via a third network <b>130</b>. The third network <b>130</b> may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), a wired network (e.g., Ethernet network), a wireless network (e.g., an 802.xx network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE-Advanced network, 1G, 2G, 3G, 4G, 5G, etc.), routers, hubs, switches, server computers, and/or a combination thereof. In at least one embodiment, the second network <b>120</b> and the third network <b>130</b> are the same network or include at least some overlapping components.

The one or more relay servers <b>125</b> may include one or more computing devices, such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, smartphone, cars, drones, a robot, any mobility device that has an operating system, etc.), data stores (e.g., hard disks, memories, databases), networks, software components, and/or hardware components. The one or more relay servers <b>125</b> may be configured to receive a beacon from an intermediate device <b>115</b>. The one or more relay servers <b>125</b> may send the beacon, or data related to or associated with to an endpoint manager server <b>135</b>. The one or more relay servers <b>125</b> may receive a message from the endpoint manager server <b>135</b> and, in some embodiments, may send the message from the endpoint manager server <b>135</b> to an intermediate device <b>115</b>. In at least some embodiments, the intermediate device <b>115</b> may perform one or more operations responsive to receiving the message from the endpoint manager server <b>135</b>. The operations include operations local to the intermediate device <b>115</b>, and/or sending the message from the endpoint manager server <b>135</b> to an endpoint device <b>105</b>.

The endpoint manager server <b>135</b> may include one or more computing devices, such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, a smartphone, a car, a drone, a robot, any mobility device that has an operating system etc.), data stores (e.g., hard disks, memories, databases), networks, software components, and/or hardware components. The endpoint manager server <b>135</b> may be associated with one or more endpoint devices <b>105</b>. For example, a particular corporation, person, or manufacturer may sell an endpoint device <b>105</b> and may use an endpoint manager server <b>135</b> to communicate with and/or control the endpoint device <b>105</b>.

The endpoint manager server <b>135</b> may send messages associated with a particular endpoint device <b>105</b>, or a set of endpoint devices <b>105</b>. For example, the endpoint manager server <b>135</b> may send updates (e.g., firmware, software) to the particular endpoint device <b>105</b>, or the set of endpoint devices <b>105</b>. The endpoint manager server <b>135</b> may send other communications to an endpoint device <b>105</b>, such as a response to a request from a beacon generated by the particular endpoint device <b>105</b>.

Each relay server <b>125</b> may include a message manager <b>140</b>. The message manager <b>140</b> may be implemented using hardware including a processor, a microprocessor (e.g., to perform or control performance of one or more operations), an FPGA, or an ASIC. In some other instances, the message manager <b>140</b> may be implemented using a combination of hardware and software. Implementation in software may include rapid activation and deactivation of one or more transistors or transistor elements such as may be included in hardware of a computing system (e.g., the relay server <b>135</b>). Additionally, software defined instructions may operate on information within transistor elements. Implementation of software instructions may at least temporarily reconfigure electronic pathways and transform computing hardware.

Each relay server <b>125</b> may include a data storage <b>145</b>. The data storage <b>145</b> may include any memory or data storage. In some embodiments, the data storage <b>145</b> may include computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. The computer-readable storage media may include any available media that may be accessed by a general-purpose or special-purpose computer, such as a processor. For example, the data storage <b>145</b> may include computer-readable storage media that may be tangible or non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and that may be accessed by a general-purpose or special-purpose computer. Combinations of the above may be included in the data storage <b>145</b>. In the depicted embodiment, the data storage <b>145</b> is part of the relay server <b>125</b>. In some embodiments, the data storage <b>145</b> may be separate from the relay server <b>125</b> and may access the data storage <b>145</b> via a network. In at least one embodiment, the data storage <b>145</b> may include multiple data storages.

The data storage <b>145</b> may include data pertaining to the endpoint devices <b>105</b>, intermediate devices <b>115</b>, and endpoint manager servers <b>135</b> and relationships between the endpoint devices <b>105</b>, intermediate devices <b>115</b>, and endpoint manager servers <b>135</b>. For example, the data storage <b>145</b> may include a table or list of endpoint devices that are associated with a particular endpoint manager server <b>135</b>. The data storage <b>145</b> may include data pertaining to beacons received from endpoint devices, such as a timestamp of the receipt of the beacon, a timestamp associated with the creation of the beacon, a geo-location associated with the beacon and/or the endpoint device <b>105</b> that created or transmitted the beacon, sensor data associated with the endpoint device, routing information for how and/or where to send data between endpoint manager servers <b>135</b> and endpoint devices <b>105</b>, connection strengths between intermediate devices and endpoint devices, proximity of an endpoint device <b>105</b> to an intermediate device <b>115</b>, type of wireless network <b>110</b> that connects an intermediate device <b>115</b> and an endpoint device <b>105</b>, a cost of a connection between an intermediate device <b>115</b> and an endpoint device <b>105</b>, a current battery level of the intermediate device, a type of intermediate device, etc.

The message manager <b>140</b> may process communications between the endpoint devices <b>105</b>, the intermediate devices <b>115</b> and the endpoint manager server(s) <b>135</b>. In an example, the message manager <b>140</b> may receive a beacon from the intermediate device <b>115</b><i>a </i>via the second network <b>120</b><i>a</i>. The beacon may have been sent to the intermediate device via the wireless network <b>110</b><i>a </i>by endpoint device <b>105</b><i>a</i>. A beacon may contain characteristics about the endpoint device <b>105</b>, including an identifier of the endpoint device <b>105</b> (e.g., a MAC address, a unique ID), a geographical location of the endpoint device <b>105</b><i>a</i>, and advertisements of the UUIDs of the services it supports, etc. The message manager <b>140</b> may identify the characteristic of the beacon, such as by analyzing the beacon to identify information pertaining to the beacon. The message manager <b>140</b> may access the data storage <b>145</b> to identify, based on the characteristic of the beacon, an endpoint manager server <b>135</b> that is associated with the beacon. For example, the identifier of the endpoint device may be associated with a particular manufacturer that operations a particular endpoint manager server <b>135</b>. The message manager <b>140</b> may identify this particular endpoint manager server <b>135</b> in the data storage <b>145</b> and an address and/or path to send the beacon in order to reach the endpoint manager server <b>135</b>. In at least some embodiments, the message manager <b>140</b> may send the beacon, or a beacon message to the endpoint manager server <b>135</b> via the third network <b>130</b>. The beacon message may include the beacon, may not include the beacon, or may include information pertaining to the beacon.

In at least one embodiment, a beacon may include data from multiple services associated with the endpoint device <b>105</b>. Additionally or alternatively, multiple beacons from a single endpoint device <b>105</b> may be generated and broadcast via the wireless network <b>110</b>. Each of these multiple beacons, for example, may be associated with a different service associated with the endpoint device <b>105</b>. The message manager <b>140</b> may identify the services, and based on information for the service, identify an appropriate endpoint manager server <b>135</b> that should receive a beacon message.

The endpoint manager server <b>135</b> may receive the message from the relay server <b>125</b>. The endpoint manager server <b>135</b> may store the message, process the message, generate a report based on the message, may generate a notification or response based on the message, or any other action. For example, endpoint manager server <b>135</b> may generate a response message pertaining to the beacon message. The response message may include a message intended for one or more of the relay server <b>125</b>, an intermediate device <b>115</b>, the endpoint device <b>105</b> that generated the beacon, or another endpoint device <b>105</b> that did not generate the beacon. The endpoint manager server <b>135</b> may send the response message to the same relay server <b>125</b> that sent the beacon message to the endpoint manager server <b>135</b> (e.g., the relay server <b>125</b><i>a</i>), or to a different relay server <b>125</b> that did not send the beacon message to the endpoint manager server <b>135</b> (e.g., relay server <b>125</b><i>b</i>).

The relay server <b>125</b> may receive, from the endpoint manager server <b>135</b>, the response message pertaining to the beacon message. The relay server <b>125</b> may process the response message, such as by performing operations at the relay server <b>125</b>, sending data to another device (e.g., a user device), sending data to an endpoint device <b>105</b>, etc.

The network architecture <b>100</b> may be used to exchange data between any devices capable of network-based communication in a manner that is different than conventional communication over the Internet.

In an example, the network architecture <b>100</b> may leverage existing smartphone infrastructure to create delay-tolerant connectivity. The network architecture <b>100</b> can move data to the cloud in an initially delay tolerant fashion, which may be useful for many types of IoT communications such as firmware updates, status updates, log-file storage, and micropayments. The intermediate device may include software that runs on smartphones to periodically scan for other devices (e.g., the endpoint devices <b>105</b>) like industrial devices, smartwatches, wearables, logistics trackers, and environmental sensors. These endpoint devices <b>105</b> may connect with the software client running on the smartphones to create massive, area wide networks for moving data to and within the cloud.

Further, it has been estimated that 95% of the human population is covered by some sort of cellular service. The network architecture <b>100</b> can be deployed anywhere in the world and enables regions of lower connectivity to increase their connectivity. Moreover, the network architecture <b>100</b> can provide coverage beyond the reach of conventional cellular networks by using software that runs on Bluetooth®-enabled smartphones, for example. Users may travel to areas of limited or no cellular connectivity, but still may receive beacons from endpoint devices <b>105</b> via the wireless network <b>110</b>. Using the network architecture <b>100</b>, telco operators, for example, can now easily deploy a software update to their user devices to begin communicating with endpoint devices <b>105</b> as described herein to provide higher latency IoT connectivity to even the remotest regions of the world.

In a specific example, the network architecture <b>100</b> can be used for asset tracking and management. For example, the network architecture <b>100</b> can be used to find lost items that are configured as an endpoint device <b>105</b>, such as a skateboard with a wireless radio chipset, an attached tracking beacon, a laptop, etc. A user, for example, may indicate that the item is lost, such as by using a mobile application or website to indicate, to the endpoint manager server <b>135</b> or to the relay server <b>125</b>, that the item is lost. In a first embodiment, the endpoint manager server <b>135</b> may send a message to one or more relay servers <b>125</b> to watch for the lost item. The relay servers <b>125</b> may add an identifier of the lost item to a lost item watch list. As intermediate devices <b>115</b> move to different geographic locations, they can receive beacons from different endpoint devices <b>103</b>. The intermediate devices <b>115</b> then forward the beacons to the relay servers <b>125</b>. When a relay server <b>125</b> server receivers a beacon, the relay server <b>125</b> can analyze the beacon to determine if the beacon originated at an endpoint device <b>105</b> that is on the watch list. When the relay server <b>125</b> identifies a beacon that originated at an endpoint device <b>105</b> that is on the watch list, the relay server <b>125</b> can notify the endpoint manager server <b>135</b> that the lost item has been found. In at least some embodiments, the relay server <b>125</b> may send the notification that the lost item has been found as a push notification or as a pull notification (i.e., in response to a request from the endpoint manager server <b>135</b>). In at least some embodiments, the relay server <b>125</b> may send the notification that the lost item has been found to the user device that was used by the user to indicate that the item was lost.

Modifications, additions, or omissions may be made to the network architecture <b>100</b> without departing from the scope of the present disclosure. The present disclosure more generally applies to the network architecture <b>100</b> including one or more endpoint devices <b>105</b>, one or more wireless networks, one or more intermediate devices <b>115</b>, one or more second networks <b>120</b>, one or more relay servers <b>125</b>, one or more third networks <b>130</b>, and one or more endpoint manager servers <b>135</b> or any combination thereof.

Moreover, the separation of various components in the embodiments described herein is not meant to indicate that the separation occurs in all embodiments. In addition, it may be understood with the benefit of this disclosure that the described components may be integrated together in a single component or separated into multiple components.

<figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates an example network architecture <b>200</b> in which embodiments of the present disclosure may be implemented. The network architecture <b>200</b> may include components illustrated and described in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, such as one or more endpoint devices <b>105</b>, one or more intermediate devices <b>115</b>, one or more relay servers <b>125</b>, and one or more endpoint manager servers <b>135</b>. In particular, <figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates how intermediate devices <b>115</b> may move within the network architecture <b>200</b> and how data is communicated within the network architecture <b>200</b> due to the movements.

As compared to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, <figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates that the intermediate device <b>115</b><i>b </i>has moved to a different geographical location. In response to this move, the intermediate device <b>115</b><i>b </i>is no longer in communication with the relay server <b>125</b><i>a </i>and instead, is in communication with the relay server <b>125</b><i>b</i>. The intermediate device <b>115</b><i>b </i>is also no longer close enough to the endpoint device <b>105</b><i>b </i>to be able to communicate with the endpoint device <b>105</b><i>b</i>. As illustrated, there is no intermediate device <b>115</b> that is within range of the endpoint device <b>105</b><i>b</i>. The endpoint device <b>105</b><i>b</i>, however, may continue to send beacons even though there is no device within range to receive the beacons.

Also illustrated, the intermediate device <b>115</b><i>b </i>is now within range of the endpoint device <b>105</b><i>c</i>. The intermediate device <b>115</b><i>b </i>is now able to communicate with the endpoint device <b>105</b><i>c </i>via the wireless network <b>110</b><i>e</i>, such as by receiving beacons from the endpoint device <b>105</b><i>c </i>and by sending response messages to the endpoint device <b>105</b><i>c</i>. In at least some embodiments, the intermediate device <b>115</b><i>c </i>may have previously received a beacon from the endpoint device <b>105</b><i>c </i>and may have forwarded the beacon to the relay server <b>125</b><i>b</i>. The relay server <b>125</b><i>b </i>may have sent a beacon message to the endpoint manager server <b>135</b> and may have received a response message from the endpoint manager server <b>135</b>. Since the intermediate device <b>115</b><i>b </i>is now within range of the endpoint device <b>105</b><i>c</i>, as well as the intermediate device <b>115</b><i>c</i>, the relay server <b>125</b><i>b </i>may select one of the intermediate device <b>115</b><i>b </i>or the intermediate device <b>115</b><i>c </i>to handle sending the response message to the endpoint device <b>105</b><i>c</i>. The relay server <b>125</b><i>b </i>may use any selection criteria to select which intermediate device <b>115</b> to use to send the response message, such as a connection strength between the intermediate device <b>115</b> and the target endpoint device <b>105</b>, a proximity of an endpoint device <b>105</b> to an intermediate device <b>115</b>, a type of wireless network <b>110</b> that connects an intermediate device <b>115</b> and an endpoint device <b>105</b>, a cost of a connection between an intermediate device <b>115</b> and an endpoint device <b>105</b>, a current battery level of the intermediate device, a type of intermediate device, etc.

In at least some embodiments, both of the intermediate device <b>115</b><i>b </i>and the intermediate device <b>115</b><i>c </i>are within range of the endpoint device <b>105</b><i>c </i>and both receive the same beacon from the endpoint device <b>105</b><i>c</i>. Further, the intermediate device <b>115</b><i>b </i>and the intermediate device <b>115</b><i>c </i>both may forward the beacon of the endpoint device <b>105</b><i>c </i>to the relay server <b>125</b><i>b</i>. To reduce redundancy, network traffic, battery life, etc., the relay server <b>125</b><i>b </i>may select one of the intermediate device <b>115</b><i>b </i>and the intermediate device <b>115</b><i>c </i>to handle communication with the endpoint device <b>105</b><i>c </i>and instruct the non-selected intermediate device to ignore beacons from the endpoint device <b>105</b><i>c</i>, to discard beacons from the endpoint device <b>105</b><i>c</i>, to stop sending beacons from the endpoint device <b>105</b><i>c</i>, or any other operation that may reduce network congestion, free-up data storage space, free-up processor capabilities, etc. As more intermediate devices <b>115</b> become available for data transport, data transmission frequency for a particular intermediate device may decrease. In the long term, with enhanced density intermediate device and machine learning based protocols, the technology described here may significantly improve battery life for intermediate devices, reduce network congestion, improve global connectivity, etc. The relay server <b>125</b><i>b </i>may use any selection criteria to select which intermediate device <b>105</b> to use to communicate with the endpoint device <b>105</b> and which intermediate device to cease communications regarding the endpoint device <b>105</b>, such as a connection strength between the intermediate device <b>115</b> and the target endpoint device <b>105</b>, a proximity of an endpoint device <b>105</b> to an intermediate device <b>115</b>, a type of wireless network <b>110</b> that connects an intermediate device <b>115</b> and an endpoint device <b>105</b>, a cost of a connection between an intermediate device <b>115</b> and an endpoint device <b>105</b>, a current battery level of the intermediate device, a type of intermediate device, etc.

<figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates an example network architecture <b>300</b> in which embodiments of the present disclosure may be implemented. The network architecture <b>300</b> may include components illustrated and described in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, such as one or more endpoint devices <b>105</b>, one or more intermediate devices <b>115</b>, one or more relay servers <b>125</b>, and one or more endpoint manager servers <b>135</b>. In particular, <figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates how an intermediate device <b>115</b><i>a </i>may communicate with endpoint device <b>105</b><i>a </i>even without the intermediate device <b>115</b><i>a </i>being connected to the second network <b>102</b> (e.g., without having an active Internet connection). For example, the intermediate device <b>115</b><i>a </i>may move to an area with little or no cellular coverage and still be able to receive beacons from endpoint devices <b>105</b>. Further, the intermediate device <b>115</b><i>a </i>may have previously received a message addressed to the endpoint device <b>105</b><i>a</i>. The intermediate device <b>115</b><i>a </i>may store this message until the intermediate device <b>115</b><i>a </i>is within range of the endpoint device <b>105</b><i>a</i>, upon which the intermediate device <b>115</b><i>a </i>may send the message to the endpoint device <b>105</b><i>a</i>. In at least some embodiments, the intermediate device <b>115</b><i>a </i>may have been selected by a relay server <b>125</b> to handle this particular message for endpoint device <b>105</b><i>a </i>based on prior activities of the intermediate device <b>115</b><i>a</i>. For example, the intermediate device <b>115</b><i>a </i>may have previously carried messages to the endpoint device <b>105</b><i>a</i>. Additionally or alternatively, the intermediate device <b>115</b><i>a </i>may be the only intermediate device that has communicated with the endpoint device <b>105</b><i>a</i>, or the intermediate device <b>115</b><i>a </i>may be the most recent intermediate device to have communicated with the endpoint device <b>105</b><i>a. </i>

<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates an example network architecture <b>400</b> in which embodiments of the present disclosure may be implemented. The network architecture <b>400</b> may include components illustrated and described in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, such as one or more endpoint devices <b>105</b>, one or more intermediate devices <b>115</b>, one or more relay servers <b>125</b>, and one or more endpoint manager servers <b>135</b>. In particular, <figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates how an intermediate device <b>115</b><i>a </i>that was previously not connected to the second network <b>120</b> (as illustrated in <figref idref="DRAWINGS">FIG. <b>3</b></figref>) can move within range of the second network <b>120</b> and communicated data received from the endpoint device <b>105</b><i>a</i>. As illustrated in <figref idref="DRAWINGS">FIG. <b>4</b></figref>, the intermediate device <b>115</b><i>a </i>has moved to a location that is within range of the second network <b>120</b><i>b</i>. Once connected to the relay server <b>125</b><i>b </i>via the second network <b>120</b><i>b</i>, the intermediate device <b>115</b><i>a </i>may send a beacon received from the endpoint device <b>105</b><i>a</i>. The intermediate device <b>115</b><i>a </i>may also receive additional messages from the relay server <b>125</b><i>b </i>that that are addressed to the endpoint device <b>105</b><i>a </i>that the intermediate device <b>115</b><i>a </i>may send to the endpoint device <b>105</b><i>a </i>at a later time.

<figref idref="DRAWINGS">FIGS. <b>5</b>-<b>7</b></figref> illustrate flow diagrams of example methods related to decentralized networking. The methods may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both, which processing logic may be included in the intermediate device <b>115</b> and/or the relay server <b>125</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, or another computer system or device. However, another system, or combination of systems, may be used to perform the methods. For simplicity of explanation, methods described herein are depicted and described as a series of acts. However, acts in accordance with this disclosure may occur in various orders and/or concurrently, and with other acts not presented and described herein. Further, not all illustrated acts may be used to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methods may alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, the methods disclosed in this specification are capable of being stored on an article of manufacture, such as a non-transitory computer-readable medium, to facilitate transporting and transferring such methods to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

<figref idref="DRAWINGS">FIG. <b>5</b></figref> illustrates a flow diagram of an example method <b>500</b> to handle communications between devices. For example, the example method <b>500</b> may be performed by a relay server (e.g., the relay server <b>125</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) to handle communications for and between an endpoint device (e.g., the endpoint device <b>105</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) and an endpoint manager server <b>135</b> (e.g., the endpoint manager server <b>135</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>).

The method <b>500</b> may begin at block <b>505</b>, where processing logic may receive a beacon from a first intermediate device via a first network. The first intermediate device may include the intermediate device <b>115</b><i>a </i>of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, for example. The beacon may have been received by the first intermediate device from an endpoint device (e.g., the endpoint device <b>105</b><i>a </i>of <figref idref="DRAWINGS">FIG. <b>1</b></figref>) via a second network (e.g., the wireless network <b>110</b><i>a </i>of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). In at least some embodiments, the first network is a longer-range network or a higher-power network as compared to the second network.

At block <b>510</b>, the processing logic may identifying a characteristic of the beacon. For example, the beacon may include data indicative of a geographical location of the endpoint device and an identifier of the endpoint device. Identifying the characteristic of the beacon may include scanning the beacon to identify the data indicative of the geographical location of the endpoint device and the identifier of the endpoint device.

At block <b>515</b>, the processing logic may identifying a server that is associated with the beacon. The server may include the endpoint manager server <b>135</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. In at least some embodiments, the processing logic may use the characteristic of the beacon to identify the server. For example, the identifier of the endpoint device may be associated with a particular server. The processing logic may use the identifier of the endpoint device as a key to lookup the server and/or an address of the server.

At block <b>520</b>, the processing logic may send a beacon message to the server via a third network. The third network may include the network <b>130</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. In at least some embodiments, the beacon message may include at least one of: the beacon, or information pertaining to the beacon, such as data collected by the beacon. In at least some embodiments, sending the beacon message to the server via the third network may include sending the identifier of the endpoint device to the server. The processing logic may send the beacon message to the server as a push or pull message.

At block <b>525</b>, the processing logic may receive, from the server, a response message pertaining to the beacon message. In at least some embodiments, the response message may be addressed to a second intermediate device (e.g., the intermediate device <b>115</b><i>b </i>of <figref idref="DRAWINGS">FIG. <b>1</b></figref>), or a user device. In at least some embodiments, the response message may include an indication that the endpoint device—a lost device—has been found. The response message may also include at least one instruction, executable by the second intermediate device or user device, to display a location of the endpoint device on an electronic map.

At block <b>530</b>, the processing logic may process the response message. In at least some embodiments, processing the response message includes sending the response message to the second intermediate device. In at least some embodiments, the response message may include an instruction executable by the endpoint device and processing the response message may include sending the response message to the endpoint device. Processing the response message may also include storing the response message.

At block <b>535</b>, the processing logic may send the response message to an endpoint device. In at least some embodiments, sending the response message to the endpoint device may include identifying an intermediate device that is currently communicatively coupled to the endpoint device, such as any of the intermediate devices <b>115</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. Sending the response message to the endpoint device may also include sending the response message to the identified intermediate device with an instruction to forward the response message to the endpoint device.

<figref idref="DRAWINGS">FIG. <b>6</b></figref> illustrates a flow diagram of an example method <b>600</b> to handle communications between an endpoint device and other devices. For example, the example method <b>600</b> may be performed by an intermediate device (e.g., the intermediate device <b>115</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) to handle communications for and between an endpoint device (e.g., the endpoint device <b>105</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) and an endpoint manager server <b>135</b> (e.g., the endpoint manager server <b>135</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>). In at least some embodiments, the processing logic may include software that is installed on more than one device.

The method <b>600</b> may begin at block <b>605</b>, where processing logic may listen for the beacon. In at least some embodiments, the processing logic may by periodically scan for beacons via a first network (e.g., the wireless network <b>110</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). The processing logic may also subscribe to beacons of one or more endpoint devices.

At block <b>610</b>, the processing logic may detect movement of a first intermediate device from a first geographic location to a second geographic location. For example, the first intermediate device may include a motion sensor, such as a gyroscope, accelerometer, GPS, network triangulator, etc. to determine movement of the first intermediate device.

At block <b>615</b>, the processing logic may, responsive to the first intermediate device moving to the second geographic location, receive a beacon from an endpoint device. For example, the first intermediate device may, upon entering a new geographic location, scan for any beacons from endpoint devices. For as long as the first intermediate device stays relatively still, the first intermediate device may not further scan for beacons. Once the first intermediate device moves, the first intermediate device may scan for beacons. In at least some embodiments, the first intermediate device is configured to receive the beacon from the endpoint device via the first network.

At block <b>620</b>, the processing logic may identify a relay server (e.g., the relay server <b>125</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>) to send a beacon message. The beacon message may include at least one of: the beacon, or information pertaining to the beacon, as described herein. In at least some embodiments, identifying the relay server to send the beacon message may include determining a geographic location of the first intermediate device and identifying the relay server from a set of relay servers. For example, the processing logic may select the relay server that is the closest relay server to the geographic location of the first intermediate device.

At block <b>625</b>, the processing logic may send the beacon message from the endpoint device to the relay server. In at least some embodiments, the beacon message may be sent from the endpoint device to the relay server in response to a determination that the first intermediate device is connected to a second network (e.g., the second network <b>120</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). In at least some embodiments, sending the beacon message from the endpoint device to the relay server may include sending the beacon message from the endpoint device to the relay server via the second network.

At block <b>630</b>, the processing logic may receive, from the relay server, a response message pertaining to the beacon message. The response message may include an identification of the endpoint device to which to send the response message. In at least one embodiment, receiving the response message pertaining to the beacon message may include receiving the response message at a second intermediate device, such as the intermediate device <b>115</b><i>b </i>of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. The first intermediate device and the second intermediate device may both have instances of a executable software application that form a virtual network of interconnected devices that may be used to transmit, carry, and receive data.

At block <b>635</b>, the processing logic may send the response message to the endpoint device, such as via the wireless network <b>110</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. In at least one embodiment, sending the response message to the endpoint device may include determining that the response message includes an instruction to send the response message to the endpoint device. To determine whether the response message includes such an instruction, the processing logic may inspect the response message, or metadata associated with the response message, to determine that the response message is to be sent to the endpoint device. In at least one embodiment, the response message may be sent to the endpoint device may via the first intermediate device or the second intermediate device.

<figref idref="DRAWINGS">FIG. <b>7</b></figref> illustrates a flow diagram of another example method <b>700</b> to handle communications between an endpoint device and other devices. For example, the example method <b>700</b> may be performed by an intermediate device (e.g., the intermediate device <b>115</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) to handle communications for and between an endpoint device (e.g., the endpoint device <b>105</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>) and an endpoint manager server <b>135</b> (e.g., the endpoint manager server <b>135</b> of <figref idref="DRAWINGS">FIGS. <b>1</b>-<b>4</b></figref>). In at least some embodiments, the processing logic may include software that is installed on more than one device.

The method <b>700</b> may begin at block <b>705</b>, where processing logic may receive a beacon from an endpoint device, such as via a wireless network (e.g., the wireless network <b>110</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). At block <b>710</b>, the processing logic may determine whether to request a response message from a server (e.g., the endpoint manager server <b>135</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>).

In response to a determination to request a response message from a server (“YES” at block <b>710</b>), the processing logic may identify a relay server to send a beacon message at block <b>715</b>. At block <b>720</b>, the processing logic may send the beacon message to the server identified at block <b>715</b>. At block <b>725</b>, the processing logic may receive a response message from the server. At block <b>730</b>, the processing logic may send the response message to the endpoint device.

In response to a determination to request a response message from a server (“NO” at block <b>710</b>), the processing logic at block <b>735</b> may listen for more beacon until a predetermined event occurs. The predetermined event may include a lapse of a predetermined period of time, reaching a time threshold, reaching a storage capacity, reaching a buffer limit, etc. At block <b>740</b>, the processing logic may identify a relay server to send one or more beacon messages associated with one or more beacons identified at block <b>735</b>. At block <b>745</b>, the processing logic may send the one or more beacon messages to one or more relay servers.

<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates a diagrammatic representation of a machine in the example form of a computing device <b>800</b> within which a set of instructions, for causing the machine to perform any one or more of the methods discussed herein, may be executed. The computing device <b>800</b> may include a mobile phone, a smart phone, a netbook computer, a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, or any computing device with at least one processor, etc., within which a set of instructions, for causing the machine to perform any one or more of the methods discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server machine in client-server network environment. The machine may include a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” may also include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

The example computing device <b>800</b> includes a processing device (e.g., a processor) <b>802</b>, a main memory <b>804</b> (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory <b>806</b> (e.g., flash memory, static random access memory (SRAM)) and a data storage device <b>816</b>, which communicate with each other via a bus <b>808</b>.

Processing device <b>802</b> represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device <b>802</b> may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device <b>802</b> may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device <b>802</b> is configured to execute instructions <b>826</b> for performing the operations and steps discussed herein.

The computing device <b>800</b> may further include a network interface device <b>822</b> which may communicate with a network <b>818</b>. The computing device <b>800</b> also may include a display device <b>810</b> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device <b>812</b> (e.g., a keyboard), a cursor control device <b>814</b> (e.g., a mouse) and a signal generation device <b>820</b> (e.g., a speaker). In at least one embodiment, the display device <b>810</b>, the alphanumeric input device <b>812</b>, and the cursor control device <b>814</b> may be combined into a single component or device (e.g., an LCD touch screen).

The data storage device <b>816</b> may include a computer-readable storage medium <b>824</b> on which is stored one or more sets of instructions <b>826</b> embodying any one or more of the methods or functions described herein. The instructions <b>826</b> may also reside, completely or at least partially, within the main memory <b>804</b> and/or within the processing device <b>802</b> during execution thereof by the computing device <b>800</b>, the main memory <b>804</b> and the processing device <b>802</b> also constituting computer-readable media. The instructions may further be transmitted or received over a network <b>818</b> via the network interface device <b>822</b>.

While the computer-readable storage medium <b>826</b> is shown in an example embodiment to be a single medium, the term “computer-readable storage medium” may include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methods of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.

Terms used herein and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” may be interpreted as “including, but not limited to,” the term “having” may be interpreted as “having at least,” the term “includes” may be interpreted as “includes, but is not limited to,” etc.).

Additionally, if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases may not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” may be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation may be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, means at least two recitations, or two or more recitations). Further, in those instances where a convention analogous to “at least one of A, B, and C, etc.” or “one or more of A, B, and C, etc.” is used, in general such a construction is intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc. For example, the use of the term “and/or” is intended to be construed in this manner.

Further, any disjunctive word or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, may be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” may be understood to include the possibilities of “A” or “B” or “A and B.”

Embodiments described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general purpose or special purpose computer. Combinations of the above may also be included within the scope of computer-readable media.

Computer-executable instructions may include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used herein, the terms “module” or “component” may refer to specific hardware implementations configured to perform the operations of the module or component and/or software objects or software routines that may be stored on and/or executed by general purpose hardware (e.g., computer-readable media, processing devices, etc.) of the computing system. In some embodiments, the different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While some of the system and methods described herein are generally described as being implemented in software (stored on and/or executed by general purpose hardware), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated. In this description, a “computing entity” may be any computing system as previously defined herein, or any module or combination of modulates running on a computing system.

All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although embodiments of the present disclosure have been described in detail, it may be understood that the various changes, substitutions, and alterations may be made hereto without departing from the spirit and scope of the present disclosure.