特許第6055052号(P6055052)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

▶ 任天堂株式会社の特許一覧
特許6055052携帯型情報端末、携帯情報システム、携帯型情報端末制御プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6055052
(24)【登録日】2016年12月9日
(45)【発行日】2016年12月27日
(54)【発明の名称】携帯型情報端末、携帯情報システム、携帯型情報端末制御プログラム
(51)【国際特許分類】
   H04W 48/16 20090101AFI20161219BHJP
   H04W 52/02 20090101ALI20161219BHJP
   H04M 1/725 20060101ALI20161219BHJP
【FI】
   H04W48/16 110
   H04W52/02
   H04M1/725
【請求項の数】7
【全頁数】75
(21)【出願番号】特願2015-173042(P2015-173042)
(22)【出願日】2015年9月2日
(62)【分割の表示】特願2012-7437(P2012-7437)の分割
【原出願日】2010年11月12日
(65)【公開番号】特開2016-34131(P2016-34131A)
(43)【公開日】2016年3月10日
【審査請求日】2015年10月1日
(31)【優先権主張番号】特願2010-134563(P2010-134563)
(32)【優先日】2010年6月11日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1
(74)【代理人】
【識別番号】110001276
【氏名又は名称】特許業務法人 小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】山崎 順稔
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】大江 徹
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】庄司 昌弘
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】安達 洋明
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】久保田 隆司
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
【審査官】 望月 章俊
(56)【参考文献】
【文献】 国際公開第2010/053427(WO,A1)
【文献】 特表2012−507339(JP,A)
【文献】 特開2010−81423(JP,A)
【文献】 米国特許出願公開第2005/0085259(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04W4/00−H04W99/00
H04B7/24−H04B7/26
H04M1/725
(57)【特許請求の範囲】
【請求項1】
近距離無線を用いて通信可能範囲に存在する不特定多数の他の情報端末からデータを自動的に受信する近距離通信手段と、
前記近距離通信手段によって受信した前記不特定多数の他の情報端末のデータをインターネットを介して送信するインターネット通信手段と、を備え、
前記近距離通信手段は、前記他の情報端末のデータとともに当該データを前記サーバに送信することを規定した規定情報をさらに受信し、
前記インターネット通信手段は、前記規定情報に基づいて前記他の情報端末のデータを前記サーバへ送信し、
前記規定情報には、送信を実行するタイミングまたは実行の優先度を指定するためのパラメタが含まれており、
前記インターネット通信手段は、前記規定情報で指定される前記パラメタに基づいて、送信の実行タイミングを制御する、携帯型情報端末。
【請求項2】
前記他の情報端末は、インターネットを介した通信が許容されていない端末である、請求項1に記載の情報端末。
【請求項3】
前記近距離通信手段は、通信可能範囲に存在する他の情報端末を自動的に繰り返し探索して自動的に接続し、当該接続された他の情報端末からデータを受信する、請求項1に記載の情報端末。
【請求項4】
前記インターネット通信手段は、前記インターネットを介してデータを受信し、
前記近距離通信手段は、前記インターネットを介して受信したデータを前記他の情報端末へ送信する、請求項1に記載の情報端末。
【請求項5】
情報端末のコンピュータによって実行される通信制御プログラムであって、
近距離無線を用いて通信可能範囲に存在する不特定多数の他の情報端末からデータを自動的に受信する近距離通信手段と、
前記近距離通信手段によって受信した前記不特定多数の他の情報端末のデータをインターネットを介して送信するインターネット通信手段として前記コンピュータを機能させ、
前記近距離通信手段は、前記他の情報端末のデータとともに当該データを前記サーバに送信することを規定した規定情報をさらに受信し、
前記インターネット通信手段は、前記規定情報に基づいて前記他の情報端末のデータを前記サーバへ送信し、
前記規定情報には、送信を実行するタイミングまたは実行の優先度を指定するためのパラメタが含まれており、
前記インターネット通信手段は、前記規定情報で指定される前記パラメタに基づいて、送信の実行タイミングを制御する、通信制御プログラム。
【請求項6】
情報端末を制御する通信制御方法であって、
近距離無線を用いて通信可能範囲に存在する不特定多数の他の情報端末からデータを自動的に受信する近距離通信ステップと、
前記近距離通信ステップにおいて受信した前記不特定多数の他の情報端末のデータをインターネットを介して送信するインターネット通信ステップとを備え、
前記近距離通信ステップでは、前記他の情報端末のデータとともに当該データを前記サーバに送信することを規定した規定情報をさらに受信し、
前記インターネット通信ステップでは、前記規定情報に基づいて前記他の情報端末のデータを前記サーバへ送信し、
前記規定情報には、送信を実行するタイミングまたは実行の優先度を指定するためのパラメタが含まれており、
前記インターネット通信ステップでは、前記規定情報で指定される前記パラメタに基づいて、送信の実行タイミングを制御する、通信制御方法。
【請求項7】
近距離無線を用いて通信可能範囲に存在する不特定多数の他の情報システムからデータを自動的に受信する近距離通信手段と、
前記近距離通信手段によって受信した前記不特定多数の他の情報システムのデータをインターネットを介して送信するインターネット通信手段とを備え、
前記近距離通信手段は、前記他の情報端末のデータとともに当該データを前記サーバに送信することを規定した規定情報をさらに受信し、
前記インターネット通信手段は、前記規定情報に基づいて前記他の情報端末のデータを前記サーバへ送信し、
前記規定情報には、送信を実行するタイミングまたは実行の優先度を指定するためのパラメタが含まれており、
前記インターネット通信手段は、前記規定情報で指定される前記パラメタに基づいて、送信の実行タイミングを制御する、情報処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信機能を備えた携帯型情報端末に関し、より特定的には、省電力モードを有する携帯型情報端末に関する。
【背景技術】
【0002】
従来、ある条件を満たしたタイミングで、スケジューリングされた通信タスクを実行する技術が存在している(例えば、特許文献1)。このような技術を用いた装置では、スケジューリングされたメッセージ送受信やダウンロードのタスクが、所定の単位時間ごとやタスクに設定されたタイミングで実行される。通信タスクは、CPUと独立して入出力プロセッサによって行われるため、CPUに電源が供給されないスタンバイモード時であっても実行されるため、ユーザが送受信やダウンロードの指示を行う必要がなくなる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2008−125659号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記特許文献1の装置は、予めネットワークへの接続が確立されていることを前提として、メッセージの送受信やダウンロードといった処理の実行を間欠的に行うものであった。そのため、送受信やダウンロードの処理を実行すべきときにネットワークへの接続がなされていない場合、ネットワークへの接続を試みることができなかった。家庭など予め決められた場所に設置して使用する据置型の装置であれば、ネットワークに常時接続されていることを前提とした上記特許文献1の発明は有用ではある。しかし、持ち歩いて使用する携帯型の装置では、ユーザの移動によりアクセスポイントとの距離が変化し、また、付近にアクセスポイントが存在しなくなる状況も発生するため、上記特許文献1の発明を用いることは困難である。さらに、ユーザの指示したアクセスポイントに接続する方法は既に周知であるが、この方法においては、接続可能なアクセスポイントが付近に存在していたとしても、当該アクセスポイントに接続するためには、付近にアクセスポイントがあることにユーザが気付き、更に、接続の指示を行う必要がある。そのため、当該接続に際してのユーザの手間がかかり、かつユーザは付近にアクセスポイントがあるかどうかを常に意識しなければならない。
【0005】
それ故に、本発明の目的は、アクセスポイントとの距離が一定ではない環境であるために常時接続が実現できない状態においても、必要なときに自動的にアクセスポイントに接続を試みることで、常時接続に類似した接続状態を実現できる携帯端末を提供することである。
また、本発明の他の目的は、接続を行うことについてユーザの意識や指示がなくとも、必要なときに自動的にアクセスポイントに接続を試み、ネットワーク上に存在させることのできる携帯端末を提供することである。
【課題を解決するための手段】
【0006】
上記目的を達成するために、本発明は以下のような構成を採用した。
【0007】
第1の発明は、第1切替手段と、探索手段と、通信処理手段とを備えた、携帯型情報端末である。第1切替手段は、非使用状態と、使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントを探
索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。
【0008】
第1の発明によれば、非使用状態のときであっても、アクセスポイントを探索し、通信も行われる。これにより、ユーザが気づかないうちにネットワークに接続することができる。
【0009】
第2の発明は、第1の発明において、非使用状態は、使用状態よりも消費電力が少ない。
【0010】
第2の発明によれば、消費電力が小さい状態にあっても、アクセスポイントを探索してデータ通信を行うことができる。
【0011】
第3の発明は、第1の発明において、携帯型情報端末は、ユーザにより開閉の操作が可能である。そして、第1切替手段は、携帯型情報端末が開状態であるときに使用状態に切り替え、閉状態であるときに非使用状態に切り替える。
【0012】
第3の発明によれば、携帯型情報端末が閉じている(つまり、ユーザが気づかない)間にもデータ通信を行うことができる。
【0013】
第4の発明は、第1の発明において、探索手段は、自動的に繰り返し前記アクセスポイントを探索する。そして、通信処理手段は、自動的にアクセスポイントに接続し、自動的にデータ通信処理を行う。
【0014】
第4の発明によれば、自動的にネットワークに接続されるので、ユーザが気づかないうちにデータ通信を行うことができる。さらに繰り返して行われるので、常時接続的な利用感を与えることができる。
【0015】
第5の発明は、第1の発明において、携帯型情報端末は、プログラム実行手段と、受付手段とを更に備える。
プログラム実行手段は、複数のアプリケーションプログラムを実行する。受付手段は、各アプリケーションプログラムから、ネットワークを介して他の情報処理装置との間で行われるデータの送信または受信の処理内容の指示を受け付ける。そして、探索手段は、所定のアクセスポイントを自動的に探索する。更に、通信処理手段は、受付手段によって複数のアプリケーションプログラムのうちそれぞれより受け付けられたデータの送信または受信を、アクセスポイントを介して、自動的に行う。
【0016】
第5の発明によれば、各アプリケーションはアクセスポイントへの接続やデータ送受信の処理を自ら行う必要はなく、指示を出しておけば、自動的にデータ送受信が行われるので、各アプリケーションの開発者はアプリケーションの設計が容易となり、ユーザとしても、データ通信を行うときに対象のアプリケーションを起動しておく必要もなくなる。
【0017】
第6の発明は、第1の発明において、携帯型情報端末は、記憶手段と、アクセスポイント情報設定手段と、探索時刻規定手段とを更に備える。記憶手段は、ユーザにより設定可能な、少なくとも1つの第1アクセスポイントに関する情報、および、ユーザにより設定不可能な、少なくとも1つの第2アクセスポイントに関する情報を記憶する。アクセスポイント情報設定手段は、ユーザにより少なくとも1つの第1アクセスポイントに関する情報を設定する。探索時刻規定手段は、少なくとも1つの第1アクセスポイントを探索する時刻を規定する。また、探索手段は、第1アクセスポイント探索手段と、第2アクセスポ
イント探索手段とを含む。第1アクセスポイント探索手段は、探索時刻規定手段によって規定された時刻が到来したときに、少なくとも1つの第1アクセスポイントに関する情報に基づいて、当該少なくとも1つの第1アクセスポイントを探索する。第2アクセスポイント探索手段は、少なくとも1つの第2アクセスポイントに関する情報に基づいて、当該少なくとも1つの第2アクセスポイントを自動的に繰り返し探索する。
【0018】
第6の発明によれば、ユーザが設定するAPは規定時刻に探索が行われ、予め設定されているAPは自動的に繰り返し探索される。前者は家庭などにあるので、規定された時間に行えば足るが、後者は端末の移動などにより検出できるときや検出できないときがあるので、繰り返し探索を行うことで検出する効率を上げることができる。
【0019】
第7の発明は、第1の発明において、通信処理手段は、所定のアクセスポイントに接続し、当該アクセスポイントを介して所定のデータを受信する。
【0020】
第7の発明によれば、ユーザが気づかないうちにネットワークに接続し、所定のデータを受信することができる。また、データ受信が開始されるまでは省電力モードであるため、消費電力を節約することができる。
【0021】
第8の発明は、第1の発明において、携帯型情報端末は、探索手段によって検出されたアクセスポイントを介した所定のデータ通信処理を通信処理手段が終了した後、当該アクセスポイントとの接続を切断する通信切断手段を更に備える。
【0022】
第8の発明によれば、消費電力を更に節約することができる。
【0023】
第9の発明は、第1の発明において、探索手段は、近距離無線通信によって所定のアクセスポイントを探索する。
【0024】
第9の発明によれば、搭載されている無線通信の通信可能距離が限られている場合には通常携帯型情報端末を移動させたときに接続が維持できる確率は低いが、そのような場合でも、常時接続的な利用感をユーザに提供することができる。
【0025】
第10の発明は、第1の発明において、携帯型情報端末は、少なくとも携帯型情報端末が非使用状態で稼働しているときにおいて所定の条件が満たされたか否かを判別する条件判別手段を更に備える。そして、探索手段は、条件判別手段によって所定の条件が満たされたと判別されたときに、所定のアクセスポイントを探索する。
【0026】
第11の発明は、第10の発明において、条件判別手段は、所定の時刻が到来したときに、条件が満たされたと判別する。
【0027】
第10乃至第11の発明によれば、ユーザの指示によらずにアクセスポイントへ接続を試みるので、ユーザが気づかないうちにネットワークに接続することができる。
【0028】
第12の発明は、第10の発明において、携帯型情報端末は、ネットワークを介して他の情報処理装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する処理規定手段を更に備える。また、通信処理手段は、処理規定手段によって規定されたデータの送信または受信を探索手段で検出されたアクセスポイントを介して行うデータ送受信処理手段を含む。そして、条件判別手段は、処理規定手段によって規定された実行時刻が到来したときに条件を満たしたと判別する。更に、データ送受信処理手段は、条件判別手段によって所定の条件が満たされたと判別され、探索手段によって所定のアクセスポイントを検出したときに、所定のデータの送信または受信を行う。
【0029】
第12の発明によれば、処理を行うべき時刻、すなわち必要なときに、アクセスポイントに接続を試みる。そのため、必要なときにアクセスポイントが携帯型情報端末の付近に存在していれば、常時接続しているのと同様の効果を奏することができる。
【0030】
第13の発明は、第1の発明において、探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントから発信されるビーコンの受信を自動的に繰り返し試みることで所定のアクセスポイントを探索し、当該ビーコンを受信することにより当該アクセスポイントの検出を行う。また、通信処理手段は、接続確立手段と、データ送受信手段とを含む。接続確立手段は、探索手段によってビーコンを受信したと判別されたとき、当該ビーコンを送信したアクセスポイントへの接続の確立を試みる。データ送受信手段は、アクセスポイントへの接続が確立されたとき、当該アクセスポイントを介して所定のデータの送信または受信を行う。
【0031】
第13の発明によれば、ユーザが指示をしなくても自動的に繰り返しアクセスポイントのビーコンの受信を試み、ビーコンを受信すればアクセスポイントとの接続を試みるため、ユーザが気づかないうちにネットワークに接続することができる。
【0032】
第14の発明は、第13の発明において、携帯型情報端末は、処理規定手段を更に備える。処理規定手段は、ネットワークを介して他の装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する。更に、通信処理手段は、実行時刻判別手段を更に含む。実行時刻判別手段は、接続確立手段によってアクセスポイントへの接続が確立されたとき、規定された実行時刻が到来しているか否かを判別する。そして、データ送受信手段は、実行時刻が到来しているとき、アクセスポイントを介して、規定されたデータの送信または受信を行う。
【0033】
第14の発明によれば、ビーコンを受信してアクセスポイントに接続したときに、既に実行予定時刻が到来している(にも関わらず実行されていない)処理を実行するため、常時接続に近い効果を奏することができる。
【0034】
第15の発明は、第1の発明において、携帯型情報端末は、表示手段を更に備える。また、使用状態においては、表示手段に電力が供給されるが、非使用状態においては、表示手段への電力は供給されない。そして、第1切替手段は、ユーザによる所定の操作に応じて使用状態と非使用状態を切り替える。更に、携帯型情報端末は、ユーザの操作に応じて非使用状態から使用状態に切り替えられたとき、通信処理手段によって受信したデータの内容を表示手段に表示する表示制御手段を更に備える。
【0035】
第15の発明によれば、ユーザが操作を行ったときに表示手段に電力が供給されるモードに切り替えられ、受信したデータが表示され、ユーザは新たなデータを受信したことを知ることができるため、ユーザに驚きを与えることができる。
【0036】
第16の発明は、第8の発明において、携帯型情報端末は、省電力モードと非省電力モードとの間で電源制御モードを切り替える第2切替手段を更に備える。そして、探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。また、第2切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替え、通信切断手段によって当該アクセスポイントとの接続が切断されたとき、当該電源制御モードを省電力モードに切り替える。
【0037】
第17の発明は、第1の発明において、携帯型情報端末は、省電力モードと非省電力モ
ードとの間で電源制御モードを切り替える第2切替手段を更に備える。そして、探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。第2切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替え、通信処理手段によるデータ通信処理が終了したとき、当該電源制御モードを省電力モードに切り替える。
【0038】
第16乃至第17の発明によれば、APが検出されると非省電力になりデータ通信が行われ、終了後に切断し省電力になるので、データ通信時に電力を必要とする場合でも(すなわち、非省電力では通信ができない場合・仕様でも)消費電力を節約することができる。
【0039】
第18の発明は、第1の発明において、通信処理手段は、アクセスポイントを介して、1以上のアプリケーションプログラムの受信を自動的に行う。そして、携帯型情報端末は、1以上のアプリケーションプログラムの受信が行われたとき、当該アプリケーションプログラムの携帯型情報端末へのインストールを自動的に行うインストール手段を更に備える。
【0040】
第18の発明によれば、自動的にアプリケーションプログラムのダウンロード(受信)およびインストールを行うので、ユーザは気付かないうちに新たなアプリケーションを受信することができるため、ユーザに驚きを与えるとともに、アプリケーション提供者にとってはアプリケーションを使用してもらう機会を増やすことができる。
【0041】
第19の発明は、第1の発明において、通信処理手段は、アクセスポイントを介して、1以上のアプリケーションプログラムの受信を自動的に行う。また、携帯型情報端末は、一覧作成手段と、選択手段と、アプリケーションプログラム実行手段と、一覧作成対象追加手段とを更に備える。一覧作成手段は、当該携帯型情報端末の起動時に、アプリケーションプログラムの一覧を作成し出力する。選択手段は、携帯型情報端末への所定の操作に応じて、一覧からいずれかのアプリケーションプログラムを選択する。アプリケーションプログラム実行手段は、選択されたアプリケーションプログラムを実行する。一覧作成対象追加手段は、通信処理手段によって自動的に受信されたアプリケーションプログラムを、一覧作成手段により作成される一覧の掲載対象へと自動的に追加する。
【0042】
第19の発明によれば、自動的に受信されたアプリケーションは、自動的に一覧(メニュー)の掲載対象となるため、ユーザは新たに受信されたアプリケーションに気づくことができる。
【0043】
第20の発明は、第1の発明において、通信処理手段は、前記アクセスポイントを介して、1以上のアプリケーションプログラムの受信を自動的に行う。携帯型情報端末は、一覧作成手段と、選択手段と、アプリケーションプログラム実行手段と、一覧作成対象追加手段とを更に備える。一覧作成手段は、当該携帯型情報端末への所定の操作に応じて、アプリケーションプログラムの一覧を作成し出力する。選択手段は、携帯型情報端末への所定の操作に応じて、一覧からいずれかのアプリケーションプログラムを選択する。アプリケーションプログラム実行手段は、選択されたアプリケーションプログラムを実行する。一覧作成対象追加手段は、通信処理手段によって自動的に受信されたアプリケーションプログラムを、一覧作成手段により作成される一覧の掲載対象へと自動的に追加する。
【0044】
第20の発明によれば、自動的に受信されたアプリケーションは、自動的に一覧(メニュー)の掲載対象となるため、ユーザは新たに受信されたアプリケーションに気づくことができる。
【0045】
第21の発明は、第1の発明において、携帯型情報端末は、近距離無線を用いて自端末の通信可能範囲に存在する通信相手となる他端末を繰り返し探索して自動的に無線接続し、当該無線接続がされた当該他端末との間で自動的にデータを送信または受信する近距離データ通信手段を更に備える。そして、通信処理手段は、近距離データ通信手段により受信したデータの内容をアクセスポイントを介して更に他の情報処理装置へ送信する。
【0046】
第21の発明によれば、近距離で他の端末と通信は可能であるがAPには接続することができない端末があった場合に、その端末の代わりにAPを介しての送信を行うことができる。
【0047】
第22の発明は、第1の発明において、携帯型情報端末は、近距離無線を用いて自端末の通信可能範囲に存在する通信相手となる他端末を繰り返し探索して自動的に無線接続し、当該無線接続がされた当該他端末との間で自動的にデータを送信または受信する近距離データ通信手段を更に備える。そして、近距離データ通信手段は、通信処理手段によって受信したデータの内容を他端末へ送信する。
【0048】
第22の発明によれば、近距離で他の端末と通信は可能であるがAPには接続することができない端末があった場合に、その端末の代わりにAPを介してデータを受信することができる。
【0049】
第23の発明は、第1の発明において、携帯型情報端末は、計時手段、近距離無線通信を行うための無線通信モジュール、演算処理手段、および、第2切替手段と、時刻判別手段を更に備える。第2切替手段は、計時手段、演算処理手段、および無線モジュールに電力が供給される非省電力モードと、計時手段および無線モジュールには電力が供給されるが演算処理手段には電力は供給されない省電力モードとの間で電源制御モードを切り替える。時刻判別手段は、少なくとも非使用状態かつ省電力モードで当該携帯型情報端末が稼働しているときにおいて所定の時刻が到来したか否かを、計時手段を用いて判別する。更に、第2切替手段は、時刻判別手段によって所定の時刻が到来したときに、電源制御モードを非省電力モードに切り替える。そして、探索手段は、少なくとも非使用状態かつ非省電力モードで前記携帯型情報端末が稼働しているときに、無線モジュールおよび演算処理手段を用いて所定のアクセスポイントを探索する。
【0050】
第24の発明は、第1の発明において、携帯型情報端末は、近距離無線通信を行うための無線通信モジュール、演算処理手段、および、第2切替手段を更に備える。第2切替手段は、演算処理手段および無線モジュールに電力が供給される非省電力モードと、無線モジュールには電力が供給されるが演算処理手段には電力は供給されない省電力モードとの間で電源制御モードを切り替える。探索手段は、少なくとも非使用状態かつ省電力モードで携帯型情報端末が稼働しているときに、無線通信モジュールによって所定のアクセスポイントを探索する。第2切替手段は、探索手段によって所定のアクセスポイントが検出されたとき、電源制御モードを非省電力モードに切り替える。そして、通信処理手段は、第2切替手段によって非省電力モードに切り替えられたとき、無線モジュールおよび演算処理手段を用いてアクセスポイントに接続し、データ通信処理を実行する。
【0051】
第23乃至第24の発明によれば、第1の発明と同様の効果を得ることができる。
【0052】
第25の発明は、処理規定手段と、時刻判別手段と、接続手段と、データ送受信手段を備える、携帯型情報端末である。処理規定手段は、ネットワークを介して他の装置との間で行われるデータの送信または受信の処理内容、および当該処理の実行時刻を規定する。時刻判別手段は、処理規定手段によって規定された実行時刻が到来したか否かを判別する。接続手段は、時刻判別手段によって前記実行時刻が到来したと判別されたとき、所定の
アクセスポイントへの接続を試みる。データ送受信手段は、接続手段によってアクセスポイントへの接続が確立されたとき、処理規定手段によって規定されたデータの送信または受信を、当該アクセスポイントを介して行う。
【0053】
第25の発明によれば、処理を行うべき時刻、すなわち必要なときに、アクセスポイントに接続を試みるので、必要なときにアクセスポイントが付近に存在していれば、常時接続しているのと同様の効果を奏することができる。
【0054】
第26の発明は、第1切替手段と、探索手段と、通信処理手段とを備えた、携帯型情報システムである。第1切替手段は、非使用状態と、使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントを探索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。
【0055】
第27の発明は、非使用状態と使用状態の2つのモードを有する携帯型情報端末のコンピュータで実行される携帯型情報端末制御プログラムである。当該プログラムは、コンピュータを、第1切替手段と、探索手段と、通信処理手段として機能させる。第1切替手段は、非使用状態と使用状態とを切り替える。探索手段は、少なくとも非使用状態で携帯型情報端末が稼働しているときに所定のアクセスポイントを探索する。通信処理手段は、探索手段によって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続し、当該アクセスポイントを介して所定のデータ通信処理を行う。
【0056】
第28の発明は、第1切替ステップと、探索ステップと、通信処理ステップとを備えた、携帯型情報端末制御方法である。第1切替ステップでは、非使用状態と使用状態とが切り替えられる。探索ステップでは、少なくとも非使用状態で携帯型情報端末が稼働しているときに、所定のアクセスポイントが探索される。通信処理ステップでは、探索ステップによって所定のアクセスポイントが検出されたとき、当該アクセスポイントに接続され、当該アクセスポイントを介して所定のデータ通信処理が行われる。
【0057】
第26乃至第28の発明によれば、第1の発明と同様の効果を得ることができる。
【発明の効果】
【0058】
本発明によれば、常時接続型ではない携帯型情報端末であっても、常時接続的な利用感をユーザに提供することができる。
【図面の簡単な説明】
【0059】
図1】本発明の第1の実施形態に係るゲーム装置1の外観図
図2】本発明の第1の実施形態に係るゲーム装置1のブロック図
図3】本実施形態にかかるネットワーク構成の全体像を示す模式図
図4】メニュー画面の一例
図5】メニュー画面の一例
図6】メニュー画面の一例
図7】「すれ違い通信」について説明するための図
図8】「すれ違い通信」について説明するための図
図9】「すれ違い通信」について説明するための図
図10】「すれ違い通信」について説明するための図
図11】本実施形態で実行される各種機能(プログラム)の相関関係を示す図
図12】マイコン37に内蔵されている記憶領域に記憶される主なデータを示す図
図13】無線通信モジュール34に内蔵されている記憶領域に記憶される主なデータを示す図
図14】NANDフラッシュメモリ33に記憶されるプログラム、データを示す図
図15図14のすれ違い通信用データ520のデータ構造の一例を示した図
図16図14のタスクデータ530のデータ構造の一例を示した図
図17図14のアプリ関連データ550のデータ構造の一例を示した図
図18図14の受信ポリシーデータ570のデータ構造の一例を示した図
図19図14のインストールリスト580のデータ構造の一例を示した図
図20図14のダウンロードリスト590のデータ構造の一例を示した図
図21】マイコン37によって実行されるマイコン処理を示すフローチャート
図22】無線モジュール処理を示すフローチャート
図23】無線モジュール処理を示すフローチャート
図24】起動時処理の詳細を示すフローチャート
図25】起動時処理の詳細を示すフローチャート
図26図24のステップS61で示すメニュー処理の詳細を示すフローチャート
図27図24のステップS61で示すメニュー処理の詳細を示すフローチャート
図28図27のステップS108で示した各アプリの処理の詳細を示すフローチャート
図29図27のステップS108で示した各アプリの処理の詳細を示すフローチャート
図30図28のステップS131で示したタスク生成処理の詳細を示すフローチャート
図31】ローカル通信用BG処理の詳細を示すフローチャート
図32】ローカル通信用BG処理の詳細を示すフローチャート
図33】インターネット通信用BG処理の詳細を示すフローチャート
図34図33のステップS191で示したポリシー処理の詳細を示すフローチャート
図35図33のステップS191で示したポリシー処理の詳細を示すフローチャート
図36】ポリシーサーバ103のメモリマップを示す図
図37】ポリシーサーバ103で実行される処理を示すフローチャート
図38図33のステップS192で示したタスク実行処理の詳細を示すフローチャート
図39図33のステップS192で示したタスク実行処理の詳細を示すフローチャート
図40図33のステップS192で示したタスク実行処理の詳細を示すフローチャート
図41図38のステップS251で示した実行順ソート処理の詳細を示すフローチャート
図42図39のステップS272で示したインストール処理の詳細を示すフローチャート
図43図39のステップS272で示したインストール処理の詳細を示すフローチャート
図44】第2の実施形態に係るボトルメールアプリの処理概要を示す図
図45】第2の実施形態に係るボトルメールアプリの処理概要を示す図
図46】ボトルメールサーバに記憶される履歴情報データのデータ構造の一例を示す図
図47】ボトルメールサーバに記憶されるAP地域テーブルの一例
図48】ゲーム装置1で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート
図49】ゲーム装置1で実行される上記ボトルメールアプリ処理の詳細を示すフローチャート
図50】ボトルメールサーバの処理の詳細を示すフローチャート
【発明を実施するための形態】
【0060】
以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。
【0061】
(第1の実施形態)
図1は、本発明にかかる携帯端末の一例である携帯型ゲーム装置(以下、単にゲーム装置)の一例を示した図である。図1において、ゲーム装置1は、折り畳み型の携帯ゲーム装置であり、開いた状態(開状態)のゲーム装置1を示している。ゲーム装置1は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。
【0062】
ゲーム装置1は、下側ハウジング11および上側ハウジング21を有する。下側ハウジング11と上側ハウジング21とは、開閉可能(折り畳み可能)に連結されている。図1の例では、下側ハウジング11および上側ハウジング21は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回転可能に連結されている。通常、ユーザは、開状態でゲーム装置1を使用する。また、ユーザは、ゲーム装置1を使用しない場合には閉状態としてゲーム装置1を保管する。また、図1に示した例では、ゲーム装置1は、上記閉状態および開状態のみでなく、下側ハウジング11と上側ハウジング21とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング21を下側ハウジング11に対して任意の角度で静止させることができる。
【0063】
下側ハウジング11には、下側LCD(Liquid Crystal Display:液晶表示装置)12が設けられる。下側LCD12は横長形状であり、長辺方向が下側ハウジング11の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置1に内蔵されている表示装置としてLCDを用いているが、例えばEL(Electro Luminescence:電界発光)を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置1は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側LCD12は、主に、内側カメラ23または外側カメラ25で撮影されている画像をリアルタイムに表示するために用いられる。
【0064】
下側ハウジング11には、入力装置として、各操作ボタン14A〜14Lおよびタッチパネル13が設けられる。図1に示されるように、各操作ボタン14A〜14Lのうち、方向入力ボタン14A、操作ボタン14B、操作ボタン14C、操作ボタン14D、操作ボタン14E、電源ボタン14F、ホームボタン14I、スタートボタン14G、およびセレクトボタン14Hは、上側ハウジング21と下側ハウジング11とを折りたたんだときに内側となる、下側ハウジング11の内側主面上に設けられる。方向入力ボタン14Aは、例えば選択操作等に用いられる。各操作ボタン14B〜14Eは、例えば決定操作やキャンセル操作等に用いられる。電源ボタン14Fは、ゲーム装置1の電力制御モードを切り替えるために用いられる。詳細は後述するが、本実施形態では、電力制御モードとして「通常電力モード」と「スリープモード」がある。ホームボタン14Iは、ゲームなどのアプリケーションが実行されているときに、メニュー画面に戻るために用いられる。図1に示す例では、方向入力ボタン14A、電源ボタン14Fおよびホームボタン14Iは、下側ハウジング11の内側主面中央付近に設けられる下側LCD12に対して、左右一方側(図1では左側)の当該主面上に設けられる。また、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、下側LCD12に対して左右他方側(図1では右側)となる下側ハウジング11の内側主面上に設けられる。方向入力ボタ
ン14A、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、ゲーム装置1に対する各種操作を行うために用いられる。
【0065】
なお、図1においては、操作ボタン14J〜14Lの図示を省略している。例えば、Lボタン14Jは、下側ハウジング11の上側面の左端部に設けられ、Rボタン14Kは、下側ハウジング11の上側面の右端部に設けられる。Lボタン14JおよびRボタン14Kは、ゲーム装置1に対して、例えば撮影指示操作(シャッター操作)を行うために用いられる。さらに、音量ボタン14Lは、下側ハウジング11の左側面に設けられる。音量ボタン14Lは、ゲーム装置1が備えるスピーカの音量を調整するために用いられる。
【0066】
また、ゲーム装置1は、各操作ボタン14A〜14Lとは別の入力装置として、さらにタッチパネル13を備えている。タッチパネル13は、下側LCD12の画面上を覆うように装着されている。なお、本実施形態では、タッチパネル13は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル13は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、本実施形態では、タッチパネル13として、例えば下側LCD12の解像度と同解像度(検出精度)のものを利用する。ただし、必ずしもタッチパネル13の解像度と下側LCD12の解像度とが一致している必要はない。また、下側ハウジング11の右側面には、挿入口(図1に示す破線)が設けられている。挿入口は、タッチパネル13に対する操作を行うために用いられるタッチペン27を収納することができる。なお、タッチパネル13に対する入力は、通常タッチペン27を用いて行われるが、タッチペン27に限らずユーザの指でタッチパネル13を操作することも可能である。
【0067】
また、下側ハウジング11の右側面には、メモリカード28を収納するための挿入口(図1では、二点鎖線で示している)が設けられている。この挿入口の内側には、ゲーム装置1とメモリカード28とを電気的に接続するためのコネクタ(図示せず)が設けられる。メモリカード28は、例えばSD(Secure Digital)メモリカードであり、コネクタに着脱自在に装着される。メモリカード28は、例えば、ゲーム装置1によって撮影された画像を記憶(保存)したり、他の装置で生成された画像をゲーム装置1に読み込んだりするために用いられる。
【0068】
さらに、下側ハウジング11の上側面には、カートリッジ29を収納するための挿入口(図1では、一点鎖線で示している)が設けられている。この挿入口の内側にも、ゲーム装置1とカートリッジ29とを電気的に接続するためのコネクタ(図示せず)が設けられる。カートリッジ29はゲームプログラム等を記録した記録媒体であり、下側ハウジング11に設けられた挿入口に着脱自在に装着される。
【0069】
下側ハウジング11と上側ハウジング21との連結部の左側部分には、3つのLED15A〜15Cが取り付けられる。ここで、ゲーム装置1は、他の機器との間で無線通信を行うことが可能であり、第1LED15Aは、ゲーム装置1の電源がオンである場合に点灯する。第2LED15Bは、ゲーム装置1の充電中に点灯する。第3LED15Cは、無線通信が確立している場合に点灯する。したがって、3つのLED15A〜15Cによって、ゲーム装置1の電源のオン/オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。
【0070】
一方、上側ハウジング21には、上側LCD22が設けられる。上側LCD22は横長形状であり、長辺方向が上側ハウジング21の長辺方向に一致するように配置される。なお、下側LCD12と同様、上側LCD22に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、上側LCD22上を覆うように、タッチパネルを設けてもかまわない。例えば、上側LCD22には、ユーザに各操作ボタン14A〜14
Lやタッチパネル13の役割を教えるための、操作説明画面が表示される。
【0071】
また、上側ハウジング21には、2つのカメラ(内側カメラ23および外側カメラ25)が設けられる。図1に示されるように、内側カメラ23は、上側ハウジング21の連結部付近の内側主面に取り付けられる。一方、外側カメラ25は、内側カメラ23が取り付けられる内側主面の反対側の面、すなわち、上側ハウジング21の外側主面(ゲーム装置1が閉状態となった場合に外側となる面であり、図1に示す上側ハウジング21の背面)に取り付けられる。なお、図1においては、外側カメラ25を破線で示している。これによって、内側カメラ23は、上側ハウジング21の内側主面が向く方向を撮影することが可能であり、外側カメラ25は、内側カメラ23の撮影方向の逆方向、すなわち、上側ハウジング21の外側主面が向く方向を撮影することが可能である。このように、本実施形態では、2つの内側カメラ23および外側カメラ25の撮影方向が互いに逆方向となるように設けられる。例えば、ユーザは、ゲーム装置1からユーザの方を見た景色を内側カメラ23で撮影することができるとともに、ゲーム装置1からユーザの反対側の方向を見た景色を外側カメラ25で撮影することができる。
【0072】
なお、上記連結部付近の内側主面には、音声入力装置としてマイク(図2に示すマイク44)が収納されている。そして、上記連結部付近の内側主面には、マイク44がゲーム装置1外部の音を検知できるように、マイクロフォン用孔16が形成される。マイク44を収納する位置およびマイクロフォン用孔16の位置は必ずしも上記連結部である必要はなく、例えば下側ハウジング11にマイク44を収納し、マイク44を収納位置に対応させて下側ハウジング11にマイクロフォン用孔16を設けるようにしても良い。
【0073】
また、上側ハウジング21の外側主面には、第4LED26(図1では、破線で示す)が取り付けられる。第4LED26は、外側カメラ25によって撮影が行われた(シャッターボタンが押下された)時点で点灯する。また、外側カメラ25によって動画が撮影される間点灯する。第4LED26によって、ゲーム装置1による撮影が行われた(行われている)ことを撮影対象者や周囲に通知することができる。
【0074】
また、上側ハウジング21の内側主面中央付近に設けられる上側LCD22に対して、左右両側の当該主面に音抜き孔24がそれぞれ形成される。音抜き孔24の奥の上側ハウジング21内にはスピーカが収納されている。音抜き孔24は、スピーカからの音をゲーム装置1の外部に放出するための孔である。
【0075】
以上に説明したように、上側ハウジング21には、画像を撮影するための構成である内側カメラ23および外側カメラ25と、例えば撮影の際に操作説明画面を表示する表示手段である上側LCD22とが設けられる。一方、下側ハウジング11には、ゲーム装置1に対する操作入力を行うための入力装置(タッチパネル13および各ボタン14A〜14L)と、ゲーム画面を表示するための表示手段である下側LCD12とが設けられる。したがって、ゲーム装置1を使用する際には、ユーザは、下側LCD12に表示される撮影画像(カメラによって撮影された画像)を見ながら、下側ハウジング11を把持して入力装置に対する入力を行うことができる。
【0076】
次に、図2を参照して、ゲーム装置1の内部構成を説明する。なお、図2は、ゲーム装置1の内部構成の一例を示すブロック図である。
【0077】
図2において、ゲーム装置1は、CPUパッケージ31、メインメモリ32、NANDフラッシュメモリ33、無線通信モジュール34、第1メモリカードインターフェース(メモリカードI/F)35および第2メモリカードI/F36、マイコン37、開閉検出器40、電源管理IC41、電源回路42、およびインターフェース回路(I/F回路)
43等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング11(または上側ハウジング21でもよい)内に収納される。
【0078】
CPUパッケージ31には、所定のプログラムを実行するための情報処理手段であるCPUが設けられている。本実施形態において、当該CPUは、その内部に2つのコアを有しており(いわゆるデュアルコアプロセッサ)、一方には主にシステム制御関連の処理を担当させ、もう一方には、主にアプリケーションの実行関連の処理を担当させている。そのほか、CPUパッケージ31には、GPU(Graphics Processor Unit)、DSP(Digital Signal Processor)、VRAM(Video RAM)が設けられている。その他、内部メインメモリ等も設けられている。図示は省略するが、これらの構成要素は、CPUパッケージ31内の内部バスによって互いに接続される(つまり、ワンチップ化されている)。ただし、これらがワンチップ化されていなくてもよいし、CPUのコア数も2つに限らない。
【0079】
GPUは、描画手段の一部を形成し、CPUからのグラフィクスコマンド(作画命令)に従って画像を生成する。VRAMは、GPUがグラフィクスコマンドを実行するために必要なデータ(ポリゴンデータやテクスチャデータ等のデータ)を記憶する。画像が生成される際には、GPUは、VRAMに記憶されたデータを用いて画像データを作成する。
【0080】
DSPは、オーディオプロセッサとして機能し、内部メインメモリやメインメモリ32に記憶されるサウンドデータや音波形(音色)データを用いて、音声データを生成する。
【0081】
なお、以下の説明においては、CPUパッケージ31を単にCPU31と記載する。
【0082】
ここで、CPU31によって実行されるプログラムは、ゲーム装置1内のNANDフラッシュメモリ33に予め記憶されていてもよいし、メモリカード28および/またはカートリッジ29から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。
【0083】
CPU31には、メインメモリ32、NANDフラッシュメモリ33、無線通信モジュール34が接続されている。メインメモリ32は、CPU31のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ32として、例えばPSRAM(Pseudo−SRAM)を用いる。
【0084】
NANDフラッシュメモリ33は、不揮発性の記憶媒体によって構成される。また、CPU31の指示に従って、図示しないメモリ制御回路が、NANDフラッシュメモリ33に対するデータの読み出しおよび書き込みを制御する。
【0085】
無線通信モジュール34は、例えばIEEE802.11.b/g/nの規格に準拠した方式により、無線LANに接続する機能を有する(後述する「インターネット通信」の際はこの方式が用いられる)。また、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する(後述する「ローカル通信」の際はこの方式が用いられる)。無線通信モジュール34は、CPU31に接続される。CPU31は、無線通信モジュール34を用いてインターネットを介して他の機器との間でデータを送受信したり、同種の他のゲーム装置との間でデータを送受信したりすることができる。また、無線通信モジュール34には、図示はしないがマイコンチップが搭載されており、後述のスリープモード中に所定の処理を実行する。
【0086】
また、第1メモリカードI/F35はCPU31に接続される。第1メモリカードI/F35は、コネクタに装着されたカートリッジ29に対するデータの読み出しおよび書き込みをCPU31の指示に従って行う。例えば、ゲーム装置1が実行することが可能なアプリケーションプログラムがカートリッジ29から読み出されてCPU31によって実行されたり、当該アプリケーションプログラムに関するデータ(例えばゲームのセーブデータ等)がカートリッジ29に書き込まれたりする。
【0087】
第2メモリカードI/F36は、CPU31に接続される。第2メモリカードI/F36は、コネクタに装着されたメモリカード28に対するデータの読み出しおよび書き込みを、CPU31の指示に応じて行う。例えば、外側カメラ25によって撮像された画像データがメモリカード28に書き込まれたり、メモリカード28に記憶された画像データがメモリカード28から読み出されてNANDフラッシュメモリ33に記憶されたりする。
【0088】
また、CPU31には、マイコン37が接続される。マイコン37は、ゲーム装置1の電源管理に関する処理や、時間に関する処理、上記ハウジングの開閉検知処理等を行う。また、これらの処理に関する通知をCPU31から受けたり、逆にCPU31に通知したりする。マイコン37は、リアルタイムクロック(RTC)39を備えている。RTC39は、時間をカウントし、マイコン37を介してCPU31に出力する。例えば、CPU31は、RTC39によって計時された時間に基づいて、現在時刻(日付)等を計算することもできる。
【0089】
また、マイコン37は、開閉検出器40および電源管理IC41と接続される。電源管理IC41は、更に、電源回路42と接続される。開閉検出器40は、上記ハウジングの開閉を検出し、その内容をマイコン37(ひいてはCPU31)に通知する。電源管理IC41は、マイコン37(マイコン37を介したCPU31)からのスリープモードへの移行やスリープモード解除の通知を受ける。そして、当該通知に基づいて適切な電力を供給するための制御を行う。電源回路42は、ゲーム装置1が有する電源(典型的には電池であり、下側ハウジング11に収納される)から供給される電力を制御し、上記電源管理IC41を介してゲーム装置1の各部品に電力を供給する。
【0090】
ここで、本実施形態にかかるゲーム装置1の電源制御のモードに関して説明する。本ゲーム装置では、電池等の電源が装着されて、上記各構成部品への電力供給が可能な状態となった後は、基本的には、「通常電力モード」と「省電力モード」の2つの電源制御モードのいずれかで動作する。「通常電力モード」は、上記構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーションを実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。本実施形態では、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、上記マイコン37、無線通信モジュール34にのみ電源を供給し、それ以外の部品、つまり、CPU31やLCDへの電力供給は停止している状態である(但し、CPU31は、「スリープモード」の解除指示を受けることは可能である)。また、「スリープモード」において、マイコン37や無線通信モジュール34は、「マイコン処理」、「無線モジュール処理」と呼ばれる処理を所定時間毎に繰り返し実行するが、これについては詳細は後述する。
【0091】
そして、本実施形態では、上述のような、開閉検出器40の検出結果に基づいてスリープモードへの移行やスリープモードの解除を行う方法のほかに、電源ボタン14Fの操作に応じて上記「通常電力モード」と「スリープモード」を切り替えることが可能である。また、電源ボタン14Fの操作によるものの他、後述するような処理によって、自動的に「スリープモード」の解除、あるいは「スリープモード」への移行も可能となっている。
例えば、ユーザが所定のゲームをプレイし終えた後、電源ボタン14Fを押すと(この操作は、ユーザから見ると、電源をオフにする操作に見える)、「スリープモード」に移行する。この状態で、ユーザはゲーム装置1を閉じて、持ち歩くこと等が可能である。その後、ユーザがゲーム装置1を開き、再度電源ボタン14Fを押すと、「スリープモード」が解除され、「通常電力モード」に移行する。または、所定時間が経過したことにより「スリープモード」へ移行するようにしてもよい。
【0092】
なお、上記「スリープモード」の他、「省電力モード」の一つとして、各LCDへの電力供給のみを停止する「モニタオフモード」での動作も可能である。このときは、CPU31やメインメモリ32への電力供給は行われる(なお、CPU31内のCPUコアと内部メモリのみに電力を供給し、上記GPUには電力は供給しないようにしてもよい)。その他、電源ボタン14Fを長押しすることで、マイコン37や無線モジュールも含めた全ての構成部品への電力供給を停止する(つまり、完全に電源を切る)「完全停止モード」に移行することも可能である。この場合は、再度電源ボタン14Fを長押しすると、「通常電力モード」に移行してゲーム装置1が起動することになる。
【0093】
ここで、上記電源制御モードに関し、ユーザがゲーム装置を使用中か否かという観点からは、以下のように言い換えることもできる。すなわち、ゲーム装置1は、「使用状態」と「非使用状態」という2つの状態を有するといえる。「使用状態」とは、ユーザがゲーム装置1のハウジングを開いて直接的に使用しているために、通常電力モードがずっと継続している状態である。例えば、ユーザが操作ボタン14等を操作して実際にゲーム等をプレイしている状態が該当する。一方、「非使用状態」とは、ユーザがゲーム装置1を主導的・直接的に使用していない状態をいう。これには、上記ハウジングが閉じられているために「スリープモード」となっている状態の他、後述するようなタスクの実行に伴い、(ハウジングは閉じられたまま)一時的に「スリープモード」が解除されてタスクにかかる処理が実行され、当該タスクの実行後は再度「スリープモード」に戻るような状態も含む。例えば、ユーザが外出する際に、ゲーム装置1のハウジングを閉じて鞄に入れている状態は「非使用状態」である。更に、このように、ゲーム装置1が鞄に入れられてユーザが外出している間に、上記のように一時的に「スリープモード」が解除されている状態、および、タスクの実行後に再度「スリープモード」に入るような状態(この間、ユーザはゲーム装置1を使用していない)も「非使用状態」である。また、当該「使用状態」と「非使用状態」が切り替わるためのトリガは、ハウジングの開閉の他、電源ボタン14Fが操作された場合もトリガとなる。つまり、ユーザがゲームをプレイしていたが(使用状態)、その後、ゲームのプレイを終えたため、ゲーム装置1の電源ボタン14Fを押下することで、「使用状態」から「非使用状態」に切り替わる。その他、例えば、一定時間ユーザの操作がなかったために「使用状態」から「非使用状態」に切り替わる場合もある。
【0094】
以下の説明においては、説明の簡略化のため、電源制御モードについては、「通常電力モード」と「スリープモード」の2つのモードだけを用いる場合を例として説明する。
【0095】
また、ゲーム装置1は、マイク44およびアンプ45を備えている。マイク44およびアンプ45は、それぞれI/F回路43に接続される。マイク44は、ゲーム装置1に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をI/F回路43に出力する。アンプ45は、I/F回路43から音声信号を増幅してスピーカ(図示せず)から出力させる。I/F回路43は、CPU31に接続される。
【0096】
また、タッチパネル13は、I/F回路43に接続される。すなわち、I/F回路43は、マイク44およびアンプ45(スピーカ)の制御を行う音声制御回路と、タッチパネル13の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換した
りする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成してCPU31に出力する。例えば、タッチ位置データは、タッチパネル13の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル13からの信号の読み込み、および、タッチ位置データの生成を所定時間に1回の割合で行う。CPU31は、I/F回路43を介して、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われた位置を知ることができる。
【0097】
操作ボタン14は、上記各操作ボタン14A〜14Lから構成され、CPU31に接続される。操作ボタン14からCPU31へは、各操作ボタン14A〜14Lに対する入力状況(押下されたか否か)を示す操作データが出力される。CPU31は、操作ボタン14から操作データを取得することによって、操作ボタン14に対する入力に応じた処理を実行する。
【0098】
内側カメラ23および外側カメラ25は、それぞれCPU31に接続される。内側カメラ23および外側カメラ25は、CPU31の指示に応じて画像を撮影し、撮影した画像データをCPU31に出力する。本実施形態では、CPU31は、内側カメラ23および外側カメラ25のいずれか一方に対して撮影指示を行い、撮影指示を受けたカメラが画像を撮影して画像データをCPU31に送る。
【0099】
また、下側LCD12および上側LCD22は、それぞれCPU31に接続される。下側LCD12および上側LCD22は、それぞれCPU31の指示に従って画像を表示する。
【0100】
次に、本実施形態で想定する処理の概要について説明する。
[ネットワークの全体構成]
まず、本実施形態で想定するネットワークの全体的な構成について説明する。図3は、本実施形態にかかるネットワーク構成の全体像を示す模式図である。図3で示されるゲーム装置1は、大きく分けて2種類の通信態様を用いる。1つめの通信態様は、インターネットを利用する態様である「インターネット通信」である。2つめの通信態様は、インターネットは経由せず直接的にゲーム装置同士を無線接続する「ローカル通信」である。
【0101】
[インターネット通信]
まず、「インターネット通信」に関して説明する。「インターネット通信」では、上述したIEEE802.11準拠の方式でアクセスポイント(以下、APと呼ぶ)に接続し、これを介してインターネットに接続する。更に、インターネットを経由して、所定のサーバと通信を行う。
【0102】
本実施形態においては、上記APは大きく2つの種類に分けられており、図3でいうと、専用AP101と一般AP102の2種類に分けられる。本実施形態において、専用AP101とは、例えば、ゲーム装置1の製造元が管理するAPをいう。つまり、ゲーム装置1の製造元は、どの専用APがどの場所に設置されているかや、各専用APの機器構成等を把握、管理している。このような専用APは、例えば、家電量販店やファーストフード店等、特定の場所に設置される。対して、一般AP102は、本実施形態では、上記専用AP以外のAP全般を示す。例えば、ユーザの個人宅に設置されたAPや、上記ゲーム装置1の製造元以外の事業者等が設置したAP等が該当する。
【0103】
それぞれのAPには、いわゆるESSIDや自らが電波を発する周波数チャネルが予め設定され、各APが備えている記憶媒体(例えばフラッシュメモリ等)に記憶されている。また、専用AP101については、後述するベンダー特定情報が更に記憶されており、
この内容がビーコンに含まれて発信される。
【0104】
また、サーバの種類についても、本実施形態では2つに大別されており、図3では、ポリシーサーバ103と、その他一般サーバ104の2種類に分けられている。ポリシーサーバ103とは、「ポリシーデータ」と呼ばれるデータを取得するための専用サーバである。本実施形態において、ゲーム装置1は、当該ポリシーサーバ103から「ポリシーデータ」と呼ばれるデータを取得し、これに基づく処理を行うが、これら処理については詳細を後述する。一般サーバ104は、上記ポリシーサーバ103以外のサーバのことである。なお、各サーバはそれぞれ、CPU等の演算処理部、メモリやHDD等の記憶部、インターネットに接続するための通信部等を有している(図示は省略する)。
【0105】
なお、本実施形態で上記のような専用APを設けているのは、上記「ポリシーデータ」については、専用APに応じた「ポリシーデータ」を定義可能とするためである。つまり、特定のAPを経由してポリシーサーバにアクセスした場合に、接続に利用しているAP(ひいてはそのAPが設置されている場所等)に応じた「ポリシーデータ」を利用可能とするためである。
【0106】
[ローカル通信]
次に、もう一つの通信態様である「ローカル通信」に関して説明する。「ローカル通信」は、ゲーム装置1同士の間で直接接続を確立して通信を行う通信態様である。図3の例では、ゲーム装置1と、他のゲーム装置1との間の通信が「ローカル通信」に該当する。
【0107】
上記のようなネットワーク構成と通信態様で、本実施形態では、主に以下のような処理が実行される。まず、「インターネット通信」を用いる処理として、タスクを実行する処理がある。本実施形態におけるタスクは、所定のデータの送受信を伴う処理を示す。より具体的には、「送信タスク」と「受信タスク」の2種類に分類される。但し、以下では、これらを総称して単に、タスク、と称することもある。このように、本実施形態で言うタスクは、データの送信または受信を伴う処理であるため、当該タスクの内容を示すデータには、接続先となるサーバのURL等が含まれる。以下に、本実施形態における当該タスクの例をいくつか挙げる。まず、キャンペーン等のお知らせをネットワークサービスの提供者からユーザに通知することを目的とした「お知らせデータを受信する」というタスクがある。また、この「お知らせデータ」には、所定のネットワークサービスの終了を通知する旨を含めることも可能である。このような場合は、当該サービスの終了にかかるネットワークアプリに関するタスクは消去される。また、ゲームに関連する処理として、例えば、レースゲームの全国大会が、ある期間に行われる場合を想定する。この期間において、ユーザのレースデータを全国ランキングに定期的にエントリーすることを目的として、「レースデータの送信」や「現在のランキングデータの受信」というタスクがある(このような場合は、「送信タスク」と「受信タスク」の2つのタスクが実行される)。
【0108】
また、「追加コンテンツの確認」というタスクもある。これは、例えばRPGの追加シナリオ等が配信された場合を想定するタスクであり、このような「追加コンテンツの有無を示す情報の受信」というタスクがある。その結果、追加コンテンツがあれば、そのデータがダウンロードされる。
【0109】
また、その他のタスクとして、本実施形態では「インストールリストの取得」というタスクがある。当該タスクは、ゲーム装置1の出荷時設定として予め設定済みのタスクである。インストールリストには、例えば、システムデータや各アプリケーションやゲームプログラム(以下では、アプリケーション、ゲームを総称して単にアプリケーション、あるいは単にアプリと呼ぶ)のアップデートに関する情報、無料アプリケーション、新作アプリケーションの体験版の存在を示す情報等が含まれる。なお、このようなアップデートや
無料アプリ、体験版に関しては、本実施形態では、その存在の有無の確認のみならず、実際の更新データや体験版プログラムのダウンロードおよびインストール処理も実行される(このようなインストール処理の詳細は後述する)。
【0110】
このように、本実施形態におけるタスクは、所定のサーバに接続して所定のデータを送受信する処理であり、このようなタスクが適宜生成されて実行されるが、その実行タイミングに関しては、大きく分けると以下の3種類のタイミングがある。
(1)時間指定実行
(2)即時実行
(3)上記専用APが関連するときの実行
これら3種類のタイミングで行われる処理については後述する。
【0111】
次に、「ローカル通信」を用いた処理について説明する。上記のように、「ローカル通信」はゲーム装置1同士を無線接続して通信を行うものである。そのため、通信対戦型のゲーム等、様々な局面で利用されるが、本実施形態では、特に、後述する「すれ違い通信」と呼ばれる通信処理を前提として説明する。
【0112】
次に、上述した「インターネット通信」で実行されるタスクの3種類の実行タイミングおよびその処理概要について説明するが、この説明に先立って、上記タスクに関して設定される「実行優先度」というパラメータ、および、「消尽回数」というパラメータについて説明する。実行優先度は、そのタスクが実行される優先度を示すものであり、同タイミングに実行されるべき複数のタスクが存在する場合に、これらの実行順序を決定するために用いられる。本実施形態においては、実行優先度は5段階に分けて定義されている。具体的には、優先度の高いものから、”EXPEDITE”>”HIGH”>”MEDIUM”>”LOW”>”STOPPED”という順番であるとする。このうち、”EXPEDITE”は最も実行優先度が高いことを表す。また、"STOPPED"は、そのタスクを実行しないことを示す。つまり、タスク自体
は存在するが、実行させたくないような場合に”STOPPED”という実行優先度が用いられ
る。”HIGH”は、高優先度、”MEDIUM”は標準の優先度、”LOW”は低優先度であること
を示す。本実施形態では、基本的には、”HIGH”、”MEDIUM”、”LOW”の3つを用いて
タスクの実行優先度が設定される。残りの2つ”EXPEDITE”および”STOPPED”について
は、特殊な事情がある場合に利用される。例えば、ゲーム装置1のシステムアップデートを緊急で行いたいような場合は、システムアップデートに関するタスクを”EXPEDITE”として設定する。また、例えば、上述したようなレースゲームの全国大会が年に1回開催されると想定する。この場合に、全国大会の開催期間中は、ユーザのレースデータの送信やランキングデータの受信を行うタスクについて、上記”HIGH”、”MEDIUM”、”LOW”の
3つの実行優先度を用いて適宜設定する。一方、全国大会の期間が終了すれば、当該タスクについては”STOPPED”を設定することで、当該タスクの実行が停止される。その後、
1年後に再び全国大会が始まれば、当該タスクの実行優先度を”HIGH”、”MEDIUM”、”LOW”を用いて適宜設定することで、当該全国大会の期間中だけ当該タスクを実行させる
ことが可能である。
【0113】
次に、消尽回数について説明する。上記タスクが生成される際に消尽回数として所定の数値が初期値として設定される。当該消尽回数は、タスクが実行される毎に例えば1ずつ減算されていく。また、当該タスクに対応するゲーム等が起動される度に、消尽回数は初期値にリセットされる。そして、消尽回数が0になったタスクは(換言すれば、このようなタスクに対応するゲーム等が長期間実行されていないことを示すことになる)、上記実行優先度に関わらず実行されない(タスク自体は消去されずに存在する)。
【0114】
このように、本実施形態では、実行優先度や消尽回数というタスクの実行制御用のパラメータを用いてタスクの実行制御が可能である。また、これらの実行制御用パラメータは
、後述するポリシーデータによって変更可能となっている。
【0115】
以下、上記の実行優先度と消尽回数を踏まえて、「インターネット通信」で実行されるタスクの3種類の実行タイミングおよびその処理概要について説明する。
【0116】
[時間指定実行]
まず、時間指定実行は、上記タスクを生成するときに、その実行時刻を指定して生成する。そして、指定された時刻が到来したら、そのタスクが実行されるというものである。この時間指定実行は、「スリープモード」中であっても実行される。また、タスクの内容によっては、後述するようなインストール処理も実行されるものもある。そのため、本実施形態では、以下のような運用が可能となる。
【0117】
例えば、ゲーム装置1が通常電力モードのときにおいて、ユーザの操作等に応じて「新作無料ゲームの有無を確認する」という内容のタスクが生成されたとする(上記のように、確認先のサーバのURL情報もタスクのデータに含まれている)。このとき、当該タスクの実行予定時刻を15:00と指定して生成したとする。その後、ユーザがゲーム装置1の電源ボタン14Fを押して「スリープモード」に移行させ、当該ゲーム装置1を持って、例えば12:00頃に外出したとする。このとき、「スリープモード」に入る直前のゲーム装置1には、図4に示すようなメニュー画面が表示されていたものとする。
【0118】
その後、15:00になると、ゲーム装置1は、上記タスクの実行を試みる。すなわち、15:00になると、まず、CPU31およびメインメモリ32への電力供給を一旦再開する。そして、インターネットに接続するために、接続可能なAPをサーチを開始する。ここでは、予め設定画面などでESSID等を登録した一般AP102のサーチを行う。そして、接続可能なAPがあれば、当該APを経由して、上記ポリシーサーバ103に接続する。そして、「ポリシーデータ」をポリシーサーバから取得する。詳細は後述するが、当該ポリシーデータには、上記タスクの実行優先度を定義した情報、すなわち、タスクの実行制御のためのパラメータが含まれる。なお、一般APのそれぞれについて異なるポリシーデータを定義することは困難であるが、一般APに共通するポリシーデータを取得させることや、本体に設定されている国情報などによって異なるポリシーデータを取得させることもできる。その後、上記タスクに含まれるURL情報に従って、サーバに接続し、新作の無料ゲームの有無を示すデータを取得する。次に、当該データに基づいて新作の無料ゲームの有無を判定し、当該無料ゲームがあるときは、更に、当該無料ゲームのプログラムがアップされている所定のサーバへ接続する。そして、当該無料ゲームのデータを取得し、ゲーム装置1にインストールする。その後、CPU31への電力供給を停止する。その結果、例えば、18:00に自宅に帰ってきたユーザが当該ゲーム装置1の電源を入れる(スリープモードから通常電力モードへ移行させる)と、図5に示すように、新たにインストールされたアプリケーションがあることを示すプレゼントアイコン112が追加されているメニューが表示される。そして、ユーザが当該プレゼントアイコン112を選択して所定のボタンを押下すれば、プレゼント箱が開くアニメーション効果が表示された後、今回インストールされた新作の無料ゲームを示すアイコンが当該プレゼントアイコン112と置き換わって表示される。
【0119】
また、その他、本実施形態では次のような運用も可能である。例えば、インストール済みのゲームに関して、「追加コンテンツの有無を確認する」という旨のタスクが生成されたとする。その実行予定時刻は上記同様15:00であるとする、そして、上述したのと同様に、ユーザがゲーム装置1をスリープモードにして12:00頃に外出し、その後、15:00頃にこのタスクが実行されて、あるゲーム、ここでは、図4のアイコン111にかかるゲームの追加コンテンツ(例えば、RPGにおける追加シナリオ)がダウンロードされたとする。このような場合は、18:00に自宅に帰ってきたユーザが当該ゲーム
装置1をスリープモードから通常電力モードへ移行させると、図6に示すように、追加コンテンツの存在を示す「New!」のマークがアイコン111の近傍に表示される。これにより、アイコン111の表すゲームについて、何らかの新しいコンテンツが届いたことをユーザに知らせている。
【0120】
上記のような処理によって、ユーザが外出する前と外出から帰って来た後で、ゲーム装置1のメニューの構成を異なったものとすることが可能となる。
【0121】
もちろん、「通常電力モード」のときにおいても時間指定実行は可能である。例えば、上記ユーザが外出せずに、15:00頃は自宅でゲームをプレイしていたとしても、当該ゲームの処理と並行して(つまり、バックグラウンド処理として)上記のような無料ゲームの取得およびインストールを行っても良い。この場合は、ユーザがゲームのプレイを終えた後、メニュー画面に遷移が行われたときに、メニュー構成が変わっていること、つまり、知らない間にプレゼントアイコン112(つまり、何らかの新しいソフトウェア要素)がメニューに加わっていることに気付くことになる。
【0122】
なお、結果的に同時刻に複数のタスクが実行されるような状況になった場合は、上記実行優先度に基づき、各タスクの実行順序が適宜決定される。
【0123】
[即時実行]
次に、上記タスクの即時実行に関して説明する。即時実行は、ユーザの指示等に応じて即時にタスクが実行されるというものである。例えば、ユーザが手動で所定のタスクの実行を指示する操作を行うような場合である。
【0124】
[専用APが関連するときのタスク実行]
次に、専用APが関連するときのタスク実行に関して説明する。上記のように、「スリープモード」においても、無線通信モジュール34には電力は供給されているため、電源が完全に切断されない限りは、基本的に無線通信モジュールは常時稼働している。そのため、本実施形態では、無線通信モジュール34は、「通常電力モード」においても「スリープモード」においても、ビーコンのスキャン(いわゆるパッシブスキャン)を繰り返し行っている。ここで、上記専用AP101から発信されるビーコンには、そのAPが上記ゲーム装置1のメーカーが管理するものであることを示す情報が含まれている。例えば、IEEE802.11規格において定義される、上記ビーコンの情報要素の一つである"Vendor Specific"に、このような情報(以下、ベンダー特定情報と呼ぶ)が含まれる。そ
こで、本実施形態では、上記ビーコンの当該ベンダー特定情報を用いて、そのビーコンが上記専用APから発信されたものであるか否かを判別する。つまり、(ゲーム装置1を所持した)ユーザが上記専用AP101の近くに来ているか否かを判定する。その結果、専用AP101からのビーコンであることが判別されたときは、当該専用AP101との接続を確立し、更に、インターネットを経由して上記ポリシーサーバ103に接続する。そして、「ポリシーデータ」をポリシーサーバから取得する。詳細は後述するが、当該ポリシーデータには、上記タスクの実行優先度を定義した情報が含まれる。また、上述したように、本実施形態では、専用AP毎に異なるポリシーデータを定義することを可能としている。例えば、店舗Aに設置されている専用AP101からポリシーサーバ103に接続した場合は「ポリシーデータA」が取得され、例えば、店舗Bに設置されている専用AP101からポリシーサーバ103に接続した場合は「ポリシーデータB」が取得される。このとき、「ポリシーデータA」では、タスクの実行優先度が、例えば、「タスクA>タスクB」というような順となるように実行優先度に設定されており、「ポリシーデータB」では、「タスクB>タスクA」という実行優先度になるよう設定されているとする。その結果、ユーザが店舗Aにいるときと店舗Bにいるときとで、優先的に実行されるタスクが異なることになる。その結果、各店舗(正確には、各店舗に設置されている専用AP1
01)に応じたタスクの実行制御を行うことが可能となっている。さらに、専用AP101と本体に設定されている国情報などの情報の双方に基づいて異なるポリシーデータを取得させることもできる。
【0125】
また、本実施形態では、上記ポリシーデータには、消尽回数を変更するための情報も含まれることがある。このような情報が含まれている場合、例えば、消尽回数が0になったタスクに対して消尽回数が1に設定される。その結果、1度だけ当該タスクを実行させることも可能となる。
【0126】
このように、本実施形態では、ゲーム装置1を所持したユーザが専用AP101の近くに来れば、ゲーム装置1は上記ポリシーサーバ103からポリシーデータを取得する。そして、ポリシーサーバ103との接続に用いた専用AP101に応じて、当該ゲーム装置で実行されるタスクの実行優先度が変更可能である。これにより、上述のように、店舗に応じて優先的に実行されるタスク(ひいては、タスクの実行順序)に変化を与えることができる。また、その他、例えば、専用AP101が設置されている店舗Aにユーザが立ち寄ったときに、当該店舗Aに特有のデータ(例えば、その店舗の専用AP101経由でしか入手できないゲーム中のアイテム等)をダウンロードさせるようなタスクが最優先で実行されるようにすることが可能となる。また、消尽回数についても変更可能であるため、例えば、消尽回数が0になり、長期間実行されていないタスクが、ある店舗を訪れた際に復活して実行されるということが可能になる。そして、当該タスクの実行結果として何らかの通知を画面に表示することで、ユーザに驚きを与えたり、積極的に情報収集を行わないユーザに対して「気づき」を与えることが可能となる。その結果、例えば、長期間プレイされていなかったゲームを再度プレイしてもらうことへの動機付けをユーザに提供することが可能となる。
【0127】
上記のように、ゲーム装置1が「スリープモード」のときにも、上記のような「インターネット通信」およびタスクの実行(サーバとの間でデータの送受信)を行うことで、本実施形態では、本来は常時接続型の端末ではないゲーム装置1であるにもかかわらず、あたかも常時接続であるかのような振る舞いをユーザに見せることができる。その結果、ユーザは、主導的・積極的にネットワークへの接続操作等を行わずとも、各種通知や無料アプリなどの入手が可能となり、また、知らないうちにゲーム装置1のソフト構成が変化していることにより驚きと楽しみをユーザに提供する事が可能となる。
【0128】
次に、上記「ローカル通信」を利用した「すれ違い通信」の処理概要について説明する。図7図10は、当該「すれ違い通信」について説明するための図である。まず、本実施形態では、NANDフラッシュメモリ33内に「すれ違い通信」用のデータ領域が確保されている。図7は、このすれ違い通信用のデータ領域を示す模式図である。図7において、当該領域は複数の「スロット」の集合で構成されている。各スロットは、所定のアプリケーションまたはゲームと対応づけられている。この対応付けは、ユーザが所定の操作を行うことで、ユーザが任意で対応付け可能となっている。各スロットは、対応付けられているアプリまたはゲームを示すIDと送信用ボックス、受信用ボックスで構成されている。そして、「すれ違い通信」は、ゲーム装置1間で、自動的に繰り返しお互いをサーチし、お互いを検出した場合、自動的にこのボックス内のデータを送受信するものである。
【0129】
以下に一例を示す。例えば、ユーザAが自己の所有するゲーム装置Aにおいて、あるゲームAをプレイしたとする。その結果、当該ゲームAの処理において、「宝の地図その1」を示すデータが、ゲームAに対応付けられているスロットの送信用ボックスに格納される。更に、当該ユーザAが別のゲームBをプレイし、当該ゲームBの処理において、ゲーム中で利用可能な「傭兵」である「戦士」のデータがゲームBに対応付けられているスロットの送信用ボックスに格納される。図8は、このような、ユーザAのゲーム装置Aにか
かる格納状態を示す模式図である。
【0130】
同様に、ユーザBが自己の所有するゲーム装置BにおいてゲームAをプレイし、その結果、「宝の地図その3」を示すデータがゲームAに対応付けられているスロットの送信用ボックスに格納される。また、ユーザBがゲームBをプレイした結果、「魔術師」の傭兵データがゲームBに対応付けられているスロットの送信用ボックスに格納される。図9は、ユーザBのゲーム装置Bにおける格納状態を示す模式図である。
【0131】
以上のような格納状態を前提として、ユーザA、ユーザBが共に、それぞれの所有するゲーム装置を所持して外出したと仮定する。ゲーム装置はそれぞれ「スリープモード」に移行しているとする。また、共に「すれ違い通信」を行うことを許可する設定がなされているものとする。また、この「スリープモード」の間、ゲーム装置1はそれぞれ、「すれ違い接続要求」という信号(すれ違い通信用のビーコン)を周期的に発信している。図10は、このような前提における「すれ違い通信」を示す模式図である。図10において、ユーザAの出発点は地点Aであり、ユーザBの出発点は地点Cであるとする。その後、両者が地点Eに到達し、それぞれのゲーム装置がローカル通信可能な範囲まで接近したとする。このとき、一方のゲーム装置が発する「すれ違い接続要求」が他方のゲーム装置により受信され、これに基づいてゲーム装置同士の「ローカル通信」のための接続が確立される。そして、次のようなデータ交換が行われる。すなわち、ユーザAのゲーム装置Aにおける送信用ボックス内のデータが、ゲーム装置Bの、それぞれ対応するゲームのスロットの受信用ボックスに送信される。具体的には、ゲームAの「宝の地図その1」が、ゲーム装置BのゲームAに対応付けられたスロットの受信用ボックスに送信される。同様に、ゲーム装置AのゲームBの「戦士の傭兵データ」が、ゲーム装置BのゲームBのスロットの受信用ボックスに送信される。同様に、ゲーム装置Bからゲーム装置Aに向けて、「宝の地図その3」と「魔術師の傭兵データ」がそれぞれ対応するゲームのスロットの受信用ボックスに送信される。
【0132】
その結果、例えば、図10の地点Bで示されるように、「すれ違い通信」後のゲーム装置Aでは、ゲームAのスロットには、送信用ボックスに「宝の地図その1」、受信用ボックスには「宝の地図その3」が格納されている。また、ゲームBのスロットには、送信用ボックスに「戦士の傭兵データ」、受信用ボックスには「魔術師の傭兵データ」が格納されている。そして、ユーザAは、当該受信用ボックスに格納されたデータをそれぞれ対応するゲームにおいて利用することが可能となる。同様に、ゲーム装置Bについても、地点Dで示されるように、ゲーム装置Aから受信した「宝の地図その3」「戦士の傭兵データ」データが格納されており、ユーザBは、これらのデータをそれぞれ対応するゲームにおいて利用可能となっている。
【0133】
このように、本実施形態における「すれ違い通信」は、ゲーム装置1が「スリープモード」のときに、すれ違い通信用の記憶領域に格納されている所定のデータの送受信を「ローカル通信」を利用して行うものである。但し、通信対象となるアプリケーションについては、双方共に上記スロットに設定しているゲームタイトルに限る。例えば、上記ユーザBが、ゲームBのみ上記スロットに対応付けており、ゲームAについてはゲーム自体を所有していないような場合は、ゲームBに関するデータのみ送受信が行われ、ゲームAのデータの送受信は行われない。
【0134】
次に、ゲーム装置1において行われる上記のような処理の詳細を説明する。まず、本処理において用いられる主なプログラムおよびデータについて説明するが、この説明に先立ち、本実施形態における処理の実行主体に関して説明する。本実施形態では、マイコン37、無線通信モジュール34、CPU31が、それぞれ独立して、以下に説明する処理の実行主体となり、これらの処理が互いに連携しながら並列的に実行される。主な処理内容
の分担を説明すると、マイコン37は、主に、ゲーム装置1の開け閉めの検知や電源制御モードの切替制御、タスク実行時刻の時間管理等に関する処理を担当する。無線通信モジュール34は、主に、すれ違い通信の実行開始条件の監視や、インターネット通信に際しての、APからのビーコンのスキャン等の処理を担当する。CPU31は、主に、上記マイコン37、無線通信モジュール34の担当する処理以外の処理全般を担当する。例えば、アプリケーションの実行、タスクの実行などである。
【0135】
ここで、以下の説明の一助のために、図11に、本実施形態で実行される各種機能(プログラム)の相関関係を示す。図11では、マイコン37が実行するマイコン処理と、無線通信モジュール34が実行する無線モジュール処理と、CPU31が実行する起動時処理とが並列して実行可能であることを示す。図11の各要素は、後述する図12図14で示される各種プログラムに対応する。図11において、例えば、マイコン37が実行する「マイコン処理」というプログラムにおいて、「ローカル通信用BG(BackGround)処理」が呼び出されて実行されることが示されている。更に、当該「ローカル通信用BG処理」においては、「インターネット通信用BG処理」が呼び出されて実行されることを示す。また、当該「ローカル通信用BG処理」は、無線通信モジュール34が実行する「無線モジュール処理」においても呼び出されることがあり、CPU31が実行する起動時処理においても呼び出されることがあることが示されている。
【0136】
以下、本処理において用いられる主なプログラム、データについて説明する。図12は、マイコン37に内蔵されている記憶領域(図示せず)に記憶される主なデータを示す図である。マイコン37内部には、プログラム領域301とデータ領域303が存在し、プログラム領域301には、上記のようなマイコン37が担当する処理を実行するためのマイコン処理プログラム302が記憶され、データ領域303には、給電状態フラグ304、次回起床時刻305が記憶される。給電状態フラグ304は、「スリープモード」であるか否かを示すためのフラグである。オンに設定されているときは「通常電力モード」、オフに設定されているときは、「スリープモード」であるとする。次回起床時刻305は、「スリープモード」を解除する時刻を示すデータである。基本的には、各タスクに設定される次回実行時刻のうち、最も早い時刻が次回起床時刻305として設定されることになる。但し、後述するように、現在の時刻から次回の実行時刻までの時間が短すぎる場合や長すぎる場合には、若干の調整が行われる。
【0137】
図13は、無線通信モジュール34に内蔵されている記憶領域(図示は省略)に記憶される主なデータを示す図である。無線通信モジュール34内の記憶領域には、プログラム領域401とデータ領域403が存在し、プログラム領域401には、上記のような無線通信モジュール34が担当する処理を実行するための無線モジュール処理プログラム402が記憶され、データ領域403には、専用AP識別情報404、既通信端末/専用AP情報405、抽出アプリID406が記憶される。
【0138】
専用AP識別情報404は、上記専用AP101を識別するための文字列である。上述したビーコンに含まれるベンダー特定情報と、当該専用AP識別情報404とが照合されることで、専用AP101か否かの判定が可能となる。既通信端末/専用AP情報405は、短期間内で同じ通信相手と連続して通信を行わないようにするための情報である。具体的には、所定の通信相手と通信が行われると、当該通信を行った相手のMACアドレスおよび通信時刻が既通信端末/専用AP情報405として、所定期間、記憶される(複数台分記憶可能である)。ここに記憶されている通信相手については、その存在が検知されても、通信が行われないように制御される。これにより、同じ通信相手と立て続けに通信を繰り返すことを避けることができる。
【0139】
抽出アプリID406は、後述するすれ違い通信用データ520のアプリID522を
抽出して記憶したデータである。このデータは、上記のような「すれ違い通信」の対象となるアプリケーションやゲームを示すものである。
【0140】
図14は、NANDフラッシュメモリ33に記憶されるプログラム、データを示す図である。なお、これらのデータは、必要に応じてメインメモリ32に展開されて実行される。NANDフラッシュメモリ33は、プログラム領域500とデータ領域510を有しており、プログラム領域500には、メニュー処理プログラム501、タスク生成処理プログラム502、ローカル通信BG処理プログラム503、インターネット通信BG処理プログラム504、ポリシー処理プログラム505、タスク実行処理プログラム506、実行順ソート処理プログラム507、インストール処理プログラム508、および、複数のアプリケーションプログラム509等が記憶される。
【0141】
メニュー処理プログラム501は、本体メニューに関する処理を実行するためのプログラムである。タスク生成処理プログラム502は、各タスクを生成するためのプログラムである。
【0142】
ローカル通信BG処理プログラム503およびインターネット通信BG処理プログラム504は、上記「ローカル通信」や「インターネット通信」に関する処理を実行するためのプログラムである。
【0143】
ポリシー処理プログラム505は、上記「ポリシーデータ」の取得やこれに基づくタスクの優先度変更等の処理を実行するためのプログラムである。タスク実行処理プログラム506は、各タスクを実行するためのプログラムであり、実行順ソート処理プログラム507は、当該タスクの実行に際して、その実行順序を決定するためのプログラムである。インストール処理プログラム508は、ゲームの体験版や無料アプリケーションをインストールしたり、システムのアップデートに関する処理を行うためのプログラムである。
【0144】
アプリケーションプログラム509は、例えばゲームなどの各種アプリケーションを実行するためのプログラムである。なお、ここでは便宜上「プログラム」と示しているが、当該アプリケーションの実行で用いられるデータの一部についても当該アプリケーションプログラムに含まれるものとする。
【0145】
次に、データ領域510について説明する。データ領域510には、すれ違い通信用データ520、タスクデータ530、アプリ関連データ550、本体設定データ560、受信ポリシーデータ570、インストールリスト580、ダウンロードリスト590、オン・ザ・フライ用キャッシュ600が記憶される。
【0146】
すれ違い通信用データ520は、上述したような「すれ違い通信」において送受信するためのデータである。図15は、すれ違い通信用データ520のデータ構造の一例を示した図である。すれ違い通信用データ520は、スロット521の集合から構成される。各スロット521は、アプリID522、送信用ボックス523、受信用ボックス524から構成される。アプリID522は、当該スロット521に対応付けられているアプリケーションやゲームを特定するためのIDである。送信用ボックス523には、「すれ違い通信」において他のゲーム装置1に送信するためのデータが格納される。受信用ボックス524には、「すれ違い通信」において他のゲーム装置1から受信したデータが格納される。
【0147】
図14に戻り、タスクデータ530は、本実施形態において実行されるタスクの内容について定義したデータである。図16は、タスクデータ530のデータ構造の一例を示した図である。タスクデータ530は、複数のタスク設定531が格納される。各タスク設
定531は、アプリID532、タスクID533、実行優先度534、通信先URL535、ファイルパス536、次回実行時刻537、実行間隔538、送信/受信識別フラグ539、消尽回数540、未処理フラグ541、一時変更フラグ542、タスクリビジョン543、前回完了時刻544、タスク登録時刻545等から構成される。
【0148】
アプリID532は、そのタスクに関連するアプリケーションやゲーム(典型的には、当該タスクの作成元になったアプリケーションやゲーム)を示すIDである。タスクID533は、当該タスクを識別するためのIDである。
【0149】
実行優先度534は、当該タスクの実行優先度を示すデータであり、上述したような”EXPEDITE”、”HIGH”、”MEDIUM”、”LOW”、”STOPPED”を示す情報が格納される。
【0150】
通信先URL535は、当該タスクの通信先(典型的には、データのアップロード先、あるいはダウンロード元のサーバ)を示す。ファイルパス536は、上記アップロードあるいはダウンロードするデータのゲーム装置1内における保存場所を示すデータである。つまり、上記通信先に対してアップロードするデータが存在するゲーム装置1内の場所、あるいは、ダウンロードしたデータを格納するゲーム装置1内での場所を示すデータである。
【0151】
次回実行時刻537は、当該タスクが次に実行されるべき時刻を示すデータである。実行間隔538は、当該タスクの実行間隔を示すデータである。例えば、1日毎、3日毎、1週間毎、等を示すデータが格納される。上記次回実行時刻537の決定の際に、当該実行間隔538が用いられる。
【0152】
送信/受信識別フラグ539は、そのタスクが所定のデータを送信する「送信タスク」であるか、所定のデータを受信する「受信タスク」であるかを示すフラグである。例えば、当該フラグがオンに設定されていれば「受信タスク」であり、オフに設定されていれば「送信タスク」であることを示す。
【0153】
消尽回数540は、上述したような当該タスクの消尽回数である。この回数が0になったタスクは、実行優先度534の内容に関わらず実行されない。未処理フラグ541は、当該タスクが実行されたか否かを示すフラグであり、オンに設定されていれば実行済み、オフに設定されていれば未実行であることを示す。一時変更フラグ542は、タスクの実行優先度534が後述のポリシーデータに基づいて変更された際に、その優先度の変更が一時的なものか否かを示すフラグである。
【0154】
タスクリビジョン543は、当該タスクに適用されたポリシーの最終のリビジョンを示すデータである。前回完了時刻544は、当該タスク設定531にかかるタスクが最後に実行されて正常に完了した時刻を示すデータである。タスク登録時刻545は、当該タスク設定531が一番最初に生成・登録された時刻を示すデータである。
【0155】
図14に戻り、次に、アプリ関連データ550は、ゲーム装置1にインストールされている各種アプリに関連するデータである。図17は、アプリ関連データ550のデータ構造の一例を示した図である。アプリ関連データ550には、複数のアプリケーション領域551が含まれている。各アプリケーション領域551には、アプリID552、タスク受信キャッシュ553、新規インストールフラグ554、セーブデータ555、が記憶される。アプリID552は、当該アプリケーション領域551に対応するアプリケーションを示すためのIDである。タスク受信キャッシュ553は、上記「受信タスク」が実行された結果、受信したデータが格納される領域である。そのため、「受信タスク」の場合は、上記タスク設定531のファイルパス536で当該タスク受信キャッシュ553の位
置を示す情報(例えばアドレス)が、示される。
【0156】
新規インストールフラグ554は、当該アプリが新規にインストールされたアプリケーションか否かを示すフラグである。当該フラグがオンに設定されていれば、上記アプリIDで示されるアプリケーションが新規にインストールされたアプリケーション(例えば、新作ゲームの体験版や、新作の無料アプリケーション等)であることを示す。
【0157】
セーブデータ555は、当該上記アプリID552で示されるアプリケーションに関するセーブデータであり、タスク送信用データ556、タスク受信データ557、すれ違い受信データ558で構成されている。その他、例えば、当該アプリケーションがゲームであれば、プレイヤキャラクタのデータやゲームの進行を示すデータ等も含まれる。
【0158】
タスク送信用データ556は、「送信タスク」において送信されるべきデータである。当該データの場所を示す情報(例えばアドレス)が、上記タスク設定531のファイルパス536で示される。タスク受信データ557は、上記タスク受信キャッシュ553のデータが、当該アプリケーションの実行に際してコピーされるものである。その結果、セーブデータ555の一部として扱われ、当該アプリケーションの処理において利用可能となる。すれ違い受信データ558も同様に、当該アプリケーションの実行に際して上記すれ違い通信用データ520の受信用ボックス524からコピーされるものである。
【0159】
図14に戻り、本体設定データ560は、ゲーム装置1に登録される各種設定等のデータである。例えば、ユーザの氏名や年齢、国情報のユーザ情報が含まれる。また、例えばユーザの自宅に設置したAPのESSID(Extended Service Set Identifier)やパス
ワード等のネットワーク設定等も含まれる。このネットワーク設定については、ゲーム装置1においてネットワーク設定のための処理が適宜実行されることで、ユーザの操作に応じて適宜設定され、記憶される。また、このネットワーク設定には、上記ユーザの設定によるものの他、出荷時設定として予め設定されている所定のプロバイダのAPのESSID等(例えば、公衆無線LANスポット等)も含まれる。その他、ゲーム装置1のシステムソフトウェアの最終更新日時等も記憶される。
【0160】
受信ポリシーデータ570は、上述したようなポリシーサーバ103から受信したポリシーデータである(そのため、ポリシーサーバ103に記憶されているポリシーデータの構造も、当該受信ポリシーデータ570と同様である)。図18は、受信ポリシーデータ570のデータ構造の一例を示した図である。受信ポリシーデータ570は、ポリシーリビジョン571、ポリシー更新日時572、AP情報573、および、複数のポリシー設定574から構成される。
【0161】
ポリシーリビジョン571は、当該受信ポリシーデータ570のリビジョンを示すデータである。ポリシー更新日時572は、当該ポリシーデータが更新された日時(ポリシーサーバにアップされた日時)を示すデータである。AP情報573は、当該受信ポリシーデータ570と関連づけられているAPを示す情報である。
【0162】
ポリシー設定574は、実行優先度等を変更する対象となるタスクとその変更内容について定義したデータである。各ポリシー設定574は、アプリID575、タスクID576、実行優先度577、タスク永続性578から構成されている。アプリID575は、ポリシーデータの適用対象となるアプリケーションを示すIDである。タスクID576は、ポリシーデータの適用対象となるタスクを示すデータであり、上記タスクデータ530のタスクID533を個別に指定するほか、例えば「全てのタスク」のように、総称的な指定や複数のタスクをまとめて指定することを示すデータが格納されることもある。
【0163】
実行優先度577は、変更後の実行優先度を示す。タスク永続性578は、今回の変更が一時的な変更であるか永続的な変更であるかを示すフラグである。オンに設定されていれば、永続的な変更であることを示す。
【0164】
図14に戻り、次に、インストールリスト580は、システムのアップデートや体験版アプリのインストール等、何らかのアプリのインストールが必要な場合に、そのインストール内容を示すためのデータである(インストール内容のインデックス的なものである)。ここで、本実施形態では、当該「インストールリストの取得」というタスクが、ゲーム装置1の出荷時の初期設定の一つとして予め上記タスクデータ530に登録されている。また、当該初期設定型のタスクであることを示すために予め定められた値が上記タスクID533として定義されている。本実施形態においては、当該インストールリスト580は、ゲーム装置1のシステム的な機能の一環として、定期的に取得されるものとする。
【0165】
図19は、インストールリスト580のデータ構造の一例を示した図である。図19において、インストールリスト580は、最新システム更新日時581、リストリビジョン582、AP情報583、および、複数のアプリ情報584から構成されている。
【0166】
最新システム更新日時581は、現在インターネットを介してゲーム装置1またはシステムプログラムを製造するメーカーから提供される、ゲーム装置1のシステムプログラムの最新の更新日時を示すデータである。ここで示されているデータと、ゲーム装置1に記憶されているシステムソフトウェアの最終更新日時とが一致するか否かで、システムアップデートの必要性が判定される。また、リストリビジョン582は、当該インストールリスト580のリビジョン(バージョン)を示す。
【0167】
AP情報583は、当該インストールリスト580に関連づけられたAPを示す情報である。つまり、上記ポリシーデータと同様に、インストールリスト580もAP毎に異なる内容のものを定義可能である。
【0168】
アプリ情報584は、インストール対象となりうるアプリケーションに関して定義したデータである、各アプリ情報584は、アプリID585、アプリバージョン586、アプリ種別587、レーティング情報588から構成される。
【0169】
アプリID585は、インストールされるアプリを識別するためのIDである。アプリバージョン586は、インストールされるアプリケーション等のバージョンを示す。アプリ種別587は、そのインストールにかかるアプリケーションの種別を示すデータである。例えば、システムプログラムであるか、体験版であるか、無料アプリであるか、等が示される。レーティング情報588は、そのインストールにかかるアプリのレーティング(対象年齢)を示す情報である。本体設定データ560に含まれるユーザの年齢情報等に応じて、実際にインストールを行うか否かが決定される。
【0170】
図14に戻り、ダウンロードリスト590は、上記インストールリスト580と上記レーティング情報等に基づいて、実際にゲーム装置1にインストールすべきものを抽出してリストアップしたデータである。図20は、ダウンロードリスト590のデータ構造の一例を示した図である。図20において、ダウンロードリスト590は、複数の案件情報591で構成される。また、各案件情報591は、アプリID592、アプリ種別593、インストール優先度594から構成されている。アプリID592およびアプリ種別593は、上記インストールリスト580のアプリID585およびアプリ種別587がコピーされたものである。インストール優先度594は、実際にインストールを行う際の処理順序を決めるためのデータである。
【0171】
図14に戻り、オン・ザ・フライ用キャッシュ600は、ゲーム装置1のシステムアップデートが実行される際に、システムアップデート用のデータを展開するための領域である。本実施形態では、システムアップデート用のデータは、圧縮ファイルとしてサーバにアップロードされる。そして、ゲーム装置1は、システムアップデートの処理を行う際は、当該圧縮ファイルをダウンロードするのと並行して、いわゆるオン・ザ・フライで当該圧縮ファイルの展開が行われる。この展開先が、当該オン・ザ・フライ用キャッシュ600である。また、ここに展開されるときのアップデート用のファイル名は、実際のシステムデータのファイル名と異なった名前で展開されるものとする。例えば、実際のシステムデータのファイル名が「firmware.bin」であるとすると、オン・ザ・フライ用キャッシュ600に展開されるアップデート用データのファイル名は、例えば、「firmware.upd」として展開される。
【0172】
次に、ゲーム装置1によって実行される上記のような処理の詳細について説明する。以下では、まず最初にマイコン37が行う処理について説明し、次に、無線通信モジュール34が行う処理について説明し、その後、CPU31が行う処理について説明する。
【0173】
[マイコン37が実行する処理]
図21は、マイコン37によって実行されるマイコン処理を示すフローチャートである。図21で示される処理は、ゲーム装置1の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。
【0174】
図21において、まず、ステップS1で、ゲーム装置1が上記「スリープモード」であるか否かが判定される。具体的には、上記給電状態フラグ304が参照されることによって「スリープモード」か否かが判定される。当該判定の結果、「スリープモード」であると判定されたときは(ステップS1でYES)、次に、ステップS2において、起床時刻(スリープモードを解除すべき時刻)が到来したか否かが判定される。具体的には、マイコン37内のRTC39が、マイコン37内の記憶領域にある次回起床時刻305と現在時刻とを比較することにより判定される。当該判定の結果、起床時刻が到来したと判定されなかったときは(ステップS2でNO)、後述のステップS6に処理が進められる。一方、起床時刻が到来したと判定されたときは(ステップS2でYES)、ステップS3において、「スリープモード」を解除し、「通常電力モード」に移行させるための命令がマイコン37からCPU31に対して発行されるとともに、給電状態フラグ304をオンにし、かつ、電源管理IC41にスリープを解除する旨を通知する。なお、ここでは「通常電力モード」に移行させる場合を例にしたが、この他、上述したようなLCDへの電源は供給しない「モニタオフモード」に移行させてもよい。つまり、CPU31に電力を供給する電源制御モードであればよい。
【0175】
次に、ステップS4において、CPU31によって、ローカル通信用BG処理が実行される。当該処理の詳細については後述するが、ここで行われる処理概要を簡単に説明する。この流れにおけるローカル通信用BG処理においては、結果的には、上記「インターネット通信」による、一般AP102およびインターネットを介した所定のサーバへの接続、および、上記タスクの実行が行われる。また、必要に応じて、インストール処理も実行されることになる。そして、当該ローカル通信用BG処理が終われば、後述するステップS6に処理が進められる。
【0176】
一方、上記ステップS1の判定の結果、ゲーム装置1が「スリープモード」ではない(つまり、「通常電力モード」で動作中)と判定されたときは(ステップS1でNO)、次に、ステップS5において、上記次回起床時刻305や上記タスクデータ530の次回実行時刻537が参照されて、起床時刻、もしくは、タスクの実行予定時刻であるスケジュール時刻が到来したか否かが判定される。当該判定の結果、いずれかの時刻が到来したと
判定されたときは(ステップS5でYES)、上記ステップS4に処理が進められる。一方、いずれの時刻も到来していないと判定されたときは(ステップS5でNO)、ステップS6に処理が進められる。
【0177】
次に、ステップS6において、ゲーム装置1が閉状態(ハウジングが閉じられている状態)から開状態(ハウジングが開かれた状態)に移行したか否か(つまり、ゲーム装置1が開かれたか否か)が判定される。具体的には、マイコン37は、開閉検出器40からハウジングが開かれたことを示す検出信号があったか否かを判定する。当該判定の結果、閉状態から開状態に移行したと判定されたときは(ステップS6でYES)、次のステップS7において、「スリープモード」を解除するための命令がマイコン37からCPU31に発行されるとともに、給電状態フラグ304をオンにし、かつ、電源管理IC41に、スリープを解除する旨を通知する。続くステップS8において、「スリープモード」から復帰したこと(解除されたこと)を示す旨がマイコン37から電源制御IC41に通知される。これに応じて、電源管理IC41は、適宜、ゲーム装置1の各構成部品への電力供給を開始する。
【0178】
一方、ステップS6の判定の結果、ゲーム装置1が閉状態から開状態に移行していないと判定されたときは(ステップS6でNO)、次に、ステップS9において、ゲーム装置1が開状態から閉状態に移行したか否か(つまり、ゲーム装置1が閉じられたか否か)が開閉検出器40からの信号により判定される。その結果、ゲーム装置1が開状態から閉状態に移行したと判定されたときは(ステップS9でYES)、次のステップS10において、「スリープモード」に移行させるための命令がマイコン37からCPU31に発行されるとともに、給電状態フラグ304をオフにし、かつ、電源管理IC41に、スリープに移行する旨を通知する。更に、続くステップS11において、「スリープモード」に移行する旨の通知がマイコン37から電源管理IC41に対して発行される。これに応じて、電源管理IC41は、適宜、ゲーム装置1の各構成部品への電力供給を停止する。一方、ステップS9の判定の結果、ゲーム装置1が開状態から閉状態に移行していないと判定されたときは(ステップS9でNO)、上記ステップS10およびS11の処理がスキップされて、マイコン処理は終了する。
【0179】
[無線通信モジュール34が実行する処理]
次に、無線通信モジュール34で実行される無線モジュール処理について説明する。図22図23は、当該無線モジュール処理を示すフローチャートである。図22で示される処理も上記マイコン処理と同様に、ゲーム装置1の電源が完全に切断されない限り、バックグラウンド処理として所定間隔で繰り返し実行される。
【0180】
図22で、まずステップS21において、上記無線通信モジュール34内の記憶領域の既通信端末/専用AP情報405が参照されて、前回の通信から所定時間経過したMACアドレスが記憶されているか否かが判定される。上述したように、既通信端末/専用AP情報405には最終な通信時刻が記憶されているため、この時刻と現在時刻とを比較することで、所定時間が経過したMACアドレスの有無が判定される。
【0181】
当該判定の結果、前回の通信から所定時間経過しているMACアドレスが記憶されていると判定されたときは(ステップS21でYES)、ステップS22において、当該条件を満たすMACアドレスおよびこれと関連づけられている最終の通信時刻のデータが既通信端末/専用AP情報405から削除される。そして、ステップS23に処理が進められる、一方、前回の通信から所定時間経過しているMACアドレスが記憶されていないと判定されたときは(ステップS21でNO)、上記ステップS22の処理はスキップされ、次のステップS23に処理が進められる。
【0182】
ステップS23において、「すれ違い接続要求」がブロードキャスト送信される。この「すれ違い接続要求」とは、上記すれ違い通信用データ520に何らかのデータが記憶されているときに、上述したような「すれ違い通信」を希望していることを他のゲーム装置1に知らせるための要求信号である。当該信号には、自身のMACアドレスが含まれる。更に、抽出アプリID406で示されるアプリIDも含まれている。つまり、データの送受信対象となる(送受信を希望する)アプリケーションを示すデータが含まれて、「すれ違い接続要求」がブロードキャストされている。
【0183】
次に、ステップS24において、「すれ違い接続応答」を受信したか否かが判定される。当該「すれ違い接続応答」とは、上記ステップS23でブロードキャスト送信した「すれ違い接続要求」を受信した他のゲーム装置1からの応答信号である。当該応答信号を受信したということは、この応答信号を返してきた他のゲーム装置1と「ローカル通信」の接続確立が可能であることを示す。当該判定の結果、他のゲーム装置1からの「すれ違い接続応答」を受信したと判定されたときは(ステップS24でYES)、次に、ステップS25において、互いのゲーム装置1において送受信対象として登録されているアプリケーションが一致するか否かが判定される。具体的には、上記受信した「すれ違い接続応答」に含まれているアプリIDと、上記抽出アプリID406とが照合される。そして、少なくとも1つ以上、一致するアプリIDがあるか否かが判定される。
【0184】
当該判定の結果、一致するアプリIDが1つもないと判定されたときは(ステップS25でNO)、「すれ違い通信」は行われずに、無線モジュール処理は終了する。一方、一致するアプリIDが少なくとも1つ以上あると判定されたときは(ステップS25でYES)、当該アプリIDに関するすれ違い用データの送受信を行うための処理が実行される。具体的には、まず、ステップS26において、ゲーム装置1が「スリープモード」であるか否かが判定される。ここで、スリープ中か否かを判別するための給電状態フラグ304はマイコン37内に存在し、また、無線モジュール34とマイコン37はCPU31を介して接続されているため、スリープ中でCPUに通電が行われていない状態では、無線モジュール34は、給電状態フラグ304にアクセスする事ができない。このため、給電状態フラグ304にアクセスすることができないという結果をもって、スリープ中であるという判別が可能である。その結果、「スリープモード」であれば(ステップS26でYES)、ステップS27において「スリープモード」を解除するための命令がCPU31に発行される。また、ここでは、CPU31に電力を供給するモードであればよいので、上述の「モニタオフモード」に移行してもよい。そして、ステップS28において、ローカル通信用BG処理が実行される。一方、ゲーム装置1が「スリープモード」ではないと判定されたときは(ステップS26でNO)、「通常電力モード」で稼働していると考えられるため、上記ステップS27の処理はスキップされて、ステップS28に処理が進められる。
【0185】
ステップS28においては、CPU31によって、ローカル通信用BG処理が実行される。この処理の詳細は後述するが、この流れでのローカル通信用BG処理での処理概要を簡単に説明すると、結果的に、「ローカル通信」を用いたすれ違い通信用データ520の送信が行われ、その後、受信が行われることになる。そして、当該ローカル通信用BG処理が終われば、無線モジュール処理も終了する。
【0186】
一方、上記ステップS24の判定の結果、自身がブロードキャストした要求信号に対する「すれ違い接続応答」を受信したと判定されなかったときは(ステップS24でNO)、次に、ステップS29において、他のゲーム装置1からの「すれ違い接続要求」を自身が受信したか否かが判定される。当該判定の結果、他のゲーム装置1から送られた「すれ違い接続要求」を受信したと判定されたときは(ステップS29でYES)、次のステップS30において、上記既通信端末/専用AP情報405が参照され、送信元のMACア
ドレスが記憶されているか否かが判定される。つまり、直近の時間において「すれ違い通信」を済ませた相手からの「すれ違い接続要求」か否かが判定される。当該判定の結果、送信元のMACアドレスが既通信端末/専用AP情報405に記憶されていると判定されたときは(ステップS30でYES)、当該送信元との通信は行わずに、無線モジュール処理は終了する。
【0187】
一方、送信元のMACアドレスが既通信端末/専用AP情報405に記憶されていないと判定されたときは(ステップS30でNO)、ステップS31において、上記ステップS25と同様に、「すれ違い通信」の対象として登録しているアプリのうち、一致するアプリIDが存在するか否かが判定される。当該判定の結果、一致するアプリIDがないと判定されたときは(ステップS31でNO)、当該送信元との通信は行わずに、無線モジュール処理は終了する。一方、一致するアプリIDが少なくとも1つ以上あると判定されたときは(ステップS31でYES)、ステップS32において、ステップS26と同様に、ゲーム装置1が「スリープモード」であるか否かが判定される。その結果、「スリープモード」であれば(ステップS32でYES)、ステップS33において、ステップS27と同様に、「スリープモード」を解除するための命令がCPU31に発行される。そして、ステップS34において、ローカル通信用BG処理が実行される。一方、ゲーム装置が「スリープモード」ではないと判定されたときは(ステップS32でNO)、既に「通常電力モード」で稼働していることになるので、上記ステップS33の処理はスキップされて、ステップS34に処理が進められる。
【0188】
ステップS34においては、上記ステップS28同様にローカル通信用BG処理が実行されるが、この場合の処理概要としては、すれ違い通信用のデータの送信が行われ、その後、受信が行われることになる(上記ステップS28の場合とは、送信と受信の順番が逆になる)。
【0189】
次に、上記ステップS29において、「すれ違い接続要求」も受信していないと判定されたときの処理(ステップS29でNO)について説明する。この場合は、専用AP101が近くに存在するか否かの判定、及び、存在する場合は専用AP101との通信を行うための処理が実行される。具体的には、図23のステップS35において、まず、アクセスポイントから発せられるビーコンのスキャンが行われる。いわゆる「パッシブスキャン」である。ここで、本実施形態では、専用AP101との通信に用いる通信チャネルは予め決められているものとする。そのため、この処理では、スリープモード移行時に当該通信チャネルを設定してから移行することで、CPU31を起動せずとも、パッシブスキャンを行うことが可能である。
【0190】
次に、ステップS36において、上記スキャンの結果、専用AP101から送信されたビーコンを受信したか否かが判定される。具体的には、無線モジュール内の記憶領域に記憶されている専用AP識別情報404が、上記スキャンで得られた受信したビーコンのベンダー特定情報に含まれているか否かが判定される。当該判定の結果、専用AP101からのビーコンを受信したと判定されなかったときは(ステップS36でNO)、当該無線モジュール処理は終了する。
【0191】
一方、専用APからのビーコンを受信したと判定されたときは(ステップS36でYES)、ステップS37において、当該ビーコンの送信元の専用AP101のMACアドレスが、既通信端末/専用AP情報405に記憶されているか否かが判定される。つまり、直近において既に通信済みの専用AP101からのビーコンであるか否かが判定される。当該判定の結果、既通信端末/専用AP情報405に記憶されていると判定されたときは(ステップS37でYES)、当該無線モジュール処理は終了する。
【0192】
一方、既通信端末/専用AP情報405に記憶されていないと判定されたときは(ステップS37でNO)、次に、ステップS38において、ステップS26やステップS32と同様に、ゲーム装置1が「スリープモード」か否かが判定される。その結果、「スリープモード」であると判定されたときは(ステップS38でYES)、ステップS39において、ステップS27やステップS33と同様に、「スリープモード」を解除するための命令がCPU31に発行される。そして、ステップS40において、ローカル通信用BG処理が実行される。一方、ゲーム装置が「スリープモード」ではないと判定されたときは(ステップS38でNO)、上記ステップS39の処理はスキップされて、ステップS40に処理が進められる。
【0193】
ステップS40においては、上記ローカル通信用BGプロセスが実行される。当該処理の詳細は後述するが、この流れにおいて実行される内容を簡単に説明すると、結果的に、専用AP101を介してポリシーサーバ103に接続する処理や、ポリシーデータに基づくタスクの優先度の変更処理等が実行され、また、各種タスクが実行されることになる。そして、当該ローカル通信用BGプロセスが終われば、当該無線モジュール処理は終了する。
【0194】
[CPU31が実行する処理]
以下、CPU31が実行する処理に関して説明する。
【0195】
[起動時処理]
図24図25は、ゲーム装置1が起動されたときに実行される起動時処理の詳細を示すフローチャートである。購入後のゲーム装置1が最初に起動されると、このフローチャートの処理が開始される。その後、電源が完全に切断されない限りは、図24に示すステップS62〜S74の処理ループがバックグラウンド処理として繰り返し実行される。例えば、ゲーム処理等が実行されているときでも、バックグラウンド処理として図24図25に示すフローチャートの処理が並列的に実行されている(主に、ゲーム処理中等にホームボタン14Iが押下されることの監視や、そのときの割り込み処理のためである)。
【0196】
図24において、まず、ステップS61で、メニュー処理が実行される。この処理の詳細は後述するが、その処理概要を簡単に説明しておくと、メニュー画面の表示に関する処理と、メニュー画面においてユーザによって選択されたアプリケーションの起動・実行処理等が行われる。
【0197】
次に、ステップS62において、「スリープモード」の解除指示を受けたか否かが判定される。具体的には、以下のような場合に、「スリープモード」の解除指示を受けたと判定される。
(1)「スリープモード」において、「すれ違い接続要求」または「すれ違い接続応答」を受信し、上記無線通信モジュール34からスリープ解除の指示を受けたとき(上記図22のステップS27あるいはステップS33)。
(2)「スリープモード」において専用AP101からのビーコンを受信し、無線通信モジュール34からスリープ解除の指示を受けたとき(上記図23のステップS39)。
(3)マイコン37(RTC39)が次回起床時刻の到来を検知し、マイコン37からスリープ解除の指示を受けたとき(上記図21のステップS3)。
(4)ゲーム装置1が閉状態から開状態に変化し、マイコン37からスリープ解除の指示を受けたとき(上記図21のステップS7)。
【0198】
当該判定の結果、スリープ解除の指示を受けたと判定されたときは(ステップS62でYES)、次に、ステップS63において、当該解除指示が無線通信モジュール34から発行された指示であるか否かが判定される。その結果、無線通信モジュール34から発行
された指示と判定されたときは(ステップS63でYES)、ステップS64において、マイコン37を介して電源制御IC41に、「スリープモード」を解除することを示す通知が発行されるとともに、マイコン37内の給電状態フラグ304をオンにする。これに応じて、電源制御IC41はCPUへの電力供給を開始し、ステップS65において、「スリープモード」が解除される。一方、上記ステップS63の判定の結果、無線通信モジュール34からの指示ではないと判定されたときは(ステップS63でNO)、マイコン37からの指示であると考えられるが、マイコン37からの指示の場合は、既に電源管理IC41には通知が行われており、かつ、既に給電状態フラグ304も変化している。そのため、上記ステップS64の処理はスキップされ、ステップS65に処理が進められる。その後、後述するステップS69に処理が進められる。
【0199】
一方、上記ステップS62の判定の結果、「スリープモード」解除の指示を受け付けていないと判定されたときは(ステップS62でNO)、ステップS66において、「スリープモード」への移行指示を受けたか否かが判定される。具体的には、以下のような場合に、「スリープモード」の移行指示を受けたと判定される。
(1)「スリープモード」の状態が解除されて上記「すれ違い通信」が行われた後、再度「スリープモード」に戻る指示が発行されたとき(後述の図31のステップS166)。
(2)「スリープモード」が解除されて専用APとの通信が行われ、その後再度「スリープモード」に戻る指示が発行されたとき(後述の図33のステップS195)。
(3)起床時刻到来により「スリープモード」が解除され、通信が行われた後、再度「スリープモード」に戻る指示が発行されたとき(後述の図33のステップS195)。
(4)開状態から閉状態に変化し、マイコン37から「スリープモード」に入る指示を受けたとき(上記図21のステップS10)。
ここで、上記(1)〜(3)の指示は、後述する「ローカル通信用BG処理」あるいは「インターネット通信用BG処理」において発行される。
【0200】
ステップS66の判定の結果、「スリープモード」への移行指示を受けたと判定されたときは(ステップS66でYES)、ステップS67において、マイコン37を介して電源管理IC41に、「スリープモード」へ移行する旨が通知され、マイコン37内の給電状態フラグ304をオフにする。そして、ステップS68において、「スリープモード」への移行が行われる。一方、上記ステップS66の判定の結果、「スリープモード」への移行指示がないと判定されたときは(ステップS66でNO)、上記ステップS67,S68の処理はスキップされて、以下に説明するステップS69に処理が進められる。
【0201】
次に、図25のステップS69において、いずれかのタスクが実行された結果、何らかのデータを受信したか否かが判定される。その結果、いずれかのタスクにおいて何らかのデータが受信されていれば(ステップS69でYES)、ステップS70において、ゲーム装置1のLED15A〜Cのうち少なくともいずれかを点灯させる。いわゆる「新着通知」に相当するものである。一方、何らかのデータの受信がされていないときは(ステップS69でNO)、ステップS70の処理はスキップされて、次のステップS71に処理が進められる。
【0202】
次に、ステップS71において、ゲーム装置1が「スリープモード」であるか否かが判定される。具体的には、給電状態フラグ304を参照することで判定できる。その結果、「スリープモード」であると判定されたときは(ステップS71でYES)、上記ステップS62に戻り、処理が繰り返される。一方、ステップS71の判定の結果、「スリープモード」ではないと判定されたときは(ステップS71でNO)、次に、ステップS72において、所定のタスクについて即時実行する旨の指示を受けたか否かが判定される。当該判定の結果、タスクの即時実行の指示は受けていないと判定されたときは(ステップS
72でNO)、後述のステップS74に処理が進められる。一方、タスクの即時実行の指示を受けたと判定されたときは(ステップS72でYES)、ステップS73において、ローカル通信用BG処理が実行される。この処理の詳細は後述するが、この流れにおける本処理の概要を簡単に説明すると、ゲーム装置1に予め登録されているAPへの接続を試みる処理と、接続できれば「インターネット通信」を用いたデータの送受信処理等が実行される(つまり、タスクの実行)。
【0203】
次に、ステップS74において、ホームボタン14Iが押下されたか否かが判定される。当該判定の結果、ホームボタン14Iが押下されたときは(ステップS74でYES)、上記ステップS61に戻り、ホームボタン14Iが押下されていないときは(ステップS74でNO)、上記ステップS62に戻って、処理が繰り返される。以上で、起動時処理の説明を終了する。
【0204】
[メニュー処理]
次に、上記ステップS61で示したメニュー処理について説明する。この処理では、メニュー画面の表示やアプリケーション起動に関する処理が行われる。特に、新規にインストールされたアプリ等の「新着要素」をメニュー画面に反映して表示する処理等が行われる。また、ゲーム装置1のシステムのアップデートに関する処理も実行される。
【0205】
図26は、当該メニュー処理の詳細を示すフローチャートである。図26において、まず、ステップS91で、タスクの実行の結果として、システムのアップデート用のデータが取得されたか否かが判定される。これは、上記オン・ザ・フライ用キャッシュ600にシステムアップデート用のデータが存在するか否かで判定される(なお、このデータは、後述する「インストール処理」において生成される)。このような判定手法の他、システムのアップデート用のデータが取得された際に、所定のフラグをオンに設定しておき、このフラグを参照して判断するようにしても良い。
【0206】
当該判定の結果、システムのアップデート用のデータが取得されていないと判定されたときは(ステップS91でNO)、後述するステップS97に処理が進められる。一方、システムのアップデート用のデータが取得されていると判定されたときは(ステップS91でYES)、ゲーム装置1のシステムアップデートに関する処理が実行される。具体的には、まず、上記オン・ザ・フライ用キャッシュ600に存在するシステムアップデート用のデータが、システムデータが記憶されているメモリ領域に移動される。上述したように、オン・ザ・フライ用キャッシュ600に展開されるアップデート用のデータのファイル名は、実際のシステムデータのファイル名とは異なる名前で展開されている。そのため、この時点では、システムデータが記憶されているメモリ領域には、例えば「firmware.bin」(アップデートが行われる前からのシステムデータ)と「firmware.upd」(アップデート用のデータ)というように、2つのデータが併存する状態となる。
【0207】
次に、ステップS92において、システムのアップデート用データを反映するか否かをユーザに確認するための確認画面が生成され、下側LCD12に表示される。そして、ユーザからの指示入力を受け付ける。このような確認画面を設けるのは、次のような理由による。すなわち、システムのアップデートは、ゲーム装置1の根幹に関わる内容であるため、その内容によっては、ユーザに大きな影響を与える可能性がある。そのため、このようにユーザに確認をとるようにしている。
【0208】
次に、ステップS93において、上記確認画面に対するユーザの指示内容が、アップデート用データの反映を指示する内容であるか否かが判定される。当該判定の結果、反映を指示する内容であれば(ステップS93でYES)、ステップS94において、システムデータのアップデートが反映される。具体的には、上記元の(更新前の)システムデータ
を削除し、アップデート用データのファイル名をシステムデータの名前にリネームすることで、システムデータのアップデートの反映が行われる。このように、更新確認の問い合わせに対して、ファイル名のリネームという処理でシステムデータをアップデートするため、ユーザから見ると、一瞬でシステムのアップデートが行われたように見える。従来は、ユーザから見ると、このようなアップデート処理に際しては、処理の完了のための待ち時間が発生することが一般的であった。しかし、上記のように、システムのアップデータが存在した際は、とりあえずダウンロードおよびファイルの展開を済ませておき、その後、上記のような確認をユーザに取ることで、システムアップデートの際にユーザに対して待ち時間を感じさせることを防ぐことができる。上記ステップS94の処理が終われば、その後、ステップS95においてメニューの再起動が実行される。その結果、上記ステップS91に処理が戻る。
【0209】
なお、システムのアップデート以外のもの、例えば、無料アプリケーションや体験版ゲーム等は、システム全体に与える影響は小さいと考えられるため、上記のような問い合わせは行われずに自動的にインストールされ、メニュー画面に反映されることになる(後述する「インストール処理」)。
【0210】
一方、上記ステップS93の判定の結果、アップデートを反映しない旨の指示内容と判定されたときは(ステップS93でNO)、ステップS96において、上記システムアップデート用のデータ(上記の例では「firmware.upd」)が破棄される。そして、上記ステップS91に戻る。
【0211】
次に、上記ステップS91の判定の結果、システムのアップデート用のデータが取得されていないと判定されたときの処理(ステップS91でNO)について説明する。この場合は、次に、メニュー画面の生成が実行される。本実施形態では、ゲーム装置1にインストールされているアプリケーションをスキャンする処理が実行され、検出された各アプリケーションに対応するアイコンがメニュー画面上に適宜配置されることで、メニュー画面が生成されて表示される。また、このスキャンの過程において、新着要素(後述する「インストール処理」において新規インストールされたアプリ等)の有無に関連する処理も実行される。
【0212】
具体的には、まず、ステップS97において、NANDフラッシュメモリ33のアプリ関連データ550が参照され、ゲーム装置1にインストールされている全てのアプリケーションについて、以下に説明するような処理(アプリケーションのスキャン)が行われたか否かが判定される。当該判定の結果、未処理のアプリケーションが残っていると判定されたときは(ステップS97でNO)、次に、未処理のアプリケーションの中からいずれか一つが処理対象として選択され(以下、スキャン対象アプリと呼ぶ)、ステップS98において、当該スキャン対象アプリが新規にインストールされたアプリケーションであるか否かが判定される。これは、上記アプリ関連データ550が参照され、スキャン対象アプリに該当するアプリケーション領域の新規インストールフラグ554がオンに設定されているか否かで判定される。
【0213】
当該判定の結果、スキャン対象アプリが新規にインストールされたアプリケーションであると判定されたときは(ステップS98でYES)、ステップS99において、上記図5で示したようなプレゼントアイコン112が生成されて、メニュー画面上に適宜配置される。一方、新規にインストールされたアプリケーションではないと判定されたときは(ステップS98でNO)、ステップS100において、当該スキャン対象アプリに対応するアイコンが生成されてメニュー画面上に適宜配置される。
【0214】
次に、ステップS101において、当該スキャン対象アプリ用のデータ(例えば、お知
らせの通知や追加コンテンツ等)が受信されたか否かが判定される。これは、例えば、上記アプリケーション領域551内のタスク受信キャッシュ553、あるいは、当該スキャン対象アプリに対応付けられているすれ違い通信用データ520の受信用ボックス524が参照されることで判定される(いずれか一方でも良いし、双方を参照して判定しても良い)。当該判定の結果、新規に受信したデータがあると判定されたときは(ステップS101でYES)、ステップS102において、当該スキャン対象アプリに対応するアイコンの近傍に、上記図6で示したような「New!」マークが配置される。そして、上記ステップS97に戻り、次のスキャン対象アプリが選択される。一方、ステップS101の判定の結果、新規に受信したデータがないと判定されたときは(ステップS101でNO)、ステップS102の処理はスキップされて、上記ステップS97の処理に戻る。
【0215】
次に、上記ステップS97において、全てのアプリケーションについて処理済み(スキャン済み)と判定されたとき(ステップS97でYES)の処理について説明する。この場合は、次に、アプリケーションの起動・実行に関する処理が行われる。具体的には、まず、図27のステップS103において、メニュー画面からいずれかのアプリケーションを示すアイコンが選択されたか否かが判定される。例えば、上記図4に示したようなメニュー画面でユーザが所定のアイコンに対してタッチオン操作したか否かが判定される。当該判定の結果、メニュー画面上のいずれのアプリケーション(のアイコン)も選択されていないと判定されたときは(ステップS103でNO)、当該ステップS103の判定が繰り返される。
【0216】
一方、メニュー画面上のいずれかのアプリケーション(のアイコン)が選択されたと判定されたときは(ステップS103でYES)、次に、ステップS104において、選択されたアプリケーションに対応する新規インストールフラグ554がオンに設定されているか否かが判定される。つまり、新規にインストールされたアプリケーションか否かが判定される。その結果、新規インストールフラグ554がオンに設定されていると判定されたときは(ステップS104でYES)、当該アプリケーションに対応するアイコンは上記プレゼントアイコン112として表示されていることになるため、ステップS105において、当該プレゼントアイコン112が、当該アプリケーションのアイコンとして本来定義されているアイコン(アプリケーションプログラムの一部として記憶されている)に変更される。このとき、プレゼントアイコン112の箱が開くようなアニメーション表示も行われる。
【0217】
次に、ステップS106において、当該アプリケーションについての新規インストールフラグ554がオフに設定されて、上記ステップS103に戻る。
【0218】
一方、上記ステップS104の判定の結果、新規インストールフラグがオフに設定されていると判定されたときは(ステップS104でNO)、次に選択されたアプリケーションの起動およびその実行が行われる。まず、選択されたアプリケーションの起動に際して、ステップS107において、認証キーによる認証処理が行われ、認証が成功したか否かが判定される。ここで、当該認証処理は、何らかの原因でインストールされた不正なアプリケーションが実行されることを防ぐための処理である。アプリケーションプログラムと一緒にダウンロード等された認証キーを用いることで、正規のアプリケーションか否かの認証が行われる。当該判定の結果、認証に成功すれば(ステップS107でYES)、ステップS108において、選択されたアプリケーションにかかる処理(以下、「各アプリの処理」と呼ぶ)が実行される。その後、当該アプリケーションにかかる処理が終了すれば、上記ステップS91の処理に戻る。一方、認証に失敗したときは(ステップS107でNO)、当該アプリケーションの実行はなされずに、上記ステップS91の処理に戻る。以上で、本体メニュー処理の説明を終了する。
【0219】
[各アプリの処理]
次に、上記ステップS108で示した各アプリの処理について説明する。なお、各アプリケーションの具体的な処理内容は当然のことながらそれぞれ異なる。そのため、この点に関しての説明は省略し、本実施形態に関する部分、すなわち、上記タスクに関する処理や上述した各種通信に関連する処理について、その最大公約数的な処理内容、すなわち、どのアプリケーションにおいても普遍的に行われると思われる処理として説明する。
【0220】
図28図29は、上記各アプリの処理の詳細を示すフローチャートである。図28において、まず、ステップS121で、何らかのタスクが実行された結果として、タスク受信キャッシュ553に、新たに受信した本アプリケーション用のデータが存在するか否かが判定される。当該判定の結果、当該新たに受信したデータがあると判定されたときは(ステップS121でYES)、ステップS122において、タスク受信キャッシュ553のデータが、本アプリケーションのセーブデータ555のタスク受信データ557に移動される(その結果、タスク受信キャッシュ553は空になる)。その後、ステップS123に処理が進められる。一方、新たに受信したデータがないと判定されたときは(ステップS121でNO)、ステップS122の処理はスキップされて、ステップS123に処理が進められる。
【0221】
次に、ステップS123において、本アプリケーションに対応付けられているすれ違い通信用データ520の受信用ボックス524に新規に受信されたデータが存在するか否かが判定される。当該判定の結果、受信用ボックス524に新規に受信されたデータがあると判定されたときは(ステップS123でYES)、ステップS124において、当該受信用ボックス524内のデータが本アプリケーションのセーブデータ555のすれ違い受信データ558に移動される(その結果、受信ボックス524は空になる)。そして、ステップS125に処理が進められる。一方、受信用ボックス524に新規に受信されたデータはないと判定されたときは(ステップS123でNO)、上記ステップS124の処理はスキップされて、ステップS125に処理が進められる。
【0222】
次に、ステップS125において、各アプリケーションの内容に応じた各種情報処理が実行される。例えば、ゲーム処理やお絵かきソフト処理、カメラアプリケーション処理等である。この情報処理において、ステップS122やステップS124において新たに移動されたタスク受信データ557やすれ違い受信データ558のデータを利用することができる。
【0223】
次に、ステップS126において、上記ステップS125における各種情報処理の結果、タスクを新たに追加するイベント、あるいは、タスクの内容を更新するイベントが発生したか否かが判定される。その結果、当該イベントが発生していないと判定されたときは(ステップS126でNO)、後述するステップS132に処理が進められる。
【0224】
一方、タスクの新規追加、あるいはタスクの更新のイベントが発生したと判定されたときは(ステップS126でYES)、次に、ステップS127において、当該発生したイベントにかかる内容が、「送信タスク」に関するものか「受信タスク」に関するものかが判定される。当該判定の結果、「送信タスク」の追加、あるいは更新という内容と判定されたときは(ステップS127でYES)、続くステップS128において、送信すべきデータが作成され、セーブデータ555のタスク送信用データ556として記憶される。更に、ステップS129において、「送信タスク」用の各種パラメータが設定される。ここで設定されるパラメータは、上記図16で示したようなタスク設定531を構成する各項目を設定するためのパラメータである。
具体的には、以下のようなパラメータ設定が行われる。
(1)アプリID→本アプリケーションのID
(2)タスクID→タスクの新規追加の場合は新規な値、更新の場合は更新しようとするタスクのタスクIDと同じ値
(3)実行優先度→任意の値
(4)通信先URL→送信先のサーバのURL
(5)ファイルパス→上記タスク送信用データ556の位置を示す値
(6)次回実行時刻→任意の値
(7)実行間隔→任意の値
(8)送信/受信識別フラグ→「送信」を表す値
(9)消尽回数→任意の値
上記のようなパラメータ設定が行われた後、後述するステップS131に処理が進められる。
【0225】
一方、上記ステップS127の判定の結果、発生したイベントにかかる内容が「受信タスク」に関するものであると判定されたときは(ステップS127でNO)、ステップS130において、「受信タスク」用の各種パラメータが設定される。当該処理は、上記ステップS129と同様にタスク設定531の各項目の設定用パラメータを設定する処理である。具体的には、以下のようなパラメータ設定が行われる。
(1)アプリID→本アプリケーションのID
(2)タスクID→タスクの新規追加の場合は新規な値、更新の場合は更新しようとするタスクのタスクIDと同じ値
(3)実行優先度→任意の値
(4)通信先URL→受信元となるサーバのURL
(5)ファイルパス→受信したデータの格納先(タスク受信キャッシュ553)を示す値
(6)次回実行時刻→任意の値
(7)実行間隔→任意の値
(8)送信/受信識別フラグ→「受信」を表す値
(9)消尽回数→任意の値
上記のようなパラメータ設定が行われた後、後述するステップS131に処理が進められる。
【0226】
次に、ステップS131において、上記設定されたパラメータに基づくタスクの新規追加あるいは既存タスクの更新を行うための、タスク生成処理が実行される。図30は、上記ステップS131で示したタスク生成処理の詳細を示すフローチャートである。図30において、まず、ステップS151で、上記パラメータの各項目に基づいて、作業用のタスク設定データが生成される。当該作業用のタスク設定データは、メインメモリ32に生成される一時的なデータであり、上記タスク設定531と同じデータ構造を有する。なお、任意の項目であってパラメータの指定がなされていない項目については、初期値として設定されている値が設定される。
【0227】
次に、ステップS152において、当該作業用のタスク設定データのアプリIDおよびタスクIDが、上記タスクデータ530に格納されているタスク設定531のいずれかのアプリID532およびタスクID533と重複しているか否かが判定される。つまり、新規追加のタスクであるか、既にあるタスクの更新になるかが判定される。当該判定の結果、重複するIDがあれば(ステップS152でYES)、ステップS153において、当該重複するタスク設定531の内容が上記作業用のタスク設定データで置き換えられる(つまり、更新される)。一方、重複するIDが存在しないと判定されたときは(ステップS152でNO)、ステップS154において、上記作業用のタスク設定データが新規のタスク設定531として、タスクデータ530に追加登録される。そして、作業用のタスクデータが消去されて、当該タスク生成処理は終了する。
【0228】
図28に戻り、ステップS131の処理が終われば、次に、図29のステップS132において、上記ステップS125の各種情報処理によって、「すれ違い通信」を用いた送信に関するイベントが発生したか否かが判定される。例えば、上記各種情報処理において、「すれ違い通信」を用いて何らかのデータを送信するための指示がユーザからなされたか否か等が判定される。当該判定の結果、「すれ違い通信」を用いて何らかのデータを送信する旨のイベントが発生したと判定されたときは(ステップS132でYES)、ステップS133において、まず、上記イベント内容に応じた送信用のデータが適宜生成される。そして、上記すれ違い通信用データ520の中の、本アプリケーションに対応するスロット521の送信用ボックス523に、当該生成された送信用のデータが格納される。そして、後述のステップS134に処理が進められる。一方、上記ステップS132の判定の結果、上記イベントが発生していないと判定されたときは(ステップS132でNO)、ステップS133の処理はスキップされて、ステップS134に処理が進められる。
【0229】
次に、ステップS134において、サーバから受信したデータが在るか否かが判定される。つまり、「受信タスク」の実行によって何らかの新規なデータが受信されたか否かが判定される(そのため、上記ステップS121の判定でYESと判定されたときは、当該判定においてもYESと判定されることになる)。例えば、サーバから新規のデータが受信されていれば、上記ステップS122でセーブデータ555に移動されているため、当該セーブデータ555が参照されることで、当該判定が行われる。
【0230】
当該判定の結果、サーバから受信した新規なデータがないと判定されたときは(ステップS134でNO)、後述するステップS142に処理が進められる。一方、サーバから受信した新規なデータがあると判定されたときは(ステップS134でYES)、次に、ステップS135において、当該受信したデータの中に、現在実行されているアプリに関するネットワークサービスの終了を知らせる旨の通知が含まれているか否かが判定される。その結果、サービス終了の旨の通知が含まれていないと判定されたときは(ステップS135でNO)、後述するステップS141に処理が進められる。
【0231】
一方、サービス終了の旨の通知が含まれていると判定されたときは(ステップS135でYES)、ステップS136において、サービス終了の旨が上側LCD22あるいは下側LCD12に表示される。次に、ステップS137において、現在実行されているアプリケーションのアプリID532を含むタスク設定531がタスクデータ530内に残っているか否かが判定される。残っていると判定されたときは(ステップS137でYES)、現在実行されているアプリケーションのアプリID532を含むタスク設定531が全て消去される。一方、残っていないと判定されたときは(ステップS137でNO)、上記ステップS138の処理はスキップされる。
【0232】
次に、ステップS139において、すれ違い通信用データ520が参照されて、現在実行されているアプリケーションのアプリID522が割り当てられているスロット521があるか否かが判定される。残っていると判定されたときは(ステップS139でYES)、ステップS140において、現在実行されているアプリケーションに対応するスロット521の内容をクリアする。その結果、当該スロット521と当該アプリケーションとの対応付けが解除される。一方、上記のようなスロットは残っていないと判定されたときは(ステップS139でNO)ステップS140の処理はスキップされる。
【0233】
次に、ステップS141において、必要に応じて、上記受信された新規なデータの内容を表示する処理が実行される。
【0234】
次に、ステップS142において、当該実行中のアプリケーション処理の終了条件が満
たされたか否かが判定される。その結果、終了条件が満たされていなければ(ステップS142でNO)、上記ステップS121に戻り、処理が繰り返される。終了条件が満たされていれば(ステップS142でYES)、本アプリ処理は終了される。以上で、各アプリの処理の説明を終了する。
【0235】
[ローカル通信用BG処理]
次に、上述したような各処理において適宜呼び出されていたローカル通信用BG処理(具体的には、図21のステップS4、図22のステップS28およびS34、図23のステップS40、図25のステップS73)について説明する。この処理では、主に、上記「すれ違い通信」における送受信処理と、上記所定のAPのスキャンや当該APとの接続処理等の制御が行われる。また、所定のAPと接続した際には、上記「インターネット通信」等を行うための処理である「インターネット用BG処理」が適宜呼び出される。
【0236】
図31図32は、当該ローカル通信用BG処理の詳細を示すフローチャートである。まず、ステップS161において、無線通信モジュール34がすれ違い接続応答を受信しているか否かが判定される。これは、例えば、CPU31が無線通信モジュール34に対して、すれ違い接続応答を受信したか否かを問い合わせするような処理によって判定される。当該判定の結果、上記すれ違い接続応答を受信していないと判定されたときは(ステップS161でNO)、後述するステップS167に処理が進められる。一方、上記すれ違い接続応答を受信していると判定されたときは(ステップS161でYES)、自ゲーム装置1が発した要求に対して、応答可能な(ローカル通信のための接続が確立した)他のゲーム装置1が存在しているということになる(上記図22のステップS28では、この流れに来ることになる)。そのため、次のステップS162において、当該通信相手となった他のゲーム装置1に対して、すれ違い通信用データ520の送信用ボックス523のデータが送信される。但し、上記のように、送信されるデータは、上記アプリID522が、通信相手のすれ違い通信用データ520のものと一致したスロット521にかかるデータに限る。
【0237】
次に、ステップS163において、送信時刻、および、当該通信相手である他のゲーム装置1のMACアドレスが無線通信モジュール34内の既通信端末/専用AP情報405に記憶される。
【0238】
次に、ステップS164において、すれ違い通信における「受信」の処理が行われたか否かが判定される。本実施形態では、すれ違い通信は原則として「送信」と「受信」がセットで行われる。そのため、この判定では、両方とも済んだのか、一方だけしか済ませていないのかが判定されることになる。当該判定の結果、受信処理がまだ行われていないと判定されたときは(ステップS164でNO)、後述するステップS170の処理に進み、通信相手から送られてくるデータの受信が行われる。
【0239】
一方、既に受信処理は行われたと判定されたときは(ステップS164でYES)、ステップS165において、今回の通信(この通信とは、「ローカル通信」だけでなく、後述の「インターネット通信」も含む)を行うために「スリープモード」が解除されていたのか否かが判定される。当該判定の結果、今回の通信のために「スリープモード」が解除されていたと判定されたときは(ステップS165でYES)、今回の通信前は「スリープモード」の状態であったと考えられるため、この状態に戻すために、ステップS166において、CPU31に給電を停止するための命令がCPU31自身から送られ、「スリープモード」に移行するための処理が実行されるとともに、マイコン37内の給電状態フラグ304をオフにし、電源管理IC41にスリープへ移行する旨を通知する。一方、ステップS165の判定の結果、今回の通信のために「スリープモード」が解除されていたのではないと判定されたときは(ステップS165でNO)、元々「通常電力モード」で
稼働している状態であったと考えられるため、ステップS166の処理はスキップされる。そして、当該ローカル通信用BG処理は終了する。
【0240】
次に、上記ステップS161の判定の結果、上記すれ違い接続応答を受信していないと判定されたときの処理について説明する。この場合は、まず、ステップS167において、すれ違い接続要求、すなわち、他のゲーム装置1からのすれ違い通信の要求を無線通信モジュール34が受信したか否かが判定される。その結果、当該要求を受信していないと判定されたときは(ステップS167でNO)、後述のステップS173に処理が進められる。一方、当該要求を受信したと判定されたときは(ステップS167でYES)、ステップS168において、すれ違い接続応答が生成されて、上記すれ違い接続要求の送信元である他のゲーム装置1へ送信される(なお、上記図22のステップS34の処理では、この流れで処理が進められることになる)。このとき、当該すれ違い接続応答には、上記無線通信モジュール34に記憶されている抽出アプリID406の内容が含まれて送信される(つまり、すれ違い通信の対象となるアプリを相手側に通知することになる)。
【0241】
次に、ステップS169において、応答時刻、および、通信相手である他のゲーム装置1のMACアドレスが、無線通信モジュール34内の既通信端末/専用AP情報405に記憶される。
【0242】
次に、ステップS170において、通信相手からデータを受信したか否かが判定される。これは、本実施形態では、アプリID522が一致するもののみ送受信対象としている関係上、他のゲーム装置1からのすれ違い通信要求を受け、接続は確立したものの、双方で一致するアプリID522がなかったために、実際には送受信するデータがない、という場合を判定するためのものである。すなわち、ステップS169にて送信した接続応答を、相手端末が受信したものの、相手端末側の図22のステップS25でNOであった場合には、データは送信されてこないことになる。当該判定で、相手端末からのデータが(一定時間内に)受信されていないと判定されたときは(ステップS170でNO)、上記一致するアプリID522がなかった場合に相当すると考えられるため、上記ステップS165に処理が進められて、「スリープモード」に戻すか否かの判定が行われる。一方、相手端末からデータを受信したと判定されたときは(ステップS170でYES)、当該受信したデータが、そのアプリID522に対応するスロット521の受信用ボックス524に格納される。なお、上記ステップS164からステップS170に来た場合は、少なくとも1つはアプリID522が一致する送受信対象があったことになり、相手端末からはデータが送信されてくるため、途中で転送エラーが生じない限り、この判定ではYESと判定される。
【0243】
次に、ステップS172において、すれ違い通信にかかる送信処理が既に行われているか否かが判定される。その結果、まだすれ違い通信にかかる送信処理が行われていないと判定されたときは(ステップS172でNO)、上記ステップS162に処理が進められ、すれ違い通信にかかる送信処理が行われる。一方、送信処理は既に行われていると判定されたときは(ステップS172でYES)、上記ステップS165に処理が進められる。
【0244】
次に、上記ステップS167の判定の結果、すれ違い接続要求が受信されていないと判定されたときの処理について説明する。この場合は、次に、「インターネット通信」に関する処理が実行されることになる。まず、図32のステップS173において、無線通信モジュール34が、専用AP101からのビーコンを受信したか否かが判定される。当該判定の結果、専用AP101からのビーコンを受信したと判定されたときは(ステップS173でYES)、ステップS174において、当該ビーコンの発信元となる専用AP101への接続処理が実行される。なお、上記図23のステップS40の処理では、この流
れで処理が進められることになる。
【0245】
次に、ステップS175において、現在時刻と接続した専用AP101のMACアドレスが無線通信モジュール34内の既通信端末/専用AP情報405に記憶される。
【0246】
次に、ステップS176において、インターネット通信用BG処理が実行される。この処理では、ポリシーデータの取得とこれに基づく処理やタスクの実行処理が行われる。この処理の詳細については後述する。当該処理が終われば、当該ローカル通信用BG処理は終了する。
【0247】
一方、上記ステップS173の判定の結果、専用AP101のビーコンを受信していないと判定されたときは(ステップS173でNO)、ステップS177で、本体設定データ560が参照され、ゲーム装置1に登録・設定されている所定のAPをサーチする処理が実行される。例えば、ユーザの自宅に設置したAPや、出荷時設定として予め定義されている公衆無線LANサービスのAP等をサーチする処理が実行される。サーチ方法は典型的にはパッシブスキャンであるが、APのBSSIDやAPとの通信に用いられる周波数が予めゲーム装置1に記憶されていれば、直接APと接続を行うこともできる。
【0248】
次に、ステップS178において、上記ステップS177におけるサーチの結果、APが存在したか否かが判定される。その結果、APが存在しなかった(サーチの結果、検出できなかった)と判定されたときは(ステップS178でNO)、上記ステップS165に処理が進められる。一方、APが存在したと判定されたときは(ステップS178でYES)、ステップS179において、当該サーチされたAPへの接続処理が行われる。そして、ステップS180において、後述するインターネット通信用BG処理が実行される。当該処理が終われば、当該ローカル通信用BG処理は終了する。以上で、ローカル通信用BG処理の説明を終了する。
【0249】
[インターネット通信用BG処理]
次に、上記ステップS176等で示したインターネット通信用BG処理について説明する。この処理では、「インターネット通信」を利用した各種データの送受信にかかる処理等が実行される。
【0250】
図33は、当該インターネット通信用BG処理の詳細を示すフローチャートである。まず、ステップS191において、ポリシー処理が実行される。当該処理の詳細は後述するが、ここでは、主に、ポリシーデータの取得、および、当該ポリシーデータに基づくタスクの実行優先度の調整が行われる。
【0251】
次に、ステップS192において、タスク実行処理が行われる。この処理についても詳細は後述するが、この処理では、タスクの実行や、インストール処理等が行われる。
【0252】
タスク処理が終了すれば、次に、ステップS193においてAP101または102との通信の切断が実行される。続くステップS194において、今回の通信のために「スリープモード」が解除されていたか否かが判定される。その結果、「スリープモード」が解除されていたと判定されたときは(ステップS194でYES)、ステップS195において、「スリープモード」に戻すために、CPU31に給電を停止するための命令がCPU31自身から送られ、「スリープモード」に移行するための処理が実行されるとともに、マイコン37内の給電状態フラグ304をオフにし、電源管理IC41にスリープへ移行する旨を通知する。一方、ステップS194の判定の結果、今回の通信のために「スリープモード」が解除されていたのではないと判定されたときは(ステップS194でNO)、ステップS195の処理はスキップされる。そして、当該インターネット通信用BG
処理は終了する。
【0253】
[ポリシー処理]
次に、上記ステップS191で示したポリシー処理について説明する。図34図35は、当該ポリシー処理の詳細を示したフローチャートである。まず、ステップS201において、上述したようなポリシーサーバ103との接続を確立する処理が実行される。次に、ステップS202において、現在通信に利用しているAPが専用AP101であるか否かが判定される。これは、APとの接続の際に利用したビーコンに、上述したようなベンダー特定情報が含まれているか否かで判定される。当該判定の結果、専用AP101を利用していると判定されたときは(ステップS202でYES)、ステップS203において、当該利用している専用AP101の識別子と、ゲーム装置1に設定されている国情報(上記本体設定データ560に含まれている)を含んだポリシーデータのリクエストを生成し、ポリシーサーバ103に送信する。このリクエストは、例えば、以下のようなHTTPリクエストである。
「https://xxx.net/国情報を示す文字列/AP識別子/」
【0254】
一方、現在通信に使用しているAPが専用AP101ではないと判定されたときは(ステップS202でNO)、ステップS204において、上記国情報を含んだポリシーデータのリクエストが生成され、ポリシーサーバ103へ送信される。このときのリクエストは、例えば、以下のような内容となる。
「https://xxx.net/国情報を示す文字列/」
【0255】
上記のようなリクエストに応じて、ポリシーサーバ103からポリシーデータが送信開始されるため、次に、ステップS205において、ポリシーサーバ103からポリシーデータがダウンロードされ、受信ポリシーデータ570としてメインメモリ32あるいはNANDフラッシュメモリ33に格納される。
【0256】
ダウンロードが終われば、次に、当該ダウンロードした受信ポリシーデータ570を適用するための処理が実行される。具体的には、まず、ステップS206において、受信ポリシーデータ570に含まれる全てのポリシー設定574について、以下に示すような処理が行われたか否か、つまり、実行優先度や消尽回数の変更が適用されたか否かが判定される。当該判定の結果、全てのポリシー設定574について適用済み(処理済み)と判定されたときは(ステップS206でYES)、当該ポリシー処理は終了する。一方、未適用(未処理)のポリシー設定574が残っていれば(ステップS206でNO)、ステップS207において、まだ適用されていないポリシー設定574のうちいずれか1つが選択される。以下、この選択されたポリシー設定574を「処理対象ポリシー設定」と呼ぶ。
【0257】
次に、ステップS208において、処理対象ポリシー設定の内容が、全てのタスクを適用対象とする内容であるか否かが判定される。これは、当該処理対象ポリシー設定のタスクID576に、全タスクを適用対象とする旨の文字列が示されているか否か等で判定される。当該判定の結果、全タスクを適用対象とする内容ではないと判定されたときは(ステップS208でNO)、後述のステップS213に処理が進められる。
【0258】
一方、当該判定の結果、全タスクを適用対象とすると判定されたときは(ステップS208でYES)、次に、ステップS209において、処理対象ポリシー設定のタスク永続性578が、オンに設定されているか否か、すなわち、「永続的」であることを示す内容か否かが判定される。当該判定の結果、「永続的」と判定されたときは(ステップS209でYES)、ステップS212において、ゲーム装置1に登録されている(つまり、タスクデータ530内の)全てのタスクの実行優先度534が、当該処理対象ポリシー設定の
実行優先度577で示される値に変更される。そして、後述のステップS218に処理が進められる。
【0259】
一方、ステップS209の判定の結果、「永続的」ではないと判定されたときは(ステップS209でNO)、ステップS210において、タスクデータ530内の全てのタスクについての現在の実行優先度534がメインメモリ32にバックアップされる。そして、ステップS211において、ゲーム装置1に登録されている全てのタスクの実行優先度534が当該処理対象ポリシー設定の実行優先度577で示される値に変更される。そして、後述のステップS218に処理が進められる。
【0260】
次に、上記ステップS208の判定の結果、全タスクを適用対象とする内容ではないと判定されたときの処理について説明する。この場合は、ステップS213において、タスクデータ530が参照されて、処理対象ポリシー設定のタスクID576およびアプリID575と同じ値を有するタスク設定531がタスクデータ530内に存在するか否かが判定される。当該判定の結果、存在しないと判定されたときは(ステップS213でNO)、当該処理対象ポリシー設定については処理済みとしたうえで上記ステップS206に戻る。その結果、受信ポリシーデータ570から、未処理のポリシー設定574が次の処理対象ポリシー設定として選択され、処理が繰り返される。
【0261】
一方、上記タスクIDおよびアプリIDが一致するタスク設定531が存在すると判定されたときは(ステップS213でYES)、次に、ステップS214において、当該処理対象ポリシー設定のタスク永続性578が「永続的」を示す値か否かが判定される。その結果、「永続的」であれば、ステップS215において、上記タスクIDおよびアプリIDが一致するタスク設定531の実行優先度が、処理対象ポリシー設定の実行優先度577で示される値に設定される。そして、後述のステップS218に処理が進められる。
【0262】
一方、ステップS214の判定の結果、「永続的」ではないと判定されたときは(ステップS214でNO)、ステップS216において、上記タスクIDおよびアプリIDが一致するタスク設定531の実行優先度534がメインメモリ32上にバックアップされる。そして、ステップS217において、上記タスクIDおよびアプリIDが一致するタスク設定531の実行優先度534が、処理対象ポリシー設定の実行優先度577で示される値に設定される。
【0263】
次に、ステップS218において、上記実行優先度534が変更された結果、変更を適用される対象となったタスク設定531が以下に示すような条件を満たしているか否かが判定される。この条件とは、(1)消尽回数540が0であること、(2)上記変更適用後の実行優先度534が"EXPEDIATE"であること、(3)タスクリビジョン543の値が
今回取得した受信ポリシーデータ570のポリシーリビジョン571と一致すること、である。この3つの条件の全ては満たしていないと判定されたときは(ステップS218でNO)、ステップS219において、当該タスク設定531の消尽回数540に1が加算される。すなわち、消尽回数が0となって実行されなくなったタスクに対して、実行優先度が"EXPEDIATE"、つまり最優先で実行させたいタスクとするために、消尽回数540の
値を変更するものである。そして、ステップS220において、今回適用したタスク設定531のタスクリビジョン543の値として、上記受信ポリシーデータ570のポリシーリビジョン571の値が記録される。そして、上記ステップS206に処理が戻る。
【0264】
一方、ステップS218の判定の結果、上記3つの条件を全て満たしていると判定されたときは(ステップS218でYES)、以前も同じリビジョンのポリシーを受信し、そのときに当該タスクは実行されていると考えられる。この場合、同じリビジョンのポリシーデータを受信したときは、再度当該タスクを実行させないため、上記のような消尽回数
540の加算は行われずに、ステップS220に処理が進められる。以上で、ポリシー処理の説明は終了する。
【0265】
[ポリシーサーバの処理]
ここで、上記ポリシー処理における通信相手となるポリシーサーバの処理についても説明する。まず、具体的な処理の説明の前に、ポリシーデータが格納されている当該ポリシーサーバ103のメモリマップについて簡単に説明する。図36は、ポリシーサーバ103のメモリマップを示す図である。図36に示すように、ポリシーサーバ103には、国情報152毎に分けて複数のポリシーデータ153が格納されている。各ポリシーデータ153の構造は、上記図18で示した受信ポリシーデータ570と同様である。図36では、説明を判りやすくするため、AP情報154のみ示している。AP情報154は、所定の専用AP101を示す値が割り振られているものと、NULL値が設定されているものがあるとする。本実施形態では、各国情報毎に、専用AP101を示す値が割り振られたポリシーデータ153は複数存在するとする(但し、これら複数のポリシーデータ153の間では、AP情報154は重複していないとする)。また、AP情報にNULL値が設定されたポリシーデータ153は一つだけしか存在しないものとする。このようなポリシーデータ153がポリシーサーバ103に格納されていることを前提として、以下のような処理が実行される。
【0266】
図37は、当該ポリシーサーバ103で実行される処理を示すフローチャートである。図37において、まず、ステップS231において、上述したようなポリシーデータ153のリクエストの受信があったか否かが判定される。その結果、受信していないと判定されたときは(ステップS231でNO)、当該ステップS231の処理が繰り返される。つまり、当該リクエストの待ち受け状態となる。一方、ポリシーデータ153のリクエストを受信したと判定されたときは(ステップS231でYES)、次に、ステップS232において、受信したリクエストにAPの識別子が付加されているか否かが判定される。その結果、付加されているときは(ステップS232でYES)、専用AP101を経由してポリシーサーバ103にアクセスしてきていると考えられる。この場合は、ステップS233において、リクエストに含まれているゲーム装置1の国情報、および、APの識別子に対応するポリシーデータ153が読み出される。つまり、上記リクエストに含まれる国情報が上記ポリシーサーバ103に記憶されている国情報152と照合され、一致するものがあれば、更に、リクエストに含まれるAP識別子とAP情報154とが照合され、一致するポリシーデータ153が検索され、読み出される。そして、ステップS235において、当該読み出されたポリシーデータ153が上記リクエストの送信元のゲーム装置1に送信される。
【0267】
一方、上記ステップS232の判定の結果、上記リクエストにAPの識別子が付加されていないと判定されたときは(ステップS232でNO)、専用AP101を介さずにポリシーサーバにアクセスしてきている場合であると考えられる。そのため、この場合は、ステップS234において、まず、上記リクエストに含まれる国情報と上記ポリシーサーバの国情報152とが照合され、一致するものが検索される。そして、AP情報154にNULL値が設定されているポリシーデータ153が読み出される。そして、上記ステップS235において、当該ポリシーデータ153の送信が行われる。以上で、ポリシーサーバの説明は終了する。
【0268】
[タスク実行処理]
次に、上記図33のステップS192で示した、タスクの実行処理について説明する。この処理では、タスクの設定内容に基づいて所定のデータの送受信が行われる。更に、インストール処理も行われる。図38図40は、当該タスク処理の詳細を示すフローチャートである。まず、ステップS251において、実行順ソート処理が実行される。この処
理では、タスクの実行優先度や次回実行時刻、消尽回数等を考慮して、実行すべきタスクの抽出が行われ、その実行順序を決定するための処理が行われる。また、以下のような処理が行われた結果、メインメモリ32に「実行順序リスト」という一時的なデータが生成される。
【0269】
図41は、上記ステップS251にかかる実行順ソート処理の詳細を示すフローチャートである。図41において、まず、ステップS291で、上記タスクデータ530が参照されて、次回実行時刻537が現在時刻以前であって、且つ、消尽回数540が0ではないタスク設定531が抽出される。ここで、次回実行時刻が現在時刻「以前」であるものを抽出している理由は、専用AP101に接続するタイミングは偶然ビーコンを受信したときであるために、タスクの実行時刻と完全に一致する時刻に当該処理が行われることはまれであるからである。そのため、既に実行時刻を経過してしまっていても、この時点においては抽出が行われる。
【0270】
次に、ステップS292において、上記抽出された各タスク設定531についての評価が行われる。当該評価の意図は、長い間実行されていないタスクほど、より優先的に実行されるように調整するという意図である。そのため、本実施形態では、「評価ポイント」というものを用いる。当該「評価ポイント」は、その値が高いほど、優先的に実行すべきであることを示す。そして、この処理では、上記抽出された各タスク設定531の前回完了時刻544と現在時刻とが比較され、前回完了時刻544から現在時刻までの時間が長いものほど高い点数の「評価ポイント」が与えられる。つまり、長時間実行されていないタスク設定531ほど、高い「評価ポイント」が設定される。
【0271】
次に、ステップS293において、上記抽出されたタスクから実行優先度534が”STOPPED”のタスクが除外される。”STOPPED”は実行停止を意味する内容であるからである。
【0272】
次に、ステップS294において、実行優先度534および上記「評価ポイント」に基づいて、これまでの処理でピックアップされた各タスク設定531がソートされる。具体的には、まず、実行優先度534に基づいて各タスク設定531がソートされる。次に、実行優先度が同じタスク設定531の間で、上記「評価ポイント」に基づくソートが行われる。その結果、同じ実行優先度を有するタスク設定531の間では、長時間実行されていないタスクほど優先的に実行されるような順序づけがなされることになる。なお、未実行のタスク設定、すなわち、前回完了時刻544に値が設定されていないタスク設定531については、当該タスク設定531が登録された時刻であるタスク登録時刻545に基づいてソートされる。すなわち、登録時刻が古いものほど優先的に実行されるようにソートされる。
【0273】
次に、ステップS295において、未処理フラグ541がオンに設定されているタスク設定531があるか否かが判定される。その結果、未処理フラグ541がオンのタスク設定531があると判定されたときは(ステップS295でYES)、ステップS296において、当該未処理のタスク設定531の実行優先度が”HIGH”であって、その中での実行順序が上位に来るように調整される。つまり、この時点で未処理となっているタスクは、以前にタスクが実行可能な状態であったときに、何らかの原因で当該タスクが実行されなかったと考えられる。そのため、このようなタスクについては、"EXPEDITE"の次の優先度で実行されるように調整することで、いわゆる「レジューム」的な動作が行われるようにするものである。一方、ステップS295の判定の結果、未処理フラグ541がオンのタスク設定531がないときは(ステップS295でNO)、ステップS296の処理はスキップされて、本実行順ソート処理は終了する。その結果、上記「実行順序リスト」がメインメモリ32上に生成されることになる。当該「実行順序リスト」では、上記のよう
な処理の結果、上記処理でピックアップされたタスクが、その実行順位の高いものから順にソートされて示されている。
【0274】
図38に戻り、実行順ソート処理が終われば、次に、ステップS252において、上記「実行順序リスト」にリストアップされている全てのタスクを全て実行し終えたか否かが判定される。当該判定の結果、すべて実行し終えたと判定されたときは(ステップS252でYES)、後述するステップS275に処理が進められる。一方、まだ未実行のタスクが残っていると判定されたときは(ステップS252でNO)、次に、ステップS253において、完了していないタスクのうち、実行順序が最上位のタスクが選択される。以下、当該選択されたタスクを処理対象タスクと呼ぶ。
【0275】
次に、ステップS254において、選択された処理対象タスクにかかるタスク設定531の未処理フラグ541がオンに設定される。
【0276】
次に、ステップS255において、当該処理対象タスクにかかるタスク設定531の通信先URL535が参照され、HTTPリクエストが生成される。
続くステップS256において、本体設定データ560が参照され、上記生成されたHTTPリクエストの文字列にゲーム装置1に設定されている国情報が付加される。
【0277】
次に、ステップS257において、現在行われている「インターネット通信」は、専用AP101を利用した通信であるか否か、つまり、専用AP101を介してインターネットに接続しているか否かが判定される。その結果、専用AP101を利用した通信であると判定されたときは(ステップS257でYES)、ステップS258において、現在使用しているAPにかかるAP識別子が、上記HTTPリクエストの文字列に更に付加される。一方、専用APを利用していないと判定されたときは(ステップS257でNO)、当該ステップS258の処理はスキップされる。
【0278】
次に、ステップS259において、処理対象タスクにかかるタスク設定531の送信/受信識別フラグ539を参照することにより、処理対象タスクの内容が「受信タスク」か否かが判定される。つまり、データの受信を行うためのタスクであるか、送信を行うためのタスクであるかが判定される。その結果、「受信タスク」であると判定されたときは(ステップS259でYES)、ステップS260において、上記の処理で生成されたHTTPリクエストが、当該処理対象タスクにかかるタスク設定531の通信先URL535で示されるサーバに対して送信される。これに応じて、当該サーバが所定のデータの送信を開始するので、ステップS261において、当該サーバから送信されるデータのダウンロード(以下、DLと呼ぶこともある)が開始される。ステップS262において、当該ダウンロードが完了したか否かが判定され、未完了であれば(ステップS262でNO)、完了するまでダウンロードが継続される。ダウンロードが完了すれば(ステップS262でYES)、続くステップS263において、当該処理対象タスクにかかるタスク設定531のファイルパス536で示される格納場所すなわち当該タスク設定531のアプリID532に対応するアプリケーションのアプリケーション領域551のタスク受信キャッシュ553に、ダウンロードされたデータが格納される。その後、後述するステップS267に処理が進められる。
【0279】
一方、上記ステップS259の判定の結果、処理対象タスクの内容が「受信タスク」ではない、つまり、「送信タスク」であると判定されたときは(ステップS259でNO)、ステップS264において、当該処理対象タスクのファイルパス536で示される格納場所、本実施形態では、当該処理対象タスクに対応するアプリケーション領域551のタスク送信用データ556から、送信(アップロード)すべきデータが取得される。そして、当該データが上記HTTPリクエストに付加される。
【0280】
次に、ステップS265において、上記送信データが付加されたHTTPリクエストがサーバに送信される。すなわち、通信先URL535で示されるURLに対してのデータのアップロード処理が開始される。その後、アップロードが完了すれば、ステップS266において、サーバから送られてくる完了通知(データのアップロードが正常終了したことを示す通知)が受信される。そして、ステップS267に処理が進められる。
【0281】
次に、図39のステップS267において、処理対象タスクにかかるタスク設定531の未処理フラグ541にオフが設定される。続くステップS268において、前回完了時刻544に現在時刻が完了時刻として記憶される。更に、ステップS269において、消尽回数540の値から1が減算される。
【0282】
次に、ステップS270において、タスク設定531の実行間隔538が参照されて次回実行時刻が算出され、次回実行時刻537として記憶される。
【0283】
次に、ステップS271において、上記処理対象タスクの内容が、「インストールリストの取得」というタスクであるか否かが判定される。上述したように、当該「インストールリストの取得」というタスクは、ゲーム装置1の出荷時設定として予め設定されているタスクである。そのタスク設定531の内容としては、予め定められた固定的なタスクID533が割り当てられており、また、定期的に実行されるように設定されている。そのため、当該タスクID533を参照することで、「インストールリストの取得」というタスクか否かが判定される。当該判定の結果、「インストールリストの取得」のタスクであると判定されたときは(ステップS271でYES)、ステップS272において、インストール処理が実行される。この処理の詳細は後述する。一方、「インストールリストの取得」のタスクではないと判定されたときは(ステップS271でNO)、ステップS272の処理はスキップされる。
【0284】
次に、ステップS273において、処理対象タスクにかかるタスク設定531の一時変更フラグ542が参照されることにより、当該処理対象タスクの実行優先度534が一時的な変更にかかるものか否かが判定される。その結果、一時的な変更と判定されたときは(ステップS273でYES)、ステップS274において、バックアップされている実行優先度データが用いられ、当該処理対象タスクにかかる実行優先度534が元の値に変更される。一方、一時的な変更ではないと判定されたときは(ステップS273でNO)、ステップS274の処理はスキップされる。その後、上記図38のステップS253に戻り、未実行のタスクが適宜選択されて処理が繰り返される。
【0285】
次に、図38のステップS253において、全てのタスクを実行し終えたと判定されたときの処理(ステップS253でNO)について説明する。このときは、次回起床時刻305を設定するための処理が実行される。具体的には、まず、図40のステップS275において、タスクデータ530内の全てのタスク設定531についての次回実行時刻537が読み込まれる。続くステップS276において、全タスクのうち、次回実行時刻537が最も早い時刻のタスクが検出される。そして、当該最も早い次回実行時刻が現在時刻から30分以内であるか否かが判定される。当該判定の結果、30分以内であると判定されたときは(ステップS276でYES)、ステップS277において、現在時刻の30分後の時刻を次回起床時刻305として設定する。つまり、一旦タスクが実行されると、その後、最低30分間はタスクの実行が行われないように設定されることになる。これにより、あまりに頻繁に接続が行われてしまうことを防ぎ、ゲーム装置1の更なる省電力化や、ネットワークトラフィックの負荷の軽減を図ることが可能となる。そして、当該タスク実行処理は終了する。
【0286】
一方、ステップS276の判定の結果、最も早い次回実行時刻は現在時刻から30分以内ではないと判定されたときは(ステップS276でNO)、ステップS278において、当該最も早い次回実行時刻537が現在時刻から3時間後よりも遅い時刻であるか否かが判定される。その結果、3時間後よりも遅いと判定されたときは(ステップS278でYES)、ステップS279において、現在時刻から3時間後の時刻が次回起床時刻305として設定される。これにより、少なくとも3時間後には接続を試みることになるので、定期的にゲーム装置1に接続を試みさせることができる。なお、上記のような30分や3時間という値はあくまで一例であり、設定時刻はこれらに限定されるものではない。
【0287】
一方、最も早い次回実行時刻537は現在時刻から3時間後よりも遅い時刻ではないと判定されたときは(ステップS278でNO)、当該最も早い次回実行時刻は、30分から3時間の間ということになり、当該最も早い次回実行時刻が次回起床時刻305として設定される。そして、当該タスク実行処理が終了する。以上で、タスク実行処理の説明を終了する。
【0288】
[インストール処理]
次に、上記ステップS272で示したインストール処理の詳細を説明する。本処理では、主に、システムのアップデートに関する処理、無料アプリや体験版ゲーム等の新規インストール処理、既存アプリの更新処理等が行われる。図42図43は、当該インストール処理の詳細を示すフローチャートである。まず、ステップS311において、インストールリスト580自体がアップデートされているか否かが判定される。これは、インストールリスト580のリストリビジョン582について、上記タスク実行処理における取得前のインストールリストのものと取得後のインストールリストのものとが比較されることで判定される。
【0289】
当該判定の結果、インストールリスト580自体に更新がない(リストリビジョン582が同じ値)と判定されたときは(ステップS311でNO)、本インストール処理は終了する。一方、インストールリスト580自体が更新されていると判定されたときは(ステップS311でNO)、次に、ステップS312において、タスク実行処理において取得された最新のインストールリスト580における最新システム更新日時581が、本体設定データ560に記憶されているゲーム装置1自身の最新更新日時よりも新しいか否かが判定される。その結果、新しいと判定されたときは(ステップS312でYES)、ステップS313において、ダウンロードリスト590に、「システムアップデート」を示す案件情報591が追加される。このとき、インストール優先度594には最上位で優先されることを示す値が設定される。一方、ステップS312の判定の結果、上記更新日時が新しくないと判定されたときは(ステップS312でNO)、当該ステップS313の処理はスキップされる。
【0290】
次に、ステップS314において、インストールリスト580に含まれている全てのアプリ情報584について、インストールを行うか否かの判断を行ったか否かが判定される。その結果、全てについて判断を行ったと判定されたときは(ステップS314でYES),後述するステップS318に処理が進められる。一方、まだ未判断のアプリ情報584が残っているときは(ステップS314でNO)、次に、ステップS315において、当該インストール判断が行われていないアプリ情報584からいずれか1つが選択される。
【0291】
次に、ステップS316において、当該選択されたアプリ情報584のレーティング情報588と本体設定データ560に記憶されているユーザの年齢情報に基づいて、レーティングの条件が満たされているか否かが判定される。その結果、レーティングの条件が満たされていると判定されたときは(ステップS316でYES)、ステップS317にお
いて、適宜インストール優先度594が設定された案件情報591がダウンロードリスト590に追加される。なお、ここで設定されるインストール優先度594には、上記システムアップデートにかかる優先度よりは低い値が設定される。そして、上記ステップS314に戻り、全てのアプリ情報584について判断されるまで、処理が繰り返される。一方、ステップS316の判定においてレーティングの条件が満たされていないと判定されたときは(ステップS316でNO)、ステップS317の処理はスキップされて上記ステップS314に戻される。つまり、レーティングの条件を満たさないアプリケーションについてはダウンロードリスト590に追加されないので、インストールが行われないことになる。
【0292】
次に、上記ステップS314の判定の結果、インストールリスト580の全てのアプリ情報584について判断が行われた(換言すれば、ダウンロードリスト590が完成した)ときの処理について説明する。この場合は、ダウンロードリスト590で示される各アプリケーション等のデータが適宜ダウンロードされてインストールされる。ここで、当該データのダウンロード先に関して説明する。本実施形態では、まず、ショップサーバと呼ばれる専用のサーバにアクセスする。そして、アプリIDを当該ショップサーバに通知すると、当該アプリのダウンロード先を示すURLがショップサーバから送られてくる。そして、当該URLに基づいて所定のサーバから無料アプリケーション等の実体となるデータ(プログラムファイル等)がダウンロードされる。
【0293】
次に、ステップS318において、ダウンロードリスト590に挙げられている案件情報591がインストール優先度594の順にソートされる。
【0294】
次に、図43のステップS319において、ダウンロードリスト590に挙げられている案件情報591の全てについてダウンロードが行われたか否かが判定される。その結果、全ての案件情報591についてダウンロードが終わったと判定されたときは(ステップS319でYES)、インストール処理は終了する。
【0295】
一方、ステップS319の判定の結果、案件情報591の全てについてダウンロードが行われていないと判定されたときは(ステップS319でNO)、ステップS320において、まだダウンロードが行われていない案件情報591の中から、インストール優先度594が最上位の案件情報591が1つ選択される。以下、当該選択された案件情報591を処理対象案件情報と呼ぶ。
【0296】
次に、ステップS321において、処理対象案件情報がシステムのアップデートにかかるものか否かが判定される。その結果、システムアップデートにかかる案件と判定されたときは(ステップS321でYES)、ステップS322において、上記ショップサーバへのアクセスが行われ、システムの構成要素の一覧を示すデータが取得される。ここで、本実施形態にかかるゲーム装置1のシステムは、複数のプログラムによって構成されている。そのため、当該システムを構成する個々のプログラムのことを、構成要素と呼んでいる。例えば、上述したメニュー処理やローカル通信用BG処理等も、ここでいう構成要素に該当する。つまり、上記システムの構成要素の一覧とは、ゲーム装置1のシステムを構成するファイル(プログラム、データ)群のうち、更新が必要となるファイルの一覧である。
【0297】
次に、ステップS323において、上記構成要素の一覧で示されている全構成要素のインストールが終了したかが判定される。全て終了したと判定されたときは(ステップS323でYES)、上記ステップS319に戻り、処理が繰り返されることで、システムアップデート以外の他の案件情報の処理に移る。一方、全ては終了していないと判定されたときは(ステップS323でNO)、ステップS324において、未インストールの構成
要素のうち1つが選択される。次に、ステップS325において、選択された構成要素のデータを取得するためのリクエストが上記ショップサーバに送信される。続くステップS326において、当該ショップサーバから送信されてくる、上記選択された構成要素のダウンロード元を示すURL情報が受信される。
【0298】
次に、ステップS327において、当該URLで示されるサーバへの接続が行われ、構成要素のダウンロードが開始される。ダウンロードが開始されると、ステップS328において、ダウンロードと並行して、オン・ザ・フライ用キャッシュ600にダウンロードされつつある構成要素のデータが展開される。つまり、オン・ザ・フライでインストールされる。その後、ダウンロードおよびオン・ザ・フライでのインストールが終われば(オン・ザ・フライであるため、ほぼ同時刻に終了することになる)、上記ステップS323に戻り、処理が繰り返される。
【0299】
次に、上記ステップS321の判定の結果、処理対象案件情報がシステムのアップデートにかかるものではない(ステップS321でNO)と判定されたときの処理について説明する。このような場合は、処理対象案件情報で示される内容は、無料アプリケーションやアプリケーションの体験版等であると考えられる。この場合は、まず、ステップS329において、処理対象案件情報で示されるアプリID592がショップサーバに送信される。ここで、ゲーム装置1の固有情報(シリアルナンバー等)も同時に送信される。次に、ステップS330において、ショップサーバから送信されてくる、ダウンロード元のURLを示す情報が受信される。なお、ショップサーバは、上記アプリIDとともに送信されたゲーム装置1の固有情報を分析し、PC等の他の装置からではなくゲーム装置1からのリクエストであったか否かを判別する。ゲーム装置1からのリクエストであれば、上記ダウンロード元のURLを示す情報をゲーム装置1へ返す。
【0300】
続くステップS331において、当該URLで示されるサーバに接続され、上記無料アプリケーション等のデータのダウンロードが開始される。この際、アプリケーションを起動する前にアプリケーションの正当性の認証を行うためのキーもダウンロードされる。ダウンロードが開始されれば、ステップS332において、NANDフラッシュメモリ33のプログラム領域500のアプリケーションプログラム509として、オン・ザ・フライでインストールされる(既存のアプリケーションであれば上書きされ、新規のアプリケーションであれば、新たなアプリケーションプログラム509として展開される)。また、このとき、当該インストールされたアプリケーションが新規のアプリケーションであれば、当該新規インストールアプリケーションに対応するアプリ関連データ550も生成される。その結果、当該新規アプリケーションが上記ステップS97におけるアプリケーションのスキャン対象となり、メニュー内に表示されることになる。
【0301】
次に、ステップS333において、上記オン・ザ・フライでのインストールが終われば、当該インストールされたアプリケーションに対応するアプリケーション領域551の新規インストールフラグ554がオンに設定される。そして、上記ステップS319に戻り、処理が繰り返される。以上で、インストール処理の説明を終了する。
【0302】
以上で、第1の実施形態にかかる各種処理の説明を終了する。
【0303】
上記で説明したように、本実施形態では、CPU31に電力が供給されていない状態でも、上記タスクの実行条件が満たされれば、自動的にCPU31に通電し、APへの接続が試みられる。その結果、ユーザが気付かないうちにネットワークへ接続することが可能となる。また、タスクの実行条件が満たされないうちは、CPU31には電力は供給されないため、消費電力を節約することも可能である。これにより、携帯型ゲーム装置のような、常時接続を前提としていない情報端末であっても、常時接続しているかのような振る
舞いを行わせつつ、消費電力の節約も可能となる。
【0304】
また、ユーザが気付かないうちにネットワーク接続すると共に、更に、上述したような無料アプリケーション等のダウンロード及びインストールも行っている。そのため、ユーザが次にゲーム装置1を動作させた際に、新しいアプリケーションが加わっている事等による驚きを与えることも可能となる。また、このようなアプリケーション等は既にインストール、あるいはアップデート済みになっているため、ユーザに待ち時間を与えることを防ぐ事もできる。
【0305】
また、上記「受信タスク」を実行した結果、所定のアプリケーションにかかるネットワークサービスが終了した通知を受信することができ、また、終了した旨をユーザに通知している。更に、この場合は、当該ネットワークサービスにかかるタスクを消去するようにしている。これにより、ユーザは主体的に情報収集を行わなくても、所定のネットワークサービスが終了したことを知ることが可能となるほか、不要となるタスクを消去することでメモリ容量を節約できる。
【0306】
また、上記実施形態では、専用AP101に応じて異なるポリシーデータを配信することも可能となっている。そのため、ポリシーサーバへの接続に用いたAP毎に、タスクの実行優先度を変化させることができる。これにより、様々な場所に応じて実行されるタスクおよび実行順をある程度変化させることが可能となり、ユーザに対して、ゲーム装置1を持ち歩く楽しみを提供できる。すなわち、ゲーム装置1を所持していろいろな場所に外出させる楽しみを与えることができる。
【0307】
更に、上記実施形態では、ポリシーサーバに接続した際に、専用AP101ごとに異なる識別子だけではなく、ゲーム装置本体に設定されている国情報をも用いて、配信するポリシーデータを決定している。そのため例えば同じ専用AP101に接続した複数のゲーム装置1であっても、それぞれに設定されている国情報に応じて異なるポリシーデータを受信させることができる。
【0308】
また、専用AP101ではない、例えばユーザの自宅のAP102を経由してポリシーサーバにアクセスしたようなときでも、上記国情報に応じて異なるポリシーデータを配信することが可能である。
【0309】
また、上記実施形態では、ポリシーデータの適用に際して、アプリIDとタスクIDを用いているため、アプリケーション毎にタスクの実行優先度を変更することが可能である。そのため、上記国情報と当該アプリケーションとの組み合わせで、より柔軟な実行優先度の変更が可能である。
【0310】
また、インストール処理に関して、システムアップデートの場合は、オン・ザ・フライでインストールしながらも、その反映についてはユーザに確認するようにしている。そして、確認がとれれば、ファイル名のリネームおよび再起動によりシステムのアップデートを反映している。これにより、システムのアップデートに際にユーザに与える待ち時間を短縮することができる。また、システムアップデート以外の、例えば無料アプリケーション等の、影響度の低いアプリケーションのインストールについてはユーザの確認無しでインストールする。そのため、ユーザの利便性をより高めることができるほか、ユーザが気づかないうちにインストールが行われており、ゲーム装置1のソフトウェア構成が変化しているので、ユーザに新たな驚きを与えることができ、かつ、新たにインストールされたアプリケーションをプレイしてもらうためのきっかけを与えることができる。
【0311】
また、タスクの次回実行時刻(次回起床時刻)について、次回実行予定時刻が現在時刻
からあまりに近い場合は、所定時間内はタスクが実行されないように調整している。これにより、あまりに短い時間間隔でタスクが頻繁に実行されることを防ぎ、無駄な処理や無駄なネットワークトラフィックを省くことが可能となる。また、次回実行時刻があまりにも先の時刻すぎる場合も時間調整を行っているため、ある程度定期的に接続を試みさせることが可能である。
【0312】
また、上記実行優先度として、単純に優先度を示す”HIGH”、”MEDIUM”、”LOW”の
他、実行しないことを示す”STOPPED”や、最優先で実行させる”EXPEDITE”という値を
利用している。そして、上記のようにポリシーデータを受信させて、これら実行優先度の変更が可能となっている。そのため、”STOPPED”や”EXPEDITE”を利用することで、ゲ
ーム装置1で実行されるタスクに関して、ある程度、サーバ側(ネットワークサービスの提供者側)から制御することも可能である。
【0313】
なお、上記実施形態においては、「スリープモード」に移行する操作やスリープモードを解除する操作として、折りたたみ式のハウジングを有するゲーム装置1を閉じる/開く、という操作を例に挙げたが、これに限らず、ボタン操作で移行や解除をするようにしてもよい。
【0314】
また、上記実施形態では、無線モジュール処理における「スリープモード」か否かの判定で、給電状態フラグ304にアクセスできなければスリープ中と判定し、スリープ中であればこれを解除する命令をCPU31に発行する例を挙げた。「スリープモード」の解除については、この例の他、「スリープモード」であるか否かを直接的に判断するのではなく、次のような処理を行っても良い。例えば、ゲーム装置1が現在「スリープモード」であるか否かに関わらず、無線モジュール34は、CPU31に対してスリープを解除するための命令を発行する。そして、CPU31側において、命令を受けたときにスリープ中であったならばスリープの解除を行い、スリープ中でないならば当該命令を無視する、という処理を行うようにしても良い。また、このような処理は、無線モジュール34とCPU31との間だけではなく、マイコン37とCPU31との間等でも適用可能である。つまり、「スリープモード」か否かを判断し、「スリープモード」であるときはこれを解除するための処理全般について、上記のような処理方法を適用可能である。
【0315】
また、上記実施形態では、1つのタスクとしては所定のデータの「送信」あるいは「受信」のみを行うものを「タスク」の例としてあげたが、この他、「送受信」を行う処理を1つのタスクとした場合であっても本発明は適用可能である。
【0316】
また、上記実施形態では、タスクの次回実行時刻537に基づいて次回起床時刻305を設定していた。この他、タスクの次回実行時刻に関係なく、予め決められた所定の時間間隔で定期的にAPのスキャンを行うようにしてもよい。
【0317】
また、上記実施形態では、専用AP101の一例として、上記のようなベンダー特定情報がビーコンに含まれるか否かで専用AP101を識別していた。この他、このようなベンダー特定情報を有していない一般のAP102(例えばユーザの自宅のAP)についても、専用APと同じ扱いで動作させるようにしても良い。この場合は、このような一般AP102のESSIDを上記専用AP識別情報404として記憶させるようにする。そして、受信したビーコンに含まれるESSIDが当該記憶させたESSIDと一致するか否かを判定することで、上記専用AP101の場合と同様の処理を行うようにしても良い。
【0318】
また、専用AP101の識別に関しては、上記ベンダー特定情報の代わりとして、専用AP101のMACアドレスやIPアドレスを利用するようにしても良い。
【0319】
また、上記実施形態では、ポリシーデータの取得に際して、本体設定データ560内の国情報を用いる場合を例に挙げたが、この他、ゲーム装置1の製造番号やシリアル番号、IPアドレス、ユーザの居住地域、ユーザ名、ユーザの性別や誕生日、ユーザの好きな色、のような情報を利用してもよい。これらの情報はいずれも本体設定データ560に記憶され、また、その内容もユーザによって適宜変更可能とすればよい。
【0320】
また、上記実施形態では、ポリシーデータの受信に関して、上記専用AP101経由の場合は、当該専用AP101を示すAP識別子+国情報に基づいてポリシーデータが選択され、専用AP101経由ではないときは国情報のみに基づいてポリシーデータが選択されていた。この他、本体設定データ560の情報を参照することなく、例えば、専用AP101経由時は、AP識別子のみに基づいてポリシーデータが選択され、専用AP101経由ではないときは、予め用意されている共通的なポリシーデータを選択したり、あるいは、ポリシーデータの受信自体を行わないようにしてもよい。
【0321】
また、上記実施形態では、ポリシーデータについてはポリシーサーバに記憶する場合を例に挙げていたが、この他、専用APに上記ポリシーデータを記憶させておき、専用AP101との接続が確立した後、ゲーム装置1にポリシーデータがダウンロードされるようにしてもよい。また、APから発信されるビーコンに上記ポリシーデータを含めるようにしても良い。この場合は、APへの接続が確立せずとも、APの探索と同時にポリシーデータの受信および適用が可能となる。また、このような場合も、専用AP101毎に内容の異なったポリシーデータを記憶させればよい。但し、ポリシーデータの管理の観点からすれば、一元管理が可能なように1つのポリシーサーバ103に格納されるほうが好ましい。
【0322】
また、タスクの生成に関して、上記ポリシーデータにタスクを生成するためのデータを含めるようにしても良い。この場合は、ポリシーデータを受信した後に、ゲーム装置1において、当該ポリシーデータに含まれるタスク生成用のデータ(パラメータ)に基づいて新規のタスクが生成され、実行されることになる。
【0323】
また、システムのアップデート処理に関して、上記実施形態では、システムアップデートの要否の判断に、最新システムの更新日時を利用していたが、これに限らず、バージョン情報を利用するようにしても良い。この場合は、システムのアップデート用データにバージョン情報を含ませるようにすればよい。
【0324】
また、システムアップデートの反映の確認の際、上記実施形態では、反映しないことが選ばれたとき、アップデート用のデータをすぐに破棄していた。これに限らず、何度か確認を行い、反映しないことが所定回数続けて指示されたときにアップデート用のデータを破棄するようにしてもよい。これにより、ユーザの誤操作によってアップデート用のデータが破棄されてしまうことを防ぐことが可能となる。
【0325】
また、上記実施形態では、タスクに「消尽回数」が設定されていた。そして、消尽回数が0になったタスクであっても、ポリシーデータの適用の結果、消尽回数が加算されることがあった(つまり、タスクが復活していた)。このような、ポリシーデータによるタスクの復活に限らず、ゲーム装置1のシステムが消尽回数が0になったタスクの中からランダムに選択したタスクについて、その消尽回数を加算するような処理を行っても良い。
【0326】
また、その他、消尽回数を利用して、タスクの実行頻度が徐々に低下していくような制御を行っても良い。例えば、以下のような制御を行うことが考えられる。
(1)まず、消尽回数が初期値として30に設定されているタスクがあり、当該タスクが毎日実行されたとする。このとき、毎日実行されたか否かの判断方法としては、消尽回
数が減ったか否かの確認を毎日行ってもよいし、30日経過した時点で消尽回数が0になっているか否かを確認するようにしてもよい。また、何日か実行されない日があっても許容するようにしてもよい。
(2)毎日タスクが実行されて、消尽回数が0になった後、30日間は、10日に1回タスクが実行されるようにする。例えば、毎回1/10の確率でタスクが実行されるようにしたり、10日目、20日目、30日目というように、適宜実行日を決めるようにしてもよい。
(3)更に、その後の90日間は、30日に1回タスクが実行されるようにする。例えば、1/30の確率で実行させたり、実行日を予め決めるようにしてもよい。
(4)更に、その後の120日間は、60日に1回タスクが実行されるようにする。例えば、1/60の確率でタスクを実行させたり、予め実行日を決めるようにしてもよい。
(5)そして、上記の120日が経過すれば、それ以降は実行しないようにする。例えば、タスクを消去してもよいし、消去せずポリシーデータによる制御などの別のきっかけで実行する余地を残してもよい。
これにより、しばらく使用していなかったアプリケーションに関するタスクの消尽回数が何らかのきっかけで復活しタスクが実行されるので、ユーザに驚きを与えることができる。
【0327】
また、上記実施形態では、ゲーム装置1が起動されたときに実行される起動時処理においてメニュー処理が実行された結果、ゲーム装置1にインストールされているアプリケーションがスキャンされ、その一覧がメニューとして表示されていた。そのため、例えば、ゲーム装置1が「スリープモード」のときにユーザが電源ボタン14Fを押下する(つまり、ゲーム装置1を起動させる)と、「スリープモード」が解除され、図4等で示したようなアプリケーションアイコンが並べられたメニュー画面が即時に表示される。また、ゲーム装置1に通電が全く行われていない状態(電源オフの状態)のときにユーザが電源ボタン14Fを押下してゲーム装置1の電源をオンにしたときも同様である。このように、アプリケーションの一覧であるメニュー画面はゲーム装置1の起動時に表示されるものであるが、この「起動時」に関しては、上記のような即時の場合に限らない。例えば、ゲーム装置1を起動させたときは、まず、メーカーのロゴや「ユーザへの注意事項」のような通知事項が表示された後に、上記のようなメニュー画面が表示されるような場合も含む。また、その他、メニューが階層構造であるような場合も含む。例えば、起動時は、まず、「ゲーム」「音楽」「写真」等のように、ゲーム装置1にインストールされている各種アプリのジャンルを示すジャンルメニューが表示され、いずれかのジャンルが選択されると、このジャンルに属するアプリケーションの一覧が表示されるような場合も含む。さらに複数の階層にわたってもよい。
【0328】
また、上記実施形態では、タスク生成に際して(上記ステップS129やステップS130)、実行優先度に任意の値を設定する場合を例に挙げた。しかし、実行優先度については、タスク生成時に必ずしも何らかの値が設定される必要はなく、実行優先度が未設定の状態でタスクが生成されるようにしても良い。そして、上記ポリシーデータの適用によって初めて実行優先度が設定されるようにしても良い。更には、実行優先度だけに限らず、消尽回数等についても、最初は未設定のままタスクが生成され、ポリシーデータの適用によって初めてその内容が設定されるようにしても良い。
【0329】
また、上記実施形態では、携帯型のゲーム装置を情報端末の例としたが、その他の携帯型情報端末、例えば、無線LAN機能を搭載したPDAやノートパソコン等にも有用である。
【0330】
(第2の実施形態)
次に、本発明の第2の実施形態について説明する。第2の実施形態では、上述の第1の
実施形態で説明したような処理を用いたアプリケーションの一例として、「ボトルメールアプリケーション」というアプリケーション処理(以下、単にボトルメールアプリと呼ぶ)について説明する。なお、当該第2の実施形態に係るゲーム装置は、上述した第1の実施形態と同様であるため、同一の参照符号を付して詳細な説明を省略する。
【0331】
図44および図45は、本発明の第2の実施形態に係るボトルメールアプリの処理概要を示す図である。図44は、ゲーム装置1と、第1の実施形態で図15を用いて説明したすれ違い通信用の送信用ボックス523および受信用ボックス524(以下の説明では、「すれ違い用送信ボックス」、「すれ違い用受信ボックス」と呼ぶ)と、タスクにおける通信で用いられるタスク受信キャッシュ553およびタスク送信用データ556とを抜き出して模式的に示した図である。図44では、ゲーム装置1を示す四角形の左上にすれ違い用受信ボックス524を示し、当該四角形の右側に、上から順にタスク受信キャッシュ553、タスク送信用データ556、すれ違い用送信ボックス523を縦に並べて示している。
【0332】
このような模式図を前提として、図45を用いて第2の実施形態にかかる処理概要を説明する。図45においては、ゲーム装置A〜ゲーム装置Dが示されている。これらのゲーム装置にはボトルメールアプリがインストールされているものとする。また、図45では、ボトルメールサーバも示されている。本実施形態にかかるボトルメールアプリは、ゲーム装置Aで作成された「ボトルメール」と呼ばれるメール(図45では「BM」として示す)を、すれ違い通信を用いて他のゲーム装置に次々に転送していく、つまり、メールを放流できるアプリケーションである。
【0333】
図45において、まず、ゲーム装置Aでボトルメールが作成され、すれ違い用の送信ボックスに格納される。このとき、当該ボトルメールには「世代情報」が設定される。この「世代情報」で示される回数だけ、当該ボトルメールの転送が可能であるが、「世代情報」を設定しない場合は、回数に関係なく当該ボトルメールの転送が可能である。その後、すれ違い通信が行われることで、当該ボトルメールがゲーム装置Aからゲーム装置Bに移動する。すなわち、ゲーム装置Aのすれ違い用送信ボックスからゲーム装置Bのすれ違い用受信ボックスに移動される。
【0334】
その後、ゲーム装置Bにおいてボトルメールアプリが実行されると、ゲーム装置Bのすれ違い用受信ボックスからすれ違い用送信ボックスへ、当該ボトルメールが移動される。このとき、ゲーム装置Bにおいて、ボトルメールの世代情報に所定値が加算される。更に、ゲーム装置Bにおいて、ボトルメールサーバへ送信するための付加情報(図45では「Info」と示す)が生成される。この「Info」には、当該ボトルメールと、ゲーム装置Bの所有者の名前と、上記加算後の世代情報等が含まれる。そして、当該「Info」を適当な時期にボトルメールサーバに送信するための「送信タスク」も生成・登録される。その結果、適当なタイミングで「送信タスク」が実行され、ゲーム装置Bから「Info」がボトルメールサーバに送信される。ボトルメールサーバでは、当該情報を履歴情報(図45では「Log」と示す)として蓄積する。
【0335】
その後、ゲーム装置Bとゲーム装置Cとの間ですれ違い通信が発生し、ボトルメールがゲーム装置Bからゲーム装置Cに移動する。その後、ゲーム装置Cにおいてボトルメールアプリが実行されると、上記ゲーム装置Bの場合と同様に、すれ違い用受信ボックスからすれ違い用送信ボックスへ当該ボトルメールが移動され、そして、世代情報が加算され、上記「Info」およびこれに関する「送信タスク」も生成される。そして、適当なタイミングで、ゲーム装置Cからも「Info」がボトルメールサーバに送信され、「Log」に蓄積される。
【0336】
その後、ゲーム装置Cとゲーム装置Dの間ですれ違い通信が発生し、ボトルメールがゲーム装置Cからゲーム装置Dに移動する。ゲーム装置Dにおいても、ボトルメールアプリが実行されることによって、すれ違い用受信ボックスからすれ違い用送信ボックスへの当該ボトルメールの移動、上記世代情報の加算や「送信タスク」による「Info」の送信が行われる。
【0337】
このように、ゲーム装置Aで作成されたボトルメールが、すれ違い通信によって他のゲーム装置に次々に転送されている。その一方で、当該ボトルメールを受信したゲーム装置B、C、Dでは、上記「Info」が適宜ボトルメールサーバに送信されている。そのため、ゲーム装置Aのユーザは、ボトルメールサーバに蓄積されている「Log」を取得する事で、自己の放流したボトルメールが何人の間で流通したかや、最後の受取人が誰か等、放流したボトルメールのその後の状況を知ることが可能となる。そして、本実施形態では、このような「Log」を取得するために「受信タスク」を生成し、適当な時期に「Log」を受信するようにしている。
【0338】
つまり、第2の実施形態では、「ローカル通信(すれ違い通信)」と「インターネット通信」とを連携させることにより、今までにない新たな楽しみ方が可能なアプリケーションを提供することが可能である。
【0339】
以下、第2の実施形態にかかる処理の詳細について説明する。上記のような処理は、ゲーム装置1において実行される「ボトルメールアプリ処理」と、ボトルメールサーバにおいて実行される「ボトルメールサーバ処理」とが連動することで実現される。まず、本処理において用いられるデータに関して説明する。ゲーム装置1において実行される処理においては、基本的には、上記第1の実施形態と同様のデータが用いられる。但し、「ボトルメールアプリ」のデータとして、上記「ボトルメール」や上記付加情報(図45の「Info」)を示すデータが適宜生成されることになる。
【0340】
一方、ボトルメールサーバでは、上述したような処理を実行するためのプログラムの他、上述した履歴情報データ(図45の「Log」)が記憶されることになる。図46は、当該履歴情報データのデータ構造の一例を示す図である。図46に示すように、履歴情報データは、複数のボトルメール履歴データ161の集合で構成され、各ボトルメール履歴データ161は、アップロード数162と複数の転送情報163で構成される。アップロード数162は、ゲーム装置1から上記付加情報等がアップロードされた回数を示す。この値は、換言すれば、そのボトルメールが転送された回数を示す事にもなる。転送情報163は、ボトルメールの転送先となったゲーム装置1(図45ではゲーム装置B〜D)に関する情報であり、世代情報164、送信者名165、AP情報166、メール内容167の集合で構成される。世代情報164および送信者名165は、ゲーム装置1から上記付加情報として送信されてきたデータである。AP情報166は、上記付加情報の送信の際に用いられたAPを示すための情報である。この情報と後述するAP地域テーブルに基づき、付加情報が送信されたときにゲーム装置1が居た地域が特定可能となる。メール内容167は、付加情報と同時に送信されてきたボトルメールの内容(本文)である。転送先でボトルメールの内容が加工されることも想定し、その変更履歴を参照可能なように転送先それぞれにおけるボトルメールを送信したものである。また、その他、図示は省略するが、各ボトルメールを一意に識別するための情報等も含まれる。
【0341】
また、ボトルメールサーバには、APの設置されている地域を特定するためのデータも記憶される。図47は、APとその設置されている地域との対応関係を定義したAP地域テーブルの一例である。図47に示すようなテーブルに相当するデータに基づき、ボトルメールサーバは上記AP情報166に基づいた地域の特定が可能となる。
【0342】
図48および図49は、ゲーム装置1で実行される上記ボトルメールアプリ処理の詳細を示すフローチャートである。なお、図48において、ステップS351〜S354の処理と、S367〜S373にかかる処理は、上記図28および図29で説明したステップS121〜S124の処理、および、ステップS134〜S140の処理と同様である(これらの処理で扱われるデータの内容は、上述のようなボトルメールに関するデータとなる)。そのため、これらの処理については詳細な説明は省略する。
【0343】
図48において、ステップS354の次に、ステップS355において、ボトルメールに設定されている(付随している)世代情報に所定値が加算される。次に、ステップS356において、世代情報が閾値未満であるか否かが判定される。この閾値は、例えば、ボトルメールアプリにおける規定値として予め設定されている。当該判定の結果、世代情報が閾値未満ではないと判定されたときは(ステップS356でNO)、当該ボトルメールはこれ以上転送できないとして、後述するステップS360に処理が進められる。
【0344】
一方、閾値未満であると判定されたときは(ステップS356でYES)、当該ボトルメールは転送可能であることを示すため、ステップS357において、当該ボトルメールを、すれ違い通信を用いて他のゲーム装置に転送するための処理が実行される。すなわち、当該ボトルメールアプリに対応付けられているスロット521のアプリID522に、当該ボトルメールアプリを示す値が記憶される。更に、上記ステップS354で取得されたボトルメール(セーブデータ555内のすれ違い受信データ558に格納されている)が、当該スロット521の送信用ボックス523に移動される。
【0345】
次に、ステップS358において、ボトルメールサーバに送信するための付加情報データ(図45の「Info」)が生成されてセーブデータ555に格納される。すなわち、上記世代情報と、本体設定データ560から取得されるユーザ名を含むデータが作成されて、上記ボトルメールと共にタスク送信用データ556に格納される。次に、ステップS359において、上記ステップS358で準備されたデータを適当な時期にボトルメールサーバに送信するための「送信タスク」が生成される。
【0346】
次に、ステップS360において、新たに放流するボトルメールが(ユーザによって)作成されたか否かが判定される。その結果、新たなボトルメールが作成されていなければ(ステップS360でNO)、後述のステップS363に処理が進められる。一方、新たなボトルメールが作成されていれば(ステップS360でYES)、次に、ステップS361において、当該新たに作成されたボトルメールをすれ違い通信によって他のゲーム装置1に転送するための準備が行われる。すなわち、上記アプリID522にボトルメールアプリを示す値が格納される。更に、送信用ボックス523に当該新たに作成されたボトルメールが格納される。なお、上記ステップS357においてもボトルメールが格納されていた場合は、結果的に、他のゲーム装置1から受けたボトルメールと、自己の作成したボトルメールとが併存して格納される状態となる。
【0347】
次に、ステップS362において、自己の作成したボトルメールの放流後の状況を示す履歴情報データ(上記図25の「Log」)をボトルメールサーバから取得するための「受信タスク」が生成される。
【0348】
次に、図49のステップS363において、上記放流後のボトルメールの状況を確認する旨の指示がユーザによって行われたか否かが判定される。その結果、当該指示が行われていないと判定されたときは(ステップS363でNO)、後述のステップS367に処理が進められる。
【0349】
一方、上記確認指示がユーザによって行われたと判定されたときは(ステップS363
でYES)、ステップS364において、上記放流後のボトルメールの状況を示す履歴情報データをボトルメールサーバから受信するための即時実行型のタスクが生成され、即時に実行される。次に、ステップS365において、上記タスクの即時実行の結果、タスク受信キャッシュ553に当該ボトルメールアプリ向けの新規データ(ここでは受信された履歴情報データ)が存在するか否かが判定される。その結果、存在していなければ(ステップS365でNO)、後述するステップS367に処理が進められる。一方、ボトルメールアプリ向けの新規データがあると判定されたときは(ステップS365でYES)、ステップS366において、当該新規データが当該ボトルメールアプリのセーブデータ555内のタスク受信データ557に移動される。このようにセーブデータ555内に移動されることで、本ボトルメールアプリから当該履歴情報データにアクセス可能となる。
【0350】
その後、ステップS367において、図48のステップS362または図49のステップS364で生成した「受信タスク」の結果、本ボトルメールアプリ向けの何らかの新規なデータが在るか否かが判定される。その結果、新規なデータがなければ(ステップS367でNO)、上記ステップS351に戻り処理が繰り返される。一方、新規なデータがあるときは(ステップS367でYES)、ステップS368〜S373において、当該ボトルメールアプリに関するネットワークサービスが終了したか否かを判定する処理と、サービス終了のときはタスクとすれ違い通信用のデータをクリアする処理が実行される。この処理は、図29を用いて上述したステップS135〜S140の処理と同様であるため、詳細な説明は省略する。
【0351】
ステップS373の処理が終われば、ステップS374において、上記受信履歴情報が参照されて、「世代情報」、「受取人の名前」、「アップロード者数」、「地域」等の情報が表示される。ここで、「地域」に関しては、後述するボトルメールサーバの処理において、サーバ側で判断されて付加された情報である。
【0352】
次に、ステップS375において、本ボトルメールアプリを終了するか否かが判定され、終了しないと判定されたときは(ステップS375でNO)、上記ステップS351に戻り、処理が繰り返され、終了すると判定されたときは(ステップS375でYES)、本ボトルメールアプリ処理が終了される。以上で、ボトルメールアプリの説明を終了する。
【0353】
次に、上記ボトルメールアプリに対応して、上記ボトルメールサーバで実行される処理について説明する。図50は、当該ボトルメールサーバの処理の詳細を示すフローチャートである。図50において、まず、ステップS391において、上述したような「送信タスク」(図48のステップS359で生成されたタスク)の実行によりゲーム装置1から送信されたデータ(上記図45の「Info」)を受信したか否かが判定される。その結果、受信していないと判定されたときは(ステップS391でNO)、後述のステップS394に処理が進められる。一方、受信したと判定されたときは(ステップS391でYES)、ステップS392において、受信したデータが上記ボトルメール履歴データ161として格納される(上記図45の「Log」として格納される)。
【0354】
次に、ステップS393において、当該受信したボトルメールにかかるアップロード数162に1が加算される。
【0355】
次に、ステップS394において、上記ゲーム装置1からの履歴情報データのリクエストがあったか否かが判定される。当該リクエストは、上記「受信タスク」(図48のステップS362または図49のステップS364で生成されたタスク)の実行によって発行されるものである。当該判定の結果、リクエストを受信していないと判定されたときは(ステップS394でNO)、上記ステップS391に戻り、処理が繰り返される。一方、
リクエストを受信したと判定されたときは(ステップS394でYES)、ステップS395において、上記履歴情報データが参照され、当該リクエストの内容に対応するボトルメール履歴データ161が読み出される。なお、ボトルメール履歴データ161の特定手法としては、例えば、ボトルメールの作成者と作成日時、作成されたゲーム装置1に固有の番号等に基づいて所定のID番号を生成し、これをボトルメール自体のデータに埋め込むようにしておく。そして、上記リクエストに際して、当該IDを当該リクエストに含めることで、ボトルメール履歴データ161を特定すること等が考えられる。
【0356】
次に、読み出されたボトルメール履歴データ161のAP情報166が取得され上記AP地域テーブル(図47参照)が参照されることで、当該AP情報166に対応付けられている地域172が取得される。
【0357】
次に、上記読み出されたボトルメール履歴データ161の内容と上記地域172に基づいて履歴情報データが作成され、リクエスト元のゲーム装置1に送信される。その後、上記ステップS391に戻って処理が繰り返される。以上で、ボトルメールサーバの処理の説明を終了する。
【0358】
上記のように、第2の実施形態では、あるゲーム装置1で作成されたボトルメールをすれ違い通信を用いて他のゲーム装置1に伝播させる。そして、すれ違い通信で当該ボトルメールを受信したゲーム装置1では、当該受信したデータにユーザ名やAP情報等の付加情報を加えてボトルメールサーバに送信している。これにより、上記ボトルメールの作成者は、ボトルメールサーバに問い合わせを行うことにより、自己が作成し、放流したボトルメールの現在状況を確認することが可能となる。更に、最終的な状態だけでなく、途中でボトルメールの伝播に関わったユーザに関する情報を確認することも可能となる。このように、「ローカル通信」(すれ違い通信)と「インターネット通信」(ボトルメールサーバとの通信)を連動させることで、今までにない新しい楽しみ方をユーザに提供する事が可能となる。
【0359】
なお、上記実施形態では、ボトルメールの作成者が自己の作成したボトルメールの現在状況を確認する際、「受信タスク」を生成するようにしていたが、必ずしも「タスク」を用いる必要はなく、ユーザの操作に応じて(タスクは使わずに)適宜ボトルメールサーバにアクセスし、上記履歴情報データを取得するようにしても良い。ここで、放流した主だけでなく、伝播の途中に関わったゲーム装置1からボトルメールの現在状況を確認できるようにしても良い。
【0360】
また、「地域」の特定に関して、上記実施形態ではボトルメールサーバ側でAP情報166に基づいた「地域」の特定がなされていたが、この他、ボトルメールサーバからゲーム装置1にAP情報166を送信するようにし、ゲーム装置1側の処理で当該AP情報166に基づいて上記「地域」を特定するようにしても良い。
【0361】
(第3の実施形態)
次に、本発明の第3の実施形態について説明する。第3の実施形態では、上述の第1の実施形態で説明したような、タスクによる送受信(インターネット通信)と、上記「すれ違い通信」(ローカル通信)を連携させた処理の一例を更に示す。より具体的には、タスクで受信したデータを「すれ違い通信」を利用して他のゲーム装置に送信する例と、逆に、「すれ違い通信」で他のゲーム装置から受信したデータを、タスクを用いて所定のサーバにアップロードする例について説明する。
【0362】
まず、上記タスクの実行によってAPを介してサーバ等から受信したデータを「すれ違い通信」を用いて他のゲーム装置に送信する処理について説明する。例えば、上記タスク
の実行によって取得された体験版や無料ゲーム等を、上記「すれ違い通信」を利用して他のゲーム装置1に送信する場合を想定する。この場合、例えば、ゲーム装置Aにおいて上記タスクが実行された結果、体験版や無料ゲーム等が新規インストールされたとする。このとき、ゲーム装置Aにおいて、当該体験版や無料ゲーム等のデータが上記すれ違い通信用データ520に設定されるように構成する。これにより、他のゲーム装置に「すれ違い通信」を介して送信することが可能となる。更に、受信したゲーム装置側においては、当該「すれ違い通信」で取得した体験版や無料ゲーム等が自動的にインストールされるようにしてもよい。このようにタスクを実行して受信し、すれ違い通信で他のゲーム装置1に送信されるデータは体験版や無料ゲーム等に限らず、何らかのゲームアプリケーションが用いるためのデータであってもよい。
【0363】
次に、別の例として、他のゲーム装置から「すれ違い通信」で取得したデータを「送信タスク」を用いて所定のサーバにアップロードする処理について説明する。例えば、ユーザがAPの登録をゲーム装置1に行っていない等で、上記「ローカル通信」しかできない設定となっているゲーム装置Bを想定する。このような場合は、ゲーム装置Bにおいて、所定のサーバにアップロードするためのアップデータが作成され、更にこのアップデータを送信するための「送信タスク」を生成するためのタスク生成用データが作成されるようにする。このデータは、例えば、上記ポリシーデータと同じ構成であることが考えられる。そして、両データがすれ違い通信用データ520に格納されるように構成する。その結果、「すれ違い通信」でこれらのデータが上記ゲーム装置Aに送信される。ゲーム装置Aでは、「すれ違い通信」で受信した上記タスク生成用データに基づき「送信タスク」が生成される(上記ステップS129やS130と同様の処理が実行されればよい)。その結果、このタスクが実行されることによって、ゲーム装置Bで生成されたアップデータを、ゲーム装置Aがゲーム装置Bに代わって所定のサーバに送信することが可能となる。
【0364】
このように、「インターネット通信」と「ローカル通信」を連携させることで、複数のゲーム装置1の間で様々なデータのやりとりが可能となる。また、「インターネット通信」ができない設定となっているゲーム装置1についても、「ローカル通信」(すれ違い通信)を利用して他のゲーム装置を経由してデータを送受信することで、間接的に「インターネット通信」が可能となる。
【0365】
なお、上記各実施形態において、ゲーム装置1において実行された一連の処理については、複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記ゲーム装置1が行っていた一連の処理のうちの一部の処理(例えば、アプリケーション処理の一部)がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。
【産業上の利用可能性】
【0366】
本発明にかかる携帯型情報端末、携帯型情報システム、および携帯型情報端末制御プログラムは、本来常時接続での運用が想定されていない携帯型情報端末においても常時接続に近い使用感を提供することができ、携帯型ゲーム装置やPDA、ノートパソコン等に有用である。
【符号の説明】
【0367】
1…ゲーム装置
11…下側ハウジング
12…下側LCD
13…タッチパネル
14…操作ボタン
15、26…LED
16…マイクロフォン用孔
21…上側ハウジング
22…上側LCD
23…内側カメラ
24…音抜き孔
25…外側カメラ
27…タッチペン
28、29…メモリカード
31…CPU
32…メインメモリ
33…NANDフラッシュメモリ
34…無線通信モジュール
35…第1メモリカードI/F
36…第2メモリカードI/F
37…マイコン
39…RTC
40…開閉検出器
41…電源管理IC
42…電源回路
43…I/F回路
44…マイク
45…アンプ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44
図45
図46
図47
図48
図49
図50