JP2017201544A - 通信装置 - Google Patents

Abstract

【課題】所望のターゲットを確実に選択することができるようにする。
【解決手段】少なくともP2P（Peer to Peer）のアプリケーションを含む複数のターゲットと、複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、外部装置との近接通信を行うフロントエンドとを備え、フロントエンドは、外部装置から、System Codeを含む第１のコマンドを受信する受信部と、第１のコマンドを複数のターゲットに送信する送信部と、P2Pのアプリケーションに関する確定ターゲットの優先度を管理する優先度管理部とを有する通信装置が提供される。本技術は、例えば、NFC規格に対応した通信装置に適用することができる。
【選択図】図３

Description

本技術は、通信装置に関し、特に、所望のターゲットを確実に選択することができるようにした通信装置に関する。

無線通信の規格として、NFC（Near Field Communication）が知られている。NFC規格に対応したNFCデバイスでは、端末内に複数の通信対象（以下、ターゲットという）が同時に存在する場合が想定される。

NFCデバイスとして、ターゲットとしての複数のセキュアエレメントと、それらのセキュアエレメントに共通に使用され、リーダなどの外部装置と近接通信するフロントエンドとを備え、フロントエンドが、起動時に、複数のセキュアエレメントに対して通信のための異なるタイムスロットを割り当てるものが既に提案されている（例えば、特許文献１参照）。

図１に示すように、NFCの無線通信を行う非接触無線チップ（CLF：Contactless Front End）（以下、フロントエンドともいう）と、リーダ（reader）が近接通信を行う場合、シングルレスポンスとマルチレスポンスの２つの方式がある。

シングルレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが１つのポーリングレスポンスを返すので、リーダは、そのポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、シングルレスポンス方式では、特別な回路を設けることなく実装できるというメリットがある反面、マルチレスポンス方式と比べてターゲットの正答率(「リーダに対して、リーダが望むターゲットからのレスポンスを応答できる確率」を意味する)が低くなってしまう。

一方、マルチレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが複数のポーリングレスポンスを返すので、リーダは、複数レスポンス受信に対応していれば、複数のポーリングレスポンスの中から選択された所望のポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、マルチレスポンス方式は、一度に複数のレスポンスを返信するための特別な回路をフロントエンドに設ける必要があって実装面が複雑になる反面、シングルレスポンス方式と比べてターゲットの正答率を高くすることができる。

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

ところで、図２に示すように、フロントエンドがマルチレスポンス方式の機能を有する場合であっても、例えば３つのポーリングレスポンスを返したいときに、２つのタイムスロットしかないと、スロット不足のため、一度にポーリングレスポンスを返信することができなくなる。このように、マルチレスポンス方式では、スロット数が多ければ、ポーリングスロットをすべて返信することが可能となるが、リーダが、TSN=0,1など、小さいTSN（Time Slot Number）によりポーリングしてきた場合に、スロット数が不足してしまい、すべてのポーリングレスポンスを返せなくなるときがある。また、アプリケーションプログラムによっては、電子マネーのアプリケーションプログラムのようにシングルレスポンスを期待するものや、リーダの実装制約により、マルチレスポンスを受信できないものも存在する。

また、マルチレスポンス方式を利用するためには、特別な回路をフロントエンドに設ける必要があるため、マルチレスポンス方式に対応してない既存のデバイスだと、特別な回路を実装する必要が出てくる。

さらに、リーダから送られるコマンドによっては、フロントエンドにて、どのターゲットのレスポンスを返信すればよいかを判別できない場合があり、その場合には、リーダが所望とするターゲットを選択できないことになる。

本技術はこのような状況に鑑みてなされたものであり、上記のリーダの動作仕様に対応し、かつ、フロントエンドに特別な回路を実装することなく、リーダが所望とするターゲットを確実に選択することができるようにするものである。

本技術の一側面の通信装置は、少なくともP2P（Peer to Peer）のアプリケーションを含む複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記外部装置から、System Codeを含む第１のコマンドを受信する受信部と、前記第１のコマンドを前記複数のターゲットに送信する送信部と、前記P2Pのアプリケーションに関する前記確定ターゲットの優先度を管理する優先度管理部とを有する通信装置である。

本技術の一側面の通信装置においては、少なくともP2P（Peer to Peer）のアプリケーションを含む複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドが設けられる。そして、前記フロントエンドでは、前記外部装置から、System Codeを含む第１のコマンドが受信され、前記第１のコマンドが前記複数のターゲットに送信され、前記P2Pのアプリケーションに関する前記確定ターゲットの優先度が管理される。

本技術の一側面によれば、所望のターゲットを確実に選択することができる。

近接通信の方式を説明する図である。 マルチレスポンス方式における応答条件の例を示す図である。 NFCデバイスの構成例を示す図である。 CLFの詳細な構成例を示す図である。 ルーティングのステートマシンの概要を示す図である。 ルーティングのステートマシンの状態遷移を示す図である。 ポーリングコマンドを受信した場合の処理プロセスを示す図である。 SENSF_REQコマンドの処理プロセスを示す図である。 SENSF_RESコマンドの処理プロセスを示す図である。 ポーリングコマンド以外のコマンドを受信した場合の処理プロセスを示す図である。 ニュートラル状態における受信パケットの処理プロセスを示す図である。 ニュートラル状態における受信パケットの処理プロセスを示す図である。 T3Tセレクト状態における受信パケットの処理プロセスを示す図である。 T3Tセレクト状態における受信パケットの処理プロセスを示す図である。 P2Pセレクト状態における受信パケットの処理プロセスを示す図である。 本技術を利用した具体的な運用例を示すシーケンス図である。 本技術を利用した具体的な運用例を示すシーケンス図である。 SENSF_RESコマンドのパケットにてNFCID2の格納位置を示す図である。 NFCID2の抽出及び一時的保持の処理を示すシーケンス図である。 NFCID2のリプレイス処理の概要を示す図である。 NFCID2のリプレイス処理を示すシーケンス図である。 コマンド対応処理を説明するフローチャートである。 ニュートラル状態における受信パケットの処理を説明するフローチャートである。 コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。

［NFCデバイスの構成例］
図３は、NFCデバイスの構成例を示す図である。

NFCデバイス１１は、例えば、携帯電話機、ICカード、携帯情報端末、又はパーソナルコンピュータなどの装置として構成される。NFCデバイス１１は、NFCリーダ１２等の外部装置と、例えばISM（Industry Science Medical）バンドの13.56MHzの周波数の搬送波を用いて、数10cm以内（接触している場合も含む）の距離で近接通信を行う。

NFCデバイス１１は、CLF３１、ESE３２、DH３３、及びUICC３４から構成される。CLF３１と、ターゲットとしてのESE３２、DH３３、及びUICC３４のそれぞれは、有線により接続され、相互に通信可能とされる。

CLF（Contactless Front End）３１は、NFCデバイス１１内に設けられたアンテナに接続され、NFCリーダ１２と近接通信を行う。CLF３１は、NFCリーダ１２から送信されてくるコマンドに応じて、NFCリーダ１２が所望とするターゲットを選択して、NFCリーダ１２との間で通信が行われるように制御する。

また、CLF３１は、メモリ３１Ａを内蔵しており、必要に応じて各種のデータを、メモリ３１Ａに記憶する。

ESE（Embedded Secure Element）３２は、ICチップのセキュリティを含めたコア部分となるセキュアエレメントであって、例えば、電子決済や電子乗車券、入退室管理のNFCアプリケーションにおけるセキュリティ機能を実現する。

DH（Device Host）３３は、NFCデバイス１１の各部の動作を制御する。また、DH３３は、P2Pアプリ４１又はT3Tアプリ４２を実行する。P2Pアプリ４１は、P2P（Peer to Peer）のアプリケーションプログラムである。また、T3Tアプリ４２は、NFC規格により規定されているT3T（Type 3 Tag）のエミュレーション用のアプリケーションプログラムである。P2Pアプリ４１及びT3Tアプリ４２は、それぞれ、１又は複数実行可能とされる。

UICC（Universal Integrated Circuit Card）３４は、例えば、SIM（Subscriber Identity Module）カードから構成される。UICC３４は、NFCアプリケーションプログラムを実行することで、例えば、電子決済機能を実現する。

このように、ESE３２、UICC３４、P2Pアプリ４１、及びT3Tアプリ４２は、NFCリーダ１２の通信対象となるターゲットであって、それぞれが所定の処理を行う。換言すれば、ターゲットには、ESE３２やUICC３４などのデバイスと、P2Pアプリ４１やT3Tアプリ４２などのアプリケーションプログラムが含まれることになる。ただし、ターゲットには、ESE３２又はUICC３４にて実行されるアプリケーションプログラムが含まれるようにしてもよい。

NFCデバイス１１は、以上のように構成される。

［CLFの詳細な構成例］
図４は、図３のCLF３１の詳細な構成例を示す図である。

CLF３１は、パケット受信処理部１０１、ルーティング状態管理部１０２、優先度管理部１０３、及び無線通信制御部１０４から構成される。

パケット受信処理部１０１は、NFCリーダ１２から送信される受信パケットに関する処理を行う。

ルーティング状態管理部１０２は、CLF３１にて行われるルーティングの状態遷移を管理する。ルーティング状態には、後述するニュートラル状態とセレクト状態がある。

優先度管理部１０３は、ポーリングコマンドに対するターゲットからの応答（レスポンス）の優先度を管理する。なお、優先度に関する情報は、メモリ３１Ａに保持され、必要に応じて適宜読み出される。

無線通信制御部１０４は、NFCリーダ１２との間で行われる近接通信を制御するための処理を行う。

CLF３１は、以上のように構成される。

［CLFによるルーティングの概要］
次に、CLF３１によるルーティングの概要について説明する。CLF３１にて行われるルーティングは、ルーティングのステートマシンと、各ステートにおける受信パケットの処理プロセスによって実現される。

［ルーティングのステートマシン］
図５に示すように、ステートマシンは、ニュートラル状態（NEUTRAL）と、セレクト状態（SELECTED）の２つの状態で構成される。ニュートラル状態は、ターゲットが確定していない状態を意味し、セレクト状態は、ターゲットが確定している状態を意味する。

ニュートラル状態では、NFCリーダ１２からの受信パケットの解析が行われ、当該解析結果に応じて、ターゲットを確定するための処理が行われる。ターゲットが確定すると、ルーティング状態は、ニュートラル状態からセレクト状態に遷移する。

セレクト状態では、受信パケットが、ニュートラル状態にて確定された確定ターゲットに自動的に振り分けられる。また、セレクト状態には、プロトコルに応じて、P2Pセレクト状態（P2P SELECTED）と、T3Tセレクト状態（T3T SELECTED）が存在する。P2Pセレクト状態は、P2Pアプリ４１が選択されている状態を意味する。T3Tセレクト状態は、P2Pアプリ４１以外のESE３２、UICC３４、又はT3Tアプリ４２等が選択されている状態を意味する。また、所定の解除条件が発生して確定ターゲットが解除されると、ルーティング状態は、セレクト状態からニュートラル状態に遷移する。

確定ターゲットは、NFCリーダ１２からの受信パケットに格納されたコマンドコードや受信パケットのプロトコルなどの入力情報に対する所定のチェック条件に基づいて、NFCデバイス１１内に存在するターゲットの中から、NFCリーダ１２との単一の通信対象として、CLF３１により決定されるものである。CLF３１は、確定ターゲットが解除されるか、又は確定ターゲットが変更されるまでは、受信パケットを、選択された確定ターゲットに振り分けることになる。

図６は、ルーティングのステートマシンの状態遷移を示す図である。

図６において、ニュートラル状態にてP2Pアプリ４１が確定ターゲットとして選択されると、ルーティング状態は、ニュートラル状態からP2Pセレクト状態に遷移する。また、ニュートラル状態にてT3Tアプリ４２等が確定ターゲットとして選択されると、ルーティング状態は、ニュートラル状態からT3Tセレクト状態に遷移する。また、SENSF_REQコマンドが受信された場合や、RF（Radio Frequency）信号がオフになった場合には、ルーティング状態は、ニュートラル状態に留まる。

P2Pセレクト状態にて、RF信号がオフになった場合、又はRLS_REQコマンド、DSL_REQコマンド、NFC-Aへの technology changeを伴うPSL_REQコマンド、若しくはRF_DEACTIVATE_CMDコマンドが受信された場合には、ルーティング状態は、P2Pセレクト状態からニュートラル状態に遷移する。また、P2Pセレクト状態にて、上記以外のコマンドが受信された場合には、ルーティング状態は、P2Pセレクト状態に留まる。なお、RLS_REQコマンド，DSL_REQコマンドは、P2P通信のトランザクションの終了を指示するためのコマンドである。PSL_REQコマンドは、P2P通信の通信状態の変更を指示するためのコマンドである。また、RF_DEACTIVATE_CMDコマンドは、所定の規格に準拠した終了を指示するためのコマンドである。

T3Tセレクト状態にて、RF_DEACTIVATE_CMDコマンドが受信された場合、又はSENSF_REQコマンドが各ターゲットにブロードキャスト送信された後に、その応答が返信された場合には、ルーティング状態は、T3Tセレクト状態からニュートラル状態に遷移する。また、T3Tセレクト状態にて、SENSF_REQコマンドに対する応答が返信されなかった場合やRF信号がオフになった場合などは、ルーティング状態は、T3Tセレクト状態に留まる。さらに、T3Tセレクト状態にて、有効なP2Pのコマンドを受信した場合、ルーティング状態は、T3Tセレクト状態からP2Pセレクト状態に遷移する。

このように、CLF３１は、ニュートラル状態、P2Pセレクト状態、又はT3Tセレクト状態のいずれかのルーティング状態に遷移し、その状態に応じた受信パケットの処理プロセスを行うことになる。

［受信パケットの処理プロセス］
パケット受信の処理プロセスは、ポーリングコマンドを受信した場合の処理プロセスと、ポーリングコマンド以外のコマンドを受信した場合の処理プロセスに分類される。

（ポーリングコマンドを受信した場合の処理プロセス）
図７は、ポーリングコマンドを受信した場合の処理プロセスを示す図である。

CLF３１は、NFCリーダ１２からSENSF_REQコマンドを受信した場合、当該コマンドを、複数のターゲットにブロードキャスト送信する。

すなわち、SENSF_REQコマンドを格納するパケットには、ターゲットを特定するための識別情報が含まれていないため、ターゲットを特定するためのプロセスに用いることはできない。従って、CLF３１は、ターゲットの対象となり得る候補を探索するためのポーリングコマンドとして、SENSF_REQコマンドを、ブロードキャスト送信する。換言すれば、NFCリーダ１２にとって、SENSF_REQコマンドは、確定ターゲットの候補を探索して、当該ターゲットに関する情報を取得するためのコマンドであると言える。

なお、ターゲットの識別情報としては、例えば、ターゲットを一意に識別可能なNFCID2が用いられる。

また、P2Pアプリ４１及びT3Tアプリ４２に対するSENSF_REQコマンドは、DH３３には送信されずに、CLF３１内で処理される。以下、このような、実際にはSENSF_REQコマンドが送信されないターゲットを、論理ターゲットと称する一方、例えば、ESE３２やUICC３４のように、SENSF_REQコマンドが実際に送られるターゲットを、物理ターゲットと称して区別する。ただし、論理ターゲットと、物理ターゲットを区別する必要がない場合には、単に、ターゲットと称する。本実施の形態において、SENSF_REQコマンドは、物理ターゲットに対してだけでなく、論理ターゲットにもブロードキャスト送信されるものとして説明する。

より具体的には、図８に示すように、CLF３１は、NFCリーダ１２からSENSF_REQコマンドを受信した場合、当該SENSF_REQコマンドを、論理ターゲットであるP2Pアプリ４１Ｌ及びT3Tアプリ４２Ｌと、物理ターゲットであるESE３２及びUICC３４にブロードキャスト送信する。

CLF３１からSENSF_REQコマンドが送信されると、図９に示すように、各ターゲットのそれぞれは、SENSF_REQコマンドに応じて、SENSF_RESコマンドを応答することになる。そして、CLF３１は、応答があったターゲットの中から、当該応答に対する優先度に従って、応答を返信する確定ターゲットの候補を選択する。CLF３１は、シングルレスポンス方式に従い、選択した確定ターゲットの候補からのSENSF_RESを、NFCリーダ１２に返信する。

例えば、CLF３１は、P2Pアプリ４１Ｌ、T3Tアプリ４２Ｌ、ESE３２、及びUICC３４から応答があった場合、P2Pアプリ４１（P2Pアプリ４１Ｌ）、ESE３２、UICC３４、T3Tアプリ４２（T3Tアプリ４２Ｌ）の順の優先度に従って、それらの応答のうち、最も高い優先度のP2Pアプリ４１の応答を選択し、NFCリーダ１２に返信する。

なお、CLF３１からのSENSF_REQコマンドに対しては、複数応答がある場合や応答が全くない場合もある。例えば、SENSF_RESコマンドの応答をしてきたターゲットが１つだけであった場合、CLF３１は、当該ターゲットからのSENSF_RESコマンドを、NFCリーダ１２に返信する。また、SENSF_RESコマンドの応答をしてきたターゲットが１つもなかった場合、CLF３１は、NFCリーダ１２に対する返信を行わないことになる。この場合、CLF３１は、現在のルーティングの状態を維持する。

また、SENSF_REQコマンドは、基本的にすべてのターゲットにブロードキャスト送信されるものであるが、ターゲットの状態などによっては、送信されない場合もある。

（ポーリングコマンド以外のコマンドを受信した場合の処理プロセス）
図１０は、ポーリングコマンド以外のコマンドを受信した場合の処理プロセスを示す図である。

CLF３１は、NFCリーダ１２からSENSF_REQ以外のコマンドを受信した場合、当該コマンドを、特定のターゲットに送信する。すなわち、SENSF_REQ以外のコマンドは、NFCリーダ１２が所望のターゲットを特定した上で、特定のターゲットに送信されるものであるため、当該コマンドを格納するパケットには、特定のターゲットの識別情報が含まれている。従って、CLF３１は、ターゲットの識別情報に応じて、P2Pアプリ４１、T3Tアプリ４２、ESE３２、又はUICC３４のいずれかを選択して、コマンドを送信する。

このように、CLF３１においては、ポーリングコマンドを受信した場合と、ポーリングコマンド以外のコマンドを受信した場合では、その処理プロセスが異なることになる。

［各ルーティング状態における受信パケットの処理プロセス］
次に、上記の各ルーティング状態における受信パケットの処理プロセスについて説明する。

（ニュートラル状態における受信パケットの処理プロセス）
図１１は、ニュートラル状態における受信パケットの処理プロセスの概要を示す図である。

ニュートラル状態における受信パケットの処理プロセスで行われるルーティングの方式には、コマンドコードルーティング、プロトコルルーティング、及びテクノロジールーティングの３種類がある。

コマンドコードルーティング（command code routing）は、NFCリーダ１２からのコマンドを常時監視して、特定のコマンドを受信した場合には、当該コマンドに対応付けられたターゲットに、受信パケットを送るルーティングの方式である。

プロトコルルーティング（protocol routing）は、受信パケットがどのプロトコルになるかを、プロトコルベースで判別し、当該判別結果に応じたターゲットに、受信パケットを送るルーティングの方式である。プロトコルルーティングでは、例えば、受信パケットのプロトコルが、P2Pのプロトコルであるのか、又はT3Tのプロトコルであるかなどが判別される。以下、P2Pのプロトコルの判別結果に応じたルーティングを、P2Pプロトコルルーティングと称し、T3Tのプロトコルの判別結果に応じたルーティングをT3Tプロトコルルーティングと称する。

テクノロジールーティング（technology routing）は、受信したパケットがどのプロトコルにも属さない場合に、あらかじめ特定されたターゲットに、受信パケットを送るルーティングの方式である。テクノロジールーティングでは、例えば、実装的にP2PやT3Tのプロトコルが無効になっていた場合に、NFC-Fのパケットは第１のターゲットに送り、NFC-Bのパケットは第２のターゲットに送るなどを、あらかじめ決めておくことで、受信パケットが、該当するターゲットに送られるようにすることができる。

図１１に示すように、NFCリーダ１２からSENSF_REQコマンドを受信した場合には、SENSF_REQコマンドが、各ターゲットにブロードキャスト送信される。一方、NFCリーダ１２からSENSF_REQ以外のコマンドを受信した場合には、まず、コマンドコードルーティングが行われ、確定ターゲットが選択された場合には、確定ターゲットに受信パケットが送られる。

コマンドコードルーティングにて確定ターゲットが選択されなかった場合、P2Pプロトコルルーティング及びT3Tプロトコルルーティングが行われる。それらのプロトコルルーティングによって、確定ターゲットが選択された場合には、確定ターゲットに受信パケットが送られる。

また、プロトコルルーティングにて確定ターゲットが選択されなかった場合、テクノロジールーティングが行われる。テクノロジールーティングにおいては、受信パケットの送信先が決まっているので、その送信先となるターゲットに受信パケットが送られる。

なお、コマンドコードルーティングは、特定の運用における特定の機能を実現するために行われるものであるため、運用によっては実装されない場合もある。その場合には、CLF３１は、SENSF_REQ以外のコマンドを受信したとき、コマンドコードルーティングを行わずに、プロトコルルーティングから開始する。そして、プロトコルルーティングにて確定ターゲットが選択されなかった場合、CLF３１は、テクノロジールーティングを行うことになる。

次に、図１２を参照して、ニュートラル状態における受信パケットの処理プロセスの詳細について説明する。図１２には、図１１に示した各ルーティングの詳細な処理の内容が図示されている。

コマンドコードルーティングでは、まず、受信パケットのコマンドコードのチェックが行われる（Ｓ１１）。Ｓ１１のチェック条件を満たしている場合には、受信パケットのNFCID2と、すべてのターゲットのNFCID2との比較が行われる（Ｓ１２）。Ｓ１２にてNFCID2が一致する場合には、所定のルーティングテーブルに、所定のターゲットが登録されているかのチェックが行われる（Ｓ１３）。そして、Ｓ１３のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。例えば、ルーティングテーブルにて、DH３３がT3Tのプロトコルルーティングのターゲットとして登録されている場合には、DH３３と通信可能となるので、T3Tアプリ４２が確定ターゲットに選択される。

上記のＳ１１，Ｓ１２，又はＳ１３のチェック条件を満たさない場合、コマンドコードルーティングは終了し、次に、P2Pプロトコルルーティングが行われる。

P2Pプロトコルルーティングでは、受信したコマンドが、P2Pのコマンドであるかのチェックが行われる（Ｓ２１）。Ｓ２１のチェック条件を満たしている場合には、所定のルーティングテーブルのチェックが行われる（Ｓ２２）。Ｓ２２のチェック条件を満たしている場合、P2Pのプロトコルとして応答可能なコマンドであるかなどのチェックがさらに行われる（Ｓ２３）。そして、Ｓ２３のチェック条件を満たしている場合には、P2Pアプリ４１が確定ターゲットに選択される。これにより、ルーティング状態は、ニュートラル状態からP2Pセレクト状態に遷移する。

また、上記のＳ２１のチェック条件を満たさない場合、P2Pプロトコルルーティングは終了し、次に、T3Tプロトコルルーティングが行われる。

ここで、SENSF_REQコマンドに対する応答（SENSF_RESコマンド）の優先度であるが、初期状態では、P2Pアプリ４１、ESE３２、UICC３４、T3Tアプリ４２の順に優先度が高くなっている。そのため、SENSF_REQコマンドに対し、P2Pアプリ４１を確定ターゲットの候補として選択してP2Pアプリ４１のSENSF_RESコマンドを応答した後で、P2Pアプリ４１に対する所定のコマンドが送られてこないと、トランザクションが不成立になってしまう。そこで、プロトコルルーティングにおいては、P2Pアプリ４１に対する所定のコマンドを受信できなかった時点で（Ｓ２１の「No」）、応答の優先度の変更を行い（Ｓ３１）、P2Pアプリ４１の優先度を下げる。

例えば、CLF３１は、ESE３２、UICC３４、T3Tアプリ４２、P2Pアプリ４１の順に優先度を変更する。これにより、CLF３１は、次に、SENSF_REQコマンドを受信し、ターゲットにブロードキャスト送信した場合、変更された優先度に従って、優先度の最も高いESE３２を確定ターゲットの候補として選択し、各ターゲットからのSENSF_RESコマンドのうち、ESE３２の応答を、NFCリーダ１２に返信することになる。

なお、当該優先度の変更は、後述するＳ３２のチェック条件を満たさない場合に、その後の処理として行ってもよい。

図１２の説明に戻り、T3Tプロトコルルーティングでは、受信パケットに格納されたNFCID2と、P2Pアプリ４１以外のターゲット、すなわち、T3Tアプリ４２、ESE３２、UICC３４のNFCID2との比較が行われる（Ｓ３２）。Ｓ３２にてNFCID2が一致する場合には、所定のルーティングテーブルに、所定のターゲットが登録されているかのチェックが行われる（Ｓ３３）。そして、Ｓ３３のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。これにより、ルーティング状態は、ニュートラル状態からT3Tセレクト状態に遷移する。

上記のＳ２２，Ｓ２３，Ｓ３２，Ｓ３３のチェック条件を満たさない場合、プロトコルルーティングは終了し、次に、テクノロジールーティングが行われる。

テクノロジールーティングでは、所定のルーティングテーブルのチェックが行われる（Ｓ４１）。Ｓ４１のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。これにより、ニュートラル状態からT3Tセレクト状態に遷移する。

一方、Ｓ４１のチェック条件を満たさない場合には、受信パケットは破棄され（Ｓ４２）、受信パケットの処理は終了する。

なお、SENSF_REQコマンドを受信した場合には、SENSF_REQプロセス処理によって、受信パケットに格納されたパラメータや所定のルーティングテーブルのチェックが行われる（Ｓ５１）。Ｓ５１のチェック条件を満たしている場合には、SENSF_REQコマンドは、各ターゲットにブロードキャスト送信される。一方、Ｓ５１のチェック条件を満たさない場合には、受信パケットは破棄される（Ｓ５２）。

このように、ニュートラル状態における受信パケットの処理プロセスでは、受信パケットの評価を行い、評価結果に応じて、確定ターゲットが選択される。また、確定ターゲットが選択されると、ルーティング状態は、ニュートラル状態からP2Pセレクト状態又はT3Tセレクト状態に遷移する。さらに、確定ターゲットの候補として選択したP2Pアプリ４１からの応答をNFCリーダ１２に返信したにもかかわらず、P2PプロトコルルーティングにてP2Pアプリ４１が確定ターゲットに選択されなかった場合には、応答の優先度の変更が行われ、P2Pアプリ４１の優先度が下げられる。

（T3Tセレクト状態における受信パケットの処理プロセス）
図１３は、T3Tセレクト状態における受信パケットの処理プロセスの概要を示す図である。

T3Tセレクト状態における受信パケットの処理プロセスで行われるルーティングの方式は、コマンドコードルーティング及びP2Pプロトコルルーティングとなる。

図１３に示すように、NFCリーダ１２からSENSF_REQコマンドを受信した場合には、SENSF_REQコマンドが、各ターゲットにブロードキャスト送信される。一方、NFCリーダ１２からSENSF_REQ以外のコマンドを受信した場合には、まず、コマンドコードルーティングが行われる。

また、コマンドコードルーティングにて確定ターゲットが選択されなかった場合、P2Pプロトコルルーティングが行われる。すなわち、前述した状態遷移図（図６）に示したように、ルーティング状態が、T3Tセレクト状態からP2Pセレクト状態に遷移する場合があるため、T3Tセレクト状態においても、P2Pプロトコルルーティングが行われる。P2Pプロトコルルーティングにおいて、P2Pアプリ４１が確定ターゲットに選択された場合、ルーティング状態は、T3Tセレクト状態からP2Pセレクト状態に遷移する。一方、P2Pアプリ４１が確定ターゲットに選択されなかった場合、確定ターゲットは、現在のターゲットのまま変動せず、さらに、ルーティング状態もT3Tセレクト状態から変動しないことになる。

なお、前述したように、コマンドコードルーティングが実装されない場合には、P2Pプロトコルルーティングのみが行われることになる。

次に、図１４を参照して、T3Tセレクト状態における受信パケットの処理プロセスの詳細について説明する。図１４には、図１３に示した各ルーティングの詳細な処理の内容が図示されている。

図１４において、コマンドコードルーティング及びP2Pプロトコルルーティングは、図１２と同様に行われるため、その説明は省略する。ただし、図１４のＳ２１，Ｓ２２，Ｓ２３のチェック条件を満たさない場合には、プロトコルルーティングは終了し、確定ターゲット及びルーティング状態は変動しないため、受信パケットは、現在のターゲットに送られることになる。なお、図１４の処理プロセスでは、前述した応答の優先度の変更は行われない。

また、SENSF_REQコマンドを受信した場合には、SENSF_REQプロセス処理が、図１２と同様に行われる。

このように、T3Tセレクト状態における受信パケットの処理プロセスでは、コマンドコードルーティング及びP2Pプロトコルルーティングのみが行われ、それらのルーティングの評価結果に応じて、確定ターゲットが選択される。

（P2Pセレクト状態における受信パケットの処理プロセス）
図１５は、P2Pセレクト状態における受信パケットの処理プロセスを示す図である。

図１５に示すように、P2Pセレクト状態における受信パケットの処理プロセスにおいては、CLF３１は、NFCリーダ１２からの受信パケットを、すべて、P2Pアプリ４１に送信する。

このように、P2Pセレクト状態における受信パケットの処理プロセスでは、受信パケットの評価は行われず、受信パケットは、常に確定ターゲットであるP2Pアプリ４１に送信される。

以上、受信パケットの処理プロセスについて説明した。

［具体的な運用例］
次に、図１６及び図１７のシーケンス図を参照して、本技術を利用した具体的な運用例について説明する。

図１６及び図１７においては、NFCリーダ１２からのコマンドに対する、CLF３１、ESE３２、UICC３４の動作が示されている。また、論理ターゲットであるP2Pアプリ４１Ｌ及びT3Tアプリ４２Ｌについては、CLF３１内で処理される。ここで、NFCリーダ１２の所望とするアプリケーションプログラムは、ESE３２に存在するものとする。

また、図中の右側に示される、「SENSF_RES Priority order」は、応答の優先度におけるターゲットの並び順の状態を示している。「Normal order」は、P2Pアプリ４１の優先度が最も高い状態の並び順を意味する。また、「P2P deprioritised」は、P2Pアプリ４１の優先度が下げられた状態の並び順を意味する。

「P2P_RSP_FLG」は、P2Pアプリ４１のSENSF_RESコマンドの応答時にセットされるフラグである。「P2P_RSP_FLG」は、P2Pアプリ４１以外のSENSF_RESコマンドの応答時、又はルーティング状態がニュートラル状態に戻ったとき、クリアされる。また、「Routing State」は、前述したルーティング状態を示すもので、ニュートラル状態、P2Pセレクト状態、又はT3Tセレクト状態のいずれかの状態となる。

図１６に示すように、NFCリーダ１２からSENSF_REQコマンドが送信されると、CLF３１は、SENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信する。ブロードキャスト送信されたSENSF_REQコマンドは、ESE３２及びUICC３４にそれぞれ受信され、その応答がCLF３１に返信される。また、CLF３１は、SENSF_REQコマンドに対する、P2Pアプリ４１Ｌ及びT3Tアプリ４２Ｌに関する処理を行う。

CLF３１は、初期状態ではP2Pアプリ４１の優先度が最も高いので、P2Pアプリ４１を確定ターゲットの候補として選択し、P2Pアプリ４１のNFCID2を含むSENSF_RESコマンドを、NFCリーダ１２に返信する。すると、NFCリーダ１２は、CLF３１からのSENSF_RESコマンドに応じて、P2Pアプリ４１のNFCID2を含むRequest System codeコマンドを送信する。CLF３１は、NFCリーダ１２からのRequest System codeコマンドを、ESE３２に送信するが、当該コマンドを誤ったターゲットに送信してしまったため、応答を得ることはできない。結果としてNFCリーダ１２も応答を得ることができず、この場合、トランザクションに失敗したことになる（図中の「FAIL」）。

すなわち、CLF３１において、ポーリングパラメータのSC（System Code）が“FFFF”となるSENSF_REQコマンドに対して、P2Pアプリ４１のSENSF_RESコマンドを応答した後で、ATR_REQ，Ad-hoc通信用コマンドセット，Get Container Issue Information以外のコマンドを受信すると、当該トランザクションは不成立となる。ここで、ATR_REQコマンドは、NFC規格により規定されているP2P通信で用いられるコマンドである。また、Ad-hoc通信用コマンドセットは、所定の規格に準拠したアドホック通信用のコマンドである。Get Container Issue Informationは、所定の規格に準拠したICチップに関連する情報を取得するためのコマンドである。

この場合、CLF３１は、ターゲットからの応答の優先度を、ESE３２、UICC３４、T3Tアプリ４２、P2Pアプリ４１の順に変更して、P2Pアプリ４１の優先度を下げる。これにより、P2Pアプリ４１以外の次のトランザクションが成立されるようにする。なお、CLF３１は、例えば5〜10秒間など、所定の期間のみ優先度の変更を行い、当該期間経過後に優先度を元に戻して、P2Pアプリ４１の優先度が最も高くなるようにする。具体的には、図１６の「Timer start」から、図１７の「Timer expire」までの期間が、優先度を変更する期間となる。

一方、NFCリーダ１２は、トランザクションが失敗した場合、RF信号を一度オフしてから、再度オンする。そして、NFCリーダ１２は、再度、SENSF_REQコマンドを送信する。CLF３１は、NFCリーダ１２からのSENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信する。ESE３２及びUICC３４は、SENSF_RESコマンドをそれぞれ返信する。

CLF３１は、応答の優先度が変更されESE３２の優先度が最も高いので、ESE３２を確定ターゲットの候補として選択し、ESE３２のNFCID2を含むSENSF_RESコマンドを、NFCリーダ１２に返信する。すると、NFCリーダ１２から、ESE３２のNFCID2を含むRequest System codeコマンドが送信されるので、CLF３１は、当該コマンドをESE３２に送信する。このとき、CLF３１は、確定ターゲットの候補として選択されていたESE３２を、確定ターゲットとして選択する。また、「Routing State」は、ニュートラル状態からT3Tセレクト状態に遷移する。

Request System codeコマンドには、ESE３２のNFCID2が含まれているので、ESE３２は、当該コマンドに応じて、Request System code responseコマンドを返信する。Request System code responseコマンドは、CLF３１を経由して、NFCリーダ１２に送信される。このRequest System code responseコマンドには、ESE３２のSCとして“FE00”が含まれている。

NFCリーダ１２は、Request System code responseコマンドに応じて、当該コマンドにて取得したSCを用いて、SENSF_REQコマンドを送信する。CLF３１は、NFCリーダ１２からのSENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信するが、SCが“FE00”となるサービスにUICC３４が対応していないため、ESE３２からのみSENSF_RESコマンドが返信されることになる。CLF３１は、ESE３２からのSENSF_RESコマンドを、NFCリーダ１２に返信する。

NFCリーダ１２は、ESE３２のNFCID2を含むSENSF_RESコマンドに応じて、ESE３２に対するESE３２のNFCID2を含むRequest Serviceコマンドを送信する。CLF３１は、NFCリーダ１２からのRequest Serviceコマンドを、ESE３２に送信する。ESE３２は、CLF３１からのRequest Serviceコマンドに応じて、Request Service responseコマンドを返信する。CLF３１は、ESE３２からのRequest Service responseコマンドを、NFCリーダ１２に返信する。

このように、P2Pアプリ４１に対するトランザクションが不成立となった場合、ターゲットからの応答の優先度を変更することで、その時点で最も優先度が高くなったESE３２に対するトランザクションを成立させることができる。また、仮に、ESE３２に対するトランザクションが不成立となった場合には、その次に優先度の高いUICC３４、T3Tアプリ４２の順にトランザクションの成立を試みることになる。

以降、所定の期間の終了時刻（図１７の「Timer expire」）まで、同様の処理が繰り返され、NFCリーダ１２とESE３２の間で処理が行われる。なお、図１７に示すように、所定の期間中に、NFCリーダ１２によりRF信号がオフされたとしても、CLF３１では、優先度の変更に関する情報を保持しているため、RF信号がオンされた後は、ESE３２が最も高い優先度であるとして、処理を継続することができる。

そして、所定の期間の終了時刻が経過すると、CLF３１は、応答の優先度を初期状態に戻して、P2Pアプリ４１の優先度が最も高くなるようにする。これにより、例えば、その後、他のNFCリーダと近接通信を行う場合には、優先度が最も高いP2Pアプリ４１に対するトランザクションの成立から試みることになる。

以上のように、ある運用では、P2Pアプリ４１以外のターゲットを通信対象とする場合にもかかわらず、最初にNFCリーダ１２から送られるSENSF_REQコマンドに含まれるポーリングパラメータのSCが“FFFF”で、RC（Request Code）が"1"以外となる場合、すなわち、トランザクションの最初のコマンドにて、P2P通信とまったく同じポーリングパラメータにて通信を開始する場合がある。この場合、CLF３１は、P2Pアプリ４１の応答を返信するのか、又はP2Pアプリ４１以外のターゲットの応答を返信するのかを、コマンドからは判別することができない。そのため、当該SENSF_REQコマンドに対し、P2Pアプリ４１のSENSF_RESコマンドを応答した後で、ATR_REQ等の所定のコマンド以外のコマンドを受信すると、当該トランザクションは不成立となってしまう。

そこで、本技術を利用した運用では、このような条件が満たされた段階で、所定の期間だけ、SENSF_REQコマンドに対する応答の優先度を変更して、次のトランザクションが成立されるようにしている。これにより、CLF３１は、どのターゲットの応答を返信するかを判別することができない場合でも、P2Pアプリ４１以外のターゲットを順次、確定ターゲットの候補とすることができるので、NFCリーダ１２が所望とするターゲットを確実に選択することが可能となる。その結果、NFCリーダ１２とターゲットとの間で行われる通信を、迅速に確立することができる。

［NFCID2の抽出及び一時的保持］
次に、図１８及び図１９を参照して、NFCID2の抽出及び一時的保持に関する処理について説明する。

CLF３１は、SENSF_RESコマンドの応答時に、ESE３２及びUICC３４からのSENSF_RESコマンドのパケットに格納されたNFCID2を抽出する。図１８は、SENSF_RESコマンドのパケットにおけるNFCID2の格納位置を示している。

CLF３１は、ESE３２及びUICC３４のNFCID2をそれぞれ１つずつ、ターゲットと対応付けてメモリ３１Ａに保持する。CLF３１は、SENSF_REQコマンドに対する応答がある度にNFCID2を抽出して、メモリ３１Ａに保持された対応情報を更新する。なお、P2Pアプリ４１及びT3Tアプリ４２のNFCID2については、例えば、所定の規格に準拠した識別情報が、あらかじめメモリ３１Ａに保持される。

具体的には、図１９に示すように、CLF３１は、NFCリーダ１２からのSENSF_REQコマンド（SC=“FFFF”）をブロードキャスト送信し、その応答を、ESE３２及びUICC３４から受信する。CLF３１は、ESE３２及びUICC３４からのSENSF_RESコマンドに含まれるNFCID2を抽出し、メモリ３１Ａに保持する。この例では、ESE３２のNFCID2として“NFCID2_ese_0”、UICC３４のNFCID2として“NFCID2_uicc_0”がそれぞれ抽出され、メモリ３１Ａに保持される。

また、再度、NFCリーダ１２からSENSF_REQコマンド（SC=“FF00”）が送信されると、CLF３１は、当該SENSF_REQコマンドをブロードキャスト送信し、その応答を、ESE３２からのみ受信する。CLF３１は、ESE３２からのSENSF_RESコマンドに含まれるNFCID2として“NFCID2_ese_1”を抽出し、メモリ３１Ａに保持する。

このように、各ターゲットのNFCID2の値は、常に同じとは限らないので、CLF３１は、SENSF_RESコマンドを受信する度に、メモリ３１Ａに保持されたNFCID2の値を更新する。

［NFCID2のリプレイス処理］
次に、図２０及び図２１を参照して、NFCID2のリプレイス処理について説明する。

図２０に示すように、CLF３１は、特定のコマンドコードを受信して、ターゲットを強制的に変更した場合、NFCリーダ１２との通信用のNFCID2と、ターゲットとの通信用のNFCID2を置換して通信する必要がある。

例えば、CLF３１は、Get Container Issue Informationコマンドを受信した場合に、強制的にターゲットをESE３２に変更するとき、ESE３２のNFCID2を使用する必要があるため、ESE３２のNFCID2に置換してから、ESE３２との通信を行う。また、CLF３１は、NFCリーダ１２に応答をする場合には、NFCリーダ１２から受信したコマンドに含まれるNFCID2に再度置換してから応答する。

また、例えば、CLF３１は、Propose Ad-hoc Modeコマンドを受信した場合に、強制的にターゲットをDH３３に変更するとき、DH３３のT3Tアプリ４２のNFCID2に置換してから、T3Tアプリ４２と通信を行う。また、NFCリーダ１２との通信を行う場合には、当該置換前のNFCID2を用いて通信が行われる。

具体的には、図２１に示すように、CLF３１は、NFCリーダ１２からのSENSF_REQコマンド（SC=“FFFF”）をブロードキャスト送信し、その応答を、ESE３２及びUICC３４から受信する。CLF３１は、SENSF_RESコマンドに含まれるNFCID2を抽出し、メモリ３１Ａに保持する。そして、CLF３１は、優先度に従って、P2Pアプリ４１のNFCID2を含むSENSF_RESコマンドを返信する。

また、NFCリーダ１２からGet Container Issue Informationコマンドが送信されると、CLF３１は、当該コマンドに含まれるNFCID2を、P2Pアプリ４１からESE３２のものに置換してから、ESE３２に送信する。すると、当該コマンドに対する応答がESE３２から送信されるので、CLF３１は、応答コマンドに含まれるNFCID2を、ESE３２からP2Pアプリ４１のものに置換してから、NFCリーダ１２に送信する。

このように、コマンドに含まれるNFCID2を置換することで、NFCリーダ１２により指定されたコマンドの送り先を、強制的に変更することができる。このようなリプレイス処理は、例えば、上記のコマンドコードルーティングを行う場合には、必要な処理となる。

［ターゲット解除処理］
次に、ターゲットの解除処理について説明する。CLF３１は、所定のターゲット解除条件に基づいて、確定ターゲットを解除する。この解除条件は、ユーザによる実行中のアプリケーションプログラムの終了操作をトリガとするものと、RF信号の消失などの外部要因によるものとがある。

（RF_DEACTIVATE_CMD受信による解除）
CLF３１は、DH３３から、RF_DEACTIVATE_CMDコマンド(Idle Mode，DH_Request)などの特定のコマンドを受信した場合、NFCリーダ１２との通信そのものが終了するので、確定ターゲットを解除する。なお、当該コマンドが受信された場合には、いかなるルーティング状態にあっても、確定ターゲットが解除される。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（SENSF_REQ受信時におけるSENSF_RES応答による解除）
CLF３１は、ルーティング状態がT3Tセレクト状態にある場合に、NFCリーダ１２からのSENSF_REQコマンドをブロードキャスト送信して、SENSF_RESコマンドの応答があったときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（RLS_REQ受信による解除）
CLF３１は、P2Pアプリ４１が確定ターゲットに選択されている場合に、RLS_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（DSL_REQ受信による解除）
CLF３１は、P2Pアプリ４１が確定ターゲットに選択されている場合に、DSL_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（RF信号の消失による解除）
CLF３１は、P2Pアプリ４１が確定ターゲットに選択されている場合に、RF信号のオフが検出された場合には、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（NFC-Aへのtechnology changeを伴うPSL_REQによる解除）
CLF３１は、P2Pアプリ４１が確定ターゲットに選択されている場合に、NFC-Aへのtechnology changeを伴うPSL_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。

（その他の解除条件）
CLF３１は、デバイスリセットが発生した場合やCORE_RESET_CMDコマンドを受信した場合など、RF_DEACTIVATE_CMDコマンド以外のRFST_IDLE状態への遷移を引き起こす事象が発生した場合には、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。なお、CORE_RESET_CMDコマンドは、所定の規格に準拠したリセットを指示するためのコマンドである。

以上、ターゲット解除処理について説明した。

［コマンド対応処理］
次に、図２２のフローチャートを参照して、NFCリーダ１２からのコマンドを受信した際に、CLF３１にて実行されるコマンド対応処理について説明する。

ステップＳ１０１において、パケット受信処理部１０１は、NFCリーダ１２からコマンドを受信したか否かを判定する。ステップＳ１０１において、コマンドを受信したと判定された場合、処理は、ステップＳ１０２に進められる。

ステップＳ１０２において、パケット受信処理部１０１は、受信したコマンドがSENSF_REQコマンドであるか否かを判定する。ステップＳ１０２において、SENSF_REQコマンドであると判定された場合、処理は、ステップＳ１０３に進められる。

ステップＳ１０３において、パケット受信処理部１０１は、SENSF_REQコマンドを、各ターゲットにブロードキャスト送信する。

ステップＳ１０４において、パケット受信処理部１０１は、SENSF_REQコマンドを受信したターゲットから返信されるSENSF_RESコマンドを受信する。

ステップＳ１０５において、パケット受信処理部１０１は、応答のあったターゲットの中から、応答の優先度に従って、応答を返信する確定ターゲットの候補を選択する。なお、前述の通り、応答の優先度は、初期状態では、P2Pアプリ４１が最も高い優先度となる。

ステップＳ１０６において、パケット受信処理部１０１は、ステップＳ１０５にて選択した確定ターゲットの候補からのSENSF_RESコマンドを、NFCリーダ１２に送信する。これにより、NFCリーダ１２は、NFCデバイス１１からのSENSF_RESコマンドを受信し、当該コマンドに応じた処理を行う。

一方、ステップＳ１０２において、受信したコマンドがSENSF_REQコマンド以外のコマンドであると判定された場合、処理は、ステップＳ１０７に進められる。

ステップＳ１０７において、パケット受信処理部１０１は、現在のルーティング状態がニュートラル状態であるか否かを判定する。ステップＳ１０７において、現在のルーティング状態がニュートラル状態であると判定された場合、処理は、ステップＳ１０８に進められる。

ステップＳ１０８において、パケット受信処理部１０１は、ニュートラル状態における受信パケットの処理を行う。

ここで、図２３のフローチャートを参照して、図２２のステップＳ１０８に対応するニュートラル状態における受信パケットの処理について説明する。

ステップＳ１３１において、パケット受信処理部１０１は、ニュートラル状態における受信パケットの処理を行う。当該受信パケット処理では、前述した図１１及び図１２で説明したように、コマンドコードルーティング、プロトコルルーティング、及びテクノロジールーティングによって、受信パケットの評価が行われ、その評価結果に応じて、確定ターゲットが選択される。

また、ルーティング状態管理部１０２は、確定ターゲットが選択された場合、ルーティング状態を、現在のニュートラル状態から、P2Pセレクト状態又はT3Tセレクト状態に遷移させる。

ステップＳ１３２において、パケット受信処理部１０１は、NFCリーダ１２に対する直前の応答として、P2Pアプリ４１のSENSF_RESコマンドの応答をしたか否かを判定する。ステップＳ１３２において、直前にP2Pアプリ４１のSENSF_RESコマンドの応答をしたと判定された場合、処理は、ステップＳ１３３に進められる。

ステップＳ１３３において、パケット受信処理部１０１は、ステップＳ１３１の処理によって、P2Pアプリ４１が確定ターゲットに選択されたか否かを判定する。ステップＳ１３３において、P2Pアプリ４１が確定ターゲットに選択されなかったと判定された場合、処理は、ステップＳ１３４に進められる。

ステップＳ１３４において、優先度管理部１０３は、優先度の変更を行う。すなわち、この場合、確定ターゲットの候補として選択されたP2Pアプリ４１のSENSF_RESコマンドの応答をしたのにもかかわらず、NFCリーダ１２からP2Pアプリ４１に対するコマンド以外のコマンドを受信したことになるので、優先度の変更が行われる。例えば、優先度管理部１０３は、初期状態では最も高い優先度となるP2Pアプリ４１の優先度を下げて、ESE３２、UICC３４、T3Tアプリ４２、P2Pアプリ４１の順に優先度を変更する。この場合、P2Pアプリ４１の優先度は、ターゲットの中で最も低い優先度となる。

なお、変更後の優先度の順序であるが、上記の順序に限らず、他の順序に並び替えることも可能である。例えば、ターゲットが、ESE３２、UICC３４、及びP2Pアプリ４１からなる場合に、P2Pアプリ４１が確定ターゲットに選択されなかったとき、優先度管理部１０３は、ESE３２、UICC３４、P2Pアプリ４１の順となるように優先度を変更することができる。この場合に、優先度管理部１０３は、ESE３２、P2Pアプリ４１、UICC３４の順となるように優先度を変更してもよい。

また、例えば、ターゲットが、ESE３２及びUICC３４のうちいずれか一方しか存在しなかった場合、優先度管理部１０３は、P2Pアプリ４１の優先度を、ESE３２及びUICC３４のいずれか一方の次の優先度に変更する。すなわち、ターゲットには、ESE３２及びUICC３４のいずれか一方又は双方が少なくとも含まれており、優先度管理部１０３は、P2Pアプリ４１が確定ターゲットに選択されなかった場合、P2Pアプリ４１の優先度を、ESE３２及びUICC３４のいずれか一方又は双方の次の優先度に変更する。

さらに、優先度管理部１０３は、NFCリーダ１２の動作シーケンスに応じて、応答の優先度を変更するようにしてもよい。

このように、変更後の優先度の順序は、例えばターゲットの種類や運用の形態などに応じて、任意に設定されるものであり、原則として、最も高い優先度であったP2Pアプリ４１の優先度が低くなるように並び替えられることになる。

ステップＳ１３２において、直前にP2Pアプリ４１のSENSF_RESコマンドの応答をしていないと判定された場合には、ステップＳ１３３及びＳ１３４はスキップされる。また、ステップＳ１３３において、P2Pアプリ４１が確定ターゲットに選択されたと判定された場合には、ステップＳ１３４はスキップされる。

ステップＳ１３４の処理が終了又はスキップされると、処理は、図２２のステップＳ１０８に戻り、それ以降の処理が行われる。

また、ステップＳ１０７において、現在のルーティング状態がニュートラル状態ではないと判定された場合、処理は、ステップＳ１０９に進められる。

ステップＳ１０９において、パケット受信処理部１０１は、現在のルーティング状態がT3Tセレクト状態であるか否かを判定する。ステップＳ１０９において、現在のルーティング状態がT3Tセレクト状態であると判定された場合、処理は、ステップＳ１１０に進められる。

ステップＳ１１０において、パケット受信処理部１０１は、T3Tセレクト状態における受信パケット処理を行う。当該受信パケット処理では、前述した図１３及び図１４で説明したように、コマンドコードルーティング及びP2Pプロトコルルーティングによって、受信パケットの評価が行われ、その評価結果に応じて、確定ターゲットが選択される。

一方、ステップＳ１０９において、現在のルーティング状態がT3Tセレクト状態でない、つまり、P2Pセレクト状態であると判定された場合、処理は、ステップＳ１１１に進められる。

ステップＳ１１１において、パケット受信処理部１０１は、P2Pセレクト状態における受信パケット処理を行う。当該受信パケット処理では、前述した図１５で説明したように、受信パケットの評価は行われず、受信パケットは、常にP2Pアプリ４１に送信される。

ステップＳ１０１においてコマンドを受信していないと判定された場合、又はステップＳ１０８，Ｓ１１０，Ｓ１１１の処理が終了した場合、処理は、ステップＳ１１２に進められる。

ステップＳ１１２において、優先度管理部１０３は、図２３のステップＳ１３４にて応答の優先度の変更を行ったか否かを判定する。ステップＳ１１２において、優先度の変更を行ったと判定された場合、処理は、ステップＳ１１３に進められる。

ステップＳ１１３において、優先度管理部１０３は、所定の期間を経過したか否かを判定する。ステップＳ１１３において、所定の期間を経過したと判定された場合、処理は、ステップＳ１１４に進められる。

ステップＳ１１４において、優先度管理部１０３は、応答の優先度を初期状態に戻して、P2Pアプリ４１の優先度が最も高くなるように変更する。

なお、ステップＳ１１２において優先度を変更していないと判定された場合、ステップＳ１１３において所定の期間を経過していないと判定された場合、又はステップＳ１１４の処理が終了した場合、処理は、ステップＳ１０１に戻り、それ以降の処理が繰り返される。

以上、コマンド対応処理について説明した。コマンド対応処理によれば、ルーティング状態に応じた受信パケットの処理プロセスが行われる。また、ニュートラル状態における受信パケットの処理プロセスでは、受信パケットの評価が行われ、P2Pアプリ４１のSENSF_RESコマンドの応答をしたのにもかかわらず、P2Pアプリ４１が確定ターゲットに選択されなかった場合には、応答の優先度の変更が行われ、P2Pアプリ４１の優先度が下げられる。

［本技術を適用したコンピュータの説明］
前述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

図２４は、前述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

コンピュータ２００において、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。

バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、及びドライブ２１０が接続されている。

入力部２０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。

以上のように構成されるコンピュータ２００では、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５及びバス２０４を介して、RAM２０３にロードして実行することにより、前述した一連の処理が行われる。

コンピュータ２００（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

コンピュータ２００では、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。

なお、コンピュータ２００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

ここで、本明細書において、コンピュータ２００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。

また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。

さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

なお、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

また、前述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

なお、本技術は、以下のような構成をとることができる。

（１）
少なくともP2P（Peer to Peer）のアプリケーションを含む複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備え、
前記フロントエンドは、
前記外部装置から、System Codeを含む第１のコマンドを受信する受信部と、
前記第１のコマンドを前記複数のターゲットに送信する送信部と、
前記P2Pのアプリケーションに関する前記確定ターゲットの優先度を管理する優先度管理部と
を有する
通信装置。
（２）
前記送信部は、前記外部装置から前記第１のコマンドを受信した場合、前記第１のコマンドを、前記複数のターゲットにブロードキャスト送信する
前記（１）に記載の通信装置。
（３）
前記優先度管理部は、
前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も優先度の高いターゲットとし、
前記P2Pアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pアプリケーションの優先度を下げる
前記（１）又は（２）に記載の通信装置。
（４）
前記複数のターゲットのうち、前記P2Pのアプリケーションを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）の少なくとも一方を含んでおり、
前記優先度管理部は、前記P2Pのアプリケーションの優先度を、前記セキュアエレメント及び前記UICCの少なくとも一方の次の優先度に変更する
前記（３）に記載の通信装置。
（５）
前記優先度管理部は、前記セキュアエレメント、前記UICC、前記P2Pのアプリケーションの順となるように優先度を変更する
前記（４）に記載の通信装置。
（６）
前記優先度管理部は、前記セキュアエレメント、前記P2Pのアプリケーション、前記UICCの順となるように優先度を変更する
前記（４）に記載の通信装置。
（７）
前記他のターゲットは、さらに、所定の規格に準拠した所定のアプリケーションを含んでおり、
前記優先度管理部は、前記セキュアエレメント、前記UICC、前記所定のアプリケーション、前記P2Pのアプリケーションの順となるように優先度を変更する
前記（４）に記載の通信装置。
（８）
前記優先度管理部は、前記P2Pのアプリケーションの優先度を、最も低い優先度に変更する
前記（１）乃至（４）のいずれかに記載の通信装置。
（９）
前記優先度管理部は、前記外部装置の動作シーケンスに応じて、優先度を変更する
前記（１）乃至（４）のいずれかに記載の通信装置。
（１０）
前記優先度管理部は、前記P2Pのアプリケーションの優先度を変更した場合に、あらかじめ設定された所定の期間を経過したとき、前記P2Pのアプリケーションの優先度を、最も高い優先度に戻す
前記（１）乃至（４）のいずれかに記載の通信装置。

１１ NFCデバイス， １２ NFCリーダ， ３１ CLF， ３１Ａ メモリ， ３２ ESE， ３３ DH， ３４ UICC， ４１，４１Ｌ P2Pアプリ， ４２，４２Ｌ T3Tアプリ， １０１ パケット受信処理部， １０２ ルーティング状態管理部， １０３ 優先度管理部， １０４ 無線通信制御部， ２００ コンピュータ， ２０１ CPU

Claims (10)

1. 少なくともP2P（Peer to Peer）のアプリケーションを含む複数のターゲットと、
   前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
   を備え、
   前記フロントエンドは、
   前記外部装置から、System Codeを含む第１のコマンドを受信する受信部と、
   前記第１のコマンドを前記複数のターゲットに送信する送信部と、
   前記P2Pのアプリケーションに関する前記確定ターゲットの優先度を管理する優先度管理部と
   を有する
   通信装置。
2. 前記送信部は、前記外部装置から前記第１のコマンドを受信した場合、前記第１のコマンドを、前記複数のターゲットにブロードキャスト送信する
   請求項１に記載の通信装置。
3. 前記優先度管理部は、
   前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も優先度の高いターゲットとし、
   前記P2Pアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pアプリケーションの優先度を下げる
   請求項２に記載の通信装置。
4. 前記複数のターゲットのうち、前記P2Pのアプリケーションを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）の少なくとも一方を含んでおり、
   前記優先度管理部は、前記P2Pのアプリケーションの優先度を、前記セキュアエレメント及び前記UICCの少なくとも一方の次の優先度に変更する
   請求項３に記載の通信装置。
5. 前記優先度管理部は、前記セキュアエレメント、前記UICC、前記P2Pのアプリケーションの順となるように優先度を変更する
   請求項４に記載の通信装置。
6. 前記優先度管理部は、前記セキュアエレメント、前記P2Pのアプリケーション、前記UICCの順となるように優先度を変更する
   請求項４に記載の通信装置。
7. 前記他のターゲットは、さらに、所定の規格に準拠した所定のアプリケーションを含んでおり、
   前記優先度管理部は、前記セキュアエレメント、前記UICC、前記所定のアプリケーション、前記P2Pのアプリケーションの順となるように優先度を変更する
   請求項４に記載の通信装置。
8. 前記優先度管理部は、前記P2Pのアプリケーションの優先度を、最も低い優先度に変更する
   請求項４に記載の通信装置。
9. 前記優先度管理部は、前記外部装置の動作シーケンスに応じて、優先度を変更する
   請求項４に記載の通信装置。
10. 前記優先度管理部は、前記P2Pのアプリケーションの優先度を変更した場合に、あらかじめ設定された所定の期間を経過したとき、前記P2Pのアプリケーションの優先度を、最も高い優先度に戻す
    請求項４に記載の通信装置。

Images