JP5897688B2 - 情報処理システム、情報処理装置、情報処理プログラム、情報処理方法、および、記憶媒体 - Google Patents

Description

本発明は、近距離無線通信を行うための情報処理システム、情報処理装置、情報処理プログラム、情報処理方法、および、記憶媒体に関する。

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

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

従来、近距離無線通信によって情報処理装置と通信を行う記憶媒体は、情報処理装置において実行される特定のアプリケーションプログラムにおいて利用されるだけであり、記憶媒体の汎用性については改善の余地があった。

それ故、本発明の目的は、記憶媒体をより汎用的に利用することができる情報処理システム、情報処理装置、情報処理プログラム、情報処理方法、および、記憶媒体を提供することである。

上記の課題を解決すべく、本発明は、以下の（１）〜（３６）の構成を採用した。

（１）
本発明の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
記憶媒体は、所定のゲームアプリケーションプログラムで利用可能なアプリ用データと、当該所定のゲームアプリケーションプログラムであるか他のゲームアプリケーションプログラムであるかにかかわらず利用可能な共用データとを記憶する記憶手段を備える。
情報処理システムは、受付手段と、第１処理手段と、第２処理手段とを備える。受付手段は、情報処理装置で実行されるゲームアプリケーションプログラムから、記憶手段に対するデータの読み出しに関する指令を受け付ける。第１処理手段は、受け付けられた指令がアプリ用データに関する指令である場合、当該指令が所定のゲームアプリケーションプログラムからの指令であることを条件として、記憶手段から読み出したアプリ用データを当該所定のゲームアプリケーションプログラムに渡す。第２処理手段は、受け付けられた指令が共用データに関する指令である場合、当該指令が所定のゲームアプリケーションプログラムからの指令であるか他のゲームアプリケーションプログラムであるかにかかわらず、記憶手段から読み出した共用データを指令元のゲームアプリケーションプログラムに渡す。

（２）
記憶手段は、記憶媒体の種類毎に設定される識別情報を記憶していてもよい。このとき、所定のゲームアプリケーションプログラムは、自身がアプリ用データを利用可能な種類の記憶媒体に設定される識別情報を含んでいてもよい。第１処理手段は、記憶手段から読み出した識別情報と、指令元のゲームアプリケーションプログラムから取得した識別情報とに基づいて、受け付けられた指令が所定のゲームアプリケーションプログラムからの指令であるか否かを判定してもよい。

（３）
記憶手段は、アプリ用データを利用可能な１種類以上の所定のゲームアプリケーションプログラムを特定するための識別情報を記憶していてもよい。このとき、受付手段は、指令元のゲームアプリケーションプログラムに対応する識別情報を当該ゲームアプリケーションプログラムから受け付けてもよい。第１処理手段は、記憶手段に記憶されている識別情報と、指令元のゲームアプリケーションプログラムから取得した識別情報とに基づいて、受け付けられた指令が所定のゲームアプリケーションプログラムからの指令であるか否かを判定してもよい。

（４）
記憶手段は、第１処理手段によって復号可能な方式で暗号化されたアプリ用データおよび第２処理手段によって復号可能な方式で暗号化された共用データを記憶してもよい。

（５）
記憶媒体は、所定のゲームアプリケーションプログラムを実行することによって生成される仮想空間に登場するオブジェクトであってアプリ用データおよび／または共用データが表すオブジェクトを立体的または平面的に表す外観を有していてもよい。

（６）
記憶手段は、共用データとして、オブジェクトの識別情報、当該オブジェクトが属するグループの識別情報、記憶媒体毎に固有の識別情報、および、記憶媒体の種類を示す識別情報のうち少なくとも１つのデータを記憶してもよい。

（７）
情報処理装置は、ある記憶媒体との間で近距離無線通信が可能となった場合、当該記憶媒体が当該情報処理装置からのアクセスが許可される許可記憶媒体であるか否かを判定する判定手段を備えていてもよい。受付手段は、近距離無線通信が可能となった記憶媒体が許可記憶媒体であると判定された場合、情報処理装置で実行されるゲームアプリケーションプログラムからの指令に応じた処理を実行してもよい。

（８）
記憶媒体は、データの読み出しが可能でかつ書き込みが不可能な読み出し専用領域に共用データの少なくとも一部を記憶し、データの読み出しおよび書き込みが可能な読み書き可能領域にアプリ用データを記憶してもよい。

（９）
アプリ用データは、所定のゲームアプリケーションプログラムのセーブデータであってもよい。

（１０）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
記憶媒体は、所定のアプリケーションプログラムに登場するオブジェクトに関するデータであって、当該所定のアプリケーションプログラムであるか否かにかかわらず利用可能な共用データを記憶する記憶手段を備える。
情報処理装置は、第１処理手段と、第２処理手段とを備える。第１処理手段は、所定のアプリケーションプログラムを実行する際に、記憶手段から読み出した共用データを用いることによって、出力装置にオブジェクトに関する情報を出力する第１処理を実行する。第２処理手段は、所定のアプリケーションプログラムとは異なるアプリケーションプログラムを実行する際に、記憶手段から読み出した共用データを用いることによって、出力装置にオブジェクトに関する情報を出力する処理であって第１処理とは異なる第２処理を実行する。

（１１）
情報処理装置は、判定手段と、許可手段とをさらに備えていてもよい。判定手段は、ある記憶媒体との間で近距離無線通信が可能となった場合、当該記憶媒体が当該情報処理装置で実行されるアプリケーションプログラムからのアクセスが許可される許可記憶媒体であるか否かを判定する。許可手段は、近距離無線通信が可能となった記憶媒体が許可記憶媒体であると判定されたことを条件として、情報処理装置で実行されるアプリケーションプログラムにおける共用データの利用を許可する。

（１２）
第１処理手段は、第１処理として、表示装置にオブジェクトを表示する処理を実行してもよい。第２処理手段は、第２処理として、表示装置にオブジェクトを表示する処理であって第１処理と異なる処理を実行してもよい。

（１３）
第２処理手段は、第２処理として、第１処理によって表示されるオブジェクトの表示態様とは異なる表示態様で当該オブジェクトを表示する処理を実行してもよい。

（１４）
第２処理手段は、所定のアプリケーションプログラムとは異なるゲームアプリケーションプログラムを実行する際に、第２処理として、ゲームの進行に影響を与えない処理を実行してもよい。

（１５）
記憶媒体は、共用データが表すオブジェクトを立体的または平面的に表す外観を有してもよい。

（１６）
記憶媒体は、それに記憶されるデータの一部または全部に対するハッシュ値を記憶してもよい。判定手段は、記憶媒体から読み出したデータに基づいて算出されるハッシュ値と、当該記憶媒体から読み出したハッシュ値とに基づいて、記憶媒体が許可記憶媒体であるか否かを判定してもよい。

（１７）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
記憶媒体は、情報処理装置が所定のアプリケーションプログラムを実行することによって生成される仮想空間に登場するオブジェクトを立体的または平面的に表す外観を有する。また、記憶媒体は、オブジェクトの第１識別情報と、当該オブジェクトが属するグループの第２識別情報とを記憶する。
情報処理装置は、記憶媒体から読み出した第１識別情報を用いて所定の処理を実行し、記憶媒体から読み出した第２識別情報を用いて当該所定の処理を実行する。

（１８）
情報処理装置は、第１判定手段と、第２判定手段と、処理実行手段とを備えていてもよい。第１判定手段は、アプリケーションプログラムの実行中において、記憶媒体から読み出された第１識別情報が実行中のアプリケーションプログラムにおいて登録された値であるか否かを判定する。第２判定手段は、記憶媒体から読み出された第２識別情報が実行中のアプリケーションプログラムにおいて登録された値であるか否かを判定する。処理実行手段は、記憶媒体から読み出された第１識別情報および第２識別情報の少なくともいずれかが実行中のアプリケーションプログラムにおいて登録された値である場合、当該アプリケーションプログラムにおける所定の処理を実行する。

（１９）
所定の処理は、オブジェクトに関する処理であってもよい。
処理実行手段は、記憶媒体から読み出された第１識別情報が実行中のアプリケーションプログラムにおいて登録された値である場合、当該第１識別情報を用いてオブジェクトを特定してもよい。また、処理実行手段は、記憶媒体から読み出された第１識別情報が実行中のアプリケーションプログラムにおいて登録された値ではなく、かつ、記憶媒体から読み出された第２識別情報が実行中のアプリケーションプログラムにおいて登録された値である場合、当該第２識別情報を用いてオブジェクトを特定してもよい。

（２０）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記記憶媒体は、所定のアプリケーションプログラムであるか否かにかかわらず利用可能な共用データを記憶する記憶手段を備える。
前記情報処理装置は、以下の手段を備える。
・ユーザおよび／または前記情報処理装置に関する登録データが前記記憶媒体に記憶されていることを条件として、前記所定のアプリケーションにおける所定の処理を許可する許可手段
・前記登録データが前記記憶媒体に記憶されているか否かを判定する判定手段
・前記登録データが前記記憶媒体に記憶されていないと判定された場合、前記登録データを前記記憶媒体に記憶するための処理を実行する登録処理手段

（２１）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記記憶媒体は、ユーザおよび／または前記情報処理装置に関する登録データを記憶するための記憶手段を備える。
前記情報処理装置は、以下の手段を備える。
・前記登録データが前記記憶媒体に記憶されているか否かを判定するための処理を、複数のアプリケーションプログラムにおいて共通で実行する判定手段
・前記判定手段により前記登録データが前記記憶媒体に記憶されていないと判定された場合、前記登録データを前記記憶媒体に記憶するための処理を実行する登録処理手段

（２２）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記記憶媒体は、ユーザおよび／または前記情報処理装置に関する登録データを記憶する記憶手段を備える。
前記情報処理装置は、以下の手段を備える。
・前記登録データが前記記憶媒体に記憶されているか否かを判定する判定手段
・前記記憶媒体に対して前記登録データの読み出しおよび／または書き込みを行う際に、前記判定手段により前記登録データが前記記憶媒体に記憶されていないと判定された場合、前記登録データを前記記憶媒体に記憶するための処理を実行する登録処理手段

（２３）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記情報処理装置は、以下の手段を備える。
・所定のアプリケーションの実行中において、前記記憶媒体に対してアクセス可能となった場合、前記記憶媒体に記憶されるアプリ用データが当該所定のアプリケーションにおいて利用可能であるか否かを示す利用情報が前記記憶媒体に記憶されているか否かを判定する利用判定手段
・前記利用情報が前記記憶媒体に記憶されていないと判定されたことを少なくとも条件として、前記記憶媒体に記憶されるアプリ用データが前記所定のアプリケーションにおいて利用可能であることを示す利用情報を前記記憶媒体に書き込む書込手段
・あるアプリケーションにおいてアプリ用データが利用可能であることを示す利用情報が記憶媒体に記憶されていることを条件として、当該あるアプリケーションに対して当該記憶媒体に記憶されているアプリ用データの利用を許可する許可手段

（２４）
前記記憶媒体は、所定の識別情報を記憶してもよい。
前記情報処理装置は、以下の手段をさらに備えていてもよい。
・実行中の所定のアプリケーションから、当該所定のアプリケーションにおいてアプリ用データを記憶するために利用可能な記憶媒体の識別情報を示す利用可能情報を取得する取得手段
・前記記憶媒体に記憶されている識別情報と、前記取得された利用可能情報とに基づいて、当該記憶媒体が前記所定のアプリケーションで利用可能であるか否かを判定する利用可能判定手段
また、前記書込手段は、前記利用可能判定手段による判定結果が肯定である場合に、前記利用情報が前記記憶媒体に記憶されていないと判定されたことを条件として、前記記憶媒体に記憶されるアプリ用データが前記所定のアプリケーションにおいて利用可能であることを示す利用情報を前記記憶媒体に書き込んでもよい。

（２５）
前記利用可能情報は、前記記憶媒体の種類を識別するための種類識別情報を示すものであってもよい。
前記情報処理装置は、前記利用可能情報として、前記所定のアプリケーションで利用可能な記憶媒体の種類を識別するための種類識別情報のリストを取得する取得手段をさらに備えてもよい。
前記利用可能判定手段は、前記記憶媒体に記憶されている種類識別情報が前記種類識別情報のリストに含まれるか否かを判定してもよい。

（２６）
前記情報処理装置は、前記記憶媒体に前記利用情報が記憶されている場合に、ユーザの操作に応じて当該利用情報を当該記憶媒体から消去させる消去手段をさらに備えてもよい。

（２７）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記記憶媒体は、所定のアプリケーションプログラムで利用可能なアプリ用データを記憶する記憶手段を備える。
前記情報処理装置は、以下の手段を備える。
・前記記憶媒体に記憶されるデータに対するバックアップデータを記憶するバックアップ記憶手段
・前記情報処理装置と通信可能である記憶媒体に記憶されているデータが壊れている場合、当該情報処理装置において前記所定のアプリケーションプログラムが実行されていない場合であっても、当該記憶媒体に記憶されているデータを、前記バックアップデータを用いて復旧するデータ復旧手段

（２８）
前記情報処理装置は、前記記憶媒体に所定のデータを書き込む書込手段をさらに備えてもよい。
前記バックアップ記憶手段は、前記書込手段によって書き込まれる前に前記所定のデータをバックアップデータとして記憶してもよい。

（２９）
前記情報処理装置は、前記記憶媒体を識別するための識別情報を取得する識別情報取得手段をさらに備えてもよい。
前記バックアップ記憶手段は、前記識別情報に関連付けて前記バックアップデータを記憶してもよい。

（３０）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う第１の情報処理装置とを含む情報処理システムである。
前記記憶媒体は、所定のオブジェクトを立体的または平面的に表す外観を有する。
前記記憶媒体は、前記所定のオブジェクトを示すオブジェクト情報とは異なる他の情報を、第１の方法で暗号化された状態で、前記オブジェクト情報を、前記第１の方法とは異なる第２の方法で暗号化された状態で記憶する記憶手段を備える。
前記第１の情報処理装置は、前記記憶媒体に記憶されているオブジェクト情報を用いて、前記オブジェクトを表示装置に表示させる処理を実行する。

（３１）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う第１の情報処理装置とを含む情報処理システムである。
前記記憶媒体は、所定のオブジェクトを立体的または平面的に表す外観を有する。
前記記憶媒体は、前記所定のオブジェクトを示すオブジェクト情報とは異なる他の情報を、第１の方法で暗号化された状態で記憶するとともに、前記オブジェクト情報を、暗号化されない状態で記憶する記憶手段を備える。
前記第１の情報処理装置は、前記記憶媒体に記憶されているオブジェクト情報を用いて、前記オブジェクトを表示装置に表示させる処理を実行する。

（３２）
前記情報処理システムは、前記第１の情報処理装置とは異なる第２の情報処理装置をさらに含んでもよい。
前記第１の情報処理装置は、第１の方法で暗号化された情報を復号する第１復号処理機能を有していない。
前記第２の情報処理装置は、第１の方法で暗号化された情報を復号する第１復号処理手段と、第２の方法で暗号化された情報を復号する第２復号処理手段とを備える。

（３３）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記情報処理装置は、以下の手段を備える。
・所定のアプリケーションの実行中において前記情報処理装置にアクセス可能となった記憶媒体が、ユーザおよび／または前記情報処理装置に関する登録データを記憶しているか否かを判定する判定手段
・前記記憶媒体が前記登録データを記憶していないと判定された場合、ユーザによって入力された登録内容に基づいて登録データを前記記憶媒体に書き込むとともに、当該登録データが前記記憶媒体に書き込まれる場合には、ユーザ指示の有無にかかわらず、前記所定のアプリケーションに関する情報を前記記憶媒体に書き込む書込処理手段

（３４）
本発明の他の一例は、記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムである。
前記記憶媒体は、前記情報処理装置を用いてアクセス可能なネットワークサービスに関するユーザの識別情報を記憶している。
前記情報処理装置は、前記ネットワークサービスを提供するサーバと通信可能である。
前記情報処理装置は、前記記憶媒体と通信可能となった場合、一定条件下で、かつ、前記ユーザの指示の有無にかかわらず、前記記憶媒体から読み出した前記識別情報を用いて前記サーバにアクセスする。

（３５）
前記情報処理システムは、前記記憶媒体と近距離無線通信を行う、前記情報処理装置とは異なる他の情報処理装置を含んでもよい。
前記他の情報処理装置は、前記識別情報を記憶するための記憶手段を有する。
前記他の情報処理装置は、前記記憶媒体と通信を行って前記記憶媒体に記憶されている記憶されている識別情報を前記記憶手段に記憶させる。

（３６）
前記他の情報処理装置は、前記記憶手段に記憶されている識別情報を用いて前記サーバにアクセスしてもよい。

なお、本発明の別の一例は、上記（１）〜（３６）における情報処理システムに含まれる情報処理装置または記憶媒体であってもよいし、当該情報処理装置の各手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記情報処理システムにおいて実行される情報処理方法であってもよい。

本発明によれば、近距離無線通信を行う記憶媒体をより汎用的に利用することができる。

本実施形態に係る情報処理システムの一例の構成を示す図 タグの外観の一例を示す図 タグに記憶されるデータの一例を示す図 特定アプリプログラムによってタグからデータが読み出される場合における情報処理システムの処理の流れの一例を示す図 特定アプリプログラムによってタグからデータが読み出される場合における情報処理システムの処理の流れの一例を示す図 読出指令を受けた場合における通信制御部の処理（読出指令処理）の流れの一例を示すフローチャート タグに対して初期登録データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図 登録指令を受けた場合における通信制御部の処理（登録指令処理）の流れの一例を示すフローチャート タグに対して専用データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図 書込指令を受けた場合における通信制御部の処理（書込指令処理）の流れの一例を示すフローチャート 装置変更回数のカウント方法の一例を示す図 アプリケーションプログラムによってＣＰＵが実行する処理の流れの一例を示すフローチャート 特定アプリプログラムによってＣＰＵが実行する処理（特定アプリ処理）の流れの一例を示すフローチャート 特定アプリ処理におけるキャラクタ設定画面の一例を示す図 特定アプリ処理によって表示部に表示されるゲーム画像の一例を示す図 特定アプリプログラムとは異なる他のアプリケーションプログラムによってＣＰＵが実行する処理（他アプリ処理）の流れの一例を示すフローチャート 他アプリ処理におけるキャラクタ設定画面の一例を示す図 本実施形態の変形例におけるタグに記憶されるデータの一例を示す図 本実施形態の他の変形例におけるタグに記憶されるデータの一例を示す図 本実施形態の変形例において、アプリケーションプログラムによってタグにデータが書き込まれる場合における情報処理システムの処理の流れの一例を示す図 本実施形態の変形例における書込指令処理の流れの一例を示すフローチャート 本実施形態の変形例において、タグに初期登録データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図 本実施形態の変形例における登録確認画像の一例を示す図 本実施形態の変形例において初期登録を行うための処理の流れの一例を示すフローチャート 本実施形態の変形例における情報処理装置がタグのバックアップデータを記憶する場合における情報処理システムの一例を示す図 本実施形態の変形例における書込指令処理の流れの一例を示すフローチャート 本実施形態の変形例における読出指令処理の流れの一例を示すフローチャート 本実施形態の変形例におけるデータ復旧処理の流れの一例を示す図 本実施形態の変形例における情報処理装置において記憶されるプログラム構成の概要を示す図

［１．通信システムの構成］
以下、本実施形態の一例に係る情報処理システム、情報処理装置、情報処理プログラム、情報処理方法、および記憶媒体について説明する。まず、情報処理システムの構成について説明する。図１は、本実施形態に係る情報処理システムの一例の構成を示す図である。図１に示すように、情報処理システム１は、記憶媒体（タグ）２と、情報処理装置３とを含む。情報処理装置３は、タグ２との間で近距離無線通信が可能な任意の情報処理装置である。

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

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

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

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

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

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

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

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

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

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

図２は、タグ２の外観の一例を示す図である。図２に示すように、本実施形態におけるタグ２は、キャラクタを表す外観を有する、フィギュア型のタグである。タグ２が表すキャラクタは、情報処理装置３で実行可能な特定のアプリケーション（例えばゲーム）に登場するキャラクタである。ユーザは、このタグ２を用いることによって、上記特定のアプリケーションにおいて上記キャラクタを登場させることができる。すなわち、情報処理装置３は、上記特定のアプリケーションのプログラムを実行する際、タグ２に記憶されるデータを用いることによって、当該アプリケーションのプログラムによって生成される仮想空間に上記のキャラクタを登場させる。なお、フィギュア型のタグ２は、アプリケーションに登場する任意のオブジェクトを表すものであり、キャラクタに限らず、ゲームアプリケーションにおけるアイテムを表すものであってもよい。

上記のように、タグ２は、特定のアプリケーションプログラムにおいて用いられる。また、詳細は後述するが、タグ２は、特定のアプリケーションプログラムにおいてのみ利用可能なデータ（後述する専用データ）を記憶することができる。以下では、このような特定のアプリケーションプログラムを「特定アプリプログラム」と呼ぶ。なお、１種類のタグに対応する特定アプリプログラムは１種類であってもよいし、複数種類であってもよい。例えば、１つのシリーズのアプリケーションとして複数種類のアプリケーションが提供されている場合には、これら複数種類のアプリケーションが特定アプリプログラムであってもよい。

なお、詳細は後述するが、タグ２は、特定アプリプログラムにおいて利用可能である一方、他のアプリケーションプログラムにおいても利用可能である。すなわち、タグ２は、特定アプリプログラムにおいてのみ利用可能なデータを記憶する一方、特定アプリプログラム以外の他のアプリケーションプログラムにおいても利用可能なデータも記憶する。以下、タグ２に記憶されるデータの一例について説明する。

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

また、本実施形態においては、大別して、専用データ、共用データ、および管理データという３種類のデータがタグ２に記憶される。なお、図３に示すように、本実施形態においては、各データが記憶される記憶領域（専用データ領域、共用データ領域、および管理データ領域）は予め定められているものとするが、他の実施形態においては定められていなくてもよい。

専用データは、上述の特定アプリプログラムでのみ利用可能なデータである。本実施形態において、専用データは、特定アプリプログラムのセーブデータを含む（図３参照）。セーブデータとしては、例えば、タグ２が表すキャラクタに関するパラメータを示すデータ、特定アプリプログラムのゲームの進行状態を示すデータ、および／または、特定アプリプログラムのゲームのプレイヤに関するデータ等が記憶される。なお、本実施形態においては、専用データは、読み書き可能領域２２に記憶され、読み出し専用領域２１には記憶されない（図３参照）。

次に、共用データについて説明する。共用データは、特定アプリプログラムであるか否かにかかわらず利用可能なデータである。本実施形態においては、共用データは、読み出し専用領域２１および読み書き可能領域２２の両方に記憶される。なお、タグ２は、読み出し専用領域２１または読み書き可能領域２２のいずれか一方にのみ共用データを記憶してもよい。

読み出し専用領域２１には、共用データとして、少なくとも次のデータ（情報）が記憶される。
・固有ＩＤ（を示すデータ）
・タイプＩＤ（を示すデータ）
・フィギュアＩＤ（を示すデータ）
・シリーズＩＤ（を示すデータ）
・利用ＩＤ（を示すデータ）

固有ＩＤは、タグに固有の識別情報である。ここで、本実施形態におけるタグ２のようなＮＦＣタグには、ＵＩＤ（Ｕｎｉｑｕｅ ＩＤ）という、タグに固有の識別情報が記憶される。上記固有ＩＤは、このＵＩＤとは異なる情報である。固有ＩＤは、タグを用いたサービスの提供者がタグを管理しやすいように、ＵＩＤとは別に付されたＩＤである。

フィギュアＩＤは、フィギュア型のタグ２の外観（形状・色）に固有の識別情報である。フィギュアＩＤは、タグ２のフィギュアの種類を一意に特定することが可能な識別情報である。例えば、１つのキャラクタにつき、それぞれ外観が異なる（例えば、ポーズや服装が異なる）複数種類のタグがある場合には、各タグには異なる値のフィギュアＩＤが設定される。この場合、フィギュアＩＤは、キャラクタに固有のＩＤ（キャラクタＩＤ）と、ポーズ・服装などの違いを示すＩＤ（ナンバリングＩＤ）とを含んでもよい。また、１つのキャラクタに複数の種類がある場合（例えば、あるキャラクタがアイテムを取得することによっていくつかの形態に変身する場合）、上記フィギュアＩＤ（キャラクタＩＤ）は、当該複数の種類を１グループとしてキャラクタを示すＩＤと、種類毎に異なるＩＤとを含んでいてもよい。

なお、情報処理装置３において実行可能なアプリケーションプログラムは、自身において利用する（利用可能な）タグのフィギュアＩＤの情報を含んでいる。詳細は後述するが、アプリケーションプログラムに含まれるフィギュアＩＤの値と、タグに記憶されるフィギュアＩＤの値とが一致する場合、アプリケーションプログラムは、当該タグに記憶される専用データを利用可能となる。つまり、フィギュアＩＤは、タグ２に記憶される専用データの利用を管理するための識別情報であるとも言うことができる。

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

タイプＩＤは、タグ２の種類を示す識別情報である。本実施形態においては、情報処理装置３においては、タグ２のようなフィギュア型のタグの他、カード型のタグも利用可能であるとする。タイプＩＤは、タグの種類として、フィギュア型のタグであるかカード型のタグであるかを示す識別情報である。なお、他の実施形態においては、タイプＩＤによって識別可能なタグの種類は任意である。例えば、タグを提供する業者毎に異なるタイプＩＤが付されてもよい。

利用ＩＤは、タグ２に記憶される専用データ（詳細は後述する）を利用可能なアプリケーションプログラム（上記の特定アプリプログラム）を特定する識別情報である。ここで、情報処理装置３において実行可能なアプリケーションプログラムには、利用ＩＤが付される。本実施形態においては、タグ２に記憶される専用データの利用を管理するために上記のフィギュアＩＤが用いられる（後述の特定アプリ判定処理を参照）。ただし、他の実施形態においては、タグ２に記憶される専用データの利用を管理するために利用ＩＤが用いられてもよい。

また、図３に示すように、読み書き可能領域２２には、共用データとして、初期登録データと更新データとが記憶される。なお、タグ２に記憶される共用データの内容は任意である。例えば、他の実施形態においては、タグ２は、共用データとして、初期登録データおよび更新データのいずれか一方のみを記憶してもよい。

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

本実施形態においては、初期登録データには次のデータが含まれる。
・アバターデータ
・ニックネーム（を示すデータ）
・登録日時（を示すデータ）
・地域（を示すデータ）

アバターデータは、ユーザのアバターのデータである。アバターデータは、情報処理装置３がアバターを生成して表示部１７に表示するために用いられるデータを含む。具体的には、アバターデータは、アバターの各部位（目や鼻等の形や、体型等）を示すデータを含んでいる。なお、本実施形態においては、情報処理装置３には、アバターデータを用いてアバターを生成するプログラムが記憶されているものとする。本実施形態においては、アバターを生成するプログラムは、情報処理装置３のシステムプログラムまたはライブラリとして予め記憶されており、各アプリケーションプログラムにおいて（アバター生成プログラムを用いることによって）アバターを表示することが可能である。

本実施形態においては、情報処理装置３には、アバターの各部位のパーツデータ（画像データあるいは３次元モデルデータ）が、１つの部位につき複数種類、予め記憶されている（アバター生成プログラムにパーツデータが含まれていてもよい）。また、パーツデータには種類毎に番号が付されており、アバターデータは、アバターを構成する各部位のパーツデータの番号を示す。情報処理装置３は、アバター生成プログラムを実行することによって、アバターデータが示す番号のパーツデータを用いてアバターを生成することが可能である。このように、本実施形態においては、タグ２に記憶されるアバターと、タグ２が表すキャラクタとでは、異なる方法（処理）で画像が生成される。

ニックネームは、ユーザがタグ２に対して付けるニックネームである。例えば、１人のユーザが同じ外観のタグを２つ以上所有している場合、これらのタグに対して互いに異なるニックネームを付すことで、各タグを区別することができる。

詳細は後述するが、タグに対して初期登録処理が実行される場合（後述する図７、図８参照）、情報処理装置３は、上記アバターデータおよびニックネームをユーザに入力させる。そして、入力されたデータが、後述する登録日時および地域のデータとともに、初期登録データとしてタグ２に記憶される。

登録日時は、初期登録が行われた日時である。また、地域は、初期登録が行われた地域である。詳細は後述するが、本実施形態においては、登録日時および地域のデータは、初期登録処理において情報処理装置３によって自動的にタグ２に書き込まれる。

次に、更新データに含まれる情報について説明する。更新データは、タグ２と情報処理装置３との通信が行われる際に（一定条件下で）内容が更新されるデータである。本実施形態においては、更新データには次のデータが含まれる。
・書き込み回数（を示すデータ）
・最終書き込み装置（を示すデータ）
・装置変更回数（を示すデータ）
・最終利用アプリ（を示すデータ）
・最終書き込み日時（を示すデータ）
詳細は後述するが、本実施形態においては、タグ２に記憶されている更新データは、専用データが書き込まれるタイミングで更新（上書き）される。

書き込み回数は、タグ２に対する専用データの書き込みが行われた回数である。

最終書き込み装置は、タグ２に対する専用データの書き込みを最後に行った情報処理装置である。本実施形態においては、情報処理装置毎に固有の識別情報が付されているものとし、最終書き込み装置のデータとして、書き込みを行った情報処理装置の識別情報のハッシュ値のデータが記憶される（書き込みを行った情報処理装置の識別情報自体のデータが記憶されてもよい）。

装置変更回数は、専用データの書き込みを行う情報処理装置が変更された回数である。詳細は後述するが、例えば、ユーザ自身の情報処理装置によってタグ２に対する書き込みが行われた後、ユーザの情報処理装置とは異なる情報処理装置（例えば、外出先の店頭に設置されている情報処理装置や、ユーザの友人の情報処理装置）によってタグ２に対する書き込みが行われた場合、装置変更回数が更新される。

最終利用アプリは、タグ２に対して専用データの書き込みを最後に行ったアプリケーションプログラムである。本実施形態においては、最終利用アプリのデータとして、アプリケーションプログラム毎に固有の識別情報のデータ（上記の利用ＩＤのデータでもよい）が記憶される。

最終書き込み日時は、タグ２に対して専用データの書き込みが最後に行われた日時である。

次に、管理データについて説明する。管理データは、タグの管理のために用いられるデータであり、例えば後述するアクセス許可判定処理等において用いられる。管理データは、基本的にはアプリケーションにおいては用いられないデータである。

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

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

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

［２．情報処理システムにおける処理動作］
次に、図４〜図１２を参照して、タグ２に対するデータの読み出しおよび書き込みに関する情報処理システム１の処理動作について説明する。なお、図４等に示すように、本実施形態においては、情報処理装置３内における動作を、機能的にアプリケーション部３１と通信制御部３２とに分けて説明する。本実施形態において、アプリケーション部３１は、上述のアプリケーションプログラムを実行するＣＰＵ１３である。通信制御部３２は、上述の通信プログラムを実行するＣＰＵ１３と、通信チップ１２および通信部１１とによって実現される。なお、他の実施形態においては、情報処理装置３における情報処理は、アプリケーションプログラムと通信プログラムという２種類のプログラムによって実現される必要は無く、単一のプログラムによって実現されてもよい。

（２−１：データ読出時の動作）
以下、図４〜図６を参照して、タグ２からデータを読み出す動作について説明する。図４および図５は、特定アプリプログラムによってタグからデータが読み出される場合における情報処理システムの処理の流れの一例を示す図である。なお、図４は、情報処理装置３において特定アプリプログラムが実行される場合、すなわち、アプリケーション部３１が特定アプリプログラムを実行するＣＰＵ１３によって実現される場合を示している。一方、図５は、情報処理装置３において特定アプリプログラムではない他のアプリケーションプログラムが実行される場合、すなわち、アプリケーション部３１が当該他のアプリケーションプログラムを実行するＣＰＵ１３によって実現される場合を示している。

また、図６は、読出指令を受け付けた場合における通信制御部３２の処理（読出指令処理）の流れの一例を示すフローチャートである。なお、図６に示すフローチャート（後述する図８，図１０，図１２におけるフローチャートについても同様）における各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。また、本実施形態では、上記フローチャートの各ステップの処理をＣＰＵ１３が実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ１３以外のプロセッサや専用回路が実行するようにしてもよい。

まず、アプリケーション部３１は、通信制御部３２に対してタグ２からのデータの読出指令を送る（図４および図５参照）。本実施形態において、この読出指令にはフィギュアＩＤが含まれる。上述のように、特定アプリプログラムは、自身が専用データを利用可能なタグのフィギュアＩＤの情報を含んでいる。したがって、アプリケーション部３１は、読出指令とともに、特定アプリプログラムに含まれるフィギュアＩＤを通信制御部３２へ送る。

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

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

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

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

専用データおよび共用データに含まれる各データのアドレスが特定されると、通信制御部３２は、共用データおよび専用データをタグ２から読み出す。通信制御部３２は、読み出したデータを復号してメモリ１４に記憶しておく。このように、本実施形態においては、通信制御部３２は、アプリケーション部３１からの読出指令の内容（タグ２内のどのデータを読み出すか）、および、アプリケーションプログラムの種類（特定アプリプログラムか否か）にかかわらず、共用データおよび専用データをタグ２から読み出す。

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

本実施形態においては、アクセス許可判定処理における判定は、タグ２に記憶されるデータのハッシュ値（第１ハッシュ値および第２ハッシュ値）を用いて行われる。具体的には、通信制御部３２は、ステップＳ２で読み出した、読み出し専用領域２１内のデータについて、上述の所定のアルゴリズムによってハッシュ値（第１ハッシュ値）を算出する。そして、算出したハッシュ値と、ステップＳ２で読み出した第１ハッシュ値とが一致するか否かを判定する。さらに、これら２つのハッシュ値が一致する場合には、読み書き可能領域２２内のデータと第２ハッシュ値についても同様に判定を行う。すなわち、通信制御部３２は、ステップＳ２で読み出した読み書き可能領域２２内のデータについて上記所定のアルゴリズムによってハッシュ値（第２ハッシュ値）を算出し、算出したハッシュ値と、ステップＳ２で読み出した第２ハッシュ値とが一致するか否かを判定する。

算出したハッシュ値と読み出した第２ハッシュ値とが一致する場合、通信制御部３２は、タグ２は許可タグであると判定する。この場合、通信制御部３２は、ステップＳ５の処理を実行する。一方、上記ハッシュ値を用いた２回の判定のいずれかにおいてハッシュ値が一致しない場合、タグ２は許可タグではないと判定する。この場合、通信制御部３２は、ステップＳ４の処理を実行する。

以上のように、本実施形態においては、タグ２は、それに記憶されるデータの一部または全部に対するハッシュ値（第１ハッシュ値および第２ハッシュ値）を記憶しており、通信制御部３２は、タグ２から読み出したデータに基づいて算出されるハッシュ値と、タグ２から読み出したハッシュ値とに基づいて、タグ２が許可タグであるか否かを判定する。このように、タグ２にハッシュ値を記憶しておくことによって、タグ２が許可タグであるか否かの判定を容易に行うことができる。

なお、他の実施形態においては、アクセス許可判定処理における判定は、他の方法によって行われてもよい。例えば、通信制御部３２は、タグ２に記憶されている所定の情報を（情報処理装置３の側でも）予め記憶しておき、タグから読み出した情報と、予め記憶しておいた情報とが一致するか否かによって上記判定を行ってもよい。なお、この判定に用いる所定の情報としては、例えば、以下の情報が考えられる。
・ＮＦＣタグに記憶されている、ＮＦＣの規格において定められるタグのタイプ（Ｔｙｐｅ１，Ｔｙｐｅ２等）を示す情報
・情報処理装置３（および／または情報処理装置３で実行可能なアプリケーションプログラム）を提供する事業者が許可するタグであることを示す情報（専用コード）
・上述のバージョン情報
また例えば、アクセス許可判定処理における判定は、読み出し専用領域２１に記憶されるデータが、バージョン情報から特定される設定に適合しているか否かによって行われてもよい。また例えば、アクセス許可判定処理における判定は、通信制御部３２によって読み出された所定のデータ（例えば、読み出し専用領域２１に記憶されるデータ）のサイズが所定の範囲内であるか否かによって上記判定を行ってもよい。

ステップＳ４において、通信制御部３２は、タグ２が許可タグではないことをアプリケーション部３１に通知する。この通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、タグ２が許可されたものではないためにデータの読み出しを行うことができない旨をユーザに対して通知する。ステップＳ４の処理の終了後、通信制御部３２は、図６に示す読出指令処理を終了する。

一方、ステップＳ５において、通信制御部３２は、特定アプリ判定処理を実行する。特定アプリ判定処理は、通信制御部３２に対する指令（ここでは読出指令）を行ったアプリケーションプログラムが特定アプリプログラムであるか否かを判定する処理である。

特定アプリ判定処理における判定は、上述のフィギュアＩＤを用いて行われる。すなわち、通信制御部３２は、アプリケーション部３１から指令と共に取得したフィギュアＩＤ（フィギュアＩＤが複数である場合にはそのうちのいずれか）と、ステップＳ２でタグ２から読み出したフィギュアＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは特定アプリプログラムであると判定する。この場合、通信制御部３２は、ステップＳ６の処理を実行する。一方、両者が異なれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは非特定アプリプログラム（特定アプリプログラムではないアプリケーションプログラム）と判定する。この場合、通信制御部３２は、ステップＳ７の処理を実行する。

ステップＳ６において、通信制御部３２は、アプリケーション部３１に対して専用データおよび共用データを渡す（出力する）（図４参照）。つまり、指令を行ったアプリケーションプログラムが特定アプリプログラムである場合には、通信制御部３２は、専用データの受け取りを許可する。なお、ステップＳ６の処理の終了後、通信制御部３２は、図６に示す読出指令処理を終了する。

なお、通信制御部３２から専用データおよび共用データを受け取ったアプリケーション部３１は、受け取ったデータを用いた情報処理を実行する。この情報処理の内容は任意である。例えば、アプリケーション部３１は、専用データであるセーブデータを用いたゲーム処理を実行する。なお、本実施形態においては、特定アプリプログラムは、専用データであるセーブデータを用いることとするが、専用データとともに（あるいは専用データに代えて）共用データを用いてもよい。

一方、ステップＳ７において、通信制御部３２は、アプリケーション部３１に対して共用データを渡す（出力する）（図５参照）。つまり、指令を行ったアプリケーションプログラムが非特定アプリプログラムである場合には、通信制御部３２は、専用データの受け取りを制限（禁止）する。なお、ステップＳ７の処理の終了後、通信制御部３２は、図６に示す読出指令処理を終了する。

なお、通信制御部３２から共用データを受け取ったアプリケーション部３１は、受け取ったデータを用いた情報処理を実行する。この情報処理の内容は任意であるが、例えば、以下の処理例が考えられる。
・フィギュアＩＤを用いて、フィギュアＩＤが表すキャラクタを表示する処理（図１２参照）
・アバターデータを用いて、ユーザのアバターを表示する処理（例えば、アバターをプレイヤキャラクタとして用いてゲームを実行する処理）
・ニックネームを情報処理装置３に記憶しておき、適宜のタイミングで表示する処理。
・更新データの内容に応じた処理（例えば、書き込み回数が所定回数以上である場合にゲーム上の特典を付与する処理、最終書き込み日時が所定時点よりも過去であれば「久しぶり」といったメッセージを表示する処理等）

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

（２−２：初期登録時の動作）
次に、図７および図８を参照して、タグ２に対して初期登録データを書き込む動作について説明する。図７は、タグ２に対して初期登録データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図である。また、図８は、登録指令を受けた場合における通信制御部３２の処理（登録指令処理）の流れの一例を示すフローチャートである。

まず、アプリケーション部３１は通信制御部３２に対して登録指令を出力し、通信制御部３２は登録指令を受け付ける。ここで、登録指令は、初期登録データをタグに書き込む指令である。本実施形態においては、登録指令を行うアプリケーション部３１は、情報処理装置３におけるシステムアプリケーションプログラム（ＯＳプログラム）によって実現される。つまり、初期登録データの書き込みは、システムアプリケーションプログラムによって（情報処理装置３の機能として）行われる。例えば、システムアプリケーションプログラムの実行中において（例えば、メニュー画面の表示中において）、タグ２に対する初期登録を行う旨の指示がユーザによって行われる。この指示が受け付けられたことに応じて、アプリケーション部３１は登録指令を出力する。

なお、本実施形態においては、システムアプリケーションのみが共用データを書き込むことができるものとするが、他の実施形態においては、他のアプリケーション（特定アプリプログラムおよび／または非特定アプリプログラム）が共用データを書き込むことができるようにしてもよい。

登録指令を受け付けると、通信制御部３２は、図７および図８に示すステップＳ１〜Ｓ３，Ｓ１１〜Ｓ１３の一連の処理（登録指令処理）の実行を開始する。図８に示すステップＳ１〜Ｓ３における処理は図６に示す処理と同じである。

登録指令処理においては、ステップＳ３の判定結果が肯定であった場合（タグ２が許可タグである場合）、ステップＳ１１の処理が実行される。一方、ステップＳ３の判定結果が否定であった場合（タグ２が許可タグでない場合）、図６に示すステップＳ４の処理が実行される。

登録指令処理においては、上記ステップＳ４の処理によって、タグ２が許可タグではないことの通知を受け取った場合、アプリケーション部３１は、例えば、タグ２が許可されたものではないためにデータの登録を行うことができない旨をユーザに対して通知する。ステップＳ４の処理の終了後、通信制御部３２は、図８に示す読出指令処理を終了する。

一方、ステップＳ１１において、通信制御部３２は、タグ２が許可タグであることの通知（許可通知）をアプリケーション部３１へ出力する。なお、図７は、許可通知がアプリケーション部３１へ出力される場合の処理を示している。

許可通知を受け取ると、アプリケーション部３１は、タグ２に書き込むべき初期登録データを取得する（図７に示すステップＳ２１）。本実施形態においては、アプリケーション部３１は、アバターデータとニックネームのデータをユーザから受け付けるとともに、登録日時および地域のデータを取得する。具体的には、アプリケーション部３１は、アバターの各部位（目や鼻等）について複数種類の候補を用意しておき、候補から所望の形状をユーザに選択させる。これによって、ユーザの指示に応じたアバターデータを取得することができる。また、ニックネームは、ユーザに所望の文字情報を入力させることで取得することができる。また、現在の日時を示すデータ、および、情報処理装置３が存在する地域（国）を示すデータは情報処理装置３に記憶されているものとし、アプリケーション部３１は、これらのデータを取得する。アプリケーション部３１は、以上のようにして取得した各データを含む初期登録データを、通信制御部３２へ渡す（出力する）。

ステップＳ１２において、通信制御部３２は、初期登録データをアプリケーション部３１から取得する。なお、他の実施形態においては、通信制御部３２は、ユーザによって指定されるデータ（アバターデータおよびニックネームのデータ）をアプリケーション部３１から取得し、情報処理装置３において記憶されているデータ（現在の日時および地域のデータ）を自身で取得するようにしてもよい。

ステップＳ１３において、通信制御部３２は、タグ２に対する書込処理を実行する。本実施形態においては、タグ２に対するデータの書き込みは、タグ２の読み書き可能領域２２に記憶されるデータの全体を一単位として行われる。すなわち、通信制御部３２は、ステップＳ２で読み出した専用データと、ステップＳ２で読み出した共用データに対して初期登録データを追加した新たな共用データと、第２ハッシュ値のデータとをタグ２に書き込む。なお、初期登録データ以外の共用データについては、ステップＳ２で読み出されてメモリ１４に記憶されたデータが用いられる。ここで、初期登録データが追加されることによって、共用データの内容は変更されることになる。したがって、ステップＳ１３において、通信制御部３２は、変更後の共用データ（初期登録データが追加された共用データ）についてハッシュ値を算出する。そして、算出したハッシュ値を新たな第２ハッシュ値としてタグ２に書き込む。ステップＳ１３の処理の後、通信制御部３２は登録指令処理を終了する。

なお、上記においては、タグ２に初期登録データが記憶されていない場合を想定して処理を説明した。なお、タグ２に初期登録データが記憶されている場合も、上記と同様の登録指令書理を実行することで、初期登録データの内容を更新することができる。この場合、ステップＳ１３においては、通信制御部３２は、ステップＳ２で読み出した専用データと、ステップＳ２で読み出した共用データに対して初期登録データを更新した新たな共用データとを、タグ２に書き込むことになる。以上のように、アプリケーション部３１は、タグ２に対して初期登録データを新たに書き込む場合の他、タグ２に登録されている初期登録データを更新する場合にも、登録指令を通信制御部３２へ送るようにしてもよい。

また、他の実施形態においては、通信制御部３２は、読出指令や書込指令に応じてタグ２と近距離無線通信を行う際に、初期登録データを書き込む処理を実行してもよい。例えば、読出指令処理におけるステップＳ２においてタグ２からデータを読み出した場合、通信制御部３２は、初期登録データがタグ２に記憶されているか否かを判定し、初期登録データが記憶されていない場合、アプリケーション部３１に通知を行うようにしてもよい。この通知に応じて、アプリケーション部３１は上記ステップＳ２１の処理を実行し、通信制御部３２は上記ステップＳ１２およびＳ１３の処理を実行してもよい。これによって、通信制御部３２は、読出指令処理において（初期登録データが未登録である場合には）初期登録データをタグ２に書き込むことができる。

（２−３：データ書込時の動作）
次に、図９および図１０を参照して、タグ２に対して専用データ（および更新データ）を書き込む動作について説明する。図９は、タグ２に対して専用データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図である。また、図１０は、書込指令を受けた場合における通信制御部３２の処理（書込指令処理）の流れの一例を示すフローチャートである。

まず、アプリケーション部３１は、通信制御部３２に対してタグ２に対するデータの書込指令を送る（図９および図１０参照）。この書込指令には、上述した読出指令と同様、アプリケーション部３１のアプリケーションプログラムに含まれるフィギュアＩＤが含まれる。

書込指令を受け付けると、通信制御部３２は、図１０に示す一連の処理（書込指令処理）の実行を開始する。ここで、書込指令処理におけるステップＳ１〜Ｓ６の処理は、上述した読出指令処理におけるステップＳ１〜Ｓ６の処理と同様である。このように、本実施形態においては、タグ２からデータを書き込む場合には、まずタグ２から読み出される。そして、詳細は後述するが、読み出されたデータに対して適宜変更が加えられ、変更後のデータがタグ２に書き込まれる。

書込指令処理においては、ステップＳ５の判定結果が否定であった場合（書込指令を行ったアプリケーションプログラムが特定アプリプログラムでない場合）には、ステップＳ３１の処理が実行される。ステップＳ３１において、通信制御部３２は、データの書き込みを行うことができない旨をアプリケーション部３１に通知する。この通知を受け取ったアプリケーション部３１の処理は任意である。例えば、アプリケーション部３１は、接続されたタグ２は、実行中のアプリケーションによってデータの書き込みを行うことができないタグである旨をユーザに通知する処理を実行する。ステップＳ３１の後、通信制御部３２は書込指令処理を終了する。

一方、書込指令処理においては、ステップＳ５の判定結果が肯定であった場合（書込指令を行ったアプリケーションプログラムが特定アプリプログラムである場合）には、ステップＳ６の処理が実行される。すなわち、通信制御部３２は、アプリケーション部３１に対して専用データおよび共用データを渡す（出力する）（図９、図１０参照）。なお、上述のように、ステップＳ６においてアプリケーション部３１に渡されるデータはこれに限らず、例えば、専用データ（セーブデータ）のみが渡されてもよい。また、書込指令処理においては、ステップＳ６の処理に代えて、データの書き込みが許可される旨をアプリケーション部３１へ通知する処理が実行されてもよい。

専用データおよび共用データを受け取ったアプリケーション部３１は、タグ２に書き込むべきデータ（ここでは、セーブデータ）を通信制御部３２へ送る。すなわち、ステップＳ３２において、通信制御部３２は、タグ２に書き込むべきデータをアプリケーション部３１から取得する。

ステップＳ３３において、通信制御部３２は、タグ２に書き込むべき更新データを生成する。上述のように、本実施形態においては、タグ２に専用データ（セーブデータ）が書き込まれる際に更新データが更新される。したがって、通信制御部３２は、書き込み回数、最終書き込み装置、装置変更回数、最終利用アプリ、および、最終書き込み日時のデータを取得（生成）する。具体的には、書き込み回数のデータとして、通信制御部３２は、ステップＳ２で読み出した更新データが示す書き込み回数に１を加えた値を示すデータを生成する。また、情報処理装置３には自機の識別情報が（例えばメモリ１４に）記憶されているので、通信制御部３２は、最終書き込み装置のデータとして、この識別情報のデータを取得する。また、通信制御部３２は、最終利用アプリのデータとして、書込指令を行ったアプリケーションプログラムから、当該アプリケーションプログラムの識別情報（アプリＩＤ）のデータを取得する。また、通信制御部３２は、最終書き込み日時のデータとして、現在の日時の情報を取得する。なお、装置変更回数のデータについては、次のようにして算出される。

図１１は、装置変更回数のカウント方法の一例を示す図である。図１１においては、まず、ユーザが自宅で、ユーザが所有する情報処理装置３ａを用いてタグ２にデータ（セーブデータ）を書き込んだ場合を考える。また、この時点での装置変更回数Ｎは“Ａ”とする。なお、この後、情報処理装置３ａによってタグ２にセーブデータが書き込まれても、装置変更回数Ｎは“Ａ”のままである。

図１１においては、情報処理装置３ａによってタグ２にセーブデータが書き込まれた後、ユーザは、（タグ２を持って移動し、）他の情報処理装置３ｂによってタグ２にセーブデータを書き込んだものとする。なお、他の情報処理装置３ｂは、例えば、ユーザの知人の情報処理装置や、販売促進等の目的で店頭に設置された情報処理装置である。上記他の情報処理装置３ｂによってタブ２にセーブデータが書き込まれる際、装置変更回数Ｎは“Ａ＋１”に更新される。なお、この後、他の情報処理装置３ｂによってタグ２にセーブデータが再度書き込まれても、装置変更回数Ｎは“Ａ＋１”のままである。

図１１においては、さらにその後、ユーザは、（タグ２を持って移動し、）自身の情報処理装置３ａを用いてタグ２にセーブデータを再び書き込んだものとする。この場合、情報処理装置３ａによってセーブデータが書き込まれる際、装置変更回数Ｎは、“Ｎ＝Ａ＋２”に更新される。

以上のように、本実施形態においては、前回にデータ（セーブデータ）の書き込みを行った情報処理装置と、今回にデータ（セーブデータ）の書き込みを行う情報処理装置とが異なる場合、装置変更回数が１加算される。一方、両者が異なる場合、装置変更回数が維持される。

したがって、ステップＳ３３の処理においては、通信制御部３２は、ステップＳ２で読み出した共用データ（更新データ）に含まれる最終書き込み装置の情報が、今回の書込指令を行った情報処理装置３を示すか否かを判定する。すなわち、通信制御部３２は、ステップＳ２で読み出した更新データに含まれる最終書き込み装置の情報と、今回のステップＳ３３で取得した最終書き込み装置の情報とが一致するか否かを判定する。そして、両者が一致する場合、データの書き込みを行う情報処理装置は変更されていないと判断し、装置変更回数を維持する。すなわち、ステップＳ２で読み出した装置変更回数の値をそのまま、タグ２に書き込む装置変更回数の値とする。一方、両者が一致しない場合、データの書き込みを行う情報処理装置が変更されたと判断し、装置変更回数をインクリメントする。すなわち、ステップＳ２で読み出した装置変更回数の値を１加算した値を、タグ２に書き込む装置変更回数の値とする。

本実施形態においては、以上のようにして、更新すべき更新データが取得・生成される。

ステップＳ３４において、通信制御部３２は、タグ２に対する書込処理を実行する。上述のように、本実施形態においては、タグ２に対するデータの書き込みは、タグ２の読み書き可能領域２２に記憶されるデータの全体を一単位として行われる。すなわち、通信制御部３２は、ステップＳ３２でアプリケーション部３１から取得した新たな専用データと、ステップＳ３３で取得した新たな更新データを含む共用データとを、タグ２に書き込む。なお、更新データ以外の共用データについては、ステップＳ２で読み出されてメモリ１４に記憶されたデータが用いられる。ここで、更新データが変更されることによって、共用データの内容は変更されることになる。したがって、ステップＳ３４において、通信制御部３２は、変更後の共用データ（更新データの内容が変更された共用データ）についてハッシュ値を算出する。そして、算出したハッシュ値を新たな第２ハッシュ値としてタグ２に書き込む。ステップＳ３４の処理の後、通信制御部３２は書込指令処理を終了する。

なお、上記のように本実施形態においては、タグ２に専用データが書き込まれることに応じて更新データの更新が行われる。ただし、更新データは任意のタイミングで更新されてもよい。例えば、タグ２に対する読み出しに関する情報が更新データに含まれてもよく（後述する“［４．変形例］”参照）、このとき、タグ２からデータが読み出されるタイミングで更新データが更新されてもよい。すなわち、通信制御部３２は、読出指令処理においてステップＳ６またはＳ７の処理の次に、新たな更新データを生成してタグ２に書き込む処理を実行してもよい。

また、本実施形態においては、通信制御部３２は、タグ２に初期登録データが記憶されているかいなかにかかわらず、タグ２に対する更新データの書き込みを行う。ここで、他の実施形態においては、情報処理装置３（通信制御部３２）は、タグ２に初期登録データが記憶されていることを条件として、タグ２に対する更新データの書き込みを行うようにしてもよい。これによれば、初期登録が行われた時点を基準として更新データ（例えば、書き込み回数等）を記録することができる。

以上のように、本実施形態においては、タグ２に対するデータの書き込みおよび読み出しは、本体データ（専用データおよび共用データ）の全体を一単位として行われるものとする。つまり、タグ２からデータを読み出す場合には、（本体データのうちの一部のみが必要である場合であっても）本体データの全体が読み出される。また、タグ２に対してデータを書き込む（本体データを書き換える）場合には、（本体データの一部のみを書き換える場合であっても）本体データの全体が書き換えられる。

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

（２−４：アプリケーションプログラムによる処理例１）
次に、図１２を参照して、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理の例について説明する。図１２は、アプリケーションプログラムによってＣＰＵ１３が実行する処理の流れの一例を示すフローチャートである。なお、図１２に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開始される。

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

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

ステップＳ４２において、アプリケーション部３１は、タグ２との通信を行うか否かを判定する。すなわち、アプリケーション部３１は、タグ２との通信を行うための所定のゲーム条件が満たされたか否かを判定する。この所定のゲーム条件は、ゲーム状況が、タグ２が表すキャラクタが登場することができる状況になったことであり、例えば、プレイヤキャラクタが所定のステージに進んだことや、プレイヤキャラクタが所定のアイテムを取得したこと等である。なお、ステップＳ４２の処理は、ステップＳ４１におけるゲーム処理が実行される間の適宜のタイミングで実行される。したがって、ステップＳ４２の判定処理の結果が否定となる場合、ステップＳ４１の処理が再度実行され、ステップＳ４２の判定処理の結果が肯定となるまでステップＳ４１およびＳ４２の処理が繰り返し実行される。一方、ステップＳ４２の判定処理の結果が肯定となる場合、後述するステップＳ４３の処理が実行される。

ステップＳ４３において、アプリケーション部３１は、読出指令を出力し、タグ２からデータを読み出す。すなわち、上述したように、アプリケーション部３１はまず、通信制御部３２へ読出指令を出力する（図４等参照）。これに応じて、通信制御部３２はタグ２との通信を行い（ステップＳ１）、タグ２から読み出したデータをアプリケーション部３１へ渡す（ステップＳ２，Ｓ６，Ｓ７）。これによって、アプリケーション部３１はタグ２からのデータを取得する。なお、上述のように、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、専用データおよび共用データが取得され、実行中のアプリケーションプログラムが非特定アプリプログラムである場合には、共用データが取得される。ステップＳ４３においてタグ２からのデータが取得されると、ステップＳ４４の処理が実行される。

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

ステップＳ４４において、アプリケーション部３１は、ステップＳ４３で取得されたフィギュアＩＤが、実行中のアプリケーションにおいて登録されているキャラクタに対応するものであるか否かを判定する。ここで、アプリケーションプログラムには、タグ２によってゲームに登場する各キャラクタを生成するためのデータが含まれている。また、アプリケーションプログラムには、当該各キャラクタのそれぞれに関連付けられたフィギュアＩＤの情報が予め登録されているものとする。ステップＳ４４の判定は、ステップＳ４３で取得されたフィギュアＩＤが、実行中のアプリケーションプログラムにおいて登録されているフィギュアＩＤのいずれかと一致するか否かによって行われる。ステップＳ４４の判定結果が肯定となる場合、後述するステップＳ４６の処理が実行される。一方、ステップＳ４４の判定結果が否定となる場合、後述するステップＳ４５の処理が実行される。

ステップＳ４５において、アプリケーション部３１は、ステップＳ４３で取得されたシリーズＩＤが、実行中のアプリケーションに設定されるシリーズＩＤと一致するか否かを判定する。なお、アプリケーションプログラムには、そのアプリケーションプログラムに設定されるシリーズＩＤの情報が予め登録されているものとする。したがって、アプリケーション部３１は、ステップＳ４３で取得されたシリーズＩＤと、実行中のアプリケーションプログラムにおいて登録されているシリーズＩＤと一致するか否かを判定する。ステップＳ４５の判定において、２つのシリーズＩＤが一致すると判定された場合、タグ２に記憶されているフィギュアＩＤが示すキャラクタは、（アプリケーションプログラムにおいて登録されていないものであるものの）アプリケーションプログラムが属するシリーズにおいて登録されているキャラクタであることがわかる。ステップＳ４５の判定結果が肯定となる場合、後述するステップＳ４６の処理が実行される。一方、ステップＳ４５の判定結果が否定となる場合、後述するステップＳ４７の処理が実行される。

ステップＳ４６において、アプリケーション部３１は、フィギュアＩＤが示すキャラクタを仮想空間に登場させる処理を実行する。ここで、タグ２に記憶されるフィギュアＩＤが表すキャラクタをアプリケーション部３１がわかっている場合（当該フィギュアＩＤがアプリケーションにおいて登録されている場合、すなわち、ステップＳ４４の判定結果が肯定となる場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができる。すなわち、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いて仮想空間内におけるキャラクタを生成する。

一方、タグ２に記憶されるフィギュアＩＤが表すキャラクタをアプリケーション部３１がわかっていない場合（当該フィギュアＩＤがアプリケーションにおいて登録されていない場合、すなわち、ステップＳ４４の判定結果が否定となり、ステップＳ４５の判定結果が肯定となる場合）、アプリケーション部３１は、自身のアプリケーションプログラム内の情報を用いてキャラクタを仮想空間に登場させることができない。そのため、上記の場合、アプリケーション部３１は、タグ２から取得したフィギュアＩＤを用いて当該フィギュアＩＤが示すキャラクタを特定し、特定したキャラクタを仮想空間に登場させる。例えば、アプリケーション部３１は、外部のサーバにアクセスして、タグ２から取得したフィギュアＩＤをサーバへ送信し、これに応じてサーバから送信されてくるキャラクタのデータ（キャラクタを生成するためのデータ）を受信する。また、実行中のアプリケーションプログラムが特定アプリプログラムである場合には、キャラクタを生成するためのデータをセーブデータに含めておき、アプリケーション部３１は、セーブデータを用いてキャラクタを生成してもよい。

なお、ステップＳ４６における、キャラクタを仮想空間に登場させる処理は、実行中のアプリケーションプログラムが特定アプリプログラムである場合と非特定アプリプログラムである場合とで異なっていてもよい。例えば、アプリケーション部３１は、特定アプリプログラムの場合、タグ２が表すキャラクタの全体を（キャラクタをそのまま）表示部１７に表示するのに対して、非特定アプリプログラムの場合、当該キャラクタの一部のみを表示する（例えば、タグ２が表すキャラクタの帽子や服装を他のキャラクタに付ける）ようにしてもよい。また例えば、アプリケーション部３１は、特定アプリプログラムの場合、タグ２が表すキャラクタを通常の表示態様で表示部１７に表示するのに対して、非特定アプリプログラムの場合、当該キャラクタを当該通常の表示態様とは異なる表示態様で（例えば、キャラクタを２頭身にして）表示するようにしてもよい。

一方、ステップＳ４７において、アプリケーション部３１は、タグ２が、実行中のアプリケーションにおいて利用できない（対応していない）タグであることをユーザに通知する。

上記ステップＳ４６またはＳ４７の後、アプリケーション部３１はステップＳ１の処理を再度実行する。以降、ゲームを終了する条件（例えば、ゲームを終了する指示をユーザが行ったこと）が満たされるまで、図１２に示す一連の処理が実行される。

（２−５：アプリケーションプログラムによる処理例２）
次に、図１３〜図１７を参照して、アプリケーションプログラムによって情報処理装置３のＣＰＵ１３（アプリケーション部３１）が実行する処理の他の例について説明する。図１３は、タグ２に関する特定アプリプログラムによってＣＰＵ１３が実行する処理（特定アプリ処理）の流れの一例を示すフローチャートである。また、図１６は、タグ２に関する特定アプリプログラムとは異なる他のアプリケーションプログラムによってＣＰＵ１３が実行する処理（他アプリ処理）の流れの一例を示すフローチャートである。以下では、単一のタグ２を、特定アプリプログラムによるゲームに用いる場合と、他のアプリケーションプログラムに用いる場合とにおける処理例について説明する。なお、図１３および図１６に示す処理は、例えば、ユーザがアプリケーションの起動指示を行ったことに応じて開始される。

まず、図１３〜図１５を参照して、特定アプリ処理について説明する。特定アプリ処理においては、まずステップＳ５１において、アプリケーション部３１は、キャラクタ設定画面を表示部１７に表示する。キャラクタ設定画面は、ユーザ（プレイヤ）が操作するプレイヤキャラクタを設定するためのものである。詳細は後述するが、特定アプリ処理では、プレイヤのアバターとプレイヤキャラクタとの組がキャラクタ設定画面において表示される（図１４参照）。

ここで、図１３に示す特定アプリ処理では、タグを用いてプレイヤキャラクタの指定が行われる。すなわち、キャラクタ設定画面が表示される状態において、ユーザは、自身が操作したいキャラクタのタグを情報処理装置３（のアンテナ部分）にかざして、当該タグと情報処理装置３との間で近距離無線通信を行わせる。なお、上記タグについては初期登録処理が実行済みであり、ユーザのアバターデータが記憶されているものとする。タグとの近距離無線通信が可能になると、情報処理装置３は、タグからデータを読み出し、タグから読み出したアバターデータに対応するユーザをプレイヤとして設定するとともに、当該プレイヤのプレイヤキャラクタとして、タグのキャラクタを設定する。これによって、プレイヤとプレイヤキャラクタとの組が設定される。本実施形態における特定アプリ処理においては、上記のプレイヤとプレイヤキャラクタとの組を設定する処理が、ステップＳ５２〜Ｓ５３によって行われる。

具体的には、ステップＳ５２において、アプリケーション部３１は、タグからデータを読み出す処理を実行する。この処理は、上記図４〜図６に示した処理と同様である。すなわち、アプリケーション部３１は読出指令を通信制御部３２に渡す。これに応じて、通信制御部３２がタグとの通信処理等（ステップＳ１〜Ｓ３，Ｓ５）を行って、共用データ・専用データをアプリケーション部３１に渡す。これによって、アプリケーション部３１はタグからデータを取得する（読み出す）ことができる。

ステップＳ５３において、アプリケーション部３１は、プレイヤとプレイヤキャラクタとの組を設定する。具体的には、アプリケーション部３１は、ステップＳ５２で読み出したデータのうちのアバターデータに基づいてプレイヤを設定する。すなわち、プレイヤを特定するデータとして当該アバターデータがメモリ１４に記憶される。また、アプリケーション部３１は、ステップＳ５２で読み出したデータのうちのフィギュアＩＤに基づいてプレイヤキャラクタを設定する。すなわち、設定されたプレイヤに対応するプレイヤキャラクタを示すデータとして、読み出したデータのうちのフィギュアＩＤのデータがメモリ１４に記憶される。さらに、アプリケーション部３１は、設定されたプレイヤとプレイヤキャラクタとの組を、キャラクタ設定画面において表示する。

図１４は、特定アプリ処理におけるキャラクタ設定画面の一例を示す図である。図１４に示すように、キャラクタ設定画面においては、プレイヤのアバターの画像４１と、プレイヤキャラクタの画像４２とが関連付けて表示される。なお、図１４は、上述したタグ２を用いて１人目のプレイヤとそのプレイヤキャラクタとが設定された状態におけるキャラクタ設定画面を示している。したがって、アバターの画像４１およびプレイヤキャラクタの画像４２は、１人目のプレイヤの欄に表示される（２人目以降のプレイヤの欄は空欄である）。なお、図１３に示す特定アプリ処理によるゲームは、最大４人のプレイヤがプレイ可能であるものとする。そのため、キャラクタ設定画面には４人分のプレイヤの欄が設定されている。

アバターの画像４１は、タグ２から読み出されたアバターデータを用いて生成される。上述したように、アバター（の画像）の生成は、情報処理装置３において予め用意されているアバター生成プログラムをＣＰＵ１３が実行することによって行われる。なお、本実施形態においては、アバターデータおよびアバター生成プログラムを用いることによってアバターの全身を表示することが可能である。ただし、特定アプリ処理においては、アバターの一部（顔）の画像が表示される。また、図１４では、プレイヤの名前（図１４では「たろう」）がアバターの画像４１とともに表示される。例えば、表示される名前は、アバターデータにユーザの名前を示すデータが含まれる場合には当該データが示す名前であってもよい。また、他の実施形態においては、表示される名前は、初期登録データに含まれる上述のニックネームであってもよい。

ステップＳ５４において、アプリケーション部３１は、プレイヤキャラクタの設定を終了するか否かを判定する。例えば、設定可能な最大数（ここでは４つ）のプレイヤキャラクタが設定された場合、あるいは、ユーザがゲーム開始の指示を行った場合、アプリケーション部３１は設定を終了すると判定する。一方、最大数のプレイヤキャラクタが設定されておらず、かつ、ゲーム開始の指示が行われていない場合、アプリケーション部３１は設定を終了しないと判定する。ステップＳ５４の判定結果が否定である場合、ステップＳ５２の処理が再度実行される。この場合、プレイヤキャラクタをすでに設定したプレイヤとは別のプレイヤが自分のタグを情報処理装置３にかざすと、ステップＳ５２およびＳ５３の処理によって、新たなプレイヤとプレイヤキャラクタとの組が設定される。一方、ステップＳ５４の判定結果が肯定である場合、ステップＳ５５の処理が実行される。

ステップＳ５５において、アプリケーション部３１は、ゲーム処理を実行する。このゲーム処理によるゲームの内容は任意である。本実施形態においては、ゲーム中においても、プレイヤ（プレイヤのアバター）とプレイヤキャラクタとの対応関係が表示される。図１５は、特定アプリ処理によって表示部１７に表示されるゲーム画像の一例を示す図である。図１５に示すゲーム画像は、２人のプレイヤがゲームをプレイする場合を示している。すなわち、上記ゲーム画像においては、第１のプレイヤキャラクタ４３と、第２のプレイヤキャラクタ４４が登場するゲーム空間が表示されている。また、上記ゲーム画像には、プレイヤ（のアバター）とプレイヤキャラクタとの組を示す画像４５および４６が含まれる。なお、図１５は、表示部１７に表示されるゲーム画像を示すとともに、拡大した画像４５を示している。この画像４５はアバターの画像４６とプレイヤキャラクタの画像４７とを含み、アバターの画像４６とプレイヤキャラクタの画像４７とが関連付けて表示される。また、画像４５および４６のように、プレイヤとプレイヤキャラクタとの各組について、アバターの画像とプレイヤキャラクタの画像とが関連付けて表示される。

上記ゲーム処理は、ゲームを終了する条件（例えば、ゲームを終了する指示をユーザが行ったこと）が満たされるまで実行され、当該条件が満たされると、アプリケーション部３１は、ゲーム処理を終了して、特定アプリ処理を終了する。

上記特定アプリ処理によれば、ユーザは、情報処理装置３に対してタグ２をかざす操作によって、ゲームにおけるプレイヤキャラクタを容易に設定することができる。また、上記特定アプリ処理では、プレイヤキャラクタとプレイヤ（のアバター）とが関連付けて表示される（図１４および図１５参照）。これによって、各プレイヤは、自身の操作するプレイヤキャラクタを容易に認識することができる。

次に、図１６および図１７を参照して、他アプリ処理について説明する。他アプリ処理においては、まずステップＳ６１において、アプリケーション部３１は、キャラクタ設定画面を表示部１７に表示する。詳細は後述するが、他アプリ処理では、プレイヤのアバターがプレイヤキャラクタとして設定され、当該アバターの画像がキャラクタ設定画面において表示される（図１７参照）。

図１６に示す他アプリ処理では、上記特定アプリ処理と同様、タグを用いてプレイヤキャラクタの指定が行われる。すなわち、キャラクタ設定画面が表示される状態において、ユーザは、自身のアバターのデータが記憶されているタグを情報処理装置３（のアンテナ部分）にかざして、当該タグと情報処理装置３との間で近距離無線通信を行わせる。タグとの近距離無線通信が可能になると、情報処理装置３は、タグからデータを読み出し、タグから読み出したアバターデータを用いてアバターを生成して、プレイヤキャラクタとして設定する。本実施形態における他アプリ処理においては、上記のプレイヤキャラクタを設定する処理が、ステップＳ６２〜Ｓ６３によって行われる。

ステップＳ６２において、アプリケーション部３１は、タグからデータを読み出す処理を実行する。ステップＳ６２の処理は、上記ステップＳ５２と同様である。

ステップＳ６３において、アプリケーション部３１は、ステップＳ６２で読み出したアバターデータに基づいてプレイヤキャラクタを設定する。具体的には、アプリケーション部３１は、読み出したアバターデータから、アバターを識別する情報（例えば、アバターの名前）を取得し、アバターを識別する情報を、プレイヤキャラクタを示すデータとしてメモリ１４に記憶する。また、アプリケーション部３１は、設定されたプレイヤキャラクタをキャラクタ設定画面において表示する。

図１７は、他アプリ処理におけるキャラクタ設定画面の一例を示す図である。図１７に示すように、キャラクタ設定画面においては、プレイヤキャラクタとなる、プレイヤのアバターの画像５０が表示される。なお、図１７は、上述したタグ２を用いて１人目のプレイヤのプレイヤキャラクタが設定された状態におけるキャラクタ設定画面を示している。したがって、アバターの画像５０は、１人目のプレイヤの欄に表示される（２人目以降のプレイヤの欄は空欄である）。なお、図１６に示す他アプリ処理によるゲームは、最大４人のプレイヤがプレイ可能であるものとする。そのため、キャラクタ設定画面には４人分のプレイヤの欄が設定されている。

アバターの画像５０は、特定アプリ処理の場合と同様、タグ２から読み出されたアバターデータを用いて、情報処理装置３において予め用意されているアバター生成プログラムを実行することによって、生成される。なお、他アプリ処理においては、特定アプリ処理とは異なる表示態様でアバターが表示される。すなわち、他アプリ処理においては、アバターの全身が生成されて表示される。また、他アプリ処理においても特定アプリ処理と同様、プレイヤの名前（図１７では「たろう」）がアバターの画像５０とともに表示される。

ステップＳ６４において、アプリケーション部３１は、プレイヤキャラクタの設定を終了するか否かを判定する。ステップＳ６４の判定は、上記ステップＳ５４の判定と同様の方法で行われてもよい。ステップＳ６４の判定結果が否定である場合、ステップＳ６２の処理が再度実行される。この場合、プレイヤキャラクタをすでに設定したプレイヤとは別のプレイヤが自分のタグを情報処理装置３にかざすと、ステップＳ６２およびＳ６３の処理によって、新たなプレイヤのプレイヤキャラクタが設定される。一方、ステップＳ６４の判定結果が肯定である場合、ステップＳ６５の処理が実行される。

ステップＳ６５において、アプリケーション部３１は、ゲーム処理を実行する。このゲーム処理によるゲームの内容は任意である。本実施形態においては、ゲーム中において、アバターであるプレイヤキャラクタが登場し、プレイヤによる操作に従って制御される。上記ゲーム処理は、ゲームを終了する条件（例えば、ゲームを終了する指示をユーザが行ったこと）が満たされるまで実行され、当該条件が満たされると、アプリケーション部３１は、ゲーム処理を終了して、他アプリ処理を終了する。

なお、他の実施形態においては、他アプリ処理においても特定アプリ処理と同様に、アプリケーション部３１は、タグ２が表すキャラクタと、当該タグ２に記憶されているアバターデータ（プレイヤ情報）とを関連付けて表示してもよい。例えば、アプリケーション部３１は、タグ２のキャラクタの服装をしたアバターを、プレイヤキャラクタとして登場させてもよい。また例えば、タグ２がアイテムを表す外観である場合、アバターをプレイヤキャラクタとして登場させるとともに、タグ２が表すアイテムを当該プレイヤキャラクタに持たせるようにしてもよい。

上記他アプリ処理によれば、ユーザは、情報処理装置３に対してタグ２をかざす操作によって、ゲームにおけるプレイヤキャラクタの設定（より具体的には、自身のアバターをプレイヤキャラクタとする設定）を容易に行うことができる。アバターをプレイヤキャラクタとすることによって、各プレイヤは、自身の操作するプレイヤキャラクタを容易に認識することができる。また、本実施形態における他アプリ処理によれば、単一のタグ２を用いて特定アプリ処理とは異なるプレイヤキャラクタを登場させることができる。

なお、他の実施形態においては、１つのアプリケーションプログラム（特定アプリプログラムであってもよいし、そうでなくてもよい）において、タグが表すキャラクタをゲーム空間に登場させるとともに、アバターをゲーム空間に登場させるようにしてもよい。例えば、キャラクタを表す第１タグと、アバターを表す第２タグとが用意されている場合を考える。なお、第２タグは、特定のアバターを表すものではなく、例えば顔と体の輪郭のみを表し、細かい部位（目や鼻や口）が無いような、アバターの概観を表すものである。また、第２タグには、アバターデータが記憶されるとともに、アバターであることを示す情報（ゲーム空間に登場させるキャラクタがアバターであることを示す情報）がフィギュアＩＤとして記憶されているものとする。このとき、第１タグと情報処理装置３との間で近距離無線通信が行われて、第１タグを用いてアプリケーションが実行される場合には、情報処理装置３は、第１タグが表すキャラクタを仮想空間に（例えばプレイヤキャラクタとして）登場させる。一方、第２タグと情報処理装置３との間で近距離無線通信が行われて、第２タグを用いてアプリケーションが実行される場合には、情報処理装置３は、第２タグに記憶されるアバターデータを用いてアバターを生成し、当該アバターを仮想空間に（例えばプレイヤキャラクタとして）登場させる。なお、上記において、アプリケーションプログラムは、上記第２タグのみに対応し、第１タグには対応しない（第１タグが表すキャラクタは登場しない）ものであってもよい。

また、本実施形態のようにタグ２にアバターデータを記憶することによって、タグ２を用いて（タグ２を介して）情報処理装置間でアバターデータを移動する（単なるデータの移動であってもよいし、データの複製であってもよいし、データの交換であってもよい）ことができる。すなわち、ある情報処理装置によってタグ２にアバターデータが記憶された（上述の登録指令処理を参照）後、他の情報処理装置は、近距離無線通信によってタグ２からデータを読み出すことによって、アバターデータを取得することができる。例えば、ユーザは、自分のタグにアバターデータを記憶させておき、友人の家に行った際に友人の情報処理装置に自分のタグからデータを取得させることで、自分のアバターデータを友人の情報処理装置に記憶させることができる。

なお、アバターデータ等のユーザに関するデータの情報処理装置間での移動は、上記のタグ２を用いる方法に加えて（または代えて）、他の方法で行われてもよい。例えば、インターネット等のネットワークを介したネットワーク通信を行うネットワーク通信部を各情報処理装置が備える場合には、ネットワーク通信によって情報処理装置間でデータが送受信されてもよい。また、情報処理装置が、赤外通信やＢｌｕｅｔｏｏｔｈ（登録商標）等の無線通信を行う無線通信部を各情報処理装置が備える場合には、当該無線通信によって情報処理装置間で直接データが送受信されてもよい。また、情報処理装置間で上述の近距離無線通信が可能である場合には、近距離無線通信によって情報処理装置間でデータが送受信されてもよい。また、データを取得する側の情報処理装置がカメラ（２次元バーコードを読み取る手段）を有する場合には、２次元バーコードを用いて情報処理装置間でデータが送受信されてもよい。すなわち、アバターデータを表す２次元バーコードを一方の情報処理装置が生成し、他方の情報処理装置は当該２次元バーコードを読み取ることによってアバターデータを取得してもよい。なお、上記実施形態のようなタグを用いた方法によれば、ユーザは、情報処理装置にタグをかざすという簡易な操作でデータの移動を行うことができる。

［３．本実施形態の作用効果］
以上のように、本実施形態においては、タグ２は、特定アプリプログラムで利用可能なアプリ用データ（専用データ）と、当該特定アプリプログラムであるか否かにかかわらず利用可能な共用データとを記憶する記憶手段を備える。通信制御部３２は、情報処理装置３で実行されるアプリケーションプログラムから、タグ２に対するデータの読み出しおよび／または書き込みに関する指令を受け付ける。受け付けられた指令が専用データに関する指令（例えば専用データを読み出す指令）である場合、通信制御部３２は、当該指令が特定アプリプログラムからの指令であることを条件として（ステップＳ５でＹｅｓ）、タグ２から読み出した専用データを当該特定アプリプログラムに渡す（ステップＳ６）。また、受け付けられた指令が共用データに関する指令（例えば共用データを読み出す指令）である場合、当該指令が特定アプリプログラムからの指令であるか否かにかかわらず、通信制御部３２は、タグ２から読み出した共用データを指令元のアプリケーションプログラムに渡す（ステップＳ６，Ｓ７）。

したがって、本実施形態によれば、専用データを特定アプリプログラムで利用するためにタグ２を用いることができるとともに、特定アプリプログラムに制限されない他のアプリケーションプログラムにおいて共用データを利用するためにタグ２を用いることができる。これによって、タグ２を利用可能なアプリケーションを増やすことができ、タグ２を汎用的に利用することができる。また、特定アプリプログラム以外の他のアプリケーションプログラムにおいても共用データを利用できるようにする一方、専用データについては当該他のアプリケーションプログラムでの利用を制限することができる。そのため、専用データが当該アプリケーションプログラムにおいて不正に利用されることを防止することができる。

また、本実施形態においては、タグ２は、タグの種類毎に設定される識別情報（フィギュアＩＤ）を記憶している。また、特定アプリプログラムは、自身が専用データを利用可能な種類のタグに設定されるフィギュアＩＤを含んでいる。通信制御部３２は、タグ２から読み出したフィギュアＩＤと、アプリケーションプログラムから取得したフィギュアＩＤとに基づいて、受け付けられた指令が特定アプリプログラムからの指令であるか否かを判定する。これによれば、受け付けられた指令が特定アプリプログラムからの指令であるか否かを容易に判定することができる。

なお、フィギュアＩＤを用いて上記判定を行う場合、特定アプリプログラムは、利用可能なタグのうちから、所定の種類のタグに制限してアクセスを行うことも可能である。すなわち、特定アプリプログラムは、利用可能な全てのタグのフィギュアＩＤを通信制御部３２に送ることによって、利用可能な任意のタグとのアクセスを可能とすることができる。一方、特定アプリプログラムは、利用可能な各タグのフィギュアＩＤのうちで一部のフィギュアＩＤを通信制御部３２に送ることによって、利用可能なタグのうちから、アクセス可能なタグを制限することができる。このように、フィギュアＩＤを用いて特定アプリ判定処理を実行する場合には、指令元のアプリケーションプログラムが特定アプリプログラムであるか否かを判定することに加え、情報処理装置３に接続されたタグが、特定アプリプログラムによってアクセスが許可されたタグであるか否かを判定することも可能である。

本実施形態においては、タグ２は、所定のアプリケーションプログラム（特定アプリプログラム）に登場するオブジェクト（キャラクタ）に関するデータであって、当該所定のアプリケーションプログラムであるか否かにかかわらず利用可能な共用データを記憶する。そして、情報処理装置３は、特定アプリプログラムを実行する際に、タグ２から読み出した共用データを用いることによって、表示部１７にオブジェクトを表示する第１処理（キャラクタの全体を表示する処理）を実行する（ステップＳ４６）。また、情報処理装置３は、特定アプリプログラムとは異なるアプリケーションプログラム（非特定アプリプログラム）を実行する際に、タグ２から読み出した共用データを用いることによって、第１処理とは異なる第２処理（上記キャラクタの服を着た他のキャラクタを表示する処理）を実行する（ステップＳ４６）。

上記によれば、所定のアプリケーションプログラムに制限されることなく、他のアプリケーションプログラムにおいても、共用データを利用するためにタグ２を用いることができる。これによって、タグ２を利用可能なアプリケーションを増やすことができ、タグ２を汎用的に利用することができる。

なお、上記第１処理および第２処理は、オブジェクトを表示する処理に限らず、オブジェクトに関する情報を出力する任意の処理であってもよい。オブジェクトに関する情報とは、例えば、オブジェクトを表す画像であってもよいし、オブジェクトに関する音声（キャラクタの声やテーマ曲）であってもよい。例えば、タグ２が表すキャラクタにテーマ曲が設定されている場合、第１処理および／または第２処理は、当該テーマ曲を（例えばＢＧＭとして）スピーカから出力する処理であってもよい。

また、通信制御部３２は、あるタグとの間で近距離無線通信が可能となった場合、そのタグが情報処理装置３で実行されるアプリケーションプログラムからのアクセスが許可される許可タグであるか否かを判定する（ステップＳ３）。そして、通信制御部３２は、近距離無線通信が可能となったタグが許可タグであると判定された場合、情報処理装置で実行されるアプリケーションプログラムからの指令（読出指令等）に応じた処理を実行する（ステップＳ６，Ｓ７）。換言すれば、通信制御部３２は、近距離無線通信が可能となったタグが許可タグであると判定されたことを条件として、情報処理装置３で実行されるアプリケーションプログラムにおける共用データの利用を許可する。これによれば、許可タグについては、所定のアプリケーションプログラム以外の他のアプリケーションプログラムでもタグのデータを利用できる一方、当該他のアプリケーションが、許可タグでないタグからデータを読み出すことを防止することができる。

なお、本実施形態においては、情報処理装置３は、上記第２処理として、上記第１処理によって表示されるオブジェクト（キャラクタ）の表示態様とは異なる表示態様で当該オブジェクトを表示する（例えば、オブジェクトの一部のみを表示したり、オブジェクトを２頭身で表示したりする）処理を実行する（ステップＳ４６）。これによればアプリケーションに合わせた表示態様でオブジェクトを表示することができるので、タグの汎用性（タグに記憶されるデータの汎用性）をより向上することができる。

なお、他の実施形態においては、情報処理装置３は、上記所定のアプリケーションプログラムとは異なるゲームアプリケーションプログラム（非特定アプリプログラム）を実行する際に、上記第２処理として、ゲームの進行に影響を与えない処理を実行してもよい。例えば、上記実施形態においても述べたように、情報処理装置３は、タグ２とは異なるキャラクタの見た目のみを変化させ（例えば服装を変化させ）、ゲームの進行に影響を与えるゲームパラメータ（例えばキャラクタの強さのパラメータ等）については変化させない処理を実行してもよい。このように、上記第２処理は、上記第１処理に比べて共用データが補助的に使用されてもよい。これによれば、アプリケーションプログラムの開発者にとっては第２処理における共用データの利用を図りやすくなるので、ひいてはタグの汎用性を向上する結果に繋がる。

本実施形態においては、タグ２は、情報処理装置３が所定のアプリケーションプログラム（特定アプリプログラム）を実行することによって生成される仮想空間に登場するオブジェクト（キャラクタ）を立体的（平面的でもよい）に表す外観を有する（図２）。また、タグ２は、上記オブジェクトの第１識別情報（フィギュアＩＤ）と、当該オブジェクトが属するグループの第２識別情報（シリーズＩＤ）とを記憶する。ここで、情報処理装置３は、タグ２から読み出したフィギュアＩＤを用いて所定の処理（フィギュアＩＤが示すキャラクタを表示する処理（ステップＳ４６））を実行するとともに、タグ２から読み出したシリーズＩＤを用いて当該所定の処理を実行する。

上記によれば、情報処理装置３で実行されるアプリケーションは、フィギュアＩＤを用いても、シリーズＩＤを用いても、上記所定の処理を実行することができる。すなわち、例えばフィギュアＩＤを用いることができない（フィギュアＩＤが登録されていない）場合であっても、（シリーズＩＤが登録されていれば）シリーズＩＤを用いて所定の処理を実行することができる。このように、本実施形態によれば、アプリケーションが所定の処理を実行しやすくすることができ、タグをより多くのアプリケーションで用いやすくすることができるので、汎用性の高いタグを提供することができる。

なお、情報処理装置３は、アプリケーションプログラムの実行中において、タグ２から読み出されたフィギュアＩＤが、実行中のアプリケーションプログラムにおいて登録された値であるか否かを判定する（ステップＳ４４）。また、情報処理装置３は、タグ２から読み出されたシリーズＩＤが、実行中のアプリケーションプログラムにおいて登録された値であるか否かを判定する（ステップＳ４５）。そして、上記所定の処理（ステップＳ４６）は、タグ２から読み出されたフィギュアＩＤおよびシリーズＩＤの少なくともいずれかが、実行中のアプリケーションプログラムにおいて登録された値である場合に実行される（図１２）。これによれば、フィギュアＩＤおよびシリーズＩＤのいずれかがアプリケーションプログラムにおいて登録されていれば、アプリケーションプログラムは所定の処理を実行することができる。これによって、タグをより多くのアプリケーションで用いやすくすることができ、汎用性の高いタグを提供することができる。

また、本実施形態においては、上記所定の処理は、オブジェクト（キャラクタ）に関する処理である。ここで、情報処理装置３は、タグ２から読み出されたフィギュアＩＤが、実行中のアプリケーションプログラムにおいて登録された値である場合、当該フィギュアＩＤを用いてオブジェクトを特定する（ステップＳ４６）。また、情報処理装置３は、
タグ２から読み出されたフィギュアＩＤが、実行中のアプリケーションプログラムにおいて登録された値ではなく（ステップＳ４４：Ｎｏ）、かつ、タグ２から読み出されたシリーズＩＤが、実行中のアプリケーションプログラムにおいて登録された値である場合（ステップＳ４５：Ｙｅｓ）、当該シリーズＩＤを用いてオブジェクトを特定する。これによれば、フィギュアＩＤを用いることができない場合であってもシリーズＩＤを用いてオブジェクトを特定することができ、オブジェクトに関する所定の処理を実行することができる。

（図１３および図１６に示すアプリ処理に関する作用効果）
また、本実施形態においては、タグ２は、自身の外観が表すオブジェクトに関するオブジェクト情報（フィギュアＩＤ等）を記憶している。また、情報処理装置３は、ユーザの指示に基づき作成されたキャラクタ（アバター）の画像を特定するキャラクタ画像情報（アバターデータ）をタグ２に書き込む（ステップＳ１３）。さらに、情報処理装置３は、タグ２から読み出したオブジェクト情報とキャラクタ画像情報との少なくともいずれかを用いて所定の処理（ステップＳ５３，Ｓ５５，Ｓ６３，またはＳ６５のゲーム処理）を実行する。

上記によれば、あるオブジェクトの外観を有するタグに、ユーザのアバターの画像を特定する情報を書き込むことができる。そして、当該オブジェクトに関する情報とアバターの情報とを用いた処理が実行される。これによれば、オブジェクトに関する情報を有するタグをより多くの用途に利用することができ、タグをより汎用的に利用することができる。例えば、タグが表すオブジェクトをプレイヤキャラクタとして用いる場合に、そのプレイヤキャラクタを操作するプレイヤのアバターをプレイヤキャラクタとともに表示したり（図１４、図１５参照）、プレイヤのアバターをプレイヤキャラクタとして用いたりする（図１７）ことが可能になる。

なお、本実施形態においては、上記所定の処理は、特定アプリプログラムが実行されることによって行われる処理であった。ここで、他の実施形態においては、上記所定の処理は、特定アプリプログラム以外の他のアプリケーションプログラムが実行されることによって行われてもよい。また、所定の処理は、オブジェクト情報とキャラクタ画像情報との両方を用いた処理であってもよい。また、情報処理装置は、（タグから読み出した）オブジェクト情報を用いる第１処理と、（タグから読み出した）キャラクタ画像情報を用いる処理とを実行する第２処理とを実行してもよい。

なお、「仮想空間に登場するオブジェクトを表す外観を有するタグ」とは、仮想空間に登場する１つのオブジェクトを詳細に表すタグに限らず、仮想空間に登場するオブジェクトの概観を表すタグであってもよい。つまり、「仮想空間に登場するオブジェクトを表す外観を有するタグ」とは、他のオブジェクトとの区別がつく程度にオブジェクトを表す外観を有していてもよい。例えば、上述したアバターを表す第２タグは、特定のアバターではなく、アバターの概観を表すものである。つまり、第２タグは、アバターデータが表す各部位を正確に表すものではなく、例えば、顔および体の輪郭のみで目や鼻や口が無い外観を有していてもよい。あるいは、第２タグは、予め定められた標準の形状である各部位を表す外観を有していてもよい。このとき、第２タグは、アバターデータに基づいて生成されるアバターとは正確には一致しないが、アバターの概観を表すものと言える。「仮想空間に登場するオブジェクトを表す外観を有するタグ」の概念には、このような第２タグも含まれる。

また、上記実施形態においては、情報処理装置３は、上記所定の処理として、オブジェクト（プレイヤキャラクタ）の少なくとも一部とキャラクタ（アバター）の少なくとも一部とを関連付けて表示装置に表示させる処理を実行する（ステップＳ５３，Ｓ５５）。これによれば、タグに記憶されているオブジェクトとユーザ（のキャラクタ）との関係をわかりやすく提示することができる。なお、上記処理は、図１４に示すような、キャラクタ設定画面においてプレイヤキャラクタとアバターとを関連付けて表示する処理であってもよいし、ゲーム中においてプレイヤキャラクタとアバターとを関連付けて表示する処理であってもよい。また、上記処理は、アバターをプレイヤキャラクタとする場合において、タグが表すオブジェクトの服装をしたプレイヤキャラクタを登場させたり、タグが表すアイテムを持ったプレイヤキャラクタを登場させたりする処理であってもよい。

なお、上記実施形態においては、タグが表すオブジェクトが、ユーザにより操作されるプレイヤキャラクタであり、ユーザの指示に基づき作成されたキャラクタが、プレイヤキャラクタを操作するユーザに対応するキャラクタである。これによれば、例えばプレイヤとプレイヤキャラクタとの組を設定する操作をタグによって行うことができる等、タグをより汎用的に利用することができる。

また、上記実施形態においては、キャラクタ画像情報は、ユーザのアバターの画像を特定する情報（アバターデータ）である。より具体的には、アバターの画像を特定する情報は、当該アバターを構成する各部位の画像を特定する情報である。これによれば、情報処理装置は、当該情報に基づいてアバターを容易に生成することができる。

また、上記実施形態においては、情報処理装置３は所定のアプリケーションプログラム（特定アプリプログラム）を実行することによって、タグから読み出したオブジェクト情報を用いて仮想空間（ゲーム空間）にオブジェクトを登場させる登場処理を実行する（ステップＳ５５）。これによれば、タグが表す現実のオブジェクトがあたかも仮想空間に入り込んで登場したかのような感覚をユーザに体験させることができ、アプリケーションの興趣性を向上することができる。

さらに、情報処理装置は、上記所定のアプリケーションプログラム（特定アプリプログラム）とは異なる他のアプリケーションプログラムを実行することによって、タグから読み出したキャラクタ画像情報（アバターデータ）を用いて仮想空間にキャラクタ（アバター）を登場させる（ステップＳ６５）。これによれば、タグに記憶されたユーザのキャラクタ（アバター）を仮想空間に登場させることができ、アプリケーションの興趣性を向上することができる。また、単一のタグを用いて、所定のアプリケーションプログラムと他のアプリケーションプログラムとで異なるキャラクタを仮想空間に登場させることができる。

また、上記実施形態においては、タグ２は、自身の外観が表すオブジェクトに関するオブジェクト情報（フィギュアＩＤ等）と、ユーザに関するユーザ情報（アバターデータ）とを記憶している。情報処理装置３は、タグ２から読み出したオブジェクト情報とユーザ情報とを用いて、オブジェクトとそれに対応するユーザを示す情報とを関連付けて表示装置に表示させる（ステップＳ５３，Ｓ５５）。これによれば、タグに記憶されているオブジェクトとユーザ（のキャラクタ）との関係をわかりやすく提示することができる。

なお、上記実施形態においては、ユーザ情報は、タグ２の外観が表すオブジェクトとは異なるキャラクタであって、ユーザに対応するキャラクタ（アバター）を特定する情報である。また、情報処理装置は、所定のアプリケーションプログラム（特定アプリプログラム）とは異なる他のアプリケーションプログラムを実行することによって、タグ２から読み出したユーザ情報によって特定されるキャラクタ（アバター）を仮想空間に登場させる（ステップＳ６５）。これによれば、タグに記憶されたユーザのキャラクタ（アバター）を仮想空間に登場させることができ、アプリケーションの興趣性を向上することができる。また、単一のタグを用いて、所定のアプリケーションプログラムと他のアプリケーションプログラムとで異なるキャラクタを仮想空間に登場させることができる。

なお、上記ユーザ情報は、ユーザを示す任意の情報でよく、上記実施形態におけるアバターデータに限らず、例えば、ユーザの名前やニックネームやＩＤ等であってもよい。

［４．変形例］
（特定アプリ判定処理の変形例）
上記実施形態においては、特定アプリ判定処理における判定は、フィギュアＩＤを用いて行われた。ここで、他の実施形態においては、上記判定は、上述の利用ＩＤを用いて行われてもよい。以下、利用ＩＤを用いて特定アプリ判定処理を行う変形例について説明する。

本変形例では、まず、アプリケーション部３１は、タグ２の専用データに関する読み書きを行う場合、指令（読出指令や書込指令等）に利用ＩＤを含めて通信制御部３２に送る。つまり、アプリケーションプログラムには、自身に設定される利用ＩＤの情報が含まれており、アプリケーション部３１が通信制御部３２に対する指令を行う際には、利用ＩＤを含む指令を通信制御部３２へ渡す（出力する）。これによって、通信制御部３２はアプリケーションプログラムの利用ＩＤを取得することができる。なお、アプリケーション部３１が利用ＩＤを通信制御部３２へ送るタイミングは任意である。例えば、他の実施形態においては、特定アプリ判定処理において通信制御部３２が利用ＩＤをアプリケーション部３１に対して要求し、この要求に応じてアプリケーション部３１が利用ＩＤを通信制御部３２へ送るようにしてもよい。

なお、他の実施形態においては、アプリケーションに固有のアプリＩＤ（利用ＩＤとは異なる）と、そのアプリケーションに設定される利用ＩＤとをアプリケーション毎に関連付けたテーブルを用いて通信制御部３２が利用ＩＤを特定するようにしてもよい。すなわち、通信制御部３２は、上記テーブルを記憶しておき、アプリケーション部３１から読出指令と共にアプリＩＤを取得し、取得したアプリＩＤに関連付けられる利用ＩＤを当該アプリケーションの利用ＩＤとして決定してもよい。

特定アプリ判定処理において、通信制御部３２は、アプリケーション部３１から指令と共に取得した利用ＩＤと、上述のステップＳ２でタグ２から読み出した利用ＩＤとを比較する。そして、両者が一致すれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは特定アプリプログラムであると判定する。一方、両者が異なれば、通信制御部３２は、上記指令を行ったアプリケーションプログラムは非特定アプリプログラムと判定する。

上記変形例のように、タグ２は、専用データを利用可能な１種類以上の特定アプリプログラムを特定するための識別情報（利用ＩＤ）を記憶していてもよい。また、通信制御部３２は、指令元のアプリケーションプログラムに対応する利用ＩＤを当該アプリケーションプログラムから受け付ける。そして、通信制御部３２は、タグ２に記憶されている利用ＩＤと、指令元のアプリケーションプログラムから取得した利用ＩＤとに基づいて、受け付けられた指令が特定アプリプログラムからの指令であるか否かを判定する（ステップＳ５）。これによれば、受け付けられた指令が特定アプリプログラムからの指令であるか否かを容易に判定することができる。

（タグに自由データ領域を設定する変形例）
他の実施形態においては、タグ２には、図３に示した各領域（専用データ領域、共用データ領域、および管理データ領域）に加えて、自由データ領域が設定されてもよい。以下、図１８を参照して、上記実施形態の変形例として、タグ２に自由データ領域が設定される例について説明する。

図１８は、本実施形態の変形例におけるタグに記憶されるデータの一例を示す図である。図１８に示すように、本変形例においては、タグ２の読み書き可能領域２２に、自由データ領域が設定される。自由データ領域は、特定アプリプログラム以外のアプリケーションプログラム（非特定アプリプログラム）がデータを書き込むことができる領域である。なお、タグ２の出荷時においては基本的に、自由データ領域にはデータが記憶されていない。ただし、例えばタグを購入したユーザに特典としてゲームデータを付与する場合等には、何らかのデータが自由データ領域に記憶されていてもよい。

非特定アプリプログラムを実行するアプリケーション部３１がタグ２にデータ（ここではセーブデータ）を書き込む場合、まず、アプリケーション部３１は通信制御部３２へ書込指令を送る。上記変形例に係る特定アプリ判定処理と同様、この書込指令にはアプリケーションプログラムの利用ＩＤが含まれている。書込指令に応じて、通信制御部３２は上記実施形態と同様の処理（ステップＳ１〜Ｓ６，Ｓ３１）を実行する（ただし、ステップＳ５については、上記変形例に係る、利用ＩＤを用いた特定アプリ判定処理と同様の処理を実行する。）。すなわち、通信制御部３２は、タグ２にアクセスしてデータを読み出し、読み出したデータ（共用データ）をアプリケーション部３１に渡す。そして、アプリケーション部３１は、タグ２に書き込むべきセーブデータを通信制御部３２へ渡す。

アプリケーション部３１からセーブデータを受け取ると、通信制御部３２は、書込指令を受け付けた時に取得した利用ＩＤと、受け取ったセーブデータとを関連付けてタグ２に書き込む（図１８参照）。タグ２において、書き込まれるデータと利用ＩＤとを関連付ける方法は任意であるが、例えば、自由データ領域を複数のブロックに区分して管理する方法が用いられてもよい。１つのブロックは、セーブデータを書き込むデータ領域と、そのセーブデータに対応するアプリケーションプログラムの利用ＩＤを書き込むＩＤ領域とを含む。このとき、通信制御部３２は、１つのブロックのデータ領域にセーブデータを書き込むと共に、そのブロックのＩＤ領域に利用ＩＤを書き込む。これによって、セーブデータと利用ＩＤとが関連付けて記憶されることになる。なお、通信制御部３２は、セーブデータのデータサイズによっては、２以上のブロックに対してデータの書き込みを行ってもよい。このとき、セーブデータが書き込まれる各ブロックの各ＩＤ領域のそれぞれに、同じ利用ＩＤが書き込まれる。

なお、本変形例においても上記実施形態と同様、セーブデータの書き込み時に更新データが更新されてもよい。

非特定アプリプログラムを実行するアプリケーション部３１がタグ２からセーブデータを読み出す場合、アプリケーション部３１は通信制御部３２へ読出指令を送る。上記変形例と同様、この読出指令にはアプリケーションプログラムの利用ＩＤが含まれている。読出指令に応じて、通信制御部３２は上記実施形態と同様のステップＳ１〜Ｓ４の処理を実行する。

ここで、本変形例においては、通信制御部３２は、上記実施形態におけるステップＳ３のアクセス許可判定処理において許可タグでないと判定された場合、ステップＳ５の特定アプリ判定処理として、次の判定処理を実行する。すなわち、通信制御部３２は、読出指令に含まれる利用ＩＤと、タグ２の自由データ領域に記憶される利用ＩＤとが一致するか否かを判定する。この判定処理は、読出指令を行ったアプリケーションプログラムが、タグ２の自由データ領域内のセーブデータに対応するアプリケーションプログラムであるか否かを判定するための処理である。

上記判定処理において、２つの利用ＩＤが一致する場合、通信制御部３２は、共用データと、一致した利用ＩＤと関連付けて記憶されるセーブデータとをアプリケーション部３１に渡す。これによって、タグ２の自由データ領域にセーブデータを書き込んだアプリケーションは、タグ２からセーブデータを読み出すことができる。一方、２つの利用ＩＤが一致しない場合、通信制御部３２は、共用データ（のみ）をアプリケーション部３１に渡す。

以上のように、他の実施形態においては、特定アプリプログラム以外の他のアプリケーションプログラムが、データをタグ２に書き込むことができるようにしてもよい。すなわち、タグ２は、所定のアプリケーションプログラム（特定アプリプログラム）によってデータを読み書き可能な記憶領域（専用データ領域）と、当該所定のアプリケーションプログラムであるか否かにかかわらずデータを読み出し可能な記憶領域（共用データ領域）と、当該所定のアプリケーションプログラムであるか否かにかかわらずデータを書き込むことが可能な記憶領域（自由データ領域）とを有していてもよい。これによれば、タグ２にデータを書き込むことができるアプリケーションプログラムの種類が増えるので、タグ２の汎用性・利便性をより向上することができる。

上記変形例においては、通信制御部３２は、アプリケーションプログラムからの指令に応じてタグ２の自由データ領域にデータを書き込む場合、書き込むデータと、当該アプリケーションプログラムの利用ＩＤとを関連付けてタグ２に記憶させる。そして、自由データ領域に記憶されるデータの読出指令をアプリケーションプログラムから受け付けた場合、通信制御部３２は、受け付けられた指令に含まれる利用ＩＤと、タグ２の自由データ領域において読み出し対象のデータに関連付けられている利用ＩＤとに基づいて、当該データを当該アプリケーションプログラムに渡すか否かを判定する。これによれば、タグ２の自由データ領域に記憶されたデータを、そのデータに対応するアプリケーションプログラム（データを書き込んだアプリケーションプログラムと、それと同じ利用ＩＤが設定されるアプリケーションプログラム）において読み出すことができるように管理することができる。

なお、上記変形例において、自由データ領域に書き込まれたデータ（および利用ＩＤ）は、情報処理装置３によって削除することができるようにしてもよい。例えば、ユーザの削除指示を受けたシステムアプリケーションプログラムからの指令に応じて、通信制御部３２は、削除指示に係るデータをタグ２から削除するようにしてもよい。これによれば、タグ２の自由データ領域に空きが無くなった場合でも、空きを新たに生成することで別のデータを書き込むことができるようになる。また、他の実施形態においては、タグ２には、自由データ領域に書き込まれたデータに関連付けて、当該データが削除可能か否かを示す情報が記憶されるようにしてもよい。

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

（アプリ用データに関する変形例）
また、他の実施形態においては、情報処理装置３は、タグ２に書き込むべきアプリ用データについて、タグに固有の情報を反映して書き込むようにしてもよい。例えば、情報処理装置３（アプリケーション部３１および／または通信制御部３２）は、アプリ用データに含まれる所定のゲームパラメータについて、書き込むべきタグ２に固有の情報（例えば固有ＩＤ）を反映した値としてもよい。そして、当該値のゲームパラメータを含むアプリ用データがタグ２に書き込まれてもよい。なお、所定のゲームパラメータは、アプリ用データに対応するアプリケーションにおけるゲーム処理において用いられる任意のパラメータでよい。例えば、所定のゲームパラメータは、タグの外観が表すオブジェクト（キャラクタまたはアイテム）に関するパラメータ（例えばキャラクタの強さを表すパラメータや、キャラクタの外観を表すパラメータ）であってもよい。

具体的には、タグ２に対してアプリ用データが最初に書き込まれる際、アプリケーション部３１は、上記ゲームパラメータとして所定の初期値を設定する。通信制御部３２は、この初期値が設定されたゲームパラメータを含むアプリ用データをタグ２に書き込む。この初期値は、任意であり、ランダム値であってもよいし、タグ２に固有の情報（例えば固有ＩＤ）に基づく数値であってもよいし、固定値であってもよい。その後、上記タグ２に記憶されるアプリ用データを更新する際、アプリケーション部３１は、更新前のタグ２に記憶されているアプリ用データに含まれる上記ゲームパラメータを、固有ＩＤを用いて更新する。例えば、タグ２に記憶される固有ＩＤに基づく係数を更新前の値に掛けることによって、ゲームパラメータの更新後の値が算出されてもよい。そして、通信制御部３２は、更新後の値となったゲームパラメータを含むアプリ用データ（更新後のアプリ用データ）をタグ２に書き込むことで、アプリ用データを更新する。上記のようなゲームパラメータをアプリ用データに含めることで、タグ２に記憶されるアプリ用データにタグに固有の情報を含めることができ、アプリ用データをタグに固有の情報とすることができる。

上記によれば、２つのタグが表すキャラクタ（キャラクタＩＤ）が同じであって、同じようにゲームを進めたとしても、タグの固有ＩＤが異なるので、２つのタグのアプリ用データ（に含まれる上記ゲームパラメータ）が互いに異なる内容となる。例えば、仮に同じようにゲームを進めたとしても、タグに対応するゲームキャラクタの見た目が異なったり、強さが異なったり、成長度合いが異なったりするようになる。これによれば、タグに記憶されるアプリ用データはタグに固有のものとなるので、それぞれのタグは（外観が同じタグであっても）それぞれのタグに固有のものとなる。これによって、タグに対する愛着をユーザに持たせやすくなる。また、外観が同じタグであっても、ゲームパラメータの違いによってタグ同士をより確実に区別することができる。

また、上記ゲームパラメータを更新することによって、ユーザは、タグ２を利用することでゲームパラメータを変更することができる。なお、上記のように、情報処理装置３は、アプリ用データの更新の度にゲームがより有利になるような値となるように、ゲームパラメータを更新してもよい。これによれば、タグ２を利用する動機付けをユーザに与えることができ、タグ２の利用をユーザに促すことができる。

（共用データに関する変形例）
上記実施形態においては、共用データに含まれるデータの例として、図３に示すデータを例示した。ここで、共用データに含まれるデータは任意である。他の実施形態においては、初期登録データは、ユーザの入力したメッセージのデータを含んでいてもよい。このメッセージは、例えば、情報処理装置３が実行するアプリケーションによって読み出されて表示部１７に表示される。

また例えば、初期登録データは、情報処理装置３のユーザを識別する識別情報を含んでいてもよい。ユーザの識別情報は、例えば、情報処理装置３を用いたネットワークサービス（例えばネットワークを介したアプリケーションの提供サービス）が行われる場合における、当該ネットワークサービス上でのユーザのＩＤである。例えば、ユーザが外出先の情報処理装置においてタグにアクセスした場合、当該情報処理装置は、ユーザのＩＤをタグから読み出し、当該情報処理装置に対するユーザのアクセスがあったことをサーバへ通知する。これによって、サーバは、ユーザがタグを用いてアクセスした情報処理装置を管理することができる。例えば、各種のイベントが行われる場所に情報処理装置を設置しておき、タグを用いて情報処理装置に対するアクセスをユーザに行わせることによって、サーバは、イベントに参加したユーザを知ることができる。例えば、サーバは、情報処理装置からの通知に応じて、上記ネットワークサービス上において所定のサービスや特典をユーザに付与するようにしてもよい。

上記のように、タグ２は、情報処理装置３を用いてアクセス可能なネットワークサービスに関するユーザの識別情報を記憶する。情報処理装置３は、ネットワークサービスを提供するサーバと通信可能であり、タグ２と通信可能となった場合、一定条件下で、かつ、ユーザの指示の有無にかかわらず、タグ２から読み出した識別情報を用いてサーバにアクセスする。なお、「サーバにアクセスする」とは、情報処理装置３がサーバによって提供されるネットワークサービスにログインすることの他、情報処理装置３がサーバと通信を行うことも含む意味である。上記によれば、ユーザは、タグ２を情報処理装置３にかざすだけで、サーバとの通信を行うためのさらなる操作が必要ないので、タグ２の利便性を向上することができる。

なお、情報処理装置３によってネットワークサービスにログインする場合、サーバは、上記識別情報に加えて、パスワードの入力を条件としてログインを許可するようにしてもよい。これによれば、タグ２の所有者でない他の者が他のユーザのタグ２を用いてネットワークサービスに不正にログインすることを防止することができる。なお、サーバは、タグ２を用いたネットワークサービスへのログインを受け付けるとともに、タグ２を用いずに、情報処理装置３に対してユーザ識別情報（およびパスワード）を入力することによるログインを受け付けてもよい。タグ２を用いたログインが行われる場合、サーバは、当該サーバにアクセスした情報処理装置３と通信可能なタグ２に記憶されるユーザの識別情報を取得し、当該ユーザのパスワードの入力をユーザに要求する。サーバは、正しいパスワードが情報処理装置３において入力されたことを条件としてログインを許可する。

タグ２にユーザの識別情報を記憶する方法は任意である。例えば、情報処理装置３の記憶部（例えばメモリ）にユーザの識別情報が登録（記憶）されている場合、上記初期登録処理において情報処理装置３（通信制御部３２）は、情報処理装置３に記憶されている識別情報を取得してタグ２に記憶するようにしてもよい。また例えば、通信制御部３２は、初期登録処理においてユーザの識別情報の入力をユーザから受け付け、入力された識別情報をタグ２に記憶するようにしてもよい。なお、ユーザの識別情報が情報処理装置３に記憶されている場合、情報処理装置３は、記憶されている識別情報を用いてネットワークサービスにログインすることが可能である。したがって、ユーザは、ユーザの識別情報が記憶されている情報処理装置（例えば、当該ネットワークサービスのための専用端末）についてはタグ２を用いずにネットワークサービスにログインすることができ、ユーザの識別情報が記憶されていない情報処理装置（例えば、上記専用端末とは異なる汎用の情報処理端末）についてはタグ２を用いることによってネットワークサービスにログインすることができる。

また、ユーザの識別情報を記憶していない情報処理装置は、タグ２と通信可能となった場合、タグ２に記憶されているユーザの識別情報を読み出して、自機の記憶部に記憶してもよい。これによれば、ユーザの識別情報を記憶していなかった情報処理装置に対して、タグ２を用いて識別情報を登録することができる。例えば、まず、ユーザの識別情報を記憶している第１の情報処理装置に対してタグ２をアクセスさせる（タグ２をかざす）ことによってタグ２に識別情報を登録し、さらに、ユーザの識別情報を記憶していない第２の情報処理装置に対してタグ２をアクセスさせることによって、第２の情報処理装置に識別情報を登録することも可能である。このように、タグ２を用いることによって、ユーザの識別情報を容易に登録することができる。なお、各情報処理装置は、タグ２と近距離無線通信を行うことが可能であり、記憶部を有していればよく、第１の情報処理装置と第２の情報処理装置とは異なる種類の情報処理装置であってもよい。

また、上記実施形態においては、更新データには、タグ２に対する書き込みに関する情報（書き込み回数、最終書き込み装置、装置変更回数、最終利用アプリ、および、最終書き込み日時）が含まれる。ここで、他の実施形態においては、更新データは、タグ２に対する読み出しに関する情報を含んでいてもよい。例えば、更新データは、タグ２からのデータの読み出し回数（タグ２に対するアクセスがあった回数）、タグ２からデータを最後に読み出した情報処理装置、データの読み出しを行う情報処理装置が変更された回数、タグ２からデータの読み出しを最後に行ったアプリケーションプログラム、および／または、タグ２からデータの読み出しが最後に行われた日時等の情報を含んでいてもよい。

また、上記実施形態においては、タグ２に対する最後の書き込みに関する情報（最終書き込み装置、最終利用アプリ、および、最終書き込み日時）が更新データに含まれる。ここで、他の実施形態においては、更新データは、タグ２に対する書き込みの履歴に関する情報を含んでいてもよい。例えば、更新データは、タグ２に対してデータ（専用データでもよい）の書き込みを行った情報処理装置、タグ２に対してデータ（専用データでもよい）の書き込みを行ったアプリケーションプログラム、および／または、タグ２に対してデータ（専用データでもよい）の書き込みが行われた日時に関する履歴の情報を含んでいてもよい。また、他の実施形態においては、タグ２に対するデータの読み出しの履歴に関する情報が更新データに含まれていてもよい。

例えば、他の実施形態においては、更新データによって、タグ２に対するデータの書き込みを行った情報処理装置をホームとアウェイとに区別して管理してもよい。ここで、ホームの情報処理装置は、初期登録データが書き込まれた情報処理装置であり、典型的にはユーザが所有する情報処理装置である。また、アウェイの情報処理装置は、ホームの情報処理装置以外の他の情報処理装置であり、典型的には、ユーザの知人の情報処理装置や、店頭やイベント会場に設置された情報処理装置である。更新データは、ホームの情報処理装置による書き込み回数と、アウェイの情報処理装置による書き込み回数とを含んでいてもよい。これによれば、情報処理装置は、ホームの情報処理装置とアウェイの情報処理装置との利用状況に応じた情報処理を実行することができる。

また、他の実施形態においては、更新データは、所定の条件が満たされた場合にオンに設定されるフラグデータを含んでもよい。上記所定の条件は、例えば、店頭やイベント会場に設置される特定の情報処理装置がタグにアクセスしたことである。つまり、特定の情報処理装置によって、タグに記憶されているフラグデータがオンを示す値に更新される。これによれば、例えば店頭やイベント会場にユーザが足を運んだことを示す情報がタグに記憶されることになる。したがって、アプリケーションは、このような情報を用いた情報処理（例えば、特定のイベントに足を運んだユーザに対して特典を付与する処理）を実行することができる。

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

（利用ＩＤを読み書き可能領域に記憶する変形例）
上記実施形態においては、利用ＩＤは読み出し専用領域に記憶された（図３）。ここで、利用ＩＤは、読み書き可能領域２２に記憶されてもよい。つまり、ユーザ側（アプリケーション側）で利用ＩＤを設定または変更できるようにしてもよい。以下、利用ＩＤがタグ２の読み書き可能領域２２に記憶される変形例について説明する。

図１９は、本実施形態の他の変形例におけるタグに記憶されるデータの一例を示す図である。図１９に示すように、利用ＩＤは、読み書き可能領域２２に記憶される。また、本変形例においては、利用ＩＤは管理データ領域に記憶される。利用ＩＤは、上述のように、タグ２に記憶される専用データ（セーブデータ）を利用可能なアプリケーションプログラム（特定アプリプログラム）を特定する識別情報である。

また、本変形例においては、タグ２の読み書き可能領域２２にタイトルＩＤ（のデータ）が記憶される。タイトルＩＤは、アプリケーションの名前（例えばゲームアプリケーションであれば、ゲームのタイトル等）を特定する識別情報である。タイトルＩＤは、上述したシリーズＩＤとは異なり、例えば１つのシリーズのアプリケーションとして複数種類のアプリケーションが提供されている場合であっても、各アプリケーションを区別できるように、当該各アプリケーションで異なるＩＤが付与される。なお、他の実施形態においては、利用ＩＤとともにタイトルＩＤが記憶されている必要はなく、タイトルＩＤは記憶されなくてもよい。

本変形例においては、上記利用ＩＤおよびタイトルＩＤは、出荷時には記憶されていないものとする。つまり、ユーザによって購入されたばかりのタグ２には、（読み書き可能領域２２に記憶される他のデータと同様、）利用ＩＤおよびタイトルＩＤが記憶されていない。一方、アプリケーションプログラムには、自身に設定される利用ＩＤの情報が含まれているものとする。なお、他の実施形態においては、出荷時に利用ＩＤ（およびタイトルＩＤ）がタグ２に記憶されていてもよい。この場合であっても、情報処理装置３は、タグ２に記憶されている利用ＩＤを消去する処理（後述する初期化処理）によって利用ＩＤを消去可能とすることで、後述する処理（図２０および図２１参照）によって利用ＩＤを再設定することができる。

上記以外のデータについては、上記実施形態と同様のデータがタグ２に記憶される。

次に、図２０および図２１を参照して、本変形例における情報処理システム１の処理動作について説明する。図２０は、本変形例において、アプリケーションプログラムによってタグにデータが書き込まれる場合における情報処理システムの処理の流れの一例を示す図である。ここでは、利用ＩＤが記憶されていないタグ２に対して、専用データ（セーブデータ）の書込指令が行われた場合を例として説明する。

図２０に示すように、本変形例においては、ステップＳ３におけるアクセス許可判定処理においてタグ２へのアクセスが許可された場合、通信制御部３２は、タグ２に利用ＩＤが記憶されているか否かを判定する（ステップＳ７１）。詳細は後述するが、例えばユーザによって購入されたばかりのタグのように、専用データ領域へのアクセスがまだ行われていないタグについては、利用ＩＤが記憶されていない。したがって、このようなタグについては、ステップＳ７１において、利用ＩＤが記憶されていないと判定される。

利用ＩＤが記憶されていないと判定された場合、通信制御部３２は、上記実施形態と同様のステップＳ６，Ｓ３２，Ｓ３３の処理を実行した後、セーブデータ等をタグ２に書き込む際に、利用ＩＤをタグ２に書き込む（ステップＳ７２）。なお、利用ＩＤは、任意のタイミングでアプリケーション部３１から通信制御部３２へ送られることで通信制御部３２に取得されてよい。例えば、利用ＩＤは、ステップＳ１において、書込指令に含めて通信制御部３２へ送られてもよいし、ステップＳ３２において、タグ２に書き込まれるべきデータとともに通信制御部３２へ送られてもよい。

図２１は、本変形例における書込指令処理の流れの一例を示すフローチャートである。なお、図２１に示すフローチャートは、図１０との相違点を示しており、本変形例における書込指令処理について、図２１に示す処理以外の処理は、上記実施形態と同様である。

図２１に示すように、ステップＳ３の判定結果が肯定である場合、ステップＳ７１の処理が実行される。すなわち、ステップＳ７１において、通信制御部３２は、タグ２に利用ＩＤが記憶されているか否かを判定する。この判定は、ステップＳ２でタグ２から読み出されたデータを参照することで行うことができる。ステップＳ７１の判定結果が否定である場合、上述のように、ステップＳ６，Ｓ３２，およびＳ３３の処理が実行される。さらに、続くステップＳ７２において、通信制御部３２は、セーブデータ等（上記ステップＳ３４でタグ２に書き込まれるデータ）とともに利用ＩＤをタグ２に書き込む。

一方、ステップＳ７１の判定結果が肯定である場合、ステップＳ５の処理が実行される。ここで、本変形例においては、ステップＳ５の判定処理は、利用ＩＤを用いて行われる（上述の“（特定アプリ判定処理の変形例）”参照）。したがって、あるアプリケーションからの指令に基づいてタグ２に利用ＩＤが書き込まれると、そのアプリケーション（および、同じ利用ＩＤに対応するアプリケーション）によって専用データ領域に対するアクセスが可能となり、その他のアプリケーションによる専用データ領域に対するアクセスは制限される。

上記においては、アプリケーション部３１からの書込指令を受け付けた場合における処理について説明した。通信制御部３２は、書込指令以外の他の指令（読出指令等）を受け付けた場合も書込指令の場合と同様に、タグ２に利用ＩＤを書き込むようにしてもよい。

すなわち、他の指令を受け付けた場合において、アクセス許可判定処理（ステップＳ３）の判定結果が肯定となった場合、通信制御部３２は、上記ステップＳ７１の判定処理を実行する。そして、ステップＳ７１の判定結果が否定となる場合、通信制御部３２は、タグ２に利用ＩＤを書き込む。なお、通信制御部３２は、タグ２に利用ＩＤを書き込む処理の前または後に、アプリケーション部３１からの指令に応じた処理を実行する。一方、ステップＳ７１の判定結果が肯定となる場合、通信制御部３２は、利用ＩＤを用いてステップＳ５の特定アプリ判定処理を実行する。

なお、読出指令を受け付けた場合、通信制御部３２は、受け付けた指令が、専用データ（セーブデータ）を読み出す指令であることを条件として、タグ２に利用ＩＤを書き込むようにしてもよい。つまり、アプリケーション部３１からの指令が共用データを読み出す指令である場合には、タグ２に利用ＩＤが記憶されていない場合であっても、タグ２に利用ＩＤを書き込まないようにしてもよい。これによれば、通信制御部３２は、タグ２の専用データ領域に対して初めてアクセスがある場合に、タグ２に利用ＩＤを書き込むこととなる。したがって、アプリケーション部３１が単に共用データを利用する（読み出す）場合には、タグ２に利用ＩＤが書き込まれない結果、このタグ２の専用データ領域に対するアクセスは制限されないことになるので、利便性を向上することができる。

以上のように、本変形例においては、情報処理装置３は、所定のアプリケーションの実行中において、タグ２に対してアクセス可能となった場合、タグ２に記憶されるアプリ用データ（専用データ）が当該所定のアプリケーションにおいて利用可能であるか否かを示す利用情報（利用ＩＤ）がタグ２に記憶されているか否かを判定する（ステップＳ７１）。また、情報処理装置３は、利用情報がタグ２に記憶されていないと判定されたことを少なくとも条件として、タグ２に記憶されるアプリ用データが上記所定のアプリケーションにおいて利用可能であることを示す利用情報をタグ２に書き込む（ステップＳ７２）。情報処理装置３は、あるアプリケーションにおいてアプリ用データが利用可能であることを示す利用情報がタグ２に記憶されていることを条件として、当該あるアプリケーションに対してタグ２に記憶されているアプリ用データの利用を許可する（ステップＳ５）。

上記において、情報処理装置３は、利用情報がタグ２に記憶されていない（と判定された）ことを少なくとも条件として利用情報をタグ２に書き込めばよい。すなわち、情報処理装置３は、利用情報がタグ２に記憶されていない場合に自動的に（ユーザの指示の有無にかかわらず）利用情報をタグ２に書き込むようにしてもよいし、利用情報を書き込むか否かをユーザに確認するようにしてもよい。なお、ユーザに確認した結果、利用情報をタグ２に書き込まない旨の指示をユーザが行った場合、情報処理装置３は、アプリ用データをタグ２に記憶することを制限してもよい。つまり、情報処理装置３は、アプリケーションに対応する利用情報がタグ２に記憶されていることを条件として、当該アプリケーションのアプリ用データをタグ２に記憶することを許可するようにしてもよい。

上記によれば、タグの利用情報をユーザ側で設定することができる。つまり、ユーザは、利用情報が記憶されていないタグを、あるアプリケーションの実行中に用いることによって、そのタグを、当該あるアプリケーションに関するアプリ用データを記憶するために用いることができる。これによれば、タグを、どのアプリケーションに用いるか（どのアプリケーションのアプリ用データを記憶するために用いるか）を、ユーザが決定することができるので、タグの利便性をより向上することができる。

なお、上記においては、任意のタグを、任意のアプリケーションのアプリ用データを記憶するために用いることができる。ここで、他の実施形態においては、情報処理システム１は、アプリ用データを記憶するためにタグを用いることができるアプリケーションを、例えば以下の方法で制限してもよい。

すなわち、上記変形例において、通信制御部３２は、ステップＳ７１の処理の前に、アプリ対応判定処理を実行するようにしてもよい。アプリ対応判定処理は、通信中のタグ２が、指令元のアプリケーションに対応するか否かを判定する処理である。この判定は、例えば、アプリケーションプログラムに、自身のアプリ用データを記憶するために用いることができるタグの情報（利用可能情報）を含めておくことで行うことができる。すなわち、通信制御部３２は、アプリケーション部３１から利用可能情報を取得し、利用可能情報が示すタグのうちに、通信中のタグ２が含まれるか否かを判定する。この判定は、実行中のアプリケーションで通信中のタグ２が利用可能であるか否かを判定するものである。この判定は、タグ２に記憶されている識別情報と、取得された利用可能情報とに基づいて行うことができる。すなわち、上記の判定は、利用可能情報が示す識別情報（のリスト）に、タグ２に記憶されている識別情報が含まれるか否かによって行うことができる。なお、利用可能情報は、アプリケーションにおいてアプリ用データを記憶するために利用可能なタグ２の識別情報を示す情報であってもよい。例えば、利用可能情報は、タグ２の種類を識別するための識別情報であるフィギュアＩＤ（利用可能なフィギュアＩＤのリスト）を示す情報であってもよい。

利用可能情報が示すタグのうちに通信中のタグ２が含まれる場合、通信制御部３２は、通信中のタグ２が指令元のアプリケーションに対応すると判定し、ステップＳ７１の処理を実行する。一方、利用可能情報が示すタグのうちに通信中のタグ２が含まれない場合、通信制御部３２は、通信中のタグ２が指令元のアプリケーションに対応しないと判定する。この場合、例えば、アプリケーション部３１は、タグ２がそのアプリケーションのアプリ用データを記憶するために用いることができない旨をユーザに通知する。

上記のように、情報処理システム１は、通信中のタグ２が指令元の（実行中の）アプリケーションに対応するか否かの判定を行い、対応すると判定されたことを少なくとも条件として、タグ２に利用ＩＤを記憶するようにしてもよい。すなわち、情報処理装置３は、実行中の所定のアプリケーションから利用可能情報を取得し、タグ２が当該所定のアプリケーションで利用可能であるか否かを判定する。そして、情報処理装置３は、この判定結果が肯定である場合に、利用ＩＤがタグ２に記憶されていないと判定されたことを条件として（ステップＳ７１でＮｏ）、タグ２に記憶されるアプリ用データが上記所定のアプリケーションにおいて利用可能であることを示す利用ＩＤをタグ２に書き込む。

ここで、アプリケーションの内容と全く関係のないキャラクタ（例えば、そのアプリケーションに登場しないキャラクタ）を表すタグが、そのアプリケーションに用いられるとすれば、タグの外観からはタグとアプリケーションとの関連性がわからなくなってしまう。そのため、後になるとユーザ自身が、タグにどのアプリケーションのアプリ用データを記憶したかがわからなくなってしまうおそれがある。これに対して、上記によれば、アプリケーションとの関連性がないタグの利用を制限することができるので、タグの利便性をより向上することができる。

なお、上記アプリ対応判定処理は、タグが、アプリ用データを記憶するためのタグとして、アプリケーションに対応するか否かを判定する処理である。すなわち、アプリ対応判定処理においてタグがアプリケーションに対応しないと判定された場合であっても、当該アプリケーションにおいて当該タグの共用データを利用することは可能である。

（初期登録をユーザに促す変形例）
上記実施形態においては、ユーザによって初期登録を行う旨の指示が行われたことに応じて、タグ２に対する初期登録データの登録（書込）が行われた。ここで、他の実施形態においては、アクセス可能となったタグ２に初期登録データが登録されていない場合、情報処理装置３は、初期登録をユーザに促すようにしてもよい。以下、初期登録をユーザに促す変形例について説明する。

図２２は、本変形例において、タグに初期登録データが書き込まれる場合における情報処理システムの処理の流れの一例を示す図である。なお、図２２は、あるアプリケーション（特定アプリであってもよいし、特定アプリでなくてもよい）の実行中において、情報処理装置３とタグ２とが通信可能となった場合の処理の流れを示している。

まず、通信制御部３２は、上記ステップＳ１の接続処理を実行する。この接続処理は、任意のタイミングで開始されてよい。本変形例においては、接続処理は、アプリケーション部３１からの指令（具体的には、読出指令または書込指令）があったことに応じて開始される。なお、他の実施形態においては、一定時間間隔で接続処理が実行されてもよい。ステップＳ１の次にステップＳ２の処理が実行される。ステップＳ１およびＳ２の処理の内容は上記実施形態と同様である。

本変形例においては、通信制御部３２は、初期登録判定処理を実行する（ステップＳ８１）。初期登録判定処理は、タグ２に対する初期登録が行われているか否か、すなわち、初期登録データがタグ２に記憶されているか否かを判定する処理である。この判定は、上記ステップＳ２でタグ２から読み出したデータを参照することによって行うことができる。タグ２に対する初期登録が行われていないと判定された場合、通信制御部３２は、初期登録が行われていないことの通知（未登録通知）をアプリケーション部３１へ送る（ステップＳ８２）。なお、図２２には図示しないが、タグ２に対する初期登録が行われていると判定された場合には、通信制御部３２は、アプリケーション部３１からの指令に応じた処理を実行する。

未登録通知を受け取ったアプリケーション部３１は、ユーザに対して登録を確認する処理を実行する（ステップＳ８３）。具体的には、アプリケーション部３１は、ユーザに対して登録を確認するための画像（登録確認画像）を表示部１７に表示する。さらに、アプリケーション部３１は、登録に関するユーザの入力を受け付け、初期登録データを取得する（ステップＳ８４）。ステップＳ８３およびＳ８４の具体的な処理内容は任意であるが、本変形例においては以下のようにして行われる。

図２３は、登録確認画像の一例を示す図である。図２３に示す登録確認画像は、アバターデータとニックネームのデータとの入力をユーザに促すための画像である。図２３に示すように、登録確認画像は、オーナー入力部６１と、ニックネーム入力部６３とを含む。オーナー入力部６１は、タグ２のオーナーを示す情報（ここでは、アバター）を入力するための画像である。

本変形例においては、図２３に示すように、アバター（ここでは、アバターの顔と名前）の情報が予め表示されている場合がある。すなわち、アプリケーション部３１は、タグ２にアバターデータが記憶されている（ただし、ニックネームのデータはタグ２に記憶されていない）場合、登録確認画像において、タグ２に記憶されているアバターデータに基づいてアバターの情報を表示する。

また、図２２に示す一連の処理はタグ毎に繰り返し実行されてもよく、複数のタグについて連続して初期登録が行われてもよい。この場合、アプリケーション部３１は、直前に初期登録が行われた際に設定されたアバターの情報を、今回の初期登録における登録確認画像において表示する。すなわち、アプリケーション部３１は、最後に初期登録が行われた際に設定されたアバターデータ（前回アバターデータ）をメモリ１４に記憶しておき、次に登録確認画像を表示する際、メモリ１４に記憶されている前回アバターデータに基づいてアバターの情報を表示する。

さらに、ユーザのアバターとして情報処理装置３にアバターデータ（前回アバターデータとは異なる）が登録されている場合には、アプリケーション部３１は、このアバターデータに基づいてアバターの情報を表示してもよい。すなわち、タグ２にアバターデータが記憶されておらず、かつ、メモリ１４に前回アバターデータが記憶されていない場合、アプリケーション部３１は、情報処理装置３に登録されているアバターデータに基づいてアバターの情報を表示する。

上記のように、本変形例においては、登録済みのアバターデータ、あるいは、ユーザが入力することが予測されるアバター（前回アバターデータ、および、情報処理装置３に登録されているアバターデータ）がある場合には、これらのアバターデータに基づく情報が表示される。これによって、ユーザの入力の手間を省くことができる。なお、他の実施形態においては、これらのアバターデータに基づく情報は表示されなくてもよい。

図２３においては、オーナー入力部６１には、変更ボタン６２が含まれる。この変更ボタン６２を指定する入力をユーザが行った場合、アプリケーション部３１は、オーナー入力部６１に表示されているアバターを他のアバターに変更する入力を受け付ける。これによって、ユーザは、すでに表示されているアバターを他のアバターに変更することが可能である。

また、ニックネーム入力部６３は、タグ２のニックネームを示す情報を入力するための画像である。ユーザは、ニックネーム入力部６３の入力欄に文字入力を行うことによって、タグ２のニックネームを入力する。入力された文字は上記入力欄に表示される。

図２３に示すように、登録確認画像は登録ボタン６４を含む。アプリケーション部３１は、登録ボタン６４を指定する入力をユーザが行った場合、アプリケーション部３１は、当該入力の時点で表示されているアバターおよびニックネームのデータを、初期登録データとして取得する。なお、本変形例において、ユーザは、登録確認画像が表示されている場合に必ずしも初期登録を行う必要はなく、アバターおよび／またはニックネームの表示を空欄にして登録ボタン６４を指定してもよい。この場合、空欄になっている情報については初期登録が行われず、空欄でない情報についてのみ初期登録が行われる。

また、上記実施形態と同様、アプリケーション部３１は、現在の日時を示すデータ、および、情報処理装置３が存在する地域（国）を示すデータを取得する。以上のようにして取得された初期登録データは、アプリケーション部３１から通信制御部３２へ送られる。すなわち、通信制御部３２は、初期登録データをアプリケーション部３１から取得する（ステップＳ８５）。ステップＳ８５の処理は、上記実施形態におけるステップＳ１２の処理と同様である。さらに、通信制御部３２は、初期登録データ等をタグ２に書き込む（ステップＳ８６）。ステップＳ８６の処理は、上記実施形態におけるステップＳ１３の処理と同様である。

以上のように、本変形例においては、タグ２に初期登録データ（の一部）が登録されていない場合、初期登録を行うための登録確認画像が表示され、初期登録が行われた場合には、初期登録データがタグ２に書き込まれる。これによって、情報処理システム１は、ユーザに初期登録を促すことができる。なお、詳細は後述するが、本変形例においては、初期登録が行われていないタグ２に対しては、専用データの記憶が制限（禁止）されるものとする。これによって、ユーザが初期登録を行う動機付けをより強くすることができる。

図２４は、本変形例において初期登録を行うための処理の流れの一例を示すフローチャートである。本変形例においては、上述した読出指令処理および書込指令処理において、図２４に示す処理が実行される。

読出指令処理または書込指令処理において、ステップＳ３の判定結果が肯定である場合、上記ステップＳ８１の処理が実行される。すなわち、ステップＳ８１において、通信制御部３２は上記の初期登録判定処理を実行する。ステップＳ８１の判定結果が肯定である場合、後述するステップＳ８７の処理が実行される。一方、ステップＳ８１の判定結果が否定である場合、ステップＳ８２の処理が実行される。すなわち、ステップＳ８２において、通信制御部３２は、未登録通知をアプリケーション部３１へ送る。通信制御部３２においては、ステップＳ８２の次にステップＳ８５の処理が実行される。

ステップＳ８５において、通信制御部３２は、アプリケーション部３１から初期登録データを取得したか否かを判定する。ステップＳ８５の判定結果が否定である場合、ステップＳ８６の処理がスキップされて、後述するステップＳ８７の処理が実行される。一方、ステップＳ８５の判定結果が肯定である場合、ステップＳ８６の処理が実行される。すなわち、ステップＳ８６において、アプリケーション部３１から取得した初期登録データ等をタグ２に書き込む。

ステップＳ８７において、通信制御部３２は、アプリケーション部３１からの読出指令または書込指令が、専用データにアクセスする指令か否か、すなわち、専用データを読み出す、または、書き込む指令であるか否かを判定する。ステップＳ８７の判定結果が否定である場合、上述のステップＳ５の処理が実行される。つまり、アプリケーション部３１が専用データ以外の他のデータ（共用データ）にアクセスする場合には、指令（読出指令または書込指令）に応じた処理が上記実施形態と同様に実行される。

一方、ステップＳ８７の判定結果が肯定である場合、ステップＳ８８の処理が実行される。ステップＳ８８において、通信制御部３２は、上記ステップＳ８１と同様の初期登録判定処理を実行する。ステップＳ８８の判定結果が肯定である場合、上述のステップＳ５の処理が実行される。つまり、初期登録データがタグ２に記憶されている場合には、指令（読出指令または書込指令）に応じた処理が上記実施形態と同様に実行される。

また、ステップＳ８８の判定結果が否定である場合、ステップＳ８９の処理が実行される。ステップＳ８９において、通信制御部３２は、タグ２の専用データ領域は利用できない旨の通知をアプリケーション部３１に対して行う。この通知を受け取ったアプリケーション部３１は、どのような処理を実行してもよいが、例えば、初期登録が済んでいないために専用データ領域の利用ができない旨をユーザに通知する処理を実行する。ステップＳ８９の後、通信制御部３２は、読出指令処理または書込指令処理を終了する。

以上のように、本変形例においては、タグ２は、所定のアプリケーションプログラムであるか否かにかかわらず利用可能な共用データを記憶する。情報処理装置３は、ユーザおよび／または情報処理装置３に関する登録データ（初期登録データ）がタグ２に記憶されていることを条件として、所定のアプリケーションにおける所定の処理（専用データにアクセスする処理）を許可する（ステップＳ８７〜Ｓ８９）。ここで、情報処理装置３は、登録データがタグ２に記憶されているか否かを判定し、登録データがタグ２に記憶されていないと判定された場合、登録データをタグ２に記憶するための処理（ステップＳ８３）を実行する。

上記「登録データ」は、上記実施形態における初期登録データの他、タグ２に登録（記録）される、ユーザおよび／または情報処理装置３に関する任意のデータでよい。上記「所定の処理」は、上記実施形態においては専用データにアクセスする処理であった、具体的な処理内容は任意である。例えば、他の実施形態においては、上記「所定の処理」は、タグ２からデータを書き込む処理であってもよいし、タグ２にアクセスする処理であってもよい。つまり、情報処理装置３は、登録データがタグ２に記憶されていない場合に、タグ２に対するデータの書き込みを制限してもよいし、タグ２に対するアクセス自体を制限してもよい。

また、上記「登録データをタグ２に記憶するための処理」は、登録データの記憶をユーザに確認する（促す）処理（上記変形例参照）であってもよいし、ユーザの確認なく（ユーザの指示にかかわらず）自動的に登録データをタグ２に記憶する処理であってもよい。

上記によれば、所定の処理を実行するために（所定の処理の機能を利用するために）、ユーザは登録データをタグ２に記憶することが要求されるので、情報処理システム１は、登録データをタグ２に記憶させることをユーザに促すことができる。さらに、上記によれば、所定のアプリケーション以外のアプリケーションが共用データを利用することについては、タグ２に対する登録データの記憶が要求されないので、ユーザは登録を行わなくてもタグ２を利用することができ、タグ２の利便性を向上することができる。つまり、上記によれば、タグ２に対する登録をユーザに促すことができるとともに、タグ２の利便性を向上することができる。

また、本変形例においては、登録データがタグ２に記憶されているか否かの判定は、複数のアプリケーションに共通で実行される。すなわち、情報処理装置３は、特定のアプリケーション（例えば、タグ２の専用データにアクセスする所定のアプリケーション）の実行中に限らず、複数のアプリケーションのいずれかが実行されている場合に上記判定を行う。この複数のアプリケーションは、タグ２との通信を行う任意のアプリケーションであってもよい。このように、本変形例においては、複数種類のアプリケーションにおいて共通に、上記判定が行われるので、ユーザに初期登録を行わせる機会が増え、初期登録を行わせやすくすることができる。

また、本変形例においては、情報処理装置３は、タグ２に対して登録データの読み出しおよび／または書き込みを行う際（例えば、アプリケーション部３１が読出指令および／または書込指令を送る場合）に、登録データがタグ２に記憶されていないと判定された場合、登録データをタグ２に記憶するための処理を実行する。これによれば、タグ２に記憶される登録データに対するアクセスが行われる際に、登録データをタグ２に記憶するための処理が実行されるので、適切なタイミングでユーザに初期登録を行わせることができる。

上記変形例において、情報処理装置３は、初期登録データをタグ２に記憶する場合に、実行中のアプリケーション（指令元のアプリケーション）に関するデータを専用データとしてタグ２に記憶するようにしてもよい。すなわち、アプリケーション部３１は、上記ステップＳ２１において初期登録データを取得した場合、初期登録データとともに所定の専用データを通信制御部３２へ送信する。この専用データの内容は任意であるが、例えば、アプリケーションにおいてタグ２に応じて初期設定されるデータであり、具体的には、ゲームアプリケーションにおいて登場するキャラクタ（タグ２が表すキャラクタ）の初期パラメータを示すデータである。専用データは、初期登録データ（アバターデータおよび／またはニックネームのデータ）に基づいて生成されてもよい。

通信制御部３２は、初期登録データおよび専用データを取得すると、指令元のアプリケーションが専用データにアクセス可能なアプリケーションであるか否かを判定する。この判定は、上述の特定アプリ判定処理と同様に行うことができる。指令元のアプリケーションが専用データにアクセス可能であると判定された場合、通信制御部３２は、アプリケーション部３１から取得した初期登録データおよび専用データをタグ２に記憶する。一方、指令元のアプリケーションが専用データにアクセス可能でないと判定された場合、通信制御部３２は、アプリケーション部３１から取得した初期登録データをタグ２に記憶する。このとき、アプリケーション部３１から取得された専用データはタグ２に記憶されない。

以上のように、情報処理装置３は、所定のアプリケーションの実行中において情報処理装置３にアクセス可能となったタグ２が、ユーザおよび／または情報処理装置に関する登録データを記憶しているか否かを判定する（ステップＳ８１）。そして、情報処理装置３は、タグ２が登録データを記憶していないと判定された場合、ユーザによって入力された登録内容に基づいて登録データをタグ２に書き込むとともに、当該登録データがタグ２に書き込まれる場合には、ユーザ指示の有無にかかわらず、所定のアプリケーションに関する情報（専用データ）をタグ２に書き込む。

上記によれば、登録データをタグ２に登録（記憶）した場合に、所定のアプリケーションに関する情報もタグ２に自動的に記憶される。これによって、上記情報をタグ２に記憶する指示をユーザが別途行う必要がないので、ユーザの手間を省くことができる。

なお、上記においては、専用データは、ユーザに確認を取ることなく自動的に（ユーザの指示の有無にかかわらず）生成されて通信制御部３２へ送られる。ただし、他の実施形態においては、情報処理装置３は、専用データをタグ２に書き込むか否かについてユーザの確認をとるようにしてもよい。

（タグ２に記憶されるデータのバックアップをとる変形例）
情報処理装置３は、タグ２に記憶されるデータのバックアップデータを記憶するようにしてもよい。図２５は、情報処理装置がタグのバックアップデータを記憶する場合における情報処理システムの一例を示す図である。図２５に示すように、情報処理装置３は、タグに記憶されるデータをバックアップデータとして、タグ毎に自機に記憶してもよい。以下、タグのデータのバックアップを取る変形例について説明する。

本変形例においては、タグ２にデータが書き込まれる際に、情報処理装置３においてバックアップがとられる（バックアップデータが更新される）。図２６は、本変形例における書込指令処理の流れの一例を示すフローチャートである。図２６に示すように、本変形例においては、通信制御部３２は、タグ２に書き込むべき更新データを生成する処理（ステップＳ３３）の次に、ステップＳ９１の処理を実行する。

ステップＳ９１において、通信制御部３２は、バックアップデータの更新を行う。具体的には、通信制御部３２は、接続中のタグ２を識別するための識別情報（例えばＵＩＤ、または、固有ＩＤ）と、当該タグ２のバックアップデータとを関連付けて、所定の記憶部に記憶する。ここで記憶されるバックアップデータは、次のステップＳ３４でタグ２に書き込むべきデータである。本変形例においては、読み書き可能領域２２に記憶されるべきデータがバックアップデータとして記憶される。また、識別情報とバックアップデータとを関連付けて記憶しておくことで、バックアップデータがどのタグに記憶されているデータであるかを特定することができる。なお、所定の記憶部は、情報処理装置３に内蔵される記憶装置であってもよいし、情報処理装置３がアクセス可能な外部記憶装置であってもよい。

上記ステップＳ９１の後、上記実施形態と同様のステップＳ３４の処理が実行される。これによって、バックアップデータと同じデータがタグ２に書き込まれることになる。したがって、タグ２に書き込まれた最新のデータがバックアップデータとして保存されることになる。

さらに、本変形例においては、タグ２からデータが読み出される際に、バックアップデータがタグ２の最新のデータであるか否かがチェックされ、最新のデータでない場合にはバックアップデータの更新が行われる。図２７は、本変形例における読出指令処理の流れの一例を示すフローチャートである。図２７に示すように、本変形例においては、ステップＳ３におけるアクセス許可判定処理においてタグ２へのアクセスが許可された場合、ステップＳ９２の処理が実行される。

ステップＳ９２において、通信制御部３２は、ステップＳ２でタグ２から読み出したデータと、上記記憶部に記憶されている当該タグ２のバックアップデータとが同じであるか否かを判定する。この判定の具体的な方法は任意であるが、例えば、通信制御部３２は、両者のハッシュ値（上記第２ハッシュ値）が同じであるか否かを判定してもよい。なお、情報処理装置３がタグに初めてアクセスした場合には、当該タグのバックアップデータは記憶部に記憶されていない。この場合、通信制御部３２は、タグから読み出したデータとバックアップデータとは同じでないと判定する。

ステップＳ９２の判定結果が肯定である場合、上記実施形態と同様のステップＳ５の処理が実行される。つまり、この場合には、バックアップデータはタグの最新のデータであるので、バックアップデータの更新は行われない。

一方、ステップＳ９２の判定結果が否定である場合、ステップＳ９３の処理が実行される。すなわち、ステップＳ９３において、通信制御部３２は、接続中のタグ２のバックアップデータを更新する。具体的には、通信制御部３２は、上記記憶部に記憶されるバックアップデータのうち、接続中のタグ２に関連付けられるバックアップデータを、ステップＳ２でタグ２から読み出したデータとなるように更新する。また、接続中のタグ２に関連付けられるバックアップデータが上記記憶部に記憶されていない場合には、通信制御部３２は、当該タグ２の識別情報と、ステップＳ２でタグ２から読み出したデータとを関連付けて記憶部に記憶する。上記ステップＳ９３の後、上記実施形態と同様のステップＳ５の処理が実行される。

上記のように、本変形例においては、タグ２からデータが読み出される際において、バックアップデータがタグ２の最新のデータでない場合にはバックアップデータの更新が行われる。例えば、本変形例においては、あるタグに対して情報処理装置３によってデータの書き込みが行われた後、当該タグに対して他の情報処理装置によってデータの書き込みが行われた場合、情報処理装置３に記憶されているバックアップデータは、当該タグの最新のデータではないことになる。これに関して、本変形例においては、上記ステップＳ９１〜Ｓ９２の処理によって、タグ２からデータが読み出される際において、バックアップデータがタグの最新のデータとなるように更新される。

ここで、情報処理装置３とタグ２とは近距離無線通信を行うので、タグ２に対するデータの書き込み中に通信が途絶えると（例えば、タグ２が情報処理装置３から離れてしまうと）、タグ２のデータが壊れてしまう（データが正しい内容を表さない）おそれがある。本変形例においては、タグ２のデータが壊れた場合、情報処理装置３は、バックアップデータを用いてタグ２のデータを復旧することができる。以下、データ復旧処理について説明する。

図２８は、データ復旧処理の流れの一例を示す図である。本変形例において、データ復旧処理は、アプリケーション部３１によって復旧指令が出力されたことに応じて開始される。ここで、アプリケーション部３１は、システムアプリケーションプログラムであってもよいし、他のアプリケーションであってもよい。例えば、システムアプリケーションプログラムの実行中において（例えば、メニュー画面の表示中において）、タグ２に対するデータ復旧を行う旨の指示がユーザによって行われる。この指示が受け付けられたことに応じて、アプリケーション部３１（システムアプリケーションプログラム）は復旧指令を出力する。また例えば、アプリケーションの実行中において、アプリケーション部３１がタグ２から取得したデータが壊れていた場合、アプリケーション部３１は復旧指令を出力する。

まずステップＳ１０１において、通信制御部３２は、接続中のタグ２からタグ２の識別情報（ＵＩＤ）を読み出す。ステップＳ１０１の読出処理は、上述のステップＳ２と同様の処理であってもよい。なお、ＵＩＤは読み出し専用領域２１に記憶されているので、データが壊れることがなく、正しい内容であることが保証されている。つまり、上記識別情報は、ＵＩＤあるいは固有ＩＤのように、読み出し専用領域２１に記憶されていることが好ましい。

ステップＳ１０２において、通信制御部３２は、情報処理装置３の上記記憶部に、通信中のタグ２のバックアップデータが記憶されているか否かを判定する。この判定は、ステップＳ１０１で読み出された識別情報に関連付けられたバックアップデータが記憶部に記憶されているか否かによって行うことができる。ステップＳ１０２の判定結果が否定である場合、ステップＳ１０３の処理が実行される。一方、ステップＳ１０２の判定結果が肯定である場合、ステップＳ１０４の処理が実行される。

ステップＳ１０３において、通信制御部３２は、バックアップデータが無い旨をアプリケーション部３１に通知する。この場合、例えば、アプリケーション部３１は、バックアップデータがないため復旧できない旨をユーザに通知する。ステップＳ１０３の後、通信制御部３２はデータ復旧処理を終了する。

ステップＳ１０４において、通信制御部３２は、通信中のタグ２に対応するバックアップデータを取得する。すなわち、通信制御部３２は、ステップＳ１０１で読み出された識別情報に関連付けられたバックアップデータを記憶部から読み出す。続くステップＳ１０５において、通信制御部３２は、ステップＳ１０４で取得したバックアップデータをタグ２に書き込む。

ステップＳ１０６において、通信制御部３２は、タグ２に対するデータの書き込みが成功したか否かを判定する。この判定は、例えば、データの書き込み中にタグ２との通信が切断されたか否かによって行うことができる。

ステップＳ１０６の判定結果が肯定である場合、ステップＳ１０７の処理が実行される。すなわち、ステップＳ１０７において、通信制御部３２は、データ復旧が成功したことをアプリケーション部３１に通知する。この場合、例えば、アプリケーション部３１は、データ復旧が成功したことをユーザに通知する。

一方、ステップＳ１０６の判定結果が否定である場合、ステップＳ１０８の処理が実行される。すなわち、ステップＳ１０８において、通信制御部３２は、データ復旧が失敗したことをアプリケーション部３１に通知する。この場合、例えば、アプリケーション部３１は、データ復旧が失敗したことをユーザに通知する。アプリケーション部３１は、再度データ復旧をやり直すことをユーザに促す通知を行ってもよい。

上記ステップＳ１０７またはＳ１０８の後、通信制御部３２はデータ復旧処理を終了する。以上のデータ復旧処理によって、情報処理装置３は、タグ２のデータを復旧することができる。ここで、本変形例においては、任意のアプリケーションが実行中である場合に（実行中のアプリケーションの種類にかかわらず）、タグ２のデータが壊れていた場合には、データ復旧処理が実行される。

上記変形例によれば、タグ２は、所定のアプリケーションプログラム（特定アプリプログラム）で利用可能なアプリ用データ（専用データ）を記憶する。情報処理装置３は、タグ２に記憶されるデータに対するバックアップデータを記憶する。また、情報処理装置３は、情報処理装置３と通信可能であるタグ２に記憶されているデータが壊れている場合、当該情報処理装置３において実行中のアプリケーションに関わらず、当該タグ２に記憶されているデータを、バックアップデータを用いて復旧する。

上記によれば、特定アプリプログラムの実行中でなくても（例えば、システムアプリケーションまたは非特定アプリの実行中であっても）、タグ２のデータが壊れていた場合には、特定アプリプログラムに対応するアプリ用データも含めてタグ２のデータが復旧される。したがって、特定アプリプログラムを実行せずともアプリ用データを復旧することができるので、より多くの機会にデータを復旧することができる。

なお、他の実施形態においては、情報処理装置３は、単一のタグ２について複数のバックアップデータを記憶しておくようにしてもよい。このとき、情報処理装置３は、タグ２のバックアップデータと関連付けて、バックアップデータを記憶した時の日時（日付のみでもよい）を記憶するようにしてもよい。この場合、情報処理装置３は、データ復旧処理において日時のデータを参照することによって、最後に記憶されたバックアップデータだけでなく、それよりも以前に記憶されたバックアップデータを用いてデータを復旧させることができる。すなわち、上記の場合、ステップＳ１０４において、通信制御部３２は、記憶部に記憶されている、通信中のタグ２に対応するバックアップデータを全て読み出す。そして、通信制御部３２は、読み出したバックアップデータに関連付けられる日時を表示し、復旧に用いるバックアップデータの日時をユーザに選択させる。さらに、ステップＳ１０５において、通信制御部３２は、ユーザが選択した日時に関連付けられるバックアップデータをタグ２に書き込む。これによって、ユーザは、バックアップの日時の異なる複数のバックアップデータから所望のものを選択してデータを復旧させることができる。

（ソフトウェア構成に関する変形例）
情報処理装置３は、タグ２に対する各種の設定処理（上述した初期登録の処理、データ復旧処理等）を実行するためのタグ設定プログラムを記憶しておき、当該タグ設定プログラムを実行することによって設定処理を実行するようにしてもよい。以下、情報処理装置３においてタグ設定プログラムが用意される変形例について説明する。

図２９は、本変形例における情報処理装置３において記憶されるプログラム構成の概要を示す図である。図２９に示すように、情報処理装置３は、システムアプリケーションプログラム（ここでは、「システムアプリケーション」と記載する。）と、タグ設定プログラムと、アプリケーションプログラム（ここでは、特定アプリプログラムおよび非特定アプリプログラムを指す）と、通信プログラムとを記憶している。

本変形例においては、タグ設定プログラムは、初期登録プログラムと、復旧プログラムと、データ消去プログラムと、初期化プログラムとを含む。なお、他の実施形態においては、タグ設定プログラムは、これらのプログラムのうちのいくつかのみを含んでいてもよいし、他のプログラムを含んでいてもよい。

初期登録プログラムは、通信制御部３２（通信プログラム）を用いて、上述した初期登録を実行するためのプログラムである。初期登録プログラムは、例えば、上述したステップＳ８３およびＳ８４の処理を実行するためのプログラムである。

復旧プログラムは、通信制御部３２（通信プログラム）を用いて、上述したタグ２のデータ復旧を実行するためのプログラムである。復旧プログラムは、例えば、上述の“（タグ２に記憶されるデータのバックアップをとる変形例）”で説明した変形例において、復旧指令を通信制御部３２に送る処理、および／または、通信制御部３２からの通知に基づいてユーザに対して通知を行う処理を実行するためのプログラムである。なお、他の実施形態においては、上記変形例におけるデータ復旧処理（図２８）において通信制御部３２が実行する処理のうち、一部の処理（例えば、ステップＳ１０２およびＳ１０４）は、復旧プログラムによって実行されてもよい。

データ消去プログラムは、タグ２の専用データの消去を実行するためのプログラムである。すなわち、情報処理装置３は、データ消去プログラムを実行することによって、タグ２の専用データを消去することができる。また、初期化プログラムは、タグ２の初期化（読み書き可能領域２２のデータの消去）を実行するためのプログラムである。すなわち、情報処理装置３は、初期化プログラムを実行することによって、タグ２の読み書き可能領域２２に記憶されているデータを消去することができる。したがって、上述した“（利用ＩＤを読み書き可能領域２２に記憶する変形例）”において初期化プログラムが実行される場合には、タグ２に設定された利用ＩＤを消去することができる。これによって、消去された利用ＩＤとは異なる利用ＩＤを新たにタグに対して設定することもできる。

本変形例において、システムアプリケーションおよび各アプリケーションプログラムは、タグ設定プログラムを用いて、タグ２に対する処理を実行する。タグ設定プログラムは、システムアプリケーションによって実行されるアプリケーションとして実行され、かつ、各アプリケーションプログラムにおいてアプレットとして実行されるものであってもよい。つまり、タグ設定プログラムは、システムアプリケーションから起動することができるとともに、各アプリケーションプログラムから起動することができるものであってもよい。このように、タグ設定プログラムを情報処理装置３において用意することによって、各アプリケーションプログラムにおいては、タグ設定プログラムによる機能を用意する必要がないので、アプリケーションの開発を容易にすることができる。

システムアプリケーションからタグ設定プログラムを起動する場合には、タグ設定プログラムに含まれる上記４つのプログラムのいずれかをユーザが指定して実行するようにしてもよい。例えば、システムアプリケーションによるメニュー画面においてタグ設定プログラムが指定されて起動した場合、「初期登録」、「データ復旧」、「データ消去」、および「初期化」という４つの項目が表示されてもよい。このとき、ユーザが選択した項目に応じたプログラムが実行されることで、項目に応じた処理が実行される。

一方、アプリケーションプログラムからタグ設定プログラムを起動する場合には、当該アプリケーションプログラムが、タグ設定プログラムに含まれる上記４つのプログラムのいずれかを状況に応じて選択して実行してもよい。例えば、特定アプリであるアプリケーションプログラムが専用データをタグ２に書き込もうとした際に、タグ２において初期登録データが記憶されていなかった場合には、初期登録プログラムを実行することによって、タグ２に初期登録データを書き込むようにしてもよい。

（タグに記憶されるデータの暗号化に関する変形例）
他の実施形態においては、タグ２に記憶されるデータは、一部のデータが暗号化されていなくてもよいし、一部のデータが他のデータとは異なる暗号方式で暗号化されていてもよい。例えば、タグ２の外観が表すキャラクタ（オブジェクト）を示す情報（例えば、上述のフィギュアＩＤ）は、暗号化されずにタグ２に記憶されてもよい。これによれば、タグ２に記憶された暗号化データを復合する機能を有する情報処理装置のみならず、当該機能を持たない情報処理装置によっても、キャラクタを示す情報を読み出すことができ、タグ２を用いて処理を実行することができる。つまり、タグ２の汎用性をより向上することができる。また、キャラクタを示す情報は、タグ２の外観から認識することができる情報であるので、暗号化しなくてもセキュリティ上大きな問題はないと考えられる。

上記のように、タグ２は、所定のオブジェクトを立体的または平面的に表す外観を有する。また、タグ２は、上記所定のオブジェクトを示すオブジェクト情報（フィギュアＩＤ）を、暗号化されない状態で記憶するとともに、オブジェクト情報とは異なる他の情報を暗号化された状態で記憶する。情報処理装置３は、タグ２に記憶されているオブジェクト情報を用いて、上記オブジェクトを表示装置に表示させる処理を実行する。これによれば、上記のように、タグの汎用性を向上することができる。

なお、オブジェクト情報は、他の情報とは異なる暗号化方式で記憶されてもよい。すなわち、タグ２は、上記オブジェクト情報とは異なる他の情報を、第１の方法で暗号化された状態で記憶し、オブジェクト情報を、第１の方法とは異なる第２の方法で暗号化された状態で記憶してもよい。このとき、例えば、第２の方法の暗号化に対応する復号機能として、第１の方法の暗号化に対応する復号機能よりも利用しやすい（例えば、無償で提供される）機能を採用することによって、上記と同様、タグの汎用性を向上することができる。

また、上記においては、異なる２種類の情報処理装置においてタグ２を利用することができる。例えば、第１の情報処理装置は、第１の方法で暗号化された情報を復号する機能を有さず、第２の方法で暗号化された情報を復号する第２復号処理手段を備えるものとする。また、第２の情報処理装置は、第１の方法で暗号化された情報を復号する第１復号処理手段と、第２の方法で暗号化された情報を復号する第２復号処理手段とを備えるものとする。ただし、オブジェクト情報が暗号化されていない場合には、各情報処理装置は第２復号処理手段を備えていなくてもよい。このとき、第１の情報処理装置は、タグ２に記憶されているオブジェクト情報を用いることができ、第２の情報処理装置は、タグ２に記憶されているオブジェクト情報および上記他の情報を用いることができる。これによれば、第２の情報処理装置（例えば、タグ２に対応した専用の情報処理装置）によってタグ２に記憶されている各種情報を用いることができるとともに、第１の情報処理装置（例えば、近距離無線通信の機能を有する汎用の情報処理装置）においてもタグ２を利用することができる。

（アプリケーションプログラムによる処理に関する変形例）
上述したように、１つのキャラクタ（オブジェクト）に複数の種類がある場合、タグ２に記憶されるキャラクタを示す情報（上記フィギュアＩＤ）は、当該複数の種類を１グループとしてキャラクタを示す第１ＩＤと、種類毎に異なる第２ＩＤとを含んでいてもよい。このとき、アプリケーション部３１は、タグ２に記憶されるデータ（共用データ）を用いる処理として、フィギュアＩＤの一部に基づいて情報処理を実行してもよい。具体的には、アプリケーション部３１は、上記第１ＩＤに基づいて情報処理を実行してもよい。この情報処理の内容は任意であるが、例えば、第１ＩＤに応じて異なる内容が実行され、かつ、第１ＩＤが同じであれば、第２ＩＤが異なっていても同じ内容が実行される処理である。具体的には、アプリケーション部３１は、ゲームアプリケーションにおいて、第１ＩＤに基づいてアイテムを登場させる処理を実行してもよい。このとき、アプリケーション部３１は、タグ２から読み出される第１ＩＤが同じであれば、第２ＩＤが異なっていても同じアイテムを登場させる。上記によれば、アプリケーション部３１は、同じグループに属する複数の種類のキャラクタについて同じ処理を実行することができる。

また、アプリケーション部３１は、所定のタグ２と通信が行われたことを条件として、実行中のアプリケーションにおける設定を変更するようにしてもよい。例えばゲームアプリケーションにおいて、アプリケーション部３１は、設定を変更することによって、ゲームにおいて利用できるキャラクタまたはアイテムを増加させたり、新たなステージをユーザがプレイできるように変更したりする。

ここで、変更された設定内容は、情報処理装置３において保存（記憶）されてもよい。これによれば、ユーザは、アプリケーションを起動する度に、情報処理装置３とタグ２とを通信させる必要がないので、タグ２の利便性を向上することができる。また、アプリケーション部３１は、タグ２によってアプリケーションの設定を変更する処理を、（タグ２と現在通信中の情報処理装置とは異なる）他の情報処理装置において当該タグ２によって当該アプリケーションの設定が変更されたか否かに関わらず、実行するようにしてもよい。これによれば、ユーザは、１つのタグを用いて、複数の情報処理装置において実行される各アプリケーションの設定を変更することができるので、タグの利便性を向上することができる。

なお、他の実施形態においては、アプリケーション部３１は、タグ２によって変更された設定を情報処理装置３において保存しないようにしてもよい。この場合、アプリケーションが起動される度に上記設定はデフォルトの設定に戻されるので、設定を変更するためには、起動の度にタグ２を用いる（情報処理装置３とタグ２とを通信させる）ことが要求されることになる。

また、他の実施形態においては、タグ２によってアプリケーションの設定が変更された場合、アプリケーション部３１は、設定を変更したことを示す設定変更情報をタグ２に書き込むようにしてもよい。このとき、アプリケーション部３１は、（タグ２と現在通信中の情報処理装置とは異なる）他の情報処理装置においてタグ２によってアプリケーションの設定が変更されていないことを条件として、当該タグ２によって当該アプリケーションの設定を変更する処理を実行するようにしてもよい。

本実施形態は、記憶媒体をより汎用的に利用すること等を目的として、例えばゲームアプリケーション等を実行するゲーム装置やゲームシステム、あるいは、ゲームデータを記憶する記憶媒体等として利用することができる。

１ 情報処理システム
２ タグ（記憶媒体）
３ 情報処理装置
１１ 通信部
１２ 通信チップ
１３ ＣＰＵ
１４ メモリ
１５ プログラム記憶部
１６ 入力部
１７ 表示部
２１ 読み出し専用領域
２２ 読み書き可能領域
３１ アプリケーション部
３２ 通信制御部

Claims (13)

1. 記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムであって、
   前記記憶媒体は、所定のゲームアプリケーションプログラムで利用可能なアプリ用データと、当該所定のゲームアプリケーションプログラムであるか他のゲームアプリケーションプログラムであるかにかかわらず利用可能な共用データとを記憶する記憶手段を備え、
   前記情報処理装置で実行されるゲームアプリケーションプログラムから、前記記憶手段に対するデータの読み出しに関する指令を受け付ける受付手段と、
   受け付けられた指令が前記アプリ用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であることを条件として、前記記憶手段から読み出した前記アプリ用データを当該所定のゲームアプリケーションプログラムに渡す第１処理手段と、
   受け付けられた指令が前記共用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であるか他のゲームアプリケーションプログラムであるかにかかわらず、前記記憶手段から読み出した前記共用データを指令元のゲームアプリケーションプログラムに渡す第２処理手段とを備える、情報処理システム。
2. 前記記憶手段は、前記記憶媒体の種類毎に設定される識別情報を記憶しており、
   前記所定のゲームアプリケーションプログラムは、自身がアプリ用データを利用可能な種類の記憶媒体に設定される識別情報を含んでおり、
   前記第１処理手段は、前記記憶手段から読み出した識別情報と、指令元のゲームアプリケーションプログラムから取得した識別情報とに基づいて、受け付けられた指令が前記所定のゲームアプリケーションプログラムからの指令であるか否かを判定する、請求項１に記載の情報処理システム。
3. 前記記憶手段は、前記アプリ用データを利用可能な１種類以上の所定のゲームアプリケーションプログラムを特定するための識別情報を記憶しており、
   前記受付手段は、指令元のゲームアプリケーションプログラムに対応する識別情報を当該ゲームアプリケーションプログラムから受け付け、
   前記第１処理手段は、前記記憶手段に記憶されている識別情報と、指令元のゲームアプリケーションプログラムから取得した識別情報とに基づいて、受け付けられた指令が前記所定のゲームアプリケーションプログラムからの指令であるか否かを判定する、請求項１に記載の情報処理システム。
4. 前記記憶手段は、前記第１処理手段によって復号可能な方式で暗号化されたアプリ用データおよび前記第２処理手段によって復号可能な方式で暗号化された共用データを記憶する、請求項１から請求項３のいずれか１項に記載の情報処理システム。
5. 前記記憶媒体は、前記所定のゲームアプリケーションプログラムを実行することによって生成される仮想空間に登場するオブジェクトであって前記アプリ用データおよび／または前記共用データが表すオブジェクトを立体的または平面的に表す外観を有する、請求項１から請求項４のいずれか１項に記載の情報処理システム。
6. 前記記憶手段は、前記共用データとして、前記オブジェクトの識別情報、当該オブジェクトが属するグループの識別情報、記憶媒体毎に固有の識別情報、および、前記記憶媒体の種類を示す識別情報のうち少なくとも１つのデータを記憶する、請求項５に記載の情報処理システム。
7. 前記情報処理装置は、ある記憶媒体との間で近距離無線通信が可能となった場合、当該記憶媒体が当該情報処理装置からのアクセスが許可される許可記憶媒体であるか否かを判定する判定手段を備え、
   前記受付手段は、近距離無線通信が可能となった記憶媒体が許可記憶媒体であると判定された場合、前記情報処理装置で実行されるゲームアプリケーションプログラムからの前記指令に応じた処理を実行する、請求項１から請求項６のいずれか１項に記載の情報処理システム。
8. 前記記憶媒体は、データの読み出しが可能でかつ書き込みが不可能な読み出し専用領域に前記共用データの少なくとも一部を記憶し、データの読み出しおよび書き込みが可能な読み書き可能領域に前記アプリ用データを記憶する、請求項１から請求項７のいずれか１項に記載の情報処理システム。
9. 前記アプリ用データは、前記所定のゲームアプリケーションプログラムのセーブデータである、請求項１から請求項８のいずれか１項に記載の情報処理システム。
10. 前記記憶媒体は、それに記憶されるデータの一部または全部に対するハッシュ値を記憶しており、
    前記判定手段は、前記記憶媒体から読み出したデータに基づいて算出されるハッシュ値と、当該記憶媒体から読み出したハッシュ値とに基づいて、前記記憶媒体が許可記憶媒体であるか否かを判定する、請求項７に記載の情報処理システム。
11. 記憶媒体と近距離無線通信を行う情報処理装置であって、
    前記記憶媒体は、所定のゲームアプリケーションプログラムで利用可能なアプリ用データと、当該所定のゲームアプリケーションプログラムであるか他のゲームアプリケーションプログラムであるかにかかわらず利用可能な共用データとを記憶する記憶手段を備え、
    前記情報処理装置で実行されるゲームアプリケーションプログラムから、前記記憶手段に対するデータの読み出しに関する指令を受け付ける受付手段と、
    受け付けられた指令が前記アプリ用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であることを条件として、前記記憶手段から読み出した前記アプリ用データを当該所定のゲームアプリケーションプログラムに渡す第１処理手段と、
    受け付けられた指令が前記共用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であるか他のゲームアプリケーションプログラムであるかにかかわらず、前記記憶手段から読み出した前記共用データを指令元のゲームアプリケーションプログラムに渡す第２処理手段とを備える、情報処理装置。
12. 記憶媒体と近距離無線通信を行う情報処理装置のコンピュータによって実行される情報処理プログラムであって、
    前記記憶媒体は、所定のゲームアプリケーションプログラムで利用可能なアプリ用データと、当該所定のゲームアプリケーションプログラムであるか他のゲームアプリケーションプログラムであるかにかかわらず利用可能な共用データとを記憶する記憶手段を備え、
    前記情報処理装置で実行されるゲームアプリケーションプログラムから、前記記憶手段に対するデータの読み出しに関する指令を受け付ける受付手段と、
    受け付けられた指令が前記アプリ用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であることを条件として、前記記憶手段から読み出した前記アプリ用データを当該所定のゲームアプリケーションプログラムに渡す第１処理手段と、
    受け付けられた指令が前記共用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であるか他のゲームアプリケーションプログラムであるかにかかわらず、前記記憶手段から読み出した前記共用データを指令元のゲームアプリケーションプログラムに渡す第２処理手段として前記コンピュータを機能させる、情報処理プログラム。
13. 記憶媒体と、当該記憶媒体と近距離無線通信を行う情報処理装置とを含む情報処理システムにおいて実行される情報処理方法であって、
    前記記憶媒体は、所定のゲームアプリケーションプログラムで利用可能なアプリ用データと、当該所定のゲームアプリケーションプログラムであるか他のゲームアプリケーションプログラムであるかにかかわらず利用可能な共用データとを記憶する記憶手段を備え、
    前記情報処理装置で実行されるゲームアプリケーションプログラムから、前記記憶手段に対するデータの読み出しに関する指令を受け付ける受付ステップと、
    受け付けられた指令が前記アプリ用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であることを条件として、前記記憶手段から読み出した前記アプリ用データを当該所定のゲームアプリケーションプログラムに渡す第１処理ステップと、
    受け付けられた指令が前記共用データに関する指令である場合、当該指令が前記所定のゲームアプリケーションプログラムからの指令であるか他のゲームアプリケーションプログラムであるかにかかわらず、前記記憶手段から読み出した前記共用データを指令元のゲームアプリケーションプログラムに渡す第２処理ステップとを備える、情報処理方法。
    
    

Images