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

Abstract

サーバ（２０）と、遠距離無線通信の複数の基地局（３０）と、複数の基地局のうちの一の基地局に通信接続する少なくとも１つの機器であって、それぞれが当該機器の現在の稼働状態を示す稼働情報を、一の基地局を介してサーバに逐次送信する少なくとも１つの機器（１０）と、を備え、複数の基地局のそれぞれは、稼働情報を逐次受信すると、逐次受信された稼働情報と共に当該基地局に固有の情報である固有情報をサーバに逐次送信し、サーバは、稼働情報および固有情報を逐次受信し、逐次受信された稼働情報および固有情報を対応付けて逐次記憶し、第１のタイミングで受信された第１固有情報と、第２のタイミングで受信された第２固有情報とが異なる場合、第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する。

Description

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

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

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

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

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

本開示の一態様に係る機器管理システムは、ネットワークに通信接続されているサーバと、前記ネットワークに通信接続されている、遠距離無線通信の複数の基地局と、前記複数の基地局のうちの一の基地局に通信接続する少なくとも１つの機器であって、それぞれが当該機器の現在の稼働状態を示す稼働情報を、前記一の基地局を介して前記サーバに逐次送信する少なくとも１つの機器と、を備え、前記複数の基地局のそれぞれは、前記稼働情報を逐次受信すると、逐次受信された前記稼働情報と共に当該基地局に固有の情報である固有情報を前記サーバに逐次送信し、前記サーバは、前記稼働情報および前記固有情報を逐次受信し、対応するタイミングで逐次受信された前記稼働情報および前記固有情報を対応付けて逐次記憶し、第１のタイミングで受信された第１固有情報と、前記第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なる場合、前記第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、前記第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する。

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

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

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

本開示の一態様に係る機器管理システムは、ネットワークに通信接続されているサーバと、前記ネットワークに通信接続されている、遠距離無線通信の複数の基地局と、前記複数の基地局のうちの一の基地局に通信接続する少なくとも１つの機器であって、それぞれが当該機器の現在の稼働状態を示す稼働情報を、前記一の基地局を介して前記サーバに逐次送信する少なくとも１つの機器と、を備え、前記複数の基地局のそれぞれは、前記稼働情報を逐次受信すると、逐次受信された前記稼働情報と共に当該基地局に固有の情報である固有情報を前記サーバに逐次送信し、前記サーバは、前記稼働情報および前記固有情報を逐次受信し、対応するタイミングで逐次受信された前記稼働情報および前記固有情報を対応付けて逐次記憶し、第１のタイミングで受信された第１固有情報と、前記第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なる場合、前記第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、前記第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する。

このため、例えば、現在の機器のユーザの使用に基づく稼働情報を管理するため、ユーザの使用状態に適した機器の状態を判定することができる。このように、当該ユーザ以外のユーザなどによる使用に基づく稼働情報を除外して機器の管理を行うことができるため、機器の管理を効率よく行うことができる。

また、前記サーバは、前記複数の第１稼働情報を第１識別子と対応付けて記憶し、かつ、前記複数の第２稼働情報を前記第１識別子とは異なる第２識別子と対応付けて記憶することで、前記複数の第１稼働情報と、前記複数の第２稼働情報とを分けて管理してもよい。

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

また、前記第２識別子は、前記第２期間において前記少なくとも１つの機器を利用しているユーザに対応付けられていることを示す識別子であり、前記サーバは、前記第２のタイミングの後の第３のタイミングで受信された第３固有情報が前記第２固有情報と異なる場合、前記少なくとも１つの機器が移動したと判断し、前記少なくとも１つの機器のユーザが他のユーザに変更されたか否かの問い合わせを、前記少なくとも１つの機器または前記ユーザが所有する端末に送信してもよい。

このため、例えば機器の譲渡が為されたか否かを効果的に判定することができる。

また、前記サーバは、前記問い合わせを送信した後に、前記少なくとも１つの機器または前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器のユーザが前記他のユーザに変更されたことを示す場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を、前記複数の第１稼働情報および前記複数の第２稼働情報とは分けて管理してもよい。

これによれば、例えば機器の譲渡が為された場合に、譲渡前のユーザによる稼働情報とは分けて管理するため、譲渡後のユーザに適した機器の状態を判定することができる。

また、前記サーバは、前記問い合わせを送信した後に、前記少なくとも１つの機器または前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器のユーザが前記他のユーザに変更されていないことを示す場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を前記複数の第２稼働情報と共に管理してもよい。

このため、例えば機器の譲渡が為されずに機器が移動した場合には、ユーザを変更せずに機器の管理を行うことができる。

また、前記少なくとも１つの機器は、複数の機器であり前記サーバは、前記第２のタイミングで前記複数の機器から受信された複数の前記第２固有情報が互いに同じであり、かつ、前記第２のタイミングの後の第３のタイミングで前記複数の機器から受信された複数の第３固有情報が互いに同じであり、かつ、前記第２固有情報と、前記第３固有情報とが異なる場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を前記複数の第２稼働情報と共に管理してもよい。

このため、例えば複数の機器が移動した場合には、ユーザが変更されていないと見なして、機器の管理を行うことができる。

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

このため、当該機器の管理をしないため、管理にかかる処理負荷を低減することができる。

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

このため、当該機器の管理をしないため、管理にかかる処理負荷を低減することができる。

また、前記第２識別子は、前記第２期間において前記少なくとも１つの機器を利用しているユーザに対応付けられていることを示す識別子であり、前記サーバは、前記第２のタイミングの後の第３のタイミングで受信された第３固有情報が前記第２固有情報と異なる場合、前記少なくとも１つの機器が移動したと判断し、前記少なくとも１つの機器が盗難されたか否かの問い合わせを、前記ユーザが所有する端末に送信し、前記問い合わせを送信した後に、前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器が盗難されたことを示す場合、機器を使用できないようにロックする制御信号を前記少なくとも１つの機器に送信し、前記少なくとも１つの機器は、前記制御信号を受信すると、当該機器を使用できないようにロックしてもよい。

このため、機器が盗難された場合に、他のユーザが機器を使用できないようにロックすることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１５は、家電の生涯管理について説明するための図である。

ＬＰＷＡ技術の特徴は、例えば、下記の２点である。

１つ目は、ユーザが設定することなくクラウドとの通信が可能である点である。つまり、全てのＩｏＴ家電をクラウドに接続させ、機器固有ＩＤと通信モジュールＩＤを管理することで、クラウドは、家電機器の稼働状態把握が可能となる。

２つ目は、上記のＩＤ管理情報と通信網から得られる情報による家電機器の概算位置情報の取得が可能である点である。つまり、クラウドは、ＩｏＴ家電がどこで使われているかが把握可能となる。

このように、ＬＰＷＡ技術を採用することで、クラウドは、全てのＩｏＴ家電の稼働状況、位置情報を把握可能となり、家電機器の生涯管理が可能となる。この生涯管理により、購入・設置に始まり、引っ越しなどの転機、廃棄までの家電利用シーンに応じた適切な機能提供を実現することができる。

このように、本開示は、家電機器がどの状態にあるのかを判断する方法と各状態に応じて提供する機能に関する。

常時接続ＩｏＴ家電に搭載する通信モジュールには、下記２つのモデルが考えられる。２つのモデルとは、（１）通信モジュール内にバッテリが装着されていない未装着モデル、および、（２）通信モジュール内にバッテリが装着されている装着モデルである。

（１）のモデルの通信モジュールは、電源がオンとなる通電開始時に通信を開始する。これにより、クラウドに位置情報、利用頻度、設定されているメニュー項目の情報などがアップロードされる。そして、クラウドは、アップロードされた情報から対応する家電機器が店頭に置かれてデモをしている状態、ユーザの宅内に設置され使用されている状態、引っ越しまたは転売直後の状態、長期間未使用状態などのような機器の状態を推定することができる。

（２）のモデルの通信モジュールは、バッテリを有しているため、外部電源からの通電が無くてもクラウドと通信することが可能である。このため、クラウドは、（２）のモデルに対して、（１）のモデルでは推定できない、または困難だった状態の推定も可能である。例えば（１）のモデルについて、外部電源から通電されていない状態、例えば、廃棄されたのか、長期間未使用状態で保管されているのかの推定が困難だった。（２）のモデルはバッテリにより外部電源からの通電が無い場合であっても通信可能となるため、（１）のモデルよりも多くの推定可能なケースが存在する。例えば、クラウドは、（２）のモデルが最後に通信した際の位置情報が焼却場やリサイクルセンター等であれば廃棄と推定することができる。他にも、クラウドは、（２）のモデルについて、過去に使用していた際と同じ位置情報のまま、利用頻度０の状態が続いていれば長期間未使用状態と推定することができる。また、クラウドは、（２）のモデルの通信モジュールを搭載している家電機器であれば、家電機器が不法投棄されてしまったケースも検知することができる。

このように、クラウドは、常時接続ＩｏＴ家電から様々な情報を取得するため、取得された情報に基づいて様々な家電機器の状態を予測し、使い初めから廃棄までの「家電機器の生涯」の間において状況に応じた機能提供を実現することができる。

家電機器が常時クラウドに接続していることで、万が一、製品をリコールするような事態になっても、クラウドは、出荷後も機器と通信接続され、機器の状態をトレースできる。このため、クラウドは、リコールの対象製品に対し、故障の告知、強制停止等の対応を実行できる。製造メーカは、機器をトレースできていることで、リコール対応の進捗を正確に把握することができ、状態不明の機器に対する対応費用を大幅に削減できるというメリットがある。また、新しい機能提供、使い勝手の向上のためのソフトウェアアップデートなどの出荷後の機能拡張開発に関しても、第三世代ではクラウドへの接続率の低さからお客様価値に繋がりにくかったが、常時接続が可能な第四世代では、付加価値をお客様にきちんと提供できるようになる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、サーバ２０がＬＰＷＡを用いた常時接続により機器１０から日々の「位置情報」を収集する場合の例について説明する。

図２０および図２１は、使用開始日時時点の位置から現在日時時点の位置までの移動距離の一例を表したグラフである。

ＬＰＷＡを用いた常時接続により、機器１０からサーバ２０に集められる位置情報は、これまでの家電機器がネットワークに接続される形態では実現できなかった状態予測が可能とするための重要な要素のひとつである。また、機器１０の電源が入の時、通信モジュール１０１は、サーバ２０へ稼働情報を逐次送信する。このため、サーバ２０では、現在日時までに逐次送信され、蓄積されたデータのうちで最も古い送信日時が、ユーザが機器１０を使用し始めた日時（以下、「使用開始日時」とも言う。）であると判断できる。

図２０および図２１は、機器１０の使用開始日時の位置情報とデータ送信日時の位置情報との間の距離を算出した値を縦軸に、使用開始日時からの経過日数を横軸にしたグラフである。図２０のグラフにおいて、線が無い区間は家電機器の電源が切の状態であったことを表す。図２０および図２１では、横軸に平行な線は、家電機器が同一場所に存在することを示し、垂直の線は移動したことを表す。家電機器は、基本宅内の範囲で使用されるため、移動の検知は状態予測を行う上で重要なポイントとなる。

一方、図２１は、家電機器に通信モジュール用バッテリを内蔵した場合のグラフ例である。これにより、家電機器の電源状態に関わらず通信モジュールは稼働状態データをクラウドに送信することができるため、当該家電機器の電源が切の場合であっても、当該家電機器の移動トレースが可能となる。

次に、機器１０がＬＰＷＡ常時接続により、日々の「稼働回数」が収集される場合の例について説明する。

図２２は、稼働回数を「積算」で集計したグラフである。図２３は、稼働回数を「日毎」で集計したグラフである。

機器１０のＬＰＷＡ常時接続により、サーバ２０に稼働情報として集められる日々の稼働回数は、これまでの家電機器とネットワーク接続方法では実現できなかった状態予測が可能となる重要な要素のひとつである。これまで以上に家電機器の状態把握が容易になるとともに、あらゆる家電機器に適用することで、それを前提とした家電機器の状態予測も可能となる。

図２２は、機器１０の稼働回数を積算して算出した値を縦軸に、使用開始日時からの経過日数を横軸にしたグラフである。図２２のグラフにおいて、線が無い区間もしくは横軸に平行な線は、家電機器が未稼働な状態であることを表す。長期間における稼働回数の変遷の確認を目的としている。

図２３は、機器１０の稼働回数を日毎に算出した値を縦軸に、使用開始日時からの経過日数を横軸にしたグラフである。図２３のグラフにおいて、線が無い区間もしくは値が０の時は、機器１０が未稼働な状態であることを表す。短期間または中期間における稼働回数の増減パターンの確認を目的としている。

サーバ２０は、ＬＰＷＡ常時接続により、複数の機器１０全ての使い始めから廃棄までの位置情報や稼働状況を把握できるようになり、これらの情報を活用した家電の状態ごとの機能提供が可能となる。具体的な機能提供の例は、家電を購入し、設置したタイミングでＷｉ−Ｆｉ接続をサポートすること、引っ越しの直後や家庭内の住人が増えたタイミングで広告を提供することや、家電の廃棄を検知することでリコール対象から除外することなどである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバ２０は、取得された機器コードを、予めサーバ側で管理されている機器情報に基づいて対応する機器１０の通信アドレスに変換する。通信アドレスに変換できれば、サーバ２０は、当該機器１０に対して表示部１１２での明滅を指示する制御信号を送信する（Ｓ３４）。なお、この明滅指示の制御信号については、サーバ２０による成りすましを防止するための仕組みが必要である。成りすましの防止ができなければ、擬似サーバを利用することによって、悪意のある第三者のユーザアカウントと機器１０とを紐付けることが可能となってしまう。成りすましの防止のためには、例えばサーバ２０の公開鍵を予め機器１０で保持しておき、サーバ２０からの明滅指示は時変要素を加えた上で通知し、全体にサーバ２０の秘密鍵による署名を付与することなどが望ましい。

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

サーバ２０は、入力を受信すると、ユーザアカウントと機器１０との紐付けを完了し、完了通知を操作機器４０に送信する（Ｓ３６）。なお、サーバ２０は、入力を待つ期間を定めておくことが望ましい。通常は１分程度とする必要がある。サーバ２０は、明滅指示の制御信号を送信してから、カウントを開始し、入力を待つ期間が経過しても入力を受信できない場合、紐付けが失敗した旨の完了通知を操作機器４０に送信してもよい。

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

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

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

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

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

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

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

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

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

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

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

この要求に対してサーバ２０は、ワンタイムパスワードを機器１０に送信する（Ｓ５４）。発行されたワンタイムパスワードは、機器１０の表示部１１２で表示される。

操作機器４０は、表示部１１２に表示されたワンタイムパスワードの入力をユーザから受け付け、入力されたワンタイムパスワードをサーバ２０に送信する（Ｓ５５）。なお、図３３では、ワンタイムパスワードをそのまま送付するとしているが、実際にはログイン情報を用いて処理した結果を送付することが望ましい。処理の方法としては、機器コードだけではなくセッションを識別するためのＩＤを機器コードに付与した上で、先述した鍵データで暗号化するなどの方法が想定される。また、通信全体をＳＳＬなどの暗号化通信で保護することも好ましい。

サーバ２０は、操作機器４０から受け取ったワンタイムパスワードが予め発行したワンタイムパスワードと一致しているかを確認し、一致を確認した段階でユーザアカウントと機器ＩＤを紐付ける。サーバ２０は、紐付けの完了通知を操作機器４０に送信する（Ｓ５６）。なお、サーバ２０は、入力を待つ期間を定めておくことが望ましい。通常は１分程度とする必要がある。サーバ２０は、ワンタイムパスワードを送信してから、カウントを開始し、入力を待つ期間が経過しても入力を受信できない場合、紐付けが失敗した旨の完了通知を操作機器４０に送信してもよい。

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

次に、機器１０の状態予測について説明する。まず、機器１０の使用開始からユーザ使用中の予測ケースについて説明する。

図３４および図３５は、ユーザ使用中の予測ケースのグラフの一例を示す図である。

機器１０が製造工場から出荷され、ユーザが使用を開始し、現在も使用中と予測したケースの例である。サーバ２０は、ユーザが機器１０の使用を開始した日時からの経過日数が、当該製品の耐用年数、耐用使用回数を超過している場合は、家電上のＬＥＤ／ディスプレイ等に通知したり、サーバからの制御で強制的に動作しない様にする制御信号を機器１０に送信してもよい。なお、通知は、ユーザが所有する操作機器４０に送信されてもよい。他にも、サーバ２０は、図３５に示されるような稼働回数からフィルター等の消耗品の交換を促す情報や、洗濯槽の掃除等の点検を促す情報を機器１０またはユーザの操作機器４０に送信することで、より製品をより万全の性能でご利用いただくことが可能となる。

次に、家電機器の生涯管理のうちのユーザが使用中の期間について説明する。

図３６は、ＬＰＷＡによる常時接続ＩｏＴ家電の一例を示したものである。

この例では、Ｗｉ−Ｆｉ ＧＷのない環境においてもスマートフォンからＩｏＴ家電制御クラウド、ＬＰＷＡ回線網を通じて家電の遠隔操作をすることができ、更にはＬＰＷＡの機能を持たない外部サービス群からのサービス提供もＩｏＴ家電制御クラウドを通じて利用することを示している。

また、ＩｏＴ家電制御クラウドからの制御以外にも家電側から家電の状態を通知するログをＬＰＷＡ回線網経由でＩｏＴ家電制御クラウドに送信することもできる。サーバ２０は、送られてきたログから家電の故障を検知した場合などにユーザに通知するなど、購入後の家電に対するアフターサービスを可能としている。

図３７は、ＬＰＷＡによる家電機器とユーザ紐付けサポート機能について説明するための図である。

家電機器とユーザとを紐付ける方法に関しては上述したとおりである。ここでは複数の家電機器が宅内ある状態で、紐付け完了している家電機器と紐付けされていない家電機器が混在しているケースにおいて、ＬＰＷＡを用いた紐付けサポート機能を示す。図３７の例においてはエアコンの紐付けを完了し、洗濯機、冷蔵庫はまだ紐付け完了していない状態であることが示されている。

エアコンの紐付けが終わったタイミングで紐付け操作をしていたスマートフォンなどの操作機器に対して、「他にも紐付け完了していない機器はありますか？」などの問いかけを行う。問いかけの結果、操作機器に同意を示す入力が為された場合、エアコンは、（１）に示すように、周辺デバイスに対してＬＰＷＡで呼びかけを行う。

呼びかけの方法は、例えば自らが基地局として動作するソフトウェアアクセスポイントとして動作し、呼びかけを一斉配信するなどの方法である。呼びかけの内容は「ユーザ紐付け完了していない機器はありますか？」などである。この呼びかけに対して、（２）に示すように、ユーザ紐付け完了していない機器は応答し、応答を受信したエアコンは、同一宅内にあると思われる機器を判定する。この際判定の方法としては、応答の際の受信信号強度（ＲＳＳＩ）や通信遅延時間などの情報を用いて判定することを想定している。

同一宅内にあると判定された機器があった場合、エアコンは、（３）に示すように、操作機器に対して、「この機器をお持ちですか？」などの問いかけを行う。提示された機器を所有していた場合、ユーザはその機器を選択することで、（４）に示すように紐付け処理を開始することができる。この際の紐付け処理は既に紐付けたい機器の機器コードがわかっている状態なので、前述の図２９および図３０で示した処理のうち、機器コードを送信した後の処理に合流する形になる。他には既にユーザとエアコンとが紐付け済みであること、エアコンと同一宅内にあることの二つの条件をクリアしているので紐付け登録を略式にすることなども考えられる。例えば操作機器で提示された機器を選択すると家電機器側で操作端末との紐付け待ち状態に入り、機器でボタンを押すと紐付けが完了するなどである。この際ボタンは、複数ボタンの同時押しであってもよい。操作機器が紐付けを完了するために押すボタンを指定するなどの方法も有用である。

図３７の例ではエアコンの紐付けを完了したタイミングで続けて紐付けを促しているが、他のタイミングで操作機器に「この機器をお持ちですか？」といったプッシュ通知をして紐付けを促す形態も考えられる。例えば紐付けされていない機器が起動したタイミングでユーザと紐付いている機器が周辺にいるかＬＰＷＡで問いかけを行い、紐付け済みの機器が同一宅内であると判定された場合に紐付け済みの家電機器経由で操作機器に紐付けを促してもよい。

図３８は、ＬＰＷＡによる常時接続を生かしたＷｉ−Ｆｉ接続サポート機能について説明するための図である。

ＬＰＷＡによる常時接続を生かし、Ｗｉ−Ｆｉ ＧＷとＩｏＴ家電機器との間の接続をサポートする３つの手法を示す。

手法１は、宅内接続設定共有である。手法２は、リモートＷｉ−Ｆｉ接続設定である。手法３は、Ｗｉ−Ｆｉ ＧＷの ＢＳＳＩＤ情報を活用したユーザアカウントとの紐付け設定である。

いずれの手法もＩｏＴ家電機器がＬＰＷＡとＷｉ−Ｆｉのモジュールを両方保持していることと、ＬＰＷＡを利用してＩｏＴ家電制御クラウドに接続していることを前提としていることと、ユーザはスマートフォン等の操作機器を利用してＩｏＴ家電制御クラウドにログインできるユーザアカウントを持っていることとを前提としている。

図３８においては、機器としての冷蔵庫、洗濯機、エアコンはそれぞれＬＰＷＡを利用してＩｏＴ家電制御クラウドに繋がっている状態であり、操作機器としてのスマーフォンはＷｉ−Ｆｉ ＧＷを通じて、サーバ２０としてのＩｏＴ家電制御クラウドにログインしている状態を示す。

以下、順に、手法１〜３について説明する。

図３９は、ＬＰＷＡによる常時接続を生かしたＷｉ−Ｆｉ接続サポート機能の手法１について説明するための図である。

手法１は、１台目のＩｏＴ家電にＷｉ−Ｆｉの接続設定をすれば、その接続設定情報を、ＬＰＷＡを利用して宅内に存在するＷｉ−Ｆｉに未接続のＩｏＴ家電に通知することで、接続設定情報を横連携して共有する手法である。図３９は、洗濯機を１台目のＩｏＴ家電としてＷｉ−Ｆｉの接続設定を行う例である。

（１）１台目の接続設定を行う際に、洗濯機において、ＳＳＩＤを選択しＰａｓｓｗｏｒｄを入力する方法でＷｉ−Ｆｉ ＧＷとの接続を完了させ、入力されたＳＳＩＤとＰａｓｓｗｏｒｄ情報とを記憶する。これにより、洗濯機は、Ｗｉ−Ｆｉ ＧＷに接続された状態となる。

（２）次にＷｉ−Ｆｉ ＧＷに接続完了した洗濯機は、ＩｏＴ家電制御クラウドに対してＷｉ−Ｆｉ接続が完了した通知を送信する。

（３）通知を受けたＩｏＴ家電制御クラウドは、洗濯機と紐付くユーザアカウントを所有するユーザに洗濯機がＷｉ−Ｆｉ接続完了したことを通知するとともに、当該ユーザの所有する「別のＷｉ−Ｆｉ未接続ＩｏＴ家電機器もＷｉ−Ｆｉ接続しませんか？」とスマートフォンに表示させることで、他の機器のＷｉ−Ｆｉへの接続をユーザに促す。

（４）ユーザが同意した場合、洗濯機が記録しているＷｉ−Ｆｉの接続情報をＩｏＴ家電制御クラウドに送信する。

（５）ＩｏＴ家電制御クラウドは、ＬＰＷＡ経由でＷｉ−Ｆｉに未接続ＩｏＴ家電に、受信されたＷｉ−Ｆｉの接続情報を送信する。

（６）Ｗｉ−Ｆｉの接続情報を受信した、Ｗｉ−Ｆｉに未接続の各ＩｏＴ家電は、受信したＷｉ−Ｆｉの接続情報を用いてＷｉ−Ｆｉ ＧＷに対してＷｉ−Ｆｉ接続処理を行う。

図４０は、ＬＰＷＡによる常時接続を生かしたＷｉ−Ｆｉ接続サポート機能の手法２について説明するための図である。

手法２は、ユーザアカウントと紐付けされたユーザ所有のＩｏＴ家電に対してＬＰＷＡを利用してＷｉ−Ｆｉの設定コマンドを送信することで接続処理を実行させる手法である。

（１）ユーザは、スマートフォンにアプリを実行させ、実行させたアプリ上でＩｏＴ家電制御クラウドにログインする。

（２）次に、ユーザは、スマートフォンのアプリ上で、ＩｏＴ家電制御クラウドにＷｉ−Ｆｉ ＧＷの接続情報を登録するために、Ｗｉ−Ｆｉ ＧＷのＳＳＩＤおよびＰａｓｓｗｏｒｄ情報を入力する。

（３）ＩｏＴ家電制御クラウドは、ユーザアカウントと紐付け済みのＩｏＴ家電に対して（２）で登録した接続情報をＬＰＷＡ経由で送信する。

（４）接続情報を受信したＩｏＴ家電は、受信された接続情報を用いてＷｉ−Ｆｉ ＧＷに対して接続処理を行う。

図４１は、ＬＰＷＡによる常時接続を生かしたＷｉ−Ｆｉ接続サポート機能の手法３について説明するための図である。

手法３は、ＩｏＴ家電とユーザアカウントとが紐付き済みだった手法１および手法２とは異なり、ＩｏＴ家電およびユーザアカウントの紐付けと、Ｗｉ−Ｆｉの接続処理を同時に実現する手法である。

ユーザは、スマートフォンにアプリを実行させ、実行させたアプリ上でＩｏＴ家電制御クラウドにログインし、Ｗｉ−Ｆｉ接続に必要な情報を登録する（Ｓ６１）。ここで、ユーザにより入力される情報は、スマートフォンが接続しているＷｉ−Ｆｉ ＧＷのＳＳＩＤおよびパスワードである。また、ＩｏＴ家電制御クラウドに登録する際、スマートフォンは、アプリ内部でＳＳＩＤ情報からＢＳＳＩＤを取得し、ＳＳＩＤおよびＢＳＳＩＤの両方を登録する。この結果、ＩｏＴ家電制御クラウド上には、ユーザアカウントと、ＳＳＩＤ、ＢＳＳＩＤおよびパスワードを含むＷｉ−Ｆｉ接続情報とが登録される。

ＩｏＴ家電は、電源オンの後、Ｗｉ−Ｆｉサーチを行い、周辺のＷｉ−Ｆｉ情報を収集し、ＢＳＳＩＤリストを作成する。ＩｏＴ家電は、作成したＢＳＳＩＤリストを、ＬＰＷＡを利用してＩｏＴ家電制御クラウドに送信する（Ｓ６２）。

ＩｏＴ家電制御クラウドは、受信されたＢＳＳＩＤと登録済みＢＳＳＩＤとを用いてマッチング検索し（Ｓ６３）、一致した場合（Ｓ６４でＹｅｓ）、ＳＳＩＤリストを通知ＩｏＴ家電に送信する（Ｓ６５）。

ＩｏＴ家電は、受信されたＳＳＩＤリストの中からスマートフォンが接続しているＷｉ−ＦｉのＳＳＩＤ選択する（Ｓ６６）。

ＩｏＴ家電制御クラウドは、ＳＳＩＤを登録したスマートフォンに対して接続許可を問い合わせる（Ｓ６７）。

スマートフォンは、アプリ上で許可／不許可の選択をユーザから受け付ける（Ｓ６８）。

許可の場合（Ｓ６８でＹｅｓ）、ＩｏＴ家電制御クラウドは、ＩｏＴ家電にＷｉ−Ｆｉ ＧＷのパスワードとＳＳＩＤとを登録したユーザアカウントを含むユーザ情報を送信する（Ｓ６９）。

ＩｏＴ家電は、ＷｉＦｉ接続処理を行い接続に成功した場合（Ｓ７０でＹｅｓ）、ＳＳＩＤを登録したスマートフォンと同一Ｗｉ−Ｆｉ ＧＷに接続される。このため、ＩｏＴ家電は、ＩｏＴ家電制御クラウドから受信したユーザアカウントを用いて、スマートフォンアプリとＩｏＴ家電との間で紐付け処理を行うことでユーザアカウントとＩｏＴ家電が紐付けられる（Ｓ７１）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本開示は、ＬＰＷＡによるクラウドとの常時接続を実現した、第四世代の生活家電（常時接続ＩｏＴ家電）に関する。常時接続ＩｏＴ家電ではユーザが特に意識することなくクラウドとの接続を完了し、クラウドを活用したサービスを利用することが可能である。本発明においては、常時接続ＩｏＴ家電がクラウドにアップロードするログ情報や位置情報から、家電機器の状態予測を実現している。

この機能により家電機器が今どのような状態にあるのか、どのような使い方をされているのかを的確に判定し、ユーザに対してそのタイミングで求められている機能、情報の提供を可能としている。具体的にはユーザが家電機器を購入し、ご自宅に設置したタイミングではユーザアカウントの登録を促す機能であったり、ユーザ家電を他者に譲渡したタイミングで、ユーザアカウントの解除し忘れがあった場合には解除を促す機能であったり、万が一お使いの家電にリコールが発生した際には迅速にリコール情報の通知を送り、リモートメンテナンスを実現することなどである。他にも引っ越しや出産などによるくらしの変化を的確に判定し、ユーザに対して新生活に向けた広告を表示するなど、従来型のマイコン生活家電では実現できなかったユーザの生活に寄り添った機能拡張、提供を実現する。

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

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

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

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

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

Claims (10)

1. ネットワークに通信接続されているサーバと、
   前記ネットワークに通信接続されている、遠距離無線通信の複数の基地局と、
   前記複数の基地局のうちの一の基地局に通信接続する少なくとも１つの機器であって、それぞれが当該機器の現在の稼働状態を示す稼働情報を、前記一の基地局を介して前記サーバに逐次送信する少なくとも１つの機器と、を備え、
   前記複数の基地局のそれぞれは、前記稼働情報を逐次受信すると、逐次受信された前記稼働情報と共に当該基地局に固有の情報である固有情報を前記サーバに逐次送信し、
   前記サーバは、
   前記稼働情報および前記固有情報を逐次受信し、対応するタイミングで逐次受信された前記稼働情報および前記固有情報を対応付けて逐次記憶し、
   第１のタイミングで受信された第１固有情報と、前記第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なる場合、前記第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、前記第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて管理する
   機器管理システム。
2. 前記サーバは、前記複数の第１稼働情報を第１識別子と対応付けて記憶し、かつ、前記複数の第２稼働情報を前記第１識別子とは異なる第２識別子と対応付けて記憶することで、前記複数の第１稼働情報と、前記複数の第２稼働情報とを分けて管理する
   請求項１に記載の機器管理システム。
3. 前記第２識別子は、前記第２期間において前記少なくとも１つの機器を利用しているユーザに対応付けられていることを示す識別子であり、
   前記サーバは、前記第２のタイミングの後の第３のタイミングで受信された第３固有情報が前記第２固有情報と異なる場合、前記少なくとも１つの機器が移動したと判断し、前記少なくとも１つの機器のユーザが他のユーザに変更されたか否かの問い合わせを、前記少なくとも１つの機器または前記ユーザが所有する端末に送信する
   請求項２に記載の機器管理システム。
4. 前記サーバは、前記問い合わせを送信した後に、前記少なくとも１つの機器または前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器のユーザが前記他のユーザに変更されたことを示す場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を、前記複数の第１稼働情報および前記複数の第２稼働情報とは分けて管理する
   請求項３に記載の機器管理システム。
5. 前記サーバは、前記問い合わせを送信した後に、前記少なくとも１つの機器または前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器のユーザが前記他のユーザに変更されていないことを示す場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を前記複数の第２稼働情報と共に管理する
   請求項３または４に記載の機器管理システム。
6. 前記少なくとも１つの機器は、複数の機器であり
   前記サーバは、
   前記第２のタイミングで前記複数の機器から受信された複数の前記第２固有情報が互いに同じであり、かつ、前記第２のタイミングの後の第３のタイミングで前記複数の機器から受信された複数の第３固有情報が互いに同じであり、かつ、前記第２固有情報と、前記第３固有情報とが異なる場合、前記第３のタイミング以降の第３期間において受信された複数の第３稼働情報を前記複数の第２稼働情報と共に管理する
   請求項１または２に記載の機器管理システム。
7. 前記サーバは、前記第２のタイミングの後の第４のタイミングから所定期間後となっても稼働情報を受信しない場合、前記第４のタイミングまでに受信された複数の前記稼働情報の管理状態を非管理状態に変更する
   請求項１から６のいずれか１項に記載の機器管理システム。
8. 前記サーバは、前記第２のタイミングの後の第４のタイミングから所定期間後となっても稼働情報を受信せず、かつ、前記第４のタイミングで受信された第４固有情報が予め保持している固有情報リストに含まれる複数の固有情報のいずれか１つと同じである場合、前記第４のタイミングまでに受信された複数の前記稼働情報の管理状態を非管理状態に変更する
   請求項１から６のいずれか１項に記載の機器管理システム。
9. 前記第２識別子は、前記第２期間において前記少なくとも１つの機器を利用しているユーザに対応付けられていることを示す識別子であり、
   前記サーバは、
   前記第２のタイミングの後の第３のタイミングで受信された第３固有情報が前記第２固有情報と異なる場合、前記少なくとも１つの機器が移動したと判断し、前記少なくとも１つの機器が盗難されたか否かの問い合わせを、前記ユーザが所有する端末に送信し、
   前記問い合わせを送信した後に、前記端末から受信した前記問い合わせに対する回答が、前記少なくとも１つの機器が盗難されたことを示す場合、機器を使用できないようにロックする制御信号を前記少なくとも１つの機器に送信し、
   前記少なくとも１つの機器は、前記制御信号を受信すると、当該機器を使用できないようにロックする
   請求項２に記載の機器管理システム。
10. 遠距離無線通信の基地局を介して、前記基地局に通信接続されている機器の稼働状態を示す稼働情報と、前記機器が通信接続されている前記基地局に固有の情報である固有情報とを、逐次受信し、
    対応するタイミングで逐次受信された前記稼働情報および前記固有情報を対応付けて逐次記憶し、
    前記記憶では、第１のタイミングで受信された第１固有情報と、前記第１のタイミングの次の第２のタイミングで受信された第２固有情報とが異なる場合、前記第１のタイミングまでの第１期間において受信された複数の第１稼働情報と、前記第２のタイミング以降の第２期間において受信された複数の第２稼働情報とを分けて記憶する
    機器管理方法。

Images