(58)【調査した分野】(Int.Cl.,DB名)
前記更新準備手段は、前記低消費電力状態では通電されていないハードウェアコンポーネントであって、前記更新の書き込み対象となるハードウェアコンポーネントへの通電を開始し、
前記更新インストール手段は、前記更新準備手段によって通電された前記ハードウェアコンポーネントにかかる書き込みを伴うシステム更新インストールを実行する、請求項1に記載の情報処理装置。
前記情報処理装置は、前記更新インストール手段によるシステム更新インストールの終了後、ユーザの操作を求めることなく、更新後のシステムによる前記情報処理装置の動作を開始する、請求項1に記載の情報処理装置。
前記情報処理装置は、前記更新インストール手段による更新インストール後、前記情報処理装置をシャットダウンする処理を実行するシャットダウン手段を更に備える、請求項1に記載の情報処理装置。
前記情報処理装置は、前記シャットダウン手段によりシャットダウンされた後、当該情報処理装置の動作状態を前記低消費電力状態に自動的に切り替える、請求項4に記載の情報処理装置。
前記情報処理装置は、前記更新確認手段、更新準備手段、および更新インストール手段による一連の処理の間、当該処理にかかる映像音声信号の外部機器への出力は行わない、請求項1に記載の情報処理装置。
前記システムソフトウェアは前記第1の種類のソフトウェアに属し、当該システムソフトウェア以外のアプリケーションは前記第2の種類のソフトウェアに属する、請求項8に記載の情報処理装置。
前記低消費電力状態であるか、前記更新インストール手段による処理が行われる状態であるかに応じて、前記ハードウェアコンポーネントの通電時における動作状態を変更する、動作状態変更手段を更に備える、請求項1に記載の情報処理装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のような情報処理装置では、情報処理装置の消費電力(動作モード)の観点からみると、ダウンロードするときの消費電力と、インストールするときの消費電力はほぼ同じであった。
【0005】
それ故に、本発明の目的は、自動的にダウンロードおよびインストールを行う際の情報処理装置の消費電力をより軽減することができ、更に、ダウンロードおよびインストールの利便性を向上できる情報処理装置等を提供することである。
【課題を解決するための手段】
【0006】
上記目的を達成するために、例えば以下のような構成例が挙げられる。
【0007】
構成例の一例は、ネットワークを介して外部装置と通信可能な情報処理装置であって、当該情報処理装置は、本装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも2つの動作状態を切り替えて動作可能である。そして、当該情報処理装置は、更新確認手段と、更新準備手段と、更新インストール手段とを備える。更新確認手段は、低消費電力状態において、ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する。更新準備手段は、更新が存在する場合、所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始を行う。更新インストール手段は、ダウンロードした更新データに基づいて、システムの更新インストールを実行する。更に、更新確認手段、更新準備手段、更新インストール手段による一連の処理は、ユーザの操作によることなく自動的に実行される。
【0008】
上記構成例によれば、情報処理装置の消費電力を抑えつつも、当該情報処理装置のシステムの更新処理を実行させることができ、ユーザの利便性を高めることが可能となる。
【0009】
他の構成例として、更新準備手段は、低消費電力状態では通電されていないハードウェアコンポーネントであって、更新の書き込み対象となるハードウェアコンポーネントへの通電を開始し、更新インストール手段は、更新準備手段によって通電されたハードウェアコンポーネントにかかる書き込みを伴うシステム更新インストールを実行するようにしてもよい。
【0010】
上記構成例によれば、情報処理装置の消費電力を抑えながら、ハードウェアコンポーネントへの書き込みが必要なシステム更新を実行することができる。
【0011】
他の構成例として、更新準備手段による処理は低消費電力状態において実行されてもよい。
【0012】
上記構成例によれば、情報処理装置の消費電力をより低減することが可能となる。
【0013】
他の構成例として、情報処理装置は、更新インストール手段によるシステム更新インストールの終了後、ユーザの操作を求めることなく、更新後のシステムによる情報処理装置の動作を開始するような構成としてもよい。
【0014】
上記構成例によれば、ユーザの利便性を高めることができる。
【0015】
他の構成例として、情報処理装置は、更新インストール手段による更新インストール後、情報処理装置をシャットダウンする処理を実行するシャットダウン手段を更に備えていてもよい。更には、情報処理装置は、シャットダウン手段によりシャットダウンされた後、自動的に動作状態を低消費電力状態に切り替えるようにしてもよい。
【0016】
上記構成例によれば、情報処理装置の消費電力を抑えつつ、システムの更新およびその後の再起動まで行うことが可能となる。更には、一旦システム更新を行った後、引き続いてその後に発生する更新のチェック処理を実行でき、その自動的なダウンロードおよび更新インストール処理を行うことも可能となる。
【0017】
他の構成例として、情報処理装置は、ユーザの操作に基づいて情報処理装置の動作状態を前記通常使用状態以外の状態から通常使用状態へ切換えるためのユーザによる指示操作を受け付ける操作受付手段と、前記更新確認手段、更新準備手段、および更新インストール手段による一連の処理が行われている間に、操作受付手段が指示操作を受け付けたことに応じて、情報処理装置の動作状態を通常使用状態へ切替える通常状態移行手段とを更に備える構成としても良い。また、情報処理装置は、低消費電力状態においてダウンロードが行われている間に、操作受付手段がユーザによる指示操作を受け付けたときは、当該ダウンロード処理を中断するダウンロード中断手段と、動作状態が通常使用状態となった後、中断したダウンロードを再開する再開手段とを更に備える構成としても良い。また、再開手段は、動作状態が通常使用状態になった後、バックグラウンド処理としてダウンロードを再開してもよい。更には、更新インストール手段によるシステムの更新インストール処理中に、操作受付手段がユーザによる指示操作を受け付けたときは、通常状態移行手段は、当該システムの更新インストール処理を継続しながら通常使用状態への切替えを行うようにしてもよい。
【0018】
上記構成例によれば、ダウンロード処理については一旦中断し、その後再開することでユーザの利便性を確保しつつも、システム更新のような重要な処理については速やかに完了させることができる。
【0019】
他の構成例として、情報処理装置は、更新確認手段、更新準備手段、および更新インストール手段による一連の処理の間、当該処理にかかる映像音声信号の外部機器への出力は行わないように構成してもよい。
【0020】
上記構成例によれば、システム更新に係る処理を行っていることをユーザに気付かせることなく、当該処理を進行させることができる。
【0021】
他の構成例として、更新の対象となるソフトウェアには、第1の種類のソフトウェアと第2の種類のソフトウェアが含まれており、更新確認手段は、第1の種類のソフトウェアの更新の有無と、第2の種類のソフトウェアの更新の有無の双方を判定する判定手段を含み、更新準備手段および更新インストール手段による処理は、第1の種類のソフトウェアの更新があると判定されたときに実行されるように構成してもよい。更には、上記システムソフトウェアは第1の種類のソフトウェアに属し、当該システムソフトウェア以外のアプリケーションは第2の種類のソフトウェアに属していてもよい。
【0022】
上記構成例によれば、例えばシステムソフトウェアの更新が発生するときにのみ、その更新に必要な通電を行うため、総合的にみて、情報処理装置の消費電力をより軽減することができる。
【発明の効果】
【0023】
本実施形態によれば、システムの更新のダウンロードおよびインストールを行う際の情報処理装置の消費電力をより軽減することができる。また、ダウンロードおよびインストールの利便性も向上できる。
【発明を実施するための形態】
【0025】
以下、本発明の一実施形態について説明する。本実施形態では、情報処理システムの一例として、据え置き型のゲームシステムを例に挙げて説明する。
【0026】
[1.ゲームシステムの全体構成]
図1は、ゲームシステム1の外観図である。
図1において、ゲームシステム1は、テレビジョン受像器等に代表される据置型のディスプレイ装置(以下、「テレビ」と記載する)2、据置型のゲーム装置3、光ディスク4、コントローラ5を含む。ゲームシステム1は、コントローラ5を用いたゲーム操作に基づいてゲーム装置3においてゲーム処理を実行し、ゲーム処理によって得られるゲーム画像をテレビ2に表示するものである。
【0027】
ゲーム装置3には、当該ゲーム装置3に対して交換可能に用いられる情報記憶媒体の一例である光ディスク4が脱着可能に挿入される。光ディスク4には、ゲーム装置3において実行されるための情報処理プログラム(典型的にはゲームプログラム)が記憶されている。ゲーム装置3の前面には光ディスク4の挿入口が設けられている。ゲーム装置3は、挿入口に挿入された光ディスク4に記憶されている情報処理プログラムを読み出して実行することによってゲーム処理を実行可能である。
【0028】
ゲーム装置3には、テレビ2が接続コードを介して接続される。テレビ2は、ゲーム装置3において実行されるゲーム処理によって得られるゲーム画像を表示する。テレビ2はスピーカ2Lおよび2Rを有しており、スピーカ2Lおよび2Rは、上記ゲーム処理の結果得られるゲーム音声を出力する。なお、他の実施形態においては、ゲーム装置3と据置型の表示装置とは一体となっていてもよい。また、ゲーム装置3とテレビ2との通信は無線通信であってもよい。
【0029】
コントローラ5は、自機に対して行われた操作の内容を表す操作データをゲーム装置3に与えるものである。コントローラ5とゲーム装置3とは所定の無線通信によって通信可能である。なお、他の実施形態においてはコントローラ5とゲーム装置3とは有線で接続されてもよい。
【0030】
[2.ゲーム装置3の内部構成]
次に、
図2を参照して、ゲーム装置3の内部構成について説明する。
図2は、ゲーム装置3の内部構成を示すブロック図である。ゲーム装置3は、CPU(Central Processing Unit)11、メインメモリ12、フラッシュメモリ14、無線通信部15、コントローラ通信部16、ディスクドライブ17、電源制御部18、AV−IC19、GPU20、およびDSP21等を有する。
【0031】
CPU11は、光ディスク4に記憶されたゲームプログラム等を実行することによってゲーム処理を実行するものであり、ゲームプロセッサとして機能する。なお、本実施形態では、CPU11は、いわゆるマルチコアプロセッサであるとする。具体的には、3コアのプロセッサであるとする。もちろん、他の実施形態では、コア数は3に限るものではないことや、マルチコアでなくてもよいことはいうまでもない。
【0032】
CPU11には、メインメモリ12、フラッシュメモリ14、無線通信部15,コントローラ通信部16、ディスクドライブ17、電源制御部18、GPU20、DSP21が接続される。また、GPU20およびDSP21は、AV-IC19にも接続される。揮発性のメインメモリ12は、光ディスク4から読み出されたゲームプログラムや、フラッシュメモリ14から読み出されたゲームプログラム等のプログラムを記憶したり、各種データを記憶したりするものであり、CPU11のワーク領域やバッファ領域として用いられる。ディスクドライブ17は、光ディスク4からプログラムデータ等を読み出し、メインメモリ12に読み出したデータを書き込む。
【0033】
GPU20は、描画手段の一部を形成し、CPU11からのグラフィクスコマンド(作画命令)に従って画像を生成する。
【0034】
DSP21は、オーディオプロセッサとして機能し、外部メインメモリ12に記憶されるサウンドデータや音波形(音色)データを用いて、音声データを生成する。
【0035】
上記のようにゲーム装置3において生成される画像および音声のうちで、テレビ2において出力される画像および音声のデータは、AV−IC19によって読み出される。AV−IC19は、読み出した画像データを図示しないAVコネクタを介してテレビ2に出力するとともに、読み出した音声データを、テレビ2に内蔵されるスピーカ2Lおよび2Rに出力する。これによって、テレビ2に画像が表示されるとともにスピーカ2Lおよび2Rから音が出力される。
【0036】
ゲーム装置3は、インターネット等のネットワークに接続して外部情報処理装置(例えば他のゲーム装置や、各種サーバ等)と通信を行うことが可能である。すなわち、CPU11は、無線通信部15を介してインターネット等のネットワークに接続し、ネットワークに接続される外部情報処理装置と通信することができる。CPU11は、定期的にフラッシュメモリ14にアクセスし、ネットワークへ送信する必要があるデータの有無を検出し、当該データが有る場合には、無線通信部15を介してネットワークに送信する。また、CPU11は、外部情報処理装置から送信されてくるデータや所定のサーバからダウンロードしたデータを、ネットワークおよび無線通信部15を介して受信し、受信したデータをフラッシュメモリ14に記憶する。
【0037】
また、ゲーム装置3は、コントローラ通信部16を介して、コントローラ5からの操作データを受信することが可能である。すなわち、CPU11は、コントローラ5から送信される操作データをコントローラ通信部16を介して受信し、メインメモリ12に記憶(一時記憶)する。なお、本実施形態では、当該コントローラ通信部16は2つの動作モードを有している。一つは、通常動作を行う通常動作モードであり、もう一つは、低電力にて動作する低電力モードである。詳細は後述するが、ゲーム装置3がノーマルモードで動作しているときは、通常動作モードで動作する。また、低消費電力モードで動作しているときは、コントローラ通信部16は低電力モードとなる。そして、この低電力モードのときは、コントローラ通信部16は、コントローラ5に備えられている電源ボタンの操作のみ受け付けるという動作を行う。
【0038】
電源制御部18は、RTC(Real Time Clock)を含み、時間を計測することが可能である。後述するゲーム装置3の動作モードを所定のタイムスケジュールに従って変更するために、電源制御部18で計測される時間が用いられる。また、電源制御部18は、ゲーム装置3の各部に対する給電を制御する。例えば、電源制御部18は、計測された時間に基づいてCPU11の起動を制御する。
【0039】
なお、本実施形態においては、ゲーム装置3(の各部)は、外部電源から取得される電力で動作する。電源制御部18は、外部電源からの電力をゲーム装置3の各部に対して供給する。例えば、ゲーム装置3は、家庭用電源からACアダプタ(図示せず)を介して電力を取得してもよい。また、他の実施形態においては、ゲーム装置3は、内部電源(バッテリ等)から取得される電力で動作してもよい。
【0040】
その他、図示は省略するが、上記以外のハードウェアコンポーネント(モジュール)も実装されている(例えば、Bluetooth(登録商標)モジュール等)。ここで、これらのハードウェアコンポーネントの中には、そのコンポーネントを制御するための制御プログラムが書き込まれたチップ(マイコン)を搭載するものが含まれる。また、このチップは、書き換え可能に構成されているものとする。本実施形態では、システム更新処理の一環として、このようなチップの書き換えも行う。
【0041】
次に、コントローラ5について説明する。
図1で示したコントローラ5は、ゲーム装置3と無線で接続される。コントローラ5は、複数の操作ボタンを有しており、ユーザの各種操作を受け付け可能である。なお、
図1で示したようなコントローラの他、例えば、
図3に示すような、LCD71やタッチパネル72を有するコントローラを利用する構成であっても良い。
【0042】
次に、本実施形態にかかるゲーム装置3で実行される情報処理の動作概要を説明する。本実施形態にかかる処理は、主に、ゲーム装置3の電源がオフとなっている間に、システム更新を行う処理である。なお、システム更新のための更新データの入手手法について、本実施形態では、ゲーム装置3は、所定のサーバからダウンロードすることで取得する。すなわち、ゲーム装置3は、所定のサーバに更新データの有無を問い合わせる。そして、存在する場合は更新用のデータをダウンロードする(なお、本実施形態では、システム以外のアプリケーションの更新の有無についても、これに併せて問い合わせている)。そして、ダウンロードした更新用データを用いてシステム更新を行う。
【0043】
まず、本実施形態におけるゲーム装置3の動作状態(動作モード)について説明する。まず、本実施形態のゲーム装置3の動作状態としては、ユーザからの観点でいうと、電源オンである状態(以下、電源オン状態)と電源がオフである状態(以下、電源オフ状態)とがある。電源オン状態は、主にユーザがゲームをプレイしている等、ゲーム装置3を使用している状態ともいえる。換言すれば、ユーザから見て、ゲーム装置3の電源がオンになっていると認識されるような状態である。一方、電源オフ状態は、ユーザから見て「電源がオフ」と認識できる状態であり、かつ、AC電力の供給が可能な状態であるとする。つまり、ACアダプタ等はコンセントにささっている状態であるとする。あるいは、ゲーム装置3がバッテリーで動作するタイプのものであれば、ゲーム装置3の動作に必要な最低限以上のバッテリー残量が残っている状態であるとする。
【0044】
上記電源オン状態におけるゲーム装置3の動作モードのことを、ノーマルモードと呼ぶ。ノーマルモードは、全てのハードウェアコンポーネントに通電している状態である。また、テレビ2への映像・音声信号の出力もなされている。
【0045】
一方、電源オフ状態のときの動作モード(換言すれば、ゲーム装置3の通電状況)としては、スタンバイモード、低消費電力モード、そして、システム更新モードの3つがある。電源オフ状態のときは、基本的には、ゲーム装置3は、スタンバイモードと低消費電力モードの2つのモードを所定のタイムスケジュールに基づいて切換えながら動作している。より具体的には、電源オフ状態の時の動作モードは基本的にはスタンバイモードであるが、間欠的に低消費電力モードが立ち上がるような制御が行われる。更に、所定の条件下では、後述するシステム更新モードで動作する場合もある。
【0046】
スタンバイモードでは、電源制御部18のみ通電している状態であり、その他の各ハードウェアコンポーネントへの通電は行われていない。このモードでは、電源ボタンによる電源オンの操作のみ受け付けている状態となっている。上記スタンバイモードは、いわば待機電力で動作している待機状態ともいえる。
【0047】
一方、低消費電力モードでは、ゲーム装置3を構成するハードウェアコンポーネントのうち、CPU11を含む一部のハードウェアコンポーネントにのみ通電がなされている。つまり、スタンバイモードよりも消費電力は大きいが、ノーマルモードに比べると消費電力は小さい状態である。また、CPU11にも通電されているため、CPU11による情報処理も可能な状態である。ここで、当該低消費電力モードにおいて実行される処理として、本実施形態では、システムやアプリケーションの更新が存在するか否か(更新が発生しているか否か)をチェックする処理がある。更に、更新が存在する場合は、所定のサーバからその更新データをダウンロードする処理も行われる。つまり、ユーザから見てゲーム装置3の電源が切れているオフの間に、例えばシステムやアプリケーションの更新データのダウンロードを済ませておく、というような動作を行う。そして、低消費電力モードでは、このようなダウンロード処理に必要なハードウェアコンポーネントのみ通電されている状態となっている。具体的には、本実施形態では、CPU11、メインメモリ12、フラッシュメモリ14、無線通信部15、コントローラ通信部16および電源制御部18に通電されているものとする。ここで、CPU11に関して、本実施形態では、上記のように3コアのマルチプロセッサである。そして、この低消費電力モードにおいては、CPU11は、1コアのみで動作するものとする。また、このとき、更に、CPU11の動作クロック数を落として動作させるようにしても良い。また、コントローラ通信部16に関して、上述のようにコントローラ通信部16は2つの動作モードを有している。そして、当該低消費電力モードのときは、コントローラ5の電源オン操作のみ受付け可能な低電力モードで動作している。つまり、当該低消費電力モードは、上記ダウンロード処理に必要最低限の電力のみ供給し、それ以外のハードウェアコンポーネントへは通電しないようにして、できるだけ電力消費を抑えている動作モードといえる。
【0048】
そして、本実施形態では、電源オフ状態では、基本的には、
図4で示すような制御が行われる。
図4は、電源オフ状態でのゲーム装置3の基本的な動作モードを説明するための図である。まず、ノーマルモードで動作中に電源オフ操作(シャットダウン操作)が行われることで、ノーマルモードからスタンバイモードに移行する(スタンバイモードへの移行は、いわゆるシャットダウン処理に相当する)。その後、所定時間が経過すると、低消費電力モードに移行する。この低消費電力モードにおいて、上記更新のチェック処理や、(更新があるときは)ダウンロード処理等が実行される。これらの処理が完了した後、低消費電力モードからスタンバイモードに移行する。その後、所定時間が経過すると、低消費電力モードに移行し、その後、またスタンバイモードに移行する。このように、電源オフ時は、スタンバイモードをベースとしつつ、所定のタイムスケジュールに従って低消費電力モードに間欠的に切り替わる。
【0049】
ここで、低消費電力モードにおいてダウンロードされるデータには、ゲーム装置3のシステム更新用のデータパッケージ(以下、更新パッケージと呼ぶ)が含まれる。この更新パッケージの適用について、従来では、上記低消費電力モードで更新パッケージのダウンロードを完了させ、その後、ゲーム装置3がノーマルモードで起動したときにシステム更新を行う、という手法が知られている。しかし、この手法の場合、ユーザにとっては、更新が終わるまでの待ち時間が発生することになる。特に、長期間ゲーム装置3の電源をオンにしておらず、久しぶりに電源をオンしたような場合であって、複数の更新が溜まっているような場合に、これらの更新が全て適用されるまでの待ち時間が大きくなってしまうことが考えられる。そのため、本実施形態では、ゲーム装置3が電源オフ状態である間に、システム更新も済ませてしまおうというものである。
【0050】
ところで、上述のように、低消費電力モードでは、できるだけ消費電力を下げるために、必要最低限のハードウェアコンポーネントしか通電されていない。その一方で、上記更新パッケージには、所定のハードウェアコンポーネントのチップ書き換えが発生するような更新も含まれる場合がある(例えば、所定のハードウェアコンポーネントに搭載されているマイコン等の制御プログラムの更新)。そして、この更新対象となる所定のハードウェアコンポーネントが、低消費電力モードにおいては通電されていないような場合、低消費電力モードの状態では、上記チップの書き換え処理を実行することができず、システム更新ができない。(上記コントローラ通信部16についても、上記低電力モードの状態では、当該コントローラ通信部16のチップの書き換えができないものとする)このような場合、ゲーム装置3を低消費電力モードからノーマルモードに自動的に移行させて、システム更新を行うことも考えられる。しかし、このような制御を行うと、テレビ2への映像・音声信号の出力等もなされることになり、ユーザからみると、電源をオフにしたはずのゲーム装置が勝手に起動しているように見えてしまう。
【0051】
そこで、本実施形態では、ユーザにはゲーム装置3が電源オフ状態であると認識させつつも、ゲーム装置3の内部的には、システム更新に必要なハードウェアコンポーネントへの通電を行い、ハードウェア的にシステム更新が可能な状態である、システム更新モードというものを設けている。そして、このシステム更新モードに移行してからシステム更新処理を行う。つまり、ハードウェアコンポーネントへの電力供給や消費電力の観点からみると、システム更新モードは、ノーマルモードと低消費電力モードの間に位置するようなモードとなる。つまり、消費電力の大きい順に、ノーマルモード、システム更新モード、低消費電力モード、スタンバイモード、という関係となっている。システム更新モードでは、より具体的には、以下のような通電状況となる。まず、CPU11、メインメモリ12、フラッシュメモリ14、無線通信部15、電源制御部18、GPU20,DSP21については通電が行われる。また、コントローラ通信部16についても、上記通常動作モードで動作させる。また、CPU11は、ノーマルモードの場合と同様に、3コアとも利用可能な状態で動作する(CPU11の動作クロックもノーマルモードと同様である)。一方、ディスクドライブ17への通電はなされない(これにより、比較的騒音値が高いディスクの回転音が発生することを抑えることも可能となる)。また、GPU20による画像生成処理や映像の出力処理自体はなされるが、しかし、テレビ2への映像信号出力はなされない。つまり、ゲーム装置3からテレビ2への映像信号出力は行われない。いわば、映像信号が、AV−IC19のところでせき止められたような状態となる。また、音声に関しても同様である。その他、システム更新の対象となり得るハードウェアコンポーネントについても通電がなされる。
【0052】
上記のことから、低消費電力モードおよびシステム更新モードは、次のように捉えることもできる。すなわち、上記低消費電力モードでは、更新チェックおよびダウンロード処理が可能となるハードウェアコンポーネントに通電されていればよい。そして、システム更新モードでは、システム更新インストールが可能なハードウェアコンポーネントに通電されていればよい。そのため、他の実施形態では、低消費電力モード(ダウンロード処理)のときよりも、システム更新モード(システム更新インストール)における消費電力のほうが小さくなるような構成であってもよい。
【0053】
ここで、上記システム更新モードにおいて通電対象となるハードウェアコンポーネントについては、例えば、事前にシステム更新の対象となり得るハードウェアコンポーネントを洗い出しておき、システム更新モードにおける通電対象として構成しておくことが考えられる。そのため、もし、上記ディスクドライブ17もシステム更新の対象となり得る場合は、システム更新モードにおいてはディスクドライブ17にも通電するようにしてもよい。また、逆に、例えば、上記無線通信部15がシステム更新の対象とならない場合は、システム更新モードにおいては無線通信部15に通電しないような構成としても良い。更に言えば、システム更新モードでは、テレビ2等の外部装置への映像・音声出力だけが止められているだけで、その他の点については、結果的には実質的にノーマルモードと同様の通電状態・動作状態となっていてもよい。この場合でも、テレビ2への出力はオフの状態であるため、ユーザから見れば、見かけ上、ゲーム装置3は電源オフ状態と見える。また、少なくとも、AV−IC19にかかる消費電力は抑えることができる。
【0054】
また、コントローラ通信部16について、本実施形態では、上記のように通常動作モードと低電力モードとを有する場合を例示している。他の実施形態では、例えばコントローラ5に電源ボタンが搭載されていない場合、上記低電力モードは設けない構成としても良い。このような場合は、上記低消費電力モードやスタンバイモードではコントローラ通信部16への通電を行わないようにしてもよい。
【0055】
また、更に他の実施形態では、上記のような各ハードウェアコンポーネントに対して通電を行う/行わないという制御の他、各ハードウェアコンポーネントの動作状態を変更する、という制御を行うようにしてもよい。例えば、上記のようなコントローラ通信部16でいうと、上記システム更新モードであるか低消費電力モードであるかに応じて、通常動作モードと低電力モードとを切換える制御や、後述の冷却用のファンの回転数を変化させるような制御を行っても良い。つまり、各ハードウェアコンポーネントについて、通電はしている状態であるが、より消費電力を抑えて動作させることが可能なもの(動作状態を変更できるもの)である場合、消費電力を抑えて動作する動作状態に適宜切換えるような制御を行っても良い。
【0056】
なお、上記
図2では図示を省略しているが、ゲーム装置3には、本体の動作モードを示すためのLEDも実装されている。そして、本実施形態では、当該LEDについて、例えばノーマルモードでは青色で点灯させ、スタンバイモードでは赤色で点灯させ、低消費電力モードではオレンジ色で点灯させるとする。この場合、上記システム更新モードでは、低消費電力モードと同じくオレンジ色で点灯させる。つまり、システム更新モードは、見た目は低消費電力モードのように見せかける。なお、他の実施形態では、例えばスタンバイモード、低消費電力モード、システム更新モード共に同じ色(例えば赤色)で点灯させるようにしてもよい。
【0057】
また、ゲーム装置3には、冷却用のファンが搭載されていてもよい。そして、このファンの回転に関しては、低消費電力モードでは、ノーマルモードの時よりも回転数を落として動作させてもよい。低消費電力モードでは、ノーマルモードの時よりも発熱が少なくなると考えられるためである。一方、システム更新モードでは、ノーマルモードと同様の回転数で動作させればよい。低消費電力モードの時よりは発熱も多くなり、場合によっては、ノーマルモードの場合と同じくらいの発熱になり得るためである。
【0058】
ここで、
図5を用いて、上記ゲーム装置3の各ハードウェアコンポーネントに対する給電の有無や動作状況の一例をモード毎に示す。
図5で示すように、上記4つの動作モードは、ゲーム装置3における消費電力が互いに異なる。例えば、ノーマルモードでは全てのハードウェアコンポーネントに通電されている。一方、スタンバイモードでは、電源制御部18およびコントローラ通信部16のみに通電されている状態となっている。なお、コントローラ通信部16については、上述した低電力モード(電源オン操作のみ受付)にて動作している。また、低消費電力モードでは、上記のように、更新チェックおよびダウンロード処理の実行に必要な分のハードウェアコンポーネントにのみ通電している。すなわち、CPU11とメモリ関係、サーバとの通信に必要となる無線通信部15、電源制御部18への通電も行われる。また、コントローラ通信部16についても通電が行われており、上述の低電力モードにて動作している。また、ダウンロード処理の処理負荷は比較的低いことから、CPU11の動作モードも1コア動作となっている。これにより、消費電力を必要最低限の状態に抑えつつ、上記更新チェックやダウンロード処理が実行できる。また、システム更新モードでは、システム更新の処理の実行に必要な分のハードウェアコンポーネントに通電している。また、CPU11も3コア動作となっており、コントローラ通信部16も通常モードで動作する。そのため、ノーマルモードよりは消費電力を抑えつつ、システムの更新インストールが可能である。なお、このモードでは、テレビへの出力は行っていないため、ユーザに対して、ゲーム装置3が電源オフの状態であると認識させることができる。このように、ゲーム装置3は、これらの動作モードを適宜切り替えて動作することによって、省電力化を図っている、
【0059】
なお、本実施形態では、上記のシステム更新が行われるタイミングでのユーザの同意を得る必要は無いものとする。例えば、システム更新についての包括的な許可をユーザから事前に得ておくような態様を利用している。そのため、本実施形態では、ユーザの操作を求めることなく、更新インストールや更新後のシステムの自動的な実行が可能となっている。
【0060】
上記システム更新モードは、低消費電力モードにおける更新チェックで、システムの更新が発生していると判定された場合にのみ起動し得る。具体的には、低消費電力モードの更新チェックの結果、システム更新が発生している場合、その更新パッケージのダウンロード後、低消費電力モードからシステム更新モードに移行して、システム更新を実行する、という制御が行われる。
図6に、このような場合の動作イメージを示す。まず、ノーマルモードで動作中に電源オフ操作が行われることで、ノーマルモードからスタンバイモードに移行する。その後、所定時間経過すると、低消費電力モードに移行する。このときの低消費電力モードにおいては、更新チェックの結果、システムの更新は見つからなかったとする。このときは、低消費電力モードからスタンバイモードに移行する。その後、所定時間の経過後、再度低消費電力モードに移行する。この低消費電力モードにおいて、システムの更新が見つかったとする。その結果、当該低消費電力モードで更新パッケージがダウンロードされ、その後、システム更新モードに移行する。そして、更新パッケージに基づいたシステム更新処理が行われ、その後、スタンバイモードに移行する。その後、所定時間の経過後、再度低消費電力モードに移行するが、この時点で、ゲーム装置3は更新後のシステムで動作することになる。つまり、システム更新が行われた後、再起動も自動的に行われることとなる。また、上述のように低消費電力モードにおいてダウンロード処理も自動的に行われるため、このようなダウンロードとシステム更新インストールにかかるユーザの利便性を向上することができる。
【0061】
なお、ゲーム装置3は上記システム更新モードで動作した後は、更新インストール処理の結果にかかわらず、一旦スタンバイモードに移行(つまり、シャットダウン)する。そして、所定時間経過後、更新インストール処理の結果にかかわらず、低消費電力モードに移行する。仮に、更新インストールが何らかの理由で完了しないまま、システム更新処理が終了してスタンバイモードに移行した場合でも、その次は、システム更新モードに移行せずに、低消費電力モードへの移行が行われることになる。そして、必要に応じて、低消費電力モードからシステム更新モードに移行して、完了しなかった更新インストールをやり直す、という制御が行われる。
【0062】
ここで、上記更新パッケージに含まれ得るもの、すなわち、「システムの更新」の対象となるものとしては、以下のようなものがある。
A)ゲーム装置3の基本的な制御システム(いわゆるOSやファームウェア等。以下、システムファイルと呼ぶこともある)の更新データ。
B)各ハードウェアコンポーネントのチップに書き込まれている制御用プログラム等の更新データ。また、このハードウェアコンポーネントには、コントローラ5も含まれる。例えば、コントローラ5が上記
図3で示したようなタイプであり、当該コントローラ5のLCD71等の制御プログラムがコントローラ5自体のチップ(マイコン)に書き込まれていれば、当該チップを更新するためのデータもこの更新データに含まれる。
C)上記ゲーム装置3は量産され得るものであるところ、これらの各ゲーム装置に共通してインストールされているアプリケーション(いわば、プリインストールされている、メーカー提供のアプリケーション等)の更新用データ。
【0063】
一方、ユーザの操作に基づいてゲーム装置3にインストールされたアプリケーション、例えば、ユーザがネットショップで購入し、ダウンロードしたゲーム等にかかる更新データは、上記のようなシステムの更新パッケージには含まれない。以下では、このようなシステム以外のアプリケーションについてはユーザアプリと呼ぶこともある。
【0064】
また、低消費電力モードにおける更新チェックにおいて、システムの更新と、それ以外のアプリケーション(ユーザアプリ)の更新の双方が見つかる場合もあるが、この場合、システム更新処理が優先的に行われるものとする。例えば、更新パッケージのダウンロードおよびシステムの更新のみを先に行い、更新後のシステムにて、上記それ以外のアプリケーションの更新データのダウンロードおよび更新処理を行っても良い。また、更新パッケージと上記アプリの更新データのダウンロードだけ先に済ませておき、システム更新処理を先に実行してから、更新後のシステムにて、アプリの更新処理を行うようにしても良い。
【0065】
また、本実施形態におけるシステムの更新処理は、概ね次のように行われる。上記更新パッケージは圧縮された状態で生成されている。そのため、まず、フラッシュメモリ14にダウンロードされた更新パッケージを展開してメインメモリ12に格納する処理が実行される。そして、当該展開したデータに基づいて、上記のように、所定のハードウェアコンポーネントのチップを書き換える処理や、ゲーム装置3のシステムファイルを更新する処理等を実行する。本実施形態でのシステムファイルの更新は、具体的には次のように行われる。まず、上記更新パッケージに含まれる制御システムの更新データは、差分という形ではなく、(更新後の)制御システム全体のデータが含まれているとする。また、一例として、現在のシステムファイルが格納されているフォルダ名が”SYSTEM”であるとする(フラッシュメモリ14に格納されている)。このような前提で、上記更新パッケージに含まれる更新後のシステムファイルが抽出・展開され、例えば"NEWSYSTEM"という名前のフォルダに格納される。そして、上記"SYSTEM"フォルダを削除し、"NEWSYSTEM"フォルダの名前を"SYSTEM"に変名する、という処理が行われる。これにより、ゲーム装置のシステムが更新後のシステムに置き換わることになる。その後、ゲーム装置3の再起動が行われることで、更新後のシステムで動作することになる。ここで、以下の説明では、上記更新にかかるシステムファイルを"NEWSYSTEM"フォルダに格納するところまでの処理を「インストール」と呼ぶ。具体的には、ハードウェアコンポーネントのチップ書き換え、共通アプリの更新、およびシステムファイルをフラッシュメモリ14(上記"NEWSYSTEM")へ格納する処理を「インストール」と呼ぶ、そして、その後のフォルダ名の変名にかかる処理のことは「更新の反映」と呼ぶ。
【0066】
なお、上記のように、「システムの更新」の対象としては、各ゲーム装置に共通してインストールされているアプリケーションも含まれる。例えば、「OS」と「メニューアプリケーション」の2つの更新対象があると想定する。この場合、まず「OS」の更新が実行され、この「OS」の更新の反映が行われる。その後、「メニューアプリケーション」の更新が実行され、「メニューアプリケーション」の更新の反映が行われる。そして、この2つの「更新」および「更新の反映」が行われた後に、ゲーム装置3の再起動が行われることになる。つまり「システムの更新」の対象が複数のソフトウェアコンポーネントにわたっている場合は、各コンポーネント単位で「更新」と「更新の反映」を行うようにしてもよい。
【0067】
また、更新処理の具体的内容は、上記の例に限らない。例えば、制御システムを構成するデータが複数の種類のデータで構成されている場合を想定する。一例として、(A)OS、(B)OSに必要なデータ群1、(C)OSに必要なデータ群2の3種類のデータで制御システムが構成されているとする。このような場合、(B)OSに必要なデータ群1、のみを更新することで制御システムを更新することも可能である。すなわち、ダウンロードされる更新データには、(B)OSに必要なデータ群1のみが含まれており、このデータ群1のみを更新するような処理としてもよい。つまり、データ単位で置き換えるような更新処理でもよい。
その他、上記"NEWSYSTEM"フォルダのような中間作業用のフォルダは用いずに、直接に上記"SYSTEM"フォルダ内のファイルを置き換えるような更新処理を行っても良い。
【0068】
また、本実施形態では、上記電源オフ状態において上述のダウンロードや更新インストールの実行中に、ユーザによる電源オン操作が行われた場合、以下のように動作する。まず、低消費電力モードにおいて更新パッケージのダウンロードが行われている最中に電源オン操作が行われた場合は、一旦当該ダウンロードが中断される。そして、ノーマルモードに移行した後、中断したダウンロードがバックグラウンド処理として再開される。なお、ダウンロード完了後は、例えば、ユーザにシステムの更新データがあることを通知し、ユーザの操作に基づいて、ノーマルモードにおいてシステム更新インストールを行っても良い。あるいは、次に電源オフ状態に移行した際に、システム更新モードにて更新インストールを行うようにしても良い。
【0069】
一方、システム更新モードにおける更新インストールの実行中に電源オン操作が行われたときは、更新インストールの処理はそのまま継続しながら、ノーマルモードへの移行を行う。具体的には、通電していなかった各ハードウェアコンポーネントにも通電を行い、テレビ2への映像、音声出力も行うことになる(上記LEDを実装している場合は、ノーマルモードを示す色で点灯させる)。その結果、ユーザから見ると、電源オン操作を行うことでテレビ2に画面が表示されるが、その画面には、例えばシステム更新インストールの進捗を示す画面が表示されていることになる(例えばプログレスバーが表示されている画面等)。この場合は、当該更新インストールの処理が終了するまで、ユーザはゲーム装置3を利用することができないことになる。
【0070】
次に、
図7〜
図11を参照して、本実施形態におけるゲーム装置3の動作をより詳細に説明する。
【0071】
図7は、ゲーム装置3のフラッシュメモリ14に格納されるデータの一例を示している。また、
図8は、メインメモリ12に格納されるデータの一例を示している。フラッシュメモリ14には、更新パッケージデータ201、システムファイル202、更新システムファイル203、等が格納される。また、メインメモリ12には、作業用展開データ204等、処理に必要なデータが適宜格納される。
【0072】
更新パッケージデータ201は、所定のサーバからダウンロードすることで得られた更新パッケージのデータである。各種更新用のデータが圧縮されてパッケージ化されたものである。システムファイル202は、更新前の、すなわち、現在動作しているシステムにかかるシステムファイルである。例えば、上述した"SYSTEM"フォルダに格納されたシステムファイル(データ群)である。更新システムファイル203は、上記更新パッケージデータから抽出される、更新されたシステムファイルである。例えば、上述した"NEWSYSTEM"フォルダに格納されるデータ群である。
【0073】
作業用展開データ204は、上記更新パッケージデータ201を展開したデータである。上記更新システムファイルの基になるデータや、ハードウェアコンポーネントのチップに書き込むための各種更新データが含まれる。
【0074】
次に、
図9〜
図11のフローチャートを参照して、電源オフ状態においてゲーム装置3で実行される処理の流れを説明する。
【0075】
図9は、上記スタンバイモードにおけるゲーム装置3の動作の詳細を示すフローチャートである。スタンバイモードでは、電源制御部18が実行主体となる。
図9において、ステップS1で、電源制御部18は、電源オンの操作が行われたか否かを判定する。その結果、電源オン操作が行われたときは(ステップS1でYES)、ステップS2で、電源制御部18は、ノーマルモード移行のための起動命令をCPU11に発行する。その結果、ゲーム装置3は、上記ノーマルモードに移行する(ノーマルモードで起動する)。
【0076】
一方、電源オンの操作が行われていないときは(ステップS1でNO)、次に、ステップS3で、電源制御部18は、RTCで計測された時間に基づき、低消費電力モードに移行する時間が到来したか否かを判定する。その結果、到来していれば(ステップS3でYES)、電源制御部18は、低消費電力モードとしてゲーム装置3を動作させるための起動命令をCPU11に対して発行する。その結果、CPU11等、低消費電力モードの動作に最低限必要なハードウェアコンポーネントへの給電が行われ、ゲーム装置3は低消費電力モードに移行する(低消費電力モードとして起動する)ことになる。一方、低消費電力モードを起動する時間が到来していなければ(ステップS3でNO)、上記ステップS1に戻り、処理が繰り返される。以上で、スタンバイモードにおけるゲーム装置3の動作の説明を終了する。
【0077】
次に、低消費電力モードにおけるゲーム装置の動作について説明する。
図10は、低消費電力モードにおけるゲーム装置3の動作の詳細を示すフローチャートである。このモードでは、CPU11が動作主体となる。まず、ステップS11で、CPU11は、無線通信部15を介して所定のサーバと接続し、更新データ(システム更新、アプリの更新の双方)の有無をサーバに問い合わせる処理を実行する(更新チェック処理)。例えば、サーバから、各アプリやシステムの最新バージョンを示す更新リストのデータを受信する等の処理である。
【0078】
次に、ステップS12で、上記問い合わせの結果に基づいて、更新データが有るか否かを判定する。例えば、上記更新リストと、ゲーム装置3のシステムのバージョンやゲーム装置3にインストールされている各アプリのバージョンを比較することで、更新データの有無を判定する。当該判定の結果、更新データがないときは(ステップS12でNO)、後述のステップS17の処理に進む。一方、更新データがあるときは(ステップS12でYES)、次に、ステップS13で、CPU11は上記所定のサーバから、更新データをダウンロードする処理を実行する。
【0079】
ダウンロード処理が終われば、ステップS14で、CPU11は、今回行ったダウンロードにシステムの更新が含まれているか否かを判定する。これは、上記更新リストに基づいて判定しても良いし、ダウンロードしたデータのファイル名等から判定しても良い。つまり、システムの更新があるか否かが判定できれば、その判定手法はどのようなものでもよい。
【0080】
上記判定の結果、システムの更新が含まれているときは(ステップS14でYES)、ステップS15で、CPU11は、ゲーム装置3の動作モードをシステム更新モードに移行するため処理を実行する。すなわち、ゲーム装置3をシステム更新モードとして再起動させる処理が実行される。これにより、システム更新の対象となり得るハードウェアコンポーネントへの通電が行われる。また、例えばCPU11の動作モードの変更(1コア動作から3コア動作への切換え)等も行われることになる。ゲーム装置3がシステム更新モードで起動すれば、後述する
図11の処理が実行されることになる。
【0081】
一方、上記ステップS14の判定の結果、システムの更新が含まれていないときは(ステップS14でNO)、ステップS16で、CPU11は、その他の処理を適宜実行する。例えば、アプリケーションの更新データをダウンロードしていた場合は、アプリケーションの更新処理を行う。ここで、アプリケーションの更新については、基本的には、フラッシュメモリ14に格納されているアプリケーションプログラムを、上記ダウンロードした更新データで上書きするという処理となる。そのため、ハードウェアコンポーネントのチップへの書き込み等が発生し得るシステムの更新と異なり、アプリケーションの更新については、低消費電力モードの状態でも実行可能である。
【0082】
次に、ステップS17で、CPU11は、低消費電力モードの次回の起動時間を設定する処理を行う。その後、ステップS18で、CPU11は、低消費電力モードからスタンバイモードへの移行処理を実行する。
【0083】
なお、上記のフローでは省略しているが、上記ダウンロードが完了する前に電源オン操作が行われたときは、低消費電力モードにおけるダウンロードは中断され、ノーマルモードへ移行する処理が実行されることになる。そして、ノーマルモードにおいて、バックグラウンドの処理として、中断したダウンロードが再開される。
【0084】
以上で、低消費電力モードにおける処理の説明を終了する。
【0085】
次に、
図11を用いて、システム更新モードにおけるゲーム装置3の動作の詳細を説明する。
図11は、システム更新モードにおけるゲーム装置3の動作の詳細を示すフローチャートである。このモードでも、動作主体はCPU11となる。
【0086】
ゲーム装置3がシステム更新モードに移行すると、まず、ステップS31で、CPU11は、更新パッケージをインストールする処理を実行する。具体的には、圧縮されている更新パッケージデータ201を展開し、作業用展開データ204としてメインメモリ12に格納する。更に、当該作業用展開データ204に基づいて、上記のように、所定のハードウェアコンポーネントのチップを書き換える処理や、更新にかかるシステムファイルをフラッシュメモリ14(例えば上記"NEWSYSTEM"フォルダ)に格納する処理等を実行する。
【0087】
次に、ステップS32で、CPU11は、インストールが完了したか否かを判定する。当該判定の結果、インストールがまだ完了していなければ(ステップS32でNO)、上記ステップS31に戻り、インストール処理を続行する。一方、インストールが完了すれば(ステップS32でYES)、ステップS33で、CPU11は、更新を反映するための処理を行う。すなわち、上記のように"SYSTEM"フォルダを削除し、"NEWSYSTEM"フォルダの名前を"SYSTEM"に変名する、という処理が行われる。その後、ステップS34で、CPU11は、スタンバイモードへの移行処理を実行する。これにより、スタンバイモードに移行した後、低消費電力モードあるいはノーマルモードに移行したタイミングが、ゲーム装置3の再起動に相当することになる。その結果、更新後のシステムでゲーム装置3が動作することになる。このことは、換言すれば、ユーザの同意・許諾を示す操作等を求めることなく、システム更新の反映を行い、更新後のシステムで動作させるともいえる。
【0088】
なお、上記フローチャートでの図示は省略したが、システム更新モードにおいて電源オン操作が行われたときは、通電していなかった各ハードウェアコンポーネントにも通電が行われる。その結果、テレビ2への映像、音声出力も行われることになる。つまり、更新処理は継続しながら、全てのハードウェアコンポーネントへの通電を行うことで、ノーマルモードへの移行が行われる。また、この場合、更新処理が終われば、再起動を行い、再度ノーマルモードで起動するように構成すればよい。
【0089】
以上で、システム更新モードにおける動作の説明を終了する。
【0090】
このように、本実施形態では、ゲーム装置3が電源オフ状態のとき、一部のハードウェアコンポーネントにのみ通電を行うことで消費電力を抑えて動作する低消費電力モードに加え、ゲーム装置3をシステム更新処理が可能な状態としつつもユーザには電源オフ状態のように見せて動作するシステム更新モードを設けている。そして、このシステム更新モードでは、システムの更新に必要なハードウェアコンポーネントに通電を行っている。これにより、ゲーム装置3が電源オフ状態の間に、ユーザに気付かせることなくシステム更新処理を実行させることができ、ゲーム装置3の消費電力を抑えつつも、ユーザの利便性を高めることが可能となる。
【0091】
なお、上記の例では、低消費電力モードにおいて更新パッケージのダウンロードを行い、そのインストールをシステム更新モードで行っていた。他の実施形態では、更新パッケージのダウンロードおよびインストールの双方をシステム更新モードで行うようによい。例えば、低消費電力モードにおいて上述の更新チェックを行い、その結果に基づき、システムの更新があるか否かを判定する。そして、システムの更新がある場合は、その時点で低消費電力モードからシステム更新モードに移行してもよい。そして、システム更新モードにおいて、更新パッケージのダウンロードとインストールの双方を実行するようにしてもよい。
【0092】
また、上記実施形態では、更新したシステムの反映も電源オフ状態において行っていた。他の実施形態では、更新の反映については、例えばシステム更新モードでは行わずに、次にノーマルモードに移行した際に、更新の反映についてユーザの同意操作を要求するようにしてもよい。そして、ユーザの同意が得られれば、上述したようなフォルダの変名処理を行い、ゲーム装置3を再起動するような制御を行っても良い。
【0093】
また、上記実施形態においては、情報処理システムの一例として据え置き型のゲームシステム1を例にして説明したが、これに限らず、例えば携帯型ゲーム機のような情報処理装置等にも上記の構成は適用可能である。また、ゲーム装置以外でも、例えばスマートフォンやいわゆるタブレット端末等の、ゲーム装置以外の情報処理装置や情報処理システムにも適用可能である。