特許 6765400 デバイス診断サーバ及びプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6765400

(24)【登録日】2020年9月17日

(45)【発行日】2020年10月7日

(54)【発明の名称】デバイス診断サーバ及びプログラム

(51)【国際特許分類】

   G06Q 10/00 20120101AFI20200928BHJP

【ＦＩ】

   G06Q10/00 300

【請求項の数】3

【全頁数】13

(21)【出願番号】特願2018-187330(P2018-187330)

(22)【出願日】2018年10月2日

(65)【公開番号】特開2020-57193(P2020-57193A)

(43)【公開日】2020年4月9日

【審査請求日】2019年3月18日

(73)【特許権者】

【識別番号】501440684

【氏名又は名称】ソフトバンク株式会社

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】杉野 雅之

【審査官】 田中 秀樹

(56)【参考文献】

【文献】 特開２０１６−１７３７８２（ＪＰ，Ａ）

【文献】 特開２０１６−１５７２８０（ＪＰ，Ａ）

【文献】 特開２０１１−１７５５０４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

デバイスの稼働状態をあらわすデバイス・ログデータを取得する第１取得部と、
デバイスの修理内容をあらわす修理受付データを取得する第２取得部と、
前記デバイスが利用する通信ネットワークの状態をあらわすネットワーク・ログデータを取得する第３取得部と、
同一デバイスにおける前記デバイス・ログデータと前記修理受付データとの対を訓練データとして学習し、学習モデルを生成する学習部と、
あるデバイスの前記デバイス・ログデータが、前記第１取得部によって取得された場合に、取得された前記デバイス・ログデータ及び前記学習モデルを利用して、前記あるデバイスにどのような故障がいつ頃発生するかを推定する推定部と、
推定結果を出力する出力部とを具備し、
前記推定部は、前記あるデバイスについて前記デバイス・ログデータが取得できない場合には、前記あるデバイスの直近のデバイス・ログデータ、前記ネットワーク・ログデータ及び前記学習モデルを利用して、前記あるデバイスにどのような故障がいつ頃発生するかを推定する、デバイス診断サーバ。

【請求項2】

前記推定部が、現時点で故障はしていないものの、所定期間内に故障する可能性が高いと推定した場合、前記出力部は、前記推定結果を当該デバイスに通知する、請求項１に記載のデバイス診断サーバ。

【請求項3】

デバイスを診断するコンピュータによって実行されるプログラムであって、
前記コンピュータを、
デバイスの稼働状態をあらわすデバイス・ログデータを取得する第１取得部と、
デバイスの修理内容をあらわす修理受付データを取得する第２取得部と、
前記デバイスが利用する通信ネットワークの状態をあらわすネットワーク・ログデータを取得する第３取得部と、
同一デバイスにおける前記デバイス・ログデータと前記修理受付データとの対を訓練データとして学習し、学習モデルを生成する学習部と、
あるデバイスの前記デバイス・ログデータが、前記第１取得部によって取得された場合に、前記デバイス・ログデータ及び前記学習モデルを利用して、前記あるデバイスにどのような故障がいつ頃発生するかを推定する推定部と、
推定結果を出力する出力部として機能させ、
前記推定部は、前記あるデバイスについて前記デバイス・ログデータが取得できない場合には、前記あるデバイスの直近のデバイス・ログデータ、前記ネットワーク・ログデータ及び前記学習モデルを利用して、前記あるデバイスにどのような故障がいつ頃発生するかを推定する、ためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネット等の通信ネットワークを通じてデバイスの状態を効率よく診断するための技術に関する。

【背景技術】

【0002】

一般に、スマートフォンなどのデバイスを所持する顧客は、デバイスに何らかの不具合が生じたとき、販売店の修理受付カウンタにて修理依頼を行う、または修理サービスセンタにデバイスを配送して修理依頼を行っている（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００２−９２２０６号公報

【発明の概要】

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

【0004】

ところで、上述した従来のアフターサービスにおいては、修理サービスセンタの作業スタッフが配送されるデバイスの状態を診断したうえで、修理費用の見積を作成し、顧客に見積書を郵送している。その後、修理サービスセンタの作業スタッフは、顧客からの正式な修理依頼を受けることで、デバイスの修理を開始する。このように、従来のアフターサービスにおいては、修理サービスセンタへデバイスが配送されてから、実際に修理が開始されるまでに長期間を要する、という問題がある。

【0005】

本発明は、以上説明した事情を鑑みてなされたものであり、従来に比してデバイスの状態を早期に診断することで、迅速かつ利便性の高いアフターサービスを実現することが可能なデバイス診断技術を提供することを目的の一つとする。

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

【0006】

本開示の一形態に係るデバイス診断サーバは、デバイスの状態をあらわすデバイス・ログデータを取得する第１取得部と、デバイスの修理内容をあらわす修理受付データを取得する第２取得部と、同一デバイスにおける前記デバイス・ログデータと前記修理受付データとの対を訓練データとして学習し、学習モデルを生成する学習部と、あるデバイスの前記デバイス・ログデータが、前記第１取得部によって取得された場合に、取得された前記デバイス・ログデータ及び前記学習モデルを利用して、前記あるデバイスの状態を推定する推定部と、推定結果を出力する出力部とを具備することを要旨とする。

【0007】

本開示の他の形態に係るプログラムは、デバイスを診断するコンピュータによって実行されるプログラムであって、前記コンピュータを、デバイスの状態をあらわすデバイス・ログデータを取得する第１取得部と、デバイスの修理内容をあらわす修理受付データを取得する第２取得部と、同一デバイスにおける前記デバイス・ログデータと前記修理受付データとの対を訓練データとして学習し、学習モデルを生成する学習部と、あるデバイスの前記デバイス・ログデータが、前記第１取得部によって取得された場合に、前記デバイス・ログデータ及び前記学習モデルを利用して、前記あるデバイスの状態を推定する推定部と、推定結果を出力する出力部として機能させることを要旨とする。

【発明の効果】

【0008】

本発明によれば、従来に比してデバイスの状態を早期に診断することで、迅速かつ利便性の高いアフターサービスを実現することが可能となる。

【図面の簡単な説明】

【0009】

【図1】本実施形態に係るデバイス診断システムの概略構成を示す図である。

【図2】デバイス診断システムの概要を示す概念図である。

【図3】デバイス診断サーバの機能構成を示すブロック図である。

【図4】学習部による学習動作の概念図である。

【図5】デバイス・ログデータを例示した図である。

【図6】修理受付データを例示した図である。

【図7】訓練データを例示した図である。

【図8】学習モデルの生成イメージをあらわす概念図である。

【図9】推定部に入力されるあるデバイスのデバイス・ログデータを例示した図である。

【図10】学習モデル生成処理を示すフローチャートである。

【図11】デバイス診断処理を示すフローチャートである。

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

【0010】

以下、本発明の実施形態について図面を参照しつつ詳細に説明する。なお、以下の説明において同一の要素には同一の符号を付し、重複する説明を省略する。

【0011】

Ａ．本実施形態
Ａ−１．概要
図１は、本実施形態に係るデバイス診断システム１０００の概略構成を示す図である。
デバイス診断システム１０００は、各ユーザが所持するデバイス１００と、デバイス診断サーバ２００と、基地局などの通信装置３００とを備えて構成される。

【0012】

各デバイス１００と、デバイス診断サーバ２００とは、それぞれ通信装置３００、通信ネットワークＮを介して相互に接続されている。通信ネットワークＮは、例えば、インターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース、ＷｉＦｉ（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであってもよく、有線であるか無線であるかを問わない。

【0013】

図２は、デバイス診断システム１０００の概要を示す概念図である。
デバイス１００には、デバイスの稼働状態をあらわすデバイス・ログデータを収集する専用アプリケーション（以下、「ログ収集アプリ」という。）ＡＰが搭載されている。デバイス１００は、所定のタイミングで、収集したデバイス・ログデータをデバイス診断サーバ２００に送信する（ステップＳ１）。

【0014】

一方、ユーザはデバイス１００に何らかの故障（例えば電源が入らない）が発生すると、デバイス販売店等にて修理受付を行う。デバイス販売店等にて修理が受け付けられると、修理内容をあらわす修理受付データがデバイス診断サーバ２００に送信される（ステップＳ２）。

【0015】

デバイス診断サーバ２００は、同一デバイス１００のデバイス・ログデータと、修理受付データとの対を、訓練データとして学習し、学習モデルを生成する。この学習モデルは、デバイス１００において、いかなる事象（イベント）が検知されると、いかなる故障がいつ頃発生するか等（すなわち、デバイス１００の状態）を推定するためのアルゴリズムである。

【0016】

その後、デバイス診断サーバ２００は、いずれかのデバイス１００からデバイス・ログデータを取得すると、生成した学習モデルを利用して当該デバイス１００の状態を推定し（ステップＳ３）、推定結果を外部（例えば、デバイス販売店やデバイスのユーザなど）に出力する（ステップＳ４）。

【0017】

なお、通信装置３００は、デバイス１００が利用する通信ネットワークの稼働状態をあらわすネットワーク・ログデータを収集する。各通信装置３００は、デバイス診断サーバ２００からの求めに応じて、ネットワーク・ログデータをデバイス診断サーバ２００に送信する（ステップＳ５）。詳述すると、デバイス診断サーバ２００は、例えばデバイス１００から予め設定されたタイミングでデバイス・ログデータを取得できない場合や、ポーリングに応答しない場合などは、当該デバイス１００が故障していると判断し、通信装置３００に対してネットワーク・ログデータの送信要求（取得要求）を行う。通信装置３００は、デバイス診断サーバ２００からの求めに応じてネットワーク・ログデータを取得し、デバイス診断サーバ２００に返信する。デバイス診断サーバ２００は、通信装置３００からネットワーク・ログデータを受信すると、受信したネットワーク・ログデータと、当該デバイス１００の直近のデバイス・ログデータと、デバイス診断用の学習モデルを利用して、当該デバイス１００の状態を推定する。そして、デバイス診断サーバ２００は、推定結果を外部に出力する。

【0018】

デバイス診断システム１０００によれば、ユーザが故障したデバイス１００を販売店等に持ち込む前に、いかなる故障が発生したのかをデバイス診断サーバ２００において検知することが可能となる。これにより、検知のタイムラグを無くすだけでなく、ユーザへの予防保全や、販売店等におけるデバイスの買い替え促進準備や修理受付業務の効率化（例えば来店予約や代替えデバイスの事前手配）など、迅速かつ利便性の高いアフターサービスを実現することが可能となる。

【0019】

Ａ−２．構成
[デバイス１００]
デバイス１００は、ユーザが所持等する端末であり、例えばスマートフォンや、携帯電話機などである。
デバイス１００のメモリには、各種の制御プログラムのほか、上述したログ収集アプリＡＰが格納されている。また、デバイス１００には、例えば以下に例示する各種センサの一部（または全部）が搭載されている。
＜各種センサ＞
・加速度センサ、周囲温度センサ、重力センサ、ジャイロセンサ、光センサ、線形加速センサ、地磁気センサ、方位センサ、気圧センサ、近接センサ、相対温度センサ、回転ベクトルセンサ、温度センサなど。

【0020】

デバイス１００は、各種センサによって検知される情報に基づき、デバイス識別番号、基地局ＩＤ、電波強度、ＧＰＳ位置情報、ソフトウェアバージョン、ＣＰＵ温度、ＣＰＵ負荷、バッテリ温度、充電回数、バッテリ容量など、デバイスの稼働状態をあらわすデバイス・ログデータを生成・収集する。また、デバイス１００は、収集したデバイス・ログデータを、所定のタイミング（例えば、一定の時間間隔）でデバイス診断サーバ２００に送信する。

【0021】

なお、デバイス１００は、通信ネットワークＮを介してデータの授受が可能な端末であればよく、携帯情報端末（ＰＤＡ）、タブレット端末や、パーソナルコンピュータ（ＰＣ）、ノートＰＣなどでもよい。

【0022】

[デバイス診断サーバ２００]
デバイス診断サーバ２００は、管理下にあるデバイス１００の状態を診断（推定）する装置であり、例えばサーバコンピュータなどにより構成される。

【0023】

図３は、デバイス診断サーバ２００の機能構成を示すブロック図である。
デバイス診断サーバ２００は、制御部２１０と、データ取得部２２０と、記憶部２３０と、学習部２４０と、推定部２５０と、出力部２６０とを備えている。

【0024】

制御部２１０は、ＣＰＵ、ＲＯＭ、ＲＡＭなどを主要構成部品とするＭＣＵ（Micro Control Unit）などを備えており、ＲＯＭやＲＡＭに格納された各種プログラム等を実行することにより、デバイス診断サーバ２００の各部を統括的に制御する。

【0025】

データ取得部２２０は、外部から所定のデータを取得するものであり、第１取得部２２１、第２取得部２２２、第３取得部２２３を備えており、外部から所定のデータを取得し、取得した各データを学習部２４０に供給する。

【0026】

第１取得部２２１は、各デバイス１００から所定のタイミングで送信されるデバイス・ログデータを取得する。
第２取得部２２２は、デバイス販売店等にて修理受付が行われた各デバイス１００の修理内容をあらわす修理受付データを取得する。修理受付データは、例えばデバイス販売店等にて修理受付を行ったオペレータがＰＣ端末（図示略）に入力し、ＰＣ端末からデバイス診断サーバ２００に所定のタイミングで送信すればよい。
第３取得部２２３は、各通信装置３００から所定のタイミングで送信されるネットワーク・ログデータを収集する。

【0027】

記憶部２３０は、例えばフラッシュメモリなどにより構成され、デバイス・ログデータや修理受付データ、ネットワーク・ログデータをはじめとする各種のデータを一時的に記憶する。

【0028】

学習部２４０は、デバイス・ログデータ及び修理受付データを利用して、デバイス１００の状態を診断するための学習を行うものであり、訓練データ生成部２４１と学習モデル生成部２４２とを備えている。

【0029】

図４は、学習部２４０による学習動作の概念図である。
訓練データ生成部２４１は、各デバイス１００のデバイス・ログデータと修理受付データから訓練データを生成する。図５〜図７は、それぞれデバイス・ログデータ、修理受付データ、訓練データを例示した図である。
デバイス・ログデータは、デバイス識別番号、ログデータを取得した時間（ログタイム）、基地局ＩＤ、ソフトウェアのバージョン情報、充電回数のほか、ユーザがデバイス１００で利用するアプリケーションを特定するアプリケーション情報（利用アプリ１、利用アプリ２）、操作履歴をあらわす操作ログ情報などを含んでいる（図５参照）。

【0030】

一方、修理受付データは、修理受付番号、デバイス１００の機種名、デバイス識別番号、製造年月日、購入日のほか、修理受付日時をあらわす修理受付日情報、修理区分をあらわす修理区分情報、ユーザによる修理の申告内容をあらわす申告情報、修理受付をした地域をあらわす修理地域情報、修理受付をした店舗をあらわす修理店舗情報などを含んでいる（図６参照）。

【0031】

訓練データ生成部２４１は、デバイス・ログデータ及び修理受付データに含まれるデバイス識別番号をキーとすることで、同一デバイスに係るデバイス・ログデータと修理受付データを特定する。そして、訓練データ生成部２４１は、デバイス・ログデータと修理受付データとの対からなる訓練データを生成する（図７参照）。なお、訓練データは、デバイス稼働中に、どのようなデバイス・ログデータが取得されると、どのような故障がいつ頃発生する可能性が高いか等を学習するために必要なデータセットである。

【0032】

学習モデル生成部２４２は、訓練データを用いて学習することで、デバイス診断用の学習モデルを生成する。図８は、学習モデルの生成イメージをあらわす概念図である。
図８は、ある機種について、各デバイスのデバイス・ログデータに示される充電回数と、“電源入らず”との理由により修理受付が行われた各デバイスの修理受付データに示される充電回数との関係をあらわす学習モデルを例示している。

【0033】

図８に示す学習モデルでは、デバイス・ログデータに示される充電回数が、ある閾値（例えば、５００回；以下、「学習閾値」という。）を超えると、そのデバイスについては、電源入らずという事象により、後に修理に出される可能性が高くなる、といった推定が行われる。なお、図８では、学習対象として「充電回数」を例示しているが、「加速度」、「重力」、「ジャイロセンサの値」など、様々なパラメータを利用してもよい。

【0034】

推定部２５０は、いずれかのデバイス１００からデバイス・ログデータが入力されると、学習モデル生成部２４２によって生成された学習モデルを利用して、当該デバイス１００の状態を推定する。図９は、推定部２５０に入力されるあるデバイス１００のデバイス・ログデータを例示した図である。

【0035】

図９の例では、デバイス・ログデータに示される充電回数が「７１５回」であり、学習モデルに示される学習閾値「５００回」を超えている。よって、推定部２５０は、当該デバイス１００については、「電源」（電源入らずなど）に関する修理が１か月以内に発生する、と推定する。

【0036】

出力部２６０は、推定部２５０による推定結果を外部に出力する。例えば、当該デバイス１００については、電源（電源入らずなど）に関する修理が１か月以内に発生する、といった推定結果を推定部２５０から受け取ると、出力部２６０は、受け取った推定結果を当該デバイス１００宛てに送信する。このように、本実施形態では、現時点で故障はしていないものの、所定期間内に故障する可能性が高いと推定部２５０が推定した場合、出力部２６０は、推定結果を当該デバイス１００に通知する態様としたが、送信先は、当該デバイス１００に限る趣旨ではなく、販売店等や、デバイスの開発センタ、修理センタ（いずれも図示略）などであってもよい。

【0037】

[通信装置３００]
通信装置３００は、例えば基地局などによって構成され、デバイス１００が利用する通信ネットワークの稼働状態をあらわすネットワーク・ログデータを収集する。デバイス診断サーバ２００は、デバイス１００から予め設定されたタイミングでデバイス・ログデータを取得できない場合や、ポーリングに応答しない場合は、デバイス１００が故障していると判断し、通信装置３００に対してネットワーク・ログデータの送信要求（取得要求）を行う。通信装置３００は、デバイス診断サーバ２００からの求めに応じて、ネットワーク・ログデータをデバイス診断サーバ２００に送信する。なお、ネットワーク・ログデータには、例えば基地局ＩＤ、電波強度、基地局の位置情報などが含まれている。

【0038】

デバイス診断サーバ２００は、デバイス１００の故障によってデバイス・ログデータを取得できない場合には、通信装置３００からネットワーク・ログデータを取得するとともに、記憶部等に格納されている当該デバイス１００の直近のデバイス・ログデータを利用して、当該デバイス１００の状態の推定を行う。

【0039】

これにより、当該デバイス１００が故障して最新のデバイス・ログデータを取得できない場合でも、ネットワーク・ログデータを活用することで、当該デバイス１００の状態の推定（すなわち、デバイス診断）を、精度よく行うことが可能となる。以下、デバイス診断サーバ２００による学習モデル生成処理及びデバイス診断処理の動作について説明する。

【0040】

Ａ−３．動作
[学習モデル生成処理]
図１０は、学習モデル生成処理を示すフローチャートである。
デバイス診断サーバ２００の第１取得部２２１は、各デバイス１００からデバイス・ログデータを受信する（ステップＳＡ１）。一方、第２取得部２２２は、販売店等から修理受付データを受信する（ステップＳＡ２）。第１取得部２２１及び第２取得部２２２によって取得された各データは、記憶部２３０に順次格納される。

【0041】

訓練データ生成部２４１は、デバイス・ログデータ及び修理受付データに含まれるデバイス識別番号をキーとすることで、同一デバイスに係るデバイス・ログデータと修理受付データを特定する。そして、訓練データ生成部２４１は、デバイス・ログデータと修理受付データとの対からなる訓練データを生成する（ステップＳＡ３）。

【0042】

学習モデル生成部２４２は、訓練データを用いて学習することで、例えば図８に示すようなデバイス診断用の学習モデルを生成し（ステップＳＡ４）、処理を終了する。

【0043】

[デバイス診断処理]
図１１は、デバイス診断処理を示すフローチャートである。なお、以下に示すデバイス診断処理は、デバイス診断用の学習モデルが既に生成されている場合を想定する。
デバイス診断サーバ２００の制御部２１０は、各デバイス１００について、正常にデバイス・ログデータを受信できているか否かを判断する（ステップＳＢ１）。詳述すると、設定されたタイミングでデバイス・ログデータを受信している場合には、制御部２１０は、正常にデバイス・ログデータを受信していると判断する一方、設定されたタイミングでデバイス・ログデータを受信できない場合には、正常にデバイス・ログデータを受信できていないと判断する。制御部２１０は、判断結果を推定部２５０に通知する。

【0044】

推定部２５０は、制御部２１０から、正常にデバイス・ログデータを受信できている旨の通知を受けとると（ステップＳＢ１；ＹＥＳ）、新たに受信されるデバイス・ログデータとデバイス診断用の学習モデルを利用して、当該デバイス１００の状態を推定する（ステップＳＢ２；図９参照）。そして、推定部２５０は、推定結果を出力部２６０に供給する。

【0045】

出力部２６０は、推定部２５０から供給される推定結果を、当該デバイス１００等に送信し（ステップＳＢ３）、処理を終了する。

【0046】

一方、推定部２５０は、制御部２１０から、正常にデバイス・ログデータを受信できていない旨の通知を受けとると（ステップＳＢ１；ＮＯ）、通信装置３００に対してネットワーク・ログデータの送信要求を行う。通信装置３００は、かかる要求に応じて、基地局ＩＤ、電波強度、基地局の位置情報などを含むネットワーク・ログデータを取得し、デバイス診断サーバ２００に送信する。デバイス診断サーバ２００の第３取得部２２３は、通信装置３００からネットワーク・ログデータを受信すると（ステップＳＢ４）、記憶部２３０に格納するとともに、推定部２５０に送る。

【0047】

推定部２５０は、ネットワーク・ログデータと、直近のデバイス・ログデータと、デバイス診断用の学習モデルを利用して、当該デバイス１００の状態を推定する（ステップＳＢ５）。そして、推定部２５０は、推定結果を出力部２６０に供給する。

【0048】

出力部２６０は、推定部２５０から供給される推定結果を、当該デバイス１００等に送信し（ステップＳＢ３）、処理を終了する。

【0049】

以上説明したように、本実施形態によれば、各デバイス１００から取得されるデバイス・ログデータと、販売店等から取得される修理受付データとの対をもとに、訓練データを生成し、生成した訓練データから学習モデルを生成する。そして、生成した学習モデルと、稼働中のデバイスから送信されるデバイス・ログデータをもとに、当該デバイス１００の状態を推定（診断）するため、迅速かつ精度の高いデバイス診断が可能となる。

【0050】

さらに、当該デバイス１００が故障して最新のデバイス・ログデータを取得できない場合でも、ネットワーク・ログデータを活用することで、当該デバイス１００の状態の推定（すなわち、デバイス診断）を、精度よく行うことが可能となる。

【0051】

Ｂ．変形例
本発明は、上述した本実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述した各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更し、または並列に実行することができる。

【0052】

また、本明細書において、「部」とは、単に物理的構成を意味するものではなく、その「部」が実行する処理をソフトウェアによって実現する場合も含む。また、１つの「部」が実行する処理を２つ以上の物理的構成や装置により実現されても、２つ以上の「部」が実行する処理を１つの物理的手段や装置により実現されてもよい。

【0053】

本明細書において説明した各処理を実施するプログラムは、記録媒体に記憶させてもよい。この記録媒体を用いれば、デバイス診断システム１０００を構成する各コンピュータに、上記プログラムをインストールすることができる。ここで、上記プログラムを記憶した記録媒体は、非一過性の記録媒体であっても良い。非一過性の記録媒体は特に限定されないが、例えば、ＣＤ−ＲＯＭ等の記録媒体であっても良い。

【符号の説明】

【0054】

１０００…デバイス診断システム、Ｎ…通信ネットワーク、１００…デバイス、ＡＰ…ログ収集アプリ、２００…デバイス診断サーバ、２１０…制御部、２２０…データ取得部、２２１…第１取得部、２２２…第２取得部、２２３…第３取得部、２３０…記憶部、２４０…学習部、２４１…訓練データ生成部、２４２…学習モデル生成部、２５０…推定部、２６０…出力部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】