(57)【要約】【課題】更新ソフトウェアの存在の有無を確認する問い合わせ間隔を適切に制御することを目的とする。【解決手段】判定部（１１）は、システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定する。問い合わせ部（１２）は、判定部（１１）で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否かを問い合わせる。取得部（１３）は、問い合わせ部（１２）の問い合わせの結果、サーバに更新ソフトウェアが存在する場合には、更新ソフトウェアをサーバから取得する。【選択図】図１
2017134589.tif 000002
【特許請求の範囲】
【請求項１】
システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定する判定部と、
前記判定部で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否かを問い合わせる問い合わせ部と、
前記問い合わせ部の問い合わせの結果、前記サーバに前記更新ソフトウェアが存在する場合には、前記更新ソフトウェアを前記サーバから取得する取得部と、
を含む、情報処理装置。
【請求項２】
前記品質は、前記情報処理装置のリセット頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度、所定機能を使用した場合の電池消費量、及び所定機能を使用した場合のプロセッサ発熱量の少なくとも１つに基づいて判定される、
請求項１に記載の情報処理装置。
【請求項３】
前記判定部は、前記情報処理装置のリセット頻度が第１閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度が第２閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度が第３閾値を越える場合、前記所定機能を使用した場合の電池消費量が第４閾値を越える場合、及び前記所定機能を使用した場合のプロセッサ発熱量が第５閾値を越える場合、の少なくとも１つの場合に、前記品質が悪いと判定する、
請求項２に記載の情報処理装置。
【請求項４】
前記問い合わせ部は、前記判定部が前記品質が良いと判定した場合には、前記問い合わせ間隔を現在の問い合わせ間隔よりも長くなるように定め、前記判定部が前記品質が悪いと判定した場合には前記問い合わせ間隔を現在の問い合わせ間隔よりも短くなるように定める、
請求項１〜請求項３の何れか１項に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
情報処理装置には、出荷時から多くのソフトウェアがインストールされている。これらのソフトウェアは、その欠陥を修正するため、また、更新された他のソフトウェアとの整合をとるために情報処理装置の出荷後も更新される。一般的に、情報処理装置とサーバとの間では、ネットワークを介して、サーバが当該更新されたソフトウェア（以下、更新ソフトウェアまたは更新ソフトともいう。）を有しているか否か、を確認するための通信が行われる。例えば、情報処理装置の一例であるプリンタに対して、更新ソフトの存在を通知するサーバが存在する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−０９２３７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、スマートフォンなどの携帯型情報処理装置では、サーバとの通信に無線通信を使用し、無線通信では電力を消費する。サーバが更新ソフトの存在を通知し、携帯型情報処理装置が当該通知を受け取る場合、携帯型情報処理装置は、サーバからの通知を待つ間も通信可能な状態を維持するために、電力を消費する。
【０００５】
一方で、充電池によって稼動する携帯型情報処理装置では、稼働時間を延ばすために電力の消費を抑制することが重要である。また、サーバが更新ソフトの存在を通知する場合、サーバは多数存在する携帯型情報処理装置に当該通知を行うため、サーバ及びネットワークの負荷も増大する。
【０００６】
本発明は、１つの側面として、更新ソフトウェアの存在の有無を確認する問い合わせ間隔を適切に制御することを目的とする。
【課題を解決するための手段】
【０００７】
１つの実施形態では、判定部は、システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定する。問い合わせ部は、判定部で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否かを問い合わせる。取得部は、問い合わせ部の問い合わせの結果、サーバに更新ソフトウェアが存在する場合には、更新ソフトウェアをサーバから取得する。
【発明の効果】
【０００８】
１つの側面として、更新ソフトウェアの存在の有無を確認する問い合わせ間隔を適切に制御することを可能とする。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係る情報処理装置の要部機能の一例を示すブロック図である。
【図２】本実施形態に係る情報処理装置のハードウェアの構成の一例を示すブロック図である。
【図３】本実施形態に係るソフトウェア更新処理の概要を説明するための概念図である。
【図４】本実施形態に係る品質判定情報取得処理の流れの一例を示すフローチャートである。
【図５】本実施形態に係るリセット回数取得処理の流れの一例を示すフローチャートである。
【図６】本実施形態に係る強制終了回数取得処理の流れの一例を示すフローチャートである。
【図７】本実施形態に係るフリーズ回数取得処理の流れの一例を示すフローチャートである。
【図８】本実施形態に係る電池消費量判定処理の流れの一例を示すフローチャートである。
【図９】本実施形態に係るＣＰＵ発熱量判定処理の流れの一例を示すフローチャートである。
【図１０】本実施形態に係る問い合わせ間隔調整処理の流れの一例を示すフローチャートである。
【図１１】本実施形態に係るソフトウェア品質判定処理の流れの一例を示すフローチャートである。
【図１２】本実施形態に係るソフトウェア品質判定処理を説明するための概念図である。
【図１３】本実施形態に係る更新ソフトウェア問い合わせ処理の流れの一例を示すフローチャートである。
【発明を実施するための形態】
【００１０】
［第１実施形態］
以下、図面を参照して実施形態の一例を詳細に説明する。
【００１１】
図１に示す情報処理装置１０は、判定部１１、問い合わせ部１２及び取得部１３を含む。判定部１１は、システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定する。問い合わせ部１２は、判定部１１で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否かを問い合わせる。取得部１３は、問い合わせ部１２の問い合わせの結果、サーバに更新ソフトウェアが存在する場合には、更新ソフトウェアをサーバから取得する。
【００１２】
情報処理装置１０は、一例として、図２に示すように、プロセッサの一例であるＣＰＵ（Central Processing Unit）２１、一次記憶部２２、二次記憶部２３、温度計２４、タッチパネルディスプレイ２５、通信部２６及び外部インターフェイス２７を含む。ＣＰＵ２１、一次記憶部２２、二次記憶部２３、タッチパネルディスプレイ２５、通信部２６及び外部インターフェイス２７は、バス２９を介して相互に接続されている。
【００１３】
一次記憶部２２は、例えば、ＲＡＭ（Random Access Memory）などの揮発性のメモリである。二次記憶部２３は、例えば、ＨＤＤ（Hard Disk Drive）、またはＳＳＤ（Solid State Drive）などの不揮発性のメモリである。
【００１４】
二次記憶部２３は、一例として、ソフトウェア更新プログラム領域２３Ａ（以下、ソフト更新プログラム領域ともいう。）に後述する基本ソフトを更新するためのソフトウェア更新プログラム（以下、ソフト更新プログラムともいう。）を記憶している。ＣＰＵ２１は、ソフト更新プログラム領域２３Ａからソフト更新プログラムを読み出して一次記憶部２２に展開する。ＣＰＵ２１は、ソフト更新プログラムを実行することで、図１の判定部１１、問い合わせ部１２、及び取得部１３として動作する。なお、ソフト更新プログラムは、外部サーバに記憶され、ネットワークを介して、一次記憶部２２に展開されてもよい。また、ソフト更新プログラムは、ＤＶＤ（Digital Versatile Disc）などの非一時的記録媒体に記憶され、記録媒体読込装置を介して読み込まれ、一次記憶部２２に展開されてもよい。
【００１５】
二次記憶部２３は、また、一例として、基本ソフトを記憶する基本ソフト領域２３Ｂ、基本ソフトリストの情報を記憶する基本ソフトリスト領域２３Ｃ、及び後述するフラグ、カウンタ、またはレジスタを記憶するフラグ領域２３Ｄ、カウンタ領域２３Ｅ、及びレジスタ領域２３Ｆを含む。基本ソフトとは、システムソフトウェア（以下、「システムソフトともいう。）またはプリインストールアプリケーション（以下、「プリインアプリ」ともいう。）であり、基本ソフトは、情報処理装置１０の出荷時に、基本ソフト領域２３Ｂに記憶されている。基本ソフトリストは、基本ソフトであるシステムソフト及びプリインアプリのリストであり、例えば、基本ソフト領域２３Ｂに基本ソフトを記憶する際に、基本ソフトの名称または識別情報を登録することにより生成される。ＣＰＵ２１は、基本ソフト領域２３Ｂから基本ソフトを読み出して一次記憶部２２に展開し、実行する。
【００１６】
温度計２４は、ＣＰＵ２１に接続され、ＣＰＵ２１のＣＰＵ温度を計測し、計測したＣＰＵ温度の値をＣＰＵ２１に送信する。タッチパネルディスプレイ２５は、タッチパネル２５Ａ及びディスプレイ２５Ｂを含む。ディスプレイ２５Ｂは、例えば、アプリ及びアプリの機能をユーザに選択させるためのアイコン、並びに、当該アプリ及びアプリの機能の画面などを表示する。タッチパネル２５Ａは、例えば、当該アプリ及びアプリの機能などを選択するユーザのタッチ操作を検出する。
【００１７】
通信部２６は、例えば、更新ソフトの有無の問い合わせをサーバに対して送信し、当該問い合わせの結果及び更新ソフトをサーバから受信する。外部インターフェイス２７には、外部装置が接続され、外部インターフェイス２７は、外部装置とＣＰＵ２１との間の各種情報の送受信を司る。
【００１８】
なお、情報処理装置１０は、例えば、スマートフォンであってよいが、本実施形態は、これに限定されない。例えば、情報処理装置１０は、タブレット、ノートパソコン、または、携帯ゲーム装置の携帯型情報処理装置などであってよい。また、情報処理装置１０は、デスクトップパソコン、プリンタなどの周辺機器、またはネットワークに接続可能なテレビなど、基本ソフトを含む任意の装置であってよい。
【００１９】
次に、情報処理装置１０の作用の概略について説明する。本実施形態では、図３に例示するように、ＣＰＵ２１は、ブロック３１で、基本ソフトの品質を判定する。ＣＰＵ２１は、ブロック３２で、ブロック３１の判定で取得された品質判定結果３１Ａに基づいて、基本ソフトの品質が悪い場合の間隔が基本ソフトの品質が良い場合の間隔より短くなるように問い合わせ間隔３２Ａを調整する。
【００２０】
基本ソフトの品質が「良い」とは、情報処理装置１０の動作に対する基本ソフトに起因する問題が少ない、即ち、ユーザが不快さをあまり感じることなく、情報処理装置１０を使用することができている状態である。一方、基本ソフトの品質が「悪い」とは、情報処理装置１０の動作に基本ソフトに起因する問題が多く、即ち、情報処理装置１０の使用においてユーザが不快さを感じる状態である。
【００２１】
情報処理装置１０の動作における基本ソフトに起因する問題とは、例えば、情報処理装置１０がリセットする頻度が高い、基本ソフトが強制終了する頻度が高い、または基本ソフトがフリーズする頻度が高い、などである。また、基本ソフトに起因する問題とは、例えば、電池消費量が多い、またはＣＰＵ２１の発熱量が多い、などである。
【００２２】
本実施形態では、例えば、次の何れか１つの場合に、基本ソフトの品質が悪いと判断する。即ち、情報処理装置１０のリセット頻度が第１閾値を越える場合、基本ソフトの強制終了頻度が第２閾値を越える場合、基本ソフトのフリーズ頻度が第３閾値を越える場合、及び所定機能を使用した場合の電池消費量が第４閾値を越える場合である。また、所定機能を使用した場合のＣＰＵ発熱量が第５閾値を越える場合も、基本ソフトの品質が悪いと判断する。
【００２３】
ＣＰＵ２１は、ブロック３３で、問い合わせ間隔３２Ａで、基本ソフトを更新するソフトウェアまたは更新された基本ソフトである更新ソフトの有無３３Ａを、ネットワーク１７を介して、サーバ１６に問い合わせる。サーバ１６に更新ソフト３４Ａが存在する場合、ＣＰＵ２１は、ブロック３４で、更新ソフト３４Ａをサーバ１６から受信して、基本ソフトを更新する。
【００２４】
次に、情報処理装置１０の作用について説明する。図４に、基本ソフトの品質を判定するための情報を取得する品質判定情報取得処理を例示する。情報処理装置１０の電源キーをオンする操作が行われると、ＣＰＵ２１は、ステップ１１０で、情報処理装置１０がリセットした回数を取得するリセット回数取得処理を行う。ＣＰＵ２１は、ステップ１２０で、基本ソフトの強制終了が発生した回数を取得する強制終了回数取得処理を行う。ＣＰＵ２１は、ステップ１３０で、基本ソフトのフリーズが発生した回数を取得するフリーズ回数取得処理を行う。ＣＰＵ２１は、ステップ１４０で、所定の機能を使用した場合の電池消費量が所定の閾値を越える回数を取得する電池消費量判定処理を行う。ＣＰＵ２１は、ステップ１５０で、所定の機能を使用した場合のＣＰＵ発熱量が閾値を越える回数を取得するＣＰＵ発熱量判定処理を行う。
【００２５】
ＣＰＵ２１は、ステップ１１４で、電源キーをオフする操作が行われたか否か判定し、ステップ１１４の判定が否定されると、ステップ１２０に戻る。ステップ１１４の判定が肯定されると、ＣＰＵ２１は、ステップ１１５で、後述する第１フラグに０を設定し、品質判定情報取得処理を終了する。
【００２６】
図４のステップ１１０のリセット回数取得処理の詳細を図５に例示する。ＣＰＵ２１は、ステップ１１１で、二次記憶部２３のフラグ領域２３Ｄの第１フラグがリセットされているか、即ち、第１フラグに０が設定されているか否かを判定する。第１フラグは、情報処理装置１０が直前にオフされた際に、電源キーを操作することによって、適切にオフされたか否かを示すフラグである。後述するように、第１フラグに０が設定されている場合、情報処理装置１０が直前にオフされた際に電源キーをオフする操作によって適切にオフされたことを示す。
【００２７】
ステップ１１１の判定が肯定された場合、ＣＰＵ２１は、ステップ１１２で、第１フラグをセット、即ち、第１フラグに１を設定して、リセット回数取得処理を終了する。ステップ１１１の判定が肯定された場合とは、即ち、情報処理装置１０が直前にオフされた際に電源キーをオフする操作によって適切にオフされた場合である。一方、ステップ１１１の判定が否定された場合、ＣＰＵ２１は、ステップ１１３でカウンタ領域２３Ｅの第１カウンタに１を加算し、リセット回数取得処理を終了する。ステップ１１１の判定が否定される場合とは、情報処理装置１０が直前にオフされた際に、例えば、異常動作に起因するリセットによってオフされた場合である。第１カウンタは、リセット回数をカウントするカウンタである。第１カウンタに初期値０を設定するタイミングについては後述する。
【００２８】
図４のステップ１２０〜ステップ１５０を行った後、ＣＰＵ２１は、ステップ１１４で、電源キーをオフする操作が行われたか否かを判定する。ステップ１１４の判定が否定されると、ＣＰＵ２１は、ステップ１２０に進む。一方、ステップ１１４の判定が肯定された場合、即ち、電源キーをオフする操作が行われた場合、ＣＰＵ２１は、ステップ１１５で、第１フラグに０を設定する。
【００２９】
電源キーをオフする操作が行われた場合、ＣＰＵ２１は、ステップ１１５で、第１フラグに０を設定するため、情報処理装置１０が、電源キーをオフする操作によって適切にオフされた場合、第１フラグには０が設定されている。一方、異常動作に起因するリセットによってオフされた場合、第１フラグには図５のステップ１１２で設定された１が設定されている。また、次に電源キーをオンする操作が行われた際に実行されるリセット回数取得処理において、ステップ１１１で、第１フラグに０が設定されているか否かを判定する。当該判定により、情報処理装置１０が直前にオフされた際に電源キーをオフする操作によって適切にオフされたのか、異常動作に起因するリセットによってオフされたのかを判定することができる。
【００３０】
図４のステップ１２０の強制終了回数取得処理の詳細を図６に例示する。ＣＰＵ２１は、ステップ１２１で、ソフトウェアの強制終了が発生したか否かを判定する。ここでは、ソフトウェアは、基本ソフト以外のソフトウェアも含む。ソフトウェアの強制終了が発生したか否かは、オペレーティングシステムから情報を収集することによって判定する。
【００３１】
ステップ１２１の判定が肯定されると、ステップ１２２で、ＣＰＵ２１は、強制終了されたソフトウェアが基本ソフトであるか否か判定する。ＣＰＵ２１は、強制終了されたソフトウェアが、例えば、二次記憶部２３の基本ソフトリスト領域２３Ｃに記憶されている基本ソフトリストに登録されている基本ソフトの何れかであるか否かを判定する。
【００３２】
ステップ１２２の判定が肯定された場合、ＣＰＵ２１は、ステップ１２３で二次記憶部２３のカウンタ領域２３Ｅの第２カウンタに１を加算し、強制終了回数取得処理を終了する。第２カウンタは、強制終了回数をカウントするカウンタである。第２カウンタに初期値０を設定するタイミングについては後述する。
【００３３】
ステップ１２１の判定が否定された場合、またはステップ１２２の判定が否定された場合も、ＣＰＵ２１は、強制終了回数取得処理を終了する。
【００３４】
図４のステップ１３０のフリーズ回数取得処理の詳細を図７に例示する。ＣＰＵ２１は、ステップ１３１でソフトウェアのフリーズが発生したか否かを判定する。ここでは、ソフトウェアは、基本ソフト以外のソフトウェアも含む。ソフトウェアのフリーズが発生したか否かは、オペレーティングシステムから情報を収集することによって判定する。
【００３５】
ステップ１３１の判定が肯定されると、ステップ１３２で、ＣＰＵ２１は、フリーズが発生したソフトウェアが基本ソフトであるか否か判定する。ＣＰＵ２１は、フリーズが発生したソフトウェアが、例えば、二次記憶部２３の基本ソフトリスト領域２３Ｃに記憶されている基本ソフトリストに登録されている基本ソフトの何れかであるか否かを判定する。
【００３６】
ステップ１３２の判定が肯定された場合、ＣＰＵ２１は、ステップ１３３で二次記憶部２３のカウンタ領域２３Ｅの第３カウンタに１を加算して、フリーズ回数取得処理を終了する。第３カウンタは、フリーズの発生回数をカウントするカウンタである。第３カウンタに初期値０を設定するタイミングについては後述する。
【００３７】
ステップ１３１の判定が否定された場合、またはステップ１３２の判定が否定された場合も、ＣＰＵ２１は、フリーズ回数取得処理を終了する。
【００３８】
図４のステップ１４０の電池消費量判定処理の詳細を図８に例示する。ここでは、動画アプリを用いて所定時間動画を録画する場合について説明する。ＣＰＵ２１は、ステップ１４１で、基本ソフトである動画アプリが起動されているか否か判定する。
【００３９】
ステップ１４１の判定が肯定されると、ステップ１４２で、動画アプリの録画機能が起動されたか否か判定する。ステップ１４２の判定が肯定された場合、ステップ１４４で、電池残量ＢＲＳ（％）を二次記憶装置２３のレジスタ領域２３Ｆの第１電池残量レジスタに記憶する。
【００４０】
ステップ１４５で、ＣＰＵ２１は、所定時間が経過したか否か判定する。所定時間は、例えば、１分であってよい。ステップ１４５の判定が肯定されると、ステップ１４７で、ＣＰＵ２１は、電池残量ＢＲＥ（％）をレジスタ領域２３Ｆの第２電池残量レジスタに記憶する。
【００４１】
ステップ１４８で、ＣＰＵ２１は、第１電池残量レジスタに記憶した電池残量ＢＲＳから第２電池残量レジスタに記憶した電池残量ＢＲＥを減算した値が第４閾値を越えるか否か判定する。ステップ１４８の判定が肯定された場合、ＣＰＵ２１は、ステップ１４９で、二次記憶部２３のカウンタ領域２３Ｅの第４カウンタに１を加算し、電池消費量判定処理を終了する。第４カウンタは、動画アプリを用いて１分間動画を録画した場合の電池消費量が第４閾値を越える回数をカウントするカウンタである。
【００４２】
第４閾値は、例えば、情報処理装置１０を出荷する前のテスト段階における電池消費量を基準として設定されてもよいし、情報処理装置１０の設計情報を基準として設定されてもよい。本実施形態では、例えば、４ｋ動画を１分間録画した場合に、電池消費量が５％を越えた場合に、ステップ１４９で、第４カウンタに１を加算する。
【００４３】
ステップ１４２の判定が否定された場合、ステップ１４３で、ＣＰＵ２１は、録画機能以外の機能が起動されたか、もしくは、動画アプリが終了されたか否かを判定する。ステップ１４３の判定が否定された場合、ＣＰＵ２１は、ステップ１４２に戻る。
【００４４】
また、ステップ１４５の判定が否定された場合、ステップ１４６で、ＣＰＵ２１は録画機能が終了されたか否かを判定する。判定が否定された場合、即ち、所定時間が経過する前に録画機能が終了されていない場合、ＣＰＵ２１は、ステップ１４５に戻る。ステップ１４３またはステップ１４６の判定が肯定された場合、もしくは、ステップ１４１またはステップ１４８の判定が否定された場合、ＣＰＵ２１は、電池消費量判定処理を終了する。
【００４５】
なお、例えば、動画の映像規格毎（例えば、４ｋ動画、フルＨＤ動画、及び７２０ｐ動画など）に電池消費量を判定するようにしてもよい。また、例えば、複数のアプリの複数の機能毎に電池消費量を判定するようにしてもよい。例えば、音楽アプリを用いて所定時間音楽を再生する場合について電池消費量を判定するようにしてもよいし、電話アプリを用いて所定時間通話をする場合について電池消費量を判定するようにしてもよい。
【００４６】
図４のステップ１５０のＣＰＵ発熱量判定処理の詳細を図９に例示する。ここでは、動画アプリを用いて所定時間動画を録画する場合について説明する。
【００４７】
ＣＰＵ２１は、ステップ１５１で、動画アプリが起動されているか否か判定する。ステップ１５１の判定が肯定されると、ステップ１５２で、録画機能が起動されたか否か判定する。ステップ１５２の判定が肯定された場合、ステップ１５４で、温度計２４で計測したＣＰＵ温度ＣＴＳ（度）を二次記憶部２３のレジスタ領域２３Ｆの第１ＣＰＵ温度レジスタに記憶する。
【００４８】
ステップ１５５で、ＣＰＵ２１は、所定時間が経過したか否か判定する。所定時間は、例えば、１分であってよい。ステップ１５５の判定が肯定されると、ステップ１５７で、ＣＰＵ２１は、温度計２４で計測したＣＰＵ温度ＣＴＥ（度）をレジスタ領域２３Ｆの第２ＣＰＵ温度レジスタに記憶する。
【００４９】
ステップ１５８で、ＣＰＵ２１は、第２ＣＰＵ温度レジスタに記憶したＣＰＵ温度ＣＴＥから第１ＣＰＵ温度レジスタに記憶したＣＰＵ温度ＣＴＳを減算した値が第５閾値を越えるか否か判定する。ステップ１５８の判定が肯定された場合、ＣＰＵ２１は、ステップ１５９で、二次記憶部２３のカウンタ領域２３Ｅの第５カウンタに１を加算し、ＣＰＵ発熱量判定処理を終了する。第５カウンタは、動画アプリを用いて１分間動画を録画した場合のＣＰＵ発熱量が第５閾値を越える回数をカウントするカウンタである。
【００５０】
第５閾値は、例えば、情報処理装置１０の出荷前のテスト段階におけるＣＰＵ発熱量を基準として設定されてもよいし、情報処理装置１０の設計情報を基準として設定されてもよい。第５カウンタの初期値の設定については後述する。本実施形態では、例えば、４ｋ動画を１分間録画した場合に、ＣＰＵ発熱量が１０度を越えた場合に、ステップ１５９で、第５カウンタに１を加算する。
【００５１】
ステップ１５２の判定が否定された場合、ステップ１５３で、ＣＰＵ２１は、録画機能以外の機能が起動されたか、もしくは、動画アプリが終了されたか否かを判定する。ステップ１５３の判定が否定された場合、ＣＰＵ２１は、ステップ１５２に戻る。
【００５２】
また、ステップ１５５の判定が否定された場合、ステップ１５６で、ＣＰＵ２１は録画機能が終了されたか否かを判定する。判定が否定された場合、即ち、所定時間が経過する前に録画機能が終了されていない場合、ＣＰＵ２１は、ステップ１５５に戻る。ステップ１５３またはステップ１５６の判定が肯定された場合、もしくは、ステップ１５１またはステップ１５８の判定が否定された場合、ＣＰＵ２１は、ＣＰＵ発熱量判定処理を終了する。
【００５３】
なお、例えば、動画の映像規格毎（例えば、４ｋ動画、フルＨＤ動画、及び７２０ｐ動画など）にＣＰＵ発熱量を判定するようにしてもよい。また、例えば、複数のアプリの複数の機能毎にＣＰＵ発熱量を判定するようにしてもよい。例えば、音楽アプリを用いて所定時間音楽を再生する場合についてＣＰＵ発熱量を判定するようにしてもよいし、電話アプリを用いて所定時間通話をする場合についてＣＰＵ発熱量を判定するようにしてもよい。
【００５４】
図１０に、問い合わせ間隔調整処理を例示する。問い合わせ間隔調整処理は、所定期間毎に行われる。例えば、問い合わせ間隔調整処理は１日に１回行われてもよい。
【００５５】
ステップ１６１で、ＣＰＵ２１は、二次記憶部２３のレジスタ領域２３Ｆの問い合わせ間隔レジスタから問い合わせ間隔を取得する。なお、問い合わせ間隔の初期値は、例えば、２週間であってよい。
【００５６】
ステップ１６２で、ＣＰＵ２１は、後述するソフト品質判定処理を行う。ステップ１６３で、ＣＰＵ２１は、基本ソフトの品質が良いか否か、即ち、後述する品質フラグが１であるか否かを判定する。ステップ１６３の判定が肯定された場合、ＣＰＵ２１は、ステップ１６４で、問い合わせ間隔レジスタに記憶されている問い合わせ間隔が最長の問い合わせ間隔以上であるか否か判定する。ステップ１６４の判定が否定された場合、ＣＰＵ２１は、問い合わせ間隔レジスタに記憶されている問い合わせ間隔を延長し、問い合わせ間隔調整処理を終了する。
【００５７】
最長の問い合わせ間隔は、例えば、８週間であってよく、ステップ１６５において、問い合わせ間隔は、例えば、２週間ずつ延長されてもよい。即ち、問い合わせ間隔の初期値が２週間であり、基本ソフトの品質が良い状態が継続した場合、問い合わせ間隔は、４週間、６週間、８週間と、８週間まで延長され、その後、基本ソフトの品質が良い状態が継続したとしても問い合わせ間隔は延長されない。
【００５８】
ステップ１６３の判定が否定された場合、ＣＰＵ２１は、ステップ１６６で、問い合わせ間隔レジスタに記憶されている問い合わせ間隔が最短の問い合わせ間隔以下であるか否か判定する。ステップ１６６の判定が否定された場合、ＣＰＵ２１は、ステップ１６７で、問い合わせ間隔レジスタに記憶されている問い合わせ間隔を短縮し、問い合わせ間隔調整処理を終了する。
【００５９】
最短の問い合わせ間隔は、例えば、２日であってよく、ステップ１６７において、問い合わせ間隔は、例えば、半減されてもよい。即ち、問い合わせ間隔の初期値が２週間であり、基本ソフトの品質が悪い状態が継続した場合、問い合わせ間隔は、７日、４日、２日と、２日まで短縮され、その後、基本ソフトの品質が悪い状態が継続したとしても、問い合わせ間隔は短縮されない。なお、ここでは、問い合わせ間隔を半減する際に小数点以下を切り上げている。
【００６０】
なお、上記では、問い合わせ間隔が延長及び短縮される期間は一定とした。しかしながら、本実施形態はこれに限定されない。例えば、問い合わせ間隔が延長及び短縮される期間は、後述するリセット頻度、強制終了頻度、フリーズ頻度、電池消費量、またはＣＰＵ発熱量の何れかの値、もしくは、電池消費量またはＣＰＵ発熱量が各々閾値を越えた回数に基づいて決定されてもよい。即ち、リセット頻度、強制終了頻度、フリーズ頻度、電池消費量、またはＣＰＵ発熱量の何れかの値、もしくは、電池消費量またはＣＰＵ発熱量が各々閾値を越えた回数が大きくなるに従って、ステップ１６７で短縮される期間を長く設定してもよい。一方、リセット頻度、強制終了頻度、フリーズ頻度、電池消費量、またはＣＰＵ発熱量の何れかの値、もしくは、電池消費量またはＣＰＵ発熱量が各々閾値を越えた回数が小さくなるに従って、ステップ１６７で短縮される期間を短く設定してもよい。
【００６１】
図１０のステップ１６２のソフト品質判定処理の詳細を図１１に例示する。ステップ１７１で、ＣＰＵ２１は、図５に例示したリセット回数取得処理で取得したリセット回数に基づいて、リセット頻度が第１閾値を越えるか否かを判定する。
【００６２】
ステップ１７２で、ＣＰＵ２１は、図６に例示した強制終了回数取得処理で取得した強制終了回数に基づいて、強制終了頻度が第２閾値を越えるか否かを判定する。ステップ１７３で、ＣＰＵ２１は、図７に例示したフリーズ回数取得処理で取得したフリーズ回数に基づいて、フリーズ頻度が第３閾値を越えるか否か判定する。
【００６３】
ステップ１７４で、ＣＰＵ２１は、図８に例示した電池消費量判定処理で、電池消費量が第４閾値を越えたか否かを判定する。ステップ１７５で、ＣＰＵ２１は、図９に例示したＣＰＵ発熱量判定処理で、ＣＰＵ発熱量が第５閾値を越えたか否かを判定する。
【００６４】
ステップ１７１〜ステップ１７５の何れか１つの判定が肯定された場合、ステップ１７７で、ＣＰＵ２１は、二次記憶部２３のフラグ領域２３Ｄの品質フラグに、基本ソフトの品質が悪いことを示す値０を設定する。ステップ１７１〜ステップ１７５の全ての判定が否定された場合、ステップ１７６で、ＣＰＵ２１は、品質フラグに、基本ソフトの品質が良いことを示す値１を設定する。
【００６５】
ステップ１７１のリセット頻度はリセット頻度演算部によって算出され、ステップ１７２の強制終了頻度は強制終了頻度演算部によって算出され、ステップ１７３のフリーズ頻度はフリーズ頻度演算部によって算出される。リセット頻度演算部、強制終了頻度演算部及びフリーズ頻度演算部の各々は、同様の構成を有するため、図１２に例示する一般化した頻度演算部２０を用いて説明する。
【００６６】
頻度演算部２０は、二次記憶部２３のカウンタ領域２３Ｅの第ｎカウンタ２００（ｎは１〜３の自然数）、第ｎ−１カウンタ２０１、第ｎ−２カウンタ２０２、…、第ｎ−（ｍ−１）カウンタｍ−１（ｍは自然数）、及び第ｎ−ｍカウンタｍを含む。ＣＰＵ２１は、第ｎ−（ｍ−１）カウンタｍ−１のカウント値を第ｎ−ｍカウンタｍにセットし、第ｎ−（ｍ−２）カウンタｍ−２のカウント値を第ｎ−（ｍ−１）カウンタｍ−１にセットする。同様に、隣接するカウンタのカウント値を順次移動し、第ｎ−１カウンタ２０１のカウント値を第ｎ−２カウンタ２０２に移動すると、ＣＰＵ２１は、第ｎカウンタ２００のカウント値を第ｎ−１カウンタ２０１に移動する。また、ＣＰＵ２１は、第ｎカウンタ２００に初期値０を設定する。
【００６７】
ＣＰＵ２１は、第ｎ−１カウンタ２０１〜第ｎ−ｍカウンタｍのカウント値を合計することによって、問い合わせ間隔調整処理をｍ回行った場合の頻度を取得することができる。問い合わせ間隔調整処理を１日に１回行う場合、取得される頻度はｍ日間のカウント値の合計となる。
【００６８】
ステップ１７１では、所定の期間に発生したリセット回数であるリセット頻度を取得し、第１閾値と比較する。図５に例示するように、リセット回数は第１カウンタにカウントされているため、図１２においてｎ＝１である。また、問い合わせ間隔調整処理を１日に１回行い、所定の期間を１０日であるとすれば、図１２においてｍ＝１０である。例えば、所定の期間が１０日である場合、第１閾値は２回であってよい。第１閾値は、例えば、情報処理装置１０の出荷前のテスト段階におけるリセット頻度を基準として設定されてもよい。
【００６９】
ステップ１７２では、所定の期間に発生した強制終了回数である強制終了頻度を取得し、第２閾値と比較する。図６に例示するように、強制終了回数は第２カウンタにカウントされているため、図１２においてｎ＝２である。また、問い合わせ間隔調整処理を１日に１回行い、所定の期間を１０日であるとすれば、図１２においてｍ＝１０である。例えば、所定の期間が１０日である場合、第２閾値は５回であってよい。第２閾値は、例えば、情報処理装置１０の出荷前のテスト段階における強制終了頻度を基準として設定されてもよい。
【００７０】
ステップ１７３では、所定の期間に発生したフリーズ回数であるフリーズ頻度を取得し、第３閾値と比較する。図７に例示するように、フリーズ回数は第３カウンタにカウントされているため、図１２においてｎ＝３である。また、問い合わせ間隔調整処理を１日に１回行い、所定の期間を１０日であるとすれば、図１２においてｍ＝１０である。例えば、所定の期間が１０日である場合、第３閾値は３０回であってよい。第３閾値は、例えば、情報処理装置１０の出荷前のテスト段階におけるフリーズ頻度を基準として設定されてもよい。
【００７１】
ステップ１７４では、電池消費量が第４閾値を越えたか否か判定するために、第４カウンタを参照する。第４カウンタのカウントが０でない場合、電池消費量が第４閾値を越えたと判定する。ここで、第４カウンタに初期値０を設定する。
【００７２】
ステップ１７５では、ＣＰＵ発熱量が第５閾値を越えたか否か判定するために、第５カウンタのカウントが０であるか否か判定する。第５カウンタのカウントが０でない場合、ＣＰＵ発熱量が第５閾値を越えたと判定する。ここで、第５カウンタに初期値０を設定する。
【００７３】
図１３に、更新ソフトウェア問い合わせ処理を例示する。更新ソフトウェア問い合わせ処理は、前回更新ソフトウェア問い合わせ処理が終了してから、問い合わせ間隔レジスタに記憶されている問い合わせ間隔が経過した後に、開始される。ＣＰＵ２１は、ステップ１８１で、サーバに基本ソフトの更新ソフトが存在するか否か問い合わせを行う。
【００７４】
ＣＰＵ２１は、ステップ１８２で、更新ソフトが存在するか否か判定する。ステップ１８２の判定が肯定された場合、即ち、例えば、サーバから更新ソフトが存在することを示す応答を受信した場合、ステップ１８３で、ＣＰＵ２１は、更新ソフトをサーバから二次記憶部２３にダウンロードする。ステップ１８４で、ＣＰＵ２１は、当該更新ソフトで二次記憶部２３の基本ソフト領域２３Ｂの基本ソフトを更新して、更新ソフトウェア問い合わせ処理を終了する。ステップ１８２の判定が否定された場合、更新ソフトウェア問い合わせ処理を終了する。
【００７５】
なお、ステップ１８２の判定が連続して否定された回数をカウントし、所定の値を越えた場合、問い合わせ間隔レジスタの値を初期値に戻すようにしてもよい。問い合わせの際に、更新ソフトが連続して存在しない場合、例えば、情報処理装置１０に取り付けたケースなどのオプション品、もしくは、基本ソフト以外のソフトウェアなどに起因して、ソフトウェアの品質が悪いと判定されている可能性が高い。この場合に、基本ソフトの更新ソフトの存在の有無を問い合わせる間隔を短縮することは、情報処理装置１０、ネットワーク及びサーバへの負荷を不必要に増加させる原因となるためである。
【００７６】
なお、図１１において、ステップ１７１〜ステップ１７５の判定を行う例について説明したが、本実施形態はこれに限定されない。例えば、ステップ１７１〜ステップ１７５の何れか１つ、または何れか２つ〜４つの組み合わせの判定を行うようにしてもよい。また、ステップ１７１〜ステップ１７５に例示した以外の基本ソフトの品質の判定を行うようにしてもよい。
【００７７】
なお、第１〜第５閾値の各々の値は、情報処理装置１０の出荷時に、二次記憶部２３のレジスタ領域２３Ｆに記憶されていてもよいが、本実施形態はこれに限定されない。第１〜第５閾値の各々の値は、例えば、更新ソフトウェアと共に、サーバからダウンロードされ、レジスタ領域２３Ｅに記憶されてもよい。即ち、第１〜第５閾値の各々の値は変更可能であってよい。
【００７８】
なお、図４〜図１１及び図１３のフローチャートは一例であり、フローチャートにおけるステップの順序は変更されてもよい。上記した、フラグ、カウンタ、レジスタは一例であり、処理に応じて、より多くのフラグ、カウンタ、レジスタが利用されてもよいし、より少ないフラグ、カウンタ、レジスタが利用されてもよい。
【００７９】
本実施形態では、判定部１１は基本ソフトの品質を判定し、問い合わせ部１２は判定部１１で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように問い合わせ間隔を定める。判定部１１は、定めた問い合わせ間隔で、サーバ１６に更新ソフトが存在するか否かを問い合わせる。取得部１３は、問い合わせ部１２の問い合わせの結果、サーバ１６に更新ソフトウェアが存在する場合には、更新ソフトウェアをサーバ１６から取得する。
【００８０】
本実施形態によれば、更新ソフトウェアの存在の有無を確認する問い合わせ間隔を適切に制御することを可能とする。
【００８１】
問い合わせ間隔が固定されている場合、例えば、更新ソフトウェアの有無の問い合わせが行われた直後に基本ソフトが更新され、基本ソフトの品質が悪いために、ユーザが不快に感じる事象が長期間継続し、ユーザエクスペアリアンスが低下する可能性があり得る。一方で、基本ソフトの品質が良く、基本ソフトの更新が不要であり、従って、基本ソフトの更新頻度が低下するにも拘わらず、短い固定間隔で更新ソフトウェアの有無の問い合わせが行われると、サーバ、ネットワーク及び情報処理装置に不要な負担がかかる。
【００８２】
一方、本実施形態によれば、上記したように、更新ソフトウェアの存在の有無を確認する問い合わせ間隔を適切に制御することを可能とする。基本ソフトの品質が悪い場合には、問い合わせの頻度を増大するため、情報処理装置を使用するユーザが不快に感じる事象が長期間継続することを抑制し、ユーザエクスペアリアンスを向上させることができる。一方、基本ソフトの品質が良い場合には、更新ソフトウェアの有無の問い合わせの頻度を低減するため、不要な問い合わせを行うことでサーバ、ネットワーク及び情報処理装置にかかる負担を低減することができる。
【００８３】
以上の各実施形態に関し、更に以下の付記を開示する。
【００８４】
（付記１）
システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定する判定部と、
前記判定部で判定された品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否かを問い合わせる問い合わせ部と、
前記問い合わせ部の問い合わせの結果、前記サーバに前記更新ソフトウェアが存在する場合には、前記更新ソフトウェアを前記サーバから取得する取得部と、
を含む、情報処理装置。
（付記２）
前記品質は、前記情報処理装置のリセット頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度、所定機能を使用した場合の電池消費量、及び所定機能を使用した場合のプロセッサ発熱量の少なくとも１つに基づいて判定される、
付記１の情報処理装置。
（付記３）
前記判定部は、前記情報処理装置のリセット頻度が第１閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度が第２閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度が第３閾値を越える場合、前記所定機能を使用した場合の電池消費量が第４閾値を越える場合、及び前記所定機能を使用した場合のプロセッサ発熱量が第５閾値を越える場合、の少なくとも１つの場合に、前記品質が悪いと判定する、
付記２の情報処理装置。
（付記４）
前記問い合わせ部は、前記判定部が前記品質が良いと判定した場合には、前記問い合わせ間隔を現在の問い合わせ間隔よりも長くなるように定め、前記判定部が前記品質が悪いと判定した場合には前記問い合わせ間隔を現在の問い合わせ間隔よりも短くなるように定める、
付記１〜付記３の何れかの情報処理装置。
（付記５）
プロセッサが、
システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定し、
判定された前記品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否か問い合わせを行い、
前記問い合わせの結果、前記サーバに前記更新ソフトウェアが存在する場合には、前記更新ソフトウェアを前記サーバから取得する、
ソフトウェア更新方法。
（付記６）
前記品質は、情報処理装置のリセット頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度、所定機能を使用した場合の電池消費量、及び所定機能を使用した場合のプロセッサ発熱量の少なくとも１つに基づいて判定される、
付記５のソフトウェア更新方法。
（付記７）
前記情報処理装置のリセット頻度が第１閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度が第２閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度が第３閾値を越える場合、前記所定機能を使用した場合の電池消費量が第４閾値を越える場合、及び前記所定機能を使用した場合のプロセッサ発熱量が第５閾値を越える場合、の少なくとも１つの場合に、前記品質が悪いと判定する、
付記６のソフトウェア更新方法。
（付記８）
前記品質が良いと判定した場合には、前記問い合わせ間隔を現在の問い合わせ間隔よりも長くなるように定め、前記品質が悪いと判定した場合には前記問い合わせ間隔を現在の問い合わせ間隔よりも短くなるように定める、
付記５〜付記７の何れかのソフトウェア更新方法。
（付記９）
システムソフトウェア及びプリインストールアプリケーションを含むソフトウェアの品質を判定し、
判定された前記品質に基づいて、品質が悪い場合の間隔が品質が良い場合の間隔より短くなるように定めた問い合わせ間隔で、サーバに更新ソフトウェアが存在するか否か問い合わせを行い、
前記問い合わせの結果、前記サーバに前記更新ソフトウェアが存在する場合には、前記更新ソフトウェアを前記サーバから取得する、
ソフトウェア更新処理をプロセッサに実行させるためのプログラム。
（付記１０）
前記品質は、情報処理装置のリセット頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度、所定機能を使用した場合の電池消費量、及び所定機能を使用した場合のプロセッサ発熱量の少なくとも１つに基づいて判定される、
付記９のプログラム。
（付記１１）
前記ソフトウェア更新処理は、前記情報処理装置のリセット頻度が第１閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションの強制終了頻度が第２閾値を越える場合、前記システムソフトウェアまたは前記プリインストールアプリケーションのフリーズ頻度が第３閾値を越える場合、前記所定機能を使用した場合の電池消費量が第４閾値を越える場合、及び前記所定機能を使用した場合のプロセッサ発熱量が第５閾値を越える場合、の少なくとも１つの場合に、前記品質が悪いと判定する、
付記１０のプログラム。
（付記１２）
前記ソフトウェア更新処理は、前記品質が良いと判定した場合には、前記問い合わせ間隔を現在の問い合わせ間隔よりも長くなるように定め、前記品質が悪いと判定した場合には前記問い合わせ間隔を現在の問い合わせ間隔よりも短くなるように定める、
付記９〜付記１１の何れかのプログラム。
【符号の説明】
【００８５】
１０  情報処理装置
１１  判定部
１２  問い合わせ部
１３  取得部
２１  ＣＰＵ
２２  一次記憶部
２３  二次記憶部
【図１】
2017134589.tif 000003
【図２】
2017134589.tif 000004
【図３】
2017134589.tif 000005
【図４】
2017134589.tif 000006
【図５】
2017134589.tif 000007
【図６】
2017134589.tif 000008
【図７】
2017134589.tif 000009
【図８】
2017134589.tif 000010
【図９】
2017134589.tif 000011
【図１０】
2017134589.tif 000012
【図１１】
2017134589.tif 000013
【図１２】
2017134589.tif 000014
【図１３】
2017134589.tif 000015