JP6403122B2

JP6403122B2 - 通信デバイス及び通信システム

Info

Publication number: JP6403122B2
Application number: JP2015536436A
Authority: JP
Inventors: 高木　伸哉; 伸哉高木
Original assignee: Panasonic Intellectual Property Management Co Ltd
Current assignee: Panasonic Intellectual Property Management Co Ltd
Priority date: 2013-09-11
Filing date: 2014-08-19
Publication date: 2018-10-10
Anticipated expiration: 2034-08-19
Also published as: WO2015037187A1; JPWO2015037187A1; JP6516133B2; US20160198477A1; CN105453112A; US10085268B2; CN105453112B; JP2018152130A

Description

本開示は、複数のプロトコルを用いる通信デバイスに関する。

近年、非接触通信の技術を用いたＩＣ（集積回路）カードは、ＩＣ乗車券、パスポート、電子マネーなどさまざまなアプリケーションに利用されてきている。このうち、国内のＩＣ乗車券及び電子マネーの多くにはFeliCa（登録商標）と呼ばれる技術が用いられている。FeliCaの仕様は、通信プロトコルの他、カードに格納されるデータの読み書きを初めとするコマンド機能等も規定し、ＪＩＳＸ６３１９−４として規格化されている。

一方、パスポート、運転免許証、ｔａｓｐｏカード等、ＩＳＯ／ＩＥＣ１４４４３で規定されている通信プロトコルやＩＳＯ／ＩＥＣ７８１６で規定されるコマンド体系（「ＩＳＯプロトコル」と総称する）を使用する分野も多い。

特開２００７−１８３７８０号公報特開２０１１−２４０９１号公報

特開２００７−１８３７８０号公報は、全プロトコルで共通のフォーマットのサービス・ディレクトリ・データをカードに格納するシステムを記載する。特開２０１１−２４０９１号公報は、非接触通信において所定フォーマットのフレームを送受信するための通信プロトコルを用いて、それとは異なるフォーマットのフレームを送受信することを記載する。

しかしながら、あるプロトコルのカードと、それとは異なるプロトコルのリーダライタとは通信できない。そのためアプリケーション間の連携は限られる。

ある実施形態による通信デバイスは、第１通信プロトコルに準拠する信号を無線で送受信する第１送受信部と、前記第１送受信部によって受信された信号に含まれる第１フレームを処理する第１プロトコル処理部と、第２通信プロトコルに準拠する信号を無線で送受信する第２送受信部と、前記第２送受信部によって受信された信号に含まれる第２フレームを処理する第２プロトコル処理部と、前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部とを備える通信デバイスであって、前記第２送受信部は、前記デバイス識別情報を外部へ送信する。

ある実施形態による通信システムは、通信デバイスと、第１機器と、第２機器とを備える通信システムであって、前記第１機器は、第１通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、前記第２機器は、第２通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、前記通信デバイスは、前記第１通信プロトコルに準拠する信号を送受信する第１送受信部と、前記第１送受信部が受信した信号によって表される第１フレームを処理する第１プロトコル処理部と、前記第２通信プロトコルに準拠する信号を送受信する第２送受信部と、前記第２送受信部が受信した信号に含まれる第２フレームを処理するための第２プロトコル処理部と、前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部とを備え、前記第２送受信部は、前記デバイス識別情報を前記第２機器へ送信する。

上記構成により、通信デバイスは、異なる通信プロトコルで送信されたフレームに含まれるコマンドを処理できる。

図１は、例示的実施形態による通信システムの構成図である。図２は、例示的実施形態による通信デバイスの構成図である。図３は、例示的実施形態による通信デバイスの記憶部の構成図である。図４は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図５は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図６は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図７は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図８は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図９は、例示的実施形態による機器及び通信デバイスの間の通信フレームの構造図である。図１０は、例示的実施形態による通信デバイスのコマンド判別に関するフローである。図１１は、例示的実施形態による通信デバイスのステータスの処理に関するフローである。図１２は、例示的実施形態による通信システムの機器の構成図である。図１３は、例示的実施形態による機器及び通信デバイスの間のシーケンス図である。図１４は、例示的実施形態による機器及び通信デバイスの間のシーケンス図である。図１５は、例示的実施形態によるアンチコリジョン処理シーケンスで使用されるフレームの構造図である。図１６は、例示的実施形態によるアンチコリジョン処理シーケンスで使用されるフレームの構造図である。図１７は、例示的実施形態によるアンチコリジョン処理シーケンスで使用されるフレームの構造図である。図１８は、例示的実施形態によるＩＣカードのハードウェアのブロック図である。

図面を参照して、さまざまな実施形態を説明する。図面を通して、同一の参照符号は、同様の構成要素を指す。

用語の定義
「通信デバイス」という語は、FeliCa（登録商標）、MIFARE（登録商標）、ＮＦＣなどの非接触の近距離無線通信規格に準拠するＩＣカード（スマートカードとも呼ばれる）又はタグ、及びそれらと共に用いられるリーダライタを指す。非接触とは、カード内のＩＣチップからの端子が有線でリーダライタに接続されるのではないことを意味する。よってＩＣカードがリーダライタに接触するよう置かれても非接触通信と言える。特にリーダライタは、単に「機器」とも呼ばれる。

「ＮＦＣ」（near field communication）という語は、一般的には、13.56MHzの周波数を利用する通信距離10cm程度の近距離無線通信技術を指す。狭義のＮＦＣは、ISO／IEC 18092（NFCIP-1）という国際標準規格で定められた通信技術を指す。広義のＮＦＣは、NFCIP-1に加え、業界標準団体であるＮＦＣフォーラムが策定した実装規格であるＮＦＣフォーラム仕様も含む。

「通信プロトコル」（エアプロトコルとも呼ばれる）という語は、非接触の近距離通信（near field communication, NFC）のための仕様を指す。広義の通信プロトコルは、物理形状、無線仕様、衝突検出／回避、及び通信プロトコルを指す。FeliCaの通信プロトコルは、ＪＩＳＸ６３１９−４で規定される。MIFAREの通信プロトコルは、ＩＳＯ／ＩＥＣ１４４４３で規定される。

「フレーム」は、データビット及びオプション誤り検出ビットのシーケンスであって、フレームデリミタが最初と最後とに付される。

主に「部」という語で示される機能ブロック（処理部など）は、説明のために図示され、記述されている。単一の機能ブロックは、複数の要素を含んでもよい。逆に、複数の機能ブロックが単一の要素で実現されてもよい。加えて、機能ブロックは、ソフトウェア、ハードウェア、又はソフトウェア及びハードウェアの組み合わせで実現され得る。

「アプリケーション」という語は、ＩＣカードを利用するアプリケーションプログラムを指す。

システムの概略
図１は、ある実施形態による通信デバイスを使用した通信システム１００を示す。ＩＣカード１、リーダライタFeliCa−ＲＷ２、及びリーダライタＩＳＯ−ＲＷ３は、通信デバイスとして機能する。ＩＣカード１は、後述するように、例えばFeliCaアプリケーションファイル及びＩＳＯアプリケーションファイルを記憶する。

リーダライタFeliCa−ＲＷ２は、FeliCaで規定される通信プロトコル及びコマンド体系を使用してＩＣカード１にアクセスする。ＩＣカード１及びリーダライタFeliCa−ＲＷ２の間の通信は、例えば、ＪＩＳＸ６３１９−４で規定される。リーダライタＩＳＯ−ＲＷ３は、ＩＳＯで規定される通信プロトコル及びコマンド体系を使用してＩＣカード１にアクセスする。ＩＣカード１及びリーダライタＩＳＯ−ＲＷ３の間の通信は、例えば、ＩＳＯ／ＩＥＣ１４４４３で規定される。ここで「アクセス」とは、所望のアプリケーションの選択、相互認証、又はＩＣカード１に記憶されているファイルへのアクセス等、アプリケーションを実行するための様々な処理を意味する。

ＩＣカードの構造
図２は、ＩＣカード１の構造を示す。通信処理部４は、FeliCa−ＲＦ送受信部４１と、ＩＳＯ−ＲＦ送受信部４２とを含む。FeliCa−ＲＦ送受信部４１は、FeliCaプロトコル（ＪＩＳＸ６３１９−４）に準拠する信号（例えば13.56MHzのＲＦ（高周波）信号）を無線で送受信する。ＩＳＯ−ＲＦ送受信部４２は、ＩＳＯプロトコル（例えばＩＳＯ／ＩＥＣ１４４４３）に準拠する信号を無線で送受信する。

制御部５は、典型的には、ＣＰＵ（中央処理ユニット）と、記憶部６に記憶されたプログラムとによって実現される機能ブロックであり、ＩＣカード１が送受信するデータを処理する。制御部５は、FeliCaプロトコル処理部５２及びＩＳＯプロトコル処理部５４を含む。FeliCaプロトコル処理部５２は、FeliCa−ＲＦ送受信部４１によって受信された信号に含まれるフレームを処理する。ＩＳＯプロトコル処理部５４は、ＩＳＯ−ＲＦ送受信部４２によって受信された信号に含まれるフレームを処理する。

加えて制御部５は、通信プロトコル識別部５１、FeliCaコマンド処理部５３、アプリケーション選択器５５、ＩＳＯコマンド処理部５６、及びコマンドフォーマット変換部５７を含む。通信プロトコル識別部５１は、FeliCa−ＲＦ送受信部４１又はＩＳＯ−ＲＦ送受信部４２によって受信された信号の通信プロトコルを識別する。FeliCaコマンド処理部５３は、FeliCaプロトコル処理部５２によって処理されたフレームから取り出されたコマンドを処理する。

アプリケーション選択器５５は、アプリケーション選択コマンドに基づいて、複数のアプリケーションのうちの一つを選択する。このアプリケーション選択コマンドは、複数のアプリケーションのそれぞれに割り当てられたアプリケーション識別コードのうちの１つを指定する。ＩＳＯコマンド処理部５６は、ＩＳＯプロトコル処理部５４によって処理されたフレームから取り出されたコマンドを処理する。コマンドフォーマット変換部５７は、ＩＳＯプロトコル処理部５４によって出力されたフレームから取り出されたコマンドを変換して、FeliCaコマンド処理部５３に与える。

記憶部６は、一般にはメモリであり、より具体的にはＥＥＰＲＯＭ（電気的消去可能プログラム可能ＲＯＭ）、ＦｅＲＡＭ（強誘電体メモリ）等のような不揮発性メモリである。記憶部６は、アプリケーションで使用されるファイル、及びそのようなファイルを管理する情報を格納する。具体的には記憶部６は、FeliCaプロトコルのような通信プロトコルで使用されるデバイス識別情報を記憶する。ある実施形態によれば、ＩＳＯ−ＲＦ送受信部４２は、デバイス識別情報をリーダライタ２又は３へ送信する。リーダライタ２又は３は、デバイス識別情報をコマンド処理のために利用できる。

図３は、記憶部６の詳細を示す。図３に示されるＩＣカード１は、記憶部６の中に複数のアプリケーションを記憶する。そのような複数のアプリケーションは、例えばFeliCaアプリケーション及びＩＳＯアプリケーションである。記憶部６は、３種類以上のアプリケーションを記憶してもよい。

記憶部６は、カード内アプリケーション管理部６１、FeliCaアプリケーションを管理するFeliCaアプリケーション管理部６２、及びＩＳＯアプリケーションを管理するＩＳＯアプリケーション管理部６３を階層データ構造において記憶する。カード内アプリケーション管理部６１は、ＩＣカード１に搭載されているアプリケーション全体を管理する。カード内アプリケーション管理部６１は、カード内アプリケーションリスト６４を利用することによってアプリケーションを管理する。カード内アプリケーションリスト６４は、記憶部６が記憶するアプリケーションのリストであり、具体的には、アプリケーションごとにユニークに付与されているアプリケーション識別コードを記述する。FeliCaアプリケーション管理部６２及びＩＳＯアプリケーション管理部６３は、FeliCaアプリケーションファイル６５及びＩＳＯアプリケーションファイル６６をそれぞれ管理する。FeliCaアプリケーションファイル６５及びＩＳＯアプリケーションファイル６６は、それぞれのアプリケーションで使用されるデータを格納する。

システム１００において、リーダライタFeliCa−ＲＷ２及びＩＳＯ−ＲＷ３は、カード
１内のFeliCaアプリケーションファイル６５又はＩＳＯアプリケーションファイル６６にアクセスできる。本実施形態では、リーダライタFeliCa−ＲＷ２はFeliCaアプリケーションファイル６５だけにアクセスし、リーダライタＩＳＯ−ＲＷ３はFeliCaアプリケーションファイル６５及びＩＳＯアプリケーションファイル６６の両方にアクセスする。

フレームの構造
図４は、FeliCaアプリケーションファイル６５にアクセスするためにFeliCa−ＲＦ送受信部４１がFeliCa−ＲＷ２から受け取るフレーム（パケットとも呼ばれる）の構造を示す。図２及び図４を参照して、FeliCa−ＲＷ２からFeliCaアプリケーションファイル６５にアクセスする際の処理の流れを説明する。図４において、プリアンブル１０１及び同期コード１０２は、フレームの伝送における同期をとるための情報である。情報フィールド１０３は、フレームの本体であり、ペイロードとも呼ばれる。ＣＲＣ１０４は、情報フィールド１０３を対象とした誤り検出符号である。

FeliCa−ＲＦ送受信部４１は、このような構造のフレームを受け取ると、ＣＲＣ１０４により当該フレーム受信時に通信異常が発生していないかを検証する。通信異常が発生していない場合、FeliCa−ＲＦ送受信部４１は通信プロトコル識別部５１に対し、現在使用している通信プロトコルがFeliCaプロトコルである旨を通知するとともに、情報フィールド１０３をFeliCaプロトコル処理部５２に渡す。

情報フィールド１０３は、情報フィールド１０３の長さを示すＬＥＮ１０５と、コマンド名（読み出しや書き込み等）を示すＣ-Ｃｏｄ１０６と、当該ＩＣカード１をユニークに識別するためのコードＩＤｍ１０７と、コマンドデータであるＣ−Ｄａｔａ１０８とを含む。Ｃ−Ｄａｔａ１０８が例えば書き込みコマンドであるなら、書き込みデータ、その長さに関する情報等を含む。

FeliCaプロトコル処理部５２は、フレームの宛先が自分であるか否かをＩＤｍ１０７に基づいて判断し、自分宛のフレームである場合、Ｃ−Ｃｏｄ１０６及びＣ−Ｄａｔａ１０８を取り出し、それぞれコマンドコード１０９及びコマンドデータ１１０としてFeliCaコマンド処理部５３に渡す。これらはFeliCaのコマンド体系に準拠したものである。

FeliCaコマンド処理部５３はこれらの情報を受け取ると、コマンドコード１０９に応じた処理を行う。例えば、読み出しコマンドであれば、コマンドデータ１１０で指定されたデータをFeliCaアプリケーションファイル６５から読み出す。

図５は、ＩＣカード１からのレスポンスフレームの構造を示す。図２及び図５を参照して、受信したコマンドに対してＩＣカード１からFeliCa−ＲＷ２へレスポンスを返す際の処理の流れを説明する。FeliCaコマンド処理部５３は、通信プロトコル識別部５１に保持されている情報によって現在使用している通信プロトコルがFeliCaプロトコルであることを認識する。この場合、FeliCaコマンド処理部５３は、読み出したデータ及び処理結果をそれぞれレスポンスデータ１３１及びステータス１３０としてFeliCaプロトコル処理部５２に渡す。ここで処理結果とは、例えば、コマンド処理が正常に終了したか否かを表すデータである。

FeliCaプロトコル処理部５２は、受け取った上記情報をそれぞれＲ−Ｄａｔａ１２９及びＳｔｓ１２８に設定する。さらにコマンドコード１０６に対する規定値をレスポンスコード１２６に設定し、コマンド受信時に受け取ったＩＤｍ１０７と同じ値をＩＤｍ１２７に設定した上で、情報フィールド１２３をFeliCa−ＲＦ送受信部４１に渡す。なお、ＬＥＮ１２５には情報フィールド１２３の長さを設定する。

FeliCa−ＲＦ送受信部４１は、情報フィールド１２３に対するＣＲＣ１２４を算出して付加し、さらにプリアンブル１２１と同期コード１２２を付加したフレームをFeliCa−ＲＷ２に送信する。

上記は一つのコマンドに対する処理の流れを示したものであるが、このような処理を必要なコマンドの分だけ繰返し実行する。これにより、FeliCa−ＲＷ２がＩＣカード１に搭載されるFeliCaのアプリケーションを実行できる。本実施形態では、通信プロトコル識別部５１が現在使用されている通信プロトコルに関する情報を保持し、この情報によってFeliCaコマンド処理部がレスポンスの送り先を判別する点が従来のシステムとは異なる。

図６は、ＩＳＯ−ＲＦ送受信部４２がＩＳＯ−ＲＷ３から受け取るフレームの構造を示す。図２及び図６を参照して、ＩＳＯ−ＲＷ３からＩＳＯアプリケーションを実行する際の処理の流れを説明する。ＩＣカード１がＩＳＯ−ＲＷ３で処理できる複数のアプリケーションを搭載している場合、最初にアプリケーションの選択が必要になる。このため、まずＩＳＯ−ＲＷ３は、カード内アプリケーション管理部６１を選択する。具体的には、カード内アプリケーション管理部６１を選択するためのコマンドを、図６に示す構造のフレームに載せてＩＣカード１へ送信する。

図６に示される信号ＳＯＦ（start of frame）１４１及びＥＯＦ（end of frame）１４３は、フレームの先端及び終端をそれぞれ示す。ＩＳＯ−ＲＦ送受信部４２は、ＳＯＦ及びＥＯＦを有するフレームを受け取ると、このフレームはＩＳＯプロトコルに準拠する旨を通信プロトコル識別部５１に通知し、かつ、フレーム本体１４２をＩＳＯプロトコル処理部５４に渡す。

フレーム本体１４２は、フレームの種類を示すＰＣＢ１４４と、フレームの宛先が自分であるか否かを判断するためのＣＩＤ１４５と、コマンド情報を伝送するためのＩＮＦ１４６と、誤り検出符号ＣＲＣ１４７とを含む。ＩＳＯプロトコル処理部５４は、フレームの宛先が自分であるか否かをＣＩＤ１４５に基づいて判断し、自分宛のフレームである場合、ＣＲＣ１４７により当該フレーム受信時に通信異常が発生していないかを検証する。通信異常が発生していない場合、ＩＳＯプロトコル処理部５４は、ＩＮＦ１４６をアプリケーション選択器５５に渡す。

ＩＮＦ１４６は、コマンドの分類を示すＣＬＡ１４８と、コマンド名（読み出しや書き込み等）を示すＩＮＳ１４９と、コマンドパラメータＰＡＲ１５０と、後続するＣｍｄ−Ｄａｔａ１５２の長さを示すＬｃ１５１と、コマンドデータであるＣｍｄ−Ｄａｔａ１５２と、受信可能なレスポンスの最大長を示すＬｅ１５３とを含む。ＣＬＡ１４８は、ＩＮＳ１４９及びＰＡＲ１５０で示されるコードがＩＳＯで規定されるコマンド体系に準拠したものであるか、それとも当該アプリケーション独自のコードであるかを識別する。また、ＰＡＲ１５０及びＣｍｄ−Ｄａｔａ１５２には、例えば書き込みコマンドであれば、書き込みアドレス及び書き込みデータがそれぞれ設定される。なお、コマンドデータが存在しないコマンドの場合（例えば読み出しコマンド）、Ｌｃ１５１は付加されない。また、レスポンスでデータが送られないコマンドの場合（例えば書き込みコマンド）、Ｌｅ１５３は付加されない。

カード内アプリケーション管理部６１を選択するためのコマンドの場合、ＣＬＡ１４８にはＩＳＯのコマンド体系であることを示すコードが設定され、ＩＮＳ１４９には選択コマンドを示すコードが設定されている。また、ＰＡＲ１５０には選択対象がアプリケーションであることを示すコードが設定されている。ここで、カード内アプリケーション管理部６１は、カード内のアプリケーションを管理することを目的とした、広義のアプリケーションに含まれる。さらにＣｍｄ−Ｄａｔａ１５２には選択対象がカード内アプリケーション管理部６１であることを示すコードが設定されている。このコードは前述したアプリケーション識別コードであり、カード内アプリケーション管理部６１にもFeliCaアプリケーションやＩＳＯアプリケーションと同様にユニークなアプリケーション識別コードが付与されている。

アプリケーション選択器５５は、前述のアプリケーション選択コマンドを受け取ると、現在選択されているアプリケーションがカード内アプリケーション管理部６１であるという情報を保持した後、ＩＮＦ１４６をＩＳＯコマンド処理部５６に渡す。ＩＳＯコマンド処理部５６は選択対象がカード内アプリケーション管理部６１であるため、カード内アプリケーションリスト６４の情報を読み出す。カード内アプリケーションリスト６４は、ＩＣカード１に搭載されている全てのアプリケーション識別コードを含む。

図７は、ＩＣカード１からのレスポンスフレームの構造を示す。図２及び図７を参照して、受信したコマンドに対してＩＣカード１からＩＳＯ−ＲＷ３へレスポンスを返す際の処理の流れを説明する。カード内アプリケーション管理部６１に対する選択コマンドの場合、ＩＳＯコマンド処理部５６は、Ｒｓｐ−Ｄａｔａ１６８に前述の読み出しデータを設定し、ＳＷ１６９に処理結果を設定して、これらをアプリケーション選択器５５を介してＩＳＯプロトコル処理部５４に渡す。ここで読み出しデータは、ＩＣカード１に搭載されている全てのアプリケーションの識別コードであり得る。処理結果は、コマンド処理が正常に終了したか否か等を表すデータである。

ＩＳＯプロトコル処理部５４は、受け取った前述の情報をＩＮＦ１６６に設定し、コマンド受信時に受け取ったＣＩＤ１４５と同じ値をＣＩＤ１６５に設定する。さらにフレームの種類を示すＰＣＢ１６４を設定するとともに、これらの情報に対するＣＲＣ１６７を算出して付加し、ＩＳＯ−ＲＦ送受信部４２に渡す。ＩＳＯ−ＲＦ送受信部４２は受け取った情報をフレーム本体１６２に設定し、フレームの先端及び終端を示すＳＯＦ１６１、ＥＯＦ１６３を付加してＩＳＯ−ＲＷ３に送信する。

通信システム１で用いられ得るさまざまなアプリケーションを一義的に特定するように、アプリケーション識別コードは規定される。その結果、ＩＣカードを利用するさまざまなシステムにおいて、ＩＳＯ−ＲＷ３は、ＩＣカード１に搭載されているアプリケーションを特定できる。

ＩＳＯ−ＲＷ３は、受信したレスポンスによって、実行したいＩＳＯアプリケーションがＩＣカード１に搭載されていることを知る。ＩＳＯ−ＲＷ３は、今度はこのＩＳＯアプリケーションを選択するための選択コマンドをＩＣカード１に送信する。この選択コマンドは、コマンドデータ１５２で指定されるアプリケーション識別コードがＩＳＯアプリケーション管理部６３を示す点を除き、前述したカード内アプリケーション管理部６１を選択する際に用いられたフレームと同じ構造である。このコマンドを受信した際のＩＳＯ−ＲＦ送受信部４２及びＩＳＯプロトコル処理部５４の処理内容は前述した処理と同様である。

アプリケーション選択器５５は、受け取ったコマンドによって、選択対象がＩＳＯアプリケーション管理部６３であることを認識する。この場合、アプリケーション選択器５５は、現在選択されているアプリケーションがＩＳＯアプリケーション管理部６３であるという情報を保持した後、当該フレームのＩＮＦ１４６をＩＳＯコマンド処理部５６に渡す。ＩＳＯコマンド処理部５６は、ＩＳＯアプリケーション管理部６３から当該アプリケーションの属性情報を読み出し、それをレスポンスデータ１６８に設定する。アプリケーションの属性情報は、例えば、アクセス権の設定に関する情報やサポートしている機能に関する情報などである。当該コマンドに対するレスポンスをＩＳＯ−ＲＷ３に送信するまでの流れは、前述したカード内アプリケーション管理部６１の選択コマンドに対するレスポンスの場合と同様である。

次に、前述のように選択したＩＳＯアプリケーション管理部６３に対し、ＩＳＯ−ＲＷ３がアプリケーション処理を行う際の処理の流れを説明する。一例として、ＩＳＯアプリケーションファイル６６からデータを読み出す場合について述べる。ＩＳＯ−ＲＷ３からの読み出しコマンドを受信した際のＩＳＯ−ＲＦ送受信部４２及びＩＳＯプロトコル処理部５４の処理内容は前述した処理と同様である。

アプリケーション選択器５５は現在選択中のアプリケーションがＩＳＯアプリケーション管理部６３であるという情報を保持しているので、受け取ったコマンド（ＩＮＦ１４６）をＩＳＯコマンド処理部５６に渡す。ＩＳＯコマンド処理部５６はコマンドで指定された通り、ＩＳＯアプリケーションファイル６６からデータを読み出し、それをＲｓｐ−Ｄａｔａ１６８に設定する。当該コマンドに対するレスポンスをＩＳＯ−ＲＷ３に送信するまでの流れは、前述したカード内アプリケーション管理部６１の選択コマンドに対するレスポンスの場合と同様である。

上述したような一連の処理によって、ＩＳＯ−ＲＷ３はＩＣカード１に搭載されている複数のアプリケーションから所望のＩＳＯアプリケーションを選択し、そのアプリケーションのファイルにアクセスできる。本実施形態では、通信プロトコル識別部５１が現在使用されている通信プロトコルに関する情報を保持する点が従来のシステムとは異なる。

図８は、ＩＳＯ−ＲＦ送受信部４２がＩＳＯ−ＲＷ３から受け取るフレームの構造を示す。図２及び図８を参照して、ＩＳＯ−ＲＷ３からFeliCaアプリケーションファイル６５にアクセスする際の処理の流れを説明する。最初にＩＳＯ−ＲＷ３がカード内アプリケーション管理部６１を選択し、そのレスポンスによってＩＣカード１に搭載されているアプリケーションを知るまでの処理については前述した流れと同様である。

ＩＳＯ−ＲＷ３は実行したいFeliCaアプリケーションがＩＣカード１に搭載されていることを知ると、このFeliCaアプリケーションを選択するための選択コマンドをＩＣカード１に送信する。この選択コマンドはコマンドデータ１５２で指定されるアプリケーション識別コードがFeliCaアプリケーション管理部６２を示す点を除き、前述したカード内アプリケーション管理部６１を選択する際に用いられたフレームと同じ構造である。このコマンドを受信した際のＩＳＯ−ＲＦ送受信部４２及びＩＳＯプロトコル処理部５４の処理内容は前述した処理と同様である。

アプリケーション選択器５５は受け取ったコマンドによって、選択対象がFeliCaアプリケーション管理部６２であることを認識する。この場合、アプリケーション選択器５５は、現在選択されているアプリケーションがFeliCaアプリケーション管理部６２であるという情報を保持した後、FeliCaアプリケーション管理部６２から属性情報を読み出し、それをレスポンスデータ１６８に設定する。ここで属性情報は、例えば、FeliCaアプリケーションのバージョン番号を表すデータである。当該コマンドに対するレスポンスをＩＳＯ−ＲＷ３に送信するまでの流れは、前述したカード内アプリケーション管理部６１の選択コマンドに対するレスポンスの場合と同様である。

次に、前述のように選択したFeliCaアプリケーション管理部６２に対し、ＩＳＯ−ＲＷ３がアプリケーション処理を行う際の処理の流れを説明する。一例として、FeliCaアプリケーションファイル６５からデータを読み出す場合について述べる。ＩＳＯ−ＲＷ３からの読み出しコマンドを受信した際のＩＳＯ−ＲＦ送受信部４２及びＩＳＯプロトコル処理部５４の処理内容は前述した処理と同様である。

アプリケーション選択器５５は、現在選択中のアプリケーションがFeliCaアプリケーション管理部６２であるという情報を保持しているので、受け取ったコマンド（ＩＮＦ１４６）をコマンドフォーマット変換部５７に渡す。

コマンドフォーマット変換部５７は、図８に示すように、受け取ったＩＮＦ１４６からＩＮＳ１４９及びＣｍｄ−Ｄａｔａ１５２を取り出し、それぞれコマンドコード１８１及びコマンドデータ１８２としてFeliCaコマンド処理部５３に渡す。ここで、コマンドコード１８１及びコマンドデータ１８２は、FeliCa−ＲＷ２からFeliCaアプリケーションにアクセスする場合を説明した、図４のコマンドコード１０９及びコマンドデータ１１０と同じものが受信したフレーム上にマッピングされている。したがって、FeliCaコマンド処理部５３は、FeliCa−ＲＷからのアクセス時と同一の処理によってFeliCaアプリケーションファイル６５からデータを読み出すことができる。

図９は、ＩＣカード１からのレスポンスフレームの構造を示す。図２及び図９を参照して、読み出しコマンドに対するレスポンスを返す際の処理の流れを説明する。FeliCaコマンド処理部５３は、通信プロトコル識別部５１に保持されている情報によって現在使用している通信プロトコルがFeliCaプロトコルであることを認識する。この場合、FeliCaコマンド処理部５３は、読み出したデータ及び処理結果をレスポンスデータ１９１及びステータス１９２としてコマンドフォーマット変換部５７に渡す。処理結果は、例えば、コマンド処理が正常に終了したか否かを表すデータである。ここで、レスポンスデータ１９１及びステータス１９２は、図４のレスポンスデータ１３１及びステータス１３０と同じものである。コマンドフォーマット変換部５７は受け取ったレスポンスデータ１９１及びステータス１９２をそれぞれＲｓｐ−Ｄａｔａ１６８及びＳＷ１６９としてＩＳＯプロトコル処理部５４に渡す。これ以降のＩＳＯプロトコル処理部５４及びＩＳＯ−ＲＦ送受信部４２の処理は前述した処理と同様である。

上述したような一連の処理によって、ＩＳＯ−ＲＷ３はＩＣカード１に搭載されている複数のアプリケーションから所望のFeliCaアプリケーションを選択し、そのアプリケーションのファイルにアクセスできる。換言すれば、ＩＳＯ−ＲＷ３は、FeliCa−ＲＷ２によるFeliCaアプリケーションの処理と同様の処理を実行できる。このようなＩＳＯ−ＲＷ３によるFeliCaアプリケーションの実行は、従来のシステムにはない新規なものである。

コマンド処理のフロー
図１０は、ある実施形態における受信コマンドの判別手順を示したフローチャートを示す。このフローは、アプリケーション選択器５５による処理、ＩＳＯコマンド処理部５６又はFeliCaコマンド処理部５３による処理を含む。図１０を参照しながら、アプリケーション選択器５５におけるアプリケーション選択コマンドとアプリケーション処理コマンド（読み出しコマンド等）とを判別する手順について詳しく説明する。

まず、アプリケーション選択器５５は、受信したコマンドがアプリケーション選択コマンドか否かを判断する（ステップＳ１）。何らかのアプリケーション処理を実行中（具体的には、あるアプリケーション処理コマンドに対するレスポンスを送信した後で、当該アプリケーションに対する次のコマンドを待っている状態）であっても、アプリケーション選択コマンドを優先的に受け付けるため、別のアプリケーションを選択できる。

アプリケーション選択コマンドを受信した場合、そのコマンドで指定されるアプリケーション識別コードにより選択対象のアプリケーションを判別する（ステップＳ１０）。選択対象がカード内アプリケーション管理部６１である場合、アプリケーション選択器５５は現在選択中のアプリケーションがカード内アプリケーション管理部６１である旨の情報を内部に保持する（ステップＳ１１）。その後、ＩＳＯコマンド処理部５６がカード内アプリケーション管理部６１の選択処理（カード内アプリケーションリスト６４の読み出し等）を行う（ステップＳ１２）。選択対象がＩＳＯアプリケーション管理部６３である場合も同様の処理の流れ（ステップＳ１３、Ｓ１４）である。また、選択対象がFeliCaアプリケーション管理部６２である場合も、ステップＳ１６の実行主体がアプリケーション選択器５５である点を除き同様の処理が行われる（ステップＳ１５，Ｓ１６）。また、選択対象のアプリケーションが当該ＩＣカード１に搭載されていない場合はコマンド異常として処理する（ステップＳ１７）。

一方、受信したコマンドがアプリケーション選択コマンド以外の場合、アプリケーション選択器５５は既に選択状態にあるアプリケーションに対するコマンドであるとみなし、現在選択中のアプリケーションが何であるかを判別する（ステップＳ３０）。この判別には、ステップＳ１１、Ｓ１３、Ｓ１５のいずれかのステップで保持した情報を使用する。

現在選択中のアプリケーションがカード内アプリケーション管理部６１である場合、ＩＳＯコマンド処理部５６がカード内アプリケーション管理部６１に対するコマンド処理（例えば、空き領域サイズの取得やアプリケーションの追加等）を実行する（ステップＳ３１）。現在選択中のアプリケーションがＩＳＯアプリケーション管理部６３である場合も同様に、ＩＳＯコマンド処理部５６がＩＳＯアプリケーション管理部６３に対するコマンド処理（例えば、ＩＳＯアプリケーションファイル６６の読み出し等）を実行する（ステップＳ３２）。また、現在選択中のアプリケーションがFeliCaアプリケーション管理部６２である場合は、FeliCaコマンド処理部５３がFeliCaアプリケーション管理部６２に対するコマンド処理（例えば、FeliCaアプリケーションファイル６５の読み出し等）を実行する（ステップＳ３３）。また、アプリケーションが未選択である場合はコマンド異常として処理する（ステップＳ３４）。

ここで、アプリケーション選択コマンドかそれ以外かに関わらず、アプリケーション選択器５５が受け取るコマンドは全て図６又は図８のＣＬＡ１４８〜Ｌｅ１５３に示す構造をしている。アプリケーション選択コマンドとＩＳＯアプリケーション管理部６３に対するコマンド群はともにＩＳＯ体系に沿ったコマンドである。ＩＳＯ体系に沿ったコマンドの場合、ＩＮＳ１４９がコマンドごとに異なるため、アプリケーション選択コマンドとそれ以外のコマンド群とを確実に判別できる。一方、FeliCaアプリケーション管理部６２に対するコマンド群については、コマンドコード１８１がＩＳＯ体系とは別に独自に決められているので、アプリケーション選択コマンドのＩＮＳ１４９と重複する可能性がある。しかし、ＩＳＯ体系のコマンドに属するアプリケーション選択コマンドの場合、ＣＬＡ１４８がＩＳＯ体系のコマンドであることを示している。具体的には、１バイトの長さを持つＣＬＡ１４８の最上位ビットの値が’０’に設定されている。これに対し、FeliCaアプリケーション管理部６２に対するコマンド群の場合、ＣＬＡ１４８の最上位ビットに’１’を設定することにより独自コマンドであることを明示する。このようにして、アプリケーション選択コマンドとFeliCaアプリケーション管理部６２に対するコマンド群も確実に見分けることができるため、ステップＳ１の分岐は正しく処理できる。

なお、本実施形態では、ＩＣカード１に複数のアプリケーションが搭載されている場合で説明したが、FeliCaアプリケーションだけが搭載されている場合、このようなアプリケーション選択の処理は不要であり、ＩＳＯ−ＲＷ３でFeliCaアプリケーションを実行する場合でも、最初からFeliCaアプリケーション管理部６２に対するコマンドを送信できる。

ＩＳＯプロトコルは、それが扱うフレーム構造以外の点でもFeliCaプロトコルとは異なる。例えば、図５及び図９においてステータス１３０及びステータス１９２をそれぞれＳｔｓ１２８及びＳＷ１６９に設定する旨説明したが、FeliCaコマンドの中にはステータス１３０及びステータス１９２が存在しないものもある。このようなコマンドではコマンドが異常終了した場合、各プロトコルの規定に従い、FeliCaプロトコルでは無応答とし、ＩＳＯプロトコルでは何らかの処理結果ＳＷ１６９を返すことが必要になる。

これを実現するため、ステータス１３０及びステータス１９２が存在しないFeliCaコマンドのレスポンスだけを対象として、「正常終了」と「異常終了」を示す２種類のステータスコードを新たに規定する。これらのステータスコードの扱いについて図１１を参照しながら説明する。

図１１は、ある実施形態におけるステータスの処理方法を示したフローチャートである。このフローは、FeliCaプロトコル処理部５２による処理、FeliCa−ＲＦ送受信部４１による処理を含む。

まず、FeliCaプロトコル処理部５２は現在処理しているコマンドのコマンドコード１０９によって、そのレスポンスにＳｔｓ１２８を付加するコマンドか否かを判別する（ステップＳ６０）。Ｓｔｓ１２８を付加するコマンドの場合、ステータス１３０をそのままＳｔｓ１２８に設定し（ステップ６１）、情報フィールド１２３を組み立ててFeliCa−ＲＦ送受信部４１に渡す（ステップ６２）。FeliCa−ＲＦ送受信部４１はそのレスポンスをFeliCa−ＲＷ２へ送信した後、受信モードに移行して次のコマンドの受信待ちに入る（ステップ６３）。

一方、Ｓｔｓ１２８を付加するコマンドでない場合、FeliCaプロトコル処理部５２はステータス１３０の示している内容が「正常終了」か「異常終了」かを判別する（ステップＳ６４）。「正常終了」の場合、ステータス１３０を削除し、Ｓｔｓ１２８を付加しない情報フィールド１２３を組み立て、FeliCa−ＲＦ送受信部４１に渡す（ステップ６５）。FeliCa−ＲＦ送受信部４１はそのレスポンスをFeliCa−ＲＷ２へ送信した後、受信モードに移行して次のコマンドの受信待ちに入る（ステップ６３）。

「異常終了」の場合、FeliCaプロトコル処理部５２はFeliCa−ＲＦ送受信部４１に対し、コマンド異常である旨を通知する（ステップＳ６６）。FeliCa−ＲＦ送受信部４１はFeliCa−ＲＷ２へレスポンスを返さず、受信モードに移行して次のコマンドの受信待ちに入る（ステップ６７）。

一方、ＩＳＯプロトコル処理部５４の処理に関しては、どのようなFeliCaコマンドに対しても、ステータス１９２（「正常終了」又は「異常終了」を示すコードも含む）をＩＳＯ体系のコードに変換してＳＷ１６９に設定する。

FeliCaコマンドは独自コマンドであるため、ＳＷ１６９に設定されるコードも独自に決めたものでもよい。よってＩＳＯ体系のコードへの変換は必須ではない。しかし、ＩＳＯ−ＲＷ３がFeliCaアプリケーション及びＩＳＯアプリケーションの両方に対応している場合、ステータスコードの体系を合わせておくことにより処理の共通化を図ることができる効果を奏する。

このようにしてFeliCaプロトコル及びＩＳＯプロトコルの両方に応じた処理を実行できる。

リーダライタの構造
図１２は、FeliCa−ＲＷ２及びＩＳＯ−ＲＷ３の構造の概略を示す。FeliCa−ＲＷ２及びＩＳＯ−ＲＷ３の処理について、図１２及び図４〜図９を参照しながら簡単に説明する。

FeliCa−ＲＷ２がＩＣカード１のFeliCaアプリケーションを実行する場合、FeliCaアプリケーション処理部２０１は各コマンドに応じて図４のコマンドコード１０９及びコマンドデータ１１０を組み立て、FeliCaプロトコル処理部２０２に渡す。FeliCaプロトコル処理部２０２はそれらをそれぞれＣ−Ｃｏｄ１０６及びＣ−Ｄａｔａ１０８に設定するとともに、ＬＥＮ１０５とＩＤｍ１０７を付加してFeliCa−ＲＦ送受信部２０３に渡す。FeliCa−ＲＦ送受信部２０３はそれを情報フィールド１０３に設定し、プリアンブル１０１、同期コード１０２及びＣＲＣ１０４を付加してＩＣカード１に送信する。それに対するＩＣカード１からのレスポンスフレームの構造は図５に示す通りである。レスポンスの処理は前述と同様である。

ＩＳＯ−ＲＷ３がＩＣカード１のＩＳＯアプリケーションを実行する場合、ＩＳＯアプリケーション処理部２１１は各コマンドに応じて図６のＣＬＡ１４８〜Ｌｅ１５３を組み立て、ＩＳＯプロトコル処理部２１２に渡す。ＩＳＯプロトコル処理部２１２はそれらをＩＮＦ１４６に設定するとともにＰＣＢ１４４，ＣＩＤ１４５及びＣＲＣ１４７を付加してＩＳＯ−ＲＦ送受信部２１３に渡す。ＩＳＯ−ＲＦ送受信部２１３はそれをフレーム本体１４２に設定し、ＳＯＦ１４１とＥＯＦ１４３を付加してＩＣカード１に送信する。それに対するＩＣカード１からのレスポンスのフレーム構造は図７に示す通りである。レスポンスの処理については前述と同様である。

ＩＳＯ−ＲＷ３がＩＣカード１のFeliCaアプリケーションを実行する場合、FeliCaアプリケーション処理部２１４は各コマンドに応じて図８のコマンドコード１８１及びコマンドデータ１８２を組み立て、コマンドフォーマット変換部２１５に渡す。コマンドフォーマット変換部２１５はそれらをそれぞれＩＮＳ１４９及びＣｍｄ−Ｄａｔａ１５２に設定するとともに、ＣＬＡ１４８、ＰＡＲ１５０、Ｌｃ１５１及びＬｅ１５３を付加してＩＳＯプロトコル処理部２１２に渡す。

ここで、前述した通りＣＬＡの最上位ビットには独自コマンドを示す”１”を設定する。また、ＰＡＲ１５０は使用しないため２バイト分００ｈ（１６進表記）を設定する。なお、ＪＩＳＸ６３１９−４ではFeliCa仕様の将来拡張用として２バイトのコマンドコードを規定している。このような拡張コマンドを使用する場合はコマンドコード１８１の上位バイト、下位バイトをそれぞれＩＮＳ１４９及びＰＡＲの１バイト目にマッピングすればよい。

ＩＳＯプロトコル処理部２１２はそれらをＩＮＦ１４６に設定するとともにＰＣＢ１４４，ＣＩＤ１４５及びＣＲＣ１４７を付加してＩＳＯ−ＲＦ送受信部２１３に渡す。ＩＳＯ−ＲＦ送受信部２１３はそれをフレーム本体１４２に設定し、ＳＯＦ１４１とＥＯＦ１４３を付加してＩＣカード１に送信する。それに対するＩＣカード１からのレスポンスのフレーム構造は図９に示す通りである。レスポンスの処理については前述と同様である。

なお、前述の説明ではＩＳＯ−ＲＷ３がFeliCaアプリケーションとＩＳＯアプリケーションの両方に対応している場合を示したが、FeliCaアプリケーションだけに対応している場合、言うまでもなくＩＳＯアプリケーション処理部２１１は不要である。また、前述のＩＳＯ−ＲＷ３に関する記述では、ＩＣカード１側の処理と対比しやすいようFeliCaアプリケーション処理部２１４とコマンドフォーマット変換部２１５とを分けて説明したが、明確に機能を分離する必要性はなく、FeliCaアプリケーション処理部２１５がアプリケーション処理の中で図８のＣＬＡ１４８〜Ｌｅ１５３を組み立ててもよい。

ここで、図４のＩＤｍ１０７と、図８のＣＩＤ１４５は共に自分宛のフレームであるか否かを判断するためのもので、同じ役割を果たすものである。したがって、ＩＳＯ−ＲＷ３からFeliCaアプリケーションにアクセスする際のフレーム構造では図８及び図９に示す通りＣＩＤが使用され、ＩＤｍは使用されない。

しかし、ＩＤｍはＩＣカード１にユニークな情報である。よってＩＤｍは、通信制御より上位のレイヤ（例えばコマンド処理）で用いてもよい。例えばＩＤｍを鍵データ生成用に利用すれば、ＩＣカードごとに異なるので、相互認証用の鍵を多様化させることができる。これを実現するためには、ＩＣカード１のＩＤｍをＩＳＯ−ＲＷ３に通知すればよい。図１３及び図１４を参照してＩＤｍ及びＣＩＤをより詳細に説明する。

アンチコリジョン処理シーケンス
図１３は、FeliCaの通信プロトコルにおけるＩＤｍの役割を示すシーケンス図である。FeliCa−ＲＷ２及びＩＣカード１の間の通信は、アンチコリジョン処理シーケンス及びアプリケーション処理シーケンスによって実現される。アンチコリジョン処理シーケンスとはFeliCa−ＲＷ２が発生した磁界内に存在するＩＣカード１を認識するためのステップであり、磁界内にＩＣカードが複数枚存在する場合にその中から一枚だけを捕捉する処理も含んでいる。一方、アプリケーション処理シーケンスとは、アンチコリジョン処理シーケンスで捕捉したＩＣカード１に対するアプリケーション処理（データの読み出しや書き込み等）である。

アンチコリジョン処理シーケンスでは、FeliCa−ＲＷ２が送信したポーリングコマンドに対し、ＩＣカード１は８バイトのＩＤｍを返す。ＩＤｍは各ＩＣカードにユニークな値を持つ。磁界内に複数枚のＩＣカードが存在する場合はそれぞれのＩＣカードが異なるＩＤｍを送信する。アプリケーション処理シーケンスでは各コマンド及びレスポンスにＩＤｍを付与して送信することにより、ＩＣカード１は自分に対するコマンドであるか否かを判断でき、FeliCa−ＲＷ２は対象としているＩＣカード１からのレスポンスであるか否かを判断できる。

図１４は、ＩＳＯの通信プロトコルにおけるＣＩＤの役割を示すシーケンス図である。FeliCaの通信プロトコルと同様、ＩＳＯ−ＲＷ３及びＩＣカード１の間の通信は、アンチコリジョン処理シーケンス及びアプリケーション処理シーケンスによって実現される。

アンチコリジョン処理シーケンスでは、ＩＳＯ−ＲＷ３が送信したＲＥＱＢコマンドに対し、ＩＣカード１は４バイトのＰＵＰＩ（pseudo-unique PICC identifier）を返す。このＰＵＰＩはMIFAREのＵＩＤに相当し、ＩＤｍと同様、各ＩＣカードにユニークな値であるが、擬似的なものであって固定値ではない。

磁界内に複数枚のＩＣカードが存在する場合はそれぞれのＩＣカードが異なるＰＵＰＩを送信する。FeliCaの通信プロトコルでは以降のアプリケーション処理シーケンスにＩＤｍを付加するが、コマンド及びレスポンスごとに８バイトのＩＤｍを付加するのはオーバーヘッドとなる。アンチコリジョン処理シーケンスで複数のＩＣカードが捕捉され、アプリケーション処理シーケンスで複数のＩＣカードを同時に扱う場合を想定すれば、数枚のＩＣカードを扱う能力があれば十分である。この場合、複数のカードを識別するためには、コード長は、４ビットで足りる。したがってＩＳＯの通信プロトコルでは、ＩＳＯ−ＲＷ３はＲＥＱＢコマンドに続くＡＴＴＩＢコマンドにおいて、４バイトのＰＵＰＩと４ビットのＣＩＤとを対にしてＩＣカード１に送ることによりＰＵＰＩをＣＩＤに置き換え、以降のアプリケーション処理シーケンスでは、各コマンド及びレスポンスにＣＩＤを付与して送信することによって通信対象のＩＣカードを特定する。このようなＩＳＯの通信プロトコルにおいて、ＩＣカード１からＩＳＯ−ＲＷ３にＩＤｍを通知する方法には何通りかある。そのうちの一つはＲＥＱＢコマンドに対するレスポンスにＩＤｍを含めることである。

アンチコリジョン処理
図１５は、ＩＳＯの通信プロトコルにおけるＲＥＱＢコマンドに対するレスポンスのフレーム構造を示す。ＳＯＦ２３０及びＥＯＦ２３６はフレームの先端及び終端を示す信号であり、コード２３１は本フレームがＲＥＱＢコマンドに対するレスポンスであることを示す１バイトの固定値である。ＰＵＰＩ２３２は上述した４バイト長のデータである。アプリケーションデータ２３３はアプリケーション特有のデータ用に４バイト分確保しているが、ＩＳＯでは詳細は規定しておらず、アプリケーションに開放されている。また、３バイトのプロトコル情報２３４は通信プロトコルの制御に使用されるものであり、用途はＩＳＯで規定されている。ＣＲＣ２３５は誤り検出符号である。

このフレームでＩＤｍの伝送用に使用できるのはアプリケーションデータ２３３である。ＰＵＰＩ２３２及びアプリケーションデータ２３３の長さは、ＩＤｍの長さに等しい８バイトである。よってＩＤｍの前半４バイトをＰＵＰＩ２３２に割り当て、後半４バイトをアプリケーションデータ２３３に割り当てればよい。この方法であれば、ＩＤｍの伝送用に新たにコマンドを使用する必要もなく、伝送されるデータ量も増加しないため、オーバーヘッドを最小限に抑えることができる。

しかし、ＰＵＰＩをＩＣカードごとに異なる固定値にすると、ＰＵＰＩがユーザと関連付けられるので、例えばＰＵＰＩにより個人の行動が特定できる等のプライバシーの問題がある。この対策としてＰＵＰＩを乱数化する場合、FeliCaのプロトコルとしてＩＤｍはＩＣカードごとに異なる固定値であるため、ＩＤｍの前半４バイトをＰＵＰＩに割り当てることができず、この方法は使えない。別の方法としては、ＲＥＱＢコマンドに続くＡＴＴＲＩＢコマンドに対するレスポンスにＩＤｍを含めることが考えられる。

図１６は、ＩＳＯの通信プロトコルにおけるＡＴＴＲＩＢコマンドに対するレスポンスのフレーム構造を示す。ＳＯＦ２４０及びＥＯＦ２４４は、それぞれフレームの先端及び終端を示す信号であり、ＳＯＦ２４０に続く１バイトのデータ２４１の下位４ビットにＣＩＤが設定される。上位層応答２４２は０〜複数バイト長のオプションデータで、ＩＳＯでは詳細は規定しておらず、アプリケーションに開放されている。ＣＲＣ２４３は誤り検出符号である。

このフレームでＩＤｍの伝送用に使用できるのは上位層応答２４２である。任意の長さを割り当てることができるため、ＩＤｍ通知用として使用できる。本来はオプションデータであるため、通信されるデータ量が８バイト分、増える。しかしアプリケーション全体の処理時間から見れば、無視できる。前述の方法と同様、ＩＤｍの伝送用に新たにコマンドを使用する必要もない。

その他にも、ＩＤｍもFeliCaアプリケーションファイル６５等に格納し、通常の読み出しコマンドで読み出す方法や、ＩＤｍを読み出すための専用コマンドを設ける等の方法も考えられる。これらの方法は処理時間のオーバーヘッドの点でややデメリットがある。

FeliCa−ＲＷ２でFeliCaアプリケーションを実行する場合に比べ、ＩＳＯ−ＲＷ３でFeliCaアプリケーションを実行する場合、FeliCaアプリケーション管理部６２の選択が必要になる分、オーバーヘッドが増える。FeliCaアプリケーションは特にＩＣ乗車券として使用する場合、混在する改札機で処理できるようにするため、処理時間は重要な要件となる。

上記選択処理におけるオーバーヘッドを軽減するために、カード内アプリケーション管理部６１にアクセスせず、直接FeliCaアプリケーション管理部６２を選択すればよい。もし、FeliCaアプリケーションがＩＣカードに搭載されていない場合はこの選択コマンドに対しエラーレスポンスが返されることになる。これによりＩＳＯ−ＲＷ３はＩＣカードにFeliCaアプリケーションが搭載されているか否かを知ることができる。

カード内アプリケーション管理部６１にアクセスすることによってＩＣカードに搭載されているアプリケーションを知る方法は、リーダライタとＩＣカードとが互いに相手の情報を何も持たないところからスタートして相互運用性を確保する手段として汎用的に用いることができる。また、端末に表示されたアプリケーション一覧からカード所持者自身が実行したいアプリケーションを選択するといったシステムにも適している。しかし、改札機のように用途が限定されている場合、目的とするアプリケーションを直接選択するのも一つの有効な手段である。

更には、アンチコリジョン処理シーケンス直後は暗黙的にFeliCaアプリケーションを選択状態とする方法も考えられる。これにより、FeliCaアプリケーションの実行の際にはアプリケーション選択といったステップを踏むことなく、すぐにFeliCaアプリケーションの処理に入ることができる。それに加え、図１０を参照して説明した通り、FeliCaアプリケーションが選択されている時でもアプリケーション選択コマンドは優先的に受け付けられるため、改札機以外の端末ではＩＣカード１に搭載されている全アプリケーションを知った上でアプリケーションを選択するような通常の処理を実行できる。

この方法はＩＣ乗車券等のFeliCaアプリケーションだけに注目した場合であるが、より汎用的には、アンチコリジョン処理シーケンス直後に暗黙的に選択されるアプリケーションをケースバイケースで決定できるようにすることが望ましい。このための方法を図１７を参照しながら説明する。

図１７は、ＲＥＱＢコマンドのフレーム構造を示している。ＳＯＦ２５０及びＥＯＦ２５５は、それぞれフレームの先端及び終端を示す信号である。コード２５１は、本フレームがＲＥＱＢコマンドであることを示す１バイトの固定値である。ＡＦＩ２５２は、後述するアプリケーション分野識別（application field identification、ＡＦＩ）コードである。ＰＡＲＡＭ２５３は、アンチコリジョン処理用のパラメータである。ＣＲＣ２５４は、誤り検出符号である。

ＡＦＩ２５２は、例えば財布内にＩＣカードが複数枚入っている場合等、磁界内に存在するＩＣカードが複数枚存在する場合に、ＲＥＱＢコマンドに対するレスポンス同士が衝突する確率を低減させるよう応答するＩＣカードを制限するために用いるパラメータである。

具体的にはＩＳＯで規定されているＡＦＩ２５２を以下のように使う。１バイトのＡＦＩ２５２は二分割される。上位４ビットは、分野を示すコードを格納する。下位４ビットは、小分類を示すコードを格納する。ＩＣカード１は、カード発行時点で決められた、分野コード及び分類コードを持つ。ＲＥＱＢコマンドのＡＦＩ２５２の値が００ｈ（１６進表記）の場合は全てのＩＣカードがＲＥＱＢコマンドに対して応答を返す。ＡＦＩ２５２の値がＸ０ｈ（’Ｘ’は’１’〜’Ｆ’の値）の場合、自身の分野コードが’Ｘ’であるＩＣカードだけが応答を返す（自身の小分類コードは無視）。また、ＡＦＩ２５２の値が０Ｙｈ（’Ｙ’は’１’〜’Ｆ’の値）の場合、自身の小分類コードが’Ｙ’であるＩＣカードだけが応答を返す（自身の分野コードは無視）。そして、ＡＦＩ２５２の値がＸＹｈの場合、自身の分野コードが’Ｘ’で、かつ小分類コードが’Ｙ’あるＩＣカードだけが応答を返す。このようにして、ＲＥＱＢコマンドに対して応答するＩＣカードの数を減らし、アンチコリジョン処理を効率良く実行できる。

ここで、FeliCaアプリケーションに所定の分野コードかつ／又は小分類コードを割り当て、ＲＥＱＢコマンドのＡＦＩ２５２の値がその条件に合致する場合に応答を返すとともに、FeliCaアプリケーションを暗黙的に選択する。同様に、ＲＥＱＢコマンドのＡＦＩ２５２が別の所定の値である場合は、他の所定のアプリケーションを暗黙的に選択することもできる。この場合、ＩＣカード１には二種類の分野コードかつ／又は小分類コードが割り当てられる。ＲＥＱＢコマンドのＡＦＩ２５２が００ｈを含め、それ以外の値の場合はいずれのアプリケーションも暗黙的に選択しない。

また、次のような応用形も考えられる。例えば、ＲＥＱＢコマンドのＡＦＩ２５２の値がＸ１ｈの場合はＲＥＱＢコマンドに対して応答するとともにFeliCaアプリケーションを暗黙的に選択し、ＡＦＩ２５２の値がＸ２ｈの場合はＲＥＱＢコマンドに対して応答するとともに別のアプリケーションを暗黙的に選択する。そして、ＡＦＩ２５２の値がＸ０ｈの場合はＲＥＱＢコマンドに対して応答するが、いずれのアプリケーションも暗黙的に選択しない。このように分野コードかつ／又は小分類コードの値により、ＲＥＱＢコマンドに対する応答の有無と、アプリケーションの暗黙的選択の有無とを別々に決定することで、様々な応用が可能となる。

なお、図１５又は図１６を用いた説明の中で、ＲＥＱＢコマンド又はＡＴＴＲＩＢコマンドに対するレスポンスでＩＤｍを送信する方法について述べたが、ＲＥＱＢコマンドのＡＦＩ２５２が所定の分野コードかつ／又は小分類コードと一致した場合に限りＩＤｍを送信するようにしてもよい。

上述した実施形態では、制御部５は、ＩＣカード１内に搭載されているアプリケーション識別コードのリストをカード内アプリケーション管理部６１への選択コマンドに対するレスポンスとして返す。しかしこのような実施形態には限定されず、アプリケーション識別コードのリストを格納するためのファイルを記憶部６に記憶し、ＩＳＯ−ＲＷ３がアプリケーション識別コードのリストをこのファイルから別のコマンド（例えば、読出しコマンド）で読み出してもよい。

ＩＣカードのハードウェア
図１８は、さまざまな実施形態によるＩＣカードのハードウェアのブロック図である。ＩＣカード１は、ＩＣチップ３１０、及びアンテナ３２０を含む。

アンテナ３２０は、ＩＣチップ３１０に電気的に接続される。ＩＣカード１がFeliCa−ＲＷ２又はＩＳＯ−ＲＷ３の近傍にある時、アンテナ３２０は、FeliCa−ＲＷ２又はＩＳＯ−ＲＷ３と電磁的に結合される。通信処理部４は、アンテナ３２０が受けたFeliCa−ＲＷ２又はＩＳＯ−ＲＷ３からの電磁波から直流電圧を発生し、電源電圧としてＩＣチップ３１０に供給する。

ＩＣチップ３１０は、通信処理部４、制御部５、及び記憶部６を含む。記憶部６は、ＲＯＭ３１２、ＲＡＭ３１４、及びＥＥＰＲＯＭ３１６を含む。ＲＯＭ３１２は、変更する必要のないアプリケーションソフトウェアやプラットフォームとなるＯＳ（operating system）を記憶する。ＲＡＭ３１４は、主に制御部５の作業用メモリとしてデータを記憶する。不揮発性メモリであるＥＥＰＲＯＭ３１６は、ＩＣカード１の電源電圧が動作電圧より下がってもデータを保持する。よってＥＥＰＲＯＭ３１６は、アプリケーションソフトウェアによって用いられるユーザデータなどを記憶する。

上述のように、さまざまな実施形態による通信デバイスは、FeliCaプロトコルで送信されたフレームに含まれるコマンドと、ＩＳＯプロトコルで送信されたフレームに含まれるコマンドとを、処理できる。FeliCaプロトコルで使用されるデバイス識別情報と同じ役割を果たす情報がＩＳＯの通信プロトコルでも別途規定されているので、デバイス識別情報はＩＳＯの通信プロトコルでは使用する必要はない。しかし、デバイス識別情報はこの通信デバイスにユニークな情報であるため、例えば相互認証用の鍵を多様化させる（すなわち通信デバイスごとに異なる鍵データとする）といった目的のため、通信制御より上位のレイヤ（すなわちコマンド処理）で使用することも考えられる。さまざまな実施形態では、ＩＳＯプロトコルを使用する場合でもデバイス識別情報を通信デバイスから取得できるため、この情報をコマンド処理で使用できる。

また、ＩＳＯプロトコルのアプリケーションと同様、FeliCaのアプリケーションにもアプリケーション識別コードを付与することにより、ＩＳＯ規格で規定されているアプリケーション選択コマンドにより選択が可能となる。さらに、アンチコリジョン処理で指定されるアプリケーション分野識別コードが所定の条件に合致する場合に、所定のアプリケーションを暗黙的に選択する手段を設けることにより、FeliCaのアプリケーションを選択するためのオーバーヘッドをなくすことができ、高速処理が要求されるＩＣ乗車券としての利用も可能となる。

また、コマンド処理中に異常が発生した場合、ＩＳＯプロトコルでは異常を示すレスポンスを外部機器に返すのに対し、FeliCaプロトコルでは無応答とする等の通信プロトコルの違いがあるが、さまざまな実施形態では、同じ処理結果に対しても使用している通信プロトコルによって処理を分けることにより、この差異を吸収できる。

さまざまな実施形態によれば、一つの通信プロトコルだけサポートしている通常のリーダライタを用いてシステムを構築することを前提とした上で、前述したような異なるアプリケーション間の連携を実現するために、ＩＳＯプロトコルのフレーム及びコマンド体系を用いてFeliCaアプリケーションのファイルへのアクセスが可能となる。

さまざまな実施形態によれば、通信デバイスがFeliCaのアプリケーションとＩＳＯプロトコルのアプリケーションの双方を搭載し、ＩＳＯプロトコルのコマンド体系でＩＳＯプロトコルのアプリケーションだけではなく、FeliCaプロトコルのアプリケーションをも選択できる。さらに、混雑する改札での利用シーンにも対応できるよう、FeliCaのアプリケーションを短時間で選択できる。

さまざまな実施形態によれば、FeliCaプロトコル及びＩＳＯプロトコルの差異を吸収できる。

上述のように、改善されたＩＣカードは格段に多くのシーンで用いられ、その結果、魅力的なアプリケーションが新たに生み出されると期待される。例えば、現在では駅構内の券売機や改札機等でしか行うことができないＩＣ乗車券へのチャージや残高確認が様々な機器で行えるようになる。また、ＩＣ乗車券の利用履歴を別の機器で読み出すことが可能となるため、あるイベント会場に公共交通機関を利用した来場者に割引や優先的な座席の確保といった特典を与える等のサービスの導入が容易になってくる。あるいは、カードに記録されたユーザ支援情報（高齢者や障害者等の情報）を券売機や改札機で読み取ることにより、表示を大きくしたり、音声ガイダンスを付けたり、ゲートが閉じるまでの時間を長くしたりする等、きめ細かな人に優しいサービスを提供することも可能となる。

ある実施形態による通信デバイスは、アプリケーション選択器をさらに備え、前記記憶部は、複数のアプリケーションを記憶し、前記アプリケーション選択器は、前記複数のアプリケーションのそれぞれに割り当てられたアプリケーション識別コードを指定するアプリケーション選択コマンドによって、前記複数のアプリケーションのうちの一つを選択し、前記第２プロトコル処理部は、前記アプリケーション選択コマンドを処理する。

ある実施形態による通信デバイスは、アンチコリジョン処理時に外部から指定されるアプリケーション分野識別コードが所定の条件を満たす時には、予め決められたアプリケーションが選択される。

ある実施形態による通信デバイスは、前記コマンド処理部は、前記識別部に保持されている情報に従って、コマンドの処理結果を前記第１プロトコル処理部または前記第２プロトコル処理部のいずれかに出力する。

ある実施形態による通信デバイスは、前記処理結果が異常を示す時には、前記第１送受信部は前記処理結果を外部へ送信せず、前記第２送受信部は前記処理結果を外部へ送信する。

ある実施形態による通信デバイスは、前記第１通信プロトコルはＪＩＳＸ６３１９−４で規定され、前記第２通信プロトコルはＩＳＯ／ＩＥＣ１４４４３で規定される。

さまざまな実施形態を説明したが、本発明はこれら例示的な実施形態に限定されるものではなく、当業者であれば特許請求の範囲に規定される本発明の趣旨を逸脱しない範囲において様々な変更が可能である。

本開示の実施形態は、非接触通信技術を用いたデバイス又はシステムに適用可能である。

１ＩＣカード
２ FeliCa−ＲＷ
３ＩＳＯ−ＲＷ
４通信処理部
５制御部
６記憶部
５１通信プロトコル識別部
５２ FeliCaプロトコル処理部
５３ FeliCaコマンド処理部
５４ＩＳＯプロトコル処理部
５５アプリケーション選択器
５６ＩＳＯコマンド処理部
５７コマンドフォーマット変換部
６１カード内アプリケーション管理部
６２ FeliCaアプリケーション管理部
６３ＩＳＯアプリケーション管理部
６４カード内アプリケーションリスト
６５ FeliCaアプリケーションファイル
６６ＩＳＯアプリケーションファイル

Claims

第１通信プロトコルに準拠する信号を無線で送受信する第１送受信部と、
前記第１送受信部によって受信された信号に含まれる第１フレームを処理する第１プロトコル処理部と、
第２通信プロトコルに準拠する信号を無線で送受信する第２送受信部と、
前記第２送受信部によって受信された信号に含まれる第２フレームを処理する第２プロトコル処理部と、
前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、
前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、
前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、
前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部と、
アプリケーション選択器と、
を備える通信デバイスであって、
前記第２送受信部は、前記デバイス識別情報を外部へ送信し、
前記記憶部は、複数のアプリケーションを記憶し、
前記アプリケーション選択器は、前記複数のアプリケーションのそれぞれに割り当てられたアプリケーション識別コードを指定するアプリケーション選択コマンドによって、前記複数のアプリケーションのうちの一つを選択し、
前記第２プロトコル処理部は、前記アプリケーション選択コマンドを処理する
通信デバイス。
アンチコリジョン処理時に外部から指定されるアプリケーション分野識別コードが所定の条件を満たす時には、予め決められたアプリケーションが選択される
請求項１に記載の通信デバイス。
第１通信プロトコルに準拠する信号を無線で送受信する第１送受信部と、
前記第１送受信部によって受信された信号に含まれる第１フレームを処理する第１プロトコル処理部と、
第２通信プロトコルに準拠する信号を無線で送受信する第２送受信部と、
前記第２送受信部によって受信された信号に含まれる第２フレームを処理する第２プロトコル処理部と、
前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、
前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、
前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、
前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部と、
を備える通信デバイスであって、
前記第２送受信部は、前記デバイス識別情報を外部へ送信し、
前記コマンド処理部は、前記識別部に保持されている情報に従って、コマンドの処理結果を前記第１プロトコル処理部または前記第２プロトコル処理部のいずれかに出力し、
前記処理結果が異常を示す時には、前記第１送受信部は前記処理結果を外部へ送信せず、前記第２送受信部は前記処理結果を外部へ送信する
通信デバイス。
通信デバイスと、第１機器と、第２機器とを備える通信システムであって、
前記第１機器は、第１通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、
前記第２機器は、第２通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、
前記通信デバイスは、
前記第１通信プロトコルに準拠する信号を送受信する第１送受信部と、
前記第１送受信部が受信した信号によって表される第１フレームを処理する第１プロトコル処理部と、
前記第２通信プロトコルに準拠する信号を送受信する第２送受信部と、
前記第２送受信部が受信した信号に含まれる第２フレームを処理するための第２プロトコル処理部と、
前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、
前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、
前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、
前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部と、
アプリケーション選択器と、
を備え、
前記第２送受信部は、前記デバイス識別情報を前記第２機器へ送信し、
前記記憶部は、複数のアプリケーションを記憶し、
前記アプリケーション選択器は、前記複数のアプリケーションのそれぞれに割り当てられたアプリケーション識別コードを指定するアプリケーション選択コマンドによって、前記複数のアプリケーションのうちの一つを選択し、
前記第２機器は、前記アプリケーション選択コマンドを前記通信デバイスに送信する
通信システム。
アンチコリジョン処理時に前記第２機器によって指定されるアプリケーション分野識別コードが所定の条件を満たす時には、予め決められたアプリケーションが前記通信デバイスによって選択される
請求項４に記載の通信システム。
通信デバイスと、第１機器と、第２機器とを備える通信システムであって、
前記第１機器は、第１通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、
前記第２機器は、第２通信プロトコルに準拠する信号を前記通信デバイスと無線で送受信し、
前記通信デバイスは、
前記第１通信プロトコルに準拠する信号を送受信する第１送受信部と、
前記第１送受信部が受信した信号によって表される第１フレームを処理する第１プロトコル処理部と、
前記第２通信プロトコルに準拠する信号を送受信する第２送受信部と、
前記第２送受信部が受信した信号に含まれる第２フレームを処理するための第２プロトコル処理部と、
前記第１送受信部又は前記第２送受信部によって受信された信号の通信プロトコルを識別する識別部と、
前記第１フレームから取り出されたコマンドを処理するコマンド処理部と、
前記第２フレームから取り出されたコマンドを変換して前記コマンド処理部に与える変換部と、
前記第１通信プロトコルで使用されるデバイス識別情報を記憶する記憶部と、
を備え、
前記第２送受信部は、前記デバイス識別情報を前記第２機器へ送信し、
前記コマンド処理部は、前記識別部に保持されている情報に従って、コマンドの処理結果を前記第１プロトコル処理部または前記第２プロトコル処理部のいずれかに出力し、
前記処理結果が異常を示す時には、前記第１送受信部は前記処理結果を前記第１機器へ送信せず、前記第２送受信部は前記処理結果を前記第２機器へ送信する
通信システム。