特許 6770905 情報処理装置及び情報処理システム

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

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

(11)【特許番号】6770905

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

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

(54)【発明の名称】情報処理装置及び情報処理システム

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20201012BHJP

【ＦＩ】

   G06Q10/06

【請求項の数】4

【全頁数】15

(21)【出願番号】特願2017-18162(P2017-18162)

(22)【出願日】2017年2月3日

(65)【公開番号】特開2018-124887(P2018-124887A)

(43)【公開日】2018年8月9日

【審査請求日】2017年8月14日

【審判番号】不服2019-8041(P2019-8041/J1)

【審判請求日】2019年6月17日

(73)【特許権者】

【識別番号】501440684

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

(74)【代理人】

【識別番号】100079108

【弁理士】

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

(74)【代理人】

【識別番号】100109346

【弁理士】

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

(74)【代理人】

【識別番号】100117189

【弁理士】

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

(74)【代理人】

【識別番号】100134120

【弁理士】

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

(72)【発明者】

【氏名】遠藤 真明

(72)【発明者】

【氏名】桶井 貞宏

(72)【発明者】

【氏名】村山 光範

【合議体】

【審判長】 渡邊 聡

【審判官】 佐藤 聡史

【審判官】 松田 直也

(56)【参考文献】

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

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

【文献】 チャーリー ラッセル著，外１名，”Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ ２００８ オフィシャルマニュアル 上”，日経ＢＰソフトプレス，２００９年３月２日，初版，Ｐ．４３５−４３８

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

G06Q 10/00-99/00

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

【請求項1】

複数の端末と通信可能な情報処理装置であって、
各端末にインストールされている複数のアプリケーションプログラムのうち特定のアプリケーションプログラムのＣＰＵ使用率を収集する収集部と、
収集された前記ＣＰＵ使用率が第１の評価期間中に第１の閾値以上であった回数に基づき各端末の処理が高負荷状態であるか否かを判定する判定部と、
前記判定部の判定結果を提供する提供部と、
を備える情報処理装置。

【請求項2】

前記収集部はさらに、各端末の利用時間Ｄ、バッテリ駆動時間Ｅ、社外ネットワーク接続時間Ｆを収集し、
前記判定部はさらに、前記バッテリ駆動時間Ｅを前記利用時間Ｄで除した値Ｅ／Ｄが第２の評価期間中に第２の閾値以上であった場合、または、前記社外ネットワーク接続時間Ｆを前記利用時間Ｄで除した値Ｆ／Ｄが第３の評価期間中に第３の閾値以上であった場合に、前記端末が持ち運ばれて利用されることが多い高携帯利用状態であると判定する、
請求項１に記載の情報処理装置。

【請求項3】

前記収集部はさらに、各端末の回復不可能セクタ数を収集し、
前記判定部はさらに、収集された前記回復不可能セクタ数に基づき前記端末の故障可能性を判定する、
請求項１又は２に記載の情報処理装置。

【請求項4】

請求項１に記載の情報処理装置と、他の情報処理装置と、を備える情報処理システムであって、
前記他の情報処理装置は、
前記端末から機種交換の要求を受け付けた場合に、前記情報処理装置に対して前記判定結果を要求する要求部と、
前記判定結果が前記高負荷状態であることを示している場合には前記端末より処理能力が高い機種を選択可能機種とする変更部と、
前記機種交換を要求した前記端末に対して前記選択可能機種を通知する通知部と、
を有する情報処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置及び情報処理システムに関する。

【背景技術】

【0002】

従来、会社や団体等のグループでは、端末の交換申請等がされた場合、ユーザに係らず同一種類の端末を申請したユーザに貸し出していた。

【0003】

これに関し、特許文献１には、各端末におけるアプリケーションプログラムの利用状況を分析する情報分析装置が開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１２−１４５３０号公報

【発明の概要】

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

【0005】

しかしながら、特許文献１に記載のように、アプリケーションプログラムの利用状況を把握できたとしても、その情報だけでは、ユーザに不適切な端末を貸し出してしまうという問題があった。また、このような問題は、端末を譲渡する場合にも存在する。以下では、上記「貸し出し」及び「譲渡」を含めて「提供」という。

【0006】

本発明は以上説明した事情を鑑みてなされたものであり、適切な端末をユーザが選択可能な情報処理装置を提供することを目的の一つとする。

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

【0007】

本発明の第一態様における情報処理装置は、複数の端末と通信可能な情報処理装置であって、各端末にインストールされている複数のアプリケーションプログラムのうち特定のアプリケーションプログラムのＣＰＵ使用率を収集する収集部と、収集された前記ＣＰＵ使用率が第１の評価期間中に第１の閾値以上であった回数に基づき各端末の処理が高負荷状態であるか否かを判定する判定部と、前記判定部の判定結果を提供する提供部とを備える。

【0008】

なお、上記「判定結果を要求した端末」とは、上記複数の端末だけでなく、それ以外の端末であってもよい。

【0009】

この態様によれば、提供部から各端末の処理の負荷度合が提供される。したがって、ユーザが端末の交換申請等をする際に、負荷度合が提供された者又は装置は、当該負荷度合に基づき、ユーザに応じて適切な端末をユーザが選択可能となる。

【発明の効果】

【0010】

本発明によれば、各端末の処理の負荷度合が提供されるので、当該負荷度合に基づき適切な端末を選択可能となる。

【図面の簡単な説明】

【0011】

【図1】図１は、第１実施形態に係る情報処理システムの全体構成の一例を示す図である。

【図2】図２は、収集サーバのハードウェア構成の一例を概略的に示す図である。

【図3】図３は、収集サーバと受付サーバとの機能的な構成の一例を概略的に示すブロック図である。

【図4】図４は、第１実施形態に係る情報処理システムにおいて、収集サーバと端末との間でバックグラウンドにて行われる処理の流れを示すフローチャートである。

【図5】図５は、第１実施形態に係る情報処理システムにおいて、端末のユーザが端末の交換申請を行う場合に、端末と、受付サーバと、収集サーバとの間で行われる処理の流れを示すフローチャートである。

【図6】図６（Ａ）は、端末の交換申請の開始ボタンが押下された場合に、端末に表示されるトップ画面の一例を示す図である。図６（Ｂ）は、端末に表示される、端末の交換申請画面の一例を示す図である。

【図7】図７は、端末に表示される確認画面の一例を示す図である。

【図8】図８は、第２実施形態に係る情報処理システムにおいて、収集サーバと端末との間でバックグラウンドにて行われる処理の流れを示すフローチャートである。

【図9】図９は、第２実施形態に係る情報処理システムにおいて、例えば端末のユーザのうち権限のあるユーザ（会社の上司等）が有償アプリの更新を検討する場合に、端末と、受付サーバと、収集サーバとの間で行われる処理の流れを示すフローチャートである。

【図10】図１０は、端末に表示される各有償アプリの利用率の一例を示す図である。

【図11】図１１は、第３実施形態に係る情報処理システムにおいて、受付サーバの管理者等が端末の故障可能性を把握する場合に、受付サーバと、収集サーバとの間で行われる処理の流れを示すフローチャートである。

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

【0012】

以下、添付図面を参照しながら本発明の実施形態について説明する。説明の理解を容易にするため、各図面において同一の構成要素及びステップに対しては可能な限り同一の符号を付して、重複する説明は省略する。

【0013】

＜第１実施形態＞
図１は、第１実施形態に係る情報処理システム１の全体構成の一例を示す図である。図１に示すように、情報処理システム１は、収集サーバ１０と、複数の端末１２と、受付サーバ１４と、を備える。これらの装置は、イントラネットやインターネット等の通信ネットワークＮＴを介して互いに通信可能に接続されている。

【0014】

収集サーバ１０は、複数の端末１２の情報（以下、「端末情報」という。）を収集し、収集した端末情報に基づき各種判定を行う情報処理装置である。なお、収集サーバ１０は、受付サーバ１４の端末情報も収集し、収集した端末情報に基づき各種判定を行ってもよい。

【0015】

端末１２は、会社や団体等のグループ内に設けられた端末である。端末１２としては、デスクトップパソコン等の非可搬型通信装置や、携帯電話、携帯電話、ＰＨＳ、衛星携帯電話、タブレット、及び、ノートパソコン等の可搬型通信装置等が挙げられる。第１実施形態では、端末１２が可搬型通信装置のノートパソコンである場合を説明する。

【0016】

受付サーバ１４は、複数の端末１２からの要求を受け付け、その要求に対する処理を行う、収集サーバ１０とは異なる他の情報処理装置である。なお、収集サーバ１０と受付サーバ１４は、一つの装置で構成されてもよい。

【0017】

図２は、収集サーバ１０のハードウェア構成の一例を概略的に示す図である。図２に示すように、収集サーバ１０は、制御装置２０と、通信装置２６と、記憶装置２８と、を備える。制御装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２２及びメモリ２４を主に備えて構成される。

【0018】

制御装置２０では、ＣＰＵ２２がメモリ２４或いは記憶装置２８等に格納された所定のプログラムを実行することにより、各種の機能実現手段として機能する。この機能実現手段の詳細については後述する。

【0019】

通信装置２６は、外部の装置と通信するための通信インターフェース等で構成される。通信装置２６は、例えば、端末１２や受付サーバ１４との間で各種の情報を送受信する。

【0020】

記憶装置２８は、ハードディスク等で構成される。記憶装置２８は、制御装置２０における処理の実行に必要な各種プログラムや各種の情報、及び処理結果の情報を記憶する。

【0021】

なお、収集サーバ１０は、専用又は汎用のサーバ・コンピュータなどの情報処理装置を用いて実現することができる。なお、収集サーバ１０は、単一の情報処理装置より構成されるものであっても、通信ネットワークＮＴ上に分散した複数の情報処理装置より構成されるものであってもよい。

【0022】

なお、図２は、収集サーバ１０が有する主要なハードウェア構成の一部を示しているに過ぎず、収集サーバ１０は、サーバが一般的に備える他の構成を備えることができる。

【0023】

複数の端末１２と、受付サーバ１４のハードウェア構成も、例えば操作手段を備える他は、収集サーバ１０と同様の構成を備えることができる。

【0024】

図３は、収集サーバ１０と受付サーバ１４との機能的な構成の一例を概略的に示すブロック図である。図３に示すように、収集サーバ１０は、収集部３０と、判定部３２と、提供部３４と、記憶部３６等の機能部を備える。また、受付サーバ１４は、要求部４０と、変更部４２と、通知部４４等の各機能部を備える。記憶部３６は、一又は複数の記憶装置２８で実現される。その他の各機能部は、制御装置２０が記憶装置２８に格納されたプログラムを実行することによって実現される。

【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】

（ステップＳＰ５４）
変更部４２は、ユーザが選択できる選択可能機種として、言い換えればユーザが交換可能な端末の種類として、現在選択できるものよりもバッテリ駆動時間が長く、且つ、軽量なモビリティ機器を追加する。そして、処理はステップＳＰ５６の処理に移行する。

【0055】

（ステップＳＰ５６）
通知部４４は、選択可能機種を端末１２に返信する。

【0056】

（ステップＳＰ５８）
端末１２は、選択可能機種を受付サーバ１４から受信する。これに応答して、端末１２は、受信した選択可能機種に基づき、例えば図６（Ｂ）に示すような交換申請画面を表示する。この交換申請画面では、機種タイプのタブを選択すると、選択可能機種が選択可能となっている。

【0057】

（ステップＳＰ６０）
端末１２は、選択可能機種の中から希望機種の申請をユーザから受け付ける。

【0058】

以上、第１実施形態によれば、提供部３４から各端末１２の処理の負荷度合や各端末１２が持ち運ばれて利用される携帯度合が受付サーバ１４に提供される。したがって、ユーザが端末１２の交換申請をする際に、負荷度合や携帯度合が提供された受付サーバ１４は、これらの負荷度合や携帯度合に基づき、ユーザに応じて適切な端末が選択可能となる。

【0059】

また、受付サーバ１４のユーザ又は端末１２のユーザのうち権限のあるユーザ（会社の上司等）は、例えば図７に示すように、その装置にて、社員番号等を入力することで、その社員に対応する、パラメータＨｉｓｐｅｃやパラメータＭｏｂｉｌｉｔｙの値、その値となる条件等を示す確認画面を表示し、これらの情報を把握することができる。

【0060】

＜第２実施形態＞
次に、第２実施形態について説明する。第２実施形態では、第１実施形態の構成に加えて、判定部３２はさらに、端末情報に基づき、各端末１２にインストールされているアプリの利用度合を判定する。

【0061】

図８は、第２実施形態に係る情報処理システムにおいて、収集サーバ１０と端末１２との間でバックグラウンドにて行われる処理の流れを示すフローチャートである。この処理は、例えば１ヶ月毎などの定期的に、又はランダムに開始される。また、この処理は、端末１２毎に行われる。

【0062】

（ステップＳＰ７０）
収集サーバ１０の収集部３０は、端末情報として、端末１２において現在利用されている有償アプリのタイトルの取得要求を端末１２に対して送信する。この処理が端末１２毎に繰り返されることで、各端末１２において利用されている有償アプリのタイトルが収集される。そして、処理はステップＳＰ７２の処理に移行する。

【0063】

（ステップＳＰ７２）
端末１２は、タイトルの取得要求を収集サーバ１０から受信する。これに応答して、端末１２は、端末１２において現在利用されている、言い換えれば現在アクティブになっているウィンドウの有償アプリのタイトルを取得し、当該タイトルを収集サーバ１０に返信する。そして、処理はステップＳＰ７４の処理に移行する。なお、端末装置１２が能動的にタイトルを送信してもよい。この場合、ステップＳＰ７０は省略される。

【0064】

（ステップＳＰ７４）
収集サーバ１０は、タイトルを端末１２から受信する。そして、収集サーバ１０の判定部３２は、受信したタイトルに基づき、端末１２において現在利用されている有償アプリの名前（アプリ名）を特定する。そして、処理はステップＳＰ７６の処理に移行する。

【0065】

（ステップＳＰ７６）
判定部３２は、特定したアプリ名を記憶部３６に格納する。そして、一連の処理が終了する。

【0066】

図９は、第２実施形態に係る情報処理システムにおいて、例えば端末１２のユーザのうち権限のあるユーザ（会社の上司等）が有償アプリの更新を検討する場合に、端末１２と、受付サーバ１４と、収集サーバ１０との間で行われる処理の流れを示すフローチャートである。なお、以下では、端末１２の代わりに、別の情報処理装置が用いられてもよい。

【0067】

（ステップＳＰ８０）
端末１２は、有償アプリの更新を検討するためのボタン（不図示）の押下を受け付ける。そして、処理はステップＳＰ８２の処理に移行する。

【0068】

（ステップＳＰ８２）
端末１２は、各端末１２に現在インストールされている有償アプリの一覧要求を受付サーバ１４に対して送信する。そして、処理はステップＳＰ８４の処理に移行する。

【0069】

（ステップＳＰ８４）
受付サーバ１４は、一覧要求を端末１２から受信する。これに応答して、受付サーバ１４は、当該受付サーバ１４の記憶部を参照し、各端末１２に現在インストールされている有償アプリの一覧を取得し、これを端末１２に返信する。そして、処理はステップＳＰ８６の処理に移行する。

【0070】

（ステップＳＰ８６）
端末１２は、有償アプリの一覧を受付サーバ１４から受信する。これに応答して、端末１２は、受信した有償アプリの一覧を表示する。そして、処理はステップＳＰ８８の処理に移行する。

【0071】

（ステップＳＰ８８）
端末１２は、例えば一覧が表示されている中で、利用率ボタン（不図示）が押下されると、各有償アプリの利用率の要求を収集サーバ１０に対して送信する。なお、利用率の要求は、受付サーバ１４を介して収集サーバ１０に対して送信されてもよい。そして、処理はステップＳＰ９０の処理に移行する。

【0072】

（ステップＳＰ９０）
収集サーバ１０の判定部３２は、記憶部３６を参照し、収集したアプリ名を取得する。そして、処理はステップＳＰ９２の処理に移行する。

【0073】

（ステップＳＰ９２）
判定部３２は、取得したアプリ名に基づき、各有償アプリの利用率（利用度合）を算出（判定）する。そして、処理はステップＳＰ９４の処理に移行する。

【0074】

（ステップＳＰ９４）
収集サーバ１０の提供部３４は、算出された利用率を端末１２に返信（提供）する。そして、処理はステップＳＰ９６の処理に移行する。

【0075】

（ステップＳＰ９６）
端末１２は、利用率を収集サーバ１０から受信して、これを表示する。図１０は、端末１２に表示される各有償アプリの利用率の一例を示す図である。図１０では、各有償アプリの利用率が円グラフにして表示されている。

【0076】

以上、第２実施形態によれば、端末１２に、各端末１２にインストールされているアプリの利用度合が提供される。これにより、ユーザは利用度合に基づいて有償アプリを更新するかどうかを適切に検討することができる。

【0077】

＜第３実施形態＞
次に、第３実施形態について説明する。第３実施形態では、第１実施形態の構成に加えて、判定部３２はさらに、端末情報に基づき、端末１２の故障可能性を判定する、

【0078】

図１１は、第３実施形態に係る情報処理システムにおいて、受付サーバ１４の管理者等が端末１２の故障可能性を把握する場合に、受付サーバ１４と、収集サーバ１０との間で行われる処理の流れを示すフローチャートである。なお、端末１２のユーザのうち権限のある者も、端末１２を介して、又は、端末１２及び受付サーバ１４を介して端末１２の故障可能性を把握する場合にも、上記処理が行われてもよい。また、上記処理が開始される前に、収集サーバ１０の収集部３０は、各端末１２の回復不可能セクタ数を収集する。

【0079】

（ステップＳＰ１００）
受付サーバ１４は、故障可能性のある端末１２を把握するためのボタン（不図示）の押下を受け付ける。そして、処理はステップＳＰ１０２の処理に移行する。

【0080】

（ステップＳＰ１０２）
受付サーバ１４は、故障可能性のある端末の一覧要求を収集サーバ１０に対して送信する。そして、処理はステップＳＰ１０４の処理に移行する。

【0081】

（ステップＳＰ１０４）
収集サーバ１０は、一覧要求を受付サーバ１４から受信する。これに応答して、収集サーバ１０の判定部３２は、端末１２毎に、収集された回復不可能セクタ数が閾値以上か否かを判定する。次に、判定部３２は、肯定判定した場合に、対応する端末１２が故障可能性のある端末と判定する。そして、処理はステップＳＰ１０６の処理に移行する。

【0082】

（ステップＳＰ１０６）
収集サーバ１０の提供部３４は、判定部３２が故障可能性のある端末と判定した端末の端末一覧を作成する。そして、処理はステップＳＰ１０８の処理に移行する。

【0083】

（ステップＳＰ１０８）
提供部３４は、作成した端末一覧を受付サーバ１４に返信（提供）する。そして、処理はステップＳＰ１１０の処理に移行する。

【0084】

（ステップＳＰ１１０）
受付サーバ１４は、端末一覧を収集サーバ１０から受信し、これを表示する。

【0085】

以上、第３実施形態によれば、端末１２に、故障可能性のある端末一覧が提供される。これにより、ユーザは端末一覧から故障可能性のある端末１２を把握し、その後の対応を検討することができる。

【0086】

＜変形例＞
以上、具体例を参照しつつ本発明の実施の形態について説明した。しかし、本発明はこれらの具体例に限定されるものではない。すなわち、これら具体例に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。前述した各具体例が備える各要素およびその配置、条件、形状などは、例示したものに限定されるわけではなく適宜変更することができる。

【0087】

例えば、収集部３０は、端末情報としてＣＰＵ使用率Ａ等を収集する場合を説明したが、他にも各端末１２のメモリの使用率や端末１２の位置情報を収集してもよい。そして、これらの端末情報に基づき、判定部３２は、メモリの負荷度合や、端末１２の利用場所を判定するようにしてもよい。

【0088】

また、第１実施形態では、取得要求に応じて端末１２がＣＰＵ使用率Ａを収集サーバ１０に対して送信する場合を説明したが、端末１２が能動的に送信するようにしてもよい。また、第１実施形態では、使用率Ａが閾値Ｓ１以上か否かの判定は、収集サーバ１０で行う場合を説明したが、端末１２で行ってもよい。具体的には、まず、端末１２がその日初めて起動した際に、端末１２は収集サーバ１０に対して、特定アプリの一覧情報と閾値を要求する。それに対して収集サーバ１０は特定アプリの一覧と閾値を返信する。端末１２はその情報を端末１２の記憶装置に格納する。端末１２は定期的（数分おき）にアプリ一覧のＣＰＵ使用率Ａを取得し閾値を上回る場合はその情報を収集サーバ１０に送信する。

【符号の説明】

【0089】

１０…収集サーバ、１２…端末、１４…受付サーバ、３０…収集部、３２…判定部、３４…提供部、３６…記憶部、４０…要求部、４２…変更部、４４…通知部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】