通信装置、制御方法、及びプログラム
【課題】迅速に通信を確立することができるようにする。
【解決手段】フロントエンドは、所定の処理を実行する複数のターゲットの中から、近接通信を行う外部装置の通信対象となる確定ターゲットを選択して、外部装置との間で通信が行われるように制御するに際して、確定ターゲットの候補を選択するためのコマンドの送信を行うとき、その送信先として、所定のターゲットが２回に１回選択されるように制御する。本技術は、例えば、NFC規格に対応した通信装置に適用することができる。
【解決手段】フロントエンドは、所定の処理を実行する複数のターゲットの中から、近接通信を行う外部装置の通信対象となる確定ターゲットを選択して、外部装置との間で通信が行われるように制御するに際して、確定ターゲットの候補を選択するためのコマンドの送信を行うとき、その送信先として、所定のターゲットが２回に１回選択されるように制御する。本技術は、例えば、NFC規格に対応した通信装置に適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、通信装置、制御方法、及びプログラムに関し、特に、迅速に通信を確立することができるようにした通信装置、制御方法、及びプログラムに関する。
【背景技術】
【０００２】
無線通信の規格として、NFC（Near Field Communication）が知られている。NFC規格に対応したNFCデバイスでは、端末内に複数の通信対象（以下、ターゲットという）が同時に存在する場合が想定される。
【０００３】
本出願人は、NFCデバイスとして、ターゲットとしての複数のセキュアエレメントと、それらのセキュアエレメントに共通に使用され、リーダ等の外部装置と近接通信するフロントエンドとを備え、フロントエンドが、起動時に、複数のセキュアエレメントに対して通信のための異なるタイムスロットを割り当てるものを先に提案している（例えば、特許文献１参照）。
【０００４】
図１に示すように、NFCの無線通信を行う非接触無線チップ（CLF：Contactless Front End）（以下、フロントエンドともいう）と、リーダ（reader）が近接通信を行う場合、シングルレスポンスとマルチレスポンスの２つの方式がある。
【０００５】
シングルレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが１つのポーリングレスポンスを返すので、リーダは、そのポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、シングルレスポンス方式では、特別な回路を設けることなく実装できるというメリットがある反面、マルチレスポンス方式と比べてターゲットの正答率(「リーダに対して、リーダが望むターゲットからのレスポンスを応答できる確率」を意味するものであり、以下、正答率という)が低くなってしまう。
【０００６】
一方、マルチレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが複数のポーリングレスポンスを返すので、リーダは、複数レスポンス受信に対応していれば、複数のポーリングレスポンスの中から選択された所望のポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、マルチレスポンス方式は、一度に複数のレスポンスを返信するための特別な回路をフロントエンドに設ける必要があって実装面が複雑になる反面、シングルレスポンス方式と比べてターゲットの正答率を高くすることができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−４９７７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、図２に示すように、フロントエンドがマルチレスポンス方式の機能を有する場合であっても、例えば３つのポーリングレスポンスを返したいときに、２つのタイムスロットしかないと、スロット不足のため、一度にポーリングレスポンスを返信することができなくなる。このように、マルチレスポンス方式では、スロット数が多ければ、ポーリングスロットを全て返信することが可能となるが、リーダが、TSN=0,1など、小さいTSN（Time Slot Number）によりポーリングしてきた場合に、スロット数が不足してしまい、全てのポーリングレスポンスを返せなくなるときがある。
【０００９】
また、マルチレスポンス方式を利用するためには、特別な回路をフロントエンドに設ける必要があるため、マルチレスポンス方式に対応してない既存のデバイスだと、特別な回路を実装する必要が出てくる。
【００１０】
また、あるNFCのリーダ動作規格によると、リーダは２回のポーリングを行い、２回のうちどちらかに、P2P（Peer to Peer）のアプリケーションからのレスポンスがあれば、P2Pのアプリケーションの動作を進めることができる、という動作仕様が定義されており、この動作仕様に対応する必要がある。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、上記のリーダの動作仕様に対応し、かつ、フロントエンドに特別な回路を実装することなく、リーダが所望とするターゲットを確実に選択して、迅速に通信を確立することができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の通信装置は、それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する。
【００１３】
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する。
【００１４】
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである。
【００１５】
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる。
【００１６】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する。
【００１７】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。
【００１８】
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。
【００１９】
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する。
【００２０】
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する。
【００２１】
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する。
【００２２】
通信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
【００２３】
本技術の一側面の制御方法又はプログラムは、前述した本技術の一側面の通信装置に対応する制御方法又はプログラムである。
【００２４】
本技術の一側面の通信装置、制御方法、及びプログラムにおいては、それぞれが所定の処理を実行する複数のターゲットの中から、外部装置の通信対象となる確定ターゲットが選択され、外部装置との近接通信が行われる。また、確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットが２回に１回選択される。
【発明の効果】
【００２５】
本技術の一側面によれば、迅速に通信を確立することができる。
【図面の簡単な説明】
【００２６】
【図１】近接通信の方式を説明する図である。
【図２】マルチレスポンス方式における応答条件の例を示す図である。
【図３】NFCデバイスの構成例を示す図である。
【図４】CLFの詳細な構成例を示す図である。
【図５】ルーティング処理を説明するフローチャートである。
【図６】シンプルローテーション方式の候補遷移図である。
【図７】スキップ機能を含むシンプルローテーション方式の候補遷移図である。
【図８】スキップ機能を含むP2Pメインのローテーション方式の候補遷移図である。
【図９】ブロードキャスト送信を説明するシーケンス図である。
【図１０】ブロードキャスト送信を、スキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合の候補遷移図である。
【図１１】候補選択処理の流れを説明するフローチャートである。
【図１２】IDm比較方式を説明するシーケンス図である。
【図１３】IDm比較方式による確定処理の流れを説明するフローチャートである。
【図１４】ATR_REQ受信方式を説明するシーケンス図である。
【図１５】ATR_REQ受信方式による確定処理の流れを説明するフローチャートである。
【図１６】RF信号の消失によるターゲットの解除を説明する図である。
【図１７】RF信号が消失して復活した場合を説明するシーケンス図である。
【図１８】解除処理の流れを説明するフローチャートである。
【図１９】ルーティングの状態遷移図である。
【図２０】ユースケース１を説明するシーケンス図である。
【図２１】ユースケース２を説明するシーケンス図である。
【図２２】ユースケース３を説明するシーケンス図である。
【図２３】拡張版のスキップ機能を含むP2Pメインのローテーション方式の候補遷移図である。
【図２４】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照しながら本技術の実施の形態について説明する。
【００２８】
［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（Peer to Peer）のアプリケーションであるP2Pアプリ４１を実行する。なお、P2Pアプリ４１は、１又は複数実行可能とされる。
【００３５】
UICC（Universal Integrated Circuit Card）３４は、例えば、SIM（Subscriber Identity Module）カードから構成される。UICC３４は、NFCアプリケーションを実行することで、例えば、電子決済機能を実現する。
【００３６】
このように、ESE３２、UICC３４、及びP2Pアプリ４１は、NFCリーダ１２の通信対象となるターゲットであって、それぞれが所定の処理を行う。換言すれば、ターゲットには、ESE３２やUICC３４などのデバイスと、P2Pアプリ４１などのアプリケーションが含まれることになる。
【００３７】
NFCデバイス１１は、以上のように構成される。
【００３８】
［CLFの詳細な構成例］
図４は、図３のCLF３１の詳細な構成例を示す図である。
【００３９】
CLF３１は、候補選択部１０１、確定部１０２、解除部１０３、及び無線通信制御部１０４から構成される。
【００４０】
候補選択部１０１は、所定の規則に従って、NFCリーダ１２の通信対象となるターゲットの候補（以下、ターゲット候補という）を選択する候補選択処理を行う。候補選択処理が行われることで、ターゲット候補として、１又は複数のターゲットが選択される。
【００４１】
確定部１０２は、所定の規則に従って、候補選択処理によりターゲット候補として選択されたターゲットを確定する確定処理を行う。確定処理が行われることで、ターゲット候補として選択されたターゲットのうち、NFCリーダ１２の通信対象となるターゲット（以下、確定ターゲットという）が確定される。
【００４２】
解除部１０３は、所定の規則に従って、確定処理により確定されたターゲットを解除する解除処理を行う。解除処理が行われることで、確定ターゲットがNFCリーダ１２の通信対象から解除される。
【００４３】
無線通信制御部１０４は、NFCリーダ１２との間で行われる近接通信を制御するための処理を行う。
【００４４】
CLF３１は、以上のように構成される。
【００４５】
［ルーティング処理］
次に、図５のフローチャートを参照して、CLF３１により実行されるルーティング処理について説明する。
【００４６】
ステップＳ１において、候補選択部１０１は、候補選択処理を行う。この候補選択処理によって、複数のターゲットの中から、１以上のターゲットが、ターゲット候補として選択される。
【００４７】
なお、候補選択処理の詳細は、図６乃至図１１を参照して後述する。
【００４８】
ステップＳ２において、確定部１０２は、確定処理を行う。この確定処理によって、ターゲット候補として選択された１以上のターゲットの中から、NFCリーダ１２の通信対象となる確定ターゲットが確定される。
【００４９】
なお、確定処理の詳細は、図１２乃至図１５を参照して後述する。
【００５０】
ステップＳ３において、解除部１０３は、解除処理を行う。この解除処理によって、確定ターゲットがNFCリーダ１２の通信対象から解除される。すなわち、一旦、通信対象として確定された確定ターゲットは、解除処理が行われ、通信対象から解除されるまで、NFCリーダ１２の通信対象となる。
【００５１】
なお、解除処理の詳細は、図１６乃至図１８を参照して後述する。また、規格によっては、解除処理を行う必要のない規格もあるが、その場合にはステップＳ３の処理は省略される。
【００５２】
以上で、ルーティング処理の説明を終了する。
【００５３】
前述したルーティング処理によれば、複数のターゲットの中から、１以上のターゲット候補が選択され、選択された１以上のターゲットの中から、NFCリーダ１２の通信対象となる確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、通信対象として確定された確定ターゲットと、NFCリーダ１２との間で通信が行われる。
【００５４】
［候補選択処理］
次に、図６乃至図１１を参照して、図５のステップＳ１に対応する候補選択処理について説明する。
【００５５】
ここでは、候補選択処理として、固定ターゲット方式、シンプルローテーション方式、スキップ機能を含むシンプルローテーション方式、及び、スキップ機能を含むP2Pメインのローテーション方式の４つの方式について説明する。
【００５６】
固定ターゲット方式は、アプリケーションから特に選択されない限り、デフォルトで設定されたターゲットが常に選択される方式である。
【００５７】
固定ターゲット方式を採用すると、実装面では極めてシンプルになるというメリットがある反面、ターゲット候補の選択時の正答率が悪くなるというデメリットもある。例えば、ターゲットをESE３２に固定してしまうと、ユーザの事前設定なしには、P2Pアプリ４１やUICC３４などのアプリケーションを動作させることができなくなる。
【００５８】
シンプルローテーション方式は、ターゲット候補を順次変更することで、ターゲットを選択する方式である。CLF３１は、NFCリーダ１２からポーリングされる度に、異なるターゲット候補を選択して、選択されたターゲットからのレスポンスを返信する。
【００５９】
具体的には、図６に示すように、例えば、最初のポーリングではESE３２がターゲット候補として選択され、その後、ポーリングされるごとにローテーションが行われ、UICC３４、P2Pアプリ４１、ESE３２、・・・が順次、ターゲット候補として選択される。
【００６０】
シンプルローテーション方式を採用すると、実装面ではシンプルになるというメリットがある反面、所望のターゲットを選択するためにポーリングのリトライを繰り返す場合が出てくるため、ターゲット候補の選択時の正答率は上がらないというデメリットがある。
【００６１】
スキップ機能を含むシンプルローテーション方式は、前述したシンプルローテーションに加えて、あるターゲットが、対象外であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する方式である。CLF３１は、NFCリーダ１２からポーリングされる度に、そのポーリングパラメータをチェックして、対象外となるターゲットを判定する。そして、対象外のターゲット候補であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する。
【００６２】
具体的には、図７に示すように、例えば、ポーリングパラメータのSC（System Code）が"FFFF"ではない場合、又はRC（Request Code）="1"の場合、そのポーリングは、P2Pアプリ４１に対するものではないため、ターゲット候補を、UICC３４からESE３２に切り替える。すなわち、前述したシンプルローテーションであると、UICC３４の次はP2Pアプリ４１がターゲット候補となるところ、P2Pアプリ４１がスキップされ、ターゲット候補がESE３２に強制的に切り替えられることになる。
【００６３】
スキップ機能を含むシンプルローテーションを採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、所定の規則により対象外となるターゲットを特定して非選択とすることで、ターゲット候補の選択時の正答率も向上させることができる。
【００６４】
スキップ機能を含むP2Pメインのローテーション方式は、前述したスキップ機能を含むシンプルローテーションを、P2Pアプリ４１を中心に行う方式である。
【００６５】
具体的には、図８に示すように、ローテーションの順番が、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順に行われる。これは、あるNFCのリーダ動作規格によると、NFCリーダ１２は２回のポーリングを行い、２回のうちどちらかにP2Pアプリ４１からのレスポンスがあれば、P2P動作を進めることができる、という動作仕様が定義されており、これに対応するため、２回に１回は必ず、P2Pアプリ４１のレスポンスが返信されるようにしたものである。
【００６６】
これにより、ターゲットとなる、P2Pアプリ４１，ESE３２，UICC３４のうち、P2Pアプリ４１が２回に１回必ず選択されるので、NFCリーダ１２では、確実にP2Pアプリ４１に対する動作が行われることになる。また、スキップ機能を含むシンプルローテーション方式と同様に、例えば、P2Pアプリ４１に対するポーリングではない場合には、ローテーションが、P2Pアプリ４１をスキップして、ターゲット候補がESE３２又はUICC３４に、強制的に切り替えられる。
【００６７】
なお、図８の例では、P2Pアプリ４１が２回に１回必ずターゲット候補として選択されるとして説明したが、NFCリーダ１２側の動作の規則に応じて、P2Pアプリ４１以外の他のターゲットが２回に１回、ターゲット候補として選択されるようにしてもよい。すなわち、３以上のターゲットのうちの１つのターゲットが、２回に１回、ターゲット候補として選択されるようにすることで、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【００６８】
スキップ機能を含むP2Pメインのローテーション方式を採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。また、NFCリーダ１２側の動作の規則に応じて、所定のターゲットが優先的に選択されるので、NFCリーダ１２側の動作との整合をとることができる。
【００６９】
また、CLF３１は、NFCリーダ１２から受信したポーリングコマンドを、ターゲットに送信する場合、ユニキャスト又はブロードキャストにより送信することができる。
【００７０】
ユニキャストでは、現時点で、ターゲット候補となっているターゲットにのみ、ポーリングコマンドが送信される。そのため、ユニキャスト送信を行う場合には、実装面ではシンプルとなるが、ターゲット候補の選択時の正答率の向上には寄与しないこととなる。
【００７１】
一方、ブロードキャストでは、ターゲット候補となっているターゲットであるか否かに関係なく、複数のターゲットにポーリングコマンドが送信される。
【００７２】
具体的には、図９に示すように、例えば、ESE３２がターゲット候補となっている場合に、NFCリーダ１２がUICC３４に対するSCを指定してポーリングコマンドを送信してきたとき、CLF３１は、ポーリングコマンドを、ESE３２とUICC３４の両方にブロードキャストで送信する。これにより、ESE３２からは無応答となるが、UICC３４からはレスポンスがあるため、ターゲット候補を、ESE３２からUICC３４に切り替えて、NFCリーダ１２に返信することができる。すなわち、ブロードキャスト送信を行う場合には、実装面ではユニキャストに比べて複雑になるが、ターゲット候補の選択時の正答率の大幅な向上が見込まれる。
【００７３】
図１０は、図９で説明したブロードキャスト送信を、図８で説明したスキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合のターゲット候補遷移図である。
【００７４】
前述したように、スキップ機能を含むP2Pメインのローテーション方式では、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にローテーションされる。それに対して、ブロードキャスト送信が組み込まれると、P2Pアプリ４１からESE３２又はUICC３４にターゲット候補が遷移する際に、ブロードキャスト送信に対するレスポンスに応じて、ESE３２又はUICC３４にターゲット候補が遷移する。
【００７５】
例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１の順に候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC３４からは無応答であったが、ESE３２からレスポンスがあった場合、UICC３４ではなく、ESE３２がターゲット候補とされる。そして、P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にターゲット候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC３４からレスポンスがあったが、ESE３２からは無応答であった場合、ESE３２ではなく、UICC３４がターゲット候補とされ、その後、P2Pアプリ４１に候補が遷移される。
【００７６】
すなわち、ブロードキャスト送信を、スキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にローテーションされる。
【００７７】
このように、３以上のターゲットのうちの１つのターゲットが、２回に１回選択されるようにターゲット候補を選択するだけでなく、ブロードキャスト送信することで、２回に１回選択されるターゲット以外のターゲットの正答率を、さらに向上させることができる。その結果、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【００７８】
次に、図１１のフローチャートを参照して、候補選択部１０１により実行される、図５のステップＳ１に対応する候補選択処理の流れについて説明する。
【００７９】
なお、図１１では、候補選択処理として最も効率がよい方式となる、スキップ機能を含むP2Pメインのローテーション方式による候補選択処理について説明する。
【００８０】
ステップＳ２１において、候補選択部１０１は、初期設定を行う。この初期設定としては、例えば、P2Pアプリ４１からローテーションを開始するか否かに応じて、変数i=0又は1がセットされる。
【００８１】
ステップＳ２２において、候補選択部１０１は、無線通信制御部１０４を制御して、NFCリーダ１２からポーリングコマンドを受信したか否かを判定する。ステップＳ２２において、ポーリングコマンドを受信したと判定された場合、処理は、ステップＳ２３に進められる。
【００８２】
ステップＳ２３において、候補選択部１０１は、NFCリーダ１２からのポーリングコマンドに含まれるポーリングパラメータに基づいて、P2Pアプリ４１がターゲット候補の対象外となるか否かを判定する。ここでは、前述したように、例えば、ポーリングパラメータが、SC="FFFF"ではない場合、又はRC="1"の場合、そのポーリングは、P2Pアプリ４１に対するものではないことになる。
【００８３】
なお、ここでは、P2Pアプリ４１がターゲット候補の対象外となる例を説明したが、ポーリングパラメータに応じて、P2Pアプリ４１以外の他のターゲットが対象外となるようにしてもよい。
【００８４】
ステップＳ２３において、P2Pアプリ４１がターゲット候補の対象外であると判定された場合、処理は、ステップＳ２４に進められる。ステップＳ２４において、候補選択部１０１は、P2Pアプリ４１以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE３２又はUICC３４がターゲット候補として選択される。
【００８５】
一方、ステップＳ２３において、P2Pアプリ４１がターゲット候補の対象であると判定された場合、処理は、ステップＳ２５に進められる。ステップＳ２５において、候補選択部１０１は、変数iの値が偶数であるか否かを判定する。
【００８６】
ステップＳ２５において、変数iの値が偶数であると判定された場合、処理は、ステップＳ２６に進められる。ステップＳ２６において、候補選択部１０１は、P2Pアプリ４１を、ターゲット候補として選択する。
【００８７】
一方、ステップＳ２５において、変数iの値が奇数であると判定された場合、処理は、ステップＳ２４に進められる。ステップＳ２４において、候補選択部１０１は、P2Pアプリ４１以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE３２又はUICC３４がターゲット候補として選択される。また、このとき、ESE３２及びUICC３４に対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を向上させることができるのは、図９を参照して前述した通りである。
【００８８】
ステップＳ２４又はＳ２６が終了すると、処理は、ステップＳ２７に進められる。ステップＳ２７において、候補選択部１０１は、変数iの値を1インクリメントする。これにより、次のステップＳ２５の判定処理では、偶数と奇数が逆になるので、判定結果も逆になり、直近で、P2Pアプリ４１がターゲット候補として選択された場合には、次は、P2Pアプリ４１以外の他のターゲットが選択されることになる。その逆に、P2Pアプリ４１以外の他のターゲットが直近で選択された場合には、次は、P2Pアプリ４１がターゲット候補として選択されることになる。
【００８９】
ステップＳ２７の処理が終了すると、ステップＳ２８において、候補選択部１０１は、ターゲット候補の選択が終了したか否かを判定する。
【００９０】
ステップＳ２８において、ターゲット候補の選択が終了していないと判定された場合、処理は、ステップＳ２２に戻り、前述した処理が繰り返される。すなわち、ターゲット候補の選択が終了したと判定されるまで（ステップＳ２８のYes）、ステップＳ２２乃至Ｓ２８の処理が繰り返され、ターゲット候補として、P2Pアプリ４１が２回に１回選択されることになる。ただし、前述の通り、例えば、P2Pアプリ４１に対するポーリングではない場合には、ESE３２又はUICC３４が、ターゲット候補として強制的に選択される。
【００９１】
そして、ステップＳ２８において、ターゲット候補の選択が終了したと判定された場合、図１１の候補選択処理は終了する。
【００９２】
以上のように、スキップ機能を含むP2Pメインのローテーション方式を用いて、候補選択処理を行うことで、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。
【００９３】
また、NFCリーダ１２側の動作の規則に合わせて、P2Pアプリ４１等の所定のターゲットが優先的に選択されるので、NFCリーダ１２側の動作との整合をとることができる。さらに、所定のターゲット以外の複数のターゲットに対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を大幅に向上させることができる。
【００９４】
［確定処理］
次に、図１２乃至図１５を参照して、図５のステップＳ２に対応する確定処理について説明する。
【００９５】
ここでは、確定処理として、IDm比較方式及びATR_REQ受信方式の２つの方式について説明する。
【００９６】
IDm比較方式は、シングルレスポンス方式において、NFCリーダ１２からCLF３１に対して、複数回のポーリングが行われる場合に、CLF３１が各ポーリングに対して、ICチップの固有のIDであるIDmを用いて、異なるポーリングレスポンスを返すことにより、擬似的にマルチレスポンスを行う方式である。
【００９７】
具体的には、図１２に示すように、CLF３１は、NFCリーダ１２からのポーリングコマンドに応じて、候補選択処理を行う。CLF３１は、UICC３４からレスポンスがあった場合、UICC３４のIDmを取得して、メモリ３１Ａに記憶する。これにより、UICC３４がターゲット候補としてキープされる。そして、CLF３１は、UICC３４のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【００９８】
続いて、NFCリーダ１２から異なるポーリングコマンドが送信された場合、CLF３１は、候補選択処理を行う。CLF３１は、ESE３２からレスポンスがあった場合、ESE３２のIDmを取得して、メモリ３１Ａに記憶する。これにより、ESE３２が候補に加えられ、ターゲット候補として、UICC３４とESE３２が選択される。そして、CLF３１は、ESE３２のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【００９９】
その後、NFCリーダ１２からリクエストサービス（Request Service）等のポーリング以外のコマンドが送信された場合、CLF３１は、受信したコマンドに含まれるIDmと、メモリ３１Ａに記憶していたIDmとを比較して、IDmが一致したターゲット候補を、通信対象となる確定ターゲットとして確定する。例えば、NFCリーダ１２からのリクエストサービスにESE３２のIDmが含まれている場合、CLF３１は、ESE３２を確定ターゲットとして確定して、そのリクエストサービスをESE３２に送信する。
【０１００】
IDm比較方式を採用すると、IDmを取得して比較する処理等が加わるものの、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。ただし、ターゲット候補が確定される前に、IDmを含まないコマンドを受け付けることはできない。
【０１０１】
次に、図１３のフローチャートを参照して、確定部１０２により実行されるIDm比較方式による確定処理の流れについて説明する。
【０１０２】
ステップＳ４１において、確定部１０２は、候補選択処理により、ターゲット候補が選択されたか否かを判定する。ステップＳ４１において、ターゲット候補が選択されたと判定された場合、処理は、ステップＳ４２に進められる。
【０１０３】
ステップＳ４２において、確定部１０２は、選択されたターゲット候補のIDmを取得して、メモリ３１Ａに記憶させる（ステップＳ４３）。
【０１０４】
ステップＳ４３の処理が終了すると、ステップＳ４４において、確定部１０２は、無線通信制御部１０４を制御して、NFCリーダ１２からポーリングコマンド以外のコマンドを受信したか否かを判定する。
【０１０５】
ステップＳ４４において、ポーリングコマンド以外のコマンドを受信していないと判定された場合、処理は、ステップＳ４１に戻り、前述した処理が繰り返される。すなわち、ステップＳ４１乃至Ｓ４４が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ３１Ａに記憶される。
【０１０６】
一方、ステップＳ４４において、ポーリングコマンド以外のコマンドを受信したと判定された場合、処理は、ステップＳ４５に進められる。ステップＳ４５において、確定部１０２は、NFCリーダ１２からのポーリングコマンド以外のコマンドに含まれるIDmと、メモリ３１Ａに記憶されているIDmとを比較し、それらのIDmが一致するか否かを判定する（ステップＳ４６）。
【０１０７】
ステップＳ４６において、メモリ３１Ａに記憶されたIDmの中に、コマンドに含まれるIDmと一致するIDmが存在すると判定された場合、処理は、ステップＳ４７に進められる。ステップＳ４７において、確定部１０２は、IDmが一致するターゲット候補を、確定ターゲットとして確定する。例えば、ESE３２のIDmがメモリ３１Ａに記憶されている場合であって、NFCリーダ１２からのリクエストサービスにESE３２のIDmが含まれているとき、ESE３２が確定ターゲットとなる。
【０１０８】
一方、ステップＳ４６において、IDmが一致しないと判定された場合、ステップＳ４７はスキップされる。この場合、通信対象が確定されないため、候補選択処理が継続されることになる。そして、CLF３１は、NFCリーダ１２との通信が続いたとしても、ルートが確定していないため、レスポンスが行われず、そのままの状態に留まることになる。その後、NFCリーダ１２とCLF３１の間の通信が切断されれば、ターゲット候補はリセットされるので、NFCリーダ１２によるポーリングからやり直しとなる。すなわち、NFCリーダ１２との通信が途切れた後、再度、NFCリーダ１２によるポーリングが行われることになる。
【０１０９】
確定ターゲットが確定されるか（ステップＳ４７）、あるいは、IDmが一致しないと判定されると（ステップＳ４６のNo）、図１３の確定処理は終了する。
【０１１０】
以上のように、IDm比較方式を用いて、確定処理を行うことで、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。
【０１１１】
ATR_REQ受信方式は、マルチレスポンス方式又はシングルレスポンス方式において、P2Pアプリ４１としてNFCリーダ１２にレスポンスした後、正しいATR_REQ（属性要求）を受信した場合にはATR_RESを返信して、確定ターゲットを確定する方式である。
【０１１２】
具体的には、図１４に示すように、CLF３１は、NFCリーダ１２からのポーリングコマンドに応じて、候補選択処理を行い、P2Pアプリ４１のポーリングレスポンスを返信する。これにより、P2Pアプリ４１がターゲット候補としてキープされる。
【０１１３】
続いて、NFCリーダ１２から異なるポーリングコマンドが送信された場合、CLF３１は、候補選択処理を行う。CLF３１は、ESE３２からレスポンスがあった場合、ESE３２のIDmを取得して、メモリ３１Ａに記憶する。これにより、ESE３２が候補に加えられ、ターゲット候補として、P2Pアプリ４１とESE３２が選択される。そして、CLF３１は、ESE３２のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【０１１４】
その後、NFCリーダ１２から、ATR_REQが送信された場合、CLF３１は、P2Pアプリ４１を確定ターゲットとして確定して、ATR_RESをNFCリーダ１２に返信する。
【０１１５】
そして、CLF３１は、NFCリーダ１２からのATR_REQに応じて、P2Pアプリ４１を確定ターゲットとして確定する。なお、この場合、ターゲットの確定を目的としてのIDmの比較は行われず、正しいATR_REQの受信によってターゲットが確定されることになる。
【０１１６】
次に、図１５のフローチャートを参照して、確定部１０２により実行されるATR_REQ受信方式による確定処理の流れについて説明する。
【０１１７】
ステップＳ６１乃至Ｓ６３においては、図１３のステップＳ４１乃至Ｓ４３と同様に、確定部１０２によって、選択されたターゲット候補のIDmが取得され、メモリ３１Ａに記憶される。
【０１１８】
ステップＳ６４において、確定部１０２は、無線通信制御部１０４を制御して、NFCリーダ１２からATR_REQを受信したか否かを判定する。
【０１１９】
ステップＳ６４において、ATR_REQを受信していないと判定された場合、処理は、ステップＳ６１に戻り、前述した処理が繰り返される。すなわち、ステップＳ６１乃至Ｓ６４が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ３１Ａに記憶される。
【０１２０】
一方、ステップＳ６４において、ATR_REQを受信したと判定された場合、処理は、ステップＳ６５に進められる。ステップＳ６５において、確定部１０２は、P2Pアプリ４１を確定ターゲットとして確定する。
【０１２１】
P2Pアプリ４１が通信対象として確定されると、図１５の確定処理は終了する。
【０１２２】
以上のように、ATR_REQ受信方式を用いて、確定処理を行うことで、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。
【０１２３】
また、例えば、DH３３上にFALP（FeliCa Ad-hoc Link Protocol）が実装された場合、確定部１０２は、FALP専用のNFCリーダ１２から送信されるPropose Ad-hocコマンドを監視することで、Propose Ad-hocコマンドが受信された場合、強制的に、FALPを確定ターゲットとすることができる。すなわち、確定部１０２によって、NFCリーダ１２から送信されるコマンドが監視され、所定のコマンドである場合には、そのコマンドに対応する所定のターゲットが、強制的に確定ターゲットとされる。
【０１２４】
［解除処理］
次に、図１６乃至図１８を参照して、解除処理について説明する。
【０１２５】
ここでは、解除処理として、強制終了方式、RF消失解除方式、ポーリング受信解除方式、RLS_REQ受信解除方式、及びDSL_REQ受信解除方式の５つの方式について説明する。
【０１２６】
強制終了方式は、DH３３により実行されているアプリケーションが、ユーザ操作により終了された場合、それをトリガとして、DH３３から強制的に確定ターゲットの解除が行われる方式である。
【０１２７】
RF消失解除方式は、NFCリーダ１２とCLF３１の近接通信が切断され、RF（Radio Frequency）信号が消失した場合に、確定ターゲットの解除が行われる方式である。
【０１２８】
ところで、RF消失解除方式では、RF信号のオン／オフのチャタリングが発生した場合に、予期せぬRF信号の消失による通信対象の解除によって、ユーザに不便が生じる場合がある。具体的には、図１６に示すように、NFCリーダ１２とCLF３１の近接通信が行われる場合に、ポーリングの終わりのほうで搬送波が検出されると、RF信号が一瞬オンになった後、通信相手がListenモードになって、RF信号がオフになってしまう。この時点で、RF信号のオフが検出され、確定ターゲットの解除が行われるのは、処理上好ましくない。
【０１２９】
また、図１７に示すように、NFCリーダ１２とCLF３１の近接通信が行われている途中で、RF信号が消失して、解除処理が行われると、その後、NFCリーダ１２とCLF３１の近接通信が復活した場合には、確定ターゲットが解除されているため、CLF３１は、どのターゲットと通信するのかが不明となる。
【０１３０】
そこで、ポーリング受信解除方式では、RF信号の消失後の再接続に対応するために、RF信号が消失した時点では、確定ターゲットの解除を行わず、RF信号の消失後、NFCリーダ１２から、次のポーリングコマンドが受信された時点で、確定ターゲットが解除されるようにする。また、RF信号の消失後に受信したコマンドが、ポーリングコマンドでなければ、RF信号の消失前の経路、すなわち、RF信号の消失前と同一のターゲットとの間で処理が継続されるようにする。
【０１３１】
このポーリング受信解除方式によって、RF信号の消失後の再接続に対応することが可能となる。ポーリング受信解除方式を採用すると、実装面では特別な状態を想定する必要がなくなるので、シンプルな構成とすることができるというメリットがある。
【０１３２】
RLS_REQ受信解除方式は、NFCリーダ１２が、CLF３１との近接通信を完全に終了するときに送信するコマンドであるRLS_REQを利用して、RLS_REQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ４１が確定ターゲットとして確定されている場合であって、RLS_REQが受信されたとき、CLF３１は、P2Pアプリ４１を、確定ターゲットから解除する。
【０１３３】
DSL_REQ受信解除方式は、NFCリーダ１２が、ターゲットをディセレクト状態とする（非活性化する）ときに送信するコマンドであるDSL_REQを利用して、DSL_REQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ４１が確定ターゲットとして確定されている場合であって、DSL_REQが受信されたとき、CLF３１は、P2Pアプリ４１を、確定ターゲットから解除する。
【０１３４】
なお、前述した５つの方式以外のターゲット解除条件を用いて、ターゲットの解除が行われるようにしてもよい。例えば、NFCデバイス１１をリセットするためのデバイスリセットなどの各種の規格で定められたコマンドが受信されたことをターゲット解除条件とすることができる。
【０１３５】
次に、図１８のフローチャートを参照して、解除部１０３により実行される解除処理の流れについて説明する。
【０１３６】
ステップＳ８１において、解除部１０３は、確定ターゲットを解除するための所定の条件であるターゲット解除条件が発生したか否かを判定する。
【０１３７】
例えば、ポーリング受信解除方式におけるRF信号の消失後のポーリングコマンドの受信、RLS_REQ受信解除方式におけるRLS_REQの受信、又はDSL_REQ受信解除方式におけるDSL_REQの受信がターゲット解除条件となるので、それらの解除条件が発生した場合、処理は、ステップＳ８２に進められる。
【０１３８】
ステップＳ８２において、解除部１０３は、例えば、P2Pアプリ４１等の通信対象として確定されていた確定ターゲットを解除する。
【０１３９】
確定ターゲットが解除されると、図１８の解除処理は終了する。
【０１４０】
以上のように、ポーリング受信解除方式、RLS_REQ受信解除方式、又はDSL_REQ受信解除方式を用いて、解除処理を行うことで、例えば、RF信号の消失後の再接続にも対応することが可能となる。
【０１４１】
［ルーティング状態遷移］
図１９は、ルーティングの状態遷移を示す図である。
【０１４２】
図１９において、非選択状態は、ターゲット候補の選択が行われていない状態を表す。また、選択中状態は、NFCリーダ１２からポーリングコマンドを受信して、ターゲット候補が選択されている状態を表す。なお、選択中状態において、通信が切断されてRF信号が消失するか、所定のコマンドが受信された場合、非選択状態に遷移される。
【０１４３】
P2P確定中状態は、選択中状態時にNFCリーダ１２からATR_REQが受信され、P2Pアプリ４１が確定ターゲットとなっている状態を表す。なお、P2P確定中状態において、RF信号が消失したり、NFCリーダ１２からのコマンドRLS_REQやDSL_REQ、CLFを制御するDHから無線通信処理の強制終了を指示するためのコマンドであるDEACTIVATE_CMDが受信された場合、非選択状態に遷移される。
【０１４４】
確定中状態は、選択中状態時に、NFCリーダ１２から、ポーリングコマンドと、ATR_REQ以外のコマンドを受信して、P2Pアプリ４１以外の他のターゲットが確定ターゲットとなっている状態を表す。なお、確定中状態において、所定のコマンドが受信された場合、非選択状態に遷移される。また、確定中状態において、通信が切断されてRF信号が消失した場合、リトライ待機中状態に遷移される。
【０１４５】
リトライ待機中状態は、確定中状態時に、RFが消失したため、リトライを待っている状態を表す。なお、リトライ待機中状態において、RF信号が復活後、ポーリング以外のNFC-Fのコマンドを受信するなどした場合、確定中状態に遷移される。また、リトライ待機中状態において、ポーリングコマンドが受信された場合、選択中状態に遷移される。
【０１４６】
以上のように、ルーティング処理においては、非選択状態、選択中状態、P2P確定中状態、確定中状態、及びリトライ待機中状態のいずれかに状態遷移が行われることで、複数のターゲットの中から、１以上のターゲット候補が選択され、確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、確定ターゲットと、NFCリーダ１２との間で通信が行われる。
【０１４７】
［ユースケースの例］
次に、前述したルーティング処理の具体的例として、ユースケース１乃至３を説明する。図２０は、ユースケース１を説明するためのシーケンス図である。
【０１４８】
ユースケース１は、NFCリーダ１２がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ４１から開始されるケースの例である。
【０１４９】
図２０に示すように、P2Pアプリ専用のNFCリーダ１２からポーリングコマンドが送信されると、CLF３１の候補選択部１０１は、ターゲット候補として、P2Pアプリ４１を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１５０】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信され、そのレスポンスがCLF３１に返される。
【０１５１】
候補選択部１０１は、ESE３２及びUICC３４からのレスポンスに応じて、ESE３２をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。これにより、ターゲット候補として、P2Pアプリ４１とESE３２が選択されたことになる。
【０１５２】
続いて、NFCリーダ１２からコマンドATR_REQが送信されると、CLF３１の確定部１０２によって、P2Pアプリ４１が確定ターゲットとされ、コマンドATR_RESが返信される。これにより、P2Pアプリ専用のNFCリーダ１２とP2Pアプリ４１が、CLF３１を介して、所定のP2Pトランザクション処理を行うことになる。
【０１５３】
そして、P2Pトランザクション処理が終了して、NFCリーダ１２からコマンドDSL_REQが送信されると、CLF３１の解除部１０３によって、P2Pアプリ４１が確定ターゲットから解除され、コマンドDSL_RESが返信される。なお、その後、再度、NFCリーダ１２からポーリングコマンドが送信された場合には、前述した処理が繰り返され、P2Pアプリ４１が、ターゲット候補として選択される。
【０１５４】
以上のように、ユースケース１では、NFCリーダ１２によるポーリングに応じて、P2Pアプリ４１及びESE３２がターゲット候補として選択された段階で、P2Pアプリ４１が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ４１が確定ターゲットから解除されると、NFCリーダ１２によるポーリングが再開され、P2Pアプリ４１及びUICC３４がターゲット候補として選択されることになる。
【０１５５】
すなわち、ユースケース１では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、P2Pアプリ４１、ESE３２、P2Pアプリ４１、UICC３４の順にターゲットが選択され、P2Pアプリ４１が２回に１回選択される。
【０１５６】
図２１は、ユースケース２を説明するためのシーケンス図である。
【０１５７】
ユースケース２は、NFCリーダ１２がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがESE３２から開始されるケースの例である。
【０１５８】
図２１に示すように、P2Pアプリ専用のNFCリーダ１２からポーリングコマンドが送信されると、CLF３１の候補選択部１０１は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信され、そのレスポンスがCLF３１に返される。
【０１５９】
候補選択部１０１は、ESE３２及びUICC３４からのレスポンスに応じて、ESE３２をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１６０】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、ターゲット候補として、P2Pアプリ４１を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。これにより、ターゲット候補として、ESE３２とP2Pアプリ４１が選択されたことになる。
【０１６１】
続いて、NFCリーダ１２からコマンドATR_REQが送信されると、P2Pアプリ４１が確定ターゲットとされる。これにより、P2Pアプリ専用のNFCリーダ１２とP2Pアプリ４１の間では、所定のP2Pトランザクション処理が行われる。そして、P2Pトランザクション処理が終了すると、NFCリーダ１２からコマンドDSL_REQが送信され、P2Pアプリ４１が確定ターゲットから解除される。
【０１６２】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１によって、そのポーリングコマンドがブロードキャスト送信され、ESE３２及びUICC３４によってそれぞれ受信される。そして、UICC３４がターゲット候補に選択され、そのポーリングレスポンスがNFCリーダ１２に返信される。その後、P2Pアプリ４１がターゲット候補に追加され、前述した処理が繰り返されることになる。
【０１６３】
以上のように、ユースケース２では、NFCリーダ１２によるポーリングに応じて、ESE３２及びP2Pアプリ４１がターゲット候補として選択された段階で、P2Pアプリ４１が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ４１が確定ターゲットから解除されると、NFCリーダ１２によるポーリングが再開され、UICC３４及びP2Pアプリ４１がターゲット候補として選択されることになる。
【０１６４】
すなわち、ユースケース２では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、ESE３２、P2Pアプリ４１、UICC３４、P2Pアプリ４１の順にターゲットが選択され、P2Pアプリ４１が２回に１回選択される。
【０１６５】
図２２は、ユースケース３を説明するためのシーケンス図である。
【０１６６】
ユースケース３は、NFCリーダ１２がESE専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ４１から開始されるケースの例である。
【０１６７】
図２２に示すように、ESE専用のNFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ４１に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ４１からESE３２に切り替える。そして、CLF３１の候補選択部１０１は、ポーリングコマンドをブロードキャスト送信する。
【０１６８】
ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信される。このとき、ESE３２からはレスポンスがあったが、UICC３４からは無応答であった場合、候補選択部１０１は、ターゲット候補として、ESE３２を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。なお、ここでは、ターゲット候補として選択されたESE３２のIDmがメモリ３１Ａに記憶される。
【０１６９】
続いて、NFCリーダ１２からリクエストサービス等のポーリング以外のコマンドが送信された場合、確定部１０２は、受信したコマンドに含まれるIDmと、メモリ３１Ａに記憶していたIDmとを比較する。そして、確定部１０２は、IDmが一致するESE３２を確定ターゲットとし、そのリクエストサービスをESE３２に送信する。ESE３２が、リクエストサービスに応じてレスポンスを返信すると、そのレスポンスは、NFCリーダ１２に送信される。これにより、ESE専用のNFCリーダ１２とESE３２が、CLF３１を介して、所定のESEトランザクション処理を行うことになる。
【０１７０】
その後、RF信号が消失した場合、所定のターゲット解除条件を満たすまでは、解除処理は行われず、確定ターゲットが維持される。
【０１７１】
そして、再度、NFCリーダ１２からポーリングコマンドが送信されると、ESE３２が確定ターゲットから解除される。また、候補選択部１０１は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ４１に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ４１からUICC３４に切り替える。また、候補選択部１０１が、そのポーリングコマンドをブロードキャスト送信すると、ESE３２及びUICC３４によってそれぞれ受信され、ESE３２からのみレスポンスが返信される。そこで、候補選択部１０１は、ターゲット候補として、ESE３２を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１７２】
続いて、NFCリーダ１２からリクエストサービスが送信された場合、確定部１０２は、IDmの比較を行い、IDmが一致するESE３２を確定ターゲットとし、そのリクエストサービスをESE３２に送信する。また、ESE３２からのレスポンスは、NFCリーダ１２に送信される。これにより、ESE専用のNFCリーダ１２とESE３２が、CLF３１を介して、所定のESEトランザクション処理を行うことになる。
【０１７３】
以上のように、ユースケース３では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられる。すなわち、NFCリーダ１２によるポーリングに応じて、ターゲット候補を選択する段階で、ポーリングパラメータがチェックされ、P2Pアプリ４１には該当しないので、ESE３２又はUICC３４がターゲット候補として選択される。そして、ポーリングコマンドをブロードキャスト送信して、レスポンスがあったESE３２が確定ターゲットとなり、ESEトランザクション処理が行われる。
【０１７４】
また、RF信号が消失した場合でも、所定のターゲット解除条件を満たすまでは、確定ターゲットが維持されるため、NFCリーダ１２とCLF３１の近接通信が復活した場合に処理を継続することができる。
【０１７５】
なお、図２２の例では、ESE専用のリーダについて説明したが、UICC専用のリーダに対する動作は、基本的に、ESE専用のリーダに対する動作と同一の動作となるため、その説明は省略する。
【０１７６】
このように、スキップ機能を含むP2Pメインのローテーション方式を採用することで、３以上のターゲットのうちの１つのターゲットが、２回に１回、ターゲット候補として選択されるので、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【０１７７】
また、シングルレスポンス方式が用いられることで、CLF３１（フロントエンド）に特別な回路を実装することなく、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【０１７８】
［スキップ機能を含むP2Pメインのローテーション方式の拡張］
図２３は、拡張版のスキップ機能を含むP2Pメインのローテーション方式のターゲット候補遷移図である。
【０１７９】
拡張版のスキップ機能を含むP2Pメインのローテーション方式では、前述した図８を参照して説明したESE３２，UICC３４，P2Pアプリ４１に加えて、DH３３上に実装されるT3T（Type 3 Tag）エミュレーションがローテーションに含まれる。この場合であっても、基本的なローテーションは図８と変らず、ターゲットとなる、P2Pアプリ４１，ESE３２，UICC３４，T3Tのうち、P2Pアプリ４１が２回に１回必ず選択されることになる。
【０１８０】
具体的には、図２３に示すように、ローテーションの順番が、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１，T3T，P2Pアプリ４１の順に行われる。また、前述したように、例えば、P2Pアプリ４１に対するポーリングではない場合には、ローテーションが、P2Pアプリ４１をスキップして、ESE３２、UICC３４、又はT3Tに、強制的に切り替えられる。
【０１８１】
このように、P2Pアプリ４１以外のターゲットが増えても、P2Pアプリ４１を中心にして、P2Pアプリ４１が２回に１回必ず選択されるので、NFCリーダ１２では、確実にP2Pアプリ４１に対する動作が行われることになる。
【０１８２】
［本技術を適用したコンピュータの説明］
前述した一連の処理は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
【０１８３】
そこで、図２４は、前述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示している。
【０１８４】
プログラムは、コンピュータ２００に内蔵されているハードディスク等の記憶部２０８やROM(Read Only Memory)２０２に予め記録しておくことができる。
【０１８５】
あるいはまた、プログラムは、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブルメディア２１１に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブルメディア２１１は、いわゆるパッケージソフトウエアとして提供することができる。
【０１８６】
なお、プログラムは、前述したようなリムーバブルメディア２１１からコンピュータ２００にインストールする他、ダウンロードサイトから、デジタル衛星放送用の人工衛星を介して、コンピュータ２００に無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータ２００に有線で転送し、コンピュータ２００では、そのようにして転送されてくるプログラムを、通信部２０９で受信し、記憶部２０８にインストールすることができる。
【０１８７】
コンピュータ２００は、CPU(Central Processing Unit)２０１を内蔵している。CPU２０１には、バス２０４を介して、入出力インタフェース２０５が接続されており、CPU２０１は、入出力インタフェース２０５を介して、ユーザによって、キーボードや、マウス、マイク等で構成される入力部２０６が操作等されることにより指令が入力されると、それに従って、ROM２０２に格納されているプログラムを実行する。あるいは、また、CPU２０１は、記憶部２０８に格納されているプログラム、衛星若しくはネットワークから転送され、通信部２０９で受信されて記憶部２０８にインストールされたプログラム、又はドライブ２１０に装着されたリムーバブルメディア２１１から読み出されて記憶部２０８にインストールされたプログラムを、RAM(Random Access Memory)２０３にロードして実行する。これにより、CPU２０１は、前述したフローチャートにしたがった処理、あるいは前述したブロック図の構成により行われる処理を行う。そして、CPU２０１は、その処理結果を、必要に応じて、例えば、入出力インタフェース２０５を介して、LCD(Liquid Crystal Display)やスピーカ等で構成される出力部２０７から出力、あるいは、通信部２０９から送信、さらには、記憶部２０８に記録等させる。
【０１８８】
ここで、本明細書において、コンピュータ２００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
【０１８９】
また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。
【０１９０】
また、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０１９１】
さらに、本技術は、以下の構成とすることも可能である。
【０１９２】
［１］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備え、
前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
通信装置。
［２］
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する
［１］に記載の通信装置。
［３］
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである
［１］又は［２］に記載の通信装置。
［４］
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる
［３］に記載の通信装置。
［５］
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する
［１］乃至［４］のいずれかに記載の通信装置。
［６］
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
［５］に記載の通信装置。
［７］
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
［５］に記載の通信装置。
［８］
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
［５］乃至［７］のいずれかに記載の通信装置。
［９］
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する
［８］に記載の通信装置。
［１０］
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する
［８］に記載の通信装置。
［１１］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御方法であって、
前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む制御方法。
［１２］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御用のプログラムであって、
前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
【符号の説明】
【０１９３】
１１ NFCデバイス， １２ NFCリーダ， ３１ CLF， ３１Ａ メモリ， ３２ ESE， ３３ DH， ３４ UICC， ４１ P2Pアプリ， １０１ 候補選択部， １０２ 確定部， １０３ 解除部， １０４ 無線通信制御部， ２００ コンピュータ， ２０１ CPU
【技術分野】
【０００１】
本技術は、通信装置、制御方法、及びプログラムに関し、特に、迅速に通信を確立することができるようにした通信装置、制御方法、及びプログラムに関する。
【背景技術】
【０００２】
無線通信の規格として、NFC（Near Field Communication）が知られている。NFC規格に対応したNFCデバイスでは、端末内に複数の通信対象（以下、ターゲットという）が同時に存在する場合が想定される。
【０００３】
本出願人は、NFCデバイスとして、ターゲットとしての複数のセキュアエレメントと、それらのセキュアエレメントに共通に使用され、リーダ等の外部装置と近接通信するフロントエンドとを備え、フロントエンドが、起動時に、複数のセキュアエレメントに対して通信のための異なるタイムスロットを割り当てるものを先に提案している（例えば、特許文献１参照）。
【０００４】
図１に示すように、NFCの無線通信を行う非接触無線チップ（CLF：Contactless Front End）（以下、フロントエンドともいう）と、リーダ（reader）が近接通信を行う場合、シングルレスポンスとマルチレスポンスの２つの方式がある。
【０００５】
シングルレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが１つのポーリングレスポンスを返すので、リーダは、そのポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、シングルレスポンス方式では、特別な回路を設けることなく実装できるというメリットがある反面、マルチレスポンス方式と比べてターゲットの正答率(「リーダに対して、リーダが望むターゲットからのレスポンスを応答できる確率」を意味するものであり、以下、正答率という)が低くなってしまう。
【０００６】
一方、マルチレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが複数のポーリングレスポンスを返すので、リーダは、複数レスポンス受信に対応していれば、複数のポーリングレスポンスの中から選択された所望のポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、マルチレスポンス方式は、一度に複数のレスポンスを返信するための特別な回路をフロントエンドに設ける必要があって実装面が複雑になる反面、シングルレスポンス方式と比べてターゲットの正答率を高くすることができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−４９７７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、図２に示すように、フロントエンドがマルチレスポンス方式の機能を有する場合であっても、例えば３つのポーリングレスポンスを返したいときに、２つのタイムスロットしかないと、スロット不足のため、一度にポーリングレスポンスを返信することができなくなる。このように、マルチレスポンス方式では、スロット数が多ければ、ポーリングスロットを全て返信することが可能となるが、リーダが、TSN=0,1など、小さいTSN（Time Slot Number）によりポーリングしてきた場合に、スロット数が不足してしまい、全てのポーリングレスポンスを返せなくなるときがある。
【０００９】
また、マルチレスポンス方式を利用するためには、特別な回路をフロントエンドに設ける必要があるため、マルチレスポンス方式に対応してない既存のデバイスだと、特別な回路を実装する必要が出てくる。
【００１０】
また、あるNFCのリーダ動作規格によると、リーダは２回のポーリングを行い、２回のうちどちらかに、P2P（Peer to Peer）のアプリケーションからのレスポンスがあれば、P2Pのアプリケーションの動作を進めることができる、という動作仕様が定義されており、この動作仕様に対応する必要がある。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、上記のリーダの動作仕様に対応し、かつ、フロントエンドに特別な回路を実装することなく、リーダが所望とするターゲットを確実に選択して、迅速に通信を確立することができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の通信装置は、それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する。
【００１３】
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する。
【００１４】
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである。
【００１５】
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる。
【００１６】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する。
【００１７】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。
【００１８】
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。
【００１９】
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する。
【００２０】
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する。
【００２１】
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する。
【００２２】
通信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
【００２３】
本技術の一側面の制御方法又はプログラムは、前述した本技術の一側面の通信装置に対応する制御方法又はプログラムである。
【００２４】
本技術の一側面の通信装置、制御方法、及びプログラムにおいては、それぞれが所定の処理を実行する複数のターゲットの中から、外部装置の通信対象となる確定ターゲットが選択され、外部装置との近接通信が行われる。また、確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットが２回に１回選択される。
【発明の効果】
【００２５】
本技術の一側面によれば、迅速に通信を確立することができる。
【図面の簡単な説明】
【００２６】
【図１】近接通信の方式を説明する図である。
【図２】マルチレスポンス方式における応答条件の例を示す図である。
【図３】NFCデバイスの構成例を示す図である。
【図４】CLFの詳細な構成例を示す図である。
【図５】ルーティング処理を説明するフローチャートである。
【図６】シンプルローテーション方式の候補遷移図である。
【図７】スキップ機能を含むシンプルローテーション方式の候補遷移図である。
【図８】スキップ機能を含むP2Pメインのローテーション方式の候補遷移図である。
【図９】ブロードキャスト送信を説明するシーケンス図である。
【図１０】ブロードキャスト送信を、スキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合の候補遷移図である。
【図１１】候補選択処理の流れを説明するフローチャートである。
【図１２】IDm比較方式を説明するシーケンス図である。
【図１３】IDm比較方式による確定処理の流れを説明するフローチャートである。
【図１４】ATR_REQ受信方式を説明するシーケンス図である。
【図１５】ATR_REQ受信方式による確定処理の流れを説明するフローチャートである。
【図１６】RF信号の消失によるターゲットの解除を説明する図である。
【図１７】RF信号が消失して復活した場合を説明するシーケンス図である。
【図１８】解除処理の流れを説明するフローチャートである。
【図１９】ルーティングの状態遷移図である。
【図２０】ユースケース１を説明するシーケンス図である。
【図２１】ユースケース２を説明するシーケンス図である。
【図２２】ユースケース３を説明するシーケンス図である。
【図２３】拡張版のスキップ機能を含むP2Pメインのローテーション方式の候補遷移図である。
【図２４】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照しながら本技術の実施の形態について説明する。
【００２８】
［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（Peer to Peer）のアプリケーションであるP2Pアプリ４１を実行する。なお、P2Pアプリ４１は、１又は複数実行可能とされる。
【００３５】
UICC（Universal Integrated Circuit Card）３４は、例えば、SIM（Subscriber Identity Module）カードから構成される。UICC３４は、NFCアプリケーションを実行することで、例えば、電子決済機能を実現する。
【００３６】
このように、ESE３２、UICC３４、及びP2Pアプリ４１は、NFCリーダ１２の通信対象となるターゲットであって、それぞれが所定の処理を行う。換言すれば、ターゲットには、ESE３２やUICC３４などのデバイスと、P2Pアプリ４１などのアプリケーションが含まれることになる。
【００３７】
NFCデバイス１１は、以上のように構成される。
【００３８】
［CLFの詳細な構成例］
図４は、図３のCLF３１の詳細な構成例を示す図である。
【００３９】
CLF３１は、候補選択部１０１、確定部１０２、解除部１０３、及び無線通信制御部１０４から構成される。
【００４０】
候補選択部１０１は、所定の規則に従って、NFCリーダ１２の通信対象となるターゲットの候補（以下、ターゲット候補という）を選択する候補選択処理を行う。候補選択処理が行われることで、ターゲット候補として、１又は複数のターゲットが選択される。
【００４１】
確定部１０２は、所定の規則に従って、候補選択処理によりターゲット候補として選択されたターゲットを確定する確定処理を行う。確定処理が行われることで、ターゲット候補として選択されたターゲットのうち、NFCリーダ１２の通信対象となるターゲット（以下、確定ターゲットという）が確定される。
【００４２】
解除部１０３は、所定の規則に従って、確定処理により確定されたターゲットを解除する解除処理を行う。解除処理が行われることで、確定ターゲットがNFCリーダ１２の通信対象から解除される。
【００４３】
無線通信制御部１０４は、NFCリーダ１２との間で行われる近接通信を制御するための処理を行う。
【００４４】
CLF３１は、以上のように構成される。
【００４５】
［ルーティング処理］
次に、図５のフローチャートを参照して、CLF３１により実行されるルーティング処理について説明する。
【００４６】
ステップＳ１において、候補選択部１０１は、候補選択処理を行う。この候補選択処理によって、複数のターゲットの中から、１以上のターゲットが、ターゲット候補として選択される。
【００４７】
なお、候補選択処理の詳細は、図６乃至図１１を参照して後述する。
【００４８】
ステップＳ２において、確定部１０２は、確定処理を行う。この確定処理によって、ターゲット候補として選択された１以上のターゲットの中から、NFCリーダ１２の通信対象となる確定ターゲットが確定される。
【００４９】
なお、確定処理の詳細は、図１２乃至図１５を参照して後述する。
【００５０】
ステップＳ３において、解除部１０３は、解除処理を行う。この解除処理によって、確定ターゲットがNFCリーダ１２の通信対象から解除される。すなわち、一旦、通信対象として確定された確定ターゲットは、解除処理が行われ、通信対象から解除されるまで、NFCリーダ１２の通信対象となる。
【００５１】
なお、解除処理の詳細は、図１６乃至図１８を参照して後述する。また、規格によっては、解除処理を行う必要のない規格もあるが、その場合にはステップＳ３の処理は省略される。
【００５２】
以上で、ルーティング処理の説明を終了する。
【００５３】
前述したルーティング処理によれば、複数のターゲットの中から、１以上のターゲット候補が選択され、選択された１以上のターゲットの中から、NFCリーダ１２の通信対象となる確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、通信対象として確定された確定ターゲットと、NFCリーダ１２との間で通信が行われる。
【００５４】
［候補選択処理］
次に、図６乃至図１１を参照して、図５のステップＳ１に対応する候補選択処理について説明する。
【００５５】
ここでは、候補選択処理として、固定ターゲット方式、シンプルローテーション方式、スキップ機能を含むシンプルローテーション方式、及び、スキップ機能を含むP2Pメインのローテーション方式の４つの方式について説明する。
【００５６】
固定ターゲット方式は、アプリケーションから特に選択されない限り、デフォルトで設定されたターゲットが常に選択される方式である。
【００５７】
固定ターゲット方式を採用すると、実装面では極めてシンプルになるというメリットがある反面、ターゲット候補の選択時の正答率が悪くなるというデメリットもある。例えば、ターゲットをESE３２に固定してしまうと、ユーザの事前設定なしには、P2Pアプリ４１やUICC３４などのアプリケーションを動作させることができなくなる。
【００５８】
シンプルローテーション方式は、ターゲット候補を順次変更することで、ターゲットを選択する方式である。CLF３１は、NFCリーダ１２からポーリングされる度に、異なるターゲット候補を選択して、選択されたターゲットからのレスポンスを返信する。
【００５９】
具体的には、図６に示すように、例えば、最初のポーリングではESE３２がターゲット候補として選択され、その後、ポーリングされるごとにローテーションが行われ、UICC３４、P2Pアプリ４１、ESE３２、・・・が順次、ターゲット候補として選択される。
【００６０】
シンプルローテーション方式を採用すると、実装面ではシンプルになるというメリットがある反面、所望のターゲットを選択するためにポーリングのリトライを繰り返す場合が出てくるため、ターゲット候補の選択時の正答率は上がらないというデメリットがある。
【００６１】
スキップ機能を含むシンプルローテーション方式は、前述したシンプルローテーションに加えて、あるターゲットが、対象外であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する方式である。CLF３１は、NFCリーダ１２からポーリングされる度に、そのポーリングパラメータをチェックして、対象外となるターゲットを判定する。そして、対象外のターゲット候補であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する。
【００６２】
具体的には、図７に示すように、例えば、ポーリングパラメータのSC（System Code）が"FFFF"ではない場合、又はRC（Request Code）="1"の場合、そのポーリングは、P2Pアプリ４１に対するものではないため、ターゲット候補を、UICC３４からESE３２に切り替える。すなわち、前述したシンプルローテーションであると、UICC３４の次はP2Pアプリ４１がターゲット候補となるところ、P2Pアプリ４１がスキップされ、ターゲット候補がESE３２に強制的に切り替えられることになる。
【００６３】
スキップ機能を含むシンプルローテーションを採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、所定の規則により対象外となるターゲットを特定して非選択とすることで、ターゲット候補の選択時の正答率も向上させることができる。
【００６４】
スキップ機能を含むP2Pメインのローテーション方式は、前述したスキップ機能を含むシンプルローテーションを、P2Pアプリ４１を中心に行う方式である。
【００６５】
具体的には、図８に示すように、ローテーションの順番が、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順に行われる。これは、あるNFCのリーダ動作規格によると、NFCリーダ１２は２回のポーリングを行い、２回のうちどちらかにP2Pアプリ４１からのレスポンスがあれば、P2P動作を進めることができる、という動作仕様が定義されており、これに対応するため、２回に１回は必ず、P2Pアプリ４１のレスポンスが返信されるようにしたものである。
【００６６】
これにより、ターゲットとなる、P2Pアプリ４１，ESE３２，UICC３４のうち、P2Pアプリ４１が２回に１回必ず選択されるので、NFCリーダ１２では、確実にP2Pアプリ４１に対する動作が行われることになる。また、スキップ機能を含むシンプルローテーション方式と同様に、例えば、P2Pアプリ４１に対するポーリングではない場合には、ローテーションが、P2Pアプリ４１をスキップして、ターゲット候補がESE３２又はUICC３４に、強制的に切り替えられる。
【００６７】
なお、図８の例では、P2Pアプリ４１が２回に１回必ずターゲット候補として選択されるとして説明したが、NFCリーダ１２側の動作の規則に応じて、P2Pアプリ４１以外の他のターゲットが２回に１回、ターゲット候補として選択されるようにしてもよい。すなわち、３以上のターゲットのうちの１つのターゲットが、２回に１回、ターゲット候補として選択されるようにすることで、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【００６８】
スキップ機能を含むP2Pメインのローテーション方式を採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。また、NFCリーダ１２側の動作の規則に応じて、所定のターゲットが優先的に選択されるので、NFCリーダ１２側の動作との整合をとることができる。
【００６９】
また、CLF３１は、NFCリーダ１２から受信したポーリングコマンドを、ターゲットに送信する場合、ユニキャスト又はブロードキャストにより送信することができる。
【００７０】
ユニキャストでは、現時点で、ターゲット候補となっているターゲットにのみ、ポーリングコマンドが送信される。そのため、ユニキャスト送信を行う場合には、実装面ではシンプルとなるが、ターゲット候補の選択時の正答率の向上には寄与しないこととなる。
【００７１】
一方、ブロードキャストでは、ターゲット候補となっているターゲットであるか否かに関係なく、複数のターゲットにポーリングコマンドが送信される。
【００７２】
具体的には、図９に示すように、例えば、ESE３２がターゲット候補となっている場合に、NFCリーダ１２がUICC３４に対するSCを指定してポーリングコマンドを送信してきたとき、CLF３１は、ポーリングコマンドを、ESE３２とUICC３４の両方にブロードキャストで送信する。これにより、ESE３２からは無応答となるが、UICC３４からはレスポンスがあるため、ターゲット候補を、ESE３２からUICC３４に切り替えて、NFCリーダ１２に返信することができる。すなわち、ブロードキャスト送信を行う場合には、実装面ではユニキャストに比べて複雑になるが、ターゲット候補の選択時の正答率の大幅な向上が見込まれる。
【００７３】
図１０は、図９で説明したブロードキャスト送信を、図８で説明したスキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合のターゲット候補遷移図である。
【００７４】
前述したように、スキップ機能を含むP2Pメインのローテーション方式では、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にローテーションされる。それに対して、ブロードキャスト送信が組み込まれると、P2Pアプリ４１からESE３２又はUICC３４にターゲット候補が遷移する際に、ブロードキャスト送信に対するレスポンスに応じて、ESE３２又はUICC３４にターゲット候補が遷移する。
【００７５】
例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１の順に候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC３４からは無応答であったが、ESE３２からレスポンスがあった場合、UICC３４ではなく、ESE３２がターゲット候補とされる。そして、P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にターゲット候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC３４からレスポンスがあったが、ESE３２からは無応答であった場合、ESE３２ではなく、UICC３４がターゲット候補とされ、その後、P2Pアプリ４１に候補が遷移される。
【００７６】
すなわち、ブロードキャスト送信を、スキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１，UICC３４，P2Pアプリ４１の順にローテーションされる。
【００７７】
このように、３以上のターゲットのうちの１つのターゲットが、２回に１回選択されるようにターゲット候補を選択するだけでなく、ブロードキャスト送信することで、２回に１回選択されるターゲット以外のターゲットの正答率を、さらに向上させることができる。その結果、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【００７８】
次に、図１１のフローチャートを参照して、候補選択部１０１により実行される、図５のステップＳ１に対応する候補選択処理の流れについて説明する。
【００７９】
なお、図１１では、候補選択処理として最も効率がよい方式となる、スキップ機能を含むP2Pメインのローテーション方式による候補選択処理について説明する。
【００８０】
ステップＳ２１において、候補選択部１０１は、初期設定を行う。この初期設定としては、例えば、P2Pアプリ４１からローテーションを開始するか否かに応じて、変数i=0又は1がセットされる。
【００８１】
ステップＳ２２において、候補選択部１０１は、無線通信制御部１０４を制御して、NFCリーダ１２からポーリングコマンドを受信したか否かを判定する。ステップＳ２２において、ポーリングコマンドを受信したと判定された場合、処理は、ステップＳ２３に進められる。
【００８２】
ステップＳ２３において、候補選択部１０１は、NFCリーダ１２からのポーリングコマンドに含まれるポーリングパラメータに基づいて、P2Pアプリ４１がターゲット候補の対象外となるか否かを判定する。ここでは、前述したように、例えば、ポーリングパラメータが、SC="FFFF"ではない場合、又はRC="1"の場合、そのポーリングは、P2Pアプリ４１に対するものではないことになる。
【００８３】
なお、ここでは、P2Pアプリ４１がターゲット候補の対象外となる例を説明したが、ポーリングパラメータに応じて、P2Pアプリ４１以外の他のターゲットが対象外となるようにしてもよい。
【００８４】
ステップＳ２３において、P2Pアプリ４１がターゲット候補の対象外であると判定された場合、処理は、ステップＳ２４に進められる。ステップＳ２４において、候補選択部１０１は、P2Pアプリ４１以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE３２又はUICC３４がターゲット候補として選択される。
【００８５】
一方、ステップＳ２３において、P2Pアプリ４１がターゲット候補の対象であると判定された場合、処理は、ステップＳ２５に進められる。ステップＳ２５において、候補選択部１０１は、変数iの値が偶数であるか否かを判定する。
【００８６】
ステップＳ２５において、変数iの値が偶数であると判定された場合、処理は、ステップＳ２６に進められる。ステップＳ２６において、候補選択部１０１は、P2Pアプリ４１を、ターゲット候補として選択する。
【００８７】
一方、ステップＳ２５において、変数iの値が奇数であると判定された場合、処理は、ステップＳ２４に進められる。ステップＳ２４において、候補選択部１０１は、P2Pアプリ４１以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE３２又はUICC３４がターゲット候補として選択される。また、このとき、ESE３２及びUICC３４に対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を向上させることができるのは、図９を参照して前述した通りである。
【００８８】
ステップＳ２４又はＳ２６が終了すると、処理は、ステップＳ２７に進められる。ステップＳ２７において、候補選択部１０１は、変数iの値を1インクリメントする。これにより、次のステップＳ２５の判定処理では、偶数と奇数が逆になるので、判定結果も逆になり、直近で、P2Pアプリ４１がターゲット候補として選択された場合には、次は、P2Pアプリ４１以外の他のターゲットが選択されることになる。その逆に、P2Pアプリ４１以外の他のターゲットが直近で選択された場合には、次は、P2Pアプリ４１がターゲット候補として選択されることになる。
【００８９】
ステップＳ２７の処理が終了すると、ステップＳ２８において、候補選択部１０１は、ターゲット候補の選択が終了したか否かを判定する。
【００９０】
ステップＳ２８において、ターゲット候補の選択が終了していないと判定された場合、処理は、ステップＳ２２に戻り、前述した処理が繰り返される。すなわち、ターゲット候補の選択が終了したと判定されるまで（ステップＳ２８のYes）、ステップＳ２２乃至Ｓ２８の処理が繰り返され、ターゲット候補として、P2Pアプリ４１が２回に１回選択されることになる。ただし、前述の通り、例えば、P2Pアプリ４１に対するポーリングではない場合には、ESE３２又はUICC３４が、ターゲット候補として強制的に選択される。
【００９１】
そして、ステップＳ２８において、ターゲット候補の選択が終了したと判定された場合、図１１の候補選択処理は終了する。
【００９２】
以上のように、スキップ機能を含むP2Pメインのローテーション方式を用いて、候補選択処理を行うことで、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。
【００９３】
また、NFCリーダ１２側の動作の規則に合わせて、P2Pアプリ４１等の所定のターゲットが優先的に選択されるので、NFCリーダ１２側の動作との整合をとることができる。さらに、所定のターゲット以外の複数のターゲットに対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を大幅に向上させることができる。
【００９４】
［確定処理］
次に、図１２乃至図１５を参照して、図５のステップＳ２に対応する確定処理について説明する。
【００９５】
ここでは、確定処理として、IDm比較方式及びATR_REQ受信方式の２つの方式について説明する。
【００９６】
IDm比較方式は、シングルレスポンス方式において、NFCリーダ１２からCLF３１に対して、複数回のポーリングが行われる場合に、CLF３１が各ポーリングに対して、ICチップの固有のIDであるIDmを用いて、異なるポーリングレスポンスを返すことにより、擬似的にマルチレスポンスを行う方式である。
【００９７】
具体的には、図１２に示すように、CLF３１は、NFCリーダ１２からのポーリングコマンドに応じて、候補選択処理を行う。CLF３１は、UICC３４からレスポンスがあった場合、UICC３４のIDmを取得して、メモリ３１Ａに記憶する。これにより、UICC３４がターゲット候補としてキープされる。そして、CLF３１は、UICC３４のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【００９８】
続いて、NFCリーダ１２から異なるポーリングコマンドが送信された場合、CLF３１は、候補選択処理を行う。CLF３１は、ESE３２からレスポンスがあった場合、ESE３２のIDmを取得して、メモリ３１Ａに記憶する。これにより、ESE３２が候補に加えられ、ターゲット候補として、UICC３４とESE３２が選択される。そして、CLF３１は、ESE３２のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【００９９】
その後、NFCリーダ１２からリクエストサービス（Request Service）等のポーリング以外のコマンドが送信された場合、CLF３１は、受信したコマンドに含まれるIDmと、メモリ３１Ａに記憶していたIDmとを比較して、IDmが一致したターゲット候補を、通信対象となる確定ターゲットとして確定する。例えば、NFCリーダ１２からのリクエストサービスにESE３２のIDmが含まれている場合、CLF３１は、ESE３２を確定ターゲットとして確定して、そのリクエストサービスをESE３２に送信する。
【０１００】
IDm比較方式を採用すると、IDmを取得して比較する処理等が加わるものの、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。ただし、ターゲット候補が確定される前に、IDmを含まないコマンドを受け付けることはできない。
【０１０１】
次に、図１３のフローチャートを参照して、確定部１０２により実行されるIDm比較方式による確定処理の流れについて説明する。
【０１０２】
ステップＳ４１において、確定部１０２は、候補選択処理により、ターゲット候補が選択されたか否かを判定する。ステップＳ４１において、ターゲット候補が選択されたと判定された場合、処理は、ステップＳ４２に進められる。
【０１０３】
ステップＳ４２において、確定部１０２は、選択されたターゲット候補のIDmを取得して、メモリ３１Ａに記憶させる（ステップＳ４３）。
【０１０４】
ステップＳ４３の処理が終了すると、ステップＳ４４において、確定部１０２は、無線通信制御部１０４を制御して、NFCリーダ１２からポーリングコマンド以外のコマンドを受信したか否かを判定する。
【０１０５】
ステップＳ４４において、ポーリングコマンド以外のコマンドを受信していないと判定された場合、処理は、ステップＳ４１に戻り、前述した処理が繰り返される。すなわち、ステップＳ４１乃至Ｓ４４が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ３１Ａに記憶される。
【０１０６】
一方、ステップＳ４４において、ポーリングコマンド以外のコマンドを受信したと判定された場合、処理は、ステップＳ４５に進められる。ステップＳ４５において、確定部１０２は、NFCリーダ１２からのポーリングコマンド以外のコマンドに含まれるIDmと、メモリ３１Ａに記憶されているIDmとを比較し、それらのIDmが一致するか否かを判定する（ステップＳ４６）。
【０１０７】
ステップＳ４６において、メモリ３１Ａに記憶されたIDmの中に、コマンドに含まれるIDmと一致するIDmが存在すると判定された場合、処理は、ステップＳ４７に進められる。ステップＳ４７において、確定部１０２は、IDmが一致するターゲット候補を、確定ターゲットとして確定する。例えば、ESE３２のIDmがメモリ３１Ａに記憶されている場合であって、NFCリーダ１２からのリクエストサービスにESE３２のIDmが含まれているとき、ESE３２が確定ターゲットとなる。
【０１０８】
一方、ステップＳ４６において、IDmが一致しないと判定された場合、ステップＳ４７はスキップされる。この場合、通信対象が確定されないため、候補選択処理が継続されることになる。そして、CLF３１は、NFCリーダ１２との通信が続いたとしても、ルートが確定していないため、レスポンスが行われず、そのままの状態に留まることになる。その後、NFCリーダ１２とCLF３１の間の通信が切断されれば、ターゲット候補はリセットされるので、NFCリーダ１２によるポーリングからやり直しとなる。すなわち、NFCリーダ１２との通信が途切れた後、再度、NFCリーダ１２によるポーリングが行われることになる。
【０１０９】
確定ターゲットが確定されるか（ステップＳ４７）、あるいは、IDmが一致しないと判定されると（ステップＳ４６のNo）、図１３の確定処理は終了する。
【０１１０】
以上のように、IDm比較方式を用いて、確定処理を行うことで、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。
【０１１１】
ATR_REQ受信方式は、マルチレスポンス方式又はシングルレスポンス方式において、P2Pアプリ４１としてNFCリーダ１２にレスポンスした後、正しいATR_REQ（属性要求）を受信した場合にはATR_RESを返信して、確定ターゲットを確定する方式である。
【０１１２】
具体的には、図１４に示すように、CLF３１は、NFCリーダ１２からのポーリングコマンドに応じて、候補選択処理を行い、P2Pアプリ４１のポーリングレスポンスを返信する。これにより、P2Pアプリ４１がターゲット候補としてキープされる。
【０１１３】
続いて、NFCリーダ１２から異なるポーリングコマンドが送信された場合、CLF３１は、候補選択処理を行う。CLF３１は、ESE３２からレスポンスがあった場合、ESE３２のIDmを取得して、メモリ３１Ａに記憶する。これにより、ESE３２が候補に加えられ、ターゲット候補として、P2Pアプリ４１とESE３２が選択される。そして、CLF３１は、ESE３２のIDmを含むポーリングレスポンスを、NFCリーダ１２に返信する。
【０１１４】
その後、NFCリーダ１２から、ATR_REQが送信された場合、CLF３１は、P2Pアプリ４１を確定ターゲットとして確定して、ATR_RESをNFCリーダ１２に返信する。
【０１１５】
そして、CLF３１は、NFCリーダ１２からのATR_REQに応じて、P2Pアプリ４１を確定ターゲットとして確定する。なお、この場合、ターゲットの確定を目的としてのIDmの比較は行われず、正しいATR_REQの受信によってターゲットが確定されることになる。
【０１１６】
次に、図１５のフローチャートを参照して、確定部１０２により実行されるATR_REQ受信方式による確定処理の流れについて説明する。
【０１１７】
ステップＳ６１乃至Ｓ６３においては、図１３のステップＳ４１乃至Ｓ４３と同様に、確定部１０２によって、選択されたターゲット候補のIDmが取得され、メモリ３１Ａに記憶される。
【０１１８】
ステップＳ６４において、確定部１０２は、無線通信制御部１０４を制御して、NFCリーダ１２からATR_REQを受信したか否かを判定する。
【０１１９】
ステップＳ６４において、ATR_REQを受信していないと判定された場合、処理は、ステップＳ６１に戻り、前述した処理が繰り返される。すなわち、ステップＳ６１乃至Ｓ６４が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ３１Ａに記憶される。
【０１２０】
一方、ステップＳ６４において、ATR_REQを受信したと判定された場合、処理は、ステップＳ６５に進められる。ステップＳ６５において、確定部１０２は、P2Pアプリ４１を確定ターゲットとして確定する。
【０１２１】
P2Pアプリ４１が通信対象として確定されると、図１５の確定処理は終了する。
【０１２２】
以上のように、ATR_REQ受信方式を用いて、確定処理を行うことで、CLF３１に対して、複数回ポーリングコマンドを送信してくるNFCリーダ１２に対しては、ターゲットの正答率を向上させることができる。
【０１２３】
また、例えば、DH３３上にFALP（FeliCa Ad-hoc Link Protocol）が実装された場合、確定部１０２は、FALP専用のNFCリーダ１２から送信されるPropose Ad-hocコマンドを監視することで、Propose Ad-hocコマンドが受信された場合、強制的に、FALPを確定ターゲットとすることができる。すなわち、確定部１０２によって、NFCリーダ１２から送信されるコマンドが監視され、所定のコマンドである場合には、そのコマンドに対応する所定のターゲットが、強制的に確定ターゲットとされる。
【０１２４】
［解除処理］
次に、図１６乃至図１８を参照して、解除処理について説明する。
【０１２５】
ここでは、解除処理として、強制終了方式、RF消失解除方式、ポーリング受信解除方式、RLS_REQ受信解除方式、及びDSL_REQ受信解除方式の５つの方式について説明する。
【０１２６】
強制終了方式は、DH３３により実行されているアプリケーションが、ユーザ操作により終了された場合、それをトリガとして、DH３３から強制的に確定ターゲットの解除が行われる方式である。
【０１２７】
RF消失解除方式は、NFCリーダ１２とCLF３１の近接通信が切断され、RF（Radio Frequency）信号が消失した場合に、確定ターゲットの解除が行われる方式である。
【０１２８】
ところで、RF消失解除方式では、RF信号のオン／オフのチャタリングが発生した場合に、予期せぬRF信号の消失による通信対象の解除によって、ユーザに不便が生じる場合がある。具体的には、図１６に示すように、NFCリーダ１２とCLF３１の近接通信が行われる場合に、ポーリングの終わりのほうで搬送波が検出されると、RF信号が一瞬オンになった後、通信相手がListenモードになって、RF信号がオフになってしまう。この時点で、RF信号のオフが検出され、確定ターゲットの解除が行われるのは、処理上好ましくない。
【０１２９】
また、図１７に示すように、NFCリーダ１２とCLF３１の近接通信が行われている途中で、RF信号が消失して、解除処理が行われると、その後、NFCリーダ１２とCLF３１の近接通信が復活した場合には、確定ターゲットが解除されているため、CLF３１は、どのターゲットと通信するのかが不明となる。
【０１３０】
そこで、ポーリング受信解除方式では、RF信号の消失後の再接続に対応するために、RF信号が消失した時点では、確定ターゲットの解除を行わず、RF信号の消失後、NFCリーダ１２から、次のポーリングコマンドが受信された時点で、確定ターゲットが解除されるようにする。また、RF信号の消失後に受信したコマンドが、ポーリングコマンドでなければ、RF信号の消失前の経路、すなわち、RF信号の消失前と同一のターゲットとの間で処理が継続されるようにする。
【０１３１】
このポーリング受信解除方式によって、RF信号の消失後の再接続に対応することが可能となる。ポーリング受信解除方式を採用すると、実装面では特別な状態を想定する必要がなくなるので、シンプルな構成とすることができるというメリットがある。
【０１３２】
RLS_REQ受信解除方式は、NFCリーダ１２が、CLF３１との近接通信を完全に終了するときに送信するコマンドであるRLS_REQを利用して、RLS_REQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ４１が確定ターゲットとして確定されている場合であって、RLS_REQが受信されたとき、CLF３１は、P2Pアプリ４１を、確定ターゲットから解除する。
【０１３３】
DSL_REQ受信解除方式は、NFCリーダ１２が、ターゲットをディセレクト状態とする（非活性化する）ときに送信するコマンドであるDSL_REQを利用して、DSL_REQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ４１が確定ターゲットとして確定されている場合であって、DSL_REQが受信されたとき、CLF３１は、P2Pアプリ４１を、確定ターゲットから解除する。
【０１３４】
なお、前述した５つの方式以外のターゲット解除条件を用いて、ターゲットの解除が行われるようにしてもよい。例えば、NFCデバイス１１をリセットするためのデバイスリセットなどの各種の規格で定められたコマンドが受信されたことをターゲット解除条件とすることができる。
【０１３５】
次に、図１８のフローチャートを参照して、解除部１０３により実行される解除処理の流れについて説明する。
【０１３６】
ステップＳ８１において、解除部１０３は、確定ターゲットを解除するための所定の条件であるターゲット解除条件が発生したか否かを判定する。
【０１３７】
例えば、ポーリング受信解除方式におけるRF信号の消失後のポーリングコマンドの受信、RLS_REQ受信解除方式におけるRLS_REQの受信、又はDSL_REQ受信解除方式におけるDSL_REQの受信がターゲット解除条件となるので、それらの解除条件が発生した場合、処理は、ステップＳ８２に進められる。
【０１３８】
ステップＳ８２において、解除部１０３は、例えば、P2Pアプリ４１等の通信対象として確定されていた確定ターゲットを解除する。
【０１３９】
確定ターゲットが解除されると、図１８の解除処理は終了する。
【０１４０】
以上のように、ポーリング受信解除方式、RLS_REQ受信解除方式、又はDSL_REQ受信解除方式を用いて、解除処理を行うことで、例えば、RF信号の消失後の再接続にも対応することが可能となる。
【０１４１】
［ルーティング状態遷移］
図１９は、ルーティングの状態遷移を示す図である。
【０１４２】
図１９において、非選択状態は、ターゲット候補の選択が行われていない状態を表す。また、選択中状態は、NFCリーダ１２からポーリングコマンドを受信して、ターゲット候補が選択されている状態を表す。なお、選択中状態において、通信が切断されてRF信号が消失するか、所定のコマンドが受信された場合、非選択状態に遷移される。
【０１４３】
P2P確定中状態は、選択中状態時にNFCリーダ１２からATR_REQが受信され、P2Pアプリ４１が確定ターゲットとなっている状態を表す。なお、P2P確定中状態において、RF信号が消失したり、NFCリーダ１２からのコマンドRLS_REQやDSL_REQ、CLFを制御するDHから無線通信処理の強制終了を指示するためのコマンドであるDEACTIVATE_CMDが受信された場合、非選択状態に遷移される。
【０１４４】
確定中状態は、選択中状態時に、NFCリーダ１２から、ポーリングコマンドと、ATR_REQ以外のコマンドを受信して、P2Pアプリ４１以外の他のターゲットが確定ターゲットとなっている状態を表す。なお、確定中状態において、所定のコマンドが受信された場合、非選択状態に遷移される。また、確定中状態において、通信が切断されてRF信号が消失した場合、リトライ待機中状態に遷移される。
【０１４５】
リトライ待機中状態は、確定中状態時に、RFが消失したため、リトライを待っている状態を表す。なお、リトライ待機中状態において、RF信号が復活後、ポーリング以外のNFC-Fのコマンドを受信するなどした場合、確定中状態に遷移される。また、リトライ待機中状態において、ポーリングコマンドが受信された場合、選択中状態に遷移される。
【０１４６】
以上のように、ルーティング処理においては、非選択状態、選択中状態、P2P確定中状態、確定中状態、及びリトライ待機中状態のいずれかに状態遷移が行われることで、複数のターゲットの中から、１以上のターゲット候補が選択され、確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、確定ターゲットと、NFCリーダ１２との間で通信が行われる。
【０１４７】
［ユースケースの例］
次に、前述したルーティング処理の具体的例として、ユースケース１乃至３を説明する。図２０は、ユースケース１を説明するためのシーケンス図である。
【０１４８】
ユースケース１は、NFCリーダ１２がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ４１から開始されるケースの例である。
【０１４９】
図２０に示すように、P2Pアプリ専用のNFCリーダ１２からポーリングコマンドが送信されると、CLF３１の候補選択部１０１は、ターゲット候補として、P2Pアプリ４１を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１５０】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信され、そのレスポンスがCLF３１に返される。
【０１５１】
候補選択部１０１は、ESE３２及びUICC３４からのレスポンスに応じて、ESE３２をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。これにより、ターゲット候補として、P2Pアプリ４１とESE３２が選択されたことになる。
【０１５２】
続いて、NFCリーダ１２からコマンドATR_REQが送信されると、CLF３１の確定部１０２によって、P2Pアプリ４１が確定ターゲットとされ、コマンドATR_RESが返信される。これにより、P2Pアプリ専用のNFCリーダ１２とP2Pアプリ４１が、CLF３１を介して、所定のP2Pトランザクション処理を行うことになる。
【０１５３】
そして、P2Pトランザクション処理が終了して、NFCリーダ１２からコマンドDSL_REQが送信されると、CLF３１の解除部１０３によって、P2Pアプリ４１が確定ターゲットから解除され、コマンドDSL_RESが返信される。なお、その後、再度、NFCリーダ１２からポーリングコマンドが送信された場合には、前述した処理が繰り返され、P2Pアプリ４１が、ターゲット候補として選択される。
【０１５４】
以上のように、ユースケース１では、NFCリーダ１２によるポーリングに応じて、P2Pアプリ４１及びESE３２がターゲット候補として選択された段階で、P2Pアプリ４１が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ４１が確定ターゲットから解除されると、NFCリーダ１２によるポーリングが再開され、P2Pアプリ４１及びUICC３４がターゲット候補として選択されることになる。
【０１５５】
すなわち、ユースケース１では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、P2Pアプリ４１、ESE３２、P2Pアプリ４１、UICC３４の順にターゲットが選択され、P2Pアプリ４１が２回に１回選択される。
【０１５６】
図２１は、ユースケース２を説明するためのシーケンス図である。
【０１５７】
ユースケース２は、NFCリーダ１２がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがESE３２から開始されるケースの例である。
【０１５８】
図２１に示すように、P2Pアプリ専用のNFCリーダ１２からポーリングコマンドが送信されると、CLF３１の候補選択部１０１は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信され、そのレスポンスがCLF３１に返される。
【０１５９】
候補選択部１０１は、ESE３２及びUICC３４からのレスポンスに応じて、ESE３２をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１６０】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、ターゲット候補として、P2Pアプリ４１を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。これにより、ターゲット候補として、ESE３２とP2Pアプリ４１が選択されたことになる。
【０１６１】
続いて、NFCリーダ１２からコマンドATR_REQが送信されると、P2Pアプリ４１が確定ターゲットとされる。これにより、P2Pアプリ専用のNFCリーダ１２とP2Pアプリ４１の間では、所定のP2Pトランザクション処理が行われる。そして、P2Pトランザクション処理が終了すると、NFCリーダ１２からコマンドDSL_REQが送信され、P2Pアプリ４１が確定ターゲットから解除される。
【０１６２】
次に、NFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１によって、そのポーリングコマンドがブロードキャスト送信され、ESE３２及びUICC３４によってそれぞれ受信される。そして、UICC３４がターゲット候補に選択され、そのポーリングレスポンスがNFCリーダ１２に返信される。その後、P2Pアプリ４１がターゲット候補に追加され、前述した処理が繰り返されることになる。
【０１６３】
以上のように、ユースケース２では、NFCリーダ１２によるポーリングに応じて、ESE３２及びP2Pアプリ４１がターゲット候補として選択された段階で、P2Pアプリ４１が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ４１が確定ターゲットから解除されると、NFCリーダ１２によるポーリングが再開され、UICC３４及びP2Pアプリ４１がターゲット候補として選択されることになる。
【０１６４】
すなわち、ユースケース２では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、ESE３２、P2Pアプリ４１、UICC３４、P2Pアプリ４１の順にターゲットが選択され、P2Pアプリ４１が２回に１回選択される。
【０１６５】
図２２は、ユースケース３を説明するためのシーケンス図である。
【０１６６】
ユースケース３は、NFCリーダ１２がESE専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ４１から開始されるケースの例である。
【０１６７】
図２２に示すように、ESE専用のNFCリーダ１２からポーリングコマンドが送信されると、候補選択部１０１は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ４１に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ４１からESE３２に切り替える。そして、CLF３１の候補選択部１０１は、ポーリングコマンドをブロードキャスト送信する。
【０１６８】
ブロードキャスト送信されたポーリングコマンドは、ESE３２及びUICC３４にそれぞれ受信される。このとき、ESE３２からはレスポンスがあったが、UICC３４からは無応答であった場合、候補選択部１０１は、ターゲット候補として、ESE３２を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。なお、ここでは、ターゲット候補として選択されたESE３２のIDmがメモリ３１Ａに記憶される。
【０１６９】
続いて、NFCリーダ１２からリクエストサービス等のポーリング以外のコマンドが送信された場合、確定部１０２は、受信したコマンドに含まれるIDmと、メモリ３１Ａに記憶していたIDmとを比較する。そして、確定部１０２は、IDmが一致するESE３２を確定ターゲットとし、そのリクエストサービスをESE３２に送信する。ESE３２が、リクエストサービスに応じてレスポンスを返信すると、そのレスポンスは、NFCリーダ１２に送信される。これにより、ESE専用のNFCリーダ１２とESE３２が、CLF３１を介して、所定のESEトランザクション処理を行うことになる。
【０１７０】
その後、RF信号が消失した場合、所定のターゲット解除条件を満たすまでは、解除処理は行われず、確定ターゲットが維持される。
【０１７１】
そして、再度、NFCリーダ１２からポーリングコマンドが送信されると、ESE３２が確定ターゲットから解除される。また、候補選択部１０１は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ４１に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ４１からUICC３４に切り替える。また、候補選択部１０１が、そのポーリングコマンドをブロードキャスト送信すると、ESE３２及びUICC３４によってそれぞれ受信され、ESE３２からのみレスポンスが返信される。そこで、候補選択部１０１は、ターゲット候補として、ESE３２を選択し、そのポーリングレスポンスをNFCリーダ１２に返信する。
【０１７２】
続いて、NFCリーダ１２からリクエストサービスが送信された場合、確定部１０２は、IDmの比較を行い、IDmが一致するESE３２を確定ターゲットとし、そのリクエストサービスをESE３２に送信する。また、ESE３２からのレスポンスは、NFCリーダ１２に送信される。これにより、ESE専用のNFCリーダ１２とESE３２が、CLF３１を介して、所定のESEトランザクション処理を行うことになる。
【０１７３】
以上のように、ユースケース３では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられる。すなわち、NFCリーダ１２によるポーリングに応じて、ターゲット候補を選択する段階で、ポーリングパラメータがチェックされ、P2Pアプリ４１には該当しないので、ESE３２又はUICC３４がターゲット候補として選択される。そして、ポーリングコマンドをブロードキャスト送信して、レスポンスがあったESE３２が確定ターゲットとなり、ESEトランザクション処理が行われる。
【０１７４】
また、RF信号が消失した場合でも、所定のターゲット解除条件を満たすまでは、確定ターゲットが維持されるため、NFCリーダ１２とCLF３１の近接通信が復活した場合に処理を継続することができる。
【０１７５】
なお、図２２の例では、ESE専用のリーダについて説明したが、UICC専用のリーダに対する動作は、基本的に、ESE専用のリーダに対する動作と同一の動作となるため、その説明は省略する。
【０１７６】
このように、スキップ機能を含むP2Pメインのローテーション方式を採用することで、３以上のターゲットのうちの１つのターゲットが、２回に１回、ターゲット候補として選択されるので、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【０１７７】
また、シングルレスポンス方式が用いられることで、CLF３１（フロントエンド）に特別な回路を実装することなく、NFCリーダ１２が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。
【０１７８】
［スキップ機能を含むP2Pメインのローテーション方式の拡張］
図２３は、拡張版のスキップ機能を含むP2Pメインのローテーション方式のターゲット候補遷移図である。
【０１７９】
拡張版のスキップ機能を含むP2Pメインのローテーション方式では、前述した図８を参照して説明したESE３２，UICC３４，P2Pアプリ４１に加えて、DH３３上に実装されるT3T（Type 3 Tag）エミュレーションがローテーションに含まれる。この場合であっても、基本的なローテーションは図８と変らず、ターゲットとなる、P2Pアプリ４１，ESE３２，UICC３４，T3Tのうち、P2Pアプリ４１が２回に１回必ず選択されることになる。
【０１８０】
具体的には、図２３に示すように、ローテーションの順番が、P2Pアプリ４１を中心にして、例えば、P2Pアプリ４１，ESE３２，P2Pアプリ４１，UICC３４，P2Pアプリ４１，T3T，P2Pアプリ４１の順に行われる。また、前述したように、例えば、P2Pアプリ４１に対するポーリングではない場合には、ローテーションが、P2Pアプリ４１をスキップして、ESE３２、UICC３４、又はT3Tに、強制的に切り替えられる。
【０１８１】
このように、P2Pアプリ４１以外のターゲットが増えても、P2Pアプリ４１を中心にして、P2Pアプリ４１が２回に１回必ず選択されるので、NFCリーダ１２では、確実にP2Pアプリ４１に対する動作が行われることになる。
【０１８２】
［本技術を適用したコンピュータの説明］
前述した一連の処理は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
【０１８３】
そこで、図２４は、前述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示している。
【０１８４】
プログラムは、コンピュータ２００に内蔵されているハードディスク等の記憶部２０８やROM(Read Only Memory)２０２に予め記録しておくことができる。
【０１８５】
あるいはまた、プログラムは、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブルメディア２１１に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブルメディア２１１は、いわゆるパッケージソフトウエアとして提供することができる。
【０１８６】
なお、プログラムは、前述したようなリムーバブルメディア２１１からコンピュータ２００にインストールする他、ダウンロードサイトから、デジタル衛星放送用の人工衛星を介して、コンピュータ２００に無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータ２００に有線で転送し、コンピュータ２００では、そのようにして転送されてくるプログラムを、通信部２０９で受信し、記憶部２０８にインストールすることができる。
【０１８７】
コンピュータ２００は、CPU(Central Processing Unit)２０１を内蔵している。CPU２０１には、バス２０４を介して、入出力インタフェース２０５が接続されており、CPU２０１は、入出力インタフェース２０５を介して、ユーザによって、キーボードや、マウス、マイク等で構成される入力部２０６が操作等されることにより指令が入力されると、それに従って、ROM２０２に格納されているプログラムを実行する。あるいは、また、CPU２０１は、記憶部２０８に格納されているプログラム、衛星若しくはネットワークから転送され、通信部２０９で受信されて記憶部２０８にインストールされたプログラム、又はドライブ２１０に装着されたリムーバブルメディア２１１から読み出されて記憶部２０８にインストールされたプログラムを、RAM(Random Access Memory)２０３にロードして実行する。これにより、CPU２０１は、前述したフローチャートにしたがった処理、あるいは前述したブロック図の構成により行われる処理を行う。そして、CPU２０１は、その処理結果を、必要に応じて、例えば、入出力インタフェース２０５を介して、LCD(Liquid Crystal Display)やスピーカ等で構成される出力部２０７から出力、あるいは、通信部２０９から送信、さらには、記憶部２０８に記録等させる。
【０１８８】
ここで、本明細書において、コンピュータ２００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
【０１８９】
また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。
【０１９０】
また、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０１９１】
さらに、本技術は、以下の構成とすることも可能である。
【０１９２】
［１］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備え、
前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
通信装置。
［２］
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する
［１］に記載の通信装置。
［３］
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである
［１］又は［２］に記載の通信装置。
［４］
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる
［３］に記載の通信装置。
［５］
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する
［１］乃至［４］のいずれかに記載の通信装置。
［６］
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
［５］に記載の通信装置。
［７］
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
［５］に記載の通信装置。
［８］
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
［５］乃至［７］のいずれかに記載の通信装置。
［９］
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する
［８］に記載の通信装置。
［１０］
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する
［８］に記載の通信装置。
［１１］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御方法であって、
前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む制御方法。
［１２］
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御用のプログラムであって、
前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
【符号の説明】
【０１９３】
１１ NFCデバイス， １２ NFCリーダ， ３１ CLF， ３１Ａ メモリ， ３２ ESE， ３３ DH， ３４ UICC， ４１ P2Pアプリ， １０１ 候補選択部， １０２ 確定部， １０３ 解除部， １０４ 無線通信制御部， ２００ コンピュータ， ２０１ CPU
【特許請求の範囲】
【請求項１】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備え、
前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
通信装置。
【請求項２】
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する
請求項１に記載の通信装置。
【請求項３】
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである
請求項１に記載の通信装置。
【請求項４】
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる
請求項３に記載の通信装置。
【請求項５】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する
請求項１に記載の通信装置。
【請求項６】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
請求項５に記載の通信装置。
【請求項７】
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
請求項５に記載の通信装置。
【請求項８】
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
請求項５に記載の通信装置。
【請求項９】
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する
請求項８に記載の通信装置。
【請求項１０】
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する
請求項８に記載の通信装置。
【請求項１１】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御方法であって、
前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む制御方法。
【請求項１２】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御用のプログラムであって、
前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
【請求項１】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備え、
前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
通信装置。
【請求項２】
前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する
請求項１に記載の通信装置。
【請求項３】
前記所定のターゲットは、P2P（Peer to Peer）のアプリケーションである
請求項１に記載の通信装置。
【請求項４】
前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICC（Universal Integrated Circuit Card）のいずれか一方又は双方を含んでいる
請求項３に記載の通信装置。
【請求項５】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する
請求項１に記載の通信装置。
【請求項６】
前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
請求項５に記載の通信装置。
【請求項７】
前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する
請求項５に記載の通信装置。
【請求項８】
前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
請求項５に記載の通信装置。
【請求項９】
前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する
請求項８に記載の通信装置。
【請求項１０】
前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する
請求項８に記載の通信装置。
【請求項１１】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御方法であって、
前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む制御方法。
【請求項１２】
それぞれが所定の処理を実行する複数のターゲットと、
前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
を備える通信装置の制御用のプログラムであって、
前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを２回に１回選択する
ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２０１３−４１３４９（Ｐ２０１３−４１３４９Ａ）
【公開日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願番号】特願２０１１−１７６４９２（Ｐ２０１１−１７６４９２）
【出願日】平成２３年８月１２日（２０１１．８．１２）
【出願人】（５０４１３４５２０）フェリカネットワークス株式会社 (129)
【Ｆターム（参考）】
【公開日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願日】平成２３年８月１２日（２０１１．８．１２）
【出願人】（５０４１３４５２０）フェリカネットワークス株式会社 (129)
【Ｆターム（参考）】
[ Back to top ]