(57)【要約】  統一的プロトコルは、コントローラデバイスと、そのコントローラによって制御されるアクセサリデバイスとの間の、安全な認証通信を容易にすることができる。アクセサリとコントローラとは、ペアリングを確立することができ、このペアリングの存在は、その後に検証して、安全な通信セッションを作り出すために使用することができる。アクセサリは、そのアクセサリをサービスの集合として定義する、アクセサリ定義レコードを提供することができ、各サービスは、１つ以上の特性を有する。安全な通信セッション内では、コントローラは、それらの特性を問い合わせることにより、アクセサリ状態を判定することができ、かつ／又は、それらの特性を修正することにより、アクセサリに、その状態を変化させるように命令することができる。
2017511028.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
ペアリングのために利用可能なアクセサリを、コントローラによって検出することと、
前記アクセサリとペアリングを確立するために、前記コントローラによって、ペア設定動作を実行することであって、前記ペア設定動作が、
前記アクセサリと前記コントローラとの間で交換される帯域外情報項目を使用して、共有シークレットを確立することと、
前記共有シークレットを使用して、前記アクセサリの長期公開キーと前記コントローラの長期公開キーとを安全に交換することと、
前記アクセサリの識別子と関連させて、前記アクセサリの前記長期公開キーを、前記コントローラによって、安全かつ永続的に記憶することと、
を含む、ことと、
前記コントローラによって、前記ペアリング済みアクセサリからアクセサリ定義レコードを取得することであって、前記アクセサリ定義レコードが、サービスのセットを含み、各サービスが、特性のセットを有し、各特性が、アクセサリ状態の態様を表す、ことと、
前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正するために、前記コントローラによって、前記ペアリング済みアクセサリに要求を通信することであって、前記要求が、前記ペアリング済みアクセサリの動作を呼び出す命令として、前記ペアリング済みアクセサリによって解釈される、ことと、
を含む、方法。
【請求項２】
前記アクセサリの前記動作を呼び出す前に、
前記コントローラによって、前記ペアリング済みアクセサリとのペア検証動作を実行することを更に含み、前記ペア検証動作が、
前記ペアリング済みアクセサリの前記長期公開キー、及び前記コントローラの前記長期公開キーに対応する長期秘密キーを前記コントローラが有するという証明を、前記ペアリング済みアクセサリに送信することと、
前記コントローラの前記長期公開キー、及び前記ペアリング済みアクセサリの前記長期公開キーに対応する長期秘密キーを前記ペアリング済みアクセサリが有するという証明を、前記ペアリング済みアクセサリから受信することと、
を含み、前記コントローラが、前記ペア検証動作が成功する場合にのみ、前記ペアリング済みアクセサリの前記動作を呼び出す、請求項１に記載の方法。
【請求項３】
前記ペア検証動作を実行することが、セッションキーを生成することを更に含み、前記セッションキーが、前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正する、前記要求を暗号化するために使用される、請求項２に記載の方法。
【請求項４】
前記アクセサリ定義レコード内で定義された前記特性のセットからの、特定の特性の変化の通知に加入する、前記ペアリング済みアクセサリに対する要求を、前記コントローラによって送信することを更に含み、前記加入する要求が、前記特定の特性を指定し、かつ通知モードを更に指定する、請求項１に記載の方法。
【請求項５】
前記指定された通知モードが、イベントメッセージ通知モードであり、前記方法が、
前記加入する要求の送信の後に続けて、前記アクセサリからの非請求の応答メッセージを、前記コントローラによって受信することを更に含み、前記非請求の応答メッセージが、前記コントローラによって指定された前記特性の変化の通知を含む、請求項４に記載の方法。
【請求項６】
前記帯域外情報項目が、
前記アクセサリによってユーザに提供され、前記ユーザによって前記コントローラに提供される設定コード、又は
前記アクセサリ以外のソースから、前記コントローラによって取得される、デジタル証明書検証情報、
のうちの１つ以上を含み、前記デジタル証明書検証情報が、前記アクセサリから前記コントローラによって受信されるデジタル証明書及び署名を検証するために使用可能である、請求項１に記載の方法。
【請求項７】
前記コントローラによって、別のコントローラの代理として、前記ペアリング済みアクセサリとペア追加動作を実行することを更に含み、前記ペア追加動作が、前記コントローラによって、前記アクセサリに、前記他のコントローラの長期公開キー、又は、前記他のコントローラを検証するために前記アクセサリによって使用可能な証明書のうちの、一方若しくは双方を提供することを含む、請求項１に記載の方法。
【請求項８】
コントローラであって、
１つ以上のアクセサリと通信する通信インタフェースと、
１つ以上のペアリング済みアクセサリに関するペアリングレコードを安全に記憶する、セキュア記憶要素と、
１つ以上のペアリング済みアクセサリに関するアクセサリ定義レコードを記憶するように構成された、データ記憶要素と、
前記通信インタフェース、前記セキュア記憶要素、及び前記データ記憶要素に結合された、処理サブシステムと、
を備え、前記処理サブシステムが、
１つ以上のアクセサリとペアリングを確立するように構成され、アクセサリとペアリングを確立することが、
帯域外情報項目を取得することと、
前記アクセサリから、前記アクセサリの長期公開キー、及び前記アクセサリが前記帯域外情報項目を有するという証明を、安全に取得することと、
前記アクセサリに、前記コントローラの長期公開キーを安全に提供することと、
前記アクセサリに関するペアリングレコードを作成して、前記セキュア記憶要素内に永続的に記憶することと、
を含み、前記ペアリングレコードが、前記アクセサリの長期公開キーを含み、
アクセサリとペアリングを確立した後に、前記ペアリング済みアクセサリからアクセサリ定義レコードを取得するように構成され、前記アクセサリ定義レコードが、サービスのセットを含み、各サービスが、特性のセットを有し、各特性が、アクセサリ状態の態様を表し、
前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正する要求を、前記アクセサリに通信することによって、前記ペアリング済みアクセサリの動作を呼び出す
ように構成される、コントローラ。
【請求項９】
前記通信インタフェースが、少なくとも２つの異なるトランスポートプロトコルスタックを含み、前記通信インタフェースが、特定のアクセサリとの通信に関して使用するために、前記トランスポートプロトコルスタックのうちの１つを選択する、請求項８に記載のコントローラ。
【請求項１０】
前記少なくとも２つの異なるトランスポートプロトコルスタックが、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック、及びＨＴＴＰ／ＩＰプロトコルスタックを含む、請求項９に記載のコントローラ。
【請求項１１】
前記処理サブシステムが、ペアリング済みアクセサリと、ペア検証済みセッションを確立するように更に構成され、前記ペア検証済みセッションを確立することが、
前記ペアリング済みアクセサリの前記長期公開キー、及び前記コントローラの前記長期公開キーに対応する長期秘密キーを前記コントローラが有するという証明を、前記ペアリング済みアクセサリに送信することと、
前記コントローラの前記長期公開キー、及び前記ペアリング済みアクセサリの前記安全に記憶された長期公開キーに対応する長期秘密キーを前記ペアリング済みアクセサリが有するという証明を、前記ペアリング済みアクセサリから受信することと、
前記コントローラと前記ペアリング済みアクセサリとの間で交換される後続のメッセージを暗号化するために使用可能な、１つ以上のセッションキーを確立することと、
を含む、請求項８に記載のコントローラ。
【請求項１２】
前記処理サブシステムが、確立されたペア検証済みセッション内で、ペア追加動作を実行するように更に構成され、前記ペア追加動作を実行することが、前記ペアリング済みアクセサリがペアリングを確立することになる別のコントローラの長期公開キーを、前記ペアリング済みアクセサリに送信することを含む、請求項１１に記載のコントローラ。
【請求項１３】
方法であって、
アクセサリによって、前記アクセサリがペアリングのために利用可能であることを広告することと、
コントローラとペアリングを確立するために、前記アクセサリによって、ペア設定動作を実行することであって、前記ペア設定動作が、
前記アクセサリと前記コントローラとの間で交換される帯域外情報項目を使用して、共有シークレットを確立することと、
前記共有シークレットを使用して、前記アクセサリの長期公開キー、及び前記コントローラの長期公開キーを安全に交換することと、
前記コントローラの識別子と関連させて、前記コントローラの前記長期公開キーを、前記アクセサリによって安全かつ永続的に記憶することと、
を含む、ことと、
前記アクセサリによって、前記ペアリング済みコントローラに、前記ペアリング済みアクセサリに関するアクセサリ定義レコードを提供することであって、前記アクセサリ定義レコードが、サービスのセットを含み、各サービスが、特性のセットを有し、各特性が、アクセサリ状態の態様に対応する、ことと、
前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正する、前記ペアリング済みコントローラからの要求を、前記アクセサリによって受信することと、
前記受信された要求に応答して呼び出される動作を、前記アクセサリによって実行することと、
を含む、方法。
【請求項１４】
前記アクセサリがペアリングモードに入るべきであることを示すユーザアクションを、前記アクセサリで検出することを更に含み、
前記アクセサリがペアリングのために利用可能であることを広告することが、前記ユーザアクションの検出に応答して実行される、請求項１３に記載の方法。
【請求項１５】
１つのコントローラと前記ペア設定動作を実行した後に、前記ペアリング済みコントローラの前記長期公開キーが、安全かつ永続的に記憶されたまま維持される限り、前記アクセサリが、その後は、いずれの他のコントローラとも、前記ペア設定動作を実行することを拒否する、請求項１３に記載の方法。
【請求項１６】
前記特性のうちの１つ以上を修正する、前記コントローラからの前記要求を受信する前に、
前記アクセサリによって、前記ペアリング済みコントローラとペア検証動作を実行することを更に含み、前記ペア検証動作が、
前記アクセサリの前記長期公開キー、及び前記ペアリング済みコントローラの前記長期公開キーに対応する長期秘密キーを前記ペアリング済みコントローラが有するという証明を、前記ペアリング済みコントローラから受信することと、
前記ペアリング済みコントローラの前記長期公開キー、及び前記アクセサリの前記長期公開キーに対応する長期秘密キーを前記アクセサリが有するという証明を、前記ペアリング済みコントローラに送信することと、
を含み、
前記アクセサリが、前記ペア検証動作が成功する場合にのみ、前記要求に応答して前記呼び出される動作を実行する、請求項１３に記載の方法。
【請求項１７】
前記ペア検証動作を実行することが、セッションキーを生成することを更に含み、前記セッションキーが、前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正する、前記受信された要求を復号するために使用され、
前記アクセサリが、前記受信された要求の復号が成功する場合にのみ、前記呼び出される動作を実行する、請求項１６に記載の方法。
【請求項１８】
前記アクセサリ定義レコード内で定義された前記特性のセットからの、特定の特性の変化の通知に加入する、前記ペアリング済みコントローラからの要求を、前記アクセサリによって受信することであって、前記加入する要求が、前記特定の特性を指定し、かつ通知モードを更に指定する、ことと、
前記指定された特性が変化する場合に、前記指定された通知モードに基づいて、前記アクセサリによって、前記ペアリング済みコントローラに対する更新通知を生成することと、
を更に含む、請求項１３に記載の方法。
【請求項１９】
前記指定された通知モードが、イベントメッセージ通知モードであり、前記更新を生成することが、前記ペアリング済みコントローラに、非請求の応答メッセージを送信することを含み、前記非請求の応答メッセージが、前記指定された特性の前記変化の通知を含む、請求項１８に記載の方法。
【請求項２０】
前記帯域外情報項目が、前記アクセサリによってローカルに記憶され、かつ帯域外通信チャネルを使用して前記コントローラに通信される、設定コードを含む、請求項１３に記載の方法。
【請求項２１】
前記アクセサリによって、別のコントローラの代理としての前記ペアリング済みコントローラと、ペア追加動作を実行することを更に含み、前記ペア追加動作が、
前記アクセサリによって、前記他のコントローラの長期公開キーを、前記ペアリング済みコントローラから受信することと、
前記他のコントローラの識別子と関連させて、前記他のコントローラの前記長期公開キーを、前記アクセサリによって安全かつ永続的に記憶することと、
を含み、前記ペア追加動作の後に続けて、前記他のコントローラが、前記アクセサリによって、第２のペアリング済みコントローラとして取り扱われる、請求項１３に記載の方法。
【請求項２２】
アクセサリであって、
１つ以上のコントローラと通信する通信インタフェースと、
動作構成要素と、
ペアリングレコードを安全に記憶するセキュア記憶要素と、
アクセサリ定義レコードを記憶するように構成され、前記アクセサリ定義レコードが、サービスのセットを含み、各サービスが、特性のセットを有し、各特性が、前記動作構成要素の状態を含めた、アクセサリ状態の態様を表す、アクセサリデータ記憶要素と、
前記通信インタフェース、前記動作構成要素、前記セキュア記憶要素、及び前記アクセサリデータ記憶要素に結合された、処理サブシステムと、
を備え、前記処理サブシステムが、
１つ以上のコントローラとペアリングを確立するように構成され、コントローラとペアリングを確立することが、
帯域外情報項目を取得することと、
前記コントローラから、前記コントローラの長期公開キー、及び前記コントローラが前記帯域外情報項目を有するという証明を、安全に取得することと、
前記コントローラに、前記アクセサリの長期公開キーを安全に提供することと、
前記コントローラに関するペアリングレコードを作成して、前記セキュア記憶要素内に永続的に記憶することと、
を含み、前記ペアリングレコードが、前記コントローラの長期公開キーを含み、
コントローラとペアリングを確立した後に、前記記憶されたアクセサリ定義レコードを、前記ペアリング済みコントローラに提供するように構成され、
前記アクセサリ定義レコード内で指定された前記特性のうちの１つ以上を修正する要求を、前記ペアリング済みコントローラから受信するように構成され、
前記要求に応答して、前記少なくとも１つの動作構成要素の動作を達成する
ように構成される、アクセサリ。
【請求項２３】
前記処理サブシステムが、ペアリング済みコントローラと、ペア検証済みセッションを確立するように更に構成され、前記ペア検証済みセッションを確立することが、
前記アクセサリの前記長期公開キー、及び前記ペアリング済みコントローラの前記安全に記憶された長期公開キーに対応する長期秘密キーを前記ペアリング済みコントローラが有するという証明を、前記ペアリング済みコントローラから受信することと、
前記ペアリング済みコントローラの前記長期公開キー、及び前記アクセサリの前記長期公開キーに対応する長期秘密キーを前記アクセサリが有するという証明を、前記ペアリング済みコントローラに送信することと、
前記ペアリング済みコントローラと前記アクセサリとの間で交換される後続のメッセージを暗号化するために使用可能な、１つ以上のセッションキーを確立することと、
を含む、請求項２２に記載のアクセサリ。
【請求項２４】
前記処理サブシステムが、確立されたペア検証済みセッション内で、ペア追加動作を実行するように更に構成され、前記ペア追加動作を実行することが、
前記アクセサリがペアリングを確立することになる別のコントローラの長期公開キーを、前記ペアリング済みコントローラから受信することと、
前記他のコントローラに関するペアリングレコードを作成して、前記セキュア記憶要素内に永続的に記憶することと、
を含み、前記ペアリングレコードが、前記他のコントローラの前記受信された長期公開キーを含む、請求項２３に記載のアクセサリ。
【請求項２５】
前記少なくとも１つの動作構成要素が、
ロックメカニズム、
電球、
ドア開閉装置、又は
カメラ、
のうちの１つ以上を含む、請求項２２に記載のアクセサリ。
【発明の詳細な説明】
【背景技術】
【０００１】
〔関連出願の相互参照〕
本出願は、２０１４年２月５日出願の「Ｐｒｏｔｏｃｏｌｓ  ａｎｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ  ｆｏｒ  ａｎ  Ａｃｃｅｓｓｏｒｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ」と題された米国特許仮出願第６１／９３５，９６７号に対する優先権を主張するものであり、その開示は、全体が参照により本明細書に組み込まれる。本出願はまた、２０１５年２月５日出願の「Ｕｎｉｆｏｒｍ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｂｅｔｗｅｅｎ  Ｃｏｎｔｒｏｌｌｅｒｓ  ａｎｄ  Ａｃｃｅｓｓｏｒｉｅｓ」と題された米国特許出願第１４／６１４，９１４号に対する優先権も主張するものであり、その開示は、全体が参照により本明細書に組み込まれる。
【０００２】
本開示は、全般的に、電子デバイス間の通信に関し、詳細には、コントローラとアクセサリとの間の通信のための統一的通信プロトコルに関する。
【０００３】
電子デバイスは、様々な用途において、ますます一般的になりつつある。携帯電話、タブレットコンピュータ、家庭用娯楽システムなどは、ユーザが日頃から対話する電子デバイスのうちの一部に過ぎない。
【０００４】
より一般的になりつつある電子デバイスの別のカテゴリとしては、サーモスタット、照明装置、家庭用電化製品などの、電子制御可能な様々なデバイスが挙げられる。
【発明の概要】
【０００５】
現時点では、電子制御可能な複数のデバイス又はシステムをユーザが管理することは、困難な場合がある。例えば、ユーザの家庭は、サーモスタット、電子制御可能な照明システム、ホームセキュリティシステムなどを有し得る。そのような各システムは、異なる製造元によって作製される場合があり、各製造元は、専用のコントローラデバイス（例えば、ＩＲベースのリモート制御デバイス）、又は、携帯電話、タブレット、若しくは家庭用コンピュータシステムなどの汎用コンピューティングデバイス上にユーザがインストールして実行することが可能な、コントローラアプリを提供することができる。各コントローラデバイス又はコントローラアプリは、典型的には、特定の製造元のシステム用にカスタマイズされており、他の製造元によるシステムと、又は同じ製造元による他のシステムとであっても、相互運用することができない場合がある。そのような断片的手法は、容易に拡張可能なものではない。中央制御又は中央管理することが可能な、異種のシステムのアレイを有する、「スマートホーム」環境などを作り出すことを希求するユーザは、膨大な数のコントローラデバイス及び／又はコントローラアプリを蓄積する必要性に直面する。
【０００６】
本発明の特定の実施形態は、コントローラデバイス（又は「コントローラ」）と、制御される任意数の他の電子デバイス（本明細書では「アクセサリデバイス」又は単純に「アクセサリ」と称されるもの）との間の通信のための、「統一的」プロトコルに関する。コントローラは、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯電話、他のハンドヘルド型コンピューティングデバイス又はウェアラブルコンピューティングデバイスなどの、汎用コンピューティングデバイス上で、その汎用コンピューティングデバイスに適切な実行可能プログラムコードを提供することによって実装することができ、あるいは、コントローラは、特殊目的コンピューティングデバイスとすることもできる。アクセサリは、コントローラによって制御可能な、任意のデバイスを含み得る。アクセサリの例としては、照明器具、サーモスタット、ドアロック、自動ドア開閉装置（例えば、ガレージドア開閉装置）、スチルカメラ又はビデオカメラなどが挙げられる。アクセサリ及びコントローラは、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ  ＬＥなどの標準トランスポートプロトコルを使用する、有線チャネル又は無線チャネルを介して、互いに通信することができる。
【０００７】
一部の実施形態では、統一的アクセサリプロトコルは、アクセサリをサービスの集合として定義するための、単純かつ拡張可能なフレームワークを定義し得るものであり、各サービスは、特性のセットとして定義され、各特性は、任意の所定の時間での定義値を有する。それらの特性は、そのアクセサリの状態の様々なアトミックな態様を表し得る。例えば、サーモスタットの場合には、特性としては、電力（サーモスタットユニットがオン又はオフのいずれであるか）、現在温度（サーモスタットによって測定される実際の温度）、及び目標温度（サーモスタットが維持するように努める設定可能温度）を挙げることができる。このプロトコルは、コントローラによって、アクセサリにコマンド及び制御メッセージ（要求）を送信するために使用可能な、及びアクセサリが、応答メッセージを送信するために使用可能なメッセージフォーマットを更に定義することができる。それらの要求は、コントローラがアクセサリ特性を問い合わせる（例えば、読み取る）ことを可能にし、一部の場合には、アクセサリ特性を修正する（例えば、書き込む）ことも可能にし得るものであり、例えば、コントローラは、電力特性を読み取ることにより、そのアクセサリがオン又はオフのいずれであるかを判定することができ、電力特性に書き込むことにより、そのアクセサリをオフ又はオンにすることができる。したがって、適切な要求を送信することによって、機能に関わりなく、いずれのタイプのアクセサリも制御することができる。アクセサリは、アクセサリ定義レコードをコントローラに提供することができる。このアクセサリ定義レコードは、そのアクセサリの、アクセス可能な全ての特性についての完全な情報を含み得る。コントローラは、アクセサリと対話する方法を決定する際に、そのアクセサリ定義レコードを使用することができる。例えば、アクセサリ定義レコードからの情報は、コントローラによって、そのアクセサリを動作させるためのユーザインタフェースを構築するために、並びに、そのアクセサリに対する要求メッセージを構築するために使用することができる。
【０００８】
一部の実施形態では、このプロトコルは、特性が変化する場合に、アクセサリがコントローラに通知するために使用することが可能な通知メカニズムを更に定義することができる。例としては、いずれかの特性が変化したか否かに関して、コントローラがアクセサリに問い合わせることが可能な、受動的通知メカニズム、並びに、特定の特性が変化する場合に、アクセサリが、１つ以上のコントローラに対するメッセージを選択的に生成することが可能な、能動的通知メカニズム又はイベントベースの通知メカニズムが挙げられる。複数の通知メカニズムを同時にサポートすることができ、コントローラは、特定のアクセサリ、サービス、又は特性に関して使用するための、通知メカニズムを選択することができる。
【０００９】
一部の実施形態では、このプロトコルは、無認可のコントローラがアクセサリを動作させることを防止するために使用することが可能な、セキュリティ対策を定義することができる。例えば、アクセサリは、そのアクセサリと以前にペアリングを確立していることにより、そのアクセサリによって認識されるコントローラからのみ、要求を受理するように構成することができる。ペアリングを確立することは、アクセサリとコントローラとの間で、長期公開キーを安全な方式で交換し、各デバイスがそれらのキーを永続的に記憶することを含み得る。このプロトコルは、アクセサリの所有者／操作者の承認を受けることなくペアリングが確立されるリスクを低減するように、ペア設定手順を指定することができる。例えば、ペア設定プロセスの間、ユーザは一方のデバイス（例えば、アクセサリ）によって提示される設定コードを読み取り、その設定コードを他方のデバイス（例えば、コントローラ）に入力すること、又はそれらのデバイスを、互いに物理的に近接させて配置することが必要とされる場合がある。ペアリングが確立されると、そのペアリングを活用して、ペアリング済みのコントローラ及びアクセサリのみがそれらの間で交換されるメッセージを読み取ることができるように、エンドツーエンドのメッセージ暗号化を提供することができる。例えば、以前にペアリングを確立したアクセサリとコントローラとが再接続する場合、それらは以前のペアリングを（例えば、それぞれが他方の長期公開キーを保有することを証明することによって）検証して、セッション固有の暗号キーを生成することができる。
【００１０】
一部の実施形態では、このプロトコルは、コントローラが、その近傍の適合するアクセサリを発見して構成する手順を、定義することができる。そのような手順は、コントローラによって管理される自動化制御システムに、新たなアクセサリを追加するタスクを、簡略化することができる。
【００１１】
以下の発明を実施するための形態を、添付の図面と併せて参照することにより、本発明の性質及び利点に関する理解をより深めることができるであろう。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態に係る、家庭環境を示す。
【図２Ａ】本発明の実施形態に係る、アクセサリ特性の例示的定義を示す。
【図２Ｂ】本発明の実施形態に係る、アクセサリ特性の例示的定義を示す。
【図２Ｃ】本発明の実施形態に係る、アクセサリ特性の例示的定義を示す。
【図２Ｄ】本発明の実施形態に係る、アクセサリ特性の例示的定義を示す。
【図２Ｅ】本発明の実施形態に係る、特性に関して定義することが可能なプロパティの実施例を示す。
【図２Ｆ】本発明の実施形態に係る、定義することが可能な拡張特性の実施例を示す。
【図２Ｇ】本発明の実施形態に係る、アクセサリサービスの例示的定義を示す。
【図２Ｈ】本発明の実施形態に係る、アクセサリサービスの例示的定義を示す。
【図２Ｉ】本発明の実施形態に係る、定義することが可能なアクセサリ情報サービスの実施例を示す。
【図２Ｊ】本発明の実施形態に係る、定義することが可能なアクセサリ情報サービスに関する特性の実施例を示す。
【図３Ａ】本発明の実施形態に係る、アクセサリ定義レコードの実施例を示す。
【図３Ｂ】本発明の実施形態に係る、アクセサリ定義レコードの実施例を示す。
【図３Ｃ】本発明の実施形態に係る、アクセサリ定義レコードの実施例を示す。
【図４】本発明の実施形態に係る、コントローラによってアクセサリを発見するプロセスの、フローチャートである。
【図５Ａ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｂ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｃ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｄ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｅ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｆ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｇ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｈ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｉ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｊ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図５Ｋ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの実施例を示す。
【図６Ａ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの更なる実施例を示す。
【図６Ｂ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの更なる実施例を示す。
【図６Ｃ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの更なる実施例を示す。
【図６Ｄ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの更なる実施例を示す。
【図６Ｅ】本発明の実施形態に係る、要求メッセージ及び応答メッセージの更なる実施例を示す。
【図７】本発明の実施形態に係る、受動的通知プロセスの実施例を示す。
【図８】本発明の実施形態に係る、広告式通知プロセスの実施例を示す。
【図９】本発明の実施形態に係る、能動的通知プロセスの実施例を示す。
【図１０】本発明の実施形態に係る、イベント通知プロセスの実施例を示す。
【図１１Ａ】本発明の実施形態に係る、通知に加入する要求メッセージの実施例を示す。
【図１１Ｂ】本発明の実施形態に係る、イベントメッセージの実施例を示す。
【図１２】本発明の実施形態に係る、アクセサリに関するペアリングプロファイルに関する、例示的特性を示す。
【図１３Ａ】本発明の実施形態に係る、設定コードベースのペア設定プロセスの実施例を示す。
【図１３Ｂ】本発明の実施形態に係る、設定コードベースのペア設定プロセスの実施例を示す。
【図１３Ｃ】本発明の実施形態に係る、設定コードベースのペア設定プロセスの実施例を示す。
【図１４Ａ】本発明の実施形態に係る、認証チップ及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１４Ｂ】本発明の実施形態に係る、認証チップ及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１４Ｃ】本発明の実施形態に係る、認証チップ及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ａ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ｂ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ｃ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ｄ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ｅ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１５Ｆ】本発明の実施形態に係る、設定コード及びセキュリティ証明書を使用する、ペア設定プロセスの実施例を示す。
【図１６】本発明の実施形態に係る、一般化されたペア設定プロセスの実施例を示す。
【図１７Ａ】本発明の実施形態に係る、ペア検証プロセスの実施例を示す。
【図１７Ｂ】本発明の実施形態に係る、ペア検証プロセスの実施例を示す。
【図１７Ｃ】本発明の実施形態に係る、ペア検証プロセスの実施例を示す。
【図１８Ａ】本発明の実施形態に係る、ペア追加プロセスの実施例を示す。
【図１８Ｂ】本発明の実施形態に係る、ペア追加プロセスの実施例を示す。
【図１９Ａ】本発明の実施形態に係る、ペア除去プロセスの実施例を示す。
【図１９Ｂ】本発明の実施形態に係る、ペア除去プロセスの実施例を示す。
【図２０】本発明の実施形態に係る、ドアロックアクセサリに関する例示的な動作環境を示す。
【図２１】本発明の実施形態に係る、ドアロックアクセサリに関する例示的なサービス定義を示す。
【図２２】本発明の実施形態に係る、コントローラをアクセサリとペアリングするプロセスの実施例を示す。
【図２３】本発明の実施形態に係る、ドアをロック解除するプロセスの実施例を示す。
【図２４】本発明の実施形態に係る、ＩＰカメラアクセサリに関する動作環境を示す。
【図２５Ａ】本発明の実施形態に係る、ＩＰカメラアクセサリに関する例示的なサービス定義を示す。
【図２５Ｂ】本発明の実施形態に係る、ＩＰカメラアクセサリに関する例示的なサービス定義を示す。
【図２６Ａ】本発明の実施形態に係る、図２５に示すサービスの特性に関する、例示的定義を示す。
【図２６Ｂ】本発明の実施形態に係る、図２５に示すサービスの特性に関する、例示的定義を示す。
【図２６Ｃ】本発明の実施形態に係る、図２５に示すサービスの特性に関する、例示的定義を示す。
【図２６Ｄ】本発明の実施形態に係る、図２５に示すサービスの特性に関する、例示的定義を示す。
【図２６Ｅ】本発明の実施形態に係る、図２５に示すサービスの特性に関する、例示的定義を示す。
【図２７Ａ】本発明の実施形態に係る、ＩＰカメラアクセサリに関するアクセサリ定義レコードの実施例を示す。
【図２７Ｂ】本発明の実施形態に係る、ＩＰカメラアクセサリに関するアクセサリ定義レコードの実施例を示す。
【図２７Ｃ】本発明の実施形態に係る、ＩＰカメラアクセサリに関するアクセサリ定義レコードの実施例を示す。
【図２７Ｄ】本発明の実施形態に係る、ＩＰカメラアクセサリに関するアクセサリ定義レコードの実施例を示す。
【図２８】本発明の実施形態に係る、ＩＰカメラアクセサリを制御するプロセスの実施例を示す。
【図２９】本発明の実施形態に係る、メディアセッション開始要求の実施例を示す。
【図３０】本発明の実施形態に係る、メディアセッション開始応答の実施例を示す。
【図３１】本発明の実施形態に係る、メディアセッション終了要求の実施例を示す。
【図３２】本発明の実施形態に係る、メディアセッション終了応答の実施例を示す。
【図３３】本発明の実施形態に係る、ＩＰストリーミングサービスに関する例示的なサービス定義を示す。
【図３４】本発明の実施形態に係る、図３３のＩＰストリーミングサービスに関する特性定義の実施例を示す。
【図３５】本発明の実施形態に係る、ＩＰストリーミングに関するプロセスの実施例を示す。
【図３６】本発明の実施形態に係る、コントローラの簡略ブロック図である。
【図３７】本発明の実施形態に係る、アクセサリの簡略ブロック図である。
【図３８】本発明の実施形態に係る、コントローラアーキテクチャの簡略ブロック図である。
【図３９】本発明の実施形態に係る、アクセサリアーキテクチャの簡略ブロック図である。
【発明を実施するための形態】
【００１３】
本発明の特定の実施形態は、コントローラデバイス（又は「コントローラ」）と、制御される任意数の他の電子デバイス（本明細書では「アクセサリデバイス」又は単純に「アクセサリ」と称されるもの）との間の通信のための、「統一的」プロトコルに関する。コントローラは、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯電話、他のハンドヘルド型コンピューティングデバイス又は着用型コンピューティングデバイスなどの、汎用コンピューティングデバイス上で、その汎用コンピューティングデバイスに適切な実行可能プログラムコードを提供することによって実装することができ、あるいは、コントローラは特殊目的コンピューティングデバイスとすることもできる。アクセサリは、コントローラによって制御可能な任意のデバイスを含み得る。アクセサリの例としては、照明器具、サーモスタット、ドアロック、自動ドア開閉装置（例えば、ガレージドア開閉装置）、スチルカメラ又はビデオカメラなどが挙げられる。アクセサリ及びコントローラは、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、Ｂｌｕｅｔｏｏｔｈ  ＬＥなどの標準トランスポートプロトコルを使用する、有線チャネル又は無線チャネルを介して、互いに通信することができる。
例示的環境
【００１４】
図１は、本発明の実施形態による、家庭環境１００を示す。家庭環境１００は、環境１００内に配置された様々なアクセサリデバイス（アクセサリとも称されるもの）と通信することが可能なコントローラ１０２を含む。コントローラ１０２としては、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、携帯情報端末、あるいは、本明細書で説明されるようなアクセサリにコマンド及び制御メッセージを通信して、ユーザインタフェースを提示することにより、ユーザがそれらのアクセサリ上での所望の動作を指示することが可能となる、任意の他のコンピューティングデバイス又はデバイスのセットを挙げることができる。一部の実施形態では、コントローラ１０２は、複数の個別デバイスを使用して実装することができる。例えば、環境１００内の固定された場所に設置することが可能な、アクセサリと通信する基地局と、ユーザインタフェースを提供し、基地局と通信することによりアクセサリに対する制御を達成する、１つ以上の移動リモート制御局（例えば、携帯電話、タブレットコンピュータ、スマートウオッチ、眼鏡などのハンドヘルド型デバイス又はウェアラブルデバイス）とが存在し得る。
【００１５】
任意のタイプのアクセサリデバイスを制御することができる。アクセサリデバイスの例としては、ドアロック１０４、ガレージドアシステム１０６、照明器具１０８、防犯カメラ１１０、及びサーモスタット１１２が挙げられる。一部の場合には、コントローラ１０２は、アクセサリと直接通信することができ、例えばコントローラ１０２は、ドアロック１０４及びガレージドアシステム１０６と直接通信しているように示されている。他の場合には、コントローラ１０２は、中継機器を介して通信することができる。例えばコントローラ１０２は、無線ネットワークアクセスポイント１１４を介して、アクセスポイント１１４によって提供される無線ネットワーク上に存在するアクセサリ１０８、１１０、１１２と通信しているように示されている。上述のように一部の実施形態では、コントローラ１０２は基地局を含み得るものであり、基地局の機能性は、アクセスポイント１１４に組み込むか、又は制御されるアクセサリのうちの１つ（例えば、サーモスタット１１２）に組み込むことができる。
【００１６】
様々な通信トランスポート及びトランスポートの組み合わせを使用することができ、種々のトランスポートを、種々のデバイスで使用することができる。通信トランスポートの一実施例は、Ｂｌｕｅｔｏｏｔｈ  ＳＩＧ，Ｉｎｃ．（ｈｔｔｐ：／／ｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍ）によって定義及び公表されたＢｌｕｅｔｏｏｔｈ（登録商標）通信規格及びプロトコルに適合する、トランスポートとすることができ、用語「Ｂｌｕｅｔｏｏｔｈ」とは、本明細書で使用するとき、全般的に、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信規格及びプロトコルを指し、用語「Ｂｌｕｅｔｏｏｔｈ  ＬＥ」とは、本明細書で使用するとき、Ｂｌｕｅｔｏｏｔｈ（登録商標）Ｓｍａｒｔ（登録商標）通信規格及びプロトコルを指す。Ｂｌｕｅｔｏｏｔｈプロトコルは、限られた範囲内での、デバイス間の直接的なポイントツーポイント通信をサポートすることができる。通信トランスポートの別の実施例は、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅ（登録商標）（ｈｔｔｐ：／／ｗｗｗ．ｗｉ−ｆｉ．ｏｒｇ）によって定義及び公布されたＷｉ−Ｆｉ（登録商標）通信規格及びプロトコルに適合する、トランスポートとすることができ、本明細書で使用するとき、「Ｗｉ−Ｆｉ」とは、全般的に、Ｗｉ−Ｆｉ（登録商標）規格及びプロトコルを指す。Ｗｉ−Ｆｉプロトコルは、中央アクセスポイントを有する無線ネットワークを定義することができ、この中央アクセスポイントは、そのネットワーク上の種々のデバイス間の通信を経路指定する。このネットワークは、例えばＴＣＰ及びＨＴＴＰを含めた、標準インターネットプロトコルスイート（ＩＰ）をサポートすることができる。Ｂｌｕｅｔｏｏｔｈ及びＷｉ−Ｆｉは、通信トランスポート及び通信プロトコルの実施例として使用されるものであり、他のトランスポート及びプロトコルもまた、使用することができる点を理解されたい。更には、無線通信トランスポートが示されているが、有線トランスポートもまた、これらのアクセサリのうちの一部又は全てに提供することができる。例えば、電球１０８は、有線接続によってアクセスポイント１１４に接続することができ、コントローラ１０２は、ブリッジとしての役割を果たし得るアクセスポイント１１４に無線でメッセージを送信し、このアクセスポイント１１４が、有線接続を介して電球１０８にメッセージを伝えることによって電球１０８と通信することができる。有線通信と無線通信との他の組み合わせもまた可能である。
【００１７】
更には、１つのコントローラ１０２が示されているが、家庭環境１００は、複数のコントローラデバイスを有し得る。例えば、この家庭に居住する各人は、アクセサリ１０４〜１１２のうちの一部又は全てに関するコントローラとしての役割を果たすことが可能な、１つ以上の個人用デバイス（例えば、携帯電話、タブレット、ラップトップ、ウェアラブルデバイス）を有し得る。異なるコントローラデバイスは、それらのアクセサリの異なるサブセットと通信するように構成することができ、例えば、子供のコントローラは、サーモスタット１１２に対する設定を修正することを阻止される場合があるが、その一方で、親のコントローラは、設定を修正することが許可される。そのような許可は、例えば以下で説明されるペアリング技術を使用して、構成及び制御することができる。
【００１８】
本発明の特定の実施形態は、アクセサリ１０４〜１１２のうちのいずれか又は全てなどの１つ以上のアクセサリとの、コントローラ１０２などのコントローラによる通信を容易にする、統一的アクセサリプロトコルに関する。このプロトコルは、アクセサリをサービスの集合としてモデル化する、単純かつ拡張可能なフレームワークを提供し得るものであり、各サービスは、特性のセットとして定義され、各特性は、任意の所定の時間での定義値を有する。それらの特性は、そのアクセサリの状態の様々なアトミックな態様を表し得る。例えば、サーモスタット１１２の場合には、特性としては、電力（サーモスタットがオン又はオフのいずれであるか）、サーモスタット１１２によって測定される現在温度、及びサーモスタット１１２が設定される目標温度を挙げることができる。サービス及び特性を使用するアクセサリモデルの実施例は、以下で説明される。
【００１９】
このプロトコルは、アクセサリ（例えば、サーモスタット１１２）にコマンド及び制御メッセージ（要求）を送信するために、コントローラ（例えば、コントローラ１０２）によって使用可能なメッセージフォーマットと、コントローラ（例えば、コントローラ１０２）に応答メッセージを送信するために、アクセサリ（例えば、サーモスタット１１２）によって使用可能なメッセージフォーマットとを、更に定義することができる。コマンド及び制御メッセージにより、コントローラは、アクセサリ特性の現在の状態を問い合わせる（例えば、読み取る）ことが可能となり、一部の場合には、アクセサリ特性を修正する（例えば、書き込む）ことが可能となり得る。例えば、サーモスタット１１２の電力特性を修正することにより、サーモスタット１１２を、オフ又はオンにすることができる。したがって、適切なメッセージを送信することによって、機能又は製造元に関わりなくいずれのタイプのアクセサリも制御することができる。これらのメッセージフォーマットは、コントローラ及びアクセサリの全体にわたって、統一的なものとすることができ、実施例が以下で説明される。一部の実施形態では、アクセサリは、アクセサリ定義レコードを、コントローラに提供することができる。このアクセサリ定義レコードは、そのアクセサリの、アクセス可能な全ての特性についての完全な情報を含み得る。コントローラは、アクセサリと対話する方法を決定する際に、そのアクセサリ定義レコードを使用することができる。例えば、コントローラは、アクセサリ定義レコードからの情報を使用することにより、そのアクセサリを動作させるためのユーザインタフェースを構築すると共に、そのアクセサリに対する要求メッセージを構築することができる。
【００２０】
このプロトコルは、状態変化の場合に、アクセサリ１１２（又は、他のアクセサリ）がコントローラ１０２に選択的に通知することを可能にする、通知メカニズムを更に定義することができる。例としては、コントローラ１０２が、いずれかの特性が変化したか否かを見つけ出すためにアクセサリ（例えば、アクセサリ１１２）に問い合わせることが可能な受動的通知メカニズム、並びに、特定の特性が変化する場合に、アクセサリ１１２（又は、他のアクセサリ）が、選択的に１つ以上のコントローラに対するメッセージを生成すること、及び／又は広告を一斉配信することが可能な能動的、広告式、又はイベントベースの通知メカニズムが挙げられる。複数の通知メカニズムを同時にサポートすることができ、コントローラは、特定のアクセサリ、サービス、又は特性に関して使用する通知メカニズムを選択することができる。実施例が以下で説明される。
【００２１】
一部の実施形態では、所定のアクセサリとの通信は、認可済みコントローラに限定することができる。このプロトコルは、コントローラ１０２がアクセサリ１０４を制御することが可能となる、ユーザが意図する高度の信頼性を提供する状況下で、コントローラ１０２と所定のアクセサリ（例えば、ドアロックアクセサリ１０４）との間で「ペアリング」を確立する１つ以上のメカニズムを指定することができ、特定のアクセサリとペアリングを確立したコントローラは、そのアクセサリに関して認可済みであると見なすことができる。ペアリングは例えば、短期キー及び帯域外共有シークレットを使用する、安全な暗号化フレームワークを確立することによって、確立することができる。アクセサリ及びコントローラに関する長期公開キーをこのフレームワーク内で交換することができ、アクセサリ及びコントローラは、それらの交換されたキーを永続的に記憶することにより、ペアリングを確立することができる。ペアリングが確立された後、アクセサリ１０４は、受信した通信が、ペアリング済みコントローラ１０２からであるか、又は別のデバイスからであるかを検証することが可能であり、アクセサリ１０４は、ペアリング済みコントローラ１０２からではない、あらゆる通信を拒絶することができる（逆もまた同様）。例えば、以前にペアリングを確立したアクセサリとコントローラとが再接続する場合、それらは、以前のペアリングを（例えば、それぞれが他方の長期公開キーを保有することを証明することによって）検証して、ペア検証済みセッション内での通信に関して使用される、セッション固有の暗号キーを生成することができる。一部の実施形態では、複数のコントローラが同じアクセサリとペアリングを確立することができ、アクセサリは、そのペアリング済みコントローラのうちのいずれからの通信も、受理して応答することができる一方で、ペアリングされていないコントローラからの通信は、拒絶又は無視することができる。ペアリングプロセスの実施例が以下で説明される。
【００２２】
家庭環境１００は例示的なものであり、変型及び修正が可能であることが理解されるであろう。本発明の実施形態は、ユーザが、コントローラデバイスを使用して１つ以上のアクセサリデバイスを制御することを望む、任意の環境内で実施することができ、それらの環境としては、家庭、自動車若しくは他の乗り物、オフィスビル、複数の建物を有する構内（例えば、大学又は企業の構内）などが挙げられるが、これらに限定されない。コントローラは、１つ以上の他のデバイス（アクセサリ）を制御するために使用される、任意のデバイスとすることができ、アクセサリは、その動作の一部又は全てを、コントローラによって制御することが可能となる、任意のデバイスとすることができる。コントローラ１０２は、コントローラ内に実施されるか又は含まれるものとして本明細書で説明される特徴のうちの、いずれか若しくは全てを実施するか又は含み得るものであり、アクセサリ１０４〜１１２などのアクセサリは、アクセサリ内に実施されるか又は含まれるとして本明細書で説明される特徴のうちの、いずれか若しくは全てを実施するか又は含み得る。
【００２３】
一部の実施形態では、コントローラ１０２は、リモートな場所（例えば、世界内の任意の場所）から、アクセサリ（例えば、アクセサリ１０８）と通信することができる。例えば、リモートな環境内に配置されている間、コントローラ１０２は、アクセサリ１０８にメッセージを中継する（例えば、アクセサリ１０８とローカルで通信することが可能な、環境１００内に配置されたアクセスポイント１１４と通信することによる）能力を有するサーバと、広域ネットワーク（例えば、インターネット）を介して通信することができる。コントローラ１０２とアクセサリ１０８との間の通信のコンテンツは、サーバには不透明なものとすることができ、例えば、コントローラ１０２及びアクセサリ１０８は、メッセージが暗号化されている安全な通信セッション（例えば、本明細書で説明されるような、ペア検証済みセッション）を確立することができ、サーバは、その暗号化されたデータを、そのコンテンツに関しては不可知のままで、単純に転送することができる。それゆえ、アクセサリは、ローカルで（例えば、アクセサリへの直接通信経路を確立することが可能なコントローラによって）、又はリモートで（例えば、中継サーバなどを介して間接的に通信するコントローラによって）動作させることができる。
例示的アクセサリモデル
【００２４】
一部の実施形態では、統一的アクセサリプロトコルは、任意のアクセサリを「サービス」の集合としてモデル化する、統一的なフレームワーク及びシンタックスを提供することができる。「サービス」とは、本明細書で使用するとき、アクセサリデバイスの特徴、機能、若しくは動作を達成するための、データ及び関連挙動の集合（又は、その一部分）を指すことができる。各サービスは、「特性」の集合としてモデル化することができ、各特性は、そのアクセサリのアトミックなデータ要素又は挙動（アクセサリ状態の要素とも称されるもの）を表す。以下で説明されるように、アクセサリは、アクセサリ定義レコードをコントローラに提供することによって、そのアクセサリ自体をコントローラに説明することができ、このアクセサリ定義レコードは、そのアクセサリのサービス及び特性を定義する、構造化データオブジェクトとすることができる。この構造化データオブジェクトは、様々な特定のフォーマットで、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法）、Ｂｌｕｅｔｏｏｔｈ  ＬＥ汎用属性プロファイル（ＧＡＴＴ）、あるいは、構造化データを表現して通信する他の技術及びフォーマットを使用して、表現することができる。以下で説明されるように、コントローラは、アクセサリを制御する方法を決定するために、アクセサリ定義レコードを使用することができる。
【００２５】
例えば、図１のサーモスタットアクセサリ１１２は、何らかの目標に近い温度を維持するように、ある区域（例えば、部屋、又は建物、若しくは建物の一部分）の温度を調節する機能を実行する、構成要素を含み得る。アクセサリ１１２をモデル化する目的上、温度調節は、「サーモスタット」サービスとして特定することができる。このサーモスタットサービスの特性としては、サーモスタットがオン又はオフのいずれであるか、現在の設定目標温度、現在の測定温度、及び、サーモスタットによって調節されるシステムが、現在、加熱モード（加熱器をオンにすることにより、より高い目標温度に向けて測定温度を駆動することが可能）であるか、若しくは冷却モード（冷却器をオンにすることにより、より低い目標温度に向けて測定温度を駆動することが可能）であるかを、挙げることができる。より複雑な実施例では、サーモスタットは、例えば、時刻及び／又は曜日に応じて異なる目標温度を選択するように、プログラム可能とすることができ、そのような場合には、特性は、時間範囲のセット及び各時間範囲に対する関連目標温度などの特徴をプログラムすることを含み得る。
【００２６】
一部の場合には、アクセサリは、複数のサービスを提供することができる。例えば、ガレージドアアクセサリ１０６は、自動ガレージドア開閉装置を使用して実装することができ、この自動ガレージドア開閉装置は、ドアを開閉させることができ、また、例えばガレージの内部を照らすように制御することが可能な、照明も有する。したがって、ガレージドアアクセサリ１０６の定義としては、ガレージドアを開閉する機能を達成する「ドア開閉装置」サービスと、照明をオン又はオフにする（異なる）機能を達成する「電球」サービスとを挙げることができる。「ドア開閉装置」サービスの特性としては、ドアの現在の状態（例えば、開放、閉鎖、開放の途中、閉鎖の途中）、ドアが（例えば、開閉装置がドアを開放することを防ぐために）ロックされているか否か、及びドアが妨害されているか否か（例えば、ドア開閉装置システム内の障害物センサが、ドアの閉鎖を妨害する障害物を検知しているか否か）を挙げることができる。電球サービスの特性としては、照明がオン又はオフのいずれであるか、及び（照明が可変輝度制御を有する場合には）現在の輝度レベルを挙げることができる。
【００２７】
任意のアクセサリを、サービスの集合としてモデル化することができ、同じ環境内の異なるアクセサリが、同じサービス又は同様のサービスのうちの一部若しくは全てを含み得ることを理解されたい。例えば、家庭環境１００などの環境は、異なる場所の複数の電球（例えば、各部屋内の照明）、複数のドアロック（例えば、各外部ドアのロック、室内ドアのロック）などを有し得る。一部の実施形態では、統一的アクセサリプロトコルは、各アクセサリ及び各サービスを一意的に特定することができるように、名前空間を定義することによって、そのような重複を明示的に可能にすることにより、異なるアクセサリ上の同じサービスのインスタンス、又は同じアクセサリ上の同様のサービスの複数のインスタンスを、容易に識別することが可能となる。
【００２８】
一部の実施形態では、統一的アクセサリプロトコルは、頻繁に使用され、かつ／又は種々のアクセサリタイプの範囲にわたって存在すると予想される特性を含み得る、「コア」特性のセットを定義することができる。この特性のセットは、拡張可能にさせることができ、例えば、アクセサリ製造元は、製造元固有の特性（本明細書では「拡張」特性とも称されるもの）を定義することが許容される場合がある。それゆえ、アクセサリは、コア特性に限定されない、しかしながら、適用可能な場合に、コア特性を使用することにより、システムの設計及び動作を容易にすることができる。例えば、コントローラのシステムソフトウェアは、コア特性のプロパティを定義するコードを含み得るものであり、コア特性のみを使用するアクセサリは、その特性及びそれらの現在の値を特定することによって、そのアクセサリ自体をコントローラに説明することができる。
【００２９】
図２Ａ〜図２Ｄは、本発明の実施形態による、定義することが可能な標準特性２０１〜２２９の一部の実施例を示す。各特性２０１〜２２９は、それらの特性の所定のインスタンスが属するサービスを提供するアクセサリ（又は、アクセサリの一部分）の状態の、何らかの態様を表す値（図２Ａ〜図２Ｄには示さず）を有し得る。この実施例では、各特性２０１〜２２９は、タイプ、許可、及びフォーマットを有するものとして説明される。フォーマットに応じて、追加的情報（例えば、最小値、最大値、ステップサイズ、単位、又は有効値の列挙リスト）もまた含まれる。
【００３０】
特性の「タイプ」は、その特性に割り当てられた、一意の名前又は識別子（例えば、文字列）とすることができる。この実施例では、タイプを割り当てるために、逆引きドメイン名規則が使用され、このことにより、アクセサリ製造元による拡張特性の定義を容易にすることができる。例えば、図２Ａ〜図２Ｄに示される特性定義を含む、統一的アクセサリプロトコルの公布者が、「ｐｒｏｔｏ．ｃｏｍ」と呼ばれるインターネットドメインの所有者である場合には、全てのコア特性のタイプは、文字列「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．」で開始して、その後に、「ｏｎ」、「ｂｒｉｇｈｔｎｅｓｓ」などの、特性固有の名前を続けることができる。他の命名規則を使用することもできる。
【００３１】
一部の実施形態では、命名されるタイプに加えて、又はその代わりに、一意の数値識別子（図２Ａ〜図２Ｄには示さず）を、各特性に割り当てることができる。例えば、一意の数値識別子は、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）ＲＦＣ４１２２に適合する、３６の十六進数からなるＵＵＩＤとすることができる（本明細書で参照される全ての「ＩＥＴＦ  ＲＦＣ」文書は、ｈｔｔｐ：／／ｉｅｔｆ．ｏｒｇ／ｒｆｃ．ｈｔｍｌを介してアクセスすることができる）。この統一的アクセサリプロトコルは、全てのコア特性に関する共通の「ベース」ＵＵＩＤ（例えば、最後の２８の十六進数）を定義して、各特性に一意の「短い」ＵＵＩＤ（例えば、最初の８つの十六進数）を割り当てることができ、任意の番号付けスキームを使用することができる。特にＵＵＩＤを短縮化する規則と組み合わされた、ＵＵＩＤの使用により、コントローラ又はアクセサリは、文字列の使用と比較すると、より少量の送信データを使用して、対象となる特性を指定することが可能となり得る。例えば、一部の実施形態では、短縮化規則により、３６の数のＵＵＩＤを、僅か２つ又は３つの十六進数に低減することができる。
【００３２】
特性の「許可」は、コントローラが特性と対話する（例えば、特性を問い合わせるか又は修正する）ために許容される方式を示すことができる。一部の実施形態では、これらの許可は、文字列のアレイとして表すことができ、各文字列は、特定の対話の方式に対応する。文字列が存在する場合には、その文字列の対応する対話の方式が許可され、文字列が存在しない場合には、対話は許可されない。定義することが可能な許可文字列の一部の実施例を、表１に示す。
【表１】
2017511028.tif 000003
【００３３】
一部の実施形態では、特性に関する読み取り許可は、コントローラが、アクセサリ状態の対応する態様を見つけ出すことが所望される場合に与えられ、書き込み許可は、コントローラが、アクセサリ状態の対応する態様に変化を引き起こすことが可能であることが所望される場合に与えられる。それゆえ、例えば、アクセサリが直接制御することが可能な条件に関連する特性（例えば、Ｔａｒｇｅｔ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１０）は、読み取り及び書き込み許可を有し得るが、その一方で、アクセサリが直接制御することができない条件に関連する特性（例えば、Ｃｕｒｒｅｎｔ  Ｔｅｍｐｅｒａｔｕｒｅ特性２０９）は、読み取り許可のみを有し得る。
【００３４】
各特性２０１〜２２９は、アクセサリ状態の対応する属性又は態様を反映する、値を有し得る。図２Ａ〜図２Ｄは、各特性２０１〜２２９の値に関するフォーマットを指定する。本明細書で使用するとき、＜ｂｏｏｌｅａｎ＞フォーマットは、その特性が真及び偽の値を取ることを示し、＜ｉｎｔ＞フォーマットは、その特性が符号付きの整数値を取ることを示し、＜ｆｌｏａｔ＞は、その特性が符号付きの浮動小数点数値を取ることを示し、＜ｓｔｒｉｎｇ＞は、その特性が、例えばＵＴＦ−８符号化を使用する、文字列値を取ることを示し、＜ｄａｔｅ＞は、その特性が日付値（例えば、ＩＳＯ  ８６０１フォーマットでのＵＴＦ−８日付文字列）を取ることを示し、＜ｄａｔａ＞は、その特性を使用して、データブロブ（すなわち、そのコンテンツに関してプロトコルが不可知であり得る、データのブロック）を記憶することができることを示す。＜ｅｎｕｍ＞フォーマットは、その特性が、特定の条件を表す、定義された値のセットのうちの１つを取ることを示し、可能な値は、その特性に関する「有効値」として列挙される。一部の実施形態では、列挙値フォーマットは、各有効値に異なる整数を割り当てることによって実施することができる。＜ｔｌｖ＞フォーマットは、パック化されたタイプ−長さ−値のデータタイプを示し、第１バイトはタイプを示し、第２バイトは長さ（Ｎバイト）を示し、残余のＮバイトは値を含む。一部の実施形態では、他のフォーマットを使用することができ、例としては、本明細書では＜ｏｂｊｅｃｔ＞として示される、データオブジェクトフォーマット（データオブジェクトは、キー−値フォーマットを使用して更に定義することができる）、及びアレイフォーマット（他のフォーマットのいずれかでの、固定長又は可変長の値のアレイとすることが可能なもの）が挙げられる。一部の実施形態では、統一的アクセサリプロトコルは、特性に関する許容フォーマットの、閉じた領域を指定することができ、それゆえ、全ての特性（拡張特性を含めたもの）の値は、それらの許容フォーマットのうちの１つで表される。
【００３５】
特性の値は、アクセサリ状態の属性又は態様を示すことができる。この値は、表されている情報に適切なフォーマットで、指定することができる。一部の場合には、特性定義は、値の範囲を指定することができる。例えば、「最大」（又は、「最大値」）は、上限値を示し得るものであり、「最小」（又は、「最小値」）は、下限値を示し得るものであり、「ステップ」（又は、「ステップサイズ」）は、離散値を取る特性に関する、最小の増分を示し得る。「単位」は、値が測定される際の具体的な単位を示すために、定義することができ、この情報により、コントローラによる値の解釈を容易にすることができる。
【００３６】
例えば、「Ｏｎ」特性２０１は、アクセサリの電源がオンである場合には「ｔｒｕｅ」、アクセサリの電源がオフである場合には「ｆａｌｓｅ」のブール値を有し得る。この特性は、例えば、電球、照明スイッチ、又は、オン及びオフの状態を有する（かつ、そのオフ状態の間に、コントローラと通信することが可能な）他のアクセサリに関連して使用することができる。別の実施例としては、「Ｏｕｔｌｅｔ  ｉｎ  Ｕｓｅ」特性２０２は、電源コンセントを有するアクセサリで使用することができ、そのブール値は、電源コンセントに電源プラグが接続されているか否かを示すことができる。この場合には、アクセサリは、電源プラグを物理的に挿入又は除去することができないと想定され、したがって、この特性は、読み取り専用の許可を有する。
【００３７】
アクセサリモデルを使用する、アクセサリ制御の単純な実施例として、電源コンセントアクセサリが、そのコンセントへの電力潮流を開始又は停止させることが可能な、制御スイッチを有すると仮定する。この電源コンセントアクセサリは、「Ｏｎ」特性２０１及び「Ｏｕｔｌｅｔ  ｉｎ  Ｕｓｅ」特性２０２を有するサービスとして、モデル化することができる。コントローラは、「Ｏｕｔｌｅｔ  ｉｎ  Ｕｓｅ」特性２０２を読み取ることにより、そのコンセントに電源プラグが接続されているか否かを判定することができ、次いで、電源プラグが接続されているか否かに応じて、そのコンセントへの電力を有効又は無効にするように、「Ｏｎ」特性２０１に書き込むことができる。
【００３８】
Ｂｒｉｇｈｔｎｅｓｓ特性２０３、Ｈｕｅ特性２０４、及びＳａｔｕｒａｔｉｏｎ特性２０５は、例えば、光源を提供するアクセサリに関連して使用することができる。Ｂｒｉｇｈｔｎｅｓｓ特性２０３は、そのアクセサリによってサポートされる最大輝度の百分率として、輝度レベルを示す、（図２Ａでの「最小、最大、ステップ」フィールドで示されるような）０〜１００の範囲の整数値を有し得る。百分率の単位で指定される全ての特性と同様に、アクセサリは、デバイス状態の対応する態様（この場合には、輝度）に関して、厳密に１００の別個の設定をサポートする必要がなく、その代わりに、アクセサリは、所定の百分率値を、利用可能な設定に対応付けすることができる点を理解されたい。Ｈｕｅ特性２０４は、０〜３６０度の範囲の色相を指定する、浮動小数点値を有し得るものであり、この度数の値の、自然界の色相への変換は、標準色モデル化の実践に従うものとすることができる。Ｓａｔｕｒａｔｉｏｎ特性２０５は、所望の色の彩度を、最大値の百分率として定義する、０〜１００の範囲の浮動小数点値を有し得る。コントローラは、これらの特性を読み取ることにより、現在の設定を判定することができ、これらの特性に書き込むことにより、その設定を変更することができる。他の色モデルもまた、サポートすることができる（例えば、ＣＩＥ  １９３１色空間、色温度など）。
【００３９】
Ａｕｄｉｏ  Ｆｅｅｄｂａｃｋ特性２０６は、アクセサリが、ユーザ入力、又はアクセサリで検出される他のイベントに応答する、任意選択的な音声フィードバック（例えば、ビープ音）を有する場合に、使用することができる。音声フィードバックは、この特性にブール値を書き込むことによって有効又は無効にすることができる。Ｏｕｔｐｕｔ  Ｖｏｌｕｍｅ特性２０７は、音を発生させるアクセサリ上での出力音量を、読み取るか又は設定するために使用することができ、この値は、そのアクセサリが発生させることが可能な最大音量の、百分率を示し得る。
【００４０】
Ｌｏｇｓ特性２０８は、アクセサリが、タイムスタンプを押されたアクティビティのログを保持する場合に、使用することができる。それらのログの構造は、アクセサリ製造元によって定義することができ、又は、特定のタイプのアクセサリに関しては、統一的アクセサリプロトコルの発布者によって指定することができる。この実施例では、コントローラは、特性２０８を読み取ることによって、そのアクセサリのログを取得することができるが、それらのログを更新することはコントローラの役割ではないため、特性２０８には書き込まない。アクセサリは、そのルーチン動作の一部として、コントローラ対話のレコードをログに追加することができ、コントローラは、残りのログと共に、任意のそのようなレコードを受信することができる点を理解されたい。
【００４１】
図２Ｂは、サーモスタットアクセサリに関する特性の実施例を示すものであり、このサーモスタットアクセサリは、環境（例えば、家屋又は部屋）内部の現在温度を監視して、目標温度に向けて温度を調節するために、加熱及び／又は冷却システムを制御することが可能な、任意のアクセサリを含み得る。Ｃｕｒｒｅｎｔ  Ｔｅｍｐｅｒａｔｕｒｅ特性２０９は、アクセサリによって測定された現在温度を判定するために、コントローラによって読み取ることができる。Ｔａｒｇｅｔ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１０は、サーモスタットアクセサリの目標温度設定を判定するために、コントローラによって読み取ることができ、また、その目標温度設定を変更するために、コントローラによって書き込むこともできる。この実施例では、温度は、摂氏の度数で指定されるが、他の尺度（例えば、華氏、ケルビン）で置き換えることもできる。いずれの尺度がプロトコルによって指定されるかに関わりなく、コントローラ又はアクセサリは常に、内部使用及び／又はユーザへの表示のために、異なる尺度に変換することができる。例えば、Ｔｅｍｐｅｒａｔｕｒｅ  Ｕｎｉｔｓ２１１は、ユーザに温度を表示する際に、いずれの単位をアクセサリが使用するべきかを指示するために、コントローラによって読み取るか又は書き込むことができる。更には、温度特性２０９及び２１０は、許容される値の範囲を指定するが、他の範囲を使用することもでき、又は範囲を指定しないままにすることもできる。
【００４２】
一部のサーモスタットは、加熱及び冷却の双方を制御するように動作可能とすることができる。したがって、Ｃｕｒｒｅｎｔ  ＨＥＡＴ／Ｃｏｏｌ  Ｓｔａｔｕｓ特性２１２を読み取ることにより、サーモスタットが現在、加熱している（目標温度に向けて能動的に加温している）か、冷却している（目標温度に向けて能動的に冷却している）か、又はオフであるかを判定することができる。コントローラは、いつ加熱又は冷却するべきかを決定するものではないため、書き込み許可は提供されない。サーモスタットの動作モードは、Ｔａｒｇｅｔ  Ｈｅａｔ／Ｃｏｏｌ  Ｍｏｄｅ特性２１３に書き込むことによって制御することができる。この実施例では、モード特性２１３に関する有効値としては、加熱モード（サーモスタットが、目標温度に向けて環境を加温する）、冷却モード（サーモスタットが、目標温度に向けて環境を冷却する）、オートモード（サーモスタットが、環境の条件に応じて、加熱モード又は冷却モードを動的に選択することができる）、及びオフが挙げられる。オートモードが選択される場合、サーモスタットを加熱モード又は冷却モードへと切り替えるための、温度閾値を指定することが望ましい場合がある。例えば、Ｃｏｏｌｉｎｇ  Ｔｈｒｅｓｈｏｌｄ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１４は、現在温度が冷却閾値温度を超過する場合には、サーモスタットが冷却モードを有効にするように、冷却閾値温度を設定するために、コントローラによって書き込むことができ、Ｈｅａｔｉｎｇ  Ｔｈｒｅｓｈｏｌｄ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１５は、現在温度が加熱閾値温度を下回る場合には、サーモスタットが加熱モードを有効にするように、加熱閾値温度を設定するために、コントローラによって書き込むことができる。図２Ｂに示すように、Ｃｏｏｌｉｎｇ  Ｔｈｒｅｓｈｏｌｄ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１４及びＨｅａｔｉｎｇ  Ｔｈｒｅｓｈｏｌｄ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１５は、互いに異なり、かつＴａｒｇｅｔ  Ｔｅｍｐｅｒａｔｕｒｅ特性２１０とは異なる、上限値及び下限値を有し得るが、これは必須ではない。
【００４３】
図２Ｃは、ドア開閉装置（例えば、ガレージドア開閉装置、あるいは、ドアを開放及び／又は閉鎖する、他の自動化されたメカニズム）及びドアロックに関する特性の実施例を示す。Ｃｕｒｒｅｎｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１６は、ドアが現在、開放されているか、閉鎖されているか、開放若しくは閉鎖の途中か、又は停止している（例えば、完全開放又は完全閉鎖されておらず、移動もしていない）かを判定するために、コントローラによって読み取ることができる。Ｔａｒｇｅｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１７は、ドアを開放するべきか又は閉鎖するべきかを指示するために、コントローラによって書き込むことができる。コントローラが、Ｃｕｒｒｅｎｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１６に合致しない値を、Ｔａｒｇｅｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１７に書き込む場合には、アクセサリは、現在の状態を変更して、その目標に合致させるように、ドア開閉装置メカニズムを作動させることによって応答することができる。例えば、ドアが開放しており（Ｃｕｒｒｅｎｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１６が、「ｏｐｅｎ（開放）」の値を有し）、コントローラが、Ｔａｒｇｅｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１７に「ｃｌｏｓｅｄ（閉鎖）」の値を書き込む場合には、アクセサリは、ドアを閉鎖するように、ドア開閉装置を作動させることができる。ドア開閉装置の作動時に、アクセサリは、Ｃｕｒｒｅｎｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１６を「ｃｌｏｓｉｎｇ（閉鎖中）」に更新することができ、ドアが完全閉鎖されると、アクセサリは、Ｃｕｒｒｅｎｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１６を更に、目標状態に合致する「ｃｌｏｓｅｄ（閉鎖）」に更新することができる。コントローラは、Ｔａｒｇｅｔ  Ｄｏｏｒ  Ｓｔａｔｅ特性２１７を読み取ることによって、任意の時点で現在のドアの状態を学習することができる。
【００４４】
一部の実施形態では、ドア開閉装置アクセサリは、コントローラに追加的情報を提供することができる。例えば、Ｍｏｔｉｏｎ  Ｄｅｔｅｃｔｅｄ特性２１８を使用することにより、ドアの周囲での動作（例えば、ドアをノックすること）を、アクセサリが検出したか否かを示すことができる。Ｏｂｓｔｒｕｃｔｉｏｎ  Ｄｅｔｅｃｔｅｄ特性２１９を使用することにより、ドアの移動を妨げる恐れがある障害物を、アクセサリが検出したか否かを示すことができる。コントローラは、これらの特性を読み取ることによってこの情報を取得することができる。一部の実施形態では、アクセサリは、これらの特性の変化が検出された場合には（例えば、ドアが妨害されることになった場合、又は動作が検出された場合には）、コントローラに通知を送信することができる。
【００４５】
ドアをロックすることは、ドアの開放又は閉鎖とは、別個に取り扱うことができる。例えば、「ロックメカニズム」アクセサリは、デッドボルト、磁気ロック、又は、ドアが開放されることを防ぐために係合させることが可能な、任意の他の物理的メカニズムを制御する、任意のデバイスに関して実装することができる。Ｌｏｃｋ  Ｍｅｃｈａｎｉｓｍ  Ｃｕｒｒｅｎｔ  Ｓｔａｔｅ特性２２０は、ロックメカニズムが現在、固定解除（ロック解除）されているか、固定（ロック）されているか、故障している（ロック又はロック解除することが不可能）か、又は不明であるかを判定するために、コントローラによって読み取ることができる。Ｌｏｃｋ  Ｍｅｃｈａｎｉｓｍ  Ｔａｒｇｅｔ  Ｓｔａｔｅ特性２２１は、ドアのロック又はロック解除を要求するために、コントローラによって書き込むことができる。Ｌｏｃｋ  Ｍｅｃｈａｎｉｓｍ  Ｌａｓｔ  Ａｃｔｉｏｎ特性２２２は、ロック上で実行された最後の既知の動作を判定するために、コントローラによって読み取ることができる。様々なレベルの詳細をサポートすることができる。例えば、一実施形態では、有効値としては、（１）物理的移動を使用する（例えば、ユーザがデッドボルトレバーを物理的に移動させた）内側からの固定、（２）物理的移動を使用する外側からの固定、（３）キーパッドを使用する固定、（４）リモートでの（例えば、コントローラからの要求に基づく）固定、（５）タイムアウト条件に基づく固定、（６）物理的移動を使用する内側からの固定解除、（７）物理的移動を使用する外側からの固定解除、（８）キーパッドを使用する固定解除、及び（９）リモートでの固定解除を挙げることができる。他の有効値の組み合わせもまた、所望される情報の粒度に応じて、定義することができる。
【００４６】
更なる特性を、ロックメカニズムの管理に関連付けることができる。例えば、Ｌｏｃｋ  Ｍａｎａｇｅｍｅｎｔ  Ａｕｔｏ  Ｔｉｍｅｏｕｔ特性２２３を使用することにより、アクセサリがロックを自動的に再ロックするまでの、タイムアウト期間を設定することができる。このタイムアウト期間は、例えば、ロックがロック解除されるときに開始することができる。一部の実施形態では、タイムアウト期間の持続時間は、その特性の（例えば、秒の単位での）数値とすることができ、値０は、タイムアウト期間が存在しない（すなわち、ロックは、ロックする特定の行動が取られるまで、ロック解除されたまま維持することができる）ことを示すために使用することができる。Ｌｏｃｋ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ特性２２４は、そのロックに関連する特定の機能を、例えば、その機能を特定する値を特性２２４に書き込むことによって、呼び出すために使用することができる。呼び出すことが可能な機能の実施例としては、ロックアクティビティのログの読み取り（Ｌｏｇｓ特性２０８に関する値をアクセサリが返すことを、結果的にもたらし得る）、ログの消去、ロックの時間の設定などが挙げられる。別の実施例として、供給元は、１日の特定の時間の間のみ、ロックのリモート開放を許可することなどの、ロックの使用に関する様々なポリシーを、ユーザが設定することを可能にするように、望む場合がある。一部の実施形態では、コントローラは、これらのポリシーを、Ｌｏｃｋ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ特性２２４に書き込むことによって、ロックアクセサリに提供することができる。一部の実施形態では、統一的アクセサリプロトコルは、Ｌｏｃｋ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ特性２２４に書き込まれるデータのコンテンツを指定しないが、統一的アクセサリプロトコルを使用して、コントローラからアクセサリに確実にデータを通信することができ、かつ供給元固有の方式で、そのデータをアクセサリによって解釈することができるように、ＴＬＶフォーマット又は他のフォーマットでデータが提供されることを、指定することができる。
【００４７】
図２Ｄは、コア特性の更なる実施例を示す。Ｒｏｔａｔｉｏｎ  Ｄｉｒｅｃｔｉｏｎ特性２２５は、ファン（又は、回転要素を有する任意の他のアクセサリ）を、時計回り又は反時計回りのいずれかの方向で回転するように制御するために、使用することができる。Ｒｏｔａｔｉｏｎ  Ｓｐｅｅｄ特性２２６は、ファン（又は、他の回転要素）の回転速度を制御するために使用することができ、この速度は、最大速度の百分率として示される。
【００４８】
Ｎａｍｅ特性２２７は、アクセサリ又はサービスに、人間に読み取り可能な名前を割り当てるために、使用することができる。この名前は、文字列として（例えば、ＵＴＦ−８フォーマットで）表すことができる。
【００４９】
Ａｄｍｉｎｉｓｔｒａｔｏｒ−Ｏｎｌｙ  Ａｃｃｅｓｓ特性２２８は、アクセサリ又はサービスへのアクセスを、そのアクセサリに関する管理者として確立されている（すなわち、管理者許可を有する）コントローラに限定するために、使用することができる。コントローラを管理者として確立する技術の実施例が、以下で説明される。一部の実施形態では、アクセサリの管理者として確立されているコントローラのみが、特性２２８に書き込むことができる。
【００５０】
Ｖｅｒｓｉｏｎ特性２２９は、アクセサリ又はサービスについてのバージョン情報を提供するために、使用することができる。
【００５１】
図２Ａ〜図２Ｄに示す特性は、実施例として提供されていることを理解されたい。任意数のコア特性を定義することができる。例えば、屋内環境の他の制御可能な態様（例えば、相対湿度）に関する特性を、定義することができる。統一的アクセサリプロトコルの一部として定義される特性の具体的な組み合わせは、必要に応じて変化させることができる。一部の実施形態では、コア特性として定義されない特性は、本明細書で説明される技術を使用して、サードパーティ（例えば、アクセサリ製造元）によって、拡張特性として定義することができる。
【００５２】
一部の実施形態では、これらの特性のセットは、拡張可能である。アクセサリは、新たな特性（「拡張」特性とも称されるもの）を、その特性に関するプロパティ（又は、記述子）のセットを提供することによって定義することができる。図２Ｅは、本発明の実施形態による、定義可能な特性のプロパティのセットを示す。コア特性に関しては、これらのプロパティは、プロトコルによって（例えば、図２Ａ〜図２Ｄに示されるように）定義することができる。一部の実施形態では、アクセサリは、コア特性のプロパティのうちの一部を再定義することにより、その特性に関して定義されたデフォルトのプロパティを上書きすることができる。一部の実施形態では、拡張特性は、アクセサリ定義レコード内に、これらのプロパティを提供することによって定義することができる。実施例が以下で説明される。
【００５３】
「タイプ」２３０は、例えば、上述のような逆引きドメイン名規則を使用して特性のタイプを定義する、文字列とすることができる。一部の実施形態では、文字列に加えて、又は文字列の代わりに、数値識別子（例えば、上述のようなＵＵＩＤ）を、タイプ識別子として使用することができる。
【００５４】
「許可」２３１は、コントローラに関して許可されるアクセスのタイプを特定する、文字列（例えば、上記の表１内の許可のうちのいずれか又は全て）のアレイとすることができる。
【００５５】
「通知モード」２３２は、特性に対する変化を、どのようにコントローラに通知するべきかを指示するために使用される、文字列のアレイとすることができる。一部の実施形態では、コントローラは、特定の通知モードに加入するために、このプロパティに書き込むことができる。表２は、サポートすることが可能な通知モードの、一部の実施例を列挙する。これらの各通知モードの動作が、以下で説明される。
【表２】
2017511028.tif 000004
【００５６】
一部の実施形態では、受動的通知は、コントローラによるいずれの加入にも関わりなく、全ての特性に関して、全てのアクセサリによってサポートされ、他のサポートされる通知モードは、コントローラによる加入要求に基づいて、選択的に有効化することができる。一部の実施形態では、「Ｐａｉｒｅｄ  Ｒｅａｄ」許可を有する全てのコア特性はまた、少なくとも「イベント」通知モードもサポートする。
【００５７】
「フォーマット」２３３は、特性の値に関するフォーマットを特定する文字列、例えば、ブール値、文字列、整数、浮動小数点、ＴＬＶなどとすることができる。一部の実施形態では、このプロトコルは、認識されるフォーマットのセットを定義することができ、その定義されたセットから、フォーマット２３３を選択することができる。
【００５８】
「値」２３４は、特性の現在の値とすることができる。
【００５９】
「最小値」２３５及び「最大値」２３６は、限界が所望される場合に、特性に対する下限値及び上限値を設定するために、使用することができる。同様に、「ステップサイズ」２３７は、最小増分が所望される場合に、特性の値を変化させるための最小増分を指定するために、使用することができる。最小値、最大値、及びステップ値が指定される場合、アクセサリは、その範囲内のあらゆる有効値を認識して、その有効値に応答することが予想される。しかしながら、上述のように、このことは、そのアクセサリ上で利用可能な設定の数が、有効値の数と等しくなければならないことを意味するものではない。例えば、電球アクセサリが、Ｂｒｉｇｈｔｎｅｓｓ特性２０３を有する場合には、このアクセサリは、輝度特性が１００に設定されている場合に、輝度が最大となり、輝度特性が０に設定されている場合に、ゼロとなるように、（例えば、電球に供給される電流を調節することによって）輝度を制御することができる。輝度特性が定義されている電球は、ゼロと最大輝度との間に、少なくとも１つの中間階調を有するものと予想され（しかしながら、厳密に必要とされるものではない）、アクセサリのサポートが、１００よりも多いか又は少ない中間階調である場合には、そのアクセサリは、その輝度階調に対する輝度特性値の対応付けを定義することができる。
【００６０】
一部の実施形態では、列挙値フォーマットをサポートすることができ、フォーマット２３３が「列挙」として指定される場合に、「ｖａｌｉｄＶａｌｕｅｓ」プロパティ２３８を使用して、それらの有効値を列挙することができる。
【００６１】
「Ｕｎｉｔ」プロパティ２３９は、特性に関して使用する単位（例えば、百分率、特定の温度尺度など）を指示することができる。一部の実施形態では、このプロトコルは、好ましい単位系を指定することができ、この系の範囲内で、所定の特性に関するＵｎｉｔプロパティ２３９を選択することができる。
【００６２】
「ＵｓｅｒＤｅｓｃｒｉｐｔｏｒ」プロパティ２４０は、特性又はその機能を、人間に読み取り可能な方式で説明する、文字列を提供することができる。例えば、Ｃｕｒｒｅｎｔ  ＨＥＡＴ／Ｃｏｏｌ  Ｓｔａｔｕｓ特性２１２に関するユーザ記述子は、「加熱／冷却システムが現在、加熱しているか、冷却しているか、又はオフであるかを示す」と言うことができる。
【００６３】
「所有者」プロパティ２４１は、特性を定義又は再定義した、組織単位を特定することができる。一部の実施形態では、このことは、ユーザ又は開発者が、様々な特性の定義のソースを理解するために役立ち得る。
【００６４】
図２Ｅでのプロパティ（及び、任意選択的に他のプロパティ）のうちのいずれか又は全てを、１つの特性に関して定義することができる。上述のように、コア特性に関しては、このプロトコルは、デフォルトの定義を指定することができ、コア特性が使用される場合、その特性のプロパティの全てを、（例えば、以下で説明されるような）アクセサリ定義レコード内に含めることは必須ではない。一部の実施形態では、アクセサリは、再定義するべきプロパティを、アクセサリ定義レコード内に含めることによってコア特性を再定義することができる。拡張特性は、それらが定義するプロパティの全てを、アクセサリ定義レコード内に含めることによって定義することができる。
【００６５】
一部の実施形態では、特性のプロパティは、コントローラによって読み取ることができ、それらの特性を制御するための、及び／又は現在の値を提示するための、グラフィカルユーザインタフェースをレンダリングする方法を決定するために、使用することができる。例えば、Ｂｒｉｇｈｔｎｅｓｓ特性２０３（図２Ａ）、又は百分率として表現される任意の他の特性の場合には、コントローラは、０〜１００％のスライダとしてコントロールをレンダリングして、そのスライダを１％のステップで移動させることができる。特性２０１（図２Ａ）、又はブール値として表現される任意の他の特性の場合には、コントローラは、オン／オフのスイッチをレンダリングすることができる。温度関連の特性の場合には、コントローラは、「摂氏」の単位（又は、他の温度単位）を有する特性に基づく温度計などをレンダリングすることができ、又は、単純に数値を表示することもできる。ＵｓｅｒＤｅｓｃｒｉｐｔｏｒ２４０が、特性に関して定義される場合は、コントローラは、その特性に関するユーザインタフェース制御要素に関連して、テキストをレンダリングすることができ、このことは、その制御要素をユーザが理解することを容易にし得る。それゆえ、アクセサリは、自己記述型であり得ることにより、アクセサリ定義レコードが与えられると、コントローラは、任意のアクセサリを制御するためのインタフェースを、そのアクセサリに関して具体的にプログラムされていない場合でも、動的に生成することができる。
【００６６】
図２Ａ〜図２Ｄに示す特性、及び図２Ｅに示すプロパティ（又は、記述子）は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。統一的アクセサリプロトコルは、任意数及び任意の組み合わせの特性を定義することができ、示されたものとは異なるプロパティ及び値のセットを使用して、特性を定義することができる。例えば、最大文字列長プロパティを使用して、文字列の長さに対して上限値を指定することができ、最大データ長プロパティを使用して、データを含む特性に対して（例えば、データオブジェクト又はデータブロブに関して）上限値を指定することができる。
【００６７】
更には、上述のように、このプロトコルは、アクセサリ製造元が、それらのアクセサリに関して、カスタマイズされた拡張特性、又は製造元固有の拡張特性を定義することを可能にし得る。例として、製造元（インターネットドメイン「ｄｉｓｃｏｂａｌｌ．ｃｏｍ」を所有するもの）が、種々の方向及び種々の速度で回転するように制御することが可能なミラーボールと、そのボールの表面に向けて方向付けることが可能な光源とを有する、「ディスコボール」システムを製造すると想定する。光源は、図２Ａ〜図２Ｄからのコア特性（例えば、「オン」特性２０１及びＢｒｉｇｈｔｎｅｓｓ特性２０３）を使用して、モデル化及び制御することができる。製造元は、光源及び／又はミラーボールの更なる制御に関する、拡張特性を定義することを望む場合がある。図２Ｆは、このシナリオに関する拡張特性の実施例を示す。
【００６８】
Ｓｔｒｏｂｅ特性２４２は、ストロボ効果を制御するための、例示的特性である。真である場合、この照明は、ストロボモードで動作され、偽である場合、この照明は、定常モードで動作される。
【００６９】
Ｄｉｒｅｃｔｉｏｎ特性２４３は、ミラーボールの回転の方向を制御するための、例示的特性である。このボールは、無回転（停止される）か、時計回りに回転するか、又は反時計回りに回転することができる。コア特性が、Ｒｏｔａｔｉｏｎ  Ｄｉｒｅｃｔｉｏｎ特性２２５を含む実施形態では、製造元は、そのコア特性を使用するか又は拡張特性を定義するかを、選択することができる。
【００７０】
Ｓｐｅｅｄ特性２４４は、ミラーボールの回転の速度を制御するための、例示的特性である。この実施例での速度は、２つの設定（低速回転に関する０、高速回転に関する１）を有する。コア特性が、Ｒｏｔａｔｉｏｎ  Ｓｐｅｅｄ特性２２６を含む実施形態では、製造元は、そのコア特性を使用するか又は拡張特性を定義するかを、選択することができる。
【００７１】
上述のように、統一的アクセサリプロトコルは、アクセサリを、１つ以上のサービスとしてモデル化することができ、各サービスは、特性の集合としてモデル化される。したがって、サービスは、その構成要素である特性を特定することによって定義することができ、それらの特性は、コア特性及び／又は拡張特性の、任意の組み合わせを含み得る。一部の実施形態では、統一的アクセサリプロトコルは、頻繁に使用され、かつ／又は様々なアクセサリタイプにわたって有用であると予想されるサービスを含み得る、コアサービスのセットを定義することができる。このサービスのセットは、拡張可能にさせることができ、例えば、アクセサリ製造元は、コアサービスに製造元固有の特性を追加するか、又は追加的な「拡張」サービスを定義することが、許容される場合がある。しかしながら、適用可能な場合に、コアサービスを使用することにより、既定のサービス及び特性を、システム設計者が活用することを可能にすることによって、システムの設計及び動作を容易にすることができる。
【００７２】
図２Ｇ、図２Ｈは、本発明の実施形態による、定義することが可能なコアサービス２５１〜２５８の実施例を示す。各サービス２５１〜２５８には、そのサービスを特定する一意の名前とすることが可能な、「タイプ」を割り当てることができる。この実施例では、特性のタイプと同様に、アクセサリ製造元による新たなサービスの定義を容易にするために、逆引きドメイン名規則を使用して、タイプを定義することができる。それゆえ、図２Ｇ、図２Ｈでのコアサービスのタイプは、「ｃｏｍ．ｐｒｏｔｏ．ｓｖｃ」で開始する（「ｓｖｃ」は、そのタイプが、特性ではなくサービスに関するものであることを示すために、使用することができる）。
【００７３】
一部の実施形態では、タイプに加えて、又はその代わりに、一意の数値サービス識別子（図２Ｇ、図２Ｈには示さず）を、各サービスに割り当てることができる。例えば、ＩＥＴＦ  ＲＦＣ  ４１２２によって定義されるようなＵＵＩＤ（３６の十六進数からなる識別子）を、各サービスに割り当てることができる。この統一的アクセサリプロトコルは、全てのサービスに関する共通の「ベース」ＵＵＩＤ（例えば、最後の２８の十六進数）を定義して（必要に応じて、全ての特性に割り当てられるベースＵＵＩＤと同じか、又は異なるものとすることができる）、各サービスに一意の「短い」ＵＵＩＤ（例えば、最初の８つの十六進数）を割り当てることができ、任意の番号付けスキームを使用することができる。特に、「短い」ＵＵＩＤに基づく、ＵＵＩＤを短縮化する規則と組み合わされた、ＵＵＩＤの使用により、コントローラ又はアクセサリは、文字列の使用と比較すると、より少量の送信データを使用して、対象となるサービスを指定することが可能となり得る。
【００７４】
各サービス２５１〜２５８は、アクセサリが実行することが可能な機能を表し、必須特性（図２Ｇ、図２Ｈでの「必須特性」プロパティ）のセット、及び任意選択特性（図２Ｇ、図２Ｈでの「任意選択特性」プロパティ）のセットを参照することによって定義される。この実施例では、各サービスは、少なくとも１つの任意選択特性（名前）を有し、他の実施形態では、任意選択特性のセットは、少なくとも一部のサービスに関して、空にすることができる。
【００７５】
この実施例では、特性が、所定のコアサービスに関して「必須」であるとして定義されるのは、そのコアサービスを提供することを申告する、任意の対応アクセサリが、そのアクセサリを制御するために、その「必須」特性を認識及び使用すると予想される場合である。例えば、Ｌｉｇｈｔ  ｂｕｌｂサービス２５１は、必須特性「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｏｎ」（図２Ａの特性２０１）を含み、このことは、アクセサリが、「ｃｏｍ．ｐｒｏｔｏ．ｓｖｃ．ｌｉｇｈｔｂｕｌｂ」サービスを提供することを申告する場合には、そのアクセサリが、照明をオン（真）又はオフ（偽）にすることによって、特性「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｏｎ」への書き込み要求に応答し、照明がオン（真）又はオフ（偽）のいずれであるかを示す、ブール値を返すことによって、特性「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｏｎ」への読み取り要求に応答すると予想されることを意味する。一部の実施形態では、アクセサリは、認可済み（又は、ペアリング済み）コントローラからの要求にのみ応答することができ、認可は、以下で説明される。
【００７６】
この実施例では、特性が、所定のコアサービスに関して「任意選択的」であるとして定義されるのは、アクセサリが、そのサービスの中に、その特性を含めることが必要とされていないが、その特性を含むことができる場合である。例えば、Ｌｉｇｈｔ  ｂｕｌｂサービス２５１は、任意選択特性「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｂｒｉｇｈｔｎｅｓｓ」（図２Ａの特性２０３）を含む。オン又はオフの設定のみを有する電球アクセサリ（多くの従来の蛍光灯器具など）は、輝度制御を必要とせず、そのようなアクセサリは、「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｂｒｉｇｈｔｎｅｓｓ」特性をサポートする必要はない。輝度制御を有する電球アクセサリ（例えば、調光可能なランプ）は、「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｂｒｉｇｈｔｎｅｓｓ」特性を含むことにより、コントローラは、その調光器を動作させることが可能となり得る。同様に、色相及び彩度は、Ｌｉｇｈｔ  ｂｕｌｂサービス２５１に関する任意選択特性とすることができる。
【００７７】
必須特性及び任意選択特性の組み合わせを指定して、他のサービス２５２〜２５８を同様に定義することができる。それらの特性は、タイプ別に図２Ｇ、図２Ｈで特定され、上述の図２Ａ〜図２Ｄで示されるように定義することができる。特性は、１つのコアサービスでは必須であり、別のコアサービスでは任意選択的であり得る点に留意されたい。例えば、ロックメカニズム現在の状態、及び目標状態は、Ｇａｒａｇｅ  Ｄｏｏｒ  Ｏｐｅｎｅｒサービス２５３に関しては任意選択特性であるが、Ｌｏｃｋ  Ｍｅｃｈａｎｉｓｍサービス２５４に関しては必須である。
【００７８】
図２Ｇ、図２Ｈでのコアサービスの実施例は、例示の目的のために提供されていることを理解されたい。任意数のコアサービスを定義することができ、所定のコアサービスに関連付けられる、具体的な必須特性及び／又は任意選択特性は、必要に応じて変化させることができる。更には、拡張特性がサポートされる実施形態では、製造元は、拡張特性を追加することによって、コアサービスを増大させることを許容される場合がある。更には、又はその代わりに、一部の実施形態では、製造元は、コア特性及び／又は拡張特性の任意の組み合わせを使用して、拡張サービスを定義することができる。
【００７９】
このプロトコルによって指定されるコアサービスとすることが可能な、「Ａｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎ」サービスを使用して、そのアクセサリ自体を説明することができる。一部の実施形態では、このプロトコルは、全てのプロトコル対応アクセサリが、それらのアクセサリ定義レコード内に、アクセサリ情報サービスのインスタンスを含むように、指定することができる。図２Ｉは、本発明の実施形態による、（図２Ｇ、図２Ｈと同じフォーマットでの）Ａｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎサービス２６１に関する定義を示し、図２Ｊは、（図２Ａ〜図２Ｄと同じフォーマットでの）Ａｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎサービス２６１に関する追加的特性２７１〜２７６の定義を示す。
【００８０】
Ｉｄｅｎｔｉｔｙ特性２７１は、アクセサリの自己識別ルーチンを呼び出すために、コントローラによって書き込むことができる。この自己識別ルーチンは、ユーザが観察可能なアクションを、アクセサリが開始することを含み得る。例えば、アクセサリは、光を点滅させるか、音を発するか、振動するか、可動構成要素を移動させる（例えば、ドアを開閉させる）か、特定のメッセージ（例えば、「ここにいます」）を表示するか、又は、ユーザが観察することが可能な何らかの他の物理的アクションを実行することができる。アクセサリの自己識別ルーチンを、コントローラから呼び出すことは、例えば、そのコントローラが、ユーザが制御することを望むアクセサリと通信していることを確認する点に関連して、有用であり得る。一部の実施形態では、コントローラは、Ｉｄｅｎｔｉｔｙ特性２７１に「ｔｒｕｅ」を書き込むことによって、アクセサリの自己識別ルーチンを呼び出すことができる。
【００８１】
Ｍａｎｕｆａｃｔｕｒｅｒ  Ｎａｍｅ特性２７２、Ｍｏｄｅｌ  Ｎａｍｅ特性２７３、及びＳｅｒｉａｌ  Ｎｕｍｂｅｒ特性２７４は、アクセサリについての識別情報を取得するために、コントローラによって読み取ることができる。一部の実施形態では、これらの値は、人間に読み取り可能な文字列とすることができる。
【００８２】
Ｆｉｒｍｗａｒｅ  Ｒｅｖｉｓｉｏｎ特性２７５、Ｈａｒｄｗａｒｅ  Ｒｅｖｉｓｉｏｎ特性２７６、及び／又はＳｏｆｔｗａｒｅ  Ｒｅｖｉｓｉｏｎ特性２７７は、アクセサリについての世代情報を取得するために、コントローラによって読み取ることができ、この情報は、そのアクセサリと対話する方法を決定するために、コントローラによって使用することができる。一部の実施形態では、改訂情報は、標準フォーマット、例えば、＜ｘ＞．＜ｙ＞．＜ｚ＞；＜ｗ＞で表すことができ、＜ｘ＞は、メジャーバージョン番号であり、＜ｙ＞はマイナーバージョン番号であり、＜ｚ＞は改訂バージョン番号であり、＜ｗ＞は追加的情報を含み得る。
【００８３】
前述の特性及びサービスの実施例は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。統一的アクセサリプロトコルは、任意数及び任意の組み合わせの、コア特性並びにコアサービスを定義することができ、示されたものとは異なる特性のセットを使用して、所定のサービスを定義することができる。上述のように、拡張特性及び／又は拡張サービス（例えば、アクセサリ製造元によって定義されるようなもの）を使用して、コアサービスを増大させることにより、統一的な通信及び制御フレームワークの範囲内で、様々な必要性に対する、かなりの程度の柔軟性及び適応性を提供することができる。
【００８４】
一部の実施形態では、異なるバージョンのコアサービス定義が共存し得る。異なる世代の製品間での適合性を促進するために、後のバージョンのコアサービス定義は、新たな任意選択特性の追加に限定することができ、必須特性の一貫したセットを維持することにより、相互運用性を促進することができる。
【００８５】
上述のように、一部の実施形態では、アクセサリ製造元は、拡張特性をサービスに追加することができる。例えば、アクセサリが、ストロボの選択肢を有する照明である場合には、製造元は、ストロボ特性（例えば、図２ＦのＳｔｒｏｂｅ特性２４２）を、コアＬｉｇｈｔ  ｂｕｌｂサービス２５１に追加することができる。製造元はまた、拡張サービスを定義することもできる。例えば、上述のディスコボールの場合には、製造元は、ミラーボール及び照明を制御するために、拡張サービス「ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｓｖｃ．ｄｉｓｃｏｂａｌｌ」を定義することができる。このサービスは、以下の特性を含み得る。
●  ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｏｎ（図２Ａの特性２０１）、
●  ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｂｒｉｇｈｔｎｅｓｓ（図２Ａの特性２０３）、
●  ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｈｕｅ（図２Ａの特性２０４）、
●  ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｃｈ．ｓｔｒｏｂｅ−ｏｎ（図２Ｆの特性２４２）、
●  ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｃｈ．ｒｏｔａｔｅ−ｄｉｒｅｃｔｉｏｎ（図２Ｆの特性２４３）、及び
●  ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｃｈ．ｒｏｔａｔｅ−ｓｐｅｅｄ（図２Ｆの特性２４４）。
【００８６】
特性を有するサービスの集合としてアクセサリを表す、アクセサリモデルを、アクセサリオブジェクトとして、コントローラに通信することができる。アクセサリオブジェクトは、ＪＳＯＮ、又は、構造化データオブジェクトを（例えば、ネスト化されたキー−値のペアを使用して）表す他の表記法を使用して、通信することができる。図３Ａ〜図３Ｃは、本発明の実施形態による、アクセサリオブジェクト３００の実施例を示す。アクセサリオブジェクト３００は、ＪＳＯＮを使用して表されるが、他の表現で置き換えることもできる。付属の照明を有するガレージドア開閉装置が、例示の目的のために使用されるが、アクセサリモデルは、いずれの特定のアクセサリにも限定されない。
【００８７】
アクセサリオブジェクト３００は、サービスインスタンス３１０、３２０、３３０のアレイで表すことができ、各サービスインスタンスは、特性インスタンスのアレイとして表すことができる。それゆえ、サービスインスタンス３１０は、特性インスタンス３１１〜３１５を含み得るものであり、サービスインスタンス３２０は、特性インスタンス３２１〜３２５を含み得るものであり、サービスインスタンス３３０は、特性インスタンス３３１、３３２を含み得る。この実施例では、サービスインスタンス３１０は、図２ＩのＡｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎサービス２６１のインスタンスであり、サービスインスタンス３２０は、図２ＧのＧａｒａｇｅ  Ｄｏｏｒ  Ｏｐｅｎｅｒサービス２５３のインスタンスであり、サービスインスタンス３３０は、図２ＧのＬｉｇｈｔ  ｂｕｌｂサービス２５１のインスタンスである。（用語「サービス」及び「サービスインスタンス」は、用語「特性」及び「特性インスタンス」と同様に、本明細書では互換的に使用することができる。）
【００８８】
各サービスインスタンス３１０、３２０、３３０、及び各特性インスタンス３１１〜３１５、３２１〜３２５、３３１、３３２は、サービス又は特性のタイプを含むことにより、そのインスタンスのサービス又は特性を特定することができる。この実施例では、タイプ文字列が使用される。一部の実施形態では、ＵＵＩＤ又は短縮化されたＵＵＩＤを使用することにより、サービス及び特性のタイプを、文字列ではなく、数値的に特定することが可能となり得る。このことにより、アクセサリオブジェクト３００のサイズを低減することができる。各サービスインスタンス及び各特性インスタンスにはまた、インスタンス識別子も割り当てられる。この実施例では、アクセサリの各サービスインスタンス及び各特性インスタンスは、順次式に、又は任意の他の所望の方式で割り当てることが可能な、一意のインスタンス識別子を有する。このことにより、以下で説明されるように、アクセサリ内の任意のサービスインスタンス又は特性インスタンスには、そのインスタンス識別子を参照することによってアドレスすることが可能となる。一部の実施形態では、異なる一意性規則を実施することができる。例えば、各サービスインスタンスは、一意のサービスインスタンス識別子を有し得るものであり、各特性インスタンスは、サービスインスタンス内の特性インスタンスの間で一意の、特性インスタンス識別子を有し得る。このことにより、サービスインスタンスには、そのインスタンス識別子を参照することによってアドレスすることが可能となり、特性インスタンスには、その特性インスタンスが属するサービスインスタンスのインスタンス識別子と共に、そのインスタンス識別子を参照することによってアドレスすることが可能となり得る。他のスキームを使用することもできる。
【００８９】
図３Ａでは、サービスインスタンス３１０は、図２ＩのＡｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎサービス２６１のインスタンスとすることができる。一部の実施形態では、このプロトコルは、各アクセサリが、アクセサリ情報サービスの単一のインスタンスを有し、そのアクセサリ情報サービスのインスタンスが、１のインスタンスＩＤを有するように、指定することができるが、必要に応じて、異なる規則を指定することもできる。特性インスタンス３１１〜３１５は、サービス２６１に関する必須特性のインスタンスとすることができる。図３Ｂでは、サービスインスタンス３２０は、図２ＧのＧａｒａｇｅ  Ｄｏｏｒ  Ｏｐｅｎｅｒサービス２５３のインスタンスとすることができる。特性インスタンス３２１〜３２３は、サービス２５３に関する必須特性のインスタンスとすることができる。この実施例では、サービスインスタンス３２０はまた、ガレージドア開閉装置のロックメカニズムを制御するための、任意選択特性インスタンス３２４、３２５も含む。図３Ｃでは、サービスインスタンス３２０は、図２ＧのＬｉｇｈｔ  ｂｕｌｂサービス２５１のインスタンスとすることができる。特性インスタンス３３１は、サービス２５１に関する必須特性のインスタンスとすることができ、特性インスタンス３３２は、任意選択的な輝度特性のインスタンスとすることができる。
【００９０】
アクセサリ情報サービス以外のサービスに関しては、同じサービスの複数のインスタンスが、アクセサリオブジェクト内に共存し得る。例えば、独立制御可能な複数の電球を動作させるアクセサリは、各電球に関して、Ｌｉｇｈｔ  ｂｕｌｂサービス２５１の異なるインスタンスを有することにより、各電球の状態を独立して制御することが可能となり得る。
【００９１】
アクセサリオブジェクト３００はまた、読み取り許可を有する各特性インスタンスに関する、現在の値を提供することもできる。例えば、ガレージドアは現在、閉鎖されており（現在のドア状態特性インスタンス３２１は、「閉鎖」に対応付けされる、値２を有する）、照明はオフである（オン特性インスタンス３３１は、偽の値を有する）。識別特性インスタンス３１５は、この特性に対するアクセスが、書き込み専用であるため、ヌル値を有する。
【００９２】
各特性インスタンスに関する許可は、「ｐｅｒｍｓ」文字列のアレイとして示すことができる。この実施例では、そのアレイは、アクセサリが、この特性に関してイベント通知をサポートすることを示す、「Ｅｖｅｎｔｓ」文字列を含み得る。例えば、以下で説明されるように、コントローラは、その許可が「Ｅｖｅｎｔｓ」文字列を含む、任意の特性インスタンスに関して、イベント通知に加入することができる。イベント通知メカニズムの実施例が、以下で説明される。
【００９３】
図３Ｃは、コア特性を部分的に再定義するアクセサリの実施例を示す。輝度特性インスタンス３３２が、新たな最小値、最大値、及びステップ値を指定することによって、輝度増分の数を低減するように（コア特性２０３と比較して）再定義される。この再定義は、インスタンス３３２にのみ適用され、アクセサリオブジェクト３００内で定義される、いずれの他のサービスインスタンスの輝度特性にも、又は、所定のコントローラが相互運用する、いずれの他のアクセサリの輝度特性にも、影響を及ぼすものではない。
【００９４】
図３Ａ〜図３Ｃのアクセサリオブジェクトは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。アクセサリは、任意数及び任意の組み合わせのサービスインスタンスを含み得るものであり、アクセサリ内のサービスインスタンスは、任意数及び任意の組み合わせの特性インスタンスを含み得る。所定の特性インスタンスの、より多く又はより少ないプロパティを、アクセサリオブジェクト内で指定することができ、例えば、図２Ｅに示された様々なプロパティのうちのいずれか又は全てを、指定することができる。アクセサリが、複数のサービスインスタンスを含む場合、それらのサービスインスタンスのうちの１つ（例えば、アクセサリ情報サービスインスタンス以外の、そのアクセサリオブジェクト内で列挙される最初のサービスインスタンス）を、一次サービスとして指定することができる。
【００９５】
更には、図３Ａ〜図３Ｃは、ＪＳＯＮを使用する実装を示すものであるが、いずれの特定の表記法又はシンタックスの使用も、必須とされるものではない。例えば、本開示を入手可能な当業者には、Ｂｌｕｅｔｏｏｔｈ  ＬＥ汎用属性プロファイル（ＧＡＴＴ）を活用することによって、アクセサリのサービス及び特性を表すことにより、コントローラとＢｌｕｅｔｏｏｔｈ  ＬＥを使用するアクセサリとの間の通信を促進することができる点が理解されるであろう。例えば、サービス及び特性は、各サービス及び各特性が一意のＵＵＩＤを有するように、ＵＵＩＤによって特定することができる。
【００９６】
更には、一部の実施形態では、コントローラは、単一のエンドポイント（アクセサリサーバとも称されるもの）と通信して、１つ以上のアクセサリと対話することができる。このことをサポートするために、アクセサリ定義レコードは、１つ以上のアクセサリオブジェクトを含み得るものであり、各アクセサリオブジェクトは、図３Ａ〜図３Ｃに示される方式で表すことができる。各アクセサリオブジェクトには、アクセサリオブジェクトのアレイ内で一意である、アクセサリインスタンスＩＤを割り当てることができる。所定のアクセサリサーバは、１つ以上のアクセサリオブジェクトをサービス提供することができ、それらのアクセサリオブジェクトの全てが、そのアクセサリサーバに関する単一のアクセサリ定義レコード内に表される。コントローラは、任意数のアクセサリサーバと通信することができる。一部の実施形態では、複数のアクセサリを制御する（又は、別のアクセサリにメッセージを中継する）単一のエンドポイントは、「ブリッジ」と称される場合があり、そのようなアクセスポイントに関するアクセサリ定義レコードは、そのブリッジに関するアクセサリオブジェクト、並びに、そのブリッジによって制御される各アクセサリに関するアクセサリオブジェクトを含み得る。このブリッジに関するアクセサリオブジェクトは、アクセサリ情報サービスの単一のインスタンスのみを含み得るものであり、そのブリッジに関するアクセサリオブジェクトの存在により、コントローラに、ブリッジが存在することを示すことができる。
【００９７】
動作中、各アクセサリ（又は、アクセサリサーバ）は、そのアクセサリ定義レコードを、永続的記憶装置内に記憶することができる。アクセサリは、そのアクセサリ定義レコードの全て又は一部を、要求に応じて、コントローラに提供することができる。以下で説明されるように、このことは、デバイス発見プロセスの一部として、又は他の時点で（例えば、ペアリング済みコントローラからの要求に応じて）実施することができる。一部の実施形態では、コントローラは、アクセサリ定義レコードからの情報を使用して、そのアクセサリとペアリングするか又は他の方式で接続するか否かを、判定することができる。ペアリング又は接続が確立される場合には、コントローラは、そのアクセサリ定義レコードを使用して、アクセサリを制御する方法を決定することができる。
【００９８】
アクセサリ定義レコードは、自己完結型とすることができ、これは、コントローラが、そのアクセサリと対話するために、そのアクセサリについての、いずれの他の情報も必要としないことを意味する。例えば、アクセサリ定義レコードは、製造元固有の特性（例えば、「ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｃｈ．ｒｏｔａｔｅ−ｄｉｒｅｃｔｉｏｎ」）、及び／又は製造元固有のサービス（例えば、「ｃｏｍ．ｄｉｓｃｏｂａｌｌ．ｓｖｃ．ｄｉｓｃｏｂａｌｌ」）の完全な定義を含み得るものであり、この定義は、それらの特性及びサービスの、人間に読み取り可能な記述子を含み得る。コントローラは、様々な特性に関する、人間に読み取り可能な記述子、及びユーザが操作可能な制御要素（例えば、特性の「単位」プロパティに基づいて、選択されるもの）を提示する、ユーザインタフェースを生成するようにプログラムすることができ、ユーザは必要に応じて、アクセサリを制御するために、その制御要素を操作することができる。コントローラは、ユーザ入力（例えば、特性に新たな値を書き込むこと）に基づいて、制御メッセージ（要求）を送信することができ、それゆえ、コントローラは、アクセサリ固有のソフトウェア、又は他のアクセサリ固有のカスタム設定を必要とすることなく、そのアクセサリの制御が可能となる。
例示的なアクセサリ発見プロセス
【００９９】
アクセサリを制御する前に、コントローラは、最初に、制御することになるアクセサリとの通信を確立する。「アクセサリ発見」とは、本明細書で使用するとき、全般的に、コントローラが、通信することになるアクセサリの位置を特定することができる、任意のプロセスを指す。一部の場合での発見は、コントローラとアクセサリとの間の通信が実施するべき、ユーザ検証を含み得る。一部の実施形態では、アクセサリ発見は、ＵｐｎＰフォーラム（ｈｔｔｐ：／／ｗｗｗ．ｕｐｎｐ．ｏｒｇ）によって開発されたプロトコルの、Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）、又はＡｐｐｌｅ  Ｉｎｃ．によって開発されたＢｏｎｊｏｕｒ（登録商標）ネットワーキング技術（ＩＥＴＦ  ＲＦＣ  ６７６２及びＩＥＴＦ  ＲＦＣ  ６７６３として公開され、本明細書では「Ｂｏｎｊｏｕｒ」と称されるもの）などの、無線若しくは他のネットワーク上のデバイス及び／又はサービスの位置特定を容易にする、既存のサービス発見プロトコルを活用することができる。デバイス発見サービスでは、一方のデバイス（例えば、アクセサリ）は、その存在、アドレスを示す情報、及び任意選択的に、その能力についての追加的情報を、広告することができる。他方のデバイス（例えば、コントローラ）は、それらの広告を閲覧し、その一斉配信された情報に基づいて、対象となるデバイスを特定することができる。アドレスを使用して、閲覧しているデバイスは、広告主との通信を開始することができる。
【０１００】
ネットワーク及び発見サービスに応じて、広告は、リアルタイムの（例えば、マルチキャスト信号又はビーコン信号を通じた）情報の一斉配信、及び／又は、他のデバイスが情報を取得することが可能な、中央の（例えば、ネットワークアクセスポイントの）レポジトリに広告情報を提供することを含み得るが、これは必須ではない。広告の閲覧は、一斉配信された広告を検出すること、及び／又は、中央のレポジトリから広告情報を取得することを含み得る。
【０１０１】
図４は、本発明の実施形態による、コントローラ４０４によってアクセサリ４０２を発見するプロセス４００のフローチャートである。アクセサリ４０２は、例えば、図１でのアクセサリのうちのいずれかとすることができ、コントローラ４０４は、例えば、図１のコントローラ１０２とすることができる。
【０１０２】
ブロック４１０で、アクセサリ４０２は、そのアクセサリ４０２が現在ペアリングされていない（又は、ペアリングするコントローラを探している）ことを示すように、状態ビットを設定することができる。これは例えば、以下で説明される状態フラグ標識内のビット「ｓｆ＃」とすることができる。
【０１０３】
ブロック４１２で、アクセサリ４０２は、デバイス発見サービス上で、統一的アクセサリプロトコル（「ＵＡＰ」）をサポートするアクセサリとして、その存在を広告することができる。例えば、Ｂｏｎｊｏｕｒを使用して、アクセサリは、それ自体を、名前及びサービスタイプで広告することができる。この名前は、そのアクセサリに関する、ユーザに読み取り可能な名前（例えば、「サーモスタット」）とすることができ、一部の場合には、広告される名前は、アクセサリ定義レコードのアクセサリ情報サービスインスタンス内で指定される名前とすることができる。サービスタイプは、統一的アクセサリプロトコルに関して定義することができる（例えば、サービスタイプ「＿ｕａｐ．＿ｔｃｐ」）。この広告はまた、追加的情報も含み得る。例えば、アクセサリは、表３に示されるキーを有する、Ｂｏｎｊｏｕｒ  ＴＸＴを提供することができる。
【表３】
2017511028.tif 000005
【０１０４】
当業者には、他のサービス発見プロトコル及び技術を使用して、同様の情報を配信することができる点が理解されるであろう。例えば、ＳＳＤＰを使用して、アクセサリは、マルチキャストＨＴＴＰ  ＮＯＴＩＦＹメッセージを使用する、名前及びサービスタイプのＵＲＩを広告することができ、このＵＲＩは、アクセサリに対するユニキャスト要求を介して追加的情報を取得するために、コントローラによって使用することができる。
【０１０５】
ブロック４１４で、コントローラ４０４は、未構成のアクセサリに関して閲覧することができる。特定のタイミングが必要とされることはないが、一般的に、コントローラは、コントローラの閲覧時にアクセサリの広告が検出可能である場合にのみ、アクセサリを発見する。
【０１０６】
ブロック４１６で、コントローラ４０４は、例えばブロック４１２からの広告を検出することによってアクセサリ４０２を見つけることができる。ブロック４１８で、コントローラ４０４は、その広告に基づいて、アクセサリ４０２が、相互運用に関する「対象のもの」又は潜在的な候補であるか否かを判定することができる。例えば、コントローラ４０４は、表２の発見状態フラグ「ｓｆ＃」を確認することにより、そのアクセサリが、既にコントローラと構成又はペアリング済みであるか否かを判定することができる。別の例として、コントローラ４０４は、表２のプロトコルバージョン「ｐｖ」を確認することにより、そのアクセサリのプロトコルバージョンが、コントローラのものと適合可能であるか否かを判定することができる。更には、一部の場合には、コントローラは、アクセサリに関して、特定のコンテキストで閲覧している（例えば、特定のアプリケーションを実行している）場合があり、広告される名前、一次サービス識別子、アクセサリモデル名、特徴フラグ、又は、アクセサリの広告から入手可能な任意の他の情報に基づいて、対象となるアクセサリを限定することができる。コントローラ４０４が、そのアクセサリが対象のものではないと判定する場合には、コントローラ４０４は、ブロック４１４に戻り、閲覧を継続する。（一部の実施形態では、この閲覧動作は、対象となるアクセサリが見つからない場合には、タイムアウトすることができる。）
【０１０７】
ブロック４２２で、コントローラ４０４は、そのアクセサリについての情報をユーザに提示することができ、ブロック４２４で、ユーザは、そのアクセサリとのペアリングをコントローラが確立するべきか否かを指示する入力を提供することができる。例えば、コントローラ４０４は、そのアクセサリの広告から取得された情報のうちのいずれか又は全てを、ユーザに提示して、コントローラ４０４をアクセサリ４０２に接続するべきか否かを指示するように、ユーザに促すことができる。必須ではないが、ユーザ確認を要求することは、コントローラとアクセサリとの間の虚偽又は不要なペアリングを回避するために役立ち得る。
【０１０８】
ブロック４２６で、コントローラ４０４は、ブロック４２４で受信したユーザ入力を解釈して、アクセサリ４０２とペアリングするべきか否かを判定することができる。ペアリングするべきではない場合には、コントローラ４０４は、ブロック４１４に戻り、他のアクセサリを探すことができる。コントローラ４０４及びアクセサリ４０２が、ペアリングするべきである場合には、ブロック４２８及びブロック４３０で、コントローラ４０４及びアクセサリ４０２はペア設定プロセスを実行することができる。一部の実施形態では、このペア設定プロセスを使用することにより、コントローラ４０４とアクセサリ４０２との間の安全な通信を容易にするための暗号キーを確立することができ、ブロック４２８及びブロック４３０で実施することが可能なペア設定プロセスの実施例が以下で説明される。一部の実施形態では、ユーザ確認を、このペア設定プロセスに組み込むことができ、ペア設定を開始する前の別個のユーザ確認は必要とされない。
【０１０９】
ペア設定プロセスの完了が成功したものと想定すると、ブロック４３１で、アクセサリ４０２は、例えば上述の状態フラグ標識「ｓｆ＃」を更新することによって、現時点でそのアクセサリと通信するために認可が必要とされていること、及び／又は、現時点で、そのアクセサリが少なくとも１つのコントローラとペアリングされていることを示すように、その状態を更新することができる。
【０１１０】
ブロック４３２で、コントローラ４０４は、アクセサリ４０２からのアクセサリ定義レコードを取得してキャッシュすることができ、アクセサリ４０２は、ブロック４３４で、そのレコードを要求に応じて提供することができる。コントローラ４０４が、アクセサリ定義レコードをキャッシュする場合、その情報は、アクセサリ４０２内の状態変化の検出を容易にするために使用することができる。一部の実施形態では、コントローラ４０４はまた、アクセサリの広告からの情報（例えば、上記の表２からの情報のうちのいずれか又は全て）もキャッシュすることができ、この情報もまた、例えば、以下で説明されるような状態カウンタ「ｓ＃」を使用して、そのアクセサリ内の状態変化を検出するために使用することができる。
【０１１１】
ブロック４３６及びブロック４３８で、コントローラ４０２及びアクセサリ４０４は、コマンド及び制御メッセージの交換を開始することにより、コントローラ４０４は、アクセサリ４０４を制御することが可能となり得る。一部の実施形態では、これらのメッセージは、ペア設定プロセスで、又は、以下で説明されるような後続のペア検証プロセスで確立されたキーを使用して、暗号化することができる。
【０１１２】
本明細書で説明される発見プロセスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。更には、Ｂｏｎｊｏｕｒサービスが、デバイス発見サービスの実施例として使用されているが、同様の概念は、他のデバイス発見サービスのコンテキストで適用することもできる。
【０１１３】
一部の実施形態では、特定のアクセサリとペアリングするか否かを判定する前に、コントローラ４０４は、アクセサリ４０２から、アクセサリ定義レコード（又は、その一部分）を要求することができる。例えば、コントローラ４０４は、アクセサリにメッセージ（例えば、ＨＴＴＰ  ＧＥＴ要求）を送信して、そのアクセサリ定義レコードを要求することができる。このＨＴＴＰ  ＧＥＴ要求に関して使用されるＵＲＬは、統一的アクセサリプロトコルの規則によって、又はアクセサリの広告内で（例えば、ＴＸＴレコード内で）指定することができる。構成に応じて、アクセサリ４０２は、ペアリングされていないコントローラからの要求に応答して、そのアクセサリ定義レコードの全て、一部を提供することができ、又は全く提供しないことも可能である。一部の実施形態では、アクセサリ４０２は、部分的なアクセサリ定義レコードを提供することができる。例えば、上述のように、一部の特性は、それらの特性の読み取り及び／又は書き込みが、ペアリング済みコントローラによってのみ可能であることを指定する、プロパティを有し得るものであり、そのような特性についての情報を、ペアリングされていないコントローラに提供することは、望ましくない場合がある。したがって、アクセサリ４０２は、「パブリック」な特性、すなわち、ペアリングされていないコントローラが読み取り及び／又は書き込みを許可される特性を、特定することができ、ペアリングされていないコントローラに提供される、部分的なアクセサリ定義レコードは、少なくとも１つのパブリックな特性を有する、サービスインスタンスのみを含み得るものであり、パブリックな特性及び非パブリックな特性の双方を有するサービスインスタンスのうちの、パブリックな特性インスタンスのみを含み得る。一部の実施形態では、アクセサリ定義レコードは、ペアリングが確立される前には、全くアクセス不能であるように作成され、その場合には、ペアリングするか否かの決定は、アクセサリの広告、コントローラのコンテキスト、及び／又はユーザ入力に基づき得る。
【０１１４】
一部の実施形態では、発見プロセス４００又は同様のプロセスを使用して、状態変化を検出することができる。例えば、表２に示されるように、状態が変化する際に、状態番号「ｓ＃」をインクリメントすることができる。アクセサリは、例えば、更新されたＴＸＴレコードを一斉配信することによって、状態変化を広告することができ、以前に（例えば、プロセス４００のブロック４３２で）そのＴＸＴレコードをキャッシュしている、ペアリング済みコントローラは、一斉配信された「ｓ＃」の値と、そのキャッシュされている値とを比較することによって、変化を検出することができる。
【０１１５】
図４のプロセスは、コントローラ及びアクセサリが、ＴＣＰ／ＩＰを使用して通信する場合に、使用することができる。一部の実施形態では、統一的アクセサリプロトコルは、ＴＣＰ／ＩＰに加えて、又はその代わりに、Ｂｌｕｅｔｏｏｔｈ  ＬＥなどの他のトランスポートをサポートすることができる。このことが当てはまる場合、アクセサリは、それらのサービスを、Ｂｌｕｅｔｏｏｔｈ  ＬＥを使用して広告することができる。例えば、アクセサリは、１つ以上のＢｌｕｅｔｏｏｔｈ  ＬＥ広告チャネル上で、広告することができる。この広告データは、例えば、アクセサリに関するローカル名、一意のアクセサリ識別子、アクセサリが発見可能であることを示すフラグ、サービス（以下で説明されるようなペアリングサービスを含めたもの）のうちの少なくとも一部に関するＵＵＩＤ、アクセサリ状態の標識（表２での現在の状態番号と同様のもの）、及び、アクセサリが、少なくとも１つのコントローラとペア設定を実行しているか否かの指標のうちの、いずれか又は全てを含み得る。この情報は、上述のプロセス４００と同様の発見プロセスで使用することができる。
例示的な通信
【０１１６】
コントローラが、アクセサリとのペアリングを確立した後、そのコントローラは、コマンド及び制御メッセージ（要求）を、そのアクセサリに送信することができる。これらの要求は、アクセサリの状態についての情報を取得するために、及び／又はアクセサリの状態の態様を変化させるために使用することができる。一部の実施形態では、コマンド及び制御メッセージは、アクセサリ定義レコード内で定義されるような、特定のサービス又は特性に関するパスを反映するＵＲＬにアドレス指定される、ＨＴＴＰ要求とすることができる。そのような実施形態では、アクセサリは、ＨＴＴＰサーバ（リソースに関する要求を受信して応答する）としての役割を果たし得るものであり、その一方で、コントローラは、ＨＴＴＰクライアント（サーバ／アクセサリに対する要求を生成して、応答を受信する）としての役割を果たし得る。一部のアクセサリは、例えば、種々のインタフェース又はドメイン上での通信を管理するために、複数のＨＴＴＰサーバを実装することができる点に留意されたい。一部の実施形態では、アクセサリ及びコントローラは、単一のＴＣＰ接続及び／又はＨＴＴＰパイプライン方式を通じて、複数のＨＴＴＰ要求をサポートする（例えば、応答を受信する前に、複数のＨＴＴＰ要求を送信する）ことができる。
【０１１７】
例えば、図３Ａ〜図３Ｃに示されるアクセサリオブジェクト３００を仮定すると、コントローラは、リソースを表すために、図５ＡのＵＲＬ５００を構築することができ、この場合には、図３Ｂで定義されるドア開閉装置サービスインスタンス３２０のドア状態特性インスタンス３２１である。ＵＲＬ５００は、プロトコル識別プレフィックス５０２（「ｈｔｔｐ：／／」）、アクセサリに関するホスト名５０４（上述の図４の発見プロセスを通じて取得することが可能なもの）、及びローカルパス５０６を含む。ローカルパス５０６は、統一的アクセサリプロトコルを通じて公開されるサービスへの参照を示す、プロトコルキーワード５０８（「ｐｒｏｔｏ／」）、特定のサービスインスタンスを特定する、サービスインスタンス識別子５１０（「ｓｅｒｖｉｃｅ／＜サービスＩＤ＞」）、及び、そのサービスインスタンス内の特性インスタンスを特定する、特性インスタンス識別子５１２（「ｃｈａｒａｃｔｅｒｉｓｔｉｃ／＜特性ＩＤ＞」）を含み得る。図５Ａでは、＜サービスＩＤ＞及び＜特性ＩＤ＞は、アクセサリオブジェクト内で定義されたインスタンス識別子で置き換えられている。それゆえ、図３Ａ〜図３Ｃを参照すると、７のインスタンスＩＤを有するサービスインスタンスは、ガレージドア開閉装置サービスインスタンス３２０であり、８のインスタンスＩＤを有する特性インスタンスは、現在の状態特性インスタンス３２１となる。それゆえ、ＵＲＬ５００は、ガレージドア開閉装置の延在のドア状態を参照するものとして、理解することができる。同様の方式で、サービス及び特性に関するインスタンスＩＤを使用して、他のＵＲＬを、アクセサリ定義レコードから生成することができる。任意のサービスインスタンスの任意の特性インスタンスを、この方式で特定することができる。
【０１１８】
コントローラは、この方式で構築されたＵＲＬに対するＨＴＴＰ  ＧＥＴ（ＰＵＴ）要求を生成することにより、特性を読み取る（書き込む）ことができる更には、ＵＲＬ５００の階層構造を利用することにより、コントローラは、単一のトランザクションで、複数の特性又は複数のサービスに対する、読み取り若しくは書き込みが可能となり得る。例えば、特定のサービスの全ての特性を読み取るように、ＧＥＴ要求を送信することは、特性識別子を省略することによって達成することができる。応答は、図３Ａ〜図３Ｃと同様のフォーマットで特性を含む、ＪＳＯＮオブジェクトとすることができる。
【０１１９】
アクセサリリソースの現在の状態を判定するために、コントローラは、図５ＡのＵＲＬ５００に基づくＨＴＴＰ  ＧＥＴ要求を送信することができる。図５Ｂは、図５ＡのＵＲＬ５００から構築された、ＧＥＴ要求５２０の実施例を示す。ＧＥＴ要求５２０は、ＵＲＬ５００のホスト５０４にアドレス指定され、ローカルパス５２６（ＵＲＬ５００のローカルパス５０６と同様のもの）を、取得するリソースとして指定する。この実施例では、ローカルパス５２６は、単一の特性を指定するものではなく、指定されたサービスインスタンスの全ての特性を読み取る要求として、解釈することができる。
【０１２０】
ＨＴＴＰ  ＧＥＴ要求５２０に応答して、アクセサリは、要求されたリソース（状態情報）を提供する、ＨＴＴＰ応答を送信することができる。図５Ｃは、図５Ｂの要求に応答して提供することが可能な、例示的なＨＴＴＰ応答５３０の一部分を示す。この応答は、その応答及び状態（「２００  ＯＫ」）を特定し、コンテンツ５３４が、統一的アクセサリプロトコルによって定義されるようなＪＳＯＮオブジェクトとしてフォーマットされていることを示す、ＨＴＴＰ応答ヘッダ５３２を含む。コンテンツ５３４は、要求されたリソースに関する状態情報を含み、この実施例では、図３Ｂのドア開閉装置サービスインスタンス３２０である。サービスインスタンス３２０は、５つの特性インスタンスを含み、この要求は、全ての特性を読み取ることであるため、５つ全ての特性の現在の状態が報告される。（図５Ｃでは、２つの特性のみが示されているが、同様の方式で残部が存在し得ることが理解されるであろう。）所望のレベルの粒度を反映するように、パス５２６を修正することによって、他のレベルの粒度（例えば、単一の特性インスタンス、又は全てのサービスインスタンス）の読み取り要求及び応答を構築することができる。
【０１２１】
同様に、コントローラは、適切なＵＲＬにＨＴＴＰ  ＰＵＴ要求を送信することによって、アクセサリに関する状態情報を変更することができる。図５Ｄは、図５ＡのＵＲＬ５００から構築された、ＰＵＴ要求５４０の実施例を示す。ＰＵＴ要求５４０は、ＵＲＬ５００のホスト５０４にアドレス指定され、ローカルパス５４６（ＵＲＬ５００のローカルパス５０６と同様のもの）を、コンテンツ５４２が書き込まれるリソースとして指定する。この実施例では、ＰＵＴ要求５４０は、１つの特性インスタンスに書き込むものであるため、パス５４６は、その所望の特性インスタンス（図３Ｂの、ドア開閉装置目標ドア状態特性インスタンス３２２に相当するもの）のインスタンスＩＤを含む。コンテンツ５４２は、書き込む値を指定する。図３Ｂの実施例では、特性インスタンス３２２は、タイプ「ｃｏｍ．ｐｒｏｔｏ．ｃｈ．ｄｏｏｒ−ｓｔａｔｅ．ｔａｒｇｅｔ」のものであり、上述のように、この特性タイプに関する値１は、「開放」状態に対応付けすることができる。したがって、ＰＵＴ要求５４０は、ガレージドアを開放する命令として、アクセサリによって解釈することができる。
【０１２２】
アクセサリは、空のＨＴＴＰ「２０４  Ｎｏ  Ｃｏｎｔｅｎｔ（コンテンツなし）」応答で応答することができ、例えばドアを開放することによって、状態の更新を実施することができる。（ドアが能動的に開放している間、アクセサリは、現在のドア状態特性インスタンス３２１を、ドアが開放中であることを示す値に更新し、次いで、ドアが完全に開放されると、「開放」を示す値に更新することができる。）一部の実施形態では、アクセサリ応答は、例えば図５Ｆを参照して以下で説明されるような、コンテンツを含み得る。例えば、エラーが発生した場合には、アクセサリは、ＨＴＴＰエラー応答で応答することができる。例えば、ＨＴＴＰエラーコード４００は、不正な要求（例えば、シンタックスエラー又は無効な特性）を示し得るものであり、エラーコード４０３は、禁止アクション（例えば、コントローラが書き込み許可を有さないリソースへの、書き込みの試み）を示し得るものであり、エラーコード５００は、アクセサリでの内部エラーを示し得る。一部の場合には、エラー応答のコンテンツは、そのエラーについての情報を有する、「ｒｅｓｐｏｎｓｅ（応答）」オブジェクトを含み得る。応答オブジェクトの実施例は、以下で説明される。
【０１２３】
一部の実施形態では、単一のＰＵＴ要求を使用して、複数の特性を書き込むことができる。図５Ｅは、図５ＡのＵＲＬ５００から構築された、ＰＵＴ要求５５０の実施例を示す。ＰＵＴ要求５５０は、ＰＵＴ要求５４０と同様のものとすることができるが、ただし、ローカルパス５５６は、複数の特性に書き込むことを可能にする、サービスレベルの粒度である。図３のアクセサリ定義３００、及び図２Ａでの特性定義を参照すると、ＰＵＴ要求５５０は、ガレージドアをロック解除して開放する要求として、解釈することができる。この実施例が示すように、ＰＵＴ要求を使用して、サービスの特性のサブセットに書き込むことが可能である。この要求は、書き込まれる特性のみを含み得るものであり、各特性データオブジェクト内の、タイプ及びインスタンスＩＤのキーの存在により、曖昧性を防ぐことができる。更には、書き込まれる特性は任意の順序で列挙することができる。
【０１２４】
アクセサリは、各特性の現在の状態を含むメッセージで、応答することができる。図５Ｆは、本発明の実施形態による、例示的な応答５６０を示す。応答５６０は、空ではないＨＴＴＰ応答であり、そのコンテンツ５６２は、更新された各特性５６３、５６４の現在の値を含む。各特性に関して、「ｒｅｓｐｏｎｓｅ」オブジェクト５６５、５６６が含まれる。図示のように、この応答オブジェクトは、「ｄｅｖｅｌｏｐｅｒＭｅｓｓａｇｅ（開発者メッセージ）」を含み得る。エラーが発生した場合には、この開発者メッセージは、そのエラーの平易な文言での説明を提供することができ、任意選択的に、その問題を修正するための提案を提供することができる。「ｅｒｒｏｒＣｏｄｅ（エラーコード）」は、（例えば、応答して行うべきコントローラのアクションを選択するために使用可能な）数値コードとすることができる。「ｍｏｒｅＩｎｆｏ（更なる情報）」文字列は、エラーについて役立てるために参照するべき、プロトコル仕様又は他の文書のセクションを特定することなどの、追加的情報を提供することができる。図５Ｆに示す実施例では、エラーは発生しておらず、各特性の状態は、図５Ｅで要求された状態である。エラーが発生した場合には、その状態は、要求された状態に合致し得ない。
【０１２５】
同様の方式で、図５Ｅの要求５５０と同様のＰＵＴ要求を使用して、１つのサービス、又は複数のサービスに書き込むことができ、図５Ｆの要求５０６と同様の応答を生成することができる。
【０１２６】
上述のように、コントローラは、ＰＵＴ要求を送信することによって、アクセサリ内の状態変化を要求することができる。一部の場合には、この状態変化は、完了するためにある程度の時間を必要とし得る、アクセサリ機能（例えば、コマンド又は動作の実行）を呼び出すことを伴い得る。応答する際のアクセサリの柔軟性を可能にするために、一部の実施形態は、一部の特性又はサービスに関する、遅延応答挙動をサポートする。
【０１２７】
コントローラが、ＨＴＴＰ  ＰＵＴを使用して特性に書き込む場合、アクセサリは、その要求を評価して、応答選択肢を（例えば、その書き込まれた具体的な特性に基づいて）選択することができる。一部の実施形態では、２つの応答選択肢、「インライン結果」及び「問い合わせ結果」が提供される。インライン結果に関しては、アクセサリは、要求された動作を実行して、次いで、その結果を（例えば、図５Ｅ及び図５Ｆを参照して上述されたような）ＨＴＴＰ応答で返す。この応答は、その動作を完了するために必要である限り、遅延させることができる。問い合わせ結果に関しては、アクセサリは、動作を実行する前にＨＴＴＰ応答を返す。この場合には、この動作前ＨＴＴＰ応答は、コントローラが後に、ＨＴＴＰ  ＧＥＴ要求を送信して結果を得るために使用することが可能な、（アクセサリによって割り当てられた）「トランザクションＩＤ」を含み得る。この動作前ＨＴＴＰ応答はまた、ＧＥＴ要求を送信する前にコントローラが待機するべき最小時間を示す、（同じくアクセサリによって割り当てられた）「トランザクション持続時間」も含み得る。アクセサリは、１回の要求ごとに、応答選択肢を選択することができる。
【０１２８】
例示として、構成ポートを開く機能性を実施する、アクセサリを考察する。このポートは、様々な特性を有するサービスとしてモデル化することができる。図５Ｇは、コントローラが、ポートを開くことを要求するために真のブール値を書き込むことが可能な、特性インスタンス５７１を示す。図５Ｈは、本発明の実施形態による、ポートを開くことを要求するためにコントローラによって使用することが可能な、ＰＵＴ要求５７２を示す。（特性インスタンス５７１は、インスタンスＩＤ２２を有するサービスインスタンス内で定義されていることを理解されたい。）アクセサリは、例えば、コントローラ許可若しくはアクセサリの現在の状態に応じて、要求を満たすか又は拒絶することができる。アクセサリは、最初に要求に対して作動してから応答する（インライン結果）か、又は応答してから作動する（問い合わせ結果）かを選択することができる。
【０１２９】
アクセサリが、最初に要求に対して作動することを選択する場合には、そのアクセサリは、結果を示すインライン応答を送信することができる。例えば、要求を満たすことは、ソケットを作り出して、ポートのリッスンを開始することを含み得る。アクセサリは、構成されたポートについての情報を、そのＨＴＴＰ応答で伝えることができる。図５Ｉは、図５Ｈの要求５７２に対する、インラインＨＴＴＰ応答５７３の実施例を示す。コンテンツ５７４は、ポート識別子、及び要求に関する状態標識を含み得る。
【０１３０】
アクセサリが、最初に応答することを選択する場合には、そのアクセサリは、コントローラが後に結果に関して問い合わせるために使用することが可能な情報を含む、トランザクション応答を送信することができる。図５Ｊは、本発明の実施形態による、トランザクション応答５７５の実施例を示す。トランザクション応答５７５は、そのトランザクションを特定するためにアクセサリによって生成された、ＵＵＩＤ又は他の識別子とすることが可能なトランザクションＩＤ５７６と、トランザクション持続時間５７７（例えば、秒の単位）とを含む。応答５７５は、コントローラが５秒待機してから、応答を取得するためにアクセサリに問い合わせるべきであることを示す。その時間の間に、アクセサリは、アクションを実行して、トランザクションＩＤと共に結果を記憶することができる。
【０１３１】
トランザクション持続時間が経過した後、コントローラは、例えば、最初の要求と同じＵＲＬを使用して、ＨＴＴＰ  ＧＥＴ要求を送信することによってアクセサリに問い合わせることができる。図５Ｋは、本発明の実施形態による、トランザクション状態の問い合わせのために使用することが可能な、ＨＴＴＰ  ＧＥＴ要求５７８の実施例を示す。ＧＥＴ要求５７８は、トランザクション応答５７５からのトランザクションＩＤを含み得る。このトランザクションＩＤは、その問い合わせが、アクセサリが記憶することが可能であった、特定のトランザクションの結果に関するものであることを、そのアクセサリに示す。アクセサリは、そのトランザクションの結果を含むＨＴＴＰ応答で、応答することができ、この応答は、図５Ｉのインライン応答５７３と、同様又は同一のものとすることができる。
【０１３２】
リソースにアクセスする他の技術を実施することもできる。１つの代替的実装は、非階層的ＵＲＬを使用して、アクセサリの各サービスインスタンス及び特性インスタンスの、一意のインスタンスＩＤを活用することができ、これによりＨＴＴＰメッセージの長さを低減することができる。
【０１３３】
例えば、図６Ａは、アクセサリの特性及びサービスへのアクセスを可能にするように構築することが可能な、簡略化されたＵＲＬ６００を示す。ＵＲＬ６００は、プロトコル識別プレフィックス６０２（「ｈｔｔｐ：／／」）、ホスト名６０４（上述の図４の発見プロセスを通じて提供することが可能なもの）、及び、この実施例では「／ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ」である、ローカルＵＲＬ６０６を含む。ローカルＵＲＬ６０６は、アクセサリによってサポートされるＵＲＬのセットから、選択することができる。表４は、本発明の実施形態による、統一的アクセサリプロトコルが定義することが可能なＵＲＬを列挙する。
【表４】
2017511028.tif 000006
【０１３４】
この実施例では、コントローラは、図６Ａに示される方式で構築されたＵＲＬに、要求を送信することによってアクセサリ機能を呼び出すことができ、そのローカルＵＲＬは、呼び出される機能に基づいて、表４から選択される。／ｐａｉｒ−ｓｅｔｕｐ、／ｐａｉｒ−ｖｅｒｉｆｙ、及び／ｐａｉｒｉｎｇｓのＵＲＬは、コントローラとアクセサリとの間のペアリングの確立及び検証に関連して使用することができ、実施例が以下で説明される。ペアリング済みコントローラは、アクセサリの／ａｃｃｅｓｓｏｒｉｅｓのＵＲＬに、ＧＥＴ要求を送信することにより、そのアクセサリ定義レコードを取得することができる。／ａｃｃｅｓｓｏｒｉｅｓのＵＲＬは、アクセサリ特性の読み取り又は書き込みを伴う、全ての対話のために使用することができる。
【０１３５】
／ｉｄｅｎｔｉｆｙのＵＲＬにより、ペアリングされていないコントローラは、例えば、そのアクセサリが、いずれかのコントローラとペアリングを確立する前に、そのアクセサリの自己識別ルーチンを呼び出すことが可能となり得る。アクセサリが、いずれのコントローラともペアリングされていない場合には、そのアクセサリは、ＨＴＴＰ２０４「Ｎｏ  Ｃｏｎｔｅｎｔ」応答で応答して、自己識別ルーチンを呼び出すように進行することができる。アクセサリが、コントローラとペアリングを確立している場合には、そのアクセサリは、（例えば、ＨＴＴＰ４００「Ｂａｄ  Ｒｅｑｕｅｓｔ（不正な要求）」応答で）要求を拒絶することにより、そのＵＲＬが有効ではないことを示すことができる。一部の実施形態では、ペアリング済みコントローラは、図２Ｉ及び図３Ａに示されるようなアクセサリ識別サービス内に含めることが可能なＩｄｅｎｔｉｔｙ特性２７１に書き込むことによって、そのアクセサリの自己識別ルーチンを呼び出すことができる。
【０１３６】
図６Ｂは、図３Ａ〜図３Ｃのアクセサリオブジェクト３００によって定義されるアクセサリの特性を読み取るために、ＵＲＬ６００を使用して送信することが可能なＨＴＴＰ  ＧＥＴ要求６１０の実施例を示す。ＧＥＴ要求６１０は、ＵＲＬ６００のホスト６０４にアドレス指定され、ローカルＵＲＬ６０６を指定する。文字列６１２は、読み取られる特性インスタンス（単数又は複数）を指定する、ＵＲＬパラメータである。使用されるフォーマットは、＜アクセサリＩＩＤ＞．＜特性ＩＩＤ（単数又は複数）＞であり、＜アクセサリＩＩＤ＞は、アクセサリのインスタンス識別子であり、＜特性ＩＩＤ（単数又は複数）＞は、コンマで区切られた、読み取られる特性に関するインスタンス識別子のリストである。図３ＢのインスタンスＩＤを参照すると、ＧＥＴ要求６１０は、現在のドア状態及び目標のドア状態を読み取る要求として、理解することができる。様々な特性インスタンス識別子（例えば、ＵＲＬパラメータ「？１．８−１２」）などの、他のフォーマットを使用することもできる。この実施例では、アクセサリの各特性が、一意のインスタンス識別子に割り当てられるため、サービスインスタンス識別子を指定する必要はない。他の実施形態では、必要に応じて、サービスインスタンス識別子を含めることができる。
【０１３７】
図６Ｃは、ＧＥＴ要求６１０に応答して送信することが可能な、ＨＴＴＰ応答６２０の実施例を示す。応答６２０は、その応答及び状態（「２００  ＯＫ」）を特定し、コンテンツ６２４が、統一的アクセサリプロトコルに関するＪＳＯＮオブジェクトとしてフォーマットされていることを示す、ＨＴＴＰ応答ヘッダ６２２を含み得る。コンテンツ６２４は、要求された各特性インスタンスに関する状態情報（値）を含み得る。この実施例では、各特性に関して送信されるデータは、その値及びインスタンスＩＤのみを含む。アクセサリの各特性インスタンスが、一意のインスタンスＩＤを有する限り、この情報は、要求に応答するために十分である。
【０１３８】
この方式で、アクセサリの任意数の特性（異なるサービスインスタンスの特性を含めたもの）を、単一のＧＥＴ要求及び応答を使用して読み取ることができる。更には、コントローラが、複数のアクセサリオブジェクトをサービスするアクセサリサーバと通信している場合には、そのコントローラは、そのサーバ上の複数のアクセサリの特性を読み取るために、例えば、それらの特性を、コンマで区切られた＜アクセサリＩＩＤ＞．＜特性ＩＩＤ（単数又は複数）＞のリストとして指定することによって単一のＧＥＴ要求を送信することができる。例えば、ＵＲＬパラメータ（「？１．８．９，２．６，７」）は、インスタンスＩＤ１を有するアクセサリから、特性インスタンス８及び９を読み取り、インスタンスＩＤ２を有するアクセサリから、特性インスタンス６及び７を読み取る要求として、アクセサリサーバによって理解することができる。
【０１３９】
特性は、そのアクセサリの／ｃｈａｒａｃｔｅｒｉｓｔｉｃｓのＵＲＬに対するＨＴＴＰ  ＰＵＴ要求を使用して、書き込むことができる。図６Ｄは、アクセサリの任意数の特性に書き込むために使用することが可能な、ＰＵＴ要求６３０の実施例を示す。書き込まれる各特性に関して、コンテンツ６３４は、アクセサリインスタンスＩＤ、特性インスタンスＩＤ、及び新たな値を指定することができる。この実施例では、２つの特性が書き込まれるが、このアレイは、同じアクセサリサーバ上の異なるアクセサリの特性を含めた、任意数（１つ以上）の特性を含み得る。
【０１４０】
エラーが発生しない場合には、アクセサリは、空のＨＴＴＰ「２０４  Ｎｏ  Ｃｏｎｔｅｎｔ」応答で応答することができ、適切なアクションを開始する（例えば、ドアを移動させるために、ガレージドア開閉装置内のモータを起動させる）ことによって状態の更新を実施することができる。エラーが発生した場合には、アクセサリは、エラーメッセージで応答することができる。図６Ｅは、ＰＵＴ要求６３０に応答して送信することが可能な、エラーメッセージ６４０の実施例を示す。この実施例では、コンテンツ６４４は、書き込みが試みられた各特性インスタンスが特定されていることを（再度、アクセサリインスタンスＩＤ及び特性インスタンスＩＤを使用して）特定する。新たな値は示されていない。状態コード６４６、６４８は、いずれの書き込みが失敗したかを通信するために使用される。この実施例では、状態コード６４６（値０）は、インスタンスＩＤ８を有する特性に関しては、エラーが発生しなかったことを示す。状態コード６４８（値−１２３４５）は、インスタンスＩＤ９を有する特性に関して、エラーが発生したことを示す。この状態コード６４８の値は、エラーのタイプを示し得る。例えば、状態コードは、不十分な権限（例えば、コントローラが、特性に書き込むことを認可されない）、リソースにアクセスすることができないこと（例えば、アクセサリの電源がオフである）、リソースがビジーであること、要求がサポートされていないこと（例えば、読み取り専用特性に対する書き込みの試み）、値が無効であること（例えば、最小値及び最大値を有する特性に対して、範囲外）、及び他のエラー条件を示すように、必要に応じて定義することができる。
【０１４１】
図５Ａ〜図５Ｋ、及び図６Ａ〜図６Ｅの、これらのコマンド及び制御メッセージのフォーマット並びにシーケンスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。ＨＴＴＰにより、任意のリソースを、任意の時点で要求することが可能となり、したがって、コントローラは、任意の順序でＨＴＴＰ要求を送信することができ、アクセサリは、受信された順序で、ＨＴＴＰ要求に応答することができる。アクセサリは、標準ＨＴＴＰ応答（エラーメッセージを含むもの）で応答することができ、コントローラは、そのＨＴＴＰ応答を、肯定応答（又は、エラーの場合には、否定応答）メッセージとして取り扱うことができる。一部の実施形態では、アクセサリのサービス及び特性の、ＨＴＴＰリソースへの対応付けは、コントローラが情報を取得する方式における、実質的な柔軟性を可能にし得る。一部の実施形態では、より短いＵＲＬを有するインスタンス識別子の使用は、より短い要求及び応答をもたらし得るものであり、このことにより、帯域幅要件を低減することができる。
【０１４２】
更には、これらの実施形態は、ＨＴＴＰを使用するように示されているが、本発明は、いずれかの特定のフレーム化プロトコルに限定されるものではなく、他のプロトコルで置き換えることもできる。例えば、コントローラ及びアクセサリが、Ｂｌｕｅｔｏｏｔｈ  ＬＥを使用して通信する実施形態では、コントローラは、Ｂｌｕｅｔｏｏｔｈ  ＬＥ  ＧＡＴＴ層、並びに、各サービス及び特性に割り当てられたＵＵＩＤを活用することによって、特性に対する読み取り及び書き込みを行うことができる。
【０１４３】
上記の実施例では、コントローラは、例えばＨＴＴＰ要求を使用して、アクセサリにコマンド及び制御メッセージ（要求）を送信することによって、アクセサリ内の状態変化を開始させることができる。他の場合には、アクセサリの状態変化は、コントローラ以外のソースによって開始させることができ、このことが実施される場合、コントローラは、そのアクセサリに接続されている場合もあれば、接続されていない場合もある。例えば、異なるコントローラが、異なる時点で、同じアクセサリと対話している場合があり、又は、ユーザが、アクセサリを手動で（例えば、ガレージドア開閉装置を作動させるために、ガレージ内の開／閉ボタンを押して）動作させる場合もある。それゆえ、アクセサリ状態は、コントローラが認識することなく、変化する場合がある。したがって、統一的アクセサリプロトコルの一部の実装は、コントローラに状態変化を通知するメカニズムを提供することができる。複数の通知メカニズムを同時にサポートすることができ、コントローラは、いずれのメカニズムが好ましいかを、例えば、特性ごとに、又はサービスごとに決定することができる。
【０１４４】
通知メカニズムの実施例は、上記の表２内に列挙されている。一部の場合には、アクセサリは、アクセサリの状態が変化するたびにインクリメントさせることが可能な、内部状態カウンタを保持することができる。必要に応じて、単一の状態カウンタをアクセサリレベルで保持することができ、又は、異なるサービス又は特性に関して、異なる状態カウンタを保持することもできる。様々な実施形態は、以下で説明される通知メカニズムのうちのいずれか又は全てをサポートすることができる。
【０１４５】
図７は、本発明の実施形態による、「受動的」通知プロセス７００の実施例を示す。プロセス７００は、コントローラが、状態変化が生じたか否かを判定するために、アクセサリの内部状態カウンタを読み取ることを伴う。したがって、コントローラがアクセサリから接続解除されている間に変化が生じたという事実は、その後にコントローラが再接続する際、そのコントローラによって検出することができる。一部の実施形態では、受動的通知が、デフォルトで有効化されており（例えば、あらゆるアクセサリが、内部状態カウンタを保持する）、その通知を有効化するために、特定のアクション（例えば、加入すること）は必要とされない。
【０１４６】
ブロック７０６及び７０８で、コントローラ７０２及びアクセサリ７０４は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス４００、及び／又は以下で説明される他のプロセス（例えば、ペア検証）を実行することを含み得る。
【０１４７】
ブロック７１２で、アクセサリ７０４は、その現在の内部状態カウンタ値を、コントローラ７０２に提供することができ、コントローラ７０２は、ブロック７１４で、その値を取得して記憶することができる。一部の実施形態では、コントローラ７０２は、適切なリソース（例えば、アクセサリ情報サービス内で定義することが可能な、読み取り可能な状態カウンタ特性）に、ＨＴＴＰ  ＧＥＴ要求を送信することができる。ブロック７１２でのアクセサリ７０４による応答は、そのカウンタ値を含み得る。コントローラ７０２は、この値を記憶することができる。以降のいずれかの時点で、コントローラ７０２は、アクセサリ７０４から接続解除することができる（ブロック７１６）。
【０１４８】
ブロック７１８で、コントローラ７０２が接続解除された後に、アクセサリ７０４内で状態変化が生じ得る。それに応答してアクセサリ７０４は、ブロック７２０で、その状態カウンタを更新することができる。
【０１４９】
その後、コントローラ７０２は、アクセサリ７０４に再接続することができる（ブロック７２２）。ブロック７２４で、アクセサリ７０４は、現在の内部状態カウンタ値をコントローラ７０２に提供することができ、コントローラ７０２は、ブロック７２６で、その値を取得することができる。一部の実施形態では、このことは、適切なリソースに向けられた、コントローラ７０２によるＨＴＴＰ  ＧＥＴ要求を通じて行うことができ、アクセサリ７０４による応答は、そのカウンタ値を含み得る。ブロック７２８で、コントローラ７０２は、例えば、ブロック７２６で取得したカウンタ値と、以前にブロック７１４で取得して記憶したカウンタ値とを比較することによって、状態変化を検出することができる。一部の実施形態では、コントローラ７０２は、記憶された古いカウンタ値を、新たなカウンタ値で上書きすることができる。その後、ブロック７３０で、アクセサリ７０４は、更新された状態情報を、コントローラ７０２に提供することができ、コントローラ７０２は、ブロック７３２で、その情報を取得する。一部の実施形態では、このことは、コントローラ７０２によるＨＴＴＰ  ＧＥＴ要求、及びアクセサリ７０４による応答を使用して行うことができ、コントローラは、アクセサリ定義レコードを要求するか、又は、その状態変化がコントローラにとって対象のものとなる、特定の特性のみを要求するかを、選択することができる。
【０１５０】
図８は、本発明の実施形態による、「広告式」通知プロセス８００の実施例を示す。プロセス８００では、アクセサリは、（例えば、上述のような）デバイス発見サービスを使用して、状態変化が生じたことを広告することができる。この広告を検出するコントローラは、アクセサリに接続して、更新された状態情報を取得することができる。
【０１５１】
ブロック８０６及び８０８で、コントローラ８０２及びアクセサリ８０４は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス４００、及び／又は以下で説明されるペアリングプロセスを実行することを含み得る。ブロック８１０で、コントローラ８０２は、広告式通知への加入の要望を示すことができる。例えば、図２Ｅを参照して上述されたように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、その通知モードプロパティに書き込むことによって、通知モードを指定することができる。一部の実施形態では、アクセサリ８０４は、少なくとも１つのコントローラが広告式通知に加入していない限り、状態変化を広告せず、このことにより、ネットワークトラフィックを低減することができる。
【０１５２】
ブロック８１２で、アクセサリ８０４は、現在の内部状態カウンタ値を、コントローラ８０２に提供することができ、コントローラ８０２は、ブロック８１４で、その値を取得して記憶することができる。一部の実施形態では、このことは、適切なリソースに向けられた、コントローラ８０２によるＨＴＴＰ  ＧＥＴ要求を通じて行うことができ、アクセサリ８０４による応答は、そのカウンタ値を含み得る。コントローラ８０２は、この値を記憶することができる。以降のいずれかの時点で、コントローラ８０２は、アクセサリ８０４から接続解除することができる（ブロック８１６）。
【０１５３】
ブロック８１８で、コントローラ８０２が接続解除された後に、アクセサリ８０４内で状態変化が生じ得る。それに応答して、アクセサリ８０４は、ブロック８２０で、その内部状態カウンタを更新することができる。ブロック８２２で、アクセサリ８０４はまた、更新された状態カウンタも広告することができる。例えば、上記の表３に示されるように、アクセサリは、例えばＢｏｎｊｏｕｒ  ＴＸＴレコード内の、状態番号「ｓ＃」を含む情報などを広告することができる。アクセサリは、そのフィールドを更新して、新たなＴＸＴレコードを一斉配信することによって、状態変化を広告することができる。
【０１５４】
ブロック８２４で、コントローラ８０２が一斉配信をリッスンしていると想定すると、コントローラ８０２は、その変化を検出することができる。例えば、コントローラ８０２は、その一斉配信から、現在の状態カウンタを抽出して、その一斉配信された状態カウンタと、記憶されている状態カウンタとを比較し、そのアクセサリの状態が変化したことを示す不一致を検出することができる。ブロック８２６で、コントローラ８０２は、アクセサリ８０４に再接続することができ、ブロック８２８で、アクセサリ８０４は、更新された状態情報を、コントローラ８０２に提供することができ、コントローラ８０２は、ブロック８３０で、その情報を取得する。一部の実施形態では、このことは、コントローラ８０２によるＨＴＴＰ  ＧＥＴ要求、及びアクセサリ８０４による応答を通じて行うことができる。
【０１５５】
図９は、本発明の実施形態による、「能動的」通知プロセス９００の実施例を示す。プロセス９００では、アクセサリは、状態情報が更新されると、コントローラに警告するために、コントローラへの接続を開始することができる。例えば、コントローラは、デバイス発見サービス（例えば、Ｂｏｎｊｏｕｒサービス）に、状態更新の受信専用のサービスレコードを登録することができ、アクセサリは、そのコントローラのサービスレコードを使用して、コントローラへの接続を開始することができる。
【０１５６】
ブロック９０６及び９０８で、コントローラ９０２及びアクセサリ９０４は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス４００、及び／又は以下で説明されるペアリングプロセスを実行することを含み得る。ブロック９１０で、コントローラ９０２は、能動的通知への加入の要望を示すことができる。例えば、上述のように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、その通知モードプロパティに書き込むことによって、通知モードを指定することができる。一部の実施形態では、アクセサリ９０４は、少なくとも１つのコントローラが、能動的通知に加入している場合にのみ、能動的通知に関連する動作を実行し、このことにより、ネットワークトラフィックを低減することができる。
【０１５７】
ブロック９１２で、コントローラ９０２は、能動的通知をリッスンするポートを設定することができる。ブロック９１４で、コントローラ９０２は、デバイス発見サービスに、サービスレコードを登録することができる。例えば、Ｂｏｎｊｏｕｒサービスが使用される場合には、コントローラ９０２は、一意のＤＮＳ  ＳＲＶレコードを登録することができる。ＳＲＶレコードが一意である場合には、そのコントローラは、ＴＸＴレコードの探索、広告、又は提供などの動作を回避することにより、ネットワークトラフィックを低減することができる。一実施形態では、ＤＮＳ  ＳＲＶレコードは、以下のフォーマットを有し得る。
＜ＩＤ＞．＿ｇｕｉｄ．＿ｔｃｐ．ｌｏｃａｌ．＜ＴＴＬ＞ＩＮ  ＳＲＶ＜ｐｒｉｏｒｉｔｙ＞＜ｗｅｉｇｈｔ＞＜ｐｏｒｔ＞＜ｔａｒｇｅｔ＞、
【０１５８】
式中、＜ＩＤ＞は、コントローラに関する一意識別子（例えば、小文字でダッシュが除去されたＧＵＩＤ、ＵＵＩＤ、又は他の識別子）であり、「．＿ｇｕｉｄ．＿ｔｃｐ」は、ＤＮＳサービスタイプであり、「ｌｏｃａｌ」は、ドメイン名であり、＜ＴＴＬ＞は、ＳＲＶレコードの生存時間であり（例えば、１２０秒とすることができる）、＜ｐｒｉｏｒｉｔｙ＞は、目標ホストの優先度であり（例えば、そのサービス内で認識される、最も高い優先度とすることができる）、＜ｗｅｉｇｈｔ＞は、同じ優先度を有するレコードに関する相対的重みであり（例えば、０とすることができる）、＜ｐｏｒｔ＞は、コントローラ９０２上で動作している統一的アクセサリプロトコルサーバのＴＣＰポート番号であり（例えば、ブロック９１２で設定されるポート）、＜ｔａｒｇｅｔ＞は、統一的アクセサリプロトコルサーバに接続するためのＩＰアドレスを取得するために使用することが可能な、ＤＮＳ名である。
【０１５９】
ブロック９１６で、コントローラ９０２を接続解除することができる。
【０１６０】
ブロック９１８で、コントローラ９０２が接続解除された後に、アクセサリ９０４内で状態変化が生じ得る。それに応答して、ブロック９２０で、アクセサリ９０４は、例えば、サービスタイプ「．＿ｇｕｉｄ．＿ｔｃｐ」に関するマルチキャストＤＮＳ  ＳＲＶ問い合わせを送信することによって、デバイス発見サービスに、登録されたサービスの位置を特定するように問い合わせることができる。（一部の実施形態では、アクセサリ９０４は、少なくとも１つのコントローラが能動的通知に加入している場合にのみ、ブロック９２０での問い合わせ、及び後続のアクションを実行する。）ブロック９２２で、コントローラ９０４は、ブロック９１２及び９１４で確立された、ＤＮＳ名及びポート識別子で、その問い合わせに応答することができる。ブロック９２４で、アクセサリ９０４は、そのＤＮＳ名を解決するために、そのポートにユニキャスト問い合わせを送信することができる。一部の実施形態では、ＩＰｖ４及びＩＰｖ６アドレス指定バージョンの双方をサポートするアクセサリは、ＩＰｖ４及びＩＰｖ６アドレス指定の双方（例えば、ＩＰｖ４に関するＤＮＳ  Ａ問い合わせ、及びＩＰｖ６に関するＤＮＳ  ＡＡＡＡ問い合わせ）を使用して、問い合わせを送信することができ、アクセサリが、一方のＩＰアドレスバージョンのみをサポートする場合には、１つの問い合わせのみを送信することができる。
【０１６１】
ブロック９２６で、コントローラ９０２は、その解決されたアドレスを有する、ユニキャスト応答を送信することができる。アクセサリが、２つの問い合わせを送信した場合には、コントローラは、いずれのＩＰアドレスバージョン（単数又は複数）をサポートしているかに応じて、いずれか一方又は双方に応答することができる。
【０１６２】
ブロック９２８で、アクセサリ９０４は、解決されたアドレスを使用して、コントローラ９０２への新たな接続を開始することができる。一部の実施形態では、コントローラが、ＩＰｖ４アドレス及びＩＰｖ６アドレスの双方を提供する場合には、ＩＰｖ６を推奨することができる。ブロック９３０で、コントローラ９０２は、その接続を受理することができる。接続の試みが失敗した場合には、アクセサリは、再試行することができ、一部の実施形態では、再試行の頻度は、例えば６０秒ごとに１回までに、制限することができる。
【０１６３】
ブロック９３２で、アクセサリ９０４は、更新された状態情報を送信することができ、ブロック９３４で、コントローラ９０２は、その更新された状態情報を受信することができる。一部の実施形態では、更新された状態情報を送信する前に、以前に確立されたペアリングの検証（例えば、以下で説明されるペア検証プロセスを使用するもの）が必要とされる場合がある。この検証により、通知に加入した同じコントローラに、アクセサリが状態情報を報告しているという保証を提供することができる。
【０１６４】
図１０は、本発明の実施形態による、「イベント通知」プロセス１０００の実施例を示す。プロセス１０００では、アクセサリは、変化した特性に関するイベント通知を受信するように現在加入しているコントローラに、非請求のＨＴＴＰ応答（本明細書では、ＥＶＥＮＴメッセージとも称されるもの）を送信することができる。この実施例では、コントローラは、アクセサリに接続されている間の任意の時点で通知に加入することができ、そのアクセサリから接続解除すると自動的に未加入となる。
【０１６５】
ブロック１００６及び１００８で、コントローラ１００２及びアクセサリ１００４は、接続を確立することができる。様々な実施形態では、接続を確立することは、プロセス４００、及び／又は以下で説明される他のペアリングプロセスを実行することを含み得る。ブロック１０１０で、コントローラ１００２は、イベント通知への加入の要望を示すことができる。例えば、上述のように、各特性は、通知モードプロパティを有し得るものであり、コントローラは、このプロパティに書き込むことによって通知モードを指定することができる。
【０１６６】
図１１Ａは、特性に関するイベント通知に加入する、ＨＴＴＰ  ＰＵＴ要求１１１０の実施例を示す。コンテンツ１１０２は、特性を（アクセサリインスタンスＩＤ及び特性インスタンスＩＤによって）特定し、通知モードプロパティに関する値「ｅｖ」を含む。複数の特性を、単一の加入要求内に列挙することができ、一部の実施形態では、加入要求は、１つ以上の特性に値を書き込む要求と組み合わせることができる。アクセサリは、指定された特性に関するイベント通知に加入する要求として、要求１１００を理解することができ、確認（例えば、ＨＴＴＰ２０４「Ｎｏ  Ｃｏｎｔｅｎｔ」）又はエラー応答（例えば、その特性に関してイベント通知がサポートされていない場合）で、応答することができる。所望の通知方法（単数又は複数）を指定することによって、他のタイプのイベント通知（例えば、上述のような能動的通知又は広告式通知）に加入するために、同様のメッセージをコントローラによって使用することができる。
【０１６７】
加入した後、ブロック１０１４で、コントローラ１００２は、イベントベースの通知から加入解除することができる。一部の実施形態では、コントローラ１００２は、アクセサリ１００４から接続解除する場合には、自動的に加入解除される。加えて、又はその代わりに、コントローラ１００２は、アクセサリ１００４から接続解除することなく、通知モードプロパティに新たな値を書き込むことによって、明示的に加入解除することができる。コントローラ１００２が、（自動的又は明示的に）加入解除する場合には、いずれの後続のイベント通知も、もはやコントローラ１００２に送信されることはなく、プロセス１０００は、ブロック１０１６で終了することができる。（加入解除されたコントローラ１００２は、当然ながら、再び加入するためにプロセス１０００を実行することができる。）コントローラ１００２を自動的又は明示的に加入解除することにより、アクセサリ１００４は、対象としない（又は、接続されていない）コントローラへのイベントメッセージを、生成するか又は送信を試みることを回避することができるため、アクセサリ１００４による電力消費を低減するために役立ち得る。
【０１６８】
ブロック１０１８で、状態変化が、アクセサリ１００４内で生じる場合があり、ブロック１０２０で、アクセサリ１００４は、その内部状態カウンタを更新することができ、内部状態カウンタを更新することは、例えば上述のように、受動的通知及び／又は広告式通知に関連して有用であり得る。更には、コントローラ１００２が、イベントベースの通知に加入している場合には、アクセサリ１００４は、コントローラ１００２に対する通知を生成することができる。
【０１６９】
例えば、ブロック１０２４で、アクセサリ１００４は、その影響を受けた特性に対する状態変化に関するイベントベースの通知に、いずれかのコントローラ（例えば、コントローラ１００２）が現在加入しているか否かを判定することができる。
【０１７０】
コントローラが現在加入していない場合には、更なるアクションは実施されず、プロセス１０００は、ブロック１０２６で終了することができる。少なくとも１つのコントローラ（例えば、コントローラ１００２）が、現在加入している場合には、ブロック１０２８で、アクセサリ１００４は、更新された状態情報を含むイベントメッセージを生成することができる。
【０１７１】
図１１Ｂは、本発明の実施形態による、イベントメッセージ１１２０の実施例を示す。イベントメッセージ１１２０は、ＨＴＴＰ応答と同様の構造とすることができるが、しかしながら、ＨＴＴＰ応答とは異なり、イベントメッセージ１１２０は、特定のＨＴＴＰ要求に応答して送信されるものではない。ヘッダ部分１１２２は、メッセージ１１２０をイベントメッセージとして特定することができ、バージョン情報及び状態コードを含み得る。ボディ１１２２は、変化した特性の、更新された値を含み得るものであり、本明細書での他の実施例と同様に、その特性は、アクセサリ識別子及びインスタンス識別子によって特定することができる。複数の特性が変化した場合には、そのアクセサリは、単一のイベントメッセージ１１２０内に、複数の特性を含めることができ、すなわち、イベントメッセージを結合させることができる点を理解されたい。他のフォーマットもまた、使用することができる。
【０１７２】
再び図１０を参照すると、ブロック１０３０で、アクセサリ１００４は、コントローラ１００２にイベントメッセージを送信することができ、ブロック１０３２で、コントローラ１００２は、そのイベントメッセージを受信することができる。例えば、コントローラ１００２内のＨＴＴＰスタックを修正することにより、イベントメッセージ１１００を（例えば、ヘッダ１１２２に基づいて）認識することができる。コントローラ１００２は、受信したイベントメッセージから、更新された状態情報を抽出することができる。
【０１７３】
上述の様々な通知プロセスは、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。更には、同じアクセサリが、これらの通知プロセスのうちのいずれか又は全てを同時にサポートすることができ、同じ状態変化が、その状態変化の時点で、いずれの通知選択肢に様々なコントローラが加入しているかに応じて、内部状態カウンタの更新、更新された状態カウンタの広告、１つ以上の加入コントローラとの通信の開始、及び／又は加入コントローラへのイベントメッセージの送信のうちのいずれか又は全てを生じさせることができる。他の通知メカニズム及び通知プロセスを、図７〜図１０に示されるものに加えて、又はそれらの代わりにサポートすることができる。
【０１７４】
上述のように、コントローラは、例えば特性の通知モードプロパティに書き込むことによって、特性ごとに状態変化通知に加入することができる。アクセサリは、問題となる特性に関連して、いずれかのコントローラが各通知メカニズムに加入しているか否かに基づいて、いずれの通知メカニズム（単数又は複数）を実行するかを判定することができる。一部の実施形態では、受動的通知はデフォルトのメカニズムであり、内部状態カウンタは、いずれかのコントローラが具体的に何を要求しているかに関わりなく常に更新される。広告式通知、イベント通知、及び／又は能動的通知は、ネットワークトラフィックを作り出し得るため、これらのメカニズムの使用は、受動的通知に依存することが、ユーザエクスペリエンスに悪影響を及ぼすことになる場合に限定することができる。
【０１７５】
一部の実施形態では、状態変化の告知（例えば、広告式通知、イベント通知、及び／又は能動的通知を介したもの）によって生成されるネットワークトラフィックを低減するために様々なポリシーを課すことができる。例えば状態変化の広告は、少なくとも１つのコントローラが広告式通知に加入している場合に限定することができ、接続を開始するためにサービスレコードに問い合わせすることは、少なくとも１つのコントローラが能動的通知に加入している場合に限定することができる。更には、全ての広告式通知、能動的通知、又はイベント通知を最短遅延期間（例えば、１秒）で結合するように、アクセサリに要求することにより、ネットワークトラフィックを更に低減することができる。別の実施例として、広告、イベント通知、及び／又はアクセサリ開始接続の頻度を制限することができる（例えば、３０秒ごとに１回まで）。ネットワークトラフィックを最小限に抑える受動的通知を、デフォルトとして使用することができる。そのような制限は、設計選択の問題であり、必要に応じて変更又は除去することができる。制限が課され、アクセサリがその制限に違反する場合、違反を検出するコントローラは、その不正挙動をユーザに警告することができ、かつ／又は、そのアクセサリとのペアリングを終了することができる。
例示的なペアリングプロセス
【０１７６】
一部の実施形態では、アクセサリとコントローラとの間の通信のセキュリティを確保することが、有用であり得る。例えば、図１を参照すると、コントローラ１０２を使用して、例えば、上述のように要求メッセージを送信することによって、ドア１０４をロック解除するか、又はガレージ１０６を開放することができる。当業者には、そのような動作は、特定の認可済みコントローラに限定されるべきであることが理解されるであろう。
【０１７７】
したがって、本発明の一部の実施形態は、ペアリングの認証、及びエンドツーエンドの暗号化などの、セキュリティ対策を提供する。ペアリングの認証は、アクセサリとコントローラとの間でのペアリングの確立（ペア設定とも称されるもの）の一部として実施することができ、その間に、アクセサリ及びコントローラは、セキュリティフレームワークを（例えば、暗号化技術を使用して）確立することができ、そのフレームワーク内で、長期公開キーを交換することができる。一部の実施形態では、ペア設定は、情報（例えば、設定コード）の帯域外交換を組み込むことができ、この帯域外交換は、アクセサリに対して、特定のコントローラとペアリングするべきであることを検証するための、及び／又はコントローラに対して、特定のアクセサリとペアリングするべきであることを検証するための、ユーザ入力（又は、ユーザアクション）を組み込むことができる。この方式で、公開キーを交換した後、コントローラ及びアクセサリは、それらのキーを記憶して、その後、ペアリングが確立されたことを検証するために、それらのキーを使用することができる。エンドツーエンドの暗号化は、アクセサリ及びコントローラの双方内で、セッションキーを（例えば、ペアリングの検証後に）生成し、それらのセッションキーを使用して、各メッセージが送信デバイスから発せられる前に、そのメッセージを暗号化することを含み得ることにより、そのメッセージが傍受された場合にも、傍受者は、そのメッセージを利用することが不可能となる。それゆえ、リンク層又はトランスポート層で、通信ネットワークのセキュリティを確保することは必要とされない。例えば、アクセサリとコントローラとが、（例えば、以下で説明されるような、ペア検証プロセスを使用して）再接続するたびに、新たなセッションキーを生成することができる。更には、確立済みのペアリングを（例えば、記憶されている長期公開キーを除去することによって）する除去メカニズムを提供することができ、これにより、特定のアクセサリを制御することを一旦認可されたコントローラが無認可となる。
【０１７８】
一部の実施形態では、暗号キー（以下で説明されるキーのうちのいずれか又は全てを含めたもの）は、デバイスに関するデータを安全に記憶することが可能な、専用の集積回路チップなどの、「セキュア要素」（「セキュア記憶要素」とも称される）内にのみ、排他的に記憶させることができる。このセキュア要素を使用することにより、受信された長期公開キー、及び／又は、ペアリング関係が確立されている他のデバイスを特定する他の情報の、永続的で安全な記憶を提供することができる。このことは、攻撃者が、適切な設定プロセスを経ずにペアリングを追加する（コントローラの不正使用をもたらす恐れがある）こと、又は、無認可でペアリングを除去する（コントローラの正当な使用を妨げる恐れがある）ことを、防止するために役立ち得る。更には、一部の実施形態では、このセキュア要素はまた、アクセサリ又はコントローラのメインプロセッサに対するコプロセッサ（又は、「セキュアコンピューティング要素」）としての役割を、そのセキュア要素が果たすことを可能にする、論理回路も含み得る。このセキュア要素は、様々な入力及び命令を受信して、それらの入力に対する暗号化動作を実行することができる。このセキュア要素は、それらの動作を実行し、出力を提供することができる。本明細書で説明される暗号化動作のうちのいずれか又は全て（例えば、キーの生成、秘密キーでの署名、及びキーを伴う他の動作）は、セキュアコンピューティング要素に委譲することができる。本明細書で使用するとき、「セキュア要素」は、安全な記憶及び／又は安全なコンピューティングの任意の組み合わせを提供することができる。
【０１７９】
一部の実施形態では、ペアリングをサポートするアクセサリは、そのアクセサリモデルの一部として、ペアリングプロファイルを有し得る。本明細書で説明される他のサービスと同様に、このペアリングプロファイルは、特性の集合として定義することができる。一部の実施形態では、統一的アクセサリプロトコルは、全てのアクセサリがペアリングプロファイルを有するように、指定することができる。他の実施形態では、ペアリングプロファイルは、任意選択的な特徴とすることができるが、このプロトコルは、アクセサリがペアリングプロファイルを有する場合には、コントローラが、いずれかのコマンド及び制御メッセージを交換する前に、そのアクセサリとペアリングすることが必要となり得るように、指定することができる。更には、ペアリング要件の調整もまた可能である。例えば、アクセサリのペアリングプロファイルは、ペアリングを必要とする具体的なサービスインスタンスを特定することにより、そのアクセサリのサービスのうちの一部へのアクセスを、ペアリングなしで可能にすることができる。
【０１８０】
図１２は、本発明の実施形態による、ペアリングプロファイルに関する例示的特性１２０１〜１２０５を示す。このフォーマットは、全般的には図２Ａと同様である。本明細書で説明される他の特性と同様に、特性１２０１〜１２０５は、例えばＨＴＴＰ  ＧＥＴ要求などを使用して、コントローラによって読み取ることができ、例えばＨＴＴＰ  ＰＵＴ要求又はＨＴＴＰ  ＰＯＳＴ要求などを使用して、書き込みを（許可される場合に）実行することができる。
【０１８１】
Ｐａｉｒｉｎｇ  Ｓｔａｔｅ  Ｒｅｑｕｅｓｔ特性１２０１は、ペアリングプロセスの状態の変化を要求するために（例えば、以下で説明される、ペア設定、ペア検証、ペア追加、及び／又はペア除去プロセスの間に、様々な要求を送信するために）、コントローラによって書き込むことができる。一部の実施形態では、コントローラは、特性１２０１に書き込むことではなく、（例えば、上記の表４に示されるような）ペアリングＵＲＬにＨＴＴＰ  ＰＯＳＴ要求を送信することによって、ペアリングプロセスの状態の変化を要求することができる。ペアリングプロセスの状態及び要求の実施例は、具体的なペアリングプロセスに関連して以下で説明される。
【０１８２】
Ｆｅａｔｕｒｅ  Ｆｌａｇｓ特性１２０２は、アクセサリによってサポートされるペアリング特徴を定義する、ビットマスクとすることができる。例えば、以下で説明されるように、様々なアクセサリは、設定コードベースのペアリング（ペアリングを実施するべきであることを確認するために、ＰＩＮなどの設定コードを、ユーザが入力することを必要とし得るもの）、証明書ベースのペアリング（以下で説明されるような、一方又は双方のデバイス内の認証チップを使用して提供することが可能な証明書インフラストラクチャを使用し得るもの）、及び／又は委譲ペアリング（別のコントローラをペアリングするべきであることを、既にペアリングされているコントローラが検証することを可能にし得るもの）をサポートすることができる。一部の実施形態では、Ｆｅａｔｕｒｅ  Ｆｌａｇｓ特性１２０２はまた、アクセサリが現在、ペア設定を使用して新たなペアリングを確立することが可能なモードにあるか否かを示すビットも含み得る。特性１２０２は、コントローラによって読み取ることができるが、書き込むことはできず、コントローラは、ペア設定をどのように実行するか、及びペア設定を実行するべきか否かを判定する際に、その情報を使用することができる。
【０１８３】
Ｐａｉｒｉｎｇ  Ｃｕｒｒｅｎｔ  Ｓｔａｔｅ特性１２０３は、ペアリングプロセスの現在の状態、例えば、エラーが発生しているか否か、又は以下で説明される様々な他の状態を示すことができる。この特性は、コントローラによって読み取ることができるが、書き込むことはできない。
【０１８４】
Ｐａｉｒｉｎｇ  Ｌｉｓｔ特性１２０４は、そのアクセサリと確立された全てのペアリングのリストを、記憶することができる。例えば、公開キー（設定コードベースのペアリング用）、及び／又はペアリング済みコントローラの証明書（証明書ベースのペアリング用）、並びに、各コントローラがいずれの許可を有するかを示す、ＴＬＶ項目を、各ペアリングに関して生成することができる。これらのＴＬＶ項目は、サブＴＬＶ、単一の最上位ＴＬＶとして、（分離記号を使用して）一体にパック化することができる。一部の実施形態では、アクセサリは、最上位ＴＬＶを、要求側コントローラに送信する前に暗号化する。
【０１８５】
Ｐａｉｒｉｎｇ  ＩＤ特性１２０５は、ＭＡＣアドレス、アクセサリの公開キーの一部分、アクセサリの「ユーザ名」（例えば、以下で説明されるようなもの）などの、そのアクセサリに関するグローバル一意識別子とすることができる。
【０１８６】
一部の実施形態では、特性１２０１〜１２０５は、少なくとも、アクセサリが少なくとも１つのコントローラとペアリングを確立するような時間まで、ペアリングされていないコントローラに可視のアクセサリペアリングサービスインスタンスを定義することによって、コントローラに公開することができる。例えば、アクセサリが、通信トランスポートとしてＢｌｕｅｔｏｏｔｈ  ＬＥを使用する場合には、アクセサリは、Ｂｌｕｅｔｏｏｔｈ  ＬＥを介して、そのペアリングサービスを広告することができる。
【０１８７】
ペアリングサービスに加えて、又はその代わりに、アクセサリは、コントローラがペアリング機能性にアクセスするために参照することが可能な、１つ以上のＵＲＬを定義することができる。例えば、上記の表４を参照すると、コントローラは、ペア設定プロセスの間、要求を作成して関連情報を提供するために、ＨＴＴＰ  ＰＯＳＴ要求を、／ｐａｉｒ−ｓｅｔｕｐのＵＲＬに送信することができる。コントローラは、ペア検証プロセスの間、要求を作成して関連情報を提供するために、ＨＴＴＰ  ＰＯＳＴ要求を、／ｐａｉｒ−ｖｅｒｉｆｙのＵＲＬに送信することができる。コントローラは、ペアリングを管理するために、例えば、ペア追加プロセス及びペア除去プロセスを開始するために、あるいは、そのアクセサリに関する確立済みペアリングのリストを取得するために、ＨＴＴＰ  ＰＯＳＴ要求を、／ｐａｉｒｉｎｇｓのＵＲＬに送信することができ、このＰＯＳＴ要求は、具体的な要求を示すデータオブジェクトを含み得る。
【０１８８】
アクセサリとコントローラとの間にペアリングを確立するプロセス（「ペア設定」と称されるもの）の実施例を、ここで説明する。これらのプロセス又は他のプロセスのいずれも、例えば、図４のプロセス４００のブロック４２８及び４３０で実施することができる。したがって、以下では、アクセサリ及びコントローラは、既に発見を実行して、通信チャネルを開いていることが想定されるが、この通信チャネルはセキュリティが確保されていない場合がある。更に、ユーザは、コントローラが特定のアクセサリとペアリングするべきであることを、既にコントローラに確認していることが想定される。
【０１８９】
一部の実施形態では、ペア設定は、アクセサリがペアリングモードにある場合にのみ、許可される。アクセサリをペアリングモードにすることは、そのアクセサリとの、ユーザによる物理的接触を伴い得る。例えば、ユーザは、物理的対象物（例えば、キー）を、アクセサリ上の差込口内に挿入すること、アクセサリ上のスイッチを「ペアリング」位置に移動させることなどが、必要とされる場合がある。一部の実施形態では、ペア設定は、アクセサリが、いずれのコントローラともペアリングを確立していない場合にのみ、許可される。アクセサリが、１つのペアリングを確立した後は、更なるペアリングは、以下で説明されるような、ペア追加プロセス（又は、他の委譲ペアリングプロセス）を使用して確立することができる。
【０１９０】
図１３Ａ〜図１３Ｃは、本発明の実施形態による、コントローラ１３０２及びアクセサリ１３０４に関する、設定コードベースのペア設定プロセス１３００を示す。設定コードベースのペア設定では、ユーザは、双方向の認証を提供するために、アクセサリの設定コード（例えば、そのアクセサリに固有であり、容易に推測可能ではない、１０桁の識別番号とすることが可能なもの）を、コントローラで入力することが必要となり得る。セキュリティのために、アクセサリの設定コードは、アクセサリによってディスプレイ上に示すか、若しくはユーザによって手動で（例えば、アクセサリ上の物理ダイヤルを設定するか、又はキーパッドに数字を打ち込むことによって）アクセサリに提供することができ、又は、設定コードは、アクセサリの筐体又はパッケージング上の、若しくはそれらの内部の、いずれかの場所に（例えば、目立たない表面上のラベルに）印刷することができる。アクセサリ製造元は、公的にアクセス可能な情報（例えば、シリアル番号、ＭＡＣアドレス、製造元名、製造日など）からは設定コードを導出しないことによって、セキュリティを強化することができる。本明細書での実施例では、ペア設定は、Ｓｅｃｕｒｅ  Ｒｅｍｏｔｅ  Ｐａｓｓｗｏｒｄ（「ＳＲＰ」）プロトコル（ｈｔｔｐ：／／ｓｒｐ．ｓｔａｎｄｆｏｒｄ．ｅｄｕに文書化）を活用するが、しかしながら、他のプロトコルを使用することもできる。
【０１９１】
最初に図１３Ａを参照すると、ブロック１３０６で、コントローラ１３０２は、関連するユーザ名（「ｕｓｅｒＣ」）を検索することができる。このユーザ名は、コントローラを互いに区別することを助けるために、アクセサリによって使用することが可能な、コントローラ１３０２及び／又はコントローラ１３０２の認可ユーザの、任意の識別子を含み得る。ブロック１３０８で、コントローラ１３０２は、例えば、適切なＵＲＬへのＨＴＴＰ  ＰＯＳＴ要求として、ペア設定開始要求を送信することができる。このペア設定開始要求は、そのペア設定開始要求が送信されたことを示す状態標識（一部の実施形態では、この状態標識及び後続の状態標識は、コントローラによって、図１２のＰａｉｒｉｎｇ  Ｓｔａｔｅ  Ｒｅｑｕｅｓｔ特性１２０１に書き込むことができる）と、設定コードベースのペアリング方法が使用されていることを示す方法標識と、コントローラのユーザネームｕｓｅｒＣとを含み得る。
【０１９２】
ブロック１３１０で、アクセサリ１３０４は、このペア設定開始要求をスロットリングするか否かを判定することができる。例えば、ランダムな推測に基づく攻撃を阻むために、アクセサリ１３０４は、次の開始要求を待機する時間が、ペア設定の試みが失敗するたびに倍増される、指数的スロットリングを実施することができる（例えば、最後のｎの試みが失敗した場合には、（ｎ＋１）番目の試みは、少なくとも２n-1秒待機しなければならない）。このスロットリングは、セッションごとに、又は接続ごとに適用されるのではなく、包括的に適用することができる。スロットリング時間は、ペア設定の試みが成功した後に、リセットすることができる。したがって、ブロック１３１０で、スロットリングが実施されており、最後の試みからスロットリング時間が経過していない場合には、アクセサリ１３０４は、ブロック１３１２でスロットリングメッセージを送信することができる。このスロットリングメッセージは、コントローラが、再試行する前に待機する必要がある時間の長さを示すことができる。ブロック１３１４で、スロットリングメッセージが受信された場合には、コントローラ１３０２は、（適切な時間、待機した後に）再試行するか否かを、判定することができる。コントローラ１３０２が、再試行することを判定した場合には、プロセス１３００は、ブロック１３０８に戻り、適切な待機時間の後に、新たなペア設定開始要求を送信することができる。
【０１９３】
ブロック１３１０で、アクセサリ１３０４が、要求をスロットリングしない場合には、プロセス１３００は、ブロック１３１６に進行することができ、このブロック１３１６で、アクセサリ１３０４は、例えばＳＲＰ＿ｎｅｗ（ＳＲＰ６ａ＿ｓｅｒｖｅｒ＿ｍｅｔｈｏｄ（））などの適切なＳＲＰプロトコル機能を呼び出すことによって、ＳＲＰセッションを作り出すことができ、コントローラのユーザ名を、受信した値ｕｓｅｒＣに（ＳＲＰ＿ｓｅｔ＿ｕｓｅｒｎａｍｅ又はＳＲＰ＿ｓｅｔ＿ｕｓｅｒ＿ｒａｗで）設定することができ、ＳＲＰ＿ｓｅｔ＿ｐａｒａｍｓで設定することが可能な、ランダムなソルト（例えば、少なくとも１６バイト）を生成することができ、それ自体の設定コードを（例えば、ＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ又はＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ＿ｒａｗを使用して）選択及び設定することができ、公開キー（「ｐｋＡ」）を（例えば、ＳＲＰ＿ｇｅｎ＿ｐｕｂを使用して）生成することができる。公開キーｐｋＡは、プロセス１３００の持続時間にわたって使用され、次いで破棄される、（秘密キー「ｓｋＡ」を伴う）短期キーペアの一部とすることができる。
【０１９４】
アクセサリは、様々な技術を使用して、設定コードを選択することができる。例えば、設定コードは、ＥＥＰＲＯＭ内にプログラムする（及び、アクセサリ上に、若しくはユーザが見つけることが可能なラベル上などに印刷する）ことができる。あるいは、プロセス１３００に先立って（又は、その間に）、ユーザが、アクセサリ上若しくはアクセサリ内に提供された、機械的又は電子的入力デバイスを使用することによって、ユーザ選択設定コードを、そのアクセサリ内に入力することができる。更に別の選択肢として、アクセサリは、そのアクセサリが、ユーザに設定コードを（例えば、その設定コードをユーザに表示するか又は他の方式で信号を送ることによって）通知する能力を有するのであれば、ペア設定プロセス１３００を実行する各インスタンスの間に、ランダムな設定コードを生成することができる。他の技術もまた、使用することができる。
【０１９５】
ブロック１３１８で、アクセサリ１３０４は、ランダムなソルト及び公開キーｐｋＡを、コントローラ１３０２に送信することができ、コントローラ１３０２は、ブロック１３２０で、それらを受信することができる。ランダムなソルト及び公開キーｐｋＡを、ブロック１３１８で送信すると、アクセサリ１３０４は、そのアクセサリの公開キーが送信されたことを示すように、ペアリング状態を更新することができる。
【０１９６】
ブロック１３２２で、コントローラ１３０２は、ユーザから、アクセサリの設定コードを取得することができる。例えば、コントローラ１３０２は、アクセサリの設定コードを入力することをユーザに促す、ユーザインタフェース画面を提示することができる。設定コードが、帯域外で、すなわち、ペア設定プロセスを実行するために使用されている通信チャネルとは独立した通信チャネルを介して、コントローラ１３０２に配信される限り、他の技術を使用することもできる。例えば、一部の実施形態では、ユーザは、コントローラ１３０２の搭載カメラを動作させることにより、設定コードがアクセサリ上に出現する際に、その設定コードの画像をキャプチャすることができ（この画像は、人間に読み取り可能な表現、又は、バーコード若しくはクイックレスポンス（ＱＲ）コードなどの機械読み取り可能な表現を含み得る）、コントローラ１３０２は、その設定コードを抽出するために画像処理を実行することができる。アクセサリ１３０４からコントローラ１３０２に設定コードを提供するために使用可能な技術の、他の実施例としては、コントローラ１３０２がアクセサリ１３０４に物理的に近接して配置又は保持されている間の、アクセサリ１３０４からコントローラ１３０２への近距離通信（ＮＦＣ）伝送、コントローラ１３０２によって検出可能なアクセサリ１３０４による音波又は超音波伝送、高速光信号伝達（例えば、コントローラ１３０２のカメラ又は光検出器の視野内での、アクセサリ１３０４によって発生される光パルスのシーケンス）、あるいは、アクセサリ１３０４、又は設定コードを記憶する関連デバイスの、コントローラ１３０２のコネクタインタフェースへの物理的接続が挙げられる。
【０１９７】
ブロック１３２４で、コントローラ１３０２は、例えば、ＳＲＰ＿ｎｅｗ（ＳＲＰ６ａ＿ｓｅｒｖｅｒ＿ｍｅｔｈｏｄ（））などの適切なＳＲＰプロトコル機能を呼び出すことによってＳＲＰセッションを作り出すことができ、コントローラのユーザ名を、（ＳＲＰ＿ｓｅｔ＿ｕｓｅｒｎａｍｅ又はＳＲＰ＿ｓｅｔ＿ｕｓｅｒ＿ｒａｗで）設定することができ、アクセサリから受信したソルトを（ＳＲＰ＿ｓｅｔ＿ｐａｒａｍｓで）設定することができ、それ自体の公開キー（「ｐｋＣ」）を（例えば、ＳＲＰ＿ｇｅｎ＿ｐｕｂを使用して）生成することができ、ユーザ入力設定コードを使用して、ＳＲＰパスワードを（例えば、ＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ又はＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ＿ｒａｗを使用して）設定することができ、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を（例えば、ＳＲＰ＿ｃｏｍｐｕｔｅ＿ｋｅｙを使用して）計算することができる。アクセサリ公開キーｐｋＡと同様に、公開キーｐｋＣは、プロセス１３００の持続時間にわたって使用され、次いで破棄される、（秘密キー「ｓｋＣ」を伴う）短期キーペアの一部とすることができる。
【０１９８】
ブロック１３２６で、コントローラ１３０２は、それ自体のアイデンティティを証明するために、コントローラ証明（「ｐｒｏｏｆＣ」）を（例えば、ＳＲＰ＿ｒｅｓｐｏｎｄを使用して）生成することができる。ブロック１３２８で、コントローラ１３０２は、公開キーｐｋＣ及び証明ｐｒｏｏｆＣを含む検証要求を、例えば、適切なＵＲＬへのＨＴＴＰ  ＰＯＳＴ要求として、アクセサリに送信することができる。この要求をブロック１３２８で送信すると、コントローラ１３０２は、そのコントローラの証明が送信されたことを示すように、ペアリング状態を更新することができる。
【０１９９】
ブロック１３３０で、アクセサリ１３０４は、コントローラ証明ｐｒｏｏｆＣを検証することができる。例えば、アクセサリ１３０４は、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を（例えば、ＳＲＰ＿ｃｏｍｐｕｔｅ＿ｋｅｙを使用して）計算することができ、その共有シークレットを使用して、ｐｒｏｏｆＣを（例えば、ＳＲＰ＿ｖｅｒｉｆｙを使用して）検証することができる。
【０２００】
図１３Ｂに示すように、ブロック１３３２で、ブロック１３３０での検証が失敗した場合には、ブロック１３３４で、アクセサリ１３０４は、コントローラ１３０２にエラーメッセージを送信することができる。ブロック１３３６で、そのエラーメッセージをコントローラ１３０２が受信した場合には、プロセス１３００は、ブロック１３３８で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
【０２０１】
ブロック１３３２で、検証が成功した場合には、ブロック１３４０で、アクセサリ１３０４は、それ自体のアイデンティティを証明するために、アクセサリ証明（「ｐｒｏｏｆＡ」）を（例えば、ＳＲＰ＿ｒｅｓｐｏｎｄを使用して）生成することができる。ブロック１３４２で、アクセサリ１３０４は、アクセサリ証明ｐｒｏｏｆＡを、コントローラ１３０２に送信することができ、コントローラ１３０２は、ブロック１３４４で、ｐｒｏｏｆＡを受信することができる。ｐｒｏｏｆＡをブロック１３４２で送信すると、アクセサリ１３０４は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
【０２０２】
ブロック１３４６で、コントローラ１３０２は、ｐｒｏｏｆＡを（例えば、ＳＲＰ＿ｖｅｒｉｆｙを使用して）検証することができる。ブロック１３４８で、検証が失敗した場合には、プロセス１３００を終了することができる（ブロック１３５０）。検証がブロック１３４８で成功した場合には、現時点で、そのアクセサリ及びコントローラはそれぞれ、認証された共有シークレットを保有している。
【０２０３】
したがって、ブロック１３５２で、コントローラ１３０２は、その共有シークレットｉｎｐｕｔＫｅｙから、新たな暗号キー（「Ｋｅｙ」）を生成することができる。例えば、コントローラ１３０２は、ｉｎｐｕｔＫｅｙ、ランダムなソルト、及び追加的情報項目（コントローラ１３０２内に予めプログラム可能なもの）を入力として使用して、５１２ビットハッシュ用のＳｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍバージョン２を実装するＨＭＡＣベースのキー導出関数（ＩＥＴＦ  ＲＦＣ  ２１０４で定義される、ＨＭＡＣ−ＳＨＡ−５１２）を使用することができる。ブロック１３５４で、コントローラ１３０２は、Ｋｅｙを使用して、その長期公開キー（ＬＴＰＫＣ）を暗号化することができる。この長期公開キーは、コントローラ上に（例えば、上述のようなセキュア要素内に）永続的に記憶されるキーとすることができ、プロセス１３００でそれ以前に生成された短期公開キーｐｋＣとは無関係である。この暗号化は、キーとしてＫｅｙを使用し、メッセージとしてＬＴＰＫＣを使用し、及びノンスを使用して、ＣｈａＣｈａ２０−Ｐｏｌｙ１３０５（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ａｇｌ−ｔｌｓ−ｃｈａｃｈａ２０ｐｏｌｙ１３０５−０３で入手可能な、ＩＥＴＦインターネットドラフトｄｒａｆｔ−ａｇｌ−ｔｌｓ−ｃｈａｃｈａ２０ｐｏｌｙ１３０５−０３で説明されるもの）などの暗号化及び認証アルゴリズムを使用することにより、暗号化データｅｄａｔａＣ及び認証タグａｕｔｈＴａｇＣを作り出すことができる。
【０２０４】
ブロック１３５６で、コントローラ１３０４は、アクセサリ１３０４に、ｅｄａｔａＣ及びａｕｔｈＴａｇＣを送信することができ、コントローラ１３０２はまた、ＬＴＰＫＣがアクセサリに送信されたことを示すように、ペアリング状態を更新することもできる。
【０２０５】
ブロック１３５８で、ｅｄａｔａＣ及びａｕｔｈＴａｇＣを受信すると、アクセサリ１３０２は、コントローラ１３０２がブロック１３５２で使用したものと同じ方法を使用して、暗号キー（「Ｋｅｙ」）を生成することができる。この時点まで全てが正常に進行している場合には、その暗号キーは同じＫｅｙであるはずである。ブロック１３６０で、アクセサリ１３０２は、受信したａｕｔｈＴａｇＣを検証することができる。
【０２０６】
図１３Ｃに示すように、ブロック１３６２で、ブロック１３６０での検証が失敗した場合には、ブロック１３６４で、アクセサリ１３０４は、コントローラ１３０２にエラーメッセージを送信することができる。ブロック１３６６で、そのエラーメッセージをコントローラ１３０２が受信した場合には、プロセス１３００は、ブロック１３６８で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
【０２０７】
ブロック１３６２が成功をもたらした場合には、ブロック１３７０で、アクセサリ１３０４は、ＬＴＰＫＣを復号することができ、ブロック１３７２で、アクセサリ１３０４は、ＬＴＰＫＣ、及びコントローラのユーザ名ｕｓｅｒＣを、ペアリング済みコントローラのレコードとして、永続的に記憶することができる。そのような記憶は、上述のようなセキュア要素内に存在させることができる。
【０２０８】
ブロック１３７４で、アクセサリ１３０４は、そのアクセサリの長期公開キー（ＬＴＰＫＡ）と、そのアクセサリに関連付けられたユーザ名とを含む、データオブジェクトを構築することができる。このアクセサリの長期公開キーは、（例えば、アクセサリ１３０４のセキュア要素内に）永続的に記憶されるキーとすることができ、プロセス１３００でそれ以前に生成された短期公開キーｐｋＡとは無関係である。コントローラのユーザ名ｕｓｅｒＣと同様に、アクセサリのユーザ名ｕｓｅｒＡは、アクセサリを互いに区別することを助けるために、コントローラによって使用することが可能な、アクセサリ１３０４又はアクセサリ１３０４の認可ユーザの、任意の識別子を含み得る。ブロック１３７６で、アクセサリ１３０４は、ブロック１３７４で生成されたデータオブジェクトを暗号化することにより、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを生成することができる。ブロック１３５４でコントローラ１３０２によって使用されたものと同じ暗号化アルゴリズムを、使用するができる。ブロック１３７８で、アクセサリ１３０４は、コントローラ１３０２に、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを送信することができ、アクセサリ１３０４はまた、ＬＴＰＫＡがコントローラに送信されたことを示すように、ペアリング状態を更新することもできる。
【０２０９】
ブロック１３８０で、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを受信すると、コントローラ１３０２は、受信したａｕｔｈＴａｇＡを検証することができる。
【０２１０】
ブロック１３８２で、ブロック１３８０での検証が失敗した場合には、ブロック１３８４で、プロセス１３００は終了することができ、コントローラ１３０４は、ユーザにエラーを報告することができる。検証が成功した場合には、ブロック１３８６で、コントローラ１３０４は、ＬＴＰＫＡを復号して、ＬＴＰＫＡ、及びアクセサリのユーザ名ｕｓｅｒＡを、ペアリング済みアクセサリのレコードとして、永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。ブロック１３８８で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
【０２１１】
プロセス１３００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１３００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、ＳＲＰ並びに具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための他のプロトコル及びアルゴリズムで置き換えることもできる。
【０２１２】
一部の実施形態では、ペアリングプロセスは、認証インフラストラクチャを活用することができる。例えば、認証チップ（集積回路デバイス、すなわちＩＣ）を、アクセサリ及び／又はコントローラデバイス内に組み込むことができる。この認証チップは、デバイスに関する暗号キー、そのデバイスに関するセキュリティ証明書、及び、他のデバイスによって提示することが可能な有効若しくは無効なセキュリティ証明書についての情報を、安全に記憶することができる。一部の実施形態では、この認証チップは上述のセキュア要素（又は、その一部分）を実装することができる。所定のアクセサリが認証チップを含む場合には、その認証チップをペア設定プロセスで使用することができる。
【０２１３】
図１４Ａ〜図１４Ｃは、本発明の実施形態による、認証チップを使用する、コントローラ１４０２及びアクセサリ１４０４に関するペア設定プロセス１４００の実施例を示す。コントローラ１４０２は、プロセス１４００を開始する前に、アクセサリ１４０４が認証チップを有することを確認していることが想定される。例えば、上述のＦｅａｔｕｒｅ  Ｆｌａｇｓ特性１２０２は、証明書ベースのペアリングをアクセサリがサポートするか否かを示すフラグを含み得る。このフラグは、認証チップを有するアクセサリに対して設定することができる。別の実施例として、アクセサリが証明書ベースのペアリングをサポートするか否かを示すフラグを、そのアクセサリに関するサービス発見レコードの特徴フラグのフィールド（例えば、表３でのＢｏｎｊｏｕｒ  ＴＸＴレコードの特徴フラグ「ｆｆ」フィールド）内に含めることができ、このことにより、そのフラグを、ペアリングされていないコントローラに、より容易にアクセス可能にさせることができる。（認証チップが欠如しているアクセサリが、それにもかかわらず、このフラグを設定する場合には、コントローラは、プロセス１４００を実行する通常の過程で、認証チップが存在しないことを検出し、エラーを報告することができる）。
【０２１４】
図１４Ａを参照すると、ブロック１４０６で、コントローラ１４０２は、例えば、楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎキー共有プロトコルに基づく、Ｃｕｒｖｅ２５５１９アルゴリズム（ｈｔｔｐ：／／ｃｒ．ｙｐ．ｔｏ／ｅｃｄｈ．ｈｔｍｌで文書化）を使用して、公開／秘密キーペア（ｐｋＣ、ｓｋＣ）を生成することができる。このキーペアは、プロセス１４００の持続時間にわたって使用され、次いで破棄される短期キーペアとすることができる。ブロック１４０８で、コントローラ１４０２は、アクセサリ１４０４に、例えば適切なＵＲＬへのＨＴＴＰ  ＰＯＳＴ要求として、ペア設定開始要求を送信することができ、この要求は公開キーｐｋＣを含み得る。このペア設定開始要求は、そのペア設定開始要求が送信されたことを示す状態標識を含み得る（一部の実施形態では、この状態標識及び後続の状態標識は、図１２のペアリング制御点特性１２０１に書き込むことができる）。
【０２１５】
ブロック１４１０で、このペア設定開始要求に応答して、アクセサリ１４０４は、例えばＣｕｒｖｅ２５５１９アルゴリズムを使用して、公開／秘密キーペア（ｐｋＡ、ｓｋＡ）を生成することができる。（ｐｋＣ、ｓｋＣ）と同様に、このキーペアは、プロセス１４００の持続時間にわたって使用され、次いで破棄される、短期キーペアとすることができる。図示されていないが、プロセス１３００に関連して上述されたスロットリング挙動を組み込むことができ、アクセサリ１４０４は、ペア設定開始要求が、失敗した試みの後、過度に早い時点で受信された場合には、その要求を拒否することができる。
【０２１６】
ブロック１４１２で、アクセサリ１４０４は、ｓｋＡ及びｐｋＣを使用して、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を生成することができる。ブロック１４１４で、アクセサリ１４０４は、公開キーｐｋＡとｐｋＣとを連結することによって、メッセージを構築することができ、ブロック１４１６で、アクセサリ１４０４は、その認証チップを使用してメッセージに署名することにより、メッセージ「ｓｍｓｇ」を生成することができる。認証チップは、それ自体の（ｐｋＡ及びｓｋＡとは無関係な）永続的なキーペアを有し得るものであり、ＳＨＡ−１又はＳＨＡ−２（連邦情報処理規格刊行物１８０−４で文書化されている、米国国家安全保障局によって設計された、暗号ハッシュ関数）などの任意の所望のアルゴリズムを実行することができる。
【０２１７】
ブロック１４１８で、アクセサリ１４０４は、対称キー（「Ｋｅｙ」）を生成することができる。例えば、アクセサリ１４０４は、ｉｎｐｕｔＫｅｙ、ソルト（例えば、既定の文字列）、及び追加的情報を入力として使用してＨＭＡＣ−ＳＨＡ−５１２を使用することができる。
【０２１８】
ブロック１４２０で、アクセサリ１４０４は、ブロック１４１８で生成されたキーＫｅｙを使用して、ブロック１４１６からの署名付きメッセージｓｍｓｇを暗号化することにより、証明「ｐｒｏｏｆＡ」を生成することができる。任意の対称暗号化アルゴリズムを使用することができる。
【０２１９】
ブロック１４２２で、アクセサリ１４０４は、コントローラ１４０２に応答を送信することができる。この応答は、公開キーｐｋＡ、アクセサリ証明ｐｒｏｏｆＡ、及び認証チップによって提供されるアクセサリ証明書を含み得る。この応答をブロック１４２２で送信すると、アクセサリ１４０４は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
【０２２０】
ブロック１４２４で、コントローラ１４０２は、そのアクセサリ証明書を検証することができる。例えば、コントローラ１４０２は、有効なアクセサリ証明書を特定する情報を記憶する、それ自体の認証チップ又は他のセキュアデータストアを有し得るものであり、その情報は、信頼される認証局によってコントローラ１４０２に提供され、一部の場合には、信頼される認証局によって更新することもできる。コントローラ１４０２は、この情報を使用して、受信したアクセサリ証明書が有効であることを確認することができる。一部の実施形態では、特定の証明書は、特定のクラスのアクセサリに関してのみ有効とすることができ、コントローラ１４０２は、アクセサリから以前に受信した情報（例えば、アクセサリ定義レコード、又は上述のようなデバイス発見の間に提供された他の情報）を使用して、そのアクセサリのクラス、及び、受信したアクセサリ証明書が、そのアクセサリのクラスに関して有効であるか否かを判定することができる。
【０２２１】
図１４Ｂを参照すると、ブロック１４２６で、アクセサリ証明書が有効ではない場合には、プロセス１４００は終了することができ（ブロック１４２８）、コントローラ１４０２は、ユーザにエラーを通知することができる。アクセサリ証明書が有効である場合には、ブロック１４３０で、コントローラ１４０２は、ｓｋＣ及びｐｋＡを使用して、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を生成することができる。ブロック１４３２で、コントローラ１４０２は、対称キー（「Ｋｅｙ」）を生成することができる。例えば、アクセサリ１４０４は、ｉｎｐｕｔＫｅｙ、ソルト（例えば、既定の文字列）、及び追加的情報を入力として使用して、ＨＭＡＣ−ＳＨＡ−５１２を使用することができる。ブロック１４３４で、コントローラ１４０４は、対称キーＫｅｙを使用することにより、ｐｒｏｏｆＡを暗号化するためにアクセサリ１４０４によって使用されたものと同じアルゴリズムを使用して、アクセサリから受信したｐｒｏｏｆＡを復号することができる。それゆえ、コントローラ１４０２は署名付きメッセージｓｍｓｇを取得する。ブロック１４３６で、コントローラ１４０２は、アクセサリ証明書を使用して、そのｓｍｓｇ上の署名を検証することができる。ブロック１４３８で、その署名が有効ではない場合には、プロセス１４００は終了することができ（ブロック１４４０）、コントローラ１４０２はユーザにエラーを通知することができる。
【０２２２】
図１４Ｃを参照すると、署名が有効である場合には、ブロック１４４２で、コントローラ１４０２は、コントローラのユーザ名「ｕｓｅｒＣ」及びコントローラの長期公開キーＬＴＰＫＣを有する、データオブジェクトを構築することができる（これは、上述のプロセス１３００の場合と同じものであり得る）。ブロック１４４４で、コントローラ１４０２は、そのデータオブジェクトを暗号化することにより、ｅｄａｔａＣ及びａｕｔｈＴａｇＣを生成することができる。ブロック１４４２での暗号化は、上述のプロセス１３００と同様に、キーとしてＫｅｙを使用し、メッセージとしてＬＴＰＫＣを使用し、及びノンスを使用して、ＣｈａＣｈａ２０−Ｐｏｌｙ１３０５などの暗号化及び認証アルゴリズムを使用することができる。ブロック１４４６で、コントローラ１４０２は、アクセサリ１４０４にｅｄａｔａＣ及びａｕｔｈＴａｇＣを含む、交換要求メッセージを送信することができ、コントローラ１４０２はまた、ＬＴＰＫＣがアクセサリに送信されたことを示すように、ペアリング状態を更新することもできる。
【０２２３】
ブロック１４４８で、アクセサリ１４０４は、その対称キーＫｅｙを使用して、受信したａｕｔｈＴａｇＣを検証することができる。ブロック１４５０で、ブロック１４４８での検証が失敗した場合には、ブロック１４５２で、アクセサリ１４０４はコントローラ１４０２にエラーメッセージを送信することができる。ブロック１４５４で、そのエラーメッセージをコントローラ１４０２が受信した場合には、プロセス１４００は、ブロック１４５６で終了することができる。一部の実施形態では、このコントローラは、ユーザにエラーを報告することができる。
【０２２４】
ブロック１４５０が成功をもたらした場合には、ブロック１４５８で、アクセサリ１４０４は、ＬＴＰＫＣを復号することができ、ブロック１４６０で、アクセサリ１３０４は、ＬＴＰＫＣ、及びコントローラのユーザ名ｕｓｅｒＣを、ペアリング済みコントローラのレコードとして永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。
【０２２５】
ブロック１４６２で、アクセサリ１４０４は、双方とも上述のプロセス１３００の場合と同じものであり得る、そのアクセサリの長期公開キー（ＬＴＰＫＡ）と、そのアクセサリに関連付けられたユーザ名（ｕｓｅｒＡ）とを含む、データオブジェクトを構築することができる。アクセサリの長期公開／秘密キーペアは、そのアクセサリの認証チップ内のキーペアとは異なるものとすることができる。ブロック１４６４で、アクセサリ１４０４は、ブロック１４６２で生成されたデータオブジェクトを暗号化することにより、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを生成することができる。ブロック１４４４でコントローラ１４０２によって使用されたものと同じ暗号化アルゴリズムを、使用するができる。ブロック１４６６で、アクセサリ１３０４は、コントローラ１４０２に、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを送信することができ、アクセサリ１４０４はまた、ＬＴＰＫＡがコントローラに送信されたことを示すように、ペアリング状態を更新することもできる。
【０２２６】
ブロック１４６８で、ｅｄａｔａＡ及びａｕｔｈＴａｇＡを受信すると、コントローラ１４０２は、以前に生成されたキーＫｅｙを使用して、受信したａｕｔｈＴａｇＡを検証することができる。
【０２２７】
ブロック１４７０で、ブロック１４６８での検証が失敗した場合には、ブロック１４７２で、プロセス１４００は終了することができ、コントローラ１４０４は、ユーザにエラーを報告することができる。検証が成功した場合には、ブロック１４７４で、コントローラ１４０４は、ＬＴＰＫＡを復号して、ＬＴＰＫＡ、及びアクセサリのユーザ名ｕｓｅｒＡを、ペアリング済みアクセサリのレコードとして永続的に記憶することができる（そのような記憶は、上述のセキュア要素内に存在させることができる）。ブロック１４７６で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
【０２２８】
プロセス１４００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１４００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための他のプロトコル及びアルゴリズムで置き換えることもできる。
【０２２９】
上述のようなプロセス１４００は、アクセサリが、検証のために証明書をコントローラに送信するが、コントローラは、対応する証明書をアクセサリに送信しないという点で非対称的である。一部の実施形態では、双方向の証明書検証を実施することができる。例えば、証明書を有するコントローラが、ブロック１４１２〜１４１６と同様の処理を実行することにより、コントローラ証明（「ｐｒｏｏｆＣ」）を生成することができ、そのコントローラ証明を、コントローラ証明書と共に、アクセサリに送信することができる。アクセサリは、ブロック１４２４〜１４３６と同様の処理を実行することにより、そのコントローラ証明を検証することができる。
【０２３０】
一部の実施形態では、認証チップは、特定のデバイスに固有のものとすることができ、各デバイスは、一意の証明書を有し得る。他の実施形態では、同じクラスのアクセサリ（又は、コントローラ）は、同一の認証チップを、またそれゆえ、同一の証明書を有し得る。このことが当てはまる場合、ペア設定の間の中間者攻撃に対する防御は、低減される恐れがあるが、しかしながら、長期公開キーが交換された後は、後続のペア検証の間の双方向認証のために、これらのキーを信頼して使用することができる。
【０２３１】
中間者攻撃又は他の悪用のリスクを更に低減するために、他の技術を使用することもできる。例えば、ペア設定プロセスでの２つのデバイスの一方（又は、双方）が、どの程度他方のデバイスが近接しているかを（例えば、Ｂｌｕｅｔｏｏｔｈ  ＬＥ又はＮＦＣを使用して）検出することが可能な、近接センサを有する場合には、そのセンサを有するデバイスは、他方のデバイスが近接位置に（例えば、数インチの範囲内に）存在しないか又は留まらない場合には、ペア設定プロセスを中止することができる。このことにより、中間者攻撃の可能性を低減することができるが、これは、攻撃するデバイスが、その過程で、目的とする参加者に物理的に近接する必要があり、ユーザが気づく可能性が高い状況となるためである。
【０２３２】
一部の実施形態は、セキュリティ証明書及び設定コードの双方に基づくペアリングを、ペア設定プロセスに組み込むことができる。図１５Ａ〜図１５Ｆは、本発明の実施形態による、セキュリティ証明書及び設定コードを使用する、コントローラ１５０２及びアクセサリ１５０４に関するペア設定プロセス１５００の実施例を示す。プロセス１５００は、上述のプロセス１３００及びプロセス１４００の機能を組み込むことができる。
【０２３３】
最初に図１５Ａを参照すると、ブロック１５０６で、コントローラ１５０２は、ペア設定プロセスを開始するために、アクセサリ１５０４に開始要求を送信することができる。例えば、コントローラ１５０２は、アクセサリ１５０４の／ｐａｉｒ−ｓｅｔｕｐのＵＲＬに、ＨＴＴＰ  ＰＯＳＴ要求を送信することができる。このＰＯＳＴ要求は、所望のペアリング状態（例えば、「ペア設定を開始する」）を示す、ＴＬＶデータオブジェクトと、設定コード及び／又は証明書を使用するか否かを示す方法識別子とを含み得る。ブロック１５０８で、アクセサリ１５０４は、その開始要求を受信することができ、現在のペアリング状態を適宜に設定することができる。ブロック１５１０で、アクセサリ１５０４は、存在し得る他のあらゆるコントローラが、ペア設定を開始することを阻止することができる。例えば、ブロック１５１０の後に、ペア設定を開始する要求が受信される場合には、アクセサリは、エラー応答（例えば、ＨＴＴＰ４２９「Ｔｏｏ  Ｍａｎｙ  Ｒｅｑｕｅｓｔｓ（要求が多すぎる）」メッセージ）を返すことができる。アクセサリ１５０４は、プロセス１５００が完了する（又は、エラーにより終了する）まで、この方式でペア設定要求を阻止し続けることができる。
【０２３４】
一部の実施形態では、アクセサリ１５０４は、ペア設定の試みの失敗の数を、包括的に、又はコントローラごとに、最大試行回数までに制限することができる。例えば、アクセサリ１５０４は、制限（例えば、５回の試行、１０回の試行、又は何らかの他の制限）を定義して、失敗した試行のカウンタを保持することができる。カウンタが制限に到達するか、又は制限を超過した場合には、ブロック１５１２で、アクセサリは、その要求を拒絶することができ、プロセス１５００は、ブロック１５１４で終了することができる。一部の実施形態では、アクセサリ１５０４は、コントローラ１５０２に、エラーの原因（例えば、過度に多い試行）を示すエラー応答を送信することができる。あるいは、スロットリング技術（例えば、図１３Ａを参照して上述されたようなもの）又は他の技術を使用することにより、無認可のコントローラによる、ペア設定を実行する総当たり試行を防ぐことができる。
【０２３５】
最大試行回数を超過していないと想定すると、ブロック１５１６で、アクセサリ１５０４はペア設定を開始することができる。例えば、アクセサリ１５０４は、例えば、ＳＲＰ＿ｎｅｗ（ＳＲＰ６ａ＿ｓｅｒｖｅｒ＿ｍｅｔｈｏｄ（））などの適切なＳＲＰプロトコル機能を呼び出すことによって、ＳＲＰセッションを作り出すことができ、そのセッションに関するＳＲＰユーザ名を（例えば、総称とすることが可能な固定文字列をユーザ名として使用して、ＳＲＰ＿ｓｅｔ＿ｕｓｅｒｎａｍｅで）設定することができ、ＳＲＰ＿ｓｅｔ＿ｐａｒａｍｓで設定することが可能な、ランダムなソルト（例えば、少なくとも１６バイト）を生成することができ、ＳＲＰパスワードとして（例えば、ＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ又はＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ＿ｒａｗを使用して）設定される、設定コードを選択する（例えば、取得する）ことができる。
【０２３６】
プロセス１３００と同様に、アクセサリ１５０４は、ＥＥＰＲＯＭからのコードの読み取り、ユーザからのコードの受信、（例えば、プロセス１５００の実行の間の）ランダムコードの生成などを含めた様々な技術を使用して、設定コードを選択することができる。ブロック１５１８で、アクセサリ１５０４は、その設定コードをユーザに提示することができる。例えば、アクセサリ及び設定コードに応じて、そのコードは、アクセサリ１５０４又はそのパッケージングに張り付けられた、ラベル上に印刷するか、アクセサリ１５０４のディスプレイ上に提示することなどが可能である。一部の場合には、ユーザに設定コードを提示するのではなく、アクセサリ１５０４は、ＮＦＣチャネル、又は極めて短い距離（例えば、５０ｃｍ未満）を使用する他の信号伝達チャネルなどの、ペア設定プロセス１５００に関して使用されているチャネルとは独立した通信チャネルを使用して、そのコードをコントローラ１５０２に配信することができる。
【０２３７】
ブロック１５２０で、アクセサリ１５０４は、（例えば、ＳＲＰ＿ｇｅｎ＿ｐｕｂを使用して）公開キー（「ｐｋＡ」）を生成することができる。公開キーｐｋＡは、プロセス１５００の持続時間にわたって使用され、次いで破棄される、（秘密キー「ｓｋＡ」を伴う）短期キーペアの一部とすることができる。
【０２３８】
ブロック１５２２で、アクセサリ１５０４は、例えばＨＴＴＰ応答メッセージを使用して、開始要求に対する応答を送信することができる。この応答は、公開キーｐｋＡ及びランダムなソルトを含み得る。この応答をブロック１５２２で送信すると、アクセサリ１０４は、そのアクセサリの公開キーが送信されたことを示すように、現在のペアリング状態を更新することができる。
【０２３９】
ブロック１５２４で、コントローラ１５０２は、開始要求に対する応答を受信することができる。ブロック１５２６で、コントローラ１５０２は、ユーザから、設定コードを取得することができる。例えば、コントローラ１５０２は、アクセサリの設定コードを入力することをユーザに促す、ユーザインタフェース画面を提示することができる。上述のプロセス１３００のブロック１３２２と同様に、設定コードが、帯域外で、すなわち、ペア設定プロセスを実行するために使用されている通信チャネルとは独立した通信チャネルを介して、コントローラ１５０２に配信される限り、他の技術を使用することもできる。使用される具体的な技術に応じて、コントローラによる設定コードの取得には、何らかの形態のユーザアクティビティ（例えば、コードを入力すること、コントローラをアクセサリに近接させて保持すること、コントローラのカメラを操作することなど）を組み込むことができ、そのようなアクティビティは、デバイスのアイデンティティの帯域外確認を提供することに加えて、コントローラ１５０２とアクセサリ１５０４とのペアリングを確立することをユーザが意図していることの確認として役立ち得る。
【０２４０】
図１５Ｂを参照すると、ブロック１５２８で、コントローラ１５０２は、例えば、ＳＲＰ＿ｎｅｗ（ＳＲＰ６ａ＿ｓｅｒｖｅｒ＿ｍｅｔｈｏｄ（））などの適切なＳＲＰプロトコル機能を呼び出すことによって、ＳＲＰセッションを作り出すことができ、ＳＲＰユーザ名を（例えば、総称とすることが可能な固定文字列をユーザ名として使用して、ＳＲＰ＿ｓｅｔ＿ｕｓｅｒｎａｍｅで）設定することができ、アクセサリから受信したソルトに（ＳＲＰ＿ｓｅｔ＿ｐａｒａｍｓで）ソルトを設定することができ、それ自体の公開キー（「ｐｋＣ」）を（例えば、ＳＲＰ＿ｇｅｎ＿ｐｕｂを使用して）生成することができ、ブロック１５２６で取得した設定コードを使用して、ＳＲＰパスワードを（例えば、ＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ又はＳＲＰ＿ｓｅｔ＿ａｕｔｈ＿ｐａｓｓｗｏｒｄ＿ｒａｗを使用して）設定することができる。アクセサリ公開キーｐｋＡと同様に、公開キーｐｋＣは、プロセス１５００の持続時間にわたって使用され、次いで破棄される、（秘密キー「ｓｋＣ」を伴う）短期キーペアの一部とすることができる。ブロック１５３０で、コントローラ１５０２は、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を（例えば、ＳＲＰ＿ｃｏｍｐｕｔｅ＿ｋｅｙを使用して）計算することができる。ブロック１５３２で、コントローラ１５０２は、共有シークレットｉｎｐｕｔＫｅｙを有することの証明（「ｐｒｏｏｆＣ」）を（例えば、ＳＲＰ＿Ｒｅｓｐｏｎｄを使用して）生成することができる。
【０２４１】
ブロック１５３４で、コントローラ１５０２は、アクセサリ１５０４に、検証要求を送信することができる。例えば、コントローラ１５０２は、アクセサリ１５０４の／ｐａｉｒ−ｓｅｔｕｐのＵＲＬに、ＨＴＴＰ  ＰＯＳＴ要求を送信することができる。このＰＯＳＴ要求は、所望のペアリング状態（例えば、「ペア設定を検証する」）を示すＴＬＶデータオブジェクト、コントローラの公開キーｐｋＣ、及びコントローラ証明ｐｒｏｏｆＣを含み得る。
【０２４２】
ブロック１５３６で、アクセサリ１５０４は、その検証要求を受信することができる。ブロック１５３８で、アクセサリ１５０４は、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を（例えば、ＳＲＰ＿ｃｏｍｐｕｔｅ＿ｋｅｙを使用して）計算することができ、この共有シークレットは、ブロック１５３０でコントローラ１５０２によって計算された共有シークレットと合致するはずである。
【０２４３】
ブロック１５４０で、アクセサリ１５０４は、ブロック１５３８で計算された共有シークレットを使用して、コントローラ証明ｐｒｏｏｆＣを（例えば、ＳＲＰ＿ｖｅｒｉｆｙを使用して）検証することができる。図１５Ｂには示されないが、検証が失敗した場合には、アクセサリ１５０４は、プロセス１５００を終了させて、コントローラ１５０２にエラーメッセージを送信することができる。（本明細書で説明される他のペアリングプロセスと同様に、コントローラ１５０２はそのエラーをユーザに報告することができる。）
【０２４４】
ｐｒｏｏｆＣが検証されたと想定すると、ブロック１５４２で、アクセサリ１５０４は、共有シークレットを保有していることを証明するために、アクセサリ証明（「ｐｒｏｏｆＡ」）を（例えば、ＳＲＰ＿ｒｅｓｐｏｎｄを使用して）生成することができる。ブロック１５４４で、アクセサリ１５０４は、その共有シークレットから、セッション暗号キー（「ｅＫｅｙ」）を導出することができる。例えば、アクセサリ１５０４は、ｉｎｐｕｔＫｅｙ、ソルト、及び追加的情報を入力として使用して、５１２ビットハッシュ用のＳｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍバージョン２を実装するＨＫＤＦベースのキー導出関数（ＩＥＴＦ  ＲＦＣ  ６２３４で文書化されている、ＨＫＤＦ−ＳＨＡ−５１２）を使用することができる。
【０２４５】
図１５Ｃを参照すると、この実施例では、アクセサリ１５０４は、信頼される認証局によって発行されたセキュリティ証明書を有することが想定される。一部の実施形態では、この証明書は、図１４Ａ〜図１４Ｃを参照して上述されたように、認証チップ内に組み込むことができる。このことが当てはまる場合、アクセサリ１５０４は、その証明書を使用して、そのアイデンティティをコントローラ１５０２に更に証明することができる。一部の実施形態では、ブロック１５０６でコントローラ１５０２によって送信される開始要求、又はブロック１５３４でコントローラ１５０２によって送信される検証要求は、アクセサリが証明書で認証するべきか否かの指標を含み得る。
【０２４６】
アクセサリ１５０４が証明書で認証する場合には、ブロック１５４６で、アクセサリ１５０４は、ブロック１５３８で計算された共有シークレット（ｉｎｐｕｔＫｅｙ）から、署名するためのチャレンジを生成することができる。例えば、このチャレンジは、ｉｎｐｕｔＫｅｙ、ソルト、及び追加的情報項目を入力として使用して、ＨＫＤＦ−ＳＨＡ−５１２などのキー導出関数を適用することによって、生成することができる。これらのソルト及び追加的情報項目は、アクセサリ１５０４内に、そのオペレーティングシステム又はファームウェアの一部としてプログラムすることが可能な既定の値を有し得る。ブロック１５４８で、アクセサリ１５０４は、その証明書を使用して、このチャレンジに署名することができる。例えば、アクセサリ１５０４が認証チップを含む場合には、その認証チップが、チャレンジに署名することができる。上述のように、認証チップは、それ自体の永続的なキーペア（ｐｋＡ及びｓｋＡ、あるいはＬＴＰＫＡ及びＬＴＳＫＡとは独立したもの）を有し得るものであり、ＳＨＡ−１などの任意の所望の署名アルゴリズムを実行することができる。
【０２４７】
ブロック１５５０で、アクセサリ１５０４は、認証チップから取得することが可能な、署名付きチャレンジ及びアクセサリ証明書を含む、データ構造を構築することができる。ブロック１５５２で、アクセサリ１５０４は、ブロック１５５０で構築されたデータ構造を、ブロック１５４４で生成された暗号キー（ｅＫｅｙ）を使用して暗号化することができる。ＣｈａＣｈａ２０−Ｐｏｌｙ１３０５  ＡＥＡＤなどの、任意の対称暗号化アルゴリズムを使用することができる。この暗号化アルゴリズムは、暗号化データ構造、及びタグ（ａｕｔｈＴａｇＡ）を生成することができる。
【０２４８】
ブロック１５５４で、アクセサリ１５０４は、コントローラ１５０２に検証応答を送信することができる。この検証応答は、ブロック１５４２で生成されたアクセサリ証明ｐｒｏｏｆＡ、並びに、ブロック１５５０で生成された暗号化データ構造及びａｕｔｈＴａｇＡを含み得る。上述のように、一部の実施形態では、証明書ベースの認証を実行するか否かを、（例えば、コントローラ１５０２が、証明書ベースの認証を要求したか否かに応じて）選択することができる。証明書ベースの認証が実行されていない場合には、この検証応答は、暗号化データ構造及びａｕｔｈＴａｇＡを省略することができる。
【０２４９】
ブロック１５５６で、コントローラ１５０２は、アクセサリ１５０４から検証応答を受信することができる。ブロック１５５８で、コントローラ１５０２は、アクセサリ証明ｐｒｏｏｆＡを（例えば、ＳＲＰ＿ｖｅｒｉｆｙを使用して）検証することができる。検証が失敗した場合には、プロセス１５００はエラーで終了することができる。検証が成功したと想定すると、ブロック１５６０で、コントローラ１５０２は、ブロック１５３０で計算された共有シークレット（ｉｎｐｕｔＫｅｙ）から、暗号キー（ｅＫｅｙ）を導出することができる。コントローラ１５０２は、アクセサリ１５０４がブロック１５４４で使用したものと同じキー導出アルゴリズム及び入力を使用することができ、そのため、ブロック１５６０で導出されるｅＫｅｙは、ブロック１５４４でアクセサリによって生成されたｅＫｅｙに合致することが予想される。
【０２５０】
ブロック１５６２で、コントローラ１５０２は、受信したａｕｔｈＴａｇＡを検証することができ、ブロック１５６４で、コントローラ１５０２は、受信したデータ構造を復号することができる。
【０２５１】
ここで図１５Ｄを参照すると、ブロック１５６６で、コントローラ１５０２は、復号されたデータ構造から抽出されたアクセサリ証明書を検証することができる。例えば、上述のように、コントローラ１５０２は、有効なアクセサリ証明書を特定する情報を記憶する、それ自体の認証チップ又は他のセキュアデータストアを有し得るものであり、その情報は、信頼される認証局によって提供され、一部の場合には、信頼される認証局によって更新することもできる。あるいは、コントローラ１５０２は、受信した証明書を検証するために、信頼される認証局とリアルタイムで通信することが可能な場合もある。コントローラ１５０２は、認証局からの（ローカルでキャッシュされているか、又はリアルタイムで取得される）情報を使用して、アクセサリ証明書が有効であることを確認することができる。一部の実施形態では、特定の証明書は、特定のクラスのアクセサリに関してのみ有効とすることができ、コントローラ１５０２は、アクセサリから以前に受信した情報（例えば、上述のようなデバイス発見の間に提供された他の情報）を使用して、アクセサリのクラス、及び、アクセサリ証明書がそのアクセサリのクラスに関して有効であるか否かを判定することができる。証明書が有効ではない場合には、プロセス１５００はエラーで終了することができる。
【０２５２】
証明書が有効であると想定すると、ブロック１５６８で、コントローラ１５０２は、共有シークレットｉｎｐｕｔＫｅｙからチャレンジを生成することができる。コントローラ１５０２は、アクセサリ１５０４がブロック１５４６で使用したものと同じアルゴリズム及び入力（例えば、既定のソルト及び追加的情報項目を伴う、ｉｎｐｕｔＫｅｙ）を使用することができ、結果として、コントローラ１５０２及びアクセサリ１５０４は、双方とも同じチャレンジを生成するはずである。この技術の場合、コントローラ１５０２が、アクセサリ１５０４に平文のチャレンジを送信することは必要とされない。更には、チャレンジが、共有シークレットｉｎｐｕｔＫｅｙを組み込む場合には、そのチャレンジを偽者が推測することは困難なものとなり得る。ブロック１５７０で、コントローラ１５０２は、アクセサリ証明書からの公開キーを使用して、署名付きチャレンジを検証することができる。検証が失敗した場合には、プロセス１５００はエラーで終了することができる。
【０２５３】
検証が成功したと想定すると、コントローラはこの時点で、アクセサリと長期公開キーを交換する準備が整う。ブロック１５７２で、コントローラ１５０２は、共有シークレットの表現（例えば、コントローラ１５０２内に、そのオペレーティングシステム又はファームウェアの一部としてプログラムすることが可能な既定の値を有し得る、ソルト及び追加的情報項目を有する、共有シークレットのＨＤＫＦ−ＳＨＡ−５１２）、コントローラの長期公開キー（ＬＴＰＫＣ）、及びコントローラの識別子を連結する、ＬＴＰＫＣメッセージを生成することができる。一部の実施形態では、コントローラは、ブロック１５７２で使用することが可能な、既定の（ＬＴＰＫＣ、ＬＴＳＫＣ）キーペアを有し、他の実施形態では、（ＬＴＰＫＣ、ＬＴＳＫＣ）キーペアを、ブロック１５７２で生成することができる。ブロック１５７４で、コントローラ１５０２は、その長期秘密キー（ＬＴＳＫＣ）を使用して、例えば、Ｅｄ２５５１９（ｈｔｔｐ：／／ｅｄ２５５１９．ｃｒ．ｙｐ．ｔｏで文書化）などの署名アルゴリズムを、ＬＴＰＫＣメッセージに適用することによって、ＬＴＰＫＣメッセージに署名することができる。ブロック１５７６で、コントローラ１５０２は、ＬＴＰＫＣメッセージからの署名、ＬＴＰＫＣ、及びコントローラのＩＤを含むデータ構造を構築することができる。（ＬＴＰＫＣメッセージ自体は、アクセサリ１５０４が再構築することが可能となるため、このデータ構造から省略することができる。）ブロック１５７８で、コントローラ１５０２は、ブロック１５６０で導出された暗号キーｅＫｅｙを使用して、そのデータ構造を暗号化し、認証タグ（ａｕｔｈＴａｇＣ）を生成することができる。
【０２５４】
ブロック１５８０で、コントローラ１５０２は、アクセサリにキー交換要求を送信することができる。例えばコントローラ１５０２は、アクセサリ１５０４の／ｐａｉｒ−ｓｅｔｕｐのＵＲＬに、ＨＴＴＰ  ＰＯＳＴ要求を送信することができる。このキー交換要求は、ブロック１５７８で生成された暗号化データ構造及び認証タグを含み得る。ブロック１５８２で、アクセサリ１５０４は、コントローラ１５０２からキー交換要求を受信することができる。
【０２５５】
ここで図１５Ｅを参照すると、ブロック１５８４で、アクセサリ１５０４は、受信した認証タグを検証することができる。ブロック１５８６で、アクセサリ１５０４は、データ構造を復号することができ、ブロック１５８８で、アクセサリ１５０４は、そのデータ構造内に含まれる署名を検証することができる。これらの検証のうちのいずれかが失敗した場合には、プロセス１５００はエラーで終了することができる。
【０２５６】
認証タグ及び署名が検証されたと想定すると、ブロック１５９０で、アクセサリ１５０４は、そのデータ構造から注出されたＬＴＰＫＣ及びコントローラＩＤを、ペアリング済みコントローラのレコードとして、永続的に記憶することができる。そのような記憶は、上述のセキュア要素内に存在させることができる。
【０２５７】
アクセサリ１５０４は、同様の方式で、それ自体の長期公開キー（ＬＴＰＫＡ）をコントローラ１５０２に送信することができる。例えば、ブロック１５９２で、アクセサリ１５０４は、共有シークレットの表現（例えば、アクセサリのシステムソフトウェア又はファームウェア内にプログラムされた既定の値を有し得る、ソルト及び追加的情報項目を有する、共有シークレットのＨＤＫＦ−ＳＨＡ−５１２）、アクセサリの長期公開キー（ＬＴＰＫＡ）、及びアクセサリの識別子を連結する、ＬＴＰＫＡメッセージを生成することができる。一部の実施形態では、アクセサリは、ブロック１５９２で使用することが可能な既定の（ＬＴＰＫＡ、ＬＴＳＫＡ）キーペアを有し、他の実施形態では、（ＬＴＰＫＡ、ＬＴＳＫＡ）キーペアを、ブロック１５９２で生成することができる。ブロック１５９４で、アクセサリ１５０４は、その長期秘密キー（ＬＴＳＫＡ）を使用して、例えば、Ｅｄ２５５１９などの署名アルゴリズムを、ＬＴＰＫＡメッセージに適用することによって、ＬＴＰＫＡメッセージに署名することができる。ブロック１５９６で、アクセサリ１５０４は、ＬＴＰＫＡメッセージからの署名、ＬＴＰＫＡ、及びアクセサリのＩＤを含むデータ構造を構築することができる。（ＬＴＰＫＡメッセージ自体は、コントローラ１５０２が再構築することが可能となるため、このデータ構造から省略することができる。）ブロック１５９８で、アクセサリ１５０４は、ブロック１５４４で導出された暗号キーｅＫｅｙを使用して、そのデータ構造を暗号化し、認証タグ（ａｕｔｈＴａｇＢ）を生成することができる。
【０２５８】
ブロック１５０１で、アクセサリ１５０４は、コントローラ１５０２に、キー交換応答を送信することができる。このキー応答は、ブロック１５９８で生成された、暗号化データ構造及び認証タグを含み得る。ブロック１５０３で、コントローラ１５０２は、このキー交換応答を受信することができる。
【０２５９】
ここで図１５Ｆを参照すると、ブロック１５０５で、コントローラ１５０２は、受信した認証タグを検証することができる。ブロック１５０７で、コントローラ１５０２は、データ構造を復号することができ、ブロック１５０９で、コントローラ１５０２は、そのデータ構造内に含まれる署名を検証することができる。これらの検証のうちのいずれかが失敗した場合には、プロセス１５００はエラーで終了することができる。
【０２６０】
認証タグ及び署名が検証されたと想定すると、ブロック１５１１で、コントローラ１５０２は、そのデータ構造から注出されたＬＴＰＫＡ及びアクセサリＩＤを、ペアリング済みアクセサリのレコードとして、永続的に記憶することができる。そのような記憶は、上述のようなセキュア要素内に存在させることができる。
【０２６１】
ブロック１５１３で、ペア設定は完了し、そのことを示すようにペアリング状態を更新することができる。
【０２６２】
プロセス１５００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１５００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、セキュリティが確保されていない通信チャネルを介した、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。
【０２６３】
上述のようなプロセス１５００は、アクセサリが、検証のために証明書をコントローラに送信するが、コントローラは、対応する証明書をアクセサリに送信しないという点で、非対称的である。一部の実施形態では、双方向の証明書検証を実施することができる。例えば、証明書を有するコントローラが、ブロック１５４６〜１５５２と同様の処理を実行することにより、チャレンジを生成して、そのチャレンジに、コントローラ証明を使用して署名することができ、その署名付きチャレンジを、コントローラ証明書と共に、アクセサリに送信することができる。アクセサリは、ブロック１５６６〜１５７０と同様の処理を実行することにより、そのコントローラの証明を検証することができる。
【０２６４】
一部の実施形態では、所定のアクセサリ又はコントローラは、ペア設定プロセス１３００、１４００、１５００（及び／又は、具体的には説明されない他のプロセス）のうちのいずれか又は全てをサポートすることができ、使用されるペア設定プロセスは、ペアリングごとに選択することができる。統一性のために、コントローラは、複数のペア設定プロセスを（例えば、証明書の有無に関わりなく）サポートすることができ、所定のアクセサリに関するプロセスを、そのアクセサリがいずれのプロセス（単数又は複数）をサポートするかに基づいて、選択することができる。プロセスには、優先順位を（例えば、提供される相対的なセキュリティに基づいて）割り当てることができ、コントローラは、所定のアクセサリがサポートする、最も好ましいプロセスを選択することができる。コントローラは、例えば、開始要求メッセージ内にプロセス識別子を含めることによって、そのプロセスを使用するように指定することができる。
【０２６５】
図１６を参照することによって、より一般的なペア設定の図が示され、この図は、本発明の実施形態による、コントローラ１６０２とアクセサリ１６０４との間の、一般化されたペア設定プロセス１６００を示す。ペア設定プロセス１６００は、ブロック１６０６で、コントローラ１６０２によって開始することができる。例えば、上述のように、コントローラ１６０２は、ペア設定を実行するべきアクセサリ（例えば、アクセサリ１６０４）を特定するために、プロセス４００を（ブロック４２６を経て）実行することができる。コントローラ１６０２は、アクセサリ１６０４もまた、ブロック１６０８でペア設定を開始することができるように、アクセサリ１６０４にメッセージ（例えば、適切なＵＲＬへのＰＯＳＴ要求）を送信することができる。
【０２６６】
ブロック１６１０及び１６１２で、アクセサリ１６０４及びコントローラ１６０２は、共有シークレット（例えば、上述のプロセス１３００、１４００、及びプロセス１５００でのｉｎｐｕｔＫｅｙ）を確立することができる。共有シークレットを確立することは、双方向の情報交換を含み得る。例えば、プロセス１３００では、アクセサリは、ソルト及び短期公開キーを提供し、コントローラは、そのコントローラの短期公開キーを提供する。プロセス１４００及びプロセス１５００では、アクセサリは、そのアクセサリの短期公開キー及び証明書を提供し、コントローラは、そのコントローラの短期公開キーを提供する。一部の実施形態では、共有シークレットはまた、双方のデバイス内に（例えば、セキュア要素内、又は他の場所に）予めプログラムされた、他の情報も組み込むことができる。共有シークレットはまた、コントローラがアクセサリと相互運用されるように（例えば、ユーザによって）認可されている証拠を提供することが可能な、帯域外情報も組み込むことができる。例えば、プロセス１３００又はプロセス１５００では、共有シークレットを構築するために、アクセサリの設定コードが、コントローラ及びアクセサリによって使用される。上述のように、アクセサリの設定コードは、帯域外で、すなわち、証明の送信及び受信に使用されているチャネル以外の通信チャネルを使用して、コントローラに提供することができる。帯域外チャネルの例としては、ユーザ入力（例えば、ユーザは、コントローラのユーザインタフェースでアクセサリの設定コードを入力することができ、コントローラのカメラを使用して設定コードの写真を撮影することができる）、近距離通信チャネル、光信号伝達チャネル、有線電子信号伝達チャネル、音声（例えば、超音波）チャネルなどを挙げることができる。一部の場合には、帯域外チャネルは、ユーザ介入（例えば、設定コードを入力すること、アクセサリに近接した近距離内にコントローラを保持すること、写真を撮影すること、コネクタのプラグを差し込むこと）を組み込むことができ、帯域外チャネルを介して設定コードを通信するという事実は、ペアリングの確立をユーザが承認していることの指標として役立ち得る。
【０２６７】
ブロック１６１４で、コントローラ１６０２は、証明を生成して、アクセサリ１６０４に送信することができる。本明細書で使用するとき、「証明」又は「暗号化証明」は、共有シークレットを保有している受信デバイス（この場合は、アクセサリ１６０４）が、送信デバイス（この場合は、コントローラ１６０２）もまた共有シークレットを保有していることを検証するために使用することが可能な、任意の情報を含み得る。コントローラの証明の実施例としては、プロセス１３００、１４００、１５００での、「ｐｒｏｏｆＣ」と標識されたメッセージが挙げられる。
【０２６８】
ブロック１６１６で、アクセサリ１６０４は、コントローラの証明を受信することができ、ブロック１６１８で、アクセサリ１６０４は、そのローカルで生成された共有シークレットのコピーに基づいて、その証明を検証することができる。共有シークレットが合致しない場合には、コントローラの証明は検証されることなく、プロセス１６００はエラーで終了することができる。設定コードを使用して共有シークレットを生成する場合、ブロック１６１８での検証はまた、アクセサリに対するコントローラの認証としての役割も果たし得ることに留意されたい。
【０２６９】
証明が検証されたと想定すると、ブロック１６２０で、アクセサリ１６０４は、その共有シークレットをアクセサリ１６０４もまた保有していることを立証するために、それ自体の証明を生成して、コントローラ１６０２に送信することができる。このアクセサリの証明は、例えば、（プロセス１３００及びプロセス１５００と同様に）同じく共有シークレットを組み込むコントローラの証明とは異なる、暗号化メッセージとすることができる。一部の実施形態では、アクセサリのアイデンティティの他の証明を組み込むことができ、例えば、プロセス１４００及びプロセス１５００では、アクセサリは、そのアクセサリのアイデンティティの少なくとも一部の態様を確認する証明書を使用して、メッセージに署名することができる。
【０２７０】
ブロック１６２４で、コントローラは、受信した証明を検証することができる。ブロック１６１８と同様に、共有シークレットが合致しない場合には、アクセサリの証明は検証されることなく、プロセス１６００はエラーで終了することができる。設定コードを使用して共有シークレットを生成する場合、ブロック１６２４での検証はまた、コントローラに対するアクセサリの認証としての役割も果たし得ることに留意されたい。例えばアクセサリの証明が、（プロセス１４００及びプロセス１５００と同様に）証明書を使用して署名されたメッセージを組み込む場合には、更なる認証を提供することができる。
【０２７１】
ブロック１６２４で証明が検証されたと想定すると、双方のデバイスは、互いに認証されたと見なすことができ、共有シークレットを使用して、上述の長期公開キーなどの更なる情報を交換することにより、（永続的な）ペアリングを確立することができる。例えば、ブロック１６２６で、コントローラ１６０２は、その長期公開キー（ＬＴＰＫＣ）を送信することができる。ＬＴＰＫＣは、例えば、（プロセス１３００、１４００、及びプロセス１５００と同様に）共有シークレットから導出されたキーを使用して、暗号化された形態で送信することができる。ブロック１６２８で、アクセサリ１６０４は、ＬＴＰＫＣを受信して、永続的に（例えば、上述のようなセキュア要素内に）記憶することができる。ブロック１６３０で、アクセサリ１６０４は、その長期公開キー（ＬＴＰＫＡ）を送信することができる。ＬＴＰＫＡもまた、例えば、（プロセス１３００、１４００、及びプロセス１５００と同様に）共有シークレットから導出されたキーを使用して、暗号化された形態で送信することができる。ブロック１６３２で、コントローラ１６０２は、ＬＴＰＫＡを受信して、永続的に（例えば、上述のようなセキュア要素内に）記憶することができる。その後、この時点で各デバイスが認証されており、他方とのペアリングを確立するレコードを永続的に記憶しているため、ペア設定が完了する（ブロック１６３４）。
【０２７２】
プロセス１６００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、証明は、いずれの順序でも（アクセサリが最初に、又はコントローラが最初に）交換することができ、長期公開キーもまた、いずれの順序でも交換することができる。
【０２７３】
長期公開キーは、本明細書では、プライベート（又は、秘密）キーとは異なり、それらを他のデバイスに提供することが可能なことを示すために、「公開」と称されることに留意されたい。しかしながら、プロセス１３００、１４００、１５００、１６００で示されるように、ペア設定は、共有シークレットが他の情報（例えば、設定コード）を使用して確立された後に、デバイスが、暗号化された形態で長期公開キーを交換することを可能にし得る。一部の実施形態では、長期公開キーの復号及び記憶は、受信デバイス内のセキュアコンピューティング要素内で実施することができ、このことにより、長期公開キーが無認可のデバイスに公開されることを、更に防ぐことができる。このことは、無認可のデバイスがペア設定レコードを偽造することを、著しくより困難なものにさせることができる。このレベルのセキュリティにより、ペア設定レコードを、以下で説明されるように、デバイスが再接続する際の、より単純なペア検証プロセスのために使用することが可能となる。
【０２７４】
上述のペア設定プロセスのうちのいずれかを介して確立されたペアリングは、アクセサリ及びコントローラが、それらが受信する長期公開キーを永続的記憶装置（例えば、不揮発性メモリ、磁気ディスクなど）内に記憶することができるという点で、永続的な状態とすることができ、この永続的記憶装置は、セキュア要素内に存在し得る。一部の実施形態では、アクセサリが、１つのコントローラとペア設定を実行した後では、そのアクセサリは、あらゆる他のコントローラがペア設定を実行することを、例えば、ペア設定を開始するあらゆる受信要求に、エラーメッセージで応答することによって、防ぐことができる。アクセサリとペア設定を実行したコントローラは、そのアクセサリに関する「管理者」に指定することができ、例えば、以下で説明されるようなペア追加プロセスを使用して、そのアクセサリに、他のコントローラとのペアリングを確立するように命令することを、許容される場合がある。
【０２７５】
一部の実施形態では、アクセサリは、複数のコントローラと、同時にペアリングを確立することができ、各ペアリングは、ペア設定、ペア追加（以下で説明）などを使用して確立することができる。例えば、アクセサリは、ペアリングを確立した各コントローラの識別子及び関連するＬＴＰＫＣを含む、ルックアップテーブル若しくは他のデータ構造を、永続的に記憶することができる。このデータ構造はまた、そのコントローラについての他の情報も含み得る。例えば、異なるコントローラには、そのアクセサリに対する異なる程度の制御（許可と称されるもの）を付与することができ、そのアクセサリによって保持されるデータ構造は、いずれの許可を各コントローラが有するかを指定する、標識（例えば、フラグ）を含み得る。様々な許可を定義することができる。定義することが可能な１つの許可は、「管理者」許可であり、一部の実施形態では、管理者許可を有するコントローラのみが、そのアクセサリに、他のコントローラに関するペアリングレコードを（例えば、以下で説明されるようなペア追加プロセスを使用して）追加することができる。一部の実施形態では、ペア設定の実行が成功したコントローラには、管理者許可を自動的に付与することができる。他のコントローラには、ペア追加の間に、選択的に（例えば、以下で説明されるように）管理者許可を付与することができる。
【０２７６】
同様に、コントローラは、複数のアクセサリと、同時にペアリングを確立することができる。例えば、コントローラは、複数のアクセサリとペア設定を実行することができ、又は一部の場合には、コントローラは、以下で説明されるようなペア追加プロセスを介して、アクセサリとのペアリングを追加することができる。コントローラは、そのコントローラがペアリングを確立した各アクセサリの識別子及び関連するＬＴＰＫＡを含む、ルックアップテーブル若しくは他のデータ構造を、永続的に記憶することができる。このデータ構造はまた、コントローラが、そのアクセサリに関していずれの許可を有するかなどの、情報も含み得る。
【０２７７】
ペアリングを確立したコントローラ及びアクセサリは、その後は、互いに継続的な通信を維持しない場合があることが想到される。例えば、アクセサリ又はコントローラは、電源がオフになる場合があり、又は、一方のデバイスが、もう一方のデバイスの範囲外に移動される場合もある。互いにペアリングを確立したコントローラ及びアクセサリが、通信可能状態に戻る場合、再びペア設定を実行する代わりに、それらのデバイスは、異なるプロセス（本明細書では、ペア検証と称されるもの）を使用して、以前に確立されたペアリングの存在を検証することができる。ペア検証は、以前に（例えば、ペア設定又はペア追加の間に）作成され記憶された、長期公開キーレコードを使用することができる。ペア検証プロセスはまた、それらのデバイスがペア検証済み状態に維持されている限りは、後続のメッセージを暗号化するために使用することが可能な、新たな共有シークレット及び／又はセッションキーを生成することもできる。ペア検証済み状態（本明細書では、ペア検証済みセッションとも称されるもの）は、いずれかのデバイスによって、例えば、それ自体のセッションキーのコピーを削除することにより、他方のデバイスからの今後のメッセージの復号を不可能にさせることによって、終了させることができる。一部の実施形態では、ペア検証は、コントローラが、ペアリングを確立したアクセサリとの、統一的アクセサリプロトコル通信のためのチャネルを開くことを試みるたびに、実行することができる。
【０２７８】
図１７Ａ〜図１７Ｃは、本発明の実施形態による、コントローラ１７０２とアクセサリ１７０４との間のペア検証プロセス１７００の実施例を示す。プロセス１７００は、ペア検証が適切なアクションであることを、コントローラ１７０２が判定する場合に、例えば、コントローラ１７０２が、アクセサリ１７０４上での何らかの動作を制御する、ユーザ命令を受信し、かつ、ペア検証済みセッションが現在、コントローラ１７０２とアクセサリ１７０４との間に存在しない場合に、又は、コントローラ１７０２が、アクセサリ１７０４と再接続する場合に、開始することができる。
【０２７９】
図１７Ａを参照すると、ブロック１７０６で、コントローラ１７０４は、例えば上述のようなＣｕｒｖｅ２５５１９アルゴリズムを使用して、新たな短期キーペア（ｐｋＣ、ｓｋＣ）を生成することができる。ブロック１７０８で、コントローラ１７０４は、アクセサリ１７０４に、ペア検証開始要求を送信することができ、この要求は、短期公開キーｐｋＣ（及び、任意選択的に、ペアリングが確立された際にアクセサリ１７０４に提供された、コントローラＩＤ若しくはコントローラのユーザ名ｕｓｅｒＣなどの、追加的情報）を含み得る。一部の実施形態では、このペア検証開始要求は、アクセサリの／ｐａｉｒ−ｖｅｒｉｆｙのＵＲＬへの、ＨＴＴＰ  ＰＯＳＴ要求として送信することができる。一部の実施形態では、ペア検証開始状態をコントローラ１７０４が要求していることを示すように、図１２のＰａｉｒｉｎｇ  Ｓｔａｔｅ  Ｒｅｑｕｅｓｔ特性１２０１に、状態標識を書き込むことができる。
【０２８０】
ブロック１７１０で、アクセサリ１７０４は、ペア検証開始要求を受信することができ、そのペアリング済みコントローラのリスト内で、長期公開キー（ＬＴＰＫＣ）を検索することができる。一部の実施形態では、この検索は、セキュア要素内で実行することができ、アクセサリ１７０４の他の論理構成要素は、その検索が成功したか否かを、単に知ることができる。上述のように、コントローラＩＤ（又は、ユーザ名ｕｓｅｒＣ）をＬＴＰＫＣと関連付けるペアリングレコードは、ペアリングが確立される場合、永続的に記憶することができるため、ブロック１７１０により、アクセサリ１７０４は、コントローラ１７０２と既にペアリングが確立されているか否かを判定することが可能となり得る。
【０２８１】
ブロック１７１２で、コントローラ１７０２とのペアリングが、未だ確立されていない場合には、アクセサリ１７０４は、ブロック１７１４でエラーメッセージを送信することができる。ブロック１７１６で、コントローラ１７０２が、そのエラーメッセージを受信した場合には、プロセス１７００は、ブロック１７１８で終了することができ、コントローラ１７０２は、ユーザにエラーを報告することができる。
【０２８２】
アクセサリ１７０４が、コントローラ１７０２との確立済みペアリングを有すると判定する場合には、ブロック１７２０で、アクセサリ１７０４は、例えばＣｕｒｖｅ２５５１９アルゴリズムを使用して、短期公開／秘密キーペア（ｐｋＡ、ｓｋＡ）を生成することができる。ブロック１７２２で、アクセサリ１７０４は、ｓｋＡ及びｐｋＣを使用して、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を生成することができる。ブロック１７２４で、アクセサリ１７０４は、対称キー（「Ｋｅｙ」）を導出することができる。例えば、アクセサリ１７０４は、ｉｎｐｕｔＫｅｙ、ソルト（例えば、ペア設定で使用されたソルトとは異なるものとすることが可能な、既定の文字列）、及び追加的情報を入力として使用して、ＨＤＫＦ−ＳＨＡ−５１２を使用することができる。
【０２８３】
ブロック１７２６で、アクセサリ１７０４は、アクセサリ情報メッセージを生成して、署名することができる例えば、アクセサリ１７０４は、ｐｋＡとｐｋＣとを連結して、アクセサリの長期秘密キー（ＬＴＳＫＡ）で、その連結に署名することができる。アクセサリＩＤなどの追加的情報もまた、連結することができる。ブロック１７２８で、アクセサリ１７０４は、対称キーＫｅｙを使用して、この署名付きメッセージを暗号化することにより、アクセサリ証明（ｐｒｏｏｆＡ）及び認証タグ（ａｕｔｈＴａｇＡ）を生成することができる。ブロック１７３０で、アクセサリ１７０４は、コントローラ１７０２に、ペア検証開始応答を送信することができる。この応答は、ｐｒｏｏｆＡ、認証タグ、及び短期公開キーｐｋＡを含み得る。アクセサリ識別子又はユーザ名（ペアリングが確立された際に、コントローラに与えられたアクセサリ名とすることが可能な、「ｕｓｅｒＡ」）などの他の情報もまた、含めることができる。この応答をブロック１７３０で送信すると、アクセサリ１７０４は、そのアクセサリの証明が送信されたことを示すように、ペアリング状態を更新することができる。
【０２８４】
ブロック１７３２で、この応答を受信した後、コントローラ１７０２は、そのペアリング済みアクセサリのリスト内で、例えばアクセサリＩＤ又はアクセサリのユーザ名に基づいて、長期公開キー（ＬＴＰＫＡ）を検索することができる。一部の実施形態では、この検索は、セキュア要素内で実行することができ、コントローラ１７０２の他の論理構成要素は、その検索が成功したか否かを、単に知ることができる。上述のように、アクセサリＩＤ（又は、ユーザ名ｕｓｅｒＡ）をＬＴＰＫＡと関連付けるペアリングレコードは、ペアリングが確立される場合、永続的に記憶することができるため、ブロック１７３２により、コントローラ１７０２は、アクセサリ１７０４と既にペアリングが確立されているか否かを判定することが可能となり得る。
【０２８５】
図１７Ｂを参照すると、ブロック１７３４で、アクセサリ１７０４とのペアリングが未だ確立されていない場合には、プロセス１７００は、ブロック１７３６で終了することができ、コントローラ１７０２は、ユーザにエラーを報告することができる。一部の実施形態では、コントローラ１７０２は、アクセサリ１７０４との確立済みペアリングを示す、記憶されたレコードを有するか否かを、プロセス１７００を開始する前に判定することができ、ブロック１７３４での、この更なる確認を省略することができる。
【０２８６】
コントローラ１７０２が、アクセサリ１７０４との確立済みペアリングを有すると判定した場合には、ブロック１７３８で、コントローラ１７０２は、ｓｋＣ及びｐｋＡを使用して、共有シークレット（「ｉｎｐｕｔＫｅｙ」）を生成することができる。ブロック１７４０で、コントローラ１７０２は、対称キー（「Ｋｅｙ」）を導出することができる。例えば、コントローラ１７０２は、ｉｎｐｕｔＫｅｙ、ソルト、及び追加的情報項目を入力として使用して、ＨＤＫＦ−ＳＨＡ−５１２を使用することができる。一部の実施形態では、これらのソルト及び追加的情報項目は、ペア設定の間に使用された既定の値とは異なる、既定の値を有し得る。エラーが発生しなかった場合には、ブロック１７４０で導出されるＫｅｙは、ブロック１７２４でアクセサリ１７０４によって導出されたＫｅｙと合致するはずである。
【０２８７】
ブロック１７４２で、コントローラ１７０２は、受信したｐｒｏｏｆＡを、対称キーＫｅｙを使用して復号することができ、また、ａｕｔｈＴａｇＡを検証することもできる。ブロック１７４４で、コントローラ１７０２は、ｐｒｏｏｆＡから抽出された署名付きアクセサリ情報メッセージ上の、アクセサリの署名を検証することができる。この検証は、アクセサリ１７０４との確立済みペアリングからの、記憶されたＬＴＰＫＡを使用することができる。成功した場合には、この検証により、（他のアクセサリが、同じ長期キーペアを有さないという前提の下で）アクセサリ１７０４が、以前にＬＴＰＫＡを提供したアクセサリと同じものであることが確認される。ブロック１７４６で、ａｕｔｈＴａｇＡ又は署名が検証されない場合には（又は、復号が失敗した場合には）、プロセス１７００は、ブロック１７４８で終了することができ、コントローラ１７０２は、ユーザにエラーを報告することができる。
【０２８８】
図１７Ｃを参照すると、検証がブロック１７４６で成功した場合には、ブロック１７５０で、コントローラ１７０２は、コントローラ情報メッセージを生成して署名することができる。例えば、コントローラ１７０２は、ｐｋＣとｐｋＡとを連結して（この実施例での順序は、ブロック１７２４での連結とは逆である）、コントローラの長期秘密キーで、その連結に署名することができる。コントローラＩＤなどの追加的情報もまた、連結することができる。ブロック１７５２で、コントローラ１７０２は、対称キーＫｅｙを使用して、この署名付きメッセージを暗号化することにより、コントローラ証明（ｐｒｏｏｆＣ）及び認証タグ（ａｕｔｈＴａｇＣ）を生成することができる。ブロック１７５４で、コントローラ１７０２は、アクセサリ１７０４に、検証終了要求を送信することができる。この要求は、ｐｒｏｏｆＣ及びａｕｔｈＴａｇＣを含み得る。この要求をブロック１７５４で送信すると、コントローラ１７０２は、そのコントローラの証明が送信されたことを示すように、ペアリング状態を更新することができる。
【０２８９】
ブロック１７５６で、アクセサリ１７０４は、検証終了要求を受信することができ、その受信したｐｒｏｏｆＣを、対称キーＫｅｙを使用して復号し、ａｕｔｈＴａｇＣを検証することができる。ブロック１７５８で、アクセサリ１７０４は、ｐｒｏｏｆＣから抽出された署名付きコントローラ情報メッセージ上の、コントローラの署名を検証することができる。この検証は、コントローラ１７０２との確立済みペアリングからの、記憶されたＬＴＰＫＣを使用することができる。成功した場合には、この検証により、（他のコントローラが、同じ長期キーペアを有さないという前提の下で）コントローラ１７０２が、以前にＬＴＰＫＣを提供したコントローラと同じものであることが確認される。ブロック１７６０で、ａｕｔｈＴａｇＣ又は署名が検証されない場合には（又は、復号が失敗した場合には）、アクセサリ１７０４は、ブロック１７６２で、コントローラ１７０２にエラー応答を送信することができる。検証が成功した場合には、アクセサリ１７０４は、ブロック１７６４で、コントローラ１７０２に成功応答を送信することができる。いずれの場合にも、応答を送信すると、アクセサリ１７０４は、その適切な応答を示すように、ペアリング状態を更新することができる。
【０２９０】
ブロック１７６６で、コントローラ１７０２は、いずれの応答が受信されたかを判定することができる。エラーメッセージ１７６２が受信された場合には、プロセス１７００は、ブロック１７６８で終了することができ、コントローラ１７０２は、ユーザにエラーを報告することができる。成功メッセージ１７６４が受信された場合には、ペア検証は、ブロック１７７０で完了し、そのことを示すようにペアリング状態を更新することができる。
【０２９１】
プロセス１７００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１７００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。
【０２９２】
プロセス１７００は、ペアリングが確立された際に長期公開キーが交換された（例えば、ペア設定又はペア追加プロセスが使用された）方式とは、独立したものであることにもまた留意されたい。アクセサリ及びコントローラは、各デバイスが他方の長期公開キーを有し、それらの長期公開キーを（例えば、各デバイスのセキュア要素内に）常に記憶したまま維持することができる限り、ペア検証をすることができる。
【０２９３】
更には、アクセサリ及びコントローラに関連付けられたユーザ名（「ｕｓｅｒＡ」及び「ｕｓｅｒＣ」）は、ペア検証の間に、他方のデバイスが長期公開キーを検索することを可能にする、任意の情報を含み得る。この情報は、実際のユーザの名前又は他の識別子を含み得るが、これは必須ではない。一部の実施形態では、ユーザ名は、特定の長期公開キーが属するデバイスの、デバイス識別子を組み込むことができる（又は、そのデバイス識別子とすることができる）。
【０２９４】
上述の様々なペア設定プロセスと同様に、ペア検証プロセス１７００は、新たな暗号キー（Ｋｅｙ）を生成することを含み得る。一部の実施形態では、このキーは、ペア検証プロセス１７００の完了後に続けて送信される、いずれか又は全てのメッセージ（例えば、上述のような要求及び応答）を暗号化するための、セッションキーとして使用することができる。このセッションキーは、いずれかのデバイスが、そのデバイスのセッションキーのコピーを削除するか又は無効化するまで、存続し得る。それゆえ、いずれかのデバイスは、そのデバイス自体のセッションキーのコピーを削除するか又は無効化することによって、任意の時点で、他方との通信を一方的に切断することができる。例えば、アクセサリは、コントローラが近接閾値の外側に移動するか、若しくはアクセサリとの接続性を喪失する場合には、又は、タイムアウト期間内に、若しくはセッション持続時間の一定の上限値（アクセサリ製造元又はプログラマが選択して作成するものと同じ短さ若しくは長さとすることが可能なもの）の後に、通信が実施されない場合には、セッションキーを削除することができる。このことにより、アクセサリは、コントローラのアクセスを、必要に応じて制限することが可能となる。
【０２９５】
一部の実施形態では、ペア検証プロセス１７００の間に導出される暗号キーは、プロセス１７００の間にのみ使用される。ペア検証済みセッション内での後続の通信に関しては、コントローラ１７０２及びアクセサリ１７０４は、それぞれ、１つ以上の新たなセッションキーを計算することができる。例えば、アクセサリからコントローラへのセッションキー（「ＡＣセッションキー」）は、制御ソルト及び追加的情報項目（既定の定数値とすることが可能なもの）と共に、ペア検証の間に（例えば、プロセス１７００のブロック１７２２及び１７３８で）生成された共有シークレット（ｉｎｐｕｔＫｅｙ）に、ＨＫＤＦ−ＳＨＡ−５１２（又は、同様のアルゴリズム）を適用することによって、導出することができる。例えば、コントローラからアクセサリへのセッションキー（「ＣＡセッションキー」）は、別の制御ソルト及び追加的情報項目（同じく、既定の定数値とすることが可能なもの）と共に、ペア検証の間に生成された共有シークレット（ｉｎｐｕｔＫｅｙ）に、ＨＫＤＦ−ＳＨＡ−５１２（又は、同様のアルゴリズム）を適用することによって、導出することができる。一部の実施形態では、異なる制御ソルト及び／又は異なる追加的情報項目を使用して、ＡＣセッションキー及びＣＡセッションキーを生成することができるため、それらの２つのセッションキーは、同じである必要はない。コントローラ及びアクセサリは、それぞれ、ＡＣセッションキー及びＣＡセッションキーの双方を生成することができる。ペア検証済みセッション内での後続の通信の間、ＡＣセッションキーは、アクセサリによって、コントローラに送信するメッセージを暗号化するために、かつコントローラによって、アクセサリから受信するメッセージを復号するために使用することができ、その一方で、ＣＡセッションキーは、コントローラによって、アクセサリに送信するメッセージを暗号化するために、かつアクセサリによって、コントローラから受信するメッセージを復号するために使用することができる。いずれかのデバイスは、そのセッションキーを無効化すること（例えば、そのセッションキーを削除するか、又は、そのセッションキーを使用して暗号化されている任意の受信メッセージに、エラーで応答すること）によって、セッションを終了することができる。
【０２９６】
更には、一部の実施形態では、単一のコントローラが、複数の長期キーペア（ＬＴＰＫＣ、ＬＴＳＫＣ）を定義して使用することができる。例えば、複数の認可ユーザを有するコントローラ（例えば、共用コンピュータ）は、異なるユーザが、異なるアクセサリのサブセットと対話することができるように、各認可ユーザに関して、異なる長期キーペアを有し得る。コントローラが、各キーペアに関して別個のユーザ名を有する限り、アクセサリは、そのコントローラが２つ以上のキーペアを有することを認識する必要はない。別の例として、コントローラは、異なるアクセサリとペアリングを確立するために、異なる長期キーペアを使用することができる。複数の長期キーペアを使用するコントローラは、ペアリングが確立されている各アクセサリに関して、いずれの（ＬＴＰＫＣ、ＬＴＳＫＣ）ペアが使用されたかを、追跡することができる。同様に、アクセサリは、複数の長期キーペア（ＬＴＰＫＡ、ＬＴＳＫＡ）を有することが可能であり、ペアリングが確立されている各コントローラに関して、いずれのペアが使用されたかを、追跡することができる。一部の実施形態では、デバイスは、特定の長期公開キーを与える他のデバイスの数を制限することができ、複数の長期公開キーを有することにより、そのデバイスは、異なるキーに随時切り替えることが可能となり得る。
【０２９７】
一部の実施形態では、長期公開キー（又は、一部の場合には、証明書）は、「ペア追加」と称することが可能なプロセス、すなわちペアを追加することが可能なプロセスで、ペア設定又はペア検証後の任意の時点で、デバイス間で交換することができる。例えば、上述のように、アクセサリは、１つのコントローラ（そのアクセサリに関する「管理者」又は「アドミン」と称することが可能なもの）とペア設定を実行するように、そのアクセサリ自体を制限することができ、最初に成功したペア設定の後は（例えば以下で説明されるように、少なくとも、そのペアリングが除去されるまでは）、全ての後続のペア設定要求を拒否することができる。他のコントローラが、そのアクセサリと対話することを可能にするために、アドミンコントローラは、ペア追加プロセスを実行することにより、そのアクセサリと、異なるコントローラとの間に（又は、一部の場合には、そのアクセサリと、同じコントローラの異なる長期公開キーとの間に）、ペアリングを確立することができる。
【０２９８】
図１８Ａ〜図１８Ｂは、本発明の実施形態による、コントローラ１８０２（例えば、管理者許可を有するコントローラ）とアクセサリ１８０４との間の、ペア追加プロセス１８００の実施例を示す。このプロセスでは、コントローラ１８０２は、以前に、アクセサリ１８０４とペア設定を実行している（また、それにより管理者許可を取得している）か、又は、ペア追加プロセス１８００を実行する、以前のインスタンスを介して、管理者として追加されていることが想定される。
【０２９９】
最初に図１８Ａを参照すると、ブロック１８０６及び１８０８で、コントローラ１８０２及びアクセサリ１８０４は、ペア検証プロセス（例えば、プロセス１７００）を完了することにより、共有シークレット及びセッションキー（単数又は複数）（例えば、上述のようなＡＣキー及びＣＡキー）を確立することができる。
【０３００】
ブロック１８１０で、コントローラ１８０２は、アクセサリ１８０４と交換するための長期公開キー（ＬＴＰＫＮ）を特定することができる。このキーは、例えば、ペアリングが確立されることになるコントローラ（本明細書では、「新規」コントローラとも称されるもの）に属する、長期公開キーとすることができ、このコントローラは、コントローラ１８０２以外のコントローラとすることができる。一部の実施形態では、その新規コントローラに関する、セキュリティ証明書（長期公開キーを含み得るもの）を取得することができる。ブロック１８１２で、コントローラ１８０２は、データブロックを生成することができ、このデータブロックは、そのデータブロックが、ペアリングを追加する要求に関するものであることの指標と、長期公開キーＬＴＰＫＮと、新規コントローラのコントローラ識別子と、新規コントローラに付与されることになる許可を示す、許可情報（例えば、フラグ）とを含む。例えば、上述のように、アクセサリとペア設定を実行する最初のコントローラを、そのアクセサリに関する管理者として、自動的に指定することができる。ペア追加プロセス１８００を介して追加される各新規コントローラに関して、許可情報は、その新規コントローラもまた管理者として指定するべきか否かを、指定することができる。一部の実施形態では、アクセサリに関する管理者は、そのアクセサリに関するペア追加を実行することが許可されるが、管理者ではないコントローラは、ペア追加を実行することを許可されない。
【０３０１】
ブロック１８１４で、コントローラ１８０２は、アクセサリ１８０４に、ペア追加開始要求を送信することができ、この要求は、ブロック１８１２で生成されたデータブロックを含み得る。ペア検証済みセッション内での全ての通信と同様に、この要求は、適切なセッションキーを使用して暗号化することができる。一部の実施形態では、このペア追加開始要求は、そのペア追加開始要求を特定する状態標識を含み得る（この状態標識及び後続の状態標識は、図１２のＰａｉｒｉｎｇ  Ｓｔａｔｅ  Ｒｅｑｕｅｓｔ特性１２０１に書き込むことができる）。一部の実施形態では、このペア追加開始要求は、アクセサリ１８０４の／ｐａｉｒｉｎｇｓのＵＲＬ（又は、他の適切なＵＲＬ）への、ＨＴＴＰ  ＰＯＳＴ要求として送信することができる。
【０３０２】
ブロック１８１６で、アクセサリ１８０４は、そのペア追加開始要求を受信することができる。ペア検証済みセッションでの、コントローラからの任意の受信要求と同様に、アクセサリ１８０４は、適切なセッションキーを使用して、その要求を復号することから開始することができ、復号が失敗した場合には、アクセサリ１８０４は、エラー応答を返す（又は、全く応答しない）ことが可能である。ブロック１８１８で、アクセサリ１８０４は、コントローラ１８０２が、ペア追加を実行することを許可されているか否かを判定することができる。例えば、上述のように、コントローラには、選択的に管理者許可を付与することができ、ペア追加は、管理者許可を有するコントローラに限定することができる。別の実施例として、ユーザインタフェースを有するアクセサリは、ペア追加要求を許可するべきか否かを示すように、ユーザに促すことができる。更に別の実施例として、上述のように、一部の場合には、ユーザは、機械的操作を介して、アクセサリをペアリングモードにすることができ、一部のアクセサリは、ペアリングモードにある間にのみ、ペア追加要求を許可するように構成することができる。更に別の実施例として、一部の実施形態では、アクセサリ１８０４は、同時に記憶することが可能なペアリングの数に対する上限値（例えば、１６のペアリング、３２のペアリング、又は何らかの他の限界値）を有し得るものであり、アクセサリ１８０４は、この限界値を超過する結果となる場合には、ペア追加要求を不許可として取り扱うことができる。特定のペア追加要求をアクセサリ１８０４が許可するべきか否かを判定する、他の技術もまた使用することができる。要求が許可されない場合には、アクセサリ１８０４は、ブロック１８２０でエラーメッセージを送信することができる。
【０３０３】
図１８Ｂを参照すると、ペア追加要求が許可された場合には、ブロック１８３２で、アクセサリ１８０４は、受信したメッセージに基づく新たなペアリングを、永続的に（例えば、そのセキュア要素内に）記憶することができる。例えば、アクセサリ１８０４は、新規コントローラに関する、受信したコントローラ識別子及び許可と関連させて、受信した長期公開キーＬＴＰＫＮを記憶することができる。
【０３０４】
一部の実施形態では、アクセサリ１８０４は、プロセス１８００の間、コントローラ１８０２に長期公開キー（ＬＴＰＫＡ）を提供する必要はないが、これは、コントローラ１８０２が、プロセス１８００を開始する前に、その長期公開キーを受信しているためである。しかしながら、他の実施形態では、アクセサリ１８０４は、異なるコントローラでは異なる長期公開キーを使用することが望ましい場合がある。このことが当てはまる場合、アクセサリ１８０４は、その新規コントローラによって使用されるべき長期公開キーを含む、データブロックを準備することができる。例えば、ブロック１８３４で、アクセサリ１８０４は、新規コントローラによって使用されることになる長期公開キーを特定することができ、この長期公開キーは、以前にコントローラ１８０２に提供された長期公開キー（ＬＴＰＫＡ）と同じものか、又は異なるものとすることができる。ブロック１８３６で、アクセサリ１８０４は、ブロック１８３４で特定された長期公開キーと、新規コントローラによって使用されることになるアクセサリ識別子（以前にコントローラ１８０２に提供されたアクセサリ識別子と同じものか、又は異なるものとすることが可能なもの）とを含む、データブロックを生成することができる。
【０３０５】
ブロック１８３８で、アクセサリ１８０４は、コントローラ１８０２に、ペア追加応答を送信することができる。データブロックが、ブロック１８３６で生成された場合には、そのデータブロックを、ペア追加応答内に含めることができる。ペア検証済みセッション内での全ての通信と同様に、この応答は、適切なセッションキーを使用して暗号化することができる。ペア追加応答は、そのペア追加応答が送信されたことを示すように、状態標識を更新することを含み得る。
【０３０６】
ブロック１８４０で、コントローラ１８０２は、このペア追加応答を受信することができる。ペア検証済みセッションでの、アクセサリからの任意の受信応答と同様に、コントローラ１８０２は、適切なセッションキーを使用して、その応答を復号することから開始することができ、復号が失敗した場合には、その応答を無視することができ、プロセス１８００はエラーで終了することができる。
【０３０７】
ブロック１８４４で、コントローラ１８０２は、その応答が成功を示すものか否かを判定することができる。成功を示すものではない場合には、プロセス１８００は、ブロック１８４６で終了することができ、コントローラ１８０２は、ユーザにエラーを通知することができる。応答が成功を示すものである場合には、ブロック１８４８で、コントローラ１８０２は、新規コントローラに、このペアリングを通知することができる。例えば、コントローラ１８０２は、新規コントローラに、アクセサリ１８０４に関する、アクセサリ識別子及び長期公開キーＬＴＰＫＡを通信することができる。一部の実施形態では、コントローラ１８０２は、アクセサリ１８０４に関する、以前に記憶されたＬＴＰＫＡ及びアクセサリ識別子を、新規コントローラに提供することができ、他の実施形態では、コントローラ１８０２は、ペア追加応答内でアクセサリ１８０４によって提供された情報を、新規コントローラに提供することができる。新規コントローラは、受信したＬＴＰＫＡ及びアクセサリ識別子を、ペアリングレコードとして永続的に記憶することができる。その後は、新規コントローラは、アクセサリ１８０４と（コントローラ１８０２の更なる関与を伴うことなく）ペア検証プロセス（例えば、プロセス１７００）を実行することができ、アクセサリ１８０４と対話することができる。
【０３０８】
プロセス１８００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１８００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のプロトコル及びアルゴリズムで置き換えることもできる。一部の実施形態では、ペア追加プロセス１８００は、以下で説明されるような、委譲ペアリングのモードとして使用することができる。
【０３０９】
上述のように、ペア設定及びペア追加は、受信デバイスによって永続的かつ安全に記憶することが可能な、長期公開キーを交換することによって、アクセサリとコントローラとの間のペアリングが確立されることを可能にし得る。一部の場合には、例えば、永続的記憶装置から長期公開キーを除去することによって、確立済みペアリングを除去することが望ましい場合がある。したがって、本発明の特定の実施形態は、ペア除去プロセスを提供する。
【０３１０】
図１９Ａ〜図１９Ｂは、本発明の実施形態による、コントローラ１９０２（例えば、管理者許可を有するコントローラ）とアクセサリ１９０４との間の、ペア除去プロセス１９００の実施例を示す。プロセス１９００は、全般的にプロセス１８００と同様とすることができるが、ただし、プロセス１９００は、新たなペアリングを確立するのではなく、既存のペアリングを除去する結果をもたらす。このプロセスでは、コントローラ１９０２は、以前に、アクセサリ１９０４とペア設定を実行している（また、それにより管理者許可を取得している）か、又は、例えばペア追加プロセス１８００の実行を介して、管理者として追加されていることが想定される。
【０３１１】
図１９Ａを参照すると、ブロック１９０６及び１９０８で、コントローラ１９０２及びアクセサリ１９０４は、ペア検証プロセス（例えば、プロセス１７００）を完了することにより、共有シークレット及びセッションキー（単数又は複数）（例えば、上述のようなＡＣキー及びＣＡキー）を確立することができる。
【０３１２】
ブロック１９１０で、コントローラ１９０２は、除去されることになるコントローラの識別子を取得することができる。この識別子は、アクセサリ１８０４によって、ペアリングレコード内に記憶されている識別子とすることができる。一部の場合には、この識別子は、コントローラ１９０２自体の識別子とすることができ（コントローラは、それ自体のペアリングを除去することができる）、他の場合には、別のコントローラの識別子とすることができる。一部の場合には、ブロック１９１０は、この識別子に加えて、除去されるコントローラの長期公開キーを得ることを含み得る。ブロック１９１２で、コントローラ１９０２は、データブロックを生成することができ、このデータブロックは、そのデータブロックが、ペアリングを除去する要求に関するものであることの指標と、ペアリングが除去されることになるコントローラの識別子とを含む。一部の実施形態では、このデータブロックは、除去されるコントローラの長期公開キーなどの、他の情報を含み得る。
【０３１３】
ブロック１９１４で、コントローラ１９０２は、アクセサリ１９０４に、ペア除去開始要求を送信することができ、この要求は、ブロック１９１２で生成されたデータブロックを含み得る。ペア検証済みセッション内での全ての通信と同様に、この要求は、適切なセッションキーを使用して暗号化することができる。一部の実施形態では、このペア除去開始要求は、そのペア開始要求が送信されたことを示す除去状態標識を含み得る（この状態標識及び後続の状態標識は、図１２のＰａｉｒｉｎｇ  Ｓｔａｔｅ  Ｒｅｑｕｅｓｔ特性１２０１に書き込むことができる）。一部の実施形態では、このペア除去開始要求は、アクセサリ１９０４の／ｐａｉｒｉｎｇｓのＵＲＬ（又は、他の適切なＵＲＬ）への、ＨＴＴＰ  ＰＯＳＴ要求として送信することができる。
【０３１４】
ブロック１９１６で、アクセサリ１９０４は、そのペア除去開始要求を受信することができる。ペア検証済みセッションでの、コントローラからの任意の受信要求と同様に、アクセサリ１９０４は、適切なセッションキーを使用して、その要求を復号することから開始することができ、復号が失敗した場合には、アクセサリ１９０４は、エラー応答を返す（又は、全く応答しない）ことが可能である。ブロック１９１８で、アクセサリ１９０４は、コントローラ１９０２が、ペア除去を実行することを許可されているか否かを判定することができる。例えば、上述のように、コントローラには、選択的に管理者許可を付与することができ、ペア除去は、管理者許可を有するコントローラに限定することができる。別の実施例として、ユーザインタフェースを有するアクセサリは、ペア除去要求を許可するべきか否かを示すように、ユーザに促すことができる。更に別の実施例として、上述のように、一部の場合には、ユーザは、機械的操作を介して、アクセサリをペアリングモードにすることができ、一部のアクセサリは、ペアリングモードにある間にのみ、ペア除去要求を許可するように構成することができる。特定のペア除去要求をアクセサリ１９０４が許可するべきか否かを判定する、他の技術もまた使用することができる。要求が許可されない場合には、アクセサリ１９０４は、ブロック１９２０でエラーメッセージを送信することができる。
【０３１５】
図１９Ｂを参照すると、ペア除去要求が許可された場合には、ブロック１９３２で、アクセサリ１９０４は、その確立済みペアリングのリストから、受信したデータブロック内で指定されたコントローラとのペアリングを、（例えば、そのペアリングレコードをセキュア記憶要素から削除することによって）除去することができる。
【０３１６】
一部の実施形態では、アクセサリ１９０４は、プロセス１９００の間、長期公開キー（ＬＴＰＫＡ）を除去する、相互的な命令を提供する必要はない。アクセサリ１９０４が、ペアリングレコードを除去した後、除去されたコントローラは、アクセサリ１９０４とのペア検証を実行することが不可能となり、このことにより、除去されたコントローラもまた、そのペアリングレコードを除去するか否かに関わりなく、除去されたコントローラがアクセサリ１９０４と対話することを防ぐことができる。しかしながら、他の実施形態では、除去されることになるペアリングを、アクセサリ１９０４が指定することが望ましい場合がある。このことが当てはまる場合、アクセサリ１９０４は、その新たに除去されるコントローラによって除去されるべき長期公開キー及びアクセサリ識別子を含む、データブロックを準備することができる。例えば、ブロック１９３４で、アクセサリ１９０４は、新たに除去されるコントローラから除去するべき、長期公開キーを特定することができ、この長期公開キーは、例えば、そのコントローラが追加された際に、プロセス１８００のブロック１８３４で特定されたキーとすることができる。ブロック１９３６で、アクセサリ１９０４は、ブロック１９３４で特定された長期公開キーと、この長期公開キーに関連付けられたアクセサリ識別子とを含む、データブロックを生成することができる。
【０３１７】
ブロック１９３８で、アクセサリ１９０４は、コントローラ１９０２に、ペア除去応答を送信することができる。データブロックが、ブロック１９３６で生成された場合には、そのデータブロックを、ペア除去応答内に含めることができる。ペア検証済みセッション内での全ての他の通信と同様に、この応答は、適切なセッションキーを使用して暗号化することができる。ペア除去応答は、そのペア除去応答が送信されたことを示すように、状態標識を更新することを含み得る。
【０３１８】
ブロック１９４０で、コントローラ１９０２は、このペア除去応答を受信することができる。ペア検証済みセッションでの、アクセサリからの任意の受信応答と同様に、コントローラ１９０２は、適切なセッションキーを使用して、その応答を復号することから開始することができ、復号が失敗した場合には、その応答を無視することができ、プロセス１９００はエラーで終了することができる。
【０３１９】
ブロック１９４４で、コントローラ１９０２は、その応答が成功を示すものか否かを判定することができる。成功を示すものではない場合には、プロセス１９００はブロック１９４６で終了することができ、コントローラ１９０２はユーザにエラーを通知することができる。応答が成功を示すものである場合には、ブロック１９４８で、コントローラ１９０２は、除去されたコントローラに、そのペアリングが除去されたことを通知することができる。一部の実施形態では、コントローラ１９０２はまた、除去されたコントローラに、アクセサリ１９０４に関するアクセサリ識別子及び／又は長期公開キーＬＴＰＫＡを通信することもできる。その後は、除去されたコントローラは、もはやアクセサリ１９０４とペア検証プロセスを実行することが不可能となり、このことは、除去されたコントローラが、アクセサリ１９０４と対話することが不可能となる結果をもたらし得る。プロセス１９００を介して除去されたコントローラは、その後に、ペア追加プロセス１８００を介して再び追加することができる。一部の実施形態は、アクセサリ１９０４が、除去されたコントローラを「ブラックリストに載せる」選択肢を提供することができ、このことにより、除去されたコントローラがアクセサリ１９０４とペアリングを確立することを防ぐことができる。例えば、コントローラ１９０２からのペア除去要求は、除去されたコントローラをブラックリストに載せるべきか否かに関する、指標を含み得るものであり、アクセサリ１９０４は、ブラックリストに載せられたコントローラのリストを、永続的に記憶することができる。ペア設定又はペア追加の間に、アクセサリ１９０４は、このブラックリストを確認することができ、ブラックリスト上にコントローラが存在する場合には、エラーを返すことができる。
【０３２０】
プロセス１９００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。例えば、コントローラがアクセサリにメッセージを送信するたびに、又はその逆の場合も同様に（例えば、ペアリングプロセスの状態が変化する場合に）、エラーが検出される場合がある。一部のエラー条件が示されているが、いずれかの時点でエラーが検出された場合には、プロセス１９００は終了することができ、コントローラは、そのエラーをユーザに通知することができる点を理解されたい。更には、具体的な暗号化及び／又は認証アルゴリズムへの言及は、例示を目的とするものであり、安全なデータの交換のための、他のパスワードプロトコル及びアルゴリズムで置き換えることもできる。一部の実施形態では、ペア除去プロセス１９００は、以下で説明されるような、委譲ペアリングに関連して使用することができる。
【０３２１】
上述の実施形態は、アクセサリ及びコントローラが、ペアリングを作成（設定）、検証、追加、及び除去することを可能にするものであり、ペアリングは、そのペアリングでの各パートナーデバイスによる、他方のパートナーデバイスの長期公開キー及び／又は証明書の永続的記憶を含み得る。
【０３２２】
一部の実施形態では、ユーザが、所定のアクセサリとペアリングされたコントローラのリスト、又は所定のコントローラとペアリングされたアクセサリのリストを取得することが有用であり得る。後者（コントローラとペアリングされたアクセサリ）の場合には、コントローラ上で実行されるプログラム（例えば、オペレーティングシステム又はアプリケーションプログラム）が、そのコントローラの記憶されたペアリング情報を読み取ることによってリストを生成することができ、そのコントローラ自体のユーザインタフェース上で、そのリストをユーザに提示することができる。所定のアクセサリとペアリングされたコントローラのリストを提供するために、特定の実施形態は、コントローラが、アクセサリから、全てのペアリング済みコントローラのリストを取得することを可能にし、次いで、コントローラは、そのリストをユーザに提示することができる。
【０３２３】
例えば、図１２に示されるように、アクセサリは、そのペアリングプロファイルの一部として、Ｐａｉｒｉｎｇ  Ｌｉｓｔ特性１２０４を有し得る。特性１２０４は、そのアクセサリとの確立済みペアリングを有する、各コントローラについての情報（例えば、コントローラＩＤなど）を含み得るが、いずれのコントローラの長期公開キーも含む必要はない。一部の実施形態では、コントローラは、任意の他の特性と同様に、例えばＨＴＴＰ  ＧＥＴ要求などを使用して、Ｐａｉｒｉｎｇ  Ｌｉｓｔ特性１２０４を読み取ることができる。一部の実施形態では、コントローラは、アクセサリの／ｐａｉｒｉｎｇｓのＵＲＬ（又は、他の適切なＵＲＬ）に、ＨＴＴＰ  ＰＯＳＴ要求を送信することによって、アクセサリのペアリングリストを取得することができ、このＰＯＳＴ要求は、ペアリングリストが要求されていることを示す項目を含み得る。
【０３２４】
一部の実施形態では、コントローラは、アクセサリ応答を暗号化することができるように、ペア検証済みセッション内でのみ、Ｐａｉｒｉｎｇ  Ｌｉｓｔ１２０４を読み取ることを許容される場合がある。更には、一部の実施形態では、Ｐａｉｒｉｎｇ  Ｌｉｓｔ１２０４の読み取りは、管理者許可を有するコントローラに限定することができる。
【０３２５】
一部の実施形態では、アクセサリは、一度に１つのコントローラとのみ、ペアリングを確立することができ、ペアリングを確立するコントローラのみが、そのペアリングを後に除去することを許可される。このことにより、セキュリティを向上させることができる。しかしながら、一部の用途では、不都合な方式で制限的となる恐れがある。例えば、家庭環境１００（図１）の場合では、その家庭内に複数の人々が居住している場合には、各自が、ドアロック１０４をロック解除することが可能なコントローラ１０２（例えば、携帯電話）を有することが望ましい場合がある。
【０３２６】
したがって、本発明の特定の実施形態は、複数のコントローラとのペアリングを、アクセサリが同時に維持することを可能にし得る。例えば、各コントローラは、上述のペア設定プロセスを使用して、別個にペアリングを確立することができる。しかしながら、コントローラが独立してペアリングを確立することを可能にすることは、一部の用途に関しては、セキュリティが不十分となる恐れがある。例えば、家庭の玄関ドアのロックの場合には、家の所有者は、その家の所有者の明示的な許可なくして、他人がペアリングを確立することを、防止することを望む場合がある。
【０３２７】
管理されたペアリングを可能にするために、特定の実施形態は、「委譲」ペアリングプロセスを提供することができる。委譲ペアリングプロセスでは、第１の（「アドミン」又は「マスタ」）コントローラが、例えば上述のようなペア設定を使用して、アクセサリとペアリングを確立することにより、管理者許可を取得することができる。その後は、アドミンコントローラは、任意の後続の（「委譲」）コントローラに関するペア設定プロセスに参加することを、要求される場合がある。
【０３２８】
委譲ペアリングの１つのタイプは、「直接的」委譲とすることができる。直接的委譲では、マスタコントローラは、図１８Ａ〜図１８Ｂのペア追加プロセス１８００又は同様のプロセスを使用して、委譲コントローラに関するコントローラ公開キー（及び、コントローラのユーザ名）を、アクセサリに配信することができる。直接的委譲に関しては、マスタコントローラは、委譲コントローラと通信して、その委譲コントローラの長期公開キーを取得することができる。
【０３２９】
委譲ペアリングの別のタイプは、「外部」又は「転送」委譲とすることができる。外部委譲では、アクセサリは、ペア設定及びペア検証を「認可者」デバイスに委譲するように構成することができ、この認可者デバイスは、マスタコントローラ内に、又はマスタコントローラと通信することが可能な何らかの他のデバイス内に組み込むことができる。認可者デバイスは、上述のようにアクセサリとペア設定を実行することができ、ペア設定の後、その認可者は、アクセサリへの安全なチャネルを維持する（又は、ペア検証を使用して再確立する）ことができる。アクセサリが、ペア設定又はペア検証要求を受信した場合には、アクセサリは、その安全なチャネルを介して、その要求を認可者に転送することができる。認可者は、その動作を実行することができ、かつ／又は、その動作を許容するべきか否かをアクセサリに示すことができる。
【０３３０】
委譲ペアリングの第３のタイプは、「証明書ベースの」委譲とすることができる。証明書ベースの委譲では、マスタコントローラは、信頼証明書チェーンを使用して、アクセサリを構成することができる。例えば、マスタコントローラは、図１８Ａ〜図１８Ｂのペア追加プロセス１８００、又は同様のプロセスを使用して、アクセサリに、信頼証明書チェーンを安全に配信することができる。例えば、コントローラがアクセサリに送信する、「証明書チェーン設定要求」メッセージを定義することができる（このメッセージは、例えば、証明書チェーンを受信するために定義された特性又はＵＲＬへの、ＨＴＴＰ  ＰＵＴ要求とすることができる）。この要求メッセージのコンテンツは、例えばルートから最深までのサブ権限の順序で証明書チェーンを含む、ＴＬＶ項目又は一連のＴＬＶ項目を含み得る。このＴＬＶ項目（単数又は複数）は、ペア検証の間に確立された対称キーで暗号化することができ、マスタコントローラの長期秘密キーＬＴＳＫＣを使用して、デジタル署名することができる。アクセサリは、記憶されたＬＴＰＫＣを使用して、その署名を検証し、対称キーを使用して、暗号化されたＴＬＶ項目（単数又は複数）を復号することにより、証明書チェーンを抽出することができる。一部の実施形態では、この証明書チェーンは、アクセサリのセキュア記憶要素内に記憶させることができる。アクセサリは、成功又は失敗を示す応答メッセージを送信することができる。
【０３３１】
別のコントローラが、そのアクセサリとペア設定を実行することを試みる場合、そのコントローラには、その長期公開キーに加えて、又はその代わりに、証明書を提供するように要求することができる。アクセサリは、その証明書が、以前に受信した信頼証明書チェーンによって署名されているか否かを判定することができ、その証明書がそのように署名されているか否かに部分的に基づいて、ペア設定を受理するか、又は拒絶することができる。委譲コントローラは、何らかの他のチャネルを介して（例えば、マスタコントローラ、信頼される認証局などから）、適切に署名された証明書を取得し、それをアクセサリに提示することによって、そのアクセサリに関して認可されることが可能となる。
【０３３２】
本明細書で説明されるペアリングプロセス及びアーキテクチャは、例示的なものであり、変型及び修正が可能であることが、当業者には理解されるであろう。異なる暗号化アルゴリズム、キー、及びプロトコルで置き換えることができ、複数の異なる暗号化アルゴリズム、キー、及びプロトコルを、所定の動作環境内で同時にサポートすることができる。
例示的アクセサリ：ドアロック
【０３３３】
本発明の実施形態に存在し得る様々な態様及び特徴を更に示すために、ここで具体的なアクセサリの実施例を説明する。
【０３３４】
第１の実施例は、ドアロックアクセサリであり、このドアロックアクセサリは、ドアに設置することが可能なドアロックに結合される、電子ロックユニットを含み得る。一部の実施形態では、ドアロック自体は、機械式ロック（例えば、デッドボルトタイプ）とすることができ、電子ロックユニットが、電気機械式アクチュエータを動作させることにより、ロック位置とロック解除位置との間で、この機械式ロックを移動させることができる。機械式ロックが現時点でロック位置又はロック解除位置のいずれにあるかを、電子ロックユニットが判定することを可能にするために、位置センサなどもまた提供することができる。他の実施形態では、他のタイプのドアロック、例えば、磁気ロック、電子ロック、並びに、電気制御信号を供給し、かつ／又は機械的な力を適用することによって、ロック及びロック解除することが可能な、任意の他のタイプのロックを使用することができる。電子ロックユニットは、上述のような統一的アクセサリプロトコルを実施する論理回路、及び１つ以上のコントローラと通信する通信回路を収容するか、若しくはそれらの回路に接続することができる。電子ロックユニットは、電気信号（例えば、１つ以上のワイヤ上の電圧又は電流レベル）を生成することにより、例えば電気機械式アクチュエータなどを介して、ドアロックを動作させることができる。一部の実施形態では、電子ロックユニット及びドアロックは、ドアに取り付けられるか、又はドア若しくはドアフレームの内側に取り付けられるモジュールなどの、共通の筐体の内部に物理的に配置することができる。他の実施形態では、電子ロックユニット及びドアロックは、別個の筐体内に存在し得る。例えばドアロックは、ドアの内側に存在し得るが、その一方で、電子ロックユニットは、近傍の壁面上に取り付けられる。ドアロック内のアクチュエータと電子ロックユニットとの間の、有線接続を提供することができる。無線接続もまた、本発明の範囲から逸脱することなく使用することができるが、このコンテキストでの無線接続は、更なるセキュリティ上の問題を生じさせる恐れがあることが、当業者には理解されるであろう。
【０３３５】
図２０を参照すると、本発明の実施形態による、ドアロックアクセサリ２００４に関する動作環境２０００が示されている。動作環境２０００は、例えば、オフィスビル、家庭、アパート若しくはホテルの建物、又は、少なくとも１つの室内ドア若しくは外部ドア２００６を有する任意の他の構造体内に、実装することができる。例示の目的上、ドア２００６をロック及びロック解除する能力は、複数の個人に提供されることが望ましいと想定される。ドア２００６は、「所有者」（すなわち、ドア２００６を通過することを誰が許容されるべきか又は許容されないべきかを判定する権限を、法的に又は合意によって与えられている、何らかの人物若しくはエンティティ）を有することが、更に想定される。例えば、環境２０００が、オフィスビル内に実装される場合には、そのビルの所有者（又は、その所有者の認可を得て行為するテナント）を、ドア２００６の所有者とすることができる。環境２０００が、家庭内に実装される場合には、その所有者は、家の所有者、世帯主、又は、居住者によって指定される他の個人とすることができる。
【０３３６】
この実施例では、ドアロックアクセサリ２００４は、１つ以上のユーザ操作コントローラ２０１２（３つが示されているが、任意の数を使用することが可能）と無線通信するように構成することができる。例えば、ドアロックアクセサリ２００４は、コントローラ２０１２のうちの１つに対する物理的近接性によってトリガされることにより、通信を開始させることが可能な、センサ２０２０を提供することができる。ドアロックアクセサリ２００４はまた、マスタコントローラ（管理者とも称されるもの）２０１８と通信することもできる。この実施例では、マスタコントローラ２０１８との通信は、無線接続によるものであるが、有線接続もまた使用することができる。
【０３３７】
マスタコントローラ２０１８は、デスクトップコンピュータ、ラップトップコンピュータ、携帯電話、タブレットなどを含めた、ドア２００６の所有者によって所有又は操作されるコンピューティングデバイスとすることができる。オフィスビルの場合には、マスタコントローラ２０１８を操作する人物を、指定のセキュリティ担当者とすることができる。マスタコントローラ２０１８は、ドア２００６に対して任意の場所に、物理的に配置することができる。例えば、マスタコントローラ２０１８は、ドア２００６がアクセスを提供する部屋の中、この建物内の他の場所に配置された警備室の中、又は全く別の建物内に存在し得る。一部の実施形態では、マスタコントローラ２０１８はまた、ユーザデバイス（例えば、携帯電話）としての役割も果たし得る。
【０３３８】
ドアロックアクセサリ２００４の設置に続けて、マスタコントローラ２０１８は、上述のようなペア設定プロセスを実行することにより、それ自体をマスタコントローラとして確立することができ、例えば、マスタコントローラ２０１８は、ペア設定の実行の結果として（例えば、上述のような）管理者許可を取得することができる。その後は、委譲ペアリング技術（例えば、上述のようなペア追加）を使用することにより、ドアロックアクセサリ２００４と、ユーザデバイス２０１２のそれぞれとの間に、ペアリングを確立することができる。あるいは、ドアロックアクセサリ２００４は、特定の物理的条件下（例えば、アクセサリ２００４内にキーが物理的に挿入される）でのみ、ペア設定を実行することができるように構成することができ、ドアロックアクセサリ２００４は、ペアリングに関する物理的条件が取得された場合に、一度にユーザデバイス２０１２のそれぞれと、ペア設定を実行することができる。
【０３３９】
一部の実施形態では、ドアロックアクセサリ２００４に関するアクセサリモデルは、ドアをロック及びロック解除する能力を提供する、ロックメカニズムサービス（例えば、図２ＧのＬｏｃｋ  Ｍｅｃｈａｎｉｓｍサービス２５４のインスタンス）を含み得る。ドアロックアクセサリ２００４に関するアクセサリモデルはまた、ロック管理サービス（例えば、図２ＨのＬｏｃｋ  Ｍａｎａｇｅｍｅｎｔサービス２５５のインスタンス）も含み得るものであり、このロック管理サービスは、いつ誰がドアをロック又はロック解除したかを示す入力を有する、ロックログを保持することなどの、他のロック関連機能をサポートすることができる。このロックログは、例えばマスタコントローラ２０１８によってアクセスすることができる。
【０３４０】
図２１は、本発明の実施形態による、ドアロックアクセサリ２００４に関するアクセサリオブジェクト２１００の実施例を示す。オブジェクト２１００は、表の形態で示されているが、図３Ａ〜図３Ｃと同様のＪＳＯＮオブジェクトとして表すこともできる。図示のように、ドアロックアクセサリ２００４は、アクセサリ識別サービスインスタンス２１０２、ロックメカニズムサービスインスタンス２１０４、及びロック管理サービスインスタンス２１０６を含み得る。各サービスインスタンスは、図示のような特性を含み得るものであり、これらの特性は、図２Ａ〜図２Ｄ、及び図２Ｊに従って定義することができる。例えば、現在の状態特性２１１０は、そのドアが現在、ロックされているか又はロック解除されているか（又は、故障しているかなど）のいずれであるかを判定するために、コントローラによって読み取ることができ、目標状態特性２１１２は、そのドアのロック又はロック解除を要求するために、コントローラによって書き込むことができる。
【０３４１】
ロックログ特性２１１６は、ロックログイベントレコードのアレイを含み得るものであり、各ロックログイベントレコードは、データオブジェクトとすることができる。この実施例では、各ロックログイベントレコードは、ドアロック２００４にアクセスしたエンティティ（人物又はデバイス）の識別子、そのアクセスが実施された時間、及び実行された動作（例えば、ロック又はロック解除、ロックログの読み取り、ロックログの消去）を含み得る。そのアクセスについての、追加的な供給元固有の情報を提供するために、任意選択的な文字列要素を提供することができる。一部の実施形態では、コントローラは、特性２１１６を読み取ることにより、ロックログにアクセスすることができる。
【０３４２】
ロック管理制御点特性２１１４を使用して、例えば、ロックログの読み取り又は消去の要求を送信することができる。例えば、コントローラは、特性２１１４にデータオブジェクトを書き込む要求を送信することができ、そのデータオブジェクトは、具体的な要求として解釈することができる。この実施例では、サポートされる要求としては、ロックログの読み取り（データオブジェクト内で指定された開始時間から開始）、ロックログの消去（データオブジェクト内で指定されるように、全ての入力、又は指定された範囲の入力を、ロックログから削除することが可能）、及び、ドアロックアクセサリ２００４が将来のロックログ入力を記録するための基準として使用することが可能な、現在時間の設定（この時間の設定は、例えば、サマータイムを考慮に入れるためなどに、有用であり得る）を挙げることができる。図５Ｇ〜図５Ｋを参照して上述したように、一部の実施形態では、ドアロックアクセサリ２００４は、制御点特性２１１４への書き込み要求に、インラインで応答するか、又は問い合わせ結果メカニズムを通じて応答するかを、選択することができる。この決定は、１回の要求ごとのものにすることができる。
【０３４３】
図２１に示される他の特性は、図２Ａ〜図２Ｄ、及び図２Ｊを参照して上述したように動作することができる。
【０３４４】
図２１に示されるサービス及び特性は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。ロックの機能性に応じて、サービス及び特性の他のセット並びにサブセットを、ロックアクセサリに関して定義することができる。
【０３４５】
更なる例示のために、ここで具体的な実施シナリオを説明する。このシナリオでは、ドア２００６の所有者は、ドアロックアクセサリ２００４を購入して、ドア２００６に設置することができる。（ドアロックアクセサリ２００４は、ドア２００６の一部として、又は後付けのアップグレードとして販売することができる。）ドア２００６の所有者は、マスタコントローラ２０１８を、ドアロックアクセサリ２００４と通信するように構成することができる。例えば、マスタコントローラ２０１８は、上述の統一的アクセサリプロトコルに適合するメッセージを送信及び受信する、及び、ドア２００６の所有者がドアロックアクセサリ２００４と対話することを可能にするグラフィカルユーザインタフェース（又は、他のタイプのユーザインタフェース）を生成するプログラム（例えば、オペレーティングシステムプログラム、又はユーザがインストールしたアプリケーションプログラム）を実行することが可能な、デスクトップ又はポータブル（例えば、ラップトップ、ハンドヘルド型、モバイル、ウェアラブル）コンピュータシステムとすることができる。
【０３４６】
この設置を実行した後、ドア２００６の所有者は、マスタコントローラ２０１８を、ドアロックアクセサリ２００４とペアリングさせることができる。図２２は、本発明の実施形態による、ドア２００６の所有者などのユーザが、マスタコントローラ２０１８をドアロックアクセサリ２００４と（又は、任意の他のコントローラを任意の他のアクセサリと）ペアリングさせることが可能な、プロセスのフローチャートである。
【０３４７】
ブロック２２０２で、ドアロックアクセサリ２００４（又は、任意の他のアクセサリ）は、ペアリングモードに入ることができる。一部の実施形態では、ユーザが、アクセサリをペアリングモードにさせることができる。一部の実施形態では、各アクセサリ製造元は、そのアクセサリをペアリングモードにさせる、特定のユーザアクションを定義することができる。例えば、ドアロックアクセサリ２００４の場合には、アクセサリ製造元は、アクセサリ筐体のいずれかの場所に、アクセサリ製造元によって提供されたキーをユーザが挿入する、物理的キーホール又はキースロットを提供することができる。別の実施例として、ドアロックアクセサリ２００４は、その筐体上若しくは筐体の内側に、ペアリングモードを有効化又は無効化する、機械式スイッチを有し得るものであり、このスイッチは、ドア２００６が閉鎖されている場合にアクセス不可能となるように、配置することができる。一般的に、アクセサリをペアリングモードにさせることは、認可ユーザが存在しており、コントローラをアクセサリとペアリングさせることを試みていることを、そのアクセサリに示す、様々なアクションを伴い得るが、しかしながら、アクセサリをペアリングモードにさせる、いずれかの特定の技術の使用は、必須ではない。更には、一部の実施形態では、ドアロックアクセサリ２００４は、最初に設置されて電源投入される際に、又は、いずれのコントローラともペアリングを確立していない場合は常に、自動的にペアリングモードに入ることができる。
【０３４８】
ブロック２２０４で、コントローラは、アクセサリを見つけることができる。例えば、ドアロックアクセサリ２００４及びマスタコントローラ２０１８の場合には、アクセサリ２００４は、ペアリングモードに置かれた場合、例えば上述のようなデバイス発見サービスを使用して、そのペアリングに関する可用性を広告することを開始することができる。マスタコントローラ２０１８は、例えば、図４のアクセサリ発見プロセス４００を、ブロック４２２まで実行することによって、ドアロックアクセサリ２００４の位置を特定することが可能な、統一的コントローラプログラム（又は、他のプログラムコード）を実行することができる。別の実施例として、一部のコントローラは、アクセサリを自動的に（一定の間隔で、又は、ある区域内に入ることなどのイベントに応答して）探索するか、又は、コントローラによって提供された「ＦＩＮＤ」コントロールを作動させることなどのユーザ入力に応答して、アクセサリを探索するように構成することができる。
【０３４９】
ブロック２２０６で、ユーザは、コントローラに、ブロック２２０４で見つけたアクセサリとペアリングするように命令することができる。例えば、上述のように、アクセサリ発見プロセス４００は、コントローラが、アクセサリについての情報をユーザに提示して、ユーザに、ペアリングを実施するべきか否かを示すように促すことを含み得る。別の実施例として、アクセサリ発見を実行するコントローラは、見つけられた全てのアクセサリのリストを、ユーザに提示することができ、ユーザは、そのリストから、ペアリングするアクセサリを選択することができる。このユーザ命令は、様々な形態を取ることができる。一部の場合には、このユーザ命令は、ドアロックアクセサリ２００４の設定コードを入力することを含み得るものであり、他の場合には、この設定コードの入力は、別個のユーザアクションとすることができる。
【０３５０】
ブロック２２０８で、このユーザ命令に応答して、コントローラは、ブロック２２０４で見つけたアクセサリと、ペア設定プロセスを開始することができる。例えば、上述のペア設定プロセス（プロセス１３００、１４００、１５００、１６００）のうちのいずれかを、ブロック２２０８で開始することができる。
【０３５１】
ブロック２２１０で、ペア設定プロセスの間のいずれかの時点で、ユーザは、ペア設定を開始した特定のコントローラとのペアリングを実施するべきであることの検証を、アクセサリに提供することができる。検証が必要とされるか否か、及びいずれの検証が必要とされるかは、アクセサリ製造元によって決定することができる。一部の実施形態では、アクセサリは、そのアクセサリがペアリングモードにあり、コントローラがペアリングを試みているという事実の他には、いかなる追加的検証も必要としない。更には、一部の実施形態では、ブロック２２０６でのユーザ入力（アクセサリ設定コードを含み得るもの）はまた、ブロック２２１０での検証としての役割も果たし得る。アクセサリが検証を必要とする場合、そのような検証は、例えば、アクセサリによって検出可能な何らかのアクションをユーザが実行し、そのアクションが正しく実行されない場合には、コントローラに対するエラー応答をアクセサリが生成するという要件を、ペア設定プロセスに含めることによって、実施することができる。
【０３５２】
例えば、ペアリングプロセス１３００及び１５００は、アクセサリの設定コードをコントローラが有するという、コントローラの証明の形態で、アクセサリに対する検証を含む。上述のように、コントローラは、アクセサリの設定コードをユーザから取得して、その設定コードを、共有シークレットを生成する際に使用することができ、コントローラが、共有シークレットを正しく生成したという事実は、そのコントローラが設定コードを有するという、アクセサリに対する検証となり得る。別の実施例として、コントローラ及びアクセサリの双方が、近距離通信（ＮＦＣ）技術（例えば、ＮＦＣフォーラム（ｈｔｔｐ：／／ｎｆｃ−ｆｏｒｕｍ．ｏｒｇ）によって公布される規格に適合する通信技術）を装備する場合には、アクセサリは、ユーザがＮＦＣ通信範囲内にコントローラを持ち込むことを要求することができ、そのＮＦＣチャネル上のコントローラが、別のチャネル上でペア設定を実行しているコントローラと同じものであることを確認するために、そのコントローラと情報を交換することができる。（例えば、コントローラは、ＮＦＣチャネル及びペア設定チャネルの双方を介して、そのコントローラの共有シークレットの証明（ｐｒｏｏｆＣ）を提供することが、必要とされる場合がある。）他の検証動作で置き換えることができ、単一のユーザアクションにより、ブロック２２０６でのペアリングの命令、及びブロック２２１０での検証の双方を提供することができる。
【０３５３】
ブロック２２１２で、ペア設定プロセスを完了することができ、（エラーが発生していないと想定すると）ユーザに、アクセサリとのペアリングが確立されたことを、（例えば、コントローラによって）通知することができる。その後は、ブロック２２１４で、アクセサリは、ペアリングモードを終了することができる。一部の実施形態では、ペアリングモードを終了することは、アクセサリをペアリングモードから解除する、ユーザアクションを含み得る。そのようなユーザアクションは、物理的キーの除去、ペアリングスイッチの無効化位置への切り替えなどの、アクセサリをペアリングモードにさせるためにブロック２２０２で行われたユーザアクションの反転とすることができる。一部の実施形態では、アクセサリは、ペア設定が完了すると、自動的にペアリングモードを終了することができる。
【０３５４】
図２０を参照すると、環境２０００では、プロセス２２００は、ドア２００６の所有者が、ドアロックアクセサリ２００４とペアリングさせることを望む、各コントローラ２０１２に関して繰り返すことができる。しかしながら、一部の環境では、各コントローラ２０１２を個別にペアリングすることは、不都合な場合がある。例えば、ペアリングが、接近した物理的近接性を必要とする場合には、各コントローラ２０１２を順番に、そのような近接性に持ち込んで、ペアリングさせなければならない。多数のコントローラ２０１２がペアリングされる場合には（例えば、ドア２００６が、多くの居住者を有する大型ビルの玄関ドアである場合には）、このことは、極めて時間を要することになり得る。更には、一部の実施形態では、ドアロックアクセサリ２００４は、第１のコントローラがペアリングの確立に成功した後には、第２のコントローラがペア設定を実行することを、許可しない場合がある。
【０３５５】
したがって、一部の実施形態では、プロセス２２００を使用して、ドアロック２００４と１つのコントローラ（例えば、マスタコントローラ２０１８）との間に、ペアリングを確立することができる。その後に、マスタコントローラ２０１８は、委譲ペアリングプロセス（例えば、ペア追加プロセス１８００、又は上述の他の委譲ペアリングプロセス）を使用して、ドアロック２００４と追加のコントローラ２０１２とのペアリングを確立することができる。例えば、マスタコントローラ２０１８が、特定のコントローラ２０１２に関する長期公開キー（又は、セキュリティ証明書）を有する場合には、マスタコントローラ２０１８は、ペア追加プロセス１８００を使用して、そのキー（又は、証明書）をドアロックアクセサリ２００４に提供することができる。別の実施例として、マスタコントローラ２０１８は、（例えば、上述のような）信頼証明書チェーンを、ドアロックアクセサリ２００４に提供することができ、各コントローラ２０１２は、その信頼証明書チェーンによって署名された証明書を有することが可能であり、この証明書を使用することにより、所定のコントローラ２０１２は、ペアリングを確立してドアロックアクセサリ２００４にアクセスすることが可能となり得る。上述のように、一部の実施形態では、マスタコントローラ２０１８は、任意の追加コントローラ２０１２に、選択的にアドミン許可を付与することができ、アドミン許可を有するコントローラ２０１２は、ペア追加を実行することにより、アクセサリ２００４と追加のコントローラ２０１２との間のペアリングを確立することができる。
【０３５６】
更には、ドア２００６にアクセスすることを認可されたユーザのセットは、経時的に変化し得る。例えば、オフィスビルでは、従業員は辞職する場合があり、その時点で、その従業員のビルへのアクセスは、終了させるべきである。家庭では、同居人が引っ越す場合がある。マスタコントローラ２０１８（又は、管理者許可を有する他のコントローラ）は、例えば、上述のペア除去プロセス１９００を使用して、もはやアクセスを認めるべきではない任意のコントローラ２０１２との、ドアロックアクセサリ２００４のペアリングを除去することによって、そのような更新を実施することができる。
【０３５７】
一部の実施形態では、マスタコントローラ２０１８（又は、ドアロックアクセサリ２００４に関するアドミン許可を有する、他のコントローラ２０１２）上で実行される統一的コントローラプログラムにより、ドア２００６へのアクセスの管理を容易にするための、様々なユーザインタフェースを提供することができる。例えば、所有者又はセキュリティ担当者は、例えば上述のようなリストペアリング要求を使用して、認可済みコントローラのリストを見ることができ（一部の実施形態では、このリストは、認可済みコントローラのユーザを特定することも含み得る）、その認可リストに追加するべき新規コントローラを特定することができ、かつ／又は、その認可リストから除去するべき、認可済みコントローラを選択することができる。それゆえ、組織環境又はマルチユーザ環境内でのセキュリティ動作を、効率化することができる。
【０３５８】
特定のコントローラ２０１２が、ドアロックアクセサリ２００４と（例えば、直接的ペアリング又は委譲ペアリングを含めた、上述の技術のいずれかを使用して）ペアリングを確立すると、そのコントローラ２０１２を使用して、ドア２００６にアクセスすることができる。例えば、コントローラ２０１２には、コントローラ２０１２が上述のような統一的アクセサリプロトコルに適合するメッセージを送信及び受信することを可能にする、プログラムコード（例えば、オペレーティングシステム又はアプリケーションコード）を供給することができる。このプログラムはまた、コントローラ２０１２のユーザがアクセサリと対話することを可能にするための、グラフィカルユーザインタフェース（又は、他のタイプのユーザインタフェース）も定義することができる。
【０３５９】
図２３は、本発明の実施形態による、ドアをロック解除するプロセス２３００のフローチャートである。プロセス２３００は、例えば、図２０の任意のコントローラ２０１２（又は、コントローラ２０１８）とドアロックアクセサリ２００４との間で実行することができる。
【０３６０】
プロセス２３００は、コントローラ２０１２が、ドア２００６をロック解除するべきであることを判定する、ブロック２３０２で開始することができる。例えば、ポータブルコントローラ２０１２を持ち運ぶユーザは、ドアロックアクセサリ２００４の範囲内に進入することができる。「範囲内」とは、無線通信範囲内として、又は必要に応じてより狭いものとして、定義することができる。例えば、不注意によるドアのロック解除を回避するために、コントローラ２０１２及びドアロックアクセサリ２００４は、近接感知能力を有するように（例えば、Ｂｌｕｅｔｏｏｔｈ  ＬＥ、ＮＦＣなどを使用して）構成することができ、コントローラ２０１２は、ドアをロック解除することを試みる、最大範囲（例えば、数インチ、２フィート、６フィート以内、又は何らかの他の範囲内）を定義するように構成することができる。一部の実施形態では、ドアロックアクセサリ２００４が範囲内に存在することを、コントローラ２０１２が検出すると、コントローラ２０１２は、ドア２００６のロック解除をユーザが望んでいることを確認するために、ユーザと対話することができる。例えば、ユーザは、範囲内に進入すると、アプリケーション又はシステムレベルのプログラム（又は、その一部分）を起動するか、若しくは他の方式でアクティブにすることにより、ドアをロック解除することができる。他の実施形態では、コントローラ２０１２は、プロセス２３００の諸部分をバックグラウンドプロセスとして実行することにより、コントローラ２０１２がペアリングを確立したドアロックアクセサリを走査することができ、そのようなアクセサリを範囲内で検出すると、コントローラ２０１２は、ユーザに対するプロンプトを生成することができる。更には、コントローラ２０１２が、ユーザに、ドアをロック解除するべきであることを確認するように促す際、コントローラ２０１２は、コントローラ２０１２が認可ユーザによって持ち運ばれていることを検証するために、認証証明情報（例えば、パスワード、又は、指紋などの生体証明情報）を供給するように、ユーザに要求することができる。更に他の実施形態では、コントローラ２０１２は、ユーザ入力を使用することなく、コントローラ２０１２が、ドアロックアクセサリ２００４の範囲内に進入する場合は常に、ドア２００６のロック解除を自動的に試みるように、構成することができる。他の実装もまた、可能である。具体的な実装は、具体的なドアロックアクセサリ２００４に関して所望される、セキュリティのレベルに応じて変化し得るものであるため、いずれのドアにユーザが接近したかに応じて、同じコントローラが異なる方式で挙動する場合もある。
【０３６１】
更には、他の技術を使用して、ドアをロック解除するべきであることを判定することができ、コントローラ２０１２とドアロックアクセサリ２００４との物理的近接性は、必須のものではない。例えば、ユーザは、コントローラ２０１２上のユーザインタフェースを操作することにより、ドアを選択して、そのドアをロック解除するべきであることを指示することによって、ドア２００６をリモートで（例えば、別の部屋、又は全く別の場所から）ロック解除することが可能となり得る。一部の実施形態では、リモートなロック解除を実行する前に、コントローラ２０１２は、コントローラ２０１２が認可ユーザによって操作されていることを検証するために、認証証明情報（例えば、パスワード、又は、指紋などの生体証明情報）を供給するように、ユーザに要求することができる。
【０３６２】
ブロック２３０６及び２３０８で、コントローラ２０１２及びドアロックアクセサリ２００４は、ペア検証動作（例えば、上述のプロセス１７００）を実行することができる。この動作は、それらの２つのデバイス間でペアリングが以前に確立されたことを、検証することができる。ブロック２３１０で、このペア検証プロセスが成功しなかった場合には、プロセス２３００は、ブロック２３１２で終了することができ、コントローラ２０１２は、ユーザにエラーを警告することができる。一部の実施形態では、ユーザに、再試行するように促すことができる。ペア検証は、コントローラ２０１２が、ドアロックアクセサリ２００４のロック解除を試みるたびに必要とされる場合がある。
【０３６３】
ペア検証プロセスが成功した場合には、ブロック２３１４で、コントローラ２０１２は、ドアを開放するために、ドアロックアクセサリ２００４に、暗号化された要求を送信することができる。例えば、図５Ａ〜図５Ｄを参照して上述されたように、コントローラ２０１２は、ドアロックアクセサリ２００４のロック状態特性２１０２に、ブール値「ｔｒｕｅ」（開放）の値を書き込む、ＨＴＴＰ  ＰＵＴ要求を送信することができる。ペア検証済みセッションでの全ての通信と同様に、この要求は、ペア検証の間に（又は、後に）確立されたセッションキーを使用して暗号化することができる。一部の実施形態では、この要求は、コントローラ２０１２の長期秘密キーで署名することもできるが、このことは必須ではない。
【０３６４】
ブロック２３１６で、ドアロックアクセサリ２００４は、その暗号化された要求を受信することができる。ブロック２３１８で、ドアロックアクセサリ２００４は、その要求を検証して復号することができる。ペア検証済みセッション内での全ての通信と同様に、正しいセッションキーで暗号化されていない場合には、アクセサリは、その要求を無視することができる。更には、その要求が、コントローラの長期秘密キーで署名されていた場合には、アクセサリは、そのアクセサリの（確立済みペアリングに関して永続的に記憶することが可能な）コントローラの長期公開キーのコピーを使用して、その署名を、またそれゆえコントローラのアイデンティティを、検証することができる。アクセサリ２００４はまた、コントローラ２０１２が、ドアをロック解除することを許可されていることも、検証することができる。例えば、一部の実施形態では、特定の時間でのアクセスは、管理者許可を有するコントローラに限定することができる。この制限は、図２Ｄの特性２２８のインスタンスとすることが可能な、アドミン限定アクセス特性２１２２（図２１）に、管理者特権を有するコントローラが書き込むことによって、設定又は解除することができる。他の規則又は決定基準もまた、適用することができる。
【０３６５】
ブロック２３２０で、その要求が有効である場合には（例えば、正しく復号されており、許可されたコントローラからのものである場合には）、ドアロックアクセサリ２００４は、ブロック２３２２でのドアのロック解除に進むことができる。一部の実施形態では、ドアロックアクセサリ２００４は、コントローラ２０１２に、ロック解除を（例えば、ＨＴＴＰ２００  ＯＫ応答を送信することによって）報告することができる。必要に応じて、コントローラ２０１２及び／又はドアロックアクセサリ２００４はまた、成功を示すユーザ感知可能出力も提供することができる。例えば、一方又は双方のデバイスは、ビープ音を鳴らすか、又はクリック音を鳴らすか、緑色ライトを点滅させることなどが可能である。一部の実施形態では、アクセサリのフィードバック挙動は、ロックサービスインスタンス２１０６の定義内に、必要に応じて、Ａｕｄｉｏ  Ｆｅｅｄｂａｃｋ特性２０６（図２Ａ）又は他の特性などの、適切な特性を含めることによって、カスタマイズ可能にさせることができる。
【０３６６】
ブロック２３０２で、その要求が有効ではない場合には、ブロック２３２４で、ドアロックアクセサリ２００４は、コントローラ２０１２に、エラーメッセージを（例えば、ＨＴＴＰエラー応答を送信することによって）送信することができる。一部の実施形態では、コントローラ２０１２は、ユーザにエラーを通知することができ、かつ／又は、再度試行するようにユーザに促すことができる。必要に応じて、コントローラ２０１２及び／又はドアロックアクセサリ２００４はまた、ロック解除の試みが失敗したことを示す、ユーザ感知可能出力も提供することができる。例えば、一方又は双方のデバイスは、エラー音（例えば、成功音とは異なるビープ音）を鳴らすこと、赤色ライトを点滅させることなどが可能である。
【０３６７】
プロセス２３００は例示的なものであり、変型及び修正が可能であることが理解されるであろう。逐次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。プロセス２３００は、以前に確立されたペアリングの存在に依存するものであるが、そのペアリングが確立された方式（例えば、証明書ベース又は設定コードベース、直接的又は委譲）とは無関係であり得る点に留意されたい。それゆえ、この実施例でのアクセサリ及びコントローラは、それらが確立済みペアリングを有することを知る必要があるが、そのペアリングが、いつどのようにして確立されたかを知る必要はない。
【０３６８】
更には、プロセス２３００は、ドアをロックする特定のコンテキストでの、コントローラとアクセサリとの間の対話を示すものであるが、本開示を入手可能な当業者には、同様のプロセスを、任意のアクセサリの任意の動作を制御するために実施することができる点が、認識されるであろう。
【０３６９】
一部の実施形態では、ドアロックアクセサリ２００４は、ドアをロックする明示的な命令が（例えば、プロセス２３００と同様のプロセスを介して）受信されるまで、ドア２００６をロック解除したまま放置することができる。他の実施形態では、ドアロックアクセサリ２００４は自動的再ロック時間間隔を適用することができる。例えばブロック２３２２でドア２００６をロック解除した後、アクセサリ２００４は一定の期間（例えば、１０秒）待機してから、再ロックすることができる。ブロック２３２２でロック解除した後、ユーザが速やかに（例えば、５秒以内に）開放しない場合には、ドア２００６を自動的に再ロックすることなどの、他のセキュリティ対策もまた実装することができる。自動的再ロック挙動は、例えばオートタイムアウト特性インスタンス２１２４（図２１）に、非ゼロ値を書き込むことによって実施することができる。
【０３７０】
一部の実施形態では、ドアロックアクセサリ２００４は、ドアをロック解除する前に、更なる条件又はユーザアクションを必要とする場合がある。例えば上述のように、ドアロックアクセサリ２００４は、ＮＦＣトランシーバを組み込むことができ、ドアロックアクセサリ２００４は、ロック解除の前に、コントローラ２０１２がＮＦＣ範囲内に持ち込まれることを必要とし得る。又は、ドアロックアクセサリ２００４は、ユーザがいつドアに接触しているかを検出する、センサを有し得るものであり、ロック解除要求が有効であることをアクセサリが判定した後、ドアが速やかに（例えば、２秒又は５秒以内に）接触されない場合には、ロック解除することを拒絶することができる。
【０３７１】
別の実施例として、一部の実施形態では、ドアロック（又は、任意の他のアクセサリ）の製造元又は供給元は、コントローラとアクセサリとの間で交換される「データブロブ」の使用によって、製造元固有の挙動を組み込むことを選択することができる。本明細書で使用するとき、「データブロブ」とは、コントローラによって記憶することが可能であり（例えば、図２０のコントローラ２０１２のそれぞれ及びマスタデバイス２０１８は、データブロブを記憶することが可能）、アクセサリに、そのアクセサリへの任意の要求の一部として送信するか、又は特定の要求（例えば、特定の特性に書き込む要求）と共に選択的に送信することが可能なデータのブロックを指す。コントローラの観点からは、このデータブロブは、不透明とすることができ、データブロブを受信するアクセサリは、アクセサリ固有の方式でそのコンテンツを解釈することができる。
【０３７２】
例示として、ドアロックアクセサリ２００４の場合には、製造元は、ドアロックアクセサリ２００４のユーザに、そのロックの認可ユーザとして登録するように要求することができる。例えば、製造元は、ウェブサイトをサポートするサーバを提供することができ、このウェブサイトで、ユーザは、そのロックに関する認可コードを（例えば、そのサーバにアカウントを作成することによって）取得することができる。認可ブロック（認可コードと、アクセサリ製造元によって所望される任意の追加的情報とを含む、データオブジェクトとすることが可能なもの）を、サーバによって生成して、ユーザのコントローラ２０１２に配信することができる。コントローラ２０１２は、この認可ブロックを、アクセサリ２００４に関連付けられたデータブロブとして記憶することができる。コントローラ２０１２が、その後、アクセサリ２００４に要求を送信する際に、コントローラ２０１２は、その要求内に、記憶されたデータブロブを含めることができる。
【０３７３】
一部の実施形態では、データブロブの送信は、要求の性質に応じて変化し得る。例えば、アクセサリ定義レコードは、（例えば、図３Ａ〜図３Ｃに示されるような）特性を定義することができ、この特性には、その特性に関してコントローラが有する許可が含まれる。一部の実施形態では、特性にアクセスするためにデータブロブが必要とされることを示すように、許可文字列（例えば、「Ｂｌｏｂ  Ｒｅｑｕｉｒｅｄ」）を定義することができ、アクセサリ製造元は、データブロブを受信することがアクセサリ製造元によって所望される、任意の特性に関する許可の定義内に、この文字列を含めることができる。特定の特性への要求を生成する際、コントローラ２０１２は、アクセサリ定義レコード（そのコントローラがキャッシュすることが可能なもの）から、それらの許可を参照することにより、データブロブが必要とされるか否かを判定することができ、必要とされる場合には、コントローラ２０１２は、その要求にデータブロブを付加することができる。他の実施形態では、データブロブを送信するか否かの決定は、アクセサリごとのレベルで実施することができる（例えば、コントローラが、特定のアクセサリに関して記憶されたデータブロブを有する場合には、コントローラは、そのアクセサリに送信する全ての要求に、データブロブを付加することができる）。
例示的アクセサリ：ＩＰカメラ
【０３７４】
本発明の様々な実施形態に従って制御することが可能なアクセサリの第２の実施例は、ＩＰカメラアクセサリである。ＩＰカメラアクセサリは、ビデオ画像を（音声の有無に関わりなく）キャプチャし、キャプチャされたメディア（音声及び／又はビデオ）を他のデバイスにストリーミングすることが可能な、カメラを含み得る。一部の場合には、ＩＰカメラはまた、録画すること、及び／又は以前に録画されたコンテンツの再生などの、他の機能性も提供することができる。本明細書で説明されるような、統一的アクセサリプロトコルを使用する任意の他のアクセサリと同様に、これらの機能性は、サービスとしてモデル化することができ、それらの様々なサービスの特性インスタンスの読み取り及び書き込みによって制御することができる。
【０３７５】
上述の統一的アクセサリプロトコルの実施形態では、コントローラとアクセサリとの間の通信は、ＨＴＴＰ要求及びＨＴＴＰ応答を使用して実施することができる。ＩＰカメラの場合には、ＨＴＴＰ要求及びＨＴＴＰ応答を使用することにより、カメラを設定してその挙動を制御すること（例えば、カメラの照準を合わせること、録画を開始及び停止することなど）ができるが、しかしながら、ＨＴＴＰは、デバイス間でのリアルタイムのメディアコンテンツのストリーミングには、あまり適していない恐れがある。したがって、本明細書で説明されるＩＰカメラの実施形態では、ＩＰカメラ及びコントローラは、メディアセキュリティのために使用するＳＲＴＰプロトコル（例えば、ＩＥＴＦ  ＲＦＣ３７１１で定義されるようなもの）と共に、ＲＴＰプロトコル（例えば、ＩＥＴＦ  ＲＦＣ３５５０で定義されるようなもの）などの、異なるプロトコルを使用することができる。明らかとなるように、他のメディアストリーミングプロトコルで置き換えることもできる。この統一的アクセサリプロトコルは、ストリーミングプロトコルをサポートするストリーミングセッション（統一的アクセサリプロトコルに従って定義されたペア検証済みセッションとは、別個のものとすることが可能なもの）を確立するために使用可能な特性を定義することができ、ストリーミングされるコンテンツの配信は、そのストリーミングセッションを介して実施することができる。
【０３７６】
図２４を参照すると、本発明の実施形態による、ＩＰカメラアクセサリ２４０４に関する動作環境２４００が示されている。この実施例では、ＩＰカメラアクセサリ２４０４は、例えば無線アクセスポイント２４０６を介して、コントローラ２４０２と通信することができる。直接通信もまた、サポートすることができる。ＩＰカメラアクセサリ２４０４は、ある区域内に恒久的又は取り外し可能に設置される器具（例えば、建物内の部屋、廊下、若しくは出入り口内に設置される、防犯カメラ又は監視カメラ）とすることができ、又は、多種多様な設定でビデオをキャプチャするために使用することが可能な、ポータブルカメラとすることもできる。コントローラ２４０２は、ＩＰカメラ２４０４を制御する任意のデバイスとすることができる。例えば、ＩＰカメラ２４０４は、建物用の防犯カメラとして使用され、コントローラ２４０２は、その建物内のセキュリティ局に実装することができる。別の実施例として、ＩＰカメラ２４０４は、例えばベビーモニタとして子供の部屋内に設置することができ、コントローラ２４０２は、親の携帯電話、タブレット、又は親が一般的に持ち運ぶ他のデバイスとすることができる。更に別の実施例として、ユーザは、公園又は鳥獣保護区にＩＰカメラ２４０４を持ち出して、目立たない場所に設置し、次いで、リモートな場所に退却して、コントローラ２４０２を使用してＩＰカメラ２４０４を制御することにより、野生動物などの良質なビデオを得る可能性を高めることができる。それゆえＩＰカメラ２４０４の使用は、いずれかの特定の環境、又はいずれかの特定のコントローラに限定されるものではない。
【０３７７】
本明細書で説明される他のアクセサリと同様に、ＩＰカメラアクセサリ２４０２は、サービスの集合としてモデル化することができる。図２５Ａ、図２５Ｂは、本発明の実施形態による、ＩＰカメラアクセサリ２４０２に関するアクセサリモデル内に含めることが可能なサービス２５０１〜２５０５に関する例示的定義を示す。上記の図２Ｇ、図２Ｈに示されるサービス定義の実施例と同様に、サービス定義２５０１〜２５０５は、必須特性及び／又は任意選択特性を指定することができる。図２６Ａ〜図２６Ｅは、図２５Ａ、図２５Ｂのサービスの特性に関する例示的定義を示す。図２６Ａ〜図２６Ｅには提供されていない、図２５Ａ、図２５Ｂに列挙された特性に関する例示的定義は、図２Ａ〜図２Ｄ内に見出すことができる。これらのサービス及び／又は特性のうちのいずれも、コアサービス及びコア特性として定義することができ、そうではない場合には、拡張サービス及び拡張特性として定義することができる。
【０３７８】
図２５Ａを参照すると、ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１は、メディアセッションを管理するために使用されるリアルタイム通信サービスを説明することができる。例えば、ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１は、例えば以下で説明されるように、コントローラ２４０２とＩＰカメラアクセサリ２４０４との間のメディアストリームの設定及び制御を容易にする特性を含み得る。
【０３７９】
Ｒｅｃｏｒｄｉｎｇサービス２５０２は、録画デバイスを制御するために、例えば、録画を開始、停止、又はスケジュールするために使用される、サービスを説明することができる。同様に、Ｐｌａｙｂａｃｋサービス２５０３は、アクセサリによって、記憶されたメディアの再生を制御するために、例えば、再生の開始及び一旦停止のために使用される、サービスを説明することができる。この実施例では示されないが、Ｐｌａｙｂａｃｋサービス２５０３の一部として、又は別個のコンテンツ選択サービスとして、記憶されたメディアアイテムを再生するように選択するための、更なる特性を定義することができる点が、当業者には認識されるであろう。
【０３８０】
図２５Ｂを参照すると、Ｃａｍｅｒａサービス２５０４は、カメラをオン又はオフにすることなどの、カメラ設定の制御を提供することができる。一部の実施形態では、カメラ方向付け特性（例えば、パン、チルト、ズーム、回転）などの、カメラ設定に関連する他の特性を、任意選択特性として、このサービス内に含めることができる。他の任意選択特性としては、暗視（オン又はオフ）及びミラーモード（キャプチャした画像のミラーリングの有効化又は無効化）などの、画像処理特性を挙げることができる。特定のカメラアクセサリが提供する、任意のユーザ選択可能設定は、Ｃａｍｅｒａサービス２５０４内に定義されて含められる、対応する特性を有し得る。
【０３８１】
Ｍｉｃｒｏｐｈｏｎｅサービス２５０５は、音を記録するように動作可能なマイクロホンの、制御を提供することができる。サービス２５０５は、マイクロホンを有する任意のカメラアクセサリに関する定義内に含めることができ、マイクロホンを有さない任意のカメラアクセサリに関しては、省略することができる。
【０３８２】
Ｓｐｅａｋｅｒサービス２５０６は、音を出力するように動作可能なスピーカに対する制御を提供することができる。サービス２５０６は、スピーカ出力を有する任意のカメラアクセサリに関する定義内に含めることができ、スピーカ出力を有さない任意のカメラアクセサリに関しては省略することができる。
【０３８３】
図２６Ａ、図２６Ｂを参照すると、ＩＰカメラの管理に関して有用な特性は、Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ特性２６０１、Ｓｅｓｓｉｏｎ  Ｅｎｄ特性２６０２、及び追加的特性２６０３〜２６１５を含み得る。（図２６Ａに示される）Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ特性２６０１及びＳｅｓｓｉｏｎ  Ｅｎｄ特性２６０２には、ストリーミングセッションを開始及び終了させるために、コントローラによって書き込むことができる。追加的特性２６０３〜２６１５は、ＩＰカメラのビデオストリーミング及び／又は音声ストリーミングのプロパティについての情報を取得するために、コントローラによって読み取ることができる。
【０３８４】
Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ特性２６０１は、ストリーミングセッションを開始するために、コントローラが、ＩＰカメラアクセサリによって使用可能な情報を提供するために書き込むことが可能な、（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトを値として有し得る。図２６Ｃは、Ｓｅｓｓｉｏｎ  Ｓｔａｒｔ特性２６０１内に含めることが可能な、データ要素の実施例を示す。セッションＩＤ２６３１は、開始されるストリーミングセッションに関するＵＵＩＤとすることができる。コントローラＩＰアドレス２６３２及びコントローラポート２６３３は、ストリーミングされるデータを（例えば、ＩＰｖ４又はＩＰｖ６フォーマットを使用して）送信するべき宛先を特定することができる。コントローラＳＲＴＰマスタキー２６３４及びコントローラＳＲＴＰマスタソルト２６３５は、そのセッション内でストリーミングされるメディアを暗号化するために使用されることになる、ソルト及びマスタ暗号キーを提供することができる。ビデオ最大帯域幅２６３６及び音声最大帯域幅２６３７は、ストリーミングデータ帯域幅の上限値を（例えば、キロビット毎秒（ｋｂｐｓ）の単位で）示すことができる。
【０３８５】
再び図２６Ａを参照すると、Ｓｅｓｓｉｏｎ  Ｅｎｄ特性２６０２は、終了させるセッションのセッション識別子を提供する、（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトを値として有し得る。一部の実施形態では、セッションを終了するために他の情報は必要とされない。
【０３８６】
Ｖｉｄｅｏ  Ｃｏｄｅｃ  Ｎａｍｅ２６０３は、ＩＰカメラサービスインスタンスのビデオコーデックによって提供されるメディアのタイプを表す、文字列を提供することができる。一部の実施形態では、その文字列に関する有効値のセット（例えば、ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇを介してアクセス可能なＩＡＮＡ（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）によって定義される、コーデック名のセット）を定義することができる。一部の実施形態では、ＩＰカメラサービス２５０１の所定のインスタンスは、１つのコーデック（例えば、ＩＥＴＦ  ＲＦＣ６１８４で定義されるようなＨ．２６４コーデック）をサポートし、複数のコーデックをサポートするＩＰカメラアクセサリは、ＩＰカメラサービス２５０１の複数のインスタンスを定義することができる。コントローラは、セッションに関する所望のコーデックを、ＩＰカメラサービス２５０１の、対応するインスタンスのセッション開始特性に書き込むことによって選択することができる。
【０３８７】
Ｖｉｄｅｏ  Ｃｏｄｅｃ  Ｐａｒａｍｅｔｅｒｓ２６０４は、ビデオコーデックに関する追加的パラメータを提供することができる。含まれる具体的なパラメータは、Ｖｉｄｅｏ  Ｃｏｄｅｃ  Ｎａｍｅ２６０３に応じて変化し得るものであり、キー−値フォーマットで表現することができる。例えば、Ｈ．２６４コーデックの場合には、Ｖｉｄｅｏ  Ｃｏｄｅｃ  Ｐａｒａｍｅｔｅｒｓ２６０４は、Ｈ．２６４コーデックのサブプロファイル及びレベルを指定する、プロファイル−レベルＩＤと、そのコーデックが単一のＮＡＬユニットモード又は非インタリーブモードのいずれをサポートするかを指定する、パケット化モードを含み得る。サービスインスタンスによってサポートされる具体的なビデオコーデックに応じて、他のパラメータも定義することができる。
【０３８８】
Ｖｉｄｅｏ  Ａｔｔｒｉｂｕｔｅｓ特性２６０５は、サービス−レベル属性（例えば、ＳＤＰ属性）を提供することができる。例としては、画像属性、及び方向性属性（例えば、送信専用、受信専用、又は双方向性（送信及び受信））が挙げられる）。一部の実施形態では、方向が指定されない場合には、「送信専用」を、デフォルトとして推定することができる。
【０３８９】
ＲＴＰ  Ｖｉｄｅｏ  Ｐａｙｌｏａｄ  Ｔｙｐｅ特性２６０６は、例えば、ＲＴＰに関して指定されるような、７ビット整数ペイロードタイプを提供することができる。
【０３９０】
ＲＴＰ  Ｐｒｏｔｏｃｏｌ特性２６０７は、使用されている具体的なＲＴＰベースのプロファイルを特定する、文字列を提供することができる。例えば、「ＲＴＰ／ＳＡＶＰ」は、ＩＥＴＦ  ＲＦＣ３５５０で定義されるプロファイルを指すことができ、その一方で、「ＲＴＰ／ＳＡＶＰＦ」は、ＩＥＴＦ  ＲＦＣ５１０４で定義されるプロファイルを指すことができる。他のプロファイル及び文字列もまた定義することができる。
【０３９１】
ＲＴＰ  Ｅｘｔｅｎｓｉｏｎｓ特性２６０８は、このＩＰカメラサービス２５０１のインスタンスによってサポートされるＲＴＰ拡張を列挙する、文字列のアレイを提供することができる。ＲＴＰ拡張の実施例としては、ピクチャロス指標、時間空間トレードオフ要求、一時的最大メディアストリーミングビットレートなどを挙げることができる。
【０３９２】
ＳＲＴＰ  Ｃｒｙｐｔｏ  Ｓｕｉｔｅ特性２６０９は、安全なＲＴＰストリーミングのために使用されるべき暗号化スイートを特定する、文字列を提供することができる。一部の実施形態では、この文字列は、暗号化スイートのＩＡＮＡ登録名に適合し得る。一部の実施形態では、ＳＲＴＰ  Ｃｒｙｐｔｏ  Ｓｕｉｔｅ特性２６０９は、ＳＲＴＰが使用されないこと（例えば、ストリーミングされるビデオデータが暗号化されないこと）を「ｎｏｎｅ」の値が示すことを可能にし得る。
【０３９３】
図２６Ｂを参照すると、Ａｕｄｉｏ  Ｃｏｄｅｃ  Ｎａｍｅ特性２６１０は、音声コーデックによって提供されるメディアのタイプを表す、文字列を提供することができる。一部の実施形態では、その文字列に関する有効値のセット（例えば、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙによって定義されるコーデック名のセット）を定義することができる。一部の実施形態では、ＩＰカメラサービス２５０１の所定のインスタンスは、音声コーデックとビデオコーデックとの１つの組み合わせをサポートすることができ、ＩＰカメラアクセサリは、ＩＰカメラサービス２５０１の複数のインスタンスを定義することによって、コーデックの複数の組み合わせをサポートするができる。コントローラは、セッションに関する所望の音声コーデック及びビデオコーデックを、ＩＰカメラサービス２５０１の、対応するインスタンスのセッション開始特性に書き込むことによって選択することができる。
【０３９４】
Ａｕｄｉｏ  Ｃｏｄｅｃ  Ｐａｒａｍｅｔｅｒｓ２６１１は、音声コーデックに関する追加的パラメータを提供することができる。含まれる具体的なパラメータは、Ａｕｄｉｏ  Ｃｏｄｅｃ  Ｎａｍｅ２６１０に応じて変化し得るものであり、キー−値フォーマットで表現することができる。例えば、Ｏｐｕｓコーデックの場合には、音声コーデックパラメータ２６０４は、固定ビットレート又は可変ビットレートのいずれが有効化されるかに関する標識を含み得る。具体的な音声コーデックに応じて、他のパラメータも定義することができる。
【０３９５】
Ａｕｄｉｏ  Ａｔｔｒｉｂｕｔｅｓパラメータ２６１３は、メディア−レベル属性（例えば、ＳＤＰ属性）を提供することができる。例としては、方向性属性（例えば、送信専用、受信専用、又は双方向性（送信及び受信））が挙げられる。一部の実施形態では、方向が指定されない場合には、「送信専用」をデフォルトとして推定することができる。
【０３９６】
ＲＴＰ  Ａｕｄｉｏ  Ｃｌｏｃｋ  Ｒａｔｅ特性２６１４は、例えば、ＲＴＰに関して指定されるような、音声に関するＲＴＰクロックレートを提供することができる。
【０３９７】
ＲＴＰ  Ａｕｄｉｏ  Ｐａｙｌｏａｄ  Ｔｙｐｅ特性２６１５は、例えば、ＲＴＰに関して指定されるような、７ビット整数ペイロード時間を提供することができる。
【０３９８】
様々な実施形態では、メディアのストリーミングに関して、他の特性及びサービスもまた、定義することができる。一部の実施形態では、あらゆるサービスインスタンスで、全ての特性が使用されるわけではない。例えば、音声を受信又はストリーミングしないＩＰカメラアクセサリに関するアクセサリモデルは、特性２６１０〜２６１５を省略することができる。
【０３９９】
図２６Ｄは、本発明の実施形態による、カメラサービス２５０３の様々な特性２６５１〜２６５６に関する例示的定義を示す。これらの（任意選択的とすることが可能な）特性は、このカメラサービスが、対応する挙動をサポートする場合に、定義することができる。コントローラは、これらの特性に書き込むことにより、カメラの向き及び撮像挙動を制御することができる。例えば、Ｎｉｇｈｔ  Ｖｉｓｉｏｎ特性２６５１は、暗視撮像モードを有効化又は無効化するために使用可能な、ブール値を有し得る。
【０４００】
Ｐａｎ特性２６５２は、カメラのパニングを制御するために使用することができる。例えば、カメラは、水平面内で回転可能とすることができる。このパニングの量は、例えば、中心位置に対する、カメラの最大水平方向回転の百分率として、指定することができる。この中心位置は、ゼロのパン値を有するように定義することができ、Ｐａｎ特性２６５２の正の値は、右側へのパニングを示し、Ｐａｎ特性２６５２の負の値は、左側へのパニングを示す。度数などの他の単位を使用することもできる。
【０４０１】
同様に、Ｔｉｌｔ特性２６５３は、カメラのチルト角度（例えば、水平方向に対する光軸の角度）を制御するために使用することができる。このチルトの量は、例えば、中心位置に対する、カメラの最大チルトの百分率として、指定することができる。この中心位置は、ゼロのチルト値を有するように定義することができ、Ｔｉｌｔ特性２６５３の正の値は、上向きのチルトを示し、Ｔｉｌｔ特性２６５２の負の値は、負のチルトを示す。度数などの他の単位を使用することもできる。
【０４０２】
Ｒｏｔａｔｉｏｎ特性２６５４は、カメラの光軸を中心とする、カメラの回転角度を制御するために使用することができる。この回転の量は、例えば、度数の単位で指定することができる。一部の実施形態では、列挙値を（例えば、右９０度、左９０度、１８０度、及び無回転の回転設定をサポートするために）使用することができる。
【０４０３】
Ｚｏｏｍ特性２６５５は、カメラに関するズーム（又は、拡大）率を指定するために使用することができる。
【０４０４】
Ｍｉｒｒｏｒ特性２６５６は、画像の表示、ストリーミング、又は記憶の前に、その画像にミラーリング変換（例えば、垂直軸を中心とするミラーリング）を施すべきか否かを示すために使用されるブール値とすることができる。
【０４０５】
図２６Ｅは、図２５ＡのＲｅｃｏｒｄｉｎｇサービス２５０２及びＰｌａｙｂａｃｋサービス２５０３内に含めることが可能な、更なる特性の定義を示す。Ｒｅｃｏｒｄｉｎｇ  Ｃｏｎｔｒｏｌ特性２６６１は、録画を開始又は停止するために、コントローラによって書き込むことができる。この値は、実行する動作（例えば、録画の開始、録画の停止、録画のスケジュール）の識別子と、その動作に適切な追加的パラメータ（例えば、録画の持続時間、スケジュールされた録画に関する開始時間及び／又は停止時間など）とを含み得る、（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトとすることができる。Ｒｅｃｏｒｄｉｎｇ  Ｓｔａｔｕｓ特性２６６２は、録画サービスが録画中であるか否かを判定するために、コントローラによって読み取ることができる。この値は、カメラが現在録画中であるか否かの指標を含み得る（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトとすることができ、他の情報もまた、含めることができる（例えば、録画に関するスケジュールされた終了時間、スケジュールされた今後の録画についての情報、録画のための利用可能な記憶スペース及び／又は使用済みの記憶スペースの量など）。
【０４０６】
Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ特性２６６３は、記憶されたメディアコンテンツ（例えば、以前に録画されたコンテンツ）の再生を制御するために、コントローラによって書き込むことができる。この値は、実行する動作（例えば、再生の開始、再生の一時停止、再生の終了など）の識別子を含み得る（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトとすることができる。再生されるコンテンツ項目の識別子などの、追加的パラメータもまた含めることができる。Ｐｌａｙｂａｃｋ  Ｓｔａｔｕｓ特性２６６４は、現在の再生状態を判定するために、コントローラによって読み取ることができる。この値は、再生が進行中であるか否かの指標を含み得る、（例えば、ＴＬＶフォーマット、又は他のキー−値フォーマットの）データオブジェクトとすることができ、他の情報もまた、含めることができる（例えば、再生されているコンテンツ項目の識別子、コンテンツ項目の持続時間、再生位置など）。Ｐｌａｙｂａｃｋ  Ｓｐｅｅｄ特性２６６５は、再生速度を制御するために使用することができ、その値は、１．０の通常再生速度に対する増速率を示す。一部の実施形態では、Ｐｌａｙｂａｃｋ  Ｓｐｅｅｄ特性２６６５に関する有効値は、再生サービス２５０２の具体的なインスタンスがサポートする速度に、制限することができる。
【０４０７】
本明細書で説明されるサービス及び特性は、例示を目的とするものである。他のサービス及び特性もまた、定義することができる。例えば、再生する具体的なコンテンツ項目の特定を容易にするために、利用可能なコンテンツ項目のデータベース又は他のリストを、コントローラがナビゲートする（例えば、閲覧又は検索する）ことを可能にすることが、望ましい場合がある。コントローラによるデータベースのナビゲーションを容易にするために、更なる特性を定義することができる。これらの特性は、必要に応じて、再生サービス２５０２、又は異なるサービス（例えば、コンテンツ閲覧サービス）内に含めることができる。
【０４０８】
図２７Ａ〜図２７Ｄは全体として、本発明の実施形態による、ＩＰカメラアクセサリ２４０２に関するアクセサリオブジェクト２７００を示す。この実施例では、アクセサリオブジェクト２７００は、ＪＳＯＮで表現されており、図３Ａ〜図３Ｃのアクセサリオブジェクト３００と同様の構造である。他のフォーマット及び言語もまた、使用することができる。
【０４０９】
図２７Ａに示されるアクセサリ情報サービスインスタンス２７０２は、上記で定義されたＡｃｃｅｓｓｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎサービスインスタンス２６１と、同様又は同一のものとすることができる。この実施例では、アクセサリオブジェクト２７００は、図２７Ｂ、図２７Ｃに示されるＩＰカメラストリーミングサービス２７０４（図２５Ａのサービス定義２５０１に適合するもの）、図２７Ｄに示されるカメラサービス２７０６（図２５Ｂのサービス定義２５０３に適合するもの）、及び図２７Ｄに示されるマイクロホンサービス２７０８（図２５Ｂのサービス定義２５０４に適合するもの）である、３つの他のサービスのインスタンスを含む。この実施例では、ＩＰカメラアクセサリ２４０２はスピーカを有さず、またローカルでの録画又は再生能力も有さず、その結果として、これらのサービスのインスタンスは定義されない。（本開示を入手可能な当業者には、それらのサービスのインスタンスに関する、適切なアクセサリオブジェクトを構築することが可能となるであろう。）この実施例では、各特性インスタンスの現在の値が、アクセサリオブジェクト２７００内で指定され、書き込み専用の特性に関しては、ヌル値が指定されている。
【０４１０】
図２４のＩＰカメラアクセサリ２４０４及びコントローラ２４０２とのユーザ対話は、上述の対話と同様のものとすることができる。例えば、ユーザは、コントローラ２４０２を操作することにより、所望の挙動を指示することができ、コントローラ２４０２は、その所望の挙動を達成するように、アクセサリ２４０４に要求（例えば、ＨＴＴＰ要求）を送信することができる。図２８は、本発明の実施形態による、対話シナリオを示すプロセス２８００のフローチャートである。
【０４１１】
ブロック２８０２で、ユーザは、ＩＰカメラアクセサリ２４０４を設定することができる。例えば、ユーザは、所望の運用場所及び向きに、カメラを配置するか若しくは取り付けて、電力ケーブルを接続し、アクセサリ２４０４をペアリングモードに（アクセサリ２４０４が自動的にペアリングモードに入らない場合には）させることなどが可能である。ブロック２８０４で、コントローラ２４０２は、ＩＰカメラアクセサリ２４０４を発見することができる。例えば、上述のように、コントローラ２４０２は、図４のプロセス４００のコントローラ実行可能部分を実行することが可能な、アプリケーションプログラムを実行することができる。このアプリケーションは、明示的なユーザ命令に応答して、又はバックグラウンドプロセスとして実行することができ、ユーザには、所望のアクセサリが見つかったことを確認するように、又は、ペアリングするために利用可能なアクセサリのリストから、アクセサリ２４０４を選択するように、促すことができる。ブロック２８０６で、コントローラ２４０２及びＩＰカメラアクセサリ２４０４は、ペア検証済みセッションを確立することができる。例えば、コントローラ２４０２及びＩＰカメラアクセサリ２４０４は、上述のペア設定プロセスのうちのいずれかの後に続けて、上述のようなペア検証プロセスを実行することができる。ペア設定の間の検証要件を、必要に応じて適用することができ、例えば、ドアロックアクセサリ２００４に関連して上述された選択肢のうちの、いずれかを使用することができる。具体的な検証要件は、具体的なＩＰカメラアクセサリの性質又は目的用途に応じて決定することができる。例えば、ビルの防犯カメラは、複数の形態の検証を必要とし得るが、その一方で、一般消費者の「ウェブカメラ」タイプのカメラは、そのカメラがペアリングモードにあること、及び、そのカメラ上のラベルに印刷された設定コードをユーザが入力することのみを必要とし得る。
【０４１２】
ブロック２８０８で、ユーザは、ペアリング済みコントローラ２４０２を使用して、例えば、ＩＰカメラストリーミングサービス２７０４の「ｏｎ」特性（インスタンスＩＤ  ８）に値「ｔｒｕｅ」を書き込む要求を送信することによって、ＩＰカメラアクセサリ２４０４に電源投入することができる。この実施例では、ＩＰカメラアクセサリ２４０４は、そのトランシーバが、ペアリング済みコントローラからの信号を受信することは可能であるが、他のサービス（例えば、アクセサリオブジェクト２７００内に列挙される他のサービス）は電源切断される、低電力モードを有し得る。
【０４１３】
図２５Ａ、図２５Ｂに示されるように、サービス２５０１〜２５０５の種々のサービスは、それぞれ別個の「ｏｎ」特性を有し得る。このことにより、コントローラは、サービスインスタンスを、それらが使用されることになる場合に選択的に電源投入することによって、電力消費を管理することが可能となり得る。一部の実施形態では、１つのサービスの「ｏｎ」特性の変化は、他のサービスに影響を及ぼし得る。例えば、ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１を電源切断することは、全てのビデオストリームの送信を停止する結果をもたらし得るが、Ｍｉｃｒｏｐｈｏｎｅサービス２５０５又はＳｐｅａｋｅｒサービス２５０６の動作を停止する必要はない。ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１は、他のサービスがオフのまま維持されている間にも電源投入することができるが、メディアストリームがアクティブである場合には、そのストリームに関連付けられる、いずれのサービスインスタンスも電源投入されたまま維持されるべきであり、さもなければ、ストリーミングが停止する恐れがある。また、一部の実施形態では、ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１は、新たなセッションに関するストリームのうちの１つに関連付けられたサービスインスタンスが、電源切断された場合には、その新たなセッションが開始されることを許容しない。ＩＰカメラスサービス２５０１を電源切断することにより、全てのメディアセッションを終了させ、他の関連サービスインスタンス（例えば、Ｍｉｃｒｏｐｈｏｎｅサービス２５０６又はＳｐｅａｋｅｒサービス２５０６）を自動的に電源切断することができる。ＩＰカメラスサービス２５０１を電源投入することは、全ての関連サービスインスタンスを電源投入する結果をもたらし得る（それらは、その後に使用されていない場合には、電源切断することができる）が、いずれの以前のメディアセッションも、復旧する必要はない。他の電力管理規則もまた、実装することができる。
【０４１４】
ブロック２８１０で、ユーザは、例えばコントローラ２４０２のユーザインタフェースと対話することによって、ＩＰカメラアクセサリ２４０４からのビデオのストリーミングを開始するように、コントローラ２４０２に命令することができる。例えば、ユーザは、カメラがコントローラ２４０２にビデオをストリーミングするべきであることを、指示することができる（一部の実施形態では、ユーザは、異なる宛先デバイスを指定することができる）。それに応答して、ブロック２８１２で、コントローラ２４０２は、メディアセッションを開始する要求を生成して、ＩＰカメラアクセサリ２４０４に送信することができる。
【０４１５】
一部の実施形態では、このメディアセッション開始要求は、ＩＰカメラアクセサリ２４０４の／ｃｈａｒａｃｔｅｒｉｓｔｉｃｓのＵＲＬへの、ＨＴＴＰ  ＰＵＴ要求として送信することができる。図２７Ａ〜図２７Ｄのアクセサリオブジェクト２７００を使用する実施形態に関して、実施例を図２９に示す。要求メッセージ２９００は、メッセージボディ２９０２を有し得る。メッセージボディ２９０２は、書き込まれることになるインスタンスの、インスタンス識別子２９０４を含み得る（インスタンスＩＤ９は、ＩＰカメラサービスインスタンス２７０４（図２７Ｂ）に関するセッション開始特性に対応する）。値２９０６は、セッションＩＤ、コントローラ２４０２（又は、他の宛先デバイス）に関するＩＰアドレス及びポート、並びにＳＲＴＰストリーミングデータに関して使用される暗号キー及びソルトなどの、コントローラ２４０２とのストリーミングセッションを確立するためにＩＰカメラアクセサリ２４０４によって使用可能な情報を含み得る。
【０４１６】
ブロック２８１４で、ＩＰカメラアクセサリ２４０４は、このメディアセッション開始要求に対する応答を送信することができる。一部の実施形態では、この応答は、ＨＴＴＰ応答として送信することができるメディアセッション開始要求が図２９に示されるようなものである実施形態に関して、実施例を図３０に示す。応答メッセージ３０００は、メッセージボディ３００２を有し得る。メッセージボディ３００２は、値３００４を含み得る。値３００４は、正常終了（例えば、エラーコード０）又は発生した具体的なエラー（例えば、無効なパラメータ、リソースがビジー、アクセス拒否など）を示す値を有し得る、エラーコード３００２を含み得る。エラーがないものと想定すると、値３００４は、アクセサリのＩＰアドレス及びポート、並びにアクセサリのＳＲＴＰ暗号パラメータなどの、ＩＰカメラアクセサリ２４０４とのストリーミングセッションに接続するためにコントローラ２４０２によって使用可能な、追加的情報を提供することができる。
【０４１７】
この実施例では、ＳＲＴＰ暗号パラメータは、セッション開始要求及びセッション開始応答内に含めることができる。これらのパラメータは、平文で送信する必要がないことを理解されたい。要求２９００及び応答３０００が、コントローラ２４０２とアクセサリ２４０４との間のペア検証済みセッション内で交換される実施形態では、これらのパラメータは、（そのペア検証済みセッションのセッションキーを使用して）暗号化された形態で送信されることにより、侵入者に対して防御される。
【０４１８】
これらの要求及び応答の代替的実施形態もまた、実施することができる。上述の例示的なサービス定義では、ＩＰ  Ｃａｍｅｒａ  Ｓｔｒｅａｍｉｎｇサービス２５０１の所定のインスタンスは、関連するコーデック、属性、ペイロードなどを有し、これらは、そのサービスインスタンスの固定された特性とすることができ、異なる特性のセットを、そのサービスの異なるインスタンスとして定義することができる。他の実施形態では、異なる実装を使用することができる。例えば、ストリーミングセッション開始要求は、所望のセキュリティに応じて、ＲＴＰ又はＳＲＴＰを使用して配信することが可能なメディアストリームを構成するために、ＳＤＰを活用することができる。本明細書で使用するとき、「メディアストリーム」は、１つ以上の「メディアフロー」で構成することができ、各メディアフローは、１つの方向での、音声データ又はビデオデータの転送である。例えば、「一方向ビデオ」ストリームは、ＩＰカメラアクセサリ２４０４からコントローラ２４０２への１つのビデオフローを含み得る。「一方向音声」ストリームは、ＩＰカメラアクセサリ２４０４からコントローラ２４０２への、１つの音声フローを含み得る。「一方向音声及びビデオ」ストリームは、ＩＰカメラアクセサリ２４０４からコントローラ２４０２への、１つの音声フロー及び１つのビデオフローを含み得るものであり、それらの２つのフローを同期させることができる。「一方向ビデオ及び双方向音声」ストリームは、コントローラ２４０２からＩＰカメラアクセサリ２４０４への１つの音声フロー、及びＩＰカメラアクセサリ２４０４からコントローラ２４０２への２つのメディアフロー（１つのビデオ、１つの音声）を含み得るものであり、後者の２つのフローを同期させることができる。ＳＤＰは、メディア能力及びトランスポートパラメータを含む、メディアセッションを説明する命名法及びシンタックスを提供することができる。例えば、ＳＤＰは、以下の情報の説明をサポートする：メディアのタイプ（例えば、音声、ビデオ）、メディアのコーデック（例えば、ＬＰＣＭ音声、Ｈ．２６４ビデオ）、ネットワークトランスポート（例えば、受信ＩＰアドレス及びポート）、ストリーム属性（例えば、受信専用、送信専用、送信及び受信）、及びメディアセキュリティ（例えば、ＳＲＴＰを使用するか否か）。ＳＤＰはまた、コントローラとカメラアクセサリとの間のメディアセッションをネゴシエーションするための、簡便なモデルも提供することができ、このモデル内で、それらのデバイスは、相互に許容可能な、メディアのタイプ、メディアのコーデックなどのメディア設定に収斂する。
【０４１９】
したがって、ＩＰカメラストリーミングサービスの一部の代替的実装では、コントローラ（例えば、コントローラ２４０２）は、メディアセッション開始要求内に（例えば、要求２９００内に含まれるデータオブジェクト内に）、ＳＤＰ提案を含み得る。この要求を受信するアクセサリ（例えば、ＩＰカメラアクセサリ２４０４）は、そのメディアセッション開始要求に対する応答内に（例えば、応答３０００内に含まれるデータオブジェクト内に）、メディアセッション要求に対する応答の一部として、ＳＤＰ応答を含み得る。
【０４２０】
再び図２８を参照すると、ストリーミングセッションが確立されると、ブロック２８１６で、ＩＰカメラアクセサリ２４０４は、コントローラ２４０４（又は、メディアセッション開始要求内で指定されるような、他の宛先デバイス）への、メディアのストリーミングを開始することができる。ストリーミングされる具体的なメディア及びストリーミングフォーマットは、アクセサリのＩＰストリーミングサービスの特性に応じて決定することができ、例えばストリーミングは、ビデオ及び／又は音声を含み得る。更には、一部の場合には、ストリーミングサービスは逆方向のフローをサポートすることができ、そのフローは同時に開始することができる。コントローラ２４０２（又は、他の宛先デバイス）は、受信したメディアをユーザに提示することができ、かつ／又は、受信したメディアを、後に提示するために記憶することもできる。メディアコンテンツのストリーミングは、無期限に継続することができる。
【０４２１】
いずれかの時点で、ユーザは、ブロック２８１８で、例えば、ユーザインタフェースの「停止」コントロールを操作することによって、コントローラ２４０２に、メディアストリーミングを停止するように命令することができる。それに応答して、ブロック２８２０で、コントローラ２４０２は、メディアセッション終了要求を生成して、ＩＰカメラアクセサリ２４０４に送信することができる。図３１は、要求２９００及び応答３０００が交換された実施形態に関する、メディアセッション終了要求メッセージ３１００の実施例を示す。メディアセッション開始要求２９００と同様に、メディアセッション終了要求３０００は、ＨＴＴＰ  ＰＵＴ要求とすることができる。要求メッセージ３１００は、メッセージボディ３１０２を有し得る。メッセージボディ３１０２は、書き込まれることになるインスタンスの、インスタンス識別子３１０４を含み得る（インスタンスＩＤ１０は、ＩＰカメラサービスインスタンス２７０４（図２７Ｂ）に関するセッション終了特性に対応する）。値３１０６は、コントローラ２４０２とのストリーミングセッションを終了するためにＩＰカメラアクセサリ２４０４によって使用可能な、情報を含み得るものであり、この実施例では、セッション識別子で十分である。
【０４２２】
再び図２８を参照すると、ブロック２８２２で、アクセサリ２４０４は、その要求に対する応答を送信することができる。図３２は、アクセサリ２４０４が、図３１の要求３１００に応答して生成することが可能なメディアセッション終了応答３２００の実施例を示す。応答メッセージ３２００は、メッセージボディ３２０２を有し得る。メッセージボディ３２０２は値３２０４を含み得る。値３２０４は、エラーが発生したか否かを示すエラーコードを含み得る。このエラーコードは、メディアセッション開始要求に応答するためのエラーコードと同様に定義することができる。
【０４２３】
ブロック２８２４で、ＩＰカメラアクセサリ２４０４は、コントローラ２４０２への、メディアのストリーミングを停止することができる。（定義されたストリームが、逆方向のフローを含む場合には、そのフローを同時に終了することができる。）ブロック２８２４の後、コントローラ２４０２及びアクセサリ２４０４は、ペア検証済みセッションのままに留まることができ、コントローラ２４０２は、そのペア検証済みセッション内で、再びストリーミングを開始することができ、かつ／又は、コントローラ２４０２の他の機能を呼び出すこともできる。
【０４２４】
プロセス２８００は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。順次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。異なるコンテキストでは、ユーザは、プロセス２８００の適切な部分を使用して、ＩＰカメラアクセサリ２４０４と対話することができる。一部の実施形態では、メディアセッションの開始又は終了などの、特定のアクションを実行する前に、ペア検証が必要とされる場合があり、又はペア検証は、ＩＰカメラストリーミングサービスとのあらゆる対話の、前提条件とすることができる。ペア検証済みセッション内では、全ての要求及び応答は、暗号化することができる。更には、ＳＤＰ、ＲＴＰ、及びＳＲＤＰなどの特定のメディア関連プロトコルが、例示の目的のために使用されるが、他のプロトコルで置き換えることもできる。
【０４２５】
プロセス２８００は、限定するものではないが、メディアキャプチャ動作を含めた、ユーザがコントローラを操作してペアリング済みアクセサリを制御することによって実行することが可能な、多種多様な対話式制御動作の実施例として理解することができる。アクセサリが実行することが可能な、任意のタイプの機能又は動作を、本明細書で説明されるものと同様のプロセスを使用して制御することができる。
実施例：ストリーミングインタフェース
【０４２６】
一部のアクセサリは、それらのアクセサリ自体とコントローラとの間の、ＩＰストリーミングをサポートすることができる。上記のＩＰカメラの実施例と同様のリアルタイムメディアストリーミングは１つの選択肢であるが、他のタイプのデータストリーミングもまたサポートすることができる。例えば、ＴＣＰ又はＵＤＰストリーミングをサポートすることができる。一部の実施形態では、アクセサリは、全てのデータを暗号化された形態でストリーミングすることが必要とされる場合がある。例えば、ＴＣＰストリームに関しては、ＴＬＳ−ＰＳＫ（ＣｈａＣｈａ２０／Ｐｏｌｙ１３０５）を使用することができ、その一方で、ＵＤＰストリームに関しては、ＤＴＬＳ−ＰＳＫ（ＣｈａＣｈａ２０／Ｐｏｌｙ１３０５）を使用することができる。一部の実施形態では、ＩＰストリーミングの実施は、上述のＩＰカメラサービスの実施例と同様のものとすることができる。代替的実施もまた、可能である。ここで一実施例を説明する。
【０４２７】
図３３は、本発明の実施形態による、ＩＰストリーミングサービス３３０１に関する例示的なサービス定義を示す。これらの特性は、図３４で、Ｓｔｒｅａｍｉｎｇ  ｃａｐａｂｉｌｉｔｉｅｓ特性３４０１、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｉｎｐｕｔ特性３４０２、及びＳｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ３４０３として定義される。これらの特性のそれぞれはデータオブジェクトとすることができ、それらのキー及び値は、示されるようなものとすることができる。各特性３４０１〜３４０３内には、任意選択的な「ｐｒｏｔｏｃｏｌ−ｉｎｆｏ」キー（その値がオブジェクトであるもの）が含まれており、このキーを使用して、更なるプロトコル固有メタデータを提供することができる。
【０４２８】
この実施例では、コントローラは、ストリームを開くか又は閉じるために、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｉｎｐｕｔ特性３４０２に書き込むことができ、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３を読み取ることによって、ストリーミングの状態を取得することができる。例えば、上述のように、ペアリング済みコントローラは、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３に関するイベント通知に加入することができ、アクセサリは、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３の値が変化する場合は常に、非請求のイベント応答をコントローラに送信することができる。更には、ペアリング済みコントローラはまた、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３を（例えば、上述のようなＨＴＴＰ  ＧＥＴ要求を使用して）読み取ることもできる。
【０４２９】
一部の実施形態では、アクセサリは、インライン結果又は問い合わせ結果のいずれで応答するかを、１回の要求ごとに判定する選択肢を有し得る。インライン結果及び問い合わせ結果の実施例は、図５Ｇ〜図５Ｋを参照して上述されており、このコンテキストで適用することができる。この実施例では、「ｏｎ」は、ＩＰストリーミングサービス３３０１の特性としては示されず、必要に応じて、その定義内に含めることができる。
【０４３０】
ＩＰストリーミングをサポートするアクセサリは、そのアクセサリモデル内に、ＩＰストリーミングサービスを含み得る。本開示を入手可能な当業者には、ＪＳＯＮ又は他の記述言語若しくは表記法で、適切な表現を構成することが可能となるであろう。
【０４３１】
図３５は、本発明の実施形態による、コントローラによって実行することが可能なＩＰストリーミングに関するプロセス３５００の、フローチャートである。ブロック３５０２で、コントローラは、図３３及び図３４で定義されるようなＩＰストリーミングサービスを有するアクセサリと、ペアリングすることができる。例えば、上述のペア設定及びペア検証プロセスを使用することができ、コントローラは、アクセサリ定義レコードを読み取ることにより、そのアクセサリがＩＰストリーミングサービスを有することを判定することができる。
【０４３２】
ブロック３５０４で、コントローラは、例えば、Ｓｔｒｅａｍｉｎｇ  ｃａｐａｂｉｌｉｔｉｅｓ特性３４０１に向けられたＨＴＴＰ  ＧＥＴ要求を送信することによって、アクセサリからＳｔｒｅａｍｉｎｇ  ｃａｐａｂｉｌｉｔｉｅｓ特性３４０１を読み取ることができる。この要求は上述の実施例に従って構築することができる。ブロック３５０６で、コントローラは、ストリーム識別子を生成することができ、識別子を生成する従来技術（例えば、ＵＵＩＤ）を使用することができる。ブロック３５０８で、コントローラは、例えば１の要求タイプと、ブロック３５０６で生成されたストリーム識別子に設定されたストリームｉｄとを有するＨＴＴＰ  ＰＵＴ要求を、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｉｎｐｕｔ特性３４０２に送信することによって、「ストリームを開く」要求をアクセサリに送信することができる。このストリーミングセッションに関して使用する、ＩＰアドレス及びポートなどの他の情報を、例えば、ｐｒｏｔｏｃｏｌ−ｉｎｆｏオブジェクト内に含めることができる。この要求は上述の実施例に従って構築することができる。
【０４３３】
ブロック３５１０で、コントローラは、アクセサリからの応答を受信することができる。一部の実施形態では、この応答は、インライン結果応答（例えば、図５Ｉの応答５７３と同様のもの）、又は、トランザクションｉｄを確立した後に続けて、コントローラがＳｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３を読み取り、確立されたトランザクションｉｄを参照する、問い合わせ結果応答（例えば、図５Ｊの応答５７４、及び図５Ｋの後続の要求５７８と同様のもの）のいずれかとすることができる。いずれの場合にもこの応答は、ポート識別子と、ストリーミングセッションに接続するためにコントローラによって使用可能な任意の他の情報とを含み得る。
【０４３４】
ブロック３５１２で、コントローラは、この応答内で提供された情報を使用して、ストリーミングセッションに接続することができる。ブロック３５１４で、コントローラは、データストリームに関する暗号化を設定することができる。例えば、ＴＬＳ又はＤＴＬＳ暗号化（例えば、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｋｅｏｈｏ−ｌｗｉｇ−ｄｔｌｓ−ｉｏｔ−０１で入手可能な、ＩＥＴＦ  ＲＦＣ４２７９又はＩＥＴＦ  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ  ｄｒａｆｔ−ｋｅｏｈｏ−ｌｗｉｇ−ｄｔｌｓ−ｉｏｔ−０１で文書化されているような、トランスポート層セキュリティ又はデータグラムトランスポート層セキュリティ）に関するキーを、ペア設定若しくはペア検証の間に（ブロック３５０２で）生成された共有シークレット、及び（ブロック３５０６で生成された）ストリームＩＤから導出することができる。アクセサリは、同じ情報からキーを導出することができる。ブロック３５１６で、これらのデバイスは、暗号化されたデータをストリーミングすることができる。データは、必要に応じて、一方又は双方の方向で（コントローラからアクセサリへ、及び／又はアクセサリからコントローラへ）流れることができる。
【０４３５】
コントローラが、ストリームを中断することを決定すると、ブロック３５１８で、コントローラは、例えば、２の要求タイプと、ブロック３５０６で生成されたストリーム識別子に設定されたストリームｉｄとを有するＨＴＴＰ  ＰＵＴ要求を、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｉｎｐｕｔ点特性３４０２に送信することによって、「ストリームを閉じる」要求を送信することができる。この要求もまた、上述の実施例に従って構築することができる。ブロック３５２０で、コントローラは、アクセサリがポートを閉じたことを確認する応答を受信することができる。この応答はブロック３５１０での応答と同じ方式で提供することができる。
【０４３６】
プロセス３５００は例示的なものであり、変型及び修正が可能であることが理解されるであろう。順次的として説明されるステップは、並列に実行することができ、ステップの順序を変更することができ、ステップの修正、組み合わせ、追加、又は省略も可能である。ストリーミングサービスは、アクセサリとコントローラとの間で、任意の種類のデータをいずれかの方向で安全にストリーミングするための汎用ＩＰストリーミングインタフェースを提供することができる。図示の実施例では、ＴＣＰ及びＵＤＰは、リアルタイムプロトコルではない。他の実施形態は、例えば上述のＩＰカメラストリーミングサービス、又は同様のサービスを使用して、リアルタイムストリーミングを提供することができる。
【０４３７】
一部の実施形態では、コントローラは、アクセサリが、その状態が変化した場合には（例えば、ストリーミング中にエラーが発生した場合には）コントローラに警告することを可能にする通知に加入することができる。例えば、図３４を参照すると、コントローラは、Ｓｔｒｅａｍｉｎｇ  ｃｏｎｔｒｏｌ  ｒｅｓｕｌｔ特性３４０３に関するイベント通知（又は、サポートすることが可能な他のタイプの通知）に加入することができる。ストリーミング状態が、アクセサリ側で変化した場合には、アクセサリは、状態コードを更新して、コントローラへの通知（例えば、上述のような非請求のイベントメッセージ）を生成することができる。
例示的デバイス
【０４３８】
本明細書で説明される実施形態は、全般的に従来の設計のものとすることが可能な、電子デバイス内に実装することができ、この電子デバイスは、コントローラ（第１の電子デバイス）がアクセサリ（第２の電子デバイス）の動作を制御することが可能なコマンド及び制御動作をサポートする統一的アクセサリプロトコルに適合するように、適応させることができる。
【０４３９】
図３６は、本発明の実施形態による、コントローラ３６００の簡略ブロック図である。コントローラ３６００は、本明細書で説明されるコントローラの機能、挙動、及び能力のうちのいずれか若しくは全て、並びに、明示的には説明されない他の機能、挙動、及び能力を実行することができる。コントローラ３６００は、処理サブシステム３６１０、記憶デバイス３６１２、ユーザインタフェース３６１４、通信インタフェース３６１６、セキュア要素３６１８、及び暗号化論理モジュール３６２０を含み得る。コントローラ３６００はまた、バッテリ、電力コントローラ、及び、様々な強化能力を提供するように動作可能な他の構成要素などの、他の構成要素（明示的には図示せず）も含み得る。様々な実施形態では、コントローラ３６００は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、又は、任意の所望のフォームファクタを有する他のシステム内に実装することができる。更には上述のように、コントローラ３６００は基地局内に部分的に実装することができ、及び、その基地局と通信してユーザインタフェースを提供する移動ユニット内に、部分的に実装することができる。
【０４４０】
記憶デバイス３６１２は、例えばディスク、フラッシュメモリ、又は任意の他の非一時的記憶媒体、若しくは媒体の組み合わせを使用して実装することができ、揮発性及び／又は不揮発性の媒体を含み得る。一部の実施形態では、記憶デバイス３６１２は、コントローラによって実行されるものとして本明細書で説明される、いずれか又は全ての動作を実行するプログラムを含めた、処理サブシステム３６１０によって実行されることになる１つ以上のアプリケーションプログラム及び／又はオペレーティングシステムプログラムを、記憶することができる。例えば、記憶デバイス３６１２は、アクセサリ定義レコードを読み取り、その中の情報に基づいて、そのアクセサリを制御するためのグラフィカルユーザインタフェースを生成することが可能な、統一的コントローラアプリケーションを記憶することができる。一部の実施形態では、本明細書で説明されるコントローラ機能性の諸部分（又は全て）は、アプリケーションではなく、オペレーティングシステムプログラム内で実施することができる。一部の実施形態では、記憶デバイス３６１２はまた、特定のアクセサリに関して、又は特定のカテゴリのアクセサリに関して設計されたアプリ（例えば、ＩＰカメラアクセサリを管理するＩＰカメラアプリ、又はドアロックアクセサリと対話するセキュリティアプリ）も記憶することができる。
【０４４１】
ユーザインタフェース３６１４は、タッチパッド、タッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、マイクロホンなどの入力デバイス、並びに、ビデオスクリーン、インジケータランプ、スピーカ、ヘッドホンジャックなどの出力デバイスを、サポートする電子機器（例えば、デジタル−アナログ又はアナログ−デジタルコンバータ、信号プロセッサなど）と共に含み得る。ユーザは、ユーザインタフェース３６１４の入力デバイスを操作して、コントローラ３６００の機能性を呼び出すことができ、またユーザインタフェース３６１４の出力デバイスを介して、コントローラ３６００からの出力を見ること及び／又は聞くことができる。
【０４４２】
処理サブシステム３６１０は、１つ以上の集積回路、例えば、１つ以上のシングルコア若しくはマルチコアマイクロプロセッサ、又はマイクロコントローラとして実施することができ、それらの実施例は、当該技術分野において既知である。動作時には、処理システム３６１０は、コントローラ３６００の動作を制御することができる。様々な実施形態では、処理サブシステム３６１０は、プログラムコードに応答して様々なプログラムを実行することができ、同時に実行されている複数のプログラム又はプロセスを維持することができる。任意の所定の時点で、実行されるプログラムコードのうちの一部又は全ては、処理サブシステム３６１０内に、及び／又は記憶デバイス３６１２などの記憶媒体内に存在し得る。
【０４４３】
好適なプログラミングを通じて、処理サブシステム３６１０は、コントローラ３６００に関する様々な機能性を提供することができる。例えば、一部の実施形態では、処理サブシステム３６１０は、コントローラによって実行されるものとして上述された様々なプロセス（又は、その諸部分）を実行することができる。処理サブシステム３６１０はまた、記憶デバイス３６１２内に記憶することが可能なプログラムを含めた、コントローラ３６００の他の機能を制御する他のプログラムも、実行することができる。一部の実施形態では、これらのプログラムは、例えば、アクセサリに送信されるメッセージを生成し、かつ／又はアクセサリからのメッセージを受信することによって、アクセサリと対話することができる。そのようなメッセージは、上述のような統一的アクセサリプロトコルに適合し得る。
【０４４４】
通信インタフェース３６１６は、コントローラ３６００に関する、音声及び／又はデータ通信能力を提供することができる。一部の実施形態では、通信インタフェース３６１６は、無線音声及び／又はデータネットワークにアクセスするための、無線周波数（ＲＦ）トランシーバ構成要素（例えば、セルラー電話技術、３Ｇ、４Ｇ／ＬＴＥなどのデータネットワーク技術、Ｗｉ−Ｆｉ（ＩＥＥＥ  ８０２．１１ファミリ規格）、又は他の移動通信技術、若しくはこれらの任意の組み合わせを使用するもの）、近距離無線通信用の構成要素（例えば、Ｂｌｕｅｔｏｏｔｈ及び／又はＢｌｕｅｔｏｏｔｈ  ＬＥ規格、ＮＦＣなどを使用するもの）、及び／又は他の構成要素を含み得る。一部の実施形態では、通信インタフェース３６１６は、無線インタフェースに加えて、又はその代わりに、有線ネットワーク接続性（例えば、Ｅｔｈｅｒｎｅｔ（登録商標））を提供することができる。通信インタフェース３６１６は、ハードウェア構成要素（例えば、ドライバ回路、アンテナ、変調器／復調器、エンコーダ／デコーダ、並びに他のアナログ及び／又はデジタル信号処理回路）及びソフトウェア構成要素の組み合わせを使用して、実装することができる。一部の実施形態では、通信インタフェース３６１６は、同じトランスポート又は異なるトランスポートを使用して、複数の通信チャネルを同時にサポートすることができる。
【０４４５】
セキュア記憶モジュール３６１８は、コントローラ３６００に関する暗号情報を安全に記憶することが可能な、集積回路などとすることができる。セキュア記憶モジュール３６１８内に記憶することが可能な情報の例としては、コントローラの長期公開キー及び長期秘密キー３６２２（上述のようなＬＴＰＫＣ、ＬＴＳＫＣ）、及びペアリング済みアクセサリのリスト３６２７（例えば、上述のようなペア設定又はペア追加プロセスを完了しているアクセサリに関する、アクセサリ長期公開キーＬＴＰＫＡにアクセサリＩＤを対応付けするルックアップテーブル）が挙げられる。
【０４４６】
一部の実施形態では、暗号化動作は、セキュア記憶モジュール３６１８と通信する暗号化論理モジュール３６２０内で実施することができる。物理的に、暗号化論理モジュール３６２０は、必要に応じて、セキュア記憶モジュール３６１８と同じ集積回路、又は異なる集積回路（例えば、処理サブシステム３６１０内のプロセッサ）内に実装することができる。暗号化論理モジュール３６２０は、上述のいずれか又は全ての暗号化動作を含めた、コントローラ３６００の暗号化動作を実施又はサポートする、様々な論理回路（必要に応じて、固定されるか、又はプログラム可能なもの）を含み得る。セキュア記憶モジュール３６１８及び／又は暗号化論理モジュール３６２０は、コントローラ３６００の残部には「ブラックボックス」として現れ得る。それゆえ、例えば、通信インタフェース３６１６は、その通信インタフェース３６１６が復号することができない、暗号化された形態のメッセージを受信することができ、そのメッセージを、処理サブシステム３６１０に単純に配信することができる。処理サブシステム３６１０もまた、そのメッセージを復号することは不可能であるが、そのメッセージを暗号化されたものとして認識して、暗号化論理モジュール３６２０に配信することができる。暗号化論理モジュール３６２０は、そのメッセージを（例えば、セキュア記憶モジュール３６１８から抽出された情報を使用して）復号し、いずれの情報を処理サブシステム３６１０に返すべきかを判定することができる。結果として、特定の情報はセキュア記憶モジュール３６１８及び暗号化論理モジュール３６２０内でのみ利用可能となり得る。セキュア記憶モジュール３６１８及び暗号化論理モジュール３６２０が、内部セキュアレポジトリからのコードのみを実行する、単一の集積回路上に実装される場合には、このことは、情報の抽出を極めて困難にさせることができ、このことにより、高度のセキュリティを提供することができる。他の実装もまた、可能である。
【０４４７】
図３７は、本発明の実施形態による、アクセサリ３７００の簡略ブロック図である。アクセサリ３７００は、本明細書で説明されるアクセサリの機能、挙動、及び能力のうちのいずれか若しくは全て、並びに、明示的には説明されない他の機能、挙動、及び能力を実施することができる。アクセサリ３７００は、記憶デバイス３７２８、処理サブシステム３７３０、ユーザインタフェース３７３２、アクセサリ固有ハードウェア３７３４、通信インタフェース３７３６、セキュア要素３７３８、及び暗号化論理モジュール３７４０を含み得る。アクセサリ３７００はまた、バッテリ、電力コントローラ、及び、様々な強化能力を提供するように動作可能な他の構成要素などの他の構成要素（明示的には図示せず）も含み得る。
【０４４８】
アクセサリ３７００は、コントローラ３６００などのコントローラによって動作させることが可能な、広範なクラスのアクセサリを代表するものであり、そのようなアクセサリは、能力、複雑性、及びフォームファクタの点で、幅広く変化し得る。様々なアクセサリは、図３７には明示的に示されない構成要素を含み得るものであり、それらの構成要素としては、固定式又は取り外し式の記憶媒体を有する記憶デバイス（ディスク、フラッシュメモリなど）；ビデオスクリーン、スピーカ、又は、外部の音声／ビデオデバイスに接続するためのポート；レンズ、画像センサなどのカメラ構成要素、及びそれらに関するコントロール（例えば、絞り、ズーム、露光時間、フレームレートなど）；音声を（単独で、又はビデオ録画と関連して）録音するマイクロホンなどが挙げられるが、これらに限定されない。
【０４４９】
記憶デバイス３７２８は、例えば、ディスク、フラッシュメモリ、又は任意の他の非一時的記憶媒体、若しくは媒体の組み合わせを使用して実装することができ、揮発性及び／又は不揮発性の媒体を含み得る。一部の実施形態では、記憶デバイス３７２８は、アクセサリによって実施されるものとして上述された様々な動作、並びに特定のアクセサリ挙動に関連する動作を実行するプログラムを含めた、処理サブシステム３７３０によって実行されることになる１つ以上のプログラムを記憶することができる。記憶デバイス３７２８はまた、例えば上述のようなコントローラデバイスに提供することが可能な、（例えば上述のような）アクセサリオブジェクト又はアクセサリ定義レコードも記憶することができる。記憶デバイス３７２８はまた、アクセサリ状態情報、及びアクセサリ３７００の動作の間に使用することが可能な任意の他のデータも記憶することができる。
【０４５０】
処理サブシステム３７３０は、例えば、アクセサリ３７００に関連付けられた様々な機能を実行するプログラムコードを実行する、１つ以上のシングルコア若しくはマルチコアマイクロプロセッサ及び／又はマイクロコントローラを含み得る。例えば、処理サブシステム３７３０は、アクセサリによって実施されるものとして本明細書で説明される、いずれか又は全ての動作を、例えば記憶デバイス３７２８内に記憶されたプログラムコードを実行することによって、実施することができる。処理サブシステム３７３０はまた、アクセサリ３７３０の他の機能を制御する、他のプログラムも実行することができる。一部の場合には、処理サブシステム３７３０によって実行されるプログラムは、例えば、コントローラに送信されるメッセージを生成し、かつ／又はコントローラからのメッセージを受信することによって、コントローラ（例えば、コントローラ３６００）と対話することができる。そのようなメッセージは、上述のような統一的アクセサリプロトコルに適合し得る。
【０４５１】
ユーザインタフェース３７３２は、タッチパッド、タッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、マイクロホンなどの、ユーザ操作可能な入力デバイス、並びに、ビデオスクリーン、インジケータランプ、スピーカ、ヘッドホンジャックなどの出力デバイスを、サポートする電子機器（例えば、デジタル−アナログ又はアナログ−デジタルコンバータ、信号プロセッサなど）と共に含み得る。具体的なアクセサリ３７００の実装に応じて、ユーザは、ユーザインタフェース３７３２の入力デバイスを操作して、アクセサリ３７００の機能性を呼び出すことができ、またユーザインタフェース３７３４の出力デバイスを介して、アクセサリ３７００からの出力を見ること及び／又は聞くことができる。一部のアクセサリは、最小限のユーザインタフェースを提供する場合があり、又はユーザインタフェースを提供しない場合もある。
【０４５２】
アクセサリ固有ハードウェア３７３４は、アクセサリ３７００内に存在することにより、その機能性を有効化又はサポートすることが可能な、任意の他の構成要素を含み得る。例えば、様々な実施形態では、アクセサリ固有ハードウェア３７３４としては、固定式又は取り外し式記憶媒体を使用する１つ以上の記憶デバイス、ＧＰＳ受信機、電力供給及び／又は電力管理回路、カメラ、マイクロホン、１つ以上のアクチュエータ、環境センサ（例えば、温度センサ、圧力センサ、加速度計、化学センサなど）などを挙げることができる。適切なアクセサリ固有ハードウェア３７３４を提供することによって、任意のタイプのアクセサリ機能性をサポートすることができる点を理解されたい。
【０４５３】
通信インタフェース３７３６は、アクセサリ３７００に関する、音声及び／又はデータ通信能力を提供することができる。一部の実施形態では、通信インタフェース３７３６は、無線音声及び／又はデータネットワークにアクセスするための、無線周波数（ＲＦ）トランシーバ構成要素（例えば、セルラー電話技術、３Ｇ、４Ｇ／ＬＴＥなどのデータネットワーク技術、Ｗｉ−Ｆｉ（ＩＥＥＥ  ８０２．１１ファミリ規格）、又は他の移動通信技術、若しくはこれらの任意の組み合わせを使用するもの）、近距離無線通信用の構成要素（例えば、Ｂｌｕｅｔｏｏｔｈ及び／又はＢｌｕｅｔｏｏｔｈ  ＬＥ規格、ＮＦＣなどを使用するもの）、及び／又は他の構成要素を含み得る。一部の実施形態では、通信インタフェース３７３６は、無線インタフェースに加えて、又はその代わりに、有線ネットワーク接続性（例えば、Ｅｔｈｅｒｎｅｔ）を提供することができる。通信インタフェース３７３６は、ハードウェア構成要素（例えば、ドライバ回路、アンテナ、変調器／復調器、エンコーダ／デコーダ、並びに他のアナログ及び／又はデジタル信号処理回路）及びソフトウェア構成要素の組み合わせを使用して、実装することができる。一部の実施形態では、通信インタフェース３７３６は、同じトランスポート又は異なるトランスポートを使用して、複数の通信チャネルを同時にサポートすることができる。
【０４５４】
セキュア記憶モジュール３７３８は、アクセサリ３７００に関する暗号情報を安全に記憶することが可能な、集積回路などとすることができる。セキュア記憶モジュール３７３８内に記憶することが可能な情報の例としては、アクセサリの長期公開キー及び長期秘密キー３７４２（上述のようなＬＴＰＫＡ、ＬＴＳＫＡ）、及びペアリング済みコントローラのリスト３７４４（例えば、上述のようなペア設定又はペア追加プロセスを完了しているコントローラに関する、コントローラ長期公開キーＬＴＰＫＣにコントローラＩＤを対応付けするルックアップテーブル）が挙げられる。
【０４５５】
一部の実施形態では、暗号化動作は、セキュア記憶モジュール３７３８と通信する暗号化論理モジュール３７４０内で実施することができる。物理的に、暗号化論理モジュール３７４０は、必要に応じて、セキュア記憶モジュール３７３８と同じ集積回路、又は異なる集積回路（例えば、処理サブシステム３７３０内のプロセッサ）内に実装することができる。暗号化論理モジュール３７４０は、上述のいずれか又は全ての暗号化動作を含めた、アクセサリ３７００の暗号化動作を実施又はサポートする、様々な論理回路（必要に応じて、固定されるか、又はプログラム可能なもの）を含み得る。セキュア記憶モジュール３７３８及び／又は暗号化論理モジュール３７４０は、アクセサリ３７００の残部には「ブラックボックス」として現れ得る。それゆえ、例えば、通信インタフェース３７３６は、その通信インタフェース３７３６が復号することができない、暗号化された形態のメッセージを受信することができ、そのメッセージを、処理サブシステム３７３０に単純に配信することができる。処理サブシステム３７３０もまた、そのメッセージを復号することは不可能であるが、そのメッセージを暗号化されたものとして認識して、暗号化論理モジュール３７４０に配信することができる。暗号化論理モジュール３７４０は、そのメッセージを（例えば、セキュア記憶モジュール３７３８から抽出された情報を使用して）復号し、いずれの情報を処理サブシステム３７３０に返すべきかを判定することができる。結果として、特定の情報は、セキュア記憶モジュール３７３８及び暗号化論理モジュール３７４０内でのみ利用可能となり得る。セキュア記憶モジュール３７３８及び暗号化論理モジュール３７４０が、内部セキュアレポジトリからのコードのみを実行する、単一の集積回路上に実装される場合には、このことは、情報の抽出を極めて困難にさせることができ、このことにより高度のセキュリティを提供することができる。他の実装もまた可能である。
【０４５６】
アクセサリ３７００は、コントローラ３６００などのコントローラと対話する、任意の電子装置とすることができる。一部の実施形態では、コントローラ３６００は、上述のようなアクセサリ３７００の動作に対するリモート制御を提供することができる。例えば、コントローラ３６００は、入力コントロール及び出力コントロール（例えば、アクセサリ３７００から取得した現在の状態情報を表示するディスプレイスクリーン、及び状態情報に対する変更を可能にするタッチスクリーンオーバーレイなどの入力コントロール）の双方を含み得る、アクセサリ３７００に関するリモートユーザインタフェースを提供することができる。様々な実施形態でのコントローラ３６００は、アクセサリ３７００の任意の機能を制御することができ、また、アクセサリ３７００からデータを受信することもできる。
【０４５７】
図３８は、本発明の実施形態による、コントローラ３８００に関するコントローラアーキテクチャの実施例を示す。このコントローラアーキテクチャは、対話式サブシステムのセットとして示され、各サブシステムは、１つ以上のモジュールを含む。これらのモジュールのそれぞれは、１つ以上のプログラム可能プロセッサ上、及び／又は１つ以上の固定機能プロセッサ内で実行される、プログラムコードを使用して実行することができ、それらのプロセッサ（単数又は複数）は、他のハードウェアデバイス（例えば、アクチュエータ、ディスプレイなど）を制御するための出力信号伝達、及び／又は他のハードウェアデバイス（例えば、キーボード；タッチスクリーン；アクチュエータ、モータ、又はセンサからのフィードバック若しくは状態信号など）からの信号を受信するための入力信号伝達を含み得ることを理解されたい。これらのサブシステムのうちの一部は、任意のタイプの不揮発性記憶デバイス（例えば、半導体フラッシュメモリ、ＥＥＰＲＯＭ、磁気ディスク又は光ディスクなど）を使用して実装することが可能な、永続的データ記憶装置を含み得る。図示されていないが、これらのサブシステムのうちの一部又は全ては、ディスプレイ、キーボード、タッチスクリーン、マイクロホン、スピーカ、センサなどの更なるハードウェア要素を含み得る。
【０４５８】
セキュリティサブシステム３８０２は、セキュア記憶要素３８０４、ペア設定モジュール３８０６、ペア検証モジュール３８０８、ペア追加モジュール３８１０、ペア除去モジュール３８１２、及び暗号化論理モジュール３８１４を含み得る。セキュア記憶要素３８０４は、上述のセキュア記憶要素３６１８又は他のセキュア記憶要素と、同様若しくは同一のものとすることができる。一部の実施形態では、セキュア記憶要素３８０４は、コントローラ３８００に関する長期公開／秘密キーペア（例えば、上述のようなＬＴＰＫＣ、ＬＴＳＫＣ）、並びに、コントローラ３８００がペアリングを確立した各アクセサリに関するペアリングレコードを安全に記憶するために使用される。上述のように、各ペアリングレコードは、ペアリング済みアクセサリの識別子、ペアリング済みアクセサリの長期公開キー、及び任意選択的に、ペアリング済みアクセサリとのコントローラ３８００の対話に関する許可設定（例えば、コントローラ３８００が、管理者許可を有するか否か）を含み得る。コントローラ３８００が、種々のアクセサリに関連する種々の長期公開キーを使用する実施形態では、各ペアリングレコードはまた、ペアリング済みアクセサリと共に使用される長期公開キーの標識も含み得る。必要に応じて他の情報を含めることができる。
【０４５９】
ペア設定モジュール３８０６は、ペア設定プロセスのコントローラ部分を実行することができる。ペア設定プロセスは、コントローラ３８００及びアクセサリが、その後に各デバイスが他方のアイデンティティを検証するために使用することが可能な長期公開キーを、安全に交換する任意のプロセスとすることができる。一部の実施形態では、ペア設定プロセスは、アクセサリのアイデンティティを検証するための、コントローラ３８００とアクセサリとの間での情報項目の帯域外交換（例えば、設定コード、アクセサリのセキュリティ証明書の検証）を含み得る。上述のペア設定プロセス（例えば、プロセス１３００、１４００、１５００、及び／又はプロセス１６００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア設定モジュール３８０６は、ペア設定の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム３８５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア設定モジュール３８０６は、ペア設定プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３８１４の機能を呼び出すことができる。
【０４６０】
ペア検証モジュール３８０８は、ペア検証プロセスのコントローラ部分を実行することができる。ペア検証プロセスは、コントローラ３８００及びアクセサリが、以前に記憶された長期公開キーを使用して、他方のデバイスのアイデンティティを検証する、任意のプロセスとすることができる。上述のペア検証プロセス（例えば、プロセス１７００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア検証モジュール３８０８は、ペア検証の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム３８５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア検証モジュール３８０８は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３８１４の機能を呼び出すことができる。
【０４６１】
ペア追加モジュール３８１０は、ペア追加プロセスのコントローラ部分を実行することができる。ペア追加プロセスは、コントローラ３８００が、アクセサリとのペアリングを確立した後に、そのアクセサリがペアリングを確立することになる「新規」コントローラに関する長期公開キーをそのアクセサリに提供する、任意のプロセスとすることができ、この新規コントローラは、コントローラ３８００とは異なるデバイスとすることができる。上述のペア追加プロセス（例えば、プロセス１８００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア追加モジュール３８１０は、ペア追加の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム３８５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア追加モジュール３８１０はまた、追加される新規コントローラに関する長期公開キー（又は、証明書）を取得するために、別のコントローラ又は他の外部のキー情報源と通信することもできる。一部の実施形態では、ペア追加モジュール３８１０は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３８１４の機能を呼び出すことができる。
【０４６２】
ペア除去モジュール３８１２は、ペア除去プロセスのコントローラ部分を実行することができる。ペア除去プロセスは、コントローラ３８００が、アクセサリとのペアリングを確立した後に、そのアクセサリによってペアリングが除去されることになるコントローラの識別子を、そのアクセサリに提供する、任意のプロセスとすることができ、この除去されるコントローラは、コントローラ３８００とは異なるデバイスとすることができる。上述のペア除去プロセス（例えば、プロセス１９００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア除去モジュール３８１２は、ペア除去の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム３８５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア除去モジュール３８１２はまた、除去されるコントローラに関する識別情報を取得するために、別のコントローラ又は他の外部の情報源と通信することもできる。一部の実施形態では、ペア除去モジュール３８０８は、ペア除去プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３８１２の機能を呼び出すことができる。
【０４６３】
暗号化論理モジュール３８１４は、コントローラ３８００によって使用可能な暗号化アルゴリズムを実行することができる。例としては、キー生成アルゴリズム；ＳＲＰで使用されるアルゴリズム及び関数；ハッシュアルゴリズム；ＣｈａＣｈａ２０−Ｐｏｌｙ１３０５、Ｃｕｒｖｅ２５５１９、Ｅｄ２５５１９、及び／又は他のアルゴリズムなどの、キーベースの暗号化／復号アルゴリズムが挙げられる。一部の実施形態では、暗号化論理モジュール３８１４は、暗号化アルゴリズム及び関連サービスを呼び出すために、コントローラ３８００の他のモジュールによって使用可能な、ＡＰＩ（アプリケーションプログラムインタフェース）を提供することができる。任意数及び任意の組み合わせの、暗号化アルゴリズム並びに関連サービスを、サポートすることができる。
【０４６４】
ユーザ対話サブシステム３８３０は、コントローラ３８００のユーザとの対話を管理することができる。例えば、ユーザインタフェース生成モジュール３８３２は、例えばディスプレイデバイス上に、ユーザに提示されるユーザインタフェースを生成することができる。このユーザインタフェースは、アクセサリと対話するためにユーザによって操作可能な、制御要素を含み得る。例えば、上述のように、コントローラ３８００は、アクセサリオブジェクト内で提供される情報に基づいて、グラフィカルユーザインタフェースをレンダリングすることができる。ユーザ入力受信モジュール３８３４は、ユーザインタフェースからの入力を受信して、その入力に応答して行うべきアクション（例えば、アクセサリに送信されるメッセージを生成すること）を決定するために、その入力を処理することができる。一部の実施形態では、ユーザ入力受信モジュール３８３４は、ユーザ入力に応答して、コントローラ３８００の他のモジュールの機能を呼び出すことができる。
【０４６５】
アクセサリ対話サブシステム３８５０は、コントローラ３８００とアクセサリとの対話をサポートすることができる。アクセサリオブジェクト記憶要素３８５２は、揮発性又は不揮発性の記憶媒体（例えば、半導体フラッシュメモリ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＳＲＡＭ、磁気ディスク又は光ディスクなど）を使用して実装することができる。一部の実施形態では、アクセサリオブジェクト記憶要素３８５２は、コントローラ３８００が情報を有する各アクセサリの、表現を記憶するために使用することができる。例えば、上述のように、アクセサリとペアリングを確立した後、コントローラ３８００などのコントローラは、そのアクセサリから、１つ以上のアクセサリオブジェクトを含み得る、アクセサリ定義レコードを取得することができる。コントローラ３８００は、そのように取得したアクセサリオブジェクトを、アクセサリオブジェクト記憶要素３８５２内に記憶することができる。記憶されたアクセサリオブジェクトは、ユーザインタフェースを（例えば、ユーザインタフェース生成モジュール３８３２によって）生成すること、ユーザ入力を（例えば、ユーザ入力受信モジュール３８３４によって）解釈すること、アクセサリに対する要求を生成すること、及び／又はアクセサリから応答若しくは通知を受信することを含めた、数多くの方式で使用することができる。
【０４６６】
アクセサリ発見モジュール３８５４は、アクセサリの発見に関連する動作、例えば、一斉配信をリッスンすること、発見したアクセサリとペアリングするか否かを判定することなどを実行することができる。例えば、アクセサリ発見モジュール３８５４は、図４を参照して上述されたコントローラ動作を実施することができる。
【０４６７】
要求生成モジュール３８５６は、アクセサリに対する要求を生成して、送信することができる。例えば、ユーザ入力受信モジュール３８３４からの（例えば、ドアをロック解除する）命令に応答して、要求生成モジュール３８５６は、アクセサリに対する適切な（例えば、上述のようなロック状態特性に書き込む）要求メッセージを生成することができる。要求メッセージの実施例は、上述されている。一部の実施形態では、メッセージを生成することは、そのメッセージを暗号化することを含み得るものであり、要求生成モジュール３８５６は、その要求を生成することに関連して、暗号化論理モジュール３８１４によってサポートされる機能を呼び出すことができる。一部の実施形態では、要求生成モジュール３８５６は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、アクセサリに対する要求（例えば、図１３〜図１９を参照して上述された要求のうちのいずれか）を生成して送信するために、セキュリティサブシステム３８０２と対話することができる。
【０４６８】
応答処理モジュール３８５８は、アクセサリから受信することが可能な、要求メッセージに対する任意の応答を、受信して処理することができる。例えば、要求生成モジュール３８５６が、アクセサリに（例えば、上述のようなロック状態特性に書き込む）要求メッセージを送信した後、応答処理モジュール３８５８は、アクセサリから応答メッセージを受信することができ、そのメッセージを解釈することができる。一部の実施形態では、この応答メッセージは、暗号化された形態で受信することができ、応答処理モジュール３８５８は、その応答を解釈することに関連して、暗号化論理モジュール３８１４によってサポートされる機能を呼び出すことができる。応答処理モジュール３８５８はまた、その応答に基づいて、ユーザインタフェースサブシステム３８３０に、情報（例えば、状態コード、エラーが発生したか否かなど）を提供することもでき、ユーザインタフェースサブシステム３８３０は、この情報に基づいて、ユーザへのフィードバックを生成することができる。一部の実施形態では、応答処理モジュール３８５８はまた、応答メッセージ内に含まれる情報に基づいて、アクセサリオブジェクト記憶要素３８５２を更新することもできる。一部の実施形態では、応答処理モジュール３８５８は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、アクセサリから受信される応答（例えば、図１３〜図１９を参照して上述された応答のうちのいずれか）を受信して処理するために、セキュリティサブシステム３８０２と対話することができる。
【０４６９】
通知処理モジュール３８６０は、アクセサリから受信することが可能な通知メッセージを、受信して処理することができる。上述のように、様々な通知メカニズムをサポートすることができ、通知処理モジュール３８６０は、これらの通知メカニズムのうちのいずれか又は全て（例えば、上述のプロセス７００、８００、９００、１０００のうちのいずれか又は全て）をサポートすることができる。例えば、受動的通知の場合には、通知処理モジュール３８６０は、アクセサリによって報告される状態カウンタ値と、記憶されている（例えば、アクセサリオブジェクト記憶要素３８５２内の）状態カウンタ値とを比較することができ、不一致を検出することができる。一部の実施形態では、不一致を検出すると、通知処理モジュール３８６０は、更なる状態情報（例えば、更新されたアクセサリ定義レコード、又はその諸部分）を取得するために、要求生成モジュール３８５６に、アクセサリに対する要求を生成して送信するように命令することできる。広告式通知の場合には、通知処理モジュール３８６０は、アクセサリ発見モジュール３８５４を介して受信した広告を処理することにより、状態変化を有する既知のアクセサリを（例えば、アクセサリ記憶要素３８５２内に記憶されているアクセサリオブジェクトの状態カウンタに基づいて）検出することができる。イベント通知の場合には、応答処理モジュール３８５８によって、非請求の応答メッセージを受信することができ、応答処理モジュール３８５８は、そのメッセージを、非請求の応答（例えば、上述のようなＥＶＥＮＴメッセージ）として認識することができ、更なる処理のために、そのメッセージを通知モジュール３８６０に提供することができる。具体的な通知メカニズムに関わりなく、通知モジュール３８６０は、変化した状態情報の性質を判定して、ユーザ対話サブシステム３８３０に、適切な情報を提供することができる。一部の実施形態では、通知モジュール３８６０はまた、アクセサリオブジェクト記憶要素３８５２内の記憶されたアクセサリオブジェクトを更新することもできる。
【０４７０】
通信インタフェースモジュール３８７０は、アクセサリを含めた他のデバイスとの通信をサポートする、サービスを提供することができる。一部の実施形態では、通信インタフェースモジュール３８７０は、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３８７２及び／又はＨＴＴＰ／ＩＰプロトコルスタック３８７４を実行することができる。Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３８７２は、Ｂｌｕｅｔｏｏｔｈ  ＬＥトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。ＨＴＴＰ／ＩＰプロトコルスタック３８７４は、ＨＴＴＰ及びＩＰトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。Ｂｌｕｅｔｏｏｔｈ  ＬＥ及びＨＴＴＰ／ＩＰは、例示として使用されるものであるが、通信インタフェースモジュール３８７０内では、任意の組み合わせのトランスポートプロトコルをサポートすることができ、コントローラ３８００の所定のインスタンスは、１つ以上のトランスポートプロトコルをサポートすることができる点を理解されたい。上述のように、コントローラ３８００は、デバイス対話のクライアント／サーバモデル内で、クライアントデバイスとしての役割を果たし得るものであり、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３８７２及び／又はＨＴＴＰ／ＩＰプロトコルスタック３８７４は、クライアント挙動をサポートするように構成することができる。
【０４７１】
一部の実施形態では、通信インタフェースモジュール３８７０内のプロトコルスタックは、特定の非標準メッセージを認識するように修正することができる。例えば、上述のように、ＨＴＴＰ／ＩＰプロトコルスタック３８７４は、アクセサリからの非請求「イベント」メッセージ（例えば、上述の図１１Ｂのイベントメッセージ１１２０）を認識するように構成することができる。
【０４７２】
一部の実施形態では、通信インタフェースモジュール３８７０は、外部デバイスに対するメッセージを送信及び／又は受信するために、他のモジュールによって使用可能な、ＡＰＩを提供することができる。このＡＰＩは、トランスポート非依存であるように設計することができ、具体的なメッセージに関するトランスポートの選択は、コントローラ３８００内の他のモジュールに対しては透過的に、通信インタフェースモジュール３８７０内で実施することができる。コントローラ３８００の通信ポート（図示せず）で受信されたメッセージは、そのポート構成に基づいて、Ｂｌｕｅｔｏｏｔｈ  ＬＥスタック３８７２又はＨＴＴＰ／ＩＰスタック３８７４に送信することができ、Ｂｌｕｅｔｏｏｔｈ  ＬＥスタック３８７２及びＨＴＴＰ／ＩＰスタック３８７４のそれぞれは、適切に構成された通信ポートに、発信メッセージを送信することができる。
【０４７３】
図３９は、本発明の実施形態による、アクセサリ３９００に関するアクセサリアーキテクチャの実施例を示す。このアクセサリアーキテクチャは、対話式サブシステムのセットとして示され、各サブシステムは、１つ以上のモジュールを含む。これらのモジュールのそれぞれは、１つ以上のプログラム可能プロセッサ上、及び／又は１つ以上の固定機能プロセッサ内で実行される、プログラムコードを使用して実行することができ、それらのプロセッサ（単数又は複数）は、他のハードウェアデバイス（例えば、アクチュエータ、ディスプレイなど）を制御するための出力信号伝達、及び／又は他のハードウェアデバイス（例えば、キーボード；タッチスクリーン；アクチュエータ、モータ、又はセンサからのフィードバック若しくは状態信号など）からの信号を受信するための入力信号伝達を含み得ることを理解されたい。これらのサブシステムのうちの一部は、任意のタイプの不揮発性記憶デバイス（例えば、半導体フラッシュメモリ、ＥＥＰＲＯＭ、磁気ディスク又は光ディスクなど）を使用して実装することが可能な、永続的データ記憶装置を含み得る。図示されていないが、これらのサブシステムのうちの一部又は全ては、ディスプレイ、キーボード、タッチスクリーン、マイクロホン、スピーカ、モータ、アクチュエータ、センサなどの、更なるハードウェア要素を含み得る。
【０４７４】
セキュリティサブシステム３９０２は、セキュア記憶要素３９０４、ペア設定モジュール３９０６、ペア検証モジュール３９０８、ペア追加モジュール３９１０、ペア除去モジュール３９１２、及び暗号化論理モジュール３９１４を含み得る。セキュア記憶要素３９０４は、上述のセキュア記憶要素３７３８又は他のセキュア記憶要素と、同様若しくは同一のものとすることができる。一部の実施形態では、セキュア記憶要素３９０４は、アクセサリ３９００に関する長期公開／秘密キーペア（例えば、上述のようなＬＴＰＫＡ、ＬＴＳＫＡ）、並びに、アクセサリ３９００がペアリングを確立した各コントローラに関するペアリングレコードを安全に記憶するために使用される。上述のように、各ペアリングレコードは、ペアリング済みコントローラの識別子、ペアリング済みコントローラの長期公開キー、及び任意選択的に、アクセサリ３９００とのペアリング済みコントローラの対話に関する許可設定（例えば、特定のペアリング済みコントローラが、管理者許可を有するか否か）、及び／又はペアリング済みコントローラに関する加入設定（例えば、そのコントローラが、受動的モード以外の特定の通知モードに加入しているか否かの標識）を含み得る。アクセサリ３９００が、種々のコントローラに関連する種々の長期公開キーを使用する実施形態では、各ペアリングレコードはまた、ペアリング済みコントローラと共に使用される長期公開キーの標識も含み得る。必要に応じて、他の情報を含めることができる。
【０４７５】
ペア設定モジュール３９０６は、ペア設定プロセスのアクセサリ部分を実行することができる。ペア設定プロセスは、アクセサリ３９００及びコントローラが、その後に各デバイスが他方のアイデンティティを検証するために使用することが可能な長期公開キーを、安全に交換する任意のプロセスとすることができる。一部の実施形態では、ペア設定プロセスは、アクセサリ３９００のアイデンティティを検証するための、アクセサリ３９００とコントローラとの間での情報項目の帯域外交換（例えば、設定コード、アクセサリのセキュリティ証明書の検証）を含み得る。上述のペア設定プロセス（例えば、プロセス１３００、１４００、１５００、及び／又はプロセス１６００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア設定モジュール３８０６は、ペア設定の間のコントローラとの通信を達成するために、コントローラ対話サブシステム３９５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア設定モジュール３９０６は、ペア設定プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３９１４の機能を呼び出すことができる。
【０４７６】
ペア検証モジュール３９０８は、ペア検証プロセスのアクセサリ部分を実行することができる。ペア検証プロセスは、アクセサリ３９００及びコントローラが、以前に記憶された長期公開キーを使用して、他方のデバイスのアイデンティティを検証する任意のプロセスとすることができる。上述のペア検証プロセス（例えば、プロセス１７００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア検証モジュール３９０８は、ペア検証の間のアクセサリとの通信を達成するために、コントローラ対話サブシステム３９５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア検証モジュール３９０８は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３９１４の機能を呼び出すことができる。
【０４７７】
ペア追加モジュール３９１０は、ペア追加プロセスのアクセサリ部分を実行することができる。ペア追加プロセスは、アクセサリ３９００との確立済みペアリングを有するコントローラが、アクセサリ３９００に、アクセサリ３９００がペアリングを確立することになる「新規」コントローラに関する長期公開キーを提供する、任意のプロセスとすることができ、上述のペア追加プロセス（例えば、プロセス１８００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア追加モジュール３９１０は、ペア追加の間の、以前にペアリングされたコントローラとの通信を達成するために、コントローラ対話サブシステム３９５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア追加モジュール３９１０はまた、追加される新規コントローラに関する長期公開キー（又は、証明書）を取得するために、外部のキー情報源と通信することもできる。一部の実施形態では、ペア追加モジュール３９１０は、ペア検証プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３９１４の機能を呼び出すことができる。
【０４７８】
ペア除去モジュール３９１２は、ペア除去プロセスのアクセサリ部分を実行することができる。ペア除去プロセスは、アクセサリ３９００との確立済みペアリングを有するコントローラが、アクセサリ３９００によってペアリングが除去されることになるコントローラの識別子を、アクセサリ３９００に提供する、任意のプロセスとすることができ、この除去されるコントローラは、ペア除去プロセスを呼び出すコントローラとは異なるデバイスとすることができる。上述のペア除去プロセス（例えば、プロセス１９００）又は他のプロセスのうちのいずれかを使用することができる。一部の実施形態では、ペア除去モジュール３９１２は、ペア除去の間のアクセサリとの通信を達成するために、アクセサリ対話サブシステム３９５０（以下で説明されるもの）と対話することができる。一部の実施形態では、ペア除去モジュール３９１２はまた、除去されるコントローラに関する識別情報を取得するために、別のコントローラ又は他の外部の情報源と通信することもできる。一部の実施形態では、ペア除去モジュール３９０８は、ペア除去プロセスに関連する暗号化動作を実行するために、暗号化論理モジュール３９１２の機能を呼び出すことができる。
【０４７９】
暗号化論理モジュール３９１４は、アクセサリ３９００によって使用可能な暗号化アルゴリズムを実行することができる。例としては、キー生成アルゴリズム；ＳＲＰで使用されるアルゴリズム及び関数；ハッシュアルゴリズム；ＣｈａＣｈａ２０−Ｐｏｌｙ１３０５、Ｃｕｒｖｅ２５５１９、Ｅｄ２５５１９、及び／又は他のアルゴリズムなどの、キーベースの暗号化／復号アルゴリズムが挙げられる。一部の実施形態では、暗号化論理モジュール３９１４は、暗号化アルゴリズム及び関連サービスを呼び出すために、アクセサリ３９００の他のモジュールによって使用可能な、ＡＰＩ（アプリケーションプログラムインタフェース）を提供することができる。任意数及び任意の組み合わせの、暗号化アルゴリズム並びに関連サービスを、サポートすることができる。
【０４８０】
アクセサリアクションサブシステム３９３０は、例えば、コントローラ対話サブシステム３９５０を介してコントローラから受信した要求に応答して、アクセサリ３９００のハードウェア構成要素及び／又はソフトウェア構成要素の様々な動作を管理することができる例えば、アクセサリ３９００は、特定のアクション（例えば、ドアの開放又は閉鎖、カメラの操作など）を行うことが可能な、様々な動作構成要素３９３２を組み込む（又は、それらと通信する）ことができる。動作構成要素３９３２は、ハードウェア構成要素及び／又はソフトウェア構成要素を含み得るものであり、所定の動作構成要素３９３２は、エフェクタモジュール３９３４からの受信制御信号（例えば、デジタル又はアナログ形態の電気信号）に応答することができ、かつ／又は、フィードバックモジュール３９３６へのフィードバック信号（例えば、デジタル又はアナログ形態の電気信号）を生成することができる。
【０４８１】
エフェクタモジュール３９３４は、例えば、ユーザによって要求される動作を達成又は実施するための、動作構成要素３９３２に対する制御信号を生成することができる。具体的な信号は、アドレスされている具体的な動作構成要素３９３２に応じて決定することができる。例示として、動作構成要素３９３２は、電力をオン又はオフに切り替えることが可能なスイッチング回路を含み得るものであり、エフェクタモジュール３９３２は、電力をオン又はオフにする、そのスイッチング回路に対する信号を生成することができる。別の実施例として、動作構成要素３９３２は、電気制御信号に応答して、物理的対象物の動作（例えば、デッドボルトのラッチ留め又はラッチ解除、ドアの開放又は閉鎖）を生じさせることが可能な、電気機械式アクチュエータを含み得るものであり、エフェクタモジュール３９３２は、そのアクチュエータに対する信号を生成することができる。更に別の実施例として、動作構成要素３９３２は、デジタルカメラを制御するためのＡＰＩを含み得るものであり（実装に応じて、このカメラ自体が動作構成要素である場合もあれば、そうではない場合もある）、エフェクタモジュール３９３２は、そのデジタルカメラを制御するために、ＡＰＩコールを呼び出すことができる。様々な実施形態では、エフェクタモジュール３９３４は、コントローラインタフェースサブシステム３９５０を介して受信された、コントローラからの要求、及び／又はアクセサリ３９００のユーザインタフェースで受信された入力に応答して、動作することができる。
【０４８２】
フィードバックモジュール３９３６は、動作構成要素３９３２からのフィードバック信号を受信することができる。具体的な信号は、具体的な動作構成要素３９３２に応じて決定することができる。例えば、スイッチング回路は、そのスイッチの現在の状態を示すフィードバック信号を提供することができる。電気機械式アクチュエータは、現在の状態（例えば、その物理対象物の位置及び／又は動作）を示すフィードバック信号を提供することができる。ＡＰＩは、エラーコード又は状態コードを（例えば、ＡＰＩコールから戻ると）提供することができる。更に別の実施例として、動作構成要素３９３２は、様々な環境条件に関する１つ以上のセンサ（例えば、運動センサ、位置センサ、温度センサ、障害物センサなど）を含み得るものであり、フィードバックモジュール３９３６は、それらのセンサからのセンサデータ信号を受信することができる。一部の実施形態では、フィードバックモジュール３９３６は、受信されたフィードバック信号に基づいて、コントローラ対話サブシステム３９５０にフィードバック情報を提供することができる。
【０４８３】
コントローラ対話サブシステム３９５０は、アクセサリ３９００とコントローラとの対話をサポートすることができる。アクセサリオブジェクト（単数又は複数）記憶要素３９５２は、揮発性又は不揮発性の記憶媒体（例えば、半導体フラッシュメモリ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＳＲＡＭ、磁気ディスク又は光ディスクなど）を使用して実装することができる。一部の実施形態では、アクセサリオブジェクト記憶要素３８５２は、アクセサリ３９００と対話するためにコントローラによって使用することが可能な、１つ以上のアクセサリオブジェクトの表現を記憶するために使用することができる。記憶されたアクセサリオブジェクト（単数又は複数）は、要求に応じて（例えば、コントローラとのペア検証プロセスの実行後に）コントローラに供給することができ、記憶されたアクセサリオブジェクト（単数又は複数）は、アクセサリの状態が変化する場合に、更新することができる。例えば、フィードバックモジュール３９３６は、動作構成要素３９３２から受信したフィードバック信号に基づいて、記憶されたアクセサリオブジェクト（単数又は複数）を更新することができる。
【０４８４】
発見モジュール３９５４は、広告を一斉配信すること、確立済みペアリングを有さないコントローラからの、ペア設定を実行する要求を受信することなどの、アクセサリ３９００をコントローラに発見可能にさせることに関連する動作を、実行することができる。例えば、発見モジュール３９５４は、図４を参照して上述されたアクセサリ動作を実施することができる。
【０４８５】
要求処理モジュール３９５６は、コントローラからの要求メッセージを受信して処理することができる。例えば、受信された要求メッセージ（例えば、上述のようなロック状態特性に書き込むもの）に応答して、要求処理モジュール３９５６は、その要求が許可されているか否か（例えば、ペア検証済み状態が、そのコントローラで存在するか否か、そのメッセージが、有効なセッションキーを使用して暗号化されているか否か、及び、そのコントローラが、要求されたアクションを実行するための許可を有するか否か）を判定することができる。要求が有効であると想定すると、要求処理モジュール３９５６は、エフェクタモジュール３９３４に対する（例えば、ロックメカニズムを作動させる）命令を生成することができる。一部の実施形態では、要求が許可されているか否かを判定することは、そのメッセージを復号することを含み得るものであり、要求処理モジュール３９５６は、その要求を処理することに関連して、暗号化論理モジュール３９１４によってサポートされる機能を呼び出すことができる。一部の実施形態では、要求処理モジュール３９５６は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、コントローラから受信される要求（例えば、図１３〜図１９を参照して上述された要求のうちのいずれか）を受信して処理するために、セキュリティサブシステム３９０２と対話することができる。
【０４８６】
応答生成モジュール３９５８は、要求メッセージに対する応答を生成及び送信して、コントローラに応答メッセージを送信することができる。例えば、要求処理モジュール３９５６が要求を受信して、その要求が許可されていないと判定した場合には、要求処理モジュール３９５６は、そのように応答生成モジュール３９５８に通知することができ、応答生成モジュール３９５８は、エラー応答を生成することができる。その反対に、要求処理モジュール３９５６が要求を受信して、その要求が許可されていると判定した場合には、要求処理モジュール３９５６は、許可された要求が受信されており、エフェクタモジュール３９３４によって処理中であることを、応答生成モジュール３９５８に通知することができる。一部の実施形態では、応答モジュール３９５８は、フィードバックモジュール３９３６からフィードバック情報を受信することを待機して、次いで、そのフィードバック情報を組み込む応答メッセージを生成することができる。例えば、応答生成モジュール３９５８が、センサを読み取るか又はロックを開放する要求を受信した場合には、応答生成モジュール３９５８は、そのセンサの読み取り値、又はロックの開放の確認を、フィードバックモジュール３９３６から受信することを待機して、次いで、適切な応答メッセージ生成することができる。一部の実施形態では、この応答メッセージは、送信する前に暗号化することができ、応答生成モジュール３９５８は、そのメッセージを暗号化することに関連して、暗号化論理モジュール３９１４によってサポートされる機能を呼び出すことができる。一部の実施形態では、応答生成モジュール３９５８は、ペア設定、ペア検証、ペア追加、又はペア除去の動作の間に、コントローラに対する応答（例えば、図１３〜図１９を参照して上述された応答のうちのいずれか）を生成して送信するために、セキュリティサブシステム３９０２と対話することができる。
【０４８７】
通知生成モジュール３９６０は、フィードバックモジュール３９３６から（例えば、アクセサリオブジェクト（単数又は複数）記憶要素３９５２内に記憶されたアクセサリオブジェクトが、更新される場合には常に）情報を受信することができ、その情報に基づいて、コントローラに対する通知メッセージを生成することができる。上述のように、様々な通知メカニズムをサポートすることができ、通知生成モジュール３９６０は、これらの通知メカニズムのうちのいずれか又は全て（例えば、上述のプロセス７００、８００、９００、１０００のうちのいずれか又は全て）をサポートすることができる。例えば、受動的通知の場合には、通知処理モジュール３９６０は、アクセサリオブジェクト（単数又は複数）記憶要素３９５２内に保持されている内部状態カウンタを、単純に更新することができる。広告式通知の場合には、通知生成モジュール３９６０は、状態カウンタを更新して、発見モジュール３９５４に、その更新された状態カウンタ値を含む広告を生成するように命令することができる。イベント通知の場合には、通知モジュール３９６０は、上述のような加入コントローラに送信する非請求の応答（例えば、上述のようなＥＶＥＮＴメッセージ）を生成するように、応答生成モジュール３９５８に命令することができる。一部の実施形態では、通知モジュール３９６０は、様々な通知メカニズム及び／又は様々な特性に関する、加入コントローラのリストを保持することができ、いずれかのコントローラが加入しているか否かに応じて、１つ以上のメカニズムを開始させることができる。一部の実施形態では、この加入情報は、アクセサリオブジェクト（単数又は複数）記憶要素３９５２内に保持することができる。
【０４８８】
通信インタフェースモジュール３９７０は、コントローラを含めた他のデバイスとの通信をサポートする、サービスを提供することができる。一部の実施形態では、通信インタフェースモジュール３９７０は、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３９７２及び／又はＨＴＴＰ／ＩＰプロトコルスタック３９７４を実施することができる。Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３９７２は、Ｂｌｕｅｔｏｏｔｈ  ＬＥトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。ＨＴＴＰ／ＩＰプロトコルスタック３９７４は、ＨＴＴＰ及びＩＰトランスポートプロトコルに従った、発信メッセージのフォーマッティング、及び受信メッセージの解釈を提供することができる。Ｂｌｕｅｔｏｏｔｈ  ＬＥ及びＨＴＴＰ／ＩＰは、例示として使用されるものであるが、通信インタフェースモジュール３９７０内では、任意の組み合わせのトランスポートプロトコルをサポートすることができ、コントローラ３９００の所定のインスタンスは、１つ以上のトランスポートプロトコルをサポートすることができる点を理解されたい。上述のように、アクセサリ３９００は、デバイス対話のクライアント／サーバモデル内で、サーバデバイスとしての役割を果たし得るものであり、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタック３８７２及び／又はＨＴＴＰ／ＩＰプロトコルスタック３８７４は、サーバ挙動をサポートするように構成することができる。
【０４８９】
一部の実施形態では、通信インタフェースモジュール３９７０内のプロトコルスタックは、特定の非標準メッセージを生成するように修正することができる。例えば、上述のように、ＨＴＴＰ／ＩＰプロトコルスタック３９７４は、アクセサリからの非請求「イベント」メッセージ（例えば、上述の図１１Ｂのイベントメッセージ１１２０）を生成するように構成することができる。
【０４９０】
一部の実施形態では、通信インタフェースモジュール３９７０は、外部デバイスに対するメッセージを送信及び／又は受信するために、他のモジュールによって使用可能な、ＡＰＩを提供することができる。このＡＰＩは、トランスポート非依存であるように設計することができ、具体的なメッセージに関するトランスポートの選択は、アクセサリ３９００内の他のモジュールに対しては透過的に、通信インタフェースモジュール３９７０内で実施することができる。アクセサリ３９００の通信ポート（図示せず）で受信されたメッセージは、そのポート構成に基づいて、Ｂｌｕｅｔｏｏｔｈ  ＬＥスタック３９７２又はＨＴＴＰ／ＩＰスタック３９７４に送信することができ、Ｂｌｕｅｔｏｏｔｈ  ＬＥスタック３９７２及びＨＴＴＰ／ＩＰスタック３９７４のそれぞれは、適切に構成された通信ポートに発信メッセージを送信することができる。
【０４９１】
本明細書で説明されるシステム構成及び構成要素は、例示的なものであり、変型及び修正が可能であることが理解されるであろう。コントローラ３６００（又は、コントローラ３８００）の実装は、コントローラによって実行されるものとして上述された動作のうちの、いずれか又は全てを実行することができ、アクセサリ３７００（又は、アクセサリ３８００）の実装は、アクセサリによって実行されるものとして上述された動作のうちのいずれか又は全てを実行することができ、異なる図面に関連する、異なる参照番号の使用は、そうではないことを意味する意図はない点を理解されたい。コントローラ及び／又はアクセサリは、本明細書では具体的に説明されない他の能力（例えば、携帯電話、全地球測位システム（ＧＰＳ）、広帯域データ通信、インターネット接続性など）を有し得る。実装に応じて、これらのデバイスは、一方（又は、双方）のデバイスによってサポートされる任意の機能性を提供するように、又は、各デバイス内に部分的に実施される機能性を提供するように、相互運用することができる。一部の実施形態では、特定のアクセサリは、特定のコントローラを介してアクセス可能でも呼び出し可能でもないが、別のコントローラを介して、又はそのアクセサリと直接対話することによってアクセス可能な何らかの機能性を有し得る。
【０４９２】
更には、コントローラ及びアクセサリは、本明細書では特定のブロックを参照して説明されているが、これらのブロックは、説明の便宜上定義されているものであり、構成部品の特定の物理的配置構成を意味する意図はないことを理解されたい。更には、これらのブロックは、物理的に別個の構成要素に対応する必要はない。ブロックは、例えばプロセッサをプログラムすることによって、又は適切な制御回路を提供することによって、様々な動作を実行するように構成することができ、様々なブロックは、初期の構成が取得される方法に応じて、再構成可能である場合もあれば、そうではない場合もある。本発明の実施形態は、回路及びソフトウェアの任意の組み合わせを使用して実装される電子デバイスを含めた、様々な装置で実現することができる。
【０４９３】
数多くの動作及び対話をサポートすることができる。例えば、一部の実施形態では、アクセサリは、デバイス発見サービス上で広告を一斉配信することにより、そのアクセサリが、コントローラとペアリングするために利用可能であることを示すことができる。コントローラは、例えば、その広告を検出することによって、アクセサリを見つけることができ、ペア設定プロセス（例えば、図１３〜図１６を参照して上述されたプロセスのうちのいずれか）を開始して、例えば、長期公開キー、及び設定コード若しくはセキュリティ証明書などの帯域外情報項目を安全に交換することによって、ペアリングを確立することができる。ペア設定プロセスが完了すると、アクセサリは、そのアクセサリ自体を、いずれの追加のコントローラとも、（例えば、いずれのペア設定開始要求も無視するか、又はそれに応答してエラーを返すことによって）ペア設定を実行することを不可能にさせることができ、ペア設定を実行したコントローラには、管理者許可を付与することができる。管理者許可を有するコントローラは、アクセサリに、ペア追加プロセス（例えば、図１８を参照して上述されたようなもの）を実行するか、又は上述の（例えば、アクセサリに信頼証明書チェーンを提供する）他の委譲ペアリングプロセスを使用することによって、１つ以上の追加のコントローラとペアリングを確立するように、命令することができる。管理者許可を有するコントローラはまた、アクセサリに、ペア除去プロセス（例えば、図１９Ａ〜図１９Ｂを参照して上述されたようなもの）を実行することによって、１つ以上の他のコントローラとの（又は、その管理者許可を有するコントローラとの）確立済みペアリングを除去するように命令することもできる。
【０４９４】
この方式で、ユーザのコントローラは、いずれの更なるペアリングの確立にも参加することが必要となり得るため、コントローラ及びアクセサリのユーザは、いずれの他のコントローラが、そのアクセサリとペアリングするかということに対して、制御を維持することができる。一部の実施形態では、ユーザは、例えば、１つ以上の追加のコントローラに管理者許可を付与するように、アクセサリに命令することによって、その制御を他者と共有することができる。管理者許可を有するコントローラのユーザはまた、もはや所望されない任意のペアリングを含めた、確立済みペアリングを除去するように、アクセサリに命令することもできる。
【０４９５】
アクセサリとペアリングを確立しているコントローラ（「ペアリング済みコントローラ」とも称されるもの）は、必ずしもアクセサリへの常時接続を維持せずとも、アクセサリに対する制御を行使することができる。例えば、ペアリング済みコントローラが、アクセサリに再接続する場合、そのコントローラは、ペア検証プロセス（例えば、図１７を参照して上述されたようなもの）を開始することができ、このペア検証プロセスにより、アクセサリ及びコントローラは、それらの間に確立済みペアリングが存在することを、検証することが可能となる。このペア検証プロセスはまた、アクセサリとコントローラとの接続が維持されている間に送信することが可能な、あらゆる後続のメッセージのセキュリティを確保するために使用可能な、１つ以上のセッションキーも提供することができ、この条件は「ペア検証済みセッション」と称することができる。
【０４９６】
接続されている間、コントローラは、コマンド及び制御メッセージ（又は、要求メッセージ）をアクセサリに送信することができる。適切な要求メッセージを使用することによって、コントローラは、アクセサリの現在の状態を判定することができ、一部の場合は、アクセサリに、その現在の状態の態様を変化させるように命令することができる。例えば、アクセサリは、その状態を特性及びサービスの集合として説明する、アクセサリモデルを（例えば、アクセサリオブジェクトとして）保持することができる。コントローラは、それらの特性のうちの１つ以上（それらの特性のうちの全て、又はそれらの任意のサブセットを含み得るもの）を読み取るか、又は他の方式で問い合わせることによって、アクセサリの現在の状態の態様を判定することができ、それらの特性のうちの１つ以上に書き込むか、又は他の方式で修正することによって、アクセサリに、その現在の状態の態様を変化させるように命令することができる。アクセサリが、ペア検証済みセッション内で、そのような要求の全てが暗号化されたメッセージとして送信されることを必要とする場合には、そのアクセサリの操作は、認可済みコントローラに限定することができる。
【０４９７】
アクセサリは、自己定義式のものとすることができる。例えば、ペアリングを確立した後、ペアリング済みコントローラは、アクセサリからアクセサリ定義レコードを要求することができる。アクセサリ定義レコードは、そのコントローラとペアリングされているアクセサリを介して制御することが可能な、各アクセサリに関するアクセサリオブジェクトを定義することができる。一部の実施形態では、アクセサリがいずれかのペアリングを確立する前に、アクセサリ定義レコードの全て又は一部を、コントローラに利用可能にさせることにより、ペアリングを確立するか否かを判定する際に、そのアクセサリ定義レコードからの情報を使用することが可能となり得る。他の実施形態では、コントローラは、アクセサリの広告内に含まれる情報（例えば、上述のようなＴＸＴレコード）に基づいて、ペアリングを確立するか否かを判定することができ、アクセサリ定義レコードは、ペアリングが確立された後にのみ、コントローラに利用可能にさせることができる。ペアリング済みコントローラは、そのアクセサリ定義レコードを使用して、特性の問い合わせ及び／又は修正の要求を生成することにより、そのアクセサリの制御を有効にすることができる。コントローラは、必要に応じて、ユーザ入力に応答して、又は自動的に（例えば、コントローラが様々な条件を検出することに基づいて）、そのような要求を生成することができる。一部の実施形態では、コントローラは、アクセサリを制御するように動作可能なユーザインタフェースを、動的に生成することが可能な場合があり、このユーザインタフェースは、アクセサリ定義レコード内で提供される情報に基づくものである。
【０４９８】
一部の実施形態では、アクセサリは、その状態の変化を、任意のペアリング済みコントローラに通知することができる。例えば受動的通知プロセス（例えば、図７に示されるようなもの）、広告式通知プロセス（例えば、図８に示されるようなもの）、能動的通知プロセス（例えば、図９に示されるようなもの）、及び／又はイベントメッセージ通知プロセス（例えば、図１０に示されるようなもの）の任意の組み合わせをサポートすることができる。一部の実施形態では、ペアリング済みコントローラは、特定の特性に関して特定の通知方法（例えば、広告式、能動的、及び／又はイベントメッセージ）に加入するために、アクセサリに要求を送信することができる。アクセサリは、様々なコントローラに関する加入状態情報を保持することができ、現在の加入状態に基づいて特定のタイプの通知を生成することができる。
更なる実施形態
【０４９９】
本発明は、特定の実施形態に関して説明されているが、当業者には、数多くの修正が可能であることが認識されるであろう。単一のコントローラは、本明細書で説明されるプロセスを使用することにより、任意数のアクセサリとペアリングを確立することができ、異なるアクセサリと異なる時点で選択的に通信することができる。同様に、単一のアクセサリは、そのアクセサリが（例えば、上述のようなペア設定及びペア追加を使用して）ペアリングを確立している複数のコントローラによって、制御することができる。アクセサリのいずれの機能も、その機能を、１つ以上の特性を有するサービスとしてモデル化し、それらのサービス及び／又はその特性とコントローラが対話する（例えば、読み取る、修正する、更新を受信する）ことを可能にすることによって制御することができる。したがって、本明細書で説明されるようなプロトコル及び通信プロセスは、「統一的」なものとすることができる、これは、それらのプロトコル及び通信プロセスが、アクセサリの機能、又はコントローラのフォームファクタ、又は具体的なインタフェースには関わりなく、１つ以上のコントローラ及び１つ以上のアクセサリを使用する任意のコンテキストで適用可能であることを意味する。
【０５００】
更には、上記の一部の実施例は、標準インターネットプロトコル（ＩＰ）伝送スタック（例えば、ＴＣＰ／ＩＰ）をサポートする、ローカルエリアネットワーク及び広域ネットワークを介して使用することが可能なプロトコルである、ＨＴＴＰに具体的に言及している。しかしながら、他の伝送プロトコルもまた、使用することができる。例えば、Ｂｌｕｅｔｏｏｔｈ  ＬＥプロトコルスタックは、一方のデバイスが別のデバイスの属性を問い合わせるか又は修正することを可能にする、汎用属性（ＧＡＴＴ）層を含む。一部の実施形態では、アクセサリ特性のインスタンスは、ＧＡＴＴモデルに基づく属性として、コントローラに公開することができる。したがって、コントローラはまた、Ｂｌｕｅｔｏｏｔｈ  ＬＥを使用して、アクセサリ特性を問い合わせる（例えば、読み取る）ことも、修正する（例えば、書き込む）こともできる。一部の実施形態では、特定のアクセサリは、ＩＰ及び／又はＢｌｕｅｔｏｏｔｈ  ＬＥ伝送プロトコルの一方若しくは双方をサポートすることができ、コントローラは、そのアクセサリの能力に応じて、及びコントローラによって確立された環境設定に応じて、一部のアクセサリとはＩＰを使用して対話し、他のアクセサリとはＢｌｕｅｔｏｏｔｈ  ＬＥを使用して対話することができる。
【０５０１】
本明細書で説明される様々な特徴、例えば、方法、装置、コンピュータ可読媒体などは、専用の構成要素、及び／又はプログラム可能プロセッサ、及び／又は他のプログラム可能デバイスの、任意の組み合わせを使用して実現することができる。本明細書で説明される様々なプロセスは、同じプロセッサ又は異なるプロセッサ上に、任意の組み合わせで実行することができる。構成要素が、特定の動作を実行するように構成されるとして説明される場合、そのような構成は、例えば、その動作を実行するように電子回路を設計することによって、その動作を実行するようにプログラム可能電子回路（マイクロプロセッサなど）をプログラムすることによって、又はこれらの任意の組み合わせによって、達成することができる。更には、上述の実施形態は、特定のハードウェア構成要素及びソフトウェア構成要素に言及し得るものであるが、当業者には、異なる組み合わせのハードウェア構成要素及び／又はソフトウェア構成要素もまた使用することができ、ハードウェア内で実施されるものとして説明される特定の動作はまた、ソフトウェア内でも実施することができ、逆もまた同様であることが理解されるであろう。
【０５０２】
本明細書で説明される様々な特徴を組み込むコンピュータプログラムは、様々なコンピュータ可読記憶媒体上に、符号化して記憶させることができ、好適な媒体としては、磁気ディスク若しくは磁気テープ、コンパクトディスク（ＣＤ）若しくはＤＶＤ（デジタル多用途ディスク）などの光記憶媒体、フラッシュメモリ、及び他の非一時的媒体が挙げられる。プログラムコードで符号化されたコンピュータ可読媒体は、適合する電子デバイスと共にパッケージ化することができ、又は、そのプログラムコードは、電子デバイスとは別個に（例えばインターネットダウンロードを介して、又は別個にパッケージ化されたコンピュータ可読記憶媒体として）提供することもできる。
【０５０３】
それゆえ、本発明は、特定の実施形態に関して説明されているが、本発明は、以下の特許請求の範囲内での、全ての修正及び等価物を包含することを意図するものであることが理解されるであろう。
【図１】
2017511028.tif 000007
【図２Ａ】
2017511028.tif 000008
【図２Ｂ】
2017511028.tif 000009
【図２Ｃ】
2017511028.tif 000010
【図２Ｄ】
2017511028.tif 000011
【図２Ｅ】
2017511028.tif 000012
【図２Ｆ】
2017511028.tif 000013
【図２Ｇ】
2017511028.tif 000014
【図２Ｈ】
2017511028.tif 000015
【図２Ｉ】
2017511028.tif 000016
【図２Ｊ】
2017511028.tif 000017
【図３Ａ】
2017511028.tif 000018
【図３Ｂ】
2017511028.tif 000019
【図３Ｃ】
2017511028.tif 000020
【図４】
2017511028.tif 000021
【図５Ａ】
2017511028.tif 000022
【図５Ｂ】
2017511028.tif 000023
【図５Ｃ】
2017511028.tif 000024
【図５Ｄ】
2017511028.tif 000025
【図５Ｅ】
2017511028.tif 000026
【図５Ｆ】
2017511028.tif 000027
【図５Ｇ】
2017511028.tif 000028
【図５Ｈ】
2017511028.tif 000029
【図５Ｉ】
2017511028.tif 000030
【図５Ｊ】
2017511028.tif 000031
【図５Ｋ】
2017511028.tif 000032
【図６Ａ】
2017511028.tif 000033
【図６Ｂ】
2017511028.tif 000034
【図６Ｃ】
2017511028.tif 000035
【図６Ｄ】
2017511028.tif 000036
【図６Ｅ】
2017511028.tif 000037
【図７】
2017511028.tif 000038
【図８】
2017511028.tif 000039
【図９】
2017511028.tif 000040
【図１０】
2017511028.tif 000041
【図１１Ａ】
2017511028.tif 000042
【図１１Ｂ】
2017511028.tif 000043
【図１２】
2017511028.tif 000044
【図１３Ａ】
2017511028.tif 000045
【図１３Ｂ】
2017511028.tif 000046
【図１３Ｃ】
2017511028.tif 000047
【図１４Ａ】
2017511028.tif 000048
【図１４Ｂ】
2017511028.tif 000049
【図１４Ｃ】
2017511028.tif 000050
【図１５Ａ】
2017511028.tif 000051
【図１５Ｂ】
2017511028.tif 000052
【図１５Ｃ】
2017511028.tif 000053
【図１５Ｄ】
2017511028.tif 000054
【図１５Ｅ】
2017511028.tif 000055
【図１５Ｆ】
2017511028.tif 000056
【図１６】
2017511028.tif 000057
【図１７Ａ】
2017511028.tif 000058
【図１７Ｂ】
2017511028.tif 000059
【図１７Ｃ】
2017511028.tif 000060
【図１８Ａ】
2017511028.tif 000061
【図１８Ｂ】
2017511028.tif 000062
【図１９Ａ】
2017511028.tif 000063
【図１９Ｂ】
2017511028.tif 000064
【図２０】
2017511028.tif 000065
【図２１】
2017511028.tif 000066
【図２２】
2017511028.tif 000067
【図２３】
2017511028.tif 000068
【図２４】
2017511028.tif 000069
【図２５Ａ】
2017511028.tif 000070
【図２５Ｂ】
2017511028.tif 000071
【図２６Ａ】
2017511028.tif 000072
【図２６Ｂ】
2017511028.tif 000073
【図２６Ｃ】
2017511028.tif 000074
【図２６Ｄ】
2017511028.tif 000075
【図２６Ｅ】
2017511028.tif 000076
【図２７Ａ】
2017511028.tif 000077
【図２７Ｂ】
2017511028.tif 000078
【図２７Ｃ】
2017511028.tif 000079
【図２７Ｄ】
2017511028.tif 000080
【図２８】
2017511028.tif 000081
【図２９】
2017511028.tif 000082
【図３０】
2017511028.tif 000083
【図３１】
2017511028.tif 000084
【図３２】
2017511028.tif 000085
【図３３】
2017511028.tif 000086
【図３４】
2017511028.tif 000087
【図３５】
2017511028.tif 000088
【図３６】
2017511028.tif 000089
【図３７】
2017511028.tif 000090
【図３８】
2017511028.tif 000091
【図３９】
2017511028.tif 000092
【国際調査報告】
2017511028.tif 000093
2017511028.tif 000094
2017511028.tif 000095