特許 7515682 情報処理装置、情報処理方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-07-04

(45)【発行日】2024-07-12

(54)【発明の名称】情報処理装置、情報処理方法及びプログラム

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20240705BHJP

【ＦＩ】

G06Q10/20

【請求項の数】 6

(21)【出願番号】P 2023201501

(22)【出願日】2023-11-29

【審査請求日】2023-11-29

【早期審査対象出願】

(73)【特許権者】

【識別番号】517330830

【氏名又は名称】アシュリオンジャパン・ホールディングス合同会社

(74)【代理人】

【識別番号】100079108

【弁理士】

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

(74)【代理人】

【識別番号】100109346

【弁理士】

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

(74)【代理人】

【識別番号】100117189

【弁理士】

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

(74)【代理人】

【識別番号】100134120

【弁理士】

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

(72)【発明者】

【氏名】安野 雅之

【審査官】阿部 潤

(56)【参考文献】

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

【文献】特開２０２２－１６９２１７（ＪＰ，Ａ）

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

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

Ｇ０６Ｑ １０／００ － ９９／００

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

【請求項1】

ユーザが利用中の端末に関する端末データを取得する取得部と、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定する推定部と、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定する判定部と、
を有し、
前記推定部は、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨する推奨部、を有し、
前記推奨部は、前記判定部により、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
情報処理装置。

【請求項2】

前記判定部は、前記消耗度及び前記故障率に加えて、前記端末が備える部品の在庫状況に基づいて、更に、前記端末が備える部品ごとに交換を推奨する時期を判定する、
請求項１に記載の情報処理装置。

【請求項3】

前記判定部は、前記端末が備える部品の交換を推奨すると判定したとき、前記端末を、少なくとも１つのグレードにランク付けする、
請求項１に記載の情報処理装置。

【請求項4】

前記端末データには、少なくとも前記端末から取得したテレメトリデータ、前記端末の過去の修理実績データが含まれる、
請求項１に記載の情報処理装置。

【請求項5】

ユーザが利用中の端末に関する端末データを取得するステップと、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定するステップと、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定するステップと、
を含み、
前記推定するステップは、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨するステップ、を有し、
前記推奨するステップは、前記判定するステップにより、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
情報処理装置が実行する情報処理方法。

【請求項6】

ユーザが利用中の端末に関する端末データを取得するステップと、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定するステップと、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定するステップと、
をコンピュータに実行させるためのプログラムであって、
前記推定するステップは、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨するステップ、を有し、
前記推奨するステップは、前記判定するステップにより、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

携帯端末の契約、販売及び故障対応を行う店舗には、使用中の携帯端末に不具合があると訴えるユーザが来店する。不具合を訴えるユーザが来店した場合、店員は、ユーザから不具合の内容をヒアリングし、専用のテスタに接続することで故障有無の診断を行い、診断結果に応じて修理及び端末交換を行う。なお、特許文献１には、携帯端末の不具合を診断する技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００３－０５１８８２号公報

【発明の概要】

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

【0004】

上述の通り、現状の故障対応は、ユーザの申告を受けてから行われることが一般的である。しかしながら、申告を受けてから修理又は交換を行う場合、ユーザの要望等により、部分的な部品交換で済むにも関わらず、端末ごと交換を行うなどの過剰な対応が行われる可能性がある。

【0005】

そこで、本発明は、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することを目的とする。

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

【0006】

本発明の一態様に係る情報処理装置は、ユーザが利用中の端末に関する端末データを取得する取得部と、前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定する推定部と、前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定する判定部と、を有する。

【発明の効果】

【0007】

本発明によれば、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することができる。

【図面の簡単な説明】

【0008】

【図1】図１は、本実施形態に係る管理システムの一例を示す図である。

【図2】図２は、管理装置のハードウェア構成例を示す図である。

【図3】図３は、管理装置の機能ブロック構成例を示す図である。

【図4】図４は、部品管理ＤＢの一例を示す図である。

【図5】図５は、在庫管理ＤＢの一例を示す図である。

【図6】図６は、交換推奨時期を判定する処理手順の一例を示すフローチャートである。

【図7】図７は、交換推奨時期を示す判定条件データの一例を示す図である。

【図8】図８は、交換状況を更新する処理手順の一例を示すフローチャートである。

【図9】図９は、ユーザに修理提案又は推奨機種提案を行う際の処理手順の一例を示すフローチャートである。

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

【0009】

添付図面を参照して、本発明の実施形態について説明する。各図において、同一の符号を付したものは、同一又は同様の構成を有する。

【0010】

＜システム構成＞
図１は、本実施形態に係る管理システム１の一例を示す図である。管理システム１は、管理装置１０と、１以上の端末２０とを含む。管理装置１０と端末２０は、無線通信ネットワークを介して接続され、相互に通信を行うことができる。

【0011】

管理装置１０は、ユーザが利用する端末２０を管理する装置である。管理装置１０は、１又は複数の物理的なサーバ等から構成されていてもよいし、ハイパーバイザー（hypervisor）上で動作する仮想的なサーバを用いて構成されていてもよいし、クラウドサーバを用いて構成されていてもよい。

【0012】

端末２０は、スマートフォン、タブレット端末、携帯電話機、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、携帯情報端末（ＰＤＡ）、家庭用ゲーム機器など、ユーザが利用する端末であれば、どのような端末であってもよい。

【0013】

管理装置１０は、ユーザが利用する端末２０を構成する部品ごとに部品状態を管理するとともに、端末２０の端末データに基づいて、将来不具合が発生することが予想される部品の有無等を推定する。また、管理装置１０は、将来不具合が発生することが予想される部品が存在する場合、不具合が生じる前に、ユーザに対し部品交換を推奨する。ここで、端末データは、端末２０に関連するデータであり、例えば、テレメトリデータ、診断データ、症状データ、及び、修理実績データ等を含む。テレメトリデータ、診断データ、症状データ、及び、修理実績データの具体例等については後述する。なお、テレメトリデータ、診断データ、症状データ、及び、修理実績データは端末データの一例に過ぎない。端末データには、テレメトリデータ、症状データ、及び、修理実績データの全部が含まれていてもよいし、一部のデータが含まれていなくてもよいし、更に他のデータが含まれていてもよい。

【0014】

また、管理装置１０は、端末２０と、当該端末２０を利用するユーザとの相性を推定し、推定結果に応じて端末２０の買い替えを推奨するようにしてもよい。例えば、主にメール及びＷｅｂブラウジングを行うユーザが、３次元ゲームを円滑にプレイ可能な端末２０を所持しているなど、ユーザの利用形態と端末２０のスペックが不一致であるユーザに対し、端末２０の部品交換に代えて端末２０の買い替えを推奨することが考えらえる。

【0015】

また、管理装置１０は、部品状態を管理する端末２０に対し、端末２０の品質を示す複数のグレードにランク付けするようにしてもよい。例えば、ユーザから端末２０を買い取り又は下取り等を行い、中古市場に流通させる際に、端末２０の品質をランク付けすることで端末２０の円滑な流通を実現することができる。

【0016】

＜ハードウェア構成＞
図２は、管理装置１０のハードウェア構成例を示す図である。管理装置１０は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphical Processing Unit）等のプロセッサ１１、メモリ、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等の記憶装置１２、有線又は無線通信を行う通信ＩＦ（Interface）１３、入力操作を受け付ける入力デバイス１４、及び情報の出力を行う出力デバイス１５を有する。入力デバイス１４は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等である。出力デバイス１５は、例えば、ディスプレイ、タッチパネル及び／又はスピーカ等である。

【0017】

＜機能ブロック構成＞
図３は、管理装置１０の機能ブロック構成例を示す図である。管理装置１０は、記憶部１００と、取得部１０１と、推定部１０２と、判定部１０３と、推奨部１０４と、表示制御部１０５と、収集部１０６とを含む。記憶部１００は、管理装置１０が備える記憶装置１２を用いて実現することができる。また、取得部１０１と、推定部１０２と、判定部１０３と、推奨部１０４と、表示制御部１０５と、収集部１０６とは、管理装置１０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

【0018】

記憶部１００は、端末データＤＢ１００ａと、部品管理ＤＢ１００ｂと、在庫管理ＤＢ１００ｃとを記憶する。端末データＤＢ１００ａは、取得部１０１によって端末２０から取得された端末データを格納するＤＢ（DataBase）である。部品管理ＤＢ１００ｂは、端末２０を構成する各種の部品について、部品ごとの交換実績、交換推奨時期等を管理するＤＢである。在庫管理ＤＢ１００ｃは、端末２０を構成する各種の部品について、部品ごとの在庫状況を管理するＤＢである。

【0019】

取得部１０１は、ユーザが利用中の端末２０に関する端末データを取得する。例えば、当該端末データには、少なくとも端末２０から取得したテレメトリデータ、端末２０の過去の修理実績データが含まれていてもよい。

【0020】

推定部１０２は、取得部１０１により取得された端末データに基づいて、端末２０が備える部品ごとの消耗度と、端末２０が備える部品ごとの故障率とを推定する。

【0021】

「消耗度」は、部品が消耗又は劣化している度合いを示す指標である。部品が消耗又は劣化するとは、部品が動作するものの、新品時の性能を発揮することができなくなることを言う。消耗度は、例えば０～１００％で定義され、１００％に近いほど部品が消耗又は劣化していることを意味してもよい。なお、部品がどのような状態の場合に消耗度を何％にするのかについては、部品ごとに定義が異なっていてもよい。例えばバッテリーの場合、消耗度１００％は、バッテリー容量が新品時の５０％に低下した状態であると定義してもよい。また、メモリ、プロセッサ、各種センサ及びプリント基盤など、故障する可能性はあるものの、実質、消耗や性能劣化をしないような部品については、消耗度は０％のままとするようにしてもよい。

【0022】

「故障率」は、部品が故障する可能性を示す指標である。部品が故障するとは、部品が動作しなくなることを言う。故障率は、例えば０～１００％で定義され、１００％に近いほど故障する可能性が高いことを意味してもよい。例えばタッチパネルは、タッチパネルに負荷がかかる使い方をされる端末２０ほど、故障する可能性が高い。また、内部ストレージは、空き容量が少ない状態で何度もデータの書き換えを行うような使い方をされる端末２０ほど、書き換え可能な上限に達して故障する可能性が高い。また、プロセッサは、３Ｄゲーム等の高負荷であるアプリケーションを動作させる時間が長い端末２０ほど、故障する可能性が高い。なお、メモリ、プロセッサ、各種センサ及びプリント基盤など、端末２０の使われ方と故障率との相関が低い部品については、購入時からの経過時間に応じて徐々に故障率が上昇することとしてもよい。

【0023】

判定部１０３は、推定部１０２により推定された消耗度及び故障率に基づいて、端末２０が備える部品ごとに交換を推奨するか否かを判定する。また、判定部１０３は、推定部１０２により推定された消耗度及び故障率に基づいて、端末２０が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。また、判定部１０３は、消耗度及び故障率に加えて、端末２０が備える部品の在庫状況に基づいて、端末２０が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。

【0024】

推奨部１０４は、端末データに基づいて、ユーザと端末２０との相性を示す値（以下、「相性度」と言う。）を推定し、ユーザと端末２０との相性度が所定の閾値未満である場合、ユーザに端末２０の交換を推奨する。

【0025】

また、推奨部１０４は、判定部１０３により、端末２０が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、ユーザと端末２０との相性度が所定の閾値未満である場合に、ユーザに端末２０の交換を推奨するようにしてもよい。若しくは、推奨部１０４は、判定部１０３により、端末２０が備える部品の中に交換を推奨する部品が存在すると判定され、かつ、ユーザと端末２０との相性度が所定の閾値未満である場合に、ユーザに端末２０の交換を推奨するようにしてもよい。

【0026】

表示制御部１０５は、管理装置１０が出力する各種の情報をディスプレイに表示させる。例えば、表示制御部１０５は、推定部１０２により推定された消耗度及び故障率、及び、判定部１０３により判定された交換を推奨する時期を、ディスプレイに表示させるようにしてもよい。

【0027】

収集部１０６は、複数の端末２０の各々から端末データを取得して端末データＤＢ１００ａに格納する。例えば、収集部１０６は、当該複数の端末２０から、所定周期で端末データを取得して端末データＤＢ１００ａに格納するようにしてもよいし、通信オペレータのサーバから、端末２０に関するテレメトリデータを取得するようにしてもよい。端末データＤＢ１００ａには、収集された端末データのうち最新の端末データが格納されていてもよいし、最新を含む複数の端末データが履歴として格納されていてもよい。

【0028】

また、収集部１０６は、端末２０に関する各種のサポートを受け付けるサポートセンターのサーバ等から、端末２０の症状データを取得して端末データＤＢ１００ａに格納する。

【0029】

また、収集部１０６は、端末２０に関する修理を受け付けるサポートセンターのサーバ等から、端末２０の修理実績データを取得して端末データＤＢ１００ａに格納する。

【0030】

図４は、部品管理ＤＢ１００ｂの一例を示す図である。部品管理ＤＢ１００ｂは、端末２０ごとに部品を管理しており、図４の例は、１つの端末２０に関する部品管理ＤＢ１００ｂを示している。「部品名」は端末２０を構成する各部品の名称を示す。「部品ＩＤ」は部品を一意に識別する識別子を示す。「購入時期」は、端末２０を購入した日付を示す。「交換実績」は、前回部品を交換した日付を示す。「消耗度」は、端末データに基づいて推定された消耗度を示す。「故障率」は、端末データに基づいて推定された故障率を示す。「交換推奨時期」は、消耗度及び故障率に基づいて判定された、部品の交換を推奨する時期を示す日付が格納される。特に交換の必要がない部品については“無し”が格納される。「交換状況」は、交換推奨時期までに部品交換されたか否かを示す。例えば、“Green”は、交換推奨時期が設定され、かつ、現在の日付が交換推奨時期よりも前であることを示す。“Yellow”は、交換推奨時期が設定され、かつ、現在の日付が、交換推奨時期を超過してから所定期間以内（例えば１週間など）であることを示す。“Red”は、交換推奨時期が設定され、かつ、現在の日付が、交換推奨時期を所定期間超えて超過していることを示す。

【0031】

図５は、在庫管理ＤＢ１００ｃの一例を示す図である。在庫管理ＤＢ１００ｃは、管理装置１０が管理する全端末２０の部品の在庫を管理する。「部品名」は端末２０を構成する各部品の名称を示す。「部品ＩＤ」は部品を一意に識別する識別子を示す。「部品供給状況」は、部品の在庫状況を示す。“Green”は、在庫が潤沢にあることを示す。“Yellow”は、在庫が少ないこと（又は、在庫が第１所定日数（例えば数週間等）で無くなること）を示す。“Red”は、在庫がほとんど無いこと（又は、在庫が第２所定日時（例えば数日等）で無くなること）を示す。なお、第１所定日数及び第２所定日数は、各部品で共通の日数であってもよいし、部品ごとに異なる日数であってもよい。

【0032】

以上説明した機能ブロック構成において、端末データＤＢ１００ａは、管理装置１０と通信可能な１以上の他の情報処理装置に記憶されていてもよい。取得部１０１は、当該情報処理装置に問い合わせることで、端末データを取得するようにしてもよい。また、在庫管理ＤＢ１００ｃは、管理装置１０と通信可能な１以上の他の情報処理装置に記憶されていてもよい。管理装置１０は、当該情報処理装置に問い合わせることで、部品の在庫状況を取得するようにしてもよい。

【0033】

＜処理手順＞
（交換推奨時期の判定）
図６は、交換推奨時期を判定する処理手順の一例を示すフローチャートである。管理装置１０は、図６に示す処理手順を、端末２０ごとに周期的に実行することで、部品の消耗度分析や部品の故障率予測を繰り返し行い、部品の交換推奨時期を設定又は更新する。図６の例において、ステップＳ１０１及びステップＳ１０２の処理順序は逆であってもよい。

【0034】

ステップＳ１００で、取得部１０１は、端末データＤＢ１００ａから、ユーザが利用中の端末２０に関する端末データを取得する。前述した通り、端末データには、テレメトリデータ、診断データ、症状データ、及び、修理実績データ等が含まれていてもよい。

【0035】

テレメトリデータは、端末２０から出力される端末２０の状態を示すデータである。テレメトリデータには、端末２０から出力されるデータそのものに加えて、端末２０から出力されるデータを加工又は解析することで得られるデータが含まれていてもよい。テレメトリデータには、例えば、端末ＩＤ（ＩＭＥＩ（International Mobile Equipment Identity）等）、ＯＳ（Operating System）バージョン、送受信データ量、バッテリー容量（設計値）、推定バッテリー容量、プロセッサ使用率、インストールされているアプリケーションの一覧、各アプリケーションの動作時間、アプリケーションの起動イベント及び／又は終了イベント、アプリケーションの操作ログ、アプリケーションのインストール日時、内部ストレージ全容量、内部ストレージ空き容量、通信状態に関する情報（電波状態シグナル：圏内、圏外、強弱など）、オペレーションシステムにおける各種設定値、ウェブサイトへのアクセス情報、各種イベントの発生時刻及び／又は終了時刻、位置情報、端末２０が備える各種センサ（例えば加速度センサ）による検出データ等が含まれていてもよい。

【0036】

症状データは、ユーザから申告された、端末２０の動作に対してユーザが感じる不具合を示すデータである。症状データには、タッチパネルの反応（スクロール、ピンチイン、ピンチアウトなど）が悪い、画面のスクロールが遅い、バッテリーの持ちが悪い、端末２０の動作が遅い、通信速度が遅い、音が小さいといった症状を示すデータが挙げられる。

【0037】

修理実績データは、端末２０が過去に修理された実績を示すデータである。例えば、修理実績データには、例えば、端末２０の修理箇所及び修理を行った日付を示す情報が含まれていてもよい。

【0038】

ステップＳ１０１で、推定部１０２は、端末データに基づいて、端末２０を構成する各部品の故障率を推定する。例えば、推定部１０２は、端末データを、部品の故障率を推定する学習モデルに入力し、当該学習モデルから出力される故障率を取得することで、故障率を推定する。部品の故障率を推定する学習モデルは、例えば、テレメトリデータ、症状データ及び修理実績データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。

【0039】

例えば、タッチパネルを酷使する３Ｄゲームを頻繁に利用した結果、タッチパネルに負荷がかかってタッチパネルを交換したユーザが利用する端末２０が存在し、当該端末２０のテレメトリデータには、当該３Ｄゲームを長時間動作させたことを示すデータ、プロセッサ使用率が高い時間が長いことを示すデータが含まれており、当該端末データの症状データには、タッチパネルの反応が悪いとの申告があったことを示すデータが含まれているものとする。この場合、当該端末２０のテレメトリデータ及び症状データを入力データとして故障率１００％を出力する教師データを作成することができる。同様に、修理実績データに、タッチパネルを交換した履歴が存在しない端末２０の端末データから、故障率０％を出力する教師データを作成することができる。このように、多数の端末２０から収集した端末データを用いて多数の教師データを生成し、モデルを学習させることで、タッチパネルの故障率を出力する学習モデルを生成することができる。なお、故障率を出力する学習モデルは、部品ごとに生成するようにしてもよい。

【0040】

なお、推定部１０２は、端末２０の購入時期又は前回交換した日付から経過した期間に基づいて故障率が線形に増加することを示す数式（例えば故障率＝経過期間×１０％など）を利用し、当該数式に経過期間を入力することで故障率を取得するようにしてもよい。当該数式は、部品毎に異なっていてもよい。

【0041】

また、本実施形態では、バッテリーの消耗度と故障率との間には相関関係があるとみなすようにしてもよい。例えば、推定部１０２は、バッテリーの故障率とバッテリー消耗度との相関関係を示す数式を利用し、当該数式に消耗度を入力することで故障率を取得するようにしてもよい。当該数式は、例えば、消耗度が１００％である場合の故障率は１００％とし、消耗度が８０％である場合の故障率は６０％とし、消耗度が５０％である場合の故障率は３０％とするといったものであってもよい。

【0042】

ステップＳ１０２で、推定部１０２は、端末データに基づいて、端末２０を構成する各部品の消耗度を推定する。ここで、推定部１０２は、端末データを、部品の消耗度を推定する学習モデルに入力し、当該学習モデルから出力される消耗度を取得することで、消耗度を推定する。部品の消耗度を推定する学習モデルは、例えば、テレメトリデータ及び症状データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。

【0043】

例えば、バッテリーが劣化した端末２０のテレメトリデータに、バッテリーの充電回数を示すデータが含まれており、当該端末２０の症状データには、バッテリーの持ちが悪いとの申告があったことを示すデータが含まれていると仮定する。この場合、当該端末２０のテレメトリデータを入力データとして消耗度１００％を出力する教師データを作成することができる。同様に、症状データに、バッテリーの持ちが悪いことを示すデータが含まれてない端末２０の端末データから、消耗度０％を出力する教師データを作成することができる。このように、多数の端末２０から収集した端末データを用いて多数の教師データを生成し、モデルを学習させることで、バッテリーの消耗度を出力する学習モデルを生成することができる。なお、消耗度を出力する学習モデルは、部品ごとに生成するようにしてもよい。なお、前述したように、消耗度は０％のままとする部品については、学習モデルを用意する必要はない。

【0044】

なお、端末データに、部品の消耗度を示すデータが含まれる場合、推定部１０２は、当該部品の消耗度については、端末データの値をそのまま利用して推定することとしてもよいし、端末データの値を所定の数式を用いて補正した後の値を利用して推定することとしてもよい。

【0045】

ステップＳ１０３で、判定部１０３は、推定部１０２により推定された消耗度及び故障率に基づいて、端末２０が備える部品ごとに交換を推奨するか否かを判定する。例えば、判定部１０３は、消耗度及び故障率に応じた交換推奨時期を示す判定条件データと、推定部１０２により推定された消耗度及び故障率とを比較し、消耗度及び故障率が判定条件データに合致する場合、部品交換が必要であると判定し、消耗度及び故障率が判定条件データに合致しない場合、部品交換が必要ではないと判定するようにしてもよい。

【0046】

また、判定部１０３は、消耗度及び故障率に加えて、端末２０が備える部品の在庫状況に基づいて、端末２０が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。例えば、判定部１０３は、消耗度及び故障率に応じた交換推奨時期を示す判定条件データと、推定部１０２により推定された消耗度、故障率及び部品の在庫状況とを比較し、することで、端末２０が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。

【0047】

判定部１０３は、判定した部品の交換推奨時期を、部品管理ＤＢ１００ｂの「交換推奨時期」フィールドに格納する。また、判定部１０３は、ステップＳ１０１～ステップＳ１０３の処理手順を部品ごとに実行することで、部品管理ＤＢ１００ｂの「交換推奨時期」フィールドに、判定した部品ごとの交換推奨時期を設定する。なお、判定部１０３は、判定条件データのいずれにも該当しない部品については、現時点では交換が不要であると判定し、部品管理ＤＢ１００ｂの「交換推奨時期」フィールドに「無し」を設定する。

【0048】

図７は、交換推奨時期を示す判定条件データの一例を示す図である。例えば判定番号１の判定条件は、部品ＩＤがxxxxである部品について、消耗度がａ％を超えており、かつ、故障率がｂ％を超えており、かつ部品供給状況が「Green」である場合、数か月以内に部品交換を推奨することを示す。同様に、判定番号２の判定条件は、部品ＩＤがxxxxである部品について、消耗度がａ％を超えており、かつ、故障率がｂ％を超えており、かつ部品供給状況が「Yello」である場合、数週間以内に部品交換を推奨することを示す。同様に、判定番号３の判定条件は、部品ＩＤがxxxxである部品について、消耗度がａ％を超えており、かつ、故障率がｂ％を超えており、かつ部品供給状況が「Red」である場合、数日以内に部品交換を推奨することを示す。このように、同一の部品であっても、部品供給状況によって、交換推奨時期を変化させることができる。

【0049】

また、例えば判定番号４の判定条件は、部品ＩＤがyyyyである部品について、消耗度がｃ％を超えており、かつ、故障率がｄ％を超えており、かつ部品供給状況が「Green」である場合、数週間以内に部品交換を推奨することを示す。一方、前述の通り、判定番号１の判定条件では、部品供給状況が「Green」である場合、数か月以内に部品交換を推奨することを示している。このように部品供給状況が同一であっても、部品の種類によって、交換推奨時期を変化させることができる。

【0050】

なお、判定条件データは一例に過ぎず、本実施形態に係る判定条件データはこれに限定されるものではない。例えば、図７に示す判定条件から部品供給条件を削除し、消耗度及び故障率から交換推奨時期を判定することが可能な判定条件データが用意されていてもよい。この場合、判定部１０３は、推定部１０２により推定された消耗度及び故障率と当該判定条件データを比較することで、端末２０が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。

【0051】

（交換状況の設定）
図８は、交換状況を更新する処理手順の一例を示すフローチャートである。管理装置１０は、図８に示す処理手順を、端末２０ごと及び部品ごとに周期的に実行することで、ユーザが部品を交換済みであるか否かを示す交換状況を更新する。

【0052】

ステップＳ２００で、判定部１０３は、部品管理ＤＢ１００ｂを参照し、現在の日付が交換推奨時期を超過しているか否かを判定する。現在の日付が交換推奨時期を超過している場合はステップＳ２０２に進み、超過していない場合はステップＳ２０１に進む。

【0053】

ステップＳ２０１で、判定部１０３は、部品管理ＤＢ１００ｂの「交換状況」に「Green」を設定する。

【0054】

ステップＳ２０２で、判定部１０３は、現在の日付が、交換推奨時期から所定期間経過しているか否かを判定する。現在の日付が交換推奨時期を所定期間経過している場合はステップＳ２０４に進み、超過していない場合はステップＳ２０３に進む。

【0055】

ステップＳ２０３で、判定部１０３は、部品管理ＤＢ１００ｂの「交換状況」に「Yellow」を設定する。

【0056】

ステップＳ２０４、判定部１０３は、部品管理ＤＢ１００ｂの「交換状況」に「Red」を設定する。

【0057】

（修理提案、推奨機種提案）
図９は、ユーザに修理提案又は推奨機種提案を行う際の処理手順の一例を示すフローチャートである。管理装置１０は、図９に示す処理手順を、端末２０ごとに実行することで、端末２０のユーザに対して部品の修理提案を行う。

【0058】

ステップＳ３０１で、推奨部１０４は、部品管理ＤＢ１００ｂを参照し、「交換推奨時期」に日付が設定されている部品を検索することで、修理が必要な部品の有無を判定する。交換が必要な部品が存在する場合はステップＳ３０２に進み、存在しない場合はステップＳ３０５に進む。

【0059】

ステップＳ３０２で、推奨部１０４は、端末２０を利用するユーザに対し、「交換推奨時期」に日付が設定されている部品の交換を推奨する。例えば、推奨部１０４は、端末２０に対し、交換が必要な部品の名称及び部品の交換を推奨することを示すメッセージを送信するようにしてもよい。なお、推奨部１０４は、交換が必要な部品の「交換状況」が“Yellow”である場合、端末２０に対し、「交換状況」が“Green”である場合よりも高頻度にメッセージを送信するようにしてもよい。また、推奨部１０４は、交換が必要な部品の「交換状況」が“Red”である場合、端末２０に対し、「交換状況」が“Yellow”である場合よりも高頻度にメッセージを送信するようにしてもよい。

【0060】

ステップＳ３０３で、推奨部１０４は、ユーザから部品交換をしないとの通知を受けた場合、ステップＳ３０５の処理手順に進む。部品交換を行うとの通知を受けた場合、ステップＳ３０４の処理手順に進む。

【0061】

ステップＳ３０４で、推奨部１０４は、端末２０の部品交換が行われたことの通知を修理作業者等から受けた場合、部品管理ＤＢ１００ｂを参照し、交換された部品の「交換実績」を、部品が交換された日に更新し、「交換推奨時期」を「無し」に更新し、「交換状況」を「Green」に更新する。

【0062】

ステップＳ３０５で、推定部１０２は、端末データに基づいて、端末２０を利用するユーザと、当該端末２０との相性を推定する。相性が良いと推定した場合は処理を終了し、相性が悪いと推定した場合はステップＳ３０６の処理手順に進む。

【0063】

ここで、推定部１０２は、端末データを、端末２０の相性を推定する学習モデルに入力し、当該学習モデルから出力される、ユーザと端末２０との相性度を取得することで、ユーザと端末２０の相性を推定するようにしてもよい。なお、相性度は、例えば０～１００％の範囲であり、値が大きいほどユーザと端末２０の相性がよいことを意味するものであってもよい。ユーザと端末２０の相性を推定する学習モデルは、例えば、テレメトリデータ及び症状データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。

【0064】

例えば、一定期間の間、症状データに、端末２０のレスポンスが悪い、端末２０の動作が遅いといったように、端末２０の性能に関する否定的なデータが含まれていない場合、ユーザと端末２０は相性がよい（つまりユーザは特に不満が無い）と想定される。この端末データを利用することで、当該端末２０のテレメトリデータ及び症状データを入力データとして相性度を高い値（例えば１００％など）として出力する教師データを作成することができる。

【0065】

一方、症状データに、端末２０のレスポンスが悪い、端末２０の動作が遅いといったように、端末２０の性能に関する否定的なデータが含まれており、かつ、テレメトリデータに、高いスペックが要求されるアプリケーション（３Ｄゲーム等）を高頻度に利用していることを示すデータ等が含まれる場合、ユーザと端末２０は相性が悪い（つまりユーザは端末２０のスペックに不満がある）と想定される。この端末データを利用することで、当該端末２０のテレメトリデータ及び症状データを入力データとして相性度を低い値（例えば０％など）として出力する教師データを作成することができる。

【0066】

なお、推定部１０２は、学習モデルを用いた推定に限られず、ルールベースによる相性の推定を行うようにしてもよい。例えば、推定部１０２は、テレメトリデータに、端末２０を繰り返し再起動していることを示すデータが含まれており、かつ、負荷の高いアプリケーション（３Ｄゲーム等）を高頻度に利用していることを示すデータ等が含まれる場合、ユーザは端末２０と相性が悪いと推定するルールが予め用意されていてもよい。若しくは、推定部１０２は、テレメトリデータに、負荷の高いアプリケーション（３Ｄゲーム等）を高頻度に利用していることを示すデータ等が含まれるが、端末２０を繰り返し再起動していることを示すデータが含まれていない場合、ユーザは端末２０と相性が良いと推定するようにしてもよい。また、推定部１０２は、テレメトリデータに、負荷の低いアプリケーション（メール、ウェブブラウザ等）のみを利用していることを示すデータが含まれており、かつ、端末２０のスペックがハイスペック端末である場合、ユーザは端末２０と相性が悪い（不要に高機能な端末２０を利用している）と推定するようにしてもよい。

【0067】

また、推定部１０２は、学習モデルを用いた相性の推定及びルールベースによる相性の推定の両方を行い、少なくともいずれか一方の推定結果によってユーザは端末２０と相性が悪いと推定された場合に、ユーザと端末２０の相性が悪いと推定するようにしてもよい。若しくは、推定部１０２は、学習モデルを用いた相性の推定及びルールベースによる相性の推定の両方を行い、両方の推定結果によってユーザは端末２０と相性が悪いと推定された場合に、ユーザと端末２０の相性が悪いと推定するようにしてもよい。学習モデルとルールベースを組み合わせることで、推定精度を向上させることが可能になる。

【0068】

ステップＳ３０６で、推奨部１０４は、端末２０を利用するユーザに対し、端末２０の交換を推奨する。例えば、推奨部１０４は、ユーザの端末２０に対し、他の機種の端末２０を推奨することを示すメッセージを送信するようにしてもよい。当該メッセージには、交換を推奨する機種名が含まれていてもよい。交換を推奨する機種のスペックについては、相性を推定する学習済みモデルから出力されるようにしてもよいし、若しくは、ルールベースで判断されてもよい。

【0069】

以上説明した処理手順において、ステップＳ３０５及びステップＳ３０６の処理手順は、部品の交換が不要又は部品の交換が不可能である場合に実行されるようにしたが、これに限定されるものではない。例えば、推定部１０２は、ステップＳ３０５及びステップＳ３０６の処理手順ステップＳ３０２の処理手順の前に実行し、端末２０とユーザの相性が悪い場合は、部品交換を推奨することに代えて、端末２０の交換を推奨することを示すメッセージを送信するようにしてもよい。

【0070】

（端末２０のグレード判定）
判定部１０３は、ステップＳ３０２の処理手順において、部品交換が必要な端末２０を、複数のグレードにランク付けするようにしてもよい。例えば、交換が必要な部品の数及び／又は部品の内容に応じて、端末２０を複数のグレードにランク付けするようにしてもよい。具体的には、バッテリー交換のみである場合はグレードＡ、ディスプレイ交換が必要な端末２０はグレードＢ、メモリ及びセンサ等など、交換の難易度が高い部品の交換が必要な端末２０はグレードＣのように判定するようにしてもよい。例えば、ユーザから、部品交換をせずに下取りに出したいとの申し出を受けた場合に、端末２０を予めランク付けしておくことで、中古市場などに流通させる際に、端末２０の円滑な流通を実現することができる。

【0071】

＜まとめ＞
以上説明した実施形態によれば、管理装置１０は、端末２０を構成する各部品の交換要否を推定し、部品交換が必要である場合はユーザに通知するようにした。これにより、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することが可能になる。

【0072】

また、管理装置１０は、部品の消耗度と故障率の両方を用いて部品交換の要否及び交換推奨時期を判定するようにした。部品には、徐々に消耗していくことで本来の性能を発揮できなくなる部品と、消耗はしないが突然故障する部品とが存在する。したがって、部品の消耗度と故障率の両方を用いて部品交換の要否等を判定することで、部品の消耗度及び故障率のうち一方のみを利用する場合と比較して、判定精度を向上させることが可能になる。

【0073】

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。

【符号の説明】

【0074】

１…管理システム、１０…管理装置、１１…プロセッサ、１２…記憶装置、１３…通信ＩＦ、１４…入力デバイス、１５…出力デバイス、２０…端末、１００…記憶部、１００ａ…端末データＤＢ、１００ｂ…部品管理ＤＢ、１００ｃ…在庫管理ＤＢ、１０１…取得部、１０２…推定部、１０３…判定部、１０４…推奨部、１０５…表示制御部、１０６…収集部

【要約】

【課題】部品に不具合が生じる前に交換を推奨することを可能とする技術を提供すること。
【解決手段】ユーザが利用中の端末に関する端末データを取得する取得部と、前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定する推定部と、前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定する判定部と、を有する情報処理装置を提供する。
【選択図】図３

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】