知財求人 - 知財ポータルサイト「IP Force」
▶ フィリップス ライティング ホールディング ビー ヴィの特許一覧
特許7314117ドライバへの補助負荷の接続又は切断を検出するための方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-14
(45)【発行日】2023-07-25
(54)【発明の名称】ドライバへの補助負荷の接続又は切断を検出するための方法及び装置
(51)【国際特許分類】
H05B 47/175 20200101AFI20230718BHJP
H05B 47/17 20200101ALI20230718BHJP
【ＦＩ】
H05B47/175
H05B47/17
【請求項の数】
14
(21)【出願番号】P 2020506889
(86)(22)【出願日】2018-08-09
(65)【公表番号】
(43)【公表日】2020-10-08
(86)【国際出願番号】 EP2018071610
(87)【国際公開番号】W WO2019030318
(87)【国際公開日】2019-02-14
【審査請求日】2021-08-05
(31)【優先権主張番号】17185989.5
(32)【優先日】2017-08-11
(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】
前記補助負荷の前記決定された少なくとも１つの許可に基づいて、前記照明ドライバの前記補助電力出力部に接続された補助負荷に、及び／又は前記一次電力出力部に接続された一次負荷に供給される前記電力を制御可能に制限するステップを含む、請求項１２に記載の制御方法。
【請求項14】
コンピュータプログラムコード手段を含むコンピュータプログラムであって、前記コンピュータプログラムコード手段が、前記コンピュータプログラムがコンピュータ上で実行されると、請求項１１乃至１３の何れか一項に記載の方法を実行するように構成されている、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はドライバの技術分野に関し、より詳細には、電力を一次出力部及び補助出力部の両方に供給するように構成されたドライバに関する。
【背景技術】
【0002】
主電源を負荷に接続するドライバを設けることが周知であり、ドライバは、負荷に供給される電力を調節する、又は他の仕方で制御することができる。この種のドライバは照明又は音響設備において特に普及している。
【0003】
電力を複数の負荷に供給する能力を有するドライバが次第に一般的になりつつある。これらのドライバは、通例、電力を一次負荷に供給するように設計されており、通例、１つ以上の補助負荷に接続するように更に構成されている。接続された１つ以上の補助負荷もまた、電力をドライバから引き出してよい。それゆえ、ドライバは、少なくとも、一次負荷に接続するための第１のインターフェース又は出力部と、補助負荷に接続するための第２のインターフェース又は出力部とを備えてもよい。例えば、欧州特許出願公開第３００１７７８（Ａ１）号を参照されたい。
【発明の概要】
【発明が解決しようとする課題】
【0004】
少なくとも、電力を複数の負荷に供給する能力を有するドライバの、この次第に一般的になりつつある動向のゆえに、市場においては、このようなドライバの機能及び適用を改善することが要望されている。
【課題を解決するための手段】
【0005】
本発明は、請求項によって定義される。
【0006】
ドライバであって、ドライバの一次負荷に電気的に接続するように構成された一次電力出力部と、ドライバの補助負荷に電気的に接続するように構成された補助電力出力部と、電力を一次電力出力部及び補助電力出力部に供給するための電源と、ドライバコントローラであって、補助負荷が補助電力出力部に接続すること、又はそれから切断することによって生じた、補助電力出力部における電力消費の変化があるかどうかを判定する、及び電力消費の変化が生じたと判定したことに応じて、補助負荷及び／又は一次負荷に関する少なくとも１つのアクションを実行するように構成されている、ドライバコントローラと、を備える、ドライバが提案される。
【0007】
これにより、本発明は、補助出力部における電力消費の検出された変化に応じてアクションがトリガされるドライバを提供する。電力消費の変化は、ドライバへの補助負荷の接続又は切断を示す。
【0008】
電力消費の変化によってトリガされる、ドライバによって実行されるアクションは、補助負荷監視ステップ、補助負荷識別ステップ、補助負荷への電力供給の制約、などのうちの任意の１つ以上を含んでもよい。
【0009】
１つの特定の実施形態では、アクションは、接続されているが識別不能である補助負荷への補助電力出力部を切ることを含んでもよい。電力を切ることによって、未知の、敵意のある可能性のある、及び／又は認可されていない、補助負荷が、ドライバが部分を成すシステムに対する攻撃、又はすぐ近くの他のシステム若しくは人に対する攻撃を実行するために必要な電力を受電することがないことを確実にすることができる。
【0010】
本発明は、補助負荷のプラグをドライバに差し込むこと、又は補助負荷のプラグをドライバから引き抜くことが、当該ドライバの補助出力部における電力消費の変化を生じさせることを認識している。特に、本発明は、電力消費のこの変化が、補助負荷に関するドライバのアクションをトリガするために用いられてもよいことを認識している。本明細書で使用するとき、（補助負荷によって生じた）電力消費の変化の結果としてドライバによってとられる任意のアクションは、補助負荷に関して実行される。変化は、特に、瞬間変化であってもよい。
【0011】
補助負荷を接続するための変化は、例えば、電力が消費されていない状態（例えば、０ｍＷ、開放回路）から、プラグを差し込まれた補助負荷によって補助出力部において最小量（例えば、１０～１００ｍＷ）の電力が消費されている状態へのジャンプであることができるであろう。例として、このジャンプは、補助負荷が補助電力出力部に接続するか、又は切断することによって生じる、述べられたとおりの電力消費の瞬間的又は実質的に瞬間的な変化であってもよい。例えば、変化は電力消費のディップ若しくはピークであってもよく、又は電力消費の増加であってもよい。
【0012】
更に、補助負荷を接続することに関する変化は、それぞれ、ドライバの基準出力電力に対するステップ、又はピーク／ディップなどの、電力消費の永久的ジャンプ又は一時的ジャンプであってもよい。
【0013】
それゆえ、述べられたように、本発明は、補助出力部自体における電力消費の検出された瞬間変化に応じてアクションがトリガされるドライバを提供し、瞬間変化は、接続又は切断された補助負荷にとって特徴的である電力消費の検出可能な勾配を生じさせる。
【0014】
これは、負荷がいつドライバに接続又は切断されたのかについての単純で正確な判定を可能にし、外部構成要素（例えば、光検出器）、又は他の複雑な監視技法（例えば、出力インターフェース問い合わせ方法）を必要としない。本提案のコンセプトはまた、補助負荷の接続／切断がドライバの対応する反応を生じさせることも確実にする。本提案の技法は、例えば、たとえ、補助負荷が通信能力を有しないか、又は（例えば、不適合、旧式ソフトウェア、期限切れライセンス、若しくは送信器の欠如のゆえに）通信をドライバへ伝送することができない場合でも、アクションがドライバによって実行されることを可能にする。
【0015】
補助負荷は、追加の能力を一次負荷に提供するために用いられてもよい。例えば、補助負荷は、感知、通信、又は記憶能力を、ドライバが一部を成すシステムに提供してもよい。例によっては、補助負荷は一次負荷のパラメータを感知してもよく、メータとして機能してもよい。それゆえ、接続された一次負荷を有するドライバにオプションとして追加される補助負荷は、一次負荷がよりコンパクトになることを可能にし得るが、その理由は、望ましいが、場合によっては必須でない一次負荷の能力が、必要に応じて接続されることができる補助負荷に外部調達されてもよくなるためである。
【0016】
本発明の諸実施形態は、照明システム又は設備において利用されるときに特に有利である。それゆえ、ドライバは照明ドライバであってもよい。具体的には、少なくとも、通例、レトロフィット位置などの、ライト設置位置における制約された空間／重量要求の理由で、照明システムは一次負荷及び補助負荷を特に必要とすることが認識された。想定される照明システムでは、一次負荷は光源（例えば、ＬＥＤ、ＬＥＤストリング、又はハロゲン電球を含む）であり、場合によっては、何らかの感知及び通信ハードウェア、並びに補助負荷が、光源のため、又はドライバのための追加の監視／制御／通信を提供する。
【0017】
補助負荷はまた、一次負荷の照明機能に関連しない感知／制御／通信フィーチャを提供してもよい。特定の諸実施形態は、照明システムが、建物内の空気質を監視する必要などの、ドライバの近傍の人又はデバイスの他の必要を満たすセンサ及び通信デバイスのための便利なホスティングプラットフォームとして機能することができることを想定している。
【0018】
諸実施形態は、補助負荷がドライバに接続及びドライバから切断されてもよく、これにより、モジュール性をもたらすため、ドライバを備えるシステムのための高度のコンフィギュアビリティを可能にする。接続又は切断に応じてアクションを実行することは、それに応じて、ドライバがシステムの新たなコンフィギュレーションに従って応答することを可能にする。
【0019】
好ましくは、一次出力部に供給される最大電力は、補助出力部に供給される最大電力よりも大きい。それゆえ、一次負荷は補助負荷よりも多くの電力をドライバから引き出すことができてもよい。これは、有利に、補助負荷がドライバに接続されたときに、ドライバの一次的な意図された動作が維持されることができることを確実にする。これはまた、補助負荷が、（通常、より重要な）一次負荷によって必要とされる電力を流用しないことも確実にし得る。
【0020】
諸例では、一次出力部に供給される最大電力は、補助出力部に供給される最大電力よりも少なくとも１０倍大きくてもよい。このような実施形態は、補助出力部における負荷（例えば、センサ）によって引き出される電力が、一次負荷（例えば、光源）に供給される電力よりも著しく小さいため、有利である。
【0021】
好ましくは、一次負荷は光源である。例えば、一次負荷はＬＥＤストリングなどの発光負荷であってもよい。以前に説明されたように、諸実施形態は、照明設備において利用されるときに特に有利である。
【0022】
ドライバは、オプションとして、補助電力出力部に接続された補助負荷に供給される電力を制御可能に遮断又は制限するように構成された電力制限部を更に備える。このように、ドライバコントローラによって実行されるアクションのうちの１つは、補助負荷に供給される電力を遮断又は制限することであってもよい。これは、補助負荷の電力消費が制御されることを可能にし、認可されていない、又は許可されていない負荷が、電力をドライバから引き出さないよう、ドライバから切断されることを可能にし得る。
【0023】
ドライバコントローラによって実行される少なくとも１つのアクションは、補助負荷のための識別信号の利用可能性(availability)を判定することを含んでもよい。識別信号は、ドライバが（或る時点で）補助負荷のための識別信号を得ることができる場合に、利用可能であると考えられる。
【0024】
識別信号の利用可能性及び／又は利用不可能性(non-availability)は、ドライバコントローラによって実行される更なるアクションに影響を及ぼすことができ、これにより、ドライバのコンフィギュアビリティ及びモジュール性を高める。更に、一実施形態は、接続／切断が生じたときに識別信号をチェックすることのみ含んでもよく、これにより、ドライバの電力消費を低減する。
【0025】
ドライバコントローラによって実行される少なくとも１つのアクションは、識別信号の要請を補助負荷へ送信することを含んでもよい。それゆえ、ドライバコントローラは識別信号のチェックを能動的に実行してもよい。このような要請を実行することは、識別信号及びそれに応じて実行される任意のアクションのセキュリティを高め得る。
【0026】
好ましくは、識別信号は補助負荷のためのデジタル的に可読の識別情報を含み、ドライバは、識別信号が利用可能であると判定したことに応じて、補助負荷のためのデジタル的に可読の識別情報を処理し、補助負荷の少なくとも１つの許可を決定するように構成された許可チェッカ(permission checker)を更に備える。
【0027】
例として、識別信号は、補助負荷のためのデジタル的に可読の識別情報を含んでもよく、ドライバは、デジタル的に可読の識別情報を包含する識別信号の利用可能性に応じて、補助負荷のためのこのデジタル的に可読の情報を処理し、ドライバに関する補助負荷の少なくとも１つの許可を決定するように構成された許可チェッカを更に備える。
【0028】
一実施形態では、許可チェッカは、デジタル的に可読の識別情報が、補助負荷の少なくとも１つの許可を決定するべく、信頼できるライセンス付与機関によって生成されたライセンスデータを含むかどうかを検証するための暗号手段を用いるように構成されている。
【0029】
即ち、許可チェッカは、デジタル的に可読の識別情報が、補助負荷の少なくとも１つの許可を決定するべく、信頼できるライセンス付与機関によって生成されたライセンスデータを含むかどうかを判定してもよい。
【0030】
例によっては、識別情報は、製造通し番号などの、補助負荷の精度の高い識別(identity)を含む。他の、又は更なる諸実施形態では、識別情報は、例えば、補助負荷が特定の種別の負荷の一員であることを識別する、補助負荷の分類識別を含んでもよい。別の例として、識別情報は、補助負荷が、信頼される、又はライセンスを受けたデバイスであるかどうかを識別してもよい。識別情報はライセンスデータを包含してもよい。
【0031】
これにより、補助負荷は、補助負荷のデジタル的に可読の識別情報（例えば、ライセンスに関する情報）、及び識別情報から決定された許可を用いて正当性を検証されてもよい。
【0032】
一実施形態では、補助負荷の少なくとも１つの許可は、電力をドライバから引き出すための許可を含み、ドライバコントローラは、補助負荷が、電力をドライバから引き出すための許可に関連付けられない場合、補助電力出力部に接続された補助負荷に供給される電力を遮断又は制限するように構成されている。
【0033】
諸方法は、補助負荷がどのように電力を受電するか、あるいはドライバ、一次負荷、及び／又はドライバを備えるシステム全体と他の仕方で相互作用することができるかを安全に制御することを含む。これは、認可されていないデバイス（例えば、ライセンスを受けていないデバイス）が、システム、ドライバ、及び／又は一次負荷と相互作用するのを禁止することに役立ち得、これにより、セキュリティ及び／又はコンフィギュアビリティの層を提供する。例えば、諸方法は、認可されていないデバイスが、ドライバの近傍の他のシステム又は人のセキュリティ又はプライバシを攻撃するためにドライバからの電力を使用する能力を抑制し得る。
【0034】
異なる補助負荷はドライバに関する異なる許可を有してもよい。異なる許可は、例えば、補助負荷に関連付けられたライセンスのレベルに依存してもよい。
【0035】
更なる例として、ドライバコントローラによって実行される少なくとも１つのアクションは、接続された補助負荷によって引き出される最大電力を制限すること、接続又は切断された補助負荷の識別を決定すること、接続又は切断された補助負荷の分類タイプを決定すること、補助負荷が補助電力出力部に接続されたか、又はそれから切断されたことを示す出力信号を生成すること、一次負荷の電力引き出し(power drain)と補助負荷の電力引き出しとを比較すること、タイマを開始又は終了すること、金銭トランザクションを開始又は終了すること、補助負荷のための認可チェックを実行すること、補助負荷のための認可チェックを実行し、チェックが、補助負荷が認可されていることを検出しなかった場合、警告信号を送信すること、及び補助負荷のための認可チェックを実行し、チェックが、補助負荷が認可されていることを検出しなかった場合、警告信号を送信することであって、警告信号が一次負荷の動作を、警告を示すように制御する、こと（例えば、一次負荷が光源である場合、警告信号は、光源を赤く明滅するよう制御することであってもよい）、のうちの１つ以上を含んでもよい。
【0036】
それゆえ、ドライバコントローラは、補助出力部における電力消費の変化によって示されるとおりの、ドライバへの補助負荷の接続／切断に応じて任意の数のアクションを実行してもよい。好ましくは、アクションは補助負荷に関して実行され、これは、有利に、ドライバコントローラが補助負荷の接続／切断に適切に応答することを確実にする。
【0037】
諸例では、少なくとも１つのアクションは一次負荷に関して実行されてもよい。それゆえ、更なる例として、補助電力出力部における電力消費の変化が生じたと判定したことに応じて、ドライバコントローラによって実行される少なくとも１つのアクションは、一次負荷に供給される電力を遮断又は制限すること、一次負荷をスタンバイ（又はスリーブ）状態に設定することであって、例えば、一次負荷は、認可されていない補助負荷を判定すると、スタンバイ状態に入ってもよく、及び／又は認可された補助負荷を判定すると、再起動されてもよい（スタンバイ状態を抜ける）、設定すること、補助負荷を接続又は切断したときの一次負荷の動作パラメータを決定すること、例えば、強度又は様式を変更するなどの、制御コマンドを一次負荷に提供すること、のうちの任意の１つ以上を含んでもよく、一次負荷が光源を駆動する場合、少なくとも１つのアクションは、光源に関連付けられた色、強度、色温度、変調、及び／又は照明場面を変更すること、例えば、タイムアウトシーケンス又は試運転プロセスなどの、ドライバコントローラ内の既定の制御アルゴリズムをトリガすること、試運転プロセスを開始し、ドライバコントローラ内に記憶された既存の制御コマンドプログラムの内容を変更すること、上述されたように、一次負荷を制御することによって警告信号又は確認（例えば、視覚又は聴覚出力）を提供すること、あるいはこれらの任意の組み合わせを含んでもよい。このような例は、補助電力出力部における電力消費の変化が生じたと判定することに基づいて一次負荷が制御され得るため、有利である。特に、試運転プロセスを開始することは有利である。一次負荷が光源であるときには、光源を駆動するドライバのドライバコントローラは、センサデバイス、例えば、（例えば、認可され、試運転のための正しい資格を有する）光センサの接続を判定し、判定したことに応じて、試運転及び／又は較正のアクションを実行してもよい（アクションは、例えば、色を発すること、強度を変更すること、又は可視光通信を実行することである）。別の例、特に、認可されていない、又は資格のない補助負荷が接続されたと判定されたときは必ず、一次負荷の動作を保護するために、一次負荷に供給される電力を遮断又は制限すること、及び切断時にはその逆を行うことが有利であり得る。
【0038】
識別信号は、近距離通信プロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）プロトコル、デジタル調光照明インターフェース（Digital Addressable Lighting Interface；ＤＡＬＩ（登録商標））プロトコル、汎用非同期受信機／送信機（Universal Asynchronous Receiver/Transmitter protocol；ＵＡＲＴ）プロトコル、ＵＳＢプロトコル、Ｉ２Ｃプロトコル、及びパワーオーバーイーサネット（Power over Ethernet；ＰｏＥ）プロトコルのうちの１つに従うものであってもよい。
【0039】
それゆえ、識別信号は、任意の好適な有線又は無線通信プロトコルを用いてドライバに提供されてもよい。セキュリティ及び改善された信頼性のためには、有線通信プロトコルを用いることが特に有利であろう。この場合、識別信号は、補助電力出力部のためのコネクタを通って延びる導線を介してドライバコントローラに提供される。これはまた、識別信号をドライバコントローラに渡すために必要とされる配線及び／又は部品（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＮＦＣ受信器）の量も低減させるであろう。
【0040】
ドライバは、ドライバと補助負荷との間の通信チャネルを介して識別信号を受信するように構成されていてもよい。具体的には、補助負荷は、独立デバイス（識別信号を生成してもよい）とドライバとの間で、識別信号などのメッセージをルーティングするように構成されていてもよい。
【0041】
１つのこのような実施形態では、ドライバは、補助出力部へ延びる導線の対を備えてもよく、これは、導線のこの対のみを通じて電力送達機構及び双方向性通信機構を組み合わせるＤＡＬＩ（登録商標）バスプロトコルを用いる。別の実施形態では、補助電力出力部のためのコネクタを通って延びる４本の導線が存在してもよく、２本の導線は電力線及び接地線であり、他の２本の導線は、ＵＡＲＴ、ＵＳＢ、又はＩ２Ｃなどの電気プロトコルを用いた、双方向性通信のために用いられる。
【0042】
好ましくは、ドライバは、照明設備のためのドライバ、即ち、照明ドライバであり、一次電力出力部は、照明設備の光源に接続するように構成されている。特定の諸実施形態では、補助電力出力部は、照明設備のための感知、制御、通信、又は監視能力を提供する補助負荷に接続するように構成されている。
【0043】
上述されたドライバを備える照明設備であって、一次電力出力部が、照明設備の光源に接続するように構成されており、補助電力出力部が、照明設備（又は照明設備の近傍の区域）のための感知、制御、通信、又は監視能力を提供する補助負荷に接続するように構成されている、照明設備が提供されてもよい。
【0044】
また、ドライバであって、ドライバの一次負荷に電気的に接続するように構成された一次電力出力部と、ドライバの補助負荷に電気的に接続するように構成された補助電力出力部と、電力を一次電力出力部及び補助電力出力部に供給するための電源と、を有するドライバの制御方法であって、補助負荷が補助電力出力部に接続又は切断されることによって生じた、補助電力出力部における電力消費の変化があるかどうかを判定するステップと、電力消費の変化が生じたと判定したことに応じて、補助負荷及び／又は一次負荷に関する少なくとも１つのアクションを実行するステップと、を含む、制御方法が提案される。
【0045】
少なくとも１つのアクションは、上述されたもののうちの任意のものを含んでもよい。
【0046】
制御方法は、補助負荷の決定された少なくとも１つの許可に基づいて、ドライバの補助電力出力部に接続された補助負荷に供給される電力を制御可能に制限するステップを更に含んでもよい。
【0047】
制御方法は、補助負荷の決定された少なくとも１つの許可に基づいて、ドライバの一次電力出力部に接続された一次負荷に供給される電力を制御可能に制限するステップを更に含んでもよい。
【0048】
また、コンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータプログラムコード手段が、コンピュータプログラムがコンピュータ上で実行されると、上述された方法を実行するように構成されている、コンピュータプログラムが提案される。
【図面の簡単な説明】
【0049】
ここで、本発明の実施例が、添付図面を参照して詳細に説明される。
【図1】本発明の一実施形態に係るドライバを示す。
【図2】本発明の一実施形態に係るドライバを示す。
【図3】一実施形態に係る補助出力部における電力消費の変化を検出する方法を示す図である。
【図4】補助負荷のプラグの差し込み又はプラグの引き抜きに起因する電力消費の変化を検出するためのデバイスの回路図を示す。
【図5】一実施形態に係る方法を示す。
【図6】本発明の修正された一実施形態に係るドライバを示す。
【図7】本発明のなお更に修正された一実施形態に係るドライバを示す。
【発明を実施するための形態】
【0050】
本発明のコンセプトによれば、一次負荷のための一次出力部と、補助負荷のための補助出力部とを有するドライバが提案される。ドライバの電源が電力を両方の出力部に供給する。補助出力部における電力消費の変化を検出することによって、補助負荷の接続又は切断が判定され、電力消費のこの変化に応じてドライバコントローラによってアクションが実行される。
【0051】
諸実施形態は、ドライバへの補助負荷の接続又は切断が当該ドライバの補助出力部における電力消費の変化を生じさせ得るとの認識に少なくとも一部基づく。ドライバはこの変化に反応してアクションを実行し、これにより、新たに接続された又は切断された補助負荷に応答してもよい。
【0052】
例示的な諸実施形態は、例えば、ドライバが光源の電圧供給を提供し、制御する、照明設備において利用されてもよい。ドライバ及び／又は光源は、サイズ、部品予算、及び／又は重量の点で制約され得るため、光源のためのドライバへの補助負荷の接続を可能にすることは特に有利である。それゆえ、補助負荷を接続することは、光源又は関連付けられたドライバのサイズ、部品予算、及び／又は重量に悪影響を及ぼすことなく、より高いコンフィギュアビリティ及びモジュール性をもって追加のアクション（例えば、通信、感知、又は監視）を実行する能力を光源に与える。
【0053】
本明細書で使用するとき、用語「一次負荷」は、ドライバが出力電源を提供するように設計された負荷である、ドライバによって駆動される一次負荷又は主負荷を指す。例えば、照明設備の一次負荷は、典型的には、光源であろう。用語「補助負荷」は、二次負荷などの、電力をドライバから引き出してもよい任意の他の補足又はオプションの負荷を指すために用いられる。照明設備のために、補助負荷は、周囲光センサ、温度センサ、電気メータ、照明機能には関連しないが、照明システムの近傍における人又は他のデバイスの他の必要を満たすセンサ、などのうちの任意の１つ以上を含んでもよい。
【0054】
【0055】
一次電力出力部４又は一次電力インターフェースが電源３に電気的に接続されており、一次負荷５又は一次デバイスに電気的に接続可能である。一次負荷５は一次電力出力部を介して電力を電源３から引き出す。実施形態によっては、一次電力出力部は一次負荷に、固定して、又は永久的に接続されている。一次負荷５は、ドライバ２自体の電気部品と同じ回路ボード基板上に装着された、ＬＥＤストリングなどの、光源を含んでもよい。
【0056】
補助電力出力部６又は補助電力インターフェースが同じく電源３に電気的に接続されており、補助負荷７又は補助デバイスに電気的に接続可能である。具体的には、補助負荷７は、電力を電源３から引き出すために補助電力出力部６に接続可能である。好ましくは、補助電力出力部は、補助負荷７に選択可能に接続可能である（即ち、補助電力出力部は、補助負荷が補助電力出力部に接続又は補助電力出力部から切断することを可能にするように設計されている）。
【0057】
電源３は、オプションとして、電力を補助電力出力部に送達するように構成された専用電源部品（例えば、変圧器、バックコンバータ、又は出力短絡から保護するための電流制限器）を含む。それゆえ、補助電力出力部に供給される電力は、一次電力出力部に供給される電力とは異なってもよく、例えば、それは異なる電圧を有することができる。
【0058】
電源３は、例えば、出力部４、６ごとに１つずつ、２つの異なる変圧器を包含してもよい。好ましくは、各出力部４、６は少なくとも１つの技術構成要素を他の出力部４、６と共用し、例えば、それらはどちらも同じ主電源入力コネクタ又は電池から電力を引き出す。
【0059】
一次電力出力部４は、ドライバの一次負荷に電気的に接続するためのインターフェースである。補助電力出力部６は、ドライバの補助負荷に電気的に接続するためのインターフェースである。
【0060】
【0061】
補助負荷は、プラグ取付具８を用いて、例えば、補助電力出力部６に接続してもよい。プラグ取付具８は任意の周知の電気コネクタから成ってもよく、例えば、補助電力出力部６にそこから電力を引き出すべく接続するための１つ以上のピン、及びオプションとして、例えば、信号を監視するか、又はデータを交換するための追加のピンを含む、任意の周知の形式のものであってよい。したがって、補助電力出力部６は、補助負荷７からプラグ取付具８を受容するためのコンプリメンタリ（complementary）インターフェース（例えば、ソケット）を含んでもよい。
【0062】
電源３は、電力を第１の形態から第２の形態へ変換するための任意の周知の電力変換装置を含んでもよく、第２の形態は、少なくとも一次負荷を駆動するために適している。例えば、電源３は、主電源９を、接続された一次負荷５を駆動するための電源、及び接続された補助負荷を駆動するための電源に変換してもよい。好適な電力変換器は当該技術分野において周知であり、例えば、スイッチトモード電源、変圧器、整流器、フィルタ、フィラメントエミュレーションユニットなどのうちの１つ以上を含んでもよい。
【0063】
ドライバ２は、ドライバの動作を制御するように構成されたドライバコントローラ１０を更に備える。例えば、ドライバコントローラ１０は、電源によって一次／補助出力部に供給される電圧及び／又は電流レベルを制御する、電力が一次電力出力部及び／又は補助電力出力部に供給されるかどうかを制御する、などのように構成されていてもよい。
【0064】
一実施形態では、ドライバコントローラ１０は、ドライバの動作を制御するために用いられる制御信号ＳＣＯＮを受信するように構成されている。特定の例では、制御信号ＳＣＯＮは、電源３によって一次出力部４に供給される電力の所望の電圧レベルを示し、これにより、一次負荷５の所望の動作を示してもよい。例えば、一次負荷５が光源を含む場合、制御信号ＳＣＯＮは所望の調光レベルを表してもよく、又は一次負荷がスピーカを含む場合、制御信号ＳＣＯＮは所望の音量レベルを表してもよい。
【0065】
本発明は、補助負荷７が補助電力出力部６に接続又は切断された点又は時間を検出し、それに応じてアクションを実行する方法に関する。
【0066】
それを行うために、ドライバコントローラ１０は、補助出力部における電力消費の変化を検出するように構成されている。電力消費の変化を検出したことに応じて、ドライバコントローラ１０は、補助負荷がドライバ２に接続された、又はドライバ２から切断されたと判定し、アクションを実行する。例えば、補助出力部における電力消費の（突然の、又は瞬間的な）増大は、補助負荷がドライバに接続されたこと（及びドライバから電力を引き出したこと）を示してもよく、それに対して、補助出力部における電力消費の（突然の、又は瞬間的な）減少は、補助負荷がドライバから切断されたこと（及びこれにより、もはやドライバから電力を引き出さないこと）を示してもよい。
【0067】
多種多様の可能なアクションが想定され、補助負荷を識別すること、補助負荷を認証すること、補助負荷が、信頼されるシステム構成要素として識別されることができない場合、補助負荷への電力を断ち、特定のレベルの電力を消費するための補助負荷の権利を主張する有効なライセンスが識別信号内で利用可能でない場合、補助負荷への電力を制限すること、補助出力部における電源の電圧レベルを調整すること、補助負荷が接続されたことを示す出力信号を生成すること、一次負荷及び／又は補助負荷による最大電力引き出しを制御すること、補助負荷の各接続／切断をメモリ内に記録することなどを含んでもよい。
【0068】
電力消費を監視する、又は補助負荷における電力消費の変化を検出する数多くの想定される方法が存在する。一例が、補助負荷７のプラグ取付具８の接続前における補助出力部６を示す図３に示されている。代替的に、補助負荷における電力消費の変化を検出することは、ドライバによって一次負荷に供給される電力を監視することによって行われてもよい。
【0069】
ここで、プラグ取付具８は第１のピン８Ａ及び第２のピン８Ｂを含む。補助出力部６は、第１のピン８Ａ及び第２のピン８Ｂをそれぞれ受け入れるための第１のピンソケット３１及び第２のピンソケット３２を含む。プラグ取付具が補助出力部に接続されると、電流が第１のソケット３１と第２のソケット３２との間で（即ち、補助負荷を介して）流れることができる。それゆえ、補助出力部のピンソケットの間における電流の流れの存在又は不存在は、補助出力部への補助負荷の接続又は切断を示してもよい。言い換えれば、補助出力部内における電流の流れの変化は、補助出力部における電力消費の変化を示す。
【0070】
それゆえ、（プラグ取付具を介した）補助負荷の接続又は切断によって生じた電力消費の変化を検出するために、ドライバコントローラは電流感知デバイス３５を含んでもよい。電流感知デバイス３５（例えば、電流計）は、それを通る電流の流れを検出するように構成されており、補助出力部を通る、又は補助出力部への電流の流れを検出するために接続されてもよい。電流感知デバイス３５は、例えば、電源３と補助出力部６との間において、補助出力部に直列接続されてもよい。
【0071】
好ましくは、電流感知デバイス３５は、電流が検出されているのか（即ち、補助負荷が接続されているのか）、それとも電流が検出されていないのか（即ち、補助負荷が接続されていないのか）を示す２値信号を提供する。
【0072】
少なくとも１つの実施形態では、電流感知デバイスは、検出された電流が（０ｍＡよりも大きい値である）所定の電流値を上回るのか、それとも下回るのかを示す２値信号を提供する。これは、電流感知デバイスが、補助負荷が接続されたかどうかを判定する際に、（例えば、一次出力部への電源の容量結合によって生じる）可能なトリクル又は漏れ電流を考慮することを可能にし得る。所定の電流値を上回る検出電流は、補助負荷が補助出力部に接続されていることを示し、所定の電流値を下回る検出電流は、補助負荷が補助出力部に接続されていないことを示す。所定の電流値は、０．０１ｍＡ～１ｍＡの領域内、例えば、０．１ｍＡ前後であってもよい。
【0073】
一実施形態では、電流感知デバイスは、追跡又は監視された電流が所定の電流値を横切る際にのみ信号を提供するように構成されている。これは、（例えば、瞬間的時点における）補助出力部への補助負荷の接続及び／又は切断の明示的インジケーションを提供してもよい。例えば、電流が所定の電流値を（高から低へ）横切った場合、これは、補助負荷が補助出力部から切断されたことを示してもよい。
【0074】
測定される電流は、例えば、ＲＭＳ電流値（例えば、補助負荷のためのＡＣ電流電源の場合）、又は実際の値（例えば、補助負荷へのＤＣ電流電源の場合）であってもよい。
【0075】
図４は、電流感知デバイス３５の一実施形態をより詳細に示す。
【0076】
補助出力プラグ６は、周知の仕方で電力線路４７及び接地線路４８を用いて、電源ＶＳＵＰを補助負荷７へ送達する。電源ＶＳＵＰの電圧は２４Ｖの領域内にあってもよい。
【0077】
電力を消費する補助負荷７の存在は、電流がプラグ６を通って流れることができるため、プラグ６と接地線路４８との間に接続された感知抵抗器４１にわたって電圧差を生じさせる。この差は増幅器４２によって増幅され、増幅された電圧は比較器４３の第１の入力部に入力される。この比較器４３は、増幅された電圧Ａを、比較器４３の第２の入力部において受け取られた基準電圧Ｂと比較する。比較器は、増幅された電圧Ａが基準電圧Ｂよりも大きいのか（例えば「１」）、それともそれ以下であるのか（例えば「０」）を示す２値信号を提供する、出力「Ａ＞Ｂ」を有する。比較器は、任意の周知の方法に従って、例えば、演算増幅器構成を用いて構成されてもよい。出力された２値信号Ａ＞Ｂはマイクロコントローラ１０のデジタル入力ピンに送られてもよい。
【0078】
比較器４３によって出力された２値信号Ａ＞Ｂは、電流が補助出力部６を通って流れているかどうか、及びこの電流が所定の電流値を上回っているかどうかを示す。
【0079】
所定の電流値は、感知抵抗器４１及びバイアス抵抗器４４、４５のための適切な値を選択することによって変更されることができる。感知抵抗器４１の値を変更することは、同じ電流に対する増幅電圧Ａを変える。バイアス抵抗器の値を変更することは基準電圧Ｂを変える。抵抗器の値の選択はまた、増幅器４２の増幅係数又は利得も考慮するべきである。
【0080】
電流感知デバイス３５の部品に電力を供給するために、低電力線路４９も電源によって提供されてよい。基準電圧Ｂは、分圧器構成で低電力線路４９と接地線路４８との間に配置されたバイアス抵抗器４４及び４５を用いて作り出される。代替的に、バイアス抵抗器４４、４５は電力線路４７と接地線路４８との間に配置されてもよい。低電力線路は３．３Ｖの領域内の電圧供給を搬送してもよい。実施形態によっては、低電力線路４９は、電力線路４７に結合された変圧器によって電力を供給される。
【0081】
２値信号が低から高、又はその逆に切り替わることによって示されるとおりの、補助出力部における電力消費の変化を検出したことに応じて、ドライバ２は、補助負荷がドライバ２に接続又は切断されたと判定する。
【0082】
それゆえ、本提案のコンセプトは、ドライバが、補助負荷の接続／切断を能動的に監視するための専用外部要素（例えば、光感受性要素）を備えることを必要としない。むしろ、電力消費の変化の検出は、補助負荷の接続を検出する、単純で、信頼性が高く、電力効率のよい仕方を提供する。
【0083】
以上において簡単に識別されたように、ドライバコントローラ１０は、補助負荷の接続及び／又は切断を示す補助出力部における電力消費の変化を検出したことに応じて少なくとも１つのアクションを実行する。それゆえ、ドライバコントローラ１０は補助負荷の接続に応答する。
【0084】
図５は、一実施形態に係るドライバコントローラ１０によって実施される方法５０を示す。
【0085】
方法５０は、補助出力部における電力消費を監視するステップ５１を含む。ステップ５２において、電力消費の変化が生じたかどうかが判定される。新たな補助負荷の取り付け又は取り外しを示す電力消費の変化が生じたと判定したことに応じて、ドライバコントローラはアクションを実行する。
【0086】
ここで、アクションは、補助負荷７のための識別信号を要請するステップ５３、及び（利用可能である場合）補助負荷のための識別信号を受信するステップ５４を含む。
【0087】
識別信号は、好ましくは、補助負荷のためのデジタル的に可読の識別情報を搬送する。このデジタル的に可読の識別情報は、通例、補助負荷の、又は補助負荷に関連付けられたライセンス、分類、又は識別に関する情報を含む。デジタル的に可読の識別情報は、後に説明されるように、補助負荷の１つ以上の許可を識別するために用いられてもよい。
【0088】
ステップ５３は、補助負荷のための識別信号が利用可能であるかどうか（即ち、ドライバが識別信号を得ることができるかどうか）を判定することを含むと理解されてもよい。これは、例えば、識別信号が送信されることになるとのインジケーションを受信すること、又は識別信号自体の受信を含んでもよい。
【0089】
識別信号を要請するステップ５３はオプションとしてのものであり、方法５０は、代わりに、例えば、所定の時間長、識別信号を受信するのを待つこと、又は補助負荷が電力を所定の仕方で引き出し始めるなど、補助負荷が、識別信号の受信を（おそらく）もたらすことになる相互作用のシーケンスを開始するのを待つことを含んでもよい。それゆえ、識別信号の受信は受動的に実行されてもよく、ドライバコントローラと、識別信号を供給するデバイスとの間の通信は、双方向性又は（例えば、補助負荷からのみの）一方向性であってもよい。
【0090】
しかし、識別信号を要請することは、補助負荷をドライバに接続することのセキュリティを改善してもよい。例えば、要請は符号化されてもよく、符号化された要請は、認可された補助負荷、正しいプログラムを実行している補助負荷、又は承認されたライセンス付与機関（クラウドコンピューティングサーバなど）と通信する能力を有する補助負荷によってのみ復号可能である。別の例では、要請は、補助負荷がドライバのための適切な通信プロトコルに準拠していることを確実にするためのハンドシェークプロトコルの一部を形成してもよい。
【0091】
一例では、要請は、認可されたライセンス付与機関によって処理されるべきナンスを包含してもよい。それゆえ、補助負荷（又は識別信号を提供する他のデバイス）は、ナンスを、適切な処理及び認可のために、認可されたサーバに渡すことを必要としてもよく、処理されたナンスは識別情報としてドライバコントローラ１０に返される。これは、デバイスが、認可されたデバイスを詐称するか、又は他の仕方でその機能を果たすことができる可能性を低下させる。
【0092】
識別信号は、（例えば、ＵＡＲＴ ｒｘ／ｔｘ線又は他の通信チャネルを用いて）補助負荷７から直接得られてもよい。即ち、補助負荷７は、識別信号をドライバコントローラ１０に提供するように構成されていてもよい。
【0093】
例によっては、補助電力出力部６は、補助負荷７とドライバコントローラ１０との間の通信を可能にするように構成されている。例えば、補助電力出力部は、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ；ユニバーサルシリアルバス）プロトコル、ＵＡＲＴ（万能非同期受信機／送信機）プロトコル、又はＤＡＬＩ（登録商標）（デジタル調光照明インターフェース）プロトコルに準拠した要素を含んでもよい。
【0094】
他の諸実施形態では、補助負荷は、Ｂｌｕｅｔｏｏｔｈ（登録商標）及び／又は近距離無線通信技法などの、無線通信方法を用いてドライバコントローラと通信するように構成されている。これにより、ドライバは、少なくとも補助負荷と無線通信するように構成された無線送信器及び／又は受信器を含んでもよい。補助負荷７とドライバコントローラ１０との間の通信を可能にするための他の好適な有線又は無線プロトコルは当業者に周知となるであろう。
【0095】
電力消費の変化を判定するステップ５２と、識別信号を要請し、受信するステップ５３、５４との間の所定の時間遅延（図示せず）が存在してもよい。これは、有利に、ドライバコントローラが、識別信号が供給されることを期待する前に、補助負荷７が、必要とされる始動シーケンスを実行することを可能にしてもよい。所定の時間遅延は、０．１～６００秒の領域内、例えば、６０秒前後であってもよい。これは、有利に、補助負荷の始動手順が実行されることを可能にするために十分に長く、一方で、補助負荷による潜在的電力引き出しを低減し、アクションがドライバコントローラによって実行される前に補助負荷が悪意のあるプロセスを実行する可能性を減少させると認識された。
【0096】
方法５０は、識別信号、及び特に、識別信号によって搬送されるデジタル的に可読の識別情報に基づいて、ドライバ２、一次負荷５、及び／又はドライバ２を包含するシステムの他の要素に関する、補助負荷７のための少なくとも１つの許可を決定するプロセス５５を更に含んでもよい。それゆえ、プロセス５５は、デジタル的に可読の識別情報を処理し、少なくとも１つの許可を決定することを含んでもよい。
【0097】
識別信号及び／又は識別情報がステップ５３／５４において提供されない場合、プロセス５５は、許可が補助負荷に関連付けられるか、又は他の仕方で認められるべきでないと決定する。
【0098】
プロセス５５は、識別情報が、信頼できるライセンス付与機関によって発行されたライセンスデータを包含するかどうかを判定するための暗号手段を用いるステップ５６を含んでもよい。ライセンスデータは、例えば、識別情報の情報ブロック若しくはパケット又は識別情報の暗号化方法から成ってもよい。情報ブロックが改ざんされていないこと、及び即ち、信頼できるライセンス付与機関によって作成されたことを検証するために、プロセス５５は、ブロックの完全性、及び／又はブロック上の署名の正当性を暗号によってチェックすることを含んでもよい。これは、例えば、ドライバの製造時に、ドライバのメモリ内に以前に記憶されたサーバのための公開鍵情報を用いて、及びオプションとして、外部サーバ（ライセンス付与機関など）との通信を介して実行されてもよい。外部サーバとの通信はチャレンジ－レスポンスシナリオで（例えば、ナンスを用いて）実行されてもよく、ドライバ２から直接、又は補助負荷７を介して実行されることができるであろう。
【0099】
プロセス５５はまた、ステップ５６の結果に基づいて、許可を決定するステップ５７を含んでもよい。識別情報が、信頼できるライセンス付与機関によって発行されたライセンスデータを包含しない場合、許可は補助負荷に関連付けられない、又は他の仕方で付与されない。識別情報が、信頼できるライセンス付与機関によって発行されたライセンスデータを実際に包含する場合、ライセンスデータ、及び／又は識別情報の他の要素に基づいて補助負荷の許可が決定されてもよい。
【0100】
許可チェッカは、実施形態によっては、補助負荷のためのライセンスの正当性又は範囲をチェックし、それに基づいて許可を決定するように構成されたライセンスチェッカであると考えられてもよい。
【0101】
例えば、識別情報は、補助負荷のための所望の許可に関する情報を包含してもよい。別の例では、ライセンスデータ（暗号チェックによって決定されてもよい）に関連付けられたライセンスのレベルが補助負荷のための許可を規定してもよい（例えば、より高いレベルのライセンスはより多くの許可に関連付けられる）。
【0102】
更に別の例では、通し番号又はライセンス詳細などの、識別情報の要素が、（データベースサーバの）データベース内に記憶された情報と比較されてもよい。データベースは、例えば、ルックアップテーブルにおいて、特定の通し番号、又は識別情報の他の要素を有する補助負荷に付与されるべき許可を列挙してもよい。例えば、特定の範囲内の通し番号を有する補助負荷は、第１の最大電力をドライバから引き出すことを許可されてもよく、それに対して、別の範囲内の通し番号を有する補助負荷は、第２の、より低い最大電力をドライバから引き出すことを許可されるのみであってもよい。データベースサーバは、例えば、クラウド－コンピューティングネットワークなどの分散ネットワーク内に配置されていてもよく、又は専用メモリ内など、ドライバ自体の内部に配置されていてもよい。
【0103】
一例では、ドライバ、一次負荷、及び／又は補助負荷の更なるパラメータが、許可を決定するために用いられてもよい。このような更なるパラメータは、ドライバの位置、ドライバの識別、ドライバの能力、一次負荷の能力、補助負荷の能力、ドライバに接続された負荷の数、識別信号が提供された回数、などのうちの任意の１つ以上を含んでもよい。データベースサーバのデータベース内に記憶されたルックアップテーブルが、これらの更なるパラメータに基づいて許可を決定するために用いられてもよい。それゆえ、補助負荷の許可は、（ドライバごとに変化するなど）ドライバ及び／又は補助負荷の他のパラメータに基づいて変化してもよい。
【0104】
一例では、識別情報又は識別信号は、識別情報が、信頼できるライセンス付与機関によって発行されたライセンス情報を包含すると判定された場合、又は認証されたライセンス情報が特定のレベルのものである場合に付与される、補助負荷の所望の許可を包含する。
【0105】
一般的に言えば、プロセス５５は、ドライバのための識別情報の信憑性の正当性を検証するステップ５６と、認証された識別情報、及びオプションとして、ドライバ／補助負荷の他のパラメータに基づいて補助負荷のための許可を決定するステップ５７とを含む。
【0106】
ステップ５３～５７はドライバの許可チェッカ（図示せず）によって実行されてもよい。実施形態によっては、許可チェッカはドライバコントローラ１０の一態様として形成されるが、他の諸実施形態では、許可チェッカは別個のプロセッサ又はコントローラである。
【0107】
暗号手段を用いる代わりに、より未熟な実施形態では、ステップ５６は、通し番号などの、補助負荷のための識別情報を（データベースサーバの）データベースのレコードと比較することを含んでもよい。識別情報がデータベースのレコード内に存在する場合、補助負荷は、上述されたように決定されてもよい、少なくとも１つの許可に関連付けられると決定される。この方法はシステムの単純性を高め、外部サーバ（信頼されるライセンス付与機関など）への依存性を低下させる。しかし、このようなシステムは、不都合に、通例、上述された信頼されるライセンス付与方法を用いて回避される、補助負荷の「詐称」を可能にし得る。
【0108】
好ましい一実施形態では、方法５０は、識別情報が、電力をドライバから引き出すための許可に関連付けられるかどうかを判定するステップ５８を含む。これにより、ステップ５８は、補助負荷が、電力をドライバ２の電源３から引き出すことを許可されるかどうかを識別してもよい。以上において詳述されたように、電力をドライバから引き出すための許可は、信頼できるライセンス付与機関によって発行されたライセンスデータを包含する識別信号のための識別情報に応じて付与されてもよい。
【0109】
この許可の利用可能性又は存在に応じて、本方法は、例えば、電源が補助電力出力部６に接続することを可能にすることによって、電力が補助負荷７へ流れることを許可するステップ５９Ａを含む。代替的に、電力が一次負荷へ流れることを許可する。このような許可が存在しない場合、本方法は、代わりに、補助負荷への電力の流れを制約するステップ５９Ｂへ進む。ステップ５９Ｂは、電力が補助負荷へ（例えば、補助電力出力部を介して）流れることを完全に禁止すること、又は単に補助負荷への最大電力を制限すること（例えば、トリクル電流に制限する）を含んでもよい。代替的に、電力が（例えば、一次電力出力部を介して）一次負荷へ流れることを禁止するか、又は単に一次負荷への最大電力を制限する（例えば、スタンバイ状態に制限する）。
【0110】
補助負荷への最大電力をトリクル電流に制限することによって、認可されていない補助負荷の動作が、（例えば、不十分な電力が供給されるため）防止され得るが、電力消費の変化が依然として監視され得るため、認可されていない補助負荷の切断は依然として検出されてもよい。このような切断を検出すると、新たな補助負荷が接続されることを可能にし、新たに接続された補助負荷が適切なアクションを実行することを許可するために、補助負荷に供給される電力が増大されてもよい。
【0111】
補助負荷及び／又は一次負荷への電力供給の制御は、例えば、電力制限部を用いて実行されてもよい。電力制限部は、制御可能に、補助電力出力部を（例えば、スイッチ若しくはトランジスタを用いて）電源から切断し、及び／又は電力を使用して一次電力出力部を駆動することを停止するか、補助電力出力部を接地電圧に接続するか、又は可変抵抗器の抵抗を制御するように動作可能であってもよい。他の方法も当業者に容易に理解されるであろう。
【0112】
それゆえ、ドライバコントローラ１０は、補助電力出力部に接続／補助電力出力部から切断された補助負荷の少なくとも１つの決定された許可に基づいて、（補助電力出力部における）補助負荷に供給される電源のレベルを制限又は制約するように構成されていてもよい。
【0113】
それゆえ、代替的に、ドライバコントローラ１０は、補助電力出力部に接続／補助電力出力部から切断された補助負荷の少なくとも１つの決定された許可に基づいて、（一次電力出力部における）一次負荷に供給される電源のレベルを制限又は制約するように構成されていてもよい。
【0114】
これにより、ドライバコントローラ１０は、補助負荷のための識別情報（即ち、識別信号）に基づいて、補助負荷（及び／又は一次負荷）が電力を電源３から引き出すことを認可するように構成されていてもよい。
【0115】
無論、補助負荷への電源の制約及び／又は制限は、補助負荷の許可を決定することとは独立して実行されてもよい。例として、ドライバコントローラは、補助負荷がこのような電源を受けることを許可されるよう決定されない限り、デフォルトで、負荷への電源を最初に制限してもよい。
【0116】
電力をドライバから引き出すための許可のみの代わりに、例によっては、補助負荷の少なくとも１つの許可は、電力をドライバの電源から引き出すための許可、ドライバコントローラと通信するため、又はそれドライバコントローラから特定のデータを得るための許可、一次負荷と通信するため、又は一次負荷から特定のデータを得るための許可、ドライバの動作を制御するための許可、一次負荷の動作を制御するための許可、のうちの任意の１つ以上を含む。
【0117】
それゆえ、補助負荷は、ドライバ／一次負荷のアクションを制御するために一次負荷及び／又はドライバと通信することができてもよい。補助負荷は、それを行うための許可を必要としてもよく、許可は、補助負荷の許可を決定するプロセスに従って付与されることができる。
【0118】
プロセス５５は、補助負荷に関連付けられる許可が存在しない（即ち、補助負荷は、ドライバ２に関するいかなるアクションを実行することも許可されない）と決定してもよいことは理解されるであろう。実施形態によっては、また、補助負荷のための識別信号が（例えば、所定の期間内に、又は明示的要請５３に応じて）提供されなかった場合、新たに接続された補助負荷はいかなる許可にも関連付けられないと仮定される。これは、有利に、未知の、認可されていない可能性のあるデバイスが電力をドライバから引き出すことを防止することになる。
【0119】
少なくとも１つの実施形態では、補助負荷のための識別情報がドライバ２に関するいかなる許可にも関連付けられないと決定された場合、方法５０は、警告信号を生成することを含んでもよい。警告信号は、クラウド－コンピューティングシステムなどの外部監視システム、一次負荷５に提供されるか、又はドライバ２の動作を制御するために用いられてもよい。
【0120】
実施形態によっては、警告信号は、ドライバ２に関する許可に関連付けられない負荷である、認可されていない補助負荷が、補助電力出力部６を介してドライバに接続されたことを示すよう一次負荷の動作を制御する。一次負荷の動作は、例えば、視覚（例えば、光）又は聴覚出力であってもよい。
【0121】
一次負荷が光源を含む一例では、警告信号は、光源によって出力される光のサイクル的な（即ち、周期的な）明滅を生じさせてもよい。一次負荷の動作の制御は、例えば、５時間前後などの、１～７時間の所定の期間にわたって提供されてもよい。例として、一次負荷の光源によって出力される光が、例えば、１～７時間の、所定の期間にわたって明滅させられてもよい（即ち、サイクル的にオン及びオフにさせられる）。光の周期的明滅は、例えば、所定の期間の間、１秒ごと、２秒ごと、又は５秒ごとに生じてもよい。明滅はまた、可視光通信信号であってもよい。
【0122】
諸実施形態では、警告信号はドライバ３及び／又は一次負荷の聴覚／視覚／触覚要素の動作を制御してもよい。好ましくは、聴覚／視覚／触覚要素は、特定の（時間又は空間）パターンを出力するように制御される。例えば、警告信号は、ドライバ及び／又は一次負荷の視覚要素（例えば、信号伝達ＬＥＤ）のライトを、時間に関して所定のシーケンスで、及び／又は所定の出力光配列で点灯させてもよい。別の例では、警告信号が、認可されていない負荷がドライバに接続されたことを示す場合、特定の音が聴覚要素によって発せられてもよい。
【0123】
ドライバ２は、補助負荷の許可、及び／又は警告信号を識別する聴覚／視覚／触覚出力を生成するように構成されていてもよい。これは、視覚的、聴覚的、又は触覚的に実行されてもよい。例えば、ドライバ２は、補助負荷の決定された許可のリストを出力するスクリーン（図示せず）を備えてもよい。これは、補助負荷をドライバに装着する容易性を高め、ユーザが正しい補助負荷を装着することを確実にし得る。
【0124】
これにより、本提案の諸実施形態は、有利に、補助負荷の装着者（即ち、補助負荷７をドライバ２に接続する者）に、彼らが、誤った、又は許可可能でない補助負荷７を使用していることについて教示する。
【0125】
識別信号が正当性検証のためにドライバに渡された回数、又は許可を有しない補助負荷が補助電力出力部に何回接続しようと試みたのかを監視するステップ（図示せず）が存在してもよい。このステップは、ドライバ自体によって、又はクラウド－コンピューティングシステムなどの、監視システムによって実施されてもよい。
【0126】
ドライバは、回数が所定の回数よりも多くなった、例えば、２回より多くなった、又は１０回より多くなった場合、第２の警告信号を生成するように構成されていてもよい。実施形態によっては、ドライバは、第２の警告信号が生成されたことに応じて、所定の期間にわたって補助負荷接続をもはやチェックしなくてもよい（即ち、補助電力出力部を遮断する）。
【0127】
また、さもなければ補助負荷への電力を切るであろう（例えば、ステップ５３～５９Ｂにおいて実行されるとおりの）チェック方法を迂回しつつ、認可されていない補助負荷をドライバに接続することを欲する、システムの潜在的攻撃者は、主電源電力切断攻撃を試みることができるであろうということも認識された。主電源電力切断攻撃は、ドライバをそれ自身の主電源から一時的に切り離し、これにより、ドライバを不活性（inert）にし、方法５０を実行できなくさせ、補助負荷を取り付け、その後、ドライバをその電源へ再接続することを含んでもよい。それゆえ、主電源電力切断攻撃は、ドライバが主電源電力から切断されているときに（即ち、アクティブでないときに）補助負荷をドライバに取り付けることを含む。
【0128】
このような攻撃から保護するために、ステップ５３以下と同様のチェック方法が、ドライバ２によって、それ自身の電源の中断後に実行されなければならない。それゆえ、ドライバが電源を投入されたときに、補助負荷の識別チェックがドライバによって実行されてもよい。このチェックは、それのためのトリガをドライバコントローラのパワーアップブート（power-up-boot）ソフトウェアコード内に含めることによって実施されることができるであろう。
【0129】
方法５０に関する他の変形例が、別の実施形態に係る、ドライバ２を有する、変更された照明設備１を示す、図６を更に参照して説明されることになる。
【0130】
ドライバ２は、ドライバ２及び補助負荷７とは別個の独立デバイス６０と通信するように構成されている。可能な独立デバイス６０の一例は携帯電話又はスマートフォンである。
【0131】
一実施形態では、方法５０のステップ５４において受信される識別信号は独立デバイス６０によって提供されてもよい。したがって、独立デバイス６０は、補助負荷のための識別信号を提供するように構成されていてもよい。いくつかのこのような実施形態では、補助負荷７はドライバ２及び／又はドライバコントローラ１０と直接通信することができなくてもよい。それゆえ、独立デバイス６０は、識別情報に関連付けられたステップのための上述された諸実施形態の補助負荷として機能してもよい。
【0132】
実施形態によっては、（独立デバイス６０によって生成された）補助負荷のための識別情報は認証のために認可サーバ６１に渡されてもよい。認可サーバは、識別信号がドライバ２に渡されるためのライセンスデータを生成してもよい。
【0133】
諸実施形態では、補助負荷の許可を決定するプロセス５５を実行する際に、許可チェッカは、補助負荷の識別信号のライセンスデータを暗号によってチェックするために認可サーバ６１と通信するように構成されていてもよい。許可チェッカ１０は、図６に示されるように、独立デバイス６０を介して、又は以前の実施形態において説明されたように、補助負荷を介して認可サーバ６１と通信してもよい。
【0134】
システムセキュリティを最大化するために、ドライバコントローラ１０の一態様として形成された許可チェッカは、独立デバイス６０がそれ自体では、許可チェッカによって受け入れ可能である（識別信号中の識別情報の）ライセンスデータを作成することができないように設計されてもよい。その代わりに、独立デバイス６０は、適切なライセンスデータを包含する識別信号を生成するために認可サーバ６１と連絡を取ることを必要とされてもよい。通例、このサーバは、クラウド－コンピューティングネットワーク又はクラウドコンピューティングサービスプロバイダなどの、インターネットを介して到達可能な、高度に安全な施設内にあることになる。
【0135】
認可サーバ６１の生の関与（live participation）を強制するための、ドライバ２のための１つの実施方法は、認可サーバ６１へ送信されなければならない（識別信号のための要請の一部分である）暗号ナンスを生成することであり、ナンスは、チャレンジ－レスポンスプロトコルにおけるチャレンジの役割を果たす。サーバ６１は、ナンスを用いて、次に許可チェッカに返される署名された暗号レスポンスを作成することができる。それゆえ、ナンスは、ステップ５３において発行される識別信号の要請の一部分の役割を果たし、署名された暗号レスポンスは、ステップ５４において提供される補助負荷の識別信号の役割を果たしてもよい。ナンスを用いることによって、いくつかの種類のキャプチャ－アンド－リプレイ攻撃が検出され、防止されることができ、システムセキュリティを改善する。暗号署名を用いることによって、送信中に識別信号（例えば、識別信号の一部を形成する許可）を変更し得るであろういくつかの種類の攻撃が検出され、防止されてもよく、これにより、システムセキュリティを改善する。
【0136】
その後、許可チェッカは、例えば、ドライバの製造時に、ドライバ内に記憶された認可サーバのための公開鍵情報を用いてレスポンスの完全性及び信憑性の正当性を検証してもよい。
【0137】
（例えば、ナンスを含んでもよい要請に対する）レスポンスはまた、サーバが、暗号手段によって安全にされた認証プロトコルを用いて、補助負荷の識別を確立することに基づいて、サーバ６１によって作成された補助負荷のための許可のリストを含んでもよい。例えば、ナンスを有する要請をサーバ６１に渡す際に、独立デバイスはまた、サーバ６１によって許可を決定するために用いられる、補助負荷のための何らかの識別情報（通し番号など）を得て、次へ回してもよい。
【0138】
例えば、独立デバイス６０は、補助負荷のための（例えば、補助負荷自体の上に配置された）バーコードをスキャンするように構成されており、場合によっては、上述された仕方で、ナンスを用い、サーバ６１の助けを借りて、ドライバ２の許可チェッカによって受け入れられることになる許可を含む識別信号を作成するために用いられるバーコードスキャナを含んでもよく、スキャンされたバーコードに一部基づいて許可が選ばれる。それゆえ、諸実施形態では、スキャンされたバーコードは、（オプションとして、ドライバ２の許可チェッカによって提供されたナンスに更に基づく）認証のためにサーバ６１に渡されてもよい。
【0139】
別の実施形態では、独立デバイスは、例えば、補助負荷と通信すること、又は補助負荷の無線周波数識別（radio-frequency identification；ＲＦＩＤ）タグをスキャンすることによって、補助負荷の識別信号を生成するように構成された、（補助負荷と通信する）近距離通信デバイス、又はＲＦＩＤデバイスを含んでもよい。
【0140】
更に他の実施形態では、独立デバイス６０のユーザが、キーボード又はタッチスクリーンなどの入力デバイスを介して、ドライバ２に接続された補助負荷を表す識別情報、コード、又はパスワードを入力してもよい。この入力された識別情報は独立デバイスによってデバイスコントローラ１０へ伝送される（オプションとして、識別情報の準備は認可サーバ６１の助けを借りて実行される）。
【0141】
独立デバイス６０は、任意の周知の通信プロトコル、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ（登録商標）などの無線通信プロトコル、又はＵＡＲＴプロトコルなどの有線通信プロトコルを用いて通信することができてもよい。他の好適な通信プロトコルも当業者に容易に理解されるであろう。
【0142】
少なくとも１つの考えられる実施形態では、ドライバ２によって実行される代わりに、独立デバイス６０が、補助負荷７の許可を決定することを実行してもよい。例えば、独立デバイスは、補助負荷の識別信号を、例えば、独立デバイス内、又は外部サーバ上に記憶された、データベースのレコードと比較し、補助負荷の許可を決定してもよい。次に、これらの許可は、ドライバコントローラ１０による適切な実行のためにドライバ２に渡されてもよい。
【0143】
一実施形態では、ドライバ（コントローラ）によって生成された警告信号が独立デバイスに渡される。警告信号は、例えば、（独立デバイスのスクリーン上にテキストを表示するなど）警告を独立デバイスによって表示させてもよい。警告は、特定のアプリケーション又はプログラムを実行するスマートフォンによって生成されてもよい。
【0144】
図７は、上述された装置及び方法に対する別の変形例を示す。具体的には、図７は図６のものと同様の構成を示すが、この場合、独立デバイス６０及びドライバ２（例えば、許可チェッカを有する）は直接通信の手段を有しない。その代わりに、補助負荷７は、独立デバイス６０、及びオプションとして、認証サーバ６１と、ドライバとの間の通信チャネルを提供する。この異例の構成は、（例えば、独立デバイス６０と通信するための）ドライバ内におけるコストのかかる余分な通信ハードウェアの必要性を防ぐため、有利である。
【0145】
１つの可能な構成では、図７に示されるように、補助負荷は、補助電力出力部６を介して延びる電気配線を用いて独立デバイスからドライバへの通信チャネルを作り出す。これは、いくつかの種類の中間者又はなりすまし攻撃を防止する、システムセキュリティにおける追加の利点を有し、また、材料コストも節減し得る。それゆえ、補助負荷７は、ドライバ２と独立デバイス６０（及びオプションとして、その先の認可デバイスまで）との間の通信のためのルーティングデバイスの役割を果たしてもよい。このように、ドライバは、補助負荷とドライバとの間の有線通信チャネルを通じて、識別信号を含む、メッセージを受信するように構成されていてもよい。
【0146】
補助負荷は、無線プロトコルを用いて独立デバイスと通信してもよい。このような実施形態は、補助負荷が、追加の、又は不要なハードウェアを低減するために通信能力をドライバ及び／又は一次負荷に提供する通信モジュールであるときに、特に有利である。
【0147】
通信チャネルの機能を果たす、信頼されない、敵意のある補助負荷は、それを通って流れるいくつかのメッセージを変更すること、例えば、付与されなかった許可を得ようと試みることによって、又はそれを通って流れるメッセージをリプレイ攻撃における将来の使用のために捕捉することによって、システムセキュリティに対する攻撃を試みることができるであろうことに留意されたい。敵意のある補助負荷による上述の種類の攻撃を防止するために、よく知られた暗号技法が、通信チャネルを保護するために用いられることができ、たとえ、チャネルが、信頼されない可能性のある媒介を介して流れても、通信チャネルを終端間で安全にする。これらの例は、上述されたとおりの、ナンスの使用、及びメッセージの署名である。
【0148】
概して、上述の暗号方策の全ての説明に関しては、いくつかの代替例もまた可能である。これらの代替例は、時として、ハードウェアコスト、特に、ドライバにおけるコストを節減し得、これにより、ハードウェアのコスト及びサイズを低減する。（ナンスを用いるよりも若干セキュリティが低い）１つの代替例では、いくつかの種類のリプレイ攻撃を防止するために、識別情報内のメッセージシーケンスカウンタが用いられることができる。（公開鍵暗号法を用いた署名を使用するよりもセキュリティが若干低い）別の代替例では、「共有秘密」鍵、許可チェッカ（即ち、ドライバ）及び認証サーバにのみ知られた番号を用いる対称暗号法を使用するメッセージ署名が使用されることができる。好ましくは、この場合、ドライバは、ドライバハードウェアを所持する攻撃者が「共有秘密」鍵をドライバから抽出することが難しくなるように構築される必要がある。この抽出が非常に難しくされた場合、コストを節減し、効率を改善するための、更なる最適化は、ドライバのいくつかの物理コピー（即ち、同じ共有秘密鍵を有する異なるドライバ）において同じ共有秘密鍵を用いることになり得るであろう。
【0149】
識別信号を提供する際のセキュリティ及び改善された信頼性のために、有線通信プロトコルが用いられることができ、この場合は、識別信号が、補助電力出力部のためのコネクタを通って延びる導線を介してドライバコントローラに提供される。実施形態によっては、補助負荷は、独立デバイス及び／又は認証サーバ６１からの情報をルーティングしてもよい。
【0150】
これはまた、識別信号をドライバコントローラに渡すために必要とされる配線及び／又は部品（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＮＦＣ受信器）の量も低減させるであろう。
【0151】
１つのこのような実施形態では、ドライバは、補助出力部へ延びる導線の対を備えてもよく、これは、導線のこの対のみを通じて電力送達機構及び双方向性通信機構を組み合わせるＤＡＬＩ（登録商標）バスプロトコルを用いる。別の実施形態では、補助電力出力部のためのコネクタを通って延びる４本の導線が存在してもよく、２本の導線は電力線及び接地線であり、他の２本の導線は、ＵＡＲＴ、ＵＳＢ、又はＩ２Ｃなどの電気プロトコルを用いた、双方向性通信のために用いられる。
【0152】
無論、他の諸実施形態では、補助負荷は無線プロトコルを用いてドライバと通信する。
【0153】
図６及び図７を参照して説明された方法（即ち、ナンス及び／又は認可サーバの使用）は、補助負荷単独で、即ち、独立デバイスを必要とすることなく、用いるように構成されてもよい。例として、補助負荷７は、認可サーバ６１と直接通信し、これにより、図６及び図７の独立デバイス６０の代わりに機能することが可能であってもよい。それゆえ、補助負荷は、ドライバ２と認可サーバ６１との間の通信のためのルーティングデバイスとして機能してもよい。代替的に、ドライバ及び認可サーバは互いに直接通信してもよい。
【0154】
本発明のいくつかの変異型では、電流感知デバイス３５は、上述されたとおりの２値信号のみではなく、どのぐらいの電力が消費されているのかに関する情報を提供するように設計されていてもよい。
【0155】
この詳細情報は、例えば、所定の電力量（例えば、１０Ｗ）よりも多くが補助負荷によって消費されているとの情報、又はどのぐらいの電力が補助負荷によって消費されているのかを含んでもよい。特定のアクションがこのような詳細情報に基づいてトリガされてもよく、これは、ドライバ２によって実行されるアクションに対するカスタマイズ性の向上を可能にする。
【0156】
例として、接続された補助負荷のために予想される（例えば、その識別情報に基づいて算出される）よりも大きい消費などの、予想外に高い電力消費は、ドライバ及び／又は負荷に危険をもたらし得る補助負荷内部における短絡を示す可能性が高い。ドライバは、コントローラに、補助負荷への電力を中断させてもよく（例えば、補助出力部を電源から切断する）、これにより、危険を回避する。
【0157】
別の想定される変異型では、ドライバは、補助負荷によって消費されている電力を監視することによってシステムのセキュリティを高めてもよい。これは、特に、生のネットワーク接続を有し、したがって、潜在的にマルウェアに感染し得る補助負荷に適用される。ドライバは、補助負荷によって消費されている電力を、（補助負荷のための識別情報に基づいて識別されることができるであろう）通常動作下で補助負荷がどのように電力を引き出すべきであるかを記述する「電力指紋」情報と比較することができる。大きな不一致がある場合、補助負荷がマルウェアに感染している可能性がある。ドライバは、補助負荷への電力を中断することによって応答することができ、これにより、マルウェアが動作するために利用可能な時間窓を制限することによってシステムセキュリティを高める。この種の保護は、他の機器を再感染させるためにネットワークをスキャンする「ボットネット」マルウェアから保護するために特に意義がある。
【0158】
実施形態によっては、ドライバは、それぞれの２つ以上の補助負荷に接続するための２つ以上の補助電力出力部又はインターフェースを備える。ドライバコントローラは、補助電力出力部の各々への補助負荷のそれぞれの接続又は切断を検出し、それに応じてそれぞれのアクションを実行するように構成されていてもよい。
【0159】
諸実施形態は、電力を引き出すための許可などの、補助負荷の１つ以上の許可を決定することを含む（ドライバによって実行されるべき）アクションに関する。しかし、ドライバによって実行されるべき様々な他のアクションも想定される。例えば、アクションは、補助負荷が接続されると、課金トランザクションを開始し（例えば、タイマ）、補助負荷が切断されると、課金トランザクションを終了することを含んでもよい。これは、ドライバの操作者が、補助負荷の操作者に、補助負荷がドライバに接続されている時間にわたって、（例えば、補助負荷によって引き出された電力、又は実行されたサービスなどの代金を支払うために）課金することを可能にするであろう。他の可能なアクションが以前に示された。
【0160】
諸実施形態は、概して、照明設備のためのドライバに関して説明されたが、当業者は、本コンセプトは、それぞれ一次負荷及び補助負荷のための一次出力部及び補助出力部を有する他のドライバに適用されてもよいことを理解するであろう。これは、例えば、音響設備、視覚出力システム、コンピューティングシステムなどの状況におけるものであってもよい。
【0161】
補助負荷は、通信、感知、又は監視能力をドライバ及び／又は一次負荷（若しくはドライバに接続された他の負荷）に提供するように構成されていてもよい。例えば、補助負荷は、（例えば、一次負荷の光源の明るさを制御するための）制御情報を一次負荷に提供するためにネットワークブリッジと通信する、又はネットワークブリッジに感知データ（例えば、ドライバ／一次負荷の近傍の温度）を提供するように構成されていてもよい。
【0162】
ドライバであって、ドライバの一次負荷に電気的に接続するように構成された一次電力出力部と、ドライバの補助負荷に電気的に接続するように構成された補助電力出力部と、電力を一次電力出力部及び補助電力出力部に供給するための電源と、を有するドライバの制御方法であって、補助負荷が補助電力出力部に接続されること、又は補助電力出力部から切断されることによって生じた、補助電力出力部における電力消費の変化があるかどうかを判定するステップと、電力消費の変化が生じたと判定したことに応じて、補助負荷及び／又は一次負荷に関する少なくとも１つのアクションを実行するステップと、を含む制御方法が提案される。
【0163】
本方法は、電力制限部を用いて、補助電力出力部に接続された補助負荷及び／又は一次電力出力部に接続された一次負荷に供給される電力を制御可能に遮断又は制限するステップを含んでもよい。
【0164】
本方法の少なくとも１つのアクションは、補助負荷のための識別信号の利用可能性を判定することを含んでもよい。好ましくは、識別信号は補助負荷のためのデジタル的に可読の識別情報を含み、本方法は、識別信号が利用可能であると判定したことに応じて、補助負荷の少なくとも１つの許可を決定するために、許可チェッカを用いて補助負荷のためのデジタル的に可読の識別情報を処理するステップを含んでもよい。
【0165】
本方法は、デジタル的に可読の識別情報が、補助負荷の少なくとも１つの許可を決定するべく、信頼できるライセンス付与機関によって生成されたライセンスデータを含むかどうかを確認するための暗号手段を用いるように構成されていてもよい。
【0166】
補助負荷の少なくとも１つの許可は、電力をドライバから引き出すための許可を含んでもよく、本方法は、補助負荷が、電力をドライバから引き出すための許可に関連付けられない場合、補助電力出力部に接続された補助負荷に供給される電力を遮断又は制限するステップを含むように構成されていてもよい。更に、諸例では、本方法は、補助負荷が、電力をドライバから引き出すための許可に関連付けられない場合、一次電力出力部に接続された一次負荷に供給される電力を遮断又は制限するステップを含むように構成されていてもよい。
【0167】
本方法は、ドライバと補助負荷との間の通信チャネルを介して識別信号を受信するステップを含んでもよい。
【0168】
本方法に従って実行される少なくとも１つのアクションは、接続された補助負荷によって引き出される最大電力を制限すること、接続又は切断された補助負荷の識別を決定すること、接続又は切断された補助負荷の分類タイプを決定すること、補助負荷が補助電力出力部に接続されたか、又は補助電力出力部から切断されたことを示す出力信号を生成すること、一次負荷の電力引き出しと補助負荷の電力引き出しとを比較すること、タイマを開始又は終了すること、金銭又は課金トランザクションを開始又は終了すること、補助負荷のための認可チェックを実行すること、補助負荷のための認可チェックを実行し、チェックが、補助負荷が認可されていることを検出しなかった場合、警告信号を送信すること、及び補助負荷のための認可チェックを実行し、チェックが、補助負荷が認可されていることを検出しなかった場合、警告信号を送信することであって、警告信号が一次負荷の動作を、警告を示すように制御する、こと、のうちの１つ以上を含んでもよい。
【0169】
任意の上述の方法は、例えば、ドライバコントローラを用いて実施されてもよい。
【0170】
上述のように、諸実施形態はドライバコントローラを利用する。コントローラは、必要とされる様々な機能を実行するために、ソフトウェア及び／又はハードウェアを使用して、数多くの方法で実装されることができる。プロセッサは、必要とされる機能を実行するように、ソフトウェア（例えば、マイクロコード）を使用してプログラムされてもよい、１つ以上のマイクロプロセッサを採用する、ドライバコントローラの一例である。しかしながら、ドライバコントローラは、プロセッサを採用して、又はプロセッサを採用せずに実装されてもよく、また、一部の機能を実行するための専用ハードウェアと、他の機能を実行するためのプロセッサ（例えば、１つ以上のプログラムされたマイクロプロセッサ、及び関連回路）との組み合わせとして実装されてもよい。
【0171】
本開示の様々な実施形態で採用されてもよいドライバコントローラ構成要素の例としては、限定するものではないが、従来のマイクロプロセッサ、特定用途向け集積回路（application specific integrated circuit；ＡＳＩＣ）、及びフィールドプログラマブルゲートアレイ（field-programmable gate array；ＦＰＧＡ）が挙げられる。
【0172】
様々な実装形態では、プロセッサ又はドライバコントローラは、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、及びＥＥＰＲＯＭ（登録商標）などの、揮発性及び不揮発性のコンピュータメモリなどの、１つ以上の記憶媒体と関連付けられてもよい。これらの記憶媒体は、１つ以上のプロセッサ及び／又はコントローラ上で実行されると、必要とされる機能を実行する、１つ以上のプログラムでエンコードされてもよい。様々な記憶媒体は、プロセッサ又はドライバコントローラ内に固定されてもよく、あるいは、それらの記憶媒体上に記憶されている１つ以上のプログラムが、プロセッサ又はドライバコントローラ内にロードされることができるように、可搬性であってもよい。
【0173】
図面、本開示、及び添付の請求項の検討によって、開示される実施形態に対する他の変形形態が、当業者により理解されることができ、また、特許請求される発明を実施する際に実行されることができる。請求項では、単語「備える（comprising）」は、他の要素又はステップを排除するものではなく、不定冠詞「１つの（a）」又は「１つの（an）」は、複数を排除するものではない。特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。請求項中のいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】