JP7004654B2 - モノのインターネット（ＩｏＴ）デバイスを制御するための二次の通信チャネルを確立するためのシステム及び方法 - Google Patents

Description

（背景）
本発明は、概して、コンピュータシステムの分野に関する。より具体的には、本発明は、ＩｏＴデバイスを制御するための二次の通信チャネルを確立するためのシステム及び方法に関する。

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

本出願の譲受人は、ＩｏＴデバイスが安全な鍵交換を実行してＩｏＴサービスとの安全な通信チャネルを確立するシステムを開発した。いったん安全な通信チャネルが確立されると、ＩｏＴサービスは、ＩｏＴデバイスからのデータを安全に制御して受信してもよい。しかし、場合によっては、例えば、ＩｏＴサービスがアクセス不可能であるとき（例えば、ネットワークコネクティビティが失われているとき）等に、第２のチャネルがＩｏＴデバイスによって確立されるのを可能にすることが好ましい場合がある。
本発明のより良好な理解は、以下の図面と併せた以下の詳細な説明から得ることができる。

ＩｏＴシステムアーキテクチャの異なる実施形態を例示する。 ＩｏＴシステムアーキテクチャの異なる実施形態を例示する。 本発明の一実施形態によるＩｏＴデバイスを例示する。 本発明の一実施形態によるＩｏＴハブを例示する。 ＩｏＴデバイスからのデータを制御及び収集し、通知を生成するための本発明の実施形態を例示する。 ＩｏＴデバイスからのデータを制御及び収集し、通知を生成するための本発明の実施形態を例示する。 ＩｏＴデバイスからのデータを収集し、ＩｏＴハブ及び／又はＩｏＴサービスからの通知を生成するための本発明の実施形態を例示する。 中間モバイルデバイスが固定ＩｏＴデバイスからデータを収集し、データをＩｏＴハブに提供する、システムの一実施形態を例示する。 本発明の一実施形態で実装される中間接続ロジックを例示する。 本発明の一実施形態による方法を例示する。 プログラムコード及びデータ更新がＩｏＴデバイスに提供される一実施形態を例示する。 プログラムコード及びデータ更新がＩｏＴデバイスに提供される方法の一実施形態を例示する。 セキュリティアーキテクチャの一実施形態の高レベル図を例示する。 ＩｏＴデバイス上に鍵を記憶するために加入者識別モジュール（subscriber identity module）（ＳＩＭ）が使用されるアーキテクチャの一実施形態を例示する。 バーコード又はＱＲコード（登録商標）を使用してＩｏＴデバイスが登録される一実施形態を例示する。 バーコード又はＱＲコードを使用してペアリングが実行される一実施形態を例示する。 ＩｏＴハブを使用してＳＩＭをプログラミングするための方法の一実施形態を例示する。 ＩｏＴデバイスをＩｏＴハブ及びＩｏＴサービスに登録するための方法の一実施形態を例示する。 ＩｏＴデバイスに送信されるデータを暗号化するための方法の一実施形態を例示する。 ＩｏＴサービスとＩｏＴデバイスとの間でデータを暗号化するための本発明の異なる実施形態を例示する。 ＩｏＴサービスとＩｏＴデバイスとの間でデータを暗号化するための本発明の異なる実施形態を例示する。 安全な鍵交換を実行し、共通シークレットを生成し、シークレットを使用してキーストリームを生成するための本発明の実施形態を例示する。 本発明の一実施形態によるパケット構造を例示する。 ＩｏＴデバイスと正式にペアリングすることなくＩｏＴデバイスとの間でデータを読み書きするための一実施形態に用いられる技術を例示する。 本発明の一実施形態で用いられるコマンドパケットの例示的なセットを例示する。 コマンドパケットを使用したトランザクションの例示的なシーケンスを例示する。 本発明の一実施形態による方法を例示する。 本発明の一実施形態による安全なペアリングのための方法を例示する。 本発明の一実施形態による安全なペアリングのための方法を例示する。 本発明の一実施形態による安全なペアリングのための方法を例示する。 本発明の一実施形態によるシステムアーキテクチャを例示する。 本発明の一実施形態による一体式の安全ＩｏＴデバイスを例示する。 一体式の安全ＩｏＴデバイスが、本発明の一実施形態によるドアに結合されてもよいことをここに例示する。 圧力センサを備える本発明の別の実施形態を例示する。 圧力センサを備える本発明の別の実施形態を例示する。 本発明の一実施形態による方法を例示する。 二次の通信チャネルを支えるシステムアーキテクチャを例示する。 二次の通信チャネルを実装するための方法を例示する。 データ送信状態を識別するためのアドバタイジング間隔を調節するための本発明の一実施形態を例示する。 本発明の一実施形態による方法を例示する。 本発明の一実施形態による典型的なコマンド及び応答パターンを例示する。 無線通信パターンを不明瞭化するための本発明の一実施形態を例示する。 ＩｏＴサービスとＩｏＴデバイス１０１との間の通信を曖昧化するための別の実施形態を例示する。 本発明の一実施形態による方法を例示する。 本発明の一実施形態による別の方法を例示する。 データ送信状態を識別するためのアドバタイジング間隔を調節するための本発明の一実施形態を例示する。 本発明の一実施形態による方法を例示する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述したように、Ｂｌｕｅｔｏｏｔｈ ＬＥなどのＩｏＴデバイスを相互接続するために使用される無線技術は概して、近距離技術であるため、ＩｏＴ実装のためのハブがＩｏＴデバイスの範囲外にある場合、ＩｏＴデバイスは、ＩｏＴハブにデータを送信することができない（逆もまた同様）。

この欠陥に対処するために、本発明の一実施形態は、モバイルデバイスが範囲内にあるとき、１つ以上のモバイルデバイスと周期的に接続するために、ＩｏＴハブの無線範囲外にあるＩｏＴデバイスのための機構を提供する。いったん接続されると、ＩｏＴデバイスは、ＩｏＴハブに提供される必要がある任意のデータをモバイルデバイスに送信することができ、次いでモバイルデバイスは、ＩｏＴハブにデータを転送する。

図６に例示するように、一実施形態は、ＩｏＴハブ１１０と、ＩｏＴハブ１１０の範囲外にあるＩｏＴデバイス６０１と、モバイルデバイス６１１とを含む。範囲外のＩｏＴデバイス６０１は、データを収集及び通信することが可能な任意の形態のＩｏＴデバイスを含んでもよい。例えば、ＩｏＴデバイス６０１は、冷蔵庫内の利用可能な食料品、食料品を消費するユーザ、及び現在の温度を監視するように、冷蔵庫内に構成されたデータ収集デバイスを備えてもよい。当然のことながら、本発明の基本原理は、いかなる特定のタイプのＩｏＴデバイスにも限定されない。本明細書に記載される技術は、ほんの数例を挙げると、スマートメータ、コンロ、洗濯機、乾燥機、照明システム、ＨＶＡＣシステム、及び視聴覚機器に関するデータを収集及び送信するために使用されるデバイスを含む、任意のタイプのＩｏＴデバイスを使用して実装されてもよい。

更に、動作中のモバイルデバイスである、図６に例示するＩｏＴデバイス６１１は、データを通信及び記憶することが可能な任意の形態のモバイルデバイスであってもよい。例えば、一実施形態では、モバイルデバイス６１１は、本明細書に記載される技術を促進するために、アプリケーションがその上にインストールされたスマートフォンである。別の実施形態では、モバイルデバイス６１１は、ネックレス若しくはブレスレットに取り付けられた通信トークン、スマートウォッチ、又はフィットネスデバイスなど、装着可能なデバイスを含む。装着可能なトークンは、スマートフォンデバイスを所有しない高齢のユーザ又は他のユーザにとって特に有用であり得る。

動作中、範囲外のＩｏＴデバイス６０１は、モバイルデバイス６１１との接続性を周期的又は連続的にチェックしてもよい。接続を確立した後（例えば、ユーザが冷蔵庫の近くを移動する結果として）、ＩｏＴデバイス６０１上の任意の収集されたデータ６０５が、モバイルデバイス６１１上の一時データリポジトリ６１５に自動的に送信される。一実施形態では、ＩｏＴデバイス６０１及びモバイルデバイス６１１は、ＢＴＬＥなどの低電力無線標準を使用して、ローカル無線通信チャネルを確立する。そのような場合、モバイルデバイス６１１は、既知のペアリング技術を使用してＩｏＴデバイス６０１と最初にペアリングされてもよい。

いったんデータが一時データリポジトリに伝送されると、モバイルデバイス６１１は、ＩｏＴハブ１１０との通信が確立されるとデータを送信する（例えば、ユーザがＩｏＴハブ１１０の範囲内を歩くとき）。次いで、ＩｏＴハブは、中央データリポジトリ４１３にデータを記憶してもよく、かつ／又はインターネット上で、１つ以上のサービス及び／若しくは他のユーザデバイスにデータを送信してもよい。一実施形態では、モバイルデバイス６１１は、異なるタイプの通信チャネルを使用して、ＩｏＴハブ１１０にデータを提供してもよい（潜在的に、ＷｉＦｉなどのより高出力の通信チャネル）。

範囲外のＩｏＴデバイス６０１、モバイルデバイス６１１、及びＩｏＴハブはすべて、本明細書に記載される技術を実装するためのプログラムコード及び／又はロジックにより構成されてもよい。図７に例示するように、例えば、本明細書に記載される動作を実行するために、ＩｏＴデバイス６０１は、中間接続ロジック及び／又はアプリケーションにより構成されてもよく、モバイルデバイス６１１は、中間接続ロジック／アプリケーションにより構成されてもよく、ＩｏＴハブ１１０は、中間接続ロジック／アプリケーション７２１により構成されてもよい。各デバイス上の中間接続ロジック／アプリケーションは、ハードウェア、ソフトウェア、又はこれらの任意の組み合わせで実装されてもよい。一実施形態では、ＩｏＴデバイス６０１の中間接続ロジック／アプリケーション７０１は、モバイルデバイス上の中間接続ロジック／アプリケーション７１１（デバイスアプリケーションとして実装されてもよい）との接続を検索及び確立して、一時データリポジトリ６１５にデータを伝送する。次いで、モバイルデバイス６１１上の中間接続ロジック／アプリケーション７０１は、中央データリポジトリ４１３にデータを記憶するＩｏＴハブ上の中間接続ロジック／アプリケーションに、データを転送する。

図７に例示するように、各デバイス上の中間接続ロジック／アプリケーション７０１、７１１、７２１は、手元のアプリケーションに基づき構成されてもよい。例えば、冷蔵庫に関して、接続ロジック／アプリケーション７０１は、周期的ベースで少数のパケットを送信するだけでよい。他のアプリケーション（例えば、温度センサ）に対して、接続ロジック／アプリケーション７０１は、より頻繁な更新を送信する必要があり得る。

モバイルデバイス６１１よりはむしろ、一実施形態では、ＩｏＴデバイス６０１が、ＩｏＴハブ１１０の範囲内に位置する１つ以上の中間ＩｏＴデバイスとの無線接続を確立するように構成されてもよい。この実施形態では、ＩｏＴハブの範囲外の任意のＩｏＴデバイス６０１が、他のＩｏＴデバイスを使用して「チェーン」を形成することによってハブにリンクされてもよい。

加えて、簡潔にするために、単一のモバイルデバイス６１１のみが図６及び図７に例示されるが、一実施形態では、異なるユーザの複数のそのようなモバイルデバイスは、ＩｏＴデバイス６０１と通信するように構成されてもよい。更に、同じ技術が、複数の他のＩｏＴデバイスに対して実装されてもよく、それにより、自宅全体にわたって中間デバイスデータ収集システムを形成する。

更に、一実施形態では、本明細書に記載される技術は、様々な異なるタイプの関連データを収集するために使用されてもよい。例えば、一実施形態では、モバイルデバイス６１１がＩｏＴデバイス６０１と接続するたびに、ユーザの識別が、収集されたデータ６０５と共に含まれてもよい。このようにして、ＩｏＴシステムは、自宅内の異なるユーザの挙動を追跡するために使用されてもよい。例えば、冷蔵庫内で使用される場合、収集されたデータ６０５は、冷蔵庫のそばを通る各ユーザ、冷蔵庫を開ける各ユーザ、及び各ユーザによって消費される特定の食料品の識別を含んでもよい。異なるタイプのデータが、他のタイプのＩｏＴデバイスから収集されてもよい。このデータを使用して、システムは、例えば、どのユーザが衣服を洗濯するのか、どのユーザが所与の日にテレビを観るのか、各ユーザが就寝及び起床する時間などを判定することが可能である。次いで、このクラウドソースデータのすべてが、ＩｏＴハブのデータリポジトリ４１３内にコンパイルされてもよく、かつ／又は外部サービス若しくはユーザに転送されてもよい。

本明細書に記載される技術の別の有益な用途は、補助を必要とし得る高齢のユーザを監視するためのものである。このアプリケーションに関して、モバイルデバイス６１１は、ユーザの自宅の異なる室内の情報を収集するために、高齢のユーザによって装着された非常に小型のトークンであってもよい。ユーザが冷蔵庫を開けるたびに、例えば、このデータは、収集されたデータ６０５と共に含まれ、トークンを介してＩｏＴハブ１１０に伝送される。次いで、ＩｏＴハブは、１つ以上の外部ユーザ（例えば、高齢のユーザを世話する子供又は他の個人）にデータを提供してもよい。データが指定された期間（例えば、１２時間）収集されていない場合、これは、高齢のユーザが自宅を動き回っていない、かつ／又は冷蔵庫を開けていないことを意味する。次いで、ＩｏＴハブ１１０又はＩｏＴハブに接続された外部サービスは、これらの他の個人にアラート通知を送信し、彼らに高齢のユーザを確認するべきであることを通知してもよい。加えて、収集されたデータ６０５は、ユーザによって消費されている食品、並びに食料品店に行くことが必要であるかどうか、高齢のユーザがテレビを観ているかどうか、及びどれほど頻繁に観ているか、高齢のユーザが衣服を洗濯する頻度などの他の関連情報を含んでもよい。

別の実装例において、洗濯機、冷蔵庫、ＨＶＡＣシステムなどの電子デバイスに問題がある場合、収集されたデータは、交換される必要がある部品の指示を含んでもよい。そのような場合、通知は、問題を解決するための要求と共に技術者に送信されてもよい。次いで、技術者は、必要とされる交換部品を持って自宅に到着し得る。

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

８０１において、ＩｏＴハブの範囲外にあるＩｏＴデバイスは、データ（例えば、冷蔵庫の扉の開放、使用された食料品など）を周期的に収集する。８０２において、ＩｏＴデバイスは、モバイルデバイスとの接続性を周期的又は連続的にチェックする（例えば、ＢＴＬＥ標準によって指定されたものなど、接続を確立するための標準的なローカル無線技術を使用して）。８０２において、モバイルデバイスへの接続が確立され、判定された場合、８０３において、収集されたデータは、８０３においてモバイルデバイスに伝送される。８０４において、モバイルデバイスは、ＩｏＴハブ、外部サービス、及び／又はユーザにデータを伝送する。述べられたように、モバイルデバイスは、それが既に接続されている場合（例えば、ＷｉＦｉリンクを介して）、すぐにデータを送信し得る。

ＩｏＴデバイスからデータを収集することに加えて、一実施形態では、本明細書に記載される技術は、データを更新するか、又は別様にＩｏＴデバイスにデータを提供するために使用されてもよい。一例が図９Ａに示され、それは、ＩｏＴデバイス６０１（又はそのようなＩｏＴデバイスの群）上にインストールされる必要があるプログラムコード更新９０１を有する、ＩｏＴハブ１１０を示す。プログラムコード更新は、システム更新、パッチ、コンフィギュレーションデータ、及びＩｏＴデバイスがユーザの要求通り動作するために必要とされる任意の他のデータを含んでもよい。一実施形態では、ユーザは、モバイルデバイス又はコンピュータを介してＩｏＴデバイス６０１に対するコンフィギュレーションオプションを指定してもよく、それらは次いで、本明細書に記載される技術を使用して、ＩｏＴハブ１１０上に記憶され、かつＩｏＴデバイスに提供される。具体的には、一実施形態では、ＩｏＴハブ１１０上の中間接続ロジック／アプリケーション７２１は、モバイルデバイス６１１上の中間接続ロジック／アプリケーション７１１と通信して、一時記憶装置６１５内にプログラムコード更新を記憶する。モバイルデバイス６１１がＩｏＴデバイス６０１の範囲に入るとき、モバイルデバイス６１１上の中間接続ロジック／アプリケーション７１１は、ＩｏＴデバイス６０１上の中間／接続ロジック／アプリケーション７０１と接続して、デバイスにプログラムコード更新を提供する。一実施形態では、ＩｏＴデバイス６０１は次いで、新しいプログラムコード更新及び／又はデータをインストールするための自動更新プロセスに入ってもよい。

ＩｏＴデバイスを更新するための方法が、図９Ｂに示される。本方法は、上記のシステムアーキテクチャとの関連で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

９００において、新しいプログラムコード又はデータ更新は、ＩｏＴハブ及び／又は外部サービス（例えば、インターネット上でモバイルデバイスに連結された）上で利用可能になる。９０１において、モバイルデバイスは、ＩｏＴデバイスの代わりにプログラムコード又はデータ更新を受信及び記憶する。ＩｏＴデバイス及び／又はモバイルデバイスは、９０２において接続が確立されているかどうかを判定するために周期的にチェックする。９０３において接続が確立され、判定された場合、９０４において、更新は、ＩｏＴデバイスに伝送され、インストールされる。
改善されたセキュリティのための実施形態

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

対称鍵を使用するある実施形態において、対称鍵交換は、各デバイス間（例えば、各デバイスとハブと、及びハブとサービスとの間）で交渉され得る。鍵交換が完了すると、各送信デバイスは、対称鍵を使用して各送信を暗号化し、かつ／又はそれに署名し、その後、データを受信デバイスに送信する。
モノのインターネット（ＩｏＴ）システムに安全な通信を確立するための装置及び方法

本発明の一実施形態では、通信チャネルをサポートするために使用される中間デバイス（例えば、ユーザのモバイルデバイス６１１及び／又はＩｏＴハブ１１０など）に関わらず、データの暗号化及び解読は、ＩｏＴサービス１２０と各ＩｏＴデバイス１０１との間で実行される。ＩｏＴハブ１１０を介して通信する一実施形態が図１６Ａに例示され、ＩｏＴハブを必要としない別の実施形態が図１６Ｂに例示される。

最初に図１６Ａで、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間の通信を暗号化／解読するために、ＩｏＴサービス１２０は、「サービスセッション鍵」１６５０のセットを管理する暗号化エンジン１６６０を含み、各ＩｏＴデバイス１０１は、「デバイスセッション鍵」１６５１のセットを管理する暗号化エンジン１６６１を含む。暗号化エンジンは、本明細書に記載するセキュリティ／暗号化技術を実行するとき、セッション公開／秘密鍵ペアを生成して、このペアのセッション秘密鍵へのアクセスを防止するための（他のものの中でも）ハードウェアセキュリティモジュール１６３０～１６３１、及び導出したシークレットを使用してキーストリームを生成するためのキーストリーム生成モジュール１６４０～１６４１を含む、異なるハードウェアモジュールに依拠することができる。一実施形態では、サービスセッション鍵１６５０及びデバイスセッション鍵１６５１は、関連する公開／秘密鍵ペアを含む。例えば、一実施形態では、ＩｏＴデバイス１０１上のデバイスセッション鍵１６５１は、ＩｏＴサービス１２０の公開鍵、及びＩｏＴデバイス１０１の秘密鍵を含む。以下に詳細に説明するように、一実施形態では、安全な通信セッションを確立するために、セッション公開／秘密鍵ペア１６５０及び１６５１がそれぞれの暗号化エンジン、それぞれ１６６０及び１６６１によって使用されて、同じシークレットを生成し、このシークレットは次にＳＫＧＭ１６４０～１６４１によって使用されて、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間の通信を暗号化及び解読するキーストリームを生成する。本発明の一実施形態によるシークレットの生成及び使用に関連付けられた追加の詳細は、以下に提供される。

図１６Ａで、鍵１６５０～１６５１を使用してシークレットが生成されると、クライアントは、クリアトランザクション１６１１によって示されるように常にＩｏＴサービス１２０を介してＩｏＴデバイス１０１にメッセージを送信することになる。本明細書で使用されるとき「クリア」は、根本的なメッセージが本明細書に記載された暗号化技術を使用して暗号化されていないことを示すことを意味する。しかし、例示したように、一実施形態では、セキュアソケットレイヤー（ＳＳＬ）チャネル又は他の安全なチャネル（例えば、インターネットプロトコルセキュリティ（Internet Protocol Security）（ＩＰＳＥＣ）チャネル）は、通信を保護するためにクライアントデバイス６１１とＩｏＴサービス１２０との間で確立される。ＩｏＴサービス１２０上の暗号化エンジン１６６０は、次に、生成されたシークレットを使用してメッセージを暗号化して、１６０２で暗号化メッセージをＩｏＴハブ１１０に送信する。メッセージを直接暗号化するためにシークレットを使用するのではなく、一実施形態では、シークレット及びカウンタ値を使用して、キーストリームを生成し、このキーストリームを使用して、それぞれのメッセージパケットを暗号化する。この実施形態の詳細は、図１７に関して以下に説明する。

例示したように、ＳＳＬ接続又は他の安全なチャネルは、ＩｏＴサービス１２０とＩｏＴハブ１１０との間で確立することができる。ＩｏＴハブ１１０（一実施形態ではメッセージを解読する能力を有さない）は、１６０３で（例えば、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）通信チャネルを介して）暗号化メッセージをＩｏＴデバイスに送信する。ＩｏＴデバイス１０１上の暗号化エンジン１６６１は、次に、シークレットを使用してメッセージを解読して、メッセージコンテンツを処理することができる。キーストリームを生成するためにシークレットを使用する実施形態では、暗号化エンジン１６６１は、シークレット及びカウンタ値を使用してキーストリームを生成し、次にメッセージパケットの解読のためにキーストリームを使用することができる。

メッセージ自体は、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間の任意の形態の通信を含むことができる。例えば、メッセージは、測定を行ってその結果をクライアントデバイス６１１に通知して返すことなどの特定の機能を実行することをＩｏＴデバイス１０１に命令するコマンドパケットを含むことができる、又はＩｏＴデバイス１０１の動作を構成するコンフィギュレーションデータを含むことができる。

応答が必要とされる場合、ＩｏＴデバイス１０１上の暗号化エンジン１６６１は、シークレット又は導出されたキーストリームを使用して、応答を暗号化し、１６０４で暗号化応答をＩｏＴハブ１１０に送信し、ＩｏＴハブ１１０は、１６０５で応答をＩｏＴサービス１２０に転送する。ＩｏＴサービス１２０上の暗号化エンジン１６６０は、次に、シークレット又は導出されたキーストリームを使用して応答を解読して、１６０６で（例えば、ＳＳＬ又は他の安全な通信チャネルを介して）解読された応答をクライアントデバイス６１１に送信する。

図１６Ｂは、ＩｏＴハブを必要としない実施形態を例示する。むしろ、この実施形態では、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間の通信は、クライアントデバイス６１１を介して行われる（例えば、図６～図９Ｂに関して上述した実施形態におけるように）。この実施形態では、メッセージをＩｏＴデバイス１０１に送信するために、クライアントデバイス６１１は、１６１１でメッセージの非暗号化バージョンをＩｏＴサービス１２０に送信する。暗号化エンジン１６６０は、シークレット又は導出されたキーストリームを使用してメッセージを暗号化して、１６１２で暗号化メッセージをクライアントデバイス６１１に返送する。クライアントデバイス６１１は、次に、１６１３で暗号化メッセージをＩｏＴデバイス１０１に転送し、暗号化エンジン１６６１は、シークレット又は導出されたキーストリームを使用してメッセージを解読する。ＩｏＴデバイス１０１は、次に、本明細書に記載されたようにメッセージを処理することができる。応答が必要とされる場合、暗号化エンジン１６６１は、シークレットを使用して、応答を暗号化し、１６１４で暗号化応答をクライアントデバイス６１１に送信し、クライアントデバイス６１１は、１６１５で暗号化応答をＩｏＴサービス１２０に転送する。暗号化エンジン１６６０は、次に、応答を解読して、１６１６で解読された応答をクライアントデバイス６１１に送信する。

図１７は、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間で最初に実行することができる鍵交換及びキーストリーム生成を例示する。一実施形態では、この鍵交換は、ＩｏＴサービス１２０及びＩｏＴデバイス１０１が新しい通信セッションを確立するたびに実行することができる。代替的に、鍵交換を実行することができ、交換されたセッション鍵を指定された期間（例えば、一日、一週間など）使用することができる。簡潔にするために図１７に中間デバイスは示されていないが、通信は、ＩｏＴハブ１１０及び／又はクライアントデバイス６１１を介して行うことができる。

一実施形態では、ＩｏＴサービス１２０の暗号化エンジン１６６０は、セッション公開／秘密鍵ペアを生成するために、コマンドをＨＳＭ１６３０（例えば、Ａｍａｚｏｎ（登録商標）によって提供されるＣｌｏｕｄＨＳＭなどとすることができる）に送信する。ＨＳＭ１６３０は、その後、このペアのセッション秘密鍵へのアクセスを防止することができる。同様に、ＩｏＴデバイス１０１上の暗号化エンジンは、セッション公開／秘密鍵ペアを生成してこのペアのセッション秘密鍵へのアクセスを防止するＨＳＭ１６３１（例えば、Ａｔｍｅｌ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）によるＡｔｅｃｃ５０８ ＨＳＭなどの）にコマンドを送信することができる。当然のことながら、本発明の基本原理は、いかなる特定のタイプの暗号化エンジン又は製造業者にも限定されない。

一実施形態では、ＩｏＴサービス１２０は、１７０１で、ＨＳＭ１６３０を使用して生成されたそのセッション公開鍵をＩｏＴデバイス１０１に送信する。ＩｏＴデバイスは、そのＨＳＭ１６３１を使用して、それ自体のセッション公開／秘密鍵ペアを生成し、１７０２でそのペアの公開鍵をＩｏＴサービス１２０に送信する。一実施形態では、暗号化エンジン１６６０～１６６１は、楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ（Elliptic curve Diffie-Hellman）（ＥＣＤＨ）プロトコルを使用し、このプロトコルは、楕円曲線公開－秘密鍵ペアを有する２つの当事者が共有シークレットを確立することができる匿名鍵の取り決めである。一実施形態では、これらの技術を使用して、１７０３で、ＩｏＴサービス１２０の暗号化エンジン１６６０は、ＩｏＴデバイスセッション公開鍵及びそれ自体のセッション秘密鍵を使用してシークレットを生成する。同様に、１７０４で、ＩｏＴデバイス１０１の暗号化エンジン１６６１は、ＩｏＴサービス１２０のセッション公開鍵及びそれ自体のセッション秘密鍵を使用して同じシークレットを独自に生成する。より具体的には、一実施形態では、ＩｏＴサービス１２０上の暗号化エンジン１６６０は、シークレット＝ＩｏＴデバイスセッション公開鍵^*ＩｏＴサービスセッション秘密鍵という式に従って、シークレットを生成し、ここで（^*）は、ＩｏＴデバイスセッション公開鍵がＩｏＴサービスセッション秘密鍵によって点乗積されることを意味する。ＩｏＴデバイス１０１上の暗号化エンジン１６６１は、シークレット＝ＩｏＴサービスセッション公開鍵^*ＩｏＴデバイスセッション秘密鍵という式に従って、シークレットを生成し、ＩｏＴサービスセッション公開鍵は、ＩｏＴデバイスセッション秘密鍵によって点乗積される。結局、ＩｏＴサービス１２０及びＩｏＴデバイス１０１は両方とも、以下に説明するように通信を暗号化するのに使用される同じシークレットを生成した。一実施形態では、暗号化エンジン１６６０～１６６１は、シークレットを生成するための上記の動作を実行するＫＳＧＭ、それぞれ１６４０～１６４１などのハードウェアモジュールに依拠する。

シークレットが決定されると、シークレットは、暗号化エンジン１６６０及び１６６１によって使用されて、データを直接暗号化及び解読することができる。代替的に、一実施形態では、暗号化エンジン１６６０～１６６１は、コマンドをＫＳＧＭ１６４０～１６４１に送信して、それぞれのデータパケットを暗号化／解読するためにシークレットを使用して新しいキーストリームを生成する（すなわち、それぞれのパケットに対して新しいキーストリームデータ構造が生成される）。具体的には、キーストリーム生成モジュール１６４０～１６４１の一実施形態は、それぞれのデータパケットに対してカウンタ値が増加され、キーストリームを生成するためにシークレットと組み合わせて使用される、Ｇａｌｏｉｓ／カウンタモード（Galois／Counter Mode）（ＧＣＭ）を実装する。したがって、データパケットをＩｏＴサービス１２０に送信するために、ＩｏＴデバイス１０１の暗号化エンジン１６６１は、シークレット及び現在のカウンタ値を使用して、ＫＳＧＭ１６４０～１６４１に新しいキーストリームを生成させ、次のキーストリームを生成するためにカウンタ値を増加させる。次に、新たに生成されたキーストリームを使用して、データパケットを暗号化し、その後、ＩｏＴサービス１２０に送信される。一実施形態では、キーストリームは、データでＸＯＲされて、暗号化データパケットを生成する。一実施形態では、ＩｏＴデバイス１０１は、カウンタ値を暗号化データパケットと共にＩｏＴサービス１２０に送信する。ＩｏＴサービス上の暗号化エンジン１６６０は、次に、ＫＳＧＭ１６４０と通信し、ＫＳＧＭ１６４０は、受信したカウンタ値及びシークレットを使用して、キーストリーム（同じシークレット及びカウンタ値が使用されるので同じキーストリームでなければならない）を生成し、生成されたキーストリームを使用して、データパケットを解読する。

一実施形態では、ＩｏＴサービス１２０からＩｏＴデバイス１０１に送信されるデータパケットは、同じ方法で暗号化される。具体的には、それぞれのデータパケットに対してカウンタが増加されて、シークレットと共に使用されて、新しいキーストリームを生成する。キーストリームは、次に、データを暗号化するために使用され（例えば、データ及びキーストリームのＸＯＲを実行して）、暗号化データパケットは、カウンタ値と共にＩｏＴデバイス１０１に送信される。ＩｏＴデバイス１０１上の暗号化エンジン１６６１は、次に、ＫＳＧＭ１６４１と通信し、ＫＳＧＭ１６４１は、カウンタ値及びシークレットを使用して、データパケットを解読するために使用される同じキーストリームを生成する。したがって、この実施形態では、暗号化エンジン１６６０～１６６１は、それら自体のカウンタ値を使用して、データを暗号化するキーストリームを生成し、暗号化データパケットと共に受信したカウンタ値を使用して、データを解読するキーストリームを生成する。

一実施形態では、それぞれの暗号化エンジン１６６０～１６６１は、それが他方から受信した最後のカウンタ値を追跡し、カウンタ値がシーケンス外で受信されたか否か又は同じカウンタ値が１回より多く受信されたか否かを検出するシーケンシングロジックを含む。カウンタ値がシーケンス外で受信された場合、又は同じカウンタ値が１回より多く受信された場合、これは、リプレイアタックが試みられていることを示し得る。それに応答して、暗号化エンジン１６６０～１６６１は、通信チャネルから接続を切ることができる、及び／又はセキュリティアラートを生成することができる。

図１８は、４バイトのカウンタ値１８００と、可変サイズの暗号化データフィールド１８０１と、６バイトのタグ１８０２とを含む、本発明の一実施形態で用いられる例示的な暗号化データパケットを例示する。一実施形態では、タグ１８０２は、解読されたデータ（それが解読されたら）の妥当性を確認するチェックサム値を含む。

上述したように、一実施形態では、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間で交換されたセッション公開／秘密鍵ペア１６５０～１６５１は、定期的に、及び／又はそれぞれの新しい通信セッションの開始に応答して生成することができる。

本発明の一実施形態は、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間のセッションを認証するための追加の技術を実装する。具体的には、一実施形態では、親鍵ペア、工場鍵ペアのセット、並びにＩｏＴサービス鍵ペアのセット及びＩｏＴデバイス鍵ペアのセットを含む、公開／秘密鍵ペアの階層が使用される。一実施形態では、親鍵ペアは、他の鍵ペアのすべてに対する信頼のルートを含み、単一の高度に安全な場所に（例えば、本明細書に記載されたＩｏＴシステムを実装する組織の管理下に）維持される。マスター秘密鍵を使用して、工場鍵ペアなどの様々な他の鍵ペアの上に署名を生成する（及びそれによって認証する）ことができる。署名は、次に、マスター公開鍵を使用して検証することができる。一実施形態では、ＩｏＴデバイスを製造するそれぞれの工場は、それ自体の工場鍵ペアを割り当てられ、工場鍵ペアは、次に、ＩｏＴサービス鍵及びＩｏＴデバイス鍵を認証するために使用することができる。例えば、一実施形態では、工場秘密鍵を使用して、ＩｏＴサービス公開鍵及びＩｏＴデバイス公開鍵の上に署名を生成する。これらの署名は、次に、対応する工場公開鍵を使用して検証することができる。これらのＩｏＴサービス／デバイス公開鍵は、図１６Ａ～図１６Ｂに関して上述した「セッション」公開／秘密鍵と同じではないことに留意されたい。上述したセッション公開／秘密鍵は、一時的であり（すなわち、サービス／デバイスセッションに対して生成される）、一方、ＩｏＴサービス／デバイス鍵ペアは、恒久的なものである（すなわち、工場で生成される）。

親鍵、工場鍵、サービス／デバイス鍵の間の上述の関係を念頭に、本発明の一実施形態は、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間の認証及びセキュリティの追加のレイヤを提供するために、以下の動作を実行する。
Ａ．一実施形態では、ＩｏＴサービス１２０は、最初に、以下を含むメッセージを生成する。
１．ＩｏＴサービスの一意的なＩＤ：
・ＩｏＴサービスのシリアルナンバー、
・タイムスタンプ、
・この一意的なＩＤに署名するために使用される工場鍵のＩＤ、
・一意的なＩＤ（すなわち、サービス）のクラス、
・ＩｏＴサービスの公開鍵、
・一意的なＩＤの上の署名。
２．以下を含む工場証明書：
・タイムスタンプ、
・証明書に署名するために使用される親鍵のＩＤ、
・工場公開鍵、
・工場証明書の署名。
３．ＩｏＴサービスセッション公開鍵（図１６Ａ～図１６Ｂに関して上述したような）。
４．ＩｏＴサービスセッション公開鍵署名（例えば、ＩｏＴサービスの秘密鍵で署名された）。
Ｂ．一実施形態では、メッセージは、交渉チャネル（以下に説明する）上でＩｏＴデバイスに送信される。ＩｏＴデバイスは、メッセージを解析して：
１．工場証明書の署名（メッセージペイロード内に存在する場合のみ）を検証する。
２．一意的なＩＤによって識別された鍵を使用して一意的なＩＤの署名を検証する。
３．一意的なＩＤからのＩｏＴサービスの公開鍵を使用してＩｏＴサービスセッション公開鍵署名を検証する。
４．ＩｏＴサービスの公開鍵、並びにＩｏＴサービスのセッション公開鍵を保存する。
５．ＩｏＴデバイスセッション鍵ペアを生成する。
Ｃ．ＩｏＴデバイスは、次に、以下を含むメッセージを生成する：
１．ＩｏＴデバイスの一意的なＩＤ、
・ＩｏＴデバイスのシリアルナンバー、
・タイムスタンプ、
・この一意的なＩＤに署名するために使用される工場鍵のＩＤ、
・一意的なＩＤ（すなわち、ＩｏＴデバイス）のクラス、
・ＩｏＴデバイスの公開鍵、
・一意的なＩＤの署名。
２．ＩｏＴデバイスのセッション公開鍵。
３．ＩｏＴデバイスの鍵で署名された（ＩｏＴデバイスセッション公開鍵＋ＩｏＴサービスセッション公開鍵）の署名。
Ｄ．このメッセージは、ＩｏＴサービスに返送される。ＩｏＴサービスは、メッセージを解析して：
１．工場公開鍵を使用して一意的なＩＤの署名を検証する。
２．ＩｏＴデバイスの公開鍵を使用してセッション公開鍵の署名を検証する。
３．ＩｏＴデバイスのセッション公開鍵を保存する。
Ｅ．ＩｏＴサービスは、次に、ＩｏＴサービスの鍵で署名された（ＩｏＴデバイスセッション公開鍵＋ＩｏＴサービスセッション公開鍵）の署名を含むメッセージを生成する。
Ｆ．ＩｏＴデバイスは、メッセージを解析して：
１．ＩｏＴサービスの公開鍵を使用してセッション公開鍵の署名を検証する。
２．ＩｏＴデバイスセッション秘密鍵及びＩｏＴサービスのセッション公開鍵からキーストリームを生成する。
３．ＩｏＴデバイスは、次に、「メッセージング利用可能」メッセージを送信する。
Ｇ．ＩｏＴサービスは、次に、以下を実行する：
１．ＩｏＴサービスセッション秘密鍵及びＩｏＴデバイスのセッション公開鍵からキーストリームを生成する。
２．以下を含めて、メッセージングチャネル上で新しいメッセージを作成する：
・ランダムな２バイト値を生成して記憶する。
・ブーメラン属性Ｉｄ（以下に説明する）及びランダム値を有する属性メッセージを設定する。
Ｈ．ＩｏＴデバイスは、メッセージを受信して：
１．メッセージを解読することを試みる。
２．示された属性Ｉｄ上と同じ値を有する更新を送信する。
Ｉ．ＩｏＴサービスは、メッセージペイロードがブーメラン属性更新を含むことを認識する：
１．そのペアリング状態を真に設定する。
２．交渉チャネル上でペアリング完了メッセージを送信する。
Ｊ．ＩｏＴデバイスは、メッセージを受信して、ＩｏＴデバイスのペアリング状態を真に設定する。

上述の技術は「ＩｏＴサービス」及び「ＩｏＴデバイス」に関して説明したが、本発明の基本原理は、ユーザのクライアントデバイス、サーバ、及びインターネットサービスを含む、任意の２つのデバイス間で安全な通信チャネルを確立するように実装することができる。

上述の技術は、秘密鍵が無線で共有されない（シークレットが片方の当事者から他方に送信される現在のＢｌｕｅｔｏｏｔｈペアリング技術と対照的に）ので、高度に安全である。会話全体を聞いている攻撃者は、公開鍵を有するのみということになり、これは、共有シークレットを生成するために不十分である。これらの技術はまた、署名された公開鍵を交換することによる中間者攻撃を防止する。加えて、ＧＣＭ及び別個のカウンタがそれぞれのデバイス上で使用されるため、任意の種類の「リプレイアタック」（中間者がデータをキャプチャしてそれを再度送信する）が防止される。いくつかの実施形態はまた、非対称カウンタを使用することによりリプレイアタックを防止する。
デバイスを正式にペアリングすることなくデータ及びコマンドを交換するための技術

ＧＡＴＴは、一般属性プロファイル（Generic Attribute Profile）に対する頭字語であり、これは、２つのＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）デバイスがデータを往復して伝送する方法を規定する。これは、属性プロトコル（Attribute Protocol）（ＡＴＴ）と呼ばれる一般データプロトコルを利用し、このプロトコルは、簡単なルックアップテーブルに、テーブルへの入力ごとに１６ビットの特性ＩＤを使用してサービス、特性、及び関連データを記憶するために使用される。一方で「特性」は、「属性」と呼ばれることもあることに留意されたい。

Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイス上で、最も一般的に使用される特性は、デバイスの「名前」（特性ＩＤ １０７５２ （０ｘ２Ａ００）を有する）である。例えば、Ｂｌｕｅｔｏｏｔｈデバイスは、その近傍内の他のＢｌｕｅｔｏｏｔｈデバイスを、ＧＡＴＴを使用してこれらの他のＢｌｕｅｔｏｏｔｈデバイスによって発行された「名前」特性を読み取ることにより、識別することができる。したがって、ブルートゥースデバイスは、デバイスを正式にペアリング／結合することなくデータを交換するための固有の能力を有する（「ペアリング」と「結合」とが時として交換可能に使用される点に留意されたい。この議論の残りは、用語「ペアリング」を使用することになる）。

本発明の一実施形態は、ＢＴＬＥ対応ＩｏＴデバイスと、これらのデバイスと正式にペアリングすることなく通信するために、この能力を利用する。それぞれの個別のＩｏＴデバイスとのペアリングは、ペアリングするために必要とされる時間のため、及び同時に１つのペアリングされた接続のみを確立することができるため、著しく非効率であろう。

図１９は、Ｂｌｕｅｔｏｏｔｈ（ＢＴ）デバイス１９１０が、ペアリングされたＢＴ接続を正式に確立することなくＩｏＴデバイス１０１のＢＴ通信モジュール１９０１とのネットワークソケットアブストラクションを確立する、特定の一実施形態を例示する。ＢＴデバイス１９１０は、図１６Ａに示すようなＩｏＴハブ１１０及び／又はクライアントデバイス６１１内に含めることができる。例示したように、ＢＴ通信モジュール１９０１は、特性ＩＤ、それらの特性ＩＤに関連付けられた名前、及びそれらの特性ＩＤに対する値のリストを含むデータ構造を維持する。それぞれの特性に対する値は、現在のＢＴ標準に従って特性ＩＤにより識別された２０バイトのバッファに記憶することができる。しかしながら、本発明の基本原理は、いかなる特定のバッファサイズにも限定されない。

図１９の実施例では、「名前」特性は、「ＩｏＴデバイス１４」の特定の値を割り当てられたＢＴで規定された特性である。本発明の一実施形態は、ＢＴデバイス１９１０との安全な通信チャネルを交渉するために使用される追加の特性の第１のセット、及びＢＴデバイス１９１０との暗号化通信のために使用される追加の特性の第２のセットを指定する。具体的には、例示した実施例で特性ＩＤ＜６５５３２＞により識別された「交渉書込」特性は、発信交渉メッセージを送信するために使用することができ、特性ＩＤ＜６５５３３＞により識別された「交渉読取」特性は、受信交渉メッセージを受信するために使用することができる。「交渉メッセージ」は、本明細書に記載されたような安全な通信チャネルを確立するためにＢＴデバイス１９１０及びＢＴ通信モジュール１９０１によって使用されるメッセージを含むことができる。例として、図１７で、ＩｏＴデバイス１０１は、「交渉読取」特性＜６５５３３＞を介してＩｏＴサービスセッション公開鍵１７０１を受信することができる。鍵１７０１は、ＩｏＴサービス１２０からＢＴＬＥ対応ＩｏＴハブ１１０又はクライアントデバイス６１１に送信することができ、それらは、次に、ＧＡＴＴを使用して、特性ＩＤ＜６５５３３＞により識別された交渉読取値バッファに鍵１７０１を書込むことができる。ＩｏＴデバイスのアプリケーションロジック１９０２は、次に、特性ＩＤ＜６５５３３＞により識別された値バッファから鍵１７０１を読み取って、上述したようにそれを処理することができる（例えば、それを使用してシークレットを生成し、シークレットを使用してキーストリームを生成するなど）。

鍵１７０１が２０バイト（一部の現在の実装形態での最大バッファサイズ）より大きい場合は、鍵は２０バイトの部分に書き込むことができる。例えば、最初の２０バイトは、ＢＴ通信モジュール１９０３によって特性ＩＤ＜６５５３３＞に書き込んで、ＩｏＴデバイスアプリケーションロジック１９０２によって読み取ることができ、ＩｏＴデバイスアプリケーションロジック１９０２は、次に、確認応答メッセージを特性ＩＤ＜６５５３２＞により識別された交渉書込値バッファに書込むことができる。ＧＡＴＴを使用して、ＢＴ通信モジュール１９０３は、この確認応答を特性ＩＤ＜６５５３２＞から読み取ることができ、それに応じて、鍵１７０１の次の２０バイトを特性ＩＤ＜６５５３３＞により識別された交渉読取値バッファに書込むことができる。この方法で、特性ＩＤ＜６５５３２＞及び＜６５５３３＞により規定されたネットワークソケットアブストラクションは、安全な通信チャネルを確立するために使用される交渉メッセージを交換するために確立される。

一実施形態では、安全な通信チャネルが確立されると、特性ＩＤ＜６５５３４＞（ＩｏＴデバイス１０１から暗号化データパケットを送信するための）及び特性ＩＤ＜６５５３３＞（ＩｏＴデバイスにより暗号化データパケットを受信するための）を使用して、第２のネットワークソケットアブストラクションが確立される。すなわち、ＢＴ通信モジュール１９０３が送信する暗号化データパケット（例えば、図１６Ａの暗号化メッセージ１６０３などの）を有するとき、ＢＴ通信モジュール１９０３は、特性ＩＤ＜６５５３３＞により識別されたメッセージ読取値バッファを使用して一度に２０バイト、暗号化データパケットを書込み始める。ＩｏＴデバイスアプリケーションロジック１９０２は、次に、読取値バッファから一度に２０バイト、暗号化データパケットを読み取り、必要に応じて特性ＩＤ＜６５５３２＞により識別された書込値バッファを介して確認応答メッセージをＢＴ通信モジュール１９０３に送信することになる。

一実施形態では、後述するＧＥＴ、ＳＥＴ、及びＵＰＤＡＴＥのコマンドを使用して、２つのＢＴ通信モジュール１９０１と１９０３との間でデータ及びコマンドを交換する。例えば、ＢＴ通信モジュール１９０３は、特性ＩＤ＜６５５３３＞を識別しＳＥＴコマンドを含むパケットを送信して、特性ＩＤ＜６５５３３＞により識別された値フィールド／バッファに書込むことができ、それは次に、ＩｏＴデバイスアプリケーションロジック１９０２によって読み取ることができる。ＩｏＴデバイス１０１からデータを取得するために、ＢＴ通信モジュール１９０３は、特性ＩＤ＜６５５３４＞により識別された値フィールド／バッファに向けられたＧＥＴコマンドを送信することができる。ＧＥＴコマンドに応答して、ＢＴ通信モジュール１９０１は、特性ＩＤ＜６５５３４＞により識別された値フィールド／バッファからのデータを含むＵＰＤＡＴＥパケットをＢＴ通信モジュール１９０３に送信することができる。加えて、ＵＰＤＡＴＥパケットは、ＩｏＴデバイス１０１上の特定の属性の変化に応答して、自動的に送信することができる。例えば、ＩｏＴデバイスが照明システムに関連付けられていて、ユーザが照明をオンにする場合、ＵＰＤＡＴＥパケットを送信して、照明アプリケーションに関連付けられたオン／オフ属性にこの変化を反映することができる。

図２０は、本発明の一実施形態による、ＧＥＴ、ＳＥＴ、及びＵＰＤＡＴＥ用に使用される例示的なパケット形式を例示する。一実施形態では、これらのパケットは、交渉の後に、メッセージ書込＜６５５３４＞及びメッセージ読取＜６５５３３＞チャネルを介して送信される。ＧＥＴパケット２００１では、最初の１バイトのフィールドは、パケットをＧＥＴパケットとして識別する値（０Ｘ１０）を含む。２番目の１バイトのフィールドは、現在のＧＥＴコマンドを一意的に識別する（すなわち、ＧＥＴコマンドが関連付けられた現在のトランザクションを識別する）要求ＩＤを含む。例えば、サービス又はデバイスから送信されたＧＥＴコマンドのそれぞれのインスタンスに、異なる要求ＩＤを割り当てることができる。これは、例えば、カウンタを増加させて、カウンタ値を要求ＩＤとして使用することにより、実行することができる。しかしながら、本発明の基本原理は、要求ＩＤを設定するためのいかなる特定の方法にも限定されるものではない。

２バイトの属性ＩＤは、パケットが向けられたアプリケーション特有の属性を識別する。例えば、ＧＥＴコマンドが図１９に例示したＩｏＴデバイス１０１に送信されている場合、属性ＩＤを使用して、要求されている特定のアプリケーション特有の値を識別することができる。上述の実施例に戻って、ＧＥＴコマンドは、照明システムの電源状態などのアプリケーション特有の属性ＩＤに向けることができ、この属性ＩＤは、照明が電源がオン又はオフになっているかを識別する値（例えば、１＝オン、０＝オフ）を含む。ＩｏＴデバイス１０１がドアに関連付けられたセキュリティ装置である場合、値フィールドは、ドアの現在の状態（例えば、１＝開いている、０＝閉じている）を識別することができる。ＧＥＴコマンドに応答して、属性ＩＤにより識別された現在の値を含む応答を送信することができる。

図２０に例示したＳＥＴパケット２００２及びＵＰＤＡＴＥパケット２００３もまた、パケットのタイプ（すなわち、ＳＥＴ及びＵＰＤＡＴＥ）を識別する最初の１バイトのフィールド、要求ＩＤを含む２番目の１バイトのフィールド、及びアプリケーションで定義された属性を識別する２バイトの属性ＩＤフィールドを含む。加えて、ＳＥＴパケットは、ｎバイトの値データフィールドに含まれたデータの長さを識別する２バイト長の値を含む。値データフィールドは、ＩｏＴデバイス上で実行されるコマンド、及び／又はなんらかの方法でＩｏＴデバイスの動作を構成する（例えば、所望のパラメータを設定する、ＩｏＴデバイスの電源を切るなど）コンフィギュレーションデータを含むことができる。例えば、ＩｏＴデバイス１０１がファンの速度を制御する場合、値フィールドは、現在のファンの速度を反映することができる。

ＵＰＤＡＴＥパケット２００３は、ＳＥＴコマンドの結果の更新を提供するために送信することができる。ＵＰＤＡＴＥパケット２００３は、ＳＥＴコマンドの結果に関連したデータを含むことができるｎバイトの値データフィールドの長さを識別する、２バイト長の値フィールドを含む。加えて、１バイトの更新状態フィールドは、更新されている変数の現在の状態を識別することができる。例えば、ＳＥＴコマンドがＩｏＴデバイスにより制御された照明をオフにすることを試みた場合、更新状態フィールドは、照明が正常にオフにされたか否かを示すことができる。

図２１は、ＳＥＴ及びＵＰＤＡＴＥコマンドを伴うＩｏＴサービス１２０とＩｏＴデバイス１０１との間の例示的なトランザクションのシーケンスを例示する。ＩｏＴハブ及びユーザのモバイルデバイスなどの中間デバイスは、本発明の基本原理を不明瞭にすることを避けるために示されていない。２１０１で、ＳＥＴコマンド２１０１は、ＩｏＴサービスからＩｏＴデバイス１０１に送信されて、ＢＴ通信モジュール１９０１により受信され、ＢＴ通信モジュール１９０１は、それに応じて、２１０２で特性ＩＤにより識別されたＧＡＴＴ値バッファを更新する。ＳＥＴコマンドは、２１０３で低電力マイクロコントローラ（microcontroller）（ＭＣＵ）２００により（又は図１９に示すＩｏＴデバイスアプリケーションロジック１９０２などの低電力ＭＣＵ上で実行されているプログラムコードにより）値バッファから読み取られる。２１０４で、ＭＣＵ２００又はプログラムコードは、ＳＥＴコマンドに応答して動作を実行する。例えば、ＳＥＴコマンドは、新しい温度などの新しいコンフィギュレーションパラメータを指定する属性ＩＤを含むことができる、又はオン／オフなどの状態値（ＩｏＴデバイスを「オン」又は低電力状態に入らせるための）を含むことができる。したがって、２１０４で、新しい値がＩｏＴデバイスに設定され、２１０５でＵＰＤＡＴＥコマンドが返され、２１０６でＧＡＴＴ値フィールドの実際の値が更新される。場合により、実際の値は、所望の値に等しいであろう。他の場合では、更新された値は、異なることがある（すなわち、ＩｏＴデバイス１０１がある特定のタイプの値を更新するのに時間がかかることがあるため）。最終的に、２１０７で、ＧＡＴＴ値フィールドからの実際の値を含むＵＰＤＡＴＥコマンドがＩｏＴサービス１２０に返送される。

図２２は、本発明の一実施形態によるＩｏＴサービスとＩｏＴデバイスとの間で安全な通信チャネルを実装するための方法を例示する。本方法は、上述のネットワークアーキテクチャとの関連で実装され得るが、いかなる特定のアーキテクチャにも限定されない。

２２０１で、ＩｏＴサービスは、楕円曲線デジタル署名アルゴリズム（elliptic curve digital signature algorithm）（ＥＣＤＳＡ）証明書を使用してＩｏＴハブと通信するための暗号化チャネルを作成する。２２０２で、ＩｏＴサービスは、セッションシークレットを使用してＩｏＴデバイスパケット内のデータ／コマンドを暗号化して、暗号化デバイスパケットを作成する。上述したように、セッションシークレットは、ＩｏＴデバイス及びＩｏＴサービスによって独自に生成することができる。２２０３で、ＩｏＴサービスは、暗号化チャネルを介して暗号化デバイスパケットをＩｏＴハブに送信する。２２０４で、解読することなく、ＩｏＴハブは、暗号化デバイスパケットをＩｏＴデバイスに渡す。２２－５で、ＩｏＴデバイスは、セッションシークレットを使用して、暗号化デバイスパケットを解読する。上述したように、一実施形態では、これは、シークレット及びカウンタ値（暗号化デバイスパケットと共に提供される）を使用してキーストリームを生成し、次にキーストリームを使用してパケットを解読することにより実現することができる。２２０６で、ＩｏＴデバイスは、次に、デバイスパケットに含まれたデータ及び／又はコマンドを抽出して処理する。

したがって、上述の技術を使用して、標準的なペアリング技術を使用して、ＢＴデバイスを正式にペアリングすることなく、２つのＢＴ対応デバイス間で双方向の安全なネットワークソケットアブストラクションを確立することができる。これらの技術は、ＩｏＴサービス１２０と通信するＩｏＴデバイス１０１に関して上述したが、本発明の基本原理は、任意の２つのＢＴ対応デバイス間で安全な通信チャネルを交渉して確立するように実装することができる。

図２３Ａ～図２３Ｃは、本発明の一実施形態によるデバイスをペアリングするための詳細な方法を例示する。本方法は、上述のシステムアーキテクチャとの関連で実装され得るが、いかなる特定のシステムアーキテクチャにも限定されない。

２３０１で、ＩｏＴサービスは、ＩｏＴサービスのシリアルナンバー及び公開鍵を含むパケットを作成する。２３０２で、ＩｏＴサービスは、工場秘密鍵を使用してパケットに署名する。２３０３で、ＩｏＴサービスは、暗号化チャネルを介してＩｏＴハブにパケットを送信し、２３０４で、ＩｏＴハブは、非暗号化チャネルを介してＩｏＴデバイスにパケットを転送する。２３０５で、ＩｏＴデバイスは、パケットの署名を検証し、２３０６で、ＩｏＴデバイスは、ＩｏＴデバイスのシリアルナンバー及び公開鍵を含むパケットを生成する。２３０７で、ＩｏＴデバイスは、工場秘密鍵を使用してパケットに署名し、２３０８で、ＩｏＴデバイスは、非暗号化チャネルを介してＩｏＴハブにパケットを送信する。

２３０９で、ＩｏＴハブは、暗号化チャネルを介してパケットをＩｏＴサービスに転送し、２３１０で、ＩｏＴサービスは、パケットの署名を検証する。２３１１で、ＩｏＴサービスは、セッション鍵ペアを生成し、２３１２で、ＩｏＴサービスは、セッション公開鍵を含むパケットを生成する。ＩｏＴサービスは、次に、２３１３で、ＩｏＴサービス秘密鍵でパケットに署名し、２３１４で、ＩｏＴサービスは、暗号化チャネルを介してパケットをＩｏＴハブに送信する。

図２３Ｂに移って、２３１５で、ＩｏＴハブは、非暗号化チャネルを介してパケットをＩｏＴデバイスに転送し、２３１６で、ＩｏＴデバイスは、パケットの署名を検証する。２３１７で、ＩｏＴデバイスは、セッション鍵ペアを生成し（例えば、上述の技術を使用して）、２３１８で、ＩｏＴデバイスセッション公開鍵を含むＩｏＴデバイスパケットが生成される。２３１９で、ＩｏＴデバイスは、ＩｏＴデバイス秘密鍵でＩｏＴデバイスパケットに署名する。２３２０で、ＩｏＴデバイスは、非暗号化チャネルを介してＩｏＴハブにパケットを送信し、２３２１で、ＩｏＴハブは、暗号化チャネルを介してＩｏＴサービスにパケットを転送する。

２３２２で、ＩｏＴサービスは、パケットの署名を検証し（例えば、ＩｏＴデバイス公開鍵を使用して）、２３２３で、ＩｏＴサービスは、ＩｏＴサービス秘密鍵及びＩｏＴデバイス公開鍵を使用して、セッションシークレットを生成する（先に詳細に説明したように）。２３２４で、ＩｏＴデバイスは、ＩｏＴデバイス秘密鍵及びＩｏＴサービス公開鍵を使用して、セッションシークレットを生成し（また、上述したように）、２３２５で、ＩｏＴデバイスは、乱数を生成して、セッションシークレットを使用してその乱数を暗号化する。２３２６で、ＩｏＴサービスは、暗号化チャネルを介して暗号化パケットをＩｏＴハブに送信する。２３２７で、ＩｏＴハブは、非暗号化チャネルを介して暗号化パケットをＩｏＴデバイスに転送する。２３２８で、ＩｏＴデバイスは、セッションシークレットを使用してパケットを解読する。

図２３Ｃに移って、２３２９で、ＩｏＴデバイスは、セッションシークレットを使用してパケットを再暗号化し、２３３０で、ＩｏＴデバイスは、非暗号化チャネルを介して暗号化パケットをＩｏＴハブに送信する。２３３１で、ＩｏＴハブは、暗号化チャネルを介して暗号化パケットをＩｏＴサービスに転送する。２３３２で、ＩｏＴサービスは、セッションシークレットを使用してパケットを解読する。２３３３で、ＩｏＴサービスは、乱数がＩｏＴサービスが送信した乱数と一致することを検証する。ＩｏＴサービスは、次に、２３３４で、ペアリングが完了したことを示すパケットを送信し、２３３５で、その後のメッセージはすべて、セッションシークレットを使用して暗号化される。
一体成形部品ためのシステム及び方法
モノのインターネット（ＩｏＴ）セキュリティセンサ

本発明の一実施形態は、一体成形のモノのインターネット（ＩｏＴ）セキュリティセンサを備え、このセンサは、既存の無線ドア／窓センサの制約（例えば、位置調整、かさ高性、誤作動等）に対処する。図２４は、ユーザの家庭又は事業所内の様々なドア及び／又は窓に結合されている、３つのかかるＩｏＴデバイス２４０１～２４０３を有するシステムアーキテクチャを示す。様々なシステム構成要素同士の間の相互作用は、上記のように生じてもよい。例えば、示しているアーキテクチャは、ＩｏＴハブ２４０５を含み、このＩｏＴハブは、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）チャネル等の低出力無線通信チャネルを介してＩｏＴデバイス２４０１～２４０３と通信し、一実施形態では、ＩｏＴクラウドサービス２４２０との通信チャネルを確立する。

示すように、ＩｏＴクラウドサービス２４２０は、ＩｏＴデバイスデータベース２４３０を含んでもよく、このデータベースは、システムに構成された（図２４に示されない複数のＩｏＴハブ及びデバイスを含んでもよい）ＩｏＴデバイス２４０１～２４０３及びＩｏＴハブ２４０５のそれぞれのためのデータベース記録を含む。ＩｏＴデバイス管理ロジック２４１５は、新たなＩｏＴデバイスためのデータベース記録を作成し、ＩｏＴデバイス２４０１～２４０３のそれぞれによって送信されたデータに応じてＩｏＴデバイス記録を更新する。ＩｏＴデバイス管理ロジック２４１５は、また、上記の様々なセキュリティ／暗号化機能を実装することにより、（例えば、ＱＲコード／バーコードを使用して）システムに新たなデバイスを付加し、ＩｏＴデバイス２４０１～２４０３と通信するときに通信を暗号化するためのキーを使用するか、及び／又はデジタル署名を生成してもよい。一実施形態では、ユーザは、デバイス２４０１～２４０３のそれぞれに関連した情報にアクセスしてもよく、及び／又はＡｎｄｒｏｉｄ（登録商標）デバイス又はｉＰｈｏｎｅ（登録商標）等のスマートフォンデバイスであってもよいユーザデバイス２４１０にインストールされたアプリを介してデバイスを制御してもよい。それに加えて、ユーザは、デスクトップ又はラップトップコンピュータにインストールされたブラウザ又はアプリケーションを介してＩｏＴデバイスにアクセス又は制御してもよい。一実施形態では、ユーザデバイス２４１０のアプリ又はアプリケーションから送信された制御信号は、インターネット２４２２を介してＩｏＴクラウドサービス２４２０に渡され、次いで、ＩｏＴクラウドサービス２４２０からＩｏＴハブ２４０５まで、及び、ＩｏＴハブ２４０５からＩｏＴデバイス２４０１～２４０３のうちの１つ又は複数のものまで転送される。勿論、本発明の基礎原理は、ユーザが様々なＩｏＴデバイス２４０１～２４０３にアクセス／制御するといういかなる特定の態様にも限定されない。

上記のように、一実施形態では、ＩｏＴデバイス２４０１～２４０３は、ドア及び／又は窓に構成された一体成形のセキュリティデバイスを備える。図２５は、例示的なＩｏＴデバイス２４０１を示し、このデバイスは、（例えば、上記のようなＢＴＬＥ等の低出力無線リンクを使用して）セキュリティ状態をＩｏＴハブ２４０５に報告するためのラジオマイクロコントローラ２５１０、動作を検出するための加速計２５０２、及び、近くのオブジェクトから反射される電磁放射を生成及び感知するための近接センサ及びロジック２５０５を含む。一実施形態では、電磁放射は、赤外線（ＩＲ）放射である（すなわち、ＩＲスペクトル内にある）。しかし、様々な別の形式の電磁放射が、本発明の基礎原理に従いながら使用されてもよい。

別の実施形態では、近接センサ２５０５は、現在のドア位置を検出するための磁力計を備える。例えば、磁力計は、地磁界の方向に対するドアの向きを検出するように構成されてもよい。磁力計は、ドアが閉じている位置及び開いている位置にあるときに、測定値をとることによって較正されてもよい。最新の磁力計測定値が、次いで、較正された測定値と比較されて、ドアが現在開いているか又は閉じているかを決定してもよい。

図２５に示す例では、ＩｏＴデバイス２４０１は、側柱２５２１に面するドア２５２０の内側部分に付着されている。一実施形態では、例えば、それはドアと側柱（ドアが確保されるフレームの鉛直部分）との間に嵌合するのに十分なほど小さくてもよい。しかし、この特定の配置は、本発明の基礎原理に従うのに必要ではないことが留意されるべきである。更に、本発明の基礎原理は、また、ユーザの家庭又はオフィスの窓又は任意の別の可動オブジェクトに実装されてもよい。

作動中、ドア２５２０が静止しているとき、ラジオｕＣ２５１０は、バッテリ寿命を保つために非常に低い電圧又はオフ状態に維持される。一実施形態では、ドアが動かされると、加速計２５０２が割り込んでラジオｕＣ２５１０を起動させ、このことが、次に近接センサ／ロジック２５０５を使用して側柱２５２１がそれの前で静止しているか否かを「見る」。ドアが静止していない場合、近接センサは、ラジオｕＣがＩｏＴハブ２４０５に送信する警告信号を生成してもよい。

一実施形態では、近接センサ／ロジック２５０５は、ＩＲ放射を伝送するためのＩＲ送信機と、側柱２５２１から反射するＩＲ放射を検出するためのＩＲ検出器と、を備える。一実施形態では、近接センサ／ロジック２５０５は、反射されたＩＲ放射の強度を測定する。近接センサ／ロジック２５０５は、次いで、ドアが閉じているときに存在することが知られた（例えば、下記で論じるように較正を介して収集されてもよい）示度と最新のＩＲ示度を比較してもよい。示度が一致する（又は、指定閾値内にある）場合、近接センサ／ロジック２５０５は、ドアが閉じている位置にあると決定する。しかし、示度が一致しない（例えば、閾値外である）場合、近接センサ／ロジック２５０５は、ドアが開いていると決定し、ラジオｕＣ２５１０を介してアラーム状態を生成してもよい。

一実施形態では、近接センサ／ロジック２５０５は、ドア２５２０の「閉じている」位置にＩＲ示度を較正するための較正ロジックを含む。一実施形態では、ＩｏＴデバイス２４０１がドアに装着された後に、ユーザは、ドアが閉じている位置にあるときにユーザに確認することを要求するユーザデバイス２４１０のアプリを介して較正処理を実行する。いったんユーザが指示を与えると、示度を記録することになる近接センサ２５０５に通知するためにコマンドが送信されてもよい。これらの示度は、次いで、上記のような最新の示度と比較されることにより、ドアが、現時点で開いているか又は閉じているかを決定してもよい。

図２６は、ＩｏＴデバイス２４０１が、ドア２５２０の内面と側柱２５２１との間のドア２５２０の下側部分に設置されている一実施形態を示す。この実施形態のＩｏＴデバイス２４０１は、近接センサ／ロジック２５０５だけがドア２５２０と側柱２５２１との間に設置され、同時に、ＩｏＴデバイス２４０１の残りの構成要素（例えば、ラジオｕＣ及び加速計２５０２）がドアの面に設置されているという直角のフォームファクタを使用してもよい。この実施形態は、ドア２５２０と側柱２５２１との間に収まる部分が可能な限り薄い（例えば、場合によってはわずかに数ミリメートルである）ことを可能にし、同時に、（より嵩張る傾向があり得る）無線ラジオｕＣ等の他の構成要素がドアの動きを妨げないことを可能にしてもよい。勿論、本発明の基礎原理は、構成要素のすべてがドア２５２０と側柱２５２１との間の単一パッケージに嵌合するのに十分なほど小さいようなＩｏＴデバイス２４０１を含んでもよい。

更に、ＩｏＴデバイス２４０１が、側柱２５２１から最も遠く離れたドアの縁部等の別の位置に置かれてもよいことが理解されるであろう。この実施形態では、近接センサ／ロジック２５０５は、ドアの縁部とドア枠の直ぐ隣の部分との間のＩＲ測定値をとってもよい。同様に、ＩｏＴデバイス２４０１は、また、窓の縁部に又はその近傍に置かれてもよい。この実施形態では、近接センサ／ロジック２５０５は、窓枠又は窓敷居等の近くの構造オブジェクトから跳ね返されたＩＲ測定値をとることになる。繰り返しになるが、較正処理が、閉じている及び／又は開いている位置での測定値をとるために実装されてもよく、それに続く示度がこれらの測定値と比較されて、窓が開いているか又は閉じているかを決定してもよい。

様々な異なるタイプのセンサがＩｏＴデバイス２４０１の内部で使用されるか又はそれに結合されることにより、ユーザの家庭又は事業所内のドア、窓、又は別の装置の位置を感知してもよい。いくつかの例示的な実施形態が以下で説明される。

図２７Ａ～図２７Ｂに示すように、本発明の別の実施形態は、ドア２７１０の内側に結合された感圧抵抗器（force sensing resistor）（ＦＳＲ）２７０２を含む。この示している実施形態では、ＦＳＲ２７０２は、表すようにそれ自体がドアに直接装着されているゴムバンパ構成要素２７０１に装着される。ＦＳＲ２７０２は、ＦＳＲリード線２７０４のセット（例えば、ＦＳＲ２７０２に作用している最新の力を通信するワイヤのセット）を介してＩｏＴデバイス２７０３に通信可能に取り付けられる。図２７に示す実施形態のように、この実施形態では、ＩｏＴデバイス２７０３は、表すように、ＦＳＲセンサだけがドア２７１０と側柱との間に設置され、同時に、ＩｏＴデバイス２７０３の残りの構成要素（例えば、ラジオｕＣ及び加速計２５０２）は、ドアの面に設置されるという直角のフォームファクタを有してもよい。ＩｏＴデバイス２７０３は、（上記の実施形態の場合のように）ラジオモジュールと、電源用の小型バッテリと、を含んでもよい。

別の実施形態において、ＦＳＲ２７０２は、ドアの内側縁部よりもむしろドア２７１０の外側縁部に装着されてもよく、また、ドア枠（例えば、側柱２５２１）に結合されてもよい。本発明の基礎原理は、ＩｏＴデバイス２７０３及びＦＳＲ２７０２のためのなんらかの特定の取付け位置に限定されない。更に、同一の基本原理が、ユーザの家庭又は事業所の窓又は別のデバイスにＦＳＲ２７０２を使用するために適用されてもよい。

図２７Ａ～図２７Ｂに示す例において、感圧抵抗器（ＦＳＲ）２７０２は、ドアの内側がドア枠の極近くに入るときを検出することができる。短い距離を越えて、ＦＳＲ２７０２は、ドアによってＦＳＲを通してドア枠に適用されている力の連続測定値を提供する。上記のように、ＦＳＲ２７０２の一実施形態が、力をドアからＦＳＲを通して枠まで伝達する小型ゴムバンパ２７０１に装着される。バンパ２７０１のサイズ及び稠度（consistency）は、様々なドア間隙に適応するように変えられてもよい。（例えば、ドアが閉じている結果として）ＦＳＲに作用する力に応じて、ＦＳＲ２７０２は、ＩｏＴデバイス２７０３によって受信されて処理される、及び／又は自らを通してＩｏＴハブ２４０５及びＩｏＴサービス２４２０に送信される電気信号を生成する。例えば、異なる抵抗が、異なるレベルの作用力に対してＦＳＲ２７０２にわたって測定されてもよい（すなわち、一貫した電圧を仮定したときに異なる電流量をもたらす）。指定閾値力に達したとき、ＩｏＴデバイス２７０３（又は、ＩｏＴハブ２４０５又はサービス２４２０）は、このことがドアが「閉じている」位置にあることを意味すると解釈してもよい。閾値未満の力が検出されるとき、ＩｏＴデバイス２７０３、ＩｏＴハブ２４０５、又はＩｏＴサービス２４２０は、このことがドアが部分的にだけ開いている（例えば、わずかに半開きで、それによって部分的にだけＦＳＲを押し下げている）ことを意味すると解釈してもよい。力が検出されないとき、ＩｏＴデバイス２７０３、ＩｏＴハブ２４１０、及び／又はサービス２４２０は、ドアが開いていると断定してもよい。したがって、ＦＳＲ２７０２等、小さいダイナミックレンジにわたって連続的な力の計測値を提供するセンサを使用することは、（単にオン又はオフである既存のセキュリティセンサと対照的に）ドア位置のより正確な判定を提供する。先の実施形態のように、ＦＳＲ２７０２／ＩｏＴデバイス２７０３は、（二部式である磁気ドアセンサの現在の形式の反対であるように）ドア又はドア枠に完全に付着されてもよい一体式のデバイスとして実装されてもよい。

一実施形態では、ユーザは、最初にインストールされるときに、ＦＳＲ２７０２／ＩｏＴデバイス２７０３を較正してもよい。例えば、ユーザデバイス２４１０のアプリによって、ユーザは、ドアが全閉である、全開である、及び半開であるときについての表示を提供することを要求されてもよい。センサ示度がそれぞれの位置でとられて、ＩｏＴデバイス２７０３、ＩｏＴハブ２４１０、及び／又はサービス２４２０によって記録されてもよい。これらの示度は、次いで最新の示度と比較されて、ドアの最新の状態を決定してもよい。例えば、最新の示度が、閉じているドアに対する記録された示度の指定範囲内にある場合、ＩｏＴデバイス２７０３、ＩｏＴハブ２４１０、及び／又はサービス２４２０は、ドアが現時点で閉じていると決定してもよい。同様の比較が、開いた及び半開の状態に対してなされてもよい。

接着剤、圧力嵌め、ゴム製品、又は取り付けられたブラケットを含む様々な取付け技術が、フォームファクタ及び設計目標によって使用されてもよい。図２７Ａ～図２７Ｂに示す実施形態において、例えば、接着剤が、ゴムバンパの裏材に適用されて、ＦＳＲ２７０２及びＩｏＴデバイス２７０３をドアに付着させてもよい。使用されてもよいＦＳＲの一例は、Ｄｉｇｉ－Ｋｅｙ Ｅｌｅｃｔｒｏｎｉｃｓから利用可能なＦＳＲ ４０２ Ｒｏｕｎｄ Ｆｏｒｃｅ Ｓｅｎｓｉｎｇ Ｒｅｓｉｓｔｏｒである。

別の実施形態は、図２７Ａ～図２７Ｂに示す特徴のすべてを含むだけでなく、パッケージに付加された圧電振動センサを含む。例えば、一実施形態では、圧電振動センサは、ゴムバンパ２７０１の下に設置されてもよく、又はその内部に一体化されてもよい。ＦＳＲと同様に、電気リード線が、ＩｏＴデバイス２７０３に圧電振動センサを通信可能に結合する。一実施形態では、圧電振動センサは、パッシブ型であって、力、曲げ、又は振動が作用すると、外部デバイスに電力供給を要求することなく高電圧を生成する。したがって、振動センサは、振動又は動きに応じて、ラジオマイクロコントローラ２５１０及びＩｏＴデバイス２７０３内の別の構成要素を起動させるように構成されてもよく、それによって、これらの構成要素が、振動又は動きがない場合に、非常に低い電力状態に入ることを可能にする。振動センサは、例えば、ドアをノック／打撃することによって始動されてもよく、圧力／触覚センサとして作動してもよく、又は、単なる加速計（図２５の加速計２５０２等）として構成されてもよい。

一実施形態では、図２７Ａ～図２７ＢのＦＳＲ２７０２は、板ばねに結合された歪みゲージによって置換される。ドアが閉まり、ばねと接触すると、歪みゲージ抵抗は、ばね面の歪みに応じて変化する。抵抗変化は、順に、ばね角度、そのためドア角度に相関するばね曲りに対応する。この実施形態の結果は、ドア角度についてのずっと大きい動作範囲が利用可能であることを除いて、上記のＦＳＲ実施形態と同様である。しかし、歪みゲージ回路は動作範囲を増大させるための増幅を必要とし、その結果、この設計は、ＦＳＲ実施形態よりも大きい電力を消費する傾向がある場合がある。

別の実施形態では、図２７Ａ～図２７ＢのＦＳＲ２７０２センサ要素が、圧電フィルムと圧電抵抗フィルムとの組合せによって置換される。この実施形態の圧電フィルムは、圧電振動センサに対して上記のように作動して、力、曲げ、又は振動が作用すると、外部デバイスに電力供給を要求することなく、高電圧を生成する。しかし、圧電抵抗フィルムは、ピエゾ抵抗効果を利用し、力及び曲げに基づく可変抵抗を有する。一実施形態では、これらの２つのフィルムは、上記の板ばね／歪みゲージの組合せと同様の態様で使用されてもよい。しかし、別の実施形態では、圧電／圧電抵抗フィルムの組合せは、ドア機構のラッチ／ボルトスロット内部に取り付けられてもよく、導体のセットを介してＩｏＴデバイス２７０３に通信可能に結合されてもよい。ラッチがロック固定されてセンサを変形させるか、又はアンラッチされてセンサを自由にしているか否かによって、ドアのロック固定状態が生成された電気信号から決定されてもよい。一実施形態では、取付けは、枠又はドアのいずれかで実行される。この実施形態では、フィルムは、ドアラッチ近くの面に接着／固着され、ラッチ経路の中に突き出ることにより、ラッチ動作がフィルムと接触する。先の実施形態のように、この実施形態は、設置後に較正されることにより、ドアの開閉状態は、圧電抵抗フィルムの対応する抵抗と相関させられてもよい。

更に別の実施形態は、図２７Ａ～図２７Ｂの実施形態と同一又は同様の構成要素を保有するけれども、ドア内部に取り付けられる。改装中又は組立て中のいずれかで、小さい空洞が、センサが表面の平面を越えて延在するＦＳＲバンパだけによって中に設置されるドア又は枠の内部（ヒンジ取付け台）に作成される場合がある。このようにＦＳＲセンサを埋め込むことによって、サイズ及びフォームファクタの関与がより小さくなり、そして、より大きい容量のバッテリが使用されることにより、ユニット寿命を１０年まで延長してもよい。更に、この実施形態は、ほとんどプロファイルが見えず、視覚に入り込むことがはるかにより少ない。ユニットのサイズの制限は、バッテリの様式に依存する。

標準的なドア２７１０の文脈で説明されるけれども、上記の実施形態のすべては、また、引戸及び引窓に適用できる。自在戸が、現在の提案される実装例のうちの最も複雑なものである。引窓又は引戸に取り付けられると、これらの実施形態は、純粋に直線の経路を有するにもかかわらず、同一の基礎機能を実行する。

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

２８０１において、ドア／窓は、最初に静止位置にある。２８０２において動きが検出される場合、２８０３において、無線ｕＣがそれ自体の低電力／スリープ状態から起動される。２８０４において、無線ｕＣは、（また問合せの前には低電力状態にあってもよい、及び／又は加速計によって活性化させられていてもよい）近接センサに近接示度をとることについて問い合わせる。それに応じて、近接センサは、２８０５において示度を作成して、ドア／窓が開いている又は閉じている位置のいずれにあるかを決定する。ドア／窓が開いていると２８０６において決定される場合、２８０７において、ＩｏＴハブ、ＩｏＴサービス、及び／又はユーザデバイスに送信され得るアラーム状態を生成してもよい。最終的に、アラーム状態が調べられた後に、アラーム状態は２８０９において無効にされてもよい。一実施形態では、アラーム状態は、ＩｏＴハブ、ＩｏＴサービス、及び／又はユーザのモバイルデバイスから送信される信号に応じて無効にされてもよい。ドア／窓が開いていると２８０６において決定されない場合、２８０８において、無線ｕＣは低電力／スリープ状態に戻されてもよく、そして処理は２８０１まで戻る。

一実施形態では、ユーザは、ユーザの家庭が「保護された」状態にあるとき（例えば、ユーザが日中に家庭から離れるとき、又はユーザが眠っている夜に）、システムは上記のようにアラームを生成するように構成してもよい。別の時間の間に家庭が保護状態にないとき、ＩｏＴデバイス２４０１の様々な構成要素が、低電力／スリープ状態に入ってもよい。ＩｏＴハブ２４０５からの信号は、次いで、ユーザからの（例えば、ユーザデバイスのアプリを介する）手動入力に応じて、及び／又は毎日のスケジュール（例えば、日夜のユーザ指定時間に）に従って、ＩｏＴデバイス２４０１を動作モードに置いてもよい。

様々な技術が、ドア及び窓にＩｏＴデバイス２４０１を付着するために使用されてもよく、これらの技術は、例えば、接着剤（例えば、両面テープ）、ＩｏＴデバイスの筐体の取付け孔を通って嵌合するようにサイズ設定されたミニチュアねじを含む。
モノのインターネット（ＩｏＴ）デバイスを制御するための二次通信チャネルを確立するためのシステム及び方法

上記の本発明の実施形態において、安全なチャネルが、ＩｏＴハブ又はクライアントデバイスによってそれぞれのＩｏＴデバイスとＩｏＴサービスとの間に確立される（例えば、図１６Ａ～図１７及び関連する本文を参照）。いったん確立されると、ＩｏＴサービスは、それぞれのＩｏＴデバイスを制御及び構成するためのコマンドを安全に送信してもよい。逆方向に、それぞれのＩｏＴデバイスは、ＩｏＴサービスにデータを送信して戻してもよく、そこで、データはエンドユーザによって記憶及び／又はアクセスされてもよい。例として、ドア又は窓がユーザの家庭で開いているとき、この状態を検出するように構成されたＩｏＴデバイスが、ドア／窓が開いているという表示を安全な通信チャネルを介してＩｏＴサービスに送信してもよい。同様に、ＩｏＴデバイスがユーザのフロントドアの無線ロック固定具として構成される場合、ユーザは、コマンドをＩｏＴサービスからＩｏＴデバイスまで安全な通信チャネルを介して送信させて、フロントドアをロック解除してもよい。

上記の構成は、ＩｏＴデバイスとＩｏＴサービスとの間に実行可能な接続が存在することを仮定している。しかし、いくつかの例では、ＩｏＴサービスへの接続は、実行不可能であってもよい。例えば、ＩｏＴサービスがダウンしていてもよく、又は（例えば、セルラーデータネットワーク又は専用家庭インターネット接続を介する）ＩｏＴサービスへのインターネット接続が動作不能であってもよい。

図２９に示すように、この問題に対処するために、本発明の一実施形態は、ユーザのクライアントデバイス６１１とＩｏＴデバイス１０１との間に二次の通信チャネル２９１０を確立するための技術を提供することにより、ユーザは、（ＩｏＴハブ１１０とＩｏＴサービス１２０との間の通信経路上にバツ印で示されるように）ＩｏＴサービス１２０への接続が失われたときにさえ、ＩｏＴデバイス１０１からのデータを制御及び収集してもよい。したがって、ＩｏＴデバイス１０１が無線ドアロックである場合、ユーザは、たとえＩｏＴサービス１２０への一次の通信チャネル２９１１が動作不能であっても、二次の通信チャネル２９１０を使用してユーザのフロントドアをロック解除してもよい。

一実施形態では、二次のチャネル２９１０は、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）通信チャネルを備える。しかしながら、本発明の基本原理は、いかなる特定の無線通信プロトコルにも限定されない。

一実施形態では、二次のチャネル鍵２９５０～２９５１のセットがクライアントデバイス６１１及びＩｏＴデバイス１０１に記憶又は維持されることにより、ＩｏＴデバイス１０１とクライアントデバイス６１１との間に安全な二次の通信チャネル２９１０を確立するために使用される。二次のチャネル鍵２９５０～２９５１は、安全な鍵交換プロトコルを使用して、クライアントデバイス６１１とＩｏＴデバイス１０１との間で交換されてもよい。例えば、上記の同一の鍵交換プロトコル（又は、そのサブセット）は、クライアントデバイス６１１とＩｏＴデバイス１０１との間で鍵を交換するために使用されてもよい。その代替として、鍵がランダムに生成されて、安全にＩｏＴサービス１２０からＩｏＴデバイス１０１及びクライアントデバイス６１１に（すなわち、ＩｏＴサービスへの接続が動作可能である期間の間に）提供されてもよい。

いったん鍵が交換されてしまうと、クライアントデバイス６１１の暗号化エンジン２９６０は、それ自体の鍵２９５０を使用してＩｏＴデバイス１０１との通信を暗号化してもよく、ＩｏＴデバイス１０１の暗号化エンジン１６６１は、それ自体の鍵２９５１を使用してクライアントデバイス６１１から受信された通信を復号してもよい。反対に、ＩｏＴデバイス１０１の暗号化エンジン１６６１は、それ自体の鍵を使用して通信を暗号化してもよく、クライアントデバイス６１１の暗号化エンジン２９６０は、それ自体の鍵を使用して通信を復号してもよい。

クライアントデバイスに鍵を記憶することが上記の実施形態よりも安全ではないので、ＩｏＴデバイス１０１によって公表される機能は、第２の通信チャネル２９１０が使用されるときに限定されてもよい。第２のチャネル２９１０が使用されるときに公表／可能にされる機能は、また、製品に依存してもよい。例えば、ユーザは、ＩｏＴデバイス１０１からデータのサブセットを取り出すのを可能にされてもよく、及び／又は、ＩｏＴデバイス１０１を構成又は制御するためのコマンドのサブセットを提供されてもよい。例として、ＩｏＴデバイスは、「安全な」データとみなされるデータへのユーザーアクセスを拒んでもよく、（例えば、ＩｏＴデバイスのセキュリティコードを変える等の）「安全な」コマンドへのアクセスを拒んでもよい。

無線ドアロック等の特定タイプのＩｏＴデバイス１０１は、単一の単純な機能を有してもよい。一実施形態では、これらの機能へのアクセスは、追加のセキュリティの層を使用して、二次のチャネル２９１０を介して提供される。例えば、一実施形態では、ＩｏＴデバイスの認証モジュール２９７０は、Ｎ桁の数又は英数字パスワード等のセキュリティパスコード２９７１によって構成される。例えば、このことは、一次の安全な通信チャネル１９１１がＩｏＴサービス１２０とＩｏＴデバイス１０１との間に確立されるという期間中に実行されてもよい。ＩｏＴサービス１２０に接続すると、ユーザは、クライアントデバイス６１１のパスコードエントリアプリ２９２０を介してパスコードを選んでもよい。パスコードは、次いで、ＩｏＴサービス１２０から安全に送信されて、ＩｏＴデバイス１０１の安全な記憶装置内に安全に記憶されてもよい。

その後、ユーザが（例えば、上記のような二次のチャネル鍵を使用して）クライアントデバイス６１１から二次の通信チャネル２９１０を確立するときに、ＩｏＴデバイス１０１は、ユーザに、安全なパスコードを入力することを促してもよい。ユーザがパスコードエントリアプリ２９２０から正しく安全なパスコードを入力する場合、認証モジュール２９７０が、ユーザを認証して、ＩｏＴデバイス１０１（又は、それの指定サブセット）によって実行されるべきデータ及び機能へのアクセスを提供することになる。一実施形態では、認証エンジン２９７０は、指定された数のパスコード試行が失敗した後に、二次の通信チャネル２９１０を切断することになる。例えば、ＩｏＴデバイス１０１が無線ドアロックである場合、パスコードは、ユーザの家庭へのエントリのためのセキュリティの追加の層として作用する。

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

３００１において、安全な接続が、（例えば、上記の安全な鍵交換技術を使用して、ＩｏＴデバイスによって）ＩｏＴサービスとＩｏＴデバイスとの間に確立される。３００２において、二次の鍵交換が、ＩｏＴデバイスとクライアントデバイスとの間で実行される。上記のように、このことは、（例えば、鍵のランダムなセットを生成して、ＩｏＴデバイス及びクライアントデバイスのそれぞれに鍵を安全に提供してもよい）クライアントデバイスとＩｏＴデバイスとの間で直接、又はＩｏＴサービスを介してを含む様々な方法で達成されてもよい。

３００３において、ＩｏＴデバイスは、安全なパスコードによってプログラミングされる。上記のように、このことは、ユーザにＮ桁の数値コード又は英数字コードを入力することを促す、ユーザのクライアントデバイスのアプリを介して実行されてもよい。パスコードは、ＩｏＴサービスとＩｏＴデバイスとの間に確立された安全なチャネルを介してＩｏＴデバイスに安全に送信されてもよい。

一次の安全な接続の失敗が３００４において決定される場合、３００５において、クライアントデバイスとＩｏＴデバイスとの間の二次の安全な接続が、二次の通信プロトコルを使用して確立されてもよい。一実施形態では、二次のプロトコルは、３００２において交換された二次の鍵を使用して、ＩｏＴデバイスとクライアントデバイスとの間の通信を暗号化する。上記のように、基礎の無線通信プロトコルは、ＢＴＬＥ又は別のローカル無線プロトコルを使用して実装されてもよい。

３００６において、ＩｏＴデバイスは、ユーザにユーザのクライアントデバイスを介して安全なパスワードを入力することを促す。ユーザによる正しいパスコードの入力が３００７において決定される場合、ＩｏＴデバイスは、３００８においてそれ自体のデータ及び機能（又は、そのサブセット）へのアクセスを許可する。ユーザが正しいパスコードを入力しない場合、３００９において、ＩｏＴデバイスへのアクセスが拒否される。

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

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

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

図３１は、ＩｏＴデバイス１０１の一実施形態を示し、この実施形態において、ＢＴＬＥ通信インターフェース３１１０は、データが送信される準備ができているときにアドバタイジング間隔を調節するアドバタイジング間隔選択ロジック３１１１を含む。それに加えて、ＩｏＴハブ１１０のＢＴＬＥ通信インターフェース３１２０は、アドバタイジング間隔の変化を検出し、確認応答を与え、及びデータを受信するためのアドバタイジング間隔検出ロジック３１２１を含む。

特に、示している実施形態では、ＩｏＴデバイス１０１のアプリケーション３１０１は、それが送信されるべきデータを有することを示す。それに応じて、アドバタイジング間隔選択ロジック３１１１は、アドバタイジング間隔を修正してデータが送信されるべきこと（例えば、間隔を．７５Ｔ又はなんらかの別の値に変えること等）をＩｏＴハブ１１０に通知する。アドバタイジング間隔検出ロジック３１２１が変化を検出すると、ＢＴＬＥ通信インターフェース３１２０は、ＩｏＴデバイス１０１のＢＴＬＥ通信インターフェース３１１０に接続して、それがデータを受信する準備ができていることを示す。ＩｏＴデバイス１０１のＢＴＬＥ通信インターフェース３１１０は、次いで、ＩｏＴハブのＢＴＬＥ通信インターフェース３１２０にデータを送信する。ＩｏＴハブは、次いで、自らを通してＩｏＴサービス１２０に、及び／又はユーザのクライアントデバイス（図示せず）にデータを渡してもよい。データが送信された後に、アドバタイジング間隔選択ロジック３１１１は、次いで、通常のアドバタイジング間隔（例えば、ＡＩ＝Ｔ）に戻ってもよい。

本発明の一実施形態では、安全な通信チャネルが、上記のセキュリティ／暗号化技術のうちの１つ又は複数を使用して、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間に確立される（例えば、図１６Ａ～図２３Ｃ及び関連する本文を参照）。例えば、一実施形態では、ＩｏＴサービス１２０は、上記のようにＩｏＴデバイス１０１との鍵交換を実行して、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間のすべての通信を暗号化する。

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

３２００において、ＩｏＴデバイスは、（例えば、時間Ｔによって分離される）アドバタイジングパケットを生成するときに、標準のアドバタイジング間隔を使用する。３２０２において、ＩｏＴデバイスは、送るべきデータを有することが３２０１において決定されるまで、標準のアドバタイジング間隔を維持する。次いで、３２０３において、ＩｏＴデバイスは、アドバタイジング間隔を切り換えて送信するべきデータを有することを示す。３２０４において、ＩｏＴハブ又は別のネットワークデバイスは、ＩｏＴデバイスとの接続を確立することにより、ＩｏＴデバイスがそれ自体のデータを送信するのを可能にする。最終的に、３２０５において、ＩｏＴデバイスは、それ自体の保留データをＩｏＴハブに送信する。

アドバタイジング間隔技術がＢＴＬＥプロトコルと関連して本明細書に記載されているけれども、本発明の基礎原理は、ＢＴＬＥに限定されないことを留意すべきである。実際に、本発明の基礎原理は、デバイス同士の間に無線通信を確立するためのアドバタイジング間隔を選択する任意のシステムに実装されてもよい。

それに加えて、専用のＩｏＴハブ１１０が上記の多くの実施形態に示されているけれども、専用のＩｏＴハブハードウェアプラットホームが本発明の基礎原理に従うのに必要ではない。例えば、上記の様々なＩｏＴハブは、ｉＰｈｏｎｅｓ（登録商標）及びＡｎｄｒｏｉｄ（登録商標）デバイス等の様々な別のネットワーキングデバイス内で実行されるソフトウェアとして実装されてもよい。実際に、本明細書に記載されたＩｏＴハブは、（例えば、ＢＴＬＥ又は別のローカル無線プロトコルを使用して）ＩｏＴデバイスと通信することができる、及び（例えば、ＷｉＦｉ又はセルラーのデータ接続を使用してＩｏＴサービスに）インターネットを介して接続を確立することができる任意のデバイスに実装されてもよい。
無線通信パターンを曖昧化するための装置及び方法

たとえＩｏＴサービスとＩｏＴデバイスとの間で送信されるデータが上記の技術を使用して暗号化されるとしても、ＩｏＴサービスとＩｏＴデバイスとの間の無線トランザクションが収集されて分析されることによりユーザ行動を決定する。例えば、図３３に示すように、ＩｏＴサービス１２０は、ＩｏＴデバイスが無線ドアロックである場合に、指定時点ｔ₀においてＩｏＴデバイスにコマンド３３０２を送信して、ドアをロック解除する等の特定の機能を実行してもよい。示すように、コマンドは、ＩｏＴハブ１１０のＷＡＮインターフェース３３２１及びローカル無線通信インターフェース３３２０を通して（又は、ＩｏＴハブ機能を実装するモバイルデバイス又は別のデバイスを介して）渡されてもよい。ＩｏＴデバイス１０１のアプリケーション特有のプログラムコード３３１５は、次いで、３３０３においてコマンドを実行して、第２の時間ｔ₁においてローカル無線通信モジュール３３１０に応答を提供してもよい。無線通信モジュールは、次いで、ｔ₂において応答３３０４を送信する。一般に、無線リンクを介して送信されるコマンド３３０２と、コマンド３３０３の実行と、ＩｏＴサービスに送信して戻される応答３３０４との間のタイミングは、すべて予測可能な様式で生じることになる。例えば、コマンド３３０２を受信すると、アプリケーション３３１５は、概してそのコマンドを実行することと、応答３３０４を返すこととに同一の時間を要してもよい。したがって、無線通信を聴いている何者かは、通信パターンを暗号解読して、ユーザがユーザのドアをロック解除（又はロック固定）している、又は、様々な別のデバイス特有の機能を実行していることを理解し得る。

これらの懸念に対処するために、本発明の一実施形態は、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間の通信パターンを不明瞭化又は曖昧化するための技術を実行する。図３４は、かかる一実施形態を示し、この実施形態では、ＩｏＴデバイス１０１のサービスプログラムコード３３２１及び／又はローカル無線通信インターフェース３３１０は、本明細書に記載された様々な技術を実装するためのメッセージ通信曖昧化ロジック３４１１、３４１０を含む。特に、一実施形態では、ｔ₀においてコマンド３３０２を受信すると、アプリケーション３３１５は、ｔ₁においてそれ自体のアプリケーション特有の機能を実行して応答を提供する。しかし、図３３に示す実施形態とは対照的に、図３４では、メッセージ通信曖昧化ロジック３４１０は、応答３４０４を送信するためのタイミング遅延を導入する。したがって、ｔ₂において応答を送信する代わりに、それはｔ₂＋Ｎにおいて応答を送信し、ここで、Ｎは、時間の指定範囲内でランダムに選択された値であってもよい。タイミングを変えることに加えて、一実施形態では、メッセージ通信曖昧化ロジック３４１０は、別の技術を実行して指定の又はランダムな量だけ応答３４０４のサイズを修正する（例えば、応答パケットにＭ個の追加のバイトを付加する）等、応答を曖昧化してもよい。この態様では、ＩｏＴサービスとＩｏＴデバイスとの間のトランザクションは、先の実施形態におけるよりも予測が難しくなる。

図３５は、ＩｏＴサービス１２０とＩｏＴデバイス１０１との間の通信を曖昧化するための別の実施形態を示す。この実施形態では、ＩｏＴサービス１２０のメッセージ通信曖昧化ロジック３４１１は、コマンドパケット３３０２の前後のいずれかにおいて曖昧化パケット３５０１を送信する。図３５に示す特定の例では、それは、前に（すなわち、時間ｔ_xにおいて）送信される。一実施形態では、曖昧化パケット３５０１は、暗号化されたメッセージを含み、このメッセージは、ＩｏＴデバイス１０１のメッセージ通信曖昧化ロジック３４１０に（例えば、図３５の値Ｌによって識別される１００ｍｓ、２００ｍｓ等の）将来のなんらかの特定時間において返信メッセージ３５０２を送信させる。応答３５０２を送信する前に待機するための特定の時間は、曖昧化パケット３５０１において指定されてもよい。その代替として、待機時間の長さは、ＩｏＴデバイス１０１のメッセージ通信曖昧化ロジック３４１０によって指定されてもよい。例えば、時間の長さは、ＩｏＴサービス１２０のメッセージ通信曖昧化ロジック３４１１によって、又はＩｏＴデバイス１０１のメッセージ通信曖昧化ロジック３４１０によってランダムに選択されてもよい。応答が送信される時間をランダム化することは、ハッカーが真のトラフィック２６０２、２６０４と（本質的にノーオペレーショントラフィックである）曖昧化トラフィック２８０１、２８０２との間で区別することを困難にする。示すように、ＩｏＴデバイス１０１のメッセージ通信曖昧化ロジック２７１０は、それでも実際の応答２６０４を送信するためのランダムな遅延を実装して、トラフィックを更に曖昧化してもよい。

それに加えて、一実施形態では、曖昧化パケット２８０１は、ＩｏＴデバイス１０１のメッセージ通信曖昧化ロジック２７１０に１つ又は複数のおとりアドバタイズメントパケット２８０４を送信することを命令してもよい。上記の安全ＢＴＬＥ技術を使用するＩｏＴデバイスは、なんらかのプログラミング可能な間隔において、それらが自らが利用可能であることを示すＲＦ「チャープ」を送信するという「アドバタイジング」を実行する。誰でも、このアドバタズメントパケットを盗聴及び傍聴することができる。アドバタイズメントの部分として、１ビットが使用されて、ＩｏＴサービス１２０がＩｏＴデバイスが読み出すためのデータを有することを示す。このように、ＩｏＴサービス１２０が曖昧化パケット２８０１を送信するとき、それは、また、デバイスが将来のいくつかのプログラミング可能な時間において、おとりアドバタイズメントを送信することを要求してもよい。この追加機構は、（明瞭である）アドバタイズメントを盗聴するハッカーが真のものとおとりとの間で区別するのを困難にする。

一実施形態では、上記の様々な曖昧化技術は、ＩｏＴデバイス１０１の曖昧化ルール２７１２及びＩｏＴサービス１２０の曖昧化ルール２７１３のセットに基づいてプログラミング可能である。ルール２７１２は、例えば、曖昧化パケット２８０１、応答２８０２、及びおとりアドバタイズメント２８０４に対して使用されるべき特定のタイミングを指定してもよい。一実施形態では、ルール２７１２、２７１３は、システムの最新の状態変数２７２０、２７２１にそれぞれ従って、メッセージ通信曖昧化ロジック２７１０、２７１１の動作を指定する。最新の状態変数２７２０、２７２１は、通信が曖昧化されている対象のＩｏＴデバイス１０１のタイプ、ＩｏＴデバイス１０１の最新のバッテリレベル、時刻、最新の天気等の高水準因子を含んでもよい。例えば、特定のＩｏＴデバイス１０１は、予測可能な周期的な通信パターンを本来的に生成してはならない。かかるＩｏＴデバイスに対して、本明細書に記載された曖昧化技術は、最小のものに設定されてもよい。更に、ＩｏＴデバイス１０１のバッテリ寿命が短い（例えば、閾値を下回る）場合、より少ない数の曖昧化パケット２８０１及びおとりアドバタイズメント２８０４が、バッテリ寿命を保つために生成されてもよい。勿論、様々な異なるタイプのルールが、本発明の基礎原理に従いながら指定されてもよい。

本発明の一実施形態に従う方法が図２９に示されている。方法は、上記のシステムアーキテクチャとの関連で実装されてもよいけれども、いかなる特定のシステムアーキテクチャにも限定されない。

２９００において、ＩｏＴデバイスは、ＩｏＴサービスからコマンドを受信し、２９０１においてコマンドを実行する。２９０２において、メッセージ通信曖昧化ロジックは、応答のタイミングを調節する。上記のように、このことは、ランダムな又は予め選択されたタイミング遅延を挿入することによって達成されてもよい。２９０３において、ＩｏＴデバイスは、調節されたタイミングに従って応答を送信する。

一実施形態に従う別の方法が図３０に示されている。３０００において、ＩｏＴサービスは、ＩｏＴデバイスにコマンド（例えば、ドアをロック解除するためのコマンド）を送信する。３００１において、ＩｏＴサービスは、ＩｏＴデバイスに曖昧化パケットを送信する。上記のように、曖昧化パケットは、コマンドの前後のいずれかにおいて送信されてもよい。３００２において、ＩｏＴデバイスは、コマンドを実行して（例えば、ドアをロック解除して）応答を送信する。一実施形態では、タイミング遅延は、（例えば、図２９に関して説明されたような）応答のために使用されてもよい。３００３において、ＩｏＴデバイスは、曖昧化パケットに曖昧化応答を送信する。一実施形態では、曖昧化パケットは、タイミングが応答のために使用されることを示す。別の実施形態では、ＩｏＴデバイスは、（例えば、指定範囲内のランダムな時間長を選択して）応答のためのタイミングを決定する。曖昧化応答は、選択されたタイミングによって、応答の前後のいずれかにおいてコマンドに送信されてもよい。３００４において、ＩｏＴデバイスは、曖昧化パケットに応じて、おとりアドバタイズメントを送信する。おとりアドバタイズメントは、単独で、又は曖昧化応答の送信に付加して送信されてもよい。

図２４は、ＩｏＴデバイス１０１の一実施形態を示し、この実施形態では、ＢＴＬＥ通信インターフェース２４１０が、データが送信される準備ができているときにアドバタイジング間隔を調節するアドバタイジング間隔選択ロジック２４１１を含む。それに加えて、ＩｏＴハブ１１０のＢＴＬＥ通信インターフェース２４２０は、アドバタイジング間隔検出ロジック２４２１を含むことにより、アドバタイジング間隔の変化を検出し、確認応答を与え、データを受信する。

特に、示している実施形態では、ＩｏＴデバイス１０１のアプリケーション２４０１は、送信されるべきデータが有することを示す。それに応じて、アドバタイジング間隔選択ロジック２４１１は、アドバタイジング間隔を修正することにより、データが送信されるべきこと（例えば、間隔を．７５Ｔ、又はなんらかの別の値に変えること等）をＩｏＴハブ１１０に通知する。アドバタイジング間隔検出ロジック２４２１が変化を検出すると、ＢＴＬＥ通信インターフェース２４２０は、ＩｏＴデバイス１０１のＢＴＬＥ通信インターフェース２４１０に接続して、それがデータを受信する準備ができていることを示す。ＩｏＴデバイス１０１のＢＴＬＥ通信インターフェース２４１０は、次いで、ＩｏＴハブのＢＴＬＥ通信インターフェース２４２０にデータを送信する。ＩｏＴハブは、次いで、自らを通してＩｏＴサービス１２０に、及び／又はユーザのクライアントデバイス（図示せず）にデータを渡してもよい。データが送信された後に、アドバタイジング間隔選択ロジック２４１１は、次いで、通常のアドバタイジング間隔（例えばＡＩ＝Ｔ）に戻ってもよい。

本発明の一実施形態では、安全な通信チャネルが、上記のセキュリティ／暗号化技術のうちの１つ又は複数を使用して、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間に確立される（例えば、図１６Ａ～２３Ｃ及び関連する本文を参照）。例えば、一実施形態では、ＩｏＴサービス１２０は、上記のようにＩｏＴデバイス１０１との鍵交換を実行して、ＩｏＴデバイス１０１とＩｏＴサービス１２０との間のすべての通信を暗号化する。

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

２５００において、（例えば、時間Ｔによって分離された）アドバタイジングパケットを生成するときに、ＩｏＴデバイスは、標準のアドバタイジング間隔を使用する。ＩｏＴデバイスは、２５０２において、それが送るべきデータを有することが２５０１において決定されるまで、標準のアドバタイジング間隔を維持する。次いで、２５０３において、ＩｏＴデバイスは、アドバタイジング間隔を切り換えることにより、送信するべきデータを有することを示す。２５０４において、ＩｏＴハブ又は別のネットワークデバイスは、ＩｏＴデバイスとの接続を確立することにより、ＩｏＴデバイスがそれ自体のデータを送信するのを可能にする。最終的に、２５０５において、ＩｏＴデバイスは、それ自体の保留データをＩｏＴハブに送信する。

Claims (20)

1. モノのインターネット（ＩｏＴ）デバイスとクライアントデバイスとの間に二次の通信チャネルを確立する方法であって、
   一次の鍵のセットを使用して前記ＩｏＴデバイスとＩｏＴサービスとの間に一次の安全な通信チャネルを前記ＩｏＴデバイスによって確立することと、
   前記一次の安全な通信チャネルを使用して二次の鍵交換を前記ＩｏＴデバイスによって実行することであって、前記クライアントデバイス及び前記ＩｏＴデバイスは、それぞれ前記二次の鍵交換の後に二次の鍵のセットを提供される、ことと、
   前記クライアントデバイスのアプリケーション（アプリ）からパスコードを前記ＩｏＴデバイスによって受信することであって、前記クライアントデバイスのユーザが前記パスコードを選び、前記パスコードは、前記一次の安全な通信チャネルを介して前記ＩｏＴデバイスに送信される、ことと
   前記ＩｏＴデバイスによって、前記ＩｏＴデバイスに前記パスコードを記憶することと、
   前記ＩｏＴデバイス及び／または前記クライアントデバイスによって、前記一次の安全な通信チャネルが動作不能であることを検出することと、
   それに応じて、前記ＩｏＴデバイス及び／または前記クライアントデバイスによって、前記二次の鍵のセットを使用して、前記クライアントデバイスと前記ＩｏＴデバイスとの間に二次の安全な無線接続を確立することと、
   前記ＩｏＴデバイスによって、前記ユーザに前記パスコードを前記クライアントデバイスから入力することを要求することと、
   前記ユーザが正しいパスコードを前記クライアントデバイスから入力したときだけ、前記クライアントデバイスに、前記二次の安全な無線接続を介して前記ＩｏＴデバイスによって利用可能にされたデータ及び／又は機能へのアクセスを前記ＩｏＴデバイスによって提供することと、
   を含む、方法。
2. 前記二次の安全な無線接続を介する前記データ及び／又は機能へのアクセスは、前記一次の安全な通信チャネルを介して接続されるときよりも前記データ及び／又は機能へのより限定されたアクセスを含む、請求項１に記載の方法。
3. 前記二次の安全な無線接続を確立すると、前記ユーザに前記パスコードを入力することを促すために、前記クライアントデバイスの前記アプリを実行することを更に含み、前記パスコードは、前記ＩｏＴデバイスが前記データ及び／又は機能へのアクセスを提供する前に、前記アプリから前記ＩｏＴデバイスに送信される、請求項１に記載の方法。
4. 前記ＩｏＴデバイスは、無線ドアロックを備え、前記二次の安全な通信チャネルを介してアクセスされるべき少なくとも１つの機能が、前記無線ドアロックをロック解除することを含む、請求項３に記載の方法。
5. 一次の鍵のセットを使用して、前記ＩｏＴデバイスとＩｏＴサービスとの間に一次の安全な通信チャネルを確立することが、
   ＩｏＴハブ又は前記クライアントデバイスを通して前記ＩｏＴサービスと前記ＩｏＴデバイスとの間に通信を確立することと、
   サービス公開鍵及びサービス秘密鍵を前記ＩｏＴサービス上の第１の暗号化エンジンの鍵生成ロジックによって生成することと、
   デバイス公開鍵及びデバイス秘密鍵を前記ＩｏＴデバイス上の第２の暗号化エンジンの鍵生成ロジックによって生成することと、
   前記サービス公開鍵を前記第１の暗号化エンジンから前記第２の暗号化エンジンに送信し、前記デバイス公開鍵を前記第２の暗号化エンジンから前記第１の暗号化エンジンに送信することと、
   前記デバイス公開鍵及び前記サービス秘密鍵を使用して秘密を生成することと、
   前記サービス公開鍵及び前記デバイス秘密鍵を使用して同一の前記秘密を生成することと、
   前記秘密を使用して又は前記秘密から派生したデータ構造を使用して、前記第１の暗号化エンジンと前記第２の暗号化エンジンとの間で送信されるデータパケットを暗号化及び復号することと、
   を含む、請求項１に記載の方法。
6. 前記鍵生成ロジックは、ハードウェアセキュリティモジュール（ＨＳＭ）を備える、請求項５に記載の方法。
7. 前記秘密から派生した前記データ構造は、前記第１の暗号化エンジンによって生成された第１の鍵ストリームと、前記第２の暗号化エンジンによって生成された第２の鍵ストリームと、を備える、請求項６に記載の方法。
8. 第１のカウンタは、前記第１の暗号化エンジンと関連し、第２のカウンタは、前記第２の暗号化エンジンと関連し、前記第１の暗号化エンジンは、前記第２の暗号化エンジンに送信される各データパケットに応じる前記第１のカウンタを増加させ、前記第２の暗号化エンジンは、前記第１の暗号化エンジンに送信される各データパケットに応じる前記第２のカウンタを増加させる、請求項７に記載の方法。
9. 前記第１の暗号化エンジンは、前記第１のカウンタの現在のカウンタ値及び前記秘密を使用して前記第１の鍵ストリームを生成し、前記第２の暗号化エンジンは、前記第２のカウンタの現在のカウンタ値及び前記秘密を使用して前記第２の鍵ストリームを生成する、請求項８に記載の方法。
10. 前記第１の暗号化エンジンは、前記第１のカウンタ値及び前記秘密を使用して前記第１の鍵ストリームを生成するための楕円曲線方法（ＥＣＭ）モジュールを備え、前記第２の暗号化エンジンは、前記第１のカウンタ値及び前記秘密を使用して前記第２の鍵ストリームを生成するためのＥＣＭモジュールを備える、請求項９に記載の方法。
11. 前記第１の暗号化エンジンは、前記第１の鍵ストリームを使用して第１のデータパケットを暗号化することにより、第１の暗号化されたデータパケットを生成し、
    前記第１の暗号化されたデータパケットを前記第１のカウンタの現在のカウンタ値と共に前記第２の暗号化エンジンに送信する、請求項９に記載の方法。
12. 前記第２の暗号化エンジンは、前記第１のカウンタの現在のカウンタ値及び前記秘密を使用して前記第１の鍵ストリームを生成し、前記第１の鍵ストリームを使用して前記第１の暗号化されたデータパケットを復号する、請求項１１に記載の方法。
13. モノのインターネット（ＩｏＴ）ロジックデバイスとクライアントデバイスとの間に二次の通信チャネルを確立するシステムであって、
    前記ＩｏＴロジックデバイス、前記クライアントデバイス及び認証回路を備え、
    前記ＩｏＴロジックデバイスは、一次の鍵のセットを使用してＩｏＴサービスとの一次の安全な通信チャネルを確立し、
    前記ＩｏＴロジックデバイスは、前記一次の安全な通信チャネルを使用して二次の鍵交換を実行し、
    前記クライアントデバイス及び前記ＩｏＴロジックデバイスは、前記二次の鍵交換の後に、それぞれ二次の鍵のセットを提供され、
    前記認証回路は、前記ＩｏＴロジックデバイスにパスコードを記憶し、前記認証回路が前記ＩｏＴロジックデバイスに前記パスコードを記憶する前に前記クライアントデバイスのアプリケーション（アプリ）から前記パスコードは最初に受信され、前記クライアントデバイスのユーザは前記パスコードを選択し、前記パスコードは前記一次の安全な通信チャネルを介して前記ＩｏＴロジックデバイスへ送信され、
    前記認証回路は前記ＩｏＴロジックデバイスに前記パスコードを記憶し、
    前記ＩｏＴロジックデバイス及び／又は前記クライアントデバイスは、前記一次の安全な通信チャネルが動作不能であることを検出し、
    前記ＩｏＴロジックデバイス及び／又は前記クライアントデバイスは、それに応じて、前記二次の鍵のセットを使用して前記クライアントデバイスと前記ＩｏＴロジックデバイスとの間に二次の安全な無線接続を確立し、
    前記認証回路は前記クライアントデバイスから前記パスコードを入力するように前記ユーザを促すためのものであり、
    前記ＩｏＴロジックデバイスは、前記ユーザが前記クライアントデバイスから正しいパスコードを入力したときだけ、前記クライアントデバイスに、前記二次の安全な無線接続を介して前記ＩｏＴロジックデバイスによって利用可能にされたデータ及び／又は機能へのアクセスを提供される、システム。
14. 前記二次の安全な無線接続を介するデータ及び／又は機能への前記アクセスは、前記一次の安全な通信チャネルを介して接続されるときよりも、前記データ及び／又は機能へのより限定されたアクセスを含む、請求項１３に記載のシステム。
15. 前記クライアントデバイスで実行される前記アプリが、前記二次の安全な無線接続を確立すると、前記ユーザに前記パスコードを入力することを促すことを更に備え、前記パスコードは、前記ＩｏＴロジックデバイスが前記データ及び／又は機能へのアクセスを提供する前に、前記アプリから前記ＩｏＴロジックデバイスに送信される、請求項１３に記載のシステム。
16. 前記ＩｏＴロジックデバイスは、無線ドアロックを備え、前記二次の安全な通信チャネルを介してアクセスされるべき少なくとも１つの機能が、前記無線ドアロックをロック固定又はロック解除することを含む、請求項１５に記載のシステム。
17. 一次の鍵のセットを使用して、前記ＩｏＴロジックデバイスと前記ＩｏＴサービスとの間に一次の安全な通信チャネルを確立することが、
    前記ＩｏＴロジックデバイスが、ＩｏＴハブ又は前記クライアントデバイスを通して前記ＩｏＴサービスとの通信を確立することと、
    サービス公開鍵及びサービス秘密鍵を生成するための鍵生成ロジックを備える、ＩｏＴサービス上の第１の暗号化エンジンと、
    デバイス公開鍵及びデバイス秘密鍵を生成するための鍵生成ロジックを備える、ＩｏＴロジックデバイス上の第２の暗号化エンジンと、を備え、
    第１の暗号化エンジンは、第２の暗号化エンジンにサービス公開鍵を送信するためのものであって、第２の暗号化エンジンは、第１の暗号化エンジンにデバイス公開鍵を送信するためのものであり、
    第１の暗号化エンジンは、デバイス公開鍵及びサービス秘密鍵を使用して秘密を生成するためのものであり、
    前記第２の暗号化エンジンは、前記サービス公開鍵及び前記デバイス秘密鍵を使用して同一の前記秘密を生成するためのものであり、
    いったん前記秘密が生成されると、前記第１の暗号化エンジン及び前記第２の暗号化エンジンは、前記秘密を使用して又は前記秘密から派生したデータ構造を使用して、前記第１の暗号化エンジンと前記第２の暗号化エンジンとの間で送信されるデータパケットを暗号化及び復号する、請求項１３に記載のシステム。
18. 前記鍵生成ロジックは、ハードウェアセキュリティモジュール（ＨＳＭ）を備える、請求項１７に記載のシステム。
19. 前記秘密から派生したデータ構造は、前記第１の暗号化エンジンによって生成された第１の鍵ストリームと、前記第２の暗号化エンジンによって生成された第２の鍵ストリームと、を備える、請求項１８に記載のシステム。
20. 前記第１の暗号化エンジンと関連する第１のカウンタと、前記第２の暗号化エンジンと関連する第２のカウンタと、を更に備え、前記第１の暗号化エンジンは、前記第２の暗号化エンジンに送信される各データパケットに応じる前記第１のカウンタを増加させ、前記第２の暗号化エンジンは、前記第１の暗号化エンジンに送信される各データパケットに応じる前記第２のカウンタを増加させる、請求項１９に記載のシステム。

Images