特許 7096256 デバイスペアリング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-06-27

(45)【発行日】2022-07-05

(54)【発明の名称】デバイスペアリング

(51)【国際特許分類】

   H04W 76/10 20180101AFI20220628BHJP

   G06F 21/44 20130101ALI20220628BHJP

   G06F 21/31 20130101ALI20220628BHJP

   H04W 12/06 20210101ALI20220628BHJP

   H04W 4/80 20180101ALI20220628BHJP

   H04W 12/04 20210101ALI20220628BHJP

【ＦＩ】

H04W76/10

G06F21/44

G06F21/31

H04W12/06

H04W4/80

H04W12/04

【請求項の数】 13

(21)【出願番号】P 2019543204

(86)(22)【出願日】2018-02-05

(65)【公表番号】

(43)【公表日】2020-04-09

(86)【国際出願番号】 EP2018052785

(87)【国際公開番号】W WO2018146042

(87)【国際公開日】2018-08-16

【審査請求日】2021-02-02

(31)【優先権主張番号】17155571.7

(32)【優先日】2017-02-10

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】516043960

【氏名又は名称】シグニファイ ホールディング ビー ヴィ

【氏名又は名称原語表記】ＳＩＧＮＩＦＹ ＨＯＬＤＩＮＧ Ｂ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ４８，５６５６ ＡＥ Ｅｉｎｄｈｏｖｅｎ，Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100163821

【弁理士】

【氏名又は名称】柴田 沙希子

(72)【発明者】

【氏名】メケンカンプ ジェラルドゥス イングベルトゥス

【審査官】長谷川 未貴

(56)【参考文献】

【文献】米国特許出願公開第２０１５／０２２２５１７（ＵＳ，Ａ１）

【文献】特開２０１６－１０７６１２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

ＩＰＣ Ｈ０４Ｂ ７／２４ － ７／２６

Ｈ０４Ｗ ４／００ － ９９／００

ＤＢ名 ３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

ロックメカニズム及びペアリングプロトコルの両方を使用して第１のデバイスと第２のデバイスの間の制御メッセージの交換のための無線通信接続を確立する方法であって、
ロックメカニズムを適用して、第１のデバイスと第２のデバイスの間で、第１のペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するステップであって、前記第１のペアリングプロトコルは、ディスプレイを必要としないプロトコルである、ステップと、
前記ロックメカニズムによって前記第１のペアリングプロトコルがアクティブにされることを条件として、前記第１のペアリングプロトコルを使用して前記第１のデバイスと前記第２のデバイスの間でペアリングを実行するステップと、
前記ペアリングが完了した場合、制御メッセージの交換のための無線通信接続をアクティブにする、及び前記第２のデバイスがディスプレイを有していないと報告するモードから前記第２のデバイスがディスプレイを有すると報告するモードに前記第２のデバイスを切り替え、これにより、前記第１のデバイスが前記第１のペアリングプロトコルを使用することを必要とするモードから前記第１のデバイスが前記第１のペアリングプロトコルとは異なる第２のペアリングプロトコルを使用することを必要とするモードに前記第２のデバイスが切り替わる、モードの切り替えをトリガするステップと
を含む、方法。

【請求項2】

前記ロックメカニズムによるアクティベーションに応答して、前記第１のデバイスは、前記ペアリングのための認証を取得し、前記ペアリングの完了は、前記認証を条件とする、請求項１に記載の方法。

【請求項3】

前記ロックメカニズムは、前記第２のデバイスと既にペアリングされている第３のデバイスと前記第２のデバイスの間で実行され、前記第１のペアリングプロトコルは、前記ロックメカニズムによる前記第１のペアリングプロトコルへのアクセスのロック解除が前記第３のデバイスによって実行されることを条件として前記第１のデバイスと前記第２のデバイスの間でアクティブにされる、請求項１に記載の方法。

【請求項4】

前記ロックメカニズムは、前記第１のデバイスと前記第２のデバイスの間に視線を必要とする、請求項１、２又は３に記載の方法。

【請求項5】

前記ロックメカニズムは、前記第１のデバイス及び前記第２のデバイスが所定の物理的近接範囲内にあることを必要とする、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記第２のペアリングプロトコルは、ユーザが、前記第１のデバイスのユーザインターフェースに前記第２のデバイスのコードを手動で入力することを必要とするが、前記第１のペアリングプロトコルはそうではない、請求項１に記載の方法。

【請求項7】

前記ロックメカニズムは、所定の時間ウインドウの経過に応答して前記モードの切り替えをトリガするよう構成されるタイマメカニズムを含む、請求項１に記載の方法。

【請求項8】

前記第１のペアリングプロトコルは、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＪｕｓｔＷｏｒｋｓペアリングである、請求項１に記載の方法。

【請求項9】

前記第２のペアリングプロトコルは、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＰａｓｓＫｅｙペアリングである、請求項１に記載の方法。

【請求項10】

前記ロックメカニズムは、アカウント登録情報を比較することにより、新しいユーザアカウントが既知のユーザに属するかどうかを判断する、請求項１乃至５のいずれか一項に記載の方法。

【請求項11】

前記ロックメカニズムは、前記第１のデバイスとサーバ、及び前記第２のデバイスと前記サーバの間の共有秘密鍵を使用して完了する、請求項１０に記載の方法。

【請求項12】

ロックメカニズム及びペアリングプロトコルの両方を使用して制御メッセージの交換のための他の制御デバイスとの無線通信接続を確立するよう動作可能な、被制御デバイスであって、
第１のペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するためにロックメカニズムを適用するための制御ロジックであって、前記第１のペアリングプロトコルは、ディスプレイを必要としないプロトコルである、制御ロジックと、
前記ロックメカニズムによって前記第１のペアリングプロトコルがアクティブにされることを条件として、前記第１のペアリングプロトコルを使用して当該被制御デバイスと前記制御デバイスの間でペアリングを実行するよう構成される送信機及び受信機と
を含み、前記ペアリングが完了した場合、制御メッセージの受信のために無線通信接続をアクティブにする、及び当該被制御デバイスがディスプレイを有していないと報告するモードから当該被制御デバイスがディスプレイを有すると報告するモードに当該被制御デバイスを切り替え、これにより、前記制御デバイスが前記第１のペアリングプロトコルを使用することを必要とするモードから前記制御デバイスが前記第１のペアリングプロトコルとは異なる第２のペアリングプロトコルを使用することを必要とするモードに当該被制御デバイスが切り替わる、モードの切り替えをトリガする、被制御デバイス。

【請求項13】

コンピュータ可読ストレージ上に具現化され、被制御デバイスの１つ以上の処理ユニットで実行された場合、ロックメカニズム及びペアリングプロトコルの両方を使用して制御メッセージの交換のための他の制御デバイスとの無線通信接続を確立するよう構成されるコードを含むコンピュータプログラムであって、
第１のペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するためにロックメカニズムを適用する動作であって、前記第１のペアリングプロトコルは、ディスプレイを必要としないプロトコルである、動作と、
前記ロックメカニズムによって前記第１のペアリングプロトコルがアクティブにされることを条件として、前記第１のペアリングプロトコルを使用して前記被制御デバイスと前記制御デバイスの間でペアリングを実行する動作と
を実行するよう構成され、前記ペアリングが完了した場合、制御メッセージの受信のために無線通信接続をアクティブにする、及び前記被制御デバイスがディスプレイを有していないと報告するモードから前記被制御デバイスがディスプレイを有すると報告するモードに前記被制御デバイスを切り替え、これにより、前記制御デバイスが前記第１のペアリングプロトコルを使用することを必要とするモードから前記制御デバイスが前記第１のペアリングプロトコルとは異なる第２のペアリングプロトコルを使用することを必要とするモードに前記被制御デバイスが切り替わる、モードの切り替えをトリガする、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、制御デバイスと被制御デバイスとのペアリングに関する。

【背景技術】

【0002】

コネクテッドライティング(Connected lighting)は、従来の有線、電気的オンオフ又は調光回路によって制御されるものではなく（又は制御されるだけでなく）、有線接続又はより多くは無線接続、例えば、有線又は無線ネットワークを介すデータ通信プロトコルを使用して制御される１つ以上の照明器具のシステムを指す。典型的には、複数の照明器具、ましては照明器具内の個々のランプが、各々、Ｚｉｇｂｅｅ、Ｗｉ－Ｆｉ又はＢｌｕｅｔｏｏｔｈ（登録商標）等の無線ネットワークプロトコルに従って照明制御デバイスから照明制御コマンドを受信するため（また場合によっては、無線ネットワークプロトコルを使用して照明制御デバイスにステータスレポートを送信するため）の無線受信機又は送受信機を備えてもよい。照明制御デバイスは、ユーザ端末、例えば、スマートフォン、タブレット、ラップトップ若しくはスマートウォッチ等のポータブルユーザ端末の形態、又はデスクトップコンピュータ若しくはワイヤレスウォールパネル等の静的なユーザ端末の形態を取ってもよい。そのような場合、照明制御コマンドは、ユーザ端末のユーザインターフェース（例えば、タッチスクリーン又はポイント・アンド・クリック・インターフェース）を介してユーザによってアプリケーションに提供されるユーザ入力に基づいて、及び／又はアプリケーションの自動機能に基づいて、ユーザ端末上で実行される照明制御アプリケーションから生じてもよい。ユーザデバイスは、照明制御コマンドを照明器具に直接送信してもよく、又は無線ルータ、アクセスポイント、若しくは照明ブリッジ等の中間デバイスを介して送信してもよい。

【0003】

モノのインターネット（ＩｏＴ）では、多くの種類のデバイスがインターネットに接続される。デバイスがワイヤレスネットワークにリンクされる場合、最も重要なステップの１つは初期セットアップである。問題は、セキュアな方法で特定のネットワークに参加するようにデバイスをいかにコンフィギュレーションするかである。通常、これらのデバイスは、何らかの種類のネットワーク識別子又はセキュリティキーを入力するためのディスプレイ又はキーボードを有さない。デバイスが認証され、適切なネットワークに参加し、暗号化キーを交換する初期セットアップは、通常、ペアリングと呼ばれる。コネクテッドライティングでは、初期セットアップは、通常、コミッショニングと呼ばれ、デバイスをペアリングすること及びコンフィギュレーションすることを含む。Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙでは、ネットワークへ参加すること及び鍵を交換することは、ペアリングと呼ばれ、ペアリングプロセス中に暗号化キーが将来の使用のために保存される場合、これは、ボンディングと呼ばれる。

【0004】

ＩｏＴデバイスのための無線規格は、ペアリングの標準化された方法を記述している。例えば、ＺｉｇＢｅｅは、近接ベースのペアリング(proximity based pairing)及びパスコードによるペアリングを含む。Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙは、同様の形式のＰａｓｓＫｅｙペアリングをサポートしているが、認証が必要とされない「ＪｕｓｔＷｏｒｋｓ」として知られるペアリング方法もサポートしている。これは、例えば、電話機が、新しいデバイスが初めて電源を入れられた場合に、該新しいデバイスに簡単に接続できるようにするために使用され得る。Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）規格は、帯域外(out-of-band)メカニズムも記述している。この場合、暗号化キーは、Ｂｌｕｅｔｏｏｔｈ（登録商標）以外の方法を使用して共有される。一例は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ペアリングの一部としてキーを交換するためにＮＦＣを使用することである。

【0005】

Ｄ１（ＵＳ ２０１５／２２２５１７ Ａ１）は、コントローラデバイスと、コントローラによって制御されるアクセサリデバイスとの間の、安全な認証通信を容易にすることができる統一的プロトコルを開示している。アクセサリ及びコントローラは、ペアリングを確立することができ、この場合、アクセサリは、アクセサリ定義レコードを提供することができ、アクセサリ定義レコードは、サービスの集合としてアクセサリを定義し、各アクセサリは、１つ以上の特性を有する。セキュアな通信セッション内で、コントローラは、アクセサリの状態を判断するために特性を問い合わせる、及び／又は状態を変更するようアクセサリに指示するために特性を修正することができる。

【発明の概要】

【発明が解決しようとする課題】

【0006】

標準化された方法の問題は、多くのタイプの製品にとって、標準化されたソリューションがどれも完璧ではないということである。例えば、４桁又は６桁のパスキーを入力することは難しくないが、問題は、大抵、パスキーを見つけることである。Ｐｈｉｌｉｐｓ Ｈｕｅ－Ｌａｍｐｓの場合、パスキーは（小さなフォントサイズを使用して）ランプに印刷されている。しかしながら、ランプが既に天井の照明器具に取り付けられている場合はどうなるか？この状況では、ユーザにとって、パスキーを取得するのが困難になっている可能性があることが理解できるであろう。Ｂｌｕｅｔｏｏｔｈ（登録商標）では、帯域外メカニズムが、（標準化されていない）方法で暗号化キーを交換するために使用されることができる。しかしながら、当該方法は、現在のｉＯＳ及びＡｎｄｒｏｉｄデバイスではサポートされていなく、スマートフォンを使用するデバイス制御アプリケーションにとっては役に立たない。したがって、多くのベンダーは、標準化されたペアリング及び暗号化が使用されない、（標準化されていない）アプリケーションレベルのセキュリティメカニズムを定義することに頼っている。これは、以下のように実装される。規格は、送信されるメッセージが保護されない単純な接続を許可している。アプリケーションによって送信されるデータは、ネットワークを介してただ送信される。しかしながら、送信アプリケーションはデータを暗号化し、ワイヤレスネットワークはこれを保護を必要としない通常のデータとして渡し、適切なレシーバは当該データを解読する。このアプローチの不利な点は、（標準化されていない）ペアリング及び暗号化メカニズムが送信側と受信側の両方で設計及び実装される必要がある一方、（既に実装され利用可能な）標準メカニズムが使用されないままであることである。

【0007】

斯かる課題又は同様の課題に対処するために、本開示は、初期の独自の（すなわち、非標準の）ロックメカニズム(initial proprietary (or: non-standardized) locking mechanism)が、後の標準の（すなわち、非独自の）ペアリング方法(later standardized (or: non-proprietary) pairing method)が使用される前に実行される方法を提供する。

【課題を解決するための手段】

【0008】

本明細書で開示される第１の態様によれば、（標準化されていない）ロックメカニズム(locking mechanism)及び（標準化された）ペアリングプロトコルの両方を使用して第１のデバイスと第２のデバイスの間の制御メッセージの交換のための無線通信接続を確立する方法であって、標準化されていないロックメカニズムを適用して、標準化されたペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するステップと、標準化されていないロックメカニズムによってアクティブにされることを条件として、標準化されたペアリングプロトコルを使用して第１のデバイスと第２のデバイスの間でペアリングを実行するステップと、ペアリングプロトコルが完了した場合、制御メッセージの交換のための無線通信接続をアクティブにするステップとを含む、方法が提供される。

【0009】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムによるアクティベーションに応答して、第１のデバイスが（標準化された）ペアリングのための認証を取得すること、及び（標準化された）ペアリングの完了が前記認証を条件とすることを含む。

【0010】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、第２のデバイスと既にペアリングされている第３のデバイスと第２のデバイスの間で実行されること、及び（標準化された）ペアリングプロトコルが、（標準化されていない）ロックメカニズムが第３のデバイスによって実行されることを条件として第１のデバイスと第２のデバイスの間でアクティブにされることを含む。

【0011】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、第１のデバイスと第２のデバイスの間に遮るもののない視線(unobstructed line of sight)を必要とすることを含む。

【0012】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、第１のデバイス及び第２のデバイスが所定の物理的近接範囲内にあることを必要とすることを含む。

【0013】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムによるアクティベーションに応答して、第２のデバイスが、第１のデバイスが第１の（標準化された）ペアリングプロトコルを使用することを必要とするモードから第１のデバイスが第２の（標準化された）ペアリングプロトコルを使用することを必要とするモードに切り替わること含む。

【0014】

ある実施形態では、当該方法はさらに、第２の（標準化された）ペアリングプロトコルが、ユーザが、第１のデバイスのユーザインターフェースに第２のデバイスのコードを手動で入力することを必要とするが、第１の（標準化された）ペアリングプロトコルはそうではないことを含む。

【0015】

ある実施形態では、当該方法はさらに、前記モードの切り替えが、第２のデバイスが、第２のデバイスがディスプレイを有していないと報告する状態から第２のデバイスがディスプレイを有すると報告するモードに切り替わることによってトリガされることを含む。

【0016】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、所定の時間ウインドウの経過に応答して前記モードの切り替えをトリガするよう構成されるタイマメカニズムを含むことを含む。

【0017】

ある実施形態では、当該方法はさらに、第１の（標準化された）ペアリングプロトコルが、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＪｕｓｔＷｏｒｋｓペアリングであることを含む。

【0018】

ある実施形態では、当該方法はさらに、第２の（標準化された）ペアリングプロトコルが、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＰａｓｓＫｅｙペアリングであることを含む。

【0019】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、アカウント登録情報を比較することにより、新しいユーザアカウントが既知のユーザに属するかどうかを判断することを含む。

【0020】

ある実施形態では、当該方法はさらに、（標準化されていない）ロックメカニズムが、第１のデバイスとサーバ、及び第２のデバイスとサーバの間の共有秘密鍵(shared secret)を使用して完了することを含む。

【0021】

本明細書で開示される第２の態様によれば、（標準化されていない）ロックメカニズム及び（標準化された）ペアリングプロトコルの両方を使用して制御メッセージの交換のために他の制御デバイスとの無線通信接続を確立するよう動作可能な、被制御デバイスであって、（標準化された）ペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するために（標準化されていない）ロックメカニズムを適用するための制御ロジックと、（標準化されていない）ロックメカニズムによってアクティブにされることを条件として、（標準化された）ペアリングプロトコルを使用して被制御デバイスと制御デバイスの間でペアリングを実行するよう構成される送信機及び受信機とを含み、（標準化された）ペアリングプロトコルの完了が、制御メッセージの受信のために無線通信接続をアクティブにする、被制御デバイスが提供される。

【0022】

本明細書で開示される第３の態様によれば、コンピュータ可読ストレージ上に具現化され、被制御デバイスの１つ以上の処理ユニットで実行された場合、（標準化されていない）ロックメカニズム及び（標準化された）ペアリングプロトコルの両方を使用して制御メッセージの交換のために他の制御デバイスとの無線通信接続を確立するよう構成されるコードを含むコンピュータプログラムであって、（標準化された）ペアリングプロトコルへのアクセスがロックされる又はロック解除されるかを設定するために（標準化されていない）ロックメカニズムを適用する動作と、（標準化されていない）ロックメカニズムによってアクティブにされることを条件として、（標準化された）ペアリングプロトコルを使用して被制御デバイスと制御デバイスの間でペアリングを実行する動作とを実行するよう構成され、（標準化された）ペアリングプロトコルの完了が、制御メッセージの受信のために無線通信接続をアクティブにする、コンピュータプログラムが提供される。

【図面の簡単な説明】

【0023】

本開示の理解を助け、実施形態がどのように実施され得るかを示すために、例として添付の図面を参照する。

【図1】制御デバイスと、制御デバイスにより制御されるデバイスとを含むシステムの概略ブロック図である。

【図2】制御デバイスと被制御デバイスとを含む別のシステムの概略ブロック図である。

【図3】チェイニングされたペアリングプロセスを示す概略的なシグナリングチャートである。

【図4】メッセージ交換プロセスを示す概略図である。

【図5】独自のロックプロトコルとしてコーディングレイヤを使用するプロセスのフローチャートを示す概略図である。

【発明を実施するための形態】

【0024】

上記の又は類似の課題を解決するために、本明細書において、（標準化されていない）ロックメカニズムが、その後の標準化されたペアリング方法をロック解除又はロックする（及び可能であれば、該ペアリング方法の情報を提供する）方法が開示される。（標準化されていない）ロックメカニズムと標準化されたペアリングプロトコルがチェイニングされる(chained)。斯くして、有益な効果が達成されるように各々の望ましい品質間のトレードオフを達成することが可能である。

【0025】

本方法は、少なくとも２つのデバイスに関する。第１のデバイスは、第２のデバイス、又はワイヤレスネットワークへの参加を支援することができるデバイスに接続することを意図している。第２のデバイスは、ワイヤレス接続又はワイヤレスネットワークに参加することを意図している。両方のデバイスは、複数のペアリング方法を実装する、及び複数のプロトコルを使用して通信することができてもよい。斯くして、（標準化されていない）ロックメカニズムの結果(outcome)に応じて、標準化されたペアリングプロトコルへのアクセスを許可又はブロックするメカニズムが提供される。（標準化されていない）ロックメカニズムは、非標準のメカニズムである。すなわち、ロックメカニズムは、標準化されたペアリングプロトコルの一部を形成せず、該ペアリングプロトコルへのアクセスが、（標準化されていない）ロックメカニズムがアクティブにされることを条件としてロック解除又はロックされる。本記述の全体を通して、非標準のメカニズムは、（標準化されていない）ロックメカニズムとも呼ばれる。

【0026】

デバイスは、ＺｉｇＢｅｅ及びＢＬＥ両方の機能を有することも可能である。これは、ブリッジを必要としないランプの生産を可能にする。なぜなら、ほとんどの携帯電話はＢＬＥをサポートし、斯くして、ランプを直接制御できるからである。これの作用は、ａ）現在のスターターキットのランプは工場でペアリングされるが、携帯電話はこれらに直接接続する必要があろう、ｂ）目下、追加のランプが後で加えられる必要があるかもしれないが、直接接続には異なるプロセスが必要とされるであろう、ｃ）ユーザは自身の電話を変更するかもしれない、といったようにペアリングプロセスを変更することであろう。現時点では、電話は単に古いブリッジとペアリングし、該ブリッジが、依然として既存のランプにペアリングされるが、電話との直接接続の場合、既存のランプは、新しい電話とも直接ペアリングすることが必要とされるであろう。

【0027】

Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）標準化ペアリングプロセスの例には、「ＪｕｓｔＷｏｒｋｓ」及び「ＰａｓｓＫｅｙ」ペアリングがある。

【0028】

「ＪｕｓｔＷｏｒｋｓ」では、携帯電話及びランプが、認証なしでペアリングをセットアップする。携帯電話のアプリケーションがペアリングを開始し、ＢＬＥデバイス（ランプ）との将来の通信のために暗号化キーが交換される。ＪｕｓｔＷｏｒｋｓ単独では、いつでも認証を必要としないため、非常に安全とは見なされない。任意のデバイスが、いつでもＪｕｓｔＷｏｒｋｓ対応デバイスを介してペアリングすることを可能にしている。

【0029】

ＰａｓｓＫｅｙペアリングでは、ＢＬＥデバイスは、６桁のピンコードに関連付けられ（例えば、ピンコードは画面上に示されることができる）、該ピンコードは、ランプの場合、ランプ（及びオプションとして箱）に印刷されることができる。ユーザは、携帯電話上で同じＰＩＮコードを入力する必要がある。コードが一致する場合、電話とデバイスは暗号化キーを交換し、これらのキーは、認証済みキーとしてフラグが立てられる。キーが交換された場合、デバイスは、ペアリングされたと言われる。

【0030】

ＰａｓｓＫｅｙは、認証（すなわち、鍵）を必要とするため、単独で使用してもよく、斯くして、携帯電話を制御可能なデバイスに接続するのに好適にセキュアである。しかしながら、ユーザの観点からＰａｓｓＫｅｙを使用する場合いくつかの悩ましいプロセスをたどることがある。例えば、パスキー自体を物理的に見つける必要がある。これは、例えば、上述した天井に取り付けられたライトの例のように、潜在的に困難である可能性がある。これは、「電球を設置する」、次いで「コードを入力する」という順で提示されることがよくある、提供された取扱説明書のステップにユーザが従う場合に見込まれるシナリオである。

【0031】

他のペアリングプロトコルに、ＪｕｓｔＷｏｒｋｓと同様のセキュリティレベルのペアリング方法がある。例えば、近接ベースのペアリングを含むＺｉｇＢｅｅである。

【0032】

ペアリングは、無線で接続されるべきデバイスの情報を相互に登録するために必要とされるプロセスである。ワイヤレス接続を確立するためにデバイスをペアリングする必要がある。デバイスがオフにされてもペアリング情報は通常保持されるので、通常、同じデバイスを再度ペアリングする必要はない。ペアリング済みデバイスは、確立された接続を介したさらなる通信を可能にするために暗号化キーを交換したデバイスである。

【0033】

斯くして、ＢＬＥ ＪｕｓｔＷｏｒｋｓ等の標準化されたペアリングプロトコルと組み合わせて使用され得る（標準化されていない）ロックメカニズムは、標準化されたペアリングが使用されることを可能にするが、先ず（標準化されていない）ロックメカニズムを成就する(successfully traverse)という要件が追加される。組み合わされる方法は、例えばＰａｓｓＫｅｙ単独よりもセキュアではないが、各々が単独では望ましくないと見なされる２つの標準化されたペアリング方法間のトレードオフを提供する。斯くして、セキュリティと使いやすさとの間のトレードオフを可能にするペアリングプロセスが提供される。

【0034】

図１は、第１及び第２のデバイスとそれらの構成要素を含む概略図である。

【0035】

第１のデバイス１０２は、無線信号を送信及び受信するための送受信機１０４を備える。送受信機１０４は、コントローラ１０６に接続される。コントローラ１０６は、（標準化されていない）ロックメカニズムと標準化されたペアリングプロトコルの両方のステップを実行させる。標準化されたペアリングプロトコル及び（標準化されていない）ロックメカニズムは、必要に応じて、送受信機１０４又はさらなる代替インターフェース１０８によって促進される。代替インターフェースは、（標準化されていない）ロックメカニズムのうちの１つの一部として情報を受信及び／又は送信することができる任意のインターフェースであってもよい。例えば、このインターフェースは、コード化された光を受信及び検出するためのセンサ、近距離無線通信（ＮＦＣ）送信機／受信機、又は送受信機タイプのコンポーネントが適切でない場合の情報の帯域外タイプの交換のための任意の他のインターフェースであってもよい。

【0036】

第２のデバイス１１０は、無線信号を送信及び受信するための送受信機１１２を含む。送受信機１１２は、制御ロジック１１４に接続される。制御ロジック１１４は、デバイス１１０を他のデバイス、例えば、デバイス１０２とペアリングするために必要な標準化されたペアリングプロトコルのステップを実行する。これは、複数の異なるプロトコルのプロセスを実行すること、及びソフトウェア及び／又はハードウェアを含み得るデバイス１１０の異なる要素を伴うことを含んでもよい。例えば、ロジック１１４は、ドライバ１１６に接続される。ロジック１１４は、ランプ１１８を駆動するように、ドライバ１１６にコマンドを送ってもよい。ランプ１１８は、デバイス１１０内に収容され、デバイス１１０は、例えば、照明器具であってもよい。ロジック１１４はまた、さらなる代替インターフェース１２０を制御する。代替インターフェース１２０は、デバイス１１０によって使用されている（標準化されていない）ロックメカニズムのうちの１つの一部として情報を受信及び／又は送信することができる任意のインターフェースであってもよい。例えば、このインターフェースは、コード化された光を感知するためのセンサ、近距離無線通信（ＮＦＣ）送信機／受信機、又は送受信機タイプのコンポーネントが適切でない場合の情報の帯域外タイプの交換のための任意の他のインターフェースであってもよい。情報がコード化された光として送信される場合、ランプ１１８は、送信のためにさらなる代替インターフェースの代わりに使用されることができ、このようにして制御ロジック１１４に接続されてもよい。

【0037】

無線信号１２２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ、ＺｉｇＢｅｅ等の複数の可能な無線通信信号タイプのうちの任意の１つであり、ペアリングプロトコル通信ストリームを提供し、標準化されたペアリング及び暗号化通信を提供する。サイドチャネル送信又は代替的な帯域外送信１２４は、標準化されたペアリングプロトコル又は特別なロック解除メッセージを介して送信されるメッセージを含む。この送信は、デバイス１０２又は１１０をそれぞれ他方のデバイスに対して認証するための（標準化されていない）ロックメカニズムの一部として使用されるコード又はキー１２６を含んでもよい。

【0038】

一部の実施形態では、コード１２６は、デバイスバインド方法(device-bound method)を通じてデバイスで直接受信されてもよい。例えば、デバイス１０２のユーザが手動でコードを入力すること、又はバーコードスキャナ１０８を使用してコードを受信することを必要とする標準化されたペアリングプロトコルのためである。斯くして、コードは、送信１２４によって受信されなくてもよい。しかしながら、コードは依然として、標準化されたペアリングプロトコルのロックを解除する（標準化されていない）ロックメカニズムの一部としてデバイスによって受信される。すなわち、（標準化されていない）ロックメカニズムにより、標準化されたペアリングプロトコルの実行が可能になる。

【0039】

図２は、ユーザが、ブリッジデバイス２０２を含むように自身のシステムを拡張した図１の概略図を示す。この例では、送信２０４乃至２０６及び２０８乃至２１０の任意の送信が、中間ブリッジデバイス２０２を通過することにより一方のタイプから他方のタイプに変換されてもよい。例えば、デバイス１０２からブリッジデバイスに送信されるＷｉ－Ｆｉ信号は、該Ｗｉ－Ｆｉ信号のコンテンツが、デバイス１１０へＺｉｇＢｅｅプロトコル通信の形式で中継されてもよい。このような信号の変換は、同様に反対方向の送信で生じてもよい。ブリッジデバイスは、とりわけ、デバイス１１０にディスプレイを有していないことを再び報告させるために頼られてもよい。これは、この状態が報告されるファクトリニュー期間よりも後の時点である。ファクトリニュー期間は、事前に定義された時間ウインドウ（すなわち、最初の１０分間の使用）であり、後の時点は、この時間ウインドウが経過した後である。そのため、しばらく後の時点で、使用される標準化されたペアリングは、コードを必要としないペアリング、例えば、ＪｕｓｔＷｏｒｋｓペアリングであることが可能になる。

【0040】

ペアリングは、ペアリングを要求するメッセージから始まり、制御されることを望むデバイスと制御コマンドが入力されるべきデバイスの間のメッセージの交換が続く。再び、一例は携帯電話とランプである。メッセージの交換は非常に複雑になり得、多くの情報の往復の交換及びネゴシエーションを含み、最終的には（成功した場合）暗号化キーの交換を含む。標準の方法では、ペアリング方法は、デフォルトでブロックされ、その後メッセージの交換を通じてブロック解除される。

【0041】

図３は、第１のデバイスと第２のデバイスとさらなる第３のデバイスの間のメッセージ交換プロセス３００を示している。第１のデバイスは、図１のデバイス１０２であってもよく、例えば、スマートフォンであってもよい。第２のデバイスは、図１のデバイス１１０であってもよく、例えば、照明器具であってもよい。さらなるデバイス３３０は、機能的に第１のデバイス１０２と同様のデバイスの第２の例である。第１の実施形態に従って、非標準化ロックメカニズムを使用する（標準化されていない）プロセスが、第１のデバイスと第２のデバイスとの間で実行される。これは、第１のデバイス１０２が特別なロック解除メッセージ３０２を第２のデバイス１１０に送信することから始まる。メッセージ３０２は、後に標準化されたペアリングプロトコルが「ロック解除」されていると見られるように、少なくとも何らかの情報を含む。第２のデバイスは、アクノレッジメントメッセージ３０４を第２のデバイス１１０に送り返すことによって、この特別なロック解除メッセージ３０２を受信したこと、及び（標準化されていない）プロセスが成功裏に完了したことに応答してもよい。この返信メッセージ３０４は、認証の証明として後続の標準化されたペアリングプロトコルで使用するコード１２６を含んでもよい。その後、第１のデバイス１０２は、標準化されたペアリングプロトコルを使用して第２のデバイス１１０とのペアリングを試みる。この標準化されたペアリングは、ペアリング要求メッセージ３０６の送信によって開始される。（標準化されていない）プロセスが成功裏に完了しているので、第２のデバイス１１０は、ペアリング要求を承諾する（３０８）。その後、第１及び第２のデバイス間のペアリングが達成されるように、ペアリングメッセージ交換が継続する。メッセージ交換は複雑であってもよく、少なくとも暗号化キー３１０の交換を含む。

【0042】

第１のデバイスが、第２のデバイス１１０とペアリングすることを望むが、標準化されていないロックメカニズムを使用して（標準化されていない）プロセスを完了していない場合、ペアリング要求３１２は、第２のデバイスによって拒絶される（３１４）。

【0043】

例えば、第１の実施形態では、スマートフォンとワイヤレスコネクテッドランプとの間の接続がセットアップされるべきである。この接続にはＢｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）を使用することが意図されている。しかしながら、電球又はランプがすでに天井の照明器具に配置されているという物理的な状況等、このＢＬＥ接続の直接セットアップを妨げる状況が存在する場合がある。このような制限は、電球に印刷された認証コード又はパスキーに簡単にアクセスできないので、標準のＢＬＥペアリング方法をユーザにとって不便なものにし得る。この状況では、近接ベースのＢＬＥメソッドが妥当であるかもしれないが、このタイプのコントロールペアリングプロトコル用にプログラムされた照明デバイスは、あまりセキュアなものではないので、それほど望ましくない。同様に、標準化された「ＪｕｓｔＷｏｒｋｓ」ペアリング方法も、単独ではあまりセキュアなものではない。斯くして、（標準化されていない）ロックメカニズムは、ユーザの便宜を図るように標準化されたペアリング方法の使用を認証するために使用されることができる。

【0044】

特別な「ロック解除」メッセージは、電話からランプに送信される。この特別なメッセージを使用して、ランプは、該ランプとペアリングする際に当該電話により用いられるＪｕｓｔＷｏｒｋｓペアリング方法をロック解除する。ペアリング要求の前に特別なロック解除メッセージを提供していない電話からのランプとペアリングする要求は、その要求が承諾されず、該電話は、ＪｕｓｔＷｏｒｋｓ方法によりペアリングすることを許可されない。すなわち、特別なロック解除メッセージに含まれる追加の情報（又は特別なロック解除メッセージを以前に提供した結果として受信されたさらなる情報、例えば、コード１２６）を最初に提供することなくランプとペアリングしようと試みる、いかなる時点のいかなる他の電話も、そのペアリングの要求は拒否される。斯くして、（標準化されていない）ロックメカニズムが、標準化されたペアリング方法であるＪｕｓｔＷｏｒｋｓにはない認証レベルを提供するために導入される。（標準化されていない）ロックメカニズムが成功裏に完了しているため、モバイルデバイス１０２は、この安全性が低い標準化されたペアリングプロトコル及び暗号化を使用して接続することが許可される。

【0045】

Ｐｈｉｌｉｐｓのアプリは、この（標準化されていない）ロックメカニズムを提供することができる。斯くして、デバイス上の他のアプリケーションは、標準の暗号化方法を使用して照明器具に接続し、ランプを制御することが可能であり、鍵は、「Ｊｕｓｔ Ｗｏｒｋｓ」ペアリングプロトコルによって取得されている。

【0046】

第２の実施形態では、ペアリング方法は、さらなる制御デバイスを含む。この実施形態では、さらなるモバイルデバイス（例えば、スマートフォン）は、被制御デバイス（例えば、ランプ）と既にペアリングされている。このようなシナリオは、例えば、（ランプが新しい電話とペアリングされる必要がある）ユーザが自身の電話を変更する場合に発生する可能性がある。この場合、すでにペアリングされている電話は、特別なロック解除メッセージを送信するという要件を満たしている。すなわち、後の時点で、非制御デバイスと既にペアリングされているため、さらなるペアリングされている電話は、第１のデバイスを認証することができる。さらなるモバイルデバイスは、例えば仮想ボタンを押すことにより、特別なロック解除メッセージをランプに送信して、後続の制御デバイス（ここでは、第１のデバイス）を追加することができる。斯くして、すでにペアリングされているデバイスは、第２の制御デバイスを「保証」する。さらなるモバイルデバイスは、特別なロック解除メッセージを送信する場合近接してもよい（すなわち、近接ベースの認証を使用してもよい）。第１のデバイスが、さらなるモバイルデバイスによって代わりに完了されている（標準化されていない）ロックメカニズムを使用することに代えて、近接ベースの認証を満たすことが要求されてもよい。その後、第２のデバイスは、標準化されたペアリング方法を使用して第１のデバイスとペアリングすることができる。代替的又は追加的に、第２の制御デバイスは、例えば（標準化されていない）ロックメカニズムの一部として、すでにペアリングされているさらなるデバイスによってランプに対して明示的に識別されてもよい。

【0047】

第２の実施形態に従って、（標準化されていない）ロックメカニズムは、第１のデバイス１０２と第２のデバイス１１０との間で実行される。さらなるデバイス３３０は、すでに第２のデバイス１１０とペアリングされていて、第２のデバイス１１０とペアリングすることを望むデバイスは再び、第１のデバイス１０２である。さらなるデバイス３３０は、第１のデバイス１０２の代わりに（標準化されていない）ロックメカニズムを完了し、このようにして、さらなるデバイス３３０は、第１のデバイス１０２を保証する。さらなるデバイス３３０が特別なロック解除メッセージ（ポストペアリング）３１６を成功裏に送信すると、第１のデバイス１０２は、第２のデバイス１１０とのペアリングを要求することができる。この標準化されたペアリングは、第１のデバイス１０２が第２のデバイス１１０と成功裏にペアリングするために第２のデバイス１１０に近接しなければならないような方法で実行されてもよい。これは、第２のデバイス１１０が正しいデバイスにセキュアに接続することができる１つの方法である。代替的に、第１のデバイス１０２を識別する何らかの情報が、どのデバイス（１０２）がプロキシによりさらなるデバイス３３０の動作によって認証されているのかを判断できるように、第２のデバイス１１０と交換されてもよい。斯くして、第１のデバイスは、ペア要求メッセージ３１８を第２のデバイス１１０に送信し、要求が承諾され（３２０）、第２のデバイス１１０とのペアリングに進み、暗号化キー３２２を交換することができる。

【0048】

図４は、第１のデバイス１０２、第２のデバイス１１０、及びポータルを介してアクセス可能なバックエンドサーバ４０２間のメッセージ交換プロセス４００を示している。第３の実施形態では、（標準化されていない）ロックメカニズムはまた、スマートフォン等の制御デバイス１０２及び第２のデバイス１１０（例えば、ランプ）に加え、バックエンドサーバ４０２を含む。目下論じられているペアリング方法のこの第３の実施形態では、新しいユーザＩＤを有する新しいアカウントが、ユーザによって作成され得る。その後、新しいアカウントは登録され、斯くして、名前、住所等に関連付けられる。新しいアカウントは、既知のユーザに属しているものとして認識される。その後、既知のユーザがポータル４０２にログインする場合、メッセージの複雑な交換が、（標準化されていない）ロックメカニズムをロック解除させることを可能にする。これは、新しいアカウントが同じ既知のユーザに属していると判断できるためである。ポータル４０２は、ランプ１１０と秘密交換(secret exchange)を行う。共有秘密鍵(shared secret)のやり方で、ランプ１１０及びポータル４０６は、共有秘密鍵４０６の半分を交換し、ポータル４０２及びモバイルデバイス１０２は、秘密番号(secret number)４０８を交換する。交換は複雑な方法で行われるため、スヌーピングする第三者が交換のどの部分が秘密鍵の一部であるかを判断することは困難である。共有秘密鍵は、共有秘密鍵の半分同士を組み合わせることにより鍵の導出を可能にする。半分だけが鍵を提供することもなく、単に最終鍵の半分を提供することもない。斯くして、複雑なハンドシェイクを通じて、モバイルデバイス及びランプは、結果がモバイルデバイスの認証となるように、通信することができる。

【0049】

図３及び図４の矢印は単一のメッセージ又は通信インスタンスを示しているが、実際には、単一の矢印によって表されるコンテンツを通信するために送信される一連のメッセージが存在し得ることを認識されたい。単一の矢印は、メッセージングプロセスの一般的な概要を示すためのものに過ぎない。

【0050】

第４の実施形態では、第１の実施形態のペアリング方法と同様に、スマートフォン等の制御デバイス１０２とランプ等の第２のデバイス１１０との間で（標準化されていない）ロックメカニズム及び標準化されたペアリングプロトコルが実行される。ユーザがランプを購入し、開梱し、ねじ込むと、ランプは、ファクトリニューライクモードで動作する。未使用のランプ１１０は、ディスプレイを有していないと報告する。ＢＬＥ規格によれば、携帯電話１０２とのペアリングは、ＪｕｓｔＷｏｒｋｓペアリングという結果になる。ユーザはＰＩＮコードを入力する必要はない。しかしながら、ペアリングが成功すると（又は１０分経過した場合）、ランプは、「気が変わり(change its mind)」、ディスプレイを有すると報告する。

【0051】

携帯電話は、ペアリング要求メッセージをランプに送信する。典型的には、これは、ランプと制御デバイスがそれぞれの機能を詳述するメッセージを交換するような交換を招き、最終的にこれらの報告された機能に基づいて両方のデバイスに適したペアリング方法を決定することになる。例えば、ランプが画面(screen)を持っていると報告した場合、２つのデバイスは、「ＰａｓｓＫｅｙ」のペアリング方法を決定してもよい。なぜなら、ランプは、ユーザにキーを表示することができるからである。ファクトリニューランプは、ペアリング要求が初めて受信された場合にある特定の機能を報告するように事前コンフィギュレーションされることができる。斯くして、最初のペアリング要求は、ディスプレイを有していないというランプからのレポートが常に満足されてもよい。その結果、ペアリング方法は、「ＪｕｓｔＷｏｒｋｓ」方法に決定されることが余儀なくされる。この場合、ランプはさらに、その後、及び／又はタイムアウト期間（例えば、１０分）がアクティベーション後に経過した後、ディスプレイを有することを常に報告するようプログラムされることができる。アクティベーションは、ランプが最初にパワーオンされた（何らかの電力が供給された）又は取付具にねじ込まれたときと見なされることができる。

【0052】

他のデバイスとのその後のペアリングネゴシエーションは、ＰａｓｓＫｅｙペアリングが使用される（関与するデバイスによってネゴシエートされる）ことを要し、ユーザはランプに印刷された６桁のコードを入力する必要があることになる。このアプローチは、ランプが簡単にセットアップできるが、ネイバー（neighbor)によって制御されることができないことを確実にする。ランプはセットアップ中に短時間脆弱であるが、長年の使用中には脆弱ではない。これは、サードパーティ／悪意のある第三者が、事前に定義されたウインドウ内で、新しくパワーオンされたデバイスを発見する可能性が低いためである。しかしながら、第２のデバイス（ランプ）のユーザは、それをプラグインしウインドウを開いたパーティであるので、ウインドウが開いていることが分かる。長年の使用にわたっては、当該デバイスは、後続のペアリングがＰａｓｓＫｅｙペアリング又はその他の第２の標準化されたペアリングプロトコルを使用することを余儀なくされるので、このように脆弱ではない。

【0053】

この実施形態では、（標準化されていない）ロックメカニズムは、第２のデバイスのディスプレイ状態の変更を可能にし、該変更をトリガする所定の追加のコーディングであると見なされることができる。すなわち、（標準化されていない）ロックメカニズムは、最初のペアリングが実行されたことを決定する、及び／又はタイムアウト期間が経過したかどうかを決定するコーディングである。斯くして、すべての実施形態における（標準化されていない）ロックメカニズムは、標準化されたペアリングプロトコルの上のレイヤを提供し、該標準化されたペアリングプロトコルとは明らかに区別されることが分かる。この特定の実施形態では、当該レイヤはロック機能をもたらし、その後、標準化された「ＪｕｓｔＷｏｒｋｓ」ペアリング方法はロックされる。これは、その後に受信したすべてのペアリング要求が、（ランプは「ディスプレイが存在する」と報告するため）「ＪｕｓｔＷｏｒｋｓ」を介しては拒否され、「ＰａｓｓＫｅｙ」が有効になるためである。この実施形態に加えて、前述の「ロック解除」方法のうちの１つを使用して「ＪｕｓｔＷｏｒｋs」ペアリング方法を再度アクティブにする又はロック解除することが可能であってもよい。ユーザにとって、パスコードを使用することなくペアリングすることは、後の時点でも容易であるので、この実施形態のさらなる例では、ランプは再びディスプレイを有していないと報告し、ＪｕｓｔＷｏｒｋｓが使用されることを余儀なくさせる。これは、例えば、携帯電話が（信号強度測定に基づいて）ランプに近接する、（ユーザが自身のシステムをブリッジを有するように拡張したと仮定して）ブリッジを介してランプに送信されるＺｉｇＢｅｅコマンドがこのモードを開始する、コード化された光を使用する等によってアクティブにされることができる。

【0054】

図５は、その後の標準化されたペアリングプロトコルを変更する、（標準化されていない）ロッキングプロトコルとしてコーディングのレイヤを使用するプロセス５００のフローチャートである。

【0055】

プロセスは、サーバに追加されたレイヤが所定の時間ウインドウを含む、ステップＳ５０２で始まる。この所定の時間ウインドウは、第２のデバイス（例えば、ランプ）が最初にパワーオンされた場合に始まる。これは、初めてデバイスに電力が供給され、「スイッチオン」されたと見なされるときである。これは、スイッチを伴っても、伴わなくてもよい。電力が供給されると、標準化されたペアリングプロトコルの上に追加のレイヤを提供するコードが実行されることができる。ウインドウは、その後の所定の時間で終了するように設定される。例えば、１０分の期間が定義されてもよい。したがって、この期間は、所定の時間ウインドウの経過に応答する、（第２のデバイスがディスプレイを有していないと報告するモードから第２のデバイスがディスプレイを有すると報告するモードへの切り替えをトリガする）タイミングメカニズムを提供する。タイムアウト期間を定義するこのウインドウ内で、第２のデバイス（例えば、ランプ）は、ペア要求メッセージに応答して実行されるネゴシエーションの一部としてディスプレイを有していないと報告する。その結果、合意される標準化されたペアリングプロトコルは、ＪｕｓｔＷｏｒｋｓペアリングプロトコル等のキー又はピンを必要としないプロトコルである。

【0056】

所定のタイムアウト期間が経過した場合、プロセスは、ステップＳ５０４に進む。このステップでは、潜在的な制御デバイスから受信したペアリング要求メッセージに応答して第２のデバイスによって報告される機能が異なる。変更は、第２のデバイスがディスプレイを有していると報告することである。これは、第２の標準化されたペアリングプロトコルが使用されることを余儀なくさせる。この第２の標準化されたペアリングプロトコルは、第１のデバイスによるキー又はピンの入力を必要とするプロトコルである。例えば、ＰａｓｓＫｅｙペアリングである。

【0057】

所定のタイムアウト期間が経過していない場合、プロセスは、ステップＳ５０６に進む。プロセスは、ペアリング要求が第１のデバイスによって受信されたかどうかを判断する。第１のデバイスは、例えば、携帯電話、タブレット等の制御デバイスとなり得る任意のデバイスであり得る。

【0058】

ペアリング要求メッセージが受信された場合、プロセスは、ステップＳ５０４で述べられた第２のペアリングプロトコルとは異なる第１のペアリングプロトコルがアクティブにされる、ステップＳ５０８に進む。この第１のペアリングプロトコルは、実行されるためにディスプレイを必要としないプロトコル、例えば、ＪｕｓｔＷｏｒｋｓペアリングプロトコルである。斯くして、第１のデバイスから受信したペアリング要求メッセージに応答して、第２のデバイスは、ディスプレイを有していないと報告する。

【0059】

その後、プロセスは、ステップＳ５１０に進む。第１のペアリングが実行された後、第２のデバイスは、ペアリング要求メッセージに応答して報告する機能を、第２のデバイスはディスプレイを有していると報告するように切り替える。その結果、第２のデバイスと、ペアリングすることを望む他のモバイルデバイスとの間のペアリングネゴシエーション中に決定される標準化されたペアリングプロトコルは、第２の標準化されたペアリングプロトコルである。例えば、第２の標準化されたペアリングプロトコルは、先に使用されたＪｕｓｔＷｏｒｋｓペアリングプロトコルに代えて、ＰａｓｓＫｅｙペアリングのプロトコルであってもよい。

【0060】

第１のデバイスが第２のデバイスとペアリングした後のある時点で、第１のデバイスが、第２のデバイスにメッセージを送信し、第２のデバイスにディスプレイを有すると報告させなくするような、プロセスに対する追加のステップがあってもよい。これは、第１の標準化されたペアリングプロトコル、すなわち、ＪｕｓｔＷｏｒｋｓを再びアクティブにする。したがって、さらなる制御デバイスは、第１の標準化されたペアリングプロトコルを使用して、キー又はコードを必要とせずに、第２のデバイスとペアリングすることが可能である。斯くして、第１のデバイスは、上記の第２の実施形態と同様の方法で、さらなるデバイスのためのプロキシによる認証を提供する。このステップＳ５１２の結果、プロセスは、ステップＳ５０２にリセットされたと考えられ得る。

【0061】

追加のステップＳ５１２は、現在ペアリングされている第１のデバイスが、第２のデバイスがディスプレイを含むと再び報告するように、第２のデバイスの機能を後日再設定することを可能にしてもよい。斯くして、第２のデバイスに対するさらなる制御デバイスの、第１の標準化されたペアリングプロトコルを使用する、その後のペアリングが可能である。

【0062】

これは、関与するデバイスのＩＤの交換を含むことができ、追加的に、一方のデバイスから他方のデバイスへの、又は各デバイスから他のそれぞれのデバイスへの認証を含んでもよい。メッセージ３０４で交換される情報は、携帯電話が自身を認証することを可能にするコード１２６を含んでもよい。例えば、標準化されたペアリングプロトコルの一部は、第１のデバイスのユーザインターフェースにおけるコード１２６の入力を要求してもよい。

【0063】

さらなる例は、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信とＺｉｇＢｅｅ通信の両方をサポートするＨｕｅランプである。Ｂｌｕｅｔｏｏｔｈ（登録商標）ペアリングをセットアップするためにＺｉｇＢｅｅを使用することを考える。Ｂｌｕｅｔｏｏｔｈ（登録商標）の観点から、ＺｉｇＢｅｅを介した情報交換は、標準の帯域外方式として実装され得るが、Ａｎｄｒｏｉｄ及びｉＯＳはこれをサポートしていない。しかしながら、ＺｉｇＢｅｅを使用して、情報は交換されることができる。おそらくは、携帯電話に６桁のキーが示されることになる。これは、標準のＢｌｕｅｔｏｏｔｈ（登録商標）パスキーペアリングをセットアップするために使用される鍵になり得る。代替的に、ＺｉｇＢｅｅの近接ベースのペアリングが、ＢＬＥの「Ｊｕｓｔ Ｗｏｒｋｓ」ペアリングをロック解除するために使用されてもよい（これは、ユーザがパスキーを探す必要が無いことを意味する）。電話は、デバイスとペアリング（及びバインディング）された場合、標準の暗号化を使用して、標準の方法でＢｌｕｅｔｏｏｔｈ（登録商標）経由で通信することができる。

【0064】

この実施形態では、図１を参照すると、デバイス１１０は再び、照明器具（すなわち、Ｈｕｅランプ）である。この例では、照明器具１１０及びデバイス１０２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信及びＺｉｇＢｅｅ通信の両方をサポートすることができる。斯くして、代替インターフェース１２０は、ＺｉｇＢｅｅプロトコルを使用して通信することができる送受信機であり、送受信機１１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続をサポートする。斯くして、代替インターフェース１０８は、ＺｉｇＢｅｅプロトコルを使用した通信もサポートする。したがって、この実施形態では、ＺｉｇＢｅｅが、Ｂｌｕｅｔｏｏｔｈ（登録商標）ペアリングをロック解除するために使用される。（標準化されていない）ロックメカニズムは、ＺｉｇＢｅｅを使用し、６桁のキーを携帯電話に送信する。Ａｎｄｒｏｉｄ及びｉＯＳは、標準のＢｌｕｅｔｏｏｔｈ（登録商標）ペアリングにおける帯域外通信をサポートしていない。しかしながら、標準の帯域外ペアリングがサポートされている場合、ＺｉｇＢｅｅを介した情報の交換は、このようにしてＢＬＥ接続をロック解除することができる。帯域外がサポートされていない場合、ＺｉｇＢｅｅは、（標準化されていない）ロックメカニズムとして機能することによって情報を交換するために依然使用されることができる。例えば、特別なロック解除メッセージ、及び可能であればコード１２６も含むＺｉｇＢｅｅ送信１２４によってである。コード１２６は、携帯電話に表示するための６桁のキーであり得、標準のＢｌｕｅｔｏｏｔｈ（登録商標）パスキーペアリングで使用されることができる。ＺｉｇＢｅｅプロトコルは近接ペアリング機能も備えている。斯くして、送信１２４を介したＺｉｇＢｅｅ近接ペアリングは、ＢＬＥ「Ｊｕｓｔ Ｗｏｒｋｓ」のペアリングプロトコルをロック解除するために使用されることができる。この後者の例の利点は、ユーザが、自身のデバイスが帯域外のＢｌｕｅｔｏｏｔｈ（登録商標）ペアリングをサポートしていない場合、パスキーを探すことが必要とされないことである。近接ペアリングは、ＺｉｇＢｅｅプロトコルを介すかどうかに関係なく、ＢＬＥの標準化されたペアリングプロトコルの一部ではなく、斯くして、（標準化されていない）ロックメカニズムを提供する。斯くして、ＺｉｇＢｅｅの標準化されたペアリングプロトコルの一部ではあるが、この実施形態の近接ペアリングは、その後使用される標準化されたプロトコルの一部と見なされない（標準化されていない）ロックメカニズムレイヤを提供する。

【0065】

図１を参照すると、（標準化されていない）ロックメカニズムは、ランプ若しくは照明器具の箱にある印刷されたコードの入力、ＱＲコード（登録商標）の読み取り、又は代替インターフェース１０８を使用した、電球から放射されるコード化された光のコードの検出を含んでもよい。これらの方法を使用する利点は、本質的な近接性が、これらの方法でコードを取得することに関連付けられることである。そうすることにより、セキュリティのレイヤが、その後使用される標準化されたペアリングプロトコルに追加される。すなわち、これらの方法で提示される、及び明示的には述べられていないが当業者には明らかな他の方法で提示されるコードにアクセスすることができる人は、ランプの所有者及び意図されたユーザである見込みが非常に高いということである。コード１２６は、１６進コードであってもよく、斯くして、６桁の１０進数の入力のみを許可するＢＬＥ標準帯域外方法に適合しないであろう。（標準化されていない）ロックメカニズムはまた、近接性に直接依存してもよい。斯くして、正しいモバイルデバイスが（正しい意図されたユーザによって）使用されることを確実にするのに十分に小さな近接範囲が望ましいであろう。しかしながら、デバイスから天井（及び照明器具）までの距離が大きすぎることまでは、近接範囲ではない。

【0066】

上記の実施形態は例としてのみ述べられていることを理解されたい。開示された実施形態に対する他の変更は、図面、開示、及び添付の特許請求の範囲の研究から、クレームされた発明を実施する際に当業者によって理解され、達成され得る。

【0067】

特許請求の範囲において、「含む（comprising）」という単語は他の要素又はステップを排除するものではなく、不定冠詞「a」又は「an」は複数を除外しない。単一のプロセッサ又は他のユニットが、請求項に列挙されたいくつかの項目の機能を果たすことができる。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用できないことを示すものではない。コンピュータプログラムは、他のハードウェアと一緒に又は他のハードウェアの一部として供給される光学記憶媒体又は固体媒体等の適切な媒体上に記憶／分配され得るが、インターネット又は他の有線又は無線の電気通信システム等の他の形態で分配されてもよい。請求項中の参照符号は、範囲を限定するものとして解釈されるべきではない。

【図1】

【図2】

【図3】

【図4】

【図5】