Low energy beacon encoding

BACKGROUND

0001Even when not being used by a user, mobile computing devices typically communicate with a cellular network at intervals to send and receive data for various purposes, such as updating the time, determining the location of the mobile computing device, or checking signal strength. These communications are often instigated by the mobile computing devices by sending a message to the network and receiving some form of response. These actions can use a significant amount of energy and reduce the battery life of the mobile computing device.

0002For communicating with other mobile devices over relatively short distances, Bluetooth® wireless technology has become increasingly popular, allowing a mobile computing device to communicate wirelessly with another nearby device without having to route the communication through a network of remote devices, such as satellites and cell towers.

SUMMARY

0003This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

0004Techniques and tools are described for transmitting beacon messages using a wireless communication protocol, such as the Bluetooth Low Energy protocol. In some examples, beacon messages can be generated in a compact format and included in an AdvData portion of a payload of a protocol data unit (PDU) of a Bluetooth Low Energy advertising channel packet. A beacon message can be transmitted from a stationary beacon generation device and broadcast to an area within a transmission range of the beacon generation device, and mobile computing devices, such as mobile phones, can receive the beacon message and perform one or more actions in response to information contained in the beacon message, all while requiring minimal energy use by beacon generation device and the mobile computing device.

0005The beacon messages can be formatted in a compact beacon message format that can include one or more type octets followed, if necessary, by a typed payload. The one or more type octets can comprise data that indicates an advertising type for the beacon message. The typed payload can contain additional data. Data contained in the beacon message can be specific to the location of the beacon generation device, such as a request for the mobile computing device to switch to silent mode or flight mode while in the area of the beacon generation device.

0006In some examples, the mobile computing device can receive a beacon message in sleep mode and process the beacon message without awaking from sleep mode, in order to conserve energy. In some examples, the mobile computing device can display a message to a user in response to a beacon message. In some examples, a beacon message can comprise a request for the mobile computing device to respond with identification information, such as to obtain security access. In some examples, a beacon message can contain a URL or other address from which the mobile computing device can retrieve additional information.

0007The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

0008<figref idref="DRAWINGS">FIG. 1</figref> is a diagram depicting exemplary mobile computing devices within an exemplary transmission range of an exemplary beacon generation device.

0009<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an exemplary method for transmitting beacon messages.

0010<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram depicting an exemplary method for receiving beacon message.

0011<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram depicting an exemplary format for beacon messages.

0012<figref idref="DRAWINGS">FIG. 5</figref> is a chart describing exemplary advertising types.

0013<figref idref="DRAWINGS">FIG. 6</figref> is a chart describing exemplary extended advertising types.

0014<figref idref="DRAWINGS">FIG. 7</figref> shows an exemplary beacon message.

0015<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram illustrating an example mobile computing device in conjunction with which techniques and tools described herein may be implemented.

DETAILED DESCRIPTION

0016The following description is directed to techniques and solutions for transmitting beacon messages using a wireless communication protocol (e.g., a low energy wireless communication protocol). For example, compact beacon messages can be transmitted from a beacon generation device to one or more mobile computing devices using a Bluetooth Low Energy wireless communication protocol. However, the techniques and solutions described herein can be applicable to many types of systems wherein a beacon message is wirelessly transmitted from one device to one or more other devices over a relatively short range.

0017The techniques and solutions described herein can also be applied to wireless communication protocols that may not be classified as low energy protocols. For example, the techniques and solutions described herein can be applied to transmitting beacon messages using other wireless communication protocols, such as Wi-Fi® (e.g., by transmitting the beacon messages within beacon frames of the Wi-Fi protocol).

0018In the techniques and solutions described herein, a beacon message refers to a message that is sent, or broadcast, repeatedly or constantly from a transmitting device to an area within a range of the transmitting device to be received by any properly configured receiving device located within that area, and which carries some information associated with the transmitting device or the location of the transmitting device. A beacon message can also be called an advertising message by some protocols, such as Bluetooth Low Energy.

Bluetooth Low Energy

0019Bluetooth Low Energy (BLE) is an exemplary wireless communication protocol that can be used to transmit beacon messages as described herein with low energy cost. The BLE specification (“BLE Specification”) is defined in Volume 6 of the Bluetooth Specification

0020Version 4.0, published Jun. 30, 2010. The BLE system uses short wavelength radio transmissions in the 2.4 GHz ISM band at 2400-2483.5 MHz and uses 40 RF channels that are 2 MHz wide. BLE can use a radio technology called frequency-hopping spread spectrum, which chops up the data being sent and transmits chunks of it on across the different channels. BLE transmissions can have a variable range, such as about 50 m, an over-the-air data rate of about 1 Mb/s, and a power consumption of about 1% to about 50% of that of Classis Bluetooth, depending on the application.

0021BLE comprises plural link layer states, including an advertising state. The link layer in the advertising state can transmit advertising channel packets and can optionally listen to and respond to responses triggered by these advertising channel packets. A BLE device in the advertising state is known as an advertiser.

0022In BLE, the 40 RF channels are allocated into two physical channels: an advertising channel and a data channel. The advertising physical channel uses three RF channels for discovering devices, initiating a connection and broadcasting data. The data physical channel uses up to 37 RF channels for communication between connected devices. The link layer uses one physical channel at a given time.

0023The BLE link layer has only one packet format used for both advertising channel packets and data channel packets. The packet format is shown in <figref idref="DRAWINGS">FIG. 4</figref> at <b>410</b>. Each packet consists of four fields: the preamble <b>412</b>, the access address <b>414</b>, the protocol data unit (PDU) <b>416</b>, and the cyclic redundancy check (CRC) <b>418</b>. When a packet is transmitted in an advertising physical channel, the PDU is called the advertising channel PDU, and when a packet is transmitted in a data physical channel, the PDU is called the data channel PDU.

0024The advertising channel PDU <b>416</b> has a 16-bit header <b>420</b> and a variable size payload <b>430</b>. The PDU type field <b>421</b> of the advertising channel PDU that is contained in the header <b>420</b> indicates the PDU type. There are currently <b>7</b> PDU types, some of which are discussed below. The length field <b>425</b> indicates the length of the payload <b>430</b> in octets. The valid range of the length field <b>425</b> is 6 to 37 octets. The RFU field <b>422</b>, TxAdd field <b>423</b>, RxAdd field <b>424</b> and RFU field <b>426</b> are not discussed herein.

0025The following advertising channel PDU types are used in the specified events:

0026ADV_IND: used in connectable undirected advertising events;

0027ADV_DIRECT_IND: used in connectable directed advertising events;

0028ADV_NONCONN_IND: used in non-connectable undirected advertising events;

0029ADV_SCAN_IND: used in scannable undirected advertising events.

0000These PDU types are sent by the link layer in the advertising state.

0030The PDU types ADV_IND, ADV_NONCONN_IND and ADV_SCAN_IND are each used in “undirected” advertising events, meaning that a transmission is broadcast to no particular receiver, but can be received by any properly configured device within the transmission range of the sending device. The ADV_IND type can be used to establish a connection with one or more receiving device, whereas the ADV_NONCONN_IND type can be used for non-connectable, or one-way, communications to one or more receiving devices, and the ADV_SCAN_IND type can be used in scanning advertising events.

0031The payload <b>430</b> for all three of the PDU types ADV_IND, ADV_NONCONN_IND and ADV_SCAN_IND is the same. The payload <b>430</b> consists of an AdvA field <b>432</b> and an AdvData field <b>434</b>. The AdvA field <b>432</b> contains <b>6</b> octets for the advertiser's public or random device address. The AdvData field <b>434</b> can contain 0 to 31 octets of advertising data from the advertiser's host. Octets 0 and 1 of the AdvData field <b>434</b> can be reserved for manufacturer data, leaving octets 2 through 31 for advertising data, though when such manufacturer data is not needed, all octets 0 through 31 can be used for advertising data.

Exemplary Beacon System

0032<figref idref="DRAWINGS">FIG. 1</figref> is a diagram depicting an exemplary beacon system <b>100</b>. The system can comprise at least one beacon generation device <b>110</b> configured to generate and transmit at least one beacon message using a low-energy wireless communication protocol, such as BLE. The beacon message can have a transmission range <b>120</b>, such as a specified maximum distance (e.g., about 50 m) from the beacon generation device <b>110</b>. The transmission range <b>120</b> can vary depending on a plurality of factors. Any properly configured device within an area <b>130</b> defined by the range <b>120</b> can receive the beacon message. The system <b>100</b> can further comprise one or more mobile computing devices <b>140</b> within the area <b>130</b> that are configured to receive the beacon message. Devices located outside of the range <b>120</b>, such as device <b>150</b>, may not receive messages from the beacon generation device <b>110</b>. Exemplary beacon generation devices and mobile computing devices are described in more detail below in the section entitled “Exemplary Devices.”

Exemplary Method for Transmitting a Beacon Message

0033<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an exemplary method <b>200</b> for transmitting beacon messages. At <b>210</b>, at least one beacon message can be generated with a beacon generation device, such as the device <b>110</b> in <figref idref="DRAWINGS">FIG. 1</figref>. The generated beacon message can be defined by a beacon message format. At <b>220</b>, the generated beacon message can be transmitted, with the beacon generation device, using a low-energy wireless communication protocol to an area, such as the area <b>130</b>, within a transmission range, such as the range <b>120</b>, of the beacon generation device for reception by one or more mobile computing devices, such as the devices <b>140</b>, located in the transmission area.

Exemplary Method for Receiving a Beacon Message

0034<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram depicting an exemplary method <b>300</b> for receiving beacon messages. At <b>310</b>, at least one beacon message can be received with a mobile computing device, such as the device <b>140</b> in <figref idref="DRAWINGS">FIG. 1</figref>. The beacon message can be transmitted in a low-energy wireless communication protocol. At <b>320</b>, the at least one action can be performed by the mobile computing device based at least in part on location-based information associated with a location of the mobile computing device when it received the beacon message. This action can be performed without input from a user of the mobile computing device.

Exemplary Beacon Message Format

0035Beacon messages can be defined by a beacon message format such that the beacon messages can be transmitted with a specific low-energy wireless communication protocol. It is also desirable for the beacon message format to require a minimal volume of data in order to conserve energy and include as many beacon messages as possible in each packet. In some examples, a beacon message format can allow for a variable length or size of the beacon message depending on the purpose of the beacon message or the type of the beacon message. For example, some beacon messages can be as short as a couple bits or one octet, while other beacon messages can be as long as the maximum size allowed by the communication protocol being used, such as to transmit complex data requiring many octets.

0036In some embodiments, when the low-energy wireless communication protocol comprises BLE, one or more beacon messages can be formatted such that they can be included in an AdvData field <b>434</b> of a payload <b>430</b> of a PDU <b>416</b> of a data channel packet <b>410</b> (see <figref idref="DRAWINGS">FIG. 4</figref>). As shown in <figref idref="DRAWINGS">FIG. 4</figref>, the AdvData field <b>434</b> can contain 0 to 31 octets of data. A beacon message in the AdvData field <b>434</b> must therefore also comprise no more than 31 octets of data, or else be parsed into multiple chunks sent in different data channel packets <b>410</b>. More typically, however, a plurality of beacon messages can be contained in the AdvData field <b>434</b> of a single data channel packet <b>410</b>. For example, <figref idref="DRAWINGS">FIG. 4</figref> shows a first beacon message <b>440</b> and an N^thbeacon message <b>460</b>, indicating N total beacon messages, contained in a single AdvData field <b>434</b>. The beacon message format exemplified in beacon messages <b>440</b> and <b>460</b> in <figref idref="DRAWINGS">FIG. 4</figref> are not limited to use with BLE, but instead can be used with other low-energy, or non-low-energy, wireless communication protocols, such as Wi-Fi.

0037As shown in <figref idref="DRAWINGS">FIG. 4</figref>, an exemplary beacon message format can comprise one or more type octets <b>442</b>, including at least a main type octet that comprises a first bit <b>446</b> followed by seven type bits <b>448</b>. Additional type octets can also be included in some beacon messages, such as an extension type octet <b>444</b>. The beacon message format can further comprise a typed payload <b>450</b>, if necessary. Some beacon messages can include a typed payload, and others can not include a typed payload. The typed payload <b>450</b> can comprise a payload length <b>452</b> followed by payload data <b>454</b>.

0038The seven type bits <b>448</b> can indicate an advertising type for the beacon message <b>440</b>. The advertising type can be one of a set of predetermined advertising types that indicate location-based information associated with a location of the beacon generation device and/or a location of the mobile computing device that receives the beacon message.

0039The first bit <b>446</b> can be either a “0” or a “1”. The first bit <b>446</b> being a “0” can indicate that the beacon message has no typed payload <b>450</b> and that no subsequent type octets are present in the beacon message. The first bit <b>446</b> being a “0” can indicate that the main type octet is the last type octet and the main type octet is the end of the beacon message. In such a beacon message, all the information necessary to affect the intended message can be included in and/or implied by the seven type bits <b>448</b>.

0040The first bit <b>446</b> being a “1” can indicate that a subsequent one or more octets of the beacon message comprise a typed payload for the beacon message. The typed payload <b>450</b> can comprise a payload length field <b>452</b> followed by payload data field <b>454</b>. The payload length field <b>452</b> can comprise the length in octets of the typed payload <b>450</b>, including the payload length field <b>452</b> itself. The payload length field <b>452</b> can comprise 5 bits (e.g., bits 0-4) of the first octet of the typed payload <b>450</b>. 5 bits can be sufficient to indicate a typed payload length of up to 32 octets. When the beacon message is included in an AdvData field in BLE, the typed payload <b>450</b> is limited to no more than 30 octets, in which case a 5-bit long payload length field <b>452</b> can be sufficient. In other embodiments, the payload length field <b>452</b> can be more or fewer than 5 bits, depending on the maximum size of the typed payload <b>450</b> allowed by the wireless communication protocol with which the beacon message is to be transmitted. In the case where the payload length field <b>452</b> is 5 bits long, the typed payload <b>450</b> can be contained in a single octet if the payload data field <b>454</b> is 3 bits or fewer.

0041Some beacon messages can comprise an extension type octet, such as the octet <b>444</b> in <figref idref="DRAWINGS">FIG. 4</figref>, preceding the first bit <b>446</b> of the main type octet. The extension type octet can indicate that the advertising type of the beacon message is an extended advertising type. The extension type octet <b>444</b>, when present in a beacon message, can comprise an 8 bit combination that the main type octet is not permitted to comprise, according to the beacon message format. For example, the extension type octet <b>444</b>, when present, can always comprise “11111111”, “FF”, or some other predetermined octet, while the main type octet can be permitted to comprise any other 8 bit combination. Because the extension type octet is unique from the main type octet, the two can be distinguished by a receiving device. In some examples, more than one extension type octet <b>444</b> can be included preceding the main type octet. The extension type octets <b>444</b> can be included in a beacon message when the total number of possible predetermined advertising types exceeds <b>128</b>, the amount of different advertising types that can be indicated by the seven type bits <b>448</b>. Each extension type octet <b>444</b> preceding the main type octet can be effective to double the number of different advertising types that can be indicated by the type octets <b>442</b>.

0042In the cases where one or more beacon messages are transmitted in a given portion or field of a protocol that has a length requirement (e.g., the length of the data transmitted in the given portion or field must be a certain number of octets), additional bits, such as a zero fill <b>490</b>, can be added subsequent to the last beacon message in the given portion or field such that the total length of the one or more beacon messages plus the additional bits equals a desirable length. These additional bits can carry meaningless information, and can simply be a string of “0” bits, for example.

Exemplary Advertising Types

0043<figref idref="DRAWINGS">FIGS. 5 and 6</figref> list a plurality of exemplary advertising types <b>448</b> for beacon messages <b>440</b>. The list <b>500</b> in <figref idref="DRAWINGS">FIG. 5</figref> comprises exemplary regular advertising types (i.e., advertising types that are not extended advertising types) and the list <b>600</b> in <figref idref="DRAWINGS">FIG. 6</figref> comprises exemplary extended advertising types. As indicated, some advertising types are associated with no typed payload <b>450</b>, while other advertising types are associated with fixed length or variable length typed payloads. It can be desirable for the advertising types most commonly used and/or those that are associated with lengthy typed payloads <b>450</b> to be regular advertising types, because beacon messages with extended advertising types are at least one octet longer (due to the extension type octet(s) <b>444</b>) than beacon messages with regular advertising types and have less space for the typed payload <b>450</b>.

0044The advertising type of a beacon message can be one of a set of predetermined advertising types. Each predetermined advertising type can be defined to indicate a specific message (e.g., command, suggestion, request, or other useful information) to a mobile computing device that receives the beacon message. Mobile computing devices can be pre-configured to know what idea each of the predetermined advertising types indicates. Thus, with a beacon message of just one octet in length (if the advertising type is associated with no typed payload), a beacon generation device can communicate to a receiving mobile computing device a whole variety of specific messages. The compact nature of such a beacon message, in addition to the fact the mobile computing device does not need to request the message or otherwise initiate communication with the beacon generation device, can reduce the energy cost associated with communicating the message, both for the advertiser and for the receiver. In many common scenarios, further energy savings can arise because the beacon message conveys to the receiving device sufficient information such that the receiving device can understand the beacon message and react to it without the need to further communicate with other external entities to obtain additional information (e.g., the “silence requested” beacon discussed below can convey all the information the receiving device needs to switch the device to silent mode without recourse to further external look-ups via radio or other wireless communication that would consume more energy).

0045An exemplary advertising type that is not associated with a typed payload is a “silence requested” advertising type in which the beacon message requests that any receiving mobile computing devices switch to silent mode. This advertising type can be used, for example, in a movie theater or in a classroom. In one example, a stationary beacon generation device can be mounted in a movie theater such that the range of the beacon transmission includes the whole theater but not the hallway areas outside of the theater. When any mobile computing devices that are configured to receive and understand the beacon message receive the beacon message (when they enter the theater), the mobile computing device can automatically understand that it should switch to silent mode. Depending on its settings, the mobile computing device can either automatically switch to silent mode without input from a user, or it can display a message to the user asking if the user would like to switch to silent mode.

0046Another exemplary advertising type that is not associated with a typed payload is a “flight mode requested” advertising type, such as for use in an airplane, in which the beacon message requests that any receiving mobile computing devices switch to a flight mode configuration, which can be mean, for example, that the antenna is turned off and/or the device is in silent mode. When any mobile computing devices that are configured to receive and understand the beacon message receive the beacon message (e.g., when they enter the airplane), the mobile computing device can automatically understand that it should switch to flight mode. Depending on its settings, the mobile computing device can either automatically switch to flight mode without input from a user, or it can display a message to the user asking if the user would like to switch to flight mode.

0047Another exemplary advertising type that is not associated with a typed payload is a “hands-free mode only” advertising type, such as for use in an automobile, in which the beacon message informs that any receiving mobile computing devices may be required to only operate in hands-free mode.

0048Other exemplary advertising types can be associated a variable or fixed length typed payload. One exemplary advertising type that is associated with a variable length typed payload is a “location” advertising type in which the beacon message informs receiving mobile computing devices of the geographic location of the beacon generation device and/or the receiving mobile computing device. The payload data for a beacon message of this “location” advertising type can comprise a string of bits that indicates the geographic location, such as WGS84 longitude and latitude. More bits can be used to indicate higher resolution locations, and fewer bits can be used to indicate lower resolution locations.

0049Another exemplary advertising type that is associated with a variable length typed payload is a “local time” advertising type in which the payload data of the beacon message contains local time information. Different sizes of payloads can be used depending on the time accuracy desired.

0050Some exemplary advertising types can be associated with beacon messages that contain a URL or other address information in the payload which a receiving mobile computing device can use to look up and retrieve location-based information from another location. In an exemplary advertising type “store coupons,” (example advertising type FF04 in <figref idref="DRAWINGS">FIG. 6</figref>), the beacon message can include URL information in its payload indicating a website from which store coupons can be retrieved. For example, a grocery store can have a beacon generation device located in or near the store that transmits these “store coupon” type beacon messages. Any mobile computing device near the store can receive the beacon messages and retrieve, or download, up-to-date coupons from the indicated website for use in the store. The length of the payload data indicating the URL in such a case can vary depending on the length of the URL.

0051Some exemplary advertising types that can be associated with beacon messages can contain information in the payload for use with an application (an “app”) for a mobile computing device. The example advertising type FF21 shown in <figref idref="DRAWINGS">FIG. 6</figref>, called “Festival Attendee Phone App Beacon”, is an example of such an advertising type. The payload of such a beacon message can comprise information that can be used by an app. For example, the payload can contain information regarding performances at a particular festival venue where the beacon generation device is located.

0052Some exemplary advertising types can be associated with beacon messages that request identifying information from the receiving mobile computing devices. For example, example advertising type FF<b>25</b> in <figref idref="DRAWINGS">FIG. 6</figref> can be used for security access. In one example, a beacon generation device located at a security access location (e.g., a parking garage gate, or an office entrance) and can transmit a beacon message that requests that any receiving mobile computing device respond with a security access code. In some cases, such a beacon message can have no payload and simply request security access information. In other cases, the beacon message can include a fixed length payload that contains identifying information specific to that particular security access location (a user might have access to some doors and not to others). The receiving mobile computing device can be configured to respond to the security access beacon message with a general security code, with information identifying the particular mobile computing device and/or with information identifying a user of the mobile computing device. Such a response by the receiving mobile computing device can be performed automatically in response to receiving the beacon message, or can be performed after receiving authorization from a user.

Exemplary Beacon Messages

0053<figref idref="DRAWINGS">FIG. 7</figref> shows an exemplary sentence <b>700</b> that comprises plural exemplary beacon messages and a zero fill <b>795</b> at the end. The sentence <b>700</b> can be formatted to be included in the AdvData field <b>434</b> of a PDU <b>416</b> of a BLE advertising packet <b>410</b> (see <figref idref="DRAWINGS">FIG. 4</figref>). This exemplary sentence <b>700</b> includes a group of beacon messages that can be generated and transmitted by the same beacon generation device and can include related messages that are associated with the location of the beacon generation device. In the particular example of the sentence <b>700</b>, the beacon messages are all related a particular building having a wheelchair accessible entrance and wherein mobile computing devices should be in silent mode.

0054The exemplary sentence <b>700</b> comprises a first beacon message “0102” wherein the first “0” indicated at <b>710</b> comprises the first bit <b>446</b> of a main type octet <b>442</b> and the following “02” indicated at <b>720</b> comprises the seven type bits <b>448</b> of the main type octet <b>442</b>. The fact that the first bit is a “0” indicates that the beacon message has no typed payload and that no subsequent type octets are present in the beacon message. Thus, this is a one-octet beacon message having a regular advertising type and no typed payload. The advertising type “02” corresponds to the example advertising type 2 shown in <figref idref="DRAWINGS">FIG. 5</figref>, which indicates to a receiving mobile computing device that silent mode should be used.

0055The second beacon message in the sentence <b>700</b> is “110111710476080812233689”. The first “1” indicated at <b>730</b> comprises the first bit <b>446</b> of a main type octet <b>442</b> and the following “01” indicated at <b>740</b> comprises the seven type bits <b>448</b> of the main type octet <b>442</b>. The fact that the first bit is a “1” indicates that a subsequent one or more octets of the beacon message comprise a typed payload for the beacon message. The advertising type “01” indicated at <b>740</b> corresponds to the example advertising type 1 shown in <figref idref="DRAWINGS">FIG. 5</figref>, which indicated to a receiving mobile computing device that the payload data comprises data indicating the geographic location of the beacon generation device (e.g., the WGS84 coordinates of the building where the beacon generation device is located). The “17” indicated at <b>750</b> comprises the 5-bit long payload length field <b>452</b> of the typed payload, and the “0476080812233689” indicated at <b>760</b> comprised the payload data of the beacon message (e.g., the WGS84 coordinates). The typed payload of this beacon message is 17 octets long, as indicated by the payload length field <b>750</b>, making the entire beacon message 18 octets long.

0056The third beacon message in the sentence <b>700</b> is “FF10103”. The “FF” indicated at <b>770</b> comprises an extension type octet <b>444</b>, which indicates that the advertising type of this beacon message is an extended advertising type. The “0” indicated at <b>780</b> comprises the first bit <b>446</b> of a main type octet <b>442</b> and the following “03” indicated at <b>790</b> comprises the seven type bits <b>448</b> of the main type octet <b>442</b>. The fact that the first bit is a “0” indicates that the beacon message has no typed payload and that no subsequent type octets are present in the beacon message. Thus, this is a two-octet beacon message having an extended advertising type entitled “FF03” and no typed payload. The advertising type “FF03” is not shown in <figref idref="DRAWINGS">FIG. 5</figref> or <b>6</b>, but indicates to a receiving mobile computing device that a wheelchair accessible entrance is present.

0057The three exemplary beacon messages included in the exemplary sentence <b>700</b> comprise a total of 21 octets. If, for example, these beacon messages are transmitted in wireless communication protocol field that requires a specific fixed length, then a zero fill <b>795</b> can be appended to the beacon messages to make the sentence <b>700</b> the desired total length.

Exemplary Actions in Response to Receiving a Beacon Message

0058After receiving a beacon message, a mobile computing device can be configured to perform one or more actions in response to the beacon message. Some exemplary responsive actions can be performed without any input from a user of the mobile computing device, while other exemplary responsive actions can require input from a user prior to being performed by the mobile computing device.

0059One exemplary action that a mobile computing device can perform in response to a received beacon message without input from a user is displaying a message to a user of the mobile computing device. Such a displayed message can depend on the advertising type of the beacon message. For example, in response to receiving a “silence requested” beacon message, the mobile computing device can be configured to display a message to the user indicating that silence is requested and/or asking the user for input as to whether or not the user would like to switch the mobile computing device to silent mode. Other exemplary displayed messages can comprise information associated with the location of the beacon generation device and/or the location of the receiving mobile computing device, such as the name of a building or the presence of a wheelchair accessible entrance.

0060Another exemplary action that a mobile computing device can perform in response to a received beacon message without input from a user is automatically adjusting a local setting of the receiving mobile computing device. Automatically switching to silent mode or flight mode are examples of this type of action.

0061In some examples, a mobile computing device can be configured to receive a beacon message in sleep mode and process the beacon message in firmware without awaking from sleep mode. As used herein, the term “sleep mode” can mean any conventional low power consumption mode, such as a sleep mode, standby mode, suspend mode, or other similar mode wherein the mobile computing device attempts to conserve power by turning off the display screen, antenna, hard drive and/or other functions that are not necessary, and from which the mobile computing device can switch to an active mode without having to boot up or reboot. As used herein, the term “firmware” means a fixed or semi-fixed program and/or data structure in a given hardware device that internally controls the given electronic hardware device, and without which the given hardware device would be non-functional. For example, a mobile computing device can be configured to receive a “silence requested” beacon messages while in sleep mode, and then switch the device to silent mode using firmware without the phone awaking from sleep mode. This can save significant battery life for mobile computing device. A majority of beacon messages that a mobile computing device receives can have advertising types that do not require any user input or a responsive communication by the mobile computing device. In these situations, a processor of the mobile computing device would significantly drain the battery of it acted in response to all received beacons. By configuring the mobile computing device to receive and process certain beacon signals in firmware, the processor need not act in response to these beacon messages, saving significant energy. A user can adjust the settings/preferences of the mobile computing device to decide which advertising types the device should automatically react to without awaking, which advertising types it should awaken in response to and react to, and/or which advertising types it should ignore.

0062Another exemplary action that a mobile computing device can perform in response to a received beacon message without input from a user is wirelessly transmitting data comprising information specific to the mobile computing device or specific to a user/owner of the mobile computing device. For example, in response to a “security access” beacon message, the mobile computing device can transmit data comprising information identifying the mobile computing device and/or a user or owner of the mobile computing device. Such data can be transmitted back to the beacon generation device and/or to another computing device at a remote location, such as a security access terminal located in another building, in order to gain access to a secured area. In some examples, the date transmitted by the mobile computing device in response to such a beacon message can further comprise at least a portion of the beacon message itself, such data identifying the beacon generation device that is located in the payload of the beacon message. Thus, a remote security access terminal can receive data indicating both what security access is requested and who/what is requesting such access. In some embodiments, all of this can be performed automatically by the mobile computing device without input from a user, and optionally using firmware while the mobile computing device remains in sleep mode.

Exemplary Devices

0063<figref idref="DRAWINGS">FIG. 8</figref> depicts a detailed example of a device <b>800</b>, such as a beacon generation device or a mobile computing device, capable of implementing the techniques and solutions described herein. The device <b>800</b> includes a variety of optional hardware and software components, shown generally at <b>802</b>. In general, a component <b>802</b> in the device <b>800</b> can communicate with any other component of the device, although not all connections are shown, for ease of illustration. The device <b>800</b> can be any of a variety of computing devices (e.g., cell phone, smartphone, handheld computer, laptop computer, notebook computer, tablet device, netbook, media player, Personal Digital Assistant (PDA), camera, video camera, etc.) and can allow wireless two-way communications with one or more communications networks <b>804</b>, such as a Wi-Fi, cellular, or satellite network.

0064The illustrated device <b>800</b> includes a controller or processor <b>810</b> (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system <b>812</b> controls the allocation and usage of the components <b>802</b> and support for one or more applications <b>814</b> such as software components that implement one or more of the innovative features described herein. In addition, the application programs can include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application.

0065The illustrated device <b>800</b> includes memory <b>820</b>. Memory <b>820</b> can include non-removable memory <b>822</b> and/or removable memory <b>824</b>. The non-removable memory <b>822</b> can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory <b>824</b> can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in Global System for Mobile Communications (GSM) communication systems, or other well-known memory storage technologies, such as “smart cards.” The memory <b>820</b> can be used for storing data and/or code for running the operating system <b>812</b> and the applications <b>814</b>. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. The memory <b>820</b> can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

0066The device <b>800</b> can support one or more input devices <b>830</b>, such as a touchscreen <b>832</b> (e.g., capable of capturing finger tap inputs, finger gesture inputs, or keystroke inputs for a virtual keyboard or keypad), microphone <b>834</b> (e.g., capable of capturing voice input), camera <b>836</b> (e.g., capable of capturing still pictures and/or video images), physical keyboard <b>838</b>), buttons and/or trackball <b>840</b> and one or more output devices <b>850</b>, such as a speaker <b>852</b> and a display <b>854</b> (e.g., with an associated graphics processing unit (GPU) <b>853</b>)). Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touchscreen <b>832</b> and display <b>854</b> can be combined in a single input/output device.

0067The device <b>800</b> can provide one or more natural user interfaces (NUIs). For example, the operating system <b>812</b> or applications <b>814</b> can comprise speech-recognition software as part of a voice user interface that allows a user to operate the device <b>800</b> via voice commands. For example, a user's voice commands can be used to provide input to a map navigation tool.

0068A wireless modem <b>860</b> can be coupled to one or more antennas (not shown) and can support two-way communications between the processor <b>810</b> and external devices, as is well understood in the art. The modem <b>860</b> is shown generically and can include, for example, a cellular modem for communicating at long range with the mobile communication network <b>804</b>, a Bluetooth-compatible modem <b>864</b> (such as a BLE—compatible modem), or a Wi-Fi-compatible modem <b>862</b> for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router. The wireless modem <b>860</b> is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the device <b>800</b> and a public switched telephone network (PSTN).

0069The device <b>800</b> can further include at least one input/output port <b>880</b>, a power supply <b>882</b>, a satellite navigation system receiver <b>884</b>, such as a Global Positioning System (GPS) receiver, sensors <b>886</b> such as an accelerometer, a gyroscope, or an infrared proximity sensor for detecting the orientation and motion of device <b>800</b>, and for receiving gesture commands as input, a transceiver <b>888</b> (for wirelessly transmitting analog or digital signals) and/or a physical connector <b>890</b>, which can be a USB port, IEEE 1394 (FireWire) port, and/or RS-232 port. The illustrated components <b>802</b> are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.

0070The device <b>800</b> can determine location data that indicates the location of the device based upon information received through the satellite navigation system receiver <b>884</b> (e.g., GPS receiver). Alternatively, the device <b>800</b> can determine location data that indicates location of the device in another way. For example, the location of the device can be determined by triangulation between cell towers of a cellular network. Or, the location of the device can be determined based upon the known locations of Wi-Fi routers in the vicinity of the device. The location data can be updated every second or on some other basis, depending on implementation and/or user settings. Regardless of the source of location data, the device <b>800</b> can provide the location data to a map navigation tool for use in map navigation. For example, the map navigation tool periodically requests, or polls for, current location data through an interface exposed by the operating system <b>812</b> (which in turn may get updated location data from another component of the device <b>800</b>), or the operating system <b>812</b> pushes updated location data through a callback mechanism to any application (such as the map navigation tool) that has registered for such updates.

0071The device <b>800</b> can implement the technologies described herein. For example, the Bluetooth-compatible modem <b>864</b> and/or the transceiver <b>888</b> can be used to send and/or receive beacon messages using BLE. The applications <b>814</b> can include various components configured to cause the device to perform various actions in response to a received beacon message, such as displaying a message on the display <b>854</b>, receiving input from a user with the input devices <b>830</b>, switching the device to a silent mode, or communicating with the network <b>804</b>. At least some of these actions can be performed using firmware.

0072The device <b>800</b> can be part of an implementation environment in which various types of services (e.g., computing services) are provided by a computing “cloud.” For example, the cloud can comprise a collection of computing devices, which may be located centrally or distributed, that provide cloud-based services to various types of users and devices connected via a network such as the Internet. Some tasks (e.g., processing user input and presenting a user interface) can be performed on local computing devices (e.g., connected devices) while other tasks (e.g., storage of data to be used in subsequent processing) can be performed in the cloud.

0073Although <figref idref="DRAWINGS">FIG. 8</figref> illustrates a device <b>800</b>, more generally, the techniques and solutions described herein can be implemented with devices having other screen capabilities and device form factors, such as a desktop computer, a television screen, or device connected to a television (e.g., a set-top box or gaming console). Services can be provided by the cloud through service providers or through other providers of online services. Thus, the techniques and solutions described herein can be implemented with any of the connected devices as a client computing device. Similarly, any of various computing devices in the cloud or a service provider can perform the role of server computing device and deliver data to the connected devices.

Alternatives and Variations

0074Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

0075Any of the disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media (e.g., non-transitory computer-readable media, such as one or more optical media discs such as DVD or CD, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as hard drives)) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable media (e.g., non-transitory computer-readable media). The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.

0076For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.

0077The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and non-obvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub-combinations with one another. The disclosed methods, devices, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved. In view of the many possible embodiments to which the principles of the disclosed invention may be applied, it should be recognized that the illustrated embodiments are only preferred examples of the invention and should not be taken as limiting the scope of the invention. Rather, the scope of the invention is defined by the following claims. We therefore claim as our invention all that comes within the scope of these claims.