(57)【要約】      （修正有）【課題】携帯端末の故障を考慮した動作診断に係るユーザーの利便性を改善する。【解決手段】端末装置３は、複数のアプリケーション１〜アプリケーションＮの実行履歴をアプリ実行頻度ＤＢ６３に蓄積する記憶部１３０ｂと、所定のタイミングに、実行履歴に基づいて、複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行するアプリ動作診断部３５を備えた自己診断処理部３０と、を有する。【選択図】図３
2016173628.tif 000002
【特許請求の範囲】
【請求項１】
端末装置における複数のアプリケーションの実行履歴を蓄積する記憶手段と、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する診断処理手段と、
を有することを特徴とする端末装置。
【請求項２】
前記診断処理手段は、
前記動作診断処理において、前記実行頻度が前記所定の頻度以上のアプリケーションのログに、起動に係るエラー記録があるか否かを判断し、エラー記録がある場合、該アプリケーションは稼働失敗したと診断する
ことを特徴とする請求項１記載の端末装置。
【請求項３】
前記診断処理手段は、
前記動作診断処理において、前記エラー記録がない場合で、かつ、該アプリケーションが診断対象として設定されているか否かを判断し、該アプリケーションが診断対象として設定されている場合には、前記動作診断処理を実行する
ことを特徴とする請求項２記載の端末装置。
【請求項４】
複数のアプリケーションの実行履歴を蓄積し、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する、
処理をコンピュータに行わせることを特徴とする動作診断プログラム。
【請求項５】
複数のアプリケーションの実行履歴を蓄積し、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する、
処理をコンピュータが行うことを特徴とする動作診断方法。
【請求項６】
端末装置に蓄積された、前記端末装置における複数のアプリケーションの実行履歴に基づき、前記複数のアプリケーションから選択されたアプリケーションについての動作診断結果を受信する受信手段と、
受信した前記動作診断結果に基づき、前記端末装置の修理又は点検が必要であるか否かを判定する判定手段と、
修理又は点検が必要であると判定された場合、前記動作診断結果に応じた前記端末装置の修理又は点検に関する情報を前記端末装置に送信する送信手段と、
を有することを特徴とするコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置、動作診断プログラム、動作診断方法、及びコンピュータに関する。
【背景技術】
【０００２】
スマートデバイス、ウェアラブル端末等の情報処理端末の故障は、ユーザーが自身で情報処理端末を操作したとき、又は、情報処理端末の自己診断機能を手動で実行させたときに発見する場合がある。
【０００３】
情報処理端末の故障がユーザーによって認識されるまで放置されることのないよう、定期的に自己診断を行い、異常がある場合には、外部サーバーに対して診断結果を送信する技術等が提案されている。
【０００４】
また、効率的に自己診断を行うために、複数の機能ブロックの各々の動作頻度に応じて自己診断の優先順位を設定し、設定した優先順位と自己診断の実行可能回数とに基づいて各機能ブロックの自己診断を行う技術等が知られている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１０８１１１号公報
【特許文献２】特開２０１２−２５２３７３号公報
【特許文献３】特許３８８０４５３号公報
【特許文献４】特開２００５−１８１９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、情報処理端末の故障が発見された後に、ユーザーが、情報処理端末の販売店、又は、サービス拠点に持ち込み、又は、送付することで、初めて情報処理端末の修理が開始となる。ユーザーは、今すぐにでも端末を使用したいにも係らず、修理を完了し、情報処理端末が使用できるまでに多大な時間がかかる場合がある。
【０００７】
特に、ユーザーが出張、旅行など、移動先で故障を検知した場合は、修理が完了するまで時間がかかるため、修理依頼を躊躇してしまう場合がある。このような場合、出張先、旅行先では情報処理端末、又は、情報処理端末の機能が使用できないという不便さがある。
【０００８】
したがって、１つの側面では、本発明は、端末装置の故障を考慮した、端末装置のユーザーの利便性を改善することを目的とする。
【課題を解決するための手段】
【０００９】
一態様によれば、端末装置における複数のアプリケーションの実行履歴を蓄積する記憶手段と、所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する診断処理手段と、を有することを特徴とする端末装置が提供される。
【００１０】
また、一態様によれば、端末装置に蓄積された、前記端末装置における複数のアプリケーションの実行履歴に基づき、前記複数のアプリケーションから選択されたアプリケーションについての動作診断結果を受信する受信手段と、受信した前記動作診断結果に基づき、前記端末装置の修理又は点検が必要であるか否かを判定する判定手段と、修理又は点検が必要であると判定された場合、前記動作診断結果に応じた前記端末装置の修理又は点検に関する情報を前記端末装置に送信する送信手段と、を有することを特徴とするコンピュータが提供される。
【発明の効果】
【００１１】
端末装置の故障を考慮した、端末装置のユーザーの利便性を改善することができる。
【図面の簡単な説明】
【００１２】
【図１】修理システムのネットワーク構成例を示す図である。
【図２】携帯端末のハードウェア構成を示す図である。
【図３】携帯端末の機能構成例を示す図である。
【図４】ログＤＢのデータ構成例を示す図である。
【図５】診断時間ＤＢのデータ構成例を示す図である。
【図６】アプリ実行頻度ＤＢのデータ構成例を示す図である。
【図７】位置情報ＤＢのデータ構成例を示す図である。
【図８】動作診断結果ＤＢのデータ構成例を示す図である。
【図９】携帯端末の動作診断処理を説明するためのフローチャート図である。
【図１０】図９のステップＳ７６でのアプリ動作診断部によるアプリ動作診断処理を説明するためのフローチャート図である。
【図１１】サーバーのハードウェア構成を示す図である。
【図１２】サーバーの機能構成例を示す図である。
【図１３】サーバー処理を説明するための図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態を図面に基づいて説明する。本実施例では、スマートデバイス、ウェアラブル端末等の情報処理端末の実行頻度の高いアプリケーションの動作を診断し、故障を発見した際の位置情報に基づいて、情報処理端末の位置周辺で情報処理端末を効率的に修理又は点検できるようにする。情報処理端末として、携帯端末を一例として以下に説明するが、携帯端末に限定されるものではない。
【００１４】
図１は、修理システムのネットワーク構成例を示す図である。図１に示す修理システム１０００は、サーバー２００と、パーツセンター３００と、販売店４００と、１台以上の携帯端末３とがネットワーク２（インターネットを含む）を介して接続される。本実施例では、販売店４００は、サービス拠点であってもよい。
【００１５】
携帯端末３は、所定のタイミングで携帯端末３の動作を診断する自己診断処理部３０を有する。自己診断処理部３０は、センサー動作診断、送受信動作診断、端末動作診断、及びシステム状態診断に加えて、ユーザーが使用する頻度の高いアプリケーションを優先してアプリ動作診断を行う。
【００１６】
端末管理番号７１と、自己診断処理部３０によって実行された動作診断結果７２と、位置情報７３とを含む診断情報７０が、統合サービスセンター１００のサーバー２００へ送信される。端末管理番号７１は、携帯端末３の機種、携帯端末３のユーザーに関する情報等と関連付けられてサーバー２００で管理される携帯端末３の識別情報である。動作診断結果７２は、携帯端末３が自動で行う種々の動作診断の結果を示し、詳細は図８で後述される。位置情報７３は、携帯端末３の現在の位置を示す情報である。
【００１７】
統合サービスセンター１００は、サーバー２００、パーツセンター３００、販売店３００等を含む。サーバー２００は、拠点毎に設置されていてもよいし、１台のサーバー２００が、全ての携帯端末３から収集した診断情報７０を一元的に管理してもよい。パーツセンター３００及び販売店３００の各々は、１台以上の情報処理端末を有し、インターネット２に接続される。本実施例では、各情報処理端末を識別することなく、単に、パーツセンター３００及び販売店３００として説明する。
【００１８】
サーバー２００は、コンピュータ装置であり、各携帯端末３から診断情報７０を収集して、携帯端末３の現在位置から最も近いパーツセンター３００と販売店４００とを選定し、修理又は点検の手配に係る処理を行う。
【００１９】
即ち、サーバー２００は、携帯端末３から受信した動作診断結果７２から修理又は点検に必要なパーツを判別し、また、携帯端末３の位置情報７３からパーツを保管している最も近いパーツセンター３００と販売店４００とを選定し、パーツが到着する日時を算出する。
【００２０】
その後、サーバー２００は、携帯端末３のユーザーに、修理可能日時及び販売店４００に関する情報を電子メール、電話等で通知する。ユーザーが携帯端末３の修理又は点検を希望した場合、販売店４００にパーツを送付する手続きを実施し、修理又は点検を実施する。
【００２１】
パーツセンター３００は、サーバー２００からパーツの送付指示を受信すると、送付指示で指定されるパーツを送付指示で指定される販売店４００への発送に係る処理を行う。
【００２２】
販売店４００は、ユーザーの携帯端末３を修理又は点検するための訪問に応じて入力された端末管理番号７１と一致する、サーバー２００から事前に受信した修理依頼を表示部に表示する。携帯端末３は、修理依頼に基づいて、パーツセンター３００から送付されたパーツを用いて修理される。
【００２３】
上述したようなサーバー２００、パーツセンター３００、及び販売店４００が行う種々の処理は、特許文献３及び特許文献４に開示される公知の技術によって実現できるため、詳細な説明は省略する。
【００２４】
図２は、携帯端末のハードウェア構成を示す図である。図２において、携帯端末３は、コンピュータによって制御されるタブレット型、携帯電話等の情報処理端末であって、ＣＰＵ（Central Processing Unit）１１ｂと、主記憶装置１２ｂと、ユーザーＩ／Ｆ（インターフェース）１５ｂと、測位装置１６ｂと、通信Ｉ／Ｆ１７ｂと、ドライブ装置１８ｂとを有し、バスＢ２に接続される。
【００２５】
ＣＰＵ１１ｂは、主記憶装置１２ｂに格納されたプログラムに従って携帯端末３を制御するプロセッサである。主記憶装置１２ｂには、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１ｂにて実行されるプログラム、ＣＰＵ１１ｂでの処理に必要なデータ、ＣＰＵ１１ｂでの処理にて得られたデータ等を記憶又は一時保存する。主記憶装置１２ｂに格納されているプログラムが、ＣＰＵ１１ｂに実行されることによって、各種処理が実現される。
【００２６】
ユーザーＩ／Ｆ１５ｂは、ＣＰＵ１１ｂの制御のもとに必要な各種情報を表示し、また、ユーザによる操作入力を可能とするタッチパネル等である。測位装置１６ｂは、３基以上のＧＰＳ（Global Positioning System）衛星からの信号を受信して、地球上の現在地の測定を行う。携帯端末３の現在位置を示す位置情報７３が、位置情報ＤＢ（データベース）３２（図３）に記憶される。通信Ｉ／Ｆ１７ｂによる通信は無線又は有線に限定されるものではない。
【００２７】
携帯端末３によって行われる処理を実現するプログラムは、ネットワーク２を介して外部装置からダウンロードされる。或いは、予め携帯端末３の主記憶装置１２ｂに記憶されていても良い。
【００２８】
ドライブ装置１８ｂは、ドライブ装置１８ｂにセットされた記憶媒体１９ｂ（例えば、ＳＤ（Secure Digital）メモリカード等）と携帯端末３とのインターフェースを行う。主記憶装置１２ｂ及び／又は記憶媒体１９ｂが記憶部１３０ｂに相当する。
【００２９】
携帯端末３は、デスクトップ型、ノートブック型、ラップトップ型等の情報処理端末であっても良い。
【００３０】
図３は、携帯端末の機能構成例を示す図である。図３において、携帯端末３は、自己診断処理部３０を有し、記憶部１３０ｂには、動作診断結果ＤＢ６１、位置情報ＤＢ６２、アプリ実行頻度ＤＢ６３、診断時間ＤＢ６４、ログＤＢ６５、複数のアプリケーション１、２、・・・Ｎ等が記憶される。複数のアプリケーション１、２等は、携帯端末３にインストール済みのアプリケーションである。
【００３１】
自己診断処理部３０は、携帯端末３の動作診断を行う処理部であり、ＣＰＵ１１ｂが対応するプログラムを実行することによって実現される。自己診断処理部３０は、更に、センサー動作診断部３１と、送受信動作診断部３２と、端末動作診断部３３と、システム状態診断部３４と、アプリ動作診断部３５と、診断結果通知部３６とを有する。
【００３２】
センサー動作診断部３１は、携帯端末３の、ＧＰＳ（Global Positioning System）、ネットワーク通信、Ｗｉ−Ｆｉ、Bluetooth(登録商標)等のセンサーの動作を診断する。送受信動作診断部３２は、Ｗｅｂデータ、電子メール等の送受信動作を診断する。端末動作診断部３３は、画面表示、音、バイブレーター等の端末の動作を診断する。システム状態診断部３４は、ＣＰＵ１１ｂ、主記憶装置１２ｂの使用状況等のシステム状態を診断する。
【００３３】
アプリ動作診断部３５は、アプリケーション１、２、・・・Ｎ等（以下、単に、「アプリケーションｉ」（ｉ＝１、２、・・・Ｎ）という）のログを確認する。ログは、アプリケーションｉ毎に記憶され、アプリケーションｉ毎の対応するログＤＢ６５ｉ（ｉ＝１、２、・・・Ｎ）に格納されている。
【００３４】
アプリケーション１のログ確認は、ログＤＢ６５１を用いて行われ、アプリケーション２のログ確認は、ログＤＢ６５２を用いて行われ、・・・、アプリケーションＮのログ確認は、ログＤＢ６５Ｎを用いて行われる。ログＤＢ６５ｉは、総称して「ログＤＢ６５」という場合がある。
【００３５】
また、アプリ動作診断部３５によるアプリケーションｉに対するアプリ動作診断処理では、過去の起動状態をアプリ実行頻度ＤＢ６３に格納することで、実行頻度を判別し、予め定められた閾値よりも実行頻度の高いアプリケーションｉを診断対象とする。又は、ユーザーが診断対象とするアプリケーションｉを選択してもよい。
【００３６】
アプリ動作診断部３５は、各アプリケーションｉのログＤＢ６５ｉから前月のstart upからshutdownまでの時間を集計し、前月の起動時間の合計値を算出することで各アプリケーションｉの実行頻度を取得して、アプリ実行頻度ＤＢ６３に格納する。本実施例では、各アプリケーションｉの起動回数ではなく、起動している、言い換えると、動作している時間の合計を実行頻度とすることで、ユーザーが常に必要としているプリケーションｉを判定する。
【００３７】
診断時間ＤＢ６４には、予め指定された診断の日時、又は、定期的に診断する日付及び／又は時間が格納される。更に、予め指定された閾値時間を格納するようにしてもよい。
【００３８】
更に、アプリ動作診断部３５は、インストール済みアプリケーションｉのログＤＢ６５ｉから診断日時にsystem startup fail等のエラーの記録が存在するか否かを検索し、エラーの記録がなければ正常稼働、エラーの記録があれば稼働失敗を動作診断結果ＤＢ６１に格納する。エラーの記録に関する正常稼働又は稼働失敗の１以上の情報は、自動診断を行った日付に対応付けて動作診断結果ＤＢ６１で管理される。
【００３９】
アプリ動作診断部３５は、予め指定された診断日時、又は、定期的に診断する日時に、アプリ実行頻度ＤＢ６３に格納された前月の起動時間の合計値によって示される実行頻度が閾値時間より長い場合に、アプリケーションｉに対してアプリ動作診断処理を実施する。また、アプリ動作診断部３５は、閾値時間によるアプリ動作診断処理の要否に係らず、ユーザーが予め指定したアプリケーションｉについては、アプリ動作診断処理を行う。
【００４０】
診断結果通知部３６は、センサー動作診断部３１、送受信動作診断部３２、端末動作診断部３３、システム状態診断部３４、及び、アプリ動作診断部３５による診断結果を、統合サービスセンター１００のサーバー２００と、ユーザーとに通知する。
【００４１】
診断結果通知部３６は、端末管理番号７１、動作診断結果ＤＢ６１の動作診断結果７２、測位装置１６ｂが取得した位置情報７３等を示す診断情報７０を、通信Ｉ／Ｆ１７ｂにより、ネットワーク２を介して統合サービスセンター１００のサーバー２００へ送信する。また、診断結果通知部３６は、動作診断結果７２をユーザーＩ／Ｆ１５ｂに表示、電子メールでユーザー宛てに送信する等により、ユーザーに通知する。
【００４２】
次に、図４から図８で、データベース６１〜６５のデータ構成例について説明する。図４は、ログＤＢのデータ構成例を示す図である。図４において、ログＤＢ６５ｉは、アプリケーションｉ毎に用意され、所定のログデータ形式で、アプリケーションｉの動作状態を時系列に蓄積して記録したデータベースである。
【００４３】
所定のログデータ形式は、例えば、「月 日 時間:分:秒 動作: 結果」等である。「Dec 16 11:15:45 init: system startup now.」は、「１２月１６日の１１時１５分４５秒の初期化動作によって、アプリケーションｉのシステムが開始された」ことを示している。また、「Dec 16 11:24:30 init: system shutdown now.」は、「１２月１６日の１１時２４分３０秒の初期化動作によって、アプリケーションｉのシステムがシャットダウンした」ことを示している。更に、「Dec 17 13:05:15 init: system startup fail.」は、「１２月１７日の１３時０５分２０秒の初期化動作によって、アプリケーションｉのシステムのスタートアップは失敗した」ことを示している。
【００４４】
図５は、診断時間ＤＢのデータ構成例を示す図である。図５において、診断時間ＤＢ６４は、自己診断処理部３０による動作診断処理の実施の日時を記憶するデータベースである。診断時間ＤＢ６４には、指定診断日時、定期診断日時、及び閾値時間等が記憶される。
【００４５】
図５では、指定診断日時は、２０１４年１２月２５日の００時００分００秒であることが示されている。また、定期診断日時は、毎週日曜日の０３時００分００秒であることが示されている。更に、閾値時間は１０時００分００秒であることを示している。
【００４６】
図６は、アプリ実行頻度ＤＢのデータ構成例を示す図である。図６において、アプリ実行頻度ＤＢ６３は、所定期間（例えば、直前の１か月間）の各アプリケーションｉが動作していた合計時間を管理するデータベースであり、アプリケーション名、実行頻度等の項目を有する。
【００４７】
アプリケーション名は、既にインストール済みのアプリケーション１、２、・・・Ｎを特定可能な情報を示す。実行頻度は、アプリ動作診断部３５が算出した、所定期間中にアプリケーションｉが動作した時間の合計（動作時間合計）を示す。所定期間は、例えば、前月等である。
【００４８】
アプリ動作診断部３５は、図４に示すようなデータ構成を有する、各アプリケーションｉに対応するログＤＢ６５ｉを参照して、前月のstart upからshutdownまでの時間を集計することで、前月の動作時間合計を算出する。算出された動作時間合計をアプリ実行頻度ＤＢ６３に格納する。
【００４９】
図６では、過去1か月間のデータ例を示している。例えば、２０１４年１１月１日から３０日までの１か月間において、少なくとも、アプリケーション１は「2014/11/01 15:28:35」及び「2014/11/02 10:13:56」で起動され、アプリケーション２は「2014/11/30 23:42:10」で起動され、アプリケーションＮは「2014/11/02 08:11:24」で起動されたことが分かる。
【００５０】
図７は、位置情報ＤＢのデータ構成例を示す図である。図７において、位置情報ＤＢ６２は、携帯端末３の現在位置を示す位置情報を時系列に記憶するデータベースであり、日時、緯度経度等の項目を有する。日時は、現在位置を測位した日時を示す。経度緯度は、測位装置１６ｂが複数のＧＰＳ衛星から受信した信号に基づいて測位した結果を示す。
【００５１】
図７では、例えば、２０１４年１１月２９日１０時１２分４１秒時点での現在位置は、経度緯度（35.658xx, 139.7454yy）であり、２０１４年１２月０１日１４時５１分１９秒時点での現在位置は、経度緯度（35.6813xx, 139.7660yy）であり、２０１４年１２月０２日０８時３１分２７秒時点での現在位置は、経度緯度（35.5313xx, 139.6968yy）である。
【００５２】
図８は、動作診断結果ＤＢのデータ構成例を示す図である。図８において、動作診断結果ＤＢ６１は、自己診断処理部３０によって行われた種々の動作診断を記憶するデータベースである。記憶部１３０ｂにインストール済みのアプリケーション１、２、・・・、Ｎに関しては、アプリケーションｉの動作を診断するアプリ動作診断処理が実施されたアプリケーションｉの結果が記憶される。
【００５３】
図８では、２０１４年１２月０１日には、アプリケーション２、・・・Ｎに対して動作診断が実施され、全て正常稼働であったことを示している。２０１４年１２月０１日には、アプリケーション１に対するアプリ動作診断処理の結果が示されていない。アプリケーション１に対しては、アプリ動作診断処理が行われなかったことを示している。
【００５４】
２０１４年１２月０２日には、アプリケーション１、２、・・・Ｎに対して動作診断が実施され、全て正常稼働であったことを示している。２０１４年１２月０２日には、アプリケーション１に対するアプリ動作診断処理の結果が示されている。
【００５５】
２０１４年１２月０３日には、アプリケーション１、２、・・・Ｎに対して動作診断が実施され、アプリケーション２以外は、全て正常稼働であったことを示している。２０１４年１２月０３日のアプリケーション２に対するアプリ動作診断処理の結果は、稼働失敗を示している。
【００５６】
また、少なくとも２０１４年１２月０１日〜２０１４年１２月０３日の間は、センサー動作、送受信動作、及びシステム状態は、正常稼働であったことを示している。
【００５７】
携帯端末３の自己診断処理部３０による動作診断処理について図９で説明する。図９は、携帯端末の動作診断処理を説明するためのフローチャート図である。図９において、自己診断処理部３０は、携帯端末３の起動、指定診断日時、又は定期診断日時であるか否かを判断する（ステップＳ７１）。携帯端末３の起動は、電源投入時に相当する。携帯端末３の起動でない場合に、現在日時が、診断時間ＤＢ６４に記憶される指定診断日時又は定期診断日時に達しているか否かを判断する。いずれにも該当しない場合（ステップＳ７１のＮｏ）、自己診断処理部３０は、所定間隔でステップＳ７１を繰り返す。
【００５８】
いずれかに該当した場合（ステップＳ７１のＹｅｓ）、自己診断処理部３０のセンサー動作診断部３１は、種々のセンサーの動作を診断し、センサー動作の正常稼働又は稼働失敗を動作診断結果ＤＢ６１に記憶する（ステップＳ７２）。
【００５９】
自己診断処理部３０の送受信動作診断部３２は、送受信動作を診断し、送受信動作の正常稼働又は稼働失敗を動作診断結果ＤＢ６１に記憶する（ステップＳ７３）。自己診断処理部３０の端末動作診断部３３は、端末動作を診断し、端末動作の正常稼働又は稼働失敗を動作診断結果ＤＢ６１に記憶する（ステップＳ７４）。自己診断処理部３０のシステム状態診断部３４は、システム状態を診断し、端末動作の正常稼働又は稼働失敗を動作診断結果ＤＢ６１に記憶する（ステップＳ７５）。
【００６０】
自己診断処理部３０のアプリ動作診断部３５は、アプリケーションの動作を診断するアプリ動作診断処理を行い、アプリケーション動作の正常稼働又は稼働失敗を動作診断結果ＤＢ６１に記憶する（ステップＳ７６）。アプリ動作診断処理については、図１０で説明される。ステップＳ７２からＳ７６の処理順は上述の順に限定されない。
【００６１】
その後、自己診断処理部３０では、診断結果通知部３６は、動作診断結果ＤＢ６１から動作診断結果７２を取得し（ステップＳ７７）、測位装置１６ｂから現在の位置情報を取得して（ステップＳ７８）、現在の位置情報７３を取得できたか否かを判断する（ステップＳ７９）。
【００６２】
現在の位置情報を取得できなかった場合（ステップＳ７９のＮｏ）、診断結果通知部３６は、位置情報ＤＢ６２から直前の位置情報を取得して、現在の位置情報７３とする（ステップＳ８０）。一方、現在の位置情報７３を取得できた場合（ステップＳ７９のＹｅｓ）、診断結果通知部３６は、取得した位置情報７３を位置情報ＤＢ６２に格納する（ステップＳ８１）。
【００６３】
ステップＳ８０又はＳ８１の後、診断結果通知部３６は、診断情報７０を作成して統合サービスセンター１００のサーバ２００へ送信する（ステップＳ８２）。診断結果通知部３６は、携帯端末３の端末管理番号７１と、動作診断結果７２と、位置情報７３とを示す診断情報７０を作成して、サーバ２００へ送信する。
【００６４】
また、診断結果通知部３６は、動作診断結果７２をユーザーＩ／Ｆ１５ｂに表示して、ユーザーに通知する（ステップＳ８３）。ステップＳ８２及びＳ８３の処理順を限定するものではない。このユーザーへ通知するステップＳ８３の処理は、ステップＳ８２の前に行ってもよい。ステップＳ８２及びＳ８３の後、自己診断処理部３０は、ステップＳ７１へと戻り、携帯端末３が動作中（携帯端末３が電源を切られていない状態）は、上述した同様の処理を繰り返す。
【００６５】
図１０は、図９のステップＳ７６でのアプリ動作診断部によるアプリ動作診断処理を説明するためのフローチャート図である。図１０において、アプリ動作診断部３５は、記憶部１３０ｂにインストール済みのアプリケーション１〜Ｎから順に１つ選択して、アプリケーションｉとする（ステップＳ７６１）。
【００６６】
アプリ動作診断部３５は、アプリ実行頻度ＤＢ６３からアプリケーションｉの実行頻度を取得し（ステップＳ７６２）、診断時間ＤＢ６４から閾値時間（例えば、「10:00:00」（図５））を取得する（ステップＳ７６３）。
【００６７】
アプリ動作診断部３５は、アプリケーションｉの実行頻度が閾値時間より長い時間を示すか否かを判断する（ステップＳ７６４）。アプリケーションｉの実行頻度が閾値時間以下の場合（ステップＳ７６４のＮｏ）、アプリケーションｉが診断対象であるか否かを判断する（ステップＳ７６５）。アプリケーションｉが診断対象であるか否かの判断は、予めユーザーによって設定された設定情報を参照することで判断される。アプリケーションｉが診断対象ない場合（ステップＳ７６５のＮｏ）、アプリ動作診断部３５は、ステップＳ７７０へと進む。
【００６８】
アプリケーションｉが診断対象である場合（ステップＳ７６５のＹｅｓ）、アプリ動作診断部３５は、ステップＳ７６６へと進む。アプリケーションｉの実行頻度が閾値時間以下であったとしても、ユーザーによる設定が優先され、アプリケーションｉの動作診断が行われる。
【００６９】
ステップＳ７６４においてＹｅｓの場合、アプリ動作診断部３５は、現在日時（即ち、診断日時）に基づいて、アプリケーションｉのログＤＢ６５ｉから起動に係るエラーの記録を検索する（ステップＳ７６６）。エラーの記録は、例えば、system startup fail等である。
【００７０】
そして、アプリ動作診断部３５は、エラーの記録を検索できたか否かを判断する（ステップＳ７６７）。エラーの記録を検索できなかった場合、アプリ動作診断部３５は、アプリケーションｉに関して稼働失敗を動作診断結果ＤＢ６１に記憶して（ステップＳ７６８）、ステップＳ７７０へと進む。
【００７１】
一方、エラーの記録を検索できた場合、アプリ動作診断部３５は、アプリケーションｉに関して正常稼働を動作診断結果ＤＢ６１に記憶して（ステップＳ７６８）、ステップＳ７７０へと進む。
【００７２】
ステップＳ７６５、Ｓ７６８、又はＳ７６９の後、アプリ動作診断部３５は、アプリケーションｉのログＤＢ６５ｉを用いて、所定期間（例えば、前月）の実行頻度を算出して、アプリ実行頻度ＤＢ６３に記憶する（ステップＳ７７０）。アプリ動作診断部３５は、ログＤＢ６５ｉから前月のstart upからshutdownまでの時間を集計し、前月の起動時間の合計値を算出することでアプリケーションｉの実行頻度を取得して、アプリ実行頻度ＤＢ６３に格納する。
【００７３】
そして、アプリ動作診断部３５は、アプリケーション１〜Ｎの全てに対して終了したか否かを判断する（ステップＳ７７１）。アプリケーション１〜Ｎの全てに対して上述した処理を終了していない場合（ステップＳ７７１のＮｏ）、アプリ動作診断部３５は、ステップＳ７６１へと戻り上述した処理を繰り返す。一方、アプリケーション１〜Ｎの全てに対して上述した処理を終了した場合（ステップＳ７７１のＹｅｓ）、アプリ動作診断部３５は、このアプリ動作診断処理を終了する。
【００７４】
次に、サーバー２００について説明する。サーバー２００は、図１１に示すようなハードウェア構成を有する。図１１は、サーバーのハードウェア構成を示す図である。図１１において、サーバー２００は、コンピュータによって制御される情報処理装置であって、ＣＰＵ１１ａと、主記憶装置１２ａと、補助記憶装置１３ａと、入力装置１４ａと、表示装置１５ａと、通信Ｉ／Ｆ（インターフェース）１７ａと、ドライブ装置１８ａとを有し、バスＢ１に接続される。
【００７５】
ＣＰＵ１１ａは、主記憶装置１２ａに格納されたプログラムに従ってサーバー２００を制御する。主記憶装置１２ａには、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１ａにて実行されるプログラム、ＣＰＵ１１ａでの処理に必要なデータ、ＣＰＵ１１ａでの処理にて得られたデータ等を記憶又は一時保存する。
【００７６】
補助記憶装置１３ａには、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３ａに格納されているプログラムの一部が主記憶装置１２ａにロードされ、ＣＰＵ１１ａに実行されることによって、各種処理が実現される。主記憶装置１２ａと補助記憶装置１３ａとが、記憶部１３０ａに相当する。
【００７７】
入力装置１４ａは、マウス、キーボード等を有し、オペレーターがサーバー２００による処理に必要な各種情報を入力するために用いられる。表示装置１５ａは、ＣＰＵ１１ａの制御のもとに必要な各種情報を表示する。入力装置１４ａと表示装置１５ａとは、一体化したタッチパネル等によるユーザインタフェースであってもよい。通信Ｉ／Ｆ１７ａは、有線又は無線などのネットワークを通じて通信を行う。通信Ｉ／Ｆ１７ａによる通信は無線又は有線に限定されるものではない。 
サーバー２００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９ａによってサーバー２００に提供される。
【００７８】
ドライブ装置１８ａは、ドライブ装置１８ａにセットされた記憶媒体１９ａ（例えば、ＣＤ−ＲＯＭ等）とサーバー２００とのインターフェースを行う。
【００７９】
また、記憶媒体１９ａに、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１９ａに格納されたプログラムは、ドライブ装置１８ａを介してサーバー２００にインストールされる。インストールされたプログラムは、サーバー２００により実行可能となる。
【００８０】
尚、プログラムを格納する記憶媒体１９ａはＣＤ−ＲＯＭに限定されず、コンピュータが読み取り可能な、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。
【００８１】
図１２は、サーバーの機能構成例を示す図である。図１２において、サーバー２００は、受信部２４１と、判定部２４２と、送信部２４３と、手配部２４４とを有し、記憶部１３０ａには、登録リスト２７１が記憶されている。
【００８２】
受信部２４１は、携帯端末３から送信された診断情報７０を、通信Ｉ／Ｆ１７ａを介して受信すると、診断情報７０を判定部２４２に通知する。判定部２４２は、受信部２４１から通知された診断情報７０の動作診断結果７２を参照して、携帯端末３の稼働状態を判定する。判定部２４２は、動作診断結果７２に稼働失敗がある場合、送信部２４３に診断情報７０を通知する。
【００８３】
送信部２４３は、ユーザーに修理又は点検を希望するか否かを確認する確認電子メール８ａを通信Ｉ／Ｆ１７ｂを介して送信することで、携帯端末３から送信されたユーザーからの希望の有無を示す返信電子メール８ｂを通信Ｉ／Ｆ１７ｂを介して受信する（ステップＳ２４３）。返信電子メール８ｂによって、ユーザーが修理又は点検を希望を希望していると判断した場合、送信部２４３は、診断情報７０と、修理又は点検に関する修理又は点検情報とを通知する。
【００８４】
ユーザーは、出張、旅行中等の日常の生活圏以外にいる状況では、日常生活に戻ってから修理又は点検をしたいと考える場合がある。この場合、ユーザーは、修理又は点検を希望しない返信を行ってもよい。
【００８５】
出張、旅行中等の日常の生活圏以外にいる状況においても、稼働失敗したアプリケーションが使用し続けたいアプリケーションである場合、ユーザーは、早急に修理又は点検を希望する場合がある。この場合、ユーザーによって、修理又は点検を希望する返信がなされてもよい。
【００８６】
このように、本実施例では、ユーザーの利便性に応じて、必要なアプリケーションをユーザーが適切なタイミングで修理又は点検を行える。
【００８７】
手配部２４４は、診断情報７０と修理又は点検情報とに基づいて、パーツ配送データ９ａを作成して、パーツセンター３００に送信し、また、修理依頼データ９ｂを作成して、販売店４００（又はサービス拠点）に送信する。
【００８８】
次に、サーバー２００で行われるサーバー処理について図１３で説明する。図１３は、サーバー処理を説明するための図である。以下に説明するサーバー処理は、サーバー１００のＣＰＵ１１ａが対応するプログラムを実行することで実現される。
【００８９】
図１３において、サーバー２００において、受信部２４１は、診断情報７０を携帯端末３から受信したか否かを判断する（ステップＳ２０１）。診断情報７０を受信していない場合（ステップＳ２０１のＮｏ）、受信部２４１は、所定間隔でステップＳ２０１を行う。一方、診断情報７０を受信している場合（ステップＳ２０１のＹｅｓ）、受信部２４１は、受信した診断情報７０を判定部２４２に通知する。
【００９０】
診断情報７０の通知を受けると、判定部２４２は、動作診断結果７２に稼働失敗があるか否かを判断する（ステップＳ２０２）。動作診断結果７２に稼働失敗がない場合（ステップＳ２０２のＮｏ）、判定部２４２は、ステップＳ２０１に戻り、上述同様の処理を繰り返す。一方、動作診断結果７２に稼働失敗がある場合（ステップＳ２０２のＹｅｓ）、判定部２４２は、稼働失敗を示す機器の状態フラグをリセットする（ステップＳ２０３）。そして、判定部２４２は、診断情報７０を送信部２４３に通知する。
【００９１】
診断情報７０の通知に応じて、送信部２４３は、動作診断結果７２に基づいて、修理又は点検するパーツを判断する（ステップＳ２０４）。また、送信部２４３は、診断情報７０の位置情報７３に基づいて、パーツセンター、及び、販売店（又はサービス拠点）を登録リスト２７１から検索する（ステップＳ２０５）。登録リスト２７１には、各パーツセンター３００、各販売店４００（又はサービス拠点）等の所在地、連絡先等が記憶されている。
【００９２】
送信部２４３は、登録リストから位置情報７３に近いパーツセンター３００及び販売店４００（又はサービス拠点）を検索できたか否かを判断する（ステップＳ２０６）。検索できなかった場合（ステップＳ２０６のＮｏ）、送信部２４３は、診断情報７０に基づく種々の情報を表示及び／又は印刷する（ステップＳ２０７）。その後、サーバー２００は、このサーバー処理を終了する。この場合、診断情報７０に基づく種々の情報の出力に基づいて、オペレーターがユーザーに連絡する等して、修理希望の有無、修理に関して対応可能な販売店４００（又はサービス拠点）、修理日時等について確認し、必要な手続きが行われる。
【００９３】
検索できた場合（ステップＳ２０６のＹｅｓ）、送信部２４３は、パーツの到着日時を算出する（ステップＳ２０８）。
【００９４】
そして、送信部２４３は、診断情報７０の送信元のユーザーに、修理又は点検を希望するか否かを確認する確認電子メールを送信することで、ユーザーの携帯端末３から修理又は点検の希望の有無を示す返信電子メールを受信する（ステップＳ２０９）。
【００９５】
送信部２４３は、ユーザーが修理又は点検を希望しているか否かを判断する（ステップＳ２１０）。ユーザーが修理又は点検を希望していない場合（ステップＳ２１０のＮｏ）、サーバー２００は、このサーバ処理を終了する。一方、ユーザーが修理又は点検を希望している場合（ステップＳ２１０のＹｅｓ）、送信部２４３は、診断情報７０及び修理又は点検に関する修理又は点検情報を手配部２４４に通知する。
【００９６】
修理又は点検情報には、修理又は点検するパーツの情報、パーツセンタ３００の情報、販売店４００（又はサービス拠点）の情報、パーツが販売店４００（又はサービス拠点）に到着する到着日時の情報等が含まれる。
診断情報７０及び修理又は点検に関する修理又は点検情報の通知に応じて、手配部２４４は、ステップＳ２０４において判別した修理又は点検するパーツの配送に係るパーツ配送データ９ａを作成して、ステップＳ２０５で検索したパーツセンター３００に送信する（ステップＳ２１１）。
【００９７】
また、手配部２４４は、動作診断結果７２において稼働失敗を示すパーツに係る修理依頼データ９ｂを作成して、ステップＳ２０５で検索した販売店４００（又はサービス拠点）に送信する（ステップＳ２１２）。動作診断結果７２において、稼働失敗したアプリケーションｉがある場合には、修理依頼データにアプリケーションｉが指定される。そして、サーバー２００は、このサーバー処理を終了する。
【００９８】
上述したように、本実施例では、インストール済みの複数のアプリケーション１〜Ｎのう実行頻度が高いアプリケーションの動作を自己診断する。よって、携帯端末３のユーザーが故障に気付かない場合でも、動作診断結果７２がユーザーに通知されることで、ユーザーは容易に故障を認識することができる。
【００９９】
また、サーバー２００へは、端末管理番号７１と、動作診断結果７２と、位置情報７３とが通知され、サーバー２００は、ユーザーの現在位置に近いバーツセンター３００及び販売店４００（又はサービス拠点）を選択する。従って、ユーザーは、出張先、旅行中でも修理が可能となるため、ユーザーは、出張中、旅行中に携帯端末３を使用できない事態を回避することができる。
【０１００】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、主々の変形や変更が可能である。
【０１０１】
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
端末装置における複数のアプリケーションの実行履歴を蓄積する記憶手段と、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する診断処理手段と、
を有することを特徴とする端末装置。
（付記２）
前記診断処理手段は、
前記動作診断処理において、前記実行頻度が前記所定の頻度以上のアプリケーションのログに、起動に係るエラー記録があるか否かを判断し、エラー記録がある場合、該アプリケーションは稼働失敗したと診断する
ことを特徴とする付記１記載の端末装置。
（付記３）
前記診断処理手段は、
前記動作診断処理において、前記エラー記録がない場合で、かつ、該アプリケーションが診断対象として設定されているか否かを判断し、該アプリケーションが診断対象として設定されている場合には、前記動作診断処理を実行する
ことを特徴とする付記２記載の端末装置。
（付記４）
前記診断処理手段は、
前記実行履歴を参照して、所定期間における前記アプリケーションの動作の開始から終了までの時間の合計することで、前記実行頻度を算出する
ことを特徴とする付記１乃至３のいずれか一項記載の端末装置。
（付記５）
複数のアプリケーションの実行履歴を蓄積し、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する、
処理をコンピュータに行わせることを特徴とする動作診断プログラム。
（付記６）
複数のアプリケーションの実行履歴を蓄積し、
所定のタイミングに、前記実行履歴に基づいて、前記複数のアプリケーションの内、実行頻度が所定の頻度以上のアプリケーションについての動作診断処理を実行する、
処理をコンピュータが行うことを特徴とする動作診断方法。
（付記７）
端末装置に蓄積された、前記端末装置における複数のアプリケーションの実行履歴に基づき、前記複数のアプリケーションから選択されたアプリケーションについての動作診断結果を受信する受信手段と、
受信した前記動作診断結果に基づき、前記端末装置の修理又は点検が必要であるか否かを判定する判定手段と、
修理又は点検が必要であると判定された場合、前記動作診断結果に応じた前記端末装置の修理又は点検に関する情報を前記端末装置に送信する送信手段と、
を有することを特徴とするコンピュータ。
【符号の説明】
【０１０２】
２            インターネット
３            携帯端末
８ａ          確認電子メール、            ８ｂ          返信電子メール
９ａ          パーツ配送データ、          ９ｂ          修理依頼データ
１１ａ        ＣＰＵ、                    １２ａ        主記憶装置
１３ａ        補助記憶装置、              １４ａ        入力装置
１５ａ        表示装置、                  １７ａ        通信Ｉ／Ｆ
１８ａ        ドライブ装置、              １９ａ        記憶装置
１１ｂ        ＣＰＵ、                    １２ｂ        主記憶装置
１５ｂ        ユーザーＩ／Ｆ、            １６ｂ        測位装置
１７ｂ        通信Ｉ／Ｆ、                １８ｂ        ドライブ装置
１９ｂ        記憶媒体
３０          自己診断処理部
３１          センサー動作診断部、        ３２          送受信動作診断部
３３          端末動作診断部、            ３４          システム状態診断部
３５          アプリ動作診断部、          ３６          診断結果通知部
６１          動作診断結果ＤＢ、          ６２          位置情報ＤＢ
６３          アプリ実行頻度ＤＢ、        ６４          診断時間ＤＢ
６５、６５ｉ  ログＤＢ
７０          診断情報、
７１          端末管理番号、              ７２          動作診断結果
７３          位置情報
１００        統合サービスセンター
１３０ａ      記憶部、                    １３０ｂ      記憶部
２００        サーバー
３００        パーツセンター
４００        販売店
【図１】
2016173628.tif 000003
【図２】
2016173628.tif 000004
【図３】
2016173628.tif 000005
【図４】
2016173628.tif 000006
【図５】
2016173628.tif 000007
【図６】
2016173628.tif 000008
【図７】
2016173628.tif 000009
【図８】
2016173628.tif 000010
【図９】
2016173628.tif 000011
【図１０】
2016173628.tif 000012
【図１１】
2016173628.tif 000013
【図１２】
2016173628.tif 000014
【図１３】
2016173628.tif 000015