"それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択する通信装置。前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する請求項1に記載の通信装置。前記所定のターゲットは、P2PPeertoPeerのアプリケーションである請求項1に記載の通信装置。前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICCUniversalIntegratedCircuitCardのいずれか一方又は双方を含んでいる請求項3に記載の通信装置。前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する請求項1に記載の通信装置。前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する請求項5に記載の通信装置。前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する請求項5に記載の通信装置。前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する請求項5に記載の通信装置。前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する請求項8に記載の通信装置。前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する請求項8に記載の通信装置。それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備える通信装置の制御方法であって、前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択するステップを含む制御方法。それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備える通信装置の制御用のプログラムであって、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択するステップを含む処理を、通信装置のコンピュータに実行させるプログラム。ところで、図2に示すように、フロントエンドがマルチレスポンス方式の機能を有する場合であっても、例えば3つのポーリングレスポンスを返したいときに、2つのタイムスロットしかないと、スロット不足のため、一度にポーリングレスポンスを返信することができなくなる。このように、マルチレスポンス方式では、スロット数が多ければ、ポーリングスロットを全て返信することが可能となるが、リーダが、TSN01など、小さいTSNTimeSlotNumberによりポーリングしてきた場合に、スロット数が不足してしまい、全てのポーリングレスポンスを返せなくなるときがある。また、マルチレスポンス方式を利用するためには、特別な回路をフロントエンドに設ける必要があるため、マルチレスポンス方式に対応してない既存のデバイスだと、特別な回路を実装する必要が出てくる。また、あるNFCのリーダ動作規格によると、リーダは2回のポーリングを行い、2回のうちどちらかに、P2PPeertoPeerのアプリケーションからのレスポンスがあれば、P2Pのアプリケーションの動作を進めることができる、という動作仕様が定義されており、この動作仕様に対応する必要がある。本技術はこのような状況に鑑みてなされたものであり、上記のリーダの動作仕様に対応し、かつ、フロントエンドに特別な回路を実装することなく、リーダが所望とするターゲットを確実に選択して、迅速に通信を確立することができるようにするものである。本技術の一側面の通信装置は、それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択する。前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する。前記所定のターゲットは、P2PPeertoPeerのアプリケーションである。前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICCUniversalIntegratedCircuitCardのいずれか一方又は双方を含んでいる。前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する。前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する。前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する。前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する。前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する。通信装置は、独立した装置であってもよいし、1つの装置を構成している内部ブロックであってもよい。本技術の一側面の制御方法又はプログラムは、前述した本技術の一側面の通信装置に対応する制御方法又はプログラムである。本技術の一側面の通信装置、制御方法、及びプログラムにおいては、それぞれが所定の処理を実行する複数のターゲットの中から、外部装置の通信対象となる確定ターゲットが選択され、外部装置との近接通信が行われる。また、確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットが2回に1回選択される。本技術の一側面によれば、迅速に通信を確立することができる。以下、図面を参照しながら本技術の実施の形態について説明する。[NFCデバイスの構成例]図3は、NFCデバイスの構成例を示す図である。NFCデバイス11は、例えば、携帯電話機、ICカード、携帯情報端末、又はパーソナルコンピュータなどの装置として構成される。NFCデバイス11は、NFCリーダ12等の外部装置と、例えばISMIndustryScienceMedicalバンドの1356MHzの周波数の搬送波を用いて、数10cm以内接触している場合も含むの距離で近接通信を行う。NFCデバイス11は、CLF31、ESE32、DH33、及びUICC34から構成される。CLF31と、ターゲットとしてのESE32、DH33、及びUICC34のそれぞれは、有線により接続され、相互に通信可能とされる。CLFContactlessFrontEnd31は、NFCデバイス11内に設けられたアンテナに接続され、NFCリーダ12と近接通信を行う。CLF31は、NFCリーダ12から送信されてくるコマンドに応じて、NFCリーダ12が所望とするターゲットを選択して、NFCリーダ12との間で通信が行われるように制御する。また、CLF31は、メモリ31Aを内蔵しており、必要に応じて各種のデータが記憶される。ESEEmbeddedSecureElement32は、ICチップのセキュリティを含めたコア部分となるセキュアエレメントであって、例えば、電子決済や電子乗車券、入退室管理のNFCアプリケーションにおけるセキュリティ機能を実現する。DHDeviceHost33は、NFCデバイス11の各部の動作を制御する。また、DH33は、P2PPeertoPeerのアプリケーションであるP2Pアプリ41を実行する。なお、P2Pアプリ41は、1又は複数実行可能とされる。UICCUniversalIntegratedCircuitCard34は、例えば、SIMSubscriberIdentityModuleカードから構成される。UICC34は、NFCアプリケーションを実行することで、例えば、電子決済機能を実現する。このように、ESE32、UICC34、及びP2Pアプリ41は、NFCリーダ12の通信対象となるターゲットであって、それぞれが所定の処理を行う。換言すれば、ターゲットには、ESE32やUICC34などのデバイスと、P2Pアプリ41などのアプリケーションが含まれることになる。NFCデバイス11は、以上のように構成される。[CLFの詳細な構成例]図4は、図3のCLF31の詳細な構成例を示す図である。CLF31は、候補選択部101、確定部102、解除部103、及び無線通信制御部104から構成される。候補選択部101は、所定の規則に従って、NFCリーダ12の通信対象となるターゲットの候補以下、ターゲット候補というを選択する候補選択処理を行う。候補選択処理が行われることで、ターゲット候補として、1又は複数のターゲットが選択される。確定部102は、所定の規則に従って、候補選択処理によりターゲット候補として選択されたターゲットを確定する確定処理を行う。確定処理が行われることで、ターゲット候補として選択されたターゲットのうち、NFCリーダ12の通信対象となるターゲット以下、確定ターゲットというが確定される。解除部103は、所定の規則に従って、確定処理により確定されたターゲットを解除する解除処理を行う。解除処理が行われることで、確定ターゲットがNFCリーダ12の通信対象から解除される。無線通信制御部104は、NFCリーダ12との間で行われる近接通信を制御するための処理を行う。CLF31は、以上のように構成される。[ルーティング処理]次に、図5のフローチャートを参照して、CLF31により実行されるルーティング処理について説明する。ステップS1において、候補選択部101は、候補選択処理を行う。この候補選択処理によって、複数のターゲットの中から、1以上のターゲットが、ターゲット候補として選択される。なお、候補選択処理の詳細は、図6乃至図11を参照して後述する。ステップS2において、確定部102は、確定処理を行う。この確定処理によって、ターゲット候補として選択された1以上のターゲットの中から、NFCリーダ12の通信対象となる確定ターゲットが確定される。なお、確定処理の詳細は、図12乃至図15を参照して後述する。ステップS3において、解除部103は、解除処理を行う。この解除処理によって、確定ターゲットがNFCリーダ12の通信対象から解除される。すなわち、一旦、通信対象として確定された確定ターゲットは、解除処理が行われ、通信対象から解除されるまで、NFCリーダ12の通信対象となる。なお、解除処理の詳細は、図16乃至図18を参照して後述する。また、規格によっては、解除処理を行う必要のない規格もあるが、その場合にはステップS3の処理は省略される。以上で、ルーティング処理の説明を終了する。前述したルーティング処理によれば、複数のターゲットの中から、1以上のターゲット候補が選択され、選択された1以上のターゲットの中から、NFCリーダ12の通信対象となる確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、通信対象として確定された確定ターゲットと、NFCリーダ12との間で通信が行われる。[候補選択処理]次に、図6乃至図11を参照して、図5のステップS1に対応する候補選択処理について説明する。ここでは、候補選択処理として、固定ターゲット方式、シンプルローテーション方式、スキップ機能を含むシンプルローテーション方式、及び、スキップ機能を含むP2Pメインのローテーション方式の4つの方式について説明する。固定ターゲット方式は、アプリケーションから特に選択されない限り、デフォルトで設定されたターゲットが常に選択される方式である。固定ターゲット方式を採用すると、実装面では極めてシンプルになるというメリットがある反面、ターゲット候補の選択時の正答率が悪くなるというデメリットもある。例えば、ターゲットをESE32に固定してしまうと、ユーザの事前設定なしには、P2Pアプリ41やUICC34などのアプリケーションを動作させることができなくなる。シンプルローテーション方式は、ターゲット候補を順次変更することで、ターゲットを選択する方式である。CLF31は、NFCリーダ12からポーリングされる度に、異なるターゲット候補を選択して、選択されたターゲットからのレスポンスを返信する。具体的には、図6に示すように、例えば、最初のポーリングではESE32がターゲット候補として選択され、その後、ポーリングされるごとにローテーションが行われ、UICC34、P2Pアプリ41、ESE32、が順次、ターゲット候補として選択される。シンプルローテーション方式を採用すると、実装面ではシンプルになるというメリットがある反面、所望のターゲットを選択するためにポーリングのリトライを繰り返す場合が出てくるため、ターゲット候補の選択時の正答率は上がらないというデメリットがある。スキップ機能を含むシンプルローテーション方式は、前述したシンプルローテーションに加えて、あるターゲットが、対象外であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する方式である。CLF31は、NFCリーダ12からポーリングされる度に、そのポーリングパラメータをチェックして、対象外となるターゲットを判定する。そして、対象外のターゲット候補であると判定された場合には、そのターゲットをスキップして、次のターゲットをターゲット候補として選択する。具体的には、図7に示すように、例えば、ポーリングパラメータのSCSystemCodeがFFFFではない場合、又はRCRequestCode1の場合、そのポーリングは、P2Pアプリ41に対するものではないため、ターゲット候補を、UICC34からESE32に切り替える。すなわち、前述したシンプルローテーションであると、UICC34の次はP2Pアプリ41がターゲット候補となるところ、P2Pアプリ41がスキップされ、ターゲット候補がESE32に強制的に切り替えられることになる。スキップ機能を含むシンプルローテーションを採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、所定の規則により対象外となるターゲットを特定して非選択とすることで、ターゲット候補の選択時の正答率も向上させることができる。スキップ機能を含むP2Pメインのローテーション方式は、前述したスキップ機能を含むシンプルローテーションを、P2Pアプリ41を中心に行う方式である。具体的には、図8に示すように、ローテーションの順番が、P2Pアプリ41を中心にして、例えば、P2Pアプリ41,ESE32,P2Pアプリ41,UICC34,P2Pアプリ41の順に行われる。これは、あるNFCのリーダ動作規格によると、NFCリーダ12は2回のポーリングを行い、2回のうちどちらかにP2Pアプリ41からのレスポンスがあれば、P2P動作を進めることができる、という動作仕様が定義されており、これに対応するため、2回に1回は必ず、P2Pアプリ41のレスポンスが返信されるようにしたものである。これにより、ターゲットとなる、P2Pアプリ41,ESE32,UICC34のうち、P2Pアプリ41が2回に1回必ず選択されるので、NFCリーダ12では、確実にP2Pアプリ41に対する動作が行われることになる。また、スキップ機能を含むシンプルローテーション方式と同様に、例えば、P2Pアプリ41に対するポーリングではない場合には、ローテーションが、P2Pアプリ41をスキップして、ターゲット候補がESE32又はUICC34に、強制的に切り替えられる。なお、図8の例では、P2Pアプリ41が2回に1回必ずターゲット候補として選択されるとして説明したが、NFCリーダ12側の動作の規則に応じて、P2Pアプリ41以外の他のターゲットが2回に1回、ターゲット候補として選択されるようにしてもよい。すなわち、3以上のターゲットのうちの1つのターゲットが、2回に1回、ターゲット候補として選択されるようにすることで、NFCリーダ12が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。スキップ機能を含むP2Pメインのローテーション方式を採用すると、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。また、NFCリーダ12側の動作の規則に応じて、所定のターゲットが優先的に選択されるので、NFCリーダ12側の動作との整合をとることができる。また、CLF31は、NFCリーダ12から受信したポーリングコマンドを、ターゲットに送信する場合、ユニキャスト又はブロードキャストにより送信することができる。ユニキャストでは、現時点で、ターゲット候補となっているターゲットにのみ、ポーリングコマンドが送信される。そのため、ユニキャスト送信を行う場合には、実装面ではシンプルとなるが、ターゲット候補の選択時の正答率の向上には寄与しないこととなる。一方、ブロードキャストでは、ターゲット候補となっているターゲットであるか否かに関係なく、複数のターゲットにポーリングコマンドが送信される。具体的には、図9に示すように、例えば、ESE32がターゲット候補となっている場合に、NFCリーダ12がUICC34に対するSCを指定してポーリングコマンドを送信してきたとき、CLF31は、ポーリングコマンドを、ESE32とUICC34の両方にブロードキャストで送信する。これにより、ESE32からは無応答となるが、UICC34からはレスポンスがあるため、ターゲット候補を、ESE32からUICC34に切り替えて、NFCリーダ12に返信することができる。すなわち、ブロードキャスト送信を行う場合には、実装面ではユニキャストに比べて複雑になるが、ターゲット候補の選択時の正答率の大幅な向上が見込まれる。図10は、図9で説明したブロードキャスト送信を、図8で説明したスキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合のターゲット候補遷移図である。前述したように、スキップ機能を含むP2Pメインのローテーション方式では、P2Pアプリ41を中心にして、例えば、P2Pアプリ41,ESE32,P2Pアプリ41,UICC34,P2Pアプリ41の順にローテーションされる。それに対して、ブロードキャスト送信が組み込まれると、P2Pアプリ41からESE32又はUICC34にターゲット候補が遷移する際に、ブロードキャスト送信に対するレスポンスに応じて、ESE32又はUICC34にターゲット候補が遷移する。例えば、P2Pアプリ41,ESE32,P2Pアプリ41の順に候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC34からは無応答であったが、ESE32からレスポンスがあった場合、UICC34ではなく、ESE32がターゲット候補とされる。そして、P2Pアプリ41,UICC34,P2Pアプリ41の順にターゲット候補が遷移した後、ポーリングコマンドをブロードキャスト送信することで、UICC34からレスポンスがあったが、ESE32からは無応答であった場合、ESE32ではなく、UICC34がターゲット候補とされ、その後、P2Pアプリ41に候補が遷移される。すなわち、ブロードキャスト送信を、スキップ機能を含むP2Pメインのローテーション方式に組み込んだ場合、P2Pアプリ41を中心にして、例えば、P2Pアプリ41,ESE32,P2Pアプリ41,ESE32,P2Pアプリ41,UICC34,P2Pアプリ41,UICC34,P2Pアプリ41の順にローテーションされる。このように、3以上のターゲットのうちの1つのターゲットが、2回に1回選択されるようにターゲット候補を選択するだけでなく、ブロードキャスト送信することで、2回に1回選択されるターゲット以外のターゲットの正答率を、さらに向上させることができる。その結果、NFCリーダ12が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。次に、図11のフローチャートを参照して、候補選択部101により実行される、図5のステップS1に対応する候補選択処理の流れについて説明する。なお、図11では、候補選択処理として最も効率がよい方式となる、スキップ機能を含むP2Pメインのローテーション方式による候補選択処理について説明する。ステップS21において、候補選択部101は、初期設定を行う。この初期設定としては、例えば、P2Pアプリ41からローテーションを開始するか否かに応じて、変数i0又は1がセットされる。ステップS22において、候補選択部101は、無線通信制御部104を制御して、NFCリーダ12からポーリングコマンドを受信したか否かを判定する。ステップS22において、ポーリングコマンドを受信したと判定された場合、処理は、ステップS23に進められる。ステップS23において、候補選択部101は、NFCリーダ12からのポーリングコマンドに含まれるポーリングパラメータに基づいて、P2Pアプリ41がターゲット候補の対象外となるか否かを判定する。ここでは、前述したように、例えば、ポーリングパラメータが、SCFFFFではない場合、又はRC1の場合、そのポーリングは、P2Pアプリ41に対するものではないことになる。なお、ここでは、P2Pアプリ41がターゲット候補の対象外となる例を説明したが、ポーリングパラメータに応じて、P2Pアプリ41以外の他のターゲットが対象外となるようにしてもよい。ステップS23において、P2Pアプリ41がターゲット候補の対象外であると判定された場合、処理は、ステップS24に進められる。ステップS24において、候補選択部101は、P2Pアプリ41以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE32又はUICC34がターゲット候補として選択される。一方、ステップS23において、P2Pアプリ41がターゲット候補の対象であると判定された場合、処理は、ステップS25に進められる。ステップS25において、候補選択部101は、変数iの値が偶数であるか否かを判定する。ステップS25において、変数iの値が偶数であると判定された場合、処理は、ステップS26に進められる。ステップS26において、候補選択部101は、P2Pアプリ41を、ターゲット候補として選択する。一方、ステップS25において、変数iの値が奇数であると判定された場合、処理は、ステップS24に進められる。ステップS24において、候補選択部101は、P2Pアプリ41以外の他のターゲットを、ターゲット候補として選択する。この場合、例えば、ESE32又はUICC34がターゲット候補として選択される。また、このとき、ESE32及びUICC34に対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を向上させることができるのは、図9を参照して前述した通りである。ステップS24又はS26が終了すると、処理は、ステップS27に進められる。ステップS27において、候補選択部101は、変数iの値を1インクリメントする。これにより、次のステップS25の判定処理では、偶数と奇数が逆になるので、判定結果も逆になり、直近で、P2Pアプリ41がターゲット候補として選択された場合には、次は、P2Pアプリ41以外の他のターゲットが選択されることになる。その逆に、P2Pアプリ41以外の他のターゲットが直近で選択された場合には、次は、P2Pアプリ41がターゲット候補として選択されることになる。ステップS27の処理が終了すると、ステップS28において、候補選択部101は、ターゲット候補の選択が終了したか否かを判定する。ステップS28において、ターゲット候補の選択が終了していないと判定された場合、処理は、ステップS22に戻り、前述した処理が繰り返される。すなわち、ターゲット候補の選択が終了したと判定されるまでステップS28のYes、ステップS22乃至S28の処理が繰り返され、ターゲット候補として、P2Pアプリ41が2回に1回選択されることになる。ただし、前述の通り、例えば、P2Pアプリ41に対するポーリングではない場合には、ESE32又はUICC34が、ターゲット候補として強制的に選択される。そして、ステップS28において、ターゲット候補の選択が終了したと判定された場合、図11の候補選択処理は終了する。以上のように、スキップ機能を含むP2Pメインのローテーション方式を用いて、候補選択処理を行うことで、前述したシンプルローテーション方式と同等のシンプルさで実装できるだけでなく、ターゲット候補の選択時の正答率も向上させることができる。また、NFCリーダ12側の動作の規則に合わせて、P2Pアプリ41等の所定のターゲットが優先的に選択されるので、NFCリーダ12側の動作との整合をとることができる。さらに、所定のターゲット以外の複数のターゲットに対して、ポーリングコマンドをブロードキャスト送信することで、ターゲット候補の選択時の正答率を大幅に向上させることができる。[確定処理]次に、図12乃至図15を参照して、図5のステップS2に対応する確定処理について説明する。ここでは、確定処理として、IDm比較方式及びATRREQ受信方式の2つの方式について説明する。IDm比較方式は、シングルレスポンス方式において、NFCリーダ12からCLF31に対して、複数回のポーリングが行われる場合に、CLF31が各ポーリングに対して、ICチップの固有のIDであるIDmを用いて、異なるポーリングレスポンスを返すことにより、擬似的にマルチレスポンスを行う方式である。具体的には、図12に示すように、CLF31は、NFCリーダ12からのポーリングコマンドに応じて、候補選択処理を行う。CLF31は、UICC34からレスポンスがあった場合、UICC34のIDmを取得して、メモリ31Aに記憶する。これにより、UICC34がターゲット候補としてキープされる。そして、CLF31は、UICC34のIDmを含むポーリングレスポンスを、NFCリーダ12に返信する。続いて、NFCリーダ12から異なるポーリングコマンドが送信された場合、CLF31は、候補選択処理を行う。CLF31は、ESE32からレスポンスがあった場合、ESE32のIDmを取得して、メモリ31Aに記憶する。これにより、ESE32が候補に加えられ、ターゲット候補として、UICC34とESE32が選択される。そして、CLF31は、ESE32のIDmを含むポーリングレスポンスを、NFCリーダ12に返信する。その後、NFCリーダ12からリクエストサービスRequestService等のポーリング以外のコマンドが送信された場合、CLF31は、受信したコマンドに含まれるIDmと、メモリ31Aに記憶していたIDmとを比較して、IDmが一致したターゲット候補を、通信対象となる確定ターゲットとして確定する。例えば、NFCリーダ12からのリクエストサービスにESE32のIDmが含まれている場合、CLF31は、ESE32を確定ターゲットとして確定して、そのリクエストサービスをESE32に送信する。IDm比較方式を採用すると、IDmを取得して比較する処理等が加わるものの、CLF31に対して、複数回ポーリングコマンドを送信してくるNFCリーダ12に対しては、ターゲットの正答率を向上させることができる。ただし、ターゲット候補が確定される前に、IDmを含まないコマンドを受け付けることはできない。次に、図13のフローチャートを参照して、確定部102により実行されるIDm比較方式による確定処理の流れについて説明する。ステップS41において、確定部102は、候補選択処理により、ターゲット候補が選択されたか否かを判定する。ステップS41において、ターゲット候補が選択されたと判定された場合、処理は、ステップS42に進められる。ステップS42において、確定部102は、選択されたターゲット候補のIDmを取得して、メモリ31Aに記憶させるステップS43。ステップS43の処理が終了すると、ステップS44において、確定部102は、無線通信制御部104を制御して、NFCリーダ12からポーリングコマンド以外のコマンドを受信したか否かを判定する。ステップS44において、ポーリングコマンド以外のコマンドを受信していないと判定された場合、処理は、ステップS41に戻り、前述した処理が繰り返される。すなわち、ステップS41乃至S44が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ31Aに記憶される。一方、ステップS44において、ポーリングコマンド以外のコマンドを受信したと判定された場合、処理は、ステップS45に進められる。ステップS45において、確定部102は、NFCリーダ12からのポーリングコマンド以外のコマンドに含まれるIDmと、メモリ31Aに記憶されているIDmとを比較し、それらのIDmが一致するか否かを判定するステップS46。ステップS46において、メモリ31Aに記憶されたIDmの中に、コマンドに含まれるIDmと一致するIDmが存在すると判定された場合、処理は、ステップS47に進められる。ステップS47において、確定部102は、IDmが一致するターゲット候補を、確定ターゲットとして確定する。例えば、ESE32のIDmがメモリ31Aに記憶されている場合であって、NFCリーダ12からのリクエストサービスにESE32のIDmが含まれているとき、ESE32が確定ターゲットとなる。一方、ステップS46において、IDmが一致しないと判定された場合、ステップS47はスキップされる。この場合、通信対象が確定されないため、候補選択処理が継続されることになる。そして、CLF31は、NFCリーダ12との通信が続いたとしても、ルートが確定していないため、レスポンスが行われず、そのままの状態に留まることになる。その後、NFCリーダ12とCLF31の間の通信が切断されれば、ターゲット候補はリセットされるので、NFCリーダ12によるポーリングからやり直しとなる。すなわち、NFCリーダ12との通信が途切れた後、再度、NFCリーダ12によるポーリングが行われることになる。確定ターゲットが確定されるかステップS47、あるいは、IDmが一致しないと判定されるとステップS46のNo、図13の確定処理は終了する。以上のように、IDm比較方式を用いて、確定処理を行うことで、CLF31に対して、複数回ポーリングコマンドを送信してくるNFCリーダ12に対しては、ターゲットの正答率を向上させることができる。ATRREQ受信方式は、マルチレスポンス方式又はシングルレスポンス方式において、P2Pアプリ41としてNFCリーダ12にレスポンスした後、正しいATRREQ属性要求を受信した場合にはATRRESを返信して、確定ターゲットを確定する方式である。具体的には、図14に示すように、CLF31は、NFCリーダ12からのポーリングコマンドに応じて、候補選択処理を行い、P2Pアプリ41のポーリングレスポンスを返信する。これにより、P2Pアプリ41がターゲット候補としてキープされる。続いて、NFCリーダ12から異なるポーリングコマンドが送信された場合、CLF31は、候補選択処理を行う。CLF31は、ESE32からレスポンスがあった場合、ESE32のIDmを取得して、メモリ31Aに記憶する。これにより、ESE32が候補に加えられ、ターゲット候補として、P2Pアプリ41とESE32が選択される。そして、CLF31は、ESE32のIDmを含むポーリングレスポンスを、NFCリーダ12に返信する。その後、NFCリーダ12から、ATRREQが送信された場合、CLF31は、P2Pアプリ41を確定ターゲットとして確定して、ATRRESをNFCリーダ12に返信する。そして、CLF31は、NFCリーダ12からのATRREQに応じて、P2Pアプリ41を確定ターゲットとして確定する。なお、この場合、ターゲットの確定を目的としてのIDmの比較は行われず、正しいATRREQの受信によってターゲットが確定されることになる。次に、図15のフローチャートを参照して、確定部102により実行されるATRREQ受信方式による確定処理の流れについて説明する。ステップS61乃至S63においては、図13のステップS41乃至S43と同様に、確定部102によって、選択されたターゲット候補のIDmが取得され、メモリ31Aに記憶される。ステップS64において、確定部102は、無線通信制御部104を制御して、NFCリーダ12からATRREQを受信したか否かを判定する。ステップS64において、ATRREQを受信していないと判定された場合、処理は、ステップS61に戻り、前述した処理が繰り返される。すなわち、ステップS61乃至S64が繰り返され、ターゲット候補が選択された場合には、そのターゲットのIDmが、メモリ31Aに記憶される。一方、ステップS64において、ATRREQを受信したと判定された場合、処理は、ステップS65に進められる。ステップS65において、確定部102は、P2Pアプリ41を確定ターゲットとして確定する。P2Pアプリ41が通信対象として確定されると、図15の確定処理は終了する。以上のように、ATRREQ受信方式を用いて、確定処理を行うことで、CLF31に対して、複数回ポーリングコマンドを送信してくるNFCリーダ12に対しては、ターゲットの正答率を向上させることができる。また、例えば、DH33上にFALPFeliCaAdhocLinkProtocolが実装された場合、確定部102は、FALP専用のNFCリーダ12から送信されるProposeAdhocコマンドを監視することで、ProposeAdhocコマンドが受信された場合、強制的に、FALPを確定ターゲットとすることができる。すなわち、確定部102によって、NFCリーダ12から送信されるコマンドが監視され、所定のコマンドである場合には、そのコマンドに対応する所定のターゲットが、強制的に確定ターゲットとされる。[解除処理]次に、図16乃至図18を参照して、解除処理について説明する。ここでは、解除処理として、強制終了方式、RF消失解除方式、ポーリング受信解除方式、RLSREQ受信解除方式、及びDSLREQ受信解除方式の5つの方式について説明する。強制終了方式は、DH33により実行されているアプリケーションが、ユーザ操作により終了された場合、それをトリガとして、DH33から強制的に確定ターゲットの解除が行われる方式である。RF消失解除方式は、NFCリーダ12とCLF31の近接通信が切断され、RFRadioFrequency信号が消失した場合に、確定ターゲットの解除が行われる方式である。ところで、RF消失解除方式では、RF信号のオン/オフのチャタリングが発生した場合に、予期せぬRF信号の消失による通信対象の解除によって、ユーザに不便が生じる場合がある。具体的には、図16に示すように、NFCリーダ12とCLF31の近接通信が行われる場合に、ポーリングの終わりのほうで搬送波が検出されると、RF信号が一瞬オンになった後、通信相手がListenモードになって、RF信号がオフになってしまう。この時点で、RF信号のオフが検出され、確定ターゲットの解除が行われるのは、処理上好ましくない。また、図17に示すように、NFCリーダ12とCLF31の近接通信が行われている途中で、RF信号が消失して、解除処理が行われると、その後、NFCリーダ12とCLF31の近接通信が復活した場合には、確定ターゲットが解除されているため、CLF31は、どのターゲットと通信するのかが不明となる。そこで、ポーリング受信解除方式では、RF信号の消失後の再接続に対応するために、RF信号が消失した時点では、確定ターゲットの解除を行わず、RF信号の消失後、NFCリーダ12から、次のポーリングコマンドが受信された時点で、確定ターゲットが解除されるようにする。また、RF信号の消失後に受信したコマンドが、ポーリングコマンドでなければ、RF信号の消失前の経路、すなわち、RF信号の消失前と同一のターゲットとの間で処理が継続されるようにする。このポーリング受信解除方式によって、RF信号の消失後の再接続に対応することが可能となる。ポーリング受信解除方式を採用すると、実装面では特別な状態を想定する必要がなくなるので、シンプルな構成とすることができるというメリットがある。RLSREQ受信解除方式は、NFCリーダ12が、CLF31との近接通信を完全に終了するときに送信するコマンドであるRLSREQを利用して、RLSREQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ41が確定ターゲットとして確定されている場合であって、RLSREQが受信されたとき、CLF31は、P2Pアプリ41を、確定ターゲットから解除する。DSLREQ受信解除方式は、NFCリーダ12が、ターゲットをディセレクト状態とする非活性化するときに送信するコマンドであるDSLREQを利用して、DSLREQが受信された場合に、確定ターゲットの解除が行われる方式である。ここでは、P2Pアプリ41が確定ターゲットとして確定されている場合であって、DSLREQが受信されたとき、CLF31は、P2Pアプリ41を、確定ターゲットから解除する。なお、前述した5つの方式以外のターゲット解除条件を用いて、ターゲットの解除が行われるようにしてもよい。例えば、NFCデバイス11をリセットするためのデバイスリセットなどの各種の規格で定められたコマンドが受信されたことをターゲット解除条件とすることができる。次に、図18のフローチャートを参照して、解除部103により実行される解除処理の流れについて説明する。ステップS81において、解除部103は、確定ターゲットを解除するための所定の条件であるターゲット解除条件が発生したか否かを判定する。例えば、ポーリング受信解除方式におけるRF信号の消失後のポーリングコマンドの受信、RLSREQ受信解除方式におけるRLSREQの受信、又はDSLREQ受信解除方式におけるDSLREQの受信がターゲット解除条件となるので、それらの解除条件が発生した場合、処理は、ステップS82に進められる。ステップS82において、解除部103は、例えば、P2Pアプリ41等の通信対象として確定されていた確定ターゲットを解除する。確定ターゲットが解除されると、図18の解除処理は終了する。以上のように、ポーリング受信解除方式、RLSREQ受信解除方式、又はDSLREQ受信解除方式を用いて、解除処理を行うことで、例えば、RF信号の消失後の再接続にも対応することが可能となる。[ルーティング状態遷移]図19は、ルーティングの状態遷移を示す図である。図19において、非選択状態は、ターゲット候補の選択が行われていない状態を表す。また、選択中状態は、NFCリーダ12からポーリングコマンドを受信して、ターゲット候補が選択されている状態を表す。なお、選択中状態において、通信が切断されてRF信号が消失するか、所定のコマンドが受信された場合、非選択状態に遷移される。P2P確定中状態は、選択中状態時にNFCリーダ12からATRREQが受信され、P2Pアプリ41が確定ターゲットとなっている状態を表す。なお、P2P確定中状態において、RF信号が消失したり、NFCリーダ12からのコマンドRLSREQやDSLREQ、CLFを制御するDHから無線通信処理の強制終了を指示するためのコマンドであるDEACTIVATECMDが受信された場合、非選択状態に遷移される。確定中状態は、選択中状態時に、NFCリーダ12から、ポーリングコマンドと、ATRREQ以外のコマンドを受信して、P2Pアプリ41以外の他のターゲットが確定ターゲットとなっている状態を表す。なお、確定中状態において、所定のコマンドが受信された場合、非選択状態に遷移される。また、確定中状態において、通信が切断されてRF信号が消失した場合、リトライ待機中状態に遷移される。リトライ待機中状態は、確定中状態時に、RFが消失したため、リトライを待っている状態を表す。なお、リトライ待機中状態において、RF信号が復活後、ポーリング以外のNFCFのコマンドを受信するなどした場合、確定中状態に遷移される。また、リトライ待機中状態において、ポーリングコマンドが受信された場合、選択中状態に遷移される。以上のように、ルーティング処理においては、非選択状態、選択中状態、P2P確定中状態、確定中状態、及びリトライ待機中状態のいずれかに状態遷移が行われることで、複数のターゲットの中から、1以上のターゲット候補が選択され、確定ターゲットが確定される。そして、確定ターゲットが解除されるまで、確定ターゲットと、NFCリーダ12との間で通信が行われる。[ユースケースの例]次に、前述したルーティング処理の具体的例として、ユースケース1乃至3を説明する。図20は、ユースケース1を説明するためのシーケンス図である。ユースケース1は、NFCリーダ12がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ41から開始されるケースの例である。図20に示すように、P2Pアプリ専用のNFCリーダ12からポーリングコマンドが送信されると、CLF31の候補選択部101は、ターゲット候補として、P2Pアプリ41を選択し、そのポーリングレスポンスをNFCリーダ12に返信する。次に、NFCリーダ12からポーリングコマンドが送信されると、候補選択部101は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE32及びUICC34にそれぞれ受信され、そのレスポンスがCLF31に返される。候補選択部101は、ESE32及びUICC34からのレスポンスに応じて、ESE32をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ12に返信する。これにより、ターゲット候補として、P2Pアプリ41とESE32が選択されたことになる。続いて、NFCリーダ12からコマンドATRREQが送信されると、CLF31の確定部102によって、P2Pアプリ41が確定ターゲットとされ、コマンドATRRESが返信される。これにより、P2Pアプリ専用のNFCリーダ12とP2Pアプリ41が、CLF31を介して、所定のP2Pトランザクション処理を行うことになる。そして、P2Pトランザクション処理が終了して、NFCリーダ12からコマンドDSLREQが送信されると、CLF31の解除部103によって、P2Pアプリ41が確定ターゲットから解除され、コマンドDSLRESが返信される。なお、その後、再度、NFCリーダ12からポーリングコマンドが送信された場合には、前述した処理が繰り返され、P2Pアプリ41が、ターゲット候補として選択される。以上のように、ユースケース1では、NFCリーダ12によるポーリングに応じて、P2Pアプリ41及びESE32がターゲット候補として選択された段階で、P2Pアプリ41が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ41が確定ターゲットから解除されると、NFCリーダ12によるポーリングが再開され、P2Pアプリ41及びUICC34がターゲット候補として選択されることになる。すなわち、ユースケース1では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、P2Pアプリ41、ESE32、P2Pアプリ41、UICC34の順にターゲットが選択され、P2Pアプリ41が2回に1回選択される。図21は、ユースケース2を説明するためのシーケンス図である。ユースケース2は、NFCリーダ12がP2Pアプリ専用のリーダであって、ターゲット候補選択のローテーションがESE32から開始されるケースの例である。図21に示すように、P2Pアプリ専用のNFCリーダ12からポーリングコマンドが送信されると、CLF31の候補選択部101は、そのポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE32及びUICC34にそれぞれ受信され、そのレスポンスがCLF31に返される。候補選択部101は、ESE32及びUICC34からのレスポンスに応じて、ESE32をターゲット候補に選択し、そのポーリングレスポンスをNFCリーダ12に返信する。次に、NFCリーダ12からポーリングコマンドが送信されると、候補選択部101は、ターゲット候補として、P2Pアプリ41を選択し、そのポーリングレスポンスをNFCリーダ12に返信する。これにより、ターゲット候補として、ESE32とP2Pアプリ41が選択されたことになる。続いて、NFCリーダ12からコマンドATRREQが送信されると、P2Pアプリ41が確定ターゲットとされる。これにより、P2Pアプリ専用のNFCリーダ12とP2Pアプリ41の間では、所定のP2Pトランザクション処理が行われる。そして、P2Pトランザクション処理が終了すると、NFCリーダ12からコマンドDSLREQが送信され、P2Pアプリ41が確定ターゲットから解除される。次に、NFCリーダ12からポーリングコマンドが送信されると、候補選択部101によって、そのポーリングコマンドがブロードキャスト送信され、ESE32及びUICC34によってそれぞれ受信される。そして、UICC34がターゲット候補に選択され、そのポーリングレスポンスがNFCリーダ12に返信される。その後、P2Pアプリ41がターゲット候補に追加され、前述した処理が繰り返されることになる。以上のように、ユースケース2では、NFCリーダ12によるポーリングに応じて、ESE32及びP2Pアプリ41がターゲット候補として選択された段階で、P2Pアプリ41が確定ターゲットとなり、P2Pトランザクション処理が行われる。そして、P2Pトランザクション処理の終了後、P2Pアプリ41が確定ターゲットから解除されると、NFCリーダ12によるポーリングが再開され、UICC34及びP2Pアプリ41がターゲット候補として選択されることになる。すなわち、ユースケース2では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられ、例えば、ESE32、P2Pアプリ41、UICC34、P2Pアプリ41の順にターゲットが選択され、P2Pアプリ41が2回に1回選択される。図22は、ユースケース3を説明するためのシーケンス図である。ユースケース3は、NFCリーダ12がESE専用のリーダであって、ターゲット候補選択のローテーションがP2Pアプリ41から開始されるケースの例である。図22に示すように、ESE専用のNFCリーダ12からポーリングコマンドが送信されると、候補選択部101は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ41に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ41からESE32に切り替える。そして、CLF31の候補選択部101は、ポーリングコマンドをブロードキャスト送信する。ブロードキャスト送信されたポーリングコマンドは、ESE32及びUICC34にそれぞれ受信される。このとき、ESE32からはレスポンスがあったが、UICC34からは無応答であった場合、候補選択部101は、ターゲット候補として、ESE32を選択し、そのポーリングレスポンスをNFCリーダ12に返信する。なお、ここでは、ターゲット候補として選択されたESE32のIDmがメモリ31Aに記憶される。続いて、NFCリーダ12からリクエストサービス等のポーリング以外のコマンドが送信された場合、確定部102は、受信したコマンドに含まれるIDmと、メモリ31Aに記憶していたIDmとを比較する。そして、確定部102は、IDmが一致するESE32を確定ターゲットとし、そのリクエストサービスをESE32に送信する。ESE32が、リクエストサービスに応じてレスポンスを返信すると、そのレスポンスは、NFCリーダ12に送信される。これにより、ESE専用のNFCリーダ12とESE32が、CLF31を介して、所定のESEトランザクション処理を行うことになる。その後、RF信号が消失した場合、所定のターゲット解除条件を満たすまでは、解除処理は行われず、確定ターゲットが維持される。そして、再度、NFCリーダ12からポーリングコマンドが送信されると、ESE32が確定ターゲットから解除される。また、候補選択部101は、そのポーリングパラメータをチェックして、ポーリングがP2Pアプリ41に対するものではないと判定した場合、ターゲット候補を、P2Pアプリ41からUICC34に切り替える。また、候補選択部101が、そのポーリングコマンドをブロードキャスト送信すると、ESE32及びUICC34によってそれぞれ受信され、ESE32からのみレスポンスが返信される。そこで、候補選択部101は、ターゲット候補として、ESE32を選択し、そのポーリングレスポンスをNFCリーダ12に返信する。続いて、NFCリーダ12からリクエストサービスが送信された場合、確定部102は、IDmの比較を行い、IDmが一致するESE32を確定ターゲットとし、そのリクエストサービスをESE32に送信する。また、ESE32からのレスポンスは、NFCリーダ12に送信される。これにより、ESE専用のNFCリーダ12とESE32が、CLF31を介して、所定のESEトランザクション処理を行うことになる。以上のように、ユースケース3では、ターゲット候補の選択に際して、スキップ機能を含むP2Pメインのローテーション方式が用いられる。すなわち、NFCリーダ12によるポーリングに応じて、ターゲット候補を選択する段階で、ポーリングパラメータがチェックされ、P2Pアプリ41には該当しないので、ESE32又はUICC34がターゲット候補として選択される。そして、ポーリングコマンドをブロードキャスト送信して、レスポンスがあったESE32が確定ターゲットとなり、ESEトランザクション処理が行われる。また、RF信号が消失した場合でも、所定のターゲット解除条件を満たすまでは、確定ターゲットが維持されるため、NFCリーダ12とCLF31の近接通信が復活した場合に処理を継続することができる。なお、図22の例では、ESE専用のリーダについて説明したが、UICC専用のリーダに対する動作は、基本的に、ESE専用のリーダに対する動作と同一の動作となるため、その説明は省略する。このように、スキップ機能を含むP2Pメインのローテーション方式を採用することで、3以上のターゲットのうちの1つのターゲットが、2回に1回、ターゲット候補として選択されるので、NFCリーダ12が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。また、シングルレスポンス方式が用いられることで、CLF31フロントエンドに特別な回路を実装することなく、NFCリーダ12が所望とするターゲットを確実に選択して、迅速に通信を確立することができる。[スキップ機能を含むP2Pメインのローテーション方式の拡張]図23は、拡張版のスキップ機能を含むP2Pメインのローテーション方式のターゲット候補遷移図である。拡張版のスキップ機能を含むP2Pメインのローテーション方式では、前述した図8を参照して説明したESE32,UICC34,P2Pアプリ41に加えて、DH33上に実装されるT3TType3Tagエミュレーションがローテーションに含まれる。この場合であっても、基本的なローテーションは図8と変らず、ターゲットとなる、P2Pアプリ41,ESE32,UICC34,T3Tのうち、P2Pアプリ41が2回に1回必ず選択されることになる。具体的には、図23に示すように、ローテーションの順番が、P2Pアプリ41を中心にして、例えば、P2Pアプリ41,ESE32,P2Pアプリ41,UICC34,P2Pアプリ41,T3T,P2Pアプリ41の順に行われる。また、前述したように、例えば、P2Pアプリ41に対するポーリングではない場合には、ローテーションが、P2Pアプリ41をスキップして、ESE32、UICC34、又はT3Tに、強制的に切り替えられる。このように、P2Pアプリ41以外のターゲットが増えても、P2Pアプリ41を中心にして、P2Pアプリ41が2回に1回必ず選択されるので、NFCリーダ12では、確実にP2Pアプリ41に対する動作が行われることになる。[本技術を適用したコンピュータの説明]前述した一連の処理は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。そこで、図24は、前述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示している。プログラムは、コンピュータ200に内蔵されているハードディスク等の記憶部208やROM202に予め記録しておくことができる。あるいはまた、プログラムは、フレキシブルディスク、CDROM,MOディスク,DVD、磁気ディスク、半導体メモリなどのリムーバブルメディア211に、一時的あるいは永続的に格納記録しておくことができる。このようなリムーバブルメディア211は、いわゆるパッケージソフトウエアとして提供することができる。なお、プログラムは、前述したようなリムーバブルメディア211からコンピュータ200にインストールする他、ダウンロードサイトから、デジタル衛星放送用の人工衛星を介して、コンピュータ200に無線で転送したり、LAN、インターネットといったネットワークを介して、コンピュータ200に有線で転送し、コンピュータ200では、そのようにして転送されてくるプログラムを、通信部209で受信し、記憶部208にインストールすることができる。コンピュータ200は、CPU201を内蔵している。CPU201には、バス204を介して、入出力インタフェース205が接続されており、CPU201は、入出力インタフェース205を介して、ユーザによって、キーボードや、マウス、マイク等で構成される入力部206が操作等されることにより指令が入力されると、それに従って、ROM202に格納されているプログラムを実行する。あるいは、また、CPU201は、記憶部208に格納されているプログラム、衛星若しくはネットワークから転送され、通信部209で受信されて記憶部208にインストールされたプログラム、又はドライブ210に装着されたリムーバブルメディア211から読み出されて記憶部208にインストールされたプログラムを、RAM203にロードして実行する。これにより、CPU201は、前述したフローチャートにしたがった処理、あるいは前述したブロック図の構成により行われる処理を行う。そして、CPU201は、その処理結果を、必要に応じて、例えば、入出力インタフェース205を介して、LCDやスピーカ等で構成される出力部207から出力、あるいは、通信部209から送信、さらには、記憶部208に記録等させる。ここで、本明細書において、コンピュータ200に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理例えば、並列処理あるいはオブジェクトによる処理も含むものである。また、プログラムは、1のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。また、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。さらに、本技術は、以下の構成とすることも可能である。[1]それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記フロントエンドは、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択する通信装置。[2]前記フロントエンドは、前記外部装置からポーリングコマンドを受信した場合、そのコマンドを、前記所定のターゲット以外の複数のターゲットにブロードキャスト送信する[1]に記載の通信装置。[3]前記所定のターゲットは、P2PPeertoPeerのアプリケーションである[1]又は[2]に記載の通信装置。[4]前記複数のターゲットのうち、前記所定のターゲットを除く他のターゲットは、セキュアエレメント及びUICCUniversalIntegratedCircuitCardのいずれか一方又は双方を含んでいる[3]に記載の通信装置。[5]前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットのうち、前記外部装置の通信対象となるターゲットを、前記確定ターゲットとして確定する[1]乃至[4]のいずれかに記載の通信装置。[6]前記フロントエンドは、前記確定ターゲットの候補として選択したターゲットから得られる前記ターゲットの識別子と、前記外部装置が送信したコマンドに含まれる識別子が一致する場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する[5]に記載の通信装置。[7]前記フロントエンドは、前記外部装置から、前記確定ターゲットの候補として選択したターゲットを前記確定ターゲットとして確定するためのコマンドを受信した場合、当該確定ターゲットの候補を、前記確定ターゲットとして確定する[5]に記載の通信装置。[8]前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する[5]乃至[7]のいずれかに記載の通信装置。[9]前記フロントエンドは、前記外部装置との近接通信が切断された後、前記外部装置からポーリングコマンドを受信した場合、前記確定ターゲットを解除する[8]に記載の通信装置。[10]前記フロントエンドは、前記外部装置から、前記外部装置と前記確定ターゲットとの通信を終了するためのコマンドを受信した場合、前記確定ターゲットを解除する[8]に記載の通信装置。[11]それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備える通信装置の制御方法であって、前記フロントエンドが、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択するステップを含む制御方法。[12]それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備える通信装置の制御用のプログラムであって、前記確定ターゲットの候補を選択するためのコマンドの送信を行うに際し、その送信先として、所定のターゲットを2回に1回選択するステップを含む処理を、通信装置のコンピュータに実行させるプログラム。"