Power efficient wireless connectivity

Described herein are systems and methods for maintaining a wireless connection to a remote server while a device is in a low power mode. As a result of maintaining the connection, the device can receive messages triggering a wakeup event and placing the device in a normal power mode, enabling the device to be controlled remotely. To maintain the connection, the device transitions from sending encrypted network messages to a server from a first interval while in the normal power mode to a second interval while in the low power mode. In addition, the device sends unencrypted network messages to the server at the first interval using low power circuitry. The low power circuitry receives messages from the server and may trigger the device to enter the normal power mode and/or a connection maintenance mode.

BACKGROUND

Electronic devices may be configured to connect to remote servers via a network while in an active state. The electronic devices may maintain the connection in order to improve device responsiveness, reduce a latency associated with responding to input commands and to enable additional functionality such as the ability to control the electronic devices remotely.

DETAILED DESCRIPTION

Electronic devices may be configured to connect to remote servers via a network while in an active state. The devices may maintain the connection in order to improve device responsiveness, reduce a latency associated with responding to input commands, and to enable additional functionality such as the ability to control the electronic devices remotely. Because the active state may consume energy (e.g., electrical power) a device may monitor user activity and/or system activity and enter a sleep state (e.g., a type of low power state) to conserve energy. While in the sleep state, however, the device might lose connection to the network and/or remote servers. After the connection is loss, transitioning from the sleep state to the active state may cause the user to experience a delay as the device reconnects to the network and/or remote server. In addition, when the device is in the sleep state, the user loses the ability to wake the device using the remote server and/or a companion application.

To improve user responsiveness and/or reduce energy consumption, devices, systems and methods may provide an improved sleep state (e.g., low power mode) that remains connected to a network and/or a remote server(s) while consuming less energy than while in the active state (e.g., normal power mode). Thus, a device in the low power mode may have reduced latency and improved user-perceivable responsiveness when transitioning from the low power mode to the normal power mode as the device may communicate with the remote server(s) with much less delay associated with reconnecting to the remote server(s). In addition, as the device maintains a connection with the remote server(s), the device may be controlled remotely in the low power mode. For example, the user may use a companion application running on an external device to send a command to the device via the remote server(s), enabling the user to wake the device from the low power mode and/or input other commands. Therefore, the device may consume less energy and/or have improved battery life as the device may enter the low power mode more frequently without substantially degrading a user experience and/or removing functionality.

To maintain a connection with the remote server(s), the device may send encrypted network messages at a first interval (e.g., every 30 seconds) while in the normal power mode (e.g., first mode) and may send the encrypted network messages at a second interval (e.g., every 5 minutes) while in the low power mode (e.g., second mode). For example, prior to entering the low power mode, the device may send a notification to the remote server(s) indicating the second interval and the device may set a timer using clock circuitry to trigger a wakeup event. The wakeup event may instruct the device to enter the normal power mode and/or a connection maintenance mode. For example, the device may enter the connection maintenance mode to communicate to the remote server(s) (e.g., send encrypted network messages and/or reconnect to the remote server(s)) and return to the low power mode without entering the normal power mode. Thus, the device may remain in the low power mode until the timer triggers the wakeup event, at which point the device may send an encrypted network message to the remote server(s). As the remote server(s) are aware that the device is in the low power mode, they maintain the connection based on the second interval instead of the first interval. In addition, the device may send unencrypted network messages to the remote server(s) to maintain the connection. For example, the device may send the unencrypted network messages using low power circuitry (e.g., wireless transceiver or the like) at the first interval while the device remains in the low power mode. While in the low power mode, the low power circuitry may receive messages from the remote server(s) and may trigger a wakeup event.

FIG. 1illustrates a system100that includes a device102capable of entering a low power mode. Whether in a normal power mode (e.g., first mode) or the low power mode (e.g., second mode), the device102may remain connected to network(s)199and server(s)112. For example, the device102may receive audio commands from a user10, generate audio data corresponding to the audio commands and send the audio data to the server(s)112. The server(s)112may perform automatic speech recognition (ASR) processing, natural language understanding (NLU) and/or other processing to determine a command corresponding to the audio data and may send an instruction to the device102to perform the command. As illustrated inFIG. 1, the system100may include one or more companion devices110local to user(s)10, as well as one or more networks199and one or more server(s)112connected to the device102across the network(s)199. Thus, the device102may receive messages from a companion device110controlled by a user10, as well as from server(s)112(e.g., server(s)112aand server(s)112b) via a Virtual Internet Protocol (VIP) address114. Therefore, the user10and/or server(s)112may control the device102remotely even when the device102is in the low power mode.

The device102may include a central processor unit (CPU)104and low power circuitry106(e.g., network interface such as a wireless transceiver, although the disclosure is not limited thereto). While in the normal power mode, the CPU104and the low power circuitry106may remain in an active state, consuming more energy than the low power mode but performing additional functionality. For example, the CPU104may send encrypted network messages to the server(s)112in the normal power mode. While in the low power mode, the low power circuitry106may remain in the active state but the CPU104may enter a low power state, reducing the energy consumption and functionality. For example, the low power circuitry106may send unencrypted network messages to the server(s)112in the low power mode.

The device102may be a portable electronic device (e.g., smartphone, tablet, laptop, voice-enabled device or the like) configured to operate using battery power, and the device102may enter the low power mode in order to reduce energy consumption and conserve the battery power. However, the disclosure is not limited thereto and the device102may be a wired electronic device with or without a battery. For example, the device102may be an appliance (e.g., washer, dryer, refrigerator, or the like), an entertainment device (e.g., television, speakers, video game console, or the like), computing device (e.g., desktop computer, server, external hard drive or the like) and/or consumer electronic device that may enter the low power mode in order to reduce energy consumption.

The CPU104may be one or more primary or application processors configured to execute an operating system, applications or the like. The CPU104is configured to transition between the normal power mode and the low power mode in order to reduce energy consumption. The normal power mode consumes more electrical power than the low power mode. The low power mode may also be referred to as “sleep” or “suspend mode” or the like.

The low power circuitry106may be a network interface or other circuitry on the device102that includes an interface processor configured to maintain a network connection while in the low power mode. For example, the low power circuitry106may be a wireless transceiver or other wireless network circuitry on the device102. However, the disclosure is not limited thereto and the low power circuitry106may be a wired network interface or other component without departing from the disclosure. The low power circuitry106may consume less energy than the CPU104and may be configured to transition between a normal power mode and a low power mode. The low power circuitry106may be configured to establish a network connection with the network(s)199and exchange data and/or messages with devices (e.g., companion device110and/or server(s)112) via the network(s)199.

The low power circuitry106may be configured to block inbound data unless the device102has previously initiated a network connection. Thus, the server(s)112cannot initiate a network connection with the device102, but the device102may initiate the network connection with the server(s)112. Blocking the inbound data improves network security for the device102but may prevent legitimate resources such as the server(s)112from communicating directly with the device102. For example, when the server(s)112have data to send to the device102, the low power circuitry106may block this message.

To maintain a network connection to the server(s)112, the device102may be configured to send keepalive data to the server(s)112. Ongoing transmission of the keepalive data across the network(s)199maintains the network connection between the device102and the server(s)112. For example, the device102may send encrypted keepalive messages including keepalive data at a first interval (e.g., every 30 seconds). The encrypted keepalive messages may be sent using cryptographic protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL) or the like using network protocols such as Transmission Control Protocol (TCP)/Internet Protocol (IP) (hereinafter referred to as TCP/IP). In response receiving the encrypted keepalive messages, the server(s)112may send acknowledgement messages to the device102. In some examples, the device102may send the encrypted keepalive messages to a specific server112ato maintain a single connection. However, the disclosure is not limited thereto and the device102may send encrypted keepalive messages to multiple servers112to maintain multiple connections without departing from the disclosure. While the network connection is maintained, the server(s)112may communicate as needed with the device102. However, if the server(s)112do not receive the encrypted keepalive messages for a first duration of time (e.g., 2 minutes), the server(s)112may send a notification to the device102that the server(s)112is closing the network connection. The device102may attempt to reconnect with the server(s)112to maintain the network connection. Similarly, if the device102does not receive the acknowledgement messages for a second duration of time (e.g., 2 minutes), the device102may attempt to reconnect with the server(s)112to maintain the network connection.

To reduce power consumption, the device102may enter the low power mode and send the encrypted keepalive messages including the keepalive data at a second interval (e.g., every 5 minutes). Prior to entering the low power mode, the device102may send an encrypted notification to the server(s)112indicating that the device102will be entering the low power mode and specifying the second interval. The device102may determine a duration of time associated with the second interval (e.g., 5 minutes) and the CPU104may set a timer using clock circuitry and enter the low power mode. After the duration of time elapses, the timer triggers a wakeup event that instructs the CPU104to enter the normal power mode or a connection maintenance mode to send an encrypted keepalive message. In the connection maintenance mode, the CPU104may send the encrypted keepalive message and reset the timer but doesn't perform other functionality, and once the encrypted keepalive message is sent the CPU104enters the low power mode. Thus, the CPU104may enter the connection maintenance mode, send the encrypted keepalive message, reset the timer for the duration of time and enter the low power mode. In contrast, if the device102enters the normal power mode the device102may send a notification to the server(s)112that the device102is in the normal power mode and/or perform other actions before entering the low power mode.

To reduce power consumption, the low power circuitry106may be configured by the CPU104to send the keepalive data while the CPU104is in the low power mode. For example, the low power circuitry106may send unencrypted keepalive messages including the keepalive data at the first interval (e.g., every 30 seconds). The unencrypted keepalive messages may be sent using network protocols (e.g., TCP/IP) but without cryptographic protocols (e.g., TLS, SSL or the like). However, the disclosure is not limited thereto and the low power circuitry106may send encrypted keepalive messages and/or send the keepalive data at a second interval without departing from the present disclosure. Prior to the device102sending the unencrypted keepalive messages to the server(s)112, the device102may send an encrypted notification indicating to the server(s)112that the device102will be sending unencrypted keepalive messages in order to maintain the connection.

While the network connection between the device102and the server(s)112is maintained, the low power circuitry106may be configured to monitor incoming messages from the server(s)112and may trigger a wakeup event. For example, the low power circuitry106may receive a message matching a wakeup signature and may trigger a normal wakeup event that instructs the CPU104to wakeup (e.g., transition from the low power mode to the normal power mode). Once in the normal power mode, the application processor may communicate with the server or take other action. Additionally or alternatively, the low power circuitry106may trigger a connection wakeup event that instructs the CPU104to enter the connection maintenance mode, communicate with the server(s)112to maintain the connection and enter the low power mode without performing other functionality or entering the normal power mode. For example, in response to the server(s)112sending a message indicating that the connection will be ended unless the device102responds, the low power circuitry106may trigger the CPU104to enter the connection maintenance mode to communicate with the server(s)112and maintain the connection before returning to the low power mode. In contrast, if the CPU104enters the normal power mode the device102may send a notification to the server(s)112that the CPU104is in the normal power mode and/or perform other actions before entering the low power mode.

The wakeup signature may include a source address, destination address, source port and destination port associated with the connection between the device102and the VIP114. Thus, the low power circuitry106may identify messages from the VIP114and trigger a wakeup event (or connection wakeup event) while ignoring messages from other source addresses/ports. For example, messages sent directly from the companion device110to the device102would not match the wakeup signature and therefore not trigger a wakeup event. However, if the companion device110sent a message to the server(s)112instructing the server(s)112to send a message to the device102via the VIP114, the device102would receive the message from the VIP114, determine that the message matched the wakeup signature and trigger a wakeup event. For example, the user10may use a companion application running on the companion device110to trigger the wakeup event of the device102and/or perform other commands.

In order to trigger the wakeup event, each of the server(s)112in communication with the device102may send messages to the device102via the VIP114, such that a first message from a first server112ahas the same source address and source port as a second message from a second server112b. Thus, the VIP114may be associated with the server(s)112and the device102may communicate with multiple server(s)112simultaneously via the VIP114. For example, the first server112amay be associated with a first service and/or application whereas the second server112bmay be associated with a second service and/or application. Additionally or alternatively, the second server112bmay be associated with the first service and/or application and may communicate with the device102at a later point in time than the first server112a. In addition to the VIP114, various networking devices (e.g., routers, firewalls, network address translators or the like) may process the data during transit between the device102and the server(s)112and/or companion device110.

As illustrated inFIG. 1, the device102may enter (120) a normal power mode and send (122) encrypted keepalive message(s) to the server(s)112while in the normal power mode. At a certain point in time, the device102may determine (124) to enter the low power mode. For example, the device102may detect limited system activity and/or user activity for a duration of time and may transition to the low power mode to conserve energy. Additionally or alternatively, the device102may detect input (e.g., button press on the device102, an instruction received from a companion application running on the companion device110, or the like) instructing the device102to enter the low power mode.

Prior to entering the low power mode, the device102may send (126) a low power mode notification to the server(s)112. The low power mode notification may inform the server(s)112that the device102is entering the low power mode in order to modify connection parameters. For example, the device102may transition from sending encrypted keepalive message(s) at a first time interval (e.g., every 30 seconds) to a second time interval (e.g., every 5 minutes), may transition from sending encrypted keepalive message(s) to sending unencrypted keepalive message(s), and/or may inform the server(s)112of the wakeup signature, a fixed payload and/or other message characteristics in use when the device102is in the low power mode. Using the wakeup signature, the server(s)112may send a message to the device102that triggers a wakeup event on the device102while the device102is in the low power mode. However, in some examples the wakeup signature may be fixed by the device102based on the connection between the device102and the VIP114and the server(s)112may not be aware of the wakeup signature. Using the fixed payload, the server(s)112may validate unencrypted keepalive message(s) that include the fixed payload.

The device102may configure (128) the low power circuitry and enter (130) the low power mode. For example, the CPU104may configure the low power circuitry106prior to entering the low power mode. In some examples, the CPU104may configure the low power circuitry106to send the unencrypted keepalive message(s) during the low power mode, including specifying the fixed payload, network and/or session parameters associated with the unencrypted keepalive messages or the like. Thus, the low power circuitry106may send (132) unencrypted keepalive message(s) to the server(s)112, the unencrypted keepalive message(s) including the fixed payload, specific addresses associated with the server(s)112or the like.

Additionally or alternatively, the CPU104may configure the low power circuitry106with regard to wakeup events. In some examples, the CPU104may send the low power circuitry106a wakeup signature with which to monitor incoming messages. Thus, when the low power circuitry106receives a message matching the wakeup signature, the low power circuitry106may trigger a wakeup event for the CPU104. As will be discussed in greater detail below, the wakeup signature may include a source address, a destination address, a source port and a destination port, although the disclosure is not limited thereto and the wakeup signature may include additional data.

In some examples, the CPU104may differentiate between a normal wakeup event (e.g., the CPU104transitions from the low power mode to the normal power mode) and a connection wakeup event (e.g., the CPU104transitions from the low power mode to the connection maintenance mode and back to the low power mode). For example, the low power circuitry106may initiate a connection wakeup event when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for a first duration of time, when the low power circuitry106receives a message from the server(s)112indicating that the connection will be closed, when a second duration of time elapses, and/or in response to other conditions. When the device102sends a keepalive message (encrypted and/or unencrypted) to the server(s)112, the server(s)112respond with an acknowledgement message acknowledging receipt of the keepalive message. Thus, when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for the first duration of time, the low power circuitry106may determine that the device102is not communicating to the server(s)112and may trigger the connection wakeup event for the CPU104to reconnect to the server(s)112before resuming the low power mode. Similarly, when the low power circuitry106receives the message from the server(s)112indicating that the connection will be closed, the low power circuitry106may trigger the connection wakeup event for the CPU104to maintain the connection to the server(s)112before resuming the low power mode. Finally, the second duration of time may be associated with the second interval at which the CPU104sends encrypted keepalive messages during the low power mode. Thus, the low power circuitry106may set a timer or otherwise monitor the second duration of time and trigger a connection wakeup event when the second duration of time has elapsed.

While the above example describes the low power circuitry106being configured to trigger a connection wakeup event based on contents of messages received from the server(s)112(e.g., when the low power circuitry106receives a message from the server(s)112indicating that the connection will be closed), the disclosure is not limited thereto. For example, the low power circuitry106may trigger a normal wakeup event for any message that matches the wakeup signature, and the CPU104may determine whether the message requires establishing/maintaining a connection to the server(s)112or performing other actions. Thus, the low power circuitry106may not identify messages from the server(s)112indicating that the connection will be closed, but may instead trigger the normal wakeup event when the messages match the wakeup signature and the CPU104may determine what action(s) to perform. Additionally or alternatively, the low power circuitry106may not determine when the second duration of time elapses. Instead, the CPU104and/or other circuitry (e.g., clock circuitry included in the CPU104or elsewhere on the device102) may set a timer corresponding to the second duration of time and may trigger a connection wakeup event when the second duration of time elapses. Further, the disclosure is not limited to triggering a connection wakeup event when the second duration of time elapses, and the CPU104, the low power circuitry106and/or other circuitry may trigger a normal wakeup event instead.

As illustrated inFIG. 1, the device102may determine (134) if a wakeup event is detected (e.g., detection of a wakeword). A wakeup event may include a connection wakeup event and/or a normal wakeup event. If the device102determines that a wakeup event is not detected, the device102may loop (136) to step132and remain in the low power mode. If the device102determines that a connection wakeup event is detected, the device102may enter (138) the connection maintenance mode and communicate (140) with the server(s)112before looping (142) to step130and entering the low power mode. However, while communicating with the server in step140, the device102may receive first messages requiring the device102to perform additional operations. If the device102receives these first messages, the device102may loop (144) to step120and enter the normal power mode to perform the additional operations. Additionally or alternatively, if the device102determines that a normal wakeup event is detected, the device102may loop (146) to step120and enter the normal power mode. The device102may continue to operate in the normal power mode until determining to enter the low power mode again.

WhileFIG. 1illustrates the device102differentiating between a normal wakeup event and a connection wakeup event, the disclosure is not limited thereto and the device102may only detect normal wakeup events. For example, the low power circuitry106may initiate a normal wakeup event upon receiving a message matching the wakeup signature, when the low power circuitry106doesn't receive the acknowledgement message from the server(s)112for the first duration of time, when the low power circuitry106receives the message from the server(s)112indicating that the connection will be closed, when the second duration of time elapses, and/or in response to the other conditions. Therefore, instead of entering the connection maintenance mode and returning to the low power mode after communicating with the server(s)112, the device102may instead enter the normal power mode and determine to enter the low power mode at a later point in time.

In some examples, the connection maintenance mode may be included as part of the low power mode, such that the device102remains in the low power mode while communicating with the server(s)112to establish/maintain the connection. Thus, the device102remains in the low power mode and doesn't send a notification to the server(s)112that the device102is entering the normal power mode, and/or other external indications (e.g., buttons, lights, or the like on the device102) may correspond to the low power mode. In other examples, the connection maintenance mode may be included as part of the normal power mode, such that the device102enters the normal power mode to communicate with the server(s)112and then transitions back to the low power mode at a later point in time. Thus, the device102may send a notification to the server(s)112that the device102is entering the normal power mode and enter the normal power mode, and/or other external indications (e.g., buttons, lights, or the like on the device102) may correspond to the normal power mode.

FIGS. 2A-2Billustrate a state diagram and a communication diagram associated with a sleep mode. As illustrated inFIG. 2A, the state diagram includes an “On” state210, an “Off” state220and a “Sleep” state230.

Within the “On” state210, the state diagram includes an “Active On” state212and an “Idle On” state214. For example, the “Active On” state212may correspond to when a device202is active, whether performing user requested processes or background processes, whereas the “Idle On” state214may correspond to when the device202is idle, performing neither user requested process or background processes. When in the “Active On” state212, the device202may use external indications to indicate that the device202is active, such as powering on first Light Emitting Diodes (LEDs) or the like. Similarly, when in the “Idle On” state214, the device202may use external indications to indicate that the device202is idle, such as powering on second LEDs or the like. For example, the device202may provide power to a first number of LEDs in the “Active On” state212and provide power to a second, smaller, number of LEDs in the “Idle On” state214.

The device202may transition from the “Active On” state212to the “Idle On” state214in response to a “System Inactive” command216(e.g., when the device202determines that the system is inactive) and may transition from the “Idle On” state214to the “Active On” state212in response to a “System Active” command218(e.g., when the device202determines that the system is active). The device202may determine that the system is active or inactive based on a duration of time without system activity or other techniques known to one of skill in the art. The device202may consume more energy in the “Active On” state212than in the “Idle On” state214. For example, in the “Active On” state212a processor may be on, memory may auto-refresh, system clocks, buses, phase locked loops (PLLs) and other internal circuitry may be on. In contrast, in the “Idle On” state214, the processor may be in a low power mode, the memory may auto-refresh and the system clocks, buses, PLLs and other internal circuitry may be in a reduced voltage mode, such as operating at a lower frequency than in the “Active On” state212.

The “Off” state220may consume the least amount of energy, as the processor, memory, system clocks, buses, PLLs and other internal circuitry may be powered off. The device202may transition from the “On” state210to the “Off” state220in response to a “Power Off” command222, which may correspond to a power off command (e.g., an instruction received by the device202, a long button press on an external power button or the like), when a battery level is below a first threshold (e.g., 25%) and the device202detects no user activity for a period of time (e.g., 24 hours) or when the battery level is below a second threshold (e.g., 0%). The device202may transition from the “Off” state220to the “On” state210in response to a “Power on” command224, which corresponds to receiving an input (e.g., a short or long button press on the external power button) and/or detecting a physical connection (e.g., the user plugging a Universal Serial Bus (USB) cable or Line-in to the device202).

The “Sleep” state230may consume more energy than the “Off” state220but less energy than the “On” state210. For example, the “Sleep” state230may correspond to a low power mode in which the processor is gated, the memory self-refreshes, and the system clocks, buses, PLLs and other internal circuitry (e.g., wireless transceiver) may be powered off. The device202may transition from the “On” state210to the “Sleep” state230in response to a “User Inactive” command232(e.g., when the device202determines that the user is inactive for a period of time (e.g., 24 hours), when the battery level is below a third threshold (e.g., 5%), in response to a command from the user instructing the device102to enter the “Sleep” state230(e.g., button press, input received from companion application, etc.), or the like). The device202may transition from the “Sleep” state230to the “On” state210in response to the “User Active” command234, which corresponds to receiving an input (e.g., a short or long button press on any external button) and/or detecting a physical connection (e.g., the user plugging the USB cable or Line-in to the device202). The device202may transition from the “Sleep” state230to the “Off” state220in response to the “Power Off” command236, which corresponds to receiving a physical power off command (e.g., detecting a long button press on an external power button or the like).

Using the state diagram illustrated inFIG. 2A, a device202may reduce energy consumption by entering the “Sleep” state230. However, in the “Sleep” state230the device202powers off internal circuitry such as a wireless transceiver or other network adapters and the device202loses connections to the server(s)112. Therefore, the device202loses functionality and cannot receive messages from the server(s)112and/or be controlled remotely by a companion application and/or the server(s)112. Thus, the device202enters the “Sleep” state230only after determining that the device202hasn't detected user activity for a relatively long duration of time, such as 24 hours.

FIG. 2Billustrates a communication diagram for the device202using the state diagram ofFIG. 2A. As illustrated inFIG. 2B, the device202may detect (1250) system activity and send (1252) keepalive data to the VIP114, which may send (1254) the keepalive data to the server(s)112. The device202may be configured to send the keepalive data at a first interval (e.g., every 30 seconds) while in the “On” state210. Upon receiving the keepalive data, the server(s)112may send an acknowledgement message (not illustrated) to the device202to confirm receipt of the keepalive data. While the server(s)112receives the keepalive data, the server(s)112may maintain a connection between the device202and the server(s)112.

However, the device202may detect (256) system/user inactivity (e.g., detect the “User Inactive” command232) and may enter (258) sleep mode (e.g., “Sleep” state230). During the sleep mode, the device202may power off network adapters and therefore the device202doesn't send keepalive data to the VIP114and/or the server(s)112. The server(s)112may maintain the connection until the server(s)112determine that the keepalive data has not been received for a duration of time. For example, if the device202sends the keepalive data at the first interval (e.g., every 30 seconds), the server(s)112may maintain the connection until the server(s)112determine that the keepalive data is not received for a fixed number of cycles (e.g., three cycles) and/or a fixed duration of time (e.g., 2 minutes). Therefore, the server(s)112may determine (260) that the keepalive data is not received for the fixed number of intervals (e.g., three intervals of 30 seconds each) and/or the duration of time (e.g., 2 minutes) and the server(s)112may disconnect (262) the device202.

While the device202is disconnected from the server(s)112, the device202cannot receive messages from the server(s)112and/or respond to remote commands. Thus, the device202may only respond to local commands input to the device202, such as input on an external button. At a later point in time, the device202may detect (264) user activity (e.g., a button press or connection of USB/line-in cable) and may enter (266) an active mode (e.g., normal power mode). After entering the active mode, the device202may establish (266) a new connection with the server(s)112, which may result in a latency and reduced user responsiveness as perceived by the user10. For example, the device202may need to establish the connection prior to performing functionality and/or responding to user commands and establishing the connection may require a fixed amount of time (e.g., 5-10 seconds). Therefore, the user10may perceive the latency and/or reduced user responsiveness as sluggishness of the device202when transitioning from the sleep mode to the active mode.

To reduce the latency and/or improve user responsiveness,FIG. 3is a state diagram illustrating a low power mode according to embodiments of the present disclosure. As illustrated inFIG. 3, “Sleep” state230is replaced by Low Power Mode330, which maintains connectivity to the server(s)112while consuming less energy than the “On” state210. As illustrated inFIG. 3, the “On” state210and “Off” state220(and corresponding transitions between states) are identical to the state diagram illustrated inFIG. 2Aand a corresponding description is therefore omitted.

Low power mode330may consume more energy than the “Off” state220but less energy than the “On” state210. For example, the low power mode330may corresponds to a low power mode in which the processor is gated, the memory self-refreshes, the system clocks, buses, PLLs and other internal circuitry may be powered off. In contrast to the “Sleep” state230, however, the low power mode330may maintain power to low power circuitry (e.g., wireless transceiver or other circuitry) and the device may be operating using the low power circuitry, such as low power circuitry106. Therefore, while in the low power mode, the device102may maintain a connection to the server(s)112using the low power circuitry106while the processor (e.g., CPU104) is in a low power mode.

The device102may transition from the “On” state210to the low power mode330in response to a “User Inactive” command232, as described above with regard toFIG. 2A. However, as the device102maintains a connection to the server(s)112and therefore may receive messages and/or be controlled remotely via the server(s)112, the device102may enter the low power mode more aggressively, such as when the device102determines that the user is inactive for a second period of time (e.g., 5 minutes) that is much shorter than the first period of time (e.g., 24 hours) used to enter the “Sleep” state230.

As illustrated inFIG. 3, the device102may transition from the low power mode330to the “On” state210in response to the “User Active” command234(as described above with regard toFIG. 2A) and a normal wakeup event332, which may be triggered by the low power circuitry106. For example, the low power circuitry106may monitor incoming messages and trigger the normal wakeup event332when a message matches a wakeup signature. As will be discussed in greater detail below, the wakeup signature may include a source address, a destination address, a source port and a destination port, although the disclosure is not limited thereto and the wakeup signature may include additional data. In response to the normal wakeup event332, the device102may transition from the low power mode330to the “On” state210(e.g., normal power mode) and may perform operations and/or other functionality with reduced latency perceived by the user. For example, the user10may use a companion application running on the device10to instruct the server(s)112to send a command to the device102to trigger the normal wakeup event332and instruct the device102to play music. Thus, while in the low power mode330, the device102may transition to the normal power mode and play the music requested by the user10.

Additionally or alternatively, the low power circuitry106may trigger the normal wakeup event332for connection maintenance. For example, the low power circuitry106may initiate a connection wakeup event when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for a first duration of time, when the low power circuitry106receives a message from the server(s)112indicating that the connection will be closed, when a second duration of time associated with sending encrypted keepalive messages elapses, and/or in response to other conditions. When the device102sends a keepalive message (encrypted and/or unencrypted) to the server(s)112, the server(s)112respond with an acknowledgement message acknowledging receipt of the keepalive message. Thus, when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for the first duration of time, the low power circuitry106may determine that the device102is not communicating to the server(s)112and may trigger the normal wakeup event332so that the device102may enter the normal voltage mode and reconnect to the server(s)112. Similarly, when the low power circuitry106receives the message from the server(s)112indicating that the connection will be closed, the low power circuitry106may trigger the normal wakeup event332so that the device102may enter the normal voltage mode and maintain the connection to the server(s)112. Finally, the second duration of time may be associated with a second interval at which the device102sends encrypted keepalive messages during the low power mode330. Thus, the low power circuitry106may set a timer or otherwise monitor the second duration of time and trigger the normal wakeup event332when the second duration of time has elapsed.

In some examples, the device102may differentiate between the normal wakeup event332and a connection wakeup event342, which corresponds to the connection maintenance described above. For example, the low power circuitry106may trigger the connection wakeup event342so that the device102enters the connection maintenance mode340to establish and/or maintain connection to the server(s)112and then, in response to a connection complete344command, transition back to the low power mode330. Thus, the device102maintains the connection using the connection maintenance mode340without entering the “On” state210(e.g., normal power mode) and/or sending a notification to the server(s)112that the device102is in the normal power mode.

For example, the low power circuitry106may initiate the connection wakeup event342when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for a first duration of time, when the low power circuitry106receives a message from the server(s)112indicating that the connection will be closed, when a second duration of time associated with sending the encrypted keepalive messages elapses, and/or in response to other conditions. When the device102sends a keepalive message (encrypted and/or unencrypted) to the server(s)112, the server(s)112respond with an acknowledgement message acknowledging receipt of the keepalive message. Thus, when the low power circuitry106doesn't receive an acknowledgement message from the server(s)112for the first duration of time, the low power circuitry106may determine that the device102is not communicating to the server(s)112and may trigger the connection wakeup event342for the device102to enter the connection maintenance mode340and reconnect to the server(s)112before resuming the low power mode330. Similarly, when the low power circuitry106receives the message from the server(s)112indicating that the connection will be closed, the low power circuitry106may trigger the connection wakeup event342for the device102to enter the connection maintenance mode340and maintain the connection to the server(s)112before resuming the low power mode330. Finally, the second duration of time may be associated with the second interval at which the CPU104sends encrypted keepalive messages during the low power mode330. Thus, the low power circuitry106may set a timer or otherwise monitor the second duration of time and trigger the connection wakeup event342for the device102to enter the connection maintenance mode340and send the encrypted keepalive message when the second duration of time has elapsed.

In order to enable additional functionality (e.g., control the device102remotely) and/or reduce latency or improve user responsiveness when transitioning from the low power mode330to the normal power mode (e.g., “On” state210), the device102may be configured to maintain a connection with the server(s)112during the low power mode330. The device102may maintain the connection with the server(s)112and/or enable additional functionality using multiple techniques, as described in greater detail below. For example, the device102may maintain the connection to the server(s)112by sending encrypted keepalive messages at a different interval during the low power mode330, the low power circuitry106may maintain the connection to the server(s)112by sending unencrypted keepalive messages during the low power mode330and/or triggering the normal wakeup event332/connection wakeup event342, and the low power circuitry106may monitor incoming messages and trigger the normal wakeup event332to enable the additional functionality.

FIG. 4is a communication diagram that illustrates sending encrypted network messages at different intervals according to embodiments of the present disclosure. In order to maintain the connection between the device102and the server(s)112, the device102may send encrypted keepalive messages at a first interval (e.g., every 30 seconds) in the normal power mode. However, sending the encrypted keepalive messages may require that the device102be in the normal power mode, and entering the normal power mode to send messages at the first interval negates the reduction in energy consumption of the low power mode. Therefore, the device102may send the encrypted keepalive messages at a second interval (e.g., every 5 minutes) in the low power mode.

As illustrated inFIG. 4, the CPU104may enter (410) the normal power mode and may send (412) the encrypted keepalive messages to the server(s)112(via the low power circuitry106and the VIP114) using a first time period (e.g., 30 seconds) that corresponds to the first interval. The CPU104may determine (414) to enter the low power mode and may send (416) a low power mode notification to the server(s)112indicating a second interval that corresponds to a second time period (e.g., 5 minutes). The CPU104may enter (418) the low power mode and operate in a low power mode to reduce energy consumption. At a later point in time, the CPU104may determine (420) that the second time period has passed, enter (422) the connection maintenance mode, send (424) an encrypted keepalive message and enter (426) the low power mode again. In some examples, the CPU104may determine that the second time period has elapsed by setting a timer using clock circuitry included in the CPU104, the low power circuitry106and/or other components on the device102. However, the disclosure is not limited thereto and the CPU104may determine that the second time period has elapsed using techniques known to one of skill in the art. Thus, the CPU104may continue to transition from the low power mode to the connection maintenance mode and send the encrypted keepalive messages based on the second time period.

FIG. 5is a communication diagram that illustrates sending unencrypted network messages according to embodiments of the present disclosure. As discussed above, the CPU104may send the encrypted keepalive messages using cryptographic protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL) or the like using network protocols such as Transmission Control Protocol (TCP)/Internet Protocol (IP) (hereinafter referred to as TCP/IP). In contrast, the low power circuitry106may send unencrypted keepalive messages using network protocols (e.g., TCP/IP) but without cryptographic protocols (e.g., TLS, SSL or the like). For purposes of illustrating a primary example embodiment, the drawings and corresponding descriptions illustrate the CPU104sending encrypted keepalive messages and the low power circuitry106sending unencrypted keepalive messages. However, in other examples the keepalive messages sent from the CPU104may not be encrypted and/or the keepalive messages sent by the low power circuitry106may be encrypted without departing from the present disclosure. For example, the low power circuitry106may send encrypted keepalive messages at the first interval during the low power mode330without departing from the disclosure.

As illustrated inFIG. 5, the CPU104may enter (410) the normal power mode and may send (412) the encrypted keepalive messages to the server(s)112(via the low power circuitry106and the VIP114) using a first time period (e.g., 30 seconds) that corresponds to the first interval. The CPU104may determine (414) to enter the low power mode and may send (416) a low power mode notification to the server(s)112indicating that the low power circuitry106will send unencrypted keepalive messages using the first time period.

The CPU104may configure (510) the low power circuitry106by sending network and/or session parameters to the low power circuitry106, along with the first time period and other data required to send the unencrypted keepalive messages. The CPU104may enter (418) the low power mode and, while the CPU104is in the low power mode, the low power circuitry106may send (512) the unencrypted keepalive messages using the first time period.

FIG. 6is a communication diagram that illustrates sending encrypted network messages at different intervals along with sending unencrypted network messages according to embodiments of the present disclosure. WhileFIG. 4illustrates the CPU104sending the encrypted keepalive messages using the second time period andFIG. 5illustrates the low power circuitry106sending the unencrypted keepalive messages using the first time period,FIG. 6illustrates both examples occurring simultaneously.

As illustrated inFIG. 6, the CPU104may enter (410) the normal power mode and may send (412) the encrypted keepalive messages to the server(s)112(via the low power circuitry106and the VIP114) using a first time period (e.g., 30 seconds) that corresponds to the first interval. The CPU104may determine (414) to enter the low power mode and may send (416) a low power mode notification to the server(s)112indicating that the CPU104will send encrypted keepalive messages using a second time period and that the low power circuitry106will send unencrypted keepalive messages using the first time period.

The CPU104may configure (510) the low power circuitry106by sending network and/or session parameters to the low power circuitry106, along with the first time period and other data required to send the unencrypted keepalive messages. The CPU104may enter (418) the low power mode and, while the CPU104is in the low power mode, the low power circuitry106may send (512) the unencrypted keepalive messages using the first time period. While the low power circuitry106sends the unencrypted keepalive messages using the first time period, the CPU104may send the encrypted keepalive messages using the second time period. For example, the CPU104may determine (420) that the second time period has passed, enter (422) the connection maintenance mode, send (424) an encrypted keepalive message and enter (426) the low power mode again.

Using the techniques illustrated inFIGS. 4, 5 and/or 6, the device102may send encrypted/unencrypted keepalive messages in order to maintain a connection to the server(s)112during the low power mode.

FIG. 7illustrates an example of connection data according to embodiments of the present disclosure. Connection data700may provide information to the low power circuitry106for use in maintaining an established network connection. For example, the CPU104may send the connection data700to the low power circuitry106in order to configure the low power circuitry106to send keepalive messages to the server(s)112. In some examples, the connection data700may be provided to the low power circuitry106using an application programming interface (“API”) provided by an operating system of the device102.

As illustrated inFIG. 7, the connection data700may include an established connection identifier710, a keepalive interval720, keepalive data730and other data750. The established connection identifier710may identify a particular connection, such as a connection between the device102and a first server112a. In some examples, the device102may be connected to multiple servers112(e.g.,112a,112b, etc.) simultaneously and the CPU104may send connection data700(e.g.,700a,700b, etc.) corresponding to each server112. The keepalive interval720may define an interval of time between transmission of the keepalive data. For example, the device102may send encrypted keepalive messages using a first keepalive interval720a(e.g., 30 seconds) in the normal power mode, may send encrypted keepalive messages using a second keepalive interval720b(e.g., 5 minutes) in the low power mode and may send unencrypted keepalive messages using the first keepalive interval720ain the low power mode. As described herein, examples of keepalive intervals may be illustrated as rounded numbers, such as 30 seconds or 5 minutes. However, the disclosure is not limited thereto and actual keepalive intervals may be specific numbers, such as 27 seconds or 4.5 minutes without departing from the present disclosure. In some examples, the low power circuitry106may be configured to test different intervals with a particular server112xin order to determine a keepalive interval720in which bidirectional communication with the server112xis maintained but which minimizes transmissions.

The connection data700may also include keepalive data730, which may include one or more of a source address732, a source port734, a destination address736, a destination port738, encryption740and/or a payload742. The source address732may specify an address of the device102on the network(s)199, such as an IP address. The source port734may specify a particular TCP or UDP port, although the disclosure is not limited thereto and the protocols may vary. The destination address736may specify an address of the server112xon the network(s)199, such as an IP address. The destination port738may specify a particular TCP or UDP port, although the disclosure is not limited thereto and the protocols may vary. In some examples, the connection data730may indicate the protocol (e.g., TCP, UDP, etc.) such that the low power circuitry106may send the keepalive data730as a TCP packet, a UDP packet or the like. In some examples, the keepalive data730may be encrypted. The connection data730may include the encryption740information such as keys, initialization vectors or the like. The keepalive data730may also include a payload742, such as a current battery state, last known geographic location or the like. In some examples, the unencrypted keepalive messages may specify a fixed payload742known to the server(s)112in order to validate the keepalive data. Additionally or alternatively, the other data750may be included in the connection data700. For example, an established connection may have an expiration time such that after a given interval or a particular count of transmitted keepalive data730, the low power circuitry106may discontinue sending keepalive messages.

While the connection to the server(s)112is maintained, the device102may enable additional functionality, such as allowing the user10to control the device102remotely.FIG. 8is a communication diagram illustrating a wakeup event according to embodiments of the present disclosure. As illustrated inFIG. 8, the CPU104may determine (810) to enter a low power mode, may send (812) a low power mode notification to the server(s)112, and may send (814) configuration information to the low power circuitry106, including an instruction to trigger a normal wakeup event when an incoming message matches a wakeup signature. The low power circuitry106may configure (816) the low power circuitry106and the CPU104may enter (818) the low power mode.

While the CPU104is in the low power mode, the low power circuitry106may send (820) unencrypted keepalive messages to the server(s)112. However, as discussed above, the present disclosure is not limited thereto and the low power circuitry106may send encrypted keepalive messages to the server(s)112without departing from the disclosure. In some examples, the low power circuitry106may send keepalive messages (encrypted or unencrypted) including a payload to identify current session communication. Therefore, the keepalive message may be sent without encryption protocols (e.g., unencrypted) but the payload may be encrypted. While in the low power mode, the server(s)112may send (822) data matching a wakeup signature to the low power circuitry106. The low power circuitry106may identify (824) the wakeup signature (e.g., determine that the data matches the wakeup signature) and may send (826) a normal wakeup notification to the CPU104. The CPU104may enter (828) a normal power mode and may respond (830) to the data received.

FIG. 9illustrates an example of a wakeup signature according to embodiments of the present disclosure. As illustrated inFIG. 9, a wakeup signature900may include a source address902, a source port904, a destination address906, and a destination port908. One or more wakeup signatures900may be provided by the CPU104to the low power circuitry106to trigger the normal wakeup event. The low power circuitry106may be configured to compare data such as the data received from the server(s)112to the one or more wakeup signatures900. When the comparison indicates a match, the low power circuitry may generate the normal wakeup notification to transition the CPU104from the low power mode to the normal power mode. The low power circuitry106may use the wakeup signature900to define what received data will trigger or not trigger the normal wakeup event.

The source address902may indicate the address or addresses from which the data may be received. For example, the data received from an IP address of 172.16.12.02 may be acceptable for triggering the normal wakeup event, while data received from 172.16.12.04 may not. Similarly, the destination address906may indicate a valid destination address associated with the data. The source port904may indicate a port of the server(s)112from which the data was sent and the destination port908may indicate a port of the device102to which the data was sent. However, the disclosure is not limited thereto and the source port904may be a virtual port or the like and may not correspond to a port on the server(s)112. When the data matches the wakeup signature900, the low power circuitry106may be configured to trigger the normal wakeup event and transition the CPU104from the low power mode to the normal power mode. In some examples, the data may include additional data indicating a particular application and/or specified command and the device102may open the particular application and/or perform the specified command.

In some examples, the device102may configure the low power circuitry106to trigger multiple wakeup events using multiple wakeup signatures900. For example, a first wakeup signature900amay include a first source port904aand a second wakeup signature900bmay include a second source port904b. Thus, the low power circuitry106may trigger a first wakeup event using the first wakeup signature900aand may trigger a second wakeup event using the second wakeup signature900b. Additionally or alternatively, multiple wakeup signatures900may include different source addresses902and/or destination ports908to trigger individual wakeup events without departing from the disclosure.

FIG. 10is a communication diagram illustrating a communication event according to embodiments of the present disclosure. As illustrated inFIG. 10, the CPU104may determine (810) to enter a low power mode, may send (812) a low power mode notification to the server(s)112, and may send (814) configuration information to the low power circuitry106, including an instruction to trigger a normal wakeup event when an incoming message matches a wakeup signature. The low power circuitry106may configure (816) the low power circuitry106and the CPU104may enter (818) the low power mode.

While the CPU104is in the low power mode, the low power circuitry106may send (820) unencrypted keepalive messages to the server(s)112. Typically, the server(s)112sends an acknowledgement message in response to keepalive messages, indicating that the keepalive messages were received. The low power circuitry106may determine (1010) that acknowledgement message(s) were not received for a fixed duration of time (e.g., 2 minutes) and may send (1012) a connection wakeup notification to the CPU104. The CPU104may enter (1014) a connection maintenance mode, communicate (1016) to reconnect/maintain connection to the server(s)112and may enter (1018) the low power mode.

FIG. 11is a communication diagram illustrating a communication event according to embodiments of the present disclosure. As illustrated inFIG. 11, the CPU104may determine (810) to enter a low power mode, may send (812) a low power mode notification to the server(s)112, and may send (814) configuration information to the low power circuitry106, including an instruction to trigger a normal wakeup event when an incoming message matches a wakeup signature. The low power circuitry106may configure (816) the low power circuitry106and the CPU104may enter (818) the low power mode.

While the CPU104is in the low power mode, the low power circuitry106may send (820) unencrypted keepalive messages to the server(s)112. The server(s)112may send (1110) a disconnect notification to the low power circuitry106and the low power circuitry106may determine (1112) that the CPU104needs to maintain the connection to the server(s)112and may send (1114) a connection wakeup notification to the CPU104. The CPU104may enter (1116) a connection maintenance mode, communicate (1118) to reconnect/maintain connection to the server(s)112and may enter (1120) the low power mode.

FIG. 12is a flowchart conceptually illustrating an example method for entering a low power mode according to embodiments of the present disclosure. As illustrated inFIG. 12, the CPU104may enter (1210) a normal power mode and may send (1212) encrypted keepalive message(s) using a first time period. At a later point in time, the CPU104may determine (1214) to enter a low power mode, may send (1216) a low power mode notification, may configure (1218) low power circuitry106, may optionally set (1220) a timer and may enter (1222) the low power mode.

FIGS. 13A-13Care flowcharts conceptually illustrating example methods for responding to wakeup events according to embodiments of the present disclosure. As illustrated inFIG. 13A, the CPU104may determine (1310) that a time threshold is exceeded, may enter (1312) a connection maintenance mode, may send (1314) an encrypted keepalive message and may enter (1316) the low power mode again.

As illustrated inFIG. 13B, the CPU104may receive (1320) a connection wakeup notification, may enter (1322) the connection maintenance mode, may reconnect (1324) with the server and may enter (1326) the low power mode.

As illustrated inFIG. 13C, the CPU104may receive (1330) a normal wakeup notification and may enter (1332) a normal power mode.

FIGS. 14A-14Bare flowcharts conceptually illustrating example methods for transitioning between a processor and low power circuitry according to embodiments of the present disclosure. As illustrated inFIG. 14A, the CPU104may determine (1410) session parameters, may send (1412) the session parameters to low power circuitry106, may instruct (1414) the low power circuitry to enable a custom filter (e.g., corresponding to the wakeup signature), may place (1416) a socket in repair mode and may enter (1418) a low power mode.

As illustrated inFIG. 14B, the CPU104may request (1440) most recent session information from the low power circuitry106, may determine (1442) session parameters, may place (1444) the socket in normal mode and may enter (1446) normal power mode. For example, the CPU104may retrieve the session parameters and apply the session parameters prior to placing the socket in the normal mode.

FIG. 15is a flowchart conceptually illustrating an example method for low power circuitry triggering wakeup events according to embodiments of the present disclosure. As illustrated inFIG. 15, the low power circuitry106may receive (1510) configuration information from the CPU104and may send (1512) unencrypted keepalive message(s) using a first time period. The low power circuitry106may determine (1514) if a message was received, and if a message is not received, may determine (1516) if a time threshold was exceeded. If the time threshold was not exceeded, the low power circuitry106may loop (1518) to step1512and continue. If the time threshold was exceeded, the low power circuitry106may determine (1520) that acknowledgement message(s) were not received and may send (1522) a connection wakeup notification to the CPU104.

If the low power circuitry106determined that a message was received in step1514, the low power circuitry106may determine (1524) if the message matches a wakeup signature specified by the configuration information. If the message doesn't match the wakeup signature, the low power circuitry106may loop (1526) to step1512and continue. If the message matches the wakeup signature, the low power circuitry106may determine (1528) if the message is a disconnect notification. If the message is a disconnect notification, the low power circuitry106may loop (1530) to step1522and send a connection wakeup notification to the CPU104. If the message is not a disconnect notification, the low power circuitry106may send (1532) a normal wakeup notification to the CPU104.

WhileFIG. 15illustrates the low power circuitry106performing step1528to determine whether to send a connection wakeup notification or a normal wakeup notification, the disclosure is not limited thereto. Instead, the low power circuitry106may send a normal wakeup notification when the message matches the wakeup signature and the CPU104may determine whether to enter the connection maintenance mode or the normal power mode. Additionally or alternatively, the low power circuitry106may send the normal wakeup notification instead of the connection wakeup notification and the CPU104may enter the normal power mode in response to every wakeup notification.

FIG. 16is a block diagram conceptually illustrating a device102that may be used with the described system. The device102may include one or more controllers/processors1604, that may include a central processing unit (CPU) for processing data and computer-readable instructions, and a memory1606for storing data and instructions of the respective device. The memory1606may individually include volatile random access memory (RAM), non-volatile read only memory (ROM), non-volatile magnetoresistive (MRAM) and/or other types of memory. Each device may also include a data storage component1608, for storing data and controller/processor-executable instructions. Each data storage component may individually include one or more non-volatile storage types such as magnetic storage, optical storage, solid-state storage, etc. Each device may also be connected to removable or external non-volatile memory and/or storage (such as a removable memory card, memory key drive, networked storage, etc.) through respective input/output device interfaces1602.

The device102may include the CPU104, the low power circuitry106and, in some examples, clock circuitry1610. Computer instructions for operating the device102and its various components may be executed by the respective device's controller(s)/processor(s)1604/CPU104/low power circuitry106, using the memory1606as temporary “working” storage at runtime. A device's computer instructions may be stored in a non-transitory manner in non-volatile memory1606, storage1608, or an external device(s). Alternatively, some or all of the executable instructions may be embedded in hardware or firmware on the respective device in addition to or instead of software.

The device102includes input/output device interfaces1602. A variety of components may be connected through the input/output device interfaces, as will be discussed further below. Additionally, the device102may include an address/data bus1624for conveying data among components of the respective device. Each component within the device102may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus1624.

As a way of indicating to a user that a connection between another device has been opened and/or a state of the device102(e.g., active, idle, low power mode or off), the device102may be configured with a visual indicator, such as an LED or similar component (not illustrated), that may change color, flash, or otherwise provide visual indications associated with the device102. The device102may also include input/output device interfaces1602that connect to a variety of components such as an antenna1614, a microphone1616and/or a speaker1618. Via the antenna(s), the input/output device interfaces1602may connect to one or more networks199via a wireless local area network (WLAN) (such as WiFi) radio, Bluetooth, and/or wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc. A wired connection such as Ethernet may also be supported.