JP2006211519A - 通信装置、通信方法、およびプログラム - Google Patents

通信装置、通信方法、およびプログラム Download PDF

Info

Publication number
JP2006211519A
JP2006211519A JP2005023434A JP2005023434A JP2006211519A JP 2006211519 A JP2006211519 A JP 2006211519A JP 2005023434 A JP2005023434 A JP 2005023434A JP 2005023434 A JP2005023434 A JP 2005023434A JP 2006211519 A JP2006211519 A JP 2006211519A
Authority
JP
Japan
Prior art keywords
communication
initiator
communication device
data
command
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005023434A
Other languages
English (en)
Other versions
JP4432787B2 (ja
Inventor
Yoshihisa Takayama
佳久 高山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2005023434A priority Critical patent/JP4432787B2/ja
Application filed by Sony Corp filed Critical Sony Corp
Priority to US11/814,974 priority patent/US8515345B2/en
Priority to PCT/JP2006/301309 priority patent/WO2006080435A1/ja
Priority to EP06712475.0A priority patent/EP1845632B1/en
Priority to CN200680003635.0A priority patent/CN101112010B/zh
Publication of JP2006211519A publication Critical patent/JP2006211519A/ja
Priority to HK08102542.1A priority patent/HK1111828A1/xx
Application granted granted Critical
Publication of JP4432787B2 publication Critical patent/JP4432787B2/ja
Priority to US13/908,689 priority patent/US8874033B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/72—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for local intradevice communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/40—Near-field transmission systems, e.g. inductive or capacitive transmission systems characterised by components specially adapted for near-field transmission
    • H04B5/48—Transceivers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/77—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for interrogation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/79—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for data transfer in combination with power transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Near-Field Transmission Systems (AREA)
  • Telephone Function (AREA)

Abstract

【課題】近接通信を行う通信装置が本来有している能力を十分に発揮することができるようにする。
【解決手段】 イニシエータは、NFCIP-1に従って、ターゲットと近接通信を行う。例えば、イニシエータは、イニシエータ自身またはターゲットが有する所定のn+1種類の能力のそれぞれについて、対応する能力に関連する情報を１以上含むカプセル[0]乃至[n]を生成する（Ｓ６１）。次に、イニシエータは、生成されたカプセル[0]乃至[n]を含むコマンドATR_REQを生成する（Ｓ６２乃至Ｓ６４）。そして、イニシエータは、コマンドATR_REQをターゲットに送信する。本発明は、例えば、ICカードシステムなどに適用できる。
【選択図】図２０

Description

本発明は、通信装置、通信方法、およびプログラムに関し、例えば、近接通信を行う通信装置が本来有している能力を十分に発揮することができるようにする通信装置、通信方法、およびプログラムに関する。
近接通信を行うシステムとしては、例えば、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， ２２ 電源部， ５１ カプセル，６１乃至６５ フィールド

Claims (10)

  1. データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置において、
    前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御手段
    を備えることを特徴とする通信装置。
  2. 前記通信プロトコルは、前記通信装置および前記他の通信装置が有すべきまたは有することが可能な属性をさらに規定し、１以上の前記コマンドのうちの１つとして、前記属性を通信相手に通知するまたは要求するための属性コマンドを少なくとも規定し、１以上の前記コマンドのうちの１つとして、前記属性コマンドに対する属性レスポンスを少なくとも規定しており、
    前記制御手段は、前記通信プロトコルに前記属性として規定されている種類とは異なるｎ+1種類（nは、０以上の整数値）の能力のそれぞれについて、対応する種類の能力に関連する情報を１以上含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドまたは前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項１に記載の通信装置。
  3. 前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項２に記載の通信装置。
  4. 前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記他の通信装置が有しているまたは有することが可能なレベルを前記通信装置自身に対して通知する指示を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項２に記載の通信装置。
  5. 前記他の通信装置により、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを前記他の通信装置に対して通知する指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個の前記データ群が前記属性コマンドに格納されて前記通信装置自身に送信されてきた場合、
    前記制御手段は、
    前記属性コマンドを前記通信装置自身が受信する制御をさらに行い、
    受信された前記属性コマンドに格納されたn+1個の前記データ群のそれぞれに含まれる前記指示に基づいて、n+1種類の能力のそれぞれについて、対応する種類の能力についての、前記通信装置自身が有しているまたは有することが可能なレベルを示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項２に記載の通信装置。
  6. 前記制御手段は、n+1種類の能力のそれぞれについて、対応する種類の能力の活性化を前記他の通信装置が行うことの指示を少なくとも含む前記データ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性コマンドに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項２に記載の通信装置。
  7. 前記他の通信装置により、n+1種類の能力のそれぞれについて、対応する能力の活性化を前記通信装置自身が行うことの指示を少なくとも含むデータ群がn+1種類毎にそれぞれ生成され、生成されたn+1個の前記データ群が前記属性コマンドに格納されて前記通信装置自身に送信されてきた場合、
    前記制御手段は、
    前記属性コマンドを前記通信装置自身が受信する制御をさらに行い、
    受信された前記属性コマンドに格納されたn+1個の前記データ群のそれぞれに含まれる前記指示に基づいて、n+1種類の能力のそれぞれの活性化を行うための制御をさらに行い、
    n+1種類の能力のそれぞれについて、対応する種類の能力の活性化の結果を示す情報を少なくとも含むデータ群をn+1種類毎にそれぞれ生成し、生成されたn+1個の前記データ群を、前記属性レスポンスに格納させて、前記他の通信装置に送信する制御を行う
    ことを特徴とする請求項２に記載の通信装置。
  8. 前記コマンドまたは前記レスポンスに格納される１以上のデータ群のそれぞれに含まれる情報により特定される１種類以上の能力のうちの１種類は、前記通信装置または前記他の通信装置が出力する電磁波の電力の制御を行う能力である
    ことを特徴とする請求項１に記載の通信装置。
  9. データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置の通信方法において、
    前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ
    を含むことを特徴とする通信方法。
  10. データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行うこと、１以上のコマンド、および、１以上のレスポンスが少なくとも規定されている通信プロトコルに従って、通信相手である他の通信装置と通信を行う通信装置を制御するコンピュータに実行させるプログラムにおいて、
    前記通信装置自身または前記他の通信装置が有する所定の１種類の能力に関連する情報を１以上含むデータ群を能力の種類毎にそれぞれ生成し、生成された１以上の前記データ群を、前記通信プロトコルで規定されている１以上の前記コマンドおよび１以上の前記レスポンスのうちの所定の１つに格納させて、前記他の通信装置に送信する制御を行う制御ステップ
    を含むことを特徴とするプログラム。
JP2005023434A 2005-01-31 2005-01-31 通信装置、通信方法、およびプログラム Active JP4432787B2 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2005023434A JP4432787B2 (ja) 2005-01-31 2005-01-31 通信装置、通信方法、およびプログラム
PCT/JP2006/301309 WO2006080435A1 (ja) 2005-01-31 2006-01-27 通信装置、通信方法、およびプログラム
EP06712475.0A EP1845632B1 (en) 2005-01-31 2006-01-27 Communication apparatus, communication method, and program
CN200680003635.0A CN101112010B (zh) 2005-01-31 2006-01-27 用于近场通信的通信装置和通信方法
US11/814,974 US8515345B2 (en) 2005-01-31 2006-01-27 Communication apparatus, communication method, and program
HK08102542.1A HK1111828A1 (en) 2005-01-31 2008-03-05 Communication apparatus and communication method for near field communication
US13/908,689 US8874033B2 (en) 2005-01-31 2013-06-03 Communication apparatus, communication method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005023434A JP4432787B2 (ja) 2005-01-31 2005-01-31 通信装置、通信方法、およびプログラム

Publications (2)

Publication Number Publication Date
JP2006211519A true JP2006211519A (ja) 2006-08-10
JP4432787B2 JP4432787B2 (ja) 2010-03-17

Family

ID=36740459

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005023434A Active JP4432787B2 (ja) 2005-01-31 2005-01-31 通信装置、通信方法、およびプログラム

Country Status (6)

Country Link
US (2) US8515345B2 (ja)
EP (1) EP1845632B1 (ja)
JP (1) JP4432787B2 (ja)
CN (1) CN101112010B (ja)
HK (1) HK1111828A1 (ja)
WO (1) WO2006080435A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8068011B1 (en) 2010-08-27 2011-11-29 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
US8537907B2 (en) 2010-02-23 2013-09-17 Samsung Electronics Co., Ltd Receiving system for use in near field communication and mode detection method therefore
JP2016010117A (ja) * 2014-06-26 2016-01-18 カシオ計算機株式会社 無線通信装置、無線通信システム、無線通信方法、及びプログラム
JP2016119705A (ja) * 2011-09-30 2016-06-30 クアルコム，インコーポレイテッド Ｎｆｃデータ交換構成パラメータ更新機構を改善するための方法および装置

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101408544B1 (ko) * 2007-05-07 2014-06-17 삼성전자주식회사 근거리무선통신의 데이터 송수신 방법
US8340111B1 (en) * 2008-03-26 2012-12-25 Marvell Israel (M.I.S.L) Ltd. Method and apparatus for power reduction in network
JP4458184B2 (ja) * 2008-06-09 2010-04-28 ソニー株式会社 情報管理装置、通信処理装置、および方法、並びにプログラム
JP4548524B2 (ja) 2008-07-29 2010-09-22 ソニー株式会社 通信装置、プログラム、通信方法および通信システム
JP4720899B2 (ja) * 2008-11-27 2011-07-13 ソニー株式会社 通信装置、通信方法、プログラム、および通信システム
US20110059692A1 (en) * 2009-09-08 2011-03-10 Electronics And Telecommunications Research Institute Communications device using near field
US20110076951A1 (en) * 2009-09-30 2011-03-31 Kabushiki Kaisha Toshiba Information processing apparatus
EP2540121A1 (en) * 2010-02-22 2013-01-02 Qualcomm Incorporated Controlling access point transmit power based on event-triggered access terminal messaging
JP5710649B2 (ja) 2010-02-22 2015-04-30 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ アクセス端末ランク付けに基づいてアクセスポイント送信電力を制御すること
US9397726B2 (en) 2010-08-23 2016-07-19 Radeum, Inc. System and method for communicating between near field communication devices within a target region using near field communication
WO2013012114A1 (ko) 2011-07-21 2013-01-24 엘지전자 주식회사 무선 전력 신호를 통한 무선 전력 수신기의 통신
US9124303B2 (en) * 2011-10-19 2015-09-01 Nokia Technologies Oy Apparatus and method for near field communication
US9214988B2 (en) 2012-02-06 2015-12-15 Qualcomm Incorporated Methods and apparatus for improving peer communications using an active communication mode
JP6019675B2 (ja) 2012-03-30 2016-11-02 ブラザー工業株式会社 機能実行装置
JP6019676B2 (ja) 2012-03-30 2016-11-02 ブラザー工業株式会社 通信装置
JP5867319B2 (ja) 2012-07-03 2016-02-24 ブラザー工業株式会社 通信装置
JP5958161B2 (ja) 2012-08-03 2016-07-27 ブラザー工業株式会社 通信装置
JP5900228B2 (ja) * 2012-08-06 2016-04-06 ブラザー工業株式会社 通信装置
FR3002099B1 (fr) 2013-02-12 2016-05-27 Proton World Int Nv Configuration de routeurs nfc pour communication p2p
JP6332768B2 (ja) * 2013-03-18 2018-05-30 華為終端（東莞）有限公司 Ｎｆｃデバイスのための通信方法および装置ならびにそのｎｆｃデバイス
KR20150009072A (ko) * 2013-07-12 2015-01-26 삼성전자주식회사 동작모드 제어 방법 및 그 방법을 처리하는 전자 장치
US9088895B2 (en) * 2013-08-19 2015-07-21 Arm Ip Limited Establishing communication links automatically with local devices
US9916707B2 (en) 2013-08-19 2018-03-13 Arm Ip Limited Interacting with embedded devices within a user's environment
JP6264815B2 (ja) 2013-09-30 2018-01-24 ブラザー工業株式会社 通信装置
JP6402494B2 (ja) 2014-05-30 2018-10-10 ブラザー工業株式会社 機能実行システム、機能実行装置、及び、通信端末
KR102272243B1 (ko) * 2014-09-18 2021-07-06 삼성전자주식회사 카드 리더기 및 그것의 동작 방법
US9723431B2 (en) * 2014-12-18 2017-08-01 Intel Corporation Close proximity transport configuration
WO2018022101A1 (en) * 2016-07-29 2018-02-01 Hewlett-Packard Development Company, L.P. Wireless charging

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3231394B2 (ja) * 1992-04-01 2001-11-19 株式会社リコー モデム
JPH0715525A (ja) * 1993-06-28 1995-01-17 Ricoh Co Ltd マルチメディア通信端末装置
US5473691A (en) * 1993-11-05 1995-12-05 Microsoft Corporation System and method for computer data transmission
CA2134620A1 (en) * 1993-11-05 1995-05-06 Arul Menezes System and method for exchanging computer data processing capabilities
JP3522882B2 (ja) * 1995-03-22 2004-04-26 株式会社東芝 プロトコル切換方法
EP0987877B1 (en) * 1998-04-06 2005-09-28 Panasonic Communications Co., Ltd. Image communication device and image communication method
US6282407B1 (en) 1998-04-16 2001-08-28 Motorola, Inc. Active electrostatic transceiver and communicating system
ATE210858T1 (de) * 1998-07-21 2001-12-15 Koninkl Philips Electronics Nv System zur übertragung von daten von einem datenträger nach einer station mittels eines oder zum mindest eines anderen hilfsträgersignals
US6487241B1 (en) 1999-11-22 2002-11-26 Advanced Micro Devices, Inc. Method and apparatus employing cutback probe
KR100697002B1 (ko) * 2001-02-17 2007-03-20 삼성전자주식회사 톤 간격 조절을 포함한 초고속 디지털 가입자회선을 위한초기화 방법 및 이를 지원하는 시스템
JP2004215225A (ja) * 2002-12-17 2004-07-29 Sony Corp 通信システムおよび通信方法、並びにデータ処理装置
US7423989B2 (en) * 2004-02-13 2008-09-09 Broadcom Corporation Preamble formats for MIMO wireless communications
US8300666B2 (en) * 2004-10-07 2012-10-30 Cisco Technology, Inc. Inline power-based common mode communications in a wired data telecommunications network

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8537907B2 (en) 2010-02-23 2013-09-17 Samsung Electronics Co., Ltd Receiving system for use in near field communication and mode detection method therefore
US8068011B1 (en) 2010-08-27 2011-11-29 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
US8395486B2 (en) 2010-08-27 2013-03-12 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
US9858455B2 (en) 2010-08-27 2018-01-02 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
JP2016119705A (ja) * 2011-09-30 2016-06-30 クアルコム，インコーポレイテッド Ｎｆｃデータ交換構成パラメータ更新機構を改善するための方法および装置
JP2016010117A (ja) * 2014-06-26 2016-01-18 カシオ計算機株式会社 無線通信装置、無線通信システム、無線通信方法、及びプログラム

Also Published As

Publication number Publication date
US8515345B2 (en) 2013-08-20
US20130267175A1 (en) 2013-10-10
CN101112010A (zh) 2008-01-23
CN101112010B (zh) 2011-03-30
EP1845632B1 (en) 2014-08-20
EP1845632A1 (en) 2007-10-17
US8874033B2 (en) 2014-10-28
HK1111828A1 (en) 2008-08-15
JP4432787B2 (ja) 2010-03-17
WO2006080435A1 (ja) 2006-08-03
EP1845632A4 (en) 2012-12-12
US20080299907A1 (en) 2008-12-04

Similar Documents

Publication Publication Date Title
JP4432787B2 (ja) 通信装置、通信方法、およびプログラム
JP4367349B2 (ja) 通信装置、通信方法、およびプログラム
JP4720899B2 (ja) 通信装置、通信方法、プログラム、および通信システム
JP4378643B2 (ja) 通信システム、通信装置、通信方法、およびプログラム
JP4023308B2 (ja) 通信装置および通信方法
US9106273B2 (en) Communication system, communication method, and data processing apparatus
KR101997577B1 (ko) 근거리 무선 통신 리더를 구비한 모바일 단말 장치와 근거리 무선 통신 태그를 구비한 디바이스 및 그 ａｐ 연결 방법
RU2532618C2 (ru) Устройство передачи данных, способ передачи данных и система передачи данных
JP4706702B2 (ja) 通信システム、通信装置および通信方法、並びにプログラム
JP4682735B2 (ja) 通信システム、通信装置、通信方法、およびプログラム
JP4525715B2 (ja) 通信装置、通信方法、および通信システム
JP3695464B2 (ja) 近接通信方法および通信装置
JP5327558B2 (ja) 通信装置、通信方法、およびプログラム
JP5263314B2 (ja) 通信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070828

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090825

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091026

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20091201

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20091214

R151 Written notification of patent or utility model registration

Ref document number: 4432787

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130108

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250