(57)【特許請求の範囲】
【請求項１】
ビーコンメッセージを送信する方法であって、
ビーコン生成デバイスで、少なくとも１つのビーコンメッセージを生成するステップであり、前記少なくとも１つのビーコンメッセージは、ビーコンメッセージフォーマットにより規定され、前記ビーコンメッセージフォーマットは、１つ以上のタイプオクテットを有し、前記１つ以上のタイプオクテットは、第１ビットに続いて7個のタイプビットを有する主タイプオクテットを有し、前記7個のタイプビットは、前記ビーコンメッセージのアドバタイジングタイプを示し、前記アドバタイジングタイプは、前記ビーコン生成デバイスの位置に関連する位置ベースの情報を示す一式の所定のアドバタイジングタイプのうち１つであり、前記第１ビットは、前記ビーコンメッセージがタイプペイロードを有さず、以降のタイプオクテットが前記ビーコンメッセージに存在しないことを示す“0”であるか、前記ビーコンメッセージの以降の１つ以上のオクテットが前記ビーコンメッセージのタイプペイロードを有することを示す“1”であり、前記タイプペイロードは、ペイロード長フィールドに続いてペイロードデータフィールドを有し、前記ペイロード長フィールドは、前記タイプペイロードのオクテット単位の長さであるステップと、
前記ビーコン生成デバイスで、送信エリア内に位置する１つ以上のモバイルコンピュータデバイスによる受信のため、低エネルギー無線通信プロトコルを使用して、前記ビーコン生成デバイスの送信範囲内の送信エリアに前記少なくとも１つのビーコンメッセージを送信するステップと、
を有する方法。
【請求項２】
前記第１ビットは、“1”であり、前記ビーコンメッセージは、タイプペイロードを有し、前記タイプペイロードは、ペイロード長フィールドに続いてペイロードデータフィールドを有し、前記ペイロード長フィールドは、前記タイプペイロードのオクテット単位の長さを示す5ビットまでを有する、請求項１に記載の方法。
【請求項３】
前記ビーコンメッセージは、前記主タイプオクテットの前に拡張タイプオクテットを有し、前記拡張タイプオクテットは、前記アドバタイジングタイプが拡張アドバタイジングタイプであることを示す、請求項１又は２に記載の方法。
【請求項４】
前記少なくとも１つのビーコンメッセージは、Bluetooth  Low  Energyアドバタイジングチャネルのパケットのプロトコルデータユニット（PDU）のペイロードのAdvDataフィールドで送信される、請求項１ないし３のうちいずれか１項に記載の方法。
【請求項５】
ビーコンメッセージを受信する方法であって、
モバイルコンピュータデバイスで、低エネルギー無線通信プロトコルで送信されたビーコンメッセージを受信するステップであり、前記少なくとも１つのビーコンメッセージは、ビーコンメッセージフォーマットにより規定され、前記ビーコンメッセージフォーマットは、１つ以上のタイプオクテットを有し、前記１つ以上のタイプオクテットは、第１ビットに続いて7個のタイプビットを有する主タイプオクテットを有し、前記7個のタイプビットは、前記ビーコンメッセージのアドバタイジングタイプを示し、前記アドバタイジングタイプは、前記モバイルコンピュータデバイスの位置に関連する位置ベースの情報を示す一式の所定のアドバタイジングタイプのうち１つであり、前記第１ビットは、前記ビーコンメッセージがタイプペイロードを有さず、以降のタイプオクテットが前記ビーコンメッセージに存在しないことを示す“0”であるか、前記ビーコンメッセージの以降の１つ以上のオクテットが前記ビーコンメッセージのタイプペイロードを有することを示す“1”であり、前記タイプペイロードは、ペイロード長に続いてペイロードデータを有し、前記ペイロード長は、前記タイプペイロードのオクテット単位の長さであるステップと、
ユーザからの入力なしに前記位置ベースの情報に少なくとも部分的に基づいて少なくとも１つの動作を実行するステップと
を有する方法。
【請求項６】
前記少なくとも１つのビーコンメッセージは、Bluetooth  Low  Energyアドバタイジングチャネルのパケットのプロトコルデータユニット（PDU）のペイロードのAdvData部分に含まれる、請求項５に記載の方法。
【請求項７】
前記モバイルコンピュータデバイスは、スリープモードで前記ビーコンメッセージを受信し、スリープモードから起動せずにファームウェアで前記ビーコンメッセージを処理するように構成される、請求項５又は６に記載の方法。
【請求項８】
少なくとも１つの動作を実行するステップは、
前記受信したビーコンメッセージに応じて、前記ビーコンメッセージの少なくとも一部を他のコンピュータデバイスに無線で転送することを有する、請求項５ないし７のうちいずれか１項に記載の方法。
【請求項９】
前記モバイルコンピュータデバイスは、前記位置ベースの情報に基づいて、ユーザからの入力なしに前記モバイルコンピュータデバイスのローカル設定を調整するように構成される、請求項５ないし８のうちいずれか１項に記載の方法。
【請求項１０】
モバイルコンピュータデバイスがビーコン生成デバイスの送信範囲内にいるときに、ビーコン生成デバイスからBluetooth  Low  Energyプロトコルを介して送信された無向のビーコンメッセージを受信して処理するように構成されたモバイルコンピュータデバイスであって、
前記ビーコンメッセージは、Bluetooth  Low  Energyアドバタイジングチャネルのパケットのプロトコルデータユニット（PDU）のペイロードのAdvData部分に含まれ、前記ビーコンメッセージは、ビーコンメッセージフォーマットにより規定され、
前記ビーコンメッセージフォーマットは、１つ以上のタイプオクテットを有し、前記１つ以上のタイプオクテットは、主タイプオクテットを有し、前記主タイプオクテットは、第１ビットに続いて7個のタイプビットを有し、前記7個のタイプビットは、前記ビーコンメッセージのアドバタイジングタイプを示し、前記アドバタイジングタイプは、前記ビーコン生成デバイスの位置に関連する位置ベースの情報を示す一式の所定のアドバタイジングタイプのうち１つであり、前記第１ビットは、前記ビーコンメッセージがタイプペイロードを有さず、前記主タイプオクテットが前記ビーコンメッセージの最後のオクテットであることを示す“0”であるか、前記ビーコンメッセージの前記主タイプオクテットに続いて次の１つ以上のオクテットが前記ビーコンメッセージのタイプペイロードを有することを示す“1”であり、前記タイプペイロードは、ペイロード長に続いてペイロードデータを有し、前記ペイロード長は、前記タイプペイロードのオクテット単位の長さであり、
前記モバイルコンピュータデバイスは、前記一式の所定のアドバタイジングタイプのうち少なくとも１つのアドバタイジングタイプについて、スリープモードから起動せずにファームウェアで前記ビーコンメッセージを受信して処理するように構成されるモバイルコンピュータデバイス。
【発明の詳細な説明】
【背景技術】
【０００１】
ユーザにより使用されていない場合であっても、典型的には、モバイルコンピュータデバイスは、時間の更新、モバイルコンピュータデバイスの位置の判定又は信号強度の検査のように、様々な目的のデータを送信及び受信するために、定期的にセルラネットワークと通信する。これらの通信は、ネットワークにメッセージを送信し、何らかの形式の応答を受信することで、モバイルコンピュータデバイスによりしばしば開始される。これらの動作は、かなりの量のエネルギーを使用し、モバイルコンピュータデバイスの電池寿命を低減する可能性がある。
【０００２】
比較的短い距離で他のモバイルデバイスと通信するために、Bluetooth（登録商標）無線技術がますます普及してきており、衛星及びセルタワーのような遠隔デバイスのネットワークを通じて通信をルーティングする必要なく、モバイルコンピュータデバイスが他の近くのデバイスと無線で通信することを可能にしている。
【発明の概要】
【課題を解決するための手段】
【０００３】
この概要は、詳細な説明において以下に更に説明する概念の抜粋を簡単な形式で紹介するために提供される。この概要は、特許請求の範囲の主な特徴又は必須の特徴を特定することを意図するものではなく、特許請求の範囲を限定するために使用されることを意図するものでもない。
【０００４】
Bluetooth  Low  Energyプロトコルのような無線通信プロトコルを使用して、ビーコンメッセージを送信する技術及びツールが記載される。いくつかの例では、ビーコンメッセージは、コンパクトなフォーマットで生成され、Bluetooth  Low  Energyアドバタイジングチャネルのパケットのプロトコルデータユニット（PDU：Protocol  data  unit）のペイロードのAdvData部分に含まれてもよい。ビーコン生成デバイス及びモバイルコンピュータデバイスによる最小のエネルギー使用を必要としつつ、ビーコンメッセージは、静止したビーコン生成デバイスから送信され、ビーコン生成デバイスの送信範囲内のエリアにブロードキャストされてもよく、携帯電話のようなモバイルコンピュータデバイスは、ビーコンメッセージを受信し、ビーコンメッセージに含まれる情報に応じて１つ以上の動作を実行してもよい。
【０００５】
ビーコンメッセージは、１つ以上のタイプオクテット（type  octet）に続いて、必要に応じてタイプペイロード（typed  payload）を含んでもよいコンパクトなビーコンメッセージフォーマットにフォーマットされてもよい。１つ以上のタイプオクテットは、ビーコンメッセージのアドバタイジングタイプを示すデータを有してもよい。タイプペイロードは、更なるデータを含んでもよい。ビーコンメッセージに含まれるデータは、モバイルコンピュータデバイスがビーコン生成デバイスのエリア内でサイレントモード（マナーモード）又はフライトモードに切り替えるための要求のように、ビーコン生成デバイスの位置に特有のものでもよい。
【０００６】
いくつかの例では、モバイルコンピュータデバイスは、エネルギーを節約するために、スリープモードでビーコンメッセージを受信し、スリープモードから起動せずにビーコンメッセージを処理してもよい。いくつかの例では、モバイルコンピュータデバイスは、ビーコンメッセージに応じてユーザにメッセージを表示してもよい。いくつかの例では、ビーコンメッセージは、セキュリティアクセスの取得等のために、モバイルコンピュータデバイスが識別情報で応答するための要求を有してもよい。いくつかの例では、ビーコンメッセージは、モバイルコンピュータデバイスが更なる情報を取得することができるURL又は他のアドレスを含んでもよい。
【図面の簡単な説明】
【０００７】
【図１】例示的なビーコン生成デバイスの例示的な送信範囲内の例示的なモバイルコンピュータデバイスを示す図
【図２】ビーコンメッセージを送信する例示的な方法を示すブロック図
【図３】ビーコンメッセージを受信する例示的な方法を示すブロック図
【図４】ビーコンメッセージの例示的なフォーマットを示すブロック図
【図５】例示的なアドバタイジングタイプを記述する図
【図６】例示的な拡張アドバタイジングタイプを記述する図
【図７】例示的なビーコンメッセージを示す図
【図８】ここに記載の技術及びツールが実装され得る例示的なモバイルコンピュータデバイスを示すブロック図
【発明を実施するための形態】
【０００８】
本発明の前述及び他の目的、特徴及び利点は、添付図面を参照することで、以下の詳細な説明から明らかになる。
【０００９】
以下の説明は、無線通信プロトコル（例えば、低エネルギー無線通信プロトコル）を使用してビーコンメッセージを送信する技術及び対策を対象とする。例えば、コンパクトなビーコンメッセージは、Bluetooth  Low  Energy無線通信プロトコルを使用してビーコン生成デバイスから１つ以上のモバイルコンピュータデバイスに送信されてもよい。しかし、ここに記載の技術及び対策は、ビーコンメッセージが比較的短い範囲で１つのデバイスから１つ以上の他のデバイスに無線で送信される多くの種類のシステムに適用可能である。
【００１０】
ここに記載の技術及び対策はまた、低エネルギープロトコルとして分類されない可能性がある無線通信プロトコルにも適用可能である。例えば、ここに記載の技術及び対策は、Wi-Fi（登録商標）のような他の無線通信プロトコルを使用したビーコンメッセージの送信にも適用可能である（例えば、Wi-Fiプロトコルのビーコンフレーム内でビーコンメッセージを送信することによる）。
【００１１】
ここに記載の技術及び対策では、ビーコンメッセージは、送信デバイスの範囲内のエリアに送信デバイスから繰り返し又は絶えず送信又はブロードキャストされ、そのエリア内に位置するいずれか適切に構成された受信デバイスにより受信されるメッセージを示し、送信デバイスに関連する何らかの情報又は送信デバイスの位置を伝達する。ビーコンメッセージは、Bluetooth  Low  Energyのようないくつかのプロトコルによりアドバタイジングメッセージとも呼ばれる。
【００１２】
＜Bluetooth  Low  Energy＞
Bluetooth  Low  Energy（BLE）は、ここに記載するビーコンメッセージを低エネルギーコストで送信するために使用され得る例示的な無線通信プロトコルである。BLE仕様（“BLE  Specification”）は、2010年6月30日に公開されたBluetooth  Specification  Version  4.0のVolume  6に規定されている。BLEシステムは、2400〜2483.5MHzの2.4GHz  ISM帯において短波長の無線送信を使用し、2MHz幅の40個のRFチャネルを使用する。BLEは、周波数ホッピングスペクトラム拡散と呼ばれる無線技術を使用してもよい。これは、送信されているデータを細分し、異なるチャネルを通じてそのチャンク（chunk）を送信する。BLE送信は、用途に応じて、約50m、約1Mb/sの無線（over-the-air）データレート、及びClassis  Bluetoothのものの約1%〜約50&の電力消費のような可変の範囲を有してもよい。
【００１３】
BLEは、アドバタイジング状態を含む複数のリンクレイヤ状態を有する。アドバタイジング状態のリンクレイヤは、アドバタイジングチャネルのパケットを送信することができ、任意選択でこれらのアドバタイジングチャネルのパケットにより起動された応答を受信して応答することができる。アドバタイジング状態のBLEデバイスは、アドバタイザ（advertiser）として知られている。
【００１４】
BLEでは、40個のRFチャネルが２つの物理チャネル（アドバタイジングチャネル及びデータチャネル）に割り当てられる。アドバタイジング物理チャネルは、デバイスの発見、接続の開始及びデータのブロードキャストのために3つのRFチャネルを使用する。データ物理チャネルは、接続されたデバイスの間での通信のために、37個までのRFチャネルを使用する。リンクレイヤは、所与の時点で１つの物理チャネルを使用する。
【００１５】
BLEリンクレイヤは、アドバタイジングチャネルのパケット及びデータチャネルのパケットの双方に使用される１つのみのパケットフォーマットを有する。パケットフォーマットは、図４において410で示されている。各パケットは、4個のフィールド（プリアンブル412、アクセスアドレス414、プロトコルデータユニット（PDU：protocol  data  unit）416及び巡回冗長検査（CRC：cyclic  redundancy  check）418）で構成される。パケットがアドバタイジング物理チャネルで送信される場合、PDUは、アドバタイジングチャネルPDUと呼ばれ、パケットがデータ物理チャネルで送信される場合、PDUは、データチャネルPDUと呼ばれる。
【００１６】
アドバタイジングチャネルPDU416は、16ビットのヘッダ420と、可変サイズのペイロード430とを有する。ヘッダ420に含まれるアドバタイジングチャネルPDUのPDUタイプフィールド421は、PDUタイプを示す。現在では7個のPDUタイプが存在し、これらのうちいくつかについて以下に説明する。長さフィールド425は、オクテット単位のペイロード430の長さを示す。長さフィールド425の有効範囲は6〜37オクテットである。RFUフィールド422、TxAddフィールド423、RxAddフィールド424及びRFUフィールド426は、ここでは説明しない。
【００１７】
指定のイベントにおいて以下のアドバタイジングチャネルPDUタイプが使用される。
・ADV_IND：接続可能な無向（undirected）のアドバタイジングイベントで使用される。
・ADV_DIRECT_IND：接続可能な有向（directed）のアドバタイジングイベントで使用される。
・ADV_NONCONN_IND：接続不可能な無向のアドバタイジングイベントで使用される。
・ADV_SCAN_IND：スキャン可能な無向のアドバタイジングイベントで使用される。
これらのPDUタイプは、アドバタイジング状態においてリンクレイヤにより送信される。
【００１８】
PDUタイプADV_IND、ADV_NONCONN_IND及びADV_SCAN_INDは、それぞれ“無向”のアドバタイジングイベントで使用され、これは、送信が不特定の受信機にブロードキャストされ、送信デバイスの送信範囲内のいずれか適切に構成されたデバイスにより受信可能であることを意味する。ADV_INDタイプは、１つ以上の受信デバイスと接続を確立するために使用されてもよいが、ADV_NONCONN_INDタイプは、１つ以上の受信デバイスへの接続不可能な通信又は一方向の通信に使用されてもよく、ADV_SCAN_INDは、アドバタイジングイベントをスキャンする場合に使用されてもよい。
【００１９】
全ての３つのPDUタイプADV_IND、ADV_NONCONN_IND及びADV_SCAN_INDのペイロード430は同じである。ペイロード430は、AdvAフィールド432とAdvDataフィールド434とで構成される。AdvAフィールド432は、アドバタイザのパブリック又はランダムのデバイスアドレスのための6オクテットを含む。AdvDataフィールド434は、アドバタイザのホストからの0〜31オクテットのアドバタイジングデータを含む。AdvDataフィールド434のオクテット0及び1は、製造者データに確保され、アドバタイジングデータにオクテット2〜31を残してもよい。しかし、このような製造者データが必要ない場合、全てのオクテット0〜31はアドバタイジングデータに使用されてもよい。
【００２０】
＜例示的なビーコンシステム＞
図１は、例示的なビーコンシステム100を示す図である。システムは、BLEのような低エネルギー無線通信プロトコルを使用して少なくとも１つのビーコンメッセージを生成して送信するように構成された少なくとも１つのビーコン生成デバイス110を有してもよい。ビーコンメッセージは、ビーコン生成デバイス110からの指定の最大距離（例えば、約50m）のような送信範囲120を有してもよい。送信範囲120は、複数の要因に応じて変化してもよい。範囲120により規定されたエリア130内のいずれか適切に構成されたデバイスは、ビーコンメッセージを受信してもよい。システム100は、ビーコンメッセージをを受信するように構成されたエリア130内の１つ以上のモバイルコンピュータデバイス140を更に有してもよい。デバイス150のような範囲120の外に位置するデバイスは、ビーコン生成デバイス110からメッセージを受信しなくてもよい。例示的なビーコン生成デバイス及びモバイルコンピュータデバイスについて、“例示的なデバイス”という題の章で以下に詳細に説明する。
【００２１】
＜ビーコンメッセージを送信する例示的な方法＞
図２は、ビーコンメッセージを送信する例示的な方法200を示すブロック図である。210において、少なくとも１つのビーコンメッセージは、ビーコン生成デバイス（図１のデバイス110等）で生成されてもよい。生成されたビーコンメッセージは、ビーコンメッセージフォーマットにより規定されてもよい。220において、生成されたビーコンメッセージは、送信範囲内に位置する１つ以上のモバイルコンピュータデバイス（デバイス140等）による受信のために、ビーコン生成デバイスで低エネルギー無線通信プロトコルを使用して、ビーコン生成デバイスの送信範囲（範囲120等）内のエリア（エリア130等）に送信されてもよい。
【００２２】
＜ビーコンメッセージを受信する例示的な方法＞
図３は、ビーコンメッセージを受信する例示的な方法300を示すブロック図である。310において、少なくとも１つのビーコンメッセージは、モバイルコンピュータデバイス（図１のデバイス140等）で受信されてもよい。ビーコンメッセージは、低エネルギー無線通信プロトコルで送信されてもよい。320において、ビーコンメッセージを受信した場合、モバイルコンピュータデバイスの位置に関連する位置ベースの情報に少なくとも部分的に基づいて、少なくとも１つの動作がモバイルコンピュータデバイスにより実行されてもよい。この動作は、モバイルコンピュータデバイスのユーザからの入力なしに実行されてもよい。
【００２３】
＜例示的なビーコンメッセージフォーマット＞
ビーコンメッセージは、ビーコンメッセージが特定の低エネルギー無線通信プロトコルで送信可能なように、ビーコンメッセージフォーマットにより規定されてもよい。また、エネルギーを節約して各パケットにできるだけ多くのビーコンメッセージを含めるために、ビーコンメッセージフォーマットが最小のデータ量を必要とすることが望ましい。いくつかの例では、ビーコンメッセージフォーマットは、ビーコンメッセージの目的又はビーコンメッセージのタイプに応じて可変長又は可変サイズのビーコンメッセージを許容してもよい。例えば、或るビーコンメッセージは、数ビット又は1オクテットほどの短さでもよく、他のビーコンメッセージは、多くのオクテットを必要とする複雑なデータの送信等のために、使用されている通信プロトコルにより許容される最大サイズほどの長さでもよい。
【００２４】
いくつかの実施例では、低エネルギー無線通信プロトコルがBLEを有する場合、１つ以上のビーコンメッセージは、データチャネルのパケット410のPDU416のペイロード430のAdvDataフィールド434に含まれ得るようにフォーマットされてもよい（図４参照）。図４に示すように、AdvDataフィールド434は、0〜31オクテットのデータを含んでもよい。従って、AdvDataフィールド434のビーコンメッセージはまた、せいぜい31オクテットのデータを有さなければならず、さもなければ、異なるデータチャネルのパケット410で送信される複数のチャンクに分解されなければならない。しかし、より具体的には、複数のビーコンメッセージは、単一のデータチャネルのパケット410のAdvDataフィールド434に含まれてもよい。例えば、図４は、単一のAdvDataフィールド434に含まれる第１のビーコンメッセージ440及び第Nのビーコンメッセージ460（N個の合計のビーコンメッセージを示す）を示している。図４のビーコンメッセージ440及び460に例示されるビーコンメッセージフォーマットは、BLEでの使用に限定されず、その代わりに、Wi-Fiのような他の低エネルギー又は非低エネルギーの無線通信プロトコルで使用されてもよい。
【００２５】
図４に示すように、例示的なビーコンメッセージフォーマットは、第１ビット446に続いて7個のタイプビット448を有する主（メイン）タイプオクテットを少なくとも含む１つ以上のタイプオクテット442を有してもよい。更なるタイプオクテットも、拡張タイプオクテット444のようにいくつかのビーコンメッセージに含まれてもよい。ビーコンメッセージフォーマットは、必要に応じてタイプペイロード450を更に有してもよい。或るビーコンメッセージはタイプペイロードを含んでもよく、他のものはタイプペイロードを含まなくてもよい。タイプペイロード450は、ペイロード長452に続いてペイロードデータ454を有してもよい。
【００２６】
7個のタイプビット448は、ビーコンメッセージ440のアドバタイジングタイプを示してもよい。アドバタイジングタイプは、ビーコン生成デバイスの位置及び／又はビーコンメッセージを受信するモバイルコンピュータデバイスの位置に関連する位置ベースの情報を示す一式の所定のアドバタイジングタイプのうち１つでもよい。
【００２７】
第１ビット446は、“0”又は“1”でもよい。“0”である第１ビット446は、ビーコンメッセージがタイプペイロード450を有さず、以降のタイプオクテットがビーコンメッセージに存在しないことを示してもよい。“0”である第１ビット446は、主タイプオクテットが最後のタイプオクテットであり、主タイプオクテットがビーコンメッセージの終わりにあることを示してもよい。このようなビーコンメッセージでは、目的のメッセージに影響を及ぼすために必要な全ての情報は、7個のタイプビット448に含まれてもよく、及び／又は7個のタイプビット448により暗示されてもよい。
【００２８】
“1”である第１ビット446は、ビーコンメッセージの以降の１つ以上のオクテットがビーコンメッセージのタイプペイロードを有することを示してもよい。タイプペイロード450は、ペイロード長フィールド452に続いてペイロードデータフィールド454を有してもよい。ペイロード長フィールド452は、ペイロード長フィールド452自体を含むタイプペイロード450のオクテット単位の長さを有してもよい。ペイロード長フィールド452は、タイプペイロード450の第１オクテットの5ビット（例えば、0〜4ビット）を有してもよい。5ビットは、32オクテットまでのタイプペイロードの長さを示すのに十分になり得る。ビーコンメッセージがBLEのAdvDataに含まれる場合、タイプペイロード450は、せいぜい30オクテットに制限される。この場合、5ビットの長さのペイロード長フィールド452で十分になり得る。他の実施例では、ペイロード長フィールド452は、ビーコンメッセージが送信される無線通信プロトコルにより許容されるタイプペイロード450の最大サイズに応じて、5ビットより多くてもよく、少なくてもよい。ペイロード長フィールド452が5ビットの長さである場合に、ペイロードデータフィールド454が3ビット以下である場合、タイプペイロード450は、単一のオクテットに含まれてもよい。
【００２９】
いくつかのビーコンメッセージは、主タイプオクテットの第１ビット446の前に、拡張タイプオクテット（図４のオクテット444等）を有してもよい。拡張タイプオクテットは、ビーコンメッセージのアドバタイジングタイプが拡張アドバタイジングタイプであることを示してもよい。拡張タイプオクテット444は、ビーコンメッセージに存在する場合、ビーコンメッセージフォーマットに従って、主タイプオクテットが有することを許容されない8ビットの組み合わせを有してもよい。例えば、拡張タイプオクテット444は、存在する場合には常に“11111111”、“FF”又は他の所定のオクテットを有してもよく、主オクテットは、他の8ビットの組み合わせを有することが許容されてもよい。拡張タイプオクテットは、主タイプオクテットと重複しないため、これらは受信デバイスにより区別可能である。いくつかの例では、１つより多くの拡張タイプオクテット444が主タイプオクテットの前に含まれてもよい。拡張タイプオクテット444は、可能な所定のアドバタイジングタイプの総数が128（7個のタイプビット448により示されることができる異なるアドバタイジングタイプの量）を超えた場合、ビーコンメッセージに含まれてもよい。主タイプオクテットの前の各拡張タイプオクテット444は、タイプオクテット442により示されることができる異なるアドバタイジングタイプの数を２倍にするのに効果的になり得る。
【００３０】
１つ以上のビーコンメッセージが長さの要件を有するプロトコルの所与の部分又はフィールドで送信される場合（例えば、所与の部分又はフィールドで送信されるデータの長さが特定の数のオクテットでなければならない場合）、１つ以上のビーコンメッセージに更なるビットを加えた合計の長さが所望の長さと等しくなるように、更なるビット（ゼロの充填490等）が所与の部分又はフィールドの最後のビーコンメッセージに続いて追加されてもよい。これらの更なるビットは意味のない情報を伝達してもよく、例えば、単に“0”のビット列でもよい。
【００３１】
＜例示的なアドバタイジングタイプ＞
図５及び６は、ビーコンメッセージ440についての複数の例示的なアドバタイジングタイプ448のリストである。図５のリスト500は、例示的な通常のアドバタイジングタイプ（すなわち、拡張アドバタイジングタイプでないアドバタイジングタイプ）を有し、図６のリスト600は、例示的な拡張アドバタイジングタイプを有する。図示のように、或るアドバタイジングタイプは、タイプペイロード450のないものに関連し、他のアドバタイジングタイプは、固定長又は可変長のタイプペイロードに関連する。最も一般に使用されるアドバタイジングタイプ及び／又は長いタイプペイロード450に関連するものが通常のアドバタイジングタイプになることが望ましい。この理由は、拡張アドバタイジングタイプを有するビーコンメッセージは、通常のアドバタイジングタイプを有するビーコンメッセージより少なくとも１オクテット長く（拡張タイプオクテット444のため）、タイプペイロード450に少ない空間を有するからである。
【００３２】
ビーコンメッセージのアドバタイジングタイプは、一式の所定のアドバタイジングタイプのうち１つでもよい。それぞれの所定のアドバタイジングタイプは、ビーコンメッセージを受信するモバイルコンピュータデバイスに対して特定のメッセージ（例えば、コマンド、示唆、要求又は他の有用な情報）を示すように規定されてもよい。モバイルコンピュータデバイスは、所定のアドバタイジングタイプのそれぞれがどのような概念を示すかを認識するように予め構成されてもよい。従って、1オクテットのみの長さのビーコンメッセージで（アドバタイジングタイプがタイプペイロードのないものに関連する場合）、ビーコン生成デバイスは、様々な特定のメッセージを受信モバイルコンピュータデバイスに通信することができる。モバイルコンピュータデバイスがメッセージを要求する必要がないという事実又はビーコン生成デバイスとの通信を開始する必要がないという事実に加えて、このようなビーコンメッセージのコンパクトな性質は、アドバタイザと受信機との双方にとってメッセージを通信することに関連するエネルギーコストを低減することができる。多くの一般的なシナリオでは、受信デバイスがビーコンメッセージを理解し、更なる情報を取得するために他の外部エンティティと更に通信する必要なく反応できるように、ビーコンメッセージが十分な情報を受信デバイスに伝えるため、更なるエネルギー節約が生じてもよい（例えば、以下に説明する“サイレンス要求（silence  requested）”ビーコンは、多くのエネルギーを消費する無線通信又は他の無線通信を介して更なる外部の探索に頼らずに、受信デバイスがデバイスをサイレントモードに切り替えるために必要な全ての情報を伝えてもよい）。
【００３３】
タイプペイロードに関連しない例示的なアドバタイジングタイプは、いずれかの受信モバイルコンピュータデバイスがサイレントモードに切り替わることをビーコンメッセージが要求する“サイレンス要求”のアドバタイジングタイプである。このアドバタイジングタイプは、例えば、映画館又は教室で使用されてもよい。一例では、ビーコン送信の範囲が全体の映画館を含むが、映画館の外部の通路エリアを含まないように、静止したビーコン生成デバイスが映画館に取り付けられてもよい。ビーコンメッセージを受信して理解するように構成されたいずれかのモバイルコンピュータデバイスがビーコンメッセージを受信した場合（映画館に入った場合）、モバイルコンピュータデバイスは、サイレントモードに切り替わるべきであることを自動的に理解してもよい。この設定に応じて、モバイルコンピュータデバイスは、ユーザからの入力なしにサイレントモードに自動的に切り替わってもよく、ユーザがサイレントモードに切り替えたいか否かを求めるメッセージをユーザに表示してもよい。
【００３４】
タイプペイロードに関連しない他の例示的なアドバタイジングタイプは、飛行機内で使用されるもののような“フライトモード要求（flight  mode  requested）”のアドバタイジングタイプである。この場合、ビーコンメッセージは、いずれかのモバイルコンピュータデバイスがフライトモード構成に切り替わることを要求する。これは、例えば、アンテナがオフになること及び／又はデバイスがサイレントモードになることを意味してもよい。ビーコンメッセージを受信して理解するように構成されたいずれかのモバイルコンピュータデバイスがビーコンメッセージを受信した場合（飛行機に入った場合）、モバイルコンピュータデバイスは、フライトモードに切り替わるべきであることを自動的に理解してもよい。この設定に応じて、モバイルコンピュータデバイスは、ユーザからの入力なしにフライトモードに自動的に切り替わってもよく、ユーザがフライトモードに切り替えたいか否かを求めるメッセージをユーザに表示してもよい。
【００３５】
タイプペイロードに関連しない他の例示的なアドバタイジングタイプは、自動車内で使用されるもののような“ハンズフリーモードのみ（hands-free  mode  only）”のアドバタイジングタイプである。この場合、ビーコンメッセージは、いずれかの受信モバイルコンピュータデバイスがハンズフリーモードのみで動作することを求められ得ることを通知する。
【００３６】
他の例示的なアドバタイジングタイプは、可変長又は固定長のタイプペイロードに関連してもよい。可変長のタイプペイロードに関連する１つの例示的なアドバタイジングタイプは、ビーコンメッセージがビーコン生成デバイス及び／又は受信モバイルコンピュータデバイスの地理的位置を受信モバイルコンピュータデバイスに通知する“位置”のアドバタイジングタイプである。この“位置”のアドバタイジングタイプのビーコンメッセージのペイロードデータは、WGS84緯度及び軽度のような地理的位置を示すビット列を有してもよい。更に高い分解能の位置を示すために多くのビットが使用されてもよく、更に低い分解能の位置を示すために少ないビットが使用されてもよい。
【００３７】
可変長のタイプペイロードに関連する他の例示的なアドバタイジングタイプは、ビーコンメッセージのペイロードデータが現地時間情報を含む“現地時間”のアドバタイジングタイプである。所望の時間の精度に応じて異なるサイズのペイロードが使用されてもよい。
【００３８】
いくつかの例示的なアドバタイジングタイプは、受信モバイルコンピュータデバイスが他の位置から位置ベースの情報を探索して取得するために使用されてもよいURL又は他のアドレス情報をペイロードに含むビーコンメッセージに関連してもよい。例示的なアドバタイジングタイプである“ストアクーポン”（例えば、図６のアドバタイジングタイプFF04）では、ビーコンメッセージは、ストアクーポンが取得され得るウェブサイトを示すURL情報をそのペイロードに含んでもよい。例えば、食品雑貨店は、これらの“ストアクーポン”のタイプのビーコンメッセージを送信する店内又は店の近くに位置するビーコン生成デバイスを有してもよい。店の近くのいずれかのモバイルコンピュータデバイスは、ビーコンメッセージを取得し、店内で使用するために示されたウェブサイトから最新のクーポンを取得又はダウンロードしてもよい。このような場合、URLを示すペイロードデータの長さは、URLの長さに応じて変化してもよい。
【００３９】
ビーコンメッセージに関連し得るいくつかの例示的なアドバタイジングタイプは、モバイルコンピュータデバイスのアプリケーション（“app”）で使用する情報をペイロードに含んでもよい。“フェスティバル参加者の電話アプリケーションのビーコン”と呼ばれる図６に示す例示的なアドバタイジングタイプFF21は、このようなアドバタイジングタイプの例である。このようなビーコンメッセージのペイロードは、アプリケーションにより使用され得る情報を含んでもよい。例えば、ペイロードは、ビーコン生成デバイスが位置する特定のフェスティバル会場の演奏に関する情報を含んでもよい。
【００４０】
いくつかの例示的なアドバタイジングタイプは、受信モバイルコンピュータデバイスから識別情報を要求するビーコンメッセージに関連してもよい。例えば、図６の例示的なアドバタイジングタイプFF25は、セキュリティアクセスに使用されてもよい。一例では、セキュリティアクセス位置（例えば、駐車場のゲート又は会社の入り口）に位置するビーコン生成デバイスは、いずれかの受信モバイルコンピュータデバイスがセキュリティアクセスコードで応答することを要求するビーコンメッセージを送信してもよい。或る場合、このようなビーコンメッセージはペイロードを有さず、単にセキュリティアクセス情報を要求してもよい。他の場合、ビーコンメッセージは、その特定のセキュリティアクセス位置に特有の識別情報を含む固定長のペイロードを含んでもよい（ユーザは或るドアにアクセスしており、他のドアにアクセスしていない可能性がある）。受信モバイルコンピュータデバイスは、一般的なセキュリティコード、特定のモバイルコンピュータデバイスを識別する情報及び／又はモバイルコンピュータデバイスのユーザを識別する情報を用いて、セキュリティアクセスのビーコンメッセージに応答するように構成されてもよい。受信モバイルコンピュータデバイスによるこのような応答は、ビーコンメッセージの受信に応じて自動的に実行されてもよく、ユーザからの許可を受けた後に実行されてもよい。
【００４１】
＜例示的なビーコンメッセージ＞
図７は、複数の例示的なビーコンメッセージと終わりにゼロの充填795とを有する例示的なセンテンス700を示している。センテンス700は、BLEアドバタイジングパケット410のPDU416のAdvDataフィールド434に含まれるようにフォーマットされてもよい（図４参照）。この例示的なセンテンス700は、同じビーコン生成デバイスにより生成及び送信されてもよく、ビーコン生成デバイスの位置に関連する関係するメッセージを含んでもよいビーコンメッセージのグループを含む。センテンス700の特定の例では、ビーコンメッセージは、車椅子でアクセス可能な入口を有する特定のビルに全て関係しており、また、モバイルコンピュータデバイスはサイレントモードになるべきである。
【００４２】
例示的なセンテンス700は、第１のビーコンメッセージ“0｜02”を有する。710で示す最初の“0”は、主タイプオクテット442の第１ビット446を有し、720で示す次の“02”は、主タイプオクテット442の7個のタイプビット448を有する。第１ビットが“0”であるという事実は、ビーコンメッセージがタイプペイロードを有さず、次のタイプオクテットがビーコンメッセージに存在しないことを示す。従って、これは通常のアドバタイジングタイプを有し、タイプペイロードを有さない1オクテットのビーコンメッセージである。アドバタイジングタイプ“02”は、図５に示す例示的なアドバタイジングタイプ2に対応し、受信モバイルデバイスに対してサイレントモードが使用されるべきであることを示す。
【００４３】
センテンス700の第２のビーコンメッセージは、“1｜01｜17｜0476080812233689”である。730で示す最初の“1”は、主タイプオクテット442の第１ビット446を有し、740で示す次の“01”は、主タイプオクテット442の7個のタイプビット448を有する。第１ビットが“1”であるという事実は、ビーコンメッセージの以降の１つ以上のオクテットがビーコンメッセージについてタイプペイロードを有することを示す。740で示すアドバタイジングタイプ“01”は、図５に示す例示的なアドバタイジングタイプ1に対応し、受信モバイルコンピュータデバイスに対してペイロードデータがビーコン生成デバイスの地理的位置（例えば、ビーコン生成デバイスが位置するビルのWGS84座標）を示すデータを有することを示す。750で示す“17”は、タイプペイロードの5ビットの長さのペイロード長フィールド452を有し、760で示す“0476080812233689”は、ビーコンメッセージのペイロードデータ（例えば、WGS84座標）を有する。このビーコンメッセージのタイプペイロードは、ペイロード長フィールド750により示されるように17オクテットの長さであり、全体のビーコンメッセージを18オクテットの長さにする。
【００４４】
センテンス700の第３のビーコンメッセージは、“FF｜0｜03”である。770で示す“FF”は、拡張タイプオクテット444を有し、このビーコンメッセージのアドバタイジングタイプが拡張アドバタイジングタイプであることを示す。780で示す“0”は、主タイプオクテット442の第１ビット446を有し、790で示す次の“03”は、主タイプオクテット442の7個のタイプビット448を有する。第１ビットが“0”であるという事実は、ビーコンメッセージがタイプペイロードを有さず、次のタイプオクテットがビーコンメッセージに存在しないことを示す。従って、これは、“FF03”という拡張アドバタイジングタイプを有し、タイプペイロードを有さない2オクテットのビーコンメッセージである。アドバタイジングタイプ“FF03”は図５又は６に示されていないが、受信モバイルコンピュータデバイスに対して車椅子でアクセス可能な入り口が存在することを示す。
【００４５】
例示的なセンテンス700に含まれる３つの例示的なビーコンメッセージは、合計で21オクテットを有する。例えば、これらのビーコンメッセージが特定の固定長を必要とする無線通信プロトコルフィールドで送信される場合、センテンス700を所望の合計の長さにするためにゼロの充填795がビーコンメッセージに追加されてもよい。
【００４６】
＜ビーコンメッセージの受信に応じた例示的な動作＞
ビーコンメッセージを受信した後に、モバイルコンピュータデバイスは、ビーコンメッセージに応じて１つ以上の動作を実行するように構成されてもよい。或る例示的な応答動作は、モバイルコンピュータデバイスのユーザからの入力なしに実行されてもよく、他の例示的な応答動作は、モバイルコンピュータデバイスにより実行される前に、ユーザからの入力を必要としてもよい。
【００４７】
モバイルコンピュータデバイスがユーザからの入力なしに受信したビーコンメッセージに応じて実行し得る１つの例示的な動作は、モバイルコンピュータデバイスのユーザへのメッセージの表示である。このように表示されたメッセージは、ビーコンメッセージのアドバタイジングタイプに依存してもよい。例えば、“サイレンス要求”のビーコンメッセージの受信に応じて、モバイルコンピュータデバイスは、サイレンスが要求されていることを示すメッセージ及び／又はユーザがモバイルコンピュータデバイスをサイレントモードに切り替えたいか否かに関してユーザに入力を求めるメッセージをユーザに表示するように構成されてもよい。他の例示的な表示されるメッセージは、ビルの名前又は車椅子でアクセス可能な入り口の存在のような、ビーコン生成デバイスの位置及び／又は受信モバイルコンピュータデバイスの位置に関連する情報を有してもよい。
【００４８】
モバイルコンピュータデバイスがユーザからの入力なしに受信したビーコンメッセージに応じて実行し得る他の例示的な動作は、受信モバイルコンピュータデバイスのローカル設定の自動的な調整である。サイレントモード又はフライトモードへの自動的な切り替えは、この種類の動作の例である。
【００４９】
いくつかの例では、モバイルコンピュータデバイスは、スリープモードでビーコンメッセージを受信し、スリープモードから起動せずにファームウェアでビーコンメッセージを処理するように構成されてもよい。ここで使用される“スリープモード”という用語は、スリープモード、スタンバイモード、サスペンドモード、又は、モバイルコンピュータデバイスがディスプレイ画面、アンテナ、ハードドライブ及び／又は必要ない他の機能を電源オフにすることにより電力を節約することを試み、モバイルコンピュータデバイスがそこからブートアップ又はリブートの必要なしにアクティブモードに切り替わることができる他の同様なモードのように、いずれか従来の低電力消費モードを意味してもよい。ここで使用される“ファームウェア”という用語は、所与のハードウェアデバイスにおける固定又は半固定のプログラム及び／又はデータ構造を意味する。所与のハードウェアデバイスは、所与の電子ハードウェアデバイスを内部で制御し、それなしに所与のハードウェアデバイスが機能しないものである。例えば、モバイルコンピュータデバイスは、スリープモードの間に“サイレンス要求”のビーコンメッセージを受信し、電話がスリープモードから起動することなく、ファームウェアを使用してデバイスをサイレントモードに切り替えるように構成されてもよい。これは、モバイルコンピュータデバイスのかなりの電池寿命を節約し得る。モバイルコンピュータデバイスが受信するビーコンメッセージの多くは、ユーザ入力又はモバイルコンピュータデバイスによる応答通信を必要としないアドバタイジングタイプを有してもよい。これらの状況では、モバイルコンピュータデバイスのプロセッサは、全ての受信したビーコンに応じて動作した場合に電池をかなり消耗する。モバイルコンピュータデバイスがファームウェアで特定のビーコン信号を受信して処理するように構成することにより、プロセッサは、これらのビーコンメッセージに応じて動作する必要はなくなり、かなりのエネルギーを節約する。どのアドバタイジングタイプに対してデバイスが起動せずに自動的に反応するか、どのアドバタイジングタイプに対して起動して反応するか、及び／又はどのアドバタイジングタイプを無視するかを判定するために、ユーザは、モバイルコンピュータデバイスの設定／プレファレンスを調整してもよい。
【００５０】
モバイルコンピュータデバイスがユーザからの入力なしに受信したビーコンメッセージに応じて実行し得る他の例示的な動作は、モバイルコンピュータデバイスに特有の情報又はモバイルコンピュータデバイスのユーザ／所有者に特有の情報を有するデータの無線送信である。例えば、“セキュリティアクセス”のビーコンメッセージに応じて、モバイルコンピュータデバイスは、モバイルコンピュータデバイス及び／又はモバイルコンピュータデバイスのユーザ若しくは所有者を識別する情報を有するデータを送信してもよい。セキュリティのあるエリアへのアクセスを得るために、このようなデータは、ビーコン生成デバイス及び／又は遠隔位置の他のコンピュータデバイス（他のビル内に位置するセキュリティアクセス端末等）に返信されてもよい。いくつかの例では、このようなビーコンメッセージに応じてモバイルコンピュータデバイスにより送信されるデータは、ビーコンメッセージ自体の一部、ビーコンメッセージのペイロードに存在するビーコン生成デバイスを識別するようなデータを少なくとも更に有してもよい。従って、遠隔セキュリティアクセス端末は、どのセキュリティアクセスが要求されているか、及びだれ／何がこのようなアクセスを要求しているかを示すデータを受信してもよい。いくつかの実施例では、この全ては、ユーザからの入力なしにモバイルコンピュータデバイスにより自動的に実行されてもよく、任意選択で、モバイルコンピュータデバイスがスリープモードのままである間にファームウェアを使用して実行されてもよい。
【００５１】
＜例示的なデバイス＞
図８は、ここに記載の技術及び対策を実施することができるデバイス800（ビーコン生成デバイス又はモバイルコンピュータデバイス等）の詳細な例を示している。デバイス800は、概して802で示す様々な任意選択のハードウェア及びソフトウェアコンポーネントを含む。一般的に、デバイス800のコンポーネント802は、デバイスの他のコンポーネントと通信してもよいが、図示を容易にするために全ての接続が示されているとは限らない。デバイス800は、様々なコンピュータデバイス（例えば、携帯電話、スマートフォン、ハンドヘルドコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットデバイス、ネットブック、メディアプレイヤ、パーソナルデジタルアシスタント（PDA：Personal  Digital  Assistant）、カメラ、ビデオカメラ等）のいずれかでもよく、１つ以上の無線通信ネットワーク804（Wi-Fi、セルラ又は衛星ネットワーク等）と無線の双方向通信を可能にしてもよい。
【００５２】
図示のデバイス800は、信号符号化、データ処理、入出力処理、電力制御及び／又は他の機能のようなタスクを実行するために、コントローラ又はプロセッサ810（例えば、シグナルプロセッサ、マイクロプロセッサ、ASIC、又は他の制御及び処理論理回路）を含む。オペレーティングシステム812は、コンポーネント802の割り当て及び使用と、１つ以上のアプリケーション814（ここに記載の本発明の特徴のうち１つ以上を実施するソフトウェアコンポーネント等）のサポートとを制御する。更に、アプリケーションプログラムは、共通のモバイルコンピュータアプリケーション（例えば、電話アプリケーション、電子メールアプリケーション、カレンダー、連絡先マネージャ、ウェブブラウザ、メッセージングアプリケーション）又は他のコンピュータアプリケーションを含んでもよい。
【００５３】
図示のデバイス800は、メモリ820を含む。メモリ820は、取り外し不可能なメモリ822及び／又は取り外し可能なメモリ824を含んでもよい。取り外し不可能なメモリ822は、RAM、ROM、フラッシュメモリ、ハードディスク又は他の周知のメモリ記憶技術を含んでもよい。取り外し可能なメモリ824は、フラッシュメモリ若しくはGSM（Global  System  for  Mobile  Communications）通信システムで周知のSIM（Subscriber  Identity  Module）カード、又は“スマートカード”のような他の周知のメモリ記憶技術を含んでもよい。メモリ820は、オペレーティングシステム812及びアプリケーション814を実行するためのデータ及び／又はコードを格納するために使用されてもよい。例示的なデータは、１つ以上の有線又は無線ネットワークを介して１つ以上のネットワークサーバ又は他のデバイスに対して送信／受信されるウェブページ、テキスト、画像、音声ファイル、ビデオデータ又は他のデータセットを含んでもよい。メモリ820は、IMSI（International  Mobile  Subscriber  Identity）のような加入者識別子と、IMEI（International  Mobile  Equipment  Identifier）のような装置識別子とを格納するために使用されてもよい。このような識別子は、ユーザ及び装置を識別するためにネットワークサーバに送信されてもよい。
【００５４】
デバイス800は、１つ以上の入力デバイス830（タッチスクリーン832（例えば、指のタップ入力、指のジェスチャ入力又は仮想キーボード若しくはキーパッドのキーストローク入力を取得可能なもの）、マイクロフォン834（例えば、音声入力を取得可能なもの）、カメラ836（例えば、静止画及び／又はビデオ画像を取得可能なもの）、物理キーボード838、ボタン及び／又はトラックボール840等）と、１つ以上の出力デバイス850（スピーカ852及びディスプレイ854（例えば、関連するグラフィックス処理ユニット（GPU）853を備えたもの）等）とをサポートしてもよい。他の可能な出力デバイス（図示せず）は、圧電性又は他の触覚性の出力デバイスを含んでもよい。いくつかのデバイスは、１つより多くの入力／出力機能を提供してもよい。例えば、タッチスクリーン832及びディスプレイ854は、単一の入出力デバイスに結合されてもよい。
【００５５】
デバイス800は、１つ以上のナチュラルユーザインタフェース（NUI：natural  user  interface）を提供してもよい。例えば、オペレーティングシステム812又はアプリケーション814は、ユーザが音声コマンドを介してデバイス800を操作することを可能にする音声ユーザインタフェースの一部としての音声認識ソフトウェアを有してもよい。例えば、ユーザの音声コマンドは、地図ナビゲーションツールに入力を提供するために使用されてもよい。
【００５６】
無線媒体860は、１つ以上のアンテナ（図示せず）に結合されてもよく、当該技術分野において周知のように、プロセッサ810と外部デバイスとの間の双方向通信をサポートしてもよい。モデム860は、一般的に図示されており、例えば、モバイル通信ネットワーク804との長距離の通信のためのセルラモデム、外部のBluetooth搭載デバイス又はローカル無線データネットワーク若しくはルータと短距離で通信するためのBluetooth互換モデム864（BLE互換モデム等）又はWi-Fi互換モデム862を含んでもよい。無線モデム860は、典型的には、１つ以上のセルラネットワーク（単一のセルラネットワーク内、セルラネットワーク間又はデバイス800とPSTN（public  switched  telephone  network）との間でのデータ及び音声通信のためのGSMネットワーク等）と通信するように構成される。
【００５７】
デバイス800は、少なくとも１つの入出力ポート880、電源882、衛星ナビゲーションシステム受信機884（GPS（Global  Positioning  System）受信機等）、デバイス800の向き及び動きを検出し、入力としてジェスチャコマンドを受信するためのセンサ886（加速度計、ジャイロスコープ又は赤外線近接センサ等）、トランシーバ888（アナログ又はデジタル信号を無線で送信するためのもの）、及び／又は物理コネクタ890（USBポート、IEEE1394（FireWire）ポート及び／又はRS-232ポートでもよい）を更に含んでもよい。図示のコンポーネントのいずれかは削除されてもよく、他のコンポーネントが追加されてもよいため、図示のコンポーネント802は必ずしも必要ではなく、必ずしも包含されない。
【００５８】
デバイス800は、衛星ナビゲーションシステム受信機884（例えば、GPS受信機）を通じて受信した情報に基づいて、デバイスの位置を示す位置データを判定してもよい。或いは、デバイスは、他の方法でデバイスの位置を示す位置データを判定してもよい。例えば、デバイスの位置は、セルラネットワークのセルタワーの間の三角測量により判定されてもよい。或いは、デバイスの位置は、デバイスの近くのWi-Fiルータの既知の位置に基づいて判定されてもよい。位置データは、実装及び／又はユーザ設定に応じて、毎秒又は他のものに基づいて更新されてもよい。位置データのソースに拘わらず、デバイス800は、地図ナビゲーションで使用するために位置データを地図ナビゲーションツールに提供してもよい。例えば、地図ナビゲーションツールは、オペレーティングシステム812により作用されるインタフェースを通じて現在の位置データを定期的に要求又はポーリングしてもよく（次に、オペレーティングシステム812は、デバイス800の他のコンポーネントから更新された位置データを取得してもよい）、オペレーティングシステム812は、このような更新について登録したいずれかのアプリケーション（地図ナビゲーションツール等）へのコールバック機構を通じて更新された位置データをプッシュしてもよい。
【００５９】
デバイス800は、ここに記載の技術を実施してもよい。例えば、Bluetooth互換モデム864及び／又はトランシーバ888は、BLEを使用したビーコンメッセージを送信及び／又は受信するために使用されてもよい。アプリケーション814は、デバイスに対して受信したビーコンメッセージに応じて様々な動作（ディスプレイ854へのメッセージの表示、入力デバイス830を用いたユーザからの入力の受信、サイレントモードへのデバイスの切り替え、又はネットワーク804との通信等）を実行させるように構成された様々なコンポーネントを含んでもよい。これらの動作のうち少なくともいくつかはファームウェアを使用して実行されてもよい。
【００６０】
デバイス800は、様々な種類のサービス（例えば、コンピュータサービス）がコンピュータ“クラウド”により提供される実施環境の一部でもよい。例えば、クラウドは、インターネットのようなネットワークを介して接続された様々なユーザ及びデバイスに対してクラウドに基づくサービスを提供する、集中的又は分散して配置されてもよいコンピュータデバイスの集合を有してもよい。或るタスク（例えば、ユーザ入力の処理及びユーザインタフェースの提示）は、ローカルコンピュータデバイス（例えば、接続されたデバイス）で実行されてもよく、他のタスク（例えば、以降の処理で使用されるデータの格納）は、クラウドで実行されてもよい。
【００６１】
図８はデバイス800を示しているが、より一般的には、ここに記載の技術及び対策は、他の映写機能及びデバイス形状を有するデバイス（デスクトップコンピュータ、テレビ画面又はテレビに接続されたデバイス（例えば、セットトップボックス又はゲームコンソール）等）で実施されてもよい。サービスは、サービスプロバイダ又はオンラインサービスの他のプロバイダを通じてクラウドにより提供されてもよい。従って、ここに記載の技術及び対策は、クライアントコンピュータデバイスとしての接続されたデバイスのいずれかで実施されてもよい。同様に、クラウド又はサービスプロバイダの様々なコンピュータデバイスのいずれかは、サーバコンピュータデバイスの役目を実行し、データを接続されたデバイスに配信してもよい。
【００６２】
＜別法及び変形＞
開示の方法のいくつかの動作について便宜上の提示のために特定の順序で説明したが、特定の順序が以下に示す特定の言語により要求されない限り、この記載の方法は、再配置を含むことが分かる。例えば、順に記載した動作は、或る場合には再配置されてもよく、同時に実行されてもよい。更に、簡潔にするために、添付図面は、開示の方法が他の方法と共に使用され得る様々な方法を示さないことがある。
【００６３】
開示の方法のいずれかは、１つ以上のコンピュータ読み取り可能な記憶媒体に格納されたコンピュータ実行可能命令又はコンピュータプログラムプロダクト（例えば、１つ以上の光メディアディスク（DVD又はCD等）、揮発性メモリコンポーネント（DRAM又はSRAM等）、又は不揮発性メモリコンポーネント（ハードドライブ等）のような過渡的でないコンピュータ読み取り可能な媒体）として実装され、コンピュータ（例えば、スマートフォン又はコンピュータハードウェアを含む他のモバイルデバイスを含むいずれか商用利用可能なコンピュータ）で実行されてもよい。開示の技術を実装するコンピュータ実行可能命令のいずれかと、開示の実施例の実施中に生成されて使用されるいずれかのデータとは、１つ以上のコンピュータ読み取り可能な媒体（例えば、過渡的でないコンピュータ読み取り可能な媒体）に格納されてもよい。コンピュータ実行可能命令は、例えば、専用ソフトウェアアプリケーションの一部でもよく、ウェブブラウザを介してアクセス又はダウンロードされるソフトウェアアプリケーションの一部でもよく、他のソフトウェアアプリケーション（遠隔コンピュータアプリケーション等）の一部でもよい。このようなソフトウェアは、例えば、単一のローカルコンピュータ（例えば、いずれか適切な商用利用可能なコンピュータ）で実行されてもよく、１つ以上のネットワークコンピュータを使用してネットワーク環境（例えば、インターネット、広域ネットワーク、ローカルエリアネットワーク、クライアントサーバネットワーク（クラウドコンピュータネットワーク等）、又は他のこのようなネットワーク）で実行されてもよい。
【００６４】
明瞭にするために、ソフトウェアに基づく実装の特定の選択された態様のみが記載されている。当該技術分野において周知の他の詳細は省略されている。例えば、開示の技術は、いずれか特定のコンピュータ言語又はプログラムに限定されないことが分かる。例えば、開示の技術は、C++、Java（登録商標）、Perl、JavaScript（登録商標）、Adobe  Flash又は他の適切なプログラミング言語で記述されたソフトウェアにより実施されてもよい。同様に、開示の技術は、いずれかの特定のコンピュータ又はハードウェアの種類に限定されない。適切なコンピュータ又はハードウェアの特定の詳細は周知であり、この開示で詳細に示される必要はない。
【００６５】
開示の方法、装置及びシステムは、決して限定として解釈されるべきではない。その代わりに、この開示は、単独での及び様々な相互の組み合わせ及びサブコンビネーションでの、様々な開示の実施例の全ての新規な自明でない特徴及び態様を対象とする。開示の方法、デバイス及びシステムは、いずれか特定の態様若しくは特徴又はこれらの組み合わせに限定されず、また、開示の実施例は、１つ以上の特定の利点が存在すること又は問題が解決されることを要求しない。開示の発明の原理が適用され得る多くの可能な実施例を鑑みて、示された実施例は単に本発明の好ましい例に過ぎず、本発明の範囲を限定するものとして受け取られるべきでないことが分かる。むしろ、本発明の範囲は以下の特許請求の範囲により規定される。従って、本発明はこれらの特許請求の範囲内にある全てを請求する。
【図１】
0005964430.tif 000002
【図２】
0005964430.tif 000003
【図３】
0005964430.tif 000004
【図４】
0005964430.tif 000005
【図５】
0005964430.tif 000006
【図６】
0005964430.tif 000007
【図７】
0005964430.tif 000008
【図８】
0005964430.tif 000009