JP6596091B2 - 物のインターネットのプラットフォーム、装置、及び方法 - Google Patents

Description

本発明は、概して、コンピュータシステムの分野に関する。より具体的には、本発明は、ネットワークデバイスを安全に接続するためのシステムのインターネット及び方法に関する。

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

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

ＩｏＴシステムアーキテクチャの異なる実施形態を示す。 ＩｏＴシステムアーキテクチャの異なる実施形態を示す。 本発明の一実施形態によるＩｏＴデバイスを示す。 本発明の一実施形態によるＩｏＴハブを示す。 セキュリティアーキテクチャの一実施形態の高レベル図を示す。 ＩｏＴデバイス上に鍵を記憶するために加入者識別モジュール（ＳＩＭ）が使用されるアーキテクチャの一実施形態を示す。 バーコード又はＱＲコード（登録商標）を使用してＩｏＴデバイスが登録される一実施形態を示す。 バーコード又はＱＲコード（登録商標）を使用してペアリングが実行される一実施形態を示す。 ＩｏＴハブを使用してＳＩＭをプログラミングするための方法の一実施形態を示す。 ＩｏＴデバイスをＩｏＴハブ及びＩｏＴサービスに登録するための方法の一実施形態を示す。 ＩｏＴデバイスに送信されるデータを暗号化するための方法の一実施形態を示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一実施形態では、低電力マイクロコントローラ２００は、後述する実施形態（例えば、図４〜図６及び関連付けられた本文を参照）によって使用される暗号鍵を記憶するための安全な鍵ストアも含む。代替的に、キーは、後述するように、加入者識別モジュール（ＳＩＭ）内に確保されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. システムであって、
   ハードウェア物のインターネット（ＩｏＴ）ハブであって、広域ネットワーク（ＷＡＮ）を介して前記ＩｏＴハブをＩｏＴサービスに連結するためのネットワークインターフェースと、
   ＩｏＴデバイスとの暗号化通信を確立するために使用可能な１つ以上の暗号鍵を用いて識別デバイスをプログラミングするためのプログラミングロジックと、を備える、物のインターネット（ＩｏＴ）ハブと、
   前記ＩｏＴハブによる前記識別デバイスのプログラミング後に前記識別デバイスとインターフェース接続する、前記ＩｏＴデバイスと、を備え、
   前記識別デバイスがプログラミングされ、前記ＩｏＴデバイスとインターフェース接続されると、前記ＩｏＴデバイスが、前記１つ以上の鍵を使用して、前記ＩｏＴハブ／前記ＩｏＴサービスとの安全な通信チャンネルを確立し、
   前記識別デバイスをプログラミングすることが、公開／秘密鍵ペアを生成すること、及び前記公開／秘密鍵ペアのうち少なくとも前記秘密鍵を前記識別デバイス上に記憶することを含み、
   前記識別デバイスをプログラミングすることが、少なくとも前記公開鍵を前記ＩｏＴハブ上の安全な記憶装置内に記憶することを更に含み、
   前記ＩｏＴハブが、前記ネットワークインターフェースを介して、対応する署名付きの前記公開鍵を前記ＩｏＴサービスに安全に転送することと、更に、前記ＩｏＴハブに関連付けられ、かつＩｏＴハブ秘密鍵に対応する、対応する署名付きのＩｏＴハブ公開鍵を安全に転送することと、を更に含み、
   コマンド／データを前記ＩｏＴデバイスに安全に送信するために、前記ＩｏＴサービスが、前記コマンド／データを暗号化し、前記公開鍵を使用して第１の署名を生成して、暗号化されたＩｏＴデバイスパケットを生成し、次に、前記ＩｏＴデバイスパケットを暗号化し、前記ＩｏＴハブ公開鍵を使用して第２の署名を生成して、ＩｏＴハブパケットを生成する、
   システム。
2. 前記識別デバイスが、加入者識別モジュール（ＳＩＭ）を備える、請求項１に記載のシステム。
3. 前記識別デバイスが、前記ＩｏＴデバイスに結合される、請求項１に記載のシステム。
4. 前記ＩｏＴハブが、ＩｏＴハブ秘密鍵を使用して、前記ＩｏＴハブパケットを解読し、前記第２の署名を認証して、前記ＩｏＴデバイスパケットを生成し、前記ＩｏＴデバイスパケットを前記ＩｏＴデバイスに転送し、前記ＩｏＴデバイスが、前記秘密鍵を使用して、前記第１の署名を認証し、前記ＩｏＴデバイスパケットを解読する、請求項１に記載のシステム。
5. 前記識別デバイスが、前記プログラミングロジックによって提供される秘密鍵を記憶するための安全鍵記憶装置を備える、請求項１に記載のシステム。
6. 前記暗号鍵が、対称暗号鍵を備える、請求項１に記載のシステム。
7. システムであって、
   広域ネットワーク（ＷＡＮ）を介してハードウェア物のインターネット（ＩｏＴ）ハブをＩｏＴサービスに連結するためのネットワークインターフェースを備える前記ＩｏＴハブと、
   ＩｏＴデバイスとの安全な通信チャンネルを確立するために使用可能な１つ以上の暗号鍵を受信するための、前記ＩｏＴハブ上のローカルインターフェースと、を備え、
   前記ＩｏＴハブが前記１つ以上の暗号鍵を受信したら、前記ＩｏＴハブ及び前記ＩｏＴサービスが、前記１つ以上の暗号鍵を使用して、前記ＩｏＴデバイスとの安全な通信チャンネルを確立する、
   第１の公開／秘密鍵ペアが、前記ＩｏＴデバイスと関連付けられ、前記ＩｏＴハブが、前記第１の公開／秘密鍵ペアのうち少なくとも前記公開鍵を受信し、前記公開鍵を前記ＩｏＴサービスに転送する、
   第２の公開／秘密鍵ペアが、前記ＩｏＴハブと関連付けられ、前記ＩｏＴハブが、前記第２の公開／秘密鍵ペアのうち少なくとも前記公開鍵を、前記ＩｏＴデバイス及び前記ＩｏＴサービスに提供する、
   前記ＩｏＴデバイスが、前記第２の公開／秘密鍵ペアの前記公開鍵を使用して、前記ＩｏＴハブに向けられた通信を暗号化し、前記ＩｏＴハブ及び前記ＩｏＴサービスが、前記第１の公開／秘密鍵ペアの前記公開鍵を使用して、前記ＩｏＴデバイスに向けられた通信を暗号化する、
   コマンド／データを前記ＩｏＴデバイスに安全に送信するために、前記ＩｏＴサービスが、前記第１の公開／秘密鍵ペアの前記公開鍵を使用して前記コマンド／データを暗号化して、暗号化されたＩｏＴデバイスパケットを生成し、次に、前記第２の公開／秘密鍵ペアの前記公開鍵を使用して前記ＩｏＴデバイスパケットを暗号化して、ＩｏＴハブパケットを生成する、
   システム。
8. 前記ローカルインターフェースが、前記１つ以上の暗号鍵を識別するバーコード又はＱＲコードを読み取るためのバーコード又はＱＲコードリーダを備える、請求項７に記載のシステム。
9. 前記ＩｏＴハブが、前記第１及び第２の公開／秘密鍵ペアの前記公開鍵を、前記ＩｏＴサービスに安全に転送する、請求項７に記載のシステム。
10. 前記ＩｏＴサービスが、前記ＩｏＴデバイスの前記公開鍵を使用して、各コマンド／データと共に送信される署名を生成し、前記ＩｏＴデバイスが、前記ＩｏＴデバイスの前記秘密鍵を使用して前記署名を検証する、請求項７に記載のシステム。
11. 前記ＩｏＴサービスが、前記ＩｏＴデバイスに送信されるコマンド／データ毎にシーケンス番号又はナンスを含み、前記ＩｏＴデバイスが、前記シーケンス番号又はナンスを検証する、請求項７に記載のシステム。
12. 前記ＩｏＴハブが、前記第２の公開／秘密鍵ペアの前記秘密鍵を使用して、前記ＩｏＴハブパケットを解読して、前記ＩｏＴデバイスパケットを生成し、前記ＩｏＴデバイスパケットを前記ＩｏＴデバイスに転送し、前記ＩｏＴデバイスが、前記第１の公開／秘密鍵ペアの前記秘密鍵を使用して、前記ＩｏＴデバイスパケットを解読する、請求項７に記載のシステム。
13. 前記ローカルインターフェースが、ＢＬＵＥＴＯＯＴＨ低エネルギー（ＬＥ）通信チャンネル又はＷＩＦＩ通信チャンネルを備える、請求項７に記載のシステム。
14. 前記暗号鍵が、前記ＩｏＴデバイス及びＩｏＴハブによって共有される対称暗号鍵を備える、請求項６に記載のシステム。
15. 方法であって、
    広域ネットワーク（ＷＡＮ）を介して物のインターネット（ＩｏＴ）ハブをＩｏＴサービスに連結するためのネットワークインターフェースを備える前記ＩｏＴハブを提供することと、
    ＩｏＴデバイスとの暗号化通信を確立するために使用可能な１つ以上の暗号鍵を含めるように、前記ＩｏＴハブによって識別デバイスをプログラミングすることと、
    前記ＩｏＴハブによる前記識別デバイスのプログラミング後に、前記ＩｏＴデバイスを前記識別デバイスとインターフェース接続することと、を含み、
    前記識別デバイスがプログラミングされ、前記ＩｏＴデバイスとインターフェース接続されると、前記ＩｏＴデバイスが、前記１つ以上の鍵を使用して、前記ＩｏＴハブ及び／又は前記ＩｏＴサービスとの安全な通信チャンネルを確立する、
    前記識別デバイスをプログラミングすることが、公開／秘密鍵ペアを生成すること、及び前記公開／秘密鍵ペアのうち少なくとも前記秘密鍵を前記識別デバイス上に記憶することを含み、
    前記識別デバイスをプログラミングすることが、少なくとも前記公開鍵を前記ＩｏＴハブ上の安全な記憶装置内に記憶することを更に含み、
    前記ＩｏＴハブが、前記ネットワークインターフェースを介して、対応する署名付きの前記公開鍵を前記ＩｏＴサービスに安全に転送することと、更に、前記ＩｏＴハブに関連付けられ、かつＩｏＴハブ秘密鍵に対応する、対応する署名付きのＩｏＴハブ公開鍵を安全に転送することと、を更に含み、
    コマンド／データを前記ＩｏＴデバイスに安全に送信するために、前記ＩｏＴサービスが、前記コマンド／データを暗号化し、前記公開鍵を使用して第１の署名を生成して、暗号化されたＩｏＴデバイスパケットを生成し、次に、前記ＩｏＴデバイスパケットを暗号化し、前記ＩｏＴハブ公開鍵を使用して第２の署名を生成して、ＩｏＴハブパケットを生成する、
    方法。
16. 前記識別デバイスが、加入者識別モジュール（ＳＩＭ）を備える、請求項１５に記載の方法。
17. 前記識別デバイスが、前記ＩｏＴデバイスに結合される、請求項１５に記載の方法。
18. 前記識別デバイスをプログラミングすることが、公開／秘密鍵ペアを生成すること、及び前記公開／秘密鍵ペアのうち少なくとも前記秘密鍵を前記識別デバイス上に記憶することを含む、請求項１５に記載の方法。
19. 前記識別デバイスをプログラミングすることが、少なくとも前記公開鍵を前記ＩｏＴハブ上の安全な記憶装置内に記憶することを更に含む、請求項１８に記載の方法。
20. 前記ＩｏＴハブが、前記ネットワークインターフェースを介して、前記公開鍵を前記ＩｏＴサービスに安全に転送することと、更に、前記ＩｏＴハブに関連付けられ、かつＩｏＴハブ秘密鍵に対応するＩｏＴハブ公開鍵を安全に転送することと、を更に含む、請求項１９に記載の方法。

Images