本発明の特定の実施形態は、コントローラデバイス(又は「コントローラ」)と、制御される任意数の他の電子デバイス(本明細書では「アクセサリデバイス」又は単純に「アクセサリ」と称されるもの)との間の通信のための、「統一的」プロトコルに関する。コントローラは、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯電話、他のハンドヘルド型コンピューティングデバイス又は着用型コンピューティングデバイスなどの、汎用コンピューティングデバイス上で、その汎用コンピューティングデバイスに適切な実行可能プログラムコードを提供することによって実装することができ、あるいは、コントローラは特殊目的コンピューティングデバイスとすることもできる。アクセサリは、コントローラによって制御可能な任意のデバイスを含み得る。アクセサリの例としては、照明器具、サーモスタット、ドアロック、自動ドア開閉装置(例えば、ガレージドア開閉装置)、スチルカメラ又はビデオカメラなどが挙げられる。アクセサリ及びコントローラは、Wi−Fi、Bluetooth、Bluetooth LEなどの標準トランスポートプロトコルを使用する、有線チャネル又は無線チャネルを介して、互いに通信することができる。
例示的環境
図1は、本発明の実施形態による、家庭環境100を示す。家庭環境100は、環境100内に配置された様々なアクセサリデバイス(アクセサリとも称されるもの)と通信することが可能なコントローラ102を含む。コントローラ102としては、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、携帯情報端末、あるいは、本明細書で説明されるようなアクセサリにコマンド及び制御メッセージを通信して、ユーザインタフェースを提示することにより、ユーザがそれらのアクセサリ上での所望の動作を指示することが可能となる、任意の他のコンピューティングデバイス又はデバイスのセットを挙げることができる。一部の実施形態では、コントローラ102は、複数の個別デバイスを使用して実装することができる。例えば、環境100内の固定された場所に設置することが可能な、アクセサリと通信する基地局と、ユーザインタフェースを提供し、基地局と通信することによりアクセサリに対する制御を達成する、1つ以上の移動リモート制御局(例えば、携帯電話、タブレットコンピュータ、スマートウオッチ、眼鏡などのハンドヘルド型デバイス又はウェアラブルデバイス)とが存在し得る。
任意のタイプのアクセサリデバイスを制御することができる。アクセサリデバイスの例としては、ドアロック104、ガレージドアシステム106、照明器具108、防犯カメラ110、及びサーモスタット112が挙げられる。一部の場合には、コントローラ102は、アクセサリと直接通信することができ、例えばコントローラ102は、ドアロック104及びガレージドアシステム106と直接通信しているように示されている。他の場合には、コントローラ102は、中継機器を介して通信することができる。例えばコントローラ102は、無線ネットワークアクセスポイント114を介して、アクセスポイント114によって提供される無線ネットワーク上に存在するアクセサリ108、110、112と通信しているように示されている。上述のように一部の実施形態では、コントローラ102は基地局を含み得るものであり、基地局の機能性は、アクセスポイント114に組み込むか、又は制御されるアクセサリのうちの1つ(例えば、サーモスタット112)に組み込むことができる。
様々な通信トランスポート及びトランスポートの組み合わせを使用することができ、種々のトランスポートを、種々のデバイスで使用することができる。通信トランスポートの一実施例は、Bluetooth SIG,Inc.(http://www.bluetooth.com)によって定義及び公表されたBluetooth(登録商標)通信規格及びプロトコルに適合する、トランスポートとすることができ、用語「Bluetooth」とは、本明細書で使用するとき、全般的に、Bluetooth(登録商標)通信規格及びプロトコルを指し、用語「Bluetooth LE」とは、本明細書で使用するとき、Bluetooth(登録商標)Smart(登録商標)通信規格及びプロトコルを指す。Bluetoothプロトコルは、限られた範囲内での、デバイス間の直接的なポイントツーポイント通信をサポートすることができる。通信トランスポートの別の実施例は、Wi−Fi Alliance(登録商標)(http://www.wi−fi.org)によって定義及び公布されたWi−Fi(登録商標)通信規格及びプロトコルに適合する、トランスポートとすることができ、本明細書で使用するとき、「Wi−Fi」とは、全般的に、Wi−Fi(登録商標)規格及びプロトコルを指す。Wi−Fiプロトコルは、中央アクセスポイントを有する無線ネットワークを定義することができ、この中央アクセスポイントは、そのネットワーク上の種々のデバイス間の通信を経路指定する。このネットワークは、例えばTCP及びHTTPを含めた、標準インターネットプロトコルスイート(IP)をサポートすることができる。Bluetooth及びWi−Fiは、通信トランスポート及び通信プロトコルの実施例として使用されるものであり、他のトランスポート及びプロトコルもまた、使用することができる点を理解されたい。更には、無線通信トランスポートが示されているが、有線トランスポートもまた、これらのアクセサリのうちの一部又は全てに提供することができる。例えば、電球108は、有線接続によってアクセスポイント114に接続することができ、コントローラ102は、ブリッジとしての役割を果たし得るアクセスポイント114に無線でメッセージを送信し、このアクセスポイント114が、有線接続を介して電球108にメッセージを伝えることによって電球108と通信することができる。有線通信と無線通信との他の組み合わせもまた可能である。
更には、1つのコントローラ102が示されているが、家庭環境100は、複数のコントローラデバイスを有し得る。例えば、この家庭に居住する各人は、アクセサリ104〜112のうちの一部又は全てに関するコントローラとしての役割を果たすことが可能な、1つ以上の個人用デバイス(例えば、携帯電話、タブレット、ラップトップ、ウェアラブルデバイス)を有し得る。異なるコントローラデバイスは、それらのアクセサリの異なるサブセットと通信するように構成することができ、例えば、子供のコントローラは、サーモスタット112に対する設定を修正することを阻止される場合があるが、その一方で、親のコントローラは、設定を修正することが許可される。そのような許可は、例えば以下で説明されるペアリング技術を使用して、構成及び制御することができる。
本発明の特定の実施形態は、アクセサリ104〜112のうちのいずれか又は全てなどの1つ以上のアクセサリとの、コントローラ102などのコントローラによる通信を容易にする、統一的アクセサリプロトコルに関する。このプロトコルは、アクセサリをサービスの集合としてモデル化する、単純かつ拡張可能なフレームワークを提供し得るものであり、各サービスは、特性のセットとして定義され、各特性は、任意の所定の時間での定義値を有する。それらの特性は、そのアクセサリの状態の様々なアトミックな態様を表し得る。例えば、サーモスタット112の場合には、特性としては、電力(サーモスタットがオン又はオフのいずれであるか)、サーモスタット112によって測定される現在温度、及びサーモスタット112が設定される目標温度を挙げることができる。サービス及び特性を使用するアクセサリモデルの実施例は、以下で説明される。
このプロトコルは、アクセサリ(例えば、サーモスタット112)にコマンド及び制御メッセージ(要求)を送信するために、コントローラ(例えば、コントローラ102)によって使用可能なメッセージフォーマットと、コントローラ(例えば、コントローラ102)に応答メッセージを送信するために、アクセサリ(例えば、サーモスタット112)によって使用可能なメッセージフォーマットとを、更に定義することができる。コマンド及び制御メッセージにより、コントローラは、アクセサリ特性の現在の状態を問い合わせる(例えば、読み取る)ことが可能となり、一部の場合には、アクセサリ特性を修正する(例えば、書き込む)ことが可能となり得る。例えば、サーモスタット112の電力特性を修正することにより、サーモスタット112を、オフ又はオンにすることができる。したがって、適切なメッセージを送信することによって、機能又は製造元に関わりなくいずれのタイプのアクセサリも制御することができる。これらのメッセージフォーマットは、コントローラ及びアクセサリの全体にわたって、統一的なものとすることができ、実施例が以下で説明される。一部の実施形態では、アクセサリは、アクセサリ定義レコードを、コントローラに提供することができる。このアクセサリ定義レコードは、そのアクセサリの、アクセス可能な全ての特性についての完全な情報を含み得る。コントローラは、アクセサリと対話する方法を決定する際に、そのアクセサリ定義レコードを使用することができる。例えば、コントローラは、アクセサリ定義レコードからの情報を使用することにより、そのアクセサリを動作させるためのユーザインタフェースを構築すると共に、そのアクセサリに対する要求メッセージを構築することができる。
このプロトコルは、状態変化の場合に、アクセサリ112(又は、他のアクセサリ)がコントローラ102に選択的に通知することを可能にする、通知メカニズムを更に定義することができる。例としては、コントローラ102が、いずれかの特性が変化したか否かを見つけ出すためにアクセサリ(例えば、アクセサリ112)に問い合わせることが可能な受動的通知メカニズム、並びに、特定の特性が変化する場合に、アクセサリ112(又は、他のアクセサリ)が、選択的に1つ以上のコントローラに対するメッセージを生成すること、及び/又は広告を一斉配信することが可能な能動的、広告式、又はイベントベースの通知メカニズムが挙げられる。複数の通知メカニズムを同時にサポートすることができ、コントローラは、特定のアクセサリ、サービス、又は特性に関して使用する通知メカニズムを選択することができる。実施例が以下で説明される。
一部の実施形態では、所定のアクセサリとの通信は、認可済みコントローラに限定することができる。このプロトコルは、コントローラ102がアクセサリ104を制御することが可能となる、ユーザが意図する高度の信頼性を提供する状況下で、コントローラ102と所定のアクセサリ(例えば、ドアロックアクセサリ104)との間で「ペアリング」を確立する1つ以上のメカニズムを指定することができ、特定のアクセサリとペアリングを確立したコントローラは、そのアクセサリに関して認可済みであると見なすことができる。ペアリングは例えば、短期キー及び帯域外共有シークレットを使用する、安全な暗号化フレームワークを確立することによって、確立することができる。アクセサリ及びコントローラに関する長期公開キーをこのフレームワーク内で交換することができ、アクセサリ及びコントローラは、それらの交換されたキーを永続的に記憶することにより、ペアリングを確立することができる。ペアリングが確立された後、アクセサリ104は、受信した通信が、ペアリング済みコントローラ102からであるか、又は別のデバイスからであるかを検証することが可能であり、アクセサリ104は、ペアリング済みコントローラ102からではない、あらゆる通信を拒絶することができる(逆もまた同様)。例えば、以前にペアリングを確立したアクセサリとコントローラとが再接続する場合、それらは、以前のペアリングを(例えば、それぞれが他方の長期公開キーを保有することを証明することによって)検証して、ペア検証済みセッション内での通信に関して使用される、セッション固有の暗号キーを生成することができる。一部の実施形態では、複数のコントローラが同じアクセサリとペアリングを確立することができ、アクセサリは、そのペアリング済みコントローラのうちのいずれからの通信も、受理して応答することができる一方で、ペアリングされていないコントローラからの通信は、拒絶又は無視することができる。ペアリングプロセスの実施例が以下で説明される。
家庭環境100は例示的なものであり、変型及び修正が可能であることが理解されるであろう。本発明の実施形態は、ユーザが、コントローラデバイスを使用して1つ以上のアクセサリデバイスを制御することを望む、任意の環境内で実施することができ、それらの環境としては、家庭、自動車若しくは他の乗り物、オフィスビル、複数の建物を有する構内(例えば、大学又は企業の構内)などが挙げられるが、これらに限定されない。コントローラは、1つ以上の他のデバイス(アクセサリ)を制御するために使用される、任意のデバイスとすることができ、アクセサリは、その動作の一部又は全てを、コントローラによって制御することが可能となる、任意のデバイスとすることができる。コントローラ102は、コントローラ内に実施されるか又は含まれるものとして本明細書で説明される特徴のうちの、いずれか若しくは全てを実施するか又は含み得るものであり、アクセサリ104〜112などのアクセサリは、アクセサリ内に実施されるか又は含まれるとして本明細書で説明される特徴のうちの、いずれか若しくは全てを実施するか又は含み得る。
一部の実施形態では、コントローラ102は、リモートな場所(例えば、世界内の任意の場所)から、アクセサリ(例えば、アクセサリ108)と通信することができる。例えば、リモートな環境内に配置されている間、コントローラ102は、アクセサリ108にメッセージを中継する(例えば、アクセサリ108とローカルで通信することが可能な、環境100内に配置されたアクセスポイント114と通信することによる)能力を有するサーバと、広域ネットワーク(例えば、インターネット)を介して通信することができる。コントローラ102とアクセサリ108との間の通信のコンテンツは、サーバには不透明なものとすることができ、例えば、コントローラ102及びアクセサリ108は、メッセージが暗号化されている安全な通信セッション(例えば、本明細書で説明されるような、ペア検証済みセッション)を確立することができ、サーバは、その暗号化されたデータを、そのコンテンツに関しては不可知のままで、単純に転送することができる。それゆえ、アクセサリは、ローカルで(例えば、アクセサリへの直接通信経路を確立することが可能なコントローラによって)、又はリモートで(例えば、中継サーバなどを介して間接的に通信するコントローラによって)動作させることができる。
例示的アクセサリモデル
一部の実施形態では、統一的アクセサリプロトコルは、任意のアクセサリを「サービス」の集合としてモデル化する、統一的なフレームワーク及びシンタックスを提供することができる。「サービス」とは、本明細書で使用するとき、アクセサリデバイスの特徴、機能、若しくは動作を達成するための、データ及び関連挙動の集合(又は、その一部分)を指すことができる。各サービスは、「特性」の集合としてモデル化することができ、各特性は、そのアクセサリのアトミックなデータ要素又は挙動(アクセサリ状態の要素とも称されるもの)を表す。以下で説明されるように、アクセサリは、アクセサリ定義レコードをコントローラに提供することによって、そのアクセサリ自体をコントローラに説明することができ、このアクセサリ定義レコードは、そのアクセサリのサービス及び特性を定義する、構造化データオブジェクトとすることができる。この構造化データオブジェクトは、様々な特定のフォーマットで、例えば、JSON(JavaScript(登録商標)オブジェクト表記法)、Bluetooth LE汎用属性プロファイル(GATT)、あるいは、構造化データを表現して通信する他の技術及びフォーマットを使用して、表現することができる。以下で説明されるように、コントローラは、アクセサリを制御する方法を決定するために、アクセサリ定義レコードを使用することができる。
例えば、図1のサーモスタットアクセサリ112は、何らかの目標に近い温度を維持するように、ある区域(例えば、部屋、又は建物、若しくは建物の一部分)の温度を調節する機能を実行する、構成要素を含み得る。アクセサリ112をモデル化する目的上、温度調節は、「サーモスタット」サービスとして特定することができる。このサーモスタットサービスの特性としては、サーモスタットがオン又はオフのいずれであるか、現在の設定目標温度、現在の測定温度、及び、サーモスタットによって調節されるシステムが、現在、加熱モード(加熱器をオンにすることにより、より高い目標温度に向けて測定温度を駆動することが可能)であるか、若しくは冷却モード(冷却器をオンにすることにより、より低い目標温度に向けて測定温度を駆動することが可能)であるかを、挙げることができる。より複雑な実施例では、サーモスタットは、例えば、時刻及び/又は曜日に応じて異なる目標温度を選択するように、プログラム可能とすることができ、そのような場合には、特性は、時間範囲のセット及び各時間範囲に対する関連目標温度などの特徴をプログラムすることを含み得る。
一部の場合には、アクセサリは、複数のサービスを提供することができる。例えば、ガレージドアアクセサリ106は、自動ガレージドア開閉装置を使用して実装することができ、この自動ガレージドア開閉装置は、ドアを開閉させることができ、また、例えばガレージの内部を照らすように制御することが可能な、照明も有する。したがって、ガレージドアアクセサリ106の定義としては、ガレージドアを開閉する機能を達成する「ドア開閉装置」サービスと、照明をオン又はオフにする(異なる)機能を達成する「電球」サービスとを挙げることができる。「ドア開閉装置」サービスの特性としては、ドアの現在の状態(例えば、開放、閉鎖、開放の途中、閉鎖の途中)、ドアが(例えば、開閉装置がドアを開放することを防ぐために)ロックされているか否か、及びドアが妨害されているか否か(例えば、ドア開閉装置システム内の障害物センサが、ドアの閉鎖を妨害する障害物を検知しているか否か)を挙げることができる。電球サービスの特性としては、照明がオン又はオフのいずれであるか、及び(照明が可変輝度制御を有する場合には)現在の輝度レベルを挙げることができる。
任意のアクセサリを、サービスの集合としてモデル化することができ、同じ環境内の異なるアクセサリが、同じサービス又は同様のサービスのうちの一部若しくは全てを含み得ることを理解されたい。例えば、家庭環境100などの環境は、異なる場所の複数の電球(例えば、各部屋内の照明)、複数のドアロック(例えば、各外部ドアのロック、室内ドアのロック)などを有し得る。一部の実施形態では、統一的アクセサリプロトコルは、各アクセサリ及び各サービスを一意的に特定することができるように、名前空間を定義することによって、そのような重複を明示的に可能にすることにより、異なるアクセサリ上の同じサービスのインスタンス、又は同じアクセサリ上の同様のサービスの複数のインスタンスを、容易に識別することが可能となる。
一部の実施形態では、統一的アクセサリプロトコルは、頻繁に使用され、かつ/又は種々のアクセサリタイプの範囲にわたって存在すると予想される特性を含み得る、「コア」特性のセットを定義することができる。この特性のセットは、拡張可能にさせることができ、例えば、アクセサリ製造元は、製造元固有の特性(本明細書では「拡張」特性とも称されるもの)を定義することが許容される場合がある。それゆえ、アクセサリは、コア特性に限定されない、しかしながら、適用可能な場合に、コア特性を使用することにより、システムの設計及び動作を容易にすることができる。例えば、コントローラのシステムソフトウェアは、コア特性のプロパティを定義するコードを含み得るものであり、コア特性のみを使用するアクセサリは、その特性及びそれらの現在の値を特定することによって、そのアクセサリ自体をコントローラに説明することができる。
図2A〜図2Dは、本発明の実施形態による、定義することが可能な標準特性201〜229の一部の実施例を示す。各特性201〜229は、それらの特性の所定のインスタンスが属するサービスを提供するアクセサリ(又は、アクセサリの一部分)の状態の、何らかの態様を表す値(図2A〜図2Dには示さず)を有し得る。この実施例では、各特性201〜229は、タイプ、許可、及びフォーマットを有するものとして説明される。フォーマットに応じて、追加的情報(例えば、最小値、最大値、ステップサイズ、単位、又は有効値の列挙リスト)もまた含まれる。
特性の「タイプ」は、その特性に割り当てられた、一意の名前又は識別子(例えば、文字列)とすることができる。この実施例では、タイプを割り当てるために、逆引きドメイン名規則が使用され、このことにより、アクセサリ製造元による拡張特性の定義を容易にすることができる。例えば、図2A〜図2Dに示される特性定義を含む、統一的アクセサリプロトコルの公布者が、「proto.com」と呼ばれるインターネットドメインの所有者である場合には、全てのコア特性のタイプは、文字列「com.proto.ch.」で開始して、その後に、「on」、「brightness」などの、特性固有の名前を続けることができる。他の命名規則を使用することもできる。
一部の実施形態では、命名されるタイプに加えて、又はその代わりに、一意の数値識別子(図2A〜図2Dには示さず)を、各特性に割り当てることができる。例えば、一意の数値識別子は、Internet Engineering Task Force(IETF)RFC4122に適合する、36の十六進数からなるUUIDとすることができる(本明細書で参照される全ての「IETF RFC」文書は、http://ietf.org/rfc.htmlを介してアクセスすることができる)。この統一的アクセサリプロトコルは、全てのコア特性に関する共通の「ベース」UUID(例えば、最後の28の十六進数)を定義して、各特性に一意の「短い」UUID(例えば、最初の8つの十六進数)を割り当てることができ、任意の番号付けスキームを使用することができる。特にUUIDを短縮化する規則と組み合わされた、UUIDの使用により、コントローラ又はアクセサリは、文字列の使用と比較すると、より少量の送信データを使用して、対象となる特性を指定することが可能となり得る。例えば、一部の実施形態では、短縮化規則により、36の数のUUIDを、僅か2つ又は3つの十六進数に低減することができる。
特性の「許可」は、コントローラが特性と対話する(例えば、特性を問い合わせるか又は修正する)ために許容される方式を示すことができる。一部の実施形態では、これらの許可は、文字列のアレイとして表すことができ、各文字列は、特定の対話の方式に対応する。文字列が存在する場合には、その文字列の対応する対話の方式が許可され、文字列が存在しない場合には、対話は許可されない。定義することが可能な許可文字列の一部の実施例を、表1に示す。
一部の実施形態では、特性に関する読み取り許可は、コントローラが、アクセサリ状態の対応する態様を見つけ出すことが所望される場合に与えられ、書き込み許可は、コントローラが、アクセサリ状態の対応する態様に変化を引き起こすことが可能であることが所望される場合に与えられる。それゆえ、例えば、アクセサリが直接制御することが可能な条件に関連する特性(例えば、Target Temperature特性210)は、読み取り及び書き込み許可を有し得るが、その一方で、アクセサリが直接制御することができない条件に関連する特性(例えば、Current Temperature特性209)は、読み取り許可のみを有し得る。
各特性201〜229は、アクセサリ状態の対応する属性又は態様を反映する、値を有し得る。図2A〜図2Dは、各特性201〜229の値に関するフォーマットを指定する。本明細書で使用するとき、<boolean>フォーマットは、その特性が真及び偽の値を取ることを示し、<int>フォーマットは、その特性が符号付きの整数値を取ることを示し、<float>は、その特性が符号付きの浮動小数点数値を取ることを示し、<string>は、その特性が、例えばUTF−8符号化を使用する、文字列値を取ることを示し、<date>は、その特性が日付値(例えば、ISO 8601フォーマットでのUTF−8日付文字列)を取ることを示し、<data>は、その特性を使用して、データブロブ(すなわち、そのコンテンツに関してプロトコルが不可知であり得る、データのブロック)を記憶することができることを示す。<enum>フォーマットは、その特性が、特定の条件を表す、定義された値のセットのうちの1つを取ることを示し、可能な値は、その特性に関する「有効値」として列挙される。一部の実施形態では、列挙値フォーマットは、各有効値に異なる整数を割り当てることによって実施することができる。<tlv>フォーマットは、パック化されたタイプ−長さ−値のデータタイプを示し、第1バイトはタイプを示し、第2バイトは長さ(Nバイト)を示し、残余のNバイトは値を含む。一部の実施形態では、他のフォーマットを使用することができ、例としては、本明細書では<object>として示される、データオブジェクトフォーマット(データオブジェクトは、キー−値フォーマットを使用して更に定義することができる)、及びアレイフォーマット(他のフォーマットのいずれかでの、固定長又は可変長の値のアレイとすることが可能なもの)が挙げられる。一部の実施形態では、統一的アクセサリプロトコルは、特性に関する許容フォーマットの、閉じた領域を指定することができ、それゆえ、全ての特性(拡張特性を含めたもの)の値は、それらの許容フォーマットのうちの1つで表される。
特性の値は、アクセサリ状態の属性又は態様を示すことができる。この値は、表されている情報に適切なフォーマットで、指定することができる。一部の場合には、特性定義は、値の範囲を指定することができる。例えば、「最大」(又は、「最大値」)は、上限値を示し得るものであり、「最小」(又は、「最小値」)は、下限値を示し得るものであり、「ステップ」(又は、「ステップサイズ」)は、離散値を取る特性に関する、最小の増分を示し得る。「単位」は、値が測定される際の具体的な単位を示すために、定義することができ、この情報により、コントローラによる値の解釈を容易にすることができる。
例えば、「On」特性201は、アクセサリの電源がオンである場合には「true」、アクセサリの電源がオフである場合には「false」のブール値を有し得る。この特性は、例えば、電球、照明スイッチ、又は、オン及びオフの状態を有する(かつ、そのオフ状態の間に、コントローラと通信することが可能な)他のアクセサリに関連して使用することができる。別の実施例としては、「Outlet in Use」特性202は、電源コンセントを有するアクセサリで使用することができ、そのブール値は、電源コンセントに電源プラグが接続されているか否かを示すことができる。この場合には、アクセサリは、電源プラグを物理的に挿入又は除去することができないと想定され、したがって、この特性は、読み取り専用の許可を有する。
アクセサリモデルを使用する、アクセサリ制御の単純な実施例として、電源コンセントアクセサリが、そのコンセントへの電力潮流を開始又は停止させることが可能な、制御スイッチを有すると仮定する。この電源コンセントアクセサリは、「On」特性201及び「Outlet in Use」特性202を有するサービスとして、モデル化することができる。コントローラは、「Outlet in Use」特性202を読み取ることにより、そのコンセントに電源プラグが接続されているか否かを判定することができ、次いで、電源プラグが接続されているか否かに応じて、そのコンセントへの電力を有効又は無効にするように、「On」特性201に書き込むことができる。
Brightness特性203、Hue特性204、及びSaturation特性205は、例えば、光源を提供するアクセサリに関連して使用することができる。Brightness特性203は、そのアクセサリによってサポートされる最大輝度の百分率として、輝度レベルを示す、(図2Aでの「最小、最大、ステップ」フィールドで示されるような)0〜100の範囲の整数値を有し得る。百分率の単位で指定される全ての特性と同様に、アクセサリは、デバイス状態の対応する態様(この場合には、輝度)に関して、厳密に100の別個の設定をサポートする必要がなく、その代わりに、アクセサリは、所定の百分率値を、利用可能な設定に対応付けすることができる点を理解されたい。Hue特性204は、0〜360度の範囲の色相を指定する、浮動小数点値を有し得るものであり、この度数の値の、自然界の色相への変換は、標準色モデル化の実践に従うものとすることができる。Saturation特性205は、所望の色の彩度を、最大値の百分率として定義する、0〜100の範囲の浮動小数点値を有し得る。コントローラは、これらの特性を読み取ることにより、現在の設定を判定することができ、これらの特性に書き込むことにより、その設定を変更することができる。他の色モデルもまた、サポートすることができる(例えば、CIE 1931色空間、色温度など)。
Audio Feedback特性206は、アクセサリが、ユーザ入力、又はアクセサリで検出される他のイベントに応答する、任意選択的な音声フィードバック(例えば、ビープ音)を有する場合に、使用することができる。音声フィードバックは、この特性にブール値を書き込むことによって有効又は無効にすることができる。Output Volume特性207は、音を発生させるアクセサリ上での出力音量を、読み取るか又は設定するために使用することができ、この値は、そのアクセサリが発生させることが可能な最大音量の、百分率を示し得る。
Logs特性208は、アクセサリが、タイムスタンプを押されたアクティビティのログを保持する場合に、使用することができる。それらのログの構造は、アクセサリ製造元によって定義することができ、又は、特定のタイプのアクセサリに関しては、統一的アクセサリプロトコルの発布者によって指定することができる。この実施例では、コントローラは、特性208を読み取ることによって、そのアクセサリのログを取得することができるが、それらのログを更新することはコントローラの役割ではないため、特性208には書き込まない。アクセサリは、そのルーチン動作の一部として、コントローラ対話のレコードをログに追加することができ、コントローラは、残りのログと共に、任意のそのようなレコードを受信することができる点を理解されたい。
図2Bは、サーモスタットアクセサリに関する特性の実施例を示すものであり、このサーモスタットアクセサリは、環境(例えば、家屋又は部屋)内部の現在温度を監視して、目標温度に向けて温度を調節するために、加熱及び/又は冷却システムを制御することが可能な、任意のアクセサリを含み得る。Current Temperature特性209は、アクセサリによって測定された現在温度を判定するために、コントローラによって読み取ることができる。Target Temperature特性210は、サーモスタットアクセサリの目標温度設定を判定するために、コントローラによって読み取ることができ、また、その目標温度設定を変更するために、コントローラによって書き込むこともできる。この実施例では、温度は、摂氏の度数で指定されるが、他の尺度(例えば、華氏、ケルビン)で置き換えることもできる。いずれの尺度がプロトコルによって指定されるかに関わりなく、コントローラ又はアクセサリは常に、内部使用及び/又はユーザへの表示のために、異なる尺度に変換することができる。例えば、Temperature Units211は、ユーザに温度を表示する際に、いずれの単位をアクセサリが使用するべきかを指示するために、コントローラによって読み取るか又は書き込むことができる。更には、温度特性209及び210は、許容される値の範囲を指定するが、他の範囲を使用することもでき、又は範囲を指定しないままにすることもできる。
一部のサーモスタットは、加熱及び冷却の双方を制御するように動作可能とすることができる。したがって、Current HEAT/Cool Status特性212を読み取ることにより、サーモスタットが現在、加熱している(目標温度に向けて能動的に加温している)か、冷却している(目標温度に向けて能動的に冷却している)か、又はオフであるかを判定することができる。コントローラは、いつ加熱又は冷却するべきかを決定するものではないため、書き込み許可は提供されない。サーモスタットの動作モードは、Target Heat/Cool Mode特性213に書き込むことによって制御することができる。この実施例では、モード特性213に関する有効値としては、加熱モード(サーモスタットが、目標温度に向けて環境を加温する)、冷却モード(サーモスタットが、目標温度に向けて環境を冷却する)、オートモード(サーモスタットが、環境の条件に応じて、加熱モード又は冷却モードを動的に選択することができる)、及びオフが挙げられる。オートモードが選択される場合、サーモスタットを加熱モード又は冷却モードへと切り替えるための、温度閾値を指定することが望ましい場合がある。例えば、Cooling Threshold Temperature特性214は、現在温度が冷却閾値温度を超過する場合には、サーモスタットが冷却モードを有効にするように、冷却閾値温度を設定するために、コントローラによって書き込むことができ、Heating Threshold Temperature特性215は、現在温度が加熱閾値温度を下回る場合には、サーモスタットが加熱モードを有効にするように、加熱閾値温度を設定するために、コントローラによって書き込むことができる。図2Bに示すように、Cooling Threshold Temperature特性214及びHeating Threshold Temperature特性215は、互いに異なり、かつTarget Temperature特性210とは異なる、上限値及び下限値を有し得るが、これは必須ではない。
図2Cは、ドア開閉装置(例えば、ガレージドア開閉装置、あるいは、ドアを開放及び/又は閉鎖する、他の自動化されたメカニズム)及びドアロックに関する特性の実施例を示す。Current Door State特性216は、ドアが現在、開放されているか、閉鎖されているか、開放若しくは閉鎖の途中か、又は停止している(例えば、完全開放又は完全閉鎖されておらず、移動もしていない)かを判定するために、コントローラによって読み取ることができる。Target Door State特性217は、ドアを開放するべきか又は閉鎖するべきかを指示するために、コントローラによって書き込むことができる。コントローラが、Current Door State特性216に合致しない値を、Target Door State特性217に書き込む場合には、アクセサリは、現在の状態を変更して、その目標に合致させるように、ドア開閉装置メカニズムを作動させることによって応答することができる。例えば、ドアが開放しており(Current Door State特性216が、「open(開放)」の値を有し)、コントローラが、Target Door State特性217に「closed(閉鎖)」の値を書き込む場合には、アクセサリは、ドアを閉鎖するように、ドア開閉装置を作動させることができる。ドア開閉装置の作動時に、アクセサリは、Current Door State特性216を「closing(閉鎖中)」に更新することができ、ドアが完全閉鎖されると、アクセサリは、Current Door State特性216を更に、目標状態に合致する「closed(閉鎖)」に更新することができる。コントローラは、Target Door State特性217を読み取ることによって、任意の時点で現在のドアの状態を学習することができる。
一部の実施形態では、ドア開閉装置アクセサリは、コントローラに追加的情報を提供することができる。例えば、Motion Detected特性218を使用することにより、ドアの周囲での動作(例えば、ドアをノックすること)を、アクセサリが検出したか否かを示すことができる。Obstruction Detected特性219を使用することにより、ドアの移動を妨げる恐れがある障害物を、アクセサリが検出したか否かを示すことができる。コントローラは、これらの特性を読み取ることによってこの情報を取得することができる。一部の実施形態では、アクセサリは、これらの特性の変化が検出された場合には(例えば、ドアが妨害されることになった場合、又は動作が検出された場合には)、コントローラに通知を送信することができる。
ドアをロックすることは、ドアの開放又は閉鎖とは、別個に取り扱うことができる。例えば、「ロックメカニズム」アクセサリは、デッドボルト、磁気ロック、又は、ドアが開放されることを防ぐために係合させることが可能な、任意の他の物理的メカニズムを制御する、任意のデバイスに関して実装することができる。Lock Mechanism Current State特性220は、ロックメカニズムが現在、固定解除(ロック解除)されているか、固定(ロック)されているか、故障している(ロック又はロック解除することが不可能)か、又は不明であるかを判定するために、コントローラによって読み取ることができる。Lock Mechanism Target State特性221は、ドアのロック又はロック解除を要求するために、コントローラによって書き込むことができる。Lock Mechanism Last Action特性222は、ロック上で実行された最後の既知の動作を判定するために、コントローラによって読み取ることができる。様々なレベルの詳細をサポートすることができる。例えば、一実施形態では、有効値としては、(1)物理的移動を使用する(例えば、ユーザがデッドボルトレバーを物理的に移動させた)内側からの固定、(2)物理的移動を使用する外側からの固定、(3)キーパッドを使用する固定、(4)リモートでの(例えば、コントローラからの要求に基づく)固定、(5)タイムアウト条件に基づく固定、(6)物理的移動を使用する内側からの固定解除、(7)物理的移動を使用する外側からの固定解除、(8)キーパッドを使用する固定解除、及び(9)リモートでの固定解除を挙げることができる。他の有効値の組み合わせもまた、所望される情報の粒度に応じて、定義することができる。
更なる特性を、ロックメカニズムの管理に関連付けることができる。例えば、Lock Management Auto Timeout特性223を使用することにより、アクセサリがロックを自動的に再ロックするまでの、タイムアウト期間を設定することができる。このタイムアウト期間は、例えば、ロックがロック解除されるときに開始することができる。一部の実施形態では、タイムアウト期間の持続時間は、その特性の(例えば、秒の単位での)数値とすることができ、値0は、タイムアウト期間が存在しない(すなわち、ロックは、ロックする特定の行動が取られるまで、ロック解除されたまま維持することができる)ことを示すために使用することができる。Lock Management Control Point特性224は、そのロックに関連する特定の機能を、例えば、その機能を特定する値を特性224に書き込むことによって、呼び出すために使用することができる。呼び出すことが可能な機能の実施例としては、ロックアクティビティのログの読み取り(Logs特性208に関する値をアクセサリが返すことを、結果的にもたらし得る)、ログの消去、ロックの時間の設定などが挙げられる。別の実施例として、供給元は、1日の特定の時間の間のみ、ロックのリモート開放を許可することなどの、ロックの使用に関する様々なポリシーを、ユーザが設定することを可能にするように、望む場合がある。一部の実施形態では、コントローラは、これらのポリシーを、Lock Management Control Point特性224に書き込むことによって、ロックアクセサリに提供することができる。一部の実施形態では、統一的アクセサリプロトコルは、Lock Management Control Point特性224に書き込まれるデータのコンテンツを指定しないが、統一的アクセサリプロトコルを使用して、コントローラからアクセサリに確実にデータを通信することができ、かつ供給元固有の方式で、そのデータをアクセサリによって解釈することができるように、TLVフォーマット又は他のフォーマットでデータが提供されることを、指定することができる。
図2Dは、コア特性の更なる実施例を示す。Rotation Direction特性225は、ファン(又は、回転要素を有する任意の他のアクセサリ)を、時計回り又は反時計回りのいずれかの方向で回転するように制御するために、使用することができる。Rotation Speed特性226は、ファン(又は、他の回転要素)の回転速度を制御するために使用することができ、この速度は、最大速度の百分率として示される。
Name特性227は、アクセサリ又はサービスに、人間に読み取り可能な名前を割り当てるために、使用することができる。この名前は、文字列として(例えば、UTF−8フォーマットで)表すことができる。
Administrator−Only Access特性228は、アクセサリ又はサービスへのアクセスを、そのアクセサリに関する管理者として確立されている(すなわち、管理者許可を有する)コントローラに限定するために、使用することができる。コントローラを管理者として確立する技術の実施例が、以下で説明される。一部の実施形態では、アクセサリの管理者として確立されているコントローラのみが、特性228に書き込むことができる。
Version特性229は、アクセサリ又はサービスについてのバージョン情報を提供するために、使用することができる。
図2A〜図2Dに示す特性は、実施例として提供されていることを理解されたい。任意数のコア特性を定義することができる。例えば、屋内環境の他の制御可能な態様(例えば、相対湿度)に関する特性を、定義することができる。統一的アクセサリプロトコルの一部として定義される特性の具体的な組み合わせは、必要に応じて変化させることができる。一部の実施形態では、コア特性として定義されない特性は、本明細書で説明される技術を使用して、サードパーティ(例えば、アクセサリ製造元)によって、拡張特性として定義することができる。
一部の実施形態では、これらの特性のセットは、拡張可能である。アクセサリは、新たな特性(「拡張」特性とも称されるもの)を、その特性に関するプロパティ(又は、記述子)のセットを提供することによって定義することができる。図2Eは、本発明の実施形態による、定義可能な特性のプロパティのセットを示す。コア特性に関しては、これらのプロパティは、プロトコルによって(例えば、図2A〜図2Dに示されるように)定義することができる。一部の実施形態では、アクセサリは、コア特性のプロパティのうちの一部を再定義することにより、その特性に関して定義されたデフォルトのプロパティを上書きすることができる。一部の実施形態では、拡張特性は、アクセサリ定義レコード内に、これらのプロパティを提供することによって定義することができる。実施例が以下で説明される。
「タイプ」230は、例えば、上述のような逆引きドメイン名規則を使用して特性のタイプを定義する、文字列とすることができる。一部の実施形態では、文字列に加えて、又は文字列の代わりに、数値識別子(例えば、上述のようなUUID)を、タイプ識別子として使用することができる。
「許可」231は、コントローラに関して許可されるアクセスのタイプを特定する、文字列(例えば、上記の表1内の許可のうちのいずれか又は全て)のアレイとすることができる。
「通知モード」232は、特性に対する変化を、どのようにコントローラに通知するべきかを指示するために使用される、文字列のアレイとすることができる。一部の実施形態では、コントローラは、特定の通知モードに加入するために、このプロパティに書き込むことができる。表2は、サポートすることが可能な通知モードの、一部の実施例を列挙する。これらの各通知モードの動作が、以下で説明される。
一部の実施形態では、受動的通知は、コントローラによるいずれの加入にも関わりなく、全ての特性に関して、全てのアクセサリによってサポートされ、他のサポートされる通知モードは、コントローラによる加入要求に基づいて、選択的に有効化することができる。一部の実施形態では、「Paired Read」許可を有する全てのコア特性はまた、少なくとも「イベント」通知モードもサポートする。
「フォーマット」233は、特性の値に関するフォーマットを特定する文字列、例えば、ブール値、文字列、整数、浮動小数点、TLVなどとすることができる。一部の実施形態では、このプロトコルは、認識されるフォーマットのセットを定義することができ、その定義されたセットから、フォーマット233を選択することができる。
「値」234は、特性の現在の値とすることができる。
「最小値」235及び「最大値」236は、限界が所望される場合に、特性に対する下限値及び上限値を設定するために、使用することができる。同様に、「ステップサイズ」237は、最小増分が所望される場合に、特性の値を変化させるための最小増分を指定するために、使用することができる。最小値、最大値、及びステップ値が指定される場合、アクセサリは、その範囲内のあらゆる有効値を認識して、その有効値に応答することが予想される。しかしながら、上述のように、このことは、そのアクセサリ上で利用可能な設定の数が、有効値の数と等しくなければならないことを意味するものではない。例えば、電球アクセサリが、Brightness特性203を有する場合には、このアクセサリは、輝度特性が100に設定されている場合に、輝度が最大となり、輝度特性が0に設定されている場合に、ゼロとなるように、(例えば、電球に供給される電流を調節することによって)輝度を制御することができる。輝度特性が定義されている電球は、ゼロと最大輝度との間に、少なくとも1つの中間階調を有するものと予想され(しかしながら、厳密に必要とされるものではない)、アクセサリのサポートが、100よりも多いか又は少ない中間階調である場合には、そのアクセサリは、その輝度階調に対する輝度特性値の対応付けを定義することができる。
一部の実施形態では、列挙値フォーマットをサポートすることができ、フォーマット233が「列挙」として指定される場合に、「validValues」プロパティ238を使用して、それらの有効値を列挙することができる。
「Unit」プロパティ239は、特性に関して使用する単位(例えば、百分率、特定の温度尺度など)を指示することができる。一部の実施形態では、このプロトコルは、好ましい単位系を指定することができ、この系の範囲内で、所定の特性に関するUnitプロパティ239を選択することができる。
「UserDescriptor」プロパティ240は、特性又はその機能を、人間に読み取り可能な方式で説明する、文字列を提供することができる。例えば、Current HEAT/Cool Status特性212に関するユーザ記述子は、「加熱/冷却システムが現在、加熱しているか、冷却しているか、又はオフであるかを示す」と言うことができる。
「所有者」プロパティ241は、特性を定義又は再定義した、組織単位を特定することができる。一部の実施形態では、このことは、ユーザ又は開発者が、様々な特性の定義のソースを理解するために役立ち得る。
図2Eでのプロパティ(及び、任意選択的に他のプロパティ)のうちのいずれか又は全てを、1つの特性に関して定義することができる。上述のように、コア特性に関しては、このプロトコルは、デフォルトの定義を指定することができ、コア特性が使用される場合、その特性のプロパティの全てを、(例えば、以下で説明されるような)アクセサリ定義レコード内に含めることは必須ではない。一部の実施形態では、アクセサリは、再定義するべきプロパティを、アクセサリ定義レコード内に含めることによってコア特性を再定義することができる。拡張特性は、それらが定義するプロパティの全てを、アクセサリ定義レコード内に含めることによって定義することができる。
一部の実施形態では、特性のプロパティは、コントローラによって読み取ることができ、それらの特性を制御するための、及び/又は現在の値を提示するための、グラフィカルユーザインタフェースをレンダリングする方法を決定するために、使用することができる。例えば、Brightness特性203(図2A)、又は百分率として表現される任意の他の特性の場合には、コントローラは、0〜100%のスライダとしてコントロールをレンダリングして、そのスライダを1%のステップで移動させることができる。特性201(図2A)、又はブール値として表現される任意の他の特性の場合には、コントローラは、オン/オフのスイッチをレンダリングすることができる。温度関連の特性の場合には、コントローラは、「摂氏」の単位(又は、他の温度単位)を有する特性に基づく温度計などをレンダリングすることができ、又は、単純に数値を表示することもできる。UserDescriptor240が、特性に関して定義される場合は、コントローラは、その特性に関するユーザインタフェース制御要素に関連して、テキストをレンダリングすることができ、このことは、その制御要素をユーザが理解することを容易にし得る。それゆえ、アクセサリは、自己記述型であり得ることにより、アクセサリ定義レコードが与えられると、コントローラは、任意のアクセサリを制御するためのインタフェースを、そのアクセサリに関して具体的にプログラムされていない場合でも、動的に生成することができる。
図2A〜図2Dに示す特性、及び図2Eに示すプロパティ(又は、記述子)は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。統一的アクセサリプロトコルは、任意数及び任意の組み合わせの特性を定義することができ、示されたものとは異なるプロパティ及び値のセットを使用して、特性を定義することができる。例えば、最大文字列長プロパティを使用して、文字列の長さに対して上限値を指定することができ、最大データ長プロパティを使用して、データを含む特性に対して(例えば、データオブジェクト又はデータブロブに関して)上限値を指定することができる。
更には、上述のように、このプロトコルは、アクセサリ製造元が、それらのアクセサリに関して、カスタマイズされた拡張特性、又は製造元固有の拡張特性を定義することを可能にし得る。例として、製造元(インターネットドメイン「discoball.com」を所有するもの)が、種々の方向及び種々の速度で回転するように制御することが可能なミラーボールと、そのボールの表面に向けて方向付けることが可能な光源とを有する、「ディスコボール」システムを製造すると想定する。光源は、図2A〜図2Dからのコア特性(例えば、「オン」特性201及びBrightness特性203)を使用して、モデル化及び制御することができる。製造元は、光源及び/又はミラーボールの更なる制御に関する、拡張特性を定義することを望む場合がある。図2Fは、このシナリオに関する拡張特性の実施例を示す。
Strobe特性242は、ストロボ効果を制御するための、例示的特性である。真である場合、この照明は、ストロボモードで動作され、偽である場合、この照明は、定常モードで動作される。
Direction特性243は、ミラーボールの回転の方向を制御するための、例示的特性である。このボールは、無回転(停止される)か、時計回りに回転するか、又は反時計回りに回転することができる。コア特性が、Rotation Direction特性225を含む実施形態では、製造元は、そのコア特性を使用するか又は拡張特性を定義するかを、選択することができる。
Speed特性244は、ミラーボールの回転の速度を制御するための、例示的特性である。この実施例での速度は、2つの設定(低速回転に関する0、高速回転に関する1)を有する。コア特性が、Rotation Speed特性226を含む実施形態では、製造元は、そのコア特性を使用するか又は拡張特性を定義するかを、選択することができる。
上述のように、統一的アクセサリプロトコルは、アクセサリを、1つ以上のサービスとしてモデル化することができ、各サービスは、特性の集合としてモデル化される。したがって、サービスは、その構成要素である特性を特定することによって定義することができ、それらの特性は、コア特性及び/又は拡張特性の、任意の組み合わせを含み得る。一部の実施形態では、統一的アクセサリプロトコルは、頻繁に使用され、かつ/又は様々なアクセサリタイプにわたって有用であると予想されるサービスを含み得る、コアサービスのセットを定義することができる。このサービスのセットは、拡張可能にさせることができ、例えば、アクセサリ製造元は、コアサービスに製造元固有の特性を追加するか、又は追加的な「拡張」サービスを定義することが、許容される場合がある。しかしながら、適用可能な場合に、コアサービスを使用することにより、既定のサービス及び特性を、システム設計者が活用することを可能にすることによって、システムの設計及び動作を容易にすることができる。
図2G、図2Hは、本発明の実施形態による、定義することが可能なコアサービス251〜258の実施例を示す。各サービス251〜258には、そのサービスを特定する一意の名前とすることが可能な、「タイプ」を割り当てることができる。この実施例では、特性のタイプと同様に、アクセサリ製造元による新たなサービスの定義を容易にするために、逆引きドメイン名規則を使用して、タイプを定義することができる。それゆえ、図2G、図2Hでのコアサービスのタイプは、「com.proto.svc」で開始する(「svc」は、そのタイプが、特性ではなくサービスに関するものであることを示すために、使用することができる)。
一部の実施形態では、タイプに加えて、又はその代わりに、一意の数値サービス識別子(図2G、図2Hには示さず)を、各サービスに割り当てることができる。例えば、IETF RFC 4122によって定義されるようなUUID(36の十六進数からなる識別子)を、各サービスに割り当てることができる。この統一的アクセサリプロトコルは、全てのサービスに関する共通の「ベース」UUID(例えば、最後の28の十六進数)を定義して(必要に応じて、全ての特性に割り当てられるベースUUIDと同じか、又は異なるものとすることができる)、各サービスに一意の「短い」UUID(例えば、最初の8つの十六進数)を割り当てることができ、任意の番号付けスキームを使用することができる。特に、「短い」UUIDに基づく、UUIDを短縮化する規則と組み合わされた、UUIDの使用により、コントローラ又はアクセサリは、文字列の使用と比較すると、より少量の送信データを使用して、対象となるサービスを指定することが可能となり得る。
各サービス251〜258は、アクセサリが実行することが可能な機能を表し、必須特性(図2G、図2Hでの「必須特性」プロパティ)のセット、及び任意選択特性(図2G、図2Hでの「任意選択特性」プロパティ)のセットを参照することによって定義される。この実施例では、各サービスは、少なくとも1つの任意選択特性(名前)を有し、他の実施形態では、任意選択特性のセットは、少なくとも一部のサービスに関して、空にすることができる。
この実施例では、特性が、所定のコアサービスに関して「必須」であるとして定義されるのは、そのコアサービスを提供することを申告する、任意の対応アクセサリが、そのアクセサリを制御するために、その「必須」特性を認識及び使用すると予想される場合である。例えば、Light bulbサービス251は、必須特性「com.proto.ch.on」(図2Aの特性201)を含み、このことは、アクセサリが、「com.proto.svc.lightbulb」サービスを提供することを申告する場合には、そのアクセサリが、照明をオン(真)又はオフ(偽)にすることによって、特性「com.proto.ch.on」への書き込み要求に応答し、照明がオン(真)又はオフ(偽)のいずれであるかを示す、ブール値を返すことによって、特性「com.proto.ch.on」への読み取り要求に応答すると予想されることを意味する。一部の実施形態では、アクセサリは、認可済み(又は、ペアリング済み)コントローラからの要求にのみ応答することができ、認可は、以下で説明される。
この実施例では、特性が、所定のコアサービスに関して「任意選択的」であるとして定義されるのは、アクセサリが、そのサービスの中に、その特性を含めることが必要とされていないが、その特性を含むことができる場合である。例えば、Light bulbサービス251は、任意選択特性「com.proto.ch.brightness」(図2Aの特性203)を含む。オン又はオフの設定のみを有する電球アクセサリ(多くの従来の蛍光灯器具など)は、輝度制御を必要とせず、そのようなアクセサリは、「com.proto.ch.brightness」特性をサポートする必要はない。輝度制御を有する電球アクセサリ(例えば、調光可能なランプ)は、「com.proto.ch.brightness」特性を含むことにより、コントローラは、その調光器を動作させることが可能となり得る。同様に、色相及び彩度は、Light bulbサービス251に関する任意選択特性とすることができる。
必須特性及び任意選択特性の組み合わせを指定して、他のサービス252〜258を同様に定義することができる。それらの特性は、タイプ別に図2G、図2Hで特定され、上述の図2A〜図2Dで示されるように定義することができる。特性は、1つのコアサービスでは必須であり、別のコアサービスでは任意選択的であり得る点に留意されたい。例えば、ロックメカニズム現在の状態、及び目標状態は、Garage Door Openerサービス253に関しては任意選択特性であるが、Lock Mechanismサービス254に関しては必須である。
図2G、図2Hでのコアサービスの実施例は、例示の目的のために提供されていることを理解されたい。任意数のコアサービスを定義することができ、所定のコアサービスに関連付けられる、具体的な必須特性及び/又は任意選択特性は、必要に応じて変化させることができる。更には、拡張特性がサポートされる実施形態では、製造元は、拡張特性を追加することによって、コアサービスを増大させることを許容される場合がある。更には、又はその代わりに、一部の実施形態では、製造元は、コア特性及び/又は拡張特性の任意の組み合わせを使用して、拡張サービスを定義することができる。
このプロトコルによって指定されるコアサービスとすることが可能な、「Accessory Information」サービスを使用して、そのアクセサリ自体を説明することができる。一部の実施形態では、このプロトコルは、全てのプロトコル対応アクセサリが、それらのアクセサリ定義レコード内に、アクセサリ情報サービスのインスタンスを含むように、指定することができる。図2Iは、本発明の実施形態による、(図2G、図2Hと同じフォーマットでの)Accessory Informationサービス261に関する定義を示し、図2Jは、(図2A〜図2Dと同じフォーマットでの)Accessory Informationサービス261に関する追加的特性271〜276の定義を示す。
Identity特性271は、アクセサリの自己識別ルーチンを呼び出すために、コントローラによって書き込むことができる。この自己識別ルーチンは、ユーザが観察可能なアクションを、アクセサリが開始することを含み得る。例えば、アクセサリは、光を点滅させるか、音を発するか、振動するか、可動構成要素を移動させる(例えば、ドアを開閉させる)か、特定のメッセージ(例えば、「ここにいます」)を表示するか、又は、ユーザが観察することが可能な何らかの他の物理的アクションを実行することができる。アクセサリの自己識別ルーチンを、コントローラから呼び出すことは、例えば、そのコントローラが、ユーザが制御することを望むアクセサリと通信していることを確認する点に関連して、有用であり得る。一部の実施形態では、コントローラは、Identity特性271に「true」を書き込むことによって、アクセサリの自己識別ルーチンを呼び出すことができる。
Manufacturer Name特性272、Model Name特性273、及びSerial Number特性274は、アクセサリについての識別情報を取得するために、コントローラによって読み取ることができる。一部の実施形態では、これらの値は、人間に読み取り可能な文字列とすることができる。
Firmware Revision特性275、Hardware Revision特性276、及び/又はSoftware Revision特性277は、アクセサリについての世代情報を取得するために、コントローラによって読み取ることができ、この情報は、そのアクセサリと対話する方法を決定するために、コントローラによって使用することができる。一部の実施形態では、改訂情報は、標準フォーマット、例えば、<x>.<y>.<z>;<w>で表すことができ、<x>は、メジャーバージョン番号であり、<y>はマイナーバージョン番号であり、<z>は改訂バージョン番号であり、<w>は追加的情報を含み得る。
前述の特性及びサービスの実施例は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。統一的アクセサリプロトコルは、任意数及び任意の組み合わせの、コア特性並びにコアサービスを定義することができ、示されたものとは異なる特性のセットを使用して、所定のサービスを定義することができる。上述のように、拡張特性及び/又は拡張サービス(例えば、アクセサリ製造元によって定義されるようなもの)を使用して、コアサービスを増大させることにより、統一的な通信及び制御フレームワークの範囲内で、様々な必要性に対する、かなりの程度の柔軟性及び適応性を提供することができる。
一部の実施形態では、異なるバージョンのコアサービス定義が共存し得る。異なる世代の製品間での適合性を促進するために、後のバージョンのコアサービス定義は、新たな任意選択特性の追加に限定することができ、必須特性の一貫したセットを維持することにより、相互運用性を促進することができる。
上述のように、一部の実施形態では、アクセサリ製造元は、拡張特性をサービスに追加することができる。例えば、アクセサリが、ストロボの選択肢を有する照明である場合には、製造元は、ストロボ特性(例えば、図2FのStrobe特性242)を、コアLight bulbサービス251に追加することができる。製造元はまた、拡張サービスを定義することもできる。例えば、上述のディスコボールの場合には、製造元は、ミラーボール及び照明を制御するために、拡張サービス「com.discoball.svc.discoball」を定義することができる。このサービスは、以下の特性を含み得る。
● com.proto.ch.on(図2Aの特性201)、
● com.proto.ch.brightness(図2Aの特性203)、
● com.proto.ch.hue(図2Aの特性204)、
● com.discoball.ch.strobe−on(図2Fの特性242)、
● com.discoball.ch.rotate−direction(図2Fの特性243)、及び
● com.discoball.ch.rotate−speed(図2Fの特性244)。
特性を有するサービスの集合としてアクセサリを表す、アクセサリモデルを、アクセサリオブジェクトとして、コントローラに通信することができる。アクセサリオブジェクトは、JSON、又は、構造化データオブジェクトを(例えば、ネスト化されたキー−値のペアを使用して)表す他の表記法を使用して、通信することができる。図3A〜図3Cは、本発明の実施形態による、アクセサリオブジェクト300の実施例を示す。アクセサリオブジェクト300は、JSONを使用して表されるが、他の表現で置き換えることもできる。付属の照明を有するガレージドア開閉装置が、例示の目的のために使用されるが、アクセサリモデルは、いずれの特定のアクセサリにも限定されない。
アクセサリオブジェクト300は、サービスインスタンス310、320、330のアレイで表すことができ、各サービスインスタンスは、特性インスタンスのアレイとして表すことができる。それゆえ、サービスインスタンス310は、特性インスタンス311〜315を含み得るものであり、サービスインスタンス320は、特性インスタンス321〜325を含み得るものであり、サービスインスタンス330は、特性インスタンス331、332を含み得る。この実施例では、サービスインスタンス310は、図2IのAccessory Informationサービス261のインスタンスであり、サービスインスタンス320は、図2GのGarage Door Openerサービス253のインスタンスであり、サービスインスタンス330は、図2GのLight bulbサービス251のインスタンスである。(用語「サービス」及び「サービスインスタンス」は、用語「特性」及び「特性インスタンス」と同様に、本明細書では互換的に使用することができる。)
各サービスインスタンス310、320、330、及び各特性インスタンス311〜315、321〜325、331、332は、サービス又は特性のタイプを含むことにより、そのインスタンスのサービス又は特性を特定することができる。この実施例では、タイプ文字列が使用される。一部の実施形態では、UUID又は短縮化されたUUIDを使用することにより、サービス及び特性のタイプを、文字列ではなく、数値的に特定することが可能となり得る。このことにより、アクセサリオブジェクト300のサイズを低減することができる。各サービスインスタンス及び各特性インスタンスにはまた、インスタンス識別子も割り当てられる。この実施例では、アクセサリの各サービスインスタンス及び各特性インスタンスは、順次式に、又は任意の他の所望の方式で割り当てることが可能な、一意のインスタンス識別子を有する。このことにより、以下で説明されるように、アクセサリ内の任意のサービスインスタンス又は特性インスタンスには、そのインスタンス識別子を参照することによってアドレスすることが可能となる。一部の実施形態では、異なる一意性規則を実施することができる。例えば、各サービスインスタンスは、一意のサービスインスタンス識別子を有し得るものであり、各特性インスタンスは、サービスインスタンス内の特性インスタンスの間で一意の、特性インスタンス識別子を有し得る。このことにより、サービスインスタンスには、そのインスタンス識別子を参照することによってアドレスすることが可能となり、特性インスタンスには、その特性インスタンスが属するサービスインスタンスのインスタンス識別子と共に、そのインスタンス識別子を参照することによってアドレスすることが可能となり得る。他のスキームを使用することもできる。
図3Aでは、サービスインスタンス310は、図2IのAccessory Informationサービス261のインスタンスとすることができる。一部の実施形態では、このプロトコルは、各アクセサリが、アクセサリ情報サービスの単一のインスタンスを有し、そのアクセサリ情報サービスのインスタンスが、1のインスタンスIDを有するように、指定することができるが、必要に応じて、異なる規則を指定することもできる。特性インスタンス311〜315は、サービス261に関する必須特性のインスタンスとすることができる。図3Bでは、サービスインスタンス320は、図2GのGarage Door Openerサービス253のインスタンスとすることができる。特性インスタンス321〜323は、サービス253に関する必須特性のインスタンスとすることができる。この実施例では、サービスインスタンス320はまた、ガレージドア開閉装置のロックメカニズムを制御するための、任意選択特性インスタンス324、325も含む。図3Cでは、サービスインスタンス320は、図2GのLight bulbサービス251のインスタンスとすることができる。特性インスタンス331は、サービス251に関する必須特性のインスタンスとすることができ、特性インスタンス332は、任意選択的な輝度特性のインスタンスとすることができる。
アクセサリ情報サービス以外のサービスに関しては、同じサービスの複数のインスタンスが、アクセサリオブジェクト内に共存し得る。例えば、独立制御可能な複数の電球を動作させるアクセサリは、各電球に関して、Light bulbサービス251の異なるインスタンスを有することにより、各電球の状態を独立して制御することが可能となり得る。
アクセサリオブジェクト300はまた、読み取り許可を有する各特性インスタンスに関する、現在の値を提供することもできる。例えば、ガレージドアは現在、閉鎖されており(現在のドア状態特性インスタンス321は、「閉鎖」に対応付けされる、値2を有する)、照明はオフである(オン特性インスタンス331は、偽の値を有する)。識別特性インスタンス315は、この特性に対するアクセスが、書き込み専用であるため、ヌル値を有する。
各特性インスタンスに関する許可は、「perms」文字列のアレイとして示すことができる。この実施例では、そのアレイは、アクセサリが、この特性に関してイベント通知をサポートすることを示す、「Events」文字列を含み得る。例えば、以下で説明されるように、コントローラは、その許可が「Events」文字列を含む、任意の特性インスタンスに関して、イベント通知に加入することができる。イベント通知メカニズムの実施例が、以下で説明される。
図3Cは、コア特性を部分的に再定義するアクセサリの実施例を示す。輝度特性インスタンス332が、新たな最小値、最大値、及びステップ値を指定することによって、輝度増分の数を低減するように(コア特性203と比較して)再定義される。この再定義は、インスタンス332にのみ適用され、アクセサリオブジェクト300内で定義される、いずれの他のサービスインスタンスの輝度特性にも、又は、所定のコントローラが相互運用する、いずれの他のアクセサリの輝度特性にも、影響を及ぼすものではない。
図3A〜図3Cのアクセサリオブジェクトは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。アクセサリは、任意数及び任意の組み合わせのサービスインスタンスを含み得るものであり、アクセサリ内のサービスインスタンスは、任意数及び任意の組み合わせの特性インスタンスを含み得る。所定の特性インスタンスの、より多く又はより少ないプロパティを、アクセサリオブジェクト内で指定することができ、例えば、図2Eに示された様々なプロパティのうちのいずれか又は全てを、指定することができる。アクセサリが、複数のサービスインスタンスを含む場合、それらのサービスインスタンスのうちの1つ(例えば、アクセサリ情報サービスインスタンス以外の、そのアクセサリオブジェクト内で列挙される最初のサービスインスタンス)を、一次サービスとして指定することができる。
更には、図3A〜図3Cは、JSONを使用する実装を示すものであるが、いずれの特定の表記法又はシンタックスの使用も、必須とされるものではない。例えば、本開示を入手可能な当業者には、Bluetooth LE汎用属性プロファイル(GATT)を活用することによって、アクセサリのサービス及び特性を表すことにより、コントローラとBluetooth LEを使用するアクセサリとの間の通信を促進することができる点が理解されるであろう。例えば、サービス及び特性は、各サービス及び各特性が一意のUUIDを有するように、UUIDによって特定することができる。
更には、一部の実施形態では、コントローラは、単一のエンドポイント(アクセサリサーバとも称されるもの)と通信して、1つ以上のアクセサリと対話することができる。このことをサポートするために、アクセサリ定義レコードは、1つ以上のアクセサリオブジェクトを含み得るものであり、各アクセサリオブジェクトは、図3A〜図3Cに示される方式で表すことができる。各アクセサリオブジェクトには、アクセサリオブジェクトのアレイ内で一意である、アクセサリインスタンスIDを割り当てることができる。所定のアクセサリサーバは、1つ以上のアクセサリオブジェクトをサービス提供することができ、それらのアクセサリオブジェクトの全てが、そのアクセサリサーバに関する単一のアクセサリ定義レコード内に表される。コントローラは、任意数のアクセサリサーバと通信することができる。一部の実施形態では、複数のアクセサリを制御する(又は、別のアクセサリにメッセージを中継する)単一のエンドポイントは、「ブリッジ」と称される場合があり、そのようなアクセスポイントに関するアクセサリ定義レコードは、そのブリッジに関するアクセサリオブジェクト、並びに、そのブリッジによって制御される各アクセサリに関するアクセサリオブジェクトを含み得る。このブリッジに関するアクセサリオブジェクトは、アクセサリ情報サービスの単一のインスタンスのみを含み得るものであり、そのブリッジに関するアクセサリオブジェクトの存在により、コントローラに、ブリッジが存在することを示すことができる。
動作中、各アクセサリ(又は、アクセサリサーバ)は、そのアクセサリ定義レコードを、永続的記憶装置内に記憶することができる。アクセサリは、そのアクセサリ定義レコードの全て又は一部を、要求に応じて、コントローラに提供することができる。以下で説明されるように、このことは、デバイス発見プロセスの一部として、又は他の時点で(例えば、ペアリング済みコントローラからの要求に応じて)実施することができる。一部の実施形態では、コントローラは、アクセサリ定義レコードからの情報を使用して、そのアクセサリとペアリングするか又は他の方式で接続するか否かを、判定することができる。ペアリング又は接続が確立される場合には、コントローラは、そのアクセサリ定義レコードを使用して、アクセサリを制御する方法を決定することができる。
アクセサリ定義レコードは、自己完結型とすることができ、これは、コントローラが、そのアクセサリと対話するために、そのアクセサリについての、いずれの他の情報も必要としないことを意味する。例えば、アクセサリ定義レコードは、製造元固有の特性(例えば、「com.discoball.ch.rotate−direction」)、及び/又は製造元固有のサービス(例えば、「com.discoball.svc.discoball」)の完全な定義を含み得るものであり、この定義は、それらの特性及びサービスの、人間に読み取り可能な記述子を含み得る。コントローラは、様々な特性に関する、人間に読み取り可能な記述子、及びユーザが操作可能な制御要素(例えば、特性の「単位」プロパティに基づいて、選択されるもの)を提示する、ユーザインタフェースを生成するようにプログラムすることができ、ユーザは必要に応じて、アクセサリを制御するために、その制御要素を操作することができる。コントローラは、ユーザ入力(例えば、特性に新たな値を書き込むこと)に基づいて、制御メッセージ(要求)を送信することができ、それゆえ、コントローラは、アクセサリ固有のソフトウェア、又は他のアクセサリ固有のカスタム設定を必要とすることなく、そのアクセサリの制御が可能となる。
例示的なアクセサリ発見プロセス
アクセサリを制御する前に、コントローラは、最初に、制御することになるアクセサリとの通信を確立する。「アクセサリ発見」とは、本明細書で使用するとき、全般的に、コントローラが、通信することになるアクセサリの位置を特定することができる、任意のプロセスを指す。一部の場合での発見は、コントローラとアクセサリとの間の通信が実施するべき、ユーザ検証を含み得る。一部の実施形態では、アクセサリ発見は、UpnPフォーラム(http://www.upnp.org)によって開発されたプロトコルの、Simple Service Discovery Protocol(SSDP)、又はApple Inc.によって開発されたBonjour(登録商標)ネットワーキング技術(IETF RFC 6762及びIETF RFC 6763として公開され、本明細書では「Bonjour」と称されるもの)などの、無線若しくは他のネットワーク上のデバイス及び/又はサービスの位置特定を容易にする、既存のサービス発見プロトコルを活用することができる。デバイス発見サービスでは、一方のデバイス(例えば、アクセサリ)は、その存在、アドレスを示す情報、及び任意選択的に、その能力についての追加的情報を、広告することができる。他方のデバイス(例えば、コントローラ)は、それらの広告を閲覧し、その一斉配信された情報に基づいて、対象となるデバイスを特定することができる。アドレスを使用して、閲覧しているデバイスは、広告主との通信を開始することができる。
ネットワーク及び発見サービスに応じて、広告は、リアルタイムの(例えば、マルチキャスト信号又はビーコン信号を通じた)情報の一斉配信、及び/又は、他のデバイスが情報を取得することが可能な、中央の(例えば、ネットワークアクセスポイントの)レポジトリに広告情報を提供することを含み得るが、これは必須ではない。広告の閲覧は、一斉配信された広告を検出すること、及び/又は、中央のレポジトリから広告情報を取得することを含み得る。
図4は、本発明の実施形態による、コントローラ404によってアクセサリ402を発見するプロセス400のフローチャートである。アクセサリ402は、例えば、図1でのアクセサリのうちのいずれかとすることができ、コントローラ404は、例えば、図1のコントローラ102とすることができる。
ブロック410で、アクセサリ402は、そのアクセサリ402が現在ペアリングされていない(又は、ペアリングするコントローラを探している)ことを示すように、状態ビットを設定することができる。これは例えば、以下で説明される状態フラグ標識内のビット「sf#」とすることができる。
ブロック412で、アクセサリ402は、デバイス発見サービス上で、統一的アクセサリプロトコル(「UAP」)をサポートするアクセサリとして、その存在を広告することができる。例えば、Bonjourを使用して、アクセサリは、それ自体を、名前及びサービスタイプで広告することができる。この名前は、そのアクセサリに関する、ユーザに読み取り可能な名前(例えば、「サーモスタット」)とすることができ、一部の場合には、広告される名前は、アクセサリ定義レコードのアクセサリ情報サービスインスタンス内で指定される名前とすることができる。サービスタイプは、統一的アクセサリプロトコルに関して定義することができる(例えば、サービスタイプ「_uap._tcp」)。この広告はまた、追加的情報も含み得る。例えば、アクセサリは、表3に示されるキーを有する、Bonjour TXTを提供することができる。
当業者には、他のサービス発見プロトコル及び技術を使用して、同様の情報を配信することができる点が理解されるであろう。例えば、SSDPを使用して、アクセサリは、マルチキャストHTTP NOTIFYメッセージを使用する、名前及びサービスタイプのURIを広告することができ、このURIは、アクセサリに対するユニキャスト要求を介して追加的情報を取得するために、コントローラによって使用することができる。
ブロック414で、コントローラ404は、未構成のアクセサリに関して閲覧することができる。特定のタイミングが必要とされることはないが、一般的に、コントローラは、コントローラの閲覧時にアクセサリの広告が検出可能である場合にのみ、アクセサリを発見する。
ブロック416で、コントローラ404は、例えばブロック412からの広告を検出することによってアクセサリ402を見つけることができる。ブロック418で、コントローラ404は、その広告に基づいて、アクセサリ402が、相互運用に関する「対象のもの」又は潜在的な候補であるか否かを判定することができる。例えば、コントローラ404は、表2の発見状態フラグ「sf#」を確認することにより、そのアクセサリが、既にコントローラと構成又はペアリング済みであるか否かを判定することができる。別の例として、コントローラ404は、表2のプロトコルバージョン「pv」を確認することにより、そのアクセサリのプロトコルバージョンが、コントローラのものと適合可能であるか否かを判定することができる。更には、一部の場合には、コントローラは、アクセサリに関して、特定のコンテキストで閲覧している(例えば、特定のアプリケーションを実行している)場合があり、広告される名前、一次サービス識別子、アクセサリモデル名、特徴フラグ、又は、アクセサリの広告から入手可能な任意の他の情報に基づいて、対象となるアクセサリを限定することができる。コントローラ404が、そのアクセサリが対象のものではないと判定する場合には、コントローラ404は、ブロック414に戻り、閲覧を継続する。(一部の実施形態では、この閲覧動作は、対象となるアクセサリが見つからない場合には、タイムアウトすることができる。)
ブロック422で、コントローラ404は、そのアクセサリについての情報をユーザに提示することができ、ブロック424で、ユーザは、そのアクセサリとのペアリングをコントローラが確立するべきか否かを指示する入力を提供することができる。例えば、コントローラ404は、そのアクセサリの広告から取得された情報のうちのいずれか又は全てを、ユーザに提示して、コントローラ404をアクセサリ402に接続するべきか否かを指示するように、ユーザに促すことができる。必須ではないが、ユーザ確認を要求することは、コントローラとアクセサリとの間の虚偽又は不要なペアリングを回避するために役立ち得る。
ブロック426で、コントローラ404は、ブロック424で受信したユーザ入力を解釈して、アクセサリ402とペアリングするべきか否かを判定することができる。ペアリングするべきではない場合には、コントローラ404は、ブロック414に戻り、他のアクセサリを探すことができる。コントローラ404及びアクセサリ402が、ペアリングするべきである場合には、ブロック428及びブロック430で、コントローラ404及びアクセサリ402はペア設定プロセスを実行することができる。一部の実施形態では、このペア設定プロセスを使用することにより、コントローラ404とアクセサリ402との間の安全な通信を容易にするための暗号キーを確立することができ、ブロック428及びブロック430で実施することが可能なペア設定プロセスの実施例が以下で説明される。一部の実施形態では、ユーザ確認を、このペア設定プロセスに組み込むことができ、ペア設定を開始する前の別個のユーザ確認は必要とされない。
ペア設定プロセスの完了が成功したものと想定すると、ブロック431で、アクセサリ402は、例えば上述の状態フラグ標識「sf#」を更新することによって、現時点でそのアクセサリと通信するために認可が必要とされていること、及び/又は、現時点で、そのアクセサリが少なくとも1つのコントローラとペアリングされていることを示すように、その状態を更新することができる。
ブロック432で、コントローラ404は、アクセサリ402からのアクセサリ定義レコードを取得してキャッシュすることができ、アクセサリ402は、ブロック434で、そのレコードを要求に応じて提供することができる。コントローラ404が、アクセサリ定義レコードをキャッシュする場合、その情報は、アクセサリ402内の状態変化の検出を容易にするために使用することができる。一部の実施形態では、コントローラ404はまた、アクセサリの広告からの情報(例えば、上記の表2からの情報のうちのいずれか又は全て)もキャッシュすることができ、この情報もまた、例えば、以下で説明されるような状態カウンタ「s#」を使用して、そのアクセサリ内の状態変化を検出するために使用することができる。
ブロック436及びブロック438で、コントローラ402及びアクセサリ404は、コマンド及び制御メッセージの交換を開始することにより、コントローラ404は、アクセサリ404を制御することが可能となり得る。一部の実施形態では、これらのメッセージは、ペア設定プロセスで、又は、以下で説明されるような後続のペア検証プロセスで確立されたキーを使用して、暗号化することができる。
本明細書で説明される発見プロセスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。更には、Bonjourサービスが、デバイス発見サービスの実施例として使用されているが、同様の概念は、他のデバイス発見サービスのコンテキストで適用することもできる。
一部の実施形態では、特定のアクセサリとペアリングするか否かを判定する前に、コントローラ404は、アクセサリ402から、アクセサリ定義レコード(又は、その一部分)を要求することができる。例えば、コントローラ404は、アクセサリにメッセージ(例えば、HTTP GET要求)を送信して、そのアクセサリ定義レコードを要求することができる。このHTTP GET要求に関して使用されるURLは、統一的アクセサリプロトコルの規則によって、又はアクセサリの広告内で(例えば、TXTレコード内で)指定することができる。構成に応じて、アクセサリ402は、ペアリングされていないコントローラからの要求に応答して、そのアクセサリ定義レコードの全て、一部を提供することができ、又は全く提供しないことも可能である。一部の実施形態では、アクセサリ402は、部分的なアクセサリ定義レコードを提供することができる。例えば、上述のように、一部の特性は、それらの特性の読み取り及び/又は書き込みが、ペアリング済みコントローラによってのみ可能であることを指定する、プロパティを有し得るものであり、そのような特性についての情報を、ペアリングされていないコントローラに提供することは、望ましくない場合がある。したがって、アクセサリ402は、「パブリック」な特性、すなわち、ペアリングされていないコントローラが読み取り及び/又は書き込みを許可される特性を、特定することができ、ペアリングされていないコントローラに提供される、部分的なアクセサリ定義レコードは、少なくとも1つのパブリックな特性を有する、サービスインスタンスのみを含み得るものであり、パブリックな特性及び非パブリックな特性の双方を有するサービスインスタンスのうちの、パブリックな特性インスタンスのみを含み得る。一部の実施形態では、アクセサリ定義レコードは、ペアリングが確立される前には、全くアクセス不能であるように作成され、その場合には、ペアリングするか否かの決定は、アクセサリの広告、コントローラのコンテキスト、及び/又はユーザ入力に基づき得る。
一部の実施形態では、発見プロセス400又は同様のプロセスを使用して、状態変化を検出することができる。例えば、表2に示されるように、状態が変化する際に、状態番号「s#」をインクリメントすることができる。アクセサリは、例えば、更新されたTXTレコードを一斉配信することによって、状態変化を広告することができ、以前に(例えば、プロセス400のブロック432で)そのTXTレコードをキャッシュしている、ペアリング済みコントローラは、一斉配信された「s#」の値と、そのキャッシュされている値とを比較することによって、変化を検出することができる。
図4のプロセスは、コントローラ及びアクセサリが、TCP/IPを使用して通信する場合に、使用することができる。一部の実施形態では、統一的アクセサリプロトコルは、TCP/IPに加えて、又はその代わりに、Bluetooth LEなどの他のトランスポートをサポートすることができる。このことが当てはまる場合、アクセサリは、それらのサービスを、Bluetooth LEを使用して広告することができる。例えば、アクセサリは、1つ以上のBluetooth LE広告チャネル上で、広告することができる。この広告データは、例えば、アクセサリに関するローカル名、一意のアクセサリ識別子、アクセサリが発見可能であることを示すフラグ、サービス(以下で説明されるようなペアリングサービスを含めたもの)のうちの少なくとも一部に関するUUID、アクセサリ状態の標識(表2での現在の状態番号と同様のもの)、及び、アクセサリが、少なくとも1つのコントローラとペア設定を実行しているか否かの指標のうちの、いずれか又は全てを含み得る。この情報は、上述のプロセス400と同様の発見プロセスで使用することができる。
例示的な通信
コントローラが、アクセサリとのペアリングを確立した後、そのコントローラは、コマンド及び制御メッセージ(要求)を、そのアクセサリに送信することができる。これらの要求は、アクセサリの状態についての情報を取得するために、及び/又はアクセサリの状態の態様を変化させるために使用することができる。一部の実施形態では、コマンド及び制御メッセージは、アクセサリ定義レコード内で定義されるような、特定のサービス又は特性に関するパスを反映するURLにアドレス指定される、HTTP要求とすることができる。そのような実施形態では、アクセサリは、HTTPサーバ(リソースに関する要求を受信して応答する)としての役割を果たし得るものであり、その一方で、コントローラは、HTTPクライアント(サーバ/アクセサリに対する要求を生成して、応答を受信する)としての役割を果たし得る。一部のアクセサリは、例えば、種々のインタフェース又はドメイン上での通信を管理するために、複数のHTTPサーバを実装することができる点に留意されたい。一部の実施形態では、アクセサリ及びコントローラは、単一のTCP接続及び/又はHTTPパイプライン方式を通じて、複数のHTTP要求をサポートする(例えば、応答を受信する前に、複数のHTTP要求を送信する)ことができる。
例えば、図3A〜図3Cに示されるアクセサリオブジェクト300を仮定すると、コントローラは、リソースを表すために、図5AのURL500を構築することができ、この場合には、図3Bで定義されるドア開閉装置サービスインスタンス320のドア状態特性インスタンス321である。URL500は、プロトコル識別プレフィックス502(「http://」)、アクセサリに関するホスト名504(上述の図4の発見プロセスを通じて取得することが可能なもの)、及びローカルパス506を含む。ローカルパス506は、統一的アクセサリプロトコルを通じて公開されるサービスへの参照を示す、プロトコルキーワード508(「proto/」)、特定のサービスインスタンスを特定する、サービスインスタンス識別子510(「service/<サービスID>」)、及び、そのサービスインスタンス内の特性インスタンスを特定する、特性インスタンス識別子512(「characteristic/<特性ID>」)を含み得る。図5Aでは、<サービスID>及び<特性ID>は、アクセサリオブジェクト内で定義されたインスタンス識別子で置き換えられている。それゆえ、図3A〜図3Cを参照すると、7のインスタンスIDを有するサービスインスタンスは、ガレージドア開閉装置サービスインスタンス320であり、8のインスタンスIDを有する特性インスタンスは、現在の状態特性インスタンス321となる。それゆえ、URL500は、ガレージドア開閉装置の延在のドア状態を参照するものとして、理解することができる。同様の方式で、サービス及び特性に関するインスタンスIDを使用して、他のURLを、アクセサリ定義レコードから生成することができる。任意のサービスインスタンスの任意の特性インスタンスを、この方式で特定することができる。
コントローラは、この方式で構築されたURLに対するHTTP GET(PUT)要求を生成することにより、特性を読み取る(書き込む)ことができる更には、URL500の階層構造を利用することにより、コントローラは、単一のトランザクションで、複数の特性又は複数のサービスに対する、読み取り若しくは書き込みが可能となり得る。例えば、特定のサービスの全ての特性を読み取るように、GET要求を送信することは、特性識別子を省略することによって達成することができる。応答は、図3A〜図3Cと同様のフォーマットで特性を含む、JSONオブジェクトとすることができる。
アクセサリリソースの現在の状態を判定するために、コントローラは、図5AのURL500に基づくHTTP GET要求を送信することができる。図5Bは、図5AのURL500から構築された、GET要求520の実施例を示す。GET要求520は、URL500のホスト504にアドレス指定され、ローカルパス526(URL500のローカルパス506と同様のもの)を、取得するリソースとして指定する。この実施例では、ローカルパス526は、単一の特性を指定するものではなく、指定されたサービスインスタンスの全ての特性を読み取る要求として、解釈することができる。
HTTP GET要求520に応答して、アクセサリは、要求されたリソース(状態情報)を提供する、HTTP応答を送信することができる。図5Cは、図5Bの要求に応答して提供することが可能な、例示的なHTTP応答530の一部分を示す。この応答は、その応答及び状態(「200 OK」)を特定し、コンテンツ534が、統一的アクセサリプロトコルによって定義されるようなJSONオブジェクトとしてフォーマットされていることを示す、HTTP応答ヘッダ532を含む。コンテンツ534は、要求されたリソースに関する状態情報を含み、この実施例では、図3Bのドア開閉装置サービスインスタンス320である。サービスインスタンス320は、5つの特性インスタンスを含み、この要求は、全ての特性を読み取ることであるため、5つ全ての特性の現在の状態が報告される。(図5Cでは、2つの特性のみが示されているが、同様の方式で残部が存在し得ることが理解されるであろう。)所望のレベルの粒度を反映するように、パス526を修正することによって、他のレベルの粒度(例えば、単一の特性インスタンス、又は全てのサービスインスタンス)の読み取り要求及び応答を構築することができる。
同様に、コントローラは、適切なURLにHTTP PUT要求を送信することによって、アクセサリに関する状態情報を変更することができる。図5Dは、図5AのURL500から構築された、PUT要求540の実施例を示す。PUT要求540は、URL500のホスト504にアドレス指定され、ローカルパス546(URL500のローカルパス506と同様のもの)を、コンテンツ542が書き込まれるリソースとして指定する。この実施例では、PUT要求540は、1つの特性インスタンスに書き込むものであるため、パス546は、その所望の特性インスタンス(図3Bの、ドア開閉装置目標ドア状態特性インスタンス322に相当するもの)のインスタンスIDを含む。コンテンツ542は、書き込む値を指定する。図3Bの実施例では、特性インスタンス322は、タイプ「com.proto.ch.door−state.target」のものであり、上述のように、この特性タイプに関する値1は、「開放」状態に対応付けすることができる。したがって、PUT要求540は、ガレージドアを開放する命令として、アクセサリによって解釈することができる。
アクセサリは、空のHTTP「204 No Content(コンテンツなし)」応答で応答することができ、例えばドアを開放することによって、状態の更新を実施することができる。(ドアが能動的に開放している間、アクセサリは、現在のドア状態特性インスタンス321を、ドアが開放中であることを示す値に更新し、次いで、ドアが完全に開放されると、「開放」を示す値に更新することができる。)一部の実施形態では、アクセサリ応答は、例えば図5Fを参照して以下で説明されるような、コンテンツを含み得る。例えば、エラーが発生した場合には、アクセサリは、HTTPエラー応答で応答することができる。例えば、HTTPエラーコード400は、不正な要求(例えば、シンタックスエラー又は無効な特性)を示し得るものであり、エラーコード403は、禁止アクション(例えば、コントローラが書き込み許可を有さないリソースへの、書き込みの試み)を示し得るものであり、エラーコード500は、アクセサリでの内部エラーを示し得る。一部の場合には、エラー応答のコンテンツは、そのエラーについての情報を有する、「response(応答)」オブジェクトを含み得る。応答オブジェクトの実施例は、以下で説明される。
一部の実施形態では、単一のPUT要求を使用して、複数の特性を書き込むことができる。図5Eは、図5AのURL500から構築された、PUT要求550の実施例を示す。PUT要求550は、PUT要求540と同様のものとすることができるが、ただし、ローカルパス556は、複数の特性に書き込むことを可能にする、サービスレベルの粒度である。図3のアクセサリ定義300、及び図2Aでの特性定義を参照すると、PUT要求550は、ガレージドアをロック解除して開放する要求として、解釈することができる。この実施例が示すように、PUT要求を使用して、サービスの特性のサブセットに書き込むことが可能である。この要求は、書き込まれる特性のみを含み得るものであり、各特性データオブジェクト内の、タイプ及びインスタンスIDのキーの存在により、曖昧性を防ぐことができる。更には、書き込まれる特性は任意の順序で列挙することができる。
アクセサリは、各特性の現在の状態を含むメッセージで、応答することができる。図5Fは、本発明の実施形態による、例示的な応答560を示す。応答560は、空ではないHTTP応答であり、そのコンテンツ562は、更新された各特性563、564の現在の値を含む。各特性に関して、「response」オブジェクト565、566が含まれる。図示のように、この応答オブジェクトは、「developerMessage(開発者メッセージ)」を含み得る。エラーが発生した場合には、この開発者メッセージは、そのエラーの平易な文言での説明を提供することができ、任意選択的に、その問題を修正するための提案を提供することができる。「errorCode(エラーコード)」は、(例えば、応答して行うべきコントローラのアクションを選択するために使用可能な)数値コードとすることができる。「moreInfo(更なる情報)」文字列は、エラーについて役立てるために参照するべき、プロトコル仕様又は他の文書のセクションを特定することなどの、追加的情報を提供することができる。図5Fに示す実施例では、エラーは発生しておらず、各特性の状態は、図5Eで要求された状態である。エラーが発生した場合には、その状態は、要求された状態に合致し得ない。
同様の方式で、図5Eの要求550と同様のPUT要求を使用して、1つのサービス、又は複数のサービスに書き込むことができ、図5Fの要求506と同様の応答を生成することができる。
上述のように、コントローラは、PUT要求を送信することによって、アクセサリ内の状態変化を要求することができる。一部の場合には、この状態変化は、完了するためにある程度の時間を必要とし得る、アクセサリ機能(例えば、コマンド又は動作の実行)を呼び出すことを伴い得る。応答する際のアクセサリの柔軟性を可能にするために、一部の実施形態は、一部の特性又はサービスに関する、遅延応答挙動をサポートする。
コントローラが、HTTP PUTを使用して特性に書き込む場合、アクセサリは、その要求を評価して、応答選択肢を(例えば、その書き込まれた具体的な特性に基づいて)選択することができる。一部の実施形態では、2つの応答選択肢、「インライン結果」及び「問い合わせ結果」が提供される。インライン結果に関しては、アクセサリは、要求された動作を実行して、次いで、その結果を(例えば、図5E及び図5Fを参照して上述されたような)HTTP応答で返す。この応答は、その動作を完了するために必要である限り、遅延させることができる。問い合わせ結果に関しては、アクセサリは、動作を実行する前にHTTP応答を返す。この場合には、この動作前HTTP応答は、コントローラが後に、HTTP GET要求を送信して結果を得るために使用することが可能な、(アクセサリによって割り当てられた)「トランザクションID」を含み得る。この動作前HTTP応答はまた、GET要求を送信する前にコントローラが待機するべき最小時間を示す、(同じくアクセサリによって割り当てられた)「トランザクション持続時間」も含み得る。アクセサリは、1回の要求ごとに、応答選択肢を選択することができる。
例示として、構成ポートを開く機能性を実施する、アクセサリを考察する。このポートは、様々な特性を有するサービスとしてモデル化することができる。図5Gは、コントローラが、ポートを開くことを要求するために真のブール値を書き込むことが可能な、特性インスタンス571を示す。図5Hは、本発明の実施形態による、ポートを開くことを要求するためにコントローラによって使用することが可能な、PUT要求572を示す。(特性インスタンス571は、インスタンスID22を有するサービスインスタンス内で定義されていることを理解されたい。)アクセサリは、例えば、コントローラ許可若しくはアクセサリの現在の状態に応じて、要求を満たすか又は拒絶することができる。アクセサリは、最初に要求に対して作動してから応答する(インライン結果)か、又は応答してから作動する(問い合わせ結果)かを選択することができる。
アクセサリが、最初に要求に対して作動することを選択する場合には、そのアクセサリは、結果を示すインライン応答を送信することができる。例えば、要求を満たすことは、ソケットを作り出して、ポートのリッスンを開始することを含み得る。アクセサリは、構成されたポートについての情報を、そのHTTP応答で伝えることができる。図5Iは、図5Hの要求572に対する、インラインHTTP応答573の実施例を示す。コンテンツ574は、ポート識別子、及び要求に関する状態標識を含み得る。
アクセサリが、最初に応答することを選択する場合には、そのアクセサリは、コントローラが後に結果に関して問い合わせるために使用することが可能な情報を含む、トランザクション応答を送信することができる。図5Jは、本発明の実施形態による、トランザクション応答575の実施例を示す。トランザクション応答575は、そのトランザクションを特定するためにアクセサリによって生成された、UUID又は他の識別子とすることが可能なトランザクションID576と、トランザクション持続時間577(例えば、秒の単位)とを含む。応答575は、コントローラが5秒待機してから、応答を取得するためにアクセサリに問い合わせるべきであることを示す。その時間の間に、アクセサリは、アクションを実行して、トランザクションIDと共に結果を記憶することができる。
トランザクション持続時間が経過した後、コントローラは、例えば、最初の要求と同じURLを使用して、HTTP GET要求を送信することによってアクセサリに問い合わせることができる。図5Kは、本発明の実施形態による、トランザクション状態の問い合わせのために使用することが可能な、HTTP GET要求578の実施例を示す。GET要求578は、トランザクション応答575からのトランザクションIDを含み得る。このトランザクションIDは、その問い合わせが、アクセサリが記憶することが可能であった、特定のトランザクションの結果に関するものであることを、そのアクセサリに示す。アクセサリは、そのトランザクションの結果を含むHTTP応答で、応答することができ、この応答は、図5Iのインライン応答573と、同様又は同一のものとすることができる。
リソースにアクセスする他の技術を実施することもできる。1つの代替的実装は、非階層的URLを使用して、アクセサリの各サービスインスタンス及び特性インスタンスの、一意のインスタンスIDを活用することができ、これによりHTTPメッセージの長さを低減することができる。
例えば、図6Aは、アクセサリの特性及びサービスへのアクセスを可能にするように構築することが可能な、簡略化されたURL600を示す。URL600は、プロトコル識別プレフィックス602(「http://」)、ホスト名604(上述の図4の発見プロセスを通じて提供することが可能なもの)、及び、この実施例では「/characteristics」である、ローカルURL606を含む。ローカルURL606は、アクセサリによってサポートされるURLのセットから、選択することができる。表4は、本発明の実施形態による、統一的アクセサリプロトコルが定義することが可能なURLを列挙する。
この実施例では、コントローラは、図6Aに示される方式で構築されたURLに、要求を送信することによってアクセサリ機能を呼び出すことができ、そのローカルURLは、呼び出される機能に基づいて、表4から選択される。/pair−setup、/pair−verify、及び/pairingsのURLは、コントローラとアクセサリとの間のペアリングの確立及び検証に関連して使用することができ、実施例が以下で説明される。ペアリング済みコントローラは、アクセサリの/accessoriesのURLに、GET要求を送信することにより、そのアクセサリ定義レコードを取得することができる。/accessoriesのURLは、アクセサリ特性の読み取り又は書き込みを伴う、全ての対話のために使用することができる。
/identifyのURLにより、ペアリングされていないコントローラは、例えば、そのアクセサリが、いずれかのコントローラとペアリングを確立する前に、そのアクセサリの自己識別ルーチンを呼び出すことが可能となり得る。アクセサリが、いずれのコントローラともペアリングされていない場合には、そのアクセサリは、HTTP204「No Content」応答で応答して、自己識別ルーチンを呼び出すように進行することができる。アクセサリが、コントローラとペアリングを確立している場合には、そのアクセサリは、(例えば、HTTP400「Bad Request(不正な要求)」応答で)要求を拒絶することにより、そのURLが有効ではないことを示すことができる。一部の実施形態では、ペアリング済みコントローラは、図2I及び図3Aに示されるようなアクセサリ識別サービス内に含めることが可能なIdentity特性271に書き込むことによって、そのアクセサリの自己識別ルーチンを呼び出すことができる。
図6Bは、図3A〜図3Cのアクセサリオブジェクト300によって定義されるアクセサリの特性を読み取るために、URL600を使用して送信することが可能なHTTP GET要求610の実施例を示す。GET要求610は、URL600のホスト604にアドレス指定され、ローカルURL606を指定する。文字列612は、読み取られる特性インスタンス(単数又は複数)を指定する、URLパラメータである。使用されるフォーマットは、<アクセサリIID>.<特性IID(単数又は複数)>であり、<アクセサリIID>は、アクセサリのインスタンス識別子であり、<特性IID(単数又は複数)>は、コンマで区切られた、読み取られる特性に関するインスタンス識別子のリストである。図3BのインスタンスIDを参照すると、GET要求610は、現在のドア状態及び目標のドア状態を読み取る要求として、理解することができる。様々な特性インスタンス識別子(例えば、URLパラメータ「?1.8−12」)などの、他のフォーマットを使用することもできる。この実施例では、アクセサリの各特性が、一意のインスタンス識別子に割り当てられるため、サービスインスタンス識別子を指定する必要はない。他の実施形態では、必要に応じて、サービスインスタンス識別子を含めることができる。
図6Cは、GET要求610に応答して送信することが可能な、HTTP応答620の実施例を示す。応答620は、その応答及び状態(「200 OK」)を特定し、コンテンツ624が、統一的アクセサリプロトコルに関するJSONオブジェクトとしてフォーマットされていることを示す、HTTP応答ヘッダ622を含み得る。コンテンツ624は、要求された各特性インスタンスに関する状態情報(値)を含み得る。この実施例では、各特性に関して送信されるデータは、その値及びインスタンスIDのみを含む。アクセサリの各特性インスタンスが、一意のインスタンスIDを有する限り、この情報は、要求に応答するために十分である。
この方式で、アクセサリの任意数の特性(異なるサービスインスタンスの特性を含めたもの)を、単一のGET要求及び応答を使用して読み取ることができる。更には、コントローラが、複数のアクセサリオブジェクトをサービスするアクセサリサーバと通信している場合には、そのコントローラは、そのサーバ上の複数のアクセサリの特性を読み取るために、例えば、それらの特性を、コンマで区切られた<アクセサリIID>.<特性IID(単数又は複数)>のリストとして指定することによって単一のGET要求を送信することができる。例えば、URLパラメータ(「?1.8.9,2.6,7」)は、インスタンスID1を有するアクセサリから、特性インスタンス8及び9を読み取り、インスタンスID2を有するアクセサリから、特性インスタンス6及び7を読み取る要求として、アクセサリサーバによって理解することができる。
特性は、そのアクセサリの/characteristicsのURLに対するHTTP PUT要求を使用して、書き込むことができる。図6Dは、アクセサリの任意数の特性に書き込むために使用することが可能な、PUT要求630の実施例を示す。書き込まれる各特性に関して、コンテンツ634は、アクセサリインスタンスID、特性インスタンスID、及び新たな値を指定することができる。この実施例では、2つの特性が書き込まれるが、このアレイは、同じアクセサリサーバ上の異なるアクセサリの特性を含めた、任意数(1つ以上)の特性を含み得る。
エラーが発生しない場合には、アクセサリは、空のHTTP「204 No Content」応答で応答することができ、適切なアクションを開始する(例えば、ドアを移動させるために、ガレージドア開閉装置内のモータを起動させる)ことによって状態の更新を実施することができる。エラーが発生した場合には、アクセサリは、エラーメッセージで応答することができる。図6Eは、PUT要求630に応答して送信することが可能な、エラーメッセージ640の実施例を示す。この実施例では、コンテンツ644は、書き込みが試みられた各特性インスタンスが特定されていることを(再度、アクセサリインスタンスID及び特性インスタンスIDを使用して)特定する。新たな値は示されていない。状態コード646、648は、いずれの書き込みが失敗したかを通信するために使用される。この実施例では、状態コード646(値0)は、インスタンスID8を有する特性に関しては、エラーが発生しなかったことを示す。状態コード648(値−12345)は、インスタンスID9を有する特性に関して、エラーが発生したことを示す。この状態コード648の値は、エラーのタイプを示し得る。例えば、状態コードは、不十分な権限(例えば、コントローラが、特性に書き込むことを認可されない)、リソースにアクセスすることができないこと(例えば、アクセサリの電源がオフである)、リソースがビジーであること、要求がサポートされていないこと(例えば、読み取り専用特性に対する書き込みの試み)、値が無効であること(例えば、最小値及び最大値を有する特性に対して、範囲外)、及び他のエラー条件を示すように、必要に応じて定義することができる。
図5A〜図5K、及び図6A〜図6Eの、これらのコマンド及び制御メッセージのフォーマット並びにシーケンスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。HTTPにより、任意のリソースを、任意の時点で要求することが可能となり、したがって、コントローラは、任意の順序でHTTP要求を送信することができ、アクセサリは、受信された順序で、HTTP要求に応答することができる。アクセサリは、標準HTTP応答(エラーメッセージを含むもの)で応答することができ、コントローラは、そのHTTP応答を、肯定応答(又は、エラーの場合には、否定応答)メッセージとして取り扱うことができる。一部の実施形態では、アクセサリのサービス及び特性の、HTTPリソースへの対応付けは、コントローラが情報を取得する方式における、実質的な柔軟性を可能にし得る。一部の実施形態では、より短いURLを有するインスタンス識別子の使用は、より短い要求及び応答をもたらし得るものであり、このことにより、帯域幅要件を低減することができる。
更には、これらの実施形態は、HTTPを使用するように示されているが、本発明は、いずれかの特定のフレーム化プロトコルに限定されるものではなく、他のプロトコルで置き換えることもできる。例えば、コントローラ及びアクセサリが、Bluetooth LEを使用して通信する実施形態では、コントローラは、Bluetooth LE GATT層、並びに、各サービス及び特性に割り当てられたUUIDを活用することによって、特性に対する読み取り及び書き込みを行うことができる。
上記の実施例では、コントローラは、例えばHTTP要求を使用して、アクセサリにコマンド及び制御メッセージ(要求)を送信することによって、アクセサリ内の状態変化を開始させることができる。他の場合には、アクセサリの状態変化は、コントローラ以外のソースによって開始させることができ、このことが実施される場合、コントローラは、そのアクセサリに接続されている場合もあれば、接続されていない場合もある。例えば、異なるコントローラが、異なる時点で、同じアクセサリと対話している場合があり、又は、ユーザが、アクセサリを手動で(例えば、ガレージドア開閉装置を作動させるために、ガレージ内の開/閉ボタンを押して)動作させる場合もある。それゆえ、アクセサリ状態は、コントローラが認識することなく、変化する場合がある。したがって、統一的アクセサリプロトコルの一部の実装は、コントローラに状態変化を通知するメカニズムを提供することができる。複数の通知メカニズムを同時にサポートすることができ、コントローラは、いずれのメカニズムが好ましいかを、例えば、特性ごとに、又はサービスごとに決定することができる。
通知メカニズムの実施例は、上記の表2内に列挙されている。一部の場合には、アクセサリは、アクセサリの状態が変化するたびにインクリメントさせることが可能な、内部状態カウンタを保持することができる。必要に応じて、単一の状態カウンタをアクセサリレベルで保持することができ、又は、異なるサービス又は特性に関して、異なる状態カウンタを保持することもできる。様々な実施形態は、以下で説明される通知メカニズムのうちのいずれか又は全てをサポートすることができる。
図7は、本発明の実施形態による、「受動的」通知プロセス700の実施例を示す。プロセス700は、コントローラが、状態変化が生じたか否かを判定するために、アクセサリの内部状態カウンタを読み取ることを伴う。したがって、コントローラがアクセサリから接続解除されている間に変化が生じたという事実は、その後にコントローラが再接続する際、そのコントローラによって検出することができる。一部の実施形態では、受動的通知が、デフォルトで有効化されており(例えば、あらゆるアクセサリが、内部状態カウンタを保持する)、その通知を有効化するために、特定のアクション(例えば、加入すること)は必要とされない。
ブロック706及び708で、コントローラ702及びアクセサリ704は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス400、及び/又は以下で説明される他のプロセス(例えば、ペア検証)を実行することを含み得る。
ブロック712で、アクセサリ704は、その現在の内部状態カウンタ値を、コントローラ702に提供することができ、コントローラ702は、ブロック714で、その値を取得して記憶することができる。一部の実施形態では、コントローラ702は、適切なリソース(例えば、アクセサリ情報サービス内で定義することが可能な、読み取り可能な状態カウンタ特性)に、HTTP GET要求を送信することができる。ブロック712でのアクセサリ704による応答は、そのカウンタ値を含み得る。コントローラ702は、この値を記憶することができる。以降のいずれかの時点で、コントローラ702は、アクセサリ704から接続解除することができる(ブロック716)。
ブロック718で、コントローラ702が接続解除された後に、アクセサリ704内で状態変化が生じ得る。それに応答してアクセサリ704は、ブロック720で、その状態カウンタを更新することができる。
その後、コントローラ702は、アクセサリ704に再接続することができる(ブロック722)。ブロック724で、アクセサリ704は、現在の内部状態カウンタ値をコントローラ702に提供することができ、コントローラ702は、ブロック726で、その値を取得することができる。一部の実施形態では、このことは、適切なリソースに向けられた、コントローラ702によるHTTP GET要求を通じて行うことができ、アクセサリ704による応答は、そのカウンタ値を含み得る。ブロック728で、コントローラ702は、例えば、ブロック726で取得したカウンタ値と、以前にブロック714で取得して記憶したカウンタ値とを比較することによって、状態変化を検出することができる。一部の実施形態では、コントローラ702は、記憶された古いカウンタ値を、新たなカウンタ値で上書きすることができる。その後、ブロック730で、アクセサリ704は、更新された状態情報を、コントローラ702に提供することができ、コントローラ702は、ブロック732で、その情報を取得する。一部の実施形態では、このことは、コントローラ702によるHTTP GET要求、及びアクセサリ704による応答を使用して行うことができ、コントローラは、アクセサリ定義レコードを要求するか、又は、その状態変化がコントローラにとって対象のものとなる、特定の特性のみを要求するかを、選択することができる。
図8は、本発明の実施形態による、「広告式」通知プロセス800の実施例を示す。プロセス800では、アクセサリは、(例えば、上述のような)デバイス発見サービスを使用して、状態変化が生じたことを広告することができる。この広告を検出するコントローラは、アクセサリに接続して、更新された状態情報を取得することができる。
ブロック806及び808で、コントローラ802及びアクセサリ804は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス400、及び/又は以下で説明されるペアリングプロセスを実行することを含み得る。ブロック810で、コントローラ802は、広告式通知への加入の要望を示すことができる。例えば、図2Eを参照して上述されたように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、その通知モードプロパティに書き込むことによって、通知モードを指定することができる。一部の実施形態では、アクセサリ804は、少なくとも1つのコントローラが広告式通知に加入していない限り、状態変化を広告せず、このことにより、ネットワークトラフィックを低減することができる。
ブロック812で、アクセサリ804は、現在の内部状態カウンタ値を、コントローラ802に提供することができ、コントローラ802は、ブロック814で、その値を取得して記憶することができる。一部の実施形態では、このことは、適切なリソースに向けられた、コントローラ802によるHTTP GET要求を通じて行うことができ、アクセサリ804による応答は、そのカウンタ値を含み得る。コントローラ802は、この値を記憶することができる。以降のいずれかの時点で、コントローラ802は、アクセサリ804から接続解除することができる(ブロック816)。
ブロック818で、コントローラ802が接続解除された後に、アクセサリ804内で状態変化が生じ得る。それに応答して、アクセサリ804は、ブロック820で、その内部状態カウンタを更新することができる。ブロック822で、アクセサリ804はまた、更新された状態カウンタも広告することができる。例えば、上記の表3に示されるように、アクセサリは、例えばBonjour TXTレコード内の、状態番号「s#」を含む情報などを広告することができる。アクセサリは、そのフィールドを更新して、新たなTXTレコードを一斉配信することによって、状態変化を広告することができる。
ブロック824で、コントローラ802が一斉配信をリッスンしていると想定すると、コントローラ802は、その変化を検出することができる。例えば、コントローラ802は、その一斉配信から、現在の状態カウンタを抽出して、その一斉配信された状態カウンタと、記憶されている状態カウンタとを比較し、そのアクセサリの状態が変化したことを示す不一致を検出することができる。ブロック826で、コントローラ802は、アクセサリ804に再接続することができ、ブロック828で、アクセサリ804は、更新された状態情報を、コントローラ802に提供することができ、コントローラ802は、ブロック830で、その情報を取得する。一部の実施形態では、このことは、コントローラ802によるHTTP GET要求、及びアクセサリ804による応答を通じて行うことができる。
図9は、本発明の実施形態による、「能動的」通知プロセス900の実施例を示す。プロセス900では、アクセサリは、状態情報が更新されると、コントローラに警告するために、コントローラへの接続を開始することができる。例えば、コントローラは、デバイス発見サービス(例えば、Bonjourサービス)に、状態更新の受信専用のサービスレコードを登録することができ、アクセサリは、そのコントローラのサービスレコードを使用して、コントローラへの接続を開始することができる。
ブロック906及び908で、コントローラ902及びアクセサリ904は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス400、及び/又は以下で説明されるペアリングプロセスを実行することを含み得る。ブロック910で、コントローラ902は、能動的通知への加入の要望を示すことができる。例えば、上述のように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、その通知モードプロパティに書き込むことによって、通知モードを指定することができる。一部の実施形態では、アクセサリ904は、少なくとも1つのコントローラが、能動的通知に加入している場合にのみ、能動的通知に関連する動作を実行し、このことにより、ネットワークトラフィックを低減することができる。
ブロック912で、コントローラ902は、能動的通知をリッスンするポートを設定することができる。ブロック914で、コントローラ902は、デバイス発見サービスに、サービスレコードを登録することができる。例えば、Bonjourサービスが使用される場合には、コントローラ902は、一意のDNS SRVレコードを登録することができる。SRVレコードが一意である場合には、そのコントローラは、TXTレコードの探索、広告、又は提供などの動作を回避することにより、ネットワークトラフィックを低減することができる。一実施形態では、DNS SRVレコードは、以下のフォーマットを有し得る。
<ID>._guid._tcp.local.<TTL>IN SRV<priority><weight><port><target>、
式中、<ID>は、コントローラに関する一意識別子(例えば、小文字でダッシュが除去されたGUID、UUID、又は他の識別子)であり、「._guid._tcp」は、DNSサービスタイプであり、「local」は、ドメイン名であり、<TTL>は、SRVレコードの生存時間であり(例えば、120秒とすることができる)、<priority>は、目標ホストの優先度であり(例えば、そのサービス内で認識される、最も高い優先度とすることができる)、<weight>は、同じ優先度を有するレコードに関する相対的重みであり(例えば、0とすることができる)、<port>は、コントローラ902上で動作している統一的アクセサリプロトコルサーバのTCPポート番号であり(例えば、ブロック912で設定されるポート)、<target>は、統一的アクセサリプロトコルサーバに接続するためのIPアドレスを取得するために使用することが可能な、DNS名である。
ブロック916で、コントローラ902を接続解除することができる。
ブロック918で、コントローラ902が接続解除された後に、アクセサリ904内で状態変化が生じ得る。それに応答して、ブロック920で、アクセサリ904は、例えば、サービスタイプ「._guid._tcp」に関するマルチキャストDNS SRV問い合わせを送信することによって、デバイス発見サービスに、登録されたサービスの位置を特定するように問い合わせることができる。(一部の実施形態では、アクセサリ904は、少なくとも1つのコントローラが能動的通知に加入している場合にのみ、ブロック920での問い合わせ、及び後続のアクションを実行する。)ブロック922で、コントローラ904は、ブロック912及び914で確立された、DNS名及びポート識別子で、その問い合わせに応答することができる。ブロック924で、アクセサリ904は、そのDNS名を解決するために、そのポートにユニキャスト問い合わせを送信することができる。一部の実施形態では、IPv4及びIPv6アドレス指定バージョンの双方をサポートするアクセサリは、IPv4及びIPv6アドレス指定の双方(例えば、IPv4に関するDNS A問い合わせ、及びIPv6に関するDNS AAAA問い合わせ)を使用して、問い合わせを送信することができ、アクセサリが、一方のIPアドレスバージョンのみをサポートする場合には、1つの問い合わせのみを送信することができる。
ブロック926で、コントローラ902は、その解決されたアドレスを有する、ユニキャスト応答を送信することができる。アクセサリが、2つの問い合わせを送信した場合には、コントローラは、いずれのIPアドレスバージョン(単数又は複数)をサポートしているかに応じて、いずれか一方又は双方に応答することができる。
ブロック928で、アクセサリ904は、解決されたアドレスを使用して、コントローラ902への新たな接続を開始することができる。一部の実施形態では、コントローラが、IPv4アドレス及びIPv6アドレスの双方を提供する場合には、IPv6を推奨することができる。ブロック930で、コントローラ902は、その接続を受理することができる。接続の試みが失敗した場合には、アクセサリは、再試行することができ、一部の実施形態では、再試行の頻度は、例えば60秒ごとに1回までに、制限することができる。
ブロック932で、アクセサリ904は、更新された状態情報を送信することができ、ブロック934で、コントローラ902は、その更新された状態情報を受信することができる。一部の実施形態では、更新された状態情報を送信する前に、以前に確立されたペアリングの検証(例えば、以下で説明されるペア検証プロセスを使用するもの)が必要とされる場合がある。この検証により、通知に加入した同じコントローラに、アクセサリが状態情報を報告しているという保証を提供することができる。
図10は、本発明の実施形態による、「イベント通知」プロセス1000の実施例を示す。プロセス1000では、アクセサリは、変化した特性に関するイベント通知を受信するように現在加入しているコントローラに、非請求のHTTP応答(本明細書では、EVENTメッセージとも称されるもの)を送信することができる。この実施例では、コントローラは、アクセサリに接続されている間の任意の時点で通知に加入することができ、そのアクセサリから接続解除すると自動的に未加入となる。
ブロック1006及び1008で、コントローラ1002及びアクセサリ1004は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス400、及び/又は以下で説明される他のペアリングプロセスを実行することを含み得る。ブロック1010で、コントローラ1002は、イベント通知への加入の要望を示すことができる。例えば、上述のように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、このプロパティに書き込むことによって通知モードを指定することができる。
図11Aは、特性に関するイベント通知に加入する、HTTP PUT要求1110の実施例を示す。コンテンツ1102は、特性を(アクセサリインスタンスID及び特性インスタンスIDによって)特定し、通知モードプロパティに関する値「ev」を含む。複数の特性を、単一の加入要求内に列挙することができ、一部の実施形態では、加入要求は、1つ以上の特性に値を書き込む要求と組み合わせることができる。アクセサリは、指定された特性に関するイベント通知に加入する要求として、要求1100を理解することができ、確認(例えば、HTTP204「No Content」)又はエラー応答(例えば、その特性に関してイベント通知がサポートされていない場合)で、応答することができる。所望の通知方法(単数又は複数)を指定することによって、他のタイプのイベント通知(例えば、上述のような能動的通知又は広告式通知)に加入するために、同様のメッセージをコントローラによって使用することができる。
加入した後、ブロック1014で、コントローラ1002は、イベントベースの通知から加入解除することができる。一部の実施形態では、コントローラ1002は、アクセサリ1004から接続解除する場合には、自動的に加入解除される。加えて、又はその代わりに、コントローラ1002は、アクセサリ1004から接続解除することなく、通知モードプロパティに新たな値を書き込むことによって、明示的に加入解除することができる。コントローラ1002が、(自動的又は明示的に)加入解除する場合には、いずれの後続のイベント通知も、もはやコントローラ1002に送信されることはなく、プロセス1000は、ブロック1016で終了することができる。(加入解除されたコントローラ1002は、当然ながら、再び加入するためにプロセス1000を実行することができる。)コントローラ1002を自動的又は明示的に加入解除することにより、アクセサリ1004は、対象としない(又は、接続されていない)コントローラへのイベントメッセージを、生成するか又は送信を試みることを回避することができるため、アクセサリ1004による電力消費を低減するために役立ち得る。
ブロック1018で、状態変化が、アクセサリ1004内で生じる場合があり、ブロック1020で、アクセサリ1004は、その内部状態カウンタを更新することができ、内部状態カウンタを更新することは、例えば上述のように、受動的通知及び/又は広告式通知に関連して有用であり得る。更には、コントローラ1002が、イベントベースの通知に加入している場合には、アクセサリ1004は、コントローラ1002に対する通知を生成することができる。
例えば、ブロック1024で、アクセサリ1004は、その影響を受けた特性に対する状態変化に関するイベントベースの通知に、いずれかのコントローラ(例えば、コントローラ1002)が現在加入しているか否かを判定することができる。
コントローラが現在加入していない場合には、更なるアクションは実施されず、プロセス1000は、ブロック1026で終了することができる。少なくとも1つのコントローラ(例えば、コントローラ1002)が、現在加入している場合には、ブロック1028で、アクセサリ1004は、更新された状態情報を含むイベントメッセージを生成することができる。
図11Bは、本発明の実施形態による、イベントメッセージ1120の実施例を示す。イベントメッセージ1120は、HTTP応答と同様の構造とすることができるが、しかしながら、HTTP応答とは異なり、イベントメッセージ1120は、特定のHTTP要求に応答して送信されるものではない。ヘッダ部分1122は、メッセージ1120をイベントメッセージとして特定することができ、バージョン情報及び状態コードを含み得る。ボディ1122は、変化した特性の、更新された値を含み得るものであり、本明細書での他の実施例と同様に、その特性は、アクセサリ識別子及びインスタンス識別子によって特定することができる。複数の特性が変化した場合には、そのアクセサリは、単一のイベントメッセージ1120内に、複数の特性を含めることができ、すなわち、イベントメッセージを結合させることができる点を理解されたい。他のフォーマットもまた、使用することができる。
再び図10を参照すると、ブロック1030で、アクセサリ1004は、コントローラ1002にイベントメッセージを送信することができ、ブロック1032で、コントローラ1002は、そのイベントメッセージを受信することができる。例えば、コントローラ1002内のHTTPスタックを修正することにより、イベントメッセージ1100を(例えば、ヘッダ1122に基づいて)認識することができる。コントローラ1002は、受信したイベントメッセージから、更新された状態情報を抽出することができる。
上述の様々な通知プロセスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。更には、同じアクセサリが、これらの通知プロセスのうちのいずれか又は全てを同時にサポートすることができ、同じ状態変化が、その状態変化の時点で、いずれの通知選択肢に様々なコントローラが加入しているかに応じて、内部状態カウンタの更新、更新された状態カウンタの広告、1つ以上の加入コントローラとの通信の開始、及び/又は加入コントローラへのイベントメッセージの送信のうちのいずれか又は全てを生じさせることができる。他の通知メカニズム及び通知プロセスを、図7〜図10に示されるものに加えて、又はそれらの代わりにサポートすることができる。
上述のように、コントローラは、例えば特性の通知モードプロパティに書き込むことによって、特性ごとに状態変化通知に加入することができる。アクセサリは、問題となる特性に関連して、いずれかのコントローラが各通知メカニズムに加入しているか否かに基づいて、いずれの通知メカニズム(単数又は複数)を実行するかを判定することができる。一部の実施形態では、受動的通知はデフォルトのメカニズムであり、内部状態カウンタは、いずれかのコントローラが具体的に何を要求しているかに関わりなく常に更新される。広告式通知、イベント通知、及び/又は能動的通知は、ネットワークトラフィックを作り出し得るため、これらのメカニズムの使用は、受動的通知に依存することが、ユーザエクスペリエンスに悪影響を及ぼすことになる場合に限定することができる。
一部の実施形態では、状態変化の告知(例えば、広告式通知、イベント通知、及び/又は能動的通知を介したもの)によって生成されるネットワークトラフィックを低減するために様々なポリシーを課すことができる。例えば状態変化の広告は、少なくとも1つのコントローラが広告式通知に加入している場合に限定することができ、接続を開始するためにサービスレコードに問い合わせすることは、少なくとも1つのコントローラが能動的通知に加入している場合に限定することができる。更には、全ての広告式通知、能動的通知、又はイベント通知を最短遅延期間(例えば、1秒)で結合するように、アクセサリに要求することにより、ネットワークトラフィックを更に低減することができる。別の実施例として、広告、イベント通知、及び/又はアクセサリ開始接続の頻度を制限することができる(例えば、30秒ごとに1回まで)。ネットワークトラフィックを最小限に抑える受動的通知を、デフォルトとして使用することができる。そのような制限は、設計選択の問題であり、必要に応じて変更又は除去することができる。制限が課され、アクセサリがその制限に違反する場合、違反を検出するコントローラは、その不正挙動をユーザに警告することができ、かつ/又は、そのアクセサリとのペアリングを終了することができる。
例示的なペアリングプロセス
一部の実施形態では、アクセサリとコントローラとの間の通信のセキュリティを確保することが、有用であり得る。例えば、図1を参照すると、コントローラ102を使用して、例えば、上述のように要求メッセージを送信することによって、ドア104をロック解除するか、又はガレージ106を開放することができる。当業者には、そのような動作は、特定の認可済みコントローラに限定されるべきであることが理解されるであろう。
したがって、本発明の一部の実施形態は、ペアリングの認証、及びエンドツーエンドの暗号化などの、セキュリティ対策を提供する。ペアリングの認証は、アクセサリとコントローラとの間でのペアリングの確立(ペア設定とも称されるもの)の一部として実施することができ、その間に、アクセサリ及びコントローラは、セキュリティフレームワークを(例えば、暗号化技術を使用して)確立することができ、そのフレームワーク内で、長期公開キーを交換することができる。一部の実施形態では、ペア設定は、情報(例えば、設定コード)の帯域外交換を組み込むことができ、この帯域外交換は、アクセサリに対して、特定のコントローラとペアリングするべきであることを検証するための、及び/又はコントローラに対して、特定のアクセサリとペアリングするべきであることを検証するための、ユーザ入力(又は、ユーザアクション)を組み込むことができる。この方式で、公開キーを交換した後、コントローラ及びアクセサリは、それらのキーを記憶して、その後、ペアリングが確立されたことを検証するために、それらのキーを使用することができる。エンドツーエンドの暗号化は、アクセサリ及びコントローラの双方内で、セッションキーを(例えば、ペアリングの検証後に)生成し、それらのセッションキーを使用して、各メッセージが送信デバイスから発せられる前に、そのメッセージを暗号化することを含み得ることにより、そのメッセージが傍受された場合にも、傍受者は、そのメッセージを利用することが不可能となる。それゆえ、リンク層又はトランスポート層で、通信ネットワークのセキュリティを確保することは必要とされない。例えば、アクセサリとコントローラとが、(例えば、以下で説明されるような、ペア検証プロセスを使用して)再接続するたびに、新たなセッションキーを生成することができる。更には、確立済みのペアリングを(例えば、記憶されている長期公開キーを除去することによって)する除去メカニズムを提供することができ、これにより、特定のアクセサリを制御することを一旦認可されたコントローラが無認可となる。
一部の実施形態では、暗号キー(以下で説明されるキーのうちのいずれか又は全てを含めたもの)は、デバイスに関するデータを安全に記憶することが可能な、専用の集積回路チップなどの、「セキュア要素」(「セキュア記憶要素」とも称される)内にのみ、排他的に記憶させることができる。このセキュア要素を使用することにより、受信された長期公開キー、及び/又は、ペアリング関係が確立されている他のデバイスを特定する他の情報の、永続的で安全な記憶を提供することができる。このことは、攻撃者が、適切な設定プロセスを経ずにペアリングを追加する(コントローラの不正使用をもたらす恐れがある)こと、又は、無認可でペアリングを除去する(コントローラの正当な使用を妨げる恐れがある)ことを、防止するために役立ち得る。更には、一部の実施形態では、このセキュア要素はまた、アクセサリ又はコントローラのメインプロセッサに対するコプロセッサ(又は、「セキュアコンピューティング要素」)としての役割を、そのセキュア要素が果たすことを可能にする、論理回路も含み得る。このセキュア要素は、様々な入力及び命令を受信して、それらの入力に対する暗号化動作を実行することができる。このセキュア要素は、それらの動作を実行し、出力を提供することができる。本明細書で説明される暗号化動作のうちのいずれか又は全て(例えば、キーの生成、秘密キーでの署名、及びキーを伴う他の動作)は、セキュアコンピューティング要素に委譲することができる。本明細書で使用するとき、「セキュア要素」は、安全な記憶及び/又は安全なコンピューティングの任意の組み合わせを提供することができる。
一部の実施形態では、ペアリングをサポートするアクセサリは、そのアクセサリモデルの一部として、ペアリングプロファイルを有し得る。本明細書で説明される他のサービスと同様に、このペアリングプロファイルは、特性の集合として定義することができる。一部の実施形態では、統一的アクセサリプロトコルは、全てのアクセサリがペアリングプロファイルを有するように、指定することができる。他の実施形態では、ペアリングプロファイルは、任意選択的な特徴とすることができるが、このプロトコルは、アクセサリがペアリングプロファイルを有する場合には、コントローラが、いずれかのコマンド及び制御メッセージを交換する前に、そのアクセサリとペアリングすることが必要となり得るように、指定することができる。更には、ペアリング要件の調整もまた可能である。例えば、アクセサリのペアリングプロファイルは、ペアリングを必要とする具体的なサービスインスタンスを特定することにより、そのアクセサリのサービスのうちの一部へのアクセスを、ペアリングなしで可能にすることができる。
図12は、本発明の実施形態による、ペアリングプロファイルに関する例示的特性1201〜1205を示す。このフォーマットは、全般的には図2Aと同様である。本明細書で説明される他の特性と同様に、特性1201〜1205は、例えばHTTP GET要求などを使用して、コントローラによって読み取ることができ、例えばHTTP PUT要求又はHTTP POST要求などを使用して、書き込みを(許可される場合に)実行することができる。
Pairing State Request特性1201は、ペアリングプロセスの状態の変化を要求するために(例えば、以下で説明される、ペア設定、ペア検証、ペア追加、及び/又はペア除去プロセスの間に、様々な要求を送信するために)、コントローラによって書き込むことができる。一部の実施形態では、コントローラは、特性1201に書き込むことではなく、(例えば、上記の表4に示されるような)ペアリングURLにHTTP POST要求を送信することによって、ペアリングプロセスの状態の変化を要求することができる。ペアリングプロセスの状態及び要求の実施例は、具体的なペアリングプロセスに関連して以下で説明される。
Feature Flags特性1202は、アクセサリによってサポートされるペアリング特徴を定義する、ビットマスクとすることができる。例えば、以下で説明されるように、様々なアクセサリは、設定コードベースのペアリング(ペアリングを実施するべきであることを確認するために、PINなどの設定コードを、ユーザが入力することを必要とし得るもの)、証明書ベースのペアリング(以下で説明されるような、一方又は双方のデバイス内の認証チップを使用して提供することが可能な証明書インフラストラクチャを使用し得るもの)、及び/又は委譲ペアリング(別のコントローラをペアリングするべきであることを、既にペアリングされているコントローラが検証することを可能にし得るもの)をサポートすることができる。一部の実施形態では、Feature Flags特性1202はまた、アクセサリが現在、ペア設定を使用して新たなペアリングを確立することが可能なモードにあるか否かを示すビットも含み得る。特性1202は、コントローラによって読み取ることができるが、書き込むことはできず、コントローラは、ペア設定をどのように実行するか、及びペア設定を実行するべきか否かを判定する際に、その情報を使用することができる。
Pairing Current State特性1203は、ペアリングプロセスの現在の状態、例えば、エラーが発生しているか否か、又は以下で説明される様々な他の状態を示すことができる。この特性は、コントローラによって読み取ることができるが、書き込むことはできない。
Pairing List特性1204は、そのアクセサリと確立された全てのペアリングのリストを、記憶することができる。例えば、公開キー(設定コードベースのペアリング用)、及び/又はペアリング済みコントローラの証明書(証明書ベースのペアリング用)、並びに、各コントローラがいずれの許可を有するかを示す、TLV項目を、各ペアリングに関して生成することができる。これらのTLV項目は、サブTLV、単一の最上位TLVとして、(分離記号を使用して)一体にパック化することができる。一部の実施形態では、アクセサリは、最上位TLVを、要求側コントローラに送信する前に暗号化する。
Pairing ID特性1205は、MACアドレス、アクセサリの公開キーの一部分、アクセサリの「ユーザ名」(例えば、以下で説明されるようなもの)などの、そのアクセサリに関するグローバル一意識別子とすることができる。
一部の実施形態では、特性1201〜1205は、少なくとも、アクセサリが少なくとも1つのコントローラとペアリングを確立するような時間まで、ペアリングされていないコントローラに可視のアクセサリペアリングサービスインスタンスを定義することによって、コントローラに公開することができる。例えば、アクセサリが、通信トランスポートとしてBluetooth LEを使用する場合には、アクセサリは、Bluetooth LEを介して、そのペアリングサービスを広告することができる。
ペアリングサービスに加えて、又はその代わりに、アクセサリは、コントローラがペアリング機能性にアクセスするために参照することが可能な、1つ以上のURLを定義することができる。例えば、上記の表4を参照すると、コントローラは、ペア設定プロセスの間、要求を作成して関連情報を提供するために、HTTP POST要求を、/pair−setupのURLに送信することができる。コントローラは、ペア検証プロセスの間、要求を作成して関連情報を提供するために、HTTP POST要求を、/pair−verifyのURLに送信することができる。コントローラは、ペアリングを管理するために、例えば、ペア追加プロセス及びペア除去プロセスを開始するために、あるいは、そのアクセサリに関する確立済みペアリングのリストを取得するために、HTTP POST要求を、/pairingsのURLに送信することができ、このPOST要求は、具体的な要求を示すデータオブジェクトを含み得る。
アクセサリとコントローラとの間にペアリングを確立するプロセス(「ペア設定」と称されるもの)の実施例を、ここで説明する。これらのプロセス又は他のプロセスのいずれも、例えば、図4のプロセス400のブロック428及び430で実施することができる。したがって、以下では、アクセサリ及びコントローラは、既に発見を実行して、通信チャネルを開いていることが想定されるが、この通信チャネルはセキュリティが確保されていない場合がある。更に、ユーザは、コントローラが特定のアクセサリとペアリングするべきであることを、既にコントローラに確認していることが想定される。
一部の実施形態では、ペア設定は、アクセサリがペアリングモードにある場合にのみ、許可される。アクセサリをペアリングモードにすることは、そのアクセサリとの、ユーザによる物理的接触を伴い得る。例えば、ユーザは、物理的対象物(例えば、キー)を、アクセサリ上の差込口内に挿入すること、アクセサリ上のスイッチを「ペアリング」位置に移動させることなどが、必要とされる場合がある。一部の実施形態では、ペア設定は、アクセサリが、いずれのコントローラともペアリングを確立していない場合にのみ、許可される。アクセサリが、1つのペアリングを確立した後は、更なるペアリングは、以下で説明されるような、ペア追加プロセス(又は、他の委譲ペアリングプロセス)を使用して確立することができる。
図13A〜図13Cは、本発明の実施形態による、コントローラ1302及びアクセサリ1304に関する、設定コードベースのペア設定プロセス1300を示す。設定コードベースのペア設定では、ユーザは、双方向の認証を提供するために、アクセサリの設定コード(例えば、そのアクセサリに固有であり、容易に推測可能ではない、10桁の識別番号とすることが可能なもの)を、コントローラで入力することが必要となり得る。セキュリティのために、アクセサリの設定コードは、アクセサリによってディスプレイ上に示すか、若しくはユーザによって手動で(例えば、アクセサリ上の物理ダイヤルを設定するか、又はキーパッドに数字を打ち込むことによって)アクセサリに提供することができ、又は、設定コードは、アクセサリの筐体又はパッケージング上の、若しくはそれらの内部の、いずれかの場所に(例えば、目立たない表面上のラベルに)印刷することができる。アクセサリ製造元は、公的にアクセス可能な情報(例えば、シリアル番号、MACアドレス、製造元名、製造日など)からは設定コードを導出しないことによって、セキュリティを強化することができる。本明細書での実施例では、ペア設定は、Secure Remote Password(「SRP」)プロトコル(http://srp.standford.eduに文書化)を活用するが、しかしながら、他のプロトコルを使用することもできる。
最初に図13Aを参照すると、ブロック1306で、コントローラ1302は、関連するユーザ名(「userC」)を検索することができる。このユーザ名は、コントローラを互いに区別することを助けるために、アクセサリによって使用することが可能な、コントローラ1302及び/又はコントローラ1302の認可ユーザの、任意の識別子を含み得る。ブロック1308で、コントローラ1302は、例えば、適切なURLへのHTTP POST要求として、ペア設定開始要求を送信することができる。このペア設定開始要求は、そのペア設定開始要求が送信されたことを示す状態標識(一部の実施形態では、この状態標識及び後続の状態標識は、コントローラによって、図12のPairing State Request特性1201に書き込むことができる)と、設定コードベースのペアリング方法が使用されていることを示す方法標識と、コントローラのユーザネームuserCとを含み得る。
ブロック1310で、アクセサリ1304は、このペア設定開始要求をスロットリングするか否かを判定することができる。例えば、ランダムな推測に基づく攻撃を阻むために、アクセサリ1304は、次の開始要求を待機する時間が、ペア設定の試みが失敗するたびに倍増される、指数的スロットリングを実施することができる(例えば、最後のnの試みが失敗した場合には、(n+1)番目の試みは、少なくとも2n-1秒待機しなければならない)。このスロットリングは、セッションごとに、又は接続ごとに適用されるのではなく、包括的に適用することができる。スロットリング時間は、ペア設定の試みが成功した後に、リセットすることができる。したがって、ブロック1310で、スロットリングが実施されており、最後の試みからスロットリング時間が経過していない場合には、アクセサリ1304は、ブロック1312でスロットリングメッセージを送信することができる。このスロットリングメッセージは、コントローラが、再試行する前に待機する必要がある時間の長さを示すことができる。ブロック1314で、スロットリングメッセージが受信された場合には、コントローラ1302は、(適切な時間、待機した後に)再試行するか否かを、判定することができる。コントローラ1302が、再試行することを判定した場合には、プロセス1300は、ブロック1308に戻り、適切な待機時間の後に、新たなペア設定開始要求を送信することができる。
ブロック1310で、アクセサリ1304が、要求をスロットリングしない場合には、プロセス1300は、ブロック1316に進行することができ、このブロック1316で、アクセサリ1304は、例えばSRP_new(SRP6a_server_method())などの適切なSRPプロトコル機能を呼び出すことによって、SRPセッションを作り出すことができ、コントローラのユーザ名を、受信した値userCに(SRP_set_username又はSRP_set_user_rawで)設定することができ、SRP_set_paramsで設定することが可能な、ランダムなソルト(例えば、少なくとも16バイト)を生成することができ、それ自体の設定コードを(例えば、SRP_set_auth_password又はSRP_set_auth_password_rawを使用して)選択及び設定することができ、公開キー(「pkA」)を(例えば、SRP_gen_pubを使用して)生成することができる。公開キーpkAは、プロセス1300の持続時間にわたって使用され、次いで破棄される、(秘密キー「skA」を伴う)短期キーペアの一部とすることができる。
アクセサリは、様々な技術を使用して、設定コードを選択することができる。例えば、設定コードは、EEPROM内にプログラムする(及び、アクセサリ上に、若しくはユーザが見つけることが可能なラベル上などに印刷する)ことができる。あるいは、プロセス1300に先立って(又は、その間に)、ユーザが、アクセサリ上若しくはアクセサリ内に提供された、機械的又は電子的入力デバイスを使用することによって、ユーザ選択設定コードを、そのアクセサリ内に入力することができる。更に別の選択肢として、アクセサリは、そのアクセサリが、ユーザに設定コードを(例えば、その設定コードをユーザに表示するか又は他の方式で信号を送ることによって)通知する能力を有するのであれば、ペア設定プロセス1300を実行する各インスタンスの間に、ランダムな設定コードを生成することができる。他の技術もまた、使用することができる。
ブロック1318で、アクセサリ1304は、ランダムなソルト及び公開キーpkAを、コントローラ1302に送信することができ、コントローラ1302は、ブロック1320で、それらを受信することができる。ランダムなソルト及び公開キーpkAを、ブロック1318で送信すると、アクセサリ1304は、そのアクセサリの公開キーが送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1322で、コントローラ1302は、ユーザから、アクセサリの設定コードを取得することができる。例えば、コントローラ1302は、アクセサリの設定コードを入力することをユーザに促す、ユーザインタフェース画面を提示することができる。設定コードが、帯域外で、すなわち、ペア設定プロセスを実行するために使用されている通信チャネルとは独立した通信チャネルを介して、コントローラ1302に配信される限り、他の技術を使用することもできる。例えば、一部の実施形態では、ユーザは、コントローラ1302の搭載カメラを動作させることにより、設定コードがアクセサリ上に出現する際に、その設定コードの画像をキャプチャすることができ(この画像は、人間に読み取り可能な表現、又は、バーコード若しくはクイックレスポンス(QR)コードなどの機械読み取り可能な表現を含み得る)、コントローラ1302は、その設定コードを抽出するために画像処理を実行することができる。アクセサリ1304からコントローラ1302に設定コードを提供するために使用可能な技術の、他の実施例としては、コントローラ1302がアクセサリ1304に物理的に近接して配置又は保持されている間の、アクセサリ1304からコントローラ1302への近距離通信(NFC)伝送、コントローラ1302によって検出可能なアクセサリ1304による音波又は超音波伝送、高速光信号伝達(例えば、コントローラ1302のカメラ又は光検出器の視野内での、アクセサリ1304によって発生される光パルスのシーケンス)、あるいは、アクセサリ1304、又は設定コードを記憶する関連デバイスの、コントローラ1302のコネクタインタフェースへの物理的接続が挙げられる。
ブロック1324で、コントローラ1302は、例えば、SRP_new(SRP6a_server_method())などの適切なSRPプロトコル機能を呼び出すことによってSRPセッションを作り出すことができ、コントローラのユーザ名を、(SRP_set_username又はSRP_set_user_rawで)設定することができ、アクセサリから受信したソルトを(SRP_set_paramsで)設定することができ、それ自体の公開キー(「pkC」)を(例えば、SRP_gen_pubを使用して)生成することができ、ユーザ入力設定コードを使用して、SRPパスワードを(例えば、SRP_set_auth_password又はSRP_set_auth_password_rawを使用して)設定することができ、共有シークレット(「inputKey」)を(例えば、SRP_compute_keyを使用して)計算することができる。アクセサリ公開キーpkAと同様に、公開キーpkCは、プロセス1300の持続時間にわたって使用され、次いで破棄される、(秘密キー「skC」を伴う)短期キーペアの一部とすることができる。
ブロック1326で、コントローラ1302は、それ自体のアイデンティティを証明するために、コントローラ証明(「proofC」)を(例えば、SRP_respondを使用して)生成することができる。ブロック1328で、コントローラ1302は、公開キーpkC及び証明proofCを含む検証要求を、例えば、適切なURLへのHTTP POST要求として、アクセサリに送信することができる。この要求をブロック1328で送信すると、コントローラ1302は、そのコントローラの証明が送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1330で、アクセサリ1304は、コントローラ証明proofCを検証することができる。例えば、アクセサリ1304は、共有シークレット(「inputKey」)を(例えば、SRP_compute_keyを使用して)計算することができ、その共有シークレットを使用して、proofCを(例えば、SRP_verifyを使用して)検証することができる。
図13Bに示すように、ブロック1332で、ブロック1330での検証が失敗した場合には、ブロック1334で、アクセサリ1304は、コントローラ1302にエラーメッセージを送信することができる。ブロック1336で、そのエラーメッセージをコントローラ1302が受信した場合には、プロセス1300は、ブロック1338で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
ブロック1332で、検証が成功した場合には、ブロック1340で、アクセサリ1304は、それ自体のアイデンティティを証明するために、アクセサリ証明(「proofA」)を(例えば、SRP_respondを使用して)生成することができる。ブロック1342で、アクセサリ1304は、アクセサリ証明proofAを、コントローラ1302に送信することができ、コントローラ1302は、ブロック1344で、proofAを受信することができる。proofAをブロック1342で送信すると、アクセサリ1304は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1346で、コントローラ1302は、proofAを(例えば、SRP_verifyを使用して)検証することができる。ブロック1348で、検証が失敗した場合には、プロセス1300を終了することができる(ブロック1350)。検証がブロック1348で成功した場合には、現時点で、そのアクセサリ及びコントローラはそれぞれ、認証された共有シークレットを保有している。
したがって、ブロック1352で、コントローラ1302は、その共有シークレットinputKeyから、新たな暗号キー(「Key」)を生成することができる。例えば、コントローラ1302は、inputKey、ランダムなソルト、及び追加的情報項目(コントローラ1302内に予めプログラム可能なもの)を入力として使用して、512ビットハッシュ用のSecure Hash Algorithmバージョン2を実装するHMACベースのキー導出関数(IETF RFC 2104で定義される、HMAC−SHA−512)を使用することができる。ブロック1354で、コントローラ1302は、Keyを使用して、その長期公開キー(LTPKC)を暗号化することができる。この長期公開キーは、コントローラ上に(例えば、上述のようなセキュア要素内に)永続的に記憶されるキーとすることができ、プロセス1300でそれ以前に生成された短期公開キーpkCとは無関係である。この暗号化は、キーとしてKeyを使用し、メッセージとしてLTPKCを使用し、及びノンスを使用して、ChaCha20−Poly1305(http://tools.ietf.org/html/draft−agl−tls−chacha20poly1305−03で入手可能な、IETFインターネットドラフトdraft−agl−tls−chacha20poly1305−03で説明されるもの)などの暗号化及び認証アルゴリズムを使用することにより、暗号化データedataC及び認証タグauthTagCを作り出すことができる。
ブロック1356で、コントローラ1304は、アクセサリ1304に、edataC及びauthTagCを送信することができ、コントローラ1302はまた、LTPKCがアクセサリに送信されたことを示すように、ペアリング状態を更新することもできる。
ブロック1358で、edataC及びauthTagCを受信すると、アクセサリ1302は、コントローラ1302がブロック1352で使用したものと同じ方法を使用して、暗号キー(「Key」)を生成することができる。この時点まで全てが正常に進行している場合には、その暗号キーは同じKeyであるはずである。ブロック1360で、アクセサリ1302は、受信したauthTagCを検証することができる。
図13Cに示すように、ブロック1362で、ブロック1360での検証が失敗した場合には、ブロック1364で、アクセサリ1304は、コントローラ1302にエラーメッセージを送信することができる。ブロック1366で、そのエラーメッセージをコントローラ1302が受信した場合には、プロセス1300は、ブロック1368で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
ブロック1362が成功をもたらした場合には、ブロック1370で、アクセサリ1304は、LTPKCを復号することができ、ブロック1372で、アクセサリ1304は、LTPKC、及びコントローラのユーザ名userCを、ペアリング済みコントローラのレコードとして、永続的に記憶することができる。そのような記憶は、上述のようなセキュア要素内に存在させることができる。
ブロック1374で、アクセサリ1304は、そのアクセサリの長期公開キー(LTPKA)と、そのアクセサリに関連付けられたユーザ名とを含む、データオブジェクトを構築することができる。このアクセサリの長期公開キーは、(例えば、アクセサリ1304のセキュア要素内に)永続的に記憶されるキーとすることができ、プロセス1300でそれ以前に生成された短期公開キーpkAとは無関係である。コントローラのユーザ名userCと同様に、アクセサリのユーザ名userAは、アクセサリを互いに区別することを助けるために、コントローラによって使用することが可能な、アクセサリ1304又はアクセサリ1304の認可ユーザの、任意の識別子を含み得る。ブロック1376で、アクセサリ1304は、ブロック1374で生成されたデータオブジェクトを暗号化することにより、edataA及びauthTagAを生成することができる。ブロック1354でコントローラ1302によって使用されたものと同じ暗号化アルゴリズムを、使用するができる。ブロック1378で、アクセサリ1304は、コントローラ1302に、edataA及びauthTagAを送信することができ、アクセサリ1304はまた、LTPKAがコントローラに送信されたことを示すように、ペアリング状態を更新することもできる。
ブロック1380で、edataA及びauthTagAを受信すると、コントローラ1302は、受信したauthTagAを検証することができる。
ブロック1382で、ブロック1380での検証が失敗した場合には、ブロック1384で、プロセス1300は終了することができ、コントローラ1304は、ユーザにエラーを報告することができる。検証が成功した場合には、ブロック1386で、コントローラ1304は、LTPKAを復号して、LTPKA、及びアクセサリのユーザ名userAを、ペアリング済みアクセサリのレコードとして、永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。ブロック1388で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
プロセス1300は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1300は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、SRP並びに具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための他のプロトコル及びアルゴリズムで置き換えることもできる。
一部の実施形態では、ペアリングプロセスは、認証インフラストラクチャを活用することができる。例えば、認証チップ(集積回路デバイス、すなわちIC)を、アクセサリ及び/又はコントローラデバイス内に組み込むことができる。この認証チップは、デバイスに関する暗号キー、そのデバイスに関するセキュリティ証明書、及び、他のデバイスによって提示することが可能な有効若しくは無効なセキュリティ証明書についての情報を、安全に記憶することができる。一部の実施形態では、この認証チップは上述のセキュア要素(又は、その一部分)を実装することができる。所定のアクセサリが認証チップを含む場合には、その認証チップをペア設定プロセスで使用することができる。
図14A〜図14Cは、本発明の実施形態による、認証チップを使用する、コントローラ1402及びアクセサリ1404に関するペア設定プロセス1400の実施例を示す。コントローラ1402は、プロセス1400を開始する前に、アクセサリ1404が認証チップを有することを確認していることが想定される。例えば、上述のFeature Flags特性1202は、証明書ベースのペアリングをアクセサリがサポートするか否かを示すフラグを含み得る。このフラグは、認証チップを有するアクセサリに対して設定することができる。別の実施例として、アクセサリが証明書ベースのペアリングをサポートするか否かを示すフラグを、そのアクセサリに関するサービス発見レコードの特徴フラグのフィールド(例えば、表3でのBonjour TXTレコードの特徴フラグ「ff」フィールド)内に含めることができ、このことにより、そのフラグを、ペアリングされていないコントローラに、より容易にアクセス可能にさせることができる。(認証チップが欠如しているアクセサリが、それにもかかわらず、このフラグを設定する場合には、コントローラは、プロセス1400を実行する通常の過程で、認証チップが存在しないことを検出し、エラーを報告することができる)。
図14Aを参照すると、ブロック1406で、コントローラ1402は、例えば、楕円曲線Diffie−Hellmanキー共有プロトコルに基づく、Curve25519アルゴリズム(http://cr.yp.to/ecdh.htmlで文書化)を使用して、公開/秘密キーペア(pkC、skC)を生成することができる。このキーペアは、プロセス1400の持続時間にわたって使用され、次いで破棄される短期キーペアとすることができる。ブロック1408で、コントローラ1402は、アクセサリ1404に、例えば適切なURLへのHTTP POST要求として、ペア設定開始要求を送信することができ、この要求は公開キーpkCを含み得る。このペア設定開始要求は、そのペア設定開始要求が送信されたことを示す状態標識を含み得る(一部の実施形態では、この状態標識及び後続の状態標識は、図12のペアリング制御点特性1201に書き込むことができる)。
ブロック1410で、このペア設定開始要求に応答して、アクセサリ1404は、例えばCurve25519アルゴリズムを使用して、公開/秘密キーペア(pkA、skA)を生成することができる。(pkC、skC)と同様に、このキーペアは、プロセス1400の持続時間にわたって使用され、次いで破棄される、短期キーペアとすることができる。図示されていないが、プロセス1300に関連して上述されたスロットリング挙動を組み込むことができ、アクセサリ1404は、ペア設定開始要求が、失敗した試みの後、過度に早い時点で受信された場合には、その要求を拒否することができる。
ブロック1412で、アクセサリ1404は、skA及びpkCを使用して、共有シークレット(「inputKey」)を生成することができる。ブロック1414で、アクセサリ1404は、公開キーpkAとpkCとを連結することによって、メッセージを構築することができ、ブロック1416で、アクセサリ1404は、その認証チップを使用してメッセージに署名することにより、メッセージ「smsg」を生成することができる。認証チップは、それ自体の(pkA及びskAとは無関係な)永続的なキーペアを有し得るものであり、SHA−1又はSHA−2(連邦情報処理規格刊行物180−4で文書化されている、米国国家安全保障局によって設計された、暗号ハッシュ関数)などの任意の所望のアルゴリズムを実行することができる。
ブロック1418で、アクセサリ1404は、対称キー(「Key」)を生成することができる。例えば、アクセサリ1404は、inputKey、ソルト(例えば、既定の文字列)、及び追加的情報を入力として使用してHMAC−SHA−512を使用することができる。
ブロック1420で、アクセサリ1404は、ブロック1418で生成されたキーKeyを使用して、ブロック1416からの署名付きメッセージsmsgを暗号化することにより、証明「proofA」を生成することができる。任意の対称暗号化アルゴリズムを使用することができる。
ブロック1422で、アクセサリ1404は、コントローラ1402に応答を送信することができる。この応答は、公開キーpkA、アクセサリ証明proofA、及び認証チップによって提供されるアクセサリ証明書を含み得る。この応答をブロック1422で送信すると、アクセサリ1404は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1424で、コントローラ1402は、そのアクセサリ証明書を検証することができる。例えば、コントローラ1402は、有効なアクセサリ証明書を特定する情報を記憶する、それ自体の認証チップ又は他のセキュアデータストアを有し得るものであり、その情報は、信頼される認証局によってコントローラ1402に提供され、一部の場合には、信頼される認証局によって更新することもできる。コントローラ1402は、この情報を使用して、受信したアクセサリ証明書が有効であることを確認することができる。一部の実施形態では、特定の証明書は、特定のクラスのアクセサリに関してのみ有効とすることができ、コントローラ1402は、アクセサリから以前に受信した情報(例えば、アクセサリ定義レコード、又は上述のようなデバイス発見の間に提供された他の情報)を使用して、そのアクセサリのクラス、及び、受信したアクセサリ証明書が、そのアクセサリのクラスに関して有効であるか否かを判定することができる。
図14Bを参照すると、ブロック1426で、アクセサリ証明書が有効ではない場合には、プロセス1400は終了することができ(ブロック1428)、コントローラ1402は、ユーザにエラーを通知することができる。アクセサリ証明書が有効である場合には、ブロック1430で、コントローラ1402は、skC及びpkAを使用して、共有シークレット(「inputKey」)を生成することができる。ブロック1432で、コントローラ1402は、対称キー(「Key」)を生成することができる。例えば、アクセサリ1404は、inputKey、ソルト(例えば、既定の文字列)、及び追加的情報を入力として使用して、HMAC−SHA−512を使用することができる。ブロック1434で、コントローラ1404は、対称キーKeyを使用することにより、proofAを暗号化するためにアクセサリ1404によって使用されたものと同じアルゴリズムを使用して、アクセサリから受信したproofAを復号することができる。それゆえ、コントローラ1402は署名付きメッセージsmsgを取得する。ブロック1436で、コントローラ1402は、アクセサリ証明書を使用して、そのsmsg上の署名を検証することができる。ブロック1438で、その署名が有効ではない場合には、プロセス1400は終了することができ(ブロック1440)、コントローラ1402はユーザにエラーを通知することができる。
図14Cを参照すると、署名が有効である場合には、ブロック1442で、コントローラ1402は、コントローラのユーザ名「userC」及びコントローラの長期公開キーLTPKCを有する、データオブジェクトを構築することができる(これは、上述のプロセス1300の場合と同じものであり得る)。ブロック1444で、コントローラ1402は、そのデータオブジェクトを暗号化することにより、edataC及びauthTagCを生成することができる。ブロック1442での暗号化は、上述のプロセス1300と同様に、キーとしてKeyを使用し、メッセージとしてLTPKCを使用し、及びノンスを使用して、ChaCha20−Poly1305などの暗号化及び認証アルゴリズムを使用することができる。ブロック1446で、コントローラ1402は、アクセサリ1404にedataC及びauthTagCを含む、交換要求メッセージを送信することができ、コントローラ1402はまた、LTPKCがアクセサリに送信されたことを示すように、ペアリング状態を更新することもできる。
ブロック1448で、アクセサリ1404は、その対称キーKeyを使用して、受信したauthTagCを検証することができる。ブロック1450で、ブロック1448での検証が失敗した場合には、ブロック1452で、アクセサリ1404はコントローラ1402にエラーメッセージを送信することができる。ブロック1454で、そのエラーメッセージをコントローラ1402が受信した場合には、プロセス1400は、ブロック1456で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
ブロック1450が成功をもたらした場合には、ブロック1458で、アクセサリ1404は、LTPKCを復号することができ、ブロック1460で、アクセサリ1304は、LTPKC、及びコントローラのユーザ名userCを、ペアリング済みコントローラのレコードとして永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。
ブロック1462で、アクセサリ1404は、双方とも上述のプロセス1300の場合と同じものであり得る、そのアクセサリの長期公開キー(LTPKA)と、そのアクセサリに関連付けられたユーザ名(userA)とを含む、データオブジェクトを構築することができる。アクセサリの長期公開/秘密キーペアは、そのアクセサリの認証チップ内のキーペアとは異なるものとすることができる。ブロック1464で、アクセサリ1404は、ブロック1462で生成されたデータオブジェクトを暗号化することにより、edataA及びauthTagAを生成することができる。ブロック1444でコントローラ1402によって使用されたものと同じ暗号化アルゴリズムを、使用するができる。ブロック1466で、アクセサリ1304は、コントローラ1402に、edataA及びauthTagAを送信することができ、アクセサリ1404はまた、LTPKAがコントローラに送信されたことを示すように、ペアリング状態を更新することもできる。
ブロック1468で、edataA及びauthTagAを受信すると、コントローラ1402は、以前に生成されたキーKeyを使用して、受信したauthTagAを検証することができる。
ブロック1470で、ブロック1468での検証が失敗した場合には、ブロック1472で、プロセス1400は終了することができ、コントローラ1404は、ユーザにエラーを報告することができる。検証が成功した場合には、ブロック1474で、コントローラ1404は、LTPKAを復号して、LTPKA、及びアクセサリのユーザ名userAを、ペアリング済みアクセサリのレコードとして永続的に記憶することができる(そのような記憶は、上述のセキュア要素内に存在させることができる)。ブロック1476で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
プロセス1400は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1400は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための他のプロトコル及びアルゴリズムで置き換えることもできる。
上述のようなプロセス1400は、アクセサリが、検証のために証明書をコントローラに送信するが、コントローラは、対応する証明書をアクセサリに送信しないという点で非対称的である。一部の実施形態では、双方向の証明書検証を実施することができる。例えば、証明書を有するコントローラが、ブロック1412〜1416と同様の処理を実行することにより、コントローラ証明(「proofC」)を生成することができ、そのコントローラ証明を、コントローラ証明書と共に、アクセサリに送信することができる。アクセサリは、ブロック1424〜1436と同様の処理を実行することにより、そのコントローラ証明を検証することができる。
一部の実施形態では、認証チップは、特定のデバイスに固有のものとすることができ、各デバイスは、一意の証明書を有し得る。他の実施形態では、同じクラスのアクセサリ(又は、コントローラ)は、同一の認証チップを、またそれゆえ、同一の証明書を有し得る。このことが当てはまる場合、ペア設定の間の中間者攻撃に対する防御は、低減される恐れがあるが、しかしながら、長期公開キーが交換された後は、後続のペア検証の間の双方向認証のために、これらのキーを信頼して使用することができる。
中間者攻撃又は他の悪用のリスクを更に低減するために、他の技術を使用することもできる。例えば、ペア設定プロセスでの2つのデバイスの一方(又は、双方)が、どの程度他方のデバイスが近接しているかを(例えば、Bluetooth LE又はNFCを使用して)検出することが可能な、近接センサを有する場合には、そのセンサを有するデバイスは、他方のデバイスが近接位置に(例えば、数インチの範囲内に)存在しないか又は留まらない場合には、ペア設定プロセスを中止することができる。このことにより、中間者攻撃の可能性を低減することができるが、これは、攻撃するデバイスが、その過程で、目的とする参加者に物理的に近接する必要があり、ユーザが気づく可能性が高い状況となるためである。
一部の実施形態は、セキュリティ証明書及び設定コードの双方に基づくペアリングを、ペア設定プロセスに組み込むことができる。図15A〜図15Fは、本発明の実施形態による、セキュリティ証明書及び設定コードを使用する、コントローラ1502及びアクセサリ1504に関するペア設定プロセス1500の実施例を示す。プロセス1500は、上述のプロセス1300及びプロセス1400の機能を組み込むことができる。
最初に図15Aを参照すると、ブロック1506で、コントローラ1502は、ペア設定プロセスを開始するために、アクセサリ1504に開始要求を送信することができる。例えば、コントローラ1502は、アクセサリ1504の/pair−setupのURLに、HTTP POST要求を送信することができる。このPOST要求は、所望のペアリング状態(例えば、「ペア設定を開始する」)を示す、TLVデータオブジェクトと、設定コード及び/又は証明書を使用するか否かを示す方法識別子とを含み得る。ブロック1508で、アクセサリ1504は、その開始要求を受信することができ、現在のペアリング状態を適宜に設定することができる。ブロック1510で、アクセサリ1504は、存在し得る他のあらゆるコントローラが、ペア設定を開始することを阻止することができる。例えば、ブロック1510の後に、ペア設定を開始する要求が受信される場合には、アクセサリは、エラー応答(例えば、HTTP429「Too Many Requests(要求が多すぎる)」メッセージ)を返すことができる。アクセサリ1504は、プロセス1500が完了する(又は、エラーにより終了する)まで、この方式でペア設定要求を阻止し続けることができる。
一部の実施形態では、アクセサリ1504は、ペア設定の試みの失敗の数を、包括的に、又はコントローラごとに、最大試行回数までに制限することができる。例えば、アクセサリ1504は、制限(例えば、5回の試行、10回の試行、又は何らかの他の制限)を定義して、失敗した試行のカウンタを保持することができる。カウンタが制限に到達するか、又は制限を超過した場合には、ブロック1512で、アクセサリは、その要求を拒絶することができ、プロセス1500は、ブロック1514で終了することができる。一部の実施形態では、アクセサリ1504は、コントローラ1502に、エラーの原因(例えば、過度に多い試行)を示すエラー応答を送信することができる。あるいは、スロットリング技術(例えば、図13Aを参照して上述されたようなもの)又は他の技術を使用することにより、無認可のコントローラによる、ペア設定を実行する総当たり試行を防ぐことができる。
最大試行回数を超過していないと想定すると、ブロック1516で、アクセサリ1504はペア設定を開始することができる。例えば、アクセサリ1504は、例えば、SRP_new(SRP6a_server_method())などの適切なSRPプロトコル機能を呼び出すことによって、SRPセッションを作り出すことができ、そのセッションに関するSRPユーザ名を(例えば、総称とすることが可能な固定文字列をユーザ名として使用して、SRP_set_usernameで)設定することができ、SRP_set_paramsで設定することが可能な、ランダムなソルト(例えば、少なくとも16バイト)を生成することができ、SRPパスワードとして(例えば、SRP_set_auth_password又はSRP_set_auth_password_rawを使用して)設定される、設定コードを選択する(例えば、取得する)ことができる。
プロセス1300と同様に、アクセサリ1504は、EEPROMからのコードの読み取り、ユーザからのコードの受信、(例えば、プロセス1500の実行の間の)ランダムコードの生成などを含めた様々な技術を使用して、設定コードを選択することができる。ブロック1518で、アクセサリ1504は、その設定コードをユーザに提示することができる。例えば、アクセサリ及び設定コードに応じて、そのコードは、アクセサリ1504又はそのパッケージングに張り付けられた、ラベル上に印刷するか、アクセサリ1504のディスプレイ上に提示することなどが可能である。一部の場合には、ユーザに設定コードを提示するのではなく、アクセサリ1504は、NFCチャネル、又は極めて短い距離(例えば、50cm未満)を使用する他の信号伝達チャネルなどの、ペア設定プロセス1500に関して使用されているチャネルとは独立した通信チャネルを使用して、そのコードをコントローラ1502に配信することができる。
ブロック1520で、アクセサリ1504は、(例えば、SRP_gen_pubを使用して)公開キー(「pkA」)を生成することができる。公開キーpkAは、プロセス1500の持続時間にわたって使用され、次いで破棄される、(秘密キー「skA」を伴う)短期キーペアの一部とすることができる。
ブロック1522で、アクセサリ1504は、例えばHTTP応答メッセージを使用して、開始要求に対する応答を送信することができる。この応答は、公開キーpkA及びランダムなソルトを含み得る。この応答をブロック1522で送信すると、アクセサリ104は、そのアクセサリの公開キーが送信されたことを示すように、現在のペアリング状態を更新することができる。
ブロック1524で、コントローラ1502は、開始要求に対する応答を受信することができる。ブロック1526で、コントローラ1502は、ユーザから、設定コードを取得することができる。例えば、コントローラ1502は、アクセサリの設定コードを入力することをユーザに促す、ユーザインタフェース画面を提示することができる。上述のプロセス1300のブロック1322と同様に、設定コードが、帯域外で、すなわち、ペア設定プロセスを実行するために使用されている通信チャネルとは独立した通信チャネルを介して、コントローラ1502に配信される限り、他の技術を使用することもできる。使用される具体的な技術に応じて、コントローラによる設定コードの取得には、何らかの形態のユーザアクティビティ(例えば、コードを入力すること、コントローラをアクセサリに近接させて保持すること、コントローラのカメラを操作することなど)を組み込むことができ、そのようなアクティビティは、デバイスのアイデンティティの帯域外確認を提供することに加えて、コントローラ1502とアクセサリ1504とのペアリングを確立することをユーザが意図していることの確認として役立ち得る。
図15Bを参照すると、ブロック1528で、コントローラ1502は、例えば、SRP_new(SRP6a_server_method())などの適切なSRPプロトコル機能を呼び出すことによって、SRPセッションを作り出すことができ、SRPユーザ名を(例えば、総称とすることが可能な固定文字列をユーザ名として使用して、SRP_set_usernameで)設定することができ、アクセサリから受信したソルトに(SRP_set_paramsで)ソルトを設定することができ、それ自体の公開キー(「pkC」)を(例えば、SRP_gen_pubを使用して)生成することができ、ブロック1526で取得した設定コードを使用して、SRPパスワードを(例えば、SRP_set_auth_password又はSRP_set_auth_password_rawを使用して)設定することができる。アクセサリ公開キーpkAと同様に、公開キーpkCは、プロセス1500の持続時間にわたって使用され、次いで破棄される、(秘密キー「skC」を伴う)短期キーペアの一部とすることができる。ブロック1530で、コントローラ1502は、共有シークレット(「inputKey」)を(例えば、SRP_compute_keyを使用して)計算することができる。ブロック1532で、コントローラ1502は、共有シークレットinputKeyを有することの証明(「proofC」)を(例えば、SRP_Respondを使用して)生成することができる。
ブロック1534で、コントローラ1502は、アクセサリ1504に、検証要求を送信することができる。例えば、コントローラ1502は、アクセサリ1504の/pair−setupのURLに、HTTP POST要求を送信することができる。このPOST要求は、所望のペアリング状態(例えば、「ペア設定を検証する」)を示すTLVデータオブジェクト、コントローラの公開キーpkC、及びコントローラ証明proofCを含み得る。
ブロック1536で、アクセサリ1504は、その検証要求を受信することができる。ブロック1538で、アクセサリ1504は、共有シークレット(「inputKey」)を(例えば、SRP_compute_keyを使用して)計算することができ、この共有シークレットは、ブロック1530でコントローラ1502によって計算された共有シークレットと合致するはずである。
ブロック1540で、アクセサリ1504は、ブロック1538で計算された共有シークレットを使用して、コントローラ証明proofCを(例えば、SRP_verifyを使用して)検証することができる。図15Bには示されないが、検証が失敗した場合には、アクセサリ1504は、プロセス1500を終了させて、コントローラ1502にエラーメッセージを送信することができる。(本明細書で説明される他のペアリングプロセスと同様に、コントローラ1502はそのエラーをユーザに報告することができる。)
proofCが検証されたと想定すると、ブロック1542で、アクセサリ1504は、共有シークレットを保有していることを証明するために、アクセサリ証明(「proofA」)を(例えば、SRP_respondを使用して)生成することができる。ブロック1544で、アクセサリ1504は、その共有シークレットから、セッション暗号キー(「eKey」)を導出することができる。例えば、アクセサリ1504は、inputKey、ソルト、及び追加的情報を入力として使用して、512ビットハッシュ用のSecure Hash Algorithmバージョン2を実装するHKDFベースのキー導出関数(IETF RFC 6234で文書化されている、HKDF−SHA−512)を使用することができる。
図15Cを参照すると、この実施例では、アクセサリ1504は、信頼される認証局によって発行されたセキュリティ証明書を有することが想定される。一部の実施形態では、この証明書は、図14A〜図14Cを参照して上述されたように、認証チップ内に組み込むことができる。このことが当てはまる場合、アクセサリ1504は、その証明書を使用して、そのアイデンティティをコントローラ1502に更に証明することができる。一部の実施形態では、ブロック1506でコントローラ1502によって送信される開始要求、又はブロック1534でコントローラ1502によって送信される検証要求は、アクセサリが証明書で認証するべきか否かの指標を含み得る。
アクセサリ1504が証明書で認証する場合には、ブロック1546で、アクセサリ1504は、ブロック1538で計算された共有シークレット(inputKey)から、署名するためのチャレンジを生成することができる。例えば、このチャレンジは、inputKey、ソルト、及び追加的情報項目を入力として使用して、HKDF−SHA−512などのキー導出関数を適用することによって、生成することができる。これらのソルト及び追加的情報項目は、アクセサリ1504内に、そのオペレーティングシステム又はファームウェアの一部としてプログラムすることが可能な既定の値を有し得る。ブロック1548で、アクセサリ1504は、その証明書を使用して、このチャレンジに署名することができる。例えば、アクセサリ1504が認証チップを含む場合には、その認証チップが、チャレンジに署名することができる。上述のように、認証チップは、それ自体の永続的なキーペア(pkA及びskA、あるいはLTPKA及びLTSKAとは独立したもの)を有し得るものであり、SHA−1などの任意の所望の署名アルゴリズムを実行することができる。
ブロック1550で、アクセサリ1504は、認証チップから取得することが可能な、署名付きチャレンジ及びアクセサリ証明書を含む、データ構造を構築することができる。ブロック1552で、アクセサリ1504は、ブロック1550で構築されたデータ構造を、ブロック1544で生成された暗号キー(eKey)を使用して暗号化することができる。ChaCha20−Poly1305 AEADなどの、任意の対称暗号化アルゴリズムを使用することができる。この暗号化アルゴリズムは、暗号化データ構造、及びタグ(authTagA)を生成することができる。
ブロック1554で、アクセサリ1504は、コントローラ1502に検証応答を送信することができる。この検証応答は、ブロック1542で生成されたアクセサリ証明proofA、並びに、ブロック1550で生成された暗号化データ構造及びauthTagAを含み得る。上述のように、一部の実施形態では、証明書ベースの認証を実行するか否かを、(例えば、コントローラ1502が、証明書ベースの認証を要求したか否かに応じて)選択することができる。証明書ベースの認証が実行されていない場合には、この検証応答は、暗号化データ構造及びauthTagAを省略することができる。
ブロック1556で、コントローラ1502は、アクセサリ1504から検証応答を受信することができる。ブロック1558で、コントローラ1502は、アクセサリ証明proofAを(例えば、SRP_verifyを使用して)検証することができる。検証が失敗した場合には、プロセス1500はエラーで終了することができる。検証が成功したと想定すると、ブロック1560で、コントローラ1502は、ブロック1530で計算された共有シークレット(inputKey)から、暗号キー(eKey)を導出することができる。コントローラ1502は、アクセサリ1504がブロック1544で使用したものと同じキー導出アルゴリズム及び入力を使用することができ、そのため、ブロック1560で導出されるeKeyは、ブロック1544でアクセサリによって生成されたeKeyに合致することが予想される。
ブロック1562で、コントローラ1502は、受信したauthTagAを検証することができ、ブロック1564で、コントローラ1502は、受信したデータ構造を復号することができる。
ここで図15Dを参照すると、ブロック1566で、コントローラ1502は、復号されたデータ構造から抽出されたアクセサリ証明書を検証することができる。例えば、上述のように、コントローラ1502は、有効なアクセサリ証明書を特定する情報を記憶する、それ自体の認証チップ又は他のセキュアデータストアを有し得るものであり、その情報は、信頼される認証局によって提供され、一部の場合には、信頼される認証局によって更新することもできる。あるいは、コントローラ1502は、受信した証明書を検証するために、信頼される認証局とリアルタイムで通信することが可能な場合もある。コントローラ1502は、認証局からの(ローカルでキャッシュされているか、又はリアルタイムで取得される)情報を使用して、アクセサリ証明書が有効であることを確認することができる。一部の実施形態では、特定の証明書は、特定のクラスのアクセサリに関してのみ有効とすることができ、コントローラ1502は、アクセサリから以前に受信した情報(例えば、上述のようなデバイス発見の間に提供された他の情報)を使用して、アクセサリのクラス、及び、アクセサリ証明書がそのアクセサリのクラスに関して有効であるか否かを判定することができる。証明書が有効ではない場合には、プロセス1500はエラーで終了することができる。
証明書が有効であると想定すると、ブロック1568で、コントローラ1502は、共有シークレットinputKeyからチャレンジを生成することができる。コントローラ1502は、アクセサリ1504がブロック1546で使用したものと同じアルゴリズム及び入力(例えば、既定のソルト及び追加的情報項目を伴う、inputKey)を使用することができ、結果として、コントローラ1502及びアクセサリ1504は、双方とも同じチャレンジを生成するはずである。この技術の場合、コントローラ1502が、アクセサリ1504に平文のチャレンジを送信することは必要とされない。更には、チャレンジが、共有シークレットinputKeyを組み込む場合には、そのチャレンジを偽者が推測することは困難なものとなり得る。ブロック1570で、コントローラ1502は、アクセサリ証明書からの公開キーを使用して、署名付きチャレンジを検証することができる。検証が失敗した場合には、プロセス1500はエラーで終了することができる。
検証が成功したと想定すると、コントローラはこの時点で、アクセサリと長期公開キーを交換する準備が整う。ブロック1572で、コントローラ1502は、共有シークレットの表現(例えば、コントローラ1502内に、そのオペレーティングシステム又はファームウェアの一部としてプログラムすることが可能な既定の値を有し得る、ソルト及び追加的情報項目を有する、共有シークレットのHDKF−SHA−512)、コントローラの長期公開キー(LTPKC)、及びコントローラの識別子を連結する、LTPKCメッセージを生成することができる。一部の実施形態では、コントローラは、ブロック1572で使用することが可能な、既定の(LTPKC、LTSKC)キーペアを有し、他の実施形態では、(LTPKC、LTSKC)キーペアを、ブロック1572で生成することができる。ブロック1574で、コントローラ1502は、その長期秘密キー(LTSKC)を使用して、例えば、Ed25519(http://ed25519.cr.yp.toで文書化)などの署名アルゴリズムを、LTPKCメッセージに適用することによって、LTPKCメッセージに署名することができる。ブロック1576で、コントローラ1502は、LTPKCメッセージからの署名、LTPKC、及びコントローラのIDを含むデータ構造を構築することができる。(LTPKCメッセージ自体は、アクセサリ1504が再構築することが可能となるため、このデータ構造から省略することができる。)ブロック1578で、コントローラ1502は、ブロック1560で導出された暗号キーeKeyを使用して、そのデータ構造を暗号化し、認証タグ(authTagC)を生成することができる。
ブロック1580で、コントローラ1502は、アクセサリにキー交換要求を送信することができる。例えばコントローラ1502は、アクセサリ1504の/pair−setupのURLに、HTTP POST要求を送信することができる。このキー交換要求は、ブロック1578で生成された暗号化データ構造及び認証タグを含み得る。ブロック1582で、アクセサリ1504は、コントローラ1502からキー交換要求を受信することができる。
ここで図15Eを参照すると、ブロック1584で、アクセサリ1504は、受信した認証タグを検証することができる。ブロック1586で、アクセサリ1504は、データ構造を復号することができ、ブロック1588で、アクセサリ1504は、そのデータ構造内に含まれる署名を検証することができる。これらの検証のうちのいずれかが失敗した場合には、プロセス1500はエラーで終了することができる。
認証タグ及び署名が検証されたと想定すると、ブロック1590で、アクセサリ1504は、そのデータ構造から注出されたLTPKC及びコントローラIDを、ペアリング済みコントローラのレコードとして、永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。
アクセサリ1504は、同様の方式で、それ自体の長期公開キー(LTPKA)をコントローラ1502に送信することができる。例えば、ブロック1592で、アクセサリ1504は、共有シークレットの表現(例えば、アクセサリのシステムソフトウェア又はファームウェア内にプログラムされた既定の値を有し得る、ソルト及び追加的情報項目を有する、共有シークレットのHDKF−SHA−512)、アクセサリの長期公開キー(LTPKA)、及びアクセサリの識別子を連結する、LTPKAメッセージを生成することができる。一部の実施形態では、アクセサリは、ブロック1592で使用することが可能な既定の(LTPKA、LTSKA)キーペアを有し、他の実施形態では、(LTPKA、LTSKA)キーペアを、ブロック1592で生成することができる。ブロック1594で、アクセサリ1504は、その長期秘密キー(LTSKA)を使用して、例えば、Ed25519などの署名アルゴリズムを、LTPKAメッセージに適用することによって、LTPKAメッセージに署名することができる。ブロック1596で、アクセサリ1504は、LTPKAメッセージからの署名、LTPKA、及びアクセサリのIDを含むデータ構造を構築することができる。(LTPKAメッセージ自体は、コントローラ1502が再構築することが可能となるため、このデータ構造から省略することができる。)ブロック1598で、アクセサリ1504は、ブロック1544で導出された暗号キーeKeyを使用して、そのデータ構造を暗号化し、認証タグ(authTagB)を生成することができる。
ブロック1501で、アクセサリ1504は、コントローラ1502に、キー交換応答を送信することができる。このキー応答は、ブロック1598で生成された、暗号化データ構造及び認証タグを含み得る。ブロック1503で、コントローラ1502は、このキー交換応答を受信することができる。
ここで図15Fを参照すると、ブロック1505で、コントローラ1502は、受信した認証タグを検証することができる。ブロック1507で、コントローラ1502は、データ構造を復号することができ、ブロック1509で、コントローラ1502は、そのデータ構造内に含まれる署名を検証することができる。これらの検証のうちのいずれかが失敗した場合には、プロセス1500はエラーで終了することができる。
認証タグ及び署名が検証されたと想定すると、ブロック1511で、コントローラ1502は、そのデータ構造から注出されたLTPKA及びアクセサリIDを、ペアリング済みアクセサリのレコードとして、永続的に記憶することができる。そのような記憶は、上述のようなセキュア要素内に存在させることができる。
ブロック1513で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
プロセス1500は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1500は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。
上述のようなプロセス1500は、アクセサリが、検証のために証明書をコントローラに送信するが、コントローラは、対応する証明書をアクセサリに送信しないという点で、非対称的である。一部の実施形態では、双方向の証明書検証を実施することができる。例えば、証明書を有するコントローラが、ブロック1546〜1552と同様の処理を実行することにより、チャレンジを生成して、そのチャレンジに、コントローラ証明を使用して署名することができ、その署名付きチャレンジを、コントローラ証明書と共に、アクセサリに送信することができる。アクセサリは、ブロック1566〜1570と同様の処理を実行することにより、そのコントローラの証明を検証することができる。
一部の実施形態では、所定のアクセサリ又はコントローラは、ペア設定プロセス1300、1400、1500(及び/又は、具体的には説明されない他のプロセス)のうちのいずれか又は全てをサポートすることができ、使用されるペア設定プロセスは、ペアリングごとに選択することができる。統一性のために、コントローラは、複数のペア設定プロセスを(例えば、証明書の有無に関わりなく)サポートすることができ、所定のアクセサリに関するプロセスを、そのアクセサリがいずれのプロセス(単数又は複数)をサポートするかに基づいて、選択することができる。プロセスには、優先順位を(例えば、提供される相対的なセキュリティに基づいて)割り当てることができ、コントローラは、所定のアクセサリがサポートする、最も好ましいプロセスを選択することができる。コントローラは、例えば、開始要求メッセージ内にプロセス識別子を含めることによって、そのプロセスを使用するように指定することができる。
図16を参照することによって、より一般的なペア設定の図が示され、この図は、本発明の実施形態による、コントローラ1602とアクセサリ1604との間の、一般化されたペア設定プロセス1600を示す。ペア設定プロセス1600は、ブロック1606で、コントローラ1602によって開始することができる。例えば、上述のように、コントローラ1602は、ペア設定を実行するべきアクセサリ(例えば、アクセサリ1604)を特定するために、プロセス400を(ブロック426を経て)実行することができる。コントローラ1602は、アクセサリ1604もまた、ブロック1608でペア設定を開始することができるように、アクセサリ1604にメッセージ(例えば、適切なURLへのPOST要求)を送信することができる。
ブロック1610及び1612で、アクセサリ1604及びコントローラ1602は、共有シークレット(例えば、上述のプロセス1300、1400、及びプロセス1500でのinputKey)を確立することができる。共有シークレットを確立することは、双方向の情報交換を含み得る。例えば、プロセス1300では、アクセサリは、ソルト及び短期公開キーを提供し、コントローラは、そのコントローラの短期公開キーを提供する。プロセス1400及びプロセス1500では、アクセサリは、そのアクセサリの短期公開キー及び証明書を提供し、コントローラは、そのコントローラの短期公開キーを提供する。一部の実施形態では、共有シークレットはまた、双方のデバイス内に(例えば、セキュア要素内、又は他の場所に)予めプログラムされた、他の情報も組み込むことができる。共有シークレットはまた、コントローラがアクセサリと相互運用されるように(例えば、ユーザによって)認可されている証拠を提供することが可能な、帯域外情報も組み込むことができる。例えば、プロセス1300又はプロセス1500では、共有シークレットを構築するために、アクセサリの設定コードが、コントローラ及びアクセサリによって使用される。上述のように、アクセサリの設定コードは、帯域外で、すなわち、証明の送信及び受信に使用されているチャネル以外の通信チャネルを使用して、コントローラに提供することができる。帯域外チャネルの例としては、ユーザ入力(例えば、ユーザは、コントローラのユーザインタフェースでアクセサリの設定コードを入力することができ、コントローラのカメラを使用して設定コードの写真を撮影することができる)、近距離通信チャネル、光信号伝達チャネル、有線電子信号伝達チャネル、音声(例えば、超音波)チャネルなどを挙げることができる。一部の場合には、帯域外チャネルは、ユーザ介入(例えば、設定コードを入力すること、アクセサリに近接した近距離内にコントローラを保持すること、写真を撮影すること、コネクタのプラグを差し込むこと)を組み込むことができ、帯域外チャネルを介して設定コードを通信するという事実は、ペアリングの確立をユーザが承認していることの指標として役立ち得る。
ブロック1614で、コントローラ1602は、証明を生成して、アクセサリ1604に送信することができる。本明細書で使用するとき、「証明」又は「暗号化証明」は、共有シークレットを保有している受信デバイス(この場合は、アクセサリ1604)が、送信デバイス(この場合は、コントローラ1602)もまた共有シークレットを保有していることを検証するために使用することが可能な、任意の情報を含み得る。コントローラの証明の実施例としては、プロセス1300、1400、1500での、「proofC」と標識されたメッセージが挙げられる。
ブロック1616で、アクセサリ1604は、コントローラの証明を受信することができ、ブロック1618で、アクセサリ1604は、そのローカルで生成された共有シークレットのコピーに基づいて、その証明を検証することができる。共有シークレットが合致しない場合には、コントローラの証明は検証されることなく、プロセス1600はエラーで終了することができる。設定コードを使用して共有シークレットを生成する場合、ブロック1618での検証はまた、アクセサリに対するコントローラの認証としての役割も果たし得ることに留意されたい。
証明が検証されたと想定すると、ブロック1620で、アクセサリ1604は、その共有シークレットをアクセサリ1604もまた保有していることを立証するために、それ自体の証明を生成して、コントローラ1602に送信することができる。このアクセサリの証明は、例えば、(プロセス1300及びプロセス1500と同様に)同じく共有シークレットを組み込むコントローラの証明とは異なる、暗号化メッセージとすることができる。一部の実施形態では、アクセサリのアイデンティティの他の証明を組み込むことができ、例えば、プロセス1400及びプロセス1500では、アクセサリは、そのアクセサリのアイデンティティの少なくとも一部の態様を確認する証明書を使用して、メッセージに署名することができる。
ブロック1624で、コントローラは、受信した証明を検証することができる。ブロック1618と同様に、共有シークレットが合致しない場合には、アクセサリの証明は検証されることなく、プロセス1600はエラーで終了することができる。設定コードを使用して共有シークレットを生成する場合、ブロック1624での検証はまた、コントローラに対するアクセサリの認証としての役割も果たし得ることに留意されたい。例えばアクセサリの証明が、(プロセス1400及びプロセス1500と同様に)証明書を使用して署名されたメッセージを組み込む場合には、更なる認証を提供することができる。
ブロック1624で証明が検証されたと想定すると、双方のデバイスは、互いに認証されたと見なすことができ、共有シークレットを使用して、上述の長期公開キーなどの更なる情報を交換することにより、(永続的な)ペアリングを確立することができる。例えば、ブロック1626で、コントローラ1602は、その長期公開キー(LTPKC)を送信することができる。LTPKCは、例えば、(プロセス1300、1400、及びプロセス1500と同様に)共有シークレットから導出されたキーを使用して、暗号化された形態で送信することができる。ブロック1628で、アクセサリ1604は、LTPKCを受信して、永続的に(例えば、上述のようなセキュア要素内に)記憶することができる。ブロック1630で、アクセサリ1604は、その長期公開キー(LTPKA)を送信することができる。LTPKAもまた、例えば、(プロセス1300、1400、及びプロセス1500と同様に)共有シークレットから導出されたキーを使用して、暗号化された形態で送信することができる。ブロック1632で、コントローラ1602は、LTPKAを受信して、永続的に(例えば、上述のようなセキュア要素内に)記憶することができる。その後、この時点で各デバイスが認証されており、他方とのペアリングを確立するレコードを永続的に記憶しているため、ペア設定が完了する(ブロック1634)。
プロセス1600は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、証明は、いずれの順序でも(アクセサリが最初に、又はコントローラが最初に)交換することができ、長期公開キーもまた、いずれの順序でも交換することができる。
長期公開キーは、本明細書では、プライベート(又は、秘密)キーとは異なり、それらを他のデバイスに提供することが可能なことを示すために、「公開」と称されることに留意されたい。しかしながら、プロセス1300、1400、1500、1600で示されるように、ペア設定は、共有シークレットが他の情報(例えば、設定コード)を使用して確立された後に、デバイスが、暗号化された形態で長期公開キーを交換することを可能にし得る。一部の実施形態では、長期公開キーの復号及び記憶は、受信デバイス内のセキュアコンピューティング要素内で実施することができ、このことにより、長期公開キーが無認可のデバイスに公開されることを、更に防ぐことができる。このことは、無認可のデバイスがペア設定レコードを偽造することを、著しくより困難なものにさせることができる。このレベルのセキュリティにより、ペア設定レコードを、以下で説明されるように、デバイスが再接続する際の、より単純なペア検証プロセスのために使用することが可能となる。
上述のペア設定プロセスのうちのいずれかを介して確立されたペアリングは、アクセサリ及びコントローラが、それらが受信する長期公開キーを永続的記憶装置(例えば、不揮発性メモリ、磁気ディスクなど)内に記憶することができるという点で、永続的な状態とすることができ、この永続的記憶装置は、セキュア要素内に存在し得る。一部の実施形態では、アクセサリが、1つのコントローラとペア設定を実行した後では、そのアクセサリは、あらゆる他のコントローラがペア設定を実行することを、例えば、ペア設定を開始するあらゆる受信要求に、エラーメッセージで応答することによって、防ぐことができる。アクセサリとペア設定を実行したコントローラは、そのアクセサリに関する「管理者」に指定することができ、例えば、以下で説明されるようなペア追加プロセスを使用して、そのアクセサリに、他のコントローラとのペアリングを確立するように命令することを、許容される場合がある。
一部の実施形態では、アクセサリは、複数のコントローラと、同時にペアリングを確立することができ、各ペアリングは、ペア設定、ペア追加(以下で説明)などを使用して確立することができる。例えば、アクセサリは、ペアリングを確立した各コントローラの識別子及び関連するLTPKCを含む、ルックアップテーブル若しくは他のデータ構造を、永続的に記憶することができる。このデータ構造はまた、そのコントローラについての他の情報も含み得る。例えば、異なるコントローラには、そのアクセサリに対する異なる程度の制御(許可と称されるもの)を付与することができ、そのアクセサリによって保持されるデータ構造は、いずれの許可を各コントローラが有するかを指定する、標識(例えば、フラグ)を含み得る。様々な許可を定義することができる。定義することが可能な1つの許可は、「管理者」許可であり、一部の実施形態では、管理者許可を有するコントローラのみが、そのアクセサリに、他のコントローラに関するペアリングレコードを(例えば、以下で説明されるようなペア追加プロセスを使用して)追加することができる。一部の実施形態では、ペア設定の実行が成功したコントローラには、管理者許可を自動的に付与することができる。他のコントローラには、ペア追加の間に、選択的に(例えば、以下で説明されるように)管理者許可を付与することができる。
同様に、コントローラは、複数のアクセサリと、同時にペアリングを確立することができる。例えば、コントローラは、複数のアクセサリとペア設定を実行することができ、又は一部の場合には、コントローラは、以下で説明されるようなペア追加プロセスを介して、アクセサリとのペアリングを追加することができる。コントローラは、そのコントローラがペアリングを確立した各アクセサリの識別子及び関連するLTPKAを含む、ルックアップテーブル若しくは他のデータ構造を、永続的に記憶することができる。このデータ構造はまた、コントローラが、そのアクセサリに関していずれの許可を有するかなどの、情報も含み得る。
ペアリングを確立したコントローラ及びアクセサリは、その後は、互いに継続的な通信を維持しない場合があることが想到される。例えば、アクセサリ又はコントローラは、電源がオフになる場合があり、又は、一方のデバイスが、もう一方のデバイスの範囲外に移動される場合もある。互いにペアリングを確立したコントローラ及びアクセサリが、通信可能状態に戻る場合、再びペア設定を実行する代わりに、それらのデバイスは、異なるプロセス(本明細書では、ペア検証と称されるもの)を使用して、以前に確立されたペアリングの存在を検証することができる。ペア検証は、以前に(例えば、ペア設定又はペア追加の間に)作成され記憶された、長期公開キーレコードを使用することができる。ペア検証プロセスはまた、それらのデバイスがペア検証済み状態に維持されている限りは、後続のメッセージを暗号化するために使用することが可能な、新たな共有シークレット及び/又はセッションキーを生成することもできる。ペア検証済み状態(本明細書では、ペア検証済みセッションとも称されるもの)は、いずれかのデバイスによって、例えば、それ自体のセッションキーのコピーを削除することにより、他方のデバイスからの今後のメッセージの復号を不可能にさせることによって、終了させることができる。一部の実施形態では、ペア検証は、コントローラが、ペアリングを確立したアクセサリとの、統一的アクセサリプロトコル通信のためのチャネルを開くことを試みるたびに、実行することができる。
図17A〜図17Cは、本発明の実施形態による、コントローラ1702とアクセサリ1704との間のペア検証プロセス1700の実施例を示す。プロセス1700は、ペア検証が適切なアクションであることを、コントローラ1702が判定する場合に、例えば、コントローラ1702が、アクセサリ1704上での何らかの動作を制御する、ユーザ命令を受信し、かつ、ペア検証済みセッションが現在、コントローラ1702とアクセサリ1704との間に存在しない場合に、又は、コントローラ1702が、アクセサリ1704と再接続する場合に、開始することができる。
図17Aを参照すると、ブロック1706で、コントローラ1704は、例えば上述のようなCurve25519アルゴリズムを使用して、新たな短期キーペア(pkC、skC)を生成することができる。ブロック1708で、コントローラ1704は、アクセサリ1704に、ペア検証開始要求を送信することができ、この要求は、短期公開キーpkC(及び、任意選択的に、ペアリングが確立された際にアクセサリ1704に提供された、コントローラID若しくはコントローラのユーザ名userCなどの、追加的情報)を含み得る。一部の実施形態では、このペア検証開始要求は、アクセサリの/pair−verifyのURLへの、HTTP POST要求として送信することができる。一部の実施形態では、ペア検証開始状態をコントローラ1704が要求していることを示すように、図12のPairing State Request特性1201に、状態標識を書き込むことができる。
ブロック1710で、アクセサリ1704は、ペア検証開始要求を受信することができ、そのペアリング済みコントローラのリスト内で、長期公開キー(LTPKC)を検索することができる。一部の実施形態では、この検索は、セキュア要素内で実行することができ、アクセサリ1704の他の論理構成要素は、その検索が成功したか否かを、単に知ることができる。上述のように、コントローラID(又は、ユーザ名userC)をLTPKCと関連付けるペアリングレコードは、ペアリングが確立される場合、永続的に記憶することができるため、ブロック1710により、アクセサリ1704は、コントローラ1702と既にペアリングが確立されているか否かを判定することが可能となり得る。
ブロック1712で、コントローラ1702とのペアリングが、未だ確立されていない場合には、アクセサリ1704は、ブロック1714でエラーメッセージを送信することができる。ブロック1716で、コントローラ1702が、そのエラーメッセージを受信した場合には、プロセス1700は、ブロック1718で終了することができ、コントローラ1702は、ユーザにエラーを報告することができる。
アクセサリ1704が、コントローラ1702との確立済みペアリングを有すると判定する場合には、ブロック1720で、アクセサリ1704は、例えばCurve25519アルゴリズムを使用して、短期公開/秘密キーペア(pkA、skA)を生成することができる。ブロック1722で、アクセサリ1704は、skA及びpkCを使用して、共有シークレット(「inputKey」)を生成することができる。ブロック1724で、アクセサリ1704は、対称キー(「Key」)を導出することができる。例えば、アクセサリ1704は、inputKey、ソルト(例えば、ペア設定で使用されたソルトとは異なるものとすることが可能な、既定の文字列)、及び追加的情報を入力として使用して、HDKF−SHA−512を使用することができる。
ブロック1726で、アクセサリ1704は、アクセサリ情報メッセージを生成して、署名することができる例えば、アクセサリ1704は、pkAとpkCとを連結して、アクセサリの長期秘密キー(LTSKA)で、その連結に署名することができる。アクセサリIDなどの追加的情報もまた、連結することができる。ブロック1728で、アクセサリ1704は、対称キーKeyを使用して、この署名付きメッセージを暗号化することにより、アクセサリ証明(proofA)及び認証タグ(authTagA)を生成することができる。ブロック1730で、アクセサリ1704は、コントローラ1702に、ペア検証開始応答を送信することができる。この応答は、proofA、認証タグ、及び短期公開キーpkAを含み得る。アクセサリ識別子又はユーザ名(ペアリングが確立された際に、コントローラに与えられたアクセサリ名とすることが可能な、「userA」)などの他の情報もまた、含めることができる。この応答をブロック1730で送信すると、アクセサリ1704は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1732で、この応答を受信した後、コントローラ1702は、そのペアリング済みアクセサリのリスト内で、例えばアクセサリID又はアクセサリのユーザ名に基づいて、長期公開キー(LTPKA)を検索することができる。一部の実施形態では、この検索は、セキュア要素内で実行することができ、コントローラ1702の他の論理構成要素は、その検索が成功したか否かを、単に知ることができる。上述のように、アクセサリID(又は、ユーザ名userA)をLTPKAと関連付けるペアリングレコードは、ペアリングが確立される場合、永続的に記憶することができるため、ブロック1732により、コントローラ1702は、アクセサリ1704と既にペアリングが確立されているか否かを判定することが可能となり得る。
図17Bを参照すると、ブロック1734で、アクセサリ1704とのペアリングが未だ確立されていない場合には、プロセス1700は、ブロック1736で終了することができ、コントローラ1702は、ユーザにエラーを報告することができる。一部の実施形態では、コントローラ1702は、アクセサリ1704との確立済みペアリングを示す、記憶されたレコードを有するか否かを、プロセス1700を開始する前に判定することができ、ブロック1734での、この更なる確認を省略することができる。
コントローラ1702が、アクセサリ1704との確立済みペアリングを有すると判定した場合には、ブロック1738で、コントローラ1702は、skC及びpkAを使用して、共有シークレット(「inputKey」)を生成することができる。ブロック1740で、コントローラ1702は、対称キー(「Key」)を導出することができる。例えば、コントローラ1702は、inputKey、ソルト、及び追加的情報項目を入力として使用して、HDKF−SHA−512を使用することができる。一部の実施形態では、これらのソルト及び追加的情報項目は、ペア設定の間に使用された既定の値とは異なる、既定の値を有し得る。エラーが発生しなかった場合には、ブロック1740で導出されるKeyは、ブロック1724でアクセサリ1704によって導出されたKeyと合致するはずである。
ブロック1742で、コントローラ1702は、受信したproofAを、対称キーKeyを使用して復号することができ、また、authTagAを検証することもできる。ブロック1744で、コントローラ1702は、proofAから抽出された署名付きアクセサリ情報メッセージ上の、アクセサリの署名を検証することができる。この検証は、アクセサリ1704との確立済みペアリングからの、記憶されたLTPKAを使用することができる。成功した場合には、この検証により、(他のアクセサリが、同じ長期キーペアを有さないという前提の下で)アクセサリ1704が、以前にLTPKAを提供したアクセサリと同じものであることが確認される。ブロック1746で、authTagA又は署名が検証されない場合には(又は、復号が失敗した場合には)、プロセス1700は、ブロック1748で終了することができ、コントローラ1702は、ユーザにエラーを報告することができる。
図17Cを参照すると、検証がブロック1746で成功した場合には、ブロック1750で、コントローラ1702は、コントローラ情報メッセージを生成して署名することができる。例えば、コントローラ1702は、pkCとpkAとを連結して(この実施例での順序は、ブロック1724での連結とは逆である)、コントローラの長期秘密キーで、その連結に署名することができる。コントローラIDなどの追加的情報もまた、連結することができる。ブロック1752で、コントローラ1702は、対称キーKeyを使用して、この署名付きメッセージを暗号化することにより、コントローラ証明(proofC)及び認証タグ(authTagC)を生成することができる。ブロック1754で、コントローラ1702は、アクセサリ1704に、検証終了要求を送信することができる。この要求は、proofC及びauthTagCを含み得る。この要求をブロック1754で送信すると、コントローラ1702は、そのコントローラの証明が送信されたことを示すように、ペアリング状態を更新することができる。
ブロック1756で、アクセサリ1704は、検証終了要求を受信することができ、その受信したproofCを、対称キーKeyを使用して復号し、authTagCを検証することができる。ブロック1758で、アクセサリ1704は、proofCから抽出された署名付きコントローラ情報メッセージ上の、コントローラの署名を検証することができる。この検証は、コントローラ1702との確立済みペアリングからの、記憶されたLTPKCを使用することができる。成功した場合には、この検証により、(他のコントローラが、同じ長期キーペアを有さないという前提の下で)コントローラ1702が、以前にLTPKCを提供したコントローラと同じものであることが確認される。ブロック1760で、authTagC又は署名が検証されない場合には(又は、復号が失敗した場合には)、アクセサリ1704は、ブロック1762で、コントローラ1702にエラー応答を送信することができる。検証が成功した場合には、アクセサリ1704は、ブロック1764で、コントローラ1702に成功応答を送信することができる。いずれの場合にも、応答を送信すると、アクセサリ1704は、その適切な応答を示すように、ペアリング状態を更新することができる。
ブロック1766で、コントローラ1702は、いずれの応答が受信されたかを判定することができる。エラーメッセージ1762が受信された場合には、プロセス1700は、ブロック1768で終了することができ、コントローラ1702は、ユーザにエラーを報告することができる。成功メッセージ1764が受信された場合には、ペア検証は、ブロック1770で完了し、そのことを示すようにペアリング状態を更新することができる。
プロセス1700は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1700は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。
プロセス1700は、ペアリングが確立された際に長期公開キーが交換された(例えば、ペア設定又はペア追加プロセスが使用された)方式とは、独立したものであることにもまた留意されたい。アクセサリ及びコントローラは、各デバイスが他方の長期公開キーを有し、それらの長期公開キーを(例えば、各デバイスのセキュア要素内に)常に記憶したまま維持することができる限り、ペア検証をすることができる。
更には、アクセサリ及びコントローラに関連付けられたユーザ名(「userA」及び「userC」)は、ペア検証の間に、他方のデバイスが長期公開キーを検索することを可能にする、任意の情報を含み得る。この情報は、実際のユーザの名前又は他の識別子を含み得るが、これは必須ではない。一部の実施形態では、ユーザ名は、特定の長期公開キーが属するデバイスの、デバイス識別子を組み込むことができる(又は、そのデバイス識別子とすることができる)。
上述の様々なペア設定プロセスと同様に、ペア検証プロセス1700は、新たな暗号キー(Key)を生成することを含み得る。一部の実施形態では、このキーは、ペア検証プロセス1700の完了後に続けて送信される、いずれか又は全てのメッセージ(例えば、上述のような要求及び応答)を暗号化するための、セッションキーとして使用することができる。このセッションキーは、いずれかのデバイスが、そのデバイスのセッションキーのコピーを削除するか又は無効化するまで、存続し得る。それゆえ、いずれかのデバイスは、そのデバイス自体のセッションキーのコピーを削除するか又は無効化することによって、任意の時点で、他方との通信を一方的に切断することができる。例えば、アクセサリは、コントローラが近接閾値の外側に移動するか、若しくはアクセサリとの接続性を喪失する場合には、又は、タイムアウト期間内に、若しくはセッション持続時間の一定の上限値(アクセサリ製造元又はプログラマが選択して作成するものと同じ短さ若しくは長さとすることが可能なもの)の後に、通信が実施されない場合には、セッションキーを削除することができる。このことにより、アクセサリは、コントローラのアクセスを、必要に応じて制限することが可能となる。
一部の実施形態では、ペア検証プロセス1700の間に導出される暗号キーは、プロセス1700の間にのみ使用される。ペア検証済みセッション内での後続の通信に関しては、コントローラ1702及びアクセサリ1704は、それぞれ、1つ以上の新たなセッションキーを計算することができる。例えば、アクセサリからコントローラへのセッションキー(「ACセッションキー」)は、制御ソルト及び追加的情報項目(既定の定数値とすることが可能なもの)と共に、ペア検証の間に(例えば、プロセス1700のブロック1722及び1738で)生成された共有シークレット(inputKey)に、HKDF−SHA−512(又は、同様のアルゴリズム)を適用することによって、導出することができる。例えば、コントローラからアクセサリへのセッションキー(「CAセッションキー」)は、別の制御ソルト及び追加的情報項目(同じく、既定の定数値とすることが可能なもの)と共に、ペア検証の間に生成された共有シークレット(inputKey)に、HKDF−SHA−512(又は、同様のアルゴリズム)を適用することによって、導出することができる。一部の実施形態では、異なる制御ソルト及び/又は異なる追加的情報項目を使用して、ACセッションキー及びCAセッションキーを生成することができるため、それらの2つのセッションキーは、同じである必要はない。コントローラ及びアクセサリは、それぞれ、ACセッションキー及びCAセッションキーの双方を生成することができる。ペア検証済みセッション内での後続の通信の間、ACセッションキーは、アクセサリによって、コントローラに送信するメッセージを暗号化するために、かつコントローラによって、アクセサリから受信するメッセージを復号するために使用することができ、その一方で、CAセッションキーは、コントローラによって、アクセサリに送信するメッセージを暗号化するために、かつアクセサリによって、コントローラから受信するメッセージを復号するために使用することができる。いずれかのデバイスは、そのセッションキーを無効化すること(例えば、そのセッションキーを削除するか、又は、そのセッションキーを使用して暗号化されている任意の受信メッセージに、エラーで応答すること)によって、セッションを終了することができる。
更には、一部の実施形態では、単一のコントローラが、複数の長期キーペア(LTPKC、LTSKC)を定義して使用することができる。例えば、複数の認可ユーザを有するコントローラ(例えば、共用コンピュータ)は、異なるユーザが、異なるアクセサリのサブセットと対話することができるように、各認可ユーザに関して、異なる長期キーペアを有し得る。コントローラが、各キーペアに関して別個のユーザ名を有する限り、アクセサリは、そのコントローラが2つ以上のキーペアを有することを認識する必要はない。別の例として、コントローラは、異なるアクセサリとペアリングを確立するために、異なる長期キーペアを使用することができる。複数の長期キーペアを使用するコントローラは、ペアリングが確立されている各アクセサリに関して、いずれの(LTPKC、LTSKC)ペアが使用されたかを、追跡することができる。同様に、アクセサリは、複数の長期キーペア(LTPKA、LTSKA)を有することが可能であり、ペアリングが確立されている各コントローラに関して、いずれのペアが使用されたかを、追跡することができる。一部の実施形態では、デバイスは、特定の長期公開キーを与える他のデバイスの数を制限することができ、複数の長期公開キーを有することにより、そのデバイスは、異なるキーに随時切り替えることが可能となり得る。
一部の実施形態では、長期公開キー(又は、一部の場合には、証明書)は、「ペア追加」と称することが可能なプロセス、すなわちペアを追加することが可能なプロセスで、ペア設定又はペア検証後の任意の時点で、デバイス間で交換することができる。例えば、上述のように、アクセサリは、1つのコントローラ(そのアクセサリに関する「管理者」又は「アドミン」と称することが可能なもの)とペア設定を実行するように、そのアクセサリ自体を制限することができ、最初に成功したペア設定の後は(例えば以下で説明されるように、少なくとも、そのペアリングが除去されるまでは)、全ての後続のペア設定要求を拒否することができる。他のコントローラが、そのアクセサリと対話することを可能にするために、アドミンコントローラは、ペア追加プロセスを実行することにより、そのアクセサリと、異なるコントローラとの間に(又は、一部の場合には、そのアクセサリと、同じコントローラの異なる長期公開キーとの間に)、ペアリングを確立することができる。
図18A〜図18Bは、本発明の実施形態による、コントローラ1802(例えば、管理者許可を有するコントローラ)とアクセサリ1804との間の、ペア追加プロセス1800の実施例を示す。このプロセスでは、コントローラ1802は、以前に、アクセサリ1804とペア設定を実行している(また、それにより管理者許可を取得している)か、又は、ペア追加プロセス1800を実行する、以前のインスタンスを介して、管理者として追加されていることが想定される。
最初に図18Aを参照すると、ブロック1806及び1808で、コントローラ1802及びアクセサリ1804は、ペア検証プロセス(例えば、プロセス1700)を完了することにより、共有シークレット及びセッションキー(単数又は複数)(例えば、上述のようなACキー及びCAキー)を確立することができる。
ブロック1810で、コントローラ1802は、アクセサリ1804と交換するための長期公開キー(LTPKN)を特定することができる。このキーは、例えば、ペアリングが確立されることになるコントローラ(本明細書では、「新規」コントローラとも称されるもの)に属する、長期公開キーとすることができ、このコントローラは、コントローラ1802以外のコントローラとすることができる。一部の実施形態では、その新規コントローラに関する、セキュリティ証明書(長期公開キーを含み得るもの)を取得することができる。ブロック1812で、コントローラ1802は、データブロックを生成することができ、このデータブロックは、そのデータブロックが、ペアリングを追加する要求に関するものであることの指標と、長期公開キーLTPKNと、新規コントローラのコントローラ識別子と、新規コントローラに付与されることになる許可を示す、許可情報(例えば、フラグ)とを含む。例えば、上述のように、アクセサリとペア設定を実行する最初のコントローラを、そのアクセサリに関する管理者として、自動的に指定することができる。ペア追加プロセス1800を介して追加される各新規コントローラに関して、許可情報は、その新規コントローラもまた管理者として指定するべきか否かを、指定することができる。一部の実施形態では、アクセサリに関する管理者は、そのアクセサリに関するペア追加を実行することが許可されるが、管理者ではないコントローラは、ペア追加を実行することを許可されない。
ブロック1814で、コントローラ1802は、アクセサリ1804に、ペア追加開始要求を送信することができ、この要求は、ブロック1812で生成されたデータブロックを含み得る。ペア検証済みセッション内での全ての通信と同様に、この要求は、適切なセッションキーを使用して暗号化することができる。一部の実施形態では、このペア追加開始要求は、そのペア追加開始要求を特定する状態標識を含み得る(この状態標識及び後続の状態標識は、図12のPairing State Request特性1201に書き込むことができる)。一部の実施形態では、このペア追加開始要求は、アクセサリ1804の/pairingsのURL(又は、他の適切なURL)への、HTTP POST要求として送信することができる。
ブロック1816で、アクセサリ1804は、そのペア追加開始要求を受信することができる。ペア検証済みセッションでの、コントローラからの任意の受信要求と同様に、アクセサリ1804は、適切なセッションキーを使用して、その要求を復号することから開始することができ、復号が失敗した場合には、アクセサリ1804は、エラー応答を返す(又は、全く応答しない)ことが可能である。ブロック1818で、アクセサリ1804は、コントローラ1802が、ペア追加を実行することを許可されているか否かを判定することができる。例えば、上述のように、コントローラには、選択的に管理者許可を付与することができ、ペア追加は、管理者許可を有するコントローラに限定することができる。別の実施例として、ユーザインタフェースを有するアクセサリは、ペア追加要求を許可するべきか否かを示すように、ユーザに促すことができる。更に別の実施例として、上述のように、一部の場合には、ユーザは、機械的操作を介して、アクセサリをペアリングモードにすることができ、一部のアクセサリは、ペアリングモードにある間にのみ、ペア追加要求を許可するように構成することができる。更に別の実施例として、一部の実施形態では、アクセサリ1804は、同時に記憶することが可能なペアリングの数に対する上限値(例えば、16のペアリング、32のペアリング、又は何らかの他の限界値)を有し得るものであり、アクセサリ1804は、この限界値を超過する結果となる場合には、ペア追加要求を不許可として取り扱うことができる。特定のペア追加要求をアクセサリ1804が許可するべきか否かを判定する、他の技術もまた使用することができる。要求が許可されない場合には、アクセサリ1804は、ブロック1820でエラーメッセージを送信することができる。
図18Bを参照すると、ペア追加要求が許可された場合には、ブロック1832で、アクセサリ1804は、受信したメッセージに基づく新たなペアリングを、永続的に(例えば、そのセキュア要素内に)記憶することができる。例えば、アクセサリ1804は、新規コントローラに関する、受信したコントローラ識別子及び許可と関連させて、受信した長期公開キーLTPKNを記憶することができる。
一部の実施形態では、アクセサリ1804は、プロセス1800の間、コントローラ1802に長期公開キー(LTPKA)を提供する必要はないが、これは、コントローラ1802が、プロセス1800を開始する前に、その長期公開キーを受信しているためである。しかしながら、他の実施形態では、アクセサリ1804は、異なるコントローラでは異なる長期公開キーを使用することが望ましい場合がある。このことが当てはまる場合、アクセサリ1804は、その新規コントローラによって使用されるべき長期公開キーを含む、データブロックを準備することができる。例えば、ブロック1834で、アクセサリ1804は、新規コントローラによって使用されることになる長期公開キーを特定することができ、この長期公開キーは、以前にコントローラ1802に提供された長期公開キー(LTPKA)と同じものか、又は異なるものとすることができる。ブロック1836で、アクセサリ1804は、ブロック1834で特定された長期公開キーと、新規コントローラによって使用されることになるアクセサリ識別子(以前にコントローラ1802に提供されたアクセサリ識別子と同じものか、又は異なるものとすることが可能なもの)とを含む、データブロックを生成することができる。
ブロック1838で、アクセサリ1804は、コントローラ1802に、ペア追加応答を送信することができる。データブロックが、ブロック1836で生成された場合には、そのデータブロックを、ペア追加応答内に含めることができる。ペア検証済みセッション内での全ての通信と同様に、この応答は、適切なセッションキーを使用して暗号化することができる。ペア追加応答は、そのペア追加応答が送信されたことを示すように、状態標識を更新することを含み得る。
ブロック1840で、コントローラ1802は、このペア追加応答を受信することができる。ペア検証済みセッションでの、アクセサリからの任意の受信応答と同様に、コントローラ1802は、適切なセッションキーを使用して、その応答を復号することから開始することができ、復号が失敗した場合には、その応答を無視することができ、プロセス1800はエラーで終了することができる。
ブロック1844で、コントローラ1802は、その応答が成功を示すものか否かを判定することができる。成功を示すものではない場合には、プロセス1800は、ブロック1846で終了することができ、コントローラ1802は、ユーザにエラーを通知することができる。応答が成功を示すものである場合には、ブロック1848で、コントローラ1802は、新規コントローラに、このペアリングを通知することができる。例えば、コントローラ1802は、新規コントローラに、アクセサリ1804に関する、アクセサリ識別子及び長期公開キーLTPKAを通信することができる。一部の実施形態では、コントローラ1802は、アクセサリ1804に関する、以前に記憶されたLTPKA及びアクセサリ識別子を、新規コントローラに提供することができ、他の実施形態では、コントローラ1802は、ペア追加応答内でアクセサリ1804によって提供された情報を、新規コントローラに提供することができる。新規コントローラは、受信したLTPKA及びアクセサリ識別子を、ペアリングレコードとして永続的に記憶することができる。その後は、新規コントローラは、アクセサリ1804と(コントローラ1802の更なる関与を伴うことなく)ペア検証プロセス(例えば、プロセス1700)を実行することができ、アクセサリ1804と対話することができる。
プロセス1800は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1800は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。一部の実施形態では、ペア追加プロセス1800は、以下で説明されるような、委譲ペアリングのモードとして使用することができる。
上述のように、ペア設定及びペア追加は、受信デバイスによって永続的かつ安全に記憶することが可能な、長期公開キーを交換することによって、アクセサリとコントローラとの間のペアリングが確立されることを可能にし得る。一部の場合には、例えば、永続的記憶装置から長期公開キーを除去することによって、確立済みペアリングを除去することが望ましい場合がある。したがって、本発明の特定の実施形態は、ペア除去プロセスを提供する。
図19A〜図19Bは、本発明の実施形態による、コントローラ1902(例えば、管理者許可を有するコントローラ)とアクセサリ1904との間の、ペア除去プロセス1900の実施例を示す。プロセス1900は、全般的にプロセス1800と同様とすることができるが、ただし、プロセス1900は、新たなペアリングを確立するのではなく、既存のペアリングを除去する結果をもたらす。このプロセスでは、コントローラ1902は、以前に、アクセサリ1904とペア設定を実行している(また、それにより管理者許可を取得している)か、又は、例えばペア追加プロセス1800の実行を介して、管理者として追加されていることが想定される。
図19Aを参照すると、ブロック1906及び1908で、コントローラ1902及びアクセサリ1904は、ペア検証プロセス(例えば、プロセス1700)を完了することにより、共有シークレット及びセッションキー(単数又は複数)(例えば、上述のようなACキー及びCAキー)を確立することができる。
ブロック1910で、コントローラ1902は、除去されることになるコントローラの識別子を取得することができる。この識別子は、アクセサリ1804によって、ペアリングレコード内に記憶されている識別子とすることができる。一部の場合には、この識別子は、コントローラ1902自体の識別子とすることができ(コントローラは、それ自体のペアリングを除去することができる)、他の場合には、別のコントローラの識別子とすることができる。一部の場合には、ブロック1910は、この識別子に加えて、除去されるコントローラの長期公開キーを得ることを含み得る。ブロック1912で、コントローラ1902は、データブロックを生成することができ、このデータブロックは、そのデータブロックが、ペアリングを除去する要求に関するものであることの指標と、ペアリングが除去されることになるコントローラの識別子とを含む。一部の実施形態では、このデータブロックは、除去されるコントローラの長期公開キーなどの、他の情報を含み得る。
ブロック1914で、コントローラ1902は、アクセサリ1904に、ペア除去開始要求を送信することができ、この要求は、ブロック1912で生成されたデータブロックを含み得る。ペア検証済みセッション内での全ての通信と同様に、この要求は、適切なセッションキーを使用して暗号化することができる。一部の実施形態では、このペア除去開始要求は、そのペア開始要求が送信されたことを示す除去状態標識を含み得る(この状態標識及び後続の状態標識は、図12のPairing State Request特性1201に書き込むことができる)。一部の実施形態では、このペア除去開始要求は、アクセサリ1904の/pairingsのURL(又は、他の適切なURL)への、HTTP POST要求として送信することができる。
ブロック1916で、アクセサリ1904は、そのペア除去開始要求を受信することができる。ペア検証済みセッションでの、コントローラからの任意の受信要求と同様に、アクセサリ1904は、適切なセッションキーを使用して、その要求を復号することから開始することができ、復号が失敗した場合には、アクセサリ1904は、エラー応答を返す(又は、全く応答しない)ことが可能である。ブロック1918で、アクセサリ1904は、コントローラ1902が、ペア除去を実行することを許可されているか否かを判定することができる。例えば、上述のように、コントローラには、選択的に管理者許可を付与することができ、ペア除去は、管理者許可を有するコントローラに限定することができる。別の実施例として、ユーザインタフェースを有するアクセサリは、ペア除去要求を許可するべきか否かを示すように、ユーザに促すことができる。更に別の実施例として、上述のように、一部の場合には、ユーザは、機械的操作を介して、アクセサリをペアリングモードにすることができ、一部のアクセサリは、ペアリングモードにある間にのみ、ペア除去要求を許可するように構成することができる。特定のペア除去要求をアクセサリ1904が許可するべきか否かを判定する、他の技術もまた使用することができる。要求が許可されない場合には、アクセサリ1904は、ブロック1920でエラーメッセージを送信することができる。
図19Bを参照すると、ペア除去要求が許可された場合には、ブロック1932で、アクセサリ1904は、その確立済みペアリングのリストから、受信したデータブロック内で指定されたコントローラとのペアリングを、(例えば、そのペアリングレコードをセキュア記憶要素から削除することによって)除去することができる。
一部の実施形態では、アクセサリ1904は、プロセス1900の間、長期公開キー(LTPKA)を除去する、相互的な命令を提供する必要はない。アクセサリ1904が、ペアリングレコードを除去した後、除去されたコントローラは、アクセサリ1904とのペア検証を実行することが不可能となり、このことにより、除去されたコントローラもまた、そのペアリングレコードを除去するか否かに関わりなく、除去されたコントローラがアクセサリ1904と対話することを防ぐことができる。しかしながら、他の実施形態では、除去されることになるペアリングを、アクセサリ1904が指定することが望ましい場合がある。このことが当てはまる場合、アクセサリ1904は、その新たに除去されるコントローラによって除去されるべき長期公開キー及びアクセサリ識別子を含む、データブロックを準備することができる。例えば、ブロック1934で、アクセサリ1904は、新たに除去されるコントローラから除去するべき、長期公開キーを特定することができ、この長期公開キーは、例えば、そのコントローラが追加された際に、プロセス1800のブロック1834で特定されたキーとすることができる。ブロック1936で、アクセサリ1904は、ブロック1934で特定された長期公開キーと、この長期公開キーに関連付けられたアクセサリ識別子とを含む、データブロックを生成することができる。
ブロック1938で、アクセサリ1904は、コントローラ1902に、ペア除去応答を送信することができる。データブロックが、ブロック1936で生成された場合には、そのデータブロックを、ペア除去応答内に含めることができる。ペア検証済みセッション内での全ての他の通信と同様に、この応答は、適切なセッションキーを使用して暗号化することができる。ペア除去応答は、そのペア除去応答が送信されたことを示すように、状態標識を更新することを含み得る。
ブロック1940で、コントローラ1902は、このペア除去応答を受信することができる。ペア検証済みセッションでの、アクセサリからの任意の受信応答と同様に、コントローラ1902は、適切なセッションキーを使用して、その応答を復号することから開始することができ、復号が失敗した場合には、その応答を無視することができ、プロセス1900はエラーで終了することができる。
ブロック1944で、コントローラ1902は、その応答が成功を示すものか否かを判定することができる。成功を示すものではない場合には、プロセス1900はブロック1946で終了することができ、コントローラ1902はユーザにエラーを通知することができる。応答が成功を示すものである場合には、ブロック1948で、コントローラ1902は、除去されたコントローラに、そのペアリングが除去されたことを通知することができる。一部の実施形態では、コントローラ1902はまた、除去されたコントローラに、アクセサリ1904に関するアクセサリ識別子及び/又は長期公開キーLTPKAを通信することもできる。その後は、除去されたコントローラは、もはやアクセサリ1904とペア検証プロセスを実行することが不可能となり、このことは、除去されたコントローラが、アクセサリ1904と対話することが不可能となる結果をもたらし得る。プロセス1900を介して除去されたコントローラは、その後に、ペア追加プロセス1800を介して再び追加することができる。一部の実施形態は、アクセサリ1904が、除去されたコントローラを「ブラックリストに載せる」選択肢を提供することができ、このことにより、除去されたコントローラがアクセサリ1904とペアリングを確立することを防ぐことができる。例えば、コントローラ1902からのペア除去要求は、除去されたコントローラをブラックリストに載せるべきか否かに関する、指標を含み得るものであり、アクセサリ1904は、ブラックリストに載せられたコントローラのリストを、永続的に記憶することができる。ペア設定又はペア追加の間に、アクセサリ1904は、このブラックリストを確認することができ、ブラックリスト上にコントローラが存在する場合には、エラーを返すことができる。
プロセス1900は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に(例えば、ペアリングプロセスの状態が変化する場合に)、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス1900は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び/又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のパスワードプロトコル及びアルゴリズムで置き換えることもできる。一部の実施形態では、ペア除去プロセス1900は、以下で説明されるような、委譲ペアリングに関連して使用することができる。
上述の実施形態は、アクセサリ及びコントローラが、ペアリングを作成(設定)、検証、追加、及び除去することを可能にするものであり、ペアリングは、そのペアリングでの各パートナーデバイスによる、他方のパートナーデバイスの長期公開キー及び/又は証明書の永続的記憶を含み得る。
一部の実施形態では、ユーザが、所定のアクセサリとペアリングされたコントローラのリスト、又は所定のコントローラとペアリングされたアクセサリのリストを取得することが有用であり得る。後者(コントローラとペアリングされたアクセサリ)の場合には、コントローラ上で実行されるプログラム(例えば、オペレーティングシステム又はアプリケーションプログラム)が、そのコントローラの記憶されたペアリング情報を読み取ることによってリストを生成することができ、そのコントローラ自体のユーザインタフェース上で、そのリストをユーザに提示することができる。所定のアクセサリとペアリングされたコントローラのリストを提供するために、特定の実施形態は、コントローラが、アクセサリから、全てのペアリング済みコントローラのリストを取得することを可能にし、次いで、コントローラは、そのリストをユーザに提示することができる。
例えば、図12に示されるように、アクセサリは、そのペアリングプロファイルの一部として、Pairing List特性1204を有し得る。特性1204は、そのアクセサリとの確立済みペアリングを有する、各コントローラについての情報(例えば、コントローラIDなど)を含み得るが、いずれのコントローラの長期公開キーも含む必要はない。一部の実施形態では、コントローラは、任意の他の特性と同様に、例えばHTTP GET要求などを使用して、Pairing List特性1204を読み取ることができる。一部の実施形態では、コントローラは、アクセサリの/pairingsのURL(又は、他の適切なURL)に、HTTP POST要求を送信することによって、アクセサリのペアリングリストを取得することができ、このPOST要求は、ペアリングリストが要求されていることを示す項目を含み得る。
一部の実施形態では、コントローラは、アクセサリ応答を暗号化することができるように、ペア検証済みセッション内でのみ、Pairing List1204を読み取ることを許容される場合がある。更には、一部の実施形態では、Pairing List1204の読み取りは、管理者許可を有するコントローラに限定することができる。
一部の実施形態では、アクセサリは、一度に1つのコントローラとのみ、ペアリングを確立することができ、ペアリングを確立するコントローラのみが、そのペアリングを後に除去することを許可される。このことにより、セキュリティを向上させることができる。しかしながら、一部の用途では、不都合な方式で制限的となる恐れがある。例えば、家庭環境100(図1)の場合では、その家庭内に複数の人々が居住している場合には、各自が、ドアロック104をロック解除することが可能なコントローラ102(例えば、携帯電話)を有することが望ましい場合がある。
したがって、本発明の特定の実施形態は、複数のコントローラとのペアリングを、アクセサリが同時に維持することを可能にし得る。例えば、各コントローラは、上述のペア設定プロセスを使用して、別個にペアリングを確立することができる。しかしながら、コントローラが独立してペアリングを確立することを可能にすることは、一部の用途に関しては、セキュリティが不十分となる恐れがある。例えば、家庭の玄関ドアのロックの場合には、家の所有者は、その家の所有者の明示的な許可なくして、他人がペアリングを確立することを、防止することを望む場合がある。
管理されたペアリングを可能にするために、特定の実施形態は、「委譲」ペアリングプロセスを提供することができる。委譲ペアリングプロセスでは、第1の(「アドミン」又は「マスタ」)コントローラが、例えば上述のようなペア設定を使用して、アクセサリとペアリングを確立することにより、管理者許可を取得することができる。その後は、アドミンコントローラは、任意の後続の(「委譲」)コントローラに関するペア設定プロセスに参加することを、要求される場合がある。
委譲ペアリングの1つのタイプは、「直接的」委譲とすることができる。直接的委譲では、マスタコントローラは、図18A〜図18Bのペア追加プロセス1800又は同様のプロセスを使用して、委譲コントローラに関するコントローラ公開キー(及び、コントローラのユーザ名)を、アクセサリに配信することができる。直接的委譲に関しては、マスタコントローラは、委譲コントローラと通信して、その委譲コントローラの長期公開キーを取得することができる。
委譲ペアリングの別のタイプは、「外部」又は「転送」委譲とすることができる。外部委譲では、アクセサリは、ペア設定及びペア検証を「認可者」デバイスに委譲するように構成することができ、この認可者デバイスは、マスタコントローラ内に、又はマスタコントローラと通信することが可能な何らかの他のデバイス内に組み込むことができる。認可者デバイスは、上述のようにアクセサリとペア設定を実行することができ、ペア設定の後、その認可者は、アクセサリへの安全なチャネルを維持する(又は、ペア検証を使用して再確立する)ことができる。アクセサリが、ペア設定又はペア検証要求を受信した場合には、アクセサリは、その安全なチャネルを介して、その要求を認可者に転送することができる。認可者は、その動作を実行することができ、かつ/又は、その動作を許容するべきか否かをアクセサリに示すことができる。
委譲ペアリングの第3のタイプは、「証明書ベースの」委譲とすることができる。証明書ベースの委譲では、マスタコントローラは、信頼証明書チェーンを使用して、アクセサリを構成することができる。例えば、マスタコントローラは、図18A〜図18Bのペア追加プロセス1800、又は同様のプロセスを使用して、アクセサリに、信頼証明書チェーンを安全に配信することができる。例えば、コントローラがアクセサリに送信する、「証明書チェーン設定要求」メッセージを定義することができる(このメッセージは、例えば、証明書チェーンを受信するために定義された特性又はURLへの、HTTP PUT要求とすることができる)。この要求メッセージのコンテンツは、例えばルートから最深までのサブ権限の順序で証明書チェーンを含む、TLV項目又は一連のTLV項目を含み得る。このTLV項目(単数又は複数)は、ペア検証の間に確立された対称キーで暗号化することができ、マスタコントローラの長期秘密キーLTSKCを使用して、デジタル署名することができる。アクセサリは、記憶されたLTPKCを使用して、その署名を検証し、対称キーを使用して、暗号化されたTLV項目(単数又は複数)を復号することにより、証明書チェーンを抽出することができる。一部の実施形態では、この証明書チェーンは、アクセサリのセキュア記憶要素内に記憶させることができる。アクセサリは、成功又は失敗を示す応答メッセージを送信することができる。
別のコントローラが、そのアクセサリとペア設定を実行することを試みる場合、そのコントローラには、その長期公開キーに加えて、又はその代わりに、証明書を提供するように要求することができる。アクセサリは、その証明書が、以前に受信した信頼証明書チェーンによって署名されているか否かを判定することができ、その証明書がそのように署名されているか否かに部分的に基づいて、ペア設定を受理するか、又は拒絶することができる。委譲コントローラは、何らかの他のチャネルを介して(例えば、マスタコントローラ、信頼される認証局などから)、適切に署名された証明書を取得し、それをアクセサリに提示することによって、そのアクセサリに関して認可されることが可能となる。
本明細書で説明されるペアリングプロセス及びアーキテクチャは、例示的なものであり、変型及び修正が可能であることが、当業者には理解されるであろう。異なる暗号化アルゴリズム、キー、及びプロトコルで置き換えることができ、複数の異なる暗号化アルゴリズム、キー、及びプロトコルを、所定の動作環境内で同時にサポートすることができる。
例示的アクセサリ:ドアロック
本発明の実施形態に存在し得る様々な態様及び特徴を更に示すために、ここで具体的なアクセサリの実施例を説明する。
第1の実施例は、ドアロックアクセサリであり、このドアロックアクセサリは、ドアに設置することが可能なドアロックに結合される、電子ロックユニットを含み得る。一部の実施形態では、ドアロック自体は、機械式ロック(例えば、デッドボルトタイプ)とすることができ、電子ロックユニットが、電気機械式アクチュエータを動作させることにより、ロック位置とロック解除位置との間で、この機械式ロックを移動させることができる。機械式ロックが現時点でロック位置又はロック解除位置のいずれにあるかを、電子ロックユニットが判定することを可能にするために、位置センサなどもまた提供することができる。他の実施形態では、他のタイプのドアロック、例えば、磁気ロック、電子ロック、並びに、電気制御信号を供給し、かつ/又は機械的な力を適用することによって、ロック及びロック解除することが可能な、任意の他のタイプのロックを使用することができる。電子ロックユニットは、上述のような統一的アクセサリプロトコルを実施する論理回路、及び1つ以上のコントローラと通信する通信回路を収容するか、若しくはそれらの回路に接続することができる。電子ロックユニットは、電気信号(例えば、1つ以上のワイヤ上の電圧又は電流レベル)を生成することにより、例えば電気機械式アクチュエータなどを介して、ドアロックを動作させることができる。一部の実施形態では、電子ロックユニット及びドアロックは、ドアに取り付けられるか、又はドア若しくはドアフレームの内側に取り付けられるモジュールなどの、共通の筐体の内部に物理的に配置することができる。他の実施形態では、電子ロックユニット及びドアロックは、別個の筐体内に存在し得る。例えばドアロックは、ドアの内側に存在し得るが、その一方で、電子ロックユニットは、近傍の壁面上に取り付けられる。ドアロック内のアクチュエータと電子ロックユニットとの間の、有線接続を提供することができる。無線接続もまた、本発明の範囲から逸脱することなく使用することができるが、このコンテキストでの無線接続は、更なるセキュリティ上の問題を生じさせる恐れがあることが、当業者には理解されるであろう。
図20を参照すると、本発明の実施形態による、ドアロックアクセサリ2004に関する動作環境2000が示されている。動作環境2000は、例えば、オフィスビル、家庭、アパート若しくはホテルの建物、又は、少なくとも1つの室内ドア若しくは外部ドア2006を有する任意の他の構造体内に、実装することができる。例示の目的上、ドア2006をロック及びロック解除する能力は、複数の個人に提供されることが望ましいと想定される。ドア2006は、「所有者」(すなわち、ドア2006を通過することを誰が許容されるべきか又は許容されないべきかを判定する権限を、法的に又は合意によって与えられている、何らかの人物若しくはエンティティ)を有することが、更に想定される。例えば、環境2000が、オフィスビル内に実装される場合には、そのビルの所有者(又は、その所有者の認可を得て行為するテナント)を、ドア2006の所有者とすることができる。環境2000が、家庭内に実装される場合には、その所有者は、家の所有者、世帯主、又は、居住者によって指定される他の個人とすることができる。
この実施例では、ドアロックアクセサリ2004は、1つ以上のユーザ操作コントローラ2012(3つが示されているが、任意の数を使用することが可能)と無線通信するように構成することができる。例えば、ドアロックアクセサリ2004は、コントローラ2012のうちの1つに対する物理的近接性によってトリガされることにより、通信を開始させることが可能な、センサ2020を提供することができる。ドアロックアクセサリ2004はまた、マスタコントローラ(管理者とも称されるもの)2018と通信することもできる。この実施例では、マスタコントローラ2018との通信は、無線接続によるものであるが、有線接続もまた使用することができる。
マスタコントローラ2018は、デスクトップコンピュータ、ラップトップコンピュータ、携帯電話、タブレットなどを含めた、ドア2006の所有者によって所有又は操作されるコンピューティングデバイスとすることができる。オフィスビルの場合には、マスタコントローラ2018を操作する人物を、指定のセキュリティ担当者とすることができる。マスタコントローラ2018は、ドア2006に対して任意の場所に、物理的に配置することができる。例えば、マスタコントローラ2018は、ドア2006がアクセスを提供する部屋の中、この建物内の他の場所に配置された警備室の中、又は全く別の建物内に存在し得る。一部の実施形態では、マスタコントローラ2018はまた、ユーザデバイス(例えば、携帯電話)としての役割も果たし得る。
ドアロックアクセサリ2004の設置に続けて、マスタコントローラ2018は、上述のようなペア設定プロセスを実行することにより、それ自体をマスタコントローラとして確立することができ、例えば、マスタコントローラ2018は、ペア設定の実行の結果として(例えば、上述のような)管理者許可を取得することができる。その後は、委譲ペアリング技術(例えば、上述のようなペア追加)を使用することにより、ドアロックアクセサリ2004と、ユーザデバイス2012のそれぞれとの間に、ペアリングを確立することができる。あるいは、ドアロックアクセサリ2004は、特定の物理的条件下(例えば、アクセサリ2004内にキーが物理的に挿入される)でのみ、ペア設定を実行することができるように構成することができ、ドアロックアクセサリ2004は、ペアリングに関する物理的条件が取得された場合に、一度にユーザデバイス2012のそれぞれと、ペア設定を実行することができる。
一部の実施形態では、ドアロックアクセサリ2004に関するアクセサリモデルは、ドアをロック及びロック解除する能力を提供する、ロックメカニズムサービス(例えば、図2GのLock Mechanismサービス254のインスタンス)を含み得る。ドアロックアクセサリ2004に関するアクセサリモデルはまた、ロック管理サービス(例えば、図2HのLock Managementサービス255のインスタンス)も含み得るものであり、このロック管理サービスは、いつ誰がドアをロック又はロック解除したかを示す入力を有する、ロックログを保持することなどの、他のロック関連機能をサポートすることができる。このロックログは、例えばマスタコントローラ2018によってアクセスすることができる。
図21は、本発明の実施形態による、ドアロックアクセサリ2004に関するアクセサリオブジェクト2100の実施例を示す。オブジェクト2100は、表の形態で示されているが、図3A〜図3Cと同様のJSONオブジェクトとして表すこともできる。図示のように、ドアロックアクセサリ2004は、アクセサリ識別サービスインスタンス2102、ロックメカニズムサービスインスタンス2104、及びロック管理サービスインスタンス2106を含み得る。各サービスインスタンスは、図示のような特性を含み得るものであり、これらの特性は、図2A〜図2D、及び図2Jに従って定義することができる。例えば、現在の状態特性2110は、そのドアが現在、ロックされているか又はロック解除されているか(又は、故障しているかなど)のいずれであるかを判定するために、コントローラによって読み取ることができ、目標状態特性2112は、そのドアのロック又はロック解除を要求するために、コントローラによって書き込むことができる。
ロックログ特性2116は、ロックログイベントレコードのアレイを含み得るものであり、各ロックログイベントレコードは、データオブジェクトとすることができる。この実施例では、各ロックログイベントレコードは、ドアロック2004にアクセスしたエンティティ(人物又はデバイス)の識別子、そのアクセスが実施された時間、及び実行された動作(例えば、ロック又はロック解除、ロックログの読み取り、ロックログの消去)を含み得る。そのアクセスについての、追加的な供給元固有の情報を提供するために、任意選択的な文字列要素を提供することができる。一部の実施形態では、コントローラは、特性2116を読み取ることにより、ロックログにアクセスすることができる。
ロック管理制御点特性2114を使用して、例えば、ロックログの読み取り又は消去の要求を送信することができる。例えば、コントローラは、特性2114にデータオブジェクトを書き込む要求を送信することができ、そのデータオブジェクトは、具体的な要求として解釈することができる。この実施例では、サポートされる要求としては、ロックログの読み取り(データオブジェクト内で指定された開始時間から開始)、ロックログの消去(データオブジェクト内で指定されるように、全ての入力、又は指定された範囲の入力を、ロックログから削除することが可能)、及び、ドアロックアクセサリ2004が将来のロックログ入力を記録するための基準として使用することが可能な、現在時間の設定(この時間の設定は、例えば、サマータイムを考慮に入れるためなどに、有用であり得る)を挙げることができる。図5G〜図5Kを参照して上述したように、一部の実施形態では、ドアロックアクセサリ2004は、制御点特性2114への書き込み要求に、インラインで応答するか、又は問い合わせ結果メカニズムを通じて応答するかを、選択することができる。この決定は、1回の要求ごとのものにすることができる。
図21に示される他の特性は、図2A〜図2D、及び図2Jを参照して上述したように動作することができる。
図21に示されるサービス及び特性は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。ロックの機能性に応じて、サービス及び特性の他のセット並びにサブセットを、ロックアクセサリに関して定義することができる。
更なる例示のために、ここで具体的な実施シナリオを説明する。このシナリオでは、ドア2006の所有者は、ドアロックアクセサリ2004を購入して、ドア2006に設置することができる。(ドアロックアクセサリ2004は、ドア2006の一部として、又は後付けのアップグレードとして販売することができる。)ドア2006の所有者は、マスタコントローラ2018を、ドアロックアクセサリ2004と通信するように構成することができる。例えば、マスタコントローラ2018は、上述の統一的アクセサリプロトコルに適合するメッセージを送信及び受信する、及び、ドア2006の所有者がドアロックアクセサリ2004と対話することを可能にするグラフィカルユーザインタフェース(又は、他のタイプのユーザインタフェース)を生成するプログラム(例えば、オペレーティングシステムプログラム、又はユーザがインストールしたアプリケーションプログラム)を実行することが可能な、デスクトップ又はポータブル(例えば、ラップトップ、ハンドヘルド型、モバイル、ウェアラブル)コンピュータシステムとすることができる。
この設置を実行した後、ドア2006の所有者は、マスタコントローラ2018を、ドアロックアクセサリ2004とペアリングさせることができる。図22は、本発明の実施形態による、ドア2006の所有者などのユーザが、マスタコントローラ2018をドアロックアクセサリ2004と(又は、任意の他のコントローラを任意の他のアクセサリと)ペアリングさせることが可能な、プロセスのフローチャートである。
ブロック2202で、ドアロックアクセサリ2004(又は、任意の他のアクセサリ)は、ペアリングモードに入ることができる。一部の実施形態では、ユーザが、アクセサリをペアリングモードにさせることができる。一部の実施形態では、各アクセサリ製造元は、そのアクセサリをペアリングモードにさせる、特定のユーザアクションを定義することができる。例えば、ドアロックアクセサリ2004の場合には、アクセサリ製造元は、アクセサリ筐体のいずれかの場所に、アクセサリ製造元によって提供されたキーをユーザが挿入する、物理的キーホール又はキースロットを提供することができる。別の実施例として、ドアロックアクセサリ2004は、その筐体上若しくは筐体の内側に、ペアリングモードを有効化又は無効化する、機械式スイッチを有し得るものであり、このスイッチは、ドア2006が閉鎖されている場合にアクセス不可能となるように、配置することができる。一般的に、アクセサリをペアリングモードにさせることは、認可ユーザが存在しており、コントローラをアクセサリとペアリングさせることを試みていることを、そのアクセサリに示す、様々なアクションを伴い得るが、しかしながら、アクセサリをペアリングモードにさせる、いずれかの特定の技術の使用は、必須ではない。更には、一部の実施形態では、ドアロックアクセサリ2004は、最初に設置されて電源投入される際に、又は、いずれのコントローラともペアリングを確立していない場合は常に、自動的にペアリングモードに入ることができる。
ブロック2204で、コントローラは、アクセサリを見つけることができる。例えば、ドアロックアクセサリ2004及びマスタコントローラ2018の場合には、アクセサリ2004は、ペアリングモードに置かれた場合、例えば上述のようなデバイス発見サービスを使用して、そのペアリングに関する可用性を広告することを開始することができる。マスタコントローラ2018は、例えば、図4のアクセサリ発見プロセス400を、ブロック422まで実行することによって、ドアロックアクセサリ2004の位置を特定することが可能な、統一的コントローラプログラム(又は、他のプログラムコード)を実行することができる。別の実施例として、一部のコントローラは、アクセサリを自動的に(一定の間隔で、又は、ある区域内に入ることなどのイベントに応答して)探索するか、又は、コントローラによって提供された「FIND」コントロールを作動させることなどのユーザ入力に応答して、アクセサリを探索するように構成することができる。
ブロック2206で、ユーザは、コントローラに、ブロック2204で見つけたアクセサリとペアリングするように命令することができる。例えば、上述のように、アクセサリ発見プロセス400は、コントローラが、アクセサリについての情報をユーザに提示して、ユーザに、ペアリングを実施するべきか否かを示すように促すことを含み得る。別の実施例として、アクセサリ発見を実行するコントローラは、見つけられた全てのアクセサリのリストを、ユーザに提示することができ、ユーザは、そのリストから、ペアリングするアクセサリを選択することができる。このユーザ命令は、様々な形態を取ることができる。一部の場合には、このユーザ命令は、ドアロックアクセサリ2004の設定コードを入力することを含み得るものであり、他の場合には、この設定コードの入力は、別個のユーザアクションとすることができる。
ブロック2208で、このユーザ命令に応答して、コントローラは、ブロック2204で見つけたアクセサリと、ペア設定プロセスを開始することができる。例えば、上述のペア設定プロセス(プロセス1300、1400、1500、1600)のうちのいずれかを、ブロック2208で開始することができる。
ブロック2210で、ペア設定プロセスの間のいずれかの時点で、ユーザは、ペア設定を開始した特定のコントローラとのペアリングを実施するべきであることの検証を、アクセサリに提供することができる。検証が必要とされるか否か、及びいずれの検証が必要とされるかは、アクセサリ製造元によって決定することができる。一部の実施形態では、アクセサリは、そのアクセサリがペアリングモードにあり、コントローラがペアリングを試みているという事実の他には、いかなる追加的検証も必要としない。更には、一部の実施形態では、ブロック2206でのユーザ入力(アクセサリ設定コードを含み得るもの)はまた、ブロック2210での検証としての役割も果たし得る。アクセサリが検証を必要とする場合、そのような検証は、例えば、アクセサリによって検出可能な何らかのアクションをユーザが実行し、そのアクションが正しく実行されない場合には、コントローラに対するエラー応答をアクセサリが生成するという要件を、ペア設定プロセスに含めることによって、実施することができる。
例えば、ペアリングプロセス1300及び1500は、アクセサリの設定コードをコントローラが有するという、コントローラの証明の形態で、アクセサリに対する検証を含む。上述のように、コントローラは、アクセサリの設定コードをユーザから取得して、その設定コードを、共有シークレットを生成する際に使用することができ、コントローラが、共有シークレットを正しく生成したという事実は、そのコントローラが設定コードを有するという、アクセサリに対する検証となり得る。別の実施例として、コントローラ及びアクセサリの双方が、近距離通信(NFC)技術(例えば、NFCフォーラム(http://nfc−forum.org)によって公布される規格に適合する通信技術)を装備する場合には、アクセサリは、ユーザがNFC通信範囲内にコントローラを持ち込むことを要求することができ、そのNFCチャネル上のコントローラが、別のチャネル上でペア設定を実行しているコントローラと同じものであることを確認するために、そのコントローラと情報を交換することができる。(例えば、コントローラは、NFCチャネル及びペア設定チャネルの双方を介して、そのコントローラの共有シークレットの証明(proofC)を提供することが、必要とされる場合がある。)他の検証動作で置き換えることができ、単一のユーザアクションにより、ブロック2206でのペアリングの命令、及びブロック2210での検証の双方を提供することができる。
ブロック2212で、ペア設定プロセスを完了することができ、(エラーが発生していないと想定すると)ユーザに、アクセサリとのペアリングが確立されたことを、(例えば、コントローラによって)通知することができる。その後は、ブロック2214で、アクセサリは、ペアリングモードを終了することができる。一部の実施形態では、ペアリングモードを終了することは、アクセサリをペアリングモードから解除する、ユーザアクションを含み得る。そのようなユーザアクションは、物理的キーの除去、ペアリングスイッチの無効化位置への切り替えなどの、アクセサリをペアリングモードにさせるためにブロック2202で行われたユーザアクションの反転とすることができる。一部の実施形態では、アクセサリは、ペア設定が完了すると、自動的にペアリングモードを終了することができる。
図20を参照すると、環境2000では、プロセス2200は、ドア2006の所有者が、ドアロックアクセサリ2004とペアリングさせることを望む、各コントローラ2012に関して繰り返すことができる。しかしながら、一部の環境では、各コントローラ2012を個別にペアリングすることは、不都合な場合がある。例えば、ペアリングが、接近した物理的近接性を必要とする場合には、各コントローラ2012を順番に、そのような近接性に持ち込んで、ペアリングさせなければならない。多数のコントローラ2012がペアリングされる場合には(例えば、ドア2006が、多くの居住者を有する大型ビルの玄関ドアである場合には)、このことは、極めて時間を要することになり得る。更には、一部の実施形態では、ドアロックアクセサリ2004は、第1のコントローラがペアリングの確立に成功した後には、第2のコントローラがペア設定を実行することを、許可しない場合がある。
したがって、一部の実施形態では、プロセス2200を使用して、ドアロック2004と1つのコントローラ(例えば、マスタコントローラ2018)との間に、ペアリングを確立することができる。その後に、マスタコントローラ2018は、委譲ペアリングプロセス(例えば、ペア追加プロセス1800、又は上述の他の委譲ペアリングプロセス)を使用して、ドアロック2004と追加のコントローラ2012とのペアリングを確立することができる。例えば、マスタコントローラ2018が、特定のコントローラ2012に関する長期公開キー(又は、セキュリティ証明書)を有する場合には、マスタコントローラ2018は、ペア追加プロセス1800を使用して、そのキー(又は、証明書)をドアロックアクセサリ2004に提供することができる。別の実施例として、マスタコントローラ2018は、(例えば、上述のような)信頼証明書チェーンを、ドアロックアクセサリ2004に提供することができ、各コントローラ2012は、その信頼証明書チェーンによって署名された証明書を有することが可能であり、この証明書を使用することにより、所定のコントローラ2012は、ペアリングを確立してドアロックアクセサリ2004にアクセスすることが可能となり得る。上述のように、一部の実施形態では、マスタコントローラ2018は、任意の追加コントローラ2012に、選択的にアドミン許可を付与することができ、アドミン許可を有するコントローラ2012は、ペア追加を実行することにより、アクセサリ2004と追加のコントローラ2012との間のペアリングを確立することができる。
更には、ドア2006にアクセスすることを認可されたユーザのセットは、経時的に変化し得る。例えば、オフィスビルでは、従業員は辞職する場合があり、その時点で、その従業員のビルへのアクセスは、終了させるべきである。家庭では、同居人が引っ越す場合がある。マスタコントローラ2018(又は、管理者許可を有する他のコントローラ)は、例えば、上述のペア除去プロセス1900を使用して、もはやアクセスを認めるべきではない任意のコントローラ2012との、ドアロックアクセサリ2004のペアリングを除去することによって、そのような更新を実施することができる。
一部の実施形態では、マスタコントローラ2018(又は、ドアロックアクセサリ2004に関するアドミン許可を有する、他のコントローラ2012)上で実行される統一的コントローラプログラムにより、ドア2006へのアクセスの管理を容易にするための、様々なユーザインタフェースを提供することができる。例えば、所有者又はセキュリティ担当者は、例えば上述のようなリストペアリング要求を使用して、認可済みコントローラのリストを見ることができ(一部の実施形態では、このリストは、認可済みコントローラのユーザを特定することも含み得る)、その認可リストに追加するべき新規コントローラを特定することができ、かつ/又は、その認可リストから除去するべき、認可済みコントローラを選択することができる。それゆえ、組織環境又はマルチユーザ環境内でのセキュリティ動作を、効率化することができる。
特定のコントローラ2012が、ドアロックアクセサリ2004と(例えば、直接的ペアリング又は委譲ペアリングを含めた、上述の技術のいずれかを使用して)ペアリングを確立すると、そのコントローラ2012を使用して、ドア2006にアクセスすることができる。例えば、コントローラ2012には、コントローラ2012が上述のような統一的アクセサリプロトコルに適合するメッセージを送信及び受信することを可能にする、プログラムコード(例えば、オペレーティングシステム又はアプリケーションコード)を供給することができる。このプログラムはまた、コントローラ2012のユーザがアクセサリと対話することを可能にするための、グラフィカルユーザインタフェース(又は、他のタイプのユーザインタフェース)も定義することができる。
図23は、本発明の実施形態による、ドアをロック解除するプロセス2300のフローチャートである。プロセス2300は、例えば、図20の任意のコントローラ2012(又は、コントローラ2018)とドアロックアクセサリ2004との間で実行することができる。
プロセス2300は、コントローラ2012が、ドア2006をロック解除するべきであることを判定する、ブロック2302で開始することができる。例えば、ポータブルコントローラ2012を持ち運ぶユーザは、ドアロックアクセサリ2004の範囲内に進入することができる。「範囲内」とは、無線通信範囲内として、又は必要に応じてより狭いものとして、定義することができる。例えば、不注意によるドアのロック解除を回避するために、コントローラ2012及びドアロックアクセサリ2004は、近接感知能力を有するように(例えば、Bluetooth LE、NFCなどを使用して)構成することができ、コントローラ2012は、ドアをロック解除することを試みる、最大範囲(例えば、数インチ、2フィート、6フィート以内、又は何らかの他の範囲内)を定義するように構成することができる。一部の実施形態では、ドアロックアクセサリ2004が範囲内に存在することを、コントローラ2012が検出すると、コントローラ2012は、ドア2006のロック解除をユーザが望んでいることを確認するために、ユーザと対話することができる。例えば、ユーザは、範囲内に進入すると、アプリケーション又はシステムレベルのプログラム(又は、その一部分)を起動するか、若しくは他の方式でアクティブにすることにより、ドアをロック解除することができる。他の実施形態では、コントローラ2012は、プロセス2300の諸部分をバックグラウンドプロセスとして実行することにより、コントローラ2012がペアリングを確立したドアロックアクセサリを走査することができ、そのようなアクセサリを範囲内で検出すると、コントローラ2012は、ユーザに対するプロンプトを生成することができる。更には、コントローラ2012が、ユーザに、ドアをロック解除するべきであることを確認するように促す際、コントローラ2012は、コントローラ2012が認可ユーザによって持ち運ばれていることを検証するために、認証証明情報(例えば、パスワード、又は、指紋などの生体証明情報)を供給するように、ユーザに要求することができる。更に他の実施形態では、コントローラ2012は、ユーザ入力を使用することなく、コントローラ2012が、ドアロックアクセサリ2004の範囲内に進入する場合は常に、ドア2006のロック解除を自動的に試みるように、構成することができる。他の実装もまた、可能である。具体的な実装は、具体的なドアロックアクセサリ2004に関して所望される、セキュリティのレベルに応じて変化し得るものであるため、いずれのドアにユーザが接近したかに応じて、同じコントローラが異なる方式で挙動する場合もある。
更には、他の技術を使用して、ドアをロック解除するべきであることを判定することができ、コントローラ2012とドアロックアクセサリ2004との物理的近接性は、必須のものではない。例えば、ユーザは、コントローラ2012上のユーザインタフェースを操作することにより、ドアを選択して、そのドアをロック解除するべきであることを指示することによって、ドア2006をリモートで(例えば、別の部屋、又は全く別の場所から)ロック解除することが可能となり得る。一部の実施形態では、リモートなロック解除を実行する前に、コントローラ2012は、コントローラ2012が認可ユーザによって操作されていることを検証するために、認証証明情報(例えば、パスワード、又は、指紋などの生体証明情報)を供給するように、ユーザに要求することができる。
ブロック2306及び2308で、コントローラ2012及びドアロックアクセサリ2004は、ペア検証動作(例えば、上述のプロセス1700)を実行することができる。この動作は、それらの2つのデバイス間でペアリングが以前に確立されたことを、検証することができる。ブロック2310で、このペア検証プロセスが成功しなかった場合には、プロセス2300は、ブロック2312で終了することができ、コントローラ2012は、ユーザにエラーを警告することができる。一部の実施形態では、ユーザに、再試行するように促すことができる。ペア検証は、コントローラ2012が、ドアロックアクセサリ2004のロック解除を試みるたびに必要とされる場合がある。
ペア検証プロセスが成功した場合には、ブロック2314で、コントローラ2012は、ドアを開放するために、ドアロックアクセサリ2004に、暗号化された要求を送信することができる。例えば、図5A〜図5Dを参照して上述されたように、コントローラ2012は、ドアロックアクセサリ2004のロック状態特性2102に、ブール値「true」(開放)の値を書き込む、HTTP PUT要求を送信することができる。ペア検証済みセッションでの全ての通信と同様に、この要求は、ペア検証の間に(又は、後に)確立されたセッションキーを使用して暗号化することができる。一部の実施形態では、この要求は、コントローラ2012の長期秘密キーで署名することもできるが、このことは必須ではない。
ブロック2316で、ドアロックアクセサリ2004は、その暗号化された要求を受信することができる。ブロック2318で、ドアロックアクセサリ2004は、その要求を検証して復号することができる。ペア検証済みセッション内での全ての通信と同様に、正しいセッションキーで暗号化されていない場合には、アクセサリは、その要求を無視することができる。更には、その要求が、コントローラの長期秘密キーで署名されていた場合には、アクセサリは、そのアクセサリの(確立済みペアリングに関して永続的に記憶することが可能な)コントローラの長期公開キーのコピーを使用して、その署名を、またそれゆえコントローラのアイデンティティを、検証することができる。アクセサリ2004はまた、コントローラ2012が、ドアをロック解除することを許可されていることも、検証することができる。例えば、一部の実施形態では、特定の時間でのアクセスは、管理者許可を有するコントローラに限定することができる。この制限は、図2Dの特性228のインスタンスとすることが可能な、アドミン限定アクセス特性2122(図21)に、管理者特権を有するコントローラが書き込むことによって、設定又は解除することができる。他の規則又は決定基準もまた、適用することができる。
ブロック2320で、その要求が有効である場合には(例えば、正しく復号されており、許可されたコントローラからのものである場合には)、ドアロックアクセサリ2004は、ブロック2322でのドアのロック解除に進むことができる。一部の実施形態では、ドアロックアクセサリ2004は、コントローラ2012に、ロック解除を(例えば、HTTP200 OK応答を送信することによって)報告することができる。必要に応じて、コントローラ2012及び/又はドアロックアクセサリ2004はまた、成功を示すユーザ感知可能出力も提供することができる。例えば、一方又は双方のデバイスは、ビープ音を鳴らすか、又はクリック音を鳴らすか、緑色ライトを点滅させることなどが可能である。一部の実施形態では、アクセサリのフィードバック挙動は、ロックサービスインスタンス2106の定義内に、必要に応じて、Audio Feedback特性206(図2A)又は他の特性などの、適切な特性を含めることによって、カスタマイズ可能にさせることができる。
ブロック2302で、その要求が有効ではない場合には、ブロック2324で、ドアロックアクセサリ2004は、コントローラ2012に、エラーメッセージを(例えば、HTTPエラー応答を送信することによって)送信することができる。一部の実施形態では、コントローラ2012は、ユーザにエラーを通知することができ、かつ/又は、再度試行するようにユーザに促すことができる。必要に応じて、コントローラ2012及び/又はドアロックアクセサリ2004はまた、ロック解除の試みが失敗したことを示す、ユーザ感知可能出力も提供することができる。例えば、一方又は双方のデバイスは、エラー音(例えば、成功音とは異なるビープ音)を鳴らすこと、赤色ライトを点滅させることなどが可能である。
プロセス2300は例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。プロセス2300は、以前に確立されたペアリングの存在に依存するものであるが、そのペアリングが確立された方式(例えば、証明書ベース又は設定コードベース、直接的又は委譲)とは無関係であり得る点に留意されたい。それゆえ、この実施例でのアクセサリ及びコントローラは、それらが確立済みペアリングを有することを知る必要があるが、そのペアリングが、いつどのようにして確立されたかを知る必要はない。
更には、プロセス2300は、ドアをロックする特定のコンテキストでの、コントローラとアクセサリとの間の対話を示すものであるが、本開示を入手可能な当業者には、同様のプロセスを、任意のアクセサリの任意の動作を制御するために実施することができる点が、認識されるであろう。
一部の実施形態では、ドアロックアクセサリ2004は、ドアをロックする明示的な命令が(例えば、プロセス2300と同様のプロセスを介して)受信されるまで、ドア2006をロック解除したまま放置することができる。他の実施形態では、ドアロックアクセサリ2004は自動的再ロック時間間隔を適用することができる。例えばブロック2322でドア2006をロック解除した後、アクセサリ2004は一定の期間(例えば、10秒)待機してから、再ロックすることができる。ブロック2322でロック解除した後、ユーザが速やかに(例えば、5秒以内に)開放しない場合には、ドア2006を自動的に再ロックすることなどの、他のセキュリティ対策もまた実装することができる。自動的再ロック挙動は、例えばオートタイムアウト特性インスタンス2124(図21)に、非ゼロ値を書き込むことによって実施することができる。
一部の実施形態では、ドアロックアクセサリ2004は、ドアをロック解除する前に、更なる条件又はユーザアクションを必要とする場合がある。例えば上述のように、ドアロックアクセサリ2004は、NFCトランシーバを組み込むことができ、ドアロックアクセサリ2004は、ロック解除の前に、コントローラ2012がNFC範囲内に持ち込まれることを必要とし得る。又は、ドアロックアクセサリ2004は、ユーザがいつドアに接触しているかを検出する、センサを有し得るものであり、ロック解除要求が有効であることをアクセサリが判定した後、ドアが速やかに(例えば、2秒又は5秒以内に)接触されない場合には、ロック解除することを拒絶することができる。
別の実施例として、一部の実施形態では、ドアロック(又は、任意の他のアクセサリ)の製造元又は供給元は、コントローラとアクセサリとの間で交換される「データブロブ」の使用によって、製造元固有の挙動を組み込むことを選択することができる。本明細書で使用するとき、「データブロブ」とは、コントローラによって記憶することが可能であり(例えば、図20のコントローラ2012のそれぞれ及びマスタデバイス2018は、データブロブを記憶することが可能)、アクセサリに、そのアクセサリへの任意の要求の一部として送信するか、又は特定の要求(例えば、特定の特性に書き込む要求)と共に選択的に送信することが可能なデータのブロックを指す。コントローラの観点からは、このデータブロブは、不透明とすることができ、データブロブを受信するアクセサリは、アクセサリ固有の方式でそのコンテンツを解釈することができる。
例示として、ドアロックアクセサリ2004の場合には、製造元は、ドアロックアクセサリ2004のユーザに、そのロックの認可ユーザとして登録するように要求することができる。例えば、製造元は、ウェブサイトをサポートするサーバを提供することができ、このウェブサイトで、ユーザは、そのロックに関する認可コードを(例えば、そのサーバにアカウントを作成することによって)取得することができる。認可ブロック(認可コードと、アクセサリ製造元によって所望される任意の追加的情報とを含む、データオブジェクトとすることが可能なもの)を、サーバによって生成して、ユーザのコントローラ2012に配信することができる。コントローラ2012は、この認可ブロックを、アクセサリ2004に関連付けられたデータブロブとして記憶することができる。コントローラ2012が、その後、アクセサリ2004に要求を送信する際に、コントローラ2012は、その要求内に、記憶されたデータブロブを含めることができる。
一部の実施形態では、データブロブの送信は、要求の性質に応じて変化し得る。例えば、アクセサリ定義レコードは、(例えば、図3A〜図3Cに示されるような)特性を定義することができ、この特性には、その特性に関してコントローラが有する許可が含まれる。一部の実施形態では、特性にアクセスするためにデータブロブが必要とされることを示すように、許可文字列(例えば、「Blob Required」)を定義することができ、アクセサリ製造元は、データブロブを受信することがアクセサリ製造元によって所望される、任意の特性に関する許可の定義内に、この文字列を含めることができる。特定の特性への要求を生成する際、コントローラ2012は、アクセサリ定義レコード(そのコントローラがキャッシュすることが可能なもの)から、それらの許可を参照することにより、データブロブが必要とされるか否かを判定することができ、必要とされる場合には、コントローラ2012は、その要求にデータブロブを付加することができる。他の実施形態では、データブロブを送信するか否かの決定は、アクセサリごとのレベルで実施することができる(例えば、コントローラが、特定のアクセサリに関して記憶されたデータブロブを有する場合には、コントローラは、そのアクセサリに送信する全ての要求に、データブロブを付加することができる)。
例示的アクセサリ:IPカメラ
本発明の様々な実施形態に従って制御することが可能なアクセサリの第2の実施例は、IPカメラアクセサリである。IPカメラアクセサリは、ビデオ画像を(音声の有無に関わりなく)キャプチャし、キャプチャされたメディア(音声及び/又はビデオ)を他のデバイスにストリーミングすることが可能な、カメラを含み得る。一部の場合には、IPカメラはまた、録画すること、及び/又は以前に録画されたコンテンツの再生などの、他の機能性も提供することができる。本明細書で説明されるような、統一的アクセサリプロトコルを使用する任意の他のアクセサリと同様に、これらの機能性は、サービスとしてモデル化することができ、それらの様々なサービスの特性インスタンスの読み取り及び書き込みによって制御することができる。
上述の統一的アクセサリプロトコルの実施形態では、コントローラとアクセサリとの間の通信は、HTTP要求及びHTTP応答を使用して実施することができる。IPカメラの場合には、HTTP要求及びHTTP応答を使用することにより、カメラを設定してその挙動を制御すること(例えば、カメラの照準を合わせること、録画を開始及び停止することなど)ができるが、しかしながら、HTTPは、デバイス間でのリアルタイムのメディアコンテンツのストリーミングには、あまり適していない恐れがある。したがって、本明細書で説明されるIPカメラの実施形態では、IPカメラ及びコントローラは、メディアセキュリティのために使用するSRTPプロトコル(例えば、IETF RFC3711で定義されるようなもの)と共に、RTPプロトコル(例えば、IETF RFC3550で定義されるようなもの)などの、異なるプロトコルを使用することができる。明らかとなるように、他のメディアストリーミングプロトコルで置き換えることもできる。この統一的アクセサリプロトコルは、ストリーミングプロトコルをサポートするストリーミングセッション(統一的アクセサリプロトコルに従って定義されたペア検証済みセッションとは、別個のものとすることが可能なもの)を確立するために使用可能な特性を定義することができ、ストリーミングされるコンテンツの配信は、そのストリーミングセッションを介して実施することができる。
図24を参照すると、本発明の実施形態による、IPカメラアクセサリ2404に関する動作環境2400が示されている。この実施例では、IPカメラアクセサリ2404は、例えば無線アクセスポイント2406を介して、コントローラ2402と通信することができる。直接通信もまた、サポートすることができる。IPカメラアクセサリ2404は、ある区域内に恒久的又は取り外し可能に設置される器具(例えば、建物内の部屋、廊下、若しくは出入り口内に設置される、防犯カメラ又は監視カメラ)とすることができ、又は、多種多様な設定でビデオをキャプチャするために使用することが可能な、ポータブルカメラとすることもできる。コントローラ2402は、IPカメラ2404を制御する任意のデバイスとすることができる。例えば、IPカメラ2404は、建物用の防犯カメラとして使用され、コントローラ2402は、その建物内のセキュリティ局に実装することができる。別の実施例として、IPカメラ2404は、例えばベビーモニタとして子供の部屋内に設置することができ、コントローラ2402は、親の携帯電話、タブレット、又は親が一般的に持ち運ぶ他のデバイスとすることができる。更に別の実施例として、ユーザは、公園又は鳥獣保護区にIPカメラ2404を持ち出して、目立たない場所に設置し、次いで、リモートな場所に退却して、コントローラ2402を使用してIPカメラ2404を制御することにより、野生動物などの良質なビデオを得る可能性を高めることができる。それゆえIPカメラ2404の使用は、いずれかの特定の環境、又はいずれかの特定のコントローラに限定されるものではない。
本明細書で説明される他のアクセサリと同様に、IPカメラアクセサリ2402は、サービスの集合としてモデル化することができる。図25A、図25Bは、本発明の実施形態による、IPカメラアクセサリ2402に関するアクセサリモデル内に含めることが可能なサービス2501〜2505に関する例示的定義を示す。上記の図2G、図2Hに示されるサービス定義の実施例と同様に、サービス定義2501〜2505は、必須特性及び/又は任意選択特性を指定することができる。図26A〜図26Eは、図25A、図25Bのサービスの特性に関する例示的定義を示す。図26A〜図26Eには提供されていない、図25A、図25Bに列挙された特性に関する例示的定義は、図2A〜図2D内に見出すことができる。これらのサービス及び/又は特性のうちのいずれも、コアサービス及びコア特性として定義することができ、そうではない場合には、拡張サービス及び拡張特性として定義することができる。
図25Aを参照すると、IP Camera Streamingサービス2501は、メディアセッションを管理するために使用されるリアルタイム通信サービスを説明することができる。例えば、IP Camera Streamingサービス2501は、例えば以下で説明されるように、コントローラ2402とIPカメラアクセサリ2404との間のメディアストリームの設定及び制御を容易にする特性を含み得る。
Recordingサービス2502は、録画デバイスを制御するために、例えば、録画を開始、停止、又はスケジュールするために使用される、サービスを説明することができる。同様に、Playbackサービス2503は、アクセサリによって、記憶されたメディアの再生を制御するために、例えば、再生の開始及び一旦停止のために使用される、サービスを説明することができる。この実施例では示されないが、Playbackサービス2503の一部として、又は別個のコンテンツ選択サービスとして、記憶されたメディアアイテムを再生するように選択するための、更なる特性を定義することができる点が、当業者には認識されるであろう。
図25Bを参照すると、Cameraサービス2504は、カメラをオン又はオフにすることなどの、カメラ設定の制御を提供することができる。一部の実施形態では、カメラ方向付け特性(例えば、パン、チルト、ズーム、回転)などの、カメラ設定に関連する他の特性を、任意選択特性として、このサービス内に含めることができる。他の任意選択特性としては、暗視(オン又はオフ)及びミラーモード(キャプチャした画像のミラーリングの有効化又は無効化)などの、画像処理特性を挙げることができる。特定のカメラアクセサリが提供する、任意のユーザ選択可能設定は、Cameraサービス2504内に定義されて含められる、対応する特性を有し得る。
Microphoneサービス2505は、音を記録するように動作可能なマイクロホンの、制御を提供することができる。サービス2505は、マイクロホンを有する任意のカメラアクセサリに関する定義内に含めることができ、マイクロホンを有さない任意のカメラアクセサリに関しては、省略することができる。
Speakerサービス2506は、音を出力するように動作可能なスピーカに対する制御を提供することができる。サービス2506は、スピーカ出力を有する任意のカメラアクセサリに関する定義内に含めることができ、スピーカ出力を有さない任意のカメラアクセサリに関しては省略することができる。
図26A、図26Bを参照すると、IPカメラの管理に関して有用な特性は、Session Start特性2601、Session End特性2602、及び追加的特性2603〜2615を含み得る。(図26Aに示される)Session Start特性2601及びSession End特性2602には、ストリーミングセッションを開始及び終了させるために、コントローラによって書き込むことができる。追加的特性2603〜2615は、IPカメラのビデオストリーミング及び/又は音声ストリーミングのプロパティについての情報を取得するために、コントローラによって読み取ることができる。
Session Start特性2601は、ストリーミングセッションを開始するために、コントローラが、IPカメラアクセサリによって使用可能な情報を提供するために書き込むことが可能な、(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトを値として有し得る。図26Cは、Session Start特性2601内に含めることが可能な、データ要素の実施例を示す。セッションID2631は、開始されるストリーミングセッションに関するUUIDとすることができる。コントローラIPアドレス2632及びコントローラポート2633は、ストリーミングされるデータを(例えば、IPv4又はIPv6フォーマットを使用して)送信するべき宛先を特定することができる。コントローラSRTPマスタキー2634及びコントローラSRTPマスタソルト2635は、そのセッション内でストリーミングされるメディアを暗号化するために使用されることになる、ソルト及びマスタ暗号キーを提供することができる。ビデオ最大帯域幅2636及び音声最大帯域幅2637は、ストリーミングデータ帯域幅の上限値を(例えば、キロビット毎秒(kbps)の単位で)示すことができる。
再び図26Aを参照すると、Session End特性2602は、終了させるセッションのセッション識別子を提供する、(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトを値として有し得る。一部の実施形態では、セッションを終了するために他の情報は必要とされない。
Video Codec Name2603は、IPカメラサービスインスタンスのビデオコーデックによって提供されるメディアのタイプを表す、文字列を提供することができる。一部の実施形態では、その文字列に関する有効値のセット(例えば、http://www.iana.orgを介してアクセス可能なIANA(Internet Assigned Numbers Authority)によって定義される、コーデック名のセット)を定義することができる。一部の実施形態では、IPカメラサービス2501の所定のインスタンスは、1つのコーデック(例えば、IETF RFC6184で定義されるようなH.264コーデック)をサポートし、複数のコーデックをサポートするIPカメラアクセサリは、IPカメラサービス2501の複数のインスタンスを定義することができる。コントローラは、セッションに関する所望のコーデックを、IPカメラサービス2501の、対応するインスタンスのセッション開始特性に書き込むことによって選択することができる。
Video Codec Parameters2604は、ビデオコーデックに関する追加的パラメータを提供することができる。含まれる具体的なパラメータは、Video Codec Name2603に応じて変化し得るものであり、キー−値フォーマットで表現することができる。例えば、H.264コーデックの場合には、Video Codec Parameters2604は、H.264コーデックのサブプロファイル及びレベルを指定する、プロファイル−レベルIDと、そのコーデックが単一のNALユニットモード又は非インタリーブモードのいずれをサポートするかを指定する、パケット化モードを含み得る。サービスインスタンスによってサポートされる具体的なビデオコーデックに応じて、他のパラメータも定義することができる。
Video Attributes特性2605は、サービス−レベル属性(例えば、SDP属性)を提供することができる。例としては、画像属性、及び方向性属性(例えば、送信専用、受信専用、又は双方向性(送信及び受信))が挙げられる)。一部の実施形態では、方向が指定されない場合には、「送信専用」を、デフォルトとして推定することができる。
RTP Video Payload Type特性2606は、例えば、RTPに関して指定されるような、7ビット整数ペイロードタイプを提供することができる。
RTP Protocol特性2607は、使用されている具体的なRTPベースのプロファイルを特定する、文字列を提供することができる。例えば、「RTP/SAVP」は、IETF RFC3550で定義されるプロファイルを指すことができ、その一方で、「RTP/SAVPF」は、IETF RFC5104で定義されるプロファイルを指すことができる。他のプロファイル及び文字列もまた定義することができる。
RTP Extensions特性2608は、このIPカメラサービス2501のインスタンスによってサポートされるRTP拡張を列挙する、文字列のアレイを提供することができる。RTP拡張の実施例としては、ピクチャロス指標、時間空間トレードオフ要求、一時的最大メディアストリーミングビットレートなどを挙げることができる。
SRTP Crypto Suite特性2609は、安全なRTPストリーミングのために使用されるべき暗号化スイートを特定する、文字列を提供することができる。一部の実施形態では、この文字列は、暗号化スイートのIANA登録名に適合し得る。一部の実施形態では、SRTP Crypto Suite特性2609は、SRTPが使用されないこと(例えば、ストリーミングされるビデオデータが暗号化されないこと)を「none」の値が示すことを可能にし得る。
図26Bを参照すると、Audio Codec Name特性2610は、音声コーデックによって提供されるメディアのタイプを表す、文字列を提供することができる。一部の実施形態では、その文字列に関する有効値のセット(例えば、IANA(Internet Assigned Numbers Authorityによって定義されるコーデック名のセット)を定義することができる。一部の実施形態では、IPカメラサービス2501の所定のインスタンスは、音声コーデックとビデオコーデックとの1つの組み合わせをサポートすることができ、IPカメラアクセサリは、IPカメラサービス2501の複数のインスタンスを定義することによって、コーデックの複数の組み合わせをサポートするができる。コントローラは、セッションに関する所望の音声コーデック及びビデオコーデックを、IPカメラサービス2501の、対応するインスタンスのセッション開始特性に書き込むことによって選択することができる。
Audio Codec Parameters2611は、音声コーデックに関する追加的パラメータを提供することができる。含まれる具体的なパラメータは、Audio Codec Name2610に応じて変化し得るものであり、キー−値フォーマットで表現することができる。例えば、Opusコーデックの場合には、音声コーデックパラメータ2604は、固定ビットレート又は可変ビットレートのいずれが有効化されるかに関する標識を含み得る。具体的な音声コーデックに応じて、他のパラメータも定義することができる。
Audio Attributesパラメータ2613は、メディア−レベル属性(例えば、SDP属性)を提供することができる。例としては、方向性属性(例えば、送信専用、受信専用、又は双方向性(送信及び受信))が挙げられる。一部の実施形態では、方向が指定されない場合には、「送信専用」をデフォルトとして推定することができる。
RTP Audio Clock Rate特性2614は、例えば、RTPに関して指定されるような、音声に関するRTPクロックレートを提供することができる。
RTP Audio Payload Type特性2615は、例えば、RTPに関して指定されるような、7ビット整数ペイロード時間を提供することができる。
様々な実施形態では、メディアのストリーミングに関して、他の特性及びサービスもまた、定義することができる。一部の実施形態では、あらゆるサービスインスタンスで、全ての特性が使用されるわけではない。例えば、音声を受信又はストリーミングしないIPカメラアクセサリに関するアクセサリモデルは、特性2610〜2615を省略することができる。
図26Dは、本発明の実施形態による、カメラサービス2503の様々な特性2651〜2656に関する例示的定義を示す。これらの(任意選択的とすることが可能な)特性は、このカメラサービスが、対応する挙動をサポートする場合に、定義することができる。コントローラは、これらの特性に書き込むことにより、カメラの向き及び撮像挙動を制御することができる。例えば、Night Vision特性2651は、暗視撮像モードを有効化又は無効化するために使用可能な、ブール値を有し得る。
Pan特性2652は、カメラのパニングを制御するために使用することができる。例えば、カメラは、水平面内で回転可能とすることができる。このパニングの量は、例えば、中心位置に対する、カメラの最大水平方向回転の百分率として、指定することができる。この中心位置は、ゼロのパン値を有するように定義することができ、Pan特性2652の正の値は、右側へのパニングを示し、Pan特性2652の負の値は、左側へのパニングを示す。度数などの他の単位を使用することもできる。
同様に、Tilt特性2653は、カメラのチルト角度(例えば、水平方向に対する光軸の角度)を制御するために使用することができる。このチルトの量は、例えば、中心位置に対する、カメラの最大チルトの百分率として、指定することができる。この中心位置は、ゼロのチルト値を有するように定義することができ、Tilt特性2653の正の値は、上向きのチルトを示し、Tilt特性2652の負の値は、負のチルトを示す。度数などの他の単位を使用することもできる。
Rotation特性2654は、カメラの光軸を中心とする、カメラの回転角度を制御するために使用することができる。この回転の量は、例えば、度数の単位で指定することができる。一部の実施形態では、列挙値を(例えば、右90度、左90度、180度、及び無回転の回転設定をサポートするために)使用することができる。
Zoom特性2655は、カメラに関するズーム(又は、拡大)率を指定するために使用することができる。
Mirror特性2656は、画像の表示、ストリーミング、又は記憶の前に、その画像にミラーリング変換(例えば、垂直軸を中心とするミラーリング)を施すべきか否かを示すために使用されるブール値とすることができる。
図26Eは、図25AのRecordingサービス2502及びPlaybackサービス2503内に含めることが可能な、更なる特性の定義を示す。Recording Control特性2661は、録画を開始又は停止するために、コントローラによって書き込むことができる。この値は、実行する動作(例えば、録画の開始、録画の停止、録画のスケジュール)の識別子と、その動作に適切な追加的パラメータ(例えば、録画の持続時間、スケジュールされた録画に関する開始時間及び/又は停止時間など)とを含み得る、(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトとすることができる。Recording Status特性2662は、録画サービスが録画中であるか否かを判定するために、コントローラによって読み取ることができる。この値は、カメラが現在録画中であるか否かの指標を含み得る(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトとすることができ、他の情報もまた、含めることができる(例えば、録画に関するスケジュールされた終了時間、スケジュールされた今後の録画についての情報、録画のための利用可能な記憶スペース及び/又は使用済みの記憶スペースの量など)。
Playback Control特性2663は、記憶されたメディアコンテンツ(例えば、以前に録画されたコンテンツ)の再生を制御するために、コントローラによって書き込むことができる。この値は、実行する動作(例えば、再生の開始、再生の一時停止、再生の終了など)の識別子を含み得る(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトとすることができる。再生されるコンテンツ項目の識別子などの、追加的パラメータもまた含めることができる。Playback Status特性2664は、現在の再生状態を判定するために、コントローラによって読み取ることができる。この値は、再生が進行中であるか否かの指標を含み得る、(例えば、TLVフォーマット、又は他のキー−値フォーマットの)データオブジェクトとすることができ、他の情報もまた、含めることができる(例えば、再生されているコンテンツ項目の識別子、コンテンツ項目の持続時間、再生位置など)。Playback Speed特性2665は、再生速度を制御するために使用することができ、その値は、1.0の通常再生速度に対する増速率を示す。一部の実施形態では、Playback Speed特性2665に関する有効値は、再生サービス2502の具体的なインスタンスがサポートする速度に、制限することができる。
本明細書で説明されるサービス及び特性は、例示を目的とするものである。他のサービス及び特性もまた、定義することができる。例えば、再生する具体的なコンテンツ項目の特定を容易にするために、利用可能なコンテンツ項目のデータベース又は他のリストを、コントローラがナビゲートする(例えば、閲覧又は検索する)ことを可能にすることが、望ましい場合がある。コントローラによるデータベースのナビゲーションを容易にするために、更なる特性を定義することができる。これらの特性は、必要に応じて、再生サービス2502、又は異なるサービス(例えば、コンテンツ閲覧サービス)内に含めることができる。
図27A〜図27Dは全体として、本発明の実施形態による、IPカメラアクセサリ2402に関するアクセサリオブジェクト2700を示す。この実施例では、アクセサリオブジェクト2700は、JSONで表現されており、図3A〜図3Cのアクセサリオブジェクト300と同様の構造である。他のフォーマット及び言語もまた、使用することができる。
図27Aに示されるアクセサリ情報サービスインスタンス2702は、上記で定義されたAccessory Informationサービスインスタンス261と、同様又は同一のものとすることができる。この実施例では、アクセサリオブジェクト2700は、図27B、図27Cに示されるIPカメラストリーミングサービス2704(図25Aのサービス定義2501に適合するもの)、図27Dに示されるカメラサービス2706(図25Bのサービス定義2503に適合するもの)、及び図27Dに示されるマイクロホンサービス2708(図25Bのサービス定義2504に適合するもの)である、3つの他のサービスのインスタンスを含む。この実施例では、IPカメラアクセサリ2402はスピーカを有さず、またローカルでの録画又は再生能力も有さず、その結果として、これらのサービスのインスタンスは定義されない。(本開示を入手可能な当業者には、それらのサービスのインスタンスに関する、適切なアクセサリオブジェクトを構築することが可能となるであろう。)この実施例では、各特性インスタンスの現在の値が、アクセサリオブジェクト2700内で指定され、書き込み専用の特性に関しては、ヌル値が指定されている。
図24のIPカメラアクセサリ2404及びコントローラ2402とのユーザ対話は、上述の対話と同様のものとすることができる。例えば、ユーザは、コントローラ2402を操作することにより、所望の挙動を指示することができ、コントローラ2402は、その所望の挙動を達成するように、アクセサリ2404に要求(例えば、HTTP要求)を送信することができる。図28は、本発明の実施形態による、対話シナリオを示すプロセス2800のフローチャートである。
ブロック2802で、ユーザは、IPカメラアクセサリ2404を設定することができる。例えば、ユーザは、所望の運用場所及び向きに、カメラを配置するか若しくは取り付けて、電力ケーブルを接続し、アクセサリ2404をペアリングモードに(アクセサリ2404が自動的にペアリングモードに入らない場合には)させることなどが可能である。ブロック2804で、コントローラ2402は、IPカメラアクセサリ2404を発見することができる。例えば、上述のように、コントローラ2402は、図4のプロセス400のコントローラ実行可能部分を実行することが可能な、アプリケーションプログラムを実行することができる。このアプリケーションは、明示的なユーザ命令に応答して、又はバックグラウンドプロセスとして実行することができ、ユーザには、所望のアクセサリが見つかったことを確認するように、又は、ペアリングするために利用可能なアクセサリのリストから、アクセサリ2404を選択するように、促すことができる。ブロック2806で、コントローラ2402及びIPカメラアクセサリ2404は、ペア検証済みセッションを確立することができる。例えば、コントローラ2402及びIPカメラアクセサリ2404は、上述のペア設定プロセスのうちのいずれかの後に続けて、上述のようなペア検証プロセスを実行することができる。ペア設定の間の検証要件を、必要に応じて適用することができ、例えば、ドアロックアクセサリ2004に関連して上述された選択肢のうちの、いずれかを使用することができる。具体的な検証要件は、具体的なIPカメラアクセサリの性質又は目的用途に応じて決定することができる。例えば、ビルの防犯カメラは、複数の形態の検証を必要とし得るが、その一方で、一般消費者の「ウェブカメラ」タイプのカメラは、そのカメラがペアリングモードにあること、及び、そのカメラ上のラベルに印刷された設定コードをユーザが入力することのみを必要とし得る。
ブロック2808で、ユーザは、ペアリング済みコントローラ2402を使用して、例えば、IPカメラストリーミングサービス2704の「on」特性(インスタンスID 8)に値「true」を書き込む要求を送信することによって、IPカメラアクセサリ2404に電源投入することができる。この実施例では、IPカメラアクセサリ2404は、そのトランシーバが、ペアリング済みコントローラからの信号を受信することは可能であるが、他のサービス(例えば、アクセサリオブジェクト2700内に列挙される他のサービス)は電源切断される、低電力モードを有し得る。
図25A、図25Bに示されるように、サービス2501〜2505の種々のサービスは、それぞれ別個の「on」特性を有し得る。このことにより、コントローラは、サービスインスタンスを、それらが使用されることになる場合に選択的に電源投入することによって、電力消費を管理することが可能となり得る。一部の実施形態では、1つのサービスの「on」特性の変化は、他のサービスに影響を及ぼし得る。例えば、IP Camera Streamingサービス2501を電源切断することは、全てのビデオストリームの送信を停止する結果をもたらし得るが、Microphoneサービス2505又はSpeakerサービス2506の動作を停止する必要はない。IP Camera Streamingサービス2501は、他のサービスがオフのまま維持されている間にも電源投入することができるが、メディアストリームがアクティブである場合には、そのストリームに関連付けられる、いずれのサービスインスタンスも電源投入されたまま維持されるべきであり、さもなければ、ストリーミングが停止する恐れがある。また、一部の実施形態では、IP Camera Streamingサービス2501は、新たなセッションに関するストリームのうちの1つに関連付けられたサービスインスタンスが、電源切断された場合には、その新たなセッションが開始されることを許容しない。IPカメラスサービス2501を電源切断することにより、全てのメディアセッションを終了させ、他の関連サービスインスタンス(例えば、Microphoneサービス2506又はSpeakerサービス2506)を自動的に電源切断することができる。IPカメラスサービス2501を電源投入することは、全ての関連サービスインスタンスを電源投入する結果をもたらし得る(それらは、その後に使用されていない場合には、電源切断することができる)が、いずれの以前のメディアセッションも、復旧する必要はない。他の電力管理規則もまた、実装することができる。
ブロック2810で、ユーザは、例えばコントローラ2402のユーザインタフェースと対話することによって、IPカメラアクセサリ2404からのビデオのストリーミングを開始するように、コントローラ2402に命令することができる。例えば、ユーザは、カメラがコントローラ2402にビデオをストリーミングするべきであることを、指示することができる(一部の実施形態では、ユーザは、異なる宛先デバイスを指定することができる)。それに応答して、ブロック2812で、コントローラ2402は、メディアセッションを開始する要求を生成して、IPカメラアクセサリ2404に送信することができる。
一部の実施形態では、このメディアセッション開始要求は、IPカメラアクセサリ2404の/characteristicsのURLへの、HTTP PUT要求として送信することができる。図27A〜図27Dのアクセサリオブジェクト2700を使用する実施形態に関して、実施例を図29に示す。要求メッセージ2900は、メッセージボディ2902を有し得る。メッセージボディ2902は、書き込まれることになるインスタンスの、インスタンス識別子2904を含み得る(インスタンスID9は、IPカメラサービスインスタンス2704(図27B)に関するセッション開始特性に対応する)。値2906は、セッションID、コントローラ2402(又は、他の宛先デバイス)に関するIPアドレス及びポート、並びにSRTPストリーミングデータに関して使用される暗号キー及びソルトなどの、コントローラ2402とのストリーミングセッションを確立するためにIPカメラアクセサリ2404によって使用可能な情報を含み得る。
ブロック2814で、IPカメラアクセサリ2404は、このメディアセッション開始要求に対する応答を送信することができる。一部の実施形態では、この応答は、HTTP応答として送信することができるメディアセッション開始要求が図29に示されるようなものである実施形態に関して、実施例を図30に示す。応答メッセージ3000は、メッセージボディ3002を有し得る。メッセージボディ3002は、値3004を含み得る。値3004は、正常終了(例えば、エラーコード0)又は発生した具体的なエラー(例えば、無効なパラメータ、リソースがビジー、アクセス拒否など)を示す値を有し得る、エラーコード3002を含み得る。エラーがないものと想定すると、値3004は、アクセサリのIPアドレス及びポート、並びにアクセサリのSRTP暗号パラメータなどの、IPカメラアクセサリ2404とのストリーミングセッションに接続するためにコントローラ2402によって使用可能な、追加的情報を提供することができる。
この実施例では、SRTP暗号パラメータは、セッション開始要求及びセッション開始応答内に含めることができる。これらのパラメータは、平文で送信する必要がないことを理解されたい。要求2900及び応答3000が、コントローラ2402とアクセサリ2404との間のペア検証済みセッション内で交換される実施形態では、これらのパラメータは、(そのペア検証済みセッションのセッションキーを使用して)暗号化された形態で送信されることにより、侵入者に対して防御される。
これらの要求及び応答の代替的実施形態もまた、実施することができる。上述の例示的なサービス定義では、IP Camera Streamingサービス2501の所定のインスタンスは、関連するコーデック、属性、ペイロードなどを有し、これらは、そのサービスインスタンスの固定された特性とすることができ、異なる特性のセットを、そのサービスの異なるインスタンスとして定義することができる。他の実施形態では、異なる実装を使用することができる。例えば、ストリーミングセッション開始要求は、所望のセキュリティに応じて、RTP又はSRTPを使用して配信することが可能なメディアストリームを構成するために、SDPを活用することができる。本明細書で使用するとき、「メディアストリーム」は、1つ以上の「メディアフロー」で構成することができ、各メディアフローは、1つの方向での、音声データ又はビデオデータの転送である。例えば、「一方向ビデオ」ストリームは、IPカメラアクセサリ2404からコントローラ2402への1つのビデオフローを含み得る。「一方向音声」ストリームは、IPカメラアクセサリ2404からコントローラ2402への、1つの音声フローを含み得る。「一方向音声及びビデオ」ストリームは、IPカメラアクセサリ2404からコントローラ2402への、1つの音声フロー及び1つのビデオフローを含み得るものであり、それらの2つのフローを同期させることができる。「一方向ビデオ及び双方向音声」ストリームは、コントローラ2402からIPカメラアクセサリ2404への1つの音声フロー、及びIPカメラアクセサリ2404からコントローラ2402への2つのメディアフロー(1つのビデオ、1つの音声)を含み得るものであり、後者の2つのフローを同期させることができる。SDPは、メディア能力及びトランスポートパラメータを含む、メディアセッションを説明する命名法及びシンタックスを提供することができる。例えば、SDPは、以下の情報の説明をサポートする:メディアのタイプ(例えば、音声、ビデオ)、メディアのコーデック(例えば、LPCM音声、H.264ビデオ)、ネットワークトランスポート(例えば、受信IPアドレス及びポート)、ストリーム属性(例えば、受信専用、送信専用、送信及び受信)、及びメディアセキュリティ(例えば、SRTPを使用するか否か)。SDPはまた、コントローラとカメラアクセサリとの間のメディアセッションをネゴシエーションするための、簡便なモデルも提供することができ、このモデル内で、それらのデバイスは、相互に許容可能な、メディアのタイプ、メディアのコーデックなどのメディア設定に収斂する。
したがって、IPカメラストリーミングサービスの一部の代替的実装では、コントローラ(例えば、コントローラ2402)は、メディアセッション開始要求内に(例えば、要求2900内に含まれるデータオブジェクト内に)、SDP提案を含み得る。この要求を受信するアクセサリ(例えば、IPカメラアクセサリ2404)は、そのメディアセッション開始要求に対する応答内に(例えば、応答3000内に含まれるデータオブジェクト内に)、メディアセッション要求に対する応答の一部として、SDP応答を含み得る。
再び図28を参照すると、ストリーミングセッションが確立されると、ブロック2816で、IPカメラアクセサリ2404は、コントローラ2404(又は、メディアセッション開始要求内で指定されるような、他の宛先デバイス)への、メディアのストリーミングを開始することができる。ストリーミングされる具体的なメディア及びストリーミングフォーマットは、アクセサリのIPストリーミングサービスの特性に応じて決定することができ、例えばストリーミングは、ビデオ及び/又は音声を含み得る。更には、一部の場合には、ストリーミングサービスは逆方向のフローをサポートすることができ、そのフローは同時に開始することができる。コントローラ2402(又は、他の宛先デバイス)は、受信したメディアをユーザに提示することができ、かつ/又は、受信したメディアを、後に提示するために記憶することもできる。メディアコンテンツのストリーミングは、無期限に継続することができる。
いずれかの時点で、ユーザは、ブロック2818で、例えば、ユーザインタフェースの「停止」コントロールを操作することによって、コントローラ2402に、メディアストリーミングを停止するように命令することができる。それに応答して、ブロック2820で、コントローラ2402は、メディアセッション終了要求を生成して、IPカメラアクセサリ2404に送信することができる。図31は、要求2900及び応答3000が交換された実施形態に関する、メディアセッション終了要求メッセージ3100の実施例を示す。メディアセッション開始要求2900と同様に、メディアセッション終了要求3000は、HTTP PUT要求とすることができる。要求メッセージ3100は、メッセージボディ3102を有し得る。メッセージボディ3102は、書き込まれることになるインスタンスの、インスタンス識別子3104を含み得る(インスタンスID10は、IPカメラサービスインスタンス2704(図27B)に関するセッション終了特性に対応する)。値3106は、コントローラ2402とのストリーミングセッションを終了するためにIPカメラアクセサリ2404によって使用可能な、情報を含み得るものであり、この実施例では、セッション識別子で十分である。
再び図28を参照すると、ブロック2822で、アクセサリ2404は、その要求に対する応答を送信することができる。図32は、アクセサリ2404が、図31の要求3100に応答して生成することが可能なメディアセッション終了応答3200の実施例を示す。応答メッセージ3200は、メッセージボディ3202を有し得る。メッセージボディ3202は値3204を含み得る。値3204は、エラーが発生したか否かを示すエラーコードを含み得る。このエラーコードは、メディアセッション開始要求に応答するためのエラーコードと同様に定義することができる。
ブロック2824で、IPカメラアクセサリ2404は、コントローラ2402への、メディアのストリーミングを停止することができる。(定義されたストリームが、逆方向のフローを含む場合には、そのフローを同時に終了することができる。)ブロック2824の後、コントローラ2402及びアクセサリ2404は、ペア検証済みセッションのままに留まることができ、コントローラ2402は、そのペア検証済みセッション内で、再びストリーミングを開始することができ、かつ/又は、コントローラ2402の他の機能を呼び出すこともできる。
プロセス2800は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。順次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。異なるコンテキストでは、ユーザは、プロセス2800の適切な部分を使用して、IPカメラアクセサリ2404と対話することができる。一部の実施形態では、メディアセッションの開始又は終了などの、特定のアクションを実行する前に、ペア検証が必要とされる場合があり、又はペア検証は、IPカメラストリーミングサービスとのあらゆる対話の、前提条件とすることができる。ペア検証済みセッション内では、全ての要求及び応答は、暗号化することができる。更には、SDP、RTP、及びSRDPなどの特定のメディア関連プロトコルが、例示の目的のために使用されるが、他のプロトコルで置き換えることもできる。
プロセス2800は、限定するものではないが、メディアキャプチャ動作を含めた、ユーザがコントローラを操作してペアリング済みアクセサリを制御することによって実行することが可能な、多種多様な対話式制御動作の実施例として理解することができる。アクセサリが実行することが可能な、任意のタイプの機能又は動作を、本明細書で説明されるものと同様のプロセスを使用して制御することができる。
実施例:ストリーミングインタフェース
一部のアクセサリは、それらのアクセサリ自体とコントローラとの間の、IPストリーミングをサポートすることができる。上記のIPカメラの実施例と同様のリアルタイムメディアストリーミングは1つの選択肢であるが、他のタイプのデータストリーミングもまたサポートすることができる。例えば、TCP又はUDPストリーミングをサポートすることができる。一部の実施形態では、アクセサリは、全てのデータを暗号化された形態でストリーミングすることが必要とされる場合がある。例えば、TCPストリームに関しては、TLS−PSK(ChaCha20/Poly1305)を使用することができ、その一方で、UDPストリームに関しては、DTLS−PSK(ChaCha20/Poly1305)を使用することができる。一部の実施形態では、IPストリーミングの実施は、上述のIPカメラサービスの実施例と同様のものとすることができる。代替的実施もまた、可能である。ここで一実施例を説明する。
図33は、本発明の実施形態による、IPストリーミングサービス3301に関する例示的なサービス定義を示す。これらの特性は、図34で、Streaming capabilities特性3401、Streaming control input特性3402、及びStreaming control result3403として定義される。これらの特性のそれぞれはデータオブジェクトとすることができ、それらのキー及び値は、示されるようなものとすることができる。各特性3401〜3403内には、任意選択的な「protocol−info」キー(その値がオブジェクトであるもの)が含まれており、このキーを使用して、更なるプロトコル固有メタデータを提供することができる。
この実施例では、コントローラは、ストリームを開くか又は閉じるために、Streaming control input特性3402に書き込むことができ、Streaming control result特性3403を読み取ることによって、ストリーミングの状態を取得することができる。例えば、上述のように、ペアリング済みコントローラは、Streaming control result特性3403に関するイベント通知に加入することができ、アクセサリは、Streaming control result特性3403の値が変化する場合は常に、非請求のイベント応答をコントローラに送信することができる。更には、ペアリング済みコントローラはまた、Streaming control result特性3403を(例えば、上述のようなHTTP GET要求を使用して)読み取ることもできる。
一部の実施形態では、アクセサリは、インライン結果又は問い合わせ結果のいずれで応答するかを、1回の要求ごとに判定する選択肢を有し得る。インライン結果及び問い合わせ結果の実施例は、図5G〜図5Kを参照して上述されており、このコンテキストで適用することができる。この実施例では、「on」は、IPストリーミングサービス3301の特性としては示されず、必要に応じて、その定義内に含めることができる。
IPストリーミングをサポートするアクセサリは、そのアクセサリモデル内に、IPストリーミングサービスを含み得る。本開示を入手可能な当業者には、JSON又は他の記述言語若しくは表記法で、適切な表現を構成することが可能となるであろう。
図35は、本発明の実施形態による、コントローラによって実行することが可能なIPストリーミングに関するプロセス3500の、フローチャートである。ブロック3502で、コントローラは、図33及び図34で定義されるようなIPストリーミングサービスを有するアクセサリと、ペアリングすることができる。例えば、上述のペア設定及びペア検証プロセスを使用することができ、コントローラは、アクセサリ定義レコードを読み取ることにより、そのアクセサリがIPストリーミングサービスを有することを判定することができる。
ブロック3504で、コントローラは、例えば、Streaming capabilities特性3401に向けられたHTTP GET要求を送信することによって、アクセサリからStreaming capabilities特性3401を読み取ることができる。この要求は上述の実施例に従って構築することができる。ブロック3506で、コントローラは、ストリーム識別子を生成することができ、識別子を生成する従来技術(例えば、UUID)を使用することができる。ブロック3508で、コントローラは、例えば1の要求タイプと、ブロック3506で生成されたストリーム識別子に設定されたストリームidとを有するHTTP PUT要求を、Streaming control input特性3402に送信することによって、「ストリームを開く」要求をアクセサリに送信することができる。このストリーミングセッションに関して使用する、IPアドレス及びポートなどの他の情報を、例えば、protocol−infoオブジェクト内に含めることができる。この要求は上述の実施例に従って構築することができる。
ブロック3510で、コントローラは、アクセサリからの応答を受信することができる。一部の実施形態では、この応答は、インライン結果応答(例えば、図5Iの応答573と同様のもの)、又は、トランザクションidを確立した後に続けて、コントローラがStreaming control result特性3403を読み取り、確立されたトランザクションidを参照する、問い合わせ結果応答(例えば、図5Jの応答574、及び図5Kの後続の要求578と同様のもの)のいずれかとすることができる。いずれの場合にもこの応答は、ポート識別子と、ストリーミングセッションに接続するためにコントローラによって使用可能な任意の他の情報とを含み得る。
ブロック3512で、コントローラは、この応答内で提供された情報を使用して、ストリーミングセッションに接続することができる。ブロック3514で、コントローラは、データストリームに関する暗号化を設定することができる。例えば、TLS又はDTLS暗号化(例えば、http://tools.ietf.org/html/draft−keoho−lwig−dtls−iot−01で入手可能な、IETF RFC4279又はIETF Internet Draft draft−keoho−lwig−dtls−iot−01で文書化されているような、トランスポート層セキュリティ又はデータグラムトランスポート層セキュリティ)に関するキーを、ペア設定若しくはペア検証の間に(ブロック3502で)生成された共有シークレット、及び(ブロック3506で生成された)ストリームIDから導出することができる。アクセサリは、同じ情報からキーを導出することができる。ブロック3516で、これらのデバイスは、暗号化されたデータをストリーミングすることができる。データは、必要に応じて、一方又は双方の方向で(コントローラからアクセサリへ、及び/又はアクセサリからコントローラへ)流れることができる。
コントローラが、ストリームを中断することを決定すると、ブロック3518で、コントローラは、例えば、2の要求タイプと、ブロック3506で生成されたストリーム識別子に設定されたストリームidとを有するHTTP PUT要求を、Streaming control input点特性3402に送信することによって、「ストリームを閉じる」要求を送信することができる。この要求もまた、上述の実施例に従って構築することができる。ブロック3520で、コントローラは、アクセサリがポートを閉じたことを確認する応答を受信することができる。この応答はブロック3510での応答と同じ方式で提供することができる。
プロセス3500は例示的なものであり、変型及び修正が可能であることが理解されるであろう。順次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。ストリーミングサービスは、アクセサリとコントローラとの間で、任意の種類のデータをいずれかの方向で安全にストリーミングするための汎用IPストリーミングインタフェースを提供することができる。図示の実施例では、TCP及びUDPは、リアルタイムプロトコルではない。他の実施形態は、例えば上述のIPカメラストリーミングサービス、又は同様のサービスを使用して、リアルタイムストリーミングを提供することができる。
一部の実施形態では、コントローラは、アクセサリが、その状態が変化した場合には(例えば、ストリーミング中にエラーが発生した場合には)コントローラに警告することを可能にする通知に加入することができる。例えば、図34を参照すると、コントローラは、Streaming control result特性3403に関するイベント通知(又は、サポートすることが可能な他のタイプの通知)に加入することができる。ストリーミング状態が、アクセサリ側で変化した場合には、アクセサリは、状態コードを更新して、コントローラへの通知(例えば、上述のような非請求のイベントメッセージ)を生成することができる。
例示的デバイス
本明細書で説明される実施形態は、全般的に従来の設計のものとすることが可能な、電子デバイス内に実装することができ、この電子デバイスは、コントローラ(第1の電子デバイス)がアクセサリ(第2の電子デバイス)の動作を制御することが可能なコマンド及び制御動作をサポートする統一的アクセサリプロトコルに適合するように、適応させることができる。
図36は、本発明の実施形態による、コントローラ3600の簡略ブロック図である。コントローラ3600は、本明細書で説明されるコントローラの機能、挙動、及び能力のうちのいずれか若しくは全て、並びに、明示的には説明されない他の機能、挙動、及び能力を実行することができる。コントローラ3600は、処理サブシステム3610、記憶デバイス3612、ユーザインタフェース3614、通信インタフェース3616、セキュア要素3618、及び暗号化論理モジュール3620を含み得る。コントローラ3600はまた、バッテリ、電力コントローラ、及び、様々な強化能力を提供するように動作可能な他の構成要素などの、他の構成要素(明示的には図示せず)も含み得る。様々な実施形態では、コントローラ3600は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、又は、任意の所望のフォームファクタを有する他のシステム内に実装することができる。更には上述のように、コントローラ3600は基地局内に部分的に実装することができ、及び、その基地局と通信してユーザインタフェースを提供する移動ユニット内に、部分的に実装することができる。
記憶デバイス3612は、例えばディスク、フラッシュメモリ、又は任意の他の非一時的記憶媒体、若しくは媒体の組み合わせを使用して実装することができ、揮発性及び/又は不揮発性の媒体を含み得る。一部の実施形態では、記憶デバイス3612は、コントローラによって実行されるものとして本明細書で説明される、いずれか又は全ての動作を実行するプログラムを含めた、処理サブシステム3610によって実行されることになる1つ以上のアプリケーションプログラム及び/又はオペレーティングシステムプログラムを、記憶することができる。例えば、記憶デバイス3612は、アクセサリ定義レコードを読み取り、その中の情報に基づいて、そのアクセサリを制御するためのグラフィカルユーザインタフェースを生成することが可能な、統一的コントローラアプリケーションを記憶することができる。一部の実施形態では、本明細書で説明されるコントローラ機能性の諸部分(又は全て)は、アプリケーションではなく、オペレーティングシステムプログラム内で実施することができる。一部の実施形態では、記憶デバイス3612はまた、特定のアクセサリに関して、又は特定のカテゴリのアクセサリに関して設計されたアプリ(例えば、IPカメラアクセサリを管理するIPカメラアプリ、又はドアロックアクセサリと対話するセキュリティアプリ)も記憶することができる。
ユーザインタフェース3614は、タッチパッド、タッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、マイクロホンなどの入力デバイス、並びに、ビデオスクリーン、インジケータランプ、スピーカ、ヘッドホンジャックなどの出力デバイスを、サポートする電子機器(例えば、デジタル−アナログ又はアナログ−デジタルコンバータ、信号プロセッサなど)と共に含み得る。ユーザは、ユーザインタフェース3614の入力デバイスを操作して、コントローラ3600の機能性を呼び出すことができ、またユーザインタフェース3614の出力デバイスを介して、コントローラ3600からの出力を見ること及び/又は聞くことができる。
処理サブシステム3610は、1つ以上の集積回路、例えば、1つ以上のシングルコア若しくはマルチコアマイクロプロセッサ、又はマイクロコントローラとして実施することができ、それらの実施例は、当該技術分野において既知である。動作時には、処理システム3610は、コントローラ3600の動作を制御することができる。様々な実施形態では、処理サブシステム3610は、プログラムコードに応答して様々なプログラムを実行することができ、同時に実行されている複数のプログラム又はプロセスを維持することができる。任意の所定の時点で、実行されるプログラムコードのうちの一部又は全ては、処理サブシステム3610内に、及び/又は記憶デバイス3612などの記憶媒体内に存在し得る。
好適なプログラミングを通じて、処理サブシステム3610は、コントローラ3600に関する様々な機能性を提供することができる。例えば、一部の実施形態では、処理サブシステム3610は、コントローラによって実行されるものとして上述された様々なプロセス(又は、その諸部分)を実行することができる。処理サブシステム3610はまた、記憶デバイス3612内に記憶することが可能なプログラムを含めた、コントローラ3600の他の機能を制御する他のプログラムも、実行することができる。一部の実施形態では、これらのプログラムは、例えば、アクセサリに送信されるメッセージを生成し、かつ/又はアクセサリからのメッセージを受信することによって、アクセサリと対話することができる。そのようなメッセージは、上述のような統一的アクセサリプロトコルに適合し得る。
通信インタフェース3616は、コントローラ3600に関する、音声及び/又はデータ通信能力を提供することができる。一部の実施形態では、通信インタフェース3616は、無線音声及び/又はデータネットワークにアクセスするための、無線周波数(RF)トランシーバ構成要素(例えば、セルラー電話技術、3G、4G/LTEなどのデータネットワーク技術、Wi−Fi(IEEE 802.11ファミリ規格)、又は他の移動通信技術、若しくはこれらの任意の組み合わせを使用するもの)、近距離無線通信用の構成要素(例えば、Bluetooth及び/又はBluetooth LE規格、NFCなどを使用するもの)、及び/又は他の構成要素を含み得る。一部の実施形態では、通信インタフェース3616は、無線インタフェースに加えて、又はその代わりに、有線ネットワーク接続性(例えば、Ethernet(登録商標))を提供することができる。通信インタフェース3616は、ハードウェア構成要素(例えば、ドライバ回路、アンテナ、変調器/復調器、エンコーダ/デコーダ、並びに他のアナログ及び/又はデジタル信号処理回路)及びソフトウェア構成要素の組み合わせを使用して、実装することができる。一部の実施形態では、通信インタフェース3616は、同じトランスポート又は異なるトランスポートを使用して、複数の通信チャネルを同時にサポートすることができる。
セキュア記憶モジュール3618は、コントローラ3600に関する暗号情報を安全に記憶することが可能な、集積回路などとすることができる。セキュア記憶モジュール3618内に記憶することが可能な情報の例としては、コントローラの長期公開キー及び長期秘密キー3622(上述のようなLTPKC、LTSKC)、及びペアリング済みアクセサリのリスト3627(例えば、上述のようなペア設定又はペア追加プロセスを完了しているアクセサリに関する、アクセサリ長期公開キーLTPKAにアクセサリIDを対応付けするルックアップテーブル)が挙げられる。
一部の実施形態では、暗号化動作は、セキュア記憶モジュール3618と通信する暗号化論理モジュール3620内で実施することができる。物理的に、暗号化論理モジュール3620は、必要に応じて、セキュア記憶モジュール3618と同じ集積回路、又は異なる集積回路(例えば、処理サブシステム3610内のプロセッサ)内に実装することができる。暗号化論理モジュール3620は、上述のいずれか又は全ての暗号化動作を含めた、コントローラ3600の暗号化動作を実施又はサポートする、様々な論理回路(必要に応じて、固定されるか、又はプログラム可能なもの)を含み得る。セキュア記憶モジュール3618及び/又は暗号化論理モジュール3620は、コントローラ3600の残部には「ブラックボックス」として現れ得る。それゆえ、例えば、通信インタフェース3616は、その通信インタフェース3616が復号することができない、暗号化された形態のメッセージを受信することができ、そのメッセージを、処理サブシステム3610に単純に配信することができる。処理サブシステム3610もまた、そのメッセージを復号することは不可能であるが、そのメッセージを暗号化されたものとして認識して、暗号化論理モジュール3620に配信することができる。暗号化論理モジュール3620は、そのメッセージを(例えば、セキュア記憶モジュール3618から抽出された情報を使用して)復号し、いずれの情報を処理サブシステム3610に返すべきかを判定することができる。結果として、特定の情報はセキュア記憶モジュール3618及び暗号化論理モジュール3620内でのみ利用可能となり得る。セキュア記憶モジュール3618及び暗号化論理モジュール3620が、内部セキュアレポジトリからのコードのみを実行する、単一の集積回路上に実装される場合には、このことは、情報の抽出を極めて困難にさせることができ、このことにより、高度のセキュリティを提供することができる。他の実装もまた、可能である。
図37は、本発明の実施形態による、アクセサリ3700の簡略ブロック図である。アクセサリ3700は、本明細書で説明されるアクセサリの機能、挙動、及び能力のうちのいずれか若しくは全て、並びに、明示的には説明されない他の機能、挙動、及び能力を実施することができる。アクセサリ3700は、記憶デバイス3728、処理サブシステム3730、ユーザインタフェース3732、アクセサリ固有ハードウェア3734、通信インタフェース3736、セキュア要素3738、及び暗号化論理モジュール3740を含み得る。アクセサリ3700はまた、バッテリ、電力コントローラ、及び、様々な強化能力を提供するように動作可能な他の構成要素などの他の構成要素(明示的には図示せず)も含み得る。
アクセサリ3700は、コントローラ3600などのコントローラによって動作させることが可能な、広範なクラスのアクセサリを代表するものであり、そのようなアクセサリは、能力、複雑性、及びフォームファクタの点で、幅広く変化し得る。様々なアクセサリは、図37には明示的に示されない構成要素を含み得るものであり、それらの構成要素としては、固定式又は取り外し式の記憶媒体を有する記憶デバイス(ディスク、フラッシュメモリなど);ビデオスクリーン、スピーカ、又は、外部の音声/ビデオデバイスに接続するためのポート;レンズ、画像センサなどのカメラ構成要素、及びそれらに関するコントロール(例えば、絞り、ズーム、露光時間、フレームレートなど);音声を(単独で、又はビデオ録画と関連して)録音するマイクロホンなどが挙げられるが、これらに限定されない。
記憶デバイス3728は、例えば、ディスク、フラッシュメモリ、又は任意の他の非一時的記憶媒体、若しくは媒体の組み合わせを使用して実装することができ、揮発性及び/又は不揮発性の媒体を含み得る。一部の実施形態では、記憶デバイス3728は、アクセサリによって実施されるものとして上述された様々な動作、並びに特定のアクセサリ挙動に関連する動作を実行するプログラムを含めた、処理サブシステム3730によって実行されることになる1つ以上のプログラムを記憶することができる。記憶デバイス3728はまた、例えば上述のようなコントローラデバイスに提供することが可能な、(例えば上述のような)アクセサリオブジェクト又はアクセサリ定義レコードも記憶することができる。記憶デバイス3728はまた、アクセサリ状態情報、及びアクセサリ3700の動作の間に使用することが可能な任意の他のデータも記憶することができる。
処理サブシステム3730は、例えば、アクセサリ3700に関連付けられた様々な機能を実行するプログラムコードを実行する、1つ以上のシングルコア若しくはマルチコアマイクロプロセッサ及び/又はマイクロコントローラを含み得る。例えば、処理サブシステム3730は、アクセサリによって実施されるものとして本明細書で説明される、いずれか又は全ての動作を、例えば記憶デバイス3728内に記憶されたプログラムコードを実行することによって、実施することができる。処理サブシステム3730はまた、アクセサリ3730の他の機能を制御する、他のプログラムも実行することができる。一部の場合には、処理サブシステム3730によって実行されるプログラムは、例えば、コントローラに送信されるメッセージを生成し、かつ/又はコントローラからのメッセージを受信することによって、コントローラ(例えば、コントローラ3600)と対話することができる。そのようなメッセージは、上述のような統一的アクセサリプロトコルに適合し得る。
ユーザインタフェース3732は、タッチパッド、タッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、マイクロホンなどの、ユーザ操作可能な入力デバイス、並びに、ビデオスクリーン、インジケータランプ、スピーカ、ヘッドホンジャックなどの出力デバイスを、サポートする電子機器(例えば、デジタル−アナログ又はアナログ−デジタルコンバータ、信号プロセッサなど)と共に含み得る。具体的なアクセサリ3700の実装に応じて、ユーザは、ユーザインタフェース3732の入力デバイスを操作して、アクセサリ3700の機能性を呼び出すことができ、またユーザインタフェース3734の出力デバイスを介して、アクセサリ3700からの出力を見ること及び/又は聞くことができる。一部のアクセサリは、最小限のユーザインタフェースを提供する場合があり、又はユーザインタフェースを提供しない場合もある。
アクセサリ固有ハードウェア3734は、アクセサリ3700内に存在することにより、その機能性を有効化又はサポートすることが可能な、任意の他の構成要素を含み得る。例えば、様々な実施形態では、アクセサリ固有ハードウェア3734としては、固定式又は取り外し式記憶媒体を使用する1つ以上の記憶デバイス、GPS受信機、電力供給及び/又は電力管理回路、カメラ、マイクロホン、1つ以上のアクチュエータ、環境センサ(例えば、温度センサ、圧力センサ、加速度計、化学センサなど)などを挙げることができる。適切なアクセサリ固有ハードウェア3734を提供することによって、任意のタイプのアクセサリ機能性をサポートすることができる点を理解されたい。
通信インタフェース3736は、アクセサリ3700に関する、音声及び/又はデータ通信能力を提供することができる。一部の実施形態では、通信インタフェース3736は、無線音声及び/又はデータネットワークにアクセスするための、無線周波数(RF)トランシーバ構成要素(例えば、セルラー電話技術、3G、4G/LTEなどのデータネットワーク技術、Wi−Fi(IEEE 802.11ファミリ規格)、又は他の移動通信技術、若しくはこれらの任意の組み合わせを使用するもの)、近距離無線通信用の構成要素(例えば、Bluetooth及び/又はBluetooth LE規格、NFCなどを使用するもの)、及び/又は他の構成要素を含み得る。一部の実施形態では、通信インタフェース3736は、無線インタフェースに加えて、又はその代わりに、有線ネットワーク接続性(例えば、Ethernet)を提供することができる。通信インタフェース3736は、ハードウェア構成要素(例えば、ドライバ回路、アンテナ、変調器/復調器、エンコーダ/デコーダ、並びに他のアナログ及び/又はデジタル信号処理回路)及びソフトウェア構成要素の組み合わせを使用して、実装することができる。一部の実施形態では、通信インタフェース3736は、同じトランスポート又は異なるトランスポートを使用して、複数の通信チャネルを同時にサポートすることができる。
セキュア記憶モジュール3738は、アクセサリ3700に関する暗号情報を安全に記憶することが可能な、集積回路などとすることができる。セキュア記憶モジュール3738内に記憶することが可能な情報の例としては、アクセサリの長期公開キー及び長期秘密キー3742(上述のようなLTPKA、LTSKA)、及びペアリング済みコントローラのリスト3744(例えば、上述のようなペア設定又はペア追加プロセスを完了しているコントローラに関する、コントローラ長期公開キーLTPKCにコントローラIDを対応付けするルックアップテーブル)が挙げられる。
一部の実施形態では、暗号化動作は、セキュア記憶モジュール3738と通信する暗号化論理モジュール3740内で実施することができる。物理的に、暗号化論理モジュール3740は、必要に応じて、セキュア記憶モジュール3738と同じ集積回路、又は異なる集積回路(例えば、処理サブシステム3730内のプロセッサ)内に実装することができる。暗号化論理モジュール3740は、上述のいずれか又は全ての暗号化動作を含めた、アクセサリ3700の暗号化動作を実施又はサポートする、様々な論理回路(必要に応じて、固定されるか、又はプログラム可能なもの)を含み得る。セキュア記憶モジュール3738及び/又は暗号化論理モジュール3740は、アクセサリ3700の残部には「ブラックボックス」として現れ得る。それゆえ、例えば、通信インタフェース3736は、その通信インタフェース3736が復号することができない、暗号化された形態のメッセージを受信することができ、そのメッセージを、処理サブシステム3730に単純に配信することができる。処理サブシステム3730もまた、そのメッセージを復号することは不可能であるが、そのメッセージを暗号化されたものとして認識して、暗号化論理モジュール3740に配信することができる。暗号化論理モジュール3740は、そのメッセージを(例えば、セキュア記憶モジュール3738から抽出された情報を使用して)復号し、いずれの情報を処理サブシステム3730に返すべきかを判定することができる。結果として、特定の情報は、セキュア記憶モジュール3738及び暗号化論理モジュール3740内でのみ利用可能となり得る。セキュア記憶モジュール3738及び暗号化論理モジュール3740が、内部セキュアレポジトリからのコードのみを実行する、単一の集積回路上に実装される場合には、このことは、情報の抽出を極めて困難にさせることができ、このことにより高度のセキュリティを提供することができる。他の実装もまた可能である。
アクセサリ3700は、コントローラ3600などのコントローラと対話する、任意の電子装置とすることができる。一部の実施形態では、コントローラ3600は、上述のようなアクセサリ3700の動作に対するリモート制御を提供することができる。例えば、コントローラ3600は、入力コントロール及び出力コントロール(例えば、アクセサリ3700から取得した現在の状態情報を表示するディスプレイスクリーン、及び状態情報に対する変更を可能にするタッチスクリーンオーバーレイなどの入力コントロール)の双方を含み得る、アクセサリ3700に関するリモートユーザインタフェースを提供することができる。様々な実施形態でのコントローラ3600は、アクセサリ3700の任意の機能を制御することができ、また、アクセサリ3700からデータを受信することもできる。
図38は、本発明の実施形態による、コントローラ3800に関するコントローラアーキテクチャの実施例を示す。このコントローラアーキテクチャは、対話式サブシステムのセットとして示され、各サブシステムは、1つ以上のモジュールを含む。これらのモジュールのそれぞれは、1つ以上のプログラム可能プロセッサ上、及び/又は1つ以上の固定機能プロセッサ内で実行される、プログラムコードを使用して実行することができ、それらのプロセッサ(単数又は複数)は、他のハードウェアデバイス(例えば、アクチュエータ、ディスプレイなど)を制御するための出力信号伝達、及び/又は他のハードウェアデバイス(例えば、キーボード;タッチスクリーン;アクチュエータ、モータ、又はセンサからのフィードバック若しくは状態信号など)からの信号を受信するための入力信号伝達を含み得ることを理解されたい。これらのサブシステムのうちの一部は、任意のタイプの不揮発性記憶デバイス(例えば、半導体フラッシュメモリ、EEPROM、磁気ディスク又は光ディスクなど)を使用して実装することが可能な、永続的データ記憶装置を含み得る。図示されていないが、これらのサブシステムのうちの一部又は全ては、ディスプレイ、キーボード、タッチスクリーン、マイクロホン、スピーカ、センサなどの更なるハードウェア要素を含み得る。
セキュリティサブシステム3802は、セキュア記憶要素3804、ペア設定モジュール3806、ペア検証モジュール3808、ペア追加モジュール3810、ペア除去モジュール3812、及び暗号化論理モジュール3814を含み得る。セキュア記憶要素3804は、上述のセキュア記憶要素3618又は他のセキュア記憶要素と、同様若しくは同一のものとすることができる。一部の実施形態では、セキュア記憶要素3804は、コントローラ3800に関する長期公開/秘密キーペア(例えば、上述のようなLTPKC、LTSKC)、並びに、コントローラ3800がペアリングを確立した各アクセサリに関するペアリングレコードを安全に記憶するために使用される。上述のように、各ペアリングレコードは、ペアリング済みアクセサリの識別子、ペアリング済みアクセサリの長期公開キー、及び任意選択的に、ペアリング済みアクセサリとのコントローラ3800の対話に関する許可設定(例えば、コントローラ3800が、管理者許可を有するか否か)を含み得る。コントローラ3800が、種々のアクセサリに関連する種々の長期公開キーを使用する実施形態では、各ペアリングレコードはまた、ペアリング済みアクセサリと共に使用される長期公開キーの標識も含み得る。必要に応じて他の情報を含めることができる。
ペア設定モジュール3806は、ペア設定プロセスのコントローラ部分を実行することができる。ペア設定プロセスは、コントローラ3800及びアクセサリが、その後に各デバイスが他方のアイデンティティを検証するために使用することが可能な長期公開キーを、安全に交換する任意のプロセスとすることができる。一部の実施形態では、ペア設定プロセスは、アクセサリのアイデンティティを検証するための、コントローラ3800とアクセサリとの間での情報項目の帯域外交換(例えば、設定コード、アクセサリのセキュリティ証明書の検証)を含み得る。上述のペア設定プロセス(例えば、プロセス1300、1400、1500、及び/又はプロセス1600)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア設定モジュール3806は、ペア設定の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム3850(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア設定モジュール3806は、ペア設定プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3814の機能を呼び出すことができる。
ペア検証モジュール3808は、ペア検証プロセスのコントローラ部分を実行することができる。ペア検証プロセスは、コントローラ3800及びアクセサリが、以前に記憶された長期公開キーを使用して、他方のデバイスのアイデンティティを検証する、任意のプロセスとすることができる。上述のペア検証プロセス(例えば、プロセス1700)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア検証モジュール3808は、ペア検証の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム3850(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア検証モジュール3808は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3814の機能を呼び出すことができる。
ペア追加モジュール3810は、ペア追加プロセスのコントローラ部分を実行することができる。ペア追加プロセスは、コントローラ3800が、アクセサリとのペアリングを確立した後に、そのアクセサリがペアリングを確立することになる「新規」コントローラに関する長期公開キーをそのアクセサリに提供する、任意のプロセスとすることができ、この新規コントローラは、コントローラ3800とは異なるデバイスとすることができる。上述のペア追加プロセス(例えば、プロセス1800)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア追加モジュール3810は、ペア追加の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム3850(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア追加モジュール3810はまた、追加される新規コントローラに関する長期公開キー(又は、証明書)を取得するために、別のコントローラ又は他の外部のキー情報源と通信することもできる。一部の実施形態では、ペア追加モジュール3810は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3814の機能を呼び出すことができる。
ペア除去モジュール3812は、ペア除去プロセスのコントローラ部分を実行することができる。ペア除去プロセスは、コントローラ3800が、アクセサリとのペアリングを確立した後に、そのアクセサリによってペアリングが除去されることになるコントローラの識別子を、そのアクセサリに提供する、任意のプロセスとすることができ、この除去されるコントローラは、コントローラ3800とは異なるデバイスとすることができる。上述のペア除去プロセス(例えば、プロセス1900)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア除去モジュール3812は、ペア除去の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム3850(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア除去モジュール3812はまた、除去されるコントローラに関する識別情報を取得するために、別のコントローラ又は他の外部の情報源と通信することもできる。一部の実施形態では、ペア除去モジュール3808は、ペア除去プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3812の機能を呼び出すことができる。
暗号化論理モジュール3814は、コントローラ3800によって使用可能な暗号化アルゴリズムを実行することができる。例としては、キー生成アルゴリズム;SRPで使用されるアルゴリズム及び関数;ハッシュアルゴリズム;ChaCha20−Poly1305、Curve25519、Ed25519、及び/又は他のアルゴリズムなどの、キーベースの暗号化/復号アルゴリズムが挙げられる。一部の実施形態では、暗号化論理モジュール3814は、暗号化アルゴリズム及び関連サービスを呼び出すために、コントローラ3800の他のモジュールによって使用可能な、API(アプリケーションプログラムインタフェース)を提供することができる。任意数及び任意の組み合わせの、暗号化アルゴリズム並びに関連サービスを、サポートすることができる。
ユーザ対話サブシステム3830は、コントローラ3800のユーザとの対話を管理することができる。例えば、ユーザインタフェース生成モジュール3832は、例えばディスプレイデバイス上に、ユーザに提示されるユーザインタフェースを生成することができる。このユーザインタフェースは、アクセサリと対話するためにユーザによって操作可能な、制御要素を含み得る。例えば、上述のように、コントローラ3800は、アクセサリオブジェクト内で提供される情報に基づいて、グラフィカルユーザインタフェースをレンダリングすることができる。ユーザ入力受信モジュール3834は、ユーザインタフェースからの入力を受信して、その入力に応答して行うべきアクション(例えば、アクセサリに送信されるメッセージを生成すること)を決定するために、その入力を処理することができる。一部の実施形態では、ユーザ入力受信モジュール3834は、ユーザ入力に応答して、コントローラ3800の他のモジュールの機能を呼び出すことができる。
アクセサリ対話サブシステム3850は、コントローラ3800とアクセサリとの対話をサポートすることができる。アクセサリオブジェクト記憶要素3852は、揮発性又は不揮発性の記憶媒体(例えば、半導体フラッシュメモリ、EEPROM、DRAM、SRAM、磁気ディスク又は光ディスクなど)を使用して実装することができる。一部の実施形態では、アクセサリオブジェクト記憶要素3852は、コントローラ3800が情報を有する各アクセサリの、表現を記憶するために使用することができる。例えば、上述のように、アクセサリとペアリングを確立した後、コントローラ3800などのコントローラは、そのアクセサリから、1つ以上のアクセサリオブジェクトを含み得る、アクセサリ定義レコードを取得することができる。コントローラ3800は、そのように取得したアクセサリオブジェクトを、アクセサリオブジェクト記憶要素3852内に記憶することができる。記憶されたアクセサリオブジェクトは、ユーザインタフェースを(例えば、ユーザインタフェース生成モジュール3832によって)生成すること、ユーザ入力を(例えば、ユーザ入力受信モジュール3834によって)解釈すること、アクセサリに対する要求を生成すること、及び/又はアクセサリから応答若しくは通知を受信することを含めた、数多くの方式で使用することができる。
アクセサリ発見モジュール3854は、アクセサリの発見に関連する動作、例えば、一斉配信をリッスンすること、発見したアクセサリとペアリングするか否かを判定することなどを実行することができる。例えば、アクセサリ発見モジュール3854は、図4を参照して上述されたコントローラ動作を実施することができる。
要求生成モジュール3856は、アクセサリに対する要求を生成して、送信することができる。例えば、ユーザ入力受信モジュール3834からの(例えば、ドアをロック解除する)命令に応答して、要求生成モジュール3856は、アクセサリに対する適切な(例えば、上述のようなロック状態特性に書き込む)要求メッセージを生成することができる。要求メッセージの実施例は、上述されている。一部の実施形態では、メッセージを生成することは、そのメッセージを暗号化することを含み得るものであり、要求生成モジュール3856は、その要求を生成することに関連して、暗号化論理モジュール3814によってサポートされる機能を呼び出すことができる。一部の実施形態では、要求生成モジュール3856は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、アクセサリに対する要求(例えば、図13〜図19を参照して上述された要求のうちのいずれか)を生成して送信するために、セキュリティサブシステム3802と対話することができる。
応答処理モジュール3858は、アクセサリから受信することが可能な、要求メッセージに対する任意の応答を、受信して処理することができる。例えば、要求生成モジュール3856が、アクセサリに(例えば、上述のようなロック状態特性に書き込む)要求メッセージを送信した後、応答処理モジュール3858は、アクセサリから応答メッセージを受信することができ、そのメッセージを解釈することができる。一部の実施形態では、この応答メッセージは、暗号化された形態で受信することができ、応答処理モジュール3858は、その応答を解釈することに関連して、暗号化論理モジュール3814によってサポートされる機能を呼び出すことができる。応答処理モジュール3858はまた、その応答に基づいて、ユーザインタフェースサブシステム3830に、情報(例えば、状態コード、エラーが発生したか否かなど)を提供することもでき、ユーザインタフェースサブシステム3830は、この情報に基づいて、ユーザへのフィードバックを生成することができる。一部の実施形態では、応答処理モジュール3858はまた、応答メッセージ内に含まれる情報に基づいて、アクセサリオブジェクト記憶要素3852を更新することもできる。一部の実施形態では、応答処理モジュール3858は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、アクセサリから受信される応答(例えば、図13〜図19を参照して上述された応答のうちのいずれか)を受信して処理するために、セキュリティサブシステム3802と対話することができる。
通知処理モジュール3860は、アクセサリから受信することが可能な通知メッセージを、受信して処理することができる。上述のように、様々な通知メカニズムをサポートすることができ、通知処理モジュール3860は、これらの通知メカニズムのうちのいずれか又は全て(例えば、上述のプロセス700、800、900、1000のうちのいずれか又は全て)をサポートすることができる。例えば、受動的通知の場合には、通知処理モジュール3860は、アクセサリによって報告される状態カウンタ値と、記憶されている(例えば、アクセサリオブジェクト記憶要素3852内の)状態カウンタ値とを比較することができ、不一致を検出することができる。一部の実施形態では、不一致を検出すると、通知処理モジュール3860は、更なる状態情報(例えば、更新されたアクセサリ定義レコード、又はその諸部分)を取得するために、要求生成モジュール3856に、アクセサリに対する要求を生成して送信するように命令することできる。広告式通知の場合には、通知処理モジュール3860は、アクセサリ発見モジュール3854を介して受信した広告を処理することにより、状態変化を有する既知のアクセサリを(例えば、アクセサリ記憶要素3852内に記憶されているアクセサリオブジェクトの状態カウンタに基づいて)検出することができる。イベント通知の場合には、応答処理モジュール3858によって、非請求の応答メッセージを受信することができ、応答処理モジュール3858は、そのメッセージを、非請求の応答(例えば、上述のようなEVENTメッセージ)として認識することができ、更なる処理のために、そのメッセージを通知モジュール3860に提供することができる。具体的な通知メカニズムに関わりなく、通知モジュール3860は、変化した状態情報の性質を判定して、ユーザ対話サブシステム3830に、適切な情報を提供することができる。一部の実施形態では、通知モジュール3860はまた、アクセサリオブジェクト記憶要素3852内の記憶されたアクセサリオブジェクトを更新することもできる。
通信インタフェースモジュール3870は、アクセサリを含めた他のデバイスとの通信をサポートする、サービスを提供することができる。一部の実施形態では、通信インタフェースモジュール3870は、Bluetooth LEプロトコルスタック3872及び/又はHTTP/IPプロトコルスタック3874を実行することができる。Bluetooth LEプロトコルスタック3872は、Bluetooth LEトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。HTTP/IPプロトコルスタック3874は、HTTP及びIPトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。Bluetooth LE及びHTTP/IPは、例示として使用されるものであるが、通信インタフェースモジュール3870内では、任意の組み合わせのトランスポートプロトコルをサポートすることができ、コントローラ3800の所定のインスタンスは、1つ以上のトランスポートプロトコルをサポートすることができる点を理解されたい。上述のように、コントローラ3800は、デバイス対話のクライアント/サーバモデル内で、クライアントデバイスとしての役割を果たし得るものであり、Bluetooth LEプロトコルスタック3872及び/又はHTTP/IPプロトコルスタック3874は、クライアント挙動をサポートするように構成することができる。
一部の実施形態では、通信インタフェースモジュール3870内のプロトコルスタックは、特定の非標準メッセージを認識するように修正することができる。例えば、上述のように、HTTP/IPプロトコルスタック3874は、アクセサリからの非請求「イベント」メッセージ(例えば、上述の図11Bのイベントメッセージ1120)を認識するように構成することができる。
一部の実施形態では、通信インタフェースモジュール3870は、外部デバイスに対するメッセージを送信及び/又は受信するために、他のモジュールによって使用可能な、APIを提供することができる。このAPIは、トランスポート非依存であるように設計することができ、具体的なメッセージに関するトランスポートの選択は、コントローラ3800内の他のモジュールに対しては透過的に、通信インタフェースモジュール3870内で実施することができる。コントローラ3800の通信ポート(図示せず)で受信されたメッセージは、そのポート構成に基づいて、Bluetooth LEスタック3872又はHTTP/IPスタック3874に送信することができ、Bluetooth LEスタック3872及びHTTP/IPスタック3874のそれぞれは、適切に構成された通信ポートに、発信メッセージを送信することができる。
図39は、本発明の実施形態による、アクセサリ3900に関するアクセサリアーキテクチャの実施例を示す。このアクセサリアーキテクチャは、対話式サブシステムのセットとして示され、各サブシステムは、1つ以上のモジュールを含む。これらのモジュールのそれぞれは、1つ以上のプログラム可能プロセッサ上、及び/又は1つ以上の固定機能プロセッサ内で実行される、プログラムコードを使用して実行することができ、それらのプロセッサ(単数又は複数)は、他のハードウェアデバイス(例えば、アクチュエータ、ディスプレイなど)を制御するための出力信号伝達、及び/又は他のハードウェアデバイス(例えば、キーボード;タッチスクリーン;アクチュエータ、モータ、又はセンサからのフィードバック若しくは状態信号など)からの信号を受信するための入力信号伝達を含み得ることを理解されたい。これらのサブシステムのうちの一部は、任意のタイプの不揮発性記憶デバイス(例えば、半導体フラッシュメモリ、EEPROM、磁気ディスク又は光ディスクなど)を使用して実装することが可能な、永続的データ記憶装置を含み得る。図示されていないが、これらのサブシステムのうちの一部又は全ては、ディスプレイ、キーボード、タッチスクリーン、マイクロホン、スピーカ、モータ、アクチュエータ、センサなどの、更なるハードウェア要素を含み得る。
セキュリティサブシステム3902は、セキュア記憶要素3904、ペア設定モジュール3906、ペア検証モジュール3908、ペア追加モジュール3910、ペア除去モジュール3912、及び暗号化論理モジュール3914を含み得る。セキュア記憶要素3904は、上述のセキュア記憶要素3738又は他のセキュア記憶要素と、同様若しくは同一のものとすることができる。一部の実施形態では、セキュア記憶要素3904は、アクセサリ3900に関する長期公開/秘密キーペア(例えば、上述のようなLTPKA、LTSKA)、並びに、アクセサリ3900がペアリングを確立した各コントローラに関するペアリングレコードを安全に記憶するために使用される。上述のように、各ペアリングレコードは、ペアリング済みコントローラの識別子、ペアリング済みコントローラの長期公開キー、及び任意選択的に、アクセサリ3900とのペアリング済みコントローラの対話に関する許可設定(例えば、特定のペアリング済みコントローラが、管理者許可を有するか否か)、及び/又はペアリング済みコントローラに関する加入設定(例えば、そのコントローラが、受動的モード以外の特定の通知モードに加入しているか否かの標識)を含み得る。アクセサリ3900が、種々のコントローラに関連する種々の長期公開キーを使用する実施形態では、各ペアリングレコードはまた、ペアリング済みコントローラと共に使用される長期公開キーの標識も含み得る。必要に応じて、他の情報を含めることができる。
ペア設定モジュール3906は、ペア設定プロセスのアクセサリ部分を実行することができる。ペア設定プロセスは、アクセサリ3900及びコントローラが、その後に各デバイスが他方のアイデンティティを検証するために使用することが可能な長期公開キーを、安全に交換する任意のプロセスとすることができる。一部の実施形態では、ペア設定プロセスは、アクセサリ3900のアイデンティティを検証するための、アクセサリ3900とコントローラとの間での情報項目の帯域外交換(例えば、設定コード、アクセサリのセキュリティ証明書の検証)を含み得る。上述のペア設定プロセス(例えば、プロセス1300、1400、1500、及び/又はプロセス1600)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア設定モジュール3806は、ペア設定の間のコントローラとの通信を達成するために、コントローラ対話サブシステム3950(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア設定モジュール3906は、ペア設定プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3914の機能を呼び出すことができる。
ペア検証モジュール3908は、ペア検証プロセスのアクセサリ部分を実行することができる。ペア検証プロセスは、アクセサリ3900及びコントローラが、以前に記憶された長期公開キーを使用して、他方のデバイスのアイデンティティを検証する任意のプロセスとすることができる。上述のペア検証プロセス(例えば、プロセス1700)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア検証モジュール3908は、ペア検証の間のアクセサリとの通信を達成するために、コントローラ対話サブシステム3950(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア検証モジュール3908は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3914の機能を呼び出すことができる。
ペア追加モジュール3910は、ペア追加プロセスのアクセサリ部分を実行することができる。ペア追加プロセスは、アクセサリ3900との確立済みペアリングを有するコントローラが、アクセサリ3900に、アクセサリ3900がペアリングを確立することになる「新規」コントローラに関する長期公開キーを提供する、任意のプロセスとすることができ、上述のペア追加プロセス(例えば、プロセス1800)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア追加モジュール3910は、ペア追加の間の、以前にペアリングされたコントローラとの通信を達成するために、コントローラ対話サブシステム3950(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア追加モジュール3910はまた、追加される新規コントローラに関する長期公開キー(又は、証明書)を取得するために、外部のキー情報源と通信することもできる。一部の実施形態では、ペア追加モジュール3910は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3914の機能を呼び出すことができる。
ペア除去モジュール3912は、ペア除去プロセスのアクセサリ部分を実行することができる。ペア除去プロセスは、アクセサリ3900との確立済みペアリングを有するコントローラが、アクセサリ3900によってペアリングが除去されることになるコントローラの識別子を、アクセサリ3900に提供する、任意のプロセスとすることができ、この除去されるコントローラは、ペア除去プロセスを呼び出すコントローラとは異なるデバイスとすることができる。上述のペア除去プロセス(例えば、プロセス1900)又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア除去モジュール3912は、ペア除去の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム3950(以下で説明されるもの)と対話することができる。一部の実施形態では、ペア除去モジュール3912はまた、除去されるコントローラに関する識別情報を取得するために、別のコントローラ又は他の外部の情報源と通信することもできる。一部の実施形態では、ペア除去モジュール3908は、ペア除去プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール3912の機能を呼び出すことができる。
暗号化論理モジュール3914は、アクセサリ3900によって使用可能な暗号化アルゴリズムを実行することができる。例としては、キー生成アルゴリズム;SRPで使用されるアルゴリズム及び関数;ハッシュアルゴリズム;ChaCha20−Poly1305、Curve25519、Ed25519、及び/又は他のアルゴリズムなどの、キーベースの暗号化/復号アルゴリズムが挙げられる。一部の実施形態では、暗号化論理モジュール3914は、暗号化アルゴリズム及び関連サービスを呼び出すために、アクセサリ3900の他のモジュールによって使用可能な、API(アプリケーションプログラムインタフェース)を提供することができる。任意数及び任意の組み合わせの、暗号化アルゴリズム並びに関連サービスを、サポートすることができる。
アクセサリアクションサブシステム3930は、例えば、コントローラ対話サブシステム3950を介してコントローラから受信した要求に応答して、アクセサリ3900のハードウェア構成要素及び/又はソフトウェア構成要素の様々な動作を管理することができる例えば、アクセサリ3900は、特定のアクション(例えば、ドアの開放又は閉鎖、カメラの操作など)を行うことが可能な、様々な動作構成要素3932を組み込む(又は、それらと通信する)ことができる。動作構成要素3932は、ハードウェア構成要素及び/又はソフトウェア構成要素を含み得るものであり、所定の動作構成要素3932は、エフェクタモジュール3934からの受信制御信号(例えば、デジタル又はアナログ形態の電気信号)に応答することができ、かつ/又は、フィードバックモジュール3936へのフィードバック信号(例えば、デジタル又はアナログ形態の電気信号)を生成することができる。
エフェクタモジュール3934は、例えば、ユーザによって要求される動作を達成又は実施するための、動作構成要素3932に対する制御信号を生成することができる。具体的な信号は、アドレスされている具体的な動作構成要素3932に応じて決定することができる。例示として、動作構成要素3932は、電力をオン又はオフに切り替えることが可能なスイッチング回路を含み得るものであり、エフェクタモジュール3932は、電力をオン又はオフにする、そのスイッチング回路に対する信号を生成することができる。別の実施例として、動作構成要素3932は、電気制御信号に応答して、物理的対象物の動作(例えば、デッドボルトのラッチ留め又はラッチ解除、ドアの開放又は閉鎖)を生じさせることが可能な、電気機械式アクチュエータを含み得るものであり、エフェクタモジュール3932は、そのアクチュエータに対する信号を生成することができる。更に別の実施例として、動作構成要素3932は、デジタルカメラを制御するためのAPIを含み得るものであり(実装に応じて、このカメラ自体が動作構成要素である場合もあれば、そうではない場合もある)、エフェクタモジュール3932は、そのデジタルカメラを制御するために、APIコールを呼び出すことができる。様々な実施形態では、エフェクタモジュール3934は、コントローラインタフェースサブシステム3950を介して受信された、コントローラからの要求、及び/又はアクセサリ3900のユーザインタフェースで受信された入力に応答して、動作することができる。
フィードバックモジュール3936は、動作構成要素3932からのフィードバック信号を受信することができる。具体的な信号は、具体的な動作構成要素3932に応じて決定することができる。例えば、スイッチング回路は、そのスイッチの現在の状態を示すフィードバック信号を提供することができる。電気機械式アクチュエータは、現在の状態(例えば、その物理対象物の位置及び/又は動作)を示すフィードバック信号を提供することができる。APIは、エラーコード又は状態コードを(例えば、APIコールから戻ると)提供することができる。更に別の実施例として、動作構成要素3932は、様々な環境条件に関する1つ以上のセンサ(例えば、運動センサ、位置センサ、温度センサ、障害物センサなど)を含み得るものであり、フィードバックモジュール3936は、それらのセンサからのセンサデータ信号を受信することができる。一部の実施形態では、フィードバックモジュール3936は、受信されたフィードバック信号に基づいて、コントローラ対話サブシステム3950にフィードバック情報を提供することができる。
コントローラ対話サブシステム3950は、アクセサリ3900とコントローラとの対話をサポートすることができる。アクセサリオブジェクト(単数又は複数)記憶要素3952は、揮発性又は不揮発性の記憶媒体(例えば、半導体フラッシュメモリ、EEPROM、DRAM、SRAM、磁気ディスク又は光ディスクなど)を使用して実装することができる。一部の実施形態では、アクセサリオブジェクト記憶要素3852は、アクセサリ3900と対話するためにコントローラによって使用することが可能な、1つ以上のアクセサリオブジェクトの表現を記憶するために使用することができる。記憶されたアクセサリオブジェクト(単数又は複数)は、要求に応じて(例えば、コントローラとのペア検証プロセスの実行後に)コントローラに供給することができ、記憶されたアクセサリオブジェクト(単数又は複数)は、アクセサリの状態が変化する場合に、更新することができる。例えば、フィードバックモジュール3936は、動作構成要素3932から受信したフィードバック信号に基づいて、記憶されたアクセサリオブジェクト(単数又は複数)を更新することができる。
発見モジュール3954は、広告を一斉配信すること、確立済みペアリングを有さないコントローラからの、ペア設定を実行する要求を受信することなどの、アクセサリ3900をコントローラに発見可能にさせることに関連する動作を、実行することができる。例えば、発見モジュール3954は、図4を参照して上述されたアクセサリ動作を実施することができる。
要求処理モジュール3956は、コントローラからの要求メッセージを受信して処理することができる。例えば、受信された要求メッセージ(例えば、上述のようなロック状態特性に書き込むもの)に応答して、要求処理モジュール3956は、その要求が許可されているか否か(例えば、ペア検証済み状態が、そのコントローラで存在するか否か、そのメッセージが、有効なセッションキーを使用して暗号化されているか否か、及び、そのコントローラが、要求されたアクションを実行するための許可を有するか否か)を判定することができる。要求が有効であると想定すると、要求処理モジュール3956は、エフェクタモジュール3934に対する(例えば、ロックメカニズムを作動させる)命令を生成することができる。一部の実施形態では、要求が許可されているか否かを判定することは、そのメッセージを復号することを含み得るものであり、要求処理モジュール3956は、その要求を処理することに関連して、暗号化論理モジュール3914によってサポートされる機能を呼び出すことができる。一部の実施形態では、要求処理モジュール3956は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、コントローラから受信される要求(例えば、図13〜図19を参照して上述された要求のうちのいずれか)を受信して処理するために、セキュリティサブシステム3902と対話することができる。
応答生成モジュール3958は、要求メッセージに対する応答を生成及び送信して、コントローラに応答メッセージを送信することができる。例えば、要求処理モジュール3956が要求を受信して、その要求が許可されていないと判定した場合には、要求処理モジュール3956は、そのように応答生成モジュール3958に通知することができ、応答生成モジュール3958は、エラー応答を生成することができる。その反対に、要求処理モジュール3956が要求を受信して、その要求が許可されていると判定した場合には、要求処理モジュール3956は、許可された要求が受信されており、エフェクタモジュール3934によって処理中であることを、応答生成モジュール3958に通知することができる。一部の実施形態では、応答モジュール3958は、フィードバックモジュール3936からフィードバック情報を受信することを待機して、次いで、そのフィードバック情報を組み込む応答メッセージを生成することができる。例えば、応答生成モジュール3958が、センサを読み取るか又はロックを開放する要求を受信した場合には、応答生成モジュール3958は、そのセンサの読み取り値、又はロックの開放の確認を、フィードバックモジュール3936から受信することを待機して、次いで、適切な応答メッセージ生成することができる。一部の実施形態では、この応答メッセージは、送信する前に暗号化することができ、応答生成モジュール3958は、そのメッセージを暗号化することに関連して、暗号化論理モジュール3914によってサポートされる機能を呼び出すことができる。一部の実施形態では、応答生成モジュール3958は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、コントローラに対する応答(例えば、図13〜図19を参照して上述された応答のうちのいずれか)を生成して送信するために、セキュリティサブシステム3902と対話することができる。
通知生成モジュール3960は、フィードバックモジュール3936から(例えば、アクセサリオブジェクト(単数又は複数)記憶要素3952内に記憶されたアクセサリオブジェクトが、更新される場合には常に)情報を受信することができ、その情報に基づいて、コントローラに対する通知メッセージを生成することができる。上述のように、様々な通知メカニズムをサポートすることができ、通知生成モジュール3960は、これらの通知メカニズムのうちのいずれか又は全て(例えば、上述のプロセス700、800、900、1000のうちのいずれか又は全て)をサポートすることができる。例えば、受動的通知の場合には、通知処理モジュール3960は、アクセサリオブジェクト(単数又は複数)記憶要素3952内に保持されている内部状態カウンタを、単純に更新することができる。広告式通知の場合には、通知生成モジュール3960は、状態カウンタを更新して、発見モジュール3954に、その更新された状態カウンタ値を含む広告を生成するように命令することができる。イベント通知の場合には、通知モジュール3960は、上述のような加入コントローラに送信する非請求の応答(例えば、上述のようなEVENTメッセージ)を生成するように、応答生成モジュール3958に命令することができる。一部の実施形態では、通知モジュール3960は、様々な通知メカニズム及び/又は様々な特性に関する、加入コントローラのリストを保持することができ、いずれかのコントローラが加入しているか否かに応じて、1つ以上のメカニズムを開始させることができる。一部の実施形態では、この加入情報は、アクセサリオブジェクト(単数又は複数)記憶要素3952内に保持することができる。
通信インタフェースモジュール3970は、コントローラを含めた他のデバイスとの通信をサポートする、サービスを提供することができる。一部の実施形態では、通信インタフェースモジュール3970は、Bluetooth LEプロトコルスタック3972及び/又はHTTP/IPプロトコルスタック3974を実施することができる。Bluetooth LEプロトコルスタック3972は、Bluetooth LEトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。HTTP/IPプロトコルスタック3974は、HTTP及びIPトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。Bluetooth LE及びHTTP/IPは、例示として使用されるものであるが、通信インタフェースモジュール3970内では、任意の組み合わせのトランスポートプロトコルをサポートすることができ、コントローラ3900の所定のインスタンスは、1つ以上のトランスポートプロトコルをサポートすることができる点を理解されたい。上述のように、アクセサリ3900は、デバイス対話のクライアント/サーバモデル内で、サーバデバイスとしての役割を果たし得るものであり、Bluetooth LEプロトコルスタック3872及び/又はHTTP/IPプロトコルスタック3874は、サーバ挙動をサポートするように構成することができる。
一部の実施形態では、通信インタフェースモジュール3970内のプロトコルスタックは、特定の非標準メッセージを生成するように修正することができる。例えば、上述のように、HTTP/IPプロトコルスタック3974は、アクセサリからの非請求「イベント」メッセージ(例えば、上述の図11Bのイベントメッセージ1120)を生成するように構成することができる。
一部の実施形態では、通信インタフェースモジュール3970は、外部デバイスに対するメッセージを送信及び/又は受信するために、他のモジュールによって使用可能な、APIを提供することができる。このAPIは、トランスポート非依存であるように設計することができ、具体的なメッセージに関するトランスポートの選択は、アクセサリ3900内の他のモジュールに対しては透過的に、通信インタフェースモジュール3970内で実施することができる。アクセサリ3900の通信ポート(図示せず)で受信されたメッセージは、そのポート構成に基づいて、Bluetooth LEスタック3972又はHTTP/IPスタック3974に送信することができ、Bluetooth LEスタック3972及びHTTP/IPスタック3974のそれぞれは、適切に構成された通信ポートに発信メッセージを送信することができる。
本明細書で説明されるシステム構成及び構成要素は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。コントローラ3600(又は、コントローラ3800)の実装は、コントローラによって実行されるものとして上述された動作のうちの、いずれか又は全てを実行することができ、アクセサリ3700(又は、アクセサリ3800)の実装は、アクセサリによって実行されるものとして上述された動作のうちのいずれか又は全てを実行することができ、異なる図面に関連する、異なる参照番号の使用は、そうではないことを意味する意図はない点を理解されたい。コントローラ及び/又はアクセサリは、本明細書では具体的に説明されない他の能力(例えば、携帯電話、全地球測位システム(GPS)、広帯域データ通信、インターネット接続性など)を有し得る。実装に応じて、これらのデバイスは、一方(又は、双方)のデバイスによってサポートされる任意の機能性を提供するように、又は、各デバイス内に部分的に実施される機能性を提供するように、相互運用することができる。一部の実施形態では、特定のアクセサリは、特定のコントローラを介してアクセス可能でも呼び出し可能でもないが、別のコントローラを介して、又はそのアクセサリと直接対話することによってアクセス可能な何らかの機能性を有し得る。
更には、コントローラ及びアクセサリは、本明細書では特定のブロックを参照して説明されているが、これらのブロックは、説明の便宜上定義されているものであり、構成部品の特定の物理的配置構成を意味する意図はないことを理解されたい。更には、これらのブロックは、物理的に別個の構成要素に対応する必要はない。ブロックは、例えばプロセッサをプログラムすることによって、又は適切な制御回路を提供することによって、様々な動作を実行するように構成することができ、様々なブロックは、初期の構成が取得される方法に応じて、再構成可能である場合もあれば、そうではない場合もある。本発明の実施形態は、回路及びソフトウェアの任意の組み合わせを使用して実装される電子デバイスを含めた、様々な装置で実現することができる。
数多くの動作及び対話をサポートすることができる。例えば、一部の実施形態では、アクセサリは、デバイス発見サービス上で広告を一斉配信することにより、そのアクセサリが、コントローラとペアリングするために利用可能であることを示すことができる。コントローラは、例えば、その広告を検出することによって、アクセサリを見つけることができ、ペア設定プロセス(例えば、図13〜図16を参照して上述されたプロセスのうちのいずれか)を開始して、例えば、長期公開キー、及び設定コード若しくはセキュリティ証明書などの帯域外情報項目を安全に交換することによって、ペアリングを確立することができる。ペア設定プロセスが完了すると、アクセサリは、そのアクセサリ自体を、いずれの追加のコントローラとも、(例えば、いずれのペア設定開始要求も無視するか、又はそれに応答してエラーを返すことによって)ペア設定を実行することを不可能にさせることができ、ペア設定を実行したコントローラには、管理者許可を付与することができる。管理者許可を有するコントローラは、アクセサリに、ペア追加プロセス(例えば、図18を参照して上述されたようなもの)を実行するか、又は上述の(例えば、アクセサリに信頼証明書チェーンを提供する)他の委譲ペアリングプロセスを使用することによって、1つ以上の追加のコントローラとペアリングを確立するように、命令することができる。管理者許可を有するコントローラはまた、アクセサリに、ペア除去プロセス(例えば、図19A〜図19Bを参照して上述されたようなもの)を実行することによって、1つ以上の他のコントローラとの(又は、その管理者許可を有するコントローラとの)確立済みペアリングを除去するように命令することもできる。
この方式で、ユーザのコントローラは、いずれの更なるペアリングの確立にも参加することが必要となり得るため、コントローラ及びアクセサリのユーザは、いずれの他のコントローラが、そのアクセサリとペアリングするかということに対して、制御を維持することができる。一部の実施形態では、ユーザは、例えば、1つ以上の追加のコントローラに管理者許可を付与するように、アクセサリに命令することによって、その制御を他者と共有することができる。管理者許可を有するコントローラのユーザはまた、もはや所望されない任意のペアリングを含めた、確立済みペアリングを除去するように、アクセサリに命令することもできる。
アクセサリとペアリングを確立しているコントローラ(「ペアリング済みコントローラ」とも称されるもの)は、必ずしもアクセサリへの常時接続を維持せずとも、アクセサリに対する制御を行使することができる。例えば、ペアリング済みコントローラが、アクセサリに再接続する場合、そのコントローラは、ペア検証プロセス(例えば、図17を参照して上述されたようなもの)を開始することができ、このペア検証プロセスにより、アクセサリ及びコントローラは、それらの間に確立済みペアリングが存在することを、検証することが可能となる。このペア検証プロセスはまた、アクセサリとコントローラとの接続が維持されている間に送信することが可能な、あらゆる後続のメッセージのセキュリティを確保するために使用可能な、1つ以上のセッションキーも提供することができ、この条件は「ペア検証済みセッション」と称することができる。
接続されている間、コントローラは、コマンド及び制御メッセージ(又は、要求メッセージ)をアクセサリに送信することができる。適切な要求メッセージを使用することによって、コントローラは、アクセサリの現在の状態を判定することができ、一部の場合は、アクセサリに、その現在の状態の態様を変化させるように命令することができる。例えば、アクセサリは、その状態を特性及びサービスの集合として説明する、アクセサリモデルを(例えば、アクセサリオブジェクトとして)保持することができる。コントローラは、それらの特性のうちの1つ以上(それらの特性のうちの全て、又はそれらの任意のサブセットを含み得るもの)を読み取るか、又は他の方式で問い合わせることによって、アクセサリの現在の状態の態様を判定することができ、それらの特性のうちの1つ以上に書き込むか、又は他の方式で修正することによって、アクセサリに、その現在の状態の態様を変化させるように命令することができる。アクセサリが、ペア検証済みセッション内で、そのような要求の全てが暗号化されたメッセージとして送信されることを必要とする場合には、そのアクセサリの操作は、認可済みコントローラに限定することができる。
アクセサリは、自己定義式のものとすることができる。例えば、ペアリングを確立した後、ペアリング済みコントローラは、アクセサリからアクセサリ定義レコードを要求することができる。アクセサリ定義レコードは、そのコントローラとペアリングされているアクセサリを介して制御することが可能な、各アクセサリに関するアクセサリオブジェクトを定義することができる。一部の実施形態では、アクセサリがいずれかのペアリングを確立する前に、アクセサリ定義レコードの全て又は一部を、コントローラに利用可能にさせることにより、ペアリングを確立するか否かを判定する際に、そのアクセサリ定義レコードからの情報を使用することが可能となり得る。他の実施形態では、コントローラは、アクセサリの広告内に含まれる情報(例えば、上述のようなTXTレコード)に基づいて、ペアリングを確立するか否かを判定することができ、アクセサリ定義レコードは、ペアリングが確立された後にのみ、コントローラに利用可能にさせることができる。ペアリング済みコントローラは、そのアクセサリ定義レコードを使用して、特性の問い合わせ及び/又は修正の要求を生成することにより、そのアクセサリの制御を有効にすることができる。コントローラは、必要に応じて、ユーザ入力に応答して、又は自動的に(例えば、コントローラが様々な条件を検出することに基づいて)、そのような要求を生成することができる。一部の実施形態では、コントローラは、アクセサリを制御するように動作可能なユーザインタフェースを、動的に生成することが可能な場合があり、このユーザインタフェースは、アクセサリ定義レコード内で提供される情報に基づくものである。
一部の実施形態では、アクセサリは、その状態の変化を、任意のペアリング済みコントローラに通知することができる。例えば受動的通知プロセス(例えば、図7に示されるようなもの)、広告式通知プロセス(例えば、図8に示されるようなもの)、能動的通知プロセス(例えば、図9に示されるようなもの)、及び/又はイベントメッセージ通知プロセス(例えば、図10に示されるようなもの)の任意の組み合わせをサポートすることができる。一部の実施形態では、ペアリング済みコントローラは、特定の特性に関して特定の通知方法(例えば、広告式、能動的、及び/又はイベントメッセージ)に加入するために、アクセサリに要求を送信することができる。アクセサリは、様々なコントローラに関する加入状態情報を保持することができ、現在の加入状態に基づいて特定のタイプの通知を生成することができる。
更なる実施形態
本発明は、特定の実施形態に関して説明されているが、当業者には、数多くの修正が可能であることが認識されるであろう。単一のコントローラは、本明細書で説明されるプロセスを使用することにより、任意数のアクセサリとペアリングを確立することができ、異なるアクセサリと異なる時点で選択的に通信することができる。同様に、単一のアクセサリは、そのアクセサリが(例えば、上述のようなペア設定及びペア追加を使用して)ペアリングを確立している複数のコントローラによって、制御することができる。アクセサリのいずれの機能も、その機能を、1つ以上の特性を有するサービスとしてモデル化し、それらのサービス及び/又はその特性とコントローラが対話する(例えば、読み取る、修正する、更新を受信する)ことを可能にすることによって制御することができる。したがって、本明細書で説明されるようなプロトコル及び通信プロセスは、「統一的」なものとすることができる、これは、それらのプロトコル及び通信プロセスが、アクセサリの機能、又はコントローラのフォームファクタ、又は具体的なインタフェースには関わりなく、1つ以上のコントローラ及び1つ以上のアクセサリを使用する任意のコンテキストで適用可能であることを意味する。
更には、上記の一部の実施例は、標準インターネットプロトコル(IP)伝送スタック(例えば、TCP/IP)をサポートする、ローカルエリアネットワーク及び広域ネットワークを介して使用することが可能なプロトコルである、HTTPに具体的に言及している。しかしながら、他の伝送プロトコルもまた、使用することができる。例えば、Bluetooth LEプロトコルスタックは、一方のデバイスが別のデバイスの属性を問い合わせるか又は修正することを可能にする、汎用属性(GATT)層を含む。一部の実施形態では、アクセサリ特性のインスタンスは、GATTモデルに基づく属性として、コントローラに公開することができる。したがって、コントローラはまた、Bluetooth LEを使用して、アクセサリ特性を問い合わせる(例えば、読み取る)ことも、修正する(例えば、書き込む)こともできる。一部の実施形態では、特定のアクセサリは、IP及び/又はBluetooth LE伝送プロトコルの一方若しくは双方をサポートすることができ、コントローラは、そのアクセサリの能力に応じて、及びコントローラによって確立された環境設定に応じて、一部のアクセサリとはIPを使用して対話し、他のアクセサリとはBluetooth LEを使用して対話することができる。
本明細書で説明される様々な特徴、例えば、方法、装置、コンピュータ可読媒体などは、専用の構成要素、及び/又はプログラム可能プロセッサ、及び/又は他のプログラム可能デバイスの、任意の組み合わせを使用して実現することができる。本明細書で説明される様々なプロセスは、同じプロセッサ又は異なるプロセッサ上に、任意の組み合わせで実行することができる。構成要素が、特定の動作を実行するように構成されるとして説明される場合、そのような構成は、例えば、その動作を実行するように電子回路を設計することによって、その動作を実行するようにプログラム可能電子回路(マイクロプロセッサなど)をプログラムすることによって、又はこれらの任意の組み合わせによって、達成することができる。更には、上述の実施形態は、特定のハードウェア構成要素及びソフトウェア構成要素に言及し得るものであるが、当業者には、異なる組み合わせのハードウェア構成要素及び/又はソフトウェア構成要素もまた使用することができ、ハードウェア内で実施されるものとして説明される特定の動作はまた、ソフトウェア内でも実施することができ、逆もまた同様であることが理解されるであろう。
本明細書で説明される様々な特徴を組み込むコンピュータプログラムは、様々なコンピュータ可読記憶媒体上に、符号化して記憶させることができ、好適な媒体としては、磁気ディスク若しくは磁気テープ、コンパクトディスク(CD)若しくはDVD(デジタル多用途ディスク)などの光記憶媒体、フラッシュメモリ、及び他の非一時的媒体が挙げられる。プログラムコードで符号化されたコンピュータ可読媒体は、適合する電子デバイスと共にパッケージ化することができ、又は、そのプログラムコードは、電子デバイスとは別個に(例えばインターネットダウンロードを介して、又は別個にパッケージ化されたコンピュータ可読記憶媒体として)提供することもできる。
それゆえ、本発明は、特定の実施形態に関して説明されているが、本発明は、以下の特許請求の範囲内での、全ての修正及び等価物を包含することを意図するものであることが理解されるであろう。