JP2015225655A - 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム - Google Patents

Abstract

【課題】ダウンロードおよびインストールを行う際の情報処理装置の消費電力をより軽減することができる情報処理装置等を提供すること。
【解決手段】情報処理装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な低消費電力状態において、システムソフトウェアの更新が存在するか否かを確認する。更新が存在すれば、更新データをダウンロードすると共に、当該更新の対象であって、低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電を開始する。そして、システムの更新を実行する。この一連の処理は、ユーザの操作によることなく自動的に実行される。
【選択図】図５

Description

本発明は、ネットワークを介して外部装置と通信可能な情報処理装置に関し、より特定的には、低消費電力状態におけるシステムの更新処理に関する。

従来から、アプリケーション等の所定のデータを自動的にダウンロードして、そのインストールも行う情報処理装置が知られている（例えば、特許文献１）。

特開２０１２-１８６５７号公報

上記のような情報処理装置では、情報処理装置の消費電力（動作モード）の観点からみると、ダウンロードするときの消費電力と、インストールするときの消費電力はほぼ同じであった。

それ故に、本発明の目的は、自動的にダウンロードおよびインストールを行う際の情報処理装置の消費電力をより軽減することができ、更に、ダウンロードおよびインストールの利便性を向上できる情報処理装置等を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、ネットワークを介して外部装置と通信可能な情報処理装置であって、当該情報処理装置は、本装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも２つの動作状態を切り替えて動作可能である。そして、当該情報処理装置は、更新確認手段と、更新準備手段と、更新インストール手段とを備える。更新確認手段は、低消費電力状態において、ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する。更新準備手段は、更新が存在する場合、所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始を行う。更新インストール手段は、ダウンロードした更新データに基づいて、システムの更新インストールを実行する。更に、更新確認手段、更新準備手段、更新インストール手段による一連の処理は、ユーザの操作によることなく自動的に実行される。

上記構成例によれば、情報処理装置の消費電力を抑えつつも、当該情報処理装置のシステムの更新処理を実行させることができ、ユーザの利便性を高めることが可能となる。

他の構成例として、更新準備手段は、低消費電力状態では通電されていないハードウェアコンポーネントであって、更新の書き込み対象となるハードウェアコンポーネントへの通電を開始し、更新インストール手段は、更新準備手段によって通電されたハードウェアコンポーネントにかかる書き込みを伴うシステム更新インストールを実行するようにしてもよい。

上記構成例によれば、情報処理装置の消費電力を抑えながら、ハードウェアコンポーネントへの書き込みが必要なシステム更新を実行することができる。

他の構成例として、更新準備手段による処理は低消費電力状態において実行されてもよい。

上記構成例によれば、情報処理装置の消費電力をより低減することが可能となる。

他の構成例として、情報処理装置は、更新インストール手段によるシステム更新インストールの終了後、ユーザの操作を求めることなく、更新後のシステムによる情報処理装置の動作を開始するような構成としてもよい。

上記構成例によれば、ユーザの利便性を高めることができる。

他の構成例として、情報処理装置は、更新インストール手段による更新インストール後、情報処理装置をシャットダウンする処理を実行するシャットダウン手段を更に備えていてもよい。更には、情報処理装置は、シャットダウン手段によりシャットダウンされた後、自動的に動作状態を低消費電力状態に切り替えるようにしてもよい。

上記構成例によれば、情報処理装置の消費電力を抑えつつ、システムの更新およびその後の再起動まで行うことが可能となる。更には、一旦システム更新を行った後、引き続いてその後に発生する更新のチェック処理を実行でき、その自動的なダウンロードおよび更新インストール処理を行うことも可能となる。

他の構成例として、情報処理装置は、ユーザの操作に基づいて情報処理装置の動作状態を前記通常使用状態以外の状態から通常使用状態へ切換えるためのユーザによる指示操作を受け付ける操作受付手段と、前記更新確認手段、更新準備手段、および更新インストール手段による一連の処理が行われている間に、操作受付手段が指示操作を受け付けたことに応じて、情報処理装置の動作状態を通常使用状態へ切替える通常状態移行手段とを更に備える構成としても良い。また、情報処理装置は、低消費電力状態においてダウンロードが行われている間に、操作受付手段がユーザによる指示操作を受け付けたときは、当該ダウンロード処理を中断するダウンロード中断手段と、動作状態が通常使用状態となった後、中断したダウンロードを再開する再開手段とを更に備える構成としても良い。また、再開手段は、動作状態が通常使用状態になった後、バックグラウンド処理としてダウンロードを再開してもよい。更には、更新インストール手段によるシステムの更新インストール処理中に、操作受付手段がユーザによる指示操作を受け付けたときは、通常状態移行手段は、当該システムの更新インストール処理を継続しながら通常使用状態への切替えを行うようにしてもよい。

上記構成例によれば、ダウンロード処理については一旦中断し、その後再開することでユーザの利便性を確保しつつも、システム更新のような重要な処理については速やかに完了させることができる。

他の構成例として、情報処理装置は、更新確認手段、更新準備手段、および更新インストール手段による一連の処理の間、当該処理にかかる映像音声信号の外部機器への出力は行わないように構成してもよい。

上記構成例によれば、システム更新に係る処理を行っていることをユーザに気付かせることなく、当該処理を進行させることができる。

他の構成例として、更新の対象となるソフトウェアには、第１の種類のソフトウェアと第２の種類のソフトウェアが含まれており、更新確認手段は、第１の種類のソフトウェアの更新の有無と、第２の種類のソフトウェアの更新の有無の双方を判定する判定手段を含み、更新準備手段および更新インストール手段による処理は、第１の種類のソフトウェアの更新があると判定されたときに実行されるように構成してもよい。更には、上記システムソフトウェアは第１の種類のソフトウェアに属し、当該システムソフトウェア以外のアプリケーションは第２の種類のソフトウェアに属していてもよい。

上記構成例によれば、例えばシステムソフトウェアの更新が発生するときにのみ、その更新に必要な通電を行うため、総合的にみて、情報処理装置の消費電力をより軽減することができる。

本実施形態によれば、システムの更新のダウンロードおよびインストールを行う際の情報処理装置の消費電力をより軽減することができる。また、ダウンロードおよびインストールの利便性も向上できる。

本実施形態の一例であるゲームシステムの全体像を示す模式図 ゲーム装置３の構成の一例を示すブロック図 コントローラの一例 電源オフ状態におけるゲーム装置の動作状態の遷移を示す図 ゲーム装置３の各ハードウェアコンポーネントに対する給電の有無や動作状況の一例を示す図 電源オフ状態におけるゲーム装置の動作状態の遷移を示す図 本実施形態で用いられるデータの一例 本実施形態で用いられるデータの一例 スタンバイモードにおけるゲーム装置の動作の詳細を示すフローチャート 低消費電力モードにおけるゲーム装置の動作の詳細を示すフローチャート システム更新モードにおけるゲーム装置の動作の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。本実施形態では、情報処理システムの一例として、据え置き型のゲームシステムを例に挙げて説明する。

［１．ゲームシステムの全体構成］
図１は、ゲームシステム１の外観図である。図１において、ゲームシステム１は、テレビジョン受像器等に代表される据置型のディスプレイ装置（以下、「テレビ」と記載する）２、据置型のゲーム装置３、光ディスク４、コントローラ５を含む。ゲームシステム１は、コントローラ５を用いたゲーム操作に基づいてゲーム装置３においてゲーム処理を実行し、ゲーム処理によって得られるゲーム画像をテレビ２に表示するものである。

ゲーム装置３には、当該ゲーム装置３に対して交換可能に用いられる情報記憶媒体の一例である光ディスク４が脱着可能に挿入される。光ディスク４には、ゲーム装置３において実行されるための情報処理プログラム（典型的にはゲームプログラム）が記憶されている。ゲーム装置３の前面には光ディスク４の挿入口が設けられている。ゲーム装置３は、挿入口に挿入された光ディスク４に記憶されている情報処理プログラムを読み出して実行することによってゲーム処理を実行可能である。

ゲーム装置３には、テレビ２が接続コードを介して接続される。テレビ２は、ゲーム装置３において実行されるゲーム処理によって得られるゲーム画像を表示する。テレビ２はスピーカ２Ｌおよび２Ｒを有しており、スピーカ２Ｌおよび２Ｒは、上記ゲーム処理の結果得られるゲーム音声を出力する。なお、他の実施形態においては、ゲーム装置３と据置型の表示装置とは一体となっていてもよい。また、ゲーム装置３とテレビ２との通信は無線通信であってもよい。

コントローラ５は、自機に対して行われた操作の内容を表す操作データをゲーム装置３に与えるものである。コントローラ５とゲーム装置３とは所定の無線通信によって通信可能である。なお、他の実施形態においてはコントローラ５とゲーム装置３とは有線で接続されてもよい。

［２．ゲーム装置３の内部構成］
次に、図２を参照して、ゲーム装置３の内部構成について説明する。図２は、ゲーム装置３の内部構成を示すブロック図である。ゲーム装置３は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、メインメモリ１２、フラッシュメモリ１４、無線通信部１５、コントローラ通信部１６、ディスクドライブ１７、電源制御部１８、ＡＶ−ＩＣ１９、ＧＰＵ２０、およびＤＳＰ２１等を有する。

ＣＰＵ１１は、光ディスク４に記憶されたゲームプログラム等を実行することによってゲーム処理を実行するものであり、ゲームプロセッサとして機能する。なお、本実施形態では、ＣＰＵ１１は、いわゆるマルチコアプロセッサであるとする。具体的には、３コアのプロセッサであるとする。もちろん、他の実施形態では、コア数は３に限るものではないことや、マルチコアでなくてもよいことはいうまでもない。

ＣＰＵ１１には、メインメモリ１２、フラッシュメモリ１４、無線通信部１５，コントローラ通信部１６、ディスクドライブ１７、電源制御部１８、ＧＰＵ２０、ＤＳＰ２１が接続される。また、ＧＰＵ２０およびＤＳＰ２１は、ＡＶ-ＩＣ１９にも接続される。揮発性のメインメモリ１２は、光ディスク４から読み出されたゲームプログラムや、フラッシュメモリ１４から読み出されたゲームプログラム等のプログラムを記憶したり、各種データを記憶したりするものであり、ＣＰＵ１１のワーク領域やバッファ領域として用いられる。ディスクドライブ１７は、光ディスク４からプログラムデータ等を読み出し、メインメモリ１２に読み出したデータを書き込む。

ＧＰＵ２０は、描画手段の一部を形成し、ＣＰＵ１１からのグラフィクスコマンド（作画命令）に従って画像を生成する。

ＤＳＰ２１は、オーディオプロセッサとして機能し、外部メインメモリ１２に記憶されるサウンドデータや音波形（音色）データを用いて、音声データを生成する。

上記のようにゲーム装置３において生成される画像および音声のうちで、テレビ２において出力される画像および音声のデータは、ＡＶ−ＩＣ１９によって読み出される。ＡＶ−ＩＣ１９は、読み出した画像データを図示しないＡＶコネクタを介してテレビ２に出力するとともに、読み出した音声データを、テレビ２に内蔵されるスピーカ２Ｌおよび２Ｒに出力する。これによって、テレビ２に画像が表示されるとともにスピーカ２Ｌおよび２Ｒから音が出力される。

ゲーム装置３は、インターネット等のネットワークに接続して外部情報処理装置（例えば他のゲーム装置や、各種サーバ等）と通信を行うことが可能である。すなわち、ＣＰＵ１１は、無線通信部１５を介してインターネット等のネットワークに接続し、ネットワークに接続される外部情報処理装置と通信することができる。ＣＰＵ１１は、定期的にフラッシュメモリ１４にアクセスし、ネットワークへ送信する必要があるデータの有無を検出し、当該データが有る場合には、無線通信部１５を介してネットワークに送信する。また、ＣＰＵ１１は、外部情報処理装置から送信されてくるデータや所定のサーバからダウンロードしたデータを、ネットワークおよび無線通信部１５を介して受信し、受信したデータをフラッシュメモリ１４に記憶する。

また、ゲーム装置３は、コントローラ通信部１６を介して、コントローラ５からの操作データを受信することが可能である。すなわち、ＣＰＵ１１は、コントローラ５から送信される操作データをコントローラ通信部１６を介して受信し、メインメモリ１２に記憶（一時記憶）する。なお、本実施形態では、当該コントローラ通信部１６は２つの動作モードを有している。一つは、通常動作を行う通常動作モードであり、もう一つは、低電力にて動作する低電力モードである。詳細は後述するが、ゲーム装置３がノーマルモードで動作しているときは、通常動作モードで動作する。また、低消費電力モードで動作しているときは、コントローラ通信部１６は低電力モードとなる。そして、この低電力モードのときは、コントローラ通信部１６は、コントローラ５に備えられている電源ボタンの操作のみ受け付けるという動作を行う。

電源制御部１８は、ＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）を含み、時間を計測することが可能である。後述するゲーム装置３の動作モードを所定のタイムスケジュールに従って変更するために、電源制御部１８で計測される時間が用いられる。また、電源制御部１８は、ゲーム装置３の各部に対する給電を制御する。例えば、電源制御部１８は、計測された時間に基づいてＣＰＵ１１の起動を制御する。

なお、本実施形態においては、ゲーム装置３（の各部）は、外部電源から取得される電力で動作する。電源制御部１８は、外部電源からの電力をゲーム装置３の各部に対して供給する。例えば、ゲーム装置３は、家庭用電源からＡＣアダプタ（図示せず）を介して電力を取得してもよい。また、他の実施形態においては、ゲーム装置３は、内部電源（バッテリ等）から取得される電力で動作してもよい。

その他、図示は省略するが、上記以外のハードウェアコンポーネント（モジュール）も実装されている（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール等）。ここで、これらのハードウェアコンポーネントの中には、そのコンポーネントを制御するための制御プログラムが書き込まれたチップ（マイコン）を搭載するものが含まれる。また、このチップは、書き換え可能に構成されているものとする。本実施形態では、システム更新処理の一環として、このようなチップの書き換えも行う。

次に、コントローラ５について説明する。図１で示したコントローラ５は、ゲーム装置３と無線で接続される。コントローラ５は、複数の操作ボタンを有しており、ユーザの各種操作を受け付け可能である。なお、図１で示したようなコントローラの他、例えば、図３に示すような、ＬＣＤ７１やタッチパネル７２を有するコントローラを利用する構成であっても良い。

次に、本実施形態にかかるゲーム装置３で実行される情報処理の動作概要を説明する。本実施形態にかかる処理は、主に、ゲーム装置３の電源がオフとなっている間に、システム更新を行う処理である。なお、システム更新のための更新データの入手手法について、本実施形態では、ゲーム装置３は、所定のサーバからダウンロードすることで取得する。すなわち、ゲーム装置３は、所定のサーバに更新データの有無を問い合わせる。そして、存在する場合は更新用のデータをダウンロードする（なお、本実施形態では、システム以外のアプリケーションの更新の有無についても、これに併せて問い合わせている）。そして、ダウンロードした更新用データを用いてシステム更新を行う。

まず、本実施形態におけるゲーム装置３の動作状態（動作モード）について説明する。まず、本実施形態のゲーム装置３の動作状態としては、ユーザからの観点でいうと、電源オンである状態（以下、電源オン状態）と電源がオフである状態（以下、電源オフ状態）とがある。電源オン状態は、主にユーザがゲームをプレイしている等、ゲーム装置３を使用している状態ともいえる。換言すれば、ユーザから見て、ゲーム装置３の電源がオンになっていると認識されるような状態である。一方、電源オフ状態は、ユーザから見て「電源がオフ」と認識できる状態であり、かつ、ＡＣ電力の供給が可能な状態であるとする。つまり、ＡＣアダプタ等はコンセントにささっている状態であるとする。あるいは、ゲーム装置３がバッテリーで動作するタイプのものであれば、ゲーム装置３の動作に必要な最低限以上のバッテリー残量が残っている状態であるとする。

上記電源オン状態におけるゲーム装置３の動作モードのことを、ノーマルモードと呼ぶ。ノーマルモードは、全てのハードウェアコンポーネントに通電している状態である。また、テレビ２への映像・音声信号の出力もなされている。

一方、電源オフ状態のときの動作モード（換言すれば、ゲーム装置３の通電状況）としては、スタンバイモード、低消費電力モード、そして、システム更新モードの３つがある。電源オフ状態のときは、基本的には、ゲーム装置３は、スタンバイモードと低消費電力モードの２つのモードを所定のタイムスケジュールに基づいて切換えながら動作している。より具体的には、電源オフ状態の時の動作モードは基本的にはスタンバイモードであるが、間欠的に低消費電力モードが立ち上がるような制御が行われる。更に、所定の条件下では、後述するシステム更新モードで動作する場合もある。

スタンバイモードでは、電源制御部１８のみ通電している状態であり、その他の各ハードウェアコンポーネントへの通電は行われていない。このモードでは、電源ボタンによる電源オンの操作のみ受け付けている状態となっている。上記スタンバイモードは、いわば待機電力で動作している待機状態ともいえる。

一方、低消費電力モードでは、ゲーム装置３を構成するハードウェアコンポーネントのうち、ＣＰＵ１１を含む一部のハードウェアコンポーネントにのみ通電がなされている。つまり、スタンバイモードよりも消費電力は大きいが、ノーマルモードに比べると消費電力は小さい状態である。また、ＣＰＵ１１にも通電されているため、ＣＰＵ１１による情報処理も可能な状態である。ここで、当該低消費電力モードにおいて実行される処理として、本実施形態では、システムやアプリケーションの更新が存在するか否か（更新が発生しているか否か）をチェックする処理がある。更に、更新が存在する場合は、所定のサーバからその更新データをダウンロードする処理も行われる。つまり、ユーザから見てゲーム装置３の電源が切れているオフの間に、例えばシステムやアプリケーションの更新データのダウンロードを済ませておく、というような動作を行う。そして、低消費電力モードでは、このようなダウンロード処理に必要なハードウェアコンポーネントのみ通電されている状態となっている。具体的には、本実施形態では、ＣＰＵ１１、メインメモリ１２、フラッシュメモリ１４、無線通信部１５、コントローラ通信部１６および電源制御部１８に通電されているものとする。ここで、ＣＰＵ１１に関して、本実施形態では、上記のように３コアのマルチプロセッサである。そして、この低消費電力モードにおいては、ＣＰＵ１１は、１コアのみで動作するものとする。また、このとき、更に、ＣＰＵ１１の動作クロック数を落として動作させるようにしても良い。また、コントローラ通信部１６に関して、上述のようにコントローラ通信部１６は２つの動作モードを有している。そして、当該低消費電力モードのときは、コントローラ５の電源オン操作のみ受付け可能な低電力モードで動作している。つまり、当該低消費電力モードは、上記ダウンロード処理に必要最低限の電力のみ供給し、それ以外のハードウェアコンポーネントへは通電しないようにして、できるだけ電力消費を抑えている動作モードといえる。

そして、本実施形態では、電源オフ状態では、基本的には、図４で示すような制御が行われる。図４は、電源オフ状態でのゲーム装置３の基本的な動作モードを説明するための図である。まず、ノーマルモードで動作中に電源オフ操作（シャットダウン操作）が行われることで、ノーマルモードからスタンバイモードに移行する（スタンバイモードへの移行は、いわゆるシャットダウン処理に相当する）。その後、所定時間が経過すると、低消費電力モードに移行する。この低消費電力モードにおいて、上記更新のチェック処理や、（更新があるときは）ダウンロード処理等が実行される。これらの処理が完了した後、低消費電力モードからスタンバイモードに移行する。その後、所定時間が経過すると、低消費電力モードに移行し、その後、またスタンバイモードに移行する。このように、電源オフ時は、スタンバイモードをベースとしつつ、所定のタイムスケジュールに従って低消費電力モードに間欠的に切り替わる。

ここで、低消費電力モードにおいてダウンロードされるデータには、ゲーム装置３のシステム更新用のデータパッケージ（以下、更新パッケージと呼ぶ）が含まれる。この更新パッケージの適用について、従来では、上記低消費電力モードで更新パッケージのダウンロードを完了させ、その後、ゲーム装置３がノーマルモードで起動したときにシステム更新を行う、という手法が知られている。しかし、この手法の場合、ユーザにとっては、更新が終わるまでの待ち時間が発生することになる。特に、長期間ゲーム装置３の電源をオンにしておらず、久しぶりに電源をオンしたような場合であって、複数の更新が溜まっているような場合に、これらの更新が全て適用されるまでの待ち時間が大きくなってしまうことが考えられる。そのため、本実施形態では、ゲーム装置３が電源オフ状態である間に、システム更新も済ませてしまおうというものである。

ところで、上述のように、低消費電力モードでは、できるだけ消費電力を下げるために、必要最低限のハードウェアコンポーネントしか通電されていない。その一方で、上記更新パッケージには、所定のハードウェアコンポーネントのチップ書き換えが発生するような更新も含まれる場合がある（例えば、所定のハードウェアコンポーネントに搭載されているマイコン等の制御プログラムの更新）。そして、この更新対象となる所定のハードウェアコンポーネントが、低消費電力モードにおいては通電されていないような場合、低消費電力モードの状態では、上記チップの書き換え処理を実行することができず、システム更新ができない。（上記コントローラ通信部１６についても、上記低電力モードの状態では、当該コントローラ通信部１６のチップの書き換えができないものとする）このような場合、ゲーム装置３を低消費電力モードからノーマルモードに自動的に移行させて、システム更新を行うことも考えられる。しかし、このような制御を行うと、テレビ２への映像・音声信号の出力等もなされることになり、ユーザからみると、電源をオフにしたはずのゲーム装置が勝手に起動しているように見えてしまう。

そこで、本実施形態では、ユーザにはゲーム装置３が電源オフ状態であると認識させつつも、ゲーム装置３の内部的には、システム更新に必要なハードウェアコンポーネントへの通電を行い、ハードウェア的にシステム更新が可能な状態である、システム更新モードというものを設けている。そして、このシステム更新モードに移行してからシステム更新処理を行う。つまり、ハードウェアコンポーネントへの電力供給や消費電力の観点からみると、システム更新モードは、ノーマルモードと低消費電力モードの間に位置するようなモードとなる。つまり、消費電力の大きい順に、ノーマルモード、システム更新モード、低消費電力モード、スタンバイモード、という関係となっている。システム更新モードでは、より具体的には、以下のような通電状況となる。まず、ＣＰＵ１１、メインメモリ１２、フラッシュメモリ１４、無線通信部１５、電源制御部１８、ＧＰＵ２０，ＤＳＰ２１については通電が行われる。また、コントローラ通信部１６についても、上記通常動作モードで動作させる。また、ＣＰＵ１１は、ノーマルモードの場合と同様に、３コアとも利用可能な状態で動作する（ＣＰＵ１１の動作クロックもノーマルモードと同様である）。一方、ディスクドライブ１７への通電はなされない（これにより、比較的騒音値が高いディスクの回転音が発生することを抑えることも可能となる）。また、ＧＰＵ２０による画像生成処理や映像の出力処理自体はなされるが、しかし、テレビ２への映像信号出力はなされない。つまり、ゲーム装置３からテレビ２への映像信号出力は行われない。いわば、映像信号が、ＡＶ−ＩＣ１９のところでせき止められたような状態となる。また、音声に関しても同様である。その他、システム更新の対象となり得るハードウェアコンポーネントについても通電がなされる。

上記のことから、低消費電力モードおよびシステム更新モードは、次のように捉えることもできる。すなわち、上記低消費電力モードでは、更新チェックおよびダウンロード処理が可能となるハードウェアコンポーネントに通電されていればよい。そして、システム更新モードでは、システム更新インストールが可能なハードウェアコンポーネントに通電されていればよい。そのため、他の実施形態では、低消費電力モード（ダウンロード処理）のときよりも、システム更新モード（システム更新インストール）における消費電力のほうが小さくなるような構成であってもよい。

ここで、上記システム更新モードにおいて通電対象となるハードウェアコンポーネントについては、例えば、事前にシステム更新の対象となり得るハードウェアコンポーネントを洗い出しておき、システム更新モードにおける通電対象として構成しておくことが考えられる。そのため、もし、上記ディスクドライブ１７もシステム更新の対象となり得る場合は、システム更新モードにおいてはディスクドライブ１７にも通電するようにしてもよい。また、逆に、例えば、上記無線通信部１５がシステム更新の対象とならない場合は、システム更新モードにおいては無線通信部１５に通電しないような構成としても良い。更に言えば、システム更新モードでは、テレビ２等の外部装置への映像・音声出力だけが止められているだけで、その他の点については、結果的には実質的にノーマルモードと同様の通電状態・動作状態となっていてもよい。この場合でも、テレビ２への出力はオフの状態であるため、ユーザから見れば、見かけ上、ゲーム装置３は電源オフ状態と見える。また、少なくとも、ＡＶ−ＩＣ１９にかかる消費電力は抑えることができる。

また、コントローラ通信部１６について、本実施形態では、上記のように通常動作モードと低電力モードとを有する場合を例示している。他の実施形態では、例えばコントローラ５に電源ボタンが搭載されていない場合、上記低電力モードは設けない構成としても良い。このような場合は、上記低消費電力モードやスタンバイモードではコントローラ通信部１６への通電を行わないようにしてもよい。

また、更に他の実施形態では、上記のような各ハードウェアコンポーネントに対して通電を行う／行わないという制御の他、各ハードウェアコンポーネントの動作状態を変更する、という制御を行うようにしてもよい。例えば、上記のようなコントローラ通信部１６でいうと、上記システム更新モードであるか低消費電力モードであるかに応じて、通常動作モードと低電力モードとを切換える制御や、後述の冷却用のファンの回転数を変化させるような制御を行っても良い。つまり、各ハードウェアコンポーネントについて、通電はしている状態であるが、より消費電力を抑えて動作させることが可能なもの（動作状態を変更できるもの）である場合、消費電力を抑えて動作する動作状態に適宜切換えるような制御を行っても良い。

なお、上記図２では図示を省略しているが、ゲーム装置３には、本体の動作モードを示すためのＬＥＤも実装されている。そして、本実施形態では、当該ＬＥＤについて、例えばノーマルモードでは青色で点灯させ、スタンバイモードでは赤色で点灯させ、低消費電力モードではオレンジ色で点灯させるとする。この場合、上記システム更新モードでは、低消費電力モードと同じくオレンジ色で点灯させる。つまり、システム更新モードは、見た目は低消費電力モードのように見せかける。なお、他の実施形態では、例えばスタンバイモード、低消費電力モード、システム更新モード共に同じ色（例えば赤色）で点灯させるようにしてもよい。

また、ゲーム装置３には、冷却用のファンが搭載されていてもよい。そして、このファンの回転に関しては、低消費電力モードでは、ノーマルモードの時よりも回転数を落として動作させてもよい。低消費電力モードでは、ノーマルモードの時よりも発熱が少なくなると考えられるためである。一方、システム更新モードでは、ノーマルモードと同様の回転数で動作させればよい。低消費電力モードの時よりは発熱も多くなり、場合によっては、ノーマルモードの場合と同じくらいの発熱になり得るためである。

ここで、図５を用いて、上記ゲーム装置３の各ハードウェアコンポーネントに対する給電の有無や動作状況の一例をモード毎に示す。図５で示すように、上記４つの動作モードは、ゲーム装置３における消費電力が互いに異なる。例えば、ノーマルモードでは全てのハードウェアコンポーネントに通電されている。一方、スタンバイモードでは、電源制御部１８およびコントローラ通信部１６のみに通電されている状態となっている。なお、コントローラ通信部１６については、上述した低電力モード（電源オン操作のみ受付）にて動作している。また、低消費電力モードでは、上記のように、更新チェックおよびダウンロード処理の実行に必要な分のハードウェアコンポーネントにのみ通電している。すなわち、ＣＰＵ１１とメモリ関係、サーバとの通信に必要となる無線通信部１５、電源制御部１８への通電も行われる。また、コントローラ通信部１６についても通電が行われており、上述の低電力モードにて動作している。また、ダウンロード処理の処理負荷は比較的低いことから、ＣＰＵ１１の動作モードも１コア動作となっている。これにより、消費電力を必要最低限の状態に抑えつつ、上記更新チェックやダウンロード処理が実行できる。また、システム更新モードでは、システム更新の処理の実行に必要な分のハードウェアコンポーネントに通電している。また、ＣＰＵ１１も３コア動作となっており、コントローラ通信部１６も通常モードで動作する。そのため、ノーマルモードよりは消費電力を抑えつつ、システムの更新インストールが可能である。なお、このモードでは、テレビへの出力は行っていないため、ユーザに対して、ゲーム装置３が電源オフの状態であると認識させることができる。このように、ゲーム装置３は、これらの動作モードを適宜切り替えて動作することによって、省電力化を図っている、

なお、本実施形態では、上記のシステム更新が行われるタイミングでのユーザの同意を得る必要は無いものとする。例えば、システム更新についての包括的な許可をユーザから事前に得ておくような態様を利用している。そのため、本実施形態では、ユーザの操作を求めることなく、更新インストールや更新後のシステムの自動的な実行が可能となっている。

上記システム更新モードは、低消費電力モードにおける更新チェックで、システムの更新が発生していると判定された場合にのみ起動し得る。具体的には、低消費電力モードの更新チェックの結果、システム更新が発生している場合、その更新パッケージのダウンロード後、低消費電力モードからシステム更新モードに移行して、システム更新を実行する、という制御が行われる。図６に、このような場合の動作イメージを示す。まず、ノーマルモードで動作中に電源オフ操作が行われることで、ノーマルモードからスタンバイモードに移行する。その後、所定時間経過すると、低消費電力モードに移行する。このときの低消費電力モードにおいては、更新チェックの結果、システムの更新は見つからなかったとする。このときは、低消費電力モードからスタンバイモードに移行する。その後、所定時間の経過後、再度低消費電力モードに移行する。この低消費電力モードにおいて、システムの更新が見つかったとする。その結果、当該低消費電力モードで更新パッケージがダウンロードされ、その後、システム更新モードに移行する。そして、更新パッケージに基づいたシステム更新処理が行われ、その後、スタンバイモードに移行する。その後、所定時間の経過後、再度低消費電力モードに移行するが、この時点で、ゲーム装置３は更新後のシステムで動作することになる。つまり、システム更新が行われた後、再起動も自動的に行われることとなる。また、上述のように低消費電力モードにおいてダウンロード処理も自動的に行われるため、このようなダウンロードとシステム更新インストールにかかるユーザの利便性を向上することができる。

なお、ゲーム装置３は上記システム更新モードで動作した後は、更新インストール処理の結果にかかわらず、一旦スタンバイモードに移行（つまり、シャットダウン）する。そして、所定時間経過後、更新インストール処理の結果にかかわらず、低消費電力モードに移行する。仮に、更新インストールが何らかの理由で完了しないまま、システム更新処理が終了してスタンバイモードに移行した場合でも、その次は、システム更新モードに移行せずに、低消費電力モードへの移行が行われることになる。そして、必要に応じて、低消費電力モードからシステム更新モードに移行して、完了しなかった更新インストールをやり直す、という制御が行われる。

ここで、上記更新パッケージに含まれ得るもの、すなわち、「システムの更新」の対象となるものとしては、以下のようなものがある。
Ａ）ゲーム装置３の基本的な制御システム（いわゆるＯＳやファームウェア等。以下、システムファイルと呼ぶこともある）の更新データ。
Ｂ）各ハードウェアコンポーネントのチップに書き込まれている制御用プログラム等の更新データ。また、このハードウェアコンポーネントには、コントローラ５も含まれる。例えば、コントローラ５が上記図３で示したようなタイプであり、当該コントローラ５のＬＣＤ７１等の制御プログラムがコントローラ５自体のチップ（マイコン）に書き込まれていれば、当該チップを更新するためのデータもこの更新データに含まれる。
Ｃ）上記ゲーム装置３は量産され得るものであるところ、これらの各ゲーム装置に共通してインストールされているアプリケーション（いわば、プリインストールされている、メーカー提供のアプリケーション等）の更新用データ。

一方、ユーザの操作に基づいてゲーム装置３にインストールされたアプリケーション、例えば、ユーザがネットショップで購入し、ダウンロードしたゲーム等にかかる更新データは、上記のようなシステムの更新パッケージには含まれない。以下では、このようなシステム以外のアプリケーションについてはユーザアプリと呼ぶこともある。

また、低消費電力モードにおける更新チェックにおいて、システムの更新と、それ以外のアプリケーション（ユーザアプリ）の更新の双方が見つかる場合もあるが、この場合、システム更新処理が優先的に行われるものとする。例えば、更新パッケージのダウンロードおよびシステムの更新のみを先に行い、更新後のシステムにて、上記それ以外のアプリケーションの更新データのダウンロードおよび更新処理を行っても良い。また、更新パッケージと上記アプリの更新データのダウンロードだけ先に済ませておき、システム更新処理を先に実行してから、更新後のシステムにて、アプリの更新処理を行うようにしても良い。

また、本実施形態におけるシステムの更新処理は、概ね次のように行われる。上記更新パッケージは圧縮された状態で生成されている。そのため、まず、フラッシュメモリ１４にダウンロードされた更新パッケージを展開してメインメモリ１２に格納する処理が実行される。そして、当該展開したデータに基づいて、上記のように、所定のハードウェアコンポーネントのチップを書き換える処理や、ゲーム装置３のシステムファイルを更新する処理等を実行する。本実施形態でのシステムファイルの更新は、具体的には次のように行われる。まず、上記更新パッケージに含まれる制御システムの更新データは、差分という形ではなく、（更新後の）制御システム全体のデータが含まれているとする。また、一例として、現在のシステムファイルが格納されているフォルダ名が”SYSTEM”であるとする（フラッシュメモリ１４に格納されている）。このような前提で、上記更新パッケージに含まれる更新後のシステムファイルが抽出・展開され、例えば"NEWSYSTEM"という名前のフォルダに格納される。そして、上記"SYSTEM"フォルダを削除し、"NEWSYSTEM"フォルダの名前を"SYSTEM"に変名する、という処理が行われる。これにより、ゲーム装置のシステムが更新後のシステムに置き換わることになる。その後、ゲーム装置３の再起動が行われることで、更新後のシステムで動作することになる。ここで、以下の説明では、上記更新にかかるシステムファイルを"NEWSYSTEM"フォルダに格納するところまでの処理を「インストール」と呼ぶ。具体的には、ハードウェアコンポーネントのチップ書き換え、共通アプリの更新、およびシステムファイルをフラッシュメモリ１４（上記"NEWSYSTEM"）へ格納する処理を「インストール」と呼ぶ、そして、その後のフォルダ名の変名にかかる処理のことは「更新の反映」と呼ぶ。

なお、上記のように、「システムの更新」の対象としては、各ゲーム装置に共通してインストールされているアプリケーションも含まれる。例えば、「ＯＳ」と「メニューアプリケーション」の２つの更新対象があると想定する。この場合、まず「ＯＳ」の更新が実行され、この「ＯＳ」の更新の反映が行われる。その後、「メニューアプリケーション」の更新が実行され、「メニューアプリケーション」の更新の反映が行われる。そして、この２つの「更新」および「更新の反映」が行われた後に、ゲーム装置３の再起動が行われることになる。つまり「システムの更新」の対象が複数のソフトウェアコンポーネントにわたっている場合は、各コンポーネント単位で「更新」と「更新の反映」を行うようにしてもよい。

また、更新処理の具体的内容は、上記の例に限らない。例えば、制御システムを構成するデータが複数の種類のデータで構成されている場合を想定する。一例として、（Ａ）ＯＳ、（Ｂ）ＯＳに必要なデータ群１、（Ｃ）ＯＳに必要なデータ群２の３種類のデータで制御システムが構成されているとする。このような場合、（Ｂ）ＯＳに必要なデータ群１、のみを更新することで制御システムを更新することも可能である。すなわち、ダウンロードされる更新データには、（Ｂ）ＯＳに必要なデータ群１のみが含まれており、このデータ群１のみを更新するような処理としてもよい。つまり、データ単位で置き換えるような更新処理でもよい。
その他、上記"NEWSYSTEM"フォルダのような中間作業用のフォルダは用いずに、直接に上記"SYSTEM"フォルダ内のファイルを置き換えるような更新処理を行っても良い。

また、本実施形態では、上記電源オフ状態において上述のダウンロードや更新インストールの実行中に、ユーザによる電源オン操作が行われた場合、以下のように動作する。まず、低消費電力モードにおいて更新パッケージのダウンロードが行われている最中に電源オン操作が行われた場合は、一旦当該ダウンロードが中断される。そして、ノーマルモードに移行した後、中断したダウンロードがバックグラウンド処理として再開される。なお、ダウンロード完了後は、例えば、ユーザにシステムの更新データがあることを通知し、ユーザの操作に基づいて、ノーマルモードにおいてシステム更新インストールを行っても良い。あるいは、次に電源オフ状態に移行した際に、システム更新モードにて更新インストールを行うようにしても良い。

一方、システム更新モードにおける更新インストールの実行中に電源オン操作が行われたときは、更新インストールの処理はそのまま継続しながら、ノーマルモードへの移行を行う。具体的には、通電していなかった各ハードウェアコンポーネントにも通電を行い、テレビ２への映像、音声出力も行うことになる（上記ＬＥＤを実装している場合は、ノーマルモードを示す色で点灯させる）。その結果、ユーザから見ると、電源オン操作を行うことでテレビ２に画面が表示されるが、その画面には、例えばシステム更新インストールの進捗を示す画面が表示されていることになる（例えばプログレスバーが表示されている画面等）。この場合は、当該更新インストールの処理が終了するまで、ユーザはゲーム装置３を利用することができないことになる。

次に、図７〜図１１を参照して、本実施形態におけるゲーム装置３の動作をより詳細に説明する。

図７は、ゲーム装置３のフラッシュメモリ１４に格納されるデータの一例を示している。また、図８は、メインメモリ１２に格納されるデータの一例を示している。フラッシュメモリ１４には、更新パッケージデータ２０１、システムファイル２０２、更新システムファイル２０３、等が格納される。また、メインメモリ１２には、作業用展開データ２０４等、処理に必要なデータが適宜格納される。

更新パッケージデータ２０１は、所定のサーバからダウンロードすることで得られた更新パッケージのデータである。各種更新用のデータが圧縮されてパッケージ化されたものである。システムファイル２０２は、更新前の、すなわち、現在動作しているシステムにかかるシステムファイルである。例えば、上述した"SYSTEM"フォルダに格納されたシステムファイル（データ群）である。更新システムファイル２０３は、上記更新パッケージデータから抽出される、更新されたシステムファイルである。例えば、上述した"NEWSYSTEM"フォルダに格納されるデータ群である。

作業用展開データ２０４は、上記更新パッケージデータ２０１を展開したデータである。上記更新システムファイルの基になるデータや、ハードウェアコンポーネントのチップに書き込むための各種更新データが含まれる。

次に、図９〜図１１のフローチャートを参照して、電源オフ状態においてゲーム装置３で実行される処理の流れを説明する。

図９は、上記スタンバイモードにおけるゲーム装置３の動作の詳細を示すフローチャートである。スタンバイモードでは、電源制御部１８が実行主体となる。図９において、ステップＳ１で、電源制御部１８は、電源オンの操作が行われたか否かを判定する。その結果、電源オン操作が行われたときは（ステップＳ１でＹＥＳ）、ステップＳ２で、電源制御部１８は、ノーマルモード移行のための起動命令をＣＰＵ１１に発行する。その結果、ゲーム装置３は、上記ノーマルモードに移行する（ノーマルモードで起動する）。

一方、電源オンの操作が行われていないときは（ステップＳ１でＮＯ）、次に、ステップＳ３で、電源制御部１８は、ＲＴＣで計測された時間に基づき、低消費電力モードに移行する時間が到来したか否かを判定する。その結果、到来していれば（ステップＳ３でＹＥＳ）、電源制御部１８は、低消費電力モードとしてゲーム装置３を動作させるための起動命令をＣＰＵ１１に対して発行する。その結果、ＣＰＵ１１等、低消費電力モードの動作に最低限必要なハードウェアコンポーネントへの給電が行われ、ゲーム装置３は低消費電力モードに移行する（低消費電力モードとして起動する）ことになる。一方、低消費電力モードを起動する時間が到来していなければ（ステップＳ３でＮＯ）、上記ステップＳ１に戻り、処理が繰り返される。以上で、スタンバイモードにおけるゲーム装置３の動作の説明を終了する。

次に、低消費電力モードにおけるゲーム装置の動作について説明する。図１０は、低消費電力モードにおけるゲーム装置３の動作の詳細を示すフローチャートである。このモードでは、ＣＰＵ１１が動作主体となる。まず、ステップＳ１１で、ＣＰＵ１１は、無線通信部１５を介して所定のサーバと接続し、更新データ（システム更新、アプリの更新の双方）の有無をサーバに問い合わせる処理を実行する（更新チェック処理）。例えば、サーバから、各アプリやシステムの最新バージョンを示す更新リストのデータを受信する等の処理である。

次に、ステップＳ１２で、上記問い合わせの結果に基づいて、更新データが有るか否かを判定する。例えば、上記更新リストと、ゲーム装置３のシステムのバージョンやゲーム装置３にインストールされている各アプリのバージョンを比較することで、更新データの有無を判定する。当該判定の結果、更新データがないときは（ステップＳ１２でＮＯ）、後述のステップＳ１７の処理に進む。一方、更新データがあるときは（ステップＳ１２でＹＥＳ）、次に、ステップＳ１３で、ＣＰＵ１１は上記所定のサーバから、更新データをダウンロードする処理を実行する。

ダウンロード処理が終われば、ステップＳ１４で、ＣＰＵ１１は、今回行ったダウンロードにシステムの更新が含まれているか否かを判定する。これは、上記更新リストに基づいて判定しても良いし、ダウンロードしたデータのファイル名等から判定しても良い。つまり、システムの更新があるか否かが判定できれば、その判定手法はどのようなものでもよい。

上記判定の結果、システムの更新が含まれているときは（ステップＳ１４でＹＥＳ）、ステップＳ１５で、ＣＰＵ１１は、ゲーム装置３の動作モードをシステム更新モードに移行するため処理を実行する。すなわち、ゲーム装置３をシステム更新モードとして再起動させる処理が実行される。これにより、システム更新の対象となり得るハードウェアコンポーネントへの通電が行われる。また、例えばＣＰＵ１１の動作モードの変更（１コア動作から３コア動作への切換え）等も行われることになる。ゲーム装置３がシステム更新モードで起動すれば、後述する図１１の処理が実行されることになる。

一方、上記ステップＳ１４の判定の結果、システムの更新が含まれていないときは（ステップＳ１４でＮＯ）、ステップＳ１６で、ＣＰＵ１１は、その他の処理を適宜実行する。例えば、アプリケーションの更新データをダウンロードしていた場合は、アプリケーションの更新処理を行う。ここで、アプリケーションの更新については、基本的には、フラッシュメモリ１４に格納されているアプリケーションプログラムを、上記ダウンロードした更新データで上書きするという処理となる。そのため、ハードウェアコンポーネントのチップへの書き込み等が発生し得るシステムの更新と異なり、アプリケーションの更新については、低消費電力モードの状態でも実行可能である。

次に、ステップＳ１７で、ＣＰＵ１１は、低消費電力モードの次回の起動時間を設定する処理を行う。その後、ステップＳ１８で、ＣＰＵ１１は、低消費電力モードからスタンバイモードへの移行処理を実行する。

なお、上記のフローでは省略しているが、上記ダウンロードが完了する前に電源オン操作が行われたときは、低消費電力モードにおけるダウンロードは中断され、ノーマルモードへ移行する処理が実行されることになる。そして、ノーマルモードにおいて、バックグラウンドの処理として、中断したダウンロードが再開される。

以上で、低消費電力モードにおける処理の説明を終了する。

次に、図１１を用いて、システム更新モードにおけるゲーム装置３の動作の詳細を説明する。図１１は、システム更新モードにおけるゲーム装置３の動作の詳細を示すフローチャートである。このモードでも、動作主体はＣＰＵ１１となる。

ゲーム装置３がシステム更新モードに移行すると、まず、ステップＳ３１で、ＣＰＵ１１は、更新パッケージをインストールする処理を実行する。具体的には、圧縮されている更新パッケージデータ２０１を展開し、作業用展開データ２０４としてメインメモリ１２に格納する。更に、当該作業用展開データ２０４に基づいて、上記のように、所定のハードウェアコンポーネントのチップを書き換える処理や、更新にかかるシステムファイルをフラッシュメモリ１４（例えば上記"NEWSYSTEM"フォルダ）に格納する処理等を実行する。

次に、ステップＳ３２で、ＣＰＵ１１は、インストールが完了したか否かを判定する。当該判定の結果、インストールがまだ完了していなければ（ステップＳ３２でＮＯ）、上記ステップＳ３１に戻り、インストール処理を続行する。一方、インストールが完了すれば（ステップＳ３２でＹＥＳ）、ステップＳ３３で、ＣＰＵ１１は、更新を反映するための処理を行う。すなわち、上記のように"SYSTEM"フォルダを削除し、"NEWSYSTEM"フォルダの名前を"SYSTEM"に変名する、という処理が行われる。その後、ステップＳ３４で、ＣＰＵ１１は、スタンバイモードへの移行処理を実行する。これにより、スタンバイモードに移行した後、低消費電力モードあるいはノーマルモードに移行したタイミングが、ゲーム装置３の再起動に相当することになる。その結果、更新後のシステムでゲーム装置３が動作することになる。このことは、換言すれば、ユーザの同意・許諾を示す操作等を求めることなく、システム更新の反映を行い、更新後のシステムで動作させるともいえる。

なお、上記フローチャートでの図示は省略したが、システム更新モードにおいて電源オン操作が行われたときは、通電していなかった各ハードウェアコンポーネントにも通電が行われる。その結果、テレビ２への映像、音声出力も行われることになる。つまり、更新処理は継続しながら、全てのハードウェアコンポーネントへの通電を行うことで、ノーマルモードへの移行が行われる。また、この場合、更新処理が終われば、再起動を行い、再度ノーマルモードで起動するように構成すればよい。

以上で、システム更新モードにおける動作の説明を終了する。

このように、本実施形態では、ゲーム装置３が電源オフ状態のとき、一部のハードウェアコンポーネントにのみ通電を行うことで消費電力を抑えて動作する低消費電力モードに加え、ゲーム装置３をシステム更新処理が可能な状態としつつもユーザには電源オフ状態のように見せて動作するシステム更新モードを設けている。そして、このシステム更新モードでは、システムの更新に必要なハードウェアコンポーネントに通電を行っている。これにより、ゲーム装置３が電源オフ状態の間に、ユーザに気付かせることなくシステム更新処理を実行させることができ、ゲーム装置３の消費電力を抑えつつも、ユーザの利便性を高めることが可能となる。

なお、上記の例では、低消費電力モードにおいて更新パッケージのダウンロードを行い、そのインストールをシステム更新モードで行っていた。他の実施形態では、更新パッケージのダウンロードおよびインストールの双方をシステム更新モードで行うようによい。例えば、低消費電力モードにおいて上述の更新チェックを行い、その結果に基づき、システムの更新があるか否かを判定する。そして、システムの更新がある場合は、その時点で低消費電力モードからシステム更新モードに移行してもよい。そして、システム更新モードにおいて、更新パッケージのダウンロードとインストールの双方を実行するようにしてもよい。

また、上記実施形態では、更新したシステムの反映も電源オフ状態において行っていた。他の実施形態では、更新の反映については、例えばシステム更新モードでは行わずに、次にノーマルモードに移行した際に、更新の反映についてユーザの同意操作を要求するようにしてもよい。そして、ユーザの同意が得られれば、上述したようなフォルダの変名処理を行い、ゲーム装置３を再起動するような制御を行っても良い。

また、上記実施形態においては、情報処理システムの一例として据え置き型のゲームシステム１を例にして説明したが、これに限らず、例えば携帯型ゲーム機のような情報処理装置等にも上記の構成は適用可能である。また、ゲーム装置以外でも、例えばスマートフォンやいわゆるタブレット端末等の、ゲーム装置以外の情報処理装置や情報処理システムにも適用可能である。

１ ゲームシステム
２ テレビ
３ ゲーム装置
５ 入力装置
１１ プロセッサ
１２ メインメモリ
１４ フラッシュメモリ
１５ 無線通信部
１６ コントローラ通信部
１７ ディスクドライブ
１８ 電源制御部
１９ ＡＶ−ＩＣ
２０ ＧＰＵ
２１ ＤＰＳ

Claims (16)

1. ネットワークを介して外部装置と通信可能な情報処理装置であって、
   前記情報処理装置は、当該情報処理装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも２つの動作状態を切り替えて動作可能であり、
   前記低消費電力状態において、前記ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する更新確認手段と、
   前記更新が存在する場合、前記所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、前記低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始とを行う更新準備手段と、
   前記ダウンロードした更新データに基づいて、システムの更新インストールを実行する更新インストール手段と、を備え、
   前記更新確認手段、更新準備手段、更新インストール手段による一連の処理をユーザの操作によることなく自動的に実行する、情報処理装置。
2. 前記更新準備手段は、前記低消費電力状態では通電されていないハードウェアコンポーネントであって、前記更新の書き込み対象となるハードウェアコンポーネントへの通電を開始し、
   前記更新インストール手段は、前記更新準備手段によって通電された前記ハードウェアコンポーネントにかかる書き込みを伴うシステム更新インストールを実行する、請求項１に記載の情報処理装置。
3. 前記更新準備手段による処理は前記低消費電力状態において実行される、請求項１に記載の情報処理装置。
4. 前記情報処理装置は、前記更新インストール手段によるシステム更新インストールの終了後、ユーザの操作を求めることなく、更新後のシステムによる前記情報処理装置の動作を開始する、請求項１に記載の情報処理装置。
5. 前記情報処理装置は、前記更新インストール手段による更新インストール後、前記情報処理装置をシャットダウンする処理を実行するシャットダウン手段を更に備える、請求項１に記載の情報処理装置。
6. 前記情報処理装置は、前記シャットダウン手段によりシャットダウンされた後、当該情報処理装置の動作状態を前記低消費電力状態に自動的に切り替える、請求項５に記載の情報処理装置。
7. 前記情報処理装置は、
   ユーザの操作に基づいて情報処理装置の動作状態を前記通常使用状態以外の状態から前記通常使用状態へ切換えるためのユーザによる指示操作を受け付ける操作受付手段と、
   前記更新確認手段、更新準備手段、および更新インストール手段による一連の処理が行われている間に、前記操作受付手段が前記指示操作を受け付けたことに応じて、前記情報処理装置の動作状態を前記通常使用状態へ切替える通常状態移行手段とを更に備える、請求項１に記載の情報処理装置。
8. 前記情報処理装置は、
   前記低消費電力状態において前記ダウンロードが行われている間に、前記操作受付手段が前記ユーザによる指示操作を受け付けたときは、当該ダウンロード処理を中断するダウンロード中断手段と、
   前記動作状態が前記通常使用状態となった後、前記中断したダウンロードを再開する再開手段とを更に備える、請求項７に記載の情報処理装置。
9. 前記再開手段は、前記動作状態が前記通常使用状態になった後、バックグラウンド処理として前記ダウンロードを再開する、請求項８に記載の情報処理装置。
10. 前記更新インストール手段によるシステムの更新インストール処理中に、前記操作受付手段が前記ユーザによる指示操作を受け付けたときは、前記通常状態移行手段は、当該システムの更新インストール処理を継続しながら前記通常使用状態への切替えを行う、請求項７に記載の情報処理装置。
11. 前記情報処理装置は、前記更新確認手段、更新準備手段、および更新インストール手段による一連の処理の間、当該処理にかかる映像音声信号の外部機器への出力は行わない、請求項１に記載の情報処理装置。
12. 前記更新の対象となるソフトウェアには、第１の種類のソフトウェアと第２の種類のソフトウェアが含まれており、
    前記更新確認手段は、前記第１の種類のソフトウェアの更新の有無と、第２の種類のソフトウェアの更新の有無の双方を判定する判定手段を含み、
    前記更新準備手段および更新インストール手段による処理は、前記第１の種類のソフトウェアの更新があると判定されたときに実行される、請求項１に記載の情報処理装置。
13. 前記システムソフトウェアは前記第１の種類のソフトウェアに属し、当該システムソフトウェア以外のアプリケーションは前記第２の種類のソフトウェアに属する、請求項１２に記載の情報処理装置。
14. ネットワークを介して外部装置と通信可能な情報処理システムであって、
    前記情報処理システムは、当該情報処理システムを構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも２つの動作状態を切り替えて動作可能であり、
    前記低消費電力状態において、前記ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する更新確認手段と、
    前記更新が存在する場合、前記所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、前記低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始とを行う更新準備手段と、
    前記ダウンロードした更新データに基づいて、システムの更新インストールを実行する更新インストール手段とを備え、
    前記更新確認手段、更新準備手段、更新インストール手段による一連の処理をユーザの操作によることなく自動的に実行する、情報処理システム。
15. ネットワークを介して外部装置と通信可能な情報処理装置のコンピュータを制御するための情報処理方法であって、
    前記情報処理装置は、当該情報処理装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも２つの動作状態を切り替えて動作可能であり、
    前記低消費電力状態において、前記ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する更新確認ステップと、
    前記更新が存在する場合、前記所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、前記低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始とを行う更新準備ステップと、
    前記ダウンロードした更新データに基づいて、システムの更新インストールを実行する更新インストールステップとを備え、
    前記更新確認ステップ、更新準備ステップ、更新インストールステップによる一連の処理をユーザの操作によることなく自動的に実行する、情報処理方法。
16. ネットワークを介して外部装置と通信可能な情報処理装置のコンピュータに実行させる情報処理プログラムであって、
    前記情報処理装置は、当該情報処理装置を構成しているハードウェアコンポーネントのうちの一部にのみ通電している状態であり、かつ、所定のサーバとの通信が可能な状態である低消費電力状態と、当該低消費電力状態よりも多くのハードウェアコンポーネントに通電している状態であり、その消費電力も低消費電力状態より大きな状態である通常使用状態との少なくとも２つの動作状態を切り替えて動作可能であり、
    前記情報処理装置のコンピュータを、
    前記低消費電力状態において、前記ハードウェアコンポーネントへの書き込みを要するシステムソフトウェアの更新が少なくとも一つ以上存在するか否かを確認する更新確認手段と、
    前記更新が存在する場合、前記所定のサーバから当該更新に係る更新データをダウンロードする処理の実行と、前記低消費電力状態では通電されていないハードウェアコンポーネントのうち少なくとも一部への通電の開始とを行う更新準備手段と、
    前記ダウンロードした更新データに基づいて、システムの更新インストールを実行する更新インストール手段として機能させ、
    前記更新確認手段、更新準備手段、更新インストール手段による一連の処理をユーザの操作によることなく自動的に実行する、情報処理プログラム。

Images