JP2020503766A - マイクロロケーションセンサ通信のためのシステムおよび方法 - Google Patents

Abstract

ブルートゥースローエナジーベースのマイクロロケーションシステムにおいて、センサ（例えば、センサ、ハブ、センサコントローラ、など）の間で、無線で同期、監視、または通信、あるいはそれらの組み合わせを行うためのシステムおよび方法である。システムまたは方法、あるいはその両方は、デバイスと通信するために使用されるＢＬＥプロトコルの接続間隔ギャップ内に通信プロトコルを割り込ませるためにＢＬＥハードウェア（例えば、送信機、受信機、アンテナ、など）を使用することができる。

Description

本開示は、複数のセンサからコントローラにセンサ情報を通信するシステムおよび方法に関し、より詳細には、携帯デバイスとコントローラとの間の通信に関するセンサ情報を通信することに関する。

スマートフォンをドアや車両などの機器デバイスへのアクセスや操作を指示するための鍵として利用することができるようにするため多大な努力が払われてきた。従来のシステムは、送信機と受信機との間の相対的な距離および／または位置を決定するために、通信の信号強度に依存することができる。例えば、多くの従来のシステムは、送信機と受信機との間の相対距離および／または位置を決定するために、指向性アンテナを用いて信号強度を測定する。送信機と受信機との間の複数の通信に関して複数の測定が行われる場合、かなりの数の測定が生じ得る。帯域幅の制約のために、この数は制限される可能性があり、送信機および受信機に対する位置を測定し決定するシステムの能力に悪影響を及ぼす。

１つ以上の実施形態によるシステムおよび方法は、１つ以上のセンサ（例えば、センサ、ハブ、センサコントローラなど）の間で、無線にて同期、監視、または通信、あるいはそれらの組み合わせを容易にすることができる。一実施形態におけるシステムおよび方法は、ブルートゥース（登録商標、以下同様）ローエナジー（ＢＬＥ）マイクロロケーションシステムに基づいてもよい。システムまたは方法、あるいはその両方は、デバイスと通信するために使用されるＢＬＥプロトコルの接続間隔ギャップ内に通信プロトコルを割り込ませるために、ＢＬＥハードウェア（例えば、送信機、受信機、アンテナなど）を使用してもよい。

一実施形態において、コントローラデバイスと携帯デバイスとの間の通信に関するセンサ情報を収集する方法が提供される。その方法は、通信プロトコルに従ってコントローラデバイスと携帯デバイスとの間の通信リンクに関する１つ以上の接続パラメータを送信することと、少なくとも１つのセンサデバイスにおいて１つ以上の接続パラメータを受信することとを含んでもよい。その方法は、接続間隔で、コントローラデバイスと携帯デバイスとの間の通信リンクを介してデータを繰り返し通信することを含んでもよい。少なくとも１つのセンサデバイスは、接続間隔中に、コントローラデバイスと携帯デバイスとの間の通信の１つ以上の特性を検知してもよい。１つ以上の検知特性に関するセンサ情報は、接続間隔内のギャップ時間フレームで送信されてもよい。

一実施形態において、ギャップ時間フレームは、ａ）接続間隔中のマスタデバイスと携帯デバイスとの間の通信の終了と、ｂ）次の接続間隔の開始との間に定義されてもよい。一実施形態では、この方法は、１つ以上の接続パラメータを少なくとも１つのセンサにブロードキャストすることを含んでもよい。

一実施形態において、通信プロトコルはブルートゥースローエナジーであり、センサ情報の送信は、ブルートゥースローエナジーハードウェアを介して行われるが、ブルートゥースローエナジープロトコルに従っては行われない。

一実施形態において、センサ情報を通信するためのシステムが提供される。このシステムは、コントローラデバイスと、複数のセンサデバイスとを含んでもよい。コントローラデバイスは、複数のセンサデバイスと通信し、複数のセンサデバイスの第１のセットから複数のパケットを受信するように構成されてもよい。

複数のセンサデバイスの各々は、オプションで、携帯デバイスとの（例えば、携帯デバイスへの、および／または携帯デバイスからの）通信に関する検知される特性を取得するように構成されてもよい。複数のセンサデバイスの各々は、検知特性を示すセンサ情報を有するデータパケットを生成し、そのデータパケットをコントローラデバイスおよび複数のセンサデバイスのうちの別のものの少なくとも１つに送信するように構成されてもよい。一実施形態において、データパケットは、そのデータパケットをコントローラデバイスに通信するために他のセンサデバイスによって利用されているものとは異なる通信チャネルまたは周波数上で、複数のセンサデバイスのすべてに送信されてもよい。

複数のセンサデバイスの各々は、検知される特性を検知すること、および複数のセンサデバイスの別のものから検知特性を受信することの少なくとも１つによって、検知特性を取得するように構成されてもよい。一例を提供するために、センサデバイスは、通信を介して無線にて、または特性を測定もしくは検知することによって、検知特性を受信してもよい（例えば、無線通信または温度などの外部パラメータ）。

一実施形態において、第１のセンサデバイスが複数のセンサデバイスの第１のセットに含まれ、第２のセンサデバイスが複数のデバイスの第２のセットに含まれる。第１のセットの第１のセンサデバイスは、第２のセンサデバイスがセンサ情報を含むデータパケットを送信する第１の時間フレームの間にデータパケットをコントローラデバイスに送信するように構成されてもよい。第１の時間フレームに続く第２の時間フレームの間に、コントローラデバイスは第２のセンサデバイスによって生成されたセンサ情報を受信する。

一例として、第１のセンサデバイスは、第１の時間フレームの間に第２のセンサデバイスによって生成され送信されたセンサ情報を受信し、次いで第２の時間フレームの間にセンサ情報を送信してもよい。このセンサ情報は、第２のセンサデバイスによって検知された特性の１つ以上の測定値を含んでもよい。

一実施形態において、コントローラデバイスとの通信は通信プロトコルに従って行われてもよく、そこにおいて、複数のセンサデバイスはブルートゥースローエナジー通信プロトコルに従って携帯デバイスに関する通信を受信する。コントローラデバイスは、携帯デバイスとの通信を監視するための接続パラメータを複数のセンサデバイスに通信することができる。接続パラメータは、複数の接続間隔の間に携帯デバイスからの通信の受信を容易にする情報を含むことができる。複数の接続間隔の各々の間に、携帯デバイスは、ブルートゥースローエナジープロトコルに従って、通信リンクを介してコントローラデバイスとデータを通信することができる。複数のセンサの各々は、通信リンクを介して送信される通信を受信することができるブルートゥースローエナジーハードウェアを含有してもよい。

センサ情報が複数のセンサから送信される第１および第２の時間フレームは、各接続間隔のギャップ時間フレーム内に定義されてもよい。このギャップ時間フレームの間、携帯デバイスからの通信が行われないかもしれない。

一実施形態において、第１のセンサデバイスおよび第２のセンサデバイスからの通信は、ブルートゥースローエナジーハードウェアを介して通信されるが、ブルートゥースローエナジープロトコルとは異なる通信プロトコルに従って定義されてもよい。

一実施形態において、センサ情報を収集するためのシステムを提供することができる。このシステムは、複数のセンサデバイスと通信コントローラとを含むことができる。複数のセンサデバイスは、センサ情報を通信し、検知特性を取得し、検知特性を示すセンサ情報を生成するように構成されてもよい。検知特性は、検知特性を検知すること、および複数のセンサデバイスのうちの別のものから検知特性を受信することの少なくとも１つによって取得され得る。

通信コントローラは、複数のセンサデバイスからセンサ情報を収集するように構成されてもよく、複数のセンサデバイスのうちの第１のセンサデバイスは、複数のセンサデバイスのうちの第２のセンサデバイスからセンサ情報を収集するように構成される。第１のセンサデバイスは、複数のセンサデバイスのうちの第３のセンサデバイス（オプションとして、第１のセンサデバイスであってもよい）が通信コントローラにセンサ情報を送信する時間フレームの間に、第２のセンサデバイスからセンサ情報を受信してもよい。第１のセンサデバイスは、第２のセンサデバイスから受信したセンサ情報を用いて集約データパケットを生成し、その集約データパケットを通信コントローラに送信してもよい。

一実施形態において、複数のセンサデバイスからコントローラデバイスへセンサ情報を通信する方法が提供される。この方法は、第１のセンサデバイスおよび第２のセンサデバイスのそれぞれにおいて検知特性を取得すること、および第１のセンサデバイスおよび第２のセンサデバイスのそれぞれにおいて取得された検知特性を示すセンサ情報を生成することを含むことができる。第１の時間フレームの間に、第１のセンサデバイスからのセンサ情報がコントローラデバイスに送信されてもよい。この第１の時間フレームの間に、第２のセンサデバイスからのセンサ情報が送信されてもよい。第１の時間フレームに続く第２の時間フレームの間に、第２のセンサデバイス以外のセンサデバイスが、第２のセンサデバイスで取得されたセンサ情報を送信してもよい。

本発明の実施形態が詳細に説明される前に、本発明は、以下の説明に記載の、または図面に示されたコンポーネントの動作の詳細、あるいは、構成および配置の詳細に限定されないことを理解されたい。本発明は、様々な他の実施形態で実施されてもよく、本明細書に明示的に開示されていない別の方法で実施または実行することができる。また、本明細書で使用される表現および用語は、説明のためのものであり、限定するものとして見なされるべきではないことを理解されたい。「含む（including）」および「備える（comprising）」およびそれらの変形の使用は、それ以降に列挙される品目及びそれらの等価物、並びに追加の品目およびそれらの等価物を包含することを意味する。さらに、列挙することが、様々な実施形態の説明において使用されるかもしれない。特に明記しない限り、列挙することの使用が、本発明をコンポーネントのある特定の順序または数に限定するものとして解釈されるべきではない。また、列挙することの使用が、列挙されたステップまたはコンポーネントと、またはコンポーネント内に組み合わせることができる任意の追加のステップまたはコンポーネントを本発明の範囲から除外するものとして解釈されるべきではない。

一実施形態による内部機能を有するセンサを示す図である。

一実施形態による、内部機能を有するバックチャネルコントローラを示す図である。

一実施形態による内部機能を有するセンサハブを示す図である。

一実施形態によるバックチャネルプロトコルフレームを示す図である。

一実施形態によるセンサバックチャネルセキュリティモデルを示す図である。

一実施形態によるサイドチャネルを介して接続された複数のセンサハブを示す図である。

非段階的接続の実施形態における３つのセンサ応答を示す図である。

段階的接続の実施形態における３つのセンサ応答を示す図である。

一実施形態による、段階的接続を有する７つのセンサ構成および測定データの中継を示す図である。

一実施形態による複製されたブロードキャストおよび中継されるセンサのタイミングを示す図である。

図１１Ａ−Ｄは、一実施形態による、複製されたブロードキャストおよび中継されるセンサのシーケンスを示す図である。

一実施形態によるセンサハブ間で共有されるセンサを示す図である。

一実施形態によるセンサ対デバイスまたはデバイス対センサの構成を示す図である。

一実施形態による、デバイス対ＢＣＣ通信を傍受するセンサを示す図である。

一実施形態による、近接センサから測定データを収集するためにバックチャネルを使用することを示す図である。

一実施形態によるシステムを示す図である。

一実施形態によるデバイスを示す図である。

一実施形態による図１６のシステムを示す図である。

Ａ．システム概要
本開示は、ブルートゥースローエナジー（ＢＬＥ）ベースのマイクロロケーションシステムにおいて、センサ（例えば、センサ、ハブ、センサコントローラなど）の間で無線にて同期、監視、または通信、あるいはそれらの組み合わせを行うためのシステムおよび方法に関する。システムまたは方法、あるいはその両方は、デバイスと通信するために使用される標準的なＢＬＥプロトコルの接続間隔ギャップ内に通信プロトコル（「無線バックチャネル」）を割り込ませるために、ＢＬＥハードウェア（例えば、送信機、受信機、アンテナなど）を使用することができる。本開示で説明される一般的な通信方法は、スケジュールされ、論理的なカスケードツリートポロジを介して送信されるセンサ応答を有する、１つ以上のセンサへのブロードキャストメッセージを利用することができる。

マイクロロケーションの精度を向上または最大化するためには、エラーを低減または最小化し、実質的に故障／異常を検出するように、センサ測定値を迅速かつ同期的に収集および分析することが有用である。マイクロロケーションセンサデータの監視（通信および収集）を容易にすることに加えて、システムおよび方法は、マイクロロケーションされるデバイスから独立した、センサが存在する環境に関する追加の測定情報を提供してもよく、それにより、従来の方法よりもはるかに多くのデータを高い多様性をもって提供することにより、マイクロロケーションシステムおよび方法をさらに支援することができる。システムおよび方法はまた、センサ動作を同期させるための時間関連データを配信するために使用されてもよい。さらに、システムは、設定、構成、制御、診断、動作、または他の情報、あるいはそれらの任意の組み合わせを通信するために使用されてもよい。

説明されるシステムおよび方法は、ＢＬＥベースのマイクロロケーションシステムに適用される一方で、それらは代わりの無線周波数および非無線周波数の無線（例えば、超広帯域（ＵＷＢ）、超音波、光学系（例えば、光）、など）及び有線（例えば、ＵＡＲＴ、ＬＩＮ、ＣＡＮ、イーサネット（登録商標、以下同様）、など）の技術および／またはプロトコルを使用するマイクロロケーションシステムにも適用され得ることは注目に値するかもしれない。それはまた、構成要素間の同期、監視、または通信、あるいはそれらの組み合わせを可能とするように、マイクロロケーションシステムではないシステムに適用されてもよい（例えば、本明細書に記載のＢＬＥハードウェアを使用して構成要素が通信する非マイクロロケーションシステム、ＵＷＢを使用するシステム、など）。

Ａ．１．マイクロロケーションシステム
このシステムの１つまたは複数の部分は、２０１７年４月１４に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittらの米国特許出願第１５／４８８１３６号、および２０１６年４月１５日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国仮出願第６２／３２３２６２号に記載されているマイクロロケーションシステムの１つまたは複数の部分と併せて実行することができる。これらの開示は、その全体が参照により本明細書に組み込まれる。そこでのモニタまたはマスタデバイスは、本明細書ではセンサと称され、そこでの携帯デバイスは、本明細書ではデバイスと称される（「携帯デバイス」は、その用語にかかわらず、持ち運び可能であっても良いし、または固定された位置にあってもよい）。このような実施形態において、マイクロロケーションシステムは、デバイスと通信するためにＢＬＥを使用し、センサは、互いに同期、監視、または通信、あるいはその組み合わせを行うために本明細書に記載のシステムおよび方法を利用し、センサとデバイスは、通信するためにＢＬＥハードウェアのみを利用することができる。

本システムの１つまたは複数の部分は、２０１６年１０月２７日に出願され、「デバイスを認証および認可するための、および／または鍵を配布するためのシステムおよび方法」と題する、Smithらの米国仮特許出願第６２／４１３９６６号、および２０１７年１０月２７日に出願され、「デバイスを認証および認可するためのシステムおよび方法」と題する、Smithらの米国特許出願第１５／７９６１８０号に記載されたセキュリティモデルの１つまたは複数の部分と併せて実施することができる。これらの開示は、その全体が参照により本明細書に組み込まれる。そこでのＳＣＭは本明細書ではセンサ（バックチャネル）ハブおよび／またはセンサ（バックチャネル）コントローラと称されるかもしれない。そのような実施形態では、例えば、センサ間の安全な通信を容易にするために、センサ鍵（対称および／または非対称）および／または証明書および／または他のセキュリティ関連構成および／または信用証明書が、そこに記載されている方法のいずれかを使用して（たとえば、ＡＣＰまたは別の構成パッケージを介して）、安全に取得され、更新（循環）され、および／または取り消されることができる。

マイクロロケーションシステムを組み込んだ、本開示の一実施形態によるシステムが、１００で指定され、図１６−図１８に関連して表示され、説明される。

システム１００は、以下のシステムコンポーネントのうちの１つ以上を含むことができる。ａ）１人以上のユーザ１０（例えば、人々）、ｂ）携帯デバイス（例えば、スマートフォン、カードもしくはフォブ、またはそれらの組み合わせ）および／または固定デバイス（例えば、コンピュータ／サーバ、もしくは壁掛けパネル／ディスプレイ、またはそれらの組み合わせ）などの１つ以上のデバイス１１０、ｃ）ハードウェアまたはマスタデバイスまたはハブまたはセンサコントローラとしても説明される、１つ以上のシステム制御モジュール（ＳＣＭ）１２０、ｄ）１つ以上のセンサ３１０、およびｅ）機器動作を制御し、そこにおいてサービスを起動し、システム１００の他の部分に情報を中継し、またはシステム１００の他の部分から情報を検索し、またはそれらの組み合わせのために構成され得る１つ以上の機器コンポーネント１４０。

システム１００は、１人以上のユーザ１０が、デバイス１１０を使用して機器１４０とやり取りするか、または機器１４０にアクセスすることを可能にすることができる。デバイス１１０は、ＳＣＭ１２０と通信することによって機器１４０（車両、ロック、またはテーブルなど）と通信することができる。一実施形態のＳＣＭ１２０は、デバイス１１０を認証し、設定データを提供または受信し、アクション（例えば、接続すること、または要求、コマンド、更新、または応答、またはそれらの組み合わせを送信および／または受信すること）を承認し、または所望のアクションを達成するために機器コンポーネント１４０と通信し、またはそれらの組み合わせを実行することができる。デバイス１１０は、関係するデバイスおよびユーザとの間で、（本明細書で説明される）認可および他の設定データを取得し、変更し、または配信し、またはそれらの組み合わせを行うために、クラウド（図示せず）と通信することができる。そのようなシステムの一例は、２０１７年１０月２７日に出願され、「デバイスを認証および認可するためのシステムおよび方法」と題する、Smithらの米国特許出願第１５／７９６１８０号に示され、説明されている。その開示は、その全体が参照により本明細書に組み込まれる。

Ａ．１．ａ．通信とやり取りの概要
図１６−図１８に図示された実施形態に示された１つ以上のシステムコンポーネント間の通信リンクは、無線または有線、あるいはその両方であってもよい。デバイス１１０などの１つのシステムコンポーネントは、ＳＣＭ１２０などの別のシステムコンポーネントに対してローカルまたはリモートであってもよい。システム１００は、機器が存在しない場合のように、その数がゼロである実施形態を含む、任意の数の各システムコンポーネントを含むことができる。

一実施形態において、システム１００のシステムコンポーネントの役割は、必ずしも１つのタイプのコンポーネントとして固定されるとは限らない。例えば、システムコンポーネントは、動作中に動的に役割を変更してもよく、またはシステムコンポーネントが、システム１００の２つ以上のコンポーネントの役割を受け持ってもよい。例えば、ＳＣＭ１２０は、別のＳＣＭ１２０のための機器コンポーネント１４０であってもよい。この例のより具体的な形態では、ＳＣＭ１２０は、他のＳＣＭ１２０と通信する機器コンポーネント１４０であってもよい。これらのシステムコンポーネントの１つまたは複数が存在しなくてもよいと理解されるべきであるが、開示の目的のため、残りの議論は、１つまたは複数の機器コンポーネント１４０が存在するシステム１００に焦点を当てる。オプションとして、システム１００は、デバイスのクラウドシステムなどの別のシステムと通信するように構成されてもよい。

Ａ．１．ｂ．コンポーネントの概要
図示された実施形態におけるシステム１００は、本明細書に概説されるような１つ以上のシステムコンポーネントを含むことができる。システムコンポーネントは、ユーザまたは電子システムコンポーネントであってもよく、それは、デバイス１１０、ＳＣＭ１２０、機器コンポーネント１４０、またはクラウド、もしくはそれらの組み合わせであってもよい。本明細書で論じられるように、電子システムコンポーネントは、それらのデバイスの任意の１つまたは複数として動作するように構成することができる。この意味で、一実施形態では、デバイス１１０、ＳＣＭ１２０、機器コンポーネント１４０、およびクラウド間で共通するいくつかの様相または特徴が存在し得る。開示の目的のために、これらの特徴が、図１７に示され、全体として２００で指定される電子コンポーネントに関連して説明される。

電子システムコンポーネント２００（例えば、ユーザを除くすべてのシステムコンポーネント）は、他の電子ハードウェアの中で、１つ以上のアプリケーション２３２（ソフトウェアおよび／またはファームウェアを含む）を実行する１つ以上のプロセッサ２１０、１つ以上のメモリユニット２１２（例えば、ＲＡＭおよび／またはＲＯＭ）、および１つ以上の通信ユニット２１４を含むことができる。電子システムコンポーネント２００は、通信ユニット２１４を介してより下位レベルのデバイス／電子機器へのアクセスを制御するオペレーティングシステム２３０を有していても有していなくてもよい。電子システムコンポーネント２００は、ハードウェアベースの暗号化ユニット２２２を有していても有していなくてもよく、存在しない場合、暗号化機能はソフトウェアで実行されてもよい。電子システムコンポーネント２００は、セキュアメモリユニット２２０（例えば、セキュアエレメントまたはハードウェアセキュリティモジュール（ＨＳＭ））を有していても有していなくても（または、アクセスしてもアクセスしなくても）よい。オプションのコンポーネントおよび通信経路は、図示の実施形態において仮想線で示されている。

図示された実施形態のシステム１００は、任意のコンポーネント内のセキュアメモリユニット２２０の存在に依存しない。セキュアメモリユニット２２０がオプションで存在しない場合、セキュアメモリユニット２２０に格納されてもよいデータ（例えば、非公開鍵および／または秘密鍵）は、休止時に（可能なときに）暗号化されてもよい。ソフトウェアベースおよびハードウェアベースの対策の両方を利用して、そのようなデータへのアクセスを実質的に防止し、並びに、全体的なシステムコンポーネントのセキュリティ破壊の招来を実質的に防止しまたは検出するか、またはその両方を行うことができる。このような対策機能の例には、物理的な障害物またはシールドの実装、ＪＴＡＧおよび他のポートの無効化、攻撃ベクトルを排除するようにソフトウェアインターフェースの強化、信頼できる実行環境（ハードウェアまたはソフトウェア、またはその両方）の使用、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来の検出が含まれる。

開示の目的のため、安全であることは、一般に、秘密であること（暗号化されていること）、認証されていること、および完全性が検証されていることと考えられている。しかし、本開示はそれに限定されず、「安全」という用語はこれらの態様のサブセットであってもよく、またはデータセキュリティに関連する追加の態様を含んでもよいことを理解されたい。

通信インターフェース２１４は、有線または無線を含む、本明細書で説明する通信リンクのタイプのいずれかを含む、任意のタイプの通信リンクとすることができる。通信インターフェース２１４は、外部または内部の、またはその両方の通信を容易にすることができる。例えば、通信インターフェース２１４は、アンテナ３１２に結合されてもよく、またはアンテナ３１２を組み込んでもよい。

別の例として、通信インターフェース２１４は、ブルートゥースＬＥ規格による無線通信や、Ｗｉ−Ｆｉイーサネット通信リンクを介するクラウド１３０など、デバイス１１０の形態の別のシステム電子デバイス２００との無線通信リンクを提供することができる。別の例では、通信インターフェース２１４は、複数のデバイス間の通信を容易にするＣＡＮベースの有線ネットワークなどの有線リンクを介して、機器コンポーネント１４０（例えば、車両コンポーネント）と通信するように構成することができる。一実施形態の通信インターフェース２１４は、ユーザ１０に情報を通信し、および／またはユーザ１０から情報を受信するためのディスプレイおよび／または入力インターフェースを含むことができる。

図１７に示す一実施形態では、電子システムコンポーネント２００は、別の電子システムコンポーネント２００またはユーザ以外の１つまたは複数の補助デバイス３００と通信するように構成されてもよい。補助デバイス３００は、電子システムコンポーネント２００とは異なって構成されてもよく、例えば、補助デバイス３００は、プロセッサ２１０を含まず、代わりに、電子システムコンポーネント２００との情報の送信または受信、もしくはその両方のための少なくとも１つの直接接続および／または通信インターフェースを含んでもよい。例えば、補助デバイス３００は、電子システムコンポーネント２００からの入力を受け入れるソレノイドであってもよく、または補助デバイス３００は、電子システムコンポーネント２００にアナログおよび／またはデジタルフィードバックを提供するセンサ（例えば、近接センサ）であってもよい。

Ａ．１．ｃ．マイクロロケーション
図示された実施形態のシステム１００は、デバイス１１０に関してリアルタイムで位置情報を決定するように構成されてもよい。図１６の図示の実施形態では、ユーザ１０は、デバイス１１０（例えば、スマートフォン）を携帯することができる。システム１００は、機器へのアクセスまたは機器コマンドの許可が与えられるべき位置にユーザが位置しているかどうかを判定するのに十分な精度でリアルタイムに、機器１４０（例えば、車両）に対するデバイス１１０の位置特定を容易にすることができる。

例えば、機器１４０が車両である車両の分野では、システム１００は、デバイス１１０が車両の外部にあるが、運転者側のドアまで５フィート、３フィート、または２フィート以下のようにすぐ近くであるかどうかの決定を容易にすることができる。この決定は、システム１００が車両をアンロックすべきかどうかを識別するための基礎をなすことができる。一方、システム１００が、デバイス１１０は車両の外部にあり、運転者側ドアのすぐ近くにない（例えば、２フィート、３フィート、または５フィートの範囲外にある）と判定した場合、システム１００は、運転者側ドアをロックすることを決定することができる。別の例として、システム１００が、デバイス１１０は運転者側席のすぐ近くにあるが、助手席または後席の近くではないと判断した場合、システム１００は、車両の始動を可能にすることを決定することができる。逆に、デバイス１１０が運転者側席の近接範囲外であると判定された場合、システム１００は、車両を不動にすることまたは不動を維持することを決定することができる。

この状況における車両はまた、図１８の図示された実施形態に関連して説明される、１つまたは複数のセンサ３１０のような他のタイプの機器１４０を含むことができる。１つまたは複数のセンサ３１０は、電子システムコンポーネント２００に関連して説明した実施形態と同様に構成することができる。

機器１４０のマイクロロケーションは、全地球測位システム、デバイス１１０からの通信の１つ以上の信号特性、および１つまたは複数のセンサ（例えば、近接センサ、リミットスイッチ、または視覚センサ）、またはそれらの組み合わせから得られた情報を使用するなど、様々な方法で決定することができる。システム１００を構成することができるマイクロロケーション技法の一例は、２０１７年４月１４に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittらの米国特許出願第１５／４８８１３６号に記載されており、その開示は、その全体が参照により本明細書に組み込まれる。

一実施形態において、図１８の図示された実施形態では、ＳＣＭ１２０および複数のセンサ３１０は、機器コンポーネント１４０上に、または機器コンポーネント１４０に対して固定された位置に配置することができる。機器コンポーネント１４０の例示のユースケースは、先の例で特定された車両、または機器コンポーネント１４０によってアクセスが制御される建物を含む。図示の実施形態におけるセンサ３１０は、本明細書に記載されるように１つまたは複数のアンテナ３１２を含むことができる。センサ３１０の配置または位置は、本明細書に記載の１つまたは複数の実施形態に従うことができる。ＳＣＭ１２０の信号処理は、本明細書に記載の１つまたは複数の実施形態に従うことができる。

デバイス１１０は、通信リンクを介してＳＣＭ１２０と無線で（例えば、ブルートゥースＬＥを介して）通信することができる。複数のセンサ３１０は、デバイス１１０とＳＣＭ１２０との間の通信を傍受して、信号強度などの通信の１つ以上の信号特性を決定するように構成することができる。決定された信号特性は、デバイス１１０とＳＣＭ１２０との間の通信リンクとは別の通信リンクを介して、ＳＣＭ１２０に通信されるか、または分析された後に通信されてもよい。追加的にまたは代替的に、デバイス１１０は、１つまたは複数のセンサ３１０との直接の通信リンクを確立してもよく、１つ以上の信号特性は、この直接の通信リンクに基づいて決定されてもよい。

一例として、図示の実施形態に示すように、デバイス１１０からＳＣＭ１２０への通信の伝播波が示され、３０２、３０４、３０６で明示されている。デバイス１１０（発信元）からの距離が大きいほど、無線通信の強度は小さくなる。伝播波３０６に関する通信の強度は、伝播波３０２の強度よりも小さい。さらに、時間Ｔ０において通信が送信された場合、伝播波３０２での通信のための伝搬時間（ＴＰ１−Ｔ０）は、伝播波３０６での通信のための伝搬時間（ＴＰ３−Ｔ０）よりも短い。その結果、センサ３１０が伝播波３０２で通信を受信した場合、通信の到着のタイムスタンプは、通信が伝播波３０６で受信された場合よりも早くなる可能性がある。

本明細書に記載されるように、信号強度および到着時間などの１つ以上の信号特性が、ＳＣＭ１２０に対するデバイス１１０に関する位置情報を決定するために、分析されることができる。例えば、センサ３１０とＳＣＭ１２０との間の到着時間差が、デバイス１１０の相対位置を決定するために処理されてもよい。ＳＣＭ１２０に対する１つまたは複数のセンサ３１０の位置は、デバイス１１０の相対位置がセンサ３１０およびＳＣＭ１２０に対する絶対位置に変換されることができるように、既知であってもよい。信号特性の追加的または代替的な例が、距離関数、三辺測量関数、三角測量関数、多辺測量関数、フィンガープリント関数、差分関数、飛行時間関数、到着時間関数、到着時間差関数、到着角度関数、出発角度関数、幾何学関数など、またはそれらの任意の組み合わせを含む、１つまたは複数のアルゴリズムに従って位置を決定することを容易にするために取得されてもよい。

図示の目的のために、伝播波３０２、３０４、３０６は一様な円形として描かれているが、伝播波は、干渉または指向性アンテナの使用などの他の要因に依存して形状が変化するかもしれないことに留意されたい。

一実施形態では、デバイス１１０とＳＣＭ１２０との間の通信に関する情報は、複数のセンサ３１０に提供されてもよい。例えば、ブルートゥースＬＥチャネルに関する接続パラメータが、複数のセンサ３１０が通信を監視することができるように、センサ３１０に提供されてもよい。例えば、通信チャネルは、パケットごとにまたはパケット内で送信されるビットの中で、送信の周波数など、通信中に１つまたは複数のパラメータを変更するかもしれない。これらの１つ以上の可変パラメータは、パケットまたは通信の受信を可能にするためにセンサ３１０に通信されてもよい。

Ａ．２．システムコンポーネント
一実施形態による、バックチャネルシステムとしても説明されるシステム１００は、１つまたは複数のバックチャネルコントローラ（ＢＣＣ、１２０）、１つまたは複数のセンサハブ１２１、１つまたは複数のセンサ３１０、および１つまたは複数のデバイス１１０を含むことができる。図１−図１５の図示された実施形態におけるＢＣＣ１２０は、１２０で指定され、本明細書においてＳＣＭまたはマスタデバイスとしても記載される。１つ以上のセンサハブ１２１は、（本明細書に記載されている）初期接続設備なしで構成されていることを除いて、ＢＣＣ１２０に類似してもよく、図１−図１５の図示された実施形態において１２１で指定される。図１−図１５の図示された実施形態における１つ以上のセンサ３１０は、図１６−図１８に関連して説明したセンサ３１０に相当してもよく、同様に、３１０で指定される。そして、図１−図１５の図示された実施形態における１つ以上のデバイスは、図１６−図１８に関連して説明したデバイス１１０に相当してもよく、１１０で指定される。

Ａ．２．ａ．デバイス
一実施形態において、デバイス１１０は、マイクロロケーションされ得るシステム１００内のアイテムである。いくつかの事例では、デバイス１１０はモバイル式（持ち運び可能）であってもよいが、他の事例では固定されていてもよい。システム１００の残りの部分は移動してもしなくてもよい。センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせも、デバイス１１０であり得る（例えば、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせが、製造工程中の自動較正手順の間に、マイクロロケーションされる場合）。場合によっては、デバイス１１０は人の位置に対応してもよい。他の場合には、それは車両、動物、または他のアイテムであってもよい。いくつかのシステムでは、デバイス１１０は、携帯電話、タブレット、またはＢＬＥハードウェアを備えた他の電子コンポーネントとすることができる。他のシステムでは、デバイス１１０は、ＵＷＢハードウェアを有する電子コンポーネントであってもよい。デバイス１１０の位置は、前記デバイス１１０から受信したメッセージの属性を測定することによって計算することができる。

Ａ．２．ｂ．センサ
一実施形態において、センサ３１０は、１つ以上のデバイス１１０の位置と相関し得る測定を実行することができる。センサ３１０は、マイクロロケーションをサポートするように戦略的に配置されてもよい。センサ３１０は、限定されるわけではないが、受信信号強度インジケータ（ＲＳＳＩ）、到着角度（ＡｏＡ）、または飛行時間、あるいはそれらの組み合わせを含む、任意の数の属性を、受信メッセージを介して測定または導出することができる。センサ３１０はまた、デバイス１１０、それ自体、他のセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ、あるいはそれらの組み合わせから得られた情報を転送することができる。

設備は、特定の機能を実行するソフトウェアおよび／またはハードウェアの集合であり得る。設備は、特定の機能を一般的にまたは具体的に示すためのものとして説明され得る（例えば、ＢＬＥ通信、ＢＬＥソフトウェアスタック、ＢＬＥ中央モードコントローラ、ＢＬＥ無線機など）。センサ３１０は、（以下に説明されるように）他に考えられる設備の中でも、少なくとも１つの測定実行設備（ＭＴＦ、４０４）と、少なくとも１つのバックチャネルスレーブ設備（ＢＣＳＦ、４０２）とを含むことができる。例えば、図１の図示された実施形態を参照されたい。

一実施形態において、各センサ３１０は複数のアンテナを有することができ、各パケットが送信または受信される前に所望のアンテナが選択される。この実施形態は、２０１６年１２月１４に出願され、「マイクロロケーションゾーンを確立するためのシステムおよび方法」と題する、Smithらの米国仮出願第６２／４３４３９２号、および２０１７年１２月１４に出願され、「マイクロロケーションゾーンを確立するためのシステムおよび方法」と題する、Smithらの米国非仮出願第１５／８４２４７９号に記載された１つまたは複数の実施形態と併せて実施することができ、それらの開示は、その全体が参照により本明細書に組み込まれる。

ＢＣＳＦ４０２は、適切な通信媒体上でバックチャネルプロトコル（ＢＣＰ、本明細書で説明される）を提供する。

Ａ．２．ｃ．バックチャネルコントローラ
バックチャネルコントローラ（ＢＣＣ、１２０）は、少なくとも１つの初期接続設備（ＩＣＦ、４１２）、少なくとも１つのマイクロロケーション接続設備（ＭＣＦ、４１０）、または少なくとも１つのバックチャネルコントローラ設備（ＢＣＣＦ、４００）、あるいはそれらの任意の組み合わせを含むことができる。例えば、図２の図示された実施形態を参照されたい。

初期接続設備（ＩＣＦ４１２）は、デバイス１１０とＢＣＣ１２０（すなわち、ＩＣＦ４１２）との間の「初期接続」を確立するために使用され得る。ＢＬＥを使用するこのようなマイクロロケーションシステムでは、デバイス１１０が「中央」の役割で動作している（したがって、ＩＣＦ４１２が「周辺」の役割で動作しているとき）とき、あるいは代替として、デバイス１１０が「周辺」の役割で動作している（したがって、ＩＣＦ４１２が「中央」の役割で動作している）ときに、ＩＣＦ４１２は、「初期接続」を確立することができる。測定は、ＩＣＦ４１２に接続されたデバイス１１０から行われてもよい。本開示の実施形態は、２０１６年４月１５日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国仮出願第６２／３２３２６２号に記載されている１つ以上の実施形態と併せて実行されてもよく、その開示は、その全体が参照により本明細書に組み入れられる。

一実施形態において、ＭＣＦ４１０のみが存在してもよい。そのような実施形態は、２０１５年２月１２に出願され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国非仮出願第１４／６２０９５９号に記載されているシステムの１つまたは複数の実施形態と併せて実行されてもよく、その開示は、その全体が参照により本明細書に組み入れられる。

マイクロロケーション接続設備（ＭＣＦ４１０）は、デバイス１１０とＢＣＣ１２０（すなわち、ＭＣＦ４１０）との間の「マイクロロケーション接続」（または、ＩＣＦ４１２がない場合には接続）を確立し維持するために使用され得る。ＢＬＥを使用するこのようなマイクロロケーションシステムでは、デバイス１１０が「周辺」の役割で動作している（したがって、ＭＣＦ４１０が「中央」の役割で動作している）とき、あるいは代替として、デバイス１１０が「中央」の役割で動作している（したがって、ＭＣＦ４１０が「周辺」の役割で動作している）とき、ＭＣＦ４１０は「マイクロロケーション接続」を確立することができる。測定は、ＭＣＦ４１０に接続されたデバイス１１０から行われてもよい。本開示による一実施形態は、２０１６年４月１５日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国仮出願第６２／３２３２６２号に記載されている１つ以上の実施形態と併せて実行されてもよく、その開示は、その全体が参照により本明細書に組み入れられる。

一実施形態において、ＩＣＦ４１２およびＭＣＦ４１０は、安全な接続を確立することができる。

特定の用途のために、他の設備がバックチャネルコントローラ１２０に存在してもよい。例えば、測定データに基づいてデバイス１１０の位置を決定するために、位置決定設備（ＬＤＦ）がバックチャネルコントローラ１２０内に存在してもよい。別の例として、バックチャネルコントローラ１２０は、センサネットワーク環境測定設備（ＳＮＥＭＦ）を提供してもよい。さらに別の例では、バックチャネルコントローラ１２０は、外部機器へのインターフェースを組み込んでもよい。

ＢＣＣＦ４００は、ＢＣＳＦ４０２の上位セットであってもよく、および／またはＢＣＳＦ４０２を含んでもよい。ＢＣＣＦ４００は、適切な通信媒体上にて、ＢＣＳＦ４０２（後述）の間でＢＣＰを調整してもよい。
Ａ．２．ｄ．センサハブ

センサハブ１２１は、少なくとも１つのマイクロロケーション接続設備（ＭＣＦ４１０）、および／または少なくとも１つのバックチャネルコントローラ１２０（初期接続設備［ＩＣＦ４１２］なし）を含むことができる。例えば、図３の図示された実施形態を参照されたい。センサ３１０が分散されており、センサの間での長い距離を克服するためにセンサ３１０の通信の中継器またはアグリゲータが使用され得る状況において、１つ以上のセンサハブ１２１が使用されてもよい。

Ａ．３．バックチャネルプロトコル（ＢＣＰ）
バックチャネルプロトコル（ＢＣＰ）は、ＢＣＳＦ４０２およびＢＣＣＦ４００が互いに通信することができるシステム１００および方法を定義する。

ＢＬＥベースのマイクロロケーションシステム１００において、例えば、図４の図示された実施形態に示されるように、ＢＣＰは、デバイス１１０（例えば、ＭＴＦ４０４、ＩＣＦ４１２、ＭＣＦ４１０、他の設備など）と通信するために使用される標準的なＢＬＥプロトコルの接続間隔ギャップ内に割り込ませることができる。非ＢＬＥベースのおよび／または混成技術のシステムでは、ＢＣＰは、他の通信プロトコルの中で割り込み、切り替え／多重化、もしくは同時使用されてもよく、またはそれらの任意の組み合わせでもよい。

ＢＣＰフレーム（バックチャネル［プロトコル］フレーム）は、次のセクションで説明するように、（別のプロトコル内に含まれるように、またはそれ自体に）ＢＣＰのタイミングを制限することができ、１つまたは複数のアナウンスメント、コマンド、もしくはレスポンス、またはそれらの任意の組み合わせのセットを含むことができる。

ＢＬＥベースの実施形態では、ＢＣＰフレームは、（他の箇所で説明されているように）ＢＬＥプロトコル内にＢＣＰのタイミングを制限する。このＢＬＥベースの実施形態では、接続間隔ごとに最大１つのＢＣＰフレームがある。ＢＬＥベースの実施形態の代替形態では、接続間隔ごとに１つまたは複数のＢＣＰフレームがあってもよい。

ＢＬＥベースの実施形態では、ＢＣＰがデバイス１１０と実質的に競合しないように、または、システム１００内で、それらの追加および／または削除を行うことができるように、ＢＣＰフレームが、デバイス１１０のための接続イベント後の接続間隔内に動的に配置されてもよい。代替のＢＬＥベースの実施形態では、デバイス１１０、またはシステム１００内でのそれらの追加および／または除去が、ＢＣＰタイミングに実質的に影響を及ぼさないように、ＢＣＰフレームが接続間隔の終わりに配置されてもよい。代替のＢＬＥベースの実施形態では、デバイス１１０の接続イベントの前、間、または後の様々なギャップ内でＢＣＰ通信が行われるようにして、ＢＣＰフレームが、全体のＢＬＥ接続間隔に及んでもよい。

Ａ．３．ａ．センサネットワークへの接続と再接続
ＢＣＳＦ４０２は、（セクションＡ．５．ｂに記載されているように）ＢＣＣＦ４００によって確立されたセンサネットワークに参加することができる。

ＢＣＣＦ４００の電源投入、リセット、ＢＣＳＦ４０２通信の喪失（後述）、または他の何らかのイベント、あるいはそれらの組み合わせによって、そのような動作（例えば、自己テスト失敗、コマンドなど）を引き起こす可能性があり、ＢＣＣＦ４００は、ＢＣＰ構成パラメータ（例えば、初期チャネル、周波数など）を確立し、アナウンスメントパケット（後述）を送信してもよい。

ＢＣＳＦ４０２の電源投入、リセット、ＢＣＣＦ４００通信の喪失（後述）、または他の何らかのイベント、あるいはそれらの組み合わせによって、そのような動作（例えば、自己テスト失敗、コマンドなど）を引き起こす可能性があり、ＢＣＳＦ４０２は、構成パラメータを取得するためにアナウンスパケットを待ち受けしてもよい（すなわち、後述するように、未知のＢＣＰ構成状態に入る）。

代替の実施形態では、構成パラメータが固定され、システムコンポーネントの全部またはサブセットによって既知とされ、したがって、アナウンスメントパケットが存在しなくてもよい。

Ａ．３．ａ．ｌ アナウンスメントパケット
アナウンスメントパケットは、ＢＣＰ内で使用される構成パラメータ（プロトコルバージョン情報および／または他の属性を含む）、ならびに非構成パラメータを含んでもよい。アナウンスメントパケットはまた、パラメータを含まなくてもよく、ハートビートまたは同期メカニズムとして使用されてもよい。ＢＬＥベースの実施形態では、アナウンスメントパケットは、ＢＣＳＦ４０２が通信すべき現在のＢＬＥチャネルを含み得る。ＢＬＥベースの実施形態では、アナウンスメントパケットは、次のアナウンスメントパケットが送信されることになるＢＬＥチャネルを含んでもよい。

Ａ．３．ａ．１．ａ アナウンスパケット−ＢＣＣＦ
アナウンスメントパケットは、各ＢＣＰフレームの開始時にネットワークに（すなわち、ＢＣＣＦ４００からＢＣＳＦ４０２に）ブロードキャストすることができる。ＢＣＣＦ４００はＢＣＳＦ４０２を含んでもよく、したがって他のＢＣＣＦ４００はアナウンスメントパケットの受信者であり得ることに留意されたい。通信媒体に適用可能である場合、ＢＣＣＦ４００は、現在および／または次のブロードキャスト周波数／チャネルを決定することを可能にし得るアナウンスメントパケットをＢＣＳＦ４０２に事前に提供していないかもしれない（例えば、ちょうど電源が投入された、リセットされた、もはやＢＣＳＦ４０２とは通信していないと判断されたため、または以前に通信した周波数／チャネルでのブロードキャストを停止させた可能性がある他の何らかの事象［例えば、自己テスト失敗、コマンド、など］のため、またはそれらの理由の組合せのため）。この状態（構成同期状態）にあるとき、ＢＣＣＦ４００は、（適用可能な場合、以前に確立された構成パラメータと一致しない可能性がある）新しい構成パラメータを確立することができ、さらに、タイムアウトの有無によらず、既知のＢＣＳＦ４０２の全部またはサブセットが通信（すなわち、レスポンスパケットを送信）するのを待機することができる。通信媒体に適用可能であれば、ＢＣＣＦ４００は、アナウンスメントパケットを特定の周波数／チャネル、周波数／チャネルのセット、または周波数／チャネルの全部もしくはサブセットでブロードキャストしてもよい。ブロードキャストする周波数／チャネルは、固定されていてもよいし、または、所定のシーケンス、ランダム化されたシーケンス、ネットワークの輻輳、または他の方法、あるいは適切な方法の組み合わせを使用して選択されてもよい。アナウンスメントパケットは、同じＢＣＰフレーム内で、または複数のＢＣＰフレーム間で（例えば、ネットワーク衝突を軽減するため、異なる周波数／チャネルで現在聴取しているＢＣＳＦ４０２が周波数／チャネルを変更できるようにするため、など）、またはそれらの組み合わせで、同じ周波数／チャネルで複数回送信されてもよい。

ＢＬＥベースの実施形態では、アナウンスメントパケットは３つのアドバタイジングチャネルのうちの１つでブロードキャストされてもよく、アナウンスメントパケットが送信されるアドバタイジングチャネルは、ＢＣＰフレームからＢＣＰフレームまでラウンドロビン方式で選択されてもよい（例えば、フレーム０が１番目のアドバタイズチャネル［３７］でブロードキャストし、フレーム１が２番目［３８］でブロードキャストし、フレーム２が３番目［３９］でブロードキャストし、フレーム３が１番目［３７］で、など）。この実施形態では、ＢＣＳＦ４０２は、複数のＢＣＰフレームについて同じＢＬＥチャネル上でアナウンスメントパケットを待機し、したがって、構成同期状態にあるとき、ＢＣＣＦ４００から特定の動作は必要ではないと考えられ得る。一実施形態では、構成同期状態にあるときに、ＢＣＣＦ４００からの特定の動作が必要とされるか、またはオプションで利用されてもよいことを理解されたい。代替のＢＬＥベースの実施形態では、ブロードキャストチャネルはまた、ネットワーク輻輳（例えば、計算されたバックグラウンド電力、検出された衝突数、など）に基づいて選択されてもよく、そのようなラウンドロビン選択アルゴリズムは、混雑度の高いチャネルの使用頻度が少なくなる（または、全く使用されなくなる）ように、変更されてもよい。

代替のＢＬＥベースの実施形態では、ＢＣＣＦ４００が構成同期状態にあるとき、ＢＣＣＦ４００は、適切な期間（例えば、チャネルの総数の倍数、特定の期間、既知のセンサの全部またはサブセットからレスポンスが受信されるまで、など）の間、各ＢＣＰフレームについて同じチャネルでブロードキャストしつつ、４０個のＢＬＥ（データおよび／またはアドバタイジング）チャネルのうちの１つで、アナウンスメントパケットを選択してブロードキャストしてもよく、各ＢＣＳＦ４０２は、アナウンスメントパケットが取得されるまで、可能なチャネルのセットを循環する。

代替のＢＬＥベースの実施形態では、ＢＣＣＦ４００が構成同期状態にあるとき、ＢＣＣＦ４００は、適切な期間（例えば、セットのサイズの倍数、特定の期間、既知のセンサの全部またはサブセットからレスポンスが受信されるまで、など）の間、各ＢＣＰフレームのための各ブロードキャスト用の新しいチャネルを選択しつつ、４０個のＢＬＥ（データおよび／またはアドバタイジング）チャネルの１つ以上のセット上で、アナウンスメントパケットを選択してブロードキャストしてもよく、各ＢＣＳＦ４０２は、アナウンスメントパケットが取得されるまで、可能なチャネルのセットのうちの１つのチャネル上で待機する。

代替のＢＬＥベースの実施形態では、ＢＣＣＦ４００が構成同期状態にあるとき、ＢＣＣＦ４００は、適切な期間（例えば、セットのサイズの倍数、特定の期間、既知のセンサの全部またはサブセットからレスポンスが受信されるまで、など）の間、各ＢＣＰフレームのための各ブロードキャスト用の新しいチャネルを選択しつつ、４０個のＢＬＥ（データおよび／またはアドバタイジング）チャネルの１つ以上のセット上で、アナウンスメントパケットを選択してブロードキャストしてもよく、各ＢＣＳＦ４０２は、アナウンスメントパケットが取得されるまで、可能なチャネルのセットを循環する。

Ａ．３．ａ．１．ｂ アナウンスメントパケット−紛失と省略
通信媒体は信頼できない可能性があり、したがって、アナウンスメントパケットは特定のＢＣＳＦ４０２に到達しない可能性がある。アナウンスメントパケットは、ＢＣＣＦ４００によって定期的に送信されてもよく（例えば、すべてのＢＣＰフレームの開始時に、Ｎ秒またはＮ個のＢＣＰフレームごとに１回、など）、したがって、各ＢＣＳＦ４０２は、予定されたアナウンスメントパケットを見逃したかどうかを判定することが可能であり得る（例えば、カウンタを通して、最後の受領からの経過時間、など）。ＢＣＳＦ４０２が、多すぎるアナウンスメントパケット（例えば、３）を見逃したと判定した場合、未知のＢＣＰ構成状態（後述）に遷移してもよい。

いくつかのシステムでは、または同じシステム１００内の異なる時点で、アナウンスメントパケットは、（例えば、費されるネットワーク帯域幅を減らすために）ＢＣＰフレームの開始時にＢＣＣＦ４００によって送信されなくてもよい。例えば、既知のＢＣＳＦ４０２の全部またはサブセットが予定通りに通信している、および／または１つが最近送信された場合（すなわち、アナウンスメントパケットが時々、またはＢＣＰフレームの数毎に送信されなければならない実施形態において）、ＢＣＣＦ４００はアナウンスパケットを省略してもよい。アナウンスメントパケットがＢＣＰフレームに存在しない場合、ＢＣＳＦ４０２は、所定のおよび／または動的に選択された周波数／チャネルで通信してもよい（通信媒体に適用可能な場合）。

ＢＬＥベースの実施形態では、以前のアナウンスメントパケットの受信時に、およびＢＣＰフレーム内にアナウンスメントパケットがないときに、ＢＣＳＦ４０２は、（他で説明されるように）ＢＬＥ周波数ホッピングスケジュールによって、および／または（および／または、加えて）別のスケジュールおよび／またはアルゴリズムによって指示されるＢＬＥチャネル上で通信してもよい。

Ａ．３．ａ．ｌ．ｃ アナウンスメントパケット−ＢＣＳＦ
通信媒体に適用可能な場合、特定のＢＣＳＦ４０２は、対応するＢＣＣＦによって選択されたブロードキャスト周波数／チャネルを待機していないかもしれない（例えば、ちょうど電源が投入された、リセットされた、もはやＢＣＣＦ４００とは通信していないと判断されたため、または正しい周波数／チャネルでの待機を停止させた可能性がある他の何らかの事象［例えば、自己テスト失敗、コマンド、など］のため、またはそれらの理由の組合せのため）。この状態（未知ＢＣＰ構成状態）にあるとき、ＢＣＳＦ４０２は、特定の周波数／チャネル、周波数／チャネルのセット、または周波数／チャネルの全部またはサブセットで待機してもよい。待機する周波数／チャネルは、固定されていてもよいし、または、所定のシーケンス、ランダム化されたシーケンス、ネットワークの輻輳、または他の任意の方法、あるいは適切な方法の組み合わせを使用して選択されてもよい。

ＢＣＳＦ４０２は、同じ周波数／チャネル上で（例えば、受信されるまで無期限に、またはいくつかのＢＣＰフレームおよび／または時間などの、事前に定義されたおよび／またはアルゴリズム的に定義された期間）、異なるチャネル上で（例えば、ラウンドロビン方式で、または他のシーケンスで変更、ランダム、など）、および／または両方の組み合わせで、および／または他の方法で（例えば、ネットワーク衝突を軽減するための、ＢＣＣＦ４００がブロードキャストしている周波数／チャネルを探索するための、など）、アナウンスメントパケットを待機してもよい。

ＢＬＥベースの実施形態では、ＢＣＳＦ４０２が未知ＢＣＰ構成状態にあるとき、ＢＣＳＦ４０２は、所定のおよび／またはアルゴリズム的に決められ数のＢＣＰフレームの間、固定、ランダム、またはラウンドロビン方式にて、１つ以上のＢＬＥアドバタイジングチャネル上でアナウンスパケットを待機してもよい（例えば、３［可能性のあるチャネル数］、４、６、など）。例えば、１番目のアドバタイジングチャネル［３７］が、３つのＢＣＰフレームの間、観測され、２番目のアドバタイジングチャネル［３８］が、３つのＢＣＰフレームの間、観測され、３番目のアドバタイジングチャネル［３９］が、３つのＢＣＰフレームの間、観測され、１番目のアドバタイジングチャネル［３７］が、３つのＢＣＰフレームの間、観測される、など。

Ａ．３．ａ．ｌ．ｄ アナウンスメントパケット−フォーマット
アナウンスメントパケットは、転送を単純化するために他の基礎をなすプロトコルおよび／またはデータフォーマットを使用してもよい。アナウンスメントパケットはまた、他のプロトコルを待機している他のシステムが意図せずにアナウンスメントパケットを受信しないように、他のプロトコルとはわずかに異なっていてもよい。ＢＬＥベースの実施形態では、アナウンスメントパケットは、ＢＬＥアドバタイジングパケットに類似してもよく、および／またはそれによって引き起こされてもよい（および、類似または同じ基礎データおよび／または転送フォーマットを使用してもよい）。ただし、そのフォーマットおよび／または内容は、他のＢＬＥデバイスおよび／または受信機が受信しないように、意図的に異なっていてもよい。他のプロトコルのアドバタイジングパケットから、一意的なアナウンスメントパケットを使用することで、他のシステムが、そのようなセンサネットワークの存在を意図せずに観測することを防ぐことができる。代替の実施形態では、アナウンスメントパケットがＢＬＥアドバタイジングパケットと同じである。代替の実施形態では、アナウンスメントパケットが、コマンドパケットと組み合わされる。

Ａ．３．ｂ．コマンドパケット
コマンドパケットは、コマンドＢＣＣＦ４００から、構成されたＢＣＳＦ４０２の全部またはサブセットにブロードキャストされてもよい。ＢＣＣＦ４００は、ＢＣＳＦ４０２を含むことができ、したがって他のＢＣＣＦ４００は、コマンドパケットの受信者となることができることに留意されたい。コマンドパケットは、ＢＣＳＦ４０２にアクションを実行するように、および／またはコマンドＢＣＣＦ４００に応答を提供するように促すことができる。コマンドパケットは、構成情報（例えば、接続情報［例えば、センサ３１０がデバイス１１０からのメッセージを「傍受する」ことを可能にする「マイクロロケーション接続」情報］、セキュリティ情報、同期情報［時間を含む］、センサ構成／情報、ネットワーク情報、応答シーケンス情報、など）、コマンド情報（例えば、プロトコル開始／停止／リセット／再同期、システムリセット、セルフテストの実行、同期［例えば、時間、状態、アクティビティ／アクション、など］、など）、または他の情報（例えば、ファームウェアイメージの内容、システム状態、機器状態、など）、またはそれらの組み合わせを含むことができる。コマンドパケットは、１つ以上の特定のＢＣＳＦ４０２および／または１つ以上のクラスのＢＣＳＦ４０２をターゲットとすることができる。ＢＣＣＦ４００は、受信したコマンドパケットを、その構成されたＢＣＳＦ４０２に転送してもよい。コマンドパケットは、１つ以上のコマンド／要求を含むことができる。

ＢＬＥベースのシステムでは、ＢＣＳＦ４０２は、このパケットを用いて、計時の変化を補正することができる。

ＢＬＥベースのシステム（および他のシステムにも適用可能）では、衝突を回避するのを助けるために、ＢＣＣＦ４００は、最後のメッセージがデバイス１１０から受信された後（デバイス１１０への接続が存在する場合）、事前定義された遅延（例えば、３０ｍｓ）または動的な遅延（例えば、接続されたデバイス１１０の数、または以前の衝突カウントを含む、検出された環境特性に基づく）の後にコマンドパケットを送信してもよい。

コマンドパケットは、各ＢＣＳＦ４０２が通信することができるタイミングオフセット（例えば、タイムスロット）を含むことができる。

ＢＣＳＦ４０２の全部またはサブセットが予定通りに通信している場合、ＢＣＣＦ４００は、（例えば、帯域幅を維持するために）特定のＢＣＰフレームの間にコマンドパケットを送信しなくてもよい。

Ａ．３．ｂ．ｌ コマンドパケット−紛失と省略
通信媒体は信頼できない可能性があり、したがって、コマンドパケットは特定のＢＣＳＦ４０２に到達しない可能性がある。コマンドパケットは、ＢＣＣＦ４００によって定期的に送信されてもよく（例えば、すべてのアナウンスパケットの後に、ＢＣＰフレーム毎に、Ｎ秒またはＮ個のＢＣＰフレームごとに１回、など）、したがって、各ＢＣＳＦ４０２は、予定されたコマンドパケットを見逃したかどうかを判定することが可能であり得る（例えば、カウンタを通して、最後の受領からの経過時間、など）。ＢＣＳＦ４０２が、多すぎるコマンドパケット（例えば、３）を見逃したと判定した場合、未知のＢＣＰ構成状態（後述）に遷移してもよい。

Ａ．３．ｂ．２ 周波数ホッピングスケジュール設定
無線周波数通信の場合、干渉に対する耐性を強化または最大化するために、周波数変更方式がしばしば採用される。ＢＬＥでは、これは周波数ホッピングと呼ばれる。適応型周波数ホッピングは、（ＢＬＥによって使用されることができる）検出された衝突に基づいてホッピングスケジュールを調整するために使用されることができる。ホッピングスケジュールは、他の理由（例えば、デバイス１１０へのＢＬＥ接続が追加または削除された、システムリセット、など）のために変わる可能性がある。ＢＬＥベースのシステムでは、ＢＣＰは、ＢＬＥ通信と干渉しないようにするため、ＢＬＥ周波数ホッピングスケジュールに従う。

Ａ．３．ｃ．レスポンスパケット
ＢＣＣＦ４００からのコマンドパケットを受信および処理すると、ＢＣＳＦ４０２は、アクションを実行し、および／または応答することができる。応答は、事前定義された一時的なシーケンスで送信され得る。ＢＣＣＦ４００はＢＣＳＦ４０２を含むことができ、したがって他のＢＣＣＦ４００はコマンドパケットに対する応答者であり得ることに留意されたい。一時的な応答シーケンスは、各ＢＣＳＦ４０２に応答すべきタイムスロットを割り当てる。ＢＬＥベースのシステムでは、応答シーケンスは、現在の周波数ホッピング方式／設定に従って、応答するべきＢＬＥチャネルを各ＢＣＳＦ４０２にさらに割り当てることができる。このシーケンスは、最初のＢＣＳＦ４０２が、その割り当てられたタイムスロットでその応答を送信し、ＢＣＣＦ４００と通信するように構成された各ＢＣＳＦ４０２によって追随されることで始まり、その後、ＢＣＣＦ４００が新しいコマンドパケットを送信するまで繰り返される。

ＢＣＣＦ４００からのコマンドパケットを受信および処理した後に、またはそれに応答して、各ＢＣＳＦ４０２は、応答を送信する前に、システム１００内のその識別情報に基づいて時間遅延を適用してもよい。この遅延方式は、ＢＣＳＦ４０２が、衝突を回避しつつ、かつ、システム１００の総応答時間を最適化または向上させつつ、事前定義されたシーケンスで応答することを確実にするのを助けることができる。他の非ＢＬＥベースのシステムにも適用可能であるが、特にＢＬＥベースのシステムでは、この遅延方式はまた、通信媒体の帯域幅の使用を最小限にするために利用され得る。遅延設定はコマンドパケット内に含まれてもよい。

応答は、差し向けられ、および／またはブロードキャストされてもよい。応答は、システムスループットを向上させるために、複数の周波数を使用して応答を並行して送信されてもよい。

ＢＣＳＦ４０２は、コマンドおよび／またはアナウンスメントが受信されないＢＣＰフレーム中に応答を送信してもよい。例えば、ＢＣＳＦ４０２の全部またはサブセットが正常に通信している場合、ＢＣＳＦ４０２は測定値を送信し続けることを選択することができる。

Ａ．３．ｃ．１ レスポンスパケット−紛失と省略
通信媒体は信頼できない可能性があり、したがって、レスポンスパケットは特定のＢＣＣＦ４００に到達しない可能性がある。レスポンスパケットは、ＢＣＳＦ４０２によって定期的に送信されてもよく（例えば、すべてのコマンドパケットの後に、ＢＣＰフレーム毎に［例えば、マンドパケットが省略されたとしても、など］、Ｎ秒またはＮ個のＢＣＰフレームごとに１回、など）、したがって、ＢＣＣＦ４００は、特定のＢＣＳＦ４０２から予定されたレスポンスパケットを見逃したかどうかを判定することが可能であり得る（例えば、カウンタを通して、最後の受領からの経過時間、など）。ＢＣＣＦ４００が、特定のＢＣＳＦ４０２からの、多すぎるレスポンスパケット（例えば、３）を見逃したと判定した場合、ＢＣＣＦ４００は、次のＢＣＰフレームの間にアナウンスメントパケットを送信してもよい（例えば、ＢＣＣＦ４００がそれらを省略していた場合）。ＢＣＣＦ４００が、多すぎるＢＣＳＦ（例えば、３以上、複数の戦略的ＢＣＳＦ４０２、など）から、多すぎるレスポンスパケット（例えば、３）を見逃したと判定した場合、ＢＣＣＦ４００は、構成同期状態（上述）に移行してもよい。

Ａ．４．複数のＢＣＣまたはセンサハブ
場合によっては、ＢＣＳＦ４０２（すなわち、センサ３１０）間に大きな距離があるとき、ＢＣＳＦ４０２間に障害物があるとき、または特定のＢＣＣＦ４００が管理すべきＢＣＳＦ４０２が多すぎるとき、複数のＢＣＣＦ４００（すなわち、ＢＣＣおよび／またはセンサハブ１２１）を有することが有益であり得る。複数のＢＣＣＦ４００が存在するとき、ツリーネットワークが形成される。所定のＢＣＳＦ４０２は、冗長性を提供するように、２つ以上のＢＣＣＦのネットワーク内にあるように構成されてもよい。

Ａ．５．バックチャネルセキュリティ
ＢＣＳＦ４０２とＢＣＣＦ４００との間の通信は、安全であり得る（機密、完全性検証、または認証、またはそれらの組み合わせ）。

Ａ．５．ａ．アイデンティティ
各々の個々のセンサ３１０、センサハブ１２１、およびバックチャネルコントローラ１２０（すなわち、ＢＣＳＦ４０２）のアイデンティティは、１つ以上の固有の識別子（例えば、シリアル番号）および／または１つ以上の非対称鍵（公開鍵暗号）によって確立され得る。非対称鍵は、Ｘ．５０９証明書内に組み込まれてもよい。ＢＣＳＦ４０２とＢＣＣＦ４００との間の通信を認可または保護する、他の識別子および／または鍵および／または証明書が存在してもよい。

アイデンティティ識別子および／または鍵／証明書は、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０の製造中、あるいはそれらの組み合わせの間に決定および／または格納されてもよい。一実施形態において、鍵／証明書はアイデンティティを確立するために使用され、識別子は人間および／または他のシステムおよび／または補完鍵／証明書を支援するために使用される（例えば、特定のセンサ３１０のアイデンティティは鍵／証明書を検証することによって認証されるが、認証すべき鍵／証明書は、シリアル番号を使用してセットの中から選択され得る）。代替の実施形態では、アイデンティティ識別子および／または鍵／証明書は、システム組立中に、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせが、製造、組み立て、システムテストの間の、現場での（例えば、動的に）最初の使用に置かれ、またはシステムの寿命前またはその間の任意の他の時点に置かれる、あるいはそれらの組み合わせにおいて、機器の製造工程中に決定され、格納される。

代替の実施形態では、個々のアイデンティティ非対称鍵／証明書の代わりに、各ＢＣＳＦ４０２が、１つ以上のシステム全体の非対称鍵（Ｘ．５０９証明書内に組み込まれても組み込まれなくてもよい）を備えて構成される。鍵／証明書は、製造（例えば、コンポーネントの結合させるセットを製造）中に、システム組立（例えば、個々のコンポーネントが設置された後にセットを構成）時に、製造、組立、システムテストの間の、現場での（例えば、動的に）最初の使用時に、またはシステムの寿命前またはその間の任意の他の時点で、あるいはそれらの組み合わせにおいて、決定され、格納されてもよい。

代替の実施形態では、個々のアイデンティティ非対称鍵／証明書の代わりに、各ＢＣＳＦ４０２が、１つ以上のシステム全体の対称鍵を備えて構成される。鍵は、製造（例えば、コンポーネントの結合させるセットを製造）中に、システム組立（例えば、個々のコンポーネントが設置された後にセットを構成）時に、製造、組立、システムテストの間の、現場での（例えば、動的に）最初の使用時に、またはシステムの寿命前またはその間の任意の他の時点で、あるいはそれらの組み合わせにおいて、決定され、格納されてもよい。

代替の実施形態では、個々のアイデンティティ非対称鍵／証明書の代わりに、各ＢＣＳＦ４０２が、１つ以上の個々のアイデンティティ対称鍵を備えて構成される（そこにおいて、ＢＣＣＦの構成パッケージは各ＢＣＳＦ４０２のための適切な鍵を含む）。鍵は、製造中に、組立時に、製造、組立、システムテストの間の、現場での（例えば、動的に）最初の使用時に、またはシステムの寿命前またはその間の任意の他の時点で、あるいはそれらの組み合わせにおいて、決定され、格納されてもよい。

アイデンティティを確立または決定するため、個々の非対称鍵、システム全体の非対称鍵、システム全体の対称鍵、および個々の対称鍵を組み合わせる代替の実施形態が可能である。

代替の実施形態では、ＢＣＳＦ４０２／ＢＣＣＦ４００のアイデンティティを決定、確立、または認証するために、非対称鍵／証明書または対称鍵が必要とされない。

Ａ．５．ｂ．ネットワークの定義と認可
各ＢＣＣＦ４００は、０個以上のＢＣＦＳと通信することができ、各ＢＣＦＳは、０個以上のＢＣＣＦ４００と通信することができる。ＢＬＥベースのシステムでは、特定のシステム内のセンサ３１０、センサハブ１２１、およびバックチャネルコントローラ１２０の全部またはサブセットの間で、同じアクセスアドレスを使用することができる。アクセスアドレスは、製造中（センサセットを製造する場合または個々のセンサを製造する場合の両方）、システム組み立て中および／またはシステムテスト中、メンテナンス作業中（センサの追加または削除）、またはシステムの寿命の間の任意の他の時点で、供給され、修正されてもよい。有線システムでは、全部または一部のコンポーネントを同じバスに配線することができる。他の無線システムでは、全部または一部のコンポーネントは、同じ周波数、チャネル、スロット、などを使用するように構成されてもよい。特定のセンサネットワーク上で通信するセンサの能力は、そうすることを認可されていることを意味するものではない。

組み立てられたシステムのセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせは、個別にアドレス指定可能であってもなくてもよい。共通のアクセスアドレスが利用されるＢＬＥベースのシステムでは、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、またはそれらの組み合わせは、個別にアドレス指定可能ではない（すなわち、全部または一部の通信がブロードキャストされる）。しかしながら、メッセージングプロトコルは宛先フィールドを含むことができ、その場合、低レベル通信媒体は個別にアドレス指定可能ではないが、それでもメッセージは、センサ３１０、センサハブ１２１、またはバックチャネルセンサ３１０、あるいはそれらの組み合わせの個々またはグループにアドレス指定され得る。

各ＢＣＣＦ４００は、特定のセットのＢＣＳＦ４０２と通信することのみを認可されてもよい。ＢＣＣＦ４００が通信することを認可されている各ＢＣＳＦ４０２の公開鍵（または、公開証明書）、または任意の他の適切なアイデンティティ識別子／鍵／証明書は、図５の図示された実施形態に示されるように、ＢＣＣＦ４００に内在する構成パッケージに格納されてもよい。

各ＢＣＳＦ４０２は、特定のセットのＢＣＣＦ４００と通信することのみを認可されてもよい。ＢＣＳＦ４０２が通信することを認可されている各ＢＣＣＦ４００の公開鍵（または、公開証明書）、または任意の他の適切なアイデンティティ識別子／鍵／証明書は、ＢＣＳＦ４０２に内在する構成パッケージに格納されてもよい。

ＢＣＳＦ４０２は、それらが特定のＢＣＣＦ４００用のBCCF - Network - Key鍵を所有し、適切なアイデンティティが認証されている（次のセクションで説明）とき、その特定のＢＣＣＦ４００と通信することを認可される（すなわち、特定のＢＣＣＦ４００と通信するように構成されたＢＣＳＦ４０２のセットを含むまたはそのセットからなるセンサネットワークに参加する）。BCCF - Network - Keyは、特定のＢＣＣＦ４００への／からの通信を暗号化するために使用される対称鍵である（そして、それは対称鍵であり、したがって通信するための基本的な認可を提供するので、任意の認証ステップの前に使用されてもよい）。BCCF - Network - Keyは、システム（すなわち、特定の機器に据え付けられたセンサ３１０、センサハブ１２１、およびバックチャネルコントローラ１２０のセット）全体で共有されてもよく、またはシステム内の各センサネットワークに対して１つ存在してもよい。

代替の実施形態では、ＢＣＣＦ４００および／またはＢＣＳＦ４０２が、認可されたＢＣＦＳおよび／またはＢＣＣＦ４００のアイデンティティを列挙する構成パッケージを維持せず、その代わりに、BCCF - Network - Key鍵が、特定のＢＣＣＦ４００／ＢＣＳＦ４０２のペア間で通信するための唯一の認可として使用される。

BCCF - Network - Key鍵は、製造（例えば、コンポーネントの結合させるセットを製造）中に、システム組立（例えば、個々のコンポーネントが設置された後にセットを構成）時に、製造、組立、システムテストの間の、現場での（例えば、動的に）最初の使用時に、またはシステムの寿命前またはその間の任意の他の時点で、あるいはそれらの組み合わせにおいて、決定され、格納されてもよい。

代替の実施形態では、センサネットワークまたはシステム全体の間で共有されるBCCF - Network - Key鍵の代わりに、各ＢＣＳＦ４０２が、１つ以上の個別のBCCF - Network - Key鍵（そこにおいて、ＢＣＣＦの構成パッケージは、各ＢＣＳＦ４０２用の適切な鍵を含む）を備えて構成される。BCCF - Network - Key鍵は、製造中に、システム組立時に、製造、組立、システムテストの間の、現場での（例えば、動的に）最初の使用時に、またはシステムの寿命前またはその間の任意の他の時点で、あるいはそれらの組み合わせにおいて、決定され、格納されてもよい。

代替の実施形態では、BCCF - Network - Key鍵は、非対称鍵、またはＸ．５０９証明書である。

代替の実施形態では、BCCF - Network - Key鍵はまた、アイデンティティ鍵である（対称および非対称の実施形態の両方で［証明書の有無によらず］）。

BCCF - Network - Key鍵は、上述したように、周期的に、または特定のイベントで（例えば、システム内にセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０を追加または削除するとき、システム内にアクティビティがない、またはシステムのユーザがいないとき、など）循環してもよい。

Ａ．５．ｃ．認証
報告される情報が有効で、予想されるソースからのものであることを保証するために、各ＢＣＣＦ４００は、各ＢＣＳＦ４０２のアイデンティティを認証してもよいことは注目に値する。ＢＣＣＦ４００は、安全と見なされないＢＣＳＦ４０２からの通信を無視してもよい（以下の説明を参照）。ＢＣＣＦ４００は、（次のセクションで説明するように）電源投入時に、および／または事前定義されたおよび／または動的／イベント駆動の間隔で周期的に、各ＢＣＳＦ４０２のアイデンティティを認証してもよい。上述のように、ＢＣＳＦ４０２およびＢＣＣＦ４００は、１つ以上のBCCF - Network - Key鍵で暗号化された通信リンクを使用して互いに通信することができる。一旦、ＢＣＣＦ４００が特定のＢＣＳＦ４０２を認証すると、その通信リンクは、以下に説明されるように安全であると見なされ得る（BCSF - BCCF通信リンク）。一実施形態では、認証手法は、チャレンジ−レスポンスプロトコルを使用するＴＬＳサーバ側認証と同様であってもよい。

代替の実施形態では、相互認証が行われてもよく、その場合、各ＢＣＳＦ４０２は、（次のセクションで説明するように）電源投入時に、および事前定義されたおよび／または動的／イベント駆動の間隔で周期的に通信する各ＢＣＣＦ４００のアイデンティティを追加的に認証する。一実施形態では、認証手法は、チャレンジ−レスポンスプロトコルを使用したＴＬＳクライアント側認証と同様であってもよい。ＴＬＳと同様に、それはＢＣＳＦ４０２認証と同時に発生してもしなくてもよい。

代替の実施形態では、各ＢＣＳＦ４０２が、ＢＣＣＦ４００によって署名された証明書を備えて構成され、ＢＣＣＦ４００は、各ＢＣＳＦ４０２についての信頼チェーンを検証する（すなわち、各ＢＣＳＦ４０２が、通信可能である各ＢＣＣＦ４００によって署名された証明書を所有する）。そのような実施形態では、ＢＣＣＦ４００とＢＣＳＦ４０２との間の相互認証が必要とされない場合、各ＢＣＳＦ４０２が単にＢＣＣＦ署名の証明書を所有するだけなので、各ＢＣＳＦ４０２が、それ自体の一意のアイデンティティ鍵（対称または非対称）または証明書を所有する必要はなくてもよい。一実施形態では、認証手法は、証明書チェーン検証を使用するＴＬＳサーバ側認証と同様であってもよい。

代替の実施形態では、各ＢＣＣＦ４００が、ＢＣＳＦ４０２によって署名された証明書を備えて構成され、ＢＣＳＦ４０２は、各ＢＣＣＦ４００についての信頼チェーンを検証する（すなわち、各ＢＣＣＦ４００が、通信可能である各ＢＣＳＦ４００によって署名された証明書を所有する）。そのような実施形態では、ＢＣＳＦ４０２とＢＣＣＦ４００との間の相互認証が必要とされない場合、各ＢＣＣＦ４００が単にＢＣＳＦ署名の証明書を所有するだけなので、各ＢＣＣＦ４００が、それ自体の一意のアイデンティティ鍵（対称または非対称）または証明書を所有する必要はなくてもよい。一実施形態では、認証手法は、証明書チェーン検証を使用するＴＬＳクライアント側認証と同様であってもよい。

代替の実施形態では、相互認証が、上記の２つの代替実施形態を組み合わせることによって実行される。一実施形態では、認証手法は、証明書チェーン検証を使用するＴＬＳ相互認証と同様であってもよい。

代替の実施形態では、BCSF - BCCF通信リンクが、ＢＣＳＦ４０２を認証することなく安全であると見なされてもよい（すなわち、BCCF - Network - Key鍵が認可を示すとともに、通信を暗号化するために使用され、通信は完全性検証されるが、ＢＣＳＦ４０２／ＢＣＣＦ４００は認証されない）。

代替の実施形態では、BCSF - BCCF通信リンクが安全でなくてもよい（すなわち、ＢＣＳＦ４０２が認証されなくてもよく、および／または情報が暗号化されなくてもよく、および／または完全性が検証されなくてもよい）。

Ａ．５．ｄ．セッションキー
説明したように、そして図５の図示された実施形態に示すように（すなわち、Ｌ１、Ｌ２、およびＬ３）、各ＢＣＳＦ４０２は、安全な通信リンク（BCSF - BCCF通信リンク）を使用して、１つ以上の構成されたＢＣＣＦ４００と通信する。BCSF - BCCF通信リンクは、セッションキー（BCSF - BCCF - Session - Key）を使用して保護されてもよい。BCSF - BCCF - Session - Key鍵は、（ＴＬＳセッションキーと同様に）後述のチャレンジ−レスポンス認証プロセス中に計算される対称鍵であってもよい。BCSF - BCCF - Session - Keyは、BCCF - Network - Key鍵に加えて、または、BCCF - Network - Key鍵の代わりに、認証されたＢＣＳＦ４０２／ＢＣＣＦ４００のペアに対して使用され得る。BCSF - BCCF - Session - Key鍵はまた、BCCF - Network - Key鍵と同じであってもよいし、またはBCCF - Network - Key鍵の派生物であってもよく、その場合、BCSF - BCCF - Session - Key鍵は、以下で説明するチャレンジ−レスポンス認証プロセスの間に計算されず、代わりに、BCCF - Network - Key鍵、またはその派生物が使用される（すなわち、BCSF - BCCF - Session - Key鍵は使用されなくてもよいし、またはBCCF - Network - Key鍵に基づきアルゴリズムを使用して計算されてもよい）。システムの制約のあるコンポーネントで、システム性能および応答性を向上させるために、BCSF - BCCF - Session - Key鍵が、（ＴＬＳセッション再開と同様の方法で）接続を存続させるとともに、本明細書で説明するように周期的に循環されてもよい。

Ａ．５．ｄ．ｌ チャレンジ−レスポンス
BCSF - BCCF - Session - Key鍵は、ＴＬＳ／ＤＴＬＳと同様のチャレンジ−レスポンス認証プロセスの間に、アイデンティティおよび／または他の適切な鍵（対称または非対称）および／または証明書を使用して、または２０１６年１０月２７日に出願され、「デバイスを認証および認可するための、および／または鍵を配布するためのシステムおよび方法」と題する、Smithらの米国仮特許出願第６２／４１３９６６号−その記載は、その全体が参照により本明細書に組み入れられる−に記載された１つ以上の実施形態に従って、または任意の他の適切な方法によって、各ＢＳＣＦ／ＢＣＣＦのペアについて導出することができる。

チャレンジ−レスポンス認証プロセスは、ブロードキャストコマンドを使用して、または個々の指示されたメッセージによって、用いることができる。チャレンジ−レスポンス認証プロセスはまた、システムの認証方式に適切なように、システムによって使用されるメッセージング方式に統合されてもよい（例えば、システム認証方式が認証されるべきであることを示すＢＣＣＦ４００／ＢＣＳＦ４０２から送信される各メッセージに対して、送信器は、送信される各メッセージと共に、受信器からの以前の応答から送信器が受信した暗号化ノンスを含めることができ［ゼロまたはその他の既知の値にブートストラップされた］、および、ブロードキャストメッセージに対しては［あるいは、メッセージの全部またはサブセットの暗号化ノンスの代わりに］、送信されたメッセージの署名［またはその一部］、あるいはその他の該当するチャレンジ−レスポンスプロトコルの場合、メッセージ認証コード、または他の技術［利用される鍵および/または証明書に適した］、など）。

コマンドパケット（セクションＡ．３．ｂに記載）などのブロードキャストメッセージは、複数のＢＣＳＦ４０２によって受信されることができ、したがって、BCCF - Network - Key鍵のみを使用して保護され得る。BCCF - Network - Key鍵または他の適切な鍵が、特定のＢＣＣＦ４００と通信するＢＣＳＦ４０２間で共有されない代替実施形態では、ブロードキャストメッセージが、特定のＢＣＣＦ４００（および／またはシステム）と通信するＢＣＳＦ４０２間で共有されるブロードキャスト固有のBCCF - Network - Key鍵（例えば、BCCF - Network - Broadcast - Key鍵）を使用して保護されてもよいし、別の共有識別子または鍵によって保護されてもよいし、または保護されなくてもよい。他の箇所で説明されているように、ブロードキャストメッセージに対する応答、および他のダイレクトメッセージは、BCSF - BCCF通信リンクを使用して通信される。

ＢＬＥベースのシステムの実施形態では、システム全体のBCCF - Network - Key鍵が、システム内のBCSF - BCCF通信リンクの全部またはサブセットにわたって通信を保護するために使用される。ＢＣＳＦ４０２のアイデンティティは、コマンド／レスポンスベースのチャレンジ−レスポンスプロトコルを用いて認証される。追加のセッションキーは利用されないので、ＢＣＳＦ４０２は他のＢＣＳＦ４０２からのデータを集めることができる（本明細書で説明されるように）。

ある実施形態では、Ｐ−１９２（ｓｅｃｐ１９２ｒ１）楕円曲線（非対称）暗号（ＥＣＣ）が使用される。ある実施形態では、Ｐ−２５６（ｓｅｃｐ２５６ｒｌ）楕円曲線（非対称）暗号（ＥＣＣ）が使用される。ある実施形態では、Ｐ−３８４（ｓｅｃｐ３８４ｒ１）楕円曲線（非対称）暗号（ＥＣＣ）が使用される。ある実施形態では、Ｐ−５２１（ｓｅｃｐ５２１ｒｌ）楕円曲線（非対称）暗号（ＥＣＣ）が使用される。ある実施形態では、ＲＳＡ（非対称）暗号が使用される。ある実施形態では、ＡＥＳ−１２８（対称）暗号が使用される。ある実施形態では、ＡＥＳ−１９２（対称）暗号が使用される。ある実施形態では、ＡＥＳ−２５６（対称）暗号が使用される。

Ａ．６．サイドチャネル通信
システム内に複数のバックチャネルコントローラ１２０またはセンサハブ１２１が存在する場合、本開示による一実施形態は、互いに通信するために、それらのうちの２つ以上を利用することができる。例えば、図６の図示の実施形態を参照されたい。エラー。参照元が見つからない。

サイドチャネルは、デバイス１１０が、他の関連するセンサハブ１２１およびバックチャネルコントローラ１２０への再接続を要求したり、またはそれらの存在に気づいたりすることを防止するために、１つのセンサハブ１２１またはバックチャネルコントローラ１２０から、別のものへ接続情報を転送するために（すなわち、「マイクロロケーション接続」を一方から他方に転送するために）使用することができる。サイドチャネルは、バックチャネルを使用して提供されてもよい（すなわち、それらは同じセンサネットワークであってもよく、および／または同じまたは類似の概念を使用してもよい）。
Ａ．６．ａ．サイドチャネルセキュリティ

１つ以上のサイドチャネル（ＢＣＣＦ−ＢＣＣＦ）セキュリティコンセプトは、１つ以上のバックチャネルセキュリティコンセプト（セクションＡ．５を参照）と同様であってもよい。サイドチャネルおよびバックチャネルアイデンティティ鍵および／または証明書は同じであってもよい。通信を保護するために使用される、サイドチャネルおよびバックチャネル鍵（対称および／または非対称）および／または証明書は異なっていてもよく、異なるように計算されてもよい。例えば、ＢＣＣＦ−Ａのためのバックチャネルは、システム全体の対称暗号鍵Ｋ１を使用可能であり、ＢＣＣＦ−Ｂはシステム全体の対称暗号鍵Ｋ２を使用可能であるが、ＢＣＣＦ−ＡからＢＣＣＦ−Ｂへは、チャレンジ−レスポンス認証プロトコルの一部として計算される接続固有対称暗号鍵Ｋ３を使用してもよい。

Ａ．７．バックチャネル動作モード
ある実施形態では、バックチャネルが、いくつかの動作モードを有することは有益であり得る。これらのモードは、システムの特性を最小化、最大化、増進または減少させるのを助けるために使用することができる。例えば、「スリープ」および／または「スタンバイ」モードに入ることは、電力消費の観点から有益であり得る。バックチャネルモード間の切り替えは、いくつかのシステムリソースによって、タイミングによって、外部入力によって、または他の何らかの方法によって、そうするように命令されるなどの方法によって達成されてもよい。

Ａ．８．複数デバイスのマイクロロケーション
マイクロロケーションシステムは、複数のデバイス１１０を同時にマイクロロケーションすることができる。このシステムは、２０１５年２月１２に出願され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国非仮出願第１４／６２０９５９号、および２０１６年４月１５に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittらの米国仮出願第６２／３２３２６２号に記載されている１つまたは複数の実施形態と併せて実行されてもよく、それらの開示は、その全体が参照により本明細書に組み入れられる。バックチャネルおよびサイドチャネル通信は、複数のデバイス１１０に関する同時情報の転送をサポートすることができる。

Ａ．９．バックチャネルとサイドチャネルの測定
マイクロロケーションシステム（センサ３１０、センサハブ１２１、もしくはバックチャネルコントローラ１２０、またはそれらの組み合わせ）は、セクションＡ．２に記載されているように、主として、デバイス１１０に送信されるまたはデバイス１１０から受信される信号の属性を測定する。（セクションＡ．３および他のセクションに記載されるような）バックチャネル通信および（セクションＡ．６に記載されるような）サイドチャネル通信の一部として、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、またはそれらの組み合わせが、メッセージを相互に送信することができる。これらのメッセージは、デバイス１１０からのメッセージが測定および／または処理されるのと同じ方法で測定および／または処理され得る（すなわち、情報および／または信号属性が、他のセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせに送信される、またはそれらから受信される、１つ以上のセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせのバックチャネルおよび／またはサイドチャネル通信から、測定、計算、処理、または変換され、あるいはそれらの組み合わせが行われ得る）。

バックチャネルおよび／またはサイドチャネル通信における環境の影響を測定する能力は、ＲＦ（例えば、ＢＬＥ）、超音波、または同様のバックチャネルおよび／またはサイドチャネルの使用に基づくことができ、そこにおいて、本明細書に記載されるように、通信特性が、システムが配置されている環境によって影響を受けるセンサ３１０、センサハブ１２１、およびバックチャネルコントローラ１２０の間で測定されることができ、システムが前記環境を評価することを可能にする。各ＢＣＣＦのセンサネットワークは完全に接続されており、各センサ３１０、センサハブ１２１、またはＢＣＣ１２０、あるいはそれらの組み合わせが、すべての他のセンサ３１０、センサハブ１２１、またはＢＣＣ１２０、あるいはそれらの組み合わせから送信／受信される、（アナウンスメントパケット、コマンドパケット、またはレスポンスパケット、あるいはそれらの組み合わせを含む）すべてのメッセージの属性を測定することを可能にし、各センサ３１０、センサハブ１２１、またはＢＣＣ１２０、あるいはそれらの組み合わせが、各ＢＣＰフレーム内の各メッセージについて、おおよそ追加のＮ＊（Ｎ＋２）回の測定機会を提供しつつ、ここで、Ｎはセンサ３１０の数である、すべてのメッセージについてネットワーク内のそれらの位置での測定値を生成することを可能にする（例えば、８センサシステムでは、ＢＣＰフレームごとのパケットごとに、追加の８０回の測定機会が作られる［２０Ｈｚで、１秒当たり１６００回の機会］）。有線、光学、または類似のバックチャネルおよび／またはサイドチャネルでは、システムが配置されている環境は通信特性にほとんど影響を与えない。

バックチャネルおよび／またはサイドチャネル通信を測定および／または処理することから得られる情報は、１つ以上のデバイス１１０のマイクロロケーションを援助するために、バックチャネルおよび／またはサイドチャネル通信を介して、通信され、および／または、他のバックチャネルおよび／またはサイドチャネル情報と組み合わされてもよい。例えば、この情報により、システムは、それがどのような種類の環境に存在するか、近くの障害物または物体の存在（または不存在）、異なるシステムコンポーネントの相対性能（例えば、絶対的、既知のベースラインに対して相対的、互いに対して相対的、など）、などについて決定することが可能となる。ＢＬＥベースのシステムでは、他のセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせからの送信から受信されるように、各センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、またはそれらの組み合わせでＲＳＳＩを観測することにより、システムは、それが高ノイズ（ＲＦ）または高バックグラウンド電力（ＲＦ）環境にあるのか、高反射環境内にあるのか、障害物（例えば、人体、別の車両）がシステムコンポーネントの間または近くに存在するのか決定することが可能となる。

バックチャネルおよび／またはサイドチャネル通信を測定および／または処理することから得られる情報は、情報および／または信号を収集および／または処理するため、通信速度を増加または減少するため、情報がネットワークを介して伝播される方法を変更するため（すなわち、障害物を迂回する、冗長性を追加する、メッシュトポロジに切り替える、許容誤差を緩和する、追加の誤り訂正符号および／または方法を追加する、メッセージを再試行／再送信する、など）、センサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせの送信電力を増加または減少するため、もしくは、様々なフィルタおよび／またはアルゴリズム内で、特定のセンサ３１０、センサハブ１２１、またはバックチャネルコントローラ１２０、あるいはそれらの組み合わせに関する特定の測定値および／または属性の重みを変更するため、などに使用されるアルゴリズムを調整するように、バックチャネルおよび／またはサイドチャネル通信内で使用されてもよい。

バックチャネルおよび／またはサイドチャネル通信を測定および／または処理することから得られた情報はまた、環境特有のマイクロロケーションアルゴリズムを選択する、低い確率および／または不確実な測定値および／または計算を除去するために環境知識をマイクロロケーションアルゴリズムに統合する、システムに対して近くの（または特定の場所内の）障害物の存在を通信するため、マイクロロケーションアルゴリズムおよび／またはそれらのアグリゲータ／コンバイナへの様々な入力および／またはそれらからの出力に与えられる重みを変更する、などのような、システムレベルの挙動を変えるために、デバイス１１０通信の測定および／または処理と組み合わされてもよい。

バックチャネルおよび／またはサイドチャネル通信は、デバイス１１０がなくても発生可能であり、したがって、バックチャネルおよび／またはサイドチャネル通信を測定および／または処理することから得られる情報によって、システムはデバイス１１０がなくても関連情報を取得することが可能となる。例えば、ＢＬＥベースのシステムでは、この方法は、通信デバイス１１０が存在しなくても、システムがバックグラウンド電力を決定することを可能とする。

Ａ．１０．バックチャネルおよびサイドチャネル送信電力
本明細書で説明されるように、バックチャネルおよび／またはサイドチャネルは、バックチャネルおよび／またはサイドチャネル通信から取得される情報に基づいて、（適用可能である場合）それらの送信電力を調整することができる。

Ａ．１１．センサ応答のカスケードと中継
センサ３１０の応答をカスケードおよび中継する方法を使用して、デバイス１１０のマイクロロケーションに関連するセンサ３１０のデータを通信するのに必要と考えられる全体の時間を最小化または短縮するとともに、センサ３１０からの測定データの転送に対する障害を克服することができる。全体的に短縮された通信時間のさらなる利点は、１つ以上のセンサ３１０の測定値が送信中に失われた場合に、別のデータセットがより早く利用可能になることである。

センサ中継を伴わない、典型的な非カスケード実装では、メッセージがセンサにブロードキャストされ、センサからの応答が１つずつ受信される。以下の説明では、ブロードキャストされるメッセージは、測定を行うセンサ３１０を起動するために使用されると仮定する。例えば、図７の図示された実施形態を参照されたい。

縦軸に時間が表示されているものとし、このブロードキャストは図７の１番目の横線として示されている。ブロードキャストメッセージに続いて、センサ３１０からバックチャネルコントローラ１２０へ応答が１つずつ送信される。

同時転送の機会は、全体の応答時間の短縮を容易にすることができる。バックチャネルが無線周波数を介して実装されるシステムの場合、可能であるＢＬＥシステムの場合と同様に、複数のセンサが異なる周波数で同時に送信することができることは、センサ計測データの全部またはサブセットを収集するのに必要とされる全体時間の短縮を容易にすることができる。図８の図示された実施形態で分かるように、同時通信を可能にするために、２つの周波数（周波数ＡおよびＢ）がセンサによって使用されてもよい。

同様に、センサがそれ自身の測定データを保持するだけでなく、他のセンサ測定データを中継（受信、記憶、および転送）することができることは、センサ測定データの全部またはサブセットを収集するのに必要とされる全体時間を短縮するのに役立ち得る。図８の図示された実施形態で分かるように、センサ１が周波数Ａを介してバックチャネルコントローラ１２０にその測定データを通信している間に、センサ２はセンサ３から（周波数Ｂを介して）測定データを受信する。センサ２がバックチャネルコントローラ１２０に（周波数Ａを介して）送信するとき、それは、センサ３からの中継測定データと共に、その測定データを送信している。また、センサ３１０の測定データを、位置決定設備に引き渡す前に、中継（受信、記憶、および転送）するために、センサハブ１２１が使用されてもよいことに留意されたい。

図８の図示された実施形態に示すように、センサ３１０データのカスケードおよび中継を採用することによって、３Ｔから２Ｔ時間単位へのデータ収集時間全体の短縮を図ることができる。時間全体のより劇的な短縮は、データ収集時間全体が７Ｔ時間単位から３Ｔ時間単位に短縮されている、図９の図示された実施形態において見られることができる。

以下の利用可能性は、センサ３１０の測定値の全部またはサブセットを受信するのに必要とされる時間の全体的な減少に影響を与えるであろう。
・バックチャネルコントローラ１２０またはセンサハブ１２１が同時に受信することができるチャネルの数。
・センサ３１０がセンサ３１０の通信に利用可能な通信チャネルの数。
・センサ３１０を介して中継（受信、記憶、および転送）することができるセンサ測定データのセットの数。

センサ３１０の測定データの中継が可能であることは、センサ３１０がバックチャネルコントローラ１２０またはセンサハブ１２１への信頼できるまたは実用的な通信経路を持たない状況を克服する方法を提供する。この解決策は、バックチャネルコントローラ１２０またはセンサハブ１２１への信頼できるまたは実用的な通信経路を持たないセンサ３１０へメッセージを送信する、バックチャネルコントローラ１２０またはセンサハブ１２１の能力を含み得ることに留意されたい。一実施形態では、１つ以上のセンサ３１０が、信頼性を高めるために、バックチャネルコントローラ１２０またはセンサハブ１２１のブロードキャストメッセージを複製してもよい。例えば、例示のタイミングについての図１０、および図１１Ａ−１１Ｄの図示された実施形態を参照されたい。前述のように、１つ以上のセンサ３１０は、１つ以上の他のセンサ３１０から受信した測定データを中継することができる。どのセットのセンサ３１０がどのセットの測定データを通信するかは、例えば、所望の性能、所望の信頼性、センサ３１０の接続性、利用可能な帯域幅、および／またはセンサ３１０からコントローラ１２０またはセンサハブ１２１への通信リンクのスループットなどの多くの要因に基づいて、システムごとに異なり得る。センサ３１０からコントローラ１２０またはセンサハブ１２１への通信リンクが、適切な帯域幅および／またはスループットを有する一実施形態では、すべてのセンサ３１０が、すべて他のセンサ３１０からのすべての測定データを中継してもよい。センサ３１０からコントローラ１２０またはセンサハブ１２１への通信リンクが、帯域幅および／またはスループットに制約がある別の実施形態では、１つまたは２つのセンサ３１０のみが、１つまたは２つの他のセンサ３１０から受信した測定データを中継してもよい。さらに、前述のように、測定データは、複数の周波数を使用することによって、センサ３１０、コントローラ１２０、および／またはセンサハブ１２１の間で実質的に同時に通信されることができ、したがって測定データ転送性能を改善することができる。そのような手法は、上記のものを含む任意の中継を行う実施形態で使用されてもよい。代替の実施形態では、複数の周波数を使用してセンサ３１０、コントローラ１２０、および／またはセンサハブ１２１の間で同時に（並列に）測定データを通信する代わりに、センサ３１０は、コントローラ１２０またはセンサハブ１２１との通信に使用される同じ周波数を使用して、他のセンサ３１０から測定データを受信してもよい（すなわち、センサ３１０が複数の周波数で測定データを並行して送信する代わりに、各センサ３１０は、それぞれの他に構成されたセンサ３１０が測定データをコントローラ１２０またはセンサハブ１２１に送信するときに、そのセンサ３１０からの測定データを単に受信する［例えば、傍受する］）。

Ａ．１２．非信頼性と再試行
センサ３１０に送信される測定を実行するためのコマンドは、要求された測定データを提供するセンサ３１０による以外には確認されない。測定は非常に高速で行われ、欠けているデータは重要ではないと考えられるので、この確認の欠如、および測定データの損失の可能性は許容できると考えられる。バックチャネルコントローラ１２０は、いずれかの失われたパケットから回復するための再試行を発行してもよく、必要なときにバックチャネルをより信頼できるものにすることができる。センサの再構成、スケジューリングの変更、およびファームウェアのダウンロードの実行は、再試行が必要になる可能性が高い場合の例である。

Ａ．１３．共有センサ
特定の状況下では、センサ３１０が、２つ以上のセンサハブまたはバックチャネルコントローラ１２０に通信することが有益であるかもしれない。例えば、図１２の図示された実施形態を参照されたい。

Ｂ．実施形態
以下の実施形態は、開示されるシステムおよび方法のいくつかの可能な使用法および実施例を例示する。

概して、開示されるシステムおよび方法は、任意のマイクロロケーションシステム、特に、ＢＬＥベースのシステムだけでなく、ＵＷＢ、超音波、ＩＥＥＥ８０２.１５.４内で具現化されてもよい。そのようなシステムは、多くの用途内でさらに具体化することができ、そのうちのいくつかは参照される開示の中で特定されることができる。

Ｂ．１．デバイスがセンサに接続する実施形態
この実施形態では、デバイス１１０が、オプションとして無線周波数方法を使用して、直接的にセンサへの接続を開始する。これは、マイクロロケーションシステムで使用される伝統的な方法であり、それによって、デバイス１１０は個別にセンサ３１０に接続する。デバイス１１０が接続した後、センサ３１０は、オプションとして受信信号強度インジケータ（ＲＳＳＩ）を取得することによって、デバイス１１０への大まかな近接性を判断することができる。蓄積されたＲＳＳＩ情報は、デバイス１１０のマイクロロケーションを決定するために、デバイス１１０によって、通信、収集、および分析されてもよい。バックチャネル（すなわち、各センサ３１０と通信するバックチャネルコントローラ１２０）を追加することで、センサ３１０は、蓄積して分析するために、バックチャネルコントローラ１２０にも情報を送信することができる。しかしながら、各デバイス１１０は依然として各センサ３１０に個別に接続している。そのようなマイクロロケーションシステムに適用される例示的なバックチャネルシステムおよび方法は、図１３の図示された実施形態において以下に提供される。

Ｂ．２．センサがデバイスに接続する（従来とは反対の）実施形態
この実施形態では、センサ３１０が、オプションとして無線周波数方法を使用して、直接的にデバイス１１０への接続を開始する。デバイス１１０に接続した後、センサ３１０は、オプションとして受信信号強度インジケータ（ＲＳＳＩ）を取得することによって、デバイス１１０への大まかな近接性を判断することができる。蓄積されたＲＳＳＩ情報は、デバイス１１０のマイクロロケーションを決定するために、デバイス１１０によって、通信、収集、および分析されてもよい。バックチャネル（すなわち、各センサ３１０と通信するバックチャネルコントローラ１２０）を追加することで、センサ３１０は、蓄積して分析するために、バックチャネルコントローラ１２０にも情報を送信することができる。しかしながら、各センサ３１０は依然として各デバイス１１０に個別に接続している。そのようなマイクロロケーションシステムに適用される例示的なバックチャネルシステムおよび方法もまた、図１３の図示された実施形態に関連して説明される。

Ｂ．３．デバイスからＢＣＣへの通信を傍受するセンサの実施形態
２０１６年４月１５日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国仮出願第６２／３２３２６２号−その開示は、その全体が参照により本明細書に組み入れられる−に記載されている１つ以上の実施形態と併せて実行され得る、この実施形態では、センサ３１０が、１つ以上のデバイス１１０と１つ以上のマイクロロケーション接続設備（ＭＣＦ４１０）との間のＲＦ通信を「傍受する」ために使用される。マイクロロケーションシステムは、確立されたＭＣＦからデバイスへの接続を監視し、ＲＳＳＩおよび他の情報を蓄積するセンサ３１０に基づくことができる。蓄積された情報は、１つ以上のデバイス１１０のマイクロロケーションを決定するために、１つ以上のセンサ３１０、センサハブ、またはバックチャネルコントローラ１２０、あるいはそれらの任意の組み合わせにおける１つ以上の位置決定設備（ＬＤＦ）によって、バックチャネルおよび／またはサイドチャネルを使用して、通信、収集、処理、変換または分析、あるいはそれらの任意の組み合わせが行われる。

そのようなマイクロロケーションシステムに適用される例示的なバックチャネルシステムおよび方法が、図１４の図示された実施形態に示されている。

ＢＬＥハードウェアベースの無線バックチャネルおよびサイドチャネルを有する、「傍受する」ＢＬＥベースのマイクロロケーションシステムの実施形態がある。

ＢＣＣ１２０と携帯デバイス１１０との間の通信および接続パラメータ、ならびに１つ以上のセンサ３１０において、通信を監視または傍受することは、様々な方法で実施することができる。
一実施形態では、携帯デバイス１１０とＢＣＣ１２０との間の通信リンク上で初期接続を確立することに基づいて通信が行われてもよく、その場合、（接続パラメータは、ＢＣＣ１２０によって提供され得るし、または接続の確立時に取り決められ得るが）携帯デバイス１１０が接続パラメータを提供する。そして、初期接続が確立された後、ＢＣＣ１２０は通信リンク上で基本接続を取り決めることができ、その場合、ＢＣＣ１２０は接続パラメータを提供する（または、携帯デバイス１１０と接続パラメータを取り決める）。基本接続が確立された後、マスタデバイス１１０と携帯デバイス１０は初期接続を切断することができる。１つ以上の実施形態において、初期接続が基本接続として利用されてもよいことを理解されたい。一実施形態において、接続パラメータは、携帯デバイス１１０とＢＣＣ１２０との間のＢＬＥ接続のための接続スケジュールを定義してもよい。

接続パラメータおよびスケジュールパラメータなどの、ブルートゥースＬＥの分野における通信リンクに関するパラメータの例は、以下のパラメータの１つ以上を含むことができる。
・接続ステータス−接続またはタイムアウト
・接続間隔
・接続スリープクロック精度
・中央またはマスタが各接続イベントに許容する最長接続イベントウィンドウ
・接続周波数ホップ間隔
・接続適応型周波数ホッピングチャネルマップ
・接続スレーブ待ち時間
・接続監視タイムアウト期間
・接続ＣＲＣ初期設定値
・中央および周辺アクセスアドレス、またはマスタデバイスおよび携帯デバイスアクセスアドレス
・一時接続鍵
・長期接続鍵

接続パラメータは、ＢＣＣ１２０からセンサデバイス３１０へのように、１つのシステムコンポーネントから別のものへ接続の情報を渡すために利用されてもよい。これらの接続パラメータを使用して、センサデバイス３１０は、ＢＣＣ１２０と携帯デバイス１１０との間の通信リンクを介して送信される通信を監視または傍受することができる。監視される通信は、ＢＣＣ１２０および／または携帯１１０から送信されてもよい。

Ｂ．４．センサデータ無し／制御システムの実施形態
この実施形態では、バックチャネルおよび／またはサイドチャネルは、初期構成データ、進行中のコマンド（制御コマンドおよび／または制御システムからのフィードバックなど）、およびセンサ３１０、センサハブ、およびセンサ３１０を横断する他の非測定情報を通信するために使用される。

Ｂ．５．物性を通信するセンサの実施形態
この実施形態では、センサ３１０は、熱、圧力、光、または運動などの何らかの物理現象を測定するために使用され得る。場合によっては、センサによって測定されている物理的特性が急速に変化する。センサが、物理現象の状態を同期して捕捉し、測定値を中心部に伝達することを確実にするため、そのようなマイクロロケーションシステムに適用される例示的なバックチャネルシステムおよび方法もまた、図１５の図示された実施形態に関連して説明される。この中心部は、測定情報を記録するか、または測定情報に基づいて何らかのアクションを開始することができる。

本開示は、マイクロロケーションシステムにおいて分散されたセンサと同期し、監視し、そして、特に無線で通信するための方法の１つ以上の実施形態を提供する。

本明細書の１つまたは複数の実施形態で説明されたように、本開示による実施形態は、標準ＢＬＥプロトコルに差し挟まれる通信を用いて、各ノードで単一の無線のみを使用するセンサネットワークを組み立てることを可能にする。さらに、バックチャネルプロトコルの効率性のため、マイクロロケーションをさらにサポートする追加の環境情報とともに、センサデータを適時に取得することができる。

本開示は、主にＢＬＥおよびＢＬＥハードウェアと共に使用するために説明されている。しかしながら、それは任意の通信媒体（有線および／または無線）に適用することができる。他の無線プロトコルは、ＵＷＢを含め、その用途に適している。

「垂直」、「水平」、「上」、「下」、「上方」、「下方」、「内側」、「内側へ」、「外側」および「外側へ」などの方向を示す用語が、図示された実施形態の方向に基づいて本発明を説明するのを助けるために使用される。方向を示す用語の使用が、本発明をいずれかの特定の方向に限定するものと解釈されるべきではない。

上記の説明は、本発明の現在の実施形態の説明である。均等論を含む特許法の原則に従って解釈されるべき、添付の特許請求の範囲に定義される本発明の精神および広範な態様から逸脱することなく、様々な変更や変化がなされることができる。本開示は、説明の目的のために提示されたものであり、本発明のすべての実施形態の包括的な説明として解釈されるべきではなく、または請求の範囲をこれらの実施形態に関連して図示または説明される特定の要素に限定するものでもない。例えば、限定するものではないが、記載された発明の任意の個々の要素は、実質的に同様の機能を提供するか、さもなければ適切な動作を提供する代替要素によって置き換えることができる。これには、例えば、当業者に現在知られているような、現在知られている代替要素、および開発時に当業者が代替要素として認識するような、将来的に開発される代替要素が含まれる。さらに、開示された実施形態は、共に説明され、協力して利点の集まりを提供する複数の特徴を含む。本発明は、発行された特許請求の範囲に明示的に記載されている場合を除き、これらの特徴の全てを含む、または、記載された全ての利点を提供する実施形態のみに限定されない。例えば、冠詞「a」、「an」、「the」または「said」を使用する、単数形での請求項要素を参照することは、その要素を単数に限定するものとして解釈されるべきではない。「Ｘ、ＹおよびＺのうちの少なくとも１つ」としての請求項要素に対する言及は、個々にＸ、ＹまたはＺのいずれか１つ、およびＸ、ＹおよびＺの任意の組み合わせ、例えばＸ、Ｙ、Ｚ；Ｘ、Ｙ；Ｘ、Ｚ：Ｙ、Ｚを含むことを意味する。

Claims (53)

1. コントローラデバイスと携帯デバイスとの間の通信に関するセンサ情報を収集する方法であって、
   通信プロトコルに従って、コントローラデバイスと携帯デバイスとの間の通信リンクに関する１つ以上の接続パラメータを送信すること、
   少なくとも１つのセンサデバイスにおいて、１つ以上の接続パラメータを受信すること、
   接続間隔で、コントローラデバイスと携帯デバイスとの間の通信リンクを介して、データを繰り返し通信すること、
   少なくとも１つのセンサデバイスにおいて、接続間隔中に、コントローラデバイスと携帯デバイスとの間の通信の１つ以上の特性を検知すること、および、
   １つ以上の検知特性に関するセンサ情報を、接続間隔内のギャップ時間フレーム内で送信すること、を備える方法。
2. ギャップ時間フレームは、ａ）接続間隔中のコントローラデバイスと携帯デバイスとの間の通信の終了と、ｂ）次の接続間隔の開始との間に定義される請求項１に記載の方法。
3. ギャップ時間フレームは、ａ）接続間隔中の携帯デバイスから送信される通信の終了と、ｂ）接続間隔の終了との間に定義される請求項２に記載の方法。
4. ギャップ時間フレームは、携帯デバイスの通信の時間フレームの間に定義される請求項１に記載の方法。
5. 複数のセンサデバイスとの通信が、接続間隔の複数のギャップ時間フレーム内において提供される請求項１に記載の方法。
6. アナウンスパケットおよびコマンドパケットが、携帯デバイスが通信する前の接続間隔の開始時に定義される、前記複数の中の第１のギャップ時間フレームにおいて提供され、センサ情報が、第１のギャップ時間フレームの後にある、前記複数の中の第２のギャップ時間フレームにおいて提供される請求項５に記載の方法。
7. １つ以上の接続パラメータを少なくとも１つのセンサにブロードキャストすることを備える請求項１に記載の方法。
8. 通信プロトコルはブルートゥースローエナジーであり、センサ情報の送信はブルートゥースローエナジーハードウェアを介して行われる請求項１に記載の方法。
9. 接続間隔ごとに、通信リンクを介して接続間隔中に行われる通信に関して、少なくとも１つのセンサからセンサ情報が収集される請求項１に記載の方法。
10. 接続期間中に、マスタデバイスと携帯デバイスとの間の通信の１つ以上の特性を複数のセンサデバイスで検知することを備える請求項１に記載の方法。
11. 第１のセンサデバイスにおいて、第２のセンサデバイスから、１つ以上の検知特性を取得すること、および
    第２のセンサデバイスから取得された１つ以上の検知特性を、第１のセンサデバイスから送信することを備える請求項１０に記載の方法。
12. 前記取得することは、第１のセンサデバイスにおいて検知された、１つ以上の検知特性に関するセンサ情報を第１のセンサデバイスが通信する送信期間中に、１つ以上の検知特性を取得することを含む請求項１１に記載の方法。
13. センサ情報を通信するためのシステムであって、
    複数のセンサデバイスと通信するように構成されたコントローラデバイスと、
    前記コントローラデバイスは、複数のセンサデバイスの第１のセットから複数のパケットを受信するように構成され、
    前記複数のセンサデバイスの各々は、検知特性を取得するように構成された前記複数のセンサデバイスの各々と、を備え、
    前記複数のセンサデバイスの各々は、前記検知特性を示すセンサ情報を有するデータパケットを生成するように構成され、前記複数のセンサデバイスの各々は、前記コントローラデバイスと前記複数のセンサデバイスの別のものとの少なくとも１つに前記データパケットを送信するように構成され、前記複数のセンサデバイスの各々は、前記検知特性を検知すること、および前記複数のセンサデバイスのうちの別のものから前記検知特性を受信することの少なくとも１つによって、前記検知特性を取得するように構成されており、
    第１のセンサデバイスが、前記複数のセンサデバイスの前記第１のセットに含まれており、第２のセンサデバイスが、前記複数のセンサデバイスの第２のセットに含まれており、そして、
    前記第１のセットの前記第１のセンサデバイスは、前記第２のセンサデバイスがセンサ情報を含む前記データパケットを送信する第１の時間フレームの間に、前記コントローラデバイスに前記データパケットを送信するように構成され、前記第１の時間フレームに続く第２の時間フレームの間に、前記コントローラデバイスは、前記第２のセンサデバイスによって生成されたセンサ情報を受信するシステム。
14. 前記第１のセットに第３のセンサデバイスが含まれており、前記第３のセンサデバイスは、前記第１の時間フレームの間に前記第２のセンサデバイスによって送信された前記データパケットを受信するように構成され、前記第３のセンサデバイスは、前記第２のセンサデバイスによって生成されたセンサ情報を含む前記データパケットを前記第２の時間フレームの間に送信するように構成される請求項１３に記載のシステム。
15. 前記第１のセンサデバイスは、同時に、ａ）前記コントローラデバイスに前記データパケットを送信し、ｂ）前記第２のセンサデバイスから前記データパケットを受信し、前記第２の時間フレームの間に、前記第１のセンサデバイスは、前記コントローラデバイスへセンサ情報を含む前記データパケットを送信する請求項１３に記載のシステム。
16. 前記第１のセンサデバイスは、前記複数の前記センサデバイスのうちの他のセンサデバイスから前記検知特性を受信することによってのみ、前記検知特性を取得する請求項１３に記載のシステム。
17. 前記第１のセンサデバイスによって検知された前記特性は、前記第２のセンサデバイスによって検知された前記特性とは異なる請求項１３に記載のシステム。
18. 前記第１の時間フレームの間に、前記第１のセンサデバイスが前記データパケットを送信する一方で、前記第３のセンサデバイスは同時に前記第２のセンサデバイスからセンサ情報を受信する請求項１４に記載のシステム。
19. 前記第１の時間フレームの間に、前記第３のセンサデバイスは前記第２のセンサデバイスからセンサ情報を受信する請求項１８に記載のシステム。
20. 前記第１の時間フレームの間に、前記第１のセンサデバイスは第１の通信周波数を介して前記コントローラデバイスと通信し、前記第３のセンサデバイスは前記第１の通信周波数とは異なる第２の通信周波数を介して前記第２のセンサデバイスと通信する請求項１４に記載のシステム。
21. 前記第２の時間フレームの間に、前記第３のセンサデバイスは前記コントローラデバイスと通信する請求項２０に記載のシステム。
22. 前記コントローラデバイスは、複数のセンサデバイスにコマンドパケットをブロードキャストするように構成され、前記コマンドパケットは、前記検知特性を示すセンサ情報を含む前記データパケットを送信するための指令を含む請求項１３に記載のシステム。
23. 前記コントローラデバイスとの通信は、通信プロトコルに従って行われ、前記複数のセンサデバイスは、ブルートゥースローエナジー通信プロトコルに従って携帯デバイスに関する通信を受信する請求項１３に記載のシステム。
24. 前記コントローラデバイスは、携帯デバイスとの通信を監視するための接続パラメータを前記複数のセンサデバイスに通信し、前記接続パラメータは、複数の接続間隔の間に携帯デバイスからの通信の受信を容易にする情報を含み、
    前記複数の接続間隔の各々の間に、前記携帯デバイスは、ブルートゥースローエナジープロトコルに従って、通信リンクを介して前記コントローラデバイスとデータを通信し、
    複数のセンサの各々は、通信リンクを介して送信される前記携帯デバイスからの通信を受信することが可能なブルートゥースローエナジーハードウェアを含み、そして
    前記第１および第２の時間フレームは、携帯デバイスからの通信が存在しない各接続間隔のギャップ時間フレーム内に定義され、第１のセンサデバイスおよび第２のセンサデバイスからの通信は、ブルートゥースローエナジープロトコルとは異なる通信プロトコルに従って定義され、ブルートゥースローエナジーハードウェアを介して通信される請求項２３に記載のシステム。
25. 前記コントローラデバイスは、前記携帯デバイスとの通信に利用される通信プロトコルの接続間隔ごとに、前記複数のセンサの各々からセンサ情報を受信するように構成される請求項２３に記載のシステム。
26. 複数の前記コントローラデバイスを含み、前記複数のコントローラデバイスのそれぞれは、前記複数のセンサデバイスのうちの２つ以上と通信するように構成され、前記複数のコントローラデバイスの各々は、携帯デバイスとの通信に利用される通信プロトコルの接続間隔ごとに、前記２つ以上のセンサデバイスの各々からのセンサ情報を受信するように構成される請求項２５に記載のシステム。
27. 前記複数のセンサの各々によって取得された前記検知特性は、携帯デバイスから受信される通信に関するものである請求項１３に記載のシステム。
28. 前記検知特性は、携帯デバイスから受信する通信に関する信号強度、到着角度、および飛行時間のうちの少なくとも１つである請求項２７に記載のシステム。
29. 前記検知特性は、携帯デバイスに送信される通信を示す請求項１３に記載のシステム。
30. 前記検知特性は、携帯デバイスに送信される通信の信号強度である請求項２９に記載のシステム。
31. 前記複数のセンサのうちの少なくとも１つが複数の特性を検知するように構成され、前記複数の特性のうちの少なくとも１つは環境特性を含む請求項１３に記載のシステム。
32. センサ情報を収集するためのシステムであって、
    センサ情報を通信するように構成された複数のセンサデバイスと、
    前記複数のセンサデバイスの各々は、検知特性を取得するように構成され、前記複数のセンサデバイスの各々は、前記検知特性を示すセンサ情報を生成するように構成され、前記複数のセンサデバイスの各々は、前記検知特性を検知すること、および前記複数のセンサデバイスのうちの別のものから前記検知特性を受信することの少なくとも１つによって、前記検知特性を取得するように構成されており、
    複数のセンサデバイスからセンサ情報を収集するように構成された通信コントローラと、を備え、
    前記複数のセンサデバイスのうちの第１のセンサデバイスは、前記複数のセンサデバイスのうちの第２のセンサデバイスからセンサ情報を収集するように構成され、前記第１のセンサデバイスは、前記複数のセンサデバイスのうちの第３のセンサデバイスが、センサ情報を通信コントローラに送信する時間フレームの間に、前記第２のセンサデバイスからセンサ情報を受信し、
    前記第１のセンサデバイスは、前記第２のセンサデバイスから受信したセンサ情報を用いて集約データパケットを生成し、前記第１のセンサデバイスは前記集約データパケットを前記通信コントローラに送信するシステム。
33. 前記第１のセンサデバイスと前記第３のセンサデバイスとは同じセンサデバイスである請求項３２に記載のシステム。
34. 前記第１のセンサデバイスは、前記複数の前記センサデバイスのうちの他のセンサデバイスから前記検知特性を受信することによってのみ、前記検知特性を取得する請求項３２に記載のシステム。
35. 前記第１のセンサデバイスによって検知された前記特性は、前記第２のセンサデバイスによって検知された前記特性とは異なる請求項３２に記載のシステム。
36. 前記コントローラデバイスは、複数のセンサデバイスにコマンドパケットをブロードキャストするように構成され、前記コマンドパケットは、前記検知特性を通信するための指令を含む請求項１３に記載のシステム。
37. 前記第１のセンサは、第１の時間フレームの間に、前記第２のデバイスからセンサ情報を受信し、前記第３のデバイスは、前記第１の時間フレームの間に、センサ情報を送信し、前記第２のデバイスからのセンサ情報の受信は、前記第１の時間フレームの間の、前記コントローラデバイスへのセンサ情報の送信とオーバーラップする請求項３２に記載のシステム。
38. 前記第３のデバイスは、前記第１の時間フレームの間、センサ情報を第１の周波数にて送信し、前記第２のデバイスは、前記第１の時間フレームの間、センサ情報を第２の周波数にて送信する請求項３７に記載のシステム。
39. 前記複数のセンサの各々によって検知される前記特性は、携帯デバイスから受信される通信に関する信号強度、到着角度、および飛行時間のうちの少なくとも１つである請求項３２に記載のシステム。
40. 前記コントローラデバイスとの通信は、通信プロトコルに従って行われ、
    前記複数のセンサデバイス間の通信は、同じ通信プロトコルに従って行われ、そして、
    前記コントローラデバイスは、携帯デバイスとの通信リンクを介して送信される通信の受信を容易にするための、携帯デバイスとの通信に関する接続パラメータを前記複数のセンサデバイスに通信する請求項３２に記載のシステム。
41. 前記設定パラメータは、複数の接続間隔の間に、携帯デバイスからの通信の受信を容易にする情報を含み、
    前記複数の接続間隔の各々の間に、前記携帯デバイスは、ブルートゥースローエナジープロトコルに従い、前記コントローラデバイスとの通信リンクを介してデータを通信し、
    複数のセンサの各々は、通信リンクを介して送信される前記携帯デバイスからの通信を受信することが可能なブルートゥースローエナジーハードウェアを含み、そして、
    前記第１および第２の時間フレームは、携帯デバイスからの通信が存在しない各接続間隔のギャップ時間フレーム内に定義され、第１のセンサデバイスおよび第２のセンサデバイスからの通信は、ブルートゥースローエナジープロトコルとは異なる通信プロトコルに従って定義され、前記ブルートゥースローエナジーハードウェアを介して通信される請求項４０に記載のシステム。
42. 複数のセンサデバイスからコントローラデバイスへセンサ情報を通信する方法であって、
    第１のセンサデバイスと第２のセンサデバイスとの各々において、検知特性を取得すること、
    第１のセンサデバイスと第２のセンサデバイスとの各々において取得された検知特性を示すセンサ情報を生成すること、
    第１の時間フレームの間に、第１のセンサデバイスからコントローラデバイスへセンサ情報を送信すること、
    第１の時間フレームの間に、第２のセンサデバイスからセンサ情報を送信すること、
    第１の時間フレームに続く第２の時間フレームの間に、第２のセンサデバイスにおいて取得されたセンサ情報を、第２のセンサデバイス以外のセンサデバイスから送信すること、を備える方法。
43. 第３のセンサデバイスにおける検知特性を取得すること、および、第３のセンサデバイスにおいて取得された検知特性を示すセンサ情報を生成すること、を備える請求項４２に記載の方法。
44. 前記第１の時間フレームの間に前記第２のセンサデバイスからセンサ情報を送信することは、センサ情報を第３のセンサデバイスに送信することを含み、第２のセンサデバイス以外のセンサデバイスは第３のセンサデバイスである請求項４２に記載の方法。
45. 第２のセンサデバイス以外のセンサデバイスは、第１のセンサデバイスである請求項４２に記載の方法。
46. 第１のセンサデバイスにおける検知特性は、第２のセンサデバイスにおける検知特性とは異なる請求項４２に記載の方法。
47. コントローラデバイスから複数のセンサデバイスへコマンドパケットをブロードキャストすることを備える請求項４２に記載の方法。
48. 複数のセンサデバイスにおいて、携帯デバイスとの通信を受信するための接続パラメータを通信することを備え、検知特性は、受信される通信を示す請求項４２に記載の方法。
49. 携帯デバイスとの通信は、携帯デバイスから送信されること、および携帯デバイスへ送信されることの少なくとも一方である請求項４８に記載の方法。
50. 接続パラメータは、携帯デバイスと複数のセンサデバイス以外の他のデバイスとの間で確立された通信に関する請求項４８に記載の方法。
51. 検知特性は、携帯デバイスとの通信に関する信号強度、到着角度、および飛行時間のうちの少なくとも１つである、請求項４８に記載の方法。
52. 検知特性は、環境特性および前記複数のセンサデバイスのうちの別のものから送信される通信の特性のうちの少なくとも１つである請求項４８に記載の方法。
53. 前記取得することは、ａ）他のセンサデバイスとの通信を介して検知特性を受信すること、およびｂ）第１のセンサデバイスと第２のセンサデバイスとの少なくとも１つにおいて検知特性を検知すること、の少なくとも１つを含む請求項４２に記載の方法。

Images