JPWO2019172046A1 - 機器管理方法、及び、機器管理システム - Google Patents

Abstract

複数の機器（１１〜１４）、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器（４２）とネットワークを介して通信接続されているサーバ（２０）において行われる機器管理方法であって、複数の機器のうちの第１機器（１１）を識別する第１機器識別子と第１ユーザ識別子との対応付けの要求を第１操作機器から受け付ける受け付けステップと、記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）第１機器識別子に、第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）第１ユーザ識別子に、複数の機器のうちの第１機器とは異なる第２機器（１２）を識別する第２機器識別子が対応付けられている場合、第２機器識別子と第２ユーザ識別子とを対応付けて記憶する記憶ステップ（Ｓ７１）と、を含む。

Description

本開示は、機器管理方法、及び、機器管理システムに関する。

近年、生活家電（機器ともいう）が、当該機器を制御するクラウドである家電制御クラウド（制御クラウドともいう）にネットワークを介して接続され、制御クラウドによる制御の下で動作する形態がある（特許文献１参照）。

特開２０１６−６３５２０号公報

制御クラウドによる制御の下では、ユーザは、例えば、スマートフォンなどの操作機器を用いて機器の操作を行うことができる。また、このように操作機器を用いて機器を操作するためには、制御クラウド上においてユーザの操作対象となる機器を認識する必要がある。つまり、制御クラウドは、ユーザを識別するユーザ識別子と、機器を識別する機器識別子とを対応付けることで、ユーザと機器とを対応付ける必要がある。

しかし、ユーザは、ユーザ識別子と機器識別子とを対応付けを制御クラウドにおいて設定する必要があり、ユーザが所有している複数の機器全てとユーザとを対応付ける作業に手間がかかるという課題があった。

そこで、本開示は、ユーザと機器との対応付けを効率よく行うことができる機器管理システムなどを提供する。

本開示の一態様に係る機器管理方法は、複数の機器、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器とネットワークを介して通信接続されているサーバにおいて行われる機器管理方法であって、前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受け付けステップと、記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第１ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第２機器を識別する第２機器識別子が対応付けられている場合、前記第２機器識別子と前記第２ユーザ識別子とを対応付けて記憶する記憶ステップと、を含む。

なお、これらの全般的または具体的な態様は、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本開示の機器管理方法は、ユーザアカウントと機器との対応付けを効率よく行うことができる。

図１は、生活家電の進化を示す説明図である。 図２は、第三世代の生活家電のアーキテクチャと外部サービス連携の例を示す説明図である。 図３は、第三世代の生活家電のアーキテクチャとＡＩスピーカー連携の例を示す説明図である。 図４は、第三世代の生活家電の第一の課題を示す説明図である。 図５は、第三世代の生活家電の第二の課題を示す説明図である。 図６は、ネット接続機能内蔵家電のネット接続率を示す説明図である。 図７は、クラウド生活家電のネット接続などを示す説明図である。 図８は、常時接続ＩｏＴ生活家電で利用可能な通信方式（Ｗｉ−Ｆｉ、ＬＰＷＡ）の特徴を示す表である。 図９は、第四世代の生活家電（常時接続ＩｏＴ家電）のアーキテクチャと外部サービス連携を示す第一の説明図である。 図１０は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第二の説明図である。 図１１は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第三の説明図である。 図１２は、生活家電のアーキテクチャの進化を示す図である。 図１３は、第四世代の生活家電の機能分担（機能の外部化）について説明するための図である。 図１４は、４層の顧客接点と常時接続ＩｏＴ家電との関係を示す図である。 図１５は、機器管理システムにおける家電機器の稼働状態データの収集フローを示す図である。 図１６は、クラウドが受信する家電機器の稼働情報および固有情報の具体例を示す表である。 図１７は、ＩｏＴ家電である機器のブロックを示す構成図である。 図１８は、ＩｏＴ家電制御クラウドであるサーバのブロックを示す構成図である。 図１９は、機器が一般家庭へ設置されたことを検知する方法について説明するためのグラフである。 図２０は、機器が一般家庭へ設置されたことを検知する方法について説明するためのグラフである。 図２１は、除外範囲を、複数の機器から送信される稼働情報および位置情報を用いて決定する例を示す図である。 図２２は、機器を設置の際のログ送信の同意を得るための処理を示すフローチャートである。 図２３は、ＩｏＴ家電サービスを利用するまでの手順の一例を示すフローチャートである。 図２４は、機器とユーザとの紐付け手順の第１の例を説明するための図である。 図２５は、機器とユーザとの紐付け手順の第１の例を示すフローチャートである。 図２６は、機器とユーザとの紐付け手順の第１の例を示すシーケンス図である。 図２７は、機器とユーザとの紐付け手順の第２の例を示すフローチャートである。 図２８は、機器とユーザとの紐付け手順の第２の例を示すシーケンス図である。 図２９は、複数の機器と複数のユーザとの紐付けの方法の一例の第１の場面を説明するための図である。 図３０は、複数の機器と複数のユーザとの紐付けの方法の一例の第２の場面を説明するための図である。 図３１は、複数の機器と複数のユーザとの紐付けの方法の一例の第３の場面を説明するための図である。 図３２は、同一の機器ＩＤに異なるユーザアカウントの紐付けが行われる場合に行われる紐付け処理の一例を示すシーケンス図である。 図３３は、同一の機器ＩＤに異なるユーザアカウントの紐付けが行われる場合に行われる紐付け処理において操作機器への通知を示す情報の一例を示す図である。 図３４は、複数の機器と複数のユーザとの紐付けの方法の一例の第４の場面を説明するための図である。 図３５は、複数の機器と複数のユーザとの紐付け方法の別の一例を説明するための図である。 図３６は、「引っ越し」および「譲渡」を判別する処理の一例を示すフローチャートである。 図３７は、「引っ越し」および「譲渡」を判別する処理の他の一例について説明するための図である。 図３８は、「引っ越し」および「譲渡」を判別する処理の他の一例を示すフローチャートである。 図３９は、「引っ越し」および「譲渡」を判別する処理の他の一例について説明するための図である。 図４０は、「引っ越し」および「譲渡」を判別する処理の他の一例を示すフローチャートである。 図４１は、「引っ越し」が予想されるケースの例外について説明するための図である。 図４２は、機器の種別に応じてカテゴリ分けした表である。 図４３は、機器が「譲渡・転売・盗難」の予測ケースの一例を示すグラフである。 図４４は、機器が盗難された際の対策を実行する処理のフローチャートである。 図４５は、機器の移動を検知した際のユーザと機器との紐付け処理の一例を示すフローチャートである。 図４６は、機器の移動を検知した際のユーザと機器の紐付け処理の他の一例を示すフローチャートである。 図４７は、ユーザの「家族構成変更」が為されたと予測されるケースの一例を示すグラフである。 図４８は、機器が「故障」したと予測されるケースの一例を示すグラフである。 図４９は、機器が「廃棄」されたと予測されるケースの一例を示すグラフである。

本開示の一態様に係る機器管理方法は、複数の機器、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器とネットワークを介して通信接続されているサーバにおいて行われる機器管理方法であって、前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受け付けステップと、記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第１ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第２機器を識別する第２機器識別子が対応付けられている場合、前記第２機器識別子と前記第２ユーザ識別子とを対応付けて記憶する記憶ステップと、を含む。

これによれば、第１機器識別子と第１ユーザ識別子との対応付けの要求を受け付けた場合、記憶装置に記憶されている対応関係を用いて、第２機器識別子と第２ユーザ識別子とを対応付けて記憶する。このため、ユーザと機器との対応付けを効率よく行うことができる。

また、前記記憶ステップでは、前記対応関係において、前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられている場合、前記第２ユーザ識別子で識別される第２ユーザが、前記第１ユーザが属する第１ユーザグループのメンバであるか否かを確認する第１の問い合わせを前記第１操作機器に送信し、送信された前記第１の問い合わせに対する第１の応答を受信し、受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶してもよい。

また、前記記憶ステップでは、受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されなかったことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子との対応付けと、前記第２機器識別子と前記第２ユーザ識別子との対応付けをしないとしてもよい。

これによれば、第１の問い合わせへの結果である第１の応答に応じて、第１機器識別子と第１ユーザ識別子とを対応付けるため、望ましくない対応付けの要求を受け付けないようにすることができる。

また、前記記憶ステップでは、さらに、受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１ユーザが、前記第２ユーザが属する第２ユーザグループのメンバであるか否かを確認する第２の問い合わせを送信し、送信された前記第２の問い合わせに対する第２の応答を受信し、受信された前記第２の応答が、前記第１ユーザが、前記第２ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶してもよい。

また、前記記憶ステップでは、受信された前記第２の応答が、前記第１ユーザが前記第２ユーザグループのメンバであることが承認されなかったことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子との対応付けと、前記第２機器識別子と前記第２ユーザ識別子との対応付けをしないとしてもよい。

これによれば、第２の問い合わせへの結果である第２の応答に応じて、第１機器識別子と第１ユーザ識別子とを対応付けるため、望ましくない対応付けの要求を受け付けないようにすることができる。

また、前記記憶ステップは、前記対応関係において、前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられている場合、前記第２ユーザ識別子で識別される第２ユーザが前記第１ユーザと同一人物であるか否かを確認する第３の問い合わせを前記第１操作機器に送信し、送信された前記第３の問い合わせに対する第３の応答を受信し、受信された前記第３の応答が、前記第１ユーザと前記第２ユーザとが同一人物であることが承認されたことを示す応答を含む場合、前記第１ユーザ識別子と前記第２ユーザ識別子とを対応付けて記憶してもよい。

このため、ユーザが同一人物であるか否かを問い合わせるため、同一人物であると対応付けられた機器から得られた情報を、個々のユーザに最適になるように当該機器を制御することに利用することができる。

また、前記記憶ステップでは、さらに、前記対応関係において、前記複数の機器のうちの前記第１機器および前記第２機器とは異なる第３機器を識別する第３機器識別子と前記第２ユーザ識別子とが対応付けられている場合、前記第３機器識別子と前記第１ユーザ識別子とを対応付けて記憶してもよい。

このため、ユーザと機器との対応付けをさらに効率よく行うことができる。

また、複数の機器、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器とネットワークを介して通信接続されているサーバにおいて行われる機器管理方法であって、前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受け付けステップと、記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第２ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第３機器を識別する第３機器識別子が対応付けられている場合、前記第３機器識別子と前記第１ユーザ識別子とを対応付けて記憶する記憶ステップと、を含んでもよい。

これによれば、第１機器識別子と第１ユーザ識別子との対応付けの要求を受け付けた場合、記憶装置に記憶されている対応関係を用いて、第３機器識別子と第１ユーザ識別子とを対応付けて記憶する。このため、ユーザと機器との対応付けを効率よく行うことができる。

また、前記受け付けステップでは、前記第１操作機器から前記第１ユーザ識別子を受信し、かつ、前記第１機器または前記第１操作機器から前記第１機器に関する機器関連情報を受信することで、前記要求を受け付け、前記記憶ステップは、取得された前記機器関連情報に基づいて前記第１機器を特定し、特定された前記第１機器に、前記ネットワークを介して第４の問い合わせを送信し、送信された前記第４の問い合わせに対する第４の応答を前記第１機器または前記第１操作機器から受信した場合に、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶し、前記第４の応答を受信しない場合に、前記第１機器識別子と前記第１ユーザ識別子との対応付けを行わないとしてもよい。

このため、機器とユーザとの対応付けを精度よく行うことができる。

また、前記複数の機器のそれぞれは、遠距離無線通信の基地局を介して前記ネットワークに通信接続されており、前記第１機器への前記第４の問い合わせの送信では、前記基地局を介して前記第１機器に前記第４の問い合わせを送信してもよい。

このため、機器は、遠距離無線通信の基地局を介して第４の問い合わせを受信できる。

また、前記遠距離無線通信は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）による通信であってもよい。

このため、機器は、ＬＰＷＡの基地局を介して第４の問い合わせを受信できる。

なお、これらの全般的または具体的な態様は、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

以下、適宜図面を参照しながら、実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。

なお、発明者は、当業者が本開示を十分に理解するために添付図面および以下の説明を提供するのであって、これらによって請求の範囲に記載の主題を限定することを意図するものではない。

以降において、本発明に至る背景、及び、本発明により解決すべき課題を詳細に説明した後で、実施の形態を説明する。

（本発明に至る背景）
図１は、生活家電の進化を示す説明図である。

図１に生活家電（洗濯機、冷蔵庫等の白物家電とエアコン、加湿空気清浄機等）のアーキテクチャの進化を示す。

第一世代（１９９０年以前）の生活家電機器は、コンプレッサ、モータ等のハードウェアを、ＬＳＩ（Ｌａｒｇｅ−ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等で作った制御ロジックにより実現していたため、単機能の製品となっていた。

第二世代（１９９０年以降２０１０年くらいまで）のマイコン内蔵生活家電機器には、マイコンが導入され、マイコンのソフトウェアを作成することにより、複雑な制御が可能になったことにより、多機能な家電が実現できた。しかしながら、出荷後マイコンを変更することで機能を変更、追加することはできなかった。

第三世代（２０１２年以降）のクラウド家電は、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）（以下ＢＴとする）等の通信機能を持ち、ホームＧＷ（ゲートウェイ）とブロードバンド回線網とを経由してＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）家電制御クラウドに接続可能になった。このため、出荷後もクラウドから本体内のマイコンのソフトウェアを更新することもできるようになった。マイコンのソフトウェアは更新しないで、クラウド側の該当機器の制御機構を更新すること等により、出荷後も機能追加、更新を行うことができるようになった。ここで、ＩｏＴ家電制御クラウドとは、ブロードバンド回線網などの通信路を通じて家電機器を制御するクラウド（サーバとネットワークとの集合体）であり、クラウド型のサービスの１つである。

図２は、第三世代の生活家電のアーキテクチャと外部サービス連携の例を示す説明図である。

第三世代のクラウド生活家電（洗濯機、冷蔵庫等の白物家電とエアコン、加湿）の場合は、スマートフォンのＡＰＰｓ（アプリケーション）からＩｏＴ家電制御クラウドの各生活家電制御機構を経由して、家庭内の各生活家電にアクセスすることが可能になる。

このため、ユーザは、スマートフォンのＡＰＰｓを用いることで、各生活家電の動作状況の遠隔監視、遠隔動作制御（起動、停止、温度調節、洗剤投入等）などをすることができる。また、ＥＣサービスクラウド又は見守りサービスクラウド等の外部サービス群と、ＩｏＴ家電制御クラウド内の各生活家電制御機構とが連携することにより、各種クラウドサービスから生活家電を制御したり、生活家電の動作情報（ログ等）を取り出し、それを外部サービスで利用したりすることが可能になる。

図３は、第三世代の生活家電のアーキテクチャとＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ、人工知能）スピーカー連携の例を示す説明図である。

第三世代のクラウド生活家電（洗濯機、冷蔵庫等の白物家電とエアコン、加湿）の場合は、音声対話機能を実現するＡＩスピーカーから、ホームＧＷ経由でクラウド内のＡＩスピーカー制御機構にアクセスし、そのＡＩスピーカー制御機構が各生活家電制御機構にアクセスすることで、ユーザがＡＩスピーカーから音声対話で各生活家電を遠隔制御することも可能になる。

（解決すべき課題）
図４は、第三世代の生活家電の第一の課題を示す説明図である。第一の課題は、Ｗｉ−Ｆｉ ＧＷがない家庭では、第三世代の家電の機能を使うことができない、という課題である。

ある家庭が第三世代のクラウド生活家電（洗濯機、冷蔵庫等の白物家電とエアコン、加湿）を購入した場合でも、その家庭にＷｉ−Ｆｉ等のホームＧＷがなくブロードバンド回線網に接続できない場合は、クラウド家電がＩｏＴ家電制御クラウドに接続できない。この場合、ＩｏＴ家電制御クラウドから家電にアクセスすることが不可能なため、第三世代の生活家電が掲げる、購入後のクラウド側での機能進化による商品付加価値向上という目的を達成することができない。そのため、ＩｏＴ家電でありながら製造時に機能が固定されていた従来型の第二世代生活家電（マイコン生活家電）としてしか使用できない。

図５は、第三世代の生活家電の第二の課題を示す説明図である。第二の課題は、Ｗｉ−Ｆｉ ＧＷが家庭にあってもユーザが第三世代の生活家電をＷｉ−Ｆｉ ＧＷに接続しない、という課題である。

スマートフォン、タブレット、ＰＣ等の情報機器、又は、ＡＩスピーカーは、Ｗｉ−Ｆｉ等によるインターネット接続機能がないと、ユーザがその製品に望む本来の機能が使えない。また、スマートフォン又はＡＩスピーカーには、インターネットに接続し、ユーザ情報（メールアドレス、アカウント等）を設定しないと、そもそも使えない機器もある。ユーザはそれらの機能を使いたいためにその機器を購入したため、ユーザは必ずユーザＩＤ設定又はＷｉ−Ｆｉ設定を行い、インターネットに接続させる。

スマートＴＶの場合も、Ｙｏｕｔｕｂｅ、Ｎｅｔｆｌｉｘ、Ａｍａｚｏｎ Ｐｒｉｍｅ Ｖｉｄｅｏ等の映像配信サービスが普及しており、これらの映像コンテンツを大画面ＴＶで視聴するために、ユーザ（もしくは設置業者）がＷｉ−Ｆｉの設定を行うことが多い。

クラウド生活家電の場合は、ユーザが面倒なＷｉ−Ｆｉ設定を行ったことで利用可能になるインターネットサービスが判り難かったり、このインターネットサービスの利用価値性がユーザにとって必要な機能と思えなかったりするため、ユーザは最初からインターネット接続設定を行わないことが多い。

また、購入直後において、ユーザは、Ｗｉ−Ｆｉ設定を行うが、インターネットサービスの利便性が比較的高くないと考えた場合、折角接続したものを解除する、または、何らかの理由で接続が切れても再接続しないことが多い。

従って、情報機器とＡＩスピーカーとについてはほぼ１００％接続が期待できるため、インターネットに接続されることを前提に各種クラウドサービスを開発することが可能であるが、ＴＶ又は生活家電の場合は、１００％の接続率はほぼ期待されない。

図６は、ネット接続機能内蔵家電（ＡＶと生活家電）のネット接続率を示す説明図である。

前述のクラウド生活家電は、Ｗｉ−Ｆｉ又はＢｌｕｅｔｏｏｔｈなどの通信手段が実装されることによって、ＩｏＴ家電制御クラウドへの接続が実現され、各種クラウドサービスを利用することで、マイコン生活家電にない顧客価値を提供できる。このため、Ｗｉ−Ｆｉ等の通信手段をクラウド生活家電に実装することによるコスト増加を上回る顧客価値を提供できることで顧客満足度を向上させることができる。

しかしながら、前述の通信手段は、以下に示すような多くのケースで機器を保有するユーザによる設定がなされないという課題、つまりはクラウド生活家電がクラウドへ接続されないと、マイコン生活家電と同じ顧客価値しか提供できないという課題がある。

（１）Ｗｉ−Ｆｉを接続するためには、ユーザは宅内にＷｉ−Ｆｉのアクセスポイントを用意する必要がある。しかしながら、インターネットの接続はスマートフォンからしか行わないユーザ、つまり通信キャリアが用意する通信網しか使用しないユーザにとってＷｉ−Ｆｉのアクセスポイントを宅内に保有していないケースがある。

（２）Ｗｉ−Ｆｉのアクセスポイントが宅内に存在していたとしても、家電の接続設定の煩雑さ、例えばＷｉ−Ｆｉのパスワード入力を筆頭とする接続作業のために、万人が容易にＷｉ−Ｆｉの接続設定を出来るとは言い難い。

実際、図６のように２０１７年の日本市場でのクラウド対応ＴＶ又はクラウド生活家電のネットワーク接続率は、５０％以下に留まり、多くのユーザがクラウド生活家電をマイコン生活家電として使っていることがわかる。

図７は、クラウド生活家電のネット接続などを示す説明図である。

クラウド生活家電がクラウドに接続されていない場合、ＩｏＴ家電制御クラウドからクラウド生活家電にアクセスすることが不可能である。このため、クラウド生活家電で実現可能な、購入後のクラウド側での機能進化による商品付加価値向上機能を利用することができない。

そのため、クラウド生活家電でありながら、製造時に機能が固定されていた従来型のマイコン生活家電と同等の機能しか使えない。

本来のクラウド生活家電であれば、万が一リコールなどが発生した際にも対象家電に対して緊急停止指示、リモートファーム更新、又は、ユーザへのメール通知などの対応を取ることができる。しかし、接続率の低い、現状では、製造メーカは、これらのＩｏＴ家電制御クラウドから、クラウド生活家電を制御する機能をつかうことができないことが多い。このため、対象クラウド生活家電の全部に対して、遠隔監視、制御ができれば実現可能な、リモートメンテナンス又はリコール通知等の機能が十分機能しない。

そこで、Ｗｉ−Ｆｉ又はＢＴ等の通信手段が実装されたクラウド生活家電が、実際にはクラウドへ接続されづらい状況もあるなか、家電以外の機器又はセンサをＩｏＴ化するための様々な通信手段が利用可能になってきた。

特に、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）と総称されるＩｏＴ向け利用に特化して開発された無線通信手段が実用化され、ＩｏＴ時代に適した通信方式として注目されている。

ＬＰＷＡ無線の特徴は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べ、小規模の半導体実装により端末コストを削減できることと、非常に長い通信距離（〜１０ｋｍ）が得られる低レート変調により基地局数を削減できることとによって、無線回路とインフラ設備との両方の低コスト化を実現したことである。反面、伝送レートを下げて受信感度を改善する手法を取っているため、伝送できるデータ量は小さい。

ＬＰＷＡ無線を家電機器に搭載することにより、利用者がインターネット回線を契約する必要がなくなり、家電機器が直接的に基地局に接続されて、クラウドサーバに接続したサービスを非常に低コストに実現できる可能性がある。

ＬＰＷＡは、セルラーＬＰＷＡとノンセルラーＬＰＷＡとに分類される。セルラーＬＰＷＡは、セルラーキャリアに割り当てられた周波数バンド（ライセンスバンド）を用い、セルラー回線（ＬＴＥなど）の１つとして提供されるものである。

ノンセルラーＬＰＷＡは、各国に存在するノンライセンスバンドを用いてチャネル使用費用が不要となることを利用してＬＰＷＡ無線を使用するものである。ノンライセンスバンドは他の無線システムとの共用利用となるため、チャネルを独占しないための制限が各国の電波法で規定されている。

以下に代表的なＬＰＷＡ方式について述べる。

図８は、常時接続ＩｏＴ生活家電で利用可能な通信方式（Ｗｉ−Ｆｉ、ＬＰＷＡ）の特徴を示す表である。

（１）セルラーＬＰＷＡ
（１−１）ＮＢ−ＩｏＴ
ＧＳＭ（登録商標）（２Ｇ）方式を起源とし、低伝送レート化とＬＴＥ通信シーケンスの優位性を適用し、ＩｏＴ向けのデータ伝送に特化した仕様となっている。チャンネル間隔をＧＳＭと同じ２００ｋＨｚにすることで、ＧＳＭチャネルへの置換え運用を容易にしている。上り送信のピークレートを６２．５ｋｂｐｓと低速化し、また複数回の繰返し送信（６４回）で蓄積受信することで、感度点の改善を行っている。最大リンクバジェットは１３０ｄＢと大きい。また、送信電力を１００ｍＷ（ＧＳＭは２Ｗ）に抑える仕様とし、ピーク電流を抑えて電池１本での運用を可能としている。

（１−２）ＬＴＥ−Ｍ（ＣＡＴ−Ｍ）
ＬＴＥ（４Ｇ）方式を起源とし、ＬＴＥの最小チャネル間隔（１．４ＭＨｚ）を用いて通信を行う方式である。ＬＴＥのスロット構成に準拠しているため、従来ＬＴＥの通信スロットに混在させて運用することができる。上り送信のピークレートを１Ｍｂｐｓと低速化し、繰り返し送信で蓄積受信することで、感度点の改善を行っている。最大リンクバジェットは１３０ｄＢである。

伝送レートがやや高いため、電池駆動時の消費電力が最も小さい。送信電力は２００ｍＷである。

（２）ノンセルラーＬＰＷＡ
（２−１）ＬｏＲａ
従来の小電力無線バンド（ＩＳＭバンド）を用いるが、超低レート変調により受信感度を改善している。超低レート変調の実現方法は、ＬｏＲａチャープ変調と呼ばれる特殊な拡散変調を用いる。ＬｏＲａチャープ変調の特徴は、２５０ｂｐｓの低伝送レートと拡散帯域１２５ｋＨｚとを実現し、妨害ノイズに強く高感度が得られることである。また、同一帯域幅で複数のデータレートを選択でき、これらを同一チャネルで同時に受信できるので、通信容量のキャパシティが改善される。最大リンクバジェットは１４９ｄＢである。送信電力は２０ｍＷである。

従来の小電力無線の特徴（小電力、小電流ピーク）を継承しており、電池１本で１０年駆動又はコイン電池での駆動が可能である。

ＬｏＲａ Ａｌｌｉａｎｃｅで仕様を統一し、事業者間の相互接続を可能とした。

（２−２）ＳＩＧＦＯＸ
従来の小電力無線バンド（ＩＳＭバンド）を用いるが、超低レート変調により受信感度を改善している。超低レート変調の実現方法は、狭帯域ＦＳＫ変調であり、基地局側でデジタル復調処理を工夫することで、周波数誤差の問題を克服した。ＳＩＧＦＯＸ変調では、上り１００ｂｐｓ、下り６００ｂｐｓの固定レートとなる。周波数を変えた複数回送信をすることで妨害ノイズの影響を回避している。固定レートおよび同時多重受信不可のため、通信容量のキャパシティは比較的小さい。最大リンクバジェットは１５８ｄＢである。送信電力は２０ｍＷである。

ＳＩＧＦＯＸは、従来の小電力無線の特徴（小電力、小電流ピーク）を継承しており、電池１本で１０年駆動又はコイン電池での駆動が可能である。

ＳＩＧＦＯＸ独自仕様となり、基地局をＳＩＧＦＯＸ１社で独占する形態をとる。

ＳＩＧＦＯＸは、片方向通信しかできないため、センサ系ＩｏＴには使えるが、ＩｏＴ生活家電には適さない。

図８に示されるように、常時接続ＩｏＴ生活家電を実現するためには、ＬＰＷＡ技術とＷｉ−Ｆｉとの組み合わせが適切と考えられる。しかしながら、上述したような３方式のＬＰＷＡの特質はそれぞれ異なるため、通信品質を重視すればコストが高くなり、反対にコストを重視すると通信品質が悪く安定的な通信が確保できないリスクがある。このため、常時接続ＩｏＴ家電が１つの方式のＬＰＷＡを選択することは難しい。

（実施の形態）
以降において、適切に制御クラウドに接続され、制御され得る機器について説明する。

図９は、第四世代の生活家電（常時接続ＩｏＴ家電）のアーキテクチャと外部サービス連携を示す第一の説明図である。生活家電は、例えば、洗濯機、冷蔵庫等の白物家電とエアコン、加湿空気清浄機であり、単に機器ともいう。

第三世代の生活家電の課題を解決するためには、生活家電を利用する全てのユーザがＷｉ−Ｆｉ ＧＷを持ち、生活家電をインターネットに接続し継続的に利用したいと思わせるサービス開発を行い、かつ、簡単にＷｉ−Ｆｉ設定をできるようにする必要があった。

しかし、近年多様な通信手段の台頭により従来よりも簡単に家電をクラウドに接続できる、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）と総称される通信手段が提唱され、注目されている。

ＬＰＷＡの特徴は、ユーザが設定することなく利用することができ、非常に長い通信距離（〜１０ｋｍ）を実現し、電波の届くところなら必ず基地局につながることである。

第四世代の生活家電（常時接続ＩｏＴ家電）においては、ＬＰＷＡを生活家電に搭載することにより、ユーザがＷｉ−Ｆｉ ＧＷを用意し、面倒なＷｉ−Ｆｉ設定をすることなく、クラウドと接続することが可能となり、購入後のクラウド側での機能拡張などが可能となる。

図１０は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第二の説明図である。

ＬＰＷＡは、前述の通り優れた特徴を持つ反面、伝送レートを下げて受信感度を改善する手法を取っているため、伝送できるデータ量はＷｉ−Ｆｉ又はＬＴＥなどに比べて小さい。そのため、第四世代の生活家電（以下、「常時接続ＩｏＴ家電」とも言う。）においてはＬＰＷＡだけでなく、第三世代の生活家電同様Ｗｉ−Ｆｉも併せ持つことで用途に応じた適切な通信を可能とする。

図１１は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第三の説明図である。

第三世代の生活家電の大きな課題の一つであった、ユーザに面倒なＷｉ−Ｆｉ設定を強いるという点も、以下に例を示すようにＬＰＷＡをＷｉ−Ｆｉ設定に活用することで設定を簡単にすることができる。

（１）クラウドにＷｉ−Ｆｉ設定を入力し、第四世代の生活家電はＬＰＷＡを利用して、クラウドからＷｉ−Ｆｉ設定を取得しＷｉ−Ｆｉ ＧＷに接続する。

（２）一台の第四世代の生活家電にＷｉ−Ｆｉ設定を入力し、ＬＰＷＡ経由で、宅内他機器に送信、他機器はその設定を用いてＷｉ−Ｆｉ ＧＷに接続する。

図１２は、生活家電のアーキテクチャの進化を示す図である。

第一世代（１９９０年以前）の生活家電機器は、例えばコンプレッサ、モータ等のメカニクスと制御ロジックとにより実現された単機能製品である。

第二世代（２０１０年くらいまで）の生活家電機器は、マイコンを内蔵しており、マイコンにマイコンソフトを実行させることにより、複雑な制御が可能となった。このため、第二世代の生活家電機器は、多機能である。ただし、第二世代の生活家電機器は、出荷後において、マイコンソフトを変更することで機能を変更したり、追加したりすることは困難であった。

第三世代（２０１２年以降）のクラウド家電は、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ等の通信機能を持ち、ホームＧＷとブロードバンド回線網とを経由してＩｏＴ家電制御クラウドに接続可能になった。このため、クラウド家電は、出荷後であってもＩｏＴ家電制御クラウドから本体内のマイコンソフトを更新することも、マイコンソフトを更新しないで、クラウド側の該当機器の制御機構を更新すること等により、機能の追加または機能の更新を行うことができるようになった。ただし、Ｗｉ−Ｆｉ等では、出荷された全製品を接続することが難しく、クラウド機能が使えない場合が多かった。

第四世代（２０２０年以降）ＬＰＷＡ等の常時接続機能を搭載した常時接続ＩｏＴ家電では、出荷された全製品を接続することができるため、クラウドの機能がすべての製品で利用可能になると考えられている。

図１３は、第四世代の生活家電の機能分担（機能の外部化）について説明するための図である。

第四世代のクラウド生活家電（洗濯機、冷蔵庫等の白物家電とエアコン、加湿空気清浄機等）の場合は、生活家電と、クラウド（サーバ）と、スマートフォン等のＵＩ機器との間を常時接続機能で繋ぐことで、クラウドと、スマートフォンと、生活家電などの機器とに機能分担（機能の外部化）を実現することができる。このため、機器が出荷された後も、クラウド側で機能変更や追加を行うことで、生活家電の機能・性能改善が可能となる。

また、第四世代のクラウド生活家電では、出荷された製品の全数の常時接続を容易に実現できるため、出荷後も全製品の遠隔監視および遠隔制御が可能となる。このため、品質保証機能の大幅改善が期待できる。また、不幸にも製品をリコールするような事態になっても、クラウドは、出荷後も機器と通信接続され、トレースできるため、リコールの対象製品に対し、故障の告知、強制停止等の対応を実行できる。このため、リコール費用の大幅低減が可能となる。

図１４は、４層の顧客接点と常時接続ＩｏＴ家電との関係を示す図である。

携帯キャリアは、フィーチャーフォンで完璧なプラットホーム（機器ＩＤ、個人情報、位置情報、決済手段等）を構築した。

次に、携帯音楽プレーヤー、スマートフォンなどの登場により、クラウドサービス側を奪取され、携帯キャリアにより構築されたエコシステムが弱体化した。

将来では、常時接続に対応する第四世代の常時機器ＩｏＴ家電の登場により、クラウドに常時接続できる機器ＩＤ（クラウド連携ＩＤ）を確保することで、顧客接点の取得に活用することができると考えられる。

図１５は、機器管理システムにおける家電機器の稼働状態データの収集フローを示す図である。図１６は、クラウドが受信する家電機器の稼働情報および固有情報の具体例を示す表である。

図１５に示されるように、機器管理システム１は、サーバ２０と、基地局３０と、複数の機器１０とを備える。

サーバ２０は、インターネットなどのネットワークに通信接続されており、ＩｏＴ家電制御クラウドとして機能する。サーバ２０の詳細な機能については後述する。

基地局３０は、例えばＬＰＷＡ基地局であり、ＩｏＴ家電がネットワークに常時接続するための遠距離無線通信に用いられる基地局である。図１５では、１つの基地局３０が図示されているが、機器管理システム１は、複数の基地局３０を備える。

複数の機器１０のそれぞれは、上述した第四世代の生活家電、つまり、常時接続ＩｏＴ家電であり、複数の基地局３０のうちの一の基地局３０に通信接続する。各機器１０は、当該機器１０の現在の稼働状態を示す稼働状態データ（以下、「稼働情報」とも言う。）を、当該機器１０に内蔵されているＬＰＷＡ通信モジュールを用いて、一の基地局３０を経由してサーバ２０に逐次送信する。

なお、稼働情報は、図１６に示されるように、「機器固有ＩＤ」、「通信モジュールＩＤ」、「通信モジュール種別」、「送信日時」、「電源状態」、「稼働回数のカウント開始日時」、「稼働回数」などのデータ項目を含む。稼働情報は、これらのデータ項目以外にもソフトウェアのバージョン情報、部材変更があった場合などはその差分情報を管理する情報、設定されているメニュー項目、モード設定などの情報を含んでいてもよい。これにより、サーバ２０は、機器１０がどのような状態で動作しているのかをより正確に管理することができる。また、稼働情報に含まれるデータ項目は、優先度や送信頻度が設定されていてもよく、データ送信時に毎回記載する項目、週に一度だけ記載する項目、変化があった場合のみ記載する項目など差をつけることで送信データサイズを削減してもよい。特に、通信モジュールが外部電源ではなく、内部のバッテリで動作しているケースなどでは消費電力を抑えるために重要なデータ項目だけ送信するなどの使い方が有用である。

次に、基地局３０は、稼働情報を逐次受信すると、逐次受信された稼働情報と共に当該基地局３０に固有の情報である固有情報をサーバ２０に逐次送信する。ここで、基地局３０が稼働情報を転送する際に、稼働情報と共に送信される固有情報は、図１６の表の最下段に示されるように、固有情報を送信する基地局３０が設置されている位置を示す位置情報である。また、固有情報は、位置情報に限らずに、基地局３０を識別する識別子であってもよい。以下では、固有情報として位置情報を例にして説明する。

次に、機器１０およびサーバ２０の構成についてそれぞれ説明する。

図１７は、ＩｏＴ家電である機器１０のブロックを示す構成図である。

図１７に示されるように、機器１０は、通信モジュール１０１と、制御部１０４と、機能モジュール１０７と、保持部１０８と、電源部１０９と、バッテリ１１０と、操作部１１１と、表示部１１２とを備える。

通信モジュール１０１は、機器１０を管理するサーバ２０に、互いに異なる複数の回線網を介して接続する。通信モジュール１０１は、例えば、ＬＰＷＡなどの遠距離無線通信を行うための通信モジュールである。なお、通信モジュール１０１は、図８を用いて説明した、３方式のＬＰＷＡおよびＷｉ−Ｆｉのうちの少なくとも１方式のＬＰＷＡを行う通信モジュールを含んでいてもよい。つまり、通信モジュール１０１は、複数の方式のＬＰＷＡをそれぞれ行う、複数の通信モジュールを含んでいてもよいし、ＬＰＷＡおよびＷｉ−Ｆｉをそれぞれ行う複数の通信モジュールを含んでいてもよい。通信モジュール１０１は、通信モジュールのモジュールＩＤを保持している保持部１０２を有する。通信モジュール１０１は、通信方式が異なる複数の通信モジュールを有している場合には、保持部１０２は、複数の通信モジュールのそれぞれのモジュールＩＤを保持している。

制御部１０４は、機器１０の稼働情報を生成し、生成された稼働情報を、通信モジュール１０１を用いてサーバ２０に送信する。制御部１０４は、具体的には、機器１０の電源部１０９の電源の入／切を示す電源状態を取得することで電源状態を含む稼働情報を生成してもよいし、機器１０が稼働した回数を示す稼働回数をカウントすることで稼働回数を含む稼働情報を生成してもよいし、機能モジュール１０７が発揮している機能を示す機能情報を含む稼働情報を生成してもよい。稼働情報は、図１６で説明した各種データ項目を含んでいてもよい。また、制御部１０４は、通信モジュール１０１を介してサーバ２０から受信した情報に基づく画像を表示部１１２に表示させてもよい。

機能モジュール１０７は、機器１０の機能を発揮するモジュールである。

保持部１０８は、機器１０ごとの固有のＩＤを保持している記憶装置である。

電源部１０９は、外部電源から電力を受け、機器１０内部の構成要素に電力を供給する。

バッテリ１１０は、通信モジュール１０１などに電力を供給する電池である。バッテリ１１０は、一次電池であってもよいし、二次電池であってもよい。

操作部１１１は、機器１０に対するユーザによる操作を受け付ける入力装置である。操作部１１１は、機器１０が冷蔵庫、電子レンジ、炊飯器などのように、開閉するドア、扉などを有する場合、これらのドア、扉などであってもよい。

表示部１１２は、さまざまな情報を画像として表示する表示装置である。

機器１０の構成について、冷蔵庫を例として詳しく説明する。

ＩｏＴ機器としてネット接続されているとしても、冷蔵庫である機器１０は、家電として利用されるものであり、家電として本来の機能を実現するための各種モジュールを備えている。冷蔵庫であれば、庫内を冷却するためのコンプレッサ、扉が開かれた際に庫内を照らす照明装置、庫内の温度又は湿度を測定するためのセンサなどがこうしたモジュールにあたる。このようなモジュールが機能モジュール１０７に相当する。また、冷蔵庫又はエアコンなどの大型家電機器は、電源部１０９を介して外部電源に接続される構成が一般的である。

また、近年の家電機器では様々な便利機能を制御するために、マイクロコンピューター又はプロセッサを用いた制御部１０４が搭載されていることが一般的である。例えば、製氷機能を持つ冷蔵庫であれば、製氷された氷を保存しておく専用皿内に設置されたセンサで製氷の是非を判断し、新たな氷を作るような動作を行う。こうした詳細な動作を行うために、マイクロコンピューター又はプロセッサと、そこで実行されるソフトウェアによって制御が行われている。

さらに、機器１０は、ユーザに対して様々な情報を提示するための表示部１１２、又は、ユーザが複雑な操作を行うための操作部１１１をもつ。

従来の機器の表示部は、複数のランプ又は数桁の数字での表示など限定的な方法で、異常状態の表示又は通電の有無など最低限必要な表示だけを行っていた。また、操作も数個のボタンだけで、急速冷凍の指示又は異常時のリセット操作などシンプルな操作を行ってきた。

これに対して、機器１０は、小型のタッチパネルディスプレイを、操作部１１１及び表示部１１２として備え、より複雑な状態の表示、及び、各種の設定が可能である。

機器１０に対し、ＩｏＴ家電を特徴付けるものが、通信モジュール１０１である。通信モジュール１０１は、Ｗｉ−Ｆｉ又はＬＴＥなど様々な通信手段のなかのいずれか、または複数の方式でインターネットへの接続を可能とする。通信モジュールが複数搭載されている場合にはそれぞれ通信モジュールごとに独立した通信モジュールＩＤが付与され、通信方式によっては例えばＬＴＥにおける電話番号のように通信識別子としての役割をになう。インターネットと接続することにより、制御部１０４で収集した各種情報をサーバ２０に送付すること、又は、反対にサーバ２０から機器１０の制御に必要となる情報を取得することが可能である。さらに、近年ではＬＰＷＡと呼ばれる、通信速度は低いものの、低消費電力でネット接続が可能な技術も出てきている。ＬＰＷＡでは、外部電源とは別に機器１０内にバッテリ１１０を持つことで、外部電源に接続されていない場合でも最低限の通信が可能となる。また、通信によっては、特定の家電機器を指定して制御を行う必要もあるため、機器１０ごとの固有ＩＤを保持する保持部１０８を備えることも想定される。

図１８は、ＩｏＴ家電制御クラウドであるサーバ２０のブロックを示す構成図である。

図１８に示されるように、サーバ２０は、通信部２０１と、制御部２０２と、記憶部２０３とを有する。

通信部２０１は、インターネットなどのネットワークに通信接続することで、機器１０により逐次送信された稼働情報および位置情報を逐次受信する。また、通信部２０１は、ネットワークを介してユーザの操作機器４０から第１ユーザＩＤと機器１０を識別する識別子である第１機器ＩＤとの対応付けの要求を示す要求情報を受信する。また、通信部２０１は、制御部２０２の処理結果をネットワークおよび基地局３０を介して、機器１０に送信してもよい。

制御部２０２は、通信部２０１により互いに対応するタイミングで逐次受信された稼働情報および位置情報を対応付けて逐次記憶部２０３に記憶する。また、制御部２０２は、通信部２０１により受信された要求情報により示される要求を受け付け、受け付けられた要求に応じて第１機器ＩＤと第１ユーザＩＤとを対応付けて記憶部２０３に記憶する。制御部２０２は、所定のプログラムを実行することで、記憶部２０３に記憶された稼働情報または位置情報を用いた処理結果を通信部２０１に機器１０へ送信してもよい。

制御部２０２は、所定のプログラムを記憶している不揮発性メモリと、所定のプログラムを実行するプロセッサとにより実現される。制御部２０２は、上記の機能を実現する専用回路により実現されてもよい。

記憶部２０３は、通信部２０１により受信された稼働情報および位置情報を記憶する。また、記憶部２０３は、第１機器ＩＤと第１ユーザＩＤとを対応付けて記憶する。記憶部２０３は、機器を識別する機器ＩＤと、ユーザを識別するユーザＩＤとが対応付けられている対応関係を記憶していてもよい。対応関係は、当該対応関係においてユーザＩＤに対応付けられている機器ＩＤで識別される機器が、当該ユーザＩＤで示されるユーザに所有されていることを示す情報である。記憶部２０３は、制御部２０２による処理結果を記憶してもよい。記憶部２０３は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などにより実現される。

次に、家電機器の状態予測、例えば、家電機器が「一般家庭へ設置されたこと」の予測方法について説明する。

図１９および図２０は、機器１０が一般家庭へ設置されたことを検知する方法について説明するためのグラフである。

機器１０は、ユーザに購入され、一般家庭に設置されることで始めて、ユーザとの間に関係が生まれる。つまり、機器１０が一般家庭へ設置されたタイミングを、ユーザ利用開始として考えることもできるため、当該タイミングを検知することは非常に重要となる。

機器１０が一般家庭へ設置されたタイミングを検知する方法は複数考えられる。

例えば、サーバ２０は、機器１０が最初に通電された際に、ユーザに確認することで機器１０が一般家庭に設置されたと判定してもよい。この場合、機器１０において、ユーザに機器１０が一般家庭に設置されたことを確認するＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示部１１２に表示し、操作部１１１からの入力を受け付けることで、機器１０が一般家庭に設置されたか否かを確認してもよい。この場合、機器１０は、最初に家電量販店の店頭で通電されるケースも考えられるが、「利用を開始しますか？」などの質問を表示し、Ｎｏの場合は続けて「店頭利用ですか？」などを表示し、当該表示への回答を受け付けることで、店頭利用とユーザの一般家庭による利用とを区別することが考えられる。また、使用開始日、稼働回数などの稼働情報は、ユーザが利用するタイミングから蓄積していき、店頭利用時は情報をリセットしてもよい。

つまり、サーバ２０の制御部２０２は、逐次受信された複数の固有情報のうち、第１のタイミングで受信された第１固有情報と、第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なるか否かを判定し、第１固有情報と第２固有情報とが異なる場合、第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する。つまり、第１期間は、機器１０がユーザに購入される前の期間であることを示し、第２期間は、機器１０がユーザに販売された後において当該ユーザに所有されている期間であることを示す。

制御部２０２は、具体的には、複数の第１稼働情報を第１識別子と対応付けて記憶し、かつ、複数の第２稼働情報を第１識別子とは異なる第２識別子と対応付けて記憶部２０３に記憶することで、複数の第１稼働情報と、複数の第２稼働情報とを分けて管理してもよい。第１識別子は、例えば、販売前であり家電量販店などに位置する場合を示す識別子である。第２識別子は、第２期間において少なくとも１つの機器を利用しているユーザに対応付けられていることを示す識別子である。例えば、第２識別子は、一般家庭のユーザにより購入された後に、当該ユーザの家の中に設置されたことを示す識別子である。なお、複数の第１稼働情報は、ユーザの利用開始が検知された後において、記憶部２０３から削除されてもよい。

なお、第１識別子は、第１のユーザに所有されていることを示す識別子とし、第２識別子は、第１のユーザとは異なる第２のユーザに所有されていることを示す識別子としてもよい。

また、例えば、サーバ２０は、機器１０の操作部１１１がユーザから特定の利用操作を受け付けた場合に、機器１０が一般家庭に設置されたと判定してもよい。特定の利用操作は、具体的には、機器１０が洗濯機であれば注水を検知した場合、炊飯器であれば実際に炊飯が始まって蒸気を検知した場合に、行われたことが判定されてもよい。このように、特定の利用操作は、実際に販売される前に利用されることが考えにくい操作であることが好ましい。また、特定の利用操作とは、エアコンのように設置工事が必ずある機器であれば、工事事業者による設置設定の一部が行われたことを検知した場合に、特定の利用操作が行われたと判定されてもよい。

また、例えば、サーバ２０は、逐次受信した位置情報を用い、機器１０の位置が例えば家電量販店、流通倉庫などのような除外範囲の外の位置を示す場合、一般家庭に設置されたと判定してもよい。除外範囲を示す情報は、記憶部２０３に予め記憶されていてもよいし、通信部２０１により外部装置から取得されてもよい。なお、都市部では、この判定方法だけでは不十分だが、Ｆａｌｓｅ Ｐｏｓｉｔｉｖｅ（誤って一般家庭に設置されたと判定する）はないため、利用することが望ましい。なお、除外範囲は、図２１に示されるように、予め定められた範囲に限らずに、機器１０が内蔵バッテリを有する通信モジュールを有していれば、通電されていない機器１０が多く集まる場所としてもよい。これにより、コストをかけずに常に最新の除外範囲を定めることができる。図２１は、除外範囲を、複数の機器から送信される稼働情報および位置情報を用いて決定する例を示す図である。

本実施の形態に係るサーバ２０は、第１のタイミングで受信された第１固有情報と、第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なる場合、第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する。このため、現在の機器のユーザの使用に基づく稼働情報を管理するため、ユーザの使用状態に適した機器の状態を判定することができる。このように、当該ユーザ以外のユーザなどによる使用に基づく稼働情報を除外して機器の管理を行うことができるため、機器の管理を効率よく行うことができる。

また、ユーザが使用している第２期間中に取得された稼働情報および固有情報に基づく機器の状態の判定を、第１期間中に取得された稼働情報および固有情報とは分けて行うことができる。このため、機器の状態の判定を精度よく行うことができる。

次に、機器１０の生涯管理のうちの家電購入および設置において行われる処理の一例について説明する。

一般家庭での利用が開始した際に、機器１０が稼働情報などのログを送信することは、プライバシ保護の観点から問題がある可能性もある。機器１０のログは、ユーザのＩＤと紐付けられないかぎりは日本の法律における個人情報とはならないが、ユーザの心情として気持ち悪さが残る可能性がある。そのため、一般家庭での利用が開始されたと判断される場合には、一旦、機器１０は、ログをサーバ２０に送信することを停止することが望ましい。ただし、機器１０がメッセージを表示できる表示部１１２を有する場合には、ログをサーバ２０に送信することを説明した上で同意を求め、同意が得られれば引き続き機器１０がログを送信し続けることも考えられる。

図２２は、機器１０を設置の際のログ送信の同意を得るための処理を示すフローチャートである。

なお、ここでは機器１０は、通信モジュール１０１を備える機器であるため、ネットワークに接続する設定の必要はないものとしている。

まず、機器１０は、購入され、ユーザの家に設置される（Ｓ１）。このとき、機器１０は、店舗からユーザの家に移動するため、サーバ２０には、異なる固有情報が送信される。

これにより、サーバ２０は、図１９および図２０を用いて説明した手段で、一般家庭での利用を検知する（Ｓ２）。なお、サーバ２０が検知するのではなく、機器１０が特定の利用操作を受け付けたことで、一般家庭での機器１０の利用を検知してもよい。

サーバ２０は、ユーザに対してログ送信の同意是非を問い合わせる（Ｓ３）。この場合、サーバ２０は、問い合わせるための情報を機器１０に送信し、機器１０は、当該情報を受信し、問い合わせるための情報を表示部１１２に表示する。機器１０が一般家庭での機器１０の利用を検知した場合には、機器１０が問い合わせてもよい。

機器１０の操作部１１１が入力を受け付けることで同意を得た場合（Ｓ３でＹｅｓ）、機器１０は、継続してログを送信する（Ｓ４）。これにより、サーバ２０は、例えば、機器１０が冷蔵庫であれば電力消費量などのデータと、利用地域における気温状況などから故障検知を行うことが可能である。また、サーバ２０は、リチウムイオン電池における充電量の推移や、太陽光発電での発電量の推移についても、同様に故障検知が可能である。こうした情報を収集しておくことで、ユーザに対しても買い替え時期のお知らせなどの機能を提供することが可能となる。

一方で、機器１０の操作部１１１が入力を受け付けることで同意が得られなかった場合（Ｓ３でＮｏ）、機器１０は、ログの送信を停止する（Ｓ５）。

なお、機器１０は、一旦ログ送信を停止した場合でも、機器１０とユーザの紐付けを行う際に、あらためてユーザからの同意を取得することができれば、ログの送信を再開してもよい。

サーバ２０は、ログの送信に同意が得られなかった場合でも、機器の情報を保存し続け、サーバ２０から機器１０への通知やコマンド送ってもよい。このような機能は、リコールの際にリコール情報の通知やファーム更新を促すインジケーターを表示させるなどユーザの安全を守るための機能であるため、無効化されないようにしてもよい。

図２３は、ＩｏＴ家電サービスを利用するまでの手順の一例を示すフローチャートである。

まず、機器１０は、家電量販店などでユーザに購入された後、ユーザ自身または販売者が当該機器１０を自宅まで輸送して設置する（Ｓ１１）。機器１０がエアコンなどの大型家電の場合には、設置工事を伴うものもある。一般的な大型家電は外部電源で動作するため、家庭内のコンセントに接続することで通電され、家電機器としての動作を始める。

次に、機器１０の常時接続の設定が為される（Ｓ１２）。現在広く利用されているＷｉ−Ｆｉ技術では、機器１０は、各家庭内のＷｉ−Ｆｉアクセスポイントに接続されることで常時接続が為されてもよい。このためには、Ｗｉ−Ｆｉアクセスポイントの名称や、必要に応じて暗号化通信のためのパスワードなどを設定する必要がある。なお、ＬＴＥなど通信キャリアのキャリア網に接続される場合には、予め工場出荷までに家電機器の設定を行っておくことで、この常時接続設定は不要である。

こうして、常時接続設定が完了すると、機器１０は、稼働情報をサーバ２０に送信することが可能となる。たとえば、運転状況のログなどの履歴データをサーバ２０に送信することが想定される。ただし、セキュリティ上の問題からこの時点ではまだ当該機器１０に対してユーザは外部から操作を行うことはできない。

次に、ユーザは、機器１０を操作するためのユーザアカウントを作成する（Ｓ１３）。通常のケースでは、操作機器を用いてＷｅｂブラウザで閲覧するＩｏＴ家電サービスのホームページ上で、ユーザＩＤおよびパスワードを設定することでユーザアカウントが作成される。

そして、ユーザは、作成されたユーザアカウントを用いて、操作機器でログインする（Ｓ１４）。操作機器としては、スマートフォン、タブレットの利用を想定するが、スマートスピーカーなどのＶＰＡ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ａｓｓｉｓｔａｎｔ）機器の利用も想定される。

こうして、ユーザが操作機器でログインを行った後で、機器１０とユーザＩＤとの紐付けを行う（Ｓ１５）。この紐付けを行うことによって、以降は当該ユーザのアカウントでログインした操作機器からの操作が可能となる。

この後で、ＩｏＴ家電を用いた様々なサービスが利用可能となる（Ｓ１６）。近年では、設置工事担当者や修理で訪問したサービスマンがＷｉ−Ｆｉ設定やユーザアカウントの設定を補佐、代行入力してくれるケースもある。

機器１０を用いた様々なサービスとして例えば、冷蔵庫内にカメラが設置されているとすると、外出先からでもスマートフォンでログインしておけば、ＩｏＴ家電に対応したアプリを用いてカメラで撮影した画像を閲覧することで、冷蔵庫に入れてある食品などを確認することができる。なお、予め紐付けされたユーザアカウントでのみＩｏＴ家電の操作ができるため、無関係な第三者から冷蔵庫内の映像を盗み見される心配はない。

ユーザアカウントの紐付けが完了していない状態の機器１０は各種サービスを利用できない、つまり機能制限がかかった状態であるので、ユーザにフル機能の提供をするために電源起動時などタイミングでユーザアカウントの紐付けを促す通知を表示するなどの工夫が考えられる。

図２４は、機器１０とユーザとの紐付け手順の第１の例を説明するための図である。図２５は、機器１０とユーザとの紐付け手順の第１の例を示すフローチャートである。

第１の例では、まず、ユーザは、スマートフォンなどの操作機器４０にユーザＩＤおよびパスワードを入力することでログインする（Ｓ２１）。

次に、ユーザは、操作機器４０を用いて、機器１０に与えられた機器コードを入力し、機器１０は、入力された機器コードをサーバ２０に送信する（Ｓ２２）。

この例では、機器１０自身に機器コードが表示される。なお、機器コードは、機器１０に表示される代わりに、例えば保証書、取扱説明書などの機器１０の付属物に記載されていても良い。また、入力ミスを防止するためにスマートフォンが備えるカメラで機器コード撮影し、スマートフォン自身またはサーバ側で文字認識させてもよい。また、機器コードは、数字などの文字列としなくてもよく、二次元バーコードなどであってもよい。

機器１０が機器コードをサーバ２０に送信すると、サーバ２０は、機器コードで指定された機器１０に対して通知を行う。なお、機器１０のメーカは、工場での設定において機器コードと、通信モジュールによる通信のための通信アドレス情報との対応表を作成しておくことが必要となる。これにより、サーバ２０は、対応表を記憶部２０３に記憶していれば記憶部２０３に記憶されている対応表を参照すること、そうでなければ外部装置から対応表を取得し、取得された対応表を参照することで、指定された機器コードに対応する通信アドレスを特定し、当該機器１０に対して通知を行うことが可能となる。

機器１０は、サーバ２０からの通知を受信すると、機器１０が備える表示部１１２で通知があった旨を表示する（Ｓ２３）。例えば、機器１０は、表示用のランプを明滅させることによって、通知の受信をユーザに知らせてもよい。

この受信の通知を行った後で、ユーザは、機器１０の操作部１１１に入力を行うことで、ユーザにより入力がされたことを示す情報がサーバ２０に送信される（Ｓ２４）。これにより、サーバ２０は、機器ＩＤとユーザＩＤとを紐付けることで、機器１０とユーザとの紐付けを完了する。操作部１１１は、例えば、入力用のボタンであってもよく、ボタンが押下されることで入力が為されてもよい。

図２６は、機器１０とユーザとの紐付け手順の第１の例を示すシーケンス図である。

操作機器４０は、入力されたユーザＩＤとパスワードを受け付けて、ユーザＩＤおよびパスワードをサーバ２０に送信する（Ｓ３１）。これにより、サーバ２０は、操作機器４０からユーザＩＤを受信する。ここで、操作機器４０は、第１操作機器の一例である。また、ユーザは、第１ユーザの一例であり、ユーザＩＤは、第１ユーザ識別子の一例である。サーバ２０では、予めサーバ２０で管理されているユーザ情報に基づいてパスワードが正しいかどうかが確認される。ここで、パスワードが正しくなかった場合には第三者による成りすましの可能性があるため、以降の処理は継続されない。

パスワードが正しかった場合、サーバ２０は、操作機器４０に対してログイン情報を送信する（Ｓ３２）。ログイン情報とは、例えばセッションを識別するためのＩＤと、以降の通信で利用する鍵データである。

次に、操作機器４０は、図２４および図２５で示した方法で取得した機器コードをサーバ２０に対して送信する（Ｓ３３）。これにより、サーバ２０は、操作機器４０から機器コードを受信する。ここで、機器１０は、第１機器の一例である。また、機器コードは、機器関連情報の一例である。

なお、図２４および図２５では、機器コードをそのまま送信するとしているが、実際にはログイン情報を用いて処理した結果を送付することが望ましい。処理の方法としては、機器コードだけではなくセッションを識別するためのＩＤを機器コードに付与した上で、先述した鍵データで暗号化するなどの方法が想定される。また、通信全体をＳＳＬなどの暗号化通信で保護することも好ましい。

サーバ２０は、ユーザＩＤおよび機器コードを受信することで、ユーザＩＤおよび機器コードの対応付けの要求を受け付ける。また、サーバ２０は、取得された機器コードに基づいて機器１０を特定し、特定された機器１０にネットワークを介して第４の問い合わせとしての制御信号を送信する。サーバ２０は、機器コードと予めサーバ２０で管理されている機器情報（つまり、上述した対応表）とに基づいて、機器情報において機器コードに対応付けられている機器１０の通信アドレスに変換する。通信アドレスに変換できれば、サーバ２０は、当該機器１０に対して表示部１１２での明滅を指示する制御信号を送信する（Ｓ３４）。

なお、この明滅指示の制御信号については、サーバ２０による成りすましを防止するための仕組みが必要である。成りすましの防止ができなければ、擬似サーバを利用することによって、悪意のある第三者のユーザアカウントと機器１０とを紐付けることが可能となってしまう。成りすましの防止のためには、例えばサーバ２０の公開鍵を予め機器１０で保持しておき、サーバ２０からの明滅指示は時変要素を加えた上で通知し、全体にサーバ２０の秘密鍵による署名を付与することなどが望ましい。

機器１０は、明滅指示を受信すると、表示部１１２を明滅させる。その後ユーザが操作部１１１に入力を行えば、機器１０は、サーバ２０に受け付けた入力を送信する（Ｓ３５）。つまり、機器１０は、第４の問い合わせに対する第４の応答をサーバ２０に送信する。

サーバ２０は、入力を受信すると、ユーザアカウントと機器１０との紐付けを完了し、完了通知を操作機器４０に送信する（Ｓ３６）。つまり、サーバ２０は、第４の応答を機器１０から受信した場合に、機器ＩＤとユーザＩＤとを対応付けて記憶部２０３に記憶する。

なお、サーバ２０は、入力を待つ期間を定めておくことが望ましい。通常は１分程度とする必要がある。サーバ２０は、明滅指示の制御信号を送信してから、カウントを開始し、入力を待つ期間が経過しても入力を受信できない場合、紐付けが失敗した旨の完了通知を操作機器４０に送信してもよい。つまり、サーバ２０は、所定期間が経過しても第４の応答を受信しない場合に、機器ＩＤとユーザＩＤとの対応付けを行わない。サーバ２０は、第４の問い合わせを送信したタイミングで、カウントを開始し、カウントが所定期間に達しても第４の応答を受信しない場合に、機器ＩＤとユーザＩＤとの対応付けを行わずに処理を終了する。

操作機器４０は、受信した完了通知を表示する。

図２７は、機器１０とユーザとの紐付け手順の第２の例を示すフローチャートである。

第２の例では、まず、ユーザは、スマートフォンなどの操作機器４０にユーザＩＤおよびパスワードを入力することでログインし（Ｓ４１）、ログインした状態で待機させ、ユーザは、機器１０の設定ボタンを押す（Ｓ４２）。

機器１０は、設定ボタンが押されるとサーバ２０に対し、機器１０とユーザアカウントとを紐付けるためのパスワードを要求する。この時、サーバ２０は、ワンタイムパスワードまたは時限式のパスワードを発行することが望ましい。そして、機器１０は、サーバ２０からパスワードを受信し、パスワードを表示部１１２に表示する（Ｓ４３）。

ユーザは、表示部１１２に表示されたパスワードを操作機器４０に入力し、操作機器４０は、入力されたパスワードをサーバ２０に送信する（Ｓ４４）。この例において、パスワードは、数字などの文字列を例示しているが、二次元バーコードまたはＬＥＤの明滅パターン、モールス信号などの音データ等であってもよい。二次元バーコードまたはＬＥＤの明滅パターンの場合には、操作機器４０のカメラを用いて読み取ることにより、パスワードが入力される。モールス信号などの音データである場合には、操作機器４０のマイクで収音することにより、パスワードが入力される。

サーバ２０は、操作機器４０からパスワードを受信すると、紐付け要求をした機器１０とパスワードを送ってきたユーザアカウントとの間で紐付けし（Ｓ４５）、紐付け完了を示す通知を機器１０に送信する。

機器１０は、サーバ２０からの紐付け完了の通知を受信すると、機器１０が備える表示部１１２で通知があった旨を表示する（Ｓ４６）。例えば、機器１０は、表示用のランプを明滅させることによって、通知の受信をユーザに知らせてもよい。

図２８は、機器１０とユーザとの紐付け手順の第２の例を示すシーケンス図である。

操作機器４０は、入力されたユーザＩＤとパスワードを受け付けて、ユーザＩＤおよびパスワードをサーバ２０に送信する（Ｓ５１）。これにより、サーバ２０は、操作機器４０からユーザＩＤを受信する。ここで、操作機器４０は、第１操作機器の一例である。また、ユーザは、第１ユーザの一例であり、ユーザＩＤは、第１ユーザ識別子の一例である。サーバ２０では、予めサーバ２０で管理されているユーザ情報に基づいてパスワードが正しいかどうかが確認される。ここで、パスワードが正しくなかった場合には第三者による成りすましの可能性があるため、以降の処理は継続されない。

パスワードが正しかった場合、サーバ２０は、操作機器４０に対してログイン情報を送信する（Ｓ５２）。ログイン情報とは、例えばセッションを識別するためのＩＤと、以降の通信で利用する鍵データである。

次に、機器１０は、ユーザからの入力を受け付けると、サーバ２０に対してワンタイムパスワードの発行を要求する（Ｓ５３）。なお、この要求の際に、機器１０は、あわせて自身の機器ＩＤをサーバ２０に送信する。ここで、機器１０は、第１機器の一例である。また、機器ＩＤは、機器関連情報の一例である。また、機器ＩＤは、機器識別子とも言う。なお、サーバ２０は、通信の際の機器１０のアドレス情報に基づいて、サーバ２０で予め管理されている機器情報から、対応する機器ＩＤを取得してもよい。この場合、アドレス情報は、機器関連情報の一例である。

サーバ２０は、ユーザＩＤおよび機器ＩＤを受信することで、ユーザＩＤおよび機器コードの対応付けの要求を受け付ける。また、サーバ２０は、ワンタイムパスワードの要求に応答して、ワンタイムパスワードを機器１０に送信する（Ｓ５４）。なお、機器１０の通信アドレスは、上述した第１の例におけるステップＳ３４と同様の方法を用いることで特定される。ここで送信されるワンタイムパスワードは、第４の問い合わせの一例である。発行されたワンタイムパスワードは、機器１０の表示部１１２で表示される。

操作機器４０は、表示部１１２に表示されたワンタイムパスワードの入力をユーザから受け付け、入力されたワンタイムパスワードをサーバ２０に送信する（Ｓ５５）。つまり、機器１０は、第４の問い合わせに対する第４の応答としてのワンタイムパスワードをサーバ２０に送信する。

なお、図２８では、ワンタイムパスワードをそのまま送付するとしているが、実際にはログイン情報を用いて処理した結果を送付することが望ましい。処理の方法としては、機器コードだけではなくセッションを識別するためのＩＤを機器コードに付与した上で、先述した鍵データで暗号化するなどの方法が想定される。また、通信全体をＳＳＬなどの暗号化通信で保護することも好ましい。

サーバ２０は、操作機器４０から受け取ったワンタイムパスワードが予め発行したワンタイムパスワードと一致しているかを確認し、一致を確認した段階でユーザアカウントと機器ＩＤを紐付ける。つまり、サーバ２０は、第４の応答を機器１０から受信した場合に、機器ＩＤとユーザＩＤとを対応付けて記憶部２０３に記憶する。サーバ２０は、紐付けの完了通知を操作機器４０に送信する（Ｓ５６）。

なお、サーバ２０は、入力を待つ期間を定めておくことが望ましい。通常は１分程度とする必要がある。サーバ２０は、ワンタイムパスワードを送信してから、カウントを開始し、入力を待つ期間が経過しても入力を受信できない場合、紐付けが失敗した旨の完了通知を操作機器４０に送信してもよい。つまり、サーバ２０は、所定期間が経過しても第４の応答を受信しない場合に、機器ＩＤとユーザＩＤとの対応付けを行わない。サーバ２０は、第４の問い合わせを送信したタイミングで、カウントを開始し、カウントが所定期間に達しても第４の応答を受信しない場合に、機器ＩＤとユーザＩＤとの対応付けを行わずに処理を終了する。

操作機器４０は、受信した完了通知を表示する。

このように、ユーザＩＤと機器ＩＤとの対応付けをユーザが所望する組合せで対応付けることができるため、精度よく機器とユーザとの対応付けを行うことができる。また、機器は、ＬＰＷＡの基地局３０を介して第４の問い合わせを受信できる。

以上のように、ユーザＩＤと機器ＩＤとが対応付けられてサーバ２０の記憶部２０３に記憶されることで、記憶部２０３には、複数のユーザＩＤ毎に、複数の機器ＩＤが対応付けられた対応関係が記憶されることとなる。

次に、複数の機器と複数のユーザとの紐付けの方法について説明する。

図２９は、複数の機器と複数のユーザとの紐付けの方法の一例の第１の場面を説明するための図である。

ここでは、２台のエアコン１１、１３、１台の冷蔵庫１２、および１台のテレビ１４により構成される合計で４台のＩｏＴ家電が１つの家庭内に設置されている例が示されている。２台のエアコン１１、１３は、それぞれ、リビングルームおよび子供部屋に設置されている。エアコン１１、１３、冷蔵庫１２およびテレビ１４のそれぞれは、機器１０の一例である。つまり、エアコン１１、１３、冷蔵庫１２およびテレビ１４のそれぞれは、図示しないが、基地局３０とＬＰＷＡによって通信接続されている。

また、この家庭は、父、母、兄および妹から構成される４人家族であり、父と母は各々エアコン１１、１３、冷蔵庫１２およびテレビ１４を操作するためのユーザアカウント（ユーザＩＤ）を保有しているものとする。ここで、父は、第２ユーザの一例であり、母は、第１ユーザの一例である。ユーザアカウントは、サーバ２０が実現するＩｏＴ家電制御クラウド上におけるユーザアカウントである。

既に述べたように機器１０は、ユーザアカウントと紐付けられる前から、その常時接続性を生かして家電の操作ログまたは動作ログをサーバ２０へ基地局３０を介して送信している。一方で、ユーザは、スマートフォン、ＶＰＡなどの操作機器を用いて、機器１０の操作を行おうとする場合、機器１０とユーザアカウントとの紐付けが必須である。

例えば、図２９の例では、父が所有するスマートフォン４１上で動作するアプリにおいて、ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントでログインし、リビングルームのエアコン１１に対して紐付けを既に行っているものとする。つまり、サーバ２０で記憶されている対応関係には、ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントと、エアコン１１の機器ＩＤとが対応付けられている。また、サーバ２０で記憶されている対応関係には、ユーザアカウント、及び、操作対象となる機器の機器ＩＤに、さらに、ＩｏＴ家電制御クラウドへのログインに用いられた操作機器の機器ＩＤが対応付けられていてもよい。つまり、対応関係では、ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍと、エアコン１１の機器ＩＤと、スマートフォン４１の機器ＩＤとが対応付けられていてもよい。これによって、父は、所有するスマートフォン４１を用いてエアコン１１を操作することができる。なお、ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍは、第２ユーザＩＤの一例である。エアコン１１は、第１機器の一例であり、エアコン１１の機器ＩＤは、第１機器ＩＤの一例である。スマートフォン４１は、第２操作機器の一例である。

また、母は、所有するスマートフォン４２上で動作するアプリにおいて、ｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントでログインし、冷蔵庫１２に対して紐付けを既に行ったものとする。つまり、サーバ２０で記憶されている対応関係には、ｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントと、冷蔵庫１２の機器ＩＤとが対応付けられている。なお、対応関係では、ｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍと、冷蔵庫１２の機器ＩＤと、スマートフォン４２の機器ＩＤとが対応付けられていてもよい。これによって、母は、所有するスマートフォン４２を用いて冷蔵庫１２を操作することができる。なお、ｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍは、第１ユーザＩＤの一例である。冷蔵庫１２は、第２機器の一例であり、冷蔵庫１２の機器ＩＤは、第２機器ＩＤの一例である。スマートフォン４２は、第１操作機器の一例である。

さらに、この例では、家庭内にＶＰＡ４３が設置されており、このＶＰＡは、父のユーザアカウントであるｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍでログインされている。ＶＰＡ４３は、子供部屋のエアコン１３およびテレビ１４に対して紐付けを既に行ったものとする。なお、対応関係では、ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍと、エアコン１３およびテレビ１４の各機器ＩＤと、スマートフォン４１の機器ＩＤとが対応付けられていてもよい。これによって、ユーザは、ＶＰＡ４３を用いて、子供部屋のエアコン１３およびテレビ１４を操作することができる。なお、ＶＰＡ４３は、一般的に家族共用で利用されるケースが多い。この場合には、兄または妹は、自分のスマートフォンまたはユーザアカウントを持ってはいないものの、ＶＰＡ４３を用いて子供部屋のエアコン１３またはテレビ１４を操作することができる。

図３０は、複数の機器と複数のユーザとの紐付けの方法の一例の第２の場面を説明するための図である。第２の場面は、複数の同一のユーザアカウントを介して複数の操作機器と機器との紐付けが行われる場面である。

さて、図２９では父が所有するｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントは、スマートフォン４１、ＶＰＡ４３などの複数の操作機器で利用されている。このユーザアカウントを介することによって、明示的には紐付けられていない操作機器とＩｏＴ家電とが紐付けられてもよい。

図３０では、同一のユーザアカウントを介することにより間接的に紐付けられる操作機器とＩｏＴ家電との関係を点線で示している。この例では、父は、父が所有するスマートフォン４１を用いることで、サーバ２０が記憶している対応関係において明示的に紐付けられているリビングルームのエアコン１１に加えて、同一のユーザアカウントで間接的に紐付けられた子供部屋のエアコン１３およびテレビ１４の操作を許可してもよい。

また、サーバ２０は、２台のエアコン１１、１３、およびテレビ１４を同一のｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍというユーザアカウントで紐付けて管理することとなる。これによって、例えば２台のエアコン１１、１３で部屋を空調するときの温度設定などの設定情報を共有することができる。また、テレビ１４の視聴状態に応じてテレビ１４が設置されている部屋と同じ部屋に設置されているエアコン１１の運転状態を適切に制御することが可能となる。

図３１は、複数の機器と複数のユーザとの紐付けの方法の一例の第３の場面を説明するための図である。第３の場面は、機器を介してユーザアカウント同士の紐付けが行われる場面である。

さて、さらに図３１では、母が所有するスマートフォン４２上で動作するアプリにて、リビングルームのエアコン１１を母のユーザアカウントｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍに紐付ける操作をサーバ２０が受け付けたとする。この場合、母はスマートフォン４２を用いて、図２４〜図２７を用いて上述した機器１０とユーザとの紐付け手段を行ったものとする。

このとき、既にエアコン１１には、父のユーザアカウントであるｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍが紐付けられており、同じエアコン１１に複数のユーザアカウントが紐付けられたということは、これらの複数のユーザアカウントを所有しているユーザ同士は家族であるという蓋然性が高い。

このため、この場合にサーバ２０は、父のユーザアカウントと母のユーザアカウントで紐付けられている機器とを紐付けて、紐付けた結果を対応関係としてさらに記憶部２０３に記憶させてもよい。同様に、サーバ２０は、父のユーザアカウントで紐付けられている機器と母のユーザアカウントとを紐付けて、紐付けた結果を対応関係としてさらに記憶部２０３に記憶させてもよい。つまり、サーバ２０は、記憶部２０３に記憶されている対応関係において、（ｉ）第１機器ＩＤに、第１ユーザＩＤとは異なる第２ユーザＩＤが対応付けられており、かつ、（ｉｉ）第１ユーザＩＤに、複数の機器のうちの第１機器とは異なる第２機器を識別する第２機器ＩＤが対応付けられている場合、第２識別子と第２ユーザＩＤとを対応付けて記憶部２０３に記憶させる。これにより、サーバ２０は、対応関係を更新する。

このように、同一の機器ＩＤに異なるユーザアカウントの紐付けが行われるケースを検知した場合に行われる紐付け処理の一例について次の図３２および図３３を用いて説明する。

図３２は、同一の機器ＩＤに異なるユーザアカウントの紐付けが行われる場合に行われる紐付け処理の一例を示すシーケンス図である。図３３は、同一の機器ＩＤに異なるユーザアカウントの紐付けが行われる場合に行われる紐付け処理において操作機器への通知を示す情報の一例を示す図である。

図３２に示すように、まず、サーバ２０は、同一機器への紐付けを検出する（Ｓ６１）。例えば、上述したように、母がスマートフォン４２を操作することにより、エアコン１１の機器ＩＤと母のユーザアカウントとの紐付けの要求がスマートフォン４２により送信される。サーバ２０は、当該要求を受信することで、対応関係において、エアコン１１の機器ＩＤに紐付けられている他のユーザアカウントがあるか否かを判定する。サーバ２０は、他のユーザアカウントがある場合、同一機器への紐付けを検出する。一方で、サーバ２０は、他のユーザアカウントが無い場合、エアコン１１の機器ＩＤと母のユーザアカウントとの紐付けを行い、この処理を終了する。

サーバ２０は、ステップＳ６１の後で、検出結果をスマートフォン４２に通知する（Ｓ６２）。ここで、サーバ２０により送信される検出結果には、対応関係においてｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍで識別されるユーザである父が、ｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍで識別されるユーザである母の家族であるか否かを確認する第１の問い合わせが含まれる。

スマートフォン４２は、サーバ２０から検出結果を受信すると、図３２に示されるように、同一機器への紐付けを検出したことをユーザに通知する画面４２１を表示する。これにより、ユーザアカウントと紐付けようとした機器に既に他のユーザアカウントが紐づいていたことを検出した旨がユーザに対して通知される。

次に、スマートフォン４２は、サーバ２０から受信した検出結果に基づいて、第１の問い合わせを示す画面４２２を表示する（Ｓ６３）。これにより、ユーザに、ステップＳ６１において検出された他のユーザアカウントで示されるユーザ（つまり、父）が母の‘家族であるかどうかが確認される。ここでは、家庭内に設置された機器に対する紐付けが行われる場合であるため、画面４２２において家族であるか否かが確認されるユーザとして、無関係な第三者が表示されることは原則として考えにくい。

次に、スマートフォン４２は、第１の問い合わせを示す画面４２２への入力を受け付け（Ｓ６４）、受け付けた入力結果をサーバ２０に送信する（Ｓ６５）。入力結果は、第１の問い合わせに対する第１の応答を示す。スマートフォン４２は、入力結果をサーバ２０に送信すると、入力結果としての通知を、サーバ２０を介してスマートフォン４１に送信したことが完了した旨を示す画面４２３を表示する（Ｓ６６）。

サーバ２０は、ステップＳ６５で送信された入力結果を受信すると、入力結果が、父が母の家族であることが母により承認されたことを示す応答を含む場合、当該入力結果を父のユーザアカウントに対応付けられているスマートフォン４１に送信する（Ｓ６７）。サーバ２０は、当該入力結果を、エアコン１１の機器ＩＤと母のユーザアカウントとを対応付けることを示す通知として送信する。通知は、母が父の家族であるか否かを父に確認する第２の問い合わせを含んでいてもよい。

スマートフォン４１は、サーバ２０から受信した通知に基づいて、第２の問い合わせを示す画面４１１を表示する（Ｓ６８）。画面４１１は、アプリが次回に起動されたときに表示されてもよいし、メールまたは通知などのプッシュ式の仕組みを使って表示されてもよい。

次に、スマートフォン４１は、第２の問い合わせを示す画面４１１への入力を受け付け（Ｓ６９）、受け付けた入力結果をサーバ２０に送信する（Ｓ７０）。

サーバ２０は、ステップＳ７０で送信された入力結果を受信すると、入力結果が、母が父の家族であることが父により承認されたことを示す応答を含む場合、エアコン１１の機器ＩＤと母のユーザアカウントとを対応付けて記憶する（Ｓ７１）。

なお、サーバ２０は、ステップＳ６５で受信された入力結果が、父が母の家族であることが母により承認されなかったことを示す応答を含む場合、ステップＳ７１において、エアコン１１の機器ＩＤと母のユーザアカウントとの対応付けを行わなくてもよい。例えば、ステップＳ６５で家族でないとの回答が受信された場合には、本例ではサーバ２０は、処理を停止してもよい。なお、この場合、サーバ２０は、処理を停止するのではなく、積極的に紐付けを解除してもよい。これは、ＩｏＴ家電が譲渡されたケース、知人が訪問してきた際に誤って、または悪意を持って紐付け操作が行われた場合への対策である。先に紐付けを行ったユーザが解除権を持つとの考え方がもっともシンプルであるが、この方法では譲渡に対応できないため、例えば強制的に紐付けの解除の操作をＩｏＴ家電の操作部で受け付けてもよい。このように、第１の問い合わせへの結果である第１の応答に応じて、機器ＩＤとユーザアカウントとを対応付けるため、望ましくない対応付けの要求を受け付けないようにすることができる。

また、サーバ２０は、ステップＳ７０で受信された入力結果が、母が父の家族であることが父により承認されなかったことを示す応答を含む場合、ステップＳ７１において、エアコン１１と母のユーザアカウントとの対応付けを行わなくてもよい。例えば、ステップＳ７０で家族でないとの回答が受信された場合には、本例ではサーバ２０は、処理を停止してもよい。このように、第２の問い合わせへの結果である第２の応答に応じて、機器ＩＤとユーザアカウントとを対応付けるため、望ましくない対応付けの要求を受け付けないようにすることができる。

なお、別の形態としては、家族か否かを問い合わせることなく、無条件に家族として取り扱ってもよい。つまり、第１の問い合わせおよび第２の問い合わせをすることなく、無条件に父と母とが家族であるとして、エアコン１１と母のユーザアカウントとの紐付けを行ってもよい。

また、家族と問い合わせたとしてＮＯとの回答があった場合には、当該ＩｏＴ家電において紐付け元のユーザアカウントとの紐付けを許可しなくてもよい。

図３４は、複数の機器と複数のユーザとの紐付けの方法の一例の第４の場面を説明するための図である。第４の場面は、機器を介してユーザアカウント同士の紐付けが行われる別の場面である。

図３２で示したシーケンス図において、父のユーザアカウントと母のユーザアカウントが家族同士であると承認された場合、図３３で示すように、家庭内の全てのＩｏＴ家電が全てのユーザアカウントと相互に紐付けることができる。つまり、エアコン１１、１３、冷蔵庫１２およびテレビ１４と、父のユーザアカウントであるｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍおよび母のユーザアカウントであるｍｏｍ＠ｐａｎａｓｏｎｉｃ．ｃｏｍとを相互に紐付けることができる。

このため、ステップＳ６５で受信された入力結果が、父が母の家族であることが母により承認されたことを示す応答を含み、かつ、ステップＳ７０で送信された入力結果が、母が父の家族であることが父により承認されたことを示す応答を含む場合、サーバ２０は、冷蔵庫１２の機器ＩＤと父のユーザアカウントとの紐付けを行ってもよい。このように、エアコン１１の機器ＩＤと母のユーザアカウントとの対応付けの要求を受け付けた場合、サーバ２０は、記憶されている対応関係を用いて、冷蔵庫１２の機器ＩＤと父のユーザアカウントとを対応付けて記憶する。このため、ユーザと機器との対応付けを効率よく行うことができる。

なお、サーバ２０は、ステップＳ６５で受信された入力結果が、父が母の家族であることが母により承認されたことを示す応答を含む場合に、冷蔵庫１２の機器ＩＤと父のユーザアカウントとの紐付けを行ってもよい。また、サーバ２０は、第１の問い合わせおよび第２の問い合わせをすることなく、無条件に父と母とが家族であるとして、冷蔵庫１２の機器ＩＤと父のユーザアカウントとの紐付けを行ってもよい。

また、サーバ２０は、母のユーザアカウントとリビングのエアコン１１の機器ＩＤとを対応付ける要求があった場合に、対応関係において、エアコン１１の機器ＩＤには既に父のユーザアカウントが対応付けられており、かつ、父のユーザアカウントにはさらにエアコン１３の機器ＩＤおよびテレビ１４の機器ＩＤとが対応付けられている。このため、サーバ２０は、エアコン１３の機器ＩＤおよびテレビ１４の機器ＩＤと母のユーザアカウントとの対応付けを記憶してもよい。このため、ユーザと機器との対応付けをさらに効率よく行うことができる。

これにより、図３４の破線で示されるように、各機器の機器ＩＤと、各ユーザアカウントとが紐付けられる。

図３５は、複数の機器と複数のユーザとの紐付け方法の別の一例を説明するための図である。

図３５で示される例では、父が複数のユーザアカウントを持っているケースである。このようなケースは、家庭内に複数メーカのＩｏＴ家電が存在し、各メーカが異なるユーザアカウントの体系を管理および運用している場合に発生しうる。ただし、ユーザ観点ではたとえメーカが異なったとしてもＩｏＴ家電同士が連携することが好ましいため、メーカ同士が連携することを前提としたケースとなる。なお、別メーカの例以外にも、たとえ同じメーカであったとしても、スマートフォンの買い替えなどによって、既に作成していたユーザアカウントまたはパスワードを失念してしまい、新たに別のユーザアカウントまたはパスワードを設定した場合などにもこのケースが発生しうる。

図３５で示される例では、子供部屋のエアコン１３またはテレビ１４が、リビングルームのエアコン１１または冷蔵庫１２とは別メーカの製品であり、別メーカのユーザアカウントで設定されてしまっているケースである。この場合には、リビングルームのエアコン１１を操作するための父のユーザアカウント（ｄａｄ＠ｐａｎａｓｏｎｉｃ．ｃｏｍ）と、子供部屋のエアコン１３を操作するための父のユーザアカウント（ｄａｄ＠ｍａｔｓｕｓｈｉｔａ．ｃｏｍ）とは各々異なる別のユーザアカウントであるため、当面は別人として取り扱われる。

この状態から、図３５で太い点線で示した紐付け操作が行われることでＩｏＴ家電を介したユーザ紐付けのシーケンスが始まる。つまり、図２４〜図３４で説明した機器とユーザとの紐付けのシーケンスが開始される。ここでは、原則として図３２および図３３で示したものと同様のシーケンスとなる。例えば、画面４２２による「家族ですか？」の問い合わせの前に、サーバ２０は、例えば、他のユーザアカウントで識別されるユーザが同一人物であるか否かを確認する「同一人物ですか？」という第３の問い合わせを、現在ユーザが操作しているＶＰＡ４３に送信してもよい。なお、ＶＰＡ４３に問い合わせをする場合には、ＶＰＡ４３は、音声でユーザに問い合わせをし、ユーザからは音声による応答を取得する。このように、ユーザアカウントが異なる場合には、家族であるのか同一人物であるのかの判定がつかないため、第３の問い合わせをユーザにして、ユーザから応答を得ることで異なるユーザアカウントが家族のユーザアカウントであるか同一人物のユーザアカウントであるかの判別を行う。ここで、受信された応答が、同一人物であることが承認されたことを示す場合、異なるユーザアカウントを対応付けて同一人物であるとして記憶する。操作の観点では家族であるか同一人物であるかの区分には大きな差はないが、例えば、家族であるか同一人物であるかの区分をしておくことで、同一人物であるユーザアカウントに対応付けられた機器から得られた情報を、個々のユーザに最適になるように当該機器を制御することに利用することができる。

なお、第１の問い合わせは、第２ユーザが、第１ユーザが属する第１ユーザグループのメンバであるか否かを確認する問い合わせであればよく、第２ユーザが第１ユーザの家族であるか否かを確認する問い合わせでなくてもよい。つまり、第１の応答には、第２ユーザが第１ユーザグループのメンバであることが承認されたこと、または、承認されなかったことを示す応答が含まれる。

同様に、第２の問い合わせは、第１ユーザが、第２ユーザが属する第２ユーザグループのメンバであるか否かを確認する問い合わせであればよく、第１ユーザが第２ユーザの家族であるか否かを確認する問い合わせでなくてもよい。つまり、第２の応答には、第１ユーザが第２ユーザグループのメンバであることが承認されたこと、または、承認されなかったことを示す応答が含まれる。

第１ユーザグループのメンバの家族以外の例は、シェアハウスのメンバである。第２ユーザグループのメンバの家族以外の例も、同様に、シェアハウスのメンバである。

このように、上述における「母の家族」は、第１ユーザが属する第１ユーザグループのメンバと読み替えることができる。また、「父の家族」は、第２ユーザが属する第２ユーザグループのメンバと読み替えることができる。

なお、第２ユーザが、第１ユーザグループのメンバであると承認され、かつ、第１ユーザが、第２ユーザグループのメンバであると承認されれば、第１ユーザグループおよび第２ユーザグループは、同一のユーザグループであると見なされる。

次に、機器１０の状態予測のうちの、設置場所の移動または使用ユーザが変更された時のイベントを判定方法について説明する。

図３６は、「引っ越し」および「譲渡」を判別する処理の一例を示すフローチャートである。

機器１０は、購入された後で他のユーザに譲渡されることが考えられる。特にユーザと機器１０との間で紐付けが行われた後で、当該機器１０を他のユーザに譲渡した場合には問題が発生する。何も対策を施さない場合、前に利用していたユーザは、譲渡した後であっても、機器１０のログを閲覧すること、または、機器１０の操作を行うことが可能である。一方で、機器１０をリセットするなどしてユーザと機器との紐付けが解除されれば、このような問題は解決される。しかしながら、このような紐付けの解除のための操作は、従来の家電機器では必要ない操作であるため、譲渡を受けたユーザが正しくリセットを行うことができるかは疑わしい。

そこで、サーバ２０は、ＩｏＴ家電から受信した稼働情報および位置情報を用いて譲渡されたか否かを判断することが望ましい。譲渡の際には、通常家電機器への通電を一旦切断した上で、別の場所に移動させて新たに利用を開始することが想定される。サーバ２０は、稼働情報を用いることでＩｏＴ家電の通電状況を確認することが可能であり、また先述した位置情報を用いることで、設置場所が変更されていることも識別可能である。この二つを組み合わせることにより、サーバ２０は、機器１０が譲渡された可能性を判断することが可能である。

例えば、サーバ２０は、稼働情報および位置情報を用いて、機器１０の通電切断と機器１０の設置場所が移動したことを検知する（Ｓ８１）。サーバ２０は、例えば、稼働情報の電源状態が切であるかを判定することで機器１０が通電切断であるかを判定することができる。また、サーバ２０は、位置情報が前回の位置情報から変化した場合に、機器１０の設置場所が移動したことを検知することができる。

ただし、これだけではユーザが変らずに住所だけが変わった、つまり引っ越したのか、譲渡されたのかは判断できない。そこで、表示部を有する機器であれば、表示部に、紐付けの変更が必要かどうかの問い合わせ表示させることで、ユーザに問い合わせてもよい。

つまり、サーバ２０は、機器１０が表示部を有しているか否かを判定する（Ｓ８２）。サーバ２０は、機器１０の情報を参照することで当該機器１０が表示部を有しているか否かを判定してもよいし、稼働情報に機器１０が表示部を有しているか否かの情報が含まれていれば、稼働情報に基づいて判定してもよい。

表示部を有していない場合（Ｓ８２でＮｏ）、いったん安全のためにユーザと機器との紐付けを保留とする（Ｓ８３）。その上で、サーバ２０は、紐付けを行ったスマートフォンなどの操作機器に、「譲渡」であるのか「引越」であるのかを確認するメッセージを送信することでユーザに「譲渡」であるのか「引越」であるのかを問い合わせる（Ｓ８４）。この問い合わせで「引越」であることが確認できれば、保留状態を解除して、ユーザと機器１０との紐付けを維持する（Ｓ８５）。反対に「譲渡」であることが確認できれば、紐付けを解除する（Ｓ８６）。

表示部を有している場合（Ｓ８２でＹｅｓ）、表示部を用いて上記問い合わせを行う（Ｓ８７）。この問い合わせで「引越」であることが確認できれば、保留状態を解除して、ユーザと機器１０との紐付けを維持する（Ｓ８８）。反対に「譲渡」であることが確認できれば、紐付けを解除する（Ｓ８９）。

このように、譲渡を受けたユーザは、紐付けが解除されることで適切にリセット操作を行うことが可能である。逆に、ユーザが変わらずに住所だけが変わったのであれば、サーバ２０は、紐付けの変更が不要であると判断することができ、ユーザは引き続きこれまでどおりに機器１０を利用することが可能である。

以上のように、制御部２０２は、第２のタイミングの後の第３のタイミングで受信された第３固有情報が第２固有情報と異なる場合、第３固有情報を送信した機器１０が移動したと判断し、機器１０のユーザが他のユーザに変更されたか否かの問い合わせを、機器１０またはユーザが所有するスマートフォンなどの端末に、通信部２０１を用いて送信してもよい。なお、第３のタイミングとは、ステップＳ８１の検知のタイミングに対応する。

制御部２０２は、問い合わせを送信した後に、機器１０または端末から受信した問い合わせに対する回答が、機器１０のユーザが他のユーザに変更されたことを示す場合、第３のタイミング以降の第３期間において受信された複数の第３稼働情報を、複数の第１稼働情報および複数の第２稼働情報とは分けて管理する。制御部２０２は、具体的には、複数の第３稼働情報を第１識別子および第２識別子とは異なる第３識別子で対応付けて記憶部２０３に記憶することで、複数の第３稼働情報を、複数の第１稼働情報および複数の第２稼働情報とは分けて管理する。このため、機器１０の譲渡が為されたか否かを効果的に判定することができる。また、機器１０の譲渡が為された場合に、譲渡前のユーザによる稼働情報とは分けて管理するため、譲渡後のユーザに適した機器１０の状態を判定することができる。

一方で、制御部２０２は、問い合わせを送信した後に、機器１０または端末から受信した問い合わせに対する回答が、機器１０のユーザが他のユーザに変更されていないことを示す場合、第３のタイミング以降の第３期間において受信された複数の第３稼働情報を複数の第２稼働情報と共に管理する。制御部２０２は、具体的には、複数の第３稼働情報を第２識別子と対応付けて記憶部２０３に記憶する。このため、例えば機器１０の譲渡が為されずに機器１０が移動した場合には、ユーザを変更せずに機器１０の管理を行うことができる。

図３７は、「引っ越し」および「譲渡」を判別する処理の他の一例について説明するための図である。図３８は、「引っ越し」および「譲渡」を判別する処理の他の一例を示すフローチャートである。

引っ越しと譲渡を区別する方法として、先述の通電切断と、設置場所の移動検知に加え、他の情報を組み合わせることで家電機器が譲渡されたのか引っ越しなのかの可能性をより正確に判定してもよい。図３７では、時刻Ｔ１で同時に、複数の機器（機器Ａおよび機器Ｂ）が同時に移動した場合の位置情報の例が示されている。このように同時に複数の機器が移動した場合は、引っ越しが行われたと考えられる。このため、ユーザが所有している複数の機器の位置情報を連動させることで判定精度を上げることができる。例えば、ユーザの所有する冷蔵庫、洗濯機、エアコンなどが同じタイミングで位置変更された場合は高確率で引っ越しの可能性が高く、洗濯機だけ変更されていた場合は引っ越しではない可能性が高くなる。

この場合、サーバ２０は、稼働情報および位置情報に基づいて、通電切断と設置場所の移動を検知する（Ｓ９１）。

次に、サーバ２０は、連動して場所を移動した機器が複数あるか否かを判定する（Ｓ９２）。つまり、サーバ２０は、第１の場所から第２の場所に移動した機器が複数あるか否かを判定する。

サーバ２０は、連動して場所を移動した機器が複数あると判定した場合（Ｓ９２でＹｅｓ）、引っ越しの可能性が高いと判定する（Ｓ９３）。

サーバ２０は、連動して場所を移動した機器が複数ないと判定した場合（Ｓ９２でＮｏ）、つまり、移動した機器が１台である場合、譲渡の可能性が高いと判定する（Ｓ９４）。

このように、制御部２０２は、時刻Ｔ１よりも前の第２のタイミングで複数の機器１０から受信された複数の第２固有情報が互いに同じであり、かつ、第２のタイミングの後の時刻Ｔ１よりも後の第３のタイミングで複数の機器から受信された複数の第３固有情報が互いに同じであり、かつ、第２固有情報と第３固有情報とが異なる場合、第３のタイミング以降の第３期間において受信された複数の第３稼働情報を複数の第２稼働情報と共に管理してもよい。このため、複数の機器が移動した場合には、ユーザが変更されていないと見なして、機器の管理を行うことができる。

図３９は、「引っ越し」および「譲渡」を判別する処理の他の一例について説明するための図である。図４０は、「引っ越し」および「譲渡」を判別する処理の他の一例を示すフローチャートである。

サーバ２０は、先述の通電切断と、設置場所の移動を検知することに加え、日毎の稼働回数情報を併せて用いることで、「引っ越し」か「譲渡」かの判定を行っても良い。これにより、判定精度を改善することができる。

図３９では、位置情報が変化しているが、稼働回数のパターンに変化が少ない。このように、サーバ２０は、位置情報が変化してもいても、位置情報が変化する前の期間と、位置情報が変化する後の期間における単位時間当たりの稼働回数の変化のパターンが所定の相関度を満たす場合（つまり類似する場合）、引っ越しの可能性が高いと判断してもよい。

この場合のサーバ２０の処理では、図４０に示されるように、図３８の処理と比較してステップＳ９２の代わりに、ステップＳ１０２を行っている点が異なる。ステップＳ１０１、Ｓ１０３、Ｓ１０４の処理は、それぞれ、ステップＳ９１、Ｓ９３、Ｓ９４の処理と同様である。

ステップＳ１０２では、サーバ２０は、利用頻度が変化したか否かを判定している。利用頻度が変化したか否かは、上述したように、稼働回数の変化のパターンが所定の相関度を満たすか否かを判定することで判定している。

図３９に示されるように、日毎の稼働回数が変化するということは家電機器を使う人が異なる可能性が高く、「譲渡」された可能性がより高くなる。逆に日毎の稼働回数が変化しないということはこれまでと利用頻度が変わっていないので同一人物が他の場所で使っている「引っ越し」と考えられる。ただし、この判定方法はシェーバーやドライヤーのように外出先に持ち運んで使う家電機器にそのまま適応することはできない。

図４１は、「引っ越し」が予想されるケースの例外について説明するための図である。図４２は、機器の種別に応じてカテゴリ分けした表である。

上述のように、機器１０の位置情報が変化したことで、引っ越しか譲渡かを判定することができるが、外出先で持ち運び使う小型の機器においては位置情報が変更されていたとしても外出先で利用しているだけのケースがある。つまり、位置情報が変化されたことがサーバ２０によって検知されても、引っ越しでも譲渡でもない場合がある。例えば、図４１に示されるように、持ち運びが想定されるシェーバーやドライヤーなどの小型家電は、ユーザにより持ち運びされると位置が変化することになる。この場合、ユーザは、元の家に帰ってくることが想定される。このため、サーバ２０は、元の位置に戻ったことを検知することで、引っ越しも譲渡も行われずにユーザに継続して利用されていると判断することができる。つまりこの場合、サーバ２０は、ユーザと機器との紐付けを維持したままとする。

このように、日常生活の中で基本的に通電切断されない冷蔵庫や洗濯機などの大型家電と宅外への持ち運びが想定されるシェーバーやドライヤーなどの小型家電では、引っ越しと判定する際の影響度を変更することで、より判定精度を高めることができる。なお、図４２に示されるように、機器の大きさや、季節によって使用される機器などに応じて、複数のカテゴリに分類し、サーバ２０は、これらのカテゴリの特徴に応じて機器の状態の判断を変更してもよい。

次に、機器１０の状態予測のうち、機器１０が「譲渡・転売・盗難」が予測されるケースについて説明する。

図４３は、機器１０が「譲渡・転売・盗難」の予測ケースのグラフを示す図である。

図４３に示されるように、機器１０の位置が変化し、かつ、稼働回数のパターンも大きく変化した場合、機器１０のユーザが変更したと予測される。このため、サーバ２０は、「譲渡・転売・盗難」が発生したと予測する。これにより、サーバ２０は、機器１０上のＬＥＤ／ディスプレイ等に、確認を促す通知または警告の通知をするサービスを行うことが可能である。また、ユーザ変更前のアカウント情報が紐付いた状態で残っている場合は該当ユーザに対してメールなどで通知を行い、アカウント情報の紐付け解除を促す。

一度、ユーザと機器との紐付けが行われた後で紐付け解除を行った場合、当該機器から過去ユーザのログなどを参照できることは管理上望ましくない。参照できるログは、ユーザと紐付く範囲のログに限定されるべきだが、当該機器の耐用年数、耐用使用回数を超過していることなどのユーザの安全に関わる情報は、家電機器を安全にお使いいただくためにもこれらの情報を伝えた方が良いケースもある。こういった観点を踏まえ、サーバ上では当該機器の初回の使用時から現在までの累計情報をユーザが利用したログとは別途管理しておくことが有用である。または、累計情報に対して、どの期間がユーザと紐付いていたのかを管理することで実現可能となる。

家電機器に紐付く累計情報は、量販店の店頭で展示していた機器を販売するケースや転売などの再販売のケースで参照できるようにするなどの使い方も考えられる。

次に、機器１０の状態予測において機器１０が盗難された際の対策機能について説明する。

図４４は、機器１０が盗難された際の対策を実行する処理のフローチャートである。

機器１０が盗難された場合、ユーザが自身のユーザアカウントと紐付く機器１０を他ユーザが使用できないようにロックできる機能を持たせることが望ましい。具体的には、盗難された機器１０に対して、紐付けを行ったスマートフォンなどの操作機器４０を用いて、操作機器から盗難された機器１０をロックさせる命令を送る機能である。この機能を持つことで盗難により不正に機器１０を入手したユーザが機器１０を利用することや、不正なユーザに過去のログが閲覧されることを防ぐことが可能となる。

まず、サーバ２０は、機器１０が送信する位置情報、稼働状態などの情報から「盗難」の疑いがあることを検知する（Ｓ１１１）。

ユーザが気づいていれば、ステップＳ１１５に進み、ユーザが気づいていなければステップＳ１１３に進む。なお、ステップＳ１１２では、ステップＳ１１１の後で、所定期間経過するまでにユーザの操作機器４０からステップＳ１１５における操作機器でのロックボタンが押されたことを示す情報を受信したか否かを判定する。これにより、所定期間経過してもロックボタンが押されていない場合には、ステップＳ１１３に進む。

ステップＳ１１３において、サーバ２０は、機器１０に紐付くユーザアカウントに対してユーザの操作機器４０に機器１０が盗難されていないかを問い合わせる（Ｓ１１４）。この機能により、ユーザが盗難されたことに気づいていない状態であっても、家電機器から「ご自宅にありますか？」、「手元にありますか？」などのメッセージが操作機器４０に送られることでユーザは盗難されたことに気づくことが可能となる。

サーバ２０は、ステップＳ１１４において盗難の入力を操作機器４０から受信するとステップＳ１１５に進む。なお、この場合、盗難の入力がされたときにステップＳ１１５のロックボタンが押されたと見なしてもよい。

ステップＳ１１５において、ロックボタンが押されると、機器１０がロックされる。このように、機器１０をロックさせる機能を使って家電機器をロックすることで不正利用をやめさせることができる。

ステップＳ１１４において盗難ではないことを示す入力を操作機器４０から受信すると、この処理を終了する。

次に、一旦ロックされた家電機器のロックを解除することが考える。家電機器側だけでロックを解除できてしまうと不正利用を防ぐことができないため、紐付くユーザアカウントにロック解除の確認を送信する機能が必要となる。しかし、ユーザがこの機能を悪用し、ユーザアカウント紐付けした状態で転売し、転売後にロックするなどのケースが考えられるため製造メーカにロック解除用の連絡窓口を設ける必要がある。製造メーカは連絡を受けた家電機器に紐付くユーザアカウントを持つユーザに対して連絡を取り、ロック解除の可否を判断する。

盗難対策機能を実現する上で、通信モジュールを用いてクラウドと通信可能なことが前提となる。そのため、盗難の際にこの通信モジュールを取り外してから家電機器を運び出すケースが考えられる。この対策として家電機器は通信モジュールが取り外された状態では常にロックするようにすることが有用である。

このように、制御部２０２は、第２のタイミングの後の第３のタイミングで受信された第３固有情報が第２固有情報と異なる場合、機器１０が移動したと判断し、機器１０が盗難されたか否かの問い合わせを、通信部２０１を用いて、ユーザが所有する端末に送信してもよい。次に、制御部２０２は、問い合わせを送信した後に、端末から受信した問い合わせに対する回答が、機器１０が盗難されたことを示す場合、機器１０を使用できないようにロックする制御信号を、通信部２０１を用いて送信してもよい。この場合、機器１０は、制御信号を受信すると、当該機器１０を使用できないようにロックしてもよい。このため、機器１０が盗難された場合に、他のユーザが機器１０を使用できないようにロックすることができる。

ここで、機器１０を使用できないようにロックするとは、具体的には、機器１０が操作部１１１からのユーザの入力を受け付けない状態となることである。例えば、機器１０は、機器１０の電源をオフにして、かつ、その後に機器１０が操作部１１１からのユーザの入力を受け付けない状態となってもよい。また、機器１０が冷蔵庫、洗濯機、電子レンジ、炊飯器など開閉する扉を有する機器の場合、扉が開かないようにロックされてもよい。

次に、機器１０の状態予測において、複数情報を利用した「引っ越し」および「譲渡」の判別について説明する。

図４５は、機器１０の移動を検知した際のユーザと機器１０との紐付け処理の一例を示すフローチャートである。

これまで示してきたいくつの判定方法を組み合わせ、「引っ越し」と「譲渡」の判別をするフローの例を示す。

サーバ２０は、通電切断、及び、設置場所の移動を検知する（Ｓ１２１）。

サーバ２０は、機器１０に表示部があるか否かを判定する（Ｓ１２２）。

サーバ２０は、機器１０に表示部がない場合（Ｓ１２２でＮｏ）、複数機器が同時に移動したか否かを判定する（Ｓ１２３）。

サーバ２０は、複数同時に移動していない場合（Ｓ１２３でＮｏ）、ユーザと機器１０との紐付けを保留する（Ｓ１２４）。

ステップＳ１２３において、サーバ２０は、複数機器が同時に移動した場合（Ｓ１２３でＹｅｓ）、移動した複数機器が小型家電のみか否かを判定する（Ｓ１２５）。

サーバ２０は、移動した複数機器が小型家電のみである場合（Ｓ１２５でＹｅｓ）、複数機器が数日で元の設置場所に戻るか否かを判定する（Ｓ１２６）。

サーバ２０は、複数機器が数日で元の設置場所に戻った場合（Ｓ１２６でＹｅｓ）、または、ステップＳ１２５でＮｏと判定された場合、ユーザと複数機器との紐付けを維持する（Ｓ１２７）。

サーバ２０は、複数機器が数日で元の設置場所に戻らない場合（Ｓ１２６でＹｅｓ）、ステップＳ１２４に進む。

ステップＳ１２２において、サーバ２０は、機器１０に表示部があると判定した場合（Ｓ１２２でＹｅｓ）、譲渡であるか否かをユーザの操作機器４０に問い合わせる（Ｓ１２８）。

サーバ２０は、操作機器４０から譲渡であるとの回答を受信した場合（Ｓ１２８でＹｅｓ）、ユーザと機器との紐付けを解除する。

サーバ２０は、操作機器４０から譲渡でないとの回答を受信した場合（Ｓ１２８でＮｏ）、ステップＳ１２７に進む。

この例では表示部がなく、ユーザに確認が取りにくい構成であっても、引っ越しとほぼ断定できる場合にはユーザと機器１０との紐付け状態を保留状態にせず、継続利用できるように判定フローが構築されている。

図４６は、機器１０の移動を検知した際のユーザと機器１０の紐付け処理の他の一例を示すフローチャートである。

前述の例とは逆に、疑わしい状況を極力紐付け保留にし、利用者の確認を常に要求することでセキュリティを担保する考え方もある。この場合、複数の家電機器を利用している場合一つ一つ確認処理を行うのは煩わしいので、一つ確認した段階でＩｏＴ機器間通信しで結果を共有できる構成が望ましい。

この場合、サーバ２０は、通電切断、及び、設置場所の移動を検知する（Ｓ１３１）。

サーバ２０は、ユーザと機器１０との紐付けを保留する（Ｓ１３２）。

サーバ２０は、譲渡であるか否かをユーザの操作機器４０に問い合わせる（Ｓ１３３）。

サーバ２０は、操作機器４０から譲渡であるとの回答を受信した場合（Ｓ１３３でＹｅｓ）、ユーザと機器との紐付けを解除する。

サーバ２０は、操作機器４０から譲渡でないとの回答を受信した場合（Ｓ１３３でＮｏ）、ユーザと機器との紐付けを維持する（Ｓ１３５）。

次に、機器１０の状態予測において、ユーザの「家族構成変更」が為されたと予測されるケースについて説明する。

図４７は、ユーザの「家族構成変更」が為されたと予測されるケースのグラフを示す図である。

図４７に示されるように、機器１０の所在位置が変わらないが、稼働回数のパターンが大きく変化している。この場合が、「家族構成変更」したと予測されるケースである。ユーザは、結婚や両親と同居などの変化があった可能性が考えられ、家電上のＬＥＤ／ディスプレイ等に、それに見合った商品広告を表示するなどのサービスが可能である。

次に、機器の状態予測において、機器１０が「故障」または「廃棄」と予測されるケースについて説明する。

図４８は、機器１０が「故障」したと予測されるケースのグラフを示す図である。図４９は、機器１０が「廃棄」されたと予測されるケースのグラフを示す図である。

図４８および図４９に示されるように、サーバ２０は、一定期間以上、稼働情報および位置情報を受信していない場合、「故障」または「廃棄」が発生したと予測する。また、サーバ２０は、機器１０が通信モジュール用バッテリを内蔵する場合において、当該機器１０の所在位置が変わってから、稼働回数がゼロとなり一定期間以上データ送信が無い場合、「廃棄」されたと予測してもよい。

他にも、サーバ２０は、通信モジュール用バッテリを内蔵する場合は通信が途絶した場所が特定範囲（焼却場やリサイクルセンター）であった場合には、ほぼ確実に「廃棄」と判断できる。該当家電機器がリコール対象だった場合には「廃棄」と判定した段階でリコール対象の管理リストから除外してもよい。仮に「廃棄」が誤判定で、家電機器が再度動き始めた場合には、通信が再開しているはずなので改めてリコール通知を送ることで、対応することができる。このため誤判定になるリスクは少ないと考えられる。

このように、サーバ２０は、第２のタイミングの後の第４のタイミングから所定期間後となっても稼働情報を受信しない場合、第４のタイミングまでに受信された複数の稼働情報の管理状態を非管理状態に変更してもよい。

また、制御部２０２は、第２のタイミングの後の第４のタイミングから所定期間後となっても、通信部２０１が稼働情報を受信せず、かつ、第４のタイミングで受信された第４固有情報が予め保持している固有情報リストに含まれる複数の固有情報のいずれか１つと同じである場合、第４のタイミングまでに受信された複数の稼働情報の管理状態を非管理状態に変更してもよい。

このように、サーバ２０は、機器１０が故障または廃棄と判定した場合、当該機器１０の管理をしないため、管理にかかる処理負荷を低減することができる。

以上のように、本開示における技術の例示として、実施の形態を説明した。そのために、添付図面および詳細な説明を提供した。

したがって、添付図面および詳細な説明に記載された構成要素の中には、課題解決のために必須な構成要素だけでなく、上記実装を例示するために、課題解決のためには必須でない構成要素も含まれ得る。そのため、それらの必須ではない構成要素が添付図面や詳細な説明に記載されていることをもって、直ちに、それらの必須ではない構成要素が必須であるとの認定をするべきではない。

また、上述の実施の形態は、本開示における技術を例示するためのものであるから、請求の範囲またはその均等の範囲において種々の変更、置き換え、付加、省略などを行うことができる。

本開示は、機器の管理を効率よく行うことができる機器管理システム、機器管理方法などとして有用である。

１ 機器管理システム
１０ 機器
１１、１３ エアコン
１２ 冷蔵庫
１４ テレビ
２０ サーバ
３０ 基地局
４０ 操作機器
４１、４２ スマートフォン
４３ ＶＰＡ
１０１ 通信モジュール
１０２ 保持部
１０４ 制御部
１０７ 機能モジュール
１０８ 保持部
１０９ 電源部
１１０ バッテリ
１１１ 操作部
１１２ 表示部
２０１ 通信部
２０２ 制御部
２０３ 記憶部
４１１、４２１〜４２３ 画面

Claims (13)

1. 複数の機器、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器とネットワークを介して通信接続されているサーバにおいて行われる機器管理方法であって、
   前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受け付けステップと、
   記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第１ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第２機器を識別する第２機器識別子が対応付けられている場合、前記第２機器識別子と前記第２ユーザ識別子とを対応付けて記憶する記憶ステップと、を含む
   機器管理方法。
2. 前記記憶ステップでは、
   前記対応関係において、前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられている場合、前記第２ユーザ識別子で識別される第２ユーザが、前記第１ユーザが属する第１ユーザグループのメンバであるか否かを確認する第１の問い合わせを前記第１操作機器に送信し、
   送信された前記第１の問い合わせに対する第１の応答を受信し、
   受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶する
   請求項１に記載の機器管理方法。
3. 前記記憶ステップでは、
   受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されなかったことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子との対応付けと、前記第２機器識別子と前記第２ユーザ識別子との対応付けをしない
   請求項２に記載の機器管理方法。
4. 前記記憶ステップでは、さらに、
   受信された前記第１の応答が、前記第２ユーザが前記第１ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１ユーザが、前記第２ユーザが属する第２ユーザグループのメンバであるか否かを確認する第２の問い合わせを送信し、
   送信された前記第２の問い合わせに対する第２の応答を受信し、
   受信された前記第２の応答が、前記第１ユーザが、前記第２ユーザグループのメンバであることが承認されたことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶する
   請求項２または３に記載の機器管理方法。
5. 前記記憶ステップでは、
   受信された前記第２の応答が、前記第１ユーザが前記第２ユーザグループのメンバであることが承認されなかったことを示す応答を含む場合、前記第１機器識別子と前記第１ユーザ識別子との対応付けと、前記第２機器識別子と前記第２ユーザ識別子との対応付けをしない
   請求項４に記載の機器管理方法。
6. 前記記憶ステップは、
   前記対応関係において、前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられている場合、前記第２ユーザ識別子で識別される第２ユーザが前記第１ユーザと同一人物であるか否かを確認する第３の問い合わせを前記第１操作機器に送信し、
   送信された前記第３の問い合わせに対する第３の応答を受信し、
   受信された前記第３の応答が、前記第１ユーザと前記第２ユーザとが同一人物であることが承認されたことを示す応答を含む場合、前記第１ユーザ識別子と前記第２ユーザ識別子とを対応付けて記憶する
   請求項１から５のいずれか１項に記載の機器管理方法。
7. 前記記憶ステップでは、さらに、
   前記対応関係において、前記複数の機器のうちの前記第１機器および前記第２機器とは異なる第３機器を識別する第３機器識別子と前記第２ユーザ識別子とが対応付けられている場合、前記第３機器識別子と前記第１ユーザ識別子とを対応付けて記憶する
   請求項１から６のいずれか１項に記載の機器管理方法。
8. 複数の機器、および、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器とネットワークを介して通信接続されているサーバにおいて行われる機器管理方法であって、
   前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受け付けステップと、
   記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第２ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第３機器を識別する第３機器識別子が対応付けられている場合、前記第３機器識別子と前記第１ユーザ識別子とを対応付けて記憶する記憶ステップと、を含む
   機器管理方法。
9. 前記受け付けステップでは、前記第１操作機器から前記第１ユーザ識別子を受信し、かつ、前記第１機器または前記第１操作機器から前記第１機器に関する機器関連情報を受信することで、前記要求を受け付け、
   前記記憶ステップは、
   取得された前記機器関連情報に基づいて前記第１機器を特定し、
   特定された前記第１機器に、前記ネットワークを介して第４の問い合わせを送信し、
   送信された前記第４の問い合わせに対する第４の応答を前記第１機器または前記第１操作機器から受信した場合に、前記第１機器識別子と前記第１ユーザ識別子とを対応付けて記憶し、前記第４の応答を受信しない場合に、前記第１機器識別子と前記第１ユーザ識別子との対応付けを行わない
   請求項１から８のいずれか１項に記載の機器管理方法。
10. 前記複数の機器のそれぞれは、遠距離無線通信の基地局を介して前記ネットワークに通信接続されており、
    前記第１機器への前記第４の問い合わせの送信では、前記基地局を介して前記第１機器に前記第４の問い合わせを送信する
    請求項９に記載の機器管理方法。
11. 前記遠距離無線通信は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）による通信である
    請求項１０に記載の機器管理方法。
12. ネットワークに通信接続されている複数の機器と、
    前記ネットワークに通信接続されており、かつ、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器と、
    前記ネットワークを介して通信接続されているサーバと、を備え、
    前記サーバは、
    前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受付部と、
    記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第１ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第２機器を識別する第２機器識別子が対応付けられている場合、前記第２機器識別子と前記第２ユーザ識別子とを対応付けて記憶する記憶部と、を有する
    機器管理システム。
13. ネットワークに通信接続されている複数の機器と、
    前記ネットワークに通信接続されており、かつ、第１ユーザを識別する第１ユーザ識別子に対応付けられている第１操作機器と、
    前記ネットワークを介して通信接続されているサーバと、を備え、
    前記サーバは、
    前記複数の機器のうちの第１機器を識別する第１機器識別子と前記第１ユーザ識別子との対応付けの要求を前記第１操作機器から受け付ける受付部と、
    記憶装置に記憶されている対応関係であって、機器を識別する機器識別子と、ユーザを識別するユーザ識別子とが対応付けられている対応関係において、（ｉ）前記第１機器識別子に、前記第１ユーザ識別子とは異なる第２ユーザ識別子が対応付けられており、かつ、（ｉｉ）前記第２ユーザ識別子に、前記複数の機器のうちの前記第１機器とは異なる第３機器を識別する第３機器識別子が対応付けられている場合、前記第３機器識別子と前記第１ユーザ識別子とを対応付けて記憶する記憶部と、を有する
    機器管理システム。

Images