(57)【特許請求の範囲】
【請求項１】
デバイスコントローラシステムであって、
センサ情報を受信するよう構成された通信インターフェースと、
前記通信インターフェースと接続されたプロセッサであって、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、前記デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することと関連付けられた第１の期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を実行することと関連付けられた第２の期待値と比べ、前記第１の期待値は、複数のローカル環境を表すノードの階層を含むグラフモデルに基づいて利用のために選択された環境状態に基づいて、決定され、
前記動作を自動的に実行することと関連付けられた前記第１の期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定し、
承認示唆を特定し、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信するよう構成された、プロセッサと、
を備える、システム。
【請求項２】
請求項１に記載のシステムであって、前記動作を実行することは、前記デバイスのプロパティを、前記動作に関連する特定の構成に変更することを含む、システム。
【請求項３】
請求項１に記載のシステムであって、前記センサ情報を用いて検出された前記少なくとも１つの状態は、ユーザについての状態情報および環境についての状態情報を含む複数の状態の一部であり、前記複数の状態は、前記動作を自動的に実行することと関連付けられた前記第１の期待値を決定するために用いられる、システム。
【請求項４】
請求項１に記載のシステムであって、前記センサ情報を用いて検出された前記少なくとも１つの状態は、前記動作を自動的に実行することと関連付けられた前記第１の期待値を決定する際に用いられる前記少なくとも１つの状態の信頼度に関連し、前記信頼度は、前記動作を自動的に実行することと関連付けられた前記第１の期待値を決定するために用いられる、システム。
【請求項５】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値は、機械学習を用いて自動的に決定された自動化ルールを用いて決定されたものである、システム。
【請求項６】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値は、少なくとも部分的には、前記受信されたセンサ情報を用いて検出された異なる状態に各々関連する成分期待値を組み合わせることによって決定されたものである、システム。
【請求項７】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値を前記第２の期待値と比べることは、前記動作を自動的に実行することと関連付けられた前記第１の期待値を、前記第２の期待値に対して評価することを含む、システム。
【請求項８】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値を前記第２の期待値と比べることは、コスト最小化関数を利用することを含む、システム。
【請求項９】
請求項１に記載のシステムであって、前記ユーザインタラクティブな認定は、前記動作が実行されるべきであることを承認する前記承認示唆に関連する、システム。
【請求項１０】
請求項１に記載のシステムであって、前記ユーザインタラクティブな認定は、前記動作の実行を取り消すことを命令する指示に関連する、システム。
【請求項１１】
請求項１に記載のシステムであって、前記承認示唆は、前記動作が実行されるべきか否かについての問い合わせに応答してユーザから受信したものである、システム。
【請求項１２】
請求項１に記載のシステムであって、前記承認示唆は、前記動作が実行される旨の警告に応答して取り消しユーザ指示を受信していないことに関連する、システム。
【請求項１３】
請求項１に記載のシステムであって、前記承認示唆は、前記動作に固有ではない汎用のユーザ示唆に関連する、システム。
【請求項１４】
請求項１に記載のシステムであって、前記プロセッサは、さらに、ユーザが前記動作を手動で実行する可能性があると判定して、前記ユーザが前記動作を実行するのを待つことと関連付けられた期待値を評価するよう構成される、システム。
【請求項１５】
請求項１に記載のシステムであって、前記第２の期待値は、ユーザへ問い合せを送信する負のコストを考慮する、システム。
【請求項１６】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値は、時間と共に値が減衰する成分を含む、システム。
【請求項１７】
請求項１に記載のシステムであって、前記センサ情報は、カメラまたはマイクからの情報を含む、システム。
【請求項１８】
請求項１に記載のシステムであって、前記動作は、指定された将来の時点に前記デバイスによって実行されるか、または、複数の時点に繰り返される、システム。
【請求項１９】
請求項１に記載のシステムであって、前記動作は、前記動作が完全に実行されることの示唆を提供するために、部分的に実行される、システム。
【請求項２０】
請求項１に記載のシステムであって、前記デバイスは、或る期間にわたって段階的に徐々に前記動作を実行し、前記期間の終了前に前記動作を一時停止するためのユーザ指示が受信された場合、前記動作の前記徐々の実行は一時停止され、前記動作を元に戻すためのユーザ指示が受信された場合、前記動作は保留される、システム。
【請求項２１】
請求項１に記載のシステムであって、前記動作が実行される旨の警告表示がユーザに提供され、前記警告表示は、視覚的警告、聴覚的警告、警告メッセージ、バイブレーション警告、または、機械的警告の内の１または複数を提供することを含む、システム。
【請求項２２】
請求項１に記載のシステムであって、前記動作を自動的に実行することと関連付けられた前記第１の期待値は、少なくとも部分的には、ユーザへ示された問い合わせに応答して以前に受信されたユーザ応答に基づいて決定されたものである、システム。
【請求項２３】
方法であって、
センサ情報を受信する工程と、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することと関連付けられた第１の期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を実行することと関連付けられた第２の期待値と比べる工程であって、前記第１の期待値は、複数のローカル環境を表すノードの階層を含むグラフモデルに基づいて利用のために選択された環境状態に基づいて、決定される、工程と、
前記動作を自動的に実行することと関連付けられた前記第１の期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定する工程と、
承認示唆を特定する工程と、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信する工程と、
を備える、方法。
【請求項２４】
持続性のコンピュータ読み取り可能な記憶媒体であって、
センサ情報を受信するためのコンピュータ命令と、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することと関連付けられた第１の期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を実行することと関連付けられた第２の期待値と比べるためのコンピュータ命令であって、前記第１の期待値は、複数のローカル環境を表すノードの階層を含むグラフモデルに基づいて利用のために選択された環境状態に基づいて、決定される、コンピュータ命令と、
前記動作を自動的に実行することと関連付けられた前記第１の期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定するためのコンピュータ命令と、
承認示唆を特定するためのコンピュータ命令と、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信するためのコンピュータ命令と、
を含む、記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
ネットワーク接続デバイス（例えば、インターネット・オブ・シングズ（すなわち、ＩｏＴ）デバイス）は、環境（例えば、住居）内でのデバイスの遠隔制御および自動化を可能にする。しかしながら、これらのデバイスは、しばしば、完全には自律することができない。しばしば、ユーザが、遠隔操作でデバイスを手動操作しなければならないか、または、ユーザが、所望の動作を摸倣しようとする複雑なルールを手作業で作らなければならない。例えば、ユーザは、デバイスが具体的に位置する場所、デバイスの能力／範囲、および、所望の結果に関係するので各デバイスが周囲環境へ具体的にどのように影響するか、を知っている必要がある。
【発明の概要】
【０００２】
以下の詳細な説明と添付の図面において、本発明の様々な実施形態を開示する。
【図面の簡単な説明】
【０００３】
【図１Ａ】ネットワークデバイスを自動制御するためのシステムの一実施形態を示す図。
【０００４】
【図１Ｂ】ネットワークデバイスを自動制御するための構成要素の間の相互作用の一実施形態を示す図。
【０００５】
【図１Ｃ】ネットワークデバイスを自動制御するためのシステムのサブ構成要素の一実施形態を示す図。
【０００６】
【図２】デバイス制御ルールを自動的に学習および適用するための処理の一実施形態を示すフローチャート。
【０００７】
【図３】検出された状態が正確な状態である可能性を決定するための処理の一実施形態を示すフローチャート。
【０００８】
【図４】ネットワーク接続された制御可能デバイスの自動化ルールを自動的に発見するための処理の一実施形態を示すフローチャート。
【０００９】
【図５】選択された出力結果を決定するための処理の一実施形態を示すフローチャート。
【００１０】
【図６】ネットワーク接続された制御可能デバイスの制御可能プロパティの出力候補を自動的に決定するための処理の一実施形態を示すフローチャート。
【００１１】
【図７】選択された出力を実施するための処理の一実施形態を示すフローチャート。
【００１２】
【図８】改善された出力を発見するよう試みる処理の一実施形態を示すフローチャート。
【００１３】
【図９Ａ】接続デバイス環境の階層グラフモデルの区域レベルの一例を示す図。
【００１４】
【図９Ｂ】接続デバイス環境の階層グラフモデルの建物レベルの一例を示す図。
【００１５】
【図９Ｃ】接続デバイス環境の階層グラフモデルのユニットレベルの一例を示す図。
【００１６】
【図９Ｄ】接続デバイス環境の階層グラフモデルの部屋レベルの一例を示す図。
【００１７】
【図１０】接続デバイス環境のグラフモデルを初期化するための処理の一実施形態を示すフローチャート。
【００１８】
【図１１】グラフモデルを用いてコマンドを処理するための処理の一実施形態を示すフローチャート。
【発明を実施するための形態】
【００１９】
本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）など、様々な形態で実施されうる。本明細書では、これらの実施例または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書で用いられているように、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。
【００２０】
以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術事項については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。
【００２１】
インタラクティブデバイスコントローラが開示されている。例えば、ユーザのニーズを予測し、遠隔操作で複雑な一連のスマートデバイスを手動で作動させるようユーザに要求することなしに自動的にスマートデバイスを制御するコントローラハブを用いて、配備環境のネットワーク接続スマートデバイスが自律的に制御される。コントローラハブは、機械学習、ユーザの指定した嗜好、および／または、自動化ルールを、検出されたセンサ入力（例えば、カメラ、マイク、モーション検出器などからの入力）に適用することによって、ユーザのニーズを予測してよい。しかしながら、特定の状況では、スマートデバイスを制御する（例えば、電球をオンにする）ための動作が実行されるべきであると断定的に決定することが難しい場合がある。例えば、動作がユーザの状態によってトリガされた時のセンサ入力（例えば、カメラ画像）を所与として、ユーザの状態（例えば、現在の動作がユーザによって実行されている）を断定的に決定するのは困難な場合がある。いくつかの実施形態において、単に動作を実行するか実行しないかではなく、ユーザは、動作が実行されるべきか否かを確認するようプロンプトされる。例えば、動作は、ユーザのニーズを予測する際に、潜在的に実行される動作であるとシステムによって自動的に特定されたものである（例えば、ユーザは、動作の実行を具体的に要求していないが、システムが、その動作を望ましい動作として自動的に特定した）。しかしながら、センサ入力の解析結果の不確実性を考慮すると、システムは、その動作を実行すべきであると十分には確信しないので、システムは、システムが動作を実行するべきか否かをスピーカの音声出力を通してユーザにプロンプトする。動作が実行されるべきであるとユーザが承認した場合、その動作は実行される。
【００２２】
いくつかの実施形態において、環境の１または複数の状態についてのセンサ情報が受信される。例えば、センサが、閉鎖的な物理位置（例えば、家、建物など）に配置されており、センサ入力が、環境の様々な状態（例えば、環境内のデバイスの状態、温度、湿度、明るさ、動き、１または複数の人間または動物の状態、など）を決定するための解析に向けて受信される。いくつかの実施形態において、１または複数の状態が、受信されたセンサ入力に基づいて状態が正確である確度に関連付けられる。
【００２３】
センサ情報を用いて検出された状態に少なくとも部分的に基づいて、動作を潜在的に実行することに対する期待値と比較して、動作を自動的に実行することに対する期待値が評価される。例えば、期待値は、オプションに関連付けられた望ましさ度の尺度である。期待値は、特定の関連する動作に固有である。期待値は、要因の中でも特に、入力状態を所与として動作の関連オプションを選択する潜在的利益、入力状態を所与として動作の関連オプションを選択しない潜在的損害、動作に対する過去のオプション選択の履歴、関連オプションの選択についてのユーザへの迷惑など、を考慮に入れてよい。いくつかの実施形態において、期待値は、決定された１または複数の状態を所与として、動作の各出力操作タイプについて決定される。これらの出力操作タイプは、（例えば、ユーザインタラクティブな認定を受けずに）動作を自動的に実行すること、ユーザインタラクティブな認定を条件として動作が潜在的に実行されるべきであると決定すること、および、動作を実行しないこと、を含みうる。ユーザインタラクティブな認定は、動作が実行されるべきか否かをユーザに問い合わせて、ユーザが承認示唆を提供した場合にのみ動作を実行するすることに関連してよい。別の例において、ユーザインタラクティブな認定は、他の指示がない限りは動作が実行される旨の警告を提供して、他の指示があった場合に動作を実行しないことに関連してよい。ユーザインタラクティブな認定は、動作を実行する事前認定であってよく、ユーザからの認定示唆が、動作の実行を許可または阻止してよい。
【００２４】
いくつかの実施形態において、動作を実行しないことは、ユーザが動作を手動で実行する可能性があるために動作の実行を待つことに関連する。いくつかの実施形態において、期待値を評価することは、最も望ましい結果に対応する期待値（例えば、最高値または最低値）を選択するために、特定の動作に関連する各出力操作タイプに関連する期待値を比較することを含む。
【００２５】
いくつかの実施形態において、自動的に動作を行う期待値が、ユーザインタラクティブな認定を受けずに動作を自動的に実行することをトリガするのに不十分であると判定された場合、ユーザは、動作が実行されるべきかあるいは実行を阻止されるべきかについてユーザからの応答を要求するためのインタラクティブな問い合わせを提供される。
【００２６】
図１Ａは、ネットワークデバイスを自動制御するためのシステムの一実施形態を示す図である。デバイス１０２は、センサデバイスおよび制御可能デバイス（例えば、ＩｏＴデバイス）など、１または複数のネットワーク接続デバイスを含む。デバイス１０２に含まれる１または複数の制御可能デバイスの例は、スイッチ、ドアロック、サーモスタット、電球、キッチン／家庭用電気製品、カメラ、スピーカ、カレージドアオープナ、窓装飾（例えば、ロールシェード、カーテンなど）、ファン、コンセント、オーディオ／ビジュアルデバイス、調光器、灌水システム、ペット給餌器、および、コンピュータネットワークに接続されることのできる任意のその他のデバイス、を含む。デバイス１０２に含まれる１または複数のセンサデバイスの例は、スイッチ、カメラ、モーション検出器、光検出器、加速度計、赤外線検出器、温度計、空気質センサ、煙探知器、マイク、湿度検出器、ドアセンサ、窓センサ、水検出器、ガラス破損検出器、電力利用センサ、および、任意のその他のセンサ、を含む。
【００２７】
ハブ１０４は、有線および／または無線接続を介してデバイス１０２と通信する。例えば、デバイス１０２の内の１つのデバイスが、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標、以下同じ）、Ｂｌｕｅｔｏｏｔｈ低エネルギ、Ｚｉｇｂｅｅ、Ｚ−Ｗａｖｅ、電力線通信、Ｅｔｈｅｒｎｅｔ、および／または、任意のその他の無線または有線通信プロトコルを利用するよう構成された通信インターフェースを介して、ハブ１０４と通信する。いくつかの実施形態において、ハブ１０４およびデバイス１０２は、同じ環境内に配備されている。例えば、デバイス１０２は、住居に配備されたデバイスを含み、ハブ１０４は、短距離無線信号で住居内のデバイスと無線通信する。いくつかの実施形態において、ハブ１０４は、ユーザデバイス１０８を用いたおよび／またはネットワーク１１０を介したデバイス１０２の通信および／または制御を容易にする。例えば、ユーザデバイス１０８は、デバイス１０２の内の１つのデバイスを制御するため、および、そのデバイスに関する情報を見るために、直接無線接続（例えば、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉなど）を介しておよび／またはネットワーク１１０を介してハブ１０４に接続する。別の例において、ユーザデバイス１０８は、ハブ１０４および／またはサーバ１０６を介してデバイス１０２にアクセスするために、ネットワーク１１０に接続する。いくつかの実施形態において、デバイス１０２の内の１または複数のデバイス／センサは、ハブ１０４に情報を報告し、次いで、ハブ１０４は、報告された情報を処理に向けてネットワーク１１０を介してサーバ１０６に提供する。いくつかの実施形態において、デバイス１０２の内の１または複数のデバイスおよび／またはセンサは、ハブ１０４を介してルーティングされることなしに、ネットワーク１１０と直接通信する。例えば、デバイスが、ネットワーク１１０に直接アクセスするために、ＷｉＦｉおよび／またはセル無線を備える。
【００２８】
ユーザデバイス１０８の例は、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、デスクトップコンピュータ、ウェアラブルデバイス、スマートウォッチ、および、ユーザの任意のその他の電子コンピュータデバイス、を含む。いくつかの実施形態において、デバイス１０２の自動化を可能にするために、ユーザデバイス１０８からの情報が、サーバ１０６および／またはハブ１０４に提供される。例えば、デバイス自動化ルールを決定および／またはトリガするために、ユーザデバイス１０８によって検出されたＧＰＳ位置が、センサ入力としてハブ１０４および／またはサーバ１０６に提供される。いくつかの実施形態において、デバイス１０２の内の１つのデバイスに関連する情報が、ユーザデバイス１０８に提供される。例えば、デバイス１０２の内の１つのデバイスについて検出された警告が、ハブ１０４および／またはサーバ１０６を介してユーザデバイス１０８に提供される。サーバ１０６は、デバイス１０２に関連する情報を処理および／または格納することでデバイス１０２の制御および管理を可能にするためのクラウドコンピュータインフラストラクチャの一部であってよい。いくつかの実施形態において、ハブ１０４は、デバイス１０２を自動制御するためのインターフェースおよび制御ハブとして機能する。ストレージ要素は、図１Ａに明示的に示されていないが、図に示した構成要素のいずれかが、ローカルストレージを備えてよい、および／または、ローカルに接続されたストレージおよび／またはリモートストレージにアクセスしてよい。例えば、ローカルおよび／またはリモートストレージが、デバイス１０２と物理的配備環境との間の関係性をマッピングする環境グラフモデルを格納する。
【００２９】
いくつかの実施形態において、図１Ａに示したシステムを用いて、ユーザがデバイス１０２の内の１または複数の制御可能デバイスとどのように相互作用したいのかを自動的に学習することで、制御可能デバイスのプロパティを自律的かつ自動的に調整するために、機械学習が実行される。いくつかの実施形態において、ユーザの嗜好および行動の強力な統計モデルが自動的に構築される。例えば、デバイス１０２およびユーザデバイス１０８のセンサが、ユーザの存在、活動、および、行動上の嗜好性について学習するために、環境グラフモデルと共に利用される。デバイス１０２の内の制御可能デバイスが、学習されたデータに基づいて自動的に管理および制御されてよい。例えば、制御コマンドまたはユーザ定義の制御ルールを明示的に提供するようユーザに要求することによって、遠隔操作でデバイス１０２の内の制御可能デバイスを単に利用するのではなく、デバイスは、デバイスの明示的なユーザトリガなしに、学習したユーザ嗜好に基づいて自動的に制御される。
【００３０】
いくつかの実施形態において、多くの異なるデバイス／センサ（例えば、デバイス１０２）からの入力を統合して、ユーザの存在、活動、および、行動の固有のモデルを構築するために、機械学習（例えば、ローカルおよび／またはクラウドベース）が利用される。例えば、住居などの環境に、リモートまたはローカルに制御できるデバイス１０２が設置される。デバイス１０２のセンサは、環境内での人の存在および動きに関するデータ、環境プロパティ（住居の光、温度、および、湿度など）の測定値、対象物の動き、および、環境の様々な位置の動画を提供しうる。機械学習は、デバイス／センサの位置、機能、および、行動のプロパティ、ならびに、学習プロセス中のそれらのデータを説明するためのグラフモデルを考慮に入れてよい。
【００３１】
いくつかの実施形態において、自動的に決定されたユーザの嗜好性と一致するように制御可能デバイスを自動制御してデバイス１０２の内の制御可能デバイスを自動調整する方法を学習するために、学習が実行される。例えば、センサが、制御可能デバイスの状態（例えば、スイッチ、サーモスタット、および、その他のデバイスの挙動およびそれらとの相互作用）の変化を引き起こす環境条件を検出し、環境条件は、グラフモデルを用いてコンテキストを与えられ、デバイス１０２の内のデバイスが、自動学習されたユーザの嗜好性に従って自律的に命令される。
【００３２】
いくつかの実施形態において、機械学習は、ローカルハブによって特定の環境のために実行される。例えば、ハブ１０４は、環境のグラフモデルを用いて、デバイス１０２を含むハブ１０４が配備された環境のユーザのために学習を実行する。いくつかの実施形態では、ローカルハブで機械学習を実行するのではなく、機械学習の少なくとも一部が、リモートで（例えば、クラウドベースで）実行される。例えば、ハブ１０４の環境に対する機械学習が、ローカル環境のグラフモデルを知るサーバ１０６によって実行される。いくつかの実施形態では、バックエンドサーバが、様々な異なる環境にわたって学習を実行し、各ローカル環境を自動的に構成するのに役立つように結果を利用する。例えば、グラフモデルが、様々なローカル環境を表しそれらを結びつけるノードの階層を含み（例えば、建物のグラフモデルは、建物の個々のユニットに対するノード要素を含む）、学習が、様々なローカル環境のグラフ全体にわたって実行される。
【００３３】
いくつかの実施形態において、ハブ１０４および／またはサーバ１０６は、デバイス１０２の内の１または複数のデバイスから受信したセンサデータを状態表現（例えば、個人の行動、位置などの状態）へ変換する１または複数の推論エンジンを備える。例えば、推論エンジンは、統計的技術および／またはディープラーニング技術に依存する機械学習アルゴリズムを利用する。いくつかの実施形態において、ハブ１０４および／またはサーバ１０６は、１または複数のカメラセンサから画像／動画を受信する「視覚エンジン」（例えば、ＭＬ  ｉｎｆｅｒｅｎｃｅ）を備え、被写体（例えば、人間、ペットなど）の位置、行動、および、活動（例えば、空間的特徴および動きの特徴）を推測するために視覚アルゴリズムを用いて画像／動画を解析する。いくつかの実施形態では、カメラ動画データが、接続されたデバイスを所望の状態に制御する人物の手のジェスチャを学習するために解析される。一実施形態において、ジェスチャは、人物による統計的実証から学習される。一実施形態において、ジェスチャは、ディープラーニングを用いて学習される。いくつかの実施形態において、視覚データおよびその他のセンサデバイスからのデータの出力は、人物の存在、活動、および、行動上の嗜好性に関する情報を含む意味表現を構築するために利用される。状態情報は、グラフモデルを用いてコンテキストを与えられてよく、１または複数の状態に関する高次情報が、グラフモデルを用いて外挿されてよい。
【００３４】
いくつかの実施形態では、図のシステムにおいて、データは、イベント駆動型データベースアーキテクチャを用いて送信される。例えば、センサデータは、最初に、ストリーミングの前にコンパクトな特徴ベクトルに変換される。いくつかの実施形態において、センサデータは、システム内の様々なタイプのノイズをモデル化する統計的学習モデルによって、ストリーミングの前に、クリーニングされる。
【００３５】
いくつかの実施形態において、ハブ１０４および／またはサーバ１０６は、検出された状態を用いて１または複数の自動決定された自動化ルールをトリガする１または複数の「ルールエンジン」を備える。例えば、ルールエンジンは、事前条件および事後条件を含むルールからなり、環境の特定の事前条件状態が検出された場合に、１または複数のネットワーク接続された制御可能デバイスを事後条件状態にさせるためのルールがトリガされる。例えば、人物が机で本を読んでいることが検出された場合、システムは、読書灯をオンにする。ルールの事前条件は、グラフモデルの１または複数のプロパティに基づいてよい。
【００３６】
いくつかの実施形態において、サーバ１０６は、自動化ルールを自動的に決定するために利用できる様々なタイプの情報を格納する。例えば、様々な時点のセンサデータ、および、デバイス１０２のデバイス制御イベント（例えば、照明スイッチを押すイベント、サーモスタットの温度を変更するイベント、など）が記録される。ユーザによって望まれる嗜好／構成を学習することにより、嗜好／構成は、環境内の条件が以前に記録された条件と一致した時に再作成されてよい。いくつかの実施形態において、デバイスの制御動作の統計モデル（例えば、遷移モデル）が決定される。例えば、ネットワーク接続された電球がオンまたはオフにされると、関連する環境条件（例えば、ユーザの位置、動作、日時など）および関連する制御可能デバイス状態が格納される。いくつかの実施形態において、どの状態ベクトルが制御可能デバイスのどの制御動作に対応するのかが学習される。いくつかの実施形態において、学習方法は、状態ベクトルの値を制御可能デバイスの状態変化にマッピングする関数の重みを学習する。いくつかの実施形態において、学習方法は、状態ベクトルから制御可能デバイスの状態変化への多段非線形マッピングを学習するために、ディープラーニングを利用する。いくつかの実施形態において、自動的にトリガされたルールの動作に関するユーザからのフィードバックが、報償の形態で受信され、強化学習を用いて、制御ルールが自動的に修正される。いくつかの実施形態において、サーバ１０６は、１または複数の配備環境のためのグラフモデルを格納する。
【００３７】
いくつかの実施形態では、特定の警戒イベントまたは重要イベントが検出され、データが格納される。例えば、不法侵入が異常イベントとして検出され、それに応じて、スマートフォンに送信される警告およびサイレンの作動を含む出力警告が生成される。別の例では、赤ちゃんがベビーベットから這い出したことが検出される。手動で設定されるアラームと異なり、自動的に検出される異常イベントは、センサデータを用いたイベントの統計モデリングに基づいて検出されてよい。
【００３８】
いくつかの実施形態において、イベントの検出に応答して、出力応答（例えば、音、ユーザ警告、光警告、ウェアラブル警告など）が生成される。例えば、閾値期間を超えてストーブが放置されていることが検出された場合、および／または、対象者の存在が検出されない場合、ストーブが自動的にオフにされる、および／または、出力警告が生成される。別の例では、水漏れが検出された場合、自動出力警告が送信され、水栓が自動的にオフにされる。別の例では、人が倒れて、人のさらなる動きが検出されなかった場合に、緊急連絡先および／または救急機関への警告が自動的に送信される。別の例では、人物の存在が朝の時間にリビングルームで検出された場合に、カーテンが自動的に開かれる。別の例では、湿度が閾値よりも高いことが検出された場合に、ファンが自動的にオンにされる。別の例では、好ましい湿度を維持するために、加湿器が、自動的にオン／オフに切り替えられる。別の例では、学習された好ましい時間に到達すると、コーヒーメーカーが自動的にオンにされる。別の例では、食洗機が、エネルギ率の比較的低い時に作動されるように自動的にスケジューリングされる。別の例では、光度が、時刻に基づいて自動的に調節される（例えば、対象者がトイレを使うために真夜中に起きた場合には、低い光度で照明が点灯される）。別の例では、対象者が夕食を取っていることが検出された場合に、音楽が自動的にオンにされる。別の例では、気温および湿度が閾値を超えることが検出され、対象者が座っていると検出された場合に、ファンが自動的にオンにされる。
【００３９】
特定の状況では、デバイス（例えば、デバイス１０２の制御可能デバイス）を制御するための動作（例えば、デバイスのプロパティの変更）が実行されるべきであると断定的に決定するのが困難な場合がある。例えば、センサ入力を所与として入力状態（例えば、状態ベクトルにおける状態）を断定的に決定するのが困難な場合がある。したがって、自動化ルールの評価の出力が、単に、制御可能デバイスのプロパティを変更するか変更しないかである場合、自動化ルールに提供された環境状態の不確実性の結果として、変更されることが望ましくない場合に制御可能デバイスのプロパティが変更されるか（例えば、不必要に積極的な変更のトリガ）、あるいは、変更されることが望ましい場合に制御可能デバイスのプロパティが変更されないか（例えば、不必要に保守的な変更のトリガ）、のいずれかが起こりうる。いくつかの実施形態において、自動化ルールの評価の結果として、単に動作を実行したり実行しなかったりするのではなく、ユーザは、自動化ルールへの入力状態が十分なレベルの確実性をもって決定されえない場合に、動作のトリガを承認するのか拒否するのかをインタラクティブにプロンプトされる。例えば、ハブ１０４は、実行されることが望ましいと自動的に特定された動作をシステムが実行すべきであるか否かを、スピーカの音声出力を通してユーザにプロンプトする。動作が実行されるべきであるとユーザが承認した場合、その動作は実行される。自動化ルールによってトリガされた動作を扱う結果の例は、以下を含む：動作を実行する；動作が実行される旨の警告を提供した後に動作を実行する（例えば、ユーザには動作の実行をキャンセルする機会がある）；動作を実行するか否かをユーザに問い合わせる（例えば、ユーザが承認した場合にのみ動作を実行する）；ユーザが動作を手動で実行する可能性があると判定する（例えば、動作を実行せずに待機する）；および、動作を実行しない。
【００４０】
以下の内の１または複数が、ネットワーク１１０に含まれてよい：直接または間接物理通信接続、モバイル通信ネットワーク、インターネット、イントラネット、ローカルエリアネットワーク、ワイドエリアネットワーク、ストレージエリアネットワーク、無線ネットワーク、セルラーネットワーク、ならびに、２以上のシステム、構成要素、または、ストレージデバイスを接続する任意のその他の形態。図１Ａに示した構成要素のいずれかの追加が存在してもよい。例えば、複数のハブが、単一の環境内に配備され利用されてもよい。また、複数のユーザデバイスが、ユーザ関連情報を受信するためおよび／または同一環境のデバイスを制御するために利用されてもよい。サーバ１０６は、ネットワーク接続デバイスデータを処理する複数の分散サーバの１つであってよい。いくつかの実施形態において、図１Ａに示していない構成要素が存在してもよい。
【００４１】
図１Ｂは、ネットワークデバイスを自動制御するための構成要素の間の相互作用の一実施形態を示す図である。クラウドベース機械学習モジュール１２０が、ルールエンジン１２２と通信する。ルールエンジン１２２は、センサ１２４から入力を受信し、デバイス１２６を制御する。クラウドベース機械学習モジュール１２０の例は、図１Ａに関連して議論した機械学習を実行するための１または複数のモジュールを含む。ルールエンジン１２２の例は、ハブ１０４および／または図１Ａのサーバ１０６の１または複数の「ルールエンジン」を含む。センサ１２４および／または制御デバイス１２６は、図１Ａのデバイス１０２に含まれてよい。ルールエンジン１２２と通信するクラウドベース機械学習モジュール１２０は、ルールを発見して呼び出すために、センサ１２４およびデバイス１２６を含む環境のグラフモデルを利用してよい。
【００４２】
図１Ｃは、ネットワークデバイスを自動制御するためのシステムのサブ構成要素の一実施形態を示す図である。いくつかの実施形態において、図１Ｃに示すクラウドの構成要素１３０は、図１Ａのサーバ１０６に含まれてよい。いくつかの実施形態において、図１Ｃに示すローカルハブの構成要素１３２は、図１Ａのハブ１０４に含まれてよい。
【００４３】
図２は、デバイス制御ルールを自動的に学習および適用するための処理の一実施形態を示すフローチャートである。図２の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６によって実行されてよい。
【００４４】
工程２０２で、センサデータが受信される。いくつかの実施形態において、受信されるセンサデータは、図１Ａのデバイス１０２の内の１または複数のセンサデバイスからのデータを含む。例えば、スイッチ、カメラ、モーション検出器、光検出器、加速度計、赤外線検出器、温度計、空気質センサ、煙探知器、マイク、湿度検出器、ドアセンサ、窓センサ、水検出器、ガラス破損検出器、および、環境を監視する任意のその他のセンサからのデータが受信される。いくつかの実施形態において、センサデータは、ユーザデバイス（例えば、図１Ａのデータデバイス１０８）からのデータを含む。例えば、ユーザデバイス上のセンサ（例えば、位置センサ、ＧＰＳ、加速度計、心拍センサ、方位センサ、マイク、ジャイロスコープなど）からのデータが受信される。別の例において、ユーザデバイスからのデータは、状態データおよび／またはユーザ指定データを含む。いくつかの実施形態において、センサデータは、１または複数の制御可能なデバイスからのデータを含む。例えば、図１Ａのデバイス１０２の内の制御可能デバイスの状態、構成、機能的状態、パラメータ、および／または、任意のその他のデータが受信される。いくつかの実施形態において、センサデータは、定期的に受信される。例えば、センサデバイスは、現在検出されているセンサデータを定期的に送信する。いくつかの実施形態において、センサデータは、動的に受信される。例えば、センサデータは、センサデータが検出された時に受信される。いくつかの実施形態において、受信されるセンサデータは、複数のセンサデバイスから受信される。いくつかの実施形態において、センサデータは、ハブ（例えば、図１Ａのハブ１０４）で受信され、センサデータは、別のハブと共有される／別のハブに送信される、および／または、処理のためにコンピューティングクラウドへ送信される（例えば、図１Ａのサーバ１０６へ送信される）。
【００４５】
工程２０４で、１または複数の状態が、機械学習を用いて特定される。いくつかの実施形態において、機械学習は、受信されたセンサデータを用いて実行される。いくつかの実施形態において、機械学習の実行は、回帰隠れマルコフモデルおよび／または期待値最大化を利用することを含む。いくつかの実施形態において、各状態は、機械学習を用いて検出したい情報の個別のカテゴリに関連する。例えば、人物によって現在実行されている活動が、検出されうる複数の可能な活動の中から検出されることが望ましい。これは、カメラの動画／画像データを分析して、人物および人物によって実行された活動を検出することによって達成されてよい。いくつかの実施形態において、検出された各対象の状態が決定される。いくつかの実施形態において、センサデータを１または複数の特定の状態に変えることにより、センサデータは、１または複数の自動化ルールを決定するために利用できる意味のある変数値になる。いくつかの実施形態において、状態は、ベクトルの形態であってよい。例えば、状態ベクトルは、値のグループを含む。いくつかの実施形態において、状態ベクトルは、以下の内の１または複数を含む：時刻値、天気予報、日付値、ならびに、時間および／または環境条件に関連するその他のデータ。
【００４６】
多くの例で、完全に正確に特定の状態を決定するのは困難である。例えば、センサデータを用いて、対象の正確な位置および活動を決定するのは困難でありうる。いくつかの実施形態において、決定された状態が正確である可能性／確率が決定される。例えば、特定の状態が、複数の異なる可能な状態の１つである場合があり、可能な各状態が正確な状態である確率が決定される。いくつかの実施形態において、確率を決定するために、機械学習（例えば、統計的学習および／またはディープラーニング）が実行されてよい。例えば、各候補状態の全体の可能性／割合を決定するために、センサデータと潜在的な状態との間の相関、以前の状態と潜在的な状態との間の相関（例えば、遷移モデル）、および、異なる状態／状態要素の間の関係性の、統計的学習モデルおよび／またはディープラーニングモデルが構築され、利用される。
【００４７】
いくつかの実施形態において、時系列での観察が、統計的入力として利用され、時間と共に変化する状態ベクトルを評価するために利用される。状態ベクトルは、検出された対象の存在、活動などについての情報にセンサデータを変換する推論エンジンの出力であってよい。一実施形態において、住居内での対象（例えば、人間およびペット）の動的プロセスおよびそれらの動きがモデル化される。一実施形態では、非線形関係を学習するために、ディープラーニングが利用される。いくつかの実施形態では、人の数、人の位置、および、人の活動を推測するために、マイクセンサからキャプチャされた音が利用される。一実施形態において、音を上述の状態ベクトルに関連付けるために、統計モデルが利用される。
【００４８】
いくつかの実施形態において、対象の活動状態（例えば、概略的な活動状態−読書、睡眠、料理、など、および、詳細な活動状態−本を開いて読む、本を下に置く、など）を含む状態ベクトルが推定される。一実施形態において、状態ベクトルは、時刻、天気、住居にいる人数、対象の位置、および、実行されている現在の活動など、その他の関連情報を含む。いくつかの実施形態において、状態ベクトルは、１または複数の制御可能デバイス状態を含む。いくつかの実施形態において、状態ベクトルは、環境の各領域（例えば、部屋）ごとの対象のリストを含む。いくつかの実施形態において、学習方法は、センサデータの値を状態ベクトルにマッピングする関数の重みを学習する。いくつかの実施形態において、学習方法は、センサデータから状態ベクトルへの多段非線形マッピングを学習するために、ディープラーニングを利用する。
【００４９】
いくつかの実施形態において、１または複数の状態が、環境のグラフモデルを用いて特定される。例えば、図１Ａのサーバ１０６および／またはハブ１０４に格納されたグラフモデルが利用される。グラフモデルの一例は、図９Ａ〜図９Ｄに示されている。グラフモデルがノードとノード間の関係性とを特定するので、特定された状態および／または検出されたセンサデータが、グラフモデルからのコンテキスト情報で増強されうる。例えば、センサの物理的配置の情報（例えば、位置、向きなど）を用いて、検知された情報にコンテキストを提供できるので、センサについての物理的位置情報、ならびに、互いとの関係性および物理環境の領域との関係性が、検出されたセンサデータのさらなる位置情報を推測するために利用されうる。いくつかの実施形態において、グラフモデルから決定されたさらなる状態は、状態ベクトルに含められる。いくつかの実施形態において、グラフモデルは、状態および／またはセンサデータを抽象化することを可能にする。例えば、センサデータは、センサデータが取得された領域のタイプに関連する領域についてのより高いレベルの情報に一般化されうる。
【００５０】
いくつかの実施形態において、センサおよび／またはカメラからのデータは、個人がどの活動を実行ししうるかまたは個人がどの場所に行きうるかを予測するために解析される。活動および／または位置の予測に基づいて、先行動作が取られてよい。例えば、ユーザが読書机に向かって移動し始めた場合に、ユーザが読書机に行って読書すると予測され、ユーザが読書を始める前に、ネットワーク接続された照明が点灯する。
【００５１】
工程２０６で、１または複数の自動化ルールが、特定された状態に基づいて発見される。例えば、特定された状態が特定の制御可能デバイスの状態／ステータス／動作と相関することが観察されると、関連する状態が検出された時に制御可能デバイスを関連する状態／ステータス／動作に置くルールが生成される。決定された状態と検出された制御可能デバイスの状態／ステータス／動作との間の相関が特定されてよく、相関が閾値に達すると、自動化ルールが動的に作成および／または更新される。いくつかの実施形態において、一群の状態および／または或る範囲の状態値と、制御可能デバイスの状態／ステータス／動作との間の相関が特定され、自動化ルールを生成するために利用される。いくつかの実施形態において、各状態の確率測度は、相関および／または自動化ルールを決定する時に利用されてよい。いくつかの実施形態において、決定された状態および関連する確率値ならびに共起する制御可能デバイスの状態／ステータス／動作の履歴が経時的に、格納され、相関を発見するために機械学習（例えば、統計的学習および／またはディープラーニング）を用いて解析される。相関測度が閾値を超えた場合に、対応する自動化ルールが作成／更新されてよい。いくつかの実施形態において、自動化ルールは、発見された新しい相関に基づいて、絶えず追加／更新される。
【００５２】
いくつかの実施形態において、デバイスを制御するルールエンジン内のルールは、自動的に学習される。一実施形態において、ルールは、ポリシーを学習するために、強化学習問題として作成される。一実施形態において、ポリシーの実行は、比例微分制御器を用いて実行される。ルールエンジンは、トリガ状態ベクトルおよびセンサ情報に基づいて動作を行ってよい（例えば、デバイスの状態を変化させてよい）。一実施形態において、機械学習アルゴリズムのパラメータは、オンライン確率的勾配アルゴリズムを用いて変更される。ルールエンジンは、ルールを学習および／またはトリガするために、ユーザデバイス、ウェブサービス、気象情報サービス、カレンダーイベント、および、その他のデータソースからのデータを考慮に入れてよい。
【００５３】
いくつかの実施形態において、１または複数の自動化ルールを発見する工程は、環境のグラフモデルを利用する工程を含む。例えば、自動化ルールは、グラフモデルの特定のノード、エリア／領域、関係性、および／または、エッジに基づいてよい。いくつかの実施形態において、グラフモデルは、より汎用的なルールの発見を可能にする。例えば、信頼できる設置位置情報および／またはデバイスの関係性なしに、ルールに基づいて検出されたセンサ／デバイスだけが発見される。しかしながら、グラフモデルからのコンテキスト情報があれば、一般的な位置の概念／記述（例えば、キッチン）および／またはデバイス間の関係性に適用可能なより汎用的なルールを発見することができる。より汎用的なルールを発見、呼び出し、および／または、利用することを可能にすることにより、ルールは、より多くの状況および位置で適用可能になる。例えば、特定のユーザに固有であるが、より広いエリア／領域に一般化されたルールが、その特定のユーザが、異なるグラフモデルを有するが同じラベルを付されたエリア／領域を持つ異なる環境に移動することから、異なる環境で適用されてよい（例えば、異なるキッチンで、実際の照明デバイスおよびそれらの構成が異なっていても、夜にユーザがキッチンエリアに入った時に照明を点灯するルールが、ユーザの行くすべてのキッチンに適用されてよい）。いくつかの実施形態において、グラフモデルを用いてより広い概念に動作を一般化する（例えば、より広い位置コンテキストに一般化する）ことを可能にすることにより、ルールの発見が、（例えば、同じユーザおよび／または異なるユーザによる）様々な異なるタイプの配備環境にわたって行われうる。
【００５４】
工程２０８で、自動的に発見されたルールが、決定された状態に基づいて呼び出される。例えば、自動的に発見されたルールのトリガ条件は、特定された状態であり、ルールは、制御可能デバイスのプロパティ（例えば、状態／ステータス／機能／動作など）を、ルールによって指定されたように変更するために呼び出される。いくつかの実施形態において、ルールのトリガ条件は、複数の異なる状態および／または或る範囲の状態である。いくつかの実施形態では、複数のルールが、決定された状態に基づいて適用／トリガされる。いくつかの実施形態では、適用されるルールが、適用される別のルールと矛盾する。例えば、或るルールが、照明スイッチをオンにすることが好ましいと規定する一方で、別のルールが、照明スイッチをオフにすることが好ましいと規定する。ルール間の衝突を解消するために、各ルールが、別のルールよりも高いそのルールの優先度を示す優先値に関連付けられてもよい。いくつかの実施形態において、自動的にトリガされたルールの動作に関するユーザからのフィードバックが、報償の形態で受信され、強化学習を用いて、制御ルールが自動的に修正される。
【００５５】
いくつかの実施形態において、ルールを呼び出す工程は、グラフモデルを利用する工程を含む。例えば、１または複数のトリガ条件および／または所望の結果が、グラフモデルの要素に基づく。例えば、条件が特定のデバイスを参照することを要求するのではなく、条件は、グラフモデルのノードおよびエッジに基づいて特定されうる一般化された概念を参照する（例えば、「電球＃２３２１」がオンにされる、に対して、照明が「キッチン」でオンにされる）。
【００５６】
いくつかの実施形態において、最適化関数が、制御可能デバイスのプロパティを変更するために利用される。例えば、各周期間隔で、状態入力が受信され（例えば、ユーザ状態、デバイス／センサ状態、環境状態、工程２０４の状態、など）、状態入力を所与として制御可能デバイスの最適プロパティ設定を選択するために利用される。これは、最適化関数（例えば、コスト関数）を用いて、制御可能デバイスの候補プロパティ設定の最適化評価値（例えば、学習または指定されたコスト値）を評価することで、最適候補プロパティ設定を選択して実施する工程を含む。最適化評価値の１または複数の成分が、１または複数の動的なパラメータに従って変化してよい。
【００５７】
図３は、検出された状態が正確な状態である可能性を決定するための処理の一実施形態を示すフローチャートである。図３の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図３の処理は、図２の工程２０４に含まれる。いくつかの実施形態において、図３の処理は、定期的に実行される。いくつかの実施形態において、図３の処理は、動的に実行される。例えば、図３の処理は、新たなセンサデータが受信された時に実行される。
【００５８】
工程３１２で、実際の状態の候補状態が決定される。例えば、新たに受信されたセンサデータに対応しうる候補状態が特定される。いくつかの実施形態において、候補状態は、対象（例えば、人間、動物、ペット、ロボット、その他の生物または無生物など）の実際の現在の状態であると考えられる状態である。例えば、対象の正確な現在の状態（例えば、位置および現在実行中の活動）は、完全に正確にセンサデータから決定することが困難でありうるので、対象に対する候補状態（例えば、各候補状態は、位置成分および活動成分を含む）が特定される。
【００５９】
いくつかの実施形態において、候補状態を決定する工程は、受信されたセンサデータに関連しうるすべての可能な状態を特定する工程を含む。例えば、カメラからのデータを用いて特定できる対象のすべての可能な所定の活動が特定される。いくつかの実施形態において、候補状態を決定する工程は、最も可能性のある候補状態を特定する工程を含む。例えば、すべての可能な状態を特定するのではなく、最も可能性のある候補状態が特定される。いくつかの実施形態において、最も可能性のある候補状態は、図２の工程２０２で受信された関連センサデータを解析することによって特定される。いくつかの実施形態において、候補状態を決定する工程は、新たに受信されたセンサデータに関連する対象を特定する工程と、対象に対して最後に決定された状態を特定する工程と、を含む。いくつかの実施形態において、最も可能性のある候補状態は、以前の現在の状態に基づいて特定される。例えば、所与の以前の状態（例えば、対象の位置）について、いくつかの状態だけが新しい現在の状態になるのに適格であり（例えば、以前の位置に隣接する位置のみ）、これらの状態が特定される。
【００６０】
いくつかの実施形態では、単一の状態が、複数のサブ状態を含む。いくつかの実施形態において、各状態は、対象の識別子、対象の大まかな位置（例えば、住居／建物のどの部屋か）、大まかな位置の中での対象の詳細な位置（例えば、ベッドルームのベッドの上）、対象が環境内に存在するか否か、対象のタイプ（例えば、人間対ペット、具体的な個人など）、対象の大まかな活動（例えば、読書）、および、対象の詳細な活動（例えば、本を開く）を含む。いくつかの実施形態において、各候補状態は、制御可能オブジェクトの状態を含む。いくつかの実施形態において、対象の活動状態は、検出できる（例えば、観察データ／トレーニングデータに基づいて検出できる）所定の活動の内の１つである。
【００６１】
いくつかの実施形態において、候補状態を決定する工程は、グラフモデル（例えば、図９Ａ〜図９Ｄに示したグラフモデル）に基づいて状態を特定する工程を含む。例えば、受信されたセンサデータがコンテキストを与えられ、センサデータに関連する情報が、グラフモデルに基づいて特定される（例えば、データを検出したセンサのノードに接続されたエッジの情報／プロパティ、および、センサのノードに接続された他のノードの情報／プロパティ）。可能な状態は、グラフモデルに基づいて特定および／または除外されてよい。
【００６２】
工程３１４で、候補状態の各々について、その候補状態が受信センサデータに対応する可能性が決定される。例えば、受信されたセンサデータが特定の候補状態に対応する確率が決定される。いくつかの実施形態において、可能性は、センサデータを所与として、候補状態が実際の状態である確率を特定する。いくつかの実施形態において、この可能性は、機械学習を用いて決定される。例えば、統計的学習および／またはディープラーニング処理が、異なるセンサデータと、対応する状態との間の関連性の例のトレーニングデータセットを解析して、異なるセンサデータと、異なる状態との間の関連性の関連確率を決定するために利用されてきた。いくつかの実施形態において、候補状態が受信センサデータに対応する可能性は、所定の解析アルゴリズムを用いて決定される。例えば、コンピュータ視覚パターン認識アルゴリズムが、カメラセンサデータの解析に利用され、アルゴリズムは、可能性を提供する。いくつかの実施形態において、可能性は、グラフモデルを用いて決定される。
【００６３】
工程３１６で、候補状態の各々について、候補状態が、以前に特定された状態の後の次の状態である可能性が決定される。例えば、候補状態が、対象の以前に決定された状態が決定された状態の後の実際の状態である確率が決定される。いくつかの実施形態において、この可能性は、機械学習を用いて決定される。例えば、統計的学習および／またはディープラーニング処理が、異なる状態の間で観察された状態遷移を解析して、以前の状態を所与として各潜在的な候補状態の確率の遷移モデルを決定するために利用されてきた。一例では、モーション検出センサが、住居の各部屋に設置されてきた。住居の部屋の相対位置は、機械学習を用いて、対象が部屋から部屋へ移動する時にセンサトリガのパターンを観察することによって、自動的に決定されうる。部屋の間の接続がわかると、対象の現在の部屋の位置を所与として、隣接する可能性のある部屋がわかり、接続されている可能性のある部屋の内の隣の部屋に対象が行く各可能性が、決定されてよい。例えば、対象の位置を示す以前の状態を前提として、次の状態は、対象の決定／観察された移動速度および状態のセンサデータ間の経過時間を所与として到達可能な隣接する部屋に限定される。いくつかの実施形態において、候補状態が次の状態である可能性は、グラフモデルを用いて決定される。
【００６４】
工程３１８で、候補状態の各々について、同時状態成分相関が決定される。例えば、いくつかの候補状態成分は、候補状態成分の別のグループよりも正確な状態に一緒に含まれる可能性が高い。いくつかの実施形態において、同時状態相関を決定する工程は、候補状態の或る成分が候補状態の別の成分を所与として正確な／実際の状態に含まれる確率を決定する工程を含む。例えば、候補状態が、位置状態成分および活動状態成分を含み、特定の位置状態成分を所与として特定の活動状態成分の確率が決定される。いくつかの実施形態において、同時状態相関を決定する工程は、候補状態の状態成分の異なる対の組みあわせとそれぞれ関連する複数の確率を決定する工程を含む。いくつかの実施形態において、同時状態成分相関は、グラフモデルを用いて決定される。
【００６５】
工程３２０で、候補状態の各々について、候補状態が実際の状態である全体の可能性が決定される。例えば、各候補状態について、候補状態が対象の正確な状態である全体の確率が決定される。いくつかの実施形態において、全体の状態を決定する工程は、工程３１４、３１６、および、３１８で決定された確率の内の１または複数を掛け合わせる工程を含む。例えば、少なくとも、候補状態が受信センサデータに対応する第１確率および候補状態が以前に特定された状態の次の状態である第２確率が、全体の可能性を得るために掛け合わせられる。いくつかの実施形態において、候補状態は、それらの全体の可能性に基づいてソートされ、最良の全体の可能性を有する候補状態が、実際の／正確な状態として選択される。
【００６６】
図４は、ネットワーク接続された制御可能デバイスの自動化ルールを自動的に発見するための処理の一実施形態を示すフローチャートである。図４の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図４の処理は、図２の工程２０６に含まれる。いくつかの実施形態において、図４の処理は、定期的に実行される。いくつかの実施形態において、図４の処理は、動的に実行される。例えば、図４の処理は、新たな現在の状態が特定された時に実行される。
【００６７】
工程４０２で、特定された状態は、対応する制御可能デバイスプロパティと相関される。例えば、図３の工程３１２で対象の実際の状態として特定された状態が、図１Ａのデバイス１０２の内の制御可能デバイスの対応するステータス、構成、機能的状態、プロパティ、パラメータ、および／または、任意のその他のデータと相関される。いくつかの実施形態において、特定された状態は、特定された状態に対応する制御可能デバイスプロパティを特定するために、特定された状態および制御可能デバイスプロパティの格納された履歴を解析することによって、対応する制御可能デバイスプロパティと相関される。例えば、特定された状態（例えば、状態ベクトル）と、制御可能デバイスの対応する制御可能プロパティ（例えば、ステータス、構成、機能的状態、パラメータ、および／または、任意のその他のデータ）との間の対応する組み合わせが決定される。いくつかの実施形態において、特定された状態を対応する制御可能デバイスプロパティと相関させる工程は、相関を発見するために機械学習を実行する工程を含む。例えば、統計的学習および／またはディープラーニング技術が、特定された状態と制御可能デバイスプロパティとの間の時間的相関を発見するために利用される。いくつかの実施形態において、特定された状態は、以下の内の１または複数を含みうる状態ベクトルを含む：時刻値、天気予報、日付値、ならびに、時間および／または環境条件に関連するその他のデータ。いくつかの実施形態において、特定された状態が特定の制御可能デバイスプロパティに対応する履歴確率が決定される。
【００６８】
工程４０４で、特定された状態は、１または複数の特定された状態のクラスタと相関される。いくつかの実施形態において、類似の特定された状態（例えば、或る範囲内の状態値）が、クラスタ化され、制御可能デバイス状態と相関される。例えば、互いに近い範囲にある物理的位置に関連する特定されたデバイス状態がクラスタ化される。この状態のクラスタは、１または複数の対応する制御可能デバイスプロパティと相関される。いくつかの実施形態において、クラスタ内の１または複数の特定された状態が同じ制御可能デバイスプロパティと対応するクラスタ確率が決定される。クラスタ確率は、クラスタに含まれる任意の特定された状態が制御可能デバイスプロパティに対応する履歴確率を特定しうる。いくつかの実施形態において、クラスタ確率は、クラスタの各特定された状態の個々の確率（例えば、図３の工程３２０で決定された確率）を少なくとも掛け合わせることによって決定される。いくつかの実施形態において、クラスタは、環境のグラフモデル（例えば、図９Ａ〜図９Ｄに示したグラフモデル）を用いて特定される。例えば、特定された状態に対応するノード／エッジが特定され、クラスタは、グラフモデル内の近接に基づいて特定される。
【００６９】
工程４０６で、履歴確率が閾値を満たす場合、関連する自動化ルールが作成される。例えば、工程４０２で決定された履歴確率および／または工程４０４で決定されたクラスタ確率が、閾値（例えば、８０％）より大きい場合、対応する自動化ルールが、ルールデータベースに格納される。いくつかの実施形態において、自動化ルールは、（例えば、特定された状態のクラスタに含まれる）特定された状態が検出された場合に、対応する制御可能プロパティ設定が再作成／実施される（例えば、対応する制御可能デバイスのプロパティが、制御可能デバイスプロパティ設定で指定されたルールでになるよう変更される）ことを特定する。いくつかの実施形態において、自動化ルールは、定期的に更新される。例えば、自動化ルールは、終了時刻に関連付けられており、ルールは、終了後に更新または削除される。いくつかの実施形態において、関連する自動化ルールを生成する工程は、特定された状態と、対応する制御可能デバイスプロパティとの間の関係性を特定する１または複数の最適化評価値を設定または変更する工程を含む。例えば、特定された状態を所与として、対応する特定の制御可能デバイスプロパティ設定のユーザの望ましさ度が決定され、最適化関数を用いて制御可能デバイスを自動的に決定および制御する際に利用するために保存される。
【００７０】
図５は、選択された出力結果を決定するための処理の一実施形態を示すフローチャートである。図５の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図５の処理は、図２の工程２０８に含まれる。いくつかの実施形態において、図５の処理は、定期的に実行される。例えば、図５の処理は、一定の時間間隔で繰り返される。いくつかの実施形態において、図５の処理は、動的に実行される。例えば、図５の処理は、新たな入力または状態が特定された時に実行される。いくつかの実施形態において、図５の処理は、各制御可能デバイスの各制御可能プロパティが自動的に制御されるように繰り返される。
【００７１】
工程５０２で、状態を示す複数の入力が受信される。例えば、各入力は、その入力の関連する状態を特定する。いくつかの実施形態において、受信された入力は、制御可能デバイスの自動制御に対応する。例えば、入力の状態は、新たな制御設定を決定するために解析され、動作が、制御可能デバイスに新たな制御設定を実施するために潜在的に実行される。いくつかの実施形態において、受信された入力は、図２の工程２０４で特定された１または複数の状態を含む。いくつかの実施形態において、受信された入力は、図３の処理を用いて特定された１または複数の状態（例えば、状態のベクトル）を含む。各受信された入力は、１または複数の対象の対応する状態（例えば、ユーザ位置、ユーザ活動、ユーザ嗜好、ユーザタイプ、ユーザプロフィール、ユーザカテゴリ、ユーザの習熟レベル、ユーザ知識レベル、システム機能のユーザ知識など）、デバイスの対応する状態（例えば、センサデータ、制御可能デバイス設定、デバイス構成など）、および／または、環境の対応する状態（例えば、時刻、日付、気象、湿度、空気の質、地理的位置など）を示しうる。いくつかの実施形態において、受信された状態は、以前の状態（例えば、対象物、デバイス、センサのなど以前の状態の履歴）を含む。いくつかの実施形態において、受信された状態は、ユーザインタラクティブな認定の問い合せまたは示唆に応答して受信された以前のユーザが提供した示唆を特定する状態を含む。いくつかの実施形態において、状態を示す入力の内の１または複数は、受信されたセンサ情報を解析することによって決定されたものである。例えば、図１Ａのデバイス１０２の内の１または複数のデバイスおよび／または図１Ｂのセンサ１２４からのセンサ情報が、状態を決定するために受信および利用される。いくつかの実施形態において、複数の入力の内の少なくとも１つが、シーンモードを示す。例えば、様々なシーンモード（例えば、朝食シーン、就寝シーン、読書シーン、映画鑑賞シーン、不在モードなど）が、１または複数のユーザの特定の活動または状況にとって望ましい一群の制御可能デバイス設定を規定する。シーンモードは、ユーザによって手動で指定されてよい、および／または、自動的に決定されてよい。
【００７２】
いくつかの実施形態において、複数の入力の内の少なくとも１つが、状態、出力、出力タイプ、設定、および／または、構成の履歴を示す。例えば、入力は、制御可能デバイスプロパティ設定を特定する１または複数の以前に決定された出力を特定する。いくつかの実施形態において、入力状態の内の１または複数は、対応する状態が正確な状態である信頼度に関連付けられる。例えば、受信されたセンサ情報に基づいて全く正確な状態を決定することは難しい場合があり、候補状態が、関連する信頼度スコア値と共に特定される。
【００７３】
いくつかの実施形態において、入力を受信する工程は、より大きいグループの入力の中から利用される入力を選択する工程を含む。例えば、制御可能デバイスのプロパティのための出力制御設定を自動的に決定する際にどの入力が関連するのかが決定される。利用される入力の選択は、予め構成されていてもよい（例えば、制御可能デバイスの特定の制御可能プロパティのための所定の構成に基づいて決定されていてよい）。例えば、プログラマが、特定の出力（例えば、制御可能デバイスの制御設定）を自動的に決定する際にどの入力が解析されるのかを手動で構成している。いくつかの実施形態において、利用される入力の選択は、図４の工程４０６で作成された自動化ルールに少なくとも部分的に基づく。いくつかの実施形態において、利用される入力の選択は、制御可能デバイスに対する入力に関連するデバイスの位置に少なくとも部分的に基づく。例えば、（例えば、グラフモデルを用いて決定された）設置環境内のデバイス／センサの物理的位置のマッピングに基づいて、制御される制御可能デバイスと同じ部屋および／または物理的に近くに配置されたデバイスの状態が、自動的に入力として選択される。様々な実施形態において、利用される入力の選択は、機械学習に基づいて自動的に決定される。
【００７４】
工程５０４で、示唆された状態に基づいて、制御可能デバイスを自動制御する複数の出力候補が評価される。例えば、示唆された状態は、図２の工程２０６で発見され工程２０８で呼び出された１または複数の評価ルールへの入力として、少なくとも部分的には出力候補および／または出力候補の望ましさを特定することによって制御可能デバイスを自動的に制御するために利用される。
【００７５】
いくつかの実施形態において、複数の出力候補が評価される。例えば、制御可能デバイスの制御可能プロパティ設定の複数の候補（例えば、制御可能デバイスのプロパティの候補設定）が評価される。各出力候補は、特定の制御可能プロパティ設定に関連するだけでなく、特定の出力操作タイプに関連する。制御可能デバイスの制御可能プロパティを変更するための動作を実行することに関連する出力操作タイプの例は、以下を含む：動作（例えば、ユーザインタラクティブな認定を受けずに実行される動作）を実行する；動作が実行される旨の警告を提供した後に動作を実行する（例えば、動作の実行を取り消すユーザインタラクティブな機会がある）；動作を実行するか否かをユーザに問い合わせる（例えば、ユーザが動作の実行をインタラクティブに承認した場合にのみ動作を実行する）；ユーザが動作を手動で実行する可能性があると判定する（例えば、動作を実行せずに待機する）；および、動作を実行しない。
【００７６】
いくつかの実施形態において、複数の出力候補の評価は、自動的に検出／学習されたおよび／またはユーザ／プログラマ指定された嗜好／ルールに少なくとも部分的に基づく。例えば、どの最適化関数を利用するか、および／または、異なる構成設定の間の嗜好／関係性を示す値（例えば、最適化評価値／期待値）が、機械学習および／または（例えば、図４の処理を用いて決定された）嗜好／ルールを用いて自動的に選択／決定される。
【００７７】
いくつかの実施形態において、複数の出力候補は、最適化関数に従って評価される。例えば、制御可能デバイスの制御可能プロパティ設定の複数の候補（例えば、制御可能デバイスのプロパティの候補設定）が、最適化関数に従って評価される。最適化関数は、受信された入力ならびに１または複数の受信された入力の１または複数のパラメータに依存する。最適化関数の例は、コスト関数、最大化関数、リスク関数、価値関数、確率関数、決定関数、または、複数の出力候補を比較するために利用できる任意のその他の関数、を含む。いくつかの実施形態において、出力候補を評価する工程は、各構成候補について各出力候補の予測された望ましさ度（例えば、最適化期待値）を決定する工程を含む。例えば、各出力候補について、候補出力の望ましさを特定する候補最適化期待値が決定される。最適化関数を用いて最適化期待値を比較することにより、出力候補の１つが、実施される最適出力として選択されてよい。
【００７８】
いくつかの実施形態において、出力候補を評価する工程は、各出力候補について（例えば、各出力候補は、制御可能デバイスの特定の制御可能プロパティの特定の出力操作タイプおよび特定の構成設定候補に関連する）、受信された入力状態の少なくとも一部の各々に対する出力候補の予測された望ましさ度を評価する工程を含む。例えば、望ましさ度は、入力状態が同じであっても、各異なる出力候補によって異なる。いくつかの実施形態において、特定の出力候補の望ましさ度を決定するために、出力候補に対応する入力状態成分評価値（例えば、成分期待値）が、各入力状態について決定され、出力候補の入力状態成分評価値は、出力候補の望ましさ度全体（例えば、総期待値）を決定するために、合計される／まとめられる（例えば、平均される）。換言すると、各入力状態に対応する成分値が、各出力候補の期待値を決定するために、各出力候補について合計される／まとめられる（例えば、加重平均される）。一例において、電動式カーテンデバイスに対する構成設定候補は、カーテン開設定およびカーテン閉設定である。この例の出力操作タイプは、デバイスを望ましい設定（例えば、カーテン開またはカーテン閉）に置くための動作を自動的に実行すること、動作を自動的に実行する前にユーザに警告すること、動作を実行するか否かをユーザに問い合わせること、および、ユーザが動作を手動で実行するのを待つこと、を含む。この例では、８つの総期待値が決定される（例えば、４つの出力処理作タイプ×２つの構成設定候補＝８つの出力候補）。これらの総期待値の各々について、出力候補に関する各入力状態の成分期待値が、（例えば、発見された自動化ルールを用いて）決定され、（例えば、最適化関数を用いて）組み合わせられることで、総期待値が決定された。
【００７９】
いくつかの実施形態において、すべての構成設定候補に対する出力操作タイプを評価するのではなく、最初に、望ましい構成設定候補がすべての構成設定候補の中から選択され、次いで、望ましい構成設定候補に対する出力操作タイプが、望ましい構成設定候補について評価され、選択されなかった構成設定候補については評価されない。例えば、対応する構成設定候補に対する各入力状態に対応する各構成設定候補の個々の成分望ましさ度を組み合わせることによって、各構成設定候補の望ましさ度の総計が、（例えば、自動的に発見された自動化ルールを用いて）決定される。（例えば、最適化関数を用いて）異なる構成設定候補の望ましさ度の総計を比較することにより、望ましい構成設定候補が選択される。次いで、望ましい構成設定候補を所与として、異なる出力操作タイプが、望ましい構成設定候補のための異なる出力操作タイプの各々について総期待値を決定することによって評価される。これらの総期待値の各々について、対応する出力操作タイプに関する各入力状態の成分期待値が、（例えば、発見された自動化ルールを用いて）決定され、（例えば、最適化関数を用いて）組み合わせられることで、対応する出力操作タイプの総期待値が決定される。これは、選択された望ましい構成設定候補の異なる出力操作タイプに、出力候補を効果的に絞る。
【００８０】
いくつかの実施形態において、望ましさの尺度（例えば、期待値）は、要因の中でも特に、入力状態を所与として関連出力候補を選択する潜在的な利益／リスク／コスト、入力状態を所与として関連出力候補を選択しない潜在的損害、選択された過去の出力候補の履歴、関連オプションの選択についてのユーザへの迷惑など、を考慮に入れてよい。
【００８１】
一例において、関連構成設定を実施するための動作を実行するか否かをユーザへインタラクティブに問い合わせる出力操作に関連する出力候補の期待値を決定する際に、この出力候補の期待値は、ユーザについて検出された状態に照らしてユーザへの問い合せの迷惑を考慮に入れる（例えば、ユーザが睡眠状態である場合、ユーザへの迷惑度が高い）。別の例において、ユーザが動作を手動で実行するのを待つ出力操作に関連する出力候補の期待値を決定する際に、この出力候補に関連する期待値は、動作を手動で実行するためにユーザが必要とする労力を考慮に入れる（例えば、ユーザが物理的に物理スイッチの近くにいて、いつもどおりに手動でスイッチを作動させる場合、労力は少ない）。
【００８２】
別の例において、動作のトリガをインタラクティブに防ぐ機会をユーザに与える出力操作に関連する出力候補の期待値を決定する際に、この出力候補の関連期待値は、動作の深刻性（例えば、夜にベッドルームのカーテンを開けるなどの非常に重大な動作は、入力状態が高い信頼度で決定されえない限りは自動的に実行されるべきではない）、および、以前に選択された出力（例えば、ユーザが、動作を実行するか否かについての応答を提供することを求めた以前の要求に応答しなかった場合、警告後にその動作が実行される可能性が高い）を考慮に入れる。
【００８３】
別の例において、ユーザインタラクティブな認定を受けずに動作を実行することに関連する出力候補の期待値を決定する際に、この出力候補の関連期待値は、ユーザが以前に動作の実行の希望を示唆したか否かを考慮に入れる。例えば、ユーザが、ユーザの快適さ／満足度を高める任意の動作を実行するという希望を示唆する場合があり（例えば、ユーザは、「私を幸せにして」という音声コマンドを提供する）、システムがユーザの満足度を高めるための動作を実行するというユーザの認識および希望を前提として、認定なしに（例えば、警告もユーザ確認要求もなしに）動作が実行される可能性が高い。いくつかの実施形態において、ユーザの快適さ／満足度を高める任意の動作を実行する希望をユーザが示唆することは、曖昧であるかまたはシステムによって理解されない検出ユーザコマンドに関連する。例えば、ユーザコマンドが完全には理解されない場合でも、それは、ユーザの快適さおよび満足度を高める１または複数の動作を実行するというユーザの希望を示唆する。
【００８４】
いくつかの実施形態において、１または複数の成分評価値（例えば、成分期待値）が、動的に決定される。例えば、出力候補および入力状態から成分評価値への所定の静的なマッピングを用いるのではなく、成分評価値は、１または複数の他の変数に従って変化しうる。一例において、成分評価値は、時刻値を入力として用いるパラメータによってパラメータ化された減衰関数に従って、指定されたイベントの時刻から経時的に減衰する。入力状態の中で以前の状態の履歴を考慮に入れる場合、古い履歴状態を重視せず、最近の履歴状態の効果を強調するために、成分評価値の減衰が利用されてよい。いくつかの実施形態において、１または複数の成分評価値は、以前の出力イベントから経過した時間に基づく。例えば、指定された最近の時間窓内でユーザに提供されるユーザインタラクティブな問い合せの総回数に制限が存在し、この制限に達したか否かに応じて、１または複数の成分評価値が大きくまたは小さくなる。
【００８５】
いくつかの実施形態において、特定の出力候補について各個別の入力状態を別個に評価するだけではなく、入力状態のクラスタが、特定の出力候補についてグループとして評価される。例えば、いくつかの入力状態が、（例えば、グラフモデルに基づいて）共に相関されるために決定され、出力候補について、成分最適化評価値が、個々の入力状態について別個にではなく、単一の全体として入力状態のクラスタについて（例えば、グラフモデルに基づいて）決定される。
【００８６】
工程５０６で、選択出力候補が、評価に基づいて出力候補の中から選択される。例えば、最適化関数を最適化する出力が、出力候補の中から選択される。いくつかの実施形態において、選択出力候補は、制御可能デバイスのプロパティの選択された構成設定を特定する。いくつかの実施形態において、出力を選択する工程は、出力候補最適化評価値の比較（例えば、最適化関数を用いて最適化評価値を比較する）に基づいて出力候補を選択する工程を含む。例えば、コスト値（例えば、期待値）が、各出力候補に対して決定されており、コスト最小化関数を用いて、最小のコスト値を持つ出力候補が選択される。
【００８７】
様々な実施形態において、最適化関数を利用することにより、自動化の相関／ポリシー／ルールの間の衝突が解消される。例えば、受信された入力状態が２以上の自動化相関／ポリシー／ルールをトリガするので、これら２以上の自動化相関／ポリシー／ルールが有効化されるが、それらは、すべてが同時に実施されることができない矛盾する制御可能デバイス設定を指定しうる（例えば、或るルールが「オン」構成設定を指定する一方で、別のルールが「オフ」構成設定を指定する）。各可能な構成設定に関連する様々な関連最適化値を比較することにより、入力状態を所与とした最も最適な構成設定が決定されてよい。
【００８８】
工程５０８で、選択出力候補が実施される。いくつかの実施形態において、妥当な場合には、選択出力候補に関連する動作が実行される。例えば、選択出力候補の制御可能デバイス構成設定が、現在の設定からの変更である場合、動作は、選択出力候補の出力操作タイプに基づいて、妥当であれば、選択出力候補の制御可能デバイス構成設定へ変更するために制御可能デバイスに命令を提供することによって実行される。動作の別の例は、１または複数のセンサデバイスを用いて得られた情報に基づいて、遠隔ユーザへ警告／通知を送信する動作を含む。
【００８９】
いくつかの実施形態において、選択出力候補に関連する動作は、将来の或る時点に実行される（例えば、明朝９時にコーヒーメーカーのスイッチを入れる動作）。例えば、動作を実行することは、将来の指定された時間に制御可能デバイスの設定を変更するために制御可能デバイスに提供されたまたは提供される１または複数の命令のスケジューリングすることを含む。いくつかの実施形態において、選択出力候補に関連する動作は、反復される（例えば、指定された間隔で反復される）。例えば、動作を実行することは、定期的に制御可能デバイスの設定を変更する（例えば、平日の午前９時に毎日カーテンを開ける）ために制御可能デバイスに提供されたまたは提供される１または複数の命令をスケジューリングすることを含む。いくつかの実施形態において、選択出力候補の制御可能デバイス構成設定は、制御可能デバイスの将来の状態または挙動に影響する構成設定を示す。例えば、選択出力候補の制御可能デバイス構成設定は、将来に電球のスイッチを入れられた時にはいつでも、望ましい明るさを示す。いくつかの実施形態において、動作および／または選択出力候補は、複数の制御可能デバイスのための複数の構成設定を制御することに関連する。例えば、動作は、複数の異なる制御可能デバイスの制御可能デバイス構成設定へ変更するためにそれらのデバイスに命令が送信されるようトリガする。
【００９０】
動作を実行することに関連する出力操作タイプの例は、以下を含む：動作（例えば、ユーザインタラクティブな認定を受けずに実行される動作）を実行する；動作が実行される旨の警告を提供した後に動作を実行する（例えば、動作の実行を取り消すユーザインタラクティブな機会がある）；動作を実行するか否かをユーザに問い合わせる（例えば、ユーザが動作の実行をインタラクティブに承認した場合にのみ動作を実行する）；ユーザが動作を手動で実行する可能性があると判定する（例えば、動作を実行せずに待機する）；および、動作を実行しない。選択出力候補に関連する出力操作タイプに応じて、選択出力候補の実施は異なって操作される。様々なタイプの処理の例を図７に示す。
【００９１】
工程５１０で、出力に関するフィードバックが受信される。例えば、出力結果が望ましくない出力結果（例えば、制御可能デバイスの構成設定）になった場合、ユーザは、構成設定を明確に変更することによって特にその構成設定を置き換えてもよい（例えば、ネットワーク接続された制御可能デバイスの制御スイッチを調整してよい）。いくつかの実施形態において、ユーザは、出力構成設定の変更が望まれたか否かをユーザ示唆を介して確認してよい。例えば、ユーザデバイスを用いて、ユーザは、最近の出力が結果としてユーザの望む自動化挙動につながったか否かを明確化してよい。いくつかの実施形態において、ユーザによる行動がなければ、望ましくない出力ではなかったという確認フィードバックになる。例えば、同じ入力状態を前提として、ユーザが、より長くおよび／またはより頻繁に、フィードバックの提供も構成設定の変更もしていないほど、入力状態と選択された出力との間の関係性が、ユーザによって受け入れられていると想定される。
【００９２】
工程５１２で、受信されたフィードバックに少なくとも部分的に基づいて、妥当な場合、１または複数の参照最適化評価値が更新される。例えば、入力状態と特定の出力候補（例えば、制御可能デバイスの構成設定）との間の関連性を特定する１または複数の参照値（例えば、期待値を決定する際に将来の評価のために参照される評価メトリック値）が、受信されたフィードバックを用いて更新される。例えば、出力が望ましかったというユーザからの肯定的な示唆があれば、関連する最適化評価値を下げ、出力が望ましくなかったというユーザからの否定的な示唆があれば、関連する最適化評価値を上げる。
【００９３】
図６は、ネットワーク接続された制御可能デバイスの制御可能プロパティの出力候補を自動的に決定するための処理の一実施形態を示すフローチャートである。図６の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図６の処理の少なくとも一部は、図２の工程２０８に含まれる。いくつかの実施形態において、図６の処理の少なくとも一部は、図５の工程５０４および／または工程５０６に含まれる。
【００９４】
工程６０２で、自動制御される制御可能デバイスプロパティの候補構成設定が、評価に向けて選択される。例えば、制御可能デバイスのプロパティの構成設定を自動的に決定するために、プロパティの各候補構成設定が、ネットワーク接続デバイス設置環境（例えば、アパートメントユニット）の状態（例えば、工程５０２で受信されたユーザ、センサ、デバイス、環境、構成モード／グループ分けの状態など）に基づいて評価され、各候補構成設定が評価に向けて繰り返し選択される。いくつかの実施形態において、次の候補構成設定を選択する工程は、制御可能ネットワークデバイスのプロパティのための候補構成設定のリスト内の次の項目を選択する工程を含む。いくつかの実施形態において、候補構成設定のリストは、制御可能ネットワークデバイスのプロパティのすべての可能な構成設定を含む。制御可能ネットワークデバイスのプロパティの例は、スイッチ状態、値の設定、強度レベル、通知が送信されるべきか否か、および、任意のその他の制御可能なプロパティを含む。様々な実施形態において、制御可能ネットワークデバイスは、図１Ａのデバイス１０２または図１Ｂのデバイス１２６に含まれる。
【００９５】
プロパティのための候補構成設定のリストは、予め構成されてよい。例えば、プロパティのためのすべての可能な構成設定からの一部が、リストに含まれるよう選択されている。いくつかの実施形態において、反復されるプロパティのための候補構成設定のリストは、動的に決定される。例えば、候補構成設定値は、１または複数の変数に基づいて動的に変化する１または複数の限界によって制限される。例えば、電球の最大強度出力は、日中の時間に基づいて制限され（例えば、電球は、日中には全範囲の強度を出力することを許容されるが、夜間には最大強度の５０％しか出力しないよう制限される）、候補構成設定のリストは、時間に基づいた制限内の強度値だけを含む。
【００９６】
工程６０４で、各適用可能な入力状態について、選択された候補構成設定の成分評価値が決定される。例えば、制御可能ネットワークデバイスのプロパティを自動制御するために図５の工程５０２で受信された入力状態の各適用可能な入力状態について、選択された候補構成設定の成分評価値が決定される。
【００９７】
いくつかの実施形態において、（例えば、特定の構成設定についての）入力状態および候補状態の各々異なるペアについて、入力状態と候補出力との間の関係性を定量化する対応する成分評価値を格納するデータ構造が存在する。例えば、成分評価値は、特定の入力状態のために選択された候補構成設定の望ましさの大きさを特定する。いくつかの実施形態において、成分評価値は、自動的に検出／学習されたおよび／またはユーザ／プログラマ指定された嗜好／ルールに少なくとも部分的に基づく。例えば、どの最適化関数を利用するか、および／または、特定の構成設定の嗜好／構成設定の間の関係性を示す成分最適化評価値／期待値が、機械学習および／または（例えば、図４の処理を用いて決定された）嗜好／ルールを用いて自動的に選択／決定される。
【００９８】
いくつかの実施形態において、成分評価値は、グラフモデルに基づいて決定される。例えば、関連ノードの間の関連エッジのプロパティが、選択された候補構成設定の望ましさを特定する。一例において、成分評価値は、コスト関数を用いて評価されるコスト値である。いくつかの実施形態において、成分評価値は、少なくとも部分的には式を用いて計算される。いくつかの実施形態では、評価値が、自動的に決定されている。例えば、評価値は、検出されたデータおよびユーザフィードバックに基づいて機械学習を用いて決定されている。いくつかの実施形態において、評価値は、少なくとも部分的に事前に規定されている。例えば、ユーザおよび／またはプログラマが、評価値を指定している。
【００９９】
いくつかの実施形態において、入力状態の成分評価値を決定する工程は、１または複数のパラメータを用いて成分評価値を動的に決定する工程を含む。例えば、所定の静的な値を用いるのではなく、成分評価値は、パラメータへの入力である１または複数の他の変数に従って変化しうる。いくつかの実施形態において、成分評価値は、時刻値を入力として用いるパラメータによってパラメータ化された減衰関数に従って、指定されたイベントの時刻から経時的に減衰する。例えば、照明スイッチが手動でオンにされた後に、電球の光強度が徐々に減衰し、最大の明るさの光強度設定に関連する成分評価値は、スイッチがオンにされてからの時間を入力値として利用するパラメータ減衰関数に従って減衰する。いくつかの実施形態において、成分評価値は、環境内で検出されたユーザの数に基づいたパラメータに従って変化する（例えば、特定のスイッチ状態および候補光レベル構成設定のための成分評価値が、部屋にいるユーザの数に基づく）。
【０１００】
いくつかの実施形態において、１または複数の入力状態および／またはパラメータは、１または複数の以前の出力または構成設定に基づく。例えば、短期間内に構成設定を急速に変更することは（例えば、モータ、電球などにダメージを与えうるため）望ましくなく、短期間に異なる構成設定へ複数回変更することは、成分評価値の決定時に以前の構成設定の変化を考慮に入れる（例えば、多くの構成変更が短期間内に制御可能デバイスの同じプロパティに対して実施された時に、基本成分評価値に調整係数を加える）ことによって妨げられる。
【０１０１】
いくつかの実施形態において、特定の成分評価値について各適用可能な入力状態を別個に評価するだけではなく、入力状態のクラスタが、特定の成分評価についてグループとして評価される。例えば、いくつかの入力状態が、（例えば、グラフモデルに基づいて）共に相関されるために決定され、成分最適化評価値が、個々の入力状態について別個にではなく、単一の全体として入力状態のクラスタについて決定される。
【０１０２】
工程６０６で、決定された成分評価値は、選択された潜在的な構成設定の各出力操作タイプについて総評価値（例えば、総期待値）を決定するために組み合わせられる。選択された候補構成設定の出力操作タイプは、デバイス設定を関連する選択候補構成設定に変更するための動作が、妥当な場合に、どのように操作されるかおよび操作されるか否か（例えば、制御可能デバイスプロパティ設定変更がどのように操作されるか）を指定する。制御可能デバイスのプロパティを変更するための動作を実行することに関連する出力操作タイプの例は、以下を含む：動作（例えば、ユーザインタラクティブな認定を受けずに実行される動作）を実行する；動作が実行される旨の警告を提供した後に動作を実行する（例えば、動作の実行を取り消すユーザインタラクティブな機会がある）；動作を実行するか否かをユーザに問い合わせる（例えば、ユーザが動作の実行をインタラクティブに承認した場合にのみ動作を実行する）；ユーザが動作を手動で実行する可能性があると判定する（例えば、動作を実行せずに待機する）；および、動作を実行しない。
【０１０３】
いくつかの実施形態において、選択された候補に対して決定された成分評価値が合計される／組み合わせられる。いくつかの実施形態において、総評価値を決定する工程は、決定された成分最適化評価値の内の１または複数の値の加重和を決定する工程を含む。いくつかの実施形態において、総評価値を決定する工程は、決定された成分評価値の内の１または複数の値の平均を決定する工程を含む。
【０１０４】
いくつかの実施形態において、総評価値を決定する工程は、成分評価値の加重値を決定する工程を含む。例えば、全く正確な現在の状態を完全な精度で決定するのは困難な場合があるので、受信された入力状態の内の１または複数が、入力状態が実際の正確な入力状態である決定された可能性を表す１または複数の重み係数（例えば、パーセント値）に関連付けられる。これは、同一の実際の入力状態のための異なる候補入力状態が受信され、独立して評価された後に、重み係数に基づいて重み付けされて結びつけられること（例えば、加重平均）を可能にしうる。例えば、ユーザが座った状態である可能性が７０％であり、ユーザが立った状態である可能性が３０％であることを、受信された入力が示すとする。他の最適化評価値と合計する前に、座った状態について決定された成分評価値に０．７を掛け、立った状態について決定された成分値に０．３を掛ける。重み値は、１または複数の要因に基づいて（例えば、時刻またはその他の環境変数／状態に基づいて）動的に変化しうる。
【０１０５】
いくつかの実施形態において、成分評価値または加重成分評価値の合計または平均の結果が、選択された潜在的構成設定の各出力操作タイプに対する総評価値を決定するために、スケーリングおよび／または調整（例えば、調整値の加算または減算）される。例えば、スケーリングまたは調整値は、特定の構成設定の各異なる出力操作タイプに固有であり、入力状態の内の１または複数に基づいて変化する。例えば、１または複数の入力状態の各々について、特定の構成設定および出力操作タイプに固有の対応するスケーリングまたは調整値が、選択された潜在的構成設定の各出力操作タイプに対する最終的な総評価値（例えば、総期待値）を決定するために決定および適用される（例えば、成分評価値および／または総評価値に適用される）。
【０１０６】
いくつかの実施形態において、スケーリングおよび／または調整値は、要因の中でも特に、選択された潜在的な構成設定に対する関連出力操作タイプを選択する潜在的な利益／リスク／コスト、選択された潜在的な構成設定に対する関連出力操作タイプを選択しない潜在的な損害、選択された過去の出力操作タイプの履歴、関連出力操作タイプの選択についてのユーザへの迷惑など、を考慮に入れてよい。
【０１０７】
一例において、関連構成設定を実施するための動作を実行するか否かをユーザへインタラクティブに問い合わせる出力操作タイプに関連するスケーリングおよび／または調整値を決定する際に、この出力操作タイプのスケーリングおよび／または調整値は、ユーザについて検出された状態に照らしてユーザへの問い合せの迷惑を考慮に入れる（例えば、ユーザが睡眠状態である場合、ユーザへの迷惑度が高い）。別の例において、ユーザが動作を手動で実行するのを待つことに対応する出力操作タイプに関連するスケーリングおよび／または調整値を決定する際に、この出力操作タイプに関連するスケーリングおよび／または調整値は、動作を手動で実行するためにユーザが必要とする労力を考慮に入れる（例えば、ユーザが物理的に物理スイッチの近くにいて、いつもどおりに手動でスイッチを作動させる場合、労力は少ない）。
【０１０８】
別の例において、動作を実行する前に警告をユーザへ通知することに対応する関連する出力操作タイプに関連するスケーリングおよび／または調整値を決定する際に、この出力候補の関連スケーリングおよび／または調整値は、動作の深刻性（例えば、夜にベッドルームのカーテンを開けるなどの非常に重大な動作は、入力状態が高い信頼度で決定されえない限りは自動的に実行されるべきではない）、および、以前に選択された出力（例えば、ユーザが、動作を実行するか否かについての応答を提供することを求めた以前の要求に応答しなかった場合、警告後にその動作が実行される可能性が高い）を考慮に入れる。
【０１０９】
別の例において、ユーザインタラクティブな認定を受けずに動作を実行することに関連する出力操作タイプのスケーリングおよび／または調整値を決定する際に、この出力操作タイプの関連スケーリングおよび／または調整値は、ユーザが以前に動作の実行の希望を示唆したか否かを考慮に入れる。例えば、ユーザが、ユーザの快適さ／満足度を高める任意の動作を実行するという希望を示唆する場合があり（例えば、ユーザは、「私を幸せにして」という音声コマンドを提供する）、システムがユーザの満足度を高めるための動作を実行するというユーザの認識および希望を前提として、認定なしに（例えば、警告もユーザ確認要求もなしに）動作が実行される可能性が高い。
【０１１０】
いくつかの実施形態において、評価に向けて選択される制御可能ネットワークデバイスのプロパティのさらなる候補構成設定が存在するか否かが判定される。例えば、評価される候補構成設定のリストから、評価される次の候補構成設定が存在するか否かが判定される。評価に向けて選択されるさらなる候補構成設定が存在すると判定された場合、処理は、工程６０２に戻る。
【０１１１】
工程６０８で、最適化関数を用いて、実施される選択候補構成設定および出力操作タイプが選択される。
【０１１２】
いくつかの実施形態において、利用される最適化関数は、予め決定される。いくつかの実施形態において、利用される最適化関数は、１または複数の要因（例えば、制御されるプロパティ、入力状態、ユーザ嗜好など）に基づいて複数の最適化関数の中から選択される。いくつかの実施形態において、最適化関数を用いる工程は、最適化関数を用いて、候補構成設定および出力操作タイプの各々に対する総評価値（例えば、期待値）を比較して、最適な総評価値を選択する工程を含む。例えば、最適化関数は、コスト最適化関数であり、決定された総評価値の各々は、コスト値を表し、選択された候補構成設定は、最低コスト値を持つ候補構成設定である。最適化関数の他の例は、特に、最大化関数、リスク関数、価値関数、確率関数、および、決定関数を含む。いくつかの実施形態において、最適化関数は、最大の出力候補最適化評価値を持つ候補構成設定および出力操作タイプが選択されることを規定する。いくつかの実施形態において、最適化関数は、極小／極大の出力候補最適化評価値を持つ候補構成設定および出力操作タイプが選択されることを規定する。様々な実施形態において、最適化関数を用いる工程は、最適化関数によって定義された基準を用いて、決定された総評価値の中から統計的に関連する値を特定する工程と、出力操作タイプのとおりに制御可能デバイス上で実施される設定として、対応する選択された候補構成設定および出力操作タイプを特定する工程と、を含む。
【０１１３】
いくつかの実施形態において、選択された潜在的な構成設定および出力操作タイプは、図５の工程５０８での実施のために提供され、処理は図５の工程５１０に戻る。いくつかの実施形態において、選択された候補構成設定は、選択された候補構成設定が、自動制御される制御可能デバイスプロパティの現在の構成設定とは異なる構成設定を示す場合にのみ、制御可能デバイスに提供される。
【０１１４】
図６の処理の一実例において、制御可能なネットワーク接続デバイスモータによって電動化されたリビングルームのカーテンを自動的に開けるか否かを決定するために、カーテン開設定およびカーテン閉設定の候補構成設定が別個に評価される。受信された入力状態は、ユーザがリビングルームにいる機会が７０％（例えば、リビングルーム状態の機会が７０％）であり、ユーザがベッドルームにいる機会が３０％（例えば、ベッドルーム状態の機会が３０％）であることを示す。カーテン開設定が評価される時、リビングルーム状態に対する成分評価値「−１」およびベッドルームに対する成分評価値−１１を組み合わせて、複合評価値「−４」（例えば、（．７）×（−１）＋（．３）×（−１１））が決定される。リビングルーム状態について、３つの異なる出力操作タイプの各々に対してこの複合評価値「−４」をスケーリングおよび／または調整すると、出力操作タイプ１に対する総評価値「−１０」、出力操作タイプ２に対する総評価値「−５」、および、出力操作タイプ３に対する総評価値「−１」が特定される。ベッドルーム状態について、３つの異なる出力操作タイプの各々に対して複合評価値「−４」をスケーリングおよび／または調整すると、出力操作タイプ１に対する総評価値「−２０」、出力操作タイプ２に対する総評価値「−２０」、および、出力操作タイプ３に対する総評価値「−２０」が特定される。異なる状態に対する総評価値を組み合わせた後、出力操作タイプ１に対する複合総評価値「−１３」（例えば、（．７）（−１０）＋（．３）（−２０）））、出力操作タイプ２に対する複合総評価値「−９．５」例えば、（．７）（−５）＋（．３）（−２０））、および、出力操作タイプ３に対する「−６．７」（例えば、（．７）（−１）＋（．３）（−２０））が、カーテン開設定についての結果として得られる。カーテン閉設定に同様の処理を適用すると、出力操作タイプ１に対する複合総評価値例「−２１」、出力操作タイプ２に対する複合総評価値例「−１２」、および、出力操作タイプ３に対する複合総評価値例「−１０」が、カーテン閉設定についての結果として得られる。利用されるコスト最適化関数は、最低の総評価値を持つ構成設定候補が選択されることを規定しており、出力操作タイプ３でのカーテン開設定（すなわち、−６．７が最低値）が、最低の総評価値を持つので、実施される選択出力候補として選択される。
【０１１５】
図７は、選択された出力を実施するための処理の一実施形態を示すフローチャートである。図７の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図７の処理の少なくとも一部は、図５の工程５０８に含まれる。
【０１１６】
工程７０２で、選択された出力が受信される。いくつかの実施形態において、選択された出力は、図５の工程５０６で選択された出力候補である。
【０１１７】
工程７０４で、選択された出力の出力操作タイプが、ユーザインタラクティブな認定を受けずに動作を実行することに対応するか否かが判定される。例えば、出力操作タイプが、ユーザ警告を提供することも動作実行についてのユーザ確認を求めることもなしに動作を実行することに対応するか否かが判定される。工程７０４で、選択された出力の出力操作タイプが、ユーザインタラクティブな認定を受けずに動作を実行することに対応すると判定された場合、工程７１０で、妥当な場合には動作が実行される。
【０１１８】
例えば、工程７１０で、選択された出力候補の制御可能デバイス構成設定が、制御可能デバイスのプロパティの対応する現在の設定からの変更である場合、動作は、選択された出力候補の指定されたデバイス構成設定へ変更するように制御可能デバイスへ命令を提供することによって実行される。いくつかの実施形態において、動作は、制御可能デバイスの永続的なプロパティ状態とは関連せず、動作は、常に工程７１０で実行される。動作を実行する工程は、１または複数のセンサデバイスを用いて得られた情報に基づいて、遠隔ユーザへ警告／通知を送信する工程を含む。いくつかの実施形態において、動作を実行する工程は、或る期間にわたって段階的に徐々に動作を実行する工程を含む。例えば、動作が、新たな目標強度レベルにスピーカのボリューム強度を変更することである場合、スピーカのボリューム強度は、新たな目標強度レベルに向かって時間を掛けて徐々に変更される。動作を徐々に実行する間に、動作の徐々の実行を停止／一時停止するための指示が、ユーザから受信されてよい。例えば、ユーザは、ユーザの望むレベルで、音量の徐々の増大中にボリューム変更を停止／一時停止するよう指示する。動作の徐々の実行を停止／一時停止するための指示が受信されると、動作は停止／一時停止され、停止指示の時点での現在の設定が維持される。いくつかの実施形態において、動作を元に戻すための指示が受信されると、動作は保留される（例えば、以前のデバイス構成設定に戻すように制御可能デバイスに命令を提供する）。
【０１１９】
工程７０４で、選択された出力の出力操作タイプが、ユーザインタラクティブな認定を受けずに動作を実行することに対応しないと判定された場合、工程７０６で、選択された出力の出力操作タイプが、動作が実行される旨の警告表示を提供することに対応するか否かが判定される。工程７０６で、選択された出力の出力操作タイプが、動作が実行される旨の警告表示を提供することに対応すると判定された場合、工程７１２で、警告表示が提供される。例えば、警告表示は、動作が実行される旨の示唆をユーザに提供する。
【０１２０】
警告表示は、インタラクティブな視覚的警告（例えば、警告灯の点灯、光の点滅、光強度の変更、光の色の変更、電子ディスプレイ警告など）、聴覚的警告（例えば、スピーカを介した音声警告、音声トーン、音声／音量強度の変更など）、警告メッセージ（例えば、電子メール、テキストメッセージ、チャットメッセージ、アプリケーション通知など）、バイブレーション警告、機械的警告（例えば、モータの作動、ブラインドの開閉など）、および、任意の他のタイプの警告通知、を含んでよい。いくつかの実施形態において、警告通知は、動作の実行に近づくにつれて時間と共に強度（例えば、光の強度、色、ボリューム、メッセージの深刻さ、など）を徐々に増してもよい。いくつかの実施形態において、警告表示を提供する工程は、動作を徐々にまたは部分的に実行する工程を含む。例えば、動作が、新たな目標強度レベルに電球の光強度を変更することである場合、電球の光強度は、新たな目標強度レベルに向かって部分的に変更される。別の例において、動作が、電動式カーテンを完全に開くことである場合、カーテンは、カーテンが完全に開く旨の示唆を提供するために少し開かれる。いくつかの実施形態において、警告表示は、動作が実行される時を示す時間値を提供する。例えば、他の指示が無い限りは３分で自動的に光を点灯する旨のメッセージが、ユーザに提供される。
【０１２１】
工程７１４で、取り消し指示が待機期間中に受信されたか否かが判定される。例えば、待機期間が経過した後、処理は工程７１０に進む。待機時間中、ユーザは、動作の実行を取り消しまたは停止するための指示を提供できる。取り消し指示は、音声コマンド、（例えば、カメラによって検出される）動きジェスチャ、物理的スイッチの作動、コンピュータ入力、アプリケーション入力、デジタルメッセージ、および、任意のその他のユーザ入力を介して提供されてよい。取り消し指示が工程７１４で受信された場合、工程７２０で、動作を実行しないことが決定される。取り消し指示が工程７１４で受信されなかった場合、処理は工程７１０へ進む。いくつかの実施形態において、工程７１２で警告表示を提供する工程が、動作を徐々にまたは部分的に実行する工程を含む場合、受信された取り消し指示は、徐々にまたは部分的に実行された動作を取り消すことを指示してよい。取り消し指示が、徐々にまたは部分的に実行された動作を取り消すことを指示する場合、工程７２０で、徐々にまたは部分的に実行された動作は保留される（例えば、以前のデバイス構成設定に戻すように制御可能デバイスに命令を提供する）。いくつかの実施形態では、取り消し指示が工程７１４で受信されなくても、動作の完了前に、徐々に実行されている動作の実行を停止するための指示が受信される。動作の徐々の実行を停止するための指示が待機期間の終了前に受信された場合（例えば、待機期間は、動作の徐々の実行を完了するのに必要な時間である）、動作の徐々の実行は一時停止され、指示の点での現在の制御可能デバイス設定が工程７１０で維持される。
【０１２２】
工程７０６で、選択された出力の出力操作タイプが、動作が実行される旨の警告表示を提供することに対応しないと判定された場合、工程７０８で、選択された出力の出力操作タイプが、動作を実行するか否かをユーザに問い合わせることに対応するか否かが判定される。工程７０８で、選択された出力の出力操作タイプが、動作を実行するか否かを問い合わせることに対応すると判定された場合、工程７１６で、動作を実行するか否かを問い合わせるために、ユーザインタラクティブな問い合せがユーザに送信される。問い合わせは、視覚的問い合わせ（例えば、光の点灯、光の点滅、光の色の変更、電子ディスプレイ上での問い合わせなど）、聴覚的問い合わせ（例えば、スピーカを介した音声での質問、音声トーンなど）、問い合わせメッセージ（例えば、電子メール、テキストメッセージ、チャットメッセージ、アプリケーション通知など）、バイブレーション問い合わせ、および、任意のその他のタイプのユーザ問い合わせを介して送信されてよい。いくつかの実施形態において、問い合わせは、ユーザが応答を提供しない場合には、時間と共に強度（例えば、光の強度、色、ボリューム、メッセージの深刻さ、など）を徐々に増してもよい。
【０１２３】
工程７１６の後、工程７１８で、動作を実行する肯定的な示唆が受信されたか否かが判定される。ユーザは、音声コマンド、（例えば、カメラによって検出される）動きジェスチャ、物理的スイッチの作動、コンピュータ入力、アプリケーション入力、および、任意のその他のユーザ入力を介して、肯定的な示唆を提供してよい。工程７１８で、肯定的な示唆が受信された場合、処理は工程７１０に進む。工程７１８で、肯定的な示唆が受信されなかった場合（例えば、指定された期間内に、否定的な示唆があったか、または、指示がなかった場合）、処理は工程７２０に進む。
【０１２４】
工程７０８で、選択された出力の出力操作タイプが、動作を実行するか否かを問い合わせることに対応しないと判定された場合、工程７０９で、選択された出力の出力操作タイプが、ユーザが動作を手動で実行するのを待つことに対応するか否かが判定される。工程７０９で、選択された出力の出力操作タイプが、ユーザが動作を手動で実行するのを待つことに対応すると判定された場合、処理は工程７２０に進む。いくつかの実施形態において、工程７０９で、選択された出力の出力操作タイプが、ユーザが動作を手動で実行するのを待つことに対応すると判定された場合、処理は、ユーザが動作を手動で実行することを許容するために指定の期間待機し、ユーザが指定の期間内に動作を実行しなかった場合、処理は、工程７１０、工程７１２、または、工程７１６に進んでよい（図示せず）。４つのタイプの出力操作タイプが図７に示されているが、さらなるまたはその他の出力操作タイプが、様々な他の実施形態で存在してもよい。例えば、工程７０９で、選択された出力の出力操作タイプが、ユーザが動作を手動で実行するのを待つことに対応しないと判定された場合、他の出力操作タイプを特定するために、他のテストが実行されてもよい。
【０１２５】
いくつかの実施形態において、図７の工程のいずれかで受信されるユーザ応答の１または複数の態様は、制御可能デバイスの自動的制御に利用される。例えば、ユーザ応答の１または複数の態様（例えば、応答のトーン、応答において検出されたユーザのいら立ち、音声韻律、応答の内容など）が、図５の工程５０２における入力状態として、図５の工程５０６における選択出力候補の選択において、図６の工程６０８で用いられる最適化関数への入力値として、などに利用される。
【０１２６】
図８は、改善された出力を発見するよう試みる処理の一実施形態を示すフローチャートである。図８の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、図８の処理の少なくとも一部は、図２の工程２０８に含まれる。いくつかの実施形態において、図８の処理の少なくとも一部は、図５の工程５０６に含まれる。いくつかの実施形態において、図８の処理の少なくとも一部は、図６の工程６０８に含まれる。いくつかの実施形態において、図８の処理の少なくとも一部は、制御可能デバイスを制御するための出力が自動的に決定される度に繰り返される。
【０１２７】
工程８０２で、テスト出力を出力する機会閾値が特定される。例えば、（例えば、図５および／または図６の処理を用いて）最適化関数を利用して最も最適な出力を選択する場合、選択出力は、出力候補の決定された候補最適化評価値に基づいて選択される。しかしながら、候補最適化評価値が出力候補の望ましさを正確に捉えていない場合、選択出力候補は準最適でありうる。結果および入力に対応する最適化評価値は、フィードバックに基づいて調整および改善されうるが（例えば、ユーザが準最適な設定を最適な設定に手動で変更し、機械学習を用いて、この変更から学習する）、ユーザは、出力が最適でなくても満足であれば、出力結果を改善するために有効なフィードバックを提供しなくてもよい。例えば、最適なファン速度設定が低速であっても、ユーザは、現在の異なるファン設定（例えば、高速）が満足であれば、この最適な速度を示すためのフィードバックを提供しなくてよい。
【０１２８】
いくつかの実施形態において、より最適な出力（例えば、制御可能デバイスの出力構成設定）を発見するために、最適化に従って最も最適ではないかもしれない出力が、潜在的により最適な出力を発見するために、限られた例で出力として提供される。例えば、最適化関数によって選択された最も最適な出力を用いるのではなく、ランダムな出力および／または２番目に最適な出力が、この出力が潜在的により最適な出力であるか否かを判断するために、出力として提供される。いくつかの実施形態において、機会閾値は、最も最適な出力として選択されなかった出力が出力として提供される目標確率を特定する。いくつかの実施形態において、機会閾値は、動的に決定される。例えば、機会閾値を動的に変化させることにより、ベータテスタは、最も最適ではないかもしれないより多くのテスト出力にさらされうるが、信頼性を求める商用ユーザは、最も最適ではなないかもしれない比較的少ないテスト出力にさらされる。別の例では、最も最適ではないかもしれない連続的なテスト出力にユーザを絶えずさらすのではなく、時間間隔内に提供されるテスト出力の数が、学習選択機会閾値を変化させることによって制限される。
【０１２９】
いくつかの実施形態において、機会閾値を特定する工程は、以下の内の１または複数に少なくとも部分的に基づいて、機会閾値を動的に選択する工程を含む：１または複数の入力状態（例えば、図５の工程５０２で受信されるもの）、最後のテスト出力からの時間、ユーザのプロフィール、最後のテスト出力の正確さの結果／フィードバック、現在の時刻／日付、および、制御されるプロパティおよび／または制御可能デバイスのタイプ、など。
【０１３０】
工程８０４で、特定された機会閾値に基づいた選択基準が満たされたか否かが判定される。例えば、機会閾値を用いて評価されたランダム化選択基準に基づいて、最適化関数で選択された出力ではないテスト出力が出力されるべきか否かが判定される。いくつかの実施形態において、テスト出力が提供されるべきか否かを判定するために、ランダム値が選択され、ランダム値が機会閾値の限界によって境界された範囲内にあるか否かが判定される。（例えば、ランダム値が機会閾値未満である場合、機会閾値は満たされ、そうでない場合には満たされない）。
【０１３１】
工程８０４で、選択基準が満たされなかったと判定された場合、工程８０６で、最適化関数を用いて最適であると選択された選択出力が出力される。例えば、（例えば、図５の工程５０６、図６の工程６０８などで）最適化関数によって最適であると選択された出力が、制御可能デバイスを制御するための出力として提供される。
【０１３２】
工程８０４で、選択基準が満たされたと判定された場合、工程８０８で、テスト出力が出力される。例えば、特定された（例えば、図６の工程６０２で特定された）潜在的な出力候補（例えば、制御される制御可能デバイスのプロパティの候補構成設定）の中から、出力候補の１つがランダムに選択されて出力される。出力されるようランダムに選択される資格のある出力候補は、最適化関数を用いて実行される解析に基づいて制限されてよい。例えば、最適化関数によってランク付けされた出力候補の上位５０％のみが、テスト出力としての出力に向けて選択される資格がある。別の例では、最適化関数に基づいて決定された２番目に最適な出力が、テスト出力として提供される。
【０１３３】
工程８１０で、出力に関するフィードバックが受信される。例えば、出力の結果、制御可能デバイスのプロパティの望ましくない構成設定が生じた場合、ユーザは、構成設定を明確に変更することによって特にその構成設定を置き換えてもよい（例えば、デバイスの制御スイッチを調整してよい）。いくつかの実施形態において、ユーザは、出力構成設定が所望の構成設定であるか否かをユーザ指示を介して確認してよい。例えば、ユーザデバイスを用いて、ユーザは、最近の出力が結果としてユーザの望む自動化挙動につながったか否かを明確化してよい（例えば、最適化成分値が指示に基づいて変更される）。いくつかの実施形態において、ユーザによる行動がなければ、望ましくない出力ではなかったという確認フィードバックになる。例えば、同じ入力状態を前提として、ユーザが、より長くおよび／またはより頻繁に、フィードバックの提供も構成設定の変更もしていないほど、入力状態と出力との間の関係性が、ユーザによって受け入れられていると想定される。
【０１３４】
工程８１２で、受信されたフィードバックに少なくとも部分的に基づいて、妥当な場合、１または複数の参照最適化評価値が更新される。例えば、入力状態と特定の出力（例えば、制御可能デバイスの構成設定）との間の関連性を特定する１または複数の参照値（例えば、将来の評価のために参照される値）が、受信されたフィードバックを用いて更新される。例えば、出力が望ましかったというユーザからの肯定的な示唆があれば、関連する最適化評価値を下げ、出力が望ましくなかったというユーザからの否定的な示唆があれば、関連する最適化評価値を上げる。
【０１３５】
図９Ａ〜図９Ｄは、階層的な配備環境グラフモデルの様々なレベルの例を示す図である。例えば、グラフモデルは、ルール発見および実施ならびにデバイス制御に用いるために、図１Ａのハブ１０４および／またはサーバ１０６に格納される。いくつかの実施形態において、配備環境のグラフモデルは、グラフデータフォーマット内でのデバイス／センサおよび物理環境ならびにそれらの接続のモデルである。デバイス／センサおよび物理環境の位置は、グラフモデル内でノードとして表され、ノード間の接続はエッジとして表される。グラフモデル内のデバイスノードは、必ずしも「スマート」デバイスまたはネットワーク「接続」デバイスまたは「ＩｏＴ」デバイスである必要はない。例えば、通常の「スマートでない」電球が、グラフモデル内に表された部屋／環境の照明に影響するので、グラフモデル内でノードとして表される。グラフモデル内での他のノードが、この電球を感知および／または制御できてもよい。例えば、電球ノードは、電球の状態を感知できるモデル内の別のデバイスノード（例えば、光センサノード）、および／または、電球を制御する（例えば、スマートネットワーク接続照明スイッチ）モデル内の別のデバイスノードに接続されてよい。例のグラフモデルは、階層的であり、１つのレベルのノードが、高いレベルのノードのプロパティを継承する１または複数のノードおよびエッジを表しうる。エッジは、複数のレベルにわたって、異なる階層レベル／グルーピングのノードの間に存在しうる。各エッジは、ノードに関する記述、構成、設定、ＩＤ、および／または、任意のその他のプロパティをそれぞれ特定する１または複数のプロパティに関連付けられてよい。各エッジは、エッジによって接続されたノードの間の関係性を特定する１または複数のプロパティに関連付けられてよい。例えば、物理的な位置／プロパティ（例えば、物理的接続タイプのエッジ）、機能的プロパティ（例えば、機能的接続タイプのエッジ）、行動プロパティ（例えば、行動活動接続タイプのエッジ）、および／または、任意の他の関係プロパティを特定する関係性が、エッジのプロパティとして特定される。図９Ａ〜図９Ｄに示したグラフモデルレベルは、例にすぎず、例を明確に図示するために単純化されている。すべてのノードおよびエッジが示されているわけではなく、さらなるノードおよびエッジが存在してもよい。ノードプロパティは、照明、温度、湿度、地理的位置（例えば、住居の部屋／エリア）、寸法、振動、圧力、位置、太陽光の方向、デバイスの位置、音のレベルなどの物理的プロパティを含んでもよい。例えば、カーテンノードの機能的プロパティは、カーテンを開ける機能であり（そして、照明および熱に影響する）、その環境への影響は、その機能に対する照明および温度の関係性を特定するグラフ内のエッジを通してモデル化される。
【０１３６】
エッジは、ノードの間の関係性を規定しうる。物理的および機能的エッジプロパティは、２つの位置ノードの間の照明の関係性（例えば、或るエリアの照明が隣室の照明に影響する）、２つのノードの間の温度の関係性（例えば、或るエリアの温度変化が隣のエリアの温度変化に影響し、間に断熱壁があれば、影響は小さくなる）、地理的位置の間の関係性（例えば、住居のレイアウトであり、リビングルームはダイニングルームから歩いて行けるが、廊下ノードを通過する必要があるのでバスルームには直接行けない）、音の関係性（例えば、或るエリアでの音楽または音声が、他のエリアの音に影響する）、２つのデバイスの間の関係性（例えば、１つのスイッチが３つの電球を制御しうるか、または、位置ノードが２つのカメラから見える）、などを含みうる。例えば、カーテン（デバイスノード）が開かれると、その照明効果が、屋外環境を表すノードから入る光から、リビングルームの光レベルの変化を特定する光プロパティエッジによってモデル化される。行動エッジプロパティは、活動に関連しうる（例えば、人物が、ダイニングルームで作業している場合があるが、そのエリアの「利用」は、隣接するリビングルームを含む）。例えば、人物が、料理中である場合があり、キッチンおよびダイニングルームは、料理活動のために接続している。別の例において、子どもの携帯電話が、親のベッドルームに対する機能的影響を全く持たず、権限のある所有者だけが、特定の位置のカメラ映像にアクセスできる。
【０１３７】
図９Ａは、接続デバイス環境の階層グラフモデルの区域レベルの一例を示す図である。グラフモデルに示すように、ノードは、位置／物理的建物を示すだけでなく、共有リソースと、デバイスの内、そのレベルの位置／建物によって共有されたデバイスと、を表しうる。グラフモデルレベル９０２は、或る区域の建物を表すノード９０６および９０８を示す。ノード９０４は、建物の区域のための自動ゲートを表しており、ノード９１０は、その区域のためのデバイス自動化を管理するサーバ（例えば、図１Ａのサーバ１０６）を表す。建物ノード９０６は、建物の物理的位置座標、建物の地理的向き、建物に含まれるユニットの数、建物に関連して実行できる活動、建物の高さ、建物の容積など、を記述するプロパティに関連付けられてよい。グラフモデルレベル９０２に示されたノード間の接続（すなわち、エッジ）は、ノード間の物理的位置の接続／関係性を表す。例えば、ノード間のエッジが、物理的な通路、位置のつながり、および／または、ワイヤの接続、の存在を表しうる。各エッジは、１または複数のプロパティに関連付けられてよい。例えば、エッジは、強度、距離、および／または、接続ノード間の距離／位置に関連する時刻値を特定するプロパティ値に関連付けられてよい。グラフ９０２は、物理的接続タイプのエッジだけを示しているが、図示されていない他のタイプのエッジが、他の図の例によって示されるように存在しうる。例えば、機能タイプのエッジが、ノード間の機能的接続（例えば、ネットワーク接続）を特定する（例えば、グラフモデルは、建物間／サーバ間で検出された接続速度を特定し、グラフモデルは、ノード間の最速のネットワークパスを特定するために利用されてよい）。別の例において、行動タイプのエッジが、特定のタイプの行動活動のために存在する接続を特定する（例えば、人々、活動、所有、許可、プライバシなどに基づいた接続）。グラフモデルレベル９０２は、階層グラフモデルの１つのレベルを示しており、階層グラフモデルのより高いレベルが存在しうる。例えば、グラフモデルレベル９０２は、グラフモデルのより高いレベルにおいて接続された複数の区域ノードの内の１つの区域ノードを表す。
【０１３８】
図９Ｂは、接続デバイス環境の階層グラフモデルの建物レベルの一例を示す図である。図９Ｂに示すグラフモデルレベル９１２は、図９Ａに示したレベルより低いレベルを表す。具体的には、レベル９１２は、図９Ａの建物９０６のサブノードおよびエッジを表す。ノード９１４、９１６、９１８、および、９２０は、図９Ａの建物９０６のアパートメントユニットを表す。建物のこれらのアパートメントすべてのためのデバイス管理サーバは、ノード９２２によって表されている。グラフモデルレベル９１２に示されたノード間の接続は、ノード間の物理的位置の接続／関係性を表す。グラフレベル９１２は、物理的接続タイプのエッジだけを示しているが、図示されていない他のタイプのエッジが存在しうる。
【０１３９】
図９Ｃは、接続デバイス環境の階層グラフモデルのユニットレベルの一例を示す図である。図９Ｃに示すグラフモデルレベル９２４は、図９Ｂに示したグラフレベルより低いレベルを表す。具体的には、レベル９２４は、図９Ｂのアパートメント９１８のサブノードを表す。ノードは、建物、ユニット、および、デバイスを表しうるだけでなく、物理的な部屋および物理的な領域も表しうる。アパートメントユニット内の場所は、ノード９２６〜９３６によって表される。給湯器ノード９２５は、ユニットの給湯器デバイスを表す。グラフモデルレベル９２４に示されたノード間の接続は、ノード間の物理的位置の接続／関係性を表す。グラフレベル９２４は、物理的接続タイプのエッジを実線の接続として示す。また、グラフレベル９２４は、行動タイプのエッジの例をノード間の点線の接続として示す。キッチン９２６とダイニングルーム９３０との間の点線は、特定の行動活動のための部屋／領域の間の行動的接続を表す。この行動エッジは、食事活動のために、キッチンとダイニングルームとの間のプライバシが、値０．５の中程度のプライバシ設定に設定されることが好ましいと特定するプロパティに関連付けられている。このプライバシプロパティ値は、食事活動が行われていることが検出された時に、中間レベルのプライバシを維持するように関連デバイスを調節するために利用されてよい。
【０１４０】
リビングルーム９３４とベッドルーム９３６との間の点線は、部屋／エリアの間の行動上の接続を表す。この行動エッジは、勉強活動のために、リビングルームとベッドルームとの間のプライバシが、値１．０の高いプライバシ設定に設定されることが好ましいと特定するプロパティに関連付けられている。このプライバシプロパティ値は、勉強活動が行われていることが検出された時に、部屋の間で高いレベルのプライバシを維持する（例えば、雑音を最小限に抑える）ように関連デバイスを調節するために利用されてよい。行動エッジは、人物および／または動物／ペットの活動に関連してよい。
【０１４１】
図９Ｄは、接続デバイス環境の階層グラフモデルの部屋レベルの一例を示す図である。図９Ｄに示すグラフモデルレベル９４０は、図９Ｃに示したグラフレベルより低いレベルを表す。具体的には、グラフレベル９４０は、図９Ｃのキッチン９２６のサブノードを表す。ノードは、デバイスおよびユニットパーティションを表しうるだけでなく、領域のサブ領域も表しうる。ノードであるキッチンエリア９５０は、全体的なキッチンの場所／領域を表す。キッチンアイランド領域９５２およびカウンタ領域９５４は、キッチンエリア９５０のサブ領域を表す。カウンタ領域９５４は、さらに、サブ領域であるシンク領域９５６およびコンロ領域９５８に分割される。シンク領域に固有の照明が、スイッチ９６４によって制御される照明９６０によって表される。コンロ領域に固有のファンが、スイッチ９６６によって制御されるファン９６２によって表される。キッチンのカメラが、カメラ９４２によって表される。キッチンのマイクおよびスピーカが、モジュール９４４によって表される。キッチンのモーションセンサが、モーションセンサ９４６によって表される。キッチンのブラインド制御デバイスが、ノード９４８によって表される。
【０１４２】
グラフモデルレベル９４０に示すノード間の実線のエッジ接続は、ノード間の物理位置の接続／関係性を表す。例えば、カメラ９４２は、キッチンエリアの領域に設置／取り付けされるためにキッチンエリア９５０に接続される。グラフモデルレベル９４０のノード間の点線のエッジ接続は、接続されたノード間の機能的な接続／関係性を表す。例えば、カメラ９４２とキッチンアイランド領域９５２との間の機能的エッジは、カメラの画像キャプチャ機能が少なくともキッチンアイランド領域９５２の画像をキャプチャできることを特定する。このエッジに関連するプロパティは、カメラによってキャプチャできるキッチンアイランド領域の正確な部分を特定してよい。さらに、照明９６０と、キッチンアイランド領域９５２、シンク領域９５６、および、コンロ領域９５８との間の点線のエッジ接続は、照明の発光機能が、接続された領域に到達することを特定する。これらの機能的エッジの各々は、各接続領域に到達する光の強度の測定値を特定するプロパティに関連付けられる。シンク領域９５６への機能的エッジは、強い発光を示すプロパティ強度値「１．０」を有すると特定され、コンロ領域９５８への機能的エッジは、中程度の発光を示すプロパティ強度値「０．５」を有すると特定され、キッチンアイランド領域９５２への機能的エッジは、低い発光を示すプロパティ強度値「０．２」を有すると特定される。機能的エッジの別の例は、ノード間のオーディオ／音声の関係性を含む。
【０１４３】
図１０は、接続デバイス環境のグラフモデルを初期化するための処理の一実施形態を示すフローチャートである。図１０の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、グラフモデルは、図１Ａのハブ１０４および／またはサーバ１０６に格納されたグラフモデルである。いくつかの実施形態において、グラフモデルの一例は、図９Ａ〜図９Ｄのグラフモデルである。
【０１４４】
工程１００２で、グラフモデルが初期化される。いくつかの実施形態において、グラフモデルを初期化する工程は、接続デバイス環境が確立されるためのグラフモデルを確立する工程を含む。例えば、ユーザは、グラフモデルを構築するために、環境内のデバイス／センサならびにそれらの位置および接続を指定する。いくつかの実施形態において、グラフモデルを初期化する工程は、グラフモデルの仕様を受信する工程を含む。例えば、ソフトウェアを用いて、ユーザは、環境内の領域および接続デバイスを含む環境の構成を指定する。
【０１４５】
グラフモデルは、異なる設置環境および異なる住居にわたって様々であってよい。しかしながら、機械学習を用いて、或る設置環境から別の設置環境へグラフの少なくとも一部を適用してもよい。例えば、或る住居からの学習が別の住居に移植されうるように、グラフモデル内のパターンが見出され、様々な設置環境に適用されてよい。換言すると、機械学習は、グラフモデルの類似の部分にわたる行動／プロセスを特定するために利用され、結果として、異なる設置環境およびグラフモデルにわたる共通ルールを生成する。
【０１４６】
いくつかの実施形態において、１または複数のテンプレートが、グラフモデルの初期化に利用される。例えば、ユーザは、予め構築されたグラフモデルテンプレートを提供され、ユーザは、グラフモデルの少なくとも一部を指定するのに必要に応じて、テンプレートを調整して組み合わせることができる。いくつかの実施形態において、ネットワーク接続デバイスは、非常に類似したおよび／または同じ環境にわたって配備される。例えば、複数の建物／アパートメントユニットが、同じレイアウトに基づく場合があり、一人の設置者が、各ユニットに同じように繰り返し設置するネットワーク接続デバイスおよびセンサのタイプおよび具体的な設置位置を決定したとする。設計が標準化されているので、グラフモデルテンプレートが、同じ／類似のユニットに対して生成されて、すべての同じ／類似のユニットに適用されてよい。別の例では、環境部分（例えば、部屋、領域など）のためのグラフモデルテンプレートが、配備環境のためのグラフモデルの構築に利用可能であってもよい。グラフモデルテンプレートは、各配備例に対してカスタマイズ可能であってよい。例えば、グラフモデルテンプレートを用いる際に、テンプレートの要素が、各ユニットの偏差／ばらつきを考慮するように修正／指定されてよい。
【０１４７】
いくつかの実施形態において、グラフモデルを初期化する工程は、グラフモデル内の代表ノードに個々の物理デバイスを関連付ける工程を含む。例えば、テンプレートグラフモデルは、テンプレートグラフモデル内にデバイス／センサのためのプレースホルダを含むが、デバイス／センサノードは、現実世界に配備／設置されたデバイス／センサとは特に関連付けられておらず、ユーザ／設置者は、これらのプレースホルダに対して個々の現実世界のデバイス／センサの識別子を指定してよい。ネットワーク接続デバイスが類似した複数のユニットにわたって配備される例において、設置者は、ユニットのためのグラフモデルテンプレートに基づいて、各ユニット内に物理センサ／デバイスを設置してよい。いくつかの実施形態において、グラフモデルテンプレートに基づいて、物理センサ／デバイスは、自動的にグラフモデルテンプレート内のノードに関連付けられる。例えば、各センサ／デバイスは、センサ／デバイスの対応するグラフモデルノードを決定するために、他のセンサ／デバイスと共に、１または複数のテストを実行する。一例において、グラフモデルテンプレートに２つの電球デバイスノードが存在し、２つのネットワーク接続電球が環境内に設置されている場合、どの物理的電球がグラフモデルテンプレート内のどの電球ノードに対応するのかを決定する必要がある。この例において、一方の電球がオンにされ、一方で、他方の電球がオフにされている特に、配備環境内のセンサからのフィードバックデータを用いて、オンになった電球の位置およびそれに対応するノードを推定し、オフになった電球のノードを消去法で特定する。
【０１４８】
いくつかの実施形態において、グラフモデルのノードおよび／またはエッジのプロパティが、ユニットの位置および／または向きに基づいて変えられる。例えば、建物の３階のアパートメントユニットが、１階のユニットに比べて異なるプライバシの懸案事項を有しており、窓装飾デバイスノードおよび／またはノードを接続するエッジに関連するプライバシプロパティ設定値が、環境の位置および／または向きに基づいて変更される。別の例では、窓を通して入る日光および／または雑音の量が、窓の方向／向きに基づいて変化しうるので、窓装飾デバイスおよび／またはそのエッジに関連するプロパティ設定値が、関連する窓の位置および／または向きに基づいて変更される。
【０１４９】
工程１００４で、グラフモデルが検証される。例えば、正確なグラフモデルが配備環境に対して初期化されたことを保証するために、自動テストが実行される（例えば、閉ループ検証）。いくつかの実施形態において、自動検証は、１または複数のテストを実行することによって実行される（例えば、各物理デバイス／センサがグラフモデル内の正確な対応ノードに関連付けられていることを保証するためのテスト）。例えば、各制御可能デバイス／センサについて、１または複数の制御可能プロパティが有効化され、それらの効果がセンサを用いて検出され、検出された効果がグラフモデルに従って期待された通りであるか否かが判定される。一例において、環境に影響するデバイス（例えば、音、光など）がオンにされるよう命令されると、グラフモデルに従って（例えば、対応するノードの間のエッジに従って）その効果を検出できるはずのセンサが、グラフモデルが正確であれば効果を検出するはずである。いくつかの実施形態において、ユーザ／設置者は、１または複数の動作を実行するよう（例えば、特定の経路を歩く、スイッチをオンにする、など）命令され、環境のセンサ用いて、検出されたデータがグラフモデルにフィットすることが検証される。エラーが検出された場合、そのエラーは、自動的に修正されてよい（例えば、２つのノードの間のスイッチデバイスの関連性）、および／または、ユーザ／設置者がエラーを修正することを可能にするために、エラーメッセージが提供されてよい。
【０１５０】
いくつかの実施形態において、グラフモデルを用いて、１または複数のデバイス／センサが定期的に検証される。例えば、センサ／デバイスが、使用中に故障する場合があり、センサ／デバイスの正確な機能は、グラフモデルを用いて、テストされるデバイス／センサについて、どの他のデバイス／センサが、テスト対象のデバイス／センサを検出／影響することができるのかを特定し、これらのデバイス／センサがテスト対象のデバイス／センサの機能の正確な動作を検出できることを検証することにより、定期的に検証される。いくつかの実施形態において、定期的な検証が、メンテナンスの問題を検出するために利用される。例えば、特定の共通したメンテナンスの問題のための検証テストが、グラフモデルに基づいて定期的に実行されてよい。
【０１５１】
いくつかの実施形態において、グラフモデルを用いることにより、最も効率的なセンサ／デバイス配置位置、および／または、所望の有効範囲を提供するのに必要な任意の追加センサ／デバイスの位置が特定されてよい。例えば、環境内で有効化されることが望まれるルールおよび／または機能の所望のセットに基づいて、グラフモデルは、グラフモデル（これにプロパティが関連付けられている）内でさらなるノードをどこに配置できるのか、どこでノードを取り除くことができるのか、および／または、エッジのどのプロパティ値を変更（例えば、質を向上）できるのか、を特定するために解析されてよい。次いで、解析の結果は、所望の有効範囲を達成するために物理環境内で利用されてよい。
【０１５２】
図１１は、グラフモデルを用いてコマンドを処理するための処理の一実施形態を示すフローチャートである。図１１の処理は、少なくとも部分的には、図１Ａのハブ１０４および／またはサーバ１０６で実施されてよい。いくつかの実施形態において、グラフモデルは、図１Ａのハブ１０４および／またはサーバ１０６に格納されたグラフモデルである。いくつかの実施形態において、グラフモデルの一例は、図９Ａ〜図９Ｄのグラフモデルである。いくつかの実施形態において、図１１の処理の少なくとも一部は、図２〜図３の工程２０４、２０６、２０８、３１４、３１６、および／または、３１８、図４の工程４０４、図５の工程５０２および／または５０４、図６の工程６０４、ならびに／もしくは、図１０の工程１００４に含まれる。
【０１５３】
工程１１０２で、コマンドが受信される。いくつかの実施形態において、コマンドは、ユーザコマンドである。例えば、ユーザが、スイッチを作動させるか、または、命令を提供する。ユーザコマンドは、マイクによって検出される音声コマンドであってよい。いくつかの実施形態において、コマンドは、自動化コマンドである（例えば、事前設定または自動決定されたルールに基づいて呼び出される）。いくつかの実施形態において、コマンドは検出される。例えば、センサが、トリガされている。いくつかの実施形態において、コマンドは、明示的なユーザコマンドではない。例えば、コマンドは、センサが検出した環境プロパティに基づいて自動的に呼び出される。いくつかの実施形態において、コマンドは、ルールの呼び出しである。いくつかの実施形態において、コマンドは、新しいルールの発見である。いくつかの実施形態において、コマンドは、デバイス／センサの状況をテストするためのテストコマンドである。
【０１５４】
工程１１０４で、環境のグラフモデルが、コマンドに関連するグラフモデルのノードを特定するために適用される。例えば、グラフモデルは、デバイス／センサ間および物理的領域間の関係性を規定し、この関係性情報は、関連するデバイス／センサおよびそれらのコマンドに関係する関係性を特定するために利用される。いくつかの実施形態において、特定されるノードは、グラフモデルのすべてのノードの一部である。いくつかの実施形態において、ノードを特定する工程は、コマンドに直接関連するノード（例えば、コマンドによって指定されたデバイスに対応するノード）を特定する工程と、その後に、コマンド関連の関係性で特定されたノードに接続されたノードを決定する工程と、を含む。例えば、ガレージのドアを開くコマンドが受信されると、ガレージドアオープナに対応するノードがグラフモデル内で特定され、次いで、コマンド関係の関係性でガレージドアオープナノードに接続された他のノードが特定される（例えば、関連する照明をオンにするために、ガレージドアオープナのガレージ領域を照らすことができるすべての照明関連ノードを特定する）。いくつかの実施形態において、グラフモデルは階層的であり、コマンドは、グラフ階層の１または複数のレベルに関連しうる。例えば、低いレベルのノード／エッジは、直接対応するより高いレベルのノードからプロパティを継承する。
【０１５５】
いくつかの実施形態において、ノードを特定する工程は、コマンドの物理的なエリア／領域に関連付けられたノードを特定する工程を含む。例えば、コマンドは、物理的なエリア／領域に関連付けられており（例えば、キッチンの照明をオンにするコマンド）、物理的なエリア／領域に関連付けられたグラフモデルのノードが特定される。次いで、物理的なエリア／領域に接続され、コマンドに関連付けられた他のノードが、他のノードと物理的なエリア／領域とのグラフモデルエッジ接続に基づいて特定されうる。物理的なエリア／領域は、コマンド内で直接指定されてよい、および／または、推定されてよい（例えば、コマンドを提供したユーザの位置）。物理的なエリア／領域は、部屋、部屋の中の位置、ユニット、建物、屋外の位置、サブ領域、特定の物品の周りの位置、および／または、任意のその他の特定可能な位置であってよい。
【０１５６】
いくつかの実施形態において、グラフのコンテキスト情報を用いることにより、グラフのコンテキスト情報がない場合よりも、汎用的かつ直感的なコマンドを利用することができる。例えば、特定のデバイス名およびデバイスの構成をユーザが知っている必要があるのではなく、ユーザは、グラフモデルの位置および／または関係性の概念に関連するコマンドを提供することができる。特定された位置／関係性に基づいて、適用可能なデバイス／ノードを自動的に決定することができる。さらに、コンテキスト情報は、より汎用的かつコンテキストアウェアなルールを自動的に発見することを可能にする。例えば、グラフモデルの位置コンテキスト情報がなければ、ルールの発見／利用時に利用される状態入力は、孤立して存在する。しかしながら、グラフモデルの位置コンテキスト情報があれば、一般化されたエリア／領域のためのルールを発見／利用するために、コンテキスト情報に基づいて、（例えば、特定のデバイスのためだけではなく、より広い領域／エリアに）入力状態を一般化することができる、より汎用的なルールを発見、呼び出し、および／または、利用することを可能にすることにより、ルールは、より多くの状況および位置で適用可能になる。例えば、特定のユーザに固有であるが、より広いエリア／領域に一般化されたルールが、その特定のユーザが、異なるグラフモデルを有するが同じラベルを付されたエリア／領域を持つ異なる環境に移動することから、異なる環境で適用されてよい（例えば、異なるキッチンで、実際の照明デバイスおよびそれらの構成が異なっていても、夜にユーザがキッチンエリアに入った時に照明を点灯するルールが、ユーザの行くすべてのキッチンに適用されてよい）。いくつかの実施形態において、グラフモデルを用いてより広い概念に動作を一般化する（例えば、より広い位置コンテキストに一般化する）ことを可能にすることにより、ルールの発見が、（例えば、同じユーザおよび／または異なるユーザによる）様々な異なるタイプの配備環境にわたって行われうる。
【０１５７】
いくつかの実施形態において、グラフモデルは、ノード間の物理的関係性を特定するエッジ（例えば、ノード間の接続）を含んでおり、これらのエッジは、ノードを特定する際に利用される。例えば、ノード（例えば、デバイス／センサ、位置エリアなど）の間の物理的位置／関係性を特定するこれらのタイプのエッジおよび任意の関連プロパティ（例えば、強度値）が、コマンドの処理に利用される。デバイス／センサの位置および互いの物理的関係性は、コマンドの処理に関連するノードを特定するため、および／または、ノードの情報を処理する際に物理的コンテキストを提供するために利用されてよい。例えば、互いに既知のそれぞれの位置を所与として複数のセンサのカメラおよび／またはマイクデータを処理することによってイベントの位置を特定するために、位置の三角測量が実行される。別の例において、位置情報は、影響を受けるすべての特定のデバイスの正確な知識（例えば、特定の領域内のすべての照明をオンにするためのコマンド）を求めることなしに、グラフモデル内で特定された物理的関係に基づいて、物理的に同じ場所にあるデバイス／センサの共同管理を可能にする。いくつかの実施形態において、センサ配置の位置情報は、センサで検出された動きが人間のユーザまたはペットのいずれに関連しているのかを判定するために利用される。例えば、地面近くに取り付けられたセンサは、人間およびペットの動きを検出しうるが、地面近くの動きを検出しないように高く取り付けられたセンサは、ペットの動きを検出する可能性が低い。
【０１５８】
いくつかの実施形態において、ノードの物理的な関係性は、野外環境のコンテキストを提供する。例えば、グラフモデルは、屋外の天気、時刻／日付、および／または、太陽の位置の間の関係性を捉える。一例において、窓の位置／配置／向き、および、少なくとも部分的にグラフモデルを用いて得られた太陽位置情報に基づいて、窓に入る太陽光の期待量が決定され、窓付近のサーモスタットが室内温度を正確に測定しているのか、または、サーモスタットに当たる直射日光によって異常な影響を受けているのかを判定するために利用される。複数の温度センサが存在する場合、正確である可能性の最も高いセンサが、利用されるよう選択されてよい。別の例では、バスルームの換気扇が、グラフモデルを用いて、（例えば、ユーザの入浴により）バスルームでのみ高い湿度が検出されているのか、または、アパートメントユニット全体の湿度が高いのか（例えば、グラフモデルを用いて決定されたようにバスルームから十分に離れた場所にあるセンサで検出される）を検出することによって、バスルームの湿度を効率的に制御でき、バスルームの換気扇は、バスルームセンサと遠隔センサとの間で十分な湿度の差が検出された時にのみオンにされる。
【０１５９】
いくつかの実施形態において、グラフモデルは、ノード間の機能的関係性を特定するエッジを含んでおり、これらのエッジは、ノードを特定する際に利用される。例えば、ノード間の機能的関係性を特定するこれらのタイプのエッジおよび任意の関連プロパティ（例えば、機能識別および接続の強度値）は、コマンドの処理に利用される。機能的関係性の例は、光および音の関係性を含む。例えば、別のノードに影響するノードによって出力／制御される光および／またはノイズの量が、関連する強度値を持つエッジ接続として表される。一例において、ユーザが部屋を暗くするためのコマンドを提供すると、ユーザの位置が決定され、光の関係性を特定する機能的エッジを持つ位置に接続されたノードすべてが特定され、光出力を下げるよう命令される。
【０１６０】
いくつかの実施形態において、グラフモデルは、ノード間の行動的関係性を特定するエッジを含んでおり、これらのエッジは、ノードを特定する際に利用される。例えば、ノード間の行動活動の関係性を特定するこれらのタイプのエッジおよび任意の関連プロパティ（例えば、行動活動の識別、活動の関連プロパティ、および、接続の強度値）は、コマンドの処理に利用される。行動活動の関係性の例は、人および／または動物／ペットの活動／行動（例えば、人間ユーザの活動、所有、許可、プライバシなど）に関連する関係性を含む。例えば、各行動的関係性タイプのエッジは、指定された活動（例えば、仕事、食事、学習、ＴＶ視聴、入浴など）に固有であり、各行動的関係性タイプのエッジは、指定された活動にのみ適用可能である。異なるコンテキストおよび行動活動が、異なるデバイス設定につながりうる。例えば、読書活動は、光の明るい設定を引き起こすが、睡眠活動は、明るさの低い設定を引き起こしうる。
【０１６１】
いくつかの実施形態において、コマンドに関連する活動が決定され、コマンドに関連するグラフモデルのノードを特定する工程は、決定された活動のためのエッジを特定する工程を含む。例えば、ユーザが睡眠中であることが検出され、睡眠活動に関連するプライバシ／照明エッジが特定され、それに従って、グラフモデル内でユーザの位置に接続された特定されたエッジに基づいてデバイスを調整するために利用される。別の例では、１または複数の行動エッジが、１または複数の特定のユーザおよび／またはユーザのタイプに関連付けられており、権限のあるユーザおよび／または権限のあるタイプのユーザがコマンドを提供したか否かおよび／または検出されたか否かに基づいて、機能の有効化／無効化を可能にする。
【０１６２】
工程１１０６で、特定されたノードは、コマンドに応答して作動される。例えば、コマンドの所望の結果が、適切な特定されたノードの１または複数の特徴を有効化／無効化する（例えば、状態を変更する）ことによって達成される。いくつかの実施形態において、ノードを作動させる工程は、特定されたノードの内の１または複数のノードのデバイス／センサをオン／オフする工程を含む。いくつかの実施形態において、ノードを作動させる工程は、特定されたノードの１または複数の状態を決定する工程を含む。例えば、状態は、１または複数のルールを学習および／または有効化するために利用できる。いくつかの実施形態において、ノードを作動させる工程は、１または複数のデバイス設定を変更する工程を含む。いくつかの実施形態において、ノードを作動させる工程は、特定されたノードの１または複数の関連エッジおよび／またはノードを決定する工程を含む。いくつかの実施形態において、ノードを作動させる工程は、センサデータを評価する工程を含む。いくつかの実施形態において、ノードを作動させる工程は、特定されたノードに基づいてグラフモデルを変更する工程を含む。例えば、ノードおよび／またはエッジの１または複数のプロパティが変更されてもよいし、１または複数のノード／エッジがグラフモデルに追加または除去されてよい。いくつかの実施形態において、ノードを作動させる工程は、各ノードがどのようにコマンドと関連しているか、および、各ノードが、該当する場合に、コマンドを処理するためにどのように呼び出されるべきか、を決定する工程と、適切なノードを呼び出す工程と、を含む。いくつかの実施形態において、ノードを作動させる工程は、コマンドおよび特定されたノードに関連する１または複数のルールを特定する工程と、特定されたルールを呼び出す工程と、を含む。
【０１６３】
上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
本発明は、たとえば、以下のような態様で実現することもできる。
適用例１：
デバイスコントローラシステムであって、
センサ情報を受信するよう構成された通信インターフェースと、
前記通信インターフェースと接続されたプロセッサであって、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、前記デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することに対する期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を潜在的に実行することに対する期待値と比べて評価し、
前記動作を自動的に実行する前記期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定し、
承認示唆を特定し、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信するよう構成された、プロセッサと、
を備える、システム。
適用例２：
適用例１のシステムであって、前記動作を実行することは、前記デバイスのプロパティを、前記動作に関連する特定の構成に変更することを含む、システム。
適用例３：
適用例１のシステムであって、前記センサ情報を用いて検出された前記少なくとも１つの状態は、ユーザについての状態情報および環境についての状態情報を含む複数の状態の一部であり、前記複数の状態は、前記動作を自動的に実行することに対する前記期待値を決定するために用いられる、システム。
適用例４：
適用例１のシステムであって、前記センサ情報を用いて検出された前記少なくとも１つの状態は、前記動作を自動的に実行することに対する前記期待値を決定する際に用いられる前記少なくとも１つの状態の信頼度に関連し、前記信頼度は、前記動作を自動的に実行することに対する前記期待値を決定するために用いられる、システム。
適用例５：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値は、グラフモデルに基づいての利用のために選択された環境状態に基づいて決定されたものである、システム。
適用例６：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値は、機械学習を用いて自動的に決定された自動化ルールを用いて決定されたものである、システム。
適用例７：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値は、少なくとも部分的には、前記受信されたセンサ情報を用いて検出された異なる状態に各々関連する成分期待値を組み合わせることによって決定されたものである、システム。
適用例８：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値を評価することは、前記動作を自動的に実行することに対する前記期待値を、前記動作を潜在的に実行することに対する前記期待値と比較することを含む、システム。
適用例９：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値を評価することは、コスト最小化関数を利用することを含む、システム。
適用例１０：
適用例１のシステムであって、前記ユーザインタラクティブな認定は、前記動作が実行されるべきであることを承認する前記承認示唆に関連する、システム。
適用例１１：
適用例１のシステムであって、前記ユーザインタラクティブな認定は、前記動作の実行を取り消すことを命令する指示に関連する、システム。
適用例１２：
適用例１のシステムであって、前記承認示唆は、前記動作が実行されるべきか否かについての問い合わせに応答してユーザから受信したものである、システム。
適用例１３：
適用例１のシステムであって、前記承認示唆は、前記動作が実行される旨の警告に応答して取り消しユーザ指示を受信していないことに関連する、システム。
適用例１４：
適用例１のシステムであって、前記承認示唆は、前記動作に固有ではない汎用のユーザ示唆に関連する、システム。
適用例１５：
適用例１のシステムであって、前記プロセッサは、さらに、ユーザが前記動作を手動で実行する可能性があると判定して、前記ユーザが前記動作を実行するのを待つことに対する期待値を評価するよう構成される、システム。
適用例１６：
適用例１のシステムであって、前記動作を潜在的に実行することに対する前記期待値は、ユーザへ問い合せを送信する負のコストを考慮する、システム。
適用例１７：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値は、時間と共に値が減衰する成分を含む、システム。
適用例１８：
適用例１のシステムであって、前記センサ情報は、カメラまたはマイクからの情報を含む、システム。
適用例１９：
適用例１のシステムであって、前記動作は、指定された将来の時点に前記デバイスによって実行されるか、または、複数の時点に繰り返される、システム。
適用例２０：
適用例１のシステムであって、前記動作は、前記動作が完全に実行されることの示唆を提供するために、部分的に実行される、システム。
適用例２１：
適用例１のシステムであって、前記デバイスは、或る期間にわたって段階的に徐々に前記動作を実行し、前記期間の終了前に前記動作を一時停止するためのユーザ指示が受信された場合、前記動作の前記徐々の実行は一時停止され、前記動作を元に戻すためのユーザ指示が受信された場合、前記動作は保留される、システム。
適用例２２：
適用例１のシステムであって、前記動作が実行される旨の警告表示がユーザに提供され、前記警告表示は、視覚的警告、聴覚的警告、警告メッセージ、バイブレーション警告、または、機械的警告の内の１または複数を提供することを含む、システム。
適用例２３：
適用例１のシステムであって、前記動作を自動的に実行することに対する前記期待値は、少なくとも部分的には、ユーザへ示された問い合わせに応答して以前に受信されたユーザ応答に基づいて決定されたものである、システム。
適用例２４：
方法であって、
センサ情報を受信する工程と、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することに対する期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を潜在的に実行することに対する期待値と比べて評価する工程と、
前記動作を自動的に実行する前記期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定する工程と、
承認示唆を特定する工程と、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信する工程と、
を備える、方法。
適用例２５：
コンピュータプログラム製品であって、前記コンピュータプログラム製品は、持続性のコンピュータ読み取り可能な記憶媒体内に具現化され、
センサ情報を受信するためのコンピュータ命令と、
前記センサ情報を用いて検出された少なくとも１つの状態に少なくとも部分的に基づいて、デバイスコントローラシステムによって制御されるデバイスに関連する動作を自動的に実行することに対する期待値を、ユーザインタラクティブな認定を受けて、前記デバイスコントローラシステムによって制御される前記デバイスに関連する前記動作を潜在的に実行することに対する期待値と比べて評価するためのコンピュータ命令と、
前記動作を自動的に実行する前記期待値が、前記ユーザインタラクティブな認定を受けずに前記動作を自動的に実行することをトリガするのに不十分であると判定するためのコンピュータ命令と、
承認示唆を特定するためのコンピュータ命令と、
前記承認示唆に少なくとも部分的に基づいて、前記動作を実行するための命令を前記デバイスに送信するためのコンピュータ命令と、
を備える、コンピュータプログラム製品。
【図１Ａ】
0006858260.tif 000002
【図１Ｂ】
0006858260.tif 000003
【図１Ｃ】
0006858260.tif 000004
【図２】
0006858260.tif 000005
【図３】
0006858260.tif 000006
【図４】
0006858260.tif 000007
【図５】
0006858260.tif 000008
【図６】
0006858260.tif 000009
【図７】
0006858260.tif 000010
【図８】
0006858260.tif 000011
【図９Ａ】
0006858260.tif 000012
【図９Ｂ】
0006858260.tif 000013
【図９Ｃ】
0006858260.tif 000014
【図９Ｄ】
0006858260.tif 000015
【図１０】
0006858260.tif 000016
【図１１】
0006858260.tif 000017