(57)【要約】【課題】近接通信を行う通信装置が本来有している能力を十分に発揮することができるようにする。【解決手段】  イニシエータは、NFCIP-1に従って、ターゲットと近接通信を行う。例えば、イニシエータは、イニシエータ自身またはターゲットが有する所定のn+1種類の能力のそれぞれについて、対応する能力に関連する情報を１以上含むカプセル[0]乃至[n]を生成する（Ｓ６１）。次に、イニシエータは、生成されたカプセル[0]乃至[n]を含むコマンドATR_REQを生成する（Ｓ６２乃至Ｓ６４）。そして、イニシエータは、コマンドATR_REQをターゲットに送信する。本発明は、例えば、ICカードシステムなどに適用できる。【選択図】図２０
2006211519.tif 000002
【特許請求の範囲】
【請求項１】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置において、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御手段
を備えることを特徴とする通信装置。
【請求項２】
前記通信プロトコルは、前記通信装置および前記他の通信装置が有すべきまたは有することが可能な属性をさらに規定し、１以上の前記コマンドのうちの１つとして、前記属性を通信相手に通知するまたは要求するための属性コマンドを少なくとも規定し、１以上の前記コマンドのうちの１つとして、前記属性コマンドに対する属性レスポンスを少なくとも規定しており、
前記制御手段は、前記通信プロトコルに前記属性として規定されている種類とは異なるｎ+1種類（nは、０以上の整数値）の能力のそれぞれについて、対応する種類の能力に関連する情報を１以上含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドまたは前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記他の通信装置が有しているまたは有することが可能なレベルを前記通信装置自身に対して通知する指示を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項５】
前記他の通信装置により、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを前記他の通信装置に対して通知する指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個の前記データ群が前記属性コマンドに格納されて前記通信装置自身に送信されてきた場合、
前記制御手段は、
前記属性コマンドを前記通信装置自身が受信する制御をさらに行い、
受信された前記属性コマンドに格納されたn+1個の前記データ群のそれぞれに含まれる前記指示に基づいて、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項６】
前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力の活性化を前記他の通信装置が行うことの指示を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項７】
前記他の通信装置により、n+1種類の能力のそれぞれについて、対応する能力の活性化を前記通信装置自身が行うことの指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個の前記データ群が前記属性コマンドに格納されて前記通信装置自身に送信されてきた場合、
前記制御手段は、
前記属性コマンドを前記通信装置自身が受信する制御をさらに行い、
受信された前記属性コマンドに格納されたn+1個の前記データ群のそれぞれに含まれる前記指示に基づいて、n+1種類の能力のそれぞれの活性化を行うための制御をさらに行い、
n+1種類の能力のそれぞれについて、対応する種類の能力の活性化の結果を示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項８】
前記コマンドまたは前記レスポンスに格納される１以上のデータ群のそれぞれに含まれる情報により特定される１種類以上の能力のうちの１種類は、前記通信装置または前記他の通信装置が出力する電磁波の電力の制御を行う能力である
ことを特徴とする請求項１に記載の通信装置。
【請求項９】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置の通信方法において、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ
を含むことを特徴とする通信方法。
【請求項１０】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置を制御するコンピュータに実行させるプログラムにおいて、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ
を含むことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法、およびプログラムに関し、例えば、近接通信を行う通信装置が本来有している能力を十分に発揮することができるようにする通信装置、通信方法、およびプログラムに関する。
【背景技術】
【０００２】
近接通信を行うシステムとしては、例えば、IC(Integrated Circuit)カードシステムが広く知られている。ICカードシステムにおいては、リーダ／ライタが電磁波を発生することにより、いわゆるRF(Radio Frequency)フィールド（磁界）を形成する。そして、リーダ／ライタに、ICカードが近づくと、ICカードは、電磁誘導によって、電源の供給を受けるとともに、リーダ／ライタとの間でデータ伝送を行う。
【０００３】
かかるICカードシステムに代表される近接通信を行うための通信プロトコルとしては、例えば、NFCIP(Near Field Communication Interface and Protocol)-1がある。なお、NFCIP-1は、ISO/IEC 18092としても規定されている。
【０００４】
NFCIP-1には、データを送受信する複数の通信装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の通信装置のうちの１の通信装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、複数の通信装置のうちの他の通信装置において、１の通信装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとが規定されており、NFCIP-1に準拠した複数の通信装置どうしは、アクティブモードまたはパッシブモードのうちのいずれかの通信モードで通信を行う（例えば、特許文献１や非特許文献１参照）。
【０００５】
【特許文献１】特開2004-215225号公報
【非特許文献１】Standard ECMA-340, "Near Field Communication Interface and Protocol(NFCIP-1)", 2nd Edition, December 2004, ECMA
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、複数の通信装置がNFCIP-1に準拠した通信を行う場合、複数の通信装置のうちの少なくとも１つが、NFCIP-1で規定されている能力群以上の能力を本来有していたとしても、本来有している能力を十分に発揮できていない、という課題があった。
【０００７】
本発明は、このような状況に鑑みてなされたものであり、近接通信を行う通信装置が本来有している能力を十分に発揮することができるようにするものである。
【課題を解決するための手段】
【０００８】
本発明の通信装置は、データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置であって、通信装置自身または他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上のデータ群を、通信プロトコルで規定されている１以上のコマンドおよび１以上のレスポンスのうちの所定の１つに格納させて、他の通信装置に送信する制御を行う制御手段を備えることを特徴とする。
【０００９】
通信プロトコルは、通信装置および他の通信装置が有すべきまたは有することが可能な属性をさらに規定し、１以上のコマンドのうちの１つとして、その属性を通信相手に通知するまたは要求するための属性コマンドを少なくとも規定し、１以上のコマンドのうちの１つとして、属性コマンドに対する属性レスポンスを少なくとも規定しており、制御手段は、通信プロトコルに属性として規定されている種類とは異なるn+1種類（nは、０以上の整数値）の能力のそれぞれについて、対応する種類の能力に関連する情報を１以上含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性コマンドまたは属性レスポンスに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１０】
制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性コマンドに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１１】
制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、他の通信装置が有しているまたは有することが可能なレベルを通信装置自身に対して通知する指示を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性コマンドに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１２】
他の通信装置により、n+1種類の能力のそれぞれについて、対応する種類の能力についての、通信装置自身が有しているまたは有することが可能なレベルを他の通信装置に対して通知する指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個のデータ群が属性コマンドに格納されて通信装置自身に送信されてきた場合、制御手段は、属性コマンドを通信装置自身が受信する制御をさらに行い、受信された属性コマンドに格納されたn+1個のデータ群のそれぞれに含まれる指示に基づいて、n+1種類の能力のそれぞれについて、対応する種類の能力についての、通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性レスポンスに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１３】
制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力の活性化を他の通信装置が行うことの指示を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性コマンドに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１４】
他の通信装置により、n+1種類の能力のそれぞれについて、対応する能力の活性化を通信装置自身が行うことの指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個のデータ群が属性コマンドに格納されて通信装置自身に送信されてきた場合、制御手段は、属性コマンドを通信装置自身が受信する制御をさらに行い、受信された属性コマンドに格納されたn+1個のデータ群のそれぞれに含まれる指示に基づいて、n+1種類の能力のそれぞれの活性化を行うための制御をさらに行い、n+1種類の能力のそれぞれについて、対応する種類の能力の活性化の結果を示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個のデータ群を、属性レスポンスに格納させて、他の通信装置に送信する制御を行うようにすることができる。
【００１５】
コマンドまたはレスポンスに格納される１以上のデータ群のそれぞれに含まれる情報により特定される１種類以上の能力のうちの１種類は、通信装置または他の通信装置が出力する電磁波の電力の制御を行う能力であるようにすることができる。
【００１６】
本発明の通信方法は、データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、複数の装置のうちの他の装置において、１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置の通信方法であって、通信装置自身または他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上のデータ群を、通信プロトコルで規定されている１以上のコマンドおよび１以上のレスポンスのうちの所定の１つに格納させて、他の通信装置に送信する制御を行う制御ステップを含むことを特徴とする。
【００１７】
本発明のプログラムは、データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、複数の装置のうちの他の装置において、１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置を制御するコンピュータに実行させるプログラムであって、通信装置自身または他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上のデータ群を、通信プロトコルで規定されている１以上のコマンドおよび１以上のレスポンスのうちの所定の１つに格納させて、他の通信装置に送信する制御を行う制御ステップを含むことを特徴とする。
【００１８】
本発明の通信装置および通信方法並びにプログラムにおいては、データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、複数の装置のうちの他の装置において、１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信装置と、その通信相手である他の通信装置との間で通信が行われる。詳細には、通信装置自身または他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群が能力の種類毎にそれぞれ生成され、生成された１以上のデータ群が、通信プロトコルで規定されている１以上のコマンドおよび１以上のレスポンスのうちの所定の１つに格納されて、他の通信装置に送信される。
【発明の効果】
【００１９】
本発明によれば、通信装置が、他の通信装置と近接通信を行うことが可能になる。特に、近接通信を行う通信装置が本来有している能力を十分に発揮することが可能になる。
【発明を実施するための最良の形態】
【００２０】
以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２１】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００２２】
請求項１に記載の通信装置は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコル（例えば、NFCIP-1）に従って、通信相手である他の通信装置と通信を行う通信装置（例えば、通信装置は、図１と図４のNFC通信装置１であり、他の通信装置は、図１のNFC通信装置２または３である）において、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群（例えば、図１２のカプセル５１）を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンス（例えば、図８に示されるコマンドまたはレスポンス）のうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御手段（例えば、図４の制御部２１）
を備えることを特徴とする。
【００２３】
請求項２に記載の通信装置において、
前記通信プロトコルは、前記通信装置および前記他の通信装置が有すべきまたは有することが可能な属性（例えば、図１５の「kbps]の項目に規定されている伝送レート」をさらに規定し、１以上の前記コマンドのうちの１つとして、前記属性を通信相手に通知するまたは要求するための属性コマンド（例えば、図１３の構造のコマンドATR_REQ）を少なくとも規定し、１以上の前記コマンドのうちの１つとして、前記属性コマンドに対する属性レスポンス（例えば、図１９の構造のレスポンスATR_REQ）を少なくとも規定しており、
前記制御手段は、前記通信プロトコルに前記属性として規定されている種類とは異なるn+1種類（nは、０以上の整数値）の能力のそれぞれについて、対応する種類の能力に関連する情報を１以上含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドまたは前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
ようにすることができる。
【００２４】
請求項９に記載の通信方法は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置（例えば、通信装置は、図１と図４のNFC通信装置１であり、他の通信装置は、図１のNFC通信装置２または３である）の通信方法において、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ（例えば、図２０のイニシエータ側のATR_REQ送信処理や、図２１のターゲット側のATR_REQ受信処理のうちの特にステップＳ８６以降の処理）
を含むことを特徴とする通信方法。
【００２５】
請求項１０に記載のプログラムは、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置（例えば、通信装置は、図１と図４のNFC通信装置１であり、他の通信装置は、図１のNFC通信装置２または３である）を制御するコンピュータに実行させるプログラム（例えば、図４のCPU２１Ａ）において、
前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ（例えば、図２０のイニシエータ側のATR_REQ送信処理や、図２１のターゲット側のATR_REQ受信処理のうちの特にステップＳ８６以降の処理）
を含むことを特徴とする。
【００２６】
以下、図面を参照して、本発明の実施の形態について説明する。
【００２７】
図１は、本発明を適用した通信システム（システムとは、複数の装置が論理的に結合したもの物をいい、各構成の装置が同一筐体中にあるか否かは問わない）の一実施の形態の構成例を示している。
【００２８】
図１においては、通信システムは、３つのNFC通信装置１，２，３から構成されている。NFC通信装置１乃至３それぞれは、他のNFC通信装置との間で、単一の周波数の搬送波を使用した、電磁誘導による近接通信（NFC(Near Field Communication)）を行うことができるようになっている。
【００２９】
ここで、NFC通信装置１乃至３が使用する搬送波の周波数としては、例えば、ISM(Industrial Scientific Medical)バンドの13.56MHzなどを採用することができる。
【００３０】
また、近接通信とは、通信する装置どうしの距離が、数10cm以内となって可能となる通信を意味し、通信する装置どうし（の筐体）が接触して行う通信も含まれる。
【００３１】
なお、図１の通信システムは、NFC通信装置１乃至３のうちの１以上をリーダ／ライタとするとともに、他の１以上をICカードとするICカードシステムとして採用することができることは勿論、NFC通信装置１乃至３それぞれを、PDA(Personal Digital Assistant)、PC（Personal Computer）、携帯電話、腕時計、ペン等の通信システムとして採用することも可能である。即ち、NFC通信装置１乃至３は、近接通信を行う装置であり、ICカードシステムのICカードやリーダ／ライタなどに限定されるものではない。
【００３２】
NFC通信装置１乃至３は、２つの通信モードによる通信が可能である。２つの通信モードとしては、パッシブモードとアクティブモードとがある。いま、NFC通信装置１乃至３のうちの、例えば、NFC通信装置１と２の間の通信に注目すると、パッシブモードでは、上述した従来のICカードシステムと同様に、NFC通信装置１と２のうちの一方のNFC通信装置である、例えば、NFC通信装置１は、自身が発生する電磁波（に対応する搬送波）を変調することにより、他方のNFC通信装置であるNFC通信装置２にデータを送信し、NFC通信装置２は、NFC通信装置１が発生する電磁波（に対応する搬送波）を負荷変調することにより、NFC通信装置１にデータを送信する。
【００３３】
一方、アクティブモードでは、NFC通信装置１と２のいずれも、自身が発生する電磁波（に対応する搬送波）を変調することにより、データを送信する。
【００３４】
ここで、電磁誘導による近接通信を行う場合、最初に電磁波を出力して通信を開始し、いわば通信の主導権を握る装置を、イニシエータと呼ぶ。イニシエータは、通信相手にコマンドを送信し、その通信相手は、そのコマンドに対するレスポンスを返す形で、近接通信が行われるが、イニシエータからのコマンドに対するレスポンスを返す通信相手を、ターゲットと呼ぶ。
【００３５】
例えば、いま、NFC通信装置１が電磁波の出力を開始して、NFC通信装置２との通信を開始したとすると、図２および図３に示すように、NFC通信装置１がイニシエータとなり、NFC通信装置２がターゲットとなる。
【００３６】
そして、パッシブモードでは、図２に示すように、イニシエータであるNFC通信装置１が電磁波を出力し続け、NFC通信装置１は、自身が出力している電磁波を変調することにより、ターゲットであるNFC通信装置２に、データを送信するとともに、NFC通信装置２は、イニシエータであるNFC通信装置１が出力している電磁波を負荷変調することにより、NFC通信装置１に、データを送信する。
【００３７】
一方、アクティブモードでは、図３に示すように、イニシエータであるNFC通信装置１は、自身がデータを送信する場合に、自身で電磁波の出力を開始し、その電磁波を変調することにより、ターゲットであるNFC通信装置２に、データを送信する。そして、NFC通信装置１は、データの送信終了後は、電磁波の出力を停止する。ターゲットであるNFC通信装置２も、自身がデータを送信する場合に、自身で電磁波の出力を開始し、その電磁波を変調することにより、ターゲットであるNFC通信装置２に、データを送信する。そして、NFC通信装置２は、データの送信終了後は、電磁波の出力を停止する。
【００３８】
なお、図１では、３つのNFC通信装置１乃至３によって、通信システムが構成されているが、通信システムを構成するNFC通信装置は、３つに限定されるものではなく、２または４以上であっても良い。さらに、通信システムは、NFC通信装置の他、例えば、従来のICカードシステムを構成するICカードやリーダ／ライタなどを含めて構成することも可能である。
【００３９】
次に、図４は、図１のNFC通信装置１の構成例を示している。なお、図１の他のNFC通信装置２および３も、図４のNFC通信装置１と同様に構成されるため、その説明は、省略する。
【００４０】
アンテナ１１は、閉ループのコイルを構成しており、このコイルに流れる電流が変化することで、電磁波を出力する。また、アンテナ１１としてのコイルを通る磁束が変化することで、アンテナ１１に電流が流れる。
【００４１】
受信部１２は、アンテナ１１に流れる電流を受信し、同調と検波を行い、復調部１３に出力する。復調部１３は、受信部１２から供給される信号を復調し、デコード部１４に供給する。デコード部１４は、復調部１３から供給される信号としての、例えばマンチェスタ符号などをデコードし、そのデコードの結果得られるデータを、データ処理部１５に供給する。
【００４２】
データ処理部１５は、デコード部１４から供給されるデータに基づき、所定の処理を行う。また、データ処理部１５は、他の装置に送信すべきデータを、エンコード部１６に供給する。
【００４３】
エンコード部１６は、データ処理部１５から供給されるデータを、例えば、マンチェスタ符号などにエンコードし、選択部１７に供給する。選択部１７は、変調部１９または負荷変調部２０のうちのいずれか一方を選択し、その選択した方に、エンコード部１６から供給される信号を出力する。
【００４４】
ここで、選択部１７は、制御部２１の制御にしたがって、変調部１９または負荷変調部２０を選択する。制御部２１は、通信モードがパッシブモードであり、NFC通信装置１がターゲットとなっている場合は、選択部１７に負荷変調部２０を選択させる。また、制御部２１は、通信モードがアクティブモードである場合、または通信モードがパッシブモードであり、かつ、NFC通信装置１がイニシエータとなっている場合は、選択部１７に変調部１９を選択させる。従って、エンコード部１６が出力する信号は、通信モードがパッシブモードであり、NFC通信装置１がターゲットとなっているケースでは、選択部１７を介して、負荷変調部２０に供給されるが、他のケースでは、選択部１７を介して、変調部１９に供給される。
【００４５】
電磁波出力部１８は、アンテナ１１から、所定の単一の周波数の搬送波（の電磁波）を放射させるための電流を、アンテナ１１に流す。変調部１９は、電磁波出力部１８がアンテナ１１に流す電流としての搬送波を、選択部１７から供給される信号にしたがって変調する。これにより、アンテナ１１からは、データ処理部１５がエンコード部１６に出力したデータにしたがって搬送波を変調した電磁波が放射される。
【００４６】
負荷変調部２０は、外部からアンテナ１１としてのコイルを見たときのインピーダンスを、選択部１７から供給される信号にしたがって変化させる。他の装置が搬送波としての電磁波を出力することにより、アンテナ１１の周囲にRFフィールド（磁界）が形成されている場合、アンテナ１１としてのコイルを見たときのインピーダンスが変化することにより、アンテナ１１の周囲のRFフィールドも変化する。これにより、他の装置が出力している電磁波としての搬送波が、選択部１７から供給される信号にしたがって変調（負荷変調）され、データ処理部１５がエンコード部１６に出力したデータが、電磁波を出力している他の装置に送信される。
【００４７】
ここで、変調部１９および負荷変調部２０における変調方式としては、例えば、振幅変調(ASK(Amplitude Shift Keying))を採用することができる。但し、変調部１９および負荷変調部２０における変調方式は、ASKに限定されるものではなく、PSK(Phase Shift Keying)やQAM(Quadrature Amplitude Modulation)その他を採用することが可能である。また、振幅の変調度についても8％から30％、50％、100％等数値に限定されることはなく、好適なものを選択すれば良い。
【００４８】
制御部２１は、NFC通信装置１を構成する各ブロックの制御等を行う。即ち、制御部２１は、例えば、CPU(Central Processing Unit)２１Ａや、EEPROM(Electrically and Erasable Programmable Read Only Memory)２１Ｂ、その他図示せぬRAM(Random Access Memory)などで構成される。CPU２１Ａは、EEPROM２１Ｂに記憶されているプログラムを実行し、これにより、NFC通信装置１を構成する各ブロックの制御、その他の各種の処理を行う。EEPROM２１Ｂは、CPU２１Ａが実行すべきプログラムや、CPU２１Ａの動作上必要なデータを記憶する。
【００４９】
なお、CPU２１Ａがプログラムを実行することにより行う一連の処理は、CPU２１Ａに代えて専用のハードウェアを設けて、その専用のハードウェアによって行うことが可能である。また、CPU２１Ａに実行させるプログラムは、EEPROM２１Ｂにあらかじめインストールしておく他、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）し、いわゆるパッケージソフトウエアとして提供することができる。さらに、プログラムは、近接通信によって、NFC通信装置１に送信し、EEPROM２１Ｂにインストールすることができる。
【００５０】
電源部２２は、NFC通信装置１を構成する各ブロックに、必要な電源を供給する。なお、図４では、制御部２１がNFC通信装置１を構成する各ブロックを制御することを表す線の図示と、電源部２２がNFC通信装置１を構成する各ブロックに電源を供給することを表す線の図示は、図が煩雑になるため、省略してある。また、電源部２２は、電池（バッテリ）を内蔵していても良いし、電池を内蔵せずに、アンテナ１１に流れる電流から電源となる電力を得るものであっても良い。但し、後者の場合には、NFC通信装置１は、パッシブモードのターゲットとしてのみ動作する。
【００５１】
ここで、上述の場合には、デコード部１４およびエンコード部１６において、マンチェスタ符号を処理するようにしたが、デコード部１４およびエンコード部１６では、マンチェスタ符号だけでなく、例えば、モディファイドミラーや、NRZ(Non Return to Zero)などの複数種類の符号の中から１つを選択して処理するようにすることが可能である。
【００５２】
次に、NFC通信装置１乃至３は、いずれも、最初に電磁波を出力して通信を開始するイニシエータになり得る。さらに、アクティブモードでは、NFC通信装置１乃至３は、イニシエータとなる場合でも、ターゲットとなる場合でも、自身で電磁波を出力する。
【００５３】
従って、NFC通信装置１乃至３が近接している状態で、そのうちの２以上が同時に電磁波を出力した場合には、コリジョン(collision)が生じ、通信を行うことができなくなる。
【００５４】
そこで、NFC通信装置１乃至３それぞれは、他の装置からの電磁波（によるRFフィールド）が存在するかどうかを検出し、存在しない場合にのみ、電磁波の出力を開始し、これにより、コリジョンを防止するようになっている。ここで、このように、他の装置からの電磁波が存在するかどうかを検出し、存在しない場合にのみ、電磁波の出力を開始する処理を、コリジョンを防止するという目的から、RFCA(RF Collision Avoidance)処理という。
【００５５】
RFCA処理には、イニシエータとなろうとするNFC通信装置（図１では、NFC通信装置１乃至３のうちの１以上）が最初に行う初期RFCA処理と、アクティブモードでの通信中において、電磁波の出力を開始するNFC通信装置が、その開始をしようとするごとに行うレスポンスRFCA処理との２つがある。初期RFCA処理であっても、レスポンスRFCA処理であっても、電磁波の出力を開始する前に、他の装置による電磁波が存在するかどうかを検出し、存在しない場合にのみ、電磁波の出力を開始するという点は同一である。但し、初期RFCA処理とレスポンスRFCA処理とでは、他の装置による電磁波の存在が検出されなくなってから、電磁波の出力を開始しなければならないタイミングまでの時間等が異なる。
【００５６】
そこで、まず図５を参照して、初期RFCA処理について説明する。
【００５７】
図５は、初期RFCA処理によって出力が開始される電磁波を示している。なお、図５において（後述する図６も同様）、横軸は時間を表し、縦軸は、NFC通信装置が出力する電磁波のレベルを表す。
【００５８】
イニシエータとなろうとするNFC通信装置は、常時、他の装置による電磁波の検出を行っており、他の装置による電磁波が、時間ＴIDT＋ｎ×ＴRFWだけ連続して検出されなかった場合、電磁波の出力を開始し、その出力から時間ＴIRFGだけ経過した後に、データ（コマンドを含む）の送信(Send Request)を開始する。
【００５９】
ここで、時間ＴIDT＋ｎ×ＴRFWにおけるＴIDTは、初期遅延時間と呼ばれ、搬送波の周波数をｆcで表すこととすると、例えば、４０９６／ｆcより大の値が採用される。ｎは、例えば、０以上３以下の整数で、乱数を用いて生成される。ＴRFWは、RF待ち時間と呼ばれ、例えば、５１２／ｆcが採用される。時間ＴIRFGは、初期ガードタイムと呼ばれ、例えば、５msより大の値が採用される。
【００６０】
なお、電磁波が検出されてはならない時間ＴIDT＋ｎ×ＴRFWに、乱数であるｎを採用することにより、複数のNFC通信装置が同一のタイミングで、電磁波の出力を開始してしまう可能性の低減が図られている。
【００６１】
NFC通信装置が、初期RFCA処理によって、電磁波の出力を開始した場合、そのNFC通信装置は、イニシエータとなるが、その際、通信モードとして、アクティブモードが設定されたときには、イニシエータとなったNFC通信装置は、自身のデータの送信を終了した後、電磁波の出力を停止する。一方、通信モードとして、パッシブモードが設定されたときには、イニシエータとなったNFC通信装置は、ターゲットとの通信が完全に完了するまで、初期RFCA処理によって開始した電磁波の出力を、そのまま続行する。
【００６２】
次に、図６は、レスポンスRFCA処理によって出力が開始される電磁波を示している。
【００６３】
アクティブモードにおいて電磁波を出力しようとするNFC通信装置は、他の装置による電磁波の検出を行い、他の装置による電磁波が、時間ＴADT＋ｎ×ＴRFWだけ連続して検出されなかった場合、電磁波の出力を開始し、その出力から時間ＴARFGだけ経過した後に、データの送信(Send Responsese)を開始する。
【００６４】
ここで、時間ＴADT＋ｎ×ＴRFWにおけるｎとＴRFWは、図５の初期RFCA処理における場合と同一のものである。また、時間ＴADT＋ｎ×ＴRFWにおけるＴADTは、アクティブディレイタイムと呼ばれ、例えば、７６８／ｆc以上２５５９／ｆc以下の値が採用される。時間ＴARFGは、アクティブガードタイムと呼ばれ、例えば、１０２４／ｆcより大の値が採用される。
【００６５】
図５と図６から明らかなように、初期RFCA処理によって電磁波の出力を開始するには、少なくとも初期遅延時間ＴIDTの間、電磁波が存在してはならず、レスポンスRFCA処理によって電磁波の出力を開始するには、少なくともアクティブディレイタイムＴADTの間、電磁波が存在してはならない。
【００６６】
そして、初期遅延時間ＴIDTは、４０９６／ｆcより大の値であるのに対して、アクティブディレイタイムＴADTは、７６８／ｆc以上２５５９／ｆc以下の値であることから、NFC通信装置がイニシエータになろうとする場合には、アクティブモードでの通信中において電磁波を出力しようとする場合よりも、電磁波が存在しない状態が長時間必要である。逆に言えば、NFC通信装置がアクティブモードでの通信中において電磁波を出力しようとする場合には、イニシエータになろうとする場合よりも、電磁波が存在しない状態になってから、それほど間をおかずに、電磁波を出力しなければならない。これは、次のような理由による。
【００６７】
即ち、NFC通信装置がアクティブモードで通信を行う場合、一方のNFC通信装置は、自身で電磁波を出力してデータを送信し、その後、電磁波の出力を停止する。そして、他方のNFC通信装置が電磁波の出力を開始し、データを送信する。従って、アクティブモードの通信では、いずれのNFC通信装置も、電磁波の出力を停止していることがある。このため、NFC通信装置がイニシエータになろうとする場合には、そのNFC通信装置の周囲でアクティブモードの通信が行われていないことを確認するために、イニシエータになろうとしているNFC通信装置の周囲で、他の装置が電磁波を出力していないことを、十分な時間確認する必要がある。
【００６８】
これに対して、アクティブモードでは、上述したように、イニシエータが電磁波を出力することにより、ターゲットにデータを送信する。そして、ターゲットは、イニシエータが電磁波の出力を停止してから、電磁波の出力を開始することにより、イニシエータにデータを送信する。その後、イニシエータは、ターゲットが電磁波の出力を停止してから、電磁波の出力を開始することにより、イニシエータにデータを送信し、以下、同様にして、イニシエータとターゲットの間でデータがやりとりされる。
【００６９】
従って、アクティブモードの通信を行っているイニシエータとターゲットの周囲に、イニシエータとなろうとするNFC通信装置が存在する場合に、アクティブモードの通信を行っているイニシエータとターゲットのうちの一方が電磁波の出力を停止してから、他方が電磁波の出力を開始するまでの時間が長いと、その間は電磁波が存在しないため、イニシエータとなろうとするNFC通信装置が、初期RFCA処理によって電磁波の出力を開始する。この場合、先に行われていたアクティブモードの通信が妨げられることになる。
【００７０】
このため、アクティブモードの通信中に行われるレスポンスRFCA処理では、電磁波が存在しない状態になってから、それほど間をおかずに、電磁波を出力しなければならないようにしている。
【００７１】
次に、イニシエータになろうとするNFC通信装置は、図５で説明したように、初期RFCA処理によって電磁波の出力を開始し、その後、データの送信を行う。イニシエータになろうとするNFC通信装置は、電磁波の出力を開始することで、イニシエータとなり、そのイニシエータに近接する位置に存在するNFC通信装置はターゲットとなるが、イニシエータが、ターゲットとデータのやりとりをするには、そのデータをやりとりするターゲットを特定しなければならない。このため、イニシエータは、初期RFCA処理によって電磁波の出力を開始した後に、そのイニシエータに近接する位置に存在する１以上のターゲットに対して、各ターゲットを特定する情報としての、例えば、乱数などによって決定されるNFCID(NFC Identification)を要求する。そして、イニシエータに近接する位置に存在するターゲットは、イニシエータからの要求に応じて、自身を特定するNFCIDを、イニシエータに送信する。
【００７２】
イニシエータは、以上のようにしてターゲットから送信されてくるNFCIDによってターゲットを特定し、その特定したターゲットとの間で、データのやりとりを行う。
【００７３】
アクティブモードでは、イニシエータが、後述するコマンド（リクエスト）ATR_REQを、そこに自身を特定するNFCIDを含めて送信し、そのATR_REQに対して、１のターゲットが、コマンドATR_REQに対する後述するレスポンスATR_RESを、そこに自身を特定するNFCIDを含めて返す（送信する）ことにより、イニシエータとターゲットとが、互いのNFCIDを認識し、互いを特定する。
【００７４】
一方、パッシブモードでは、イニシエータは、SDD(Single Device Detection)処理と呼ばれる処理を行うことによって、その周囲（近接する位置）に存在するターゲットを、そのNFCIDによって特定する。
【００７５】
ここで、SDD処理において、イニシエータは、ターゲットのNFCIDを要求するが、この要求は、イニシエータが、ポーリングリクエストフレームと呼ばれるフレームを送信することによって行われる。ターゲットは、ポーリングリクエストフレームを受信すると、例えば、自身のNFCIDを乱数によって決定し、そのNFCIDを配置したポーリングレスポンスフレームと呼ばれるフレームを送信する。イニシエータは、ターゲットから送信されてくるポーリングレスポンスフレームを受信することで、ターゲットのNFCIDを認識する。
【００７６】
ところで、パッシブモードのターゲットは、負荷変調によりデータを送信するから、RFCA処理を行わない。従って、SDD処理において、イニシエータが、その周囲のターゲットに対して、そのNFCIDを要求した場合、イニシエータの周囲に、複数のターゲットが存在するときには、その複数のターゲットの２以上から、同時に、NFCIDが送信されてくることがあり得る。この場合、その２以上のターゲットから送信されてくるNFCIDがコリジョンし、イニシエータは、そのコリジョンしたNFCIDを認識することができない。
【００７７】
そこで、SDD処理は、NFCIDのコリジョンをなるべく避けるために、例えば、タイムスロットを用いた方法で行われる。
【００７８】
即ち、図７は、タイムスロットを用いた方法により行われるSDD処理のシーケンスを示している。なお、図７では、イニシエータの周囲に、５つのターゲット＃１，＃２，＃３，＃４，＃５が存在するものとしてある。
【００７９】
SDD処理では、イニシエータがポーリングリクエストフレームを送信するが、その送信の完了後、所定の時間Ｔdだけおいて、所定の時間Ｔsの幅のタイムスロットが設けられる。なお、時間Ｔdは、例えば、５１２×６４／ｆcとされ、タイムスロットの幅としての時間Ｔsは、例えば、２５６×６４／ｆcとされる。また、タイムスロットは、例えば、時間的に最も先行するものから、０からのシーケンシャルな番号（整数）が付されることによって特定される。
【００８０】
ここで、図７では、タイムスロット＃０，＃１，＃２，＃３の４つを示してあるが、タイムスロットは、例えば、１６まで設けることが可能である。あるポーリングリクエストフレームに対して設けられるタイムスロットの数TSNは、イニシエータが指定し、ポーリングリクエストフレームに含められて、ターゲットに送信される。
【００８１】
ターゲットは、イニシエータから送信されてくるポーリングリクエストフレームを受信し、そのポーリングリクエストフレームに配置されているタイムスロットの数TSNを認識する。さらに、ターゲットは、０以上TSN−１の範囲の整数Ｒを、乱数により生成し、その整数Ｒによって特定されるタイムスロット＃Ｒのタイミングで、自身のNFCIDを配置したポーリングレスポンスフレームを送信する。
【００８２】
以上のように、ターゲットは、ポーリングレスポンスフレームを送信するタイミングとしてのタイムスロットを、乱数により決定するので、複数のターゲットがポーリングレスポンスフレームを送信するタイミングがばらつくこととなり、これにより、複数のターゲットが送信するポーリングレスポンスフレームどうしのコリジョンをなるべく避けることができる。
【００８３】
なお、ターゲットにおいて、ポーリングレスポンスフレームを送信するタイミングとしてのタイムスロットを、乱数により決定しても、複数のターゲットがポーリングレスポンスフレームを送信するタイムスロットが一致し、これにより、ポーリングレスポンスフレームのコリジョンが生じる場合がある。図７の実施の形態では、タイムスロット＃０において、ターゲット＃４のポーリングレスポンスフレームが、タイムスロット＃１において、ターゲット＃１と＃３のポーリングレスポンスフレームが、タイムスロット＃２において、ターゲット＃５のポーリングレスポンスフレームが、タイムスロット＃３において、ターゲット＃２のポーリングレスポンスフレームが、それぞれ送信されており、ターゲット＃１と＃３のポーリングレスポンスフレームがコリジョンを生じている。
【００８４】
この場合、イニシエータは、コリジョンを生じているターゲット＃１と＃３のポーリングレスポンスフレームを正常に受信することができない。そのため、イニシエータは、再度、ポーリングリクエストフレームを送信し、これにより、ターゲット＃１と＃３に対して、それぞれのNFCIDが配置されたポーリングレスポンスフレームの送信を要求する。以下、イニシエータにおいて、その周囲にあるターゲット＃１乃至＃５すべてのNFCIDを認識することができるまで、イニシエータによるポーリングリクエストフレームの送信と、ターゲットによるポーリングレスポンスフレームの送信とが繰り返し行われる。
【００８５】
なお、イニシエータが、ポーリングリクエストフレームを再度送信した場合に、すべてのターゲット＃１乃至＃５が、ポーリングレスポンスフレームを返すこととすると、再び、ポーリングレスポンスフレームどうしがコリジョンを起こす可能性がある。そこで、ターゲットにおいては、イニシエータからポーリングリクエストフレームを受信した後、それほど時間をおかずに、ポーリングリクエストフレームを再度受信した場合には、例えば、そのポーリングリクエストを無視するようにすることができる。但し、この場合、図７の実施の形態では、最初に送信されたポーリングリクエストフレームに対して、ポーリングレスポンスのコリジョンを生じているターゲット＃１と＃３については、イニシエータは、そのターゲット＃１と＃３のNFCIDを認識することができないので、ターゲット＃１または＃３との間でのデータのやりとりは、できないことになる。
【００８６】
そこで、イニシエータが、ポーリングレスポンスフレームを正常に受信し、そのNFCIDを認識することができたターゲット＃２，＃４，＃５については、通信対象から一時的にはずし（ディセレクト状態にし）、これにより、ポーリングリクエストフレームに対する応答としてのポーリングレスポンスフレームを返さないようにすることができる。この場合、イニシエータが送信する再度のポーリングリクエストフレームに対して、ポーリングレスポンスフレームを返してくるのは、最初のポーリングリクエストフレームの送信によってNFCIDを認識することができなかったターゲット＃１と＃３だけとなる。従って、この場合、ポーリングレスポンスフレームどうしがコリジョンを起こす可能性を小さくしながら、ターゲット＃１乃至＃５すべてのNFCIDを認識することが可能となる。
【００８７】
また、ここでは、ターゲットは、上述したように、ポーリングリクエストフレームを受信すると、自身のNFCIDを、乱数によって決定（生成）する。このため、異なるターゲットから、同一のNFCIDがポーリングレスポンスフレームに配置されて、イニシエータに送信されてくる場合があり得る。イニシエータにおいて、異なるタイムスロットにおいて、同一のNFCIDが配置されたポーリングレスポンスフレームが受信された場合、イニシエータには、例えば、ポーリングレスポンスフレームどうしがコリジョンを起こした場合と同様に、ポーリングリクエストフレームを再度送信させることができる。
【００８８】
ここで、上述したように、NFC通信装置は、既存のICカードシステムを構成するICカードやリーダ／ライタとの間でも、そのICカードやリーダ／ライタが採用している伝送レートで、データのやりとりを行うことができる。いま、ターゲットが、例えば、既存のICカードシステムのICカードである場合、SDD処理は、例えば、次のようにして行われる。
【００８９】
即ち、イニシエータは、初期RFCA処理により、電磁波の出力を開始し、ターゲットであるICカードは、その電磁波から電源を得て、処理を開始する。つまり、いまの場合、ターゲットは、既存のICカードシステムのICカードであるから、動作するための電源を、イニシエータが出力する電磁波から生成する。
【００９０】
ターゲットは、電源を得て、動作可能な状態になってから、例えば、最長でも２秒以内に、ポーリングリクエストフレームを受信する準備を行い、イニシエータからポーリングリクエストフレームが送信されてくるのを待つ。
【００９１】
一方、イニシエータは、ターゲットにおいてポーリングリクエストフレームを受信する準備が整ったかどうかに関係なく、ポーリングリクエストフレームを送信することができる。
【００９２】
ターゲットは、イニシエータからのポーリングリクエストフレームを受信した場合、上述したように、所定のタイムスロットのタイミングで、ポーリングレスポンスフレームを、イニシエータに送信する。イニシエータは、ターゲットからのポーリングレスポンスフレームを正常受信することができた場合、上述したように、そのターゲットのNFCIDを認識する。一方、イニシエータは、ターゲットからのポーリングレスポンスフレームを正常受信することができなかった場合、ポーリングリクエストフレームを、再度送信することができる。
【００９３】
なお、いまの場合、ターゲットは、既存のICカードシステムのICカードであるから、動作するための電源を、イニシエータが出力する電磁波から生成する。このため、イニシエータは、初期RFCA処理によって開始した電磁波の出力を、ターゲットとの通信が完全に終了するまで続行する。
【００９４】
次に、NFC通信装置では、イニシエータがターゲットにコマンドを送信し、ターゲットが、イニシエータからのコマンドに対するレスポンスを送信する（返す）ことで、通信が行われる。
【００９５】
そこで、図８は、イニシエータがターゲットに送信するコマンドと、ターゲットがイニシエータに送信するレスポンスとを示している。
【００９６】
図８において、アンダーバー(_)の後にREQの文字が記述されているものは、コマンドを表し、アンダーバー(_)の後にRESの文字が記述されているものは、レスポンスを表す。図８の実施の形態では、コマンドとして、ATR_REQ，WUP_REQ，PSL_REQ，DEP_REQ，DSL_REQ，RLS_REQの６種類が用意されており、コマンドに対するレスポンスとしても、コマンドと同様に、ATR_RES，WUP_RES，PSL_RES，DEP_RES，DSL_RES，RLS_RESの６種類が用意されている。上述したように、イニシエータは、コマンド（リクエスト）をターゲットに送信し、ターゲットは、そのコマンドに対応するレスポンスをイニシエータに送信するので、コマンドは、イニシエータによって送信され、レスポンスは、ターゲットによって送信される。
【００９７】
コマンドATR_REQは、イニシエータが、ターゲットに対して、自身の属性（仕様）を知らせるとともに、ターゲットの属性を要求するときに、ターゲットに送信される。ここで、イニシエータまたはターゲットの属性としては、そのイニシエータまたはターゲットが送受信することのできるデータの伝送レートなどがある。なお、コマンドATR_REQには、イニシエータの属性の他、そのイニシエータを特定するNFCIDなどが配置され、ターゲットは、コマンドATR_REQを受信することにより、イニシエータの属性とNFCIDを認識する。
【００９８】
レスポンスATR_RESは、ターゲットが、コマンドATR_REQを受信した場合に、そのコマンドATR_REQに対する応答として、イニシエータに送信される。レスポンスATR_RESには、ターゲットの属性やNFCIDなどが配置される。
【００９９】
なお、コマンドATR_REQやレスポンスATR_RESに配置される属性としての伝送レートの情報には、イニシエータやターゲットが送受信することのできるデータの伝送レートすべてを含めることができる。この場合、イニシエータとターゲットとの間で、コマンドATR_REQとレスポンスATR_RESのやりとりが１度行われるだけで、イニシエータは、ターゲットが送受信可能な伝送レートを認識することができ、ターゲットも、イニシエータが送受信可能な伝送レートを認識することができる。
【０１００】
コマンドWUP_REQは、イニシエータが、通信するターゲットを選択するときに送信される。即ち、後述するコマンドDSL_REQを、イニシエータからターゲットに送信することにより、ターゲットを、ディセレクト(deselect)状態（イニシエータへのデータの送信（レスポンス）を禁止した状態）とすることができるが、コマンドWUP_REQは、そのディセレクト状態を解いて、ターゲットを、イニシエータへのデータの送信を可能にする状態とする場合に送信される。なお、コマンドWUP_REQには、ディセレクト状態を解くターゲットのNFCIDが配置され、コマンドWUP_REQを受信したターゲットのうち、そのコマンドWUP_REQに配置されているNFCIDによって特定されるターゲットが、ディセレクト状態を解く。
【０１０１】
レスポンスWUP_RESは、コマンドWUP_REQを受信したターゲットのうち、そのコマンドWUP_REQに配置されているNFCIDによって特定されるターゲットが、ディセレクト状態を解いた場合にコマンドWUP_REQに対する応答として送信される。
【０１０２】
なお、コマンドWUP_REQは、イニシエータがアクティブモード時にのみ送信し、レスポンスWUP_RESは、ターゲットがアクティブモード時にのみ送信する。
【０１０３】
コマンドPSL_REQは、イニシエータが、ターゲットとの通信に関する通信パラメータを変更するときに送信される。ここで、通信パラメータとしては、例えば、イニシエータとターゲットとの間でやりとりするデータの伝送レートなどがある。
【０１０４】
コマンドPSL_REQには、変更後の通信パラメータの値が配置され、イニシエータからターゲットに送信される。ターゲットは、コマンドPSL_REQを受信し、そこに配置されている通信パラメータの値にしたがって、通信パラメータを変更する。さらに、ターゲットは、コマンドPSL_REQに対するレスポンスPSL_RESを送信する。
【０１０５】
コマンドDEP_REQは、イニシエータが、データ（いわゆる実データ）の送受信（ターゲットとの間のデータ交換）を行うときに送信され、そこには、ターゲットに送信すべきデータが配置される。レスポンスDEP_RESは、ターゲットが、コマンドDEP_REQに対する応答として送信し、そこには、イニシエータに送信すべきデータが配置される。従って、コマンドDEP_REQによって、イニシエータからターゲットにデータが送信され、そのコマンドDEP_REQに対するレスポンスDEP_RESによって、ターゲットからイニシエータにデータが送信される。
【０１０６】
コマンドDSL_REQは、イニシエータが、ターゲットをディセレクト状態とするときに送信される。コマンドDSL_REQを受信したターゲットは、そのコマンドDSL_REQに対するレスポンスDSL_RESを送信してディセレクト状態となり、以後、コマンドWUP_REQ以外のコマンドには反応しなくなる（レスポンスを返さなくなる）。
【０１０７】
コマンドRLS_REQは、イニシエータが、ターゲットとの通信を完全に終了するときに送信される。コマンドRLS_REQを受信したターゲットは、そのコマンドRLS_REQに対するレスポンスRLS_RESを送信し、イニシエータとの通信を完全に終了する。
【０１０８】
ここで、コマンドDSL_REQとRLS_REQは、いずれも、ターゲットを、イニシエータとの通信の対象から解放する点で共通する。しかしながら、コマンドDSL_REQによって解放されたターゲットは、コマンドWUP_REQによって、再び、イニシエータと通信可能な状態となるが、コマンドRLS_REQによって解放されたターゲットは、イニシエータが初期RFCA処理から処理をやり直さないと、イニシエータと通信可能な状態とならない。かかる点で、コマンドDSL_REQとRLS_REQは、異なる。
【０１０９】
次に、NFC通信装置の通信は、ISO/IEC 18092として規定されているNFCIP-1にしたがって行われる。
【０１１０】
そこで、図９乃至図１１を参照して、NFCIP-1にしたがった通信処理について説明する。
【０１１１】
まず、図９は、NFCIP-1にしたがった通信処理の概要を説明するフローチャートである。
【０１１２】
まず最初に、ステップＳ１において、イニシエータとなるNFC通信装置は、初期RFCA処理を行い、ステップＳ２に進む。ステップＳ２では、イニシエータとなるNFC通信装置は、ステップＳ１の初期RFCA処理により、RFフィールドを検出したかどうかを判定する。ステップＳ２において、RFフィールドを検出したと判定された場合、ステップＳ１に戻り、以下、同様の処理が繰り返される。即ち、イニシエータとなるNFC通信装置は、RFフィールドを検出している間は、そのRFフィールドを形成している他のNFC通信装置による通信の妨げとならないように、RFフィールドを形成しない。
【０１１３】
一方、ステップＳ２において、RFフィールドを検出していないと判定された場合、NFC通信装置は、アクティブモードとパッシブモードのうちのいずれかの通信モードを選択して、ステップＳ３に進み、NFC通信装置は、イニシエータとなって、伝送レートの選択等を行う。
【０１１４】
即ち、NFCIP-1では、例えば、106kbpsや、212kbps，424kbps等の複数の伝送レートの中から、実際の通信に使用する伝送レートを選択することが可能である。そこで、ステップＳ３では、イニシエータとなったNFC通信装置は、伝送レートの選択を行う。
【０１１５】
具体的には、パッシブモードの通信を行う場合、ステップＳ２から、ステップＳ３を構成するステップＳ３−１とＳ３−２のうちのステップＳ３−１に進み、NFC通信装置は、イニシエータとなって、通信モードをパッシブモードに移行させ、伝送レートを選択する。さらに、ステップＳ３−１では、イニシエータとなったNFC通信装置は、所定の初期化処理とSDD処理を行い、ステップＳ４を構成するステップＳ４−１とＳ４−２のうちのステップＳ４−１に進む。
【０１１６】
ステップＳ４−１では、NFC通信装置は、パッシブモードでアクティベーション（活性化）（起動）し、パッシブモードのターゲットとの間で、コマンドATR_REQとレスポンスATR_RESをやりとりして、ステップＳ５に進む。
【０１１７】
一方、アクティブモードの通信を行う場合、ステップＳ２から、ステップＳ３を構成するステップＳ３−１とＳ３−２のうちのステップＳ３−２に進み、NFC通信装置は、イニシエータとなって、通信モードをアクティブモードに移行させ、伝送レートを選択し、ステップＳ４を構成するステップＳ４−１とＳ４−２のうちのステップＳ４−２に進む。
【０１１８】
ステップＳ４−２では、NFC通信装置は、アクティブモードでアクティベーションし、ターゲットとの間で、コマンドATR_REQとレスポンスATR_RESをやりとりして、ステップＳ５に進む。
【０１１９】
ステップＳ５では、NFC通信装置は、通信に必要な通信パラメータ（例えば、伝送レートなど）を、現在の通信パラメータから変更する必要がある場合には、その通信パラメータを選択し、その通信パラメータ等を配置したコマンドPSL_REQとレスポンスPSL_RESを、ターゲットとの間でやりとりして、通信パラメータを変更し、ステップＳ６に進む。
【０１２０】
ステップＳ６では、NFC通信装置は、ステップＳ５で選択した通信パラメータにしたがって、コマンドDEP_REQとレスポンスDEP_RESを、ターゲットとの間でやりとりして、データ交換プロトコルによるデータ交換（通信）を行い、そのデータ交換の終了後、ステップＳ７に進む。ステップＳ７では、NFC通信装置は、コマンドDSL_REQとレスポンスDSL_RES、またはコマンドRSL_REQとレスポンスRSL_RESを、ターゲットとの間でやりとりして、ディアクティベーション（非活性化）し、トランザクションを終了する。
【０１２１】
なお、NFC通信装置は、例えば、デフォルトで、ターゲットとなるように設定することができ、ターゲットに設定されているNFC通信装置は、RFフィールドを形成することはせず、イニシエータからコマンドが送信されてくるまで（イニシエータがRFフィールドを形成するまで）、待ち状態となる。
【０１２２】
また、NFC通信装置は、例えば、アプリケーションからの要求に応じて、イニシエータとなることができる。さらに、例えば、アプリケーションでは、通信モードをアクティブモードまたはパッシブモードのうちのいずれにするか、伝送レートを選択（決定）することができる。
【０１２３】
また、イニシエータとなったNFC通信装置は、外部にRFフィールドが形成されていなければ、RFフィールドを形成し、ターゲットは、イニシエータによって形成されたRFフィールドによって活性化する。
【０１２４】
その後、イニシエータは、選択された通信モードと伝送レートで、コマンドを送信し、ターゲットは、イニシエータと同一の通信モードと伝送レートで、レスポンスを返す（送信する）。
【０１２５】
次に、図１０のフローチャートを参照して、パッシブモードにおけるアクティベーションプロトコルの処理（パッシブモードでのデータ交換を行うのに、NFC通信装置で行われる処理）を説明する。
【０１２６】
まず最初に、ステップＳ１１において、イニシエータは、初期RFCA処理を行い、ステップＳ１２に進み、通信モードをパッシブモードとする。そして、ステップＳ１３に進み、イニシエータは、初期化処理とSDD処理を行って、伝送レートを選択する。
【０１２７】
ここで、ステップＳ１１の処理が、図９のステップＳ１およびＳ２の処理に対応し、ステップＳ１２およびＳ１３の処理が、図９のステップＳ３（Ｓ３−１）の処理に対応する。
【０１２８】
その後、ステップＳ１４に進み、イニシエータは、ターゲットに属性を要求するかどうかを判定する。ここで、属性とは、NFC通信装置の仕様の情報で、例えば、NFC通信装置が対応することができる伝送レートの情報などがある。
【０１２９】
ステップＳ１４において、ターゲットに属性を要求しないと判定された場合、ステップＳ３３５に進み、イニシエータは、ターゲットとの通信を、独自プロトコルにしたがって行い、ステップＳ１４に戻り、以下、同様の処理を繰り返す。
【０１３０】
また、ステップＳ１４において、ターゲットに属性を要求すると判定された場合、ステップＳ１６に進み、イニシエータは、コマンドATR_REQを送信し、これにより、ターゲットに属性を要求する。そして、イニシエータは、ターゲットからコマンドATR_REQに対するレスポンスATR_RESが送信されてくるのを待って、ステップＳ１７に進み、そのレスポンスATR_RESを受信して、ステップＳ１８に進む。
【０１３１】
ここで、ステップＳ１６およびＳ１７の処理は、図９のステップＳ４（Ｓ４−１）の処理に対応する。
【０１３２】
ステップＳ１８では、イニシエータは、ステップＳ１７でターゲットから受信したレスポンスATR_RESに基づき、通信パラメータ、即ち、例えば、伝送レートを変更することができるかどうかを判定する。ステップＳ１８において、伝送レートを変更することができないと判定された場合、ステップＳ１９乃至Ｓ２１をスキップして、ステップＳ２２に進む。
【０１３３】
また、ステップＳ１８において、伝送レートを変更することができると判定された場合、ステップＳ１９に進み、イニシエータは、コマンドPSL_REQを送信し、これにより、ターゲットに伝送レートの変更を要求する。そして、イニシエータは、コマンドPSL_REQに対するレスポンスPSL_RESがターゲットから送信されてくるのを待って、ステップＳ１９からＳ２０に進み、そのレスポンスPSL_RESを受信して、ステップＳ２１に進む。ステップＳ２１では、イニシエータは、ステップＳ２０で受信したレスポンスPSL_RESにしたがい、通信パラメータ、即ち、例えば、伝送レートを変更し、ステップＳ２２に進む。
【０１３４】
ここで、ステップＳ１８乃至Ｓ２１の処理は、図９のステップＳ５の処理に対応する。
【０１３５】
ステップＳ２２では、イニシエータは、データ交換プロトコルにしたがい、ターゲットとの間でデータ交換、即ち、コマンドDEP_REQとレスポンスDEP_RESのやりとりを行う。
【０１３６】
ここで、ステップＳ２２の処理は、図９のステップＳ６の処理に対応する。
【０１３７】
ステップＳ２２においてデータ変換が行われた後は、イニシエータは、必要に応じて、ステップＳ２３またはＳ２５に進む。
【０１３８】
即ち、イニシエータは、ターゲットをディセレクト状態にする場合、ステップＳ２２からＳ２３に進み、コマンドDSL_REQを送信する。そして、イニシエータは、コマンドDSL_REQに対するレスポンスDSL_RESがターゲットから送信されてくるのを待って、ステップＳ２３からＳ２４に進み、そのレスポンスDSL_RESを受信して、ステップＳ１４に戻り、以下、同様の処理を繰り返す。
【０１３９】
一方、イニシエータは、ターゲットとの通信を完全に終了する場合、ステップＳ２２からＳ２５に進み、コマンドRLS_REQを送信する。そして、イニシエータは、コマンドRLS_REQに対するレスポンスRLS_RESがターゲットから送信されてくるのを待って、ステップＳ２５からＳ２６に進み、そのレスポンスRLS_RESを受信して、ステップＳ１１に戻り、以下、同様の処理を繰り返す。
【０１４０】
ここで、ステップＳ２３とＳ２４の処理や、ステップＳ２５とＳ２６の処理は、図９のステップＳ７の処理に対応する。
【０１４１】
次に、図１１のフローチャートを参照して、アクティブモードにおけるアクティベーションプロトコルを説明する。
【０１４２】
まず最初に、ステップＳ３１において、イニシエータは、初期RFCA処理を行い、ステップＳ３２に進み、通信モードをアクティブモードとして、伝送レートを選択する。
【０１４３】
ここで、ステップＳ３１の処理は、図９のステップＳ１およびＳ２の処理に対応し、ステップＳ３２の処理は、ステップＳ３（Ｓ３−２）の処理に対応する。
【０１４４】
その後、ステップＳ３３乃至Ｓ３９において、図１０のステップＳ１６乃至Ｓ２２における場合とそれぞれ同様の処理が行われる。
【０１４５】
即ち、ステップＳ３３では、イニシエータは、コマンドATR_REQを送信し、これにより、ターゲットに属性を要求する。そして、イニシエータは、ターゲットからコマンドATR_REQに対するレスポンスATR_RESが送信されてくるのを待って、ステップＳ３４に進み、そのレスポンスATR_RESを受信して、ステップＳ３５に進む。
【０１４６】
ステップＳ３５では、イニシエータは、ステップＳ３４でターゲットから受信したレスポンスATR_RESに基づき、通信パラメータ、即ち、例えば、伝送レートを変更することができるかどうかを判定する。ステップＳ３５において、伝送レートを変更することができないと判定された場合、ステップＳ３６乃至Ｓ３８をスキップして、ステップＳ３９に進む。
【０１４７】
また、ステップＳ３５において、伝送レートを変更することができると判定された場合、ステップＳ３６に進み、イニシエータは、コマンドPSL_REQを送信し、これにより、ターゲットに伝送レートの変更を要求する。そして、イニシエータは、コマンドPSL_REQに対するレスポンスPSL_RESがターゲットから送信されてくるのを待って、ステップＳ３６からＳ３７に進み、そのレスポンスPSL_RESを受信して、ステップＳ３８に進む。ステップＳ３８では、イニシエータは、ステップＳ３７で受信したレスポンスPSL_RESにしたがい、通信パラメータ、即ち、例えば、伝送レートを変更し、ステップＳ３９に進む。
【０１４８】
ステップＳ３９では、イニシエータは、データ交換プロトコルにしたがい、ターゲットとの間でデータ交換、即ち、コマンドDEP_REQとレスポンスDEP_RESのやりとりを行う。
【０１４９】
ここで、ステップＳ３３およびＳ３４の処理は、図９のステップＳ４（Ｓ４−２）の処理に対応し、ステップＳ３５乃至Ｓ３８の処理は、図９のステップＳ５の処理に対応する。また、ステップＳ３９の処理は、図９のステップＳ６の処理に対応する。
【０１５０】
ステップＳ３９におけるデータ変換の後は、必要に応じて、ステップＳ４０またはＳ４４に進む。
【０１５１】
即ち、イニシエータは、いま通信を行っているターゲットをディセレクト状態にし、既にディセレクト状態になっているターゲットのうちのいずれかをウエイクアップさせる場合、ステップＳ３９からＳ４０に進み、ディセレクト状態にするターゲット宛に、コマンドDSL_REQを送信する。そして、イニシエータは、コマンドDSL_REQに対するレスポンスDSL_RESがターゲットから送信されてくるのを待って、ステップＳ４０からＳ４１に進み、そのレスポンスDSL_RESを受信する。ここで、レスポンスDSL_RESを送信してきたターゲットは、ディセレクト状態になる。
【０１５２】
その後、ステップＳ４１からＳ４２に進み、イニシエータは、ウエイクアップさせるターゲット宛に、コマンドWUP_REQを送信する。そして、イニシエータは、コマンドWUP_REQに対するレスポンスWUP_RESがターゲットから送信されてくるのを待って、ステップＳ４２からＳ４３に進み、そのレスポンスWUP_RESを受信して、ステップＳ３５に戻る。ここで、レスポンスWUP_RESを送信してきたターゲットはウエイクアップし、そのウエイクアップしたターゲットが、イニシエータがその後に行うステップＳ３５以降の処理の対象となる。
【０１５３】
一方、イニシエータは、ターゲットとの通信を完全に終了する場合、ステップＳ３９からＳ４４に進み、コマンドRLS_REQを送信する。そして、イニシエータは、コマンドRLS_REQに対するレスポンスRLS_RESがターゲットから送信されてくるのを待って、ステップＳ４４からＳ４５に進み、そのレスポンスRLS_RESを受信して、ステップＳ３１に戻り、以下、同様の処理を繰り返す。
【０１５４】
ここで、ステップＳ４０乃至４３の処理や、ステップＳ４４とＳ４５の処理は、図９のステップＳ７の処理に対応する。
【０１５５】
以上、図９乃至図１１を参照して、NFCIP-1に従った通信処理について説明した。
【０１５６】
ところで、NFC通信装置が、このようなNFCIP-1に従った通信処理を単に行っただけでは、本来有している能力を十分に発揮できない、という上述した従来の課題が生じてしまう。
【０１５７】
そこで、本発明人は、所定の１つのNFC通信装置が、自身または通信相手が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎に生成し、１以上のデータ群を所定のコマンドや所定のレスポンスに格納させて、通信相手のNFC通信装置に送信する、といった手法をさらに発明した。
【０１５８】
なお、以下、所定の種類の能力に関連する情報が記述されるフィールが１以上所定の順番に配置されることで構成される構造体（データ群）を、カプセルと呼ぶ。また、以下、カプセルも含めて所定の構造体を構成する１以上のフィールドのうちの、所定の１つのフィールドに対して、「所定の情報が記述されること」を、「所定の情報が設定される」と呼ぶ。即ち、本発明のこの手法では、送信側のNFC通信装置により、送信側と受信側（送信側から見て通信相手側）とのうちの少なくとも一方のNFC通信装置が有するn+1種類（nは０以上の整数値）の能力のそれぞれについて、対応する種類の能力に関連する各種情報が１以上のフィールドのうちの所定の１つに設定されることで、対応する種類の能力についてのカプセルがn+1種類毎にそれぞれ生成され、n+1個のカプセルが所定のコマンドや所定のレスポンスに格納されて、受信側のNFC通信装置に送信される。
【０１５９】
このカプセルは、例えば、所定の種類の能力を示す情報が設定されるフィールド、その所定の種類の能力についての「能力の活性化を通信相手側に指示するための情報」が設定されるフィールド、その所定の種類の能力についての「能力の活性化を自身が確認したことを通信相手側に通知するための情報」が設定されるフィールドを含むように構成することもできる。
【０１６０】
具体的には例えば、NFC通信装置は、図１２に示される構造のカプセル５１を利用することができる。即ち、図１２は、本発明が適用されるカプセルの構造の一例を示している。
【０１６１】
図１２のカプセル５１は、フィールド６１乃至６５から構成されている。
【０１６２】
フィールド６１には、図１２の記載の通り、いわゆるヘッダ情報が記述される。そこで、以下、フィールド６１を、単にヘッダ６１と呼ぶ。
【０１６３】
フィールド６２には、図１２の記載の通り、送信側のNFC通信装置が、受信側（送信側から見て通信相手側）のNFC通信装置に対して、所定の処理を指示するための情報が設定される。そこで、以下、フィールド６２を、「処理を指示する情報」フィールド６２と呼ぶ。即ち、後述するように、「処理を指示する情報」フィールド６２には、「能力の活性化を通信相手側に指示するための情報」のうちのひとつが設定される場合がある。ただし、「処理を指示する情報」フィールド６２に設定される情報の具体例については、後述する。
【０１６４】
フィールド６３には、図１２の記載の通り、送信側のNFC通信装置が有する能力のうちの、所定の種類の能力を示す情報が設定される。そこで、以下、フィールド６３を、「能力を示す情報」フィールド６３と呼ぶ。なお、「能力を示す情報」フィールド６３に設定される情報の具体例については、後述する。
【０１６５】
フィールド６４には、図１２の記載の通り、送信側のNFC通信装置が、受信側（送信側から見て通信相手側）のNFC通信装置に対して、その左方の「能力を示す情報」フィールド６３に設定された情報に対する指示、即ち、所定の種類の能力に対する所定の指示を行うための情報が設定される。そこで、以下、フィールド６４を、「能力を示す情報に対する指示」フィールド６４と呼ぶ。即ち、「能力を示す情報に対する指示」フィールド６４には、「能力の活性化を通信相手側に指示するための情報」のうちのひとつが設定される場合がある。ただし、「能力を示す情報に対する指示」フィールド６４に設定される情報の具体例については、後述する。
【０１６６】
フィールド６５には、図１２の記載の通り、その他の付随情報が設定される。そこで、以下、フィールド６５を、「付随情報」フィールド６５と呼ぶ。例えば、送信側のNFC通信装置は、「能力の活性化を自身が確認したことを通信相手側に通知するための情報」を付随情報として、「付随情報」フィールド６５に設定することもできる。ただし、「付随情報」フィールド６５に設定される情報の具体例については、後述する。
【０１６７】
このようなカプセル５１を採用することで、NFC通信装置と通信相手側のNFC通信装置との間で、NFCIP-1規格をそのまま忠実に利用しつつ（上述したNFCIP-1に従った通信処理を行いつつ）、NFCIP-1で規定している能力群以上の能力、即ち、NFCIP-1で規定している種類とは異なる種類の能力、或いは、NFCIP-1で規定している種類であっても、NFC通信装置または通信相手側のNFC通信装置が有する能力レベルが、NFCIP-1で規定しているレベル以上である種類の能力の存在を交換したり、その能力の活性化の指示や確認を実現することが可能になる。NFCIP-1で規定している能力群以上の能力、即ち、NFCIP-1で規定している種類とは異なる能力、或いは、NFCIP-1で規定している種類であっても、NFC装置が有している能力レベルが、NFCIP-1で規定しているレベル以上である種類の能力に関する情報を、カプセル５１に容易に含ませることができるからである。
【０１６８】
また、このようなカプセル５１を採用しない他のNFC通信装置がたとえ通信相手となったとしても、NFC通信装置は、その通信相手側のNFC通信装置との間で、上述したNFCIP-1に従った通信処理をそのまま実行することが可能になる。
【０１６９】
このようなカプセル５１の格納先は、上述したように、任意のコマンドまたは任意のレスポンスでよいが、本実施の形態では、コマンドATR_REQまたはレスポンスATR_RESとされている。コマンドATR_REQやレスポンスATR_RESは、上述したように、自身の属性（仕様）を知らせたり、通信相手の属性を要求するときに利用されるからである。即ち、自身の能力を知らせたり、通信相手の能力を要求するときに利用されるカプセル５１を、コマンドATR_REQやレスポンスATR_RESに格納することは理にかなっているからである。また、NFCIP-1では、コマンドATR_REQやレスポンスATR_RESには、General Byteと称されるフィールド（以下、フィールドGiと呼ぶ）が規定されており、このフィールドGiにカプセル５１を格納することが容易にできるからである。
【０１７０】
ここで、図１３乃至図１９を参照して、コマンドATR_REQとレスポンスATR_RESとについてさらに詳しく説明する。
【０１７１】
なお、以下、便宜上、イニシエータがコマンドATR_REQを送信し、ターゲットがレスポンスATR_RESを送信するとして、説明を行う。ただし、当然ながら、実際にはその逆、即ち、ターゲットがコマンドATR_REQを送信し、イニシエータがレスポンスATR_RESを送信する場合もあり得る。
【０１７２】
図１３は、NFCIP-1で規定されているコマンドATR_REQの構造を示している。
【０１７３】
図１３に示されるように、コマンドATR_REQには、先頭から（図中左から）、フィールドCMD0、フィールドCMD1、および、フィールドByte0乃至Byten+14（nは０以上の整数値）から構成されている。
【０１７４】
フィールドCMD0には、（Ｄ４）が設定される。フィールドCMD1には、このコマンドがコマンドATR_REQであることを示す値（００）が設定される。
【０１７５】
フィールドByte0乃至Byte9には、このコマンドATR_REQを送信するNFC通信装置、即ち、イニシエータを特定する上述したNFCIDが設定される。
【０１７６】
フィールドByte10には、このコマンドATR_REQを送信するイニシエータのデバイスIDであるDIDiが設定される。そこで、以下、フィールドByte10を、フィールドDIDiとも呼ぶ。
【０１７７】
フィールドByte11には、このコマンドATR_REQを送信するイニシエータがデータを送信する際のビットレート（伝送レート）が設定される。なお、以下、フィールドByte11を、フィールドBSiとも呼ぶ。フィールドBSiの詳細については、図１４と図１５とを参照して後述する。
【０１７８】
フィールドByte1２には、このコマンドATR_REQを送信するイニシエータがデータを受信する際のビットレート（伝送レート）が設定される。なお、以下、フィールドByte11を、フィールドBRiとも呼ぶ。フィールドBRiの詳細については、フィールドBSiの詳細とともに後述する。
【０１７９】
このように、フィールドBSiに設定される伝送レートと、フィールドBRiに設定される伝送レートとのそれぞれが、上述したように、このコマンドATR_REQを送信するイニシエータの属性（仕様）のひとつになる。
【０１８０】
フィールドByte13には、このコマンドATR_REQを送信するイニシエータについてのオプションパラメータが設定される。なお、以下、フィールドByte13を、フィールドPPiとも呼ぶ。フィールドPPiの詳細については、図１６乃至図１８を参照して後述する。
【０１８１】
フィールドByte14乃至Byte14+nのそれぞれが、上述したGeneral Byteと称されるフィールド、即ち、フィールドGiのそれぞれである。即ち、ｎ+1個のフィールドGiのそれぞれが、フィールドByte14乃至Byte14+nのそれぞれとして、このコマンドATR_REQに配置されることになる。以下、ｎ個のフィールドGiのそれぞれを、その配置順に（図１３中左から順に）、フィールドGi[0]乃至Gi[n]のそれぞれと呼ぶ。
【０１８２】
フィールドGi[0]乃至Gi[n]のそれぞれは、設計者等により指定される各種情報が設定されるフィールドであって、オプションとして用意されているフィールドである。即ち、値ｎは、設計者等により可変可能とされており、上述したように０以上の整数値となる。この値ｎは、後述するように、フィールドPPiに設定される。
【０１８３】
本実施の形態では、上述したように、フィールドGi[0]乃至Gi[n]のそれぞれに対して、図１２のカプセル５１が１つずつ格納される。
【０１８４】
以下、コマンドATR_REQのうちの、フィールドBSiを図１４と図１５とを参照して説明し、引き続き、フィールドBRiを説明し、そして、フィールドPPiを図１６乃至図１８を参照して説明する。
【０１８５】
図１４は、NFCIP-1で規定されているフィールドBSiの構造を示している。
【０１８６】
図１４に示されるように、フィールドBSiは、１バイトの情報、即ち、８ビットの情報で構成される。
【０１８７】
なお、以下、最下位ビット（図１４中最右のビット）から上位ビットに向けて（図１４中左方向に）、各ビットの情報を、ビットbit0乃至bit7のそれぞれと呼ぶ。このことは、１バイトの情報で構成される他のフィールド、即ち、フィールドBRi，PPi，Gi等でも同様とされる。
【０１８８】
フィールドBSiのうちの、ビットbit4乃至bit7には、０（ZERO）が設定され、ビットbit0乃至bit3のそれぞれには、このコマンドATR_REQを送信するイニシエータが847 kbps、1695 kbps、 3390 kbps、および 6780 kbps のそれぞれの伝送レートでの処理ができるか否かを示す情報（０または１）が設定される。即ち、例えば、０が処理できないことを示し、１が処理できることを示すとすると、ビットbit0に０が設定されていることは、このコマンドATR_REQを送信するイニシエータが847 kbpsの伝送レートでの処理ができないことを意味する。これに対して、ビットbit0に１が設定されていることは、このコマンドATR_REQを送信するイニシエータが847 kbpsの伝送レートでの処理ができることを意味する。
【０１８９】
なお、NFC通信装置は、106 kbps、 212 kbps、および 424 kbpsのそれぞれの伝送レートでの処理は必須で実行できなければならない、ということがNFCIP-1で規定されている。
【０１９０】
換言すると、NFCIP-1では、図１５に示されるように、データの送受信時の伝送レートとして取りうる値として、106 kbps、 212 kbps、 424 kbps、847 kbps、1695 kbps、 3390 kbps、および 6780 kbps が規定されている。即ち、図１５の表は、NFCIP-1で規定されている伝送レートを示している。
【０１９１】
図１５の表において、一番左の「Communication Mode」の項目には、その右方の「kbps」の項目に記述されている伝送レートで通信可能な通信モードが記述されている。即ち、106 kbps、 212 kbps、および 424 kbpsの伝送レートでは、アクティブモード（Active）とパッシブモード(Passive)との何れの通信モードでも通信可能であること（そのようにNFC通信装置を構成すればよいこと）が、NFCIP-1で規定されている。これに対して、847 kbps、1695 kbps、 3390 kbps、および 6780 kbpsでは、アクティブモード（Active）で通信可能であればよいこと（そのようにNFC通信装置を構成すればよいこと）が、NFCIP-1で規定されている。
【０１９２】
図１５の表において、真ん中の「kbps」の項目には、NFCIP-1で規定されている伝送レートが記述されている。
【０１９３】
図１５の表において、一番右の「Divisor D」の項目には、その左方の「kbps」の項目に記述されている伝送レートが使用されるときにおける、次の式（１）で使用されるパラメータＤの値が記述されている。
【０１９４】
1bd = 128 ／(D × fc)      ・・・（１）
式（１）において、bdはビットの継続時間を、fcは搬送波の周波数を、それぞれ示している。
【０１９５】
以上、図１３のコマンドATR_REQのうちの、フィールドBSiの構造について説明した。
【０１９６】
なお、フィールドBRiの構造は、上述したフィールドBSiの構造と基本的に同様であるので、その説明については省略する。
【０１９７】
換言すると、例えばこのコマンドATR_REQを送信するイニシエータ、または、このコマンドATR_REQを受信するターゲットが、6780kbpsよりも高い伝送レートでの処理が可能であったとしても、そのような高い伝送レートは、NFCIP-1では規定されておらず、フィールドBRiやフィールドBSiに設定することができない。そこで、このような場合、イニシエータは、そのような高い伝送レートに関する情報を図１２のカプセル５１に含め、さらに、そのカプセル５１を、このコマンドATR_REQのうちの図１３のフィールドGi[k]（kは、０乃至nのうちのいずれかの値）に格納させればよい。これにより、そのような高い伝送レートでの送受信の実現も可能になる。
【０１９８】
次に、図１６乃至図１８を参照して、コマンドATR_REQのうちのフィールドPPiを説明する。
【０１９９】
図１６は、NFCIP-1で規定されているフィールドPPiの構造を示している。
【０２００】
図１６に示されるように、フィールドPPiは、ビットbit0乃至bit7から構成される。
【０２０１】
ビットbit７，bit6，bit3，bit2には０（ZERO）が設定される。
【０２０２】
ビットbit4，bit5には、トランスポートデータの有効データ長を指定するための情報LRiが設定される。
【０２０３】
この情報LRiとして、図１７に示されるように、「００」、「０１」、「１０」、および「１１」のうちの何れかの値が採用される。即ち、図１７は、情報LRiが取り得る各値と、各値が示すトランスポートデータの有効データ長の範囲LENMAXとを示す表である。
【０２０４】
また、トランスポートデータとは、図１８に示されるTransport data field、即ち、フィールドCMD0乃至ByteＮ（Ｎは０以上の整数値であり、図１３や後述する図１９の例の場合にはn+14である）のことをいう。即ち、図１８は、トランスポートデータを含む１つのフレーム（例えば本実施の形態では、上述した図８に示されるコマンドやレスポンスのうちの所定の１つ）の構造を示している。詳細には、図１８のうちの、上側の図は、伝送レートが106kpsの場合の１つのフレームの構造を示しており、下側の図は、伝送レートが212kpsまたは424kbpsの場合の１つのフレームの構造を示している。
【０２０５】
なお、図１８において、SBと記述されたフィールドには、フレームの最初のフィールドであることを示す値が設定される。LENと記述されたフィールドには、それに続くトランスポートデータ（Transport data field）の有効データ長に対して１が加算された値が設定される。PAと記述されたフィールドには、前文(Premable)を示す情報が設定される。SYNCと記述されたフィールドには、同期パターンを示す情報（Synchronous pattern bit）が設定される。E1とE2と記述されたフィールドには、フレームの最後のフィールドであることを示す値が設定される。
【０２０６】
図１７と図１８に示されるように、フィールドByte63まである場合には、即ち、トランスポートデータの有効データ長が６６バイトまでの場合には、情報LRiは「００」となる。即ち、この場合、「００」が、図１６のフィールドPPiのビットbit4，bit５に設定される。
【０２０７】
フィールドByte127まである場合には、即ち、トランスポートデータの有効データ長が１３０バイトまでの場合には、情報LRiは「０１」となる。即ち、この場合、「０１」が、図１６のフィールドPPiのビットbit4，bit５に設定される。
【０２０８】
フィールドByte191まである場合には、即ち、トランスポートデータの有効データ長が１９４バイトまでの場合には、情報LRiは「１０」となる。即ち、この場合、「１０」が、図１６のフィールドPPiのビットbit4，bit５に設定される。
【０２０９】
フィールドByte２５５まである場合には、即ち、トランスポートデータの有効データ長が２５８バイトまでの場合には、情報LRiは「１１」となる。即ち、この場合、「１１」が、図１６のフィールドPPiのビットbit4，bit５に設定される。
【０２１０】
また、図１６のフィールドPPiのビットbit1には、このフィールドPPiに続いて、上述したフィールドGi[0]乃至Gi[n]が配置されているか否か（存在するか否か）を示す情報Giが設定される。即ち、情報Giは０または１となるので、例えば、０が配置されていない（存在しない）ことを示し、１が配置されている（存在する）ことを示すとする。この場合、ビットbit1に０が設定されていることは、このフィールドPPiに続いてフィールドGi[0]乃至Gi[ｎ]が配置されていないこと、即ち、本実施の形態では図１２のカプセル５１が１つも格納されていないことを意味する。これに対して、ビットbit1に1が設定されていることは、このフィールドPPiに続いてフィールドGi[0]乃至Gi[ｎ]が配置されていること、即ち、本実施の形態ではカプセル５１が少なくとも１つ格納されていることを意味する。
【０２１１】
また、このフィールドPPiのビットbit0には、NAD（Node Address）を使用するか否かを示す情報（０または１）が設定される。NADとは、上述した図１３のフィールドByte10、即ち、図１３のフィールドDIDiに設定される、このコマンドATR_REQを送信するイニシエータのデバイスIDのサブアドレスをいう。ひとつのデバイスIDに対して、１６個のサブアドレスを持つことが可能であることが、NFCIP-1で規定されている。
【０２１２】
このビットbit0において、例えば、０が使用しないことを示し、１が使用することを示すとすると、ビットbit0に０が設定されていることは、このコマンドATR_REQを送信するイニシエータがサブアドレスを使用しないことを意味する。これに対して、ビットbit0に1が設定されていることは、このコマンドATR_REQを送信するイニシエータがサブアドレスを使用することを意味する。
【０２１３】
以上、図１３乃至図１８を参照して、コマンドATR_REQの詳細な構造について説明した。
【０２１４】
このような構造を有するコマンドATR_REQのレスポンス、即ち、レスポンスATR_RESの構造が図１９に示されている。図１３と図１９とを比較するに、レスポンスATR_RESの構造は、コマンドATR_REQの構造と同様の構造を有していることがわかる。そこで、レスポンスATR_RESの構造の説明については省略する。
【０２１５】
以上説明したように、NFCIP-1では、コマンドATR_REQやレスポンスATR_RESには、フィールドGiが規定されているため、本実施の形態では、上述した図１２のカプセル５１は、コマンドATR_REQやレスポンスATR_RESのフィールドGiに格納されて、複数のNFC通信装置の間で送受信されることになる。
【０２１６】
具体的には例えば、本実施の形態では、イニシエータが、上述した図１０のステップＳ１６または図１１のステップＳ３３の処理で、コマンドATR_REQをターゲットに送信する。この場合、イニシエータが、少なくとも１つのカプセル５１をコマンドATR_REQに含めて、そのコマンドATR_REQをターゲットに送信するときには、上述した図１０のステップＳ１６または図１１のステップＳ３３の処理として、例えば図２０に示される「イニシエータ側のATR_REQ送信処理」を実行することができる。即ち、図２０は、少なくとも１つのカプセル５１を含むコマンドATR_REQをイニシエータが送信する場合の「イニシエータ側のATR_REQ送信処理」の一例を説明するフローチャートである。
【０２１７】
このような図２０の「イニシエータ側のATR_REQ送信処理」に対するターゲット側の処理（以下、ターゲット側のATR_REQ受信処理と呼ぶ）の一例が、図２１に示されている。即ち、図２１は、カプセル５１を含んでいる可能性があるコマンドATR_REQをターゲットが受信する場合の「ターゲット側のATR_REQ受信処理」の一例を説明するフローチャートである。
【０２１８】
後述するように、図２１の「ターゲット側のATR_REQ受信処理」の結果として、レスポンスATR_RESがターゲットからイニシエータに送信されてくるので、本実施の形態では、イニシエータが、上述した図１０のステップＳ１７または図１１のステップＳ３４の処理で、レスポンスATR_RESを受信する。この場合、図１０のステップＳ１７または図１１のステップＳ３４の処理として、例えば図２２に示される「イニシエータ側のATR_RES受信処理」を実行することができる。即ち、図２２は、少なくとも１つのカプセル５１を含むコマンドATR_REQに対するレスポンスATR_REＳをイニシエータが受信する場合の「イニシエータ側のATR_REＳ受信処理」の一例を説明するフローチャートである。
【０２１９】
なお、ここでは、上述したように、イニシエータがコマンドATR_REQを送信すると便宜上仮定しているため、図２０の「イニシエータ側のATR_REQ送信処理」はイニシエータにより実行され、図２１の「ターゲット側のATR_REQ受信処理」はターゲットにより実行され、図２２の「イニシエータ側のATR_REＳ受信処理」はイニシエータにより実行されることになる。ただし、上述したように、ターゲットがコマンドATR_REQを送信する場合もある。このような場合、図２０の「イニシエータ側のATR_REQ送信処理」はターゲットにより実行され、図２１の「ターゲット側のATR_REQ受信処理」はイニシエータにより実行され、図２２の「イニシエータ側のATR_REＳ受信処理」はターゲットにより実行されることになる。
【０２２０】
以下、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」のそれぞれについて、その順番に個別に説明していく。
【０２２１】
なお、以下の説明では、ｎ+1個のカプセル５１が生成または利用されることになるが、ｎ+1個のカプセル５１のうちの、リクエストATR_REQまたはレスポンスATR_REＳのフィールドGi[k]（kは、０乃至nのうちのいずれかの値）に格納される１つを、カプセル[k]と称する。
【０２２２】
はじめに、図２０のフローチャートを参照して、「イニシエータ側のATR_REQ送信処理」の一例を説明する。
【０２２３】
ステップＳ６１において、イニシエータは、コマンドATR_REQ用のカプセル［０］乃至［ｎ］のそれぞれを生成する。なお、コマンドATR_REQ用のカプセル［０］乃至［ｎ］の具体例については後述する。
【０２２４】
ステップＳ６２において、イニシエータは、カプセル［０］乃至［ｎ］のそれぞれを、コマンドATR_REQのフィールドGi[０]乃至Gi[n]のそれぞれに格納する。
【０２２５】
ステップＳ６３において、イニシエータは、コマンドATR_REQのフィールドPPiを設定する。
【０２２６】
ステップＳ６４において、イニシエータは、コマンドATR_REQのその他のフィールド（フィールドBSiやフィールドBRi等）を設定する。
【０２２７】
ステップＳ６５において、イニシエータは、コマンドATR_REQをターゲットに対して送信する。
【０２２８】
これにより、「イニシエータ側のATR_REQ送信処理」は終了となる。
【０２２９】
このようにして、コマンドATR_REQがイニシエータからターゲットに送信されると、ターゲットは、例えば図２１の「ターゲット側のATR_REQ受信処理」の処理を実行する。そこで、以下、図２１のフローチャートを参照して、「ターゲット側のATR_REQ受信処理」の一例を説明する。
【０２３０】
ステップＳ８１において、ターゲットは、コマンドATR_REQを受信する。
【０２３１】
ステップＳ８２において、ターゲットは、コマンドATR_REQの解釈を行う。
【０２３２】
ステップＳ８３において、ターゲットは、コマンドATR_REQの解釈の結果に基づいて、コマンドATR_REQのフィールドGi[0]乃至Gi[n]に情報が格納されているか否かを判定する。
【０２３３】
ステップＳ８３において、コマンドATR_REQのフィールドGi[0]乃至Gi[n]に情報が何も格納されていないと判定された場合、処理はステップＳ８８に進む。即ち、後述するステップＳ８４乃至Ｓ８７の処理は実行されない。なお、ステップＳ８８以降の処理については後述する。
【０２３４】
これに対して、図２０の「イニシエータ側のATR_REQ送信処理」の結果、イニシエータから送信されてきたコマンドATR_REQがステップＳ８１の処理で受信され、ステップＳ８２の処理で正しく解釈された場合には、コマンドATR_REQのフィールドGi[0]乃至Gi[n]のそれぞれにはカプセル[0]乃至カプセル[n]のそれぞれが格納されている。そこで、このような場合、ステップＳ８３において、コマンドATR_REQのフィールドGi[0]乃至Gi[n]に情報が格納されていると判定されて、処理はステップＳ８４に進む。
【０２３５】
ステップＳ８４において、ターゲットは、コマンドATR_REQのフィールドGi[0]乃至Gi[n]のそれぞれに従った所定の処理、即ち、フィールドGi[0]乃至Gi[n]のそれぞれに格納されたカプセル[0]乃至カプセル[ｋ]のそれぞれの内容に従った所定の処理を実行する。なお、ステップＳ８４において実行される所定の処理の具体例については後述する。
【０２３６】
ステップＳ８５において、ターゲットは、ステップＳ８４における所定の処理が成功したか否かを判定する。
【０２３７】
ステップＳ８５において、ステップＳ８４における所定の処理が失敗した（成功していない）と判定された場合、処理はステップＳ８８に進む。即ち、後述するステップＳ８６とＳ８７の処理は実行されない。なお、ステップＳ８８以降の処理については後述する。
【０２３８】
これに対して、ステップＳ８５において、ステップＳ８４における所定の処理が成功したと判定された場合、処理はステップＳ８６に進む。ステップＳ８６において、ターゲットは、レスポンスATR_RES用のカプセル［０］乃至［ｎ］を生成する。なお、レスポンスATR_RES用のカプセル［０］乃至［ｎ］の具体例については後述する。
【０２３９】
ステップＳ８７において、ターゲットは、カプセル［０］乃至［ｎ］のそれぞれを、レスポンスATR_RESのフィールドGi[０]乃至Gi[n]のそれぞれに格納する。これにより、処理はステップＳ８８に進む。
【０２４０】
以上説明したように、ステップＳ８７の処理が終了した場合、ステップＳ８３においてＮＯであると判定された場合、または、ステップＳ８５においてＮＯであると判定された場合、処理はステップＳ８８に進む。ステップＳ８８において、ターゲットは、レスポンスATR_RESのフィールドPPiを設定する。
【０２４１】
ステップＳ８９において、ターゲットは、レスポンスATR_RESのその他のフィールド（フィールドBSiやフィールドBRi等）を設定する。
【０２４２】
ステップＳ９０において、ターゲットは、レスポンスATR_RESをイニシエータに対して送信する。
【０２４３】
これにより、「ターゲット側のATR_REQ受信処理」は終了となる。
【０２４４】
このようにして、レスポンスATR_RESがターゲットからイニシエータに送信されると、イニシエータは、例えば図２２の「イニシエータ側のATR_REＳ受信処理」の処理を実行する。そこで、以下、図２２のフローチャートを参照して、「イニシエータ側のATR_REＳ受信処理」の一例を説明する。
【０２４５】
ステップＳ１０１において、イニシエータは、レスポンスATR_REＳを受信する。
【０２４６】
ステップＳ１０２において、イニシエータは、レスポンスATR_REＳの解釈を行う。
【０２４７】
ステップＳ１０３において、イニシエータは、レスポンスATR_REＳの解釈の結果に基づいて、レスポンスATR_REＳのフィールドGi[0]乃至Gi[n]に情報が格納されているか否かを判定する。
【０２４８】
ステップＳ１０３において、レスポンスATR_REＳのフィールドGi[0]乃至Gi[n]に情報が何も格納されていないと判定された場合、処理はステップＳ１０６に進む。ステップＳ１０６において、イニシエータは、カプセル[0]乃至[n]が格納されたコマンドATR_RESをターゲットに再送信する。
【０２４９】
その後、処理はステップＳ１０１に戻され、それ以降の処理が繰り返される。即ち、ステップＳ１０６の処理で再送信されたコマンドATR_RESに対してターゲットから送信されてきたレスポンスATR_RESがステップＳ１０１の処理で取得され、そのレスポンスATR_RESについてのそれ以降の処理が繰り返される。
【０２５０】
なお、ターゲットが、図２１の「ターゲット側のATR_REQ受信処理」を実行できない場合、即ち、図１２のカプセル５１を取り扱えない場合、ステップＳ１０１乃至Ｓ１０６のループ処理が延々と繰り返されることになる。そこで、図示はしないが、イニシエータは、ステップＳ１０１乃至Ｓ１０６のループ処理の繰り返し回数をカウントし、繰り返し回数が所定の閾値以上となった場合、ターゲットはカプセル５１を取り扱えないNFC通信装置であるとみなして、そのレスポンスATR_RESの設定内容を内部に記憶する等の所定の処理を実行した後、「イニシエータ側のATR_RES受信処理」を強制的に終了させるようにしてもよい。
【０２５１】
これに対して、図２１の「ターゲット側のATR_REQ受信処理」において、上述したステップＳ８６とＳ８７の処理が実行されて、ステップＳ９０の処理で、カプセル[0]乃至カプセル[ｋ]を含むレスポンスATR_RESがターゲットからイニシエータに送信され、さらに、そのレスポンスATR_RESがステップＳ１０１の処理で受信され、ステップＳ１０２の処理で正しく解釈された場合には、ステップＳ１０３において、レスポンスATR_RESのフィールドGi[0]乃至Gi[n]に情報が格納されていると判定されて、処理はステップＳ１０４に進む。
【０２５２】
ステップＳ１０４において、イニシエータは、レスポンスATR_RESのフィールドGi[0]乃至Gi[n]のそれぞれに従った所定の処理、即ち、フィールドGi[0]乃至Gi[n]のそれぞれに格納されたカプセル[0]乃至カプセル[ｋ]のそれぞれの内容に従った所定の処理を実行する。なお、ステップＳ１０４において実行される所定の処理の具体例については後述する。
【０２５３】
ステップＳ１０５において、イニシエータは、ステップＳ１０４における所定の処理が成功したか否かを判定する。
【０２５４】
ステップＳ１０５において、ステップＳ１０４における所定の処理が失敗した（成功していない）と判定された場合、処理はステップＳ１０６に進み、それ以降の処理が繰り返される。即ち、ステップS１０６の処理で、カプセル[0]乃至[n]が格納されたコマンドATR_RESが再送信され、ステップＳ１０１の処理で、それに対するレスポンスATR_RESがステップＳ１０１が取得され、そのレスポンスATR_RESについてのそれ以降の処理が繰り返される。
【０２５５】
これに対して、ステップＳ１０５において、ステップＳ１０４における所定の処理が成功したと判定された場合、「イニシエータ側のATR_RES受信処理」は終了となる。
【０２５６】
以上、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」のそれぞれについて説明した。
【０２５７】
ところで、このような図２０の「イニシエータ側のATR_REQ送信処理」が図１０のステップＳ１６または図１１のステップＳ３３の処理として実行され、図２２の「イニシエータ側のATR_REＳ受信処理」が図１０のステップＳ１７または図１１のステップＳ３４の処理として実行される場合には、コマンドATR_REQとレスポンスATR_RESとは１回ずつやり取りされることになる。
【０２５８】
ただし、コマンドATR_REQとレスポンスATR_RESとのやり取りの回数は、１回に限定されず、複数回でもよい。
【０２５９】
例えば、上述した図１２のカプセル５１を含むコマンドATR_REQとレスポンスATR_RESとを、イニシエータとターゲットとの間でやり取りすることで、所定の種類の能力の存在を交換して、その能力の活性化の指示や確認を実現することが可能になることについて上述した。この実現方法として、イニシエータとターゲットとは、所定の種類の能力の存在を交換するために、コマンドATR_REQとレスポンスATR_RESとのやり取りを１回行い、その後、その所定の種類の能力の活性化の指示や確認を行うために、コマンドATR_REQとレスポンスATR_RESとのやり取りをさらに１回行うことができる。
【０２６０】
この場合、図示はしないが、図１０のステップＳ１６とＳ１７との処理、または、図１１のステップＳ３３とＳ３４との処理が２回繰り返された後、図１０のステップ１８または図１１のステップＳ３５の処理が実行されることになる。即ち、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」の一連の処理が２回繰り返された後、図１０のステップ１８または図１１のステップＳ３５の処理が実行されることになる。
【０２６１】
以下、所定の種類の能力の存在を交換するために実行される、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」の一連の処理の具体例について説明する。そして、その説明に続いて、その所定の種類の能力の活性化の指示や確認を実現するために実行される、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」の一連の処理の具体例について説明する。
【０２６２】
即ち、ここでは、イニシエータとターゲットとの間の無線通信の出力電力の制御（以下、RF Power controlと記述する）の能力を、能力の１つの種類の具体例として挙げて、以下の説明を行っていく。換言すると、ここでは、イニシエータとターゲットとが、RF Power controlの能力のレベルを交換して、そのレベルの範囲内でRF Power controlを行うための指示（活性化の指示）や確認を行う場合におけるイニシエータとターゲットとが実行する一連の処理の具体例について説明する。
【０２６３】
この場合、はじめに、イニシエータとターゲットとは、RF Power controlの能力を交換するために、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」の一連の処理を１回行う。
【０２６４】
詳細には、イニシエータは、図２０のステップＳ６１の処理で、例えば次のようなカプセル［0］
を生成する。
【０２６５】
即ち、イニシエータは、図１２の「処理を指示する情報」フィールド６２に対して、「RF Power Controlの能力の報告」という内容を示す情報を設定する。
【０２６６】
次に、イニシエータは、「能力を示す情報」フィールド６３に対して、自分自身のRF Power Controlの能力を示す情報として、「出力電力が所定の最大値Hmaxを超えられるか否か」、「出力電力が所定の最小値Hminを超えられるか否か」、「最大値Hmaxと最小値Hminとの間は何段階で調節可能であるのか」、「デフォルトの値の指示」、「最大値Hmaxと機器固有の最大出力電力（RF Power）との間は何段階で調節可能であるのか」、および「最小値Hminと機器固有の最小出力電力（RF Power）との間は何段階で調節可能であるのか」等の情報を設定する。
【０２６７】
次に、イニシエータは、「能力を示す情報に対する指示」フィールド６４に対して、「「能力を示す情報」フィールド６３の設定値を記憶せよ」という命令を設定する。
【０２６８】
次に、イニシエータは、「付随情報」フィールド６５に対して、「このカプセル５１に格納された各情報を理解して、「能力を示す情報」フィールド６３の設定値の記憶を完了したならば、レスポンスATR_RESに含めるカプセル５１のうちの「付随情報」フィールド６５に対して、所定の合言葉｛RF Power能力解釈完了｝を設定することで返事をせよ」という内容を示す情報を設定する。
【０２６９】
そして、イニシエータは、このようにして設定された各フィールドを図１２に示される順番で配置することで、カプセル[0]を生成する。
【０２７０】
次に、図２０のステップＳ６２の処理で、イニシエータは、このカプセル[0]を、コマンドATR_REQのフィールドGi[０]に格納する。
【０２７１】
次に、ステップＳ６３の処理で、イニシエータは、コマンドATR_REQのフィールドPPiの設定を行う。詳細には、イニシエータは、上述した図１６のビットbit1に対して１を設定することにより、即ち、情報Giとして１を設定することにより、フィールドGi（General Byte）が有効であることを示す。また、イニシエータは、いまの場合、フィールドGi[０]だけが利用され、その結果、フィールドByte14までのコマンドATR_REQとなることから、図１６のビットbit4，bit5に対して「００」を設定する。即ち、情報LRiとして「００」が設定される。なお、いまの場合、n=0とされているため、情報LRiとして「００」が設定されたが、上述したように、「００」、「０１」、「１１」、および、「１１」のうちの、実際のｎに対応する適切な値が設定される。また、イニシエータは、フィールドPPiのその他のビットに対しても適切な値を設定する。
【０２７２】
そして、イニシエータは、ステップＳ６４の処理で、その他のフィールド（図１３のフィールドBSiやフィールドBRi等）の設定を行い、ステップＳ６５の処理で、このようにして各情報（各値）が設定されたコマンドATR_REQをターゲットに送信する。
【０２７３】
すると、ターゲットは、図２１のステップＳ８１の処理で、このコマンドATR_REQを受信し、ステップＳ８２の処理で、その解釈を行う。
【０２７４】
ステップＳ８２におけるコマンドATR_REQの解釈が成功すると、ステップＳ８３の処理で、コマンドATR_REQのフィールドGi[0]に情報が格納されていると判定されて、処理はステップＳ８４に進む。
【０２７５】
ステップＳ８４の処理で、ターゲットは、コマンドATR_REQのフィールドGi[0]に格納されているカプセル[０]に従って、例えば次のような処理を実行する。
【０２７６】
即ち、いまの場合、カプセル［0］のうちの図１２の「処理を指示する情報」フィールド６２には、「RF Power Controlの能力の報告」という内容を示す情報が設定されるので、ターゲットは、このカプセル[0]は、イニシエータについての「RF Power Controlの能力の報告」をするためのカプセルであることを認識する。
【０２７７】
次に、ターゲットは、カプセル［0］のうちの「能力を示す情報に対する指示」フィールド６４の設定内容、即ち、「「能力を示す情報」フィールド６３の設定値を記憶せよ」という命令を受け取り、カプセル［0］のうちの「能力を示す情報」フィールド６３の設定内容を読み出して、自分自身の内部に記憶する。
【０２７８】
そして、ターゲットは、カプセル［0］のうちの「付随情報」フィールド６５の設定内容、即ち、「このカプセル５１に格納された各情報を理解して、「能力を示す情報」フィールド６３の設定値の記憶を完了したならば、レスポンスATR_RESに含めるカプセル５１のうちの「付随情報」フィールド６５に対して、所定の合言葉｛RF Power能力解釈完了｝を設定することで返事をせよ」という内容を認識する。
【０２７９】
これにより、ステップＳ８５の処理では、所定の処理が成功したと判定されて、処理はステップＳ８６に進む。
【０２８０】
ターゲットは、ステップＳ８６の処理で、例えば次のような、レスポンスATR_RES用のカプセル［0］を生成する。
【０２８１】
即ち、ターゲットは、図１２の「処理を指示する情報」フィールド６２に対して、「RF Power Controlの自身の能力の報告、および、イニシエータからの報告に対する返答」という内容を示す情報を設定する。
【０２８２】
次に、ターゲットは、「能力を示す情報」フィールド６３に対して、自分自身のRF Power Controlの能力を示す情報として、「出力電力が所定の最大値Hmaxを超えられるか否か」、「出力電力が所定の最小値Hminを超えられるか否か」、「最大値Hmaxと最小値Hminとの間は何段階で調節可能であるのか」、「デフォルトの値の指示」、「最大値Hmaxと機器固有の最大出力電力（RF Power）との間は何段階で調節可能であるのか」、および「最小値Hminと機器固有の最小出力電力（RF Power）との間は何段階で調節可能であるのか」等の情報を設定する。
【０２８３】
次に、ターゲットは、「能力を示す情報に対する指示」フィールド６４に対して、「「能力を示す情報」フィールド６３の設定値を記憶せよ」という命令を設定する。
【０２８４】
次に、ターゲットは、「付随情報」フィールド６５に対して、イニシエータからのコマンドATR_REQに含まれていた上述した指示に従って、所定の合言葉｛RF Power能力解釈完了｝を示す情報を設定する。
【０２８５】
そして、ターゲットは、このようにして設定された各フィールドを図１２に示される順番で配置することで、カプセル[0]を生成する。
【０２８６】
次に、図２１のステップＳ８７の処理で、ターゲットは、このカプセル[0]を、レスポンスATR_RESのフィールドGi[０]に格納する。
【０２８７】
次に、ステップＳ８８の処理で、ターゲットは、コマンドATR_REQのフィールドPPiの設定を行う。詳細には、ターゲットは、上述した図１６のビットbit1に対して１を設定することにより、即ち、情報Giとして１を設定することにより、フィールドGi（General Byte）が有効であることを示す。また、ターゲットは、いまの場合、フィールドGi[０]だけが利用され、その結果、フィールドByte14までのレスポンスATR_RESとなることから、図１６のビットbit4，bit5に対して「００」を設定する。即ち、情報LRiとして「００」が設定される。なお、いまの場合、n=0とされているため、情報LRiとして「００」が設定されたが、上述したように、「００」、「０１」、「１１」、および、「１１」のうちの、実際のｎに対応する適切な値が設定される。また、ターゲットは、フィールドPPiのその他のビットに対しても適切な値を設定する。
【０２８８】
そして、ターゲットは、ステップＳ８９の処理で、その他のフィールド（図１３のフィールドBSiやフィールドBRi等）の設定を行い、ステップＳ９０の処理で、このようにして各情報（各値）が設定されたレスポンスATR_RESをイニシエータに送信する。
【０２８９】
すると、イニシエータは、図２２のステップＳ１０１の処理で、このレスポンスATR_RESを受信し、ステップＳ１０２の処理で、その解釈を行う。
【０２９０】
ステップＳ１０２におけるレスポンスATR_RESの解釈が成功すると、ステップＳ１０３の処理で、レスポンスATR_RESのフィールドGi[0]に情報が格納されていると判定されて、処理はステップＳ１０４に進む。
【０２９１】
ステップＳ１０４の処理で、イニシエータは、レスポンスATR_RESのフィールドGi[0]に格納されているカプセル[０]に従って、例えば次のような処理を実行する。
【０２９２】
即ち、いまの場合、カプセル［0］のうちの図１２の「処理を指示する情報」フィールド６２には、「RF Power Controlの能力の報告、および、イニシエータからの報告に対する返答」という内容を示す情報が設定されるので、イニシエータは、このカプセル[0]は、ターゲットについてのRF Power Controlの能力の報告と、先に送信したコマンドATR_REQに対する返答とを行うためのカプセルであることを認識する。
【０２９３】
次に、イニシエータは、カプセル［0］のうちの「能力を示す情報に対する指示」フィールド６４の設定内容、即ち、「「能力を示す情報」フィールド６３の設定値を記憶せよ」という命令を受け取り、カプセル［0］のうちの「能力を示す情報」フィールド６３の設定内容を読み出して、自分自身の内部に記憶する。
【０２９４】
そして、イニシエータは、カプセル［0］のうちの「付随情報」フィールド６５の設定内容、即ち、所定の合言葉｛RF Power能力解釈完了｝という内容を認識する。
【０２９５】
これにより、ステップＳ１０５の処理では、所定の処理が成功したと判定されて、「イニシエータ側のATR＿RES受信処理」が終了となる。
【０２９６】
以上のようにして、イニシエータとターゲットとは、RF Power controlの能力のレベルを交換することができる。
【０２９７】
次に、イニシエータとターゲットとは、そのレベルの範囲内でRF Power controlを行うための指示（活性化の指示）や確認を行うために、図２０の「イニシエータ側のATR_REQ送信処理」、図２１の「ターゲット側のATR_REQ受信処理」、および、図２２の「イニシエータ側のATR_REＳ受信処理」の一連の処理を１回行う。
【０２９８】
詳細には、イニシエータは、図２０のステップＳ６１の処理で、例えば次のようなカプセル［0］
を生成する。
【０２９９】
即ち、イニシエータは、図１２の「処理を指示する情報」フィールド６２に対して、「実行指示」という内容を示す情報を設定する。
【０３００】
次に、イニシエータは、「能力を示す情報」フィールド６３に対して、「実行指示の対象はRF Power Controlである」という内容を示す情報を設定する。
【０３０１】
次に、イニシエータは、「能力を示す情報に対する指示」フィールド６４に対して、「出力電力（RF Power）を最小値Hminよりも2段階下げろ」という命令を設定する。なお、ここでは、最小値Hminからゼロまでの範囲内で3段階の調節ができる能力をターゲット有しているという情報が、能力の存在の交換についての上述した一連の処理の結果として、イニシエータにより認識済みであるとする。
【０３０２】
次に、イニシエータは、「付随情報」フィールド６５に対して、「このカプセル５１に格納された各情報を理解して、「能力を示す情報に対する指示」フィールド６４に設定された命令に対する処理の実行を完了したならば、レスポンスATR_RESに含めるカプセル５１のうちの「付随情報」フィールド６５に対して、所定の合言葉｛出力電圧を２段階下げるのに成功しました｝を設定することで返事をせよ」という内容を示す情報を設定する。
【０３０３】
そして、イニシエータは、このようにして設定された各フィールドを図１２に示される順番で配置することで、カプセル[0]を生成する。
【０３０４】
次に、図２０のステップＳ６２の処理で、イニシエータは、このカプセル[0]を、コマンドATR_REQのフィールドGi[０]に格納する。
【０３０５】
次に、ステップＳ６３の処理で、イニシエータは、コマンドATR_REQのフィールドPPiの設定を行う。詳細には、イニシエータは、上述した図１６のビットbit1に対して１を設定することにより、即ち、情報Giとして１を設定することにより、フィールドGi（General Byte）が有効であることを示す。また、イニシエータは、いまの場合、フィールドGi[０]だけが利用され、その結果、フィールドByte14までのコマンドATR_REQとなることから、図１６のビットbit4，bit5に対して「００」を設定する。即ち、情報LRiとして「００」が設定される。なお、いまの場合、n=0とされているため、情報LRiとして「００」が設定されたが、上述したように、「００」、「０１」、「１１」、および、「１１」のうちの、実際のｎに対応する適切な値が設定される。また、イニシエータは、フィールドPPiのその他のビットに対しても適切な値を設定する。
【０３０６】
そして、イニシエータは、ステップＳ６４の処理で、その他のフィールド（図１３のフィールドBSiやフィールドBRi等）の設定を行い、ステップＳ６５の処理で、このようにして各情報（各値）が設定されたコマンドATR_REQをターゲットに送信する。
【０３０７】
すると、ターゲットは、図２１のステップＳ８１の処理で、このコマンドATR_REQを受信し、ステップＳ８２の処理で、その解釈を行う。
【０３０８】
ステップＳ８２におけるコマンドATR_REQの解釈が成功すると、ステップＳ８３の処理で、コマンドATR_REQのフィールドGi[0]に情報が格納されていると判定されて、処理はステップＳ８４に進む。
【０３０９】
ステップＳ８４の処理で、ターゲットは、コマンドATR_REQのフィールドGi[0]に格納されているカプセル[０]に従って、例えば次のような処理を実行する。
【０３１０】
即ち、いまの場合、カプセル［0］のうちの図１２の「処理を指示する情報」フィールド６２には、「実行指示」という内容を示す情報が設定されるので、ターゲットは、このカプセル[0]は、所定の種類の能力の活性化を指示するためのカプセルであることを認識する。
【０３１１】
そこで、ターゲットは、何れの種類の能力の活性化を指示するのかを認識するために、カプセル［0］のうちの「能力を示す情報」フィールド６３の設定内容を読み出す。いまの場合、「実行指示の対象はRF Power Controlである」という内容を示す情報が読み出される。従って、ターゲットは、このカプセル[0]は、RF Power Controlの実行の指示を行うカプセルであることを認識する。
【０３１２】
次に、ターゲットは、「能力を示す情報に対する指示」フィールド６４の設定内容、即ち、「出力電力（RF Power）を最小値Hminよりも2段階下げろ」という命令を受け取り、自分自身の出力電力（RF Power）を最小値Hminよりも2段階下げるために必要な各種処理を実行する。
【０３１３】
そして、ターゲットは、カプセル［0］のうちの「付随情報」フィールド６５の設定内容、即ち、「このカプセル５１に格納された各情報を理解して、「能力を示す情報に対する指示」フィールド６４に設定された命令に対する処理の実行を完了したならば、レスポンスATR_RESに含めるカプセル５１のうちの「付随情報」フィールド６５に対して、所定の合言葉｛出力電圧を２段階下げるのに成功しました｝を設定することで返事をせよ」という内容を認識する。
【０３１４】
これにより、ステップＳ８５の処理では、所定の処理が成功したと判定されて、処理はステップＳ８６に進む。
【０３１５】
ターゲットは、ステップＳ８６の処理で、例えば次のような、レスポンスATR_RES用のカプセル［0］を生成する。
【０３１６】
即ち、ターゲットは、図１２の「処理を指示する情報」フィールド６２に対して、「イニシエータからの命令に対する返答」という内容を示す情報を設定する。
【０３１７】
次に、ターゲットは、「付随情報」フィールド６５に対して、イニシエータからのコマンドATR_REQに含まれていた上述した指示に従って、所定の合言葉｛出力電圧を２段階下げるのに成功しました｝を示す情報を設定する。
【０３１８】
そして、ターゲットは、このようにして設定された各フィールドを図１２に示される順番で配置することで、カプセル[0]を生成する。
【０３１９】
なお、ここでは、ターゲットは、イニシエータからの命令に対する返答のみを行うとして、「能力を示す情報」フィールド６３と、「能力を示す情報に対する指示」フィールド６４とには何も設定しない。ただし、ターゲットが、イニシエータ側のRF Power Controlを実行する場合には、「能力を示す情報」フィールド６３や、「能力を示す情報に対する指示」フィールド６４に対して、イニシエータからのコマンドATR_REQに含まれるカプセルG[0]の設定内容と同様の内容を設定することもできる。
【０３２０】
次に、図２１のステップＳ８７の処理で、ターゲットは、このカプセル[0]を、レスポンスATR_RESのフィールドGi[０]に格納する。
【０３２１】
次に、ステップＳ８８の処理で、ターゲットは、コマンドATR_REQのフィールドPPiの設定を行う。詳細には、ターゲットは、上述した図１６のビットbit1に対して１を設定することにより、即ち、情報Giとして１を設定することにより、フィールドGi（General Byte）が有効であることを示す。また、ターゲットは、いまの場合、フィールドGi[０]だけが利用され、その結果、フィールドByte14までのレスポンスATR_RESとなることから、図１６のビットbit4，bit5に対して「００」を設定する。即ち、情報LRiとして「００」が設定される。なお、いまの場合、n=0とされているため、情報LRiとして「００」が設定されたが、上述したように、「００」、「０１」、「１１」、および、「１１」のうちの、実際のｎに対応する適切な値が設定される。また、ターゲットは、フィールドPPiのその他のビットに対しても適切な値を設定する。
【０３２２】
そして、ターゲットは、ステップＳ８９の処理で、その他のフィールド（図１３のフィールドBSiやフィールドBRi等）の設定を行い、ステップＳ９０の処理で、このようにして各情報（各値）が設定されたレスポンスATR_RESをイニシエータに送信する。
【０３２３】
すると、イニシエータは、図２２のステップＳ１０１の処理で、このレスポンスATR_RESを受信し、ステップＳ１０２の処理で、その解釈を行う。
【０３２４】
ステップＳ１０２におけるレスポンスATR_RESの解釈が成功すると、ステップＳ１０３の処理で、レスポンスATR_RESのフィールドGi[0]に情報が格納されていると判定されて、処理はステップＳ１０４に進む。
【０３２５】
ステップＳ１０４の処理で、イニシエータは、レスポンスATR_RESのフィールドGi[0]に格納されているカプセル[０]に従って、例えば次のような処理を実行する。
【０３２６】
即ち、いまの場合、カプセル［0］のうちの図１２の「処理を指示する情報」フィールド６２には、「イニシエータからの命令に対する返答」という内容を示す情報が設定されるので、イニシエータは、このカプセル[0]は、先に送信したコマンドATR_REQに対する返答を行うためのカプセルであることを認識する。
【０３２７】
そこで、イニシエータは、カプセル［0］のうちの「付随情報」フィールド６５の設定内容、即ち、所定の合言葉｛出力電圧を２段階下げるのに成功しました｝という内容を認識する。
【０３２８】
これにより、ステップＳ１０５の処理では、所定の処理が成功したと判定されて、「イニシエータ側のATR＿RES受信処理」が終了となる。
【０３２９】
以上のようにして、イニシエータとターゲットとは、RF Power controlの能力のレベルを交換した後に、そのレベルの範囲内でRF Power controlを行うための指示（活性化の指示）や確認を行うことができる。
【０３３０】
これにより、例えば、イニシエータが、重要度の高い情報を、ターゲットに対して書き込んだり、或いはターゲットから読み出す場合、その情報が送受信される際の出力電圧を可能な限り低く抑えることが可能になり、その結果、その情報の秘匿性を図ることができる、即ち、その情報の盗聴を防止することができるという効果を奏することが可能になる。特に、ターゲットがカード等で構成され、そのカードの発行時に、イニシエータがそのカードに対して鍵情報等の重要情報を書き込む場合に、この効果はより顕著なものとなる。
【０３３１】
また、例えば、イニシエータが、他のターゲットが存在する状態で、所定のターゲットを通信相手として通信を行う場合には、上述したように、コリジョンが生じる場合がある。このような場合も、イニシエータは、他のターゲットの出力電圧を抑えるとともに、通信相手のターゲットの出力電力を上げることで、コリジョンを防止することができるという効果を奏することも可能になる。
【０３３２】
また、上述した例では、RF Power controlの能力のレベルを交換する場合にも、そのレベルの範囲内でRF Power controlを行うための指示（活性化の指示）や確認を行う場合にも、図１２のカプセル５１は、コマンドATR_REQやレスポンスATR_RESに格納されたが、上述したように、その格納先は特に限定されない。例えば、RF Power controlの能力のレベルを交換する場合には、コマンドATR_REQやレスポンスATR_RESにカプセル５１を格納させて、そのレベルの範囲内でRF Power controlを行うための指示（活性化の指示）や確認を行う場合には、コマンドDEP_REQやレスポンスDEP_RESにカプセル５１を格納させることも可能である。
【０３３３】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【図面の簡単な説明】
【０３３４】
【図１】本発明を適用した通信システムの一実施の形態の構成例を示す図である。
【図２】パッシブモードを説明する図である。
【図３】アクティブモードを説明する図である。
【図４】NFC 通信装置１ の構成例を示すブロック図である。
【図５】初期RFCA 処理を説明するタイミングチャートである。
【図６】アクティブRFCA 処理を説明するタイミングチャートである。
【図７】SDD 処理を説明する図である。
【図８】コマンドとレスポンスの一覧を示す図である。
【図９】NFC 通信装置が行う一般的な初期化とSDD を説明するためのフローチャートである。
【図１０】パッシブモードにおけるアクティベーションプロトコルを説明するためのフローチャートである。
【図１１】アクティブモードにおけるアクティベーションプロトコルを説明するためのフローチャートである。
【図１２】本発明が適用されるカプセルの構造例を説明する図である。
【図１３】コマンドATR_REQの構造を説明する図である。
【図１４】コマンドATR_REQのフィールドBSiの構造を説明する図である。
【図１５】コマンドATR_REQのフィールドBSiまたはフィールドBRiに設定可能な伝送レートを説明する図である。
【図１６】コマンドATR_REQのフィールドPPiの構造を説明する図である。
【図１７】コマンドATR_REQのフィールドPPiのビットbit4に設定可能な情報LRiを説明する図である。
【図１８】コマンドATR_REQのフィールドPPiのビットbit4に設定可能な情報LRiを説明する他の図である。
【図１９】レスポンスATR_RESの構造を説明する図である。
【図２０】イニシエータ側のATR_REQ送信処理を説明するためのフローチャートである。
【図２１】ターゲット側のATR_REQ受信処理を説明するためのフローチャートである。
【図２２】イニシエータ側のATR_REＳ受信処理を説明するためのフローチャートである。
【符号の説明】
【０３３５】
１ 乃至３ NFC 通信装置， １１ アンテナ， １２ 受信部， １３ 復調部， １４ デコード部， １５ データ処理部， １６ エンコード部， １７ 選択部， １８ 電磁波出力部， １９ 変調部， ２０ 負荷変調部， ２１ 制御部， ２１Ａ CPU， ２１Ｂ EEPROM， ２２ 電源部， ５１ カプセル，６１乃至６５ フィールド
【図１】
2006211519.tif 000003
【図２】
2006211519.tif 000004
【図３】
2006211519.tif 000005
【図４】
2006211519.tif 000006
【図５】
2006211519.tif 000007
【図６】
2006211519.tif 000008
【図７】
2006211519.tif 000009
【図８】
2006211519.tif 000010
【図９】
2006211519.tif 000011
【図１０】
2006211519.tif 000012
【図１１】
2006211519.tif 000013
【図１２】
2006211519.tif 000014
【図１３】
2006211519.tif 000015
【図１４】
2006211519.tif 000016
【図１５】
2006211519.tif 000017
【図１６】
2006211519.tif 000018
【図１７】
2006211519.tif 000019
【図１８】
2006211519.tif 000020
【図１９】
2006211519.tif 000021
【図２０】
2006211519.tif 000022
【図２１】
2006211519.tif 000023
【図２２】
2006211519.tif 000024