(57)【特許請求の範囲】
【請求項１】
情報記憶媒体との間で近距離無線通信が可能なコンピュータで実行される情報処理プログラムであって、
前記情報処理プログラムは、前記コンピュータを、
情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、
前記読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、
前記情報記憶媒体と近距離無線通信を行うことによって、前記第２のデータを前記情報記憶媒体に書き込む書込手段と、
前記読込手段において読み込んだ前記第２のデータを用いて前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを実行する第２の処理手段として機能させる、情報処理プログラム。
【請求項２】
前記第１処理手段は、前記第１のアプリケーションプログラムの実行により前記第１のデータに関連する環境データを前記第２のデータとして生成する、請求項１に記載の情報処理プログラム。
【請求項３】
前記環境データは、前記第２のアプリケーションプログラムの実行により表示される内容の設計データである、請求項２に記載の情報処理プログラム。
【請求項４】
前記環境データは、前記第２のアプリケーションプログラムの実行により表示される仮想空間内の設計データである、請求項３に記載の情報処理プログラム。
【請求項５】
前記環境データは、前記第１のアプリケーションプログラムの実行により仮想空間に配置されるキャラクタに関連して表示されるデータである、請求項２に記載の情報処理プログラム。
【請求項６】
前記環境データは、前記仮想空間の構成を示すデータである、請求項５に記載の情報処理プログラム。
【請求項７】
前記第１処理手段は、前記第１のアプリケーションプログラムの実行によりユーザの操作に応じて前記第２のデータを生成する、請求項１に記載の情報処理プログラム。
【請求項８】
前記第１処理手段は、前記第１のアプリケーションプログラムの実行により前記ユーザからの選択を受け付け、受け付けた選択に応じて前記第２データを生成する、請求項７に記載の情報処理プログラム。
【請求項９】
前記第１処理手段は、前記第１のアプリケーションプログラムの実行により前記ユーザから表示される内容に関する複数のパーツの選択を受け付け、選択されたパーツに応じて前記第２のデータを生成する、請求項８に記載の情報処理プログラム。
【請求項１０】
前記第１処理手段は、前記第１のアプリケーションプログラムの実行により前記第１のデータを用いて生成されるデータの一部を前記第２のデータとして生成する、請求項１〜９のいずれか１項に記載の情報処理プログラム。
【請求項１１】
前記情報記憶媒体は、ＲＦＩＤである、請求項１〜１０のいずれか１項に記載の情報処理プログラム。
【請求項１２】
前記情報記憶媒体は、ＲＦタグである、請求項１〜１０のいずれか１項に記載の情報処理プログラム。
【請求項１３】
前記近距離無線通信は、ＮＦＣによる無線通信である、請求項１〜１２のいずれか１項に記載の情報処理プログラム。
【請求項１４】
前記第１のアプリケーションプログラムおよび第２のアプリケーションプログラムは、それぞれ異なるゲームプログラムである、請求項１〜１３のいずれか１項に記載の情報処理プログラム。
【請求項１５】
情報記憶媒体との間で近距離無線通信が可能な情報処理装置であって、
情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、
前記読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、
前記情報記憶媒体と近距離無線通信を行うことによって、前記第２のデータを前記情報記憶媒体に書き込む書込手段と、
前記読込手段において読み込んだ前記第２のデータを用いて前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを実行する第２の処理手段とを備える、情報処理装置。
【請求項１６】
情報記憶媒体と、
前記情報記憶媒体との間で近距離無線通信が可能な情報処理装置とを備え、
前記情報処理装置は、
前記情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、
前記読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、
前記情報記憶媒体と近距離無線通信を行うことによって、前記第２のデータを前記情報記憶媒体に書き込む書込手段と、
前記読込手段において読み込んだ前記第２のデータを用いて前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを実行する第２の処理手段とを含む、情報処理システム。
【請求項１７】
情報記憶媒体との間で近距離無線通信が可能な情報処理装置の制御方法であって、
前記情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込むステップと、
読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行するステップと、
前記情報記憶媒体と近距離無線通信を行うことによって、前記第２のデータを前記情報記憶媒体に書き込むステップと、
読み込んだ前記第２のデータを用いて前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを実行するステップとを備える、情報処理装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンピュータで実行される情報処理に関し、情報記憶媒体との間で近距離無線通信が可能なコンピュータで実行される情報処理プログラム、情報処理装置、情報処理システムおよび情報処理装置の制御方法に関する。
【背景技術】
【０００２】
従来、例えばＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）等の近距離無線通信によって装置間で通信を行う技術がある（例えば、特許文献１参照）。近距離無線通信では、情報処理装置に対して記憶媒体（いわゆるタグ）が接近したことに応じて、情報処理装置と記憶媒体との間で通信が開始される（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−１６３５２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来、近距離無線通信によって情報処理装置と通信を行う記憶媒体の種別は特定されており、同じアプリケーションプログラムの処理として異なる種別の記憶媒体を利用した処理は実行されていなかった。
【０００５】
本開示の目的は、記憶媒体のデータを異なるアプリケーションプログラム間で利用することが可能な情報処理プログラム、情報処理装置、情報処理システムおよび情報処理装置の制御方法を提供することである。
【課題を解決するための手段】
【０００６】
本開示のある局面に従う情報処理プログラムは、情報記憶媒体との間で近距離無線通信が可能なコンピュータで実行される情報処理プログラムであって、情報処理プログラムは、コンピュータを、情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、情報記憶媒体と近距離無線通信を行うことによって、第２のデータを情報記憶媒体に書き込む書込手段と、読込手段において読み込んだ第２のデータを用いて第１のアプリケーションプログラムとは異なる第２アプリケーションプログラムを実行する第２の処理手段として機能させる。
【０００７】
好ましくは、第１処理手段は、第１のアプリケーションプログラムの実行により第１のデータに関連する環境データを第２のデータとして生成する。
【０００８】
好ましくは、環境データは、第２アプリケーションプログラムの実行により表示される内容の設計データである。
【０００９】
好ましくは、環境データは、第２アプリケーションプログラムの実行により表示される仮想空間内の設計データである。
【００１０】
好ましくは、環境データは、第１のアプリケーションプログラムの実行により仮想空間に配置されるキャラクタに関連して表示されるデータである。
【００１１】
好ましくは、環境データは、仮想空間の構成を示すデータである。
好ましくは、第１処理手段は、第１のアプリケーションプログラムの実行によりユーザの操作に応じて第２のデータを生成する。
【００１２】
好ましくは、第１処理手段は、第１のアプリケーションプログラムの実行によりユーザからの選択を受け付け、受け付けた選択に応じて第２データを生成する。
【００１３】
好ましくは、第１処理手段は、第１のアプリケーションプログラムの実行によりユーザから表示される内容に関する複数のパーツの選択を受け付け、選択されたパーツに応じて第２のデータを生成する。
【００１４】
好ましくは、第１処理手段は、第１のアプリケーションプログラムの実行により第１のデータを用いて生成されるデータの一部を第２のデータとして生成する。
【００１５】
好ましくは、情報記憶媒体は、ＲＦＩＤである。
好ましくは、情報記憶媒体は、ＲＦタグである。
【００１６】
好ましくは、近距離無線通信は、ＮＦＣによる無線通信である。
好ましくは、第１のアプリケーションプログラム及び第２のアプリケーションプログラムは、それぞれ異なるゲームプログラムである。
【００１７】
本開示のある局面に従う情報処理装置は、情報記憶媒体との間で近距離無線通信が可能な情報処理装置であって、情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、情報記憶媒体と近距離無線通信を行うことによって、第２のデータを情報記憶媒体に書き込む書込手段と、読込手段において読み込んだ第２のデータを用いて第１のアプリケーションプログラムとは異なる第２アプリケーションプログラムを実行する第２の処理手段とを備える。
【００１８】
本開示のある局面に従う情報処理装システムは、情報記憶媒体と、情報記憶媒体との間で近距離無線通信が可能な情報処理装置とを備える。情報処理装置は、情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、情報記憶媒体と近距離無線通信を行うことによって、第２のデータを情報記憶媒体に書き込む書込手段と、読込手段において読み込んだ第２のデータを用いて第１のアプリケーションプログラムとは異なる第２アプリケーションプログラムを実行する第２の処理手段とを含む。
【００１９】
本開示のある局面に従う情報処理装置の制御方法は、情報記憶媒体との間で近距離無線通信が可能な情報処理装置の制御方法であって、情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込むステップと、読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行するステップと、情報記憶媒体と近距離無線通信を行うことによって、第２のデータを情報記憶媒体に書き込むステップと、読み込んだ第２のデータを用いて第１のアプリケーションプログラムとは異なる第２アプリケーションプログラムを実行するステップとを備える。
【発明の効果】
【００２０】
上記によれば、記憶媒体のデータを異なるアプリケーションプログラム間で利用することが可能である。
【図面の簡単な説明】
【００２１】
【図１】本実施形態１に基づく情報処理システムの一例の構成を示す図である。
【図２】実施形態１に基づくタグ２の外観の一例を示す図である。
【図３】タグに記憶されるデータの一例を示す図である。
【図４】実施形態１に基づくタグ２からデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【図５】実施形態１に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）を説明するフローチャートである。
【図６】実施形態１に基づくタグ２に対してデータを書き込む場合における情報処理システムの処理の流れの一例を示す図である。
【図７】実施形態１に基づく書込指令を受けた場合における通信制御部３２の処理（書込指令処理）の流れの一例を示すフローチャートである。
【図８】第１のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。
【図９】第１イベント処理を説明するフロー図である。
【図１０】一例として家外観設計画面を説明する図である。
【図１１】家の内装を設計することが可能な画面を説明する図である。
【図１２】タグ２に記憶されるデータの別の一例について説明する図である。
【図１３】実施形態１に基づくタグ２の利用形態の一例を説明する図である。
【図１４】第２のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。
【図１５】実施形態１に基づく第２イベント処理を説明するフロー図である。
【図１６】実施形態１に基づく一例として家外観を表示した場合を説明する図である。
【図１７】実施形態２に基づくタグ２Ｐの外観の一例を示す図である。
【図１８】実施形態２に基づくタグ２Ｐからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【図１９】実施形態２に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。
【図２０】実施形態２に基づく第２アプリ処理を説明するフロー図である。
【図２１】実施形態２に基づく第２イベント処理を説明するフロー図である。
【図２２】実施形態２に基づく一例としてユーザが操作するキャラクタオブジェクトを表示した場合を説明する図である。
【図２３】実施形態３に基づくタグ２Ｑの外観の一例を示す図である。
【図２４】実施形態３に基づくタグ２Ｑからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【図２５】実施形態３に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。
【図２６】実施形態３に基づく第２アプリ処理を説明するフロー図である。
【図２７】実施形態３に基づく第２イベント処理を説明するフロー図である。
【図２８】実施形態３に基づく選択画面を説明する図である。
【図２９】タグ２Ｑに記憶されるデータの一例について説明する図である。
【図３０】実施形態３に基づくタグ２Ｑの別の利用形態の一例を説明する図である。
【図３１】実施形態４に基づく第２アプリ処理を説明するフロー図である。
【図３２】実施形態４に基づく第２イベント処理を説明するフロー図である。
【図３３】実施形態４に基づくポイント利用判定処理のサブルーチンについて説明するフロー図である。
【図３４】タグ２Ｐに記憶されるデータの一例について説明する図である。
【図３５】実施形態４に基づくポイント利用選択画面を説明する図である。
【図３６】実施形態４に基づく一例としてベンチオブジェクトを表示した場合を説明する図である。
【発明を実施するための形態】
【００２２】
この実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。
【００２３】
（実施形態１）
＜情報処理システムの構成＞
図１は、本実施形態１に基づく情報処理システムの一例の構成を示す図である。
【００２４】
図１に示すように、情報処理システム１は、記憶媒体（タグ）２と、情報処理装置３とを含む。情報処理装置３は、タグ２との間で近距離無線通信が可能な任意の情報処理装置である。
【００２５】
本実施形態１においては、近距離無線通信の一例として、情報処理装置３とタグ２との間でＮＦＣ規格に基づく通信が行われる場合を例として説明する。ここで、近距離無線通信とは、一例として一方の装置からの電波によって（例えば電磁誘導によって）他方の装置に起電力を発生させる通信方式を指す。他方の装置は、発生した起電力によって動作することが可能である（他方の装置は、電源を有していてもよいし有していなくてもよい）。
近距離無線通信においては、情報処理装置３とタグ２とが接近した場合（典型的には両者の距離が十数センチ以下となった場合）に通信可能となる。また、近距離無線通信では、２つの通信装置の通信が確立している間（通信装置に他のタグが接近している間）は電波が送出され続ける。なお、一例として電波によって通信する方式について説明したが特にこれに限られず光でも良いし、他の媒体を用いた通信でも良くその方式については何ら限定しない。
【００２６】
情報処理装置３は、近距離無線通信が可能な任意の情報処理装置である。本実施形態１においては、情報処理装置３は、例えば携帯型ゲーム装置、携帯電話、あるいはスマートフォン等といった、携帯型（可搬型とも言う）の装置であってもよいし、パーソナルコンピュータや家庭用ゲーム機等といった据置型の装置であってもよいし、業務用のアーケードゲーム装置のような大型の装置であってもよい。例えば、情報処理装置３は、ＮＦＣリーダライタの機能を有する携帯機器である。
【００２７】
タグ２は、情報処理装置３との間で近距離無線通信が可能な任意の装置である。本実施形態１においては、タグ２は、ＮＦＣタグの機能を有する記憶媒体である。すなわち、タグは、近距離無線通信を行う回路（ＩＣチップ）と、データを記憶する記憶手段（メモリ等）とを備える。すなわち、記憶手段に対して読み書き可能な回路を含むＲＦＩＤ（Radio Frequency IDentification）である。なお、タグ２は、データを記憶する機能のみを有する装置（ＲＦタグ）であってもよく、例えばＮＦＣのカードエミュレーション機能を有する情報処理装置（携帯機器）であってもよい。
【００２８】
以下、情報処理装置３の構成について説明する。図１に示すように、情報処理装置３は通信部１１を備える。通信部１１は、近距離無線通信に用いられるアンテナである。また、情報処理装置３は通信チップ１２を備える。通信チップ１２は、後述するＣＰＵ１３からの指示に従い、通信部１１から送出すべき信号（電波）を生成する。生成された信号が通信部１１から送出される。通信チップ１２は、例えばＮＦＣチップである。
【００２９】
図１に示すように、情報処理装置３は、ＣＰＵ１３およびメモリ１４を備える。ＣＰＵ１３は、情報処理装置３で実行される各種の情報処理を実行するための情報処理部である。ＣＰＵ１３は、メモリ１４を用いて上記各種の情報処理を実行する。
【００３０】
情報処理装置３はプログラム記憶部１５を備える。プログラム記憶部１５は、情報処理装置３において実行される各種プログラム（後述する通信プログラムおよびアプリケーションプログラムを含む）を記憶する。プログラム記憶部１５は、ＣＰＵ１３がアクセス可能な任意の記憶装置（記憶媒体）である。プログラム記憶部１５は、例えばハードディスクやメモリ等の、情報処理装置３に内蔵される記憶部であってもよいし、例えば光ディスクやカートリッジ等の、情報処理装置３に着脱可能な記憶媒体であってもよいし、これらの記憶部および記憶媒体の両方であってもよい。
【００３１】
本実施形態１においては、情報処理装置３では、少なくともアプリケーションプログラムおよび通信プログラムという２種類のプログラムがプログラム記憶部１５に記憶される。アプリケーションプログラムは、タグ２との間でデータ通信を行う任意のアプリケーションを実行するためのプログラムである。アプリケーションプログラムは、例えば、タグ２からゲームデータを読み出して当該ゲームデータを用いてゲーム処理を行うゲームプログラムであってもよい。通信プログラムは、タグ２との間で近距離無線通信を行うためのプログラムである。例えば、通信プログラムは、通信チップ１２を動作させるためのファームウェアであり、ライブラリとして情報処理装置３に予め用意されていてもよい。通信プログラムは、アプリケーションからの指令を受けて通信のための動作を通信チップ１２に行わせる。なお、情報処理装置３において複数のアプリケーションプログラムが実行可能である場合、通信プログラムは、各アプリケーションで共通に使用される。つまり、通信プログラム（後述する通信制御部３２）は、複数のアプリケーションから通信に関する指令を受け付けることが可能である。
【００３２】
また、情報処理装置３は、ボタンやタッチパネル等、ユーザによる指示を受け付ける入力部１６を備える。また、情報処理装置３は、上記情報処理によって生成される画像を表示する表示部１７を備えている。
【００３３】
情報処理装置３は、複数の装置によって構成されてもよい。例えば、情報処理装置３は、ＣＰＵ１３およびメモリ１４を備える装置に対して、上記通信部１１および通信チップ１２を備える装置が着脱可能に接続される構成であってもよい。また、情報処理装置３は、ＣＰＵ１３を有する本体装置と、入力部１６および／または表示部１７を有する装置とが別体である構成であってもよい。例えば、他の実施形態において、情報処理装置３は、本体装置と、入力部１６および表示部１７を有する端末装置とによって構成されてもよいし、本体装置と、入力部１６を有する操作装置とによって構成されてもよい。また、情報処理装置３は、表示部１７を備えず、テレビを表示装置として用いる構成であってもよい。
【００３４】
また、他の実施形態においては、情報処理装置３において実行される情報処理の少なくとも一部が、ネットワーク（広域ネットワークおよび／またはローカルネットワーク）によって通信可能な複数の装置によって分散して実行されてもよい。
【００３５】
＜タグ＞
図２は、実施形態１に基づくタグ２の外観の一例を示す図である。
【００３６】
図２に示すように、本実施形態１におけるタグ２は、キャラクタの絵が描かれた（キャラクタを平面的に表す）外観を有するカード型のタグである。
【００３７】
カード型のタグとして一例としてタイプＴＹ１が関連付けられているものとする。
タグ２が表すキャラクタ（犬、Ａ子）は、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）に登場するキャラクタである。ユーザは、このタグ２を用いることによって、上記特定のアプリケーションにおいて上記キャラクタを登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２に記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間に上記のキャラクタを登場させる。なお、タグ２は、アプリケーションに登場する任意のオブジェクトを表すものであり、キャラクタに限らず、ゲームアプリケーションにおけるアイテムを表すものであってもよい。
【００３８】
上記のように、タグ２は、特定のアプリケーションプログラムにおいて用いられる。また、タグ２は、特定のアプリケーションプログラムにおいて利用可能なデータを記憶することができる。以下では、このような特定のアプリケーションプログラムを「特定アプリプログラム」と呼ぶ。
【００３９】
タグ２は、特定アプリプログラムにおいて利用可能である一方、他のアプリケーションプログラムにおいても利用を可能にしても良い。タグ２は、特定アプリプログラムにおいて利用可能なデータを記憶する一方、後述するが特定アプリプログラム以外の他のアプリケーションプログラムにおいても利用可能なデータを記憶させることも可能である。
【００４０】
なお、当該タグ２は、複数のキャラクタにそれぞれ対応して複数種類設けることも可能である。また、一般的なキャラクタと特別なキャラクタとを分類してタグ２の種類を分けることも可能である。タグ２の種類を分けることにより実行される処理も変更可能なようにしても良い。
【００４１】
以下、タグ２に記憶されるデータの一例について説明する。
図３は、タグに記憶されるデータの一例を示す図である。
【００４２】
図３に示すように、タグ２は、読み書き可能領域２１と、読み出し専用領域２２と、管理領域２３とを有する。
【００４３】
また、図３に示すように、読み書き可能領域２１には、特定アプリプログラムの実行により保存されるセーブデータが記憶される。セーブデータとしては、例えば、タグ２が表すキャラクタに関連する各種データ、特定アプリプログラムのゲームの進行状態を示すデータ、および／または、特定アプリプログラムのゲームのプレイヤに関するデータ等が記憶される。
【００４４】
なお、読み書き可能領域２１には、複数のセーブデータを格納することが可能である。具体的には、複数の特定アプリプログラムにそれぞれ対応するセーブデータを格納することが可能である。したがって、セーブデータと特定アプリプログラムとを関連付けるためのアプリケーションを識別するアプリＩＤがセーブデータとともに登録されている。
【００４５】
なお、本例においては、アプリＩＤがセーブデータとともに登録されている場合について説明するが、セーブデータを管理するために以下のキャラクタＩＤを用いるようにしてもよい。
【００４６】
なお、セーブデータに限られず、初期登録データを記憶するようにしてもよい。初期登録データは、情報処理装置３においてタグ２の利用が開始される際にユーザによって登録されるデータである。なお、初期登録データは、典型的には、タグ２が最初に利用されるタイミングでタグ２に記憶されるが、任意のタイミングでタグ２に記憶されてもよい。つまり、ユーザによるタグ２に対するデータの登録は、任意のタイミングで行われてもよい。
【００４７】
読み出し専用領域２２は、データの読み出しのみが可能な記憶領域である。読み出し専用領域２２は、タグ２の製造時においてデータが記憶され、その後（タグ２の出荷後）のデータの書き込みが禁止される記憶領域である。つまり、情報処理装置３（情報処理装置３において実行されるアプリケーション）は、読み出し専用領域２２に対するデータの書き込みを行うことは不可能である。一方、情報処理装置３（情報処理装置３において実行されるアプリケーション）は、読み書き可能領域２１に対するデータの読み出しおよび書き込みを行うことができる。なお、タグ２の出荷時においては読み書き可能領域２１にはデータが予め記憶されていてもよいし、記憶されていなくてもよい。いずれの場合であっても、タグ２と情報処理装置３との通信が行われると、情報処理装置３によって読み書き可能領域２１にデータが書き込まれて記憶される。
【００４８】
なお、図３に示すように、本実施形態１においては、各データが記憶される記憶領域（読み書き可能領域、読み出し専用領域、および管理データ領域）は予め定められているものとするが、他の実施形態においては定められていなくてもよい。
【００４９】
読み出し専用領域２２には、少なくとも次のデータ（情報）が記憶される。
・固有ＩＤ（を示すデータ２２１）
・タイプＩＤ（を示すデータ２２２）
・キャラクタＩＤ（を示すデータ２２３）
・シリーズＩＤ（を示すデータ２２４）
固有ＩＤは、タグに固有の識別情報である。ここで、本実施形態１におけるタグ２のようなＮＦＣタグには、ＵＩＤ（Ｕｎｉｑｕｅ ＩＤ）という、タグに固有の識別情報が記憶される。上記固有ＩＤは、このＵＩＤとは異なる情報である。固有ＩＤは、タグを用いたサービスの提供者がタグを管理しやすいように、ＵＩＤとは別に付されたＩＤである。
【００５０】
キャラクタＩＤは、カード型のタグ２の平面的に表されたキャラクタに固有の識別情報である。キャラクタＩＤは、タグ２のキャラクタの種類を一意に特定することが可能な識別情報である。例えば、１つのキャラクタにつき、それぞれ外観が異なる（例えば、ポーズや服装が異なる）複数種類のタグがある場合には、各タグには異なる値のフィギュアＩＤが設定される。この場合、フィギュアＩＤは、キャラクタに固有のＩＤと、ポーズ・服装などの違いを示すＩＤとを含んでもよい。
【００５１】
シリーズＩＤは、タグ２が表すオブジェクト（キャラクタ）が属するグループに固有の識別情報である。例えば、タグ２が表すキャラクタが複数種類のアプリケーション（例えば、一連のシリーズのゲームアプリケーション）に登場する場合、これら複数種類のアプリケーションが１つのグループに設定され、このグループを示すグループＩＤが設定されてもよい。
【００５２】
なお、情報処理装置３において実行可能なアプリケーションプログラムは、自身において利用する（利用可能な）タグのキャラクタＩＤの情報を含んでいる。アプリケーションプログラムに含まれるキャラクタＩＤの値と、タグに記憶されるキャラクタＩＤの値とが一致する場合、本例においては一例として特定アプリプログラムであると判断する。そして、後述するが当該特定アプリプログラムは、キャラクタＩＤに対応するキャラクタに関して当該タグに記憶されるセーブデータを利用したイベント処理を実行する。
【００５３】
タイプＩＤは、タグ２の種類を示す識別情報である。本実施形態１においては、情報処理装置３においては、タグ２のようなカード型のタグの他、フィギュア型のタグや、特殊なカード型のタグも利用可能であるとする。タイプＩＤは、タグの種類として、カード型のタグであるかフィギュア型のタグであるか、特殊なカード型のタグであるかを示す識別情報である。なお、他の実施形態においては、タイプＩＤによって識別可能なタグの種類は任意である。例えば、タグ２を提供する業者毎に異なるタイプＩＤが付されてもよい。本実施形態１においては、タグ２に記憶されているタイプＩＤと、アプリケーションプログラムに含まれるタイプＩＤとが一致する場合に当該タグ２にアクセス可能であると判定する。
【００５４】
次に、管理データについて説明する。管理データは、タグの管理のために用いられるデータであり、管理データは、基本的にはアプリケーションにおいては用いられないデータである。
【００５５】
図３に示すように、タグ２は、管理データとして、バージョン情報のデータを管理領域２３に記憶する。バージョン情報は、タグ２のデータフォーマット（記憶形式）に関するバージョンを示す。ここで、本実施形態１においては、タグ２におけるデータの記憶形式はバージョン毎に異なり、同じバージョンであればデータの記憶形式は同じであるとする。具体的には、本実施形態１においては、タグ２においてどのアドレスにどのデータが記憶されるかは、バージョン毎に定められている（なお、バージョン情報のデータが記憶されるアドレスは、バージョンが異なっても同じである）。したがって、情報処理装置３は、バージョン情報を参照することによって、各データが記憶されているアドレスを特定することができる。例えば、バージョン情報において各データのデータサイズ（各データの記憶領域のサイズ）を規定しておくことによって、バージョン情報からアドレスを特定することができる。
【００５６】
また、タグ２は、管理データとして、ハッシュ値を記憶する（図３参照）。ハッシュ値は、読み書き可能領域２１および読み出し専用領域２２内のデータに対応するハッシュ値である。ハッシュ値は、対応するデータに対して所定のアルゴリズム（ハッシュ関数）を適用することによって得られる。なお、読み出し専用領域２２内のデータの内容は変化しないが、読み書き可能領域２１内のデータの内容は変化するので、ハッシュ値は変化する。変化したハッシュ値のデータは管理領域２３に記憶される。
【００５７】
なお、本実施形態１においては、図３に示すデータのうち、情報処理装置３（本実施形態１においては、後述する通信制御部３２）によって復号可能な方式で暗号化されている。したがって、上記方式での復号機能を持たない装置によってタグ２から上記他のデータが読み出されても、当該装置はデータの内容を解読することはできない。これによって、タグ２内のデータのセキュリティを向上することができる。なお、他の実施形態においては、管理データも上記方式で暗号化されていてもよいし、３種類のデータのうち少なくとも１つは暗号化されていなくてもよい。
【００５８】
＜情報処理システムにおける処理動作＞
次に、実施形態１に基づく情報処理システム１の処理動作（読み出し）について説明する。
【００５９】
図４は、実施形態１に基づくタグ２からデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【００６０】
本実施形態１においては、情報処理装置３内における動作を、機能的にアプリケーション部３１と通信制御部３２とに分けて説明する。本実施形態１において、アプリケーション部３１は、上述のアプリケーションプログラムを実行するＣＰＵ１３である。通信制御部３２は、上述の通信プログラムを実行するＣＰＵ１３と、通信チップ１２および通信部１１とによって実現される。なお、他の実施形態においては、情報処理装置３における情報処理は、アプリケーションプログラムと通信プログラムという２種類のプログラムによって実現される必要は無く、単一のプログラムによって実現されてもよい。なお、図４においては、情報処理装置３において特定アプリプログラムが実行される場合、すなわち、アプリケーション部３１が特定アプリプログラムを実行するＣＰＵ１３によって実現される場合を示している。
【００６１】
図４に示されるように、アプリケーション部３１は、通信制御部３２に対してタグ２からのデータの読出指令を送る（処理ｓｑ１）。本実施形態１において、この読出指令にはタイプＩＤ、キャラクタＩＤおよびシリーズＩＤが含まれる。特定アプリプログラムは、自身がセーブデータを利用可能なタグのタイプＩＤ、キャラクタＩＤおよびシリーズＩＤの情報を含んでいる。したがって、アプリケーション部３１は、読出指令とともに、特定アプリプログラムに含まれるタイプＩＤ、キャラクタＩＤおよびシリーズＩＤを通信制御部３２へ送る。なお、キャラクタＩＤは、１種類に限られず複数種類のキャラクタＩＤを送信するようにしても良い。
【００６２】
なお、アプリケーション部３１は、特定アプリプログラムに含まれる各タイプＩＤを通信制御部３２に送る。ただし、タグの種類を特定できる場合には、アプリケーション部３１は、特定アプリプログラムに含まれる１以上のタイプＩＤのうち、当該タグのタイプＩＤのみを通信制御部３２に送ってもよい。同様に、キャラクタの種類を特定できる場合には、アプリケーション部３１は、特定アプリプログラムに含まれる１以上のキャラクタＩＤのうち、１つのキャラクタＩＤのみを通信制御部３２に送っても良い。例えば、プレイヤが操作しているキャラクタに対応するキャラクタを表すタグを利用するゲーム状況においてタグのデータを読み出す場合には、情報処理装置３に接続されるタグ２は、当該キャラクタのタグであると特定することができる。したがって、この場合、アプリケーション部３１は、当該キャラクタを表すタグのキャラクタＩＤのみを通信制御部３２に送ってもよい。
【００６３】
なお、他の実施形態においては、アプリケーション部３１は、読出指令（書込指令等の他の指令でも同様）を送るタイミングとは異なるタイミングでタイプＩＤ、キャラクタＩＤおよびシリーズＩＤを通信制御部３２に送るようにしてもよい。例えば、他の実施形態においては、後述するアクセス許可判定処理において通信制御部３２がタイプＩＤをアプリケーション部３１に対して要求し、この要求に応じてアプリケーション部３１がタイプＩＤを通信制御部３２へ送るようにしてもよい。同様に、特定アプリ判定処理において通信制御部３２がキャラクタＩＤをアプリケーション部３１に対して要求し、この要求に応じてアプリケーション部３１がキャラクタＩＤを通信制御部３２へ送るようにしても良い。シリーズＩＤについても同様である。
【００６４】
読出指令を受け付けると、通信制御部３２は、一連の処理（読出指令処理）の実行を開始する。
【００６５】
具体的には、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（処理ｓｑ２）。そして、通信制御部３２は接続処理したタグ２からデータの読出処理を実行する（処理ｓｑ３）。そして、通信制御部３２は、読み出したデータに基づいてアクセス許可判定処理を実行する（処理ｓｑ４）。ここでは許可と判定された場合が示されている。次に、通信制御部３２は、特定アプリ判定処理を実行する（処理ｓｑ５）。ここでは、特定アプリと判定された場合が示されている。そして、通信制御部３２は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（処理ｓｑ６）。
【００６６】
図５は、実施形態１に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）を説明するフローチャートである。
【００６７】
図５を参照して、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（ステップＳ１）。接続処理の具体的な内容は任意である。例えば、通信制御部３２は、通信部１１の周囲に存在するタグ２を検知する処理（例えばポーリング処理）と、検知されたタグ２との間で通信を確立するための処理（例えば、データ通信に必要な情報をタグ２から取得する処理）とを実行する。なお、図示していないが、読出指令処理（後述する書込指令処理においても同様）の途中においてタグ２が情報処理装置３から離れて近距離無線通信が行えなくなった場合、通信制御部３２は読出指令処理を終了し、アプリケーション部３１とのデータの受け渡しを中止する。
【００６８】
次に、通信制御部３２はデータの読出処理を実行する（ステップＳ２）。具体的には、通信制御部３２は、まず、管理データをタグ２から読み出す。そして、読み出した管理データに含まれるバージョン情報に基づいて、タグ２内の各データのアドレスを特定する。なお、バージョン情報に基づいてアドレスを特定する具体的な方法は任意である。例えば、バージョン情報自体に、各データとアドレスとの対応関係を示す情報がバージョン情報に含まれていてもよい。また例えば、上記対応関係とバージョン情報とを関連付けたテーブルを通信制御部３２が予め記憶しておき、タグ２から読み出したバージョン情報と当該テーブルとを用いて通信制御部３２が対応関係を特定してもよい。
【００６９】
各データのアドレスが特定されると、通信制御部３２は、タイプＩＤをタグ２から読み出す。通信制御部３２は、読み出したデータを復号してメモリ１４に記憶しておく。
【００７０】
次に、通信制御部３２は、アクセス許可判定処理を実行する（ステップＳ３）。アクセス許可判定処理は、情報処理装置３上で実行されるアプリケーションプログラムによる、通信が確立したタグへのアクセスが許可されるか否かを判定する処理である。換言すれば、アクセス許可判定処理は、通信が確立したタグが、情報処理装置３上で実行されるアプリケーションプログラムによるアクセスが許可されたタグ（以下、「許可タグ」と呼ぶ）か否かを判定する処理である。なお、「許可タグ」は、例えば、情報処理装置３（および／または情報処理装置３で実行可能なアプリケーションプログラム）を提供する事業者が許可したタグである。つまり、本実施形態１においては、情報処理装置３上のアプリケーションは、上記事業者によって許可されたタグにのみアクセス可能であり、上記事業者によって許可されないＮＦＣタグに対してデータの読み出し／書き込みを行うことはできない。
【００７１】
本実施形態１においては、アクセス許可判定処理における判定は、タグ２に記憶される所定の情報に基づいて実行する。例えば、通信制御部３２は、タグ２に記憶されている所定の情報を（情報処理装置３の側でも）予め記憶しておき、タグから読み出した情報と、予め記憶しておいた情報とが一致するか否かによって上記判定を行ってもよい。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致する場合には許可タグであると判断する。なお、この判定に用いる所定の情報としては、本例においては、ＮＦＣタグに記憶されている、ＮＦＣの規格において定められるタグのタイプ（ＴＹ１，ＴＹ２等）を示す情報を利用する。
【００７２】
なお、これに限られず、情報処理装置３（および／または情報処理装置３で実行可能なアプリケーションプログラム）を提供する事業者が許可するタグであることを示す情報（専用コード）等を利用するようにしても良い。
【００７３】
あるいは、上述のバージョン情報を利用するようにしても良い。例えば、アクセス許可判定処理における判定は、読み出し専用領域２２に記憶されるデータが、バージョン情報から特定される設定に適合しているか否かによって行われてもよい。また例えば、アクセス許可判定処理における判定は、通信制御部３２によって読み出された所定のデータ（例えば、読み出し専用領域２２に記憶されるデータ）のサイズが所定の範囲内であるか否かによって上記判定を行ってもよい。
【００７４】
ステップＳ３において、通信制御部３２は、タグ２が許可タグでないと判断した場合（ステップＳ３においてＮＯ）には、その旨をアプリケーション部３１に通知する（ステップＳ４）。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致しない場合には許可タグでないと判断する。そして、当該通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、タグ２が許可されたものではないためにデータの読み出しを行うことができない旨をユーザに対して通知する。ステップＳ４の処理の終了後、通信制御部３２は、読出指令処理を終了する（エンド）。
【００７５】
一方、ステップＳ３において、通信制御部３２は、タグ２が許可タグであると判断した場合（ステップＳ３においてＹＥＳ）には、特定アプリ判定処理を実行する（ステップＳ５）。具体的には、タグ２から読み出したタイプＩＤと、アプリケーション部３１から送られたタイプＩＤとが一致する場合には、特定アプリ判定処理を実行する。特定アプリ判定処理は、通信制御部３２に対する指令（ここでは読出指令）を行ったアプリケーションプログラムが特定アプリプログラムであるか否かを判定する処理である。
【００７６】
特定アプリ判定処理における判定は、上述のキャラクタＩＤを用いて行われる。すなわち、通信制御部３２は、アプリケーション部３１から指令と共に取得したキャラクタＩＤ（キャラクタＩＤが複数である場合にはそのうちのいずれか）と、ステップＳ２でタグ２から読み出したキャラクタＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは特定アプリプログラムであると判定する。特定アプリプログラムと判定した場合（ステップＳ５においてＹＥＳ）、通信制御部３２は、通信制御部３２は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（ステップＳ６）。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、キャラクタＩＤとセーブデータの受け取りを許可する。なお、ステップＳ６の処理の終了後、通信制御部３２は、図５に示す読出指令処理を終了する（エンド）。
【００７７】
なお、通信制御部３２からキャラクタＩＤとセーブデータを受け取ったアプリケーション部３１は、受け取ったデータを用いた情報処理を実行する。なお、本例においては、通信制御部３２から一例としてキャラクタＩＤとセーブデータとをアプリケーション部３１に出力する場合について説明するが特にこれに限られず、いずれか一方出会っても良いし、あるいは、他のデータでも良くこれらの組み合わせであっても良い。情報処理で利用可能なデータであればどのようなデータであっても良い。
【００７８】
この情報処理の内容は任意である。例えば、アプリケーション部３１は、セーブデータを用いたゲーム処理を実行する。なお、本実施形態１においては、特定アプリプログラムは、セーブデータを用いることとするが、セーブデータとともにキャラクタＩＤおよびタイプＩＤ等を用いた処理であってもよい。
【００７９】
一方、両者が異なれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは非特定アプリプログラム（特定アプリプログラムではないアプリケーションプログラム）と判定する。特定アプリプログラムでないと判定した場合（ステップＳ５においてＮＯ）、関連アプリ判定処理を実行する（ステップＳ７）。具体的には、タグ２から読み出したシリーズＩＤと、アプリケーション部３１から送られたシリーズＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは関連アプリプログラムであると判定する。関連アプリプログラムと判定した場合（ステップＳ７においてＹＥＳ）、通信制御部は、アプリケーション部３１に対してキャラクタＩＤとセーブデータとを出力する（ステップＳ６）。
【００８０】
通信制御部３２は、タグ２から読み出したシリーズＩＤと、アプリケーション部３１から送られたシリーズＩＤとが一致しない場合（ステップＳ７においてＮＯ）、上記指令を行ったアプリケーションプログラムは、関連アプリプログラム（関連アプリとも称する）でないと判定する。そして、通信制御部３２は、アプリケーション部３１に対して特定アプリでないことを通知する（ステップＳ８）。つまり、指令を行ったアプリケーションプログラムが関連アプリを除く非特定アプリプログラムである場合には、通信制御部３２は、セーブデータの受け取りを制限（禁止）する。なお、ステップＳ７の処理の終了後、通信制御部３２は、図５に示す読出指令処理を終了する（エンド）。
【００８１】
なお、本例においては、特定アプリで無い場合には、通信制御部３２からのセーブデータを送信しない場合について説明しているが、例えばキャラクタＩＤのみを送信するようにしても良い。アプリケーション部３１は、受け取ったキャラクタＩＤのデータを用いた情報処理を実行する。この情報処理の内容は任意であるが、例えば、キャラクタＩＤを用いて、キャラクタＩＤが表すキャラクタを表示する処理を実行するようにしても良い。
【００８２】
なお、本実施形態１においては、ステップＳ６のデータ出力処理において、通信制御部３２は、タグ２に記憶されているセーブデータの全てをアプリケーション部３１へ出力するものとした。ただし、他の実施形態においては、アプリケーション部３１は、取得すべきデータを読出指令において指定し、ステップＳ６の処理において、通信制御部３２は、当該読出指令において指定されたデータをアプリケーション部３１へ出力するようにしてもよい。なお、このとき、読出指令において指定されたデータがセーブデータであって、ステップＳ４の処理において、読出指令を行ったアプリケーションプログラムが非特定アプリプログラムであると判定された場合には、ステップＳ７において、通信制御部３２は、データの出力（読み出し）が制限されている旨をアプリケーション部３１へ通知するようにしてもよい。
【００８３】
次に、実施形態１に基づく情報処理システム１の処理動作（書き込み）について説明する。
【００８４】
図６は、実施形態１に基づくタグ２に対してデータを書き込む場合における情報処理システムの処理の流れの一例を示す図である。
【００８５】
図６に示されるように、アプリケーション部３１は、通信制御部３２に対してタグ２に対するデータの書込指令を送る（ｓｑ１０）。本実施形態１において、この書込指令には、上述した読出指令と同様、アプリケーション部３１のアプリケーションプログラムに含まれるタイプＩＤが含まれる。特定アプリプログラムは、自身がセーブデータを保存可能なタグのタイプＩＤの情報を含んでいる。したがって、アプリケーション部３１は、書込指令とともに、特定アプリプログラムに含まれるタイプＩＤを通信制御部３２へ送る。なお、タイプＩＤは、１種類に限られず複数種類のタイプＩＤを送信するようにしても良い。
【００８６】
書込指令を受け付けると、通信制御部３２は、一連の処理（書込指令処理）の実行を開始する。
【００８７】
具体的には、通信制御部３２は、タグとの通信を開始するための接続処理を実行する（処理ｓｑ１１）。そして、通信制御部３２は、接続処理したタグ２からデータの読出を処理する（処理ｓｑ１２）。そして、通信制御部３２は、読み出したデータに基づいてアクセス許可判定処理を実行する（処理ｓｑ１３）。ここでは許可と判定された場合が示されている。次に、通信制御部３２は、アプリケーション部３１に許可通知を出力する（処理ｓｑ１４）。許可通知を受け取ったアプリケーション部３１は、タグ２に書き込むべきデータ（ここでは、セーブデータ）を生成し、通信制御部３２へ送る（処理ｓｑ１５）。通信制御部３２は、アプリケーション部３１からセーブデータを取得する（処理ｓｑ１６）。通信制御部３２は、取得したセーブデータに関してタグ２に対する書込処理を実行する（処理ｓｑ１７）。
【００８８】
図７は、実施形態１に基づく書込指令を受けた場合における通信制御部３２の処理（書込指令処理）の流れの一例を示すフローチャートである。
【００８９】
図７を参照して、通信制御部３２は、タグ２との通信を開始するための接続処理を実行する（ステップＳ１０）。接続処理の具体的な内容は任意である。例えば、通信制御部３２は、通信部１１の周囲に存在するタグ２を検知する処理（例えばポーリング処理）と、検知されたタグ２との間で通信を確立するための処理（例えば、データ通信に必要な情報をタグ２から取得する処理）とを実行する。なお、図示していないが、書込指令処理（後述する書込指令処理においても同様）の途中においてタグ２が情報処理装置３から離れて近距離無線通信が行えなくなった場合、通信制御部３２は書込指令処理を終了し、アプリケーション部３１とのデータの受け渡しを中止する。
【００９０】
次に、通信制御部３２は、データの読出処理を実行する（ステップＳ１１）。具体的には、通信制御部３２は、まず、管理データをタグ２から読み出す。そして、読み出した管理データに含まれるバージョン情報に基づいて、タグ２内の各データのアドレスを特定する。なお、バージョン情報に基づいてアドレスを特定する具体的な方法は任意である。例えば、バージョン情報自体に、各データとアドレスとの対応関係を示す情報がバージョン情報に含まれていてもよい。また例えば、上記対応関係とバージョン情報とを関連付けたテーブルを通信制御部３２が予め記憶しておき、タグ２から読み出したバージョン情報と当該テーブルとを用いて通信制御部３２が対応関係を特定してもよい。
【００９１】
各データのアドレスが特定されると、通信制御部３２は、タイプＩＤをタグ２から読み出す。通信制御部３２は、読み出したデータを復号してメモリ１４に記憶しておく。
【００９２】
次に、通信制御部３２は、アクセス許可判定処理を実行する（ステップＳ１２）。アクセス許可判定処理は、情報処理装置３上で実行されるアプリケーションプログラムによる、通信が確立したタグへのアクセスが許可されるか否かを判定する処理である。
【００９３】
ステップＳ１２において、通信制御部３２は、タグ２が許可タグでないと判断した場合（書込指令を行ったタグ２はアクセスが許可されていない場合）（ステップＳ１２においてＮＯ）には、不許可のタグであることを通知する（ステップＳ１６）。通信制御部３２は、データの書き込みを行うことができない旨をアプリケーション部３１に通知する。この通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、接続されたタグ２は、実行中のアプリケーションによってデータの書き込みを行うことができないタグである旨をユーザに通知する処理を実行する。ステップＳ１６の後、通信制御部３２は書込指令処理を終了する（エンド）。
【００９４】
一方、通信制御部３２は、書込指令処理において、ステップＳ１２の判定結果が肯定であった場合（書込指令を行ったタグ２はアクセスが許可されている場合）（ステップＳ１２においてＹＥＳ）には、アプリケーション部３１に対して許可通知を出力する（ステップＳ１３）。
【００９５】
次に、通信制御部３２は、タグ２に書き込むべきデータをアプリケーション部３１から取得する（ステップＳ１４）。
【００９６】
次に、通信制御部３２は、タグ２に対する書込処理を実行する（ステップＳ１５）。上述のように、本実施形態１においては、タグ２に対するデータの書き込みは、タグ２の読み書き可能領域２１に対して行われる。すなわち、通信制御部３２は、ステップＳ１４でアプリケーション部３１から取得したセーブデータを、タグ２に書き込む。その際、通信制御部３２は、セーブデータとともに当該セーブデータに対応するアプリＩＤをともにタグ２に書き込む。なお、タグ２に書き込むことにより内容は変更されることになる。
【００９７】
したがって、ステップＳ１５において、通信制御部３２は、変更後のセーブデータについてハッシュ値を算出する。そして、算出したハッシュ値を新たなハッシュ値としてタグ２に書き込む。ステップＳ１５の処理の後、通信制御部３２は書込指令処理を終了する（エンド）。
【００９８】
なお、他の実施形態においては、タグ２に対するデータの書き込みおよび読み出しは、所定の単位毎に行われてもよい。例えば、タグ２の記憶領域が複数のブロックに分割されている場合、タグ２に対するデータの書き込みおよび読み出しは、このブロック毎に行われてもよい。
【００９９】
なお、本例においては、書込処理指令において、タグ２のタイプＩＤが一致するか否かすなわち、アクセスが許可されたタグであるか否かに基づいてタグ２に対する書込処理を許可する方式について説明したが、特にこれに限られない。例えば、読出指令処理と同様にキャラクタＩＤが一致するか否かすなわち、特定アプリプログラムか否かに基づいてタグ２に対する書込処理を許可するようにしても良い。さらに他の条件を付加するようにするようにしても良い。
【０１００】
次に、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理（第１アプリ処理）について説明する。
【０１０１】
図８は、第１のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。なお、図８に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開示される。
【０１０２】
図８では、第１のアプリケーションプログラムによる処理の一例として、ゲーム処理が実行される場合を説明する。また、タグ２に記憶されるデータ（キャラクタＩＤ）を用いて、タグ２が表すキャラクタをゲーム空間に登場させる等のイベント処理を例として説明する。
【０１０３】
ステップＳ４１において、アプリケーション部３１は、第１のアプリケーションプログラムに従ってゲーム処理を実行する。このゲーム処理の内容は任意であり、例えば、ユーザの入力に応じて仮想空間（ゲーム空間）におけるキャラクタの動作を制御したり、プログラムにおいて規定されているアルゴリズムに従って他のキャラクタの動作を制御したりする処理が実行される。
【０１０４】
ステップＳ４２において、アプリケーション部３１は、タグ２との通信を行うか否かを判定する。すなわち、アプリケーション部３１は、タグ２との通信を行うための所定のゲーム条件が満たされたか否かを判定する。この所定のゲーム条件は、ゲーム状況が、タグ２が表すキャラクタが登場することができる状況になったことであり、例えば、プレイヤキャラクタが所定のステージに進んだことや、プレイヤキャラクタが所定のアイテムを取得したこと等である。
【０１０５】
なお、ステップＳ４２の処理は、ステップＳ４１におけるゲーム処理が実行される間の適宜のタイミングで実行される。
【０１０６】
したがって、ステップＳ４２の判定処理の結果が否定となる場合、ステップＳ４１の処理が再度実行され、ステップＳ４２の判定処理の結果が肯定となるまでステップＳ４１およびＳ４２の処理が繰り返し実行される。一方、ステップＳ４２の判定処理の結果が肯定となる場合、後述するステップＳ４３の処理が実行される。
【０１０７】
ステップＳ４３において、アプリケーション部３１は、読出指令を出力し、タグ２からデータを読み出す。すなわち、上述したように、アプリケーション部３１はまず、通信制御部３２へ読出指令を出力する。これに応じて、図５で説明したフローに従って通信制御部３２はタグ２との通信を行い、タグ２から読み出したデータをアプリケーション部３１へ渡す。これによって、アプリケーション部３１はタグ２からのデータを取得する。なお、上述のように、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、タグ２からキャラクタＩＤと特定アプリプログラムに対応するセーブデータとが取得される。なお、タグ２に保存されているセーブデータが無い場合には、キャラクタＩＤのみが取得される。
【０１０８】
なお、図８では示していないが、接続されたタグ２が許可タグでない場合（ステップＳ３の判定結果が否定となる場合）には、タグ２が許可タグでない旨の通知が通信制御部３２からアプリケーション部３１へ送られる。この場合、アプリケーション部３１は、例えば、データの読み出しを行うことができない旨をユーザに対して通知し、ステップＳ４１のゲーム処理を再開する。
【０１０９】
ステップＳ４６において、アプリケーション部３１は、ステップＳ４３で取得されたキャラクタＩＤのキャラクタに基づく第１イベント処理を実行する。ここで、アプリケーションプログラムには、タグ２によってゲームに登場する各キャラクタを生成するためのデータが含まれている。また、アプリケーションプログラムには、当該各キャラクタのそれぞれに関連付けられたキャラクタＩＤの情報が予め登録されているものとする。
【０１１０】
具体的には、アプリケーション部３１は、キャラクタＩＤが示すキャラクタを仮想空間に登場させたイベント処理を実行する。ここで、タグ２に記憶されるキャラクタＩＤが表すキャラクタをアプリケーション部３１がわかっている場合（当該キャラクタＩＤがアプリケーションにおいて登録されている場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができる。すなわち、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いて仮想空間内におけるキャラクタを生成する。
【０１１１】
第１イベント処理の詳細については後述する。
次に、第１イベント処理に基づくデータを取得する（ステップＳ４８）。
【０１１２】
次に、アプリケーション部３１は、書込指令を出力し、タグ２にデータを書き込む。すなわち、アプリケーション部３１は、通信制御部３２へ書込指令を出力する（ステップＳ４９）。これに応じて、図７で説明したフローに従って通信制御部３２はタグ２との通信を行い、アプリケーション部３１から通信制御部３２に書き込むデータを出力する。
【０１１３】
そして、通信制御部３２からタグ２に対してデータを書き込む。
そして、次に、ゲームが終了したかどうかを判断する（ステップＳ５０）。
【０１１４】
ステップＳ５０において、ゲームが終了した場合（ステップＳ５０においてＹＥＳ）には、処理を終了する（エンド）。
【０１１５】
一方、ステップＳ５０において、ゲームが終了していない場合（ステップＳ５０においてＮＯ）には、ステップＳ４１に戻り、ゲーム処理を継続する。
【０１１６】
図９は、第１イベント処理を説明するフロー図である。
図９に示されるように、まず、セーブデータがあるかどうかを判断する（ステップＳ５１）。具体的には、通信制御部３２から送られたキャラクタＩＤとセーブデータとを取得した場合には、セーブデータは有りと判断する。この点で、キャラクタＩＤのみ取得した場合には、セーブデータは無しと判断する。
【０１１７】
また、複数のアプリケーションプログラムにそれぞれ対応する複数のセーブデータがある場合には、特定アプリプログラムに対応するセーブデータを取得する。その際、実行中の特定アプリプログラムに対応するセーブデータを取得するために少なくとも１つのアプリＩＤが利用される。特定アプリプログラムのアプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが有るか否か判断される。特定アプリプログラムのアプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無い場合には、セーブデータは無しと判断する。なお、後述するが特定アプリプログラムのアプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。
【０１１８】
ステップＳ５１において、セーブデータが有ると判断した場合（ステップＳ５１においてＹＥＳ）には、ステップＳ５２において、特定アプリプログラムに対応するセーブデータを読み込む。
【０１１９】
一方、ステップＳ５１において、セーブデータが無いと判断した場合（ステップＳ５１においてＮＯ）には、セーブデータは無し、すなわち初期状態と判断する。
【０１２０】
次に、家外観設計画面を表示する（ステップＳ５３）。
セーブデータがある場合には、セーブデータの内容に基づいて家外観設計画面を表示する。セーブデータが無い場合には、初期状態として規定された内容に基づいて家外観設計画面を表示する。
【０１２１】
図１０は、一例として家外観設計画面を説明する図である。
図１０に示されるように、本例における家外観設計画面は、ユーザ（操作者）がキャラクタＩＤに対応するキャラクタの家外観の設計を設定することが可能な画面である。当該画面を用いてユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家外観を設計することが可能である。
【０１２２】
本例においては、画面上部において、仮想空間内の家モデル１００が表示されるとともに、画面下部において、当該家モデルを設計するために必要なパーツ（設計部品）を選択する選択画面が表示されている。
【０１２３】
本例においては、家モデル１００の外観として３つのパートに分けられた場合が示されている。具体的には、家の屋根、家の側面、ドアに分けられている。
【０１２４】
家の屋根、家の側面、ドアの設計にそれぞれ対応して３つのタブ４０〜４２が設けられており、タブ４０〜４２を切り替えることによりそれぞれのパートの家外観を設定することが可能に設けられている。
【０１２５】
タブ４０の選択により、家の屋根を選択可能な画面に切り替わる。
タブ４１の選択により、家の側面を選択可能な画面に切り替わる。
【０１２６】
タブ４２の選択により、家のドアを選択可能な画面に切り替わる。
本例においては、一例としてタブ４２が選択された状態であり、家のドアのパーツを選択可能な画面が示されている。本例においては、それぞれドアの形状等が異なる「メルヘンなドア」、「アラブなドア」、「しかくいアラブなドア」、「しかくいまどつきのドア」、「しかくいおかしなドア」、「しかくいおもいドア」を選択可能な画面が示されている。
【０１２７】
上下に操作可能なスライダ４３が設けられており、スライダ４３を操作することにより、複数種類の家のドアのパーツを上下にスクロール表示することが可能である。
【０１２８】
そして、画面に表示された家のドアのパーツの文字をタッチすることにより入力部１６（タッチパネル）を介して当該パーツを指定することが可能である。
【０１２９】
画面上部においては、一例として指定により「しかくいまどつきのドア」を有する家モデル１００が表示されている。
【０１３０】
そして、当該画面には、「けってい」ボタン４４が設けられており、「けってい」ボタン４４を選択することにより家外観設計画面の設計が終了して次の処理が実行される。
【０１３１】
例えば、家の内装を設計可能な設定画面が表示され、当該設定が可能であるものとする。
【０１３２】
再び、図９を参照して、次に、ステップＳ５４において、設定したかどうかを判断する。具体的には、上記家外観設計画面において、家モデル１００の外観に関する各種の設計をしたかどうかを判断する。すなわち、「けってい」ボタン４４を選択したかどうかを判断する。なお、初期状態として家外観として各種のパーツが予め選択された状態としても良い。
【０１３３】
設定が無いすなわち、設定が完了しない場合（ステップＳ５４においてＮＯ）には、ステップＳ５３に戻り、上記処理を繰り返す。
【０１３４】
次に、設定したと判断した場合（ステップＳ５４においてＹＥＳ）には、次に、家側面ＩＤ、屋根ＩＤ、ドアＩＤを設定する。上記家外観設計画面で設計されたパーツ（設計データ）には、当該パーツを識別するＩＤが予め割り当てられている。具体的には、家側面ＩＤ、屋根ＩＤ、ドアＩＤは、上記家モデルを表示するためのパーツ（設計データ）を識別するＩＤであり、当該仮想空間に配置する家モデルの外観表示に関連する環境データである。言い換えれば当該環境データは、仮想空間の状況（環境）を示すデータである。具体的には、環境データは、仮想空間に配置されるオブジェクト表示（構成）を示すデータである。環境データは、キャラクタに関連する周辺の環境データであり、キャラクタデータ（強さのパラメータ等）とは異なる。
【０１３５】
そして、次に内装設計画面を表示する（ステップＳ５６）。
図１１は、家の内装を設計することが可能な画面を説明する図である。
【０１３６】
図１１（Ａ）は、内装の変更、削除等の編集が可能な画面である。当該画面を用いてユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家の内装を設計することが可能である。具体的には、家具の配置を変更したり、家具を削除等したりすることが可能である。
【０１３７】
図１１（Ｂ）、（Ｃ）は、キャラクタＩＤに対応するキャラクタに関する家具等を追加する場合を説明する図である。
【０１３８】
図１１（Ｂ）の画面上部には、上記で設計した家内部にキャラクタＩＤに対応するキャラクタオブジェクトが表示されている場合が示されている。また、画面下部には、家内部に配置する家具を選択する画面が表示されている。当該画面を用いて、ユーザ（操作者）は、ユーザの好み（趣向）に応じた任意の家の内装を設計することが可能である。
【０１３９】
本例においては、図１１（Ｂ）において家具の一例として「滑り台」のアイコン５０を選択（購入）して、図１１（Ｃ）において家の内部に「滑り台」のオブジェクトを配置した状態が示されている。
【０１４０】
再び図９を参照して、次に、設定したかどうかを判断する（ステップＳ５７）。具体的には、上記家内装設計画面において、家モデル１００の内装に関する各種の設計をしたかどうかを判断する。すなわち、図示しない「けってい」ボタンを選択したかどうかを判断する。なお、初期状態として家内装として各種のパーツが予め選択された状態としても良い。
【０１４１】
ステップＳ５７において、設定していないと判断した場合（ステップＳ５７においてＮＯ）には、ステップＳ５６に戻り、上記処理を繰り返す。
【０１４２】
一方、ステップＳ５７において、設定したと判断した場合（ステップＳ５７においてＹＥＳ）には、次に、内装ＩＤ等を設定する（ステップＳ５８）。
【０１４３】
そして、処理を終了する（リターン）。
図１２は、タグ２に記憶されるデータの別の一例について説明する図である。
【０１４４】
図１２に示すように、図３のタグ２に記憶されるデータと比較して、セーブデータの内容が具体的に示されている。
【０１４５】
具体的には、家の外観および内装のオブジェクトを規定する家側面ＩＤ（データ２１２）、屋根ＩＤ（データ２１３）、ドアＩＤ（データ２１４）、内装ＩＤ（データ２１５）、家具ＩＤ（データ２１６）等が格納されている。当該セーブデータを利用したアプリケーションプログラムを実行する際に当該セーブデータに基づく設定した家モデルを仮想空間内に表示させることが可能である。
【０１４６】
また、当該セーブデータに基づく第１イベント処理を再び実行することにより家モデルの再設計を実行することが可能である。当該家モデルの再設計によりタグ２に記憶されるデータを更新することが可能である。
【０１４７】
図１３は、実施形態１に基づくタグ２の利用形態の一例を説明する図である。
図１３に示されるように、本例においては、（１）アプリケーションプログラムＡ（アプリＡ）に従いタグ２のデータの読み込みを実行する。次に、（２）アプリケーションプログラムＡ（アプリＡ）に従いタグ２へのデータの書き込みを実行する。そして、本例においては、（３）アプリケーションプログラムＡ（アプリＡ）とは別のアプリケーションプログラムＢ（アプリＢ）に従いタグ２のデータの読み込みを実行する。本実施形態１においては、アプリＡに従いタグ２へのデータの書き込みを実行したデータに関して、アプリＢで当該データを利用する場合について説明する。
【０１４８】
次に、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理（第２アプリ処理）について説明する。
【０１４９】
図１４は、第２のアプリケーションプログラムによってＣＰＵ１３が実行する処理を説明するフロー図である。なお、図１４に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開示される。
【０１５０】
図１４では、第２のアプリケーションプログラムによる処理の一例として、ゲーム処理が実行される場合を説明する。また、タグ２に記憶されるデータ（キャラクタＩＤ）を用いて、タグ２が表すキャラクタ等をゲーム空間に登場させる等のイベント処理を例として説明する。
【０１５１】
ステップＳ６１〜Ｓ６３においては、図８のステップＳ４１〜Ｓ４３で説明したのと同様の処理が実行される。ステップＳ６３において、アプリケーション部３１は、読出指令を出力し、タグ２からデータを読み出す。すなわち、上述したように、アプリケーション部３１はまず、通信制御部３２へ読出指令を出力する。これに応じて、図５で説明したフローに従って通信制御部３２はタグ２との通信を行い、タグ２から読み出したデータをアプリケーション部３１へ渡す。これによって、アプリケーション部３１はタグ２からのデータを取得する。なお、上述のように、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、タグ２からキャラクタＩＤと特定アプリプログラムに対応するセーブデータとが取得される。なお、タグ２に保存されているセーブデータが無い場合には、キャラクタＩＤのみが取得される。
【０１５２】
ステップＳ６６において、アプリケーション部３１は、ステップＳ６３で取得されたキャラクタＩＤのキャラクタに基づく第２イベント処理を実行する。ここで、アプリケーションプログラムには、タグ２によってゲームに登場する各キャラクタを生成するためのデータが含まれている。また、アプリケーションプログラムには、当該各キャラクタのそれぞれに関連付けられたキャラクタＩＤの情報が予め登録されているものとする。
【０１５３】
ステップＳ６６における第２イベント処理の詳細については後述する。
具体的には、アプリケーション部３１は、キャラクタＩＤが示すキャラクタ等を仮想空間に登場させたイベント処理を実行する。ここで、タグ２に記憶されるキャラクタＩＤが表すキャラクタをアプリケーション部３１がわかっている場合（当該キャラクタＩＤがアプリケーションにおいて登録されている場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができる。すなわち、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いて仮想空間内におけるキャラクタを生成する。
【０１５４】
そして、次に、ゲームが終了したかどうかを判断する（ステップＳ６８）。
ステップＳ６８において、ゲームが終了した場合（ステップＳ６８においてＹＥＳ）には、処理を終了する（エンド）。
【０１５５】
一方、ステップＳ６８において、ゲームが終了していない場合（ステップＳ６８においてＮＯ）には、ステップＳ６１に戻り、ゲーム処理を継続する。
【０１５６】
図１５は、実施形態１に基づく第２イベント処理を説明するフロー図である。
図１５に示されるように、まず、関連セーブデータがあるかどうかを判断する（ステップＳ２１）。具体的には、アプリケーション部３１は、通信制御部３２から送られたキャラクタＩＤとセーブデータとを取得した場合に、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。
【０１５７】
アプリケーション部３１は、関連するアプリケーションプログラム（関連アプリプログラム）のアプリＩＤに対応するセーブデータがあるかどうかを判断する。関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。
【０１５８】
ステップＳ２１において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ２１においてＮＯ）には、関連セーブデータは無しと判断する。
【０１５９】
この場合には、ステップＳ２５に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステップＳ６５）。
【０１６０】
そして、処理を終了する（リターン）。なお、後述するが関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。
【０１６１】
ステップＳ２１において、関連セーブデータが有ると判断した場合（ステップＳ２１においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む。
【０１６２】
次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ２３）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。
【０１６３】
次に、取得した家外観データに基づいて家外観を表示する（ステップＳ２４）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。
【０１６４】
そして、ステップＳ２５に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステップＳ２５）。
【０１６５】
そして、処理を終了する（リターン）。
図１６は、実施形態１に基づく一例として家外観を表示した場合を説明する図である。
【０１６６】
図１６に示されるように、本例においては、関連セーブデータに含まれている家外観データに基づいて仮想空間内に家モデル１００を表示する。ここでは、すごろくゲームを実行するアプリケーションプログラムを実行した場合のゲーム画面が表示されている。当該ゲーム画面において、すごろくゲームの進行に用いられる複数のマスが配置されている場合が示されている。すごろくゲームは、ユーザの操作に従って出現するすごろくの目（数字）に応じてユーザが操作するキャラクタがマスを進むことによりゲームが進行する。一例として、「あと４マス」との表示に従いユーザが操作するキャラクタが４マス分、マスを進むことが可能であることが示されている。本例における第２イベント処理としては、関連セーブデータに基づいて当該ゲームの仮想空間内のオブジェクトとして上記家モデル１００を表示する。当該オブジェクトは、ユーザの操作や指示を受け付けることができないオブジェクト（操作受付不可のオブジェクト）であり、ゲームの進行に影響を与える要因とはならない。当該オブジェクトは仮想空間内の背景画像としてのみ用いられる。
【０１６７】
本実施形態１に基づく情報処理装置３は、第１のアプリケーションプログラム（アプリＡ）とは異なる第２のアプリケーションプログラム（アプリＢ）を実行する際に、アプリＡで処理したタグ２に記憶したデータを利用して処理する。当該処理により、記憶媒体（タグ）のデータを異なるアプリケーションプログラム間で利用することにより、データの汎用性を高めた処理が可能である。これによりタグ２を汎用的に利用することが可能となり、種々の利用形態を適用することが可能である。
【０１６８】
本実施形態１に基づく情報処理装置３は、第１のアプリケーションプログラム（アプリＡ）とは異なる第２のアプリケーションプログラム（アプリＢ）を実行する際に、上記第２イベント処理として、ゲームの進行に影響を与えないオブジェクトを表示する処理を実行する。例えば、ゲーム画面におけるオブジェクトとして家モデル１００を表示させる。すなわち、ゲームの進行に影響を与えるゲームパラメータ（例えばキャラクタの強さのパラメータ等）については変化させない処理を実行する。
【０１６９】
また、ゲームの進行に影響を与えないゲーム画面におけるオブジェクトとしてキャラクタＩＤが示すキャラクタオブジェクト１１０（操作受付不可のオブジェクト）を表示させる。
【０１７０】
なお、第２イベント処理は、タグ２に記憶された第１のアプリケーションプログラム（アプリＡ）により処理されたデータのみを利用したイベント処理であり、タグ２に記憶された第１のアプリケーションプログラム（アプリＡ）により処理されたデータを更新はしない。
（タグの外観に関する変形例）
上記実施形態１においては、タグ２は、キャラクタの絵が描かれた（キャラクタを平面的に表す）カード型のタグについて説明したが、キャラクタを立体的に表すフィギュア型のタグであってもよい。また、タグの形状はこれに限らず、任意の形状であってよい。これによれば、タグ２を用いてアプリケーションにおいて登場させることができるオブジェクトをユーザにわかりやすく認識させることができる。また、上記オブジェクトを表示部１７に表示する場合には、現実のオブジェクトがあたかも仮想空間に入り込んで登場したかのような感覚をユーザに体験させることができ、アプリケーションの興趣性を向上することができる。
【０１７１】
（実施形態２）
実施形態２においては、同じアプリケーションプログラムに対して種別が異なるタグにより処理が異なる場合について説明する。具体的には、タグの種別に応じて第２アプリ処理において処理が異なる場合について説明する。第１アプリ処理についてはタグの種別に依らず同様であるとする。
【０１７２】
図１７は、実施形態２に基づくタグ２Ｐの外観の一例を示す図である。
図１７に示すように、本実施形態におけるタグ２Ｐは、キャラクタを立体的に表わすフィギュア型のタグである。
【０１７３】
フィギュア型のタグとして一例としてタイプＴＹ２が関連付けられているものとする。
タグ２Ｐが表すキャラクタ（犬、Ａ子）は、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）に登場するキャラクタである。ユーザは、このタグ２Ｐを用いることによって、上記特定のアプリケーションにおいて上記キャラクタを登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２Ｐに記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間に上記のキャラクタを登場させる。
【０１７４】
図１８は、実施形態２に基づくタグ２Ｐからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【０１７５】
図１８に示されるように、図４の情報処理システムの流れと比較して異なる点は、処理ｓｑ６が処理ｓｑ６Ｐに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０１７６】
図１９は、実施形態２に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。
【０１７７】
図１９に示されるように、図５の読出指令を受けた場合における通信制御部３２の処理（読出指令処理）とを説明するフローチャートと比較して、ステップＳ６をステップＳ６Ｐに置換した点が異なる。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０１７８】
具体的には、ステップＳ６Ｐにおいて、通信制御部３２は、アプリケーション部３１に対してタイプＩＤとキャラクタＩＤとセーブデータとを出力する。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、タイプＩＤとキャラクタＩＤとセーブデータの受け取りを許可する。
【０１７９】
図２０は、実施形態２に基づく第２アプリ処理を説明するフロー図である。
図２０に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｐに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０１８０】
図２１は、実施形態２に基づく第２イベント処理を説明するフロー図である。
図２１に示されるように、まず、タグのタイプを確認する（ステップＳ７０）。具体的には、アプリケーション部３１は、通信制御部３２から送られたタイプＩＤを確認する。
【０１８１】
次に、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であるか否かを判断する（ステップＳ７１）。
【０１８２】
アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であると判断した場合（ステップＳ７１においてＹＥＳ）に、取得したセーブデータに関して、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する（ステップＳ７２）。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。
【０１８３】
関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。
【０１８４】
ステップＳ７２において、関連セーブデータが有ると判断した場合（ステップＳ７２においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む（ステップＳ７３）。
【０１８５】
次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ７４）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。
【０１８６】
次に、取得した家外観データに基づいて家外観を表示する（ステップＳ７５）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。具体的には、図１６に示されるように仮想空間内の家モデル１００が表示される。
【０１８７】
そして、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７６）。また、図１６に示されるように、仮想空間内にキャラクタオブジェクト１１０を表示する。当該キャラクタオブジェクト１１０は、ユーザが操作することのできない（ユーザの操作を制限する）選択不可能なキャラクタである。
【０１８８】
そして、処理を終了する（リターン）。
また、ステップＳ７２において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ７２においてＮＯ）には、関連セーブデータは無しと判断する。
【０１８９】
この場合には、ステップＳ７６に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステッ７６）。
【０１９０】
そして、処理を終了する（リターン）。なお、関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。
【０１９１】
一方、取得したタイプＩＤがタイプＴＹ１でないと判断した場合（ステップＳ７１においてＮＯ）には、取得したタイプＩＤがタイプＴＹ２であるか否かを判断する（ステップＳ７７）。
【０１９２】
ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。
【０１９３】
そして、処理を終了する（リターン）。
一方、ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２でないと判断した場合（ステップＳ７７においてＮＯ）には、処理を終了する（リターン）。
【０１９４】
図２２は、実施形態２に基づく一例としてユーザが操作するキャラクタオブジェクトを表示した場合を説明する図である。
【０１９５】
図２２に示されるように、本例においては、すごろくゲームを実行するアプリケーションプログラムを実行した場合のゲーム画面が表示されている。当該ゲーム画面において、すごろくゲームの進行に用いられる複数のマスが配置されている場合が示されている。すごろくゲームは、ユーザの操作に従って出現するすごろくの目（数字）に応じてユーザが操作するキャラクタがマスを進むことによりゲームが進行する。本例においては、ユーザが操作するキャラクタオブジェクト１１１としてゲーム画面に表示されている場合が示されている。
【０１９６】
なお、本例においては、ユーザが操作可能な複数のキャラクタオブジェクトがゲーム画面に表示されている。一例として４体のキャラクタオブジェクトがゲーム画面に表示されている。
【０１９７】
また、キャラクタオブジェクトに対応したポイントがゲーム画面に表示されている。
一例として、キャラクタオブジェクト１１１に対応して設けられたポイント表示領域４００が表示されている。他のキャラクタオブジェクトについても同様である。また、当該ポイント表示領域４００内には、ポイント値４０２として「１０」ポイント有る場合が示されている。他のキャラクタオブジェクトについても同様である。当該ポイント値は、すごろくゲームを実行することによりキャラクタオブジェクトに対応して加減算される。
【０１９８】
本実施形態２に基づく情報処理装置３は、第２のアプリケーションプログラム（アプリＢ）を実行する際に、タグのタイプに応じた処理を実行する。具体的には、タイプＴＹ１のタグについては、アプリＡで処理したタグ２に記憶したデータを利用して処理する。情報処理装置３は、ゲームの進行に影響を与えない処理を実行する。例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデル１００およびキャラクタＩＤが示すキャラクタオブジェクト１１０を表示させる。
【０１９９】
一方で、タイプＴＹ２のタグについては、アプリＡで処理したタグ２に記憶したデータを利用しない。タグ２に記憶されているキャラクタＩＤに基づく処理を実行する。情報処理装置３は、ゲームの進行に影響を与える処理を実行する。例えば、ゲーム画面における操作するキャラクタとして選択可能なキャラクタオブジェクト１１１を表示させる。当該キャラクタオブジェクト１１１を操作したゲームを実行することが可能である。
【０２００】
当該処理により、同じアプリケーションプログラムであっても記憶媒体（タグ）の種別に応じて異なるイベント処理を実行することが可能である。
【０２０１】
すなわち、異なる処理を実行することにより、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。
【０２０２】
（実施形態３）
実施形態３においては、同じアプリケーションプログラムに対して種別が異なるタグにより処理が異なるさらに別の場合について説明する。具体的には、タグの種別に応じて第２アプリ処理において処理が異なる場合について説明する。
【０２０３】
図２３は、実施形態３に基づくタグ２Ｑの外観の一例を示す図である。
図２３に示すように、本実施形態におけるタグ２Ｑは、カード型のタグである。
【０２０４】
カード型のタグとして、図２のカード型のタグとは異なる種別として一例としてタイプＴＹ３が関連付けられているものとする。
【０２０５】
また、当該タグ２Ｑは、タグ２の縦型のカードと比較して横型のカードであり外形的な形態が異なる。また、キャラクタの絵が描かれた外観を有しておらず、木が描かれた外観を有しており絵柄が異なる点でも形態が異なる。なお、カードの大小によっても外形的な形態を異なるようにしても良い。また、カードの材質により形態を異なるようにしても良い。例えば、タグの種別に従って、紙、プラスチック、樹脂等の材質により形態が異なるようにすることも可能である。
【０２０６】
タグ２Ｑは、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）でのみ利用される。本例においては、アプリＢでのみ利用される。ユーザは、このタグ２Ｑを用いることによって、上記特定のアプリケーションにおいてゲームに用いられるマップ（一例としてすごろくマップ）を登場させた所定のイベント処理を実行することができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２Ｑに記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間にマップを登場させる。当該マップを利用したゲームを実行することが可能である。
【０２０７】
図２４は、実施形態３に基づくタグ２Ｑからデータを読み出す場合における情報処理システムの処理の流れの一例を示す図である。
【０２０８】
図２４に示されるように、図４の情報処理システムの流れと比較して異なる点は、処理ｓｑ６が処理ｓｑ６Ｑに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０２０９】
図２５は、実施形態３に基づく読出指令を受けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。
【０２１０】
図２５に示されるように、図５の読出指令を受けた場合における通信制御部３２の処理（読出指令処理）とを説明するフローチャートと比較して、ステップＳ６をステップＳ６Ｑに置換した点が異なる。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０２１１】
具体的には、ステップＳ６Ｑにおいて、通信制御部３２は、アプリケーション部３１に対してタイプＩＤを出力する。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、タイプＩＤの受け取りを許可する。
【０２１２】
図２６は、実施形態３に基づく第２アプリ処理を説明するフロー図である。
図２６に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｑに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０２１３】
図２７は、実施形態３に基づく第２イベント処理を説明するフロー図である。
図２７に示されるように、まず、タグのタイプを確認する（ステップＳ７０）。具体的には、アプリケーション部３１は、通信制御部３２から送られたタイプＩＤを確認する。
【０２１４】
次に、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であるか否かを判断する（ステップＳ７１）。
【０２１５】
アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ１であると判断した場合（ステップＳ７１においてＹＥＳ）に、取得したセーブデータに関して、現在実行中のアプリケーションプログラムとは別の（関連する）アプリケーションプログラムのセーブデータが有るかどうかを判断する（ステップＳ７２）。この点で、キャラクタＩＤのみ取得した場合には、関連セーブデータは無と判断する。
【０２１６】
関連するアプリＩＤに関する情報は、予めアプリケーションプログラムに格納されているものとする。アプリケーション部３１は、実行中の特定アプリプログラムに関連するアプリＩＤ（関連アプリＩＤ）と一致するアプリＩＤと関連付けられたセーブデータが有るか否かを判断する。
【０２１７】
ステップＳ７２において、関連セーブデータが有ると判断した場合（ステップＳ７２においてＹＥＳ）には、関連アプリプログラムに対応するセーブデータを読み込む（ステップＳ７３）。
【０２１８】
次に、関連セーブデータに含まれている家外観データを取得する（ステップＳ７４）。
具体的には、関連セーブデータに含まれる一部のデータである家側面ＩＤ、屋根ＩＤ、ドアＩＤを取得する。なお、取得する一部のデータの種類は予め設定されているものとする。
【０２１９】
次に、取得した家外観データに基づいて家外観を表示する（ステップＳ７５）。なお、実行中の特定アプリプログラムは、関連セーブデータに含まれる家側面ＩＤ、屋根ＩＤ、ドアＩＤに基づいて家外観を表示させるための生成プログラムが含まれているものとする。具体的には、図１６に示されるように仮想空間内の家モデル１００が表示される。
【０２２０】
そして、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７６）。また、図１６に示されるように、仮想空間内にキャラクタオブジェクト１１０を表示する。当該キャラクタオブジェクト１１０は、ユーザが操作することのできない（ユーザの操作を制限する）選択不可能なキャラクタである。
【０２２１】
そして、処理を終了する（リターン）。
また、ステップＳ７２において、関連アプリプログラムの関連アプリＩＤと一致するアプリＩＤと関連付けられたセーブデータが無いと判断した場合（ステップＳ７２においてＮＯ）には、関連セーブデータは無しと判断する。
【０２２２】
この場合には、ステップＳ７６に進み、キャラクタＩＤが示すキャラクタオブジェクトを表示する処理を実行する（ステッ７６）。
【０２２３】
そして、処理を終了する（リターン）。なお、関連アプリプログラムの関連アプリＩＤは、一種類に限らず複数種類のアプリＩＤを用いることも可能である。
【０２２４】
一方、取得したタイプＩＤがタイプＴＹ１でないと判断した場合（ステップＳ７１においてＮＯ）には、取得したタイプＩＤがタイプＴＹ２であるか否かを判断する（ステップＳ７７）。
【０２２５】
ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。
【０２２６】
そして、処理を終了する（リターン）。
一方、ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２でないと判断した場合（ステップＳ７７においてＮＯ）には、取得したタイプＩＤがタイプＴＹ３であるか否かを判断する（ステップＳ８０）。
【０２２７】
ステップＳ８０において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ３であると判断した場合（ステップＳ８０においてＹＥＳ）には、選択画面を表示する（ステップＳ８１）。タイプＩＤがタイプＴＹ３である場合には、アプリケーション部３１は、上記第２イベント処理として、本例においては、ユーザの選択に従ってタグ２Ｑに格納されたマップデータに基づくすごろくマップを登場させる。あるいは、ユーザの選択に従ってタグ２Ｑに対してすごろくマップのマップデータを格納することが可能となる。
【０２２８】
一方、ステップＳ８０において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ３でないと判断した場合（ステップＳ８０においてＮＯ）には、処理を終了する（リターン）。利用可能でないタグであるため第２イベント処理を終了する。
【０２２９】
図２８は、実施形態３に基づく選択画面を説明する図である。
図２８に示されるように、ここでは、「データをセーブしますか？」と「データをロードしますか？」の表示されており、ユーザによる選択可能な「セーブ」ボタン、「ロード」ボタン、「キャンセル」ボタンが設けられている場合が示されている。
【０２３０】
再び図２７を参照して、次に、アプリケーション部３１は、選択画面においてセーブが選択されたかどうかを判断する（ステップＳ８２）。
【０２３１】
ステップＳ８２において、アプリケーション部３１は、セーブが選択されたと判断した場合（ステップＳ８２においてＹＥＳ）には、データを取得する（ステップＳ８３）。
【０２３２】
具体的には、ゲーム処理において利用しているマップデータを取得する。当該マップデータは、すごろくのマスに関するデータと、オブジェクト（操作受付不可オブジェクト）のデータとを含む。オブジェクト（操作受付不可オブジェクト）のデータは、図１６で説明した家モデル１００が表示されている場合には、家外観データを含む。また、オブジェクトのデータは、図１６で説明したキャラクタオブジェクト１１０が表示されている場合には、キャラクタＩＤを含む。
【０２３３】
そして、次に、ステップＳ８４において、アプリケーション部３１は、通信制御部３２へ取得したデータに関する書込指令を出力する。
【０２３４】
これに応じて、通信制御部３２はタグ２Ｑとの通信を行い（図７におけるステップＳ１０）、アプリケーション部３１から通信制御部３２に書き込むデータ（マップデータ）を出力する。そして、通信制御部３２からタグ２Ｑに対してデータを書き込む。
【０２３５】
そして、処理を終了する（リターン）。
当該書込指令により、タグ２Ｑにマップデータをセーブすることが可能である。そして、当該タグ２Ｑを利用してデータをロードすることにより、上記セーブしたマップデータに基づくマップを表示させることが可能となる。
【０２３６】
図２９は、タグ２Ｑに記憶されるデータの一例について説明する図である。
図２９に示すように、タグ２Ｑは、読み書き可能領域２１Ｑと、読み出し専用領域２２Ｑと、管理領域２３とを有する。具体的には、図３のタグ２に記憶されるデータと比較して、読み書き可能領域２１Ｑと、読み出し専用領域２２Ｑとが異なる。
【０２３７】
読み出し専用領域２２Ｑには、少なくとも次のデータ（情報）が記憶される。
・固有ＩＤ（を示すデータ２２１）
・タイプＩＤ（を示すデータ２２２）
上記したように、タグ２Ｑは、アプリＢでのみ利用され、仮想空間にすごろくマップを登場させる。したがって、本例においては、キャラクタＩＤ（を示すデータ２２３）やシリーズＩＤ（を示すデータ２２４）は記憶されていない場合が示されている。
【０２３８】
読み書き可能領域２１Ｑには、マップデータ（複数のセーブデータ）の内容が具体的に示されている。
【０２３９】
具体的には、すごろくマップに配置されるオブジェクトを規定するオブジェクトＩＤ（データ２４０）、すごろくマップの地形等に関するマップＩＤ（データ２４２）、キャラクタＩＤ（データ２４６）、家外観データ（家側面ＩＤ（データ２１２）、屋根ＩＤ（データ２１３）、ドアＩＤ（データ２１４）等が格納されている。
【０２４０】
再び、図２７を参照して、ステップＳ８２において、アプリケーション部３１は、セーブが選択されなかったと判断した場合（ステップＳ８２においてＮＯ）には、ロードが選択されたかどうかを判断する（ステップＳ８５）。
【０２４１】
ステップＳ８５において、アプリケーション部３１は、ロードが選択されたと判断した場合（ステップＳ８５においてＹＥＳ）には、セーブデータを読み込む（ステップＳ８６）。具体的には、セーブデータとしてタグ２Ｑに書き込んだマップデータを取得する。当該マップデータには、すごろくのマスのマップの地形等に関するデータ（マップＩＤ）と、オブジェクト（操作受付不可オブジェクト）のデータ（キャラクタＩＤ）等が含まれる。
【０２４２】
そして、次に、アプリケーション部３１は、取得したマップデータに基づくマップを表示する（ステップＳ８７）。
【０２４３】
一方、ステップＳ８５において、アプリケーション部３１は、ロードが選択されなかったと判断した場合（ステップＳ８５においてＮＯ）には、処理を終了する（リターン）。
具体的には、「キャンセル」ボタンが選択されたと判断してタグ２Ｑに関するイベント処理を終了する。
【０２４４】
本実施形態３に基づく情報処理装置３は、第２のアプリケーションプログラム（アプリＢ）を実行する際に、タグのタイプに応じた処理を実行する。具体的には、タイプＴＹ１のタグについては、アプリＡで処理したタグ２に記憶したデータを利用して処理する。情報処理装置３は、ゲームの進行に影響を与えない処理を実行する。例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデル１００およびキャラクタＩＤが示すキャラクタオブジェクト１１０を表示させる。
【０２４５】
また、タイプＴＹ２のタグ２Ｐについては、アプリＡで処理したタグ２Ｐに記憶したデータを利用しない。タグ２Ｐに記憶されているキャラクタＩＤに基づく処理を実行する。情報処理装置３は、ゲームの進行に影響を与える処理を実行する。例えば、ゲーム画面における操作するキャラクタとして選択可能なキャラクタオブジェクト１１１を表示させる。当該キャラクタオブジェクト１１１を操作したゲームを実行することが可能である。
【０２４６】
また、タイプＴＹ３のタグ２Ｑについては、タグ２Ｑに記憶されているマップデータに基づく処理を実行する。例えば、ゲーム画面におけるマップを表示させる。あるいは、タグ２Ｑにマップデータをセーブ（格納）する処理を実行する。
【０２４７】
当該処理により、同じアプリケーションプログラムであっても記憶媒体（タグ）の種別に応じて異なるイベント処理を実行することが可能である。
【０２４８】
すなわち、異なる処理を実行することにより、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。
【０２４９】
また、タイプＴＹ３のタグ２Ｑは、オブジェクト（操作受付不可オブジェクト）のデータを含むマップデータを格納する。したがって、ゲーム画面において当該オブジェクトが変更（更新）された場合には、更新されたオブジェクトを含むマップデータを格納することが可能である。
【０２５０】
例えば、タイプＴＹ１のタグ２がアプリＢで利用される毎に、例えば、ゲーム画面におけるオブジェクト（操作受付不可オブジェクト）として家モデルおよびキャラクタＩＤが示すキャラクタオブジェクトが表示される。そして、当該オブジェクト（操作受付不可オブジェクト）を含むマップデータをタイプＴＹ３のタグ２Ｑで格納し、次にゲーム処理する際に、当該タグ２Ｑを利用することにより、更新されたオブジェクト（操作受付不可オブジェクト）を含むマップデータに基づくマップでゲームを実行することが可能となる。
【０２５１】
当該処理により、タグに記憶するデータを用いてタグの興趣性を高めた処理が可能である。
【０２５２】
図３０は、実施形態３に基づくタグ２Ｑの別の利用形態の一例を説明する図である。
図３０に示されるように、本例においては、情報処理装置３ａにおいて（１）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑのデータの読み込みを実行する。具体的には、タグ２Ｑに記憶されているすごろくゲームのマップデータの読み込みを実行する。そして、マップデータに基づくマップを表示してゲームを実行することが可能である。
【０２５３】
次に、情報処理装置３ａにおいて（２）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑへのデータの書き込みを実行する。具体的には、すごろくゲームのマップデータ（オブジェクトのデータや家外観データ等）をタグ２Ｑに対して書き込みを実行する。
【０２５４】
そして、本例においては、情報処理装置３ａとは別の情報処理装置３ｂにおいて（３）アプリケーションプログラムＢ（アプリＢ）に従いタグ２Ｑのデータの読み込みを実行する。そして、マップデータに基づくマップを表示してゲームを実行することが可能である。
【０２５５】
本実施形態３においては、情報処理装置３ａにおいてアプリＢに従いタグ２Ｑへのデータの書き込みを実行したデータに関して、別の情報処理装置３ｂにおいてアプリＢで当該データを利用することが可能である。具体的には、オブジェクトのデータや家外観データは、マップ仮想空間に配置する家モデルの外観表示等に関連する環境データである。当該環境データをタグ２Ｑを利用して他のデバイスで利用することが可能である。
【０２５６】
（実施形態４）
実施形態４においては、タグと情報処理装置とが関連付けられることにより第２アプリ処理において処理が異なる場合について説明する。
【０２５７】
図３１は、実施形態４に基づく第２アプリ処理を説明するフロー図である。
図３１に示されるように、図１４のフロー図と比較して異なる点は、ステップＳ６６をステップＳ６６Ｒに置換した点である。その他の構成については同様であるのでその詳細な説明については繰り返さない。
【０２５８】
図３２は、実施形態４に基づく第２イベント処理を説明するフロー図である。
図３２に示されるように、図２７に示される第２イベント処理と比較して、ステップＳ９０，Ｓ９２を追加した点が異なる。その他のフローについては同様であるのでその詳細な説明については繰り返さない。
【０２５９】
ステップＳ７７において、アプリケーション部３１は、取得したタイプＩＤがタイプＴＹ２であると判断した場合（ステップＳ７７においてＹＥＳ）には、キャラクタＩＤに対応するキャラクタオブジェクトを表示する（ステップＳ７９）。タイプＩＤがタイプＴＹ２である場合には、アプリケーション部３１は、上記第２イベント処理として、ゲームの進行に影響を与える処理を実行する。本例においては、ユーザが操作することが可能なキャラクタを出現させる。
【０２６０】
次に、アプリケーション部３１は、ポイントの利用の選択の指示が有るか否かを判断する（ステップＳ９０）。具体的には、ユーザからの操作指示に従ってポイントの利用の選択指示が有るかどうかを判断する。例えば、アプリケーション部３１は、情報処理装置３の入力部１６による所定の操作指示（例えば所定ボタンの操作）の有無に基づいてポイントの利用の選択指示が有るかどうかを判断する。
【０２６１】
ステップＳ９０において、アプリケーション部３１は、ポイントの利用の選択の指示が有ると判断した場合（ステップＳ９０においてＹＥＳ）には、ポイントの利用の判定処理（ポイント利用判定処理）を実行する（ステップＳ９２）。ポイント利用判定処理は、キャラクタＩＤに対応するキャラクタオブジェクトに関して、当該キャラクタオブジェクトに対応付けられているポイント値を利用した処理が可能であるか否かを判定し、判定結果に基づいて所定の処理を実行する。
【０２６２】
一方、ステップＳ９０において、アプリケーション部３１は、ポイントの利用の選択の指示が無いと判断した場合（ステップＳ９０においてＮＯ）には、ステップＳ９２のポイント利用判定処理をスキップして処理を終了する（リターン）。
【０２６３】
図３３は、実施形態４に基づくポイント利用判定処理のサブルーチンについて説明するフロー図である。
【０２６４】
図３３に示されるように、アプリケーション部３１は、登録済フラグがオンしているかどうかを判断する（ステップＳ１００）。具体的には、アプリケーション部３１は、タイプＴＹ２のタグ２ＰのアプリＩＤ（本例においてはアプリＢ）に対応するセーブデータに登録済フラグがオンとして登録されているか否かを判断する。
【０２６５】
ステップＳ１００において、アプリケーション部３１は、登録済フラグがオンしていない（つまりオフ）と判断した場合（ステップＳ１００においてＮＯ）には、タグ２Ｐから取得したデータに含まれる固有ＩＤをメモリ１４に保存する（ステップＳ１０１）。
【０２６６】
タグ２Ｐの固有ＩＤとは、タグ２Ｐから読み出したデータに含まれるタグ２Ｐを識別する情報（識別情報）である。
【０２６７】
そして、次に、アプリケーション部３１は、通信制御部３２へ登録済フラグをオンする書込指令を出力する（ステップＳ１０２）。具体的には、アプリケーション部３１は、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤを保存（登録）することにより、タイプＴＹ２のタグ２ＰのアプリＩＤ（本例においてはアプリＢ）に対応するセーブデータとして登録済フラグをオンに設定する。
【０２６８】
アプリケーション部３１は、タグ２Ｐの固有ＩＤをメモリ１４に登録することにより、登録されたタグ２Ｐのデータに基づく所定のイベント処理を実行する。
【０２６９】
なお、ステップＳ１０１とステップＳ１０２との処理を入れ替えるようにすることも可能である。
【０２７０】
図３４は、タグ２Ｐに記憶されるデータの一例について説明する図である。
図３４に示すように、タグ２Ｐは、読み書き可能領域２１Ｐと、読み出し専用領域２２と、管理領域２３とを有する。具体的には、図３のタグ２に記憶されるデータと比較して、セーブデータの内容が具体的に示されている。
【０２７１】
読み書き可能領域２１Ｐには、アプリＩＤに対応するセーブデータが格納されている。
本例においては、一例としてアプリＢに対応するセーブデータが示されている。
【０２７２】
セーブデータとして、登録済フラグ（データ２５０）と、ポイントデータ（データ２５２）が格納されている。
【０２７３】
登録済フラグは、タグ２Ｐの固有ＩＤが情報処理装置３に登録されたことを示すデータである。登録済フラグがオンの場合には、登録済であることを示す。一方、登録済フラグがオフの場合には、未登録であることを示す。
【０２７４】
ポイントデータは、アプリＢのすごろくゲームを実行することにより加減算されるポイント値を指し示す。
【０２７５】
再び、図３３を参照して、ステップＳ１００において、アプリケーション部３１は、登録済フラグがオンであると判断した場合（ステップＳ１００においてＹＥＳ）には、ＩＤが一致するか否かを判断する（ステップＳ１０３）。具体的には、アプリケーション部３１は、登録済フラグがオンであると判断した場合には、タグ２Ｐから読み出したデータに含まれる固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致するか否かを判断する。
【０２７６】
ステップＳ１０３において、アプリケーション部３１は、ＩＤが一致すると判断した場合（ステップＳ１０３においてＹＥＳ）には、ポイント利用選択画面を表示する（ステップＳ１０４）。具体的には、アプリケーション部３１は、タグ２Ｐから読み出したデータに含まれる固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致すると判断した場合には、ポイント利用選択画面を表示する。
【０２７７】
図３５は、実施形態４に基づくポイント利用選択画面を説明する図である。
図３５に示されるように、ポイントを選択的に利用可能なポイント利用選択画面３００が示されている。
【０２７８】
具体的には、キャラクタオブジェクトに対応付けられたポイント値を利用してマップ上に表示するオブジェクトを選択することが可能な画面が示されている。
【０２７９】
一例として、「ベンチ」オブジェクト３０２が示されており、当該「ベンチ」オブジェクト３０２をマップ上に表示するためにポイント値として５ポイント必要である場合が示されている。
【０２８０】
また、ポイント利用選択画面３００には、「使う」ボタン３０６と、「使わない」ボタン３０８とが設けられている。また、カーソル３０４が設けられている。
【０２８１】
カーソル３０４を選択することによりマップ上に表示するオブジェクトを変更することが可能である。例えば、カーソル３０４を選択することにより「ベンチ」オブジェクトではなく、別の「ブランコ」オブジェクト等に変更することも可能である。
【０２８２】
ユーザは、入力部１６を操作して「使う」ボタン３０６を選択することにより、当該表示されているオブジェクトを選択することが可能である。
【０２８３】
一方、ユーザは、入力部１６を操作して「使わない」ボタン３０８を選択することにより、ポイント利用選択画面３００におけるポイントの利用の無しを選択することが可能である。そして、当該ポイント利用選択画面３００の表示が終了する。
【０２８４】
例えば、ユーザが「使う」ボタン３０６を選択した場合には、「ベンチ」オブジェクト３０２をマップ上に表示することが可能である。
【０２８５】
図３６は、実施形態４に基づく一例としてベンチオブジェクトを表示した場合を説明する図である。
【０２８６】
図３６に示されるように、図２２の画面と比較して、「ベンチ」オブジェクト３０２がゲーム画面に表示されている。
【０２８７】
なお、「ベンチ」オブジェクト３０２は、上記で説明した家モデル１００と同様、ゲームの進行に影響を与えないオブジェクト（操作受付不可オブジェクト）である。
【０２８８】
また、当該処理により、キャラクタオブジェクト１１１に対応して設けられたポイント表示領域４００において、ポイント値４０２は、「１０」ポイントから「５」ポイントに変更された場合が示されている。
【０２８９】
再び、図３３を参照して、アプリケーション部３１は、利用が有るかどうかを判断する（ステップＳ１０６）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使う」ボタンが選択されたか否かを判断する。
【０２９０】
ステップＳ１０６において、アプリケーション部３１は、利用が有ると判断した場合（ステップＳ１０６においてＹＥＳ）には、オブジェクトを表示する（ステップＳ１０８）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使う」ボタンが選択された場合には、当該選択されたオブジェクトをマップ上に表示する。
【０２９１】
そして、処理を終了する（リターン）。
一方、ステップＳ１０６において、アプリケーション部３１は、利用が無いと判断した場合（ステップＳ１０６においてＮＯ）には、処理を終了する（リターン）。具体的には、アプリケーション部３１は、ポイント利用選択画面３００において「使わない」ボタンが選択された場合には、当該ポイント利用選択画面の表示を終了する。
【０２９２】
一方、ステップＳ１０３において、アプリケーション部３１は、ＩＤが一致しないと判断した場合（ステップＳ１０３においてＮＯ）には、処理を終了する（リターン）。具体的には、アプリケーション部３１は、タグ２Ｐのデータに含まれている固有ＩＤと、メモリ１４に既に登録されているタグの固有ＩＤとが一致するか否かを判断し、一致しないと判断した場合には、ポイント利用選択画面の表示をスキップして処理を終了する。したがって、この場合にはポイントを利用することができない。
【０２９３】
当該処理により、情報処理装置３のメモリ１４に登録されているタグの固有ＩＤと、タグ２Ｐから読み出したデータに含まれる固有ＩＤとが一致した場合に、セーブデータのポイントを利用してオブジェクトを配置することが可能である。一方で、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤと異なる固有ＩＤが登録されている場合には、セーブデータのポイントを利用することはできない。
【０２９４】
例えば、ユーザがタグ２Ｐを有している場合に、タグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現してゲーム処理を実行することが可能である。タグ２Ｐに基づくゲーム処理を実行する場合、タグ２Ｐの固有ＩＤは、情報処理装置３のメモリ１４に登録されるものとする。また、タグ２Ｐの登録済フラグはオンに設定されるものとする。この場合、ゲーム処理として、タグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現して、当該タグ２Ｐに格納されているポイント値を利用した処理を実行することが可能である。
【０２９５】
また、別のユーザが別のタグ２Ｐ（固有ＩＤは異なる）を有している場合、ゲーム処理として、当該別のタグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現してゲーム処理を実行することが可能である。当該別のタグ２Ｐの固有ＩＤは、別の情報処理装置３のメモリ１４に登録されているものとする。また、当該別のタグ２Ｐの登録済フラグはオンに設定されているものとする。この場合、ゲーム処理として、当該別のタグ２Ｐに格納されているキャラクタＩＤに対応するキャラクタオブジェクトを出現させるが、当該別のタグ２Ｐに格納されているポイント値を利用した処理は実行できない。つまり、この場合には制限された処理となる。
【０２９６】
したがって、タグ２Ｐの固有ＩＤを情報処理装置３のメモリ１４に登録することにより情報処理装置３とタグ２Ｐとを関連付けることが可能となり、特定の装置においてゲーム処理として異なる処理を実行することが可能であり、タグを用いた処理の興趣性を高めることが可能である。
【０２９７】
なお、本例においては、情報処理装置３のメモリ１４にタグ２Ｐの固有ＩＤを登録して、アクセスするタグの固有ＩＤと比較して一致する場合に所定のイベント処理を実行する場合について説明したが、特に当該方式に限られず他の方式で実行するようにしても良い。
【０２９８】
例えば、情報処理装置３の識別情報（ＩＤ）をタグ２Ｐに登録することにより、アクセスするタグ２Ｐに登録された当該識別情報（ＩＤ）と実行する情報処理装置３の識別情報（ＩＤ）とを比較して一致する場合に所定のイベント処理を実行するようにしても良い。
【０２９９】
あるいはタグ２Ｐにユーザアカウント情報（ユーザ識別情報）を登録して、実行する情報処理装置３のメモリ１４に予め保存されているユーザアカウント情報とを比較して一致する場合に所定のイベント処理を実行するようにしても良い。
【０３００】
（情報処理システムの構成に関する変形例）
他の実施形態において、タグ２が情報処理部を有する場合には、情報処理装置３で実行される処理の一部は、タグ２の側で実行されてもよい。例えば、通信制御部３２における処理（の一部または全部）が、タグ２が有する情報処理部によって実行されてもよい。上記実施形態においては、通信制御部３２は実際にはタグ２からデータを読み出し、通信制御部３２がアプリケーション部３１へのデータの受け渡しを管理することによって、アプリケーション部３１によるタグ２からのデータの読み出しを制限するようにした。これに対して、通信制御部３２における処理がタグ２の側で実行される場合には、情報処理装置３によるタグ２からのデータの読み出しが実際に制限されることになる。
【０３０１】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０３０２】
１  情報処理システム、２  タグ、３  情報処理装置、１１  通信部、１２  通信チップ、１４  メモリ、１５  プログラム記憶部、１６  入力部、１７  表示部、２１  読み書き可能領域、２２  読み出し専用領域、２３  管理領域、３１  アプリケーション部、３２  通信制御部、４０，４１，４２  タブ、４３  スライダ、４４  ボタン、５０  アイコン、１００  家モデル。
【要約】
【課題】記憶媒体のデータを異なるアプリケーションプログラム間で利用することが可能な情報処理プログラムを提供する。
【解決手段】情報処理プログラムは、情報記憶媒体との間で近距離無線通信が可能なコンピュータで実行される情報処理プログラムであって、情報処理プログラムは、コンピュータを、情報記憶媒体と近距離無線通信を行うことによって、当該情報記憶媒体からデータを読み込む読込手段と、読込手段において読み込んだ第１のデータを用いて第２のデータを生成する第１のアプリケーションプログラムを実行する第１処理手段と、情報記憶媒体と近距離無線通信を行うことによって、第２のデータを情報記憶媒体に書き込む書込手段と、読込手段において読み込んだ第２のデータを用いて第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを実行する第２の処理手段として機能させる。
【選択図】図１３【図１】
0005889465.tif 000002
【図２】
0005889465.tif 000003
【図３】
0005889465.tif 000004
【図４】
0005889465.tif 000005
【図５】
0005889465.tif 000006
【図６】
0005889465.tif 000007
【図７】
0005889465.tif 000008
【図８】
0005889465.tif 000009
【図９】
0005889465.tif 000010
【図１０】
0005889465.tif 000011
【図１１】
0005889465.tif 000012
【図１２】
0005889465.tif 000013
【図１３】
0005889465.tif 000014
【図１４】
0005889465.tif 000015
【図１５】
0005889465.tif 000016
【図１６】
0005889465.tif 000017
【図１７】
0005889465.tif 000018
【図１８】
0005889465.tif 000019
【図１９】
0005889465.tif 000020
【図２０】
0005889465.tif 000021
【図２１】
0005889465.tif 000022
【図２２】
0005889465.tif 000023
【図２３】
0005889465.tif 000024
【図２４】
0005889465.tif 000025
【図２５】
0005889465.tif 000026
【図２６】
0005889465.tif 000027
【図２７】
0005889465.tif 000028
【図２８】
0005889465.tif 000029
【図２９】
0005889465.tif 000030
【図３０】
0005889465.tif 000031
【図３１】
0005889465.tif 000032
【図３２】
0005889465.tif 000033
【図３３】
0005889465.tif 000034
【図３４】
0005889465.tif 000035
【図３５】
0005889465.tif 000036
【図３６】
0005889465.tif 000037