JP2014160340A - 情報処理装置，情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】適したタイミングで所定のソフトウェアのアップデートを通知する。
【解決手段】充電池とプロセッサとを備える情報処理装置において、プロセッサは、充電池の充電開始を検出し、充電開始が検出された場合に、ユーザに所定のソフトウェアのアップデートの実行を通知する。また、プロセッサは、ユーザによって所定のソフトウェアのアップデートが許可された場合に、充電池が所定の充電量未満であるか否かを判定し、充電池が所定の充電量以上である場合には、所定のソフトウェアのアップデートデータを用いた書き換え処理を開始し、充電量が所定の充電量未満である場合には、充電池が所定の充電量以上になるまで、所定のソフトウェアのアップデートデータを用いた書き換え処理を遅延させる。
【選択図】図３

Description

本発明は、プログラムのアップデートのための情報処理装置，情報処理方法及び情報処理プログラムに関する。

例えば、携帯電話端末のソフトウェアアップデートでは、アップデートデータのダウンロード処理と、アップデートデータによるソフトウェアの書き換え処理とが行われる。ソフトウェアの書き換え処理がエラーになると、書き換えられるソフトウェアによっては携帯電話端末の動作に影響を与えるため、一般的にソフトウェア書き換え処理の実行中は、他の携帯電話としての機能は使用できない。また、ソフトウェア書き換え処理中に、携帯電話端末の電池残量がなくなってしまうと、書き換えエラーになってしまうため、ソフトウェアアップデートの実行の際には、電池残量が十分であることが望まれる。

特開２００５−２２２１７１号公報

しかしながら、ユーザが新たなソフトウェアアップデートの存在に気づいたときに、例えば、電池残量が不十分であったり、ユーザが携帯電話端末の機能の使用を所望しているなどして、アップデートの実行に適した状態であるとは限らない。ユーザにとって適切なタイミングでアップデートが通知されないと、アップデートを通知しても、ユーザがアップデートの実行を許可せず、アップデートが実行されない可能性がある。

本発明の一態様は、適したタイミングで所定のソフトウェアのアップデートを通知可能な情報処理装置，情報処理方法，及び情報処理プログラムを提供することを目的とする。

本発明の態様の一つは、
充電池を備える情報処理装置であって、
前記充電池の充電開始を検出する検出部と、
前記充電開始が検出された場合に、ユーザに所定のソフトウェアのアップデートの実行を通知する通知部と、
を備える情報処理装置である。

本発明の他の態様の一つは、上述した情報処理装置が実行する情報処理方法である。また、本発明の他の態様は、コンピュータを上述した情報処理装置として機能させる情報処理プログラム、及び当該プログラムを記録したコンピュータ読み取り可能な記録媒体を含むことができる。コンピュータ等が読み取り可能な記録媒体には、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

開示の情報処理端末，情報処理方法及び情報処理プログラムによれば、適したタイミングで所定のソフトウェアのアップデートを通知することができる。

携帯端末のハードウェア構成の一例を示す図である。 携帯端末の機能ブロックの一例を示す図である。 第１実施形態におけるアップデート通知プログラムの処理のフローチャートの一例である。 第２実施形態における、アップデート通知プログラムの一部の処理のフローチャートの一例である。 第３実施形態におけるアップデート通知プログラムの一部の処理のフローチャートの一例である。 第３実施形態におけるアップデート通知プログラムの一部の処理のフローチャートの一例である。 第４実施形態におけるアップデート通知プログラムの一部の処理のフローチャートの一例である。

以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜第１実施形態＞
ソフトウェアのアップデートに適した状況とは、例えば「１）携帯端末の電池の充電量が、アップデート処理のために十分に確保できる、２）ネットワークに接続可能な環境である、３）アップデートの完了まで、操作が行われない時間を十分に確保できる」といった条件を満たす状況である。

上記１）−３）を満たす可能性のある状況の一つに、携帯端末を充電する状況がある。したがって、第１実施形態では、携帯端末の充電開始イベントの発生を検知した場合に、ユーザに対して、ソフトウェアのアップデートを通知する。充電開始イベントとは、例えば、充電用のアダプタとのコネクタや端子を通じて、電力が入力開始されること、ワイヤレス給電の場合には、電磁波の受信、起電力の検出等である。

また、携帯端末の充電開始時には、電池の充電量が十分でないことが予想されるため、第１実施形態では、携帯端末は、電池の充電量が、アップデートを完了するのに十分な量を示す閾値以上になるまで、アップデート処理を遅延させる。なお、電池の充電量、又は、残量という記載における“量”とは、電池が供給可能な電力の総量を示すこととするが、本明細書では、単に、電池の充電量，残量等と記載する。

図１は、携帯端末１のハードウェア構成の一例を示す図である。携帯端末１は、ＣＰＵ（Central Processing Unit）１０１，記憶部１０２，タッチパネル１０３，表示部１０
４，無線部１０５，オーディオ入出力部１０６，スピーカー１０７，マイクロフォン１０８，アンテナ１０９，バッテリ１１０，制御ＩＣ（Integrated Circuit）１１１，充電
部１１２を備える。

記憶部１０２は、ＲＯＭ（Read Only Memory）１０２Ａ及びＲＡＭ（Random Access Memory）１０２Ｂを含む。ＲＡＭ １０２Ｂには、揮発性のものと不揮発性のものと、双方が含まれる。不揮発性のＲＡＭ １０２Ｂには、ＯＳ（Operating System），その他アプリケーションプログラム，アップデート通知プログラムが格納される。アップデート通知プログラムは、充電開始イベントを検知した場合に、アップデートの通知画面を表示し、ユーザによってアップデートが選択された場合にアップデート処理を行うためのプログラムである。

タッチパネル１０３は、位置入力装置の１つであって、表示部１０４の画面に対応する指の接触位置の座標を入力する。タッチパネル１０４は、抵抗膜方式，表面弾性波方式，赤外線方式，電磁誘導方式，静電容量方式等のいずれの方式のものでも良い。

表示部１０４は、例えば、液晶ディスプレイ（Liquid Crystal Display，ＬＣＤ）である。表示部１０４は、ＣＰＵ １０１から入力される信号に従って、画面データを表示する。

無線部１０５は、アンテナ１０９と接続しており、アンテナ１０９を通じて受信した無線信号を電気信号に変換してＣＰＵ １０１に出力したり、ＣＰＵ １０１から入力される電気信号を無線信号に変換してアンテナ１１０を通じて送信したりする。無線部１０５は、例えば、第３世代移動通信システムに対応する電子回路である。

オーディオ入出力部１０６は、音声出力装置としてのスピーカー１０７と、音声入力装置としてのマイクロフォン１０８と、接続する。オーディオ入出力部１０６は、マイクロフォン１０８から入力された音声信号を電気信号に変換してＣＰＵ １０１に出力したり、ＣＰＵ １０１から入力された電気信号を音声信号に変換してスピーカー１０７に出力したりする。

バッテリ１１０は、充電式の電池であって、例えば、リチウムイオン電池である。ただし、バッテリ１１０は、これに限られない。制御ＩＣ １１１は、マイクロプロセッサ等を含み、該マイクロプロセッサが制御部１２における充電開始イベントを検出したり、バッテリ１１０の充電量を取得したりする。

充電部２１は、例えば、充電用アダプタと接続するためのコネクタ，ＵＳＢ（Universal Serial Bus）インタフェース端子である。また、携帯端末１がワイヤレス給電による充電の機能を備えている場合には、充電部２１は、ワイヤレス給電に対応した、コイルや整流回路等を含む受電ユニットである。充電部２１は、外部電源と接続することによって、バッテリ１１０を充電する。

なお、携帯端末１のハードウェア構成は、図１に示されるものに限定されず、適宜、追加、置換、削除等の変更が可能である。携帯端末１は、態様における「情報処理装置」の一例である。「情報処理装置」の一例には、スマートフォン，ノート型のパーソナルコンピュータ（ＰＣ），携帯電話端末，携帯タブレット端末，ＰＤＡ（Personal Digital Assistant），携帯ゲーム機等の充電式電池を備える携帯可能な情報処理装置がある。

図２は、携帯端末１の機能ブロックの一例を示す図である。携帯端末１は、機能ブロックとして、アップデート制御部１１，通信部１２，充電状態判定部１３，充電制御部１４，充電状況記憶部１５，ユーザ表示部１６，操作入力部１７，アップデート用データ保持部１８，問合せ結果保持部１９を含む。なお、充電状況記憶部１５は、第１実施形態では、用いられないため、第１実施形態では説明せずに、後述の第２実施形態において説明する。

ＣＰＵ １０１は、記憶部１０２に格納されるアップデート通知プログラムを実行することによって、アップデート制御部１１，通信部１２，充電状態判定部１３，ユーザ表示部１６，操作入力部１７としての処理を行う。ただし、これらの機能ブロックは、例えば、ＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアによって実現されても
よい。

アップデート制御部１１は、通信部１２，充電状態判定部１３，ユーザ表示部１６，操
作入力部１７を制御し、ユーザに対するアップデートの通知の実行を判定する。また、アップデート制御部１１は、ユーザによってアップデートが選択された場合に、バッテリ１１０の充電量に応じて、アップデートの処理を行う。

通信部１２は、例えば、所定の周期又は所定のイベント発生時に、無線部１０５，アンテナ１０９を通じて、ネットワークに対してアップデートデータの有無を問い合わせる。所定の周期とは、例えば、１日に１回所定の時刻，１週間に１回所定の曜日の所定の時刻，である。また、所定のイベントは、例えば、充電開始イベントや、ユーザからのアップデート確認の操作入力によるアップデート制御部１１からの指示である。また、通信部１２は、アップデートデータが有る場合には、「アップデートデータ有り」の情報を問合せ結果保持部１９に格納する。通信部１２は、アップデート制御部１１からのアップデート開始の指示によって、ネットワークからアップデートデータをダウンロードし、該アップデートデータをアップデート用データ保持部１８に格納する。

ユーザ表示部１６は、アップデート制御部１１の指示にしたがって、例えば、アップデート通知用の画面や、アップデート処理中の画面，使用許諾等の各種事前確認用の画面等を表示部１０４に出力する。アップデート通知用の画面，アップデート処理中用の画面，使用許諾等の各種事前確認用の画面は記憶部１０２のＲＡＭ １０２Ｂに格納されている。

操作入力部１７は、タッチパネル１０３からのユーザ操作の座標や入力ボタンの操作等によるユーザ入力を受け付け、該ユーザ入力を解析し、該ユーザ入力に対応する命令をアップデート制御部１１に出力する。

充電状態判定部１３は、バッテリ１１０の充電状態を判定する。具体的には、充電状態判定部１３は、アップデート制御部１１からの指示に応じて、充電制御部１４からバッテリ１１０の充電量を取得し、バッテリ１１０の充電量が所定の閾値以上であるか否かを判定し、該判定結果をアップデート制御部１１に送信する。所定の閾値とは、例えば、満充電、または、満充電の６〜７割の充電量であって、携帯端末１の仕様に応じて設定される。

充電制御部１４は、制御ＩＣ １１１のマイクロプロセッサによる所定のプログラムの実行によって実現される。充電制御部１４は、バッテリ１１０の制御を行う。より具体的には、充電制御部１４は、例えば、バッテリ１１０の充電開始イベントの検出，過充電防止のための充電終了処理，バッテリ１１０の充電量の管理等を行う。充電状態判定部１３からの問い合わせに応じて、充電制御部１４は、充電状態判定部１３にバッテリの充電量を通知する。

アップデート用データ保持部１８，問合せ結果保持部１９は、アップデート通知プログラムのインストール又はＣＰＵ １０１による実行によって、記憶部１０２のＲＡＭ １０２Ｂの記憶領域に作成される。アップデート用データ保持部１８には、通信部１２によってネットワークから取得されたアップデート用のデータが格納される。問合せ結果保持部１９には、アップデートデータの有無，各ソフトウェア確認事項のユーザの確認結果が格納される。

＜処理の流れ＞
図３は、第１実施形態におけるアップデート通知プログラムの処理のフローチャートの一例である。図３に示されるフローチャートは、例えば、充電開始イベントが検出された場合に開始される。充電開始イベントは、例えば、携帯端末１に充電器との接続によって充電部１１２への電流の入力が検出されること、ワイヤレス給電の場合には、充電部１１
２において起電力が検出されること、等である。

ＯＰ１では、アップデート制御部１１は、アップデートデータが存在するか否かを判定する。この判定は、例えば、アップデート制御部１１が通信部１２にアップデートデータの存在の確認を指示し、通信部１２がネットワークに問い合わせることによって行われる。また、この判定は、例えば、通信部１２が所定の周期でアップデートデータの有無をネットワークへ問い合わせ、問合せ結果を問合せ結果保持部１９に格納する場合には、問合せ結果保持部１９の「アップデートデータ有り」の情報の有無の判定によって行われてもよい。なお、アップデートデータは、携帯端末１が備える全部または一部のソフトウェアのアップデートデータである。

アップデートデータが存在する場合には（ＯＰ１：ＹＥＳ）、処理がＯＰ２に進む。アップデートデータが存在しない場合には（ＯＰ１：ＮＯ）、図３に示される処理が終了する。

ＯＰ２では、アップデート制御部１１は、ユーザ表示部１６に、アップデートの存在の通知を指示する。ユーザ表示部１６は、アップデート制御部１１からの指示を受けて、表示部１０４にアップデート通知用の画面を表示し、アップデートを開始するようユーザを誘導する。アップデート通知用の画面には、例えば、「アップデートを開始しますか？」というような誘導メッセージと、「ＯＫ」及び「ＮＧ」といったアップデートの開始の許可又は拒否を選択するボタンとが含まれる。次に処理がＯＰ３に進む。

ＯＰ３では、アップデート制御部１１は、ユーザによって、アップデート開始が選択されたか否かを判定する。この判定は、例えば、ユーザ操作部１７からアップデート制御部１１へ入力される、タッチパネル１０３又は入力ボタンへのユーザ入力に対応する命令によって判定される。ユーザによってアップデート開始が選択された場合には（ＯＰ３：ＹＥＳ）、処理がＯＰ４に進む。ユーザによってアップデートの開始が選択されなかった場合、例えば、アップデートの開始の拒否が選択された場合には（ＯＰ３：ＮＯ）、図３に示される処理が終了する。

ＯＰ４では、アップデート制御部１１は、アップデートの対象となるソフトウェアに関する使用許諾，注意事項等の事前確認事項を表示するように、ユーザ表示部１６に指示する。ユーザ表示部１６は、アップデート制御部１１の指示を受けて、各種事前確認用の画面を表示部１０４に表示する。各種事前確認用の画面には、例えば、使用許諾や注意事項の内容と、該内容の確認ボタンとが含まれる。各種事前確認の確認結果が、ユーザによってタッチパネル１０３又は入力ボタン等から入力され、ユーザ操作部１７を通じてアップデート制御部１１に入力される。アップデート制御部１１は、各種事前確認の確認結果を問合せ結果保持部１９に格納する。次に、処理がＯＰ５に進む。

ＯＰ５では、アップデート制御部１１は、バッテリ１１０の充電量が所定の閾値以上か否かを判定する。この判定は、アップデート制御部１１が、充電状態判定部１３に指示し、充電状態判定部１３によるバッテリの充電量が所定の閾値以上か否かの判定結果を受けることによって行われる。バッテリ１１０の充電量が所定の閾値以上である場合には（ＯＰ５：ＹＥＳ）、処理がＯＰ６に進む。バッテリ１１０の充電量が所定の閾値未満である場合には（ＯＰ５：ＮＯ）、処理がＯＰ７に進む。

ＯＰ６では、アップデート制御部１１は、バッテリ１１０の充電量が所定の閾値以上であり、アップデートを実行するのに十分な量であるので、アップデートの開始を通信部１２に指示する。

ＯＰ７では、アップデート制御部１１はバッテリ１１０の充電量が所定の閾値未満であり、アップデートを実行するのに十分な量でないため、所定の周期で充電状態判定部１３にＯＰ５の判定の指示を出し、バッテリ１１０の充電量を監視する。アップデート制御部１１は、充電状態判定部１３から、バッテリ１１０の充電量が所定の閾値以上であるとの判定結果を受けると、アップデートの開始を通信部１２に指示する。なお、バッテリ１１０の充電量が所定の閾値以上になったときには、既に、ユーザの事前確認事項の確認は取れているので、再度、事前確認は行われない。また、充電量が所定の閾値に達するまでの間は、ユーザ表示部１６は、表示部１０４に、「アップデートを受け付けました。充電後にアップデートを開始します。」とのメッセージを含む画面を表示させて、ユーザにアップデート待ち状態であることを通知してもよい。

通信部１２は、アップデート制御部１１からのアップデート開始の処理を受けて、アップデートデータをネットワークからダウンロードする。アップデート制御部１１は、アップデートデータのダウンロードが完了すると、対象のソフトウェアの書き換え処理を開始し、書き換え処理が終了すると、図３に示される処理が終了する。なお、アップデートデータのダウンロード中及びソフトウェアの書き換え処理中は、ユーザ表示部１６は、表示部１６にアップデート処理中用の画面を表示させる。アップデート処理中用の画面は、例えば、「アップデート中です。操作を行わないでください。」等のメッセージが含まれる。

なお、アップデート通知プログラムの処理は、図３に示される処理に限定されない。例えば、ＯＰ５−ＯＰ７において、アップデートデータのダウンロードの開始を判定する充電量の閾値と、ソフトウェアの書き換え処理を行う処理の開始を判定する閾値とは、異なる値であってもよい。すなわち、アップデート制御部１１は、バッテリ１１０の充電量が閾値１以上である場合にアップデートデータのダウンロード開始を指示し、ダウンロード完了後、バッテリ１１０の充電量が閾値２（＞閾値１）である場合にソフトウェアの書き換え処理を開始するようにしてもよい。

＜第１実施形態の作用効果＞
第１実施形態では、携帯端末１は、充電開始イベントの発生を検知したときに、アップデートの通知を行う。バッテリ１１０の充電を契機にして、携帯端末1はソフトウェアの
アップデートに適した状況、すなわち「１）携帯端末の電池の充電量が、アップデート処理のために十分に確保できる、２）ネットワークに接続可能な環境である、３）アップデートの完了まで、操作が行われない時間が十分にある」に到達するする可能性が高い。そのため、ユーザへのアップデートの通知を充電開始イベントの発生の検知時に行うのは、適切なタイミングであると言える。適したタイミングでアップデートを通知することによって、アップデートの実施率を向上させることができる。

また、第１実施形態では、充電開始時にバッテリ１１０の充電量が十分でない場合には、携帯端末１は、バッテリ１１０の充電を待ってから、アップデートを行う。これによって、電池切れによるアップデートエラーの発生をより抑えることができる。

＜第２実施形態＞
携帯端末のアップデートに適した状況とは、例えば「１）携帯端末の電池の充電量が、アップデート処理のために十分に確保できる、２）ネットワークに接続可能な環境である、３）アップデートの完了まで、操作が行われない時間が十分に確保される」といった条件を満たす状況である。

第１実施形態では、上記１）−３）を満たす状況の一つとして、充電開始時にアップデートの通知を行う例について述べた。第２実施形態では、携帯端末１は、上記１）−３）
を満たす状況の一つとして、充電開始且つユーザの就寝前の状況という、第１実施形態よりも限定的な状況においてユーザにアップデートの通知を行う。

ユーザの就寝中は、一般的に、ユーザによる携帯端末に対する操作は行われず、また、アップデートの完了までに十分な時間（例えば、５〜８時間）を確保することができる。また、ユーザ就寝中の携帯端末１の充電は、習慣的に行われる行動の一つである。

したがって、第２実施形態では、携帯端末１は、充電に関するログを記録し、該ログからユーザの就寝時間帯を予測し、充電開始イベントの発生時刻が、予測した該ユーザの就寝時間帯に含まれる場合に、アップデートの通知を行う。なお、第２実施形態では、第１実施形態と重複する説明は省略される。

第２実施形態では、携帯端末１のハードウェア構成は、図１に示す通りである。また、携帯端末１の機能ブロックは、図２に示す通りである。

第２実施形態では、充電制御部１４及び充電状態判定部１３は、第１実施形態で説明された処理に加えて、充電に係るイベントのログを記録し、ユーザの就寝時間帯を予測する処理を行う。

充電制御部１４は、充電に係るイベントの発生を検出し、充電状態判定部１３に通知する。充電に係るイベントには、例えば、充電開始，満充電状態になること，充電終了がある。充電終了は、例えば、充電器のコネクタが携帯端末１から抜かれることが検出されることによって検出される。ワイヤレス給電の場合には、充電終了は、例えば、携帯端末１が充電器から離されることによって、送電ユニットからの磁界を検出しなくなったことによって検出される。

充電状態判定部１３は、充電制御部１４からの充電に係るイベントの発生の通知を受けて、該イベントの発生を、充電ログとして、発生時刻と共に、充電状況記憶部１５に記録する。充電開始，満充電状態，充電終了のイベントの発生時刻を、それぞれ、充電開始時刻，満充電時刻，充電終了時刻と称する。

充電状態判定部１３は、以下（条件１）、（条件２）を満たす充電開始時刻を充電ログから抽出する。
（条件１）
充電開始時刻＜満充電時刻＜充電終了時刻である。
（条件２）
充電終了時刻と満充電時刻との差分が、Ｎ時間以上である。Ｎ時間は、アップデート処理が行われるための十分な時間であって、例えば、1時間以上である。

上記（条件１）、（条件２）は、ユーザが携帯端末１を満充電後所定時間放置している状況を抽出するための条件である。第２実施形態では、（条件１）、（条件２）を満たす状況を、就寝中に充電が行われる状況とみなす。なお、（条件１）、（条件２）で用いられる満充電時刻と充電終了時刻とは、充電開始時刻の直後に発生した満充電状態イベントと充電終了イベントの発生時刻である。

充電状態判定部１３は、抽出された充電開始時刻に基づいて、ユーザの就寝予測時間帯を取得する。例えば、充電状態判定部１３は、就寝予測時間帯として、（条件１）、（条件２）を満たす充電開始時刻の統計値の前後Ｍ時間を求める。統計値は、例えば、（条件１）、（条件２）を満たす最新の複数の充電開始時刻の平均値，中央値等である。また、これに限られず、就寝予測時間帯は、（条件１）、（条件２）を満たす最新の充電開始時
刻の前後Ｍ時間であってもよい。Ｍ時間は、例えば、０．５−１時間である。また、（条件１）、（条件２）を満たす充電開始時刻の統計値がＸ時Ｙ分であるとすると、就寝予測時間帯は、Ｘ時０分からＸ時５９分として取得されてもよい。

充電状態判定部１３は、取得した就寝予測時間帯を充電状況記憶部１５に格納する。就寝予測時間帯は、所定の周期で取得されて上書きされてもよいし、充電に係るイベントの発生の通知を受ける度に取得されて上書きされてもよい。

アップデート制御部１１は、充電開始イベントの発生の通知を受けると、現在時刻が就寝予測時間帯に含まれるか否かを判定し、現在時刻が就寝予測時間帯に含まれる場合に、ユーザに対してアップデートの通知を行う。ユーザによってアップデート開始が選択されると、アップデート制御部１１は、アップデート処理を実行する。

充電状況記憶部１５は、アップデート通知プログラムのインストール又はＣＰＵ １０１による実行によって、記憶部１０２のＲＡＭ １０２Ｂの記憶領域に作成される。充電状況記憶部１５には、充電に係るイベントと発生時刻とである充電ログと、就寝予測時間帯とが格納される。

＜処理の流れ＞
図４は、第２実施形態における、アップデート通知プログラムの一部の処理のフローチャートの一例である。図４に示されるフローチャートは、例えば、充電開始イベントが検出された場合に開始される。

ＯＰ１１では、図３のＯＰ１と同様に、アップデート制御部１１は、アップデートデータが存在するか否かを判定する。アップデートデータが存在する場合には（ＯＰ１１：ＹＥＳ）、処理がＯＰ１２に進む。アップデートデータが存在しない場合には（ＯＰ１１：ＮＯ）、図４に示される処理が終了する。

ＯＰ１２では、アップデート制御部１１は、現在時刻を取得する。この現在時刻は、今回の充電開始時刻である。なお、時刻は、例えば、携帯端末１が備える内部時計（図示せず）によって取得され、該内部時計は、定期的にネットワーク経由で同期が取られている。次に処理がＯＰ１３に進む。

ＯＰ１３では、アップデート制御部１１は、現在時刻が、充電状況記憶部１５に格納される就寝予測時間帯に含まれるか否かを判定する。現在時刻が就寝予測時間帯に含まれる場合には（ＯＰ１３：ＹＥＳ）、処理がＯＰ１４に進む。現在時刻が就寝予測時間帯に含まれない場合には（ＯＰ１３：ＮＯ）、ユーザが就寝しないことが予測され、現在の状況がアップデートに適した状況でないため、アップデートの通知も処理も行われず、図４に示される処理が終了する。

ＯＰ１４では、ユーザが就寝中に充電を行う状況であることが予測され、アップデートに適した状況であるので、アップデート制御部１１は、ユーザ表示部１６に、アップデートの存在の通知を指示する。ユーザ表示部１６は、アップデート制御部１１からの指示を受けて、表示部１０４にアップデート通知用の画面を表示し、アップデートを開始するようユーザを誘導する。

以降、図３に示されるＯＰ３に処理が進み、ユーザによってアップデートの開始が選択され（ＯＰ３：ＹＥＳ）、バッテリ１１０の充電量が所定量以上になると（ＯＰ５：ＹＥＳ）、アップデート処理が開始される。

＜第２実施形態の作用効果＞
第２実施形態では、携帯端末１は、充電に係るイベントのログを記録し、該ログから志ユーザの就寝予測時間帯を取得し、充電開始のイベント発生の時刻が就寝予測時間帯に含まれる場合に、アップデートの通知を行う。これによって、アップデートの通知が、ユーザが充電を開始する度に行われるのではなく、就寝前に充電を開始した場合に行われるようになる。そのため、アップデートに適した状況において、適切なタイミングでユーザにアップデートを通知することができ、さらに、アップデートの通知によってユーザに与える煩わしさを軽減することができる。

＜第３実施形態＞
アップデート処理には、アップデートデータのダウンロード処理と、アップデートデータによるソフトウェアのデータの書き換え処理と、が含まれる。アップデート処理のうち、ソフトウェアのデータの書き換え処理は、一旦開始されると終了するまでその他の機能が使えなくなり、中断されると重大な影響を及ぼす可能性が有るため、上記１）、３）を満たす状況下で行われることが好ましい。一方、アップデートデータのダウンロード処理は、２）ネットワークに接続可能な環境であればよく、中断されたとしても、再度最初から開始すればよく、他の機能に影響を与えることはない。

第３実施形態では、携帯端末１は、ネットワークに接続した際に、アップデートデータの有無を確認し、ユーザにアップデートの通知を行う。ユーザによってアップデートが選択された場合には、携帯端末１は、各種確認事項に対するユーザの確認を取り、アップデートデータのダウンロード処理を行う。その後、充電開始された場合に、携帯端末１は、予めダウンロードしたアップデートデータを用いてソフトウェアのデータの書き換え処理を行う。なお、第３実施形態では、第１実施形態及び第２実施形態と重複する説明は省略される。

第３実施形態において、携帯端末１のハードウェア構成と機能ブロックとは、それぞれ、図１、図２に示される通りである。

第３実施形態では、アップデート制御部１１は、携帯端末１が所定のネットワークに接続した場合に、通信部１２にアップデートデータの有無の問合せを指示する。所定のネットワークとは、アップデートデータの有無の確認によって、例えば、携帯端末１の他の機能やネットワークに与える負荷が小さいネットワークである。ただし、これに限られず、携帯端末１が利用可能な無線ネットワークであればよい。携帯端末１のネットワークへの接続は、無線部１０５によって検出される。また、アップデート制御部１１は、充電開始のイベントの発生が通知されると、予めダウンロードされたアップデートデータを用いたソフトウェアの書き換え処理を開始する。

＜処理の流れ＞
図５及び図６は、それぞれ、第３実施形態におけるアップデート通知プログラムの一部の処理のフローチャートの一例である。図５に示されるフローチャートは、例えば、所定のネットワークへの接続が検出された場合に開始される。

ＯＰ２１では、アップデート制御部１１は、アップデートデータが存在するか否かを判定する。アップデートデータが存在する場合には（ＯＰ２１：ＹＥＳ）、処理がＯＰ２２に進む。アップデートデータが存在しない場合には（ＯＰ２１：ＮＯ）、図５に示される処理が終了する。

ＯＰ２２では、アップデート制御部１１は、ユーザ表示部１６に、アップデートの存在の通知を指示する。ユーザ表示部１６は、アップデート制御部１１からの指示を受けて、
表示部１０４にアップデート通知用の画面を表示し、アップデートを開始するようユーザを誘導する。次に処理がＯＰ２３に進む。

ＯＰ２３では、アップデート制御部１１は、ユーザによって、アップデート開始が選択されたか否かを判定する。ユーザによってアップデート開始が選択された場合には（ＯＰ２３：ＹＥＳ）、処理がＯＰ２４に進む。ユーザによってアップデートの開始が選択されなかった場合、例えば、アップデートの開始の拒否が選択された場合には（ＯＰ２３：ＮＯ）、図５に示される処理が終了する。

ＯＰ２４では、アップデート制御部１１は、アップデートの対象となるソフトウェアに関する使用許諾，注意事項等の事前確認事項を表示するように、ユーザ表示部１６に指示する。ユーザ表示部１６は、アップデート制御部１１の指示を受けて、各種事前確認用の画面を表示部１０４に表示する。アップデート制御部１１は、各種事前確認事項の確認結果を問合せ結果保持部１９に格納する。次に、処理がＯＰ２５に進む。

ＯＰ２５では、アップデート制御部１１は、通信部１２にアップデートデータのダウンロードを指示する。通信部１２は、アップデートデータを所定のサーバからダウンロードして、アップデート用データ保持部１８に格納する。

ＯＰ２６では、通信部１２は、アップデートデータのダウンロード処理の終了後、問合せ結果保持部１９に「アップデートデータ有り」の情報を記録する。その後、図５に示される処理が終了する。

図６に示されるフローチャートは、例えば、充電開始のイベントの発生が検出された場合に開始される。

ＯＰ３１では、アップデート制御部１１は、アップデートデータを保持しているか否かを判定する。この判定は、例えば、問合せ結果保持部１９に「アップデートデータ有り」の情報が格納されているか否かを判定することによって行われる。アップデートデータを保持している場合には（ＯＰ３１：ＹＥＳ）、処理がＯＰ３２に進む。アップデートデータを保持していない場合には（ＯＰ３１：ＮＯ）、アップデート処理は行われず、図６に示される処理が終了する。

ＯＰ３２では、アップデート制御部１１は、アップデート制御部１１は、ユーザ表示部１６に、アップデートの存在の通知を指示する。ユーザ表示部１６は、アップデート制御部１１からの指示を受けて、表示部１０４にアップデート通知用の画面を表示し、アップデート（ソフトウェアの書き換え処理）を開始するようユーザを誘導する。次に処理がＯＰ３３に進む。

ＯＰ３３では、アップデート制御部１１は、バッテリ１１０の充電量が所定の閾値以上であるか否かを判定する。バッテリ１１０の充電量が所定の閾値以上である場合には（ＯＰ３３：ＹＥＳ）、処理がＯＰ３４に進む。バッテリ１１０の充電量が所定の閾値未満である場合には（ＯＰ３３：ＮＯ）、処理がＯＰ３５に進む。

ＯＰ３４では、アップデート制御部１１は、バッテリ１１０の充電量が所定の閾値以上であり、アップデートを実行するのに十分な量であるので、アップデート用データ保持部１８に格納されるアップデートデータを用いてソフトウェアの書き換え処理を実行する。その後、図６に示される処理が終了する。

ＯＰ３５では、アップデート制御部１１は、バッテリ１１０の充電量が所定の閾値未満
であり、アップデートを実行するのに十分な量でないため、所定の周期で充電状態判定部１３にＯＰ３３の判定の指示を出し、バッテリ１１０の充電量を監視する。アップデート制御部１１は、充電状態判定部１３から、バッテリ１１０の充電量が所定の閾値以上であるとの判定結果を受けると、アップデートの開始を通信部１２に指示する。その後、図６に示される処理が終了する。

なお、ＯＰ３２において、アップデートの通知を再度行うことによって、ユーザからアップデートの許諾を受け取った後、時間が経過している可能性がある場合に、ユーザの注意を促すことができる。なお、ＯＰ３２におけるアップデートの通知は、省略されてもよい。

＜第３実施形態の作用効果＞
第３実施形態では、携帯端末１は、所定のネットワークに接続し、アップデートデータが有る場合には、ユーザに通知し、先行してアップデートデータをダウンロードする。その後、充電開始のイベントの発生を検出した場合に、携帯端末１は、ユーザに通知し、予めダウンロードしたアップデートデータを用いてソフトウェアの書き換え処理を行う。これによって、アップデートの処理に含まれる「アップデートデータのダウンロード処理」と「ソフトウェアの書き換え処理」の２段階の処理について、それぞれの処理に適したタイミングでユーザにアップデートを通知、誘導することができる。また、予めアップデートデータをダウンロードすることによって、充電中のアップデート処理に係る時間を短縮することができ、満充電状態になった時から充電終了までの時間が短くなった場合でも、アップデートのエラーの発生を低減させることができる。

＜第４実施形態＞
第４実施形態では、携帯端末１に対するアップデートの通知が、例えば、ＳＭＳ（Short Message Service）によって行われる場合に、このＳＭＳによる通知を受けたことを契
機に、携帯端末１はアップデートデータのダウンロードを行う。その後、充電開始のイベントの発生を検出した場合に、携帯端末１は、ユーザに対する通知を行い、予めダウンロードしたアップデートデータを用いて、ソフトウェアの書き換え処理を実行する。なお、第４実施形態では、第１−第３実施形態と重複する説明は省略される。

第４実施形態において、携帯端末１のハードウェア構成と機能ブロックとは、それぞれ、図１、図２に示される通りである。

第４実施形態では、通信部１２は、アップデートデータの存在を通知するＳＭＳメッセージを受信すると、アップデート制御部１１に通知する。アップデート制御部１１は、この通知を受けて、通信部１２に、アップデートデータのダウンロード処理の開始を指示する。通信部１２は、アップデート制御部１１からの指示を受けて、所定のサーバからアップデートデータをダウンロードし、アップデート用データ保持部１８に格納する。また、通信部１２は、問合せ結果保持部１９に、「アップデートデータ有り」の情報を格納する。

アップデート制御部１１は、充電開始のイベントの発生が通知されると、予めダウンロードされたアップデートデータを用いたソフトウェアの書き換え処理を開始する。

＜処理の流れ＞
図７は、第４実施形態におけるアップデート通知プログラムの一部の処理のフローチャートの一例である。図７に示されるフローチャートは、例えば、アップデートデータの存在を通知するＳＭＳメッセージの受信によって開始される。

ＯＰ４１では、アップデート制御部１１は、通信部１２にアップデートデータのダウンロードを指示する。通信部１２は、アップデートデータを所定のサーバからダウンロードして、アップデート用データ保持部１８に格納する。

ＯＰ４２では、通信部１２は、アップデートデータのダウンロード処理の終了後、問合せ結果保持部１９に「アップデートデータ有り」の情報を記録する。その後、図７に示される処理が終了する。

図７の処理の終了後、充電開始のイベントの発生が検出された場合には、図６の処理が開始される。すなわち、ユーザに対してアップデートの通知が行われ、バッテリ１１０の充電量が所定の閾値以上になった場合に、予めダウンロードされたアップデートデータを用いたソフトウェアの書き換え処理が行われる。尚、図７に示される処理は、ユーザに通知されることなく、バックグラウンドで実行される。

＜第４実施形態の作用効果＞
第４実施形態では、携帯端末１は、アップデートデータの存在を通知するＳＭＳメッセージを受信すると、アップデートデータのダウンロード処理を行い、その後、充電開始されたタイミングでアップデートの通知を行い、ソフトウェアの書き換え処理を実行する。これによって、充電開始の適したタイミングで、アップデートをユーザに通知することフができる。予めアップデートデータをダウンロードすることによって、充電中のアップデート処理に係る時間を短縮することができ、満充電状態になった時から充電終了までの時間が短くなった場合でも、アップデートのエラーの発生を低減させることができる。

なお、第４実施形態では、ネットワークからのアップデートデータの存在の通知がＳＭＳによって行われる例について説明したが、ネットワークからの通知の方法は、ＳＭＳに限られない。例えば、電子メール等であってもよい。

＜その他＞
第１−第４実施形態は、それぞれ組み合わせて実施されてもよい。例えば、第２実施形態と第３実施形態又は第４実施形態とを組み合わせて、携帯端末１は、予めアップデートデータをダウンロードし、充電開始された時刻が就寝予測時間帯である場合に、ソフトウェアのデータの書き換え処理を実行するようにしてもよい。

１ 携帯端末
１１ アップデート制御部
１２ 通信部
１３ 充電状態判定部
１４ 充電制御部
１５ 充電状況記憶部
１６ ユーザ表示部
１７ 操作入力部
１８ アップデート用データ保持部
１９ 問合せ結果保持部

Claims (7)

1. 充電池とプロセッサとを備える情報処理装置であって、
   前記プロセッサは、
   前記充電池の充電開始を検出し、
   前記充電開始が検出された場合に、ユーザに所定のソフトウェアのアップデートの実行を通知する、
   情報処理装置。
2. 前記プロセッサは、
   前記ユーザによって前記所定のソフトウェアのアップデートが許可された場合に、前記充電池が所定の充電量未満であるか否かを判定し、
   前記充電池が前記所定の充電量以上である場合には、前記所定のソフトウェアのアップデートデータを用いた書き換え処理を開始し、前記充電量が前記所定の充電量未満である場合には、前記充電池が所定の充電量以上になるまで、前記所定のソフトウェアのアップデートデータを用いた書き換え処理を遅延させる、
   請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記充電開始が検出された時刻が、所定の時間帯に含まれる場合に、ユーザに、前記所定のソフトウェアのアップデートの実行を通知する、
   請求項１又は２に記載の情報処理装置。
4. 前記プロセッサは、
   充電開始時刻，満充電となる時刻，充電終了時刻を前記メモリに記録し、
   前記メモリに保持される充電開始時刻，満充電となる時刻，充電終了時刻から、該情報処理装置が所定時間放置されるような充電が開始される時間帯を、前記所定時間帯として取得する、
   請求項３に記載の情報処理装置。
5. 前記プロセッサは、
   前記充電池の充電開始の検出に先だって、アップデートデータの存在が検出された場合に、前記アップデートデータをダウンロードし、前記メモリに格納する、
   請求項１から４のいずれか一項に記載の情報処理装置。
6. 充電池とプロセッサとを備える情報処理装置が実行する情報処理方法であって、
   前記プロセッサが、
   前記充電池の充電開始を検出し、
   前記充電開始が検出された場合に、ユーザに所定のソフトウェアのアップデートの実行を通知する、
   情報処理方法。
7. 充電池とを備える情報処理装置に、
   前記充電池の充電開始を検出させ、
   前記充電開始が検出された場合に、ユーザに所定のソフトウェアのアップデートの実行を通知させる、
   ための情報処理プログラム。

Images