以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。
(ゲーム装置の構成)
以下、本発明の一実施形態に係る情報処理装置の一例であるゲーム装置について説明する。ゲーム装置10は携帯型のゲーム装置である。図1および図2A〜Dに示されるように、ゲーム装置10は、下側ハウジング11および上側ハウジング21を有する。下側ハウジング11と上側ハウジング21とは、開閉可能(折り畳み可能)に接続されている。
(下側ハウジングの説明)
図1および図2A〜Dに示すように、下側ハウジング11には、下側LCD(Liquid Crystal Display:液晶表示装置)12、タッチパネル13、各操作ボタン14A〜14L、アナログスティック15、LED16A〜16B、挿入口17、および、マイクロフォン用孔18が設けられる。
タッチパネル13は、下側LCD12の画面上に装着されている。下側ハウジング11
の上側面には、タッチペン28を収納するための挿入口17(図1および図2Dに示す点線)が設けられている。
下側ハウジング11の内側面(主面)には、十字ボタン14A(方向入力ボタン14A)、ボタン14B、ボタン14C、ボタン14D、ボタン14E、電源ボタン14F、セレクトボタン14J、HOMEボタン14K、およびスタートボタン14Lが、設けられる。
アナログスティック15は、方向を指示するデバイスである。
下側ハウジング11の内側面には、マイクロフォン用孔18が設けられる。マイクロフォン用孔18の下部には後述する音声入力装置としてのマイク42(図3参照)が設けられる。
図2BおよびDに示されるように、下側ハウジング11の上側面には、Lボタン14GおよびRボタン14Hが設けられている。また、図2Aに示されるように、下側ハウジング11の左側面には、ゲーム装置10が備えるスピーカ43(図3参照)の音量を調整するための音量ボタン14Iが設けられる。
図2Aに示されるように、下側ハウジング11の左側面には開閉可能なカバー部11Cが設けられる。このカバー部11Cの内側には、ゲーム装置10とデータ保存用外部メモリ45とを電気的に接続するためのコネクタが設けられる。
図2Dに示されるように、下側ハウジング11の上側面には、外部メモリ44を挿入するための挿入口11Dが設けられる。
図1および図2Cに示されるように、下側ハウジング11の下側面にはゲーム装置10の電源のON/OFF状況をユーザに通知する第1LED16A、下側ハウジング11の右側面にはゲーム装置10の無線通信の確立状況をユーザに通知する第2LED16Bが設けられる。ゲーム装置10は他の機器との間で無線通信を行うことが可能であり、下側ハウジング11の右側面には、この無線通信の機能を有効/無効にする無線スイッチ19が設けられる(図2C参照)。
(上側ハウジングの説明)
図1および図2に示すように、上側ハウジング21には、上側LCD(Liquid Crystal Display:液晶表示装置)22、外側撮像部23(外側撮像部(左)23aおよび外側撮像部(右)23b)、内側撮像部24、3D調整スイッチ25、および、3Dインジケータ26が設けられる。
上側LCD22は、立体視可能な画像を表示することが可能な表示装置である。具体的には、パララックスバリア方式の裸眼立体視可能な表示装置である。上側LCD22は、視差バリアを用いてユーザの左目に左目用画像をユーザの右目に右目用画像を視認させることにより、ユーザにとって立体感のある画像(立体視画像)を表示することができる。また、上側LCD22は、上記視差バリアを無効にすることが可能であり、視差バリアを無効にした場合は、画像を平面的に表示することができる。このように、上側LCD22は、立体視画像を表示する立体表示モードと、画像を平面的に表示する(平面視画像を表示する)平面表示モードとを切り替えることが可能な表示装置である。この表示モードの切り替えは、例えば、後述する3D調整スイッチ25によって行われる。
外側撮像部23は、上側ハウジング21の外側面21Dに設けられた2つの撮像部(2
3aおよび23b)の総称である。外側撮像部(左)23aと外側撮像部(右)23bとは、ゲーム装置10が実行するプログラムによって、ステレオカメラとして使用することが可能である。
内側撮像部24は、上側ハウジング21の内側面21Bに設けられ、当該内側面の内向きの法線方向を撮像方向とする撮像部である。
3D調整スイッチ25は、スライドスイッチであり、上述のように上側LCD22の表示モードを切り替えるために用いられるスイッチである。また、3D調整スイッチ25は、上側LCD22に表示された立体視可能な画像(立体画像)の立体感を調整するために用いられる。3D調整スイッチ25のスライダ25aは、所定方向(上下方向)の任意の位置にスライド可能であり、当該スライダ25aの位置に応じて上側LCD22の表示モードが設定される。また、スライダ25aの位置に応じて、立体画像の見え方が調整される。
3Dインジケータ26は、上側LCD22が立体表示モードか否かを示すLEDである。
また、上側ハウジング21の内側面には、スピーカ孔21Eが設けられる。後述するスピーカ43からの音声がこのスピーカ孔21Eから出力される。
(ゲーム装置10の内部構成)
次に、図3を参照して、ゲーム装置10の内部の電気的構成について説明する。図3に示すように、ゲーム装置10は、上述した各部に加えて、情報処理部31、メインメモリ32、外部メモリインターフェイス(外部メモリI/F)33、データ保存用外部メモリI/F34、データ保存用内部メモリ35、無線通信モジュール36、第1マイコン37,加速度センサ39、電源回路40、インターフェイス回路(I/F回路)41、開閉検出器46等の電子部品を備えている。
情報処理部31は、所定のプログラムを実行するためのCPU(Central Processing Unit)311、画像処理を行うGPU(Graphics Processing Unit)312、VRAM(Video RAM)313を含む。CPU311は、ゲーム装置10内のメモリ(例えば外部メモリI/F33に接続された外部メモリ44やデータ保存用内部メモリ35)に記憶されているプログラムを実行することによって、当該プログラムに応じた処理を実行する。なお、CPU311によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。また、本実施形態では、CPU311はいわゆるマルチタスク制御が可能である。GPU312は、CPU311からの命令に応じて画像を生成し、VRAM313に描画する。VRAM313に描画された画像は、上側LCD22及び/又は下側LCD12に出力され、上側LCD22及び/又は下側LCD12に当該画像が表示される。
外部メモリI/F33は、外部メモリ28を着脱自在に接続するためのインターフェイスである。また、データ保存用外部メモリI/F34は、データ保存用外部メモリ29を着脱自在に接続するためのインターフェイスである。
メインメモリ32は、情報処理部31(のCPU311)のワーク領域やバッファ領域として用いられる揮発性の記憶装置である。
外部メモリ28は、情報処理部31によって実行されるプログラム等を記憶するための不揮発性の記憶装置である。外部メモリ28は、例えば読み取り専用の半導体メモリで構
成される。
データ保存用外部メモリ29は、不揮発性の読み書き可能なメモリ(例えばNAND型フラッシュメモリ)で構成され、任意のデータを保存するために用いられる。
データ保存用内部メモリ35は、読み書き可能な不揮発性メモリ(例えばNAND型フラッシュメモリ)で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ35には、無線通信モジュール36を介した無線通信によってダウンロードされたデータやプログラムが格納される。
無線通信モジュール36は、他の通信機器等と無線通信を行う機能を有する。本実施形態では、無線通信モジュール36は、後述するような「インフラストラクチャ通信」(以下、「インフラ通信」と呼ぶ)と「アドホック通信」という2種類の通信態様を実現することができる。「インフラ通信」は、例えばIEEE802.11b/g/nの規格に準拠した方式により、無線LANに接続する機能である。また、「アドホック通信」は、所定の通信方式(例えば独自プロトコルによる通信や、赤外線通信)により同種のゲーム装置との間で無線通信を行う機能である。詳細は後述するが、本実施形態では、この2種類の通信態様を用いて、「いつの間に通信」、「すれ違い通信」、「ローカル通信」という3種類の通信機能を適宜切り替えて実行する。
無線通信モジュール36には、第2マイコン361、RAM362等が含まれる。RAM362には、上記のような3種類の通信機能を実現するためのプログラムが格納される。特に、本実施形態では、RAM363の容量等の関係上、実行したい通信機能に応じて「いつの間に通信」用のプログラム、「すれ違い通信」用のプログラム、「ローカル通信」用のプログラムのいずれか一つが適宜選択されて、その都度RAM363に格納される。つまり、実行されるプログラムが適宜切り替えられる。そして、第2マイコン361は、RAM363に格納されているプログラムに基づき、上記のような3つの通信機能の実行を制御する。
加速度センサ39は、3軸(xyz軸)方向に沿った直線方向の加速度(直線加速度)の大きさを検出する。情報処理部31は、加速度センサ39が検出した加速度を示すデータ(加速度データ)を受信して、ゲーム装置10の姿勢や動きを検出することができる。
第1マイコン37は、ゲーム装置1の電源管理に関する処理や、時間に関する処理、上記ハウジングの開閉検知処理等を行う。また、これらの処理に関する通知をCPU311から受けたり、逆にCPU311に通知したりする。第1マイコン37は、リアルタイムクロック(RTC)371を備えている。RTC371は、時間をカウントし、第1マイコン37を介してCPU311に出力する。例えば、CPU311は、RTC371によって計時された時間に基づいて、現在時刻(日付)等を計算することもできる。
また、第1マイコン37は、開閉検出器46および電源回路40と接続される。開閉検出器46は、上記ハウジングの開閉を検出し、その内容を第1マイコン37(ひいてはCPU311)に通知する。電源回路40は、ゲーム装置1が有する電源(典型的には電池であり、下側ハウジング11に収納される)から供給される電力を制御し、ゲーム装置1の各部品に電力を供給する。また、電源回路40は、第1マイコン37(第1マイコン37を介したCPU311)からのスリープモードへの移行やスリープモード解除の通知を受ける。そして、当該通知に基づいて適切な電力を供給するための制御を行う。
ここで、本実施形態にかかるゲーム装置1の電源制御のモードに関して説明する。本ゲーム装置では、電池等の電源が装着されて、上記各構成部品への電力供給が可能な状態と
なった後は、基本的には、「通常電力モード」と「省電力モード」の2つの電源制御モードのいずれかで動作する。「通常電力モード」は、上記構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーション(以下、単にアプリと呼ぶ)を実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。本実施形態では、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、上記第1マイコン37、無線通信モジュール34にのみ電源を供給し、それ以外の部品、つまり、CPU311やLCDへの電力供給は停止している状態である(但し、CPU311は、「スリープモード」の解除指示を受けることは可能である)。また、「スリープモード」において、第1マイコン37や無線通信モジュール36(の第2マイコン361)は、「マイコン処理」、「スリープ中BG通信処理」と呼ばれる処理を所定時間毎に繰り返し実行するが、これについては詳細は後述する。
また、本実施形態では、上述のような、開閉検出器46の検出結果に基づいてスリープモードへの移行やスリープモードの解除を行う方法のほかに、電源ボタン14Fの操作に応じて上記「通常電力モード」と「スリープモード」を切り替えることが可能である。また、電源ボタン14Fの操作によるものの他、後述するような処理によって、自動的に「スリープモード」の解除、あるいは「スリープモード」への移行も可能となっている。例えば、ユーザが所定のゲームをプレイし終えた後、電源ボタン14Fを押すと(この操作は、ユーザから見ると、電源をオフにする操作に見える)、「スリープモード」に移行する。この状態で、ユーザはゲーム装置1を閉じて、持ち歩くこと等が可能である。その後、ユーザがゲーム装置1を開き、再度電源ボタン14Fを押すと、「スリープモード」が解除され、「通常電力モード」に移行する。または、所定時間が経過したことにより「スリープモード」へ移行するようにしてもよい。
その他、電源ボタン14Fを長押しすることで、第1マイコン37や無線通信モジュール36も含めた全ての構成部品への電力供給を停止する(つまり、完全に電源を切る)「完全停止モード」に移行することも可能である。この場合は、再度電源ボタン14Fを長押しすると、「通常電力モード」に移行してゲーム装置1が起動することになる。
ここで、上記電源制御モードに関し、ユーザがゲーム装置を使用中か否かという観点からは、以下のように言い換えることもできる。すなわち、ゲーム装置1は、「使用状態」と「非使用状態」という2つの状態を有するといえる。「使用状態」とは、ユーザがゲーム装置1のハウジングを開いて直接的に使用しているために、通常電力モードがずっと継続している状態である。例えば、ユーザが操作ボタン14等を操作して実際にゲーム等をプレイしている状態が該当する。一方、「非使用状態」とは、ユーザがゲーム装置1を主導的・直接的に使用していない状態をいう。これには、上記ハウジングが閉じられているために「スリープモード」となっている状態の他、後述するような「いつの間に通信」または「すれ違い通信」の実行に伴い、(ハウジングは閉じられたまま)一時的に「スリープモード」が解除されて「いつの間に通信」または「すれ違い通信」にかかる処理が実行され、その実行後は再度「スリープモード」に戻るような状態も含む。例えば、ユーザが外出する際に、ゲーム装置1のハウジングを閉じて鞄に入れている状態は「非使用状態」である。更に、このように、ゲーム装置1が鞄に入れられてユーザが外出している間に、上記のように一時的に「スリープモード」が解除されている状態、および、「いつの間に通信」の実行後に再度「スリープモード」に入るような状態(この間、ユーザはゲーム装置1を使用していない)も「非使用状態」である。また、当該「使用状態」と「非使用状態」が切り替わるためのトリガは、ハウジングの開閉の他、電源ボタン14Fが操作された場合もトリガとなる。つまり、ユーザがゲームをプレイしていたが(使用状態)、その後、ゲームのプレイを終えたため、ゲーム装置1の電源ボタン14Fを押下することで、
「使用状態」から「非使用状態」に切り替わる。その他、例えば、一定時間ユーザの操作がなかったために「使用状態」から「非使用状態」に切り替わる場合もある。
以下の説明においては、説明の簡略化のため、電源制御モードについては、「通常電力モード」と「スリープモード」の2つのモードだけを用いる場合を例として説明する。
I/F回路41には、タッチパネル13、マイク42およびスピーカ43が接続される。I/F回路41は、マイク42およびスピーカ43(アンプ)の制御を行う音声制御回路と、タッチパネルの制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成して情報処理部31に出力する。情報処理部31は、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われた位置を知ることができる。
操作ボタン14は、上記各操作ボタン14A〜14Lからなり、操作ボタン14から情報処理部31へは、各操作ボタン14A〜14Iに対する入力状況(押下されたか否か)を示す操作データが出力される。
下側LCD12および上側LCD22は情報処理部31に接続される。具体的には、情報処理部31は、上側LCD22のLCDコントローラ(図示せず)と接続され、当該LCDコントローラに対して視差バリアのON/OFFを制御する。上側LCD22の視差バリアがONになっている場合、情報処理部31のVRAM313に格納された右目用画像と左目用画像とが、上側LCD22に出力される。より具体的には、LCDコントローラは、右目用画像について縦方向に1ライン分の画素データを読み出す処理と、左目用画像について縦方向に1ライン分の画素データを読み出す処理とを交互に繰り返すことによって、VRAM313から右目用画像と左目用画像とを読み出す。これにより、右目用画像および左目用画像が、画素を縦に1ライン毎に並んだ短冊状画像に分割され、分割された右目用画像の短冊状画像と左目用画像の短冊状画像とが交互に配置された画像が、上側LCD22の画面に表示される。そして、上側LCD22の視差バリアを介して当該画像がユーザに視認されることによって、ユーザの右目に右目用画像が、ユーザの左目に左目用画像が視認される。以上により、上側LCD22の画面には立体視可能な画像が表示される。
外側撮像部23および内側撮像部24は、情報処理部31の指示に従って画像を撮像し、撮像した画像データを情報処理部31に出力する。
3D調整スイッチ25は、スライダ25aの位置に応じた電気信号を情報処理部31に送信する。
情報処理部31は、3Dインジケータ26の点灯を制御する。例えば、情報処理部31は、上側LCD22が立体表示モードである場合、3Dインジケータ26を点灯させる。
次に、本実施形態で想定する処理の概要について説明する。本実施形態のゲーム装置10では、バックグラウンド処理として行われる通信として、後述するような「すれ違い通信」と「いつの間に通信」と呼ばれる2種類の通信を行う。一方、ゲーム装置10は、上記のような「スリープモード」と「通常電力モード」という2つの状態を有する。本実施形態にかかる処理は、主に、このようなゲーム装置の2つの状態に応じた上記の2種類の通信の制御に関するものである。
[ネットワークの全体構成]
まず、本実施形態で想定するネットワークの全体的な構成について説明する。図4は、本実施形態にかかるネットワーク構成の全体像を示す模式図である。図4で示されるゲーム装置10は、上述したように、大きく分けて2種類の通信態様を用いる。1つめの通信態様は、インターネットを利用する態様である「インフラ通信」である。この態様では、ゲーム装置10は、アクセスポイント(以下、単にAPと呼ぶ)102を経由して所定のサーバとの通信を行う。本実施形態では、この「インフラ通信」の通信態様を利用して「いつの間に通信」という通信機能を実現する。2つめの通信態様は、インターネットは経由せず直接的にゲーム装置同士を無線接続する「アドホック通信」である。本実施形態では、「アドホック通信」の通信態様を利用して、「すれ違い通信」と「ローカル通信」の2つの通信機能を実現する。以下、これら3つの通信機能の概要を説明する。
[いつの間に通信]
まず、「いつの間に通信」について説明する。この通信機能は、バックグラウンドで実行される通信であり、アクセスポイント(以下、APと呼ぶ)を介して所定のサーバと接続し、当該サーバとの間で所定のデータの送受信を実行するものである。例えば、以下のような通信が行われる。例えば、ゲーム装置10が「スリープモード」のときを想定する。この場合に、接続可能なAPがゲーム装置10の近くに存在すれば、当該APに自動的に接続し、更に、当該APを経由して所定のサーバに自動的に接続する。そして、当該サーバから、例えば、新作ゲームの体験版プログラムが送信され、これが受信される。その後、当該体験版プログラムが実行可能なように各種設定(インストール処理等)が行われる。これにより、ユーザから見ると、例えばゲーム装置を「スリープモード」にして外出し、自宅に帰ってきてからゲーム装置10を「通常電力モード」に戻すと、いつの間にかメニューに新作ゲームの体験版が追加されている、という状態となる。また、「通常電力モード」のときもバックグラウンドで「いつの間に通信」は実行される。このような場合は、例えば、あるゲームをプレイしている時にバックグラウンドで上記のような体験版プログラム等の受信が行われ、ユーザがゲームをプレイし終えて、ゲーム装置10のホームメニューに切り替えた際に、メニューに新作ゲームの体験版がいつの間にか増えている、という状態となる。なお、本実施形態では、「いつの間に通信」で接続されるサーバ(「いつの間に通信」における通信相手)として、専用のサーバが設けられており、どのAPを経由しても当該専用のサーバに接続することが可能である。
本実施形態では、上記「いつの間に通信」の実行は「タスク」と呼ばれる単位で管理されている。「タスク」は複数定義することができる。各「タスク」には、送受信するデータの内容や、送受信処理を実行するタイミング(スケジュール)などが規定されている。各「タスク」で実行される内容例としては、「システムのアップデート」や「新作ゲームの体験版の取得」等がある。また、ゲーム装置10にインストールされている各種アプリ毎に所定のデータの送受信を行う内容の「タスク」もある。例えば、レースゲームにおいて、ユーザのラップタイムを定期的にサーバに送信すると共に、サーバからは全国ランキングのデータを受信するような内容のタスクである。
そして、本実施形態では、各「タスク」に規定されている実行スケジュールに基づいて各「タスク」の実行時間の到来が判定され、実行時刻が到来している「タスク」があれば、その「タスク」の規定内容に沿って所定のデータの送受信が所定のサーバとの間で行われることになる。ここで、本実施形態では、「いつの間に通信」を行うためには所定のAP(およびサーバ)との接続が必要になる。そのため、ある「タスク」の実行時刻が到来しても、ゲーム装置10の通信可能範囲内にAPが存在しなければ、その時点では当該「タスク」に基づく「いつの間に通信」が行えない。このような場合は、この「タスク」の実行は保留され、次にAPおよびサーバと通信可能になったタイミングでサーバとの送受信が行われることになる。
このように、「いつの間に通信」は、バックグラウンドの処理として、APを介して所定のサーバと自動的に接続し、所定のデータの送受信を自動的に行う処理である。
なお、上記「インフラ通信」については、上記「いつの間に通信」に利用する他、ユーザがウェブブラウザ等のアプリケーションを実行することでインターネットを利用するような処理にも利用される。つまり、上記APに接続されている状態であれば、ゲーム装置10は、上記「いつの間に通信」も実行可能であり、(ユーザの操作に基づく)インターネットの利用にかかる通信も実行可能な状態といえる。但し、本実施形態の説明においては、「いつの間に通信」以外の「インフラ通信」を利用した通信処理については直接的には関係しないため、詳細な説明は省略する。
[すれちがい通信]
次に、「すれちがい通信」について説明する。この処理もバックグラウンドで実行される処理である。「すれ違い通信」では、ゲーム装置10同士が直接接続され(ピアツーピア接続)、「すれ違い通信」用として予め用意されているデータの送受信が行われる。具体的には、各ゲーム装置10のデータ保存用内部メモリ35には、「すれ違い通信」用のデータ領域が予め用意されている。この領域は、「スロット」と呼ばれる単位で管理される。本実施形態では、12のスロットが予め用意されているとする。各「スロット」には、ゲーム装置10で実行可能なアプリのうちいずれか1つのアプリと対応付けられる。そして、各スロットには、送信用のデータ領域と受信用のデータ領域が含まれている。なお、スロットの数は一例であり、これに限定される必要はなく、12より少なくてもよいし、多くてもよい。
そして、以下のような流れで「すれ違い通信」が実行される。まず、所定のアプリの実行中に、適宜すれ違い用の送信データが上記スロット内に格納される(アプリとスロットの対応付けは済んでいるものとする)。その後、アプリが終了され、ユーザによってゲーム装置10が「スリープモード」に移行される。そして、ユーザがこのゲーム装置を所持して外出し、ゲーム装置10の通信可能範囲内に他のゲーム装置10が入ったとする。このときに、お互いのゲーム装置10の間で、共通するアプリのスロットの内容が送受信される。つまり、ゲーム装置Aのスロット内の送信用データがゲーム装置Bに送信されると共に、ゲーム装置Bから送信されてきた送信用データが受信され、受信データとして格納される。これにより、互いのスロットに共通して対応付けられているアプリに関して、データの送受信が行われることになる。なお、互いのスロットで共通するアプリがなかった場合は、上記の様なデータの送受信も行われず、結果的に「すれ違い通信」は行われないことになる。
このように、「すれ違い通信」は、バックグラウンドの処理として、ゲーム装置10同士で直接的に「すれ違い通信」用のデータの送受信(データの交換)を自動的に行う通信である。
[ローカル通信]
次に、「ローカル通信」について説明する。この通信は、フォアグラウンドで実行される通信である。例えば、対戦ゲーム等の実行中に行われる。すなわち、対戦ゲーム処理の一環として、ゲーム装置10同士が上記アドホック通信の態様で接続され、各ゲーム装置10の操作データ等の送受信処理を行うような場合が「ローカル通信」に該当する。換言すれば、「ローカル通信」は、上記「すれ違い通信」のように自動的に通信が行われるものではなく、例えば、対戦ゲームの開始前に、ユーザの入力操作によりお互いが「ローカル通信」を行うことを希望し、互いに同意したときに行われる通信といえる。
上記のように、本実施形態では、3種類の通信機能が利用可能となっている。ここで、これらの通信機能を行う前提として、通信可能範囲内に接続対象が存在するか否かを判定する為のサーチ処理が必要となる。すなわち、「いつの間に通信」であれば、接続可能なAPをサーチする必要があり、「すれ違い通信」「ローカル通信」では、接続可能な他のゲーム装置10をサーチする必要がある。その一方で、上記のようにゲーム装置10の無線通信モジュール36は1つである。そのため、上記の通信機能は同時に実行することができず、利用局面に応じてこれらの通信機能が適宜切り替えて実行される。本実施形態では、バックグラウンドで行われる通信である「いつの間に通信」および「すれ違い通信」については、所定の周期でのサーチの切替制御が行われている。以下、バックグラウンドで行われる「いつの間に通信」および「すれ違い通信」のサーチ(以下では、両サーチをまとめてバックグラウンドサーチと呼ぶこともある)の切替制御の概要を、「スリープモード」時の制御と「通常電力モード」時の制御とに分けて説明する。
[スリープモード時の切替制御]
まず、「スリープモード」の場合の切替制御について説明する。本実施形態では、この場合は、図5に示すような周期(サーチパターン)で「いつの間に通信」および「すれ違い通信」のサーチを切り替えている。図5においては、まず、「すれ違い通信」についてのサーチ期間として予め30秒の期間が設定されている。すなわち、この30秒の間は、「すれ違い通信」用のサーチ(他のゲーム装置10のサーチ)が行われる。なお、以下の説明では、この「すれ違い通信」用のサーチ期間を第1割当期間と呼ぶこともある。その後、「いつの間に通信」用のサーチ処理が1回入る。このサーチ処理はAPをサーチする処理であるが、AP−ゲーム装置間の電波強度等の関係で、このサーチの結果がわかるまでの期間は不定である。そのため、図5では、一例として、5〜10秒と示している。その後、また30秒間の再度「すれ違い通信」用のサーチが行われ、更にその後、「いつの間に通信」用のサーチ処理が1回行われる。つまり、30秒の間「すれ違い通信」用サーチ処理を行った後、「いつの間に通信」用のサーチ処理を1回行う、というパターンを1セットとして、このセットが繰り返し行われる。
そして、上記サーチの結果、接続対象が見つかった場合は、「すれ違い通信」あるいは「いつの間に通信」が実行されることになる。一旦「すれ違い通信」あるいは「いつの間に通信」が開始されれば、その処理にかかる一連の通信処理が完了するまでは、上記サーチ処理は行われない。例えば、「すれ違い通信」用のサーチ期間において、25秒経過時点で他のゲーム装置10が見つかり、「すれ違い通信」が開始された場合、サーチ期間の30秒が経過しても、この「すれ違い通信」にかかる一連の送受信処理が終わるまでは、APのサーチ処理は行われない。
ここで、上記30秒の期間(第1割当期間)中における「すれ違い通信」のサーチの動作についてより詳しく説明する。本実施形態では、「すれ違い通信」の接続の確立処理に際して、いずれかのゲーム装置が「親機」の立場となり、他方のゲーム装置が「子機」の立場となる。そして、上記30秒の期間の間、ゲーム装置10は、「親機」の立場と「子機」の立場を切替ながらサーチ処理を行っている。ここでは、ゲーム装置10が「親機」の立場である場合を「マスターモード」、「子機」の立場である場合を「クライアントモード」と呼ぶ。「クライアントモード」では、ゲーム装置10は、接続要求を希望する旨のビーコンを自らブロードキャストする。なお、このビーコンには、当該ビーコンが「すれちがい通信」用のビーコンである旨を示すデータ(例えば所定のID)が含まれている。一方、「マスターモード」では、ゲーム装置10は、他のゲーム装置10から送信される上記ビーコンの受信を試みる(つまり、他のゲーム装置10からのビーコンの待ち受け状態となる)。具体的には、マスターモードにおいては、ゲーム装置10は、とりあえずビーコンを受信し、上記「すれちがい通信」用のビーコンである旨を示すデータが当該受信したビーコンに含まれているか否かを判定する。そして、含まれていなければ、そのビ
ーコンは破棄して他のビーコンの受信を行う。含まれていれば、「すれ違い通信」のための処理(接続確立処理やデータの送受信処理等)を行う。
そして、本実施形態では、例えば、上記30秒の期間を1秒の期間で区切る(以下では、この1秒の期間を第2割当期間と呼ぶ)。そして、基本的には「クライアントモード」として動作し、5秒に1回の割合で「マスターモード」に切り替わるように、モードの切替パターンが設定される。これは、「マスターモード」における消費電力が「クライアントモード」における消費電力に比べて大きいため、「すれ違い通信」の行われやすさと消費電力の低減化とのバランスを考慮して導き出された割合である。
このように、「スリープモード」においては、30秒間「すれ違い通信」用のサーチが繰り返し行われた後、「いつの間に通信」用のサーチが1度だけ行われ、その後、また30秒間の「すれ違い通信」用のサーチに戻るという切替パターンで切替制御が行われている。つまり、「すれ違い通信」のほうが「いつの間に通信」よりも優先されるような制御が行われる。これは、「スリープモード」の場合は、典型的には、ハウジングが閉じられた状態で家の外で持ち歩かれているような状態であることが考えられるので、「すれ違い通信」による他のゲーム装置10との通信が行われやすい環境にしておこうという観点によるものである。
[通常電力モード時の切替制御]
次に、「通常電力モード」での切替制御の概要について説明する。この場合も、基本的には「スリープモード」と同様のパターンでバックグラウンドサーチの切替制御が行われる。つまり、30秒間の「すれ違い通信」用サーチの後、「いつの間に通信」用のサーチが一度行われ、また30秒間の「すれ違い通信」用サーチに入る、というパターンである。但し、「スリープモード」の場合と異なり、「通常電力モード」においては、「いつの間に通信」用のサーチの結果、通信可能なAPが検知され、当該AP(およびその先のサーバ)との接続が確立すれば、「いつの間に通信」にかかる一連の送受信処理が終了した後も、APとの接続は切断せずに、接続状態を維持する。図6Aは、このような通常電力モードでの切替制御の一例を示す模式図である。「いつの間に通信」用のサーチの結果、APが検知されて接続が確立すれば、当該APとの通信ができなくなるまで(例えば、ゲーム装置10が移動されて通信可能範囲内にAPが存在しなくなるまで)、当該APとの接続状態は維持される。つまり、「通常電力モード」では「いつの間に通信」(インフラ通信)のほうが優先されるような制御が行われる。これは、「通常電力モード」の場合は、ユーザがゲーム装置10に何らかの操作を行って使用している状態、例えば、ブラウザを立ち上げてインターネットを利用している場合が考えられることや、いわゆる「フレンドリスト」に登録された友達のログイン状況を把握して表示する等の処理を行いたい等、つまり、「インフラ通信」を利用した処理が必要となる可能性が高くなるであろうという観点から、「インフラ通信」に基づく処理がスムーズに行われるようにしておこうとするものである。
このように、本実施形態では、バックグラウンドで行われる通信について、「スリープモード」においては「すれ違い通信」が行われやすくなるような制御が行われ、「通常電力モード」では、「いつの間に通信」(インフラ通信)が行われやすくなるような制御が行われている。これにより、ゲーム装置の使用状態に応じて、実行させたい通信態様の実行可能性を変化させることができる。
なお、「通常電力モード」においてバックグラウンドで通信が行われている最中に、ユーザがハウジングを閉じる等して「スリープモード」への移行指示が発行された場合は、通信処理の途中であっても、当該通信処理は中止されてスリープモードに移行する。そして、上記図5で示したような「スリープモード」におけるサーチパターンでのバックグラ
ウンドサーチ処理が開始されることになる。
次に、「通常電力モード」における、上記バックグラウンド通信である「すれ違い通信」および「いつの間に通信」と、フォアグラウンドの処理である「ローカル通信」との間の切替制御に関して説明する。「すれ違い通信」および「いつの間に通信」はバックグラウンド通信であるため、所定のアプリケーションの実行と並行して通信することが可能である。その一方で、上記のようにゲーム装置10の無線通信モジュール36は1つだけである。そのため、例えば、「ローカル通信」を用いた対戦ゲーム処理(フォアグラウンドの処理)を行おうとするとき、バックグラウンド通信に無線通信モジュール36が占有されている状態だと、「ローカル通信」を行うことができなくなる。また、その他、フォアグラウンドのアプリで「ローカル通信」が行われなくとも、例えば「いつの間に通信」でサイズの大きなデータの送受信が行われているような場合に、その影響で処理負荷が一時的に高まり、フォアグラウンドのアプリの実行速度に影響を与える可能性もある。そこで、本実施形態では、アプリ側からバックグラウンド通信の停止指示を出すことで、バックグラウンドサーチ等を停止させることを可能としている。これにより、例えば、上記のような「ローカル通信」を用いて対戦ゲーム処理を行う場合は、当該対戦ゲームのアプリから(システムに対して)バックグラウンド通信の停止指示を出す。これに応じて、実行中のバックグラウンド通信の処理やバックグラウンドサーチが停止され、実質的に、無線通信モジュール36がフリーの状態となる。その後、当該対戦ゲームのアプリが当該無線通信モジュール36を用いて「ローカル通信」にかかる処理を実行することが可能となる。その後、当該アプリから停止解除の旨の通知がなされる等して、停止指示が消滅すれば、再度バックグラウンドサーチが開始される(図6B参照)。なお、停止指示を出すことが可能なアプリは、フォアグラウンドで実行中のものに限らず、バックグラウンドで実行中のアプリから停止指示を出すことも可能である。
次に、ゲーム装置1において行われる上記のような処理の詳細を説明する。まず、本処理において用いられる主なプログラムおよびデータについて説明する。なお、本実施形態における処理の実行主体に関して説明すると、本実施形態では、第1マイコン37、第2マイコン361、CPU311が、それぞれ独立して、以下に説明する処理の実行主体となり、これらの処理が互いに連携しながら並列的に実行される。
図7は、第1マイコン37に内蔵されている記憶領域(図示せず)に記憶される主なデータを示す図である。第1マイコン37の内部には、プログラム領域301とデータ領域303が存在し、プログラム領域301には、第1マイコン37が担当する処理を実行するためのマイコン処理プログラム302が記憶され、データ領域303には、給電状態フラグ304、次回起床時刻305が記憶される。給電状態フラグ304は、「スリープモード」であるか否かを示すためのフラグである。オンに設定されているときは「通常電力モード」、オフに設定されているときは、「スリープモード」であるとする。次回起床時刻305は、「スリープモード」を解除する時刻を示すデータである。例えば、本実施形態では、上記各タスクに設定される次回実行時刻のうち、最も早い時刻が次回起床時刻305として設定される。
図8は、無線通信モジュール36に内蔵されているRAM362に記憶される主なデータを示す図である。RAM362には、プログラム領域401とデータ領域403が存在する。プログラム領域401には、後述するスリープ中BG通信処理プログラム5021、「すれ違い通信」処理プログラム5022、「ローカル通信」処理プログラム5023、インフラ通信用プログラム5024のうちのいずれか1つが適宜選択されて格納される。データ領域403には、APに関する情報等が記憶される。なお、スリープ中BG通信処理プログラム5021と「すれ違い通信」処理プログラム5022は同一のプログラムであってもよい。この場合は、パラメータの設定を変えることによってそれぞれの処理動
作を変えることができる。
図9は、データ保存用内部メモリ35に記憶されるプログラム、データを示す図である。なお、これらのデータは、必要に応じてメインメモリ32に展開されて実行される。データ保存用内部メモリ35は、プログラム領域501とシステム用データ領域504とアプリ用データ領域513とを有しており、プログラム領域500には、システム用プログラム領域502が設けられている。また複数のアプリケーションプログラム(図9では第nアプリケーションプログラムと示す)が記憶される。システム用プログラム領域502には、図10で示すような複数のプログラムが記憶される。図10において、システム用プログラム領域502には、スリープ中BG通信処理プログラム5021、「すれ違い通信」処理プログラム5022、「ローカル通信」処理プログラム5023、インフラ通信用プログラム5024、通常時BG通信処理プログラム5025、管理処理プログラム5026、本体用カウンタ設定処理プログラム5027、「いつの間に通信」処理プログラム5028が記憶される。
ここで、これらプログラムに基づき実行される処理と、その実行主体となる上記第1マイコン37、第2マイコン361、CPU311との関係について簡単に説明する。図11は、「スリープモード」における各実行主体と、各実行主体が実行する処理を示す図である。また、図12は、「通常電力モード」における各実行主体と、各実行主体が実行する処理を示す図である。図11では、第1マイコン37がマイコン処理を実行することで、上記タスク(「いつの間に通信」)の実行時刻の管理や本体の開閉状態の検知を行う。また、第2マイコン361は、スリープ中BG通信処理を実行する。この処理は、上記図5で示したような切替パターンに沿ってバックグラウンドサーチ等を行うためのものである。CPU311は、基本的には「スリープモード」であるため、通電していない状態である。但し、マイコン処理においてタスクの実行時刻が到来したことが検知され、且つ、APとの通信が可能な状態であると判定されたときに、一時的に通電されて、「いつの間に通信」に関する処理を実行する。また、無線通信モジュールのマイコン処理においてAPが探索(検出)されたと判定されたときに、一時的に通電されて、「いつの間に通信」に関する処理を実行する。さらに、無線通信モジュールのマイコン処理において他のゲーム装置が探索(検出)されたと判定されたときに、一時的に通電されて、「すれ違い通信」に関するデータ交換処理を実行する。
また、図12においては、第1マイコン37は「スリープモード」のときと同じ動作を行う。第2マイコン361は、状況に応じて、「すれ違い通信」、「ローカル通信」、「インフラ通信」用のプログラムのいずれかを実行する。CPU311は、フォアグラウンドの処理として、所定のアプリケーション処理を実行する。また、バックグラウンドの処理として、管理処理と通常時BG通信処理を実行する。管理処理は、主に、アプリの起動指示の監視や、上述したようなアプリからのバックグラウンド通信停止指示の監視等を行う。通常時BG通信処理は、「通常電力モード」における「すれ違い通信」や「いつの間に通信」を実行するための処理である。なお、本実施形態では、アプリケーションは複数起動することが可能であるが、フォアグラウンドとして実行されるものは1つだけであり、フォアグラウンドで実行中のアプリ以外のアプリについてはバックグラウンドの処理として適宜処理される。
図9に戻り、次に、システム用データ領域504について説明する。システム用データ領域504には、「すれ違い通信」用データ505、「いつの間に通信」用データ506、アプリ用カウンタ507、本体用カウンタ510等が記憶される。
「すれ違い通信」用データ505は、「すれ違い通信」で用いるデータである。図13は、「すれ違い通信」用データ505のデータ構造の一例を示した図である。「すれ違い
通信」用データ505は、スロット5051の集合で構成されており、各スロット5051は、アプリID5052、送信データ5053、受信データ5054とから構成される。アプリID5052は、そのスロット5051に対応付けられているアプリケーションを示すIDである。送信データ5053は、「すれ違い通信」において他のゲーム装置10に送信されるデータである。受信データ5054は、「すれ違い通信」において他のゲーム装置10から受信したデータである。
図9に戻り、「いつの間に通信」用データ506は、「いつの間に通信」で用いられるデータである。図14は、「いつの間に通信」用データ506のデータ構造の一例を示した図である。「いつの間に通信」用データ506は、タスク5061の集合で構成されている。各タスク5061は、タスク内容定義データ5062、送信データ5063、受信データ5064等で構成されている。タスク内容定義データ5062は、そのタスクの動作内容を規定したデータである。例えば、次回に当該タスクを実行する時刻を示す次回実行時刻を示すデータ(図示は省略)が含まれる。その他、当該タスクに対応するアプリを示す情報や当該タスクの実行回数、実行優先度等を示す情報も含まれる。送信データ5063は、当該タスクにおいて所定のサーバに送信されるデータである。受信データ5064は、当該タスクにおいて所定のサーバから受信したデータである。
図9に戻り、アプリ用カウンタ507は、上述したような、アプリから発行されるバックグラウンド通信の停止指示を制御するために用いられるデータである。実行中のアプリ1つにつき、1つのアプリ用カウンタ507が割り当てられる。各アプリ用カウンタ507は、第1停止カウンタ508および第2停止カウンタ509で構成される。第1停止カウンタ508は、「すれ違い通信」を停止させたい際に用いられるカウンタである。各アプリの処理において、「すれ違い通信」を停止させたい旨の命令が発行されると、当該カウンタの値が加算される。第2停止カウンタ509は、「いつの間に通信」を停止させたい際に用いられるカウンタである。各アプリの処理において、「いつの間に通信」を停止させたい旨の命令が発行されると、当該カウンタの値が加算される。なお、各アプリの実行に際して、アプリを構成している複数の機能モジュールが内部的には並列で実行されうる。そして、上記のような停止指示は機能モジュール単位で発行されるため、1つのアプリ内で複数の機能モジュールから停止指示が発行されることもある。この場合は、カウンタの値は2以上の値になり得る。
次に、本体用カウンタ510は、バックグラウンド通信の停止指示を制御するために用いられるデータであり、第3停止カウンタ511および第4停止カウンタ512で構成される。第3停止カウンタ511は、上記複数のアプリ用カウンタ507で示される第1停止カウンタ508、すなわち、「すれ違い通信」の停止指示をとりまとめた内容となる。また、第4停止カウンタ512は、上記複数のアプリ用カウンタ507で示される第2停止カウンタ509、すなわち、「いつの間に通信」の停止指示をとりまとめた内容となる。例えば、実行中のアプリが複数ある場合、これらアプリのうちどれか一つでも「すれ違い通信」の停止指示を出していれば、「すれ違い通信」にかかる処理は停止される。
その他、システム用データ領域504には、操作データ等、システム制御に必要な各種データが記憶される。
次に、アプリ用データ領域513には、各アプリで用いられるデータが適宜記憶される。例えば、アプリの内容が対戦ゲームであれば、当該対戦ゲーム処理で用いられる各種データが適宜記憶される。
次に、ゲーム装置1によって実行される上記のような処理の詳細について説明する。まず最初に第1マイコン37が行う処理について説明する。
[第1マイコン37が実行する処理]
図15は、第1マイコン37によって実行されるマイコン処理を示すフローチャートである。図15で示される処理は、ゲーム装置10の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。
図15において、まず、ステップS1で、ゲーム装置1が上記「スリープモード」であるか否かが判定される。具体的には、上記給電状態フラグ304が参照されることによって「スリープモード」か否かが判定される。当該判定の結果、「スリープモード」ではないときは(ステップS1でNO)、後述のステップS7に処理が進められる。一方、「スリープモード」であると判定されたときは(ステップS1でYES)、次に、ステップS2において、無線通信モジュール36(の第2マイコン361)から発行される、APを検出した旨の通知を受けたか否かが判定される(当該通知は、後述の図16のステップS24において発行される)。当該判定の結果、APを検索した旨の通知が無線通信モジュール36から発行されていないときは(ステップS2でNO)、後述のステップS7に処理が進められる。一方、APを検索した旨の通知が無線通信モジュール36から発行されていたときは(ステップS2でYES)、ステップS4において、「スリープモード」を解除して「通常電力モード」に移行させるための命令が第1マイコン37からCPU311に対して発行されるとともに、給電状態フラグ304をオンにし、かつ、電源回路にスリープを解除する旨を通知する。更に、「いつの間に通信」の実行指示もCPU311に対して発行される。
この後、CPU311は一時的に通電されて動作可能な状態となり、後述するような「いつの間に通信」にかかる処理を実行する。そして、その実行が終われば、「いつの間に通信」が終了した旨の通知がCPU311から第1マイコン37に送信される。
次に、ステップS5において、上記「いつの間に通信」が終了した旨の通知を受けたか否かが判定される。その結果、当該通知を受けていない間は(ステップS5でNO)、ステップS5の判定が繰り返される(つまり、「いつの間に通信」の終了まで待機することになる)。一方、当該通知を受けたときは(ステップS5でYES)、ステップS6において、「スリープモード」に移行させるための命令が第1マイコン37からCPU311に発行されるとともに、給電状態フラグ304をオフにし、かつ、電源回路40に、スリープに移行する旨が通知される。なお、上記ステップS4の「スリープモード」を解除して「通常電力モード」に移行させるための命令、ステップ5の判定、およびステップS6の「スリープモード」に移行させるための命令は、第1マイコン37ではなく、無線通信モジュール36の第2マイコン361によって実行されてもよい。
次に、ステップS7において、ゲーム装置10が閉状態(ハウジングが閉じられている状態)から開状態(ハウジングが開かれた状態)に移行したか否か(つまり、ゲーム装置10が開かれたか否か)が判定される。具体的には、第1マイコン37は、開閉検出器46からハウジングが開かれたことを示す検出信号があったか否かを判定する。当該判定の結果、閉状態から開状態に移行したと判定されたときは(ステップS7でYES)、次のステップS8において、「スリープモード」を解除するための命令が第1マイコン37からCPU311に発行されるとともに、給電状態フラグ304をオンにし、かつ、電源回路40に、スリープを解除する旨を通知する。これに応じて、電源回路40は、適宜、ゲーム装置10の各構成部品への電力供給を開始する。
一方、ステップS7の判定の結果、ゲーム装置10が閉状態から開状態に移行していないと判定されたときは(ステップS7でNO)、次に、ステップS9において、ゲーム装置1が開状態から閉状態に移行したか否か(つまり、ゲーム装置10が閉じられたか否か
)が開閉検出器46からの信号により判定される。その結果、ゲーム装置10が開状態から閉状態に移行したと判定されたときは(ステップS9でYES)、次のステップS10において、「スリープモード」に移行させるための命令が第1マイコン37からCPU311に発行されるとともに、給電状態フラグ304をオフにし、かつ、電源回路40に、スリープに移行する旨が通知される。これに応じて、電源回路40は、適宜、ゲーム装置10の各構成部品への電力供給を停止する。一方、ステップS9の判定の結果、ゲーム装置1が開状態から閉状態に移行していないと判定されたときは(ステップS9でNO)、上記ステップS10の処理がスキップされて、マイコン処理は終了する。
[スリープ中に第2マイコン361が実行する処理]
次に、図16を用いて、「スリープモード」中に第2マイコン361によって実行される、スリープ中BG通信処理について説明する。まず、ステップS21において、すれ違い通信処理が実行される。この処理は、上述したような第1割当期間(本実施形態では30秒)の間、「すれ違い通信」にかかるサーチ処理を繰り返し、可能であれば、他のゲーム装置10と「すれ違い通信」を実行するための処理である。図17は、当該すれ違い通信処理の詳細を示すフローチャートである。図17において、まず、ステップS41で、モード設定処理が実行される。この処理は、上述したような、「すれ違い通信」におけるクライアントモードとマスターモードの設定を行うための処理である。この処理において、ゲーム装置10が「クライアントモード」で動作するか「マスターモード」で動作するかが決定される。すなわち、このステップS41が繰り返し実行されることによって、クライアントモードで動作するかマスターモードで動作するかが繰り返し設定されることになる。
次に、ステップS42において、上記ステップS41の処理の結果、ゲーム装置10が「マスターモード」で動作することになったか否かが判定される。その結果、「マスターモード」での動作ではない、すなわち、「クライアントモード」で動作する場合は(ステップS42でNO)、ステップS43において、「クライアントモード」でのサーチ処理が実行される。すなわち、他のゲーム装置に対して接続要求を求める旨のビーコンを発信する処理が実行される。
次に、ステップS44で、上記発信したビーコンに対しての返答の有無が判定されることで、他のゲーム装置10を検出したか否かが判定される。その結果、他のゲーム装置10が検出されなかったときは(ステップS44でNO)、後述のステップS46に処理が進められる。一方、他のゲーム装置10が検出されたときは(ステップS44でYES)、無線通信モジュール36または第1マイコン37からの信号でCPU311のスリープ状態が一時的に解除され、ステップS45において、当該検出された他のゲーム装置10との間で接続が確立され、「すれ違い通信」が実行される。すなわち、「すれ違い通信」用データ505が参照され、アプリID5052が共通するスロットにかかるデータの送受信が実行される。その後、「すれ違い通信」にかかるデータ交換が終わると、再度CPU311がスリープ状態に移行する。
次に、ステップS46において、上記図5で示したような第1割当期間(本実施形態では、「すれ違い通信」用のサーチ処理の開始から30秒)が経過したか否かが判定される。その結果、経過していれば(ステップS46でYES)、すれ違い通信処理は終了する。一方、まだ経過していないときは(ステップS46でNO)、続くステップS47で、第2割当期間(本実施形態では、動作モードの設定が済んでから1秒)が経過したか否かが判定される。その結果、まだ経過していないときは(ステップS47でNO)、上記ステップS43に戻り、「クライアントモード」でのサーチ処理を繰り返す。一方、第2割当期間が経過していれば(ステップS47でYES)、上記ステップS41に戻り、モード設定処理からの処理が繰り返される。すなわち、クライアントモードで動作するかマス
ターモードで動作するかが再度設定される。
次に、上記ステップS42の判定の結果、ゲーム装置10が「マスターモード」で動作する場合は(ステップS42でYES)、ステップS48において、「マスターモード」でのサーチ処理が実行される。すなわち、クライアントモードで動作している他のゲーム装置10から送信されたビーコンの受信(待ち受け)が行われる。
次に、ステップS49において、他のゲーム装置10からのビーコンが(所定時間内に)受信できたか否かを判定することで、他のゲーム装置を検出したか否かが判定される。その結果、他のゲーム装置10が検出されなかったときは(ステップS49でNO)、後述のステップS51に処理が進められる。一方、他のゲーム装置10が検出されたときは(ステップS49でYES)、無線通信モジュール36または第1マイコン37からの信号でCPU311のスリープ状態が一時的に解除され、ステップS50において、上記ステップS45と同様に、当該検出された他のゲーム装置10との間で接続が確立されて「すれ違い通信」が実行される。その後、「すれ違い通信」にかかるデータ交換が終わると、再度CPU311がスリープ状態に移行する。
次に、ステップS51において、上記第1割当期間が経過したか否かが判定される。その結果、経過していれば(ステップS51でYES)、すれ違い通信処理は終了する。一方、まだ経過していないときは(ステップS51でNO)、続くステップS52で、上記第2割当期間が経過したか否かが判定される。その結果、まだ経過していないときは(ステップS52でNO)、上記ステップS48に戻り、「マスターモード」でのサーチ処理を繰り返す。一方、第2割当期間が経過していれば(ステップS52でYES)、上記ステップS41に戻り、モード設定処理から繰り返される。すなわち、クライアントモードで動作するかマスターモードで動作するかが再度設定される。以上で、すれ違い通信処理の説明は終了する。
図16に戻り、すれ違い通信処理が終われば、次に、「いつの間に通信」用のサーチ処理が行われる。具体的には、まず、ステップS22において、APの簡易サーチ処理が行われる。ここで行われるサーチ処理では、いわゆるパッシブスキャンによるAPのサーチが行われる。また、この処理の実行主体が第2マイコン361であることから、(CPU311による演算が必要となるような)複雑な処理を伴うサーチ処理を行うのではなく、比較的簡易な処理でのサーチ処理が行われる。
次に、ステップS23において、上記サーチ処理の結果、APが検出されたか否かが判定される。その結果、APが検出されなかったときは(ステップS23でNO)、上記ステップS21に戻り、処理が繰り返される。一方、APが検出されたときは(ステップS23でYES)、ステップS24において、APを検出した旨が第1マイコン37に対して通知される。(この通知は、上記図15のマイコン処理におけるステップS2の判定で用いられる)。その結果、第1マイコン37からの信号でCPU311のスリープ状態が一時的に解除され、後述する「いつの間に通信」処理が実行されることになる。この際、無線通信モジュール36のRAM362に格納されるプログラムが、当該スリープ中BG通信処理のプログラムから「インフラ通信」用のプログラムに置き換えられる。そのため、実質的に、ここで一旦スリープ中BG通信処理が終了することになる。その後、「いつの間に通信」が終わって再度CPU311がスリープ状態に移行する際に、無線通信モジュール36のRAM362に当該スリープ中BG通信処理のプログラムが格納され、上記ステップS21からの処理が繰り返されることになる。以上で、スリープ中BG通信処理の説明は終了する。
[通常電力モードにおいてCPU311が実行する処理]
次に、主に「通常電力モード」において、CPU311が実行主体となる処理について説明する。まず、「通常電力モード」においてバックグラウンド処理として実行される(常駐して動作する)管理処理について説明する。この処理は、CPU311が通電された際に最初に実行される処理でもある。
[管理処理]
図18は、当該管理処理の詳細を示すフローチャートである。まず、ステップS71において、第1マイコンからのスリープ解除命令を受けて「スリープモード」から復帰した直後の状態であるか否かが判定される。その結果、「スリープモード」から復帰した直後の状態であるときは(ステップS71でYES)、ステップS72において、スリープ解除処理が実行される。この処理は、「通常電力モード」でゲーム装置10が動作するように準備する処理である。例えば、「スリープモード」への移行に伴い中断されていたアプリケーション処理の再開等の処理が実行される。後述するような通常時BG通信処理の開始も指示される。一方、ステップS71の判定の結果、「スリープモード」からの復帰直後ではないときは(ステップS71でNO)、ステップS72の処理はスキップされる。
次に、ステップS73において、所定のアプリの起動指示が発行されたか否かが判定される。例えば、図示は省略するが、ゲーム装置10のホームメニューが表示されている状態において、所定のアプリを示すアイコンがユーザによって選択されたような場合、当該ホームメニューを制御するアプリから、選択されたアプリを起動するための指示が発行される。当該判定の結果、アプリの起動指示が発生したと判定されたときは(ステップS73でYES)、ステップS74において、起動指示がなされたアプリに対応付けられたアプリ用カウンタ507が生成され、メインメモリ32に格納される。そして、ステップS75において、当該起動指示がなされたアプリのプロセスが生成されることで、当該アプリが起動される。
一方、上記ステップS73の判定の結果、アプリの起動指示が発行されていないときは、上記ステップS74およびS75の処理はスキップされる。
次に、ステップS76において、現在実行中のアプリのいずれかから、アプリの終了通知(後述の図20のステップS122で通知される)が発行されたか否かが判定される。その結果、発行されていないときは(ステップS76でNO)、後述のステップS78に処理が進められる。一方、終了通知が発行されているときは(ステップS76でYES)、ステップS77において、当該通知を発行したアプリのプロセスを消去する処理が実行される。
次に、ステップS78において、現在実行中のアプリの数に応じてアプリ用カウンタ507の数を調整するための処理が実行される。具体的には、対応するアプリのプロセスが存在しないアプリ用カウンタ507の有無をチェックし、このようなアプリ用カウンタ507が残っているときは消去する処理が実行される。例えば、何らかの原因で強制終了、あるいは異常終了されたアプリが発生した際に、このアプリに対応したアプリ用カウンタ507が残ったままにならないようにするための処理である。また、消去すべきアプリ用カウンタ507がある場合は、更に、当該アプリ用カウンタ507の第1停止カウンタ508、および第2停止カウンタ509のそれぞれの値が1以上であるか否かのチェックが行われる。そして、値が1以上であるカウンタがあるときは、本体用カウンタ510の値を適宜減算する処理も行われる。具体的には、消去すべきアプリ用カウンタ507の第1停止カウンタ508の値が1以上であった場合は、第3停止カウンタ511の値から1が減算される。また、第2停止カウンタ509の値が1以上であった場合は、第4停止カウンタ512の値から1が減算される。また、消去すべきアプリ用カウンタ507が複数存在する場合は、各アプリカウンタ507毎に上記の判定がなされる。例えば、消去すべき
アプリ用カウンタ507が3つあり、このうち、第1停止カウンタ508の値が1以上であるアプリ用カウンタ507が2つあった場合は、第3停止カウンタ511から2が減算されることになる。
次に、ステップS79において、本体用カウンタ設定処理が実行される。この処理は、この時点でのアプリ用カウンタ507の状態をチェックし、その内容に応じて本体用カウンタ510を設定するための処理である。図19は、当該処理の詳細を示すフローチャートである。
まず、ステップS92において、システム用データ領域内のアプリ用カウンタ507の全てについて、次に説明する処理が行われたか否かが判定される。その結果、まだ未処理のアプリ用カウンタ507が残っているときは(ステップS92でNO)、ステップS93において、未処理のアプリ用カウンタ507の中からいずれか一つが選択される。以下では、選択されたアプリ用カウンタ507のことを処理対象アプリカウンタと呼ぶ。
次に、ステップS94において、処理対象アプリカウンタの第1停止カウンタ508の値が1以上であるか否かが判定される。すなわち、処理対象アプリカウンタに対応するアプリが、「すれ違い通信」にかかる処理の停止を指示しているか否かが判定される。当該判定の結果、第1停止カウンタ508の値が1以上のときは(ステップS94でYES)、ステップS95において、直前の処理ループにおいて、当該処理対象アプリカウンタの第1停止カウンタ508の値が0であったか否か(つまり、今回新たに停止指示が出されたのか、それ以前から停止指示が出されていたのか)が判定される。その結果、直前の値が0であったときは(ステップS95でYES)、今回新たに停止指示が出されたことになるから、ステップS96において、本体用カウンタ510の第3停止カウンタ511に1が加算される。一方、0ではなかったときは(ステップS95でNO)、それ以前から停止指示が出されていたことになるから、当該ステップS96の処理はスキップされる。一方、上記ステップS94の判定の結果、第1停止カウンタ508の値が1以上ではない、すなわち、0のときは(ステップS94でNO)、ステップS100において、直前の処理ループにおいて、当該処理対象アプリカウンタの第1停止カウンタ508の値が1以上であったか否か(つまり、今回新たに停止解除が出されたのか否か)が判定される。その結果、1以上であったときは(ステップS100でYES)、今回新たに停止解除が出されたことになるから、ステップS101において、第3停止カウンタ511から1が減算される(但し、上記図18のステップS78の処理において、アプリの強制終了などによる本体用カウンタ510の調整の結果、第3停止カウンタ511の値が既に0となっている場合は、この減算は行われない)。そして、後述のステップS97に処理が進められる。一方、第1停止カウンタ508の値が1以上ではなかったときは(ステップS100でNO)、それ以前から停止解除が出されていたことになるから、ステップS101の処理はスキップされる。
次に、ステップS97において、今度は処理対象アプリカウンタの第2停止カウンタ509の値が1以上であるか否かが判定される。すなわち、処理対象アプリカウンタに対応するアプリが、「いつの間に通信」にかかる処理の停止を指示しているか否かが判定される。当該判定の結果、第2停止カウンタ509の値が1以上のときは(ステップS97でYES)、ステップS98において、直前の処理ループにおいて、当該処理対象アプリカウンタの第2停止カウンタ509の値が0であったか否かが判定される。その結果、直前の値が0であったときは(ステップS98でYES)、ステップS99において、本体用カウンタ510の第4停止カウンタ512に1が加算される。そして、上記ステップS92に戻り、処理が繰り返される。一方、0ではなかったときは(ステップS98でNO)、ステップS99の処理はスキップされる。一方、上記ステップS97の判定の結果、第2停止カウンタ509の値が1以上ではない、すなわち、0のときは(ステップS97で
NO)、次に、ステップS102において、直前の処理ループにおいて、当該処理対象アプリカウンタの第2停止カウンタ509の値が1以上であったか否かが判定される。その結果、1以上であったときは(ステップS102でYES)、ステップS103において、第4停止カウンタ512から1が減算される(但し、上記ステップS78の処理において、第4停止カウンタ512の値が既に0となっている場合は、この減算は行われない)。そして、上記ステップS92に処理が戻される。一方、第2停止カウンタ509の値が1以上ではなかったときは(ステップS102でNO)、ステップS103の処理はスキップされて、ステップS92に戻る。
このような処理によって、アプリからの停止指示または停止解除指示を本体用カウンタ510の値に反映することができる。つまり、あるアプリから停止指示が出された場合、本体用カウンタ510の値が加算され、その後、この停止指示の解除が指示された場合、本体用カウンタ510の値が減算されることとなる。
一方、上記ステップS92の判定の結果、システム用データ領域内のアプリ用カウンタ507の全てについて上述のような処理が行われたと判定されたときは(ステップS92でYES)、本体用カウンタ設定処理は終了する。
図18に戻り、次に、ステップS80において、第1マイコン37から「スリープモード」への移行命令が発行された否かが判定される。その結果、発行されていなければ(ステップS80でNO)、上記ステップS73に戻り、処理が繰り返される。一方、発行されているときは(ステップS80でYES)、ステップS81において、スリープ状態移行処理が実行される。具体的には、まず、この時点で「すれ違い通信」、または、「いつの間に通信」の処理が行われていれば、この処理が中止される。更に、無線通信モジュール36のRAM362に、スリープ中BG通信処理プログラム5021がコピーされる。これにより、「スリープモード」中に無線通信モジュール36が上記図16で示したようなスリープ中BG通信処理の実行が可能となる。その結果、後述するような「すれ違い通信」や「いつの間に通信」の停止指示が所定のアプリから指示されていたとしても、「スリープモード」に移行すれば、アプリは中断されるので、これらの指示(カウンタの値)に関わりなく「すれ違い通信」や「いつの間に通信」は実行可能となる。また、その他、実行中のアプリを中断し、そのときのアプリの状態を保存する等、「スリープモード」へ移行するための各種処理も実行される。以上で、管理処理は終了する。
[アプリ処理]
次に、ユーザからの起動指示および上記管理処理によって起動されるアプリの処理について説明する。当該アプリ処理は、フォアグラウンドの処理としても実行され得るし、バックグラウンドの処理としても実行され得る。なお、各アプリケーションの具体的な処理内容は当然のことながらそれぞれ異なる。そのため、この点に関しての説明は省略し、本実施形態に関する部分、すなわち、上記アプリ用カウンタ507に関する処理を中心に、その最大公約数的な処理内容、すなわち、どのアプリケーションにおいても普遍的に行われると思われる処理として説明する。
図20は、アプリ処理の詳細を示すフローチャートである。まず、ステップS111において、当該アプリに対応するアプリ用カウンタ507の初期化が行われる。すなわち、第1停止カウンタ508および第2停止カウンタ509の値として0が設定される。
次に、ステップS112において、各アプリケーションの内容に応じた各種情報処理が実行される。例えば、ゲーム処理やお絵かきソフト処理、カメラアプリケーション処理等である。また、この処理において、「ローカル通信」に関する処理も適宜実行され得る。この際、「ローカル通信」の処理を開始する前に、以下に説明するような通信の停止指示
が発行される。そして、「すれ違い通信」、「いつの間に通信」にかかる処理が停止されたことが確認されてから、「ローカル通信」処理プログラム5023が無線通信モジュール36のRAM362にコピーされ、「ローカル通信」にかかる処理の実行が開始される。もちろん、「ローカル通信」を行う場合のみに限らず、処理負荷を軽減する目的で停止指示を発行してもよい。このような場合は、必ずしも通信の停止を確認するまでアプリ側で待機する必要はない。
次に、ステップS113において、上記の各種情報処理の結果、「すれ違い通信」の停止指示が発せられているか否かが判定される。ここで、本実施形態では、各アプリは、ある特定の機能を持ったプログラムの集合で構成されているとする。そして、当該停止指示は、アプリを構成する各プログラム単位で発行されるものとする。そのため、あるアプリを構成するプログラム群のうち、2つのプログラムから上記停止指示が発行されることもあり、このような場合は、停止指示が2つあることになる。
上記ステップS113の判定の結果、「すれ違い通信」の停止指示が1つ以上発行されていたときは(ステップS113でYES)、ステップS114において、発行された停止指示の数に応じて第1停止カウンタ508の値が加算される。一方、停止指示が発行されていないときは(ステップS113でNO)、ステップS114の処理はスキップされる。
次に、ステップS115において、上記ステップS112の各種情報処理の結果、「いつの間に通信」の停止指示の旨が発せられているか否かが判定される。この停止指示も、上記「すれ違い通信」の場合と同様に、アプリを構成する各プログラム単位で発行される。当該判定の結果、「いつの間に通信」の停止指示が1つ以上発行されていたときは(ステップS115でYES)、ステップS116において、発行された停止指示の数に応じて第2停止カウンタ509の値が加算される。一方、停止指示が発行されていないときは(ステップS115でNO)、ステップS116の処理はスキップされる。
次に、ステップS117において、上記ステップS112の各種情報処理の結果、「すれ違い通信」の停止解除指示が発せられているか否かが判定される。これは、例えば、あるプログラムが「すれ違い通信」の停止指示を発行した後、所定の処理が終了して、「すれ違い通信」を停止しておく必要がなくなったようなときに、当該プログラムから停止を解除する指示が発行される。当該判定の結果、「すれ違い通信」の停止解除指示が1つ以上発行されていたときは(ステップS117でYES)、ステップS118において、発行された解除指示の数に応じて第1停止カウンタ508の値が減算される。一方、解除指示が発行されていないときは(ステップS117でNO)、ステップS118の処理はスキップされる。
次に、ステップS119において、上記ステップS112の各種情報処理の結果、「いつの間に通信」の停止解除指示が発せられているか否かが判定される。当該判定の結果、「いつの間に通信」の停止解除指示が1つ以上発行されていたときは(ステップS119でYES)、ステップS120において、発行された解除指示の数に応じて第2停止カウンタ509の値が減算される。一方、解除指示が発行されていないときは(ステップS119でNO)、ステップS120の処理はスキップされる。
次に、ステップS121において、アプリ終了の指示が発行されたか否かが判定される。その結果、アプリ終了の指示が出されていないとき(ステップS121でNO)、上記ステップS112に戻り、処理が繰り返される。一方。アプリ終了の指示が出されていたときは(ステップS121でYES)、ステップS122において、アプリを終了する旨をシステムに通知する処理が実行される。この通知に応じて、システム側で当該アプリの
プロセスを消去する等の処理が適宜実行されることになる。以上で、アプリ処理は終了する。
[通常時BG通信処理]
次に、「通常電力モード」においてバックグラウンド処理として実行される、通常時BG通信処理について説明する。この処理は、「通常電力モード」において、「すれ違い通信」や「いつの間に通信」をバックグラウンドで実行するための処理である。
図21は、通常時BG通信処理の詳細を示すフローチャートである。まず、ステップS131において、本体用カウンタ510が参照され、第3停止カウンタ511の値が1以上であるか否かが判定される。つまり、「すれ違い通信」にかかる処理を停止させたいアプリが1以上あるか否かが判定される。当該判定の結果、1以上のときは(ステップS131でYES)、「すれ違い通信」の停止指示を出しているアプリが少なくとも1つは存在することになる。この場合は、次に、ステップS135において、直前の処理ループにおいて、第3停止カウンタ511の値が0であったか否かが判定される。その結果、直前の値が0であったときは(ステップS135でYES)、ステップS136において、「すれ違い通信」にかかる処理を停止するための処理が行われる。具体的には、無線通信モジュール36の第2マイコン361に対して、実行中の「すれ違い通信」処理の停止を指示する等の処理が行われる(この時点で「すれ違い通信」が実行中ではなければ、当該ステップS136の処理はスキップされてもよい)。その後、後述するステップS137に処理が進められる。
一方、上記ステップS131の判定の結果、第3停止カウンタ511の値が1以上ではない、すなわち、0であるときは(ステップS131でNO)、「すれ違い通信」にかかる処理を停止させたいアプリは存在しないことになる。この場合は、次に、ステップS132において、無線通信モジュール36のRAM362に「すれ違い通信」処理プログラム5022が格納されているか否かが判定される(例えば、第3停止カウンタ511が0であり、第4停止カウンタ512が1以上である場合、無線通信モジュール36のRAM362には「すれ違い通信」処理プログラム5022が格納されたままとなる)。その結果、格納されていないときは(ステップS132でNO)、ステップS133において、無線通信モジュール36のRAM362に「すれ違い通信」処理プログラム5022がコピーされる。一方、ステップS132の判定の結果、既に「すれ違い通信」処理プログラム5022が格納されているときは(ステップS132でYES)、上記ステップS133の処理はスキップされる。
次に、ステップS134において、「すれ違い通信」処理の実行指示が第2マイコン361に対して発行される。これに応じて、第2マイコン361は、「すれ違い通信」の処理を開始する(その結果、バックグラウンドで「すれ違い通信」が実行されることになる)。なお、この「すれ違い通信」の処理は上記図17を用いて説明した処理と同じであるため、説明は省略する。更に、当該すれ違い通信処理が開始されれば、その終了まで待機する処理も実行される。本実施例では、少なくとも30秒(第1割当期間)は待機することになる。
次に、ステップS137において、第4停止カウンタ512の値が1以上であるか否かが判定される。すなわち、「いつの間に通信」にかかる処理を停止させたいアプリが存在するか否かが判定される。その結果、1以上のときは(ステップS137でYES)、「いつの間に通信」の停止指示が発行されていることになる。この場合は、直前の処理ループにおいて、第4停止カウンタ512の値が0であったか否かが判定される。その結果、直前の値が0であったときは(ステップS138でYES)、ステップS139において、「いつの間に通信」にかかる処理を停止するための処理が行われる(この時点で「いつ
の間に通信」が行われていなければ、ステップS139の処理はスキップされてもよい)。その後、上記ステップS131に戻り、処理が繰り返される。
一方、ステップS137の判定の結果、第4停止カウンタ512の値が1以上ではない、すなわち0のときは(ステップS137でNO)、「いつの間に通信」にかかる処理を実行することになる。この場合は、まず、ステップS140において、無線通信モジュール36のRAM362に、インフラ通信用プログラム5024が格納されているか否かが判定される(例えば、第3停止カウンタ511が1以上であり、第4停止カウンタ512が0のままである場合、無線通信モジュール36のRAM362にはインフラ通信用プログラム5024が格納されたままとなる)。その結果、格納されていないときは(ステップS140でNO)、ステップS141において、無線通信モジュール36のRAM362にインフラ通信用プログラム5024がコピーされる。当該インフラ通信用プログラム5024は、無線通信モジュール36にインフラ通信機能を実現させるためのプログラムであり、例えば、TCP/IPプロトコルに基づいてAPやサーバと通信するためのプログラムである。当該プログラムにおける基本的な制御手法等については当業者には既知であるため、詳しい説明は省略する。一方、既に格納されている状態のときは(ステップS140でYES)、ステップS141の処理はスキップされる。
次に、ステップS142において、APをサーチする処理が実行される。この処理では、上記無線通信モジュール36で実行されるインフラ通信用プログラム5024と連携して、APをサーチする処理が行われる。なお、ここでのサーチ処理は、「スリープモード」において実行されるAPの簡易サーチ処理(上記図16のステップS22)よりも複雑な処理を行うことが可能である。具体的には、パッシブスキャンに加えて、いわゆるアクティブスキャンも適宜利用される。これは、例えば、SSIDステルス機能を利用したAPとの接続も可能とするためである。なお、必ずしもアクティブスキャンを併用する必要はなく、パッシブスキャンのみ利用するようにしても良い。
次に、ステップS143において、上記サーチの結果、APが検出されたか否かが判定される。その結果、APが検出されなかったときは(ステップS143でNO)、上記ステップS131に戻り、処理が繰り返される。一方、APが検出されたときは(ステップS143でYES)、ステップS144において、当該APとの接続を確立する処理が実行される。
次に、ステップS145において、「いつの間に通信」処理が実行される。この処理の詳細については後述する。
「いつの間に通信」処理が終われば、次に、ステップS146において、上記ステップS144で接続したAPと通信可能な状態が継続しているか否かが判定される。例えば、上記接続したAPから発せられるビーコンを(接続確立後も)定期的に検出する等で、通信可能な状態が継続しているか否か判定可能である。これにより、例えば、APの通信可能範囲外にゲーム装置10が移動したか否かが判定可能となる。その結果、まだ通信可能な状態であるときは(ステップS146でYES)、続くステップS147において、第4停止カウンタ512の値が1以上でないか否かが判定される。その結果、1以上ではないときは(ステップS147でNO)、上記ステップS145に戻り、処理が繰り返される。つまり、APとの接続が維持されたままの状態となる。一方、1以上のときは(ステップS147でYES)、上記ステップS131に戻り処理が繰り返される。その結果、(停止指示が出ていなければ)「すれ違い通信」にかかる処理が(無線通信モジュール36において)実行されることになる。これは、APとの接続が維持されていても、アプリから「いつの間に通信」の停止指示が出されることがあり得るため、この指示を反映させるための判定である。以上で、通常時BG通信処理の説明は終了する。
[いつの間に通信処理]
次に、上記ステップS141で示した「いつの間に通信」処理の詳細を説明する。図23は、当該「いつの間に通信」処理の詳細を示すフローチャートである。まず、ステップS151において、「スリープモード」中に本処理が呼び出されたのか否かが判定される。つまり、上記マイコン処理におけるステップS4の処理に応じて実行されたものであるか否かが判定される。当該判定の結果、「スリープモード」中に呼び出されていたときは(ステップS151でYES)、ステップS152において、無線通信モジュール36のRAM362にインフラ通信用プログラム5024がコピーされる。その結果、無線通信モジュール36は、インフラ通信機能を実現できる状態となる。
次に、ステップS153において、「スリープモード」中に検出されたAP(上記図16のステップS22の結果検出されたAP)との接続を確立する処理が実行される。そして、後述のステップS154に処理が進められる。
一方、ステップS151の判定の結果、「スリープモード」中の呼び出しではないときは(ステップS151でNO)、「通常電力モード」において呼び出されたことになるため、上記ステップS152および、S153の処理はスキップされる。
次に、ステップS154において、「いつの間に通信」用データ506が参照され、この時点で実行予定であるタスク(実行予定時刻が経過しているが未処理のものも含む)が抽出される。次に、ステップS155において、上記抽出された実行予定タスクの全てについて、以下に述べるような処理が行われたか否かが判定される。その結果、未処理のタスクが残っているときは(ステップS155でNO)、次のステップS156において、未処理のタスクの中からいずれか一つが、処理対象タスクとして選択される。
次に、ステップS157において、当該処理対象タスクのタスク内容定義データ5062が参照され、その定義内容に基づいて、所定のサーバとの間でデータの送受信等が行われる。
次に、ステップS158において、APと通信可能な状態が継続しているか否か(APの通信可能範囲外に移動していないか)が判定される。その結果、通信可能な状態が継続していれば(ステップS158でYES)、上記ステップS155に戻り、処理が繰り返される。
一方、ステップS158の判定の結果、通信可能な状態になっていないと判定されたとき(ステップS158でNO)、あるいは、上記ステップS155の判定の結果、実行予定のタスクを全て処理したと判定されたときは(ステップS155でYES)、ステップS159において、上記ステップS151と同様に、「スリープモード」中に本処理が呼び出されたのか否かが判定される。その結果、「スリープモード」中に呼び出されていたときは(ステップS159でYES)、再度「スリープモード」に戻るための処理が実行される。まず、ステップS160において、無線通信モジュール36のRAM362に、スリープ中BG通信処理プログラム5021がコピーされる。これにより、無線通信モジュール36は、上記図16で示したようなスリープ中BG通信処理を実行可能な状態となる。次に、ステップS161において、いつの間に通信が終了した旨の通知を第1マイコン37に送信する。その結果、第1マイコン37から「スリープモード」への移行命令がCPU311に発行されることになる(上記図15のステップS6の処理)。
一方、ステップS159の判定の結果、「スリープモード」中の呼び出しではないときは(ステップS159でNO)、「通常電力モード」における呼び出しとなるため、上記ステップS160およびS161の処理はスキップされ、「いつの間に通信」処理は終了
する。
このように、本実施形態では、「すれ違い通信」用のサーチと「いつの間に通信」用のサーチとの2種類のサーチをバックグラウンド処理で繰り返し実行している。そして、「すれ違い通信」用のサーチにおいて他のゲーム装置10が検出されたときは「すれ違い通信」を行い、「いつの間に通信」用のサーチにおいてAPが検出されたときは「いつの間に通信」を自動的に行うように構成している。更に、この2種類のサーチを所定の周期で自動的に切替ながら実行している。これにより、2種類の通信が自動的に行われ、ユーザに意識させることなく、多様な内容の通信を実行することができる。また、近距離の端末を対象とする通信と、サーバ等の(ネットワーク的な意味で)遠距離にある接続対象との通信という2種類の通信をシームレスに実行することができる。また、「すれ違い通信」用のサーチと「いつの間に通信」用のサーチを交互に行うよう構成しているため、両通信をある程度平均的に(まんべんなく)行われるようにすることができる。例えば、イベント会場等において、そこに存在するAPの数に比べて、他のゲーム装置10の数のほうが圧倒的に多いような場合に、「すれ違い通信」ばかりが偏って行われることを防ぎ、「いつの間に通信」もある程度実行されるようにすることができる。
また、サーチパターンについて、上記実施形態では、「スリープモード」においては、30秒の「すれ違い通信」用のサーチ期間を設け、その後1回の「いつの間に通信」用のサーチを行うようにしている。つまり、「すれ違い通信」のほうがより発生しやすいように設定している。一方、「通常電力モード」においては、一旦APに接続されると、当該APと通信ができない状態となるまでは、当該APとの接続状態が維持され、その間「すれ違い通信」は行われないような制御が行われている。つまり、「スリープモード」においては、「すれ違い通信」の発生を優先し、「通常電力モード」においては、「いつの間に通信」(更には、インフラ通信を用いた各種通信処理)の発生を優先している。これにより、ゲーム装置10の使用状態に応じたより適切な通信を実行させやすくすることが可能となる。
更に、「通常電力モード」においては、「すれ違い通信」「いつの間に通信」にかかるサーチ処理について、アプリから停止指示を出すことが可能なように構成している。これにより、アプリ側からの指示でバックグラウンドの通信を停止させ、実行されるアプリの処理内容に応じて適切な通信処理を実行することができる。更には、アプリ実行時の処理負荷を軽減させることも可能となり、より柔軟なアプリの開発環境を開発者に提供することができる。また、上記本体用カウンタ510を用いて、停止指示を出しているアプリの数を加算していくため、例えば、3つのアプリから停止指示が出されており、その後、いずれか1つが停止指示を解除したときであっても、すぐには通信の停止が解除されないようにすることができる。つまり、アプリ側の停止指示を優先して反映するように制御することができる。
上述した「すれ違い通信」に関して、上記の例では、30秒間(第1割当期間内)に複数回の「すれ違い通信」が発生することもある。この他、当該30秒の間に1回「すれ違い通信」が行われて完了すれば、30秒が経過していなくとも、「すれ違い通信」処理を終了して「いつの間通信」にかかるサーチに移行するようにしても良い。具体的には、上記図17のステップS45、およびS50の処理が行われれば、その後、「すれ違い通信」処理が終了するようにしてもよい。
また、上記実施形態では、「すれ違い通信」用のサーチを30秒行った後、1回の「いつの間に通信」用のサーチの行うというパターンを繰り返すサーチパターンを例に挙げた。このサーチパターン(2種類のサーチの切替条件)については、変更可能であってもよい。例えば、このサーチパターンを定義したデータを所定のサーバに用意する。そして、
上記「いつの間に通信」を利用して、当該サーバからサーチパターンの定義データを受信し、その内容に応じてゲーム装置10においてサーチパターンを変更するようにしても良い。
また、上記のように「すれ違い通信」用のサーチと「いつの間に通信」用のサーチを交互に行っているが、このとき、サーチで検出された接続対象が、前回に接続した対象と同じであれば、当該対象とは接続しないように制御しても良い。例えば、一旦「いつの間に通信」が行われ、次に「すれ違い通信」が行われたとする。その後、「いつの間に通信」用のサーチが行われた結果、検出されたAPが先ほど接続したAPと同じであれば、他のAPを検索したり、「いつの間に通信」の処理は行わずにすぐに「すれ違い通信」用のサーチに移行するようにしても良い。
また、サーチの処理に関して、上記実施形態では、「すれ違い通信」用のサーチと、「いつの間に通信」用のサーチを交互に行うパターンを例に挙げた。これに限らず、1回のサーチにおいて「すれ違い通信」用のサーチと「いつの間に通信」用のサーチがまとめて行われるように構成しても良い。例えば、上記「マスターモード」といわゆるパッシブスキャンとを併せ持ったような動作を行わせても良い。すなわち、ゲーム装置10がビーコンを待ち受けるサーチ動作において、「すれ違い通信」用のビーコンと、APから発信されたビーコンとのいずれも受信するように構成する。そして、受信したビーコンが「すれ違い通信」用のビーコンであるか、APから発信されたビーコンであるかを判別し、その判別結果に応じて、「すれ違い通信」処理、あるいは「いつの間に通信」処理のいずれかを適宜選択して実行するように構成しても良い。つまり、「すれ違い通信」用のサーチ、「いつの間に通信」用のサーチ、という区別を設けずに、受信したビーコンの種類に応じて実行する通信処理の内容を適宜変化させるようにしてもよい。
また、上記のように、受信したビーコンの種類に応じて実行する通信処理の内容を適宜変化させる場合は、待ち行列(キュー)の概念を利用し、例えば、一定の期間において受信できた複数のビーコンについて、そのビーコンの種類に応じた通信処理を順番に行うようにしても良い。例えば、1回のサーチで3つのビーコンが受信され、その内訳としては、「すれ違い通信」用のビーコンが2つ、APからのビーコンが1つであったとする。この場合は、受信した順に沿って、「すれ違い通信」と「いつの間に通信」を順に行うようにしてもいい。例えば、「すれ違い通信」→「すれ違い通信」→「いつの間に通信」というように、一度のサーチに対して3つの通信処理が実行されるようにしてもよい。また、受信した順の他、優先度に応じて実行順を決定しても良い。例えば、「すれ違い通信」が優先的に行われるよう制御したい場合は、「すれ違い通信」を優先的に実行された後、「いつの間に通信」が実行されるように優先順位を設定する。また、「いつの間に通信」が優先的に行われるよう制御したい場合は、「いつの間に通信」を先に実行した後に「すれ違い通信」が行われるよう優先順位を決定する。また、「すれ違い通信」と「いつの間に通信」が交互に実行されるように制御したい場合は、「すれ違い通信」と「いつの間に通信」が交互に実行されるように優先順位を決定するようにしてもよい。
また、上記「すれ違い通信」として行われるデータの送受信については、更に、上記インフラ通信を利用して行う形態を併用するようにしても良い。つまり、近くに他のゲーム装置10が存在する状況であれば、上記のような「すれ違い通信」を行うが、近くに他のゲーム装置10が存在しない状況であって、インフラ通信は可能な状況であれば、同様の状況にある他のゲーム装置10との間で、インフラ通信を利用して「すれ違い通信」用データ505の送受信が行われるようにしても良い。例えば、同じ地域にいるゲーム装置間で「すれ違い通信」用データ505の送受信が行われるようにしてもよい。つまり、ある程度近い位置に存在するゲーム装置10同士であれば、インフラ通信を利用して、上述したような「すれ違い通信」と同等の処理を行うことで、「すれ違い通信」を補完するよう
にしてもよい。これは、地域的な事情などで、ユーザの近くには他のゲーム装置10を所持しているユーザが少ないような状況で有用である。または、「通常電力モード」において通信可能範囲にAPが存在する場合には、APとの接続を維持して「すれ違い通信」用のサーチを行うことができないので、そのような状況においてもすれ違い通信を行うことができるようにするのに有用である。
また、アプリから発行されるバックグラウンド通信の停止指示に関して、上記実施形態では、いずれか1つのアプリから停止指示が出されていれば、これに応じたバックグラウンド通信を停止していた。この他、実行中のアプリの中でバックグラウンド通信の停止指示を出しているアプリの数が所定数以上のときに停止したり、多数決によって停止する否かを決定するようにしても良い。
また、上記アプリ用カウンタ507に関して、上記実施形態では、アプリを構成する各プログラム単位で発行される場合を例に挙げた。そのため、アプリ用カウンタ507に含まれる各値は2以上の値となることもあったが、これに限らず、例えば停止指示があるかないかを示すフラグとして扱うようにしてもよい。すなわち、アプリを構成する各プログラムのうち1つでも停止指示を発行していれば、「停止指示あり」とし、停止指示が1つも発行されてなければ「停止指示無し」とするフラグとして扱っても良い。
また、上記実施形態では、情報処理装置の一例として携帯型のゲーム装置を例に挙げて説明した。この他、携帯電話やPDA等の小型の携帯型情報端末にも本発明は適用可能であり、特に有用である。その他、いわゆるタブレット型の情報端末(タブレット端末やタブレットPC)、スレートPCやノートパソコンなどの、小型ではないが、鞄等を利用して携行することは可能な情報処理端末についても本発明は適用可能である。
また、上記実施形態においては、アプリからのバックグラウンド通信の停止指示に関する一連の処理が単一の装置(ゲーム装置10)において実行される場合を説明したが、他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。