JP5677811B2 - 携帯型情報端末、携帯情報システム、携帯型情報端末制御プログラム - Google Patents

Description

本発明は、通信機能を備えた携帯型情報端末に関し、より特定的には、省電力モードを有する携帯型情報端末に関する。

従来、ある条件を満たしたタイミングで、スケジューリングされた通信タスクを実行する技術が存在している（例えば、特許文献１）。このような技術を用いた装置では、スケジューリングされたメッセージ送受信やダウンロードのタスクが、所定の単位時間ごとやタスクに設定されたタイミングで実行される。通信タスクは、ＣＰＵと独立して入出力プロセッサによって行われるため、ＣＰＵに電源が供給されないスタンバイモード時であっても実行されるため、ユーザが送受信やダウンロードの指示を行う必要がなくなる。

特開２００８−１２５６５９号公報

しかしながら、上記特許文献１の装置は、予めネットワークへの接続が確立されていることを前提として、メッセージの送受信やダウンロードといった処理の実行を間欠的に行うものであった。そのため、送受信やダウンロードの処理を実行すべきときにネットワークへの接続がなされていない場合、ネットワークへの接続を試みることができなかった。家庭など予め決められた場所に設置して使用する据置型の装置であれば、ネットワークに常時接続されていることを前提とした上記特許文献１の発明は有用ではある。しかし、持ち歩いて使用する携帯型の装置では、ユーザの移動によりアクセスポイントとの距離が変化し、また、付近にアクセスポイントが存在しなくなる状況も発生するため、上記特許文献１の発明を用いることは困難である。さらに、ユーザの指示したアクセスポイントに接続する方法は既に周知であるが、この方法においては、接続可能なアクセスポイントが付近に存在していたとしても、当該アクセスポイントに接続するためには、付近にアクセスポイントがあることにユーザが気付き、更に、接続の指示を行う必要がある。そのため、当該接続に際してのユーザの手間がかかり、かつユーザは付近にアクセスポイントがあるかどうかを常に意識しなければならない。

それ故に、本発明の目的は、アクセスポイントとの距離が一定ではない環境であるために常時接続が実現できない状態においても、必要なときに自動的にアクセスポイントに接続を試みることで、常時接続に類似した接続状態を実現できる携帯端末を提供することである。
また、本発明の他の目的は、接続を行うことについてユーザの意識や指示がなくとも、必要なときに自動的にアクセスポイントに接続を試み、ネットワーク上に存在させることのできる携帯端末を提供することである。

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

第１の発明は、第１切替手段と、探索手段と、通信処理手段とを備えた、携帯型情報端末である。第１切替手段は、非使用状態と、使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。

第１の発明によれば、非使用状態のときであっても、アクセスポイントを探索し、通信も行われる。これにより、ユーザが気づかないうちにネットワークに接続することができる。

第２の発明は、第１の発明において、非使用状態は、使用状態よりも消費電力が少ない。

第２の発明によれば、消費電力が小さい状態にあっても、アクセスポイントを探索してデータ通信を行うことができる。

第３の発明は、第１の発明において、携帯型情報端末は、ユーザにより開閉の操作が可能である。そして、第１切替手段は、携帯型情報端末が開状態であるときに使用状態に切り替え、閉状態であるときに非使用状態に切り替える。

第３の発明によれば、携帯型情報端末が閉じている（つまり、ユーザが気づかない）間にもデータ通信を行うことができる。

第４の発明は、第１の発明において、探索手段は、自動的に繰り返し前記アクセスポイントを探索する。そして、通信処理手段は、自動的にアクセスポイントに接続し、自動的にデータ通信処理を行う。

第４の発明によれば、自動的にネットワークに接続されるので、ユーザが気づかないうちにデータ通信を行うことができる。さらに繰り返して行われるので、常時接続的な利用感を与えることができる。

第５の発明は、第１の発明において、携帯型情報端末は、プログラム実行手段と、受付手段とを更に備える。
プログラム実行手段は、複数のアプリケーションプログラムを実行する。受付手段は、各アプリケーションプログラムから、ネットワークを介して他の情報処理装置との間で行われるデータの送信または受信の処理内容の指示を受け付ける。そして、探索手段は、所定のアクセスポイントを自動的に探索する。更に、通信処理手段は、受付手段によって複数のアプリケーションプログラムのうちそれぞれより受け付けられたデータの送信または受信を、アクセスポイントを介して、自動的に行う。

第５の発明によれば、各アプリケーションはアクセスポイントへの接続やデータ送受信の処理を自ら行う必要はなく、指示を出しておけば、自動的にデータ送受信が行われるので、各アプリケーションの開発者はアプリケーションの設計が容易となり、ユーザとしても、データ通信を行うときに対象のアプリケーションを起動しておく必要もなくなる。

第６の発明は、第１の発明において、携帯型情報端末は、記憶手段と、アクセスポイント情報設定手段と、探索時刻規定手段とを更に備える。記憶手段は、ユーザにより設定可能な、少なくとも１つの第１アクセスポイントに関する情報、および、ユーザにより設定不可能な、少なくとも１つの第２アクセスポイントに関する情報を記憶する。アクセスポイント情報設定手段は、ユーザにより少なくとも１つの第１アクセスポイントに関する情報を設定する。探索時刻規定手段は、少なくとも１つの第１アクセスポイントを探索する時刻を規定する。また、探索手段は、第１アクセスポイント探索手段と、第２アクセスポイント探索手段とを含む。第１アクセスポイント探索手段は、探索時刻規定手段によって規定された時刻が到来したときに、少なくとも１つの第１アクセスポイントに関する情報に基づいて、当該少なくとも１つの第１アクセスポイントを探索する。第２アクセスポイント探索手段は、少なくとも１つの第２アクセスポイントに関する情報に基づいて、当該少なくとも１つの第２アクセスポイントを自動的に繰り返し探索する。

第６の発明によれば、ユーザが設定するＡＰは規定時刻に探索が行われ、予め設定されているＡＰは自動的に繰り返し探索される。前者は家庭などにあるので、規定された時間に行えば足るが、後者は端末の移動などにより検出できるときや検出できないときがあるので、繰り返し探索を行うことで検出する効率を上げることができる。

第７の発明は、第１の発明において、通信処理手段は、所定のアクセスポイントに接続し、当該アクセスポイントを介して所定のデータを受信する。

第７の発明によれば、ユーザが気づかないうちにネットワークに接続し、所定のデータを受信することができる。また、データ受信が開始されるまでは省電力モードであるため、消費電力を節約することができる。

第８の発明は、第１の発明において、携帯型情報端末は、探索手段によって検出されたアクセスポイントを介した所定のデータ通信処理を通信処理手段が終了した後、当該アクセスポイントとの接続を切断する通信切断手段を更に備える。

第８の発明によれば、消費電力を更に節約することができる。

第９の発明は、第１の発明において、探索手段は、近距離無線通信によって所定のアクセスポイントを探索する。

第９の発明によれば、搭載されている無線通信の通信可能距離が限られている場合には通常携帯型情報端末を移動させたときに接続が維持できる確率は低いが、そのような場合でも、常時接続的な利用感をユーザに提供することができる。

第１０の発明は、第１の発明において、携帯型情報端末は、少なくとも携帯型情報端末が非使用状態で稼働しているときにおいて所定の条件が満たされたか否かを判別する条件判別手段を更に備える。そして、探索手段は、条件判別手段によって所定の条件が満たされたと判別されたときに、所定のアクセスポイントを探索する。

第１１の発明は、第１０の発明において、条件判別手段は、所定の時刻が到来したときに、条件が満たされたと判別する。

第１０乃至第１１の発明によれば、ユーザの指示によらずにアクセスポイントへ接続を試みるので、ユーザが気づかないうちにネットワークに接続することができる。

第１２の発明は、第１０の発明において、携帯型情報端末は、ネットワークを介して他の情報処理装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する処理規定手段を更に備える。また、通信処理手段は、処理規定手段によって規定されたデータの送信または受信を探索手段で検出されたアクセスポイントを介して行うデータ送受信処理手段を含む。そして、条件判別手段は、処理規定手段によって規定された実行時刻が到来したときに条件を満たしたと判別する。更に、データ送受信処理手段は、条件判別手段によって所定の条件が満たされたと判別され、探索手段によって所定のアクセスポイントを検出したときに、所定のデータの送信または受信を行う。

第１２の発明によれば、処理を行うべき時刻、すなわち必要なときに、アクセスポイントに接続を試みる。そのため、必要なときにアクセスポイントが携帯型情報端末の付近に存在していれば、常時接続しているのと同様の効果を奏することができる。

第１３の発明は、第１の発明において、探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントから発信されるビーコンの受信を自動的に繰り返し試みることで所定のアクセスポイントを探索し、当該ビーコンを受信することにより当該アクセスポイントの検出を行う。また、通信処理手段は、接続確立手段と、データ送受信手段とを含む。接続確立手段は、探索手段によってビーコンを受信したと判別されたとき、当該ビーコンを送信したアクセスポイントへの接続の確立を試みる。データ送受信手段は、アクセスポイントへの接続が確立されたとき、当該アクセスポイントを介して所定のデータの送信または受信を行う。

第１３の発明によれば、ユーザが指示をしなくても自動的に繰り返しアクセスポイントのビーコンの受信を試み、ビーコンを受信すればアクセスポイントとの接続を試みるため、ユーザが気づかないうちにネットワークに接続することができる。

第１４の発明は、第１３の発明において、携帯型情報端末は、処理規定手段を更に備える。処理規定手段は、ネットワークを介して他の装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する。更に、通信処理手段は、実行時刻判別手段を更に含む。実行時刻判別手段は、接続確立手段によってアクセスポイントへの接続が確立されたとき、規定された実行時刻が到来しているか否かを判別する。そして、データ送受信手段は、実行時刻が到来しているとき、アクセスポイントを介して、規定されたデータの送信または受信を行う。

第１４の発明によれば、ビーコンを受信してアクセスポイントに接続したときに、既に実行予定時刻が到来している（にも関わらず実行されていない）処理を実行するため、常時接続に近い効果を奏することができる。

第１５の発明は、第１の発明において、携帯型情報端末は、表示手段を更に備える。また、使用状態においては、表示手段に電力が供給されるが、非使用状態においては、表示手段への電力は供給されない。そして、第１切替手段は、ユーザによる所定の操作に応じて使用状態と非使用状態を切り替える。更に、携帯型情報端末は、ユーザの操作に応じて非使用状態から使用状態に切り替えられたとき、通信処理手段によって受信したデータの内容を表示手段に表示する表示制御手段を更に備える。

第１５の発明によれば、ユーザが操作を行ったときに表示手段に電力が供給されるモードに切り替えられ、受信したデータが表示され、ユーザは新たなデータを受信したことを知ることができるため、ユーザに驚きを与えることができる。

第１６の発明は、第８の発明において、携帯型情報端末は、省電力モードと非省電力モードとの間で電源制御モードを切り替える第２切替手段を更に備える。そして、探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。また、第２切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替え、通信切断手段によって当該アクセスポイントとの接続が切断されたとき、当該電源制御モードを省電力モードに切り替える。

第１７の発明は、第１の発明において、携帯型情報端末は、省電力モードと非省電力モードとの間で電源制御モードを切り替える第２切替手段を更に備える。そして、探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。第２切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替え、通信処理手段によるデータ通信処理が終了したとき、当該電源制御モードを省電力モードに切り替える。

第１６乃至第１７の発明によれば、ＡＰが検出されると非省電力になりデータ通信が行われ、終了後に切断し省電力になるので、データ通信時に電力を必要とする場合でも（すなわち、非省電力では通信ができない場合・仕様でも）消費電力を節約することができる。

第１８の発明は、第１の発明において、通信処理手段は、アクセスポイントを介して、１以上のアプリケーションプログラムの受信を自動的に行う。そして、携帯型情報端末は、１以上のアプリケーションプログラムの受信が行われたとき、当該アプリケーションプログラムの携帯型情報端末へのインストールを自動的に行うインストール手段を更に備える。

第１８の発明によれば、自動的にアプリケーションプログラムのダウンロード（受信）およびインストールを行うので、ユーザは気付かないうちに新たなアプリケーションを受信することができるため、ユーザに驚きを与えるとともに、アプリケーション提供者にとってはアプリケーションを使用してもらう機会を増やすことができる。

第１９の発明は、第１の発明において、通信処理手段は、アクセスポイントを介して、１以上のアプリケーションプログラムの受信を自動的に行う。また、携帯型情報端末は、一覧作成手段と、選択手段と、アプリケーションプログラム実行手段と、一覧作成対象追加手段とを更に備える。一覧作成手段は、当該携帯型情報端末の起動時に、アプリケーションプログラムの一覧を作成し出力する。選択手段は、携帯型情報端末への所定の操作に応じて、一覧からいずれかのアプリケーションプログラムを選択する。アプリケーションプログラム実行手段は、選択されたアプリケーションプログラムを実行する。一覧作成対象追加手段は、通信処理手段によって自動的に受信されたアプリケーションプログラムを、一覧作成手段により作成される一覧の掲載対象へと自動的に追加する。

第１９の発明によれば、自動的に受信されたアプリケーションは、自動的に一覧（メニュー）の掲載対象となるため、ユーザは新たに受信されたアプリケーションに気づくことができる。

第２０の発明は、第１の発明において、通信処理手段は、前記アクセスポイントを介して、１以上のアプリケーションプログラムの受信を自動的に行う。携帯型情報端末は、一覧作成手段と、選択手段と、アプリケーションプログラム実行手段と、一覧作成対象追加手段とを更に備える。一覧作成手段は、当該携帯型情報端末への所定の操作に応じて、アプリケーションプログラムの一覧を作成し出力する。選択手段は、携帯型情報端末への所定の操作に応じて、一覧からいずれかのアプリケーションプログラムを選択する。アプリケーションプログラム実行手段は、選択されたアプリケーションプログラムを実行する。一覧作成対象追加手段は、通信処理手段によって自動的に受信されたアプリケーションプログラムを、一覧作成手段により作成される一覧の掲載対象へと自動的に追加する。

第２０の発明によれば、自動的に受信されたアプリケーションは、自動的に一覧（メニュー）の掲載対象となるため、ユーザは新たに受信されたアプリケーションに気づくことができる。

第２１の発明は、第１の発明において、携帯型情報端末は、近距離無線を用いて自端末の通信可能範囲に存在する通信相手となる他端末を繰り返し探索して自動的に無線接続し、当該無線接続がされた当該他端末との間で自動的にデータを送信または受信する近距離データ通信手段を更に備える。そして、通信処理手段は、近距離データ通信手段により受信したデータの内容をアクセスポイントを介して更に他の情報処理装置へ送信する。

第２１の発明によれば、近距離で他の端末と通信は可能であるがＡＰには接続することができない端末があった場合に、その端末の代わりにＡＰを介しての送信を行うことができる。

第２２の発明は、第１の発明において、携帯型情報端末は、近距離無線を用いて自端末の通信可能範囲に存在する通信相手となる他端末を繰り返し探索して自動的に無線接続し、当該無線接続がされた当該他端末との間で自動的にデータを送信または受信する近距離データ通信手段を更に備える。そして、近距離データ通信手段は、通信処理手段によって受信したデータの内容を他端末へ送信する。

第２２の発明によれば、近距離で他の端末と通信は可能であるがＡＰには接続することができない端末があった場合に、その端末の代わりにＡＰを介してデータを受信することができる。

第２３の発明は、第１の発明において、携帯型情報端末は、計時手段、近距離無線通信を行うための無線通信モジュール、演算処理手段、および、第２切替手段と、時刻判別手段を更に備える。第２切替手段は、計時手段、演算処理手段、および無線モジュールに電力が供給される非省電力モードと、計時手段および無線モジュールには電力が供給されるが演算処理手段には電力は供給されない省電力モードとの間で電源制御モードを切り替える。時刻判別手段は、少なくとも非使用状態かつ省電力モードで当該携帯型情報端末が稼働しているときにおいて所定の時刻が到来したか否かを、計時手段を用いて判別する。更に、第２切替手段は、時刻判別手段によって所定の時刻が到来したときに、電源制御モードを非省電力モードに切り替える。そして、探索手段は、少なくとも非使用状態かつ非省電力モードで前記携帯型情報端末が稼働しているときに、無線モジュールおよび演算処理手段を用いて所定のアクセスポイントを探索する。

第２４の発明は、第１の発明において、携帯型情報端末は、近距離無線通信を行うための無線通信モジュール、演算処理手段、および、第２切替手段を更に備える。第２切替手段は、演算処理手段および無線モジュールに電力が供給される非省電力モードと、無線モジュールには電力が供給されるが演算処理手段には電力は供給されない省電力モードとの間で電源制御モードを切り替える。探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、無線通信モジュールによって所定のアクセスポイントを探索する。第２切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替える。そして、通信処理手段は、第２切替手段によって非省電力モードに切り替えられたとき、無線モジュールおよび演算処理手段を用いてアクセスポイントに接続し、データ通信処理を実行する。

第２３乃至第２４の発明によれば、第１の発明と同様の効果を得ることができる。

第２５の発明は、処理規定手段と、時刻判別手段と、接続手段と、データ送受信手段を備える、携帯型情報端末である。処理規定手段は、ネットワークを介して他の装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する。時刻判別手段は、処理規定手段によって規定された実行時刻が到来したか否かを判別する。接続手段は、時刻判別手段によって前記実行時刻が到来したと判別されたとき、所定のアクセスポイントへの接続を試みる。データ送受信手段は、接続手段によってアクセスポイントへの接続が確立されたとき、処理規定手段によって規定されたデータの送信または受信を、当該アクセスポイントを介して行う。

第２５の発明によれば、処理を行うべき時刻、すなわち必要なときに、アクセスポイントに接続を試みるので、必要なときにアクセスポイントが付近に存在していれば、常時接続しているのと同様の効果を奏することができる。

第２６の発明は、第１切替手段と、探索手段と、通信処理手段とを備えた、携帯型情報システムである。第１切替手段は、非使用状態と、使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。

第２７の発明は、非使用状態と使用状態の２つのモードを有する携帯型情報端末のコンピュータで実行される携帯型情報端末制御プログラムである。当該プログラムは、コンピュータを、第１切替手段と、探索手段と、通信処理手段として機能させる。第１切替手段は、非使用状態と使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに所定のアクセスポイントを探索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。

第２８の発明は、第１切替ステップと、探索ステップと、通信処理ステップとを備えた、携帯型情報端末制御方法である。第１切替ステップでは、非使用状態と使用状態とが切り替えられる。探索ステップでは、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントが探索される。通信処理ステップでは、探索ステップによって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続され、当該アクセスポイントを介して所定のデータ通信処理が行われる。

第２６乃至第２８の発明によれば、第１の発明と同様の効果を得ることができる。

本発明によれば、常時接続型ではない携帯型情報端末であっても、常時接続的な利用感をユーザに提供することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、その他のタスクとして、本実施形態では「インストールリストの取得」というタスクがある。当該タスクは、ゲーム装置１の出荷時設定として予め設定済みのタスクである。インストールリストには、例えば、システムデータや各アプリケーションやゲームプログラム（以下では、アプリケーション、ゲームを総称して単にアプリケーション、あるいは単にアプリと呼ぶ）のアップデートに関する情報、無料アプリケーション、新作アプリケーションの体験版の存在を示す情報等が含まれる。なお、このようなアップデートや無料アプリ、体験版に関しては、本実施形態では、その存在の有無の確認のみならず、実際の更新データや体験版プログラムのダウンロードおよびインストール処理も実行される（このようなインストール処理の詳細は後述する）。

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

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

次に、上述した「インターネット通信」で実行されるタスクの３種類の実行タイミングおよびその処理概要について説明するが、この説明に先立って、上記タスクに関して設定される「実行優先度」というパラメータ、および、「消尽回数」というパラメータについて説明する。実行優先度は、そのタスクが実行される優先度を示すものであり、同タイミングに実行されるべき複数のタスクが存在する場合に、これらの実行順序を決定するために用いられる。本実施形態においては、実行優先度は５段階に分けて定義されている。具体的には、優先度の高いものから、”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）処理」が呼び出されて実行されることが示されている。更に、当該「ローカル通信用ＢＧ処理」においては、「インターネット通信用ＢＧ処理」が呼び出されて実行されることを示す。また、当該「ローカル通信用ＢＧ処理」は、無線通信モジュール３４が実行する「無線モジュール処理」においても呼び出されることがあり、ＣＰＵ３１が実行する起動時処理においても呼び出されることがあることが示されている。

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

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

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

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

図１４は、ＮＡＮＤフラッシュメモリ３３に記憶されるプログラム、データを示す図である。なお、これらのデータは、必要に応じてメインメモリ３２に展開されて実行される。ＮＡＮＤフラッシュメモリ３３は、プログラム領域５００とデータ領域５１０を有しており、プログラム領域５００には、メニュー処理プログラム５０１、タスク生成処理プログラム５０２、ローカル通信ＢＧ処理プログラム５０３、インターネット通信ＢＧ処理プログラム５０４、ポリシー処理プログラム５０５、タスク実行処理プログラム５０６、実行順ソート処理プログラム５０７、インストール処理プログラム５０８、および、複数のアプリケーションプログラム５０９等が記憶される。

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

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

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

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

次に、データ領域５１０について説明する。データ領域５１０には、すれ違い通信用データ５２０、タスクデータ５３０、アプリ関連データ５５０、本体設定データ５６０、受信ポリシーデータ５７０、インストールリスト５８０、ダウンロードリスト５９０、オン・ザ・フライ用キャッシュ６００が記憶される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最新システム更新日時５８１は、現在インターネットを介してゲーム装置１またはシステムプログラムを製造するメーカーから提供される、ゲーム装置１のシステムプログラムの最新の更新日時を示すデータである。ここで示されているデータと、ゲーム装置１に記憶されているシステムソフトウェアの最終更新日時とが一致するか否かで、システムアップデートの必要性が判定される。また、リストリビジョン５８２は、当該インストールリスト５８０のリビジョン（バージョン）を示す。

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

アプリ情報５８４は、インストール対象となりうるアプリケーションに関して定義したデータである、各アプリ情報５８４は、アプリＩＤ５８５、アプリバージョン５８６、アプリ種別５８７、レーティング情報５８８から構成される。

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

図１４に戻り、ダウンロードリスト５９０は、上記インストールリスト５８０と上記レーティング情報等に基づいて、実際にゲーム装置１にインストールすべきものを抽出してリストアップしたデータである。図２０は、ダウンロードリスト５９０のデータ構造の一例を示した図である。図２０において、ダウンロードリスト５９０は、複数の案件情報５９１で構成される。また、各案件情報５９１は、アプリＩＤ５９２、アプリ種別５９３、インストール優先度５９４から構成されている。アプリＩＤ５９２およびアプリ種別５９３は、上記インストールリスト５８０のアプリＩＤ５８５およびアプリ種別５８７がコピーされたものである。インストール優先度５９４は、実際にインストールを行う際の処理順序を決めるためのデータである。

図１４に戻り、オン・ザ・フライ用キャッシュ６００は、ゲーム装置１のシステムアップデートが実行される際に、システムアップデート用のデータを展開するための領域である。本実施形態では、システムアップデート用のデータは、圧縮ファイルとしてサーバにアップロードされる。そして、ゲーム装置１は、システムアップデートの処理を行う際は、当該圧縮ファイルをダウンロードするのと並行して、いわゆるオン・ザ・フライで当該圧縮ファイルの展開が行われる。この展開先が、当該オン・ザ・フライ用キャッシュ６００である。また、ここに展開されるときのアップデート用のファイル名は、実際のシステムデータのファイル名と異なった名前で展開されるものとする。例えば、実際のシステムデータのファイル名が「firmware.bin」であるとすると、オン・ザ・フライ用キャッシュ６００に展開されるアップデート用データのファイル名は、例えば、「firmware.upd」として展開される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図２６は、当該メニュー処理の詳細を示すフローチャートである。図２６において、まず、ステップＳ９１で、タスクの実行の結果として、システムのアップデート用のデータが取得されたか否かが判定される。これは、上記オン・ザ・フライ用キャッシュ６００にシステムアップデート用のデータが存在するか否かで判定される（なお、このデータは、後述する「インストール処理」において生成される）。このような判定手法の他、システムのアップデート用のデータが取得された際に、所定のフラグをオンに設定しておき、このフラグを参照して判断するようにしても良い。

当該判定の結果、システムのアップデート用のデータが取得されていないと判定されたときは（ステップＳ９１でＮＯ）、後述するステップＳ９７に処理が進められる。一方、システムのアップデート用のデータが取得されていると判定されたときは（ステップＳ９１でＹＥＳ）、ゲーム装置１のシステムアップデートに関する処理が実行される。具体的には、まず、上記オン・ザ・フライ用キャッシュ６００に存在するシステムアップデート用のデータが、システムデータが記憶されているメモリ領域に移動される。上述したように、オン・ザ・フライ用キャッシュ６００に展開されるアップデート用のデータのファイル名は、実際のシステムデータのファイル名とは異なる名前で展開されている。そのため、この時点では、システムデータが記憶されているメモリ領域には、例えば「firmware.bin」（アップデートが行われる前からのシステムデータ）と「firmware.upd」（アップデート用のデータ）というように、２つのデータが併存する状態となる。

次に、ステップＳ９２において、システムのアップデート用データを反映するか否かをユーザに確認するための確認画面が生成され、下側ＬＣＤ１２に表示される。そして、ユーザからの指示入力を受け付ける。このような確認画面を設けるのは、次のような理由による。すなわち、システムのアップデートは、ゲーム装置１の根幹に関わる内容であるため、その内容によっては、ユーザに大きな影響を与える可能性がある。そのため、このようにユーザに確認をとるようにしている。

次に、ステップＳ９３において、上記確認画面に対するユーザの指示内容が、アップデート用データの反映を指示する内容であるか否かが判定される。当該判定の結果、反映を指示する内容であれば（ステップＳ９３でＹＥＳ）、ステップＳ９４において、システムデータのアップデートが反映される。具体的には、上記元の（更新前の）システムデータを削除し、アップデート用データのファイル名をシステムデータの名前にリネームすることで、システムデータのアップデートの反映が行われる。このように、更新確認の問い合わせに対して、ファイル名のリネームという処理でシステムデータをアップデートするため、ユーザから見ると、一瞬でシステムのアップデートが行われたように見える。従来は、ユーザから見ると、このようなアップデート処理に際しては、処理の完了のための待ち時間が発生することが一般的であった。しかし、上記のように、システムのアップデータが存在した際は、とりあえずダウンロードおよびファイルの展開を済ませておき、その後、上記のような確認をユーザに取ることで、システムアップデートの際にユーザに対して待ち時間を感じさせることを防ぐことができる。上記ステップＳ９４の処理が終われば、その後、ステップＳ９５においてメニューの再起動が実行される。その結果、上記ステップＳ９１に処理が戻る。

なお、システムのアップデート以外のもの、例えば、無料アプリケーションや体験版ゲーム等は、システム全体に与える影響は小さいと考えられるため、上記のような問い合わせは行われずに自動的にインストールされ、メニュー画面に反映されることになる（後述する「インストール処理」）。

一方、上記ステップＳ９３の判定の結果、アップデートを反映しない旨の指示内容と判定されたときは（ステップＳ９３でＮＯ）、ステップＳ９６において、上記システムアップデート用のデータ（上記の例では「firmware.upd」）が破棄される。そして、上記ステップＳ９１に戻る。

次に、上記ステップＳ９１の判定の結果、システムのアップデート用のデータが取得されていないと判定されたときの処理（ステップＳ９１でＮＯ）について説明する。この場合は、次に、メニュー画面の生成が実行される。本実施形態では、ゲーム装置１にインストールされているアプリケーションをスキャンする処理が実行され、検出された各アプリケーションに対応するアイコンがメニュー画面上に適宜配置されることで、メニュー画面が生成されて表示される。また、このスキャンの過程において、新着要素（後述する「インストール処理」において新規インストールされたアプリ等）の有無に関連する処理も実行される。

具体的には、まず、ステップＳ９７において、ＮＡＮＤフラッシュメモリ３３のアプリ関連データ５５０が参照され、ゲーム装置１にインストールされている全てのアプリケーションについて、以下に説明するような処理（アプリケーションのスキャン）が行われたか否かが判定される。当該判定の結果、未処理のアプリケーションが残っていると判定されたときは（ステップＳ９７でＮＯ）、次に、未処理のアプリケーションの中からいずれか一つが処理対象として選択され（以下、スキャン対象アプリと呼ぶ）、ステップＳ９８において、当該スキャン対象アプリが新規にインストールされたアプリケーションであるか否かが判定される。これは、上記アプリ関連データ５５０が参照され、スキャン対象アプリに該当するアプリケーション領域の新規インストールフラグ５５４がオンに設定されているか否かで判定される。

当該判定の結果、スキャン対象アプリが新規にインストールされたアプリケーションであると判定されたときは（ステップＳ９８でＹＥＳ）、ステップＳ９９において、上記図５で示したようなプレゼントアイコン１１２が生成されて、メニュー画面上に適宜配置される。一方、新規にインストールされたアプリケーションではないと判定されたときは（ステップＳ９８でＮＯ）、ステップＳ１００において、当該スキャン対象アプリに対応するアイコンが生成されてメニュー画面上に適宜配置される。

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

次に、上記ステップＳ９７において、全てのアプリケーションについて処理済み（スキャン済み）と判定されたとき（ステップＳ９７でＹＥＳ）の処理について説明する。この場合は、次に、アプリケーションの起動・実行に関する処理が行われる。具体的には、まず、図２７のステップＳ１０３において、メニュー画面からいずれかのアプリケーションを示すアイコンが選択されたか否かが判定される。例えば、上記図４に示したようなメニュー画面でユーザが所定のアイコンに対してタッチオン操作したか否かが判定される。当該判定の結果、メニュー画面上のいずれのアプリケーション（のアイコン）も選択されていないと判定されたときは（ステップＳ１０３でＮＯ）、当該ステップＳ１０３の判定が繰り返される。

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

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

一方、上記ステップＳ１０４の判定の結果、新規インストールフラグがオフに設定されていると判定されたときは（ステップＳ１０４でＮＯ）、次に選択されたアプリケーションの起動およびその実行が行われる。まず、選択されたアプリケーションの起動に際して、ステップＳ１０７において、認証キーによる認証処理が行われ、認証が成功したか否かが判定される。ここで、当該認証処理は、何らかの原因でインストールされた不正なアプリケーションが実行されることを防ぐための処理である。アプリケーションプログラムと一緒にダウンロード等された認証キーを用いることで、正規のアプリケーションか否かの認証が行われる。当該判定の結果、認証に成功すれば（ステップＳ１０７でＹＥＳ）、ステップＳ１０８において、選択されたアプリケーションにかかる処理（以下、「各アプリの処理」と呼ぶ）が実行される。その後、当該アプリケーションにかかる処理が終了すれば、上記ステップＳ９１の処理に戻る。一方、認証に失敗したときは（ステップＳ１０７でＮＯ）、当該アプリケーションの実行はなされずに、上記ステップＳ９１の処理に戻る。以上で、本体メニュー処理の説明を終了する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、ステップＳ２５９において、処理対象タスクにかかるタスク設定５３１の送信／受信識別フラグ５３９を参照することにより、処理対象タスクの内容が「受信タスク」か否かが判定される。つまり、データの受信を行うためのタスクであるか、送信を行うためのタスクであるかが判定される。その結果、「受信タスク」であると判定されたときは（ステップＳ２５９でＹＥＳ）、ステップＳ２６０において、上記の処理で生成されたＨＴＴＰリクエストが、当該処理対象タスクにかかるタスク設定５３１の通信先ＵＲＬ５３５で示されるサーバに対して送信される。これに応じて、当該サーバが所定のデータの送信を開始するので、ステップＳ２６１において、当該サーバから送信されるデータのダウンロード（以下、ＤＬと呼ぶこともある）が開始される。ステップＳ２６２において、当該ダウンロードが完了したか否かが判定され、未完了であれば（ステップＳ２６２でＮＯ）、完了するまでダウンロードが継続される。ダウンロードが完了すれば（ステップＳ２６２でＹＥＳ）、続くステップＳ２６３において、当該処理対象タスクにかかるタスク設定５３１のファイルパス５３６で示される格納場所すなわち当該タスク設定５３１のアプリＩＤ５３２に対応するアプリケーションのアプリケーション領域５５１のタスク受信キャッシュ５５３に、ダウンロードされたデータが格納される。その後、後述するステップＳ２６７に処理が進められる。

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

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

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

次に、ステップＳ２７０において、タスク設定５３１の実行間隔５３８が参照されて次回実行時刻が算出され、次回実行時刻５３７として記憶される。

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

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

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

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

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

［インストール処理］
次に、上記ステップＳ２７２で示したインストール処理の詳細を説明する。本処理では、主に、システムのアップデートに関する処理、無料アプリや体験版ゲーム等の新規インストール処理、既存アプリの更新処理等が行われる。図４２〜図４３は、当該インストール処理の詳細を示すフローチャートである。まず、ステップＳ３１１において、インストールリスト５８０自体がアップデートされているか否かが判定される。これは、インストールリスト５８０のリストリビジョン５８２について、上記タスク実行処理における取得前のインストールリストのものと取得後のインストールリストのものとが比較されることで判定される。

当該判定の結果、インストールリスト５８０自体に更新がない（リストリビジョン５８２が同じ値）と判定されたときは（ステップＳ３１１でＮＯ）、本インストール処理は終了する。一方、インストールリスト５８０自体が更新されていると判定されたときは（ステップＳ３１１でＮＯ）、次に、ステップＳ３１２において、タスク実行処理において取得された最新のインストールリスト５８０における最新システム更新日時５８１が、本体設定データ５６０に記憶されているゲーム装置１自身の最新更新日時よりも新しいか否かが判定される。その結果、新しいと判定されたときは（ステップＳ３１２でＹＥＳ）、ステップＳ３１３において、ダウンロードリスト５９０に、「システムアップデート」を示す案件情報５９１が追加される。このとき、インストール優先度５９４には最上位で優先されることを示す値が設定される。一方、ステップＳ３１２の判定の結果、上記更新日時が新しくないと判定されたときは（ステップＳ３１２でＮＯ）、当該ステップＳ３１３の処理はスキップされる。

次に、ステップＳ３１４において、インストールリスト５８０に含まれている全てのアプリ情報５８４について、インストールを行うか否かの判断を行ったか否かが判定される。その結果、全てについて判断を行ったと判定されたときは（ステップＳ３１４でＹＥＳ），後述するステップＳ３１８に処理が進められる。一方、まだ未判断のアプリ情報５８４が残っているときは（ステップＳ３１４でＮＯ）、次に、ステップＳ３１５において、当該インストール判断が行われていないアプリ情報５８４からいずれか１つが選択される。

次に、ステップＳ３１６において、当該選択されたアプリ情報５８４のレーティング情報５８８と本体設定データ５６０に記憶されているユーザの年齢情報に基づいて、レーティングの条件が満たされているか否かが判定される。その結果、レーティングの条件が満たされていると判定されたときは（ステップＳ３１６でＹＥＳ）、ステップＳ３１７において、適宜インストール優先度５９４が設定された案件情報５９１がダウンロードリスト５９０に追加される。なお、ここで設定されるインストール優先度５９４には、上記システムアップデートにかかる優先度よりは低い値が設定される。そして、上記ステップＳ３１４に戻り、全てのアプリ情報５８４について判断されるまで、処理が繰り返される。一方、ステップＳ３１６の判定においてレーティングの条件が満たされていないと判定されたときは（ステップＳ３１６でＮＯ）、ステップＳ３１７の処理はスキップされて上記ステップＳ３１４に戻される。つまり、レーティングの条件を満たさないアプリケーションについてはダウンロードリスト５９０に追加されないので、インストールが行われないことになる。

次に、上記ステップＳ３１４の判定の結果、インストールリスト５８０の全てのアプリ情報５８４について判断が行われた（換言すれば、ダウンロードリスト５９０が完成した）ときの処理について説明する。この場合は、ダウンロードリスト５９０で示される各アプリケーション等のデータが適宜ダウンロードされてインストールされる。ここで、当該データのダウンロード先に関して説明する。本実施形態では、まず、ショップサーバと呼ばれる専用のサーバにアクセスする。そして、アプリＩＤを当該ショップサーバに通知すると、当該アプリのダウンロード先を示すＵＲＬがショップサーバから送られてくる。そして、当該ＵＲＬに基づいて所定のサーバから無料アプリケーション等の実体となるデータ（プログラムファイル等）がダウンロードされる。

次に、ステップＳ３１８において、ダウンロードリスト５９０に挙げられている案件情報５９１がインストール優先度５９４の順にソートされる。

次に、図４３のステップＳ３１９において、ダウンロードリスト５９０に挙げられている案件情報５９１の全てについてダウンロードが行われたか否かが判定される。その結果、全ての案件情報５９１についてダウンロードが終わったと判定されたときは（ステップＳ３１９でＹＥＳ）、インストール処理は終了する。

一方、ステップＳ３１９の判定の結果、案件情報５９１の全てについてダウンロードが行われていないと判定されたときは（ステップＳ３１９でＮＯ）、ステップＳ３２０において、まだダウンロードが行われていない案件情報５９１の中から、インストール優先度５９４が最上位の案件情報５９１が１つ選択される。以下、当該選択された案件情報５９１を処理対象案件情報と呼ぶ。

次に、ステップＳ３２１において、処理対象案件情報がシステムのアップデートにかかるものか否かが判定される。その結果、システムアップデートにかかる案件と判定されたときは（ステップＳ３２１でＹＥＳ）、ステップＳ３２２において、上記ショップサーバへのアクセスが行われ、システムの構成要素の一覧を示すデータが取得される。ここで、本実施形態にかかるゲーム装置１のシステムは、複数のプログラムによって構成されている。そのため、当該システムを構成する個々のプログラムのことを、構成要素と呼んでいる。例えば、上述したメニュー処理やローカル通信用ＢＧ処理等も、ここでいう構成要素に該当する。つまり、上記システムの構成要素の一覧とは、ゲーム装置１のシステムを構成するファイル（プログラム、データ）群のうち、更新が必要となるファイルの一覧である。

次に、ステップＳ３２３において、上記構成要素の一覧で示されている全構成要素のインストールが終了したかが判定される。全て終了したと判定されたときは（ステップＳ３２３でＹＥＳ）、上記ステップＳ３１９に戻り、処理が繰り返されることで、システムアップデート以外の他の案件情報の処理に移る。一方、全ては終了していないと判定されたときは（ステップＳ３２３でＮＯ）、ステップＳ３２４において、未インストールの構成要素のうち１つが選択される。次に、ステップＳ３２５において、選択された構成要素のデータを取得するためのリクエストが上記ショップサーバに送信される。続くステップＳ３２６において、当該ショップサーバから送信されてくる、上記選択された構成要素のダウンロード元を示すＵＲＬ情報が受信される。

次に、ステップＳ３２７において、当該ＵＲＬで示されるサーバへの接続が行われ、構成要素のダウンロードが開始される。ダウンロードが開始されると、ステップＳ３２８において、ダウンロードと並行して、オン・ザ・フライ用キャッシュ６００にダウンロードされつつある構成要素のデータが展開される。つまり、オン・ザ・フライでインストールされる。その後、ダウンロードおよびオン・ザ・フライでのインストールが終われば（オン・ザ・フライであるため、ほぼ同時刻に終了することになる）、上記ステップＳ３２３に戻り、処理が繰り返される。

次に、上記ステップＳ３２１の判定の結果、処理対象案件情報がシステムのアップデートにかかるものではない（ステップＳ３２１でＮＯ）と判定されたときの処理について説明する。このような場合は、処理対象案件情報で示される内容は、無料アプリケーションやアプリケーションの体験版等であると考えられる。この場合は、まず、ステップＳ３２９において、処理対象案件情報で示されるアプリＩＤ５９２がショップサーバに送信される。ここで、ゲーム装置１の固有情報（シリアルナンバー等）も同時に送信される。次に、ステップＳ３３０において、ショップサーバから送信されてくる、ダウンロード元のＵＲＬを示す情報が受信される。なお、ショップサーバは、上記アプリＩＤとともに送信されたゲーム装置１の固有情報を分析し、ＰＣ等の他の装置からではなくゲーム装置１からのリクエストであったか否かを判別する。ゲーム装置１からのリクエストであれば、上記ダウンロード元のＵＲＬを示す情報をゲーム装置１へ返す。

続くステップＳ３３１において、当該ＵＲＬで示されるサーバに接続され、上記無料アプリケーション等のデータのダウンロードが開始される。この際、アプリケーションを起動する前にアプリケーションの正当性の認証を行うためのキーもダウンロードされる。ダウンロードが開始されれば、ステップＳ３３２において、ＮＡＮＤフラッシュメモリ３３のプログラム領域５００のアプリケーションプログラム５０９として、オン・ザ・フライでインストールされる（既存のアプリケーションであれば上書きされ、新規のアプリケーションであれば、新たなアプリケーションプログラム５０９として展開される）。また、このとき、当該インストールされたアプリケーションが新規のアプリケーションであれば、当該新規インストールアプリケーションに対応するアプリ関連データ５５０も生成される。その結果、当該新規アプリケーションが上記ステップＳ９７におけるアプリケーションのスキャン対象となり、メニュー内に表示されることになる。

次に、ステップＳ３３３において、上記オン・ザ・フライでのインストールが終われば、当該インストールされたアプリケーションに対応するアプリケーション領域５５１の新規インストールフラグ５５４がオンに設定される。そして、上記ステップＳ３１９に戻り、処理が繰り返される。以上で、インストール処理の説明を終了する。

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

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

また、ユーザが気付かないうちにネットワーク接続すると共に、更に、上述したような無料アプリケーション等のダウンロード及びインストールも行っている。そのため、ユーザが次にゲーム装置１を動作させた際に、新しいアプリケーションが加わっている事等による驚きを与えることも可能となる。また、このようなアプリケーション等は既にインストール、あるいはアップデート済みになっているため、ユーザに待ち時間を与えることを防ぐ事もできる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明にかかる携帯型情報端末、携帯型情報システム、および携帯型情報端末制御プログラムは、本来常時接続での運用が想定されていない携帯型情報端末においても常時接続に近い使用感を提供することができ、携帯型ゲーム装置やＰＤＡ、ノートパソコン等に有用である。

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

Claims (27)

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. 非使用状態と、使用状態とを切り替える第１切替ステップと、
    少なくとも前記非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する探索ステップと、
    前記探索ステップにおいて所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う通信処理ステップと、
    ユーザにより設定可能な、少なくとも１つの第１アクセスポイントに関する情報、および、ユーザにより設定不可能な、少なくとも１つの第２アクセスポイントに関する情報を所定の記憶部に記憶させる記憶ステップと、
    ユーザにより前記少なくとも１つの第１アクセスポイントに関する情報を設定するアクセスポイント情報設定ステップとを備え、
    前記探索ステップは、
    前記少なくとも１つの第１アクセスポイントに関する情報に基づいて、当該少なくとも１つの第１アクセスポイントを探索する第１アクセスポイント探索ステップと、
    前記少なくとも１つの第２アクセスポイントに関する情報に基づいて、当該少なくとも１つの第２アクセスポイントを探索する第２アクセスポイント探索ステップとを含む、携帯型情報端末制御方法。

Images