(57)【要約】【課題】様々なプロトコルから、近接通信を利用する。【解決手段】NFC通信装置１乃至３は、データリンク層のLLC層のLLCパケットを、MAC層のMACパケットにカプセル化し、さらに、そのMACパケットを、物理層の物理層パケットにカプセル化して送受信するが、その際、LLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限する。本発明は、例えば、ICカードシステムなどに適用できる。【選択図】図１
2006211520.tif 000002
【特許請求の範囲】
【請求項１】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御手段を備え、
前記制御手段は、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とする通信装置。
【請求項２】
前記LLCパケットは、IP(Internet Protocol)パケットをカプセル化したものである
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記LLCパケットは、前記IPパケットに対して、少なくともヘッダを付加することにより、前記IPパケットをカプセル化したものであり、
前記LLCパケットのヘッダは、前記IPパケットの最大長を表すことができるサイズの情報を含む
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置の通信方法において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御ステップを備え、
前記制御ステップでは、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とする通信方法。
【請求項５】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置を制御するコンピュータに実行させるプログラムにおいて、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御ステップを備え、
前記制御ステップでは、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とするプログラム。
【請求項６】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御手段を備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とする通信装置。
【請求項７】
前記LLCパケットは、IP(Internet Protocol)パケットをカプセル化したものである
ことを特徴とする請求項６に記載の通信装置。
【請求項８】
前記LLCパケットは、前記IPパケットに対して、少なくともヘッダを付加することにより、前記IPパケットをカプセル化したものであり、
前記LLCパケットのヘッダは、前記IPパケットの最大長を表すことができるサイズの情報を含む
ことを特徴とする請求項７に記載の通信装置。
【請求項９】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置の通信方法において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御ステップを備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とする通信方法。
【請求項１０】
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置を制御するコンピュータに実行させるプログラムにおいて、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御ステップを備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法、およびプログラムに関し、例えば、OSI(Open System Interconnection)参照モデルの上位層の様々なプロトコルから、下位層のプロトコルの近接通信を利用することができるようにする通信装置、通信方法、およびプログラムに関する。
【背景技術】
【０００２】
近接通信を行うシステムとしては、例えば、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は、OSI参照モデルの第１層（最下位層）の物理層と、第２層のデータリンク層とを規定している。従って、理論上は、上位層である第３層のネットワーク層の様々なプロトコルから、NFCIP-1を利用することができる。
【０００７】
しかしながら、ネットワーク層の様々なプロトコルから、NFCIP-1を利用する具体的な方法（プロトコル）については、何ら提案されていなかった。
【０００８】
本発明は、このような状況に鑑みてなされたものであり、上位層の様々なプロトコルから、例えば、NFCIP-1等の近接通信を利用することができるようにするものである。
【課題を解決するための手段】
【０００９】
本発明の第１の通信装置は、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、アクティブモードまたはパッシブモードで送信する制御を行う制御手段を備え、制御手段は、LLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限することを特徴とする。
【００１０】
本発明の第１の通信方法は、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、アクティブモードまたはパッシブモードで送信する制御を行う制御ステップを備え、制御ステップでは、LLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限することを特徴とする。
【００１１】
本発明の第１のプログラムは、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、アクティブモードまたはパッシブモードで送信する制御を行う制御ステップを備え、制御ステップでは、LLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限することを特徴とする。
【００１２】
本発明の第２の通信装置は、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの物理層パケットを、アクティブモードまたはパッシブモードで受信する制御を行う制御手段を備え、LLCパケットの最大長は、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限されていることを特徴とする。
【００１３】
本発明の第２の通信方法は、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの物理層パケットを、アクティブモードまたはパッシブモードで受信する制御を行う制御ステップを備え、LLCパケットの最大長は、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限されていることを特徴とする。
【００１４】
本発明の第２のプログラムは、OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの物理層パケットを、アクティブモードまたはパッシブモードで受信する制御を行う制御ステップを備え、LLCパケットの最大長は、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限されていることを特徴とする。
【００１５】
本発明の第１の通信装置、通信方法、およびプログラムにおいては、OSI参照モデルのデータリンク層のLLC層のパケットであるLLCパケットがカプセル化され、データリンク層のMAC層のパケットであるMACパケットとされる。さらに、そのMACパケットがカプセル化されて、物理層のパケットである物理層パケットとされる。そして、その物理層パケットが、アクティブモードまたはパッシブモードで送信される。この場合において、LLCパケットの最大長が、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限される。
【００１６】
本発明の第２の通信装置、通信方法、およびプログラムにおいては、OSI参照モデルのデータリンク層のLLC層のパケットであるLLCパケットをカプセル化して、データリンク層のMAC層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの物理層パケットが、アクティブモードまたはパッシブモードで受信される。この場合において、LLCパケットの最大長は、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限されている。
【発明の効果】
【００１７】
本発明によれば、OSI参照モデルの上位層の様々なプロトコルから、例えば、NFCIP-1等の近接通信を利用することが可能となる。
【発明を実施するための最良の形態】
【００１８】
以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００１９】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００２０】
請求項１に記載の通信装置は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御手段（例えば、図４の制御部２１）を備え、
前記制御手段は、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とする。
【００２１】
請求項４に記載の通信方法は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）の通信方法において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御ステップ（例えば、図９のステップＳ６や、図１０のステップＳ２２、図１１のステップＳ３９）を備え、
前記制御ステップでは、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とする。
【００２２】
請求項５に記載のプログラムは、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）を制御するコンピュータ（例えば、図４のCPU２１Ａ）に実行させるプログラムにおいて、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを、前記アクティブモードまたはパッシブモードで送信する制御を行う制御ステップ（例えば、図９のステップＳ６や、図１０のステップＳ２２、図１１のステップＳ３９）を備え、
前記制御ステップでは、前記LLCパケットの最大長を、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限する
ことを特徴とする。
【００２３】
請求項６に記載の通信装置は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御手段（例えば、図４の制御部２１）を備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とする。
【００２４】
請求項９に記載の通信方法は、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）の通信方法において、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御ステップ（例えば、図９のステップＳ６や、図１０のステップＳ２２、図１１のステップＳ３９）を備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とする。
【００２５】
請求項１０に記載のプログラムは、
データを送受信する複数の装置のそれぞれにおいて、電磁波を出力し、その電磁波を変調することによりデータの送信を行う通信モードであるアクティブモードと、複数の装置のうちの１の装置において、電磁波を出力し、その電磁波を変調することによりデータの送信を行うとともに、前記複数の装置のうちの他の装置において、前記１の装置が出力する電磁波を負荷変調することによりデータの送信を行う通信モードであるパッシブモードとのうちのいずれかの通信モードで通信を行う通信装置（例えば、図４のNFC通信装置１）を制御するコンピュータ（例えば、図４のCPU２１Ａ）に実行させるプログラムにおいて、
OSI(Open System Interconnection)参照モデルのデータリンク層のLLC(Logical link control)層のパケットであるLLCパケットをカプセル化して、前記データリンク層のMAC(Media Access Control)層のパケットであるMACパケットとし、そのMACパケットをカプセル化して、物理層のパケットである物理層パケットとし、その物理層パケットを送信する装置からの前記物理層パケットを、前記アクティブモードまたはパッシブモードで受信する制御を行う制御ステップ（例えば、図９のステップＳ６や、図１０のステップＳ２２、図１１のステップＳ３９）を備え、
前記LLCパケットの最大長は、前記物理層パケットの最大長と、前記MAC層から前記LLC層に応答せずに連続して送信することができる前記MACパケットの最大数とから求められる長さ以下に制限されている
ことを特徴とする。
【００２６】
以下、図面を参照して、本発明の実施の形態について説明する。
【００２７】
図１は、本発明を適用した通信システム（システムとは、複数の装置が論理的に結合したもの物をいい、各構成の装置が同一筐体中にあるか否かは問わない）の一実施の形態の構成例を示している。
【００２８】
図１においては、通信システムは、３つの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とOSI(Open System Interconnection)参照モデルとの関係について説明する。
【０１５６】
図１２は、OSI参照モデルを示している。なお、図１２では、その左側に、OSI参照モデルを示してあり、右側に、現在世界的に普及しているインターネットのプロトコル階層を示してある。
【０１５７】
OSI参照モデルは、ネットワークプロトコルを構成する際に規範となる7階層の構造モデルであり、最下位層（第１層）から（上位層に向けて）、物理層（第１層）、データリンク層（第２層）、ネットワーク層（第３層）、トランスポート層（第４層）、セッション層（第５層）、プレゼンテーション層（第６層）、アプリケーション層（第７層）が規定されている。
【０１５８】
なお、データリンク層には、２つの副層が存在し、その２つの副層のうちの上位の副層がLLC(Logical link control)層であり、下位の副層がMAC(Media Access Control)層である。
【０１５９】
一方、インターネットのプロトコル階層としては、最下位層から、ネットワークインターフェース層、インターネット層、トランスポート層、アプリケーション層が規定されている。インターネットのネットワークインターフェース層は、OSI参照モデルの物理層およびデータリンク層に対応する。また、インターネットのインターネット層は、OSI参照モデルのネットワーク層に対応し、インターネットのトランスポート層は、OSI参照モデルのトランスポート層に対応する。さらに、インターネットのアプリケーション層は、OSI参照モデルのセッション層、プレゼンテーション層、およびアプリケーション層に対応する。
【０１６０】
NFCIP-1は、OSI参照モデルの物理層とデータリンク層とを規定している。但し、現在のNFCIP-1では、データリンク層については、その２つの副層であるLLC層とMAC層のうちのMAC層だけを規定している。
【０１６１】
ところで、NFC通信装置どうしは、図９のステップＳ６（図１０のステップＳ２２、図１１のステップＳ３９）のデータ交換において、コマンドDEP_REQとレスポンスDEP_RESのやりとりを行う。即ち、イニシエータが、コマンドDEP_REQを送信し、ターゲットが、そのコマンドDEP_REQを受信するとともに、ターゲットが、コマンドDEP_REQに対するレスポンスDEP_RESを送信し、イニシエータが、そのレスポンスDEP_RESを受信する。
【０１６２】
NFC通信装置であるイニシエータとターゲットは、コマンドDEP_REQやレスポンスDEP_RESを、物理層の、NFCIP-1に規定されているパケット（以下、適宜、物理層パケットという）によってやりとりする。
【０１６３】
物理層パケットには、物理層の上位層、つまりデータリンク層の下位の副層であるMAC層の、NFCIP-1に規定されているパケット（以下、適宜、MACパケットという）がカプセル化されており、さらに、MACパケットには、MAC層の上位層、つまりデータリンク層の上位の副層であるLLC層のパケット（以下、適宜、LLCパケットという）がカプセル化されている。
【０１６４】
図１３は、以上のようなカプセル化の関係、および、NFCIP-1で規定されているMACパケットと物理層パケットそれぞれのフォーマットを示している。
【０１６５】
図１３において、LLCパケットは、それに、CMD0フィールド、CMD1フィールド、PFBフィールド、DIDフィールド、およびNADフィールドが付加されることによりカプセル化され、MACパケットとされる。さらに、MACパケットは、それに、PAフィールド、SYNCフィールド、LENフィールド、およびE2フィールドが付加されることによりカプセル化され、物理層パケットとされる。
【０１６６】
ここで、NFC通信装置においては、LLCパケットをカプセル化してMACパケットとし、そのMACパケットをカプセル化して物理層パケットとし、その物理層パケットを、アクティブモードまたはパッシブモードで送信するが、これらの制御は、制御部２１によって行われる。さらに、NFC通信装置においては、上述のようにして送信されてくる物理層パケットをアクティブモードまたはパッシブモードで受信するが、この制御も、制御部２１によって行われる。
【０１６７】
NFCIP-1において、物理層パケットは、その先頭から、PAフィールド、SYNCフィールド、LENフィールド、トランスポートデータフィールド(Transport Data field)、E2フィールドが順次配置されて構成される。
【０１６８】
PAフィールドには、プリアンブル(Preambe)が配置され、SYNCフィールドには、所定の同期パターン(Synchronous pattern bytes)が配置される。LENフィールドには、トランスポートデータフィールドに配置されるデータのバイト数に、１を加えた値が配置される。なお、NFCIP-1では、LENフィールドに配置される値は、３乃至２５５の範囲とされている。従って、LENフィールドに２５５が配置される場合に、物理層パケットのサイズは、最大長となり、その場合にトランスポートデータフィールドに配置されるデータのサイズ、即ち、物理層パケットのトランスポートデータフィールドに配置することができるデータの最大長は、２５４（＝２５５−１）バイトである。
【０１６９】
トランスポートデータフィールドには、上位層のデータであるMACパケットが配置される。E2フィールドには、物理層パケットのエラー検出用のコードとしての、例えば、CRC(Cyclic Redundancy Checking)コードが配置される。
【０１７０】
ここで、上述したように、NFCIP-1では、106kbps，212kbps，424kbpsの伝送レートの中から、実際の通信に使用する伝送レートを選択することができるが、図１３に示した物理層パケットは、212kbpsまたは424kbpsの伝送レートでの通信に用いられる。106kbpsの伝送レートでの通信には、図１３のPAフィールドおよびSYNCフィールドに代えて、所定のスタートバイト(Start Bite)が配置されるSBフィールドが設けられた物理層パケットが用いられる。
【０１７１】
次に、NFCIP-1において、MACパケット（コマンドDEP_REQまたはレスポンスDEP_RESとしてのMACパケット）は、その先頭から、CMD0フィールド、CMD1フィールド、PFBフィールド、DIDフィールド、NADフィールド、n+1バイトのデータフィールドであるDB0,DB1,・・・,DBnフィールドが配置されて構成される。
【０１７２】
１バイトのCMD0フィールドと、１バイトのCMD1フィールドには、コマンドDEP_REQまたはレスポンスDEP_RESを表す値が配置される。
【０１７３】
１バイトのPFBフィールドには、データ転送の制御やエラーリカバリのためのPFB情報(Control information for transaction )が配置される。
【０１７４】
ここで、コマンドDEP_REQとレスポンスDEP_RESのやりとりによるデータ交換においては、アプリケーション等が要求するデータの送受信、ACK(AcKnowledge)またはNACK(Negative AcKnowledge)の送受信、NFC通信装置の管理用のデータの送受信の３種類のデータの送受信が行われる場合があり、それぞれの場合で、PFBフィールド（に配置されるPFB情報）のフォーマットは、異なる。
【０１７５】
１バイトのDIDフィールドには、MACパケットを送信するNFC通信装置を識別する、NFCIDとは別のDID(Device ID)情報が配置される。即ち、NFCIP-1において、NFCIDは、最長で１０バイトとされており、１０バイトのNFCIDは長いので、NFC通信装置を識別するための、いわば別名として、１バイトのDID情報を使用することができるようになっている。
【０１７６】
１バイトのNADフィールドには、論理的なコネクション(logical connections)において使用されるNAD(Node Address )情報が配置される。
【０１７７】
n+1バイトのデータフィールドであるDB0,DB1,・・・,DBnフィールドには、上位層のデータであるLLCパケットが配置される。
【０１７８】
次に、図１４は、コマンドDEP_REQとレスポンスDEP_RESのやりとりによるデータ交換において、アプリケーションが要求するデータの送受信を行う場合の、図１３のPFBフィールドに配置されるPFB情報を示している。
【０１７９】
アプリケーションが要求するデータの送受信を行う場合のMACパケットに配置されるPFB情報の上位３ビットbit7,bit6,bit5は、いずれも0とされ、さらに、最上位から４ビット目のビットbit4は、MACパケットに続きがあるかどうかを表す１ビットのMI(Multiple Information link for Data Exchange Protocol )フラグが配置される。
【０１８０】
ここで、MIフラグは、MACパケットに続きがある場合には1とされ、続きがない場合には0とされる。
【０１８１】
アプリケーションが要求するデータの送受信を行う場合のMACパケットに配置されるPFB情報の最上位から５ビット目のビットbit3と、６ビット目のビットbit2には、それぞれ、NADフラグとDIDフラグが配置される。NADフラグは、MACパケット（図１３）のNADフィールドの情報が有効である場合に1とされ、無効である場合に0とされる。DIDフラグは、MACパケット（図１３）のDIDフィールドの情報が有効である場合に1とされ、無効である場合に0とされる。
【０１８２】
アプリケーションが要求するデータの送受信を行う場合のMACパケットに配置されるPFB情報の下位２ビットbit0とbit1には、２ビットのPNI(Packet Number Information)が配置される。PNIは、初期値を0として、続きのMACパケットを送信する場合には、1ずつインクリメントされる。
【０１８３】
即ち、図１３で説明したように、NFC通信装置において、LLCパケットは、MACパケットにカプセル化され、さらに、MACパケットは、物理層パケットにカプセル化され、その物理層パケットが送信される。
【０１８４】
NFCIP-1では、LLCパケットを、MACパケットにカプセル化する場合に、LLCパケットの全体を、１つのMACパケットにカプセル化し、これにより、１つのLLCパケットを、１つのMACパケットによって送信する他、LLCパケットを複数のデータに区分し、その区分によって得られる複数のデータのそれぞれを、１つずつのMACパケットにカプセル化し、これにより、１つのLLCパケットを、複数のMACパケットによって送信することができるようになっている。
【０１８５】
１つのLLCパケットを、１つのMACパケットによって送信する場合、その１つのMACパケットのPNIは0とされる。また、１つのLLCパケットを、複数のMACパケットとしての、例えば、４つのMACパケットによって送信する場合、最初（１番目）のMACパケットのPNIは0とされ、２番目のMACパケットのPNIは1とされる。そして、３番目のMACパケットのPNIは2（２進数であれば10）とされ、３番目のMACパケットのPNIは3（２進数であれば11）とされる。
【０１８６】
例えば、イニシエータが、上述のように、１つのLLCパケットを、４つのMACパケットによって送信した場合、ターゲットでは、イニシエータからのMACパケットのPNIを参照することにより、元の１つのLLCパケット（４つのMACパケットに亘ってカプセル化されているLLCパケット）を再構成することができる。
【０１８７】
なお、PNIは、上述したように、２ビットであるから、１つのLLCパケットを分割して配置することができるMACパケットの最大数は、４（＝２2）個である。
【０１８８】
ここで、MAC層では、LLC層からの１つのLLCパケットを処理するたびに、その処理結果（例えば、LLCパケットが正常に送受信されたかなどの情報）を（LLC層に）知らせるために、LLC層に応答する。従って、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数は、１つのLLCパケットを分割して配置することができるMACパケットの最大数に等しく、上述したように、４個である。
【０１８９】
よって、LLC層がMACパケットに渡すLLCパケットは、多くとも４個のMACパケットに配置する（収める）ことができるLLCパケットである必要がある。
【０１９０】
次に、図１５は、コマンドDEP_REQとレスポンスDEP_RESのやりとりによるデータ交換において、ACK/NACKの送受信を行う場合の、図１３のPFBフィールドに配置されるPFB情報を示している。
【０１９１】
ACK/NACKの送受信を行う場合のMACパケットに配置されるPFB情報の上位３ビットbit7,bit6,bit5は、それぞれ0,1,0とされ、さらに、最上位から４ビット目のビットbit4は、ACK/NACKを表す１ビットのACK/NACKフラグが配置される。
【０１９２】
ここで、ACK/NACKフラグは、その値が1または0の場合に、それぞれ、ACKまたはNACKを表す。
【０１９３】
ACK/NACKの送受信を行う場合のMACパケットに配置されるPFB情報の最上位から５ビット目のビットbit3と、６ビット目のビットbit2には、図１４における場合と同様に、それぞれ、NADフラグと、DIDフラグが配置される。さらに、そのPFB情報の下位２ビットbit0とbit1には、やはり、図１４における場合と同様に、２ビットのPNIが配置される。
【０１９４】
なお、ACK/NACKとしてのMACパケットは、例えば、イニシエータが、あるデータを配置したMACパケットを、ターゲットに送信した場合に、そのターゲットが、イニシエータからのMACパケットの受信状況（受信結果）をイニシエータに知らせるために送信される。このため、ACK/NACKとしてのMACパケットのPNIは、そのACK/NACKによって受信状況を知らせようとするMACパケット（イニシエータが送信したMACパケット）のPNIと同一の値とされる。
【０１９５】
次に、図１６を参照して、イニシエータにおいて、１つのLLCパケットを複数のデータに分割し、複数のMACパケットでターゲットに送信する場合の、イニシエータとターゲットにおけるMAC層の処理について説明する。
【０１９６】
なお、図１６において、EDC(Error Deteciton Code)は、エラー検出用のコードを表す。
【０１９７】
また、図１６では、物理層の処理（MACパケットを物理層パケットにカプセル化する処理）の図示は、省略してある。
【０１９８】
さらに、図１６では、MACパケット（図１３）のNADフィールドとDIDフィールドの情報は、いずれも無効であるとし、従って、MACパケットのPFBフィールドに配置されるPFB情報の最上位から５ビット目のビットbit3と、６ビット目のビットbit2は、いずれも0であるとする。
【０１９９】
また、図１６では、イニシエータからターゲットに送信されるMACパケットは、すべて正常受信されるものとする。従って、ターゲットは、イニシエータからのMACパケットすべてに対して、ACKとしてのMACパケットを返す（送信する）ものとする。
【０２００】
図１６では、イニシエータにおいて、１つのLLCパケットが、３つのデータに分割され、３つのMACパケットによって、ターゲットに送信されている。
【０２０１】
即ち、イニシエータでは、LLC層からMAC層に、１のLLCパケットとしてのデータ"0123456789ABCDEF"が供給される。イニシエータのMAC層では、１のLLCパケットとしてのデータ"0123456789ABCDEF"が、３つのデータ"0123456"，"789ABC"，"DEF"に分割され、それぞれ、第１のMACパケット、第２のMACパケット、第３のMACパケットにカプセル化されて、ターゲットに送信される。
【０２０２】
ここで、第１乃至第３のMACパケットは、いずれも、アプリケーションが要求するデータを送（受）信するMACパケットであり、このため、PFBフィールド（図１３）に配置されるPFB情報のビットbit7,bit6,bit5は、図１４で説明したように、いずれも0となっている。
【０２０３】
また、第１と第２のMACパケットについては、それに続くMACパケット（第２と第３のMACパケット）が存在するため、PFB情報のビットbit4のMIフラグは、図１４で説明したように、1になっている。一方、第３のMACパケットについては、それに続くMACパケットは存在しないため、そのMIフラグは、図１４で説明したように、0になっている。
【０２０４】
さらに、第１のMACパケットは、３つの第１乃至第３のMACパケットの最初のMACパケットであるため、そのPFB情報のビットbit0とbit1のPNIは、初期値である0になっている。また、第２のMACパケットは、３つの第１乃至第３のMACパケットの２番目のMACパケットであるため、そのPFB情報のPNIは、第１のMACパケットのPNIを１だけインクリメントした1になっている。さらに、第３のMACパケットは、３つの第１乃至第３のMACパケットの３番目のMACパケットであるため、そのPFB情報のPNIは、第２のMACパケットのPNIを１だけインクリメントした2になっている。
【０２０５】
以上から、第１のMACパケットのPFB情報は、１６進数で10（２進数で00010000）となり、第２のMACパケットのPFB情報は、１６進数で11（２進数で00010001）となる。また、第３のMACパケットのPFB情報は、１６進数で02（２進数で00000010）となる。
【０２０６】
一方、ターゲットは、イニシエータからの第１のMACパケットを受信し、その第１のMACパケットを正常受信したことを表すACKとしてのMACパケットS(ACK)0を送信する。さらに、ターゲットは、イニシエータからの第２のMACパケットを受信し、その第２のMACパケットを正常受信したことを表すACKとしてのMACパケットS(ACK)1を送信する。
【０２０７】
ここで、MACパケットS(ACK)0およびS(ACK)1は、ACK/NACKを送（受）信するMACパケットであるから、PFBフィールド（図１３）に配置されるPFB情報のビットbit7,bit6,bit5は、図１５で説明したように、それぞれ、0,1,0となっている。
【０２０８】
また、MACパケットS(ACK)0に続けて送信すべきMACパケットは存在せず、MACパケットS(ACK)1に続けて送信すべきMACパケットも存在しないから、MACパケットS(ACK)0およびS(ACK)1のいずれのPFB情報のビットbit4のMIフラグも、図１４で説明したように、0になっている。
【０２０９】
さらに、MACパケットS(ACK)0は、第１のMACパケットに対するACKであるから、MACパケットS(ACK)0のPFB情報のビットbit0とbit1のPNIは、第１のMACパケットのPNIと同一の値である0となっている。また、MACパケットS(ACK)1は、第２のMACパケットに対するACKであるから、MACパケットS(ACK)1のPFB情報のPNIは、第２のMACパケットのPNIと同一の値である1となっている。
【０２１０】
以上から、MACパケットS(ACK)0のPFB情報は、１６進数で40（２進数で01000000）となり、MACパケットS(ACK)1のPFB情報は、１６進数で41（２進数で01000001）となる。
【０２１１】
ターゲットが送信したMACパケットS(ACK)0およびS(ACK)1は、イニシエータのMAC層で受信され、これにより、イニシエータのMAC層は、ターゲットのMAC層において第１および第２のMACパケットが正常受信されたことを認識する。
【０２１２】
その後、ターゲットは、イニシエータからの第３のMACパケットを受信する。第３のMACパケットのPFB情報のビットbit4のMIフラグは、上述したように0になっており、これにより、ターゲットは、第３のMACパケットに続くMACパケットが存在しないこと、つまり、第３のMACパケットが最後のMACパケットであることを認識する。この場合、ターゲットは、MAC層において、いままでに得られた第１のMACパケットにカプセル化されているデータ"0123456"、第２のMACパケットにカプセル化されているデータ"789ABC"、第３のMACパケットにカプセル化されているデータ"DEF"を、PNIを参照して、その順番で結合し、元のLLCパケットとしてのデータ"0123456789ABCDEF"を再構成して、MAC層からLLC層に供給する。
【０２１３】
その後、ターゲットのLLC層では、MAC層からのデータ"0123456789ABCDEF"に対するレスポンスとしてのLLCパケットAnswerが、MAC層に供給される。ターゲットのMAC層では、LLCパケットAnswerがMACパケットにカプセル化され、イニシエータに送信される。
【０２１４】
このLLCパケットAnswerがカプセル化されたMACパケットは、イニシエータからのLLCパケットとしてのデータ"0123456789ABCDEF"全体に対する、LLC層（あるいは、さらに上位の階層）からのレスポンスであり、従って、アプリケーションが要求するデータを送（受）信するMACパケットであるから、そのPFBフィールド（図１３）に配置されるPFB情報のビットbit7,bit6,bit5は、図１４で説明したように、いずれも0となっている。
【０２１５】
さらに、LLCパケットAnswerがカプセル化されたMACパケットに続けて送信すべきMACパケットは存在しないから、そのMACパケットのPFB情報のビットbit4のMIフラグは、図１４で説明したように、0になっている。
【０２１６】
また、LLCパケットAnswerがカプセル化されたMACパケットのPFB情報のPNI（図１４）は、ターゲットが、イニシエータから直前に受信した第３のMACパケットのPNIと同一の2になっている。
【０２１７】
以上から、LLCパケットAnswerがカプセル化されたMACパケットのPFB情報は、１６進数で02（２進数で00000010）となる。
【０２１８】
ターゲットが送信した、LLCパケットAnswerがカプセル化されたMACパケットは、イニシエータのMAC層で受信され、これにより、イニシエータのMAC層は、ターゲットのMAC層において第３のMACパケットが正常受信されたことを認識する。さらに、イニシエータでは、MAC層において、MACパケットのカプセル化をといて、その結果得られるLLCパケットAnswerを、LLC層に供給する。これにより、イニシエータのLLC層（あるいは、さらに上位の階層）は、ターゲットのLLC層においてLLCパケットとしてのデータ"0123456789ABCDEF"が正常受信されたことを認識する。
【０２１９】
次に、図４に示したNFC通信装置の制御部２１は、上述したNFCIP-1のMAC層および物理層の処理、即ち、例えば、LLCパケットをMACパケットにカプセル化する処理や、MACパケットを物理層パケットにカプセル化する処理等を行う他、LLC層の処理として、MAC層に供給するLLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限する。
【０２２０】
即ち、NFCIP-1のMAC層で使用されるPFB情報のPNIは、図１３乃至図１５で説明したように、２ビットであるから、１つのLLCパケットを分割して配置することができるMACパケットの最大数は、４（＝２2）個である。そして、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数は、上述したように、１つのLLCパケットを分割して配置することができるMACパケットの最大数に等しいから、やはり、４個である。
【０２２１】
一方、MACパケットは、物理層パケットにカプセル化されるので、MACパケットの最大長は、上述したように、物理層パケット（のトランスポートデータフィールド（図１３））の最大長によって制限され、本実施の形態では、上述したように、２５４バイトである。
【０２２２】
さらに、本実施の形態では、MACパケットの５バイトは、図１３に示したように、CMD0フィールド、CMD1フィールド、PFBフィールド、DIDフィールド、およびNADフィールドとして使用されるため、MACパケットにカプセル化することができるLLC層のデータの最大長は、２４９（＝２５４−５）バイトに制限される。
【０２２３】
以上のように、MACパケットにカプセル化することができるLLC層のデータの最大長は２４９バイトであり、さらに、MAC層において、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数が４個であるので、MAC層では、LLC層から供給される１つのLLCパケットのサイズが、９９６バイト（＝２４９バイト×４個）を越えると、そのLLCパケットを処理することが困難となる。
【０２２４】
そこで、制御部２１（図４）は、LLC層の処理として、MAC層に供給するLLCパケットの最大長を、物理層パケットの最大長（ひいては、物理層パケットのトランスポートデータフィールド（図１３）に配置することができる最大長のMACパケットにカプセル化することができるLLC層のデータの最大長）と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ、即ち、本実施の形態では、９９６バイト（＝２４９バイト×４個）に制限する。
【０２２５】
これにより、OSI参照モデル（図１２）のネットワーク層以上の上位層の様々なプロトコルから、データリンク層および物理層を規定するNFCIP-1による近接通信を利用することができる。
【０２２６】
例えば、インターネットには、TCP/IP(Transmission Control Protocol/Internet Protocol)が採用されているが、このTCP/IPから、NFCIP-1による近接通信を利用することができる。
【０２２７】
即ち、TCP/IPでは、TCPのデータが、IPパケットにカプセル化されて送受信されるが、このIPパケットの送受信を、NFCIP-1による近接通信によって行うことができる。
【０２２８】
ここで、図１７は、IPパケットのフォーマットを示している。
【０２２９】
IPパケットは、IPヘッダフィールドと、ペイロードフィールドとから構成される。
【０２３０】
IPパケットのIPヘッダフィールドには、IPのヘッダ情報が配置される。
【０２３１】
IPのヘッダ情報には、４ビットのバージョン、４ビットのヘッダ長、８ビットのサービスタイプ、１６ビットのパケット長、１６ビットの識別子、３ビットのフラグ、１３ビットのフラグメントオフセット、８ビットの生存時間、８ビットのプロトコル、１６ビットのヘッダチェックサム、３２ビットの送信元IPアドレス、３２ビットの送信先IPアドレス、可変長のオプション、必要なパディングが含まれる。
【０２３２】
バージョンは、 IPのバージョンを表す。図１７に示したIPヘッダフィールドは、IPv4のものであり、現在、IPv4からの移行が進行しているIPv6のIPヘッダフィールドの構造は、IPv4のIPヘッダフィールドとは異なる。このため、バージョンは、IPヘッダフィールドの構造を識別するために使用される。
【０２３３】
ヘッダ長は、IPヘッダフィールドのサイズを表し、サービスタイプは、IPのサービスの品質を表す。サービスタイプでは、優先度、低遅延要求、高スループット要求、高信頼性要求などの指定を行うことができる。
【０２３４】
パケット長は、IPパケットのサイズ（オクテット長）を表す。
【０２３５】
識別子、フラグ、およびフラグメントオフセットは、IPパケットのフラグメント化に利用される。即ち、IPよりも下位の階層のパケット（のペイロード）の最大長が、送信しようとするIPパケットの最大長より小さい場合があり、この場合、IPパケットを、下位の階層のパケットにカプセル化することができるサイズに分割する必要がある。識別子、フラグ、およびフラグメントオフセットは、このようなIPパケットの分割に利用される。
【０２３６】
具体的には、識別子は、１つのIPパケットを、複数のIPパケットに分割することができる場合に、分割前のIPパケットを識別するのに用いられる。フラグは、IPパケットを分割することができるか（分割が許可されているか）どうかや、分割後のIPパケットについて、後段に続くIPパケットが存在するかどうかなどを表す。フラグメントオフセットは、複数に分割されたIPパケットが、何番目のIPパケットであるかのシーケンス番号を表す。
【０２３７】
生存時間は、IPパケットがネットワーク上に存在することができる期間を表す。即ち、ネットワーク上のルータは、IPパケットを処理するたびに、そのIPパケットの生存時間を減らし、0になった時点で破棄する。
【０２３８】
プロトコルは、IPの上位のトランスポート層のプロトコル（IPパケットにカプセル化されたトランスポート層のプロトコル）が何であるかを表し、例えば、TCP/IPでは、TCPである。
【０２３９】
ヘッダチェックサムは、IPヘッダ情報のエラー検出用のコードである。
【０２４０】
送信元IPアドレスは、IPパケットの送信元のIPアドレスを表し、送信先IPアドレスは、IPパケットの送信先（宛先）のIPアドレスを表す。
【０２４１】
オプションは、テストやデバック時に使用され、パディングは、ヘッダフィールドのサイズを、32ビットの整数倍にするときに使用される。
【０２４２】
IPパケットのペイロードフィールドには、IPの上位の階層のデータが配置される。例えば、TCP/IPでは、ペイロードフィールドには、TCPのデータ（パケット）が配置される。
【０２４３】
以上のようなIPパケットの送受信を、NFCIP-1による近接通信によって行う場合には、NFC通信装置の制御部２１（図４）は、LLC層において、IPパケットをカプセル化してLLCパケットを生成し、MAC層に供給する。
【０２４４】
ここで、図１８は、制御部２１がLLC層において生成するLLCパケットのフォーマットを示している。
【０２４５】
LLCパケットは、LLCヘッダフィールドと、ペイロードフィールドとから構成される。なお、制御部２１が、MAC層において図１８のLLCパケットをMACパケットにカプセル化する場合、図１８のLLCパケットは、図１３に示したMACパケットのデータフィールド（DB0,DB1,・・・,DBnフィールド）に配置される。
【０２４６】
LLCヘッダフィールドには、例えば、LLCパケットのサイズや、ペイロードフィールドに配置（カプセル化）されたデータの種類その他を表す４バイトの各種情報、LLCパケットの送信元のNFC通信装置の１０バイトのNFCID(Source NFCID)、LLCパケットの送信先（宛先）のNFC通信装置の１０バイトのNFCID(Destination NFCID)、０バイト以上のオプション(Option)などが配置される。
【０２４７】
ペイロードフィールドには、データリンク層（LLC層）の上位の階層のデータである、例えば、IPパケットが配置される。
【０２４８】
ここで、NFC通信装置の制御部２１（図４）は、データリンク層（LLC層）の上位の階層のデータ、即ち、例えば、IPパケットをカプセル化したLLCパケットのサイズが、９９６バイトを越える場合には、上述したように、LLCパケットのサイズを、９９６バイト以下に制限する。従って、LLCパケットの最大長は、９９６バイトである。
【０２４９】
また、図１８の実施の形態では、LLCヘッダフィールドのサイズは、少なくとも、２４（＝４＋１０＋１０）バイトであり、従って、LLCパケットのペイロードフィールドは、最大でも、９７２（＝９９６−２４）バイトである。
【０２５０】
以上から、LLCパケット（のペイロードフィールド）にカプセル化することができるIPパケットのサイズの最大値は、９７２バイトである。
【０２５１】
一方、IPパケットの最大長は、2kバイト（65536バイト）である。
【０２５２】
従って、IPパケットの送受信を、NFCIP-1による近接通信によって行う場合には、NFC通信装置の制御部２１（図４）は、LLC層において、IPパケットをLLCパケットにカプセル化し、MAC層に供給するが、そのIPパケットのサイズが、９７２バイトを越えるときには、LLCパケットのサイズは、MAC層で処理することができる９９６バイトを越えることになる。
【０２５３】
NFC通信装置の制御部２１（図４）は、IPパケットをカプセル化したLLCパケットのサイズが、９９６バイトを越える場合には、上述したように、LLCパケットのサイズを、９９６バイト以下に制限するが、この制限は、例えば、IPパケットを複数のデータに分割することによって行われる。即ち、制御部２１は、LLC層において、１つのIPパケットを複数のデータに分割し、各データをカプセル化することによって、サイズが９９６バイト以下の複数のLLCパケットを生成し、MAC層に供給する。
【０２５４】
ところで、例えば、イニシエータが、上述のようにして、LLC層において、１つのIPパケットを分割し、サイズが９９６バイト以下の複数のLLCパケットを生成して（、MACパケットにカプセル化し）、ターゲットに送信する場合には、ターゲットは、LLC層において、イニシエータからの複数のLLCパケットを、元の１つのIPパケットに再構成する必要がある。
【０２５５】
そこで、図１８のLLCヘッダフィールドの各種情報には、ターゲットにおいて、上述のように、複数のLLCパケットに亘ってイニシエータから送信されてくる、分割されたIPパケットを、元の１つのIPパケットに再構成するために必要な情報（以下、適宜、再構成情報という）を含めることができる。
【０２５６】
ここで、再構成情報としては、例えば、図１３乃至図１５で説明したPFB情報のMIフラグとPNIと同様の情報、即ち、LLCパケットに続きがあるかどうかを表す情報と、LLCパケットが何番目のLLCパケットであるのかを表す情報を採用することができる。
【０２５７】
以上のように、イニシエータ（の制御部２１（図４））では、LLCパケットをMACパケットにカプセル化し、さらに、そのMACパケットを物理層パケットにカプセル化し、その物理層パケットを、アクティブモードまたはパッシブモードで送信するが、その際、LLCパケットの最大長を、物理層パケットの最大長と、MAC層からLLC層に応答せずに連続して送信することができるMACパケットの最大数とから求められる長さ以下に制限する。一方、ターゲット（の制御部２１）では、そのように最大長が制限されたLLCパケットが最終的にカプセル化された物理層パケットが受信される。
【０２５８】
従って、ネットワーク層の様々なプロトコルから、NFCIP-1を利用することが可能となる。
【０２５９】
なお、LLCヘッダフィールド（図１８）に配置する情報は、上述した情報に限定されるものではない。即ち、LLCパケットに、例えば、IPパケットをカプセル化する場合には、LLCヘッダフィールドには、IPパケットのIPヘッダフィールドに配置されているヘッダ情報のうちの１６ビットのパケット長（IPパケットの最大長を表すことができるサイズ（１６ビット）の情報）、さらには、その他のヘッダ情報を配置することができる。さらに、LLCヘッダフィールドのサイズも、図１８に示したような２４バイトに限定されるものではない。また、LLCヘッダフィールドの構造も、図１８に示した構造に限定されるものではなく、例えば、図１７に示したIPヘッダフィールドと同様の構造とすることが可能である。
【０２６０】
また、LLCパケットにカプセル化するデータは、IPパケットに限定されるものではない。即ち、NFCIP-1による近接通信は、ネットワーク層のIP以外の様々なプロトコルからも利用することができる。
【０２６１】
さらに、物理層パケットやMACパケットのフォーマットは、上述したフォーマットに限定されるものではない。
【０２６２】
なお、本明細書において説明した処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行う必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
【図面の簡単な説明】
【０２６３】
【図１】本発明を適用した通信システムの一実施の形態の構成例を示す図である。
【図２】パッシブモードを説明する図である。
【図３】アクティブモードを説明する図である。
【図４】NFC通信装置１の構成例を示すブロック図である。
【図５】初期RFCA処理を説明するタイミングチャートである。
【図６】アクティブRFCA処理を説明するタイミングチャートである。
【図７】SDD処理を説明する図である。
【図８】コマンドとレスポンスの一覧を示す図である。
【図９】NFCIP-1にしたがった通信処理の概要を説明するフローチャートである。
【図１０】パッシブモードで行われる処理を説明するフローチャートである。
【図１１】アクティブモードで行われる処理を説明するフローチャートである。
【図１２】OSI参照モデルを示す図である。
【図１３】MACパケットと物理層パケットのフォーマット（構造）を示す図である。
【図１４】PFB情報のフォーマットを示す図である。
【図１５】PFB情報のフォーマットを示す図である。
【図１６】イニシエータとターゲットにおけるMAC層の処理を説明する図である。
【図１７】IPパケットのフォーマットを示す図である。
【図１８】LLCパケットのフォーマットを示す図である。
【符号の説明】
【０２６４】
１乃至３  NFC通信装置，  １１  アンテナ，  １２  受信部，  １３  復調部，  １４  デコード部，  １５  データ処理部，  １６  エンコード部，  １７  選択部，  １８  電磁波出力部，  １９  変調部，  ２０  負荷変調部，  ２１  制御部，  ２１Ａ  CPU，  ２１Ｂ  EEPROM，  ２２  電源部
【図１】
2006211520.tif 000003
【図２】
2006211520.tif 000004
【図３】
2006211520.tif 000005
【図４】
2006211520.tif 000006
【図５】
2006211520.tif 000007
【図６】
2006211520.tif 000008
【図７】
2006211520.tif 000009
【図８】
2006211520.tif 000010
【図９】
2006211520.tif 000011
【図１０】
2006211520.tif 000012
【図１１】
2006211520.tif 000013
【図１２】
2006211520.tif 000014
【図１３】
2006211520.tif 000015
【図１４】
2006211520.tif 000016
【図１５】
2006211520.tif 000017
【図１６】
2006211520.tif 000018
【図１７】
2006211520.tif 000019
【図１８】
2006211520.tif 000020