JP6800881B2 - ＩｏＴシステムにおいてユーザ位置を正確に検知するためのシステム及び方法 - Google Patents

Description

本発明は、概して、コンピュータシステムの分野に関する。より具体的には、本発明は、ＩｏＴシステムにおいてユーザ位置を正確に検知するためのシステム及び方法に関する。

「モノのインターネット」は、インターネットインフラストラクチャ内に、一意的に識別可能に組み込まれたデバイスの相互接続を指す。最終的に、ＩｏＴは、事実上あらゆるタイプの物理的なモノが、それ自体若しくはその周囲についての情報を提供し得、及び／又はインターネットをわたってクライアントデバイスを介して遠隔制御され得る、広範囲の新しいタイプのアプリケーションをもたらすことが期待される。

接続性、電力、及び規格化の欠如に関連する問題のために、ＩｏＴ開発及び採用は遅れている。例えば、ＩｏＴ開発及び採用に対する１つの障害は、開発者が新しいＩｏＴデバイス及びサービスを設計して提供することを可能にする標準プラットフォームが存在しないことである。ＩｏＴ市場に参入するためには、開発者は、所望のＩｏＴ実装に対応するために必要なネットワークプロトコル及びインフラストラクチャ、ハードウェア、ソフトウェア、並びにサービスを含む、ＩｏＴプラットフォーム全体を一から設計する必要がある。その結果、ＩｏＴデバイスの各プロバイダは、ＩｏＴデバイスの設計と接続のために専有の技術を使用しており、エンドユーザにとって複数のタイプのＩｏＴデバイスの採用が厄介となっている。ＩｏＴの採用への別の障害は、ＩｏＴデバイスの接続及び給電に関連する困難である。例えば、冷蔵庫、ガレージドアオープナー、環境センサ、家庭用セキュリティセンサ／コントローラなどの接続機器は、接続された各ＩｏＴ機器に給電するための電源を必要とし、そのような電源はしばしば便利な位置に設けられていない。

存在する別の問題は、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥなどのＩｏＴデバイスを相互接続するために使用される無線技術が、概して、近距離技術であるということである。したがって、ＩｏＴ実装のためのデータ収集ハブがＩｏＴデバイスの範囲外にある場合、そのＩｏＴデバイスは、ＩｏＴハブにデータを送信することができない（逆もまた同様）。その結果として、ＩｏＴデバイスが、範囲外にあるＩｏＴハブ（又は他のＩｏＴデバイス）にデータを提供することを可能にする技術が必要とされる。
本発明のより良好な理解は、以下の図面と併せた以下の詳細な説明から得ることができる。

ＩｏＴシステムアーキテクチャの異なる実施形態を例示する。 ＩｏＴシステムアーキテクチャの異なる実施形態を例示する。 本発明の一実施形態によるＩｏＴデバイスを例示する。 本発明の一実施形態によるＩｏＴハブを例示する。 ＩｏＴデバイスからのデータを制御及び収集し、通知を生成するための本発明の実施形態を例示する。 ＩｏＴデバイスからのデータを制御及び収集し、通知を生成するための本発明の実施形態を例示する。 ＩｏＴデバイスからのデータを収集し、ＩｏＴハブ及び／又はＩｏＴサービスからの通知を生成するための本発明の実施形態を例示する。 現在の無線ロックシステムにおいてユーザを識別することにまつわる問題を例示する。 ＩｏＴデバイス及び／又はＩｏＴハブを用いて、無線ロックシステムのユーザの位置を正確に検出するシステムを例示する。 ＩｏＴデバイス及び／又はＩｏＴハブを用いて、無線ロックシステムのユーザの位置を正確に検出する、別の実施形態を例示する。 信号強度値に基づいて位置検出システムを校正し、ユーザの位置を検出するための一実施形態を例示する。 ＩｏＴデバイス及び／又はＩｏＴハブを使用して無線ロックシステムを実装するための方法を例示する。 ホスト型認証サービスを使用するための方法についての一実施形態を例示する。 信号強度値によりユーザの位置を決定するための、本発明の一実施形態を例示する。 信号強度値に基づいて位置検出システムを校正し、ユーザの位置を検出するための別の実施形態を例示する。 暗号化及びデジタル署名などの改善されたセキュリティ技術を実装する、本発明の実施形態を例示する。 ＩｏＴデバイス上に鍵を記憶するために加入者識別モジュール（ＳＩＭ）が使用されるアーキテクチャの一実施形態を例示する。 バーコード又はＱＲコード（登録商標）を使用してＩｏＴデバイスが登録される一実施形態を例示する。 バーコード又はＱＲコード（登録商標）を使用してペアリングが行われる一実施形態を例示する。 ＩｏＴハブを使用してＳＩＭをプログラミングするための方法の一実施形態を例示する。 ＩｏＴデバイスをＩｏＴハブ及びＩｏＴサービスに登録するための方法の一実施形態を例示する。 ＩｏＴデバイスに送信されるデータを暗号化するための方法の一実施形態を例示する。

以下の説明では、説明を目的として、以下に記載される本発明の実施形態の完全な理解を提供するために、多数の特定の詳細が示される。しかしながら、本発明の実施形態がこれらの特定の詳細のうちのいくつかを用いずに実施され得ることは、当業者には明らかである。他の例では、本発明の実施形態の基本原理を不明瞭にすることを避けるために、周知の構造及びデバイスをブロック図の形態で示す。

本発明の一実施形態は、新しいＩｏＴデバイス及びアプリケーションを設計及び構築するために開発者によって利用され得るモノのインターネット（ＩｏＴ）プラットフォームを含む。具体的には、一実施形態は、所定のネットワーキングプロトコルスタックを含むＩｏＴデバイス、及びＩｏＴデバイスがインターネットに連結されるＩｏＴハブ用の基本ハードウェア／ソフトウェアプラットフォームを含む。加えて、一実施形態は、ＩｏＴサービスを含み、これを通じてＩｏＴハブ及び接続されたＩｏＴデバイスが、以下に説明するようにアクセスされ、管理され得る。加えて、ＩｏＴプラットフォームの一実施形態は、ＩｏＴサービス、ハブ、及び接続されたデバイスにアクセスし、それらを構成する、ＩｏＴアプリケーション又はウェブアプリケーション（例えば、クライアントデバイス上で実行される）を含む。既存のオンライン小売業者及び他のウェブサイトオペレータは、本明細書に記載されたＩｏＴプラットフォームを利用して、既存のユーザベースに独自のＩｏＴ機能を容易に提供することができる。

図１Ａは、本発明の実施形態が実装され得るアーキテクチャプラットフォームの概要を例示する。具体的には、例示した実施形態は、それ自体インターネット２２０を介してＩｏＴサービス１２０に通信可能に連結されている中央ＩｏＴハブ１１０に、ローカル通信チャネル１３０を介して通信可能に連結された複数のＩｏＴデバイス１０１〜１０５を含む。ＩｏＴデバイス１０１〜１０５のそれぞれは、ローカル通信チャネル１３０のそれぞれを有効にするために、ＩｏＴハブ１１０と最初にペアリングすることができる（例えば、後述するペアリング技術を使用して）。一実施形態では、ＩｏＴサービス１２０は、各ユーザのＩｏＴデバイスから収集されたユーザアカウント情報及びデータを維持するためのエンドユーザデータベース１２２を含む。例えば、ＩｏＴデバイスがセンサ（例えば、温度センサ、加速度計、熱センサ、動作検出器など）を含む場合、データベース１２２は、ＩｏＴデバイス１０１〜１０５により収集されるデータを記憶するように継続的に更新され得る。データベース１２２内に記憶されたデータは、次に、ユーザデバイス１３５上にインストールされたＩｏＴアプリケーション又はブラウザを介して（又はデスクトップ若しくは他のクライアントコンピュータシステムを介して）エンドユーザに、かつウェブクライアント（例えば、ＩｏＴサービス１２０に加入しているウェブサイト１３０など）に、アクセス可能にされてもよい。

ＩｏＴデバイス１０１〜１０５には、それ自体及びその周辺に関する情報を収集し、収集された情報を、ＩｏＴハブ１１０を介してＩｏＴサービス１２０、ユーザデバイス１３５、及び／又は外部ウェブサイト１３０に提供するための様々なタイプのセンサが備わっていてもよい。ＩｏＴデバイス１０１〜１０５のうちのいくつかは、ＩｏＴハブ１１０を介して送信される制御コマンドに応答して、指定された機能を行うことができる。ＩｏＴデバイス１０１〜１０５によって収集される情報の様々な具体例及び制御コマンドが以下に提供される。以下に説明する一実施形態では、ＩｏＴデバイス１０１は、ユーザ選択を記録し、ユーザ選択をＩｏＴサービス１２０及び／又はウェブサイトに送信するように設計されたユーザ入力デバイスである。

一実施形態では、ＩｏＴハブ１１０は、４Ｇ（例えば、モバイルＷｉＭＡＸ、ＬＴＥ）又は５Ｇセルラーデータサービスなどのセルラーサービス１１５を介してインターネット２２０への接続を確立するセルラー無線を含む。代替的に、又は加えて、ＩｏＴハブ１１０は、ＷｉＦｉアクセスポイント又はルータ１１６を介してＷｉＦｉ接続を確立するためのＷｉＦｉ無線を含むことができ、これは、ＩｏＴハブ１１０をインターネットに（例えば、エンドユーザにインターネットサービスを提供するインターネットサービスプロバイダを介して）連結する。当然のことながら、本発明の基本原理は、いかなる特定のタイプの通信チャネル又はプロトコルにも限定されないことに留意すべきである。

一実施形態では、ＩｏＴデバイス１０１〜１０５は、電池電力で長期間（例えば、数年）動作することができる超低電力デバイスである。電力を節約するために、ローカル通信チャネル１３０は、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＬＥ）などの低電力無線通信技術を使用して実装することができる。この実施形態では、ＩｏＴデバイス１０１〜１０５及びＩｏＴハブ１１０のそれぞれには、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥ無線及びプロトコルスタックが備わっている。

言及したように、一実施形態では、ＩｏＴプラットフォームは、ユーザが、接続されたＩｏＴデバイス１０１〜１０５、ＩｏＴハブ１１０、及び／又はＩｏＴサービス１２０にアクセスし、それらを構成することを可能にする、ユーザデバイス１３５上で実行されるＩｏＴアプリケーション又はウェブアプリケーションを含む。一実施形態では、アプリケーション又はウェブアプリケーションは、そのユーザベースにＩｏＴ機能性を提供するように、ウェブサイト１３０のオペレータによって設計されてもよい。例示したように、ウェブサイトは、各ユーザに関連するアカウント記録を含むユーザデータベース１３１を維持することができる。

図１Ｂは、複数のＩｏＴハブ１１０〜１１１、１９０に対する追加の接続オプションを例示する。この実施形態では、単一のユーザが、単一のユーザ構内１８０（例えば、ユーザーの自宅又はビジネス）にオンサイトでインストールされた複数のハブ１１０〜１１１を有することができる。これは、例えば、ＩｏＴデバイス１０１〜１０５のすべてを接続するのに必要な無線範囲を拡張するために行われ得る。上述したように、ユーザが複数のハブ１１０、１１１を有する場合、それらは、ローカル通信チャネル（例えば、Ｗｉｆｉ、イーサネット（登録商標）、電力線ネットワーキングなど）を介して接続されてもよい。一実施形態では、ハブ１１０〜１１１のそれぞれは、セルラー１１５又はＷｉＦｉ １１６接続（図１Ｂには明示されていない）を介してＩｏＴサービス１２０への直接接続を確立することができる。代替的に、又は加えて、ＩｏＴハブ１１０などのＩｏＴハブのうちの１つは、「マスター」ハブとして機能することができ、これは、ＩｏＴハブ１１１などのユーザ構内１８０上の他のすべてのＩｏＴハブに接続性及び／又はローカルサービスを提供する（ＩｏＴハブ１１０とＩｏＴハブ１１１を接続する点線で示すように）。例えば、マスターＩｏＴハブ１１０は、ＩｏＴサービス１２０への直接接続を確立する唯一のＩｏＴハブであってもよい。一実施形態では、「マスター」ＩｏＴハブ１１０のみに、ＩｏＴサービス１２０への接続を確立するためのセルラー通信インターフェースが備わっている。このように、ＩｏＴサービス１２０と他のＩｏＴハブ１１１との間のすべての通信は、マスターＩｏＴハブ１１０を通って流れる。この役割において、マスターＩｏＴハブ１１０には、他のＩｏＴハブ１１１とＩｏＴサービス１２０との間で交換されるデータ（例えば、可能であれば、いくつかのデータ要求にローカルでサービスする）に対してフィルタリング動作を行うための追加のプログラムコードが提供され得る。

ＩｏＴハブ１１０〜１１１がどのように接続されていようとも、一実施形態では、ＩｏＴサービス１２０は、ハブをユーザと論理的に関連付け、接続されたＩｏＴデバイス１０１〜１０５のすべてを、インストールされたアプリケーション１３５（及び／又はブラウザベースのインターフェース）を有するユーザデバイスを介してアクセス可能な、単一の包括的なユーザインターフェースの下に結合する。

この実施形態では、マスターＩｏＴハブ１１０及び１つ以上のスレーブＩｏＴハブ１１１は、ＷｉＦｉネットワーク１１６、イーサネット（登録商標）ネットワーク、及び／又は電力線通信（ＰＬＣ）ネットワーキング（例えば、ネットワークの全部若しくは一部がユーザの電力線を介して実行される）、ローカルネットワークを介して接続してもよい。加えて、ＩｏＴハブ１１０〜１１１に対して、ＩｏＴデバイス１０１〜１０５のそれぞれは、いくつか例を挙げると、ＷｉＦｉ、イーサネット（登録商標）、ＰＬＣ、又はＢｌｕｅｔｏｏｔｈ（登録商標） ＬＥなどの任意のタイプのローカルネットワークチャネルを使用して、相互接続してもよい。

図１Ｂはまた、第２のユーザ構内１８１にインストールされたＩｏＴハブ１９０を示す。実質的に無制限の数のそのようなＩｏＴハブ１９０は、世界中のユーザ構内のＩｏＴデバイス１９１〜１９２からデータを収集するようにインストールされ、構成され得る。一実施形態では、２つのユーザ構内１８０〜１８１は、同じユーザに対して構成されてもよい。例えば、一方のユーザ構内１８０がユーザの基本的なホームであり、他方のユーザ構内１８１がユーザのバケーションホームであってもよい。そのような場合、ＩｏＴサービス１２０は、ＩｏＴハブ１１０〜１１１、１９０をユーザと論理的に関連付け、取り付けられたすべてのＩｏＴデバイス１０１〜１０５、１９１〜１９２を、単一の包括的なユーザインターフェースの下に結合し、インストールされたアプリケーション１３５（及び／又はブラウザベースのインターフェース）を有するユーザデバイスを介してアクセス可能にする。

図２に例示するように、ＩｏＴデバイス１０１の例示的な実施形態は、プログラムコード及びデータ２０１〜２０３を記憶するメモリ２１０と、プログラムコードを実行しデータを処理する低電力マイクロコントローラ２００とを含む。メモリ２１０は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの揮発性メモリであってもよいし、フラッシュメモリなどの不揮発性メモリであってもよい。一実施形態では、不揮発性メモリを永続記憶に使用し、揮発性メモリをプログラムコードの実行及びデータの実行に使用することができる。更に、メモリ２１０は、低電力マイクロコントローラ２００内に統合されてもよく、バス又は通信ファブリックを介して低電力マイクロコントローラ２００に連結されてもよい。本発明の基本原理は、メモリ２１０のいかなる特定の実装にも限定されない。

例示したように、プログラムコードは、ＩｏＴデバイス１０１のアプリケーション開発者によって利用され得る所定のビルディングブロックのセットを含む、ＩｏＴデバイス２０１及びライブラリコード２０２によって行われる特定用途向けの機能セットを定義するアプリケーションプログラムコード２０３を含むことができる。一実施形態では、ライブラリコード２０２は、各ＩｏＴデバイス１０１とＩｏＴハブ１１０との間の通信を可能にするための通信プロトコルスタック２０１などのＩｏＴデバイスを実装するために必要とされる基本機能のセットを含む。言及したように、一実施形態では、通信プロトコルスタック２０１は、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥプロトコルスタックを含む。この実施形態では、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥ無線機及びアンテナ２０７は、低電力マイクロコントローラ２００内に統合されてもよい。しかしながら、本発明の基本原理は、いかなる特定の通信プロトコルにも限定されない。

図２に示す特定の実施形態はまた、ユーザ入力を受信し、ユーザ入力を低電力マイクロコントローラに提供する複数の入力デバイス又はセンサ２１０を含み、低電力マイクロコントローラは、アプリケーションコード２０３及びライブラリコード２０２に従ってユーザ入力を処理する。一実施形態では、入力デバイスの各々は、エンドユーザにフィードバックを提供するＬＥＤ ２０９を含む。

加えて、例示した実施形態は、低電力マイクロコントローラに電力を供給するための電池２０８を含む。一実施形態では、非充電式コイン型電池が使用される。しかしながら、別の実施形態では、統合された充電式電池を使用することができる（例えば、交流電源（図示せず）にＩｏＴデバイスを接続することによって再充電可能）。

オーディオを発生するためのスピーカー２０５も設けられている。一実施形態では、低電力マイクロコントローラ２９９は、スピーカー２０５上にオーディオを発生するために圧縮されたオーディオストリーム（例えば、ＭＰＥＧ−４／アドバンストオーディオコーディング（ＡＡＣ）ストリーム）を復号するための、オーディオ復号ロジックを含む。代替的に、低出力マイクロコントローラ２００及び／又はアプリケーションコード／データ２０３が、ユーザが入力デバイス２１０を介して選択を入力すると、エンドユーザに口頭のフィードバックを提供するための、デジタルでサンプリングされたオーディオスニペットを含むことができる。

一実施形態では、ＩｏＴデバイス１０１が設計される特定のアプリケーションに基づいて、１つ以上の他の／代替のＩ／Ｏデバイス又はセンサ２５０が、ＩｏＴデバイス１０１に含まれてもよい。例えば、温度、圧力、湿度などを測定するために環境センサを含めることができる。ＩｏＴデバイスがセキュリティデバイスとして使用される場合には、セキュリティセンサ及び／又はドアロックオープナーが含まれてもよい。当然のことながら、これらの例は、単に例示目的で提供されている。本発明の基本原理は、いかなる特定のタイプのＩｏＴデバイスにも限定されない。実際に、ライブラリコード２０２が備わった低電力マイクロコントローラ２００の高度にプログラム可能な性質が与えられると、アプリケーション開発者は、新しいアプリケーションコード２０３及び新しいＩ／Ｏデバイス２５０を容易に開発して、実質的に任意のタイプのＩｏＴアプリケーションのために低電力マイクロコントローラとインターフェースをとる。

一実施形態では、低電力マイクロコントローラ２００はまた、通信を暗号化するための、及び／又は符号を生成するための暗号化鍵を記憶するための安全な鍵ストアを含む。代替的に、鍵は、加入者識別モジュール（ＳＩＭ）内に確保されてもよい。

一実施形態では、実質的に電力を消費していない超低電力状態からＩｏＴデバイスを起動させるために、ウェイクアップ受信器２０７が含まれる。一実施形態では、ウェイクアップ受信器２０７は、図３に示すように、ＩｏＴハブ１１０上に構成されたウェイクアップ送信器３０７から受信されたウェイクアップ信号に応答して、ＩｏＴデバイス１０１をこの低電力状態から出させるように構成される。具体的には、一実施形態では、送信器３０７と受信器２０７は共に、テスラコイルなどの電気共振トランス回路を形成する。動作中、ハブ１１０が非常に低い電力状態からＩｏＴデバイス１０１を起動させる必要がある場合、エネルギーは送信器３０７から受信器２０７への無線周波数信号を介して送信される。エネルギー移動の理由で、ＩｏＴデバイス１０１は、それが低電力状態にあるときには、ハブからの信号を継続的に「聞く」必要がないので、実質的に電力を消費しないように構成することができる（ネットワーク信号を介してデバイスを起動させることができる、ネットワークプロトコルの場合と同様に）。むしろ、ＩｏＴデバイス１０１のマイクロコントローラ２００は、送信器３０７から受信器２０７に電気的に送信されたエネルギーを使用することによって効果的にパワーダウンされた後に起動するように構成される。

図３に例示するように、ＩｏＴハブ１１０はまた、プログラムコード及びデータ３０５を記憶するためのメモリ３１７と、プログラムコードを実行しデータを処理するためのマイクロコントローラなどのハードウェアロジック３０１とを含む。広域ネットワーク（ＷＡＮ）インターフェース３０２及びアンテナ３１０は、ＩｏＴハブ１１０をセルラーサービス１１５に連結する。代替的に、上で言及したように、ＩｏＴハブ１１０は、ローカルエリアネットワーク通信チャネルを確立するためにＷｉＦｉインターフェース（及びＷｉＦｉアンテナ）又はイーサネット（登録商標）インターフェースなどのローカルネットワークインターフェース（図示せず）を含むこともできる。一実施形態では、ハードウェアロジック３０１はまた、通信を暗号化するための、及び／又は符号を生成／検証するための暗号化鍵を記憶するための安全な鍵ストアを含む。代替的に、鍵は、加入者識別モジュール（ＳＩＭ）内に確保されてもよい。

ローカル通信インターフェース３０３及びアンテナ３１１は、ＩｏＴデバイス１０１〜１０５のそれぞれとのローカル通信チャネルを確立する。上で言及したように、一実施形態では、ローカル通信インターフェース３０３／アンテナ３１１はＢｌｕｅｔｏｏｔｈ（登録商標） ＬＥ規格を実装する。しかしながら、本発明の基本原理は、ＩｏＴデバイス１０１〜１０５とのローカル通信チャネルを確立するためのいかなる特定のプロトコルにも限定されない。図３においては別個のユニットとして示されているが、ＷＡＮインターフェース３０２及び／又はローカル通信インターフェース３０３は、ハードウェアロジック３０１と同じチップ内に組み込まれてもよい。

一実施形態では、プログラムコード及びデータは、ローカル通信インターフェース３０３及びＷＡＮインターフェース３０２を介して通信するための別個のスタックを含む通信プロトコルスタック３０８を含む。加えて、デバイスペアリングプログラムコード及びデータ３０６は、ＩｏＴハブを新しいＩｏＴデバイスとペアリングすることができるようにメモリに記憶され得る。一実施形態では、各新しいＩｏＴデバイス１０１〜１０５には、ペアリングプロセス中にＩｏＴハブ１１０に通信される一意的なコードが割り当てられる。例えば、一意的なコードは、ＩｏＴデバイス上のバーコードに組み込まれてもよく、かつバーコードリーダ１０６によって読み取られてもよく、又はローカル通信チャネル１３０を介して通信されてもよい。別の実施形態では、一意的なＩＤコードがＩｏＴデバイスに磁気的に組み込まれ、ＩｏＴハブは、無線周波数ＩＤ（ＲＦＩＤ）又は近距離通信（ＮＦＣ）センサなどの磁気センサを有し、ＩｏＴデバイス１０１がＩｏＴハブ１１０の数インチ内で移動するとき、コードを検出する。

一実施形態では、一意的なＩＤが通信されると、ＩｏＴハブ１１０は、ローカルデータベース（図示せず）に問い合わせること、コードが許容可能であることを検証するためにハッシュを行うこと、及び／又はＩｏＴサービス１２０と通信することによって、一意的なＩＤを検証し、ユーザデバイス１３５及び／又はウェブサイト１３０でＩＤコードを認証する。認証されると、一実施形態では、ＩｏＴハブ１１０は、ＩｏＴデバイス１０１をペアリングし、メモリ３１７（これは、言及したように、不揮発性メモリを含むことができる）にペアリングデータを記憶する。ペアリングが完了すると、ＩｏＴハブ１１０は、本明細書に記載の様々な機能を行うためにＩｏＴデバイス１０１と接続することができる。

一実施形態では、ＩｏＴサービス１２０を運営する組織は、開発者が新しいＩｏＴサービスを容易に設計できるように、ＩｏＴハブ１１０及び基本ハードウェア／ソフトウェアプラットフォームを提供することができる。具体的には、ＩｏＴハブ１１０に加えて、開発者には、ハブ１１０内で実行されるプログラムコード及びデータ３０５を更新するためのソフトウェア開発キット（ＳＤＫ）が提供されてもよい。加えて、ＩｏＴデバイス１０１については、ＳＤＫは様々な異なるタイプのアプリケーション１０１の設計を容易にするために、ベースのＩｏＴハードウェア（例えば、低電力マイクロコントローラ２００及び図２に示す他の構成要素）用に設計された広範なライブラリコード２０２のセットを含む。一実施形態では、ＳＤＫは、開発者がＩｏＴデバイスの入力と出力を指定するだけでよいグラフィカル設計インターフェースを含む。ＩｏＴデバイス１０１がハブ１１０及びサービス１２０に接続することを可能にする通信スタック２０１を含むネットワーキングコードはすべて、開発者のために既に配置されている。加えて、一実施形態では、ＳＤＫは、モバイルデバイス（例えば、ｉＰｈｏｎｅ（登録商標）及びＡｎｄｒｏｉｄデバイス）用のアプリケーションの設計を容易にするライブラリコードベースも含む。

一実施形態では、ＩｏＴハブ１１０は、ＩｏＴデバイス１０１〜１０５とＩｏＴサービス１２０との間のデータの連続的な双方向ストリームを管理する。ＩｏＴデバイス１０１〜１０５への／からの更新がリアルタイムで要求されるとき（例えば、ユーザがセキュリティデバイス又は環境読み取りの現在の状態を見る必要がある場合）、ＩｏＴハブは、ユーザデバイス１３５及び／又は外部のウェブサイト１３０に定期的な更新を提供するためにオープンＴＣＰソケットを維持することができる。更新を提供するために使用される特定のネットワーキングプロトコルは、基礎をなすアプリケーションのニーズに基づいて調整されてもよい。例えば、連続的な双方向ストリームを有することが理にかなっていない可能性がある場合、必要なときに情報を収集するために単純な要求／応答プロトコルを使用することができる。

一実施形態では、ＩｏＴハブ１１０及びＩｏＴデバイス１０１〜１０５の両方が、ネットワークを介して自動的に更新可能である。具体的には、ＩｏＴハブ１１０について新しい更新が利用可能であるとき、ＩｏＴサービス１２０から更新を自動的にダウンロードしてインストールすることができる。それは、古いプログラムコードを交換する前に、まず、更新されたコードをローカルメモリにコピーし、実行して、更新を検証し得る。同様に、ＩｏＴデバイス１０１〜１０５のそれぞれについて更新が利用可能である場合、それらはＩｏＴハブ１１０によって最初にダウンロードされ、ＩｏＴデバイス１０１〜１０５のそれぞれにプッシュアウトされてもよい。各ＩｏＴデバイス１０１〜１０５は、ＩｏＴハブに関して上述したのと同様の方法で更新を適用し、更新の結果をＩｏＴハブ１１０に報告する。更新が成功した場合、ＩｏＴハブ１１０は、更新をそのメモリから削除して、（例えば、各ＩｏＴデバイスについての新しい更新を確認し続けることができるように）それぞれのＩｏＴデバイスにインストールされている最新バージョンのコードを記録する。

一実施形態では、ＩｏＴハブ１１０は、Ａ／Ｃ電力を介して給電される。具体的には、ＩｏＴハブ１１０は、Ａ／Ｃ電源コードを介して供給されるＡ／Ｃ電圧をより低いＤＣ電圧に変換するための変圧器を備えた電源ユニット３９０を含むことができる。

図４Ａは、ＩｏＴシステムを使用してユニバーサル遠隔制御操作を行うための、本発明の一実施形態を例示する。具体的には、この実施形態では、ＩｏＴデバイス１０１〜１０３のセットには、（ほんの数例を挙げると）空気調節装置／ヒータ４３０、照明システム４３１、及び視聴覚機器４３２を含む、様々な異なるタイプの電子機器を制御する遠隔制御コードを送信するための、赤外線（ＩＲ）及び／又は無線周波数（ＲＦ）ブラスタ４０１〜４０３がそれぞれ備わっている。図４Ａに示される実施形態では、ＩｏＴデバイス１０１〜１０３にはまた、以下に記載されるように、それらが制御するデバイスの動作を検出するためのセンサ４０４〜４０６がそれぞれ備わっている。

例えば、ＩｏＴデバイス１０１におけるセンサ４０４は、現在の温度／湿度を検知し、それに応じて、現在の所望の温度に基づき空気調節装置／ヒータ４３０を制御するための温度及び／又は湿度センサであってもよい。この実施形態では、空気調節装置／ヒータ４３０は、遠隔制御デバイス（典型的には、それ自体が温度センサをその中に組み込んだ遠隔制御）を介して制御されるように設計されるものである。一実施形態では、ユーザは、ユーザデバイス１３５上にインストールされたアプリケーション又はブラウザを介して、所望の温度をＩｏＴハブ１１０に提供する。ＩｏＴハブ１１０上で実行される制御ロジック４１２は、センサ４０４から現在の温度／湿度を受信し、それに応じて、所望の温度／湿度に従ってＩＲ／ＲＦブラスタ４０１を制御するように、ＩｏＴデバイス１０１にコマンドを送信する。例えば、温度が所望の温度未満である場合、制御ロジック４１２は、温度を上げるように、ＩＲ／ＲＦブラスタ４０１を介して空気調節装置／ヒータにコマンドを送信してもよい（例えば、空気調節装置をオフにすることか、又はヒータをオンにすることのいずれかによって）。コマンドは、ＩｏＴハブ１１０上のデータベース４１３に記憶された必要な遠隔制御コードを含んでもよい。代替的に、又は加えて、ＩｏＴサービス４２１は、指定されたユーザ選好及び記憶された制御コード４２２に基づき電子機器４３０〜４３２を制御するために、制御ロジック４２１を実装してもよい。

例示した実施例におけるＩｏＴデバイス１０２は、照明４３１を制御するために使用される。具体的には、ＩｏＴデバイス１０２のセンサ４０５は、照明設備４３１（又は他の照明装置）によってもたらされている光の現在の輝度を検出するように構成される、光センサ又は光検出器であってもよい。ユーザは、ユーザデバイス１３５を介して、ＩｏＴハブ１１０に所望の照明レベル（オン又はオフの指示を含む）を指定してもよい。それに応答して、制御ロジック４１２は、照明４３１の現在の輝度レベルを制御するように、ＩＲ／ＲＦブラスタ４０２にコマンドを送信する（例えば、現在の輝度が低すぎる場合は照明を明るくするか、若しくは現在の輝度が高すぎる場合は照明を暗くする、又は単純に照明をオン若しくはオフにする）。

例示した実施例におけるＩｏＴデバイス１０３は、視聴覚機器４３２（例えば、テレビ、Ａ／Ｖ受信器、ケーブル／衛星受信器、ＡｐｐｌｅＴＶ（商標）など）を制御するように構成される。ＩｏＴデバイス１０３のセンサ４０６は、現在の周囲音量レベルを検出するためのオーディオセンサ（例えば、マイクロホン及び関連ロジック）、並びに／又はテレビによって発生した光に基づき（例えば、指定されたスペクトル内の光を測定することによって）、テレビがオンであるか、それともオフであるかを検出するための光センサであってもよい。代替的に、センサ４０６は、検出された温度に基づき、オーディオ機器がオンであるか、それともオフであるかを検出するための、視聴覚機器に接続された温度センサを含んでもよい。再度、ユーザデバイス１３５を介したユーザ入力に応答して、制御ロジック４１２は、ＩｏＴデバイス１０３のＩＲブラスタ４０３を介して視聴覚機器にコマンドを送信してもよい。

上記が本発明の一実施形態の単なる例示的な実施例であることに留意すべきである。本発明の基本原理は、ＩｏＴデバイスによって制御されるいかなる特定のタイプのセンサ又は機器にも限定されない。

ＩｏＴデバイス１０１〜１０３がＢｌｕｅｔｏｏｔｈ（登録商標） ＬＥ接続を介してＩｏＴハブ１１０に連結される実施形態では、センサデータ及びコマンドは、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥチャネル上で送信される。しかしながら、本発明の基本原理は、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥ又はいかなる他の通信規格にも限定されない。

一実施形態では、電子機器のそれぞれを制御するために必要とされる制御コードは、ＩｏＴハブ１１０上のデータベース４１３及び／又はＩｏＴサービス１２０上のデータベース４２２に記憶される。図４Ｂに例示するように、制御コードは、ＩｏＴサービス１２０上で維持される異なる機器に対して、制御コード４２２のマスターデータベースからＩｏＴハブ１１０に提供されてもよい。エンドユーザは、ユーザデバイス１３５上で実行されるアプリケーション又はブラウザを介して制御される電子（又は他の）機器のタイプを指定してもよく、それに応答して、ＩｏＴハブ上の遠隔制御コード学習モジュール４９１は、ＩｏＴサービス１２０上の遠隔制御コードデータベース４９２から、必要とされるＩＲ／ＲＦコードを検索してもよい（例えば、一意的なＩＤを有する各電子機器を識別する）。

加えて、一実施形態では、ＩｏＴハブ１１０には、遠隔制御コード学習モジュール４９１が、電子機器が備わった元の遠隔制御４９５から直接新しい遠隔制御コードを「学習」することを可能にする、ＩＲ／ＲＦインターフェース４９０が備わっている。例えば、空気調節装置４３０が備わった元の遠隔制御に対する制御コードが、遠隔制御データベースに含まれない場合、ユーザは、ユーザデバイス１３５上のアプリケーション／ブラウザを介してＩｏＴハブ１１０と対話して、元の遠隔制御によって生成された様々な制御コードをＩｏＴハブ１１０に教えてもよい（例えば、温度を上げる、温度を下げるなど）。いったん遠隔制御コードが学習されると、それらは、ＩｏＴハブ１１０上の制御コードデータベース４１３に記憶されてもよく、かつ／又は中央遠隔制御コードデータベース４９２に含まれるために、ＩｏＴサービス１２０に送り返されてもよい（続いて、同じ空気調節装置ユニット４３０を有する他のユーザによって使用されてもよい）。

一実施形態では、ＩｏＴデバイス１０１〜１０３のそれぞれは、極端に小さいフォームファクタを有し、両面テープ、小さい釘、磁気アタッチメントなどを使用して、それらの対応する電子機器４３０〜４３２上又はその近くに取り付けられてもよい。空気調節装置４３０などの１つの機器を制御するために、ＩｏＴデバイス１０１を十分に離して配置し、センサ４０４が自宅内の周囲温度を正確に測定することができるようにすることが望ましい（例えば、空気調節装置上に直接ＩｏＴデバイスを配置することは、空気調節装置が作動しているときに低すぎるか、又はヒータが作動しているときに高すぎる温度測定値をもたらす）。対照的に、照明を制御するために使用されるＩｏＴデバイス１０２は、センサ４０５が現在の照明レベルを検出するように、照明設備４３１上又はその近くに配置されてもよい。

記載される一般的な制御機能を提供することに加えて、ＩｏＴハブ１１０及び／又はＩｏＴサービス１２０の一実施形態は、各電子機器の現在の状態に関連した通知をエンドユーザに送信する。次いで、テキストメッセージ及び／又はアプリケーション特有の通知であってもよい通知は、ユーザのモバイルデバイス１３５のディスプレイ上に表示されてもよい。例えば、ユーザの空気調節装置が長期間オンであるが温度が変化していない場合、ＩｏＴハブ１１０及び／又はＩｏＴサービス１２０は、空気調節装置が適切に機能していないという通知をユーザに送信してもよい。ユーザが自宅におらず（人感センサを介して検出されてもよく、若しくはユーザの現在の検出された位置に基づいてもよい）、センサ４０６が、視聴覚機器４３０がオンであることを示すか、又はセンサ４０５が、照明がオンであることを示す場合、ユーザが視聴覚機器４３２及び／又は照明４３１をオフにしたいかどうか尋ねる通知がユーザに送信されてもよい。同じタイプの通知が、任意の機器のタイプに対して送信されてもよい。

いったんユーザが通知を受信すると、彼／彼女は、ユーザデバイス１３５上のアプリケーション又はブラウザを介して電子機器４３０〜４３２を遠隔制御してもよい。一実施形態では、ユーザデバイス１３５は、タッチスクリーンデバイスであり、アプリケーション又はブラウザは、機器４３０〜４３２を制御するためのユーザが選択可能なボタンを用いて、遠隔制御の画像を表示する。通知を受信した後、ユーザは、グラフィカル遠隔制御を開き、様々な異なる機器をオフにするか、又は調節してもよい。ＩｏＴサービス１２０を介して接続されている場合、ユーザの選択は、ＩｏＴサービス１２０から、次いで制御ロジック４１２を介して機器を制御するＩｏＴハブ１１０に転送されてもよい。代替的に、ユーザ入力は、ユーザデバイス１３５からＩｏＴハブ１１０に直接送信されてもよい。

一実施形態では、ユーザは、電子機器４３０〜４３２に対して様々な自動制御機能を行うように、ＩｏＴハブ１１０上の制御ロジック４１２をプログラミングしてもよい。上述の所望の温度、輝度レベル、及び音量レベルを維持することに加えて、制御ロジック４１２は、ある特定の条件が検出された場合に電子機器を自動的にオフにしてもよい。例えば、制御ロジック４１２が、ユーザが自宅にいないこと、及び空気調節装置が機能していないことを検出する場合、それは、空気調節装置を自動的にオフにしてもよい。同様に、ユーザが自宅におらず、センサ４０６が、視聴覚機器４３０がオンであることを示すか、又はセンサ４０５が、照明がオンであることを示す場合、制御ロジック４１２は、視聴覚機器及び照明をそれぞれオフにするように、ＩＲ／Ｒブラスタ４０３及び４０２を介してコマンドを自動的に送信してもよい。

図５は、電子機器５３０及び５３１を監視するためのセンサ５０３及び５０４が備わった、ＩｏＴデバイス１０４及び１０５の追加の実施形態を例示する。具体的には、この実施形態のＩｏＴデバイス１０４は、コンロがオンのままになっているときを検出するように、コンロ５３０上又はその近くに配置されてもよい、温度センサ５０３を含む。一実施形態では、ＩｏＴデバイス１０４は、温度センサ５０３によって測定された現在の温度を、ＩｏＴハブ１１０及び／又はＩｏＴサービス１２０に送信する。コンロが閾値期間を超えてオンであることが検出される場合（例えば、測定された温度に基づき）、制御ロジック５１２は、ストーブ５３０がオンであることをユーザに通知する通知を、エンドユーザのデバイス１３５に送信してもよい。加えて、一実施形態では、ＩｏＴデバイス１０４は、ユーザからの命令を受信することに応答して、又は自動的に（ユーザによって制御ロジック５１２がそうするようにプログラミングされる場合）、のいずれかによって、コンロをオフにするための制御モジュール５０１を含んでもよい。一実施形態では、制御ロジック５０１は、コンロ５３０への電気又はガスを遮断するためのスイッチを備える。しかしながら、他の実施形態では、制御ロジック５０１は、コンロ自体内に統合されてもよい。

図５はまた、洗濯機及び／又は乾燥機などのある特定のタイプの電子機器の動作を検出するための動作センサ５０４を有する、ＩｏＴデバイス１０５を例示する。使用され得る別のセンサは、周囲の音量レベルを検出するためのオーディオセンサ（例えば、マイクロホン及びロジック）である。上述の他の実施形態のように、この実施形態は、ある特定の指定された条件が満たされた場合、エンドユーザに通知を送信してもよい（例えば、動作が長期間検出され、洗濯機／乾燥機がオフになっていないことを示す場合）。図５に示されないが、ＩｏＴデバイス１０５にはまた、自動的に、かつ／又はユーザ入力に応答して、（例えば、電気／ガスをオフに切り替えることによって）洗濯機／乾燥機５３１をオフにするための制御モジュールが備わっていてもよい。

一実施形態では、制御ロジック及びスイッチを有する第１のＩｏＴデバイスは、ユーザの自宅内のすべての電力をオフにするように構成されてもよく、制御ロジック及びスイッチを有する第２のＩｏＴデバイスは、ユーザの自宅内のすべてのガスをオフにするように構成されてもよい。次いで、センサを有するＩｏＴデバイスは、ユーザの自宅内の電気又はガス駆動の機器上又はその近くに位置付けられてもよい。特定の機器がオンのままである（例えば、コンロ５３０）ことをユーザが通知された場合、ユーザは、自宅内のすべての電気又はガスをオフにするコマンドを送信して、損傷を防止してもよい。代替的に、ＩｏＴハブ１１０及び／又はＩｏＴサービス１２０の制御ロジック５１２は、そのような状態で電気又はガスを自動的にオフにするように構成されてもよい。

一実施形態では、ＩｏＴハブ１１０及びＩｏＴサービス１２０は、周期的な間隔で通信する。ＩｏＴサービス１２０が、ＩｏＴハブ１１０への接続が切れていることを検出する場合（例えば、指定された継続時間、ＩｏＴハブからの要求又は応答を受信していないことによって）、それは、エンドユーザのデバイス１３５にこの情報を通信する（例えば、テキストメッセージ又はアプリケーション特有の通知を送信することによって）。
正確性のための装置及び方法
ＩｏＴシステムにおけるユーザ位置の検知

現在の無線「スマート」ロック及びガレージドアオープナーは、エンドユーザがモバイルデバイスを介してロック及び／又はガレージドアを制御することを可能にする。これらのシステムを動作させるために、ユーザは、モバイルデバイス上でアプリケーションを開き、開ける／ロック解除又は閉じる／ロックオプションを選択しなければならない。それに応じて、無線信号が、所望の動作を実装する無線ロック又はガレージドア上の又はそれに連結された受信器に送信される。下記の考察は無線「ロック」に焦点を合わせているが、「ロック」という用語は、標準的ドアロック、無線ガレージドアオープナー、及び建物又は他の位置へのアクセスを制限するための任意の他のデバイスを指すように本明細書で広く使用される。

いくつかの無線ロックは、ユーザがいつドアの外側にいるかを決定しようと試み、それに応じて、開く／ロック解除機能をトリガする。図６は、例えば、無線デバイス６０３からの信号の信号強度に基づいて、無線デバイス６０３と共にユーザがドア６０１の外側から近づいてくるのに応答して、無線ロック６０２がトリガされる、実施例を例示する。例えば、無線ロック６０２は、無線デバイス６０３からの受信信号強度インジケータ（ＲＳＳＩ）を測定してもよく、それが閾値（例えば、−６０ｄｂｍ）に達すると、ドア６０１をロック解除する。

これらの技術にまつわる１つの明白な問題は、ＲＳＳＩ測定が無指向性であるということである。例えば、ユーザは、無線デバイス６０３と共に自宅を動き回り、無線ロック６０２又はガレージドアオープナーの横を通り過ぎ、それによってそのトリガを引き起こす場合がある。この理由で、ユーザ近接性の検出に基づいて動作する無線ロックの使用は、限定されてきた。

図７は、ＩｏＴハブ及び／又はＩｏＴデバイス７１０を使用して、ユーザの位置をより高い正確性をもって決定する、本発明の一実施形態を例示する。具体的には、本発明のこの実施形態は、無線デバイス７０３とＩｏＴロックデバイス７０２との間の信号強度を測定し、また、無線デバイス７０３と１つ以上のＩｏＴデバイス／ハブ７１０との間の信号強度も測定して、ユーザが自宅の外にいる場合と自宅の中にいる場合とを差異化する。例えば、ユーザが、自宅の中又は外でＩｏＴロック７０２から特定の距離にいる場合、自宅の中の場所からの信号強度７６１及び自宅の外の信号強度７６０は、概ね同じであり得る。図６に例示するものなどの、従来のシステムは、これらの２つの場合の間を決して差異化することがなかった。しかしながら、図７に示す実施形態では、ユーザが自宅の外及び自宅の中にいるときにそれぞれＩｏＴハブ／デバイス７１０と無線デバイス７０３との間で測定された信号強度測定値７５０及び７５１における差異を使用して、ユーザの位置を決定する。例えば、無線デバイス７０３が外の位置にあるとき、信号強度７５０は、無線デバイス７０３が中の位置にあるときの信号強度７５１とは測定できるほどに異なり得る。ほとんどの場合において自宅の中の信号強度７５１はより強いはずであるが、信号強度７５１が実際にはより弱い実例もあり得る。重要な点は、信号強度を使用して、２つの場所を差異化し得るということである。

信号強度値７６０〜７６１、７５０〜７５１は、ＩｏＴハブ／デバイス７１０において又はＩｏＴロック７０２において評価されてもよい（それがこの評価を行うインテリジェンスを有する場合）。この考察の残りの部分では、信号強度評価が、ＩｏＴハブ７１０によって行われることを想定し、ＩｏＴハブ７１０は次いで、評価の結果に基づいて、無線通信チャネル７７０（例えば、ＢＴＬＥ）を介してロック又はロック解除コマンド（又は、既にロックされている／ロック解除されている場合にはコマンドなし）をＩｏＴロック７０２に送信し得る。しかしながら、ＩｏＴロック７０２が、評価を行うロジックにより構成されている場合（例えば、信号強度値がＩｏＴロック７０２に提供される場合）には、同じ基礎的評価及び結果がＩｏＴロック７０２によって直接行われてもよいことに留意すべきである。

図８は、それが２つのＩｏＴハブ／デバイス７１０〜７１１からの信号強度値を利用するので、より高い正確性を提供することが可能である、別の実施形態を例示する。この実施形態では、信号強度８０５は、無線デバイス７０３と（１）ＩｏＴハブ／デバイス７１１、（２）ＩｏＴハブ／デバイス７１０、及び（３）ＩｏＴロック７０２との間で測定される。簡略化のために、無線デバイスは、図８において単一の位置で示される。

一実施形態では、収集された信号強度値のすべてが、ＩｏＴハブデバイス７１０〜７１１のうちの一方に提供され、そのＩｏＴハブデバイスが次いで値を評価して、ユーザの位置（例えば、内側又は外側）を決定する。ユーザが外側にいると決定する場合、ＩｏＴハブ／デバイス７１０は、コマンドをＩｏＴロック７０２に送信して、ドアをロック解除し得る。代替的に、ＩｏＴロック７０２が評価を行うロジックを有する場合、ＩｏＴハブ／デバイス７１０〜７１１は、信号強度値をＩｏＴロック７０２に送信してもよく、ＩｏＴロック７０２が信号強度値を評価してユーザの位置を決定する。

図９に例示するように、一実施形態では、ＩｏＴハブ７１０上の校正モジュール９１０が、無線デバイス７０３上のアプリケーション又はブラウザベースのコードと通信して、信号強度測定値を校正する。校正中、システム校正モジュール９１０及び／又は校正アプリケーションは、ドアの外側及びドアの内側（例えば、外側、ドア１の６フィート外側、ドア１の６フィート内側、ドア２の６フィート外側など）のある特定の位置に立つようユーザに指図し得る。ユーザは、ユーザインターフェース上の図形を選択することによって、彼／彼女が所望の場所にいることを示してもよい。システム校正アプリケーション及び／又はシステム校正モジュール９１０は次いで、収集された信号強度値９００をＩｏＴハブ／デバイス７１０上の位置データベース１３０１内の各位置と関連付ける。

いったんユーザの異なる既知の位置についての信号強度値が収集され、データベース９０１に記憶されると、信号強度分析モジュール９１１は、これらの値を使用して、検出された信号強度値に基づいて、ドアをロック／ロック解除するＩｏＴロックコマンド９５０を送信するかどうかを決定する。図９に示される実施形態では、２つの異なるドアに関する４つの例示的な位置、すなわち、ドア１の外側、ドア１の内側、ドア２の外側、及びドア２の内側が示される。ＲＳＳＩ１値は、無線ロックと関連付けられ、−６０ｄｂｍの閾値に設定される。故に、一実施形態では、信号強度分析モジュール９１１は、ＲＳＳＩ１値が少なくとも−６０ｄｍｂでない限り、ユーザの位置を決定するためのその評価を行わない。ＲＳＳＩ２及びＲＳＳＩ３値は、ユーザの無線デバイスと２つの異なるＩｏＴハブ／デバイスとの間で測定された信号強度値である。

ＲＳＳＩ１閾値に達したと想定して、信号強度分析モジュール９１１は、ＩｏＴハブ／デバイスとびユーザの無線デバイスとの間で測定された現在の信号強度値９００を、位置データベース９０１からのＲＳＳＩ２／ＲＳＳＩ３値と比較する。現在のＲＳＳＩ値が、ＲＳＳＩ２（例えば、ＩｏＴハブ／デバイス７１０について）及びＲＳＳＩ３について（例えばＩｏＴハブ／デバイス７１１について）のデータベースにおいて指定される値の指定範囲内である場合、無線デバイスは、関連付けられた位置にある又はその近くにあると決定される。例えば、「ドア１の外側」位置と関連付けられたＲＳＳＩ２値が−９０ｄｂｍであるので（例えば、校正中に行われた測定に基づいて）、ＲＳＳＩ２について現在測定される信号強度が−９３ｄｂｍ〜−８７ｄｂｍである場合、ＲＳＳＩ２比較が検証され得る（±３ｄｂｍの指定範囲を想定して）。同様に、「ドア１の外側」位置と関連付けられたＲＳＳＩ３値が−８５ｄｂｍであるので（例えば、校正中に行われた測定に基づいて）、ＲＳＳＩ３について現在測定される信号強度が−８８ｄｂｍ〜−８２ｄｂｍである場合、ＲＳＳＩ３比較が検証され得る。故に、ユーザがＩｏＴロックに対して−６０ｄｂｍ値内にいる、かつＲＳＳＩ２及びＲＳＳＩ３についての指定を上回る範囲内にいる場合、信号強度分析モジュール９１１は、ロックを開けるコマンド９５０を送信する。この方法で異なるＲＳＳＩ値を比較することによって、システムは、ＲＳＳＩ２及びＲＳＳＩ３についてのＲＳＳＩ測定値を使用して、中にいる場合及び外にいる場合を差異化するので、ユーザが自宅の中からＩｏＴロックの−６０ｄｂｍ内を通り過ぎるときの望ましくない「ロック解除」事象を回避する。

一実施形態では、信号強度分析モジュール９１１は、中にいる場合と外にいる場合との間の最大量の差異化を提供するＲＳＳＩ値に依存する。例えば、中にいる場合及び外にいる場合に対するＲＳＳＩ値が同等であるか又は非常に近い（例えば、ＲＳＳＩ３値がドア２の内側及びドア２の外側についてそれぞれ−９６ｄｂｍ及び−９７ｄｂｍなど）事例がいくつかあり得る。そのような場合、信号強度分析モジュールは、他のＲＳＳＩ値を使用して、２つの場合を差異化する。加えて、一実施形態では、信号強度分析モジュール９１１は、記録されたＲＳＳＩ値が近いとき、比較に使用されるＲＳＳＩ範囲を動的に調節し得る（例えば、測定されたＲＳＳＩ値がより近いとき、それらの範囲をより小さくする）。故に、上記の実施例において±３ｄｂｍが比較範囲として使用される一方で、ＲＳＳＩ測定値がどれだけ近いかに基づいて、様々な異なる範囲が比較のために設定されてもよい。

一実施形態では、システム校正モジュール９１０システムは、ユーザがドアを通って入るたびにｄｂｍ値を測定することによって、システムを訓練し続ける。例えば、最初の校正に続いてユーザが自宅に首尾よく入ることに応答して、システム校正モジュール９１０は、ＲＳＳＩ２及びＲＳＳＩ３についての追加のＲＳＳＩ値を記憶してもよい。この方法で、中にいる場合と外にいる場合との間を更に差異化するために、ＲＳＳＩ値の範囲が、各場合につき、位置／信号強度データベース９０１に記憶されてもよい。最終結果は、現在利用可能なものよりも遥かにより正確な無線ロックシステムである。

本発明の一実施形態に従った方法が図１０に例示される。本方法は、上述のシステムアーキテクチャとの関連で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

１００１で、ユーザデバイスとＩｏＴロックとの間の無線信号強度が測定される。１００２で、信号強度が指定される閾値を上回る（すなわち、ユーザがドアの近くにいることを示す）場合、１００２で、ユーザデバイスと１つ以上のＩｏＴハブ／デバイスとの間の無線信号強度が測定される。１００３で、収集された無線信号強度値が、以前に収集及び記憶された信号強度値と比較されて、ユーザの位置を決定する。例えば、ＲＳＳＩ値が、ユーザが以前にドアの外側にいたときのＲＳＳＩ値の指定範囲内にある場合、ユーザが現在ドアの外側にいることが決定され得る。１００４で、評価に基づいて、ユーザがドアの外側にいるかどうかに関する決定が下される。そうである場合、１００５で、ＩｏＴロックを使用してドアが自動的にロック解除される。

ＩｏＴロックシステムを校正するための方法が、図１１に例示される。１１０１で、ユーザは、ドアの外側に立つよう求められ、１１０２で、ユーザデバイスと１つ以上のＩｏＴデバイス／ハブとの間で無線信号強度データが収集される。言及したように、要求は、ユーザの無線デバイスにインストールされたユーザアプリケーションを介してユーザに送信され得る。１１０３で、ユーザは、ドアの内側に立つよう求められ、１１０４で、ユーザデバイスとＩｏＴデバイス／ハブとの間で無線信号強度データが収集される。１１０５で、信号強度データがデータベースに記憶され、これにより、それを使用して、本明細書に記載されるように信号強度値を比較して、ユーザの現在位置を決定し得る。

例示的な実施形態としてユーザの自宅が本明細書で使用されるが、本発明の実施形態は、消費者用途に限定されないことに留意されたい。例えば、これらの同じ技術を用いて、ビジネス又は他のタイプの建物へのアクセスを提供してもよい。

一実施形態では、上述したものと同様の技術を使用して、ユーザの自宅全体にわたってユーザを追跡する。例えば、ユーザの自宅においてユーザの無線デバイスと様々なＩｏＴデバイス／ハブとの間のＲＳＳＩ測定値を追跡することによって、異なるユーザ位置の「マップ」が編纂され得る。このマップを次いで使用して、ユーザが現在位置する部屋におけるスピーカーにオーディオを方向付けるなどのサービスをエンドユーザに提供してもよい。

図１２は、無線デバイス７０３と複数のＩｏＴデバイス１１０１〜１１０５及びＩｏＴハブ１１１０との間で測定されたＲＳＳＩ値を使用して、ユーザが部屋Ａ、Ｂ、又はＣにいるかを決定する、例示的なシステムの概要を提供する。具体的には、例示されるように、無線デバイス７０３と、ＩｏＴハブ１１１０、ＩｏＴデバイス１１０３、及びＩｏＴデバイス１１０２との間で測定されたＲＳＳＩ値１１２１〜１１２３に基づいて、ＩｏＴハブ１１１０は、ユーザが現在部屋Ｂにいることを決定し得る。同様に、ユーザが部屋Ｃの中に移動するとき、無線デバイス７０３と、ＩｏＴデバイス１１０４〜１１０５及びＩｏＴハブ１１１０との間のＲＳＳＩ測定値を次いで使用して、ユーザが部屋Ｃにいることを決定してもよい。３つのＲＳＳＩ測定１１２１〜１１２３のみが図１２に示されるが、ＲＳＳＩ測定は、より高い正確性を提供するために、無線デバイス７０３の範囲内の任意のＩｏＴデバイス又はＩｏＴハブとの間で行われてもよい。

一実施形態では、ＩｏＴハブ１１１０は、それ自体と様々なＩｏＴデバイス１１０１〜１１０５及び無線デバイス７０３との間のＲＳＳＩ値に基づいた三角測量技術を用いて、ユーザの位置を三角測量してもよい。例えば、ＩｏＴデバイス１１０２、ＩｏＴハブ１１１０、及び無線デバイス７０３との間に形成されたＲＳＳＩ三角形を使用して、三角形の各辺のＲＳＳＩ値に基づいて、無線デバイス７０３の現在の位置を決定してもよい。

一実施形態では、上述したものと同様の校正技術を使用して、各部屋における信号強度値を収集してもよい。図１３は、上述の実施形態にあるように、無線デバイス７０３上のアプリケーション又はブラウザベースのコードと通信して信号強度測定値を校正する、システム校正モジュール９１０を例示する。校正中、システム校正モジュール９１０及び／又は校正アプリケーションは、ＩｏＴシステムが使用されているアプリケーションに応じて、異なる部屋に、及び各部屋内のある特定の場所に立つようユーザに指図してもよい。上述したように、ユーザは、ユーザインターフェース上の図形を選択することによって、彼／彼女が所望の場所にいることを示してもよい。システム校正アプリケーション及び／又はシステム校正モジュール９１０は次いで、収集された信号強度値９００をＩｏＴハブ／デバイス７１０上の位置データベース９０１内の各位置と関連付ける。

いったんユーザの異なる既知の位置についての信号強度値が収集され、データベース１３０１に記憶されると、信号強度分析モジュール９１１は、これらの値を使用して、ユーザの自宅の周りで様々なＩｏＴデバイス１１０１〜１１０５を制御する。例えば、ＩｏＴデバイス１１０１〜１１０５がホームオーディオシステム用のスピーカー又は増幅器を含む場合、信号強度分析モジュール９１１は、オーディオが再生されている部屋を制御するＩｏＴデバイスコマンド１３０２を送信してもよい（例えば、ユーザが存在する部屋におけるスピーカーをオンにし、他の部屋におけるスピーカーをオフにする）。同様に、ＩｏＴデバイス１１０１〜１１０５が照明制御ユニットを含む場合、信号強度分析モジュール９１１は、ユーザが存在する部屋における照明をオンにし、他の部屋における照明をオフにするＩｏＴデバイスコマンド１３０２を送信してもよい。当然ながら、本発明の基本原理は、いかなる特定のエンドユーザ用途にも限定されない。

言及したように、システム校正モジュール９１０の一実施形態は、用途に基づいて、部屋内の異なる点についてのＲＳＳＩデータを収集する。図１３において、ＲＳＳＩ範囲は、各部屋につき、その部屋内の異なる場所に立つようユーザに指図することによって、収集される。例えば、ユーザの家族の部屋に関して、ＲＳＳＩ１、ＲＳＳＩ２、及びＲＳＳＩ３について、それぞれ、−９９ｄｂｍ〜−９３ｄｂｍ、−１１１ｄｂｍ〜−９０ｄｂｍ、及び−１１５ｄｂｍ〜−８５ｄｂｍのＲＳＳＩ範囲が収集される（すなわち、３つの異なるＩｏＴデバイス／ハブから収集される）。無線デバイス７０３の現在の場所がこれらの範囲の各々に該当するとき、信号強度分析モジュール９１１は、ユーザが家族の部屋にいると決定し、指定された機能の組（例えば、照明、オーディオをオンにするなど）を行うＩｏＴデバイスコマンド１３０２を送信する可能性がある。加えて、部屋内の特定の点に関して、特定のＲＳＳＩ値が収集され得る。例えば、図１３においては、ユーザが家族の部屋においてソファに座っているときに−８８ｄｂｍ、−９９ｄｂｍ、及び−１０１ｄｂｍの値が収集された。上述の実施形態にあるように、信号強度分析モジュール９１１は、ＲＳＳＩ値が記憶されたＲＳＳＩ値の指定範囲にある（例えば、±３ｄｂｍである間に収まる）場合、ユーザがカウチの上にいると決定し得る。加えて、先の実施形態にあるように、システム校正モジュール９１０は、ＲＳＳＩ値が最新にとどまることを確実にするために、異なる位置に関してデータを収集し続けてもよい。例えば、ユーザが家族の部屋の配置構成を変える場合、カウチの場所は移動し得る。この場合、システム校正モジュール９１０は、ユーザが現在カウチに座っているかどうかをユーザに尋ね（例えば、ＲＳＳＩ値が、データベースに記憶されたものと類似していることを所与として）、信号強度データベース１３０１を新たな値で更新してもよい。

一実施形態では、様々なタイプのＩｏＴデバイスとのユーザの対話を使用して、ユーザの位置を決定してもよい。例えば、ユーザの冷蔵庫にＩｏＴデバイスが備わっている場合、システムは、ユーザが冷蔵庫のドアを開けたことを検出するとすぐにＲＳＳＩ測定を行ってもよい。同様に、照明システムがＩｏＴシステムを含む場合、ユーザが自宅又はビジネスの異なる部屋における照明を調節するときに、システムは、ＲＳＳＩ測定を自動的に行ってもよい。別の例として、ユーザが様々な家庭用器具（例えば、洗濯機、乾燥機、食洗器）、視聴覚機器（例えば、テレビ、オーディオ機器など）、又はＨＶＡＣシステム（例えば、サーモスタットを調節する）と対話するときに、システムは、ＲＳＳＩ測定値をキャプチャし、その測定値をこれらの位置と関連付けてもよい。

上述の実施形態では単一のユーザについて記載されているが、本発明の実施形態は、複数のユーザに関して実装されてもよい。例えば、システム校正モジュール９１０は、信号強度データベース１３０１に記憶されるべきユーザＡ及びユーザＢの両方に関して、信号強度値を収集してもよい。信号強度分析モジュール９１１は次いで、信号強度測定値の比較に基づいてユーザＡ及びＢの現在の位置を識別し、ユーザＡ及びＢの自宅の周りでＩｏＴデバイスを制御するＩｏＴコマンド１３０２を送信してもよい（例えば、ユーザＡ及びＢが存在する部屋における照明／スピーカーをオンにしておく）。

本明細書に記載される本発明の実施形態において用いられる無線デバイス７０３は、スマートフォン、タブレット、装着可能なデバイス（例えば、スマートウォッチ、ネックレス又はブレスレットに付いたトークン）、又はＲＳＳＩ値を検出することが可能な任意の他の形態の無線デバイス７０３であってもよい。一実施形態では、無線デバイス７０３は、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥ（ＢＴＬＥ）などの短距離、低電力無線通信プロトコルを介して、ＩｏＴデバイス１１０１〜１１０５及びＩｏＴハブ１１１０と通信する。加えて、一実施形態では、無線デバイス７０３は、Ｗｉｆｉなどのより長距離の無線プロトコルを介して、ＩｏＴハブ１１１０と通信する。故に、この実施形態では、ＲＳＳＩ値は、無線デバイス７０３によって集められ、より長距離のプロトコルを使用してＩｏＴハブ１１１０に戻して通信されてもよい。加えて、個々のＩｏＴデバイス１１０１〜１１０５の各々が、ＲＳＳＩ値を収集し、短距離無線プロトコルを介してこれらの値をＩｏＴハブ１１１０に戻して通信してもよい。本発明の基本原理は、ＲＳＳＩ値を収集するために使用されるいかなる特定のプロトコル又は技術にも限定されない。

本発明の一実施形態は、本明細書に記載される技術を使用して、短距離無線プロトコルを使用してＩｏＴハブ１１１０の範囲を拡張する無線エクステンダーのための理想的な場所を位置決めする。例えば、一実施形態では、新たなエクステンダーを購入するとすぐに、システム校正モジュール９１０は、無線エクステンダーデバイスと共にユーザの自宅の部屋の各々の中に移動するようユーザに対する指図を送信する（例えば、無線デバイス７０３上のアプリケーションに指図を送信することによって）。ユーザをプロセスにわたってステップ毎に誘導するために、無線デバイス７０３上で接続ウィザードもまた実行され得る。システム校正モジュール９１０によって送信される又はウィザードからの指図に従って、ユーザは各部屋の中に歩いて行き、無線デバイス７０３上のボタンを押す。ＩｏＴハブ１１１０は次いで、それ自体とエクステンダーとの間の信号強度、及び同様に、エクステンダーとシステムにおける他のＩｏＴデバイスのすべてとの間の信号強度を測定する。システム校正モジュール９１０又は無線デバイスウィザードは次いで、無線エクステンダーを置く最適な位置の優先リストについてのユーザの意向を可能にしてもよい（すなわち、無線エクステンダーとＩｏＴハブ１１１０との間及び／又は無線エクステンダーとＩｏＴデバイス１１０１〜１１０５との間で最も高い信号強度を有する位置を選択する）。

上述の本発明の実施形態は、現在のＩｏＴシステムには見出されない、ＩｏＴシステム内の微調整された位置認識を実現する。加えて、位置検出の正確性を改善するために、一実施形態（embodiemnt）では、無線デバイス７０３上のＧＰＳシステムが、各位置に関するＧＰＳデータ並びにＲＳＳＩデータを含む、ユーザの自宅の正確なマップを提供するために使用される精密なＧＰＳデータを通信してもよい。
改善されたセキュリティのための実施形態

一実施形態では、各ＩｏＴデバイス１０１の低電力マイクロコントローラ２００及びＩｏＴハブ１１０の低電力ロジック／マイクロコントローラ３０１は、以下に記載される実施形態によって使用される暗号化鍵を記憶するための安全な鍵ストアを含む（例えば、図１４〜１９及び関連する文章を参照されたい）。代替的に、鍵は、後述するように、加入者識別モジュール（ＳＩＭ）内に確保されてもよい。

図１４は、ＩｏＴサービス１２０、ＩｏＴハブ１１０、並びにＩｏＴデバイス１０１及び１０２の間の通信を暗号化するために公開鍵インフラストラクチャ（ＰＫＩ）技術及び／又は対称鍵交換／暗号化技術を使用する、俯瞰的なアーキテクチャを例示する。

公開／秘密鍵ペアを使用する実施形態をまず説明し、続いて、対称鍵交換／暗号化技術を使用する実施形態を説明する。具体的には、ＰＫＩを使用するある実施形態では、一意的な公開／秘密鍵ペアが、各ＩｏＴデバイス１０１〜１０２、各ＩｏＴハブ１１０、及びＩｏＴサービス１２０と関連付けられる。一実施形態では、新しいＩｏＴハブ１１０がセットアップされるとき、その公開鍵がＩｏＴサービス１２０に提供され、新しいＩｏＴデバイス１０１が設定されるとき、その公開鍵がＩｏＴハブ１１０とＩｏＴサービス１２０との両方に提供される。デバイス間で公開鍵を安全に交換するための様々な技術が以下に記載される。一実施形態では、いかなる受信デバイスも、署名を認証することによって公開鍵の妥当性を検証することができるように、すべての公開鍵が、受信デバイスのすべてに既知である親鍵（すなわち、一種の証明書）によって署名される。したがって、未加工の公開鍵を単に交換するのではなく、むしろこれらの証明書が交換されることになる。

例示したように、一実施形態では、各ＩｏＴデバイス１０１、１０２は、各デバイスの秘密鍵を安全に記憶するために、それぞれ、安全な鍵ストア１４０１、１４０３を含む。次に、セキュリティロジック１４０２、１３０４が、安全に記憶された秘密鍵を利用して、本明細書に記載される暗号化／解読動作を行う。同様に、ＩｏＴハブ１１０は、ＩｏＴハブ秘密鍵、並びにＩｏＴデバイス１０１〜１０２及びＩｏＴサービス１２０の公開鍵を記憶するための安全な記憶装置１４１１、並びに、鍵を使用して暗号化／解読動作を行うためのセキュリティロジック１４１２を含む。最後に、ＩｏＴサービス１２０は、それ自体の秘密鍵、様々なＩｏＴデバイス及びＩｏＴハブの公開鍵を安全に記憶するための安全な記憶装置１４２１、並びに、鍵を使用してＩｏＴハブ及びデバイスとの通信を暗号化／解読するためのセキュリティロジック１４１３を含んでもよい。一実施形態では、ＩｏＴハブ１１０がＩｏＴデバイスから公開鍵証明書を受信すると、ＩｏＴハブ１１０は、それを（例えば、上述の親鍵を使用して署名を認証することにより）検証し、次いで、その中から公開鍵を抽出し、その公開鍵をその安全な鍵ストア１４１１に記憶する。

一例として、一実施形態では、ＩｏＴサービス１２０が、コマンド又はデータ（例えば、ドアをロック解除するコマンド、センサを読み取る要求、ＩｏＴデバイスにより処理／表示されるべきデータなど）をＩｏＴデバイス１０１に送信する必要があるとき、セキュリティロジック１４１３は、ＩｏＴデバイス１０１の公開鍵を使用してそのデータ／コマンドを暗号化して、暗号化されたＩｏＴデバイスパケットを生成する。一実施形態では、それは次に、ＩｏＴハブ１１０の公開鍵を使用し、ＩｏＴデバイスパケットを暗号化して、ＩｏＴハブパケットを生成し、ＩｏＴハブパケットをＩｏＴハブ１１０に送信する。一実施形態では、サービス１２０は、デバイス１０１が、それが信頼されるソースから変更されていないメッセージを受信していることを検証することができるように、上述のその秘密鍵又は親鍵を用いて、暗号化されたメッセージに署名する。デバイス１０１は次いで、秘密鍵及び／又は親鍵に対応する公開鍵を使用して、署名を認証してもよい。上で言及したように、対称鍵交換／暗号化技術は、公開／秘密鍵暗号化の代わりに使用されてもよい。これらの実施形態では、１つの鍵をプライベートに記憶し、対応する公開鍵を他のデバイスに提供するのではなく、それぞれのデバイスに、暗号化のために、かつ署名を認証するために使用されるものと同じ対称鍵のコピーを提供してもよい。対称鍵アルゴリズムの一例は高度暗号化標準（ＡＥＳ）であるが、本発明の基本原理は、いかなるタイプの特定の対称鍵にも限定されない。

ある対称鍵実装形態を使用すると、各デバイス１０１は、ＩｏＴハブ１１０と対称鍵を交換するために、安全な鍵交換プロトコルに入る。動的対称鍵プロビジョニングプロトコル（ＤＳＫＰＰ）などの安全な鍵プロビジョニングプロトコルが、安全な通信チャネルを介して鍵を交換するために使用され得る（例えば、コメント要求（ＲＦＣ）６０６３を参照されたい）。しかしながら、本発明の基本原理は、いかなる特定の鍵プロビジョニングプロトコルにも限定されない。

対称鍵が交換されたら、それらは、各デバイス１０１及びＩｏＴハブ１１０によって、通信を暗号化するために使用され得る。同様に、ＩｏＴハブ１１０及びＩｏＴサービス１２０は、安全な対称鍵交換を行い、次に、交換された対称鍵を使用して通信を暗号化し得る。一実施形態では、新しい対称鍵が、デバイス１０１とハブ１１０との間、かつハブ１１０とＩｏＴサービス１２０との間で定期的に交換される。一実施形態では、デバイス１０１、ハブ１１０、及びサービス１２０の間での新しい通信セッションのたびに、新しい対称鍵が交換される（例えば、通信セッション毎に新しい鍵が生成され、安全に交換される）。一実施形態では、ＩｏＴハブ内のセキュリティモジュール１４１２が信頼される場合、サービス１２０は、ハブセキュリティモジュール１３１２とセッション鍵を交渉し得、次いで、セキュリティモジュール１４１２が、各デバイス１２０とセッション鍵を交渉することになる。サービス１２０からのメッセージは、次いで、ハブセキュリティモジュール１４１２で解読及び検証され、その後、デバイス１０１への送信のために再暗号化される。

一実施形態では、ハブセキュリティモジュール１４１２でのセキュリティ侵害を防止するために、１回限りの（恒久的な）インストール鍵が、インストール時にデバイス１０１とサービス１２０との間で交渉されてもよい。メッセージをデバイス１０１に送るとき、サービス１２０は、まずこのデバイスインストール鍵を用いて暗号化／ＭＡＣし、次にハブのセッション鍵を用いてそれを暗号化／ＭＡＣし得る。ハブ１１０は次に、暗号化されたデバイスブロブを検証及び抽出し、それをデバイスに送ることになる。

本発明の一実施形態では、リプレイアタックを防止するためにカウンタ機構が実装される。例えば、デバイス１０１からハブ１１０へ（又は逆もまた同様）の連続する通信それぞれに、継続的に増加するカウンタ値が割り当てられ得る。ハブ１１０とデバイス１０１との両方がこの値を追跡し、デバイス間での連続する通信それぞれにおいてその値が正しいことを検証する。これと同じ技術が、ハブ１１０とサービス１２０との間に実装され得る。この方法でカウンタを使用すると、各デバイス間での通信を偽装することがより困難になる（カウンタ値が誤ったものになるため）。しかしながら、これを用いずとも、サービスとデバイスとの間で共有されたインストール鍵は、すべてのデバイスに対するネットワーク（ハブ）規模の攻撃を防止するであろう。

一実施形態では、公開／秘密鍵暗号化を使用するとき、ＩｏＴハブ１１０は、その秘密鍵を使用してＩｏＴハブパケットを解読し、暗号化されたＩｏＴデバイスパケットを生成し、それを、関連付けられたＩｏＴデバイス１０１に送信する。ＩｏＴデバイス１０１は次にその秘密鍵を使用して、ＩｏＴデバイスパケットを解読して、ＩｏＴサービス１２０を起点とするコマンド／データを生成する。それは次に、データを処理し、かつ／又はコマンドを実行してもよい。対称暗号化を使用すると、各デバイスは、共有された対称鍵を用いて暗号化及び解読を行う。いずれかの場合であれば、各送信デバイスはまた、受信デバイスがメッセージの信頼性を検証することができるように、その秘密鍵を用いてメッセージに署名してもよい。

異なるセットの鍵が、ＩｏＴデバイス１０１からＩｏＴハブ１１０へ、かつＩｏＴサービス１２０への通信を暗号化するために使用されてもよい。例えば、ある公開／秘密鍵構成を使用して、一実施形態では、ＩｏＴデバイス１０１上のセキュリティロジック１４０２は、ＩｏＴハブ１１０の公開鍵を使用して、ＩｏＴハブ１１０に送信されたデータパケットを暗号化する。次いで、ＩｏＴハブ１１０上のセキュリティロジック１４１２は、ＩｏＴハブの秘密鍵を使用して、データパケットを解読し得る。同様に、ＩｏＴデバイス１０１上のセキュリティロジック１４０２及び／又はＩｏＴハブ１１０上のセキュリティロジック１４１２は、ＩｏＴサービス１２０の公開鍵を使用して、ＩｏＴサービス１２０に送信されたデータパケットを暗号化し得る（それは次いで、ＩｏＴサービス１２０上のセキュリティロジック１４１３によって、サービスの秘密鍵を使用して解読され得る）。対称鍵を使用すると、デバイス１０１及びハブ１１０は、ある対称鍵を共有し得、一方でハブ及びサービス１２０は、異なる対称鍵を共有し得る。

上記の説明において、ある特定の具体的詳細が上に記載されるが、本発明の基本原理は、様々な異なる暗号化技術を使用して実装され得ることに留意すべきである。例えば、上述した一部の実施形態は、非対称の公開／秘密鍵ペアを使用するが、別の実施形態は、様々なＩｏＴデバイス１０１〜１０２、ＩｏＴハブ１１０、及びＩｏＴサービス１２０の間で安全に交換される対称鍵を使用し得る。更に、一部の実施形態では、データ／コマンド自体は暗号化されないが、データ／コマンド（又は他のデータ構造）上の署名を生成するために鍵が使用される。その後、受信者が、その鍵を使用して署名を認証し得る。

図１５に例示するように、一実施形態では、各ＩｏＴデバイス１０１上の安全な鍵ストアは、プログラム可能な加入者識別モジュール（ＳＩＭ）１５０１を使用して実装される。この実施形態では、ＩｏＴデバイス１０１は、ＩｏＴデバイス１０１上のＳＩＭインターフェース１５００内に据え付けられたプログラムされていないＳＩＭカード１５０１と共にエンドユーザに最初に提供され得る。１つ以上の暗号鍵のセットを用いてＳＩＭをプログラミングするために、ユーザは、プログラム可能なＳＩＭカード１５０１をＳＩＭインターフェース５００から取り出し、それをＩｏＴハブ１１０上のＳＩＭプログラミングインターフェース１５０２に挿入する。次いで、ＩｏＴハブ上のプログラミングロジック１５２５が、ＩｏＴデバイス１０１をＩｏＴハブ１１０及びＩｏＴサービス１２０に登録／ペアリングするように、ＳＩＭカード１５０１を安全にプログラミングする。一実施形態では、公開／秘密鍵ペアは、プログラミングロジック１５２５によってランダムに生成されてもよく、次いで、このペアの公開鍵は、ＩｏＴハブの安全な記憶デバイス４１１内に記憶されてもよく、一方で秘密鍵は、プログラム可能なＳＩＭ １５０１内に記憶されてもよい。加えて、プログラミングロジック５２５は、ＩｏＴハブ１１０、ＩｏＴサービス１２０、及び／又は任意の他のＩｏＴデバイス１０１の公開鍵を、（ＩｏＴデバイス１０１上のセキュリティロジック１３０２による発信データの暗号化に使用するために）ＳＩＭカード１４０１上に記憶してもよい。いったんＳＩＭ １５０１がプログラミングされると、新しいＩｏＴデバイス１０１に、ＳＩＭを安全な識別子として使用して（例えば、ＳＩＭを用いてデバイスを登録するための既存の技術を使用して）ＩｏＴサービス１２０がプロビジョニングされ得る。プロビジョニング後、ＩｏＴハブ１１０とＩｏＴサービス１２０との両方が、ＩｏＴデバイスの公開鍵のコピーを、ＩｏＴデバイス１０１との通信を暗号化する際に使用されるように安全に記憶する。

図１５に関して上述した技術は、新しいＩｏＴデバイスをエンドユーザに提供する際の多大な柔軟性を提供する。（現在行われているのと同様に）ユーザが販売／購入の際に各ＳＩＭを特定のサービスプロバイダに直接登録することを要するのではなく、エンドユーザによりＩｏＴハブ１１０を介してＳＩＭを直接プログラミングしてもよく、プログラミングの結果は、ＩｏＴサービス１２０に安全に通信され得る。その結果、新しいＩｏＴデバイス１０１がオンライン又はローカルの小売業者からエンドユーザに販売され、後にＩｏＴサービス１２０が安全にプロビジョニングされ得る。

ＳＩＭ（加入者識別モジュール）という具体的な文脈において登録及び暗号化技術を上述したが、本発明の基本原理は「ＳＩＭ」デバイスに限定されない。むしろ、本発明の基本原理は、暗号鍵セットを記憶するための安全な記憶装置を有する、いかなるタイプのデバイスを使用して実装されてもよい。更に、上記の実施形態は取り外し可能なＳＩＭデバイスを含むのに対し、一実施形態では、ＳＩＭデバイスは取り外し可能でないが、ＩｏＴデバイス自体が、ＩｏＴハブ１１０のプログラミングインターフェース１５０２に挿入されてもよい。

一実施形態では、ユーザがＳＩＭ（又は他のデバイス）をプログラミングすることを要するのではなく、ＳＩＭは、エンドユーザへの流通前に、ＩｏＴデバイス１０１に予めプログラミングされる。この実施形態では、ユーザがＩｏＴデバイス１０１をセットアップするとき、本明細書に記載される様々な技術が、ＩｏＴハブ１１０／ＩｏＴサービス１２０と新しいＩｏＴデバイス１０１との間で暗号鍵を安全に交換するために使用され得る。

例えば、図１６Ａに例示するように、各ＩｏＴデバイス１０１又はＳＩＭ ４０１は、ＩｏＴデバイス１０１及び／又はＳＩＭ １５０１を一意的に識別するバーコード又はＱＲコード（登録商標）１５０１と共にパッケージ化されていてもよい。一実施形態では、バーコード又はＱＲコード（登録商標）１６０１は、ＩｏＴデバイス１０１又はＳＩＭ １００１の公開鍵の符号化表現を含む。代替的に、バーコード又はＱＲコード（登録商標）１６０１は、ＩｏＴハブ１１０及び／又はＩｏＴサービス１２０によって、公開鍵を識別又は生成するために使用されてもよい（例えば、安全な記憶装置内に既に記憶されている公開鍵に対するポインタとして使用される）。バーコード又はＱＲコード（登録商標）６０１は、別個のカード上に（図１６Ａに示されるように）印刷されてもよく、又はＩｏＴデバイス自体に直接印刷されてもよい。バーコードが印刷される場所に関わらず、一実施形態では、ＩｏＴハブ１１０には、バーコードを読み取り、得られたデータをＩｏＴハブ１１０上のセキュリティロジック１０１２及び／又はＩｏＴサービス１２０上のセキュリティロジック１０１３に提供するために、バーコードリーダ２０６が備わっている。次いで、ＩｏＴハブ１１０上のセキュリティロジック１０１２は、ＩｏＴデバイスの公開鍵をその安全な鍵ストア１０１１内に記憶してもよく、ＩｏＴサービス１２０上のセキュリティロジック１０１３は、この公開鍵をその安全な記憶装置１０２１内に（後の暗号化通信に使用するために）記憶してもよい。

一実施形態では、バーコード又はＱＲコード（登録商標）１６０１内に含まれるデータはまた、インストールされたＩｏＴアプリケーション又はＩｏＴサービスプロバイダにより設計されたブラウザベースのアプレットを用いて、ユーザデバイス１３５（例えば、ｉＰｈｏｎｅ（登録商標）又はＡｎｄｒｏｉｄデバイスなど）によりキャプチャされてもよい。キャプチャされると、バーコードデータは、安全な接続（例えば、セキュアソケットレイヤー（ＳＳＬ）接続など）を介して、ＩｏＴサービス１２０に安全に通信され得る。バーコードデータはまた、安全なローカル接続を介して（例えば、ローカルＷｉＦｉ又はＢｌｕｅｔｏｏｔｈ（登録商標） ＬＥ接続を介して）クライアントデバイス１３５からＩｏＴハブ１１０に提供されてもよい。

ＩｏＴデバイス１０１上のセキュリティロジック１００２及びＩｏＴハブ１１０上のセキュリティロジック１０１２は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせを使用して実装され得る。例えば、一実施形態では、セキュリティロジック１００２、１０１２は、ＩｏＴデバイス１０１とＩｏＴハブ１１０との間にローカル通信チャネル１３０を確立するために使用されるチップ（例えば、ローカルチャネル１３０がＢｌｕｅｔｏｏｔｈ（登録商標） ＬＥである場合、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥチップ）内に実装される。セキュリティロジック１００２、１０１２の具体的な位置に関わらず、一実施形態では、セキュリティロジック１００２、１０１２は、ある特定のタイプのプログラムコードを実行するために安全な実行環境を確立するように設計される。これは、例えば、ＴｒｕｓｔＺｏｎｅ技術（一部のＡＲＭプロセッサで利用可能）及び／又はトラステッド・エグゼキューション・テクノロジー（Ｉｎｔｅｌにより設計）を使用することによって、実装され得る。当然のことながら、本発明の基本原理は、いかなる特定のタイプの安全な実行技術にも限定されない。

一実施形態では、バーコード又はＱＲコード（登録商標）１５０１は、各ＩｏＴデバイス１０１をＩｏＴハブ１１０とペアリングするために使用され得る。例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥデバイスをペアリングするために現在使用されている標準的な無線ペアリングプロセスを使用するのではなく、バーコード又はＱＲコード（登録商標）１５０１内に組み込まれたペアリングコードをＩｏＴハブ１１０に提供して、ＩｏＴハブを対応するＩｏＴデバイスとペアリングしてもよい。

図１６Ｂは、ＩｏＴハブ１１０上のバーコードリーダ２０６が、ＩｏＴデバイス１０１と関連付けられたバーコード／ＱＲコード（登録商標）１６０１をキャプチャする、一実施形態を例示する。言及したように、バーコード／ＱＲコード（登録商標）１６０１は、ＩｏＴデバイス１０１上に直接印刷されてもよく、又はＩｏＴデバイス１０１と共に提供される別個のカード上に印刷されてもよい。いずれの場合においても、バーコードリーダ２０６は、バーコード／ＱＲコード（登録商標）１６０１からペアリングコードを読み取り、このペアリングコードをローカル通信モジュール１６８０に提供する。一実施形態では、ローカル通信モジュール１６８０は、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥチップ及び関連付けられたソフトウェアであるが、本発明の基本原理は、いかなる特定のプロトコル規格にも限定されない。いったんペアリングコードが受信されると、それは、ペアリングデータ１６８５を含む安全な記憶装置内に記憶され、ＩｏＴデバイス１０１とＩｏＴハブ１１０とが自動的にペアリングされる。この方法でＩｏＴハブが新しいＩｏＴデバイスとペアリングされるたびに、そのペアリングに関するペアリングデータが、安全な記憶装置６８５内に記憶される。一実施形態では、ＩｏＴハブ１１０のローカル通信モジュール１６８０がペアリングコードを受信すると、それは、このコードを鍵として使用して、ローカル無線チャネルを介したＩｏＴデバイス１０１との通信を暗号化し得る。

同様に、ＩｏＴデバイス１０１側では、ローカル通信モジュール１５９０が、ＩｏＴハブとのペアリングを示すペアリングデータを、ローカルの安全な記憶デバイス１５９５内に記憶する。ペアリングデータ１６９５は、バーコード／ＱＲコード（登録商標）１６０１で識別される予めプログラミングされたペアリングコードを含んでもよい。ペアリングデータ１６９５はまた、安全なローカル通信チャネルを確立するために必要な、ＩｏＴハブ１１０上のローカル通信モジュール１６８０から受信されるペアリングデータ（例えば、ＩｏＴハブ１１０との通信を暗号化するための追加の鍵）を含んでもよい。

したがって、バーコード／ＱＲコード（登録商標）１６０１は、ペアリングコードが無線で送信されないため、現在の無線ペアリングプロトコルよりも遥かに安全な方法でローカルペアリングを行うために使用され得る。加えて、一実施形態では、ペアリングに使用されるものと同じバーコード／ＱＲコード（登録商標）１６０１を使用して暗号鍵を識別し、ＩｏＴデバイス１０１からＩｏＴハブ１１０へ、かつＩｏＴハブ１１０からＩｏＴサービス１２０への安全な接続を構築することができる。

本発明の一実施形態に従ってＳＩＭカードをプログラミングするための方法が、図１７に例示される。本方法は、上述のシステムアーキテクチャ内で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

１７０１で、ユーザは、空のＳＩＭカードを備えた新しいＩｏＴデバイスを受け取り、１６０２で、ユーザは、空のＳＩＭカードをＩｏＴハブに挿入する。１７０３で、ユーザは、１つ以上の暗号鍵のセットを用いて空のＳＩＭカードをプログラミングする。例えば、上で言及したように、一実施形態では、ＩｏＴハブは、公開／秘密鍵ペアをランダムに生成し、秘密鍵をＳＩＭカード上に、かつ公開鍵をそのローカルの安全な記憶装置内に記憶し得る。加えて、１７０４で、少なくとも公開鍵がＩｏＴサービスに送信され、これにより、それを使用して、ＩｏＴデバイスを識別し、かつＩｏＴデバイスとの暗号化通信を確立し得る。上で言及したように、一実施形態では、「ＳＩＭ」カード以外のプログラム可能なデバイスが、図１７に示される方法でＳＩＭカードと同じ機能を行うために使用されてもよい。

新しいＩｏＴデバイスをネットワークに統合するための方法が、図１８に例示される。本方法は、上述のシステムアーキテクチャ内で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

１８０１で、ユーザは、暗号鍵が予め割り当てられている新しいＩｏＴデバイスを受け取る。１８０２で、この鍵がＩｏＴハブに安全に提供される。上で言及したように、一実施形態では、これは、ＩｏＴデバイスと関連付けられたバーコードを読み取って、デバイスに割り当てられた公開／秘密鍵ペアの公開鍵を識別することを伴う。バーコードは、ＩｏＴハブによって直接読み取られても、又はアプリケーション若しくはブラウザを介してモバイルデバイスによってキャプチャされてもよい。別の実施形態では、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＬＥチャネル、近距離通信（ＮＦＣ）チャネル、又は安全なＷｉＦｉチャネルなどの安全な通信チャネルが、鍵の交換のためにＩｏＴデバイスとＩｏＴハブとの間に確立されてもよい。鍵の送信方法に関わらず、受信されると、それはＩｏＴハブデバイスの安全な鍵ストア内に記憶される。上で言及したように、セキュアエンクレーブ、トラステッド・エグゼキューション・テクノロジー（ＴＸＴ）、及び／又はＴｒｕｓｔｚｏｎｅなどの様々な安全な実行技術が、鍵の記憶及び保護のためにＩｏＴハブで使用され得る。加えて、１８０３で、鍵がＩｏＴサービスに安全に送信され、ＩｏＴサービスが、この鍵をそれ自体の安全な鍵ストア内に記憶する。それは次に、この鍵を使用して、ＩｏＴデバイスとの通信を暗号化し得る。再度、この交換は、証明書／署名付き鍵を使用して実装されてもよい。ハブ１１０内では、記憶された鍵の改変／追加／除去を防止することが特に重要である。

公開／秘密鍵を使用してコマンド／データをＩｏＴデバイスに安全に通信するための方法が、図１９に例示される。本方法は、上述のシステムアーキテクチャ内で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

１９０１で、ＩｏＴサービスは、ＩｏＴデバイス公開鍵を使用してデータ／コマンドを暗号化して、ＩｏＴデバイスパケットを作成する。それは次に、ＩｏＴハブの公開鍵を使用し、このＩｏＴデバイスパケットを暗号化して、ＩｏＴハブパケットを作成する（例えば、ＩｏＴデバイスパケット周囲のＩｏＴハブラッパーを作成）。１９０２で、ＩｏＴサービスは、ＩｏＴハブパケットをＩｏＴハブに送信する。１９０３で、ＩｏＴハブは、ＩｏＴハブの秘密鍵を使用してＩｏＴハブパケットを解読して、ＩｏＴデバイスパケットを生成する。それは次いで、１９０４で、ＩｏＴデバイスパケットをＩｏＴデバイスに送信し、ＩｏＴデバイスは、１９０５において、ＩｏＴデバイス秘密鍵を使用してＩｏＴデバイスパケットを解読して、データ／コマンドを生成する。１９０６で、ＩｏＴデバイスは、データ／コマンドを処理する。

対称鍵を使用するある実施形態では、対称鍵交換は、各デバイス間（例えば、各デバイスとハブと、及びハブとサービスとの間）で交渉され得る。鍵交換が完了すると、各送信デバイスは、対称鍵を使用して各送信を暗号化し、かつ／又はそれに署名し、その後、そのデータを受信デバイスに送信する。

本発明の実施形態は、上で説明した様々な工程を含み得る。本工程は、汎用又は特殊目的のプロセッサに本工程を行わせるために使用され得る、機械実行可能命令において具現化することができる。代替的に、これらの工程は、工程を行うためのハードワイヤードロジックを含む特定のハードウェア構成要素によって、又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって、行うことができる。

本明細書に記載される場合、命令は、ある特定の動作を行うように構成されるか、又は所定の機能若しくはソフトウェア命令が非一時的コンピュータ可読媒体中に具現化されたメモリ内に記憶されている、特定用途向け集積回路（ＡＳＩＣ）などの、ハードウェアの特定の構成を指し得る。したがって、図面に示される技術は、１つ以上の電子デバイス（例えば、エンドステーション、ネットワーク要素など）上に記憶及び実行されるコード及びデータを使用して実装され得る。そのような電子デバイスは、非一時的コンピュータ機械可読記憶媒体（例えば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み出し専用メモリ、フラッシュメモリデバイス、相変化メモリ）、並びに一時的なコンピュータ機械可読通信媒体（例えば、搬送波、赤外線信号、デジタル信号などの電気的、光学的、音響的又は他の形態の伝搬信号）などのコンピュータ機械可読記憶媒体を使用して、コード及びデータを記憶及び（内部で及び／又はネットワークを介して他の電子デバイスと）通信する。加えてそのような電子デバイスは、典型的に、１つ以上の記憶デバイス（非一時的機械可読記憶媒体）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続などの、１つ以上の他の構成要素に連結された１つ以上のプロセッサのセットを含む。プロセッサの組と他の構成要素との連結は、典型的には、１つ以上のバス及びブリッジ（バスコントローラとも呼ばれる）を通じて行われる。記憶デバイスとネットワークトラフィックを運ぶ信号のそれぞれは、１つ以上の機械可読記憶媒体及び機械可読通信媒体を表す。したがって、所与の電子デバイスの記憶デバイスは、その電子デバイスの１つ以上のプロセッサのセット上で実行するためのコード及び／又はデータを典型的に記憶する。当然のことながら、本発明の実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの異なる組み合わせを使用して実装されてもよい。

この詳細な説明全体を通じて、説明を目的として、本発明の完全な理解を提供するために、多数の特定の詳細を記載した。しかしながら、本発明は、これらの具体的な詳細の一部がなくても実施され得ることは、当業者にとって明らかであろう。ある特定の例では、既知の構造及び機能は、本発明の主題を不明瞭にすることを回避するために、詳述しなかった。したがって、本発明の範囲及び趣旨は、以下の特許請求の範囲の観点から判断されるべきである。

Claims (24)

1. ユーザの自宅又はビジネス内での無線デバイスと複数のモノのインターネット（ＩｏＴ）デバイス及び／又はＩｏＴハブとの間の信号強度を示す信号強度データを収集する、システム校正モジュールであって、前記信号強度データを前記ユーザの自宅又はビジネスにおける位置と関連付け、前記関連付けを位置データベースに記憶するものである、システム校正モジュールと、
   前記位置データベースにおける前記信号強度データを、前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブのうちの１つ以上との間の現在の信号強度を示す現在の信号強度データと比較することによって、前記無線デバイスの現在位置を決定する、信号強度分析モジュールと、
   前記無線デバイスにインストールされた校正アプリケーションであって、前記信号強度データを収集するときに前記システム校正モジュールと通信するものであり、１）前記ユーザの自宅又はビジネスにおける異なる部屋及び／又は各部屋内の異なる場所に移動するように、また、２）前記ユーザが前記異なる部屋及び／又は各部屋内の異なる場所の各々に到着したときに前記校正アプリケーションに指示を提供するように前記ユーザに指図するものである、校正アプリケーションと、を備え、
   前記信号強度は、前記無線デバイスから受信される信号の強度である、システム。
2. 前記校正アプリケーションは、前記指示を提供するとすぐに、前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブの各々との間の現在の信号強度データを送信するものである、請求項１に記載のシステム。
3. 前記システム校正モジュール及び信号強度分析モジュールが実行される、ＩｏＴハブを更に含む、請求項１に記載のシステム。
4. 前記位置データベースは、各位置の識別及び各位置と関連付けられた複数の信号強度値を含む、請求項１に記載のシステム。
5. 前記複数の信号強度値は、各位置で前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブとの間で測定された、受信信号強度インジケータ（ＲＳＳＩ）値を含む、請求項４に記載のシステム。
6. 前記信号強度分析モジュールは、現在の信号強度値の組を受信し、それらの値を前記位置データベースにおける前記信号強度データと比較して、前記無線デバイスの前記現在位置を決定するものである、請求項５に記載のシステム。
7. 前記信号強度分析モジュールは、前記現在の信号強度値が、前記位置データベースにおいて指定される前記信号強度値の指定範囲内にある場合に、前記無線デバイスが特定の位置にあると決定するものである、請求項６に記載のシステム。
8. 前記信号強度分析モジュールは、前記無線デバイスが前記特定の位置にあるという前記決定に応じて、ＩｏＴデバイスを制御する１つ以上のＩｏＴデバイスコマンドを送信するものである、請求項７に記載のシステム。
9. 前記無線デバイスが特定の部屋にあると決定するとすぐに、前記信号強度分析モジュールは、それに応じて、前記部屋におけるオーディオスピーカーをオンにする、かつ／又は前記部屋における照明をオンにするものである、請求項８に記載のシステム。
10. 前記無線デバイスが前記特定の部屋にあると決定するとすぐに、前記信号強度分析モジュールは、それに応じて、別の部屋におけるオーディオスピーカーをオフにする、かつ／又は前記別の部屋における照明をオフにするものである、請求項９に記載のシステム。
11. 前記信号強度分析モジュールは、三角測量技術を行って、前記無線デバイスの前記現在位置を決定するものである、請求項１に記載のシステム。
12. 前記三角測量技術は、前記無線デバイスとＩｏＴハブ、前記無線デバイスとＩｏＴデバイスとの間の信号強度値、及び前記ＩｏＴデバイスと前記ＩｏＴハブとの間の信号強度を測定することを含む、請求項１１に記載のシステム。
13. 前記信号強度データは、前記無線デバイスによって収集され、第１のＩｏＴハブに送信される、請求項１に記載のシステム。
14. 前記信号強度データは、近距離無線通信規格を用いて無線通信チャネルについて収集され、前記信号強度データは、異なる無線通信規格を用いて前記無線デバイスから前記第１のＩｏＴハブに送信される、請求項１３に記載のシステム。
15. 前記近距離無線通信規格は、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）を含み、前記異なる無線通信規格は、Ｗｉｆｉ規格を含む、請求項１４に記載のシステム。
16. ユーザの自宅又はビジネス内での無線デバイスと複数のＩｏＴデバイス及び／又はＩｏＴハブとの間の信号強度を示す信号強度データを収集することと、
    前記信号強度データを前記ユーザの自宅又はビジネスにおける位置と関連付けて、前記関連付けを位置データベースに記憶することと、
    前記位置データベースにおける前記信号強度データを、前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブとの間の現在の信号強度を示す現在の信号強度データと比較することによって、前記自宅又はビジネス内の前記無線デバイスの現在位置を決定することと、を含み、
    信号強度データを収集することは、前記無線デバイス上の校正アプリケーションにより前記ＩｏＴハブと通信することを更に含み、前記校正アプリケーションは、１）前記ユーザの自宅又はビジネスにおける異なる部屋及び／又は各部屋内の異なる場所に移動するように、また、２）前記ユーザが前記異なる部屋及び／又は各部屋内の異なる場所の各々に到着したときに前記校正アプリケーションに指示を提供するように前記ユーザに指図するものであり、
    前記信号強度は、前記無線デバイスから受信される信号の強度である、方法。
17. 前記校正アプリケーションは、前記指示を提供するとすぐに、前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブの各々との間の現在の信号強度データを送信するものである、請求項１６に記載の方法。
18. 前記位置データベースは、各位置の識別及び各位置と関連付けられた複数の信号強度値を含む、請求項１６に記載の方法。
19. 前記複数の信号強度値は、各位置で前記無線デバイスと前記複数のＩｏＴデバイス及び／又はＩｏＴハブとの間で測定された、受信信号強度インジケータ（ＲＳＳＩ）値を含む、請求項１８に記載の方法。
20. 現在位置を決定することは、現在の信号強度値の組を受信し、それらの値を前記位置データベースにおける前記信号強度データと比較して、前記無線デバイスの前記現在位置を決定することを更に含む、請求項１９に記載の方法。
21. 前記現在位置を決定することは、前記現在の信号強度値が、前記位置データベースにおいて指定される前記信号強度値の指定範囲内にある場合に、前記無線デバイスが特定の位置にあると決定することを更に含む、請求項２０に記載の方法。
22. 前記無線デバイスが前記特定の位置にあるという前記決定に応じて、ＩｏＴデバイスを制御する１つ以上のＩｏＴデバイスコマンドを送信することを更に含む、請求項２１に記載の方法。
23. 前記無線デバイスが特定の部屋にあると決定するとすぐに、それに応じて、前記部屋におけるオーディオスピーカーをオンにする、かつ／又は前記部屋における照明をオンにする、請求項２２に記載の方法。
24. 前記無線デバイスが前記特定の部屋にあると決定するとすぐに、それに応じて、別の部屋におけるオーディオスピーカーをオフにする、かつ／又は前記別の部屋における照明をオフにする、請求項２３に記載の方法。