図面 (/)

技術 通信システム、情報処理プログラム、情報処理方法、情報処理装置、情報処理システム

出願人 任天堂株式会社
発明者 藤原慎矢河本浩一伊藤裕一朗
出願日 2012年6月12日 (8年11ヶ月経過) 出願番号 2012-133042
公開日 2012年10月4日 (8年8ヶ月経過) 公開番号 2012-190485
状態 特許登録済
技術分野 計算機間の情報転送 電話機の機能
主要キーワード 遭遇回数 近隣範囲 反応内容 今回評価 構成パーツ エモーション ユーザ作成データ 評価回数
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2012年10月4日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

ユーザ自身が生活する地域において他のユーザから自己の作成したコンテンツへの評価を受けることができるシステムを、簡易な構成によって提供すること。

解決手段

近距離無線による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信すると共に、他の情報処理装置から送信されたデータを自動的に受信する。そして、ユーザの操作に基づいて、当該受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、当該生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

概要

背景

従来から、投稿者所有している画像や動画などのコンテンツユーザ端末からサーバに送信し、投稿者以外のユーザがユーザ端末を操作して当該サーバにログインしてコンテンツを評価することにより、投稿者は様々なユーザからの総合的な評価結果が得られるシステムが知られている(例えば、特許文献1参照)。

概要

ユーザ自身が生活する地域において他のユーザから自己の作成したコンテンツへの評価を受けることができるシステムを、簡易な構成によって提供すること。近距離無線による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信すると共に、他の情報処理装置から送信されたデータを自動的に受信する。そして、ユーザの操作に基づいて、当該受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、当該生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

目的

本発明の目的は、自装置内に保有するデータに対する他人の評価を受けることができるシステムを、簡易な構成によって提供する

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の情報処理装置を含む通信ステムであって、前記情報処理装置はそれぞれ、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段と、ユーザの操作に基づいて、前記受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、前記送信手段は、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、通信システム。

請求項2

情報処理装置のコンピュータを、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段、およびユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段として機能させ、前記送信手段は、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理プログラム

請求項3

前記コンピュータを、他の情報処理装置の前記送信手段により送信された評価データで示される評価の内容を出力装置に出力させる出力制御手段としてさらに機能させる、請求項2に記載の情報処理プログラム。

請求項4

前記出力制御手段は、前記評価データで示される評価の対象となったデータに基づく画像とともに、前記評価の結果を表示装置に表示させる、請求項3に記載の情報処理プログラム。

請求項5

前記コンピュータを、前記受信手段によって受信されるデータに含まれている前記評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、前記出力制御手段は、前記宛先判別手段による判別結果が肯定である場合、当該評価データで示される評価の内容を前記出力装置に出力させる、請求項3に記載の情報処理プログラム。

請求項6

前記送信手段は、前記評価データ生成手段により評価データが生成された後、前記近距離無線通信の通信可能範囲に他の情報処理装置が含まれるようになったとき、当該評価データを自動的に送信する、請求項2ないし5のいずれかに記載の情報処理プログラム。

請求項7

前記評価データ生成手段は、前記送信手段による送信および前記受信手段による受信が可能でない状態に移行した後に、前記評価データを生成し、前記送信手段は、当該送信手段による送信および前記受信手段による受信が可能である状態に移行した後に、前記評価データ生成手段により生成された評価データを送信する、請求項2ないし6のいずれかに記載の情報処理プログラム。

請求項8

前記評価データ生成手段は、前記受信手段によって受信されたデータが、以前に当該受信手段によって受信した実績がある場合に、ユーザの操作に基づいて、当該データによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する、請求項2ないし請求項7のいずれかに記載の情報処理プログラム。

請求項9

前記評価データ生成手段は、ユーザの操作に基づいて、前記受信手段により受信されたデータに基づいて示されるデータ内容に対しての当該ユーザの評価として、第1の評価と第2の評価の何れか一方を選択する手段および前記第1の評価が選択された場合に前記評価データを作成する手段を含み、前記出力制御手段は、前記評価データで示される第1の評価の内容を前記出力装置に出力させる、請求項3に記載の情報処理プログラム。

請求項10

前記評価データ生成手段は、前記評価データとして、当該評価データが示す評価の対象となったデータの送信元を示す送信元データを生成し、前記送信手段は、前記評価データ生成手段により生成された送信元データを送信し、前記コンピュータを、前記受信手段によって受信されるデータに含まれる前記送信元データに基づいて、前記評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、前記出力制御手段は、前記宛先判別手段による判別結果が肯定である場合、前記第1の評価の内容を前記出力装置に出力させる、請求項9に記載の情報処理プログラム。

請求項11

前記データは、ユーザの操作に基づいて前記情報処理装置で作成されたユーザ作成データである、請求項2〜10のいずれかに記載の情報処理プログラム。

請求項12

前記コンピュータを、少なくとも前記受信手段により受信されたデータが所定の条件を満たすか否かを判別する評価可否条件判別手段と、前記評価可否条件判別手段による判別結果が肯定である場合、前記評価データ生成手段により評価データが生成されるためのユーザの操作を許可する許可手段としてさらに機能させる、請求項2〜11のいずれかに記載の情報処理プログラム。

請求項13

前記評価可否条件判別手段は、前記受信手段により受信されたデータに、当該データの内容に対してのユーザの評価を許可することを示す許可データが含まれているか否かを判別する、請求項12記載の情報処理プログラム。

請求項14

前記評価可否条件判別手段は、前記受信手段により受信されたデータに、当該データの内容に対するユーザの評価を許可することを示す第1許可データが含まれており、かつ、自装置に、データの内容に対するユーザの評価を許可することを示す第2許可データが設定されているか否かを判別する、請求項12記載の情報処理プログラム。

請求項15

前記評価可否条件判別手段は、前記受信手段により受信されたデータに対して、前記評価データ生成手段により評価データが生成されていないか否かを判別する、請求項12記載の情報処理プログラム。

請求項16

前記評価可否条件判別手段は、前記受信手段により受信されたデータに対して、前記評価データ生成手段により評価データが生成されているときに、当該データの少なくとも一部が変更されているか否かを判別する、請求項12記載の情報処理プログラム。

請求項17

前記コンピュータを、前記評価データを取得した回数累計する評価回数累計手段と、前記評価回数の累計を表示する累計表示手段として更に機能させる、請求項9に記載の情報処理プログラム。

請求項18

複数の情報処理装置を用いる情報処理方法であって、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する送信ステップと、他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信ステップと、ユーザの操作に基づいて、前記受信ステップにおいて受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成ステップとを備え、前記送信ステップは、前記評価データ生成ステップにおいて生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理方法。

請求項19

近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段と、ユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、前記送信手段は、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理装置。

請求項20

近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理システムに対してデータを自動的に送信する送信手段と、他の情報処理システムの前記送信手段により送信されたデータを自動的に受信する受信手段と、ユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、前記送信手段は、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理システム。

技術分野

0001

本発明は、通信ステム通信機能を利用する情報処理に関し、より特定的には、近距離無線通信を用いた通信システムや情報処理に関する。

背景技術

0002

従来から、投稿者所有している画像や動画などのコンテンツユーザ端末からサーバに送信し、投稿者以外のユーザがユーザ端末を操作して当該サーバにログインしてコンテンツを評価することにより、投稿者は様々なユーザからの総合的な評価結果が得られるシステムが知られている(例えば、特許文献1参照)。

先行技術

0003

特開2009−181262号公報

発明が解決しようとする課題

0004

上記特許文献1に記載されているシステムでは、不特定多数のユーザにより評価が行われるため、コンテンツを有するユーザ自身が生活する地域における他のユーザから当該コンテンツの評価を受けたい場合であっても、簡単なシステム構成で実現することは困難であった。

0005

それ故に、本発明の目的は、自装置内に保有するデータに対する他人の評価を受けることができるシステムを、簡易な構成によって提供することである。

課題を解決するための手段

0006

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

0007

本発明にかかる通信システムは、複数の情報処理装置を含むシステムであり、情報処理装置はそれぞれ、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

0008

上記構成により、近距離無線通信により他の情報処理装置へ自動的に送信したデータに対して当該他の情報処理装置のユーザにより評価が行われ、その評価結果を近距離無線通信により自動的に受信するため、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

0009

本発明にかかる情報処理プログラムは、情報処理装置のコンピュータを、送信手段と、受信手段と、評価データ生成手段として機能させる。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

0010

上記構成例により、近距離無線通信により他の情報処理装置へ自動的に送信したデータに対して当該他の情報処理装置のユーザにより評価が行われ、その評価結果を近距離無線通信により自動的に受信するため、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

0011

他の構成例として、コンピュータを、他の情報処理装置の送信手段により送信された評価データで示される評価の内容を出力装置に出力させる出力制御手段としてさらに機能させてもよい。

0012

上記構成例によれば、自装置内に保有するデータに対する他人の評価の内容を容易に把握することができる。

0013

更に他の構成例として、表示制御手段は、評価データで示される評価の対象となったデータに基づく画像とともに、評価の結果を表示装置に表示させてもよい。

0014

上記構成例によれば、評価されたものが何かをユーザに把握させやすくすることができる。

0015

更に他の構成例として、コンピュータを、受信手段によって受信されるデータに含まれている評価データが、当該評価データの受信時より以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段と、宛先判別手段による判別結果が肯定である場合、当該評価データで示される評価の内容を表示装置に表示させる表示制御手段としてさらに機能させてもよい。

0016

上記構成例によれば、受信側において自分宛の評価データを判別するため、送信側において送信先を判別する手間を省き、評価データの送信にかかる時間を短縮することができる。特に、他の情報処理装置とすれ違った際に近距離無線通信により短時間で通信を完了させることが要求される場面において、有用である。

0017

更に他の構成例として、送信手段は、評価データ生成手段により評価データが生成された後、近距離無線通信の通信可能範囲に他の情報処理装置が含まれるようになったとき、当該評価データを自動的に送信してもよい。

0018

上記構成例によれば、他人のデータ内容についての評価を当該他人に伝えるためにユーザに別途の作業を行わせずにすませることができる。

0019

更に他の構成例として、評価データ生成手段は、送信手段による送信および受信手段による受信が可能でない状態に移行した後に評価データを生成し、送信手段は、送信手段による送信および受信手段による受信が可能である状態に移行した後に、評価データ生成手段により生成された評価データを送信するようにしてもよい。

0020

上記構成例によれば、接続状態が維持されていない状態でも(つまり、接続中でなくても)、受信されたデータによって示されるデータ内容をユーザに評価させることができる。

0021

更に他の構成例として、評価データ生成手段は、受信手段によって受信されたデータが、以前に当該受信手段によって受信した実績がある場合に、ユーザの操作に基づいて、当該データによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成するようにしてもよい。

0022

上記構成例によれば、以前に受信したことがあるデータを再度受信した場合に評価が制限されるため、送信データを格納しておくために必要なメモリの容量を削減することができる。

0023

更に他の構成例として、コンピュータを、受信手段により受信されたデータに基づいて示されるデータ内容に対しての当該ユーザの評価として、第1の評価と第2の評価を含む複数の評価選択肢を表示し、いずれか1つをユーザに選択させる選択肢表示手段として更に機能させ、評価データ生成手段は、ユーザに選択された選択肢が第1の評価を示す場合にのみ評価データを作成するようにしてもよい。

0024

上記構成例によれば、例えば、高評価がなされたときにのみ評価データが作成されるようにすることができる。

0025

更に他の構成例として、評価データ生成手段は、評価データとして、当該評価データが示す評価の対象となったデータの送信元を示す送信元データを生成し、送信手段は、評価データ生成手段により生成された送信元データを送信してもよい。更に、コンピュータを、受信手段によって受信されるデータに含まれる送信元データに基づいて、評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、出力制御手段は、宛先判別手段による判別結果が肯定である場合、第1の評価の内容を出力装置に出力させるようにしてもよい。

0026

上記構成例によれば、通信データ量を削減し、より短時間で他機とのデータの送受信を完了させることが可能となる。

0027

更に他の構成例として、データは、ユーザの操作に基づいて前記情報処理装置で作成されたユーザ作成データであってもよい。

0028

上記構成例によれば、ユーザは自身が作成したコンテンツ等のデータに対する他人の評価を簡易な構成で受けることができる。

0029

更に他の構成例として、少なくとも受信手段により受信されたデータが所定の条件を満たすか否かを判別する評価可否条件判別手段と、評価可否条件判別手段による判別結果が肯定である場合、評価データ生成手段により評価データが生成されるためのユーザの操作を許可する許可手段としてさらに機能させてもよい。

0030

上記構成例によれば、所定の条件が満たされる場合にのみ評価が可能となるため、例えば、初対面のユーザや、評価されることを希望しないユーザに対しては評価できないようにして、ユーザの利便性を高めることも可能となる。

0031

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに、当該データの内容に対してのユーザの評価を許可することを示す許可データが含まれているか否かを判別するようにしてもよい。

0032

上記構成例によれば、例えば、評価されることを希望するユーザのみ評価データが作成され、評価されることを希望しないユーザに対しては評価データが作成されないようにして、ユーザの利便性を高めることも可能となる。

0033

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに、当該データの内容に対するユーザの評価を許可することを示す第1許可データが含まれており、かつ、自装置に、データの内容に対するユーザの評価を許可することを示す第2許可データが設定されているか否かを判別する。

0034

上記構成例によれば、評価対象となるデータの送信側と受信側の双方が評価する/されることを許可しているときにのみ当該データに対する評価が可能となるため、一方的に評価が行われることを防ぐことができる。

0035

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに対して、評価データ生成手段により評価データが生成されていないか否かを判別するようにしてもよい。

0036

上記構成例によれば、一度も評価していないデータについてのみユーザの評価を行うことを可能とすることができ、一度評価したデータと同じデータを再度受信したときに、当該データに対して再度評価を行わせてしまうことを防ぐことができる。

0037

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに対して、評価データ生成手段により評価データが生成されているときに、当該データの少なくとも一部が変更されているか否かを判別するようにしてもよい。

0038

上記構成例によれば、一度評価したデータと同じデータを再度受信したか否かを判別し、同じデータであるときに、再度評価を行わせてしまうことを防ぐことができる。

0039

更に他の構成例として、コンピュータを、評価データを取得した回数累計する評価回数累計手段と、評価回数の累計を表示する累計表示手段として更に機能させてもよい。

0040

上記構成例によれば、例えば、高評価を受けた回数のみを累計し、ユーザに伝えることが可能となる。

0041

本発明にかかる情報処理方法は、送信ステップと、受信ステップと、評価データ生成ステップとを備える。送信ステップは、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信ステップは、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成ステップは、ユーザの操作に基づいて、受信ステップにおいて受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、送信ステップでは、評価データ生成ステップにおいて生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

0042

本発明にかかる情報処理装置は、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、近距離無線通信によって、不特定の他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

0043

本発明にかかる情報処理システムは、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理システムに対してデータを自動的に送信する。受信手段は、近距離無線通信によって、不特定の他の情報処理システムの送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

発明の効果

0044

本発明によれば、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

図面の簡単な説明

0045

本実施形態にかかる広場アプリ等を実行するゲーム装置1の外観図
ゲーム装置1の内部構成の一例を示すブロック図
本実施形態における「すれちがい通信」について説明するための図
本実施形態における「すれちがい通信」について説明するための図
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
広場アプリの処理にかかる画面の一例
ゲーム装置1の保存用データメモリ34のメモリマップを示す図
本体設定データ306の構成の一例
ユーザキャラクタ記憶領域307の構成の一例を示す図
すれちがい通信用データ領域308の構成の一例を示す図
すれちがい送信データ333の構成の一例を示す図
アプリ用データ領域309の構成の一例を示す図
アプリセーブデータ363の構成の一例を示す図
受信ユーザキャラ情報保存データ364の構成の一例を示す図
すれちがい通信の処理の詳細を示したフローチャート
広場アプリの処理の詳細を示すフローチャート
図31のステップS14で示した広場アプリ初期設定処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
広場アプリメイン処理の詳細を示すフローチャート
あいさつ選択ウィンドウ105の一例

実施例

0046

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

0047

図1は、本実施形態にかかる広場アプリケーション(以下、広場アプリ)等を実行するゲーム装置1の外観図である。ここでは、ゲーム装置1の一例として、携帯ゲーム装置を示す。図1において、ゲーム装置1は、折り畳み型の携帯ゲーム装置であり、開いた状態(開状態)のゲーム装置1を示している。ゲーム装置1は、開いた状態においてもユーザが両手または片手把持することができるようなサイズで構成される。

0048

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

0049

下側ハウジング11には、下側LCD(Liquid Crystal Display:液晶表示装置)12が設けられる。下側LCD12は横長形状であり、長辺方向が下側ハウジング11の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置1に内蔵されている表示装置としてLCDを用いているが、例えばEL(Electro Luminescence:電界発光)を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置1は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側LCD12は、主に、内側カメラ23または外側カメラ25で撮影されている画像をリアルタイムに表示するために用いられる。

0050

下側ハウジング11には、入力装置として、各操作ボタン14A〜14Kおよびタッチパネル13が設けられる。図1に示されるように、各操作ボタン14A〜14Kのうち、方向入力ボタン14A、操作ボタン14B、操作ボタン14C、操作ボタン14D、操作ボタン14E、電源ボタン14F、スタートボタン14G、およびセレクトボタン14Hは、上側ハウジング21と下側ハウジング11とを折りたたんだときに内側となる、下側ハウジング11の内側主面上に設けられる。方向入力ボタン14Aは、例えば選択操作等に用いられる。各操作ボタン14B〜14Eは、例えば決定操作キャンセル操作等に用いられる。電源ボタン14Fは、ゲーム装置1の電源をオンオフするために用いられる。図1に示す例では、方向入力ボタン14Aおよび電源ボタン14Fは、下側ハウジング11の内側主面中央付近に設けられる下側LCD12に対して、左右一方側(図1では左側)の当該主面上に設けられる。また、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、下側LCD12に対して左右他方側(図1では右側)となる下側ハウジング11の内側主面上に設けられる。方向入力ボタン14A、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、ゲーム装置1に対する各種操作を行うために用いられる。

0051

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

0052

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

0053

また、下側ハウジング11の右側面には、メモリカード28を収納するための挿入口(図1では、二点鎖線で示している)が設けられている。この挿入口の内側には、ゲーム装置1とメモリカード28とを電気的に接続するためのコネクタ(図示せず)が設けられる。メモリカード28は、例えばSD(Secure Digital)メモリカードであり、コネクタに着脱自在に装着される。メモリカード28は、例えば、ゲーム装置1によって撮影された画像を記憶(保存)したり、他の装置で生成された画像をゲーム装置1に読み込んだりするために用いられる。

0054

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

0055

下側ハウジング11と上側ハウジング21との連結部の左側部分には、3つのLED15A〜15Cが取り付けられる。ここで、ゲーム装置1は、他の機器との間で無線通信を行うことが可能であり、第1LED15Aは、ゲーム装置1の電源がオンである場合に点灯する。第2LED15Bは、ゲーム装置1の充電中に点灯する。第3LED15Cは、無線通信が確立している場合に点灯する。したがって、3つのLED15A〜15Cによって、ゲーム装置1の電源のオン/オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。

0056

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

0057

また、上側ハウジング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で撮影することができる。

0058

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

0059

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

0060

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

0061

以上に説明したように、上側ハウジング21には、画像を撮影するための構成である内側カメラ23および外側カメラ25と、例えば撮影の際に操作説明画面を表示する表示手段である上側LCD22とが設けられる。一方、下側ハウジング11には、ゲーム装置1に対する操作入力を行うための入力装置(タッチパネル13および各ボタン14A〜14K)と、ゲーム画面を表示するための表示手段である下側LCD12とが設けられる。したがって、ゲーム装置1を使用する際には、ユーザは、下側LCD12に表示される撮影画像(カメラによって撮影された画像)を見ながら、下側ハウジング11を把持して入力装置に対する入力を行うことができる。

0062

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

0063

図2において、ゲーム装置1は、CPU31、メインメモリ32、メモリ制御回路33、保存用データメモリ34、プリセットデータ用メモリ35、メモリカードインターフェース(メモリカードI/F)36およびカートリッジI/F44、無線通信モジュール37、ローカル通信モジュール38、リアルタイムクロックRTC)39、電源回路40、およびインターフェース回路(I/F回路)41等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング11(または上側ハウジング21でもよい)内に収納される。

0064

CPU31は、所定のプログラムを実行するための情報処理手段である。なお、CPU31によって実行されるプログラムは、ゲーム装置1内の保存用データメモリ34に予め記憶されていてもよいし、メモリカード28および/またはカートリッジ29から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。

0065

CPU31には、メインメモリ32、メモリ制御回路33、およびプリセットデータ用メモリ35が接続される。また、メモリ制御回路33には、保存用データメモリ34が接続される。メインメモリ32は、CPU31のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ32として、例えばPSRAM(Pseudo−SRAM)を用いる。保存用データメモリ34は、CPU31によって実行されるプログラムや内側カメラ23および外側カメラ25によって撮影された画像のデータ等を記憶するための記憶手段である。保存用データメモリ34は、不揮発性記憶媒体によって構成されており、例えば本実施例ではNAND型フラッシュメモリで構成される。メモリ制御回路33は、CPU31の指示に従って、保存用データメモリ34に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ35は、ゲーム装置1において予め設定される各種パラメータ等のデータ(プリセットデータ)を記憶するための記憶手段である。プリセットデータ用メモリ35としては、SPI(Serial Peripheral Interface)バスによってCPU31と接続されるフラッシュメモリを用いることができる。

0066

メモリカードI/F36は、CPU31に接続される。メモリカードI/F36は、コネクタに装着されたメモリカード28に対するデータの読み出しおよび書き込みを、CPU31の指示に応じて行う。本実施形態では、外側カメラ25によって撮像された画像データがメモリカード28に書き込まれたり、メモリカード28に記憶された画像データがメモリカード28から読み出されて保存用データメモリ34に記憶されたりする。

0067

カートリッジI/F44はCPU31に接続される。カートリッジI/F44は、コネクタに装着されたカートリッジ29に対するデータの読み出しおよび書き込みをCPU31の指示に従って行う。本実施形態では、情報処理装置10が実行することが可能なアプリケーションプログラムがカートリッジ29から読み出されてCPU31によって実行されたり、当該アプリケーションプログラムに関するデータ(例えばゲームのセーブデータ等)がカートリッジ29に書き込まれたりする。

0068

なお、本発明にかかる広場アプリ処理のプログラムは、本ゲーム装置1のプリインストールアプリとして予め保存用データメモリ34に記憶された状態であることを前提とするが、有線または無線通信回線を通じてコンピュータシステムに供給されてもよい。

0069

無線通信モジュール37は、例えばIEEE802.11.b/gの規格準拠した方式により、無線LANに接続する機能を有する。また、ローカル通信モジュール38は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール37およびローカル通信モジュール38は、CPU31に接続される。CPU31は、無線通信モジュール37を用いてインターネットを介して他の機器との間でデータを送受信することができる。また、CPU31は、ローカル通信モジュール38を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。例えば、CPU31は、ローカル通信モジュール38を用いて、近距離無線通信による通信範囲内(例えば、機器間の距離が数十メートル)にある他のゲーム装置を繰り返し探索して自動的に無線接続し、無線接続した他のゲーム装置に対してデータを自動的に送信するとともに、無線接続した他のゲーム装置から送信されるデータを自動的に受信することができる。

0070

また、CPU31には、RTC39および電源回路40が接続される。RTC39は、時間をカウントしてCPU31に出力する。例えば、CPU31は、RTC39によって計時された時間に基づいて、現在時刻(日付)等を計算することもできる。電源回路40は、ゲーム装置1が有する電源(典型的には電池であり、下側ハウジング11に収納される)から供給される電力を制御し、ゲーム装置1の各部品に電力を供給する。

0071

ここで、本実施形態では、電源が落とされていないときのゲーム装置1の動作状態として、「通常動作モード」と「スリープモード」とよばれる2つの状態がある。「通常モード」は、ゲーム装置1が開いており、ゲーム装置1を構成する部品の全てに電力が供給されている状態である。つまり、ユーザがゲーム装置1を直接操作しているような状態である。「スリープモード」は、ゲーム装置1が閉じられた(折り畳んだ)状態であるが、CPU31等の一部の構成部品には電力が供給されている状態であり、ユーザは直接的にはゲーム装置1に対して操作は行っていないが、CPU31による処理は可能な状態である。本実施形態では、この「スリープモード」中に、上記ローカル通信モジュール38を利用した「すれちがい通信」と呼ばれる通信が行われる(詳細は後述する)。

0072

また、ゲーム装置1は、マイク42およびアンプ43を備えている。マイク42およびアンプ43は、それぞれI/F回路41に接続される。マイク42は、ゲーム装置1に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をI/F回路41に出力する。アンプ43は、I/F回路41から音声信号を増幅してスピーカ(図示せず)から出力させる。I/F回路41は、CPU31に接続される。

0073

また、タッチパネル13は、I/F回路41に接続される。I/F回路41は、マイク42およびアンプ43(スピーカ)の制御を行う音声制御回路と、タッチパネル13の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成してCPU31に出力する。例えば、タッチ位置データは、タッチパネル13の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル13からの信号の読み込み、および、タッチ位置データの生成を所定時間に1回の割合で行う。CPU31は、I/F回路41を介して、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われた位置を知ることができる。

0074

操作ボタン14は、上記各操作ボタン14A〜14Kから構成され、CPU31に接続される。操作ボタン14からCPU31へは、各操作ボタン14A〜14Kに対する入力状況(押下されたか否か)を示す操作データが出力される。CPU31は、操作ボタン14から操作データを取得することによって、操作ボタン14に対する入力に応じた処理を実行する。

0075

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

0076

また、下側LCD12および上側LCD22は、それぞれCPU31に接続される。下側LCD12および上側LCD22は、それぞれCPU31の指示に従って画像を表示する。

0077

以下、本実施形態で想定する広場アプリ等の処理の概要について説明する。まず、広場アプリ等の処理の内容の説明に先立ち、この処理の前提となる「すれちがい通信」の概要について説明する。図3および図4は、本実施形態におけるすれちがい通信について説明するための図である。本実施形態では、保存用データメモリ34の中に、すれちがい通信専用の記憶領域を設ける。当該領域は、複数の「スロット」と呼ばれる単位で論理的に分けられる。このスロットの一つ一つが、所定の1つのアプリと対応付けられる。各スロットには、「送信ボックス」「受信ボックス」「アプリID」というデータが記憶される。このうち、アプリIDが、当該スロットに対応するアプリを識別するためのデータである。送信ボックスには、すれちがい通信において他のゲーム装置に送信するためのデータが格納され、受信ボックスには、すれちがい通信において他のゲーム装置から受信したデータが格納される。

0078

本実施形態では、すれちがい通信は、ゲーム装置1を上記スリープモードにしている間に行われるものとする。例えば、ユーザが、ゲーム装置を閉じた状態にして所持したまま外出したような場合に、ゲーム装置を同様の状態にして所持している他のユーザとすれ違った場合に、以下のような通信が行われる。まず、上記のようなスリープモード中において、各ゲーム装置1からは所定の周期ビーコン信号発信される。また、互いに自機の通信可能範囲内に存在する他のゲーム装置を検出しあっている。そして、他のゲーム装置1が検知されたとき、いずれかのゲーム装置1が主導する形で、ゲーム装置間ですれちがい通信用リンク(以下、このようなゲーム装置1同士での直接的な通信を「ローカル通信」と呼ぶ)が確立される。そして、ローカル通信が可能な状態となれば、ゲーム装置間で同じアプリIDが登録されたスロットの有無が判断される、そして、同じアプリIDを有するスロットが双方に存在すれば、図4に示すように、このスロットの送信ボックス内のデータが互いに送信される。相手側のゲーム装置1から送信されたデータは、受信ボックスに格納される。このようにして他のゲーム装置1から受信し、受信ボックスに格納されたデータについては、対応するアプリの起動時に当該受信ボックスから取得され、各アプリにおいて適宜用いられることになる。

0079

次に、本実施形態にかかるアプリケーションの処理概要を説明する。本実施形態にかかるアプリケーションには、主に、「ユーザキャラクタ作成アプリ」と「広場アプリ」の2つがある。これらは、ゲーム装置1の基本的なメニュー画面であるホームメニューからユーザによって選択されることで適宜実行される(例えば、これらのアプリを示す各アイコンがユーザによって選択されることで実行開始される)。

0080

ユーザキャラクタ作成アプリは、「ユーザキャラクタ」と呼ばれるキャラクタをユーザに生成させるためのアプリケーションである。本実施形態においては、ユーザキャラクタは複数のパーツによって構成されており、このパーツは、例えば、「目」、「」、「口」、「輪郭」、「髪型」等に分類されている。そして、各分類毎に予め複数のパーツが用意されてゲーム装置1に記憶されている。ユーザは、当該ユーザキャラクタ作成アプリで各種パーツを組みあわせる操作を行うことで、例えば、ユーザの顔に似ている顔を有するユーザキャラクタを生成することができる。そして、当該ユーザキャラクタ作成アプリで生成されたユーザキャラクタは、保存用データメモリ34に保存される。なお、このユーザキャラクタは、複数体生成して保存することも可能である。また、一旦作成したユーザキャラクタの外見等を編集(例えばパーツを異なるものに変更)することも可能である。

0081

一方、「広場アプリ」は、上記ユーザキャラクタをコレクションすることを主目的としたアプリである。ユーザキャラクタの収集は、上記すれちがい通信によって行われる。具体的には、上記ユーザキャラクタ作成アプリによって生成されたユーザキャラクタを、上述したようなすれちがい通信によって、他のゲーム装置1に送信すると共に、他のユーザが作成したユーザキャラクタを受信する。これにより、上記すれちがい通信が繰り返されることで、他のユーザが作成したユーザキャラクタを収集することが可能となる。そして、当該広場アプリにおいて、他のユーザの作ったユーザキャラクタを閲覧したり、自分と他のユーザのユーザキャラクタを用いた所定のミニゲーム等を実行することができる。また、このミニゲームでは、例えば、ユーザキャラクタの外観を変更することのできる「アクセサリ」のようなパーツを入手することが可能となっている。

0082

ここで、当該広場アプリでは、自己の作成したユーザキャラクタと上記すれちがい通信で取得した他のユーザキャラクタとの間で「あいさつ」させることが可能である。以下、このあいさつにかかる処理を「あいさつ処理」と呼ぶ。更に、当該広場アプリでは、他のユーザキャラクタを「評価」し、その結果を相手に伝えることも可能となっている。本実施形態では、この評価対象について、他のユーザキャラクタの外観についての評価を行うものとする。以下では、この評価にかかる処理を「評価処理」と呼ぶ。以下、これらの処理を含めた、広場アプリの動作の流れの全体的な概要を説明する。

0083

典型的な処理の流れとしては、以下のような流れを想定する。まず、広場アプリの初期設定として、すれちがい通信で用いるユーザキャラクタがユーザの操作によって登録される。本実施形態では、すれちがい通信で送受信することが可能なユーザキャラクタの数は1体のみであるとする。その後、ユーザがゲーム装置1をスリープモードにした状態で所持し、外出する。外出中に、何人かの他のユーザ(より正確には、広場アプリについてのすれちがい通信の設定が済んでいるユーザ)とすれ違うことで、上記のようなすれちがい通信(ユーザキャラクタの送受信)が何度か発生する。その後、外出を終えて帰って来たユーザが再度広場アプリを起動すると、「新着通知」として、今回の外出中に行われたすれちがい通信の回数等が示される。そして、今回の外出中に取得された他のユーザキャラクタについて、1体ずつ順番に、後述するような「あいさつ処理」と「評価処理」が行われる。そして、今回の外出中に取得された他のユーザキャラクタ全てに対しての「あいさつ処理」と「評価処理」が終われば、広場アプリのメイン画面が表示される、という流れとなる。換言すれば、本実施形態で説明する「あいさつ処理」と「評価処理」は、上記ゲーム装置をスリープモードにしてから、次に広場アプリが起動されるまでに上記すれちがい通信で取得された他のユーザキャラクタ(いわば新着のユーザキャラクタ)を対象として行われる処理である。以下、各処理の概要について説明する。

0084

[広場アプリの初期設定]
まず、上記広場アプリが初めて起動されると(初回起動時)、当該広場アプリについての初期設定処理が自動的に開始される。この処理においては、当該広場アプリの内容についての簡単な紹介が行われた後、上記すれちがい通信に関する設定、および、上記あいさつ処理において使用される「共通あいさつ」の作成(具体的には文字列の入力)が行われる。

0085

当該設定項目についてより具体的に説明する。上記すれちがい通信に関する主な設定項目としては、「すれちがい通信自体を行うか否か」という設定項目、「あいさつ処理を行うか否か」という設定項目、「評価処理を行うか否か」という設定項目、そして、すれちがい通信で用いるユーザキャラクタの選択、という設定項目がある。これらの設定項目については、当該初期設定処理において、各設定項目について「行う」「行わない」をユーザに問いかける画面を表示し、これに対するユーザの入力によって設定される。

0086

本実施形態では、「すれちがい通信自体を行うか否か」という設定項目については、「行う」という設定にする。その結果、上述したようなすれちがい通信用のスロット(上記図3参照)のいずれか一つと当該広場アプリとが関連づけられる。具体的には、当該広場アプリを示すアプリIDが上記いずれかのスロットのアプリIDに記憶されることで、スロットと広場アプリとの関連付けが行われることになる。更に、すれちがい通信において送信対象となるユーザキャラクタの選択も行われる。具体的には、ユーザキャラクタの一覧画面等が表示され、ユーザがいずれかのユーザキャラクタを選択する操作を行うことで、すれちがい通信すれちがい通信で用いるユーザキャラクタが選択されることになる。なお、もし上記スロットの全てが既に他のアプリで用いられていた場合は、その旨を知らせるメッセージが適宜表示され、この時点では関連付けは行われない。いずれかのスロットが開放された後に、再度当該関連付けの設定が行われることになる。また、ユーザキャラクタが1体も作成されていない場合は、上記ユーザキャラクタの選択の際にその旨を示すメッセージと、上記ユーザキャラクタ作成アプリを用いてユーザキャラクタの作成を促す旨のメッセージが適宜表示される。

0087

「あいさつ処理を行うか否か」という設定項目、および、「評価処理を行うか否か」という設定項目については、本実施形態では、自分側も相手側も共に「行う」と設定されている場合を例として説明する。ここで、本実施形態では、自分側と相手側の双方がこれらの設定項目を「行う」と設定している場合にのみ、あいさつ処理や評価処理が行われる。つまり、あいさつ処理についていずれか一方で「行わない」という設定がされていた場合は、あいさつ処理は行われない。また、「評価処理」についていずれか一方で「行わない」という設定がされていた場合は、評価処理は行われない。これは、いずれか一方が「あいさつ処理」を行うことを望まない場合や、「評価」されることを望まない場合にまで、強制的にあいさつや評価を行うことでユーザに不快感を与えないようにするためである。そのため、例えば、いずれか一方の側が、あいさつ処理については「行う」と設定しているが、評価処理については「行わない」と設定しているような場合は、あいさつ処理は行われるが、評価処理については行われないことになる。

0088

次に、上記「共通あいさつ」の作成の説明に際し、本実施形態のあいさつ処理で用いられる「あいさつ」全般について説明する。本実施形態のあいさつ処理では、すれちがい通信で受信した他のユーザキャラクタと自己のユーザキャラクタとの間で「あいさつ」するような処理が行われる。この「あいさつ」として、本実施形態では2種類のあいさつが定義されている。1つめは、「共通あいさつ」と呼ばれる種類のあいさつであり、2つめは「個別あいさつ」と呼ばれる種類のあいさつである。「共通あいさつ」は、不特定多数の他のユーザ(他のゲーム装置1)に対してのあいさつ、という位置づけである。つまり、相手を特に指定しないで、無差別に行われるあいさつである。また、例えば、あるグループに属している全体(全員)に対してのあいさつも「共通あいさつ」である。また、この「共通あいさつ」は、ある属性を有する多数の相手向けのあいさつであってもよい。例えば、性別が「」である他のユーザキャラクタに向けてのあいさつであってもよい。一方、「個別あいさつ」は、ある特定のユーザ(ゲーム装置1)に向けたあいさつ、という位置づけである。つまり、ユーザが個別の相手に対して行うことを意図しているあいさつである。換言すれば、(送信側のユーザの意図としては)あいさつする相手を指定・指名したあいさつである。そして、本実施形態では、基本的には「共通あいさつ」が用いられるが、2回以上すれちがい通信が行われたユーザに対しては、「個別あいさつ」を行うことも可能となる。つまり、初対面の相手に対しては「共通あいさつ」のみ利用できるが、2回以上すれ違ったことがある相手に対しては、「共通あいさつ」および「個別あいさつ」のいずれかを選択して利用可能となる。これは、2回もすれ違う(すれちがい通信が行われる)ような相手とは、それ以降何回もすれ違う可能性があることから、「個別あいさつ」によって、より親しい関係のあいさつを可能とするものである。

0089

そして、広場アプリの初期設定においては、上記「共通あいさつ」の作成のみが行われる。本実施形態では、適宜入力画面が表示され、これに対して16文字までのテキストをユーザが入力する。このテキストが「共通あいさつ」として記憶される。その結果、「あいさつ処理」では、ここで作成・記憶された「共通あいさつ」が選択できる。なお、本実施形態では、当該「共通あいさつ」は一つしか作成できないものとする。

0090

[スリープモード中のすれちがい通信]
このような広場アプリの初期設定が一通り終われば、上記ユーザキャラクタに関するデータや「共通あいさつ」のテキストデータ等が上記送信ボックスに格納される。その後、広場アプリのメイン画面が表示される。

0091

ユーザは、一旦広場アプリを終了させてゲーム装置1をスリープモードにする。そして、当該ゲーム装置1を所持して外出する。外出中に上記のようなすれちがい通信が何度か行われた後、ユーザが帰ってきたとする。

0092

外出から帰って来たユーザが広場アプリを起動すると、今回の外出中に発生したすれちがい通信(より正確には、上記ユーザキャラクタの送受信を伴うすれちがい通信。以下の説明では、すれちがい通信とはこのようなユーザキャラクタの送受信を伴うすれちがい通信のことを指すものとする)で得られた他のユーザキャラクタについての処理として、以下のような処理が実行される。

0093

[新着通知]
まず、新着通知の処理が行われる。具体的には、図5に示すように、今回の外出中に発生したすれちがい通信の回数が表示される。図5では、画面左側には自己が作成したユーザキャラクタ101が表示され、画面右側には、すれちがいで得られた他のユーザキャラクタ102の列が表示されている。また、画面上部の略中央に、今回のすれちがい回数を示すメッセージが表示されている。そして、他のユーザキャラクタ102の列から1体ずつ自己のユーザキャラクタ101に近づいてきてすれ違うようなアニメーションが表示される。その後、図6に示すような、今までに発生した(ユーザキャラクタの送受信を伴う)すれちがい通信の合計回数が表示される。

0094

新着通知にかかる表示が終わると、次に、他のユーザキャラクタ毎に、以下のような処理が順に行われる。
(1)相手側の自己紹介→(2)あいさつ処理→(3)相手側の近況報告等→(4)評価処理

0095

図7図21は、これらの処理にかかる画面の一例である。例えば、図7においては、画面の左側に自己のユーザキャラクタ101が表示され、画面右側に、今回の外出中に発生したすれちがい通信で得られた他のユーザキャラクタ102が表示されている。このような画面を基本として、以下のような処理が実行される。

0096

[(1)相手側の自己紹介]
まず最初に、(1)相手側の自己紹介が行われる。本実施形態では、図7に示すように、他のユーザの居住している「地域」と他のユーザの「名前」を自己紹介として表示する。この「地域」は、他のユーザキャラクタの送信元となったゲーム装置1の本体設定の一つとして記憶されている内容である。また、「名前」は、当該他のユーザキャラクタの作成者(つまり、他のユーザ)がそのユーザキャラクタに対して任意に付けた名前である。また、この表示は、他のユーザキャラクタ102が話しているかのように見せるため、吹き出しを用いた表示がなされる。

0097

相手側の自己紹介が終わると、当該ユーザキャラクタ102が初対面となるユーザキャラクタであるときには、図8に示すように、「はじめまして」というメッセージが吹き出しを用いて表示される。また、以前にすれちがい通信で取得した実績がある他のユーザキャラクタの場合は、図9に示すように、すれ違った回数を示すメッセージが表示される。

0098

[(2)あいさつ処理]
次に、(2)あいさつ処理が行われる。この処理では、まず「相手側から自分側へのあいさつ」が行われた後、「自分側から相手側へのあいさつ」が行われる。以下では、他のユーザキャラクタ102が初対面である場合と、そうではない場合とに分けて説明する。

0099

[初対面の場合]
現在の処理にかかる他のユーザキャラクタが初対面のユーザキャラクタである場合は、まず、「相手側から自分側へのあいさつ」として、図10に示すように、相手側が設定した「共通あいさつ」が、他のユーザキャラクタ102が話している様子で表示される。その後、「自分側から相手側へのあいさつ」として、図11に示すように、ユーザ自身が設定した「共通あいさつ」が、自己のユーザキャラクタ101が話している様子で表示される。これは、上記初期設定において作成された最長16文字のテキストメッセージである。

0100

[2度目以降の対面の場合]
現在の処理にかかる他のユーザキャラクタ102が初対面のユーザキャラクタではない場合は、「相手側から自分側へのあいさつ」としては、図12に示すように、相手側が設定した「共通あいさつ」、あるいは、「個別あいさつ」が表示される。いずれが表示されるかは、相手側がいずれのあいさつを行ったかによる。ここで、相手側のあいさつが「個別あいさつ」の場合は、その「個別あいさつ」の基となった自分側のあいさつの内容も共に表示される(図13参照)。具体的には、まず、自分側のあいさつの内容が先に表示される。そして、このあいさつ内容に対して返事するように、相手側の個別あいさつが表示される。これは、相手側の「個別あいさつ」の内容が、自分側のどのような内容のあいさつに対してのもの(返事)であるのかをユーザに把握させやすくするためである。それと同時に、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102があたかも会話しているかのように見せることで、ユーザが他のユーザとコミュニケーションをとっている感覚をより高めている。

0101

次に、「自分側から相手側へのあいさつ」として、まず、図14に示すようなあいさつの種類を選択するあいさつ選択ウィンドウ105が表示される。図14では「みんな向け」と「こべつの」の2つの選択肢が表示されている。これに対して、ユーザが「みんな向け」を選択すると、共通あいさつを選択したものとして扱われる。その結果、図15に示すように、自己の作成した「共通あいさつ」が表示される。一方、ユーザが「こべつの」を選択したときは、「個別あいさつ」を選択したとして扱われる。その結果、まず、「個別あいさつ」としてのテキストを入力するための画面(図示は省略)が表示される。この画面に対して、2バイト文字で16文字以内のテキストをユーザが所定の入力装置を用いて入力する。そして、入力が終われば、図16に示すような確認画面が表示される。この確認画面でユーザが了承すれば、図17に示すように、今入力した「個別あいさつ」が表示される。以上で、現在の他のユーザキャラクタに対するあいさつ処理は終了する。

0102

ここで上記「個別あいさつ」については、その送信相手を特定する情報と共にすれちがい通信用の送信データとして適宜設定され、送信ボックスに格納される。そして、すれちがい通信によって送信される。なお、本実施形態では、「個別あいさつ」の送信に関しては、とりあえず不特定多数の相手に送信を行うものとする。そして、受信した側で、自分宛の「個別あいさつ」か否かを判断して振り分ける。

0103

なお、上述したあいさつ処理を行うか否かの設定項目において「行わない」と設定されている場合は、図10図17にかかるあいさつ処理は省略される。

0104

[(3)相手側の近況報告等]
あいさつ処理が終わると、次に、相手側からの近況報告等を示すメッセージがいくつか表示される。図示は省略するが、例えば、最近遊んだゲームが何かを示すメッセージ等が表示される。また、その他、趣味や好きな食べ物等、プロフィールについてのメッセージ等も表示される。

0105

[(4)評価処理]
相手側の近況報告等を示すメッセージの表示が終われば、次に、評価処理が実行される。ここで、当該評価処理に関しては、個別あいさつの場合と同様に、2回以上すれちがい通信を行った相手にのみ可能となっている。つまり、初対面の相手に対しては評価処理は行われない。相手が初対面(初めてすれ違った人)である場合は、その時点では、再度会う(すれ違う)可能性については未知数であり、同じ人と2度とすれ違わない可能性も低くはない。一方、同じ人と2回目のすれちがい通信が発生した場合、比較的親しい間柄であると考えられることから、3回目以降のすれちがい通信が行われることが期待できる。そのため、再度すれ違う可能性が高い相手に対してのみ評価処理を行うようにして、無駄な評価作業を減らそうとするものである。

0106

まず、図18に示すような、他のユーザキャラクタの外観に対するユーザの評価の選択画面が表示される。図18では、他のユーザキャラクタ102の問いかけメッセージと共に、評価選択ウィンドウ107に「ふつうかな」および「すごくいい!」という2つの選択肢が表示されている。ここでは、「すごくいい!」のほうが高評価であるとする。ユーザは、この選択肢から一方を選択する。すると、その選択肢に応じた所定のメッセージが、他のユーザキャラクタ102が話しているかのように表示される。例えば、「すごくいい!」が選ばれたときは、図19に示すように、喜びを示すようなメッセージが表示される。なお、本実施形態では、評価の方法として、2つの予め記憶されているメッセージのうち1つのメッセージを選択することにより評価を行うようしているが、これに限られず、ユーザのテキスト入力により評価を行うようにしていてもよい。

0107

ここで、上記2つの選択肢のうち、高評価のほうの選択肢が選ばれた場合は、その旨を示すデータがすれちがい通信用の送信データの一つとして設定される。そして、以後に発生するすれちがい通信において、高評価したことを示すデータも他の各種データと共に相手側に送信される。そして、受信した側において、自分宛の高評価のデータが含まれているか否かを判断し、含まれていれば、次に説明するような「相手側から自分への評価」として表示されることになる。つまり、高評価の場合は、高評価したということがその相手側に通知されることになる(もちろん、同じユーザとすれ違うことが前提である)。

0108

また、この評価処理に関しては、同じ相手(ユーザキャラクタ)に対しては、原則として1度しか行えない。但し、同じ相手であっても、その外観が変更されていた場合は(上記ユーザキャラクタ生成アプリで編集可能であるため)、変更この外観について再度評価を行うことが可能となっている。

0109

自分側から相手側への評価が終われば、次に、相手側から自分への評価が表示される。これは、上記のように、相手側が自分に対して高評価を行っていた場合にのみ表示される。この場合は、図20に示すように、相手から自分への評価を示すメッセージが表示された後、図21に示すように、今までに高評価を受けた累計回数が表示される。一方、相手側が自分に対して高評価は行っていない場合(例えば、上記選択肢で「ふつうかな」を相手が選んでいた場合)は、相手側から自分への評価にかかる処理は実行されないこととなる。

0110

以上のような、(1)相手側の自己紹介→(2)あいさつ処理→(3)相手側の近況報告等→(4)評価処理、の一連の処理が、すれちがい通信で取得した他のユーザキャラクタの数の回数分だけ繰り返された後、広場アプリのメイン画面が表示され、当該広場アプリのメインとなる処理が適宜実行される。このメインとなる処理については本実施形態の説明に直接関係しないため、説明は省略する。

0111

このように、本実施形態では、近距離無線通信である「すれちがい通信」を用いてユーザキャラクタを収集すると共に、同じ相手と複数回すれちがい通信が発生している場合は、ユーザと親しい間柄の相手であるとして、上記「個別あいさつ」のような特定の相手向けのあいさつを可能としている。また、他のユーザの作成したユーザキャラクタについて評価を行い、その評価結果について相手側に送信することも可能となっている。これにより、ゲーム装置を所持して外出するだけで上記の様なすれちがい通信によるユーザキャラクタの収集が可能となり、サーバ等が不要の比較的簡易な構成で、自己のユーザキャラクタを他のユーザに評価してもらい、フィードバックしてもらうことが可能である。また、上記のように何度かすれ違った相手に対しては「個別あいさつ」という形で個別のメッセージを送信することができ、他のゲーム装置1を所持しているユーザとより親密なコミュニケーションを取っているプレイ感覚を提供することができる。

0112

次に、ゲーム装置1によって実行される広場アプリ等の処理の詳細を説明する。まず、各種処理の際に用いられる各種データについて説明する。図22は、ゲーム装置1の保存用データメモリ34のメモリマップを示す図である。図2において、保存用データメモリ34は、プログラム記憶領域301およびデータ記憶領域305を含む。プログラム記憶領域301およびデータ記憶領域305のデータは、広場アプリの実行時に、必要に応じてメインメモリ32に適宜転送されて使用される。

0113

プログラム記憶領域301は、CPU31によって実行される各種プログラムを記憶する。本実施形態では、すれちがい通信処理プログラム302と、ユーザキャラ生成アプリプログラム303と、広場アプリプログラム304などが記憶される。すれちがい通信処理プログラム302は、上述したようなスリープモードにおけるすれちがい通信を実行するためのプログラムである。ユーザキャラ生成アプリプログラム303は、上記ユーザキャラクタ作成アプリを実行するためのプログラムであり、広場アプリプログラム304は、上記広場アプリを実行するためのプログラムである。

0114

データ記憶領域305には、本体設定データ306等が記憶される。また、データ記憶領域305は、ユーザキャラクタ記憶領域307、すれちがい通信用データ領域308、アプリ用データ領域309を含んでいる。

0115

本体設定データ306は、主にゲーム装置1の本体に関する設定データである。図23は、本体設定データ306の構成の一例である。本体設定データ306は、ユーザ名データ311、地域データ312等から構成される。ユーザ名データ311は、ゲーム装置1の所有者(つまり、ユーザ)の氏名のデータである。なお、ユーザ名データ311には、ユーザを一意に識別するためのユーザIDも含まれている。地域データ312は、ユーザによって設定されるデータであり、典型的には、ユーザの住んでいる地域を示すデータである。その他、本体設定データ306には、ネットワークに接続するための情報等も含まれる。

0116

図22戻り、ユーザキャラクタ記憶領域307は、ユーザキャラクタを保存するための領域である。図24は、当該ユーザキャラクタ記憶領域307の構成の一例を示す図である。ユーザキャラクタ記憶領域307は、複数のユーザキャラクタデータ321の集合で構成されている。この領域には、ユーザ自身が作成したユーザキャラクタのデータの他、上記すれちがい通信で取得された、他のユーザによって作成されたユーザキャラクタも保存される。また、当該領域に保存されているユーザキャラクタは、上記広場アプリを含め、様々なアプリにおいて利用可能なデータである。

0117

各ユーザキャラクタデータ321は、ユーザキャラクタID322、ユーザキャラクタ名323、構成パーツ情報324、作成者ID325等から構成される。ユーザキャラクタID322は、ユーザキャラクタを一意に識別するためのIDである。本実施形態では、ゲーム装置本体に固有の番号(例えばシリアルNo)等も利用して、全世界でユニークなIDとなるように生成される。具体的には、ゲーム装置本体に固有の番号と、ユーザキャクタが作成された時点の日時を利用することでユーザキャラクタID322が生成される。

0118

ユーザキャラクタ名323は、各ユーザキャラクタに設定された名前であり、例えば、2バイト文字で10文字までの長さの文字列データである。

0119

構成パーツ情報324は、ユーザキャラクタを構成している各パーツを示す情報である(上述したように、ユーザキャラクタは、「目」、「鼻」等に分類されているパーツの集まりで構成されている)。

0120

作成者ID325は、ユーザキャラクタを作成した人の識別情報である。当該作成者ID325は、ゲーム装置本体に固有の番号を使用して生成される。その結果、作成者ID325は、ゲーム装置1毎に異なる識別情報となる。ユーザ自身が作成したユーザキャラクタであれば、上記本体設定データ306のユーザ名データ311が当該作成者情報325として記憶される。他のゲーム装置で作成されたユーザキャラクタであれば、そのユーザキャラクタを作成したユーザを示すデータ(他のゲーム装置1におけるユーザ名データ311)が作成者情報325となる。

0121

図22に戻り、すれちがい通信用データ領域308は、上記図3および図4で説明したような、すれちがい通信において用いられる各種データを格納するための領域である。図25は、当該すれちがい通信用データ領域308の構成の一例を示す図である。すれちがい通信用データ領域308には複数のスロット331(本実施形態では計16スロット)が含まれている。各スロットは、アプリID332、すれちがい送信データ333、のすれちがい受信データ334で構成されている。

0122

アプリID332は、当該スロットを使用する(対応付けられている)アプリケーションを識別するためのIDである。

0123

すれちがい送信データ333は、すれちがい通信において他のゲーム装置1に送信するためのデータである。図26は、すれちがい送信データ333の構成の一例を示す図である。図26において、すれちがい送信データ333は、送信用ユーザキャラクタデータ341、共通あいさつ文字列データ342、プロフィールデータ343、地域データ344、あいさつ処理実行フラグ345、評価処理実行フラグ346、個別あいさつデータ347、評価リスト352から構成されている。

0124

送信用ユーザキャラクタデータ341は、すれちがい通信において送信する対象となるユーザキャラクタのデータである。上記複数のユーザキャラクタデータ321のうちから、ユーザによって選ばれた1体分のユーザキャラクタデータ321(あるいは、このデータを特定するための情報)が送信用ユーザキャラクタデータ341として記憶される。

0125

共通あいさつ文字列データ342は、上述したような「共通あいさつ」を示す文字列データである。

0126

プロフィールデータ343は、上記広場アプリにおいて、あいさつ処理の後に行われる「相手側の近況報告等」で用いられるデータである。すれちがい通信における送信先となった他のゲーム装置1上で「相手側の近況報告等」が実行される際に、当該プロフィールデータ343の内容が用いられることになる。

0127

地域データ344は、上記本体設定データ306の地域データ312がコピーされたものである。

0128

あいさつ処理実行フラグ345は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、あいさつ処理を行うことを許可することを示す。オフに設定されているときは、あいさつ処理を行うことを許可しないことを示す。

0129

評価処理実行フラグ346は、上述したような評価処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、評価処理を行うことを許可することを示す。オフに設定されているときは、評価処理を行うことを許可しないことを示す。

0130

個別あいさつデータ347は、上述したような「個別あいさつ」に関するデータであり、直近の16件分の「個別あいさつ」のデータが記憶されている。個別あいさつ1件分のデータは、宛先ユーザキャラID348、個別あいさつ文字列データ349、引用あいさつ文字列データ350、引用あいさつ種別フラグ351で構成される。

0131

宛先ユーザキャラID348は、「個別あいさつ」を行った対象である相手のユーザキャラクタを特定するためのデータであり、上記ユーザキャラクタID322に対応する。

0132

個別あいさつ文字列データ349は、「個別あいさつ」の内容を示す文字列データである。

0133

引用あいさつ文字列データ350は、当該「個別あいさつ」を生成した際の、他のユーザキャラクタからのあいさつの内容である。例えば、他のユーザキャラクタが行った「またあったね、元気?」という「あいさつ」に対して、「元気だよ。」という「個別あいさつ」を返す場合を想定する。この場合、上記個別あいさつ文字列データ349には「元気だよ。」という文字列のデータが格納され、引用あいさつ文字列データ350には、「またあったね、元気?」という文字列のデータが格納されることになる。

0134

引用あいさつ種別フラグ351は、上記引用あいさつ文字列データ350として格納される、他のユーザキャラクタからのあいさつの種類が「共通あいさつ」であるか「個別あいさつ」であるかを示すフラグである。例えば、この値が”0”であれば「共通あいさつ」、”1”であれば、「個別あいさつ」であることを示す。

0135

以上のようなデータで構成される個別あいさつのデータが最大で16件まで個別あいさつデータ347に記憶される。なお、新たに当該データを格納する際に既に16件まで埋まっている場合は、古いものが1件分消去されてから格納される。

0136

評価リスト352は、当該すれちがい送信データの作成元のユーザ(つまり、送信者)が高評価したユーザキャラクタを示すデータである。直近に高評価したユーザキャラクタのユーザキャラクタID353が、最大で32件分まで格納される。

0137

図25に戻り、すれちがい受信データ334は、すれちがい通信において他のゲーム装置1から受信したデータである。ここには、上記すれちがい送信データ333と同様の構成を有する受信データ335が複数件格納される。そのため、各受信データ335については説明を省略する。

0138

なお、すれちがい送信データ333と受信データ335の構成が同じであるため、以下の説明では、これらのデータの参照符号末尾に”S”または”R”を付加することで、すれちがい送信データ333と受信データ335のいずれに含まれるデータであるかを区別する。例えば、「送信用ユーザキャラクタデータ341S」は、すれちがい送信データ333に含まれている送信用ユーザキャラクタデータ341であることを示し、「送信用ユーザキャラクタデータ341R」は、受信データ335に含まれている送信用ユーザキャラクタデータ341であることを示す。また、その他のデータについても、末尾に”R”をつけたデータについては、受信データ335に含まれているデータ(つまり、すれちがい通信によって受信したデータに含まれているデータ)であることを示すものとする。

0139

図22に戻り、アプリ用データ領域309は、ゲーム装置1で実行される各種アプリケーションで用いられるデータを記憶する領域である。図27は、当該アプリ用データ領域309の構成の一例を示す図である。当該領域には、各アプリ毎に論理的に分けられて、各アプリにおいて用いられる各種データが記憶される。図27の例では、広場アプリ用データ361と、ユーザキャラ生成アプリ用データ366と、その他のアプリ用データ367が示されている。ここでは主に、広場アプリ用データ361の内容について説明する。

0140

広場アプリ用データ361は、アプリID362、アプリセーブデータ363、受信ユーザキャラ情報保存データ364等で構成される。

0141

アプリID362は、当該「広場アプリ」を識別するためのIDである。上述のようなすれちがい通信に用いるスロットとの関連付けに用いられる。

0142

アプリセーブデータ363は、広場アプリに関する各種設定等を記憶したデータである。図28は、アプリセーブデータ363の構成の一例を示す図である。図28において、アプリセーブデータ363は、すれちがい用ユーザキャラクタデータ371、共通あいさつ文字列データ372、プロフィールデータ373、あいさつ処理実行フラグ374、評価処理実行フラグ375、個別あいさつデータ376、評価リスト377、受けた評価データ378から構成される。また、図示は省略するが、広場アプリに関してすれちがい通信を利用するかか否か(つまり、すれちがい通信を行うか否か)の設定や、すれちがい通信の累計数等のデータもアプリセーブデータ363に含まれる。

0143

すれちがい用ユーザキャラクタデータ371は、すれちがい通信における送信対象として設定したユーザキャラクタのデータである。

0144

共通あいさつ文字列データ372は、上述したような「共通あいさつ」を示す文字列データである。

0145

プロフィールデータ373は、上述したような「相手側の近況報告等」で用いられるデータである。

0146

あいさつ処理実行フラグ374は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。また、評価処理実行フラグ375は、上述したような評価処理を行うことを許可するか否かを示すフラグである。その内容は、上記すれちがい送信データ333におけるあいさつ処理実行フラグ345および評価処理実行フラグ346と同様である。

0147

個別あいさつデータ376は、直近の16件分の「個別あいさつ」についてのデータである。その構成は、上記すれちがい送信データ333における個別あいさつデータ347と同様である。

0148

評価リスト377は、自分が高評価を与えた他のユーザキャラクタのユーザキャラクタIDのリストであり、最大で直近の32件分まで保存される。その構成は、上記すれちがい送信データ333における評価リスト352と同様である。

0149

受けた評価データ378は、自己の作成したユーザキャラクタに対して高評価を行った他のユーザについてのデータであり、本実施形態では、最大で100件分の評価者情報379が記憶される。各評価者情報379は、評価対象ユーザキャラクタID380と、評価した作成者情報381で構成されている。評価対象ユーザキャラクタID380は、自己の作成したユーザキャラクタであって、高評価を受けた(評価の対象となった)ユーザキャラクタのIDである。評価した作成者情報381は、高評価を与えた他のユーザを示す情報であり、他のゲーム装置1から受信した作成者情報325Rが当該評価した作成者情報381として記憶される。例えば、ユーザAが2体のユーザキャラクタAおよびBを作成したとする。この2体を、すれちがい通信に用いるユーザキャラクタを適宜変更することで、ユーザBの所持するゲーム装置と、ユーザCが所持するゲーム装置に送信した場合を想定する。そして、ユーザキャラクタAについては、他のユーザBおよびCから高評価をされたが、ユーザキャラクタBについては、他のユーザCからしか高評価がなされなかった場合を想定する。このような場合は、受けた評価データ378としては、<ユーザキャラクタAのID+ユーザBの作成者情報>と、<ユーザキャラクタAのID+ユーザCの作成者情報>と、<ユーザキャラクタBのID+ユーザCの作成者情報>の3件分の情報となる。

0150

図27に戻り、受信ユーザキャラ情報保存データ364は、すれちがい通信によって他のゲーム装置1から受信したユーザキャラクタに関するデータである。図29は、受信ユーザキャラ情報保存データ364の構成の一例を示す図である。図29において、受信ユーザキャラ情報保存データ364には、1000体分の受信ユーザキャラ391が記憶される。各受信ユーザキャラ391は、ユーザキャラデータ392、プロフィールデータ393、すれちがい回数394、前回すれちがい日時395、地域データ396、評価処理実行フラグ397で構成されている。

0151

ユーザキャラデータ392は、上記受信データ335に含まれている送信用ユーザキャラクタデータ341Rがコピーされたものである。同様に、プロフィールデータ393は、上記受信データ335に含まれているプロフィールデータ343Rがコピーされたものである。

0152

すれちがい回数394は、当該受信したユーザキャラクタの送信元のゲーム装置1との間で、上記のようなすれちがい通信が行われた回数を示すデータである。前回すれちがい日時395は、上記受信したユーザキャラクタの送信元のゲーム装置1とすれちがい通信が最後に行われた日時を示すデータである。地域データ396は、上記受信データ335に含まれている地域データ344Rがコピーされたものである。

0153

評価処理実行フラグ397は、上記受信データ335に含まれている評価処理実行フラグ346Rがコピーされたものである。つまり、当該受信したユーザキャラクタの作成者が、このキャラクタが評価されることを望んでいるか否かを示すフラグである。

0154

以下、ゲーム装置1が行う広場アプリについての処理の詳細動作を説明するが、広場アプリの詳細動作の説明に先立って、上述したすれちがい通信にかかる具体的な処理の流れについて簡単に説明する。

0155

図30は、本実施形態にかかるすれちがい通信の処理の詳細を示したフローチャートである。このフローにかかる処理は、ゲーム装置1が「スリープモード」(すれちがい通信モード)中のときに実行される。まず、ステップS1において、ビーコン信号が発信される。このビーコン信号は、ゲーム装置同士のローカル通信確立のきっかけとなるような情報が含まれている。次に、ステップS2において、他のゲーム装置から発信されたビーコンの存在を検出する。

0156

次に、ステップS3において、上記ビーコンの検出の結果、ビーコンが検出できたか否か、つまり、自機の通信可能範囲内に他のゲーム装置1が存在するか否かが判定される。その結果、自機の通信可能範囲内に他のゲーム装置1が存在していないときは(ステップS3でNO)、後述のステップS9に処理が進められる。一方、自機の通信可能範囲内に他のゲーム装置1が存在するときは(ステップS3でYES)、ステップS4において、ローカル通信を確立するための処理が実行される。ローカル通信が確立すれば、ステップS5において、通信相手となったゲーム装置1との間で、共通するアプリID332を有するスロット331があるか否かが判定される。つまり、すれちがい通信において送受信すべきデータが在るか否かが判定される。その結果、共通するアプリID332を有するスロット331がないときは(ステップS5でNO)、後述のステップS8に処理が進められる。一方、共通するアプリID332を有するスロット331が存在するときは(ステップS5でYES)、ステップS6において、当該スロット331にかかるすれちがい送信データ333が他のゲーム装置1に送信される。同時に、他のゲーム装置1から送信されてくるすれちがい送信データ333が、すれちがい受信データ334の受信データ335として格納される。

0157

次に、ステップS7において、上記データの送受信が完了したか、または、ローカル通信が強制的に切断されたか(すれちがい通信が完了する前に、通信可能範囲外にユーザが移動したような場合等)が判定される。その結果、データの送受信が未完了であり、ローカル通信も切断されていなければ(ステップS7でNO)、上記ステップS6に戻り、データの送受信が継続される。一方、送受信が完了、または、ローカル通信が強制切断されたときは(ステップS7でYES)、ステップS8において、ローカル通信を終了するための処理が実行される。データの送受信が完了した場合は、通信を切断することで、すれちがい通信を「正常終了」させるための処理が実行される。また、送受信完了前にローカル通信が強制切断されていた場合は、それまでに受信したデータをクリアし、すれちがい通信が始まる前の状態に戻す処理が行われる。

0158

次に、ステップS9において、「スリープモード」を終了させる指示がなされたか否かが判定され、終了指示がなされていないときは(ステップS9でNO)、上記ステップS1に戻り、処理が繰り返される。一方、終了指示がなされたときは(ステップS9でYES)、すれちがい通信処理が終了される。以降、ゲーム装置1が「通常モード」で動作することで、以下に説明するような処理が実行されることになる。

0159

次に、ゲーム装置1で実行される広場アプリの処理の詳細について説明する。この処理は、ゲーム装置1のホームメニューから広場アプリの実行指示がユーザによって行われることで開始される。例えば、ホームメニューの中から、広場アプリに対応するアイコン画像をユーザが選択して所定のボタンを押下したときに開始される。

0160

図31は、広場アプリの処理の詳細を示すフローチャートである。まず、図31において、広場アプリが起動されると、保存用データメモリ34からメインメモリ32への必要なファイルのロード等の初期処理が適宜実行される。その後、ステップS11において、ユーザキャラクタ記憶領域307が参照され、作成済みのユーザキャラクタ101が1体以上存在するか否かが判定される。当該判定の結果、ユーザキャラクタ101が1体も作成されていないときは(ステップS11でNO)、ステップS12において、ユーザキャラクタの作成を促すメッセージが表示される。そして、広場アプリ処理は終了する。つまり、ユーザキャラクタが未作成の状態では、広場アプリは実質的に利用できないことになる。

0161

一方、ユーザキャラクタ101が1体以上作成済みであるときは(ステップS11でYES)、次に、ステップS13において、広場アプリが初回起動であるか否か(つまり、今まで一度も実行されたことが無いか否か)が判定される。その結果、初回起動のときは(ステップS13でYES)、ステップS14において、広場アプリ初期設定処理が実行される。この処理は、すれちがい通信で用いるユーザキャラクタの選択等、広場アプリを利用するために必要な各種設定を行うための処理である。一方、初回起動ではないときは(ステップS13でNO)、広場アプリ初期設定処理はスキップされて、後述のステップS15に処理が進められる。

0162

図32は、上記ステップS14で示した広場アプリ初期設定処理の詳細を示すフローチャートである。図32において、まず、ステップS21で、広場アプリの簡単な紹介と説明が表示される。続くステップS22において、ユーザとの対話形式ですれちがい通信に関する設定を行う処理が実行される。具体的には、「すれちがい通信」を行うか否か、「あいさつ処理」を行うか否か、「評価処理」を行うか否か、等について、対話形式を用いて設定される。その結果、ユーザの入力内容に応じて、上記すれちがい通信用データ領域308のいずれかのスロット331と広場アプリとを関連づける処理が実行される。更に、ユーザキャラクタ記憶領域307から、すれちがい通信で用いるユーザキャラクタがユーザの入力内容に基づいて選択され、アプリセーブデータ363のすれちがい用ユーザキャラクタデータ371として保存される。また、アプリセーブデータ363のあいさつ処理実行フラグ374および評価処理実行フラグ375も、ユーザの入力内容に応じて適宜設定される。

0163

次に、ステップS23において、プロフィールデータ373作成の元となる質問が適宜表示され、これに対するユーザの入力内容に応じて、プロフィールデータ373が適宜設定される。

0164

次に、ステップS24において、「共通あいさつ」を生成するための処理が実行される。具体的には、「共通あいさつ」としての文字列を入力するための画面が表示される。これに対して、ユーザによって入力された所定の文字列が共通あいさつ文字列データ372として記録される。以上で、広場アプリ初期設定処理は終了する。

0165

図31に戻り、次に、ステップS15において、広場アプリメイン処理が実行される。図33図38は、当該広場アプリメイン処理の詳細を示すフローチャートである。図33において、まず、ステップS41で、アプリセーブデータ363が参照され、広場アプリですれちがい通信を行う設定がなされているか否かが判定される。その結果、すれちがい通信を行わない旨の設定が成されているときは(ステップS41でNO)、後述するステップS80に処理が進められ、広場アプリのメイン画面が表示されることになる。

0166

一方、すれちがい通信を行う旨の設定がなされているときは(ステップS41でYES)、次に、ステップS42において、すれちがい通信用データ領域308が参照され、今回の(直近の)スリープモード中においてすれちがい通信が発生したか否かが判定される。例えば、すれちがい受信データ334の内容が空であるか否かで判定される。当該判定の結果、すれちがい通信が発生していないときは(ステップS42でNO)、続くステップS43で、アプリセーブデータ363が参照されて、すれちがい通信の累計回数が0か否かが判定される。その結果、すれちがい通信の回数が0のときは(ステップS43でNO)、他のユーザキャラクタを1体も受信していない状態であると考えられるため、ステップS44において、ユーザにすれちがい通信を行わせることを支援するためのメッセージ(例えば、「人の集まるところですれちがい通信をしてみよう!」)が表示される。その後、後述のステップS80に処理が進められる。

0167

一方、直近のスリープモード中においてすれちがい通信が発生していたときは(ステップS42でYES)、少なくとも1体は他のユーザキャラクタを受信していると考えられるため、新着通知にかかる処理が実行される。具体的には、ステップS45において、上記図5を用いて説明したような画面を用いて、今回のすれちがい通信においてすれ違った回数(受信した他のユーザキャラクタの数)が表示される。その後、当該回数が、累計すれちがい回数を示すデータ(図示は省略)に加算されて、上記図6で示したような画面が生成されて表示される。また、当該加算後の累計すれちがい回数はアプリセーブデータ363の一部として記憶される。

0168

新着通知にかかる処理が終われば、次に、受信された各ユーザキャラクタについての処理が実行される。まず、ステップS46において、すれちがい受信データ334が参照されて、処理対象となるユーザキャラクタ(受信データ335)が古い順に1件選択されて読み出される。以下、当該選択されたユーザキャラクタを処理対象キャラクタと呼ぶ。

0169

次に、ステップS47において、処理対象キャラの自己紹介を表示する処理が行われる。具体的には、受信データ335(その構成は上記図26で示したすれちがい送信データ333と同様である)の送信用ユーザキャラクタデータ341Rが参照され、これに含まれているユーザキャラクタ名323Rが取得される。また、受信データ335の地域データ344Rが参照されることで、地域名も取得される。そして、これらのデータに基づき、地域と名前を表示した自己紹介画面(上記図7参照)が生成されて表示される。

0170

次に、図34のステップS48において、処理対象キャラクタが「初対面」となるユーザキャラクタか否かが判定される。「初対面」か否かは、例えば、当該処理対象キャラクタのユーザキャラクタID322Rを基にして受信ユーザキャラ情報保存データを検索し、検索できたか否かで判定される(検索できなかった場合は「初対面」となる)。

0171

当該判定の結果、初対面であるときは(ステップS48でYES)、ステップS49において、初対面処理が実行される。図35は、当該初対面処理の詳細を示すフローチャートである。まず、ステップS101において、初対面用のあいさつが表示される。当該初対面用のあいさつは、予め定義されている文字列である。ここでは、上記図8で示したような、「はじめまして」というあいさつが表示される。

0172

次に、ステップS102において、あいさつ処理の実行に関してお互いに許可されているか否かが判定される。例えば、まず、アプリセーブデータ363のあいさつ処理実行フラグ374が参照され、自分側のあいさつ処理の実行許可が設定されているか否かが判定される。その結果、許可されていなければ、当該ステップS102の判定結果はNOとなる。許可されていれば、次に、処理対象キャラクタのあいさつ処理実行フラグ345Rが参照され、相手側のあいさつ処理の実行許可が設定されているか否かが判定される。ここで許可されていないときは、当該ステップS102の判定結果はNOとなる。許可されているときは、当該ステップS102の判定結果はYESとなる。

0173

ステップS102の判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは(ステップS102でNO)、後述のステップS105に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されていれば(ステップS102でYES)、ステップS103において、受信データ335の共通あいさつ文字列データ342Rが参照され、処理対象キャラクタにかかる(つまり、相手側の)「共通あいさつ」が表示される。

0174

次に、ステップS104において、アプリセーブデータ363の共通あいさつ文字列データ372が参照され、ユーザ自身が作成した(つまり、自分側の)「共通あいさつ」が表示される。つまり、初対面のときは、「個別あいさつ」は一切用いられないことになる。

0175

次に、ステップS105において、処理対象キャラクタにかかる近況報告の処理が実行される。これは、受信データ335のプロフィールデータ343Rが参照されることで、その内容を反映したメッセージが生成されて表示される処理である。以上で、初対面処理は終了する。

0176

図34に戻り、初対面処理が終わると、後述するステップS78に処理が進められ、次の他のユーザキャラクタにかかる処理に移行することになる(つまり、初対面時は、評価処理はなされないことになる)。

0177

一方、図34のステップS48の判定の結果、初対面のキャラクタではないときは(ステップS48でNO)、次に、ステップS50において、処理対象キャラクタとの遭遇回数(すれちがい通信が行われた回数)を表示する処理が実行される。具体的には、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタにかかるすれちがい回数394が取得される。そして、この回数に1を加算した値に基づいて上記図9で示したような画面が生成されて表示される。また、この加算後の値は、当該処理対象キャラクタにかかるすれちがい回数394として記憶される。

0178

次に、ステップS51において、あいさつ処理を行うか否かが判定される。すなわち、双方ともに「あいさつ処理」の実行許可が設定されているか否かが判定される。当該判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは(ステップS51でNO)、後述のステップS67に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されているときは(ステップS51でYES)、ステップS52において、処理対象キャラクタ(相手側)のあいさつの種類が「共通あいさつ」か否かかが判定される。具体的には、まず、処理対象キャラクタにかかる受信データ335の個別あいさつデータ347Rが参照され、自分側のユーザキャラクタのユーザキャラクタID322と一致する宛先ユーザキャラID348Rが検索される。その結果、検索できた場合は、相手側のあいさつは「個別あいさつ」であり、見つからなかった場合は、相手側のあいさつは「共通あいさつ」であると判定される。

0179

ステップS52の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」であるときは(ステップS52でYES)、ステップS53において、処理対象キャラクタにかかる受信データ335の共通あいさつ文字列データ342Rに基づいて、処理対象キャラクタ側の「共通あいさつ」が表示される。

0180

次に、ステップS54において、処理対象キャラクタとのすれちがい回数が2回目であるか否かが判定される。例えば、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタに対応する受信ユーザキャラのデータが存在するか否かが判定される。そして、存在していれば、すれちがい回数394が参照され、「2回目」を示すデータが格納されているときは、今回、2回目のすれちがいが行われたと判定される。このような判定の結果、すれちがい回数が2回目のときは(ステップS54でYES)、ステップS55において、「個別あいさつ」が送信可能となった旨のメッセージを表示する。次に、ステップS56において、上記図14で示したような、あいさつ選択ウィンドウ105に表示する内容の設定が行われる。ここでは、上記図14で示されているような「みんな向け」と「こべつの」という2つの選択肢が設定される。その後、後述するステップS61に処理が進められる。

0181

一方、上記ステップS54の判定の結果、2回目ではない(つまり、3回目以上)のときは(ステップS54でNO)、上記ステップS55の処理はスキップされる。

0182

次に、上記ステップS52の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」ではないとき(ステップS52でNO)、つまり、「個別あいさつ」であるときの処理について説明する。このときは、上記図13で示したような、相手側の「個別あいさつ」と、これの基になった自分側のあいさつの文字列を示す画面を表示するための処理が実行される。まず、図36のステップS57において、処理対象キャラ側の個別あいさつデータ347Rが参照され、引用あいさつ文字列データ350Rが取得される。そして、当該データで示される文字列、つまり、前回のすれちがい時に自分側が行ったあいさつ内容が表示される。続いて、ステップS571において、同じく処理対象キャラ側の個別あいさつデータ347Rが参照され、自分宛の個別あいさつ文字列データ349Rが取得される。そして、当該データに基づき、相手側の「個別あいさつ」が表示される。その結果、まず、前回すれちがい時に自分側が行ったあいさつが表示され、これに答えるように、相手側の「個別あいさつ」が次に表示されることになる。このように、自分側のあいさつと相手側のあいさつを順番に表示することで、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102とがあたかも会話しているかのような表現が行われることになる。。

0183

次に、ステップS58において、処理対象データにかかる受信データ335の引用あいさつ種別フラグ351Rが参照され、当該処理対象キャラクタと前回すれちがい通信が行われた際に、自分側が送ったあいさつの種類が「個別あいさつ」であったか否かが判定される。その結果、前回送ったあいさつが「個別あいさつ」のときは(ステップS58でYES)、ステップS59において、あいさつ選択ウィンドウ105の内容が設定される。ここで設定される内容は、上記図14で示したようなあいさつ選択ウィンドウ105の内容となる。

0184

一方、前回送ったあいさつが「共通あいさつ」のときは(ステップS58でNO)、ステップS581において、引用あいさつ文字列データ350Rと共通あいさつ文字列データ372とが参照され、その内容が一致するか否かが判定される。その結果、一致していないときは(ステップS581でNO)、上記ステップS59に処理が進められる。一方、一致しているときは(ステップS581でYES)、次のステップS60において、あいさつ選択ウィンドウ105の内容が設定されるが、ここで設定される内容は、図39に示すような、個別あいさつをするかしないかを問い合わせるような内容となる。これは、「共通あいさつ」で同じあいさつを複数回行ってしまうことを防止するため、「共通あいさつ」に対する相手側の「個別あいさつ」に対して「個別あいさつ」を返すことを促すためである。また、上記ステップS581の判定は、前回すれちがい通信が行われた後、「共通あいさつ」の文字列がユーザによって変更され、更にその後に同じ相手とすれちがい通信が行われた場合を想定したものである。つまり、ある相手に一旦「共通あいさつ」を送った後、「共通あいさつ」の文字列をユーザが変更した場合は、その後同じ相手に「共通あいさつ」を送ったとしても、そのあいさつ内容は別の文字列となっているため、同じ文字列の「共通あいさつ」が連続して行われることにはならない。このような、「共通あいさつ」の変更が行われたか否かを判別するために上記ステップS581の判定が行われている。

0185

図36に戻り、次に、ステップS61において、上記ステップS59またはステップS60で設定された内容であいさつ選択ウィンドウ105が生成されて表示される。そして、当該選択ボックスに対するユーザからの入力が受け付けられる。

0186

次に、ステップS62で、上記あいさつ選択ウィンドウ105に対するユーザの選択内容が「個別あいさつ」を選択したものであるか否かが判定される。当該判定の結果、「個別あいさつ」が選択されていないときは(ステップS62でNO)、ステップS63において、共通あいさつ文字列データ372に基づいた「共通あいさつ」が表示される。そして、後述のステップS67に処理が進められる。

0187

一方、「個別あいさつ」が選択されたときは(ステップS62でYES)、ステップS64において、「個別あいさつ」を作成する処理が実行される。具体的には、文字列入力画面が表示され、ユーザからの文字列入力が受け付けられる。ユーザからの文字列入力が終われば、確認メッセージが表示され(上記図16参照)、入力内容が確定すれば、次のステップS65において、当該入力された文字列データに基づき、上記図17で示したように、上記ユーザの入力した「個別あいさつ」が表示される。次に、ステップS66において、アプリセーブデータ363の個別あいさつデータ376が更新される。具体的には、現在の処理対象キャラクタを示すユーザキャラクタID322Rが、アプリセーブデータ363の個別あいさつデータ376に含まれる宛先ユーザキャラIDとして記憶される。また、上記入力が確定した文字列のデータが個別あいさつ文字列データとして記憶され、現在の処理対象キャラクタ側のあいさつの文字列データが引用あいさつ文字列データとして記憶され、現在の処理対象キャラ側のあいさつの種別を示すデータが引用あいさつ種別フラグとして記憶される。以上で、あいさつ処理は終了する。

0188

次に、図37のステップS67において、相手側の近況報告処理が行われる。相手側の近況報告処理が終われば、次に、評価処理が行われる。まず、ステップS68において、自分側と相手側の双方ともに評価処理の実行許可が設定されているか否かが判定される。これは、相手側と自分側の評価処理実行フラグが参照されることで判定される。当該判定の結果、少なくとも一方で評価処理の実行許可が設定されていないときは(ステップS68でNO)、後述のステップS78に処理が進められる。

0189

一方、双方ともに評価処理の実行許可が設定されているときは(ステップS68でYES)、ステップS69において、処理対象キャラクタについて既に評価済みであるか否かが判定される。これは、まず、処理対象キャラとのすれちがい回数が2回目か否かが判定され、2回目であれば、まだ評価していないと判定される。一方、3回目以降であるときは、更に、受信ユーザキャラ情報保存データ364に保存されている処理対象キャラクタのユーザキャラデータ392と、受信データ335における送信用ユーザキャラクタデータ341Rとが比較され、ユーザキャラクタの外見が一致するか否かが判定される。その結果、外観に違いがあるときは、新たな外観についての評価はまだ行われていないとして、まだ評価していないと判定される。3回目以降であって、前回から外観に変化がないときは、評価済みであると判定される。なお、例えば2回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが「許可しない」設定であり、3回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが「許可する」設定となっていた場合であっても、2回目と3回目とで処理対象キャラの外観に変化がないときは、評価済みであると判定される。

0190

ステップS69の判定の結果、既に評価済みであるときは(ステップS69でYES)、後述のステップS75に処理が進められる。一方、まだ評価していないときは(ステップS69でNO)、ステップS70において、上記図18で示したような画面が表示される。すなわち、2つの選択肢(高評価/普通)を有する評価選択ウィンドウ107が表示される。そして、ユーザからの入力が受け付けられる。

0191

次に、ステップS71において、ユーザの入力内容に応じた処理対象キャラクタのリアクションが表示される(上記図19参照)。また、上記受信ユーザキャラ情報保存データ364に保存されている処理対象キャラのユーザキャラデータ392の内容が受信後のデータ内容に基づいて適宜更新される。

0192

次に、ステップS72において、上記ユーザの入力にかかる内容が、高評価にかかる内容であるか否かが判定される。その結果、高評価であったときは(ステップS72でYES)、ステップS73において、次回すれ違ったときに、当該処理対象キャラの送信元のゲーム装置1に評価が送信される旨の通知メッセージが表示される。次に、ステップS74において、アプリセーブデータ363のうち、上記評価処理に関するデータが適宜更新される。具体的には、アプリセーブデータ363の評価リスト377に処理対象キャラのユーザキャラクタIDが保存される、このとき、当該IDが重複していれば、古い方のIDは削除される。また、既に32件登録されている状態であれば、一番古いデータが削除されてから保存される。

0193

一方、上記ステップS72の判定の結果、高評価ではなかったときは(ステップS72でNO)、当該ステップS73およびステップS74の処理はスキップされる。

0194

次に、図38のステップS75において、相手側から自分への評価データがあるか否かが判定される。具体的には、まず、アプリセーブデータ363の受けた評価データ378が参照され、既に100件分の評価を受けているか否か(既に100件登録されているか否か)が判定される。その結果、100件未満のときは、次に、処理対象キャラクタにかかる受信データ335の評価リスト352Rから自分のユーザキャラクタ(すれちがい通信用として現在設定されているユーザキャラクタ)のユーザキャラクタIDが検索される。その結果、見つかったときは、自分への評価データがあると判定され、見つからなかったときは、自分への評価データがないと判定される。一方、受けた評価データ378に既に100件分の評価が保存されていれば、相手側から自分への評価データがある場合でも、評価データはないものとして判定される。つまり、既に100件分の評価があるときは、相手側からの評価に関する処理は実行されないことになる。

0195

ステップS75の判定の結果、相手側から自分への評価データがないときは(ステップS75でNO)、後述のステップS78に処理が進められる。一方、自分への評価データがあるときは(ステップS75でYES)、ステップS751において、受信データ335の評価リスト352RのユーザキャラID353R(評価対象ユーザキャラクタID380に対応)と受信データ335の送信用ユーザキャラクタデータ341Rにおける作成者ID325R(評価した作成者情報381に対応)の組み合わせが、受けた評価データ378に既に存在するかどうかが判定される。その結果、既に存在するときは(ステップS751でYES)、この相手からは既に評価を受けていることになるため、後述のステップS78に処理が進められる。一方、存在しないときは(ステップS751でNO)、この相手からはまだ評価を受けたことがないことになる。この場合は、続くステップS76において、相手側からの評価を表示する処理が実行される。すなわち、上記図20で示したような画面が表示される。

0196

次に、ステップS77において、高評価の累計数が表示される。具体的には、まず、今回評価された自分側のユーザキャラクタID322が、評価者情報379の評価対象ユーザキャラクタID380として記憶され、今回の処理対象キャラクタの作成者情報325Rが評価した作成者情報381として記憶される。そして、受けた評価データ378に含まれる評価者情報379の件数が高評価の累計数として算出される。つまり、当該累計数は、複数のユーザキャラクタが作成されている場合は、これら全てのユーザキャラクタに対する高評価の数を合計した値が用いられることになる。各ユーザキャラクタは、相手毎に評価が得られるため、例えば、ユーザキャラクタAが、2人の他のユーザから高評価を得ており、ユーザキャラクタBについては4人の他のユーザから高評価を得ているときは、高評価の累計数は6となる。これは、高評価の数を集めることを目的にさせることで、ユーザに様々なユーザキャラクタを作成させて楽しんでもらう事を促進するためである。そして、この累計数に基づいて、上記図21で示したような画面が生成されて表示される。

0197

なお、上記ステップS751の判定の結果、上記の組み合わせが既に存在するときに、上記ステップS76に処理を進めるようにしても良い。この場合は、高評価の累計数は更新しないようにしてもよい。つまり、既に評価を受けた相手については、その相手からの評価の表示のみを行い、累計数は加算しないようにしてもよい。

0198

以上で、評価処理は終了する。このようにしてあいさつ処理や評価処理が終了したユーザキャラクタにかかる受信データ335は、処理済みであるとして、すれちがい受信データ334からクリアされる。

0199

次に、ステップS78において、上述したような処理がまだ行われていない受信データ335が残っているか否かが判定される。その結果、まだ残っているときは(ステップS78でYES)、上記ステップS46に戻り、処理が繰り返される。一方、全て処理したときは(ステップS78でNO)、ステップS79において、上述した処理内容が反映されるようにすれちがい送信データ333が適宜更新される。すなわち、あいさつ処理における個別あいさつに関連するデータである個別あいさつデータ347Sや、評価処理に関する評価リスト352S等が適宜更新される。

0200

次に、ステップS80において広場メイン画面が表示され、続くステップS81において、その他の広場アプリの処理が実行される。続くステップS82において、広場アプリの終了指示がユーザから指示されたか否かが判定され、終了指示がなされていなければ(ステップS82でNO)、上記ステップS81の処理が繰り返され、終了指示がなされたときは(ステップS82でYES)、当該広場アプリは終了され、ホームメニュー画面に戻ることになる。以上で、本実施形態にかかる広場アプリ処理の説明を終了する。

0201

このように、本実施形態では、最初は不特定多数に向けた「共通あいさつ」を用いて不特定多数相手とのコミュニケーションを図りつつ、その中で複数回すれ違った相手に対しては、その相手を特定した「個別あいさつ」が送信できるようにしている。これにより、他のユーザとの通信内容が画一的になることを防ぎ、よくすれ違う相手との親密度を高めることを可能として、上記のようなすれちがい通信による他人とのコミュニケーションの興趣性をより高めることが可能となる。換言すれば、すれちがい通信を繰り返すことで、親しくなれる可能性の高い他人を抽出し、その相手に対して個別にアプローチすることを可能とすることで、新たな友達を作る可能性を高めることができる。

0202

また、相手側の個別あいさつが表示される際、その個別あいさつの基になった自分側のあいさつ内容も合わせて表示されるようにしている。これにより、相手側のあいさつ(相手側の反応内容)が、自分が相手側に送ったどのようなあいさつに対してものであるかを把握させやすくすることができる。特に、上記のようなすれちがい通信によってあいさつが送受信される、換言すれば、あいさつ内容はリアルタイムにやりとりされるものではないため、このように過去に送ったあいさつ内容を表示することは効果的である。

0203

また、自己が作成したユーザキャラクタを、近距離無線通信であるすれちがい通信を用いて送信し、他のユーザに評価してもらうことが可能となっている。つまり、ユーザが生活する地域の近隣範囲内において、簡易なシステム構成によって自己の作成したユーザキャラクタを他人に評価してもらい、その結果をフィードバックしてもらうことが可能となる。これにより、自己のユーザキャラクタを他人に評価してもらうことを手軽にユーザに楽しんでもらうことが可能となる。その結果、複雑なシステム構成を用いることなく、他人とのコミュニケーションをより活発化させることが可能となる。

0204

また、評価については、高評価が行われたときにしか相手側にフィードバックしないようにしているため、ユーザが評価内容不満感じることを軽減して興趣性が下がってしまうことを防ぐことができる。更に、複数のユーザキャラクタを用いている場合、1つのユーザキャラクタについては原則評価は一回のみとする反面、各キャラクタに与えられた高評価の数を集計して表示するようにしている。そのため、よりたくさんの高評価を得るために、より多くのユーザキャラクタを生成し、より多くのすれちがい通信を行うことをユーザに促進させることが可能となる。

0205

なお、上記実施形態では、「あいさつ」の内容については、文字列のみの場合を例に挙げたが、この他、ユーザが自由な表現で作成することができるものであれば、画像や音声なども含むようにしてもよい。また、ゲーム装置1上で作成されるものに限られず、外部の装置で作成されたものを利用可能としてもよい。また、その他、例えば、「あいさつ」を表示するときに、ユーザキャラクタに所定のアクションを行わせるようにしてもよい(エモーション動作等)。この場合は、所定のアクションの内容を示すデータを上記「共通あいさつ」や「個別あいさつ」のデータに含めるようにすればよい。

0206

また、「個別あいさつ」を作成するタイミングに関して、上記実施形態では、上記あいさつ選択ウィンドウ105でユーザが「個別あいさつ」の作成を選択したときに、「個別あいさつ」の入力画面に遷移するようにしていた。この他、「個別あいさつ」については、他のタイミングにおいても作成することができるようにしてもよい。例えば、広場アプリのメイン処理の機能の一つとして「個別あいさつ」の作成と記憶が可能にしておき、ユーザは、この機能を用いて、いくつかの「個別あいさつ」を作成し、ゲーム装置1に記憶させておく。その後、上記の様なあいさつ処理が行われ、上記あいさつ選択ウィンドウ105で、ユーザが「個別あいさつ」の作成を選択したときは、入力画面は表示せずに、代わりに、上記の機能を用いて事前に作成しておいた「個別あいさつ」を選択肢(一覧)として表示させる。そして、ユーザにこの中から「個別あいさつ」を1つ選択させるようにすればよい。

0207

また、上記実施形態では、すれちがい通信は「スリープモード」のときに行われる場合を例に挙げたが、「スリープモード」以外の状態においても上記すれちがい通信が行われるように構成しても良い。

0208

また、上記実施形態では、送受信するゲーム装置1が共に携帯型ゲーム装置である場合を例に挙げたが、この他、いずれか一方は据置型ゲーム装置であってもよい。例えば、窓際に設置された据置型ゲーム装置と、その近くを通りがかったユーザの携帯型ゲーム装置との間で上記のようなすれちがい通信によりユーザキャラクタの送受信が行われてもよい。

0209

また、上記ユーザキャラクタに関して、上記実施形態では、ユーザキャラ作成アプリにおいてユーザが作成したユーザキャラクタをすれちがい通信用のユーザキャラクタに設定する場合を例に挙げていたが、この他、上記すれちがい通信によって取得された他のユーザキャラクタを、上記すれちがい通信用のキャラクタ(つまり、自分側から送信するユーザキャラクタ)として設定できるようにしてもよい。

0210

また、上記実施形態においては、他のゲーム装置1から受信した評価データに基づく評価結果を画面に表示する場合を例に挙げていたが、この他、評価結果を音声や振動等を用いてユーザに報知させるようにしてもよい。

0211

また、上記実施形態においては、すれちがい通信によって受信した他のユーザキャラクタを利用したあいさつ処理や評価処理に関する一連の処理については単一の装置(ゲーム装置1)において実行される場合を説明したが、他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。

0212

本発明にかかる通信システム、情報処理プログラム、情報処理方法、情報処理装置、情報処理システムは、簡易なシステム構成によって、ユーザが作成したコンテンツを他人に評価してもらうことを手軽に実現でき、各種ゲーム装置携帯型情報端末等に有用である。

0213

1…ゲーム装置
11…下側ハウジング
12…下側LCD
13…タッチパネル
14…操作ボタン
15、26…LED
16…マイクロフォン用孔
21…上側ハウジング
22…上側LCD
23…内側カメラ
24…音抜き孔
25…外側カメラ
27…タッチペン
28、29…メモリカード
31…CPU
32…メインメモリ
33…メモリ制御回路
34…保存用データメモリ
35…プリセットデータ用メモリ
36…メモリカードI/F
37…無線通信モジュール
38…ローカル通信モジュール
39…RTC
40…電源回路
41…I/F回路
42…マイク
43…アンプ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ