特開 2024-162355 家電機器管理システムおよびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024162355

(43)【公開日】2024-11-21

(54)【発明の名称】家電機器管理システムおよびプログラム

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20241114BHJP

   A47L 9/28 20060101ALI20241114BHJP

【ＦＩ】

G06Q10/20

A47L9/28 E

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023077764

(22)【出願日】2023-05-10

(71)【出願人】

【識別番号】399048917

【氏名又は名称】日立グローバルライフソリューションズ株式会社

(74)【代理人】

【識別番号】110000350

【氏名又は名称】ポレール弁理士法人

(72)【発明者】

【氏名】大平 昭義

(72)【発明者】

【氏名】徳永 益規

(72)【発明者】

【氏名】牛尾 奈緒子

(72)【発明者】

【氏名】吉田 征義

(72)【発明者】

【氏名】加藤 功記

(72)【発明者】

【氏名】佐々木 康祐

【テーマコード（参考）】

3B057

5L010

5L049

【Ｆターム（参考）】

3B057DA00

5L010AA00

5L049AA00

(57)【要約】

【課題】
家電機器の診断においてユーザの対応結果も考慮した診断を実施する。
【解決手段】
上記の課題を解決するための本発明の構成は、複数の家電機器３ｎと接続する利用者端末１０および診断支援装置２０を有する家電機器管理システムにおいて、複数の家電機器３ｎそれぞれにおけるログデータを収集するログデータ収集部１２と、収集されたログデータのうち、所定期間ログデータを用いて、家電機器３ｎの稼働について診断を実行する診断部１３と、診断の結果を示すレポートを出力する出力部１５を有し、出力部１５は、第１の所定期間のログデータに対する第１のレポートと、第１の所定期間が含まれない第２の所定期間のログデータに対する第２のレポートを出力する家電管理システムである。
【選択図】 図１２Ａ

【特許請求の範囲】

【請求項1】

複数の家電機器と接続する利用者端末および診断支援装置を有する家電機器管理システムにおいて、
前記複数の家電機器それぞれにおけるログデータを収集するログデータ収集部と、
収集されたログデータのうち、所定期間のログデータを用いて、前記家電機器の稼働について診断を実行する診断部と、
前記診断の結果を示すレポートを出力する出力部を有し、
前記出力部は、
第１の所定期間のログデータに対する第１のレポートと、
前記第１の所定期間が含まれない第２の所定期間のログデータに対する第２のレポートを出力する家電管理システム。

【請求項2】

複数の家電機器および診断支援装置と接続し、コンピュータである利用者端末を、
前記複数の家電機器それぞれにおけるログデータを収集するログデータ収集部と、
収集されたログデータを、前記診断支援装置に送信し、当該診断支援装置から所定期間のログデータを用いて実行される、前記家電機器の稼働について診断の結果を示すレポートを受信する通信部と、
前記レポートを出力する出力部として機能させ、
前記出力部は、第１の所定期間のログデータに対する第１のレポートおよび前記第１の所定期間が含まれない第２の所定期間のログデータに対する第２のレポートを出力するプログラム。

【請求項3】

請求項２に記載のプログラムにおいて、
前記第１の所定期間は、前記第２の所定期間より長い期間であるプログラム。

【請求項4】

請求項２に記載のプログラムにおいて、
前記第2の所定期間は、前記第１の所定期間以降の期間であるプログラム。

【請求項5】

請求項２に記載のプログラムにおいて、
前記通信部は、第1のレポートに対する対処結果を送信可能であるプログラム。

【請求項6】

請求項５に記載のプログラムにおいて、
前記通信部は、前記対処結果が送信されず一定時間経過した場合、前記第1のレポートに関する確認通知を受信し、
前記出力部は、前記確認通知を出力するプログラム。

【請求項7】

請求項６に記載のプログラムにおいて、
前記確認通知は、前記第1のレポートに対する対処を促す内容を示すプログラム。

【請求項8】

請求項５に記載のプログラムにおいて、
前記通信部は、前記対処結果を一定時間内に送信した場合に、前記第２のレポートを受信するプログラム。

【請求項9】

請求項５に記載のプログラムにおいて、
前記通信部は、前記対処結果として、前記第1のレポートが示す不具合が終息したかを示す対処結果を送信するプログラム。

【請求項10】

請求項２に記載のプログラムにおいて、
前記第１の所定期間および前記第２の所定期間の一部が重複するプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、家電機器を管理するための技術に関する。その中でも特に、家電機器に対する診断を支援するための技術に関する。

【背景技術】

【0002】

現在、家庭内などで各種家電機器が利用されている。このような家電機器は、使用や経年に伴い、劣化、故障、異常等の不具合が生じることがある。これら不具合の防止や対応を行うためには、家電機器に対する診断、点検（以下、単に診断を記載）などの管理を行うことが有効である。このような診断においては、利用者に対して、診断結果等を情報提供することで、不具合に対する対策が可能となる。

【0003】

このような家電機器に対する診断結果の出力については、特許文献１と特許文献２が提案されている。特許文献１には、「機器単体の異常状態検知に留まらず、使用者の生活において最も効果的な他機器への置き換えの提案や効果的な使用方法を提示」することが開示されている。また、特許文献２には、「一般家庭用の電気機器を利用する顧客に対して、簡便に、しかも日常生活の中で役立つ情報として、メンテナンス時期や予測寿命を知らせる」ことが開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】国際公開2018/003110号

【特許文献2】特開2007-157018号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ここで、利用者が家電機器に対して通常時とは異なる不具合を感じた際に、利用者端末を通じて気になる家電機器の不具合についての症状を入力すると、利用者端末に各種情報を提供することができる。例えば、不具合についての分析結果や不具合を改善するための対処方法を利用者端末に表示できる。この結果、その対処方法に従って利用者が対応することができた。しかしながら、時間の経過と共に不具合の症状が変化するともあり、家電機器の実態に即した情報提供が困難であった。特に、利用者が対応したとしても、実際に気になる家電機器の現象が改善しているかどうか分からず、ユーザが不安になることもあり得る。

【0006】

特許文献１や２では、不具合の発生、保守（メンテナンス）時期や予兆寿命を利用者に提供することが開示されているが、その後利用者が対応したかについてまで考慮されていない。このため、特許文献１や２では、診断した家電機器の不具合がどのようになったかを把握することは困難であった。そこで、本発明は、家電機器の状態がどのように変化したのかを実態に即して利用者に通知することを課題とする利用者の不安感を解消することを課題とする。

【課題を解決するための手段】

【0007】

上記の課題を解決するために、本発明では、複数の家電機器と接続する利用者端末および診断支援装置を有する家電機器管理システムにおいて、複数の家電機器それぞれにおけるログデータを収集するログデータ収集部と、収集されたログデータのうち、所定期間のログデータを用いて、前記家電機器の稼働について診断を実行する診断部と、診断の結果を示すレポートを出力する出力部を有し、出力部は、第１の所定期間または所定運転回数のログデータに対する第１のレポートと、第１の所定期間が含まれない第２の所定期間のログデータに対する第２のレポートを出力する家電管理システムである。また、本発明には、家電管理システムを構成する利用者端末をコンピュータとして機能させるためのプログラムも含まれる。

【発明の効果】

【0008】

本発明によれば、家電機器等の機器の診断結果の確認をより効率的に実現することが可能となる。

【図面の簡単な説明】

【0009】

【図1】実施例１および実施例２における家電機器管理システムのシステム構成図である。

【図2】実施例１および実施例２における家電機器３ｎの機能ブロック図である。

【図3】実施例１および実施例２における利用者端末１０のハードウエア構成図である。

【図4】実施例１および実施例２における診断支援装置２０のハードウエア構成図である。

【図5】実施例１および実施例２で用いられる利用者管理情報２５１を示す図である。

【図6】実施例１および実施例２で用いられる診断定義情報２５２を示す図である。

【図7】実施例１および実施例２で用いられるログデータ２５３を示す図である。

【図8】実施例１および実施例２で用いられる診断情報２５４を示す図である。

【図9】実施例１における診断処理の処理フローを示すフローチャートである。

【図10】実施例１および実施例２における表示処理の処理フローを示すフローチャートである。

【図11A】実施例１および実施例２における第１の表示例を示す図である。

【図11B】実施例１および実施例２における第２の表示例を示す図である。

【図11C】実施例１および実施例２における第３の表示例を示す図である。

【図12A】実施例１における標準診断と追加診断の考え方の第１の例を示す図である。

【図12B】実施例１における標準診断と追加診断の考え方の第２の例を示す図である。

【図12C】実施例１における標準診断と追加診断の考え方の第３の例を示す図である。

【図12D】実施例１における標準診断と追加診断の考え方の第４の例を示す図である。

【図13】実施例２における診断処理の処理フローを示すフローチャートである。

【発明を実施するための形態】

【0010】

以下、本発明の一実施形態について説明する。本実施形態は、実態に即した家電機器の診断結果を通知することを課題とする。この課題には、家電機器の不具合に対する利用者の対処に対して、家電機器の状態の変化やさらなる対処を把握することが含まれる。さらに、本実施形態の課題には、対処していなかった場合における、家電機器の状態の変化や不具合への対処を促す再通知可能とすることが含まれる。このため、本実施形態は、家庭内の１つ以上の家電機器に対して、第１の所定期間における一次診断を行い、第１の所定期間とは第1の所定期間が含まれない第2の所定期間におけるに二次診断を行う。そして、それぞれその結果を示す第１のレポートおよび第2のレポートを出力する。ここで、第2の所定期間とは、第1の所定期間とは別の期間とも表現できる。また、より望ましくは、これら診断は利用者からの指示に応じて実行される。但し、定期的など所定規則に従って、実行してもよい。このため、診断結果を示す診断情報には、定期レポートも含まれる。なお、本実施形態の診断には、点検が含まれる。また、診断以外にも、点検に伴う保守（メンテナンス）、清掃、修理、交換等の対策、対処を実行してもよい。

【0011】

なお、第2の所定期間とは、第1の所定期間以前、以降のいずれであってよい。ここで、第2の所定期間とは、第1の所定期間以前の期間を用いる場合、第1の所定期間以降の第2の所定期間における二次診断を補完するために、第1の所定期間以前のデータを用いることが望ましい。さらに、第1の所定期間と第2の所定期間の一部が重複することを妨げない。

【0012】

本実施形態によれば、利用者のメンテナンス不足などに起因する家電機器の故障等の不具合を未然に防ぐことができる。以下、本実施形態のより具体的な態様を示す各実施例について説明する。

【実施例0013】

実施例１は、家電機器の不具合に対する利用者の対処に対して、家電機器の状態の変化やさらなる対処を把握することを課題とする。特に、一次診断（第1のレポート）に応じた、利用者の対処に応じた家電機器の状態を把握することを課題とする。このために、実施例１では、一次診断の第1のレポートに対する対処後に二次診断を実行し、第2のレポートを提示する。以下、その詳細を説明する。

【0014】

＜構成＞
まず、実施例１の構成について説明する。なお、本欄で説明する各構成（図１～図４）については、実施例２とも共通である。図１は、実施例１における家電機器管理システムのシステム構成図である。図１において、家電機器管理システムは、利用者端末１０および診断支援装置２０を有し、これらが診断対象である家電機器群３０とルータ４０やネットワーク５０を介して接続されている。また、利用者端末１０と家電機器群３０は、近距離無線通信などを利用して直接接続してもよい。さらに、利用者端末１０、家電機器群３０とルータ４０、ネットワーク５０間は、有線接続でも無線接続でも構わない。以下、これらの各装置について説明する。

【0015】

まず、実施例１の管理対象である１つ以上の家電機器３ｎについて説明する。家電機器３ｎは、１つの領域（例えば、家庭内）で使用されていることを想定している。また、実施例１の家電機器３ｎには、電子レンジ３１、冷蔵庫３２、掃除機３３、ＩＨ調理機器３４、空気清浄機３５および洗濯機３６が含まれる。但し、これらは例示であり、これらの一部は省略可能であり、また、その家電機器を追加してもよい。これら各家電機器は、調理機能、冷凍機能、掃除機能といった各種機能の他、近距離無線通信等、通信機能を有する。このように、図１では家電機器群３０として記載したが、いずれか１つの家電機器３ｎないしここに例示した以外の家電機器３ｎを管理対象としてもよい。

【0016】

ここで、家電機器３ｎの構成について説明する。図２は、実施例１における家電機器３ｎの機能ブロック図である。このブロック図は、各家電機器３ｎを代表するものである。図２に示すように、家電機器３ｎは、制御部３０１、通信部３０４、表示操作パネル３０５、稼働部３０６およびセンサ３０７を有する。そして、これらは通信路を介して互いに接続されている。以下、各構成について説明する。

【0017】

まず、制御部３０１は、制御信号作成部３０２およびログデータ取得部３０３を有する。つまり、制御部３０１は、洗濯等の当該家電機器の機能を実現するための制御信号を作成、出力し、家電機器３ｎの稼働を制御し、また、当該家電機器の稼働に関するログデータを取得する。ここで、ログデータ取得部３０３は、稼働部３０６やセンサ３０７もしくは制御信号作成部３０２からログデータを取得する。なお、ログデータとは、家電機器３ｎの稼働データ（稼働時間、稼働内容）、環境（温度等）、利用開始時期、エラー等のイベントなどのいずれかを含む情報である。なお、制御部３０１は、ＭＰＵ（Micro-Processing Unit）で実現可能であり、制御信号作成部３０２やログデータ取得部３０３の各部は専用ハードウエアやプログラムといったソフトウエアで実現できる。

【0018】

通信部３０４は、ルータ４０やネットワーク５０を介した通信や近距離無線通信機能を有する。そして、通信部３０４は、取得されたログデータを出力したり、利用者端末１０などから制御指示やログデータの収集指示を受け付けたりする。表示操作パネル３０５は、利用者から家電機器に対する操作を受け付けたり、家電機器の稼働状況を出力したりする。稼働部３０６は、制御部３０１からの制御に従って、各種機能を実行する。このために、例えば、制御信号作成部３０２で作成された制御信号が用いられる。実行される機能としては、調理機能、冷凍機能、掃除機能等であり、ヒータ、圧縮機や電動送風機やモータ、アクチュエータなどで実現できる。さらに、センサ３０７は、家電機器３ｎの利用状況および／または稼働状況を取得する。例えば、センサ３０７は、温度計、照度計やカメラなどで実現できる。冷蔵庫３２内の温度や扉の開閉回数といった利用ないし稼働状況を取得する。

【0019】

なお、実施例１および後述の実施例２では、診断やその診断結果を示す情報の作成、出力を、家電機器管理システムで実行するが、少なくともこれらの一部を、家電機器３ｎで実行してもよい。この場合、制御部３０１が、診断および／または診断情報の作成を実行する。さらに、家電機器管理システムで作成された診断情報を、表示操作パネル３０５が出力してもよい。

【0020】

以上で図２の説明を終わり、図１の説明に戻る。利用者端末１０は、各家電機器３ｎ、つまり、家電機器群３０の管理に利用されるもので、スマートフォン、携帯電話、タブレット、ＰＣなどのコンピュータで実現できる。このために、利用者端末１０は、通信部１１、ログデータ収集部１２、診断部１３、診断情報配置部１４、出力部１５、入力部１６および記憶部１７を有する。通信部１１は、ルータ４０やネットワーク５０を介した通信や近距離無線通信機能を有する。また、ログデータ収集部１２は、家電機器群３０から通知されるログデータを収集する。ログデータ収集部１２は、周期的に、特に一定期間ごと（例えば、定期的）にログデータを収集することが望ましい。なお、ログデータ収集部１２を省略し、家電機器群３０が能動的にログデータを通知してもよい。

【0021】

診断部１３は、収集されたログデータに基づいて、家電機器群３０の稼働についての診断を実行し、その診断結果を示す診断情報を作成する。実施例１や実施例２においては、複数の診断項目を有する診断を実行し、診断項目ごとの診断情報が作成される。但し、本発明や実施形態では、診断項目が単数であることを妨げない。また、診断情報配置部１４は、診断部１３で作成された診断情報の配置を決定する。

【0022】

なお、診断部１３や診断情報配置部１４の機能については、少なくとも一方を診断支援装置２０に設け、少なくとも一方を省略できる。また、出力部１５は、診断情報等の各種情報を出力する。入力部１６は、利用者から診断を開始するための診断指示などの各種操作を受け付ける。なお、出力部１５および入力部１６は一体で構成できる。さらに、記憶部１７は、診断部１３や診断情報配置部１４の処理で用いられる各種情報などが記憶される。

【0023】

ここで、利用者端末１０の一実現例について説明する。図３は、実施例１における利用者端末１０のハードウエア構成図である。図３において、利用者端末１０は、タッチパネル１０１、処理装置１０２、通信装置１０３、記憶装置１０４を有し、これらは通信路を介して互いに接続されている。

【0024】

まず、タッチパネル１０１は、図１の出力部１５および入力部１６を兼ねた構成であり、利用者の指示、操作を受け付けたり、各種情報を表示したりする。なお、タッチパネル１０１は、入力デバイスと出力デバイスに分けて構成してもよい。また、処理装置１０２は、ＣＰＵ（Central Processing Unit）などのプロセッサで実現でき、後述する記憶装置１０４に記憶されている家電機器管理プログラム１０５（統合アプリ）に従って演算を実行する。そして、家電機器管理プログラム１０５は、その機能ごとに、ログデータ収集モジュール１０６、診断モジュール１０７および診断情報配置モジュール１０８で構成される。なお、これら各モジュールは、個別のプログラムや一部の組合せで実現してもよい。

【0025】

ここで、各モジュールと同一の機能を実行する図１に示す構成は以下のとおりで、ログデータ収集モジュール１０６：ログデータ収集部１２、診断モジュール１０７：診断部１３、診断情報配置モジュール１０８：診断情報配置部１４となる。このため、処理装置１０２は、家電機器管理プログラム１０５に従って、ログデータ収集部１２、診断部１３および診断情報配置部１４の処理を実行することになる。また、記憶装置１０４は、家電機器管理プログラム１０５、診断定義情報１０９、ログデータ１１０、診断情報１１１および保有機器情報１１２を記憶する。

【0026】

ここで、家電機器管理プログラム１０５は、家電機器群３０を管理するためのプログラムであってもよいし、家電機器ごとの複数のプログラムで構成してもよい。後者については、電子レンジ３１、冷蔵庫３２、掃除機３３、ＩＨ調理機器３４、空気清浄機３５や洗濯機３６各々の管理プログラムを用いることになる。なお、診断定義情報１０９、ログデータ１１０および診断情報１１１については、＜情報＞で後述する。

【0027】

また、記憶装置１０４は、メモリのような主記憶装置と、いわゆるストレージである副記憶装置（記憶媒体）で実現してもよい。なお、副記憶装置は、外付けのＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、メモリカードなどで実現してもよい。さらに、家電機器管理プログラム１０５、診断定義情報１０９、ログデータ１１０および診断情報１１１の少なくとも一部は省略できる。
これは、後述の診断支援装置２０で保持されていればよい。またさらに、家電機器管理プログラム１０５の少なくとも一部のモジュール（機能）を、診断支援装置２０に設けてもよい。

【0028】

以上で図３の説明を終わり、図１の説明に戻る。診断支援装置２０は、家電機器群３０の診断を実現するためにされ、サーバ、クラウドといったコンピュータで実現できる。このために、診断支援装置２０は、通信部２１、ログデータ収集部２２、診断部２３、診断情報配置部２４および記憶部２５を有する。

【0029】

まず、通信部２１は、ルータ４０やネットワーク５０を介した通信や近距離無線通信機能を有する。また、ログデータ収集部２２は、ログデータ収集部１２と同様の機能を実現し、ログデータ収集部２２とログデータ収集部１２は、少なくとも一方が存在すればよい。また、診断部２３も同様に診断部１３と同様の機能を実現し、少なくとも一方が存在すればよい。さらに、診断情報配置部２４も同様に診断情報配置部１４と同様の機能を実現し、少なくとも一方が存在すればよい。

【0030】

さらに、記憶部２５は、利用者管理情報２５１、診断定義情報２５２、ログデータ２５３および診断情報２５４を記憶する。なお、診断定義情報２５２、ログデータ２５３および診断情報２５４は、利用者端末１０に記憶された診断定義情報１０９、ログデータ１１０および診断情報１１１と内容的に同じものであり、一方を省略してもよい。また、利用者端末１０のリソースを考慮し、圧縮ないし簡略化された情報としてもよい。なお、これら各情報については、＜情報＞で後述する。

【0031】

ここで、診断支援装置２０の一実現例について説明する。図４は、実施例１における診断支援装置２０のハードウエア構成図である。図４において、診断支援装置２０は、処理装置２０１、通信装置２０２、メモリ２０３および副記憶装置２０４を有し、これらは通信路を介して互いに接続されている。

【0032】

まず、処理装置２０１は、ＣＰＵなどのプロセッサで実現でき、後述する副記憶装置２０４に記憶されている家電機器管理プログラム２０５に従って演算を実行する。家電機器管理プログラム２０５については、後述する。また、通信装置２０２は、図１の通信部２１に該当し、ネットワーク５０と接続し、他の装置との通信を行う。メモリ２０３および副記憶装置２０４が、図１の記憶部２５に該当する。そして、メモリ２０３は、副記憶装置２０４に記憶されている家電機器管理プログラム２０５や処理装置２０１での処理に用いられる情報が展開される。副記憶装置２０４は、いわゆるストレージで実現でき、家電機器管理プログラム２０５、利用者管理情報２５１、診断定義情報２５２、ログデータ２５３および診断情報２５４を記憶する。また、副記憶装置２０４は、外付けのＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、メモリカードなどの各種記憶媒体で実現してもよいし、ファイルサーバのように診断支援装置２０とは別装置で実現してもよい。

【0033】

ここで、家電機器管理プログラム２０５は、ログデータ収集モジュール２０６、診断モジュール２０７および診断情報配置モジュール２０８で構成される。なお、これら各モジュールは、個別のプログラムや一部の組合せで実現してもよい。ここで、各モジュールと同一の機能を実行する図１に示す構成は以下のとおりで、ログデータ収集モジュール２０６：ログデータ収集部２２、診断モジュール２０７：診断部２３、診断情報配置モジュール２０８：診断情報配置部２４となる。

【0034】

このため、処理装置２０１は、当該プログラムに従って、ログデータ収集部２２、診断部２３および診断情報配置部２４の処理を実行することになる。

【0035】

なお、家電機器管理プログラム２０５と家電機器管理プログラム１０５と同様の演算を実行するもので、少なくとも一方が存在すればよい。この際、これらを構成するモジュールについても少なくとも一方に存在すればよい。

【0036】

以上で図４の説明を終わり、図１の説明に戻る。ルータ４０は、各装置を接続するための機能を有するもので、家電機器群３０と同じ敷地内に設けられることが望ましい。なお、ルータ４０は省略もしくは他の通信機器と説き替え可能である。また、ネットワーク５０は、インターネットや公衆回線網等の通信網である。以上で、実施例１の構成についての説明を終わる。

【0037】

＜情報＞
次に、実施例1で用いられる各種情報について説明する。なお、本欄で説明する各情報（図５～図８）については、実施例２とも共通である。図５は、実施例１で用いられる利用者管理情報２５１を示す図である。家電機器群３０の利用者に関する情報である。図５に示すように、利用者管理情報２５１は、利用者名、住所、連絡先および保有機器の各項目を有する。ここで、利用者名は、該当の利用者を識別する情報であればよい。また、住所、連絡先はプライバシーを考慮し、情報として管理しない場合もあり、さらに、保有機器は、該当の利用者が保有ないし利用する家電機器、つまり、家電機器群３０を特定する情報である。なお、利用者端末１０は、利用者が保有する家電機器（家電機器群３０）を管理する保有機器情報１１２を有するが、これは利用者管理情報２５１の「保有機器」の項目と同様の構成である。

【0038】

次に、図６は、実施例１で用いられる診断定義情報２５２を示す図である。診断定義情報２５２は、診断を実行するために診断を定義するための情報である。図６に示すように、診断定義情報２５２は、家電機器、診断項目、標準診断および追加診断の各項目を有する。家電機器は、診断対象となる家電機器を識別する情報である。診断項目は、診断する内容、種別を示し、実施例３では（１）稼働実績診断、（２）予兆診断、（３）故障診断の複数が存在する。ここで、（１）稼働実績診断とは、ログデータ等に基づき特定される家電機器３ｎの稼働時間、利用した機能、モード等の診断結果を示す。また、（２）予兆診断は、ログデータ等から家電機器３ｎに発生し得る不具合の予測結果を示す。さらに、（３）故障診断等は、ログデータから家電機器３ｎで発生した故障等の不具合の判定結果を示す。なお、これらは例示であり、診断項目はこれらに限定されず、また、これらの少なくとも一部を省略してもよい。さらに、診断項目には、表示画面での表示配列を含めることが望ましい。図６での例では、括弧内の数字が、表示配列を示し、画面上部から下部に向けて、（１）稼働実績診断、（２）予兆診断、（３）故障診断の順で該当の診断情報が表示されることになる。

【0039】

また、標準診断とは、利用者の診断指示や定期的な診断など定常的な診断を示し、追加診断とは、標準診断に対する利用者等の対処に応じた診断を示す。ここで、追加診断は利用者等の診断指示に応じて実行されてもよいし、標準診断の診断結果が、否定的な結果（故障発生など）といった所定条件を満たす場合に実行されてもよい。そして、標準診断と追加診断のそれぞれは、利用データおよびその収集期間を有する。利用データとは、診断に用いるデータを示す。また、収集期間とは、利用データの収集や発生など関連する利用する範囲、期間を示す。

【0040】

ここで、標準診断における利用データは、例えばログデータである洗濯機能実行ログ、エラー発生ログなどが用いられる。また、追加診断における利用データは、対応する標準診断での利用データに関連する関連データが用いられる。例えば、（１）稼働実績診断で洗濯機能実行ログとして、利用回数や頻度が用いられた場合、その平均値が用いられる。また、関連データとしては、標準診断の利用データの平均値やその一部などの代表値、変換値や利用データ（例えば、ログデータ）そのものを用いることができる。また、標準診断の利用データに対して、その粒度を変えて関連データを特定してよい。つまり、これらの時間に関する粒度は互いに異なってもよい。ここで、時間に関する粒度とは、利用するログデータの期間の範囲や抽出周期が含まれる。

【0041】

期間の範囲とは、例えば、標準診断では1か月分のログデータを利用し、追加診断では１週間など標準診断とは別期間のログデータを利用することを意味する。また、抽出周期とは、例えば、標準診断では毎週１回ログデータを抽出し、追加診断では毎日１回ログデータを抽出するといった異なる周期のログデータを利用することを意味する。なお、標準診断に比較して、追加診断の粒度を小さく、つまり、より短期間とすることが望ましい。このようにすることで、対処の効果をタイムリーに確認できる。なお、関連データは、診断部２３や診断部１３が、診断の際に作成してもよいし、事前に作成しておき、診断定義情報２５２の一部として記憶しておいてもよい。

【0042】

また、標準診断と追加診断での利用データの粒度を変更することは、ログデータ収集部２２やログデータ収集部１２でのログデータの収集期間の長さを変えることで実現できる。より望ましくは追加診断の収集期間のほうが短くした方がよい。このことは、第1の所定期間が、第2の所定時間よりも長いとも表現できる。さらに、追加診断の収集期間の起点は、標準診断に対する対処後としてもよいし、標準診断の収集期間後としてもよい。

【0043】

また、追加診断を２回以上行うことを妨げない。この場合、２回目以降の追加診断は、その前の追加診断に対して利用者が対処したかを検証する診断としてもよいし、当初の標準診断の妥当性を検証するための診断としてもよい。

【0044】

また、標準診断と追加診断に追加して、他の診断を行ってもよい。またさらに、標準診断や追加診断との名称は一例であり、それぞれ一次診断、二次診断や通常診断、補足診断等と表現することも可能である。なお、利用者端末１０が記憶する診断定義情報１０９も同様の構成である。

【0045】

次に、図７は、実施例１で用いられるログデータ２５３を示す図である。ログデータ２５３は、家電機器３ｎの稼働に関するデータである。そして、実施例１や実施例２では、ログデータ２５３は、家電機器、日時およびログ（内容）の各項目を有する。ここで、家電機器は、診断対象となる家電機器を識別する情報である。また、日時は、ログ（内容）が発生ないし検知された日時を示す。また、ログ（内容）は、家電機器３ｎの稼働データ（稼働時間、稼働内容）、環境（温度等）、利用開始時期、エラー等のイベントなどのいずれかを含む情報である。なお、利用者端末１０が記憶するログデータ１１０も同様の構成である。

【0046】

次に、図８は、実施例１で用いられる診断情報２５４を示す図である。診断情報２５４は、家電機器３ｎ、診断種別、診断項目、診断結果および対処方法の各項目を有する。家電機器は、診断対象となる家電機器を識別する情報である。診断種別は、診断が標準診断もしくは追加診断の別を示す情報である。また、実施例１や実施例２では、診断種別には、診断を識別する情報（例えば、標準診断1）も含まれる。またさらに、診断種別には、診断が実行ないし出力された日時も含まれる。

【0047】

また、診断結果は、ログデータなどに基づき診断された内容を示す情報である。また、該当の診断項目が診断中である場合、診断中である旨が記録される。さらに、診断結果が、利用者で対応できないなど所定条件を満たす場合、優先的に出力すること（優先表示）が記録される。この優先的な出力については、処理フローで追って説明する。このように、診断結果については、利用者で対応できるものと、対応できないもの、といった所定条件によっても分類できる。また、対処方法は、診断結果に対する対処方法を示す。実施例１や実施例２では、利用者での実行が推奨される内容が示されることになる。さらに、実施例１や実施例２では標準診断の結果、追加調査が不要な場合、その旨が記録される。

【0048】

図８では、標準診断３の結果、追加診断３は不要と判定されている。なお、利用者端末１０が記憶する診断情報１１１も同様の構成である。またさらに、標準診断の結果、追加診断の一部の診断項目の診断を不要としてもよい（追加診断１の稼働実績）。これら不要との判断は、標準診断で、対処が不要であるかにより実行してもよい。例えば、追加診断１の稼働実績は、対応する標準診断１の稼働実績で問題がないため、その診断を省略している。但し、このような場合でも追加診断を実行してもよい。なお、利用者端末１０が記憶する診断情報１１１も同様の構成である。以上で、実施例１で用いられる各種情報の説明を終わる。

【0049】

＜処理フロー＞
次に、実施例１の処理フローについて説明する。なお、以下の説明において、利用者端末１０や診断支援装置２０の処理は、図１および図２に示す構成を用いて説明する。

【0050】

始めに、実施例１では、診断のためのログデータの収集、蓄積を実行する。まず、家電機器３ｎが、制御部３０１の制御に従って稼働する。また、家電機器３ｎのログデータ取得部３０３が、家電機器３ｎの稼働に応じてログデータを取得する。そして、通信部３０４が、制御部３０１の制御に従って取得したログデータを、利用者端末１０に送信する。なお、この送信は、所定周期で実行してもよいし、リアルタイムで実行してもよい。さらに、この送信は、制御部３０１が能動的に実行してもよいし、利用者端末１０のログデータ収集部１２の指示に応じて実行してもよい。つまり、いわゆるＰＵＳＨ送信、ＰＵＬＬ送信のいずれで実行してもよい。さらに、この送信は、家電機器３ｎから診断支援装置２０に対して実行してもよい。

【0051】

また、利用者端末１０の通信部１１は、送信されたログデータを、診断支援装置２０に転送する。なお、この転送において、該当の利用者端末１０ないし利用者を識別する情報や家電機器３ｎを識別する情報を付加してもよい。また、この転送は、所定周期で実行してもよいし、リアルタイムで実行してもよいし、家電機器３ｎからの送信に同期して実行してもよい。さらに、この転送は、ログデータ収集部１２が能動的に実行してもよいし、診断支援装置２０のログデータ収集部２２の指示に応じて実行してもよい。つまり、いわゆるＰＵＳＨ送信、ＰＵＬＬ送信のいずれで実行してもよい。

【0052】

また、診断支援装置２０の通信部２１が、利用者端末１０から転送もしくは家電機器３ｎから送信されたログデータを受信する。そして、ログデータ収集部１２が、受信されたログデータを、ログデータ２５３として記憶部２５に蓄積する。以上で、ログデータの収集や蓄積の説明を終わる。

【0053】

次に、ログデータ２５３を用いた診断処理について説明する。図９は、実施例１における診断処理の処理フローを示すフローチャートである。まず、ステップＳ１１において、利用者端末１０の入力部１６により、利用者から標準診断についての診断指示を受け付ける。これを受けて、ステップＳ１２において、通信部１１により、診断支援装置２０に対して、診断指示を送信する。なお、この診断指示には、診断対象である家電機器３ｎを識別する識別情報が含まれる。ステップＳ２１において、診断支援装置２０の通信部２１が、診断指示を受信する。ステップＳ２２において、診断部２３が、診断指示に応じた標準診断を実行する。この際、診断部２３は、診断指示に含まれる家電機器３ｎの識別情報に該当する診断項目と、利用データおよび収集期間を、診断定義情報２５２から特定する。

【0054】

次に、診断部２３は収集期間分の利用データを、記憶部１７のログデータ２５３から特定する。利用データとして、ログデータ２５３を用いる場合、診断部２３は該当のログデータ２５３を読み出す。そして、診断部２３は、特定された利用データを用いて、特定された各診断項目について標準診断を開始する。

【0055】

また、ステップＳ２３において、診断部２３が、ステップＳ２２で開始された診断項目のうち、診断が終了した診断項目が有るかを判定する。この結果、終了した診断項目がある場合（Ｙ）、ステップＳ２４に遷移する。また、新たに終了した診断項目がない場合（Ｎ）、ステップＳ２３を繰り返す。なお、診断の終了とは、診断結果を示す診断情報を出力可能な状態であることを示し、診断処理自体の終了、診断情報の作成、通信状況による送信待ちの解除などが含まれる。なお、このような診断項目を診断終了項目と称する。

【0056】

また、ステップＳ２４において、診断部２３が、診断が終了した診断項目により、標準診断に含まれる全診断項目の診断が終了したかを判定する。つまり、未診断の診断項目が無くなり、診断が終了した診断項目が最後の診断終了項目であるかを判定する。この結果、全診断項目の診断が終了していない、つまり、未診断の診断項目が残っている場合（Ｎ）、ステップＳ２５に遷移する。また、全診断項目の診断が終了している場合（Ｙ）、ステップＳ２６に遷移する。

【0057】

また、ステップＳ２５において、診断部２３が、通信部２１を用いて利用者端末１０に、診断終了診断項目の診断情報を送信する。このために、診断部２３は、診断結果を含む診断情報を作成する。より望ましくは、実施例１や実施例２では、図８に示すような各項目を有する診断情報２５４が作成される。また、診断部２３は、診断された結果を、診断情報２５４して記憶部１７に記憶することが望ましい。そして、診断部２３が、通信部２１を介してこれを送信する。なお、作成された診断情報がステップＳ２１で受信された診断指示に応じた標準診断、つまり、該当の標準診断のうち最初に終了した診断項目である場合、最初の診断項目であることおよび診断定義情報２５２で特定される診断項目表示配列も送信される。

【0058】

また、ステップＳ２６において、診断部２３が通信部２１を用いて利用者端末１０に、標準診断が終了したことを示す終了通知を送信する。このために、診断部２３は、ステップＳ２５と同様に、診断が終了した診断項目の診断情報を作成する。そして、診断部２３は、作成された診断情報および該当の標準診断が終了したことを示す情報を含む終了通知を送信する。以上のステップＳ２３～ステップＳ２６を実行することで、診断部２３は、診断終了項目となった診断項目から順次診断情報を作成し、通信部２１を用いて送信することになる。

【0059】

また、ステップＳ１３において、診断情報配置部１４が、ステップＳ２５もしくはステップＳ２６で送信された診断情報もしくは終了通知についての表示処理を実行する。すなわち、診断情報配置部１４は、出力部１５に、送信された診断情報について、表示配列の表示領域に、当該診断情報を順次表示する。

【0060】

以下、この表示処理の一例について、図１０に示すフローチャートに従い、図１１Ａ～図１１Ｃの表示例を参照しながら説明する。なお、本例では、稼働実績診断－故障診断－予兆診断の順で診断が終了したものとする。また、この表示処理（図１０～図１１Ｃ）も、実施例2と共通してもよい。

【0061】

図１０は、実施例１における表示処理の処理フローを示すフローチャートである。まず、ステップＳ１３１において、通信部１１では、診断情報もしくは終了通知が受信される。以下、診断情報配置部１４がこれらを用いて処理を実行する。

【0062】

ステップＳ１３２において、診断情報配置部１４が、ステップＳ１３１で受信された診断情報が最初の診断終了項目に対する診断情報であるかを判定する。つまり、診断情報配置部１４は、受信された診断情報が、対象の診断に含まれる診断項目のうち、最初に診断情報を出力可能な状態となった診断項目の診断情報であるかを判定する。この結果、最初の診断終了項目である場合（Ｙ）、ステップＳ１３３に遷移する。また、最初の診断終了項目でない場合（Ｎ）、ステップＳ１３６に遷移する。

【0063】

また、ステップＳ１３３において、診断情報配置部１４が、ステップＳ１３１で受信された情報に応じて、診断情報の表示配列を特定する。ここで、表示配列とは、利用者端末１０の出力部１５における表示画面での表示配列を示し、表示画面における複数の表示領域の表示順、表示並びなどの固定的な位置関係を示す。固定的とは、各表示領域の相対的な位置関係が固定的であることを示し、スクロールなどで表示画面での表示位置は固定であってもよいし可変であってもよい。

【0064】

利用者端末１０として、スマートフォンのような縦長の画面を用いる場合、図１１Ａ～図１１Ｃに示す１０１１～１０１３のように画面上部から下部への表示領域を用いることが望ましい。つまり、表示配列として、各表示領域を表示画面の上下方向へ並べる。但し、表示配列は、上部から下部への表示領域には限定されず、左右、中央・周辺などであってもよい。そして、診断情報配置部１４は、診断項目ごとの、特定された表示配列に応じた表示領域に該当する枠組みを、出力部１５に表示する。この枠組みとは、表示領域の外縁を示すが、これに該当の診断項目名を含めてもよい。さらに、各表示領域内には、子領域を設けてもよい。例えば、診断項目ごとに表示領域を設け、当該表示領域内に診断項目の小分類ごとの複数の子領域を設ける。

【0065】

また、ステップＳ１３４において、診断情報配置部１４が、最初の診断終了項目以外の表示領域に対して、診断中である旨の情報を挿入し、表示する。また、ステップＳ１３５において、診断情報配置部１４が、最初の診断終了項目の診断情報を、該当の枠組みに挿入して表示を行う。

【0066】

この結果、利用者端末１０の出力部１５の一例であるタッチパネル１０１には、図１１Ａに示されるように表示がされる。つまり、表示画面であるタッチパネル１０１の上部から、稼働実績診断情報表示領域１０１１、予兆診断情報表示領域１０１２および故障診断情報表示領域１０１３が表示される。そして、稼働実績診断情報表示領域１０１１には、最初の診断終了項目における稼働実績診断の診断情報が表示され、他の表示領域には診断中であることが表示される。なお、診断情報配置部１４は、診断終了項目の診断情報が表示される稼働実績診断情報表示領域１０１１について、見やすい表示としてもよい。例えば、診断情報配置部１４は、画面をスクロールしてタッチパネル１０１の最上部にこれを表示したり、強調表示など他の表示領域と区別して表示したりしてもよい。

【0067】

また、ステップＳ１３６において、診断情報配置部１４が、ステップＳ１３１で受信された診断情報が最後の診断終了項目に対する診断情報であるかを判定する。この結果、最後の診断終了項目に対する診断情報でない場合（Ｎ）、ステップＳ１３５に遷移する。また、最後の診断終了項目に対する診断情報の場合（Ｙ）、ステップＳ１３７に遷移する。ここで、本例では、稼働実績診断の次に故障診断が終了する。

【0068】

このため、ステップＳ１３５において、診断情報配置部１４は、故障診断情報表示領域１０１３にその診断結果を新たに表示する。但し、予兆診断は終了していないため、予兆診断情報表示領域１０１２には図１１Ａから引き続き診断中である旨が表示される。この結果、タッチパネル１０１では、図１１Ａから図１１Ｂに示されるように表示が変更される。つまり、診断が終了している故障診断について、稼働実績診断情報表示領域１０１１、および故障診断情報表示領域１０１３にその診断情報が表示される。また、予兆診断情報表示領域１０１２には診断中であることが引き続き表示される。

【0069】

なお、図１１Ａから図１１Ｂに表示が変更される際、診断情報配置部１４は、表示内容をスクロールし、新たに診断情報が表示される故障診断情報表示領域１０１３が見やすいように、画面をスクロールさせてもよい。特に、故障診断情報表示領域１０１３がタッチパネル１０１の枠外となる場合、診断情報配置部１４はこのように制御することが望ましい。さらに、故障診断情報表示領域１０１３のように新たに診断が終了したものは、スクロール以外の他の表示領域と区別した表示を行ってもよい。

【0070】

また、ステップＳ１３７において、診断情報配置部１４が、最後の診断終了項目の診断情報を、新たに該当の表示領域に挿入し、表示する。この際、診断情報配置部１４は、標準診断が終了したことを示す情報を表示画面に表示してもよい。

【0071】

本例においては、予兆診断情報表示領域１０１２に診断情報が挿入、表示される。この結果、タッチパネル１０１では、図１１Ｂから図１１Ｃに示されるように表示が変更される。つまり、稼働実績診断情報表示領域１０１１、予兆診断情報表示領域１０１２、および故障診断情報表示領域１０１３のそれぞれに診断情報が表示されることになる。なお、ステップＳ１３７においてもステップＳ１３５と同様に、新たに診断情報が表示される予兆診断情報表示領域１０１２はスクロールや強調表示など他の表示領域と区別した表示を行ってもよい。

【0072】

また、ステップＳ１３５およびステップＳ１３７では、所定条件を満たす診断情報の表示形式を変更してもよい。診断情報配置部１４は、該当の診断情報の診断結果に「優先表示」が含まれる場合（例えば、図８の標準診断２の故障診断）、その表示形式を変更する。

【0073】

この表示形式の変更には、固定的な表示配列ないし表示領域の変更や強調表示のような他領域とは区別した表示が含まれる。表示配列の変更には、最上部の表示領域に変更することが含まれる。図８の例の「漏電」のように、利用者のみでは対処が困難もしくは不可能な診断結果の場合、このように表示形式を変更することが望ましい。なお、表示形式を変更とは、例えば(1)稼働実績診断、(2)故障診断、(3)予兆診断の順番で通常表示している場合であっても、例えば対処が困難な「漏電」に関係する(2)故障診断を一番上に移動させる。

【0074】

以上の各処理により、表示配列が特定された各表示領域に、当該診断情報を順次表示することが実現できる。以上で表示処理の処理フローの一例の説明を終わり、図９に戻り、診断処理の説明を続ける。

【0075】

ステップＳ１４において、入力部１６が、利用者から表示された診断情報に対する対処を受け付ける。例えば、入力部１６は、洗剤の補充など利用者が対処を実行したことを受け付ける。また、入力部１６は、コンタクトセンターへの連絡などの対処そのものを受け付けてもよい。そして、ステップＳ１５において、通信部１１が、診断支援装置２０に対して、対処したことを含む対処結果を送信する。

【0076】

また、ステップＳ２７において、診断支援装置２０の通信部２１が、対処結果を受信する。これを受けて、ステップＳ２８において、診断部２３が、追加診断が必要かを判定する。この際、診断部２３は、診断情報２５４から診断された標準診断に対応する追加診断のレコードを特定し、「不要」であることは記録されるかを確認する。この結果、追加診断が必要な場合（Ｙ）、ステップＳ２９に遷移する。また、追加診断が不要な場合（Ｎ）、本処理フローを終了する。

【0077】

実施例１では、ステップＳ２９において、診断部２３が、診断定義情報２５２に従って、追加診断を実行し、端末に表示した場合を記載する。なお、ここでは追加診断の考え方を、標準診断と合わせて説明する。ここでは、各診断のタイミングや利用データについて説明する。

【0078】

図１２Ａは、実施例１形態における標準診断と追加診断の考え方の第１の例を示す図である。なお、図１２Ａでは、図面上、左から右に時間が経過する。これは後述の図１２Ｂ～図１２Ｄでも同様である。

【0079】

図１２Ａにおいて、標準診断が、第１の所定期間（Ａ期間）におけるログデータを利用データとして実行し、端末に表示される。そして、この標準診断では、標準診断を実施した時期よりも一定期間前まで(例えば標準診断日よりも2カ月前まで)のログデータが利用データとして用いられる。この結果、この標準診断の結果(第１のレポート)を示す診断情報が出力される。なお、標準診断では、一定期間前までの第1の所定期間のログデータが用いられる。さらに、標準診断では、一定期間前までの所定運転回数ごとのログデータを用いてもよい。

【0080】

また、診断情報に標準診断が行われた後、つまり、これに対する対処がされる後に、第２の所定期間（Ｂ期間）における関連データを利用データとして、追加診断が実行される。そして、追加診断の診断情報(第２のレポート)が出力される。ここで、A期間にはB期間が含まれないものとし、Ａ期間＞Ｂ期間であることが望ましい。以下の第２の例～第４の例でも、図１２Ｂ～図１２Ｄで示される第１の所定期間、第２の所定期間分の利用データを用いて同様の処理が実行される。

【0081】

次に、第１の所定期間や第２の所定期間が、第１の例よりも短い第２の例について説明する。図１２Ｂは、実施例１における標準診断と追加診断の考え方の第２の例を示す図である。この第２の例では、第１の所定期間や第２の所定期間が、第１の例よりも短い場合を示す。つまり、Ａ期間＞Ａ’期間、Ｂ期間＞Ｂ’期間である。

【0082】

以下、このように所定の期間が異なる理由について説明する。この理由は、家電機器３ｎの状態によって、利用データの所定期間を変えることが望ましいためである。例えば、「ここ最近調子がおかしい」、「急におかしい」、「今、おかしい」との利用者の感触によって所定期間を変えることで、より実態に即した診断が可能になる。

【0083】

これらの例では、「ここ最近調子がおかしい」－「急におかしい」－「今、おかしい」の順で、所定期間を短く設定する。このように設定する理由は、家電機器３ｎの状態が変化の発生・要因が上述の順で、診断指示を行う時間により近接していると考えられるためである。そして、単に各期間の時間的な長さを変えるだけでなく、第２の例における第１の所定期間の終点と第２の所定期間の起点は、同日同時間であることが望ましい。これによって、診断の対象となる日をすべての期間でカバーできることとなる。

【0084】

以下、このための処理について説明する。ステップＳ１１において、入力部１６が状態に関する感触を示す情報を利用者から受け付ける。この感触を示す情報とは、例えば利用者が「ここ最近家電の調子がおかしい」、「急に冷蔵庫が冷えなくなった」、「今、洗濯機が動かない」と利用者が選択できるようになっていることである。これを受けて、ステップＳ１２では、通信部１１により、感触を示す情報、例えば冷えが悪いなどの情報が送信される。そして幾何、ステップＳ２２において、診断部２３が、感触を示す情報に応じて、所定期間を定め、ステップＳ２２やステップＳ２９の各診断を実行する。この結果、家電機器３ｎの状態についての利用者の感触に即した診断が可能になる。

【0085】

次に、第１の例および第２の例とは、診断情報の出力のタイミングが異なる第３の例について説明する。図１２Ｃは、実施例1における標準診断と追加診断の考え方の第３の例を示す図である。第１の例および第２の例では、各診断情報が、診断が実行された際に出力される。これに対して、第３の例では、各診断情報が、診断が実行され一定時間経過した後に出力される。また、第３の例では、Ｂ期間の起点が標準処理を対処した際とされているが、標準診断の診断情報を端末に表示したときを起点としてもよい。さらに、標準診断の診断情報の出力のタイミングと追加診断の診断情報の出力タイミングを異ならせてもよい。例えば、標準診断の診断情報は第１の例のタイミングで出力し、追加診断の診断情報は第３の例のタイミングで出力する。

【0086】

以上の第１の例～第３の例では、Ａ期間が終了すると、Ｂ期間が開始する。ここで、標準診断に対する対処に時間が掛かってしまうと、Ｂ期間の関連データには対処前のデータ含まれることになってしまう。そこで、以下で説明する第４の例では、A区間の関連データから標準診断に対する対処前のデータを除くようにＢ期間を設定する。

【0087】

図１２Ｄは、実施例１における標準診断と追加診断の考え方の第４の例を示す図である。この第４の例では、Ｂ期間の起点を、標準診断に対する対処に際としている。この対処の際としては、対処が実行されたタイミングの他、ステップＳ１５の対処結果の送信のタイミング、ステップＳ２７の対処結果の受信のタイミングを用いることができる。なお、第１の例～第３の例では、標準診断の実行タイミングとして、標準診断の診断情報の作成ないし出力のタイミングを用いてもよいし、対処したタイミングを用いてもよい。以上で、各診断のタイミングや利用データについての説明を終わる。

【0088】

そして、図９のフローチャートでは、ステップＳ２３に遷移し、標準診断と同様に診断を含む固定的な表示配列における各表示領域へ順次表示するための処理を実行する。但し、追加診断では、標準診断とは別の処理を実行してもよい。

【0089】

以上で、図９の説明を終わるが、診断情報配置部１４の少なくとも一部（ステップＳ１３２～Ｓ１３７のうちの一部）を診断支援装置２０の診断情報配置部２４で実行し、診断情報配置部１４ではこれに従って出力部１５での表示を実行してもよい。また、標準診断の処理、つまり、ステップＳ１３までで処理を終わってもよい。さらに、表示配列が特定された各表示領域に、当該診断情報を順次表示することは追加診断に必須でない。また、逆に、標準診断や追加診断の診断情報の表示は順次でなくともよい。一方のみで順次表示してもよい。以上で実施例１の説明を終わる。

【実施例0090】

実施例１では、利用者による対処を条件に追加診断を実行している。但し、追加診断については、対処を条件としなくとも実現できる。その一例について、実施例２として説明する。なお、実施例２の構成や情報は実施例１と共通であるため、その説明は省略し、＜処理フロー＞について説明する。

【0091】

＜処理フロー＞
実施例２では、対処していなかった場合における、家電機器の状態の変化や不具合への対処を促す再通知可能とする。このための処理について説明する。図１３は、実施例２における診断処理の処理フローを示すフローチャートである。図１３において、ステップＳ１１～ステップＳ１３、ステップＳ２１～ステップＳ２６は、実施例１（図９）と同様の処理であるためその説明を省略する。

【0092】

そして、ステップＳ２７１において、診断支援装置２０の診断部２３が、標準診断の結果（第1のレポート）に対する対処結果の受信が無く一定時間経過したかを判定する。つまり、利用者端末１０の通信部１１が、第1のレポートに対する対処結果を送信せず一定時間経過したかが判定される。この結果、一定時間が経過している場合（Ｙ）、ステップＳ２７２に遷移する。また、一定時間内に対処結果を受信していない場合（Ｎ）、ステップＳ２７３に遷移する。なお、一定時間の起点としては、ステップＳ２５等の送信のタイミングや標準診断のタイミングなどを用いることができる。

【0093】

また、ステップＳ２７３において、診断部２３は、対処結果が不具合の終息を示すか判定する。つまり、利用者端末１０の通信部１１が、不具合の終息を示す対処結果を送信したかを判定する。この結果、終息している場合（Ｙ）、実施例１のステップＳ２９に遷移して追加診断が実行される。また、終息していない場合（Ｎ）、実施例１のステップＳ２８に遷移して追加診断の要否が判定される。なお、対処結果の終息は、利用者による対処による終息や対処がなく自然な終息のいずれであってよい。また、終息している場合（Ｙ）、本処理フローを終了してもよい。

【0094】

また、ステップＳ２７２において、診断部２３が通信部２１を用いて利用者端末１０に、第1のレポート（不具合）に関する確認通知を送信する。つまり、ステップＳ２５で送信される診断情報への対応をリマンドすることになる。なお、確認通知は、第1のレポートに対する確認や対処を促す内容を示す。

【0095】

そして、利用者端末１０の通信部１１が、標準診断に対する対処が無い場合、確認通知を受信する。そして、出力部１５が、この確認通知を出力することになる。この結果、対処を促す再通知を実現している。

【0096】

そして、ステップＳ２７４において、診断部２３が、ステップＳ２７２での確認通知に対する回答を、利用者端末１０から受信したかを判定する。この判定は、回答の受信が無く一定時間経過したかを判定する。この一定時間は、ステップＳ２７１と同じ長さであってもよいし、別のながさであってもよい。また、この一定時間の起点としては、ステップＳ２７２の送信のタイミングなどを用いることができる。この結果、回答が有った場合、ステップＳ２８に遷移する。また、回答が無かった場合、ステップＳ２９に遷移する。

【0097】

以上の結果、実施例２では、対処を促す再通知が実現できる。また、利用者の対処が無くとも追加診断を実現できる。また、実施例２には、以下の変形例も含まれる。

【0098】

＜変形例１＞
ステップＳ２７１において、一定時間が経過している場合（Ｙ）、利用者は対処しない可能性が高いと推定されるので、そのまま本処理フローを終了する。

【0099】

＜変形例２＞
ステップＳ２７１において、一定時間が経過している場合（Ｙ）、ステップＳ２９に遷移して追加診断を実行し、通信部２１を用いて追加診断の結果（第2のレポート）を、利用者端末１０に送信する。

【0100】

＜変形例３＞
変形例３は、上述の実施例２に、変形例２の処理を組み合わせて実行する。すなわち、ステップＳ２７１で、一定時間が経過している場合（Ｙ）、ステップＳ２７２において、以下の処理を実行する。診断部２３が、（１）通信部２１を用いて利用者端末１０に確認通知を送信し、（２）ステップＳ２９に遷移して追加診断を実行し、通信部２１を用いて追加診断の結果（第2のレポート）を、利用者端末１０に送信する。

【0101】

以上で、実施例１および実施例２の説明を終わるが、本発明はこれら各実施例に限定されない。例えば、上述の処理を家電機器３ｎ単独もしくは利用者端末１０や診断支援装置２０と連携して行ってもよいし、利用者端末１０や診断支援装置２０単独で実行してもよい。特に、診断支援装置２０で実行される場合、これに入力デバイスや出力デバイスを設けたり、接続したりすることが望ましい。

【0102】

さらに、診断対象には、家電機器３ｎ以外の機器、例えば、工場の生産機器やビルなどで用いられる各種産業用機器も含まれる。また、運輸等のサービス用機器も診断対象に含まれる。