JP7515682B1 - 情報処理装置、情報処理方法及びプログラム - Google Patents
情報処理装置、情報処理方法及びプログラム Download PDFInfo
- Publication number
- JP7515682B1 JP7515682B1 JP2023201501A JP2023201501A JP7515682B1 JP 7515682 B1 JP7515682 B1 JP 7515682B1 JP 2023201501 A JP2023201501 A JP 2023201501A JP 2023201501 A JP2023201501 A JP 2023201501A JP 7515682 B1 JP7515682 B1 JP 7515682B1
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- user
- data
- replacement
- failure rate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 16
- 238000003672 processing method Methods 0.000 title claims description 3
- 238000000034 method Methods 0.000 claims description 29
- 230000008439 repair process Effects 0.000 claims description 23
- 238000005516 engineering process Methods 0.000 abstract description 4
- 230000007547 defect Effects 0.000 abstract description 2
- 238000007726 management method Methods 0.000 description 54
- 208000024891 symptom Diseases 0.000 description 21
- 238000012545 processing Methods 0.000 description 15
- 238000010586 diagram Methods 0.000 description 12
- 238000012549 training Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 7
- 230000007257 malfunction Effects 0.000 description 6
- 230000004044 response Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 2
- 208000032953 Device battery issue Diseases 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Abstract
Description
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
携帯端末の契約、販売及び故障対応を行う店舗には、使用中の携帯端末に不具合があると訴えるユーザが来店する。不具合を訴えるユーザが来店した場合、店員は、ユーザから不具合の内容をヒアリングし、専用のテスタに接続することで故障有無の診断を行い、診断結果に応じて修理及び端末交換を行う。なお、特許文献1には、携帯端末の不具合を診断する技術が開示されている。
上述の通り、現状の故障対応は、ユーザの申告を受けてから行われることが一般的である。しかしながら、申告を受けてから修理又は交換を行う場合、ユーザの要望等により、部分的な部品交換で済むにも関わらず、端末ごと交換を行うなどの過剰な対応が行われる可能性がある。
そこで、本発明は、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することを目的とする。
本発明の一態様に係る情報処理装置は、ユーザが利用中の端末に関する端末データを取得する取得部と、前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定する推定部と、前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定する判定部と、を有する。
本発明によれば、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することができる。
添付図面を参照して、本発明の実施形態について説明する。各図において、同一の符号を付したものは、同一又は同様の構成を有する。
<システム構成>
図1は、本実施形態に係る管理システム1の一例を示す図である。管理システム1は、管理装置10と、1以上の端末20とを含む。管理装置10と端末20は、無線通信ネットワークを介して接続され、相互に通信を行うことができる。
図1は、本実施形態に係る管理システム1の一例を示す図である。管理システム1は、管理装置10と、1以上の端末20とを含む。管理装置10と端末20は、無線通信ネットワークを介して接続され、相互に通信を行うことができる。
管理装置10は、ユーザが利用する端末20を管理する装置である。管理装置10は、1又は複数の物理的なサーバ等から構成されていてもよいし、ハイパーバイザー(hypervisor)上で動作する仮想的なサーバを用いて構成されていてもよいし、クラウドサーバを用いて構成されていてもよい。
端末20は、スマートフォン、タブレット端末、携帯電話機、パーソナルコンピュータ(PC)、ノートPC、携帯情報端末(PDA)、家庭用ゲーム機器など、ユーザが利用する端末であれば、どのような端末であってもよい。
管理装置10は、ユーザが利用する端末20を構成する部品ごとに部品状態を管理するとともに、端末20の端末データに基づいて、将来不具合が発生することが予想される部品の有無等を推定する。また、管理装置10は、将来不具合が発生することが予想される部品が存在する場合、不具合が生じる前に、ユーザに対し部品交換を推奨する。ここで、端末データは、端末20に関連するデータであり、例えば、テレメトリデータ、診断データ、症状データ、及び、修理実績データ等を含む。テレメトリデータ、診断データ、症状データ、及び、修理実績データの具体例等については後述する。なお、テレメトリデータ、診断データ、症状データ、及び、修理実績データは端末データの一例に過ぎない。端末データには、テレメトリデータ、症状データ、及び、修理実績データの全部が含まれていてもよいし、一部のデータが含まれていなくてもよいし、更に他のデータが含まれていてもよい。
また、管理装置10は、端末20と、当該端末20を利用するユーザとの相性を推定し、推定結果に応じて端末20の買い替えを推奨するようにしてもよい。例えば、主にメール及びWebブラウジングを行うユーザが、3次元ゲームを円滑にプレイ可能な端末20を所持しているなど、ユーザの利用形態と端末20のスペックが不一致であるユーザに対し、端末20の部品交換に代えて端末20の買い替えを推奨することが考えらえる。
また、管理装置10は、部品状態を管理する端末20に対し、端末20の品質を示す複数のグレードにランク付けするようにしてもよい。例えば、ユーザから端末20を買い取り又は下取り等を行い、中古市場に流通させる際に、端末20の品質をランク付けすることで端末20の円滑な流通を実現することができる。
<ハードウェア構成>
図2は、管理装置10のハードウェア構成例を示す図である。管理装置10は、CPU(Central Processing Unit)、GPU(Graphical Processing Unit)等のプロセッサ11、メモリ、HDD(Hard Disk Drive)及び/又はSSD(Solid State Drive)等の記憶装置12、有線又は無線通信を行う通信IF(Interface)13、入力操作を受け付ける入力デバイス14、及び情報の出力を行う出力デバイス15を有する。入力デバイス14は、例えば、キーボード、タッチパネル、マウス及び/又はマイク等である。出力デバイス15は、例えば、ディスプレイ、タッチパネル及び/又はスピーカ等である。
図2は、管理装置10のハードウェア構成例を示す図である。管理装置10は、CPU(Central Processing Unit)、GPU(Graphical Processing Unit)等のプロセッサ11、メモリ、HDD(Hard Disk Drive)及び/又はSSD(Solid State Drive)等の記憶装置12、有線又は無線通信を行う通信IF(Interface)13、入力操作を受け付ける入力デバイス14、及び情報の出力を行う出力デバイス15を有する。入力デバイス14は、例えば、キーボード、タッチパネル、マウス及び/又はマイク等である。出力デバイス15は、例えば、ディスプレイ、タッチパネル及び/又はスピーカ等である。
<機能ブロック構成>
図3は、管理装置10の機能ブロック構成例を示す図である。管理装置10は、記憶部100と、取得部101と、推定部102と、判定部103と、推奨部104と、表示制御部105と、収集部106とを含む。記憶部100は、管理装置10が備える記憶装置12を用いて実現することができる。また、取得部101と、推定部102と、判定部103と、推奨部104と、表示制御部105と、収集部106とは、管理装置10のプロセッサ11が、記憶装置12に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体(Non-transitory computer readable medium)であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、USBメモリ又はCD-ROM等の記憶媒体であってもよい。
図3は、管理装置10の機能ブロック構成例を示す図である。管理装置10は、記憶部100と、取得部101と、推定部102と、判定部103と、推奨部104と、表示制御部105と、収集部106とを含む。記憶部100は、管理装置10が備える記憶装置12を用いて実現することができる。また、取得部101と、推定部102と、判定部103と、推奨部104と、表示制御部105と、収集部106とは、管理装置10のプロセッサ11が、記憶装置12に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体(Non-transitory computer readable medium)であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、USBメモリ又はCD-ROM等の記憶媒体であってもよい。
記憶部100は、端末データDB100aと、部品管理DB100bと、在庫管理DB100cとを記憶する。端末データDB100aは、取得部101によって端末20から取得された端末データを格納するDB(DataBase)である。部品管理DB100bは、端末20を構成する各種の部品について、部品ごとの交換実績、交換推奨時期等を管理するDBである。在庫管理DB100cは、端末20を構成する各種の部品について、部品ごとの在庫状況を管理するDBである。
取得部101は、ユーザが利用中の端末20に関する端末データを取得する。例えば、当該端末データには、少なくとも端末20から取得したテレメトリデータ、端末20の過去の修理実績データが含まれていてもよい。
推定部102は、取得部101により取得された端末データに基づいて、端末20が備える部品ごとの消耗度と、端末20が備える部品ごとの故障率とを推定する。
「消耗度」は、部品が消耗又は劣化している度合いを示す指標である。部品が消耗又は劣化するとは、部品が動作するものの、新品時の性能を発揮することができなくなることを言う。消耗度は、例えば0~100%で定義され、100%に近いほど部品が消耗又は劣化していることを意味してもよい。なお、部品がどのような状態の場合に消耗度を何%にするのかについては、部品ごとに定義が異なっていてもよい。例えばバッテリーの場合、消耗度100%は、バッテリー容量が新品時の50%に低下した状態であると定義してもよい。また、メモリ、プロセッサ、各種センサ及びプリント基盤など、故障する可能性はあるものの、実質、消耗や性能劣化をしないような部品については、消耗度は0%のままとするようにしてもよい。
「故障率」は、部品が故障する可能性を示す指標である。部品が故障するとは、部品が動作しなくなることを言う。故障率は、例えば0~100%で定義され、100%に近いほど故障する可能性が高いことを意味してもよい。例えばタッチパネルは、タッチパネルに負荷がかかる使い方をされる端末20ほど、故障する可能性が高い。また、内部ストレージは、空き容量が少ない状態で何度もデータの書き換えを行うような使い方をされる端末20ほど、書き換え可能な上限に達して故障する可能性が高い。また、プロセッサは、3Dゲーム等の高負荷であるアプリケーションを動作させる時間が長い端末20ほど、故障する可能性が高い。なお、メモリ、プロセッサ、各種センサ及びプリント基盤など、端末20の使われ方と故障率との相関が低い部品については、購入時からの経過時間に応じて徐々に故障率が上昇することとしてもよい。
判定部103は、推定部102により推定された消耗度及び故障率に基づいて、端末20が備える部品ごとに交換を推奨するか否かを判定する。また、判定部103は、推定部102により推定された消耗度及び故障率に基づいて、端末20が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。また、判定部103は、消耗度及び故障率に加えて、端末20が備える部品の在庫状況に基づいて、端末20が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。
推奨部104は、端末データに基づいて、ユーザと端末20との相性を示す値(以下、「相性度」と言う。)を推定し、ユーザと端末20との相性度が所定の閾値未満である場合、ユーザに端末20の交換を推奨する。
また、推奨部104は、判定部103により、端末20が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、ユーザと端末20との相性度が所定の閾値未満である場合に、ユーザに端末20の交換を推奨するようにしてもよい。若しくは、推奨部104は、判定部103により、端末20が備える部品の中に交換を推奨する部品が存在すると判定され、かつ、ユーザと端末20との相性度が所定の閾値未満である場合に、ユーザに端末20の交換を推奨するようにしてもよい。
表示制御部105は、管理装置10が出力する各種の情報をディスプレイに表示させる。例えば、表示制御部105は、推定部102により推定された消耗度及び故障率、及び、判定部103により判定された交換を推奨する時期を、ディスプレイに表示させるようにしてもよい。
収集部106は、複数の端末20の各々から端末データを取得して端末データDB100aに格納する。例えば、収集部106は、当該複数の端末20から、所定周期で端末データを取得して端末データDB100aに格納するようにしてもよいし、通信オペレータのサーバから、端末20に関するテレメトリデータを取得するようにしてもよい。端末データDB100aには、収集された端末データのうち最新の端末データが格納されていてもよいし、最新を含む複数の端末データが履歴として格納されていてもよい。
また、収集部106は、端末20に関する各種のサポートを受け付けるサポートセンターのサーバ等から、端末20の症状データを取得して端末データDB100aに格納する。
また、収集部106は、端末20に関する修理を受け付けるサポートセンターのサーバ等から、端末20の修理実績データを取得して端末データDB100aに格納する。
図4は、部品管理DB100bの一例を示す図である。部品管理DB100bは、端末20ごとに部品を管理しており、図4の例は、1つの端末20に関する部品管理DB100bを示している。「部品名」は端末20を構成する各部品の名称を示す。「部品ID」は部品を一意に識別する識別子を示す。「購入時期」は、端末20を購入した日付を示す。「交換実績」は、前回部品を交換した日付を示す。「消耗度」は、端末データに基づいて推定された消耗度を示す。「故障率」は、端末データに基づいて推定された故障率を示す。「交換推奨時期」は、消耗度及び故障率に基づいて判定された、部品の交換を推奨する時期を示す日付が格納される。特に交換の必要がない部品については“無し”が格納される。「交換状況」は、交換推奨時期までに部品交換されたか否かを示す。例えば、“Green”は、交換推奨時期が設定され、かつ、現在の日付が交換推奨時期よりも前であることを示す。“Yellow”は、交換推奨時期が設定され、かつ、現在の日付が、交換推奨時期を超過してから所定期間以内(例えば1週間など)であることを示す。“Red”は、交換推奨時期が設定され、かつ、現在の日付が、交換推奨時期を所定期間超えて超過していることを示す。
図5は、在庫管理DB100cの一例を示す図である。在庫管理DB100cは、管理装置10が管理する全端末20の部品の在庫を管理する。「部品名」は端末20を構成する各部品の名称を示す。「部品ID」は部品を一意に識別する識別子を示す。「部品供給状況」は、部品の在庫状況を示す。“Green”は、在庫が潤沢にあることを示す。“Yellow”は、在庫が少ないこと(又は、在庫が第1所定日数(例えば数週間等)で無くなること)を示す。“Red”は、在庫がほとんど無いこと(又は、在庫が第2所定日時(例えば数日等)で無くなること)を示す。なお、第1所定日数及び第2所定日数は、各部品で共通の日数であってもよいし、部品ごとに異なる日数であってもよい。
以上説明した機能ブロック構成において、端末データDB100aは、管理装置10と通信可能な1以上の他の情報処理装置に記憶されていてもよい。取得部101は、当該情報処理装置に問い合わせることで、端末データを取得するようにしてもよい。また、在庫管理DB100cは、管理装置10と通信可能な1以上の他の情報処理装置に記憶されていてもよい。管理装置10は、当該情報処理装置に問い合わせることで、部品の在庫状況を取得するようにしてもよい。
<処理手順>
(交換推奨時期の判定)
図6は、交換推奨時期を判定する処理手順の一例を示すフローチャートである。管理装置10は、図6に示す処理手順を、端末20ごとに周期的に実行することで、部品の消耗度分析や部品の故障率予測を繰り返し行い、部品の交換推奨時期を設定又は更新する。図6の例において、ステップS101及びステップS102の処理順序は逆であってもよい。
(交換推奨時期の判定)
図6は、交換推奨時期を判定する処理手順の一例を示すフローチャートである。管理装置10は、図6に示す処理手順を、端末20ごとに周期的に実行することで、部品の消耗度分析や部品の故障率予測を繰り返し行い、部品の交換推奨時期を設定又は更新する。図6の例において、ステップS101及びステップS102の処理順序は逆であってもよい。
ステップS100で、取得部101は、端末データDB100aから、ユーザが利用中の端末20に関する端末データを取得する。前述した通り、端末データには、テレメトリデータ、診断データ、症状データ、及び、修理実績データ等が含まれていてもよい。
テレメトリデータは、端末20から出力される端末20の状態を示すデータである。テレメトリデータには、端末20から出力されるデータそのものに加えて、端末20から出力されるデータを加工又は解析することで得られるデータが含まれていてもよい。テレメトリデータには、例えば、端末ID(IMEI(International Mobile Equipment Identity)等)、OS(Operating System)バージョン、送受信データ量、バッテリー容量(設計値)、推定バッテリー容量、プロセッサ使用率、インストールされているアプリケーションの一覧、各アプリケーションの動作時間、アプリケーションの起動イベント及び/又は終了イベント、アプリケーションの操作ログ、アプリケーションのインストール日時、内部ストレージ全容量、内部ストレージ空き容量、通信状態に関する情報(電波状態シグナル:圏内、圏外、強弱など)、オペレーションシステムにおける各種設定値、ウェブサイトへのアクセス情報、各種イベントの発生時刻及び/又は終了時刻、位置情報、端末20が備える各種センサ(例えば加速度センサ)による検出データ等が含まれていてもよい。
症状データは、ユーザから申告された、端末20の動作に対してユーザが感じる不具合を示すデータである。症状データには、タッチパネルの反応(スクロール、ピンチイン、ピンチアウトなど)が悪い、画面のスクロールが遅い、バッテリーの持ちが悪い、端末20の動作が遅い、通信速度が遅い、音が小さいといった症状を示すデータが挙げられる。
修理実績データは、端末20が過去に修理された実績を示すデータである。例えば、修理実績データには、例えば、端末20の修理箇所及び修理を行った日付を示す情報が含まれていてもよい。
ステップS101で、推定部102は、端末データに基づいて、端末20を構成する各部品の故障率を推定する。例えば、推定部102は、端末データを、部品の故障率を推定する学習モデルに入力し、当該学習モデルから出力される故障率を取得することで、故障率を推定する。部品の故障率を推定する学習モデルは、例えば、テレメトリデータ、症状データ及び修理実績データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。
例えば、タッチパネルを酷使する3Dゲームを頻繁に利用した結果、タッチパネルに負荷がかかってタッチパネルを交換したユーザが利用する端末20が存在し、当該端末20のテレメトリデータには、当該3Dゲームを長時間動作させたことを示すデータ、プロセッサ使用率が高い時間が長いことを示すデータが含まれており、当該端末データの症状データには、タッチパネルの反応が悪いとの申告があったことを示すデータが含まれているものとする。この場合、当該端末20のテレメトリデータ及び症状データを入力データとして故障率100%を出力する教師データを作成することができる。同様に、修理実績データに、タッチパネルを交換した履歴が存在しない端末20の端末データから、故障率0%を出力する教師データを作成することができる。このように、多数の端末20から収集した端末データを用いて多数の教師データを生成し、モデルを学習させることで、タッチパネルの故障率を出力する学習モデルを生成することができる。なお、故障率を出力する学習モデルは、部品ごとに生成するようにしてもよい。
なお、推定部102は、端末20の購入時期又は前回交換した日付から経過した期間に基づいて故障率が線形に増加することを示す数式(例えば故障率=経過期間×10%など)を利用し、当該数式に経過期間を入力することで故障率を取得するようにしてもよい。当該数式は、部品毎に異なっていてもよい。
また、本実施形態では、バッテリーの消耗度と故障率との間には相関関係があるとみなすようにしてもよい。例えば、推定部102は、バッテリーの故障率とバッテリー消耗度との相関関係を示す数式を利用し、当該数式に消耗度を入力することで故障率を取得するようにしてもよい。当該数式は、例えば、消耗度が100%である場合の故障率は100%とし、消耗度が80%である場合の故障率は60%とし、消耗度が50%である場合の故障率は30%とするといったものであってもよい。
ステップS102で、推定部102は、端末データに基づいて、端末20を構成する各部品の消耗度を推定する。ここで、推定部102は、端末データを、部品の消耗度を推定する学習モデルに入力し、当該学習モデルから出力される消耗度を取得することで、消耗度を推定する。部品の消耗度を推定する学習モデルは、例えば、テレメトリデータ及び症状データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。
例えば、バッテリーが劣化した端末20のテレメトリデータに、バッテリーの充電回数を示すデータが含まれており、当該端末20の症状データには、バッテリーの持ちが悪いとの申告があったことを示すデータが含まれていると仮定する。この場合、当該端末20のテレメトリデータを入力データとして消耗度100%を出力する教師データを作成することができる。同様に、症状データに、バッテリーの持ちが悪いことを示すデータが含まれてない端末20の端末データから、消耗度0%を出力する教師データを作成することができる。このように、多数の端末20から収集した端末データを用いて多数の教師データを生成し、モデルを学習させることで、バッテリーの消耗度を出力する学習モデルを生成することができる。なお、消耗度を出力する学習モデルは、部品ごとに生成するようにしてもよい。なお、前述したように、消耗度は0%のままとする部品については、学習モデルを用意する必要はない。
なお、端末データに、部品の消耗度を示すデータが含まれる場合、推定部102は、当該部品の消耗度については、端末データの値をそのまま利用して推定することとしてもよいし、端末データの値を所定の数式を用いて補正した後の値を利用して推定することとしてもよい。
ステップS103で、判定部103は、推定部102により推定された消耗度及び故障率に基づいて、端末20が備える部品ごとに交換を推奨するか否かを判定する。例えば、判定部103は、消耗度及び故障率に応じた交換推奨時期を示す判定条件データと、推定部102により推定された消耗度及び故障率とを比較し、消耗度及び故障率が判定条件データに合致する場合、部品交換が必要であると判定し、消耗度及び故障率が判定条件データに合致しない場合、部品交換が必要ではないと判定するようにしてもよい。
また、判定部103は、消耗度及び故障率に加えて、端末20が備える部品の在庫状況に基づいて、端末20が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。例えば、判定部103は、消耗度及び故障率に応じた交換推奨時期を示す判定条件データと、推定部102により推定された消耗度、故障率及び部品の在庫状況とを比較し、することで、端末20が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。
判定部103は、判定した部品の交換推奨時期を、部品管理DB100bの「交換推奨時期」フィールドに格納する。また、判定部103は、ステップS101~ステップS103の処理手順を部品ごとに実行することで、部品管理DB100bの「交換推奨時期」フィールドに、判定した部品ごとの交換推奨時期を設定する。なお、判定部103は、判定条件データのいずれにも該当しない部品については、現時点では交換が不要であると判定し、部品管理DB100bの「交換推奨時期」フィールドに「無し」を設定する。
図7は、交換推奨時期を示す判定条件データの一例を示す図である。例えば判定番号1の判定条件は、部品IDがxxxxである部品について、消耗度がa%を超えており、かつ、故障率がb%を超えており、かつ部品供給状況が「Green」である場合、数か月以内に部品交換を推奨することを示す。同様に、判定番号2の判定条件は、部品IDがxxxxである部品について、消耗度がa%を超えており、かつ、故障率がb%を超えており、かつ部品供給状況が「Yello」である場合、数週間以内に部品交換を推奨することを示す。同様に、判定番号3の判定条件は、部品IDがxxxxである部品について、消耗度がa%を超えており、かつ、故障率がb%を超えており、かつ部品供給状況が「Red」である場合、数日以内に部品交換を推奨することを示す。このように、同一の部品であっても、部品供給状況によって、交換推奨時期を変化させることができる。
また、例えば判定番号4の判定条件は、部品IDがyyyyである部品について、消耗度がc%を超えており、かつ、故障率がd%を超えており、かつ部品供給状況が「Green」である場合、数週間以内に部品交換を推奨することを示す。一方、前述の通り、判定番号1の判定条件では、部品供給状況が「Green」である場合、数か月以内に部品交換を推奨することを示している。このように部品供給状況が同一であっても、部品の種類によって、交換推奨時期を変化させることができる。
なお、判定条件データは一例に過ぎず、本実施形態に係る判定条件データはこれに限定されるものではない。例えば、図7に示す判定条件から部品供給条件を削除し、消耗度及び故障率から交換推奨時期を判定することが可能な判定条件データが用意されていてもよい。この場合、判定部103は、推定部102により推定された消耗度及び故障率と当該判定条件データを比較することで、端末20が備える部品ごとに交換を推奨する時期を判定するようにしてもよい。
(交換状況の設定)
図8は、交換状況を更新する処理手順の一例を示すフローチャートである。管理装置10は、図8に示す処理手順を、端末20ごと及び部品ごとに周期的に実行することで、ユーザが部品を交換済みであるか否かを示す交換状況を更新する。
図8は、交換状況を更新する処理手順の一例を示すフローチャートである。管理装置10は、図8に示す処理手順を、端末20ごと及び部品ごとに周期的に実行することで、ユーザが部品を交換済みであるか否かを示す交換状況を更新する。
ステップS200で、判定部103は、部品管理DB100bを参照し、現在の日付が交換推奨時期を超過しているか否かを判定する。現在の日付が交換推奨時期を超過している場合はステップS202に進み、超過していない場合はステップS201に進む。
ステップS201で、判定部103は、部品管理DB100bの「交換状況」に「Green」を設定する。
ステップS202で、判定部103は、現在の日付が、交換推奨時期から所定期間経過しているか否かを判定する。現在の日付が交換推奨時期を所定期間経過している場合はステップS204に進み、超過していない場合はステップS203に進む。
ステップS203で、判定部103は、部品管理DB100bの「交換状況」に「Yellow」を設定する。
ステップS204、判定部103は、部品管理DB100bの「交換状況」に「Red」を設定する。
(修理提案、推奨機種提案)
図9は、ユーザに修理提案又は推奨機種提案を行う際の処理手順の一例を示すフローチャートである。管理装置10は、図9に示す処理手順を、端末20ごとに実行することで、端末20のユーザに対して部品の修理提案を行う。
図9は、ユーザに修理提案又は推奨機種提案を行う際の処理手順の一例を示すフローチャートである。管理装置10は、図9に示す処理手順を、端末20ごとに実行することで、端末20のユーザに対して部品の修理提案を行う。
ステップS301で、推奨部104は、部品管理DB100bを参照し、「交換推奨時期」に日付が設定されている部品を検索することで、修理が必要な部品の有無を判定する。交換が必要な部品が存在する場合はステップS302に進み、存在しない場合はステップS305に進む。
ステップS302で、推奨部104は、端末20を利用するユーザに対し、「交換推奨時期」に日付が設定されている部品の交換を推奨する。例えば、推奨部104は、端末20に対し、交換が必要な部品の名称及び部品の交換を推奨することを示すメッセージを送信するようにしてもよい。なお、推奨部104は、交換が必要な部品の「交換状況」が“Yellow”である場合、端末20に対し、「交換状況」が“Green”である場合よりも高頻度にメッセージを送信するようにしてもよい。また、推奨部104は、交換が必要な部品の「交換状況」が“Red”である場合、端末20に対し、「交換状況」が“Yellow”である場合よりも高頻度にメッセージを送信するようにしてもよい。
ステップS303で、推奨部104は、ユーザから部品交換をしないとの通知を受けた場合、ステップS305の処理手順に進む。部品交換を行うとの通知を受けた場合、ステップS304の処理手順に進む。
ステップS304で、推奨部104は、端末20の部品交換が行われたことの通知を修理作業者等から受けた場合、部品管理DB100bを参照し、交換された部品の「交換実績」を、部品が交換された日に更新し、「交換推奨時期」を「無し」に更新し、「交換状況」を「Green」に更新する。
ステップS305で、推定部102は、端末データに基づいて、端末20を利用するユーザと、当該端末20との相性を推定する。相性が良いと推定した場合は処理を終了し、相性が悪いと推定した場合はステップS306の処理手順に進む。
ここで、推定部102は、端末データを、端末20の相性を推定する学習モデルに入力し、当該学習モデルから出力される、ユーザと端末20との相性度を取得することで、ユーザと端末20の相性を推定するようにしてもよい。なお、相性度は、例えば0~100%の範囲であり、値が大きいほどユーザと端末20の相性がよいことを意味するものであってもよい。ユーザと端末20の相性を推定する学習モデルは、例えば、テレメトリデータ及び症状データを用いて教師データを生成し、生成した教師データを用いてモデルを学習させることで生成することができる。
例えば、一定期間の間、症状データに、端末20のレスポンスが悪い、端末20の動作が遅いといったように、端末20の性能に関する否定的なデータが含まれていない場合、ユーザと端末20は相性がよい(つまりユーザは特に不満が無い)と想定される。この端末データを利用することで、当該端末20のテレメトリデータ及び症状データを入力データとして相性度を高い値(例えば100%など)として出力する教師データを作成することができる。
一方、症状データに、端末20のレスポンスが悪い、端末20の動作が遅いといったように、端末20の性能に関する否定的なデータが含まれており、かつ、テレメトリデータに、高いスペックが要求されるアプリケーション(3Dゲーム等)を高頻度に利用していることを示すデータ等が含まれる場合、ユーザと端末20は相性が悪い(つまりユーザは端末20のスペックに不満がある)と想定される。この端末データを利用することで、当該端末20のテレメトリデータ及び症状データを入力データとして相性度を低い値(例えば0%など)として出力する教師データを作成することができる。
なお、推定部102は、学習モデルを用いた推定に限られず、ルールベースによる相性の推定を行うようにしてもよい。例えば、推定部102は、テレメトリデータに、端末20を繰り返し再起動していることを示すデータが含まれており、かつ、負荷の高いアプリケーション(3Dゲーム等)を高頻度に利用していることを示すデータ等が含まれる場合、ユーザは端末20と相性が悪いと推定するルールが予め用意されていてもよい。若しくは、推定部102は、テレメトリデータに、負荷の高いアプリケーション(3Dゲーム等)を高頻度に利用していることを示すデータ等が含まれるが、端末20を繰り返し再起動していることを示すデータが含まれていない場合、ユーザは端末20と相性が良いと推定するようにしてもよい。また、推定部102は、テレメトリデータに、負荷の低いアプリケーション(メール、ウェブブラウザ等)のみを利用していることを示すデータが含まれており、かつ、端末20のスペックがハイスペック端末である場合、ユーザは端末20と相性が悪い(不要に高機能な端末20を利用している)と推定するようにしてもよい。
また、推定部102は、学習モデルを用いた相性の推定及びルールベースによる相性の推定の両方を行い、少なくともいずれか一方の推定結果によってユーザは端末20と相性が悪いと推定された場合に、ユーザと端末20の相性が悪いと推定するようにしてもよい。若しくは、推定部102は、学習モデルを用いた相性の推定及びルールベースによる相性の推定の両方を行い、両方の推定結果によってユーザは端末20と相性が悪いと推定された場合に、ユーザと端末20の相性が悪いと推定するようにしてもよい。学習モデルとルールベースを組み合わせることで、推定精度を向上させることが可能になる。
ステップS306で、推奨部104は、端末20を利用するユーザに対し、端末20の交換を推奨する。例えば、推奨部104は、ユーザの端末20に対し、他の機種の端末20を推奨することを示すメッセージを送信するようにしてもよい。当該メッセージには、交換を推奨する機種名が含まれていてもよい。交換を推奨する機種のスペックについては、相性を推定する学習済みモデルから出力されるようにしてもよいし、若しくは、ルールベースで判断されてもよい。
以上説明した処理手順において、ステップS305及びステップS306の処理手順は、部品の交換が不要又は部品の交換が不可能である場合に実行されるようにしたが、これに限定されるものではない。例えば、推定部102は、ステップS305及びステップS306の処理手順ステップS302の処理手順の前に実行し、端末20とユーザの相性が悪い場合は、部品交換を推奨することに代えて、端末20の交換を推奨することを示すメッセージを送信するようにしてもよい。
(端末20のグレード判定)
判定部103は、ステップS302の処理手順において、部品交換が必要な端末20を、複数のグレードにランク付けするようにしてもよい。例えば、交換が必要な部品の数及び/又は部品の内容に応じて、端末20を複数のグレードにランク付けするようにしてもよい。具体的には、バッテリー交換のみである場合はグレードA、ディスプレイ交換が必要な端末20はグレードB、メモリ及びセンサ等など、交換の難易度が高い部品の交換が必要な端末20はグレードCのように判定するようにしてもよい。例えば、ユーザから、部品交換をせずに下取りに出したいとの申し出を受けた場合に、端末20を予めランク付けしておくことで、中古市場などに流通させる際に、端末20の円滑な流通を実現することができる。
判定部103は、ステップS302の処理手順において、部品交換が必要な端末20を、複数のグレードにランク付けするようにしてもよい。例えば、交換が必要な部品の数及び/又は部品の内容に応じて、端末20を複数のグレードにランク付けするようにしてもよい。具体的には、バッテリー交換のみである場合はグレードA、ディスプレイ交換が必要な端末20はグレードB、メモリ及びセンサ等など、交換の難易度が高い部品の交換が必要な端末20はグレードCのように判定するようにしてもよい。例えば、ユーザから、部品交換をせずに下取りに出したいとの申し出を受けた場合に、端末20を予めランク付けしておくことで、中古市場などに流通させる際に、端末20の円滑な流通を実現することができる。
<まとめ>
以上説明した実施形態によれば、管理装置10は、端末20を構成する各部品の交換要否を推定し、部品交換が必要である場合はユーザに通知するようにした。これにより、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することが可能になる。
以上説明した実施形態によれば、管理装置10は、端末20を構成する各部品の交換要否を推定し、部品交換が必要である場合はユーザに通知するようにした。これにより、部品に不具合が生じる前に交換を推奨することを可能とする技術を提供することが可能になる。
また、管理装置10は、部品の消耗度と故障率の両方を用いて部品交換の要否及び交換推奨時期を判定するようにした。部品には、徐々に消耗していくことで本来の性能を発揮できなくなる部品と、消耗はしないが突然故障する部品とが存在する。したがって、部品の消耗度と故障率の両方を用いて部品交換の要否等を判定することで、部品の消耗度及び故障率のうち一方のみを利用する場合と比較して、判定精度を向上させることが可能になる。
以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。
1…管理システム、10…管理装置、11…プロセッサ、12…記憶装置、13…通信IF、14…入力デバイス、15…出力デバイス、20…端末、100…記憶部、100a…端末データDB、100b…部品管理DB、100c…在庫管理DB、101…取得部、102…推定部、103…判定部、104…推奨部、105…表示制御部、106…収集部
Claims (6)
- ユーザが利用中の端末に関する端末データを取得する取得部と、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定する推定部と、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定する判定部と、
を有し、
前記推定部は、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨する推奨部、を有し、
前記推奨部は、前記判定部により、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
情報処理装置。 - 前記判定部は、前記消耗度及び前記故障率に加えて、前記端末が備える部品の在庫状況に基づいて、更に、前記端末が備える部品ごとに交換を推奨する時期を判定する、
請求項1に記載の情報処理装置。 - 前記判定部は、前記端末が備える部品の交換を推奨すると判定したとき、前記端末を、少なくとも1つのグレードにランク付けする、
請求項1に記載の情報処理装置。 - 前記端末データには、少なくとも前記端末から取得したテレメトリデータ、前記端末の過去の修理実績データが含まれる、
請求項1に記載の情報処理装置。 - ユーザが利用中の端末に関する端末データを取得するステップと、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定するステップと、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定するステップと、
を含み、
前記推定するステップは、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨するステップ、を有し、
前記推奨するステップは、前記判定するステップにより、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
情報処理装置が実行する情報処理方法。 - ユーザが利用中の端末に関する端末データを取得するステップと、
前記端末データに基づいて、前記端末が備える部品ごとの消耗度と、前記端末が備える部品ごとの故障率とを推定するステップと、
前記消耗度及び前記故障率に基づいて、前記端末が備える部品ごとに交換を推奨するか否かを判定するステップと、
をコンピュータに実行させるためのプログラムであって、
前記推定するステップは、前記端末データに対して、学習モデル又はルールベースを適用して、前記ユーザと前記端末との相性を推定し、
さらに、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合、前記ユーザに前記端末の交換を推奨するステップ、を有し、
前記推奨するステップは、前記判定するステップにより、前記端末が備える部品の中に交換を推奨する部品が存在しないと判定され、かつ、前記ユーザと前記端末との相性を示す値が所定の閾値未満である場合に、前記ユーザに前記端末の交換を推奨する、
プログラム。
Publications (1)
Publication Number | Publication Date |
---|---|
JP7515682B1 true JP7515682B1 (ja) | 2024-07-12 |
Family
ID=
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018147148A (ja) | 2017-03-03 | 2018-09-20 | ロジテックInaソリューションズ株式会社 | 端末、保守管理システム、端末用プログラム、モジュール付き端末、モジュールアダプタ |
JP2018173793A (ja) | 2017-03-31 | 2018-11-08 | 富士通株式会社 | 情報処理装置、情報処理方法、およびプログラム |
JP2022169217A (ja) | 2021-04-27 | 2022-11-09 | 東芝ライフスタイル株式会社 | 家電システム |
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018147148A (ja) | 2017-03-03 | 2018-09-20 | ロジテックInaソリューションズ株式会社 | 端末、保守管理システム、端末用プログラム、モジュール付き端末、モジュールアダプタ |
JP2018173793A (ja) | 2017-03-31 | 2018-11-08 | 富士通株式会社 | 情報処理装置、情報処理方法、およびプログラム |
JP2022169217A (ja) | 2021-04-27 | 2022-11-09 | 東芝ライフスタイル株式会社 | 家電システム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6983928B2 (ja) | コンピューティング・デバイスについてのシステム性能およびイベント・データを収集、追跡、および記憶するためのシステムおよび方法 | |
US10891182B2 (en) | Proactive failure handling in data processing systems | |
US8301759B2 (en) | Monitoring agent programs in a distributed computing platform | |
US11329869B2 (en) | Self-monitoring | |
US9923856B2 (en) | Deputizing agents to reduce a volume of event logs sent to a coordinator | |
US9348685B2 (en) | Intermediate database management layer | |
GB2531884A (en) | Analysing effects of programs on mobile devices | |
US8370800B2 (en) | Determining application distribution based on application state tracking information | |
US11165665B2 (en) | Apparatus and method to improve precision of identifying a range of effects of a failure in a system providing a multilayer structure of services | |
JP7515682B1 (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP6015750B2 (ja) | ログ収集サーバ、ログ収集システム、ログ収集方法 | |
WO2024118188A1 (en) | Computer application error root cause diagnostic tool | |
JP2020109636A (ja) | 互換性のあるモジュールを特定するシステムおよび方法 | |
CN114896128A (zh) | 基于区块链的应用程序性能测试方法及装置 | |
CN115668131A (zh) | 加速预生产功能使用 | |
JP5565181B2 (ja) | 予測装置、予測方法、及び予測プログラム | |
JP2018190205A (ja) | 事業者間一括サービス管理装置および事業者間一括サービス管理方法 | |
JP2024023007A (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP2024006610A (ja) | コールセンタ装置、プログラム、コールセンタシステム、及び処理方法 | |
CN117952446A (zh) | 业务处理模型的监控方法、相关设备及存储介质 | |
JP2024012087A (ja) | 機械学習モデルのデータ管理システム及びデータ管理方法 | |
Jiang | FLANDROID: Energy-Efficient Recommendations of Reliable Context Providers for Android Applications | |
CN113268648A (zh) | 数据质量的确定方法、系统、计算设备及存储介质 |