(57)【要約】  本開示の実施形態は、音響的存在検証を用いて遠隔警報解除を可能にするための方法およびシステムを提供する。音響的存在検証は、警報が解除される前に、警報を遠隔で非活性化しようとするデバイスが警報を発令しているデバイスからある距離内に位置することを保証するために用いられる。音響的存在は、超音波音響信号の放射および監視を通して確立することができる。超音波音響信号は、例えば、１８ｋＨｚと２２ｋＨｚとの間のような人間の聴力を超える周波数で送信されてもよい。このような超音波信号は、比較的短い範囲を有し、壁および床を貫通することができず、したがって、警報を発令しているデバイスを遠隔で解除しようとするデバイスが警報を発令しているデバイスの見通し線内にあることを確実にする有効なツールを提供する。
2019500659.tif 000002
【特許請求の範囲】
【請求項１】
命令を格納する非一時的なコンピュータ可読媒体であって、前記命令は、実行されると、プロセッサに、
警報イベントを検出させ、
第１のワイヤレス通信タイプを使用してワイヤレス接続広告を送信して、検出された前記警報イベントをユーザデバイスに対して警告させ、
前記第１のワイヤレス通信タイプを使用して前記ユーザデバイスへの接続を確立させ、
前記接続を介して、前記警報を解除するための解除要求を受信させ、
前記ユーザデバイスによって放射される超音波信号の存在について、マイクロホンを用いて監視させ、
前記超音波信号が監視されている場合に、前記超音波信号の存在を同時に監視しながら解除要求の受信に応答してアクションを実行させるように構成される、非一時的なコンピュータ可読媒体。
【請求項２】
前記命令は、前記プロセッサに、
前記超音波信号が監視されない場合には、前記ユーザデバイスによって放射されている超音波信号の存在を監視し続けさせるように構成される、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項３】
前記超音波信号は、１８ｋＨｚ〜２２ｋＨｚの範囲の周波数を含む、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項４】
前記超音波信号は、前記ユーザデバイスが前記マイクロホンの見通し線内にある場合にのみ監視される、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項５】
前記超音波信号は、前記超音波信号内においてデータを含むようにキャリア周波数上で振幅変調される、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項６】
前記アクションは、警報解除アクションを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項７】
前記第１のワイヤレス通信タイプは、Ｂｌｕｅｔｏｏｔｈ低エネルギ（ＢＬＥ）接続タイプを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
【請求項８】
ハザード検出システムとインターフェイスする際に使用するための電子デバイスであって、
ワイヤレス通信回路と、
超音波エミッタと、
プロセッサと、
命令を記憶するメモリとを備え、前記命令は、実行されると、前記プロセッサに、
前記ハザード検出システムから、第１のワイヤレス通信タイプを使用して、ネットワークインターフェイスを介して、前記ハザード検出システムが警報を鳴動させていることを示すワイヤレス接続広告を受信させ、
前記第１のワイヤレス通信タイプを使用して、前記ネットワークインターフェイスを介して、前記ハザード検出システムへの接続を確立させ、
前記接続を介して、警報を解除するための解除要求を送信させ、
前記超音波エミッタを介して、超音波信号を放射させるように構成され、前記超音波信号は、前記ハザード検出システムの見通し線内で前記電子デバイスの存在を確認するために使用される、ハザード検出システムとインターフェイスする際に使用するための電子デバイス。
【請求項９】
前記命令は、前記プロセッサに、
前記接続を介して肯定応答信号が受信されたかどうかを判定させるように構成され、前記肯定応答信号は、前記ハザード検出システムが前記解除要求を受信し、放射された前記超音波信号の存在を検出したことを確認し、前記命令は、前記プロセッサに、さらに、
前記肯定応答信号が受信されたという判定に応答して、前記解除要求の送信を停止させ、前記超音波信号の放射を停止させ、
前記肯定応答信号が受信されていないという判定に応答して、前記解除要求を送信し続けさせ、前記超音波信号を放射し続けさせるよう構成される、請求項８に記載の電子デバイス。
【請求項１０】
前記命令は、前記プロセッサに、
ユーザが解除要求オプションを選択することを可能にするユーザインターフェイスを表示させ、
前記解除要求オプションのユーザ選択を受信させるように構成される、請求項８に記載の電子デバイス。
【請求項１１】
前記超音波信号は、１８ｋＨｚから２２ｋＨｚの範囲の周波数を含む、請求項８に記載の電子デバイス。
【請求項１２】
前記超音波信号は、人間の聴力を超える周波数を含む、請求項８に記載の電子デバイス。
【請求項１３】
警報を解除する方法であって、
警報を発令しているデバイスのセンサから、測定されたレベルが警報閾値を超過したという指示を受信することと、
超過された警報閾値に対応する警報を開始することと、
第１のワイヤレス通信タイプを使用してワイヤレス接続広告を送信することと、
前記第１のワイヤレス通信タイプを使用してリモートデバイスへの接続を確立することと、
前記リモートデバイスが前記警報を発令しているデバイスの見通し線内にあるときに前記リモートデバイスによって受信されるように意図される超音波信号を放射することと、
前記接続を介して前記警報を解除するための解除要求を受信することとを備え、前記解除要求は、前記リモートデバイスが前記放射された超音波信号を処理した後に受信され、前記方法はさらに、
前記解除要求を受信したことに応答して前記警報を解除することを備える、方法。
【請求項１４】
前記超音波信号はデータを含み、前記解除要求は前記データの少なくとも一部を含む、請求項１３に記載の方法。
【請求項１５】
前記超音波信号は、人間の聴覚の周波数を超える周波数を含む、請求項１３に記載の方法。
【請求項１６】
電子デバイスで警報を解除する方法であって、
ハザード検出システムから、第１のワイヤレス通信タイプを使用して、ネットワークインターフェイスを介して、前記ハザード検出システムが警報を鳴動させていることを示すワイヤレス接続広告を受信することと、
前記第１のワイヤレス通信タイプを使用して、前記ネットワークインターフェイスを介して、前記ハザード検出システムへの接続を確立することと、
前記ハザード検出システムによって放射される超音波信号の存在を監視することと、
前記超音波信号の監視された存在に応答して、前記接続を介して、前記警報を解除するための解除要求を送信することとを備える、電子デバイスで警報を解除する方法。
【請求項１７】
前記超音波信号は、前記ハザード検出システムの見通し線内で前記電子デバイスの存在を確認するために使用される、請求項１６に記載の方法。
【請求項１８】
前記超音波信号は、人間の聴覚の周波数を超える周波数を含む、請求項１６に記載の方法。
【請求項１９】
ユーザが解除要求オプションを選択することを可能にするユーザインターフェイスを表示することと、
前記解除要求オプションのユーザ選択を受信することとをさらに備える、請求項１６に記載の方法。
【請求項２０】
前記ユーザインターフェイス上に、前記ユーザが前記ハザード検出の見通し線内において移動するよう命令を表示することをさらに備える、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の背景
本開示は、スマートホームを含む小型建築物のためのシステム、デバイス、方法、および関連するコンピュータプログラム製品に関する。より詳細には、この特許明細書は、超音波音響信号を使用するデバイスに関する。
【背景技術】
【０００２】
今日の家庭の一部には、暖房、換気、空調（「ＨＶＡＣ」）システム、照明システム、警報システム、ホームシアター、娯楽システムなどのデバイス、機器、システムの自動制御を実現するスマートホームネットワークが装備されている。ある場合では、１つまたは複数のデバイスは、電力制約、ネットワーク制限、または利用可能な通信タイプの制約を持つ場合がある。したがって、電力制約または他の制限（例えば、利用可能な通信タイプ）を有するいくつかのデバイスは、比較的低電力のネットワークまたは通信タイプを使用するように制約され得る。しかしながら、これらの比較的低電力の接続は、デバイス間の完全な接続を妨げる制約（例えば、一方向通信）を有することがある。さらに、１つまたは複数のデバイスに接続する他のデバイスは、選択（例えば、８０２．１５）通信タイプを使用して通信するハードウェア（例えば、無線）のみを有し得る。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
さらに、これらのデバイスの中には、警報を発令するハザード検出器を含むものもある。いくつかの場合では、クリティカルイベントが検出されたときに、これらのハザード検出器が警報を発令することがある。これらの警報を解除するには、警報を発令しているデバイスとの物理的接触がしばしば必要となるが、デバイスの配置が典型的なユーザの手の届かないところにある場合、そのような接触は困難であり得る。
【課題を解決するための手段】
【０００４】
開示の概要
本明細書に開示される特定の実施形態の概要を以下に示す。これらの態様は、単にこれらの特定の実施形態の簡単な概要を読者に提供するために提示されており、これらの態様は本開示の範囲を限定するものではないことを理解されたい。実際、この開示は、以下に説明されない場合がある様々な態様を包含することができる。
【０００５】
本開示の実施形態は、音響的存在検証を用いて遠隔警報解除を可能にするための方法およびシステムを提供する。音響的存在検証は、警報が解除される前に、警報を遠隔で非活性化しようとするデバイスが警報を発令しているデバイスからある距離内に位置することを保証するために用いられる。音響的存在は、超音波音響信号の放射および監視を通して確立することができる。超音波音響信号は、例えば、１８ｋＨｚと２２ｋＨｚとの間のような人間の聴力を超える周波数で送信されてもよい。このような超音波信号は、比較的短い範囲を有し、壁および床を貫通することができず、したがって、警報を発令しているデバイスを遠隔で解除しようとするデバイスが警報を発令しているデバイスの見通し線内にあることを確実にする有効なツールを提供する。
【０００６】
本開示の様々な態様は、以下の詳細な説明を読み、図面を参照することにより、よりよく理解されるであろう。
【図面の簡単な説明】
【０００７】
【図１】実施形態による、ここに記載されるデバイス、方法、システム、サービス、および／またはコンピュータプログラム製品の１つ以上が用いられてもよいスマートホーム環境の例を示す。
【図２】実施形態による、図１のスマートホーム環境が統合され得る拡張可能なデバイスおよびサービスプラットフォームのネットワークレベル図を示す。
【図３】実施形態による、処理エンジンおよびスマートホーム環境のデバイスを参照して、図２の拡張可能なデバイスおよびサービスプラットフォームの機能図を示す。
【図４】一実施形態による、スマートホーム環境内またはスマートホーム環境なしで他のデバイスと通信することができるスマートデバイスのブロック図を示す。
【図５】一実施形態による、アプリケーション層、トランスポート層、およびネットワーク層を含むレイヤにおける通信システムの機能を示すモデル図である。
【図６】一実施形態による、少なくとも１つのデバイスがスマートホーム環境の一部である、デバイス間の情報交換を示す図である。
【図７】一実施形態による、クライアントとサーバとの間のＢＬＥ対話の概略図である。
【図８】一実施形態による、図７のクライアントとサーバとの間における、クライアントが特性に書込を行なうときの通信対話を示す。
【図９】一実施形態による、図７のクライアントとサーバとの間における、サーバが特性に書込を行なうときの通信対話を示す。
【図１０】一実施形態による、ＢＬＥサービスを介する図７のクライアントとサーバとの間の対話のブロック図を示す。
【図１１】一実施形態による、ブルートゥース（登録商標）転送プロトコルを使用して送信され得る、パックされたデータを示す図である。
【図１２】一実施形態による、図７のクライアントとサーバとの間の広告通信を示すブロック図である。
【図１３】一実施形態による、広告パケットおよびスキャン応答パケットを含む広告のブロック図を示す。
【図１４】一実施形態による、ＢＬＥ接続のための一般的なフォーマット広告を示す図である。
【図１５】一実施形態による、ＢＬＥ接続のためのクリティカルサービス広告を示す図である。
【図１６】一実施形態による例示的なハザード検出システムおよび例示的なユーザデバイスのブロック図を示す。
【図１７】一実施形態による、スマートデバイスを遠隔で解除するために使用されるデバイス間の相互接続を示す図である。
【図１８】一実施形態による、警報を解除するためのプロセスのフローチャート図を示す。
【図１９】一実施形態による、図１８のプロセスで使用される警告画面を示す。
【図２０】一実施形態による、図１８のプロセスで使用され得る解除確認画面を示す。
【図２１】一実施形態による、図１８のプロセス中の視覚的変化を反映する解除確認画面を示す。
【図２２】一実施形態による、図１８のプロセスにおいて使用され得る消音画面を示す。
【図２３】一実施形態による、図１８のプロセス中の成功または失敗を示すために使用され得る結果画面を示す。
【図２４】一実施形態による、図１９の、解除が実行された後の、更新された警告画面を示す。
【図２５Ａ】一実施形態による、警報を解除および伝播するプロセスを示す。
【図２５Ｂ】一実施形態による、警報を解除および伝播するプロセスを示す。
【図２６】一実施形態による、スマートデバイスの警報状態のための状態マシンを示す図である。
【図２７】ハザードデバイスがキッチン内に配置され、ユーザデバイスが図示されている様々な場所に配置された、家屋の例示的な床平面図を示す。
【図２８】一実施形態による例示的な音響データ符号器を示す図である。
【図２９】一実施形態による、ハザード検出システムによる検出のためにユーザデバイスが超音波信号を放射する例示的なプロセスを示す。
【図３０】一実施形態による、ハザード検出デバイスが超音波信号を放射し、ユーザデバイスが超音波信号の存在を監視する例示的なプロセスを示す図である。
【図３１】一実施形態による、超音波信号へのデータの符号化および超音波信号からのデータの復号化のための例示的なプロセスを示す。
【図３２】一実施形態による、飛行時間計算を使用して、ハザード検出デバイスに対するユーザデバイスの位置を判定する例示的なプロセスを示す図である。
【発明を実施するための形態】
【０００８】
開示の詳細な説明
以下、本開示の１つまたは複数の特定の実施形態を説明する。これらの記載された実施形態は、現在開示されている技術の単なる例である。さらに、これらの実施形態の簡潔な説明を提供するために、実際の実現例のすべての特徴は本明細書に記載されていない場合がある。任意の工学または設計プロジェクトにおけるように、任意のそうした実際の実現例を開発するには、実現例ごとに異なる可能性があるシステム関連およびビジネス関連の制約への準拠など、開発者の特定の目標を達成するために実現例固有の判断を多数行う必要がある。さらに、そのような開発努力は、複雑で時間がかかるかもしれないが、それにもかかわらず、この開示の恩恵を受ける当業者にとって設計、製作および製造の日常的な業務であり得ることが理解されるべきである。
【０００９】
本開示の様々な実施形態の要素を導入する際に、冠詞「a」、「an」および「the」は、それら要素の１つまたは複数が存在することを意味することを意図している。「備える（comprising）」、「含む（including）」および「有する（having）」という用語は、包括的であり、列挙された要素以外の追加の要素が存在し得ることを意味することが意図される。さらに、本開示の「一実施形態」または「ある実施形態」への言及は、記載された特徴をも組み込む追加の実施形態の存在を排除するものとして解釈されるものではないことを理解されたい。
【００１０】
本開示の実施形態は、一般に、ＢＬＥを介して比較的洗練されたアプリケーション層メッセージを送信し、そのような通信を使用してスマートネットワークにおいて警報を遠隔で解除することに関する。「スマートホーム環境」は、１つまたは複数のスマートデバイスを含んでもよい、一戸建て住宅、複式マンション、タウンホーム、複数ユニットのアパート、ホテル、小売店、オフィスビル、工業用建物および任意の建物などの任意の建物タイプのためのスマート環境またはスマートネットワークを意味することができることを理解されたい。
【００１１】
さらに、ユーザ、顧客、設置者、住宅所有者、居住者、ゲスト、テナント、賃貸人、修繕者、ユーザといった用語は、ネットワーク内でユーザインタフェースを介してスマートデバイスと対話する人に言及するために使用されてもよいが、これらの言及は、このような動作を実行する人に関して本教示の範囲を限定するものと決してみなされるものではないことが理解されるべきである。したがって、例えば、ユーザ、顧客、購入者、設置者、加入者、および住宅所有者という用語は、一戸建て住居の場合において同じ人をさすことがあり得ることが多く、なぜならば、家長は、購入を判断し、ユニットを購入し、ユニットを設置および構成し、ユニットのユーザの１人でもある人であるからである。しかしながら、家主−テナント環境のような他の場合では、顧客はユニットの購入に関して家主であり得、設置者は地元のアパート監督者であり得、第１のユーザはテナントであり得、第２のユーザは再び遠隔制御機能性に関して再び家主であり得る。アクションを実行する人物の身元は、１つまたは複数の実施形態によって提供される特定の利点に密接に関連してもよい-例えば、本明細書で説明するパスワード保護されたネットワークコミッショニング機能は、家主が唯一のパスワードを保持し、ネットワークの追加を制御できる場合に特に有利である-一方で、そのような身元は、以下の記述において、本教示の範囲をこれらの特定の身元を有する特定の個人に必然的に限定するものとして解釈されるべきではない。
【００１２】
Ｉ．スマートネットワーク
上述のことを念頭に置いて、図１は、本明細書でさらに説明されているデバイス、方法、システム、サービス、および/またはコンピュータプログラム製品のうちの１つまたは複数が適用可能であるものとしてよい、スマートネットワークとも称される、スマートホーム環境１００の一例を示している。図示されているスマートホーム環境１００は、構造物１５０を含み、これは例えば、家、オフィスビル、車庫、またはトレーラーハウスを含み得る。いくつかの実施形態では、デバイスは、アパートメント、コンドミニアム、またはオフィススペースなどの構造物１５０全体を含まないスマートホーム環境１００内に組み込まれ得ることは理解されるであろう。さらに、スマートホーム環境では、実際の構造物１５０の外部のデバイスを制御し、および/またはそれに結合され得る。実際、スマートホーム環境内の複数のデバイスは、構造物１５０内に物理的に存在する必要はまったくない。例えば、プールヒーターまたは灌漑システムを制御するデバイスは、構造物１５０の外部に配置され得る。
【００１３】
図示されている構造物１５０は、壁１５４を介して互いに少なくとも部分的に隔てられている、複数の部屋１５２を備える。壁１５４は、内壁または外壁を備えることができる。それぞれの部屋は、床１５６と天井１５８とをさらに備えることができる。デバイスは、壁１５４、床１５６または天井１５８に装着され、一体化され、および/または支持され得る。
【００１４】
いくつかの実施形態では、図１のスマートホーム環境１００は、スマートホームのさまざまな有益な目的を達成するために互いに、中央サーバに、クラウドコンピューティングシステムに、またはそれらの何らかの組み合わせにシームレスに統合され得る、インテリジェント型マルチセンサネットワーク接続デバイスを含むさまざまなデバイスを備える。スマートホーム環境１００は、１つまたは複数のインテリジェント型マルチセンサネットワーク接続サーモスタット１０２(これ以降「スマートサーモスタット１０２」と称する)、１つまたは複数のインテリジェント型ネットワーク接続マルチセンサハザード検出ユニット１０４(これ以降「スマートハザード検出器１０４」と称する)、１つまたは複数のインテリジェント型マルチセンサネットワーク接続ドアベルデバイス１０６(これ以降「スマートドアベル１０６」と称する)、１つ以上のインテリジェント型ネットワーク接続ドアロック１０７（以下、「スマートドアロック１０７」と呼ぶ）、または有線インターフェイスもしくはワイヤレスインターフェースを使用して相互接続することができる他のデバイスを含み得る。
【００１５】
いくつかの実施形態によれば、スマートサーモスタット１０２は、周辺気候特性(例えば、温度および/または湿度)を検出し、HVACシステム１０３をしかるべく制御する。スマートハザード検出器１０４は、危険な物質または危険な物質を示す物質(例えば、煙、火炎、または一酸化炭素)の存在を検出することができる。スマートベル１０６は、人の場所への接近または場所から退去(例えば、廊下に通じるドア)を検出し、ドアベルの機能を制御し、人の接近もしくは退去を音響的もしくは視覚的手段を介して知らせる、またはセキュリティシステム上の設定を制御する(例えば、居住者の出入りのときにセキュリティシステムを作動もしくは停止するため)ことができる。スマートドアロック１０７は、家屋内のドアのロック状態とロック解除状態とを検出し、それらの状態間をトグルで切換えるか、それぞれのドアへの人の接近または退去を検出するか、ドアが開いているか閉じているかを検出するか、またはスマートドアロックに関連する他の適切な制御を検出する。
【００１６】
いくつかの実施形態では、図１のスマートホーム環境１００は、１つまたは複数のインテリジェント型マルチセンサネットワーク接続壁面スイッチ１０８(これ以降「スマート壁面スイッチ１０８」と称する)を、１つまたは複数のインテリジェント型マルチセンサネットワーク接続壁面コンセントインターフェース１１０(これ以降「スマート壁面コンセント１１０」と称する)と共に備え得る。スマート壁面スイッチ１０８は、周囲照明状態を検出し、在室状態を検出し、１つまたは複数の照明の電力および/または減光状態を制御することができる。いくつかの場合において、スマート壁面スイッチ１０８は、天井にある扇風機などの扇風機の電力状態または速度を制御することもできる。スマート壁面コンセント１１０は、部屋またはエンクロージャの在室を検出し、１つまたは複数の壁面コンセントへの電力の供給を制御する(例えば、家の中に誰も居ない場合に電力をコンセントに供給しない)ことができる。
【００１７】
さらに、いくつかの実施形態では、図１のスマートホーム環境１００は、冷蔵庫、ストーブおよび/またはオーブン、テレビ、洗濯機、乾燥機、照明、ステレオ、インターコムシステム、車庫扉開閉装置、床の扇風機、天井の扇風機、壁面設置型空調装置、プールヒーター、灌漑システム、セキュリティシステム、窓センサ、セキュリティシステムなどの、複数のインテリジェント型マルチセンサネットワーク接続アプライアンス１１２(これ以降「スマートアプライアンス１１２」と称する)を備える。いくつかの実施形態によれば、ネットワーク接続アプライアンス１１２は、アプライアンスの各メーカーと連携することによってスマートホーム環境との互換性を確保してもよい。例えば、アプライアンスは、室内暖房具、窓用ACユニット、電動式ダクトベントなどとすることができる。コンセントに接続すると、アプライアンスは自分が何であるかを、自分がどのような種類のアプライアンスであるかを示すことなどによってスマートホームネットワークに知らせ、スマートホームの制御装置と自動的に統合することができる。アプライアンスによるスマートホームへのそのような通信は、当業者によって知られている有線もしくはワイヤレス通信プロトコルにより円滑にされ得る。スマートホームは、スマート壁面コンセント１１０を使って、粗くはあるが(ON/OFF)、制御できる古い従来型の洗濯機/乾燥機、冷蔵庫、および同様のものなどの、さまざまな非通信型の従来機器１４０も備えることができる。スマートホーム環境１００は、スマートハザード検出器１０４またはスマート壁面スイッチ１０８によって供給されるIR信号によって制御され得る、赤外線(「IR」)制御壁面設置型空調装置または他のIR制御デバイスなどの、さまざまな部分的な通信を行う従来機器１４２をさらに備えることができる。
【００１８】
いくつかの実施形態によれば、スマートホーム環境１００のスマートサーモスタット１０２、スマートハザード検出器１０４、スマートドアベル１０６、スマートドアロック１０７、スマート壁面スイッチ１０８、スマート壁面コンセント１１０、および他のデバイスは、モジュール式であり、より古い家および新しい家に組み込まれ得る。例えば、いくつかの実施形態では、これらのデバイスは、２つの基本コンポーネントからなるモジュール式プラットフォームの周りに取り付けるように設計され、これらのコンポーネントは、ヘッドユニットおよびバックプレートであり、ドッキングステーションとも称される。ドッキングステーションの複数の構成は、より古い家およびより新しい家など、いかなる家とも互換性を有するように用意される。しかし、ドッキングステーションはすべて、標準的なヘッド接続配置構成を備え、これにより、ヘッドユニットは、いかなるドッキングステーションにも取り外し可能に取り付けることができる。したがって、いくつかの実施形態では、ドッキングステーションは、家の構造物および電圧配線への物理的接続部として機能するインターフェイスであり、交換可能なヘッドユニットは、センサ、プロセッサ、ユーザーインターフェース、バッテリ、およびデバイスの他の機能的コンポーネントのすべてを収容する。
【００１９】
プロビジョニング、メンテナンス、およびアップグレードに関して商業面および機能面で多くのさまざまなことが将来起こり得ることが考えられる。例えば、特定のヘッドユニットを何年も使用した後に、ユーザは、新バージョンのヘッドユニットを購入して、古いドックステーションに単に接続することができる。また、ヘッドユニットには、機能を減らした廉価バージョン、次いで、機能が次第に高くなって行く一連のバージョンなど、多数の機能を備える洗練されたヘッドユニットに至るまで、多くの異なるバージョンがある。したがって、ヘッドユニットのさまざまなバージョンは取り替え可能であり、それらはどれもドッキングステーション内に配設されたときに動作し得ることは理解されるであろう。これは、古いヘッドユニットの共有および再配備を助長し都合がよい--例えば、ハザード検出器などの重要な高機能ヘッドユニットが、ヘッドユニットの新しいバージョンで置き換えられるときに、古いヘッドユニットは、裏の部屋または地下室などに再配備することができる。いくつかの実施形態によれば、最初にドッキングステーションに差し込んだときに、ヘッドユニットは、ユーザに(2D LCDディスプレイ、2D/3Dホログラフィック投影、ボイスインタラクションなどによって)、「Where am I(ここはどこ)」などの少数の単純な質問をすることができ、ユーザは、「living room(居間)」、「台所」などを指示することができる。
【００２０】
スマートホーム環境１００は、物理的な家の外側にあるが、家の近接地理的範囲内にあるデバイスとの通信も含み得る。例えば、スマートホーム環境１００は、スマートホーム環境１００内の他のデバイスに現在のプール温度を伝達するか、またはプール温度を制御するためのコマンドを受信するプール加熱装置監視装置１１４を備えることができる。同様に、スマートホーム環境１００は、スマートホーム環境１００内の灌漑システムに関する情報を伝達し、および/またはそのような灌漑システムを制御するための制御情報を受信する灌漑監視装置１１６を備えることができる。いくつかの実施形態によれば、家庭の郵便番号または地理的座標などに基づき、スマートホーム環境１００の地理的配置を考慮するためのアルゴリズムが提供される。次いで、地理的情報が、散水に最適な時間を決定するのに役立つデータを取得するために使用され得る。そのようなデータは、太陽位置情報、温度、露点、家が建っている土地の土壌の種類などを含み得る。
【００２１】
ネットワーク接続性のおかげで、図１のスマートホームデバイスの１つまたは複数は、ユーザがデバイスの近くに居ない場合であっても、ユーザがデバイスをインタラクティブに操作することも可能にすることができる。例えば、ユーザは、コンピュータ(例えば、デスクトップコンピュータ、ラップトップコンピュータ、もしくはタブレット)または他の携帯型電子デバイス(例えば、スマートフォン)１６６を使用してデバイスと通信することができる。ウェブページまたはアプリは、ユーザからの通信を受信し、通信に基づきデバイスを制御し、および/またはデバイスの動作に関する情報をユーザに提示するように構成され得る。例えば、ユーザは、デバイスに対する現在の設定点温度を見て、コンピュータを使用してそれを調整することができる。ユーザは、このリモート通信の間に構造物内に居てもよいし、または構造物の外部に居てもよい。
【００２２】
説明されているように、ユーザは、ネットワーク接続コンピュータまたは携帯型電子デバイス１６６を使用してスマートホーム環境１００内のスマートサーモスタットおよび他のスマートデバイスを制御することができる。いくつかの実施形態では、デバイス１６６は、スマートネットワークに、直接、または１つ以上のデバイス（たとえば、エッジルータ）を使用してスマートネットワークに接続される追加のネットワーク（たとえばＷｉＦｉ）を介して、接続され得る。いくつかの例では、居住者(例えば、家に住んでいる個人)の一部または全部が、自分たちのデバイス１６６をスマートホーム環境１００に登録することができる。そのような登録は、居住者および/またはデバイスをその家に関連付けられているものとして認証し、デバイスを使用して家の中のスマートデバイスを制御する許可を居住者に与えるために中央サーバ側で実行され得る。居住者は、居住者が就業中であるか、または休暇中であるときなどに、自分の登録されたデバイス１６６を使用して家のスマートデバイスを遠隔制御することができる。居住者は、居住者が家の中のカウチに座っているときなど、居住者が家の中に実際に居るときに、登録されたデバイスを使用してスマートデバイスを制御することもできる。デバイス１６６を登録する代わりに、または登録することに加えて、スマートホーム環境１００は、どの個人がその家に住んでいるか、したがって居住者であるか、またどのデバイス１６６がそれらの個人に関連付けられているかに関して推論し得ることは理解されるであろう。そのようなものとして、スマートホーム環境は、居住者である人を「学習」し、それらの個人に関連付けられているデバイス１６６が家のスマートデバイスを制御することを許可する。
【００２３】
いくつかの場合において、ゲストが、スマートデバイスを制御することを望むことがある。例えば、スマートホーム環境は、家の中の個人の未登録のモバイルデバイスから通信を受信することができ、その場合、前記個人は、家の居住者として認識されない。例えば、スマートホーム環境は、ゲストであると知られているか、もしくはゲストとして登録されている個人のモバイルデバイス、またはスマートデバイスとして共通のネットワーク（例えば、SSID WiFiネットワーク）上にあると判断されるモバイルデバイスから通信を受信することができる。
【００２４】
いくつかの実施形態では、処理および感知機能を収容することに加えて、デバイス１０２、１０４、１０６、１０７、１０８、１１０、１１２、１１４、１１６、１６２、１７０および他のスマートデバイス(「スマートデバイス」と総称される)のそれぞれは、データ通信および情報共有を、それらのスマートデバイスのうちの他のデバイスと、さらには中央サーバもしくはクラウドコンピューティングシステムもしくは世界のどこかでネットワーク接続されている他のデバイスに対して行うことができ得る。必要とされるデータ通信は、さまざまなカスタムもしくは標準的なワイヤレスプロトコル(Wi-Fi、ZigBee(登録商標)、6LoWPANなど)および/またはさまざまなカスタムもしくは標準有線プロトコル(CAT6 Ethernet(登録商標)、HomePlugなど)を使用して実行され得る。
【００２５】
いくつかの実施形態によれば、スマートデバイスは、すべてまたは一部が、ワイヤレスまたは有線リピーターとしての機能を果たすことができる。例えば、スマートデバイスのうちの第１のデバイスは、ワイヤレスルーター１６０を介してスマートデバイスのうちの第２のデバイスと通信することができる。スマートデバイスは、インターネット１６２などの、ネットワークへの接続を介して互いにさらに通信することができる。インターネット１６２を通じて、スマートデバイスは中央サーバまたはクラウドコンピューティングシステム１６４と通信することができる。中央サーバまたはクラウドコンピューティングシステム１６４は、デバイスに関連付けられている製造業者、サポートエンティティ、またはサービスプロバイダと関連付けられ得る。ある実施形態について、ユーザは、電話またはインターネット接続コンピュータなどの他の通信手段を使用することなくデバイスそれ自体を使用してカスタマーサポートとコンタクトをとることができるものとしてよい。さらに、ソフトウェア更新は、中央サーバまたはクラウドコンピューティングシステム１６４からスマートデバイスに自動的に送信され得る(例えば、利用可能になったとき、購入したとき、または定期的間隔で)。
【００２６】
以下に論ずるように、スマートデバイス同士を組み合わせることで、メッシュネットワークを形成してもよい。いくつかの実施形態では、このメッシュネットワークはスポークスマンノードおよび低電力ノードをスマートホーム環境１００において含んでもよく、スマートデバイスのうちのいくつかは、「スポークスマン」ノードであり、他は、「低電力」ノードである。スマートホーム環境１００内のスマートデバイスのいくつかは、電池式であるが、他のデバイスは、スマートホーム環境の壁１５４の背後の配線(例えば、１２０Ｖの線間電圧線)への接続などによる、通常の信頼性の高い電源を有する。通常の信頼性の高い電源を有するスマートデバイスは、「スポークスマン」ノードと称される。これらのノードは、スマートホーム環境１００内のさまざまな他のデバイスとの、さらには中央サーバもしくはクラウドコンピューティングシステム１６４との双方向通信を円滑にするワイヤレスプロトコルもしくは方式を使用する能力を備える。他方、電池式のデバイスは、「低電力」ノードと称される。これらのノードは、スポークスマンノードに比べて小さい傾向を有し、Zigbee、6LoWPANなどの、必要とする電力が非常に少ないワイヤレスプロトコルを使用して通信してもよい。さらに、いくつかの低電力ノードは、電力消費を低減するために、比較的少量のメモリを有することもできる。したがって、いくつかの実施形態では、これらの低電力ノードは、流線型のメッセージおよびデータのデータフォーマット（例えば証明書）を利用する。さらに、低電力ノードは、すべてではないが、双方向通信を行うことができないものもある。これらの低電力ノードは、メッセージを送信するが、「聴く」ことはできない。そのため、スポークスマンノードなどの、スマートホーム環境１００内の他のデバイスは、これらの低電力ノードに情報を送信することができない。追加的または代替的に、これらの低電力ノードは、間欠的に低電力状態に入り、低電力デバイスを通常の動作状態よりも比較的低い電力で動作させることができる。さらに、これらの実施形態のいくつかでは、低電力デバイスは、低電力状態中はメッセージを受信しないことがある。そのような実施形態では、他のノードが、これらの低電力状態の間に、比較的低電力のノードに向けられたメッセージを保持し、低電力ノードが低電力状態を出たときにそれぞれの低電力ノードにブロードキャストしてもよい。
【００２７】
ここに説明されているように、スマートデバイスは、低電力ノードおよびスポークスマンノードとして機能し、スマートホーム環境１００内でメッシュネットワークを形成する。スマートホーム環境内の個別の低電力ノードは、何を感知しているかに関するメッセージを定期的に送出し、スマートホーム環境内の他の低電力ノードは--自メッセージを送出することに加えて--それらのメッセージを繰り返し、それによって、メッセージをスマートホーム環境１００全体にわたってノードからノード(すなわち、デバイスからデバイス)へ伝えて行く。スマートホーム環境１００内のスポークスマンノードは、低電力通信プロトコルに「ドロップダウン」してこれらのメッセージを受信し、それらのメッセージを他の通信プロトコルに対して翻訳し、翻訳されたメッセージを他のスポークスマンノードおよび/または中央サーバもしくはクラウドコンピューティングシステム１６４に送信することができる。こうして、低電力通信プロトコルを使用する低電力ノードは、メッセージをスマートホーム環境１００全体にわたって、さらにはインターネット１６２上で、中央サーバもしくはクラウドコンピューティングシステム１６４に送信することができる。いくつかの実施形態によれば、メッシュネットワークは、中央サーバもしくはクラウドコンピューティングシステム１６４が定期的に家の中のスマートデバイスのすべてからデータを受信し、データに基づき推論し、いくつかのスマートデバイスのうちの１つにコマンドを送り返して本明細書で説明されているスマートホームの目的のうちのいくつかを達成することを可能にする。
【００２８】
説明されているように、スポークスマンノード、および低電力ノードのうちのいくつかは、「聴く」ことができる。したがって、ユーザ、他のデバイス、および中央サーバまたはクラウドコンピューティングシステム１６４は、低電力ノードに制御を伝達することができる。例えば、ユーザは、携帯型電子デバイス(例えば、スマートフォン)１６６を使用して、インターネット経由でコマンドを中央サーバまたはクラウドコンピューティングシステム１６４に送信することができ、次いで、これはコマンドをスマートホーム環境１００内のスポークスマンノードに中継する。スポークスマンノードは、低電力プロトコルにドロップダウンして、スマートホーム環境全体を通してコマンドを低電力ノードに伝達するだけでなく、中央サーバまたはクラウドコンピューティングシステム１６４からコマンドを直接受信しなかった他のスポークスマンノードにも伝達する。
【００２９】
低電力ノードの一例は、スマート常夜灯１７０である。光源を収容することに加えて、スマート常夜灯１７０は、超音波または受動的IRセンサなどの人感センサ、およびフォトレジスタまたは室内の光を測定する単一ピクセルセンサなどの周辺光センサを収納する。いくつかの実施形態では、スマート常夜灯１７０は、室内が暗いことを周辺光センサが検出したときに、また室内に誰か居ることを人感センサが検出したときに光源を作動させるように構成される。他の実施形態では、スマート常夜灯１７０は、室内が暗いことを周辺光センサが検出したときに光源を作動させるように単純に構成される。さらに、いくつかの実施形態によれば、スマート常夜灯１７０は、室内に人が居ることを人感センサが検出することと同期する瞬時メッセージを含む、在室状態および室内の光量に関するメッセージを定期的に送出する低電力ワイヤレス通信チップ(例えば、ZigBeeチップ)を備える。上で述べているように、これらのメッセージはワイヤレス方式で、メッシュネットワークを使用してスマートホーム環境１００内のノードからノード(すなわち、スマートデバイスからスマートデバイス)へ、さらにはインターネット１６２を経由して中央サーバまたはクラウドコンピューティングシステム１６４に送信され得る。
【００３０】
低電力ノードの他の例は、スマートハザード検出器１０４の電池式バージョンを含む。これらのスマートハザード検出器１０４は、一定の信頼性の高い電力へのアクセスのない領域内に配置されることが多く、以下で詳しく説明されているように、煙/火炎/熱センサ、一酸化炭素/二酸化炭素センサ、人感/モーションセンサ、周辺光センサ、温度センサ、湿度センサ、および同様のものなどの、任意の数および任意の種類のセンサを備えることができる。さらに、スマートハザード検出器１０４は、上で説明されているようなメッシュネットワークなどを使用することによって、各センサにそれぞれ対応するメッセージを他のデバイスおよび中央サーバまたはクラウドコンピューティングシステム１６４に送信することができる。
【００３１】
スポークスマンノードの例として、スマートドアベル１０６、スマートサーモスタット１０２、スマート壁面スイッチ１０８、およびスマート壁面コンセント１１０が挙げられる。これらのデバイス１０２、１０６、１０８、および１１０は、信頼できる電源の近くに配置され、接続されることが多く、したがって、さまざまなプロトコルによる双方向通信が可能な１つまたは複数の通信チップなどの、電力をより消費するコンポーネントを備え得る。
【００３２】
いくつかの実施形態では、これらの低電力ノードおよびスポークスマンノード(例えば、デバイス１０２、１０４、１０６、１０７、１０８、１１０、１１２、および１７０)は、スマートホーム環境内の警報システムに対する「トリップワイヤ」として機能し得る。例えば、加害者がスマートホーム環境１００の窓、ドア、および他の入口点に配置されている警報センサによる検出を回避する場合、警報は、人の存在、動き、熱、音など、メッシュネットワーク内の低電力ノードおよびスポークスマンノードの１つまたは複数からメッセージを受信した後にトリガーされ得る。例えば、人の存在を示すメッセージを常夜灯１７０から受信すると、中央サーバもしくはクラウドコンピューティングシステム１６４または他の何らかのデバイスが、警報が検出時点において作動状態にある場合に、警報をトリガーすることが可能である。したがって、警報システムは、スマートホーム環境１００全体にわたって配置されているさまざまな低電力ノードおよびスポークスマンノードによって強化され得る。この例では、ユーザは、追加のスマート常夜灯１７０を購入して設置することによってスマートホーム環境１００のセキュリティを向上させることが可能である。
【００３３】
いくつかの実施形態では、メッシュネットワークは、人が部屋から部屋へ移るときに照明を自動的にオン、オフするために使用され得る。例えば、低電力ノードおよびスポークスマンノード(例えば、デバイス１０２、１０４、１０６、１０７、１０８、１１０、１１２、および１７０)は、スマートホーム環境を通過する人の移動を検出し、メッシュネットワークを通じて対応するメッセージを伝達する。どの部屋に人が居るかを示すメッセージを使用し、中央サーバもしくはクラウドコンピューティングシステム１６４または他の何らかのデバイスは、スマート壁面スイッチ１０８の作動および停止を行い、スマートホーム環境１００内で部屋から部屋へ人が移動するときに光を自動的に供給する。さらに、ユーザは、スマート常夜灯１７０などの、ランプおよび他の光源に電力をどのスマート壁面コンセント１１０が供給するかを示す事前構成情報を与えることができる。あるいは、壁面コンセント１１０への光源のこのようなマッピングは、自動的にも行える(例えば、スマート壁面コンセント１１０は、光源が差し込まれたときに差し込まれたことを検出し、対応するメッセージを中央サーバもしくはクラウドコンピューティングシステム１６４に送信する)。このマッピング情報をどの部屋に人が居るかを示すメッセージと併用することで、中央サーバもしくはクラウドコンピューティングシステム１６４または他の何らかのデバイスは、ランプおよび他の光源に電力を供給するスマート壁面コンセント１１０の作動および停止を行い、部屋から部屋へ人が移動するときに人の移動を追跡し、光を供給する。
【００３４】
いくつかの実施形態では、低電力ノードおよびスポークスマンノードのメッシュネットワークは、緊急時または避難訓練時に出口照明を提供するために使用され得る。いくつかの場合において、これを円滑にするために、ユーザは、スマートホーム環境１００内の出口ルートを示す事前構成情報を提供する。例えば、家屋の部屋毎に、ユーザは、ルートの利用可能性に依って、最良の出口ルートのマップを提供してもよい。状況によっては、ルートが危険物によって塞がれている可能性がある場合は、別のルートが、利用可能である場合は、照明され、示されてもよい。ユーザがこの情報を提供する代わりに、中央サーバもしくはクラウドコンピューティングシステム１６４または他の何らかのデバイスが、スマートホームの家のアップロードされたマップ、ダイアグラム、建築図面を使用して、さらにはメッシュネットワークのノードから取得された位置情報(例えば、デバイスからの位置情報が家のマップを作製するために使用される)に基づき生成されたマップを使用して、それらのルートを自動的に決定することが可能であることは理解されるであろう。動作時に、警報が作動したときに(例えば、スマートハザード検出器１０４のうちの１つまたは複数が、煙を検出し、警報を作動させたとき)、中央サーバもしくはクラウドコンピューティングシステム１６４または他の何らかのデバイスは、低電力ノードおよびスポークスマンノードから取得された人がいるかどうかの情報を使用して、どの部屋に人が居るかを決定し、人が居る部屋からの出口ルートに沿って照明(例えば、常夜灯１７０、壁面スイッチ１０８、ランプに電力を供給する壁面コンセント１１０など)をオンにし、非常口灯の照明とする。
【００３５】
図１のスマートホーム環境１００には、サービスロボット１６２がさらに備えられ、図示されており、それぞれ自律的にさまざまな家事をこなすように構成されている。いくつかの実施形態について、サービスロボット１６２は、床掃除、床洗浄などを、マサチューセッツ州ベッドフォード所在のiRobot, Inc.社によって販売されているROOMBA(商標)およびSCOOBA(商標)製品などの知られている市販のデバイスと似た仕方で、行うようにそれぞれ構成され得る。床掃除および床洗浄などの家事は、一般的には居住者が居ないときに実行されるのがより望ましいので、本発明の説明の目的に関して「不在時の」または「出かけている間の」作業とみなせる。他の実施形態については、サービスロボット１６２の１つまたは複数は、居住者のために音楽を再生する、居住者のための局所的サーモスタットとしての機能を果たす、居住者のための局所的空気監視装置/清浄器としての機能を果たす、局所的乳児監視装置としての機能を果たす、居住者のための局所的ハザード検出器としての機能を果たす、などの作業を実行するように構成され、一般的に、人間の居住者がすぐ近くに居るときにそのような作業が実行されることがより望ましい。本発明の説明の目的に関して、そのような作業は、「対人」または「人間中心」作業とみなせる。
【００３６】
居住者のための局所的サーモスタットとしての機能を果たす場合、サービスロボット１６２のうちの特定の１つは、居住者のための「パーソナルコンフォートエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間を、その居住者が家の中に居る可能性があれば必ず快適な温度に保つことである。これは、従来型の壁掛け式ルームサーモスタットとは対照的であり、静的に画成された構造空間を快適な温度に保つというより弱めた形の目的を有するものである。一実施形態によれば、局所的サーモスタットサービスロボット１６２は、家の中の特定の場所(例えば、朝食を摂り、新聞を読むためにダイニングルーム)に落ち着いている特定の居住者のすぐ近く(例えば、５フィート以内)に自動的に移動するように構成される。局所的サーモスタットサービスロボット１６２は、温度センサ、プロセッサ、およびHVACシステムとの制御通信が、直接的に、もしくはHVACシステムに結合された壁掛け式ワイヤレス通信サーモスタットを通じて維持されるように、また居住者のすぐ近くの温度が所望のレベルに維持されるように構成されたワイヤレス通信コンポーネントを備える。居住者が別の場所(例えば、テレビを見るためにリビングルームのカウチ)に移動して腰を下ろした場合、局所的サーモスタットサービスロボット１６２は、移動してカウチの隣りに駐機する動作を続け、その特定のすぐ近くの空間を快適な温度に保つ。
【００３７】
局所的サーモスタットサービスロボット１６２(および/または図１のより大きなスマートホームシステム)は、パーソナルエリア空間が快適な温度に保たれるべき居住者を識別して、特定することができる技術として、限定はしないが、RFID感知機能(例えば、RFIDブレスレット、RFIDネックレス、セルラーフォンRFIDまたはRFIDキーフォブを有する人)、合成ビジョン技術(例えば、ビデオカメラおよび顔認識プロセッサ)、オーディオ技術(例えば、声、音声パターン、振動パターン認識)、超音波感知/撮像技術、および赤外線もしくは近接場通信(NFC)技術(例えば、赤外線またはNFC対応スマートフォンを携えている人)、さらにそれに伴う感知された情報から有益な結論を引き出すルールベース推論エンジンまたは人工知能技術(例えば、家の中に居住者が１人しかいない場合に、それが、すぐ近くの空間が快適な温度に保たれるべき人であり、所望の快適な温度の選択はその居住者の特定の格納されているプロファイルに対応しなければならない)が挙げられ得る。
【００３８】
居住者のための局所的空気監視/清浄器としての機能を果たす場合、特定のサービスロボット１６２が、居住者のための「パーソナルヘルスエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間の空気の品質を健康レベルに保つことである。あるいは、またはそれと併せて、居住者の温度または心拍数を監視する(例えば、精密なリモートセンサ、人装着監視装置との近接場通信などを使用する)などの、他の健康関係機能も備えることができる。居住者のための局所的ハザード検出器としての機能を果たす場合、特定のサービスロボット１６２は、居住者のための「パーソナルセーフティエリアネットワーク」と称され得るものを円滑にすると考えることができ、目的は居住者のすぐ近くの空間内に過剰な一酸化炭素、煙、火炎などがないこと保証することである。居住者識別および追跡に関してパーソナルコンフォートエリアネットワークに対する上で説明されている方法と似た方法が、同様に、パーソナルヘルスエリアネットワークおよびパーソナルセーフティエリアネットワークの実施形態に対して適用可能である。
【００３９】
いくつかの実施形態によれば、上で述べたように、サービスロボット１６２のパーソナルコンフォートエリアネットワーク、パーソナルヘルスエリアネットワーク、パーソナルセーフティエリアネットワーク、および/または他のそのような対面機能を円滑にする機能は、それらの対面機能の性能を改善し、および/またはエネルギ節約もしくは他の資源節約方法における目標を達成するために、ルールベース推論技術もしくは人工知能技術に従って家の中の他のスマートセンサと論理的統合を果たすことでさらに高められる。したがって、パーソナルヘルスエリアネットワークに関係する一実施形態について、空気監視装置/清浄器サービスロボット１６２は、家の中で飼っているペットが居住者の現在落ち着いている場所の方へ移動中であるかどうかを検出するように構成されるものとしてよく(例えば、オンボードセンサを使用し、および/またはルールベース推論/人工知能技術と共に他のスマートホームセンサとのデータ通信によって)、移動中であれば、到来するペットの空気中に浮遊するふけの増加に備えて空気清浄速度が即座に高められる。パーソナルセーフティエリアネットワークに関係する別の実施形態について、ハザード検出器サービスロボット１６２は、居住者が現在居るダイニングルーム内の位置に近い、台所において温度および湿度が上昇中であることを他のスマートホームセンサによって助言されるものとしてよく、この助言に応答して、ハザード検出器サービスロボット１６２は、周辺煙レベルのわずかな上昇は調理活動による可能性が最も高く、本当に危険な状態によるものでないとの推論の下で、煙検出閾値などのハザード検出閾値を一時的に高くする。
【００４０】
上述の「対面」および「不在時」機能は、限定はしないが、そのような機能のうちの各専用機能を有する複数の明確に区別できるサービスロボット１６２、そのような機能のうちの２つまたはそれ以上の異なる機能の統合を有する単一のサービスロボット１６２、および/または本発明の教示の範囲から逸脱することなく、これらの任意の組み合わせ(単一のサービスロボット１６２が「不在時」および「対面」の両方の機能を有することができることを含む)によって、実現され得る。電力は、充電式電池または他の充電方法を用いて供給することができ、図１は不活動期間にサービスロボット１６２が自動的にドックに入り電池を(必要ならば)充電する例示的な邪魔にならない場所にあるドッキングステーション１６４を示している。好ましくは、それぞれのサービスロボット１６２は、図１の他のワイヤレス通信スマートホームセンサのうちの１つまたは複数との、および/または１つまたは複数の他のサービスロボット１６２との(例えば、Wi-Fi、Zigbee、Z-Wave、6LoWPANなどを使用する)データ通信を円滑にするワイヤレス通信コンポーネントを備え、図１のスマートホームデバイスのうちの１つまたは複数は、インターネット経由でリモートサーバと通信することができる。あるいは、またはそれと連携して、それぞれのサービスロボット１６２は、携帯電話通信、衛星通信、３G/４Gネットワークデータ通信、または他の直接的通信方法を用いてリモートサーバと直接通信することにより構成され得る。
【００４１】
いくつかの実施形態により、サービスロボット１６２とスマートホームシステムのホームセキュリティセンサおよび関係する機能との統合に関係するシステムおよび方法が提供される。これらの実施形態は、「不在時」機能を実行する、または家に人が居ないときに他の何らかの形でアクティブであることが望ましいサービスロボット１６２(これ以降、「不在時サービスロボット」と称する)に対して適用されるときに特に適用可能であり、有利である。これらの実施形態には、ホームセキュリティシステム、侵入検出システム、および/または在室感知環境制御システム(例えば、家に人が居ないときに低エネルギ使用状態に入る在室感知自動セットバックサーモスタット)が、不在時サービスロボットにより誤ってトリガーされないようにする方法およびシステムが含まれる。
【００４２】
ある実施形態により、ホームオートメーションおよびセキュリティシステムの１つまたは複数のネットワーク接続要素とのデータ通信を行う自動化システム(例えば、クラウドベースのサーバまたは他の中央サーバ、これ以降「中央サーバ」と称する)を用いて監視サービスによって離れた場所から監視されるホームオートメーションおよびセキュリティシステム(例えば、図１に示されているような)が実現される。不在時サービスロボットは、中央サーバとの動作可能なデータ通信を行うように構成され、またその不在時サービス活動を開始する許可が中央サーバから(例えば、中央サーバからの「away-service-OK」メッセージによって)出されない限り、非不在時サービス状態のままとなる(例えば、ドッキングステーションにおいて休眠状態にある)ように構成される。システムによって行われる不在時状態決定は、(i)人感センサデータに基づき局所的敷地上スマートデバイスによって排他的に、(ii)受信された人感センサデータに基づき、および/またはユーザのスマートフォンもしくは自動車からのGPS座標などの受信された近接関係情報に基づき中央サーバによって排他的に、または(iii)(i)および(ii)の組み合わせで行われ、次いで、中央サーバによる不在時サービスロボットへの不在時サービス許可の付与をトリガーすることができる。不在時サービスロボットが継続的に家庭内位置座標を検出し、中央サーバに送信することができる、不在時サービスロボットの活動の過程において、中央サーバは、人感デバイスからの信号をフィルタリングすることで、不在時サービスロボット活動と予想外の侵入活動とを容易に区別することができ、それによって、家のセキュリティを確保しながら誤った侵入警報状態を回避することができる。あるいは、またはそれと連携して、中央サーバは、フィルタリングデータ(不在時サービスロボットによってトリガーされる予想された人感プロファイルなど)をスマートホームの人感ノードまたは関連する処理ノードに提供することができ、フィルタリングはローカルレベルで実行される。セキュリティはいくぶん低下するが、中央サーバが不在時サービスロボット活動の持続時間に対して人感機器を一時的に無効化することも本明細書の教示の範囲内に入る。
【００４３】
別の実施形態により、上の例の中央サーバの機能と類似する機能は、専用サーバコンピュータなどのオンサイトコンピューティングデバイス、「マスター」ホームオートメーションコンソールもしくはパネルによって、または図１のスマートホームデバイスのうちの１つまたは複数の付随機能として実行され得る。そのような実施形態では、不在時サービスロボットへの「away-service-OK」許可および感知された侵入検出信号に対する誤警報回避フィルタリングサービスもしくはフィルタ情報を与えるためにリモートサービスプロバイダへの依存性はない。
【００４４】
他の実施形態によれば、単一の全体的な事象統合化機能を必要とすることなく誤ホームセキュリティ警報および誤在室感知環境制御を回避しながら不在時サービスロボット機能を実装するための方法およびシステムが提供される。本開示の簡素化のために、不在時サービスロボット活動の動き、騒音、振動、または他の外乱によってトリガーされるホームセキュリティシステムおよび/または在室感知環境制御は、「活動感知システム」と単純に参照され、そのようにトリガーされたときに、誤トリガーを表す「外乱検出」結果を生じる(例えば、セキュリティサービスへの警報メッセージ、または家をより快適な「在室」設定点温度まで暖房または冷房させる自動化セットバックサーモスタットに対する「到着」決定)。一実施形態によれば、不在時サービスロボットは、不在時サービス活動の過程全体にわたって標準的な超音波を放射するように構成され、活動感知システムは、その標準的な超音波を検出するように構成され、活動感知システムは、その標準的な超音波が検出される限り外乱検出結果が生じないようにさらに構成される。他の実施形態について、不在時サービスロボットは、不在時サービス活動の過程全体にわたって標準的な通知信号を放射するように構成され、活動感知システムは、その標準的な通知信号を検出するように構成され、活動感知システムは、その標準的な通知信号が検出される限り外乱検出結果が生じないようにさらに構成され、標準的な通知信号は、光通知信号、音響通知信号、赤外線通知信号、超低周波通知信号、ワイヤレス送信データ通知信号(例えば、IPブロードキャスト、マルチキャスト、もしくはユニキャスト通知信号、またはTCP/IP双方向通信システムで送信される通知メッセージ)のうちの１つまたは複数を含む。
【００４５】
いくつかの実施形態によれば、不在時サービスロボットによって活動感知システムに送信される通知信号は、通知が延在的強盗によって学習され、複製されないように認証され暗号化される。さまざまな知られている暗号化/認証スキームが、限定はしないがサードパーティデータセキュリティサービスまたは証明機関を伴う方法を含むそのようなデータセキュリティを保証するために使用され得る。いくつかの実施形態について、許可要求応答モデルを使用することができ、そこでは、特定の不在時サービスロボットが、不在時サービス作業を実行する準備が整ったときに家の中のそれぞれの活動感知システムに許可を要求し、それぞれの活動感知システムから(または活動感知システムのすべてに対する「スポークスマン」としての機能を果たす単一の活動感知システムから)「yes」または「permission granted」メッセージを受信するまでそのような活動を開始しない。中央事象統合機能を必要としない説明されている実施形態の一利点は、一方の(オプションとして)ホームセキュリティ/環境制御機器のサプライヤーと他方の不在時サービスロボットのサプライヤーとの間の対等の関係以上のものがあり得ることであり、各サプライヤーが合意すべき説明されている標準的な一方向通知プロトコルまたは説明されている標準的双方向要求/許可プロトコルがあるということだけが必要である。
【００４６】
いくつかの実施形態によれば、活動感知システムは、それぞれの不在時サービスロボットの不在時サービス活動に本質的に関連付けられている音、振動、RF放射、または他の検出可能な環境信号もしくは「シグネチャ」を検出するように構成され、その特定の検出可能な信号または環境の「シグネチャ」が検出される限り外乱検出結果が生じないようにさらに構成される。例えば、特定の種類の真空掃除不在時サービスロボットは、特定の音またはRFシグネチャを発することができる。一実施形態について、複数の知られている不在時サービスロボットのそれぞれに対する不在時サービス環境シグネチャは、経験的に収集されたデータ、活動感知システムによって供給され、およびリモート更新サーバによって定期的に更新されている環境シグネチャに基づき活動感知システムのメモリ内に格納される。別の実施形態について、活動感知システムは、それらが取り付けられている特定の家に対する「学習モード」に入ることができ、学習セッションにおいてその家に対する不在時サービスロボットの特定の環境シグネチャを「聴き」、「学習し」、その後、それらの環境シグネチャが聴かれる間隔について外乱検出結果を抑制する。さらに、後述するように、音波または視覚による感知を使用して、音波または視覚刺激を検出するスマートデバイスの所定の範囲（例えば、音波または視覚検出の範囲）内にユーザがいることを検証することができる。
【００４７】
活動感知システムがホームセキュリティシステムではなく在室感知環境機器と関連付けられているときに特に有用である、ある実施形態について、活動感知システムは、検出された環境シグネチャと検出された在室活動との間の時間の経過による相関を自動的に求めることによって不在時サービスロボットに対する環境シグネチャを自動的に学習するように構成される。例えば、一実施形態について、Nest Learning Thermostatなどのインテリジェント型自動化非在室トリガーセットバックサーモスタットは、音響およびRF活動を常時監視し、さらには赤外線ベースの在室検出を実行するように構成され得る。不在時サービスロボットの環境シグネチャが事象から事象に移る間に比較的一定しているという事実を特に鑑みて、また不在時サービス事象が、(a)それ自体、不在時サービスロボットそれ自体によって測定されるような何らかの種類の非在室状態によってトリガーされるか、または(b)規定時刻に生じるという事実を鑑みて、事象それ自体が明らかになり、環境シグネチャが容易に学習され得るパターンが収集されたデータ中にある。概して、不在時サービスロボットの環境シグネチャがユーザによるインタラクティブな操作を必要とすることなく自動的に学習されるこの自動学習実施形態について、一定数の誤トリガーが学習プロセスの過程において許容可能であることがより好ましい。したがって、この自動学習実施形態は、誤った在室決定が少なければ不要な暖房または冷房の発生が少なくなり得るが、それ以外は重大な結果をもたらすことはなく、誤ったホームセキュリティ警報はより重大な結果を引き起こし得るという理由により、ホームセキュリティシステムよりはむしろ在室感知環境制御機器(自動化セットバックサーモスタットなど)において適用するのにより好ましい。
【００４８】
いくつかの実施形態によれば、中央サーバまたはクラウドコンピューティングシステム１６４に用意されたルールベースの推論エンジンまたは人工知能と組み合わせたスマートホーム環境のメッシュネットワーク内に配置されたスマートデバイスのセンサを含む技術は、家の個別の居住者に対して個人的な「スマートアラームクロック」を提供するために使用される。例えば、ユーザ居住者は、自分のモバイルデバイス１６６を介して中央サーバまたはクラウドコンピューティングシステム１６４と通信し、スマートアラームクロックに対するインターフェイスにアクセスすることができる。そこで、居住者は、自分の「スマートアラームクロック」をオンにし、翌日および/または追加の日に対する起床時間を入力することができる。いくつかの実施形態では、居住者は、それぞれの曜日について特定の起床時間を設定するオプション、さらには「繰り返す」入力された起床時間のうちのいくつか、またはすべてを設定するオプションを有し得る。人工知能は、これらのアラームが停まったときにそれに対する居住者の反応を考慮し、時間を追ってユーザの好ましい睡眠パターンに関して推論するために使用される。
【００４９】
いくつかの実施形態によれば、居住者が眠りに落ちたときにたまたま居住者に最も近い位置にあるスマートホーム環境１００内のスマートデバイスは、居住者が動くのを止めたときに関するメッセージを送信するデバイスであり、そこから中央サーバまたはクラウドコンピューティングシステム１６４が居住者がいつどこで眠るのを好むかに関して推論する。この最も近いスマートデバイスは、居住者を目覚めさせるアラームを鳴らすデバイスでもある。この方法で、「スマートアラームクロック」は、スマートデバイス内に配置されているセンサから取得されたデータに基づき決定される、「一意的シグネチャ」に基づき個別の居住者を追跡することによって、家全体にわたって居住者に追随する。例えば、センサは、超音波センサ、受動的IRセンサ、および同様のものを含む。一意的シグネチャは、歩き方、移動のパターン、声、身長、サイズなどの組み合わせに基づく。顔認識も使用できることは理解されるであろう。
【００５０】
一実施形態により、「スマートアラームクロック」に関連付けられている起床時間は、HVACを効率的に制御するためにスマートサーモスタット１０２によって使用され、これにより、家を居住者の所望の「睡眠」および「覚醒」温度設定に合わせて予熱または冷房する。好ましい温度設定は、居住者が眠りに入る前にサーモスタットをどの温度に設定するか、また居住者が目覚めた後にサーモスタットをどの温度に設定するかを観察するなど、時間をかけて学習され得る。
【００５１】
一実施形態により、デバイスは、隣接するナイトスタンドなど、居住者のベッドの近くに位置決めされ、騒音センサ、モーションセンサ(例えば、超音波、IR、および光)などを使用して居住者が眠るときのデータを収集する。データは、室内の他のスマートデバイスによっても同様に取得され得る。そのようなデータは、居住者の呼吸パターン、心拍数、動きなどを含み得る。居住者が実際に目覚めたときを示すデータと組み合わせてこのデータに基づき推論がなされる。例えば--定期的に--居住者の心拍数、呼吸、および移動がすべて、毎朝居住者が目覚める２０から３０分前に５%から１０%に増える場合に、居住者がいつ目覚めるかに関して予測が行われ得る。家の中の他のデバイスは、これらの予測を使用して、居住者が目覚める前に家を居住者の所望の設定に予熱または冷房するためにスマートサーモスタット１０２を調整することなど、他のスマートホームの目的を達成することができる。さらに、これらの予測を使用して、居住者に対して「スマートアラームクロック」を設定する、照明をオンにするなどの操作を行うことができる。
【００５２】
いくつかの実施形態によれば、中央サーバまたはクラウドコンピューティングシステム１６４に用意されたルールベースの推論エンジンまたは人工知能と組み合わせてスマートホーム環境中に配置されるスマートデバイスのセンサを含む技術は、アルツハイマー病の進行を検出または監視するために使用される。例えば、居住者の一意的シグネチャは、スマートホーム環境１００全体にわたる個別の居住者の移動を追跡するために使用される。このデータは、アルツハイマーを示すパターンを識別するために集約され、分析され得る。しばしば、アルツハイマーを患っている個人は、自分の家の中をあちこち移動する明確に区別できるパターンを有する。例えば、人は、台所まで歩いて行き、そこにしばらく立ち止まり、次いで、リビングルームに行き、そこにしばらく立ち止まり、次いで、台所に引き返す。このパターンは約３０分を要し、その後、人はこのパターンを繰り返す。いくつかの実施形態によれば、リモートサーバまたはクラウドコンピューティングアーキテクチャ１６４は、スマートホーム環境のメッシュネットワークによって収集された人の移動データを分析してそのようなパターンを識別する。
【００５３】
図２は、図１のスマートホーム環境１００などの複数のスマートホーム環境と統合できる拡張可能なデバイスおよびサービスのプラットフォーム２００のネットワークレベルを示している。拡張可能なデバイスおよびサービスのプラットフォーム２００は、リモートサーバまたはクラウドコンピューティングアーキテクチャ１６４を備える。スマートデバイスの各々は、リモートサーバまたはクラウドコンピューティングアーキテクチャ１６４と通信することができる。例えば、インターネット１６２への接続は、直接的に(例えば、ワイヤレスキャリアへの３G/４G接続を使用して)、ワイヤレスメッシュネットワーク(単純なワイヤレスルーターから、例えば、インテリジェント型の専用の家全体の制御ノードに至るスキームとすることができる)を通じて、またはこれらの組み合わせを通じて確立され得る。スマートネットワークは、ハブ２１２を使用してインターネット１６２に結合することができる。
【００５４】
本明細書に提示されているいくつかの例において、デバイスおよびサービスのプラットフォーム２００は、図１のスマートホーム環境１００のスマートデバイスと通信し、そのスマートデバイスからデータを収集するが、デバイスおよびサービスのプラットフォーム２００は、世界中の複数のスマートホーム環境と通信し、データを収集し得ることは理解されるであろう。例えば、中央サーバまたはクラウドコンピューティングシステム１６４は、１つまたは複数のスマートホーム環境のデバイスからホームデータ２０２を収集することができ、デバイスは、定期的にホームデータを送信するか、または特定の場合(例えば、デバイスがホームデータ２０２を問い合わせるとき)にホームデータを送信することができる。したがって、デバイスおよびサービスのプラットフォーム２００は、定期的に、世界中の家庭からデータを収集し得る。説明されているように、収集されたホームデータ２０２は、例えば、消費電力データ、在室データ、HVAC設定および使用度データ、一酸化炭素レベルデータ、二酸化炭素レベルデータ、揮発性有機化合物レベルデータ、睡眠スケジュールデータ、調理スケジュールデータ、内部および外部温度湿度データ、テレビ視聴者数データ、内部および外部騒音レベルデータなどを含む。
【００５５】
中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、１つまたは複数のサービス２０４をさらに提供することができる。サービス２０４は、例えば、ソフトウェア更新、カスタマーサポート、センサデータ収集/ロギング、天気予報、アカウント情報、リモートアクセス、リモートまたは分散制御、または使用提案(例えば、性能を改善する、光熱費を低減するなどのために収集されたホームデータ２０２に基づく)を含み得る。サービス２０４に関連付けられているデータは、中央サーバまたはクラウドコンピューティングシステム１６４側に格納され、中央サーバまたはコンピューティングシステム１６４は、適切なタイミングで(例えば、規則正しい間隔で、ユーザから要求を受信した後などに)データを取り出し、送信することができる。
【００５６】
図２に例示されているように、拡張可能なデバイスおよびサービスのプラットフォーム２００の一実施形態は、制限することなく、単一のサーバに集中させるか、またはいくつかの異なるコンピューティングエンティティ間に分散させることができる、処理エンジン２０６を備える。処理エンジン２０６は、スマートホーム環境のデバイスからデータを(例えば、インターネットまたはハブ型ネットワークを介して)受信し、データにインデックスを付け、データを分析し、および/または分析に基づきもしくは分析の一部として統計量を生成するように構成されたエンジンを含み得る。分析されたデータは、導出されたホームデータ２０８として格納され得る。
【００５７】
分析の結果または統計量は、これ以降、結果を導き出すために使用されるホームデータを提供したデバイス、他のデバイス、デバイスのユーザにウェブページを提供するサーバ、または他の非デバイスエンティティに送信して送り返すことができる。例えば、使用統計量、他のデバイスの使用に関する使用統計量、使用パターン、および/またはセンサ読み取り値を要約した統計量が、処理エンジン２０６によって生成され、送信され得る。これらの結果または統計量は、インターネット１６２を介して提供され得る。この方式で、処理エンジン２０６は、ホームデータ２０２からさまざまな有用な情報を導き出すように構成され、プログラムされ得る。単一のサーバに、１つまたは複数のエンジンを備えることができる。
【００５８】
導き出されたデータは、家、近所、または地域毎のデバイスの例示的なプログラムされた制御(例えば、電力事業のための需要応答プログラム)から、家毎に支援することができる推論抽象化の生成(例えば、家の所有者がバケーションに出かけたため、防犯用検出機器を最高感度に設定できるという推論を下せる)、政府または公益目的に使用され得る統計量および関連する推論抽象化の生成に至る、さまざまな有用な目的のためにさまざまな異なる粒度で高度に有益であり得る。例えば、処理エンジン２０６は、デバイスの集団におけるデバイス使用度に関する統計量を生成し、その統計量をデバイスユーザー、サービスプロバイダ、または他のエンティティ(例えば、統計量に対する金銭的補償を要求したか、または提供している可能性のある)に送信することができる。
【００５９】
いくつかの実施形態によれば、ホームデータ２０２、導出されたホームデータ２０８、および/または別のデータが、「自動化近隣セーフティネットワーク(automated neighborhood safety network)」を作成するために使用され得る。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４が、特定の家庭が押し入られたこと、火事、または他の何らかの種類の非常事態を示すデータを受信した場合、警報が「近所」の他のスマートホームに送信される。いくつかの場合において、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、非常事態が発生している家のある半径内にあるスマートホームを自動的に識別し、警報を識別された家に送信する。このような場合、「近所」の他の家は、セーフティネットワークの一部となるようにサインアップまたは登録しなくてよいが、その代わりに、非常事態の位置への近接度に基づき非常事態の通知を受ける。これは、堅牢な発展型の近隣安全監視ネットワークを構成し、したがって、ある人の家が押し入られようとしている場合、警報が近くの家に、例えば、これらの家に配置されているスマートデバイスを介した音声告知などによって送信され得る。それに加えて、またはその代わりに、近隣のハザード検出器が煙を検出した場合、近隣住宅は灌漑システムを作動させて火災が広がる可能性を低減することができる。このセーフティネットワークは、選択サービスであってよく、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４が警告の送り先となる家を選択することに加えて、またはその代わりに、個人がサブスクライブしてそのようなネットワークに参加することができ、また個人が、どの家から警告を受けたいかを指定することができることは理解されるであろう。これは、例えば、異なる市に住んでいる家族の家を含むことができ、したがって、個人は、他の場所に居る自分の愛する人たちが非常事態にあるときに警告を受信することができる。
【００６０】
いくつかの実施形態によれば、スマートデバイスの音、振動、および/または動き感知コンポーネントが、流水によって引き起こされる音、振動、および/または動きを検出するために使用される。検出された音、振動、および/または動きに基づき、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、家庭内の水使用量に関して推論し、関係するサービスを提供する。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、水がどのような音を発生しているか、またいつ家庭内を流れているかを認識するプログラム/アルゴリズムを実行することができる。一実施形態によれば、家庭のさまざまな水資源をマッピングするために、流水を検出した後、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、水が現在流れているかどうか、または水が家庭内で最近流されたかどうか、もしそうであれば、どの部屋、どの水消費アプライアンス(例えば、シンク、シャワー、トイレなど)が水源であったかを尋ねるメッセージを居住者のモバイルデバイスに送信する。これは、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４が家の中のそれぞれの水源の「シグネチャ」または「指紋」を決定することを可能にする。これは、ときには、本明細書において「水使用量音声指紋採取(audio fingerprinting water usage)」と称されることがある。
【００６１】
例示的な一例において、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、主浴室内のトイレに対するシグネチャを作成し、そのトイレで水が流された場合に必ず、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、そのときの水使用量がそのトイレに関連していることを知る。したがって、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、そのトイレ、さらには家の中のそれぞれの水消費用途の水使用量を追跡することができる。この情報と、水道料金の請求書またはスマート水道メーターとの相関関係を求めて、ユーザに、水使用量の内訳を提示することができる。
【００６２】
いくつかの実施形態によれば、スマートデバイスの音、振動、および/または動き感知コンポーネントは、ネズミおよび他の齧歯類、さらにはシロアリ、ゴキブリ、および他の昆虫(「害虫」と総称される)によって引き起こされる音、振動、および/または動きを検出するために使用される。検出された音、振動、および/または動きに基づき、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、家庭内の害虫検出に関して推論し、関係するサービスを提供する。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、特定の害虫がどのような音をたてるか、どのように移動するか、および/または発生する振動を、個別に、および/またはまとめて認識するプログラム/アルゴリズムを実行することができる。一実施形態によれば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、特定の種類の害虫の「シグネチャ」を決定することができる。
【００６３】
例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４が、害虫に関連付けられ得る音を検出した場合、これは、そのような音を居住者に通知し、害虫防除会社を雇うよう提案する。害虫が実際に存在していると確認された場合、居住者は、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４に、その検出が正しいことを示す確認を、名前、種類、説明、場所、数などの識別された害虫に関する詳細と共に入力する。これは、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４がより適切に検出できるように自動「チューニング」し、特定の種類の害虫に対する「シグネチャ」または「指紋」を作成することを可能にする。例えば、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、このチューニング、さらにはシグネチャおよび指紋を使用して、同じ害虫の問題を抱えていると思われる近所の家庭など、他の家庭の害虫を検出することができる。さらに、例えば、「近所」の２つまたはそれ以上の家庭が同じまたは類似の種類の害虫の問題を抱えている場合、中央サーバまたはクラウドコンピューティングアーキテクチャ１６４は、近隣の家庭もそのような問題を有し得るか、またはそのような問題を有することの影響を受けやすいという推論を行って、警告メッセージをそれらの家庭に送信し、早期検出および予防の促進を手助けすることができる。
【００６４】
いくつかの実施形態では、革新と研究とを促進し、ユーザが利用できる製品およびサービスを増やすために、デバイスおよびサービスのプラットフォーム２００において、一連のアプリケーションプログラミングインターフェース(API)２１０を、慈善事業体２２２、政府機関２２４(例えば、食品医薬品局または環境保護庁)、学術機関２２６(例えば、大学の研究者)、企業２２８(例えば、関係する機器へのデバイス保証またはサービスを提供する、ホームデータに基づき広告をターゲットとする)、ガス・電力会社２３０、および別の他のサードパーティなどのサードパーティに公開する。ＡＰＩ２１０はサードパーティシステムに結合され、サードパーティシステムに、サービス２０４、処理エンジン２０６、ホームデータ２０２、および導出されたホームデータ２０８を含む、中央サーバまたはクラウドコンピューティングシステム１６４と通信することを許してもよい。例えば、ＡＰＩ２１０は、サードパーティによって実行されるアプリケーションに、中央サーバまたはクラウドコンピューティングシステム１６４によって実行される特定のデータ処理タスクを開始し、さらにはホームデータ２０２および導出されたホームデータ２０８への動的更新を受信することを可能にしてもよい。
【００６５】
例えば、サードパーティは、サービスおよび情報をユーザに提供するために中央サーバまたはクラウドコンピューティングシステム１６４と統合する、ウェブもしくはモバイルアプリなどのプログラムおよび/またはアプリケーションを開発することができる。このようなプログラムおよびアプリケーションは、例えば、エネルギ消費量を減らす、機先を制して欠陥機器を整備する、高いサービス需要に応じる準備をする、過去のサービス実績などを追跡する、または現在知られているか、もしくは今後開発されるさまざまな有益な機能もしくはタスクを実行するユーザを助けるように設計され得る。
【００６６】
いくつかの実施形態によれば、サードパーティアプリケーションは、ホームデータ２０２および導出されたホームデータ２０８から推論を行い、そのような推論は、いつ居住者が家に居るか、いつ眠るか、いつ調理するか、いつ私室でテレビを視聴するか、いつシャワーを浴びるかということを含み得る。これらの質問に対する回答は、関心のある情報、製品、およびサービスを提供することによって、さらにはターゲットとされる広告を提供することによってサードパーティが消費者に利益をもたらすのを助けることができる。
【００６７】
一例では、輸送会社は、人々が家に居る時間に関して推論を行うアプリケーションを作成する。このアプリケーションは、それらの推論を使用して、人々が家に居る可能性が最も高い時間に配達を行うようにスケジュールする。アプリケーションは、それらのスケジュールされた時間の前後に配達ルートを構築することもできる。これにより、輸送会社が荷物の配達を何回も試みなければならない状況を減らし、消費者が輸送会社から自分の荷物を受け取らなければならない回数を減らす。
【００６８】
図３は、処理エンジン２０６、さらには図１のスマートホーム環境１００のデバイスなどのデバイスを特に参照している、図２の拡張可能なデバイスおよびサービスのプラットフォーム２００の機能図３００である。スマートホーム環境内に配設されているデバイスは、無数のさまざまな異なる個別の能力および制限を有し得るが、すべて、それぞれがデータコンシューマ３０２(DC)、データソース３０４(DS)、サービスコンシューマ３０６(SC)、およびサービスソース３０８(SS)であるという点で共通の特性を共有しているものと考えられ得る。有利には、デバイスがローカルの直接的な目的を達成するために必要な本質的制御情報を提供することに加えて、拡張可能なデバイスおよびサービスのプラットフォーム２００は、これらのデバイスから流れ出る大量のデータを利用するように構成することもできる。その直接的機能に関してデバイスそれ自体の実際の動作を強化または最適化することに加えて、拡張可能なデバイスおよびサービスのプラットフォーム２００は、さまざまな有用な目的を達成するためにさまざまな自動化された、拡張可能な、柔軟性の高い、および/またはスケーラブルな方法でそのデータの「目的を設定し直す」ことを対象とすることができる。これらの目的は、例えば、使用度パターン、デバイス効率、および/またはユーザ入力(例えば、特定の機能を要求する)に基づき事前に定義されるか、または適応的に識別され得る。
【００６９】
例えば、図３は、多数のパラダイム３１０を含むものとして処理エンジン２０６を示している。処理エンジン２０６は、一次または二次デバイス機能を監視し、管理する管理サービスパラダイム３１０ａを備えることができる。デバイス機能は、ユーザ入力を与えられたデバイスの適切な動作を保証すること、侵入者が住居内に居るか、または住居内に入ろうとしているのを推定する(例えば、さらにそのような場合に応答する)こと、デバイスに結合されている機器の故障(例えば、電球が切れている)を検出すること、エネルギ需要反応事象を実装するか、または他の何らかの形で応答すること、または現在の、もしくは予測された将来の事象もしくは特性をユーザに警告することを含み得る。処理エンジン２０６は、デバイス使用度に基づきユーザの注目する特性(例えば、デモグラフィック情報)、要望、および/または製品を推定する広告/通信パラダイム３１０ｂをさらに備えることができる。次いで、サービス、販促、製品、またはアップグレードがユーザに対してオファーされるか、または自動的に提供され得る。処理エンジン２０６は、ソーシャルネットワークからの情報を使用するか、または情報をソーシャルネットワークに提供し(例えば、デバイス使用度に基づき)、および/またはユーザおよび/またはデバイスとソーシャルネットワークプラットフォームと相互のやり取りに関連付けられているデータを処理するソーシャルパラダイム３１０ｃをさらに備えることができる。例えば、ソーシャルネットワーク上の信頼できる連絡先に報告されるようなユーザのステータスは、照明検出、セキュリティシステム停止またはデバイス使用度検出器に基づき家にいつ居るかを示すように更新することが可能である。別の例として、ユーザは、デバイス使用度統計量を他のユーザと共有することができるものとしてよい。さらに別の例では、ユーザは、請求される電気料金を減らせるHVAC設定を共有することができ、他のユーザは、HVAC設定を自分のスマートサーモスタット１０２にダウンロードして、請求される自分の電気料金を減らすことができる。
【００７０】
処理エンジン２０６は、ユーザに異議、競合、規則、コンプライアンス規定、および/または報酬を通知する、および/または動作データを使用して異議を乗り切ったかどうか、規則または規定を順守しているかどうか、および/または報酬が獲得されたかどうかを判定する異議/規則/コンプライアンス/報酬パラダイム３１０ｄを備えることができる。異議、ルール、または規定は、省エネ、安全な生活(例えば、有毒物質または発癌物質への露出を低減する)、お金の節約および/または機器の延命、健康改善、避難訓練の実施などの取り組みに関係し得る。例えば、１つの異議は、１週間に１度サーモスタットを弱めることに参加することを伴い得る。この異議の履行に成功したものは、クーポン、仮想通貨、ステータスなどによって報われる。コンプライアンスに関しては、一例は、賃貸不動産所有者が賃借人は特定の所有者の部屋にアクセスすることを許されないという規則を作ることを伴う。人感センサを有する部屋の中のデバイスが、部屋がアクセスされたときに更新を所有者に送信することが可能である。
【００７１】
処理エンジン２０６は、外来ソースからの外来情報３１６を統合するか、または他の何らかの形で利用して、１つまたは複数の処理パラダイムの機能を改善することができる。外来情報３１６は、デバイスから受信されたデータを解釈する、デバイスの近くの環境(例えば、デバイスが封じ込められている構造物の外)の特性を判定する、ユーザから利用可能なサービスまたは製品を決定する、ソーシャルネットワークまたはソーシャルネットワーク情報を識別する、デバイスなどの近くのエンティティ(例えば、救急隊、警察、または病院などの公共サービスエンティティ)の連絡先情報を決定する、家または近所に関連付けられている統計的または環境的条件、傾向、もしくは他の情報を識別する、などのために使用され得る。
【００７２】
並外れて広範な、さまざまな利点が、通常のものから深いもの至る、説明されている拡張可能なデバイスおよびサービスのプラットフォーム２００によってもたらされ、またその範囲内に収まり得る。したがって、「通常の」一例において、スマートホーム環境１００のそれぞれの寝室は、スマート壁面スイッチ１０８、スマート壁面コンセント１１０、および/またはスマートハザード検出器１０４を備えることができ、これらはすべてまたは一部が、人感センサを備え、人感センサは、居住者が眠っているか、または目覚めているかを推論する(例えば、モーション検出、顔認識、可聴音パターンなどを用いて)こともできる。火災事象が感知された場合、離れたところにあるセキュリティ/監視サービスまたは消防署は、それぞれの寝室に何人の居住者がいるか、それらの居住者がまだ眠っている(もしくは動けない)か、または寝室から適切に退去しているかどうかの知らせを受ける。これは、もちろん、説明されている拡張可能なデバイスおよびサービスのプラットフォームが備える非常に有利な機能であるが、利用可能にすることができるより大きな「インテリジェンス」の潜在的可能性を真に示すことができる実質的により「深い」例があり得る。たぶんより「深い」例を用いることで、火災安全のために使用されている同じ寝室占有データについて、近隣の子供の成長および教育の社会的パラダイムの文脈において処理エンジン２０６によって「目的を設定し直す」こともできる。したがって、例えば、「通常の」例で説明されている同じ寝室占有およびモーションデータを収集し、特定の郵便番号の地域内の学童の睡眠パターンが識別され追跡され得る処理(適切に匿名化されて)に利用可能にできる。学童の睡眠パターンの局部的変動が識別され、例えば、地域の学校の異なる栄養プログラムに対して相関され得る。
【００７３】
ＩＩ．スマートデバイス
導入として、図４は、住宅環境内における他の同様のデバイスと通信し得るデバイス４１０（たとえばサーモスタットおよび／またはハザード検出器）の例を図示する。ある実施の形態では、デバイス４１０は、１つ以上のセンサ４１２、ユーザインターフェイスコンポーネント４１４、電源４１６（たとえばライン電力接続および／またはバッテリを含む）、ネットワークインターフェイス４１８、プロセッサ４２０などを含み得る。特定のセンサ４１２、ユーザインターフェイスコンポーネント４１４および電源構成は、各デバイス４１０で同じまたは類似してもよい。しかしながら、いくつかの実施の形態では、各デバイス４１０は、デバイスタイプまたはモデルに基いて、特定のセンサ４１２、ユーザインターフェイスコンポーネント４１４および電源構成などを含んでもよいことが注目されるべきである。
【００７４】
センサ４１２は、ある実施の形態では、加速度、温度、湿度、水、供給電力、近接度、外部の動き、デバイスの動き、音声信号、超音波信号、光信号、炎、煙、一酸化炭素、全地球測位システム（ＧＰＳ）信号、無線周波数（ＲＦ）、他の電磁信号または電磁場等のようなさまざまな特性を検出してもよい。したがって、センサ４１２は、温度センサ、湿度センサ、ハザード関連センサまたは他の環境的センサ、加速度計、マイクロホン、光学センサを、カメラ（たとえば、電荷結合素子もしくはビデオカメラ）、能動的もしくは受動的輻射センサ、ＧＰＳレシーバまたは無線周波数識別検出器および／または他の好適なセンサまで、およびそれらを含んで、含んでもよい。図４は単一のセンサを伴う実施の形態を示すが、多くの実施の形態は複数のセンサを含んでもよい。ある例では、デバイス４１０は１つ以上の一次センサおよび１つ以上の二次センサを含んでもよい。ここで、一次センサは、デバイスのコア動作（たとえばサーモスタットにおいて温度を検知することまたは煙検出器において煙を検知することなど）に対して中心のデータを検知してもよく、一方、二次センサは、他のタイプのデータ（たとえば動き、光または音）を検知してもよく、それをエネルギ効率目的、セキュリティ目的、安全性目的、および/またはスマート動作目的のために用いることができる。
【００７５】
デバイス４１０における１つ以上のユーザインターフェイスコンポーネント４１４はユーザから入力を受取ってもよく、および／またはユーザに対して情報を提示してもよい。受取られた入力を用いて１つまたは複数の設定を判断してもよい。ある実施の形態では、ユーザインターフェイスコンポーネントは、ユーザの動きに応答する機械的コンポーネントまたは仮想コンポーネントを含んでもよい。たとえば、ユーザは、摺動するコンポーネントを（たとえば垂直トラックまたは水平トラックに沿って）機械的に移動させるか、もしくは回転可能なリングを（円形のトラックに沿って）回転させることができ、またはデバイス４１０のタッチパッドを横切って、もしくはその上に物体（たとえば指）を移動させてもよい。そのような動きは設定の調整に対応してもよく、それは、ユーザインターフェイスコンポーネント４１４の絶対的な位置またはユーザインターフェイスコンポーネント４１４の変位に基づいて判断することができる（たとえば回転可能リングコンポーネントの１０度の回転ごとに１°Ｆだけ設定点温度を調整することなど）。物理的な可動ユーザインターフェイスコンポーネントおよび仮想可動ユーザインターフェイスコンポーネントは、ユーザが、明らかな連続体の一部に沿って設定することを可能にすることができる。したがって、ユーザは、（たとえばアップボタンおよびダウンボタンが用いられる場合にそうであるように）２つの別個のオプションの間で選択を行なうことに制限されなくてもよく、可能な設定値の範囲に沿って設定を迅速かつ直感的に規定することができる。たとえば、ユーザインターフェイスコンポーネントのある移動のある大きさはある設定調整のある大きさと関連づけられてもよく、ユーザは設定を大きな移動で劇的に変えたり、設定を小さな移動で微調整してもよい。
【００７６】
ユーザインターフェイスコンポーネント４１４は、さらに、１つ以上のボタン（たとえばアップボタンおよびダウンボタン）、キーパッド、数値パッド、スイッチ、マイクロホン、および／またはカメラ（例えば、身振りを検出するために）を含んでもよい。ある実施の形態では、ユーザインターフェイスコンポーネント４１４はクリックおよび回転環状リングコンポーネントを含んでもよく、ユーザは、（たとえば設定を調整するよう）リングを回転することによって、および／または（たとえば調整された設定を選択するかもしくはオプションを選択するよう）リングを内方向にクリックすることによって、そのコンポーネントと対話することを可能にしてもよい。別の実施の形態では、ユーザインターフェイスコンポーネント４１４は、カメラを含んでもよく、（たとえばデバイスの出力または警報状態が変更されることになる旨を示すべく）身振り（ジェスチャ）を検出してもよい。いくつかの例では、デバイス４１０は１つの一次入力コンポーネントを有してもよく、それを用いて複数のタイプの設定を設定してもよい。ユーザインターフェイスコンポーネント４１４は、さらに、情報を、ユーザに対して、たとえば視覚ディスプレイ（たとえば薄膜トランジスタディスプレイまたは有機発光ダイオードディスプレイ）および／または音声スピーカを介して提示するよう構成されてもよい。
【００７７】
電源コンポーネント４１６は、電力接続および／またはローカルバッテリを含んでもよい。たとえば、電力接続は、デバイス４１０を、線間電圧源のような電源に接続してもよい。いくつかの例では、ＡＣ電源を用いて、（たとえば再充電可能な）ローカルバッテリを繰返し充電し得、バッテリは、後で、ＡＣ電源が利用可能でないときにデバイス４１０に電力を供給するよう用いられてもよい。
【００７８】
ネットワークインターフェイス４１８はデバイス４１０がデバイス間で通信することを可能にするコンポーネントを含んでもよい。ネットワークインターフェイスは、複数のネットワーク接続インターフェイスを含むことができる。言い換えれば、ネットワークインターフェイス４１８は、異なる通信方法を同時に使用してネットワークインターフェイス４１８がデバイス４１０を複数のネットワークおよび／または異なるデバイスに結合することを可能にする無線および／またはアンテナを含むことができる。例えば、いくつかの実施形態では、ネットワークインターフェイス４１８は、少なくとも１つの８０２．１５．４無線、少なくとも１つのＷｉＦｉ無線、少なくとも１つのブルートゥース無線、および／またはデバイスを複数のデバイスおよび／またはネットワークに接続することを可能にする他の無線を含んでもよい。ある実施の形態では、ネットワークインターフェイス４１８は、効率的ネットワーク層をその開放型システム間相互接続（ＯＳＩ）モデルの一部として用いて通信してもよい。一実施の形態では、効率的ネットワーク層は、以下において図５を参照して詳細に記載されるが、デバイス４１０が、ＲＩＰｎｇルーティング機構およびＤＴＬＳセキュリティスキームを用いて、ＩＰｖ６タイプのデータまたはトラフィックをワイヤレスで通信することを可能にしてもよい。したがって、ネットワークインターフェイス４１８は１つまたは複数のワイヤレスカードまたは何らかの他の送受信機接続を含んでもよい。
【００７９】
プロセッサ４２０は、さまざまな異なるデバイス機能のうちの１つ以上をサポートしてもよい。したがって、プロセッサ４２０は、ここに記載される機能の１つ以上を実行および／または実行させられるよう構成ならびにプログラミングされる１つ以上のプロセッサを含んでもよい。一実施の形態では、プロセッサ４２０は、ローカルメモリ（たとえばフラッシュメモリ、ハードドライブ、ランダムアクセスメモリ）に記憶されるコンピュータコードを実行する汎用プロセッサ、専用プロセッサもしくは特定用途向け集積回路、それらの組合せを含んでもよく、および／または他のタイプのハードウェア／ファームウェア／ソフトウェア処理プラットフォームを用いてもよい。さらに、プロセッサ４２０は、非同期Ｊａｖａｓｃｒｉｐｔ（登録商標）およびＸＭＬ（ＡＪＡＸ）または同様のプロトコルを用いて、クラウドサーバから与えられる命令を実行するＪａｖａ（登録商標）仮想マシン（ＪＶＭ）を動作させることなどによって、中央サーバまたはクラウドベースのシステムによって遠隔で実行または司られるアルゴリズムのローカル化されたバージョンまたは対応物として実現されてもよい。例として、プロセッサ４２０は、ある場所（たとえば家屋または部屋）がある特定の人物によって占有されるかもしくは（たとえば１つ以上のしきい値に関して）ある特定数の人々によって占有されるかどうかまで、ならびにそれを含んで、その場所がいつ占有されるかを検出してもよい。一実施の形態では、この検出は、たとえば、マイクロホン信号を解析すること、（たとえばデバイスの前における）ユーザの移動を検出すること、扉もしくはガレージ扉の開閉を検出すること、無線信号を検出すること、受信された信号のＩＰアドレスを検出すること、またはある時間窓内で１つ以上のデバイスの動作を検出することなどによって生じ得る。さらに、プロセッサ４２０は、特定の居住者または物体を識別するよう、画像認識技術を含んでもよい。
【００８０】
ある実施の形態では、プロセッサ４２０は、さらに、高消費電力プロセッサおよび低消費電力プロセッサを含んでもよい。高消費電力プロセッサは、ユーザインターフェイスコンポーネント４１４などを動作させるような、計算集中型動作を実行してもよい。低消費電力プロセッサは、逆に、センサ４１２からの危険または温度を検出するなどのような、より複雑でないプロセスを管理してもよい。一実施の形態では、低消費電力プロセッサは、計算集中型プロセスのために高消費電力プロセッサを起動するかまたは初期化してもよい。
【００８１】
いくつかの例では、プロセッサ４２０は、望ましい設定を予測、および／またはそれらの設定を実現してもよい。たとえば、存在検出に基づいて、プロセッサ４２０は、たとえば、家もしくはある特定の部屋に誰もいないときに電力を節約するよう、またはユーザの好み（たとえば一般的な住宅での好みもしくはユーザに特定の好み）に従って、デバイス設定を調整してもよい。別の例として、特定の人物、動物または物体（たとえば子供、ペットまたは紛失した物体）の検出に基づいて、プロセッサ４２０は、その人物、動物または物体がどこにあるかの音声インジケータもしくは視覚インジケータを起動してもよく、または認識されない人物がある条件下（たとえば夜もしくは照明が消えているときに）検出される場合に警報もしくはセキュリティ特徴を起動させてもよい。
【００８２】
ある例では、デバイスは、第１のデバイスによって検出されるイベントが第２のデバイスの動作に影響を与えるように、互いと対話してもよい。たとえば、第１のデバイスは、（たとえばガレージにおいて煙を検出すること、ガレージにおいて照明における変化を検出すること、および/またはガレージにおいて熱を検出することによって）煙がガレージで検出されたことを検出し得る。第１のデバイスはこの情報を第２のデバイスに効率的ネットワーク層を介して送信し、第２のデバイスは、送信された情報に対する適切なアクションを実行できる（たとえば、家屋温度設定、照明設定、音楽設定、および／またはセキュリティ警報設定を調整し得る）。別の例として、第１のデバイスは（たとえば動きまたは突然の光パターンの変化を検出することによって）ユーザが玄関に接近するのを検出し得る。第１のデバイスは、（たとえばドアベルの音のような）一般的な音声もしくは視覚信号を出力させ、または（たとえば訪問者の存在を、ユーザが占有している部屋内において知らせるよう）場所に特化した音声もしくは視覚信号を出力させてもよい。
【００８３】
例として、デバイス４１０はNest（登録商標）学習サーモスタットのようなサーモスタットを含んでもよい。ここで、サーモスタットは、温度センサ、湿度センサなどのようなセンサ４１２を含んでもよく、サーモスタットは、そのサーモスタットが配置される建物内における現在の環境状態を判断してもよい。サーモスタットのための電源コンポーネント４１６は、サーモスタットが継続的な電源の近くに配置されることを考えることなく、建物内の任意の場所に配置され得るように、ローカルバッテリであってもよい。サーモスタットはローカルバッテリを用いて電力を供給され得るので、サーモスタットは、バッテリがめったに取替えられないように、そのエネルギ使用を最小限にし得る。
【００８４】
一実施の形態では、サーモスタットは、回転可能なリングがその上にユーザインターフェイスコンポーネント４１４として配置される円形のトラックを含んでもよい。したがって、サーモスタットが暖房、換気、空調（ＨＶＡＣ）ユニットなどを制御することによって建物の温度を制御するように、ユーザは、回転可能なリングを用いて、サーモスタットと対話するかまたはサーモスタットをプログラミングしてもよい。ある例では、サーモスタットは、そのプログラミングに基づいて、建物に人がいないかもしれないときを判断してもよい。たとえば、ＨＶＡＣユニットを延長された時間期間の間電源オフにされるよう保持するようにサーモスタットがプログラミングされる場合には、サーモスタットは、建物にはその時間期間の間人がいないことになる、と判断してもよい。ここで、サーモスタットは、建物に人がいないと判断したときには照明スイッチまたは他の電子デバイスをオフにするようプログラミングされてもよい。したがって、サーモスタットはネットワークインターフェイス４１８を用いて照明スイッチデバイスと通信して、建物に人がいないと判断されたときに照明スイッチデバイスに信号を送るようにしてもよい。この態様で、サーモスタットは、建物のエネルギ使用を効率的に管理し得る。
【００８５】
一般的に、スマートネットワークは、図５に示されるように開放型システム間相互接続（ＯＳＩ）モデル４５０の一部であってもよい。ＯＳＩモデル４５０は、抽象化層に関する通信システムの機能を示す。つまり、ＯＳＩモデルは、ネットワーキングフレームワーク、またはデバイス間の通信がどのように実現され得るかを規定してもよい。一実施の形態では、ＯＳＩモデル４５０は６つの層、つまり物理層４５２、データリンク層４５４、ネットワーク層４５６、トランスポート層４５８、プラットフォーム層４６０、およびアプリケーション層４６２を含んでもよい。一般に、ＯＳＩモデル４５０における各層は、その上の層に従ってもよく、その下の層に従われてもよい。
【００８６】
このことを考慮して、物理層４５２は、互いと通信し得るデバイスのためのハードウェア仕様を与えてもよい。したがって、物理層４５２は、どのようにデバイスが互いと接続し、どのように通信リソースがそれらのデバイス間で共有され得るかを管理することをどのように支援するかなどを確立してもよい。
【００８７】
データリンク層４５４は、どのようにしてデータがデバイス間において転送され得るかを規定してもよい。一般に、データリンク層４５４は、送信されているデータパケットが伝送プロトコルの一部としてビットにエンコードおよびデコードされ得る態様を与えてもよい。
【００８８】
ネットワーク層４５６は、宛先ノードに転送されているデータがどのようにルーティングされるかを規定してもよい。ネットワーク層４５６は、さらに、アプリケーション層４６２におけるセキュリティプロトコルとインターフェイスして、転送されているデータの保全性を維持することを保証してもよい。
【００８９】
トランスポート層４５８は、ソースノードから宛先ノードへのデータのトランスペアレントな転送を規定してもよい。トランスポート層４５８は、さらに、トランスペアレントなデータの転送がどのようにして信頼性のあるままであるかを制御してもよい。したがって、トランスポート層４５８を用いて、宛先ノードに転送されるよう意図されるデータパケットが実際に宛先ノードに到達したことを検証してもよい。トランスポート層４５８において用いられてもよい例示的なプロトコルは、伝送制御プロトコル（ＴＣＰ）およびユーザ・データグラム・プロトコル（ＵＤＰ）を含んでもよい。
【００９０】
プラットフォーム層４６０は、トランスポート層４５８内において規定されるプロトコルに従ってデバイス間の接続を確立してもよい。プラットフォーム層４６０は、さらに、データパケットを、アプリケーション層４６２が用い得る形式に変換してもよい。アプリケーション層４６２は、ユーザと直接インターフェイスし得るソフトウェアアプリケーションをサポートしてもよい。したがって、アプリケーション層４６２は、ソフトウェアアプリケーションによって規定されるプロトコルを実現してもよい。たとえば、ソフトウェアアプリケーションは、ファイル転送、電子メールなどのサービスを与えてもよい。
【００９１】
ネットワーク層４５６は、インターネットプロトコルバージョン６（ＩＰｖ６）に基づいた通信プロトコルを用いて、デバイス１０間でデータをルーティングし得る。したがって、各デバイス４１０は、それ自体を、インターネット、ローカルネットワーク、ネットワークのグループ上のファブリックなどの上で識別するよう用いられる独自のアドレスを各デバイス４１０に与え得る１２８ビットのＩＰｖ６アドレスを含んでもよい。ある実施の形態では、ネットワーク層４５６は、デバイス間でデータをどのようにルーティングするかを判断するプロトコル（ＲＩＰｎｇ）を識別してもよい。図６に示すように、１つまたは複数の層を使用して、情報４７０（例えば、警報状態、セキュリティ情報など）をデバイス４７２と４７４との間で交換することができる。
【００９２】
ＩＩＩ．ＢＬＥを介したデバイス間の通信
Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギ（ＢＬＥ）は、２つのデバイス間に比較的低電力の接続を提供するワイヤレスパーソナルエリアネットワーク通信タイプである。ＢＬＥは、ＢＬＥアプリケーションを使用するために汎用属性（ＧＡＴＴ）プロファイルを（属性プロファイルの一部として）提供する。ＧＡＴＴプロファイルは、ＢＬＥ接続で「属性」として知られる短いデータを送受信するためのメカニズムを提供する。ＧＡＴＴは、ＢＬＥのほとんどまたはすべての実装例で一般に利用可能である。したがって、他のプロファイルが利用可能であってもよいが、ＧＡＴＴは、スマートネットワークデバイスおよび／またはパーソナル電子デバイス（例えば、携帯電話、ｉＰａｄ（登録商標）など）上で広く利用可能であり得る。
【００９３】
ＧＡＴＴは、複数の特性の概念に基づいて構築されている。各特性には最大サイズ５１２バイトの固定幅の値が１つあり、ほとんどの実装例で１２８バイトが使用される。一般に、特性には、一貫したサイズ（例えば、１６ビット、１２８ビット）を有する汎用一意識別子（ＵＵＩＤ）が割り当てられる。特性は、各々独自のＵＵＩＤを持つＧＡＴＴサービスとして知られているセットにグループ化される。
【００９４】
ＢＬＥ対話は、図７に示すようなクライアント役割とサーバ役割とを有するものとして特徴付けることができる。図示のように、ＧＡＴＴ対話５００は、クライアント５０２およびサーバ５０４の役割の両方を含む。クライアント５０２は、ＢＬＥ中央デバイスと呼ばれてもよく、サーバは、ＢＬＥ周辺デバイスと呼ばれてもよい。クライアントデバイス５０２は、サーバデバイス５０４の特性５０８の１つまたは複数に読出要求５０６を発行することによって、サーバデバイス５０４からデータを読出す。クライアントは、１つまたは複数の特性５０８を更新するために書込要求５１０を発行することができる。以下に説明するように、ある一般サービスは、双方のデバイスがＢＬＥを双方向データ通信として扱うことを可能にするＧＡＴＴテーブルを提供する。ＧＡＴＴサーバ５０４は、特性５０８をホストし、ＧＡＴＴクライアント５０２に、特性５０８を読出し、書込み、および／または契約利用する能力を提供する。さらに、いくつかの実施形態では、一般サービスはすべてのＢＬＥ広告に含まれるので、デバイスペアリング、警報解除、またはＢＬＥを介して通信するのに好適な他の用途など、多数の使用例でデバイス間の双方向通信を可能にするために、一般サービスを使用することができる。いくつかの実施形態では、ＧＡＴＴサーバ５０４は、デバイス間の双方向通信のために１つまたは複数の特性５０８を各々が含む１つまたは複数のサービス５１２を実装することができる。さらに、いくつかの実施形態では、各特性５０８は、異なるタイプおよび／または許可を有することができる。例えば、第１の特性５０８は、クライアントに読出および書込能力を提供し、別の特性５１４は、クライアントに、その中の値の指示のみを読み出すかまたは見る能力をクライアントに提供する。
【００９５】
したがって、ＧＡＴＴサーバはＧＡＴＴサービスを広告し、それらのサービス特性の標準値を維持する。ＧＡＴＴクライアントはＧＡＴＴサーバに接続し、サーバの特性を書込み、読出し、または契約利用することができる。クライアントが特定の特性の値を契約利用している場合、サーバはこの特性の値を変更し、ＧＡＴＴ指示を送信して、値が更新されたことをクライアントに通知してもよい。場合によっては、ＧＡＴＴ読出要求、書込要求、契約利用要求、指示要求が、サーバから受信した肯定応答とともに確実に送信されてもよい。
【００９６】
ＧＡＴＴは論理リンク制御および適応プロトコル（Ｌ２ＣＡＰ）によってサポートされ、それは次いでＬＥ非同期接続（ＬＥ  ＡＣＬ）論理トランスポートによってサポートされているので、単一のＧＡＴＴ特性読取り、書込み、契約利用または指示は信頼できると見なすことができる。これらのレイヤーは、個々のＧＡＴＴ動作についてのエラー検出、データ再送信、およびフロー制御を提供する。
【００９７】
前述のように、異なるＢＬＥ実装例における最大転送単位（ＭＴＵ）のサイズは、最小（例えば、２３バイト）から最大（例えば、５１２バイト）の範囲であり得る。これらの値は、デバイスの機能に応じてローカルに判断される。場合によっては、ピア間でＭＴＵサイズを交渉できる。クライアント５０２もサーバ５０４もＭＴＵを知らない場合、サーバ５０４は、ＢＬＥ仕様のため想定するのが安全である最大値として許容可能なフラグメントサイズ（例えば、２０バイト）で応答することができる。この場合、たとえサーバ５０４がこの数字バイトよりも大きなペイロードを伴う指示を受信したとしても、サーバ５０４はペイロードの最初の数（例えば２０）のバイトだけを読み出すことができる。いくつかの実施形態では、クライアント５０２は、常に１２８バイトの特性書込みを送信する。１つの接続イベントで特性データのすべてのバイトを転送できない場合は、複数の接続イベントを使用して特性データのバイトを転送する。さらに、ある実施形態では、ＭＴＵがペイロードのサイズから動的に判定されることを示すためにフラグメントサイズ値（例えば、２＾１６  −１、符号なし）を使用することができる。
【００９８】
図８は、クライアント５０２が特性５０８に書き込むときにおけるＢＬＥサービス５１４を介するクライアント５０２とサーバ５０４との間の通信５１８を示す。クライアント５０２は、ＢＬＥサービス５１４の属性の１つに書き込むための属性書込み要求５２０を送信する。ＢＬＥサービス５１４は、キャラクタ５０８が書込まれたかまたは書込が試みられたことを通知する通知５２２をサーバ５０４に送信する。いくつかの実施形態では、ＢＬＥサービス５１４は、書込要求５２０に関する書込応答５２４、成功の確認、失敗の通知、および／または他の情報を送信する。同様に、第２の属性書込要求５２６は、通知５２８および書込応答５３０を呼び出す。このプロセスは、通信５１８のための最終的な属性書込み要求５３２がＢＬＥサービス５１４に通知５３４および書込み応答５３６を送信させるまで続く。
【００９９】
図９は、サーバ５０４がＢＬＥサービス５１２を介して特性５１４に書き込むときの通信５４０を示す。サーバ５０４は、ＢＬＥサービス５１２において特性５１４における属性を更新要求５４２で更新し、書込は書込指示５４４を介してクライアント５０２に示される。いくつかの実施形態では、クライアント５０２は、書き込まれたデータのクライアント５０２への転送の完了時に、書込確認５４６をＢＬＥサービス５１２に送信する。そのような実施形態では、サーバ５０４は、データ損失の可能性を低減するために確認５４６を受信するまで、第２の更新要求５４８を送信するのを待ってもよい。第２の更新要求５４８がＢＬＥサービス５１２で受信されると、属性書込指示５５０がクライアント５０２に送信され、確認５５２が呼び出される。このプロセスは、書込指示５５４および書込確認５５８を呼び出す最終属性更新要求５５６がサーバ５０４によって送信されるまで続く。
【０１００】
図１０は、ＢＬＥサービス５１２を介したクライアント５０２とサーバ５０４との間の対話のブロック図を示す。図示の実施形態では、クライアント５０２からサーバ５０４に流れる通信は、第１の特性５０８を通って流れる。言い換えれば、クライアント５０２は、第１の特性５０８を介して送信された属性書込５６０を使用して、サーバ５０４にデータを送信する。更新された第１の特性は、特性更新通知５６２を介してサーバ５０４に送信される。いくつかの実施形態では、ＢＬＥサービス５１２は、別の書込み要求が送信されてもよいことをクライアント５０２に通知する書込み確認５６４を送信する。
【０１０１】
サーバ５０４からクライアント５０２への通信は、第２の特性５１４を使用して送信することができる。例えば、サーバ５０４は、特性更新要求５６６をＢＬＥサービス５１２に送信することができる。これに応答して、更新指示５６８をクライアント５０２に送信することができる。特定の実施形態では、クライアント５０２は、ＢＬＥサービス５１２に、クライアント５０２に対するデータ損失のリスクを冒すことなく新しい値で第２の特性５１４を更新できることを通知する指示受信確認５７０を送信する。
【０１０２】
Ｗｅａｖｅ（または他の通信プロトコル）がＢＬＥを介して送信されてもよい。しかしながら、ＧＡＴＴは特性ベースの通信プロトコルであり、Ｗｅａｖｅはメッセージベースのプロトコルである。さらに、単一のＷｅａｖｅメッセージペイロードは、ＧＡＴＴ特性の最大サイズより大きいかもしれない。例えば、１つのＷｅａｖｅメッセージは、１，５００バイトのサイズを有し得、一方、ＢＬＥ実装は、通信をかなり小さい数（例えば、２７バイトまたは１２８バイト）に制限し得る。したがって、Ｗｅａｖｅを使用してスマートネットワークでＢＬＥを使用するためには、上位層（例えば、アプリケーション層、トランスポート層など）は、ＧＡＴＴ上に構築されたストリーミングソケット、Ｂｌｕｅｔｏｏｔｈ転送プロトコル（ＢＴＰ）を展開し得る。Ｗｅａｖｅは、ＢＴＰを使用してＷｅａｖｅメッセージを複数のフラグメントに分割し、複数のフラグメントは、各々単一のＧＡＴＴ書込または指示を介して送信され得る。さらに、前述のように、ＭＴＵは、少なくともいくつかの特性よりも大きくてもよい。特定の実施形態では、ＢＬＥクライアントに指示を送信するために使用される特性は、ＢＬＥハンドシェイクで交渉されるＭＴＵのサイズに制限されてもよい。
【０１０３】
ＢＴＰは、トランスポート層接続の独自の概念を基底のＢＬＥ接続の上に定義する。この設計は、２０１４年１０月７日に出願され、その全体が引用により援用される、「Authenticated Session Establishment（認証されたセッション確立）」と題された米国特許出願第１４／５０８，９３３号に教示されているような、証明書認証セッション確立（ＣＡＳＥ）プロトコルまたはパスワード認証セッション確立（ＰＡＳＥ）プロトコルのような、あるＷｅａｖｅプロトコルが、ＢＬＥを介して機能することを可能にする。それは、また、ＢＬＥデバイス上でＷｅａｖｅを使用するデバイスに、プロトコルバージョンの互換性をチェックさせ、特定のデータをＢＴＰ接続ハンドシェイクの一部として交換させもする。
【０１０４】
Ｗｅａｖｅメッセージフラグメントを送信するために、ＢＴＰは２つのＧＡＴＴ特性を定義する。１つはＧＡＴＴクライアントからサーバに送信されるメッセージフラグメント用で、もう１つはサーバからクライアントに送信されるフラグメント用である。クライアントは、ＧＡＴＴ書込を介して第１の特性上でフラグメントをサーバに送信する。クライアントが第２の特性を契約利用すると、サーバはそれを使用してフラグメントをＧＡＴＴ指示を介してクライアントに送信する。
【０１０５】
いくつかの実施形態では、前述のように、ＢＴＰは、前のフラグメントの送信に応答してＧＡＴＴ書込みまたは指示確認が受信されるまで、第１のメッセージフラグメント以外のすべてを送信するのを待つことを含む。ＢＴＰが、追加のフラグメントを送信する前にＧＡＴＴ動作肯定応答を待たなかった場合、リモートＧＡＴＴサーバまたはクライアントは、対応するＧＡＴＴ動作のいずれかを確認する前に所与の特性に対して受信したすべての値を集計し得る。さらに、いくつかのケースでは、サーバまたはクライアントは、実質的により大きなバッファおよび／または処理能力を有し得、フラグメントの少なくともいくつかが失われる前に肯定応答が使用されなかった場合には他のデバイスを直ちに圧倒し得る。換言すれば、最も最近受信された値だけがＧＡＴＴスタックからアプリケーション層に渡されるであろう。特性値はｌａｓｔ−ｗｒｉｔｅ−ｗｉｎｓであるため、この挙動はＧＡＴＴプロファイルに従っては正しいであろうが、そのような挙動はデータ損失のためＢＴＰには悪いであろう。
【０１０６】
Ａ．ＢＬＥコントローラアーキテクチャ
ＧＡＴＴは、個々の書込および指示について、フロー制御、エラー検出、およびペイロード再送信を提供し得る。しかしながら、多くの実装例では、このフロー制御およびコアＧＡＴＴ機能の多くは、プラットフォームのホストプロセッサとは独立した別個のＢＬＥコントローラチップによって管理される。
【０１０７】
多くの実装例では、受信した書込要求および指示要求に応答してＧＡＴＴ肯定応答を送信するのはこのＢＬＥコントローラである。コントローラは、これらの肯定応答を、受信したデータが実際に成功する前に、ホストプロセッサのアプリケーションプログラムに送信し得る。言い換えれば、受信したデータは、ＯＳＩモデルスタックを様々な層を介してアプリケーション層にバックアップして送信されないかもしれない。この理由から、ＧＡＴＴ肯定応答は、所与のメッセージフラグメントがリモートＢＴＰアプリケーションによって受信されたことを確認するのに十分ではないかもしれない。
【０１０８】
さらに、埋め込みプラットフォームでは、ＢＬＥコントローラと、ホストプロセッサ上のＢＬＥドライバと、ホストプロセッサのＢＬＥアプリケーションとの間に非常に小さな待ち行列が存在することがある。リモートデバイスが、ＧＡＴＴ書込または指示を、これらの待ち行列が空になり得るよりも速く送信すると、ＢＬＥコントローラによってＧＡＴＴレイヤで肯定応答されたメッセージフラグメントは、ホストプロセッサ上のＢＴＰスタックに対して成功する前に廃棄される。この問題を解決するために、ＢＴＰは送信側にバックプレッシャをかけるためのアプリケーション層メカニズムを提供する。このメカニズムを使用すると、送信側は、以前のすべての送信書込みまたは指示がリモートＢＬＥコントローラによって肯定応答された場合でも、今後のＧＡＴＴ送信をいつ一時停止すべきかがわかる。
【０１０９】
さらに、特定のＢＬＥコントローラは、ホストプロセッサに送信される前に、ランダムなリセットを経験するかまたは肯定応答されたＧＡＴＴ特性の更新を廃棄し得る。ＢＴＰは、これらの障害を検出して回復できる機能を追加する。
【０１１０】
Ｂ．エラー検出
ＧＡＴＴを介して送信されるデータの保全性は、不完全なメッセージ送信に対するＬ２ＣＡＰのペイロードエラー検出および再送信機能によって維持され得る。したがって、ＢＴＰによって検出されるＬ２ＣＡＰのペイロードエラー検出によって見逃されたエラーには、メッセージフラグメント全体が誤動作しているＢＬＥコントローラによって廃棄または並べ替えられたエラーが含まれる。ＢＬＥコントローラがＢＬＥ会話中にリセットする場合、ＢＴＰメッセージフラグメントがＧＡＴＴレイヤで肯定応答された後でも、それらのフラグメントを永久に廃棄し得る。ＢＴＰは、この障害シナリオを検出し、それが生じると接続をリセットしてメッセージデータ破損の可能性を減じてもよい。ＢＬＥコントローラがＧＡＴＴ特性書込または指示を並べ替える場合、ＢＴＰはこの障害を検出して接続をリセットして、メッセージデータの破損のリスクの可能性を低減してもよい。
【０１１１】
Ｃ．メッセージフォーマット化
ＢＴＰメッセージフラグメントは、時系列順序が失われたときに肯定応答および／またはメッセージ再分類を可能にするシーケンス番号とともに送信される。ＢＴＰスタックは、そのもっとも最近受信したメッセージフラグメントの周期的な肯定応答を送信する。ＢＴＰスタックは、また、設定された期間内にそれ自身の送信されたフラグメントに対する肯定応答を受信しない場合に、接続を閉じる。接続の各側（例えば、サーバおよびクライアント）は、受信側の待ち行列が一杯になったときに、送信側にアプリケーション層（ＧＡＴＴに対する）バックプレッシャをかけるための受信ウィンドウを定義する。各側は、ＢＴＰ接続が開いているが、送信すべきアプリケーションデータがないときには、周期的なキープアライブメッセージを送信する。
【０１１２】
図１１は、ＢＴＰを使用して送信されるデータのパケット６００の実施形態を示す。パケット６００は、送信されるメッセージのタイプを識別するヘッダフラグ６０２と、そのメッセージを前のメッセージの肯定応答として識別する肯定応答番号６０４と、メッセージストリングにおいてメッセージの順序を識別するシーケンス番号６０６と、メッセージおよび／または各パケットについて長さを示すメッセージ長６０８と、クライアント５０２とサーバ５０４との間で共有されるデータを含むフラグメントペイロード６１０とを含む。いくつかの実施形態では、１つまたは複数のヘッダフラグ６０２を単一のメッセージに含めることができる。例えば、メッセージは、メッセージフラグメントと肯定応答とを含むことができる。さらに、特定の実施形態では、フラグ値は、以下の表１に示すものから選択することができる。
【０１１３】
【表１】
2019500659.tif 000003
【０１１４】
メッセージ開始ヘッダは、メッセージがパケット６００においてメッセージ長６０８を含むことを示す。いくつかの実施形態では、このメッセージ長は、メッセージ全体の長さを示し、現在記述されているパケット６００におけるデータだけではない。メッセージ開始ヘッダはまた、シーケンス番号６０６およびフラグメントペイロード６１０がパケット６００に含まれることを示す。メッセージデータヘッダは、交渉されたフラグメントサイズ（ＭＴＵ）からヘッダオーバーヘッドを差し引いたデータ長を有する非終端メッセージフラグメント（すなわち、メッセージの終わりではない）の存在を示す。メッセージヘッダはまた、シーケンス番号６０６およびフラグメントペイロード６１０がパケット６００に含まれることを示す。メッセージ終了ヘッダは、フラグメントペイロード６１０がメッセージの終わりを含むことを示す。このメッセージの長さは、メッセージ長６０８によって示されるように送信されていないメッセージのデータの残量によって判断される。メッセージ終了ヘッダはまた、パケット６００がシーケンス番号６０６およびフラグメントペイロード６１０を含むことを示す。フラグメント肯定応答ヘッダは、シーケンス番号６０６またはフラグメントペイロード６１０が含まれているかどうかにかかわらず、肯定応答６０４がパケット６００に含まれることを示す。キープアライブヘッダは、メッセージがシーケンス番号６０６をヘッダデータととともに含むが、他のフィールドは有さないことを示す。
【０１１５】
Ｄ．シーケンス番号
シーケンス番号により、ローカルまたはリモートＢＬＥコントローラがその受信したＧＡＴＴ要求をリセットまたは並べ替えたかどうかを検出できる。シーケンス番号はまた、ＢＴＰ受信ウィンドウの判定およびキープアライブメッセージの送信を容易にする。
【０１１６】
すべてのＢＴＰメッセージフラグメントは、キープアライブフラグやデータペイロードのない肯定応答フラグメントを除いて、シーケンス番号とともに送信される。これらのシーケンス番号は、１とともに送信される各メッセージフラグメントに対して１だけ単調増加する符号なし８ビット整数である。シーケンス番号は、システムによって維持される各ＢＴＰ接続ごとに別個に定義され、増分される。各接続ごとに、１つのデバイス上のＢＴＰスタックは、送受信されたメッセージフラグメントに対して別個のシーケンス番号カウンタを維持する。新しいＢＴＰ接続が形成されると、そのシーケンス番号は開始番号（例えば、０）に初期化される。シーケンス番号は、シーケンス番号のために割り当てられた所定の数のビット（例えば８）で表されるよう利用可能なサイズを超えると、開始番号に折り返される。例えば、シーケンス番号に８ビットが割り当てられる実施形態では、利用可能なシーケンス番号は０〜２５５（例えば２５５＝２８−１）である。したがって、そのような実施形態では、シーケンス番号２５５を有するメッセージフラグメントの後に、シーケンス番号０を有するメッセージフラグメントが続く。
【０１１７】
デバイスが予期しないシーケンス番号を持つメッセージフラグメントを受信すると、デバイスは対応するＢＴＰ接続をリセットする。このような障害は、Ｌ２ＣＡＰの信頼性メカニズムの障害またはＢＬＥコントローラのエラーを示す。
【０１１８】
１．シーケンス番号肯定応答
シーケンス番号肯定応答は、ＢＴＰ受信ウィンドウをサポートする。シーケンス番号肯定応答は、接続の相手側のＢＴＰスタックが稼動し続けていることを示す信号も提供する。
【０１１９】
メッセージフラグメントを送信すると、ＢＴＰスタックは、タイマ（「肯定応答受信済み」タイマ）がまだ動作していなければ、このタイマを開始する。このタイマの継続時間は、「肯定応答タイムアウト間隔」として定義される。スタックは、最も最近送信され肯定応答されなかったメッセージフラグメント以外のものに対して有効なフラグメント肯定応答が受信されたときに、このタイマを再開する。フラグメント肯定応答は、ＢＴＰメッセージフラグメントにピギーバックされた符号なし８ビット整数として受信されるか、またはシーケンス番号もしくはメッセージペイロードのないスタンドアロン肯定応答として受信される。このタイマは、最も最近送信され肯定応答されなかったメッセージフラグメントについて肯定応答が受信されると、停止する。このタイマが満了するか無効なフラグメント肯定応答が受信されると、スタックは接続をリセットする。
【０１２０】
肯定応答されたシーケンス番号Ｘが、ラップアラウンドを伴うシーケンス番号のリング上のＹとＺとの間の最短間隔内にない場合、フラグメント肯定応答は無効と見なされ、ここで、Ｙは最も古い、送信された、肯定応答されなかったメッセージフラグメントであり、Ｚは最も新しいそれである。
【０１２１】
ＢＴＰスタックがシーケンス番号を持つメッセージフラグメントを受信すると、ＢＴＰスタックはこのシーケンス番号を接続の「保留中の肯定応答」値として記録し、タイマ（「肯定応答送信」タイマ）がまだ動作していなければ、このタイマを開始する。このタイマの持続時間は、送信側が肯定応答の欠如のために接続を閉じる前に肯定応答が受信されることを確実にするために、肯定応答タイムアウト間隔の半分として定義される。
【０１２２】
保留中の肯定応答が送信されると、スタックはこのタイマを停止する。このタイマが満了して、スタックに保留中の肯定応答がある場合、肯定応答はシーケンス番号またはメッセージペイロードのないフラグメントとして直ちに送信される。このタイマが満了になる前にスタックがメッセージフラグメントを送信する場合、スタックは、保留中の肯定応答を送信されたメッセージフラグメントにピギーバックして、タイマを停止する。
【０１２３】
いくつかの実施形態では、ＢＴＰスタックが、それの、送信すべき保留中の肯定応答の数が即時送信閾値（例えば、受信ウィンドウに残された２つ以下のメッセージフラグメント）に縮小したことを検出すると、それは即座に任意の保留中の肯定応答を送信する。
【０１２４】
Ｅ．受信ウィンドウ
受信ウィンドウは、ＢＴＰ接続において両方のデバイス間でＧＡＴＴ上においてアプリケーション層のフロー制御を可能にすることによって、適切なシーケンス化を保証する。受信ウィンドウは、予期せず折り返しからフラグメントシーケンス番号を遮断する。ＢＴＰ接続の両方のデバイス（例えば、クライアントおよびサーバ）は、受信ウィンドウを定義し、ここで、ウィンドウサイズは、各側が肯定応答なしに確実に受信できると判断するシーケンシャルなメッセージフラグメントの数である。いくつかの実施形態では、ＢＬＥ接続において両方のデバイスに対してＢＴＰ接続ハンドシェイクの一部として初期ウィンドウサイズが確立される。特定の実施形態では、受信ウィンドウは、保留中の対話に対して減分される最大サイズを有することができる。いくつかの実施形態では、受信ウィンドウは、可能なシーケンス番号の数の半分でキャップされる。たとえば、可能なシーケンス番号が０〜２５５の場合、最大ウィンドウサイズは１２７と定義され得る。受信ウィンドウにこのような制限を設定すると、肯定応答されないシーケンス番号のラップアラウンドが遮断される。例えば、このような制限は、メジアンシーケンス番号１２７を下回る、より古い期待される番号も受信され得るときに送信されるメッセージフラグメントに対する、より新しい初期シーケンス番号０を受信することを遮断する。
【０１２５】
特定の実施形態では、双方は、お互いの現在の受信ウィンドウサイズを反映するようにカウンタを維持する。例えば、クライアント５０２は、サーバ５０４のウィンドウサイズを反映するようにカウンタを維持することができる。このカウンタは、新しいメッセージフラグメントが送信されるたびに減分される。メッセージ肯定応答が受信されると、カウンタは（（肯定応答されたシーケンス番号−最も古い肯定応答されなかったシーケンス番号）＋１）だけ増分される。カウンタが０の場合、送信側はカウンタが増分されるまでさらなるメッセージフラグメントを送信しないようにする。メッセージフラグメントの受信でカウンタが０から増分されると、送信側はただちにメッセージフラグメント送信を再開する。
【０１２６】
いくつかの実施形態では、ＢＬＥ接続においてＢＴＰを使用する両方のデバイスは、それら自身の受信ウィンドウサイズのカウンタを維持する。これらのカウンタは、それぞれのデバイスによって受信された最後のメッセージフラグメントのシーケンス番号と、それぞれのデバイスによって送信された最後の肯定応答とに基づいている。このカウンタは、受信側のウィンドウサイズが０の場合に不要な遅延が発生しないように早期の肯定応答を送信するために使用される。言い換えれば、あるデバイスは、そのデバイスが肯定応答をピギーバックする可能性があるメッセージフラグメントをさらに待たずに、保留中のメッセージ肯定応答を送信することができる。デバイスは、肯定応答送信タイマがまだ動作しているかどうかに関係なく、保留中のメッセージ肯定応答を直ちに送信する。
【０１２７】
Ｆ．キープアライブメッセージ
前述したように、いくつかのパケット６００は、キープアライブメッセージとして示されてもよい。キープアライブメッセージを使用して、所与の接続におけるリモートＢＴＰスタックがクラッシュまたは停止したかどうかを判断できる。したがって、接続がメッセージ層でアイドル状態になっている場合など、アプリケーションデータが送信されていない、または肯定応答されていない場合でも、キープアライブメッセージは接続を保証する。
【０１２８】
ＢＴＰスタックは、それの肯定応答送信タイマを停止し、対応する接続においてＢＬＥ中央（例えば、クライアント５０２）の役割を果たすとき、キープアライブタイマを肯定応答タイムアウト間隔の半分の持続時間で開始する。任意のメッセージフラグメント（キープアライブメッセージまたは他のタイマ駆動型肯定応答を含む）を送信し、このタイマがすでに動作しているときに、このタイマを再始動する。シーケンス番号を持つメッセージフラグメントを受信すると、このタイマを停止する。保留中の肯定応答として、このフラグメントは明示的なキープアライブメッセージを生成しその有用性を一時的に取り除く。キープアライブ送信タイマが満了すると、スタックはキープアライブメッセージを送信し、タイマは再開される。通常のペイロード担持メッセージフラグメントと同様に、失われたキープアライブ肯定応答により、接続がリセットされる。
【０１２９】
キープアライブメッセージは、有効なシーケンス番号を持つＢＴＰメッセージフラグメントであるが、ヌルのペイロードである。キープアライブメッセージは、受信側によって肯定応答されるが、キープアライブメッセージは、ＢＴＰメッセージリアセンブラから次の上位層、すなわち上位プロトコルメッセージ層へとスタックを通過しない。ＢＴＰキープアライブメッセージは、したがって、メッセージトラフィックが存在しないことに基づいてアイドル状態のスマートネットワーク接続を自動閉鎖することを妨げない。
【０１３０】
通常のペイロード担持メッセージフラグメントの場合と同様に、ＢＬＥ中央デバイス上のＢＴＰスタックは、周辺の受信ウィンドウが一杯になると、キープアライブメッセージを送信しない。
【０１３１】
ＢＴＰスタックは、肯定応答受信タイマを停止し、対応する接続においてＢＬＥ周辺の役割（例えば、サーバ５０４）を果たすとき、キープアライブ受信タイマを肯定応答タイムアウト間隔の持続時間で開始する。このタイマは、ＢＴＰメッセージフラグメントを受信するたびに再起動される。このタイマは、肯定応答受信タイマが開始されると、停止される。キープアライブ受信タイマが満了すると、周辺デバイスはＢＴＰ接続をリセットする。
【０１３２】
ＩＶ．広告
図１２に示すように、第１のデバイス６２０と第２のデバイス６２２との間にＢＬＥ接続を確立する場合、デバイスの１つ（例えば、デバイス６２０）は、広告デバイス、接続されたネットワーク、および／または潜在的なＢＬＥ接続についてのさまざまな詳細を示す広告６２４を送信出力する。スマートネットワークデバイスは、限られた広告データスペースを使用するために一貫したフォーマットで広告する。たとえば、フォーマットを５９バイトに制限し、広告に２８バイトを指定し、スキャン応答に３１バイトを指定してもよい。ＢＬＥ広告は、広告デバイスが接続するデバイス、警報、通信タイプ、および／またはネットワークに関する様々な詳細を示すために使用することができる。例えば、ＢＬＥ広告は、広告デバイスを他のデバイスと区別し、広告デバイスのための人が判読可能な名称を含み、広告デバイスのために、警報を発令している状態または警報を発令していない状態を示し、広告デバイスに接続されたデバイスのために、警報を発令している状態を示し、広告デバイスのクラスを識別し、広告デバイスがアカウントとペア設定されているかどうかを識別し、および／または広告デバイスへの結合から生じるＢＬＥ通信で使用されるサービスに関する様々な情報（すなわち、特性のグループ）を識別してもよい。
【０１３３】
さらに、広告は、ＵＵＩＤを使用してサポートされるＢＬＥサービスの指示を含むことができる。例えば、一般サービスＵＵＩＤを使用して、デバイスが特定の通信プロトコル（例えば、Ｗｅａｖｅ）を介して通信をサポートすることを示してもよい。それに加えて、またはこれに代えて、クリティカルイベントサービスＵＵＩＤを使用して、クリティカルイベント（例えば、煙が検出された）が発生し、緊急に注意を喚起すべきであることを示してもよい。いくつかの実施形態では、これらのサービスインジケータ（例えば、ＵＵＩＤ）は、同じサイズ（例えば、１６ビット）であってもよく、または他の何らかのサイズであってもよい。
【０１３４】
Ａ．一般サービス
特定のプロトコル（例えば、Ｗｅａｖｅ）上でデータ通信が行われ得ることを示す一般サービスが含まれてもよい。広告デバイスがこのサービスをサポートするという指示を含ませることによって、広告デバイスおよび別のリモートデバイスは、前述のようにＧＡＴＴ構造を使用してＢＬＥを介して通信してもよい。
【０１３５】
前述したように、広告データは一般サービスＵＵＩＤを含むことができる。一般サービスＵＵＩＤに加えて、メタデータをこのサービスに関連付けることができる。特定の実施形態では、広告は、デバイスについての識別情報を含むことができる。加えて、または代替的に、いくつかの実施形態は、認証トークンを使用して識別情報の少なくとも一部を隠すことができる。例えば、広告は、モバイル認証デバイスに接続することも、それに関する情報を共有することもできないデバイスのブルートゥース範囲内で物理的に移動し得る当該モバイル認証デバイスに対して隠蔽／暗号化することができる。広告は、どのタイプの情報が含まれているかを示すことができる。従って、一般サービスを含む広告は、使用されるＷｅａｖｅデータの種類を識別するサービスデータフィールドを含むことができる。例えば、このフィールドでは、第１の値（例えば、０ｘ０１）はデバイス情報が広告に含まれていることを示し、第２の値（例えば、０ｘ０２）はデバイス情報の明示的な記載なしに認証トークンが含まれていることを示す。いくつかの実施形態では、いくつかの情報を共有するが、他の情報を隠す、ハイブリッド通信タイプを含めることができる。さらに、いくつかの実施形態では、他の好適なデータブロックタイプをこのフィールドに符号化することができる。
【０１３６】
ＢＬＥ広告がデバイス情報を含む場合、広告は、以下の表２に表されるものと同様のフィールドを含むことができる。
【０１３７】
【表２】
2019500659.tif 000004
【０１３８】
表２は、デバイス情報における各フィールドのオクテットサイズの指示を含むが、いくつかの実施形態は、これらのサイズを実装要件に基づいて増減してもよい。デバイスクラスは、そのデバイスの製造業者またはベンダーを識別するベンダー識別子（ＩＤ）を含むことができる。デバイスクラスは、ベンダーによって提供される特定のデバイスタイプを識別する製品識別子を含むこともできる。デバイスＩＤは、スマートネットワークにおいてデバイスを識別するために使用される識別子であってもよい。例えば、デバイスＩＤは、スマートネットワークにおけるそのデバイスのためのノードＩＤであってもよい。アカウントペア設定ステータスは、デバイスがリモートサービス上のアカウントとペア設定されているかどうかを示す。いくつかの実施形態では、いくつかのアクション（例えば、警報の解除）は、リモートサービス上でアカウントにペア設定されるデバイスに制限される。言い換えれば、そのような実施形態では、リモートサービスにペア設定されていないハザード検出器を解除することはできない。さらに、いくつかの実施形態では、ハザード検出器がペア設定されるアカウントにアクセスを有する解除デバイスだけである。例えば、ハザード検出器がリモートサービスにペア設定されている場合、解除デバイス（例えば、携帯電話）がリモートサービス上でペア設定されたアカウントにアクセスすると解除デバイスに送られる解除鍵がそのサービスによって生成される。ハザード検出器は、この解除鍵なしでは解除コマンドを受け入れない。さらに、この解除鍵は、リモートサービス上で共通のアカウントとペア設定されるかまたはそのアカウントにアクセスを有する任意のデバイスに共通であってもよい。
【０１３９】
認証トークンを含む広告では、ペイロードは少なくとも部分的に暗号化されていてもよい。いくつかの実施形態では、バージョン番号付けは、暗号化された広告を受信する承認されたデバイスに広告をどのように解読するかの指示を提供するために暗号化されなくてもよい。他の実施形態では、バージョン番号付けは、広告の残りの部分とともに、または認証トークンバージョン間で一貫して解読されるそれ自身の暗号化エンベロープにおいて、暗号化されてもよい。
【０１４０】
Ｂ．クリティカルイベントサービス
デバイスにおいて緊急性を示す警報／イベントがある場合、広告は、一般サービスに加えて、またはその代わりに、付随するクリティカルイベントサービスについての詳細を含むことができる。この場合、広告は、ＵＵＩＤのリストにおけるクリティカルイベントサービスがサポートされる旨の指示、およびクリティカルイベントを分類するイベント特有情報を含むであろう。
【０１４１】
ネストデバイスがクリティカルイベントを伝える状態では、それは、広告のこのフィールドを利用することによってそのようにする。場合によっては、複数のクリティカルイベントが同時に発生することがある。
【０１４２】
以下の表３に示すフォーマットと同様のフォーマットを使用して、複数のクリティカルイベントを単一の広告で伝達することができる。
【０１４３】
【表３】
2019500659.tif 000005
【０１４４】
表３はデータ長の例を含むが、いくつかの実施形態は様々なフィールドの長さを変えることができる。さらに、クリティカルイベントタイプは、送信される警報のタイプを示すことができる。いくつかの実施形態では、このクリティカルイベントタイプは、どのようなタイプのデバイスがクリティカルイベントを発生させたかを示すことができる。例えば、ハザード検出器からの警報（例えば、煙警報、ＣＯ警報、熱警報など）は、単一のクリティカルイベントタイプとして分類することができる。各イベントタイプは、広告においてイベントタイプフィールドに対応し、およびそれに従う、定義された長さのオクテットを有することができる。
【０１４５】
以下の表４は、イベントタイプフィールドの後に続いてもよいタイプ固有イベントの考えられ得る例を示す。ここでも、以下の表は、各フィールドの可能な長さを含むが、いくつかの実施形態は、異なるフィールドサイズを有してもよく、および／または実装例間でフィールドサイズを変えてもよい。 
【０１４６】
【表４】
2019500659.tif 000006
【０１４７】
クラスイベントバージョンは、クリティカルイベントがどの一般クラスに属するかを示す。例えば、クラスイベントは、検出された危険（例えば、煙、火災、ＣＯなど）、セキュリティ警報、灌漑問題、および／またはスマートネットワークで警告され得る他の適切なイベントタイプであり得る。警報異議は、任意の解除要求が適時であることを保証するために使用される。
【０１４８】
警報情報は、クラスイベントに特有の警報タイプを示す上位ニブルを含む。例えば、検出された危険から生じる警報では、警報タイプを示す警報情報の上位ニブルは、以下の表５の値から選択することができる。
【０１４９】
【表５】
2019500659.tif 000007
【０１５０】
下位ニブルは、下の表６の値から選択され得る警報についての状態を示す。
【０１５１】
【表６】
2019500659.tif 000008
【０１５２】
Ｃ．広告における追加情報
サービスＵＵＩＤおよび関連情報に加えて、またはそれに代えて、いくつかの実施形態は、デバイスについて人間が判読可能な名称を含むことができる。例えば、いくつかの実施形態では、人間が判読可能な名称は、デバイスの名称を示す限界（例えば、４バイト）までの長さを有するオプションであってもよい。例えば、人間が判読可能な名称は、テキスト「ｄ２」に対するバイナリ値を含むことができる。広告は、さらに、製造者固有のヘッダ（ＭＳＨ）において追加の製造者固有のデータを含んでもよい。ＭＳＨは、製造業者に固有の広告データを示すＡＤタイプを含むことができる。いくつかの実施形態では、このデータは１バイト（例えば、０ｘＦＦ）を割り当てられてもよい。ＭＳＨはまた、製造者識別子コードを含むことができる。いくつかの実施形態では、この識別子は、所定の長さ（例えば、２バイト）を有してもよい。いくつかの実施形態では、この情報は、先に説明したベンダーＩＤから取得することができる。
【０１５３】
Ｄ．データの分割
いくつかの実施形態では、広告に含まれるべきデータは、サイズ制約または他の制約のために、単一の広告パケットに含めることができない。そのような場合では、広告されるべきデータは、広告パケットとスキャン応答パケットとの間で分割されてもよく、それらの両方ともがスキャンデバイスに中継される。中央デバイスのオペレーティングシステムに基づいて、これらのパケットは別々のイベントとして報告されるかもしれないが、スキャンデバイスで相関付けされる。データの分割に基づいて、クリティカルな情報が優先され、スキャン応答パケットの前に送信される広告パケットに含まれてもよい。スキャン応答パケットは、後で（例えば、スキャンデバイスからのスキャン要求に応答して）提供されてもよい。
【０１５４】
図１３は、広告パケット６３２とスキャン応答パケット６３４とに分割される広告６３０の実施形態を示す。図示されているように、広告パケット６３２は、一般サービスおよびクリティカルイベントサービスのような、利用可能なサービス６３６のためのＵＵＩＤのリストを含む。さらに、クリティカルイベントが発生した場合、および／または発生している場合、広告パケット６３２はクリティカルサービスデータ６３８を含む。
【０１５５】
よりタイムクリティカルでないデータは、広告パケット６３２とともに、および／または後で（例えば、スキャン要求に応答して）送信されてもよいスキャン応答パケット６３４に含まれてもよい。例えば、スキャン応答パケット６３４は、一般サービスデータ６４０、人間が判読可能な名称６４２、および／または送信出力レベル６４４を含むことができる。一般サービスデータ６４０および人間が判読可能な名称６４２は、先に説明した例示的な構造に準拠することができる。送信出力レベル６４４は、通信が発生するレベル（例えばｄＢで）を示すことができる。
【０１５６】
Ｅ．広告例
１．警報を発令しないデバイス例
図１４は、ＢＬＥを介してデバイスによって送信され得る広告６５０の実施形態を示す。いくつかの実施形態では、様々なフィールドのサイズおよび順序は変わる可能性がある。さらに、いくつかの実施形態では、フィールドのいくつかは、広告の少なくともいくつかの送信から省略されてもよい。特定の実施形態では、広告６５０は、広告全体の長さを示す長さフィールド６５２を含む。広告６５０はまた、どのようなタイプのデータが１つまたは複数の後続のフィールドに含まれているか、および／またはどのようなタイプのデータが長さフィールド６５２によって言及されているかを示すＡＤタイプフィールド６５４を含む。いくつかの実施形態では、ＡＤタイプフィールド６５４が、長さフィールド６５２が、長さフィールド６５２、ＡＤタイプフィールド６５４、およびＵＵＩＤのリスト６５８を含むメタデータヘッダ６５６に関係することを示す値（例えば０ｘ０２）を有する場合。いくつかの実施形態では、長さフィールドは、長さフィールド６５２およびＡＤタイプフィールド６５４が関係するデータチャンク（例えばメタデータヘッダ６５６）の長さを示す。さらに、いくつかの実施形態では、長さは、データチャンクの残りのフィールドの長さを示すことができる。例えば、そのような実施形態において、および、フィールドが図１３に示すものに対応する長さを有する場合、長さフィールドは、ＵＵＩＤのリスト６５８およびＡＤタイプフィールドＢ４が３バイトの全長を有することを示す値３を有することができる。
【０１５７】
いくつかの実施形態では、広告６５０は、人間が判読可能な名称データチャンク６６０を含むことができる。いくつかの実施形態では、この人間が判読可能な名称データチャンク６６０は、試験、診断、および／または他の適切な状況で使用するために、広告６５０を送信するデバイスについて短い識別情報を提供するために使用され得る、当該デバイスのために人間が判読可能な短い名称を提供する。ある状況では、単一のデバイスからの、および／または単一のネットワークにおけるいくつかの広告は、人間が判読可能な名称データチャンク６６０を含み得、ネットワークにおける他のメッセージおよび／またはデバイスは、人間が判読可能な名称データチャンク６６０なしで送信され得る。人間が判読可能な名称データチャンク６６０を含む広告（例えば広告６５０）において、人間が判読可能な名称データチャンク６６０は、長さフィールド６６２、ＡＤタイプフィールド６６４、および名称フィールド６６６を含む。長さフィールド６６２は、人間が判読可能な名称データチャンク６６０の長さを示す。ＡＤタイプフィールド６６４は、データチャンクが人間が判読可能な名称データチャンク６６０であることを示す値（例えば、０ｘ１６）を含み、受信側デバイスに人間が判読可能な名称データチャンク６６０の解釈方法を知らせる。名称フィールド６６６は、人間が判読可能なフォーマット（例えば、「ｔ２」）で送信側デバイスを識別するために使用され得る文字列を含む。いくつかの実施形態では、文字列は、ＵＴＦ−８またはその他の適切な文字符号化で表現されてもよい。
【０１５８】
広告６５０はまた、一般サービスデータチャンク６６８を含む。一般サービスデータチャンク６６８は、一般サービスデータチャンク６６８の長さを識別する長さフィールド６７０と、一般サービスデータチャンク６６８が一般サービスタイプであることを示す値（例えば０ｘ１６）を含むＡＤタイプフィールド６７２とを含む。一般サービスデータチャンク６６８はまた、一般サービスのための一般サービスＵＵＩＤ６７４を含む。いくつかの実施形態では、一般サービスデータチャンク６６８は、広告に含まれるネットワーク/デバイスデータについてのデータブロック長フィールド６７６も含む。言い換えれば、データブロック長フィールド６７６は、一般サービスＵＵＩＤ６７４および関連する全チャンクメタデータフィールド（例えば、長さフィールド６７０およびＡＤタイプフィールド６７２）以外の一般サービスデータチャンク６６８の長さを示す。いくつかの実施形態では、データブロック長フィールド６７６は、長さがデータブロック長フィールド６７６に含まれていない一般サービスデータチャンク６６８のフィールドが広告間においてサイズが一貫し得るため、省略することができる。
【０１５９】
一般サービスデータチャンク６６８はまた、データブロック長フィールド６７６（存在する場合）および後続のデータをデバイスおよび／またはその接続されたネットワークに関連するデータとして識別するデータブロックタイプフィールド６７８を含むことができる。
【０１６０】
一般サービスデータチャンク６６８はまた、広告６５０を受信するデバイスに広告６５０の解釈方法を知らせる符号化のバージョンを示すバージョン情報６８０を含む。いくつかの実施形態では、バージョン情報６８０は、メジャーバージョンフィールド６８２およびマイナーバージョンフィールド６８４を含む。メジャーバージョンフィールド６８２は、広告６５０フォーマットに実質的な更新が行われたときに増分される値（例えば１）を含むことができ、マイナーバージョンフィールド６８４は、広告６５０フォーマットに実質的な更新が少ないときに増分される値（例えば２）を含むことができる。メジャーバージョンフィールド６８２およびマイナーバージョンフィールド６８４に対する値は、バージョンの完全な指示（例えば、ｖ．１．２）を形成するよう組合されてもよい。いくつかの実施形態では、これらの値は、利用可能なバイトを使用して表現することができる任意の値であってもよい。例えば、各バージョンフィールドがバイトである場合、各バージョンフィールドは、サイクル前に０〜２５５の値を含むことができる。
【０１６１】
一般サービスデータチャンク６６８はまた、スマートネットワーク内においてデバイスを識別するために使用され得るデバイス識別子（ＩＤ）フィールド６８６を含む。一般サービスデータチャンク６６８は、デバイスクラス識別６８６も含む。デバイスクラス情報は、２つのサブフィールド、すなわちベンダーＩＤフィールド６８８および製品ＩＤ６９０を含むことができる。ベンダーＩＤフィールド６８８はデバイスに関するベンダーを示し、製品ＩＤ６９０はベンダー固有のデバイスのデバイスタイプを示す。一般サービスデータチャンク６６８は、前述したように、サービスペア設定ステータス６９２も含む。
【０１６２】
前述したように、いくつかの実施形態では、広告６５０は、広告パケットとスキャン応答パケットとの２つ以上のパケットに分割することができる。広告６５０が２つのパケットに分割される実施形態では、長さフィールド６５２、ＡＤタイプフィールド６５４、ＵＵＩＤのリストＢ４は、人間が判読可能な名称データチャンク６６０とともに広告パケットを形成する。広告６５０の図示された実施形態のフィールド長を使用する実施形態では、この広告パケットは１０バイトのサイズを有するであろう。このような実施形態では、スキャン応答パケットは、一般サービスデータチャンクからなり、２１バイトのサイズを有するであろう。
【０１６３】
２．警報を発令しているデバイスの例
図１５は、広告７００の一実施形態を示す。広告７００は、広告６５０のすべてのフィールドを含むが、広告７００は、広告デバイスが警報を発令している状態にあることを示すクリティカルイベントデータチャンク７０２を含む。さらに、広告７００が一般サービスデータチャンク６６８およびクリティカルイベントデータチャンク７０２を含む場合、ＵＵＩＤのリスト６５８は、広告７００において、広告６５０より長くてもよい。クリティカルイベントデータチャンク７０２は、クリティカルイベントデータチャンク７０２についての長さを示す長さフィールド７０４を含む。クリティカルイベントデータチャンク７０２はまた、クリティカルイベントデータチャンク７０２をクリティカルイベントデータチャンクとして識別する値（例えば０ｘ１６）を伴うＡＤタイプフィールド７０６を含む。クリティカルイベントデータチャンク７０２はまた、クリティカルサービスのためのＵＵＩＤを含むクリティカルサービスＵＵＩＤ７０８を含む。
【０１６４】
また、いくつかの実施形態では、クリティカルイベントデータチャンク７０２は、広告に含まれるクリティカルイベントデータのためのクリティカルイベント（ＣＥ）データブロック長フィールド７１０も含む。言い換えれば、ＣＥブロック長フィールド７１０は、チャンクメタデータフィールド（例えば、長さフィールド７０４およびＡＤタイプフィールド７０６）以外のクリティカルイベントデータチャンク７１０の長さを示す。いくつかの実施形態では、ＣＥデータブロック長フィールド７１０に長さが含まれないクリティカルイベントデータチャンク７０２のフィールドが広告間でサイズが一貫しているため、ＣＥデータブロック長フィールド７１０を省略することができる。クリティカルイベントデータチャンク７０２はまた、クリティカルイベントのタイプ（例えば、ハザード検出器からの警報イベント、セキュリティイベントなど）を示すクリティカルイベントタイプ７１２を含む。
【０１６５】
クリティカルイベントデータチャンク７０２はまた、クリティカルイベントデータチャンク７０２データをどのように解釈すべきかを示す警報イベント規格バージョン７１４を含む。クリティカルイベントデータチャンク７０２はまた、クリティカルイベントに関連する警報についての異議コードを含む警報異議７１６を含む。異議コードは、受信された解除がクリティカルイベントと実質的に同時に発生していることを検証することによって、その受信された解除が適時であることを検証するために使用される。異議コードは、４〜８オクテットのデータのような比較的小さいサイズを有する、警報時に生成されるランダム値であってもよい。次いで、受信側デバイスは、広告７００からこのコードを引き出し、異議コードを関連する解除メッセージに含める。例えば、解除メッセージは、異議値上で解除鍵を使用して署名されることができる（すなわち、異議値を解除鍵を使用して署名する）。警報を発令しているデバイスが異議コードおよび解除鍵が適切であると判断した場合、次いで、警報を発令しているデバイスは、警報が警報であること、エラーが発生したこと、または警報が非解除可能であること、または他の適切なステータスを示す応答メッセージを送信する。
【０１６６】
クリティカルイベントデータチャンク７０２はまた、クリティカルイベントデータチャンク７０２にいくつのクリティカルイベントが含まれているかを示すイベント数フィールド７１８を含む。クリティカルイベントデータチャンク７０２はまた、クリティカルイベントタイプ７１２に示される警報のタイプに特有の警報のサブタイプを示す警報タイプおよび警報状態フィールド７２０を含む。イベント数フィールド７１８が、１つより多いイベントがクリティカルイベントデータチャンク７０２に含まれていることを示す場合、クリティカルイベントデータチャンク７０２は、含まれる追加のクリティカルイベントごとに、追加の警報タイプおよび状態フィールド７２２を含む。
【０１６７】
警報タイプおよび警報状態フィールド７２０ならびに追加の警報タイプおよび状態７２２（含まれる場合）は、上記の表５および表６にて提供されるものと同様の値を含むことができる。
【０１６８】
広告７００が分割される実施形態では、長さフィールド６５２、ＡＤタイプフィールド６５４、ＵＵＩＤのリストＢ４、人間が判読可能な名称データチャンク６６０、およびクリティカルイベントデータチャンク７０２。広告７００の図示された実施形態のフィールド長を使用する実施形態では、広告パケットは２６バイトのサイズを有し、スキャン応答パケットは一般サービスデータチャンクからなり、２１バイトのサイズを有するであろう。
【０１６９】
Ｖ．ＢＬＥを使用した解除
図１６は、一実施形態による例示的なハザード検出システム１６１０および例示的なユーザデバイス１６２０のブロック図を示す。システム１６１０および１６２０の多くの異なるコンポーネントのほんのいくつかが、音響位置検証に関連する実施形態に議論の焦点を当てるよう議論される。システム１６１０は、コンポーネントの中で、とりわけ、ワイヤレス通信回路１６１２、マイクロホン１６１４、および超音波エミッタ１６１６を含むことができる。ユーザデバイス１６２０は、コンポーネントの中でもとりわけ、ワイヤレス通信回路１６２２、マイクロホン１６２４、および超音波エミッタ１６２６を含むことができる。ワイヤレス通信回路１６１２および１６２２は、システム１６１０とデバイス１６２０との間のワイヤレス通信を可能にするための任意の適切な回路であってもよい。例えば、回路１６１２および１６２２は、ブルートゥース低エネルギ（ＢＬＥ）通信、８０２．１１通信、および／または８０２．１５．４通信を行うことができる。マイクロホン１６１４および１６２４は、任意の適切なマイクロホンであってもよい。超音波エミッタ１６１６および１６２６は、高周波音響エネルギを放射することができる任意のデバイスとすることができる。例えば、エミッタ１６１６および１６２６はスピーカであってもよい。なお、図１６は、システム１６１０およびデバイス１６２０の両方が各々マイクロホンおよび超音波エミッタ有するのを示しているが、いくつかの実施形態は異なる構成を有してもよい。例えば、一実施形態では、システム１６１０はマイクロホンを有さなくてもよい。別の例として、ユーザデバイス１６２０は、超音波エミッタを有さなくてもよい。
【０１７０】
前述したように、スマートネットワークにおけるスマートデバイスは、スマートデバイス周辺の実世界の状況を追跡する様々なセンサを含む。例えば、スマートデバイスは、様々な状況の建物の居住者に警戒態勢をとらせるハザード検出、セキュリティデバイス、および／または他の監視デバイスを含むことができる。これらのデバイスは、クリティカルイベントの検出で警報を発令してもよい。例えば、図１７に示すように、スマートデバイス８００は、警報指示８０２を電子デバイス８０４に送信する。いくつかの実施形態では、電子デバイス８０４は、携帯電話、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、または警報表示８０２を受信し、解除要求８０６を送信することができる任意の他の電子デバイスを含むことができる。警報表示８０２は、ＢＬＥ広告のような比較的低い無線信号であってもよい。スマートデバイスはまた、検出されたイベントを示すために音波または視覚インジケータを提供することができる。しかしながら、いくつかの実施形態では、イベントが、イベントを意識している居住者によって観察されるとき、イベントが誤った警報であるとき、および/または警報がイベントを注意喚起することにおいてもはや役立たない場合のとき、警報は電子デバイス８０４からの解除要求を使用して解除されてもよい。
【０１７１】
いくつかの実施形態では、警報の原因または源を調査する試みが行われたことを確実にするために、解除を、スマートデバイス８００に対して予め定められた近接度内のデバイスに限定してもよい。さらに、後述するように、解除応答には、承認された個人だけが警報を解除する能力を有することを保証するいくつかのセキュリティ機能が含まれる。いくつかの実施形態では、無線による解除は、スマートデバイス８００によって監視されるセキュリティまたは安全性を損なうことなく、スマートデバイス８００に実際に物理的に接触することなく、スマートデバイス８００で警報を解除することを可能にする。いくつかの実施形態では、近接性検証は、電子デバイス８０４を使用してクリティカルイベントを引き起こす条件を検証してもよいネットワーク接続されたカメラを介して準備されてもよい。
【０１７２】
いくつかの実施形態では、警報指示８０８は、リモートサービス８１０に送信され、次いで電子デバイス８０４に中継されてもよい。これに加えて、またはこれに代えて、リモートサービス８１０は、ワイヤレスネットワークのためのアクセスポイントまたはルータで置き換えることができる。
【０１７３】
さらに、スマートデバイス８００は、ネットワーク８１４において他のデバイス８１２（例えば、ハザード検出器、温度計など）に警報および解除を伝搬することができる。ネットワーク８１４は、スマートデバイス８００と電子デバイス８０４（例えば、ＢＬＥ）との間の解除対話によって使用されるものとは異なるワイヤレス通信タイプ（例えば、８０２．１５．４）を含むことができる。
【０１７４】
特定の実施形態では、後述するように、警報指示８０２が受信される前に、リモートサービス８１０を介して警報指示８０８が受信されたとき、電子デバイス８０４は、リモートサービス８１０を介して解除が可能化されないという通知と共に警報の通知を表示してもよい。他の実施形態では、スマートデバイス８００への近接性が別の経路を介して検証され得るときにリモートサービス８１０（またはアクセスポイントもしくはルータ）を介して解除を可能にすることができる。例えば、電子デバイス８０４が、スマートデバイス８００からの電磁信号、音波信号または視覚信号を検出した場合。いくつかの実施形態では、ある警報種は、近接性検証なしでは非解除可能であり得るが、他の警報種は近接性検証に関係なく解除可能である。例えば、特定の実施形態では、煙報知器は遠隔接続からは非解除可能であり得るが、セキュリティ警報器は遠隔解除され得、なぜならば、遠隔ユーザは、セキュリティシステムのパスワードを持たない訪問者や、自動化された電子デバイス（例えば、清掃ロボット）による予定された動作のような、セキュリティ警報を引き起こすであろう条件を知っているからである。いくつかの実施形態では、警報の解除性は、警報の深刻度に基づいて変化し得る。例えば、警報がより低い優先度の「注意喚起」警告である場合、警報は解除されてもよいが、警報が実際のクリティカルイベントを示す場合、警報は解除されなくてもよい。
【０１７５】
いくつかの実施形態では、非解除可能警報で解除が試みられる場合、その警報は解除されずに、警報を発令しているリモートデバイスが解除されてもよい。言い換えれば、煙警報が屋根裏部屋から生じる場合、地下室のスマートデバイスが、屋根裏部屋における警報の通知（例えば、聴覚および／または視覚的指示）を送信してもよい。屋根裏部屋における非解除可能警報に対して解除が試みられる場合、地下室のスマートデバイスが解除されて、警報の通知の送信を止めてもよい。
【０１７６】
いくつかの実施形態では、スマートデバイスへの接続は、リモートサービス８１０にログインするために使用される電子デバイス８０４上のプログラムアプリケーションを使用することによって認証することができる。いくつかの実施形態では、電子デバイス８０４が警報指示８０２を受信したとき、電子デバイス８０４がスマートデバイスの管理に使用されるアカウントについて認証されたユーザとしてリモートサービス８１０にログインされていなければ、電子デバイス８０４はユーザインターフェイス（ＵＩ）から消音オプションを保留してもよい。それに加えて、またはそれに代えて、スマートデバイス８００は、スマートデバイス８００を管理するために使用されるアカウントについて電子デバイス８０４が認証されるまで、電子デバイス８０４への接続を遮断することができる。
【０１７７】
図１８は、電子デバイス８０４において発生し得る解除プロセス８２０のフローチャート図を示す。電子デバイス８０４は、スマートデバイス８００に対応するアカウント名およびパスワードを使用してリモートサービス８１０にログインする（ブロック８２２）。アカウントにログインすることにより、電子デバイス８０４は、スマートデバイス８００に対して認証することができる。例えば、いくつかの実施形態では、リモートサービス８１０は、電子デバイス８０４にシグネチャまたは鍵を提供して、アカウントが関係する任意の警報を発令しているデバイスに対して認証を行なうために使用され得るシグネチャを生成することができる。いくつかの実施形態では、シグネチャはアカウントパスワードから生成することができる。
【０１７８】
電子デバイス８０４は、スマートデバイスにおけるクリティカルな状態の指示を無線信号８０２で受信する（ブロック８２４）。例えば、電子デバイス８０４がクリティカルサービスを含むＢＬＥ広告を受信した場合、電子デバイス８０４は、その広告がスマートデバイス８００のクリティカルな状態の指示であると判断することができる。それに加えて、またはそれに代えて、電子デバイス８０４は、８０２．１１または８０２．１５．４ネットワークなどの１つまたは複数のネットワークを介してリモートサービス８１０を介して指示を受信することができる。さらに、いくつかの実施形態では、電子デバイス８０４は、電子デバイス８０４に無線信号８０２をスキャンさせるアプリケーションプログラムがアクティブであるとき、またはバックグラウンドで実行されているときにのみ、指示を受信する。したがって、そのような実施形態では、電子デバイス８０４がスマートデバイス８００を解除するよう準備されていないとき、電子デバイス８０４は電力消費を節約することができる。
【０１７９】
指示を受信したことに応答して、電子デバイス８０４は、クリティカルイベントが発生したという指示を表示する（ブロック８２６）。表示される画面は、指示に関するさまざまな情報に基づいて異なってもよい。例えば、電子デバイス８０４は、警報が解除可能であるかどうかを判定してもよい（ブロック８２８）。たとえば、深刻度のしきい値を超えた警報、および／または解除のしきい値数を超えて解除された警報。いくつかの実施形態では、解除性および／または非解除性を引き起こす要素が、ＢＬＥ広告に含まれてもよい。例えば、ＢＬＥ広告における広告された警報状態は、非解除可能な警報の指示を含むことができる。警報が解除可能でない場合、電子デバイス８０４は、表示された指示が電子デバイス８０４によって表示され続け得るが、解除プロセスを終結し得る（ブロック８３０）。さらに、表示された指示は、解除プロセスの終結に基づいて変化してもよい。たとえば、警報が解除可能でない場合、解除オプションが表示された指示から完全に欠落していてもよい。
【０１８０】
電子デバイス８０４が、警報が非解除可能であると判定しない場合、電子デバイス８０４は、電子デバイス８０４がスマートデバイス８００に近接しているかどうかを判定する（ブロック８３２）。例えば、いくつかの実施形態では、電子デバイス８０４がＢＬＥを介して指示を受信した場合、電子デバイス８０４は、スマートデバイス８００が近接閾値内における距離内にあると判定することができる。それに加えて、またはそれに代えて、スマートデバイス８００は、電子デバイス８０４とスマートデバイスとの間の近接性を検証するよう、電子デバイス８０４（またはスマートデバイス８００）によって使用され得る音波信号および／または光信号を送信することができる。例えば、そのような実施形態では、スマートデバイス８００は、電子デバイス８０４がスマートデバイス８００との通信において再生する超音波信号をブロードキャストしてもよい。近接性が確認された場合、電子デバイス８０４は解除オプションを提示する（ブロック８３６）。電子デバイスがブロードキャストされた音波信号を検出しない場合、またはスマートデバイス８００が、近接性に基づいて解除要求が拒否されたと応答する場合、電子デバイスは、電子デバイス８０４が解除のためにスマートデバイス８００に十分に近くないと判断してもよい。いくつかの実施形態では、近接性が確認されない場合、電子デバイス８０４は異なる画面を提示してもよい。例えば、解除オプションは、電子デバイス８０４を、スマートデバイス８００を解除する前にスマートデバイス８００に近づけるべきである、という通知としてグレーアウトされてもよい。
【０１８１】
例えば、いくつかの実施形態では、電子デバイス８０４は、図１９に示すように、警告画面９００を表示することができる。警告画面９００は、画面９００に注意を引くことを意図したアイコン９０２を含む。いくつかの実施形態では、アイコン９０２は、警報の深刻度を示すためにある色に変更された点滅リングを含む。さらに、電子デバイス８０４は、警告画面９００に注意を引くために、振動または音を発することができる。警告画面９００はまた、スマートデバイス８００によって検出されたクリティカルイベントのタイプを示す警報タイプ９０４を含む。警告画面９００はまた、クリティカルイベント、または警報に応答してどのような行動をとるべきか、に関する追加情報９０６を含むことができる。警告画面９００はまた、警報深刻度９０８を示す。例えば、警告画面９００は、１つまたは複数の注意喚起状態と１つまたは複数の警報レベル状態との間で区別することができる。警告画面９００はまた、クリティカルイベントを検出するスマートデバイス８００についての位置９１０を示す。警告画面９００はまた、警報に応答して予想される様々なアクションへのショートカットを提供するアクションバー９１２を含む。アクションバー９１２は、選択されると、クリティカルイベントおよび対応として取るべきアクションに関するより多くの情報を提供するティップスボタン９１４を含む。アクションバー９１２はまた、選択時に、電子デバイス８０４に、予め指定された連絡先に発信またはメッセージを送信させるコールボタン９１６を含む。アクションバー９１２はまた、警報消音ボタン９２０を含む。しかしながら、前述したように、警報が非解除可能な場合、警報消音ボタン９２０は画面から省略されてもよく、スマートデバイス８００と電子デバイス８０４との間の近接性が確認できない場合、警報消音ボタン９２０は、グレーアウトされるかまたは解除を行うためにデバイス同士を互いに近く移動させる必要があることを示してもよい。いくつかの実施形態では、グレーアウトされた警報消音ボタン９２０が選択された場合、電子デバイス８０４は、電子デバイス８０４をスマートデバイス８００に近づけるための明示的な指示を提示することができる。いくつかの実施形態では、警告画面９００の色は、警報の受信を示すように変更することができる。例えば、全クリアページは第１の色（例えば白）であり、警告画面９００は異なる色（例えば、黒または濃い灰色）を有してもよい。
【０１８２】
いくつかの実施形態では、警告画面９００を使用して複数の警報を提示することができる。このような実施形態では、位置９１０は、スマートネットワークにおいて各警報を発令しているデバイスついての位置（例えば、居間、キッチン、ガレージなど）を含むことができる。アイコン９０２は、各デバイス間の最高優先度警報に対応してもよい。したがって、様々な警報タイプが深刻度のレベルにおいて優先順位付けられ、最も高い深刻度の警報が位置９１０のリストの一番上に提示される。例えば、警報は、深刻度の高い順に優先順位を付けてもよい。すなわち、煙警報、一酸化炭素警報、注意喚起煙レベル通知、注意喚起一酸化炭素通知、およびその他の注意喚起通知である。
【０１８３】
図１８に戻って、警報を解除するとき、電子デバイス８０４は解除オプションの選択を受信する（ブロック８３８）。解除の選択を受信すると、電子デバイスは、図２０に示すように、解除確認画面９２２を提示することができる。解除確認画面９２２は、消音ボタン９２０が押された後に警報を解除する意図を確認する方法をユーザに指示する解除命令９２４を含む。例えば、解除命令９２４は、解除ボタン９２６を長押して、警報を解除することによって、解除を実行し得ることを指示する。いくつかの実施形態では、解除命令９２４は、警報を解除する意図を確認するための文字入力、バイオメトリック入力、ジェスチャ、ボタンクリック、および／または他の適切な入力による解除の確認など、確認方法に応じて異なる命令を与えることができる。例えば、確認がジェスチャを含む場合、ジェスチャは、任意の方向の単純なスワイプ、複数の動きを含む複合ジェスチャ、指の数と関連するジェスチャとの組み合わせ、またはそれらの何らかの組み合わせとすることができる。確認画面９２２はまた、警報タイプに関連する安全命令のような、警報を消音することに加えてとられるかもしれないアクションに関する追加命令９２８を含むことができる。例えば、煙警報が発生している場合は、追加命令は、火災時には低い姿勢を維持し、扉を開ける前には熱に気をつけるよう命令を含み得る。確認画面９２２はまた、解除が過失であったかまたはもはや望まれてはいないことを示す機構を提供するキャンセルボタン９３０を含む。
【０１８４】
図２１は、ボタン長押し中における解除ボタン９２６の変化を示す確認画面９２２の実施形態を示す。図示されているように、解除ボタン９２６は、解除ボタン９２６が長押しされると色が変化するリング９３２を含む。言い換えれば、リング９３２は、解除ボタン９２６がどれくらい長く長押しされているか、および解除が確認される前にどれくらいより長く長押しされることになるかに関するフィードバックを提供する。いくつかの実施形態では、リング９３２は、解除ボタン９２６が長押しされると色が変わる番号（例えば、２，３，４，５またはそれ以上）の弧に分割されてもよい。例えば、４つの弧があり、長押し持続時間が２秒の場合、各弧は０．５秒のボタン長押しに対応する。さらに、図示されているように、いくつかの実施形態では、弧は暗色から淡色に徐々に変化してもよい。したがって、図示の実施形態では、リング９３２は、２つのより明るい色または輝度の弧９３４、中間色または輝度の弧９３６、およびより暗い色または輝度の弧９３８を含む。本実施形態によれば、解除ボタン９２６は、解除確認期間の５０％〜７５％の間において、長押しされている。ボタンが押されたことが確認されると、電子デバイス８０４は、図２２に示す消音スクリーン９４０のような消音スクリーンを提示することができる。消音スクリーン９４０は、解除の試みが進行中であるという視覚的な解除インジケータ９４２を含む。例えば、視覚的な解除インジケータ９４２は、解除の試みが進行中であることを示す回転リングを含む。いくつかの実施形態では、消音スクリーン９４０は、解除の試みが進行中であることを示すテキストインジケータ９４４を含む。いくつかの実施形態では、テキストインジケータ９４４および／または視覚的解除インジケータ９４２は、電子デバイス８０４が解除の試みをタイムアウトするまでの時間量を反映するカウントダウンを含むことができる。
【０１８５】
図１８に戻って、解除が確認されると、電子デバイス８０４は、スマートデバイス８００から受信した無線信号に基づいてスマートデバイス８００への接続を確立する（ブロック８４０）。スマートデバイス８００がＢＬＥ広告を使用して電子デバイス８０４にクリティカルイベントを示す実施形態では、電子デバイス８０４は、ＢＬＥ広告を使用してスマートデバイス８００とＢＬＥペアリングを確立する。
【０１８６】
ワイヤレス接続を介して、電子デバイス８０４は、警報を発令しているスマートデバイス８００に解除要求を送信する（ブロック８４２）。いくつかの実施形態では、解除要求を送信することは、近接性検証および認証検証も含む。具体的には、前述したように、スマートデバイス８００は、受信したクリティカルな状態の指示の一部として異議コードを受信する。サービス８１０から検索された事前共有鍵を使用して、電子デバイス８０４は、解除シグネチャを生成し、事前共有鍵を使用して異議コードに署名する。電子デバイス８０４およびスマートデバイス８００の両方が解除シグネチャを生成するので、スマートデバイス８００は解除シグネチャを検証し、それを用いて電子デバイス８０４を認証し、電子デバイス８０４の近接性を検証してから、解除要求を承認することができる。
【０１８７】
次いで、電子デバイス８０４は、スマートデバイス８００から解除の試みのステータスを示す応答を受信する（ブロック８４４）。次に、電子デバイス８０４は、警報が解除されたかどうかを判定する（ブロック８４６）。警報が解除された場合、電子デバイス８０４は解除結果を表示してもよい（ブロック８４８）。
【０１８８】
図２３は、解除要求の成功または失敗を示すために使用され得る例示的な結果画面９５０を示す。図示の実施形態では、結果画面９５０は、解除ステータスインジケータ９５２およびテキストによる解除ステータスインジケータ９５４によって示されるように、成功した解除を示す。解除が成功しなかった実施形態では、結果画面９５０は、「ｘ」が省略された解除ステータスインジケータ９５２を使用して、解除が発生しなかったことを示してもよい。同様に、テキストによる解除ステータスインジケータ９５４は、「警報は消音されていない。」と記してもよい。いくつかの実施形態では、結果画面９５０は、クリティカルイベントが終了していない場合に解除が終了して警報が再開するまでの期間を列挙するなど、次に起こり得ることを記す追加のテキストを含むことができる。
【０１８９】
図１８に戻って、解除が成功裡に完了していない場合、電子デバイス８０４はブロック８２８に戻り、解除を再試行する。いくつかの実施形態では、解除の試みが失敗した場合、または警報が解除可能閾値を超えた場合、警報は非解除可能としてマークされてもよい。たとえば、煙が多いと、警報が非解除可能になってもよい。したがって、いくつかの実施形態では、スマートデバイスによって様々な煙レベル閾値を使用することができる：煙レベルをより綿密に追跡するためにサンプリング期間を増加させる比較的低い監視／保持レベル、相対的な優先順位レベル警報を引き起こす１つまたは複数のより高い注意喚起煙レベル、より高い優先順位警報を引き起こす、より高い煙レベル、および警報を非解除可能にする、さらにより高い煙レベルである。上記の例は煙レベルに関するものであるが、スマートデバイス８００は、スマートデバイス８００が行う任意の測定の様々なレベルに対する上昇する反応のレベルを有してもよい。
【０１９０】
解除が成功裡に完了した場合、電子デバイス８０４は、スマートデバイス８００への接続がスマートデバイスによってまだ閉じられていない場合には、スマートデバイス８００への接続を閉じる（ブロック８５０）。ＢＬＥ接続を閉じることによって、スマートデバイス８００は、例えば、解除済または警報を発令していないなど、更新された警報ステータスで広告を再開することができる。次いで、電子デバイス８０４は、更新された警報状態を受信する（ブロック８５２）。いくつかの実施形態では、更新された広告に基づいて、電子デバイスは、図２４に示されるように、警告画面９００を更新することができる。例えば、警報が解除されたという指示を受信した後、警告画面９００は、警報消音ボタン９２０をグレーアウトしてもよく、位置９１０には、解除の成功または失敗を示す警報のステータス９５６を付加してもよい。
【０１９１】
図２５Ａおよび図２５Ｂは、スマートデバイス８００によって実行され得るプロセス９６０を示す。スマートデバイス８００の動作中、スマートデバイス８００は、定期的な間隔でワイヤレス接続のための広告をブロードキャストする（ブロック９６２）。例えば、スマートデバイス８００は、ＢＬＥ、ＷｉＦｉ、および/または何らかの他のネットワークプロトコルのための広告をブロードキャストすることができる。さらに、スマートデバイス８００は、警報状態に基づいて定期的にこのメッセージを断続的にブロードキャストすることができる。例えば、警報状態がアイドル状態である（すなわち、アクティブに警報を発令していない）場合、スマートデバイスは、広告をデフォルトレート（例えば、０．５秒に１回）でブロードキャストすることができる。警報状態がある警報状態にある場合、スマートデバイス８００は、警報レート（例えば、４０ｍｓごとに１回）でブロードキャストしてもよく；警報状態が解除された場合、スマートデバイス８００は、デフォルトレートよりも高いが警報レートよりも低い解除済レート（例えば、１／４秒に１回）で関連する広告をブロードキャストしてもよい。いくつかの実施形態では、解除済レートはデフォルトレートと同じであってもよい。言い換えれば、解除された状態に対応する広告は、警報を発令していない状態に対応する広告と同じくらいの頻度で送信されるであろう。
【０１９２】
スマートデバイス８００の機能の一部として、スマートデバイス８００は、クリティカルイベントが発生したかどうかを判定する（ブロック９６４）。クリティカルイベントが発生していない場合、スマートデバイス８００は、接続のために広告をブロードキャストし続けながら、そのようなイベントをスキャンし続ける。以下により詳細に説明するように、クリティカルイベントが検出された場合、スマートデバイス８００は、その警報状態を、警報発令状態に更新する（ブロック９６６）。警報発令状態への更新の一部として、スマートデバイス８００は、先に論じられたクリティカルイベントデータチャンク７０２のクリティカルイベントサービスＵＵＩＤ７０８および他の部分を、それらに関連付けられる、警報タイプおよび深刻度のようなフィールドに対する適切な値とともに含むように、スマートデバイス８００の広告を更新する。警報状態を更新することは、クリティカルイベントをスマートデバイス８００の周囲の領域に示すために可聴信号または視覚的信号をブロードキャストすることを含むこともできる。例えば、スマートデバイス８００は、周期的にブザーを鳴動させ、および／またはクリティカルイベントの性質を示す音声メッセージを再生することができる。
【０１９３】
また、スマートデバイス８００が、このクリティカルイベントの発生に対して警報異議をまだ生成していない場合、スマートデバイス８００は、任意の解除要求の適時性を保証するために使用される異議コード７１６を生成する（ブロック９６８）。前述したように、警報異議７１６は、クリティカルイベントの検出時またはその近くで生成され、クリティカルイベントに応答して受信された解除要求が、クリティカルイベントの検出に近く間に合って送信されたことを認証するために使用される、ランダムに生成される値を含むことができる。
【０１９４】
更新された警報状態および新たに含まれるクリティカル状態データチャンク７０２を含む更新された広告を使用して、スマートデバイス８００は更新された広告を警報レートでブロードキャストする（ブロック９７０）。スマートデバイス８００はまた、スマートデバイス８００に対して解除が可能化されるかどうかを判定する（ブロック９７２）。いくつかの実施形態では、解除は、一般的に、スマートデバイス８００について、スマートデバイス上のユーザインターフェイスを介して、一般的なルールとしてデバイスのデバイスタイプに基づいて、デバイスの位置に基づいて、またはそれらの何らかの組み合わせに基づいたユーザインタフェースを介して、不能化または可能化されてもよい。特定の実施形態では、スマートデバイス８００は、スマートデバイス８００に対して解除が不能化されることを示してもよい（したがって、電子デバイス８０４に、クリティカルイベントの検出通知を表示するユーザインタフェース（たとえば警告画面９００）において、解除を不能化および／または隠蔽させてもよい）。スマートデバイス８００に対して解除が可能化されない場合、この警報については解除プロセス９６０を終了させるが、ブロック９６４において、新しいクリティカルイベントの検出で、またはスマートデバイス８００が解除可能になると、解除プロセス９６０は再開してもよい。
【０１９５】
次に、スマートデバイス８００は、解除要求が受信されるのを待つ（ブロック９７４）。解除要求が受信されると、スマートデバイス８００は、警報が解除可能であるかどうかを判定する（ブロック９７６）。いくつかの実施形態では、特定の警報に対する解除は、警報のタイプ、警報の深刻度、以前の警報解除、またはそれらの何らかの組合せに基づいて、不能化または可能化され得る。特定の実施形態では、スマートデバイス８００は、スマートデバイス８００に対して解除が不能化されることを示してもよい（したがって、電子デバイス８０４に、クリティカルイベントの検出通知を表示するユーザインタフェース（たとえば警告画面９００）において、解除を不能化および／または隠蔽させてもよい）。いくつかの実施形態では、警報に対して解除が可能化されない場合、スマートデバイス８００は、警報が解除可能ではないため、電子デバイス８０４に警報解除エラーを報告する応答を送信する（ブロック９７８）。いくつかの実施形態では、警報に対して解除が可能化されない場合、この警報については解除プロセス９６０を終了させるが、ブロック９６４において、新しいクリティカルイベントの検出で、または警報が解除可能になると、解除プロセス９６０は再開してもよい。たとえば、警報の深刻度が低下すると、警報は解除可能になってもよい。
【０１９６】
スマートデバイス８００が解除を可能化され、警報が解除可能である場合、スマートデバイス８００は、さらに、スマートデバイス８００がスマートデバイス８００の閾値距離内にあるかどうかを判定する（ブロック９８０）。例えば、スマートデバイス８００は、解除要求がＢＬＥまたは既知の範囲を伴う別のワイヤレス接続プロトコルを介して受信されたとき、スマートデバイス８００が閾値距離内にあると判断することができる。追加的または代替的に、スマートデバイスは、電子デバイス８０４が解除要求内に含み、電子デバイス８０４がスマートデバイス８００の閾値距離（例えば音波域または視覚域）内に有ることを判断するためにスマートデバイス８００が用いることができる、音波（例えば超音波）または視覚的（例えば赤外線）信号をブロードキャストしてもよい。加えて、または代替え的に、ある実施形態では、ワイヤレス通信、地理空間追跡（例えば、全地球測位システム位置）、様々な電磁場（例えば、ＲＦＩＤ、ＮＦＣ）の検出、またはクリティカルイベントが監視されたかもしれない場所から警報が不能化されることを保証するために使用され得る他の方法のための信号レベルの強度を使用して近接性を判定することができる。
【０１９７】
電子デバイス８０４がスマートデバイス８００の範囲内にあると判定された場合、スマートデバイス８００はまた、解除が承認されているかどうかを判定する（ブロック９８４）。いくつかの実施形態では、近接性検証および承認検証を組み合わせて単一のステップにすることができる。例えば、前述したように、解除要求は、異議コード７１６とリモートサービスを介して共有されたスマートデバイス８００および電子デバイス８０４の事前共有鍵とを使用して生成された解除シグネチャを含む。スマートデバイス８００および電子デバイス８０４は各々、異議コード７１６および事前共有鍵へのアクセスを有し、各々、シグネチャを生成する。いくつかの実施形態では、スマートデバイス８０４は、事前共有鍵を使用してシグネチャが適切な暗号化を含むが、シグネチャが正しい異議コードに署名されていない、と判断してもよい。例えば、事前共有鍵がヌル異議コードまたは古い異議コードを使用するシグネチャを生成するために使用される場合、スマートデバイス８００は、古い異議コードを使用して生成された１つまたは複数の古いシグネチャのコピーと、比較のために使用するヌルコードで生成されたシグネチャのコピーとを維持してもよい。これらのシグネチャのうちの１つが、電子デバイス８０４から受信した解除シグネチャと一致する場合、スマートデバイス８００は、近接性非承認エラーで応答してもよい。シグネチャが期待されるどのシグネチャとも一致しない場合、スマートデバイス８００は、電子デバイス８０４にシグネチャエラーで応答する（ブロック９８６）。いくつかの実施形態では、スマートデバイス８００は、解除性エラー、近接性エラー、またはシグネチャエラーを送信した後に、別の解除応答を待ってもよい。
【０１９８】
警報が解除可能であり、シグネチャが検証確認された場合、スマートデバイス８０２は、警報を解除する（ブロック９８８）。いくつかの実施形態では、スマートデバイス８００は、スマートネットワークにおいて他のスマートデバイスに接続され、クリティカルイベントが検出されたときにそれらに警報を発させる。このような実施形態では、スマートデバイス８００が警報を局所的に解除すると、スマートデバイス８００は、スマートネットワークにおいて警報を発令している他のデバイス８００に解除を伝搬する（ブロック９９０）。特定の実施形態では、解除伝搬の開始は、クリティカルイベントを検出することによって警報を発令した発令元デバイスに限定される。したがって、このような実施形態では、電子デバイス８０４の発令元デバイスに対する近接性検証を確実にすることにより、クリティカルイベントを引き起こす状況の全体が視覚的に調査され得るときに解除が要求されることが保証される。さらに、前述したように、スマートデバイス８００は、通信が行なわれ得る少なくとも２つのワイヤレスインターフェイスプロトコルを含む。いくつかの実施形態では、以下に説明するように、解除要求は第１のワイヤレス接続タイプ（例えばＢＬＥ）を介して受信され得、解除は第２のワイヤレス接続タイプ（例えば８０２．１５．４）を介して伝搬され得る。
【０１９９】
解除を伝搬することに加えて、スマートデバイス８００は、解除が成功裡に完了したことを示す解除応答を送信する（ブロック９９２）。いくつかの実施形態では、解除応答が送信されると、スマートデバイス８００は、解除要求が受信された接続を閉じる（ブロック９９４）。言い換えれば、電子デバイス８０４とスマートデバイス８００との間のワイヤレス接続が、接続広告（例えばＢＬＥ）を中止するペア接続である実施形態では、スマートデバイス８００が前述のように接続広告を使用して複数のデバイスにその警報状態を通信できるように、ワイヤレス接続が閉じられる。特定の実施形態では、解除応答が、スマートデバイス８００によって送信される、および／または電子デバイス８０４によって受信されると、スマートデバイス８００および／または電子デバイス８０４によって接続が閉じられる。
【０２００】
解除プロセスの一部として、承認された解除を受信した後、スマートデバイス８００は、そのワイヤレス接続広告を警報解除広告に更新する（ブロック９９８）。例えば、クリティカルサービスデータチャンク７０２は、警報が広告に示されたことを示すように更新される。スマートデバイス８００はまた、広告周期を、警報レートから、いくつかの実施形態ではデフォルトレートと同じである解除済みレートに変更する（ブロック１００２）。スマートデバイス１００２は、解除タイマが経過するまで待機し続ける（ブロック１０００）。言い換えると、解除は、制限された有効期間（例えば１分）を有し、その後、解除は停止する。解除タイマが経過した後、スマートデバイス８００は、クリティカルイベントがまだ検出されるかどうかを判定する（ブロック１００４）。クリティカルイベントがもはや有効でない場合、この警報については解除プロセス９６０は終了しても、別のクリティカルイベントが検出されたときにプロセスが再び開始してもよい。現在の警報については解除プロセス９６０は終了しているが、スマートデバイス８００が現在警報を発令している、他のアクティブな警報がある場合がある。クリティカルイベントがまだ有効である場合、スマートデバイス８００は警報を解除しない（ブロック１００６）。いくつかの実施形態では、警報を解除しないことは、警報が現在非解除可能であることを示すことを含むこともできる。言い換えれば、そのような実施形態では、各警報は一度だけ解除されてもよい。特定の実施形態では、スマートデバイス８００は、各警報について解除カウンタを保持し、解除カウンタが解除制限閾値を超えたときに警報を非解除可能として設定することができる。
【０２０１】
図２６は、スマートデバイス８００について現在の状態を判定するために使用され得る状態マシン１０１０を示す。前述したように、デフォルト状態の間、スマートデバイス８００は、スマートデバイス８００に関する一般情報をデフォルトレートで与えるワイヤレス通信タイプ（例えばＢＬＥ）広告をブロードキャストすることができる。いくつかの実施形態では、スマートデバイス８００は、ワイヤレス通信タイプを介してワイヤレス接続を遮断する。スマートデバイス８００は、デフォルト状態１０１２で開始する。イベントが検出されると、スマートデバイスは警報発令状態１０１４に移行する。前述したように、スマートデバイス８００が警報発令状態１０１４にあるとき、スマートデバイス８００は、デフォルト状態１０１２にある広告頻度よりも高いレートでワイヤレス通信タイプを介して警報情報（例えば、クリティカルイベントＵＵＩＤなど）を含む広告をブロードキャストする。さらに、警報発令状態１０１４において、スマートデバイス８００は、ワイヤレス通信タイプを介した接続が解除要求を受信することを可能にすることができる。いくつかの実施形態では、スマートデバイス８００は、伝搬通信タイプ（例えば、８０２．１５．４）を使用してスマートネットワークにおいて他のデバイスに警報の通知をブロードキャストすることもできる。警報発令状態１０１４から、イベントが終了すると、スマートデバイス８００はデフォルト状態１０１２に戻る。
【０２０２】
いくつかの実施形態では、スマートデバイス８００は、イベントが進行中であるかどうかをスマートデバイス８００が判定する保持状態または監視状態などの中間状態を経て遷移する。保持状態は、警報を発令するイベントが発生したかどうかをスマートデバイス８００が判定することを可能にするために、測定値が警報閾値（例えば、警報閾値または注意喚起閾値）に近づくと、より速いレートでデータをサンプリングするために使用される前期警報状態を含むことができる。監視状態は、測定値が上昇するが警報閾値を下回るときに、より速いレートでデータをサンプリングするために使用される後期警報状態を含むことができる。イベントがまだ進行中である、とスマートデバイスが判断した場合、スマートデバイス８００は、保持状態もしくは監視状態から復帰し、および／または警報発令状態１０１４にとどまる。警報発令状態１０１４にある間、スマートデバイス８００は、有効な解除要求を受信してもよい。警報が非解除可能である場合、スマートデバイス８００は警報発令状態１０１４のままであるが、スマートデバイス８００は依然として伝搬通信タイプを介してスマートネットワークにおいて他のデバイスに解除を伝搬してもよい。例えば、いくつかの実施形態では、スマートデバイス８００は、スマートデバイス８００で警報が解除されない場合であっても、ＢＬＥを介して解除要求を受信し、スマートネットワークにおいて他のデバイスに、８０２．１５．４ネットワーク接続を介して、および／または８０２．１１ネットワーク接続を介して、解除を伝搬することができる。警報が解除可能であり、有効な解除が受信される場合、スマートデバイス８００は、警報を解除し、解除状態１０１６に遷移してもよい。
【０２０３】
解除状態１０１６において、スマートデバイス８００は、警報が現在であるが解除されているという指示と共に、ワイヤレス通信タイプのための接続をブロードキャストする。いくつかの実施形態では、解除状態の広告ブロードキャスト頻度は、警報発令状態１０１４の広告ブロードキャスト頻度よりも低い頻度である。特定の実施形態では、解除状態１０１６の広告ブロードキャスト頻度は、デフォルト状態１０１２と同じ頻度またはそれより高い頻度である。前述したように、いくつかの実施形態では、スマートデバイス８００は、解除状態１０１６内に、限られた期間の間、留まるだけである。いくつかの実施形態では、解除期間が終了し、クリティカルイベントが依然として存在する場合には、スマートデバイス８００は警報発令状態１０１４に戻る。そうでなければ、スマートデバイス８００はデフォルト状態に戻る。いくつかの実施形態では、スマートデバイスは、保持状態を通過してから、デフォルト状態１０１２に戻る。追加的または代替的に、特定の実施形態では、スマートデバイス８００は、デフォルト状態１０１２に戻ってから、クリティカルイベントが存在するかどうかを判定する。このような実施形態では、クリティカルイベントが残っている場合、スマートデバイス８００は、デフォルト状態１０１２から警報発令状態１０１４に遷移する。
【０２０４】
上述したように、ユーザは、自分のユーザデバイスと対話することによって、煙警報器または他のデバイスを遠隔解除することができる。例えば、警報が鳴動した場合、ハザードデバイスは、ワイヤレス通信回路を介してユーザデバイスに警告してもよく、ユーザは、警報を解除するためにユーザ選択可能なオプションを有するユーザインターフェイス画面を提供されてもよい。ユーザが警報を解除するためにそのオプションを選択すると、ユーザデバイスは、その命令をワイヤレス通信回路を介してハザードデバイスに返信してもよい。しかしながら、さまざまな規制に従うため、解除コマンドは、ユーザデバイスがハザードデバイスから一定の距離内にある場合にのみ実行できる。これは、ユーザが仕事で留守の間、ユーザの家で警報を解除できないようにするためである。さらに、ワイヤレス通信回路を介して通信される信号は、実質的な範囲（例えば、ハザード検出器を有する構内の境界を越えて延びる範囲）を有することができるので、超音波信号が、ユーザの位置を検証するべく、本明細書で説明する実施形態に従って使用される。
【０２０５】
本明細書で論じられる実施形態によって使用される超音波信号は、人間の聴覚の範囲を超えて存在してもよい。これらの周波数範囲で動作させることにより、ハザードデバイスとユーザデバイスとが、それらデバイスを含む構内の居住者を煩わせることなく、通信することが可能になる。例えば、超音波信号は、１８．５ｋＨｚ以上の周波数で送信されてもよい。いくつかの実施形態では、超音波周波数は、２０ｋＨｚまたは２２ｋＨｚであり得る。超音波周波数は、１８ｋＨｚと２２ｋＨｚの間の範囲内に存在してもよい。超音波周波数の上限は、ハザードデバイスおよび／またはユーザデバイスに存在する超音波エミッタ（またはスピーカ）によって制限されてもよい。
【０２０６】
超音波信号は、距離をわたって比較的速く減衰し、壁、床などを容易に通過しない。これには、図２７に示すように、警報を遠隔で解除するために、ユーザをハザードデバイスの見通し線内にいるよう強いるという有利な点がある。図２７は、キッチン内に配置されたハザードデバイス２７１０と、図示されている様々な場所に配置されたユーザデバイス２７２０〜２７２３とを有する家屋の平面図を示す。一様な破線は、デバイス２７１０とユーザデバイス２７２０〜２７２３のうちの任意の１つとの間で通信される無線信号を表すことができる。一点鎖線は、デバイス２７２０〜２７２３によって放射される超音波信号を表すことができる。図示のように、各ユーザデバイスは、無線信号を介してハザードデバイス２７１０と通信することができる。しかしながら、すべてのユーザデバイスがハザードデバイス２７１０に超音波信号を送信することができるわけではない。家屋の外に位置するユーザデバイス２７２０は、それが放射した超音波信号で家屋の外壁を貫通することはできない。家族部屋に位置するユーザデバイス２７２１も、それが放射した超音波信号で内壁を貫通することはできない。キッチンに隣接し、ハザードデバイス２７１０の見通し線内にある部屋に位置するユーザデバイス２７２２は、それが放射した超音波信号が受信されるにはハザードデバイス２７１０から離れすぎている。キッチン内に配置され、ハザードデバイス２７１０の見通し線内に位置するユーザデバイス２７２３は、それが放射した超音波信号をハザード検出デバイス２７１０に伝達することができる。
【０２０７】
いくつかの実施形態では、超音波信号は、任意の適切なデータで符号化することができる。例えば、データは、デバイスＩＤおよび／または部屋ＩＤを識別する識別情報を含むことができる。データは、解除命令などの命令を含むことができる。超音波信号は、擬似ランダム非繰り返しパターンとして放射することができる。信号は、４ビット符号を含むことができ、または８ビット符号で送信するために連結することができる。
【０２０８】
図２８は、一実施形態による例示的な音響データエンコーダ２８００を示す。エンコーダ２８００は、線形フィードバックシフトレジスタ（ＬＦＳ）２８１０、アップサンプラ２８１２、搬送正弦波発生器２８２０、データ波発生器２８３０、乗算器２８４０、ハイパスフィルタ２８５０、及び出力２８６０を含むことができる。エンコーダ２８００は、出力２８６０によって放射される超音波信号にデータを組み込むために搬送波周波数において振幅変調を使用する。キャリア周波数（ＸＨｚとして示す）は、搬送正弦波発生器２８２０によって設定され、乗算器２８４０に与えられるＬＦＳＲ２８１０およびアップサンプラ２８１２は、ランダムノイズを乗算器２８４０に注入するように機能する。データは、データ波発生器２８３０に供給され、データ波発生器２８３０は、データを乗算器２８４０に送る。乗算器２８４０は、ノイズ、搬送波周波数およびデータを一緒に混合し、結合された信号をハイパスフィルタ２８５０に与え、ハイパスフィルタ２８５０はその信号をフィルタ処理し、信号はその後出力２８６０によって放射される。
【０２０９】
図２９は、一実施形態による、ハザード検出システムによる検出のためにユーザデバイスが超音波信号を放射する例示的なプロセス２９００を示す。図２９は、ハザード検出システムおよびユーザデバイスによってそれぞれ実行されるステップを半分に分割して示している。プロセス２９００は、ステップ２９０２で開始することができ、ハザード検出デバイスは警報イベント（例えば、煙警報、ＣＯ警報、または前期警報警報）を検出する。ステップ２９０４で、検出された警報イベントをデバイスに警告するために無線信号を送信することができる。無線信号は、ユーザデバイスに警告するためのＢＬＥ信号、ＷｉＦｉ信号、または６ＬＯＷＰＡＮ信号であり得る。ステップ２９０６において、ユーザデバイスは無線信号を受信することができる。無線信号の受信に応答して、ユーザが無線信号をハザード検出に送信することを可能にするユーザインターフェイスを表示することができる（２９０７）。例えば、ユーザインターフェイスは、（例えば、図ＸＸのような）警報を解除するためのオプションを提供することができる。ステップ２９０８において、無線信号を送信するためのユーザコマンドを受信することができる。
【０２１０】
ステップ２９１０において、ユーザデバイスは無線信号を送信することができる。ステップ２９１２において、ユーザデバイスは、超音波信号を放射することができる。いくつかの実施形態では、ユーザデバイスは、同時に、超音波信号を放射し、無線信号を送信することができる。他の実施形態では、ユーザデバイスは、無線信号を送信するためのユーザコマンドが受信された後、または無線信号がハザード検出デバイスから受信された後、定期的な間隔で超音波信号を放射することができる。
【０２１１】
ステップ２９１４において、ハザード検出デバイスは、ユーザデバイスから無線信号を受信することができる。ハザード検出デバイスは、ステップ２９１６として、超音波信号が検出されたか否かを判定することができる。ステップ２９１６における判定がＮＯである場合、プロセス２９００はステップ２９１４に戻ることができる。ステップ２９１６の判定がＹＥＳである場合、ハザード検出デバイスは、ステップ２９１８に示すように、受信した無線信号の肯定応答をユーザデバイスに送信することができる。ステップ２９２０において、ユーザデバイスによって放射されている超音波信号を同時に検出しながら、（ユーザデバイスからの）無線信号の受信に応答して、あるアクションを実行することができる。実行されるアクションは、例えば、鳴動警報の消音であり得る。
【０２１２】
ステップ２９２２において、ユーザデバイスは、肯定応答がハザード検出デバイスによって受信されたか否かを判定することができる。判定がＮＯの場合、プロセス２９００はステップ２９１０に戻ることができる。判定がＹＥＳである場合、ユーザデバイスは無線信号の送信を中止し、超音波信号の放射を中止することができる（２９２４）。
【０２１３】
図２９に示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。
【０２１４】
図３０は、一実施形態による、ハザード検出デバイスが超音波信号を放射し、ユーザデバイスが超音波信号の存在を監視する、例示的なプロセス３０００を示す。図３０は、ハザード検出システムおよびユーザデバイスによってそれぞれ実行されるステップを半分に分割して示している。プロセス３０００は、ステップ３００２で開始することができ、ハザード検出デバイスは警報イベント（例えば、煙警報、ＣＯ警報、または前期警報警報）を検出する。ステップ３００４で、検出された警報イベントをデバイスに警告するために無線信号を送信することができる。ステップ３００６において、ハザード検出デバイスは、超音波信号を放射する。
【０２１５】
ステップ３００８において、ハザード検出デバイスによって放射された無線信号は、ユーザデバイスによって受信される。その無線信号の受信に応答して、ステップ３０１０において、ユーザデバイスは、ユーザが無線信号を介してハザード検出デバイスにコマンドを送信することを可能にするユーザインターフェイスを表示する。ステップ３０１２において、無線信号を介して命令を送信するためのユーザコマンドを受信することができる。ステップ３０１４において、ハザード検出デバイスが放射している超音波信号を検出したかどうかの判定が行われる。判定がＮＯである場合、ユーザデバイスは、ステップ３０１６において、ハザード検出システムの見通し線内を移動するようにユーザに指示してもよく、次いでプロセス３０００はステップ３０１４に戻る。判定がＹＥＳである場合、ユーザデバイスは、ステップ３０１８で、ユーザが開始した命令で無線信号を送信することができる。
【０２１６】
ステップ３０２０において、無線信号がユーザデバイスから受信される。ステップ３０２２において、無線信号を受信したことに応答して、あるアクションが実行される（例えば、ブザーの解除）。
【０２１７】
図ＤＤに示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。
【０２１８】
図３１は、一実施形態による、データを超音波信号に符号化し、データを超音波信号から復号化するための、例示的なプロセス３１００を示す。図３１は、超音波信号の送信機と超音波信号の受信機とをそれぞれ半分に分割して示している。最初に送信機について説明する。ステップ３１１０から開始して、データを、振幅変調された搬送波信号に符号化することができる。例えば、図ＣＣのエンコーダを用いてデータを音響信号に符号化することができる。ステップ３１１２において、符号化されたデータ信号をスピーカに与えることができ、スピーカは、符号化されたデータ信号を音響信号として放射する。次に受信機について説明する。ステップ３１２０において、音響信号を受信することができる。ステップ３１２２において、受信された音響信号が復号され、そこで符号化されたデータが得られる。ステップ３１２４で、データが処理され、適切なアクションがとられる。
【０２１９】
図３２は、ある実施形態に従って、飛行時間計算が、ハザード検出デバイスに対するユーザデバイスの位置を判定するために使用される、例示的なプロセス３２００を示す。図３２は、開始側によって実行されるステップおよび応答側によって実行されるステップを示すために、半分に分割される。したがって、一実施形態では、開始側はハザード検出デバイスであり得、応答側はユーザデバイスであり得、別の実施形態では開始側はユーザデバイスであり得、応答側はハザード検出デバイスであり得る。
【０２２０】
ステップ３２１０から開始して、第１の音響信号が、第１の期間で開始側によって放射され得る。第１の音響信号は、超音波信号であってもよい。ステップ３２１２において、応答側は、例えば、マイクロホンを介して、第１の音響信号を受信することができる。ステップ３２１４において、応答側は、第１の信号の受信に応答して、第２の音響信号を送信することができる。第２の音響信号は、ステップ３２１６で第２の期間で受信することができる。
【０２２１】
ステップ３２１８において、音響信号の飛行時間が、第１および第２の期間に基づいて計算される。この計算は、第１の期間と第２の期間との間の差であり得る。ステップ３２２０において、開始側と応答側との間の距離が、音響信号の計算された飛行時間及び速度に基づいて判定され得る。例えば、信号の計算された飛行時間と空気中を移動する信号の速度とを乗算することによって、距離を計算することができる。ステップ３２２２では、距離がアクション可能な範囲内にあるかどうかの判定が行われる。判定がＮＯの場合、プロセス３２００はステップ３２１０に戻ることができる。判定がＹＥＳである場合、ステップ３２２４で、あるアクションを実行することができる（例えば、ブザーを解除）。
【０２２２】
図３２に示されるステップは単なる例示であり、追加のステップが追加もしくは省略されてもよく、またはステップの順序が並べ替えられてもよい。
【図１】
2019500659.tif 000009
【図２】
2019500659.tif 000010
【図３】
2019500659.tif 000011
【図４】
2019500659.tif 000012
【図５】
2019500659.tif 000013
【図６】
2019500659.tif 000014
【図７】
2019500659.tif 000015
【図８】
2019500659.tif 000016
【図９】
2019500659.tif 000017
【図１０】
2019500659.tif 000018
【図１１】
2019500659.tif 000019
【図１２】
2019500659.tif 000020
【図１３】
2019500659.tif 000021
【図１４】
2019500659.tif 000022
【図１５】
2019500659.tif 000023
【図１６】
2019500659.tif 000024
【図１７】
2019500659.tif 000025
【図１８】
2019500659.tif 000026
【図１９】
2019500659.tif 000027
【図２０】
2019500659.tif 000028
【図２１】
2019500659.tif 000029
【図２２】
2019500659.tif 000030
【図２３】
2019500659.tif 000031
【図２４】
2019500659.tif 000032
【図２５Ａ】
2019500659.tif 000033
【図２５Ｂ】
2019500659.tif 000034
【図２６】
2019500659.tif 000035
【図２７】
2019500659.tif 000036
【図２８】
2019500659.tif 000037
【図２９】
2019500659.tif 000038
【図３０】
2019500659.tif 000039
【図３１】
2019500659.tif 000040
【図３２】
2019500659.tif 000041
【手続補正書】
【提出日】平成30年10月3日(2018.10.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
構造物に関連付けられ、リモートデバイスから発される命令に応答してその動作を変更するように動作する電子デバイスであって、
ワイヤレス通信回路と、
マイクロホンと、
前記ワイヤレス通信回路および前記マイクロホンに電気的に結合されるプロセッサとを備え、前記プロセッサは、
前記ワイヤレス通信回路を介して前記リモートデバイスから発される命令を受信し、
前記マイクロホンを用いて前記リモートデバイスの存在を検証し、
前記リモートデバイスの存在が前記マイクロホンで検証されたとき、前記命令を実行するよう動作する、電子デバイス。
【請求項２】
前記プロセッサは、前記リモートデバイスの存在が前記マイクロホンで検証されないとき、前記命令の実行を阻止するよう動作する、請求項１に記載の電子デバイス。
【請求項３】
前記リモートデバイスは、前記構造物の外部に位置し、前記命令は、インターネットサービスプロバイダを介して前記ワイヤレス通信回路を介して受信される、請求項２に記載の電子デバイス。
【請求項４】
前記プロセッサが前記リモートデバイスの存在を検証しているとき、前記プロセッサは、さらに、
前記マイクロホンを使用して音声信号を受信するよう動作し、前記音声信号は、そこで符号化されたデータを含み、前記プロセッサはさらに、
受信された音声信号を復号して前記データを取得し、
復号された音声信号から得られる前記データを処理するよう動作する、請求項１〜３のいずれかに記載の電子デバイス。
【請求項５】
前記ワイヤレス通信回路は、直接的なポイントツーポイントワイヤレス通信を使用して前記リモートデバイスと通信する、請求項１〜４のいずれかに記載の電子デバイス。
【請求項６】
前記ワイヤレス通信回路は、サーバベースのワイヤレス通信を使用して前記リモートデバイスと通信する、請求項１〜５のいずれかに記載の電子デバイス。
【請求項７】
前記プロセッサはさらに、
受信された命令が音響検証を必要とするタイプであるかどうかを評価し、
前記受信された命令が音響検証を必要とするタイプでない場合には前記受信された命令を実行し、
前記受信された命令が音響検証を必要とするタイプである場合、前記命令を実行する前に前記マイクロホンを用いて前記リモートデバイスの存在を検証するよう動作する、請求項１〜６のいずれかに記載の電子デバイス。
【請求項８】
構造物に関連付けられる電子デバイスを動作させるための方法であって、前記電子デバイスは、ワイヤレス通信回路と、マイクロホンと、前記ワイヤレス通信回路および前記マイクロホンに電気的に結合されるプロセッサとを備え、前記方法は、
前記ワイヤレス通信回路を介してリモートデバイスから発される命令を受信することと、
前記マイクロホンを用いて前記リモートデバイスの存在を検証することと、
前記リモートデバイスの存在が前記マイクロホンで検証されたとき、前記命令を実行することとを備える、構造物に関連付けられる電子デバイスを動作させるための方法。
【請求項９】
前記リモートデバイスの存在が前記マイクロホンで検証されないとき、前記命令の実行を阻止することをさらに備える、請求項８に記載の方法。
【請求項１０】
前記リモートデバイスは、前記構造物の外部に位置し、前記命令は、インターネットサービスプロバイダを介して前記ワイヤレス通信回路を介して受信される、請求項９に記載の方法。
【請求項１１】
前記リモートデバイスの存在を検証することはさらに、
前記マイクロホンを使用して音声信号を受信することを含み、前記音声信号は、そこで符号化されたデータを含み、前記リモートデバイスの存在を検証することはさらに、
受信された音声信号を復号して前記データを取得することと、
復号された音声信号から得られる前記データを処理することとを含む、請求項８〜１０のいずれかに記載の方法。
【請求項１２】
直接的なポイントツーポイントワイヤレス通信を使用して前記リモートデバイスと通信することをさらに備える、請求項８〜１１のいずれかに記載の方法。
【請求項１３】
サーバベースのワイヤレス通信を使用して前記リモートデバイスと通信することをさらに備える、請求項８〜１２のいずれかに記載の方法。
【請求項１４】
受信された命令が音響検証を必要とするタイプであるかどうかを評価することと、
前記受信された命令が音響検証を必要とするタイプでない場合には前記受信された命令を実行することと、
前記受信された命令が音響検証を必要とするタイプである場合、前記マイクロホンを用いて前記リモートデバイスの存在を検証することとをさらに備える、請求項８〜１３のいずれかに記載の方法。
【請求項１５】
構造物に関連付けられる少なくとも第２の電子デバイスと通信するのに使用するための第１の電子デバイスであって、
ワイヤレス通信回路と、
音声生成回路と、
プロセッサと、
命令を格納するメモリとを備え、前記命令は、実行されると、前記プロセッサに、ユーザから、前記第２の電子デバイスに命令を出すよう入力を受信することと、前記ワイヤレス通信回路を使用して前記命令を送信することと、前記音声生成回路を介して音声信号を放射することとを実行させるように構成され、前記音声信号は、前記第２の電子デバイスに対する前記第１の電子デバイスの存在を確認するために使用される、第１の電子デバイス。
【請求項１６】
前記命令は、前記プロセッサに、データを前記音声信号に符号化させるように構成される、請求項１５に記載の第１の電子デバイス。
【請求項１７】
前記命令は、前記プロセッサに、前記命令の送信と関連して前記音声信号を同時に放射させるように構成される、請求項１５または１６に記載の第１の電子デバイス。
【請求項１８】
前記命令は、前記プロセッサに、前記ワイヤレス通信回路を介して、前記第２の電子デバイスによる前記命令の受信の確認を受信させるように構成される、請求項１５〜１７のいずれかに記載の第１の電子デバイス。
【請求項１９】
請求項８〜１４のいずれかに記載の方法をコンピュータに実行させる、プログラム。
【国際調査報告】
2019500659.tif 000042
2019500659.tif 000043
2019500659.tif 000044