以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。
(ゲーム装置の構成)
以下、本発明の実施形態にかかる情報処理装置の一例であるゲーム装置について説明する。ゲーム装置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つの撮像部(23aおよび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によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。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に接続する機能である。また、「アドホック通信」は、所定の通信方式(例えば独自プロトコルによる通信や、赤外線通信)により同種のゲーム装置との間で無線通信を行う機能である。詳細は後述するが、本実施形態では、主に「インフラ通信」を用いた「いつの間に通信」と呼ばれる通信機能を利用した処理を行う。
無線通信モジュール36には、第2マイコン361、RAM362等が含まれる。RAM362には、上記「インフラ通信」や「アドホック通信」のような無線通信を制御するためのプログラムが適宜格納される。そして、第2マイコン361は、RAM362に格納されているプログラムに基づき、上記「いつの間に通信」等を制御する。
加速度センサ39は、3軸(xyz軸)方向に沿った直線方向の加速度(直線加速度)の大きさを検出する。情報処理部31は、加速度センサ39が検出した加速度を示すデータ(加速度データ)を受信して、ゲーム装置10の姿勢や動きを検出することができる。
第1マイコン37は、ゲーム装置10の電源管理に関する処理や、時間に関する処理、上記ハウジングの開閉検知処理等を行う。また、これらの処理に関する通知をCPU311から受けたり、逆にCPU311に通知したりする。第1マイコン37は、リアルタイムクロック(RTC)371を備えている。RTC371は、時間をカウントし、第1マイコン37を介してCPU311に出力する。例えば、CPU311は、RTC371によって計時された時間に基づいて、現在時刻(日付)等を計算することもできる。
また、第1マイコン37は、開閉検出器46および電源回路40と接続される。開閉検出器46は、上記ハウジングの開閉を検出し、その内容を第1マイコン37(ひいてはCPU311)に通知する。電源回路40は、ゲーム装置10が有する電源(典型的には電池であり、下側ハウジング11に収納される)から供給される電力を制御し、ゲーム装置10の各部品に電力を供給する。また、電源回路40は、第1マイコン37(第1マイコン37を介したCPU311)からのスリープモードへの移行やスリープモード解除の通知を受ける。そして、当該通知に基づいて適切な電力を供給するための制御を行う。
ここで、本実施形態にかかるゲーム装置10の電源制御のモードに関して説明する。本ゲーム装置では、電池等の電源が装着されて、上記各構成部品への電力供給が可能な状態となった後は、基本的には、「通常電力モード」と「省電力モード」の2つの電源制御モードのいずれかで動作する。「通常電力モード」は、上記構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーション(以下、単にアプリと呼ぶ)を実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。本実施形態では、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、上記第1マイコン37、無線通信モジュール34にのみ電源を供給し、それ以外の部品、つまり、CPU311やLCDへの電力供給は停止している状態である(但し、CPU311は、「スリープモード」の解除指示を受けることは可能である)。また、「スリープモード」において、第1マイコン37や無線通信モジュール36(の第2マイコン361)は、「マイコン処理」、「スリープ中BG通信処理」と呼ばれる処理を所定時間毎に繰り返し実行する。これについては詳細は後述する。
また、本実施形態では、上述のような、開閉検出器46の検出結果に基づいてスリープモードへの移行やスリープモードの解除を行う方法のほかに、電源ボタン14Fの操作に応じて上記「通常電力モード」と「スリープモード」を切り替えることが可能である。また、電源ボタン14Fの操作によるものの他、後述するような処理によって、自動的に「スリープモード」の解除、あるいは「スリープモード」への移行も可能となっている。例えば、ユーザが所定のゲームをプレイし終えた後、電源ボタン14Fを押すと(この操作は、ユーザから見ると、電源をオフにする操作に見える)、「スリープモード」に移行する。この状態で、ユーザはゲーム装置10を閉じて、持ち歩くこと等が可能である。その後、ユーザがゲーム装置10を開き、再度電源ボタン14Fを押すと、「スリープモード」が解除され、「通常電力モード」に移行する。または、所定時間が経過したことにより「スリープモード」へ移行するようにしてもよい。
その他、電源ボタン14Fを長押しすることで、第1マイコン37や無線通信モジュール36も含めた全ての構成部品への電力供給を停止する(つまり、完全に電源を切る)「完全停止モード」に移行することも可能である。この場合は、再度電源ボタン14Fを長押しすると、「通常電力モード」に移行してゲーム装置10が起動することになる。
ここで、上記電源制御モードに関し、ユーザがゲーム装置を使用中か否かという観点からは、以下のように言い換えることもできる。すなわち、ゲーム装置10は、「使用状態」と「非使用状態」という2つの状態を有するといえる。「使用状態」とは、ユーザがゲーム装置10のハウジングを開いて直接的に使用しているために、通常電力モードがずっと継続している状態である。例えば、ユーザが操作ボタン14等を操作して実際にゲーム等をプレイしている状態が該当する。一方、「非使用状態」とは、ユーザがゲーム装置10を主導的・直接的に使用していない状態をいう。これには、上記ハウジングが閉じられているために「スリープモード」となっている状態の他、後述するような「いつの間に通信」の実行に伴い、(ハウジングは閉じられたまま)一時的に「スリープモード」が解除されて「いつの間に通信」にかかる処理が実行され、その実行後は再度「スリープモード」に戻るような状態も含む。例えば、ユーザが外出する際に、ゲーム装置10のハウジングを閉じて鞄に入れている状態は「非使用状態」である。更に、このように、ゲーム装置10が鞄に入れられてユーザが外出している間に、上記のように一時的に「スリープモード」が解除されている状態、および、「いつの間に通信」の実行後に再度「スリープモード」に入るような状態(この間、ユーザはゲーム装置10を使用していない)も「非使用状態」である。また、当該「使用状態」と「非使用状態」が切り替わるためのトリガは、ハウジングの開閉の他、電源ボタン14Fが操作された場合もトリガとなる。つまり、ユーザがゲームをプレイしていたが(使用状態)、その後、ゲームのプレイを終えたため、ゲーム装置10の電源ボタン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で再生する処理である。具体的には、本実施形態では、当該受信対象となる映像等は、テレビ局等の制作者が作成した「番組」および「広告」である。そして、本実施形態では、この「番組」のデータと「広告」のデータが個別に送受信される。つまり、サーバ側においては、「番組」と「広告」のデータが別々のファイルとして用意され、(ゲーム装置10の要求に応じて)個別に送信可能に構成されている。一方、ゲーム装置10では、当該「番組」を受信する処理と、「広告」を受信する処理が別々の処理として実行される。更に、本実施形態では、「いつの間に通信」と呼ばれる通信処理を主にバックグラウンド処理として実行することで、ユーザからの能動的な受信操作を伴うことなく、上記「番組」および「広告」のデータをバックグラウンドで自動的に受信する。
次に、本実施形態における上記「いつの間に通信」の処理概要について説明する。まず、当該「いつの間に通信」の具体的な動作例を説明する。ここでは、図4で示すようなネットワーク構成を想定する。すなわち、ゲーム装置10は、「インフラ通信」の機能を用いて(無線LANの)アクセスポイント(以下、APと呼ぶ)に接続する。そして、ゲーム装置10は、当該APを介してインターネットに接続し、所定のサーバとの通信を行う。本実施形態では、当該サーバから上記「番組」や「広告」のデータを受信する。また、ユーザの視聴履歴を示すデータを所定のサーバに送信する。
ここで、上記のように、「いつの間に通信」は基本的にバックグラウンド処理として実行される。これは、ゲーム装置10が「スリープモード」のときであっても、「通常電力モード」のときでも同様である。「いつの間に通信」の動作の典型的な例を挙げると、例えば、ユーザの自宅で「いつの間に通信」が行われる例が挙げられる。この場合、APは、ユーザの自宅に設置されたアクセスポイントとなる。そして、典型的には、ユーザがゲーム装置10を「スリープモード」(ゲーム装置10を折り畳んだ状態)にして就寝すると、就寝中に当該ゲーム装置10が自動的に「いつの間に通信」を実行し、「番組」や「広告」のデータを受信する。これにより、次の朝にユーザが目覚め、ゲーム装置10を「通常電力モード」に移行させると、新しい「番組」や「広告」が配信されており、当該「番組」や「広告」をゲーム装置10上で視聴することが可能となる。また、その他の例としては、自宅外の場所で「いつのまに通信」が行われる場合もある。この場合は、上記APは、所定の店舗(例えばファーストフード店等)に設置されているものである。そして、ユーザがゲーム装置10を「スリープモード」にして外出し、当該店舗に立ち寄った際に、ゲーム装置10が自動的に当該店舗のAPに接続し、「いつの間に通信」を実行する。つまり、ユーザが当該店舗に滞在している間に(この間、ゲーム装置は「スリープモード」であってもよいし、「通常電力モード」であってもよい)、ゲーム装置10は上記「番組」「広告」のデータを受信する。そして、ユーザが外出を終えて帰宅したとき、あるいは、例えば帰り道の電車の中等で、ゲーム装置10上で新たに受信した「番組」や「広告」を視聴することが可能となる。このように、本実施形態では、「いつの間に通信」を用いてユーザの知らない間に「番組」や「広告」のデータを受信可能となっている。そして、本実施形態では、「番組」のデータと「広告」のデータを別個のデータとして扱う(受信する)ことで、後述するような処理が可能となっている。
ここで、「いつの間に通信」における処理の管理単位である「タスク」の概念について説明する。本実施形態における「タスク」とは、所定のサーバとの間で所定のデータを送信または受信するための処理内容を定義した概念である。1つの「タスク」は、1つの送信処理、または、受信処理に対応する。そのため、本実施形態では、当該「タスク」を「送信タスク」と「受信タスク」の2種類の「タスク」として管理している。すなわち、1つの「タスク」には、「送信」または「受信」のいずれか一方の処理しか定義できない。そして、本実施形態では、「送信タスク」や「受信タスク」の実行スケジュール等を定義し、ゲーム装置10のシステムに「登録」することで、バックグラウンドでの実行を管理している。具体的には、「番組」を受信するための「受信タスク」(以下、「番組受信タスク」と呼ぶ)と「広告」を受信するための「受信タスク」(以下、「広告受信タスク」と呼ぶ)とを別々のタスクとして定義し(その実行スケジュール等も異なる)、登録している。ここで、本実施形態では、「番組」等の提供元として、テレビ局Aとテレビ局Bの2つの局を想定する。そして、各局毎に3つの「番組」を提供している場合を例とする。つまり、本実施形態では、2つのテレビ局から合計6つの「番組」が提供されるものとする。当該「番組」の具体例を挙げると、例えば、テレビ局Aの3つの番組の内訳として、数時間毎に更新される「ニュース」、1日単位で更新される「ドラマ」、1週間単位で更新される「情報バラエティ番組」等がある。一方、上記「番組受信タスク」については、1タスクが1つの番組に対応する。従って、本実施形態では、「番組受信タスク」は合計6つ登録されることになる。一方、「広告受信タスク」については、本実施形態では、2つの「受信タスク」が登録される。本実施形態では、「広告」の内容として、「CM広告」と「バナー広告」の2種類に分類されている。「CM広告」は動画データとして表される広告である。「バナー広告」は、静止画データとして表される広告である。そのため、「広告受信タスク」については、「CM広告」の「受信タスク」(以下、「CM広告受信タスク」)と「バナー広告」の「受信タスク」(以下、「バナー広告受信タスク」)の2つのタスクが登録される。また、本実施形態では、「CM広告受信タスク」の実行により受信されたCM広告のファイルの中には複数のCM広告のデータが含まれているとする。同様に、「バナー広告受信タスク」の実行により受信されたバナー広告のファイルの中には複数のバナー広告のデータが含まれているとする。
また、本実施形態では、上記のような「受信タスク」の他、「設定ファイル受信タスク」、「視聴履歴送信タスク」という「タスク」も登録され、実行される。「設定ファイル受信タスク」は、設定ファイルを受信するための「タスク」である。当該設定ファイルとは、「タスク」の実行スケジュール等を設定するためのファイルである。
詳細は後述するが、ゲーム装置10は、当該設定ファイルを参照して各「タスク」の実行スケジュール(実行優先度や実行時刻等)を変更することが可能となっている。また、「視聴履歴送信タスク」は、ユーザが視聴した番組や広告を示す履歴データを所定のサーバに送信するための「送信タスク」である。
更に、本実施形態では、「メーカー番組受信タスク」という「タスク」も登録される。これは、ゲーム装置10のメーカーが提供する「番組」(以下、メーカー番組)を受信するための「受信タスク」である。当該「メーカー番組」は、主にデモ映像やメーカーからの各種「お知らせ」を示す動画となっている。
なお、本実施形態においては、「タスク」は最大で99個まで登録することができ(本実施形態にかかる処理以外の処理、例えばゲーム処理で利用される「タスク」も存在する)、これ以上の「タスク」を登録した場合は、登録順の古いものから上書き登録される。
当該「タスク」として定義される主な内容としては、以下のようなものが含まれる。まず、タスクの実行スケジュールに関する情報が含まれる。これには「実行優先度」、「次回実行時刻」、「実行間隔」、「消尽回数」等の情報が含まれる。これらの情報は、「送信タスク」や「受信タスク」がいつ実行されるかや、どの程度の頻度で実行されるか、等を規定した内容となる。次に、送受信の対象となるデータについての情報(データの格納場所等)も含まれる。更に、通信相手となるサーバの情報(URL等)も含まれる。これらの情報は、後述するタスクデータ507として管理されるため、個々の情報の詳細については、タスクデータ507の説明のときに改めて説明する。
次に、上記のような「いつの間に通信」で受信した「番組」や「広告」を視聴するための視聴処理の概要について説明する。図5〜図8は、ゲーム装置10で実行される視聴アプリケーション(以下、視聴アプリと呼ぶ)の画面の一例である。当該視聴アプリケーションは、例えば、ゲーム装置10のホームメニュー(図示は省略)に対するユーザの操作に基づいて起動される。図5に示す画面例は、視聴アプリのメニュー画面である。この画面では、下側LCD12に、番組を示すアイコン101が6つ表示されている(番組アイコン101a〜101f)。また、下側LCD12には、その他、即時更新用のボタン102、広告一覧ボタン103、設定ボタン104も表示されている。また、現在選択中の番組やボタンを示すためのカーソル110も表示されている。ユーザは、当該下側LCD12に対して、例えば、カーソル110が合っている番組アイコン101のタッチ操作等を行うことで、各番組の再生や、各ボタンに対応した処理の実行を行うことができる。また、上側LCD22には、メニュー画面においては、下側LCD12で選択された番組アイコン101等の説明(番組内容の紹介など)が適宜表示される。
図5において、下側LCD12からユーザが所望の番組の再生指示を行うと、図6で示すような、番組再生画面に切り替わる。図6では、上側LCD22には、番組やCM広告の映像が表示される。一方、下側LCD12には、その上部に再生制御パネル121が表示され、その下にバナー広告画像122が表示され、更にその下に、メニューボタン123およびブラウザ起動ボタン124が表示される。上側LCD22で再生される動画は、再生制御パネル121(シークバーや再生/一時停止ボタン)を操作することで、再生の制御が可能である。
ここで、本実施形態では、上記のように、「番組」のデータと「広告」のデータは別々に受信される。一方、当該番組再生画面において番組が再生される際は、番組の途中でCM広告も適宜再生されるようにしている。これは、番組の再生が指示されたとき、受信済みのCM広告のファイルが参照され、原則として、ランダムにいくつかのCM広告が選択されて、上記番組の再生の途中(番組開始前と開始後も含む)でCM広告が再生されるような設定処理が実行される。これにより、番組の再生開始時に、番組内容とは関係なくランダムでCM広告が選択され、これらCM広告が番組の途中に適宜再生されることで、一般的なテレビ番組のような再生が可能となる。
なお、本実施形態では、当該視聴アプリの起動時に、未視聴の番組がある場合は、上記メニュー画面を表示せずに、当該未視聴の番組のいずれかの再生を開始する制御(未視聴番組の自動再生)も行う(つまり、視聴アプリを起動したとき、メニュー画面ではなく番組再生画面が表示される場合もある)。また、本実施形態では上記のように2つのテレビ局から番組を提供されているところ、未視聴番組の自動再生を行う際に、再生される番組が一方の局に偏らないように、両局の番組の再生機会が公平となるような制御も行われている。
次に、下側LCD12のバナー広告画像122の表示態様に関して説明する。当該バナー広告画像122は、上記「バナー広告受信タスク」で受信されたバナー広告のファイルに含まれる画像が表示されたものである。上記のように、「番組」のデータと「広告」のデータは別々に受信されるため、バナー広告画像についても、番組の再生指示がなされた際に、今回の再生において表示するバナー広告がランダムで選択され、上側LCD22における番組の再生中に適宜切り替わりながら下側LCD12に表示される(各バナー広告画像が表示される時間については各バナー広告のデータ自身に含まれている)。但し、上記CM広告の動画が上側LCD22で再生されているときについては、当該CM広告で紹介されている商品等に関連するバナー広告が表示される。つまり、CM広告と関連するバナー広告画像が表示される(例えば、A社の化粧品のCM広告が再生されていれば、当該CM広告が再生されている間は、当該化粧品が示されたバナー広告画像が下側LCD12に表示される)。以下、このような、CM広告と関連しているバナー広告のことを連動バナー広告と呼ぶ。
また、図6において、ブラウザ起動ボタン124は、ウェブブラウザを起動して、そのときに表示されているバナー広告画像に関連するサイト(広告主のサイトやショッピングサイト)を閲覧するためのボタンである。当該ボタンが押された場合、番組の再生は一時停止される。そして、当該視聴アプリはバックグラウンドの処理として切り替えられ(例えば待機状態となる)、ウェブブラウザにかかる処理がフォアグラウンドの処理として起動される。その後、ウェブブラウザにかかる処理が終了すれば、当該視聴アプリがフォアグラウンドの処理に切り替えられ、一時停止した箇所から番組の再生が再開される。
また、図6において、メニューボタン123は、当該番組再生画面を終了して上記図5のメニュー画面に戻るためのボタンである。
図5に戻り、次に、ユーザが下側LCD12から広告一覧ボタン103を押したときの処理概要について説明する。この場合、図7に示すような広告一覧画面が表示される。この画面は、上記「バナー広告受信タスク」で受信されたバナー広告のファイルに含まれる各バナー広告を閲覧するための画面である。上記のように、本実施形態では「番組」のデータと「広告」のデータが別々に受信されるため、このように広告のみを閲覧することも可能となっている。当該画面では、下側LCD12に、バナー広告のサムネイル画像131が一覧表示される。また、カーソル110も表示されている。アナログスティック15等を操作してユーザが所望のバナー広告画像にカーソル110を合わせると、上画面に、当該バナー広告に関する情報(広告内容の問い合わせ先や掲載期間等の書誌情報)が表示される。そして、ユーザが所望のバナー広告のサムネイル画像にカーソル110を合わせ、決定する操作を行うと、図8に示すような、バナー広告詳細画面が表示される。図8では、下側LCD12に、バナー広告の閲覧や再生を制御するための閲覧制御パネル141と、選択したバナー広告画像122が表示される。また、上側LCD22には、選択されたバナー広告画像に関連付けられているCM広告がある場合は、そのCM広告の映像が再生される。関連するCM広告がない場合は、当該バナー広告に関する情報が表示される。
また、下側LCD12には、戻るボタン142、ブラウザ起動ボタン143も表示されている。戻るボタン142は、上記広告一覧画面に戻るためのボタンである。ブラウザ起動ボタン143は、ウェブブラウザを起動して、そのときに表示されているバナー広告画像に関連するサイトを閲覧するためのボタンである。
図5に戻り、次に、ユーザが下側LCD12から設定ボタン104を押したときの処理について説明する。このときは、当該視聴アプリに関する設定を行うための画面が表示される(図示は省略)。ユーザはこの画面を用いて、視聴アプリの動作に関する各種設定操作を行うことができる。例えば、映像や広告の自動受信を行うか否か(つまり、上記「いつの間に通信」を実行するか否か)等を設定することが可能である。また、下側LCD12から即時更新用のボタン102をユーザがタッチすれば、最新の番組等が存在するかどうかの判定と、最新の番組等が存在する場合は、そのデータを受信する処理が実行される。この受信処理は、上記「番組受信タスク」および「広告受信タスク」の即時実行となる(つまり、バックグラウンド処理として受信処理が行われることになる)。
このように、本実施形態では、番組と広告のデータを別々に受信し、番組の再生時に、その番組と共に再生される広告をその都度決定している。そのため、ネットワークにかかる負荷を分散することができ、また、広告のみを閲覧するような処理も可能となる。
次に、ゲーム装置10において行われる「いつの間に通信」処理および視聴アプリケーション処理の詳細を説明する。なお、本実施形態における処理の実行主体に関して説明すると、本実施形態では、第1マイコン37、第2マイコン361、CPU311が、それぞれ独立して、以下に説明する処理の実行主体となり、これらの処理が互いに連携しながら並列的に実行される。まず、本実施形態にかかる各処理において用いられる主なデータについて説明する。
図9は、第1マイコン37に内蔵されている記憶領域(図示せず)に記憶される主なデータを示す図である。第1マイコン37の内部には、プログラム領域301とデータ領域303が存在し、プログラム領域301には、第1マイコン37が担当する処理を実行するためのマイコン処理プログラム302が記憶され、データ領域303には、給電状態フラグ304、次回起床時刻305が記憶される。給電状態フラグ304は、「スリープモード」であるか否かを示すためのフラグである。オンに設定されているときは「通常電力モード」、オフに設定されているときは、「スリープモード」であるとする。次回起床時刻305は、「スリープモード」を解除する時刻を示すデータである。
図10は、無線通信モジュール36に内蔵されているRAM362に記憶される主なデータを示す図である。RAM362には、プログラム領域401とデータ領域403が存在する。プログラム領域401には、通信制御プログラム402が格納される。当該プログラムは、主に上記インフラ通信にかかる処理を制御するためのプログラムである。また、APをサーチするための処理も当該プログラムによって実現される。また、データ領域403には、APに関する情報(SSID等)が含まれるAP識別情報404が記憶される。
図11は、ゲーム装置10のメインメモリ32のメモリマップを示す図である。図11において、メインメモリ32は、プログラム記憶領域501およびデータ記憶領域505を含む。プログラム記憶領域501およびデータ記憶領域505のデータは、データ保存用内部メモリ35、またはデータ保存用外部メモリ29に格納され、本実施形態にかかる処理の実行時に、必要に応じてメインメモリ32に転送されて記憶される。なお、本実施形態では、図11に示すプログラム、および、データのうち、視聴アプリプログラム503、視聴アプリ用データ509については、基本的にはデータ保存用外部メモリ29に保存されている。その他のプログラム、データについては、基本的にデータ保存用内部メモリ35に保存されている。
プログラム記憶領域501には、システム用プログラム502、視聴アプリプログラム503、ウェブブラウザアプリプログラム504が記憶される。システム用プログラムには、「いつの間に通信」処理を実行するためのプログラムやホームメニューを表示・制御するためのプログラム等、ゲーム装置10のシステムに関する各種プログラムが含まれている。視聴アプリプログラム503は、上述したような視聴アプリの実現するためのプログラムである。ウェブブラウザアプリプログラム504は、上記視聴アプリ等から呼び出されるウェブブラウザアプリを実行するためにプログラムである。
データ記憶領域505には、システム用データ506およびアプリ用データ508、操作データ511が含まれている。システム用データ506には、タスクデータ507等が含まれている。タスクデータ507は、上述した「タスク」の内容を定義するためのデータである。図12は、タスクデータ507のデータ構造の一例を示した図である。タスクデータ507には、複数のタスク設定531が格納される。各タスク設定531は、アプリID532、タスクID533、実行優先度534、通信先URL535、ファイルパス536、次回実行時刻537、実行間隔538、送信/受信識別フラグ539、消尽回数540、前回完了時刻541、タスク登録時刻542等から構成される。
アプリID532は、その「タスク」に関連するアプリケーションやゲーム(本実施形態では、視聴アプリ)を示すIDである。タスクID533は、当該タスクを識別するためのIDである。
実行優先度534は、当該「タスク」の実行優先度を示すデータである。本実施形態では、5段階の実行優先度が定義されている。具体的には、実行優先度の高い順に、"EXPEDITE"、"HIGH"、"MEDIUM"、"LOW"、"STOPPED"の5つが定義されている。そして、当該データには、これらの優先度のうちのいずれかを示す情報が格納される。
通信先URL535は、当該「タスク」の通信先(例えば、本実施形態では「番組」や「広告」のダウンロード元のサーバ等)を示す。
ファイルパス536は、「いつの間に通信」によって送信(アップロード)あるいは受信(ダウンロード)する各種ファイルのゲーム装置10内における保存場所を示すデータである。例えば、「送信タスク」の場合は、当該ファイルパス536で示されるメモリ上の場所に格納されているファイルを、上記通信先URL535で示されるサーバに送信することになる。また、「受信タスク」であれば、上記通信先URL535で示されるサーバから受信したデータ(本実施形態では「番組」や「広告」、「設定」のファイル)を、当該ファイルパス536で示されるメモリ上の場所に格納する。
次回実行時刻537は、当該タスクが次に実行されるべき時刻を示すデータである。実行間隔538は、当該タスクの実行間隔を示すデータである。例えば、3時間毎、4時間毎、1日毎、等を示すデータが格納される。上記次回実行時刻537の決定の際に、当該実行間隔538が用いられる。
送信/受信識別フラグ539は、その「タスク」が所定のデータを送信する「送信タスク」であるか、所定のデータを受信する「受信タスク」であるかを示すフラグである。例えば、当該フラグがオンに設定されていれば「受信タスク」であり、オフに設定されていれば「送信タスク」であることを示す。
消尽回数540は、当該タスクの消尽回数を示す。ここで、タスクの消尽回数について説明する。当該消尽回数は、いわば、タスクの実行可能回数を示すものである。本実施形態において、上記「タスク」が新規に生成・登録される際に、消尽回数540として所定の数値が初期値として設定される。そして、当該消尽回数540は、「タスク」が実行される毎に例えば1ずつ減算されていく。また、当該「タスク」に対応するアプリ等が起動される度に、消尽回数は初期値にリセットされる。そして、本実施形態では、消尽回数が0になった「タスク」は(換言すれば、このような「タスク」に対応するアプリやゲーム等が長期間実行されていないことを示すことになる)、上記実行優先度534の内容に関わらず実行されない、という制御が行われる(タスク自体は消去されずに存在する)。なお、本実施形態では、「番組受信タスク」の消尽回数に関しては、視聴アプリが起動されただけでは初期値にリセットはされず、対応する番組が視聴される度に初期値にリセットされるものとする。そのため、例えば、上記6つの番組のうち、ある1つの番組だけが一度も視聴されていない状態が続くと、当該番組の「受信タスク」の消尽回数は減っていく一方となり、最終的に、消尽回数が0となり、当該番組の「受信タスク」のみ実行されないという状況も起こり得る。
前回完了時刻541は、当該タスク設定531にかかる「タスク」が最後に実行されて正常に完了した時刻を示すデータである。タスク登録時刻542は、当該タスク設定531が一番最初に生成・登録された時刻を示すデータである。
図11に戻り、アプリ用データ508には、視聴アプリ用データ509、ウェブブラウザアプリ用データ510等、各種アプリやゲームで用いられるデータが含まれる。視聴アプリ用データ509は、上述したような視聴アプリで主に利用されるデータである。図13は、視聴アプリ用データ509のデータ構造の一例を示した図である。視聴アプリ用データ509は、番組パッケージ601a〜601f(以下、総称して番組パッケージ601と呼ぶこともある)、メーカー番組パッケージ602、バナー広告パッケージ603、CM広告パッケージ604、設定パッケージ605、視聴ログデータ606等から構成されている。番組パッケージ601は、上記テレビ局から配信される「番組」を示すファイルであり、1つの番組パッケージ601が1つの番組に対応する。
図14は、当該番組パッケージ601のデータ構造の一例を示す図である。各番組パッケージ601は、番組パッケージヘッダ631、番組メタデータ632、番組動画データ633を含む。番組パッケージヘッダ631には、当該番組パッケージを一意に識別するための情報や(本実施形態では、テレビ局提供の番組6つ+メーカー番組の計7つの「番組」があるため)、当該番組パッケージのバージョンを示す情報や、サムネイル用の画像データ等が含まれている。
番組メタデータ632は、当該番組の書誌的な情報、例えば、番組のタイトルや概要説明等の情報が含まれる。また、当該番組の再生有効期間についての情報も含まれる。例えば、ある番組について、当該再生有効期間として2011/6/1〜2011/6/30と定義されているような場合は、当該番組は、この期間の間だけ再生可能となる。
番組動画データ633は、当該番組の動画データである。例えば、H.264形式でエンコードされた動画データである。
図13に戻り、メーカー番組パッケージ602は、ゲーム装置10のメーカーが提供する「番組」を示すファイルである。その番組内容としては、例えば各種の「お知らせ」や「デモ映像」等がある。当該メーカー番組パッケージ602のデータ構造は、上記番組パッケージ601と同様であるため、その説明は省略する。
次に、バナー広告パッケージ603は、上記バナー広告画像が含まれるファイルである。図15は、当該バナー広告パッケージ603のデータ構造の一例を示す図である。バナー広告パッケージ603は、バナー広告パッケージヘッダ671と、複数のバナー広告ボディ672とで構成されている。バナー広告ボディ672のそれぞれが1つのバナー広告に対応している。つまり、バナー広告パッケージ603には複数のバナー広告が多重化されて格納されていることになる。バナー広告ボディ672は、バナー広告メタデータ673、バナー広告画像データ674で構成される。
バナー広告パッケージヘッダ671には、当該バナー広告パッケージ603のバージョンを示す情報や、当該バナー広告パッケージ603に含まれているバナー広告の数(つまり、バナー広告ボディ672の数)を示す情報が含まれる。更に、当該バナー広告パッケージ603内に含まれている各バナー広告ボディ672の位置を示すバナー広告インデックス情報も含まれている。当該情報を参照することで、当該バナー広告パッケージ603に含まれている各バナー広告ボディ672を検索することが可能となっている。
バナー広告メタデータ673には、当該バナー広告の書誌的な情報、例えば、当該バナー広告の画像サイズや、当該バナー広告と関連付けられたURL情報等が含まれている。例えば、上記図6のブラウザ起動ボタン124が押されたときに、当該URL情報が用いられる。更に、当該バナー広告を表示する時間(バナー再生時間)を示す情報も含まれている。例えば、この情報でバナー再生時間が5秒と定義されていれば、番組再生中において、当該バナー広告の画像が5秒間表示された後、別のバナー広告画像に切り替わる、と言う制御が行われることになる。
バナー広告画像データ674は、バナー広告の画像データであり、例えば、jpeg形式の静止画像データである。
図13に戻り、CM広告パッケージ604は、上記CM広告が含まれるファイルである。図16は、当該CM広告パッケージ604のデータ構造の一例を示す図である。CM広告パッケージ604は、CM広告パッケージヘッダ691と、複数のCM広告ボディ692と、連動バナー広告素材データ695で構成されている。また、CM広告ボディ692は、それぞれが1つのCM広告に対応している。つまり、上記バナー広告と同様に、複数のCM広告が多重化されて格納されている。
CM広告パッケージヘッダ691には、当該CM広告パッケージ604のバージョンを示す情報や、当該CM広告パッケージ604に含まれているCM広告の数を示す情報が含まれる。また、当該CM広告パッケージ604に含まれている連動バナー広告の数を示す情報も含まれる。更に、当該CM広告パッケージ604内に含まれている各CM広告ボディ692の位置を示すCM広告インデックス情報、および、各連動バナー広告ボディ672の位置を示す連動バナー広告インデックス情報も含まれている。これらのインデックス情報も、CM広告あるいは連動バナー広告を検索するために利用される。
CM広告ボディ692は、CM広告メタデータ693、CM広告動画データ694で構成される。CM広告メタデータ693には、当該CM広告の書誌的な情報、例えば、当該CM広告のタイトルや、当該CM広告に関連付けられている連動バナー広告の数や、当該連動バナー広告を特定するための情報等が含まれる。CM広告動画データ694は、CM広告の動画データである。
連動バナー広告素材データ695は、上記CM広告のいずれかに関連付けられた連動バナー広告のデータであり、複数の連動バナー広告のデータが含まれている。各連動バナー広告のデータ構造は、上述したバナー広告ボディ672と同様の構造である。
図13に戻り、設定パッケージ605は、本視聴アプリに関連する「タスク」、すなわち、上記「番組」、「広告」や、当該「設定(パッケージ)」自身を受信するための各「受信タスク」と、視聴ログを送信するための「送信タスク」の定義内容を規定したファイルである。例えば、テレビ局Aが番組の配信スケジュール(ゲーム装置10において当該番組を受信させる頻度)を変更したい場合は、当該設定パッケージ605に変更内容を示す情報が含まれて配信される。そして、これを受信した各ゲーム装置10において、当該設定パッケージ605が参照されて、該当する番組の「受信タスク」の実行スケジュールが変更されることで、番組の配信スケジュールを変更することが可能となる。
図17は、当該設定パッケージ605のデータ構造の一例を示す図である。設定パッケージ605は、設定パッケージバージョン情報641と、複数のタスク設定データ642とで構成されている。設定パッケージバージョン情報641は、当該設定パッケージ605のバージョンを示す情報である。例えば、以下に説明するタスク設定データ642の内容に変更が発生すれば、その都度、設定パッケージバージョン情報641の内容も変更され得る(例えばバージョン番号のカウントアップ等)。
タスク設定データ642は、視聴アプリで利用される各タスク(本実施形態では合計10個のタスク)の定義内容を示す情報である。各タスク設定データ642には、タスクバージョン情報651、タスク特定情報652、消尽回数653、実行優先度654、実行間隔655が含まれている。タスクバージョン情報651は、当該タスク設定データ642のバージョンを示す情報である。タスク特定情報652は、当該タスク設定データ642に対応する「タスク」を特定するための情報である。つまり、当該タスク設定データ642は、上記10個の「タスク」のどれに対応するか(適用されるか)を示す情報である。消尽回数653、実行優先度654、実行間隔655は、上述したタスク設定531(上記図12参照)の消尽回数540、実行優先度534、実行間隔538に設定される(適用される)データである。
図13に戻り、視聴ログデータ606は、ユーザが視聴した番組や広告に関するデータである。当該データは、「送信タスク」による送信対象として定義され、「いつの間に通信」によって適宜所定のサーバに送信される。視聴ログデータ606には、番組視聴データ607、CM視聴データ608、バナー視聴データ609が含まれている。番組視聴データ607は、ユーザが視聴した番組を示すデータであり、上記6つの番組のそれぞれに番組視聴データ607が用意される。CM視聴データ608は、ユーザが視聴したCM広告を示すデータであり、バナー視聴データ609は、ユーザが視聴したバナー広告を示すデータである。これら3つの視聴データのデータ構造は共通している。図18は、各視聴データのデータ構造を示す図である。各視聴データは、ユーザデータ611、最終再生日時612、再生量613、視聴番組ID614を含む。ユーザデータ611は、当該ゲーム装置10のユーザを示す情報である。これは例えば、ゲーム装置10本体内に保存されているユーザ情報や、視聴アプリの初回起動時に実行される「利用者情報登録」処理によって保存された情報が用いられる。最終再生日時612は、当該番組、または、CM広告、またはバナー広告が視聴された最新の日時を示すデータであり、分単位で記録される。再生量613は、番組やCM広告のような動画について、どこまで再生されたか(どこで再生が中断・中止されたか)を示す情報である。例えば、「最初〜1/3未満までの間」、「1/3〜2/3までの間」、「2/3〜最後までの間」のように、動画の再生時間を3つの期間に区切って、どこまで視聴されたかが示される。視聴番組ID614は、当該視聴された番組、CM広告、またはバナー広告を特定するための情報である。
その他、視聴アプリ用データ509には、視聴アプリの実行に必要な各種データが適宜含まれる。例えば、視聴アプリの動作に関する設定データ(上記図5で、下側LCD12に表示されている設定ボタン104をユーザが押したときの設定処理によって設定され得る)等が含まれる。
図11に戻り、ウェブブラウザアプリ用データ510は、ウェブブラウザアプリにおいて用いられる各種データが含まれている。
操作データ511には、操作ボタン14やアナログスティック15、タッチパネル13や加速度センサ39に対する入力状態を示すデータが含まれる。
その他、データ記憶領域505は、例えば、「いつの間に通信」において受信されるデータの一時的な保存場所等としても利用される。
次に、図19〜図28を参照して、ゲーム装置10によって実行される処理の詳細をフローチャートを用いて説明する。まず、上記「いつの間に通信」に関連する処理について説明し、その後、上記視聴アプリの処理の詳細を説明する。「いつの間に通信」に関連する処理は、第1マイコン37が実行する処理と、無線通信モジュール36が実行する処理と、CPU311が実行する処理とで構成される。「スリープモード」「通常電力モード」の切替制御にも関連するためである。
[第1マイコンが実行する処理]
まず、第1マイコン37が実行する処理について説明する。図19は、第1マイコン37によって実行されるマイコン処理を示すフローチャートである。図19で示される処理は、ゲーム装置10の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。
図19において、まず、ステップS1で、ゲーム装置10が上記「スリープモード」であるか否かが判定される。具体的には、上記給電状態フラグ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の「スリープモード」を解除して「通常電力モード」に移行させるための命令、ステップS5の判定、およびステップ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において、ゲーム装置10が開状態から閉状態に移行したか否か(つまり、ゲーム装置10が閉じられたか否か)が開閉検出器46からの信号により判定される。その結果、ゲーム装置10が開状態から閉状態に移行したと判定されたときは(ステップS9でYES)、次のステップS10において、「スリープモード」に移行させるための命令が第1マイコン37からCPU311に発行されるとともに、給電状態フラグ304をオフにし、かつ、電源回路40に、スリープに移行する旨が通知される。これに応じて、電源回路40は、適宜、ゲーム装置10の各構成部品への電力供給を停止する。一方、ステップS9の判定の結果、ゲーム装置10が開状態から閉状態に移行していないと判定されたときは(ステップS9でNO)、上記ステップS10の処理がスキップされて、マイコン処理は終了する。
[スリープモード時に第2マイコン361が実行する処理]
次に、図20を用いて、「スリープモード」中に第2マイコン361によって実行されるサーチ処理について説明する。まず、ステップS21において、APのサーチが行われる。ここで行われるサーチでは、いわゆるパッシブスキャンによるAPのサーチが行われる。
次に、ステップS23において、上記サーチ処理の結果、APが検出されたか否かが判定される。その結果、APが検出されなかったときは(ステップS23でNO)、上記ステップS41に戻り、処理が繰り返される。一方、APが検出されたときは(ステップS23でYES)、ステップS24において、APを検出した旨が第1マイコン37に対して通知される。(この通知は、上記図19のマイコン処理におけるステップS2の判定で用いられる)。その結果、第1マイコン37からの信号でCPU311のスリープ状態が一時的に解除され、後述する「いつの間に通信」処理が実行されることになる。その後、「いつの間に通信」が終わって再度CPU311がスリープ状態に移行する際に、無線通信モジュール36のRAM362に当該スリープ中BG通信処理のプログラムが格納され、上記ステップS21からの処理が繰り返されることになる。以上で、サーチ処理の説明は終了する。
[いつの間に通信処理]
次に、「いつの間に通信」処理の詳細を説明する。当該処理の主体はCPU311であり、「スリープモード」のときは、上記第1マイコン37の実行指示に基づき実行される。また、「通常電力モード」のときは、バックグラウンドの処理として所定の時間間隔で定期的に繰り返し実行される。従って、後述する視聴アプリや他のアプリが実行中であっても、原則として、そのバックグラウンドで当該「いつの間に通信」(による番組等の受信)は実行され得る。
図21は、当該「いつの間に通信」処理の詳細を示すフローチャートである。まず、ステップS41において、「スリープモード」中に本処理が呼び出されたのか否かが判定される。つまり、上記マイコン処理におけるステップS4の処理に応じて実行されたものであるか否かが判定される。当該判定の結果、「スリープモード」中に呼び出されていたときは(ステップS41でYES)、ステップS42において、「スリープモード」中に検出されたAPとの接続を確立する処理が実行される。そして、後述のステップS43に処理が進められる。一方、ステップS41の判定の結果、「スリープモード」中の呼び出しではないときは(ステップS41でNO)、上記ステップS42の処理はスキップされる。なお、この場合は、「通常電力モード」において本処理が呼び出されたことになるが、このとき、APとの接続が確立していなければ、図示は省略するが、APのサーチ処理とその接続確立処理が適宜実行されてから、次のステップS43に処理が進められる。
次に、ステップS43において、タスクデータ507が参照され、この時点で実行予定である「タスク」(実行予定時刻が経過しているが未処理のものも含む)が抽出される。なお、当該抽出された「タスク」には、上記視聴アプリに関連する「タスク」の他、他のアプリに関連する「タスク」も含まれ得る。
次に、ステップS44において、上記抽出された実行予定タスクの全てについて、以下に述べるような処理が行われたか否かが判定される。その結果、未処理のタスクが残っているときは(ステップS44でNO)、次のステップS45において、未処理のタスクの中からいずれか一つが、処理対象タスクとして選択される。
次に、ステップS46において、当該処理対象タスクに対応するタスクデータ507が参照され、その定義内容に基づいて、所定のサーバとの間でデータの送受信等が行われる。例えば、当該タスクが上記「番組受信タスク」であれば、当該タスクにかかる番組パッケージ601(上記6つの番組のうちのいずれか1つ)の受信処理が行われる。また、「視聴ログ送信タスク」であれば、上記視聴ログデータ606を所定のサーバに送信する処理が実行される。
次に、ステップS47において、ゲーム装置10とAPとが通信可能な状態が継続しているか否か(ゲーム装置10がAPの通信可能範囲外に移動していないか)が判定される。その結果、通信可能な状態が継続していれば(ステップS47でYES)、上記ステップS44に戻り、処理が繰り返される。
一方、ステップS47の判定の結果、通信可能な状態になっていないと判定されたとき(ステップS47でNO)、あるいは、上記ステップS44の判定の結果、実行予定のタスクを全て処理したと判定されたときは(ステップS44でYES)、ステップS48において、上記ステップS41と同様に、「スリープモード」中に本処理が呼び出されたのか否かが判定される。その結果、「スリープモード」中に呼び出されていたときは(ステップS48でYES)、再度「スリープモード」に戻るための処理が実行される。すなわち、ステップS49において、いつの間に通信が終了した旨の通知が第1マイコン37に送信される。その結果、第1マイコン37から「スリープモード」への移行命令がCPU311に発行されることになる。
一方、ステップS48の判定の結果、「スリープモード」中の呼び出しではないときは(ステップS48でNO)、「通常電力モード」における呼び出しとなるため、上記ステップS49の処理はスキップされ、「いつの間に通信」処理は終了する。
[視聴アプリケーション処理]
次に、視聴アプリ処理の詳細について説明する。当該処理は、上述したように、ホームメニューに対するユーザの起動指示(例えば、当該視聴アプリを示すアイコンをタッチする等)に応じて、その実行が開始される。
図22は、視聴アプリ処理の詳細を示すフローチャートである。当該処理の実行が開始されると、まず、ステップS101において、当該視聴アプリの起動が(当該アプリがゲーム装置10にインストールされてから)初めての起動(初回起動)であるか否かが判定される。その結果、初回起動でないときは(ステップS101でNO)、後述するステップS104に処理が進められる。一方、初回起動のときは(ステップS101でYES)、ステップS102において、初回起動時設定処理が実行される。これは、当該視聴アプリの実行環境をゲーム装置10内に構築するための処理である。
図23は、上記ステップS102で示した初回起動時設定処理の詳細を示すフローチャートである。図23において、まず、ステップS121で、視聴アプリで利用されるデータ、すなわち、上述した「番組」や「広告」、「設定」のファイルを記憶するための記憶領域を確保する処理が実行される。本実施形態では、上述のようにこれらのデータはデータ保存用外部メモリ29上に記憶されるものとする。従って、この処理では、データ保存用外部メモリ29上に、上記図13で示したような各種ファイルを記憶するための領域が確保される。
次に、ステップS122において、設定パッケージ605を受信するためのタスクである「設定ファイル受信タスク」を作成してシステムに登録する処理が実行される。なお、この時点における当該「設定ファイル受信タスク」の内容(実行優先度等)については、初期値として予め定義されている内容が用いられる。
次に、ステップS123において、利用者情報登録処理が実行される。この処理では、各種の設定入力画面を表示し、これに対するユーザの入力に基づき、「視聴者」であるユーザに関する情報を設定する処理が実行される。当該情報としては、例えば、ユーザの生年月日や性別がある。ここで設定された情報は、利用者情報(図示は省略)として、視聴アプリ用データ509の一部として適宜保存される。
利用者情報登録処理が終われば、次に、ステップS124で、「設定ファイル受信タスク」以外のタスクの登録が実行される。すなわち、「番組受信タスク」(6つのテレビ番組分+メーカー番組分の計7つの「タスク」)、「CM広告受信タスク」、「バナー広告受信タスク」、および「視聴履歴送信タスク」が生成されて登録される。なお、この時点ではまだ最新の設定パッケージ605が受信されていないため(上記ステップS122の処理は「受信タスク」を登録しただけであり、まだ受信そのものは行われていない)、実行優先度等の情報には、予め初期値が設定されている設定パッケージ605を用いて各「タスク」の内容が定義される。本実施形態では、初期値として、以下の内容が定義されているとする。実行優先度534としては、全受信タスク共に"LOW"であり、実行間隔538については、「番組受信タスク」は4時間、「広告受信タスク」については3時間、「設定ファイル受信タスク」および「メーカー番組受信タスク」は24時間と定義されているものとする。消尽回数540については、例えば、「番組受信タスク」は”50”、「広告受信タスク」は”80”、「設定ファイル受信タスク」および「メーカー番組受信タスク」は”100”と定義されているものとする。そして、当該処理が実行されることにより、この時点では、合計10のタスク(「受信タスク」×9、「送信タスク」×1)が登録されたことになる。以上で、初回起動時設定処理は終了する。
図22に戻り、次に、ステップS103において、上記初回起動時設定処理で登録された「受信タスク」の即時実行が行われる。つまり、初回起動の時点で、一旦、各種「番組」や「広告」の受信が試みられることになる。その結果、通信可能なAPが近くに存在していれば、「番組」や「広告」が取得される。通信ができない状況であれば、その旨のメッセージが適宜表示される。ここでは、当該処理の実行によって「番組」や「広告」が受信されたものとして説明を続ける。
次に、ステップS104において、タスクスケジューリング処理が実行される。この処理では、設定パッケージ605が更新されたような場合(つまり、各「番組」や「広告」の受信頻度等が変更された場合)に、その内容を反映して各「受信タスク」を更新する処理等が実行される。
図24は、上記ステップS104で示したタスクスケジューリング処理の詳細を示すフローチャートである。図24において、まず、ステップS141で、「設定ファイル受信タスク」が存在しているか否か(システムに登録されているか否か)が判定される。これは、本実施形態では、「タスク」の最大登録数が99個であることから、以前に一旦登録された「設定ファイル受信タスク」が、この個数制限によって消去される場合があり得ることから(99個以上「タスク」が登録される場合、古い順に消去されるため)、「設定ファイル受信タスク」の存在を確認するものである。当該判定の結果、存在していないときは(ステップS141でNO)、ステップS142において、「設定ファイル受信タスク」の登録が実行される。一方、存在していれば(ステップS141でYES)、ステップS142の処理はスキップされる。
次に、ステップS143において、「番組受信タスク」(計6個)、「メーカー番組受信タスク」」「CM広告受信タスク」、「バナー広告受信タスク」の全てが存在しているか否かが判定される。当該判定の結果、全てが存在しているときは(ステップS143でYES)、次に、ステップS144において、設定パッケージ605に(前回受信時から)更新が発生しているか否かが判定される。その結果、更新が発生しているときは(ステップS144でYES)、ステップS145において、(更新された)設定パッケージ605が参照され、各「受信タスク」の設定内容が取得される。続くステップS146において、当該取得された内容に基づいて、各「受信タスク」の設定内容が更新される。一方、更新が発生していないとき(つまり、前回に受信した内容と同じ場合)は、当該ステップS145およびS146の処理はスキップされる(各「受信タスク」の内容は更新されない)。そして、当該タスクスケジューリング処理は終了する。
一方、上記ステップS143の判定の結果、「番組受信タスク」(計6個)、「メーカー番組受信タスク」」「CM広告受信タスク」、「バナー広告受信タスク」のうち、欠けている「タスク」が1つでもあったときは(ステップS143でNO)、ステップS147において、設定パッケージ605に更新が発生しているか否かが判定される。その結果、更新が発生していれば(ステップS147でYES)、上記ステップS145に処理が進められ、更新後の設定パッケージ605の内容を「受信タスク」に反映し、存在しない「タスク」については登録するための処理が実行される。
一方、ステップS147の判定の結果、更新が発生していないときは(ステップS147でNO)、次に、ステップS148において、上記6つの番組のうち、所定期間以上視聴されていない番組があるか否かが判定される。例えば、1週間以上視聴されていない番組があるか否かが判定される。これは、例えば、次のような処理が各番組毎に対して行われることで各番組単位で判定される。まず、視聴ログデータ606が参照されて、最終再生日時612が取得される。次に、番組メタデータ632に含まれている再生開始日(その番組が配信された日)が取得される。そして、これらのうち新しいほうの日時が現在日時の一週間以上前であるか否かが判定される。その結果、一週間以上前であれば、当該番組については一週間以上視聴されていないと判断できる。
上記ステップS148の判定の結果、所定期間以上視聴されていない番組があるときは(ステップS148でYES)、ステップS149において、当該視聴されてない番組に対応する「番組受信タスク」の消尽回数に”1”が設定される。そして、ステップS150において、当該所定期間以上視聴されていない番組についての「番組受信タスク」が更新される。これは、以下のような目的で行われる。まず、ある番組について、長期間視聴されていないにもかかわらず、受信タスクのみが定期的に実行されると、消尽回数が”0”となり、受信タスクが実行されなくなった番組となる。このような番組は、ユーザが興味のない番組であると考えられる(例えば、ニュース番組だけ見ないユーザ等)。その結果、上記図5で示したメニュー画面では、当該番組についてはずっと同じサムネイルが表示され続けることになる。その一方で、例えば、当該番組の内容をテレビ局がリニューアルし、以前はニュース番組であったものが、ドラマの番組に変更された場合を想定する。このような場合、当該番組の受信タスクは、(設定パッケージの更新がない限りは)実行されないため、番組内容が変わったことをユーザに気付かせることができない。そこで、このような場合に、消尽回数を”1”にすることで、一度は番組の受信を実行することで、メニュー画面のサムネイル画像も変更され、その結果、ユーザにこのような変更を気付かせ、ひいては当該番組の視聴を促すということを目的とする。もちろん、このような番組が変更された場合に限らず、単に長い間視聴されてない番組がある場合に、一度番組の受信を実行して、メニュー画面のサムネイル画像の変更等によって、ユーザにその番組の視聴を促すという目的もある。
一方、上記ステップS148の判定の結果、所定期間以上視聴されていない番組がなければ(ステップS148でNO)、当該タスクスケジューリング処理は終了する。
図22に戻り、タスクスケジューリング処理が終われば、次に、ステップS105において、メイン処理が実行される。図25は、当該メイン処理の詳細を示すフローチャートである。図25において、まず、ステップS161で、上記図5で示したようなメニュー画面を準備するための準備処理が実行される。このステップS161の処理をより具体的に説明すると、まず、番組パッケージ601、バナー広告パッケージ603、CM広告パッケージ604が参照され、それぞれに含まれている各番組あるいは広告のメタデータが取得される。更に、各メタデータから番組等のサムネイル画像が取得され、これを元に番組アイコン101が生成されて、これらアイコンが配置されたメニュー画面の生成が行われる。この際、下側LCD12に配置される番組アイコン101の並び順に関し、各番組を提供しているテレビ局間で不公平感が生じないようにするため、以下のような処理が実行される。まず、当該視聴アプリが起動された時刻が取得される。当該時刻は、システムにおいて、「時:分:秒」の形式で記録されているものとする。そして、当該時刻の”秒”の下一桁の値が”4”以下であるか否かが判定される。その結果、”4”以下であれば、テレビ局Aの提供番組が先頭になるようにして、テレビ局Aの提供番組とテレビ局Bの提供番組とが交互に並ぶように番組アイコン101が配置される(なお、メニューが最初に表示される際、当該先頭の番組アイコン101にカーソル110が合った状態で表示される)。一方、”4”以下ではないときは、逆に、テレビ局Bの提供番組が先頭に配置されるようにして、両局の番組が交互に並ぶように配置される。つまり、視聴アプリの起動時刻の下一桁が0〜4の場合と5〜9の場合とで、メニュー画面の先頭にくる番組アイコン101にかかるテレビ局を変えている。これは、番組アイコン101の並び順に関して、両局の間で不公平感が生じないようにするためである。
次に、ステップS162において、未視聴番組が1つ以上あるか否かが判定される。これは、例えば視聴ログデータ606が参照されることで判定される、その結果、未視聴番組があるときは(ステップS162でYES)、ステップS163において、未視聴番組の中からいすれか一つ(未視聴番組が1つしかないときは、その番組)が選択される。なお、この選択の処理についても、テレビ局間で不公平感が生じないようにするため、起動時刻の下一桁の値に応じて、いずれかのテレビ局の番組から選択される。またこのとき、配信日時が古いものから優先的に選択されるように制御しても良い。このようにして、未視聴番組のいずれかが選択されれば、後述のステップS167の処理に進み、当該未視聴番組の再生が開始される(つまり、未視聴番組が自動的に再生開始されることになる)。
一方、ステップS162の判定の結果、未視聴番組がないときは(ステップS162でNO)、ステップS164において、上記ステップS161で生成されたメニュー画面が下側LCD12に表示される。また、上側LCD22には、カーソル110が合っている番組アイコン101の番組説明が表示される(当該番組説明は、番組のメタデータから取得される)。
次に、ステップS165において、操作データ511が取得される。次に、ステップS166において、当該操作データ511に基づいて、番組の再生指示がユーザによって行われたか否かが判定される。その結果、番組の再生指示が行われていたときは(ステップS166でYES)、ステップS167において、再生指示がなされた番組(以下、再生対象番組)を再生するための番組再生処理が実行される。図26は、当該番組再生処理の詳細を示すフローチャートである。まず、ステップS191において、再生対象番組の再生にあたって、合わせて再生するCM広告を選択する処理が実行される。更に、再生対象番組の再生中における当該選択されたCM広告の再生位置(CM広告の再生スケジュール)についても決定される。CM広告の選択については、基本的にはランダムに選択されるが、その中でも未視聴のCM広告が優先的に選択されるような選択制御も併せて行われる。例えば、未視聴のCM広告の中からランダムに選択されるというような選択制御が行われる。再生位置の決定については、本実施形態では、「番組開始前」「番組終了後」「番組途中」の3種類の再生位置から選択されるものとする。また、「番組途中」の場合は、その再生開始位置(CM広告が挿入される位置)が番組動画のフレーム番号で指定されるものとする(例えば、先頭からnフレーム目、等)。例えば、あるCM広告の開始位置として、番組開始から30秒の位置にあるフレーム番号が指定されていれば、番組開始から30秒分のフレームが再生されたあと、一旦番組動画の再生が一時停止され、代わりに当該CM広告の動画が再生される。そして、CM動画の再生が終われば、当該番組の31秒目のフレームからの再生が再開されることになる。
なお、CM広告の選択に関して、他の実施形態においては、上記のような未視聴のものを優先するような制御は行わずに、視聴済み、未視聴に関わらずランダムに選択されるようにしても良い。
次に、ステップS192において、番組再生中に下側LCD12に表示するバナー広告の選択と、その表示順(バナー広告の再生スケジュール)の決定が行われる。当該選択についても、上記CM広告と同様、基本的にはランダム選択されながらも、未視聴のバナー広告は優先的に選択される(他の実施形態においては、完全にランダムで選択されるようにしても良い)。なお、各バナー広告の表示時間(バナー再生時間)については、上記のように各バナー広告のバナー広告メタデータ673で指定されている。上記のような処理で決定されたCM広告およびバナー広告の再生スケジュールを示すデータ(以下、再生スケジュールデータ)は、一時的なデータとしてメインメモリ32上に適宜格納される。
次に、ステップS193において、上記図6で示したような番組再生画面が生成される。すなわち、再生制御パネル121やバナー広告画像122等が配置された画面が生成される。
次に、ステップS194において、上側LCD22において、上記再生スケジュールデータに基づく番組の再生が開始される。また、下側LCD12に上記ステップS193で生成された画面を表示する処理も実行される。
なお、本実施形態では、バックグラウンドで上記「番組受信タスク」等、当該視聴アプリに関する「タスク」に基づく通信が行われている最中に、当該番組の再生指示が行われる可能性もある。つまり、更新前の番組の再生を、更新後の番組の受信が同じタイミングで起こり得る可能性がある。このような場合、本実施形態では、上記「番組」の再生中は、上記「いつの間に通信」の実行の停止の旨をシステムに通知する。これに応じて、ゲーム装置10のシステムは、「いつの間に通信」にかかる処理の実行を一時的に抑制する。そして、番組の再生処理が終了すれば、「いつの間に通信」にかかる処理の実行を再開するような制御が行われる。但し、他の実施形態においては、「いつの間に通信」の実行は抑制せずに、番組の再生処理とバックグラウンドでの番組等の受信処理が並列で実行されるようにしてもよい。
次に、ステップS195において、操作データ511が取得される。続くステップS196において、当該操作データ511に基づき、再生制御の操作(再生制御パネル121に対する操作)が行われたか否かが判定される。その結果、再生制御の操作が行われたときは(ステップS196でYES)、ステップS197において、当該操作内容に応じた、番組動画やCM広告の再生制御処理が実行される(早送りや一時停止等)。一方、再生制御の操作は行われていないときは(ステップS196でNO)、上記ステップS197の処理はスキップされる。
次に、ステップS198において、上記操作データ511に基づいて、ウェブブラウザアプリの起動指示(例えば、ブラウザ起動ボタン124のタッチ操作等)が行われたか否かが判定される。その結果、行われていれば(ステップS198でYES)、ステップS199において、番組動画の再生が一時停止される。次に、ステップS200において、当該視聴アプリをバックグラウンド処理とし、ウェブブラウザアプリを起動する制御を行う旨を視聴アプリからシステムに通知する処理が実行される。この際、上記ブラウザ起動指示がなされたときに表示されていたバナー広告に関連するURL情報についても併せてシステムに通知される。これに応じて、ゲーム装置10のシステムは、視聴アプリをバックグラウンド処理に切替え、ウェブブラウザアプリを起動する。その結果、ステップS201で、ウェブブラウザ処理が実行される。ウェブブラウザアプリは、上記バナー広告に関連するURL情報で示されるサイトを表示し、ユーザの操作に基づく各種処理を実行する。
ウェブブラウザアプリの処理が終了すれば、システムが、視聴アプリをバックグラウンド処理からフォアグラウンド処理に切り替える。これに応じて、視聴アプリの画面が表示され、ステップS202において、再生を一時停止された位置から番組の再生が再開される。そして、上記ステップS195に戻って処理が繰り返される。
一方、上記ステップS198の判定の結果、ブラウザ起動指示がおこなわれていないときは(ステップS198でNO)、次に、ステップS203において、メニュー画面に戻る旨の指示が行われたか否かが判定される。その結果、メニュー画面に戻る指示が行われていないときは(ステップS203でNO)、ステップS204において、再生制御の処理が継続される。すなわち、上記再生スケジュールに基づいて番組やCM広告が上側LCD22に適宜再生される。また、CM広告の再生時には、これに関連する連動バナー広告の画像が下側LCD12に表示される。
一方、メニュー画面に戻る指示が行われていれば(ステップS203でYES)、番組の再生が停止され、そのときの再生実績を反映するように視聴ログデータ606が適宜更新される(どの番組がどこまで再生されたか等)。そして、当該番組再生処理は終了する。
図25に戻り、番組再生処理が終了すれば、上記ステップS164に戻り、処理が繰り返される。
一方、上記ステップS166の判定の結果、操作データ511で示される操作内容が番組の再生指示ではないときは(ステップS166でNO)、ステップS168において、「広告一覧」の起動指示、すなわち、広告一覧ボタン103が押されたか否かが判定される。その結果、広告一覧ボタン103が押されていたときは(ステップS168でYES)、ステップS169において、広告一覧処理が実行される。
図27は、上記ステップS169で示した広告一覧処理の詳細を示すフローチャートである。まず、ステップS221において、バナー広告パッケージ603が参照され、バナー広告の抽出が行われる。更に、CM広告パッケージ604が参照され、これに含まれている連動バナー広告も抽出される。
次に、ステップS222において、抽出されたバナー広告群について、配信日が古い順番にソートされる。そして、ステップS223において、上記図7で示したような広告一覧画面が生成される(配信日が古いものが上の方に表示されるような一覧となる)。次に、ステップS224において、下側LCD12に上記広告一覧画面が表示される。
次に、ステップS225において、操作データ511が取得される。次に、ステップS226において、操作データ511に基づき、いずれかのバナー広告の詳細表示の指示が行われたか否かが判定される。当該判定の結果、詳細表示の指示が行われていれば(ステップS226でYES)、ステップS227において、バナー広告詳細表示処理が実行される。図28は、当該ステップS227で示したバナー広告詳細表示処理の詳細を示すフローチャートである。まず、ステップS241において、詳細表示の指示が行われたバナー広告(以下、処理対象バナー広告)のデータに基づき、図8で示したような下側LCD12に表示するための画面が生成される。
次に、ステップS242において、処理対象バナー広告に関連しているCM広告があるか否か(つまり、処理対象バナー広告は連動バナー広告か否か)が判定される。当該判定の結果、処理対象バナー広告に関連しているCM広告がある場合は(ステップS242でYES)、ステップS243において、上側LCD22では当該関連するCM広告の再生が開始され、下側LCD12には、バナー広告詳細画面が表示される。一方、処理対象バナー広告に関連しているCM広告がない場合は(ステップS242でNO)、ステップS244において、上側LCD22には、処理対象バナー広告についての各種情報(上記メタデータから取得される)が表示され、下側LCD12にはバナー広告詳細画面が表示される。
次に、ステップS245において、操作データ511が取得される。次に、ステップS246において、ウェブブラウザアプリの起動指示が行われたか否かが当該操作データ511に基づいて判定される。その結果、ブラウザ起動指示が行われていたときは(ステップS246でYES)、ステップS247において、当該視聴アプリをバックグラウンド処理とし、ウェブブラウザアプリを起動するための制御が行われる。その結果、ゲーム装置10のシステムによって、視聴アプリがバックグラウンド処理に切替えられ、ウェブブラウザアプリの実行が開始される。その結果、ステップS248で、ウェブブラウザ処理が実行される。ウェブブラウザアプリは、上記処理対象バナー広告に関連するURL情報で示されるサイトを表示し、ユーザの操作に基づく各種処理を実行する。
ウェブブラウザアプリの処理が終了すれば、システムが、視聴アプリをバックグラウンド処理からフォアグラウンド処理に切り替える。これに応じて、視聴アプリの画面が表示され、ステップS249において、中断前の画面が復元される。そして、上記ステップS245に戻って処理が繰り返される。
一方、上記ステップS246の判定の結果、ブラウザの起動指示は行われていないときは(ステップS246でNO)、ステップS250において、再生制御操作(例えば、次のバナー広告の表示指示等)が行われたか否かが判定される。その結果、再生制御操作が行われていたときは(ステップS250でYES)、その操作内容に応じた処理が適宜実行される。例えば、別のバナー広告の表示指示が行われていた場合は、次のバナー広告の画像を表示する処理が行われる。また、このときは関連するCM広告の有無も判定され、その判定結果に応じて上側LCD22に表示する内容は適宜変更される。その後、上記ステップS245に戻って処理が繰り返される。
一方、ステップS250の判定の結果、操作内容が再生制御ではないときは(ステップS250でNO)、次に、ステップS252において、当該詳細表示処理の終了が指示されたか否か(例えば、戻るボタン142が押されたか否か)が判定される。その結果、終了指示が行われていなければ(ステップS252でNO)、ステップS253において、CM広告の再生制御処理や画面の描画処理等が実行される。その後、上記ステップS245に戻り、処理が繰り返される。一方、終了指示が行われていれば(ステップS252でYES)、当該バナー広告詳細表示処理は終了する。
図27に戻り、上記ステップS226の判定の結果、バナー広告の詳細表示の指示が行われていなければ(ステップS226でNO)、次に、ステップS228において、当該広告一覧処理の終了指示が行われたか否かが操作データ511に基づき判定される。例えば、戻るボタン132が押されたか否かが判定される。その結果、終了指示が行われていれば(ステップS228でYES)、当該広告一覧処理は終了する。一方、終了指示が行われていなければ(ステップS228でNO)、次に、ステップS229において、その他の操作が行われたか否かが判定される。例えば、画面スクロールの操作が行われたか否かが判定される。その他の操作が行われていれば(ステップS229でYES)、ステップS230において、その操作内容に応じた各種制御処理が実行される。その後、上記ステップS224に戻り、処理が繰り返される。一方、その他の操作も行われていなければ(ステップS229でNO)、上記ステップS224に戻り、処理が繰り返される。なお、本実施形態では、広告一覧処理で閲覧された各広告の視聴実績については視聴ログデータ606に反映しないものとするが、他の実施形態では、反映するようにしてもよい。以上で、広告一覧処理の説明を終了する。
図25に戻り、広告一覧処理が終われば、上記ステップS164に戻って処理が繰り返される。一方、上記ステップS168の判定の結果、広告一覧の起動指示ではないときは(ステップS168でNO)、次に、ステップS170において、設定画面の起動指示が行われたか否かが判定される。その結果、設定画面の起動指示が行われていれば(ステップS170でYES)、ステップS171において、設定画面処理が実行される。この処理では、視聴アプリに関する設定画面が表示され、ユーザの操作に基づいて各種設定を行うための処理が実行される。その後、上記ステップS164に戻り、処理が繰り返される。
一方、ステップS170の判定の結果、設定画面の起動指示も行われていなければ(ステップS170でNO)、ステップS172において、視聴アプリの終了指示が行われたか否かが判定される。終了指示が行われていなければ(ステップS172でNO)、上記ステップS164に戻り、処理が繰り返される。また、このとき、操作データで示されるユーザの操作が即時更新用のボタン102が押したことを示していれば、上記「番組」と「広告」の「受信タスク」が即時実行される。そして、即時更新中である旨を画面に表示し、当該即時更新にかかる処理が終了してから上記ステップS164に戻る。
一方、ステップS172の判定の結果、終了指示が行われていれば(ステップS172でYES)、当該メイン処理は終了する。
図22に戻り、メイン処理が終了すれば、次に、ステップS106において、「視聴ログ送信タスク」の準備処理が実行される。具体的には、当該「視聴ログ送信タスク」をシステムに登録・あるいは更新する処理が実行される。なお、本実施形態では、原則として当該「タスク」の消尽回数に”1”が設定されて登録されるものとする。つまり、視聴ログデータ606の送信は視聴アプリ終了後、基本的に一度だけ実行され、視聴アプリが起動して終了される度に、消尽回数を”1”として更新される。その結果、当該送信タスクが実行されたときに、視聴ログデータ606が所定のサーバに送信されることになる。以上で、視聴アプリ処理は終了する。
このように、本実施形態では、「番組」を構成するデータと「広告」を構成するデータを別々に受信し、別ファイルとして取り扱っている。これにより、番組と広告を一体化してデータの送受信が行われる場合に比べ、一回分の受信処理にかかるデータ量を低減して、ネットワークへの通信負荷を軽減できる。換言すれば、このような番組と広告の受信にかかる処理負担を分散することが可能となる。また、例えば、公衆の無線LANアクセスポイントを介して所定のサーバとデータの送受信を行うような携帯可能な情報端末(典型的には、通信機能に関しては近距離無線通信機能のみを有している情報端末)では、ネットワークへのいわゆる常時接続が保証されない。しかし、本発明では上記のように一回分の受信処理にかかるデータ量が低減されることができるため、特にこのような情報端末において番組やCMの配信を行う場合に好適である。
また、「広告」を「番組」とは別に受信するため、同じ「広告」を複数の番組で使いまわすことができる。そのため、複数の番組で共通の広告を用いるような態様では、番組と広告を一体化して配信する場合に比べて、同じ広告が重複して配信されてしまうことによるデータの無駄を無くすことができる。
また、上記「いつの間に通信」により、ユーザがゲーム装置10を使用していない間(スリープモード)でも「番組」等の受信ができるため、知らない間に番組が配信されることによる驚きや楽しみをユーザに与えることも可能である。
また、上記「いつの間に通信」による上記「番組」や「広告」の自動受信のスケジュールについて、「番組」と「広告」とで個別に設定することができるため、受信処理にかかる負荷を適切に分散させることができる。また、上記設定パッケージ605を用いて、これらスケジュールを変更することも可能であるため、より柔軟な番組・広告の配信を行うことができる。
また、「番組」についても、各テレビ局の「番組」毎に1つの「受信タスク」を割り当てているため、各番組の内容やその制作者等に応じて個別に受信することができ、また、その受信スケジュールも個別に設定することができる。
また、視聴ソフトが実行される際に、未視聴の番組や広告が優先的に再生され得るような制御を行っているため、番組の提供者が作成した多様な番組について、視聴者であるユーザの目に触れさせる機会をまんべんなく与えることが可能となる。
また、番組の再生に際して、各テレビ局の番組が公平に再生されるように制御を行っているため、各テレビ局からの番組提供を促進することも可能となる。
なお、上述した実施形態においては、番組パッケージにはCM広告が含まれていない例を挙げたが、他の実施形態においては、番組パッケージにCM広告を含めるように構成しても良い。そして、ある番組の再生に際しては、当該番組の途中に挿入されるCM広告は当該番組パッケージに含まれているCM広告から選択され、再生されるようにしてもよい。また、この場合、番組本編の再生中は、上述したバナー広告パッケージ603からランダムで選択されたバナー広告画像が表示されるようにしてもよいし、バナー広告についても当該番組パッケージに含めておき、その中から選択されたバナー広告のみが表示されるようにしてもよい。
また、視聴履歴の出力に関して、上記実施形態では、番組再生処理の終了時に視聴ログデータ606を更新していたが、この他、各番組の再生が開始されたタイミングで、当該番組は視聴されたものとして視聴ログデータ606を更新するようにしても良い。
また、上記実施形態では、視聴アプリを起動した際、未視聴番組があればその自動再生が行われていた。この再生に関して、未視聴番組を1本だけ再生したらメニュー画面が表示されるようにしても良いし、ユーザからの停止操作が行われるまでは、複数の未視聴番組を連続して自動再生するようにしても良い。また、複数の未視聴番組を連続して自動再生する場合は、各テレビ局の番組が交互に(2局の場合)、あるいは、同じ局の番組が連続して放送されないように順番に(3局以上ある場合)再生されるように制御すればよい。例えば、A局、B局、C局の3つのテレビ局がある場合は、「A局→B局→C局→A局→B局→C局・・・」のような順番で、各局の番組が1回づつ再生されるサイクルを1サイクルとして、このサイクルを繰り返すようにすればよい。これにより、自動再生される未視聴番組について、あるテレビ局の番組に偏って再生される(再生回数の偏り)ことを防ぐ事ができ、テレビ局間に不公平感が生じることを防ぐことができる。
また、再生順序の決定に関しても、上述の実施形態で示したような、視聴アプリの起動時刻を利用した処理に限らす、他の手法で再生順序を決定しても良い。例えば、最後に自動再生された番組のテレビ局を記録しておくように構成し、次に再生される番組は当該テレビ局以外の局の番組が選択されるようにしてもよい。あるいは、テレビ局間で予め所定の再生順序を定義しておき、当該再生順序に沿って各テレビ局の番組が順番に再生されるようにしても良い。
また、視聴アプリを起動した際の自動再生に関して、視聴履歴データを参照して、そのユーザが良く視聴している番組を優先的に自動再生してもよい。更には、視聴履歴データに基づいて各番組が再生された時間帯を算出して、視聴アプリが起動された時間帯に応じた番組を自動再生するようにしても良い。例えば、朝7時頃に視聴アプリが起動されたときは、「ニュース」番組を自動再生する等が考えられる。
また、視聴アプリを起動した際、未視聴か否かにかかわらず、ランダムに選択された番組を自動再生するように構成してもよい。
また、上記実施形態では、2つの表示装置を備えたゲーム装置10を例に説明したが、単一の表示装置を備え当該表示装置の画面上にタッチパネルを備えた携帯端末であってもよい。この場合は、例えば、画面レイアウトを、左2/3を番組再生用の領域に割り当て、残り1/3をバナー広告表示用の領域に割り当てる等すればよい。