JP2017063268A - 調停方法、調停装置及び調停プログラム - Google Patents

Abstract

【課題】第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができる調停方法、調停装置及び調停プログラムを提供する。
【解決手段】調停装置１０３は、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求に基づく第１の機器１０４の制御を許可する機器制御部３０３と、第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する状態監視部３０２４と、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かを判定する実行判定部３０２１とを備え、機器制御部３０３は、空間の状態が第１のサービスが満たすべき状態にないと判定された場合、第１のサービスとは異なる第２のサービスを第１の機器１０４に実行させるための第２の制御要求を受け付けない。
【選択図】図３

Description

本開示は、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停方法、調停装置及び調停プログラムに関するものである。

ネットワークを通じて、コントローラにインストールされたアプリケーションから宅内の家電機器などを遠隔制御する技術がある。アプリケーションは、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）及び音声対話などの入力手段を用いてユーザの操作に基づき機器を制御するサービスと、特定のルール（例えば玄関が開いたら照明機器を点灯する等）に基づき自動的に機器を制御するサービスとを実行する。このような様々なサービスが実行される場合、同一機器に対し、異なるサービスを実行させるための互いに競合する複数の制御要求が発行されることがある。ここで、制御要求が競合するとは、同一機器が同時又は短時間の間に１又は複数の端末装置から制御されることを意味する。競合が発生すると、各サービスが正しく実行されず、ユーザが混乱するおそれがある。

このような問題は、制御要求の競合発生時にいずれか一方のサービスに対応する制御要求のみを実行することで解決できる。例えば、特許文献１では、省エネ制御から通常制御に切り替えられた後、所定時間が経過すると、強制的に通常制御が終了し、省エネ制御に切り替えられる技術が記載されている。

また、例えば、特許文献２には、機器に対する操作命令を実行するか否かを決定する技術が開示されている。特許文献２では、宅外からの遠隔制御時に、制御対象機器の運転状態と操作命令の内容とに応じて操作命令を実行するか否かを決定している。

特開２０１３−２６８０号公報 特開２０１４−２０２４１８号公報

しかしながら、従来の制御装置では、機器制御の内容、及び機器が配置された空間の環境の変化に応じてサービスが実行可能であるか否かの判断が行われていないため、更なる改善が必要とされている。

本開示に係る調停方法は、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停装置における調停方法であって、前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可し、前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得し、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定し、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない。

本開示によれば、第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができ、競合する第１の制御要求と第２の制御要求とを調停することができる。

本開示の実施の形態１における機器制御システムの構成を模式的に示す図である。 本開示の実施の形態１における調停装置のハードウェア構成の一例を示す図である。 本開示の実施の形態１における調停装置の詳細な構成の一例を示す図である。 本開示の実施の形態１における調停管理テーブルの一例を示す図である。 本開示の実施の形態１における調停管理テーブルの他の例を示す図である。 本開示の実施の形態１における状態監視テーブルの一例を示す図である。 調停装置によるサービスの実行手順の一例を説明するためのフローチャートである。 サービスの属性を定義するマニフェストの構成の一例を示す図である。 マニフェスト内の終了条件の一例を示す図である。 終了条件のないマニフェストの構成の一例を示す図である。 機器がサービスを実行したときの調停装置の処理の流れを説明するための第１のフローチャートである。 機器がサービスを実行したときの調停装置の処理の流れを説明するための第２のフローチャートである。 図１１のステップＳ１２の割込み判定処理について説明するためのフローチャートである。 図１２のステップＳ１８の競合判定処理について説明するためのフローチャートである。 図１２のステップＳ２０の依存関係設定処理について説明するためのフローチャートである。 図１２のステップＳ２１の状態監視テーブル更新処理について説明するためのフローチャートである。 本開示の実施の形態１における機器ＩＤと機器種別とを対応付けた対応表の一例を示す図である。 図１６のステップＳ６４の監視対象設定処理について説明するためのフローチャートである。 状態監視部で実行するサービス監視処理について説明するためのフローチャートである。 実行判定部で実行するサービス監視処理について説明するためのフローチャートである。 図１９のステップＳ９２の目標値判定処理について説明するためのフローチャートである。 機器制御の終了をユーザに確認するための通知画面の一例を示す図である。 機器制御の切り替えをユーザに確認するための通知画面の一例を示す図である。 本開示の実施の形態２におけるマニフェスト内の終了条件の一例を示す図である。 本開示の実施の形態２における状態監視テーブルの一例を示す図である。 本開示の実施の形態２における機器のＩＤと機器種別と設置場所とを対応付けた対応表の一例を示す図である。 本開示の実施の形態２における状態監視テーブル更新処理について説明するためのフローチャートである。 図２７のステップＳ１２９の監視プロパティ値取得処理について説明するためのフローチャートである。 本開示の実施の形態２における目標値判定処理について説明するためのフローチャートである。 本開示の実施の形態３における調停装置の詳細な構成の一例を示す図である。 本開示の実施の形態３における第１の調停装置及び第２の調停装置による調停処理の動作を説明するためのフローチャートである。

（本開示の基礎となった知見）
近年、ネットワークに接続された家電機器を遠隔制御するサービス、及び複数の家電機器同士を連携して動作させるサービスが検討されている。このようなサービスの数が増加すると、それぞれの制御が互いに競合することで各サービスが正しく実行されず、ユーザが混乱することが考えられる。このような課題は、例えば事前に各サービスに優先度を付与し、優先度の高いサービスが機器を占有しているとみなし、競合発生時に優先度の高いサービスのみを実行するようにすることで解決できる。しかしながら、優先度の高いサービスによる機器の占有をいつまで継続するのが適切かは明確ではない。

例えば、夜になると照明機器を点灯するサービスが実行される場合、日が暮れてからユーザが就寝するまでの間、又は日が暮れてから夜が明けるまでの間は照明機器の点灯状態が維持される、すなわち、サービスによる照明機器の占有を継続するのが適当であると考えるのが自然である。一方、リモコンによりエアコンの温度設定を下げるサービスが実行される場合、室温が十分に低下する、又はリモコンを操作する人の体温が十分低下するまでは温度設定サービスを維持することが適切と考えるのが自然である。このように、サービスによる機器の占有期間は、機器制御の目的、又は機器制御によって引き起こされる空間内の環境の変化等に依存すると考えられる。

特許文献１では、後続サービスが実行された後、所定の間後続サービスが機器を占有するが、機器制御の目的、又は空間内の環境の変化に応じて機器を制御することができない。

また、特許文献２では、被制御機器の運転状態及び操作命令の内容に応じて操作命令（後続サービス）を実行するか否かを決定するが、操作命令は、遠隔地からのエアコン電源のＯＮ制御に限定されており、様々なサービスに適用することが難しい。

このような課題を解決するため、本開示の一態様に係る調停方法は、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停装置における調停方法であって、前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可し、前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得し、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定し、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない。

この構成によれば、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求が受け付けられ、第１の制御要求に基づく第１の機器の制御が許可される。第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報が取得される。空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが判定される。空間の状態が第１のサービスが満たすべき状態にないと判定された場合、第１のサービスとは異なる第２のサービスを第１の機器に実行させるための第２の制御要求が受け付けられない。

これにより、第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができ、競合する第１の制御要求と第２の制御要求とを調停することができる。

また、上記の調停方法において、前記空間の状態が前記第１のサービスが満たすべき状態にあると判定された場合、前記第２の制御要求を受け付け、前記第２の制御要求に基づく第１の機器の制御を許可してもよい。

この構成によれば、空間の状態が第１のサービスが満たすべき状態にあると判定された場合、第２の制御要求が受け付けられる。そして、第２の制御要求に基づく第１の機器の制御が許可される。これにより、第１のサービスから第２のサービスに切り替えることができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の機器から取得されてもよい。これにより、第１のサービスが実行される第１の機器の状態に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の機器とは異なる第２の機器から取得されてもよい。これにより、第１のサービスが実行される第１の機器とは異なる第２の機器の状態に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の制御要求に含まれる、前記第１の機器を制御するための制御対象項目と同じ種類の情報であってもよい。これにより、第１のサービスが実行される第１の機器を制御するための制御対象項目で示される状態の変化に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の制御要求に含まれる、前記第１の機器を制御するための制御対象項目とは異なる種類の情報であってもよい。これにより、第１のサービスが実行される第１の機器を制御するための制御対象項目で示される状態とは異なる状態の変化に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、前記空間の現在の状態を示す数値を含み、前記空間の状態が前記第１のサービスが満たすべき状態にあることを示す目標値の範囲に、前記数値が含まれるか否かを判定し、前記目標値の範囲に前記数値が含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、空間の現在の状態を示す数値が目標値の範囲に含まれるか否かを判定することによって、第１のサービスが第１の機器を占有する期間を容易に指定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の制御要求に基づいて前記第１の機器の制御が開始されてから現在までの間における前記空間の状態の変化量を示す数値を含み、前記空間の状態が前記第１のサービスが満たすべき状態にあることを示す目標値の範囲に、前記数値が含まれるか否かを判定し、前記目標値の範囲に前記数値が含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、第１の機器の制御が開始されてから現在までの間における空間の状態の変化量を示す数値が、目標値の範囲に含まれるか否かを判定することによって、第１のサービスが第１の機器を占有する期間を容易に指定することができる。

また、上記の調停方法において、前記空間推定情報は、複数の機器の状態を示す情報であり、前記複数の機器のそれぞれから取得した前記空間推定情報のいずれもが所定の条件を満たすか否かを判定し、前記空間推定情報のいずれもが所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、複数の機器の全ての状態に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、複数の機器の状態を示す情報であり、前記複数の機器それぞれから取得した前記空間推定情報の少なくとも１つが所定の条件を満たすか否かを判定し、前記空間推定情報の少なくとも１つが所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、複数の機器の少なくとも１つの状態に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、複数の機器の状態を示す数値であり、前記複数の機器それぞれから取得した前記数値の平均値が所定の条件を満たすか否かを判定し、前記数値の平均値が所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、複数の機器の状態を示す数値の平均値に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記複数の機器は、同一の閉じた空間に設置されていてもよい。これにより、複数の機器が存在する空間内の環境に応じて、第１のサービスが第１の機器を占有する期間を設定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の制御要求に基づいて前記第１の機器の制御が開始されてから現在までの経過時間であり、前記経過時間が所定の範囲に含まれるか否かを判定し、前記経過時間が所定の範囲に含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、第１の機器の制御が開始されてから現在までの経過時間に応じて、第１のサービスが第１の機器を占有する期間を判定することができる。

また、上記の調停方法において、前記空間推定情報は、前記第１の制御要求に基づいて制御を開始した前記第１の機器の状態が所定の状態に達してから現在までの経過時間であり、前記経過時間が所定の範囲に含まれるか否かを判定し、前記経過時間が所定の範囲に含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定されてもよい。

これにより、制御を開始した第１の機器の状態が所定の状態に達してから現在までの経過時間に応じて、第１のサービスが第１の機器を占有する期間を判定することができる。

また、上記の調停方法において、前記第１のサービスの内容を定義するサービス定義情報は、前記第１のサービスが満たすべき前記空間の状態を定義する条件定義情報を含み、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、前記サービス定義情報に含まれる前記条件定義情報を用いて判定してもよい。

これにより、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが、サービス定義情報に含まれる条件定義情報を用いて判定されるので、第１のサービスが第１の機器を占有する期間をサービス提供者が設定することができる。

また、上記の調停方法において、前記第１の制御要求は、前記第１のサービスが満たすべき状態を定義する条件定義情報を含み、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、前記第１の制御要求から取得した前記条件定義情報を用いて判定してもよい。

これにより、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが、第１の制御要求から取得した条件定義情報を用いて判定されるので、第１のサービスが第１の機器を占有する期間を、第１のサービスの実行を開始するごとに設定することができる。

また、上記の調停方法において、前記第１のサービスが満たすべき状態を定義する条件定義情報のユーザによる入力を受け付け、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、受け付けられた前記条件定義情報を用いて判定してもよい。

これにより、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが、ユーザによって入力された条件定義情報を用いて判定されるので、第１のサービスが第１の機器を占有する期間を、ユーザの嗜好に合わせて設定することができる。

また、本開示の一態様に係る調停装置は、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停装置であって、前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可する制御許可部と、前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する取得部と、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定する判定部と、を備え、前記制御許可部は、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない。

この構成によれば、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求が受け付けられ、第１の制御要求に基づく第１の機器の制御が許可される。第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報が取得される。空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが判定される。空間の状態が第１のサービスが満たすべき状態にないと判定された場合、第１のサービスとは異なる第２のサービスを第１の機器に実行させるための第２の制御要求が受け付けられない。

これにより、第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができ、競合する第１の制御要求と第２の制御要求とを調停することができる。

また、本開示の一態様に係る調停プログラムは、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停プログラムであって、コンピュータを、前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可する制御許可部と、前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する取得部と、前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定する判定部と、を備え、前記制御許可部は、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない。

この構成によれば、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求が受け付けられ、第１の制御要求に基づく第１の機器の制御が許可される。第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報が取得される。空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かが判定される。空間の状態が第１のサービスが満たすべき状態にないと判定された場合、第１のサービスとは異なる第２のサービスを第１の機器に実行させるための第２の制御要求が受け付けられない。

これにより、第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができ、競合する第１の制御要求と第２の制御要求とを調停することができる。

また、本開示は、以上のような特徴的な処理を実行する調停方法として実現することができるだけでなく、調停方法に含まれる特徴的なステップを実行するための処理部を備える調停装置などとして実現することもできる。また、このような調停方法に含まれる特徴的な各ステップをコンピュータに実行させるコンピュータプログラムとして実現することもできる。そして、そのようなコンピュータプログラムを、ＣＤ−ＲＯＭ等のコンピュータ読取可能な非一時的な記録媒体又はインターネット等の通信ネットワークを介して流通させることも可能である。

なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、構成要素、ステップ、及びステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また、全ての実施の形態において、各々の内容を組み合わせることもできる。

（実施の形態１）
まず、本開示の実施の形態における機器制御の全体構成について説明する。

図１は、本開示の実施の形態１における機器制御システムの構成を模式的に示す図である。

図１に示す機器制御システムは、操作端末１０１、調停装置１０３、第１の機器及び第２の機器を備える。

第１の機器１０４及び第２の機器１０５は、例えば、宅内に設置したエアコン、照明機器、冷蔵庫、電子レンジ、クッキングヒータ、電気錠、電動シャッター、人感センサ、温度センサ、湿度センサ、又は空気室センサ等の電子機器である。

操作端末１０１は、ユーザによる操作を受け付け、第１の機器１０４又は第２の機器１０５に対してサービスを実行させるための制御要求を調停装置１０３へ送信する。操作端末１０１は、好適にはスマートフォン、タブレット型コンピュータ、又はパーソナルコンピュータなどの端末である。

調停装置１０３は、操作端末１０１によって送信された制御要求に従って、第１の機器１０４又は第２の機器１０５を制御する。ここで言う制御とは、例えば各種機器の電源のＯＮ／ＯＦＦ、エアコンによる室内温度の変更、又は照明機器による明るさの変更等である。宅内機器の制御は、例えばＥＣＨＯＮＥＴ Ｌｉｔｅ規格等の接続方式に基づいて実現できる。なお、調停装置１０３は、調停装置１０３が第１の機器１０４又は第２の機器１０５の制御を許可してもよい。

また、調停装置１０３は、第１の機器１０４又は第２の機器１０５に対する複数の制御要求が競合した場合に、複数の制御要求を調停する。すなわち、第１の機器１０４又は第２の機器１０５に対し、同時又は短時間の間に互いに異なるサービスを実行する制御要求が送信された場合に、いずれかの制御要求のみを受け付け、残りの制御要求は受け付けない。調停装置１０３は、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する。

通信網１０２は、宅内に設置したローカルエリアネットワークである。操作端末１０１、調停装置１０３、第１の機器１０４及び第２の機器１０５は、通信網１０２を介してそれぞれ通信可能に接続される。なお、通信網１０２は、有線及び無線のいずれであってもよい。通信網１０２を構築するための通信メディアは特に限定されない。また、通信網１０２は、宅内に存在するブロードバンドルータ等を経由してインターネットに接続するなど、より広域な通信網に接続してもよい。

図２は、本開示の実施の形態１における調停装置１０３のハードウェア構成の一例を示す図である。調停装置１０３は、プロセッサ２０１、メモリ２０２、記憶部２０３、入出力部２０４、及び通信部２０５を備える。メモリ２０２は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性記憶装置で実現される。記憶部２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）又はフラッシュメモリ等の不揮発性記憶装置で実現される。調停装置１０３は、通信網１０２を介して操作端末１０１、第１の機器１０４及び第２の機器１０５と接続する。

ここで、図１において、調停装置１０３は、独立した１個の装置として示されている。しかしながら、調停装置１０３は、操作端末１０１、第１の機器１０４、第２の機器１０５、又は宅内に存在するブロードバンドルータ等の他の装置と一体の機器として構成してもよい。

また、図１において、機器制御システムは、１つの調停装置１０３を備えているが、本開示は特にこれに限定されず、複数の調停装置を備えてもよい。また、機器制御システムは、１つの操作端末１０１を備えているが、本開示は特にこれに限定されず、複数の操作端末を備えてもよい。また、機器制御システムは、２つの機器１０４，１０５を備えているが、本開示は特にこれに限定されず、３つ以上の機器を備えてもよい。

次に、本開示の調停装置によるサービス実行制御のより具体的な実施の形態を説明する。

図３は、本開示の実施の形態１における調停装置の詳細な構成の一例を示す図である。調停装置１０３は、サービス実行部３０１、調停部３０２、機器制御部３０３、及びサービス格納部３０４を備える。調停部３０２は、より詳細には、実行判定部３０２１、調停管理テーブル３０２２、状態監視テーブル３０２３、及び状態監視部３０２４を備える。

サービス実行部３０１は、操作端末１０１から受信したユーザ指示に基づく制御要求を実行判定部３０２１に向けて発行する。また、サービス実行部３０１は、制御要求の発行後に、実行判定部３０２１から受信した情報に基づいて操作端末１０１に制御結果を通知する。

実行判定部３０２１は、サービス実行部３０１から受信した制御要求と、状態監視テーブル３０２３及び調停管理テーブル３０２２に格納されている情報とに基づいて、制御要求が示すサービスを実行可能であるか否かを判定する。実行判定部３０２１の詳細な動作については後述する。

調停管理テーブル３０２２は、競合する複数の制御要求を調停するために必要な情報を保持する。

図４は、本開示の実施の形態１における調停管理テーブルの一例を示す図であり、図５は、本開示の実施の形態１における調停管理テーブルの他の例を示す図である。リクエストＩＤ６０１は、サービスによって制御されるすべての機器それぞれに対し付与される一意の識別子である。サービスＩＤ６０２は、サービスに対して付与される一意の識別子である。常駐６０３は、サービスが常駐するか否かを示す情報である。すなわち、常駐６０３が“可”のサービスは、自サービスを実行するための制御と、自サービスとは異なる他サービスを実行するための制御とが競合し、かつ、自サービスの制御権を他サービスに移譲した場合において、移譲先の他サービスが制御権を解放したタイミングで再び制御権を獲得することを示す。

割込み６０４は、サービスが割込みを許可するか否かを示す。すなわち、割込み６０４が“可”のサービスは、自サービスを実行するための制御と、自サービスとは異なる他サービスを実行するための制御とが競合した場合、自サービスの制御権を他サービスに移譲することを示す。

制御対象機器ＩＤ６０５は、制御される機器に関連付けられた一意の識別子を示す。機器占有状態６０６は、制御対象機器ＩＤ６０５に示すそれぞれの機器の制御権を、自サービスが保持しているか否かを示す。機器占有状態６０６が“使用中”であるサービスは、機器の制御権を獲得している状態であることを示す。また、機器占有状態６０６が“未使用”であるサービスは、機器の制御権を獲得した後で解放した状態であることを示す。さらに、機器占有状態６０６が“待ち”であるサービスは、機器の制御権を他サービスに移譲し、他サービスを実行する機器の制御権が解放されるのを待っている状態であることを示す。

依存関係６０７は、自サービスを実行するための制御と、自サービスとは異なる他サービスを実行するための制御とが競合し、かつ、他サービスが制御権を獲得した場合において、元々制御権を保持していた制御要求を特定するためのエントリである。依存関係６０７の値としては、調停管理テーブル３０２２内のリクエストＩＤ６０１が格納される。

以降の説明においては、調停管理テーブル３０２２のエントリは、テーブル内において最も上に位置するエントリが最も古く、新しいエントリは常にテーブルの下に追加されるものとする。調停管理テーブル３０２２の各エントリの詳細については後述する。

続いて、図３における状態監視テーブル３０２３は、サービスが実行され、機器制御の終了時点を判定するために必要な情報を保持する。

図６は、本開示の実施の形態１における状態監視テーブル３０２３の一例を示す図である。機器ＩＤ８０１は、サービスによって制御される対象機器に関連付けられた一意の識別子である。プロパティ８０２は、サービスが実行され、機器制御の終了を判定するために監視する機器状態（制御対象項目）を示す情報である。機器状態は、例えば、室内温度又は室内湿度等である。目標値８０３は、サービスが実行され、機器制御を終了させる基準とするプロパティ８０２の値を示す情報である。リクエストＩＤ８０４は、調停管理テーブル３０２２における同名のエントリと同じ意味を持つ一意の識別子である。状態監視テーブル３０２３の各エントリの詳細については後述する。

状態監視部３０２４は、状態監視テーブル３０２３の内容と、機器制御部３０３から受信した対象機器の状態とに基づいて、機器のサービス実行状態を監視する。なお、状態監視部３０２４の詳細な動作については後述する。

機器制御部３０３は、調停部３０２からの要求に基づいて、第１の機器１０４及び／又は第２の機器１０５に対して制御要求を送信するとともに、第１の機器１０４及び／又は第２の機器１０５からサービス実行状態を受信する。

サービス格納部３０４は、調停装置１０３において動作させるサービス３０４１に関する情報を格納する。

機器制御部３０３は、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求に基づき第１の機器を制御する。なお、機器制御部３０３は、複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、第１の制御要求に基づく第１の機器の制御を許可してもよい。状態監視部３０２４は、第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する。実行判定部３０２１は、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かを判定する。また、機器制御部３０３は、空間の状態が第１のサービスが満たすべき状態にないと判定された場合、第１のサービスとは異なる第２のサービスを第１の機器に実行させるための第２の制御要求を受け付けない。

また、機器制御部３０３は、空間の状態が第１のサービスが満たすべき状態にあると判定された場合、第２の制御要求を受け付ける。そして、機器制御部３０３は、第２の制御要求に基づき第１の機器を制御する。なお、機器制御部３０３は、第２の制御要求に基づく第１の機器の制御を許可してもよい。

空間推定情報は、第１の機器から取得される。また、空間推定情報は、第１の機器とは異なる第２の機器から取得されてもよい。さらに、空間推定情報は、第１の制御要求に含まれる、第１の機器を制御するためのプロパティと同じ種類の情報である。また、空間推定情報は、第１の制御要求に含まれる、第１の機器を制御するためのプロパティとは異なる種類の情報であってもよい。

サービス実行部３０１、調停部３０２、機器制御部３０３及びサービス格納部３０４は、好適には調停装置１０３の記憶部２０３に格納されたソフトウェアプログラム（具体的には、ＨＴＭＬ５又はＪａｖａＳｃｒｉｐｔ（登録商標）などの言語で記述したアプリケーションプログラム）をメモリ２０２に読み出し、読み出したソフトウェアプログラムをプロセッサ２０１で実行することにより実現される。ただしこれは一例であり、調停装置１０３のプロセッサ２０１は、例えば記憶部２０３の代わりに外部のサーバ等に格納したソフトウェアプログラムを、通信部２０５を介して取得してもよい。

続いて、図７を用いて、調停装置１０３によるサービスの実行手順の一例を説明する。

図７は、調停装置１０３によるサービスの実行手順の一例を説明するためのフローチャートである。

まず、ステップＳ１において、サービス実行部３０１は、操作端末１０１へサービス一覧を提示する。サービス一覧は、サービス名及びサービスの説明等、少なくともユーザがサービスを区別することが可能な情報を含む。すなわち、サービス一覧は、調停装置１０３に接続された第１の機器１０４又は第２の機器１０５によって実行可能なサービスの一覧を示す。サービス実行部３０１は、サービス格納部３０４からサービス一覧に関する情報を読み出し、読み出したサービス一覧に関する情報を操作端末１０１へ送信する。操作端末１０１は、調停装置１０３によって送信されたサービス一覧を受信し、受信したサービス一覧を選択可能に表示する。操作端末１０１は、表示されたサービス一覧の中から、ユーザによる所望のサービスの選択を受け付ける。ユーザは、提示されたサービス一覧の中から利用したいサービスを選択する。操作端末１０１は、サービス一覧の中からユーザによって選択されたサービスを特定する情報を調停装置１０３へ送信する。

次に、ステップＳ２において、サービス実行部３０１は、操作端末１０１によって送信されたユーザによって選択されたサービスを特定する情報を受信し、ユーザによって選択されたサービスを特定する。

次に、ステップＳ３において、サービス実行部３０１は、特定されたサービス３０４１をサービス格納部３０４から読み出す。ここで、サービス３０４１は、サービス属性を定義するマニフェスト（定義ファイル）を含む。

図８は、サービスの属性を定義するマニフェストの構成の一例を示す図であり、図９は、マニフェスト内の終了条件の一例を示す図であり、図１０は、終了条件のないマニフェストの構成の一例を示す図である。

マニフェストは、図８に示すように、項目５０１と内容５０２との組で表され、サービスを一意に区別するためのサービスＩＤ５１１、サービスによる機器制御の終了条件を定義する終了条件５１２、常駐するサービスであるか否かを示す常駐５１３、及びサービスが割込み可能であるか否かを示す割込み５１４のエントリから構成される。

ここで、終了条件５１２は、自サービスを実行する機器制御と、自サービスとは異なる他サービスを実行する機器制御とが競合し、かつ、自サービスが制御権を獲得した状況において、制御権を解放する条件である。図９に示すように、終了条件５２１は、エアコン又は照明機器といった制御対象機器の種別を示す制御対象種別５０２Ａ、機器制御の終了条件判定のトリガとなる機器制御の種類を示す制御プロパティ５０２Ｂ、機器制御の終了条件判定時の比較対象とする監視プロパティ５０２Ｃ、条件判定時に基準の値として用いる基準値５０２Ｄ、及び条件判定時の目標値である目標５０２Ｅのエントリから構成される。

例えば、図９における行５１２Ａは、エアコンの温度設定値を変更するサービスが実行された場合に、室内温度が監視され、室内温度の現在値が制御要求時に指定された値の±１℃の範囲に入ると機器制御を終了すると判定されることを意味している。同様に、図９における行５１２Ｂは、エアコンの運転モードを“除湿”に変更するサービスが実行された場合に、室内湿度が監視され、室内湿度の現在値が制御要求時の室内湿度の値を５％下回ると機器制御を終了すると判定されることを意味している。なお、図１０に示すように、終了条件５１２の内容５０２を空欄とすることも可能である。この場合、機器制御が明示的な終了条件を持たないことを意味する。

図７に戻り、サービス格納部３０４からサービス３０４１が読み出された後、ステップＳ４において、サービス実行部３０１は、サービス３０４１に含まれるマニフェストを実行判定部３０２１に通知する。

最後に、ステップＳ５において、実行判定部３０２１は、受信したマニフェストに応じて調停管理テーブル３０２２を更新する。なお、ここでの更新とは、サービスの属性を定義するマニフェストからサービスＩＤ、常駐及び割込みのそれぞれの行が読み出され、調停管理テーブル３０２２の対応する列にそれぞれ格納されることを意味する。図１０及び図４を例に説明すると、図１０のサービスＩＤ５１１が図４のサービスＩＤ６０２に格納され、図１０の常駐５１３が図４の常駐６０３に格納され、図１０の割込み５１４が図４の割込み６０４に格納される。なお、図４におけるその他の列についてはこの時点では操作されないため、説明は後述する。

次に、図１１及び図１２を用いて、機器がサービスを実行したときの調停装置１０３の処理の流れを説明する。図１１は、機器がサービスを実行したときの調停装置の処理の流れを説明するための第１のフローチャートであり、図１２は、機器がサービスを実行したときの調停装置の処理の流れを説明するための第２のフローチャートである。

以下の説明では例として、図８のマニフェストを持つサービスが宅内のエアコン（機器ＩＤ：ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１）において実行され、図１０のマニフェストを持つサービスが宅内のエアコン（機器ＩＤ：ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１）、空気清浄器（機器ＩＤ：ＡｉｒＰｕｒｉｆｉｅｒ１）及び給湯機（機器ＩＤ：ＷａｔｅｒＨｅａｔｅｒ１）の３台の機器において実行されるとして説明する。なお、初期状態ではいずれの機器もサービスを実行しておらず、ユーザは操作端末１０１上で動作するアプリケーションを操作するなどして、図１０のマニフェストを持つサービス（以下、先行サービス）を先に実行させ、その後で図８のマニフェストを持つサービス（以下、後続サービス）を実行させることを想定する。

機器に対して先行サービスを実行させるための制御要求が受信されると、ステップＳ１１において、サービス実行部３０１は、実行判定部３０２１へ当該先行サービスのサービスＩＤ及び制御要求を通知する。ここで、制御要求は、当該先行サービスのすべての制御対象機器の機器ＩＤと、それぞれに対する制御対象のプロパティの情報とを少なくとも含む。すなわち、本実施の形態における先行サービスの場合、制御要求は、エアコン（機器ＩＤ：ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１）、空気清浄器（機器ＩＤ：ＡｉｒＰｕｒｉｆｉｅｒ１）及び給湯機（機器ＩＤ：ＷａｔｅｒＨｅａｔｅｒ１）の機器ＩＤと、それぞれに対する制御対象のプロパティの情報とを含む。また、このように複数の機器に対してサービスが実行される場合、実行判定部３０２１はそれらを逐次的に処理する。

次に、ステップＳ１２において、実行判定部３０２１は、通知された制御要求について割込み可能であるか否かを判定する。ここで、ステップＳ１２の割込み判定処理の詳細について説明する。図１３は、図１１のステップＳ１２の割込み判定処理について説明するためのフローチャートである。

割込み判定処理のステップＳ３１において、実行判定部３０２１は、調停管理テーブル３０２２のすべての行を検査する。

まず、ステップＳ３２において、実行判定部３０２１は、調停管理テーブル３０２２のｉ行目の制御対象機器ＩＤ６０５と、サービス実行部３０１から通知された制御対象機器ＩＤとを比較する。

次に、ステップＳ３３において、実行判定部３０２１は、ｉ行目の制御対象機器ＩＤ６０５と、通知された制御対象機器ＩＤとの両者が一致するか否かを判定する。ここで、両者が一致しないと判定された場合（ステップＳ３３でＮＯ）、実行判定部３０２１は、ステップＳ３１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。

一方、両者が一致すると判定された場合（ステップＳ３３でＹＥＳ）、ステップＳ３４において、実行判定部３０２１は、検査しているｉ行目の割込み６０４が“可”であるか否かを判定する。ここで、ｉ行目の割込み６０４が“可”であると判定された場合（ステップＳ３４でＹＥＳ）、ステップＳ３５において、実行判定部３０２１は、割込み可能であると判定し、処理を終了する。

一方、ｉ行目の割込み６０４が“可”ではないと判定された場合（ステップＳ３４でＮＯ）、ステップＳ３６において、実行判定部３０２１は、割込み不可能であると判定し、処理を終了する。また、調停管理テーブル３０２２のすべての行に対してステップＳ３３の処理で両者が一致しないと判定された場合も、実行判定部３０２１は、割込み可能であると判定し、処理を終了する。

図１１に戻り、ステップＳ１３において、実行判定部３０２１は、割込み判定処理の結果、割込み可能であるか否かを判定する。ここで、割込み不可能であると判定された場合（ステップＳ１３でＮＯ）、ステップＳ１４において、実行判定部３０２１は、サービス実行部３０１へ機器制御失敗を通知する。

次に、ステップＳ１５において、サービス実行部３０１は、操作端末１０１へ機器制御失敗を通知して処理を終了する。

一方、ステップＳ１３において割込み可能であると判定された場合（ステップＳ１３でＹＥＳ）、ステップＳ１６において、実行判定部３０２１は、調停管理テーブル３０２２を検索し、サービスＩＤが一致する行を特定する。

次に、ステップＳ１７において、実行判定部３０２１は、サービスＩＤが一致する行のリクエストＩＤ６０１及び制御対象機器ＩＤ６０５に値を設定する。ここで、リクエストＩＤ６０１に設定する値は、調停管理テーブル３０２２において一意であればその具体的な値の形式は問わない。また、制御対象機器ＩＤ６０５に設定する値は、サービス実行部３０１から通知された制御対象機器ＩＤである。なお、ステップＳ１６で特定した行の制御対象機器ＩＤ６０５のエントリに、すでに他の機器の制御対象機器ＩＤが格納されている場合は、実行判定部３０２１は、調停管理テーブル３０２２に新規の行を追加した上で、サービスＩＤ６０２、常駐６０３及び割込み６０４の内容を新規の行に複製する。そして、実行判定部３０２１は、新規の行のリクエストＩＤ６０１及び制御対象機器ＩＤ６０５に値を設定する。

次に、ステップＳ１８において、実行判定部３０２１は、通知された制御要求について制御要求が競合しているか否かを判定する。ここで、ステップＳ１８の競合判定処理の詳細について説明する。図１４は、図１２のステップＳ１８の競合判定処理について説明するためのフローチャートである。

競合判定処理のステップＳ４１において、実行判定部３０２１は、調停管理テーブル３０２２のすべての行を検査する。

まず、ステップＳ４２において、実行判定部３０２１は、調停管理テーブル３０２２のｉ行目の機器占有状態６０６が“使用中”であるか否かを判定する。ここで、機器占有状態６０６が“使用中”ではないと判定された場合（ステップＳ４２でＮＯ）、実行判定部３０２１は、ステップＳ４１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。

一方、機器占有状態６０６が“使用中”であると判定された場合（ステップＳ４２でＹＥＳ）、ステップＳ４３において、実行判定部３０２１は、検査しているｉ行目の制御対象機器ＩＤ６０５と、サービス実行部３０１から通知された制御対象機器ＩＤを比較する。

次に、ステップＳ４４において、実行判定部３０２１は、ｉ行目の制御対象機器ＩＤ６０５と、通知された制御対象機器ＩＤとの両者が一致するか否かを判定する。ここで、両者が一致しないと判定された場合（ステップＳ４４でＮＯ）、実行判定部３０２１は、ステップＳ４１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。

一方、両者が一致すると判定された場合（ステップＳ４４でＹＥＳ）、ステップＳ４５において、実行判定部３０２１は、制御要求が競合していると判定して処理を終了する。

一方、調停管理テーブル３０２２のすべての行に対してステップＳ４４の処理で両者が一致しないと判定された場合、ステップＳ４６において、実行判定部３０２１は、制御要求が競合していないと判定して処理を終了する。

図１２に戻り、ステップＳ１９において、実行判定部３０２１は、競合判定処理の結果、制御要求が競合しているか否かを判定する。ここで、制御要求が競合していると判定された場合（ステップＳ１９でＹＥＳ）、ステップＳ２０において、実行判定部３０２１は、依存関係設定処理を実行する。次に、ステップＳ２１において、実行判定部３０２１は、状態監視テーブル更新処理を実行する。なお、初期状態ではいずれのサービスも実行されていないため、制御要求は競合し得ない。そのため、依存関係設定処理及び状態監視テーブル更新処理の詳細については後述する。

状態監視テーブル更新処理が終了した後、又は制御要求が競合していないと判定された場合（ステップＳ１９でＮＯ）、ステップＳ２２において、実行判定部３０２１は、ステップＳ１６で特定した行の機器占有状態６０６を“使用中”に変更する。

次に、ステップＳ２３において、実行判定部３０２１は、機器制御部３０３へ制御要求を送信する。

次に、ステップＳ２４において、機器制御部３０３は、制御要求を受信し、機器を制御するための機器制御コマンドを当該機器に対して送信する。機器は、機器制御コマンドを受信し、受信した機器制御コマンドに応じてサービスを実行する。そして、機器は、機器制御コマンドに対する応答として制御結果を調停装置１０３へ送信する。機器制御部３０３は、機器によって送信された制御結果を受信する。

次に、機器制御部３０３が機器から制御結果を受信すると、ステップＳ２５において、実行判定部３０２１は、サービス実行部３０１へ制御結果を返信する。

次に、ステップＳ２６において、サービス実行部３０１は、操作端末１０１へ制御結果を通知して処理を終了する。以上の処理が実行されることにより先行サービスが実行された後の調停管理テーブル３０２２の状態を図４に示す。初期状態ではいずれの機器もサービスを実行していないため、調停管理テーブル３０２２における機器占有状態６０６はすべて“使用中”となっている。

続いて、図１１及び図１２を用いて、機器に対して後続サービスを実行させる場合の処理の流れについて説明する。

まず、ステップＳ１１〜Ｓ１７の処理については、前述の処理と同様であるため説明を省略する。ステップＳ１８の競合判定処理についても前述と同様の処理を行うが、ここでは、先行サービスと後続サービスとが同じ宅内のエアコン（機器ＩＤ：ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１）で実行される。そのため、図１４のステップＳ４４において両者が一致すると判定され、ステップＳ４５において、実行判定部３０２１は、制御要求が競合していると判定して処理を終了する。その結果、図１２のステップＳ１９において制御要求が競合していると判定され、実行判定部３０２１は、依存関係設定処理及び状態監視テーブル更新処理を実行する。まず、ステップＳ２０の依存関係設定処理の詳細について説明する。図１５は、図１２のステップＳ２０の依存関係設定処理について説明するためのフローチャートである。

依存関係設定処理のステップＳ５１において、実行判定部３０２１は、調停管理テーブル３０２２のすべての行を検査する。

まず、ステップＳ５２において、実行判定部３０２１は、調停管理テーブル３０２２のｉ行目の制御対象機器ＩＤ６０５と、サービス実行部３０１から通知された制御対象機器ＩＤとを比較する。

次に、ステップＳ５３において、実行判定部３０２１は、ｉ行目の制御対象機器ＩＤ６０５と、通知された制御対象機器ＩＤとの両者が一致するか否かを判定する。ここで、両者が一致しないと判定された場合（ステップＳ５３でＮＯ）、実行判定部３０２１は、ステップＳ５１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。

一方、両者が一致すると判定された場合（ステップＳ５３でＹＥＳ）、ステップＳ５４において、実行判定部３０２１は、検査しているｉ行目のサービスＩＤ６０２の値と、サービス実行部３０１から通知されたサービスＩＤとを比較する。

次に、ステップＳ５５において、実行判定部３０２１は、ｉ行目のサービスＩＤ６０２の値と、通知されたサービスＩＤとの両者が一致するか否かを判定する。ここで、両者が一致すると判定された場合（ステップＳ５５でＹＥＳ）、ステップＳ５６において、実行判定部３０２１は、検査している行の位置（ｉの値）を記憶し、ステップＳ５１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。ここでは一例として、ステップＳ５６で記憶する行番号をｊ行目としている。

一方、両者が一致しないと判定された場合（ステップＳ５５でＮＯ）、ステップＳ５７において、実行判定部３０２１は、検査しているｉ行目の機器占有状態６０６が“使用中”であるか否かを判定する。ここで、機器占有状態６０６が“使用中”ではないと判定された場合（ステップＳ５７でＮＯ）、実行判定部３０２１は、ステップＳ５１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。

一方、機器占有状態６０６が“使用中”であると判定された場合（ステップＳ５７でＹＥＳ）、ステップＳ５８において、実行判定部３０２１は、ｉ行目の機器占有状態６０６を“待ち”に変更する。

次に、ステップＳ５９において、実行判定部３０２１は、検査しているｉ行目のリクエストＩＤ６０１の値を、先に記憶した行番号であるｊ行目の依存関係６０７に格納し、ステップＳ５１の処理に戻り、調停管理テーブル３０２２内の次の行を検査する。なお、上記ではステップＳ５９の処理に先立ってステップＳ５７の処理を実行した結果、ステップＳ５９の処理時点で依存関係６０７の格納先行番号として使用する変数ｊの値がすでに得られている。しかしながら、先にステップＳ５９の処理を実行した際にその行番号を記憶し（例えばｋ行目とする）、後でステップＳ５７の処理を実行した際にその変数ｋの値を使用してもよい。依存関係設定処理が終了した時点での調停管理テーブル３０２２の状態の一例を図５に示す。

続いて、図１２のステップＳ２１の状態監視テーブル更新処理の詳細について図６及び図１６を用いて説明する。図１６は、図１２のステップＳ２１の状態監視テーブル更新処理について説明するためのフローチャートである。

まず、状態監視テーブル更新処理のステップＳ６１において、実行判定部３０２１は、サービス実行部３０１から通知された制御対象機器ＩＤに対応する機器種別を取得する。ステップＳ６１の処理を実現するためには、例えば調停装置１０３の記憶部２０３は、図１７に示すような対応表を保持する。図１７は、本開示の実施の形態１における機器ＩＤと機器種別とを対応付けた対応表の一例を示す図である。図１７に示す対応表は、各行でそれぞれ１個の機器の情報を管理するものであり、機器を調停装置１０３に登録する際、又は機器と調停装置１０３とをペアリングする際に新規のエントリが追加される。ここで、機器種別７０２は、例えばＥＣＨＯＮＥＴ Ｌｉｔｅ規格の機器オブジェクトのクラス等のカテゴリに関連付けることを想定する。ここでは、宅内のエアコンが後続サービスを実行し、エアコンの機器ＩＤが“ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１”であるため、ステップＳ６１の処理の結果、実行判定部３０２１は、図１７に示す行７１１の機器種別“エアコン”を取得する。

次に、ステップＳ６２において、実行判定部３０２１は、サービスのマニフェストの終了条件５２１から、制御対象種別及び制御プロパティが一致する終了条件を検索する。例えば、制御要求が“温度設定値”の制御プロパティを変更する場合、ステップＳ６２の処理では、終了条件５２１における制御対象種別５０２Ａ及び制御プロパティ５０２Ｂを検索した結果、行５１２Ａの終了条件が一致する。

次に、ステップＳ６３において、実行判定部３０２１は、一致する終了条件が存在せず、かつマニフェストの常駐が“可”であるか否かを判定する。ここで、一致する終了条件が存在せず、かつマニフェストの常駐が“可”であると判定された場合（ステップＳ６３でＹＥＳ）、処理を終了する。すなわち、マニフェストに終了条件の記載がないが常駐するようなサービスに対しては、状態監視テーブルのエントリは作成しない。これにより、機器制御を一切監視することなく、機器の制御権を占有させ続けることが可能となる。

一方、一致する終了条件が存在せず、かつマニフェストの常駐が“可”ではないと判定された場合、一致する終了条件が存在し、かつマニフェストの常駐が“可”であると判定された場合、又は一致する終了条件が存在し、かつマニフェストの常駐が“可”ではないと判定された場合（ステップＳ６３でＮＯ）、ステップＳ６４において、実行判定部３０２１は、監視対象の情報を設定する監視対象設定処理を実行する。ここで、ステップＳ６４の監視対象設定処理の詳細について説明する。図１８は、図１６のステップＳ６４の監視対象設定処理について説明するためのフローチャートである。

まず、監視対象設定処理のステップＳ８１において、実行判定部３０２１は、サービス実行部３０１から通知された制御要求に含まれる制御対象機器ＩＤを状態監視テーブル３０２３の機器ＩＤ８０１に格納する。

次に、ステップＳ８２において、実行判定部３０２１は、サービス実行部３０１から通知された制御要求に含まれる制御プロパティを状態監視テーブル３０２３のプロパティ８０２に格納する。

次に、ステップＳ８３において、実行判定部３０２１は、調停管理テーブル３０２２を検索し、サービス実行部３０１から通知されたサービスＩＤと、ステップＳ８１において格納した制御対象機器ＩＤとがともに一致する行を特定する。

次に、ステップＳ８４において、実行判定部３０２１は、特定した行のリクエストＩＤ６０１の値を状態監視テーブル３０２３のリクエストＩＤ８０４に格納して処理を終了する。

図１６に戻り、監視対象設定処理が終了すると、ステップＳ６５において、実行判定部３０２１は、ステップＳ６２の処理で制御対象種別及び制御プロパティが一致する終了条件があったか否かを判定する。ここで、一致する終了条件があったと判定された場合（ステップＳ６５でＹＥＳ）、ステップＳ６６において、実行判定部３０２１は、終了条件５２１の制御対象種別及び制御プロパティが一致した行における基準値５０２Ｄを参照し、基準値５０２Ｄが“指定値”であるか否かを判定する。

ここで、基準値５０２Ｄが“指定値”であると判定された場合（ステップＳ６６でＹＥＳ）、ステップＳ６７において、実行判定部３０２１は、制御要求において指定された監視プロパティ５０２Ｃの値と、終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納して処理を終了する。

一方、基準値５０２Ｄが“指定値”ではないと判定された場合（ステップＳ６６でＮＯ）、ステップＳ６８において、実行判定部３０２１は、終了条件５２１の監視プロパティ５０２Ｃの現在値を制御対象機器から機器制御部３０３を介して取得する。

次に、ステップＳ６９において、実行判定部３０２１は、取得した現在値と終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納して処理を終了する。このように、ステップＳ６７の処理により絶対値を監視し、ステップＳ６８及びステップＳ６９の処理により相対値を監視するように指定することができる。

また、ステップＳ６５において一致する終了条件がなかったと判定された場合（ステップＳ６５でＮＯ）、ステップＳ７０において、実行判定部３０２１は、状態監視テーブル３０２３の目標値８０３に対して、条件が常に成立することを示す値を格納して処理を終了する。ここでは、条件が常に成立することを示す値の一例として“Ｔｒｕｅ”が格納されるが、その具体的な値は種々の変形が可能である。このようにすることにより、マニフェストに終了条件の記載がなく、かつ常駐しないようなサービスを実行する制御要求が、異なるサービスを実行する制御要求に割り込んだ場合に、機器の制御権を占有し続けることを防止することができる。なお、具体的な処理の流れについては、後述のサービス監視処理の説明において述べる。状態監視テーブル更新処理が終了した時点での状態監視テーブル３０２３の状態の一例を図６に示す。なお、状態監視テーブル更新処理が終了した後の処理、すなわち図１２のステップＳ２２〜ステップＳ２６の処理については、すでに説明した動作と同じであるため説明を省略する。

以上で説明したすべての処理とは独立して、調停装置１０３は、図１９及び図２０に示すサービス監視処理を常に実行する。まず、サービス監視処理を実現するために状態監視部３０２４で実行される処理の流れについて説明する。図１９は、状態監視部で実行するサービス監視処理について説明するためのフローチャートである。

サービス監視処理のステップＳ９１において、状態監視部３０２４は、状態監視テーブル３０２３のすべての行を検査する。

まず、ステップＳ９２において、状態監視部３０２４は、状態監視テーブル３０２３の各行に対して目標値判定処理を行う。ここで、ステップＳ９２の目標値判定処理の詳細について説明する。図２１は、図１９のステップＳ９２の目標値判定処理について説明するためのフローチャートである。

まず、目標値判定処理のステップＳ１１１において、状態監視部３０２４は、状態監視テーブル３０２３で検査している行の機器ＩＤ８０１の機器から、機器制御部３０３を通じてプロパティ８０２の値を取得する。

次に、ステップＳ１１２において、状態監視部３０２４は、取得したプロパティの値と、状態監視テーブル３０２３の目標値８０３に記載された値とを比較する。

次に、ステップＳ１１３において、状態監視部３０２４は、取得したプロパティの値と、状態監視テーブル３０２３の目標値８０３に記載された値との両者が一致するか否かを判定する。ここで、両者が一致すると判定された場合（ステップＳ１１３でＹＥＳ）、ステップＳ１１４において、状態監視部３０２４は、目標値を満たしたと判定して処理を終了する。

一方、両者が一致していないと判定された場合（ステップＳ１１３でＮＯ）、ステップＳ１１５において、状態監視部３０２４は、目標値を満たしていないと判定して処理を終了する。

なお、ステップＳ１１３では一例として両者の値が一致しているか否かを判定しているが、この処理は必ずしも等値性の比較である必要はなく、値の大小関係の比較や、値が特定の範囲内にあるか否かの比較といった種々の変形が可能である。

すなわち、空間推定情報は、空間の現在の状態を示す数値を含む。そして、状態監視部３０２４は、空間の状態が第１のサービスが満たすべき状態にあることを示す目標値の範囲に、数値が含まれるか否かを判定する。目標値の範囲に数値が含まれないと判定された場合、状態監視部３０２４は、空間の状態が第１のサービスが満たすべき状態にないと判定する。

また、空間推定情報は、第１の制御要求に基づいて第１の機器の制御が開始されてから現在までの間における空間の状態の変化量を示す数値を含んでもよい。この場合、状態監視部３０２４は、空間の状態が第１のサービスが満たすべき状態にあることを示す目標値の範囲に、数値が含まれるか否かを判定してもよい。目標値の範囲に数値が含まれないと判定された場合、状態監視部３０２４は、空間の状態が第１のサービスが満たすべき状態にないと判定する。

また、ステップＳ１１１で機器ＩＤ８０１に記載がない場合、又は機器ＩＤ８０１に対応する機器からプロパティ８０２の値の取得要求に対する応答がないなどの理由でプロパティの値が取得できなかった場合は、値なしとしてステップＳ１１２の処理に移行してもよい。その場合、ステップＳ１１２では値を比較することなく、両者が一致しているとしてステップＳ１１３の処理に進む。このようにすることで、故障又は通信途絶により応答が得られなくなった機器の制御権が解放されずに、同一のサービスが実行され続ける状態を防止することができる。

図１９に戻り、次に、ステップＳ９３において、状態監視部３０２４は、目標値判定処理の結果から、状態監視テーブル３０２３で検査している行のプロパティの値が目標値を満たしたか否かを判定する。ここで、プロパティの値が目標値を満たしていないと判定された場合（ステップＳ９３でＮＯ）、状態監視部３０２４は、状態監視テーブル３０２３内の次の行を検査する。

一方、プロパティの値が目標値を満たしたと判定された場合（ステップＳ９３でＹＥＳ）、ステップＳ９４において、状態監視部３０２４は、状態監視テーブル３０２３の検査している行のリクエストＩＤ８０４を実行判定部３０２１に通知する。

次に、ステップＳ９５において、状態監視部３０２４は、状態監視テーブル３０２３からリクエストＩＤ８０４と同一の値を持つ行をすべて削除する。そして、ステップＳ９１の処理に戻り、状態監視部３０２４は、状態監視テーブル３０２３内の次の行を検査する。状態監視テーブル３０２３内のすべての行に対する検査が完了すると、ステップＳ９６において、状態監視部３０２４は、所定時間待機する。所定時間が経過すると、状態監視部３０２４は、ステップＳ９１の処理を再度実行する。

なお、ステップＳ９１の処理を再度実行するタイミングは必ずしも上記所定時間が経過した時点である必要はなく、例えば、機器状態が変化した際に機器が発行する通知を機器制御部３０３が受信した後、機器制御部３０３がさらに発行する通知を状態監視部３０２４が受信した時点であってもよい。ここで、状態監視部３０２４が機器制御部３０３からの通知を受信した時点で、ステップＳ９１の繰り返し処理が実行中であるなどの理由で、即座にステップＳ９１の処理を実行できない場合は、その時点で実行している繰り返し処理が終了した時点でステップＳ９１の処理を再度実行してもよい。

続いて、サービス監視処理を実現するために実行判定部３０２１で実行される処理の流れについて説明する。図２０は、実行判定部で実行するサービス監視処理について説明するためのフローチャートである。

まず、ステップＳ１０１において、実行判定部３０２１は、状態監視部３０２４から通知されたリクエストＩＤを持つ行を、調停管理テーブル３０２２から検索する。

次に、ステップＳ１０２において、実行判定部３０２１は、検索された行の機器占有状態６０６を“未使用”に変更する。

次に、ステップＳ１０３において、実行判定部３０２１は、検索された行の依存関係６０７に値が格納されているか否かを判定することにより、他のリクエストＩＤと依存関係があるか否かを判定する。ここで、依存関係６０７に値が格納されていない、すなわち他のリクエストＩＤと依存関係がないと判定された場合（ステップＳ１０３でＮＯ）、ステップＳ１０６において、実行判定部３０２１は、制御結果をサービス実行部３０１へ通知する。

次に、ステップＳ１０７において、制御結果が通知されたサービス実行部３０１は、操作端末１０１へ制御結果を通知して処理を終了する。

一方、ステップＳ１０３において依存関係６０７に値が格納されている、すなわち他のリクエストＩＤと依存関係があると判定された場合（ステップＳ１０３でＹＥＳ）、ステップＳ１０４において、実行判定部３０２１は、調停管理テーブル３０２２内を検索し、依存関係６０７に格納された値と同じ値がリクエストＩＤ６０１に格納されている行を特定する。

次に、ステップＳ１０５において、実行判定部３０２１は、特定された行の機器占有状態６０６を“使用中”に変更する。

次に、ステップＳ１０６において、実行判定部３０２１は、制御結果をサービス実行部３０１へ通知する。

次に、ステップＳ１０７において、制御結果が通知されたサービス実行部３０１は、操作端末１０１へ制御結果を通知して処理を終了する。

以上により、機器の占有期間を明示的に指定することが可能となる。これにより、サービスによる機器制御の目的、又はサービスが実行されることによって変化する室内の環境等に適応した機器制御が可能となり、ユーザの利便性を向上させることが可能となる。

なお、図１９のステップＳ９３の説明では、プロパティの値が目標値を満たすことにより、サービスの終了条件が満たされると、機器制御は必ず終了しているが、機器制御の終了時に機器制御を終了するか否かをユーザに確認してもよい。これを実現するためには、例えばステップＳ９３の処理の終了時に、図２２に示す通知画面を操作端末１０１に表示する。

図２２は、機器制御の終了をユーザに確認するための通知画面の一例を示す図である。操作端末１０１の通知画面には、例えば、“エアコンの省エネ運転を再開します。よろしいですか？”というメッセージと、肯定的な選択肢２５０１と、否定的な選択肢２５０２とが表示される。ユーザが選択肢２５０１を選択した場合、終了条件を満たした機器制御が終了され、終了した機器制御の前に動作していた機器制御が再開される。一方、ユーザが選択肢２５０２を選択した場合、終了条件を満たした機器制御が続行される。

同様に、図１２のステップＳ１９の説明では、制御要求が競合している場合は必ず割り込んだ側のサービスが機器の制御権を獲得するとしているが、競合発生時において、実行するサービスを切り替えるか否かをユーザに確認してもよい。これを実現するためには、例えばステップＳ１９の処理の終了時に、図２３に示す通知画面を操作端末１０１に表示する。

図２３は、機器制御の切り替えをユーザに確認するための通知画面の一例を示す図である。操作端末１０１の通知画面には、例えば、“他のサービスがエアコンを使用中です。続けますか？”というメッセージと、肯定的な選択肢２６０１と、否定的な選択肢２６０２とが表示される。ユーザが選択肢２６０１を選択した場合、通常通りステップＳ２０の処理に進み、以降の処理もすべて実行される。一方、ユーザが選択肢２６０２を選択した場合、実行判定部３０２１は、ステップＳ１７で設定したリクエストＩＤ６０１と制御対象機器ＩＤ６０５とを削除した上で、サービス実行部３０１に対し機器制御キャンセルを通知して処理を終了する。

このように、第１のサービスの内容を定義するマニフェスト（サービス定義情報）は、第１のサービスが満たすべき状態を定義する終了条件（条件定義情報）を含んでもよい。そして、実行判定部３０２１は、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かを、サービス定義情報に含まれる条件定義情報を用いて判定する。なお、第１の制御要求は、第１のサービスが満たすべき状態を定義する終了条件（条件定義情報）を含んでもよい。この場合、実行判定部３０２１は、空間推定情報に基づき推定される空間の状態が第１のサービスが満たすべき状態にあるか否かを、第１の制御要求から取得した条件定義情報を用いて判定してもよい。

また、本実施の形態においては、サービスによる機器制御の終了条件をマニフェストの終了条件５２１に記載された値に基づいて設定しているが、この終了条件の値に対し任意の時点において、サービス実行部３０１からの修正又はユーザが操作する操作端末１０１からの修正を受け付けてもよい。すなわち、サービス実行部３０１により終了条件の値が修正される場合、サービス実行部３０１は、例えばサービスを実行するために呼び出す機器制御ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の引数として終了条件を設定してもよい。また、ユーザ操作により終了条件の値が修正される場合、例えばユーザが操作端末１０１上で動作するアプリケーションを操作することによって、サービス実行部３０１は、サービスが実行される前にあらかじめ終了条件を設定してもよい。また、操作端末１０１は、図２２及び図２３に示す通知画面のように、終了条件を設定するための設定画面を表示してもよい。

このように、サービス実行部３０１は、第１のサービスが満たすべき状態を定義する条件定義情報のユーザによる入力を受け付けてもよい。実行判定部３０２１は、空間推定情報に基づき推定される前記空間の状態が第１のサービスが満たすべき状態にあるか否かを、受け付けられた条件定義情報を用いて判定してもよい。

また、本実施の形態においては、調停管理テーブル３０２２における常駐６０３及び割込み６０４はサービス単位で定義しているが、サービスが実行される制御対象ごとに定義し、かつ、それぞれについてより詳細な条件を設定してもよい。例えば、異なるサービスを実行するための制御要求が特定のプロパティを操作する場合のみ常駐６０３及び割込み６０４を“可”としてもよく、特定のサービスを実行するための制御要求、特定の操作端末からの制御要求、又は特定のユーザによって入力された制御要求が競合した場合のみ常駐６０３及び割込み６０４を“可”としてもよい。

また、終了条件５２１の各行の終了条件はそれぞれ独立であるとして説明したが、任意の終了条件を組合せてもよい。すなわち、各行に存在する終了条件のうち複数の終了条件を満たしたときにサービスを終了させる終了条件設定を行うことも可能である。

さらに、終了条件５２１の監視プロパティ５０２Ｃは、対象の機器が持つプロパティの他に時間を指定してもよい。これにより、サービスが実行された後、又は機器制御が終了条件を満たしてから一定時間が経過した後に、サービスの実行を終了させることが可能となる。

すなわち、空間推定情報は、第１の制御要求に基づいて第１の機器の制御が開始されてから現在までの経過時間であってもよい。この場合、実行判定部３０２１は、経過時間が所定の範囲に含まれるか否かを判定し、経過時間が所定の範囲に含まれないと判定された場合、空間の状態が第１のサービスが満たすべき状態にないと判定してもよい。また、空間推定情報は、第１の制御要求に基づいて制御を開始した第１の機器の状態が所定の状態に達してから現在までの経過時間であってもよい。この場合、実行判定部３０２１は、経過時間が所定の範囲に含まれるか否かを判定し、経過時間が所定の範囲に含まれないと判定された場合、空間の状態が第１のサービスが満たすべき状態にないと判定する。

（実施の形態２）
本開示の実施の形態１においては、サービスの終了条件を判定する際、制御対象機器と監視対象機器とが同一であることを想定している。これに対して、本実施の形態２におけるサービスの終了条件判定では、指定した監視プロパティを持つ任意の数の機器を監視対象とする。すなわち、本実施の形態２においては、図１における通信網１０２に接続された操作端末１０１、第１の機器１０４及び第２の機器１０５を含むすべての機器が監視対象となり得る。

図２４は、本開示の実施の形態２におけるマニフェスト内の終了条件の一例を示す図である。本実施の形態を実現するために、サービスのマニフェストの構成を図２４に示すように変更する。すなわち、終了条件５２１は、監視範囲５０２Ｆ及び採用値５０２Ｇをさらに含む。

監視範囲５０２Ｆは、指定した監視プロパティを持つ機器を検索する範囲であり、“部屋”、“家”又は“１階”などのような範囲（空間）を指定する。ここで、監視範囲５０２Ｆの値として“制御対象機器”を設定し、制御対象機器のみを監視対象とすることによって、実施の形態１と論理的に等価な構成とすることも可能である。

また、採用値５０２Ｇは、監視範囲５０２Ｆの範囲にある複数の機器から監視プロパティの複数の値を取得する場合に、複数の値を状態監視テーブル３０２３の目標値８０３とそれぞれ比較した結果、最終的にどの結果を採用するかを決定するための情報である。採用値５０２Ｇには、例えば“ＡＮＤ”、“ＯＲ”又は“平均”などの値が設定される。ここで、“ＡＮＤ”は、すべての結果を採用する（すなわち、監視範囲５０２Ｆにある複数の機器から得た監視プロパティの複数の値のすべてが目標値８０３を満たすことを要求する）ことを示す。“ＯＲ”は、少なくとも１個の結果を採用する（すなわち、監視範囲５０２Ｆにある複数の機器から得た監視プロパティの複数の値の少なくとも１個が目標値８０３を満たすことを要求する）ことを示す。“平均”は、監視範囲５０２Ｆにある複数の機器から得た監視プロパティの複数の値を平均し、平均値を目標値８０３と比較した結果を採用することを示す。

図２５は、本開示の実施の形態２における状態監視テーブルの一例を示す図である。実施の形態２における状態監視テーブル３０２３は、図２５に示すように監視範囲８０５及び採用値８０６をさらに含む。具体的には、図２５に示す行８１１は、監視範囲８０５である“ＬｉｖｉｎｇＲｏｏｍ１”にある複数の機器のうち、プロパティ８０２である“室内温度”をプロパティとして持つ機器の状態を定期的に取得し、取得した状態の平均値を算出し（採用値８０６が“平均”であるため）、算出した平均値を目標値８０３と比較することを意味している。なお、図２４における列５０２Ａ〜５０２Ｅの内容及び図２５における列８０１〜８０４の内容は実施の形態１と同様であるため、説明は省略する。

図２６は、本開示の実施の形態２における機器ＩＤと機器種別と設置場所とを対応付けた対応表の一例を示す図である。本実施の形態２では、図１７に示す機器ＩＤと機器種別とを対応付けた対応表を図２６に示すように変更する。すなわち、対応表の各行は、機器の設置場所７０３を含む。設置場所７０３は、実際に機器が設置されている場所を示す一意の識別子である。設置場所７０３は、機器を調停装置１０３に登録する際、又は機器と調停装置１０３とをペアリングする際に、ユーザが操作端末１０１を操作することによって設定される。

さらに、本実施の形態２では、図１６に示した状態監視テーブル更新処理の流れを変更する。本実施の形態２における状態監視テーブル更新処理の詳細について図２７を用いて説明する。図２７は、本開示の実施の形態２における状態監視テーブル更新処理について説明するためのフローチャートである。

本実施の形態２の状態監視テーブル更新処理のステップＳ１２１において、実行判定部３０２１は、サービス実行部３０１から通知された制御対象機器ＩＤに対応する機器種別及び設置場所を取得する。ステップＳ１２１の処理を実現するためには、実施の形態１と同様に、調停装置１０３の記憶部２０３は、前述の図２６に示すような対応表を保持する。例えば、宅内のエアコンが後続サービスを実行し、エアコンの機器ＩＤが“ＡｉｒＣｏｎｄｉｔｉｏｎｅｒ１”である場合、ステップＳ１２１の処理の結果、実行判定部３０２１は、行７１１の機器種別“エアコン”及び設置場所“ＬｉｖｉｎｇＲｏｏｍ１”を取得する。

次に、ステップＳ１２２において、実行判定部３０２１は、図２４に示したサービスのマニフェストの終了条件５２１から、制御対象種別及び制御プロパティが一致する終了条件を検索する。例えば、制御要求が“温度設定値”の制御プロパティを変更する場合、ステップＳ１２２の処理では、終了条件５２１における制御対象種別５０２Ａ及び制御プロパティ５０２Ｂを検索した結果、行５１２Ａの終了条件が一致する。

次に、ステップＳ１２３において、実行判定部３０２１は、一致する終了条件が存在せず、かつマニフェストの常駐が“可”であるか否かを判定する。ここで、一致する終了条件が存在せず、かつマニフェストの常駐が“可”であると判定された場合（ステップＳ１２３でＹＥＳ）、処理を終了する。

一方、一致する終了条件が存在せず、かつマニフェストの常駐が“可”ではないと判定された場合、一致する終了条件が存在し、かつマニフェストの常駐が“可”であると判定された場合、又は一致する終了条件が存在し、かつマニフェストの常駐が“可”ではないと判定された場合（ステップＳ１２３でＮＯ）、ステップＳ１２４において、実行判定部３０２１は、監視対象の情報を設定する監視対象設定処理を実行する。なお、ステップＳ１２４の監視対象設定処理は、実施の形態１と同様であるため、説明は省略する。

監視対象設定処理が終了すると、ステップＳ１２５において、実行判定部３０２１は、ステップＳ１２２の処理で制御対象種別及び制御プロパティが一致する終了条件があったか否かを判定する。ここで、一致する終了条件があったと判定された場合（ステップＳ１２５でＹＥＳ）、ステップＳ１２６において、実行判定部３０２１は、終了条件５２１の制御対象種別及び制御プロパティが一致した行における監視範囲５０２Ｆの値及び採用値５０２Ｇの値を、状態監視テーブル３０２３の監視範囲８０５及び採用値８０６にそれぞれ格納する。

次に、ステップＳ１２７において、実行判定部３０２１は、終了条件５２１の制御対象種別及び制御プロパティが一致した行における基準値５０２Ｄを参照し、基準値５０２Ｄが“指定値”であるか否かを判定する。

ここで、基準値５０２Ｄが“指定値”であると判定された場合（ステップＳ１２７でＹＥＳ）、ステップＳ１２８において、実行判定部３０２１は、制御要求において指定された監視プロパティ５０２Ｃの値と、終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納して処理を終了する。

一方、基準値５０２Ｄが“指定値”ではないと判定された場合（ステップＳ１２７でＮＯ）、ステップＳ１２９において、実行判定部３０２１は、監視プロパティの現在値を取得する監視プロパティ値取得処理を実行する。ここで、ステップＳ１２９の監視プロパティ値取得処理の詳細について説明する。図２８は、図２７のステップＳ１２９の監視プロパティ値取得処理について説明するためのフローチャートである。

まず、監視プロパティ値取得処理のステップＳ１４１において、実行判定部３０２１は、状態監視テーブル３０２３で現在操作している行の監視範囲８０５を参照し、監視範囲８０５に存在する機器の一覧を取得する。ステップＳ１４１の処理を実現するためには、例えば図２６の対応表を検索し、対応表の設置場所７０３に格納されている値が監視範囲８０５の値と同一である行をすべて抽出する。

次に、ステップＳ１４２において、実行判定部３０２１は、取得した機器一覧から、状態監視テーブル３０２３で現在操作している行のプロパティ８０２の値を持つ機器を抽出する。ステップＳ１４２の処理は、例えばＥＣＨＯＮＥＴ Ｌｉｔｅ規格におけるＧｅｔＰｒｏｐｅｒｔｙＭａｐのように、機器と取得可能なプロパティの一覧とを関連付けたリストを検索することによって実現する。

次に、ステップＳ１４３において、実行判定部３０２１は、抽出したすべての機器から、機器制御部３０３を介してプロパティ８０２の値を取得する。

次に、ステップＳ１４４において、実行判定部３０２１は、状態監視テーブル３０２３で現在操作している行の採用値８０６が“平均”であるか否かを判定する。ここで、採用値８０６が“平均”であると判定された場合（ステップＳ１４４でＹＥＳ）、ステップＳ１４５において、実行判定部３０２１は、ステップＳ１４３の処理において取得したすべての値の平均値を算出して処理を終了する。

一方、採用値８０６が“平均”ではないと判定された場合、すなわち採用値８０６が“ＡＮＤ”又は“ＯＲ”であると判定された場合（ステップＳ１４４でＮＯ）、ステップＳ１４６において、実行判定部３０２１は、ステップＳ１４３の処理において取得したすべての値と、対応する機器ＩＤとを組にしたリストを作成して処理を終了する。

図２７に戻り、監視プロパティ値取得処理によって値が取得された後、ステップＳ１３０において、実行判定部３０２１は、取得した値と終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納して処理を終了する。ここで、監視プロパティ値取得処理によって取得した値がリストである場合、リスト内の値と終了条件５２１の目標５０２Ｅと組み合わせる方法については種々の形態が可能である。例えば、実行判定部３０２１は、リストの値の平均値を算出し、算出した平均値と終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納してもよい。また、実行判定部３０２１は、リストの各組の機器ＩＤをもとに使用する値を選択し、選択した値と終了条件５２１の目標５０２Ｅとを組み合わせた値を状態監視テーブル３０２３の目標値８０３に格納してもよい。このように、ステップＳ１２８の処理２００８により絶対値を監視し、ステップＳ１２９及びステップＳ１３０の処理により相対値を監視するように指定することができる。

また、ステップＳ１２５において一致する終了条件がなかったと判定された場合（ステップＳ１２５でＮＯ）、ステップＳ１３１において、実行判定部３０２１は、状態監視テーブル３０２３の目標値８０３に対して、条件が常に成立することを示す値を格納して処理を終了する。ステップＳ１３１の処理では、実施の形態１と同様に、条件が常に成立することを示す値の一例として“Ｔｒｕｅ”が格納される。本実施の形態２における状態監視テーブル更新処理が終了した時点での状態監視テーブル３０２３の状態の一例を図２５に示す。

また、本実施の形態２では、図２１に示した目標値判定処理の流れを変更する。本実施の形態２における目標値判定処理の詳細について図２９を用いて説明する。図２９は、本開示の実施の形態２における目標値判定処理について説明するためのフローチャートである。

まず、目標値判定処理のステップＳ１５１において、状態監視部３０２４は、監視プロパティの現在値を取得する監視プロパティ値取得処理を実行する。なお、ステップＳ１５１の監視プロパティ値取得処理は図２８に示す監視プロパティ値取得処理と同様であるため、説明は省略する。

次に、ステップＳ１５２において、状態監視部３０２４は、監視プロパティ値取得処理で取得したすべての値を検査する。

次に、ステップＳ１５３において、状態監視部３０２４は、取得したプロパティの値のそれぞれと、状態監視テーブル３０２３の目標値８０３に記載された値とを比較する。

次に、ステップＳ１５４において、状態監視部３０２４は、取得したプロパティの値と、状態監視テーブル３０２３の目標値８０３に記載された値との両者が一致するか否かを判定する。ここで、両者が一致すると判定された場合（ステップＳ１５４でＹＥＳ）、ステップＳ１５５において、状態監視部３０２４は、目標値を満たしたと判定したことを示す値を結果リストに格納する。一例として、目標値を満たしたと判定したことを示す値を“Ｔｒｕｅ”とし、状態監視部３０２４は、結果リストに“Ｔｒｕｅ”を格納する。

一方、両者が一致していないと判定された場合（ステップＳ１５４でＮＯ）、ステップＳ１５６において、状態監視部３０２４は、目標値を満たしていないと判定したことを示す値を結果リストに格納する。一例として、目標値を満たしていないと判定したことを示す値を“Ｆａｌｓｅ”とし、状態監視部３０２４は、結果リストに“Ｆａｌｓｅ”を格納する。

監視プロパティ値取得処理で取得したすべての値を比較した後、ステップＳ１５７において、状態監視部３０２４は、状態監視テーブル３０２３の採用値８０６が“ＯＲ”であるか否かを判定する。ここで、採用値８０６が“ＯＲ”であると判定された場合（ステップＳ１５７でＹＥＳ）、ステップＳ１５８において、状態監視部３０２４は、ステップＳ１５５及びステップＳ１５６の処理で作成した結果リストの値に“Ｔｒｕｅ”が存在するか否かを判定する。

ここで、結果リストの値に“Ｔｒｕｅ”が存在すると判定された場合（ステップＳ１５８でＹＥＳ）、ステップＳ１５９において、状態監視部３０２４は、目標値を満たしたと判定して処理を終了する。一方、結果リストの値に“Ｔｒｕｅ”が存在しないと判定された場合（ステップＳ１５８でＮＯ）、ステップＳ１６０において、状態監視部３０２４は、目標値を満たしていないと判定して処理を終了する。

一方、ステップＳ１５７において採用値８０６が“ＯＲ”ではない、すなわち採用値８０６が“ＡＮＤ”又は“平均”であると判定された場合（ステップＳ１５７でＮＯ）、ステップＳ１６１において、状態監視部３０２４は、ステップＳ１５５及びステップＳ１５６の処理で作成した結果リストの値がすべて“Ｔｒｕｅ”であるか否かを判定する。ここで、結果リストの値がすべて“Ｔｒｕｅ”であると判定された場合（ステップＳ１６１でＹＥＳ）、ステップＳ１５９において、状態監視部３０２４は、目標値を満たしたと判定して処理を終了する。一方、結果リストの値がすべて“Ｔｒｕｅ”ではないと判定された場合（ステップＳ１６１でＮＯ）、ステップＳ１６２において、状態監視部３０２４は、目標値を満たしていないと判定して処理を終了する。

なお、上記の説明では監視プロパティ値取得処理で取得したすべてのプロパティの値に対する比較処理（ステップＳ１５１〜Ｓ１５６）と、比較結果に対する論理演算（ステップＳ１５７〜Ｓ１５２）を逐次的に実行しているが、これは一例であり、一般的な論理演算における短絡評価を行ってもよい。

このように、空間推定情報は、複数の機器の状態を示す情報であってもよい。また、複数の機器は、同一の閉じた空間に設置されていてもよい。そして、状態監視部３０２４は、複数の機器のそれぞれから取得した空間推定情報のいずれもが所定の条件を満たすか否かを判定し、空間推定情報のいずれもが所定の条件を満たさないと判定された場合、空間の状態が第１のサービスが満たすべき状態にないと判定してもよい。また、状態監視部３０２４は、複数の機器それぞれから取得した空間推定情報の少なくとも１つが所定の条件を満たすか否かを判定し、空間推定情報の少なくとも１つが所定の条件を満たさないと判定された場合、空間の状態が第１のサービスが満たすべき状態にないと判定してもよい。さらに、状態監視部３０２４は、複数の機器それぞれから取得した数値の平均値が所定の条件を満たすか否かを判定し、数値の平均値が所定の条件を満たさないと判定された場合、空間の状態が第１のサービスが満たすべき状態にないと判定してもよい。

以上で説明したように、本実施の形態２における機器制御の終了条件判定では、指定した監視プロパティを持つ任意の数の機器を監視対象とする。これにより、宅内に存在する複数の機器の状態に応じて、機器制御の終了条件を柔軟に設定することができる。すなわち、機器を新規に追加した場合、又は機器の移設、譲渡もしくは故障等の理由により機器を使用しなくなった場合においても、監視対象機器の再設定といった煩雑な操作をユーザに強いることなく、環境に応じて監視対象機器の設定を動的に変更することが可能となる。

なお、以上の説明においては、状態監視テーブル３０２３の採用値８０６は、“ＡＮＤ”、“ＯＲ”及び“平均”の３種類の値を含むが、例えば一定数の機器が目標値を満たすことを要求するなどといった種々の変形が可能である。また、状態監視テーブル３０２３の監視範囲８０５及び採用値８０６は、ユーザが操作端末１０１上で動作するアプリケーションを操作することによって、任意のタイミングで変更してもよい。

また、終了条件５２１における監視プロパティ５０２Ｃには、実施の形態１と同様に時間を指定してもよい。さらに、監視プロパティ５０２Ｃには、通信網１０２に接続された操作端末１０１、第１の機器１０４及び第２の機器１０５を含む任意の機器から取得可能な任意の要素の値を指定してもよい。例えば、第２の機器１０５が、ユーザが身に着けている携帯型端末又はウェアラブル端末等である場合、第２の機器１０５の位置情報を監視プロパティ５０２Ｃに指定してもよい。位置情報の取得方法としては、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）、宅内に設置した無線送受信機によって送受信される電波の強度を用いた三角測量、又は端末に搭載された加速度、角速度及び磁気等の各種センサを用いた自律航法といった各種の方法が適用可能である。これにより、ユーザ又はユーザが携帯する端末の位置情報を機器制御の終了条件として利用することが可能となる。

さらにまた、監視プロパティ５０２Ｃは、操作端末１０１で動作するアプリケーションの画面上に表示した特定のボタンの押下状態であってもよい。これにより、ユーザによるボタン押下の操作を監視することも可能である。これを実現するためには、例えばサービスの実行による機器制御が成功した時点、すなわち図１２のステップＳ２６で、サービス実行部３０１が操作端末１０１に対し制御結果を通知した時点において、操作端末１０１は、操作端末１０１上で動作するアプリケーションの表示画面上に、機器制御の終了を指示するためのボタンを表示する。そして、ユーザが任意のタイミングでボタンを押下すると、操作端末１０１からサービス実行部３０１及び実行判定部３０２１を経由して状態監視部３０２４へ状態変化が通知される。これにより、ユーザが指定したタイミングでサービスの実行を終了させることが可能となる。

（実施の形態３）
本開示の実施の形態１及び実施の形態２においては、制御要求の調停又はサービスを実行するか否かの判定は、調停装置１０３内の調停部３０２が行っている。しかしながら、この構成では、同一のネットワーク内に複数の調停装置が存在する場合、それぞれの調停装置が異なる機器を個別に管理する状況が発生する可能性がある。その結果、各調停装置が管理している機器制御の占有状態に不整合が生じ得る。これに対して、本実施の形態３における機器制御では、ネットワーク内に複数の調停装置が存在する場合、複数の調停装置が連携して制御要求を調停する。

図３０は、本開示の実施の形態３における調停装置の詳細な構成の一例を示す図である。図３０に示すように、本実施の形態３では、機器制御システムは、第１の調停装置２３０１及び第２の調停装置２３０２を備える。第１の調停装置２３０１は、実施の形態１及び実施の形態２における調停装置１０３と同様に、サービス実行部３０１、調停部３０２、機器制御部３０３及びサービス格納部３０４を備える。また、第１の調停装置２３０１は、さらに動作切替部２３０３、調停要求送受信部２３０４及び調停結果送受信部２３０５を備える。第２の調停装置２３０２の構成要素は第１の調停装置２３０１の構成要素と同様であるため、説明は省略する。

動作切替部２３０３は、同一のネットワーク内において複数の調停部３０２が存在する場合に、自らが制御要求を調停する調停処理を行う第１の動作と、第２の調停装置２３０２に対して調停処理を移譲する第２の動作とを切り替える。

調停要求送受信部２３０４は、第２の調停装置２３０２に対して制御要求を調停するよう要求する調停要求を送信するとともに、第２の調停装置２３０２から調停要求を受信する。なお、調停要求送受信部２３０４の詳細な動作は後述する。

調停結果送受信部２３０５は、第２の調停装置２３０２から制御要求を調停した調停結果を受信するとともに、第２の調停装置２３０２に対して調停結果を送信する。なお、調停結果送受信部２３０５の詳細な動作は後述する。

次に、図３１を用いて、機器に対してサービスを実行させるときの第１の調停装置２３０１及び第２の調停装置２３０２の処理の流れを説明する。図３１は、本開示の実施の形態３における第１の調停装置及び第２の調停装置による調停処理の動作を説明するためのフローチャートである。なお、以下の例では、機器にサービスを実行させる制御要求を発行する機器を第１の調停装置２３０１と呼び、第１の調停装置２３０１以外の内部に調停部３０２を備える機器を第２の調停装置２３０２と呼ぶ。

機器によるサービスの実行が開始されると、まず、ステップＳ１７１において、第１の調停装置２３０１の動作切替部２３０３は、自機がネットワーク内において調停処理のマスタ及びスレーブのいずれであるかを判定する。ここで、第１の調停装置２３０１がマスタであるとは、第１の調停装置２３０１がネットワーク内の他のすべての調停装置から調停処理の要求を受信し、第１の調停装置２３０１内の調停部３０２で調停処理を実行することを意味する。また、第１の調停装置２３０１がスレーブであるとは、第１の調停装置２３０１がネットワーク内の他のいずれかの調停装置に対して調停処理の実行を要求する調停要求を送信し、調停結果を受信することを意味する。自機がネットワーク内のマスタ及びスレーブのいずれであるかは、予め決定されている。例えば、ユーザがあらかじめ操作端末１０１上で動作するアプリケーションを用いて、第１の調停装置２３０１及び第２の調停装置２３０２に対してマスタ及びスレーブのいずれであるかを設定するなど、種々の様態が可能である。

次に、ステップＳ１７２において、動作切替部２３０３は、ステップＳ１７１の判定の結果、自機が調停処理のマスタであるか否かを判定する。ここで、自機が調停処理のマスタであると判定された場合（ステップＳ１７２でＹＥＳ）、ステップＳ１７３において、調停部３０２は、複数の制御要求を調停する調停処理を実行して処理を終了する。ステップＳ１７３の調停処理は図１１及び図１２の処理と同様であるため、説明は省略する。

一方、ステップＳ１７２において自機が調停処理のマスタではないと判定された場合、すなわち自機が調停処理のスレーブであると判定された場合（ステップＳ１７２でＮＯ）、ステップＳ１７４において、調停要求送受信部２３０４は、第２の調停装置２３０２へ調停要求を送信する。調停要求は、少なくとも実行されたサービスのサービスＩＤと、制御要求そのものとを含む。サービスＩＤ及び制御要求の内容は、実施の形態１におけるサービスＩＤ及び制御要求と同様であるため説明は省略する。

次に、ステップＳ１７５において、第２の調停装置２３０２の調停要求送受信部２３０４は、第１の調停装置２３０１によって送信された調停要求を受信する。

次に、ステップＳ１７６において、調停部３０２は、複数の制御要求を調停する調停処理を実行する。ステップＳ１７６の調停処理は図１１及び図１２の処理とほぼ同様であるが、次の２点のみが異なる。まず、ステップＳ１１の処理が実行される前に、調停要求送受信部２３０４は、第１の調停装置２３０１から受信した調停要求に含まれるサービスＩＤ及び制御要求をサービス実行部３０１へ通知する。また、ステップＳ２５及びステップＳ２６の処理が実行されず、実行判定部３０２１は、調停結果送受信部２３０５へ調停結果を通知する。

次に、ステップＳ１７７において、第２の調停装置２３０２の調停結果送受信部２３０５は、第１の調停装置２３０１へ調停結果を送信する。

次に、ステップＳ１７８において、第１の調停装置２３０１の調停結果送受信部２３０５は、第２の調停装置２３０２によって送信された調停結果を受信して処理を終了する。

以上により、同一ネットワーク内に調停部３０２を備える複数の調停装置が存在する場合においても、複数の制御要求の調停を適切に行うことが可能となる。

なお、本実施の形態３の機器制御システムは、２つの調停装置を備えているが、本開示は特にこれに限定されず、３つ以上の調停装置を備えてもよい。

本開示にかかる調停方法、調停装置及び調停プログラムは、第１のサービスが第１の機器を占有する期間を、第１のサービスが実行されることによって変化する空間の環境に応じて設定することができ、競合する第１の制御要求と第２の制御要求とを調停することができ、機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停方法、調停装置及び調停プログラムとして有用である。

１０１ 操作端末
１０２ 通信網
１０３ 調停装置
１０４ 第１の機器
１０５ 第２の機器
２０１ プロセッサ
２０２ メモリ
２０３ 記憶部
２０４ 入出力部
２０５ 通信部
３０１ サービス実行部
３０２ 調停部
３０３ 機器制御部
３０４ サービス格納部
２３０１ 第１の調停装置
２３０２ 第２の調停装置
２３０３ 動作切替部
２３０４ 調停要求送受信部
２３０５ 調停結果送受信部
３０２１ 実行判定部
３０２２ 調停管理テーブル
３０２３ 状態監視テーブル
３０２４ 状態監視部
３０４１ サービス

Claims (19)

1. 機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停装置における調停方法であって、
   前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可し、
   前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得し、
   前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定し、
   前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない、
   調停方法。
2. 前記空間の状態が前記第１のサービスが満たすべき状態にあると判定された場合、前記第２の制御要求を受け付け、前記第２の制御要求に基づく第１の機器の制御を許可する、
   請求項１記載の調停方法。
3. 前記空間推定情報は、前記第１の機器から取得される、
   請求項１又は２記載の調停方法。
4. 前記空間推定情報は、前記第１の機器とは異なる第２の機器から取得される、
   請求項１又は２記載の調停方法。
5. 前記空間推定情報は、前記第１の制御要求に含まれる、前記第１の機器を制御するための制御対象項目と同じ種類の情報である、
   請求項１又は２記載の調停方法。
6. 前記空間推定情報は、前記第１の制御要求に含まれる、前記第１の機器を制御するための制御対象項目とは異なる種類の情報である、
   請求項１又は２記載の調停方法。
7. 前記空間推定情報は、前記空間の現在の状態を示す数値を含み、
   前記空間の状態が前記第１のサービスが満たすべき状態にあることを示す目標値の範囲に、前記数値が含まれるか否かを判定し、前記目標値の範囲に前記数値が含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
   請求項１又は２記載の調停方法。
8. 前記空間推定情報は、前記第１の制御要求に基づいて前記第１の機器の制御が開始されてから現在までの間における前記空間の状態の変化量を示す数値を含み、
   前記空間の状態が前記第１のサービスが満たすべき状態にあることを示す目標値の範囲に、前記数値が含まれるか否かを判定し、前記目標値の範囲に前記数値が含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
   請求項１又は２記載の調停方法。
9. 前記空間推定情報は、複数の機器の状態を示す情報であり、
   前記複数の機器のそれぞれから取得した前記空間推定情報のいずれもが所定の条件を満たすか否かを判定し、前記空間推定情報のいずれもが所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
   請求項１又は２記載の調停方法。
10. 前記空間推定情報は、複数の機器の状態を示す情報であり、
    前記複数の機器それぞれから取得した前記空間推定情報の少なくとも１つが所定の条件を満たすか否かを判定し、前記空間推定情報の少なくとも１つが所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
    請求項１又は２記載の調停方法。
11. 前記空間推定情報は、複数の機器の状態を示す数値であり、
    前記複数の機器それぞれから取得した前記数値の平均値が所定の条件を満たすか否かを判定し、前記数値の平均値が所定の条件を満たさないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
    請求項１又は２記載の調停方法。
12. 前記複数の機器は、同一の閉じた空間に設置されている、
    請求項９〜１１のいずれか１項に記載の調停方法。
13. 前記空間推定情報は、前記第１の制御要求に基づいて前記第１の機器の制御が開始されてから現在までの経過時間であり、
    前記経過時間が所定の範囲に含まれるか否かを判定し、前記経過時間が所定の範囲に含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
    請求項１又は２記載の調停方法。
14. 前記空間推定情報は、前記第１の制御要求に基づいて制御を開始した前記第１の機器の状態が所定の状態に達してから現在までの経過時間であり、
    前記経過時間が所定の範囲に含まれるか否かを判定し、前記経過時間が所定の範囲に含まれないと判定された場合、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定される、
    請求項１又は２記載の調停方法。
15. 前記第１のサービスの内容を定義するサービス定義情報は、前記第１のサービスが満たすべき前記空間の状態を定義する条件定義情報を含み、
    前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、前記サービス定義情報に含まれる前記条件定義情報を用いて判定する、
    請求項１又は２記載の調停方法。
16. 前記第１の制御要求は、前記第１のサービスが満たすべき状態を定義する条件定義情報を含み、
    前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、前記第１の制御要求から取得した前記条件定義情報を用いて判定する、
    請求項１又は２記載の調停方法。
17. 前記第１のサービスが満たすべき状態を定義する条件定義情報のユーザによる入力を受け付け、
    前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを、受け付けられた前記条件定義情報を用いて判定する、
    請求項１又は２記載の調停方法。
18. 機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停装置であって、
    前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可する制御許可部と、
    前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する取得部と、
    前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定する判定部と、を備え、
    前記制御許可部は、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない、
    調停装置。
19. 機器に対してそれぞれ異なる複数のサービスを実行させるために送信される複数の制御要求を調停する調停プログラムであって、
    コンピュータを、
    前記複数のサービスのうちの第１のサービスを実行させるための第１の制御要求を受け付け、前記第１の制御要求に基づく第１の機器の制御を許可する制御許可部と、
    前記第１のサービスの継続又は終了に関連する空間の状態を推定するための空間推定情報を取得する取得部と、
    前記空間推定情報に基づき推定される前記空間の状態が前記第１のサービスが満たすべき状態にあるか否かを判定する判定部として機能させ、
    前記制御許可部は、前記空間の状態が前記第１のサービスが満たすべき状態にないと判定された場合、前記第１のサービスとは異なる第２のサービスを前記第１の機器に実行させるための第２の制御要求を受け付けない、
    調停プログラム。

Images