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

Description

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

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

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

しかし、機器を使用するユーザが、必ずしも、ネットワークに接続するための設定などをして、機器を制御クラウドに接続するとは限らない。機器が制御クラウドに接続されなければ、制御クラウドによる機器の管理を効率よく行うことができないという問題がある。

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

本開示の一態様に係る機器管理システムは、ネットワークに通信接続されているサーバと、前記ネットワークに通信接続されている、遠距離無線通信の基地局と、前記基地局に通信接続する機器であって、当該機器の状態を示す状態情報を、前記基地局を介して前記サーバに送信する機器と、を備える。

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

本開示の機器管理システムは、機器の管理を効率よく行うことができる。

図１は、生活家電の進化を示す説明図である。 図２は、第三世代の生活家電のアーキテクチャと外部サービス連携の例を示す説明図である。 図３は、第三世代の生活家電のアーキテクチャとＡＩスピーカー連携の例を示す説明図である。 図４は、第三世代の生活家電の第一の課題を示す説明図である。 図５は、第三世代の生活家電の第二の課題を示す説明図である。 図６は、ネット接続機能内蔵家電のネット接続率を示す説明図である。 図７は、クラウド生活家電のネット接続などを示す説明図である。 図８は、常時接続ＩｏＴ生活家電で利用可能な通信方式（Ｗｉ－Ｆｉ、ＬＰＷＡ）の特徴を示す表である。 図９は、第四世代の生活家電（常時接続ＩｏＴ家電）のアーキテクチャと外部サービス連携を示す第一の説明図である。 図１０は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第二の説明図である。 図１１は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第三の説明図である。 図１２は、第四世代の生活家電のアーキテクチャと外部サービス連携を示す第四の説明図である。 図１３は、生活家電のアーキテクチャの進化を示す図である。 図１４は、第四世代の生活家電の機能分担（機能の外部化）について説明するための図である。 図１５は、機器管理システムの構成を示すブロック図である。 図１６は、ＩｏＴ家電である機器の第１の例のブロックを示す構成図である。 図１７は、ＩｏＴ家電制御クラウドであるサーバのブロックを示す構成図である。 図１８は、製造時または修理時の情報を通知する機能を有する機器において、状態情報をサーバに通知する処理フローの一例を示す図である。 図１９は、製造時または修理時に機器がサーバに送信する状態情報の一例を示す表である。 図２０は、サーバにおける機器の通電状態を判断する処理の第１の例を示すフローチャートである。 図２１は、サーバにおける機器の通電状態を判断する処理の第２の例を示すフローチャートである。 図２２は、サーバにおける、通電状態でない機器の設置状態を推定する処理の一例を示すフローチャートである。 図２３は、非通電状態の機器の通信頻度をサーバが制御する処理の一例を示すシーケンス図である。 図２４は、サーバにより決定される更新間隔と、非通電状態になってからの経過時間との関係を示すグラフである。 図２５は、ＩｏＴ家電である機器の第２の例のブロックを示す構成図である。 図２６は、機器の使用時に機器が設置されている地域を取得する方法の例を示す図である。 図２７は、機器の流通経路におけるファームウェアバージョンを通知する例について説明するための図である。 図２８は、ＥＣサービスと連携した家電管理サービスにおけるユーザと機器との紐付ける処理について説明するための図である。

本開示の一態様に係る機器管理システムは、ネットワークに通信接続されているサーバと、前記ネットワークに通信接続されている、遠距離無線通信の基地局と、前記基地局に通信接続する機器であって、当該機器の状態を示す状態情報を、前記基地局を介して前記サーバに送信する機器と、を備える。

このため、機器は、サーバに機器の状態情報を例えば定期的に送信することができる。このため、サーバは、機器の最新の状態情報を取得することができ、機器の管理を効率よく行うことができる。

また、前記機器は、前記基地局と前記遠距離無線通信用の通信モジュールと、前記通信モジュールを駆動する電力を前記通信モジュールに供給する通信用バッテリと、を有し、前記通信モジュールは、前記機器の電源がオフである場合に、前記基地局を介して前記サーバに前記状態情報を送信してもよい。

このため、通信モジュールは、機器の電源がオフの場合であっても、基地局と通信することができるため、機器の状態情報をサーバに送信することができる。

また、前記機器は、さらに、前記機器の電源がオンである場合に、前記機器の動作を制御する制御部と、前記制御部による制御状態を逐次保持する保持部と、を有し、前記通信モジュールは、前記機器の電源がオフである場合に、前記保持部に逐次保持された前記制御状態を読み出して、読み出された前記制御状態を前記状態情報として前記基地局を介して前記サーバに送信してもよい。

このため、通信モジュールは、機器の電源がオフの場合であっても、機器の制御状態を状態情報としてサーバに送信することができる。

また、前記基地局は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）の基地局であり、前記通信モジュールは、前記ＬＰＷＡの通信モジュールであってもよい。

このため、機器は、機器の通電状態をサーバに送信することができる。

また、前記状態情報は、前記機器が通電しているか否かを示す通電状態を含んでもよい。

このため、機器は、ネットワークと常時接続された状態を容易に実現できるため、機器の状態情報を定期的にサーバに送信することができる。

また、前記サーバは、前記機器から前記状態情報を受信し、受信された前記状態情報に応じて通知情報を生成し、生成された通知情報を前記機器に送信してもよい。

このため、サーバは、機器の状態に適した通知情報を機器に送信することができる。

また、機器であって、遠距離無線通信の基地局に通信接続する通信モジュールであって、前記機器の状態を示す状態情報を、前記基地局を介して、前記基地局にネットワークで通信接続されているサーバに送信する通信モジュールを備えてもよい。

このため、機器は、サーバに機器の状態情報を例えば定期的に送信することができる。

また、前記機器は、さらに、前記通信モジュールを駆動する電力を前記通信モジュールに供給する通信用バッテリを有し、前記通信モジュールは、前記機器の電源がオフの場合に、前記基地局を介して前記サーバに前記状態情報を送信してもよい。

このため、通信モジュールは、機器の電源がオフの場合であっても、基地局と通信することができるため、機器の状態情報をサーバに送信することができる。

また、前記機器は、さらに、前記機器の電源がオンである場合に、前記機器の動作を制御する制御部と、前記制御部による制御状態を逐次保持する保持部と、を有し、前記通信モジュールは、前記機器の電源がオフである場合に、前記保持部に逐次保持された前記制御状態を読み出して、読み出された前記制御状態を前記状態情報として前記基地局を介して前記サーバに送信してもよい。

このため、通信モジュールは、機器の電源がオフの場合であっても、機器の制御状態を状態情報としてサーバに送信することができる。

また、前記基地局は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）の基地局であり、前記通信モジュールは、前記ＬＰＷＡの通信モジュールであってもよい。

このため、機器は、機器の通電状態をサーバに送信することができる。

また、前記状態情報は、前記機器が通電しているか否かを示す通電状態を含んでもよい。

このため、機器は、ネットワークと常時接続された状態を容易に実現できるため、機器の状態情報を定期的にサーバに送信することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＬＰＷＡは、前述の通り、伝送できるデータ量はＷｉ－Ｆｉなどに比べて小さいという課題に関しても、複数のＬＰＷＡを同時に持つことで解決することができる。ＬＰＷＡは主だった体系としてセルラーＬＰＷＡとノンセルラーＬＰＷＡとに分類される。セルラーＬＰＷＡは、セルラーキャリアに割り当てられた周波数バンド（ライセンスバンド）を用いるため、ノンセルラーＬＰＷＡに比べ伝送できるデータ量が大きいという特徴があり、ノンセルラーＬＰＷＡはライセンス不要のため、家電メーカ主導で置局することも可能なため、カバーエリアを管理しやすいという特徴がある。Ｗｉ－Ｆｉに加え少なくとも一つ以上のＬＰＷＡを持つことで家電稼働中は常にクラウドにつながった状態を保持できる常時接続ＩｏＴ家電を実現する。

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

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

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

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

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

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

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

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

次に、本実施の形態に係る機器管理システム１について、図９で説明した構成を例にして説明する。

図１５は、機器管理システムの構成を示すブロック図である。

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

サーバ２０は、インターネットなどのネットワークに通信接続されており、ＩｏＴ家電制御クラウドとして機能する。サーバ２０は、ネットワークを介して機器１０から状態情報を受信し、受信された状態情報に応じて通知情報を生成し、生成された通知情報を機器１０に送信する。サーバ２０の詳細な機能については後述する。

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

機器１０は、上述した第四世代の生活家電、つまり、常時接続ＩｏＴ家電であり、複数の基地局３０のうちの一の基地局３０に通信接続する。機器１０は、機器１０の状態を示す状態情報を、機器１０に内蔵されているＬＰＷＡ通信モジュールを用いて、一の基地局３０を経由してサーバ２０に逐次送信する。

なお、状態情報は、例えば、「機器固有ＩＤ」、「通信モジュールＩＤ」、「通信モジュール種別」、「送信日時」、「通電状態」、などを含む。通電状態は、機器１０が通電しているか否か、つまり、電源がオンであるかオフであるかを示す。状態情報は、上記以外にもソフトウェアのバージョン情報を含んでいてもよい。これにより、サーバ２０は、機器１０がどのような状態で動作しているのかをより正確に管理することができる。

次に、基地局３０は、状態情報を逐次受信すると、逐次受信された状態情報と共に当該基地局３０に固有の情報である固有情報をサーバ２０に逐次送信する。ここで、基地局３０が状態情報を転送する際に、状態情報と共に送信される固有情報は、当該基地局を識別する基地局ＩＤであってもよいし、当該基地局が設置されている位置を示す位置情報であってもよい。

本実施の形態に係る機器１０は、サーバ２０に機器１０の状態情報を例えば定期的に送信することができる。このため、サーバ２０は、機器１０の最新の状態情報を取得することができ、機器１０の管理を効率よく行うことができる。

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

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

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

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

制御部１０４は、機器１０の電源がオンである場合に、機器１０の動作を制御する。具体的には、制御部１０４は、機能モジュール１０７を制御することで、機器１０の動作を制御する。また、制御部１０４は、機器１０の状態情報を生成し、生成された状態情報を、通信モジュール１０１を用いてサーバ２０に送信してもよい。制御部１０４は、具体的には、機器１０の電源部１０９の電源の入／切を示す通電状態を取得することで通電状態を含む状態情報を生成してもよいし、機能モジュール１０７が発揮している機能を示す機能情報を含む状態情報を生成してもよい。制御部１０４により生成される状態情報は、上記で説明した「機器固有ＩＤ」、「通信モジュールＩＤ」、「通信モジュール種別」、「送信日時」などを含んでいてもよい。また、制御部１０４は、通信モジュール１０１を介してサーバ２０から受信した情報に基づく画像を表示部１１２に表示させてもよい。

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

保持部１０８は、機器１０ごとの固有のＩＤを保持している記憶装置である。なお、以下では、状態情報のサーバ２０への送信を、状態情報の通知と称する場合もある。

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

通信用バッテリ１１０は、通信モジュール１０１などに通信モジュール１０１などを駆動する電力を供給する電池である。通信用バッテリ１１０は、一次電池であってもよいし、二次電池であってもよい。これにより、通信モジュール１０１は、機器１０の電源がオフである場合であっても、基地局３０を介してサーバ２０に状態情報を送信する。つまり、通信モジュール１０１は、機器１０の通電状態が電源オンであるか電源オフであるかに関わらず、基地局３０と通信することができるため、常時、サーバ２０に状態情報を送信することができる。

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

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

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

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

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

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

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

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

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

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

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

通信部２０１は、インターネットなどのネットワークに通信接続することで、機器１０により逐次送信された状態情報および固有情報を逐次受信する。また、通信部２０１は、制御部２０２の処理結果をネットワークおよび基地局３０を介して、機器１０または操作機器４０に送信してもよい。

制御部２０２は、通信部２０１により互いに対応するタイミングで逐次受信された状態情報および固有情報を対応付けて記憶部２０３に逐次記憶する。制御部２０２は、所定のプログラムを実行することで、記憶部２０３に記憶された状態情報または固有情報を用いた処理結果を通信部２０１に機器１０または操作機器４０へ送信してもよい。

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

記憶部２０３は、通信部２０１により受信された状態情報および固有情報を記憶する。記憶部２０３は、制御部２０２による処理結果を記憶してもよい。記憶部２０３は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などにより実現される。

次に、機器１０が製造または修理の時に送信される状態情報について説明する。

図１８は、製造時または修理時の情報を通知する機能を有する機器１０において、状態情報をサーバ２０に通知する処理フローの一例を示す図である。図１９は、製造時または修理時に機器１０がサーバ２０に送信する状態情報の一例を示す表である。

図１６を用いて既に説明したように、機器１０は、基地局３０を介してネットワークに接続することで状態情報をサーバ２０に送信する。機器１０は、例えば、製造時または修理時の情報を状態情報として送信する。これにより、サーバ２０は、受信された情報を蓄積することができ、蓄積された情報を用いて機器１０を管理することで、機器１０の製品ライフサイクルの全期間における品質を保持することができる。

このような機器１０は、例えば、初回通信確立時の基地局ＩＤを、製造工場を示す情報としてサーバ２０に送信してもよい。また、機器１０は、初回通信確立時の日時を、製造日時を示す情報としてサーバ２０に送信してもよい。機器１０は、これらの情報を状態情報に含めてサーバ２０に送信してもよい。なお、機器１０が基地局ＩＤを送信しなくてもよく、基地局３０が、機器１０から受信した状態情報に基地局ＩＤを付加して、基地局ＩＤが付加された状態情報をサーバ２０に送信してもよい。サーバ２０は、機器１０により送信された上記の情報を製造情報として保存しておくことで、製品ライフサイクル全期間に亘って、機器１０の製造日からの経過時間を算出することができる。また、サーバ２０は、機器１０の製造工場および製造日を記憶しておくことができる。

これらの情報を基に、サーバ２０は、リコール対象となった機器１０の製造工場および当該製造工場におけるリコール対象となった機器１０が製造された期間を特定することが容易にできる。よって、サーバ２０は、出荷後の機器であっても、リコール対象となった製造工場および期間で絞り込むことで、リコール対象となった複数の機器を特定することができる。このため、サーバ２０は、リコール対象となった機器１０、または、ユーザの操作機器４０に、当該機器１０がリコール対象となっていることを通知することができる。

また、サーバ２０は、機器１０の製造日からの経過期間を算出できるため、機器１０が設計耐用年数を超過した場合に、機器１０が設計耐用年数を超過したことを示す情報を、例えば、機器１０または操作機器４０に送信することで、ユーザに通知することができる。これにより、事故を未然に防止することができる。

また機器１０が修理された場合、機器１０は、例えば、修理後に最初に通信が確立された基地局３０の基地局ＩＤを、修理工場を示す情報としてサーバに２０に送信してもよい。また、機器１０は、修理後に最初に通信が確立された通信日時を、修理日時を示す情報としてサーバに送信してもよい。機器１０は、これらの情報を状態情報に含めてサーバ２０に送信してもよい。サーバ２０は、機器１０により送信された、上記の情報を修理情報として保存しておくことで、修理の履歴を管理することができる。

図１９に示されるように、機器１０は、初回通信確立時において、製造工場を示す情報および製造日時を示す情報を製造情報としてサーバ２０に送信してもよい。また、機器１０は、修理後における通信確立時において、修理工場を示す情報および修理日時を示す情報を修理情報としてサーバ２０に送信してもよい。なお、修理後であるか否かを示す情報は、修理工場の作業者が修理対象の機器１０が修理中または修理後であることを示す情報を機器１０の機器ＩＤと共にサーバ２０に送信することで、サーバ２０に当該機器１０が修理中または修理後であることを通知してもよい。

なお、機器１０は、送信した製造情報または修理情報を含む状態情報を保存してもよい。これにより、ユーザは、機器１０がネットワークと通信が確立されていなくても製造情報または修理情報を知ることができるし、機器１０は、ネットワークと通信が確立した時点で、製造情報または修理情報をサーバ２０に送信することができる。

次に、機器１０から通電状態が通知される場合のサーバ２０による処理について説明する。

機器１０は、例えば、機器１０の電源がオンであるかオフであるかを示す通電情報をサーバ２０に通知する。これにより、サーバ２０は、機器１０の設置状態を推定することができるほか、機器１０の通信機能の制御にも活用することができる。サーバ２０は、推定した結果に応じた通知をユーザに行う。これにより、サービス品質の向上につなげることができる。

図２０は、サーバ２０における機器１０の通電状態を判断する処理の第１の例を示すフローチャートである。

サーバ２０は、通電状態を含む状態情報を、基地局３０を介して機器１０から逐次受信しているものとする。

サーバ２０は、受信された状態情報を用いて、機器１０の通電状態であるか否か、つまり、電源がオンであるかオフであるかを判定する（Ｓ１）。

サーバ２０は、状態情報に含まれる通電状態が機器１０の電源がオンであることを示している場合（Ｓ１でＹｅｓ）、機器１０が通電している、つまり、電源がオンであると判断する（Ｓ２）。

サーバ２０は、状態情報に含まれる通電状態が機器１０の電源がオフであることを示している場合（Ｓ１でＮｏ）、機器１０が通信用バッテリ１１０を搭載しているか否かを判定する（Ｓ３）。なお、状態情報には、機器１０が通信用バッテリ１１０を搭載しているか否かを示すバッテリ情報が含まれていてもよく、サーバ２０は、バッテリ情報に基づいて、ステップＳ３の判定を行ってもよい。また、サーバ２０は、機器ＩＤを用いて機器１０の機器情報を外部機器から参照することで、ステップＳ３の判定を行ってもよい。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していると判定された場合（Ｓ３でＹｅｓ）、機器１０が通電していない、つまり、電源がオフであると判断する（Ｓ４）。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していないと判定された場合（Ｓ３でＮｏ）、機器１０の電源がオフであり、かつ、通知をすることができない状態（つまり、通知不可の状態）であると判断する（Ｓ５）。

このように、通電状態を通知する機能を有する機器１０により送信される状態情報によって、サーバ２０は、当該機器１０の設置状態を推定することができる。サーバ２０は、例えば、ステップＳ２のように機器１０が通電している状態であると判断した場合、工場でのテスト用や店頭での展示用、或いは使用者宅に設置され、少なくともすぐに使える状態であることがわかる。

一方で、サーバ２０は、ステップＳ４のように機器１０が通電していない状態と判断した場合、出荷前、輸送中、設置前など機器１０がすぐに使える状態にはないことがわかる。このため、サーバ２０は、例えば、通信する情報を少なくすることで通信量を抑制したり、通信頻度を低くさせる制御信号を、基地局３０を介して機器１０に送信することで、機器１０が通信用バッテリ１１０搭載の場合に、機器１０による通信用バッテリ１１０の消費電力を抑えることができる。

なお、サーバ２０は、直近に通知された情報以外にも、１つ前或いはそれ以上前の情報履歴も合わせて判断することで、機器１０の状態をより精度よく推定することができる。

図２１は、サーバ２０における機器１０の通電状態を判断する処理の第２の例を示すフローチャートである。

サーバ２０は、第１の例と同様に、通電状態を含む状態情報を、基地局３０を介して機器１０から逐次受信しているものとする。

サーバ２０は、受信された状態情報を用いて、機器１０の通電状態であるか否か、つまり、電源がオンであるかオフであるかを判定する（Ｓ１１）。

サーバ２０は、状態情報に含まれる通電状態が機器１０の電源がオンであることを示している場合（Ｓ１１でＹｅｓ）、機器１０が通信用バッテリ１１０を搭載しているか否かを判定する（Ｓ１２）。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していると判定された場合（Ｓ１２でＹｅｓ）、機器１０が通信用バッテリ１１０を搭載しており、かつ、通電している、つまり、電源がオンであると判断する（Ｓ１３）。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していないと判定された場合（Ｓ１２でＮｏ）、機器１０が通信用バッテリ１１０を搭載しておらず、かつ、通電している、つまり、電源がオンであると判断する（Ｓ１４）。

サーバ２０は、状態情報に含まれる通電状態が機器１０の電源がオフであることを示している場合（Ｓ１１でＮｏ）、機器１０が通信用バッテリ１１０を搭載しているか否かを判定する（Ｓ１５）。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していると判定された場合（Ｓ１５でＹｅｓ）、機器１０が通信用バッテリ１１０を搭載しており、かつ、通電していない、つまり、電源がオフであると判断する（Ｓ１６）。

サーバ２０は、機器１０が通信用バッテリ１１０を搭載していないと判定された場合（Ｓ１５でＮｏ）、機器１０が通信用バッテリ１１０を搭載しておらず、かつ、通電していない、つまり、通知をすることができない状態（つまり、通知不可の状態）であると判断する（Ｓ１７）。

なお、ステップＳ１２およびＳ１５の判定は、ステップＳ３と同様に行われる。

このように、通電状態およびバッテリ情報を通知する機能を有する機器１０により送信される状態情報によって、サーバ２０は、当該機器１０の設置状態または通信異常を推定することができる。サーバ２０は、例えば、通信用バッテリ１１０を搭載しており、かつ、通電している状態である機器１０について、少なくともすぐに使える状態である上に継続的な通信を期待することができると推定することができる。このため、サーバ２０は、当該機器１０からの通信が途絶えた場合には何か異常があったと推定することができる。また、サーバ２０は、例えば、通信用バッテリ１１０を搭載しておらず、かつ、通電している状態である機器１０について、その後の経過を監視する必要があると推測できる。これは、機器１０の状態が、電源コンセントが抜けている、ブレーカが落ちているなどで外部電源から電力の供給が絶たれていることで、通信が途絶える場合も考えられるためであり、必ずしも機器１０または通信経路に異常があったとは言えないからである。

なお、機器１０が通信用バッテリ１１０を搭載している場合には、機器１０は、通信用バッテリ１１０のバッテリ残量も状態情報に含めて通知してもよい。これにより、サーバ２０は、さらに、通信モジュール１０１の通信用バッテリ１１０のバッテリ切れを予測したり、検知したりすることができる。

なお、サーバ２０は、直近に通知された情報以外にも、１つ前或いはそれ以上前の情報履歴も合わせて判断することで、機器１０の状態をより精度よく推定することができる。

次に、機器から家電の種別情報の通知される場合のサーバ２０による処理について説明する。

機器１０は、例えば、機器１０（家電）の種別分類を示す種別情報をさらにサーバ２０に通知してもよい。これにより、サーバ２０は、機器１０の状態推定の精度をより高めることができる。サーバ２０は、推定された結果に応じた情報を、機器１０または操作機器４０に通知することで、ユーザに通知することができ、サービス品質の向上につなげることができる。

以下に、種別情報で示される種別分類の例を示す。種別分類は、例えば、大型ＩｏＴ家電、中型ＩｏＴ家電、および、小型ＩｏＴ家電を含む。つまり、機器１０は、大型ＩｏＴ家電、中型ＩｏＴ家電、および、小型ＩｏＴ家電のいずれかに分類される。

大型ＩｏＴ家電は、食器洗い機やビルトインＩＨコンロ、インタホンなど、設置に工事が必要なＩｏＴ家電である。中型ＩｏＴ家電は、テレビや冷蔵庫など、設置に工事は必要ないが持ち運びを想定していないＩｏＴ家電である。小型ＩｏＴ家電は、ドライヤやシェーバなど、設置に工事は必要ないが持ち運びも想定しているＩｏＴ家電である。

図２２は、サーバ２０における、通電状態でない機器１０の設置状態を推定する処理の一例を示すフローチャートである。

サーバ２０は、例えば、図２０または図２１における処理において、通信用バッテリ１１０の搭載または非搭載にかかわらず、通電状態でないと判断された場合において、以下の処理を実行する。

サーバ２０は、機器１０の使用履歴があるか否かを判定する（Ｓ２１）。サーバ２０は、例えば、記憶部２０３に記憶している機器１０の状態情報において、電源がオンを示す状態情報を含まない場合に、当該機器１０の使用履歴がないと判断し、電源がオンを示す状態情報を含む場合に、当該機器１０の使用履歴があると判断する。

サーバ２０は、機器１０の使用履歴があると判定された場合（Ｓ２１でＹｅｓ）、当該機器１０が小型ＩｏＴ家電であるか否かを判定する（Ｓ２２）。

サーバ２０は、機器１０が小型ＩｏＴ家電であると判定された場合（Ｓ２２でＹｅｓ）、当該機器１０が自宅外にあるか否かを判定する（Ｓ２３）。サーバ２０は、例えば、機器１０の状態情報と共に受信した基地局３０の基地局ＩＤがユーザの自宅周辺の基地局３０の基地局ＩＤと一致するか否かを判定することで、当該機器１０が自宅外であるか否かを判定する。なお、基地局ＩＤがユーザの自宅周辺の基地局３０の基地局ＩＤであるか否かは、ユーザが自宅に機器１０を設置した時に、機器１０を自宅に設置したことを示す情報をサーバ２０へ機器１０に送信させることで、サーバ２０には状態情報と共に自宅周辺の基地局３０の基地局ＩＤが通知される。サーバ２０は、機器１０を自宅に設置したことを示す情報と共に受信した基地局ＩＤをユーザの自宅周辺の基地局の基地局ＩＤとして保存しておくことで、ステップＳ２３の判定を行うことができる。

サーバ２０は、機器１０が自宅外にあると判定された場合（Ｓ２３でＹｅｓ）、ユーザが当該機器１０を所持して旅行していると判断する（Ｓ２４）。

サーバ２０は、機器１０が自宅内にあると判定された場合（Ｓ２３でＮｏ）、ユーザが当該機器１０を自宅で使用している（つまり、通常使用している）と判断する（Ｓ２５）。

サーバ２０は、機器１０が小型ＩｏＴ家電でないと判定された場合（Ｓ２２でＮｏ）、機器１０が中型ＩｏＴ家電であるか否かを判定する（Ｓ２６）。

サーバ２０は、機器１０が中型ＩｏＴ家電であると判定された場合（Ｓ２６でＹｅｓ）、機器１０のユーザが節電家であるか否かを判定する（Ｓ２７）。サーバ２０は、例えば、予めユーザにより、機器１０のユーザ登録が行われた時に入力された情報に基づいて、ユーザが節電家であるか否かを判定してもよい。つまり、ユーザ登録において、ユーザは、ユーザが節電家であるか否かを示す入力を、操作機器４０を用いて行い、操作機器４０は、当該入力に基づいてユーザが節電家であるか否かを示す情報をサーバ２０に送信していてもよい。

サーバ２０は、ユーザが節電家であると判定された場合（Ｓ２７でＹｅｓ）、機器１０がユーザにより節電中であると判断する（Ｓ２８）。

サーバ２０は、中型ＩｏＴ家電でないと判定された場合（Ｓ２６でＮｏ）、または、ユーザが節電家でないと判定された場合（Ｓ２７でＮｏ）、ユーザは、機器１０を使用していない、引っ越し中である、機器１０を廃棄した、および、機器１０を他のユーザに譲渡した、のいずれかを行ったと判断する（Ｓ２９）。

サーバ２０は、機器１０の使用履歴がないと判定された場合（Ｓ２１でＮｏ）、機器１０が未使用であると判断する（Ｓ３０）。

次に、サーバ２０による機器１０の通信頻度を制御する方法について説明する。

サーバ２０は、通知内容または過去に通知された内容に基づいて、機器１０の状態を推定することができる。機器１０の中には、使われる時期が限られている扇風機など、常時通電していないものもある。このような常時通電していない機器１０は、通信用バッテリ１１０を搭載することで、機器１０が外部電源から電力の供給を受けていなくても、状態情報をサーバ２０に通知することができる。しかしながら、機器１０は、頻繁に通信を行うと通信用バッテリ１１０に蓄えられている電力を早く消耗してしまう。つまり、通信頻度を適切に制御すれば、通信用バッテリ１１０を長もちさせることができると共に、通信量を抑制することもできる。

図２３は、非通電状態の機器１０の通信頻度をサーバ２０が制御する処理の一例を示すシーケンス図である。図２４は、サーバ２０により決定される更新間隔と、非通電状態になってからの経過時間との関係を示すグラフである。

機器１０は、例えば、時刻ｔ０から非通電状態になっており、サーバ２０に対して時刻ｔにｎ回目の情報通知（ｎ）を行う（Ｓ５１）。

サーバ２０は、機器１０が非通電状態になってからの経過時間から図２４に示すグラフに従って更新間隔（ｉ）を算出し、機器１０に次回通知時刻（ｔ＋ｉ）を指定する制御信号を通知情報として送信する（Ｓ５２）。

すると、機器１０は、ステップＳ５２で受信した制御信号で指定された次回通知時刻（ｔ＋１）において、ｎ＋１回目の情報通知（ｎ＋１）を行う（Ｓ５３）。以降では、ステップＳ５３をステップＳ５１に置き換えた上で、ステップＳ５２およびステップＳ５３が繰り返される。

これにより、機器１０が非通信時には部分的に電力をカットするなどしてバッテリの消費を最低限に抑えることができる。また、機器１０は、非通電時には通知内容が変わる可能性が低い。このため、サーバ２０は、非通電状態が長く続くにつれて、機器１０による情報通知の更新間隔を長く設定する。これにより、機器１０は、頻繁に情報通知を行うことによる通信用バッテリ１１０の電力を消費することを抑えることができる。なお、機器１０は、通電状態になった際には、指定された更新時刻に関わらず状態情報を通知してもよい。これにより、機器１０の状態が変化して通知内容が変化した場合にも、サーバ２０は変化した通知内容を受信することができる。

例えば、扇風機、ヒータなど季節によって通電しない時期がある機器１０の場合、サーバ２０は、機器１０が非通電状態になってからの経過時間が５日以下の場合は更新間隔を１日にし、非通電状態になってからの経過時間が５日より長くて２５日以下の場合は更新間隔を５日にし、２５日よりも長い間非通電状態にある場合は更新間隔を２５日にしてもよい。これにより、非通電状態が長くなるにつれて更新間隔も長くなるため、通信用バッテリ１１０の電力を消費することを抑えることができる。

また冷蔵庫などのように、常に通電していると想定される機器１０の場合、サーバ２０は、例えば、機器１０が非通電状態になってから５日以上経った場合には、使われていないと判断し、更新間隔を２５日にすることで、通信用バッテリ１１０の電力を消費することを抑えることができる。

また、ドライヤ、シェーバなどのように、持ち運ぶことが想定される機器１０の場合、サーバ２０は、機器１０が非通電状態になってからの経過時間が７日以下の場合の更新間隔を８時間にして機器１０の位置を追跡できるようにし、非通電状態になってからの経過時間が７日より長い場合には更新間隔を１日にすることで、通信用バッテリ１１０の電力を消費することを抑えることができる。

なお、通信頻度の制御は、サーバ２０により行われなくてもよい。例えば、機器１０は、非通電状態になってからの経過時刻を保持し、経過時刻から次回の更新時刻を算出することで、次回の更新時刻を自ら制御してもよい。

次に、通知内容を保持する保持部１０８Ａを有する機器１０Ａについて説明する。機器１０Ａは、保持部１０８Ａを有することにより、非通電状態であっても必要最小限の電力で通知を行うことができる。

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

図２５に示されるように、機器１０Ａは、機器１０と比較して本体用バッテリ１１３を備える点と、保持部１０８の代わりに保持部１０８Ａを備える点とが異なる。

この場合、制御部１０４は、当該制御部１０４の制御状態を、保持部１０８Ａに逐次記憶させている。

保持部１０８Ａは、制御部１０４による制御状態を逐次保持する。保持部１０８Ａに制御状態が保持される場合、通信モジュール１０１は、機器１０の電源がオフである場合に、保持部１０８Ａに逐次保持された制御状態を読み出して、読み出された制御状態を状態情報として基地局３０を介してサーバ２０に送信してもよい。

このように、機器１０Ａは、非通電状態であってもサーバ２０への通知に必要な情報を保持することができる保持部１０８Ａを備えており、非通電状態であっても機器１０Ａ全体に電力を供給することなしに必要な情報をサーバ２０に通知することができる。

例えば、機器１０Ａの本体用バッテリ１１３のバッテリ情報は、通信用バッテリ１１０からの電力の供給を受けている通信モジュール１０１以外で保持されている場合がある。このため、保持部１０８Ａがない構成の場合に、通信モジュール１０１は、本体用バッテリ１１３のバッテリ情報を取得するために、本体用バッテリ１１３のバッテリ情報を保持しているブロック（例えば、制御部１０４の図示しない記憶部）に電力を供給する必要がある。しかしながら、機器１０Ａは保持部１０８Ａを備えているため、通電状態にある時に本体用バッテリ１１３のバッテリ情報を保持部１０８Ａにコピーしておくことで、機器１０Ａが非通電状態になっても通信モジュール１０１に給電するのみで本体用バッテリ１１３のバッテリ情報をサーバ２０に通知することができる。なお、制御部１０４は、本体用バッテリ１１３のバッテリ情報以外の制御状態を保持部１０８Ａに保持させておき、通信モジュール１０１は、保持部１０８Ａに保持されている制御状態を状態情報としてサーバ２０に送信してもよい。

なお、通信モジュール１０１は、サーバ２０へ前回通知した内容との差分をサーバ２０に通知することで、通信量を削減してもよい。

次に、機器１０の仕向地情報について説明する。機器１０は、例えば当該機器１０の仕向地を示す仕向地情報を通知してもよい。これにより、サーバ２０は、本来の仕向地とは異なる地域で機器１０が使用された場合に、機器１０の設定を、機器１０が設置されている地域に適した設定に自動的に変更させることができる。

図２６は、機器１０の使用時に機器１０が設置されている地域を取得する方法の例を示す図である。

機器１０は、例えば、製造時に仕向地（対応地域）がわかる情報をサーバ２０に通知し、サーバ２０は、その情報を保存しておく。機器１０がユーザによって使われる際には、（１）機器１０は近隣の基地局３０に機器１０の機器ＩＤを通知する。そして、（２）基地局３０は、機器ＩＤと通信が確立した基地局ＩＤの情報をサーバ２０に通知する。

サーバ２０は、通知された情報を元に、機器１０の仕向地（対応地域）と実際に機器１０が使われている設置地域とが同じか否かを判定する。サーバ２０は、仕向地と設置地域とが同じでない場合、機器１０に設定変更をさせる指示を通知情報として送信し、設置地域の特性および性質に合わせた設定に変更する。変更する設定の例としては、メニュー画面の言語、テレビのチャンネル情報、交流周波数、水質、気温、湿度、降水量などである。

次に、在庫状態でファームウェア情報を通知する機能を備えた機器１０について説明する。

図２７は、機器１０の流通経路におけるファームウェアバージョンを通知する例について説明するための図である。

家電は、メーカの工場で製造されてから、メーカ所有、卸の物流拠点、小売店等の複数の拠点を経由し、購入されたユーザ宅に届けられる。

また、家電は、製造および販売が継続されていく中で修正または改良が行われてファームウェアが変更されることがある。このため、ファームウェアが変更されたか否かを管理するために、ファームウェアバージョンも合わせて変更されることが一般的である。

ユーザにとっても製造している家電メーカにとっても、ユーザが、修正または改良が行われた最新ファームウェアバージョンの家電を購入し使用することが望ましい。しかしながら、家電、製造されてから複数の拠点を経由する段階で在庫が発生することがあるため、工場側で最新の家電が製造出荷されたとしても、ユーザ宅に届くまでに家電には修正または改良が行われている可能性がある。このため、ユーザには、修正・改良前の家電、つまり、ファームウェアバージョンが変更されていない家電が届くことがある。また、在庫されている家電のファームウェアバージョンを確認したり、判断したりすることは、拠点の手間を考えても困難である。

そこで、機器１０は、在庫状態であっても、ネットワークに接続することでファームウェア情報をサーバ２０に通知する。これにより、サーバ２０は、ファームウェア情報と共に機器１０が通信した基地局３０の基地局ＩＤも取得するため、機器１０が存在する位置も把握できる。このため、サーバ２０は、どの拠点にどのファームウェアバージョンの機器１０が在庫されているか推定することが可能になる。サーバ２０は、さらにその情報を元に、古いファームウェアバーションの機器１０を出荷させない指示を通知情報として、拠点側の端末へ通知することで、修正または改良前の機器１０がユーザに届いてしまう状況を削減できる。

次に、ＥＣサービスと連携した家電管理サービスにおけるユーザと機器１０との紐付ける処理について説明する。

図２８は、ＥＣサービスと連携した家電管理サービスにおけるユーザと機器１０との紐付ける処理について説明するための図である。

家電の流通経路は、工場、物流拠点、小売店等の複数を経由し、家電を購入したユーザ宅に届けられるのが一般的である。家電には、個体識別用の機器ＩＤが製造段階で埋め込まれることが多い。また、ユーザの家電の購入機会は、小売店以外にもＥＣサービスによるネット購入も増加している。各ＥＣサービスは、専用の会員カードを発行し、購入金額に合わせて割引可能なポイントを付与するサービスも行っていることが多い。

一方、家電メーカ等が提供する家電管理サービス等では、ユーザと購入家電の機器ＩＤとの紐付け登録が行われる必要がある。しかしながら、当該家電の機器ＩＤを事前もしくは流通過程で把握することが困難なため、現状では、ユーザが当該サービスサイトにアクセスして購入した家電の機器ＩＤを登録する必要があり、手間がかかる。また、ユーザは、機器ＩＤを登録しても、ユーザメリットが乏しいため、ユーザによる家電の登録件数が増加しないという課題がある。

そこで、例えば、機器１０は、機器ＩＤをサーバ２０に通知することで、サーバ２０は、機器ＩＤと共に機器１０が通信した基地局３０の基地局ＩＤも取得する。これにより、家電管理サービスが機器ＩＤと機器１０が存在する位置を示す位置情報とを把握できれば、家電管理サービスとＥＣサービスとが連携することで、家電管理サービスが把握している機器ＩＤおよび位置情報と、ＥＣサービスが把握しているユーザＩＤ・購入家電情報・発送先情報とを照合することで紐付け予測が可能である。また、ユーザがＥＣサイトにログインした状態で、購入した家電に付帯の家電機器ＩＤが記載されたＱＲコード（登録商標）等をスマホ等の操作機器４０で読取し、ＥＣサイトのユーザＩＤと合わせて家電管理サービスへ受領通知を送信することにより、その紐付けの登録を確定できる。さらに、ユーザが操作機器４０を操作することで受領通知の送信を行った場合、連携するＥＣサービスの割引ポイント等をユーザに付与することで、ユーザにメリットが生まれる。これにより、ユーザに、購入した機器１０を登録させることを促すことができる。なお、ＥＣサービスがユーザに付与する割引ポイントの原資については、流通経路の省略のよるコスト削減で捻出することも可能である。

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

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

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

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

１ 機器管理システム
１０、１０Ａ 機器
２０ サーバ
３０ 基地局
４０ 操作機器
１０１ 通信モジュール
１０２ 保持部
１０４ 制御部
１０７ 機能モジュール
１０８、１０８Ａ 保持部
１０９ 電源部
１１０ 通信用バッテリ
１１１ 操作部
１１２ 表示部
１１３ 本体用バッテリ
２０１ 通信部
２０２ 制御部
２０３ 記憶部

Claims (8)

1. ネットワークに通信接続されているサーバと、
   前記ネットワークに通信接続されている、遠距離無線通信の基地局と、
   前記基地局に通信接続する機器であって、当該機器の状態を示す状態情報を、前記基地局を介して前記サーバに送信する機器と、を備え、
   前記機器は、
   前記基地局と前記遠距離無線通信用の通信モジュールと、
   前記通信モジュールを駆動する電力を前記通信モジュールに供給する通信用バッテリと、
   前記機器の電源がオンである場合に、前記機器の動作を制御する制御部と、
   前記制御部による制御状態を逐次保持し、かつ、非通電時において情報を保持可能な記憶装置である保持部と、を有し、
   前記通信モジュールは、前記機器の電源がオフである場合に前記通信用バッテリの電力を用いて、前記保持部に前記機器の電源がオンである場合に逐次保持された前記制御状態を、読み出して、読み出された前記制御状態を前記状態情報として前記基地局を介して前記サーバに送信する
   機器管理システム。
2. 前記基地局は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）の基地局であり、
   前記通信モジュールは、前記ＬＰＷＡの通信モジュールである
   請求項１に記載の機器管理システム。
3. 前記状態情報は、前記機器が通電しているか否かを示す通電状態を含む
   請求項１または２に記載の機器管理システム。
4. 前記サーバは、前記機器から前記状態情報を受信し、受信された前記状態情報に応じて通知情報を生成し、生成された通知情報を前記機器に送信する
   請求項１から３のいずれか１項に記載の機器管理システム。
5. 機器であって、
   遠距離無線通信の基地局に通信接続する通信モジュールであって、前記機器の状態を示す状態情報を、前記基地局を介して、前記基地局にネットワークで通信接続されているサーバに送信する通信モジュールと、
   前記通信モジュールを駆動する電力を前記通信モジュールに供給する通信用バッテリと、
   前記機器の電源がオンである場合に、前記機器の動作を制御する制御部と、
   前記制御部による制御状態を逐次保持し、かつ、非通電時において情報を保持可能な記憶装置である保持部と、を備え、
   前記通信モジュールは、前記機器の電源がオフである場合に前記通信用バッテリの電力を用いて、前記保持部に前記機器の電源がオンである場合に逐次保持された前記制御状態を、読み出して、読み出された前記制御状態を前記状態情報として前記基地局を介して前記サーバに送信する
   機器。
6. 前記基地局は、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ， Ｗｉｄｅ Ａｒｅａ）の基地局であり、
   前記通信モジュールは、前記ＬＰＷＡの通信モジュールである
   請求項５に記載の機器。
7. 前記状態情報は、前記機器が通電しているか否かを示す通電状態を含む
   請求項５または６に記載の機器。
8. ネットワークに通信接続されているサーバと、ネットワークに通信接続されている、遠距離無線通信の基地局と、前記基地局に通信接続する機器とを備える機器管理システムにおける機器管理方法であって、
   前記機器では、前記機器の状態を示す状態情報を、遠距離無線通信の基地局を介して、前記基地局にネットワークで通信接続されているサーバに送信し、
   前記機器は、前記基地局と前記遠距離無線通信用の通信モジュールを有し、
   前記機器では、
   前記機器の電源がオンである場合に、前記機器の制御状態を前記機器が有する保持部であって、非通電時において情報を保持可能な記憶装置である保持部に逐次保持し、
   前記機器の電源がオフである場合に、
   前記機器が有する通信用バッテリの電力で駆動された前記通信モジュールが、前記保持部に前記機器の電源がオンである場合に逐次保持された前記制御状態を読み出し、
   前記通信モジュールが、読み出された前記制御状態を、前記状態情報として前記基地局を介して前記サーバに送信する
   機器管理方法。

Images