開示の詳細な説明
以下、本開示の1つまたは複数の特定の実施形態を説明する。これらの記載された実施形態は、現在開示されている技術の単なる例である。さらに、これらの実施形態の簡潔な説明を提供するために、実際の実現例のすべての特徴は本明細書に記載されていない場合がある。任意の工学または設計プロジェクトにおけるように、任意のそうした実際の実現例を開発するには、実現例ごとに異なる可能性があるシステム関連およびビジネス関連の制約への準拠など、開発者の特定の目標を達成するために実現例固有の判断を多数行う必要がある。さらに、そのような開発努力は、複雑で時間がかかるかもしれないが、それにもかかわらず、この開示の恩恵を受ける当業者にとって設計、製作および製造の日常的な業務であり得ることが理解されるべきである。
本開示の様々な実施形態の要素を導入する際に、冠詞「a」、「an」および「the」は、それら要素の1つまたは複数が存在することを意味することを意図している。「備える(comprising)」、「含む(including)」および「有する(having)」という用語は、包括的であり、列挙された要素以外の追加の要素が存在し得ることを意味することが意図される。さらに、本開示の「一実施形態」または「ある実施形態」への言及は、記載された特徴をも組み込む追加の実施形態の存在を排除するものとして解釈されるものではないことを理解されたい。
本開示の実施形態は、一般に、BLEを介して比較的洗練されたアプリケーション層メッセージを送信し、そのような通信を使用してスマートネットワークにおいて警報を遠隔で解除することに関する。「スマートホーム環境」は、1つまたは複数のスマートデバイスを含んでもよい、一戸建て住宅、複式マンション、タウンホーム、複数ユニットのアパート、ホテル、小売店、オフィスビル、工業用建物および任意の建物などの任意の建物タイプのためのスマート環境またはスマートネットワークを意味することができることを理解されたい。
さらに、ユーザ、顧客、設置者、住宅所有者、居住者、ゲスト、テナント、賃貸人、修繕者、ユーザといった用語は、ネットワーク内でユーザインタフェースを介してスマートデバイスと対話する人に言及するために使用されてもよいが、これらの言及は、このような動作を実行する人に関して本教示の範囲を限定するものと決してみなされるものではないことが理解されるべきである。したがって、例えば、ユーザ、顧客、購入者、設置者、加入者、および住宅所有者という用語は、一戸建て住居の場合において同じ人をさすことがあり得ることが多く、なぜならば、家長は、購入を判断し、ユニットを購入し、ユニットを設置および構成し、ユニットのユーザの1人でもある人であるからである。しかしながら、家主−テナント環境のような他の場合では、顧客はユニットの購入に関して家主であり得、設置者は地元のアパート監督者であり得、第1のユーザはテナントであり得、第2のユーザは再び遠隔制御機能性に関して再び家主であり得る。アクションを実行する人物の身元は、1つまたは複数の実施形態によって提供される特定の利点に密接に関連してもよい-例えば、本明細書で説明するパスワード保護されたネットワークコミッショニング機能は、家主が唯一のパスワードを保持し、ネットワークの追加を制御できる場合に特に有利である-一方で、そのような身元は、以下の記述において、本教示の範囲をこれらの特定の身元を有する特定の個人に必然的に限定するものとして解釈されるべきではない。
I.スマートネットワーク
上述のことを念頭に置いて、図1は、本明細書でさらに説明されているデバイス、方法、システム、サービス、および/またはコンピュータプログラム製品のうちの1つまたは複数が適用可能であるものとしてよい、スマートネットワークとも称される、スマートホーム環境100の一例を示している。図示されているスマートホーム環境100は、構造物150を含み、これは例えば、家、オフィスビル、車庫、またはトレーラーハウスを含み得る。いくつかの実施形態では、デバイスは、アパートメント、コンドミニアム、またはオフィススペースなどの構造物150全体を含まないスマートホーム環境100内に組み込まれ得ることは理解されるであろう。さらに、スマートホーム環境では、実際の構造物150の外部のデバイスを制御し、および/またはそれに結合され得る。実際、スマートホーム環境内の複数のデバイスは、構造物150内に物理的に存在する必要はまったくない。例えば、プールヒーターまたは灌漑システムを制御するデバイスは、構造物150の外部に配置され得る。
図示されている構造物150は、壁154を介して互いに少なくとも部分的に隔てられている、複数の部屋152を備える。壁154は、内壁または外壁を備えることができる。それぞれの部屋は、床156と天井158とをさらに備えることができる。デバイスは、壁154、床156または天井158に装着され、一体化され、および/または支持され得る。
いくつかの実施形態では、図1のスマートホーム環境100は、スマートホームのさまざまな有益な目的を達成するために互いに、中央サーバに、クラウドコンピューティングシステムに、またはそれらの何らかの組み合わせにシームレスに統合され得る、インテリジェント型マルチセンサネットワーク接続デバイスを含むさまざまなデバイスを備える。スマートホーム環境100は、1つまたは複数のインテリジェント型マルチセンサネットワーク接続サーモスタット102(これ以降「スマートサーモスタット102」と称する)、1つまたは複数のインテリジェント型ネットワーク接続マルチセンサハザード検出ユニット104(これ以降「スマートハザード検出器104」と称する)、1つまたは複数のインテリジェント型マルチセンサネットワーク接続ドアベルデバイス106(これ以降「スマートドアベル106」と称する)、1つ以上のインテリジェント型ネットワーク接続ドアロック107(以下、「スマートドアロック107」と呼ぶ)、または有線インターフェイスもしくはワイヤレスインターフェースを使用して相互接続することができる他のデバイスを含み得る。
いくつかの実施形態によれば、スマートサーモスタット102は、周辺気候特性(例えば、温度および/または湿度)を検出し、HVACシステム103をしかるべく制御する。スマートハザード検出器104は、危険な物質または危険な物質を示す物質(例えば、煙、火炎、または一酸化炭素)の存在を検出することができる。スマートベル106は、人の場所への接近または場所から退去(例えば、廊下に通じるドア)を検出し、ドアベルの機能を制御し、人の接近もしくは退去を音響的もしくは視覚的手段を介して知らせる、またはセキュリティシステム上の設定を制御する(例えば、居住者の出入りのときにセキュリティシステムを作動もしくは停止するため)ことができる。スマートドアロック107は、家屋内のドアのロック状態とロック解除状態とを検出し、それらの状態間をトグルで切換えるか、それぞれのドアへの人の接近または退去を検出するか、ドアが開いているか閉じているかを検出するか、またはスマートドアロックに関連する他の適切な制御を検出する。
いくつかの実施形態では、図1のスマートホーム環境100は、1つまたは複数のインテリジェント型マルチセンサネットワーク接続壁面スイッチ108(これ以降「スマート壁面スイッチ108」と称する)を、1つまたは複数のインテリジェント型マルチセンサネットワーク接続壁面コンセントインターフェース110(これ以降「スマート壁面コンセント110」と称する)と共に備え得る。スマート壁面スイッチ108は、周囲照明状態を検出し、在室状態を検出し、1つまたは複数の照明の電力および/または減光状態を制御することができる。いくつかの場合において、スマート壁面スイッチ108は、天井にある扇風機などの扇風機の電力状態または速度を制御することもできる。スマート壁面コンセント110は、部屋またはエンクロージャの在室を検出し、1つまたは複数の壁面コンセントへの電力の供給を制御する(例えば、家の中に誰も居ない場合に電力をコンセントに供給しない)ことができる。
さらに、いくつかの実施形態では、図1のスマートホーム環境100は、冷蔵庫、ストーブおよび/またはオーブン、テレビ、洗濯機、乾燥機、照明、ステレオ、インターコムシステム、車庫扉開閉装置、床の扇風機、天井の扇風機、壁面設置型空調装置、プールヒーター、灌漑システム、セキュリティシステム、窓センサ、セキュリティシステムなどの、複数のインテリジェント型マルチセンサネットワーク接続アプライアンス112(これ以降「スマートアプライアンス112」と称する)を備える。いくつかの実施形態によれば、ネットワーク接続アプライアンス112は、アプライアンスの各メーカーと連携することによってスマートホーム環境との互換性を確保してもよい。例えば、アプライアンスは、室内暖房具、窓用ACユニット、電動式ダクトベントなどとすることができる。コンセントに接続すると、アプライアンスは自分が何であるかを、自分がどのような種類のアプライアンスであるかを示すことなどによってスマートホームネットワークに知らせ、スマートホームの制御装置と自動的に統合することができる。アプライアンスによるスマートホームへのそのような通信は、当業者によって知られている有線もしくはワイヤレス通信プロトコルにより円滑にされ得る。スマートホームは、スマート壁面コンセント110を使って、粗くはあるが(ON/OFF)、制御できる古い従来型の洗濯機/乾燥機、冷蔵庫、および同様のものなどの、さまざまな非通信型の従来機器140も備えることができる。スマートホーム環境100は、スマートハザード検出器104またはスマート壁面スイッチ108によって供給されるIR信号によって制御され得る、赤外線(「IR」)制御壁面設置型空調装置または他のIR制御デバイスなどの、さまざまな部分的な通信を行う従来機器142をさらに備えることができる。
いくつかの実施形態によれば、スマートホーム環境100のスマートサーモスタット102、スマートハザード検出器104、スマートドアベル106、スマートドアロック107、スマート壁面スイッチ108、スマート壁面コンセント110、および他のデバイスは、モジュール式であり、より古い家および新しい家に組み込まれ得る。例えば、いくつかの実施形態では、これらのデバイスは、2つの基本コンポーネントからなるモジュール式プラットフォームの周りに取り付けるように設計され、これらのコンポーネントは、ヘッドユニットおよびバックプレートであり、ドッキングステーションとも称される。ドッキングステーションの複数の構成は、より古い家およびより新しい家など、いかなる家とも互換性を有するように用意される。しかし、ドッキングステーションはすべて、標準的なヘッド接続配置構成を備え、これにより、ヘッドユニットは、いかなるドッキングステーションにも取り外し可能に取り付けることができる。したがって、いくつかの実施形態では、ドッキングステーションは、家の構造物および電圧配線への物理的接続部として機能するインターフェイスであり、交換可能なヘッドユニットは、センサ、プロセッサ、ユーザーインターフェース、バッテリ、およびデバイスの他の機能的コンポーネントのすべてを収容する。
プロビジョニング、メンテナンス、およびアップグレードに関して商業面および機能面で多くのさまざまなことが将来起こり得ることが考えられる。例えば、特定のヘッドユニットを何年も使用した後に、ユーザは、新バージョンのヘッドユニットを購入して、古いドックステーションに単に接続することができる。また、ヘッドユニットには、機能を減らした廉価バージョン、次いで、機能が次第に高くなって行く一連のバージョンなど、多数の機能を備える洗練されたヘッドユニットに至るまで、多くの異なるバージョンがある。したがって、ヘッドユニットのさまざまなバージョンは取り替え可能であり、それらはどれもドッキングステーション内に配設されたときに動作し得ることは理解されるであろう。これは、古いヘッドユニットの共有および再配備を助長し都合がよい--例えば、ハザード検出器などの重要な高機能ヘッドユニットが、ヘッドユニットの新しいバージョンで置き換えられるときに、古いヘッドユニットは、裏の部屋または地下室などに再配備することができる。いくつかの実施形態によれば、最初にドッキングステーションに差し込んだときに、ヘッドユニットは、ユーザに(2D LCDディスプレイ、2D/3Dホログラフィック投影、ボイスインタラクションなどによって)、「Where am I(ここはどこ)」などの少数の単純な質問をすることができ、ユーザは、「living room(居間)」、「台所」などを指示することができる。
スマートホーム環境100は、物理的な家の外側にあるが、家の近接地理的範囲内にあるデバイスとの通信も含み得る。例えば、スマートホーム環境100は、スマートホーム環境100内の他のデバイスに現在のプール温度を伝達するか、またはプール温度を制御するためのコマンドを受信するプール加熱装置監視装置114を備えることができる。同様に、スマートホーム環境100は、スマートホーム環境100内の灌漑システムに関する情報を伝達し、および/またはそのような灌漑システムを制御するための制御情報を受信する灌漑監視装置116を備えることができる。いくつかの実施形態によれば、家庭の郵便番号または地理的座標などに基づき、スマートホーム環境100の地理的配置を考慮するためのアルゴリズムが提供される。次いで、地理的情報が、散水に最適な時間を決定するのに役立つデータを取得するために使用され得る。そのようなデータは、太陽位置情報、温度、露点、家が建っている土地の土壌の種類などを含み得る。
ネットワーク接続性のおかげで、図1のスマートホームデバイスの1つまたは複数は、ユーザがデバイスの近くに居ない場合であっても、ユーザがデバイスをインタラクティブに操作することも可能にすることができる。例えば、ユーザは、コンピュータ(例えば、デスクトップコンピュータ、ラップトップコンピュータ、もしくはタブレット)または他の携帯型電子デバイス(例えば、スマートフォン)166を使用してデバイスと通信することができる。ウェブページまたはアプリは、ユーザからの通信を受信し、通信に基づきデバイスを制御し、および/またはデバイスの動作に関する情報をユーザに提示するように構成され得る。例えば、ユーザは、デバイスに対する現在の設定点温度を見て、コンピュータを使用してそれを調整することができる。ユーザは、このリモート通信の間に構造物内に居てもよいし、または構造物の外部に居てもよい。
説明されているように、ユーザは、ネットワーク接続コンピュータまたは携帯型電子デバイス166を使用してスマートホーム環境100内のスマートサーモスタットおよび他のスマートデバイスを制御することができる。いくつかの実施形態では、デバイス166は、スマートネットワークに、直接、または1つ以上のデバイス(たとえば、エッジルータ)を使用してスマートネットワークに接続される追加のネットワーク(たとえばWiFi)を介して、接続され得る。いくつかの例では、居住者(例えば、家に住んでいる個人)の一部または全部が、自分たちのデバイス166をスマートホーム環境100に登録することができる。そのような登録は、居住者および/またはデバイスをその家に関連付けられているものとして認証し、デバイスを使用して家の中のスマートデバイスを制御する許可を居住者に与えるために中央サーバ側で実行され得る。居住者は、居住者が就業中であるか、または休暇中であるときなどに、自分の登録されたデバイス166を使用して家のスマートデバイスを遠隔制御することができる。居住者は、居住者が家の中のカウチに座っているときなど、居住者が家の中に実際に居るときに、登録されたデバイスを使用してスマートデバイスを制御することもできる。デバイス166を登録する代わりに、または登録することに加えて、スマートホーム環境100は、どの個人がその家に住んでいるか、したがって居住者であるか、またどのデバイス166がそれらの個人に関連付けられているかに関して推論し得ることは理解されるであろう。そのようなものとして、スマートホーム環境は、居住者である人を「学習」し、それらの個人に関連付けられているデバイス166が家のスマートデバイスを制御することを許可する。
いくつかの場合において、ゲストが、スマートデバイスを制御することを望むことがある。例えば、スマートホーム環境は、家の中の個人の未登録のモバイルデバイスから通信を受信することができ、その場合、前記個人は、家の居住者として認識されない。例えば、スマートホーム環境は、ゲストであると知られているか、もしくはゲストとして登録されている個人のモバイルデバイス、またはスマートデバイスとして共通のネットワーク(例えば、SSID WiFiネットワーク)上にあると判断されるモバイルデバイスから通信を受信することができる。
いくつかの実施形態では、処理および感知機能を収容することに加えて、デバイス102、104、106、107、108、110、112、114、116、162、170および他のスマートデバイス(「スマートデバイス」と総称される)のそれぞれは、データ通信および情報共有を、それらのスマートデバイスのうちの他のデバイスと、さらには中央サーバもしくはクラウドコンピューティングシステムもしくは世界のどこかでネットワーク接続されている他のデバイスに対して行うことができ得る。必要とされるデータ通信は、さまざまなカスタムもしくは標準的なワイヤレスプロトコル(Wi-Fi、ZigBee(登録商標)、6LoWPANなど)および/またはさまざまなカスタムもしくは標準有線プロトコル(CAT6 Ethernet(登録商標)、HomePlugなど)を使用して実行され得る。
いくつかの実施形態によれば、スマートデバイスは、すべてまたは一部が、ワイヤレスまたは有線リピーターとしての機能を果たすことができる。例えば、スマートデバイスのうちの第1のデバイスは、ワイヤレスルーター160を介してスマートデバイスのうちの第2のデバイスと通信することができる。スマートデバイスは、インターネット162などの、ネットワークへの接続を介して互いにさらに通信することができる。インターネット162を通じて、スマートデバイスは中央サーバまたはクラウドコンピューティングシステム164と通信することができる。中央サーバまたはクラウドコンピューティングシステム164は、デバイスに関連付けられている製造業者、サポートエンティティ、またはサービスプロバイダと関連付けられ得る。ある実施形態について、ユーザは、電話またはインターネット接続コンピュータなどの他の通信手段を使用することなくデバイスそれ自体を使用してカスタマーサポートとコンタクトをとることができるものとしてよい。さらに、ソフトウェア更新は、中央サーバまたはクラウドコンピューティングシステム164からスマートデバイスに自動的に送信され得る(例えば、利用可能になったとき、購入したとき、または定期的間隔で)。
以下に論ずるように、スマートデバイス同士を組み合わせることで、メッシュネットワークを形成してもよい。いくつかの実施形態では、このメッシュネットワークはスポークスマンノードおよび低電力ノードをスマートホーム環境100において含んでもよく、スマートデバイスのうちのいくつかは、「スポークスマン」ノードであり、他は、「低電力」ノードである。スマートホーム環境100内のスマートデバイスのいくつかは、電池式であるが、他のデバイスは、スマートホーム環境の壁154の背後の配線(例えば、120Vの線間電圧線)への接続などによる、通常の信頼性の高い電源を有する。通常の信頼性の高い電源を有するスマートデバイスは、「スポークスマン」ノードと称される。これらのノードは、スマートホーム環境100内のさまざまな他のデバイスとの、さらには中央サーバもしくはクラウドコンピューティングシステム164との双方向通信を円滑にするワイヤレスプロトコルもしくは方式を使用する能力を備える。他方、電池式のデバイスは、「低電力」ノードと称される。これらのノードは、スポークスマンノードに比べて小さい傾向を有し、Zigbee、6LoWPANなどの、必要とする電力が非常に少ないワイヤレスプロトコルを使用して通信してもよい。さらに、いくつかの低電力ノードは、電力消費を低減するために、比較的少量のメモリを有することもできる。したがって、いくつかの実施形態では、これらの低電力ノードは、流線型のメッセージおよびデータのデータフォーマット(例えば証明書)を利用する。さらに、低電力ノードは、すべてではないが、双方向通信を行うことができないものもある。これらの低電力ノードは、メッセージを送信するが、「聴く」ことはできない。そのため、スポークスマンノードなどの、スマートホーム環境100内の他のデバイスは、これらの低電力ノードに情報を送信することができない。追加的または代替的に、これらの低電力ノードは、間欠的に低電力状態に入り、低電力デバイスを通常の動作状態よりも比較的低い電力で動作させることができる。さらに、これらの実施形態のいくつかでは、低電力デバイスは、低電力状態中はメッセージを受信しないことがある。そのような実施形態では、他のノードが、これらの低電力状態の間に、比較的低電力のノードに向けられたメッセージを保持し、低電力ノードが低電力状態を出たときにそれぞれの低電力ノードにブロードキャストしてもよい。
ここに説明されているように、スマートデバイスは、低電力ノードおよびスポークスマンノードとして機能し、スマートホーム環境100内でメッシュネットワークを形成する。スマートホーム環境内の個別の低電力ノードは、何を感知しているかに関するメッセージを定期的に送出し、スマートホーム環境内の他の低電力ノードは--自メッセージを送出することに加えて--それらのメッセージを繰り返し、それによって、メッセージをスマートホーム環境100全体にわたってノードからノード(すなわち、デバイスからデバイス)へ伝えて行く。スマートホーム環境100内のスポークスマンノードは、低電力通信プロトコルに「ドロップダウン」してこれらのメッセージを受信し、それらのメッセージを他の通信プロトコルに対して翻訳し、翻訳されたメッセージを他のスポークスマンノードおよび/または中央サーバもしくはクラウドコンピューティングシステム164に送信することができる。こうして、低電力通信プロトコルを使用する低電力ノードは、メッセージをスマートホーム環境100全体にわたって、さらにはインターネット162上で、中央サーバもしくはクラウドコンピューティングシステム164に送信することができる。いくつかの実施形態によれば、メッシュネットワークは、中央サーバもしくはクラウドコンピューティングシステム164が定期的に家の中のスマートデバイスのすべてからデータを受信し、データに基づき推論し、いくつかのスマートデバイスのうちの1つにコマンドを送り返して本明細書で説明されているスマートホームの目的のうちのいくつかを達成することを可能にする。
説明されているように、スポークスマンノード、および低電力ノードのうちのいくつかは、「聴く」ことができる。したがって、ユーザ、他のデバイス、および中央サーバまたはクラウドコンピューティングシステム164は、低電力ノードに制御を伝達することができる。例えば、ユーザは、携帯型電子デバイス(例えば、スマートフォン)166を使用して、インターネット経由でコマンドを中央サーバまたはクラウドコンピューティングシステム164に送信することができ、次いで、これはコマンドをスマートホーム環境100内のスポークスマンノードに中継する。スポークスマンノードは、低電力プロトコルにドロップダウンして、スマートホーム環境全体を通してコマンドを低電力ノードに伝達するだけでなく、中央サーバまたはクラウドコンピューティングシステム164からコマンドを直接受信しなかった他のスポークスマンノードにも伝達する。
低電力ノードの一例は、スマート常夜灯170である。光源を収容することに加えて、スマート常夜灯170は、超音波または受動的IRセンサなどの人感センサ、およびフォトレジスタまたは室内の光を測定する単一ピクセルセンサなどの周辺光センサを収納する。いくつかの実施形態では、スマート常夜灯170は、室内が暗いことを周辺光センサが検出したときに、また室内に誰か居ることを人感センサが検出したときに光源を作動させるように構成される。他の実施形態では、スマート常夜灯170は、室内が暗いことを周辺光センサが検出したときに光源を作動させるように単純に構成される。さらに、いくつかの実施形態によれば、スマート常夜灯170は、室内に人が居ることを人感センサが検出することと同期する瞬時メッセージを含む、在室状態および室内の光量に関するメッセージを定期的に送出する低電力ワイヤレス通信チップ(例えば、ZigBeeチップ)を備える。上で述べているように、これらのメッセージはワイヤレス方式で、メッシュネットワークを使用してスマートホーム環境100内のノードからノード(すなわち、スマートデバイスからスマートデバイス)へ、さらにはインターネット162を経由して中央サーバまたはクラウドコンピューティングシステム164に送信され得る。
低電力ノードの他の例は、スマートハザード検出器104の電池式バージョンを含む。これらのスマートハザード検出器104は、一定の信頼性の高い電力へのアクセスのない領域内に配置されることが多く、以下で詳しく説明されているように、煙/火炎/熱センサ、一酸化炭素/二酸化炭素センサ、人感/モーションセンサ、周辺光センサ、温度センサ、湿度センサ、および同様のものなどの、任意の数および任意の種類のセンサを備えることができる。さらに、スマートハザード検出器104は、上で説明されているようなメッシュネットワークなどを使用することによって、各センサにそれぞれ対応するメッセージを他のデバイスおよび中央サーバまたはクラウドコンピューティングシステム164に送信することができる。
スポークスマンノードの例として、スマートドアベル106、スマートサーモスタット102、スマート壁面スイッチ108、およびスマート壁面コンセント110が挙げられる。これらのデバイス102、106、108、および110は、信頼できる電源の近くに配置され、接続されることが多く、したがって、さまざまなプロトコルによる双方向通信が可能な1つまたは複数の通信チップなどの、電力をより消費するコンポーネントを備え得る。
いくつかの実施形態では、これらの低電力ノードおよびスポークスマンノード(例えば、デバイス102、104、106、107、108、110、112、および170)は、スマートホーム環境内の警報システムに対する「トリップワイヤ」として機能し得る。例えば、加害者がスマートホーム環境100の窓、ドア、および他の入口点に配置されている警報センサによる検出を回避する場合、警報は、人の存在、動き、熱、音など、メッシュネットワーク内の低電力ノードおよびスポークスマンノードの1つまたは複数からメッセージを受信した後にトリガーされ得る。例えば、人の存在を示すメッセージを常夜灯170から受信すると、中央サーバもしくはクラウドコンピューティングシステム164または他の何らかのデバイスが、警報が検出時点において作動状態にある場合に、警報をトリガーすることが可能である。したがって、警報システムは、スマートホーム環境100全体にわたって配置されているさまざまな低電力ノードおよびスポークスマンノードによって強化され得る。この例では、ユーザは、追加のスマート常夜灯170を購入して設置することによってスマートホーム環境100のセキュリティを向上させることが可能である。
いくつかの実施形態では、メッシュネットワークは、人が部屋から部屋へ移るときに照明を自動的にオン、オフするために使用され得る。例えば、低電力ノードおよびスポークスマンノード(例えば、デバイス102、104、106、107、108、110、112、および170)は、スマートホーム環境を通過する人の移動を検出し、メッシュネットワークを通じて対応するメッセージを伝達する。どの部屋に人が居るかを示すメッセージを使用し、中央サーバもしくはクラウドコンピューティングシステム164または他の何らかのデバイスは、スマート壁面スイッチ108の作動および停止を行い、スマートホーム環境100内で部屋から部屋へ人が移動するときに光を自動的に供給する。さらに、ユーザは、スマート常夜灯170などの、ランプおよび他の光源に電力をどのスマート壁面コンセント110が供給するかを示す事前構成情報を与えることができる。あるいは、壁面コンセント110への光源のこのようなマッピングは、自動的にも行える(例えば、スマート壁面コンセント110は、光源が差し込まれたときに差し込まれたことを検出し、対応するメッセージを中央サーバもしくはクラウドコンピューティングシステム164に送信する)。このマッピング情報をどの部屋に人が居るかを示すメッセージと併用することで、中央サーバもしくはクラウドコンピューティングシステム164または他の何らかのデバイスは、ランプおよび他の光源に電力を供給するスマート壁面コンセント110の作動および停止を行い、部屋から部屋へ人が移動するときに人の移動を追跡し、光を供給する。
いくつかの実施形態では、低電力ノードおよびスポークスマンノードのメッシュネットワークは、緊急時または避難訓練時に出口照明を提供するために使用され得る。いくつかの場合において、これを円滑にするために、ユーザは、スマートホーム環境100内の出口ルートを示す事前構成情報を提供する。例えば、家屋の部屋毎に、ユーザは、ルートの利用可能性に依って、最良の出口ルートのマップを提供してもよい。状況によっては、ルートが危険物によって塞がれている可能性がある場合は、別のルートが、利用可能である場合は、照明され、示されてもよい。ユーザがこの情報を提供する代わりに、中央サーバもしくはクラウドコンピューティングシステム164または他の何らかのデバイスが、スマートホームの家のアップロードされたマップ、ダイアグラム、建築図面を使用して、さらにはメッシュネットワークのノードから取得された位置情報(例えば、デバイスからの位置情報が家のマップを作製するために使用される)に基づき生成されたマップを使用して、それらのルートを自動的に決定することが可能であることは理解されるであろう。動作時に、警報が作動したときに(例えば、スマートハザード検出器104のうちの1つまたは複数が、煙を検出し、警報を作動させたとき)、中央サーバもしくはクラウドコンピューティングシステム164または他の何らかのデバイスは、低電力ノードおよびスポークスマンノードから取得された人がいるかどうかの情報を使用して、どの部屋に人が居るかを決定し、人が居る部屋からの出口ルートに沿って照明(例えば、常夜灯170、壁面スイッチ108、ランプに電力を供給する壁面コンセント110など)をオンにし、非常口灯の照明とする。
図1のスマートホーム環境100には、サービスロボット162がさらに備えられ、図示されており、それぞれ自律的にさまざまな家事をこなすように構成されている。いくつかの実施形態について、サービスロボット162は、床掃除、床洗浄などを、マサチューセッツ州ベッドフォード所在のiRobot, Inc.社によって販売されているROOMBA(商標)およびSCOOBA(商標)製品などの知られている市販のデバイスと似た仕方で、行うようにそれぞれ構成され得る。床掃除および床洗浄などの家事は、一般的には居住者が居ないときに実行されるのがより望ましいので、本発明の説明の目的に関して「不在時の」または「出かけている間の」作業とみなせる。他の実施形態については、サービスロボット162の1つまたは複数は、居住者のために音楽を再生する、居住者のための局所的サーモスタットとしての機能を果たす、居住者のための局所的空気監視装置/清浄器としての機能を果たす、局所的乳児監視装置としての機能を果たす、居住者のための局所的ハザード検出器としての機能を果たす、などの作業を実行するように構成され、一般的に、人間の居住者がすぐ近くに居るときにそのような作業が実行されることがより望ましい。本発明の説明の目的に関して、そのような作業は、「対人」または「人間中心」作業とみなせる。
居住者のための局所的サーモスタットとしての機能を果たす場合、サービスロボット162のうちの特定の1つは、居住者のための「パーソナルコンフォートエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間を、その居住者が家の中に居る可能性があれば必ず快適な温度に保つことである。これは、従来型の壁掛け式ルームサーモスタットとは対照的であり、静的に画成された構造空間を快適な温度に保つというより弱めた形の目的を有するものである。一実施形態によれば、局所的サーモスタットサービスロボット162は、家の中の特定の場所(例えば、朝食を摂り、新聞を読むためにダイニングルーム)に落ち着いている特定の居住者のすぐ近く(例えば、5フィート以内)に自動的に移動するように構成される。局所的サーモスタットサービスロボット162は、温度センサ、プロセッサ、およびHVACシステムとの制御通信が、直接的に、もしくはHVACシステムに結合された壁掛け式ワイヤレス通信サーモスタットを通じて維持されるように、また居住者のすぐ近くの温度が所望のレベルに維持されるように構成されたワイヤレス通信コンポーネントを備える。居住者が別の場所(例えば、テレビを見るためにリビングルームのカウチ)に移動して腰を下ろした場合、局所的サーモスタットサービスロボット162は、移動してカウチの隣りに駐機する動作を続け、その特定のすぐ近くの空間を快適な温度に保つ。
局所的サーモスタットサービスロボット162(および/または図1のより大きなスマートホームシステム)は、パーソナルエリア空間が快適な温度に保たれるべき居住者を識別して、特定することができる技術として、限定はしないが、RFID感知機能(例えば、RFIDブレスレット、RFIDネックレス、セルラーフォンRFIDまたはRFIDキーフォブを有する人)、合成ビジョン技術(例えば、ビデオカメラおよび顔認識プロセッサ)、オーディオ技術(例えば、声、音声パターン、振動パターン認識)、超音波感知/撮像技術、および赤外線もしくは近接場通信(NFC)技術(例えば、赤外線またはNFC対応スマートフォンを携えている人)、さらにそれに伴う感知された情報から有益な結論を引き出すルールベース推論エンジンまたは人工知能技術(例えば、家の中に居住者が1人しかいない場合に、それが、すぐ近くの空間が快適な温度に保たれるべき人であり、所望の快適な温度の選択はその居住者の特定の格納されているプロファイルに対応しなければならない)が挙げられ得る。
居住者のための局所的空気監視/清浄器としての機能を果たす場合、特定のサービスロボット162が、居住者のための「パーソナルヘルスエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間の空気の品質を健康レベルに保つことである。あるいは、またはそれと併せて、居住者の温度または心拍数を監視する(例えば、精密なリモートセンサ、人装着監視装置との近接場通信などを使用する)などの、他の健康関係機能も備えることができる。居住者のための局所的ハザード検出器としての機能を果たす場合、特定のサービスロボット162は、居住者のための「パーソナルセーフティエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間内に過剰な一酸化炭素、煙、火炎などがないこと保証することである。居住者識別および追跡に関してパーソナルコンフォートエリアネットワークに対する上で説明されている方法と似た方法が、同様に、パーソナルヘルスエリアネットワークおよびパーソナルセーフティエリアネットワークの実施形態に対して適用可能である。
いくつかの実施形態によれば、上で述べたように、サービスロボット162のパーソナルコンフォートエリアネットワーク、パーソナルヘルスエリアネットワーク、パーソナルセーフティエリアネットワーク、および/または他のそのような対面機能を円滑にする機能は、それらの対面機能の性能を改善し、および/またはエネルギ節約もしくは他の資源節約方法における目標を達成するために、ルールベース推論技術もしくは人工知能技術に従って家の中の他のスマートセンサと論理的統合を果たすことでさらに高められる。したがって、パーソナルヘルスエリアネットワークに関係する一実施形態について、空気監視装置/清浄器サービスロボット162は、家の中で飼っているペットが居住者の現在落ち着いている場所の方へ移動中であるかどうかを検出するように構成されるものとしてよく(例えば、オンボードセンサを使用し、および/またはルールベース推論/人工知能技術と共に他のスマートホームセンサとのデータ通信によって)、移動中であれば、到来するペットの空気中に浮遊するふけの増加に備えて空気清浄速度が即座に高められる。パーソナルセーフティエリアネットワークに関係する別の実施形態について、ハザード検出器サービスロボット162は、居住者が現在居るダイニングルーム内の位置に近い、台所において温度および湿度が上昇中であることを他のスマートホームセンサによって助言されるものとしてよく、この助言に応答して、ハザード検出器サービスロボット162は、周辺煙レベルのわずかな上昇は調理活動による可能性が最も高く、本当に危険な状態によるものでないとの推論の下で、煙検出閾値などのハザード検出閾値を一時的に高くする。
上述の「対面」および「不在時」機能は、限定はしないが、そのような機能のうちの各専用機能を有する複数の明確に区別できるサービスロボット162、そのような機能のうちの2つまたはそれ以上の異なる機能の統合を有する単一のサービスロボット162、および/または本発明の教示の範囲から逸脱することなく、これらの任意の組み合わせ(単一のサービスロボット162が「不在時」および「対面」の両方の機能を有することができることを含む)によって、実現され得る。電力は、充電式電池または他の充電方法を用いて供給することができ、図1は不活動期間にサービスロボット162が自動的にドックに入り電池を(必要ならば)充電する例示的な邪魔にならない場所にあるドッキングステーション164を示している。好ましくは、それぞれのサービスロボット162は、図1の他のワイヤレス通信スマートホームセンサのうちの1つまたは複数との、および/または1つまたは複数の他のサービスロボット162との(例えば、Wi-Fi、Zigbee、Z-Wave、6LoWPANなどを使用する)データ通信を円滑にするワイヤレス通信コンポーネントを備え、図1のスマートホームデバイスのうちの1つまたは複数は、インターネット経由でリモートサーバと通信することができる。あるいは、またはそれと連携して、それぞれのサービスロボット162は、携帯電話通信、衛星通信、3G/4Gネットワークデータ通信、または他の直接的通信方法を用いてリモートサーバと直接通信することにより構成され得る。
いくつかの実施形態により、サービスロボット162とスマートホームシステムのホームセキュリティセンサおよび関係する機能との統合に関係するシステムおよび方法が提供される。これらの実施形態は、「不在時」機能を実行する、または家に人が居ないときに他の何らかの形でアクティブであることが望ましいサービスロボット162(これ以降、「不在時サービスロボット」と称する)に対して適用されるときに特に適用可能であり、有利である。これらの実施形態には、ホームセキュリティシステム、侵入検出システム、および/または在室感知環境制御システム(例えば、家に人が居ないときに低エネルギ使用状態に入る在室感知自動セットバックサーモスタット)が、不在時サービスロボットにより誤ってトリガーされないようにする方法およびシステムが含まれる。
ある実施形態により、ホームオートメーションおよびセキュリティシステムの1つまたは複数のネットワーク接続要素とのデータ通信を行う自動化システム(例えば、クラウドベースのサーバまたは他の中央サーバ、これ以降「中央サーバ」と称する)を用いて監視サービスによって離れた場所から監視されるホームオートメーションおよびセキュリティシステム(例えば、図1に示されているような)が実現される。不在時サービスロボットは、中央サーバとの動作可能なデータ通信を行うように構成され、またその不在時サービス活動を開始する許可が中央サーバから(例えば、中央サーバからの「away-service-OK」メッセージによって)出されない限り、非不在時サービス状態のままとなる(例えば、ドッキングステーションにおいて休眠状態にある)ように構成される。システムによって行われる不在時状態決定は、(i)人感センサデータに基づき局所的敷地上スマートデバイスによって排他的に、(ii)受信された人感センサデータに基づき、および/またはユーザのスマートフォンもしくは自動車からのGPS座標などの受信された近接関係情報に基づき中央サーバによって排他的に、または(iii)(i)および(ii)の組み合わせで行われ、次いで、中央サーバによる不在時サービスロボットへの不在時サービス許可の付与をトリガーすることができる。不在時サービスロボットが継続的に家庭内位置座標を検出し、中央サーバに送信することができる、不在時サービスロボットの活動の過程において、中央サーバは、人感デバイスからの信号をフィルタリングすることで、不在時サービスロボット活動と予想外の侵入活動とを容易に区別することができ、それによって、家のセキュリティを確保しながら誤った侵入警報状態を回避することができる。あるいは、またはそれと連携して、中央サーバは、フィルタリングデータ(不在時サービスロボットによってトリガーされる予想された人感プロファイルなど)をスマートホームの人感ノードまたは関連する処理ノードに提供することができ、フィルタリングはローカルレベルで実行される。セキュリティはいくぶん低下するが、中央サーバが不在時サービスロボット活動の持続時間に対して人感機器を一時的に無効化することも本明細書の教示の範囲内に入る。
別の実施形態により、上の例の中央サーバの機能と類似する機能は、専用サーバコンピュータなどのオンサイトコンピューティングデバイス、「マスター」ホームオートメーションコンソールもしくはパネルによって、または図1のスマートホームデバイスのうちの1つまたは複数の付随機能として実行され得る。そのような実施形態では、不在時サービスロボットへの「away-service-OK」許可および感知された侵入検出信号に対する誤警報回避フィルタリングサービスもしくはフィルタ情報を与えるためにリモートサービスプロバイダへの依存性はない。
他の実施形態によれば、単一の全体的な事象統合化機能を必要とすることなく誤ホームセキュリティ警報および誤在室感知環境制御を回避しながら不在時サービスロボット機能を実装するための方法およびシステムが提供される。本開示の簡素化のために、不在時サービスロボット活動の動き、騒音、振動、または他の外乱によってトリガーされるホームセキュリティシステムおよび/または在室感知環境制御は、「活動感知システム」と単純に参照され、そのようにトリガーされたときに、誤トリガーを表す「外乱検出」結果を生じる(例えば、セキュリティサービスへの警報メッセージ、または家をより快適な「在室」設定点温度まで暖房または冷房させる自動化セットバックサーモスタットに対する「到着」決定)。一実施形態によれば、不在時サービスロボットは、不在時サービス活動の過程全体にわたって標準的な超音波を放射するように構成され、活動感知システムは、その標準的な超音波を検出するように構成され、活動感知システムは、その標準的な超音波が検出される限り外乱検出結果が生じないようにさらに構成される。他の実施形態について、不在時サービスロボットは、不在時サービス活動の過程全体にわたって標準的な通知信号を放射するように構成され、活動感知システムは、その標準的な通知信号を検出するように構成され、活動感知システムは、その標準的な通知信号が検出される限り外乱検出結果が生じないようにさらに構成され、標準的な通知信号は、光通知信号、音響通知信号、赤外線通知信号、超低周波通知信号、ワイヤレス送信データ通知信号(例えば、IPブロードキャスト、マルチキャスト、もしくはユニキャスト通知信号、またはTCP/IP双方向通信システムで送信される通知メッセージ)のうちの1つまたは複数を含む。
いくつかの実施形態によれば、不在時サービスロボットによって活動感知システムに送信される通知信号は、通知が延在的強盗によって学習され、複製されないように認証され暗号化される。さまざまな知られている暗号化/認証スキームが、限定はしないがサードパーティデータセキュリティサービスまたは証明機関を伴う方法を含むそのようなデータセキュリティを保証するために使用され得る。いくつかの実施形態について、許可要求応答モデルを使用することができ、そこでは、特定の不在時サービスロボットが、不在時サービス作業を実行する準備が整ったときに家の中のそれぞれの活動感知システムに許可を要求し、それぞれの活動感知システムから(または活動感知システムのすべてに対する「スポークスマン」としての機能を果たす単一の活動感知システムから)「yes」または「permission granted」メッセージを受信するまでそのような活動を開始しない。中央事象統合機能を必要としない説明されている実施形態の一利点は、一方の(オプションとして)ホームセキュリティ/環境制御機器のサプライヤーと他方の不在時サービスロボットのサプライヤーとの間の対等の関係以上のものがあり得ることであり、各サプライヤーが合意すべき説明されている標準的な一方向通知プロトコルまたは説明されている標準的双方向要求/許可プロトコルがあるということだけが必要である。
いくつかの実施形態によれば、活動感知システムは、それぞれの不在時サービスロボットの不在時サービス活動に本質的に関連付けられている音、振動、RF放射、または他の検出可能な環境信号もしくは「シグネチャ」を検出するように構成され、その特定の検出可能な信号または環境の「シグネチャ」が検出される限り外乱検出結果が生じないようにさらに構成される。例えば、特定の種類の真空掃除不在時サービスロボットは、特定の音またはRFシグネチャを発することができる。一実施形態について、複数の知られている不在時サービスロボットのそれぞれに対する不在時サービス環境シグネチャは、経験的に収集されたデータ、活動感知システムによって供給され、およびリモート更新サーバによって定期的に更新されている環境シグネチャに基づき活動感知システムのメモリ内に格納される。別の実施形態について、活動感知システムは、それらが取り付けられている特定の家に対する「学習モード」に入ることができ、学習セッションにおいてその家に対する不在時サービスロボットの特定の環境シグネチャを「聴き」、「学習し」、その後、それらの環境シグネチャが聴かれる間隔について外乱検出結果を抑制する。さらに、後述するように、音波または視覚による感知を使用して、音波または視覚刺激を検出するスマートデバイスの所定の範囲(例えば、音波または視覚検出の範囲)内にユーザがいることを検証することができる。
活動感知システムがホームセキュリティシステムではなく在室感知環境機器と関連付けられているときに特に有用である、ある実施形態について、活動感知システムは、検出された環境シグネチャと検出された在室活動との間の時間の経過による相関を自動的に求めることによって不在時サービスロボットに対する環境シグネチャを自動的に学習するように構成される。例えば、一実施形態について、Nest Learning Thermostatなどのインテリジェント型自動化非在室トリガーセットバックサーモスタットは、音響およびRF活動を常時監視し、さらには赤外線ベースの在室検出を実行するように構成され得る。不在時サービスロボットの環境シグネチャが事象から事象に移る間に比較的一定しているという事実を特に鑑みて、また不在時サービス事象が、(a)それ自体、不在時サービスロボットそれ自体によって測定されるような何らかの種類の非在室状態によってトリガーされるか、または(b)規定時刻に生じるという事実を鑑みて、事象それ自体が明らかになり、環境シグネチャが容易に学習され得るパターンが収集されたデータ中にある。概して、不在時サービスロボットの環境シグネチャがユーザによるインタラクティブな操作を必要とすることなく自動的に学習されるこの自動学習実施形態について、一定数の誤トリガーが学習プロセスの過程において許容可能であることがより好ましい。したがって、この自動学習実施形態は、誤った在室決定が少なければ不要な暖房または冷房の発生が少なくなり得るが、それ以外は重大な結果をもたらすことはなく、誤ったホームセキュリティ警報はより重大な結果を引き起こし得るという理由により、ホームセキュリティシステムよりはむしろ在室感知環境制御機器(自動化セットバックサーモスタットなど)において適用するのにより好ましい。
いくつかの実施形態によれば、中央サーバまたはクラウドコンピューティングシステム164に用意されたルールベースの推論エンジンまたは人工知能と組み合わせたスマートホーム環境のメッシュネットワーク内に配置されたスマートデバイスのセンサを含む技術は、家の個別の居住者に対して個人的な「スマートアラームクロック」を提供するために使用される。例えば、ユーザ居住者は、自分のモバイルデバイス166を介して中央サーバまたはクラウドコンピューティングシステム164と通信し、スマートアラームクロックに対するインターフェイスにアクセスすることができる。そこで、居住者は、自分の「スマートアラームクロック」をオンにし、翌日および/または追加の日に対する起床時間を入力することができる。いくつかの実施形態では、居住者は、それぞれの曜日について特定の起床時間を設定するオプション、さらには「繰り返す」入力された起床時間のうちのいくつか、またはすべてを設定するオプションを有し得る。人工知能は、これらのアラームが停まったときにそれに対する居住者の反応を考慮し、時間を追ってユーザの好ましい睡眠パターンに関して推論するために使用される。
いくつかの実施形態によれば、居住者が眠りに落ちたときにたまたま居住者に最も近い位置にあるスマートホーム環境100内のスマートデバイスは、居住者が動くのを止めたときに関するメッセージを送信するデバイスであり、そこから中央サーバまたはクラウドコンピューティングシステム164が居住者がいつどこで眠るのを好むかに関して推論する。この最も近いスマートデバイスは、居住者を目覚めさせるアラームを鳴らすデバイスでもある。この方法で、「スマートアラームクロック」は、スマートデバイス内に配置されているセンサから取得されたデータに基づき決定される、「一意的シグネチャ」に基づき個別の居住者を追跡することによって、家全体にわたって居住者に追随する。例えば、センサは、超音波センサ、受動的IRセンサ、および同様のものを含む。一意的シグネチャは、歩き方、移動のパターン、声、身長、サイズなどの組み合わせに基づく。顔認識も使用できることは理解されるであろう。
一実施形態により、「スマートアラームクロック」に関連付けられている起床時間は、HVACを効率的に制御するためにスマートサーモスタット102によって使用され、これにより、家を居住者の所望の「睡眠」および「覚醒」温度設定に合わせて予熱または冷房する。好ましい温度設定は、居住者が眠りに入る前にサーモスタットをどの温度に設定するか、また居住者が目覚めた後にサーモスタットをどの温度に設定するかを観察するなど、時間をかけて学習され得る。
一実施形態により、デバイスは、隣接するナイトスタンドなど、居住者のベッドの近くに位置決めされ、騒音センサ、モーションセンサ(例えば、超音波、IR、および光)などを使用して居住者が眠るときのデータを収集する。データは、室内の他のスマートデバイスによっても同様に取得され得る。そのようなデータは、居住者の呼吸パターン、心拍数、動きなどを含み得る。居住者が実際に目覚めたときを示すデータと組み合わせてこのデータに基づき推論がなされる。例えば--定期的に--居住者の心拍数、呼吸、および移動がすべて、毎朝居住者が目覚める20から30分前に5%から10%に増える場合に、居住者がいつ目覚めるかに関して予測が行われ得る。家の中の他のデバイスは、これらの予測を使用して、居住者が目覚める前に家を居住者の所望の設定に予熱または冷房するためにスマートサーモスタット102を調整することなど、他のスマートホームの目的を達成することができる。さらに、これらの予測を使用して、居住者に対して「スマートアラームクロック」を設定する、照明をオンにするなどの操作を行うことができる。
いくつかの実施形態によれば、中央サーバまたはクラウドコンピューティングシステム164に用意されたルールベースの推論エンジンまたは人工知能と組み合わせてスマートホーム環境中に配置されるスマートデバイスのセンサを含む技術は、アルツハイマー病の進行を検出または監視するために使用される。例えば、居住者の一意的シグネチャは、スマートホーム環境100全体にわたる個別の居住者の移動を追跡するために使用される。このデータは、アルツハイマーを示すパターンを識別するために集約され、分析され得る。しばしば、アルツハイマーを患っている個人は、自分の家の中をあちこち移動する明確に区別できるパターンを有する。例えば、人は、台所まで歩いて行き、そこにしばらく立ち止まり、次いで、リビングルームに行き、そこにしばらく立ち止まり、次いで、台所に引き返す。このパターンは約30分を要し、その後、人はこのパターンを繰り返す。いくつかの実施形態によれば、リモートサーバまたはクラウドコンピューティングアーキテクチャ164は、スマートホーム環境のメッシュネットワークによって収集された人の移動データを分析してそのようなパターンを識別する。
図2は、図1のスマートホーム環境100などの複数のスマートホーム環境と統合できる拡張可能なデバイスおよびサービスのプラットフォーム200のネットワークレベルを示している。拡張可能なデバイスおよびサービスのプラットフォーム200は、リモートサーバまたはクラウドコンピューティングアーキテクチャ164を備える。スマートデバイスの各々は、リモートサーバまたはクラウドコンピューティングアーキテクチャ164と通信することができる。例えば、インターネット162への接続は、直接的に(例えば、ワイヤレスキャリアへの3G/4G接続を使用して)、ワイヤレスメッシュネットワーク(単純なワイヤレスルーターから、例えば、インテリジェント型の専用の家全体の制御ノードに至るスキームとすることができる)を通じて、またはこれらの組み合わせを通じて確立され得る。スマートネットワークは、ハブ212を使用してインターネット162に結合することができる。
本明細書に提示されているいくつかの例において、デバイスおよびサービスのプラットフォーム200は、図1のスマートホーム環境100のスマートデバイスと通信し、そのスマートデバイスからデータを収集するが、デバイスおよびサービスのプラットフォーム200は、世界中の複数のスマートホーム環境と通信し、データを収集し得ることは理解されるであろう。例えば、中央サーバまたはクラウドコンピューティングシステム164は、1つまたは複数のスマートホーム環境のデバイスからホームデータ202を収集することができ、デバイスは、定期的にホームデータを送信するか、または特定の場合(例えば、デバイスがホームデータ202を問い合わせるとき)にホームデータを送信することができる。したがって、デバイスおよびサービスのプラットフォーム200は、定期的に、世界中の家庭からデータを収集し得る。説明されているように、収集されたホームデータ202は、例えば、消費電力データ、在室データ、HVAC設定および使用度データ、一酸化炭素レベルデータ、二酸化炭素レベルデータ、揮発性有機化合物レベルデータ、睡眠スケジュールデータ、調理スケジュールデータ、内部および外部温度湿度データ、テレビ視聴者数データ、内部および外部騒音レベルデータなどを含む。
中央サーバまたはクラウドコンピューティングアーキテクチャ164は、1つまたは複数のサービス204をさらに提供することができる。サービス204は、例えば、ソフトウェア更新、カスタマーサポート、センサデータ収集/ロギング、天気予報、アカウント情報、リモートアクセス、リモートまたは分散制御、または使用提案(例えば、性能を改善する、光熱費を低減するなどのために収集されたホームデータ202に基づく)を含み得る。サービス204に関連付けられているデータは、中央サーバまたはクラウドコンピューティングシステム164側に格納され、中央サーバまたはコンピューティングシステム164は、適切なタイミングで(例えば、規則正しい間隔で、ユーザから要求を受信した後などに)データを取り出し、送信することができる。
図2に例示されているように、拡張可能なデバイスおよびサービスのプラットフォーム200の一実施形態は、制限することなく、単一のサーバに集中させるか、またはいくつかの異なるコンピューティングエンティティ間に分散させることができる、処理エンジン206を備える。処理エンジン206は、スマートホーム環境のデバイスからデータを(例えば、インターネットまたはハブ型ネットワークを介して)受信し、データにインデックスを付け、データを分析し、および/または分析に基づきもしくは分析の一部として統計量を生成するように構成されたエンジンを含み得る。分析されたデータは、導出されたホームデータ208として格納され得る。
分析の結果または統計量は、これ以降、結果を導き出すために使用されるホームデータを提供したデバイス、他のデバイス、デバイスのユーザにウェブページを提供するサーバ、または他の非デバイスエンティティに送信して送り返すことができる。例えば、使用統計量、他のデバイスの使用に関する使用統計量、使用パターン、および/またはセンサ読み取り値を要約した統計量が、処理エンジン206によって生成され、送信され得る。これらの結果または統計量は、インターネット162を介して提供され得る。この方式で、処理エンジン206は、ホームデータ202からさまざまな有用な情報を導き出すように構成され、プログラムされ得る。単一のサーバに、1つまたは複数のエンジンを備えることができる。
導き出されたデータは、家、近所、または地域毎のデバイスの例示的なプログラムされた制御(例えば、電力事業のための需要応答プログラム)から、家毎に支援することができる推論抽象化の生成(例えば、家の所有者がバケーションに出かけたため、防犯用検出機器を最高感度に設定できるという推論を下せる)、政府または公益目的に使用され得る統計量および関連する推論抽象化の生成に至る、さまざまな有用な目的のためにさまざまな異なる粒度で高度に有益であり得る。例えば、処理エンジン206は、デバイスの集団におけるデバイス使用度に関する統計量を生成し、その統計量をデバイスユーザー、サービスプロバイダ、または他のエンティティ(例えば、統計量に対する金銭的補償を要求したか、または提供している可能性のある)に送信することができる。
いくつかの実施形態によれば、ホームデータ202、導出されたホームデータ208、および/または別のデータが、「自動化近隣セーフティネットワーク(automated neighborhood safety network)」を作成するために使用され得る。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ164が、特定の家庭が押し入られたこと、火事、または他の何らかの種類の非常事態を示すデータを受信した場合、警報が「近所」の他のスマートホームに送信される。いくつかの場合において、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、非常事態が発生している家のある半径内にあるスマートホームを自動的に識別し、警報を識別された家に送信する。このような場合、「近所」の他の家は、セーフティネットワークの一部となるようにサインアップまたは登録しなくてよいが、その代わりに、非常事態の位置への近接度に基づき非常事態の通知を受ける。これは、堅牢な発展型の近隣安全監視ネットワークを構成し、したがって、ある人の家が押し入られようとしている場合、警報が近くの家に、例えば、これらの家に配置されているスマートデバイスを介した音声告知などによって送信され得る。それに加えて、またはその代わりに、近隣のハザード検出器が煙を検出した場合、近隣住宅は灌漑システムを作動させて火災が広がる可能性を低減することができる。このセーフティネットワークは、選択サービスであってよく、中央サーバまたはクラウドコンピューティングアーキテクチャ164が警告の送り先となる家を選択することに加えて、またはその代わりに、個人がサブスクライブしてそのようなネットワークに参加することができ、また個人が、どの家から警告を受けたいかを指定することができることは理解されるであろう。これは、例えば、異なる市に住んでいる家族の家を含むことができ、したがって、個人は、他の場所に居る自分の愛する人たちが非常事態にあるときに警告を受信することができる。
いくつかの実施形態によれば、スマートデバイスの音、振動、および/または動き感知コンポーネントが、流水によって引き起こされる音、振動、および/または動きを検出するために使用される。検出された音、振動、および/または動きに基づき、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、家庭内の水使用量に関して推論し、関係するサービスを提供する。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、水がどのような音を発生しているか、またいつ家庭内を流れているかを認識するプログラム/アルゴリズムを実行することができる。一実施形態によれば、家庭のさまざまな水資源をマッピングするために、流水を検出した後、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、水が現在流れているかどうか、または水が家庭内で最近流されたかどうか、もしそうであれば、どの部屋、どの水消費アプライアンス(例えば、シンク、シャワー、トイレなど)が水源であったかを尋ねるメッセージを居住者のモバイルデバイスに送信する。これは、中央サーバまたはクラウドコンピューティングアーキテクチャ164が家の中のそれぞれの水源の「シグネチャ」または「指紋」を決定することを可能にする。これは、ときには、本明細書において「水使用量音声指紋採取(audio fingerprinting water usage)」と称されることがある。
例示的な一例において、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、主浴室内のトイレに対するシグネチャを作成し、そのトイレで水が流された場合に必ず、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、そのときの水使用量がそのトイレに関連していることを知る。したがって、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、そのトイレ、さらには家の中のそれぞれの水消費用途の水使用量を追跡することができる。この情報と、水道料金の請求書またはスマート水道メーターとの相関関係を求めて、ユーザに、水使用量の内訳を提示することができる。
いくつかの実施形態によれば、スマートデバイスの音、振動、および/または動き感知コンポーネントは、ネズミおよび他の齧歯類、さらにはシロアリ、ゴキブリ、および他の昆虫(「害虫」と総称される)によって引き起こされる音、振動、および/または動きを検出するために使用される。検出された音、振動、および/または動きに基づき、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、家庭内の害虫検出に関して推論し、関係するサービスを提供する。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、特定の害虫がどのような音をたてるか、どのように移動するか、および/または発生する振動を、個別に、および/またはまとめて認識するプログラム/アルゴリズムを実行することができる。一実施形態によれば、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、特定の種類の害虫の「シグネチャ」を決定することができる。
例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ164が、害虫に関連付けられ得る音を検出した場合、これは、そのような音を居住者に通知し、害虫防除会社を雇うよう提案する。害虫が実際に存在していると確認された場合、居住者は、中央サーバまたはクラウドコンピューティングアーキテクチャ164に、その検出が正しいことを示す確認を、名前、種類、説明、場所、数などの識別された害虫に関する詳細と共に入力する。これは、中央サーバまたはクラウドコンピューティングアーキテクチャ164がより適切に検出できるように自動「チューニング」し、特定の種類の害虫に対する「シグネチャ」または「指紋」を作成することを可能にする。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、このチューニング、さらにはシグネチャおよび指紋を使用して、同じ害虫の問題を抱えていると思われる近所の家庭など、他の家庭の害虫を検出することができる。さらに、例えば、「近所」の2つまたはそれ以上の家庭が同じまたは類似の種類の害虫の問題を抱えている場合、中央サーバまたはクラウドコンピューティングアーキテクチャ164は、近隣の家庭もそのような問題を有し得るか、またはそのような問題を有することの影響を受けやすいという推論を行って、警告メッセージをそれらの家庭に送信し、早期検出および予防の促進を手助けすることができる。
いくつかの実施形態では、革新と研究とを促進し、ユーザが利用できる製品およびサービスを増やすために、デバイスおよびサービスのプラットフォーム200において、一連のアプリケーションプログラミングインターフェース(API)210を、慈善事業体222、政府機関224(例えば、食品医薬品局または環境保護庁)、学術機関226(例えば、大学の研究者)、企業228(例えば、関係する機器へのデバイス保証またはサービスを提供する、ホームデータに基づき広告をターゲットとする)、ガス・電力会社230、および別の他のサードパーティなどのサードパーティに公開する。API210はサードパーティシステムに結合され、サードパーティシステムに、サービス204、処理エンジン206、ホームデータ202、および導出されたホームデータ208を含む、中央サーバまたはクラウドコンピューティングシステム164と通信することを許してもよい。例えば、API210は、サードパーティによって実行されるアプリケーションに、中央サーバまたはクラウドコンピューティングシステム164によって実行される特定のデータ処理タスクを開始し、さらにはホームデータ202および導出されたホームデータ208への動的更新を受信することを可能にしてもよい。
例えば、サードパーティは、サービスおよび情報をユーザに提供するために中央サーバまたはクラウドコンピューティングシステム164と統合する、ウェブもしくはモバイルアプリなどのプログラムおよび/またはアプリケーションを開発することができる。このようなプログラムおよびアプリケーションは、例えば、エネルギ消費量を減らす、機先を制して欠陥機器を整備する、高いサービス需要に応じる準備をする、過去のサービス実績などを追跡する、または現在知られているか、もしくは今後開発されるさまざまな有益な機能もしくはタスクを実行するユーザを助けるように設計され得る。
いくつかの実施形態によれば、サードパーティアプリケーションは、ホームデータ202および導出されたホームデータ208から推論を行い、そのような推論は、いつ居住者が家に居るか、いつ眠るか、いつ調理するか、いつ私室でテレビを視聴するか、いつシャワーを浴びるかということを含み得る。これらの質問に対する回答は、関心のある情報、製品、およびサービスを提供することによって、さらにはターゲットとされる広告を提供することによってサードパーティが消費者に利益をもたらすのを助けることができる。
一例では、輸送会社は、人々が家に居る時間に関して推論を行うアプリケーションを作成する。このアプリケーションは、それらの推論を使用して、人々が家に居る可能性が最も高い時間に配達を行うようにスケジュールする。アプリケーションは、それらのスケジュールされた時間の前後に配達ルートを構築することもできる。これにより、輸送会社が荷物の配達を何回も試みなければならない状況を減らし、消費者が輸送会社から自分の荷物を受け取らなければならない回数を減らす。
図3は、処理エンジン206、さらには図1のスマートホーム環境100のデバイスなどのデバイスを特に参照している、図2の拡張可能なデバイスおよびサービスのプラットフォーム200の機能図300である。スマートホーム環境内に配設されているデバイスは、無数のさまざまな異なる個別の能力および制限を有し得るが、すべて、それぞれがデータコンシューマ302(DC)、データソース304(DS)、サービスコンシューマ306(SC)、およびサービスソース308(SS)であるという点で共通の特性を共有しているものと考えられ得る。有利には、デバイスがローカルの直接的な目的を達成するために必要な本質的制御情報を提供することに加えて、拡張可能なデバイスおよびサービスのプラットフォーム200は、これらのデバイスから流れ出る大量のデータを利用するように構成することもできる。その直接的機能に関してデバイスそれ自体の実際の動作を強化または最適化することに加えて、拡張可能なデバイスおよびサービスのプラットフォーム200は、さまざまな有用な目的を達成するためにさまざまな自動化された、拡張可能な、柔軟性の高い、および/またはスケーラブルな方法でそのデータの「目的を設定し直す」ことを対象とすることができる。これらの目的は、例えば、使用度パターン、デバイス効率、および/またはユーザ入力(例えば、特定の機能を要求する)に基づき事前に定義されるか、または適応的に識別され得る。
例えば、図3は、多数のパラダイム310を含むものとして処理エンジン206を示している。処理エンジン206は、一次または二次デバイス機能を監視し、管理する管理サービスパラダイム310aを備えることができる。デバイス機能は、ユーザ入力を与えられたデバイスの適切な動作を保証すること、侵入者が住居内に居るか、または住居内に入ろうとしているのを推定する(例えば、さらにそのような場合に応答する)こと、デバイスに結合されている機器の故障(例えば、電球が切れている)を検出すること、エネルギ需要反応事象を実装するか、または他の何らかの形で応答すること、または現在の、もしくは予測された将来の事象もしくは特性をユーザに警告することを含み得る。処理エンジン206は、デバイス使用度に基づきユーザの注目する特性(例えば、デモグラフィック情報)、要望、および/または製品を推定する広告/通信パラダイム310bをさらに備えることができる。次いで、サービス、販促、製品、またはアップグレードがユーザに対してオファーされるか、または自動的に提供され得る。処理エンジン206は、ソーシャルネットワークからの情報を使用するか、または情報をソーシャルネットワークに提供し(例えば、デバイス使用度に基づき)、および/またはユーザおよび/またはデバイスとソーシャルネットワークプラットフォームと相互のやり取りに関連付けられているデータを処理するソーシャルパラダイム310cをさらに備えることができる。例えば、ソーシャルネットワーク上の信頼できる連絡先に報告されるようなユーザのステータスは、照明検出、セキュリティシステム停止またはデバイス使用度検出器に基づき家にいつ居るかを示すように更新することが可能である。別の例として、ユーザは、デバイス使用度統計量を他のユーザと共有することができるものとしてよい。さらに別の例では、ユーザは、請求される電気料金を減らせるHVAC設定を共有することができ、他のユーザは、HVAC設定を自分のスマートサーモスタット102にダウンロードして、請求される自分の電気料金を減らすことができる。
処理エンジン206は、ユーザに異議、競合、規則、コンプライアンス規定、および/または報酬を通知する、および/または動作データを使用して異議を乗り切ったかどうか、規則または規定を順守しているかどうか、および/または報酬が獲得されたかどうかを判定する異議/規則/コンプライアンス/報酬パラダイム310dを備えることができる。異議、ルール、または規定は、省エネ、安全な生活(例えば、有毒物質または発癌物質への露出を低減する)、お金の節約および/または機器の延命、健康改善、避難訓練の実施などの取り組みに関係し得る。例えば、1つの異議は、1週間に1度サーモスタットを弱めることに参加することを伴い得る。この異議の履行に成功したものは、クーポン、仮想通貨、ステータスなどによって報われる。コンプライアンスに関しては、一例は、賃貸不動産所有者が賃借人は特定の所有者の部屋にアクセスすることを許されないという規則を作ることを伴う。人感センサを有する部屋の中のデバイスが、部屋がアクセスされたときに更新を所有者に送信することが可能である。
処理エンジン206は、外来ソースからの外来情報316を統合するか、または他の何らかの形で利用して、1つまたは複数の処理パラダイムの機能を改善することができる。外来情報316は、デバイスから受信されたデータを解釈する、デバイスの近くの環境(例えば、デバイスが封じ込められている構造物の外)の特性を判定する、ユーザから利用可能なサービスまたは製品を決定する、ソーシャルネットワークまたはソーシャルネットワーク情報を識別する、デバイスなどの近くのエンティティ(例えば、救急隊、警察、または病院などの公共サービスエンティティ)の連絡先情報を決定する、家または近所に関連付けられている統計的または環境的条件、傾向、もしくは他の情報を識別する、などのために使用され得る。
並外れて広範な、さまざまな利点が、通常のものから深いもの至る、説明されている拡張可能なデバイスおよびサービスのプラットフォーム200によってもたらされ、またその範囲内に収まり得る。したがって、「通常の」一例において、スマートホーム環境100のそれぞれの寝室は、スマート壁面スイッチ108、スマート壁面コンセント110、および/またはスマートハザード検出器104を備えることができ、これらはすべてまたは一部が、人感センサを備え、人感センサは、居住者が眠っているか、または目覚めているかを推論する(例えば、モーション検出、顔認識、可聴音パターンなどを用いて)こともできる。火災事象が感知された場合、離れたところにあるセキュリティ/監視サービスまたは消防署は、それぞれの寝室に何人の居住者がいるか、それらの居住者がまだ眠っている(もしくは動けない)か、または寝室から適切に退去しているかどうかの知らせを受ける。これは、もちろん、説明されている拡張可能なデバイスおよびサービスのプラットフォームが備える非常に有利な機能であるが、利用可能にすることができるより大きな「インテリジェンス」の潜在的可能性を真に示すことができる実質的により「深い」例があり得る。たぶんより「深い」例を用いることで、火災安全のために使用されている同じ寝室占有データについて、近隣の子供の成長および教育の社会的パラダイムの文脈において処理エンジン206によって「目的を設定し直す」こともできる。したがって、例えば、「通常の」例で説明されている同じ寝室占有およびモーションデータを収集し、特定の郵便番号の地域内の学童の睡眠パターンが識別され追跡され得る処理(適切に匿名化されて)に利用可能にできる。学童の睡眠パターンの局部的変動が識別され、例えば、地域の学校の異なる栄養プログラムに対して相関され得る。
II.スマートデバイス
導入として、図4は、住宅環境内における他の同様のデバイスと通信し得るデバイス410(たとえばサーモスタットおよび/またはハザード検出器)の例を図示する。ある実施の形態では、デバイス410は、1つ以上のセンサ412、ユーザインターフェイスコンポーネント414、電源416(たとえばライン電力接続および/またはバッテリを含む)、ネットワークインターフェイス418、プロセッサ420などを含み得る。特定のセンサ412、ユーザインターフェイスコンポーネント414および電源構成は、各デバイス410で同じまたは類似してもよい。しかしながら、いくつかの実施の形態では、各デバイス410は、デバイスタイプまたはモデルに基いて、特定のセンサ412、ユーザインターフェイスコンポーネント414および電源構成などを含んでもよいことが注目されるべきである。
センサ412は、ある実施の形態では、加速度、温度、湿度、水、供給電力、近接度、外部の動き、デバイスの動き、音声信号、超音波信号、光信号、炎、煙、一酸化炭素、全地球測位システム(GPS)信号、無線周波数(RF)、他の電磁信号または電磁場等のようなさまざまな特性を検出してもよい。したがって、センサ412は、温度センサ、湿度センサ、ハザード関連センサまたは他の環境的センサ、加速度計、マイクロホン、光学センサを、カメラ(たとえば、電荷結合素子もしくはビデオカメラ)、能動的もしくは受動的輻射センサ、GPSレシーバまたは無線周波数識別検出器および/または他の好適なセンサまで、およびそれらを含んで、含んでもよい。図4は単一のセンサを伴う実施の形態を示すが、多くの実施の形態は複数のセンサを含んでもよい。ある例では、デバイス410は1つ以上の一次センサおよび1つ以上の二次センサを含んでもよい。ここで、一次センサは、デバイスのコア動作(たとえばサーモスタットにおいて温度を検知することまたは煙検出器において煙を検知することなど)に対して中心のデータを検知してもよく、一方、二次センサは、他のタイプのデータ(たとえば動き、光または音)を検知してもよく、それをエネルギ効率目的、セキュリティ目的、安全性目的、および/またはスマート動作目的のために用いることができる。
デバイス410における1つ以上のユーザインターフェイスコンポーネント414はユーザから入力を受取ってもよく、および/またはユーザに対して情報を提示してもよい。受取られた入力を用いて1つまたは複数の設定を判断してもよい。ある実施の形態では、ユーザインターフェイスコンポーネントは、ユーザの動きに応答する機械的コンポーネントまたは仮想コンポーネントを含んでもよい。たとえば、ユーザは、摺動するコンポーネントを(たとえば垂直トラックまたは水平トラックに沿って)機械的に移動させるか、もしくは回転可能なリングを(円形のトラックに沿って)回転させることができ、またはデバイス410のタッチパッドを横切って、もしくはその上に物体(たとえば指)を移動させてもよい。そのような動きは設定の調整に対応してもよく、それは、ユーザインターフェイスコンポーネント414の絶対的な位置またはユーザインターフェイスコンポーネント414の変位に基づいて判断することができる(たとえば回転可能リングコンポーネントの10度の回転ごとに1°Fだけ設定点温度を調整することなど)。物理的な可動ユーザインターフェイスコンポーネントおよび仮想可動ユーザインターフェイスコンポーネントは、ユーザが、明らかな連続体の一部に沿って設定することを可能にすることができる。したがって、ユーザは、(たとえばアップボタンおよびダウンボタンが用いられる場合にそうであるように)2つの別個のオプションの間で選択を行なうことに制限されなくてもよく、可能な設定値の範囲に沿って設定を迅速かつ直感的に規定することができる。たとえば、ユーザインターフェイスコンポーネントのある移動のある大きさはある設定調整のある大きさと関連づけられてもよく、ユーザは設定を大きな移動で劇的に変えたり、設定を小さな移動で微調整してもよい。
ユーザインターフェイスコンポーネント414は、さらに、1つ以上のボタン(たとえばアップボタンおよびダウンボタン)、キーパッド、数値パッド、スイッチ、マイクロホン、および/またはカメラ(例えば、身振りを検出するために)を含んでもよい。ある実施の形態では、ユーザインターフェイスコンポーネント414はクリックおよび回転環状リングコンポーネントを含んでもよく、ユーザは、(たとえば設定を調整するよう)リングを回転することによって、および/または(たとえば調整された設定を選択するかもしくはオプションを選択するよう)リングを内方向にクリックすることによって、そのコンポーネントと対話することを可能にしてもよい。別の実施の形態では、ユーザインターフェイスコンポーネント414は、カメラを含んでもよく、(たとえばデバイスの出力または警報状態が変更されることになる旨を示すべく)身振り(ジェスチャ)を検出してもよい。いくつかの例では、デバイス410は1つの一次入力コンポーネントを有してもよく、それを用いて複数のタイプの設定を設定してもよい。ユーザインターフェイスコンポーネント414は、さらに、情報を、ユーザに対して、たとえば視覚ディスプレイ(たとえば薄膜トランジスタディスプレイまたは有機発光ダイオードディスプレイ)および/または音声スピーカを介して提示するよう構成されてもよい。
電源コンポーネント416は、電力接続および/またはローカルバッテリを含んでもよい。たとえば、電力接続は、デバイス410を、線間電圧源のような電源に接続してもよい。いくつかの例では、AC電源を用いて、(たとえば再充電可能な)ローカルバッテリを繰返し充電し得、バッテリは、後で、AC電源が利用可能でないときにデバイス410に電力を供給するよう用いられてもよい。
ネットワークインターフェイス418はデバイス410がデバイス間で通信することを可能にするコンポーネントを含んでもよい。ネットワークインターフェイスは、複数のネットワーク接続インターフェイスを含むことができる。言い換えれば、ネットワークインターフェイス418は、異なる通信方法を同時に使用してネットワークインターフェイス418がデバイス410を複数のネットワークおよび/または異なるデバイスに結合することを可能にする無線および/またはアンテナを含むことができる。例えば、いくつかの実施形態では、ネットワークインターフェイス418は、少なくとも1つの802.15.4無線、少なくとも1つのWiFi無線、少なくとも1つのブルートゥース無線、および/またはデバイスを複数のデバイスおよび/またはネットワークに接続することを可能にする他の無線を含んでもよい。ある実施の形態では、ネットワークインターフェイス418は、効率的ネットワーク層をその開放型システム間相互接続(OSI)モデルの一部として用いて通信してもよい。一実施の形態では、効率的ネットワーク層は、以下において図5を参照して詳細に記載されるが、デバイス410が、RIPngルーティング機構およびDTLSセキュリティスキームを用いて、IPv6タイプのデータまたはトラフィックをワイヤレスで通信することを可能にしてもよい。したがって、ネットワークインターフェイス418は1つまたは複数のワイヤレスカードまたは何らかの他の送受信機接続を含んでもよい。
プロセッサ420は、さまざまな異なるデバイス機能のうちの1つ以上をサポートしてもよい。したがって、プロセッサ420は、ここに記載される機能の1つ以上を実行および/または実行させられるよう構成ならびにプログラミングされる1つ以上のプロセッサを含んでもよい。一実施の形態では、プロセッサ420は、ローカルメモリ(たとえばフラッシュメモリ、ハードドライブ、ランダムアクセスメモリ)に記憶されるコンピュータコードを実行する汎用プロセッサ、専用プロセッサもしくは特定用途向け集積回路、それらの組合せを含んでもよく、および/または他のタイプのハードウェア/ファームウェア/ソフトウェア処理プラットフォームを用いてもよい。さらに、プロセッサ420は、非同期Javascript(登録商標)およびXML(AJAX)または同様のプロトコルを用いて、クラウドサーバから与えられる命令を実行するJava(登録商標)仮想マシン(JVM)を動作させることなどによって、中央サーバまたはクラウドベースのシステムによって遠隔で実行または司られるアルゴリズムのローカル化されたバージョンまたは対応物として実現されてもよい。例として、プロセッサ420は、ある場所(たとえば家屋または部屋)がある特定の人物によって占有されるかもしくは(たとえば1つ以上のしきい値に関して)ある特定数の人々によって占有されるかどうかまで、ならびにそれを含んで、その場所がいつ占有されるかを検出してもよい。一実施の形態では、この検出は、たとえば、マイクロホン信号を解析すること、(たとえばデバイスの前における)ユーザの移動を検出すること、扉もしくはガレージ扉の開閉を検出すること、無線信号を検出すること、受信された信号のIPアドレスを検出すること、またはある時間窓内で1つ以上のデバイスの動作を検出することなどによって生じ得る。さらに、プロセッサ420は、特定の居住者または物体を識別するよう、画像認識技術を含んでもよい。
ある実施の形態では、プロセッサ420は、さらに、高消費電力プロセッサおよび低消費電力プロセッサを含んでもよい。高消費電力プロセッサは、ユーザインターフェイスコンポーネント414などを動作させるような、計算集中型動作を実行してもよい。低消費電力プロセッサは、逆に、センサ412からの危険または温度を検出するなどのような、より複雑でないプロセスを管理してもよい。一実施の形態では、低消費電力プロセッサは、計算集中型プロセスのために高消費電力プロセッサを起動するかまたは初期化してもよい。
いくつかの例では、プロセッサ420は、望ましい設定を予測、および/またはそれらの設定を実現してもよい。たとえば、存在検出に基づいて、プロセッサ420は、たとえば、家もしくはある特定の部屋に誰もいないときに電力を節約するよう、またはユーザの好み(たとえば一般的な住宅での好みもしくはユーザに特定の好み)に従って、デバイス設定を調整してもよい。別の例として、特定の人物、動物または物体(たとえば子供、ペットまたは紛失した物体)の検出に基づいて、プロセッサ420は、その人物、動物または物体がどこにあるかの音声インジケータもしくは視覚インジケータを起動してもよく、または認識されない人物がある条件下(たとえば夜もしくは照明が消えているときに)検出される場合に警報もしくはセキュリティ特徴を起動させてもよい。
ある例では、デバイスは、第1のデバイスによって検出されるイベントが第2のデバイスの動作に影響を与えるように、互いと対話してもよい。たとえば、第1のデバイスは、(たとえばガレージにおいて煙を検出すること、ガレージにおいて照明における変化を検出すること、および/またはガレージにおいて熱を検出することによって)煙がガレージで検出されたことを検出し得る。第1のデバイスはこの情報を第2のデバイスに効率的ネットワーク層を介して送信し、第2のデバイスは、送信された情報に対する適切なアクションを実行できる(たとえば、家屋温度設定、照明設定、音楽設定、および/またはセキュリティ警報設定を調整し得る)。別の例として、第1のデバイスは(たとえば動きまたは突然の光パターンの変化を検出することによって)ユーザが玄関に接近するのを検出し得る。第1のデバイスは、(たとえばドアベルの音のような)一般的な音声もしくは視覚信号を出力させ、または(たとえば訪問者の存在を、ユーザが占有している部屋内において知らせるよう)場所に特化した音声もしくは視覚信号を出力させてもよい。
例として、デバイス410はNest(登録商標)学習サーモスタットのようなサーモスタットを含んでもよい。ここで、サーモスタットは、温度センサ、湿度センサなどのようなセンサ412を含んでもよく、サーモスタットは、そのサーモスタットが配置される建物内における現在の環境状態を判断してもよい。サーモスタットのための電源コンポーネント416は、サーモスタットが継続的な電源の近くに配置されることを考えることなく、建物内の任意の場所に配置され得るように、ローカルバッテリであってもよい。サーモスタットはローカルバッテリを用いて電力を供給され得るので、サーモスタットは、バッテリがめったに取替えられないように、そのエネルギ使用を最小限にし得る。
一実施の形態では、サーモスタットは、回転可能なリングがその上にユーザインターフェイスコンポーネント414として配置される円形のトラックを含んでもよい。したがって、サーモスタットが暖房、換気、空調(HVAC)ユニットなどを制御することによって建物の温度を制御するように、ユーザは、回転可能なリングを用いて、サーモスタットと対話するかまたはサーモスタットをプログラミングしてもよい。ある例では、サーモスタットは、そのプログラミングに基づいて、建物に人がいないかもしれないときを判断してもよい。たとえば、HVACユニットを延長された時間期間の間電源オフにされるよう保持するようにサーモスタットがプログラミングされる場合には、サーモスタットは、建物にはその時間期間の間人がいないことになる、と判断してもよい。ここで、サーモスタットは、建物に人がいないと判断したときには照明スイッチまたは他の電子デバイスをオフにするようプログラミングされてもよい。したがって、サーモスタットはネットワークインターフェイス418を用いて照明スイッチデバイスと通信して、建物に人がいないと判断されたときに照明スイッチデバイスに信号を送るようにしてもよい。この態様で、サーモスタットは、建物のエネルギ使用を効率的に管理し得る。
一般的に、スマートネットワークは、図5に示されるように開放型システム間相互接続(OSI)モデル450の一部であってもよい。OSIモデル450は、抽象化層に関する通信システムの機能を示す。つまり、OSIモデルは、ネットワーキングフレームワーク、またはデバイス間の通信がどのように実現され得るかを規定してもよい。一実施の形態では、OSIモデル450は6つの層、つまり物理層452、データリンク層454、ネットワーク層456、トランスポート層458、プラットフォーム層460、およびアプリケーション層462を含んでもよい。一般に、OSIモデル450における各層は、その上の層に従ってもよく、その下の層に従われてもよい。
このことを考慮して、物理層452は、互いと通信し得るデバイスのためのハードウェア仕様を与えてもよい。したがって、物理層452は、どのようにデバイスが互いと接続し、どのように通信リソースがそれらのデバイス間で共有され得るかを管理することをどのように支援するかなどを確立してもよい。
データリンク層454は、どのようにしてデータがデバイス間において転送され得るかを規定してもよい。一般に、データリンク層454は、送信されているデータパケットが伝送プロトコルの一部としてビットにエンコードおよびデコードされ得る態様を与えてもよい。
ネットワーク層456は、宛先ノードに転送されているデータがどのようにルーティングされるかを規定してもよい。ネットワーク層456は、さらに、アプリケーション層462におけるセキュリティプロトコルとインターフェイスして、転送されているデータの保全性を維持することを保証してもよい。
トランスポート層458は、ソースノードから宛先ノードへのデータのトランスペアレントな転送を規定してもよい。トランスポート層458は、さらに、トランスペアレントなデータの転送がどのようにして信頼性のあるままであるかを制御してもよい。したがって、トランスポート層458を用いて、宛先ノードに転送されるよう意図されるデータパケットが実際に宛先ノードに到達したことを検証してもよい。トランスポート層458において用いられてもよい例示的なプロトコルは、伝送制御プロトコル(TCP)およびユーザ・データグラム・プロトコル(UDP)を含んでもよい。
プラットフォーム層460は、トランスポート層458内において規定されるプロトコルに従ってデバイス間の接続を確立してもよい。プラットフォーム層460は、さらに、データパケットを、アプリケーション層462が用い得る形式に変換してもよい。アプリケーション層462は、ユーザと直接インターフェイスし得るソフトウェアアプリケーションをサポートしてもよい。したがって、アプリケーション層462は、ソフトウェアアプリケーションによって規定されるプロトコルを実現してもよい。たとえば、ソフトウェアアプリケーションは、ファイル転送、電子メールなどのサービスを与えてもよい。
ネットワーク層456は、インターネットプロトコルバージョン6(IPv6)に基づいた通信プロトコルを用いて、デバイス10間でデータをルーティングし得る。したがって、各デバイス410は、それ自体を、インターネット、ローカルネットワーク、ネットワークのグループ上のファブリックなどの上で識別するよう用いられる独自のアドレスを各デバイス410に与え得る128ビットのIPv6アドレスを含んでもよい。ある実施の形態では、ネットワーク層456は、デバイス間でデータをどのようにルーティングするかを判断するプロトコル(RIPng)を識別してもよい。図6に示すように、1つまたは複数の層を使用して、情報470(例えば、警報状態、セキュリティ情報など)をデバイス472と474との間で交換することができる。
III.BLEを介したデバイス間の通信
Bluetooth(登録商標)低エネルギ(BLE)は、2つのデバイス間に比較的低電力の接続を提供するワイヤレスパーソナルエリアネットワーク通信タイプである。BLEは、BLEアプリケーションを使用するために汎用属性(GATT)プロファイルを(属性プロファイルの一部として)提供する。GATTプロファイルは、BLE接続で「属性」として知られる短いデータを送受信するためのメカニズムを提供する。GATTは、BLEのほとんどまたはすべての実装例で一般に利用可能である。したがって、他のプロファイルが利用可能であってもよいが、GATTは、スマートネットワークデバイスおよび/またはパーソナル電子デバイス(例えば、携帯電話、iPad(登録商標)など)上で広く利用可能であり得る。
GATTは、複数の特性の概念に基づいて構築されている。各特性には最大サイズ512バイトの固定幅の値が1つあり、ほとんどの実装例で128バイトが使用される。一般に、特性には、一貫したサイズ(例えば、16ビット、128ビット)を有する汎用一意識別子(UUID)が割り当てられる。特性は、各々独自のUUIDを持つGATTサービスとして知られているセットにグループ化される。
BLE対話は、図7に示すようなクライアント役割とサーバ役割とを有するものとして特徴付けることができる。図示のように、GATT対話500は、クライアント502およびサーバ504の役割の両方を含む。クライアント502は、BLE中央デバイスと呼ばれてもよく、サーバは、BLE周辺デバイスと呼ばれてもよい。クライアントデバイス502は、サーバデバイス504の特性508の1つまたは複数に読出要求506を発行することによって、サーバデバイス504からデータを読出す。クライアントは、1つまたは複数の特性508を更新するために書込要求510を発行することができる。以下に説明するように、ある一般サービスは、双方のデバイスがBLEを双方向データ通信として扱うことを可能にするGATTテーブルを提供する。GATTサーバ504は、特性508をホストし、GATTクライアント502に、特性508を読出し、書込み、および/または契約利用する能力を提供する。さらに、いくつかの実施形態では、一般サービスはすべてのBLE広告に含まれるので、デバイスペアリング、警報解除、またはBLEを介して通信するのに好適な他の用途など、多数の使用例でデバイス間の双方向通信を可能にするために、一般サービスを使用することができる。いくつかの実施形態では、GATTサーバ504は、デバイス間の双方向通信のために1つまたは複数の特性508を各々が含む1つまたは複数のサービス512を実装することができる。さらに、いくつかの実施形態では、各特性508は、異なるタイプおよび/または許可を有することができる。例えば、第1の特性508は、クライアントに読出および書込能力を提供し、別の特性514は、クライアントに、その中の値の指示のみを読み出すかまたは見る能力をクライアントに提供する。
したがって、GATTサーバはGATTサービスを広告し、それらのサービス特性の標準値を維持する。GATTクライアントはGATTサーバに接続し、サーバの特性を書込み、読出し、または契約利用することができる。クライアントが特定の特性の値を契約利用している場合、サーバはこの特性の値を変更し、GATT指示を送信して、値が更新されたことをクライアントに通知してもよい。場合によっては、GATT読出要求、書込要求、契約利用要求、指示要求が、サーバから受信した肯定応答とともに確実に送信されてもよい。
GATTは論理リンク制御および適応プロトコル(L2CAP)によってサポートされ、それは次いでLE非同期接続(LE ACL)論理トランスポートによってサポートされているので、単一のGATT特性読取り、書込み、契約利用または指示は信頼できると見なすことができる。これらのレイヤーは、個々のGATT動作についてのエラー検出、データ再送信、およびフロー制御を提供する。
前述のように、異なるBLE実装例における最大転送単位(MTU)のサイズは、最小(例えば、23バイト)から最大(例えば、512バイト)の範囲であり得る。これらの値は、デバイスの機能に応じてローカルに判断される。場合によっては、ピア間でMTUサイズを交渉できる。クライアント502もサーバ504もMTUを知らない場合、サーバ504は、BLE仕様のため想定するのが安全である最大値として許容可能なフラグメントサイズ(例えば、20バイト)で応答することができる。この場合、たとえサーバ504がこの数字バイトよりも大きなペイロードを伴う指示を受信したとしても、サーバ504はペイロードの最初の数(例えば20)のバイトだけを読み出すことができる。いくつかの実施形態では、クライアント502は、常に128バイトの特性書込みを送信する。1つの接続イベントで特性データのすべてのバイトを転送できない場合は、複数の接続イベントを使用して特性データのバイトを転送する。さらに、ある実施形態では、MTUがペイロードのサイズから動的に判定されることを示すためにフラグメントサイズ値(例えば、2^16 −1、符号なし)を使用することができる。
図8は、クライアント502が特性508に書き込むときにおけるBLEサービス514を介するクライアント502とサーバ504との間の通信518を示す。クライアント502は、BLEサービス514の属性の1つに書き込むための属性書込み要求520を送信する。BLEサービス514は、キャラクタ508が書込まれたかまたは書込が試みられたことを通知する通知522をサーバ504に送信する。いくつかの実施形態では、BLEサービス514は、書込要求520に関する書込応答524、成功の確認、失敗の通知、および/または他の情報を送信する。同様に、第2の属性書込要求526は、通知528および書込応答530を呼び出す。このプロセスは、通信518のための最終的な属性書込み要求532がBLEサービス514に通知534および書込み応答536を送信させるまで続く。
図9は、サーバ504がBLEサービス512を介して特性514に書き込むときの通信540を示す。サーバ504は、BLEサービス512において特性514における属性を更新要求542で更新し、書込は書込指示544を介してクライアント502に示される。いくつかの実施形態では、クライアント502は、書き込まれたデータのクライアント502への転送の完了時に、書込確認546をBLEサービス512に送信する。そのような実施形態では、サーバ504は、データ損失の可能性を低減するために確認546を受信するまで、第2の更新要求548を送信するのを待ってもよい。第2の更新要求548がBLEサービス512で受信されると、属性書込指示550がクライアント502に送信され、確認552が呼び出される。このプロセスは、書込指示554および書込確認558を呼び出す最終属性更新要求556がサーバ504によって送信されるまで続く。
図10は、BLEサービス512を介したクライアント502とサーバ504との間の対話のブロック図を示す。図示の実施形態では、クライアント502からサーバ504に流れる通信は、第1の特性508を通って流れる。言い換えれば、クライアント502は、第1の特性508を介して送信された属性書込560を使用して、サーバ504にデータを送信する。更新された第1の特性は、特性更新通知562を介してサーバ504に送信される。いくつかの実施形態では、BLEサービス512は、別の書込み要求が送信されてもよいことをクライアント502に通知する書込み確認564を送信する。
サーバ504からクライアント502への通信は、第2の特性514を使用して送信することができる。例えば、サーバ504は、特性更新要求566をBLEサービス512に送信することができる。これに応答して、更新指示568をクライアント502に送信することができる。特定の実施形態では、クライアント502は、BLEサービス512に、クライアント502に対するデータ損失のリスクを冒すことなく新しい値で第2の特性514を更新できることを通知する指示受信確認570を送信する。
Weave(または他の通信プロトコル)がBLEを介して送信されてもよい。しかしながら、GATTは特性ベースの通信プロトコルであり、Weaveはメッセージベースのプロトコルである。さらに、単一のWeaveメッセージペイロードは、GATT特性の最大サイズより大きいかもしれない。例えば、1つのWeaveメッセージは、1,500バイトのサイズを有し得、一方、BLE実装は、通信をかなり小さい数(例えば、27バイトまたは128バイト)に制限し得る。したがって、Weaveを使用してスマートネットワークでBLEを使用するためには、上位層(例えば、アプリケーション層、トランスポート層など)は、GATT上に構築されたストリーミングソケット、Bluetooth転送プロトコル(BTP)を展開し得る。Weaveは、BTPを使用してWeaveメッセージを複数のフラグメントに分割し、複数のフラグメントは、各々単一のGATT書込または指示を介して送信され得る。さらに、前述のように、MTUは、少なくともいくつかの特性よりも大きくてもよい。特定の実施形態では、BLEクライアントに指示を送信するために使用される特性は、BLEハンドシェイクで交渉されるMTUのサイズに制限されてもよい。
BTPは、トランスポート層接続の独自の概念を基底のBLE接続の上に定義する。この設計は、2014年10月7日に出願され、その全体が引用により援用される、「Authenticated Session Establishment(認証されたセッション確立)」と題された米国特許出願第14/508,933号に教示されているような、証明書認証セッション確立(CASE)プロトコルまたはパスワード認証セッション確立(PASE)プロトコルのような、あるWeaveプロトコルが、BLEを介して機能することを可能にする。それは、また、BLEデバイス上でWeaveを使用するデバイスに、プロトコルバージョンの互換性をチェックさせ、特定のデータをBTP接続ハンドシェイクの一部として交換させもする。
Weaveメッセージフラグメントを送信するために、BTPは2つのGATT特性を定義する。1つはGATTクライアントからサーバに送信されるメッセージフラグメント用で、もう1つはサーバからクライアントに送信されるフラグメント用である。クライアントは、GATT書込を介して第1の特性上でフラグメントをサーバに送信する。クライアントが第2の特性を契約利用すると、サーバはそれを使用してフラグメントをGATT指示を介してクライアントに送信する。
いくつかの実施形態では、前述のように、BTPは、前のフラグメントの送信に応答してGATT書込みまたは指示確認が受信されるまで、第1のメッセージフラグメント以外のすべてを送信するのを待つことを含む。BTPが、追加のフラグメントを送信する前にGATT動作肯定応答を待たなかった場合、リモートGATTサーバまたはクライアントは、対応するGATT動作のいずれかを確認する前に所与の特性に対して受信したすべての値を集計し得る。さらに、いくつかのケースでは、サーバまたはクライアントは、実質的により大きなバッファおよび/または処理能力を有し得、フラグメントの少なくともいくつかが失われる前に肯定応答が使用されなかった場合には他のデバイスを直ちに圧倒し得る。換言すれば、最も最近受信された値だけがGATTスタックからアプリケーション層に渡されるであろう。特性値はlast−write−winsであるため、この挙動はGATTプロファイルに従っては正しいであろうが、そのような挙動はデータ損失のためBTPには悪いであろう。
A.BLEコントローラアーキテクチャ
GATTは、個々の書込および指示について、フロー制御、エラー検出、およびペイロード再送信を提供し得る。しかしながら、多くの実装例では、このフロー制御およびコアGATT機能の多くは、プラットフォームのホストプロセッサとは独立した別個のBLEコントローラチップによって管理される。
多くの実装例では、受信した書込要求および指示要求に応答してGATT肯定応答を送信するのはこのBLEコントローラである。コントローラは、これらの肯定応答を、受信したデータが実際に成功する前に、ホストプロセッサのアプリケーションプログラムに送信し得る。言い換えれば、受信したデータは、OSIモデルスタックを様々な層を介してアプリケーション層にバックアップして送信されないかもしれない。この理由から、GATT肯定応答は、所与のメッセージフラグメントがリモートBTPアプリケーションによって受信されたことを確認するのに十分ではないかもしれない。
さらに、埋め込みプラットフォームでは、BLEコントローラと、ホストプロセッサ上のBLEドライバと、ホストプロセッサのBLEアプリケーションとの間に非常に小さな待ち行列が存在することがある。リモートデバイスが、GATT書込または指示を、これらの待ち行列が空になり得るよりも速く送信すると、BLEコントローラによってGATTレイヤで肯定応答されたメッセージフラグメントは、ホストプロセッサ上のBTPスタックに対して成功する前に廃棄される。この問題を解決するために、BTPは送信側にバックプレッシャをかけるためのアプリケーション層メカニズムを提供する。このメカニズムを使用すると、送信側は、以前のすべての送信書込みまたは指示がリモートBLEコントローラによって肯定応答された場合でも、今後のGATT送信をいつ一時停止すべきかがわかる。
さらに、特定のBLEコントローラは、ホストプロセッサに送信される前に、ランダムなリセットを経験するかまたは肯定応答されたGATT特性の更新を廃棄し得る。BTPは、これらの障害を検出して回復できる機能を追加する。
B.エラー検出
GATTを介して送信されるデータの保全性は、不完全なメッセージ送信に対するL2CAPのペイロードエラー検出および再送信機能によって維持され得る。したがって、BTPによって検出されるL2CAPのペイロードエラー検出によって見逃されたエラーには、メッセージフラグメント全体が誤動作しているBLEコントローラによって廃棄または並べ替えられたエラーが含まれる。BLEコントローラがBLE会話中にリセットする場合、BTPメッセージフラグメントがGATTレイヤで肯定応答された後でも、それらのフラグメントを永久に廃棄し得る。BTPは、この障害シナリオを検出し、それが生じると接続をリセットしてメッセージデータ破損の可能性を減じてもよい。BLEコントローラがGATT特性書込または指示を並べ替える場合、BTPはこの障害を検出して接続をリセットして、メッセージデータの破損のリスクの可能性を低減してもよい。
C.メッセージフォーマット化
BTPメッセージフラグメントは、時系列順序が失われたときに肯定応答および/またはメッセージ再分類を可能にするシーケンス番号とともに送信される。BTPスタックは、そのもっとも最近受信したメッセージフラグメントの周期的な肯定応答を送信する。BTPスタックは、また、設定された期間内にそれ自身の送信されたフラグメントに対する肯定応答を受信しない場合に、接続を閉じる。接続の各側(例えば、サーバおよびクライアント)は、受信側の待ち行列が一杯になったときに、送信側にアプリケーション層(GATTに対する)バックプレッシャをかけるための受信ウィンドウを定義する。各側は、BTP接続が開いているが、送信すべきアプリケーションデータがないときには、周期的なキープアライブメッセージを送信する。
図11は、BTPを使用して送信されるデータのパケット600の実施形態を示す。パケット600は、送信されるメッセージのタイプを識別するヘッダフラグ602と、そのメッセージを前のメッセージの肯定応答として識別する肯定応答番号604と、メッセージストリングにおいてメッセージの順序を識別するシーケンス番号606と、メッセージおよび/または各パケットについて長さを示すメッセージ長608と、クライアント502とサーバ504との間で共有されるデータを含むフラグメントペイロード610とを含む。いくつかの実施形態では、1つまたは複数のヘッダフラグ602を単一のメッセージに含めることができる。例えば、メッセージは、メッセージフラグメントと肯定応答とを含むことができる。さらに、特定の実施形態では、フラグ値は、以下の表1に示すものから選択することができる。
メッセージ開始ヘッダは、メッセージがパケット600においてメッセージ長608を含むことを示す。いくつかの実施形態では、このメッセージ長は、メッセージ全体の長さを示し、現在記述されているパケット600におけるデータだけではない。メッセージ開始ヘッダはまた、シーケンス番号606およびフラグメントペイロード610がパケット600に含まれることを示す。メッセージデータヘッダは、交渉されたフラグメントサイズ(MTU)からヘッダオーバーヘッドを差し引いたデータ長を有する非終端メッセージフラグメント(すなわち、メッセージの終わりではない)の存在を示す。メッセージヘッダはまた、シーケンス番号606およびフラグメントペイロード610がパケット600に含まれることを示す。メッセージ終了ヘッダは、フラグメントペイロード610がメッセージの終わりを含むことを示す。このメッセージの長さは、メッセージ長608によって示されるように送信されていないメッセージのデータの残量によって判断される。メッセージ終了ヘッダはまた、パケット600がシーケンス番号606およびフラグメントペイロード610を含むことを示す。フラグメント肯定応答ヘッダは、シーケンス番号606またはフラグメントペイロード610が含まれているかどうかにかかわらず、肯定応答604がパケット600に含まれることを示す。キープアライブヘッダは、メッセージがシーケンス番号606をヘッダデータととともに含むが、他のフィールドは有さないことを示す。
D.シーケンス番号
シーケンス番号により、ローカルまたはリモートBLEコントローラがその受信したGATT要求をリセットまたは並べ替えたかどうかを検出できる。シーケンス番号はまた、BTP受信ウィンドウの判定およびキープアライブメッセージの送信を容易にする。
すべてのBTPメッセージフラグメントは、キープアライブフラグやデータペイロードのない肯定応答フラグメントを除いて、シーケンス番号とともに送信される。これらのシーケンス番号は、1とともに送信される各メッセージフラグメントに対して1だけ単調増加する符号なし8ビット整数である。シーケンス番号は、システムによって維持される各BTP接続ごとに別個に定義され、増分される。各接続ごとに、1つのデバイス上のBTPスタックは、送受信されたメッセージフラグメントに対して別個のシーケンス番号カウンタを維持する。新しいBTP接続が形成されると、そのシーケンス番号は開始番号(例えば、0)に初期化される。シーケンス番号は、シーケンス番号のために割り当てられた所定の数のビット(例えば8)で表されるよう利用可能なサイズを超えると、開始番号に折り返される。例えば、シーケンス番号に8ビットが割り当てられる実施形態では、利用可能なシーケンス番号は0〜255(例えば255=28−1)である。したがって、そのような実施形態では、シーケンス番号255を有するメッセージフラグメントの後に、シーケンス番号0を有するメッセージフラグメントが続く。
デバイスが予期しないシーケンス番号を持つメッセージフラグメントを受信すると、デバイスは対応するBTP接続をリセットする。このような障害は、L2CAPの信頼性メカニズムの障害またはBLEコントローラのエラーを示す。
1.シーケンス番号肯定応答
シーケンス番号肯定応答は、BTP受信ウィンドウをサポートする。シーケンス番号肯定応答は、接続の相手側のBTPスタックが稼動し続けていることを示す信号も提供する。
メッセージフラグメントを送信すると、BTPスタックは、タイマ(「肯定応答受信済み」タイマ)がまだ動作していなければ、このタイマを開始する。このタイマの継続時間は、「肯定応答タイムアウト間隔」として定義される。スタックは、最も最近送信され肯定応答されなかったメッセージフラグメント以外のものに対して有効なフラグメント肯定応答が受信されたときに、このタイマを再開する。フラグメント肯定応答は、BTPメッセージフラグメントにピギーバックされた符号なし8ビット整数として受信されるか、またはシーケンス番号もしくはメッセージペイロードのないスタンドアロン肯定応答として受信される。このタイマは、最も最近送信され肯定応答されなかったメッセージフラグメントについて肯定応答が受信されると、停止する。このタイマが満了するか無効なフラグメント肯定応答が受信されると、スタックは接続をリセットする。
肯定応答されたシーケンス番号Xが、ラップアラウンドを伴うシーケンス番号のリング上のYとZとの間の最短間隔内にない場合、フラグメント肯定応答は無効と見なされ、ここで、Yは最も古い、送信された、肯定応答されなかったメッセージフラグメントであり、Zは最も新しいそれである。
BTPスタックがシーケンス番号を持つメッセージフラグメントを受信すると、BTPスタックはこのシーケンス番号を接続の「保留中の肯定応答」値として記録し、タイマ(「肯定応答送信」タイマ)がまだ動作していなければ、このタイマを開始する。このタイマの持続時間は、送信側が肯定応答の欠如のために接続を閉じる前に肯定応答が受信されることを確実にするために、肯定応答タイムアウト間隔の半分として定義される。
保留中の肯定応答が送信されると、スタックはこのタイマを停止する。このタイマが満了して、スタックに保留中の肯定応答がある場合、肯定応答はシーケンス番号またはメッセージペイロードのないフラグメントとして直ちに送信される。このタイマが満了になる前にスタックがメッセージフラグメントを送信する場合、スタックは、保留中の肯定応答を送信されたメッセージフラグメントにピギーバックして、タイマを停止する。
いくつかの実施形態では、BTPスタックが、それの、送信すべき保留中の肯定応答の数が即時送信閾値(例えば、受信ウィンドウに残された2つ以下のメッセージフラグメント)に縮小したことを検出すると、それは即座に任意の保留中の肯定応答を送信する。
E.受信ウィンドウ
受信ウィンドウは、BTP接続において両方のデバイス間でGATT上においてアプリケーション層のフロー制御を可能にすることによって、適切なシーケンス化を保証する。受信ウィンドウは、予期せず折り返しからフラグメントシーケンス番号を遮断する。BTP接続の両方のデバイス(例えば、クライアントおよびサーバ)は、受信ウィンドウを定義し、ここで、ウィンドウサイズは、各側が肯定応答なしに確実に受信できると判断するシーケンシャルなメッセージフラグメントの数である。いくつかの実施形態では、BLE接続において両方のデバイスに対してBTP接続ハンドシェイクの一部として初期ウィンドウサイズが確立される。特定の実施形態では、受信ウィンドウは、保留中の対話に対して減分される最大サイズを有することができる。いくつかの実施形態では、受信ウィンドウは、可能なシーケンス番号の数の半分でキャップされる。たとえば、可能なシーケンス番号が0〜255の場合、最大ウィンドウサイズは127と定義され得る。受信ウィンドウにこのような制限を設定すると、肯定応答されないシーケンス番号のラップアラウンドが遮断される。例えば、このような制限は、メジアンシーケンス番号127を下回る、より古い期待される番号も受信され得るときに送信されるメッセージフラグメントに対する、より新しい初期シーケンス番号0を受信することを遮断する。
特定の実施形態では、双方は、お互いの現在の受信ウィンドウサイズを反映するようにカウンタを維持する。例えば、クライアント502は、サーバ504のウィンドウサイズを反映するようにカウンタを維持することができる。このカウンタは、新しいメッセージフラグメントが送信されるたびに減分される。メッセージ肯定応答が受信されると、カウンタは((肯定応答されたシーケンス番号−最も古い肯定応答されなかったシーケンス番号)+1)だけ増分される。カウンタが0の場合、送信側はカウンタが増分されるまでさらなるメッセージフラグメントを送信しないようにする。メッセージフラグメントの受信でカウンタが0から増分されると、送信側はただちにメッセージフラグメント送信を再開する。
いくつかの実施形態では、BLE接続においてBTPを使用する両方のデバイスは、それら自身の受信ウィンドウサイズのカウンタを維持する。これらのカウンタは、それぞれのデバイスによって受信された最後のメッセージフラグメントのシーケンス番号と、それぞれのデバイスによって送信された最後の肯定応答とに基づいている。このカウンタは、受信側のウィンドウサイズが0の場合に不要な遅延が発生しないように早期の肯定応答を送信するために使用される。言い換えれば、あるデバイスは、そのデバイスが肯定応答をピギーバックする可能性があるメッセージフラグメントをさらに待たずに、保留中のメッセージ肯定応答を送信することができる。デバイスは、肯定応答送信タイマがまだ動作しているかどうかに関係なく、保留中のメッセージ肯定応答を直ちに送信する。
F.キープアライブメッセージ
前述したように、いくつかのパケット600は、キープアライブメッセージとして示されてもよい。キープアライブメッセージを使用して、所与の接続におけるリモートBTPスタックがクラッシュまたは停止したかどうかを判断できる。したがって、接続がメッセージ層でアイドル状態になっている場合など、アプリケーションデータが送信されていない、または肯定応答されていない場合でも、キープアライブメッセージは接続を保証する。
BTPスタックは、それの肯定応答送信タイマを停止し、対応する接続においてBLE中央(例えば、クライアント502)の役割を果たすとき、キープアライブタイマを肯定応答タイムアウト間隔の半分の持続時間で開始する。任意のメッセージフラグメント(キープアライブメッセージまたは他のタイマ駆動型肯定応答を含む)を送信し、このタイマがすでに動作しているときに、このタイマを再始動する。シーケンス番号を持つメッセージフラグメントを受信すると、このタイマを停止する。保留中の肯定応答として、このフラグメントは明示的なキープアライブメッセージを生成しその有用性を一時的に取り除く。キープアライブ送信タイマが満了すると、スタックはキープアライブメッセージを送信し、タイマは再開される。通常のペイロード担持メッセージフラグメントと同様に、失われたキープアライブ肯定応答により、接続がリセットされる。
キープアライブメッセージは、有効なシーケンス番号を持つBTPメッセージフラグメントであるが、ヌルのペイロードである。キープアライブメッセージは、受信側によって肯定応答されるが、キープアライブメッセージは、BTPメッセージリアセンブラから次の上位層、すなわち上位プロトコルメッセージ層へとスタックを通過しない。BTPキープアライブメッセージは、したがって、メッセージトラフィックが存在しないことに基づいてアイドル状態のスマートネットワーク接続を自動閉鎖することを妨げない。
通常のペイロード担持メッセージフラグメントの場合と同様に、BLE中央デバイス上のBTPスタックは、周辺の受信ウィンドウが一杯になると、キープアライブメッセージを送信しない。
BTPスタックは、肯定応答受信タイマを停止し、対応する接続においてBLE周辺の役割(例えば、サーバ504)を果たすとき、キープアライブ受信タイマを肯定応答タイムアウト間隔の持続時間で開始する。このタイマは、BTPメッセージフラグメントを受信するたびに再起動される。このタイマは、肯定応答受信タイマが開始されると、停止される。キープアライブ受信タイマが満了すると、周辺デバイスはBTP接続をリセットする。
IV.広告
図12に示すように、第1のデバイス620と第2のデバイス622との間にBLE接続を確立する場合、デバイスの1つ(例えば、デバイス620)は、広告デバイス、接続されたネットワーク、および/または潜在的なBLE接続についてのさまざまな詳細を示す広告624を送信出力する。スマートネットワークデバイスは、限られた広告データスペースを使用するために一貫したフォーマットで広告する。たとえば、フォーマットを59バイトに制限し、広告に28バイトを指定し、スキャン応答に31バイトを指定してもよい。BLE広告は、広告デバイスが接続するデバイス、警報、通信タイプ、および/またはネットワークに関する様々な詳細を示すために使用することができる。例えば、BLE広告は、広告デバイスを他のデバイスと区別し、広告デバイスのための人が判読可能な名称を含み、広告デバイスのために、警報を発令している状態または警報を発令していない状態を示し、広告デバイスに接続されたデバイスのために、警報を発令している状態を示し、広告デバイスのクラスを識別し、広告デバイスがアカウントとペア設定されているかどうかを識別し、および/または広告デバイスへの結合から生じるBLE通信で使用されるサービスに関する様々な情報(すなわち、特性のグループ)を識別してもよい。
さらに、広告は、UUIDを使用してサポートされるBLEサービスの指示を含むことができる。例えば、一般サービスUUIDを使用して、デバイスが特定の通信プロトコル(例えば、Weave)を介して通信をサポートすることを示してもよい。それに加えて、またはこれに代えて、クリティカルイベントサービスUUIDを使用して、クリティカルイベント(例えば、煙が検出された)が発生し、緊急に注意を喚起すべきであることを示してもよい。いくつかの実施形態では、これらのサービスインジケータ(例えば、UUID)は、同じサイズ(例えば、16ビット)であってもよく、または他の何らかのサイズであってもよい。
A.一般サービス
特定のプロトコル(例えば、Weave)上でデータ通信が行われ得ることを示す一般サービスが含まれてもよい。広告デバイスがこのサービスをサポートするという指示を含ませることによって、広告デバイスおよび別のリモートデバイスは、前述のようにGATT構造を使用してBLEを介して通信してもよい。
前述したように、広告データは一般サービスUUIDを含むことができる。一般サービスUUIDに加えて、メタデータをこのサービスに関連付けることができる。特定の実施形態では、広告は、デバイスについての識別情報を含むことができる。加えて、または代替的に、いくつかの実施形態は、認証トークンを使用して識別情報の少なくとも一部を隠すことができる。例えば、広告は、モバイル認証デバイスに接続することも、それに関する情報を共有することもできないデバイスのブルートゥース範囲内で物理的に移動し得る当該モバイル認証デバイスに対して隠蔽/暗号化することができる。広告は、どのタイプの情報が含まれているかを示すことができる。従って、一般サービスを含む広告は、使用されるWeaveデータの種類を識別するサービスデータフィールドを含むことができる。例えば、このフィールドでは、第1の値(例えば、0x01)はデバイス情報が広告に含まれていることを示し、第2の値(例えば、0x02)はデバイス情報の明示的な記載なしに認証トークンが含まれていることを示す。いくつかの実施形態では、いくつかの情報を共有するが、他の情報を隠す、ハイブリッド通信タイプを含めることができる。さらに、いくつかの実施形態では、他の好適なデータブロックタイプをこのフィールドに符号化することができる。
BLE広告がデバイス情報を含む場合、広告は、以下の表2に表されるものと同様のフィールドを含むことができる。
表2は、デバイス情報における各フィールドのオクテットサイズの指示を含むが、いくつかの実施形態は、これらのサイズを実装要件に基づいて増減してもよい。デバイスクラスは、そのデバイスの製造業者またはベンダーを識別するベンダー識別子(ID)を含むことができる。デバイスクラスは、ベンダーによって提供される特定のデバイスタイプを識別する製品識別子を含むこともできる。デバイスIDは、スマートネットワークにおいてデバイスを識別するために使用される識別子であってもよい。例えば、デバイスIDは、スマートネットワークにおけるそのデバイスのためのノードIDであってもよい。アカウントペア設定ステータスは、デバイスがリモートサービス上のアカウントとペア設定されているかどうかを示す。いくつかの実施形態では、いくつかのアクション(例えば、警報の解除)は、リモートサービス上でアカウントにペア設定されるデバイスに制限される。言い換えれば、そのような実施形態では、リモートサービスにペア設定されていないハザード検出器を解除することはできない。さらに、いくつかの実施形態では、ハザード検出器がペア設定されるアカウントにアクセスを有する解除デバイスだけである。例えば、ハザード検出器がリモートサービスにペア設定されている場合、解除デバイス(例えば、携帯電話)がリモートサービス上でペア設定されたアカウントにアクセスすると解除デバイスに送られる解除鍵がそのサービスによって生成される。ハザード検出器は、この解除鍵なしでは解除コマンドを受け入れない。さらに、この解除鍵は、リモートサービス上で共通のアカウントとペア設定されるかまたはそのアカウントにアクセスを有する任意のデバイスに共通であってもよい。
認証トークンを含む広告では、ペイロードは少なくとも部分的に暗号化されていてもよい。いくつかの実施形態では、バージョン番号付けは、暗号化された広告を受信する承認されたデバイスに広告をどのように解読するかの指示を提供するために暗号化されなくてもよい。他の実施形態では、バージョン番号付けは、広告の残りの部分とともに、または認証トークンバージョン間で一貫して解読されるそれ自身の暗号化エンベロープにおいて、暗号化されてもよい。
B.クリティカルイベントサービス
デバイスにおいて緊急性を示す警報/イベントがある場合、広告は、一般サービスに加えて、またはその代わりに、付随するクリティカルイベントサービスについての詳細を含むことができる。この場合、広告は、UUIDのリストにおけるクリティカルイベントサービスがサポートされる旨の指示、およびクリティカルイベントを分類するイベント特有情報を含むであろう。
ネストデバイスがクリティカルイベントを伝える状態では、それは、広告のこのフィールドを利用することによってそのようにする。場合によっては、複数のクリティカルイベントが同時に発生することがある。
以下の表3に示すフォーマットと同様のフォーマットを使用して、複数のクリティカルイベントを単一の広告で伝達することができる。
表3はデータ長の例を含むが、いくつかの実施形態は様々なフィールドの長さを変えることができる。さらに、クリティカルイベントタイプは、送信される警報のタイプを示すことができる。いくつかの実施形態では、このクリティカルイベントタイプは、どのようなタイプのデバイスがクリティカルイベントを発生させたかを示すことができる。例えば、ハザード検出器からの警報(例えば、煙警報、CO警報、熱警報など)は、単一のクリティカルイベントタイプとして分類することができる。各イベントタイプは、広告においてイベントタイプフィールドに対応し、およびそれに従う、定義された長さのオクテットを有することができる。
以下の表4は、イベントタイプフィールドの後に続いてもよいタイプ固有イベントの考えられ得る例を示す。ここでも、以下の表は、各フィールドの可能な長さを含むが、いくつかの実施形態は、異なるフィールドサイズを有してもよく、および/または実装例間でフィールドサイズを変えてもよい。
クラスイベントバージョンは、クリティカルイベントがどの一般クラスに属するかを示す。例えば、クラスイベントは、検出された危険(例えば、煙、火災、COなど)、セキュリティ警報、灌漑問題、および/またはスマートネットワークで警告され得る他の適切なイベントタイプであり得る。警報異議は、任意の解除要求が適時であることを保証するために使用される。
警報情報は、クラスイベントに特有の警報タイプを示す上位ニブルを含む。例えば、検出された危険から生じる警報では、警報タイプを示す警報情報の上位ニブルは、以下の表5の値から選択することができる。
下位ニブルは、下の表6の値から選択され得る警報についての状態を示す。
C.広告における追加情報
サービスUUIDおよび関連情報に加えて、またはそれに代えて、いくつかの実施形態は、デバイスについて人間が判読可能な名称を含むことができる。例えば、いくつかの実施形態では、人間が判読可能な名称は、デバイスの名称を示す限界(例えば、4バイト)までの長さを有するオプションであってもよい。例えば、人間が判読可能な名称は、テキスト「d2」に対するバイナリ値を含むことができる。広告は、さらに、製造者固有のヘッダ(MSH)において追加の製造者固有のデータを含んでもよい。MSHは、製造業者に固有の広告データを示すADタイプを含むことができる。いくつかの実施形態では、このデータは1バイト(例えば、0xFF)を割り当てられてもよい。MSHはまた、製造者識別子コードを含むことができる。いくつかの実施形態では、この識別子は、所定の長さ(例えば、2バイト)を有してもよい。いくつかの実施形態では、この情報は、先に説明したベンダーIDから取得することができる。
D.データの分割
いくつかの実施形態では、広告に含まれるべきデータは、サイズ制約または他の制約のために、単一の広告パケットに含めることができない。そのような場合では、広告されるべきデータは、広告パケットとスキャン応答パケットとの間で分割されてもよく、それらの両方ともがスキャンデバイスに中継される。中央デバイスのオペレーティングシステムに基づいて、これらのパケットは別々のイベントとして報告されるかもしれないが、スキャンデバイスで相関付けされる。データの分割に基づいて、クリティカルな情報が優先され、スキャン応答パケットの前に送信される広告パケットに含まれてもよい。スキャン応答パケットは、後で(例えば、スキャンデバイスからのスキャン要求に応答して)提供されてもよい。
図13は、広告パケット632とスキャン応答パケット634とに分割される広告630の実施形態を示す。図示されているように、広告パケット632は、一般サービスおよびクリティカルイベントサービスのような、利用可能なサービス636のためのUUIDのリストを含む。さらに、クリティカルイベントが発生した場合、および/または発生している場合、広告パケット632はクリティカルサービスデータ638を含む。
よりタイムクリティカルでないデータは、広告パケット632とともに、および/または後で(例えば、スキャン要求に応答して)送信されてもよいスキャン応答パケット634に含まれてもよい。例えば、スキャン応答パケット634は、一般サービスデータ640、人間が判読可能な名称642、および/または送信出力レベル644を含むことができる。一般サービスデータ640および人間が判読可能な名称642は、先に説明した例示的な構造に準拠することができる。送信出力レベル644は、通信が発生するレベル(例えばdBで)を示すことができる。
E.広告例
1.警報を発令しないデバイス例
図14は、BLEを介してデバイスによって送信され得る広告650の実施形態を示す。いくつかの実施形態では、様々なフィールドのサイズおよび順序は変わる可能性がある。さらに、いくつかの実施形態では、フィールドのいくつかは、広告の少なくともいくつかの送信から省略されてもよい。特定の実施形態では、広告650は、広告全体の長さを示す長さフィールド652を含む。広告650はまた、どのようなタイプのデータが1つまたは複数の後続のフィールドに含まれているか、および/またはどのようなタイプのデータが長さフィールド652によって言及されているかを示すADタイプフィールド654を含む。いくつかの実施形態では、ADタイプフィールド654が、長さフィールド652が、長さフィールド652、ADタイプフィールド654、およびUUIDのリスト658を含むメタデータヘッダ656に関係することを示す値(例えば0x02)を有する場合。いくつかの実施形態では、長さフィールドは、長さフィールド652およびADタイプフィールド654が関係するデータチャンク(例えばメタデータヘッダ656)の長さを示す。さらに、いくつかの実施形態では、長さは、データチャンクの残りのフィールドの長さを示すことができる。例えば、そのような実施形態において、および、フィールドが図13に示すものに対応する長さを有する場合、長さフィールドは、UUIDのリスト658およびADタイプフィールドB4が3バイトの全長を有することを示す値3を有することができる。
いくつかの実施形態では、広告650は、人間が判読可能な名称データチャンク660を含むことができる。いくつかの実施形態では、この人間が判読可能な名称データチャンク660は、試験、診断、および/または他の適切な状況で使用するために、広告650を送信するデバイスについて短い識別情報を提供するために使用され得る、当該デバイスのために人間が判読可能な短い名称を提供する。ある状況では、単一のデバイスからの、および/または単一のネットワークにおけるいくつかの広告は、人間が判読可能な名称データチャンク660を含み得、ネットワークにおける他のメッセージおよび/またはデバイスは、人間が判読可能な名称データチャンク660なしで送信され得る。人間が判読可能な名称データチャンク660を含む広告(例えば広告650)において、人間が判読可能な名称データチャンク660は、長さフィールド662、ADタイプフィールド664、および名称フィールド666を含む。長さフィールド662は、人間が判読可能な名称データチャンク660の長さを示す。ADタイプフィールド664は、データチャンクが人間が判読可能な名称データチャンク660であることを示す値(例えば、0x16)を含み、受信側デバイスに人間が判読可能な名称データチャンク660の解釈方法を知らせる。名称フィールド666は、人間が判読可能なフォーマット(例えば、「t2」)で送信側デバイスを識別するために使用され得る文字列を含む。いくつかの実施形態では、文字列は、UTF−8またはその他の適切な文字符号化で表現されてもよい。
広告650はまた、一般サービスデータチャンク668を含む。一般サービスデータチャンク668は、一般サービスデータチャンク668の長さを識別する長さフィールド670と、一般サービスデータチャンク668が一般サービスタイプであることを示す値(例えば0x16)を含むADタイプフィールド672とを含む。一般サービスデータチャンク668はまた、一般サービスのための一般サービスUUID674を含む。いくつかの実施形態では、一般サービスデータチャンク668は、広告に含まれるネットワーク/デバイスデータについてのデータブロック長フィールド676も含む。言い換えれば、データブロック長フィールド676は、一般サービスUUID674および関連する全チャンクメタデータフィールド(例えば、長さフィールド670およびADタイプフィールド672)以外の一般サービスデータチャンク668の長さを示す。いくつかの実施形態では、データブロック長フィールド676は、長さがデータブロック長フィールド676に含まれていない一般サービスデータチャンク668のフィールドが広告間においてサイズが一貫し得るため、省略することができる。
一般サービスデータチャンク668はまた、データブロック長フィールド676(存在する場合)および後続のデータをデバイスおよび/またはその接続されたネットワークに関連するデータとして識別するデータブロックタイプフィールド678を含むことができる。
一般サービスデータチャンク668はまた、広告650を受信するデバイスに広告650の解釈方法を知らせる符号化のバージョンを示すバージョン情報680を含む。いくつかの実施形態では、バージョン情報680は、メジャーバージョンフィールド682およびマイナーバージョンフィールド684を含む。メジャーバージョンフィールド682は、広告650フォーマットに実質的な更新が行われたときに増分される値(例えば1)を含むことができ、マイナーバージョンフィールド684は、広告650フォーマットに実質的な更新が少ないときに増分される値(例えば2)を含むことができる。メジャーバージョンフィールド682およびマイナーバージョンフィールド684に対する値は、バージョンの完全な指示(例えば、v.1.2)を形成するよう組合されてもよい。いくつかの実施形態では、これらの値は、利用可能なバイトを使用して表現することができる任意の値であってもよい。例えば、各バージョンフィールドがバイトである場合、各バージョンフィールドは、サイクル前に0〜255の値を含むことができる。
一般サービスデータチャンク668はまた、スマートネットワーク内においてデバイスを識別するために使用され得るデバイス識別子(ID)フィールド686を含む。一般サービスデータチャンク668は、デバイスクラス識別686も含む。デバイスクラス情報は、2つのサブフィールド、すなわちベンダーIDフィールド688および製品ID690を含むことができる。ベンダーIDフィールド688はデバイスに関するベンダーを示し、製品ID690はベンダー固有のデバイスのデバイスタイプを示す。一般サービスデータチャンク668は、前述したように、サービスペア設定ステータス692も含む。
前述したように、いくつかの実施形態では、広告650は、広告パケットとスキャン応答パケットとの2つ以上のパケットに分割することができる。広告650が2つのパケットに分割される実施形態では、長さフィールド652、ADタイプフィールド654、UUIDのリストB4は、人間が判読可能な名称データチャンク660とともに広告パケットを形成する。広告650の図示された実施形態のフィールド長を使用する実施形態では、この広告パケットは10バイトのサイズを有するであろう。このような実施形態では、スキャン応答パケットは、一般サービスデータチャンクからなり、21バイトのサイズを有するであろう。
2.警報を発令しているデバイスの例
図15は、広告700の一実施形態を示す。広告700は、広告650のすべてのフィールドを含むが、広告700は、広告デバイスが警報を発令している状態にあることを示すクリティカルイベントデータチャンク702を含む。さらに、広告700が一般サービスデータチャンク668およびクリティカルイベントデータチャンク702を含む場合、UUIDのリスト658は、広告700において、広告650より長くてもよい。クリティカルイベントデータチャンク702は、クリティカルイベントデータチャンク702についての長さを示す長さフィールド704を含む。クリティカルイベントデータチャンク702はまた、クリティカルイベントデータチャンク702をクリティカルイベントデータチャンクとして識別する値(例えば0x16)を伴うADタイプフィールド706を含む。クリティカルイベントデータチャンク702はまた、クリティカルサービスのためのUUIDを含むクリティカルサービスUUID708を含む。
また、いくつかの実施形態では、クリティカルイベントデータチャンク702は、広告に含まれるクリティカルイベントデータのためのクリティカルイベント(CE)データブロック長フィールド710も含む。言い換えれば、CEブロック長フィールド710は、チャンクメタデータフィールド(例えば、長さフィールド704およびADタイプフィールド706)以外のクリティカルイベントデータチャンク710の長さを示す。いくつかの実施形態では、CEデータブロック長フィールド710に長さが含まれないクリティカルイベントデータチャンク702のフィールドが広告間でサイズが一貫しているため、CEデータブロック長フィールド710を省略することができる。クリティカルイベントデータチャンク702はまた、クリティカルイベントのタイプ(例えば、ハザード検出器からの警報イベント、セキュリティイベントなど)を示すクリティカルイベントタイプ712を含む。
クリティカルイベントデータチャンク702はまた、クリティカルイベントデータチャンク702データをどのように解釈すべきかを示す警報イベント規格バージョン714を含む。クリティカルイベントデータチャンク702はまた、クリティカルイベントに関連する警報についての異議コードを含む警報異議716を含む。異議コードは、受信された解除がクリティカルイベントと実質的に同時に発生していることを検証することによって、その受信された解除が適時であることを検証するために使用される。異議コードは、4〜8オクテットのデータのような比較的小さいサイズを有する、警報時に生成されるランダム値であってもよい。次いで、受信側デバイスは、広告700からこのコードを引き出し、異議コードを関連する解除メッセージに含める。例えば、解除メッセージは、異議値上で解除鍵を使用して署名されることができる(すなわち、異議値を解除鍵を使用して署名する)。警報を発令しているデバイスが異議コードおよび解除鍵が適切であると判断した場合、次いで、警報を発令しているデバイスは、警報が警報であること、エラーが発生したこと、または警報が非解除可能であること、または他の適切なステータスを示す応答メッセージを送信する。
クリティカルイベントデータチャンク702はまた、クリティカルイベントデータチャンク702にいくつのクリティカルイベントが含まれているかを示すイベント数フィールド718を含む。クリティカルイベントデータチャンク702はまた、クリティカルイベントタイプ712に示される警報のタイプに特有の警報のサブタイプを示す警報タイプおよび警報状態フィールド720を含む。イベント数フィールド718が、1つより多いイベントがクリティカルイベントデータチャンク702に含まれていることを示す場合、クリティカルイベントデータチャンク702は、含まれる追加のクリティカルイベントごとに、追加の警報タイプおよび状態フィールド722を含む。
警報タイプおよび警報状態フィールド720ならびに追加の警報タイプおよび状態722(含まれる場合)は、上記の表5および表6にて提供されるものと同様の値を含むことができる。
広告700が分割される実施形態では、長さフィールド652、ADタイプフィールド654、UUIDのリストB4、人間が判読可能な名称データチャンク660、およびクリティカルイベントデータチャンク702。広告700の図示された実施形態のフィールド長を使用する実施形態では、広告パケットは26バイトのサイズを有し、スキャン応答パケットは一般サービスデータチャンクからなり、21バイトのサイズを有するであろう。
V.BLEを使用した解除
図16は、一実施形態による例示的なハザード検出システム1610および例示的なユーザデバイス1620のブロック図を示す。システム1610および1620の多くの異なるコンポーネントのほんのいくつかが、音響位置検証に関連する実施形態に議論の焦点を当てるよう議論される。システム1610は、コンポーネントの中で、とりわけ、ワイヤレス通信回路1612、マイクロホン1614、および超音波エミッタ1616を含むことができる。ユーザデバイス1620は、コンポーネントの中でもとりわけ、ワイヤレス通信回路1622、マイクロホン1624、および超音波エミッタ1626を含むことができる。ワイヤレス通信回路1612および1622は、システム1610とデバイス1620との間のワイヤレス通信を可能にするための任意の適切な回路であってもよい。例えば、回路1612および1622は、ブルートゥース低エネルギ(BLE)通信、802.11通信、および/または802.15.4通信を行うことができる。マイクロホン1614および1624は、任意の適切なマイクロホンであってもよい。超音波エミッタ1616および1626は、高周波音響エネルギを放射することができる任意のデバイスとすることができる。例えば、エミッタ1616および1626はスピーカであってもよい。なお、図16は、システム1610およびデバイス1620の両方が各々マイクロホンおよび超音波エミッタ有するのを示しているが、いくつかの実施形態は異なる構成を有してもよい。例えば、一実施形態では、システム1610はマイクロホンを有さなくてもよい。別の例として、ユーザデバイス1620は、超音波エミッタを有さなくてもよい。
前述したように、スマートネットワークにおけるスマートデバイスは、スマートデバイス周辺の実世界の状況を追跡する様々なセンサを含む。例えば、スマートデバイスは、様々な状況の建物の居住者に警戒態勢をとらせるハザード検出、セキュリティデバイス、および/または他の監視デバイスを含むことができる。これらのデバイスは、クリティカルイベントの検出で警報を発令してもよい。例えば、図17に示すように、スマートデバイス800は、警報指示802を電子デバイス804に送信する。いくつかの実施形態では、電子デバイス804は、携帯電話、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、または警報表示802を受信し、解除要求806を送信することができる任意の他の電子デバイスを含むことができる。警報表示802は、BLE広告のような比較的低い無線信号であってもよい。スマートデバイスはまた、検出されたイベントを示すために音波または視覚インジケータを提供することができる。しかしながら、いくつかの実施形態では、イベントが、イベントを意識している居住者によって観察されるとき、イベントが誤った警報であるとき、および/または警報がイベントを注意喚起することにおいてもはや役立たない場合のとき、警報は電子デバイス804からの解除要求を使用して解除されてもよい。
いくつかの実施形態では、警報の原因または源を調査する試みが行われたことを確実にするために、解除を、スマートデバイス800に対して予め定められた近接度内のデバイスに限定してもよい。さらに、後述するように、解除応答には、承認された個人だけが警報を解除する能力を有することを保証するいくつかのセキュリティ機能が含まれる。いくつかの実施形態では、無線による解除は、スマートデバイス800によって監視されるセキュリティまたは安全性を損なうことなく、スマートデバイス800に実際に物理的に接触することなく、スマートデバイス800で警報を解除することを可能にする。いくつかの実施形態では、近接性検証は、電子デバイス804を使用してクリティカルイベントを引き起こす条件を検証してもよいネットワーク接続されたカメラを介して準備されてもよい。
いくつかの実施形態では、警報指示808は、リモートサービス810に送信され、次いで電子デバイス804に中継されてもよい。これに加えて、またはこれに代えて、リモートサービス810は、ワイヤレスネットワークのためのアクセスポイントまたはルータで置き換えることができる。
さらに、スマートデバイス800は、ネットワーク814において他のデバイス812(例えば、ハザード検出器、温度計など)に警報および解除を伝搬することができる。ネットワーク814は、スマートデバイス800と電子デバイス804(例えば、BLE)との間の解除対話によって使用されるものとは異なるワイヤレス通信タイプ(例えば、802.15.4)を含むことができる。
特定の実施形態では、後述するように、警報指示802が受信される前に、リモートサービス810を介して警報指示808が受信されたとき、電子デバイス804は、リモートサービス810を介して解除が可能化されないという通知と共に警報の通知を表示してもよい。他の実施形態では、スマートデバイス800への近接性が別の経路を介して検証され得るときにリモートサービス810(またはアクセスポイントもしくはルータ)を介して解除を可能にすることができる。例えば、電子デバイス804が、スマートデバイス800からの電磁信号、音波信号または視覚信号を検出した場合。いくつかの実施形態では、ある警報種は、近接性検証なしでは非解除可能であり得るが、他の警報種は近接性検証に関係なく解除可能である。例えば、特定の実施形態では、煙報知器は遠隔接続からは非解除可能であり得るが、セキュリティ警報器は遠隔解除され得、なぜならば、遠隔ユーザは、セキュリティシステムのパスワードを持たない訪問者や、自動化された電子デバイス(例えば、清掃ロボット)による予定された動作のような、セキュリティ警報を引き起こすであろう条件を知っているからである。いくつかの実施形態では、警報の解除性は、警報の深刻度に基づいて変化し得る。例えば、警報がより低い優先度の「注意喚起」警告である場合、警報は解除されてもよいが、警報が実際のクリティカルイベントを示す場合、警報は解除されなくてもよい。
いくつかの実施形態では、非解除可能警報で解除が試みられる場合、その警報は解除されずに、警報を発令しているリモートデバイスが解除されてもよい。言い換えれば、煙警報が屋根裏部屋から生じる場合、地下室のスマートデバイスが、屋根裏部屋における警報の通知(例えば、聴覚および/または視覚的指示)を送信してもよい。屋根裏部屋における非解除可能警報に対して解除が試みられる場合、地下室のスマートデバイスが解除されて、警報の通知の送信を止めてもよい。
いくつかの実施形態では、スマートデバイスへの接続は、リモートサービス810にログインするために使用される電子デバイス804上のプログラムアプリケーションを使用することによって認証することができる。いくつかの実施形態では、電子デバイス804が警報指示802を受信したとき、電子デバイス804がスマートデバイスの管理に使用されるアカウントについて認証されたユーザとしてリモートサービス810にログインされていなければ、電子デバイス804はユーザインターフェイス(UI)から消音オプションを保留してもよい。それに加えて、またはそれに代えて、スマートデバイス800は、スマートデバイス800を管理するために使用されるアカウントについて電子デバイス804が認証されるまで、電子デバイス804への接続を遮断することができる。
図18は、電子デバイス804において発生し得る解除プロセス820のフローチャート図を示す。電子デバイス804は、スマートデバイス800に対応するアカウント名およびパスワードを使用してリモートサービス810にログインする(ブロック822)。アカウントにログインすることにより、電子デバイス804は、スマートデバイス800に対して認証することができる。例えば、いくつかの実施形態では、リモートサービス810は、電子デバイス804にシグネチャまたは鍵を提供して、アカウントが関係する任意の警報を発令しているデバイスに対して認証を行なうために使用され得るシグネチャを生成することができる。いくつかの実施形態では、シグネチャはアカウントパスワードから生成することができる。
電子デバイス804は、スマートデバイスにおけるクリティカルな状態の指示を無線信号802で受信する(ブロック824)。例えば、電子デバイス804がクリティカルサービスを含むBLE広告を受信した場合、電子デバイス804は、その広告がスマートデバイス800のクリティカルな状態の指示であると判断することができる。それに加えて、またはそれに代えて、電子デバイス804は、802.11または802.15.4ネットワークなどの1つまたは複数のネットワークを介してリモートサービス810を介して指示を受信することができる。さらに、いくつかの実施形態では、電子デバイス804は、電子デバイス804に無線信号802をスキャンさせるアプリケーションプログラムがアクティブであるとき、またはバックグラウンドで実行されているときにのみ、指示を受信する。したがって、そのような実施形態では、電子デバイス804がスマートデバイス800を解除するよう準備されていないとき、電子デバイス804は電力消費を節約することができる。
指示を受信したことに応答して、電子デバイス804は、クリティカルイベントが発生したという指示を表示する(ブロック826)。表示される画面は、指示に関するさまざまな情報に基づいて異なってもよい。例えば、電子デバイス804は、警報が解除可能であるかどうかを判定してもよい(ブロック828)。たとえば、深刻度のしきい値を超えた警報、および/または解除のしきい値数を超えて解除された警報。いくつかの実施形態では、解除性および/または非解除性を引き起こす要素が、BLE広告に含まれてもよい。例えば、BLE広告における広告された警報状態は、非解除可能な警報の指示を含むことができる。警報が解除可能でない場合、電子デバイス804は、表示された指示が電子デバイス804によって表示され続け得るが、解除プロセスを終結し得る(ブロック830)。さらに、表示された指示は、解除プロセスの終結に基づいて変化してもよい。たとえば、警報が解除可能でない場合、解除オプションが表示された指示から完全に欠落していてもよい。
電子デバイス804が、警報が非解除可能であると判定しない場合、電子デバイス804は、電子デバイス804がスマートデバイス800に近接しているかどうかを判定する(ブロック832)。例えば、いくつかの実施形態では、電子デバイス804がBLEを介して指示を受信した場合、電子デバイス804は、スマートデバイス800が近接閾値内における距離内にあると判定することができる。それに加えて、またはそれに代えて、スマートデバイス800は、電子デバイス804とスマートデバイスとの間の近接性を検証するよう、電子デバイス804(またはスマートデバイス800)によって使用され得る音波信号および/または光信号を送信することができる。例えば、そのような実施形態では、スマートデバイス800は、電子デバイス804がスマートデバイス800との通信において再生する超音波信号をブロードキャストしてもよい。近接性が確認された場合、電子デバイス804は解除オプションを提示する(ブロック836)。電子デバイスがブロードキャストされた音波信号を検出しない場合、またはスマートデバイス800が、近接性に基づいて解除要求が拒否されたと応答する場合、電子デバイスは、電子デバイス804が解除のためにスマートデバイス800に十分に近くないと判断してもよい。いくつかの実施形態では、近接性が確認されない場合、電子デバイス804は異なる画面を提示してもよい。例えば、解除オプションは、電子デバイス804を、スマートデバイス800を解除する前にスマートデバイス800に近づけるべきである、という通知としてグレーアウトされてもよい。
例えば、いくつかの実施形態では、電子デバイス804は、図19に示すように、警告画面900を表示することができる。警告画面900は、画面900に注意を引くことを意図したアイコン902を含む。いくつかの実施形態では、アイコン902は、警報の深刻度を示すためにある色に変更された点滅リングを含む。さらに、電子デバイス804は、警告画面900に注意を引くために、振動または音を発することができる。警告画面900はまた、スマートデバイス800によって検出されたクリティカルイベントのタイプを示す警報タイプ904を含む。警告画面900はまた、クリティカルイベント、または警報に応答してどのような行動をとるべきか、に関する追加情報906を含むことができる。警告画面900はまた、警報深刻度908を示す。例えば、警告画面900は、1つまたは複数の注意喚起状態と1つまたは複数の警報レベル状態との間で区別することができる。警告画面900はまた、クリティカルイベントを検出するスマートデバイス800についての位置910を示す。警告画面900はまた、警報に応答して予想される様々なアクションへのショートカットを提供するアクションバー912を含む。アクションバー912は、選択されると、クリティカルイベントおよび対応として取るべきアクションに関するより多くの情報を提供するティップスボタン914を含む。アクションバー912はまた、選択時に、電子デバイス804に、予め指定された連絡先に発信またはメッセージを送信させるコールボタン916を含む。アクションバー912はまた、警報消音ボタン920を含む。しかしながら、前述したように、警報が非解除可能な場合、警報消音ボタン920は画面から省略されてもよく、スマートデバイス800と電子デバイス804との間の近接性が確認できない場合、警報消音ボタン920は、グレーアウトされるかまたは解除を行うためにデバイス同士を互いに近く移動させる必要があることを示してもよい。いくつかの実施形態では、グレーアウトされた警報消音ボタン920が選択された場合、電子デバイス804は、電子デバイス804をスマートデバイス800に近づけるための明示的な指示を提示することができる。いくつかの実施形態では、警告画面900の色は、警報の受信を示すように変更することができる。例えば、全クリアページは第1の色(例えば白)であり、警告画面900は異なる色(例えば、黒または濃い灰色)を有してもよい。
いくつかの実施形態では、警告画面900を使用して複数の警報を提示することができる。このような実施形態では、位置910は、スマートネットワークにおいて各警報を発令しているデバイスついての位置(例えば、居間、キッチン、ガレージなど)を含むことができる。アイコン902は、各デバイス間の最高優先度警報に対応してもよい。したがって、様々な警報タイプが深刻度のレベルにおいて優先順位付けられ、最も高い深刻度の警報が位置910のリストの一番上に提示される。例えば、警報は、深刻度の高い順に優先順位を付けてもよい。すなわち、煙警報、一酸化炭素警報、注意喚起煙レベル通知、注意喚起一酸化炭素通知、およびその他の注意喚起通知である。
図18に戻って、警報を解除するとき、電子デバイス804は解除オプションの選択を受信する(ブロック838)。解除の選択を受信すると、電子デバイスは、図20に示すように、解除確認画面922を提示することができる。解除確認画面922は、消音ボタン920が押された後に警報を解除する意図を確認する方法をユーザに指示する解除命令924を含む。例えば、解除命令924は、解除ボタン926を長押して、警報を解除することによって、解除を実行し得ることを指示する。いくつかの実施形態では、解除命令924は、警報を解除する意図を確認するための文字入力、バイオメトリック入力、ジェスチャ、ボタンクリック、および/または他の適切な入力による解除の確認など、確認方法に応じて異なる命令を与えることができる。例えば、確認がジェスチャを含む場合、ジェスチャは、任意の方向の単純なスワイプ、複数の動きを含む複合ジェスチャ、指の数と関連するジェスチャとの組み合わせ、またはそれらの何らかの組み合わせとすることができる。確認画面922はまた、警報タイプに関連する安全命令のような、警報を消音することに加えてとられるかもしれないアクションに関する追加命令928を含むことができる。例えば、煙警報が発生している場合は、追加命令は、火災時には低い姿勢を維持し、扉を開ける前には熱に気をつけるよう命令を含み得る。確認画面922はまた、解除が過失であったかまたはもはや望まれてはいないことを示す機構を提供するキャンセルボタン930を含む。
図21は、ボタン長押し中における解除ボタン926の変化を示す確認画面922の実施形態を示す。図示されているように、解除ボタン926は、解除ボタン926が長押しされると色が変化するリング932を含む。言い換えれば、リング932は、解除ボタン926がどれくらい長く長押しされているか、および解除が確認される前にどれくらいより長く長押しされることになるかに関するフィードバックを提供する。いくつかの実施形態では、リング932は、解除ボタン926が長押しされると色が変わる番号(例えば、2,3,4,5またはそれ以上)の弧に分割されてもよい。例えば、4つの弧があり、長押し持続時間が2秒の場合、各弧は0.5秒のボタン長押しに対応する。さらに、図示されているように、いくつかの実施形態では、弧は暗色から淡色に徐々に変化してもよい。したがって、図示の実施形態では、リング932は、2つのより明るい色または輝度の弧934、中間色または輝度の弧936、およびより暗い色または輝度の弧938を含む。本実施形態によれば、解除ボタン926は、解除確認期間の50%〜75%の間において、長押しされている。ボタンが押されたことが確認されると、電子デバイス804は、図22に示す消音スクリーン940のような消音スクリーンを提示することができる。消音スクリーン940は、解除の試みが進行中であるという視覚的な解除インジケータ942を含む。例えば、視覚的な解除インジケータ942は、解除の試みが進行中であることを示す回転リングを含む。いくつかの実施形態では、消音スクリーン940は、解除の試みが進行中であることを示すテキストインジケータ944を含む。いくつかの実施形態では、テキストインジケータ944および/または視覚的解除インジケータ942は、電子デバイス804が解除の試みをタイムアウトするまでの時間量を反映するカウントダウンを含むことができる。
図18に戻って、解除が確認されると、電子デバイス804は、スマートデバイス800から受信した無線信号に基づいてスマートデバイス800への接続を確立する(ブロック840)。スマートデバイス800がBLE広告を使用して電子デバイス804にクリティカルイベントを示す実施形態では、電子デバイス804は、BLE広告を使用してスマートデバイス800とBLEペアリングを確立する。
ワイヤレス接続を介して、電子デバイス804は、警報を発令しているスマートデバイス800に解除要求を送信する(ブロック842)。いくつかの実施形態では、解除要求を送信することは、近接性検証および認証検証も含む。具体的には、前述したように、スマートデバイス800は、受信したクリティカルな状態の指示の一部として異議コードを受信する。サービス810から検索された事前共有鍵を使用して、電子デバイス804は、解除シグネチャを生成し、事前共有鍵を使用して異議コードに署名する。電子デバイス804およびスマートデバイス800の両方が解除シグネチャを生成するので、スマートデバイス800は解除シグネチャを検証し、それを用いて電子デバイス804を認証し、電子デバイス804の近接性を検証してから、解除要求を承認することができる。
次いで、電子デバイス804は、スマートデバイス800から解除の試みのステータスを示す応答を受信する(ブロック844)。次に、電子デバイス804は、警報が解除されたかどうかを判定する(ブロック846)。警報が解除された場合、電子デバイス804は解除結果を表示してもよい(ブロック848)。
図23は、解除要求の成功または失敗を示すために使用され得る例示的な結果画面950を示す。図示の実施形態では、結果画面950は、解除ステータスインジケータ952およびテキストによる解除ステータスインジケータ954によって示されるように、成功した解除を示す。解除が成功しなかった実施形態では、結果画面950は、「x」が省略された解除ステータスインジケータ952を使用して、解除が発生しなかったことを示してもよい。同様に、テキストによる解除ステータスインジケータ954は、「警報は消音されていない。」と記してもよい。いくつかの実施形態では、結果画面950は、クリティカルイベントが終了していない場合に解除が終了して警報が再開するまでの期間を列挙するなど、次に起こり得ることを記す追加のテキストを含むことができる。
図18に戻って、解除が成功裡に完了していない場合、電子デバイス804はブロック828に戻り、解除を再試行する。いくつかの実施形態では、解除の試みが失敗した場合、または警報が解除可能閾値を超えた場合、警報は非解除可能としてマークされてもよい。たとえば、煙が多いと、警報が非解除可能になってもよい。したがって、いくつかの実施形態では、スマートデバイスによって様々な煙レベル閾値を使用することができる:煙レベルをより綿密に追跡するためにサンプリング期間を増加させる比較的低い監視/保持レベル、相対的な優先順位レベル警報を引き起こす1つまたは複数のより高い注意喚起煙レベル、より高い優先順位警報を引き起こす、より高い煙レベル、および警報を非解除可能にする、さらにより高い煙レベルである。上記の例は煙レベルに関するものであるが、スマートデバイス800は、スマートデバイス800が行う任意の測定の様々なレベルに対する上昇する反応のレベルを有してもよい。
解除が成功裡に完了した場合、電子デバイス804は、スマートデバイス800への接続がスマートデバイスによってまだ閉じられていない場合には、スマートデバイス800への接続を閉じる(ブロック850)。BLE接続を閉じることによって、スマートデバイス800は、例えば、解除済または警報を発令していないなど、更新された警報ステータスで広告を再開することができる。次いで、電子デバイス804は、更新された警報状態を受信する(ブロック852)。いくつかの実施形態では、更新された広告に基づいて、電子デバイスは、図24に示されるように、警告画面900を更新することができる。例えば、警報が解除されたという指示を受信した後、警告画面900は、警報消音ボタン920をグレーアウトしてもよく、位置910には、解除の成功または失敗を示す警報のステータス956を付加してもよい。
図25Aおよび図25Bは、スマートデバイス800によって実行され得るプロセス960を示す。スマートデバイス800の動作中、スマートデバイス800は、定期的な間隔でワイヤレス接続のための広告をブロードキャストする(ブロック962)。例えば、スマートデバイス800は、BLE、WiFi、および/または何らかの他のネットワークプロトコルのための広告をブロードキャストすることができる。さらに、スマートデバイス800は、警報状態に基づいて定期的にこのメッセージを断続的にブロードキャストすることができる。例えば、警報状態がアイドル状態である(すなわち、アクティブに警報を発令していない)場合、スマートデバイスは、広告をデフォルトレート(例えば、0.5秒に1回)でブロードキャストすることができる。警報状態がある警報状態にある場合、スマートデバイス800は、警報レート(例えば、40msごとに1回)でブロードキャストしてもよく;警報状態が解除された場合、スマートデバイス800は、デフォルトレートよりも高いが警報レートよりも低い解除済レート(例えば、1/4秒に1回)で関連する広告をブロードキャストしてもよい。いくつかの実施形態では、解除済レートはデフォルトレートと同じであってもよい。言い換えれば、解除された状態に対応する広告は、警報を発令していない状態に対応する広告と同じくらいの頻度で送信されるであろう。
スマートデバイス800の機能の一部として、スマートデバイス800は、クリティカルイベントが発生したかどうかを判定する(ブロック964)。クリティカルイベントが発生していない場合、スマートデバイス800は、接続のために広告をブロードキャストし続けながら、そのようなイベントをスキャンし続ける。以下により詳細に説明するように、クリティカルイベントが検出された場合、スマートデバイス800は、その警報状態を、警報発令状態に更新する(ブロック966)。警報発令状態への更新の一部として、スマートデバイス800は、先に論じられたクリティカルイベントデータチャンク702のクリティカルイベントサービスUUID708および他の部分を、それらに関連付けられる、警報タイプおよび深刻度のようなフィールドに対する適切な値とともに含むように、スマートデバイス800の広告を更新する。警報状態を更新することは、クリティカルイベントをスマートデバイス800の周囲の領域に示すために可聴信号または視覚的信号をブロードキャストすることを含むこともできる。例えば、スマートデバイス800は、周期的にブザーを鳴動させ、および/またはクリティカルイベントの性質を示す音声メッセージを再生することができる。
また、スマートデバイス800が、このクリティカルイベントの発生に対して警報異議をまだ生成していない場合、スマートデバイス800は、任意の解除要求の適時性を保証するために使用される異議コード716を生成する(ブロック968)。前述したように、警報異議716は、クリティカルイベントの検出時またはその近くで生成され、クリティカルイベントに応答して受信された解除要求が、クリティカルイベントの検出に近く間に合って送信されたことを認証するために使用される、ランダムに生成される値を含むことができる。
更新された警報状態および新たに含まれるクリティカル状態データチャンク702を含む更新された広告を使用して、スマートデバイス800は更新された広告を警報レートでブロードキャストする(ブロック970)。スマートデバイス800はまた、スマートデバイス800に対して解除が可能化されるかどうかを判定する(ブロック972)。いくつかの実施形態では、解除は、一般的に、スマートデバイス800について、スマートデバイス上のユーザインターフェイスを介して、一般的なルールとしてデバイスのデバイスタイプに基づいて、デバイスの位置に基づいて、またはそれらの何らかの組み合わせに基づいたユーザインタフェースを介して、不能化または可能化されてもよい。特定の実施形態では、スマートデバイス800は、スマートデバイス800に対して解除が不能化されることを示してもよい(したがって、電子デバイス804に、クリティカルイベントの検出通知を表示するユーザインタフェース(たとえば警告画面900)において、解除を不能化および/または隠蔽させてもよい)。スマートデバイス800に対して解除が可能化されない場合、この警報については解除プロセス960を終了させるが、ブロック964において、新しいクリティカルイベントの検出で、またはスマートデバイス800が解除可能になると、解除プロセス960は再開してもよい。
次に、スマートデバイス800は、解除要求が受信されるのを待つ(ブロック974)。解除要求が受信されると、スマートデバイス800は、警報が解除可能であるかどうかを判定する(ブロック976)。いくつかの実施形態では、特定の警報に対する解除は、警報のタイプ、警報の深刻度、以前の警報解除、またはそれらの何らかの組合せに基づいて、不能化または可能化され得る。特定の実施形態では、スマートデバイス800は、スマートデバイス800に対して解除が不能化されることを示してもよい(したがって、電子デバイス804に、クリティカルイベントの検出通知を表示するユーザインタフェース(たとえば警告画面900)において、解除を不能化および/または隠蔽させてもよい)。いくつかの実施形態では、警報に対して解除が可能化されない場合、スマートデバイス800は、警報が解除可能ではないため、電子デバイス804に警報解除エラーを報告する応答を送信する(ブロック978)。いくつかの実施形態では、警報に対して解除が可能化されない場合、この警報については解除プロセス960を終了させるが、ブロック964において、新しいクリティカルイベントの検出で、または警報が解除可能になると、解除プロセス960は再開してもよい。たとえば、警報の深刻度が低下すると、警報は解除可能になってもよい。
スマートデバイス800が解除を可能化され、警報が解除可能である場合、スマートデバイス800は、さらに、スマートデバイス800がスマートデバイス800の閾値距離内にあるかどうかを判定する(ブロック980)。例えば、スマートデバイス800は、解除要求がBLEまたは既知の範囲を伴う別のワイヤレス接続プロトコルを介して受信されたとき、スマートデバイス800が閾値距離内にあると判断することができる。追加的または代替的に、スマートデバイスは、電子デバイス804が解除要求内に含み、電子デバイス804がスマートデバイス800の閾値距離(例えば音波域または視覚域)内に有ることを判断するためにスマートデバイス800が用いることができる、音波(例えば超音波)または視覚的(例えば赤外線)信号をブロードキャストしてもよい。加えて、または代替え的に、ある実施形態では、ワイヤレス通信、地理空間追跡(例えば、全地球測位システム位置)、様々な電磁場(例えば、RFID、NFC)の検出、またはクリティカルイベントが監視されたかもしれない場所から警報が不能化されることを保証するために使用され得る他の方法のための信号レベルの強度を使用して近接性を判定することができる。
電子デバイス804がスマートデバイス800の範囲内にあると判定された場合、スマートデバイス800はまた、解除が承認されているかどうかを判定する(ブロック984)。いくつかの実施形態では、近接性検証および承認検証を組み合わせて単一のステップにすることができる。例えば、前述したように、解除要求は、異議コード716とリモートサービスを介して共有されたスマートデバイス800および電子デバイス804の事前共有鍵とを使用して生成された解除シグネチャを含む。スマートデバイス800および電子デバイス804は各々、異議コード716および事前共有鍵へのアクセスを有し、各々、シグネチャを生成する。いくつかの実施形態では、スマートデバイス804は、事前共有鍵を使用してシグネチャが適切な暗号化を含むが、シグネチャが正しい異議コードに署名されていない、と判断してもよい。例えば、事前共有鍵がヌル異議コードまたは古い異議コードを使用するシグネチャを生成するために使用される場合、スマートデバイス800は、古い異議コードを使用して生成された1つまたは複数の古いシグネチャのコピーと、比較のために使用するヌルコードで生成されたシグネチャのコピーとを維持してもよい。これらのシグネチャのうちの1つが、電子デバイス804から受信した解除シグネチャと一致する場合、スマートデバイス800は、近接性非承認エラーで応答してもよい。シグネチャが期待されるどのシグネチャとも一致しない場合、スマートデバイス800は、電子デバイス804にシグネチャエラーで応答する(ブロック986)。いくつかの実施形態では、スマートデバイス800は、解除性エラー、近接性エラー、またはシグネチャエラーを送信した後に、別の解除応答を待ってもよい。
警報が解除可能であり、シグネチャが検証確認された場合、スマートデバイス802は、警報を解除する(ブロック988)。いくつかの実施形態では、スマートデバイス800は、スマートネットワークにおいて他のスマートデバイスに接続され、クリティカルイベントが検出されたときにそれらに警報を発させる。このような実施形態では、スマートデバイス800が警報を局所的に解除すると、スマートデバイス800は、スマートネットワークにおいて警報を発令している他のデバイス800に解除を伝搬する(ブロック990)。特定の実施形態では、解除伝搬の開始は、クリティカルイベントを検出することによって警報を発令した発令元デバイスに限定される。したがって、このような実施形態では、電子デバイス804の発令元デバイスに対する近接性検証を確実にすることにより、クリティカルイベントを引き起こす状況の全体が視覚的に調査され得るときに解除が要求されることが保証される。さらに、前述したように、スマートデバイス800は、通信が行なわれ得る少なくとも2つのワイヤレスインターフェイスプロトコルを含む。いくつかの実施形態では、以下に説明するように、解除要求は第1のワイヤレス接続タイプ(例えばBLE)を介して受信され得、解除は第2のワイヤレス接続タイプ(例えば802.15.4)を介して伝搬され得る。
解除を伝搬することに加えて、スマートデバイス800は、解除が成功裡に完了したことを示す解除応答を送信する(ブロック992)。いくつかの実施形態では、解除応答が送信されると、スマートデバイス800は、解除要求が受信された接続を閉じる(ブロック994)。言い換えれば、電子デバイス804とスマートデバイス800との間のワイヤレス接続が、接続広告(例えばBLE)を中止するペア接続である実施形態では、スマートデバイス800が前述のように接続広告を使用して複数のデバイスにその警報状態を通信できるように、ワイヤレス接続が閉じられる。特定の実施形態では、解除応答が、スマートデバイス800によって送信される、および/または電子デバイス804によって受信されると、スマートデバイス800および/または電子デバイス804によって接続が閉じられる。
解除プロセスの一部として、承認された解除を受信した後、スマートデバイス800は、そのワイヤレス接続広告を警報解除広告に更新する(ブロック998)。例えば、クリティカルサービスデータチャンク702は、警報が広告に示されたことを示すように更新される。スマートデバイス800はまた、広告周期を、警報レートから、いくつかの実施形態ではデフォルトレートと同じである解除済みレートに変更する(ブロック1002)。スマートデバイス1002は、解除タイマが経過するまで待機し続ける(ブロック1000)。言い換えると、解除は、制限された有効期間(例えば1分)を有し、その後、解除は停止する。解除タイマが経過した後、スマートデバイス800は、クリティカルイベントがまだ検出されるかどうかを判定する(ブロック1004)。クリティカルイベントがもはや有効でない場合、この警報については解除プロセス960は終了しても、別のクリティカルイベントが検出されたときにプロセスが再び開始してもよい。現在の警報については解除プロセス960は終了しているが、スマートデバイス800が現在警報を発令している、他のアクティブな警報がある場合がある。クリティカルイベントがまだ有効である場合、スマートデバイス800は警報を解除しない(ブロック1006)。いくつかの実施形態では、警報を解除しないことは、警報が現在非解除可能であることを示すことを含むこともできる。言い換えれば、そのような実施形態では、各警報は一度だけ解除されてもよい。特定の実施形態では、スマートデバイス800は、各警報について解除カウンタを保持し、解除カウンタが解除制限閾値を超えたときに警報を非解除可能として設定することができる。
図26は、スマートデバイス800について現在の状態を判定するために使用され得る状態マシン1010を示す。前述したように、デフォルト状態の間、スマートデバイス800は、スマートデバイス800に関する一般情報をデフォルトレートで与えるワイヤレス通信タイプ(例えばBLE)広告をブロードキャストすることができる。いくつかの実施形態では、スマートデバイス800は、ワイヤレス通信タイプを介してワイヤレス接続を遮断する。スマートデバイス800は、デフォルト状態1012で開始する。イベントが検出されると、スマートデバイスは警報発令状態1014に移行する。前述したように、スマートデバイス800が警報発令状態1014にあるとき、スマートデバイス800は、デフォルト状態1012にある広告頻度よりも高いレートでワイヤレス通信タイプを介して警報情報(例えば、クリティカルイベントUUIDなど)を含む広告をブロードキャストする。さらに、警報発令状態1014において、スマートデバイス800は、ワイヤレス通信タイプを介した接続が解除要求を受信することを可能にすることができる。いくつかの実施形態では、スマートデバイス800は、伝搬通信タイプ(例えば、802.15.4)を使用してスマートネットワークにおいて他のデバイスに警報の通知をブロードキャストすることもできる。警報発令状態1014から、イベントが終了すると、スマートデバイス800はデフォルト状態1012に戻る。
いくつかの実施形態では、スマートデバイス800は、イベントが進行中であるかどうかをスマートデバイス800が判定する保持状態または監視状態などの中間状態を経て遷移する。保持状態は、警報を発令するイベントが発生したかどうかをスマートデバイス800が判定することを可能にするために、測定値が警報閾値(例えば、警報閾値または注意喚起閾値)に近づくと、より速いレートでデータをサンプリングするために使用される前期警報状態を含むことができる。監視状態は、測定値が上昇するが警報閾値を下回るときに、より速いレートでデータをサンプリングするために使用される後期警報状態を含むことができる。イベントがまだ進行中である、とスマートデバイスが判断した場合、スマートデバイス800は、保持状態もしくは監視状態から復帰し、および/または警報発令状態1014にとどまる。警報発令状態1014にある間、スマートデバイス800は、有効な解除要求を受信してもよい。警報が非解除可能である場合、スマートデバイス800は警報発令状態1014のままであるが、スマートデバイス800は依然として伝搬通信タイプを介してスマートネットワークにおいて他のデバイスに解除を伝搬してもよい。例えば、いくつかの実施形態では、スマートデバイス800は、スマートデバイス800で警報が解除されない場合であっても、BLEを介して解除要求を受信し、スマートネットワークにおいて他のデバイスに、802.15.4ネットワーク接続を介して、および/または802.11ネットワーク接続を介して、解除を伝搬することができる。警報が解除可能であり、有効な解除が受信される場合、スマートデバイス800は、警報を解除し、解除状態1016に遷移してもよい。
解除状態1016において、スマートデバイス800は、警報が現在であるが解除されているという指示と共に、ワイヤレス通信タイプのための接続をブロードキャストする。いくつかの実施形態では、解除状態の広告ブロードキャスト頻度は、警報発令状態1014の広告ブロードキャスト頻度よりも低い頻度である。特定の実施形態では、解除状態1016の広告ブロードキャスト頻度は、デフォルト状態1012と同じ頻度またはそれより高い頻度である。前述したように、いくつかの実施形態では、スマートデバイス800は、解除状態1016内に、限られた期間の間、留まるだけである。いくつかの実施形態では、解除期間が終了し、クリティカルイベントが依然として存在する場合には、スマートデバイス800は警報発令状態1014に戻る。そうでなければ、スマートデバイス800はデフォルト状態に戻る。いくつかの実施形態では、スマートデバイスは、保持状態を通過してから、デフォルト状態1012に戻る。追加的または代替的に、特定の実施形態では、スマートデバイス800は、デフォルト状態1012に戻ってから、クリティカルイベントが存在するかどうかを判定する。このような実施形態では、クリティカルイベントが残っている場合、スマートデバイス800は、デフォルト状態1012から警報発令状態1014に遷移する。
上述したように、ユーザは、自分のユーザデバイスと対話することによって、煙警報器または他のデバイスを遠隔解除することができる。例えば、警報が鳴動した場合、ハザードデバイスは、ワイヤレス通信回路を介してユーザデバイスに警告してもよく、ユーザは、警報を解除するためにユーザ選択可能なオプションを有するユーザインターフェイス画面を提供されてもよい。ユーザが警報を解除するためにそのオプションを選択すると、ユーザデバイスは、その命令をワイヤレス通信回路を介してハザードデバイスに返信してもよい。しかしながら、さまざまな規制に従うため、解除コマンドは、ユーザデバイスがハザードデバイスから一定の距離内にある場合にのみ実行できる。これは、ユーザが仕事で留守の間、ユーザの家で警報を解除できないようにするためである。さらに、ワイヤレス通信回路を介して通信される信号は、実質的な範囲(例えば、ハザード検出器を有する構内の境界を越えて延びる範囲)を有することができるので、超音波信号が、ユーザの位置を検証するべく、本明細書で説明する実施形態に従って使用される。
本明細書で論じられる実施形態によって使用される超音波信号は、人間の聴覚の範囲を超えて存在してもよい。これらの周波数範囲で動作させることにより、ハザードデバイスとユーザデバイスとが、それらデバイスを含む構内の居住者を煩わせることなく、通信することが可能になる。例えば、超音波信号は、18.5kHz以上の周波数で送信されてもよい。いくつかの実施形態では、超音波周波数は、20kHzまたは22kHzであり得る。超音波周波数は、18kHzと22kHzの間の範囲内に存在してもよい。超音波周波数の上限は、ハザードデバイスおよび/またはユーザデバイスに存在する超音波エミッタ(またはスピーカ)によって制限されてもよい。
超音波信号は、距離をわたって比較的速く減衰し、壁、床などを容易に通過しない。これには、図27に示すように、警報を遠隔で解除するために、ユーザをハザードデバイスの見通し線内にいるよう強いるという有利な点がある。図27は、キッチン内に配置されたハザードデバイス2710と、図示されている様々な場所に配置されたユーザデバイス2720〜2723とを有する家屋の平面図を示す。一様な破線は、デバイス2710とユーザデバイス2720〜2723のうちの任意の1つとの間で通信される無線信号を表すことができる。一点鎖線は、デバイス2720〜2723によって放射される超音波信号を表すことができる。図示のように、各ユーザデバイスは、無線信号を介してハザードデバイス2710と通信することができる。しかしながら、すべてのユーザデバイスがハザードデバイス2710に超音波信号を送信することができるわけではない。家屋の外に位置するユーザデバイス2720は、それが放射した超音波信号で家屋の外壁を貫通することはできない。家族部屋に位置するユーザデバイス2721も、それが放射した超音波信号で内壁を貫通することはできない。キッチンに隣接し、ハザードデバイス2710の見通し線内にある部屋に位置するユーザデバイス2722は、それが放射した超音波信号が受信されるにはハザードデバイス2710から離れすぎている。キッチン内に配置され、ハザードデバイス2710の見通し線内に位置するユーザデバイス2723は、それが放射した超音波信号をハザード検出デバイス2710に伝達することができる。
いくつかの実施形態では、超音波信号は、任意の適切なデータで符号化することができる。例えば、データは、デバイスIDおよび/または部屋IDを識別する識別情報を含むことができる。データは、解除命令などの命令を含むことができる。超音波信号は、擬似ランダム非繰り返しパターンとして放射することができる。信号は、4ビット符号を含むことができ、または8ビット符号で送信するために連結することができる。
図28は、一実施形態による例示的な音響データエンコーダ2800を示す。エンコーダ2800は、線形フィードバックシフトレジスタ(LFS)2810、アップサンプラ2812、搬送正弦波発生器2820、データ波発生器2830、乗算器2840、ハイパスフィルタ2850、及び出力2860を含むことができる。エンコーダ2800は、出力2860によって放射される超音波信号にデータを組み込むために搬送波周波数において振幅変調を使用する。キャリア周波数(XHzとして示す)は、搬送正弦波発生器2820によって設定され、乗算器2840に与えられるLFSR2810およびアップサンプラ2812は、ランダムノイズを乗算器2840に注入するように機能する。データは、データ波発生器2830に供給され、データ波発生器2830は、データを乗算器2840に送る。乗算器2840は、ノイズ、搬送波周波数およびデータを一緒に混合し、結合された信号をハイパスフィルタ2850に与え、ハイパスフィルタ2850はその信号をフィルタ処理し、信号はその後出力2860によって放射される。
図29は、一実施形態による、ハザード検出システムによる検出のためにユーザデバイスが超音波信号を放射する例示的なプロセス2900を示す。図29は、ハザード検出システムおよびユーザデバイスによってそれぞれ実行されるステップを半分に分割して示している。プロセス2900は、ステップ2902で開始することができ、ハザード検出デバイスは警報イベント(例えば、煙警報、CO警報、または前期警報警報)を検出する。ステップ2904で、検出された警報イベントをデバイスに警告するために無線信号を送信することができる。無線信号は、ユーザデバイスに警告するためのBLE信号、WiFi信号、または6LOWPAN信号であり得る。ステップ2906において、ユーザデバイスは無線信号を受信することができる。無線信号の受信に応答して、ユーザが無線信号をハザード検出に送信することを可能にするユーザインターフェイスを表示することができる(2907)。例えば、ユーザインターフェイスは、(例えば、図XXのような)警報を解除するためのオプションを提供することができる。ステップ2908において、無線信号を送信するためのユーザコマンドを受信することができる。
ステップ2910において、ユーザデバイスは無線信号を送信することができる。ステップ2912において、ユーザデバイスは、超音波信号を放射することができる。いくつかの実施形態では、ユーザデバイスは、同時に、超音波信号を放射し、無線信号を送信することができる。他の実施形態では、ユーザデバイスは、無線信号を送信するためのユーザコマンドが受信された後、または無線信号がハザード検出デバイスから受信された後、定期的な間隔で超音波信号を放射することができる。
ステップ2914において、ハザード検出デバイスは、ユーザデバイスから無線信号を受信することができる。ハザード検出デバイスは、ステップ2916として、超音波信号が検出されたか否かを判定することができる。ステップ2916における判定がNOである場合、プロセス2900はステップ2914に戻ることができる。ステップ2916の判定がYESである場合、ハザード検出デバイスは、ステップ2918に示すように、受信した無線信号の肯定応答をユーザデバイスに送信することができる。ステップ2920において、ユーザデバイスによって放射されている超音波信号を同時に検出しながら、(ユーザデバイスからの)無線信号の受信に応答して、あるアクションを実行することができる。実行されるアクションは、例えば、鳴動警報の消音であり得る。
ステップ2922において、ユーザデバイスは、肯定応答がハザード検出デバイスによって受信されたか否かを判定することができる。判定がNOの場合、プロセス2900はステップ2910に戻ることができる。判定がYESである場合、ユーザデバイスは無線信号の送信を中止し、超音波信号の放射を中止することができる(2924)。
図29に示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。
図30は、一実施形態による、ハザード検出デバイスが超音波信号を放射し、ユーザデバイスが超音波信号の存在を監視する、例示的なプロセス3000を示す。図30は、ハザード検出システムおよびユーザデバイスによってそれぞれ実行されるステップを半分に分割して示している。プロセス3000は、ステップ3002で開始することができ、ハザード検出デバイスは警報イベント(例えば、煙警報、CO警報、または前期警報警報)を検出する。ステップ3004で、検出された警報イベントをデバイスに警告するために無線信号を送信することができる。ステップ3006において、ハザード検出デバイスは、超音波信号を放射する。
ステップ3008において、ハザード検出デバイスによって放射された無線信号は、ユーザデバイスによって受信される。その無線信号の受信に応答して、ステップ3010において、ユーザデバイスは、ユーザが無線信号を介してハザード検出デバイスにコマンドを送信することを可能にするユーザインターフェイスを表示する。ステップ3012において、無線信号を介して命令を送信するためのユーザコマンドを受信することができる。ステップ3014において、ハザード検出デバイスが放射している超音波信号を検出したかどうかの判定が行われる。判定がNOである場合、ユーザデバイスは、ステップ3016において、ハザード検出システムの見通し線内を移動するようにユーザに指示してもよく、次いでプロセス3000はステップ3014に戻る。判定がYESである場合、ユーザデバイスは、ステップ3018で、ユーザが開始した命令で無線信号を送信することができる。
ステップ3020において、無線信号がユーザデバイスから受信される。ステップ3022において、無線信号を受信したことに応答して、あるアクションが実行される(例えば、ブザーの解除)。
図DDに示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。
図31は、一実施形態による、データを超音波信号に符号化し、データを超音波信号から復号化するための、例示的なプロセス3100を示す。図31は、超音波信号の送信機と超音波信号の受信機とをそれぞれ半分に分割して示している。最初に送信機について説明する。ステップ3110から開始して、データを、振幅変調された搬送波信号に符号化することができる。例えば、図CCのエンコーダを用いてデータを音響信号に符号化することができる。ステップ3112において、符号化されたデータ信号をスピーカに与えることができ、スピーカは、符号化されたデータ信号を音響信号として放射する。次に受信機について説明する。ステップ3120において、音響信号を受信することができる。ステップ3122において、受信された音響信号が復号され、そこで符号化されたデータが得られる。ステップ3124で、データが処理され、適切なアクションがとられる。
図32は、ある実施形態に従って、飛行時間計算が、ハザード検出デバイスに対するユーザデバイスの位置を判定するために使用される、例示的なプロセス3200を示す。図32は、開始側によって実行されるステップおよび応答側によって実行されるステップを示すために、半分に分割される。したがって、一実施形態では、開始側はハザード検出デバイスであり得、応答側はユーザデバイスであり得、別の実施形態では開始側はユーザデバイスであり得、応答側はハザード検出デバイスであり得る。
ステップ3210から開始して、第1の音響信号が、第1の期間で開始側によって放射され得る。第1の音響信号は、超音波信号であってもよい。ステップ3212において、応答側は、例えば、マイクロホンを介して、第1の音響信号を受信することができる。ステップ3214において、応答側は、第1の信号の受信に応答して、第2の音響信号を送信することができる。第2の音響信号は、ステップ3216で第2の期間で受信することができる。
ステップ3218において、音響信号の飛行時間が、第1および第2の期間に基づいて計算される。この計算は、第1の期間と第2の期間との間の差であり得る。ステップ3220において、開始側と応答側との間の距離が、音響信号の計算された飛行時間及び速度に基づいて判定され得る。例えば、信号の計算された飛行時間と空気中を移動する信号の速度とを乗算することによって、距離を計算することができる。ステップ3222では、距離がアクション可能な範囲内にあるかどうかの判定が行われる。判定がNOの場合、プロセス3200はステップ3210に戻ることができる。判定がYESである場合、ステップ3224で、あるアクションを実行することができる(例えば、ブザーを解除)。
図32に示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。