情報処理プログラムおよび情報処理装置
【課題】 複数アプリ間で共用される情報を煩雑な操作なしで最新状態に保つ。
【解決手段】 情報処理装置（１０）では、第１−第３アプリによって共用されるセーブデータが、保存用データメモリ５２に、第１−第３アプリに対応させて第１−第３データＤａ−Ｄｃとして記憶される。コンピュータ（４２）は、たとえば第１アプリが起動されると、保存用データメモリ５２に記憶されている第１−第３データＤａ−Ｄｃをメインメモリ４８内で統合し（Ｓ７）、この統合データＤｉｎｔを第１アプリの実行に従って更新する（Ｓ１７）一方、自動保存指示やユーザによる保存指示に応じて、保存用データメモリ５２に記憶されている第１データＤａおよび第２データＤｂを更新された統合データＤｉｎｔで上書きする（Ｓ１９）。
【解決手段】 情報処理装置（１０）では、第１−第３アプリによって共用されるセーブデータが、保存用データメモリ５２に、第１−第３アプリに対応させて第１−第３データＤａ−Ｄｃとして記憶される。コンピュータ（４２）は、たとえば第１アプリが起動されると、保存用データメモリ５２に記憶されている第１−第３データＤａ−Ｄｃをメインメモリ４８内で統合し（Ｓ７）、この統合データＤｉｎｔを第１アプリの実行に従って更新する（Ｓ１７）一方、自動保存指示やユーザによる保存指示に応じて、保存用データメモリ５２に記憶されている第１データＤａおよび第２データＤｂを更新された統合データＤｉｎｔで上書きする（Ｓ１９）。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、情報処理プログラムおよび情報処理装置に関し、特にたとえば、複数のアプリケーション（ソフトウェア）の間で、セーブデータなどの情報を共用する、情報処理プログラムおよび情報処理装置に関する。
【背景技術】
【０００２】
この種の背景技術としては、たとえば特許文献１に開示されたものが知られている。この背景技術では、シリーズ化されたソフトウェア間で、古いソフトウェアのセーブデータが新しいソフトウェアでも利用できたり、新しいソフトウェアのセーブデータが古いソフトウェアでも利用できたりする。具体的には、あるソフトウェアを起動したときに、他のソフトウェアのセーブデータが存在するか否かを判別して、セーブデータが存在する場合に、当該セーブデータに関する情報を表示して、使用するセーブデータをユーザに選択させるようになっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１８３０６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記の背景技術では、古いセーブデータであってもいつまでも残存する可能性があるため、ユーザが誤って古いセーブデータを選択することがあったり、セーブデータの選択時にセーブデータの生成日時や更新日時を確認する作業が必要になったりするという問題があった。
【０００５】
それゆえに、この発明の主たる目的は、新規な、情報処理プログラムおよび情報処理装置を提供することである。
【０００６】
この発明の他の目的は、複数アプリ間で共用されるセーブデータなどの情報を煩雑な操作なしで最新状態に保つことができる、情報処理プログラムおよび情報処理装置を提供することである。
【課題を解決するための手段】
【０００７】
この発明は、上記の課題を解決するために、以下の構成を採用した。
【０００８】
第１の発明は、記憶手段に接続されたコンピュータを、アプリケーション実行手段、更新手段、および第１上書き手段として機能させる、情報処理プログラムである。記憶手段には、第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータが、第１アプリケーションに対応させて第１データとして記憶されると共に、第２アプリケーションに対応させて第２データとしても記憶される。すなわち、データは、第１アプリ用の第１データおよび第２アプリ用の第２データとして２通りに記憶される。アプリケーション実行手段は、所定のデータで第１アプリケーションを実行する。更新手段は、アプリケーション実行手段による第１アプリケーションの実行にしたがって所定のデータを更新する。第１上書き手段は、記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする。
【０００９】
第１の発明によれば、第１のアプリケーションの実行にしたがって更新された所定のデータを、第１のアプリケーションに対応させた第１データと第２のアプリケーションに対応させた第２データに上書きするため、第１データおよび第２データを煩雑な操作なしで最新状態に保つことができる。
【００１０】
第２の発明は、第１の発明に従属する情報処理プログラムであって、コンピュータを、統合手段としてさらに機能させ、アプリケーション実行手段は、統合手段によって統合された統合データで第１アプリケーションを実行する。統合手段は、記憶手段に記憶されている第１データおよび第２データを統合する。第１アプリケーションは、こうして統合された統合データで実行される。
【００１１】
第２の発明によれば、以前の第１アプリケーションおよびは第２アプリケーションの実行により更新されている第１データおよび第２データを統合して第１アプリケーションの実行で更新し、更新したデータを第１データおよび第２データに上書きするため、第１データおよび第２データを以前のアプリケーションの実行結果が反映されたものにすることができる。さらに、上書きされた後の第１データおよび第２データの何れかが消失した場合や破損した場合であっても、最新状態に保たれている一方のデータを用いて各アプリケーションを実行できる。
【００１２】
第３の発明は、第１の発明に従属する情報処理プログラムであって、第１上書き手段は、所定の指示に応じて、記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする。
【００１３】
第３の発明によれば、適切なタイミングで第１データと第２データを最新状態に保つことができる。
【００１４】
なお、好ましくは、記憶手段は、不揮発性メモリたとえばフラッシュメモリなどの保存用データメモリを含み、統合および更新の各処理は、揮発性メモリたとえばコンピュータに接続されたメインメモリあるいはコンピュータの内蔵メモリ上で行われる。ただし、場合によっては、統合および更新の各処理も記憶手段内で行ってよい。
【００１５】
第４の発明は、第２の発明に従属する情報処理プログラムであって、コンピュータを、起動手段としてさらに機能させ、統合手段は、起動手段によって第１アプリケーションが起動されたときに統合を行う。起動手段は、第１アプリケーションを起動させ、統合手段は、起動手段が第１アプリケーションを起動させたときに第１データおよび第２データの統合を行う。
【００１６】
第４の発明によれば、第１アプリケーションの起動時に第１データおよび第２データを統合するため、最新のデータで第１アプリケーションの実行を開始させることができる。
【００１７】
第５の発明は、第４の発明に従属する情報処理プログラムであって、コンピュータを、第２上書き手段としてさらに機能させる。第２上書き手段は、記憶手段に記憶されている第１データおよび第２データを、第１アプリケーションが起動されたときに統合手段によって統合された統合データで、第１アプリケーションの実行が開始される前に上書きする。
【００１８】
第５の発明によれば、第１アプリケーションの起動時に、第１データおよび第２データを統合して、統合結果を速やかに第１データおよび第２データに反映させるので、第１アプリケーションの実行により更新された統合データが第１データおよび第２データに上書きされる前にコンピュータの電源オフ等によりアプリケーションが終了した場合であっても、第１データおよび第２データを統合後の新しいデータにすることができる。
【００１９】
第６の発明は、第５の発明に従属する情報処理プログラムであって、第１および／または第２上書き手段は、記憶手段に記憶されている第１データおよび／または第２データのうち、統合手段によって統合された統合データと異なる部分を上書きする。
【００２０】
第６の発明によれば、効率的な上書きが行える。
【００２１】
第７の発明は、第２ないし第６のいずれかの発明に従属する情報処理プログラムであって、データの共用部分は複数の項目に区分されており、統合手段は第１データおよび第２データを項目毎に統合する。
【００２２】
第７の発明によれば、項目によって異なる統合ルールを適用できるので、多様な統合が実現できる。
【００２３】
第８の発明は、第７の発明に従属する情報処理プログラムであって、複数の項目の各々は、それぞれに１つのファイルが割り当てられた複数のグループのいずれか１つに属しており、第１および／または第２上書き手段は、第１データおよび第２データをファイル単位で上書きする。
【００２４】
第８の発明によれば、項目をグループ分けしてファイルに収め、上書きをファイル単位で行うようにしたので、上書きの効率を向上させることと、記憶手段としてフラッシュメモリを用いることとが容易になる。
【００２５】
第９の発明は、第８の発明に従属する情報処理プログラムであって、第１および／または第２上書き手段は、複数のグループ毎にそこに含まれる全ての項目について変化があるか否かを判定し、判定結果が肯定である項目を少なくとも１つ含むグループに対応するファイルについて上書きを行う。
【００２６】
第９の発明によれば、効率よく上書きが行える。
【００２７】
第１０の発明は、第８または第９の発明に従属する情報処理プログラムであって、統合手段は、各ファイルの属性および／または各項目の実体に応じたルールに従って統合を行う。
【００２８】
第１０の発明によれば、多様な統合を効率よく行える。
【００２９】
第１１の発明は、第１０の発明に従属する情報処理プログラムであって、属性は、各ファイルが更新日時データを含むか否かに関し、ルールは、各ファイルが更新日時データを含んでいれば最新ファイルのデータを採用するという最新採用ルールを含む。
【００３０】
第１１の発明によれば、統合にあたって最新データを採用するので、第１データおよび第２データに古いデータが残らないようにすることができる。
【００３１】
第１２の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体がアプリケーションの進行状況に関連するフラグである場合にはどれかのデータでフラグが立っていればフラグを立てるというフラグルールを含む。
【００３２】
第１３の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体が値である場合には最も良い値を採用するという最良値ルールを含む。
【００３３】
第１４の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体がデータの管理情報である場合には論理和により採用するという論理和ルールを含む。
【００３４】
第１４の発明によれば、管理情報を漏れなく採用できる。
【００３５】
第１５の発明は、第１４の発明に従属する情報処理プログラムであって、論理和ルールには、同じ管理情報の異なるデータがあればどれも採用しないという条件がつく。
【００３６】
第１５の発明では、同じ管理情報が割り当てられているのにデータ自体は異なっている（たとえば同じ写真管理情報が割り当てられているのに画像データは別物である）という場合、どの管理情報も採用されない。
【００３７】
第１５の発明によれば、間違っている可能性のある管理情報を排除できる。
【００３８】
第１６の発明は、第３の発明に従属する情報処理プログラムであって、所定の指示は自動保存指示を含む。
【００３９】
第１６の発明では、上書きは自動保存指示に応じて実行される。
【００４０】
第１６の発明によれば、ユーザは保存指示を行わなくてよいので、操作量が削減される。
【００４１】
なお、所定の指示は、ユーザによる保存指示を含んでもよい。この場合、上書きは、ユーザによる保存指示に応じて実行される。したがって、ユーザが指示するまでは上書きは行われないので、コンピュータや記憶手段への負荷を減らすことができる。
【００４２】
第１７の発明は、第１の発明に従属する情報処理プログラムであって、データは、第１アプリケーションおよび第２アプリケーションの各アプリケーションの実行により変化する当該各アプリケーションに関連するパラメータを示すデータである。
【００４３】
第１８の発明は、第２の発明に従属する情報処理プログラムであって、コンピュータを、制御手段としてさらに機能させる。制御手段は、記憶手段に記憶されている第１データに異常がある場合に、記憶手段に記憶されている第２データを利用して当該異常を修復するように統合手段を制御する。
【００４４】
第１８の発明によれば、統合を通じて異常を修復できる。
【００４５】
第１９の発明は、第１８の発明に従属する情報処理プログラムであって、制御手段は、第１データに対応する更新日時データが現在日時に対して未来かつ同日を示す場合には当該現在日時を示すように当該更新日時データを変更する一方、未来かつ翌日以降を示す場合には当該第１データを無効化する、日時制御手段を含む。
【００４６】
第１９の発明によれば、更新日時データの示す日時が未来であっても当日であれば、現在日時を示すように更新日時データを変更するに止め、翌日以降であれば、第１データ自体を無効化するので、当日のデータを生かして統合が行える。
【００４７】
第２０の発明は、第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段、所定のデータで第１アプリケーションを実行するアプリケーション実行手段、アプリケーション実行手段による第１アプリケーションの実行にしたがって所定のデータを更新する更新手段、および記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする第１上書き手段を備える、情報処理装置である。
【００４８】
第２０の発明でも、第１の発明と同様に、第１データおよび第２データを煩雑な操作なしで最新状態に保つことができる。
【発明の効果】
【００４９】
この発明によれば、複数アプリ間で共用されるセーブデータなどの情報を煩雑な操作なしで最新状態に保つことができる、情報処理プログラムおよび情報処理装置が実現される。
【００５０】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【００５１】
【図１】この発明の一実施例であるゲーム装置の外観図であり、開状態における正面を示す。
【図２】ゲーム装置の外観図であり、開状態における側面を示す。
【図３】ゲーム装置の外観図であり、（Ａ）は閉状態における一方側面を、（Ｂ）は閉状態における上面を、（Ｃ）は閉状態における他方側面を、そして（Ｄ）は閉状態における下面をそれぞれ示す。
【図４】ゲーム装置がユーザによって把持された様子を示す図解図である。
【図５】ゲーム装置の電気的構成の一例を示すブロック図である。
【図６】顔トレーニングの流れを説明するための図解図であり、（Ａ）はアプリ選択画面を示し、（Ｂ）はトレーニング選択画面を示し、（Ｃ）はトレーニング画面を示し、（Ｄ）は表情測定画面を示す。
【図７】ゲーム装置のメモリマップ図であり、（Ａ）は保存用データメモリの一部を示し、（Ｂ）はメインメモリの一部を示す。
【図８】セーブデータの構成例を示す図解図である。
【図９】項目テーブルの構成例を示す図解図である。
【図１０】統合ルールテーブルの構成例を示す図解図である。
【図１１】統合ルールの項目への適用例を示す図解図である。
【図１２】ファイル管理テーブルの構成および制御の一例を示す図解図であり、（Ａ）が制御前に対応し、（Ｂ）が制御後に対応する。
【図１３】ＣＰＵ動作の一部を示すフロー図である。
【図１４】ＣＰＵ動作の他の一部を示すフロー図である。
【図１５】ＣＰＵ動作のその他の一部を示すフロー図である。
【図１６】ＣＰＵ動作のさらにその他の一部を示すフロー図である。
【図１７】ＣＰＵ動作の他の一部を示すフロー図である。
【図１８】ＣＰＵ動作のその他の一部を示すフロー図である。
【発明を実施するための形態】
【００５２】
図１−図３には、本発明の一実施例であるゲーム装置１０の外観が示される。ゲーム装置１０は折り畳み型のゲーム装置であり、図１および図２は、開いた状態（開状態）におけるゲーム装置１０を示し、図３は、閉じた状態（閉状態）におけるゲーム装置１０を示している。また、図１は、開状態におけるゲーム装置１０の正面図であり、図２は、開状態におけるゲーム装置の側面図である。ゲーム装置１０は、２つの表示装置（ＬＣＤ１２および１４）および２つのカメラ（カメラ１６および１８）を有し、カメラによって画像を撮像し、撮像した画像を画面に表示したり、撮像した画像のデータを保存したりすることができる。
【００５３】
ゲーム装置１０は、開いた状態において両手または片手で把持することができるような小型のサイズとされる。
【００５４】
ゲーム装置１０は、下側ハウジング２０および上側ハウジング２２という２つのハウジングを有する。下側ハウジング２０と上側ハウジング２２とは、開閉可能（折り畳み可能）に接続されている。この実施例では、各ハウジング２０および２２はともに横長の長方形の板状形状であり、互いの長辺部分で回転可能に接続されている。
【００５５】
上側ハウジング２２は、下側ハウジング２０の上側の一部で回動自在に支持されている。これによって、ゲーム装置１０は、閉状態（下側ハウジング２０と上側ハウジング２２とのなす角度が約０°の状態（図３参照））と、開状態（下側ハウジング２０と上側ハウジング２２とのなす角度が約１８０°の状態（図２参照））とをとることができる。ユーザは通常、開状態でゲーム装置１０を使用し、ゲーム装置１０を使用しない場合には閉状態としてゲーム装置１０を保管する。また、ゲーム装置１０は、上記閉状態および開状態のみでなく、下側ハウジング２０と上側ハウジング２２とのなす角度を、ヒンジに発生する摩擦力などによって閉状態と開状態との間の任意の角度に維持することができる。つまり、上側ハウジング２２を下側ハウジング２０に対して任意の角度で静止させることができる。
【００５６】
まず、下側ハウジング２０に設けられる構成について説明する。図１に示すように、ゲーム装置１０は、下側ＬＣＤ（液晶表示装置）１２を有する。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング２０の長辺方向に一致するように配置される。下側ＬＣＤ１２は下側ハウジング２０に収納される。下側ＬＣＤ１２は、下側ハウジング２０の内側面に設けられる。したがって、ゲーム装置１０を使用しない場合には閉状態としておくことによって、下側ＬＣＤ１２の画面が汚れたり傷ついたりすることを防止することができる。なお、この実施例では表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置など、他の任意の表示装置を利用してもよい。また、ゲーム装置１０は任意の解像度の表示装置を利用することができる。なお、ゲーム装置１０を撮像装置として利用する場合、下側ＬＣＤ１２は主に、カメラ１６または１８で撮像されている画像をリアルタイムに表示（スルー表示）するために用いられる。
【００５７】
下側ハウジング２０の内側面はほぼ平面状に形成される。当該内側面の中央には、下側ＬＣＤ１２を露出させるための開口部２０ｂが形成される。当該開口部２０ｂの左側（図示ｙ軸負側）には開口部２０ｃが形成され、当該開口部２０ｂの右側には開口部２０ｄが形成される。開口部２０ｂおよび２０ｃは、各キートップ（各ボタン２４ａ−２４ｅの上面）を露出させるためのものである。そして、下側ハウジング２０の内部に収納される下側ＬＣＤ１２の画面が開口部２０ｂから露出し、各キートップが開口部２０ｃおよび２０ｄから露出される。このように、下側ハウジング２０の内側面には、中央に設けられる下側ＬＣＤ１２用の開口部２０ｂの左右両側に非画面領域（図１に示す点線領域Ａ１およびＡ２。具体的には、各ボタン２４ａ−２４ｅを配置するための領域；ボタン配置領域）がそれぞれ設けられる。
【００５８】
下側ハウジング２０には、入力装置として、各ボタン２４ａ−２４ｉおよびタッチパネル２８が設けられる。図１に示されるように、各ボタン２４ａ−２４ｉのうち、方向入力ボタン２４ａ、ボタン２４ｂ、ボタン２４ｃ、ボタン２４ｄ、ボタン２４ｅ、および電源ボタン２４ｆは、下側ハウジング２０の内側面に設けられる。方向入力ボタン２４ａは例えば選択操作等に用いられ、各ボタン２４ｂ−２４ｅは例えば決定操作やキャンセル操作等に用いられる。電源ボタン２４ｆは、ゲーム装置１０の電源をオン／オフするために用いられる。ここでは、方向入力ボタン２４ａおよび電源ボタン２４ｆは、下側ハウジング２０の中央付近に設けられる下側ＬＣＤ１２に対して一方の側の（図１では左側）に設けられ、ボタン２４ｂ−２４ｅは下側ＬＣＤ１２に対して他方の側（図１では右側）に設けられる。方向入力ボタン２４ａおよびボタン２４ｂ−２４ｅは、ゲーム装置１０に対する各種操作を行うために用いられる。
【００５９】
図３（Ａ）は閉状態におけるゲーム装置１０の左側面図であり、図３（Ｂ）は当該ゲーム装置１０の正面図であり、図３（Ｃ）は当該ゲーム装置１０の右側面図であり、そして図３（Ｄ）は当該ゲーム装置１０の背面図である。図３（Ｃ）に示されるように、また、図３（Ａ）に示されるように、音量ボタン２４ｉは、下側ハウジング２０の左側面に設けられる。音量ボタン２４ｉは、ゲーム装置１０が備えるスピーカ３４の音量を調整するために用いられる。また、図３（Ｄ）に示されるように、ボタン２４ｈは、下側ハウジング２０の上面の右端部に設けられる。ボタン２４ｇは、下側ハウジング２０の上面の左端部に設けられる。各ボタン２４ｇおよび２４ｈは、ゲーム装置１０に対して例えば撮影指示操作（シャッタ操作）を行うために用いられる。各ボタン２４ｇおよび２４ｈの両方をシャッターボタンとして機能させてもよく、この場合、右利きのユーザはボタン２４ｈを使用し、左利きのユーザはボタン２４ｇを使用することができ、いずれのユーザにも使い勝手が良い。なお、ゲーム装置１０は、各ボタン２４ｇおよび２４ｈを常にシャッターボタンとして有効としておいてもよいし、右利きか左利きかの設定をして（メニュープログラムなどによりユーザに設定入力をさせ、設定されたデータを記憶しておく）、右利き設定のときにはボタン２４ｈのみ有効とし、左利き設定のときにはボタン２４ｇのみ有効とするようにしてもよい。
【００６０】
図１に示されるように、ゲーム装置１０は、各操作ボタン２４ａ−２４ｉとは別の入力装として、タッチパネル２８をさらに備えている。タッチパネル２８は、下側ＬＣＤ１２の画面上に装着されている。なお、この実施例では、タッチパネル２８は抵抗膜方式のタッチパネルである。ただし、タッチパネルは抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。この実施例では、タッチパネル２８として、下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル２８の解像度と下側ＬＣＤ１２の解像度が一致している必要はない。また、下側ハウジング２０の右側面には挿入口３０（図１および図３（Ｄ）に示す点線）が設けられている。挿入口３０は、タッチパネル２８に対する操作を行うために用いられるタッチペン３６を収納することができる。なお、タッチパネル２８に対する入力は通常タッチペン３６を用いて行われるが、タッチペン３６に限らずユーザの指でタッチパネル２８を操作することも可能である。
【００６１】
図３（Ａ）に示されるように、下側ハウジング２０の右側面には開閉可能なカバー部１１Ｂが設けられる。このカバー部１１Ｂの内側には、ゲーム装置１０とメモリカード３８とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード３８は、コネクタに着脱自在に装着される。メモリカード３８は、例えば、ゲーム装置１０によって撮像された画像のデータを記憶（保存）するために用いられる。
【００６２】
図１に示されるように、下側ハウジング２０の軸部２０ａの左側部分には、３つのＬＥＤ２６ａ−２６ｃが取り付けられる。ここで、ゲーム装置１０は他の機器との間で無線通信を行うことが可能であり、第１ＬＥＤ２６ａは、無線通信が確立している場合に点灯する。第２ＬＥＤ２６ｂは、ゲーム装置１０の充電中に点灯する。第３ＬＥＤ２６ｃは、ゲーム装置１０の電源がオンである場合に点灯する。したがって、３つのＬＥＤ２６ａ−２６ｃによって、ゲーム装置１０の通信確立状況、充電状況、および、電源のオン／オフ状況をユーザに通知することができる。
【００６３】
以上に説明したように、下側ハウジング２０には、ゲーム装置１０に対する操作入力を行うための入力装置（タッチパネル２８および各ボタン２４ａ−２４ｉ）が設けられる。したがって、ユーザは、ゲーム装置１０を使用する際には下側ハウジング２０を把持してゲーム装置１０に対する操作を行うことができる。図４は、ユーザがゲーム装置１０を両手で把持した様子を示す図である。図４に示すように、ユーザは、各ＬＣＤ１２および１４がユーザの方向を向く状態で、両手の掌と中指、薬指および小指とで下側ハウジング２０の側面および外側面（内側面の反対側の面）を把持する。このように把持することで、ユーザは、下側ハウジング２０を把持したまま、各ボタン２４ａ−２４ｅに対する操作を親指で行い、ボタン２４ｇおよび２４ｈに対する操作を人差し指で行うことができる。
【００６４】
一方、上側ハウジング２２には、画像を撮像するための構成（カメラ）、および、撮像した画像を表示するための構成（表示装置）が設けられる。以下、上側ハウジング２２に設けられる構成について説明する。
【００６５】
図１に示すように、ゲーム装置１０は、上側ＬＣＤ１４を有する。上側ＬＣＤ１４は上側ハウジング２２に収納される。上側ＬＣＤ１４は横長形状であり、長辺方向が上側ハウジング２２の長辺方向に一致するように配置される。上側ＬＣＤ１４は、上側ハウジング２２の内側面（ゲーム装置１０が閉状態となった場合に内側となる面）に設けられる。したがって、ゲーム装置１０を使用しない場合には閉状態としておくことによって、上側ＬＣＤ１４の画面が汚れたり傷ついたりすることを防止することができる。なお、下側ＬＣＤ１２と同様、上側ＬＣＤ１４に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、他の実施形態においては、上側ＬＣＤ１４上にもタッチパネルを設けてもよい。
【００６６】
また、ゲーム装置１０は、２つのカメラ１６および１８を有する。各カメラ１６および１８はともに上側ハウジング２２に収納される。図１に示されるように、内側カメラ１６は、上側ハウジング２２の内側面に取り付けられる。一方、図３（Ｂ）に示されるように、外側カメラ１８は、内側カメラ１６が取り付けられる面の反対側の面、すなわち、上側ハウジング２２の外側面（ゲーム装置１０が閉状態となった場合に外側となる面）に取り付けられる。これによって、内側カメラ１６は、上側ハウジング２２の内側面が向く方向を撮像することが可能であり、外側カメラ１８は、内側カメラ１６の撮像方向の逆方向、すなわち、上側ハウジング２２の外側面が向く方向を撮像することが可能である。以上のように、この実施例では、２つのカメラ１６および１８が撮像方向が互いに逆方向となるように設けられる。したがって、ユーザはゲーム装置１０を持ち替えることなく、異なる２方向を撮像することができる。例えば、ユーザは、ゲーム装置１０からユーザの方を見た景色を内側カメラ１６で撮影することができるとともに、ゲーム装置１０からユーザの反対側の方向を見た景色を外側カメラ１８で撮影することができる。
【００６７】
また、内側カメラ１６は、上側ハウジング２２の下側の中央部に形成される軸部２２ａの中央に取り付けられる。つまり、内側カメラ１６は、２つのハウジング２０および２２が接続される部分の中央に取り付けられる。したがって、ゲーム装置１０を開状態にした場合、内側カメラ１６は、２つのＬＣＤ１２および１４の間に配置されることになる（図１参照）。換言すれば、内側カメラ１６は、ゲーム装置１０の中心付近に配置されることになる。なお、「ゲーム装置１０の中心」とは、ゲーム装置１０の操作面（開状態における各ハウジング２０および２２の内側面からなる面）の中心という意味である。なお、内側カメラ１６は、ＬＣＤ１２および１４の横方向の中心付近に配置されているということもできる。
【００６８】
この実施例では、ゲーム装置１０を開状態にした場合に内側カメラ１６はゲーム装置１０の中心付近に配置されるので、ユーザは、内側カメラ１６によってユーザ自身を撮影する場合、ユーザがゲーム装置１０に正対する位置でゲーム装置１０を把持すればよい。つまり、通常の把持位置でゲーム装置を把持すれば、ユーザは撮像範囲の中心付近に位置することになり、ユーザ自身を撮像範囲内に収めることが容易になる。
【００６９】
また、図３（Ｂ）に示されるように、外側カメラ１８は、ゲーム装置１０を開状態とした場合において上側ハウジング２２の上部（下側ハウジング２０から遠い側の部分）に配置される。なお、外側カメラ１８は、ゲーム装置１０を把持するユーザを撮影するものではないので、ゲーム装置１０の中心に設ける必要性は高くない。
【００７０】
また、図１または図３（Ｂ）に示されるように、マイク３２は、上側ハウジング２２に収納されている。具体的には、マイク３２は、上側ハウジング２２の軸部２２ａに取り付けられる。この実施例では、マイク３２は、内側カメラ１６の周囲（図ではｙ軸の側方）に取り付けられ、より具体的には、内側カメラ１６からｙ軸正方向側の側方に取り付けられる。また、軸部２２ａにおいては、マイク３２がゲーム装置１０外部の音を検知することができるように、マイク３２に対応する位置（内側カメラ１６の側方）にマイクロフォン用孔２２ｃが設けられる。
【００７１】
なお、マイク３２は下側ハウジング２０に収納されてもよい。たとえば、マイクロフォン用孔２２ｃを下側ハウジング２０の内側面、具体的には下側ハウジング２０の内側面の左下部分（ボタン配置領域Ａ１）に設け、マイク３２を、下側ハウジング２０内における、マイクロフォン用孔２２ｃの近傍に配置することができる。また、マイク３２は、その集音方向（感度が最大となる方向）が内側カメラ１６の撮像方向（光軸）と略並行（言い換えれば集音方向および撮像方向がそれぞれｙ軸と略並行）となる向きに取り付けられる。これによって、内側カメラ１６の撮像範囲内で発せられた音声は、マイク３２によって好適に捉えられる。すなわち、マイク３２入力の検出とユーザの検出とを同時行うことができるとともに、検出の精度を向上させることができる。
【００７２】
図３（Ｂ）に示されるように、上側ハウジング２２の外側面には、第４ＬＥＤ２６ｄが取り付けられる。第４ＬＥＤ２６ｄは、外側カメラ１８の周囲（この実施例では、外側カメラ１８の右側）に取り付けられる。第４ＬＥＤ２６ｄは、内側カメラ１６または外側カメラ１８によって撮影が行われた（シャッターボタンが押下された）時点で点灯する。また、内側カメラ１６または外側カメラ１８によって動画が撮影される間点灯する。第４ＬＥＤ２６ｄによって、ゲーム装置１０による撮影が行われた（行われている）ことを撮影対象者に通知することができる。
【００７３】
また、上側ハウジング２２の内側面はほぼ平面状に形成される。図１に示すように、当該内側面の中央には、上側ＬＣＤ１４を露出させるための開口部２１Ｂが形成される。上側ハウジング２２の内部に収納される上側ＬＣＤ１４の画面は、開口部２１Ｂから露出する。また、上記開口部２１Ｂの左右両側には音抜き孔２２ｄがそれぞれ１つずつ形成される。音抜き孔２２ｄの奥の上側ハウジング２２内にはスピーカ３４が収納されている。音抜き孔２２ｄは、スピーカ３４からの音を外部に放出するための孔である。
【００７４】
このように、上側ハウジング２２の内側面には、中央に設けられる上側ＬＣＤ１４用の開口部２１Ｂの左右両側に非画面領域（図１に示す点線領域Ｂ１およびＢ２。具体的には、スピーカ３４を配置するための領域；スピーカ配置領域）がそれぞれ設けられる。２つの音抜き孔２２ｄは、左右方向については、各スピーカ配置領域の左右方向における中央部付近に配置され、上下方向については、各スピーカ配置領域の下部領域（下側ハウジング２０に近い側の領域）に配置される。
【００７５】
なお、上記のように、下側ハウジング２０および上側ハウジング２２に左右方向に関して同じ位置に非画面領域をそれぞれ設けたことで、ゲーム装置１０は、図４に示すような横持ちで把持される場合だけでなく、縦持ち（図４に示す状態からゲーム装置１０を左または右回りに９０°回転させた状態）で把持される場合にも持ちやすい構成となっている。
【００７６】
以上に説明したように、上側ハウジング２２には、画像を撮像するための構成であるカメラ１６および１８、および、撮像された画像を表示するための表示手段である上側ＬＣＤ１４が設けられる。一方、下側ハウジング２０には、ゲーム装置１０に対する操作入力を行うための入力装置（タッチパネル２８および各ボタン２４ａ−２４ｉ）が設けられる。したがって、ゲーム装置１０を撮像装置として使用する際には、ユーザは、上側ＬＣＤ１４に表示される撮像画像（カメラによって撮像された画像）を見ながら、下側ハウジング２０を把持して入力装置に対する入力を行うことができる。
【００７７】
また、上側ハウジング２２のカメラ１６近傍には、音声を入力するための構成であるマイク３２が設けられており、したがってゲーム装置１０は、録音装置としても使用可能である。さらに、ユーザがマイク３２を通して音声入力を行い、ゲーム装置１０はこのマイク入力情報に基づいてゲーム処理やゲーム以外のアプリケーション処理を実行することもできる。
【００７８】
図５は、ゲーム装置１０の内部構成（電気的構成）を示すブロック図である。図５に示すように、ゲーム装置１０は、ＣＰＵ４２、メインメモリ４８、メモリ制御回路５０、保存用データメモリ５２、プリセットデータ用メモリ５４、メモリカードインターフェース（メモリカードＩ／Ｆ）４４、無線通信モジュール５６、ローカル通信モジュール５８、リアルタイムクロック（ＲＴＣ）３９、電源回路４６、およびインターフェース回路（Ｉ／Ｆ回路）４０等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング２０（または上側ハウジング２２でもよい）内に収納される。
【００７９】
ＣＰＵ４２は、各種のプログラムを実行するための情報処理手段である。ゲーム装置１０を撮像装置として利用する場合には、そのためのプログラムがゲーム装置１０内のメモリ（例えば保存用データメモリ５２）に記憶される。ＣＰＵ４２が当該プログラムを実行することで、ゲーム装置１０は撮影装置として機能する。なお、ＣＰＵ４２によって実行されるプログラムは、ゲーム装置１０内のメモリに予め記憶されていてもよいし、メモリカード３８から取得されてもよいし、他の機器との通信によって他の機器から取得されても、あるいはインターネットを通じてサーバからダウンロードされてもよい。
【００８０】
ＣＰＵ４２には、メインメモリ４８、メモリ制御回路５０、およびプリセットデータ用メモリ５４が接続される。また、メモリ制御回路５０には保存用データメモリ５２が接続される。メインメモリ４８は、ＣＰＵ４２のワーク領域やバッファ領域として用いられる記憶手段である。すなわち、メインメモリ４８は、ゲーム処理に用いられる各種データを記憶したり、外部（メモリカード３８や他の機器等）から取得されるプログラムを記憶したりする。この実施例では、メインメモリ４８として例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。保存用データメモリ５２は、ＣＰＵ４２によって実行されるプログラムや各カメラ１６および１８によって撮像された画像のデータ、ゲームやアプリケーションのセーブデータ等を記憶するための記憶手段である。保存用データメモリ５２は、例えばＮＡＮＤ型フラッシュメモリで構成される（ＮＯＲ型フラッシュメモリや他の不揮発性メモリを用いてもよい）。メモリ制御回路５０は、ＣＰＵ４２の指示に従って、保存用データメモリ５２に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ５４は、ゲーム装置１０において予め設定される各種パラメータ等のデータ（プリセットデータ）を記憶するための記憶手段である。プリセットデータ用メモリ５４としては、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）バスによってＣＰＵ４２と接続されるフラッシュメモリを用いることができる。
【００８１】
メモリカードＩ／Ｆ４４はＣＰＵ４２に接続される。メモリカードＩ／Ｆ４４は、コネクタに装着されたメモリカード３８に対するデータの読み出しおよび書き込みをＣＰＵ４２の指示に従って行う。この実施例では、各カメラ１６および１８によって撮像された画像データがメモリカード３８に書き込まれたり、メモリカード３８に記憶された画像データがメモリカード３８から読み出されて保存用データメモリ５２に記憶されたりする。
【００８２】
無線通信モジュール５６は、例えばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール５８は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール５６およびローカル通信モジュール５８はＣＰＵ４２に接続される。ＣＰＵ４２は、無線通信モジュール５６を用いてインターネットを介して他の機器との間でデータを送受信したりサーバ（図示せず）からプログラムをダウンロードしたり、ローカル通信モジュール５８を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
【００８３】
また、ＣＰＵ４２には、ＲＴＣ６０および電源回路４６が接続される。ＲＴＣ６０は、時間をカウントしてＣＰＵ４２に出力する。ＣＰＵ４２は、ＲＴＣ６０によって計時された時間に基づいて、現在時刻（日付）を計算したり、各種処理の実行タイミングを検知したりする。電源回路４６は、ゲーム装置１０が有する電源（電池；下ハウジングに収納される）からの電力を制御し、ゲーム装置１０の各部品に電力を供給する。
【００８４】
また、ゲーム装置１０は、マイク３２およびスピーカ３４を備えている。マイク３２およびスピーカ３４はそれぞれＩ／Ｆ回路４０に接続される。マイク３２は、ユーザの音声を検知して音声信号をＩ／Ｆ回路４０に出力する。スピーカ３４は、Ｉ／Ｆ回路４０からの音声信号に応じた音声を出力する。Ｉ／Ｆ回路４０はＣＰＵ４２に接続される。また、タッチパネル２８はＩ／Ｆ回路４０に接続される。Ｉ／Ｆ回路４０は、マイク３２およびスピーカ３４の制御を行う音声制御回路と、タッチパネルの制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。変換された音声データは、メインメモリ４８の音声エリア（図示せず）に書き込まれる。ゲーム装置１０を録音装置として利用する場合には、音声エリアに格納された音声データは、後にメモリ制御回路５０を介して保存用データメモリ５２に書き込まれる（必要に応じてさらに、メモリカードＩ／Ｆ４４を介してメモリカード３８に記録される）。また、音声エリアに格納された音声データ（マイク入力情報）は、各種のゲーム処理にも利用される。タッチパネル制御回路は、タッチパネル２８からの信号に基づいて所定の形式のタッチ位置データを生成してＣＰＵ４２に出力する。タッチ位置データは、タッチパネル２８の入力面のうちで入力が行われた位置の座標を示す。なお、タッチパネル制御回路は、タッチパネル２８からの信号の読み込み、および、タッチ位置データの生成を所定時間に１回の割合で行う。ＣＰＵ４２は、タッチ位置データを取得することにより、タッチパネル２８に対して入力が行われた位置を知ることができる。
【００８５】
操作部２４は、上記各ボタン２４ａ−２４ｉからなり、ＣＰＵ４２に接続される。操作部２４からＣＰＵ４２へは、各ボタン２４ａ−２４ｉに対する入力状況（押下されたか否か）を示す操作データが出力される。ＣＰＵ４２は、操作部２４から操作データを取得することによって、操作部２４に対する入力に従った処理を実行する。
【００８６】
各カメラ１６および１８はＣＰＵ４２に接続される。各カメラ１６および１８は、ＣＰＵ４２の指示に従って画像を撮像し、撮像した画像データをＣＰＵ４２に出力する。ＣＰＵ４２は、各カメラ１６および１８からの画像データをメインメモリ４８の画像エリア（図示せず）に書き込む。ゲーム装置１０を撮像装置として利用する場合には、画像エリアに格納された画像データは、後にメモリ制御回路５０を介して保存用データメモリ５２に書き込まれる（必要に応じてさらに、メモリカードＩ／Ｆ４４を介してメモリカード３８に記録される）。また、画像エリアに格納された画像データは、各種のゲーム処理にも利用される。
【００８７】
また、各ＬＣＤ１２および１４はＣＰＵ４２に接続される。各ＬＣＤ１２および１４はＣＰＵ４２の指示に従って画像を表示する。ゲーム装置１０でゲームをプレイする場合、ＬＣＤ１２および１４の一方または両方にゲーム画像が表示される。ゲーム装置１０を撮像装置として利用する場合には、ＣＰＵ４２は、各カメラ１６および１８のいずれかから取得した画像を上側ＬＣＤ１４に表示させ、所定の処理によって生成した操作画面を下側ＬＣＤ１２に表示させる。
【００８８】
以上のように構成されたゲーム装置１０で顔トレーニングを行うとき、図６（Ａ）−図６（Ｄ）のような画面が上側ＬＣＤ１４（以下“ＬＣＤ１４”）に表示される。なお、画面は、下側ＬＣＤ１２に表示されても、両方に跨って表示されてもよい。また、画面の構成は、簡略化された一例に過ぎず、様々に変更され得る。
【００８９】
最初、顔トレーニングの概要を図６（Ａ）−図６（Ｄ）により説明する。顔トレーニングを行うにあたって、ユーザは、ゲーム装置１０をネットワーク（図示せず）に接続し、所望のアプリケーションをサーバ（図示せず）からネットワーク経由でダウンロードする。
【００９０】
ここで、顔トレーニング用のアプリケーションは、“アプリＡ”，“アプリＢ”，“アプリＣ”，…のようにシリーズ化されており、たとえば、アプリＡはトレーニング０および１を含み、アプリＢはトレーニング０および２を含み、そしてアプリＣはトレーニング０および３を含む。トレーニング０，１，２および３は、たとえば顔の全体，一部，他の一部およびその他の一部をそれぞれ対象とするトレーニングである。
【００９１】
この実施例では、３つのアプリＡ−Ｃに対応するプログラムＰａ−Ｐｃおよびこれに付随する各種テーブルＣＴ，ＲＴおよびＭＴが、無線通信モジュール５６を経てＣＰＵ４２により受信され、保存用データメモリ５２に格納される（図７（Ａ）参照：詳細は後述）。
【００９２】
アプリＡ−Ｃは、ゲーム装置１０で過去に実行されたことがあり、したがって、保存用データメモリ５２には、それぞれに対応するセーブデータＤａ−Ｄｃがさらに記憶されている。ここで、セーブデータＤａ−Ｄｃは、アプリＡ−Ｃの実行により変化するアプリＡ−Ｃに関連するパラメータを示すデータともいえる。初めて実行されるアプリケーションについては、これに対応するセーブデータが、保存用データメモリ５２内に新たに生成される。すなわち、セーブデータはアプリ毎に保存されるが、どのアプリ用のセーブデータも、共通の構造を有する（図８参照：詳細は後述）。
【００９３】
セーブデータＤａは、アプリＡ用のセーブ項目だけでなく、アプリＢ，Ｃ用のセーブ項目や、アプリを特定しないセーブ項目のデータも含んでおり、セーブデータＤｂ，Ｄｃも同様である（図９参照：後述）。つまり、アプリＡ−Ｃに共通のセーブデータがあって、それをアプリＡ−Ｃ用として３通りに記憶したのが、セーブデータＤａ−Ｄｃである。したがって、セーブデータＤａ−Ｄｃは、本来同一内容でなければならないが、各アプリＡ−Ｃの実行状況によって差異が生じる。そこで、このような差異を解消するためのルーチンが、プログラムＰａ−Ｐｃに組み込まれている。
【００９４】
なお、プログラムＰａ−ＰｃおよびテーブルＣＴ，ＲＴおよびＭＴの一部または全部は、サーバからダウンロードされる代わりに、メモリカードＩ／Ｆを通じてメモリカード３８等から読み込まれても、予め保存用データメモリ５２等に格納されていてもよい。
【００９５】
ダウンロードが完了すると、ＣＰＵ４２は、図６（Ａ）のようなアプリ選択画面をＬＣＤ１４に表示する。このアプリ選択画面には、アプリＡ−Ｃにそれぞれ対応する３つのボタン“Ａ”，“Ｂ”および“Ｃ”と、そのいずれかを選択するようユーザに促すテキスト“アプリを選択してください”と、選択されたアプリの起動を指示するためのボタン“起動”と、選択されたアプリの紹介画面（図示せず）を表示させるための“紹介を見る”とが含まれる。
【００９６】
図６（Ａ）のアプリ選択画面でアプリＡが選択され、そして“起動”が指示されたとすると、ＣＰＵ４２は、図６（Ｂ）のようなトレーニング選択画面をＬＣＤ１４に表示する。トレーニング選択画面には、２種類のトレーニングにそれぞれ対応する２つのボタン“０”および“１”と、そのいずれかを選択するようユーザに促すテキスト“トレーニングを選択してください”とが含まれる。
【００９７】
図６（Ｂ）のトレーニング選択画面でトレーニング０が選択されたとすると、ＣＰＵ４２は、図６（Ｃ）のようなトレーニング画面をＬＣＤ１４に表示する。このトレーニング画面には、トレーニング“０”の内容を説明するテキスト“顔全体の表情筋を鍛えます”と、チェックボックスＣＢと、トレーニングを行ったらチックボックスＣＢに印を付けるようユーザに促すテキスト“トレーニングを終えたら印を付けてください“とが含まれる。なお、図示は省略するが、トレーニング画面には、お手本を示す画像や解説を示すテキストなどが適宜表示され、ユーザは、画面内のお手本や解説を参考に練習を行うことができる。
【００９８】
図６（Ｃ）のトレーニング画面でチェックボックスＣＢに印が付けられ、トレーニング結果の評価（表情測定）を行う指示が行われたとすると、ＣＰＵ４２は、図６（Ｄ）のような評価画面をＬＣＤ１４に表示する。この評価画面には、表情測定を行うことを知らせるテキスト“表情を測定します…”と、評価結果を示すテキスト“今日のスコアは８０点です”とが含まれる。ここで、評価結果つまりスコアは、ユーザが顔の筋肉をどれだけお手本に近い形で動かせるかを示す数値であり、所定のアルゴリズムに従って算出される。具体的には、ユーザの顔の画像を第１カメラ１６を通じて撮像し、この顔画像から各筋肉（瞼筋，頬筋など）の動きを解析し、解析結果をお手本（各筋肉の理想的な動きを示すデータであり、プログラムと一緒にダウンロードされる）と比較して、お手本との類似度をたとえば１００点満点でスコア化する。
【００９９】
上記のような顔トレーニングが実行されている期間中、セーブデータＤａ−ＤｃがＣＰＵ４２によって逐次更新される。実行されているのがアプリＡ−Ｃのどれであっても、セーブデータＤａ−Ｄｃの各々が更新される。具体的には、ＣＰＵ４２は、トレーニング開始に先立って、セーブデータＤａ−Ｄｃを項目毎に（図９参照）統合する。ここで、統合とは、セーブデータＤａ−Ｄｃそれぞれの先頭の項目におけるデータのうち１つのデータが採用されて、採用されたデータを先頭の項目におけるデータとし、この処理を最終の項目まで繰り返すことにより統合セーブデータＤｉｎｔを得ることをいう。そして、トレーニングが開始されると、いずれかの項目に該当する動作が行われる度に統合セーブデータＤｉｎｔを更新する一方、自動保存指示またはユーザによる保存指示に応じて、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ上書きする。この上書きは、ファイル単位（図８参照）で行われる。なお、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ上書きすることは、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ更新するといってもよいし、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ書き換えるといってもよい。以下、この一連の処理について、詳しく説明する。
【０１００】
図７（Ａ）を参照して、保存用データメモリ５２はプログラム領域７０およびデータ領域７２を含み、プログラム領域７０にはアプリＡ−Ｃに対応するプログラムＰａ−Ｐｃが、データ領域７２にはアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃが、それぞれ格納される。データ領域７２にはさらに、更新処理で利用される各種テーブル、具体的には項目テーブルＣＴ，統合ルールテーブルＲＴおよびファイル管理テーブルＭＴも格納される。図７（Ｂ）を参照して、メインメモリ４８はデータ領域７４を含み、データ領域７４には統合用のセーブデータＤｉｎｔが格納される。
【０１０１】
図８を参照して、アプリＡ−Ｃ用のセーブデータＤａ−Ｄｃおよび統合用のセーブデータＤｉｎｔの各々は、項目１−４１に対応する４１種類のセーブデータを含む。項目１−４１は、それぞれの内容によって１９個のグループに分類され、各グループに１つのファイルが割り当てられる。
【０１０２】
項目１−４１の内容は図９に示されており、たとえば、項目１−３は、アプリＡ−Ｃの紹介を見たかに関するもので、ファイル１が割り当てられる。項目４−７は、トレーニング０−３を１回でも行ったかに関するもので、ファイル２が割り当てられる。項目８−１０は、第１日にアプリＡ−Ｃでトレーニングをした印（チェックマーク：図６（Ｃ）参照）をつけたかに関するもので、ファイル３が割り当てられる。項目１１−１３は、第２日にアプリＡ−Ｃでトレーニングをした印をつけたかに関するもので、ファイル４が割り当てられる。項目１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１は、同じく第３−第７日に対応し、ファイル５−９が割り当てられる。項目３２−３８は、第１−第７日のスコアに関するもので、ファイル１０−１６が割り当てられる。項目３９は、写真管理情報に関するもので、ファイル１７が割り当てられる。項目４０は、“最後にトレーニングした日は今日か”に関するもので、ファイル１８が割り当てられる。そして、項目４１は、ウォーミングアップを最後にした日時に関するもので、ファイル１９が割り当てられる。
【０１０３】
また、このような１９個のファイルの一部ここではファイル１８および１９には、それぞれのファイルの更新日時を示すデータが付加される。残りのファイル１−１７には、更新日時データは付加されない（または００００年…のような無効なデータが付加される）。
【０１０４】
図９を参照して、項目テーブルＣＴは、各項目について、上記のような内容に加え、その項目の実体，その項目を参照するアプリ（参照アプリ），およびその項目を更新するアプリ（更新アプリ）が記述される。たとえば、項目１については、内容が“アプリＡの紹介を見たか”なので、実体はＹＥＳ／ＮＯを示すフラグである。そして、このフラグを参照するのはアプリＡ自身だけであり、“アプリＡの紹介を見た”場合にこのフラグを更新するのもアプリＡに限られる。項目２，３についても、実体はフラグであり、参照アプリおよび更新アプリはアプリＢ，Ｃ自身に限られる。これらのフラグは、アプリケーションの進行状況に関連するフラグであり、アプリケーションの進行に応じて所定の処理が行われた否かを判定するためのものである。
【０１０５】
項目４については、内容が“トレーニング０（顔全体）を１回でも行ったか”なので実体はフラグであり、このフラグは全アプリＡ−Ｃによって参照されかつ全アプリＡ−Ｃによって更新される。項目５については、内容が“トレーニング１（たとえば顔の一部）を１回でも行ったか”なので実体はフラグであり、参照アプリおよび更新アプリはアプリＡ自身に限られる。項目６，７についても、実体はフラグで、参照アプリおよび更新アプリはＢ，Ｃ自身に限られる。
【０１０６】
項目８については、内容が“第１日にアプリＡでトレーニングをしたか”なので、実体はフラグである。このフラグは全アプリＡ−Ｃによって参照されるが、“第１日にアプリＡでトレーニングをした”場合にこのフラグ更新するのはアプリＡ自身に限られる。項目９については、内容が“第１日にアプリＢでトレーニングをしたか”なので実体はフラグであり、参照アプリは全アプリＡ−Ｃであるが、更新アプリはアプリＢ自身に限られる。項目１０については、内容が“第１日にアプリＣでトレーニングをしたか”なので実体はフラグであり、参照アプリは全アプリＡ−Ｃであるが、更新アプリはアプリＣ自身に限られる。項目１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１も、項目８−１０や項目１１−１３の場合と同様である。
【０１０７】
項目３２については、内容が“第１日のスコア”なので、実体はスコアである。このスコアは、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。項目３３−３８についても同様である。
【０１０８】
項目３９については、内容が“写真管理情報”なので、実体は撮影日時や番号（タイトル），データ量などである。この写真管理情報は、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。項目４０については、内容が“最後にトレーニングした日は今日か”なので、実体はフラグである。このフラグは、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。そして、項目４１については、内容が“ウォーミングアップを最後にした日時”なので、実体は日時である。この日時は、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。
【０１０９】
なお、図９の項目テーブルＣＴにさらに、各項目に適用される統合ルール（次に説明するルールＲ１−Ｒ５のどれか）を予め記述しておいてもよい。
【０１１０】
図１０を参照して、統合ルールテーブルＲＴには、項目に割り当てられたファイルの属性および項目の実体に応じて５種類の統合ルールＲ１−Ｒ５が記述されている。具体的には、まず、ファイルの属性として“更新日時データを含む”および“更新日時データを含まない”の２種類が記述され、次に、“更新日時データを含む”に対応する項目の実体として“フラグ”および“フラグ以外”の２種類が、“更新日時データを含まない”に対応する項目の実体として“フラグ”，“スコア”および“写真管理情報”が、それぞれ記述されている。
【０１１１】
そして、ファイル属性が“更新日時データを含む”でありかつ実体が“フラグ”である項目の統合ルールＲ１として、“最新データを採用、但し最新データと同じ日付のデータがあればその同日データで立っているフラグは立てる”が記述されている。また、“更新日時データを含む”かつ“フラグ以外”である項目の統合ルールＲ２として“最新データを採用”が、“更新日時データを含まない”かつ“フラグ”である項目の統合ルールＲ３として“どれかでフラグが立っていればフラグを立てる”が、“更新日時データを含まない”かつ“スコア”である項目の統合ルールＲ４として“同じ日付の異なるスコアがあれば最もよいスコアを採用”が、そして“更新日時データを含まない”かつ“写真管理情報”である項目の統合ルールＲ５として“ＯＲつまり論理和による採用、但し同じ管理情報で異なる写真があればどれも採用しない（当該写真を読み込んで写真管理情報を再作成する）”が記述されている。
【０１１２】
セーブデータＤａ−Ｄｃは、このような統合ルールテーブルＲＴに基づいて項目毎に統合される。具体的には、図８−図１０を参照して、項目１−３は、割り当てられたファイル１がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目４−７は、割り当てられたファイル２がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目８−１０は、割り当てられたファイル３がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目１１−１３，１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１も、項目８−１０と同様に、ルールＲ３が適用される。
【０１１３】
項目３２は、割り照られたファイル１０がファイル更新日時データを含まず、かつ実体がスコアなので、ルールＲ４が適用される。項目３３−３８も、項目３２と同様に、ルールＲ４が適用される。項目３９は、割り当てられたファイル１７が更新日時データを含まず、かつ実体が写真管理情報なので、ルールＲ５が適用される。項目４０は、割り当てられたファイル１８がファイル更新日時データを含み、かつ実体がフラグなので、ルールＲ１が適用される。そして、項目４１は、割り当てられたファイル１９がファイル更新日時データを含み、かつ実体が日時つまりフラグ以外なので、ルールＲ２が適用される。
【０１１４】
項目毎の統合の一例を図１１に示す。まず、項目１に関し、セーブデータＤａではフラグが立っており（フラグ：ＯＮ）、セーブデータＤｂ，Ｄｃではいずれもフラグが立っていない（フラグ：ＯＦＦ）とすると、ルールＲ３の適用によって、統合セーブデータＤｉｎｔではフラグが立つ（フラグ：ＯＮ）。また、項目２に関し、セーブデータＤａ−Ｄｃのいずれでもフラグ：ＯＦＦとすると、ルールＲ３の適用によって、統合セーブデータＤｉｎｔではフラグ：ＯＦＦとなる。項目３−３１の各々も、同様に統合される。
【０１１５】
次に、項目３２に関し、セーブデータＤａ，Ｄｂ，Ｄｃでスコアがそれぞれ８０，７５，８５であるとすると、ルールＲ４の適用によって、統合セーブデータＤｉｎｔではスコアは８５となる。項目３３−３８の各々も、同様に統合される。
【０１１６】
次に、項目３９に関し、セーブデータＤａ，Ｄｂ，Ｄｃで写真管理情報（たとえば撮影番号）がそれぞれ＃１−＃１２，＃２−＃１３，＃１−＃１３であれば、ルールＲ５に従って、その論理和つまり撮影番号＃１−＃１３が採用される。ただし、同じ撮影情報で異なる写真があればどの撮影情報も採用しない、という但し書きによって、たとえば、撮影番号＃２で識別される３枚の写真のうち１枚が他と違っていたとすると、この撮影番号＃２は採用されない。この場合、撮影番号＃２に対応する３枚の写真を読み込んで確認し、撮影番号を付け直す作業が行われる。
【０１１７】
次に、項目４０に関し、セーブデータＤａではフラグ：ＯＦＦ（ファイル更新日時：２００９＿８＿１＿１５：００）、セーブデータＤｂではフラグ：ＯＮ（ファイル更新日時：２００９＿８＿１５＿１１：００）、そしてセーブデータＤｃではフラグ：ＯＦＦ（ファイル更新日時：２００９＿８＿２０＿１２：００）であるとすると、ルールＲ１の適用によって、統合セーブデータＤｉｎｔではフラグＯＦＦ（ファイル更新日時：２００９＿８＿２０＿１２：００）となる。なお、セーブデータＤｂのファイル更新日時が２００９＿８＿１５＿１１：００ではなく２００９＿８＿２０＿１１：００であったなら、これは最新データと同日であり、かつこの同日データでフラグはＯＮなので、統合セーブデータＤｉｎｔでは、この同日データのフラグ：ＯＮが採用されることとなる。
【０１１８】
次に、項目４１に関し、セーブデータＤａでは日時が２００９＿８＿１＿１６：００であり、セーブデータＤｂは存在せず、そしてセーブデータＤｃでは日時が２００９＿８＿２０＿１１：００）であるとすると、ルールＲ２の適用によって、統合セーブデータＤｉｎｔでは日時は２００９＿８＿２０＿１１：００となる。
【０１１９】
セーブデータＤａ−Ｄｃは、こうして得られた統合セーブデータＤｉｎｔで上書きされる。上書きは、いずれかの項目が更新される度に、ファイル単位で行われる。
【０１２０】
また、ゲーム装置１０では、以上のような統合処理に先行して、次のようなファイル制御処理が実行される。図１２（Ａ）を参照して、制御前（２００９年８月２０日１２：００現在）のファイル管理テーブルＭＴには、読み込まれた時点のセーブデータＤａ−Ｄｃの各々について、ファイル１−１９の状態および更新日時が記述されている。状態としては、そのファイルが正常である（オープンできる）ことを示す“正常”，そのファイルが破損している（オープンできない）ことを示す“破損”，およびそのファイルがない（無効である）ことを示す“無”の３種類がある。各ファイルの状態が３種類のどれであるかは、たとえばそのファイルの検索およびオープンを試みることによって、あるいは図示しないファイルシステムを参照して、判別される。
【０１２１】
また、更新日時は、更新日時データを含むファイルであれば、そのファイルから読み取られた値（たとえば２００９＿８＿１＿１５：００）が記述され、更新日時データを含まないファイルであれば、何も記述されない（または無効な値たとえば００００年０月０日０：００が記述される）。
【０１２２】
図１２（Ｂ）を参照して、制御後（２００９年８月２０日１２：００現在）のファイル管理テーブルＭＴは、上記のような制御前のファイル管理テーブルＭＴにおいて、状態および更新日時が２箇所ずつ変更されている。具体的には、まず状態に関し、セーブデータＤｂのファイル２の状態がファイル消去を行うことなく“破損”から“無”に変更され、セーブデータＤａのファイル３の状態がファイル消去を行った上で“破損”から“無”に変更されている。
【０１２３】
ここで、“破損”ファイルを削除するか否かは、これと同じ“正常”ファイルが別のセーブデータに存在しているか否かで決まる。セーブデータＤｂにおいて破損したファイル２は、これと同じ正常なファイル２がセーブデータＤａまたはＤｃに存在するため、消去されない。セーブデータＤｃにおいて破損したファイル３は、これと同じ正常なファイル３がセーブデータＤａおよびＤｂのいずれにも存在しないため、消去される。なお、ここで消去されなかった“無”ファイル２は、後段の統合処理および上書き処理を通じ、“正常”ファイル２で上書きされることになる。
【０１２４】
更新日時に関しては、現在日時に対して未来であるファイルが制御の対象となる。制御には、そのファイルに含まれるセーブデータは有効なままで、そのファイルの更新時刻を現在日時に変更するものと、そのファイルに含まれるセーブデータ全体を無効化するものとの２種類があり、どちらの制御を行うかは、更新日時が現在日時と同日であるか、翌日以降であるかによる。
【０１２５】
具体的には、セーブデータＤｃのファイル１８は、更新日時が“２００９＿８＿２０＿１３：００”であり、これは、現在日時“２００９＿８＿２０＿１２：０５”に対して未来かつ同日であるため、ファイル１８に含まれるセーブデータは有効なままで、現在日時に変更されている。一方、セーブデータＤｂのファイル１９は、更新日時が“２００９＿８＿２１＿１１：００”であり、これは、現在日時“２００９＿８＿２０＿１２：００”に対して未来かつ翌日以降であるため、ファイル１９に含まれるセーブデータ全体が無効化されている。
【０１２６】
このようなファイル制御処理を先行して行うことで、もし破損したファイルがあっても（ファイル内のデータに異常があっても）、これと同じ正常なファイルがあれば（別のファイル内に同じデータで正常なものがあれば）、後段の統合処理および上書き処理を通じて、破損ファイル（異常データ）を正常ファイル（正常データ）で修復することが可能となる。加えて、ゲーム装置１０では、ＲＴＣ６０の調整が可能なので、ＲＴＣ６０に基づく現在日時が過去に遡る方向に調整されると、ファイル更新日時が現在日時に対して未来となって統合処理に支障が出る可能性があるが、未来を示すファイル更新日時は、現在日時と同日であれば現在日時に変更されるので、統合処理に支障が出る可能性を低減することができる。
【０１２７】
次に、顔トレーニングを行う場合のＣＰＵ４２の動作を、図１３−図１８のフローチャートにより説明する。これらのフローチャートは、図７に示したアプリＡ用のプログラムＰａと対応している。なお、アプリＢ，Ｃ用のプログラムＰｂ，Ｐｃは、図１３−図１８と同様のフローチャートで記述されるので、図示および説明を省略する。
【０１２８】
現時点で、プログラム等のダウンロードは完了しており、保存用データメモリ５２のプログラム領域７０にはアプリＡ−Ｃ用のプログラムＰａ−Ｐｃが、データ領域７２には項目テーブルＣＴ，統合ルールテーブルＲＴおよびファイル管理テーブルＭＴが、それぞれ格納されている。また、アプリＡ−Ｃは、いずれも過去に実行されたことがあり、データ領域７２にはアプリＡ−Ｃ用のセーブデータも格納されている（図７（Ａ）参照）。
【０１２９】
まず、図１３および図１４を参照して、図６（Ａ）のようなアプリ選択画面を通じてアプリＡが選択されると、ＣＰＵ４２は、アプリＡ用のプログラムＰａを起動する。この起動処理が完了すると、ステップＳ３に進んで、アプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをメインメモリ４８の作業領域（図示せず）に読み込む。そして、セーブデータＤａ−Ｄｃに含まれる各ファイルをステップＳ５で制御した後、セーブデータＤａ−Ｄｃを項目毎に統合する。ステップＳ５のファイル制御処理およびステップＳ７の統合処理の詳細については、後述する。
【０１３０】
統合処理の結果つまり統合セーブデータＤｉｎｔは、メインメモリ４８のデータ領域７４に格納される。次のステップＳ９では、保存用データメモリ５２のデータ領域７２に格納されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃを、この統合セーブデータＤｉｎｔで上書きする。なお、ステップＳ９のセーブデータ上書き処理の詳細については、後述する。更新後、ステップＳ１１でアプリ処理が開始される。なお、アプリ処理は、たとえば図６（Ａ）−図６（Ｄ）により説明した顔トレーニングに対応する処理であり、図示しない別のフローに従って実行される。また、アプリ処理は、操作部２４を介した終了操作等に応じて、あるいは所定の終了条件が満たされたときに、終了される。
【０１３１】
次に、ステップＳ１３で、項目テーブルＣＴ（図９参照）に記述されたいずれかの項目に該当する動作（項目該当動作）がアプリ処理を通じて行われたか否かを判別し、ここでＹＥＳであればステップＳ１７−Ｓ１９を経てステップＳ２１に進む。ステップＳ１３でＮＯであれば、ステップＳ１５に移り、操作部２４やタッチパネル２８等により保存指示操作が行われたか否かを判別し、ここでＹＥＳであればステップＳ１９を経てステップＳ２１に進む。ステップＳ１５でＮＯであれば、直ちにステップＳ２１に進む。
【０１３２】
ステップＳ１７では、項目該当動作が行われたのに応じて、データ領域７４に格納されている統合セーブデータＤｉｎｔを更新する。続くステップＳ１９では、データ領域７２に格納されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをこの統合セーブデータＤｉｎｔに基づいて更新する。なお、ステップＳ１９のセーブデータ上書き処理は、ステップＳ９のそれと同様の処理であり、後述する。そしてステップＳ２１で、アプリ処理が終了されたか否かを判別し、ＮＯであればステップＳ１３に戻って同様の処理を繰り返す。ステップＳ２１でＹＥＳであれば、このフローは終了となる。
【０１３３】
上記ステップＳ５のファイル制御処理は、図１５のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ３１で、セーブデータＤａ−Ｄｃに含まれる各ファイル（図８参照）の状態を検出し、結果（正常／破損／無）をファイル管理テーブルＭＴに登録する。続くステップＳ３３では、さらに、各ファイルの更新日時を検出し、結果（ファイル更新日時）をファイル管理テーブルＭＴに登録する。なお、ファイルの状態や更新日時の具体的な検出方法については、前述したので省略する。この時点で、ファイル管理テーブルＭＴは、図１２（Ａ）のようになる。
【０１３４】
その後、ステップＳ３５に進んで、「破損」ファイルがあるか否かをファイル管理テーブルＭＴに基づいて判別し、ＮＯならステップＳ４３に進む。ステップＳ３５でＹＥＳであれば、ステップＳ３７に進んで、この「破損」ファイルに対応する「正常」ファイルがあるか否かをファイル管理テーブルＭＴに基づいてさらに判別する。そして、ステップＳ３７でＹＥＳであれば、ステップＳ３９でこの「破損」ファイルの状態を「無」に変更した後、ステップＳ４３に進む。一方、ステップＳ３７でＮＯであれば、ステップＳ４１で、この「破損」ファイルを削除すると共に、その状態を「無」に変更する。そして、ステップＳ４３に進む。
【０１３５】
ステップＳ４３では、「未来」ファイルがあるか否かをファイル管理テーブルＭＴに基づいて判別し、ＮＯならステップＳ４９に進む。ステップＳ４３でＹＥＳであれば、ステップＳ４５に進んで、この「未来」ファイルの更新日時が現在日時（これは、ゲーム装置１０のローカルな現在日時であって、ＣＲＴ６０に基づく）に対して翌日以降であるか否かをファイル管理テーブルＭＴに基づいてさらに判別する。そして、ステップＳ４５でＹＥＳであれば、ステップＳ４７でこの「未来」ファイルを無効化した後、メインルーチン（図１３−図１４参照）に復帰する。一方、ステップＳ４５でＮＯであれば、ステップＳ４９で、この「未来」ファイルの更新日時を現在日時に変更した後、メインルーチンに復帰する。この時点で、ファイル管理テーブルＭＴは、図１２（Ｂ）のようになる。
【０１３６】
こうして、セーブデータの統合に先立って、ファイル管理テーブルＭＴ上で、各ファイルの状態および更新日時が制御される。
【０１３７】
上記ステップＳ７のセーブデータ統合処理は、図１６−図１７のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ６１で、項目（ここでは図９に示す４１個の項目）を識別する変数ｉに初期値“１”をセットする。そして、ステップＳ６３で項目ｉを選択し、ステップＳ６５では、項目ｉが属するファイルＦｊ（ｊは１−１９のいずれか：図８参照）を特定して、このファイルＦｊが更新日時付きか否かを判別する。ここでＮＯであれば、ステップＳ７９に移る（ステップＳ７９およびこれに続くＳ８１−Ｓ８９については後述）。
【０１３８】
ステップＳ６５でＹＥＳであれば、ステップＳ６７に進んで、変数ｊで識別される３個のファイル、つまりアプリＡ−Ｃに対応するファイルＦｊａ−Ｆｊｃのうち、更新日時が最も新しいファイルを特定する。そして、項目ｉのセーブデータとして、この最新ファイルのセーブデータ（最新データ）を採用する（ルールＲ１またはＲ２：図１０参照）。さらにステップＳ７１で、項目ｉの実体がフラグか否かを判別し、ＮＯであればこの項目の処理を終えてステップＳ９５に進む。すなわち、実体がフラグ以外の場合、統合では、単に最新データが採用される（ルールＲ２：具体例は図１１の項目４１を参照）。
【０１３９】
一方、ステップＳ７３でＹＥＳであれば、最新ファイルと同じ日付のファイル（同日付ファイル）がファイルＦｊａ−Ｆｊｃの中にあるか否かをステップＳ７５でさらに判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ７３でＹＥＳであれば、同日付ファイルのセーブデータ（同日データ）でフラグが立っているか否かをさらに判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ７５でＹＥＳであれば、ステップＳ７７でフラグを立てた後、ステップＳ９５に進む。すなわち、実体がフラグの場合、統合では、最新データが採用されるが、同日データで立っているフラグは立てられる（ルールＲ１：具体例は図１１の項目４０を参照）。
【０１４０】
一方、ファイルＦｊが更新日時付でない場合（ステップＳ６５：ＮＯ）、ステップＳ７９で、項目ｉの実体は写真管理情報か否かを判別し、ここでＮＯであればステップＳ８１で項目ｉの実体はスコアか否かをさらに判別し、ここでもＮＯであれば項目ｉの実体はフラグとみなし、ステップＳ８３に移る。ステップＳ８３では、ファイルＦｊａ−Ｆｊｃのどれかのセーブデータでフラグが立っているか否かを判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ８３でＹＥＳであれば、ステップＳ８５でフラグを立てた後、ステップＳ９５に進む。すなわち、実体がフラグの場合、統合では、どれかでフラグがたっていればフラグを立てる（ルールＲ３：具体例は図１１の項目１，２を参照）。
【０１４１】
ステップＳ７９でＹＥＳあれば、ステップＳ８７に進んで、項目ｉのセーブデータＤａ−Ｄｃの中に含まれる写真管理情報を“ＯＲ”つまり論理和で採用する（ルールＲ５）。したがって、図１１の項目３９のように、セーブデータＤａに写真管理情報（撮影番号）＃１−＃１２が、セーブデータＤｂに撮影番号＃１−＃１３が、そしてセーブデータＤｃに撮影番号＃２−＃１３が含まれているとすると、撮影番号＃１−＃１３が採用される。ただし、撮影番号＃２で識別される３枚の写真のうち１枚が他と違っていたとすると、撮影番号＃２は採用されず（ルールＲ５の但し書き）、３枚の写真に撮影番号を付け直す処理が行われる。その後、ステップＳ９５に進む。
【０１４２】
ステップ８１でＹＥＳであれば、ステップＳ８９に進んで、項目ｉのセーブデータＤａ−Ｄｃの中に含まれるスコアのうち最もよいスコアを採用する（ルールＲ４：具体例は図１１の項目３２を参照）。その後、ステップＳ９５に進む。
【０１４３】
ステップＳ９５では、変数ｉをインクリメントする。そしてステップＳ９７で、変数ｉが最大値ｉｍａｘ（ここでは４１）を超えたか否かを判別し、ここでＮＯであれば、ステップＳ６３に戻って同様の処理を繰り返す。ステップＳ９７でＹＥＳであれば、メインルーチンに復帰する。
【０１４４】
なお、図１６−図１７のフローでは、各項目の統合に適用するルールは、統合ルールテーブルＲＴに基づいて（すなわちファイルの属性および項目の実体を判別して）決定されたが、項目テーブルＣＴ（図９参照）に各項目の統合ルールを予め記述しておく場合には、項目テーブルＣＴから読み取ればよい。
【０１４５】
上記ステップＳ９，Ｓ１９のセーブデータ上書き処理は、図１８のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ１０１で、ファイル（ここでは図８に示す１９個のファイル）を識別する変数ｊに初期値“１”をセットする。そして、ステップＳ１０３で、統合セーブデータＤｉｎｔのファイルＦｊｉｎｔをメインメモリ４８の作業領域（図示せず）に取り込む。そして、ファイルＦｊｉｎｔに属する項目の少なくとも１つに変化があったか否かをステップＳ１０５で判別し、ここでＮＯであればステップＳ１０９に進む。ステップＳ１０５でＹＥＳであれば、ステップＳ１０７でセーブデータＤａ−ＤｃのファイルＦｊａ−ＦｊｃをファイルＦｊｉｎｔにより上書きした後、ステップＳ１０９に進む。
【０１４６】
ステップＳ１０９では、変数ｊをインクリメントする。そしてステップＳ１１１で、変数ｊが最大値ｊｍａｘ（ここでは１９）を超えたか否かを判別し、ここでＮＯであれば、ステップＳ１０３に戻って同様の処理を繰り返す。ステップＳ１１１でＹＥＳであれば、メインルーチンに復帰する。
【０１４７】
このように、更新にあたって、各ファイル１−１９が変更のあった項目を含むか否かを判別して、判別結果がＹＥＳであるファイルだけを上書きするので、保存用データメモリ５２として特にＮＡＮＤ型フラッシュメモリを用いて、効率的な上書きが行える。
【０１４８】
以上から明らかなように、この実施例のゲーム装置１０では、アプリＡ−Ｃ（第１−第３アプリ）によって共用されるセーブデータが、保存用データメモリ５２（記憶手段）に、アプリＡ−Ｃに対応させてセーブデータＤａ−Ｄｃ（第１−第３セーブデータ）として記憶される。ＣＰＵ４２（コンピュータ）は、たとえばアプリＡが起動されると、保存用データメモリ５２に記憶されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをメインメモリ４８内で統合し（Ｓ７）、この統合データＤｉｎｔをアプリＡの実行に従って更新する（Ｓ１７）一方、自動保存指示やユーザによる保存指示に応じて、保存用データメモリ５２に記憶されているセーブデータＤａ−Ｄｃを更新された統合データＤｉｎｔで上書きする（Ｓ１９）。これにより、アプリＡ−Ｃ間で共用されるセーブデータを、煩雑な操作なしで最新状態に保つことができる。
【０１４９】
また、ＣＰＵ４２は、上記の統合処理（Ｓ７）をアプリ起動時に実行し、そしてアプリ処理が実行開始される前に、セーブデータＤａ−Ｄｃを統合データＤｉｎｔで上書きする（Ｓ９）。こうして、アプリ起動時に、セーブデータＤａ−Ｄｃを統合して、統合結果を速やかにセーブデータＤａ−Ｄｃに反映させることで、最新のセーブデータでアプリ処理を実行することができる。
【０１５０】
また、ＣＰＵ４２は、統合処理（Ｓ７）に先行して制御処理（Ｓ５）を実行することで、統合処理を通じてセーブデータの異常を修復する。これにより、たとえばセーブデータＤａに異常があっても、セーブデータＤｂまたはＤｃが正常であれば、その異常は、統合処理および更新処理を通じて修復することができる。
【０１５１】
なお、この実施例では、保存用データメモリ５２内にアプリＡ−Ｃ用のプログラムＰａ−ＰｃおよびセーブデータＤａ−Ｄｃが記憶されているが、プログラムＰａ−Ｐｃのいずれか１つまたは２つが現時点で記憶されていなくても、セーブデータＤａ−Ｄｃは記憶されていてよく、この場合、統合の効果を各セーブデータＤａ−Ｄｃに及ぼすことができる。たとえば、セーブデータＤａおよびＤｂの間で統合を行い、結果をセーブデータＤａ−Ｄｃに反映させる（セーブデータＤａおよびＤｂに基づく統合データＤｉｎｔでセーブデータＤａ−Ｄｃを上書きする）ことができる。
【０１５２】
また、この実施例では、項目をグループ分けして１グループに１ファイルを割り当てたが、グループ分けはせずに、１項目に１ファイルを割り当ててもよく、単一のファイルに全項目を含めることも可能である。ただし、グループ分けをする方が、効率的な上書きが行える。
【０１５３】
そして、この実施例では、上書きをファイル単位で行ったが、項目単位で上書きを行うような実施例も可能である。ただし、保存用データメモリとして、ＮＯＲ型フラッシュメモリのような、より細かな上書き制御が可能なメモリを用いる必要が生じる。
【０１５４】
また、この実施例では、保存用データメモリ５２に記憶されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃを統合し、統合して得られた統合データＤｉｎｔを用いてアプリＡ−Ｃのいずれかを実行して、アプリＡ−Ｃのいずれかの実行に応じて更新された統合データＤｉｎｔをセーブデータＤａ−Ｄｃに上書きするようにしているが、これに限られず、保存用データメモリ５２に記憶されている所定のデータを用いてアプリＡ−Ｃのいずれかを実行して、アプリＡ−Ｃのいずれかの実行に応じて更新された所定のデータをセーブデータＤａ−Ｄｃに上書きするようにしてもよい。この場合、上記所定のデータは、統合データＤｉｎｔと同じデータ構造を有する。
【０１５５】
以上では、ゲーム装置１０について説明したが、この発明は、アプリＡ，Ｂ，Ｃ…によってその少なくとも一部が共用されるデータ（セーブデータ，履歴データ，参照データ，学習データなど）をアプリＡ，Ｂ，Ｃ，…に対応させてデータＤａ，Ｄｂ，Ｄｃ，…として記憶する記憶手段（フラッシュメモリなどの保存用データメモリ，ハードディスク，書き換え可能な光ディスクなど）に接続されたコンピュータ（ＣＰＵ）を備える、情報処理装置（ＰＣ，ＰＤＡ，携帯電話端末など）に適用できる。
【符号の説明】
【０１５６】
１０ …ゲーム装置
４２ …ＣＰＵ
４８ …メインメモリ
５２ …保存用データメモリ
Ｐａ−Ｐｃ …アプリＡ−Ｃ用プログラム
Ｄａ−Ｄｃ …アプリＡ−Ｃ用セーブデータ
Ｄｉｎｔ …統合セーブデータ
Ｒ１−Ｒ５ …統合ルール
【技術分野】
【０００１】
この発明は、情報処理プログラムおよび情報処理装置に関し、特にたとえば、複数のアプリケーション（ソフトウェア）の間で、セーブデータなどの情報を共用する、情報処理プログラムおよび情報処理装置に関する。
【背景技術】
【０００２】
この種の背景技術としては、たとえば特許文献１に開示されたものが知られている。この背景技術では、シリーズ化されたソフトウェア間で、古いソフトウェアのセーブデータが新しいソフトウェアでも利用できたり、新しいソフトウェアのセーブデータが古いソフトウェアでも利用できたりする。具体的には、あるソフトウェアを起動したときに、他のソフトウェアのセーブデータが存在するか否かを判別して、セーブデータが存在する場合に、当該セーブデータに関する情報を表示して、使用するセーブデータをユーザに選択させるようになっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１８３０６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記の背景技術では、古いセーブデータであってもいつまでも残存する可能性があるため、ユーザが誤って古いセーブデータを選択することがあったり、セーブデータの選択時にセーブデータの生成日時や更新日時を確認する作業が必要になったりするという問題があった。
【０００５】
それゆえに、この発明の主たる目的は、新規な、情報処理プログラムおよび情報処理装置を提供することである。
【０００６】
この発明の他の目的は、複数アプリ間で共用されるセーブデータなどの情報を煩雑な操作なしで最新状態に保つことができる、情報処理プログラムおよび情報処理装置を提供することである。
【課題を解決するための手段】
【０００７】
この発明は、上記の課題を解決するために、以下の構成を採用した。
【０００８】
第１の発明は、記憶手段に接続されたコンピュータを、アプリケーション実行手段、更新手段、および第１上書き手段として機能させる、情報処理プログラムである。記憶手段には、第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータが、第１アプリケーションに対応させて第１データとして記憶されると共に、第２アプリケーションに対応させて第２データとしても記憶される。すなわち、データは、第１アプリ用の第１データおよび第２アプリ用の第２データとして２通りに記憶される。アプリケーション実行手段は、所定のデータで第１アプリケーションを実行する。更新手段は、アプリケーション実行手段による第１アプリケーションの実行にしたがって所定のデータを更新する。第１上書き手段は、記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする。
【０００９】
第１の発明によれば、第１のアプリケーションの実行にしたがって更新された所定のデータを、第１のアプリケーションに対応させた第１データと第２のアプリケーションに対応させた第２データに上書きするため、第１データおよび第２データを煩雑な操作なしで最新状態に保つことができる。
【００１０】
第２の発明は、第１の発明に従属する情報処理プログラムであって、コンピュータを、統合手段としてさらに機能させ、アプリケーション実行手段は、統合手段によって統合された統合データで第１アプリケーションを実行する。統合手段は、記憶手段に記憶されている第１データおよび第２データを統合する。第１アプリケーションは、こうして統合された統合データで実行される。
【００１１】
第２の発明によれば、以前の第１アプリケーションおよびは第２アプリケーションの実行により更新されている第１データおよび第２データを統合して第１アプリケーションの実行で更新し、更新したデータを第１データおよび第２データに上書きするため、第１データおよび第２データを以前のアプリケーションの実行結果が反映されたものにすることができる。さらに、上書きされた後の第１データおよび第２データの何れかが消失した場合や破損した場合であっても、最新状態に保たれている一方のデータを用いて各アプリケーションを実行できる。
【００１２】
第３の発明は、第１の発明に従属する情報処理プログラムであって、第１上書き手段は、所定の指示に応じて、記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする。
【００１３】
第３の発明によれば、適切なタイミングで第１データと第２データを最新状態に保つことができる。
【００１４】
なお、好ましくは、記憶手段は、不揮発性メモリたとえばフラッシュメモリなどの保存用データメモリを含み、統合および更新の各処理は、揮発性メモリたとえばコンピュータに接続されたメインメモリあるいはコンピュータの内蔵メモリ上で行われる。ただし、場合によっては、統合および更新の各処理も記憶手段内で行ってよい。
【００１５】
第４の発明は、第２の発明に従属する情報処理プログラムであって、コンピュータを、起動手段としてさらに機能させ、統合手段は、起動手段によって第１アプリケーションが起動されたときに統合を行う。起動手段は、第１アプリケーションを起動させ、統合手段は、起動手段が第１アプリケーションを起動させたときに第１データおよび第２データの統合を行う。
【００１６】
第４の発明によれば、第１アプリケーションの起動時に第１データおよび第２データを統合するため、最新のデータで第１アプリケーションの実行を開始させることができる。
【００１７】
第５の発明は、第４の発明に従属する情報処理プログラムであって、コンピュータを、第２上書き手段としてさらに機能させる。第２上書き手段は、記憶手段に記憶されている第１データおよび第２データを、第１アプリケーションが起動されたときに統合手段によって統合された統合データで、第１アプリケーションの実行が開始される前に上書きする。
【００１８】
第５の発明によれば、第１アプリケーションの起動時に、第１データおよび第２データを統合して、統合結果を速やかに第１データおよび第２データに反映させるので、第１アプリケーションの実行により更新された統合データが第１データおよび第２データに上書きされる前にコンピュータの電源オフ等によりアプリケーションが終了した場合であっても、第１データおよび第２データを統合後の新しいデータにすることができる。
【００１９】
第６の発明は、第５の発明に従属する情報処理プログラムであって、第１および／または第２上書き手段は、記憶手段に記憶されている第１データおよび／または第２データのうち、統合手段によって統合された統合データと異なる部分を上書きする。
【００２０】
第６の発明によれば、効率的な上書きが行える。
【００２１】
第７の発明は、第２ないし第６のいずれかの発明に従属する情報処理プログラムであって、データの共用部分は複数の項目に区分されており、統合手段は第１データおよび第２データを項目毎に統合する。
【００２２】
第７の発明によれば、項目によって異なる統合ルールを適用できるので、多様な統合が実現できる。
【００２３】
第８の発明は、第７の発明に従属する情報処理プログラムであって、複数の項目の各々は、それぞれに１つのファイルが割り当てられた複数のグループのいずれか１つに属しており、第１および／または第２上書き手段は、第１データおよび第２データをファイル単位で上書きする。
【００２４】
第８の発明によれば、項目をグループ分けしてファイルに収め、上書きをファイル単位で行うようにしたので、上書きの効率を向上させることと、記憶手段としてフラッシュメモリを用いることとが容易になる。
【００２５】
第９の発明は、第８の発明に従属する情報処理プログラムであって、第１および／または第２上書き手段は、複数のグループ毎にそこに含まれる全ての項目について変化があるか否かを判定し、判定結果が肯定である項目を少なくとも１つ含むグループに対応するファイルについて上書きを行う。
【００２６】
第９の発明によれば、効率よく上書きが行える。
【００２７】
第１０の発明は、第８または第９の発明に従属する情報処理プログラムであって、統合手段は、各ファイルの属性および／または各項目の実体に応じたルールに従って統合を行う。
【００２８】
第１０の発明によれば、多様な統合を効率よく行える。
【００２９】
第１１の発明は、第１０の発明に従属する情報処理プログラムであって、属性は、各ファイルが更新日時データを含むか否かに関し、ルールは、各ファイルが更新日時データを含んでいれば最新ファイルのデータを採用するという最新採用ルールを含む。
【００３０】
第１１の発明によれば、統合にあたって最新データを採用するので、第１データおよび第２データに古いデータが残らないようにすることができる。
【００３１】
第１２の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体がアプリケーションの進行状況に関連するフラグである場合にはどれかのデータでフラグが立っていればフラグを立てるというフラグルールを含む。
【００３２】
第１３の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体が値である場合には最も良い値を採用するという最良値ルールを含む。
【００３３】
第１４の発明は、第１０の発明に従属する情報処理プログラムであって、ルールは、項目の実体がデータの管理情報である場合には論理和により採用するという論理和ルールを含む。
【００３４】
第１４の発明によれば、管理情報を漏れなく採用できる。
【００３５】
第１５の発明は、第１４の発明に従属する情報処理プログラムであって、論理和ルールには、同じ管理情報の異なるデータがあればどれも採用しないという条件がつく。
【００３６】
第１５の発明では、同じ管理情報が割り当てられているのにデータ自体は異なっている（たとえば同じ写真管理情報が割り当てられているのに画像データは別物である）という場合、どの管理情報も採用されない。
【００３７】
第１５の発明によれば、間違っている可能性のある管理情報を排除できる。
【００３８】
第１６の発明は、第３の発明に従属する情報処理プログラムであって、所定の指示は自動保存指示を含む。
【００３９】
第１６の発明では、上書きは自動保存指示に応じて実行される。
【００４０】
第１６の発明によれば、ユーザは保存指示を行わなくてよいので、操作量が削減される。
【００４１】
なお、所定の指示は、ユーザによる保存指示を含んでもよい。この場合、上書きは、ユーザによる保存指示に応じて実行される。したがって、ユーザが指示するまでは上書きは行われないので、コンピュータや記憶手段への負荷を減らすことができる。
【００４２】
第１７の発明は、第１の発明に従属する情報処理プログラムであって、データは、第１アプリケーションおよび第２アプリケーションの各アプリケーションの実行により変化する当該各アプリケーションに関連するパラメータを示すデータである。
【００４３】
第１８の発明は、第２の発明に従属する情報処理プログラムであって、コンピュータを、制御手段としてさらに機能させる。制御手段は、記憶手段に記憶されている第１データに異常がある場合に、記憶手段に記憶されている第２データを利用して当該異常を修復するように統合手段を制御する。
【００４４】
第１８の発明によれば、統合を通じて異常を修復できる。
【００４５】
第１９の発明は、第１８の発明に従属する情報処理プログラムであって、制御手段は、第１データに対応する更新日時データが現在日時に対して未来かつ同日を示す場合には当該現在日時を示すように当該更新日時データを変更する一方、未来かつ翌日以降を示す場合には当該第１データを無効化する、日時制御手段を含む。
【００４６】
第１９の発明によれば、更新日時データの示す日時が未来であっても当日であれば、現在日時を示すように更新日時データを変更するに止め、翌日以降であれば、第１データ自体を無効化するので、当日のデータを生かして統合が行える。
【００４７】
第２０の発明は、第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段、所定のデータで第１アプリケーションを実行するアプリケーション実行手段、アプリケーション実行手段による第１アプリケーションの実行にしたがって所定のデータを更新する更新手段、および記憶手段に記憶されている第１データおよび第２データを更新手段によって更新された所定のデータで上書きする第１上書き手段を備える、情報処理装置である。
【００４８】
第２０の発明でも、第１の発明と同様に、第１データおよび第２データを煩雑な操作なしで最新状態に保つことができる。
【発明の効果】
【００４９】
この発明によれば、複数アプリ間で共用されるセーブデータなどの情報を煩雑な操作なしで最新状態に保つことができる、情報処理プログラムおよび情報処理装置が実現される。
【００５０】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【００５１】
【図１】この発明の一実施例であるゲーム装置の外観図であり、開状態における正面を示す。
【図２】ゲーム装置の外観図であり、開状態における側面を示す。
【図３】ゲーム装置の外観図であり、（Ａ）は閉状態における一方側面を、（Ｂ）は閉状態における上面を、（Ｃ）は閉状態における他方側面を、そして（Ｄ）は閉状態における下面をそれぞれ示す。
【図４】ゲーム装置がユーザによって把持された様子を示す図解図である。
【図５】ゲーム装置の電気的構成の一例を示すブロック図である。
【図６】顔トレーニングの流れを説明するための図解図であり、（Ａ）はアプリ選択画面を示し、（Ｂ）はトレーニング選択画面を示し、（Ｃ）はトレーニング画面を示し、（Ｄ）は表情測定画面を示す。
【図７】ゲーム装置のメモリマップ図であり、（Ａ）は保存用データメモリの一部を示し、（Ｂ）はメインメモリの一部を示す。
【図８】セーブデータの構成例を示す図解図である。
【図９】項目テーブルの構成例を示す図解図である。
【図１０】統合ルールテーブルの構成例を示す図解図である。
【図１１】統合ルールの項目への適用例を示す図解図である。
【図１２】ファイル管理テーブルの構成および制御の一例を示す図解図であり、（Ａ）が制御前に対応し、（Ｂ）が制御後に対応する。
【図１３】ＣＰＵ動作の一部を示すフロー図である。
【図１４】ＣＰＵ動作の他の一部を示すフロー図である。
【図１５】ＣＰＵ動作のその他の一部を示すフロー図である。
【図１６】ＣＰＵ動作のさらにその他の一部を示すフロー図である。
【図１７】ＣＰＵ動作の他の一部を示すフロー図である。
【図１８】ＣＰＵ動作のその他の一部を示すフロー図である。
【発明を実施するための形態】
【００５２】
図１−図３には、本発明の一実施例であるゲーム装置１０の外観が示される。ゲーム装置１０は折り畳み型のゲーム装置であり、図１および図２は、開いた状態（開状態）におけるゲーム装置１０を示し、図３は、閉じた状態（閉状態）におけるゲーム装置１０を示している。また、図１は、開状態におけるゲーム装置１０の正面図であり、図２は、開状態におけるゲーム装置の側面図である。ゲーム装置１０は、２つの表示装置（ＬＣＤ１２および１４）および２つのカメラ（カメラ１６および１８）を有し、カメラによって画像を撮像し、撮像した画像を画面に表示したり、撮像した画像のデータを保存したりすることができる。
【００５３】
ゲーム装置１０は、開いた状態において両手または片手で把持することができるような小型のサイズとされる。
【００５４】
ゲーム装置１０は、下側ハウジング２０および上側ハウジング２２という２つのハウジングを有する。下側ハウジング２０と上側ハウジング２２とは、開閉可能（折り畳み可能）に接続されている。この実施例では、各ハウジング２０および２２はともに横長の長方形の板状形状であり、互いの長辺部分で回転可能に接続されている。
【００５５】
上側ハウジング２２は、下側ハウジング２０の上側の一部で回動自在に支持されている。これによって、ゲーム装置１０は、閉状態（下側ハウジング２０と上側ハウジング２２とのなす角度が約０°の状態（図３参照））と、開状態（下側ハウジング２０と上側ハウジング２２とのなす角度が約１８０°の状態（図２参照））とをとることができる。ユーザは通常、開状態でゲーム装置１０を使用し、ゲーム装置１０を使用しない場合には閉状態としてゲーム装置１０を保管する。また、ゲーム装置１０は、上記閉状態および開状態のみでなく、下側ハウジング２０と上側ハウジング２２とのなす角度を、ヒンジに発生する摩擦力などによって閉状態と開状態との間の任意の角度に維持することができる。つまり、上側ハウジング２２を下側ハウジング２０に対して任意の角度で静止させることができる。
【００５６】
まず、下側ハウジング２０に設けられる構成について説明する。図１に示すように、ゲーム装置１０は、下側ＬＣＤ（液晶表示装置）１２を有する。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング２０の長辺方向に一致するように配置される。下側ＬＣＤ１２は下側ハウジング２０に収納される。下側ＬＣＤ１２は、下側ハウジング２０の内側面に設けられる。したがって、ゲーム装置１０を使用しない場合には閉状態としておくことによって、下側ＬＣＤ１２の画面が汚れたり傷ついたりすることを防止することができる。なお、この実施例では表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置など、他の任意の表示装置を利用してもよい。また、ゲーム装置１０は任意の解像度の表示装置を利用することができる。なお、ゲーム装置１０を撮像装置として利用する場合、下側ＬＣＤ１２は主に、カメラ１６または１８で撮像されている画像をリアルタイムに表示（スルー表示）するために用いられる。
【００５７】
下側ハウジング２０の内側面はほぼ平面状に形成される。当該内側面の中央には、下側ＬＣＤ１２を露出させるための開口部２０ｂが形成される。当該開口部２０ｂの左側（図示ｙ軸負側）には開口部２０ｃが形成され、当該開口部２０ｂの右側には開口部２０ｄが形成される。開口部２０ｂおよび２０ｃは、各キートップ（各ボタン２４ａ−２４ｅの上面）を露出させるためのものである。そして、下側ハウジング２０の内部に収納される下側ＬＣＤ１２の画面が開口部２０ｂから露出し、各キートップが開口部２０ｃおよび２０ｄから露出される。このように、下側ハウジング２０の内側面には、中央に設けられる下側ＬＣＤ１２用の開口部２０ｂの左右両側に非画面領域（図１に示す点線領域Ａ１およびＡ２。具体的には、各ボタン２４ａ−２４ｅを配置するための領域；ボタン配置領域）がそれぞれ設けられる。
【００５８】
下側ハウジング２０には、入力装置として、各ボタン２４ａ−２４ｉおよびタッチパネル２８が設けられる。図１に示されるように、各ボタン２４ａ−２４ｉのうち、方向入力ボタン２４ａ、ボタン２４ｂ、ボタン２４ｃ、ボタン２４ｄ、ボタン２４ｅ、および電源ボタン２４ｆは、下側ハウジング２０の内側面に設けられる。方向入力ボタン２４ａは例えば選択操作等に用いられ、各ボタン２４ｂ−２４ｅは例えば決定操作やキャンセル操作等に用いられる。電源ボタン２４ｆは、ゲーム装置１０の電源をオン／オフするために用いられる。ここでは、方向入力ボタン２４ａおよび電源ボタン２４ｆは、下側ハウジング２０の中央付近に設けられる下側ＬＣＤ１２に対して一方の側の（図１では左側）に設けられ、ボタン２４ｂ−２４ｅは下側ＬＣＤ１２に対して他方の側（図１では右側）に設けられる。方向入力ボタン２４ａおよびボタン２４ｂ−２４ｅは、ゲーム装置１０に対する各種操作を行うために用いられる。
【００５９】
図３（Ａ）は閉状態におけるゲーム装置１０の左側面図であり、図３（Ｂ）は当該ゲーム装置１０の正面図であり、図３（Ｃ）は当該ゲーム装置１０の右側面図であり、そして図３（Ｄ）は当該ゲーム装置１０の背面図である。図３（Ｃ）に示されるように、また、図３（Ａ）に示されるように、音量ボタン２４ｉは、下側ハウジング２０の左側面に設けられる。音量ボタン２４ｉは、ゲーム装置１０が備えるスピーカ３４の音量を調整するために用いられる。また、図３（Ｄ）に示されるように、ボタン２４ｈは、下側ハウジング２０の上面の右端部に設けられる。ボタン２４ｇは、下側ハウジング２０の上面の左端部に設けられる。各ボタン２４ｇおよび２４ｈは、ゲーム装置１０に対して例えば撮影指示操作（シャッタ操作）を行うために用いられる。各ボタン２４ｇおよび２４ｈの両方をシャッターボタンとして機能させてもよく、この場合、右利きのユーザはボタン２４ｈを使用し、左利きのユーザはボタン２４ｇを使用することができ、いずれのユーザにも使い勝手が良い。なお、ゲーム装置１０は、各ボタン２４ｇおよび２４ｈを常にシャッターボタンとして有効としておいてもよいし、右利きか左利きかの設定をして（メニュープログラムなどによりユーザに設定入力をさせ、設定されたデータを記憶しておく）、右利き設定のときにはボタン２４ｈのみ有効とし、左利き設定のときにはボタン２４ｇのみ有効とするようにしてもよい。
【００６０】
図１に示されるように、ゲーム装置１０は、各操作ボタン２４ａ−２４ｉとは別の入力装として、タッチパネル２８をさらに備えている。タッチパネル２８は、下側ＬＣＤ１２の画面上に装着されている。なお、この実施例では、タッチパネル２８は抵抗膜方式のタッチパネルである。ただし、タッチパネルは抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。この実施例では、タッチパネル２８として、下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル２８の解像度と下側ＬＣＤ１２の解像度が一致している必要はない。また、下側ハウジング２０の右側面には挿入口３０（図１および図３（Ｄ）に示す点線）が設けられている。挿入口３０は、タッチパネル２８に対する操作を行うために用いられるタッチペン３６を収納することができる。なお、タッチパネル２８に対する入力は通常タッチペン３６を用いて行われるが、タッチペン３６に限らずユーザの指でタッチパネル２８を操作することも可能である。
【００６１】
図３（Ａ）に示されるように、下側ハウジング２０の右側面には開閉可能なカバー部１１Ｂが設けられる。このカバー部１１Ｂの内側には、ゲーム装置１０とメモリカード３８とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード３８は、コネクタに着脱自在に装着される。メモリカード３８は、例えば、ゲーム装置１０によって撮像された画像のデータを記憶（保存）するために用いられる。
【００６２】
図１に示されるように、下側ハウジング２０の軸部２０ａの左側部分には、３つのＬＥＤ２６ａ−２６ｃが取り付けられる。ここで、ゲーム装置１０は他の機器との間で無線通信を行うことが可能であり、第１ＬＥＤ２６ａは、無線通信が確立している場合に点灯する。第２ＬＥＤ２６ｂは、ゲーム装置１０の充電中に点灯する。第３ＬＥＤ２６ｃは、ゲーム装置１０の電源がオンである場合に点灯する。したがって、３つのＬＥＤ２６ａ−２６ｃによって、ゲーム装置１０の通信確立状況、充電状況、および、電源のオン／オフ状況をユーザに通知することができる。
【００６３】
以上に説明したように、下側ハウジング２０には、ゲーム装置１０に対する操作入力を行うための入力装置（タッチパネル２８および各ボタン２４ａ−２４ｉ）が設けられる。したがって、ユーザは、ゲーム装置１０を使用する際には下側ハウジング２０を把持してゲーム装置１０に対する操作を行うことができる。図４は、ユーザがゲーム装置１０を両手で把持した様子を示す図である。図４に示すように、ユーザは、各ＬＣＤ１２および１４がユーザの方向を向く状態で、両手の掌と中指、薬指および小指とで下側ハウジング２０の側面および外側面（内側面の反対側の面）を把持する。このように把持することで、ユーザは、下側ハウジング２０を把持したまま、各ボタン２４ａ−２４ｅに対する操作を親指で行い、ボタン２４ｇおよび２４ｈに対する操作を人差し指で行うことができる。
【００６４】
一方、上側ハウジング２２には、画像を撮像するための構成（カメラ）、および、撮像した画像を表示するための構成（表示装置）が設けられる。以下、上側ハウジング２２に設けられる構成について説明する。
【００６５】
図１に示すように、ゲーム装置１０は、上側ＬＣＤ１４を有する。上側ＬＣＤ１４は上側ハウジング２２に収納される。上側ＬＣＤ１４は横長形状であり、長辺方向が上側ハウジング２２の長辺方向に一致するように配置される。上側ＬＣＤ１４は、上側ハウジング２２の内側面（ゲーム装置１０が閉状態となった場合に内側となる面）に設けられる。したがって、ゲーム装置１０を使用しない場合には閉状態としておくことによって、上側ＬＣＤ１４の画面が汚れたり傷ついたりすることを防止することができる。なお、下側ＬＣＤ１２と同様、上側ＬＣＤ１４に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、他の実施形態においては、上側ＬＣＤ１４上にもタッチパネルを設けてもよい。
【００６６】
また、ゲーム装置１０は、２つのカメラ１６および１８を有する。各カメラ１６および１８はともに上側ハウジング２２に収納される。図１に示されるように、内側カメラ１６は、上側ハウジング２２の内側面に取り付けられる。一方、図３（Ｂ）に示されるように、外側カメラ１８は、内側カメラ１６が取り付けられる面の反対側の面、すなわち、上側ハウジング２２の外側面（ゲーム装置１０が閉状態となった場合に外側となる面）に取り付けられる。これによって、内側カメラ１６は、上側ハウジング２２の内側面が向く方向を撮像することが可能であり、外側カメラ１８は、内側カメラ１６の撮像方向の逆方向、すなわち、上側ハウジング２２の外側面が向く方向を撮像することが可能である。以上のように、この実施例では、２つのカメラ１６および１８が撮像方向が互いに逆方向となるように設けられる。したがって、ユーザはゲーム装置１０を持ち替えることなく、異なる２方向を撮像することができる。例えば、ユーザは、ゲーム装置１０からユーザの方を見た景色を内側カメラ１６で撮影することができるとともに、ゲーム装置１０からユーザの反対側の方向を見た景色を外側カメラ１８で撮影することができる。
【００６７】
また、内側カメラ１６は、上側ハウジング２２の下側の中央部に形成される軸部２２ａの中央に取り付けられる。つまり、内側カメラ１６は、２つのハウジング２０および２２が接続される部分の中央に取り付けられる。したがって、ゲーム装置１０を開状態にした場合、内側カメラ１６は、２つのＬＣＤ１２および１４の間に配置されることになる（図１参照）。換言すれば、内側カメラ１６は、ゲーム装置１０の中心付近に配置されることになる。なお、「ゲーム装置１０の中心」とは、ゲーム装置１０の操作面（開状態における各ハウジング２０および２２の内側面からなる面）の中心という意味である。なお、内側カメラ１６は、ＬＣＤ１２および１４の横方向の中心付近に配置されているということもできる。
【００６８】
この実施例では、ゲーム装置１０を開状態にした場合に内側カメラ１６はゲーム装置１０の中心付近に配置されるので、ユーザは、内側カメラ１６によってユーザ自身を撮影する場合、ユーザがゲーム装置１０に正対する位置でゲーム装置１０を把持すればよい。つまり、通常の把持位置でゲーム装置を把持すれば、ユーザは撮像範囲の中心付近に位置することになり、ユーザ自身を撮像範囲内に収めることが容易になる。
【００６９】
また、図３（Ｂ）に示されるように、外側カメラ１８は、ゲーム装置１０を開状態とした場合において上側ハウジング２２の上部（下側ハウジング２０から遠い側の部分）に配置される。なお、外側カメラ１８は、ゲーム装置１０を把持するユーザを撮影するものではないので、ゲーム装置１０の中心に設ける必要性は高くない。
【００７０】
また、図１または図３（Ｂ）に示されるように、マイク３２は、上側ハウジング２２に収納されている。具体的には、マイク３２は、上側ハウジング２２の軸部２２ａに取り付けられる。この実施例では、マイク３２は、内側カメラ１６の周囲（図ではｙ軸の側方）に取り付けられ、より具体的には、内側カメラ１６からｙ軸正方向側の側方に取り付けられる。また、軸部２２ａにおいては、マイク３２がゲーム装置１０外部の音を検知することができるように、マイク３２に対応する位置（内側カメラ１６の側方）にマイクロフォン用孔２２ｃが設けられる。
【００７１】
なお、マイク３２は下側ハウジング２０に収納されてもよい。たとえば、マイクロフォン用孔２２ｃを下側ハウジング２０の内側面、具体的には下側ハウジング２０の内側面の左下部分（ボタン配置領域Ａ１）に設け、マイク３２を、下側ハウジング２０内における、マイクロフォン用孔２２ｃの近傍に配置することができる。また、マイク３２は、その集音方向（感度が最大となる方向）が内側カメラ１６の撮像方向（光軸）と略並行（言い換えれば集音方向および撮像方向がそれぞれｙ軸と略並行）となる向きに取り付けられる。これによって、内側カメラ１６の撮像範囲内で発せられた音声は、マイク３２によって好適に捉えられる。すなわち、マイク３２入力の検出とユーザの検出とを同時行うことができるとともに、検出の精度を向上させることができる。
【００７２】
図３（Ｂ）に示されるように、上側ハウジング２２の外側面には、第４ＬＥＤ２６ｄが取り付けられる。第４ＬＥＤ２６ｄは、外側カメラ１８の周囲（この実施例では、外側カメラ１８の右側）に取り付けられる。第４ＬＥＤ２６ｄは、内側カメラ１６または外側カメラ１８によって撮影が行われた（シャッターボタンが押下された）時点で点灯する。また、内側カメラ１６または外側カメラ１８によって動画が撮影される間点灯する。第４ＬＥＤ２６ｄによって、ゲーム装置１０による撮影が行われた（行われている）ことを撮影対象者に通知することができる。
【００７３】
また、上側ハウジング２２の内側面はほぼ平面状に形成される。図１に示すように、当該内側面の中央には、上側ＬＣＤ１４を露出させるための開口部２１Ｂが形成される。上側ハウジング２２の内部に収納される上側ＬＣＤ１４の画面は、開口部２１Ｂから露出する。また、上記開口部２１Ｂの左右両側には音抜き孔２２ｄがそれぞれ１つずつ形成される。音抜き孔２２ｄの奥の上側ハウジング２２内にはスピーカ３４が収納されている。音抜き孔２２ｄは、スピーカ３４からの音を外部に放出するための孔である。
【００７４】
このように、上側ハウジング２２の内側面には、中央に設けられる上側ＬＣＤ１４用の開口部２１Ｂの左右両側に非画面領域（図１に示す点線領域Ｂ１およびＢ２。具体的には、スピーカ３４を配置するための領域；スピーカ配置領域）がそれぞれ設けられる。２つの音抜き孔２２ｄは、左右方向については、各スピーカ配置領域の左右方向における中央部付近に配置され、上下方向については、各スピーカ配置領域の下部領域（下側ハウジング２０に近い側の領域）に配置される。
【００７５】
なお、上記のように、下側ハウジング２０および上側ハウジング２２に左右方向に関して同じ位置に非画面領域をそれぞれ設けたことで、ゲーム装置１０は、図４に示すような横持ちで把持される場合だけでなく、縦持ち（図４に示す状態からゲーム装置１０を左または右回りに９０°回転させた状態）で把持される場合にも持ちやすい構成となっている。
【００７６】
以上に説明したように、上側ハウジング２２には、画像を撮像するための構成であるカメラ１６および１８、および、撮像された画像を表示するための表示手段である上側ＬＣＤ１４が設けられる。一方、下側ハウジング２０には、ゲーム装置１０に対する操作入力を行うための入力装置（タッチパネル２８および各ボタン２４ａ−２４ｉ）が設けられる。したがって、ゲーム装置１０を撮像装置として使用する際には、ユーザは、上側ＬＣＤ１４に表示される撮像画像（カメラによって撮像された画像）を見ながら、下側ハウジング２０を把持して入力装置に対する入力を行うことができる。
【００７７】
また、上側ハウジング２２のカメラ１６近傍には、音声を入力するための構成であるマイク３２が設けられており、したがってゲーム装置１０は、録音装置としても使用可能である。さらに、ユーザがマイク３２を通して音声入力を行い、ゲーム装置１０はこのマイク入力情報に基づいてゲーム処理やゲーム以外のアプリケーション処理を実行することもできる。
【００７８】
図５は、ゲーム装置１０の内部構成（電気的構成）を示すブロック図である。図５に示すように、ゲーム装置１０は、ＣＰＵ４２、メインメモリ４８、メモリ制御回路５０、保存用データメモリ５２、プリセットデータ用メモリ５４、メモリカードインターフェース（メモリカードＩ／Ｆ）４４、無線通信モジュール５６、ローカル通信モジュール５８、リアルタイムクロック（ＲＴＣ）３９、電源回路４６、およびインターフェース回路（Ｉ／Ｆ回路）４０等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング２０（または上側ハウジング２２でもよい）内に収納される。
【００７９】
ＣＰＵ４２は、各種のプログラムを実行するための情報処理手段である。ゲーム装置１０を撮像装置として利用する場合には、そのためのプログラムがゲーム装置１０内のメモリ（例えば保存用データメモリ５２）に記憶される。ＣＰＵ４２が当該プログラムを実行することで、ゲーム装置１０は撮影装置として機能する。なお、ＣＰＵ４２によって実行されるプログラムは、ゲーム装置１０内のメモリに予め記憶されていてもよいし、メモリカード３８から取得されてもよいし、他の機器との通信によって他の機器から取得されても、あるいはインターネットを通じてサーバからダウンロードされてもよい。
【００８０】
ＣＰＵ４２には、メインメモリ４８、メモリ制御回路５０、およびプリセットデータ用メモリ５４が接続される。また、メモリ制御回路５０には保存用データメモリ５２が接続される。メインメモリ４８は、ＣＰＵ４２のワーク領域やバッファ領域として用いられる記憶手段である。すなわち、メインメモリ４８は、ゲーム処理に用いられる各種データを記憶したり、外部（メモリカード３８や他の機器等）から取得されるプログラムを記憶したりする。この実施例では、メインメモリ４８として例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。保存用データメモリ５２は、ＣＰＵ４２によって実行されるプログラムや各カメラ１６および１８によって撮像された画像のデータ、ゲームやアプリケーションのセーブデータ等を記憶するための記憶手段である。保存用データメモリ５２は、例えばＮＡＮＤ型フラッシュメモリで構成される（ＮＯＲ型フラッシュメモリや他の不揮発性メモリを用いてもよい）。メモリ制御回路５０は、ＣＰＵ４２の指示に従って、保存用データメモリ５２に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ５４は、ゲーム装置１０において予め設定される各種パラメータ等のデータ（プリセットデータ）を記憶するための記憶手段である。プリセットデータ用メモリ５４としては、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）バスによってＣＰＵ４２と接続されるフラッシュメモリを用いることができる。
【００８１】
メモリカードＩ／Ｆ４４はＣＰＵ４２に接続される。メモリカードＩ／Ｆ４４は、コネクタに装着されたメモリカード３８に対するデータの読み出しおよび書き込みをＣＰＵ４２の指示に従って行う。この実施例では、各カメラ１６および１８によって撮像された画像データがメモリカード３８に書き込まれたり、メモリカード３８に記憶された画像データがメモリカード３８から読み出されて保存用データメモリ５２に記憶されたりする。
【００８２】
無線通信モジュール５６は、例えばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール５８は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール５６およびローカル通信モジュール５８はＣＰＵ４２に接続される。ＣＰＵ４２は、無線通信モジュール５６を用いてインターネットを介して他の機器との間でデータを送受信したりサーバ（図示せず）からプログラムをダウンロードしたり、ローカル通信モジュール５８を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
【００８３】
また、ＣＰＵ４２には、ＲＴＣ６０および電源回路４６が接続される。ＲＴＣ６０は、時間をカウントしてＣＰＵ４２に出力する。ＣＰＵ４２は、ＲＴＣ６０によって計時された時間に基づいて、現在時刻（日付）を計算したり、各種処理の実行タイミングを検知したりする。電源回路４６は、ゲーム装置１０が有する電源（電池；下ハウジングに収納される）からの電力を制御し、ゲーム装置１０の各部品に電力を供給する。
【００８４】
また、ゲーム装置１０は、マイク３２およびスピーカ３４を備えている。マイク３２およびスピーカ３４はそれぞれＩ／Ｆ回路４０に接続される。マイク３２は、ユーザの音声を検知して音声信号をＩ／Ｆ回路４０に出力する。スピーカ３４は、Ｉ／Ｆ回路４０からの音声信号に応じた音声を出力する。Ｉ／Ｆ回路４０はＣＰＵ４２に接続される。また、タッチパネル２８はＩ／Ｆ回路４０に接続される。Ｉ／Ｆ回路４０は、マイク３２およびスピーカ３４の制御を行う音声制御回路と、タッチパネルの制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。変換された音声データは、メインメモリ４８の音声エリア（図示せず）に書き込まれる。ゲーム装置１０を録音装置として利用する場合には、音声エリアに格納された音声データは、後にメモリ制御回路５０を介して保存用データメモリ５２に書き込まれる（必要に応じてさらに、メモリカードＩ／Ｆ４４を介してメモリカード３８に記録される）。また、音声エリアに格納された音声データ（マイク入力情報）は、各種のゲーム処理にも利用される。タッチパネル制御回路は、タッチパネル２８からの信号に基づいて所定の形式のタッチ位置データを生成してＣＰＵ４２に出力する。タッチ位置データは、タッチパネル２８の入力面のうちで入力が行われた位置の座標を示す。なお、タッチパネル制御回路は、タッチパネル２８からの信号の読み込み、および、タッチ位置データの生成を所定時間に１回の割合で行う。ＣＰＵ４２は、タッチ位置データを取得することにより、タッチパネル２８に対して入力が行われた位置を知ることができる。
【００８５】
操作部２４は、上記各ボタン２４ａ−２４ｉからなり、ＣＰＵ４２に接続される。操作部２４からＣＰＵ４２へは、各ボタン２４ａ−２４ｉに対する入力状況（押下されたか否か）を示す操作データが出力される。ＣＰＵ４２は、操作部２４から操作データを取得することによって、操作部２４に対する入力に従った処理を実行する。
【００８６】
各カメラ１６および１８はＣＰＵ４２に接続される。各カメラ１６および１８は、ＣＰＵ４２の指示に従って画像を撮像し、撮像した画像データをＣＰＵ４２に出力する。ＣＰＵ４２は、各カメラ１６および１８からの画像データをメインメモリ４８の画像エリア（図示せず）に書き込む。ゲーム装置１０を撮像装置として利用する場合には、画像エリアに格納された画像データは、後にメモリ制御回路５０を介して保存用データメモリ５２に書き込まれる（必要に応じてさらに、メモリカードＩ／Ｆ４４を介してメモリカード３８に記録される）。また、画像エリアに格納された画像データは、各種のゲーム処理にも利用される。
【００８７】
また、各ＬＣＤ１２および１４はＣＰＵ４２に接続される。各ＬＣＤ１２および１４はＣＰＵ４２の指示に従って画像を表示する。ゲーム装置１０でゲームをプレイする場合、ＬＣＤ１２および１４の一方または両方にゲーム画像が表示される。ゲーム装置１０を撮像装置として利用する場合には、ＣＰＵ４２は、各カメラ１６および１８のいずれかから取得した画像を上側ＬＣＤ１４に表示させ、所定の処理によって生成した操作画面を下側ＬＣＤ１２に表示させる。
【００８８】
以上のように構成されたゲーム装置１０で顔トレーニングを行うとき、図６（Ａ）−図６（Ｄ）のような画面が上側ＬＣＤ１４（以下“ＬＣＤ１４”）に表示される。なお、画面は、下側ＬＣＤ１２に表示されても、両方に跨って表示されてもよい。また、画面の構成は、簡略化された一例に過ぎず、様々に変更され得る。
【００８９】
最初、顔トレーニングの概要を図６（Ａ）−図６（Ｄ）により説明する。顔トレーニングを行うにあたって、ユーザは、ゲーム装置１０をネットワーク（図示せず）に接続し、所望のアプリケーションをサーバ（図示せず）からネットワーク経由でダウンロードする。
【００９０】
ここで、顔トレーニング用のアプリケーションは、“アプリＡ”，“アプリＢ”，“アプリＣ”，…のようにシリーズ化されており、たとえば、アプリＡはトレーニング０および１を含み、アプリＢはトレーニング０および２を含み、そしてアプリＣはトレーニング０および３を含む。トレーニング０，１，２および３は、たとえば顔の全体，一部，他の一部およびその他の一部をそれぞれ対象とするトレーニングである。
【００９１】
この実施例では、３つのアプリＡ−Ｃに対応するプログラムＰａ−Ｐｃおよびこれに付随する各種テーブルＣＴ，ＲＴおよびＭＴが、無線通信モジュール５６を経てＣＰＵ４２により受信され、保存用データメモリ５２に格納される（図７（Ａ）参照：詳細は後述）。
【００９２】
アプリＡ−Ｃは、ゲーム装置１０で過去に実行されたことがあり、したがって、保存用データメモリ５２には、それぞれに対応するセーブデータＤａ−Ｄｃがさらに記憶されている。ここで、セーブデータＤａ−Ｄｃは、アプリＡ−Ｃの実行により変化するアプリＡ−Ｃに関連するパラメータを示すデータともいえる。初めて実行されるアプリケーションについては、これに対応するセーブデータが、保存用データメモリ５２内に新たに生成される。すなわち、セーブデータはアプリ毎に保存されるが、どのアプリ用のセーブデータも、共通の構造を有する（図８参照：詳細は後述）。
【００９３】
セーブデータＤａは、アプリＡ用のセーブ項目だけでなく、アプリＢ，Ｃ用のセーブ項目や、アプリを特定しないセーブ項目のデータも含んでおり、セーブデータＤｂ，Ｄｃも同様である（図９参照：後述）。つまり、アプリＡ−Ｃに共通のセーブデータがあって、それをアプリＡ−Ｃ用として３通りに記憶したのが、セーブデータＤａ−Ｄｃである。したがって、セーブデータＤａ−Ｄｃは、本来同一内容でなければならないが、各アプリＡ−Ｃの実行状況によって差異が生じる。そこで、このような差異を解消するためのルーチンが、プログラムＰａ−Ｐｃに組み込まれている。
【００９４】
なお、プログラムＰａ−ＰｃおよびテーブルＣＴ，ＲＴおよびＭＴの一部または全部は、サーバからダウンロードされる代わりに、メモリカードＩ／Ｆを通じてメモリカード３８等から読み込まれても、予め保存用データメモリ５２等に格納されていてもよい。
【００９５】
ダウンロードが完了すると、ＣＰＵ４２は、図６（Ａ）のようなアプリ選択画面をＬＣＤ１４に表示する。このアプリ選択画面には、アプリＡ−Ｃにそれぞれ対応する３つのボタン“Ａ”，“Ｂ”および“Ｃ”と、そのいずれかを選択するようユーザに促すテキスト“アプリを選択してください”と、選択されたアプリの起動を指示するためのボタン“起動”と、選択されたアプリの紹介画面（図示せず）を表示させるための“紹介を見る”とが含まれる。
【００９６】
図６（Ａ）のアプリ選択画面でアプリＡが選択され、そして“起動”が指示されたとすると、ＣＰＵ４２は、図６（Ｂ）のようなトレーニング選択画面をＬＣＤ１４に表示する。トレーニング選択画面には、２種類のトレーニングにそれぞれ対応する２つのボタン“０”および“１”と、そのいずれかを選択するようユーザに促すテキスト“トレーニングを選択してください”とが含まれる。
【００９７】
図６（Ｂ）のトレーニング選択画面でトレーニング０が選択されたとすると、ＣＰＵ４２は、図６（Ｃ）のようなトレーニング画面をＬＣＤ１４に表示する。このトレーニング画面には、トレーニング“０”の内容を説明するテキスト“顔全体の表情筋を鍛えます”と、チェックボックスＣＢと、トレーニングを行ったらチックボックスＣＢに印を付けるようユーザに促すテキスト“トレーニングを終えたら印を付けてください“とが含まれる。なお、図示は省略するが、トレーニング画面には、お手本を示す画像や解説を示すテキストなどが適宜表示され、ユーザは、画面内のお手本や解説を参考に練習を行うことができる。
【００９８】
図６（Ｃ）のトレーニング画面でチェックボックスＣＢに印が付けられ、トレーニング結果の評価（表情測定）を行う指示が行われたとすると、ＣＰＵ４２は、図６（Ｄ）のような評価画面をＬＣＤ１４に表示する。この評価画面には、表情測定を行うことを知らせるテキスト“表情を測定します…”と、評価結果を示すテキスト“今日のスコアは８０点です”とが含まれる。ここで、評価結果つまりスコアは、ユーザが顔の筋肉をどれだけお手本に近い形で動かせるかを示す数値であり、所定のアルゴリズムに従って算出される。具体的には、ユーザの顔の画像を第１カメラ１６を通じて撮像し、この顔画像から各筋肉（瞼筋，頬筋など）の動きを解析し、解析結果をお手本（各筋肉の理想的な動きを示すデータであり、プログラムと一緒にダウンロードされる）と比較して、お手本との類似度をたとえば１００点満点でスコア化する。
【００９９】
上記のような顔トレーニングが実行されている期間中、セーブデータＤａ−ＤｃがＣＰＵ４２によって逐次更新される。実行されているのがアプリＡ−Ｃのどれであっても、セーブデータＤａ−Ｄｃの各々が更新される。具体的には、ＣＰＵ４２は、トレーニング開始に先立って、セーブデータＤａ−Ｄｃを項目毎に（図９参照）統合する。ここで、統合とは、セーブデータＤａ−Ｄｃそれぞれの先頭の項目におけるデータのうち１つのデータが採用されて、採用されたデータを先頭の項目におけるデータとし、この処理を最終の項目まで繰り返すことにより統合セーブデータＤｉｎｔを得ることをいう。そして、トレーニングが開始されると、いずれかの項目に該当する動作が行われる度に統合セーブデータＤｉｎｔを更新する一方、自動保存指示またはユーザによる保存指示に応じて、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ上書きする。この上書きは、ファイル単位（図８参照）で行われる。なお、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ上書きすることは、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ更新するといってもよいし、更新された統合セーブデータＤｉｎｔでセーブデータＤａ−Ｄｃをそれぞれ書き換えるといってもよい。以下、この一連の処理について、詳しく説明する。
【０１００】
図７（Ａ）を参照して、保存用データメモリ５２はプログラム領域７０およびデータ領域７２を含み、プログラム領域７０にはアプリＡ−Ｃに対応するプログラムＰａ−Ｐｃが、データ領域７２にはアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃが、それぞれ格納される。データ領域７２にはさらに、更新処理で利用される各種テーブル、具体的には項目テーブルＣＴ，統合ルールテーブルＲＴおよびファイル管理テーブルＭＴも格納される。図７（Ｂ）を参照して、メインメモリ４８はデータ領域７４を含み、データ領域７４には統合用のセーブデータＤｉｎｔが格納される。
【０１０１】
図８を参照して、アプリＡ−Ｃ用のセーブデータＤａ−Ｄｃおよび統合用のセーブデータＤｉｎｔの各々は、項目１−４１に対応する４１種類のセーブデータを含む。項目１−４１は、それぞれの内容によって１９個のグループに分類され、各グループに１つのファイルが割り当てられる。
【０１０２】
項目１−４１の内容は図９に示されており、たとえば、項目１−３は、アプリＡ−Ｃの紹介を見たかに関するもので、ファイル１が割り当てられる。項目４−７は、トレーニング０−３を１回でも行ったかに関するもので、ファイル２が割り当てられる。項目８−１０は、第１日にアプリＡ−Ｃでトレーニングをした印（チェックマーク：図６（Ｃ）参照）をつけたかに関するもので、ファイル３が割り当てられる。項目１１−１３は、第２日にアプリＡ−Ｃでトレーニングをした印をつけたかに関するもので、ファイル４が割り当てられる。項目１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１は、同じく第３−第７日に対応し、ファイル５−９が割り当てられる。項目３２−３８は、第１−第７日のスコアに関するもので、ファイル１０−１６が割り当てられる。項目３９は、写真管理情報に関するもので、ファイル１７が割り当てられる。項目４０は、“最後にトレーニングした日は今日か”に関するもので、ファイル１８が割り当てられる。そして、項目４１は、ウォーミングアップを最後にした日時に関するもので、ファイル１９が割り当てられる。
【０１０３】
また、このような１９個のファイルの一部ここではファイル１８および１９には、それぞれのファイルの更新日時を示すデータが付加される。残りのファイル１−１７には、更新日時データは付加されない（または００００年…のような無効なデータが付加される）。
【０１０４】
図９を参照して、項目テーブルＣＴは、各項目について、上記のような内容に加え、その項目の実体，その項目を参照するアプリ（参照アプリ），およびその項目を更新するアプリ（更新アプリ）が記述される。たとえば、項目１については、内容が“アプリＡの紹介を見たか”なので、実体はＹＥＳ／ＮＯを示すフラグである。そして、このフラグを参照するのはアプリＡ自身だけであり、“アプリＡの紹介を見た”場合にこのフラグを更新するのもアプリＡに限られる。項目２，３についても、実体はフラグであり、参照アプリおよび更新アプリはアプリＢ，Ｃ自身に限られる。これらのフラグは、アプリケーションの進行状況に関連するフラグであり、アプリケーションの進行に応じて所定の処理が行われた否かを判定するためのものである。
【０１０５】
項目４については、内容が“トレーニング０（顔全体）を１回でも行ったか”なので実体はフラグであり、このフラグは全アプリＡ−Ｃによって参照されかつ全アプリＡ−Ｃによって更新される。項目５については、内容が“トレーニング１（たとえば顔の一部）を１回でも行ったか”なので実体はフラグであり、参照アプリおよび更新アプリはアプリＡ自身に限られる。項目６，７についても、実体はフラグで、参照アプリおよび更新アプリはＢ，Ｃ自身に限られる。
【０１０６】
項目８については、内容が“第１日にアプリＡでトレーニングをしたか”なので、実体はフラグである。このフラグは全アプリＡ−Ｃによって参照されるが、“第１日にアプリＡでトレーニングをした”場合にこのフラグ更新するのはアプリＡ自身に限られる。項目９については、内容が“第１日にアプリＢでトレーニングをしたか”なので実体はフラグであり、参照アプリは全アプリＡ−Ｃであるが、更新アプリはアプリＢ自身に限られる。項目１０については、内容が“第１日にアプリＣでトレーニングをしたか”なので実体はフラグであり、参照アプリは全アプリＡ−Ｃであるが、更新アプリはアプリＣ自身に限られる。項目１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１も、項目８−１０や項目１１−１３の場合と同様である。
【０１０７】
項目３２については、内容が“第１日のスコア”なので、実体はスコアである。このスコアは、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。項目３３−３８についても同様である。
【０１０８】
項目３９については、内容が“写真管理情報”なので、実体は撮影日時や番号（タイトル），データ量などである。この写真管理情報は、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。項目４０については、内容が“最後にトレーニングした日は今日か”なので、実体はフラグである。このフラグは、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。そして、項目４１については、内容が“ウォーミングアップを最後にした日時”なので、実体は日時である。この日時は、全アプリＡ−Ｃによって参照され、かつ全アプリＡ−Ｃによって更新される。
【０１０９】
なお、図９の項目テーブルＣＴにさらに、各項目に適用される統合ルール（次に説明するルールＲ１−Ｒ５のどれか）を予め記述しておいてもよい。
【０１１０】
図１０を参照して、統合ルールテーブルＲＴには、項目に割り当てられたファイルの属性および項目の実体に応じて５種類の統合ルールＲ１−Ｒ５が記述されている。具体的には、まず、ファイルの属性として“更新日時データを含む”および“更新日時データを含まない”の２種類が記述され、次に、“更新日時データを含む”に対応する項目の実体として“フラグ”および“フラグ以外”の２種類が、“更新日時データを含まない”に対応する項目の実体として“フラグ”，“スコア”および“写真管理情報”が、それぞれ記述されている。
【０１１１】
そして、ファイル属性が“更新日時データを含む”でありかつ実体が“フラグ”である項目の統合ルールＲ１として、“最新データを採用、但し最新データと同じ日付のデータがあればその同日データで立っているフラグは立てる”が記述されている。また、“更新日時データを含む”かつ“フラグ以外”である項目の統合ルールＲ２として“最新データを採用”が、“更新日時データを含まない”かつ“フラグ”である項目の統合ルールＲ３として“どれかでフラグが立っていればフラグを立てる”が、“更新日時データを含まない”かつ“スコア”である項目の統合ルールＲ４として“同じ日付の異なるスコアがあれば最もよいスコアを採用”が、そして“更新日時データを含まない”かつ“写真管理情報”である項目の統合ルールＲ５として“ＯＲつまり論理和による採用、但し同じ管理情報で異なる写真があればどれも採用しない（当該写真を読み込んで写真管理情報を再作成する）”が記述されている。
【０１１２】
セーブデータＤａ−Ｄｃは、このような統合ルールテーブルＲＴに基づいて項目毎に統合される。具体的には、図８−図１０を参照して、項目１−３は、割り当てられたファイル１がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目４−７は、割り当てられたファイル２がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目８−１０は、割り当てられたファイル３がファイル更新日時データを含まず、かつ実体がフラグなので、ルールＲ３が適用される。項目１１−１３，１４−１６，１７−１９，２０−２２，２３−２５，２６−２８および２９−３１も、項目８−１０と同様に、ルールＲ３が適用される。
【０１１３】
項目３２は、割り照られたファイル１０がファイル更新日時データを含まず、かつ実体がスコアなので、ルールＲ４が適用される。項目３３−３８も、項目３２と同様に、ルールＲ４が適用される。項目３９は、割り当てられたファイル１７が更新日時データを含まず、かつ実体が写真管理情報なので、ルールＲ５が適用される。項目４０は、割り当てられたファイル１８がファイル更新日時データを含み、かつ実体がフラグなので、ルールＲ１が適用される。そして、項目４１は、割り当てられたファイル１９がファイル更新日時データを含み、かつ実体が日時つまりフラグ以外なので、ルールＲ２が適用される。
【０１１４】
項目毎の統合の一例を図１１に示す。まず、項目１に関し、セーブデータＤａではフラグが立っており（フラグ：ＯＮ）、セーブデータＤｂ，Ｄｃではいずれもフラグが立っていない（フラグ：ＯＦＦ）とすると、ルールＲ３の適用によって、統合セーブデータＤｉｎｔではフラグが立つ（フラグ：ＯＮ）。また、項目２に関し、セーブデータＤａ−Ｄｃのいずれでもフラグ：ＯＦＦとすると、ルールＲ３の適用によって、統合セーブデータＤｉｎｔではフラグ：ＯＦＦとなる。項目３−３１の各々も、同様に統合される。
【０１１５】
次に、項目３２に関し、セーブデータＤａ，Ｄｂ，Ｄｃでスコアがそれぞれ８０，７５，８５であるとすると、ルールＲ４の適用によって、統合セーブデータＤｉｎｔではスコアは８５となる。項目３３−３８の各々も、同様に統合される。
【０１１６】
次に、項目３９に関し、セーブデータＤａ，Ｄｂ，Ｄｃで写真管理情報（たとえば撮影番号）がそれぞれ＃１−＃１２，＃２−＃１３，＃１−＃１３であれば、ルールＲ５に従って、その論理和つまり撮影番号＃１−＃１３が採用される。ただし、同じ撮影情報で異なる写真があればどの撮影情報も採用しない、という但し書きによって、たとえば、撮影番号＃２で識別される３枚の写真のうち１枚が他と違っていたとすると、この撮影番号＃２は採用されない。この場合、撮影番号＃２に対応する３枚の写真を読み込んで確認し、撮影番号を付け直す作業が行われる。
【０１１７】
次に、項目４０に関し、セーブデータＤａではフラグ：ＯＦＦ（ファイル更新日時：２００９＿８＿１＿１５：００）、セーブデータＤｂではフラグ：ＯＮ（ファイル更新日時：２００９＿８＿１５＿１１：００）、そしてセーブデータＤｃではフラグ：ＯＦＦ（ファイル更新日時：２００９＿８＿２０＿１２：００）であるとすると、ルールＲ１の適用によって、統合セーブデータＤｉｎｔではフラグＯＦＦ（ファイル更新日時：２００９＿８＿２０＿１２：００）となる。なお、セーブデータＤｂのファイル更新日時が２００９＿８＿１５＿１１：００ではなく２００９＿８＿２０＿１１：００であったなら、これは最新データと同日であり、かつこの同日データでフラグはＯＮなので、統合セーブデータＤｉｎｔでは、この同日データのフラグ：ＯＮが採用されることとなる。
【０１１８】
次に、項目４１に関し、セーブデータＤａでは日時が２００９＿８＿１＿１６：００であり、セーブデータＤｂは存在せず、そしてセーブデータＤｃでは日時が２００９＿８＿２０＿１１：００）であるとすると、ルールＲ２の適用によって、統合セーブデータＤｉｎｔでは日時は２００９＿８＿２０＿１１：００となる。
【０１１９】
セーブデータＤａ−Ｄｃは、こうして得られた統合セーブデータＤｉｎｔで上書きされる。上書きは、いずれかの項目が更新される度に、ファイル単位で行われる。
【０１２０】
また、ゲーム装置１０では、以上のような統合処理に先行して、次のようなファイル制御処理が実行される。図１２（Ａ）を参照して、制御前（２００９年８月２０日１２：００現在）のファイル管理テーブルＭＴには、読み込まれた時点のセーブデータＤａ−Ｄｃの各々について、ファイル１−１９の状態および更新日時が記述されている。状態としては、そのファイルが正常である（オープンできる）ことを示す“正常”，そのファイルが破損している（オープンできない）ことを示す“破損”，およびそのファイルがない（無効である）ことを示す“無”の３種類がある。各ファイルの状態が３種類のどれであるかは、たとえばそのファイルの検索およびオープンを試みることによって、あるいは図示しないファイルシステムを参照して、判別される。
【０１２１】
また、更新日時は、更新日時データを含むファイルであれば、そのファイルから読み取られた値（たとえば２００９＿８＿１＿１５：００）が記述され、更新日時データを含まないファイルであれば、何も記述されない（または無効な値たとえば００００年０月０日０：００が記述される）。
【０１２２】
図１２（Ｂ）を参照して、制御後（２００９年８月２０日１２：００現在）のファイル管理テーブルＭＴは、上記のような制御前のファイル管理テーブルＭＴにおいて、状態および更新日時が２箇所ずつ変更されている。具体的には、まず状態に関し、セーブデータＤｂのファイル２の状態がファイル消去を行うことなく“破損”から“無”に変更され、セーブデータＤａのファイル３の状態がファイル消去を行った上で“破損”から“無”に変更されている。
【０１２３】
ここで、“破損”ファイルを削除するか否かは、これと同じ“正常”ファイルが別のセーブデータに存在しているか否かで決まる。セーブデータＤｂにおいて破損したファイル２は、これと同じ正常なファイル２がセーブデータＤａまたはＤｃに存在するため、消去されない。セーブデータＤｃにおいて破損したファイル３は、これと同じ正常なファイル３がセーブデータＤａおよびＤｂのいずれにも存在しないため、消去される。なお、ここで消去されなかった“無”ファイル２は、後段の統合処理および上書き処理を通じ、“正常”ファイル２で上書きされることになる。
【０１２４】
更新日時に関しては、現在日時に対して未来であるファイルが制御の対象となる。制御には、そのファイルに含まれるセーブデータは有効なままで、そのファイルの更新時刻を現在日時に変更するものと、そのファイルに含まれるセーブデータ全体を無効化するものとの２種類があり、どちらの制御を行うかは、更新日時が現在日時と同日であるか、翌日以降であるかによる。
【０１２５】
具体的には、セーブデータＤｃのファイル１８は、更新日時が“２００９＿８＿２０＿１３：００”であり、これは、現在日時“２００９＿８＿２０＿１２：０５”に対して未来かつ同日であるため、ファイル１８に含まれるセーブデータは有効なままで、現在日時に変更されている。一方、セーブデータＤｂのファイル１９は、更新日時が“２００９＿８＿２１＿１１：００”であり、これは、現在日時“２００９＿８＿２０＿１２：００”に対して未来かつ翌日以降であるため、ファイル１９に含まれるセーブデータ全体が無効化されている。
【０１２６】
このようなファイル制御処理を先行して行うことで、もし破損したファイルがあっても（ファイル内のデータに異常があっても）、これと同じ正常なファイルがあれば（別のファイル内に同じデータで正常なものがあれば）、後段の統合処理および上書き処理を通じて、破損ファイル（異常データ）を正常ファイル（正常データ）で修復することが可能となる。加えて、ゲーム装置１０では、ＲＴＣ６０の調整が可能なので、ＲＴＣ６０に基づく現在日時が過去に遡る方向に調整されると、ファイル更新日時が現在日時に対して未来となって統合処理に支障が出る可能性があるが、未来を示すファイル更新日時は、現在日時と同日であれば現在日時に変更されるので、統合処理に支障が出る可能性を低減することができる。
【０１２７】
次に、顔トレーニングを行う場合のＣＰＵ４２の動作を、図１３−図１８のフローチャートにより説明する。これらのフローチャートは、図７に示したアプリＡ用のプログラムＰａと対応している。なお、アプリＢ，Ｃ用のプログラムＰｂ，Ｐｃは、図１３−図１８と同様のフローチャートで記述されるので、図示および説明を省略する。
【０１２８】
現時点で、プログラム等のダウンロードは完了しており、保存用データメモリ５２のプログラム領域７０にはアプリＡ−Ｃ用のプログラムＰａ−Ｐｃが、データ領域７２には項目テーブルＣＴ，統合ルールテーブルＲＴおよびファイル管理テーブルＭＴが、それぞれ格納されている。また、アプリＡ−Ｃは、いずれも過去に実行されたことがあり、データ領域７２にはアプリＡ−Ｃ用のセーブデータも格納されている（図７（Ａ）参照）。
【０１２９】
まず、図１３および図１４を参照して、図６（Ａ）のようなアプリ選択画面を通じてアプリＡが選択されると、ＣＰＵ４２は、アプリＡ用のプログラムＰａを起動する。この起動処理が完了すると、ステップＳ３に進んで、アプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをメインメモリ４８の作業領域（図示せず）に読み込む。そして、セーブデータＤａ−Ｄｃに含まれる各ファイルをステップＳ５で制御した後、セーブデータＤａ−Ｄｃを項目毎に統合する。ステップＳ５のファイル制御処理およびステップＳ７の統合処理の詳細については、後述する。
【０１３０】
統合処理の結果つまり統合セーブデータＤｉｎｔは、メインメモリ４８のデータ領域７４に格納される。次のステップＳ９では、保存用データメモリ５２のデータ領域７２に格納されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃを、この統合セーブデータＤｉｎｔで上書きする。なお、ステップＳ９のセーブデータ上書き処理の詳細については、後述する。更新後、ステップＳ１１でアプリ処理が開始される。なお、アプリ処理は、たとえば図６（Ａ）−図６（Ｄ）により説明した顔トレーニングに対応する処理であり、図示しない別のフローに従って実行される。また、アプリ処理は、操作部２４を介した終了操作等に応じて、あるいは所定の終了条件が満たされたときに、終了される。
【０１３１】
次に、ステップＳ１３で、項目テーブルＣＴ（図９参照）に記述されたいずれかの項目に該当する動作（項目該当動作）がアプリ処理を通じて行われたか否かを判別し、ここでＹＥＳであればステップＳ１７−Ｓ１９を経てステップＳ２１に進む。ステップＳ１３でＮＯであれば、ステップＳ１５に移り、操作部２４やタッチパネル２８等により保存指示操作が行われたか否かを判別し、ここでＹＥＳであればステップＳ１９を経てステップＳ２１に進む。ステップＳ１５でＮＯであれば、直ちにステップＳ２１に進む。
【０１３２】
ステップＳ１７では、項目該当動作が行われたのに応じて、データ領域７４に格納されている統合セーブデータＤｉｎｔを更新する。続くステップＳ１９では、データ領域７２に格納されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをこの統合セーブデータＤｉｎｔに基づいて更新する。なお、ステップＳ１９のセーブデータ上書き処理は、ステップＳ９のそれと同様の処理であり、後述する。そしてステップＳ２１で、アプリ処理が終了されたか否かを判別し、ＮＯであればステップＳ１３に戻って同様の処理を繰り返す。ステップＳ２１でＹＥＳであれば、このフローは終了となる。
【０１３３】
上記ステップＳ５のファイル制御処理は、図１５のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ３１で、セーブデータＤａ−Ｄｃに含まれる各ファイル（図８参照）の状態を検出し、結果（正常／破損／無）をファイル管理テーブルＭＴに登録する。続くステップＳ３３では、さらに、各ファイルの更新日時を検出し、結果（ファイル更新日時）をファイル管理テーブルＭＴに登録する。なお、ファイルの状態や更新日時の具体的な検出方法については、前述したので省略する。この時点で、ファイル管理テーブルＭＴは、図１２（Ａ）のようになる。
【０１３４】
その後、ステップＳ３５に進んで、「破損」ファイルがあるか否かをファイル管理テーブルＭＴに基づいて判別し、ＮＯならステップＳ４３に進む。ステップＳ３５でＹＥＳであれば、ステップＳ３７に進んで、この「破損」ファイルに対応する「正常」ファイルがあるか否かをファイル管理テーブルＭＴに基づいてさらに判別する。そして、ステップＳ３７でＹＥＳであれば、ステップＳ３９でこの「破損」ファイルの状態を「無」に変更した後、ステップＳ４３に進む。一方、ステップＳ３７でＮＯであれば、ステップＳ４１で、この「破損」ファイルを削除すると共に、その状態を「無」に変更する。そして、ステップＳ４３に進む。
【０１３５】
ステップＳ４３では、「未来」ファイルがあるか否かをファイル管理テーブルＭＴに基づいて判別し、ＮＯならステップＳ４９に進む。ステップＳ４３でＹＥＳであれば、ステップＳ４５に進んで、この「未来」ファイルの更新日時が現在日時（これは、ゲーム装置１０のローカルな現在日時であって、ＣＲＴ６０に基づく）に対して翌日以降であるか否かをファイル管理テーブルＭＴに基づいてさらに判別する。そして、ステップＳ４５でＹＥＳであれば、ステップＳ４７でこの「未来」ファイルを無効化した後、メインルーチン（図１３−図１４参照）に復帰する。一方、ステップＳ４５でＮＯであれば、ステップＳ４９で、この「未来」ファイルの更新日時を現在日時に変更した後、メインルーチンに復帰する。この時点で、ファイル管理テーブルＭＴは、図１２（Ｂ）のようになる。
【０１３６】
こうして、セーブデータの統合に先立って、ファイル管理テーブルＭＴ上で、各ファイルの状態および更新日時が制御される。
【０１３７】
上記ステップＳ７のセーブデータ統合処理は、図１６−図１７のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ６１で、項目（ここでは図９に示す４１個の項目）を識別する変数ｉに初期値“１”をセットする。そして、ステップＳ６３で項目ｉを選択し、ステップＳ６５では、項目ｉが属するファイルＦｊ（ｊは１−１９のいずれか：図８参照）を特定して、このファイルＦｊが更新日時付きか否かを判別する。ここでＮＯであれば、ステップＳ７９に移る（ステップＳ７９およびこれに続くＳ８１−Ｓ８９については後述）。
【０１３８】
ステップＳ６５でＹＥＳであれば、ステップＳ６７に進んで、変数ｊで識別される３個のファイル、つまりアプリＡ−Ｃに対応するファイルＦｊａ−Ｆｊｃのうち、更新日時が最も新しいファイルを特定する。そして、項目ｉのセーブデータとして、この最新ファイルのセーブデータ（最新データ）を採用する（ルールＲ１またはＲ２：図１０参照）。さらにステップＳ７１で、項目ｉの実体がフラグか否かを判別し、ＮＯであればこの項目の処理を終えてステップＳ９５に進む。すなわち、実体がフラグ以外の場合、統合では、単に最新データが採用される（ルールＲ２：具体例は図１１の項目４１を参照）。
【０１３９】
一方、ステップＳ７３でＹＥＳであれば、最新ファイルと同じ日付のファイル（同日付ファイル）がファイルＦｊａ−Ｆｊｃの中にあるか否かをステップＳ７５でさらに判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ７３でＹＥＳであれば、同日付ファイルのセーブデータ（同日データ）でフラグが立っているか否かをさらに判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ７５でＹＥＳであれば、ステップＳ７７でフラグを立てた後、ステップＳ９５に進む。すなわち、実体がフラグの場合、統合では、最新データが採用されるが、同日データで立っているフラグは立てられる（ルールＲ１：具体例は図１１の項目４０を参照）。
【０１４０】
一方、ファイルＦｊが更新日時付でない場合（ステップＳ６５：ＮＯ）、ステップＳ７９で、項目ｉの実体は写真管理情報か否かを判別し、ここでＮＯであればステップＳ８１で項目ｉの実体はスコアか否かをさらに判別し、ここでもＮＯであれば項目ｉの実体はフラグとみなし、ステップＳ８３に移る。ステップＳ８３では、ファイルＦｊａ−Ｆｊｃのどれかのセーブデータでフラグが立っているか否かを判別し、ここでＮＯであればステップＳ９５に進む。ステップＳ８３でＹＥＳであれば、ステップＳ８５でフラグを立てた後、ステップＳ９５に進む。すなわち、実体がフラグの場合、統合では、どれかでフラグがたっていればフラグを立てる（ルールＲ３：具体例は図１１の項目１，２を参照）。
【０１４１】
ステップＳ７９でＹＥＳあれば、ステップＳ８７に進んで、項目ｉのセーブデータＤａ−Ｄｃの中に含まれる写真管理情報を“ＯＲ”つまり論理和で採用する（ルールＲ５）。したがって、図１１の項目３９のように、セーブデータＤａに写真管理情報（撮影番号）＃１−＃１２が、セーブデータＤｂに撮影番号＃１−＃１３が、そしてセーブデータＤｃに撮影番号＃２−＃１３が含まれているとすると、撮影番号＃１−＃１３が採用される。ただし、撮影番号＃２で識別される３枚の写真のうち１枚が他と違っていたとすると、撮影番号＃２は採用されず（ルールＲ５の但し書き）、３枚の写真に撮影番号を付け直す処理が行われる。その後、ステップＳ９５に進む。
【０１４２】
ステップ８１でＹＥＳであれば、ステップＳ８９に進んで、項目ｉのセーブデータＤａ−Ｄｃの中に含まれるスコアのうち最もよいスコアを採用する（ルールＲ４：具体例は図１１の項目３２を参照）。その後、ステップＳ９５に進む。
【０１４３】
ステップＳ９５では、変数ｉをインクリメントする。そしてステップＳ９７で、変数ｉが最大値ｉｍａｘ（ここでは４１）を超えたか否かを判別し、ここでＮＯであれば、ステップＳ６３に戻って同様の処理を繰り返す。ステップＳ９７でＹＥＳであれば、メインルーチンに復帰する。
【０１４４】
なお、図１６−図１７のフローでは、各項目の統合に適用するルールは、統合ルールテーブルＲＴに基づいて（すなわちファイルの属性および項目の実体を判別して）決定されたが、項目テーブルＣＴ（図９参照）に各項目の統合ルールを予め記述しておく場合には、項目テーブルＣＴから読み取ればよい。
【０１４５】
上記ステップＳ９，Ｓ１９のセーブデータ上書き処理は、図１８のサブルーチンに従って実行される。ＣＰＵ４２は、最初のステップＳ１０１で、ファイル（ここでは図８に示す１９個のファイル）を識別する変数ｊに初期値“１”をセットする。そして、ステップＳ１０３で、統合セーブデータＤｉｎｔのファイルＦｊｉｎｔをメインメモリ４８の作業領域（図示せず）に取り込む。そして、ファイルＦｊｉｎｔに属する項目の少なくとも１つに変化があったか否かをステップＳ１０５で判別し、ここでＮＯであればステップＳ１０９に進む。ステップＳ１０５でＹＥＳであれば、ステップＳ１０７でセーブデータＤａ−ＤｃのファイルＦｊａ−ＦｊｃをファイルＦｊｉｎｔにより上書きした後、ステップＳ１０９に進む。
【０１４６】
ステップＳ１０９では、変数ｊをインクリメントする。そしてステップＳ１１１で、変数ｊが最大値ｊｍａｘ（ここでは１９）を超えたか否かを判別し、ここでＮＯであれば、ステップＳ１０３に戻って同様の処理を繰り返す。ステップＳ１１１でＹＥＳであれば、メインルーチンに復帰する。
【０１４７】
このように、更新にあたって、各ファイル１−１９が変更のあった項目を含むか否かを判別して、判別結果がＹＥＳであるファイルだけを上書きするので、保存用データメモリ５２として特にＮＡＮＤ型フラッシュメモリを用いて、効率的な上書きが行える。
【０１４８】
以上から明らかなように、この実施例のゲーム装置１０では、アプリＡ−Ｃ（第１−第３アプリ）によって共用されるセーブデータが、保存用データメモリ５２（記憶手段）に、アプリＡ−Ｃに対応させてセーブデータＤａ−Ｄｃ（第１−第３セーブデータ）として記憶される。ＣＰＵ４２（コンピュータ）は、たとえばアプリＡが起動されると、保存用データメモリ５２に記憶されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃをメインメモリ４８内で統合し（Ｓ７）、この統合データＤｉｎｔをアプリＡの実行に従って更新する（Ｓ１７）一方、自動保存指示やユーザによる保存指示に応じて、保存用データメモリ５２に記憶されているセーブデータＤａ−Ｄｃを更新された統合データＤｉｎｔで上書きする（Ｓ１９）。これにより、アプリＡ−Ｃ間で共用されるセーブデータを、煩雑な操作なしで最新状態に保つことができる。
【０１４９】
また、ＣＰＵ４２は、上記の統合処理（Ｓ７）をアプリ起動時に実行し、そしてアプリ処理が実行開始される前に、セーブデータＤａ−Ｄｃを統合データＤｉｎｔで上書きする（Ｓ９）。こうして、アプリ起動時に、セーブデータＤａ−Ｄｃを統合して、統合結果を速やかにセーブデータＤａ−Ｄｃに反映させることで、最新のセーブデータでアプリ処理を実行することができる。
【０１５０】
また、ＣＰＵ４２は、統合処理（Ｓ７）に先行して制御処理（Ｓ５）を実行することで、統合処理を通じてセーブデータの異常を修復する。これにより、たとえばセーブデータＤａに異常があっても、セーブデータＤｂまたはＤｃが正常であれば、その異常は、統合処理および更新処理を通じて修復することができる。
【０１５１】
なお、この実施例では、保存用データメモリ５２内にアプリＡ−Ｃ用のプログラムＰａ−ＰｃおよびセーブデータＤａ−Ｄｃが記憶されているが、プログラムＰａ−Ｐｃのいずれか１つまたは２つが現時点で記憶されていなくても、セーブデータＤａ−Ｄｃは記憶されていてよく、この場合、統合の効果を各セーブデータＤａ−Ｄｃに及ぼすことができる。たとえば、セーブデータＤａおよびＤｂの間で統合を行い、結果をセーブデータＤａ−Ｄｃに反映させる（セーブデータＤａおよびＤｂに基づく統合データＤｉｎｔでセーブデータＤａ−Ｄｃを上書きする）ことができる。
【０１５２】
また、この実施例では、項目をグループ分けして１グループに１ファイルを割り当てたが、グループ分けはせずに、１項目に１ファイルを割り当ててもよく、単一のファイルに全項目を含めることも可能である。ただし、グループ分けをする方が、効率的な上書きが行える。
【０１５３】
そして、この実施例では、上書きをファイル単位で行ったが、項目単位で上書きを行うような実施例も可能である。ただし、保存用データメモリとして、ＮＯＲ型フラッシュメモリのような、より細かな上書き制御が可能なメモリを用いる必要が生じる。
【０１５４】
また、この実施例では、保存用データメモリ５２に記憶されているアプリＡ−Ｃ用のセーブデータＤａ−Ｄｃを統合し、統合して得られた統合データＤｉｎｔを用いてアプリＡ−Ｃのいずれかを実行して、アプリＡ−Ｃのいずれかの実行に応じて更新された統合データＤｉｎｔをセーブデータＤａ−Ｄｃに上書きするようにしているが、これに限られず、保存用データメモリ５２に記憶されている所定のデータを用いてアプリＡ−Ｃのいずれかを実行して、アプリＡ−Ｃのいずれかの実行に応じて更新された所定のデータをセーブデータＤａ−Ｄｃに上書きするようにしてもよい。この場合、上記所定のデータは、統合データＤｉｎｔと同じデータ構造を有する。
【０１５５】
以上では、ゲーム装置１０について説明したが、この発明は、アプリＡ，Ｂ，Ｃ…によってその少なくとも一部が共用されるデータ（セーブデータ，履歴データ，参照データ，学習データなど）をアプリＡ，Ｂ，Ｃ，…に対応させてデータＤａ，Ｄｂ，Ｄｃ，…として記憶する記憶手段（フラッシュメモリなどの保存用データメモリ，ハードディスク，書き換え可能な光ディスクなど）に接続されたコンピュータ（ＣＰＵ）を備える、情報処理装置（ＰＣ，ＰＤＡ，携帯電話端末など）に適用できる。
【符号の説明】
【０１５６】
１０ …ゲーム装置
４２ …ＣＰＵ
４８ …メインメモリ
５２ …保存用データメモリ
Ｐａ−Ｐｃ …アプリＡ−Ｃ用プログラム
Ｄａ−Ｄｃ …アプリＡ−Ｃ用セーブデータ
Ｄｉｎｔ …統合セーブデータ
Ｒ１−Ｒ５ …統合ルール
【特許請求の範囲】
【請求項１】
第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段に接続されたコンピュータを、
所定のデータで前記第１アプリケーションを実行するアプリケーション実行手段、
前記アプリケーション実行手段による前記第１アプリケーションの実行にしたがって前記所定のデータを更新する更新手段、および
前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする第１上書き手段として機能させる、情報処理プログラム。
【請求項２】
前記記憶手段に記憶されている前記第１データおよび前記第２データを統合する統合手段として前記コンピュータをさらに機能させ、
前記アプリケーション実行手段は、前記統合手段によって統合された統合データで前記第１アプリケーションを実行する、請求項１記載の情報処理プログラム。
【請求項３】
前記第１上書き手段は、所定の指示に応じて、前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする、請求項１に記載の情報処理プログラム。
【請求項４】
前記第１アプリケーションを起動させる起動手段として前記コンピュータをさらに機能させ、
前記統合手段は、前記起動手段によって前記第１アプリケーションが起動されたときに統合を行う、請求項２記載の情報処理プログラム。
【請求項５】
前記記憶手段に記憶されている前記第１データおよび前記第２データを、前記第１アプリケーションが起動されたときに前記統合手段によって統合された統合データで、前記第１アプリケーションの実行が開始される前に上書きする、第２上書き手段として前記コンピュータをさらに機能させる、請求項４記載の情報処理プログラム。
【請求項６】
前記第１および／または第２上書き手段は、前記記憶手段に記憶されている前記第１データおよび／または前記第２データのうち、前記統合手段によって統合された統合データと異なる部分を上書きする、請求項５記載の情報処理プログラム。
【請求項７】
前記データの共用部分は複数の項目に区分されており、前記統合手段は前記第１データおよび前記第２データを項目毎に統合する、請求項２ないし６のいずれかに記載の情報処理プログラム。
【請求項８】
前記複数の項目の各々は、それぞれに１つのファイルが割り当てられた複数のグループのいずれか１つに属しており、
前記第１および／または第２上書き手段は、前記第１データおよび前記第２データをファイル単位で上書きする、請求項７記載の情報処理プログラム。
【請求項９】
前記第１および／または第２上書き手段は、前記複数のグループ毎にそこに含まれる全ての項目について変化があるか否かを判定し、判定結果が肯定である項目を少なくとも１つ含むグループに対応するファイルについて上書きを行う、請求項８記載の情報処理プログラム。
【請求項１０】
前記統合手段は、各ファイルの属性および／または各項目の実体に応じたルールに従って統合を行う、請求項８または９記載の情報処理プログラム。
【請求項１１】
前記属性は、各ファイルが更新日時データを含むか否かに関し、
前記ルールは、各ファイルが更新日時データを含んでいれば最新ファイルのデータを採用するという最新採用ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１２】
前記ルールは、項目の実体がアプリケーションの進行状況に関連するフラグである場合にはどれかのデータでフラグが立っていればフラグを立てるというフラグルールを含む、請求項１０記載の情報処理プログラム。
【請求項１３】
前記ルールは、項目の実体が値である場合には最も良い値を採用するという最良値ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１４】
前記ルールは、項目の実体がデータの管理情報である場合には論理和により採用するという論理和ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１５】
前記論理和ルールには、同じ管理情報の異なるデータがあればどれも採用しないという条件がつく、請求項１４記載の情報処理プログラム。
【請求項１６】
前記所定の指示は、自動保存指示を含む、請求項３記載の情報処理プログラム。
【請求項１７】
前記データは、前記第１アプリケーションおよび前記第２アプリケーションの各アプリケーションの実行により変化する当該各アプリケーションに関連するパラメータを示すデータである、請求項１記載の情報処理プログラム。
【請求項１８】
前記記憶手段に記憶されている前記第１データに異常がある場合に、前記記憶手段に記憶されている前記第２データを利用して当該異常を修復するように前記統合手段を制御する、制御手段として前記コンピュータをさらに機能させる、請求項２記載の情報処理プログラム。
【請求項１９】
前記制御手段は、前記第１データに対応する更新日時データが現在日時に対して未来かつ同日を示す場合には当該現在日時を示すように当該更新日時データを変更する一方、未来かつ翌日以降を示す場合には当該第１データを無効化する、日時制御手段を含む、請求項１８記載の情報処理プログラム。
【請求項２０】
第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段、
所定のデータで前記第１アプリケーションを実行するアプリケーション実行手段、
前記アプリケーション実行手段による前記第１アプリケーションの実行にしたがって前記所定のデータを更新する更新手段、および
前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする第１上書き手段を備える、情報処理装置。
【請求項１】
第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段に接続されたコンピュータを、
所定のデータで前記第１アプリケーションを実行するアプリケーション実行手段、
前記アプリケーション実行手段による前記第１アプリケーションの実行にしたがって前記所定のデータを更新する更新手段、および
前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする第１上書き手段として機能させる、情報処理プログラム。
【請求項２】
前記記憶手段に記憶されている前記第１データおよび前記第２データを統合する統合手段として前記コンピュータをさらに機能させ、
前記アプリケーション実行手段は、前記統合手段によって統合された統合データで前記第１アプリケーションを実行する、請求項１記載の情報処理プログラム。
【請求項３】
前記第１上書き手段は、所定の指示に応じて、前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする、請求項１に記載の情報処理プログラム。
【請求項４】
前記第１アプリケーションを起動させる起動手段として前記コンピュータをさらに機能させ、
前記統合手段は、前記起動手段によって前記第１アプリケーションが起動されたときに統合を行う、請求項２記載の情報処理プログラム。
【請求項５】
前記記憶手段に記憶されている前記第１データおよび前記第２データを、前記第１アプリケーションが起動されたときに前記統合手段によって統合された統合データで、前記第１アプリケーションの実行が開始される前に上書きする、第２上書き手段として前記コンピュータをさらに機能させる、請求項４記載の情報処理プログラム。
【請求項６】
前記第１および／または第２上書き手段は、前記記憶手段に記憶されている前記第１データおよび／または前記第２データのうち、前記統合手段によって統合された統合データと異なる部分を上書きする、請求項５記載の情報処理プログラム。
【請求項７】
前記データの共用部分は複数の項目に区分されており、前記統合手段は前記第１データおよび前記第２データを項目毎に統合する、請求項２ないし６のいずれかに記載の情報処理プログラム。
【請求項８】
前記複数の項目の各々は、それぞれに１つのファイルが割り当てられた複数のグループのいずれか１つに属しており、
前記第１および／または第２上書き手段は、前記第１データおよび前記第２データをファイル単位で上書きする、請求項７記載の情報処理プログラム。
【請求項９】
前記第１および／または第２上書き手段は、前記複数のグループ毎にそこに含まれる全ての項目について変化があるか否かを判定し、判定結果が肯定である項目を少なくとも１つ含むグループに対応するファイルについて上書きを行う、請求項８記載の情報処理プログラム。
【請求項１０】
前記統合手段は、各ファイルの属性および／または各項目の実体に応じたルールに従って統合を行う、請求項８または９記載の情報処理プログラム。
【請求項１１】
前記属性は、各ファイルが更新日時データを含むか否かに関し、
前記ルールは、各ファイルが更新日時データを含んでいれば最新ファイルのデータを採用するという最新採用ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１２】
前記ルールは、項目の実体がアプリケーションの進行状況に関連するフラグである場合にはどれかのデータでフラグが立っていればフラグを立てるというフラグルールを含む、請求項１０記載の情報処理プログラム。
【請求項１３】
前記ルールは、項目の実体が値である場合には最も良い値を採用するという最良値ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１４】
前記ルールは、項目の実体がデータの管理情報である場合には論理和により採用するという論理和ルールを含む、請求項１０記載の情報処理プログラム。
【請求項１５】
前記論理和ルールには、同じ管理情報の異なるデータがあればどれも採用しないという条件がつく、請求項１４記載の情報処理プログラム。
【請求項１６】
前記所定の指示は、自動保存指示を含む、請求項３記載の情報処理プログラム。
【請求項１７】
前記データは、前記第１アプリケーションおよび前記第２アプリケーションの各アプリケーションの実行により変化する当該各アプリケーションに関連するパラメータを示すデータである、請求項１記載の情報処理プログラム。
【請求項１８】
前記記憶手段に記憶されている前記第１データに異常がある場合に、前記記憶手段に記憶されている前記第２データを利用して当該異常を修復するように前記統合手段を制御する、制御手段として前記コンピュータをさらに機能させる、請求項２記載の情報処理プログラム。
【請求項１９】
前記制御手段は、前記第１データに対応する更新日時データが現在日時に対して未来かつ同日を示す場合には当該現在日時を示すように当該更新日時データを変更する一方、未来かつ翌日以降を示す場合には当該第１データを無効化する、日時制御手段を含む、請求項１８記載の情報処理プログラム。
【請求項２０】
第１アプリケーションおよび第２アプリケーションによってその少なくとも一部が共用されるデータを、当該第１アプリケーションに対応させて第１データとして記憶すると共に、当該第２アプリケーションに対応させて第２データとして記憶する、記憶手段、
所定のデータで前記第１アプリケーションを実行するアプリケーション実行手段、
前記アプリケーション実行手段による前記第１アプリケーションの実行にしたがって前記所定のデータを更新する更新手段、および
前記記憶手段に記憶されている前記第１データおよび前記第２データを前記更新手段によって更新された所定のデータで上書きする第１上書き手段を備える、情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−５９７６１（Ｐ２０１１−５９７６１Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２００９−２０５６５６（Ｐ２００９−２０５６５６）
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００２３３７７８）任天堂株式会社 (1,115)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００２３３７７８）任天堂株式会社 (1,115)
【Ｆターム（参考）】
[ Back to top ]