JP2012018657A - 情報処理端末、情報処理システム、情報処理プログラム - Google Patents

Abstract

【課題】ユーザの特別な操作を必要とせずに、新たなアプリケーションの新規インストールや、各種アプリケーションやシステムのアップデートを行うことのできる情報処理装置を提供すること。
【解決手段】情報処理装置は、接続手段と、受信手段と、インストール手段とを備える。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、プログラムの情報処理装置へのインストール処理を自動的に行う。
【選択図】図５０

Description

本発明は、通信機能を備えた情報処理端末に関し、より特定的には、システムやアプリケーションのインストール処理が実行可能な情報処理端末等に関する。

近年、デジタルコンテンツを、ネットワークを介して配信するためのシステムが主流となりつつある。その中で、コンテンツをプッシュ配信するための技術が存在している。例えば特許文献１に開示されるシステムでは、探索画面で一旦コンテンツの探索を行った後、サーバにメールを送信すると、以降、探索を行った探索条件に合致する新規コンテンツが配信された場合、サーバからコンテンツのお試し版がメールに添付されて配信される。

特開２００５−２４２３９９号公報

しかし、ネットワークを用いたコンテンツ配信のシステムの多くは、ユーザが、手に入れたいコンテンツに能動的にアクセスしてコンテンツのダウンロードを行う必要がある。すなわち、魅力的なコンテンツがあったとしても、能動的にアクセスを行わないユーザに対してはコンテンツを知らせる方法がなく、自ら積極的にアクセスを行うことは望まないが魅力的なコンテンツを手軽に知りたいというユーザの要望と、多くの人的あるいは金銭的なリソースを用いて制作したコンテンツを多くの人に知らせたいというコンテンツ制作者の要望があった。この点、特許文献１に開示されるシステムでは、コンテンツの配信後、当該コンテンツがすぐに実行可能な状態にまでもっていくかどうかという点については、上記特許文献１では考慮されていない。（例えば、インストールを要するプログラムが配信された場合、ユーザは手動にてインストーラの実行を必要とすることになる。）

それ故に、本発明の目的は、ユーザの特別な操作を必要とせずに、新たなアプリケーションの新規インストールや、各種アプリケーションやシステムのアップデートを行うことのできる情報処理装置等を提供することにある。

上記目的を達成するために、本発明は以下のような構成を採用した。

本発明の情報処理装置は、接続手段と、受信手段と、インストール手段とを備える。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、プログラムの情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに（ユーザ側からの能動的なアクセスを行わなくとも）、新しいアプリケーションやアップデートプログラムを提供できる。また、主にソフトウェア開発者の立場からすると、以下のような利点がある。新規のアプリケーションをインストールするためにユーザ側から能動的なアクセスを要するような環境では、後にアプリケーションに機能追加等が行われたとき、ユーザに機能追加のための作業（能動的なアクセス）を行ってもらえる可能性が低い。そのために、ハードウェアを所持するユーザのうち最も多くのユーザにアプリケーションを提供するためには、開発スケジュールをハードウェアの発売に間に合わせプリインストールさせる必要があった。しかし、本発明によれば、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能となり、ソフトウェア開発者のソフト開発にかかる負担を軽減することが可能となる。

他の構成例として、情報処理装置は、非使用状態と使用状態とを切り替える切替手段を更に備え、接続手段は、情報処理装置が少なくとも非使用状態で稼働しているときに、自動的にサーバに接続し、受信手段は、情報処理装置が少なくとも非使用状態において、受信処理を自動的に行い、インストール手段は、少なくとも非使用状態において、受信手段が受信したプログラムのインストール処理を自動的に行うようにしてもよい。

上記構成例によれば、非使用状態でもプログラムの受信及びインストールが行われるので、効率的にインストールを行うことができるとともに、ユーザの気付かないうちにプログラムの新規インストールが行われるため、ユーザに驚きを与えることができる。

更に他の構成例として、非使用状態は、使用状態よりも消費電力が少ないようにしてもよい。

上記構成例によれば、例えば、いわゆる省電力モードのような、消費電力が小さい状態にあっても、プログラムのインストールを自動的に行うことができる。

更に他の構成例として、情報処理装置は、ユーザにより開閉の操作が可能であり、切替手段は、情報処理装置が開状態であるときに使用状態に切り替え、閉状態であるときに非使用状態に切り替えるようにしてもよい。

上記構成例によれば、閉状態であっても、プログラムのインストールを自動的に行うことができる。

更に他の構成例として、情報処理装置は、表示装置を更に備え、切替手段は、ユーザによる所定の操作に応じて使用状態と非使用状態とを切り替え使用状態においては表示装置に電力が供給され、非使用状態においては表示装置への電力は供給されないようにしてもよい。

上記構成例によれば、表示装置に電力が供給されていない状態にあっても、プログラムのインストールを自動的に行うことができる。

更に他の構成例として、情報処理装置は、携帯型情報端末であり、自動的に繰り返し所定のアクセスポイントを探索する探索手段を更に備え、接続手段は、探索手段によってアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介してサーバと接続を行うようにしてもよい。

上記構成例によれば、自動的に繰り返しアクセスポイントを探索するので、常に移動するため固定した接続環境に存在することのない携帯型情報端末であっても、ユーザの操作を必要とせず自動的にプログラムのインストールを行うことができる。

更に他の構成例として、情報処理装置は、プログラムの受信処理のそれぞれについて、当該受信が完了したか否かを示す受信状況を記憶する受信状況記憶手段を更に備え、受信手段は、受信状況に基づいて、受信が完了していないことが示されている受信処理を再開する。

上記構成例によれば、頻繁に場所の移動がなされ常に同様の電波環境にいるとは限らない情報処理装置において、途中で接続が切断されても、その後に接続が回復したような際に、途中から未完了の受信処理を再開できるので、切断前の受信処理を無駄にせず、効率の良い受信処理が実現できる。

更に他の構成例として、情報処理装置は、１以上の前記プログラムの受信処理をそれぞれ規定する１以上のタスクを設定するタスク設定手段を更に備え、受信状況記憶手段は、当該タスクによって規定される受信処理が完了したか否かを示す受信状況をタスク毎に記憶し、受信手段は、受信が完了していないことを示す受信状況が記憶されているタスクによって規定される受信処理を再開するようにしてもよい。

上記構成例によれば、頻繁に場所の移動がなされ常に同様の電波環境にいるとは限らない情報処理装置において、途中で接続が切断されても、その後に接続が回復したような際に、途中から未完了の受信処理を再開できるので、切断前の受信処理を無駄にせず、効率の良い受信処理が実現できる。

更に他の構成例として、情報処理装置は、接続手段によってサーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報をサーバから受信する配信情報受信手段と、配信中プログラム情報を受信したとき、当該配信中プログラム情報によって特定される受信可能なプログラムの受信処理を行うか否かを所定の条件に基づいて決定する受信可否決定手段とを備え、受信手段は、受信可否決定手段によって受信処理を行うと決定されたプログラムの受信処理を行うようにしてもよい。

上記構成例によれば、複数のプログラムの更新があったときに、所定条件を満たすものだけを受信することができるので、効率よく受信処理およびインストール処理を行うことができる。なお、ここでいう所定条件とは、例えば、ある種類のプログラムを所持しているか否かや、同じバージョンを所持しているか否か、情報処理装置のユーザの年齢とプログラムの想定する利用者の年齢とが合致するか否か、等が挙げられる。

更に他の構成例として、情報処理装置は、所定のプログラムの実行履歴を示す実行履歴データを記憶する実行履歴記憶手段を更に備え、配信中プログラム情報は、受信可能な受信条件付きプログラムを特定する情報及び当該受信可能なプログラムを受信するために必要となる所定のプログラムの実行履歴に関する条件が受信のための条件を含み、受信可否決定手段は、実行履歴データで示される実行履歴が前記受信のための条件を満たしているときに、受信条件付きプログラムの受信処理を行うと決定し、当該実行履歴が当該受信のための条件を満たしていないときは、受信条件付きプログラムの受信処理を行わないと決定してもよい。

上記構成例によれば、アプリの実行履歴に関する所定の条件が満たされると所定のプログラムが自動的にインストールされるため、ユーザに驚きを与えると共に、ゲームのようなプログラムについて、新たなプログラムをインストールさせるためにより多くプレイさせる動機付けを提供することができる。

更に他の構成例として、情報処理装置は、接続手段によって前記サーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報をサーバから受信する配信情報受信手段と、配信中プログラム情報によって特定される受信可能プログラムが既に自機にインストールされているか否かを判定するインストール状況判定手段を更に備え、受信手段は、配信中プログラム情報によって特定される受信可能プログラムの受信処理を行い、インストール手段は、受信手段によって受信されたプログラムのうち、インストール状況判定手段によって既にインストール済みと判定されたプログラムについては当該プログラムのアップデート処理を行い、まだインストールされていないと判定されたプログラムについては新規インストール処理を行うようにしてもよい。

上記構成例によれば、配信されている複数のプログラムのうち、ユーザが所持していないものについては新規インストールがなされ、既に所持しているものはアップデートがそれぞれ自動的に行われることになり、ユーザの利便性をより高めることができる。

更に他の構成例として、情報処理装置は、接続手段によってサーバへの接続が行われたとき、受信可能なアプリケーションプログラムの一覧を示す配信中アプリ情報をサーバから受信する配信情報受信手段と、配信中アプリ情報を受信したとき、当該配信中アプリ情報によって特定される受信可能なアプリケーションプログラムの受信処理を行うか否かを所定の条件に基づいて決定する受信可否決定手段とを備え、受信手段は、受信可否決定手段によって受信処理を行うと決定されたアプリケーションプログラムの受信処理を行うようにしてもよい。

上記構成例によれば、複数のアプリケーションプログラムが配信されている場合、条件を満たすものだけを受信することができるので、効率よく受信処理およびインストール処理を行うことができる。

更に他の構成例として、情報処理装置は、当該情報処理装置のユーザの年齢を使用者年齢情報として当該情報処理装置内に記憶する年齢情報記憶手段を更に備え、配信中プログラム情報は、受信可能な各プログラムについての対象年齢を表す情報を含み、受信可否決定手段は、使用者年齢情報と各プログラムの対象年齢とを比較し、比較結果が所定の条件を満たしたとき、当該プログラムの受信処理を行うと決定するようにしてもよい。

上記構成例によれば、年齢制限を設けているため、ユーザに不相応なプログラムの実行のみならず受信をさせないことができ、効率的に受信処理を行うことができる。

更に他の構成例によれば、情報処理装置は、接続手段によってサーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報及び当該配信中プログラム情報で示される各プログラムを受信する順番を表した優先度情報を当該サーバから受信する配信情報受信手段を更に備え、受信手段は、配信中プログラム情報によって特定されるプログラムを、優先度情報に基づいた順番にて受信するようにしてもよい。

上記構成例によれば、優先度が設定されるので、緊急を要するプログラムや（配信者側の）お薦めプログラムを（配信者側がサーバの優先度情報を操作することで）より早く受信しインストールすることができる。

更に他の構成例として、情報処理装置は、インストールされたプログラムの一覧を作成し出力する一覧作成手段と、情報処理装置への所定の操作に応じて、一覧からいずれかのプログラムを選択する選択手段と、選択されたプログラムのアンインストール処理を行うアンインストール手段とを更に備えてもよい。

上記構成例によれば、自動的にインストールされたプログラムについては、後にユーザの操作によりアンインストールできるため、ユーザとって、新たなプログラムの導入に不満が生じたときは、過去の状態に戻すことも容易となる。また、従来はプログラムの導入をユーザに能動的に行わせていたところ、プログラムの削除をユーザに能動的に行わせることができる。

更に、他の構成例として、情報処理装置は、アンインストール手段によってアンインストールされたプログラムを特定するための削除プログラム特定情報を記憶する削除履歴記憶手段を更に備え、受信手段は、配信中プログラム情報で示されるプログラムのうち、削除プログラム特定情報で特定されるプログラムについては、受信処理を行わないようにしてもよい。

上記構成例によれば、ユーザの意思によって削除されたプログラムについては、自動的にインストールされることを防ぐことができ、ユーザの利便性を高めることができる。

更に他の構成例として、情報処理装置は、ユーザの所定の操作に応じて、情報処理装置用のプログラムが登録された所定のサーバに接続し、ユーザが希望するプログラムを、削除プログラム特定情報に含まれているプログラムであるか否かにかかわらず受信するようにしてもよい。

上記構成例によれば、ユーザの意思によって削除されたプログラムであり、自動的に受信及びインストールがなされなくなっているプログラムであっても、ユーザが再度インストールする意思があれば、再度インストールすることが可能となる。

更に他の構成例によれば、情報処理装置は記憶部を更に備え、インストール手段は、受信手段によって受信したプログラムを記憶部に記憶し、当該プログラムを実行可能とするための実行環境設定処理を行うことでインストールを完了させるようにしてもよい。

上記構成例によれば、自動的に実行環境の設定を行うので、ユーザは特別な操作を行うことなくプログラムを実行可能な状態にすることができる。

更に他の構成例として、情報処理装置は、インストールされたプログラムを記憶する記憶部と、情報処理装置の起動時に、記憶部に記憶されているプログラムの一覧を作成し出力する一覧作成手段と、情報処理装置に対して行われた所定の操作に応じて、一覧からいずれかのプログラムを選択する選択手段と、選択されたプログラムを実行するプログラム実行手段とを備え、インストール手段は、受信したプログラムを自動的に記憶部に記憶するようにしてもよい。

上記構成例によれば、記憶部に記憶され、一覧（例えば、情報処理装置を起動したときに表示されるメニュー）の対象になるので、ユーザは新たに受信されたプログラムに気付くことができる。

更に他の構成例によれば、情報処理装置は、インストールされたプログラムを記憶する記憶部と、情報処理装置に対して行われた所定の操作に応じて、記憶部に記憶されているプログラムの一覧を作成し出力する一覧作成手段と、情報処理装置への所定の操作に応じて、一覧からいずれかのプログラムを選択する選択手段と、選択されたプログラムを実行するプログラム実行手段とを備え、インストール手段は、受信したプログラムを自動的に前記記憶部に記憶するようにしてもよい。

上記構成例によれば、記憶部に記憶されたプログラムは、所定の操作に応じて出力されるプログラムの一覧に含まれるため、ユーザは新たに受信されたプログラムに気付くことができる。

更に他の構成例として、インストール手段は、更に、受信したプログラムが一覧作成手段によって作成される一覧の掲載対象となるように自動的に設定を行うことでインストールを完了するようにしてもよい。

上記構成例によれば、インストール処理としてプログラムの一覧の掲載対象となるような設定まで行うため、ユーザは新たに受信されたプログラムに気付くことができる。

更に他の構成例として、情報処理装置は権利情報データベース及び複数のプログラムを記憶する記憶部をさらに備え、受信手段は、プログラムとともに当該プログラムを実行するための権利情報を受信し、インストール手段は、受信したプログラムを自動的に記憶部に記憶するとともに、受信した権利情報を自動的に権利情報データベースに登録し、情報処理装置は、記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、実行指示を受け付けたとき、権利情報データベースに登録されている権利情報を用いて当該権利情報の認証を行う認証手段と、認証が成功したとき、実行指示がなされたプログラムを実行するプログラム実行手段とを更に備えるようにしてもよい。

上記構成例によれば、権利情報の認証が成功したときにプログラムを実行するので、不正な使用を防ぐことができる。

更に他の構成例として、情報処理装置は権利情報データベース及び複数のプログラムを記憶する記憶部をさらに備え、受信手段は、プログラムとともに当該プログラムを実行するための権利情報を受信し、インストール手段は、受信手段によってプログラム及び権利情報を受信したとき、権利情報の正当性の有無を自動的に判別する正当性確認手段と、権利情報の正当性があると判別されたとき、プログラム及び権利情報を記憶部に自動的に記憶する権利情報記憶手段と、権利情報の正当性がないと判別されたとき、権利情報の内容を破棄する権利情報破棄手段とを含み、情報処理装置は、記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、実行指示を受け付けたとき、権利情報を記憶部から読み出し、当該権利情報の認証を行う認証手段と、認証が成功したとき、実行指示がなされたプログラムを実行するプログラム実行手段とを更に備えるようにしてもよい。

上記構成例によれば、インストール処理の一環として権利情報の正当性をチェックして、権利情報の認証が成功したときにプログラムを実行するので、不正な使用を防ぐことができる。

更に他の構成例として、情報処理装置は複数のプログラムを記憶する記憶部をさらに備え、受信手段は、プログラムを受信し、インストール手段は、受信手段によってプログラムを受信したとき、当該受信したプログラムの正当性の有無を自動的に判別する正当性確認手段と、受信したプログラムの正当性があると判別されたとき、当該プログラムを記憶部に自動的に記憶する権利情報記憶手段と、受信したプログラムの正当性がないと判別されたとき、当該受信したプログラムを破棄する破棄手段とを含み、情報処理装置は、記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、実行指示を受け付けたとき、当該実行指示がなされたプログラムを実行するプログラム実行手段とを更に備えるようにしてもよい。

上記構成によれば、インストール処理の一環として受信したプログラムファイルの正当性をチェックするため、不正なプログラムが実行されることを防ぐことができる。

更に他の構成例として、接続手段は、ユーザに接続に関する操作を一切求めずにサーバへの接続を自動的に行い、受信手段は、１以上のプログラムの受信処理に際して、ユーザに対して当該受信処理に関する操作を一切求めずに受信処理を自動的に行い、インストール手段は、プログラムの情報処理装置へのインストールに際して、ユーザに対して当該インストール処理に関する操作を一切求めずに処理を進めることでインストール処理を実行するようにしてもよい。

上記構成例によれば、ユーザに特別な操作を求めることなく、プログラムを実行可能な状態にすることができる。

更に他の構成例として、情報処理装置は、接続手段によってサーバへの接続が行われたとき、受信可能なアプリケーションプログラムの一覧を示す配信中アプリ情報をサーバから受信する配信情報受信手段と、配信中アプリ情報によって特定される受信可能なアプリケーションプログラムが、既に自機にインストールされているか否かを判定するアプリインストール状況判定手段を更に備え、受信手段は、前記配信中アプリ情報によって特定される受信可能なアプリケーションプログラムの受信処理を行い、インストール手段は、受信手段によって受信されたアプリケーションプログラムのうち、アプリインストール状況判定手段によって既にインストール済みと判定されたアプリケーションプログラムについては当該アプリケーションプログラムの更新インストールを行い、まだインストールされていないと判定されたアプリケーションプログラムについては新規インストールを行うようにしてもよい。

上記構成例によれば、配信されている複数のアプリケーションのうち、ユーザが所持していないものについては新規インストールがなされ、既に所持しているものはアップデートがそれぞれ自動的に行われることになり、ユーザの利便性をより高めることができる。

更に他の構成例として、サーバから受信されるプログラムには、システムプログラムとアプリケーションプログラムの２種類のプログラムが存在し、受信手段は、アプリケーションプログラムを自動的に受信し、インストール手段は、アプリケーションプログラムの情報処理装置へのインストール処理を自動的に行うようにしてもよい。

上記構成例によれば、自動的にアプリケーションプログラムの受信・インストールを行うため、ユーザの何らの操作も必要とせずに、新しいアプリケーションを提供することができる。

本発明の情報処理装置は、切替手段と、接続手段と、受信手段と、アプリインストール手段とを備える。切替手段は、非使用状態と使用状態とを切り替える。接続手段は、情報処理装置が少なくとも非使用状態で稼働しているときに、自動的にサーバに接続する。受信手段は、情報処理装置が少なくとも非使用状態で稼働しているときにおいて、サーバから１以上のアプリケーションプログラムの受信処理を自動的に行う。アプリインストール手段は、情報処理装置が少なくとも非使用状態で稼働しているときにおいて、アプリケーションプログラムの当該情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にアプリケーションプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに、新しいアプリケーションやアップデートプログラムを提供できる。更に、非使用状態でもアプリケーションプログラムの受信及びインストールが行われるので、効率的にインストールを行うことができるとともに、ユーザの気付かないうちにアプリケーションプログラムの新規インストールが行われるため、ユーザに驚きを与えることができる。

本発明の情報処理装置は、接続手段と、受信手段と、アプリインストール手段とを備える。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のアプリケーションプログラムの受信処理を自動的に行う。アプリインストール手段は、アプリケーションプログラムの情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にアプリケーションの受信およびインストールを行うので、ユーザの何らの操作も必要とせずに、新しいアプリケーションを提供できる。

本発明のシステムは、情報処理装置とサーバを含むシステムであって、情報処理装置は、接続手段と、受信手段と、インストール手段と、プログラム実行手段とを備える。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、プログラムの情報処理装置へのインストール処理を自動的に行う。プログラム実行手段は、ユーザにより選択されたプログラムを実行する。また、サーバは、情報処理装置による接続が行われたとき、１以上のプログラムの送信処理を行う送信手段を備える。

上記構成により、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに（ユーザ側からの能動的なアクセスを行わなくとも）、新しいアプリケーションやアップデートプログラムを提供できる。また、主にソフトウェア開発者の立場からすると、以下のような利点がある。新規のアプリケーションをインストールするためにユーザ側から能動的なアクセスを要するような環境では、後にアプリケーションに機能追加等が行われたとき、ユーザに機能追加のための作業（能動的なアクセス）を行ってもらえる可能性が低い。そのために、ハードウェアを所持するユーザのうち最も多くのユーザにアプリケーションを提供するためには、開発スケジュールをハードウェアの発売に間に合わせプリインストールさせる必要があった。しかし、本発明によれば、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能となり、ソフトウェア開発者のソフト開発にかかる負担を軽減することが可能となる。

他の構成例として、サーバによって送信され、情報処理装置によって受信、インストール、及び実行がなされるプログラムはコンテンツデータ、および、情報処理装置をコンテンツデータを再生する再生手段として機能させる再生処理プログラムを含んでいてもよい。

上記構成によれば、再生手段が元々インストールされていない形式のコンテンツファイルも再生することができるようになる。よって、様々なコンテンツを自動的に配信することができる。

更に他の構成例として、サーバによって送信され、情報処理装置によって受信、インストール、及び実行がなされるプログラムは、情報処理装置を、ユーザによる当該プログラムのアンインストール指示を受け付けるアンインストール受付手段として機能させ、情報処理装置は、アンインストール受付手段によってプログラムのアンインストール指示が受け付けられたとき、前記プログラムをアンインストールするアンインストール手段を更に備えてもよい。

上記構成によれば、インストールされ実行されるプログラム内において、自己のプログラムのアンインストールを受け付けるので、自動的に（ユーザの意図に沿わず）インストールされ、かつ当該プログラムを試してみたところ興味を持てなかった場合に、簡易にアンインストールを行うことができる。

更に他の構成例として、サーバによって送信され、情報処理装置によって受信、インストール、及び実行がなされるプログラムは、ユーザにより手動で受信されるアプリケーションプログラムの紹介を行うプログラムであり、情報処理装置を、ユーザにより手動で受信されるアプリケーションプログラムの詳細情報にアクセスするための指示を受け付ける詳細情報指示受付手段として機能させ、情報処理装置は、詳細情報指示受付手段によって詳細情報にアクセスするための指示が受け付けられたとき、手動で受信されるアプリケーションプログラムに関する詳細情報を出力する詳細情報出力手段を更に備えてもよい。

上記構成によれば、アプリケーション自体は手動でダウンロードされるべきものであっても、紹介プログラムを自動的にインストールして、ユーザにアプリケーションの存在を知らせることができる。

更に他の構成例によれば、詳細情報出力手段は、詳細情報をサーバから取得して出力してもよい。

更に他の構成例によれば、情報処理装置は、詳細情報が出力されているとき、手動で受信されるアプリケーションプログラムの受信及びインストールを行うための指示をユーザから受け付ける受信指示受付手段と、受信及びインストールを行うための指示を受け付けたとき、手動で受信されるアプリケーションプログラムが登録された所定のサーバに接続し、当該アプリケーションプログラムを受信するとともに、当該受信したアプリケーションプログラムを自動的にインストールする手動受信手段をさらに備えていてもよい。

上記構成によれば、詳細情報から指示をすることでアプリケーションプログラムの受信・インストールが行えるので、紹介アプリを自動的に受信して実際に入手したくなったアプリケーションを容易に入手することができる。

更に他の構成例によれば、サーバによって送信され、情報処理装置によって受信、インストール、及び実行がなされるプログラムは、ユーザにより購入されるアプリケーションプログラム又はコンテンツの紹介を行うプログラムであり、情報処理装置を、プログラム実行手段によって実行されるプログラム内において、ユーザにより購入されるアプリケーションプログラムの購入サイトへアクセスするための指示を受け付けるアクセス指示受付手段として機能させ、情報処理装置は、アクセス指示受付手段によって購入サイトへアクセスするための指示が受け付けられたとき、ユーザにより購入されるアプリケーションプログラムの購入サイトに接続する購入サイト接続手段をさらに備えるようにしてもよい。

上記構成によれば、購入を要するアプリケーションは自動配信に適さないが、その紹介プログラムを自動的にインストールし、それを実行しユーザが気に入れば、購入するためのサイトにアクセスできるので、アプリの宣伝・広告として自動インストールの仕組みを用いて、ユーザに購入アプリの存在を知らせることができる。

本発明の情報処理装置は、接続手段と、受信手段と、インストール手段とを備える。
接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、受信手段によって受信されたプログラムが自機にインストールされていないときは、当該プログラムの新規インストール処理を自動的に行う。

上記構成によれば、サーバで配信される所定のプログラムについて、自動的に新規インストールを行うことができる。

本発明の情報処理方法は、サーバと情報処理装置を含むシステムを用いて、当該情報処理装置の機能を更新する機能更新方法であって、情報処理装置は、そのプロセッサにより、少なくとも省電力状態において、予め定めるスケジュールに従って、自動的かつ繰り返して前記サーバへの接続を試みる。次に、サーバに接続したときに、自機にインストールされていないプログラムをユーザの承諾および操作を求めずに自動的にダウンロードするとともに、当該ダウンロードしたプログラムを自動的にインストールする。更に、非省電力状態において、ユーザに情報処理装置が実行するプログラムを選択させるためのプログラムの一覧を、少なくとも省電力状態においてインストールを行ったプログラムを自動的に含めて表示する。また、自動的にインストールされたプログラムのうちユーザが希望するプログラムをアンインストールする。

上記構成によれば、メーカーが意図した機能更新を、ユーザの何らの操作も必要とせずに、かつユーザの情報処理装置を使用していないときにも、行うことができ、更新された機能をユーザがすぐに使える状態にすることができる。従来、新規の機能を導入するためにはユーザからの能動的なアクセスを要するような環境では、後にユーザに機能追加を行ってもらえる可能性が低いために開発スケジュールをハードウェアの発売に間に合わせる必要があったが、上記構成により、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能になる。更に、上記機能は自動的にダウンロードされインストールされるが、ユーザによってそれをアンインストールすることもできるので、自動的にインストールされるとしても後にユーザによって選別することが可能である。

更に他の構成例として、サーバは、情報処理装置のメーカーが管理するサーバであり、情報処理装置用のプログラムは、情報処理装置のメーカーの管理のもと、当該情報処理装置の発売後に当該情報処理装置用のプログラムを追加可能なようにサーバに登録されるようにしてもよい。

上記構成によれば、メーカーが意図した機能更新を、ユーザの何らの操作も必要とせずに、かつユーザの情報処理装置を使用していないときにも、行うことができ、更新された機能をユーザがすぐに使える状態にすることができる。

更に他の構成例として、情報処理装置は、そのプロセッサにより、さらに、ユーザの所定の操作に応じて、情報処理装置用のプログラムが登録された所定のサーバに接続し、ユーザが希望するプログラムをダウンロードするとともに、当該ダウンロードしたプログラムを自動的にインストールするようにしてもよい。

上記構成例によれば、ユーザが自主的に希望のプログラムをダウンロード及びインストールすることもできる。

本発明の情報処理プログラムは、情報処理装置のコンピュータに実行させる情報処理プログラムであって、コンピュータを、接続手段と受信手段とインストール手段として機能させる。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、プログラムの情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに（ユーザ側からの能動的なアクセスを行わなくとも）、新しいアプリケーションやアップデートプログラムを提供できる。また、主にソフトウェア開発者の立場からすると、以下のような利点がある。新規のアプリケーションをインストールするためにユーザ側から能動的なアクセスを要するような環境では、後にアプリケーションに機能追加等が行われたとき、ユーザに機能追加のための作業（能動的なアクセス）を行ってもらえる可能性が低い。そのために、ハードウェアを所持するユーザのうち最も多くのユーザにアプリケーションを提供するためには、開発スケジュールをハードウェアの発売に間に合わせプリインストールさせる必要があった。しかし、本発明によれば、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能となり、ソフトウェア開発者のソフト開発にかかる負担を軽減することが可能となる。

他の構成例として、受信手段によりサーバから自動的に受信され、インストール手段により自動的にインストールされるプログラムは、コンテンツデータを含み、コンピュータをコンテンツデータを再生する再生手段として機能させるようにしてもよい。

上記構成によれば、再生手段が元々インストールされていない形式のコンテンツファイルも再生することができるようになる。よって、様々なコンテンツを自動的に配信することができる。

更に他の構成例として、受信手段によりサーバから自動的に受信され、インストール手段により自動的にインストールされるプログラムは、コンピュータを、ユーザによる当該プログラムのアンインストール指示を受け付けるアンインストール受付手段としてさらに機能させ、情報処理プログラムは、コンピュータを、アンインストール受付手段によってプログラムのアンインストール指示が受け付けられたとき、当該プログラムをアンインストールするアンインストール手段として更に機能させるようにしてもよい。

上記構成によれば、インストールされ実行されるプログラム内において、自己のプログラムのアンインストールを受け付けるので、自動的に（ユーザの意図に沿わず）インストールされ、かつ当該プログラムを試してみたところ興味を持てなかった場合に、簡易にアンインストールを行うことができる。

更に他の構成例として、受信手段によりサーバから自動的に受信され、インストール手段により自動的にインストールされるプログラムは、コンピュータを、ユーザにより手動で受信されるアプリケーションプログラムの詳細情報にアクセスするための指示を受け付ける詳細情報指示受付手段としてさらに機能させ、情報処理プログラムは、コンピュータを、指示が受け付けられたとき、手動で受信されるアプリケーションプログラムに関する詳細情報を出力する詳細情報出力手段として更に機能させるようにしてもよい。

上記構成によれば、アプリケーション自体は手動でダウンロードされるべきものであっても、紹介プログラムを自動的にインストールして、ユーザにアプリケーションの存在を知らせることができる。

更に他の構成例として、情報処理プログラムは、コンピュータを、詳細情報が出力されているとき、ユーザから、手動で受信されるアプリケーションプログラムの受信及びインストールを行うための指示を受け付ける受信指示受付手段と、受信及びインストールを行うための指示を受け付けたとき、手動で受信されるアプリケーションプログラムが登録された所定のサーバに接続し、当該アプリケーションプログラムを受信するとともに、当該受信したアプリケーションプログラムを自動的にインストールする手動受信手段として更に機能させるようにしてもよい。

上記構成によれば、詳細情報から指示をすることでアプリケーションプログラムの受信・インストールが行えるので、紹介アプリを自動的に受信して実際に入手したくなったアプリケーションを容易に入手することができる。

更に他の構成例として、受信手段によりサーバから自動的に受信され、インストール手段により自動的にインストールされるプログラムは、コンピュータを、プログラム実行手段によって実行されるプログラム内において、ユーザにより購入されるアプリケーションプログラムの購入サイトへアクセスするための指示を受け付けるアクセス指示受付手段としてさらに機能させ、情報処理プログラムは、コンピュータを、指示が受け付けられたとき、ユーザにより購入されるアプリケーションプログラムの購入サイトに接続する購入サイト接続手段として機能させるようにしてもよい。

上記構成によれば、購入を要するアプリケーションは自動配信に適さないが、その紹介プログラムを自動的にインストールし、それを実行しユーザが気に入れば、購入するためのサイトにアクセスできるので、アプリの宣伝・広告として自動インストールの仕組みを用いて、ユーザに購入アプリの存在を知らせることができる。

本発明の情報処理システムは、接続手段と受信手段とインストール手段とを備える。接続手段は、自動的にサーバに接続する。受信手段は、サーバから１以上のプログラムの受信処理を自動的に行う。インストール手段は、プログラムの情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに（ユーザ側からの能動的なアクセスを行わなくとも）、新しいアプリケーションやアップデートプログラムを提供できる。また、主にソフトウェア開発者の立場からすると、以下のような利点がある。新規のアプリケーションをインストールするためにユーザ側から能動的なアクセスを要するような環境では、後にアプリケーションに機能追加等が行われたとき、ユーザに機能追加のための作業（能動的なアクセス）を行ってもらえる可能性が低い。そのために、ハードウェアを所持するユーザのうち最も多くのユーザにアプリケーションを提供するためには、開発スケジュールをハードウェアの発売に間に合わせプリインストールさせる必要があった。しかし、本発明によれば、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能となり、ソフトウェア開発者のソフト開発にかかる負担を軽減することが可能となる。

本発明の情報処理方法は、接続ステップと、受信ステップと、インストールステップとを備える。接続ステップは、自動的にサーバに接続する。受信ステップは、サーバから１以上のプログラムの受信処理を自動的に行う。インストールステップは、プログラムの情報処理装置へのインストール処理を自動的に行う。

上記構成により、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに（ユーザ側からの能動的なアクセスを行わなくとも）、新しいアプリケーションやアップデートプログラムを提供できる。また、主にソフトウェア開発者の立場からすると、以下のような利点がある。新規のアプリケーションをインストールするためにユーザ側から能動的なアクセスを要するような環境では、後にアプリケーションに機能追加等が行われたとき、ユーザに機能追加のための作業（能動的なアクセス）を行ってもらえる可能性が低い。そのために、ハードウェアを所持するユーザのうち最も多くのユーザにアプリケーションを提供するためには、開発スケジュールをハードウェアの発売に間に合わせプリインストールさせる必要があった。しかし、本発明によれば、ハードウェアの発売後にソフトウェアの開発スケジュールを設定することも可能となり、ソフトウェア開発者のソフト開発にかかる負担を軽減することが可能となる。

本発明によれば、自動的にプログラムの受信・インストールを行うので、ユーザの何らの操作も必要とせずに、新しいアプリケーション等を提供できる。

本発明の第１の実施形態に係るゲーム装置１の外観図 本発明の第１の実施形態に係るゲーム装置１のブロック図 本実施形態にかかるネットワーク構成の全体像を示す模式図 メニュー画面の一例 メニュー画面の一例 メニュー画面の一例 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 本実施形態で実行される各種機能（プログラム）の相関関係を示す図 マイコン３７に内蔵されている記憶領域に記憶される主なデータを示す図 無線通信モジュール３４に内蔵されている記憶領域に記憶される主なデータを示す図 ＮＡＮＤフラッシュメモリ３３に記憶されるプログラム、データを示す図 図１４のすれ違い通信用データ５２０のデータ構造の一例を示した図 図１４のタスクデータ５３０のデータ構造の一例を示した図 図１４のアプリ関連データ５５０のデータ構造の一例を示した図 図１４の受信ポリシーデータ５７０のデータ構造の一例を示した図 図１４のインストールリスト５８０のデータ構造の一例を示した図 マイコン３７によって実行されるマイコン処理を示すフローチャート 無線モジュール処理を示すフローチャート 無線モジュール処理を示すフローチャート 起動時処理の詳細を示すフローチャート 起動時処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２６のステップＳ４２４で示したアプリインストール処理の詳細を示すフローチャート 図２６のステップＳ４２４で示したアプリインストール処理の詳細を示すフローチャート 図３０のステップＳ４７１デ示した正当性確認処理の詳細を示すフローチャート 図２６のステップＳ４３２で示したアプリ更新適用処理の詳細を示すフローチャート 図２７のステップＳ１０８で示した各アプリの処理の詳細を示すフローチャート 図２７のステップＳ１０８で示した各アプリの処理の詳細を示すフローチャート 図３３のステップＳ１３１で示したタスク生成処理の詳細を示すフローチャート ローカル通信用ＢＧ処理の詳細を示すフローチャート ローカル通信用ＢＧ処理の詳細を示すフローチャート インターネット通信用ＢＧ処理の詳細を示すフローチャート 図３８のステップＳ１９１で示したポリシー処理の詳細を示すフローチャート 図３８のステップＳ１９１で示したポリシー処理の詳細を示すフローチャート ポリシーサーバ１０３のメモリマップを示す図 ポリシーサーバ１０３で実行される処理を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図４３のステップＳ２５１で示した実行順ソート処理の詳細を示すフローチャート 図４７のステップＳ２７２で示したシステムインストール処理の詳細を示すフローチャート 図４７のステップＳ２７２で示したシステムインストール処理の詳細を示すフローチャート 第２の実施形態に係るボトルメールアプリの処理概要を示す図 第２の実施形態に係るボトルメールアプリの処理概要を示す図 ボトルメールサーバに記憶される履歴情報データのデータ構造の一例を示す図 ボトルメールサーバに記憶されるＡＰ地域テーブルの一例 ゲーム装置１で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート ゲーム装置１で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート ボトルメールサーバの処理の詳細を示すフローチャート 第４の実施形態にかかるインストール処理の詳細を示すフローチャート 第４の実施形態にかかるインストール処理の詳細を示すフローチャート 第５の実施形態にかかる手動ダウンロード処理の詳細を示すフローチャート コンテンツアプリの画面例 コンテンツアプリに含まれるプログラムによる再生処理のフローチャート 削除命令受付処理の詳細を示すフローチャート

以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。

（第１の実施形態）
図１は、本発明にかかる携帯端末の一例である携帯型ゲーム装置（以下、単にゲーム装置）の一例を示した図である。図１において、ゲーム装置１は、折り畳み型の携帯ゲーム装置であり、開いた状態（開状態）のゲーム装置１を示している。ゲーム装置１は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。

ゲーム装置１は、下側ハウジング１１および上側ハウジング２１を有する。下側ハウジング１１と上側ハウジング２１とは、開閉可能（折り畳み可能）に連結されている。図１の例では、下側ハウジング１１および上側ハウジング２１は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回転可能に連結されている。通常、ユーザは、開状態でゲーム装置１を使用する。また、ユーザは、ゲーム装置１を使用しない場合には閉状態としてゲーム装置１を保管する。また、図１に示した例では、ゲーム装置１は、上記閉状態および開状態のみでなく、下側ハウジング１１と上側ハウジング２１とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング２１を下側ハウジング１１に対して任意の角度で静止させることができる。

下側ハウジング１１には、下側ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示装置）１２が設けられる。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング１１の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置１に内蔵されている表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置１は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側ＬＣＤ１２は、主に、内側カメラ２３または外側カメラ２５で撮影されている画像をリアルタイムに表示するために用いられる。

下側ハウジング１１には、入力装置として、各操作ボタン１４Ａ〜１４Ｌおよびタッチパネル１３が設けられる。図１に示されるように、各操作ボタン１４Ａ〜１４Ｌのうち、方向入力ボタン１４Ａ、操作ボタン１４Ｂ、操作ボタン１４Ｃ、操作ボタン１４Ｄ、操作ボタン１４Ｅ、電源ボタン１４Ｆ、ホームボタン１４Ｉ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、上側ハウジング２１と下側ハウジング１１とを折りたたんだときに内側となる、下側ハウジング１１の内側主面上に設けられる。方向入力ボタン１４Ａは、例えば選択操作等に用いられる。各操作ボタン１４Ｂ〜１４Ｅは、例えば決定操作やキャンセル操作等に用いられる。電源ボタン１４Ｆは、ゲーム装置１の電力制御モードを切り替えるために用いられる。詳細は後述するが、本実施形態では、電力制御モードとして「通常電力モード」と「スリープモード」がある。ホームボタン１４Ｉは、ゲームなどのアプリケーションが実行されているときに、メニュー画面に戻るために用いられる。図１に示す例では、方向入力ボタン１４Ａ、電源ボタン１４Ｆおよびホームボタン１４Ｉは、下側ハウジング１１の内側主面中央付近に設けられる下側ＬＣＤ１２に対して、左右一方側（図１では左側）の当該主面上に設けられる。また、操作ボタン１４Ｂ〜１４Ｅ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、下側ＬＣＤ１２に対して左右他方側（図１では右側）となる下側ハウジング１１の内側主面上に設けられる。方向入力ボタン１４Ａ、操作ボタン１４Ｂ〜１４Ｅ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、ゲーム装置１に対する各種操作を行うために用いられる。

なお、図１においては、操作ボタン１４Ｊ〜１４Ｌの図示を省略している。例えば、Ｌボタン１４Ｊは、下側ハウジング１１の上側面の左端部に設けられ、Ｒボタン１４Ｋは、下側ハウジング１１の上側面の右端部に設けられる。Ｌボタン１４ＪおよびＲボタン１４Ｋは、ゲーム装置１に対して、例えば撮影指示操作（シャッター操作）を行うために用いられる。さらに、音量ボタン１４Ｌは、下側ハウジング１１の左側面に設けられる。音量ボタン１４Ｌは、ゲーム装置１が備えるスピーカの音量を調整するために用いられる。

また、ゲーム装置１は、各操作ボタン１４Ａ〜１４Ｌとは別の入力装置として、さらにタッチパネル１３を備えている。タッチパネル１３は、下側ＬＣＤ１２の画面上を覆うように装着されている。なお、本実施形態では、タッチパネル１３は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル１３は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、本実施形態では、タッチパネル１３として、例えば下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル１３の解像度と下側ＬＣＤ１２の解像度とが一致している必要はない。また、下側ハウジング１１の右側面には、挿入口（図１に示す破線）が設けられている。挿入口は、タッチパネル１３に対する操作を行うために用いられるタッチペン２７を収納することができる。なお、タッチパネル１３に対する入力は、通常タッチペン２７を用いて行われるが、タッチペン２７に限らずユーザの指でタッチパネル１３を操作することも可能である。

また、下側ハウジング１１の右側面には、メモリカード２８を収納するための挿入口（図１では、二点鎖線で示している）が設けられている。この挿入口の内側には、ゲーム装置１とメモリカード２８とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード２８は、例えばＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリカードであり、コネクタに着脱自在に装着される。メモリカード２８は、例えば、ゲーム装置１によって撮影された画像を記憶（保存）したり、他の装置で生成された画像をゲーム装置１に読み込んだりするために用いられる。

さらに、下側ハウジング１１の上側面には、カートリッジ２９を収納するための挿入口（図１では、一点鎖線で示している）が設けられている。この挿入口の内側にも、ゲーム装置１とカートリッジ２９とを電気的に接続するためのコネクタ（図示せず）が設けられる。カートリッジ２９はゲームプログラム等を記録した記録媒体であり、下側ハウジング１１に設けられた挿入口に着脱自在に装着される。

下側ハウジング１１と上側ハウジング２１との連結部の左側部分には、３つのＬＥＤ１５Ａ〜１５Ｃが取り付けられる。ここで、ゲーム装置１は、他の機器との間で無線通信を行うことが可能であり、第１ＬＥＤ１５Ａは、ゲーム装置１の電源がオンである場合に点灯する。第２ＬＥＤ１５Ｂは、ゲーム装置１の充電中に点灯する。第３ＬＥＤ１５Ｃは、無線通信が確立している場合に点灯する。したがって、３つのＬＥＤ１５Ａ〜１５Ｃによって、ゲーム装置１の電源のオン／オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。

一方、上側ハウジング２１には、上側ＬＣＤ２２が設けられる。上側ＬＣＤ２２は横長形状であり、長辺方向が上側ハウジング２１の長辺方向に一致するように配置される。なお、下側ＬＣＤ１２と同様、上側ＬＣＤ２２に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、上側ＬＣＤ２２上を覆うように、タッチパネルを設けてもかまわない。例えば、上側ＬＣＤ２２には、ユーザに各操作ボタン１４Ａ〜１４Ｌやタッチパネル１３の役割を教えるための、操作説明画面が表示される。

また、上側ハウジング２１には、２つのカメラ（内側カメラ２３および外側カメラ２５）が設けられる。図１に示されるように、内側カメラ２３は、上側ハウジング２１の連結部付近の内側主面に取り付けられる。一方、外側カメラ２５は、内側カメラ２３が取り付けられる内側主面の反対側の面、すなわち、上側ハウジング２１の外側主面（ゲーム装置１が閉状態となった場合に外側となる面であり、図１に示す上側ハウジング２１の背面）に取り付けられる。なお、図１においては、外側カメラ２５を破線で示している。これによって、内側カメラ２３は、上側ハウジング２１の内側主面が向く方向を撮影することが可能であり、外側カメラ２５は、内側カメラ２３の撮影方向の逆方向、すなわち、上側ハウジング２１の外側主面が向く方向を撮影することが可能である。このように、本実施形態では、２つの内側カメラ２３および外側カメラ２５の撮影方向が互いに逆方向となるように設けられる。例えば、ユーザは、ゲーム装置１からユーザの方を見た景色を内側カメラ２３で撮影することができるとともに、ゲーム装置１からユーザの反対側の方向を見た景色を外側カメラ２５で撮影することができる。

なお、上記連結部付近の内側主面には、音声入力装置としてマイク（図２に示すマイク４４）が収納されている。そして、上記連結部付近の内側主面には、マイク４４がゲーム装置１外部の音を検知できるように、マイクロフォン用孔１６が形成される。マイク４４を収納する位置およびマイクロフォン用孔１６の位置は必ずしも上記連結部である必要はなく、例えば下側ハウジング１１にマイク４４を収納し、マイク４４を収納位置に対応させて下側ハウジング１１にマイクロフォン用孔１６を設けるようにしても良い。

また、上側ハウジング２１の外側主面には、第４ＬＥＤ２６（図１では、破線で示す）が取り付けられる。第４ＬＥＤ２６は、外側カメラ２５によって撮影が行われた（シャッターボタンが押下された）時点で点灯する。また、外側カメラ２５によって動画が撮影される間点灯する。第４ＬＥＤ２６によって、ゲーム装置１による撮影が行われた（行われている）ことを撮影対象者や周囲に通知することができる。

また、上側ハウジング２１の内側主面中央付近に設けられる上側ＬＣＤ２２に対して、左右両側の当該主面に音抜き孔２４がそれぞれ形成される。音抜き孔２４の奥の上側ハウジング２１内にはスピーカが収納されている。音抜き孔２４は、スピーカからの音をゲーム装置１の外部に放出するための孔である。

以上に説明したように、上側ハウジング２１には、画像を撮影するための構成である内側カメラ２３および外側カメラ２５と、例えば撮影の際に操作説明画面を表示する表示手段である上側ＬＣＤ２２とが設けられる。一方、下側ハウジング１１には、ゲーム装置１に対する操作入力を行うための入力装置（タッチパネル１３および各ボタン１４Ａ〜１４Ｌ）と、ゲーム画面を表示するための表示手段である下側ＬＣＤ１２とが設けられる。したがって、ゲーム装置１を使用する際には、ユーザは、下側ＬＣＤ１２に表示される撮影画像（カメラによって撮影された画像）を見ながら、下側ハウジング１１を把持して入力装置に対する入力を行うことができる。

次に、図２を参照して、ゲーム装置１の内部構成を説明する。なお、図２は、ゲーム装置１の内部構成の一例を示すブロック図である。

図２において、ゲーム装置１は、ＣＰＵパッケージ３１、メインメモリ３２、ＮＡＮＤフラッシュメモリ３３、無線通信モジュール３４、第１メモリカードインターフェース（メモリカードＩ／Ｆ）３５および第２メモリカードＩ／Ｆ３６、マイコン３７、開閉検出器４０、電源管理ＩＣ４１、電源回路４２、およびインターフェース回路（Ｉ／Ｆ回路）４３等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング１１（または上側ハウジング２１でもよい）内に収納される。

ＣＰＵパッケージ３１には、所定のプログラムを実行するための情報処理手段であるＣＰＵが設けられている。本実施形態において、当該ＣＰＵは、その内部に２つのコアを有しており（いわゆるデュアルコアプロセッサ）、一方には主にシステム制御関連の処理を担当させ、もう一方には、主にアプリケーションの実行関連の処理を担当させている。そのほか、ＣＰＵパッケージ３１には、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）が設けられている。その他、内部メインメモリ等も設けられている。図示は省略するが、これらの構成要素は、ＣＰＵパッケージ３１内の内部バスによって互いに接続される（つまり、ワンチップ化されている）。ただし、これらがワンチップ化されていなくてもよいし、ＣＰＵのコア数も２つに限らない。

ＧＰＵは、描画手段の一部を形成し、ＣＰＵからのグラフィクスコマンド（作画命令）に従って画像を生成する。ＶＲＡＭは、ＧＰＵがグラフィクスコマンドを実行するために必要なデータ（ポリゴンデータやテクスチャデータ等のデータ）を記憶する。画像が生成される際には、ＧＰＵは、ＶＲＡＭに記憶されたデータを用いて画像データを作成する。

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

なお、以下の説明においては、ＣＰＵパッケージ３１を単にＣＰＵ３１と記載する。

ここで、ＣＰＵ３１によって実行されるプログラムは、ゲーム装置１内のＮＡＮＤフラッシュメモリ３３に予め記憶されていてもよいし、メモリカード２８および／またはカートリッジ２９から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。

ＣＰＵ３１には、メインメモリ３２、ＮＡＮＤフラッシュメモリ３３、無線通信モジュール３４が接続されている。メインメモリ３２は、ＣＰＵ３１のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ３２として、例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。

ＮＡＮＤフラッシュメモリ３３は、不揮発性の記憶媒体によって構成される。また、ＣＰＵ３１の指示に従って、図示しないメモリ制御回路が、ＮＡＮＤフラッシュメモリ３３に対するデータの読み出しおよび書き込みを制御する。

無線通信モジュール３４は、例えばＩＥＥＥ８０２．１１．ｂ／ｇ／ｎの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する（後述する「インターネット通信」の際はこの方式が用いられる）。また、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する（後述する「ローカル通信」の際はこの方式が用いられる）。無線通信モジュール３４は、ＣＰＵ３１に接続される。ＣＰＵ３１は、無線通信モジュール３４を用いてインターネットを介して他の機器との間でデータを送受信したり、同種の他のゲーム装置との間でデータを送受信したりすることができる。また、無線通信モジュール３４には、図示はしないがマイコンチップが搭載されており、後述のスリープモード中に所定の処理を実行する。

また、第１メモリカードＩ／Ｆ３５はＣＰＵ３１に接続される。第１メモリカードＩ／Ｆ３５は、コネクタに装着されたカートリッジ２９に対するデータの読み出しおよび書き込みをＣＰＵ３１の指示に従って行う。例えば、ゲーム装置１が実行することが可能なアプリケーションプログラムがカートリッジ２９から読み出されてＣＰＵ３１によって実行されたり、当該アプリケーションプログラムに関するデータ（例えばゲームのセーブデータ等）がカートリッジ２９に書き込まれたりする。

第２メモリカードＩ／Ｆ３６は、ＣＰＵ３１に接続される。第２メモリカードＩ／Ｆ３６は、コネクタに装着されたメモリカード２８に対するデータの読み出しおよび書き込みを、ＣＰＵ３１の指示に応じて行う。例えば、外側カメラ２５によって撮像された画像データがメモリカード２８に書き込まれたり、メモリカード２８に記憶された画像データがメモリカード２８から読み出されてＮＡＮＤフラッシュメモリ３３に記憶されたりする。

また、ＣＰＵ３１には、マイコン３７が接続される。マイコン３７は、ゲーム装置１の電源管理に関する処理や、時間に関する処理、上記ハウジングの開閉検知処理等を行う。また、これらの処理に関する通知をＣＰＵ３１から受けたり、逆にＣＰＵ３１に通知したりする。マイコン３７は、リアルタイムクロック（ＲＴＣ）３９を備えている。ＲＴＣ３９は、時間をカウントし、マイコン３７を介してＣＰＵ３１に出力する。例えば、ＣＰＵ３１は、ＲＴＣ３９によって計時された時間に基づいて、現在時刻（日付）等を計算することもできる。

また、マイコン３７は、開閉検出器４０および電源管理ＩＣ４１と接続される。電源管理ＩＣ４１は、更に、電源回路４２と接続される。開閉検出器４０は、上記ハウジングの開閉を検出し、その内容をマイコン３７（ひいてはＣＰＵ３１）に通知する。電源管理ＩＣ４１は、マイコン３７（マイコン３７を介したＣＰＵ３１）からのスリープモードへの移行やスリープモード解除の通知を受ける。そして、当該通知に基づいて適切な電力を供給するための制御を行う。電源回路４２は、ゲーム装置１が有する電源（典型的には電池であり、下側ハウジング１１に収納される）から供給される電力を制御し、上記電源管理ＩＣ４１を介してゲーム装置１の各部品に電力を供給する。

ここで、本実施形態にかかるゲーム装置１の電源制御のモードに関して説明する。本ゲーム装置では、電池等の電源が装着されて、上記各構成部品への電力供給が可能な状態となった後は、基本的には、「通常電力モード」と「省電力モード」の２つの電源制御モードのいずれかで動作する。「通常電力モード」は、上記構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーションを実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。本実施形態では、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、上記マイコン３７、無線通信モジュール３４にのみ電源を供給し、それ以外の部品、つまり、ＣＰＵ３１やＬＣＤへの電力供給は停止している状態である（但し、ＣＰＵ３１は、「スリープモード」の解除指示を受けることは可能である）。また、「スリープモード」において、マイコン３７や無線通信モジュール３４は、「マイコン処理」、「無線モジュール処理」と呼ばれる処理を所定時間毎に繰り返し実行するが、これについては詳細は後述する。

そして、本実施形態では、上述のような、開閉検出器４０の検出結果に基づいてスリープモードへの移行やスリープモードの解除を行う方法のほかに、電源ボタン１４Ｆの操作に応じて上記「通常電力モード」と「スリープモード」を切り替えることが可能である。また、電源ボタン１４Ｆの操作によるものの他、後述するような処理によって、自動的に「スリープモード」の解除、あるいは「スリープモード」への移行も可能となっている。例えば、ユーザが所定のゲームをプレイし終えた後、電源ボタン１４Ｆを押すと（この操作は、ユーザから見ると、電源をオフにする操作に見える）、「スリープモード」に移行する。この状態で、ユーザはゲーム装置１を閉じて、持ち歩くこと等が可能である。その後、ユーザがゲーム装置１を開き、再度電源ボタン１４Ｆを押すと、「スリープモード」が解除され、「通常電力モード」に移行する。または、所定時間が経過したことにより「スリープモード」へ移行するようにしてもよい。

なお、上記「スリープモード」の他、「省電力モード」の一つとして、各ＬＣＤへの電力供給のみを停止する「モニタオフモード」での動作も可能である。このときは、ＣＰＵ３１やメインメモリ３２への電力供給は行われる（なお、ＣＰＵ３１内のＣＰＵコアと内部メモリのみに電力を供給し、上記ＧＰＵには電力は供給しないようにしてもよい）。その他、電源ボタン１４Ｆを長押しすることで、マイコン３７や無線モジュールも含めた全ての構成部品への電力供給を停止する（つまり、完全に電源を切る）「完全停止モード」に移行することも可能である。この場合は、再度電源ボタン１４Ｆを長押しすると、「通常電力モード」に移行してゲーム装置１が起動することになる。

ここで、上記電源制御モードに関し、ユーザがゲーム装置を使用中か否かという観点からは、以下のように言い換えることもできる。すなわち、ゲーム装置１は、「使用状態」と「非使用状態」という２つの状態を有するといえる。「使用状態」とは、ユーザがゲーム装置１のハウジングを開いて直接的に使用しているために、通常電力モードがずっと継続している状態である。例えば、ユーザが操作ボタン１４等を操作して実際にゲーム等をプレイしている状態が該当する。一方、「非使用状態」とは、ユーザがゲーム装置１を主導的・直接的に使用していない状態をいう。これには、上記ハウジングが閉じられているために「スリープモード」となっている状態の他、後述するようなタスクの実行に伴い、（ハウジングは閉じられたまま）一時的に「スリープモード」が解除されてタスクにかかる処理が実行され、当該タスクの実行後は再度「スリープモード」に戻るような状態も含む。例えば、ユーザが外出する際に、ゲーム装置１のハウジングを閉じて鞄に入れている状態は「非使用状態」である。更に、このように、ゲーム装置１が鞄に入れられてユーザが外出している間に、上記のように一時的に「スリープモード」が解除されている状態、および、タスクの実行後に再度「スリープモード」に入るような状態（この間、ユーザはゲーム装置１を使用していない）も「非使用状態」である。また、当該「使用状態」と「非使用状態」が切り替わるためのトリガは、ハウジングの開閉の他、電源ボタン１４Ｆが操作された場合もトリガとなる。つまり、ユーザがゲームをプレイしていたが（使用状態）、その後、ゲームのプレイを終えたため、ゲーム装置１の電源ボタン１４Ｆを押下することで、「使用状態」から「非使用状態」に切り替わる。その他、例えば、一定時間ユーザの操作がなかったために「使用状態」から「非使用状態」に切り替わる場合もある。

以下の説明においては、説明の簡略化のため、電源制御モードについては、「通常電力モード」と「スリープモード」の２つのモードだけを用いる場合を例として説明する。

また、ゲーム装置１は、マイク４４およびアンプ４５を備えている。マイク４４およびアンプ４５は、それぞれＩ／Ｆ回路４３に接続される。マイク４４は、ゲーム装置１に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をＩ／Ｆ回路４３に出力する。アンプ４５は、Ｉ／Ｆ回路４３から音声信号を増幅してスピーカ（図示せず）から出力させる。Ｉ／Ｆ回路４３は、ＣＰＵ３１に接続される。

また、タッチパネル１３は、Ｉ／Ｆ回路４３に接続される。すなわち、Ｉ／Ｆ回路４３は、マイク４４およびアンプ４５（スピーカ）の制御を行う音声制御回路と、タッチパネル１３の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル１３からの信号に基づいて所定の形式のタッチ位置データを生成してＣＰＵ３１に出力する。例えば、タッチ位置データは、タッチパネル１３の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル１３からの信号の読み込み、および、タッチ位置データの生成を所定時間に１回の割合で行う。ＣＰＵ３１は、Ｉ／Ｆ回路４３を介して、タッチ位置データを取得することにより、タッチパネル１３に対して入力が行われた位置を知ることができる。

操作ボタン１４は、上記各操作ボタン１４Ａ〜１４Ｌから構成され、ＣＰＵ３１に接続される。操作ボタン１４からＣＰＵ３１へは、各操作ボタン１４Ａ〜１４Ｌに対する入力状況（押下されたか否か）を示す操作データが出力される。ＣＰＵ３１は、操作ボタン１４から操作データを取得することによって、操作ボタン１４に対する入力に応じた処理を実行する。

内側カメラ２３および外側カメラ２５は、それぞれＣＰＵ３１に接続される。内側カメラ２３および外側カメラ２５は、ＣＰＵ３１の指示に応じて画像を撮影し、撮影した画像データをＣＰＵ３１に出力する。本実施形態では、ＣＰＵ３１は、内側カメラ２３および外側カメラ２５のいずれか一方に対して撮影指示を行い、撮影指示を受けたカメラが画像を撮影して画像データをＣＰＵ３１に送る。

また、下側ＬＣＤ１２および上側ＬＣＤ２２は、それぞれＣＰＵ３１に接続される。下側ＬＣＤ１２および上側ＬＣＤ２２は、それぞれＣＰＵ３１の指示に従って画像を表示する。

次に、本実施形態で想定する処理の概要について説明する。
［ネットワークの全体構成］
まず、本実施形態で想定するネットワークの全体的な構成について説明する。図３は、本実施形態にかかるネットワーク構成の全体像を示す模式図である。図３で示されるゲーム装置１は、大きく分けて２種類の通信態様を用いる。１つめの通信態様は、インターネットを利用する態様である「インターネット通信」である。２つめの通信態様は、インターネットは経由せず直接的にゲーム装置同士を無線接続する「ローカル通信」である。

［インターネット通信］
まず、「インターネット通信」に関して説明する。「インターネット通信」では、上述したＩＥＥＥ８０２．１１準拠の方式でアクセスポイント（以下、ＡＰと呼ぶ）に接続し、これを介してインターネットに接続する。更に、インターネットを経由して、所定のサーバと通信を行う。

本実施形態においては、上記ＡＰは大きく２つの種類に分けられており、図３でいうと、専用ＡＰ１０１と一般ＡＰ１０２の２種類に分けられる。本実施形態において、専用ＡＰ１０１とは、例えば、ゲーム装置１の製造元が管理するＡＰをいう。つまり、ゲーム装置１の製造元は、どの専用ＡＰがどの場所に設置されているかや、各専用ＡＰの機器構成等を把握、管理している。このような専用ＡＰは、例えば、家電量販店やファーストフード店等、特定の場所に設置される。対して、一般ＡＰ１０２は、本実施形態では、上記専用ＡＰ以外のＡＰ全般を示す。例えば、ユーザの個人宅に設置されたＡＰや、上記ゲーム装置１の製造元以外の事業者等が設置したＡＰ等が該当する。

それぞれのＡＰには、いわゆるＥＳＳＩＤや自らが電波を発する周波数チャネルが予め設定され、各ＡＰが備えている記憶媒体（例えばフラッシュメモリ等）に記憶されている。また、専用ＡＰ１０１については、後述するベンダー特定情報が更に記憶されており、この内容がビーコンに含まれて発信される。

また、サーバの種類についても、本実施形態では２つに大別されており、図３では、ポリシーサーバ１０３と、その他一般サーバ１０４の２種類に分けられている。ポリシーサーバ１０３とは、「ポリシーデータ」と呼ばれるデータを取得するための専用サーバである。本実施形態において、ゲーム装置１は、当該ポリシーサーバ１０３から「ポリシーデータ」と呼ばれるデータを取得し、これに基づく処理を行うが、これら処理については詳細を後述する。一般サーバ１０４は、上記ポリシーサーバ１０３以外のサーバのことである。なお、各サーバはそれぞれ、ＣＰＵ等の演算処理部、メモリやＨＤＤ等の記憶部、インターネットに接続するための通信部等を有している（図示は省略する）。

なお、本実施形態で上記のような専用ＡＰを設けているのは、上記「ポリシーデータ」については、専用ＡＰに応じた「ポリシーデータ」を定義可能とするためである。つまり、特定のＡＰを経由してポリシーサーバにアクセスした場合に、接続に利用しているＡＰ（ひいてはそのＡＰが設置されている場所等）に応じた「ポリシーデータ」を利用可能とするためである。

［ローカル通信］
次に、もう一つの通信態様である「ローカル通信」に関して説明する。「ローカル通信」は、ゲーム装置１同士の間で直接接続を確立して通信を行う通信態様である。図３の例では、ゲーム装置１と、他のゲーム装置１との間の通信が「ローカル通信」に該当する。

上記のようなネットワーク構成と通信態様で、本実施形態では、主に以下のような処理が実行される。まず、「インターネット通信」を用いる処理として、タスクを実行する処理がある。本実施形態におけるタスクは、所定のデータの送受信を伴う処理を示す。より具体的には、「送信タスク」と「受信タスク」の２種類に分類される。但し、以下では、これらを総称して単に、タスク、と称することもある。このように、本実施形態で言うタスクは、データの送信または受信を伴う処理であるため、当該タスクの内容を示すデータには、接続先となるサーバのＵＲＬ等が含まれる。以下に、本実施形態における当該タスクの例をいくつか挙げる。まず、キャンペーン等のお知らせをネットワークサービスの提供者からユーザに通知することを目的とした「お知らせデータを受信する」というタスクがある。また、この「お知らせデータ」には、所定のネットワークサービスの終了を通知する旨を含めることも可能である。このような場合は、当該サービスの終了にかかるネットワークアプリに関するタスクは消去される。また、ゲームに関連する処理として、例えば、レースゲームの全国大会が、ある期間に行われる場合を想定する。この期間において、ユーザのレースデータを全国ランキングに定期的にエントリーすることを目的として、「レースデータの送信」や「現在のランキングデータの受信」というタスクがある（このような場合は、「送信タスク」と「受信タスク」の２つのタスクが実行される）。

また、「追加コンテンツの確認」というタスクもある。これは、例えばＲＰＧの追加シナリオ等が配信された場合を想定するタスクであり、このような「追加コンテンツの有無を示す情報の受信」というタスクがある。その結果、追加コンテンツがあれば、そのデータがダウンロードされる。

また、その他のタスクとして、本実施形態では「インストールリストの取得」というタスクがある。当該タスクは、ゲーム装置１の出荷時設定として予め設定済みのタスクである。ここで、「インストールリスト」、および、本実施形態でいう「インストール」について説明する、まず、本実施形態では、ゲーム装置１で実行されるプログラムは、システムプログラムと、アプリプログラムの２種類に大別される。システムプログラムは、ゲーム装置１のシステムを構成するプログラムを指す（これは、モジュールと呼ばれることもある）。以下の説明では、このシステムプログラムのことを「システムの構成要素」と表現することもある。一方、アプリプログラムは、上記システムプログラムの範疇に含まれない各種プログラムであり、例えば、各種のゲームプログラムの他、お絵かきアプリケーションやカメラアプリケーション、オンラインショッピングアプリケーション等のゲーム以外の各種アプリケーションプログラム（有料か無料かを問わない）が挙げられる、また、これらゲームやアプリケーションの体験版等もこれに含まれる。以下の説明では、これらを総称して、単に「アプリケーション」あるいは「アプリ」と呼ぶ。また、本実施形態では、上記「プログラム」については、例えば"exe"ファイルのような、直接的に実行可能なファイルのみならず、展開することによってプログラムファイルを含んだファイル群を生成することができる、いわゆるアーカイブファイルも含むものとする（例えば、いわゆる"zip"ファイル）。そのため、以下の説明において、例えば、「アプリをダウンロードする」というような記載をした場合は、上記直接的に実行可能なアプリプログラム（例えばexeファイル）をダウンロードする場合だけではなく、展開することで当該アプリを構成する一群のファイルが生成可能なアーカイブファイルをダウンロードすることも含まれる。

次に、上記「インストールリスト」とは、インストールすることが可能なアプリの存在を示す情報（配布中のアプリケーション一覧のようなもの）や、システムの更新情報等が含まれた情報である。本実施形態では、当該インストールリストを所定のサーバから定期的に取得することで、これらインストール可能なアプリやシステムの更新データの存在の有無の確認が可能となっている。更に、このような確認のみならず、これら更新データやアプリのダウンロードおよびインストール処理も実行される。

次に、本実施形態における「インストール」について説明する。本実施形態において、「インストール」とは、上記システムプログラムやアプリプログラムをＮＡＮＤフラッシュメモリ３３等の記憶媒体上に格納し、更に、各システムプログラムやアプリプログラムとシステムとの関連付けまで行って実行可能な状態にすることを言う。このシステムとの関連付けとは、いわゆるメタデータの設定やレジストリの設定やドライバの設定、特に上記インストールされるプログラムに対応する権利情報（後述）の正当性チェック処理や当該権利情報の登録処理等の処理をいう。例えば、ゲーム装置１にインストールされていない新規のゲームを例にすると、このような新規のゲームのプログラムを取得して記憶媒体上に格納するだけではなく、ユーザによる各種指示の必要ないわゆる対話形式のインストーラを用いずに当該新規に取得されたゲームをユーザがすぐに実行可能な状態にまで各種設定を済ませておくことを意味する（つまり、ユーザにインストール処理にかかる操作を行わせず、また、ユーザの承諾も求めない）。このようなインストールの処理の詳細については後述する。

このように、本実施形態におけるタスクは、所定のサーバに接続して所定のデータを送受信する処理であり、このようなタスクが適宜生成されて実行されるが、その実行タイミングに関しては、大きく分けると以下の３種類のタイミングがある。
（１）時間指定実行
（２）即時実行
（３）上記専用ＡＰが関連するときの実行
これら３種類のタイミングで行われる処理については後述する。

次に、「ローカル通信」を用いた処理について説明する。上記のように、「ローカル通信」はゲーム装置１同士を無線接続して通信を行うものである。そのため、通信対戦型のゲーム等、様々な局面で利用されるが、本実施形態では、特に、後述する「すれ違い通信」と呼ばれる通信処理を前提として説明する。

次に、上述した「インターネット通信」で実行されるタスクの３種類の実行タイミングおよびその処理概要について説明するが、この説明に先立って、上記タスクに関して設定される「実行優先度」というパラメータ、および、「消尽回数」というパラメータについて説明する。実行優先度は、そのタスクが実行される優先度を示すものであり、同タイミングに実行されるべき複数のタスクが存在する場合に、これらの実行順序を決定するために用いられる。本実施形態においては、実行優先度は５段階に分けて定義されている。具体的には、優先度の高いものから、”EXPEDITE”＞”HIGH”＞”MEDIUM”＞”LOW”＞”STOPPED”という順番であるとする。このうち、”EXPEDITE”は最も実行優先度が高いことを表す。また、"STOPPED"は、そのタスクを実行しないことを示す。つまり、タスク自体は存在するが、実行させたくないような場合に”STOPPED”という実行優先度が用いられる。”HIGH”は、高優先度、”MEDIUM”は標準の優先度、”LOW”は低優先度であることを示す。本実施形態では、基本的には、”HIGH”、”MEDIUM”、”LOW”の３つを用いてタスクの実行優先度が設定される。残りの２つ”EXPEDITE”および”STOPPED”については、特殊な事情がある場合に利用される。例えば、ゲーム装置１のシステムアップデートを緊急で行いたいような場合は、システムアップデートに関するタスクを”EXPEDITE”として設定する。また、例えば、上述したようなレースゲームの全国大会が年に１回開催されると想定する。この場合に、全国大会の開催期間中は、ユーザのレースデータの送信やランキングデータの受信を行うタスクについて、上記”HIGH”、”MEDIUM”、”LOW”の３つの実行優先度を用いて適宜設定する。一方、全国大会の期間が終了すれば、当該タスクについては”STOPPED”を設定することで、当該タスクの実行が停止される。その後、１年後に再び全国大会が始まれば、当該タスクの実行優先度を”HIGH”、”MEDIUM”、”LOW”を用いて適宜設定することで、当該全国大会の期間中だけ当該タスクを実行させることが可能である。

次に、消尽回数について説明する。上記タスクが生成される際に消尽回数として所定の数値が初期値として設定される。当該消尽回数は、タスクが実行される毎に例えば１ずつ減算されていく。また、当該タスクに対応するゲーム等が起動される度に、消尽回数は初期値にリセットされる。そして、消尽回数が０になったタスクは（換言すれば、このようなタスクに対応するゲーム等が長期間実行されていないことを示すことになる）、上記実行優先度に関わらず実行されない（タスク自体は消去されずに存在する）。

このように、本実施形態では、実行優先度や消尽回数というタスクの実行制御用のパラメータを用いてタスクの実行制御が可能である。また、これらの実行制御用パラメータは、後述するポリシーデータによって変更可能となっている。

以下、上記の実行優先度と消尽回数を踏まえて、「インターネット通信」で実行されるタスクの３種類の実行タイミングおよびその処理概要について説明する。

［時間指定実行］
まず、時間指定実行は、上記タスクを生成するときに、その実行時刻を指定して生成する。そして、指定された時刻が到来したら、そのタスクが実行されるというものである。この時間指定実行は、「スリープモード」中であっても実行される。また、タスクの内容によっては、後述するようなインストール処理も実行されるものもある。そのため、本実施形態では、以下のような運用が可能となる。

例えば、ゲーム装置１が通常電力モードのときにおいて、ユーザの操作等に応じて「新作無料ゲームの有無を確認する」という内容のタスクが生成されたとする（上記のように、確認先のサーバのＵＲＬ情報もタスクのデータに含まれている）。このとき、当該タスクの実行予定時刻を１５：００と指定して生成したとする。その後、ユーザがゲーム装置１の電源ボタン１４Ｆを押して「スリープモード」に移行させ、当該ゲーム装置１を持って、例えば１２：００頃に外出したとする。このとき、「スリープモード」に入る直前のゲーム装置１には、図４に示すようなメニュー画面が表示されていたものとする。

その後、１５：００になると、ゲーム装置１は、上記タスクの実行を試みる。すなわち、１５：００になると、まず、ＣＰＵ３１およびメインメモリ３２への電力供給を一旦再開する。そして、インターネットに接続するために、接続可能なＡＰをサーチを開始する。ここでは、予め設定画面などでＥＳＳＩＤ等を登録した一般ＡＰ１０２のサーチを行う。そして、接続可能なＡＰがあれば、当該ＡＰを経由して、上記ポリシーサーバ１０３に接続する。そして、「ポリシーデータ」をポリシーサーバから取得する。詳細は後述するが、当該ポリシーデータには、上記タスクの実行優先度を定義した情報、すなわち、タスクの実行制御のためのパラメータが含まれる。なお、一般ＡＰのそれぞれについて異なるポリシーデータを定義することは困難であるが、一般ＡＰに共通するポリシーデータを取得させることや、本体に設定されている国情報などによって異なるポリシーデータを取得させることもできる。その後、上記タスクに含まれるＵＲＬ情報に従って、サーバに接続し、新作の無料ゲームの有無を示すデータを取得する。次に、当該データに基づいて新作の無料ゲームの有無を判定し、当該無料ゲームがあるときは、更に、当該無料ゲームのプログラムがアップされている所定のサーバへ接続する。そして、当該無料ゲームのデータを取得し、ゲーム装置１にインストールする。その後、ＣＰＵ３１への電力供給を停止する。その結果、例えば、１８：００に自宅に帰ってきたユーザが当該ゲーム装置１の電源を入れる（スリープモードから通常電力モードへ移行させる）と、図５に示すように、新たにインストールされたアプリケーションがあることを示すプレゼントアイコン１１２が追加されているメニューが表示される。そして、ユーザが当該プレゼントアイコン１１２を選択して所定のボタンを押下すれば、プレゼント箱が開くアニメーション効果が表示された後、今回インストールされた新作の無料ゲームを示すアイコンが当該プレゼントアイコン１１２と置き換わって表示される。

また、その他、本実施形態では次のような運用も可能である。例えば、インストール済みのゲームに関して、「追加コンテンツの有無を確認する」という旨のタスクが生成されたとする。その実行予定時刻は上記同様１５：００であるとする、そして、上述したのと同様に、ユーザがゲーム装置１をスリープモードにして１２：００頃に外出し、その後、１５：００頃にこのタスクが実行されて、あるゲーム、ここでは、図４のアイコン１１１にかかるゲームの追加コンテンツ（例えば、ＲＰＧにおける追加シナリオ）がダウンロードされたとする。このような場合は、１８：００に自宅に帰ってきたユーザが当該ゲーム装置１をスリープモードから通常電力モードへ移行させると、図６に示すように、追加コンテンツの存在を示す「Ｎｅｗ！」のマークがアイコン１１１の近傍に表示される。これにより、アイコン１１１の表すゲームについて、何らかの新しいコンテンツが届いたことをユーザに知らせている。

上記のような処理によって、ユーザが外出する前と外出から帰って来た後で、ゲーム装置１のメニューの構成を異なったものとすることが可能となる。

もちろん、「通常電力モード」のときにおいても時間指定実行は可能である。例えば、上記ユーザが外出せずに、１５：００頃は自宅でゲームをプレイしていたとしても、当該ゲームの処理と並行して（つまり、バックグラウンド処理として）上記のような無料ゲームの取得およびインストールを行っても良い。この場合は、ユーザがゲームのプレイを終えた後、メニュー画面に遷移が行われたときに、メニュー構成が変わっていること、つまり、知らない間にプレゼントアイコン１１２（つまり、何らかの新しいソフトウェア要素）がメニューに加わっていることに気付くことになる。

なお、結果的に同時刻に複数のタスクが実行されるような状況になった場合は、上記実行優先度に基づき、各タスクの実行順序が適宜決定される。

［即時実行］
次に、上記タスクの即時実行に関して説明する。即時実行は、ユーザの指示等に応じて即時にタスクが実行されるというものである。例えば、ユーザが手動で所定のタスクの実行を指示する操作を行うような場合である。

［専用ＡＰが関連するときのタスク実行］
次に、専用ＡＰが関連するときのタスク実行に関して説明する。上記のように、「スリープモード」においても、無線通信モジュール３４には電力は供給されているため、電源が完全に切断されない限りは、基本的に無線通信モジュールは常時稼働している。そのため、本実施形態では、無線通信モジュール３４は、「通常電力モード」においても「スリープモード」においても、ビーコンのスキャン（いわゆるパッシブスキャン）を繰り返し行っている。ここで、上記専用ＡＰ１０１から発信されるビーコンには、そのＡＰが上記ゲーム装置１のメーカーが管理するものであることを示す情報が含まれている。例えば、ＩＥＥＥ８０２．１１規格において定義される、上記ビーコンの情報要素の一つである"Vendor Specific"に、このような情報（以下、ベンダー特定情報と呼ぶ）が含まれる。そこで、本実施形態では、上記ビーコンの当該ベンダー特定情報を用いて、そのビーコンが上記専用ＡＰから発信されたものであるか否かを判別する。つまり、（ゲーム装置１を所持した）ユーザが上記専用ＡＰ１０１の近くに来ているか否かを判定する。その結果、専用ＡＰ１０１からのビーコンであることが判別されたときは、当該専用ＡＰ１０１との接続を確立し、更に、インターネットを経由して上記ポリシーサーバ１０３に接続する。そして、「ポリシーデータ」をポリシーサーバから取得する。詳細は後述するが、当該ポリシーデータには、上記タスクの実行優先度を定義した情報が含まれる。また、上述したように、本実施形態では、専用ＡＰ毎に異なるポリシーデータを定義することを可能としている。例えば、店舗Ａに設置されている専用ＡＰ１０１からポリシーサーバ１０３に接続した場合は「ポリシーデータＡ」が取得され、例えば、店舗Ｂに設置されている専用ＡＰ１０１からポリシーサーバ１０３に接続した場合は「ポリシーデータＢ」が取得される。このとき、「ポリシーデータＡ」では、タスクの実行優先度が、例えば、「タスクＡ＞タスクＢ」というような順となるように実行優先度に設定されており、「ポリシーデータＢ」では、「タスクＢ＞タスクＡ」という実行優先度になるよう設定されているとする。その結果、ユーザが店舗Ａにいるときと店舗Ｂにいるときとで、優先的に実行されるタスクが異なることになる。その結果、各店舗（正確には、各店舗に設置されている専用ＡＰ１０１）に応じたタスクの実行制御を行うことが可能となっている。さらに、専用ＡＰ１０１と本体に設定されている国情報などの情報の双方に基づいて異なるポリシーデータを取得させることもできる。

また、本実施形態では、上記ポリシーデータには、消尽回数を変更するための情報も含まれることがある。このような情報が含まれている場合、例えば、消尽回数が０になったタスクに対して消尽回数が１に設定される。その結果、１度だけ当該タスクを実行させることも可能となる。

このように、本実施形態では、ゲーム装置１を所持したユーザが専用ＡＰ１０１の近くに来れば、ゲーム装置１は上記ポリシーサーバ１０３からポリシーデータを取得する。そして、ポリシーサーバ１０３との接続に用いた専用ＡＰ１０１に応じて、当該ゲーム装置で実行されるタスクの実行優先度が変更可能である。これにより、上述のように、店舗に応じて優先的に実行されるタスク（ひいては、タスクの実行順序）に変化を与えることができる。また、その他、例えば、専用ＡＰ１０１が設置されている店舗Ａにユーザが立ち寄ったときに、当該店舗Ａに特有のデータ（例えば、その店舗の専用ＡＰ１０１経由でしか入手できないゲーム中のアイテム等）をダウンロードさせるようなタスクが最優先で実行されるようにすることが可能となる。また、消尽回数についても変更可能であるため、例えば、消尽回数が０になり、長期間実行されていないタスクが、ある店舗を訪れた際に復活して実行されるということが可能になる。そして、当該タスクの実行結果として何らかの通知を画面に表示することで、ユーザに驚きを与えたり、積極的に情報収集を行わないユーザに対して「気づき」を与えることが可能となる。その結果、例えば、長期間プレイされていなかったゲームを再度プレイしてもらうことへの動機付けをユーザに提供することが可能となる。

上記のように、ゲーム装置１が「スリープモード」のときにも、上記のような「インターネット通信」およびタスクの実行（サーバとの間でデータの送受信）を行うことで、本実施形態では、本来は常時接続型の端末ではないゲーム装置１であるにもかかわらず、あたかも常時接続であるかのような振る舞いをユーザに見せることができる。その結果、ユーザは、主導的・積極的にネットワークへの接続操作等を行わずとも、各種通知や無料アプリなどの入手が可能となり、また、知らないうちにゲーム装置１のソフト構成が変化していることにより驚きと楽しみをユーザに提供する事が可能となる。

次に、上記「ローカル通信」を利用した「すれ違い通信」の処理概要について説明する。図７〜図１０は、当該「すれ違い通信」について説明するための図である。まず、本実施形態では、ＮＡＮＤフラッシュメモリ３３内に「すれ違い通信」用のデータ領域が確保されている。図７は、このすれ違い通信用のデータ領域を示す模式図である。図７において、当該領域は複数の「スロット」の集合で構成されている。各スロットは、所定のアプリケーションまたはゲームと対応づけられている。この対応付けは、ユーザが所定の操作を行うことで、ユーザが任意で対応付け可能となっている。各スロットは、対応付けられているアプリまたはゲームを示すＩＤと送信用ボックス、受信用ボックスで構成されている。そして、「すれ違い通信」は、ゲーム装置１間で、自動的に繰り返しお互いをサーチし、お互いを検出した場合、自動的にこのボックス内のデータを送受信するものである。

以下に一例を示す。例えば、ユーザＡが自己の所有するゲーム装置Ａにおいて、あるゲームＡをプレイしたとする。その結果、当該ゲームＡの処理において、「宝の地図その１」を示すデータが、ゲームＡに対応付けられているスロットの送信用ボックスに格納される。更に、当該ユーザＡが別のゲームＢをプレイし、当該ゲームＢの処理において、ゲーム中で利用可能な「傭兵」である「戦士」のデータがゲームＢに対応付けられているスロットの送信用ボックスに格納される。図８は、このような、ユーザＡのゲーム装置Ａにかかる格納状態を示す模式図である。

同様に、ユーザＢが自己の所有するゲーム装置ＢにおいてゲームＡをプレイし、その結果、「宝の地図その３」を示すデータがゲームＡに対応付けられているスロットの送信用ボックスに格納される。また、ユーザＢがゲームＢをプレイした結果、「魔術師」の傭兵データがゲームＢに対応付けられているスロットの送信用ボックスに格納される。図９は、ユーザＢのゲーム装置Ｂにおける格納状態を示す模式図である。

以上のような格納状態を前提として、ユーザＡ、ユーザＢが共に、それぞれの所有するゲーム装置を所持して外出したと仮定する。ゲーム装置はそれぞれ「スリープモード」に移行しているとする。また、共に「すれ違い通信」を行うことを許可する設定がなされているものとする。また、この「スリープモード」の間、ゲーム装置１はそれぞれ、「すれ違い接続要求」という信号（すれ違い通信用のビーコン）を周期的に発信している。図１０は、このような前提における「すれ違い通信」を示す模式図である。図１０において、ユーザＡの出発点は地点Ａであり、ユーザＢの出発点は地点Ｃであるとする。その後、両者が地点Ｅに到達し、それぞれのゲーム装置がローカル通信可能な範囲まで接近したとする。このとき、一方のゲーム装置が発する「すれ違い接続要求」が他方のゲーム装置により受信され、これに基づいてゲーム装置同士の「ローカル通信」のための接続が確立される。そして、次のようなデータ交換が行われる。すなわち、ユーザＡのゲーム装置Ａにおける送信用ボックス内のデータが、ゲーム装置Ｂの、それぞれ対応するゲームのスロットの受信用ボックスに送信される。具体的には、ゲームＡの「宝の地図その１」が、ゲーム装置ＢのゲームＡに対応付けられたスロットの受信用ボックスに送信される。同様に、ゲーム装置ＡのゲームＢの「戦士の傭兵データ」が、ゲーム装置ＢのゲームＢのスロットの受信用ボックスに送信される。同様に、ゲーム装置Ｂからゲーム装置Ａに向けて、「宝の地図その３」と「魔術師の傭兵データ」がそれぞれ対応するゲームのスロットの受信用ボックスに送信される。

その結果、例えば、図１０の地点Ｂで示されるように、「すれ違い通信」後のゲーム装置Ａでは、ゲームＡのスロットには、送信用ボックスに「宝の地図その１」、受信用ボックスには「宝の地図その３」が格納されている。また、ゲームＢのスロットには、送信用ボックスに「戦士の傭兵データ」、受信用ボックスには「魔術師の傭兵データ」が格納されている。そして、ユーザＡは、当該受信用ボックスに格納されたデータをそれぞれ対応するゲームにおいて利用することが可能となる。同様に、ゲーム装置Ｂについても、地点Ｄで示されるように、ゲーム装置Ａから受信した「宝の地図その３」「戦士の傭兵データ」データが格納されており、ユーザＢは、これらのデータをそれぞれ対応するゲームにおいて利用可能となっている。

このように、本実施形態における「すれ違い通信」は、ゲーム装置１が「スリープモード」のときに、すれ違い通信用の記憶領域に格納されている所定のデータの送受信を「ローカル通信」を利用して行うものである。但し、通信対象となるアプリケーションについては、双方共に上記スロットに設定しているゲームタイトルに限る。例えば、上記ユーザＢが、ゲームＢのみ上記スロットに対応付けており、ゲームＡについてはゲーム自体を所有していないような場合は、ゲームＢに関するデータのみ送受信が行われ、ゲームＡのデータの送受信は行われない。

次に、ゲーム装置１において行われる上記のような処理の詳細を説明する。まず、本処理において用いられる主なプログラムおよびデータについて説明するが、この説明に先立ち、本実施形態における処理の実行主体に関して説明する。本実施形態では、マイコン３７、無線通信モジュール３４、ＣＰＵ３１が、それぞれ独立して、以下に説明する処理の実行主体となり、これらの処理が互いに連携しながら並列的に実行される。主な処理内容の分担を説明すると、マイコン３７は、主に、ゲーム装置１の開け閉めの検知や電源制御モードの切替制御、タスク実行時刻の時間管理等に関する処理を担当する。無線通信モジュール３４は、主に、すれ違い通信の実行開始条件の監視や、インターネット通信に際しての、ＡＰからのビーコンのスキャン等の処理を担当する。ＣＰＵ３１は、主に、上記マイコン３７、無線通信モジュール３４の担当する処理以外の処理全般を担当する。例えば、アプリケーションの実行、タスクの実行などである。

ここで、以下の説明の一助のために、図１１に、本実施形態で実行される各種機能（プログラム）の相関関係を示す。図１１では、マイコン３７が実行するマイコン処理と、無線通信モジュール３４が実行する無線モジュール処理と、ＣＰＵ３１が実行する起動時処理とが並列して実行可能であることを示す。図１１の各要素は、後述する図１２〜図１４で示される各種プログラムに対応する。図１１において、例えば、マイコン３７が実行する「マイコン処理」というプログラムにおいて、「ローカル通信用ＢＧ（BackGround）処理」が呼び出されて実行されることが示されている。更に、当該「ローカル通信用ＢＧ処理」においては、「インターネット通信用ＢＧ処理」が呼び出されて実行されることを示す。また、当該「ローカル通信用ＢＧ処理」は、無線通信モジュール３４が実行する「無線モジュール処理」においても呼び出されることがあり、ＣＰＵ３１が実行する起動時処理においても呼び出されることがあることが示されている。

以下、本処理において用いられる主なプログラム、データについて説明する。図１２は、マイコン３７に内蔵されている記憶領域（図示せず）に記憶される主なデータを示す図である。マイコン３７内部には、プログラム領域３０１とデータ領域３０３が存在し、プログラム領域３０１には、上記のようなマイコン３７が担当する処理を実行するためのマイコン処理プログラム３０２が記憶され、データ領域３０３には、給電状態フラグ３０４、次回起床時刻３０５が記憶される。給電状態フラグ３０４は、「スリープモード」であるか否かを示すためのフラグである。オンに設定されているときは「通常電力モード」、オフに設定されているときは、「スリープモード」であるとする。次回起床時刻３０５は、「スリープモード」を解除する時刻を示すデータである。基本的には、各タスクに設定される次回実行時刻のうち、最も早い時刻が次回起床時刻３０５として設定されることになる。但し、後述するように、現在の時刻から次回の実行時刻までの時間が短すぎる場合や長すぎる場合には、若干の調整が行われる。

図１３は、無線通信モジュール３４に内蔵されている記憶領域（図示は省略）に記憶される主なデータを示す図である。無線通信モジュール３４内の記憶領域には、プログラム領域４０１とデータ領域４０３が存在し、プログラム領域４０１には、上記のような無線通信モジュール３４が担当する処理を実行するための無線モジュール処理プログラム４０２が記憶され、データ領域４０３には、専用ＡＰ識別情報４０４、既通信端末／専用ＡＰ情報４０５、抽出アプリＩＤ４０６が記憶される。

専用ＡＰ識別情報４０４は、上記専用ＡＰ１０１を識別するための文字列である。上述したビーコンに含まれるベンダー特定情報と、当該専用ＡＰ識別情報４０４とが照合されることで、専用ＡＰ１０１か否かの判定が可能となる。既通信端末／専用ＡＰ情報４０５は、短期間内で同じ通信相手と連続して通信を行わないようにするための情報である。具体的には、所定の通信相手と通信が行われると、当該通信を行った相手のＭＡＣアドレスおよび通信時刻が既通信端末／専用ＡＰ情報４０５として、所定期間、記憶される（複数台分記憶可能である）。ここに記憶されている通信相手については、その存在が検知されても、通信が行われないように制御される。これにより、同じ通信相手と立て続けに通信を繰り返すことを避けることができる。

抽出アプリＩＤ４０６は、後述するすれ違い通信用データ５２０のアプリＩＤ５２２を抽出して記憶したデータである。このデータは、上記のような「すれ違い通信」の対象となるアプリケーションやゲームを示すものである。

図１４は、ＮＡＮＤフラッシュメモリ３３に記憶されるプログラム、データを示す図である。なお、これらのデータは、必要に応じてメインメモリ３２に展開されて実行される。ＮＡＮＤフラッシュメモリ３３は、プログラム領域５００とデータ領域５１２を有しており、プログラム領域５００は、システムプログラム領域５１５を有している。更に、プログラム領域５００には、複数のアプリケーションプログラム５１１が記憶されている。

システムプログラム領域５１５には、メニュー処理プログラム５０１、タスク生成処理プログラム５０２、ローカル通信ＢＧ処理プログラム５０３、インターネット通信ＢＧ処理プログラム５０４、ポリシー処理プログラム５０５、タスク実行処理プログラム５０６、実行順ソート処理プログラム５０７、システムインストール処理プログラム５０８、アプリインストール処理プログラム５０９、等が記憶される。

メニュー処理プログラム５０１は、本体メニューに関する処理を実行するためのプログラムである。タスク生成処理プログラム５０２は、各タスクを生成するためのプログラムである。

ローカル通信ＢＧ処理プログラム５０３およびインターネット通信ＢＧ処理プログラム５０４は、上記「ローカル通信」や「インターネット通信」に関する処理を実行するためのプログラムである。

ポリシー処理プログラム５０５は、上記「ポリシーデータ」の取得やこれに基づくタスクの優先度変更等の処理を実行するためのプログラムである。タスク実行処理プログラム５０６は、各タスクを実行するためのプログラムであり、実行順ソート処理プログラム５０７は、当該タスクの実行に際して、その実行順序を決定するためのプログラムである。システムインストール処理プログラム５０８は、システムのアップデートに関する処理を行うためのプログラムである。

アプリインストール処理プログラム５０９は、例えばゲームの体験版や無料アプリケーション等のアプリケーションを新規にインストールしたり、既にインストール済みであるゲームやアプリケーションのアップデート（更新）の処理を行うためのプログラムである。

アプリケーションプログラム５１１は、例えばゲームなどの各種アプリケーションを実行するためのプログラムである。なお、ここでは便宜上「プログラム」と示しているが、当該アプリケーションの実行で用いられるデータの一部についても当該アプリケーションプログラムに含まれるものとする。

また、図示は省略するが、システムプログラム領域５１５には、上記の各種データの他、システムプログラムの更新用のファイルが、更新対象のシステムプログラムのファイル名とは異なるファイル名をつけられて格納されることもある。詳細は後述するが、システムの更新を反映する処理が実行されるときに、更新対象となるシステム要素（例えば、「メニューの実行」）の参照情報（当該「メニューの実行」の実体となるプログラムのファイル名）がこの別名で格納されたファイル名を指し示すように変更されることでシステムプログラムの更新の反映が行われる。例えば、上記「メニューの実行」というシステム要素があり、更新前の状態では、当該要素を実行するための実行プログラムのファイル名が”menu0101.exe”であるとする。そして、いわゆるレジストリ情報として、「メニューの実行」という要素と"menu0101.exe"とが関連づけられているとする（以下、このようなレジストリ情報を「実体プログラムへの参照情報」と呼ぶ）。その後、更新ファイルがダウンロードされ、そのファイル名が"menu0201.exe"として格納されたとする。このような場合、当該システムプログラムの更新の反映については、上記「実体プログラムへの参照情報」を”menu0101.exe”から”menu0201.exe”に変更する（つまり、レジストリ情報を変更する）ことで更新の反映がなされる。

次に、データ領域５１２について説明する。データ領域５１２には、すれ違い通信用データ５２０、タスクデータ５３０、アプリ関連データ５５０、本体設定データ５６０、受信ポリシーデータ５７０、インストールリスト５８０、オン・ザ・フライ用キャッシュ６００、権利情報データベース６１０、システムインストール済みフラグ６２０、アプリインストール必要フラグ６３０、現在のシステム構成の詳細リスト６４０、構成要素比較用データ６５０、削除履歴６６０、プレイ履歴６７０等が記憶される。

すれ違い通信用データ５２０は、上述したような「すれ違い通信」において送受信するためのデータである。図１５は、すれ違い通信用データ５２０のデータ構造の一例を示した図である。すれ違い通信用データ５２０は、スロット５２１の集合から構成される。各スロット５２１は、アプリＩＤ５２２、送信用ボックス５２３、受信用ボックス５２４から構成される。アプリＩＤ５２２は、当該スロット５２１に対応付けられているアプリケーションやゲームを特定するためのＩＤである。送信用ボックス５２３には、「すれ違い通信」において他のゲーム装置１に送信するためのデータが格納される。受信用ボックス５２４には、「すれ違い通信」において他のゲーム装置１から受信したデータが格納される。

図１４に戻り、タスクデータ５３０は、本実施形態において実行されるタスクの内容について定義したデータである。図１６は、タスクデータ５３０のデータ構造の一例を示した図である。タスクデータ５３０は、複数のタスク設定５３１が格納される。各タスク設定５３１は、アプリＩＤ５３２、タスクＩＤ５３３、実行優先度５３４、通信先ＵＲＬ５３５、ファイルパス５３６、次回実行時刻５３７、実行間隔５３８、送信／受信識別フラグ５３９、消尽回数５４０、未処理フラグ５４１、一時変更フラグ５４２、タスクリビジョン５４３、前回完了時刻５４４、タスク登録時刻５４５等から構成される。

アプリＩＤ５３２は、そのタスクに関連するアプリケーションやゲーム（典型的には、当該タスクの作成元になったアプリケーションやゲーム）を示すＩＤである。タスクＩＤ５３３は、当該タスクを識別するためのＩＤである。

実行優先度５３４は、当該タスクの実行優先度を示すデータであり、上述したような”EXPEDITE”、”HIGH”、”MEDIUM”、”LOW”、”STOPPED”を示す情報が格納される。

通信先ＵＲＬ５３５は、当該タスクの通信先（典型的には、データのアップロード先、あるいはダウンロード元のサーバ）を示す。ファイルパス５３６は、上記アップロードあるいはダウンロードするデータのゲーム装置１内における保存場所を示すデータである。つまり、上記通信先に対してアップロードするデータが存在するゲーム装置１内の場所、あるいは、ダウンロードしたデータを格納するゲーム装置１内での場所を示すデータである。

次回実行時刻５３７は、当該タスクが次に実行されるべき時刻を示すデータである。実行間隔５３８は、当該タスクの実行間隔を示すデータである。例えば、１日毎、３日毎、１週間毎、等を示すデータが格納される。上記次回実行時刻５３７の決定の際に、当該実行間隔５３８が用いられる。

送信／受信識別フラグ５３９は、そのタスクが所定のデータを送信する「送信タスク」であるか、所定のデータを受信する「受信タスク」であるかを示すフラグである。例えば、当該フラグがオンに設定されていれば「受信タスク」であり、オフに設定されていれば「送信タスク」であることを示す。

消尽回数５４０は、上述したような当該タスクの消尽回数である。この回数が０になったタスクは、実行優先度５３４の内容に関わらず実行されない。未処理フラグ５４１は、当該タスクが実行されたか否かを示すフラグであり、オンに設定されていれば実行済み、オフに設定されていれば未実行であることを示す。一時変更フラグ５４２は、タスクの実行優先度５３４が後述のポリシーデータに基づいて変更された際に、その優先度の変更が一時的なものか否かを示すフラグである。

タスクリビジョン５４３は、当該タスクに適用されたポリシーの最終のリビジョンを示すデータである。前回完了時刻５４４は、当該タスク設定５３１にかかるタスクが最後に実行されて正常に完了した時刻を示すデータである。タスク登録時刻５４５は、当該タスク設定５３１が一番最初に生成・登録された時刻を示すデータである。

図１４に戻り、次に、アプリ関連データ５５０は、ゲーム装置１にインストールされている各種アプリに関連するデータである。図１７は、アプリ関連データ５５０のデータ構造の一例を示した図である。アプリ関連データ５５０には、複数のアプリケーション領域５５１が含まれている。各アプリケーション領域５５１には、アプリＩＤ５５２、タスク受信キャッシュ５５３、新規インストールフラグ５５４、セーブデータ５５５、新規アップデートフラグ５５９が記憶される。アプリＩＤ５５２は、当該アプリケーション領域５５１に対応するアプリケーションを示すためのＩＤである。タスク受信キャッシュ５５３は、上記「受信タスク」が実行された結果、受信したデータが格納される領域である。そのため、「受信タスク」の場合は、上記タスク設定５３１のファイルパス５３６で当該タスク受信キャッシュ５５３の位置を示す情報（例えばアドレス）が、示される。

新規インストールフラグ５５４は、当該アプリが新規にインストールされたアプリケーションか否かを示すフラグである。当該フラグがオンに設定されていれば、上記アプリＩＤで示されるアプリケーションが新規にインストールされたアプリケーション（例えば、新作ゲームの体験版や、新作の無料アプリケーション等）であることを示す。

セーブデータ５５５は、当該上記アプリＩＤ５５２で示されるアプリケーションに関するセーブデータであり、タスク送信用データ５５６、タスク受信データ５５７、すれ違い受信データ５５８で構成されている。その他、例えば、当該アプリケーションがゲームであれば、プレイヤキャラクタのデータやゲームの進行を示すデータ等も含まれる。

タスク送信用データ５５６は、「送信タスク」において送信されるべきデータである。当該データの場所を示す情報（例えばアドレス）が、上記タスク設定５３１のファイルパス５３６で示される。タスク受信データ５５７は、上記タスク受信キャッシュ５５３のデータが、当該アプリケーションの実行に際してコピーされるものである。その結果、セーブデータ５５５の一部として扱われ、当該アプリケーションの処理において利用可能となる。すれ違い受信データ５５８も同様に、当該アプリケーションの実行に際して上記すれ違い通信用データ５２０の受信用ボックス５２４からコピーされるものである。

新規アップデートフラグ５５９は、当該アプリの更新用のファイルがダウンロードされたか否かを示すフラグである。当該フラグがオンに設定されていれば、上記アプリＩＤ５５２で示されるアプリの更新ファイルがダウンロードされていることを示す。

図１４に戻り、本体設定データ５６０は、ゲーム装置１に登録される各種設定等のデータである。例えば、ユーザの氏名や年齢、国情報のユーザ情報が含まれる。また、例えばユーザの自宅に設置したＡＰのＥＳＳＩＤ（Extended Service Set Identifier）やパスワード等のネットワーク設定等も含まれる。このネットワーク設定については、ゲーム装置１においてネットワーク設定のための処理が適宜実行されることで、ユーザの操作に応じて適宜設定され、記憶される。また、このネットワーク設定には、上記ユーザの設定によるものの他、出荷時設定として予め設定されている所定のプロバイダのＡＰのＥＳＳＩＤ等（例えば、公衆無線ＬＡＮスポット等）も含まれる。その他、ゲーム装置１のシステムソフトウェアの最終更新日時等も記憶される。

受信ポリシーデータ５７０は、上述したようなポリシーサーバ１０３から受信したポリシーデータである（そのため、ポリシーサーバ１０３に記憶されているポリシーデータの構造も、当該受信ポリシーデータ５７０と同様である）。図１８は、受信ポリシーデータ５７０のデータ構造の一例を示した図である。受信ポリシーデータ５７０は、ポリシーリビジョン５７１、ポリシー更新日時５７２、ＡＰ情報５７３、および、複数のポリシー設定５７４から構成される。

ポリシーリビジョン５７１は、当該受信ポリシーデータ５７０のリビジョンを示すデータである。ポリシー更新日時５７２は、当該ポリシーデータが更新された日時（ポリシーサーバにアップされた日時）を示すデータである。ＡＰ情報５７３は、当該受信ポリシーデータ５７０と関連づけられているＡＰを示す情報である。

ポリシー設定５７４は、実行優先度等を変更する対象となるタスクとその変更内容について定義したデータである。各ポリシー設定５７４は、アプリＩＤ５７５、タスクＩＤ５７６、実行優先度５７７、タスク永続性５７８から構成されている。アプリＩＤ５７５は、ポリシーデータの適用対象となるアプリケーションを示すＩＤである。タスクＩＤ５７６は、ポリシーデータの適用対象となるタスクを示すデータであり、上記タスクデータ５３０のタスクＩＤ５３３を個別に指定するほか、例えば「全てのタスク」のように、総称的な指定や複数のタスクをまとめて指定することを示すデータが格納されることもある。

実行優先度５７７は、変更後の実行優先度を示す。タスク永続性５７８は、今回の変更が一時的な変更であるか永続的な変更であるかを示すフラグである。オンに設定されていれば、永続的な変更であることを示す。

図１４に戻り、次に、インストールリスト５８０は、システムのアップデートや体験版アプリのインストール等、何らかのアプリのインストールが必要な場合に、そのインストール内容を示すためのデータである（インストール内容のインデックス的なものである）。ここで、本実施形態では、当該「インストールリストの取得」というタスクが、ゲーム装置１の出荷時の初期設定の一つとして予め上記タスクデータ５３０に登録されている。また、当該初期設定型のタスクであることを示すために予め定められた値が上記タスクＩＤ５３３として定義されている。本実施形態においては、当該インストールリスト５８０は、ゲーム装置１のシステム的な機能の一環として、定期的に取得されるものとする。

図１９は、インストールリスト５８０のデータ構造の一例を示した図である。図１９において、インストールリスト５８０は、リストリビジョン５８１、ＡＰ情報５８２、システムアップデート情報５８３、および、アプリ情報５８９から構成されている。

ＡＰ情報５８２は、当該インストールリスト５８０に関連づけられたＡＰを示す情報である。つまり、上記ポリシーデータと同様に、インストールリスト５８０もＡＰ毎に異なる内容のものを定義可能である。

システムアップデート情報５８３は、システムを構成する各種システムプログラムのうち、アップデート可能なシステムプログラム（モジュール）を示す情報である。ここでは、システムプログラムを構成要素５８４として示している。アップデート対象となるシステムプログラムが複数ある場合は、複数の構成要素５８４がシステムアップデート情報５８３に含まれることになる。構成要素５８４は、構成要素ＩＤ５８５、優先順位５８６、バージョン情報５８７を含む。

構成要素ＩＤ５８５は、各構成要素を一意に識別するためのＩＤである。優先順位５８６は、この構成要素をダウンロードするためのタスクの優先順位（上記実行優先度５３４）を示すデータである。バージョン情報５８７は、当該構成要素のバージョンを示すデータである。

アプリ情報５８９は、インストール対象となりうるアプリケーションに関して定義したデータである。また、インストールリスト５８０には、複数のアプリ情報５８９が含まれることもあるし（複数のアプリの更新がある場合等）、一つも含まれない場合（システムの更新しかない場合等）もあり得る。アプリ情報５８９は、アプリＩＤ５９０、アプリバージョン５９１、アプリ種別５９２、レーティング情報５９３、優先順位５９４、ダウンロード条件情報５９５等から構成される。

アプリＩＤ５９０は、インストールされるアプリを識別するためのＩＤである。アプリバージョン５９１は、インストールされるアプリケーション等のバージョンを示す。アプリ種別５９２は、そのインストールにかかるアプリケーションの種別を示すデータである。例えば、体験版アプリであるか、無料アプリであるか、後述の「特典アプリ」であるか等が示される。レーティング情報５９３は、そのインストールにかかるアプリのレーティング（対象年齢）を示す情報である。本体設定データ５６０に含まれるユーザの年齢情報等に応じて、実際にインストールを行うか否かが決定される。

ダウンロード条件情報５９５は、当該アプリをダウンロードするため必要な条件を示すデータである。これは、例えば、あるゲームを所定時間以上プレイした場合の「特典」として、特典用のアプリをダウンロードさせるような場合を想定したものである。本実施形態では、この条件として、当該ゲームのプレイの履歴を利用する。具体的には、当該ダウンロード条件情報５９５には、ＤＬするために所持している必要があるゲームのアプリＩＤと、当該ゲームの必要プレイ時間を示す情報が含まれている。なお、このようなダウンロードのための条件が無いアプリ（ダウンロード条件が設定されていないアプリ）の場合は、当該情報には何も値は設定されないものとする。なお、以下の説明では、このような条件のことを「プレイ履歴条件」と呼ぶ。また、プレイ履歴条件が設定されているアプリのことを特に「特典アプリ」と呼ぶこともある。

図１４に戻り、オン・ザ・フライ用キャッシュ６００は、ゲーム装置１のシステムアップデートに際して、インストール方式が「移動型」であるシステムアップデート用のデータを格納するための領域である。本実施形態では、システムアップデート用のデータは、圧縮ファイルとしてサーバにアップロードされる。そして、ゲーム装置１は、インストール方式が「移動型」のシステムアップデートの処理を行う際は、当該圧縮ファイルをダウンロードするのと並行して、いわゆるオン・ザ・フライで当該圧縮ファイルの展開が行われる。この展開先が、当該オン・ザ・フライ用キャッシュ６００である。また、ここに格納されるアップデート用データのファイル名は、上述のように、更新対象のファイル名と同じ名前で格納される。例えば、あるシステムデータのファイル名が「firmware.bin」であるとすると、オン・ザ・フライ用キャッシュ６００に格納されるアップデート用データのファイル名も「firmware.bin」として格納される。後述するが、「移動型」のシステムアップデート処理では、オン・ザ・フライ用キャッシュ６００に格納されたファイルが、システムプログラム領域５１５に移動されることでアップデートの反映が完了する。

権利情報データベース６１０は、アプリケーションの実行に際して所定の認証を行うために用いる情報である権利情報が含まれたデータベースである。なお、権利情報は各アプリについてそれぞれ用意されており、アプリのダウンロード時に併せて取得される。

システムインストール済みフラグ６２０は、システム更新用のデータが取得されている状態であって、まだその反映が成されていないか否かを示すためのフラグである。つまり、システム更新の反映が可能か否かを示すフラグである。オンに設定されているときは、未反映のシステム更新用のデータがあること、すなわち、システムの更新が可能であることを示し、オフに設定されているときは、システム更新ができない（更新の必要がない、既に最新の状態である）ことを示す。

アプリインストール必要フラグ６３０は、アプリをインストールする処理が必要であるか否かを示すためのフラグであり、オンに設定されている場合は、アプリをインストールする処理が必要であることを示す。

現在のシステム構成の詳細リスト６４０は、現在のシステムを構成している各システムプログラム（モジュール、構成要素）のファイル名やそれぞれのバージョン等、各システムプログラムに関する詳細な情報を示すデータである。

構成要素比較用データ６５０は、システムのアップデートの必要があるか否かを判断するために用いられる情報である。例えば、現在のシステムプログラム全体のハッシュ値等である。

削除履歴６６０は、ユーザの意思によって削除されたアプリを示す情報（アプリＩＤ５９０等）を集積したデータである。本実施形態では、当該リストに載っているアプリについては、自動的にダウンロードおよびインストールが行われない。つまり、ユーザの意思で一旦削除されたアプリについては、原則として、自動的にインストールされることを回避することになる。

プレイ履歴６７０は、インストールされているゲーム等の各種アプリのプレイ履歴（利用履歴）を示すデータである。図示は省略するが、当該データには、対応するアプリを示すアプリＩＤと、そのアプリの（最終の）起動時刻および終了時刻、バージョン情報等が含まれている。

また、その他、図示は省略するが、データ領域５１２には、ゲーム装置１にインストールされている各アプリのバージョン情報や追加日、最終更新日等の、各アプリに関連する各種情報（いわゆるメタデータ）を集約したデータ（メタデータ・データベース）、上述したようないわゆるレジストリ情報の集合体であるレジストリデータベース等も記憶されている。

次に、ゲーム装置１によって実行される上記のような処理の詳細について説明する。以下では、まず最初にマイコン３７が行う処理について説明し、次に、無線通信モジュール３４が行う処理について説明し、その後、ＣＰＵ３１が行う処理について説明する。

［マイコン３７が実行する処理］
図２０は、マイコン３７によって実行されるマイコン処理を示すフローチャートである。図２０で示される処理は、ゲーム装置１の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。

図２０において、まず、ステップＳ１で、ゲーム装置１が上記「スリープモード」であるか否かが判定される。具体的には、上記給電状態フラグ３０４が参照されることによって「スリープモード」か否かが判定される。当該判定の結果、「スリープモード」であると判定されたときは（ステップＳ１でＹＥＳ）、次に、ステップＳ２において、起床時刻（スリープモードを解除すべき時刻）が到来したか否かが判定される。具体的には、マイコン３７内のＲＴＣ３９が、マイコン３７内の記憶領域にある次回起床時刻３０５と現在時刻とを比較することにより判定される。当該判定の結果、起床時刻が到来したと判定されなかったときは（ステップＳ２でＮＯ）、後述のステップＳ６に処理が進められる。一方、起床時刻が到来したと判定されたときは（ステップＳ２でＹＥＳ）、ステップＳ３において、「スリープモード」を解除し、「通常電力モード」に移行させるための命令がマイコン３７からＣＰＵ３１に対して発行されるとともに、給電状態フラグ３０４をオンにし、かつ、電源管理ＩＣ４１にスリープを解除する旨を通知する。なお、ここでは「通常電力モード」に移行させる場合を例にしたが、この他、上述したようなＬＣＤへの電源は供給しない「モニタオフモード」に移行させてもよい。つまり、ＣＰＵ３１に電力を供給する電源制御モードであればよい。

次に、ステップＳ４において、ＣＰＵ３１によって、ローカル通信用ＢＧ処理が実行される。当該処理の詳細については後述するが、ここで行われる処理概要を簡単に説明する。この流れにおけるローカル通信用ＢＧ処理においては、結果的には、上記「インターネット通信」による、一般ＡＰ１０２およびインターネットを介した所定のサーバへの接続、および、上記タスクの実行が行われる。また、必要に応じて、インストール処理も実行されることになる。そして、当該ローカル通信用ＢＧ処理が終われば、後述するステップＳ６に処理が進められる。

一方、上記ステップＳ１の判定の結果、ゲーム装置１が「スリープモード」ではない（つまり、「通常電力モード」で動作中）と判定されたときは（ステップＳ１でＮＯ）、次に、ステップＳ５において、上記次回起床時刻３０５や上記タスクデータ５３０の次回実行時刻５３７が参照されて、起床時刻、もしくは、タスクの実行予定時刻であるスケジュール時刻が到来したか否かが判定される。当該判定の結果、いずれかの時刻が到来したと判定されたときは（ステップＳ５でＹＥＳ）、上記ステップＳ４に処理が進められる。一方、いずれの時刻も到来していないと判定されたときは（ステップＳ５でＮＯ）、ステップＳ６に処理が進められる。

次に、ステップＳ６において、ゲーム装置１が閉状態（ハウジングが閉じられている状態）から開状態（ハウジングが開かれた状態）に移行したか否か（つまり、ゲーム装置１が開かれたか否か）が判定される。具体的には、マイコン３７は、開閉検出器４０からハウジングが開かれたことを示す検出信号があったか否かを判定する。当該判定の結果、閉状態から開状態に移行したと判定されたときは（ステップＳ６でＹＥＳ）、次のステップＳ７において、「スリープモード」を解除するための命令がマイコン３７からＣＰＵ３１に発行されるとともに、給電状態フラグ３０４をオンにし、かつ、電源管理ＩＣ４１に、スリープを解除する旨を通知する。続くステップＳ８において、「スリープモード」から復帰したこと（解除されたこと）を示す旨がマイコン３７から電源制御ＩＣ４１に通知される。これに応じて、電源管理ＩＣ４１は、適宜、ゲーム装置１の各構成部品への電力供給を開始する。

一方、ステップＳ６の判定の結果、ゲーム装置１が閉状態から開状態に移行していないと判定されたときは（ステップＳ６でＮＯ）、次に、ステップＳ９において、ゲーム装置１が開状態から閉状態に移行したか否か（つまり、ゲーム装置１が閉じられたか否か）が開閉検出器４０からの信号により判定される。その結果、ゲーム装置１が開状態から閉状態に移行したと判定されたときは（ステップＳ９でＹＥＳ）、次のステップＳ１０において、「スリープモード」に移行させるための命令がマイコン３７からＣＰＵ３１に発行されるとともに、給電状態フラグ３０４をオフにし、かつ、電源管理ＩＣ４１に、スリープに移行する旨を通知する。更に、続くステップＳ１１において、「スリープモード」に移行する旨の通知がマイコン３７から電源管理ＩＣ４１に対して発行される。これに応じて、電源管理ＩＣ４１は、適宜、ゲーム装置１の各構成部品への電力供給を停止する。一方、ステップＳ９の判定の結果、ゲーム装置１が開状態から閉状態に移行していないと判定されたときは（ステップＳ９でＮＯ）、上記ステップＳ１０およびＳ１１の処理がスキップされて、マイコン処理は終了する。

［無線通信モジュール３４が実行する処理］
次に、無線通信モジュール３４で実行される無線モジュール処理について説明する。図２１〜図２２は、当該無線モジュール処理を示すフローチャートである。図２１で示される処理も上記マイコン処理と同様に、ゲーム装置１の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。

図２１で、まずステップＳ２１において、上記無線通信モジュール３４内の記憶領域の既通信端末／専用ＡＰ情報４０５が参照されて、前回の通信から所定時間経過したＭＡＣアドレスが記憶されているか否かが判定される。上述したように、既通信端末／専用ＡＰ情報４０５には最終な通信時刻が記憶されているため、この時刻と現在時刻とを比較することで、所定時間が経過したＭＡＣアドレスの有無が判定される。

当該判定の結果、前回の通信から所定時間経過しているＭＡＣアドレスが記憶されていると判定されたときは（ステップＳ２１でＹＥＳ）、ステップＳ２２において、当該条件を満たすＭＡＣアドレスおよびこれと関連づけられている最終の通信時刻のデータが既通信端末／専用ＡＰ情報４０５から削除される。そして、ステップＳ２３に処理が進められる、一方、前回の通信から所定時間経過しているＭＡＣアドレスが記憶されていないと判定されたときは（ステップＳ２１でＮＯ）、上記ステップＳ２２の処理はスキップされ、次のステップＳ２３に処理が進められる。

ステップＳ２３において、「すれ違い接続要求」がブロードキャスト送信される。この「すれ違い接続要求」とは、上記すれ違い通信用データ５２０に何らかのデータが記憶されているときに、上述したような「すれ違い通信」を希望していることを他のゲーム装置１に知らせるための要求信号である。当該信号には、自身のＭＡＣアドレスが含まれる。更に、抽出アプリＩＤ４０６で示されるアプリＩＤも含まれている。つまり、データの送受信対象となる（送受信を希望する）アプリケーションを示すデータが含まれて、「すれ違い接続要求」がブロードキャストされている。

次に、ステップＳ２４において、「すれ違い接続応答」を受信したか否かが判定される。当該「すれ違い接続応答」とは、上記ステップＳ２３でブロードキャスト送信した「すれ違い接続要求」を受信した他のゲーム装置１からの応答信号である。当該応答信号を受信したということは、この応答信号を返してきた他のゲーム装置１と「ローカル通信」の接続確立が可能であることを示す。当該判定の結果、他のゲーム装置１からの「すれ違い接続応答」を受信したと判定されたときは（ステップＳ２４でＹＥＳ）、次に、ステップＳ２５において、互いのゲーム装置１において送受信対象として登録されているアプリケーションが一致するか否かが判定される。具体的には、上記受信した「すれ違い接続応答」に含まれているアプリＩＤと、上記抽出アプリＩＤ４０６とが照合される。そして、少なくとも１つ以上、一致するアプリＩＤがあるか否かが判定される。

当該判定の結果、一致するアプリＩＤが１つもないと判定されたときは（ステップＳ２５でＮＯ）、「すれ違い通信」は行われずに、無線モジュール処理は終了する。一方、一致するアプリＩＤが少なくとも１つ以上あると判定されたときは（ステップＳ２５でＹＥＳ）、当該アプリＩＤに関するすれ違い用データの送受信を行うための処理が実行される。具体的には、まず、ステップＳ２６において、ゲーム装置１が「スリープモード」であるか否かが判定される。ここで、スリープ中か否かを判別するための給電状態フラグ３０４はマイコン３７内に存在し、また、無線通信モジュール３４とマイコン３７はＣＰＵ３１を介して接続されているため、スリープ中でＣＰＵに通電が行われていない状態では、無線通信モジュール３４は、給電状態フラグ３０４にアクセスする事ができない。このため、給電状態フラグ３０４にアクセスすることができないという結果をもって、スリープ中であるという判別が可能である。その結果、「スリープモード」であれば（ステップＳ２６でＹＥＳ）、ステップＳ２７において「スリープモード」を解除するための命令がＣＰＵ３１に発行される。また、ここでは、ＣＰＵ３１に電力を供給するモードであればよいので、上述の「モニタオフモード」に移行してもよい。そして、ステップＳ２８において、ローカル通信用ＢＧ処理が実行される。一方、ゲーム装置１が「スリープモード」ではないと判定されたときは（ステップＳ２６でＮＯ）、「通常電力モード」で稼働していると考えられるため、上記ステップＳ２７の処理はスキップされて、ステップＳ２８に処理が進められる。

ステップＳ２８においては、ＣＰＵ３１によって、ローカル通信用ＢＧ処理が実行される。この処理の詳細は後述するが、この流れでのローカル通信用ＢＧ処理での処理概要を簡単に説明すると、結果的に、「ローカル通信」を用いたすれ違い通信用データ５２０の送信が行われ、その後、受信が行われることになる。そして、当該ローカル通信用ＢＧ処理が終われば、無線モジュール処理も終了する。

一方、上記ステップＳ２４の判定の結果、自身がブロードキャストした要求信号に対する「すれ違い接続応答」を受信したと判定されなかったときは（ステップＳ２４でＮＯ）、次に、ステップＳ２９において、他のゲーム装置１からの「すれ違い接続要求」を自身が受信したか否かが判定される。当該判定の結果、他のゲーム装置１から送られた「すれ違い接続要求」を受信したと判定されたときは（ステップＳ２９でＹＥＳ）、次のステップＳ３０において、上記既通信端末／専用ＡＰ情報４０５が参照され、送信元のＭＡＣアドレスが記憶されているか否かが判定される。つまり、直近の時間において「すれ違い通信」を済ませた相手からの「すれ違い接続要求」か否かが判定される。当該判定の結果、送信元のＭＡＣアドレスが既通信端末／専用ＡＰ情報４０５に記憶されていると判定されたときは（ステップＳ３０でＹＥＳ）、当該送信元との通信は行わずに、無線モジュール処理は終了する。

一方、送信元のＭＡＣアドレスが既通信端末／専用ＡＰ情報４０５に記憶されていないと判定されたときは（ステップＳ３０でＮＯ）、ステップＳ３１において、上記ステップＳ２５と同様に、「すれ違い通信」の対象として登録しているアプリのうち、一致するアプリＩＤが存在するか否かが判定される。当該判定の結果、一致するアプリＩＤがないと判定されたときは（ステップＳ３１でＮＯ）、当該送信元との通信は行わずに、無線モジュール処理は終了する。一方、一致するアプリＩＤが少なくとも１つ以上あると判定されたときは（ステップＳ３１でＹＥＳ）、ステップＳ３２において、ステップＳ２６と同様に、ゲーム装置１が「スリープモード」であるか否かが判定される。その結果、「スリープモード」であれば（ステップＳ３２でＹＥＳ）、ステップＳ３３において、ステップＳ２７と同様に、「スリープモード」を解除するための命令がＣＰＵ３１に発行される。そして、ステップＳ３４において、ローカル通信用ＢＧ処理が実行される。一方、ゲーム装置が「スリープモード」ではないと判定されたときは（ステップＳ３２でＮＯ）、既に「通常電力モード」で稼働していることになるので、上記ステップＳ３３の処理はスキップされて、ステップＳ３４に処理が進められる。

ステップＳ３４においては、上記ステップＳ２８同様にローカル通信用ＢＧ処理が実行されるが、この場合の処理概要としては、すれ違い通信用のデータの送信が行われ、その後、受信が行われることになる（上記ステップＳ２８の場合とは、送信と受信の順番が逆になる）。

次に、上記ステップＳ２９において、「すれ違い接続要求」も受信していないと判定されたときの処理（ステップＳ２９でＮＯ）について説明する。この場合は、専用ＡＰ１０１が近くに存在するか否かの判定、及び、存在する場合は専用ＡＰ１０１との通信を行うための処理が実行される。具体的には、図２２のステップＳ３５において、まず、アクセスポイントから発せられるビーコンのスキャンが行われる。いわゆる「パッシブスキャン」である。ここで、本実施形態では、専用ＡＰ１０１との通信に用いる通信チャネルは予め決められているものとする。そのため、この処理では、スリープモード移行時に当該通信チャネルを設定してから移行することで、ＣＰＵ３１を起動せずとも、パッシブスキャンを行うことが可能である。

次に、ステップＳ３６において、上記スキャンの結果、専用ＡＰ１０１から送信されたビーコンを受信したか否かが判定される。具体的には、無線モジュール内の記憶領域に記憶されている専用ＡＰ識別情報４０４が、上記スキャンで得られた受信したビーコンのベンダー特定情報に含まれているか否かが判定される。当該判定の結果、専用ＡＰ１０１からのビーコンを受信したと判定されなかったときは（ステップＳ３６でＮＯ）、当該無線モジュール処理は終了する。

一方、専用ＡＰからのビーコンを受信したと判定されたときは（ステップＳ３６でＹＥＳ）、ステップＳ３７において、当該ビーコンの送信元の専用ＡＰ１０１のＭＡＣアドレスが、既通信端末／専用ＡＰ情報４０５に記憶されているか否かが判定される。つまり、直近において既に通信済みの専用ＡＰ１０１からのビーコンであるか否かが判定される。当該判定の結果、既通信端末／専用ＡＰ情報４０５に記憶されていると判定されたときは（ステップＳ３７でＹＥＳ）、当該無線モジュール処理は終了する。

一方、既通信端末／専用ＡＰ情報４０５に記憶されていないと判定されたときは（ステップＳ３７でＮＯ）、次に、ステップＳ３８において、ステップＳ２６やステップＳ３２と同様に、ゲーム装置１が「スリープモード」か否かが判定される。その結果、「スリープモード」であると判定されたときは（ステップＳ３８でＹＥＳ）、ステップＳ３９において、ステップＳ２７やステップＳ３３と同様に、「スリープモード」を解除するための命令がＣＰＵ３１に発行される。そして、ステップＳ４０において、ローカル通信用ＢＧ処理が実行される。一方、ゲーム装置が「スリープモード」ではないと判定されたときは（ステップＳ３８でＮＯ）、上記ステップＳ３９の処理はスキップされて、ステップＳ４０に処理が進められる。

ステップＳ４０においては、上記ローカル通信用ＢＧプロセスが実行される。当該処理の詳細は後述するが、この流れにおいて実行される内容を簡単に説明すると、結果的に、専用ＡＰ１０１を介してポリシーサーバ１０３に接続する処理や、ポリシーデータに基づくタスクの優先度の変更処理等が実行され、また、各種タスクが実行されることになる。そして、当該ローカル通信用ＢＧプロセスが終われば、当該無線モジュール処理は終了する。

［ＣＰＵ３１が実行する処理］
以下、ＣＰＵ３１が実行する処理に関して説明する。

［起動時処理］
図２３〜図２４は、ゲーム装置１が起動されたときに実行される起動時処理の詳細を示すフローチャートである。購入後のゲーム装置１が最初に起動されると、このフローチャートの処理が開始される。その後、電源が完全に切断されない限りは、図２３に示すステップＳ６２〜Ｓ７４の処理ループがバックグラウンド処理として繰り返し実行される。例えば、ゲーム処理等が実行されているときでも、バックグラウンド処理として図２３〜図２４に示すフローチャートの処理が並列的に実行されている（主に、ゲーム処理中等にホームボタン１４Ｉが押下されることの監視や、そのときの割り込み処理のためである）。

図２３において、まず、ステップＳ６１で、メニュー処理が実行される。この処理の詳細は後述するが、その処理概要を簡単に説明しておくと、メニュー画面の表示に関する処理と、メニュー画面においてユーザによって選択されたアプリケーションの起動・実行処理等が行われる。

次に、ステップＳ６２において、「スリープモード」の解除指示を受けたか否かが判定される。具体的には、以下のような場合に、「スリープモード」の解除指示を受けたと判定される。
（１）「スリープモード」において、「すれ違い接続要求」または「すれ違い接続応答」を受信し、上記無線通信モジュール３４からスリープ解除の指示を受けたとき（上記図２１のステップＳ２７あるいはステップＳ３３）。
（２）「スリープモード」において専用ＡＰ１０１からのビーコンを受信し、無線通信モジュール３４からスリープ解除の指示を受けたとき（上記図２２のステップＳ３９）。
（３）マイコン３７（ＲＴＣ３９）が次回起床時刻の到来を検知し、マイコン３７からスリープ解除の指示を受けたとき（上記図２１のステップＳ３）。
（４）ゲーム装置１が閉状態から開状態に変化し、マイコン３７からスリープ解除の指示を受けたとき（上記図２０のステップＳ７）。

当該判定の結果、スリープ解除の指示を受けたと判定されたときは（ステップＳ６２でＹＥＳ）、次に、ステップＳ６３において、当該解除指示が無線通信モジュール３４から発行された指示であるか否かが判定される。その結果、無線通信モジュール３４から発行された指示と判定されたときは（ステップＳ６３でＹＥＳ）、ステップＳ６４において、マイコン３７を介して電源制御ＩＣ４１に、「スリープモード」を解除することを示す通知が発行されるとともに、マイコン３７内の給電状態フラグ３０４をオンにする。これに応じて、電源制御ＩＣ４１はＣＰＵへの電力供給を開始し、ステップＳ６５において、「スリープモード」が解除される。一方、上記ステップＳ６３の判定の結果、無線通信モジュール３４からの指示ではないと判定されたときは（ステップＳ６３でＮＯ）、マイコン３７からの指示であると考えられるが、マイコン３７からの指示の場合は、既に電源管理ＩＣ４１には通知が行われており、かつ、既に給電状態フラグ３０４も変化している。そのため、上記ステップＳ６４の処理はスキップされ、ステップＳ６５に処理が進められる。その後、後述するステップＳ６９に処理が進められる。

一方、上記ステップＳ６２の判定の結果、「スリープモード」解除の指示を受け付けていないと判定されたときは（ステップＳ６２でＮＯ）、ステップＳ６６において、「スリープモード」への移行指示を受けたか否かが判定される。具体的には、以下のような場合に、「スリープモード」の移行指示を受けたと判定される。
（１）「スリープモード」の状態が解除されて上記「すれ違い通信」が行われた後、再度「スリープモード」に戻る指示が発行されたとき（後述の図３６のステップＳ１６６）。
（２）「スリープモード」が解除されて専用ＡＰとの通信が行われ、その後再度「スリープモード」に戻る指示が発行されたとき（後述の図３８のステップＳ１９５）。
（３）起床時刻到来により「スリープモード」が解除され、通信が行われた後、再度「スリープモード」に戻る指示が発行されたとき（後述の図３８のステップＳ１９５）。
（４）開状態から閉状態に変化し、マイコン３７から「スリープモード」に入る指示を受けたとき（上記図２０のステップＳ１０）。
ここで、上記（１）〜（３）の指示は、後述する「ローカル通信用ＢＧ処理」あるいは「インターネット通信用ＢＧ処理」において発行される。

ステップＳ６６の判定の結果、「スリープモード」への移行指示を受けたと判定されたときは（ステップＳ６６でＹＥＳ）、ステップＳ６７において、マイコン３７を介して電源管理ＩＣ４１に、「スリープモード」へ移行する旨が通知され、マイコン３７内の給電状態フラグ３０４をオフにする。そして、ステップＳ６８において、「スリープモード」への移行が行われる。一方、上記ステップＳ６６の判定の結果、「スリープモード」への移行指示がないと判定されたときは（ステップＳ６６でＮＯ）、上記ステップＳ６７，Ｓ６８の処理はスキップされて、以下に説明するステップＳ６９に処理が進められる。

次に、図２４のステップＳ６９において、いずれかのタスクが実行された結果、何らかのデータを受信したか否かが判定される。その結果、いずれかのタスクにおいて何らかのデータが受信されていれば（ステップＳ６９でＹＥＳ）、ステップＳ７０において、ゲーム装置１のＬＥＤ１５Ａ〜Ｃのうち少なくともいずれかを点灯させる。いわゆる「新着通知」に相当するものである。一方、何らかのデータの受信がされていないときは（ステップＳ６９でＮＯ）、ステップＳ７０の処理はスキップされて、次のステップＳ７１に処理が進められる。

次に、ステップＳ７１において、ゲーム装置１が「スリープモード」であるか否かが判定される。具体的には、給電状態フラグ３０４を参照することで判定できる。その結果、「スリープモード」であると判定されたときは（ステップＳ７１でＹＥＳ）、上記ステップＳ６２に戻り、処理が繰り返される。一方、ステップＳ７１の判定の結果、「スリープモード」ではないと判定されたときは（ステップＳ７１でＮＯ）、次に、ステップＳ７２において、所定のタスクについて即時実行する旨の指示を受けたか否かが判定される。当該判定の結果、タスクの即時実行の指示は受けていないと判定されたときは（ステップＳ７２でＮＯ）、後述のステップＳ７４に処理が進められる。一方、タスクの即時実行の指示を受けたと判定されたときは（ステップＳ７２でＹＥＳ）、ステップＳ７３において、ローカル通信用ＢＧ処理が実行される。この処理の詳細は後述するが、この流れにおける本処理の概要を簡単に説明すると、ゲーム装置１に予め登録されているＡＰへの接続を試みる処理と、接続できれば「インターネット通信」を用いたデータの送受信処理等が実行される（つまり、タスクの実行）。

次に、ステップＳ７４において、ホームボタン１４Ｉが押下されたか否かが判定される。当該判定の結果、ホームボタン１４Ｉが押下されたときは（ステップＳ７４でＹＥＳ）、上記ステップＳ６１に戻り、ホームボタン１４Ｉが押下されていないときは（ステップＳ７４でＮＯ）、上記ステップＳ６２に戻って、処理が繰り返される。以上で、起動時処理の説明を終了する。

［メニュー処理］
次に、上記ステップＳ６１で示したメニュー処理について説明する。この処理では、メニュー画面の表示やアプリケーション起動に関する処理が行われる。特に、新規にインストールされたアプリ等の「新着要素」をメニュー画面に反映して表示する処理等が行われる。また、ゲーム装置１のシステムやアプリのアップデート等に関する処理も実行される。

図２５〜図２８は、当該メニュー処理の詳細を示すフローチャートである。図２５において、まず、ステップＳ４１１で、システムインストール済みフラグ６２０がオンであるか否かが判定される。これは、後述するシステムインストール処理において、システムの更新用データがダウンロードされたか否か（システムプログラムの更新が可能か否か）を判定する為の処理である。当該判定の結果、システムインストール済みフラグ６２０がオンではないときは（ステップＳ４１１でＮＯ）、システムの更新の必要はないため、後述するステップＳ４２５に処理が進められる。

一方、システムインストール済みフラグ６２０がオンのときは（ステップＳ４１１でＹＥＳ）、次に、ステップＳ４１２において、次回更新確認時刻（システムプログラムの更新を反映させるか否かを問い合わせる時刻）が経過しているか、または、システムプログラムの更新を反映させるか否かを問い合わせる時刻として値が設定されていない（空の値となっている）かが判定される。当該判定の結果が否定であるときは（ステップＳ４１２でＮＯ）、後述するステップＳ４２５に処理が進められる。一方、当該判定の結果が肯定であるときは（ステップＳ４１２でＹＥＳ）、ゲーム装置１のシステムアップデートに関する処理が実行される。具体的には、まず、ステップＳ４１３において、システムのアップデート用データを反映するか否かをユーザに確認するための確認画面が生成され、下側ＬＣＤ１２に表示される。そして、ユーザからの指示入力を受け付ける。このような確認画面を設けるのは、次のような理由による。すなわち、システムのアップデートは、ゲーム装置１の根幹に関わる内容であるため、その内容によっては、ユーザに大きな影響を与える可能性がある。そのため、このようにユーザに確認をとるようにしている。

次に、ステップＳ４１４において、上記確認画面に対するユーザの指示内容が、アップデート用データの反映を指示する内容であるか否かが判定される。当該判定の結果、アップデートを反映しない旨の指示内容と判定されたときは（ステップＳ４１４でＮＯ）、ステップＳ４２２において、次回更新確認時刻、すなわち、ステップＳ４１３で行われた確認画面を再度表示するための時刻が２４時間後に設定される。そして、後述するステップＳ４２５に処理が進められる。すなわち、システムプログラムの更新が反映可能な状態にあるときは、更新の反映をしない旨の指示をしたとしても、更新の反映をする旨の指示を行うまで、２４時間ごとにステップＳ４１３の確認画面が表示されることとなる。

一方、ステップＳ４１４の判定の結果、反映を指示する内容であれば（ステップＳ４１４でＹＥＳ）、ステップＳ４１５において、インストールリスト５８０が参照され、システムアップデート情報５８３に含まれるシステムの構成要素５８４の全てについて、以下に説明する反映の処理が行われたか否かが判定される。その結果、まだ未反映の構成要素５８４が残っているときは（ステップＳ４１５でＮＯ）、ステップＳ４１６において、未反映の構成要素５８４のうちのいずれか一つが選択される、次に、ステップＳ４１７において、当該選択されている構成要素は、既存の構成要素を置き換えるものではないか否か、つまり、新規導入か、あるいは既存の構成要素のアップデートかが判定される。当該判定の結果、既存の構成要素の置き換えではない（新規導入）であるときは（ステップＳ４１７でＮＯ）、ステップＳ４１８において、オン・ザ・フライ用キャッシュ６００に格納されている更新用のファイルをシステムプログラム領域５１５に移動する（元のファイルと置き換える）ことで、当該構成要素の更新が反映される。すなわち、上述の「移動型」のアップデートが行われる。その後、上記ステップＳ４１５に戻り、処理が繰り返される。一方、既存の構成要素の置き換えにあたるとき（つまり、構成要素のアップデートのとき）は（ステップＳ４１７でＹＥＳ）、ステップＳ４１９において、図示しないレジストリ情報が参照され、当該構成要素についての上記「実体プログラムへの参照情報」を、更新前のファイル名から上記ダウンロードされた更新用のファイル名を指し示すように変更することで、当該構成要素の更新が反映される。更に、「実体プログラムへの参照情報」の変更が終われば、更新前のファイルについては削除される（なお、更新前のファイルについては削除せずに、システムのロールバックが可能なようにＮＡＮＤフラッシュメモリ３３内の所定の領域に保存しておいてもよい）。そして、上記ステップＳ４１５に処理が戻される。

一方、上記ステップＳ４１５の判定の結果、インストールリスト５８０で示されているシステムの構成要素５８４の全てについて上記のような反映の処理が実行されたと判定されたときは（ステップＳ４１５でＹＥＳ）、ステップＳ４２０において、システムインストール済みフラグ６２０がオフに設定される。次に、ステップＳ４２１において、メニューの再起動のための処理が実行され、その結果、上記ステップＳ４１１の処理に戻ることになる。

次に、上記ステップＳ４１１の判定の結果、システムインストール済みフラグがオンではないときの処理（ステップＳ４１１でＮＯ）について説明する。この場合は、ステップＳ４２５において、ＮＡＮＤフラッシュメモリ３３のアプリ関連データ５５０が参照され、ゲーム装置１にインストールされている全てのアプリケーションについて、以下に説明するような処理（アプリケーションのスキャン）が行われたか否かが判定される。当該判定の結果、未処理のアプリケーションが残っていると判定されたときは（ステップＳ４２５でＮＯ）、次に、未処理のアプリケーションの中からいずれか一つが処理対象として選択され（以下、スキャン対象アプリと呼ぶ）、ステップＳ４２６において、当該スキャン対象アプリが新規にインストールされたアプリケーションであるか、すなわち、まだメニューに登場させたことがないアプリケーション（以下、新規アプリと呼ぶ）であるか否かが判定される。これは、上記アプリ関連データ５５０が参照され、スキャン対象アプリに該当するアプリケーション領域の新規インストールフラグ５５４がオンに設定されているか否かで判定される。なお、アプリケーションを新規にインストールする処理は、当該メニュー処理とは別個独立の処理として、当該メニュー処理と並列する形で実行されている。当該アプリケーションのインストール処理については後述する。

当該判定の結果、新規アプリではないと判定されたときは（ステップＳ４２６でＮＯ）、ステップＳ４２９において、当該スキャン対象アプリに対応するアイコンが生成されてメニュー画面上に適宜配置される。一方、スキャン対象アプリが新規アプリであると判定されたときは（ステップＳ４２６でＹＥＳ）、次に、ステップＳ４２７において、スキャン対象アプリが、今回表示されるメニューにおいて１つめの新規アプリ（１番最初にスキャンされた新規アプリ）に該当するか否かが判定される。当該判定の結果、今回表示されるメニューにおいて１つめの新規アプリであるときは、ステップＳ４２８において、上記図５で示したようなプレゼントアイコン１１２が生成されて、メニュー画面上に適宜配置される。一方、スキャン対象アプリが、２つめ以降の新規アプリ（２番目以降にスキャンされた新規アプリ）に該当する場合は（ステップＳ４２７でＮＯ）、上記ステップＳ４２８の処理はスキップされて、後述のステップＳ４３０に処理が進められる。このような処理が行われる結果、複数の新規アプリがダウンロード及びインストールされた場合、これらの新規アプリについては一度に全てを表示するのではなく、メニューが表示される度に一つずつ表示していくことになる。例えば、２つの新規アプリを取得した場合、取得後の１回目のメニュー表示ではいずれか一方のアプリがプレゼントアイコンとして表示され、他方はこの時点ではまだメニューに表示されない。その後、当該プレゼントアイコンが選択され、１つめの新規アプリが実行され、当該アプリが終了されてメニュー画面に戻ったとき、つまり、２回目のメニュー表示が実行されたときに、上記もう一つの新規アプリがプレゼントアイコンとして表示されることになる。これにより、メニューが表示される度に新しいプレゼントアイコンが表示され、新規アプリ取得の楽しさを持続してユーザに与えることが可能となる。

次に、ステップＳ４３０において、当該スキャン対象アプリ用のデータ（例えば、お知らせの通知や追加コンテンツ等）が受信されたか否かが判定される。これは、例えば、上記アプリケーション領域５５１内のタスク受信キャッシュ５５３、あるいは、当該スキャン対象アプリに対応付けられているすれ違い通信用データ５２０の受信用ボックス５２４が参照されることで判定される（いずれか一方でも良いし、双方を参照して判定しても良い）。当該判定の結果、新規に受信したデータがあると判定されたときは（ステップＳ４３０でＹＥＳ）、ステップＳ４３１において、当該スキャン対象アプリに対応するアイコンの近傍に、上記図６で示したような「Ｎｅｗ！」マークが配置される。そして、上記ステップＳ４１１に戻る。一方、ステップＳ４３０の判定の結果、新規に受信したデータがないと判定されたときは（ステップＳ４３０でＮＯ）、ステップＳ４３１の処理はスキップされて、上記ステップＳ４１１の処理に戻る。

次に、上記ステップＳ４２５において、全てのアプリケーションについて処理済み（スキャン済み）と判定されたとき（ステップＳ４２５でＹＥＳ）の処理について説明する。この場合は、ステップＳ４３２において、アプリ更新適用処理が実行される。図３２は、上記ステップＳ４３２で示したアプリ更新適用処理の詳細を示すフローチャートである。図３２において、まず、ステップＳ６０１で、アプリ関連データ５５０が参照され、新規アップデートフラグ５５９がオンに設定されているアプリがリストアップされる。

次に、ステップＳ６０２で、上記リストアップされたアプリが１以上あるか否かが判定される。その結果、１以上ないときは（ステップＳ６０２でＮＯ）、アプリの更新はないことになるため、当該アプリ更新適用処理は終了する。

一方、リストアップされたアプリが１以上あると判定されたときは（ステップＳ６０２でＹＥＳ）、ステップＳ６０３において、アプリの更新を反映するか否かをユーザに確認するための確認画面が生成され、下側ＬＣＤ１２に表示される。そして、ユーザからの指示入力が受け付けられる。

次に、ステップＳ６０４において、上記確認画面に対するユーザの指示内容が更新の反映を指示する内容であるか否かが判定される。その結果、更新を指示する内容ではないときは（ステップＳ６０４でＮＯ）、ステップＳ６０５で、上記別のファイル名で格納されたアプリの更新用のファイルが破棄される。なお、詳細は後述するが、アプリのアップデートの場合、ダウンロードされたアップデートファイルは、プログラム領域５００に、別のファイル名で格納されている。そして、当該アプリ更新適用処理は終了する。

一方、更新反映を指示する内容のときは（ステップＳ６０４でＹＥＳ）、次に、ステップＳ６０６において、上記リストアップされたアプリの全てについて、以下に示すような更新反映処理が実行されたか否かが判定される。その結果、まだ反映されていないアプリがあるときは（ステップＳ６０６でＮＯ）、ステップＳ６０７で、上記リストアップされているアプリのうち、未反映のアプリの中から一つが選択される。続くステップＳ６０８において、当該未反映のアプリについてのレジストリ情報が変更されることで、アプリの更新が行われる。具体的には、図示しないレジストリ情報が参照され、当該アプリについての「実体プログラムへの参照情報」が、上記別のファイル名で格納された更新用のファイル名を指し示すように変更されることで、アプリの更新が反映される。そして、上記ステップＳ６０６の処理に戻る。

一方、ステップＳ６０６の判定の結果、リストアップされたアプリの全てについて更新を反映したときは（ステップＳ６０６でＹＥＳ）、当該アプリ更新適用処理は終了する。

図２６に戻り、アプリ更新適用処理が終われば、次に、アプリケーションの起動・実行に関する処理が行われる。具体的には、まず、図２７のステップＳ４３３において、メニュー画面からいずれかのアプリケーションを示すアイコンが選択されたか否かが判定される。例えば、上記図４に示したようなメニュー画面でユーザが所定のアイコンに対してタッチ操作したか否かが判定される。当該判定の結果、メニュー画面上のいずれのアプリケーション（のアイコン）も選択されていないと判定されたときは（ステップＳ４３３でＮＯ）、後述するステップＳ４４３に処理が進められる。

一方、メニュー画面上のいずれかのアプリケーション（のアイコン）が選択されたと判定されたときは（ステップＳ４３３でＹＥＳ）、次に、ステップＳ４３４において、選択されたアプリケーションに対応する新規インストールフラグ５５４がオンに設定されているか否かが判定される。つまり、新規にインストールされたアプリケーションか否かが判定される。その結果、新規インストールフラグ５５４がオンに設定されていると判定されたときは（ステップＳ４３４でＹＥＳ）、当該アプリケーションに対応するアイコンは上記プレゼントアイコン１１２として表示されていることになるため、ステップＳ４３５において、当該プレゼントアイコン１１２が、当該アプリケーションのアイコンとして本来定義されているアイコン（アプリケーションプログラムの一部として記憶されている）に変更される。このとき、プレゼントアイコン１１２の箱が開くようなアニメーション表示も行われる。

次に、ステップＳ４３６において、当該アプリケーションについての新規インストールフラグ５５４がオフに設定されて、上記ステップＳ４３３に戻る。

一方、上記ステップＳ４３４の判定の結果、新規インストールフラグがオフに設定されていると判定されたときは（ステップＳ４３４でＮＯ）、次に、選択されたアプリの起動に際してのアプリの正当性チェックが行われる。具体的には、ステップＳ４３７において、選択中のアプリに対応する権利情報が権利情報データベース６１０から読み出される。次に、ステップＳ４３８において、当該読み出された権利情報の検証が行われる。この処理は、何らかの原因でインストールされた不正なアプリケーションが実行されることを防ぐための処理である。次に、ステップＳ４３９において、当該権利情報の検証が成功したか否かが判定される。成功したときは（ステップＳ４３９でＹＥＳ）、ステップＳ４４０において、プレイ履歴６７０に当該アプリの起動時刻を記録する処理が行われる。具体的には、選択されたアプリのアプリＩＤ５５２と対応付けて、アプリのバージョン情報とそのときの時刻（起動時刻）がプレイ履歴６７０に記録される。

次に、ステップＳ４４１において、選択されたアプリケーションにかかる処理（以下、「各アプリの処理」と呼ぶ）が実行される。ここで、当該アプリの起動に際して、上記権利情報データベース６１０が参照され、起動しようとするアプリに対応する権利情報が取得される。そして、当該権利情報を用いた認証処理が行われ、認証が成功したときにのみ、アプリの実行が開始される。その後、当該アプリケーションにかかる処理が終了すれば、ステップＳ４４２において、アプリの終了時刻をプレイ履歴６７０に記録するための処理が実行される。すなわち、当該実行されたアプリのアプリＩＤ５５２と対応付けて、当該アプリのバージョン情報とこの時点の時刻（終了時刻）が、プレイ履歴６７０に記録される。その後、上記ステップＳ４１１に処理が戻される。

一方、上記ステップＳ４３９の判定の結果、成功しなかったときは（ステップＳ４３９でＮＯ）、ステップＳ４４０〜Ｓ４４２の処理はスキップされ、上記ステップＳ４１１に戻る。すなわち、選択されたアプリケーションは起動しないことになる。

次に、上記ステップＳ４３３の判定の結果、いずれのアプリも選択されていないと判定されたときの処理（ステップＳ４３３でＮＯ）について説明する。このときは、アプリケーションの削除（アンインストール）に関する処理が実行される。まず、図２８のステップＳ４４３において、ソフト管理用の画面の起動を指示する操作が行われたか否かが判定される（なお、厳密には当該ソフト管理用のプログラムもアプリの一種として実現されていてもよいが、ここでは説明の便宜のため、上記ステップＳ４３３の判定対象には当該ソフト管理用のアプリは含まないものとする）。

当該判定の結果、ソフト管理用の画面の起動が指示されなかったときは（ステップＳ４４３でＮＯ）、上記ステップＳ４１１に戻り、処理が繰り返される。一方、ソフト管理用の画面の起動が指示されたときは（ステップＳ４４３でＹＥＳ）、ステップＳ４４４において、ＮＡＮＤフラッシュメモリ３３に格納されているアプリの一覧が生成されて表示される。この一覧は、ＮＡＮＤフラッシュメモリ３３に格納されているアプリをスキャンすることで生成される。その後、ユーザからの入力を受け付ける。

次に、ステップＳ４４５において、上記アプリの一覧から、ユーザが何れかのアプリの削除を指示したか否かが判定される。その結果、削除の指示があるときは（ステップＳ４４５でＹＥＳ）、ステップＳ４４６において、選択されたアプリと、これに対応する権利情報、および、アプリ関連データ５５０内の対応するアプリのアプリケーション領域５５１の情報や、その他当該アプリに関連するデータ（メタデータ等）が削除される。更に、ステップＳ４４７において、当該削除されたアプリを示すアプリＩＤ５５２を削除履歴６６０に追加することで、削除履歴６６０が更新される。これにより、一度（ユーザの意思によって）削除されたアプリについては、それ以降、自動的にインストールされることを防ぐ事が可能となる。ステップＳ４４７の処理が終われば、後述のステップＳ４４８に処理が進められる。

一方、ステップＳ４４５の判定の結果、削除指示がなかったときは（ステップＳ４４５でＮＯ）、上記ステップＳ４４６，Ｓ４４７の処理はスキップされる。

次に、ステップＳ４４８において、メニューに戻る旨の指示がユーザにより指示されたか否かが判定される。その結果、メニューに戻る指示が行われていないときは（ステップＳ４４８でＮＯ）、上記ステップＳ４４４に戻り、メニューに戻る指示が行われたときは（ステップＳ４４８でＹＥＳ）、上記ステップＳ４１１に戻る。

以上で、本体メニュー処理の説明を終了する。

［アプリケーションインストール処理］
ここで、上述したメニュー処理と並行して実行されるアプリケーションインストール処理について説明する。この処理は、メニュー処理とはまた別個の処理として、ゲーム装置１の稼働中は所定の周期で繰り返し実行されている。

図２９〜図３０は、当該アプリのインストール処理の詳細を示すフローチャートである。まず、ステップＳ４６０で、アプリインストール必要フラグ６３０がオンに設定されているか否かが判定される。その結果、オンに設定されていないときは（ステップＳ４６０でＮＯ）、アプリをインストールする必要がないことを示しているため、当該アプリインストール処理は終了する。

一方、アプリインストール必要フラグ６３０がオンのときは（ステップＳ４２３でＹＥＳ）、すなわち、システム更新の反映が終わっていることを示しているので、下記により示される、アプリのダウンロード及びインストールの処理に移る。ステップＳ４６１において、インストールリスト５８０に含まれているアプリ情報５８９で示されるアプリの全てについて、以下に説明するようなダウンロードタスク（ＤＬタスク）の生成処理が行われたか否かが判定される。当該判定の結果、まだＤＬタスクの生成処理がなされていないアプリが残っているときは（ステップＳ４６１でＮＯ）、ステップＳ４６２において、インストールリストに含まれているアプリ情報５８９のうち、まだＤＬタスク生成処理が未処理のアプリ情報５８９が一つ選択される。

次に、ステップＳ４６３において、選択されたアプリ情報５８９のレーティング情報５９３が参照され、当該アプリの対象年齢情報が取得される。次に、ステップＳ４６４において、選択されたアプリの対象年齢と、ゲーム装置１に登録されているユーザの年齢（これは、本体設定データ５６０に記憶されている）とが比較され、年齢制限と整合するか否かが判定される。例えば、レーティング情報５９３で１８才以上のみを対象とするアプリであることが示されている場合は、本体設定データ５６０に登録されているユーザの年齢が１８才以上であるか否かが判定される。当該判定の結果、年齢制限と整合していないときは（ステップＳ４６４でＮＯ）、現在選択中のアプリについてはＤＬタスク生成処理は処理済みにして、上記ステップＳ４６１に戻って処理が繰り返される。

一方、ステップＳ４６４の判定の結果、年齢制限と整合しているときは（ステップＳ４６４でＹＥＳ）、続くステップＳ４６５において、選択中のアプリが、いわゆる「体験版」であって、かつ、選択中のアプリの「製品版」を既に所有しているか否か（インストール済みであるか否か）が判定される。これは、既に「製品版」のアプリを所持しているにもかかわらず、「体験版」がダウンロードされてしまうことを防ぐためである。当該判定の結果、選択中のアプリが「体験版」であって、同アプリの「製品版」を既に有していると判定されたときは（ステップＳ４６５でＹＥＳ）、現在選択中のアプリについてＤＬタスク生成処理は処理済みとして、上記ステップＳ４６１に戻って処理が繰り返される。

一方、選択中のアプリが「体験版」であって、同アプリの「製品版」を有している状態ではないと判定されたときは（ステップＳ４６５でＮＯ）、次に、ステップＳ４６６において、同じアプリが既に所持されているか否かが判定される。これは、例えば、プレイ履歴６７０に上記選択したアプリのアプリＩＤ５９０と同じアプリＩＤが存在するか否かで判定される。当該判定の結果、同じアプリを所持していないと判定されたときは（ステップＳ４６６でＮＯ）、ステップＳ４６７において、削除履歴６６０が参照され、当該削除履歴６６０に上記選択されたアプリのアプリＩＤが載っているか否かが判定される。その結果、削除履歴６６０に当該アプリのアプリＩＤが載っているときは（ステップＳ４６７でＹＥＳ）、上記ステップＳ４６１に処理が戻される。これにより、以前にユーザの意思で削除されたアプリについて、再度自動的にインストールされることを回避している。一方、削除履歴６６０に当該アプリのアプリＩＤが載っていないときは（ステップＳ４６７でＮＯ）、後述するステップＳ４６９に処理が進められる。

一方、上記ステップＳ４６６の判定の結果、同じアプリを所持していると判定されたときは（ステップＳ４６６でＹＥＳ）、ステップＳ４６８において、同じアプリであって古いバージョンのものを所持しているか否かが判定される。この判定は、例えば、プレイ履歴６７０が参照され、古いバージョンのアプリＩＤがあるか否かで判定される。その結果、所持していないと判定されたときは（ステップＳ４６８でＮＯ）、既に最新のバージョンのものがインストール済みであると考えられるため、上記ステップＳ４６１に処理が戻される。

一方、同じアプリであって古いバージョンのものを所持していると判定されたときは（ステップＳ４６８でＹＥＳ）、当該アプリのバージョンアップ（アップデート）を行うため、次のステップＳ４６９に処理が進められる。

ステップＳ４６９においては、上記選択されたアプリについて、これをダウンロードするためのプレイ履歴条件が設定されているか否かが判定される。つまり、選択されたアプリが「特典アプリ」であるか否かが判定される。これは、上述したように、例えば、あるゲームを所定時間以上プレイした場合の「特典」として、特典アプリをダウンロードさせるような場合を想定したものである。この判定は、上記インストールリスト５８０のアプリ情報５８９が参照され、ダウンロード条件情報５９５に何らかの条件情報が設定されているか否かで判定される。当該判定の結果、プレイ履歴条件が設定されていないと判定されたときは（ステップＳ４６９でＮＯ）、選択されたアプリは、ダウンロードに際して特に条件が定められていないアプリであると考えられるため、後述するステップＳ４７１に処理が進められる。

一方、プレイ履歴条件が設定されていると判定されたときは（ステップＳ４６９でＹＥＳ）、選択されたアプリは「特典アプリ」であるため、次のステップＳ４７０において、当該特典アプリをダウンロードするためのプレイ履歴条件が満たされているか否かが判定される。この判定は、上記プレイ履歴６７０とダウンロード条件情報５９５とが比較されることで判定される。当該判定の結果、ダウンロードするためのプレイ履歴条件が満たされていないと判定されたときは（ステップＳ４７０でＮＯ）、現在選択中のアプリについてＤＬタスク生成処理は処理済みにして上記ステップＳ４６１に戻り、処理が繰り返される。一方、プレイ履歴条件が満たされていると判定されたときは（ステップＳ４７０でＹＥＳ）、次のステップＳ４７１に処理が進められる。なお、ステップＳ４６５において判定した、製品版を所持していれば体験版をインストールしない処理は、ステップＳ４７０の処理によっても実現できる。すなわち、体験版のアプリケーションに関するダウンロード条件情報５９５に、製品版のプレイ履歴が存在していればインストールを行うという条件を設定しておけばよい。

次に、これからダウンロードしようとするアプリの正当性（正規のプログラムであるか否か）をチェックするための処理が実行される。具体的には、まず、ステップＳ４７１において、選択したアプリに対応する権利情報を所定のサーバからダウンロードする。当該権利情報は、当該アプリの実行に際して認証処理を行うために用いられる情報である。なお、当該権利情報のダウンロードに関しては、上述したようなタスクは用いずに、直接・即時にダウンロードが行われる。

次に、ステップＳ４７２において、当該権利情報の正当性確認処理が実行される。図３１は、上記ステップＳ４７２で示した正当性確認処理の詳細を示すフローチャートである。図３１において、まず、ステップＳ４９１で、上記ダウンロードした権利情報の正当性を確認する処理が実行される。これは、例えば、いわゆる電子署名や電子証明書を確認する処理によって実現される。

次に、ステップＳ４９２において、権利情報の正当性に問題がなかったか否か（つまり、正規のアプリであるか否か）が判定される。その結果、問題が無いときは（ステップＳ４９２でＹＥＳ）、ステップＳ４９３において、ダウンロードした権利情報が権利情報データベース６１０に登録される。一方、問題があったときは（ステップＳ４９２でＮＯ）、ステップＳ４９４において、ダウンロードした権利情報、および、この権利情報に対応するアプリが破棄される。以上で、正当性確認処理は終了する。

図３０に戻り、正当性確認処理の次に、ステップＳ４７３において、当該正当性確認処理の結果、正当性に問題がなかったか否かが判定される。すなわち、上述の図３１のステップＳ４９３において権利情報が権利情報データベース６１０に登録されたか否かが判定される。その結果、問題が無いと判定されたときは（ステップＳ４７３でＹＥＳ）、ステップＳ４７４において、選択されたアプリをダウンロードするためのダウンロード用のタスク（受信タスク）が生成される。ここで生成されるタスクについては、上記インストールリスト５８０において当該アプリに対応するアプリ情報５８９に含まれている優先順位５９４の値に沿って、実行優先度が設定される。その後、上記ステップＳ４６１に戻って処理が繰り返される。

一方、ステップＳ４７３の判定の結果、正当性に問題があったと判定されたときは（ステップＳ４７３でＮＯ）、上記ステップＳ４７４の処理は行われずに、上記ステップＳ４６１に戻って処理が繰り返される。

次に、図２９に戻り、上記ステップＳ４６１の判定の結果、インストールリスト５８０に含まれているアプリ情報５８９で示されるアプリの全てについて上述したような処理が行われたと判定されたときの処理について説明する（ステップＳ４６１でＹＥＳ）。このときは、図３０のステップＳ４７５において、上記アプリをダウンロードするために生成されたダウンロード用の各タスクを実行するために、タスク実行処理が行われる。当該タスク実行処理の詳細については後述するが、この処理が実行されることによって、上記各アプリのプログラムファイルが所定のサーバからダウンロードされ、ＮＡＮＤフラッシュメモリ３３内に格納された状態となる。

ステップＳ４７５の処理が終われば、次に、ステップＳ４７６において、アプリインストール必要フラグ６３０がオフに設定される。以上で、アプリインストール処理は終了する。

［各アプリの処理］
次に、上記ステップＳ４４１で示した各アプリの処理について説明する。なお、各アプリケーションの具体的な処理内容は当然のことながらそれぞれ異なる。そのため、この点に関しての説明は省略し、本実施形態に関する部分、すなわち、上記タスクに関する処理や上述した各種通信に関連する処理について、その最大公約数的な処理内容、すなわち、どのアプリケーションにおいても普遍的に行われると思われる処理として説明する。

図３３〜図３４は、上記各アプリの処理の詳細を示すフローチャートである。図３３において、まず、ステップＳ１２１で、何らかのタスクが実行された結果として、タスク受信キャッシュ５５３に、新たに受信した本アプリケーション用のデータが存在するか否かが判定される。当該判定の結果、当該新たに受信したデータがあると判定されたときは（ステップＳ１２１でＹＥＳ）、ステップＳ１２２において、タスク受信キャッシュ５５３のデータが、本アプリケーションのセーブデータ５５５のタスク受信データ５５７に移動される（その結果、タスク受信キャッシュ５５３は空になる）。その後、ステップＳ１２３に処理が進められる。一方、新たに受信したデータがないと判定されたときは（ステップＳ１２１でＮＯ）、ステップＳ１２２の処理はスキップされて、ステップＳ１２３に処理が進められる。

次に、ステップＳ１２３において、本アプリケーションに対応付けられているすれ違い通信用データ５２０の受信用ボックス５２４に新規に受信されたデータが存在するか否かが判定される。当該判定の結果、受信用ボックス５２４に新規に受信されたデータがあると判定されたときは（ステップＳ１２３でＹＥＳ）、ステップＳ１２４において、当該受信用ボックス５２４内のデータが本アプリケーションのセーブデータ５５５のすれ違い受信データ５５８に移動される（その結果、受信ボックス５２４は空になる）。そして、ステップＳ１２５に処理が進められる。一方、受信用ボックス５２４に新規に受信されたデータはないと判定されたときは（ステップＳ１２３でＮＯ）、上記ステップＳ１２４の処理はスキップされて、ステップＳ１２５に処理が進められる。

次に、ステップＳ１２５において、各アプリケーションの内容に応じた各種情報処理が実行される。例えば、ゲーム処理やお絵かきソフト処理、カメラアプリケーション処理等である。この情報処理において、ステップＳ１２２やステップＳ１２４において新たに移動されたタスク受信データ５５７やすれ違い受信データ５５８のデータを利用することができる。

次に、ステップＳ１２６において、上記ステップＳ１２５における各種情報処理の結果、タスクを新たに追加するイベント、あるいは、タスクの内容を更新するイベントが発生したか否かが判定される。その結果、当該イベントが発生していないと判定されたときは（ステップＳ１２６でＮＯ）、後述するステップＳ１３２に処理が進められる。

一方、タスクの新規追加、あるいはタスクの更新のイベントが発生したと判定されたときは（ステップＳ１２６でＹＥＳ）、次に、ステップＳ１２７において、当該発生したイベントにかかる内容が、「送信タスク」に関するものか「受信タスク」に関するものかが判定される。当該判定の結果、「送信タスク」の追加、あるいは更新という内容と判定されたときは（ステップＳ１２７でＹＥＳ）、続くステップＳ１２８において、送信すべきデータが作成され、セーブデータ５５５のタスク送信用データ５５６として記憶される。更に、ステップＳ１２９において、「送信タスク」用の各種パラメータが設定される。ここで設定されるパラメータは、上記図１６で示したようなタスク設定５３１を構成する各項目を設定するためのパラメータである。
具体的には、以下のようなパラメータ設定が行われる。
（１）アプリＩＤ→本アプリケーションのＩＤ
（２）タスクＩＤ→タスクの新規追加の場合は新規な値、更新の場合は更新しようとするタスクのタスクＩＤと同じ値
（３）実行優先度→任意の値
（４）通信先ＵＲＬ→送信先のサーバのＵＲＬ
（５）ファイルパス→上記タスク送信用データ５５６の位置を示す値
（６）次回実行時刻→任意の値
（７）実行間隔→任意の値
（８）送信／受信識別フラグ→「送信」を表す値
（９）消尽回数→任意の値
上記のようなパラメータ設定が行われた後、後述するステップＳ１３１に処理が進められる。

一方、上記ステップＳ１２７の判定の結果、発生したイベントにかかる内容が「受信タスク」に関するものであると判定されたときは（ステップＳ１２７でＮＯ）、ステップＳ１３０において、「受信タスク」用の各種パラメータが設定される。当該処理は、上記ステップＳ１２９と同様にタスク設定５３１の各項目の設定用パラメータを設定する処理である。具体的には、以下のようなパラメータ設定が行われる。
（１）アプリＩＤ→本アプリケーションのＩＤ
（２）タスクＩＤ→タスクの新規追加の場合は新規な値、更新の場合は更新しようとするタスクのタスクＩＤと同じ値
（３）実行優先度→任意の値
（４）通信先ＵＲＬ→受信元となるサーバのＵＲＬ
（５）ファイルパス→受信したデータの格納先（タスク受信キャッシュ５５３）を示す値
（６）次回実行時刻→任意の値
（７）実行間隔→任意の値
（８）送信／受信識別フラグ→「受信」を表す値
（９）消尽回数→任意の値
上記のようなパラメータ設定が行われた後、後述するステップＳ１３１に処理が進められる。

次に、ステップＳ１３１において、上記設定されたパラメータに基づくタスクの新規追加あるいは既存タスクの更新を行うための、タスク生成処理が実行される。図３５は、上記ステップＳ１３１で示したタスク生成処理の詳細を示すフローチャートである。図３５において、まず、ステップＳ１５１で、上記パラメータの各項目に基づいて、作業用のタスク設定データが生成される。当該作業用のタスク設定データは、メインメモリ３２に生成される一時的なデータであり、上記タスク設定５３１と同じデータ構造を有する。なお、任意の項目であってパラメータの指定がなされていない項目については、初期値として設定されている値が設定される。

次に、ステップＳ１５２において、当該作業用のタスク設定データのアプリＩＤおよびタスクＩＤが、上記タスクデータ５３０に格納されているタスク設定５３１のいずれかのアプリＩＤ５３２およびタスクＩＤ５３３と重複しているか否かが判定される。つまり、新規追加のタスクであるか、既にあるタスクの更新になるかが判定される。当該判定の結果、重複するＩＤがあれば（ステップＳ１５２でＹＥＳ）、ステップＳ１５３において、当該重複するタスク設定５３１の内容が上記作業用のタスク設定データで置き換えられる（つまり、更新される）。一方、重複するＩＤが存在しないと判定されたときは（ステップＳ１５２でＮＯ）、ステップＳ１５４において、上記作業用のタスク設定データが新規のタスク設定５３１として、タスクデータ５３０に追加登録される。そして、作業用のタスクデータが消去されて、当該タスク生成処理は終了する。

図３３に戻り、ステップＳ１３１の処理が終われば、次に、図３４のステップＳ１３２において、上記ステップＳ１２５の各種情報処理によって、「すれ違い通信」を用いた送信に関するイベントが発生したか否かが判定される。例えば、上記各種情報処理において、「すれ違い通信」を用いて何らかのデータを送信するための指示がユーザからなされたか否か等が判定される。当該判定の結果、「すれ違い通信」を用いて何らかのデータを送信する旨のイベントが発生したと判定されたときは（ステップＳ１３２でＹＥＳ）、ステップＳ１３３において、まず、上記イベント内容に応じた送信用のデータが適宜生成される。そして、上記すれ違い通信用データ５２０の中の、本アプリケーションに対応するスロット５２１の送信用ボックス５２３に、当該生成された送信用のデータが格納される。そして、後述のステップＳ１３４に処理が進められる。一方、上記ステップＳ１３２の判定の結果、上記イベントが発生していないと判定されたときは（ステップＳ１３２でＮＯ）、ステップＳ１３３の処理はスキップされて、ステップＳ１３４に処理が進められる。

次に、ステップＳ１３４において、サーバから受信したデータが在るか否かが判定される。つまり、「受信タスク」の実行によって何らかの新規なデータが受信されたか否かが判定される（そのため、上記ステップＳ１２１の判定でＹＥＳと判定されたときは、当該判定においてもＹＥＳと判定されることになる）。例えば、サーバから新規のデータが受信されていれば、上記ステップＳ１２２でセーブデータ５５５に移動されているため、当該セーブデータ５５５が参照されることで、当該判定が行われる。

当該判定の結果、サーバから受信した新規なデータがないと判定されたときは（ステップＳ１３４でＮＯ）、後述するステップＳ１４２に処理が進められる。一方、サーバから受信した新規なデータがあると判定されたときは（ステップＳ１３４でＹＥＳ）、次に、ステップＳ１３５において、当該受信したデータの中に、現在実行されているアプリに関するネットワークサービスの終了を知らせる旨の通知が含まれているか否かが判定される。その結果、サービス終了の旨の通知が含まれていないと判定されたときは（ステップＳ１３５でＮＯ）、後述するステップＳ１４１に処理が進められる。

一方、サービス終了の旨の通知が含まれていると判定されたときは（ステップＳ１３５でＹＥＳ）、ステップＳ１３６において、サービス終了の旨が上側ＬＣＤ２２あるいは下側ＬＣＤ１２に表示される。次に、ステップＳ１３７において、現在実行されているアプリケーションのアプリＩＤ５３２を含むタスク設定５３１がタスクデータ５３０内に残っているか否かが判定される。残っていると判定されたときは（ステップＳ１３７でＹＥＳ）、現在実行されているアプリケーションのアプリＩＤ５３２を含むタスク設定５３１が全て消去される。一方、残っていないと判定されたときは（ステップＳ１３７でＮＯ）、上記ステップＳ１３８の処理はスキップされる。

次に、ステップＳ１３９において、すれ違い通信用データ５２０が参照されて、現在実行されているアプリケーションのアプリＩＤ５２２が割り当てられているスロット５２１があるか否かが判定される。残っていると判定されたときは（ステップＳ１３９でＹＥＳ）、ステップＳ１４０において、現在実行されているアプリケーションに対応するスロット５２１の内容をクリアする。その結果、当該スロット５２１と当該アプリケーションとの対応付けが解除される。一方、上記のようなスロットは残っていないと判定されたときは（ステップＳ１３９でＮＯ）ステップＳ１４０の処理はスキップされる。

次に、ステップＳ１４１において、必要に応じて、上記受信された新規なデータの内容を表示する処理が実行される。

次に、ステップＳ１４２において、当該実行中のアプリケーション処理の終了条件が満たされたか否かが判定される。その結果、終了条件が満たされていなければ（ステップＳ１４２でＮＯ）、上記ステップＳ１２１に戻り、処理が繰り返される。終了条件が満たされていれば（ステップＳ１４２でＹＥＳ）、本アプリ処理は終了される。以上で、各アプリの処理の説明を終了する。

［ローカル通信用ＢＧ処理］
次に、上述したような各処理において適宜呼び出されていたローカル通信用ＢＧ処理（具体的には、図２０のステップＳ４、図２１のステップＳ２８およびＳ３４、図２２のステップＳ４０、図２４のステップＳ７３）について説明する。この処理では、主に、上記「すれ違い通信」における送受信処理と、上記所定のＡＰのスキャンや当該ＡＰとの接続処理等の制御が行われる。また、所定のＡＰと接続した際には、上記「インターネット通信」等を行うための処理である「インターネット用ＢＧ処理」が適宜呼び出される。

図３６〜図３７は、当該ローカル通信用ＢＧ処理の詳細を示すフローチャートである。まず、ステップＳ１６１において、無線通信モジュール３４がすれ違い接続応答を受信しているか否かが判定される。これは、例えば、ＣＰＵ３１が無線通信モジュール３４に対して、すれ違い接続応答を受信したか否かを問い合わせするような処理によって判定される。当該判定の結果、上記すれ違い接続応答を受信していないと判定されたときは（ステップＳ１６１でＮＯ）、後述するステップＳ１６７に処理が進められる。一方、上記すれ違い接続応答を受信していると判定されたときは（ステップＳ１６１でＹＥＳ）、自ゲーム装置１が発した要求に対して、応答可能な（ローカル通信のための接続が確立した）他のゲーム装置１が存在しているということになる（上記図２１のステップＳ２８では、この流れに来ることになる）。そのため、次のステップＳ１６２において、当該通信相手となった他のゲーム装置１に対して、すれ違い通信用データ５２０の送信用ボックス５２３のデータが送信される。但し、上記のように、送信されるデータは、上記アプリＩＤ５２２が、通信相手のすれ違い通信用データ５２０のものと一致したスロット５２１にかかるデータに限る。

次に、ステップＳ１６３において、送信時刻、および、当該通信相手である他のゲーム装置１のＭＡＣアドレスが無線通信モジュール３４内の既通信端末／専用ＡＰ情報４０５に記憶される。

次に、ステップＳ１６４において、すれ違い通信における「受信」の処理が行われたか否かが判定される。本実施形態では、すれ違い通信は原則として「送信」と「受信」がセットで行われる。そのため、この判定では、両方とも済んだのか、一方だけしか済ませていないのかが判定されることになる。当該判定の結果、受信処理がまだ行われていないと判定されたときは（ステップＳ１６４でＮＯ）、後述するステップＳ１７０の処理に進み、通信相手から送られてくるデータの受信が行われる。

一方、既に受信処理は行われたと判定されたときは（ステップＳ１６４でＹＥＳ）、ステップＳ１６５において、今回の通信（この通信とは、「ローカル通信」だけでなく、後述の「インターネット通信」も含む）を行うために「スリープモード」が解除されていたのか否かが判定される。当該判定の結果、今回の通信のために「スリープモード」が解除されていたと判定されたときは（ステップＳ１６５でＹＥＳ）、今回の通信前は「スリープモード」の状態であったと考えられるため、この状態に戻すために、ステップＳ１６６において、ＣＰＵ３１に給電を停止するための命令がＣＰＵ３１自身から送られ、「スリープモード」に移行するための処理が実行されるとともに、マイコン３７内の給電状態フラグ３０４をオフにし、電源管理ＩＣ４１にスリープへ移行する旨を通知する。一方、ステップＳ１６５の判定の結果、今回の通信のために「スリープモード」が解除されていたのではないと判定されたときは（ステップＳ１６５でＮＯ）、元々「通常電力モード」で稼働している状態であったと考えられるため、ステップＳ１６６の処理はスキップされる。そして、当該ローカル通信用ＢＧ処理は終了する。

次に、上記ステップＳ１６１の判定の結果、上記すれ違い接続応答を受信していないと判定されたときの処理について説明する。この場合は、まず、ステップＳ１６７において、すれ違い接続要求、すなわち、他のゲーム装置１からのすれ違い通信の要求を無線通信モジュール３４が受信したか否かが判定される。その結果、当該要求を受信していないと判定されたときは（ステップＳ１６７でＮＯ）、後述のステップＳ１７３に処理が進められる。一方、当該要求を受信したと判定されたときは（ステップＳ１６７でＹＥＳ）、ステップＳ１６８において、すれ違い接続応答が生成されて、上記すれ違い接続要求の送信元である他のゲーム装置１へ送信される（なお、上記図２１のステップＳ３４の処理では、この流れで処理が進められることになる）。このとき、当該すれ違い接続応答には、上記無線通信モジュール３４に記憶されている抽出アプリＩＤ４０６の内容が含まれて送信される（つまり、すれ違い通信の対象となるアプリを相手側に通知することになる）。

次に、ステップＳ１６９において、応答時刻、および、通信相手である他のゲーム装置１のＭＡＣアドレスが、無線通信モジュール３４内の既通信端末／専用ＡＰ情報４０５に記憶される。

次に、ステップＳ１７０において、通信相手からデータを受信したか否かが判定される。これは、本実施形態では、アプリＩＤ５２２が一致するもののみ送受信対象としている関係上、他のゲーム装置１からのすれ違い通信要求を受け、接続は確立したものの、双方で一致するアプリＩＤ５２２がなかったために、実際には送受信するデータがない、という場合を判定するためのものである。すなわち、ステップＳ１６９にて送信した接続応答を、相手端末が受信したものの、相手端末側の図２１のステップＳ２５でＮＯであった場合には、データは送信されてこないことになる。当該判定で、相手端末からのデータが（一定時間内に）受信されていないと判定されたときは（ステップＳ１７０でＮＯ）、上記一致するアプリＩＤ５２２がなかった場合に相当すると考えられるため、上記ステップＳ１６５に処理が進められて、「スリープモード」に戻すか否かの判定が行われる。一方、相手端末からデータを受信したと判定されたときは（ステップＳ１７０でＹＥＳ）、当該受信したデータが、そのアプリＩＤ５２２に対応するスロット５２１の受信用ボックス５２４に格納される。なお、上記ステップＳ１６４からステップＳ１７０に来た場合は、少なくとも１つはアプリＩＤ５２２が一致する送受信対象があったことになり、相手端末からはデータが送信されてくるため、途中で転送エラーが生じない限り、この判定ではＹＥＳと判定される。

次に、ステップＳ１７２において、すれ違い通信にかかる送信処理が既に行われているか否かが判定される。その結果、まだすれ違い通信にかかる送信処理が行われていないと判定されたときは（ステップＳ１７２でＮＯ）、上記ステップＳ１６２に処理が進められ、すれ違い通信にかかる送信処理が行われる。一方、送信処理は既に行われていると判定されたときは（ステップＳ１７２でＹＥＳ）、上記ステップＳ１６５に処理が進められる。

次に、上記ステップＳ１６７の判定の結果、すれ違い接続要求が受信されていないと判定されたときの処理について説明する。この場合は、次に、「インターネット通信」に関する処理が実行されることになる。まず、図３７のステップＳ１７３において、無線通信モジュール３４が、専用ＡＰ１０１からのビーコンを受信したか否かが判定される。当該判定の結果、専用ＡＰ１０１からのビーコンを受信したと判定されたときは（ステップＳ１７３でＹＥＳ）、ステップＳ１７４において、当該ビーコンの発信元となる専用ＡＰ１０１への接続処理が実行される。なお、上記図２２のステップＳ４０の処理では、この流れで処理が進められることになる。

次に、ステップＳ１７５において、現在時刻と接続した専用ＡＰ１０１のＭＡＣアドレスが無線通信モジュール３４内の既通信端末／専用ＡＰ情報４０５に記憶される。

次に、ステップＳ１７６において、インターネット通信用ＢＧ処理が実行される。この処理では、ポリシーデータの取得とこれに基づく処理やタスクの実行処理が行われる。この処理の詳細については後述する。当該処理が終われば、当該ローカル通信用ＢＧ処理は終了する。

一方、上記ステップＳ１７３の判定の結果、専用ＡＰ１０１のビーコンを受信していないと判定されたときは（ステップＳ１７３でＮＯ）、ステップＳ１７７で、本体設定データ５６０が参照され、ゲーム装置１に登録・設定されている所定のＡＰをサーチする処理が実行される。例えば、ユーザの自宅に設置したＡＰや、出荷時設定として予め定義されている公衆無線ＬＡＮサービスのＡＰ等をサーチする処理が実行される。サーチ方法は典型的にはパッシブスキャンであるが、ＡＰのＢＳＳＩＤやＡＰとの通信に用いられる周波数が予めゲーム装置１に記憶されていれば、直接ＡＰと接続を行うこともできる。

次に、ステップＳ１７８において、上記ステップＳ１７７におけるサーチの結果、ＡＰが存在したか否かが判定される。その結果、ＡＰが存在しなかった（サーチの結果、検出できなかった）と判定されたときは（ステップＳ１７８でＮＯ）、上記ステップＳ１６５に処理が進められる。一方、ＡＰが存在したと判定されたときは（ステップＳ１７８でＹＥＳ）、ステップＳ１７９において、当該サーチされたＡＰへの接続処理が行われる。そして、ステップＳ１８０において、後述するインターネット通信用ＢＧ処理が実行される。当該処理が終われば、当該ローカル通信用ＢＧ処理は終了する。以上で、ローカル通信用ＢＧ処理の説明を終了する。

［インターネット通信用ＢＧ処理］
次に、上記ステップＳ１７６等で示したインターネット通信用ＢＧ処理について説明する。この処理では、「インターネット通信」を利用した各種データの送受信にかかる処理等が実行される。

図３８は、当該インターネット通信用ＢＧ処理の詳細を示すフローチャートである。まず、ステップＳ１９１において、ポリシー処理が実行される。当該処理の詳細は後述するが、ここでは、主に、ポリシーデータの取得、および、当該ポリシーデータに基づくタスクの実行優先度の調整が行われる。

次に、ステップＳ１９２において、タスク実行処理が行われる。この処理についても詳細は後述するが、この処理では、タスクの実行や、インストール処理等が行われる。

タスク処理が終了すれば、次に、ステップＳ１９３においてＡＰ１０１または１０２との通信の切断が実行される。続くステップＳ１９４において、今回の通信のために「スリープモード」が解除されていたか否かが判定される。その結果、「スリープモード」が解除されていたと判定されたときは（ステップＳ１９４でＹＥＳ）、ステップＳ１９５において、「スリープモード」に戻すために、ＣＰＵ３１に給電を停止するための命令がＣＰＵ３１自身から送られ、「スリープモード」に移行するための処理が実行されるとともに、マイコン３７内の給電状態フラグ３０４をオフにし、電源管理ＩＣ４１にスリープへ移行する旨を通知する。一方、ステップＳ１９４の判定の結果、今回の通信のために「スリープモード」が解除されていたのではないと判定されたときは（ステップＳ１９４でＮＯ）、ステップＳ１９５の処理はスキップされる。そして、当該インターネット通信用ＢＧ処理は終了する。

［ポリシー処理］
次に、上記ステップＳ１９１で示したポリシー処理について説明する。図３９〜図４０は、当該ポリシー処理の詳細を示したフローチャートである。まず、ステップＳ２０１において、上述したようなポリシーサーバ１０３との接続を確立する処理が実行される。次に、ステップＳ２０２において、現在通信に利用しているＡＰが専用ＡＰ１０１であるか否かが判定される。これは、ＡＰとの接続の際に利用したビーコンに、上述したようなベンダー特定情報が含まれているか否かで判定される。当該判定の結果、専用ＡＰ１０１を利用していると判定されたときは（ステップＳ２０２でＹＥＳ）、ステップＳ２０３において、当該利用している専用ＡＰ１０１の識別子と、ゲーム装置１に設定されている国情報（上記本体設定データ５６０に含まれている）を含んだポリシーデータのリクエストを生成し、ポリシーサーバ１０３に送信する。このリクエストは、例えば、以下のようなHTTPリクエストである。
「https://xxx.net/国情報を示す文字列/AP識別子/」

一方、現在通信に使用しているＡＰが専用ＡＰ１０１ではないと判定されたときは（ステップＳ２０２でＮＯ）、ステップＳ２０４において、上記国情報を含んだポリシーデータのリクエストが生成され、ポリシーサーバ１０３へ送信される。このときのリクエストは、例えば、以下のような内容となる。
「https://xxx.net/国情報を示す文字列/」

上記のようなリクエストに応じて、ポリシーサーバ１０３からポリシーデータが送信開始されるため、次に、ステップＳ２０５において、ポリシーサーバ１０３からポリシーデータがダウンロードされ、受信ポリシーデータ５７０としてメインメモリ３２あるいはＮＡＮＤフラッシュメモリ３３に格納される。

ダウンロードが終われば、次に、当該ダウンロードした受信ポリシーデータ５７０を適用するための処理が実行される。具体的には、まず、ステップＳ２０６において、受信ポリシーデータ５７０に含まれる全てのポリシー設定５７４について、以下に示すような処理が行われたか否か、つまり、実行優先度や消尽回数の変更が適用されたか否かが判定される。当該判定の結果、全てのポリシー設定５７４について適用済み（処理済み）と判定されたときは（ステップＳ２０６でＹＥＳ）、当該ポリシー処理は終了する。一方、未適用（未処理）のポリシー設定５７４が残っていれば（ステップＳ２０６でＮＯ）、ステップＳ２０７において、まだ適用されていないポリシー設定５７４のうちいずれか１つが選択される。以下、この選択されたポリシー設定５７４を「処理対象ポリシー設定」と呼ぶ。

次に、ステップＳ２０８において、処理対象ポリシー設定の内容が、全てのタスクを適用対象とする内容であるか否かが判定される。これは、当該処理対象ポリシー設定のタスクＩＤ５７６に、全タスクを適用対象とする旨の文字列が示されているか否か等で判定される。当該判定の結果、全タスクを適用対象とする内容ではないと判定されたときは（ステップＳ２０８でＮＯ）、後述のステップＳ２１３に処理が進められる。

一方、当該判定の結果、全タスクを適用対象とすると判定されたときは（ステップＳ２０８でＹＥＳ）、次に、ステップＳ２０９において、処理対象ポリシー設定のタスク永続性５７８が、オンに設定されているか否か、すなわち、「永続的」であることを示す内容か否かが判定される。当該判定の結果、「永続的」と判定されたときは（ステップＳ２０９でＹＥＳ）、ステップＳ２１２において、ゲーム装置１に登録されている（つまり、タスクデータ５３０内の）全てのタスクの実行優先度５３４が、当該処理対象ポリシー設定の実行優先度５７７で示される値に変更される。そして、後述のステップＳ２１８に処理が進められる。

一方、ステップＳ２０９の判定の結果、「永続的」ではないと判定されたときは（ステップＳ２０９でＮＯ）、ステップＳ２１０において、タスクデータ５３０内の全てのタスクについての現在の実行優先度５３４がメインメモリ３２にバックアップされる。そして、ステップＳ２１１において、ゲーム装置１に登録されている全てのタスクの実行優先度５３４が当該処理対象ポリシー設定の実行優先度５７７で示される値に変更される。そして、後述のステップＳ２１８に処理が進められる。

次に、上記ステップＳ２０８の判定の結果、全タスクを適用対象とする内容ではないと判定されたときの処理について説明する。この場合は、ステップＳ２１３において、タスクデータ５３０が参照されて、処理対象ポリシー設定のタスクＩＤ５７６およびアプリＩＤ５７５と同じ値を有するタスク設定５３１がタスクデータ５３０内に存在するか否かが判定される。当該判定の結果、存在しないと判定されたときは（ステップＳ２１３でＮＯ）、当該処理対象ポリシー設定については処理済みとしたうえで上記ステップＳ２０６に戻る。その結果、受信ポリシーデータ５７０から、未処理のポリシー設定５７４が次の処理対象ポリシー設定として選択され、処理が繰り返される。

一方、上記タスクＩＤおよびアプリＩＤが一致するタスク設定５３１が存在すると判定されたときは（ステップＳ２１３でＹＥＳ）、次に、ステップＳ２１４において、当該処理対象ポリシー設定のタスク永続性５７８が「永続的」を示す値か否かが判定される。その結果、「永続的」であれば、ステップＳ２１５において、上記タスクＩＤおよびアプリＩＤが一致するタスク設定５３１の実行優先度が、処理対象ポリシー設定の実行優先度５７７で示される値に設定される。そして、後述のステップＳ２１８に処理が進められる。

一方、ステップＳ２１４の判定の結果、「永続的」ではないと判定されたときは（ステップＳ２１４でＮＯ）、ステップＳ２１６において、上記タスクＩＤおよびアプリＩＤが一致するタスク設定５３１の実行優先度５３４がメインメモリ３２上にバックアップされる。そして、ステップＳ２１７において、上記タスクＩＤおよびアプリＩＤが一致するタスク設定５３１の実行優先度５３４が、処理対象ポリシー設定の実行優先度５７７で示される値に設定される。

次に、ステップＳ２１８において、上記実行優先度５３４が変更された結果、変更を適用される対象となったタスク設定５３１が以下に示すような条件を満たしているか否かが判定される。この条件とは、（１）消尽回数５４０が０であること、（２）上記変更適用後の実行優先度５３４が"EXPEDIATE"であること、（３）タスクリビジョン５４３の値が今回取得した受信ポリシーデータ５７０のポリシーリビジョン５７１と一致すること、である。この３つの条件の全ては満たしていないと判定されたときは（ステップＳ２１８でＮＯ）、ステップＳ２１９において、当該タスク設定５３１の消尽回数５４０に１が加算される。すなわち、消尽回数が０となって実行されなくなったタスクに対して、実行優先度が"EXPEDIATE"、つまり最優先で実行させたいタスクとするために、消尽回数５４０の値を変更するものである。そして、ステップＳ２２０において、今回適用したタスク設定５３１のタスクリビジョン５４３の値として、上記受信ポリシーデータ５７０のポリシーリビジョン５７１の値が記録される。そして、上記ステップＳ２０６に処理が戻る。

一方、ステップＳ２１８の判定の結果、上記３つの条件を全て満たしていると判定されたときは（ステップＳ２１８でＹＥＳ）、以前も同じリビジョンのポリシーを受信し、そのときに当該タスクは実行されていると考えられる。この場合、同じリビジョンのポリシーデータを受信したときは、再度当該タスクを実行させないため、上記のような消尽回数５４０の加算は行われずに、ステップＳ２２０に処理が進められる。以上で、ポリシー処理の説明は終了する。

［ポリシーサーバの処理］
ここで、上記ポリシー処理における通信相手となるポリシーサーバの処理についても説明する。まず、具体的な処理の説明の前に、ポリシーデータが格納されている当該ポリシーサーバ１０３のメモリマップについて簡単に説明する。図４１は、ポリシーサーバ１０３のメモリマップを示す図である。図４１に示すように、ポリシーサーバ１０３には、国情報１５２毎に分けて複数のポリシーデータ１５３が格納されている。各ポリシーデータ１５３の構造は、上記図１８で示した受信ポリシーデータ５７０と同様である。図４１では、説明を判りやすくするため、ＡＰ情報１５４のみ示している。ＡＰ情報１５４は、所定の専用ＡＰ１０１を示す値が割り振られているものと、ＮＵＬＬ値が設定されているものがあるとする。本実施形態では、各国情報毎に、専用ＡＰ１０１を示す値が割り振られたポリシーデータ１５３は複数存在するとする（但し、これら複数のポリシーデータ１５３の間では、ＡＰ情報１５４は重複していないとする）。また、ＡＰ情報にＮＵＬＬ値が設定されたポリシーデータ１５３は一つだけしか存在しないものとする。このようなポリシーデータ１５３がポリシーサーバ１０３に格納されていることを前提として、以下のような処理が実行される。

図４２は、当該ポリシーサーバ１０３で実行される処理を示すフローチャートである。図４２において、まず、ステップＳ２３１において、上述したようなポリシーデータ１５３のリクエストの受信があったか否かが判定される。その結果、受信していないと判定されたときは（ステップＳ２３１でＮＯ）、当該ステップＳ２３１の処理が繰り返される。つまり、当該リクエストの待ち受け状態となる。一方、ポリシーデータ１５３のリクエストを受信したと判定されたときは（ステップＳ２３１でＹＥＳ）、次に、ステップＳ２３２において、受信したリクエストにＡＰの識別子が付加されているか否かが判定される。その結果、付加されているときは（ステップＳ２３２でＹＥＳ）、専用ＡＰ１０１を経由してポリシーサーバ１０３にアクセスしてきていると考えられる。この場合は、ステップＳ２３３において、リクエストに含まれているゲーム装置１の国情報、および、ＡＰの識別子に対応するポリシーデータ１５３が読み出される。つまり、上記リクエストに含まれる国情報が上記ポリシーサーバ１０３に記憶されている国情報１５２と照合され、一致するものがあれば、更に、リクエストに含まれるＡＰ識別子とＡＰ情報１５４とが照合され、一致するポリシーデータ１５３が検索され、読み出される。そして、ステップＳ２３５において、当該読み出されたポリシーデータ１５３が上記リクエストの送信元のゲーム装置１に送信される。

一方、上記ステップＳ２３２の判定の結果、上記リクエストにＡＰの識別子が付加されていないと判定されたときは（ステップＳ２３２でＮＯ）、専用ＡＰ１０１を介さずにポリシーサーバにアクセスしてきている場合であると考えられる。そのため、この場合は、ステップＳ２３４において、まず、上記リクエストに含まれる国情報と上記ポリシーサーバの国情報１５２とが照合され、一致するものが検索される。そして、ＡＰ情報１５４にＮＵＬＬ値が設定されているポリシーデータ１５３が読み出される。そして、上記ステップＳ２３５において、当該ポリシーデータ１５３の送信が行われる。以上で、ポリシーサーバの説明は終了する。

［タスク実行処理］
次に、上記図３８のステップＳ１９２で示した、タスクの実行処理について説明する。この処理では、タスクの設定内容に基づいて所定のデータの送受信が行われる。更に、インストール処理も行われる。図４３〜図４８は、当該タスク処理の詳細を示すフローチャートである。まず、ステップＳ５１１において、実行順ソート処理が実行される。この処理では、タスクの実行優先度や次回実行時刻、消尽回数等を考慮して、実行すべきタスクの抽出が行われ、その実行順序を決定するための処理が行われる。また、以下のような処理が行われた結果、メインメモリ３２に「実行順序リスト」という一時的なデータが生成される。

図４９は、上記ステップＳ５１１にかかる実行順ソート処理の詳細を示すフローチャートである。図４９において、まず、ステップＳ２９１で、上記タスクデータ５３０が参照されて、次回実行時刻５３７が現在時刻以前であって、且つ、消尽回数５４０が０ではないタスク設定５３１が抽出される。ここで、次回実行時刻が現在時刻「以前」であるものを抽出している理由は、専用ＡＰ１０１に接続するタイミングは偶然ビーコンを受信したときであるために、タスクの実行時刻と完全に一致する時刻に当該処理が行われることはまれであるからである。そのため、既に実行時刻を経過してしまっていても、この時点においては抽出が行われる。

次に、ステップＳ２９２において、上記抽出された各タスク設定５３１についての評価が行われる。当該評価の意図は、長い間実行されていないタスクほど、より優先的に実行されるように調整するという意図である。そのため、本実施形態では、「評価ポイント」というものを用いる。当該「評価ポイント」は、その値が高いほど、優先的に実行すべきであることを示す。そして、この処理では、上記抽出された各タスク設定５３１の前回完了時刻５４４と現在時刻とが比較され、前回完了時刻５４４から現在時刻までの時間が長いものほど高い点数の「評価ポイント」が与えられる。つまり、長時間実行されていないタスク設定５３１ほど、高い「評価ポイント」が設定される。

次に、ステップＳ２９３において、上記抽出されたタスクから実行優先度５３４が”STOPPED”のタスクが除外される。”STOPPED”は実行停止を意味する内容であるからである。

次に、ステップＳ２９４において、実行優先度５３４および上記「評価ポイント」に基づいて、これまでの処理でピックアップされた各タスク設定５３１がソートされる。具体的には、まず、実行優先度５３４に基づいて各タスク設定５３１がソートされる。次に、実行優先度が同じタスク設定５３１の間で、上記「評価ポイント」に基づくソートが行われる。その結果、同じ実行優先度を有するタスク設定５３１の間では、長時間実行されていないタスクほど優先的に実行されるような順序づけがなされることになる。なお、未実行のタスク設定、すなわち、前回完了時刻５４４に値が設定されていないタスク設定５３１については、当該タスク設定５３１が登録された時刻であるタスク登録時刻５４５に基づいてソートされる。すなわち、登録時刻が古いものほど優先的に実行されるようにソートされる。

次に、ステップＳ２９５において、未処理フラグ５４１がオンに設定されているタスク設定５３１があるか否かが判定される。その結果、未処理フラグ５４１がオンのタスク設定５３１があると判定されたときは（ステップＳ２９５でＹＥＳ）、ステップＳ２９６において、当該未処理のタスク設定５３１の実行優先度が”HIGH”であって、その中での実行順序が上位に来るように調整される。つまり、この時点で未処理となっているタスクは、以前にタスクが実行可能な状態であったときに、何らかの原因で当該タスクが実行されなかったと考えられる。そのため、このようなタスクについては、"EXPEDITE"の次の優先度で実行されるように調整することで、いわゆる「レジューム」的な動作が行われるようにするものである。一方、ステップＳ２９５の判定の結果、未処理フラグ５４１がオンのタスク設定５３１がないときは（ステップＳ２９５でＮＯ）、ステップＳ２９６の処理はスキップされて、本実行順ソート処理は終了する。その結果、上記「実行順序リスト」がメインメモリ３２上に生成されることになる。当該「実行順序リスト」では、上記のような処理の結果、上記処理でピックアップされたタスクが、その実行順位の高いものから順にソートされて示されている。

図４３に戻り、実行順ソート処理が終われば、次に、ステップＳ５１２において、上記「実行順序リスト」にリストアップされている全てのタスクを全て実行し終えたか否かが判定される。当該判定の結果、すべて実行し終えたと判定されたときは（ステップＳ５１２でＹＥＳ）、後述するステップＳ５５１に処理が進められる。一方、まだ未実行のタスクが残っていると判定されたときは（ステップＳ５１２でＮＯ）、次に、ステップＳ５１３において、完了していないタスクのうち、実行順序が最上位のタスクが選択される。以下、当該選択されたタスクを処理対象タスクと呼ぶ。

次に、ステップＳ５１４において、選択された処理対象タスクにかかるタスク設定５３１の未処理フラグ５４１がオンに設定される。

次に、ステップＳ５１５において、当該処理対象タスクにかかるタスク設定５３１の通信先ＵＲＬ５３５が参照され、ＨＴＴＰリクエストが生成される。続くステップＳ５１６において、本体設定データ５６０が参照され、上記生成されたＨＴＴＰリクエストの文字列にゲーム装置１に設定されている国情報が付加される。

次に、ステップＳ５１７において、現在行われている「インターネット通信」は、専用ＡＰ１０１を利用した通信であるか否か、つまり、専用ＡＰ１０１を介してインターネットに接続しているか否かが判定される。その結果、専用ＡＰ１０１を利用した通信であると判定されたときは（ステップＳ５１７でＹＥＳ）、ステップＳ５１８において、現在使用しているＡＰにかかるＡＰ識別子が、上記ＨＴＴＰリクエストの文字列に更に付加される。一方、専用ＡＰを利用していないと判定されたときは（ステップＳ５１７でＮＯ）、当該ステップＳ５１８の処理はスキップされる。

次に、図４４のステップＳ５１９において、処理対象タスクにかかるタスク設定５３１の送信／受信識別フラグ５３９を参照することにより、処理対象タスクの内容が「受信タスク」か否かが判定される。つまり、データの受信を行うためのタスクであるか、送信を行うためのタスクであるかが判定される。その結果、「受信タスク」であると判定されたときは（ステップＳ５１９でＹＥＳ）、ステップＳ５２０において、上記の処理で生成されたＨＴＴＰリクエストが、当該処理対象タスクにかかるタスク設定５３１の通信先ＵＲＬ５３５で示されるサーバに対して送信される。このとき、当該リクエストのＨＴＴＰヘッダの”If-Modified-Since”フィールドに”前回の当該タスクの実行時刻”が含まれて送信される。これにより、If-Modified-Sinceに記される日時以降に更新があったときのみサーバはデータを送り、更新がないときは、サーバはレスポンスコード３０４のみを返すことになる。

次に、ステップＳ５２１において、上記処理対象タスクの内容が、アプリをダウンロードするためのタスクであるか否かが判定される。当該判定の結果、アプリをダウンロードするタスクであるときは（ステップＳ５２１でＹＥＳ）、ステップＳ５２２において、ダウンロード中であるか否か（後述のステップＳ５２６またはステップＳ５２９の処理でダウンロードが開始済みか否か）が判定される。その結果、ダウンロード中ではないときは（ステップＳ５２２でＮＯ）、ステップＳ５２３において、既存のアプリのアップデートに該当するか否かが判定される。この判定は、ダウンロード対象のアプリと同じアプリＩＤ５５２をもつアプリが実際にインストールされているかどうかをアプリ関連データ５５０（あるいはプログラム領域５００））を参照することで判定される。なお、このような判定の他、例えば、上記アプリのインストール処理（上記図２９〜図３０参照）において、同じアプリを有し、かつ旧バージョンを所持しているか否かを判断し、肯定の判定のときにアップデートであるというフラグを作成し、このフラグを参照して判定するようにしても良い。また、同種のアプリであってもバージョン毎にＩＤが異なるようにＩＤを付与している場合は、ＩＤを参照することでアップデートの確認が可能となる。

上記判定の結果、既存のアプリのアップデートに該当すると判定されたときは（ステップＳ５２３でＹＥＳ）、ステップＳ５２９で、ダウンロード対象のアプリ（のファイル）を、既存のアプリのファイル名とは別のファイル名でＮＡＮＤフラッシュメモリ３３のプログラム領域５００にオンザフライで格納する処理が開始される。更に、ステップＳ５３０において、新規アップデートフラグ５５９がオンに設定され、ステップＳ５３２に処理が進められる。

一方、ステップＳ５２３の判定の結果、既存アプリのアップデートに該当しない（つまり、新規アプリの導入）と判定されたときは（ステップＳ５２３でＮＯ）、次に、ステップＳ５２４において、正当性確認処理が実行される。この処理は、上記ステップＳ４７２の処理と同様処理が実行される。すなわち、今回ＤＬ対象となるファイルに関する権利情報がＤＬされ、その正当性が確認される。

次に、ステップＳ５２５において、正当性に問題が無かったか否かが判定される。その結果、問題があったときは（ステップＳ５２５でＮＯ）、後述するステップＳ５４３に処理が進められる。一方、正当性に問題が無いときは（ステップＳ５２５でＹＥＳ）、次に、ステップＳ５２６において、ダウンロード対象のアプリ（のファイル）をＮＡＮＤフラッシュメモリ３３のプログラム領域５００にオンザフライで格納する処理が開始される。このときは、新規インストールに該当するため、別のファイル名は用いずに格納される。

続くステップＳ５２７において、当該アプリに関連する各種データ（例えば、メタデータ）の生成および設定が適宜行われ、アプリ関連データ５５０としてＮＡＮＤフラッシュメモリ３３に格納される。

次に、ステップＳ５２８において、当該アプリに対応するアプリケーション領域５５１の新規インストールフラグ５５４がオンに設定される。

その後、ステップＳ５３２において、ダウンロードが完了したか否かが判定される。その結果、まだ完了していないときは、上記ステップＳ５２１の処理に戻される。ダウンロードが完了したときは（ステップＳ５３２でＹＥＳ）、次に、図４５のステップＳ５３２１において、上記完了したダウンロードの内容は、アプリのダウンロード、あるいは、システムの構成要素のダウンロードであったか否かが判定される。当該判定の結果、アプリ、またはシステム構成要素のダウンロードであったときは（ステップＳ５３２１でＹＥＳ）、ステップＳ５３２２において、当該ダウンロードされたファイルの正当性をチェックする処理が実行される。この処理は、上記図３１を用いて上述した処理内容とほぼ同様の処理が実行される。但し、そのチェック対象としては、上記権利情報の正当性ではなく、上記ダウンロードされたファイルの正当性がチェックされることになる。そして、正当性に問題が無ければＮＡＮＤフラッシュメモリ３３に適宜記憶される。また、正当性に問題があるときは、当該ファイルは破棄される。その後、後述するステップＳ５４３に処理が進められる。

一方、アプリまたはシステム構成要素のダウンロードではなかったときは（ステップＳ５３２１でＮＯ）、上記ステップＳ５３２２の処理はスキップされて、後述のステップＳ５４３に処理が進められる。

一方、上記ステップＳ５２２の判定の結果、ダウンロード中であると判定されたときは（ステップＳ５２２でＹＥＳ）、ステップＳ５３１において、ダウンロード中であるアプリのファイルを上記ＮＡＮＤフラッシュメモリ３３にオン・ザ・フライで格納していく処理が継続される。そして、上記ステップＳ５３２に処理が進められる。

次に、上記ステップＳ５２１の判定の結果、アプリのダウンロードタスクではないと判定されたときの処理について説明する。この場合は、図４５のステップＳ５３３において、上記処理対象タスクの内容が、システムの構成要素（システムプログラム）をダウンロードするためのタスクであるか否かが判定される。当該判定の結果、システムプログラムをダウンロードするタスクであるときは（ステップＳ５３３でＹＥＳ）、次に、ステップＳ５３４において、ダウンロード対象の構成要素は、既存の構成要素であるか否かが判定される。つまり、既存の構成要素のアップデートに該当するのか、新規の構成要素の取得に該当するのかが判定される。当該判定の結果、既存の構成要素のアップデートに該当する場合は（ステップＳ５３４でＹＥＳ）、ステップＳ５３６において、実際の（現在稼働中の）システムプログラムのファイル名とは別の名前で、オン・ザ・フライでシステムプログラム領域５１５にダウンロード対象の構成要素を格納する処理（ダウンロードの開始、または、開始済みであればダウンロードの継続）が実行される（例えば、実際のシステムプログラムのファイル名が「firmware001.bin」であるときは、「firmware002.bin」の名前で格納される）。そして、上記ステップＳ５３２に戻る。

一方、既存の構成要素ではない、つまり、新規の構成要素であるときは（ステップＳ５３４でＹＥＳ）、ステップＳ５３５において、オン・ザ・フライ用キャッシュ６００にオン・ザ・フライで格納する処理が実行される（ファイル名の変更はなされない）。そして、ステップＳ５３２に処理が戻る。

一方、上記ステップＳ５３３の判定の結果、受信タスクがシステムプログラムのダウンロードのタスクでもないときは（ステップＳ５３３でＮＯ）、図４６のステップＳ５３７において、受信タスクが「インストールリストの取得」のタスクであるか否かが判定される。その結果、「インストールリストの取得」であるときは（ステップＳ５３７でＹＥＳ）、ステップＳ５３８において、サーバから、変更がないことを示す旨の応答、具体的には、ＨＴＴＰレスポンスコード３０４（Ｎｏｔ Ｍｏｄｉｆｉｅｄ、すなわち更新が無い旨のレスポンスコード）が返されたか否かが判定される。当該判定の結果、ＨＴＴＰレスポンスコード３０４が返されたときは（ステップＳ５３８でＹＥＳ）、前回更新時からインストールリストが更新されていないと考えられるため、インストールリストはダウンロードされずに、上記ステップＳ５３２の処理に進められる。

一方、上記ステップＳ５３７の判定の結果、受信タスクが「インストールリストの取得」ではないと判定されたとき（ステップＳ５３７でＮＯ）、または、上記ステップＳ５３８で、ＨＴＴＰレスポンスコード３０４が返されなかったときは（ステップＳ５３８でＮＯ）、ステップＳ５３９において、当該処理対象タスクにかかるタスク設定５３１のファイルパス５３６で示される格納場所すなわち当該タスク設定５３１のアプリＩＤ５３２に対応するアプリケーションのアプリケーション領域５５１のタスク受信キャッシュ５５３に、ダウンロードされたデータが格納される。具体的には、上記ステップＳ５３７でＮＯと判定されて当該処理が実行されたときは、処理対象タスクに対応する各アプリに関連するデータ（上記のようなインストールに関連しない各種データ）が格納される。また、上記ステップＳ５３８でＮＯと判定されて当該処理が実行されるときは、インストールリスト５８０がサーバから取得されてデータ領域５１２に格納されることになる。その後、上記ステップＳ５３２の処理に進められる。

図４４に戻り、一方、上記ステップＳ５１９の判定の結果、処理対象タスクの内容が「受信タスク」ではない、つまり、「送信タスク」であると判定されたときは（ステップＳ５１９でＮＯ）、図４６のステップＳ５４０において、当該処理対象タスクのファイルパス５３６で示される格納場所、本実施形態では、当該処理対象タスクに対応するアプリケーション領域５５１のタスク送信用データ５５６から、送信（アップロード）すべきデータが取得される。そして、当該データが上記ＨＴＴＰリクエストに付加される。

次に、ステップＳ５４１において、上記送信データが付加されたＨＴＴＰリクエストがサーバに送信される。すなわち、通信先ＵＲＬ５３５で示されるＵＲＬに対してのデータのアップロード処理が開始される。その後、アップロードが完了すれば、ステップＳ５４２において、サーバから送られてくる完了通知（データのアップロードが正常終了したことを示す通知）が受信される。そして、ステップＳ５４３に処理が進められる。

次に、図４７のステップＳ５４３において、処理対象タスクにかかるタスク設定５３１の未処理フラグ５４１にオフが設定される。続くステップＳ５４４において、前回完了時刻５４４に現在時刻が完了時刻として記憶される。更に、ステップＳ５４５において、消尽回数５４０の値から１が減算される。

次に、ステップＳ５４６において、タスク設定５３１の実行間隔５３８が参照されて次回実行時刻が算出され、次回実行時刻５３７として記憶される。なお、「インストールリストの取得」のタスクに関しては、次回実行時刻が２４時間後となるように設定される。

次に、ステップＳ５４７において、上記処理対象タスクの内容が、「インストールリストの取得」というタスクであるか否かが判定される。上述したように、当該「インストールリストの取得」というタスクは、ゲーム装置１の出荷時設定として予め設定されているタスクである。そのタスク設定５３１の内容としては、予め定められた固定的なタスクＩＤ５３３が割り当てられており、また、定期的（本実施形態では２４時間毎）に実行されるように設定されている。そのため、当該タスクＩＤ５３３を参照することで、「インストールリストの取得」というタスクか否かが判定される。当該判定の結果、「インストールリストの取得」のタスクであると判定されたときは（ステップＳ５４７でＹＥＳ）、ステップＳ５４８において、システムインストール処理が実行される。この処理の詳細は後述する。一方、「インストールリストの取得」のタスクではないと判定されたときは（ステップＳ５４７でＮＯ）、ステップＳ５４８の処理はスキップされる。

次に、ステップＳ５４９において、処理対象タスクにかかるタスク設定５３１の一時変更フラグ５４２が参照されることにより、当該処理対象タスクの実行優先度５３４が一時的な変更にかかるものか否かが判定される。その結果、一時的な変更と判定されたときは（ステップＳ５４９でＹＥＳ）、ステップＳ５５０において、バックアップされている実行優先度データが用いられ、当該処理対象タスクにかかる実行優先度５３４が元の値に変更される。一方、一時的な変更ではないと判定されたときは（ステップＳ５４９でＮＯ）、ステップＳ５５０の処理はスキップされる。その後、上記図４３のステップＳ５１２に戻り、未実行のタスクが適宜選択されて処理が繰り返される。

次に、図４３のステップＳ５１２において、全てのタスクを実行し終えたと判定されたときの処理（ステップＳ５１２でＮＯ）について説明する。このときは、次回起床時刻３０５を設定するための処理が実行される。具体的には、まず、図４８のステップＳ５５１において、タスクデータ５３０内の全てのタスク設定５３１についての次回実行時刻５３７が読み込まれる。続くステップＳ５５２において、全タスクのうち、次回実行時刻５３７が最も早い時刻のタスクが検出される。そして、当該最も早い次回実行時刻が現在時刻から３０分以内であるか否かが判定される。当該判定の結果、３０分以内であると判定されたときは（ステップＳ５５２でＹＥＳ）、ステップＳ５５３において、現在時刻の３０分後の時刻を次回起床時刻３０５として設定する。つまり、一旦タスクが実行されると、その後、最低３０分間はタスクの実行が行われないように設定されることになる。これにより、あまりに頻繁に接続が行われてしまうことを防ぎ、ゲーム装置１の更なる省電力化や、ネットワークトラフィックの負荷の軽減を図ることが可能となる。そして、当該タスク実行処理は終了する。

一方、ステップＳ５５２の判定の結果、最も早い次回実行時刻は現在時刻から３０分以内ではないと判定されたときは（ステップＳ５５２でＮＯ）、ステップＳ５５４において、当該最も早い次回実行時刻５３７が現在時刻から３時間後よりも遅い時刻であるか否かが判定される。その結果、３時間後よりも遅いと判定されたときは（ステップＳ５５４でＹＥＳ）、ステップＳ５５５において、現在時刻から３時間後の時刻が次回起床時刻３０５として設定される。これにより、少なくとも３時間後には接続を試みることになるので、定期的にゲーム装置１に接続を試みさせることができる。なお、上記のような３０分や３時間という値はあくまで一例であり、設定時刻はこれらに限定されるものではない。

一方、最も早い次回実行時刻５３７は現在時刻から３時間後よりも遅い時刻ではないと判定されたときは（ステップＳ５５４でＮＯ）、当該最も早い次回実行時刻は、３０分から３時間の間ということになり、ステップＳ５５６において、当該最も早い次回実行時刻が次回起床時刻３０５として設定される。そして、当該タスク実行処理が終了する。以上で、タスク実行処理の説明を終了する。

［システムインストール処理］
次に、上記ステップＳ５４８で示したシステムインストール処理の詳細を説明する。本処理では、主に、システムプログラムのアップデートに関する処理が行われる。図５０〜図５１は、当該システムインストール処理の詳細を示すフローチャートである。まず、ステップＳ３１０において、アプリインストール必要フラグ６３０がオンに設定される。次に、ステップＳ３１１において、インストールリスト５８０のシステムアップデート情報５８３が参照され、これに含まれているシステムの構成要素５８４の全てに基づいて示されるシステム構成と、現在のシステム構成との差分の有無がチェックされる。これは、例えば、全ての構成要素に基づいて算出されるハッシュ値を比較することで、差分の有無がチェックされる。なお、システム構成の差分の有無（つまり、システムに更新があるか否か）が判別できれば、ハッシュ値を用いる方法に限らずどのような手法を用いても良い。

次に、ステップＳ３１２において、上記差分の有無のチェックの結果、システム構成に差分があるか否かが判定される。その結果、差分がないときは（ステップＳ３１２でＮＯ）、システムの更新はない（同じバージョンである）と考えられるため、ステップＳ３２３に処理が進められ、アプリのインストール処理が行われる。この処理は、上記図２６，図２９および図３０を用いて説明したステップＳ４２４の処理と同様である。すなわち、アプリをダウンロードするタスクが適宜生成され、かつ、即時実行されることで、アプリが適宜インストールされる。そして、システムインストール処理は終了する。ここでは、システムの更新がない場合はすぐにアプリケーションのインストール処理を行うことになる。

一方、ステップＳ３１２の判定の結果、差分があるときは（ステップＳ３１２でＹＥＳ）、システムの新しいバージョンが提供されていると考えられる。このときは、システムを更新するための処理が実行される。まず、ステップＳ３１３において、上記インストールリスト５８０に挙げられているシステムの構成要素５８４の全てについて、以下に述べるようなチェック処理が行われたか否かが判定される。その結果、まだチェック処理が行われていない構成要素５８４が残っているときは（ステップＳ３１３でＮＯ）、ステップＳ３１４において、インストールリスト５８０に挙げられている構成要素５８４から、チェック対象となる構成要素５８４（以下、処理対象構成要素と呼ぶ）が一つ選択される。

次に、ステップＳ３１５において、当該処理対象構成要素がインストールの対象となるか否かが判定される。具体的には、現在のシステム構成の詳細リスト６４０が参照され、このリストに上記処理対象構成要素を示す情報が載っているか否かが判定される。その結果、載っていない場合、つまり、処理対象構成要素が現在インストールされていない構成要素である場合は、構成要素の新規インストール対象として判定される。更に、上記処理対象構成要素に上記リストが載っている場合は、双方の構成要素のバージョンチェックが行われ、現在のシステム構成の詳細リスト６４０に載っているバージョンよりも、上記処理対象構成要素のバージョンのほうが新しいか否かが判定される。その結果、上記処理対象構成要素のバージョンのほうが新しい場合も、構成要素のアップデートとして、インストール対象として判定される。

上記ステップＳ３１５の判定の結果、処理対象構成要素がインストール対象ではないと判定されたときは（ステップＳ３１５でＮＯ）、上記ステップＳ３１３に処理が戻される。一方、処理対象構成要素がインストール対象であると判定されたときは（ステップＳ３１５でＹＥＳ）、次に、権利情報のチェックが実行される。まず、ステップＳ３１６において、処理対象構成要素の権利情報が所定のサーバからダウンロードされる。次に、ステップＳ３１７において、正当性確認処理が実行される。この処理は、上記図３０および図３１を用いて説明した、ステップＳ４７２にかかる処理と同様の処理が実行される。すなわち、ダウンロードされた権利情報の正当性のチェックと、その結果に応じた権利情報データベース６１０への登録、あるいは、ダウンロードした権利情報の破棄が行われる。

ステップＳ３１７の正当性確認処理が終われば、次に、ステップＳ３１８において、当該正当性確認処理の結果、正当性に問題がなかったか否かが判定される。その結果、正当性に問題がなかったときは（ステップＳ３１８でＹＥＳ）、ステップＳ３１９において、処理対象構成要素の構成要素ＩＤ５８５（図１９参照）に対応する構成要素（システムプログラム）をダウンロードするための「受信タスク」が生成される。このとき、優先順位５８６が参照され、これに示される優先順位が当該受信タスクの実行優先度５３４として設定される。一方、上記ステップＳ３１８の判定の結果、正当性に問題があったときは（ステップＳ３１８でＮＯ）、上記ステップＳ３１９の処理は行われずに、上記ステップＳ３１３へ処理が戻される。

次に、上記ステップＳ３１３の判定の結果、上記インストールリスト５８０に挙げられている構成要素５８４の全てについて上記のようなチェック処理が行われたと判定されたとき（ステップＳ３１３でＹＥＳ）の処理について説明する。なお、当該ステップＳ３１３の判定については、インストールリスト５８０にシステムアップデート情報５８３自体が含まれていないような場合（システムの更新はなく、アプリの更新や新規配布アプリのみがあるような場合）も、当該判定においてＹＥＳと判定される。

このときは、図５１のステップＳ３２０において、上記ステップＳ３１９で生成されたタスク（すなわち、システムプログラムをダウンロードするためのタスク）を実行するために、タスク実行処理が行われる。当該処理は、上述した図３８のステップＳ１９２の処理と同様の処理である（この場合は、上記図４５で示したステップＳ５３３の判定でＹＥＳと判定されて処理が進められることになる）。なお、当該ステップＳ３２０では即時でタスク実行が行われることになるが、この即時実行でのタスクが失敗した場合は、例えば１時間後に当該タスクが実行されるようにしてもよい。具体的には、上記図３７のステップＳ１７８の判定でＮＯと判定されたときに、アプリまたはシステムのダウンロードのためのタスクであるか否かを判定し、アプリまたはシステムのダウンロードのためのタスクであるときは、１時間後に同じタスクが実行されるように設定すればよい。

ステップＳ３２０の処理が終われば、次に、ステップＳ３２１において、アップデート後のシステムの構成要素（システムプログラム）に基づいて、上述したステップＳ３１１の処理で用いるための情報が生成され、構成要素比較用データ６５０としてデータ領域５１２に記憶される。ただし、構成要素比較用データ６５０の更新は、図２５で説明したシステムアップデートの反映の後でもよい。

次に、ステップＳ３２２において、システムインストール済みフラグ６２０がオンに設定される。以上で、システムインストール処理は終了する。その結果、この後にメニューが表示された際に、上記ステップＳ４１３（図２５）の処理において、システムの更新の問い合わせが行われることになる。

以上で、第１の実施形態にかかる各種処理の説明を終了する。

上記で説明したように、本実施形態では、ＣＰＵ３１に電力が供給されていない状態でも、上記タスクの実行条件が満たされれば、自動的にＣＰＵ３１に通電し、ＡＰへの接続が試みられる。その結果、ユーザが気付かないうちにネットワークへ接続することが可能となる。また、タスクの実行条件が満たされないうちは、ＣＰＵ３１には電力は供給されないため、消費電力を節約することも可能である。これにより、携帯型ゲーム装置のような、常時接続を前提としていない情報端末であっても、常時接続しているかのような振る舞いを行わせつつ、消費電力の節約も可能となる。

また、ユーザが気付かないうちにネットワーク接続すると共に、更に、上述したようなアプリケーション等のダウンロード及びインストールも行っている。従来の技術においては、一般に、携帯型情報端末等において、新規のアプリケーションが配布されている場合は、その通知のみがユーザに対して行われ、ユーザがインストール処理に関する何らかのアクション（新規アプリをインストールする意図の基で行われる操作）がなされたときに初めてインストール処理が行われる。一方、本実施形態では、新規アプリが配布されているときは、このような操作をユーザに求めることなくインストール処理まで行い、ユーザが当該アプリをすぐに利用できる状態にまで設定している。そのため、ユーザが次にゲーム装置１を動作させた際に、知らないうちに新しいアプリケーションが加わっている事による驚きを与えることが可能となる。更に、このようなアプリケーションは既にインストールが完了しており、すぐに利用できる状態となっているため、上記のようなインストールに関する操作をユーザに求めることもなく、ダウンロードやインストール処理の際に発生する処理待ちの時間をユーザに与えず、利便性をより高めることができる。

また、上述の「特典アプリ」のように、所定の条件、例えば、所定のゲームのプレイ時間が所定時間以上である、等の条件が満たされたときのみ入手可能なアプリを定義・準備しておき、これを上記のように自動的にインストールすることで、ユーザに対してゲームやアプリをより長く遊んでもらうための動機付けを提供することも可能となる。

また、上記実施形態では、レーティングのチェックに関して、レーティング情報５９３をインストールリスト５８０に含める場合を例に挙げたが、この他、レーティング情報５９３はインストールリスト５８０には含めずに、別途のファイルとして所定のサーバ上にレーティング情報を含むファイルを格納しておき、インストールリスト５８０とは別にこれを取得するようにしてもよい。

また、上記「受信タスク」を実行した結果、所定のアプリケーションにかかるネットワークサービスが終了した通知を受信することができ、また、終了した旨をユーザに通知している。更に、この場合は、当該ネットワークサービスにかかるタスクを消去するようにしている。これにより、ユーザは主体的に情報収集を行わなくても、所定のネットワークサービスが終了したことを知ることが可能となるほか、不要となるタスクを消去することでメモリ容量を節約できる。

また、上記実施形態では、専用ＡＰ１０１に応じて異なるポリシーデータを配信することも可能となっている。そのため、ポリシーサーバへの接続に用いたＡＰ毎に、タスクの実行優先度を変化させることができる。これにより、様々な場所に応じて実行されるタスクおよび実行順をある程度変化させることが可能となり、ユーザに対して、ゲーム装置１を持ち歩く楽しみを提供できる。すなわち、ゲーム装置１を所持していろいろな場所に外出させる楽しみを与えることができる。

更に、上記実施形態では、ポリシーサーバに接続した際に、専用ＡＰ１０１ごとに異なる識別子だけではなく、ゲーム装置本体に設定されている国情報をも用いて、配信するポリシーデータを決定している。そのため例えば同じ専用ＡＰ１０１に接続した複数のゲーム装置１であっても、それぞれに設定されている国情報に応じて異なるポリシーデータを受信させることができる。

また、専用ＡＰ１０１ではない、例えばユーザの自宅のＡＰ１０２を経由してポリシーサーバにアクセスしたようなときでも、上記国情報に応じて異なるポリシーデータを配信することが可能である。

また、上記実施形態では、ポリシーデータの適用に際して、アプリＩＤとタスクＩＤを用いているため、アプリケーション毎にタスクの実行優先度を変更することが可能である。そのため、上記国情報と当該アプリケーションとの組み合わせで、より柔軟な実行優先度の変更が可能である。

また、インストール処理に関して、システムアップデートの場合は、オン・ザ・フライでインストールしながらも、その反映についてはユーザに確認するようにしている。そして、確認がとれれば、実体ファイルへの参照情報を変更するようにレジストリを変更して再起動することによりシステムのアップデートを反映している。これにより、システムのアップデートに際にユーザに与える待ち時間を短縮することができる。また、システムアップデート以外の、例えば無料アプリケーション等の、影響度の低いアプリケーションのインストールについてはユーザの確認無しでインストールする。そのため、ユーザの利便性をより高めることができるほか、ユーザが気づかないうちにインストールが行われており、ゲーム装置１のソフトウェア構成が変化しているので、ユーザに新たな驚きを与えることができ、かつ、新たにインストールされたアプリケーションをプレイしてもらうためのきっかけを与えることができる。

また、タスクの次回実行時刻（次回起床時刻）について、次回実行予定時刻が現在時刻からあまりに近い場合は、所定時間内はタスクが実行されないように調整している。これにより、あまりに短い時間間隔でタスクが頻繁に実行されることを防ぎ、無駄な処理や無駄なネットワークトラフィックを省くことが可能となる。また、次回実行時刻があまりにも先の時刻すぎる場合も時間調整を行っているため、ある程度定期的に接続を試みさせることが可能である。

また、上記実行優先度として、単純に優先度を示す”HIGH”、”MEDIUM”、”LOW”の他、実行しないことを示す”STOPPED”や、最優先で実行させる”EXPEDITE”という値を利用している。そして、上記のようにポリシーデータを受信させて、これら実行優先度の変更が可能となっている。そのため、”STOPPED”や”EXPEDITE”を利用することで、ゲーム装置１で実行されるタスクに関して、ある程度、サーバ側（ネットワークサービスの提供者側）から制御することも可能である。

なお、上記実施形態においては、「スリープモード」に移行する操作やスリープモードを解除する操作として、折りたたみ式のハウジングを有するゲーム装置１を閉じる／開く、という操作を例に挙げたが、これに限らず、ボタン操作で移行や解除をするようにしてもよい。

また、上記実施形態では、無線モジュール処理における「スリープモード」か否かの判定で、給電状態フラグ３０４にアクセスできなければスリープ中と判定し、スリープ中であればこれを解除する命令をＣＰＵ３１に発行する例を挙げた。「スリープモード」の解除については、この例の他、「スリープモード」であるか否かを直接的に判断するのではなく、次のような処理を行っても良い。例えば、ゲーム装置１が現在「スリープモード」であるか否かに関わらず、無線通信モジュール３４は、ＣＰＵ３１に対してスリープを解除するための命令を発行する。そして、ＣＰＵ３１側において、命令を受けたときにスリープ中であったならばスリープの解除を行い、スリープ中でないならば当該命令を無視する、という処理を行うようにしても良い。また、このような処理は、無線通信モジュール３４とＣＰＵ３１との間だけではなく、マイコン３７とＣＰＵ３１との間等でも適用可能である。つまり、「スリープモード」か否かを判断し、「スリープモード」であるときはこれを解除するための処理全般について、上記のような処理方法を適用可能である。

また、上記実施形態では、１つのタスクとしては所定のデータの「送信」あるいは「受信」のみを行うものを「タスク」の例としてあげたが、この他、「送受信」を行う処理を１つのタスクとした場合であっても本発明は適用可能である。

また、上記実施形態では、タスクの次回実行時刻５３７に基づいて次回起床時刻３０５を設定していた。この他、タスクの次回実行時刻に関係なく、予め決められた所定の時間間隔で定期的にＡＰのスキャンを行うようにしてもよい。

また、上記実施形態では、専用ＡＰ１０１の一例として、上記のようなベンダー特定情報がビーコンに含まれるか否かで専用ＡＰ１０１を識別していた。この他、このようなベンダー特定情報を有していない一般のＡＰ１０２（例えばユーザの自宅のＡＰ）についても、専用ＡＰと同じ扱いで動作させるようにしても良い。この場合は、このような一般ＡＰ１０２のＥＳＳＩＤを上記専用ＡＰ識別情報４０４として記憶させるようにする。そして、受信したビーコンに含まれるＥＳＳＩＤが当該記憶させたＥＳＳＩＤと一致するか否かを判定することで、上記専用ＡＰ１０１の場合と同様の処理を行うようにしても良い。

また、専用ＡＰ１０１の識別に関しては、上記ベンダー特定情報の代わりとして、専用ＡＰ１０１のＭＡＣアドレスやＩＰアドレスを利用するようにしても良い。

また、上記実施形態では、ポリシーデータの取得に際して、本体設定データ５６０内の国情報を用いる場合を例に挙げたが、この他、ゲーム装置１の製造番号やシリアル番号、ＩＰアドレス、ユーザの居住地域、ユーザ名、ユーザの性別や誕生日、ユーザの好きな色、のような情報を利用してもよい。これらの情報はいずれも本体設定データ５６０に記憶され、また、その内容もユーザによって適宜変更可能とすればよい。

また、上記実施形態では、ポリシーデータの受信に関して、上記専用ＡＰ１０１経由の場合は、当該専用ＡＰ１０１を示すＡＰ識別子＋国情報に基づいてポリシーデータが選択され、専用ＡＰ１０１経由ではないときは国情報のみに基づいてポリシーデータが選択されていた。この他、本体設定データ５６０の情報を参照することなく、例えば、専用ＡＰ１０１経由時は、ＡＰ識別子のみに基づいてポリシーデータが選択され、専用ＡＰ１０１経由ではないときは、予め用意されている共通的なポリシーデータを選択したり、あるいは、ポリシーデータの受信自体を行わないようにしてもよい。

また、上記実施形態では、ポリシーデータについてはポリシーサーバに記憶する場合を例に挙げていたが、この他、専用ＡＰに上記ポリシーデータを記憶させておき、専用ＡＰ１０１との接続が確立した後、ゲーム装置１にポリシーデータがダウンロードされるようにしてもよい。また、ＡＰから発信されるビーコンに上記ポリシーデータを含めるようにしても良い。この場合は、ＡＰへの接続が確立せずとも、ＡＰの探索と同時にポリシーデータの受信および適用が可能となる。また、このような場合も、専用ＡＰ１０１毎に内容の異なったポリシーデータを記憶させればよい。但し、ポリシーデータの管理の観点からすれば、一元管理が可能なように１つのポリシーサーバ１０３に格納されるほうが好ましい。

また、タスクの生成に関して、上記ポリシーデータにタスクを生成するためのデータを含めるようにしても良い。この場合は、ポリシーデータを受信した後に、ゲーム装置１において、当該ポリシーデータに含まれるタスク生成用のデータ（パラメータ）に基づいて新規のタスクが生成され、実行されることになる。

また、システムのアップデート処理に関して、上記実施形態では、システムアップデートの要否の判断に、最新システムの更新日時を利用していたが、これに限らず、バージョン情報を利用するようにしても良い。この場合は、システムのアップデート用データにバージョン情報を含ませるようにすればよい。

また、システムアップデートの反映の確認の際、上記実施形態では、反映しないことが選ばれたとき、アップデート用のデータをすぐに破棄していた。これに限らず、何度か確認を行い、反映しないことが所定回数続けて指示されたときにアップデート用のデータを破棄するようにしてもよい。これにより、ユーザの誤操作によってアップデート用のデータが破棄されてしまうことを防ぐことが可能となる。

また、上記実施形態では、タスクに「消尽回数」が設定されていた。そして、消尽回数が０になったタスクであっても、ポリシーデータの適用の結果、消尽回数が加算されることがあった（つまり、タスクが復活していた）。このような、ポリシーデータによるタスクの復活に限らず、ゲーム装置１のシステムが消尽回数が０になったタスクの中からランダムに選択したタスクについて、その消尽回数を加算するような処理を行っても良い。

また、その他、消尽回数を利用して、タスクの実行頻度が徐々に低下していくような制御を行っても良い。例えば、以下のような制御を行うことが考えられる。
（１）まず、消尽回数が初期値として３０に設定されているタスクがあり、当該タスクが毎日実行されたとする。このとき、毎日実行されたか否かの判断方法としては、消尽回数が減ったか否かの確認を毎日行ってもよいし、３０日経過した時点で消尽回数が０になっているか否かを確認するようにしてもよい。また、何日か実行されない日があっても許容するようにしてもよい。
（２）毎日タスクが実行されて、消尽回数が０になった後、３０日間は、１０日に１回タスクが実行されるようにする。例えば、毎回１／１０の確率でタスクが実行されるようにしたり、１０日目、２０日目、３０日目というように、適宜実行日を決めるようにしてもよい。
（３）更に、その後の９０日間は、３０日に１回タスクが実行されるようにする。例えば、１／３０の確率で実行させたり、実行日を予め決めるようにしてもよい。
（４）更に、その後の１２０日間は、６０日に１回タスクが実行されるようにする。例えば、１／６０の確率でタスクを実行させたり、予め実行日を決めるようにしてもよい。
（５）そして、上記の１２０日が経過すれば、それ以降は実行しないようにする。例えば、タスクを消去してもよいし、消去せずポリシーデータによる制御などの別のきっかけで実行する余地を残してもよい。
これにより、しばらく使用していなかったアプリケーションに関するタスクの消尽回数が何らかのきっかけで復活しタスクが実行されるので、ユーザに驚きを与えることができる。

また、上記実施形態では、ゲーム装置１が起動されたときに実行される起動時処理においてメニュー処理が実行された結果、ゲーム装置１にインストールされているアプリケーションがスキャンされ、その一覧がメニューとして表示されていた。そのため、例えば、ゲーム装置１が「スリープモード」のときにユーザが電源ボタン１４Ｆを押下する（つまり、ゲーム装置１を起動させる）と、「スリープモード」が解除され、図４等で示したようなアプリケーションアイコンが並べられたメニュー画面が即時に表示される。また、ゲーム装置１に通電が全く行われていない状態（電源オフの状態）のときにユーザが電源ボタン１４Ｆを押下してゲーム装置１の電源をオンにしたときも同様である。このように、アプリケーションの一覧であるメニュー画面はゲーム装置１の起動時に表示されるものであるが、この「起動時」に関しては、上記のような即時の場合に限らない。例えば、ゲーム装置１を起動させたときは、まず、メーカーのロゴや「ユーザへの注意事項」のような通知事項が表示された後に、上記のようなメニュー画面が表示されるような場合も含む。また、その他、メニューが階層構造であるような場合も含む。例えば、起動時は、まず、「ゲーム」「音楽」「写真」等のように、ゲーム装置１にインストールされている各種アプリのジャンルを示すジャンルメニューが表示され、いずれかのジャンルが選択されると、このジャンルに属するアプリケーションの一覧が表示されるような場合も含む。さらに複数の階層にわたってもよい。

また、上記実施形態では、タスク生成に際して（上記ステップＳ１２９やステップＳ１３０）、実行優先度に任意の値を設定する場合を例に挙げた。しかし、実行優先度については、タスク生成時に必ずしも何らかの値が設定される必要はなく、実行優先度が未設定の状態でタスクが生成されるようにしても良い。そして、上記ポリシーデータの適用によって初めて実行優先度が設定されるようにしても良い。更には、実行優先度だけに限らず、消尽回数等についても、最初は未設定のままタスクが生成され、ポリシーデータの適用によって初めてその内容が設定されるようにしても良い。

また、上記実施形態では、携帯型のゲーム装置を情報端末の例としたが、その他の携帯型情報端末、例えば、無線ＬＡＮ機能を搭載したＰＤＡやノートパソコン等にも有用である。

また、上記実施形態では、ユーザがシステムアップデートの適用を拒否した場合、所定期間経過ごとに適用を承認するまで繰り返し確認を促すようにしているが、（１）所定期間経過を待たずに毎回確認を促すようにしてもよいし、（２）数回確認を促し、すべて拒否された場合には適用を行わずに、システムアップデート用のファイルを破棄するようにしてもよい。

また、上記実施形態では、複数の新規アプリをダウンロードした後にメニューに遷移したときに、プレゼントアイコン１１２で表示される新規アプリは１件のみであり、その他はメニューに表示されず、今回プレゼントアイコン１１２で表示されているアプリケーションがタッチされて固有のアイコン状態になった後、メニューに再度遷移したときに他のアプリケーション（１件）がプレゼントアイコン１１２で表示されている。これに限らず、新たに受信した複数のアプリケーションを同時にすべてプレゼントアイコン１１２で表示しても良い。

また、上記実施形態のメニュー処理に関して、「システム更新を適用するための確認を行うか」「アプリケーションのインストール処理に移るか」という判断は、それぞれ「システムインストール済みフラグがオフであるか（オフの場合はダウンロードしたものが適用されていないため、適用の確認を行う）」、「システムインストール済みフラグがオンであり（オンの場合はダウンロードしたシステム更新が反映されたことを示す）、かつ、アプリインストール必要フラグがオンか（オンであれば、前回取得したインストールリストにアプリの更新が載っているため、ダウンロード及びインストールを行う）」という条件判断にて行っていた。この他、メニュー処理プログラムがインストールプログラムに問い合わせを行い、インストールプログラムが問い合わせに応じて「ダウンロードしたシステムが適用されていないので確認を行う」「システム更新は済んだがアプリインストールが済んでいないので行う」というような指示を返すようにしてもよい。

また、上記実施形態のシステムインストール処理やアプリインストール処理において、システムやアプリをダウンロードするための受信タスクについては、即時実行される場合を例に挙げたが、この他、数十分〜数時間後の時刻に実行されるように設定してもよい。

また、上記実施形態においては、インストールリスト５８０に更新があったか否かの判定については、ＨＴＴＰレスポンスコードを参照することによって、ダウンロード時に判断するようにしていた。この他、一旦インストールリスト５８０のダウンロードを行った後、ゲーム装置１に記憶されている過去のインストールリストと当該ダウンロードしたインストールリスト５８０を比較することによって判断しても良い。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。第２の実施形態では、上述の第１の実施形態で説明したような処理を用いたアプリケーションの一例として、「ボトルメールアプリケーション」というアプリケーション処理（以下、単にボトルメールアプリと呼ぶ）について説明する。なお、当該第２の実施形態に係るゲーム装置は、上述した第１の実施形態と同様であるため、同一の参照符号を付して詳細な説明を省略する。

図５２および図５３は、本発明の第２の実施形態に係るボトルメールアプリの処理概要を示す図である。図５２は、ゲーム装置１と、第１の実施形態で図１５を用いて説明したすれ違い通信用の送信用ボックス５２３および受信用ボックス５２４（以下の説明では、「すれ違い用送信ボックス」、「すれ違い用受信ボックス」と呼ぶ）と、タスクにおける通信で用いられるタスク受信キャッシュ５５３およびタスク送信用データ５５６とを抜き出して模式的に示した図である。図５２では、ゲーム装置１を示す四角形の左上にすれ違い用受信ボックス５２４を示し、当該四角形の右側に、上から順にタスク受信キャッシュ５５３、タスク送信用データ５５６、すれ違い用送信ボックス５２３を縦に並べて示している。

このような模式図を前提として、図５３を用いて第２の実施形態にかかる処理概要を説明する。図５３においては、ゲーム装置Ａ〜ゲーム装置Ｄが示されている。これらのゲーム装置にはボトルメールアプリがインストールされているものとする。また、図５３では、ボトルメールサーバも示されている。本実施形態にかかるボトルメールアプリは、ゲーム装置Ａで作成された「ボトルメール」と呼ばれるメール（図５３では「ＢＭ」として示す）を、すれ違い通信を用いて他のゲーム装置に次々に転送していく、つまり、メールを放流できるアプリケーションである。

図５３において、まず、ゲーム装置Ａでボトルメールが作成され、すれ違い用の送信ボックスに格納される。このとき、当該ボトルメールには「世代情報」が設定される。この「世代情報」で示される回数だけ、当該ボトルメールの転送が可能であるが、「世代情報」を設定しない場合は、回数に関係なく当該ボトルメールの転送が可能である。その後、すれ違い通信が行われることで、当該ボトルメールがゲーム装置Ａからゲーム装置Ｂに移動する。すなわち、ゲーム装置Ａのすれ違い用送信ボックスからゲーム装置Ｂのすれ違い用受信ボックスに移動される。

その後、ゲーム装置Ｂにおいてボトルメールアプリが実行されると、ゲーム装置Ｂのすれ違い用受信ボックスからすれ違い用送信ボックスへ、当該ボトルメールが移動される。このとき、ゲーム装置Ｂにおいて、ボトルメールの世代情報に所定値が加算される。更に、ゲーム装置Ｂにおいて、ボトルメールサーバへ送信するための付加情報（図５３では「Ｉｎｆｏ」と示す）が生成される。この「Ｉｎｆｏ」には、当該ボトルメールと、ゲーム装置Ｂの所有者の名前と、上記加算後の世代情報等が含まれる。そして、当該「Ｉｎｆｏ」を適当な時期にボトルメールサーバに送信するための「送信タスク」も生成・登録される。その結果、適当なタイミングで「送信タスク」が実行され、ゲーム装置Ｂから「Ｉｎｆｏ」がボトルメールサーバに送信される。ボトルメールサーバでは、当該情報を履歴情報（図５３では「Ｌｏｇ」と示す）として蓄積する。

その後、ゲーム装置Ｂとゲーム装置Ｃとの間ですれ違い通信が発生し、ボトルメールがゲーム装置Ｂからゲーム装置Ｃに移動する。その後、ゲーム装置Ｃにおいてボトルメールアプリが実行されると、上記ゲーム装置Ｂの場合と同様に、すれ違い用受信ボックスからすれ違い用送信ボックスへ当該ボトルメールが移動され、そして、世代情報が加算され、上記「Ｉｎｆｏ」およびこれに関する「送信タスク」も生成される。そして、適当なタイミングで、ゲーム装置Ｃからも「Ｉｎｆｏ」がボトルメールサーバに送信され、「Ｌｏｇ」に蓄積される。

その後、ゲーム装置Ｃとゲーム装置Ｄの間ですれ違い通信が発生し、ボトルメールがゲーム装置Ｃからゲーム装置Ｄに移動する。ゲーム装置Ｄにおいても、ボトルメールアプリが実行されることによって、すれ違い用受信ボックスからすれ違い用送信ボックスへの当該ボトルメールの移動、上記世代情報の加算や「送信タスク」による「Ｉｎｆｏ」の送信が行われる。

このように、ゲーム装置Ａで作成されたボトルメールが、すれ違い通信によって他のゲーム装置に次々に転送されている。その一方で、当該ボトルメールを受信したゲーム装置Ｂ、Ｃ、Ｄでは、上記「Ｉｎｆｏ」が適宜ボトルメールサーバに送信されている。そのため、ゲーム装置Ａのユーザは、ボトルメールサーバに蓄積されている「Ｌｏｇ」を取得する事で、自己の放流したボトルメールが何人の間で流通したかや、最後の受取人が誰か等、放流したボトルメールのその後の状況を知ることが可能となる。そして、本実施形態では、このような「Ｌｏｇ」を取得するために「受信タスク」を生成し、適当な時期に「Ｌｏｇ」を受信するようにしている。

つまり、第２の実施形態では、「ローカル通信（すれ違い通信）」と「インターネット通信」とを連携させることにより、今までにない新たな楽しみ方が可能なアプリケーションを提供することが可能である。

以下、第２の実施形態にかかる処理の詳細について説明する。上記のような処理は、ゲーム装置１において実行される「ボトルメールアプリ処理」と、ボトルメールサーバにおいて実行される「ボトルメールサーバ処理」とが連動することで実現される。まず、本処理において用いられるデータに関して説明する。ゲーム装置１において実行される処理においては、基本的には、上記第１の実施形態と同様のデータが用いられる。但し、「ボトルメールアプリ」のデータとして、上記「ボトルメール」や上記付加情報（図５３の「Ｉｎｆｏ」）を示すデータが適宜生成されることになる。

一方、ボトルメールサーバでは、上述したような処理を実行するためのプログラムの他、上述した履歴情報データ（図４５の「Ｌｏｇ」）が記憶されることになる。図５４は、当該履歴情報データのデータ構造の一例を示す図である。図５４に示すように、履歴情報データは、複数のボトルメール履歴データ１６１の集合で構成され、各ボトルメール履歴データ１６１は、アップロード数１６２と複数の転送情報１６３で構成される。アップロード数１６２は、ゲーム装置１から上記付加情報等がアップロードされた回数を示す。この値は、換言すれば、そのボトルメールが転送された回数を示す事にもなる。転送情報１６３は、ボトルメールの転送先となったゲーム装置１（図５３ではゲーム装置Ｂ〜Ｄ）に関する情報であり、世代情報１６４、送信者名１６５、ＡＰ情報１６６、メール内容１６７の集合で構成される。世代情報１６４および送信者名１６５は、ゲーム装置１から上記付加情報として送信されてきたデータである。ＡＰ情報１６６は、上記付加情報の送信の際に用いられたＡＰを示すための情報である。この情報と後述するＡＰ地域テーブルに基づき、付加情報が送信されたときにゲーム装置１が居た地域が特定可能となる。メール内容１６７は、付加情報と同時に送信されてきたボトルメールの内容（本文）である。転送先でボトルメールの内容が加工されることも想定し、その変更履歴を参照可能なように転送先それぞれにおけるボトルメールを送信したものである。また、その他、図示は省略するが、各ボトルメールを一意に識別するための情報等も含まれる。

また、ボトルメールサーバには、ＡＰの設置されている地域を特定するためのデータも記憶される。図５５は、ＡＰとその設置されている地域との対応関係を定義したＡＰ地域テーブルの一例である。図５５に示すようなテーブルに相当するデータに基づき、ボトルメールサーバは上記ＡＰ情報１６６に基づいた地域の特定が可能となる。

図５６および図５７は、ゲーム装置１で実行される上記ボトルメールアプリ処理の詳細を示すフローチャートである。なお、図５６において、ステップＳ３５１〜Ｓ３５４の処理と、Ｓ３６７〜Ｓ３７３にかかる処理は、上記図３３および図３４で説明したステップＳ１２１〜Ｓ１２４の処理、および、ステップＳ１３４〜Ｓ１４０の処理と同様である（これらの処理で扱われるデータの内容は、上述のようなボトルメールに関するデータとなる）。そのため、これらの処理については詳細な説明は省略する。

図５６において、ステップＳ３５４の次に、ステップＳ３５５において、ボトルメールに設定されている（付随している）世代情報に所定値が加算される。次に、ステップＳ３５６において、世代情報が閾値未満であるか否かが判定される。この閾値は、例えば、ボトルメールアプリにおける規定値として予め設定されている。当該判定の結果、世代情報が閾値未満ではないと判定されたときは（ステップＳ３５６でＮＯ）、当該ボトルメールはこれ以上転送できないとして、後述するステップＳ３６０に処理が進められる。

一方、閾値未満であると判定されたときは（ステップＳ３５６でＹＥＳ）、当該ボトルメールは転送可能であることを示すため、ステップＳ３５７において、当該ボトルメールを、すれ違い通信を用いて他のゲーム装置に転送するための処理が実行される。すなわち、当該ボトルメールアプリに対応付けられているスロット５２１のアプリＩＤ５２２に、当該ボトルメールアプリを示す値が記憶される。更に、上記ステップＳ３５４で取得されたボトルメール（セーブデータ５５５内のすれ違い受信データ５５８に格納されている）が、当該スロット５２１の送信用ボックス５２３に移動される。

次に、ステップＳ３５８において、ボトルメールサーバに送信するための付加情報データ（図５３の「Ｉｎｆｏ」）が生成されてセーブデータ５５５に格納される。すなわち、上記世代情報と、本体設定データ５６０から取得されるユーザ名を含むデータが作成されて、上記ボトルメールと共にタスク送信用データ５５６に格納される。次に、ステップＳ３５９において、上記ステップＳ３５８で準備されたデータを適当な時期にボトルメールサーバに送信するための「送信タスク」が生成される。

次に、ステップＳ３６０において、新たに放流するボトルメールが（ユーザによって）作成されたか否かが判定される。その結果、新たなボトルメールが作成されていなければ（ステップＳ３６０でＮＯ）、後述のステップＳ３６３に処理が進められる。一方、新たなボトルメールが作成されていれば（ステップＳ３６０でＹＥＳ）、次に、ステップＳ３６１において、当該新たに作成されたボトルメールをすれ違い通信によって他のゲーム装置１に転送するための準備が行われる。すなわち、上記アプリＩＤ５２２にボトルメールアプリを示す値が格納される。更に、送信用ボックス５２３に当該新たに作成されたボトルメールが格納される。なお、上記ステップＳ３５７においてもボトルメールが格納されていた場合は、結果的に、他のゲーム装置１から受けたボトルメールと、自己の作成したボトルメールとが併存して格納される状態となる。

次に、ステップＳ３６２において、自己の作成したボトルメールの放流後の状況を示す履歴情報データ（上記図５３の「Ｌｏｇ」）をボトルメールサーバから取得するための「受信タスク」が生成される。

次に、図５７のステップＳ３６３において、上記放流後のボトルメールの状況を確認する旨の指示がユーザによって行われたか否かが判定される。その結果、当該指示が行われていないと判定されたときは（ステップＳ３６３でＮＯ）、後述のステップＳ３６７に処理が進められる。

一方、上記確認指示がユーザによって行われたと判定されたときは（ステップＳ３６３でＹＥＳ）、ステップＳ３６４において、上記放流後のボトルメールの状況を示す履歴情報データをボトルメールサーバから受信するための即時実行型のタスクが生成され、即時に実行される。次に、ステップＳ３６５において、上記タスクの即時実行の結果、タスク受信キャッシュ５５３に当該ボトルメールアプリ向けの新規データ（ここでは受信された履歴情報データ）が存在するか否かが判定される。その結果、存在していなければ（ステップＳ３６５でＮＯ）、後述するステップＳ３６７に処理が進められる。一方、ボトルメールアプリ向けの新規データがあると判定されたときは（ステップＳ３６５でＹＥＳ）、ステップＳ３６６において、当該新規データが当該ボトルメールアプリのセーブデータ５５５内のタスク受信データ５５７に移動される。このようにセーブデータ５５５内に移動されることで、本ボトルメールアプリから当該履歴情報データにアクセス可能となる。

その後、ステップＳ３６７において、図５６のステップＳ３６２または図５７のステップＳ３６４で生成した「受信タスク」の結果、本ボトルメールアプリ向けの何らかの新規なデータが在るか否かが判定される。その結果、新規なデータがなければ（ステップＳ３６７でＮＯ）、上記ステップＳ３５１に戻り処理が繰り返される。一方、新規なデータがあるときは（ステップＳ３６７でＹＥＳ）、ステップＳ３６８〜Ｓ３７３において、当該ボトルメールアプリに関するネットワークサービスが終了したか否かを判定する処理と、サービス終了のときはタスクとすれ違い通信用のデータをクリアする処理が実行される。この処理は、図３４を用いて上述したステップＳ１３５〜Ｓ１４０の処理と同様であるため、詳細な説明は省略する。

ステップＳ３７３の処理が終われば、ステップＳ３７４において、上記受信履歴情報が参照されて、「世代情報」、「受取人の名前」、「アップロード者数」、「地域」等の情報が表示される。ここで、「地域」に関しては、後述するボトルメールサーバの処理において、サーバ側で判断されて付加された情報である。

次に、ステップＳ３７５において、本ボトルメールアプリを終了するか否かが判定され、終了しないと判定されたときは（ステップＳ３７５でＮＯ）、上記ステップＳ３５１に戻り、処理が繰り返され、終了すると判定されたときは（ステップＳ３７５でＹＥＳ）、本ボトルメールアプリ処理が終了される。以上で、ボトルメールアプリの説明を終了する。

次に、上記ボトルメールアプリに対応して、上記ボトルメールサーバで実行される処理について説明する。図５８は、当該ボトルメールサーバの処理の詳細を示すフローチャートである。図５８において、まず、ステップＳ３９１において、上述したような「送信タスク」（図５６のステップＳ３５９で生成されたタスク）の実行によりゲーム装置１から送信されたデータ（上記図５３の「Ｉｎｆｏ」）を受信したか否かが判定される。その結果、受信していないと判定されたときは（ステップＳ３９１でＮＯ）、後述のステップＳ３９４に処理が進められる。一方、受信したと判定されたときは（ステップＳ３９１でＹＥＳ）、ステップＳ３９２において、受信したデータが上記ボトルメール履歴データ１６１として格納される（上記図５３の「Ｌｏｇ」として格納される）。

次に、ステップＳ３９３において、当該受信したボトルメールにかかるアップロード数１６２に１が加算される。

次に、ステップＳ３９４において、上記ゲーム装置１からの履歴情報データのリクエストがあったか否かが判定される。当該リクエストは、上記「受信タスク」（図５６のステップＳ３６２または図５７のステップＳ３６４で生成されたタスク）の実行によって発行されるものである。当該判定の結果、リクエストを受信していないと判定されたときは（ステップＳ３９４でＮＯ）、上記ステップＳ３９１に戻り、処理が繰り返される。一方、リクエストを受信したと判定されたときは（ステップＳ３９４でＹＥＳ）、ステップＳ３９５において、上記履歴情報データが参照され、当該リクエストの内容に対応するボトルメール履歴データ１６１が読み出される。なお、ボトルメール履歴データ１６１の特定手法としては、例えば、ボトルメールの作成者と作成日時、作成されたゲーム装置１に固有の番号等に基づいて所定のＩＤ番号を生成し、これをボトルメール自体のデータに埋め込むようにしておく。そして、上記リクエストに際して、当該ＩＤを当該リクエストに含めることで、ボトルメール履歴データ１６１を特定すること等が考えられる。

次に、読み出されたボトルメール履歴データ１６１のＡＰ情報１６６が取得され上記ＡＰ地域テーブル（図５５参照）が参照されることで、当該ＡＰ情報１６６に対応付けられている地域１７２が取得される。

次に、上記読み出されたボトルメール履歴データ１６１の内容と上記地域１７２に基づいて履歴情報データが作成され、リクエスト元のゲーム装置１に送信される。その後、上記ステップＳ３９１に戻って処理が繰り返される。以上で、ボトルメールサーバの処理の説明を終了する。

上記のように、第２の実施形態では、あるゲーム装置１で作成されたボトルメールをすれ違い通信を用いて他のゲーム装置１に伝播させる。そして、すれ違い通信で当該ボトルメールを受信したゲーム装置１では、当該受信したデータにユーザ名やＡＰ情報等の付加情報を加えてボトルメールサーバに送信している。これにより、上記ボトルメールの作成者は、ボトルメールサーバに問い合わせを行うことにより、自己が作成し、放流したボトルメールの現在状況を確認することが可能となる。更に、最終的な状態だけでなく、途中でボトルメールの伝播に関わったユーザに関する情報を確認することも可能となる。このように、「ローカル通信」（すれ違い通信）と「インターネット通信」（ボトルメールサーバとの通信）を連動させることで、今までにない新しい楽しみ方をユーザに提供する事が可能となる。

なお、上記実施形態では、ボトルメールの作成者が自己の作成したボトルメールの現在状況を確認する際、「受信タスク」を生成するようにしていたが、必ずしも「タスク」を用いる必要はなく、ユーザの操作に応じて（タスクは使わずに）適宜ボトルメールサーバにアクセスし、上記履歴情報データを取得するようにしても良い。ここで、放流した主だけでなく、伝播の途中に関わったゲーム装置１からボトルメールの現在状況を確認できるようにしても良い。

また、「地域」の特定に関して、上記実施形態ではボトルメールサーバ側でＡＰ情報１６６に基づいた「地域」の特定がなされていたが、この他、ボトルメールサーバからゲーム装置１にＡＰ情報１６６を送信するようにし、ゲーム装置１側の処理で当該ＡＰ情報１６６に基づいて上記「地域」を特定するようにしても良い。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。第３の実施形態では、上述の第１の実施形態で説明したような、タスクによる送受信（インターネット通信）と、上記「すれ違い通信」（ローカル通信）を連携させた処理の一例を更に示す。より具体的には、タスクで受信したデータを「すれ違い通信」を利用して他のゲーム装置に送信する例と、逆に、「すれ違い通信」で他のゲーム装置から受信したデータを、タスクを用いて所定のサーバにアップロードする例について説明する。

まず、上記タスクの実行によってＡＰを介してサーバ等から受信したデータを「すれ違い通信」を用いて他のゲーム装置に送信する処理について説明する。例えば、上記タスクの実行によって取得された体験版や無料ゲーム等を、上記「すれ違い通信」を利用して他のゲーム装置１に送信する場合を想定する。この場合、例えば、ゲーム装置Ａにおいて上記タスクが実行された結果、体験版や無料ゲーム等が新規インストールされたとする。このとき、ゲーム装置Ａにおいて、当該体験版や無料ゲーム等のデータが上記すれ違い通信用データ５２０に設定されるように構成する。これにより、他のゲーム装置に「すれ違い通信」を介して送信することが可能となる。更に、受信したゲーム装置側においては、当該「すれ違い通信」で取得した体験版や無料ゲーム等が自動的にインストールされるようにしてもよい。このようにタスクを実行して受信し、すれ違い通信で他のゲーム装置１に送信されるデータは体験版や無料ゲーム等に限らず、何らかのゲームアプリケーションが用いるためのデータであってもよい。

次に、別の例として、他のゲーム装置から「すれ違い通信」で取得したデータを「送信タスク」を用いて所定のサーバにアップロードする処理について説明する。例えば、ユーザがＡＰの登録をゲーム装置１に行っていない等で、上記「ローカル通信」しかできない設定となっているゲーム装置Ｂを想定する。このような場合は、ゲーム装置Ｂにおいて、所定のサーバにアップロードするためのアップデータが作成され、更にこのアップデータを送信するための「送信タスク」を生成するためのタスク生成用データが作成されるようにする。このデータは、例えば、上記ポリシーデータと同じ構成であることが考えられる。そして、両データがすれ違い通信用データ５２０に格納されるように構成する。その結果、「すれ違い通信」でこれらのデータが上記ゲーム装置Ａに送信される。ゲーム装置Ａでは、「すれ違い通信」で受信した上記タスク生成用データに基づき「送信タスク」が生成される（上記ステップＳ１２９やＳ１３０と同様の処理が実行されればよい）。その結果、このタスクが実行されることによって、ゲーム装置Ｂで生成されたアップデータを、ゲーム装置Ａがゲーム装置Ｂに代わって所定のサーバに送信することが可能となる。

このように、「インターネット通信」と「ローカル通信」を連携させることで、複数のゲーム装置１の間で様々なデータのやりとりが可能となる。また、「インターネット通信」ができない設定となっているゲーム装置１についても、「ローカル通信」（すれ違い通信）を利用して他のゲーム装置を経由してデータを送受信することで、間接的に「インターネット通信」が可能となる。

（第４の実施形態）
次に、本発明の第４の実施形態について説明する。上述の第１の実施形態では、システムの更新およびアプリの更新に関して、まずシステムの更新に関する処理を行った後、アプリの更新処理が行われるという処理の流れとなっていた。つまり、システムの更新がある場合は、優先的にシステム更新が行われるようになっていた。これに対し、第４の実施形態では、まずアプリの更新に関する処理を行ってから、必要に応じてシステムの更新処理を行う。より具体的には、新規インストール、あるいは更新後のアプリの動作に必要なシステムのバージョンを判定し、これが現在のシステムのバージョンよりも新しい場合は、システムの更新を実行するという流れで処理が行われる。例えば、現在のシステムのバージョンが「１．０」であるとする。一方、新規配布にかかるあるアプリがあり、このアプリの動作に必要なシステムのバージョンが「２．０」であるとする。このような場合、当該アプリがダウンロードされるときに、システムの更新も行われる。また、アプリの更新があったときにシステムのインストールを付随的に行うため、アプリの更新がない限りは、システムの更新があるとしても、必ずしもこの更新が反映されないということもあり得ることになる。

上記のような処理を実現するために、第４の実施形態では、上記第１の実施形態のシステムインストール処理（及びアプリのインストール処理）の代わりに、例えば、図５９に示すような処理が実行される。図５９は、第４の実施形態にかかるインストール処理を示すフローチャートである。本フローチャートは、第１の実施形態における、図４７のステップＳ５４８のシステムインストール処理の代わりとして実行される。すなわち、インストールリストの取得が行われた際に実行される。まず、ステップＳ４１１において、上記インストールリスト５８０に載っている全てのアプリについて、以下に示すようなダウンロードのタスクを生成する処理が行われたか否かが判定される。その結果、まだ未処理のアプリが残っているときは（ステップＳ７１１でＮＯ）、ステップＳ７１２において、インストールリスト５８０に載っているアプリの中で未処理のものから一つが選択される。

次に、ステップＳ７１３で、選択されたアプリと同じアプリで同じバージョンのものが既にインストールされているか否かが判定される。その結果、同じアプリで同じバージョンのものが既にインストールされていれば（ステップＳ７１３でＹＥＳ）、当該選択されたアプリについてはインストールや更新の必要がないため、上記ステップＳ７１１に処理が戻される。一方、選択されたアプリと同じアプリがインストールされていない、または、インストールはされているが、バージョンが異なる（インストールされているもののほうが古いバージョンである）ときは（ステップＳ７１３でＮＯ）、ステップＳ７１４で、当該アプリの権利情報が所定のサーバからダウンロードされる。続くステップＳ７１５で、権利情報の正当性確認処理が実行される。この処理は、上記第１の実施形態で説明した処理と同様である。その後、ステップＳ７１６で正当性に問題がなかったか否かが判定され、問題が無ければ（ステップＳ７１６でＹＥＳ）、ステップＳ７１７において、選択されたアプリをダウンロードするための受信タスクが生成され、上記ステップＳ７１１に処理が戻される。一方、問題があったときは（ステップＳ７１６でＮＯ）、上記ステップＳ７１７の処理は行われずに、上記ステップＳ７１１に処理が戻される。また、本実施形態では、上記第１の実施形態におけるステップＳ４６４（対象年齢の判定処理）、ステップＳ４６５（製品版を所持しているときに体験版のインストールを排除する処理）、ステップＳ４６９（プレイ履歴条件の判定処理）等を省略しているが、そのような処理が加わってもよい。

一方、上記ステップＳ７１１の判定の結果、上記インストールリスト５８０に載っている全てのアプリについて上記のようなタスク生成処理が行われたと判定されたときは（ステップＳ７１１でＹＥＳ)、ステップＳ７１８において、インストールリスト５８０において示されるシステム構成と、ゲーム装置１の現在のシステム構成とが比較される。次に、図６０のステップＳ７１９において、比較の結果、両者が一致したか否か（差分はなかったか）が判定される。その結果、一致したと判定されたときは（ステップＳ７１９でＹＥＳ）、システムの更新は不要であるため、ステップＳ７２７へと移る。一方、一致しなかったと判定されたときは（ステップＳ７１９でＮＯ）、システムの更新の必要性があると考えられるため、システム更新に関する処理が実行される。まず、ステップＳ７２０において、インストールリスト５８０に載っているシステムの構成要素５８４の全てについて、以下の述べるようなチェック処理が行われたか否かが判定される。その結果、まだチェックしていない構成要素が残っているときは（ステップＳ７２０でＮＯ）、ステップＳ７２１において、未チェックの構成要素の中から、チェック対象とする構成要素が一つ選択される。

次に、ステップＳ７２２において、チェック対象として選ばれた構成要素がインストールすべきものであるか否かの判定が行われる。具体的には、現在のシステム構成の詳細リスト６４０が参照され、現在のシステムにおけるバージョンよりもチェック対象となっている構成要素のバージョンのほうが新しいか否か、または、チェック対象となっている構成要素は、現在のシステム構成には含まれていないか否かが判定される。その結果、チェック対象となっている構成要素のバージョンのほうが新しい、あるいは、現在のシステムにおいて導入されていない構成要素であるときは（ステップＳ７２２でＹＥＳ）、次に、ステップＳ７２３において、当該構成要素の権利情報が所定のサーバからダウンロードされる。続くステップＳ７２４において、当該権利情報の正当性確認処理が実行される。この処理は、上述の第1の実施形態で説明した正当性確認処理と同様の処理である。次に、ステップＳ７２５において、ステップＳ７２４の結果、正当性に問題がなかったか否かが判定され、問題が無ければ（ステップＳ７２５でＹＥＳ）、ステップＳ７２６において、選択されたシステムの構成要素をダウンロードするための受信タスクが生成され、上記ステップＳ７２０に処理が戻される。一方、問題があったときは（ステップＳ７２５でＮＯ）、上記ステップＳ７２６の処理は行われずに、上記ステップＳ７２０に処理が戻される。

一方、上記ステップＳ７２２の判定の結果、チェック対象となっている構成要素のバージョンと現在のシステムにおける構成要素のバージョンが同じであれば（ステップＳ７２２でＮＯ）、上記ステップＳ７２３〜Ｓ７２６の処理は行われずに、上記ステップＳ７２０に処理が戻される。

次に、上記ステップＳ７２０の判定の結果、インストールリスト５８０に載っているシステムの構成要素５８４の全てについて、上記のようなチェック処理が行われたと判定されたときは（ステップＳ７２０でＹＥＳ）、ステップＳ７２７において、上記ステップＳ７１７やステップＳ７２６で生成された受信タスクを実行するために、タスク実行処理が行われる。この処理は、図４３〜図４８を用いて上記第１の実施形態で説明した処理と同様であるため、説明は省略する。以上で、第４の実施形態にかかるインストール処理は終了する。

このように、第４の実施形態では、アプリに関するインストール処理をシステムに関するインストール処理よりも先に行う。これにより、アプリの状況に応じて必要なときにのみシステムの更新を行うことができる。換言すれば、アプリの動作に必要なシステムへの更新処理をより確実に実行することができ、アプリの動作に要求されるシステムのバージョンと実際にゲーム装置にインストールされているシステムのバージョンとの不整合に基づく誤動作が起こることを防ぐ事が可能となる。

なお、上記第４の実施形態では、アプリをダウンロードするための受信タスクとシステムをダウンロードするための受信タスクを生成した後、両者をまとめて実行するようにしているが（上記ステップＳ７２７）、この処理において、アプリの受信タスクとシステムの受信タスクのいずれを先に実行するかについてはどちらでもよい。ファイルのダウンロード（通信）に時間がかかること（更には、ゲーム装置本体を持ったユーザが移動中であるような場合）を考慮すると、アプリの受信タスクを先に行うようにした場合は、ユーザに驚きを与えるという点においてはシステムよりも効果的であるアプリを優先的に取得することが可能となる点で有利である。また、システムの受信タスクを先に行うようにすれば、特にダウンロードが途中で停止してしまったときに、システムの更新はダウンロードされることになり、旧バージョンのシステムでアプリが動作することによる誤動作が起こることをより確実に防ぐ事が可能となる点で有利である。

（第５の実施形態）
次に、第５の実施形態について説明する。上記第１の実施形態では、アプリやシステムについて自動的にダウンロードし、インストールする場合を例に挙げていたが、これと併用して、手動ダウンロードを可能としても良い。特に、アプリの取得に関しては、手動ダウンロードも併用することで、よりユーザに多様なアプリに接する機会を与えることができる。あるいは、ユーザが削除したアプリについては今後の自動インストールが停止される場合に、再度そのアプリを使用することをユーザが希望した場合に、手動によってダウンロードが行われるようにすれば、ユーザにとって大変便利となる。この場合、上記メニューから起動されるアプリの一つとして、手動ダウンロード用のアプリ（オンラインショッピングアプリ等）として実現すればよい。

図６１は、このような手動ダウンロードアプリの処理の一例を示すフローチャートである。当該手動ダウンロードアプリがメニューから起動されると、まず、ステップＳ７４１において、ダウンロード可能なアプリの一覧が表示される。そして、ユーザからの入力が受け付けられる。

次に、ステップＳ７４２において、上記一覧からいずれかのアプリ（のダウンロード指示）がユーザによって選択されたか否かが判定される。その結果、いずれかのアプリが選択されたときは（ステップＳ７４２でＹＥＳ）、ステップＳ７４３において、選択されたアプリの詳細情報が表示される。例えば、選択されたアプリのスクリーンショットや、紹介文、対象年齢等の各種情報、他のユーザからのレビュー等である。また、オンラインで購入するためのアプリに関する詳細情報であれば、価格に関する情報も表示される。次に、ステップＳ７４４において、選択されたアプリのダウンロードを行うための指示がユーザによってなされたか否かが判定される。オンラインで購入するアプリであれば、購入及びダウンロードを行うための指示がなされたか否かが判定される。ダウンロードを行うための指示がなされていないとき（ステップＳ７４４でＮＯ）、上記ステップＳ７４３に処理が戻される。一方、ダウンロードを行うための指示がなされたとき（ステップＳ７４４でＹＥＳ）、ステップＳ７４５に移る。なお、オンラインで購入するアプリであれば、ステップＳ７４４でＹＥＳであるとき、ステップＳ７４５に移る前に、選択したアプリケーションの購入処理が加わる。具体的には、クレジットカード番号等の購入情報の入力又は、予め購入に必要なポイントをチャージしておく形式であれば残りポイントのチェック等がなされる。そして、その後、本当にこのアプリを購入するか否かを最終的に確認するための画面を表示し、ユーザに購入の最終的な意思を問うようにすることが望ましい。最終的な意思が得られた場合に、クレジットカードによる実際の決済処理や、購入に必要なポイントの差し引き処理が行われ、ステップＳ７４５へと移る。

ステップＳ７４５において、選択されたアプリの権利情報がダウンロードされる。次に、ステップＳ７４６で、当該権利情報の正当性確認処理が実行される。当該処理は、上記ステップＳ４７２等の正当性確認処理と同様の処理である。

次に、ステップＳ７４７において、ステップＳ７４６の結果、正当性に問題がなかったか否かが判定され、問題が無ければ（ステップＳ７４７でＹＥＳ）、ステップＳ７４８において、選択されたアプリのダウンロードが行われる。ここでは、必ずしもタスクを生成して当該タスクを実行するという形を取る必要はない。しかし、タスク実行処理において行われた当該アプリケーションに関する各種設定処理は行われる必要がある。その後、上記ステップＳ７４１に処理が戻される。一方、正当性に問題があったときは（ステップＳ７４７でＮＯ）、上記ステップＳ７４８の処理は行われずに、上記ステップＳ７４１に処理が戻される。

一方、上記ステップＳ７４２の判定の結果、上記アプリ一覧からいずれのアプリも選択されなかったときは（ステップＳ７４２でＮＯ）、ステップＳ７４９において、当該手動ダウンロードアプリの終了がユーザによって指示されたか否かが判定される。終了指示がなければ（ステップＳ７４９でＮＯ）、上記ステップＳ７４１に戻って処理が繰り返され、終了指示があったときは（ステップＳ７４９でＹＥＳ）、当該手動ダウンロード処理は終了する。

このように、第５の実施形態では、自動ダウンロード・自動インストールと併用して、手動ダウンロードも可能としている。これにより、ユーザの利便性を向上させ、様々なアプリに触れる機会をより多く与えることが可能となる。

（第６の実施形態）
次に、第６の実施形態について説明する。上記第１の実施形態では、アプリやシステムについて自動的にダウンロードし、インストールする場合を例に挙げていたが、コンテンツと当該コンテンツを再生するアプリがセット（一体）になったコンテンツアプリを自動的にダウンロードし、インストールすることができる。このようなコンテンツアプリとしては、静止画像のコンテンツと静止画像を表示するための表示ビューアアプリがセットになったものや、動画像（映像）のコンテンツと動画像を再生するための再生ビューアアプリがセットなったものがある。また、コンテンツの種類としては、ゲームソフトや映画等の商品の紹介や宣伝を行う映像（または画像）データ、商品の引き換えや割引などに利用できるクーポンデータなどがある。

図６２は、このようなコンテンツアプリを実行したときに、ゲーム装置１の表示部に表示される画面例である。上側ＬＣＤ２２には、コンテンツの一例であるゲームソフトＡの映像が表示される。下側ＬＣＤ１２には、再生ビューアアプリの一例である操作画面が表示される。下側ＬＣＤ１２に表示される操作画面は、再生タイムラインバー２０１、再生コントロールボタン２０２、「詳細情報を見る」ボタン２０３、「購入する」ボタン２０４、ゴミ箱（削除）ボタン２０５、および「おわる」ボタン２０６を含む。再生タイムラインバー２０１は、上側ＬＣＤ２２で再生されている映像の開始からの経過時間または映像全体のうちのどの位置を再生中かを示すインジケータであり、ここを直接タッチすることにより、任意の位置から映像を再生することができる。再生コントロールボタン２０２は、映像の再生（または一時停止）、早送り、巻き戻しを指示するためのボタンである。「詳細情報を見る」ボタン２０３は、上側ＬＣＤ２２に表示されているコンテンツの詳細情報を見るためのボタンであり、ここをタッチすることにより、上述のステップＳ７４３へ進み、コンテンツの詳細情報を表示したり、コンテンツの購入およびダウンロードを行うことができる。ゴミ箱ボタン２０４は、コンテンツアプリ自体をゲーム装置１から削除するためのボタンであり、ここをタッチすることにより、コンテンツアプリの削除処理が行われる。「おわる」ボタン２０５は、コンテンツアプリの実行の終了を指示するためのボタンである。

図６３は、このようなコンテンツアプリに含まれるプログラム（再生アプリ）がＣＰＵ３１によって実行される処理の一例を示すフローチャートである。コンテンツアプリがメニューから起動されると、まずステップＳ７６１において、上側ＬＣＤ２２にコンテンツアプリに含まれるコンテンツの画像が表示される。ここで、コンテンツが映像の場合は、映像の先頭が表示される。続くステップＳ７６２において、下側ＬＣＤ１２に図６２で示すような操作画面が表示される。

次に、ステップＳ７６３において、ユーザから再生を制御するような指示、すなわち、再生タイムラインバー２０１または再生コントロールボタン２０２がタッチされたか否かが判定される。その結果、再生タイムラインバー２０１または再生コントロールボタン２０２が指示されたときは（ステップＳ７６３でＹＥＳ）、ステップＳ７６４において、上側ＬＣＤ２２に表示される映像の再生を制御する処理が実行される。例えば、再生タイムラインバー２０１の任意の位置が指示されたときは、当該位置に対応する映像を読み出して上側ＬＣＤ２２に表示する。また、再生コントロールボタン２０２が指示されたときは、指示されたボタンの種類に応じて、映像の再生（再生中は一時停止）、早送り、巻き戻しが実行される。その後、上記ステップＳ７６３に処理が戻される。

一方、上記ステップＳ７６３の判定の結果、ユーザから再生を制御するような指示が行われなかったときは（ステップＳ７６３でＮＯ）、ステップＳ７６５において、ユーザからコンテンツの詳細情報を表示する指示、すなわち、「詳細情報を見る」ボタン２０３がタッチされたか否かが判定される。その結果、「詳細情報を見る」ボタン２０３が指示されたときは（ステップＳ７６５でＹＥＳ）、上述のステップＳ７４３へ進み、詳細情報の表示、コンテンツの購入・ダウンロード処理等が実行される。

一方、上記ステップＳ７６５の判定の結果、ユーザからコンテンツの詳細情報を表示する指示が行われなかったときは（ステップＳ７６５でＮＯ）、ステップＳ７６６において、ユーザからこのコンテンツアプリを削除する指示、すなわち、ゴミ箱ボタン２０４がタッチされたか否かが判定される。その結果、ゴミ箱ボタン２０４が指示されたときは（ステップＳ７６６でＹＥＳ）、ステップＳ７６７において、このコンテンツアプリの削除命令を発行する。具体的には、ユーザからの削除指示を受け付けると、ゲーム装置１のＣＰＵがメニュー処理プログラム５０１に含まれる削除プログラムに対し、自身のプログラムを削除するための命令を発行する。その後、コンテンツアプリの実行が終了する。

ここで、図６４を用いて、削除命令受付処理について説明する。図６４で表される削除命令受付処理のフローは、メニュー処理プログラムの一部として存在し、ゲーム装置１が起動している間は常に実行されている。

ステップＳ７８０において、コンテンツアプリを含む、他のアプリケーションプログラムによって、削除命令が発行されたか否かが判定される。その結果、削除命令が発行されたときは（ステップＳ７８０でＹＥＳ）、ステップＳ７８１において、削除命令を発行したアプリケーションプログラムを削除する。具体的には、削除命令には発行元のアプリケーションプログラムのアプリを特定する情報が含まれており、その情報により特定されたアプリケーションプログラム５１１を、ＮＡＮＤフラッシュメモリ３３のプログラム領域５１５にから削除する。

一方、上記ステップＳ７８０の判定の結果、削除命令が発行されていないときは（ステップＳ７８０でＮＯ）、ステップＳ７８０に戻り、繰り返し判定が行われる。

一方、上記ステップＳ７６６の判定の結果、ユーザからこのコンテンツアプリを削除する指示が行われなかったときは（ステップＳ７６６でＮＯ）、ステップＳ７６８において、ユーザからコンテンツアプリを終了する指示、すなわち、「おわる」ボタン２０５がタッチされたか否かが判定される。その結果、「おわる」ボタン２０５が指示されたときは（ステップＳ７６８でＹＥＳ）、このコンテンツアプリの実行を終了する。

一方、上記ステップＳ７６８の判定の結果、ユーザからコンテンツアプリを終了する指示が行われなかったときは（ステップＳ７６８でＮＯ）、上記ステップＳ７６３に戻る。

なお、上記実施形態では、「詳細情報を見る」ボタン２０３が指示されたとき、コンテンツの詳細情報を表示し、そのコンテンツの購入・ダウンロードが行われる例を説明したが、予め図６２の下側ＬＣＤ１２に表示される操作画面に「購入」ボタンを設け、「購入」ボタンを指示することにより、コンテンツの詳細情報を表示することなく、直接コンテンツの購入及びダウンロードを行うようにしてもよい。

また、上記実施形態では、コンテンツアプリの削除は、ＣＰＵ３１がメニュー処理プログラム５０１を実行することにより行われる例を説明したが、コンテンツアプリのプログラム自体に削除プログラムを設けておき、コンテンツアプリのプログラムに含まれる削除プログラムを実行することにより、自身を削除するようにしてもよい。

また、上記実施形態では、コンテンツの詳細情報の表示、購入・ダウンロード処理は、コンテンツアプリのプログラムとは別のプログラムが行う例を説明したが、コンテンツアプリのプログラム自体に自身のコンテンツの詳細情報の表示、購入・ダウンロード処理を実行するためのプログラムを設けておき、当該プログラムを実行することにより、コンテンツの詳細情報の表示、購入・ダウンロード処理を行うようにしてもよい。

このように、第６の実施形態では、自動ダウンロード・自動インストールされたコンテンツアプリを実行中に、削除ボタンを指示するという簡単な操作で当該コンテンツアプリの削除が行えるので、ユーザは不要なコンテンツアプリを容易に削除することができる。特に、この実施形態のように、コンテンツアプリが自動でダウンロード・インストールされるような場合には、ユーザの知らないうちに多数のコンテンツアプリがインストールされることがあるので、上述のようなコンテンツアプリを簡単に削除できるような仕組みは有用である。

また、第６の実施形態では、自動ダウンロード・自動インストールされたコンテンツを実行することにより、ユーザにコンテンツの紹介映像を提示したり、クーポンを付与したりすることができ、さらに簡単な操作でコンテンツの詳細情報を表示したり、コンテンツの購入・ダウンロードを実行できるようにしたので、より多くのユーザにコンテンツを知ってもらう機会を作ることができ、コンテンツの販売促進に結びつけることができる。

なお、上記各実施形態において、ゲーム装置１において実行された一連の処理については、複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記ゲーム装置１が行っていた一連の処理のうちの一部の処理（例えば、アプリケーション処理の一部）がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。

本発明にかかる携帯型情報端末、携帯型情報システム、および携帯型情報端末制御プログラムは、ユーザの特別な操作を必要とせずに、新たなアプリケーションの新規インストール等を行うことができ、携帯型ゲーム装置やＰＤＡ、ノートパソコン等に有用である。

１…ゲーム装置
１１…下側ハウジング
１２…下側ＬＣＤ
１３…タッチパネル
１４…操作ボタン
１５、２６…ＬＥＤ
１６…マイクロフォン用孔
２１…上側ハウジング
２２…上側ＬＣＤ
２３…内側カメラ
２４…音抜き孔
２５…外側カメラ
２７…タッチペン
２８、２９…メモリカード
３１…ＣＰＵ
３２…メインメモリ
３３…ＮＡＮＤフラッシュメモリ
３４…無線通信モジュール
３５…第１メモリカードＩ／Ｆ
３６…第２メモリカードＩ／Ｆ
３７…マイコン
３９…ＲＴＣ
４０…開閉検出器
４１…電源管理ＩＣ
４２…電源回路
４３…Ｉ／Ｆ回路
４４…マイク
４５…アンプ

本発明の第１の実施形態に係るゲーム装置１の外観図 本発明の第１の実施形態に係るゲーム装置１のブロック図 本実施形態にかかるネットワーク構成の全体像を示す模式図 メニュー画面の一例 メニュー画面の一例 メニュー画面の一例 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 「すれ違い通信」について説明するための図 本実施形態で実行される各種機能（プログラム）の相関関係を示す図 マイコン３７に内蔵されている記憶領域に記憶される主なデータを示す図 無線通信モジュール３４に内蔵されている記憶領域に記憶される主なデータを示す図 ＮＡＮＤフラッシュメモリ３３に記憶されるプログラム、データを示す図 図１４のすれ違い通信用データ５２０のデータ構造の一例を示した図 図１４のタスクデータ５３０のデータ構造の一例を示した図 図１４のアプリ関連データ５５０のデータ構造の一例を示した図 図１４の受信ポリシーデータ５７０のデータ構造の一例を示した図 図１４のインストールリスト５８０のデータ構造の一例を示した図 マイコン３７によって実行されるマイコン処理を示すフローチャート 無線モジュール処理を示すフローチャート 無線モジュール処理を示すフローチャート 起動時処理の詳細を示すフローチャート 起動時処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート 図２３のステップＳ６１で示すメニュー処理の詳細を示すフローチャート アプリインストール処理の詳細を示すフローチャート アプリインストール処理の詳細を示すフローチャート 図３０のステップＳ４７１デ示した正当性確認処理の詳細を示すフローチャート 図２６のステップＳ４３２で示したアプリ更新適用処理の詳細を示すフローチャート 図２７のステップＳ４４１で示した各アプリの処理の詳細を示すフローチャート 図２７のステップＳ４４１で示した各アプリの処理の詳細を示すフローチャート 図３３のステップＳ１３１で示したタスク生成処理の詳細を示すフローチャート ローカル通信用ＢＧ処理の詳細を示すフローチャート ローカル通信用ＢＧ処理の詳細を示すフローチャート インターネット通信用ＢＧ処理の詳細を示すフローチャート 図３８のステップＳ１９１で示したポリシー処理の詳細を示すフローチャート 図３８のステップＳ１９１で示したポリシー処理の詳細を示すフローチャート ポリシーサーバ１０３のメモリマップを示す図 ポリシーサーバ１０３で実行される処理を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図３８のステップＳ１９２で示したタスク実行処理の詳細を示すフローチャート 図４３のステップＳ５５１で示した実行順ソート処理の詳細を示すフローチャート 図４７のステップＳ５４８で示したシステムインストール処理の詳細を示すフローチャート 図４７のステップＳ５４８で示したシステムインストール処理の詳細を示すフローチャート 第２の実施形態に係るボトルメールアプリの処理概要を示す図 第２の実施形態に係るボトルメールアプリの処理概要を示す図 ボトルメールサーバに記憶される履歴情報データのデータ構造の一例を示す図 ボトルメールサーバに記憶されるＡＰ地域テーブルの一例 ゲーム装置１で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート ゲーム装置１で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート ボトルメールサーバの処理の詳細を示すフローチャート 第４の実施形態にかかるインストール処理の詳細を示すフローチャート 第４の実施形態にかかるインストール処理の詳細を示すフローチャート 第５の実施形態にかかる手動ダウンロード処理の詳細を示すフローチャート コンテンツアプリの画面例 コンテンツアプリに含まれるプログラムによる再生処理のフローチャート 削除命令受付処理の詳細を示すフローチャート

次に、上記ステップＳ５２１の判定の結果、アプリのダウンロードタスクではないと判定されたときの処理について説明する。この場合は、図４５のステップＳ５３３において、上記処理対象タスクの内容が、システムの構成要素（システムプログラム）をダウンロードするためのタスクであるか否かが判定される。当該判定の結果、システムプログラムをダウンロードするタスクであるときは（ステップＳ５３３でＹＥＳ）、次に、ステップＳ５３４において、ダウンロード対象の構成要素は、既存の構成要素であるか否かが判定される。つまり、既存の構成要素のアップデートに該当するのか、新規の構成要素の取得に該当するのかが判定される。当該判定の結果、既存の構成要素のアップデートに該当する場合は（ステップＳ５３４でＮＯ）、ステップＳ５３６において、実際の（現在稼働中の）システムプログラムのファイル名とは別の名前で、オン・ザ・フライでシステムプログラム領域５１５にダウンロード対象の構成要素を格納する処理（ダウンロードの開始、または、開始済みであればダウンロードの継続）が実行される（例えば、実際のシステムプログラムのファイル名が「firmware001.bin」であるときは、「firmware002.bin」の名前で格納される）。そして、上記ステップＳ５３２に戻る。

次に、図４３のステップＳ５１２において、全てのタスクを実行し終えたと判定されたときの処理（ステップＳ５１２でＹＥＳ）について説明する。このときは、次回起床時刻３０５を設定するための処理が実行される。具体的には、まず、図４８のステップＳ５５１において、タスクデータ５３０内の全てのタスク設定５３１についての次回実行時刻５３７が読み込まれる。続くステップＳ５５２において、全タスクのうち、次回実行時刻５３７が最も早い時刻のタスクが検出される。そして、当該最も早い次回実行時刻が現在時刻から３０分以内であるか否かが判定される。当該判定の結果、３０分以内であると判定されたときは（ステップＳ５５２でＹＥＳ）、ステップＳ５５３において、現在時刻の３０分後の時刻を次回起床時刻３０５として設定する。つまり、一旦タスクが実行されると、その後、最低３０分間はタスクの実行が行われないように設定されることになる。これにより、あまりに頻繁に接続が行われてしまうことを防ぎ、ゲーム装置１の更なる省電力化や、ネットワークトラフィックの負荷の軽減を図ることが可能となる。そして、当該タスク実行処理は終了する。

次に、ステップＳ３１２において、上記差分の有無のチェックの結果、システム構成に差分があるか否かが判定される。その結果、差分がないときは（ステップＳ３１２でＮＯ）、システムの更新はない（同じバージョンである）と考えられるため、ステップＳ３２３に処理が進められ、アプリのインストール処理が行われる。この処理は、上記図２６，図２９および図３０を用いて説明したアプリのインストール処理と同様である。すなわち、アプリをダウンロードするタスクが適宜生成され、かつ、即時実行されることで、アプリが適宜インストールされる。そして、システムインストール処理は終了する。ここでは、システムの更新がない場合はすぐにアプリケーションのインストール処理を行うことになる。

一方、ボトルメールサーバでは、上述したような処理を実行するためのプログラムの他、上述した履歴情報データ（図５３の「Ｌｏｇ」）が記憶されることになる。図５４は、当該履歴情報データのデータ構造の一例を示す図である。図５４に示すように、履歴情報データは、複数のボトルメール履歴データ１６１の集合で構成され、各ボトルメール履歴データ１６１は、アップロード数１６２と複数の転送情報１６３で構成される。アップロード数１６２は、ゲーム装置１から上記付加情報等がアップロードされた回数を示す。この値は、換言すれば、そのボトルメールが転送された回数を示す事にもなる。転送情報１６３は、ボトルメールの転送先となったゲーム装置１（図５３ではゲーム装置Ｂ〜Ｄ）に関する情報であり、世代情報１６４、送信者名１６５、ＡＰ情報１６６、メール内容１６７の集合で構成される。世代情報１６４および送信者名１６５は、ゲーム装置１から上記付加情報として送信されてきたデータである。ＡＰ情報１６６は、上記付加情報の送信の際に用いられたＡＰを示すための情報である。この情報と後述するＡＰ地域テーブルに基づき、付加情報が送信されたときにゲーム装置１が居た地域が特定可能となる。メール内容１６７は、付加情報と同時に送信されてきたボトルメールの内容（本文）である。転送先でボトルメールの内容が加工されることも想定し、その変更履歴を参照可能なように転送先それぞれにおけるボトルメールを送信したものである。また、その他、図示は省略するが、各ボトルメールを一意に識別するための情報等も含まれる。

上記のような処理を実現するために、第４の実施形態では、上記第１の実施形態のシステムインストール処理（及びアプリのインストール処理）の代わりに、例えば、図５９に示すような処理が実行される。図５９は、第４の実施形態にかかるインストール処理を示すフローチャートである。本フローチャートは、第１の実施形態における、図４７のステップＳ５４８のシステムインストール処理の代わりとして実行される。すなわち、インストールリストの取得が行われた際に実行される。まず、ステップＳ７１１において、上記インストールリスト５８０に載っている全てのアプリについて、以下に示すようなダウンロードのタスクを生成する処理が行われたか否かが判定される。その結果、まだ未処理のアプリが残っているときは（ステップＳ７１１でＮＯ）、ステップＳ７１２において、インストールリスト５８０に載っているアプリの中で未処理のものから一つが選択される。

図６２は、このようなコンテンツアプリを実行したときに、ゲーム装置１の表示部に表示される画面例である。上側ＬＣＤ２２には、コンテンツの一例であるゲームソフトＡの映像が表示される。下側ＬＣＤ１２には、再生ビューアアプリの一例である操作画面が表示される。下側ＬＣＤ１２に表示される操作画面は、再生タイムラインバー２０１、再生コントロールボタン２０２、「詳細情報を見る」ボタン２０３、、ゴミ箱（削除）ボタン２０４、および「おわる」ボタン２０５を含む。再生タイムラインバー２０１は、上側ＬＣＤ２２で再生されている映像の開始からの経過時間または映像全体のうちのどの位置を再生中かを示すインジケータであり、ここを直接タッチすることにより、任意の位置から映像を再生することができる。再生コントロールボタン２０２は、映像の再生（または一時停止）、早送り、巻き戻しを指示するためのボタンである。「詳細情報を見る」ボタン２０３は、上側ＬＣＤ２２に表示されているコンテンツの詳細情報を見るためのボタンであり、ここをタッチすることにより、上述のステップＳ７４３へ進み、コンテンツの詳細情報を表示したり、コンテンツの購入およびダウンロードを行うことができる。ゴミ箱ボタン２０４は、コンテンツアプリ自体をゲーム装置１から削除するためのボタンであり、ここをタッチすることにより、コンテンツアプリの削除処理が行われる。「おわる」ボタン２０５は、コンテンツアプリの実行の終了を指示するためのボタンである。

Claims (48)

1. 自動的にサーバに接続する接続手段と、
   前記サーバから１以上のプログラムの受信処理を自動的に行う受信手段と、
   前記プログラムの情報処理装置へのインストール処理を自動的に行うインストール手段とを備える、情報処理装置。
2. 前記情報処理装置は、非使用状態と使用状態とを切り替える切替手段を更に備え、
   前記接続手段は、前記情報処理装置が少なくとも非使用状態で稼働しているときに、自動的に前記サーバに接続し、
   前記受信手段は、前記情報処理装置が少なくとも非使用状態において、前記受信処理を自動的に行い、
   前記インストール手段は、前記少なくとも非使用状態において、前記受信手段が受信したプログラムのインストール処理を自動的に行う、請求項１に記載の情報処理装置。
3. 前記非使用状態は、前記使用状態よりも消費電力が少ない、請求項２に記載の情報処理装置。
4. 前記情報処理装置は、ユーザにより開閉の操作が可能であり、
   前記切替手段は、前記情報処理装置が開状態であるときに前記使用状態に切り替え、閉状態であるときに前記非使用状態に切り替える、請求項２に記載の情報処理装置。
5. 前記情報処理装置は、表示装置を更に備え、
   前記切替手段は、ユーザによる所定の操作に応じて前記使用状態と前記非使用状態とを切り替え、
   前記使用状態においては、前記表示装置に電力が供給され、前記非使用状態においては、前記表示装置への電力は供給されない、請求項２に記載の情報処理装置。
6. 前記情報処理装置は、携帯型情報端末であり、自動的に繰り返し所定のアクセスポイントを探索する探索手段を更に備え、
   前記接続手段は、前記探索手段によって前記アクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して前記サーバと接続を行う、請求項１に記載の情報処理装置。
7. 前記情報処理装置は、
   前記プログラムの受信処理のそれぞれについて、当該受信が完了したか否かを示す受信状況を記憶する受信状況記憶手段を更に備え、
   前記受信手段は、前記受信状況に基づいて、受信が完了していないことが示されている前記受信処理を再開する、請求項６に記載の情報処理装置。
8. 前記情報処理装置は、１以上の前記プログラムの受信処理をそれぞれ規定する１以上のタスクを設定するタスク設定手段を更に備え、
   前記受信状況記憶手段は、当該タスクによって規定される受信処理が完了したか否かを示す受信状況をタスク毎に記憶し、
   前記受信手段は、受信が完了していないことを示す受信状況が記憶されている前記タスクによって規定される受信処理を再開する、請求項７に記載の情報処理装置。
9. 前記情報処理装置は、
   前記接続手段によって前記サーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報をサーバから受信する配信情報受信手段と、
   前記配信中プログラム情報を受信したとき、当該配信中プログラム情報によって特定される前記受信可能なプログラムの受信処理を行うか否かを所定の条件に基づいて決定する受信可否決定手段とを備え、
   前記受信手段は、前記受信可否決定手段によって受信処理を行うと決定された前記プログラムの受信処理を行う、請求項１に記載の情報処理装置。
10. 前記情報処理装置は、所定のプログラムの実行履歴を示す実行履歴データを記憶する実行履歴記憶手段を更に備え、
    前記配信中プログラム情報は、前記受信可能な受信条件付きプログラムを特定する情報及び当該受信可能なプログラムを受信するために必要となる前記所定のプログラムの実行履歴に関する条件が受信のための条件を含み、
    前記受信可否決定手段は、前記実行履歴データで示される実行履歴が前記受信のための条件を満たしているときに、前記受信条件付きプログラムの受信処理を行うと決定し、当該実行履歴が当該受信のための条件を満たしていないときは、前記受信条件付きプログラムの受信処理を行わないと決定する、請求項９に記載の情報処理装置。
11. 前記情報処理装置は、
    前記接続手段によって前記サーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報をサーバから受信する配信情報受信手段と、
    前記配信中プログラム情報によって特定される受信可能プログラムが既に自機にインストールされているか否かを判定するインストール状況判定手段とを更に備え、
    前記受信手段は、前記配信中プログラム情報によって特定される受信可能プログラムの受信処理を行い、
    前記インストール手段は、前記受信手段によって受信されたプログラムのうち、前記インストール状況判定手段によって既にインストール済みと判定されたプログラムについては当該プログラムのアップデート処理を行い、まだインストールされていないと判定されたプログラムについては新規インストール処理を行う、請求項１に記載の情報処理装置。
12. 前記情報処理装置は、
    前記接続手段によって前記サーバへの接続が行われたとき、受信可能なアプリケーションプログラムの一覧を示す配信中アプリ情報をサーバから受信する配信情報受信手段と、
    前記配信中アプリ情報を受信したとき、当該配信中アプリ情報によって特定される前記受信可能なアプリケーションプログラムの受信処理を行うか否かを所定の条件に基づいて決定する受信可否決定手段とを備え、
    前記受信手段は、前記受信可否決定手段によって受信処理を行うと決定された前記アプリケーションプログラムの受信処理を行う、請求項１に記載の情報処理装置。
13. 前記情報処理装置は、当該情報処理装置のユーザの年齢を使用者年齢情報として当該情報処理装置内に記憶する年齢情報記憶手段を更に備え、
    前記配信中プログラム情報は、前記受信可能な各プログラムについての対象年齢を表す情報を含み、
    前記受信可否決定手段は、前記使用者年齢情報と前記各プログラムの対象年齢とを比較し、比較結果が所定の条件を満たしたとき、当該プログラムの受信処理を行うと決定する、請求項９に記載の情報処理装置。
14. 前記情報処理装置は、前記接続手段によって前記サーバへの接続が行われたとき、受信可能なプログラムについての情報である配信中プログラム情報及び当該配信中プログラム情報で示される各プログラムを受信する順番を表した優先度情報を当該サーバから受信する配信情報受信手段を更に備え、
    前記受信手段は、前記配信中プログラム情報によって特定される前記プログラムを、前記優先度情報に基づいた順番にて受信する、請求項１に記載の情報処理装置。
15. 前記情報処理装置は、
    前記インストールされたプログラムの一覧を作成し出力する一覧作成手段と、
    前記情報処理装置への所定の操作に応じて、前記一覧からいずれかのプログラムを選択する選択手段と、
    前記選択されたプログラムのアンインストール処理を行うアンインストール手段とを更に備える、請求項１に記載の情報処理装置。
16. 前記情報処理装置は、前記アンインストール手段によってアンインストールされたプログラムを特定するための削除プログラム特定情報を記憶する削除履歴記憶手段を更に備え、
    前記受信手段は、前記配信中プログラム情報で示されるプログラムのうち、前記削除プログラム特定情報で特定されるプログラムについては、受信処理を行わない、請求項１５に記載の情報処理装置。
17. 前記情報処理装置は、ユーザの所定の操作に応じて、前記情報処理装置用のプログラムが登録された所定のサーバに接続し、ユーザが希望するプログラムを、前記削除プログラム特定情報に含まれているプログラムであるか否かにかかわらず受信する、請求項１６に記載の情報処理装置。
18. 前記情報処理装置は記憶部を更に備え、
    前記インストール手段は、前記受信手段によって受信したプログラムを前記記憶部に記憶し、当該プログラムを実行可能とするための実行環境設定処理を行うことでインストールを完了させる、請求項１に記載の情報処理装置。
19. 前記情報処理装置は、
    インストールされたプログラムを記憶する記憶部と、
    前記情報処理装置の起動時に、前記記憶部に記憶されているプログラムの一覧を作成し出力する一覧作成手段と、
    前記情報処理装置に対して行われた所定の操作に応じて、前記一覧からいずれかのプログラムを選択する選択手段と、
    前記選択されたプログラムを実行するプログラム実行手段とを備え、
    前記インストール手段は、前記受信したプログラムを自動的に前記記憶部に記憶する、請求項１に記載の情報処理装置。
20. 前記情報処理装置は、
    インストールされたプログラムを記憶する記憶部と、
    前記情報処理装置に対して行われた所定の操作に応じて、前記記憶部に記憶されているプログラムの一覧を作成し出力する一覧作成手段と、
    前記情報処理装置への所定の操作に応じて、前記一覧からいずれかのプログラムを選択する選択手段と、
    前記選択されたプログラムを実行するプログラム実行手段とを備え、
    前記インストール手段は、前記受信したプログラムを自動的に前記記憶部に記憶する、請求項１に記載の情報処理装置。
21. 前記インストール手段は、更に、前記受信したプログラムが前記一覧作成手段によって作成される一覧の掲載対象となるように自動的に設定を行うことでインストールを完了する、請求項１９又は２０に記載の情報処理装置。
22. 前記情報処理装置は権利情報データベース及び複数のプログラムを記憶する記憶部をさらに備え、
    前記受信手段は、前記プログラムとともに当該プログラムを実行するための権利情報を受信し、
    前記インストール手段は、前記受信したプログラムを自動的に前記記憶部に記憶するとともに、前記受信した権利情報を自動的に前記権利情報データベースに登録し、
    前記情報処理装置は、
    前記記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、
    前記実行指示を受け付けたとき、前記権利情報データベースに登録されている前記権利情報を用いて当該権利情報の認証を行う認証手段と、
    前記認証が成功したとき、前記実行指示がなされたプログラムを実行するプログラム実行手段とを更に備える、請求項１に記載の情報処理装置。
23. 前記情報処理装置は権利情報データベース及び複数のプログラムを記憶する記憶部をさらに備え、
    前記受信手段は、前記プログラムとともに当該プログラムを実行するための権利情報を受信し、
    前記インストール手段は、
    前記受信手段によって前記プログラム及び前記権利情報を受信したとき、前記権利情報の正当性の有無を自動的に判別する正当性確認手段と、
    前記権利情報の正当性があると判別されたとき、前記プログラム及び前記権利情報を前記記憶部に自動的に記憶する権利情報記憶手段と、
    前記権利情報の正当性がないと判別されたとき、前記権利情報の内容を破棄する権利情報破棄手段とを含み、
    前記情報処理装置は、
    前記記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、
    前記実行指示を受け付けたとき、前記権利情報を記憶部から読み出し、当該権利情報の認証を行う認証手段と、
    前記認証が成功したとき、前記実行指示がなされたプログラムを実行するプログラム実行手段とを更に備える、請求項１に記載の情報処理装置。
24. 前記情報処理装置は複数のプログラムを記憶する記憶部をさらに備え、
    前記受信手段は、前記プログラムを受信し、
    前記インストール手段は、
    前記受信手段によって前記プログラムを受信したとき、当該受信したプログラムの正当性の有無を自動的に判別する正当性確認手段と、
    前記受信したプログラムの正当性があると判別されたとき、当該プログラムを前記記憶部に自動的に記憶する権利情報記憶手段と、
    前記受信したプログラムの正当性がないと判別されたとき、当該受信したプログラムを破棄する破棄手段とを含み、
    前記情報処理装置は、
    前記記憶部に記憶されたプログラムのうち少なくとも１つの実行指示を受け付ける実行指示受付手段と、
    前記実行指示を受け付けたとき、当該実行指示がなされたプログラムを実行するプログラム実行手段とを更に備える、請求項１に記載の情報処理装置。
25. 前記接続手段は、ユーザに接続に関する操作を一切求めずに前記サーバへの接続を自動的に行い、
    前記受信手段は、前記１以上のプログラムの受信処理に際して、ユーザに対して当該受信処理に関する操作を一切求めずに前記受信処理を自動的に行い、
    前記インストール手段は、前記プログラムの情報処理装置へのインストールに際して、ユーザに対して当該インストール処理に関する操作を一切求めずに前記インストール処理を自動的に行う、請求項１に記載の情報処理装置。
26. 前記情報処理装置は、
    前記接続手段によって前記サーバへの接続が行われたとき、受信可能なアプリケーションプログラムの一覧を示す配信中アプリ情報をサーバから受信する配信情報受信手段と、
    前記配信中アプリ情報によって特定される受信可能なアプリケーションプログラムが、既に自機にインストールされているか否かを判定するアプリインストール状況判定手段を更に備え、
    前記受信手段は、前記配信中アプリ情報によって特定される受信可能なアプリケーションプログラムの受信処理を行い、
    前記インストール手段は、前記受信手段によって受信されたアプリケーションプログラムのうち、前記アプリインストール状況判定手段によって既にインストール済みと判定されたアプリケーションプログラムについては当該アプリケーションプログラムの更新インストールを行い、まだインストールされていないと判定されたアプリケーションプログラムについては新規インストールを行う、請求項１に記載の情報処理装置。
27. 前記サーバから受信されるプログラムには、システムプログラムとアプリケーションプログラムの２種類のプログラムが存在し、
    前記受信手段は、前記アプリケーションプログラムを自動的に受信し、
    前記インストール手段は、前記アプリケーションプログラムの情報処理装置へのインストール処理を自動的に行う、請求項１に記載の情報処理装置。
28. 非使用状態と使用状態とを切り替える切替手段と、
    前記情報処理装置が少なくとも非使用状態で稼働しているときに、自動的に前記サーバに接続する接続手段と、
    前記情報処理装置が少なくとも非使用状態で稼働しているときにおいて、前記サーバから１以上のアプリケーションプログラムの受信処理を自動的に行う受信手段と、
    前記情報処理装置が少なくとも非使用状態で稼働しているときにおいて、前記アプリケーションプログラムの当該情報処理装置へのインストール処理を自動的に行うアプリインストール手段とを備える、情報処理装置。
29. 自動的にサーバに接続する接続手段と、
    前記サーバから１以上のアプリケーションプログラムの受信処理を自動的に行う受信手段と、
    前記アプリケーションプログラムの前記情報処理装置へのインストール処理を自動的に行うアプリインストール手段とを備える、情報処理装置。
30. 情報処理装置とサーバを含むシステムであって、
    前記情報処理装置は、
    自動的に前記サーバに接続する接続手段と、
    前記サーバから１以上のプログラムの受信処理を自動的に行う受信手段と、
    前記プログラムの情報処理装置へのインストール処理を自動的に行うインストール手段と、
    ユーザにより選択されたプログラムを実行するプログラム実行手段とを備え、
    前記サーバは、前記情報処理装置による接続が行われたとき、前記１以上のプログラムの送信処理を行う送信手段を備える、システム。
31. 前記サーバによって送信され、前記情報処理装置によって受信、インストール、及び実行がなされるプログラムは、
    コンテンツデータ、および、前記情報処理装置を、前記コンテンツデータを再生する再生手段として機能させる再生処理プログラムを含む、請求項３０に記載のシステム。
32. 前記サーバによって送信され、前記情報処理装置によって受信、インストール、及び実行がなされるプログラムは、前記情報処理装置を、
    ユーザによる当該プログラムのアンインストール指示を受け付けるアンインストール受付手段として機能させ、
    前記情報処理装置は、前記アンインストール受付手段によって前記プログラムのアンインストール指示が受け付けられたとき、前記プログラムをアンインストールするアンインストール手段を更に備える、請求項３０に記載のシステム。
33. 前記サーバによって送信され、前記情報処理装置によって受信、インストール、及び実行がなされるプログラムは、ユーザにより手動で受信されるアプリケーションプログラムの紹介を行うプログラムであり、前記情報処理装置を、
    前記ユーザにより手動で受信するためのアプリケーションプログラムの詳細情報にアクセスするための指示を受け付ける詳細情報指示受付手段として機能させ、
    前記情報処理装置は、前記詳細情報指示受付手段によって前記詳細情報にアクセスするための指示が受け付けられたとき、前記手動で受信されるアプリケーションプログラムに関する詳細情報を出力する詳細情報出力手段を更に備える、請求項３０に記載のシステム。
34. 前記詳細情報出力手段は、前記詳細情報をサーバから取得して出力する、請求項３３に記載の情報処理装置。
35. 前記情報処理装置は、
    前記詳細情報が出力されているとき、ユーザから、前記手動で受信されるアプリケーションプログラムの受信及びインストールを行うための指示を受け付ける受信指示受付手段と、
    前記受信及びインストールを行うための指示を受け付けたとき、前記手動で受信されるアプリケーションプログラムが登録された所定のサーバに接続し、当該アプリケーションプログラムを受信するとともに、当該受信したアプリケーションプログラムを自動的にインストールする手動受信手段をさらに備える、請求項３３に記載のシステム。
36. 前記サーバによって送信され、前記情報処理装置によって受信、インストール、及び実行がなされるプログラムは、ユーザにより購入されるアプリケーションプログラム又はコンテンツの紹介を行うプログラムであり、前記情報処理装置を、
    前記プログラム実行手段によって実行される前記プログラム内において、前記ユーザにより購入されるアプリケーションプログラムの購入サイトへアクセスするための指示を受け付けるアクセス指示受付手段として機能させ、
    前記情報処理装置は、前記アクセス指示受付手段によって購入サイトへアクセスするための指示が受け付けられたとき、前記ユーザにより購入されるアプリケーションプログラムの購入サイトに接続する購入サイト接続手段をさらに備える、請求項３０に記載のシステム。
37. 自動的にサーバに接続する接続手段と、
    前記サーバから１以上のプログラムの受信処理を自動的に行う受信手段と、
    前記受信手段によって受信されたプログラムが自機にインストールされていないときは、当該プログラムの新規インストール処理を自動的に行うインストール手段とを備える、情報処理装置。
38. サーバと情報処理装置を含むシステムを用いて、当該情報処理装置の機能を更新する情報処理方法であって、
    前記情報処理装置は、そのプロセッサにより、
    少なくとも省電力状態において、
    予め定めるスケジュールに従って、自動的かつ繰り返して前記サーバへの接続を試み、
    前記サーバに接続したときに、自機にインストールされていない情報処理装置用のプログラムをユーザの承諾および操作を求めずに自動的にダウンロードするとともに、当該ダウンロードしたプログラムを自動的にインストールし、
    非省電力状態において、
    ユーザに前記情報処理装置に記憶された複数のプログラムのうち、実行するプログラムをユーザに選択させるための選択画面において、前記少なくとも省電力状態において前記インストール済みのプログラムを自動的に含めて表示し、当該インストール済みのプログラムの選択操作に応じて、当該インストール済みのプログラムを起動し、
    前記自動的にインストールされたプログラムのうちユーザが希望するプログラムをアンインストールすることが可能な、機能更新方法。
39. 前記サーバは、前記情報処理装置のメーカーが管理するサーバであり、
    前記情報処理装置用のプログラムは、前記情報処理装置のメーカーの管理のもと、当該情報処理装置の発売後に当該情報処理装置用のプログラムを追加可能なように前記サーバに登録される、請求項３８に記載の機能更新方法。
40. 前記情報処理装置は、そのプロセッサにより、更に、ユーザの所定の操作に応じて、前記情報処理装置用のプログラムが登録された所定のサーバに接続し、ユーザが希望するプログラムをダウンロードするとともに、当該ダウンロードしたプログラムを自動的にインストールする、請求項３８に記載の機能更新方法。
41. 情報処理装置のコンピュータに実行させる情報処理プログラムであって、
    前記コンピュータを、
    自動的にサーバに接続する接続手段と、
    前記サーバから１以上のプログラムの受信処理を自動的に行う受信手段と、
    前記プログラムの前記情報処理装置へのインストール処理を自動的に行うインストール手段として機能させる、情報処理プログラム。
42. 前記受信手段によりサーバから自動的に受信され、前記インストール手段により自動的にインストールされる前記プログラムは、
    コンテンツデータを含み、
    前記コンピュータを、前記コンテンツデータを再生する再生手段として機能させる、請求項４１に記載の情報処理プログラム。
43. 前記受信手段によりサーバから自動的に受信され、前記インストール手段により自動的にインストールされるプログラムは、
    前記コンピュータを、ユーザによる当該プログラムのアンインストール指示を受け付けるアンインストール受付手段としてさらに機能させ、
    前記情報処理プログラムは、前記コンピュータを、前記アンインストール受付手段によって前記プログラムのアンインストール指示が受け付けられたとき、当該プログラムをアンインストールするアンインストール手段として更に機能させる、請求項４１に記載の情報処理プログラム。
44. 前記受信手段によりサーバから自動的に受信され、前記インストール手段により自動的にインストールされるプログラムは、
    前記コンピュータを、前記ユーザにより手動で受信されるアプリケーションプログラムの詳細情報にアクセスするための指示を受け付ける詳細情報指示受付手段としてさらに機能させ、
    前記情報処理プログラムは、前記コンピュータを、前記指示が受け付けられたとき、前記手動で受信されるアプリケーションプログラムに関する詳細情報を出力する詳細情報出力手段として更に機能させる、請求項４１に記載の情報処理プログラム。
45. 前記情報処理プログラムは、前記コンピュータを、
    前記詳細情報が出力されているとき、ユーザから、前記手動で受信されるアプリケーションプログラムの受信及びインストールを行うための指示を受け付ける受信指示受付手段と、
    前記受信及びインストールを行うための指示を受け付けたとき、前記手動で受信されるアプリケーションプログラムが登録された所定のサーバに接続し、当該アプリケーションプログラムを受信するとともに、当該受信したアプリケーションプログラムを自動的にインストールする手動受信手段として更に機能させる、請求項４４に記載の情報処理プログラム。
46. 前記受信手段によりサーバから自動的に受信され、前記インストール手段により自動的にインストールされるプログラムは、
    前記コンピュータを、前記プログラム実行手段によって実行される前記プログラム内において、前記ユーザにより購入されるアプリケーションプログラムの購入サイトへアクセスするための指示を受け付けるアクセス指示受付手段としてさらに機能させ、
    前記情報処理プログラムは、前記コンピュータを、前記指示が受け付けられたとき、前記ユーザにより購入されるアプリケーションプログラムの購入サイトに接続する購入サイト接続手段として機能させる、請求項４１に記載の情報処理プログラム。
47. 自動的にサーバに接続する接続手段と、
    前記サーバから１以上のプログラムの受信処理を自動的に行う受信手段と、
    前記プログラムの情報処理装置へのインストール処理を自動的に行うインストール手段とを備える、情報処理システム。
48. 自動的にサーバに接続する接続ステップと、
    前記サーバから１以上のプログラムの受信処理を自動的に行う受信ステップと、
    前記プログラムの情報処理装置へのインストール処理を自動的に行うインストールステップとを備える、情報処理方法。

Images