JP2016202683A - 情報処理装置、情報処理装置の制御方法、情報処理プログラムおよび情報処理システム - Google Patents

Abstract

【課題】同じアプリケーションプログラムに対して記憶媒体の種別に応じた処理を実行可能な情報処理装置を提供する。【解決手段】情報記憶媒体との間で近距離無線通信が可能な情報処理装置であって、第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、情報処理装置で実行される第１のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段とを備える。データ処理手段は、第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、第２の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与えない第２処理を実行する。【選択図】図２１

Description

本開示は、情報処理装置の情報処理に関し、近距離無線通信を行う情報処理装置、情報処理装置の制御方法、情報処理プログラムおよび情報処理システムに関する。

従来、例えばＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）等の近距離無線通信によって装置間で通信を行う技術がある（例えば、特許文献１参照）。近距離無線通信では、情報処理装置に対して記憶媒体（いわゆるタグ）が接近したことに応じて、情報処理装置と記憶媒体との間で通信が開始される（特許文献１）。

特開２０００−１６３５２４号公報

従来、近距離無線通信によって情報処理装置と通信を行う記憶媒体の種別は特定されており、同じアプリケーションプログラムの処理として異なる種別の記憶媒体を利用した処理は実行されていなかった。

本開示の目的は、同じアプリケーションプログラムに対して記憶媒体の種別に応じた処理を実行可能な情報処理装置、情報処理装置の制御方法、情報処理プログラムおよび情報処理システムを提供することである。

ある局面に従う情報記憶媒体との間で近距離無線通信が可能な情報処理装置であって、第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、情報処理装置で実行される第１のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段とを備える。データ処理手段は、第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、第２の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与えない第２処理を実行する。

好ましくは、データ処理手段は、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータに含まれる識別情報に基づいて第１処理あるいは第２処理のいずれかを実行する。

好ましくは、第２処理は、少なくとも第１処理の一部の処理を制限する処理を含む。
好ましくは、第１処理は、ゲームの進行指示に従って選択可能に設けられたオブジェクトを表示し、第２処理は、ゲームの進行指示とは無関係に選択不可能に設けられたオブジェクトを表示する。

好ましくは、データ処理手段は、情報処理装置で実行される第２のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータに基づき共通の第３処理を実行する。

好ましくは、第２の情報記憶媒体は、複数の種別が設けられ、データ処理手段は、第２の情報記憶媒体に対するデータの読出により読み出されたデータに基づき種別に応じた第２処理を実行する。

ある局面に従う情報記憶媒体との間で近距離無線通信が可能な情報処理装置の制御方法であって、第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行うステップと、情報処理装置で実行される第１のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するステップとを備える。データを処理するステップは、第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行するステップと、第２の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与えない第２処理を実行するステップとを含む。

ある局面に従う情報記憶媒体との間で近距離無線通信が可能な情報処理装置のコンピュータで実行される情報処理プログラムであって、情報処理プログラムは、コンピュータを、第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、情報処理装置で実行される第１のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段として機能させる。データ処理手段は、第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、第２の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与えない第２処理を実行する。

ある局面に従う情報処理システムであって、第１および第２の情報記憶媒体と、第１および第２の情報記憶媒体との間で近距離無線通信が可能な情報処理装置とを備える。情報処理装置は、第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、情報処理装置で実行される第１のアプリケーションプログラムにより、第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段とを含む。データ処理手段は、第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、第２の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与えない第２処理を実行する。

好ましくは、第１および第２の情報記憶媒体の形態は異なる。

上記によれば、同じアプリケーションプログラムに対して記憶媒体の種別に応じた処理を実行可能である。

本実施形態１に基づく情報処理システムの一例の構成を示す図である。 実施形態１に基づくタグ２の外観の一例を示す図である。 タグに記憶されるデータの一例を示す図である。 実施形態１に基づくタグ２からデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。 実施形態１に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）を説明するフローチャートである。 実施形態１に基づくタグ２に対してデータを書き込む場合における情報処理システムの処理の流れの一例を示す図である。 実施形態１に基づく書込指令を受けた場合における通信制御部３２の処理（書込指令処理）の流れの一例を示すフローチャートである。 第１のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。 第１イベント処理を説明するフロー図である。 一例として家外観設計画面を説明する図である。 家の内装を設計することが可能な画面を説明する図である。 タグ２に記憶されるデータの別の一例について説明する図である。 実施形態１に基づくタグ２の利用形態の一例を説明する図である。 第２のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。 実施形態１に基づく第２イベント処理を説明するフロー図である。 実施形態１に基づく一例として家外観を表示した場合を説明する図である。 実施形態２に基づくタグ２Ｐの外観の一例を示す図である。 実施形態２に基づくタグ２Ｐからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。 実施形態２に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。 実施形態２に基づく第２アプリ処理を説明するフロー図である。 実施形態２に基づく第２イベント処理を説明するフロー図である。 実施形態２に基づく一例としてユーザが操作するキャラクタオブジェクトを表示した場合を説明する図である。 実施形態３に基づくタグ２Ｑの外観の一例を示す図である。 実施形態３に基づくタグ２Ｑからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。 実施形態３に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。 実施形態３に基づく第２アプリ処理を説明するフロー図である。 実施形態３に基づく第２イベント処理を説明するフロー図である。 実施形態３に基づく選択画面を説明する図である。 タグ２Ｑに記憶されるデータの一例について説明する図である。 実施形態３に基づくタグ２Ｑの別の利用形態の一例を説明する図である。 実施形態４に基づく第２アプリ処理を説明するフロー図である。 実施形態４に基づく第２イベント処理を説明するフロー図である。 実施形態４に基づくポイント利用判定処理のサブルーチンについて説明するフロー図である。 タグ２Ｐに記憶されるデータの一例について説明する図である。 実施形態４に基づくポイント利用選択画面を説明する図である。 実施形態４に基づく一例としてベンチオブジェクトを表示した場合を説明する図である。

この実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。

（実施形態１）
＜情報処理システムの構成＞
図１は、本実施形態１に基づく情報処理システムの一例の構成を示す図である。

図１に示すように、情報処理システム１は、記憶媒体（タグ）２と、情報処理装置３とを含む。情報処理装置３は、タグ２との間で近距離無線通信が可能な任意の情報処理装置である。

本実施形態１においては、近距離無線通信の一例として、情報処理装置３とタグ２との間でＮＦＣ規格に基づく通信が行われる場合を例として説明する。ここで、近距離無線通信とは、一例として一方の装置からの電波によって（例えば電磁誘導によって）他方の装置に起電力を発生させる通信方式を指す。他方の装置は、発生した起電力によって動作することが可能である（他方の装置は、電源を有していてもよいし有していなくてもよい）。
近距離無線通信においては、情報処理装置３とタグ２とが接近した場合（典型的には両者の距離が十数センチ以下となった場合）に通信可能となる。また、近距離無線通信では、２つの通信装置の通信が確立している間（通信装置に他のタグが接近している間）は電波が送出され続ける。なお、一例として電波によって通信する方式について説明したが特にこれに限られず光でも良いし、他の媒体を用いた通信でも良くその方式については何ら限定しない。

情報処理装置３は、近距離無線通信が可能な任意の情報処理装置である。本実施形態１においては、情報処理装置３は、例えば携帯型ゲーム装置、携帯電話、あるいはスマートフォン等といった、携帯型（可搬型とも言う）の装置であってもよいし、パーソナルコンピュータや家庭用ゲーム機等といった据置型の装置であってもよいし、業務用のアーケードゲーム装置のような大型の装置であってもよい。例えば、情報処理装置３は、ＮＦＣリーダライタの機能を有する携帯機器である。

タグ２は、情報処理装置３との間で近距離無線通信が可能な任意の装置である。本実施形態１においては、タグ２は、ＮＦＣタグの機能を有する記憶媒体である。すなわち、タグは、近距離無線通信を行う回路（ＩＣチップ）と、データを記憶する記憶手段（メモリ等）とを備える。すなわち、記憶手段に対して読み書き可能な回路を含むＲＦＩＤ（Radio Frequency IDentification）である。なお、タグ２は、データを記憶する機能のみを有する装置（ＲＦタグ）であってもよく、例えばＮＦＣのカードエミュレーション機能を有する情報処理装置（携帯機器）であってもよい。

以下、情報処理装置３の構成について説明する。図１に示すように、情報処理装置３は通信部１１を備える。通信部１１は、近距離無線通信に用いられるアンテナである。また、情報処理装置３は通信チップ１２を備える。通信チップ１２は、後述するＣＰＵ１３からの指示に従い、通信部１１から送出すべき信号（電波）を生成する。生成された信号が通信部１１から送出される。通信チップ１２は、例えばＮＦＣチップである。

図１に示すように、情報処理装置３は、ＣＰＵ１３およびメモリ１４を備える。ＣＰＵ１３は、情報処理装置３で実行される各種の情報処理を実行するための情報処理部である。ＣＰＵ１３は、メモリ１４を用いて上記各種の情報処理を実行する。

情報処理装置３はプログラム記憶部１５を備える。プログラム記憶部１５は、情報処理装置３において実行される各種プログラム（後述する通信プログラムおよびアプリケーションプログラムを含む）を記憶する。プログラム記憶部１５は、ＣＰＵ１３がアクセス可能な任意の記憶装置（記憶媒体）である。プログラム記憶部１５は、例えばハードディスクやメモリ等の、情報処理装置３に内蔵される記憶部であってもよいし、例えば光ディスクやカートリッジ等の、情報処理装置３に着脱可能な記憶媒体であってもよいし、これらの記憶部および記憶媒体の両方であってもよい。

本実施形態１においては、情報処理装置３では、少なくともアプリケーションプログラムおよび通信プログラムという２種類のプログラムがプログラム記憶部１５に記憶される。アプリケーションプログラムは、タグ２との間でデータ通信を行う任意のアプリケーションを実行するためのプログラムである。アプリケーションプログラムは、例えば、タグ２からゲームデータを読み出して当該ゲームデータを用いてゲーム処理を行うゲームプログラムであってもよい。通信プログラムは、タグ２との間で近距離無線通信を行うためのプログラムである。例えば、通信プログラムは、通信チップ１２を動作させるためのファームウェアであり、ライブラリとして情報処理装置３に予め用意されていてもよい。通信プログラムは、アプリケーションからの指令を受けて通信のための動作を通信チップ１２に行わせる。なお、情報処理装置３において複数のアプリケーションプログラムが実行可能である場合、通信プログラムは、各アプリケーションで共通に使用される。つまり、通信プログラム（後述する通信制御部３２）は、複数のアプリケーションから通信に関する指令を受け付けることが可能である。

また、情報処理装置３は、ボタンやタッチパネル等、ユーザによる指示を受け付ける入力部１６を備える。また、情報処理装置３は、上記情報処理によって生成される画像を表示する表示部１７を備えている。

情報処理装置３は、複数の装置によって構成されてもよい。例えば、情報処理装置３は、ＣＰＵ１３およびメモリ１４を備える装置に対して、上記通信部１１および通信チップ１２を備える装置が着脱可能に接続される構成であってもよい。また、情報処理装置３は、ＣＰＵ１３を有する本体装置と、入力部１６および／または表示部１７を有する装置とが別体である構成であってもよい。例えば、他の実施形態において、情報処理装置３は、本体装置と、入力部１６および表示部１７を有する端末装置とによって構成されてもよいし、本体装置と、入力部１６を有する操作装置とによって構成されてもよい。また、情報処理装置３は、表示部１７を備えず、テレビを表示装置として用いる構成であってもよい。

また、他の実施形態においては、情報処理装置３において実行される情報処理の少なくとも一部が、ネットワーク（広域ネットワークおよび／またはローカルネットワーク）によって通信可能な複数の装置によって分散して実行されてもよい。

＜タグ＞
図２は、実施形態１に基づくタグ２の外観の一例を示す図である。

図２に示すように、本実施形態１におけるタグ２は、キャラクタの絵が描かれた（キャラクタを平面的に表す）外観を有するカード型のタグである。

カード型のタグとして一例としてタイプＴＹ１が関連付けられているものとする。
タグ２が表すキャラクタ（犬、Ａ子）は、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）に登場するキャラクタである。ユーザは、このタグ２を用いることによって、上記特定のアプリケーションにおいて上記キャラクタを登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２に記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間に上記のキャラクタを登場させる。なお、タグ２は、アプリケーションに登場する任意のオブジェクトを表すものであり、キャラクタに限らず、ゲームアプリケーションにおけるアイテムを表すものであってもよい。

上記のように、タグ２は、特定のアプリケーションプログラムにおいて用いられる。また、タグ２は、特定のアプリケーションプログラムにおいて利用可能なデータを記憶することができる。以下では、このような特定のアプリケーションプログラムを「特定アプリプログラム」と呼ぶ。

タグ２は、特定アプリプログラムにおいて利用可能である一方、他のアプリケーションプログラムにおいても利用を可能にしても良い。タグ２は、特定アプリプログラムにおいて利用可能なデータを記憶する一方、後述するが特定アプリプログラム以外の他のアプリケーションプログラムにおいても利用可能なデータを記憶させることも可能である。

なお、当該タグ２は、複数のキャラクタにそれぞれ対応して複数種類設けることも可能である。また、一般的なキャラクタと特別なキャラクタとを分類してタグ２の種類を分けることも可能である。タグ２の種類を分けることにより実行される処理も変更可能なようにしても良い。

以下、タグ２に記憶されるデータの一例について説明する。
図３は、タグに記憶されるデータの一例を示す図である。

図３に示すように、タグ２は、読み書き可能領域２１と、読み出し専用領域２２と、管理領域２３とを有する。

また、図３に示すように、読み書き可能領域２１には、特定アプリプログラムの実行により保存されるセーブデータが記憶される。セーブデータとしては、例えば、タグ２が表すキャラクタに関連する各種データ、特定アプリプログラムのゲームの進行状態を示すデータ、および／または、特定アプリプログラムのゲームのプレイヤに関するデータ等が記憶される。

なお、読み書き可能領域２１には、複数のセーブデータを格納することが可能である。具体的には、複数の特定アプリプログラムにそれぞれ対応するセーブデータを格納することが可能である。したがって、セーブデータと特定アプリプログラムとを関連付けるためのアプリケーションを識別するアプリＩＤがセーブデータとともに登録されている。

なお、本例においては、アプリＩＤがセーブデータとともに登録されている場合について説明するが、セーブデータを管理するために以下のキャラクタＩＤを用いるようにしてもよい。

なお、セーブデータに限られず、初期登録データを記憶するようにしてもよい。初期登録データは、情報処理装置３においてタグ２の利用が開始される際にユーザによって登録されるデータである。なお、初期登録データは、典型的には、タグ２が最初に利用されるタイミングでタグ２に記憶されるが、任意のタイミングでタグ２に記憶されてもよい。つまり、ユーザによるタグ２に対するデータの登録は、任意のタイミングで行われてもよい。

読み出し専用領域２２は、データの読み出しのみが可能な記憶領域である。読み出し専用領域２２は、タグ２の製造時においてデータが記憶され、その後（タグ２の出荷後）のデータの書き込みが禁止される記憶領域である。つまり、情報処理装置３（情報処理装置３において実行されるアプリケーション）は、読み出し専用領域２２に対するデータの書き込みを行うことは不可能である。一方、情報処理装置３（情報処理装置３において実行されるアプリケーション）は、読み書き可能領域２１に対するデータの読み出しおよび書き込みを行うことができる。なお、タグ２の出荷時においては読み書き可能領域２１にはデータが予め記憶されていてもよいし、記憶されていなくてもよい。いずれの場合であっても、タグ２と情報処理装置３との通信が行われると、情報処理装置３によって読み書き可能領域２１にデータが書き込まれて記憶される。

なお、図３に示すように、本実施形態１においては、各データが記憶される記憶領域（読み書き可能領域、読み出し専用領域、および管理データ領域）は予め定められているものとするが、他の実施形態においては定められていなくてもよい。

読み出し専用領域２２には、少なくとも次のデータ（情報）が記憶される。
・固有ＩＤ（を示すデータ２２１）
・タイプＩＤ（を示すデータ２２２）
・キャラクタＩＤ（を示すデータ２２３）
・シリーズＩＤ（を示すデータ２２４）
固有ＩＤは、タグに固有の識別情報である。ここで、本実施形態１におけるタグ２のようなＮＦＣタグには、ＵＩＤ（Ｕｎｉｑｕｅ ＩＤ）という、タグに固有の識別情報が記憶される。上記固有ＩＤは、このＵＩＤとは異なる情報である。固有ＩＤは、タグを用いたサービスの提供者がタグを管理しやすいように、ＵＩＤとは別に付されたＩＤである。

キャラクタＩＤは、カード型のタグ２の平面的に表されたキャラクタに固有の識別情報である。キャラクタＩＤは、タグ２のキャラクタの種類を一意に特定することが可能な識別情報である。例えば、１つのキャラクタにつき、それぞれ外観が異なる（例えば、ポーズや服装が異なる）複数種類のタグがある場合には、各タグには異なる値のフィギュアＩＤが設定される。この場合、フィギュアＩＤは、キャラクタに固有のＩＤと、ポーズ・服装などの違いを示すＩＤとを含んでもよい。

シリーズＩＤは、タグ２が表すオブジェクト（キャラクタ）が属するグループに固有の識別情報である。例えば、タグ２が表すキャラクタが複数種類のアプリケーション（例えば、一連のシリーズのゲームアプリケーション）に登場する場合、これら複数種類のアプリケーションが１つのグループに設定され、このグループを示すグループＩＤが設定されてもよい。

なお、情報処理装置３において実行可能なアプリケーションプログラムは、自身において利用する（利用可能な）タグのキャラクタＩＤの情報を含んでいる。アプリケーションプログラムに含まれるキャラクタＩＤの値と、タグに記憶されるキャラクタＩＤの値とが一致する場合、本例においては一例として特定アプリプログラムであると判断する。そして、後述するが当該特定アプリプログラムは、キャラクタＩＤに対応するキャラクタに関して当該タグに記憶されるセーブデータを利用したイベント処理を実行する。

タイプＩＤは、タグ２の種類を示す識別情報である。本実施形態１においては、情報処理装置３においては、タグ２のようなカード型のタグの他、フィギュア型のタグや、特殊なカード型のタグも利用可能であるとする。タイプＩＤは、タグの種類として、カード型のタグであるかフィギュア型のタグであるか、特殊なカード型のタグであるかを示す識別情報である。なお、他の実施形態においては、タイプＩＤによって識別可能なタグの種類は任意である。例えば、タグ２を提供する業者毎に異なるタイプＩＤが付されてもよい。本実施形態１においては、タグ２に記憶されているタイプＩＤと、アプリケーションプログラムに含まれるタイプＩＤとが一致する場合に当該タグ２にアクセス可能であると判定する。

次に、管理データについて説明する。管理データは、タグの管理のために用いられるデータであり、管理データは、基本的にはアプリケーションにおいては用いられないデータである。

図３に示すように、タグ２は、管理データとして、バージョン情報のデータを管理領域２３に記憶する。バージョン情報は、タグ２のデータフォーマット（記憶形式）に関するバージョンを示す。ここで、本実施形態１においては、タグ２におけるデータの記憶形式はバージョン毎に異なり、同じバージョンであればデータの記憶形式は同じであるとする。具体的には、本実施形態１においては、タグ２においてどのアドレスにどのデータが記憶されるかは、バージョン毎に定められている（なお、バージョン情報のデータが記憶されるアドレスは、バージョンが異なっても同じである）。したがって、情報処理装置３は、バージョン情報を参照することによって、各データが記憶されているアドレスを特定することができる。例えば、バージョン情報において各データのデータサイズ（各データの記憶領域のサイズ）を規定しておくことによって、バージョン情報からアドレスを特定することができる。

また、タグ２は、管理データとして、ハッシュ値を記憶する（図３参照）。ハッシュ値は、読み書き可能領域２１および読み出し専用領域２２内のデータに対応するハッシュ値である。ハッシュ値は、対応するデータに対して所定のアルゴリズム（ハッシュ関数）を適用することによって得られる。なお、読み出し専用領域２２内のデータの内容は変化しないが、読み書き可能領域２１内のデータの内容は変化するので、ハッシュ値は変化する。変化したハッシュ値のデータは管理領域２３に記憶される。

なお、本実施形態１においては、図３に示すデータのうち、情報処理装置３（本実施形態１においては、後述する通信制御部３２）によって復号可能な方式で暗号化されている。したがって、上記方式での復号機能を持たない装置によってタグ２から上記他のデータが読み出されても、当該装置はデータの内容を解読することはできない。これによって、タグ２内のデータのセキュリティを向上することができる。なお、他の実施形態においては、管理データも上記方式で暗号化されていてもよいし、３種類のデータのうち少なくとも１つは暗号化されていなくてもよい。

＜情報処理システムにおける処理動作＞
次に、実施形態１に基づく情報処理システム１の処理動作（読み出し）について説明する。

図４は、実施形態１に基づくタグ２からデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。

本実施形態１においては、情報処理装置３内における動作を、機能的にアプリケーション部３１と通信制御部３２とに分けて説明する。本実施形態１において、アプリケーション部３１は、上述のアプリケーションプログラムを実行するＣＰＵ１３である。通信制御部３２は、上述の通信プログラムを実行するＣＰＵ１３と、通信チップ１２および通信部１１とによって実現される。なお、他の実施形態においては、情報処理装置３における情報処理は、アプリケーションプログラムと通信プログラムという２種類のプログラムによって実現される必要は無く、単一のプログラムによって実現されてもよい。なお、図４においては、情報処理装置３において特定アプリプログラムが実行される場合、すなわち、アプリケーション部３１が特定アプリプログラムを実行するＣＰＵ１３によって実現される場合を示している。

図４に示されるように、アプリケーション部３１は、通信制御部３２に対してタグ２からのデータの読出指令を送る（処理ｓｑ１）。本実施形態１において、この読出指令にはタイプＩＤ、キャラクタＩＤおよびシリーズＩＤが含まれる。特定アプリプログラムは、自身がセーブデータを利用可能なタグのタイプＩＤ、キャラクタＩＤおよびシリーズＩＤの情報を含んでいる。したがって、アプリケーション部３１は、読出指令とともに、特定アプリプログラムに含まれるタイプＩＤ、キャラクタＩＤおよびシリーズＩＤを通信制御部３２へ送る。なお、キャラクタＩＤは、１種類に限られず複数種類のキャラクタＩＤを送信するようにしても良い。

なお、アプリケーション部３１は、特定アプリプログラムに含まれる各タイプＩＤを通信制御部３２に送る。ただし、タグの種類を特定できる場合には、アプリケーション部３１は、特定アプリプログラムに含まれる１以上のタイプＩＤのうち、当該タグのタイプＩＤのみを通信制御部３２に送ってもよい。同様に、キャラクタの種類を特定できる場合には、アプリケーション部３１は、特定アプリプログラムに含まれる１以上のキャラクタＩＤのうち、１つのキャラクタＩＤのみを通信制御部３２に送っても良い。例えば、プレイヤが操作しているキャラクタに対応するキャラクタを表すタグを利用するゲーム状況においてタグのデータを読み出す場合には、情報処理装置３に接続されるタグ２は、当該キャラクタのタグであると特定することができる。したがって、この場合、アプリケーション部３１は、当該キャラクタを表すタグのキャラクタＩＤのみを通信制御部３２に送ってもよい。

なお、他の実施形態においては、アプリケーション部３１は、読出指令（書込指令等の他の指令でも同様）を送るタイミングとは異なるタイミングでタイプＩＤ、キャラクタＩＤおよびシリーズＩＤを通信制御部３２に送るようにしてもよい。例えば、他の実施形態においては、後述するアクセス許可判定処理において通信制御部３２がタイプＩＤをアプリケーション部３１に対して要求し、この要求に応じてアプリケーション部３１がタイプＩＤを通信制御部３２へ送るようにしてもよい。同様に、特定アプリ判定処理において通信制御部３２がキャラクタＩＤをアプリケーション部３１に対して要求し、この要求に応じてアプリケーション部３１がキャラクタＩＤを通信制御部３２へ送るようにしても良い。シリーズＩＤについても同様である。

読出指令を受け付けると、通信制御部３２は、一連の処理（読出指令処理）の実行を開始する。

具体的には、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（処理ｓｑ２）。そして、通信制御部３２は接続処理したタグ２からデータの読出処理を実行する（処理ｓｑ３）。そして、通信制御部３２は、読み出したデータに基づいてアクセス許可判定処理を実行する（処理ｓｑ４）。ここでは許可と判定された場合が示されている。次に、通信制御部３２は、特定アプリ判定処理を実行する（処理ｓｑ５）。ここでは、特定アプリと判定された場合が示されている。そして、通信制御部３２は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（処理ｓｑ６）。

図５は、実施形態１に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）を説明するフローチャートである。

図５を参照して、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（ステップＳ１）。接続処理の具体的な内容は任意である。例えば、通信制御部３２は、通信部１１の周囲に存在するタグ２を検知する処理（例えばポーリング処理）と、検知されたタグ２との間で通信を確立するための処理（例えば、データ通信に必要な情報をタグ２から取得する処理）とを実行する。なお、図示していないが、読出指令処理（後述する書込指令処理においても同様）の途中においてタグ２が情報処理装置３から離れて近距離無線通信が行えなくなった場合、通信制御部３２は読出指令処理を終了し、アプリケーション部３１とのデータの受け渡しを中止する。

次に、通信制御部３２はデータの読出処理を実行する（ステップＳ２）。具体的には、通信制御部３２は、まず、管理データをタグ２から読み出す。そして、読み出した管理データに含まれるバージョン情報に基づいて、タグ２内の各データのアドレスを特定する。なお、バージョン情報に基づいてアドレスを特定する具体的な方法は任意である。例えば、バージョン情報自体に、各データとアドレスとの対応関係を示す情報がバージョン情報に含まれていてもよい。また例えば、上記対応関係とバージョン情報とを関連付けたテーブルを通信制御部３２が予め記憶しておき、タグ２から読み出したバージョン情報と当該テーブルとを用いて通信制御部３２が対応関係を特定してもよい。

各データのアドレスが特定されると、通信制御部３２は、タイプＩＤをタグ２から読み出す。通信制御部３２は、読み出したデータを復号してメモリ１４に記憶しておく。

次に、通信制御部３２は、アクセス許可判定処理を実行する（ステップＳ３）。アクセス許可判定処理は、情報処理装置３上で実行されるアプリケーションプログラムによる、通信が確立したタグへのアクセスが許可されるか否かを判定する処理である。換言すれば、アクセス許可判定処理は、通信が確立したタグが、情報処理装置３上で実行されるアプリケーションプログラムによるアクセスが許可されたタグ（以下、「許可タグ」と呼ぶ）か否かを判定する処理である。なお、「許可タグ」は、例えば、情報処理装置３（および／または情報処理装置３で実行可能なアプリケーションプログラム）を提供する事業者が許可したタグである。つまり、本実施形態１においては、情報処理装置３上のアプリケーションは、上記事業者によって許可されたタグにのみアクセス可能であり、上記事業者によって許可されないＮＦＣタグに対してデータの読み出し／書き込みを行うことはできない。

本実施形態１においては、アクセス許可判定処理における判定は、タグ２に記憶される所定の情報に基づいて実行する。例えば、通信制御部３２は、タグ２に記憶されている所定の情報を（情報処理装置３の側でも）予め記憶しておき、タグから読み出した情報と、予め記憶しておいた情報とが一致するか否かによって上記判定を行ってもよい。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致する場合には許可タグであると判断する。なお、この判定に用いる所定の情報としては、本例においては、ＮＦＣタグに記憶されている、ＮＦＣの規格において定められるタグのタイプ（ＴＹ１，ＴＹ２等）を示す情報を利用する。

なお、これに限られず、情報処理装置３（および／または情報処理装置３で実行可能なアプリケーションプログラム）を提供する事業者が許可するタグであることを示す情報（専用コード）等を利用するようにしても良い。

あるいは、上述のバージョン情報を利用するようにしても良い。例えば、アクセス許可判定処理における判定は、読み出し専用領域２２に記憶されるデータが、バージョン情報から特定される設定に適合しているか否かによって行われてもよい。また例えば、アクセス許可判定処理における判定は、通信制御部３２によって読み出された所定のデータ（例えば、読み出し専用領域２２に記憶されるデータ）のサイズが所定の範囲内であるか否かによって上記判定を行ってもよい。

ステップＳ３において、通信制御部３２は、タグ２が許可タグでないと判断した場合（ステップＳ３においてＮＯ）には、その旨をアプリケーション部３１に通知する（ステップＳ４）。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致しない場合には許可タグでないと判断する。そして、当該通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、タグ２が許可されたものではないためにデータの読み出しを行うことができない旨をユーザに対して通知する。ステップＳ４の処理の終了後、通信制御部３２は、読出指令処理を終了する（エンド）。

一方、ステップＳ３において、通信制御部３２は、タグ２が許可タグであると判断した場合（ステップＳ３においてＹＥＳ）には、特定アプリ判定処理を実行する（ステップＳ５）。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致する場合には、特定アプリ判定処理を実行する。特定アプリ判定処理は、通信制御部３２に対する指令（ここでは読出指令）を行ったアプリケーションプログラムが特定アプリプログラムであるか否かを判定する処理である。

特定アプリ判定処理における判定は、上述のキャラクタＩＤを用いて行われる。すなわち、通信制御部３２は、アプリケーション部３１から指令と共に取得したキャラクタＩＤ（キャラクタＩＤが複数である場合にはそのうちのいずれか）と、ステップＳ２でタグ２から読み出したキャラクタＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは特定アプリプログラムであると判定する。特定アプリプログラムと判定した場合（ステップＳ５においてＹＥＳ）、通信制御部３２は、通信制御部３２は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（ステップＳ６）。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、キャラクタＩＤとセーブデータの受け取りを許可する。なお、ステップＳ６の処理の終了後、通信制御部３２は、図５に示す読出指令処理を終了する（エンド）。

なお、通信制御部３２からキャラクタＩＤとセーブデータを受け取ったアプリケーション部３１は、受け取ったデータを用いた情報処理を実行する。なお、本例においては、通信制御部３２から一例としてキャラクタＩＤとセーブデータとをアプリケーション部３１に出力する場合について説明するが特にこれに限られず、いずれか一方出会っても良いし、あるいは、他のデータでも良くこれらの組み合わせであっても良い。情報処理で利用可能なデータであればどのようなデータであっても良い。

この情報処理の内容は任意である。例えば、アプリケーション部３１は、セーブデータを用いたゲーム処理を実行する。なお、本実施形態１においては、特定アプリプログラムは、セーブデータを用いることとするが、セーブデータとともにキャラクタＩＤおよびタイプＩＤ等を用いた処理であってもよい。

一方、両者が異なれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは非特定アプリプログラム（特定アプリプログラムではないアプリケーションプログラム）と判定する。特定アプリプログラムでないと判定した場合（ステップＳ５においてＮＯ）、関連アプリ判定処理を実行する（ステップＳ７）。具体的には、タグ２から読み出したシリーズＩＤと、アプリケーション部３１から送られたシリーズＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは関連アプリプログラムであると判定する。関連アプリプログラムと判定した場合（ステップＳ７においてＹＥＳ）、通信制御部は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（ステップＳ６）。

通信制御部３２は、タグ２から読み出したシリーズＩＤと、アプリケーション部３１から送られたシリーズＩＤとが一致しない場合（ステップＳ７においてＮＯ）、上記指令を行ったアプリケーションプログラムは、関連アプリプログラム（関連アプリとも称する）でないと判定する。そして、通信制御部３２は、アプリケーション部３１に対して特定アプリでないことを通知する（ステップＳ８）。つまり、指令を行ったアプリケーションプログラムが関連アプリを除く非特定アプリプログラムである場合には、通信制御部３２は、セーブデータの受け取りを制限（禁止）する。なお、ステップＳ７の処理の終了後、通信制御部３２は、図５に示す読出指令処理を終了する（エンド）。

なお、本例においては、特定アプリで無い場合には、通信制御部３２からのセーブデータを送信しない場合について説明しているが、例えばキャラクタＩＤのみを送信するようにしても良い。アプリケーション部３１は、受け取ったキャラクタＩＤのデータを用いた情報処理を実行する。この情報処理の内容は任意であるが、例えば、キャラクタＩＤを用いて、キャラクタＩＤが表すキャラクタを表示する処理を実行するようにしても良い。

なお、本実施形態１においては、ステップＳ６のデータ出力処理において、通信制御部３２は、タグ２に記憶されているセーブデータの全てをアプリケーション部３１へ出力するものとした。ただし、他の実施形態においては、アプリケーション部３１は、取得すべきデータを読出指令において指定し、ステップＳ６の処理において、通信制御部３２は、当該読出指令において指定されたデータをアプリケーション部３１へ出力するようにしてもよい。なお、このとき、読出指令において指定されたデータがセーブデータであって、ステップＳ４の処理において、読出指令を行ったアプリケーションプログラムが非特定アプリプログラムであると判定された場合には、ステップＳ７において、通信制御部３２は、データの出力（読み出し）が制限されている旨をアプリケーション部３１へ通知するようにしてもよい。

次に、実施形態１に基づく情報処理システム１の処理動作（書き込み）について説明する。

図６は、実施形態１に基づくタグ２に対してデータを書き込む場合における情報処理システムの処理の流れの一例を示す図である。

図６に示されるように、アプリケーション部３１は、通信制御部３２に対してタグ２に対するデータの書込指令を送る（ｓｑ１０）。本実施形態１において、この書込指令には、上述した読出指令と同様、アプリケーション部３１のアプリケーションプログラムに含まれるタイプＩＤが含まれる。特定アプリプログラムは、自身がセーブデータを保存可能なタグのタイプＩＤの情報を含んでいる。したがって、アプリケーション部３１は、書込指令とともに、特定アプリプログラムに含まれるタイプＩＤを通信制御部３２へ送る。なお、タイプＩＤは、１種類に限られず複数種類のタイプＩＤを送信するようにしても良い。

書込指令を受け付けると、通信制御部３２は、一連の処理（書込指令処理）の実行を開始する。

具体的には、通信制御部３２は、タグとの通信を開始するための接続処理を実行する（処理ｓｑ１１）。そして、通信制御部３２は、接続処理したタグ２からデータの読出を処理する（処理ｓｑ１２）。そして、通信制御部３２は、読み出したデータに基づいてアクセス許可判定処理を実行する（処理ｓｑ１３）。ここでは許可と判定された場合が示されている。次に、通信制御部３２は、アプリケーション部３１に許可通知を出力する（処理ｓｑ１４）。許可通知を受け取ったアプリケーション部３１は、タグ２に書き込むべきデータ（ここでは、セーブデータ）を生成し、通信制御部３２へ送る（処理ｓｑ１５）。通信制御部３２は、アプリケーション部３１からセーブデータを取得する（処理ｓｑ１６）。通信制御部３２は、取得したセーブデータに関してタグ２に対する書込処理を実行する（処理ｓｑ１７）。

図７は、実施形態１に基づく書込指令を受けた場合における通信制御部３２の処理（書込指令処理）の流れの一例を示すフローチャートである。

図７を参照して、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（ステップＳ１０）。接続処理の具体的な内容は任意である。例えば、通信制御部３２は、通信部１１の周囲に存在するタグ２を検知する処理（例えばポーリング処理）と、検知されたタグ２との間で通信を確立するための処理（例えば、データ通信に必要な情報をタグ２から取得する処理）とを実行する。なお、図示していないが、書込指令処理（後述する書込指令処理においても同様）の途中においてタグ２が情報処理装置３から離れて近距離無線通信が行えなくなった場合、通信制御部３２は書込指令処理を終了し、アプリケーション部３１とのデータの受け渡しを中止する。

次に、通信制御部３２は、データの読出処理を実行する（ステップＳ１１）。具体的には、通信制御部３２は、まず、管理データをタグ２から読み出す。そして、読み出した管理データに含まれるバージョン情報に基づいて、タグ２内の各データのアドレスを特定する。なお、バージョン情報に基づいてアドレスを特定する具体的な方法は任意である。例えば、バージョン情報自体に、各データとアドレスとの対応関係を示す情報がバージョン情報に含まれていてもよい。また例えば、上記対応関係とバージョン情報とを関連付けたテーブルを通信制御部３２が予め記憶しておき、タグ２から読み出したバージョン情報と当該テーブルとを用いて通信制御部３２が対応関係を特定してもよい。

各データのアドレスが特定されると、通信制御部３２は、タイプＩＤをタグ２から読み出す。通信制御部３２は、読み出したデータを復号してメモリ１４に記憶しておく。

次に、通信制御部３２は、アクセス許可判定処理を実行する（ステップＳ１２）。アクセス許可判定処理は、情報処理装置３上で実行されるアプリケーションプログラムによる、通信が確立したタグへのアクセスが許可されるか否かを判定する処理である。

ステップＳ１２において、通信制御部３２は、タグ２が許可タグでないと判断した場合（書込指令を行ったタグ２はアクセスが許可されていない場合）（ステップＳ１２においてＮＯ）には、不許可のタグであることを通知する（ステップＳ１６）。通信制御部３２は、データの書き込みを行うことができない旨をアプリケーション部３１に通知する。この通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、接続されたタグ２は、実行中のアプリケーションによってデータの書き込みを行うことができないタグである旨をユーザに通知する処理を実行する。ステップＳ１６の後、通信制御部３２は書込指令処理を終了する（エンド）。

一方、通信制御部３２は、書込指令処理において、ステップＳ１２の判定結果が肯定であった場合（書込指令を行ったタグ２はアクセスが許可されている場合）（ステップＳ１２においてＹＥＳ）には、アプリケーション部３１に対して許可通知を出力する（ステップＳ１３）。

次に、通信制御部３２は、タグ２に書き込むべきデータをアプリケーション部３１から取得する（ステップＳ１４）。

次に、通信制御部３２は、タグ２に対する書込処理を実行する（ステップＳ１５）。上述のように、本実施形態１においては、タグ２に対するデータの書き込みは、タグ２の読み書き可能領域２１に対して行われる。すなわち、通信制御部３２は、ステップＳ１４でアプリケーション部３１から取得したセーブデータを、タグ２に書き込む。その際、通信制御部３２は、セーブデータとともに当該セーブデータに対応するアプリＩＤをともにタグ２に書き込む。なお、タグ２に書き込むことにより内容は変更されることになる。

したがって、ステップＳ１５において、通信制御部３２は、変更後のセーブデータについてハッシュ値を算出する。そして、算出したハッシュ値を新たなハッシュ値としてタグ２に書き込む。ステップＳ１５の処理の後、通信制御部３２は書込指令処理を終了する（エンド）。

なお、他の実施形態においては、タグ２に対するデータの書き込みおよび読み出しは、所定の単位毎に行われてもよい。例えば、タグ２の記憶領域が複数のブロックに分割されている場合、タグ２に対するデータの書き込みおよび読み出しは、このブロック毎に行われてもよい。

なお、本例においては、書込処理指令において、タグ２のタイプＩＤが一致するか否かすなわち、アクセスが許可されたタグであるか否かに基づいてタグ２に対する書込処理を許可する方式について説明したが、特にこれに限られない。例えば、読出指令処理と同様にキャラクタＩＤが一致するか否かすなわち、特定アプリプログラムか否かに基づいてタグ２に対する書込処理を許可するようにしても良い。さらに他の条件を付加するようにするようにしても良い。

次に、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理（第１アプリ処理）について説明する。

図８は、第１のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。なお、図８に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開示される。

図８では、第１のアプリケーションプログラムによる処理の一例として、ゲーム処理が実行される場合を説明する。また、タグ２に記憶されるデータ（キャラクタＩＤ）を用いて、タグ２が表すキャラクタをゲーム空間に登場させる等のイベント処理を例として説明する。

ステップＳ４１において、アプリケーション部３１は、第１のアプリケーションプログラムに従ってゲーム処理を実行する。このゲーム処理の内容は任意であり、例えば、ユーザの入力に応じて仮想空間（ゲーム空間）におけるキャラクタの動作を制御したり、プログラムにおいて規定されているアルゴリズムに従って他のキャラクタの動作を制御したりする処理が実行される。

ステップＳ４２において、アプリケーション部３１は、タグ２との通信を行うか否かを判定する。すなわち、アプリケーション部３１は、タグ２との通信を行うための所定のゲーム条件が満たされたか否かを判定する。この所定のゲーム条件は、ゲーム状況が、タグ２が表すキャラクタが登場することができる状況になったことであり、例えば、プレイヤキャラクタが所定のステージに進んだことや、プレイヤキャラクタが所定のアイテムを取得したこと等である。

なお、ステップＳ４２の処理は、ステップＳ４１におけるゲーム処理が実行される間の適宜のタイミングで実行される。

したがって、ステップＳ４２の判定処理の結果が否定となる場合、ステップＳ４１の処理が再度実行され、ステップＳ４２の判定処理の結果が肯定となるまでステップＳ４１およびＳ４２の処理が繰り返し実行される。一方、ステップＳ４２の判定処理の結果が肯定となる場合、後述するステップＳ４３の処理が実行される。

ステップＳ４３において、アプリケーション部３１は、読出指令を出力し、タグ２からデータを読み出す。すなわち、上述したように、アプリケーション部３１はまず、通信制御部３２へ読出指令を出力する。これに応じて、図５で説明したフローに従って通信制御部３２はタグ２との通信を行い、タグ２から読み出したデータをアプリケーション部３１へ渡す。これによって、アプリケーション部３１はタグ２からのデータを取得する。なお、上述のように、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、タグ２からキャラクタＩＤと特定アプリプログラムに対応するセーブデータとが取得される。なお、タグ２に保存されているセーブデータが無い場合には、キャラクタＩＤのみが取得される。

なお、図８では示していないが、接続されたタグ２が許可タグでない場合（ステップＳ３の判定結果が否定となる場合）には、タグ２が許可タグでない旨の通知が通信制御部３２からアプリケーション部３１へ送られる。この場合、アプリケーション部３１は、例えば、データの読み出しを行うことができない旨をユーザに対して通知し、ステップＳ４１のゲーム処理を再開する。

ステップＳ４６において、アプリケーション部３１は、ステップＳ４３で取得されたキャラクタＩＤのキャラクタに基づく第１イベント処理を実行する。ここで、アプリケーションプログラムには、タグ２によってゲームに登場する各キャラクタを生成するためのデータが含まれている。また、アプリケーションプログラムには、当該各キャラクタのそれぞれに関連付けられたキャラクタＩＤの情報が予め登録されているものとする。

具体的には、アプリケーション部３１は、キャラクタＩＤが示すキャラクタを仮想空間に登場させたイベント処理を実行する。ここで、タグ２に記憶されるキャラクタＩＤが表すキャラクタをアプリケーション部３１がわかっている場合（当該キャラクタＩＤがアプリケーションにおいて登録されている場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができる。すなわち、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いて仮想空間内におけるキャラクタを生成する。

第１イベント処理の詳細については後述する。
次に、第１イベント処理に基づくデータを取得する（ステップＳ４８）。

次に、アプリケーション部３１は、書込指令を出力し、タグ２にデータを書き込む。すなわち、アプリケーション部３１は、通信制御部３２へ書込指令を出力する（ステップＳ４９）。これに応じて、図７で説明したフローに従って通信制御部３２はタグ２との通信を行い、アプリケーション部３１から通信制御部３２に書き込むデータを出力する。

そして、通信制御部３２からタグ２に対してデータを書き込む。
そして、次に、ゲームが終了したかどうかを判断する（ステップＳ５０）。

ステップＳ５０において、ゲームが終了した場合（ステップＳ５０においてＹＥＳ）には、処理を終了する（エンド）。

一方、ステップＳ５０において、ゲームが終了していない場合（ステップＳ５０においてＮＯ）には、ステップＳ４１に戻り、ゲーム処理を継続する。

図９は、第１イベント処理を説明するフロー図である。
図９に示されるように、まず、セーブデータがあるかどうかを判断する（ステップＳ５１）。具体的には、通信制御部３２から送られたキャラクタＩＤとセーブデータとを取得した場合には、セーブデータは有りと判断する。この点で、キャラクタＩＤのみ取得した場合には、セーブデータは無しと判断する。

また、複数のアプリケーションプログラムにそれぞれ対応する複数のセーブデータがある場合には、特定アプリプログラムに対応するセーブデータを取得する。その際、実行中の特定アプリプログラムに対応するセーブデータを取得するために少なくとも１つのアプリＩＤが利用される。特定アプリプログラムのアプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが有るか否か判断される。特定アプリプログラムのアプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無い場合には、セーブデータは無しと判断する。なお、後述するが特定アプリプログラムのアプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。

ステップＳ５１において、セーブデータが有ると判断した場合（ステップＳ５１においてＹＥＳ）には、ステップＳ５２において、特定アプリプログラムに対応するセーブデータを読み込む。

一方、ステップＳ５１において、セーブデータが無いと判断した場合（ステップＳ５１においてＮＯ）には、セーブデータは無し、すなわち初期状態と判断する。

次に、家外観設計画面を表示する（ステップＳ５３）。
セーブデータがある場合には、セーブデータの内容に基づいて家外観設計画面を表示する。セーブデータが無い場合には、初期状態として規定された内容に基づいて家外観設計画面を表示する。

図１０は、一例として家外観設計画面を説明する図である。
図１０に示されるように、本例における家外観設計画面は、ユーザ（操作者）がキャラクタＩＤに対応するキャラクタの家外観の設計を設定することが可能な画面である。当該画面を用いてユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家外観を設計することが可能である。

本例においては、画面上部において、仮想空間内の家モデル１００が表示されるとともに、画面下部において、当該家モデルを設計するために必要なパーツ（設計部品）を選択する選択画面が表示されている。

本例においては、家モデル１００の外観として３つのパートに分けられた場合が示されている。具体的には、家の屋根、家の側面、ドアに分けられている。

家の屋根、家の側面、ドアの設計にそれぞれ対応して３つのタブ４０〜４２が設けられており、タブ４０〜４２を切り替えることによりそれぞれのパートの家外観を設定することが可能に設けられている。

タブ４０の選択により、家の屋根を選択可能な画面に切り替わる。
タブ４１の選択により、家の側面を選択可能な画面に切り替わる。

タブ４２の選択により、家のドアを選択可能な画面に切り替わる。
本例においては、一例としてタブ４２が選択された状態であり、家のドアのパーツを選択可能な画面が示されている。本例においては、それぞれドアの形状等が異なる「メルヘンなドア」、「アラブなドア」、「しかくいアラブなドア」、「しかくいまどつきのドア」、「しかくいおかしなドア」、「しかくいおもいドア」を選択可能な画面が示されている。

上下に操作可能なスライダ４３が設けられており、スライダ４３を操作することにより、複数種類の家のドアのパーツを上下にスクロール表示することが可能である。

そして、画面に表示された家のドアのパーツの文字をタッチすることにより入力部１６（タッチパネル）を介して当該パーツを指定することが可能である。

画面上部においては、一例として指定により「しかくいまどつきのドア」を有する家モデル１００が表示されている。

そして、当該画面には、「けってい」ボタン４４が設けられており、「けってい」ボタン４４を選択することにより家外観設計画面の設計が終了して次の処理が実行される。

例えば、家の内装を設計可能な設定画面が表示され、当該設定が可能であるものとする。

再び、図９を参照して、次に、ステップＳ５４において、設定したかどうかを判断する。具体的には、上記家外観設計画面において、家モデル１００の外観に関する各種の設計をしたかどうかを判断する。すなわち、「けってい」ボタン４４を選択したかどうかを判断する。なお、初期状態として家外観として各種のパーツが予め選択された状態としても良い。

設定が無いすなわち、設定が完了しない場合（ステップＳ５４においてＮＯ）には、ステップＳ５３に戻り、上記処理を繰り返す。

次に、設定したと判断した場合（ステップＳ５４においてＹＥＳ）には、次に、家側面ＩＤ、屋根ＩＤ、ドアＩＤを設定する。上記家外観設計画面で設計されたパーツ（設計データ）には、当該パーツを識別するＩＤが予め割り当てられている。具体的には、家側面ＩＤ、屋根ＩＤ、ドアＩＤは、上記家モデルを表示するためのパーツ（設計データ）を識別するＩＤであり、当該仮想空間に配置する家モデルの外観表示に関連する環境データである。言い換えれば当該環境データは、仮想空間の状況（環境）を示すデータである。具体的には、環境データは、仮想空間に配置されるオブジェクト表示（構成）を示すデータである。環境データは、キャラクタに関連する周辺の環境データであり、キャラクタデータ（強さのパラメータ等）とは異なる。

そして、次に内装設計画面を表示する（ステップＳ５６）。
図１１は、家の内装を設計することが可能な画面を説明する図である。

図１１（Ａ）は、内装の変更、削除等の編集が可能な画面である。当該画面を用いてユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家の内装を設計することが可能である。具体的には、家具の配置を変更したり、家具を削除等したりすることが可能である。

図１１（Ｂ）、（Ｃ）は、キャラクタＩＤに対応するキャラクタに関する家具等を追加する場合を説明する図である。

図１１（Ｂ）の画面上部には、上記で設計した家内部にキャラクタＩＤに対応するキャラクタオブジェクトが表示されている場合が示されている。また、画面下部には、家内部に配置する家具を選択する画面が表示されている。当該画面を用いて、ユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家の内装を設計することが可能である。

本例においては、図１１（Ｂ）において家具の一例として「滑り台」のアイコン５０を選択（購入）して、図１１（Ｃ）において家の内部に「滑り台」のオブジェクトを配置した状態が示されている。

再び図９を参照して、次に、設定したかどうかを判断する（ステップＳ５７）。具体的には、上記家内装設計画面において、家モデル１００の内装に関する各種の設計をしたかどうかを判断する。すなわち、図示しない「けってい」ボタンを選択したかどうかを判断する。なお、初期状態として家内装として各種のパーツが予め選択された状態としても良い。

ステップＳ５７において、設定していないと判断した場合（ステップＳ５７においてＮＯ）には、ステップＳ５６に戻り、上記処理を繰り返す。

一方、ステップＳ５７において、設定したと判断した場合（ステップＳ５７においてＹＥＳ）には、次に、内装ＩＤ等を設定する（ステップＳ５８）。

そして、処理を終了する（リターン）。
図１２は、タグ２に記憶されるデータの別の一例について説明する図である。

図１２に示すように、図３のタグ２に記憶されるデータと比較して、セーブデータの内容が具体的に示されている。

具体的には、家の外観および内装のオブジェクトを規定する家側面ＩＤ（データ２１２）、屋根ＩＤ（データ２１３）、ドアＩＤ（データ２１４）、内装ＩＤ（データ２１５）、家具ＩＤ（データ２１６）等が格納されている。当該セーブデータを利用したアプリケーションプログラムを実行する際に当該セーブデータに基づく設定した家モデルを仮想空間内に表示させることが可能である。

また、当該セーブデータに基づく第１イベント処理を再び実行することにより家モデルの再設計を実行することが可能である。当該家モデルの再設計によりタグ２に記憶されるデータを更新することが可能である。

図１３は、実施形態１に基づくタグ２の利用形態の一例を説明する図である。
図１３に示されるように、本例においては、（１）アプリケーションプログラムＡ（アプリＡ）に従いタグ２のデータの読み込みを実行する。次に、（２）アプリケーションプログラムＡ（アプリＡ）に従いタグ２へのデータの書き込みを実行する。そして、本例においては、（３）アプリケーションプログラムＡ（アプリＡ）とは別のアプリケーションプログラムＢ（アプリＢ）に従いタグ２のデータの読み込みを実行する。本実施形態１においては、アプリＡに従いタグ２へのデータの書き込みを実行したデータに関して、アプリＢで当該データを利用する場合について説明する。

次に、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理（第２アプリ処理）について説明する。

図１４は、第２のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。なお、図１４に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開示される。

図１４では、第２のアプリケーションプログラムによる処理の一例として、ゲーム処理が実行される場合を説明する。また、タグ２に記憶されるデータ（キャラクタＩＤ）を用いて、タグ２が表すキャラクタ等をゲーム空間に登場させる等のイベント処理を例として説明する。

ステップＳ６１〜Ｓ６３においては、図８のステップＳ４１〜Ｓ４３で説明したのと同様の処理が実行される。ステップＳ６３において、アプリケーション部３１は、読出指令を出力し、タグ２からデータを読み出す。すなわち、上述したように、アプリケーション部３１はまず、通信制御部３２へ読出指令を出力する。これに応じて、図５で説明したフローに従って通信制御部３２はタグ２との通信を行い、タグ２から読み出したデータをアプリケーション部３１へ渡す。これによって、アプリケーション部３１はタグ２からのデータを取得する。なお、上述のように、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、タグ２からキャラクタＩＤと特定アプリプログラムに対応するセーブデータとが取得される。なお、タグ２に保存されているセーブデータが無い場合には、キャラクタＩＤのみが取得される。

ステップＳ６６において、アプリケーション部３１は、ステップＳ６３で取得されたキャラクタＩＤのキャラクタに基づく第２イベント処理を実行する。ここで、アプリケーションプログラムには、タグ２によってゲームに登場する各キャラクタを生成するためのデータが含まれている。また、アプリケーションプログラムには、当該各キャラクタのそれぞれに関連付けられたキャラクタＩＤの情報が予め登録されているものとする。

ステップＳ６６における第２イベント処理の詳細については後述する。
具体的には、アプリケーション部３１は、キャラクタＩＤが示すキャラクタ等を仮想空間に登場させたイベント処理を実行する。ここで、タグ２に記憶されるキャラクタＩＤが表すキャラクタをアプリケーション部３１がわかっている場合（当該キャラクタＩＤがアプリケーションにおいて登録されている場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができる。すなわち、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いて仮想空間内におけるキャラクタを生成する。

そして、次に、ゲームが終了したかどうかを判断する（ステップＳ６８）。
ステップＳ６８において、ゲームが終了した場合（ステップＳ６８においてＹＥＳ）には、処理を終了する（エンド）。

一方、ステップＳ６８において、ゲームが終了していない場合（ステップＳ６８においてＮＯ）には、ステップＳ６１に戻り、ゲーム処理を継続する。

図１５は、実施形態１に基づく第２イベント処理を説明するフロー図である。
図１５に示されるように、まず、関連セーブデータがあるかどうかを判断する（ステップＳ２１）。具体的には、アプリケーション部３１は、通信制御部３２から送られたキャラクタＩＤとセーブデータとを取得した場合に、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。

アプリケーション部３１は、関連するアプリケーションプログラム（関連アプリプログラム）のアプリＩＤに対応するセーブデータがあるかどうかを判断する。関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。

ステップＳ２１において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ２１においてＮＯ）には、関連セーブデータは無しと判断する。

この場合には、ステップＳ２５に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステップＳ６５）。

そして、処理を終了する（リターン）。なお、後述するが関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。

ステップＳ２１において、関連セーブデータが有ると判断した場合（ステップＳ２１においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む。

次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ２３）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。

次に、取得した家外観データに基づいて家外観を表示する（ステップＳ２４）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。

そして、ステップＳ２５に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステップＳ２５）。

そして、処理を終了する（リターン）。
図１６は、実施形態１に基づく一例として家外観を表示した場合を説明する図である。

図１６に示されるように、本例においては、関連セーブデータに含まれている家外観データに基づいて仮想空間内に家モデル１００を表示する。ここでは、すごろくゲームを実行するアプリケーションプログラムを実行した場合のゲーム画面が表示されている。当該ゲーム画面において、すごろくゲームの進行に用いられる複数のマスが配置されている場合が示されている。すごろくゲームは、ユーザの操作に従って出現するすごろくの目（数字）に応じてユーザが操作するキャラクタがマスを進むことによりゲームが進行する。一例として、「あと４マス」との表示に従いユーザが操作するキャラクタが４マス分、マスを進むことが可能であることが示されている。本例における第２イベント処理としては、関連セーブデータに基づいて当該ゲームの仮想空間内のオブジェクトとして上記家モデル１００を表示する。当該オブジェクトは、ユーザの操作や指示を受け付けることができないオブジェクト（操作受付不可のオブジェクト）であり、ゲームの進行に影響を与える要因とはならない。当該オブジェクトは仮想空間内の背景画像としてのみ用いられる。

本実施形態１に基づく情報処理装置３は、第１のアプリケーションプログラム（アプリＡ）とは異なる第２のアプリケーションプログラム（アプリＢ）を実行する際に、アプリＡで処理したタグ２に記憶したデータを利用して処理する。当該処理により、記憶媒体（タグ）のデータを異なるアプリケーションプログラム間で利用することにより、データの汎用性を高めた処理が可能である。これによりタグ２を汎用的に利用することが可能となり、種々の利用形態を適用することが可能である。

本実施形態１に基づく情報処理装置３は、第１のアプリケーションプログラム（アプリＡ）とは異なる第２のアプリケーションプログラム（アプリＢ）を実行する際に、上記第２イベント処理として、ゲームの進行に影響を与えないオブジェクトを表示する処理を実行する。例えば、ゲーム画面におけるオブジェクトとして家モデル１００を表示させる。すなわち、ゲームの進行に影響を与えるゲームパラメータ（例えばキャラクタの強さのパラメータ等）については変化させない処理を実行する。

また、ゲームの進行に影響を与えないゲーム画面におけるオブジェクトとしてキャラクタＩＤが示すキャラクタオブジェクト１１０（操作受付不可のオブジェクト）を表示させる。

なお、第２イベント処理は、タグ２に記憶された第１のアプリケーションプログラム（アプリＡ）により処理されたデータのみを利用したイベント処理であり、タグ２に記憶された第１のアプリケーションプログラム（アプリＡ）により処理されたデータを更新はしない。
（タグの外観に関する変形例）
上記実施形態１においては、タグ２は、キャラクタの絵が描かれた（キャラクタを平面的に表す）カード型のタグについて説明したが、キャラクタを立体的に表すフィギュア型のタグであってもよい。また、タグの形状はこれに限らず、任意の形状であってよい。これによれば、タグ２を用いてアプリケーションにおいて登場させることができるオブジェクトをユーザにわかりやすく認識させることができる。また、上記オブジェクトを表示部１７に表示する場合には、現実のオブジェクトがあたかも仮想空間に入り込んで登場したかのような感覚をユーザに体験させることができ、アプリケーションの興趣性を向上することができる。

（実施形態２）
実施形態２においては、同じアプリケーションプログラムに対して種別が異なるタグにより処理が異なる場合について説明する。具体的には、タグの種別に応じて第２アプリ処理において処理が異なる場合について説明する。第１アプリ処理についてはタグの種別に依らず同様であるとする。

図１７は、実施形態２に基づくタグ２Ｐの外観の一例を示す図である。
図１７に示すように、本実施形態におけるタグ２Ｐは、キャラクタを立体的に表わすフィギュア型のタグである。

フィギュア型のタグとして一例としてタイプＴＹ２が関連付けられているものとする。
タグ２Ｐが表すキャラクタ（犬、Ａ子）は、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）に登場するキャラクタである。ユーザは、このタグ２Ｐを用いることによって、上記特定のアプリケーションにおいて上記キャラクタを登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２Ｐに記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間に上記のキャラクタを登場させる。

図１８は、実施形態２に基づくタグ２Ｐからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。

図１８に示されるように、図４の情報処理システムの流れと比較して異なる点は、処理ｓｑ６が処理ｓｑ６Ｐに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。

図１９は、実施形態２に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。

図１９に示されるように、図５の読出指令を受けた場合における通信制御部３２の処理（読出指令処理）とを説明するフローチャートと比較して、ステップＳ６をステップＳ６Ｐに置換した点が異なる。その他の構成については同様であるのでその詳細な説明については繰り返さない。

具体的には、ステップＳ６Ｐにおいて、通信制御部３２は、アプリケーション部３１に対してタイプＩＤとキャラクタＩＤとセーブデータとを出力する。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、タイプＩＤとキャラクタＩＤとセーブデータの受け取りを許可する。

図２０は、実施形態２に基づく第２アプリ処理を説明するフロー図である。
図２０に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｐに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。

図２１は、実施形態２に基づく第２イベント処理を説明するフロー図である。
図２１に示されるように、まず、タグのタイプを確認する（ステップＳ７０）。具体的には、アプリケーション部３１は、通信制御部３２から送られたタイプＩＤを確認する。

次に、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であるか否かを判断する（ステップＳ７１）。

アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であると判断した場合（ステップＳ７１においてＹＥＳ）に、取得したセーブデータに関して、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する（ステップＳ７２）。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。

関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。

ステップＳ７２において、関連セーブデータが有ると判断した場合（ステップＳ７２においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む（ステップＳ７３）。

次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ７４）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。

次に、取得した家外観データに基づいて家外観を表示する（ステップＳ７５）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。具体的には、図１６に示されるように仮想空間内の家モデル１００が表示される。

そして、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７６）。また、図１６に示されるように、仮想空間内にキャラクタオブジェクト１１０を表示する。当該キャラクタオブジェクト１１０は、ユーザが操作することのできない（ユーザの操作を制限する）選択不可能なキャラクタである。

そして、処理を終了する（リターン）。
また、ステップＳ７２において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ７２においてＮＯ）には、関連セーブデータは無しと判断する。

この場合には、ステップＳ７６に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステッ７６）。

そして、処理を終了する（リターン）。なお、関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。

一方、取得したタイプＩＤがタイプＴＹ１でないと判断した場合（ステップＳ７１においてＮＯ）には、取得したタイプＩＤがタイプＴＹ２であるか否かを判断する（ステップＳ７７）。

ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。

そして、処理を終了する（リターン）。
一方、ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２でないと判断した場合（ステップＳ７７においてＮＯ）には、処理を終了する（リターン）。

図２２は、実施形態２に基づく一例としてユーザが操作するキャラクタオブジェクトを表示した場合を説明する図である。

図２２に示されるように、本例においては、すごろくゲームを実行するアプリケーションプログラムを実行した場合のゲーム画面が表示されている。当該ゲーム画面において、すごろくゲームの進行に用いられる複数のマスが配置されている場合が示されている。すごろくゲームは、ユーザの操作に従って出現するすごろくの目（数字）に応じてユーザが操作するキャラクタがマスを進むことによりゲームが進行する。本例においては、ユーザが操作するキャラクタオブジェクト１１１としてゲーム画面に表示されている場合が示されている。

なお、本例においては、ユーザが操作可能な複数のキャラクタオブジェクトがゲーム画面に表示されている。一例として４体のキャラクタオブジェクトがゲーム画面に表示されている。

また、キャラクタオブジェクトに対応したポイントがゲーム画面に表示されている。
一例として、キャラクタオブジェクト１１１に対応して設けられたポイント表示領域４００が表示されている。他のキャラクタオブジェクトについても同様である。また、当該ポイント表示領域４００内には、ポイント値４０２として「１０」ポイント有る場合が示されている。他のキャラクタオブジェクトについても同様である。当該ポイント値は、すごろくゲームを実行することによりキャラクタオブジェクトに対応して加減算される。

本実施形態２に基づく情報処理装置３は、第２のアプリケーションプログラム（アプリＢ）を実行する際に、タグのタイプに応じた処理を実行する。具体的には、タイプＴＹ１のタグについては、アプリＡで処理したタグ２に記憶したデータを利用して処理する。情報処理装置３は、ゲームの進行に影響を与えない処理を実行する。例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデル１００およびキャラクタＩＤが示すキャラクタオブジェクト１１０を表示させる。

一方で、タイプＴＹ２のタグについては、アプリＡで処理したタグ２に記憶したデータを利用しない。タグ２に記憶されているキャラクタＩＤに基づく処理を実行する。情報処理装置３は、ゲームの進行に影響を与える処理を実行する。例えば、ゲーム画面における操作するキャラクタとして選択可能なキャラクタオブジェクト１１１を表示させる。当該キャラクタオブジェクト１１１を操作したゲームを実行することが可能である。

当該処理により、同じアプリケーションプログラムであっても記憶媒体（タグ）の種別に応じて異なるイベント処理を実行することが可能である。

すなわち、異なる処理を実行することにより、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。

（実施形態３）
実施形態３においては、同じアプリケーションプログラムに対して種別が異なるタグにより処理が異なるさらに別の場合について説明する。具体的には、タグの種別に応じて第２アプリ処理において処理が異なる場合について説明する。

図２３は、実施形態３に基づくタグ２Ｑの外観の一例を示す図である。
図２３に示すように、本実施形態におけるタグ２Ｑは、カード型のタグである。

カード型のタグとして、図２のカード型のタグとは異なる種別として一例としてタイプＴＹ３が関連付けられているものとする。

また、当該タグ２Ｑは、タグ２の縦型のカードと比較して横型のカードであり外形的な形態が異なる。また、キャラクタの絵が描かれた外観を有しておらず、木が描かれた外観を有しており絵柄が異なる点でも形態が異なる。なお、カードの大小によっても外形的な形態を異なるようにしても良い。また、カードの材質により形態を異なるようにしても良い。例えば、タグの種別に従って、紙、プラスチック、樹脂等の材質により形態が異なるようにすることも可能である。

タグ２Ｑは、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）でのみ利用される。本例においては、アプリＢでのみ利用される。ユーザは、このタグ２Ｑを用いることによって、上記特定のアプリケーションにおいてゲームに用いられるマップ（一例としてすごろくマップ）を登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２Ｑに記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間にマップを登場させる。当該マップを利用したゲームを実行することが可能である。

図２４は、実施形態３に基づくタグ２Ｑからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。

図２４に示されるように、図４の情報処理システムの流れと比較して異なる点は、処理ｓｑ６が処理ｓｑ６Ｑに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。

図２５は、実施形態３に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。

図２５に示されるように、図５の読出指令を受けた場合における通信制御部３２の処理（読出指令処理）とを説明するフローチャートと比較して、ステップＳ６をステップＳ６Ｑに置換した点が異なる。その他の構成については同様であるのでその詳細な説明については繰り返さない。

具体的には、ステップＳ６Ｑにおいて、通信制御部３２は、アプリケーション部３１に対してタイプＩＤを出力する。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、タイプＩＤの受け取りを許可する。

図２６は、実施形態３に基づく第２アプリ処理を説明するフロー図である。
図２６に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｑに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。

図２７は、実施形態３に基づく第２イベント処理を説明するフロー図である。
図２７に示されるように、まず、タグのタイプを確認する（ステップＳ７０）。具体的には、アプリケーション部３１は、通信制御部３２から送られたタイプＩＤを確認する。

次に、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であるか否かを判断する（ステップＳ７１）。

アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であると判断した場合（ステップＳ７１においてＹＥＳ）に、取得したセーブデータに関して、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する（ステップＳ７２）。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。

関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。

ステップＳ７２において、関連セーブデータが有ると判断した場合（ステップＳ７２においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む（ステップＳ７３）。

次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ７４）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。

次に、取得した家外観データに基づいて家外観を表示する（ステップＳ７５）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。具体的には、図１６に示されるように仮想空間内の家モデル１００が表示される。

そして、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７６）。また、図１６に示されるように、仮想空間内にキャラクタオブジェクト１１０を表示する。当該キャラクタオブジェクト１１０は、ユーザが操作することのできない（ユーザの操作を制限する）選択不可能なキャラクタである。

そして、処理を終了する（リターン）。
また、ステップＳ７２において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ７２においてＮＯ）には、関連セーブデータは無しと判断する。

この場合には、ステップＳ７６に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステッ７６）。

そして、処理を終了する（リターン）。なお、関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。

一方、取得したタイプＩＤがタイプＴＹ１でないと判断した場合（ステップＳ７１においてＮＯ）には、取得したタイプＩＤがタイプＴＹ２であるか否かを判断する（ステップＳ７７）。

ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。

そして、処理を終了する（リターン）。
一方、ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２でないと判断した場合（ステップＳ７７においてＮＯ）には、取得したタイプＩＤがタイプＴＹ３であるか否かを判断する（ステップＳ８０）。

ステップＳ８０において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ３であると判断した場合（ステップＳ８０においてＹＥＳ）には、選択画面を表示する（ステップＳ８１）。タイプＩＤがタイプＴＹ３である場合には、アプリケーション部３１は、上記第２イベント処理として、本例においては、ユーザの選択に従ってタグ２Ｑに格納されたマップデータに基づくすごろくマップを登場させる。あるいは、ユーザの選択に従ってタグ２Ｑに対してすごろくマップのマップデータを格納することが可能となる。

一方、ステップＳ８０において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ３でないと判断した場合（ステップＳ８０においてＮＯ）には、処理を終了する（リターン）。利用可能でないタグであるため第２イベント処理を終了する。

図２８は、実施形態３に基づく選択画面を説明する図である。
図２８に示されるように、ここでは、「データをセーブしますか？」と「データをロードしますか？」の表示されており、ユーザによる選択可能な「セーブ」ボタン、「ロード」ボタン、「キャンセル」ボタンが設けられている場合が示されている。

再び図２７を参照して、次に、アプリケーション部３１は、選択画面においてセーブが選択されたかどうかを判断する（ステップＳ８２）。

ステップＳ８２において、アプリケーション部３１は、セーブが選択されたと判断した場合（ステップＳ８２においてＹＥＳ）には、データを取得する（ステップＳ８３）。

具体的には、ゲーム処理において利用しているマップデータを取得する。当該マップデータは、すごろくのマスに関するデータと、オブジェクト（操作受付不可オブジェクト）のデータとを含む。オブジェクト（操作受付不可オブジェクト）のデータは、図１６で説明した家モデル１００が表示されている場合には、家外観データを含む。また、オブジェクトのデータは、図１６で説明したキャラクタオブジェクト１１０が表示されている場合には、キャラクタＩＤを含む。

そして、次に、ステップＳ８４において、アプリケーション部３１は、通信制御部３２へ取得したデータに関する書込指令を出力する。

これに応じて、通信制御部３２はタグ２Ｑとの通信を行い（図７におけるステップＳ１０）、アプリケーション部３１から通信制御部３２に書き込むデータ（マップデータ）を出力する。そして、通信制御部３２からタグ２Ｑに対してデータを書き込む。

そして、処理を終了する（リターン）。
当該書込指令により、タグ２Ｑにマップデータをセーブすることが可能である。そして、当該タグ２Ｑを利用してデータをロードすることにより、上記セーブしたマップデータに基づくマップを表示させることが可能となる。

図２９は、タグ２Ｑに記憶されるデータの一例について説明する図である。
図２９に示すように、タグ２Ｑは、読み書き可能領域２１Ｑと、読み出し専用領域２２Ｑと、管理領域２３とを有する。具体的には、図３のタグ２に記憶されるデータと比較して、読み書き可能領域２１Ｑと、読み出し専用領域２２Ｑとが異なる。

読み出し専用領域２２Ｑには、少なくとも次のデータ（情報）が記憶される。
・固有ＩＤ（を示すデータ２２１）
・タイプＩＤ（を示すデータ２２２）
上記したように、タグ２Ｑは、アプリＢでのみ利用され、仮想空間にすごろくマップを登場させる。したがって、本例においては、キャラクタＩＤ（を示すデータ２２３）やシリーズＩＤ（を示すデータ２２４）は記憶されていない場合が示されている。

読み書き可能領域２１Ｑには、マップデータ（複数のセーブデータ）の内容が具体的に示されている。

具体的には、すごろくマップに配置されるオブジェクトを規定するオブジェクトＩＤ（データ２４０）、すごろくマップの地形等に関するマップＩＤ（データ２４２）、キャラクタＩＤ（データ２４６）、家外観データ（家側面ＩＤ（データ２１２）、屋根ＩＤ（データ２１３）、ドアＩＤ（データ２１４）等が格納されている。

再び、図２７を参照して、ステップＳ８２において、アプリケーション部３１は、セーブが選択されなかったと判断した場合（ステップＳ８２においてＮＯ）には、ロードが選択されたかどうかを判断する（ステップＳ８５）。

ステップＳ８５において、アプリケーション部３１は、ロードが選択されたと判断した場合（ステップＳ８５においてＹＥＳ）には、セーブデータを読み込む（ステップＳ８６）。具体的には、セーブデータとしてタグ２Ｑに書き込んだマップデータを取得する。当該マップデータには、すごろくのマスのマップの地形等に関するデータ（マップＩＤ）と、オブジェクト（操作受付不可オブジェクト）のデータ（キャラクタＩＤ）等が含まれる。

そして、次に、アプリケーション部３１は、取得したマップデータに基づくマップを表示する（ステップＳ８７）。

一方、ステップＳ８５において、アプリケーション部３１は、ロードが選択されなかったと判断した場合（ステップＳ８５においてＮＯ）には、処理を終了する（リターン）。
具体的には、「キャンセル」ボタンが選択されたと判断してタグ２Ｑに関するイベント処理を終了する。

本実施形態３に基づく情報処理装置３は、第２のアプリケーションプログラム（アプリＢ）を実行する際に、タグのタイプに応じた処理を実行する。具体的には、タイプＴＹ１のタグについては、アプリＡで処理したタグ２に記憶したデータを利用して処理する。情報処理装置３は、ゲームの進行に影響を与えない処理を実行する。例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデル１００およびキャラクタＩＤが示すキャラクタオブジェクト１１０を表示させる。

また、タイプＴＹ２のタグ２Ｐについては、アプリＡで処理したタグ２Ｐに記憶したデータを利用しない。タグ２Ｐに記憶されているキャラクタＩＤに基づく処理を実行する。情報処理装置３は、ゲームの進行に影響を与える処理を実行する。例えば、ゲーム画面における操作するキャラクタとして選択可能なキャラクタオブジェクト１１１を表示させる。当該キャラクタオブジェクト１１１を操作したゲームを実行することが可能である。

また、タイプＴＹ３のタグ２Ｑについては、タグ２Ｑに記憶されているマップデータに基づく処理を実行する。例えば、ゲーム画面におけるマップを表示させる。あるいは、タグ２Ｑにマップデータをセーブ（格納）する処理を実行する。

当該処理により、同じアプリケーションプログラムであっても記憶媒体（タグ）の種別に応じて異なるイベント処理を実行することが可能である。

すなわち、異なる処理を実行することにより、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。

また、タイプＴＹ３のタグ２Ｑは、オブジェクト（操作受付不可オブジェクト）のデータを含むマップデータを格納する。したがって、ゲーム画面において当該オブジェクトが変更（更新）された場合には、更新されたオブジェクトを含むマップデータを格納することが可能である。

例えば、タイプＴＹ１のタグ２がアプリＢで利用される毎に、例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデルおよびキャラクタＩＤが示すキャラクタオブジェクトが表示される。そして、当該オブジェクト（操作受付不可オブジェクト）を含むマップデータをタイプＴＹ３のタグ２Ｑで格納し、次にゲーム処理する際に、当該タグ２Ｑを利用することにより、更新されたオブジェクト（操作受付不可オブジェクト）を含むマップデータに基づくマップでゲームを実行することが可能となる。

当該処理により、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。

図３０は、実施形態３に基づくタグ２Ｑの別の利用形態の一例を説明する図である。
図３０に示されるように、本例においては、情報処理装置３ａにおいて（１）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑのデータの読み込みを実行する。具体的には、タグ２Ｑに記憶されているすごろくゲームのマップデータの読み込みを実行する。そして、マップデータに基づくマップを表示してゲームを実行することが可能である。

次に、情報処理装置３ａにおいて（２）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑへのデータの書き込みを実行する。具体的には、すごろくゲームのマップデータ（オブジェクトのデータや家外観データ等）をタグ２Ｑに対して書き込みを実行する。

そして、本例においては、情報処理装置３ａとは別の情報処理装置３ｂにおいて（３）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑのデータの読み込みを実行する。そして、マップデータに基づくマップを表示してゲームを実行することが可能である。

本実施形態３においては、情報処理装置３ａにおいてアプリＢに従いタグ２Ｑへのデータの書き込みを実行したデータに関して、別の情報処理装置３ｂにおいてアプリＢで当該データを利用することが可能である。具体的には、オブジェクトのデータや家外観データは、マップ仮想空間に配置する家モデルの外観表示等に関連する環境データである。当該環境データをタグ２Ｑを利用して他のデバイスで利用することが可能である。

（実施形態４）
実施形態４においては、タグと情報処理装置とが関連付けられることにより第２アプリ処理において処理が異なる場合について説明する。

図３１は、実施形態４に基づく第２アプリ処理を説明するフロー図である。
図３１に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｒに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。

図３２は、実施形態４に基づく第２イベント処理を説明するフロー図である。
図３２に示されるように、図２７に示される第２イベント処理と比較して、ステップＳ９０，Ｓ９２を追加した点が異なる。その他のフローについては同様であるのでその詳細な説明については繰り返さない。

ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。

次に、アプリケーション部３１は、ポイントの利用の選択の指示が有るか否かを判断する（ステップＳ９０）。具体的には、ユーザからの操作指示に従ってポイントの利用の選択指示が有るかどうかを判断する。例えば、アプリケーション部３１は、情報処理装置３の入力部１６による所定の操作指示（例えば所定ボタンの操作）の有無に基づいてポイントの利用の選択指示が有るかどうかを判断する。

ステップＳ９０において、アプリケーション部３１は、ポイントの利用の選択の指示が有ると判断した場合（ステップＳ９０においてＹＥＳ）には、ポイントの利用の判定処理（ポイント利用判定処理）を実行する（ステップＳ９２）。ポイント利用判定処理は、キャラクタＩＤに対応するキャラクタオブジェクトに関して、当該キャラクタオブジェクトに対応付けられているポイント値を利用した処理が可能であるか否かを判定し、判定結果に基づいて所定の処理を実行する。

一方、ステップＳ９０において、アプリケーション部３１は、ポイントの利用の選択の指示が無いと判断した場合（ステップＳ９０においてＮＯ）には、ステップＳ９２のポイント利用判定処理をスキップして処理を終了する（リターン）。

図３３は、実施形態４に基づくポイント利用判定処理のサブルーチンについて説明するフロー図である。

図３３に示されるように、アプリケーション部３１は、登録済フラグがオンしているかどうかを判断する（ステップＳ１００）。具体的には、アプリケーション部３１は、タイプＴＹ２のタグ２ＰのアプリＩＤ（本例においてはアプリＢ）に対応するセーブデータに登録済フラグがオンとして登録されているか否かを判断する。

ステップＳ１００において、アプリケーション部３１は、登録済フラグがオンしていない（つまりオフ）と判断した場合（ステップＳ１００においてＮＯ）には、タグ２Ｐから取得したデータに含まれる固有ＩＤをメモリ１４に保存する（ステップＳ１０１）。

タグ２Ｐの固有ＩＤとは、タグ２Ｐから読み出したデータに含まれるタグ２Ｐを識別する情報（識別情報）である。

そして、次に、アプリケーション部３１は、通信制御部３２へ登録済フラグをオンする書込指令を出力する（ステップＳ１０２）。具体的には、アプリケーション部３１は、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤを保存（登録）することにより、タイプＴＹ２のタグ２ＰのアプリＩＤ（本例においてはアプリＢ）に対応するセーブデータとして登録済フラグをオンに設定する。

アプリケーション部３１は、タグ２Ｐの固有ＩＤをメモリ１４に登録することにより、登録されたタグ２Ｐのデータに基づく所定のイベント処理を実行する。

なお、ステップＳ１０１とステップＳ１０２との処理を入れ替えるようにすることも可能である。

図３４は、タグ２Ｐに記憶されるデータの一例について説明する図である。
図３４に示すように、タグ２Ｐは、読み書き可能領域２１Ｐと、読み出し専用領域２２と、管理領域２３とを有する。具体的には、図３のタグ２に記憶されるデータと比較して、セーブデータの内容が具体的に示されている。

読み書き可能領域２１Ｐには、アプリＩＤに対応するセーブデータが格納されている。
本例においては、一例としてアプリＢに対応するセーブデータが示されている。

セーブデータとして、登録済フラグ（データ２５０）と、ポイントデータ（データ２５２）が格納されている。

登録済フラグは、タグ２Ｐの固有ＩＤが情報処理装置３に登録されたことを示すデータである。登録済フラグがオンの場合には、登録済であることを示す。一方、登録済フラグがオフの場合には、未登録であることを示す。

ポイントデータは、アプリＢのすごろくゲームを実行することにより加減算されるポイント値を指し示す。

再び、図３３を参照して、ステップＳ１００において、アプリケーション部３１は、登録済フラグがオンであると判断した場合（ステップＳ１００においてＹＥＳ）には、ＩＤが一致するか否かを判断する（ステップＳ１０３）。具体的には、アプリケーション部３１は、登録済フラグがオンであると判断した場合には、タグ２Ｐから読み出したデータに含まれる固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致するか否かを判断する。

ステップＳ１０３において、アプリケーション部３１は、ＩＤが一致すると判断した場合（ステップＳ１０３においてＹＥＳ）には、ポイント利用選択画面を表示する（ステップＳ１０４）。具体的には、アプリケーション部３１は、タグ２Ｐから読み出したデータに含まれる固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致すると判断した場合には、ポイント利用選択画面を表示する。

図３５は、実施形態４に基づくポイント利用選択画面を説明する図である。
図３５に示されるように、ポイントを選択的に利用可能なポイント利用選択画面３００が示されている。

具体的には、キャラクタオブジェクトに対応付けられたポイント値を利用してマップ上に表示するオブジェクトを選択することが可能な画面が示されている。

一例として、「ベンチ」オブジェクト３０２が示されており、当該「ベンチ」オブジェクト３０２をマップ上に表示するためにポイント値として５ポイント必要である場合が示されている。

また、ポイント利用選択画面３００には、「使う」ボタン３０６と、「使わない」ボタン３０８とが設けられている。また、カーソル３０４が設けられている。

カーソル３０４を選択することによりマップ上に表示するオブジェクトを変更することが可能である。例えば、カーソル３０４を選択することにより「ベンチ」オブジェクトではなく、別の「ブランコ」オブジェクト等に変更することも可能である。

ユーザは、入力部１６を操作して「使う」ボタン３０６を選択することにより、当該表示されているオブジェクトを選択することが可能である。

一方、ユーザは、入力部１６を操作して「使わない」ボタン３０８を選択することにより、ポイント利用選択画面３００におけるポイントの利用の無しを選択することが可能である。そして、当該ポイント利用選択画面３００の表示が終了する。

例えば、ユーザが「使う」ボタン３０６を選択した場合には、「ベンチ」オブジェクト３０２をマップ上に表示することが可能である。

図３６は、実施形態４に基づく一例としてベンチオブジェクトを表示した場合を説明する図である。

図３６に示されるように、図２２の画面と比較して、「ベンチ」オブジェクト３０２がゲーム画面に表示されている。

なお、「ベンチ」オブジェクト３０２は、上記で説明した家モデル１００と同様、ゲームの進行に影響を与えないオブジェクト（操作受付不可オブジェクト）である。

また、当該処理により、キャラクタオブジェクト１１１に対応して設けられたポイント表示領域４００において、ポイント値４０２は、「１０」ポイントから「５」ポイントに変更された場合が示されている。

再び、図３３を参照して、アプリケーション部３１は、利用が有るかどうかを判断する（ステップＳ１０６）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使う」ボタンが選択されたか否かを判断する。

ステップＳ１０６において、アプリケーション部３１は、利用が有ると判断した場合（ステップＳ１０６においてＹＥＳ）には、オブジェクトを表示する（ステップＳ１０８）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使う」ボタンが選択された場合には、当該選択されたオブジェクトをマップ上に表示する。

そして、処理を終了する（リターン）。
一方、ステップＳ１０６において、アプリケーション部３１は、利用が無いと判断した場合（ステップＳ１０６においてＮＯ）には、処理を終了する（リターン）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使わない」ボタンが選択された場合には、当該ポイント利用選択画面の表示を終了する。

一方、ステップＳ１０３において、アプリケーション部３１は、ＩＤが一致しないと判断した場合（ステップＳ１０３においてＮＯ）には、処理を終了する（リターン）。具体的には、アプリケーション部３１は、タグ２Ｐのデータに含まれている固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致するか否かを判断し、一致しないと判断した場合には、ポイント利用選択画面の表示をスキップして処理を終了する。したがって、この場合にはポイントを利用することができない。

当該処理により、情報処理装置３のメモリ１４に登録されているタグの固有ＩＤと、タグ２Ｐから読み出したデータに含まれる固有ＩＤとが一致した場合に、セーブデータのポイントを利用してオブジェクトを配置することが可能である。一方で、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤと異なる固有ＩＤが登録されている場合には、セーブデータのポイントを利用することはできない。

例えば、ユーザがタグ２Ｐを有している場合に、タグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現してゲーム処理を実行することが可能である。タグ２Ｐに基づくゲーム処理を実行する場合、タグ２Ｐの固有ＩＤは、情報処理装置３のメモリ１４に登録されるものとする。また、タグ２Ｐの登録済フラグはオンに設定されるものとする。この場合、ゲーム処理として、タグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現して、当該タグ２Ｐに格納されているポイント値を利用した処理を実行することが可能である。

また、別のユーザが別のタグ２Ｐ（固有ＩＤは異なる）を有している場合、ゲーム処理として、当該別のタグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現してゲーム処理を実行することが可能である。当該別のタグ２Ｐの固有ＩＤは、別の情報処理装置３のメモリ１４に登録されているものとする。また、当該別のタグ２Ｐの登録済フラグはオンに設定されているものとする。この場合、ゲーム処理として、当該別のタグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現させるが、当該別のタグ２Ｐに格納されているポイント値を利用した処理は実行できない。つまり、この場合には制限された処理となる。

したがって、タグ２Ｐの固有ＩＤを情報処理装置３のメモリ１４に登録することにより情報処理装置３とタグ２Ｐとを関連付けることが可能となり、特定の装置においてゲーム処理として異なる処理を実行することが可能であり、タグを用いた処理の興趣性を高めることが可能である。

なお、本例においては、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤを登録して、アクセスするタグの固有ＩＤと比較して一致する場合に所定のイベント処理を実行する場合について説明したが、特に当該方式に限られず他の方式で実行するようにしても良い。

例えば、情報処理装置３の識別情報（ＩＤ）をタグ２Ｐに登録することにより、アクセスするタグ２Ｐに登録された当該識別情報（ＩＤ）と実行する情報処理装置３の識別情報（ＩＤ）とを比較して一致する場合に所定のイベント処理を実行するようにしても良い。

あるいはタグ２Ｐにユーザアカウント情報（ユーザ識別情報）を登録して、実行する情報処理装置３のメモリ１４に予め保存されているユーザアカウント情報とを比較して一致する場合に所定のイベント処理を実行するようにしても良い。

（情報処理システムの構成に関する変形例）
他の実施形態において、タグ２が情報処理部を有する場合には、情報処理装置３で実行される処理の一部は、タグ２の側で実行されてもよい。例えば、通信制御部３２における処理（の一部または全部）が、タグ２が有する情報処理部によって実行されてもよい。上記実施形態においては、通信制御部３２は実際にはタグ２からデータを読み出し、通信制御部３２がアプリケーション部３１へのデータの受け渡しを管理することによって、アプリケーション部３１によるタグ２からのデータの読み出しを制限するようにした。これに対して、通信制御部３２における処理がタグ２の側で実行される場合には、情報処理装置３によるタグ２からのデータの読み出しが実際に制限されることになる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ 情報処理システム、２ タグ、３ 情報処理装置、１１ 通信部、１２ 通信チップ、１４ メモリ、１５ プログラム記憶部、１６ 入力部、１７ 表示部、２１ 読み書き可能領域、２２ 読み出し専用領域、２３ 管理領域、３１ アプリケーション部、３２ 通信制御部、４０，４１，４２ タブ、４３ スライダ、４４ ボタン、５０ アイコン、１００ 家モデル。

Claims (10)

1. 情報記憶媒体との間で近距離無線通信が可能な情報処理装置であって、
   第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、
   前記情報処理装置で実行される第１のアプリケーションプログラムにより、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段とを備え、
   前記データ処理手段は、前記第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、前記第２の情報記憶媒体から読み出されたデータに基づき前記ゲームの進行に影響を与えない第２処理を実行する、情報処理装置。
2. 前記データ処理手段は、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータに含まれる識別情報に基づいて前記第１処理あるいは前記第２処理のいずれかを実行する、請求項１に記載の情報処理装置。
3. 前記第２処理は、少なくとも前記第１処理の一部の処理を制限する処理を含む、請求項１または請求項２に記載の情報処理装置。
4. 前記第１処理は、前記ゲームの進行指示に従って選択可能に設けられたオブジェクトを表示し、
   前記第２処理は、前記ゲームの進行指示とは無関係に選択不可能に設けられたオブジェクトを表示する、請求項１〜３のいずれかに記載の情報処理装置。
5. 前記データ処理手段は、前記情報処理装置で実行される第２のアプリケーションプログラムにより、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータに基づき共通の第３処理を実行する、請求項１に記載の情報処理装置。
6. 前記第２の情報記憶媒体は、複数の種別が設けられ、
   前記データ処理手段は、前記第２の情報記憶媒体に対するデータの読出により読み出されたデータに基づき前記種別に応じた前記第２処理を実行する、請求項１〜５のいずれかに記載の情報処理装置。
7. 情報記憶媒体との間で近距離無線通信が可能な情報処理装置の制御方法であって、
   第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行うステップと、
   前記情報処理装置で実行される第１のアプリケーションプログラムにより、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するステップとを備え、
   前記データを処理するステップは、
   前記第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行するステップと、
   前記第２の情報記憶媒体から読み出されたデータに基づき前記ゲームの進行に影響を与えない第２処理を実行するステップとを含む、情報処理装置の制御方法。
8. 情報記憶媒体との間で近距離無線通信が可能な情報処理装置のコンピュータで実行される情報処理プログラムであって、
   前記情報処理プログラムは、前記コンピュータを、
   第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、
   前記情報処理装置で実行される第１のアプリケーションプログラムにより、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段として機能させ、
   前記データ処理手段は、前記第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、前記第２の情報記憶媒体から読み出されたデータに基づき前記ゲームの進行に影響を与えない第２処理を実行する、情報処理プログラム。
9. 第１および第２の情報記憶媒体と、
   前記第１および第２の情報記憶媒体との間で近距離無線通信が可能な情報処理装置とを備え、
   前記情報処理装置は、
   第１および第２の情報記憶媒体と近距離無線通信を行うことによって、当該第１および第２の情報記憶媒体に対するデータの読出および／または書込を行う読出／書込手段と、
   前記情報処理装置で実行される第１のアプリケーションプログラムにより、前記第１および第２の情報記憶媒体に対するデータの読出により読み出されたデータを処理するデータ処理手段とを含み、
   前記データ処理手段は、前記第１の情報記憶媒体から読み出されたデータに基づきゲームの進行に影響を与える第１処理を実行し、前記第２の情報記憶媒体から読み出されたデータに基づき前記ゲームの進行に影響を与えない第２処理を実行する、情報処理システム。
10. 前記第１および第２の情報記憶媒体の形態は異なる、請求項９記載の情報処理システム。

Images