JP2014003362A - 情報処理装置および方法、並びにプログラム - Google Patents

Abstract

【課題】異なる通信規格のインタフェースを介した通信をより容易に確立することができるようにする。
【解決手段】本技術の情報処理装置は、接続制御部は、１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、テーブル作成部により作成されたテーブル情報を記憶するテーブル記憶部と、第２の論理チャネルが存在する場合、テーブル記憶部に記憶されている第２の論理チャネルについてのテーブル情報を、第１の論理チャネルを第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部とを備える。本開示は例えば、通信を行う通信装置に適用することができる。
【選択図】図１９

Description

本技術は、情報処理装置および方法、並びにプログラムに関し、特に、異なる通信規格のインタフェースを介した通信をより容易に確立することができるようにした情報処理装置および方法、並びにプログラムに関する。

NFC（Near Field Communication）デバイス内部におけるCLF (Contactless Front-end)に接続するインタフェースとして、HC（(Host Controller Interface）の仕様がETSI（European Telecommunications Standards Institute）SCP（Smart Card Platform）において定義されている。

HCI（Host Controller Interface）規格は、UICC（Universal IC Card）とCLF間のロジカルインタフェースを定義している（例えば、特許文献１参照）。

特開２０１１−１３０４１４号公報

しかしながら、DH-CLF間のロジカルインタフェースは定義されていない。そのため、HCIとは異なる独自の仕様で実装されていることも考えられる。その場合、これらのインタフェースでは、それぞれ管理する情報が異なるため、２つのインタフェースを使って、DHとUICCとの間でCLFを介した通信を行うことが困難である恐れがあった。

本技術は、このような状況に鑑みて提案されたものであり、異なる通信規格のインタフェースを介した通信をより容易に確立することを目的とする。

本技術の一側面は、複数の処理部と、前記複数の処理部間の接続を制御する接続制御部とを備え、前記接続制御部は、１の前記処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部とを備える情報処理装置である。

前記接続制御部は、前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、前記テーブル作成部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、前記テーブル更新部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新することができる。

前記テーブル作成部および前記テーブル更新部は、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第１の論理チャネルに対応する前記第２の論理チャネルが存在するか否かを判定することができる。

前記複数の処理部は、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第１の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第２の処理部とを含み、前記対応表は、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含み、前記テーブル作成部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、前記テーブル更新部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新することができる。

前記論理チャネル確立部は、各処理部との間に、互いに異なる通信規格の論理チャネルを確立することができる。

前記論理チャネル確立部は、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立することができる。

前記論理チャネル確立部は、確立した前記論理チャネルに識別情報を割り当てることができる。

前記接続制御部は、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備えることができる。

前記テーブル情報は、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報であるようにすることができる。

前記テーブル更新部は、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除することができる。

前記テーブル記憶部は、前記テーブル情報を記憶する記憶領域を予め確保することができる。

前記複数の処理部は、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含むことができる。

前記接続制御部は、他の装置と無線通信を行う無線通信部をさらに備えることができる。

本技術の一側面は、また、情報処理装置の情報処理方法において、前記情報処理装置が、１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、作成された前記テーブル情報を記憶し、前記第２の論理チャネルが存在する場合、記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する情報処理方法である。

本技術の一側面は、さらに、コンピュータを、１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部として機能させるプログラムである。

本技術の一側面においては、１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報が、第１の論理チャネルに対応する論理チャネルを指定せずに作成され、作成されたテーブル情報が記憶され、第２の論理チャネルが存在する場合、記憶されている第２の論理チャネルについてのテーブル情報が、第１の論理チャネルを第２の論理チャネルに対応する論理チャネルとするように更新される。

本技術によれば、情報を処理することができる。特に、異なる通信規格のインタフェースを介した通信をより容易に確立することができる。

NFCデバイスの主な構成例を示す図である。 HCIデータパケットの主な構成例を示す図である。 HCIコマンド／レスポンスパケットの主な構成例を示す図である。 HCIコネクション作成コマンドの例を示す図である。 HCIコネクション作成レスポンスの例を示す図である。 HCIコネクション終了コマンドの例を示す図である。 HCIコネクション終了レスポンスの例を示す図である。 NFCEE接続常態通知の例を示す図である。 HCPパケットの主な構成例を示すブロック図である。 E-HCIパイプ作成コマンドの例を示す図である。 E-HCIパイプ作成レスポンスの例を示す図である。 E-HCIパイプオープンコマンドの例を示す図である。 E-HCIパイプオープンレスポンスの例を示す図である。 NFCデバイス内の通信路の例を示す図である。 管理情報の例を示す図である。 コマンドIDとパイプIDの対応表の例を示す図である。 NFCEEプロトコルとゲートIDの対応表の例を示す図である。 NFCデバイス内の接続例を示す図である。 DHからUICCへの接続処理の流れの例を説明するフローチャートである。 NFCデバイス内の接続例を示す図である。 DHからUICCへの接続処理の流れの例を説明するフローチャートである。 UICCからDHへの接続処理の流れの例を説明するフローチャートである。 UICC取り出し処理の流れの例を説明するフローチャートである。 DHによるコネクション終了要求処理の流れの例を説明するフローチャートである。 対応表の実装例を示す図である。 コンピュータの主な構成例を示すブロック図である。

以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（NFCデバイス）
２．第２の実施の形態（コンピュータ）

＜１．第１の実施の形態＞
［１−１ NFCデバイス内部の通信］
NFC（Near Field Communication）デバイス内部においては、DH（Device Host）とUICC（Universal IC Card）がCLF（Contactless Front End）に接続される。ETSI（European Telecommunications Standards Institute）SCP（Smart Card Platform）においては、CLF（Contactless Front End）とUICC（Universal Integrated Circuit Card）との間のロジカルインタフェース（論理インタフェースとも称する）が定義されている（HCI（Host Controller Interface））が、DHとCLFとの間の論理インタフェースは定義されていない。

したがって、DHとCLFとの間に、UICC-CLF間の論理インタフェースとは異なるインタフェースを適用することができる。その場合、DH-UICC間の通信は、異なる２つの論理インタフェースを介して行われることになる。

その場合、これらの論理インタフェースでは、それぞれ管理する情報が異なるため、２つの論理インタフェースを使って、DHとUICCとの間でCLFを介した通信を行うことが困難である恐れがあった。

例えば、DH-UICC間の接続を確立するためには、CLFが、DH-CLF間の論理インタフェースと、UICC-CLF間の論理インタフェースを、適宜関連付ける必要がある。つまり、CLFは、一方との論理インタフェースを確立し、その一方から接続要求を受けて、他方との論理インタフェースを確立し、その２つの論理インタフェースを関連付ける必要がある。

論理インタフェースを確立するためには、相手に対して接続要求や問い合わせをしたり、応答を得るまで待機したりしなければならず、このような手順では、接続のための処理時間が増大してしまう恐れがあった。

また、例えば、UICCがNFCデバイスから着脱可能な場合、CLFは、DHから接続を要求されたときは、UICCが存在しない場合であっても、問い合わせをし、得られるはずのない応答を待たなければならなかった。このような不要な処理により接続処理時間が不要に増大する恐れもあった。

［１−２ CLFによる制御処理］
そこで、複数の処理部と、前記複数の処理部間の接続を制御する接続制御部とを備える情報処理装置において、前記接続制御部が、１の前記処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部とを備えるようにする。

情報処理装置は、上述したような構成を有し、各処理部間で通信を行うものであれば、どのような処理を行う装置であってもよい。また、各処理部がどのような処理を行っても良い。論理チャネルは、任意の通信規格のものであってもよい。

接続制御部は、各処理部との間に確立した論理チャネルを、テーブル情報を用いて適宜関連付ける。これにより、処理部間での通信が可能になる。しかしながら、処理部間での通信開始時にこのような処理を行うと上述したように処理時間が増大してしまう恐れがある。そこで、接続制御部は、処理部間の通信要求を受ける前に、１の処理部との間に確立した論理チャネルについて、そのテーブル情報を作成する。その際、対応関係を結ぶ相手が居ない場合であっても、その相手を特定せずに（「空」のまま）テーブル情報を作成する。対応する相手が存在する場合は、その相手のテーブル情報を更新する。

このようにすることにより、接続制御部は、不要な問い合わせ等の処理を省略することができ、接続処理の処理時間の増大を抑制することができる。したがって、情報処理装置は、異なる通信規格のインタフェースを介した通信をより容易に確立することができる。

例えば、CLFへ接続するための、２つのインタフェース（HCIおよびE-HCI）を使って、DHとUICCがCLF経由で通信できるようになる。具体的には、携帯電話内の端末ホスト（DH）にあるアプリケーションが、UICCにあるアプリケーションのデータにアクセスすることができる。たとえば、電子マネーアプリケーションがUICCにある電子マネーの残高を見たり、決済を行ったりすることができるようになる。

なお、前記接続制御部が、前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、前記テーブル作成部が、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、前記テーブル更新部が、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するようにしてもよい。

このようにすることにより、接続制御部は、論理チャネルを確立するとともに、その論理チャネルについてのテーブル情報を作成したり、その論理チャネルの情報を他の論理チャネルのテーブル情報に反映させたりすることができる。これにより、論理チャネルが確立した直後から、その処理部と他の処理部との通信をより容易に確立することができる。

前記テーブル作成部および前記テーブル更新部が、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第１の論理チャネルに対応する前記第２の論理チャネルが存在するか否かを判定するようにしてもよい。

論理チャネルがどのように形成されるかは、規格によって決定される。したがって、処理部間の通信を確立するには、その通信の目的や仕様等に応じて、適切な論理チャネルを選択し、関連付ける必要がある。そこで、このような論理チャネルとその特徴の対応表を用いることにより、論理チャネル間の関連付けをより容易に行うことができる。

前記複数の処理部が、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第１の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第２の処理部とを含むようにしてもよい。また、前記対応表が、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含むようにしてもよい。さらに、前記テーブル作成部が、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するようにしてもよい。また、前記テーブル更新部が、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するようにしてもよい。

このように、接続制御部は、通信に用いられるプロトコルやアプリケーション等の機能に応じて論理チャネルを関連付けることができる。その場合であっても、接続制御部は、テーブル情報を作成することにより、処理部間の通信をより容易に確立することができる。

前記論理チャネル確立部が、各処理部との間に、互いに異なる通信規格の論理チャネルを確立するようにしてもよい。

上述したように論理チャネルの通信規格は任意であり、論理チャネル確立部は、互いに異なる通信規格の論理チャネルを確立することもできる。その場合であっても、接続制御部は、テーブル情報を作成することにより、処理部間の通信をより容易に確立することができる。

前記論理チャネル確立部が、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立するようにしてもよい。

このようにすることにより、処理部側からの要求に基づいて論理チャネルを確立することができる。これにより、接続制御部は、他の処理部の状況を監視する必要がなく、また、例えば、処理部の一部の機能についてのみ論理チャネルを確立することができる等、柔軟な対応が可能になる。

前記論理チャネル確立部が、確立した前記論理チャネルに識別情報を割り当てるようにしてもよい。

論理チャネルの管理は、識別番号等、所定の識別情報を用いて行うことにより、より容易になる。ただし、管理対象となる論理チャネルは、処理部の接続状況等に応じて適宜変化する可能性があるので、識別情報は適宜割り当てるようにするのが望ましい。このようにすることにより、取り扱う識別情報の数を不要に増大させることを抑制することができ、識別情報の情報量の増大を抑制することができる。

前記接続制御部が、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備えるようにしてもよい。

１度確立した論理チャネルを終了させると、その論理チャネルに関するテーブル情報は削除される。そのため、その論理チャネルを使用する通信が要求された場合、再度その論理チャネルを確立する必要がある。その際、何の情報も無ければ、接続制御部は、そのような論理チャネルが存在するのか否か（確立することができるのか否か）の確認から行わなければならない。そこで、１度確立した論理チャネルの情報を別途保持しておくことにより、接続制御部は、その論理チャネルを再確立する際に、その情報を用いて論理チャネルの状態を元に戻すことができる。これにより、接続制御部は、論理チャネルの作成やオープン等の処理を省略することができ、論理チャネルの状態をより容易に元に戻すことができる。

前記テーブル情報が、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報であるようにしてもよい。

識別情報を利用することにより、テーブル情報の情報量の増大を抑制することができる。これにより、テーブル情報の記憶に必要な記憶容量を低減することができ、コストや負荷を低減させることができる。

前記テーブル更新部が、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除するようにしてもよい。

論理チャネルの確立だけでなく、論理チャネルの切断もテーブル情報に反映させることにより、テーブル情報から現在の論理チャネルの確立状況を把握することができ、より容易に通信を確立することができる。つまり、テーブル情報により対応付けられる論理チャネルの現在の状態の確認等の処理が不要になる。

前記テーブル記憶部が、前記テーブル情報を記憶する記憶領域を予め確保するようにしてもよい。

テーブル情報は、論理チャネルの確立状況に応じて変化するが、予めその記憶領域を確保しておくことにより、容量不足等の不具合の発生を抑制することができる。

前記複数の処理部が、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含むようにしてもよい。

NFCデバイスにおけるDHやUICCと論理チャネルを確立するCLFに対して本技術を適用することができる。

前記接続制御部が、他の装置と無線通信を行う無線通信部をさらに備えるようにしてもよい。

CLFは、非接触通信（近距離無線通信）により他のデバイスとの通信を行うこともできる。

なお、本技術は、情報処理装置としてだけでなく、情報処理方法やプログラムとして実現するようにしてもよい。

［１−３ 概要］
以下のケースにおける、CLFの処理方法について記述する。
1)独自インタフェースHCIの管理情報とE-HCIの管理情報との対応管理および対応付け処理
A)CLFに接続されるDHとUICCの両方からの接続要求によってCLF経由でのDHとUICC間の接続が確立する。
B)HCI又はE-HCIの一方の接続を確立したときに「空」の対応表を作成しておくことで、もう一方の接続要求を受け付けたときにCLFから接続先への問い合わせが不要となり、処理が高速化される。
C)着脱可能なUICCが取り外された際にはCLFからDHへの通知が行われ、接続されていないUICCへデータを送信するなどの無駄な処理を防ぐことができる。
2)DHからUICCへの接続処理手順
A)UICC等の着脱可能なNFCEEとCLF経由で通信するときに、指定したデータ交換形式（プロトコル）に対応する機能を持つゲートへ接続するパイプができているかどうか状況に応じて通信チャネルを確立する。
3)UICCからDHへの接続処理手順
A)DHとCLF経由で通信するときに、指定した機能（ゲート）に対応するデータ交換形式（プロトコル）を持つコネクションができているかどうか状況に応じて通信チャネルを確立する。

DHからの接続とUICCからの接続についての相違点
UICCの場合、どの機能を持っているかを示すゲートIDのリストを取得し、そのリストに列挙されたゲートに対してパイプを作成・オープンするため、可能なものすべてについて通信チャネルを作る。これに対してDHの場合、どれかを選択して通信チャネルを作る。

［１−４ NFCデバイス］
図１は、NFCデバイスの主な構成例を示す図である。NFC（Near Field Communication）デバイス１００は、例えば、携帯電話端末等の、任意の通信装置である。図１に示されるように、NFCデバイス１００は、DH１１１、CLF１１２、およびUICC１１３を有する。

DH（Device Host）１１１は、NFCデバイスを制御するエンティティ（情報処理装置）である。情報処理装置として動作するEmbedded SEでもよい。

CLF（Contactless Front-end）１１２は、外部デバイスとRF（例えば、非接触通信・近距離無線通信等）を介して通信できる機能を持つエンティティ（通信処理装置）である。CLF１１２は、そのRF通信用のアンテナ１３１を有する。

UICC（Universal IC Card）１１３は、NFCデバイス１００に対して着脱可能なデバイス（例えば、携帯電話へ挿入するカード型デバイス）である。

DH１１１およびCLF１１２は、独自のロジカルインタフェース仕様であるHCI（Host Controller Interface）１２１により接続される。また、UICC１１３およびCLF１１２は、ETSI SCPにおいて定義されているE-HCI１２２により接続される。

［１−５ HCI］
HCI１２１は、CLF１１２とDH１１１との間のロジカルインタフェース仕様である。HCI１２１では、DH１１１から見える、NFC処理エンティティをNFCEE（NFC Execution Environment）と称する。NFCEE内部には、複数のプロトコルを処理できるエンティティを持つ。DH１１１がCLF１１２を介して接続されるNFCEEと接続する場合、コネクションを利用してDH１１１とNFCEEのプロトコル処理エンティティを接続する。それぞれのコネクションにはConnection IDという識別子が割り当てられ、CLF１１２が管理する。

DH１１１は、CLF１１２に対してNFCEEを検出するためのコマンドを送信することでCLF１１２が管理するNFCEEの識別子（NFCEE ID）およびNFCEEがサポートするプロトコル（NFCEE Protocol）を取得することができる。

UICC１１３は、NFCEEの１つの形態である。UICC１１３がCLF１１２に接続されると、CLF１１２は、DH１１１に対して、NFCEE IDとNFCEE Protocolを通知する。DH１１１がUICC１１３と接続する場合、上記のNFCEE IDとNFCEE Protocolを指定する。NFCEE Protocolには、例えば、APDU（Application Protocol Data Unit）やT3T（Type 3 Tag）Command等がある。APDUは、ISO（International Organization for Standardization）/IEC（International Electrotechnical Commission）7816-4で定義されるメッセージ構造である。NFC Forum Type 4 Tag Operationで用いられる。T3Tは、NFC Forum Type 3 Tag Operationで定義されるメッセージ構造である。

［１−６ E-HCI］
E-HCI１２２は、ETSI SCPで定義するCLF１１２とUICC１１３との間のロジカルインタフェース規格である。ここでは、E-HCIと称する。E-HCI１２２では、DH１１１やUICC１１３を含むNFC処理エンティティをホストと称する。ホストは、独立した機能を表すゲートを１つ以上持ち、CLF１１２内のゲートと接続してパイプを構成する。

CLF１１２とホストは、パイプを管理するゲートAdministration gateを必須で実装する。ホストは、デバイス内で一意のホストID（Host ID）を持つ。DH１１１とUICC１１３には固定値が割り当てられている。そのためUICC１１３がDH１１１と接続したい場合、ホストID（Host ID）を指定することになる。

［１−７ メッセージ構成］
次に、HCIのメッセージの仕様について説明する。

図２は、HCIのデータパケットの主な構成例を示す図である。このパケットは、Connection IDにより指定される論理チャネル上で交換されるメッセージの転送に使用される。

図２において、PBF（Packet Boundary Flag）は、次のパケットが連続するかどうかを示す情報である。また、Connection IDは、論理チャネルを識別する識別情報である。RFU（Reserved for future use）は、拡張用領域である。Payload Lengthは、Payloadの長さを示す情報である。Payloadは、上位層のメッセージを格納する。メッセージの形式は、使用するNFCEE Protocolによって異なる。

図３は、HCIコマンド／レスポンスパケットの主な構成例を示す図である。このパケットは、HCIのコマンド又はレスポンスを転送するために使用される。

図３において、TYPEは、パケットの内容を示す情報である。TYPEは、「要求」を表す値「001b」、「応答」を表す値「010b」、「通知」を表す「011b」のいずれかにセットされる。PBF（Packet Boundary Flag）は、次のパケットが連続するかどうかを示す情報である。GID（Group ID）は、このパケットがどの機能分類かを示す情報である。OID（Opcode ID）は、このパケットの機能を示す情報である。RFU（Reserved for future use）は、拡張用領域であり、Payload Lengthは、Payloadの長さを示す。Payloadは、コマンド又はレスポンスのパラメータを格納する。

以下に、このパケットで伝送される情報の例を示す。

図４は、HCIコネクション作成コマンドの例を示す図である。図４において、NFCEE IDは、事前に、CLF１１２からDH１１１へ通知されるものとする。NFCEE Protocolには、アプリケーションが交換するメッセージ形式に応じて、APDU（‘00’）や、T3T Command（‘02’）がセットされる。

図５は、HCIコネクション作成レスポンスの例を示す図である。図６は、HCIコネクション終了コマンドの例を示す図である。図７は、HCIコネクション終了レスポンスの例を示す図である。図８は、NFCEE接続常態通知の例を示す図である。

次に、E-HCIのメッセージの仕様について説明する。

図９は、E-HCIのHCPパケットの主な構成例を示すブロック図である。このパケットは、パイプID（Pipe ID）で指定された論理チャネル上で交換されるメッセージの転送に使用される。交換されるメッセージには、コマンド及びレスポンスも含まれる。

図９において、CB（Chaining Bit）は、次のパケットが連続するかどうかを示す情報である。pID（Pipe ID）は、このパケットが転送されるパイプを識別する識別情報である。TYPEは、このパケットの種類を示す（コマンド、レスポンス又はイベント）情報である。INSTRUCTIONは、このパケットの機能を示す情報である。Dataは、上位層のメッセージを格納する。メッセージの形式はCLFのゲートIDによって異なる。

以下に、このパケットで伝送される情報の例を示す。

図１０は、E-HCIパイプ作成コマンドの例を示す図である。接続先のゲートIDを指定するため、UICC１１３は事前にCLF１１２上のIdentity management gateからゲートIDのリストを取得しておく。ETSIにおいてDH１１１へ接続するためのゲートIDは未定義であるため、独自のゲートID定義が必要である。たとえば、次のように定義する。

T4AT wired gate ID = ‘F0’
T4BT wired gate ID = ‘F1’
T3T wired gate ID = ‘F2’

図１１は、E-HCIパイプ作成レスポンスの例を示す図である。図１２は、E-HCIパイプオープンコマンドの例を示す図である。図１３は、E-HCIパイプオープンレスポンスの例を示す図である。

［１−８ ロジカルチャネル確立処理］
DH１１１とUICC１１３との間で通信するための論理的な通信路を、論理チャネル（またはロジカルチャネル）と称する。DH１１１とCLF１１２との間では独自のコマンドを利用し、UICC１１３とCLF１１２との間ではE-HCIで定義されたコマンドを利用するものとする。

図１４は、NFCデバイス内部のシステム構成例を示す図である。

DH１１１は、任意のアプリケーションを実装する事ができるが、図１４においては、一例として、T4T（APDU）コマンドベースのアプリケーションであるT4Tアプリケーション（T4T application）２１１と、T3TコマンドベースのアプリケーションであるT3Tアプリケーション（T3T application）２１２とが実装されるものとする。

また、DH１１１とCLF１１２との間には、任意のコネクションが実装可能であるが、図１４においては、一例として、DH-UICC間の通信用のコネクションであるT4Tコネクション（T4T conn）２２１およびT3Tコネクション（T3T conn）２２２、並びに、RF通信用のコネクションであるRFコネクション（RF conn）２２３が実装されるものとする。

さらに、CLF１１２は、任意のゲートを実装する事ができるが、図１４においては、一例として、タイプA RFカードゲート（Type A RF card gate）２４１およびタイプB RFカードゲート（Type B RF card gate）２４３を実装するものとする。CLF１１２は、さらに、E-HCIに定義済みのタイプF RFカードゲート（Type F RF card gate）２４５を実装するものとする。また、CLF１１２は、DH１１１とUICC１１３との間の通信用として、T4Tワイヤードゲート（Type 4 Tag（T4T）wired gate（独自））２４２と、T3Tワイヤードゲート（Type 3 Tag (T3T) wired gate （独自））２４４とを実装するものとする。

また、UICC１１３は、任意のゲートを実装する事ができるが、図１４においては、一例として、例えばタイプA RFカードゲート（Type A RF card gate）２４１を制御するタイプAカードアプリケーションゲート（Type A card application gate）２５１を実装するものとする。また、UICC１１３は、例えばタイプB RFカードゲート（Type B RF card gate）２４２を制御するタイプBカードアプリケーションゲート（Type B card application gate）２５２を実装するものとする。さらに、UICC１１３は、例えばタイプF RFカードゲート（Type F RF card gate）２４５を制御するタイプFカードアプリケーションゲート（Type F card application gate）２５３を実装するものとする。

なお、図１４においては、CLF１１２とUICC１１３との間には、タイプA RFパイプ（Type A RF pipe）、タイプB RFパイプ（Type B RF pipe）、タイプF RFパイプ（Type F RF pipe）、T4TAパイプ（T4TA pipe）、T4TBパイプ（T4TB pipe）、およびT3Tパイプ（T3T pipe）を作成済みとする。

Type A RF pipeは、Type A RF card gate２４１とType A application gate２５１との間のパイプである。Type B RF pipeは、Type B RF card gate２４３とType B application gate２５２との間のパイプである。Type F RF pipeは、Type F RF card gate２４５とType F application gate２５３との間のパイプである。

T4TA pipeは、T4T wired gate２４２とType A application gate２５１との間のパイプである。T4TB pipeは、T4T wired gate２４２とType B application gate２５２との間のパイプである。T3T pipeは、T3T wired gate２４４とType F application gate２５３との間のパイプである。

また、UICC１１３には、任意のアプリケーションを実装することができるが、図１４においては、一例として、APDUコマンドベースのアプリケーションであるAPDUアプリケーション（APDU application）２６１と、T3TコマンドベースのアプリケーションであるタイプFアプリケーション（Type F application）２６２とが実装されるものとする。

DH１１１上のT4T application２１１とUICC１１３上のAPDU application２６１は、どちらもAPDUを処理できるアプリケーションであるため、これらを論理チャネルで接続することができる。

また、DH１１１上のT3T application２１２とUICC１１３上のType F application２６２は、どちらもT3Tコマンドを処理できるアプリケーションであるため、これらを論理チャネルで接続することができる。

［１−９ HCIの管理情報とE-HCIの管理情報との対応管理］
HCIとE-HCIでは、図１５に示される表のように、それぞれ別の情報が管理されている。２つのインタフェースを実装するCLF１１２は、次のように、これらの情報の対応付けを行う。コネクションIDとパイプIDの例については、図１６に示す。また、NFCEEプロトコルとゲートIDの例については、図１７に示す。

［１−１０ DHからUICCへの接続処理］
DH１１１は、UICC１１３との通信が必要な場合に、UICC１１３への接続処理を行うものとする。DH１１１からUICC１１３へ論理チャネルを確立する場合、DH１１１は、CLF１１２に対して、コネクション作成コマンド（パラメータ：NFCEE ID，NFCEE Protocol）を送信する。

CLF１１２は、指定されたNFCEE Protocolに対応するE-HCIパイプができている場合、対応するコネクションを作成し、コネクション作成コマンド応答（Status=OK）で応答する。パイプがない場合、エラーで応答する。E-HCIでは、CLF１１２からUICC１１３に対して、パイプを作成する機能がないため、事前に、UICC１１３挿入時などの初期化中に、UICC１１３（ホスト）がパイプを作成しておく必要がある。

［１−１１ T4T/APDU application間論理チャネルの確立］
図１８に示される例のように、DH１１１上のT4T application２１１がUICC１１３上のAPDU application２６１と論理チャネルを確立する場合、DH１１１が送信するコネクション作成コマンドにおいて、NFCEE ID=UICC，NFCEE Protocol=T4Tを指定する。

この場合、NFCEE ProtocolにT4Tが指定されたので、CLF１１２はT4T Connection ID２２１、２３１のコネクションを作成し、NFCEE Protocol = T4Tに基づくT4T wired gate２４２に接続されるパイプがあれば、T4TA pipe ID、T4TB pipe IDともリンクさせる。リンクができた場合、正常終了ステータスのコネクション作成コマンド応答をDH１１１へ送信する。パイプがなくリンクができない場合は、エラーステータスを含むコネクション作成コマンド応答をDH１１１へ送信する。

なお、プロトコル・ゲートID対応表は固定的に保持している。また、コネクション作成要求時、プロトコルに対応するゲートIDを探す。ゲートIDに対応するパイプIDとコネクションIDを関連付ける。プロトコルに対応するゲートIDが複数見つかった場合、1つのコネクションIDと関連付ける。

図１９のフローチャートを参照して、DHからUICCへの接続処理の流れの例を説明する。

UICC１１３がNFCデバイス１００の所定位置に装着されると、ステップＳ１０１において、CLF１１２は、UICC１１３に対して、Identityゲートへのパイプオープン要求を行う。ステップＳ１０２において、CLF１１２は、UICC１１３に対して、IdentityゲートへのゲートIDリスト取得要求を行う。CLF１１２は、この要求に対してUICC１１３から供給されたゲートIDリストを取得し、保持する。

ステップＳ１０３において、UICC１１３は、CLF１１２に対して、DH接続ゲートへのパイプ作成要求を行う。その際、UICC１１３は、Dest host ID，Dest gate ID，source host ID、およびsource gate IDを供給する。

ステップＳ１０４において、CLF１１２は、その要求に応じて、DH接続ゲートへのパイプを作成する。また、CLF１１２は、供給されたDest gate IDを、DH接続ゲートのゲートIDに対応するパイプIDに割り当て、表４０１を作成する。

ステップＳ１０５において、CLF１１２は、予め記憶しているプロトコル・ゲートID対応表４０４を参照し、要求されたDest gate IDに対応するプロトコルが存在するか否かを判定する。プロトコルが存在すると判定された場合、処理は、ステップＳ１０６に進む。

ステップＳ１０６において、CLF１１２は、既に作成済みの（記憶している）、そのプロトコルのコネクションIDに関するコネクションIDとパイプIDの対応表（テーブル情報）４０２を更新する。より具体的には、CLF１１２は、その対応表４０２の、要求されたDest gate IDに対応するプロトコルに対応するパイプIDの欄に、要求されたDest gate ID（ステップＳ１０４において設定したパイプID）を追加する。対応表４０２の更新が終了すると、処理は、ステップＳ１０８に進む。

また、ステップＳ１０５において、要求されたDest gate IDに対応するプロトコルが存在しないと判定された場合、処理は、ステップＳ１０７に進む。

ステップＳ１０７において、CLF１１２は、要求されたDest gate IDに関する、コネクションIDとパイプIDの対応表（テーブル情報）４０２を作成し、記憶する。その際、要求されたDest gate IDに対応付けるコネクションIDは未定であるので、CLF１１２は、「空」（empty）のコネクションIDをパイプID（Dest gate ID）に関連付ける。この「空」（empty）を示す値は任意である。ステップＳ１０７の処理が終了すると、処理はステップＳ１０８に進む。

このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF１１２は、パイプが確立次第、対応表４０２を作成する。これにより、CLF１１２は、DH１１１から接続要求があった場合に、この対応表４０２を用いて容易に通信を確立することができる。

ステップＳ１０８において、CLFは、他のパイプを作成するか否かを判定する。他のパイプを作成すると判定された場合、処理は、ステップＳ１０３に戻る。つまり、作成するパイプの数だけステップＳ１０３乃至ステップＳ１０８の処理が繰り返される。

ステップＳ１０８において、他のパイプを作成しないと判定された場合、処理は、ステップＳ１０９に進む。

ステップＳ１０９においてDH１１１からUICC接続用コネクション作成要求を取得すると、CLF１１２は、ステップＳ１１０において、その要求において指定されたプロトコルのUICC接続用コネクションを作成する。また、CLF１１２は、作成したコネクションに対してコネクションIDを割り当て、そのプロトコルと、そのコネクションIDとを関連付ける対応表４０３を作成し、記憶する。

ステップＳ１１１において、CLF１１２は、予め記憶しているプロトコル・ゲートID対応表４０４を参照し、要求されたプロトコルに対応するゲートが存在するか否かを判定する。ゲートが存在すると判定された場合、処理は、ステップＳ１１２に進む。

ステップＳ１１２において、CLF１１２は、既に作成済みの（記憶している）、そのゲートに関するコネクションIDとパイプIDの対応表（テーブル情報）４０２を更新する。より具体的には、CLF１１２は、その対応表４０２の、要求されたプロトコルに対応するゲートに対応するコネクションIDの欄に、ステップＳ１１０において割り当てられたコネクションIDを追加する。図１９の例の場合、対応表４０２が更新され、対応表４０５となる。CLF１１２は、この対応表４０５を記憶する。対応表４０２の更新が終了すると、この接続処理が終了する。

また、ステップＳ１１１において、要求されたプロトコルに対応するゲートが存在しないと判定された場合、処理は、ステップＳ１１３に進む。

ステップＳ１１３において、CLF１１２は、要求されたプロトコルに関する、コネクションIDとパイプIDの対応表（テーブル情報）４０２を作成し、記憶する。その際、要求されたプロトコルに対応付けるパイプIDは未定であるので、CLF１１２は、「空」（empty）のパイプIDをそのコネクションIDに関連付ける。この「空」（empty）を示す値は任意である。ステップＳ１１３の処理が終了すると、この接続処理が終了する。

このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF１１２は、コネクションが確立次第、対応表４０２を作成する。これにより、CLF１１２は、UICC１１３から接続要求があった場合に、この対応表４０２を用いて容易に通信を確立することができる。

なお、上述した各種対応表等の情報を記憶する記憶領域は、CLF１１２からアクセス可能な場所であれば、任意の場所に設けることができる。例えば、CLF１１２内部にその記憶領域を設けてもよいし、CLF１１２の外部に設けるようにしてもよい。

［１−１２ T3T/Type F application間論理チャネルの確立］
図２０に示されるように、DH１１１上のT3T application２１２がUICC１１３上のType F application２６２と論理チャネルを確立する場合、DH１１１が送信するコネクション作成コマンドにおいて、NFCEE ID=UICC，NFCEE Protocol=T3Tを指定する。

この場合、NFCEE ProtocolにT3Tが指定されたので、CLF１１２はT3T Connection ID２２２、２３２のコネクションを作成し、NFCEE Protocol = T3Tに基づくT3T wired gate２４４に接続されるパイプがあれば、T3T pipe IDともリンクさせる。リンクができた場合、正常終了ステータスのコネクション作成コマンド応答をDH１１１へ送信する。パイプがなくリンクができない場合、CLF１１２は、エラーステータスを含むコネクション作成コマンド応答をDH１１１へ送信する。

この場合のDHからUICCへの接続処理の流れは、図２１に示されるように、図１９を参照して説明した場合と同様である。

ステップＳ１０４において、CLF１１２は、T3T wired gate２４４にパイプID「１２」を割り当て、表４２１を作成する。

ステップＳ１０５において、CLF１１２は、予め記憶しているプロトコル・ゲートID対応表４２４を参照し、T3T wired gate２４４に対応するプロトコルが存在するか否かを判定する。

ステップＳ１０６において、CLF１１２は、既に作成済みの（記憶している）、プロトコルT3TのコネクションIDに関するコネクションIDとパイプIDの対応表（テーブル情報）４２２を更新する。

ステップＳ１０７において、CLF１１２は、T3T wired gate２４４に関する、コネクションIDとパイプIDの対応表（テーブル情報）４２２を作成し、記憶する。より具体的には、CLF１１２は、例えば、対応表４２１で割り当てられたパイプID「１２」に対して、「空」（empty）のコネクションIDをパイプID（Dest gate ID）に関連付ける対応表４２２を作成する。

このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF１１２は、パイプが確立次第、対応表４２２を作成する。これにより、CLF１１２は、DH１１１から接続要求があった場合に、この対応表４２２を用いて容易に通信を確立することができる。

CLF１１２は、ステップＳ１１０において、T3TのUICC接続用コネクションを作成し、その作成したコネクションに対してコネクションID「０５」を割り当て、そのT3TとコネクションIDとを関連付ける対応表４２３を作成し、記憶する。

ステップＳ１１１において、CLF１１２は、予め記憶しているプロトコル・ゲートID対応表４２４を参照し、プロトコルT3Tに対応するゲートが存在するか否かを判定する。

ステップＳ１１２において、CLF１１２は、既に作成済みの（記憶している）対応表４２２の、要求されたプロトコルT3Tに対応するパイプID「１２」に対応するコネクションIDの欄に、ステップＳ１１０において割り当てられたコネクションID「０５」を追加する。

ステップＳ１１３において、CLF１１２は、要求されたプロトコルT3Tに関する、コネクションID「０５」と、「空」（empty）のパイプIDの対応表（テーブル情報）４２２を作成し、記憶する。

このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF１１２は、コネクションが確立次第、対応表４２２を作成する。これにより、CLF１１２は、UICC１１３から接続要求があった場合に、この対応表４２２を用いて容易に通信を確立することができる。

［１−１３ DHからUICCへのパケット送信処理］
DH１１１上のアプリケーションは、以上のように作成したコネクションを用いて、UICC１１３上の対応アプリケーションへパケットを送信する。T4T application２１１がUICC１１３へパケットを送信する場合、T4T Connection IDを指定して、パケットを送信する。

CLF１１２は、T4T Connection IDのコネクションで受け取ったパケットを、対応するE-HCIパイプである、T4TA pipe IDとT4TB pipe IDのE-HCIパイプ（存在するパイプ）へ送信する。このとき、CLF１１２は、HCIのヘッダを、E-HCIのヘッダに置き換える処理を行う。

［１−１４ UICCからDHへの接続処理］
次に、UICC１１３からDH１１１への接続処理について説明する。この処理は、DH１１１がUICC１１３へのコネクションを作成するよりも前に、UICC１１３挿入時に行われるものとする。

UICC１１３からDH１１１へ論理チャネルを確立する場合、UICC１１３は、CLF１１２に対して、ADM_CREATE_PIPEを送信する。CLF１１２は、指定されたゲートが実装されている場合に、ANY_OKおよび作成したパイプのpipe IDで応答する。

パイプ作成後、そのパイプを開放するために、UICC１１３はANY_OPEN_PIPEを送信し、CLFはANY_OKで応答する。指定されたゲートが実装されていることで、DH１１１へ論理チャネルを確立できることとする。Conn IDが15個と限られているため、動的に作成することで、そのリソースを効率的に使うことができる。

HCIでは、E-HCIと同様に、CLF１１２からDH１１１に対して、コネクションを作成する機能がないため、事前に、たとえば、DH１１１起動時の初期化中に、DH１１１がコネクションを作成しておく必要がある。

UICC１１３から接続する場合は、UICC１１３がCLF１１２にあるゲートのリストを取得するため、CLF１１２にあるゲートすべてについて、論理チャネルを確立することになる。

［１−１５ APDU/T4T application間論理チャネルの確立］
図１８において、上述した例とは逆に、UICC１１３上のAPDU application２６１がDH１１１上のT4T application２１１と論理チャネルを確立する場合、UICC１１３が送信するADM_CREATE_PIPEにおいて、destination HID=DH、destination GID=T4T wired gate、source GID=Type A、および／または、Type B card application gateを指定する。ここで指定するGIDは、仮想的にDH上にT4T wired gate２４２があるように指定する。

この場合、CLF１１２はT4T Connection IDのコネクションを作成し、destination GIDに基づいてT4T wired pipe ID（T4TA wired pipe又はT4BT wired pipe）とリンクさせる。

図２２のフローチャートを参照して、UICCからDHへの接続処理の流れの例を説明する。

この場合の接続処理は、図１９のフローチャートを参照して説明したDHからUICCへの接続処理の各ステップの処理と同様の処理が、処理順を入れ替えて行われる。

より具体的には、ステップＳ２０１乃至ステップＳ２０５において、図１９のステップＳ１０９乃至ステップＳ１１３の各処理と同様の処理が行われ、その後、ステップＳ２０６乃至ステップＳ２１２において、図１９のステップＳ１０１乃至ステップＳ１０６の各処理と同様の処理が行われる。

なお、図２２の例の場合、ステップＳ２１０において、要求されたDest gate IDに対応するプロトコルが存在しないと判定された場合、ステップＳ１０７と同様の処理は行われずに、処理はステップＳ２１２に進む。

以上の処理の流れのより具体的な例について説明する。ステップＳ２０１においてDH１１１からUICC接続用コネクション作成要求を取得すると、CLF１１２は、ステップＳ２０２において、その要求において指定されたプロトコル「APDU」のUICC接続用コネクションを作成する。また、CLF１１２は、作成したコネクションに対してコネクションID「０４」を割り当て、そのプロトコルと、そのコネクションIDとを関連付ける対応表４４１を作成し、記憶する。

また、要求されたプロトコルに対応するゲートが存在する場合、CLF１１２は、ステップＳ２０４において、要求されたプロトコルに対応するコネクションID「０４」と、そのゲートのパイプIDの対応表（テーブル情報）４４２を作成し、記憶する。

さらに、要求されたプロトコルに対応するゲートが存在しない場合、CLF１１２は、ステップＳ２０５において、要求されたプロトコルに対応するコネクションID「０４」と、「空」（empty）パイプIDの対応表（テーブル情報）４４２を作成し、記憶する。

このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF１１２は、コネクションが確立次第、対応表４４２を作成する。これにより、CLF１１２は、UICC１１３から接続要求があった場合に、この対応表４４２を用いて容易に通信を確立することができる。

また、ステップＳ２０７において、CLF１１２は、UICC１１３に対して、IdentityゲートへのゲートIDリスト取得要求を行う。CLF１１２は、この要求に対してUICC１１３から供給されたゲートIDリストを取得し、保持する。

ステップＳ２０９において、CLF１１２は、その要求に応じて、DH接続ゲートへのパイプを作成する。また、CLF１１２は、供給されたDest gate IDをパイプID「１０、１１」としてゲートIDに関連付け、表４４３を作成する。

さらに、ステップＳ２１０において、CLF１１２は、予め記憶しているプロトコル・ゲートID対応表４４４を参照し、要求されたDest gate IDに対応するプロトコルが存在するか否かを判定する。プロトコルが存在すると判定された場合、処理は、ステップＳ２１１に進む。

ステップＳ２１１において、CLF１１２は、既に作成済みの（記憶している）、そのプロトコルのコネクションIDに関するコネクションIDとパイプIDの対応表（テーブル情報）４４２を更新する。より具体的には、CLF１１２は、その対応表４４２の、コネクションID「０４」に対応するパイプIDの欄に、要求されたDest gate ID「１０、１１」を追加する。対応表４４２の更新が終了すると、処理は、ステップＳ２１２に進む。

［１−１６ Type F/T3T application間論理チャネルの確立］
図２０において、上述した例とは逆に、UICC１１３上のType F application２６２がDH１１１上のT3T application２１２と論理チャネルを確立する場合は、UICC１１３が送信するADM_CREATE_PIPEにおいて、destination HID=DH、destination GID=T3T wired gate、source GID=Type F card application gateを指定する。ここで指定するGIDは、仮想的にDH１１１上にT3T wired gate２４４があるように指定する。

この場合、CLF１１２はT3T Connection IDのコネクションを作成し、destination GIDに基づいてT3T wired pipe IDとリンクさせる。

この場合の接続処理は、図２２のフローチャートを参照して説明した場合と同様に行われるので、その説明は省略する。

［１−１７ UICCからDHへのパケット送信処理］
UICC１１３上のアプリケーションは、成就したE-HCIパイプを用いて、DH１１１上の対応アプリケーションへパケットを送信する。APDU application２６１がDH１１１へパケットを送信する場合、作成したT4TA wired pipeまたはT4TB wired pipeを指定して、パケットを送信する。

２つの経路はどちらを使ってもよい。たとえば、別のアプリケーションがT4TB wired pipeを使っているときに、並行してT4TA wired pipeの経路でDHへパケットを送信することができる。このとき、CLF１１２は、E-HCIのヘッダを、HCIのヘッダに置き換える処理を行う。

［１−１８ UICC取り出し処理］
UICC１１３が取り外された場合、CLF１１２からDH１１１に対して通知を行う。これにより、コネクションIDとパイプIDの対応を適時に更新することができ、実際には接続されていないエンティティへのデータ送信を行うなどの不整合な処理を防ぐことができる。CLF１１２からDH１１１へのUICC１１３取り出し通知は、図８で示される形式で通知される。

図２３のフローチャートを参照して、UICC取り出し処理の流れの例を説明する。ステップＳ３０１において、CLF１１２は、DH１１１に対して、UICC１１３が取り外されたことを通知する。

ステップＳ３０２において、CLF１１２は、コネクションIDとパイプIDの対応表（テーブル情報）から、取り外されたUICC１１３に対応するパイプIDの情報を削除する。例えば、対応表４６１が保持されているとする。UICC１１３が取り外されることにより、パイプID「１０」と「１１」が削除されるとすると、CLF１１２は、対応表４６２に示されるように、それらのパイプIDの代わりに「空」（Empty）を示す値をセットする。ステップＳ３０２の処理が終了すると、UICC取り出し処理が終了する。

このようにして、対応するパイプが存在しなくなったコネクションIDの対応表を維持する。これにより、CLF１１２は、再度UICC１１３がセットされた場合に、この対応表４６２を用いて容易に通信を確立することができる。

［１−１９ DHからのコネクション終了要求］
DH１１１からコネクション終了コマンドを送信することによって、UICC１１３と接続している通信チャネルを切断することができる。その場合、CLF１１２は、コネクションIDとパイプIDの対応を更新する。

図２４のフローチャートを参照して、DHによるコネクション終了要求処理の流れの例を説明する。ステップＳ３２１において、CLF１１２は、DH１１１から供給されるコネクション終了コマンドを取得する。コネクション終了コマンドにおいては、終了するコネクションが、コネクションIDを用いて指定される。

ステップＳ３２２において、その要求に基づいて、CLF１１２は、コネクションIDとパイプIDの対応表（テーブル情報）を更新する。すなわち、指定されたコネクションIDの情報を、対応表から削除する。例えば、対応表４８１が保持されているとする。コネクションID「０４」のコネクションの終了が要求されると、CLF１１２は、対応表４８２に示されるように、そのコネクションID「０４」の代わりに「空」（Empty）を示す値をセットする。ステップＳ３２２の処理が終了すると、DHによるコネクション終了要求処理が終了する。

このようにして、対応するパイプが存在しなくなったパイプIDの対応表を維持する。これにより、CLF１１２は、再度DH１１１からUICC１１３との通信を要求された場合に、この対応表４８２を用いて容易に通信を確立することができる。

［１−２０ パイプの状態の記憶］
ETSIに従い、CLF１１２はパイプの状態を不揮発に記憶しておくことが必須となっている。UICC１１３が挿入されたときに、CLF１１２はUICC１１３との間でSWPインタフェースの活性化を行い、その間にUICC１１３から送信される２バイトのSYNC IDを保持しておく。さらに、パイプの作成・オープンを行った場合、CLF１１２は、そのSYNC IDに関連付けて、作成・オープンしたパイプのID及び状態を保持しておく。

少なくとも１つの保持したSYNC IDが、UICCから送信されたSYNC IDと一致した場合、CLF１１２は、以前挿入されたUICCだと判断し、保持しておいたパイプの状態を元に戻す。これによって、パイプ作成・オープンの手続きを省略することができる。

［１−２１ 対応表の実装例］
CLF１１２は、固定のメモリをパイプIDとコネクションIDの対応表のために確保しておく。例えば、CLF１１２は、図２５に示されるように、１６個のパイプIDに対するエントリを確保しておき、すべての値を‘FF’に設定しておく。

UICC１１３からパイプ作成が要求された場合、CLF１１２は、指定されたゲートIDに対応するプロトコルを持つコネクションが見つかったとき、対応するエントリに、パイプIDとそれに関連付けるコネクションIDを書き込む。

見つからないとき、CLF１１２は、パイプIDとコネクションIDの両方が‘FF’になっているエントリに対して、パイプIDとそれに関連付けるコネクションIDを書き込む。

DH１１１からコネクション作成が要求された場合、CLF１１２は、指定されたプロトコルに対応するゲートIDを持つパイプが見つかったとき、対応するエントリに、コネクションIDとそれに関連付けるパイプIDを書き込む。

見つからないとき、CLF１１２は、パイプIDとコネクションIDの両方が‘FF’になっているエントリに対して、コネクションIDとそれに関連付けるパイプIDを書き込む。

パイプ削除が要求された場合、CLF１１２は、要求されたパイプIDと同じ値を見つけたら、‘FF’に設定する。コネクション削除が要求された場合、CLF１１２は、要求されたコネクションIDと同じ値を見つけたら、‘FF’に設定する。

＜４．第４の実施の形態＞
［コンピュータ］
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。

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

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

バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。

入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。

以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

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

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

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

また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

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

また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

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

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

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

なお、本技術は以下のような構成も取ることができる。
（１） 複数の処理部と、
前記複数の処理部間の接続を制御する接続制御部と
を備え、
前記接続制御部は、
１の前記処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
を備える情報処理装置。
（２） 前記接続制御部は、
前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、
前記テーブル作成部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
前記テーブル更新部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する
前記（１）に記載の情報処理装置。
（３） 前記テーブル作成部および前記テーブル更新部は、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第１の論理チャネルに対応する前記第２の論理チャネルが存在するか否かを判定する
前記（２）に記載の情報処理装置。
（４） 前記複数の処理部は、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第１の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第２の処理部とを含み、
前記対応表は、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含み、
前記テーブル作成部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在しないときは、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
前記テーブル更新部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第１の論理チャネルに対応する論理チャネルとするように更新する
前記（３）に記載の情報処理装置。
（５） 前記論理チャネル確立部は、各処理部との間に、互いに異なる通信規格の論理チャネルを確立する
前記（２）乃至（４）のいずれかに記載の情報処理装置。
（６） 前記論理チャネル確立部は、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立する
前記（２）乃至（５）のいずれかに記載の情報処理装置。
（７） 前記論理チャネル確立部は、確立した前記論理チャネルに識別情報を割り当てる
前記（２）乃至（６）のいずれかに記載の情報処理装置。
（８） 前記接続制御部は、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備える
前記（２）乃至（７）のいずれかに記載の情報処理装置。
（９） 前記テーブル情報は、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報である
前記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０） 前記テーブル更新部は、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除する
前記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１） 前記テーブル記憶部は、前記テーブル情報を記憶する記憶領域を予め確保する
前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２） 前記複数の処理部は、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含む
前記（１）乃至（１１）のいずれかに記載の情報処理装置。
（１３） 前記接続制御部は、他の装置と無線通信を行う無線通信部をさらに備える
前記（１）乃至（１２）のいずれかに記載の情報処理装置。
（１４） 情報処理装置の情報処理方法において、
前記情報処理装置が、
１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
作成された前記テーブル情報を記憶し、
前記第２の論理チャネルが存在する場合、記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する
情報処理方法。
（１５） コンピュータを、
１の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
して機能させるプログラム。

１００ NFCデバイス， １１１ DH， １１２ CLF， １１３ UICC， １２１ HCI， １２２ E-HCI， １３１ アンテナ

Claims (15)

1. 複数の処理部と、
   前記複数の処理部間の接続を制御する接続制御部と
   を備え、
   前記接続制御部は、
   １の前記処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
   前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
   前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
   を備える情報処理装置。
2. 前記接続制御部は、
   前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、
   前記テーブル作成部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
   前記テーブル更新部は、前記論理チャネル確立部により前記第１の論理チャネルが確立した場合、前記第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する
   請求項１に記載の情報処理装置。
3. 前記テーブル作成部および前記テーブル更新部は、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第１の論理チャネルに対応する前記第２の論理チャネルが存在するか否かを判定する
   請求項２に記載の情報処理装置。
4. 前記複数の処理部は、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第１の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第２の処理部とを含み、
   前記対応表は、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含み、
   前記テーブル作成部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在しないときは、前記第１の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
   前記テーブル更新部は、前記論理チャネル確立部により前記第１の処理部との間に第１の論理チャネルが確立した場合、前記対応表に基づいて、前記第２の処理部との間に確立した、前記第１の論理チャネルの機能に対応するプロトコルの第２の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する
   請求項３に記載の情報処理装置。
5. 前記論理チャネル確立部は、各処理部との間に、互いに異なる通信規格の論理チャネルを確立する
   請求項２に記載の情報処理装置。
6. 前記論理チャネル確立部は、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立する
   請求項２に記載の情報処理装置。
7. 前記論理チャネル確立部は、確立した前記論理チャネルに識別情報を割り当てる
   請求項２に記載の情報処理装置。
8. 前記接続制御部は、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備える
   請求項２に記載の情報処理装置。
9. 前記テーブル情報は、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報である
   請求項１に記載の情報処理装置。
10. 前記テーブル更新部は、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除する
    請求項１に記載の情報処理装置。
11. 前記テーブル記憶部は、前記テーブル情報を記憶する記憶領域を予め確保する
    請求項１に記載の情報処理装置。
12. 前記複数の処理部は、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含む
    請求項１に記載の情報処理装置。
13. 前記接続制御部は、他の装置と無線通信を行う無線通信部をさらに備える
    請求項１に記載の情報処理装置。
14. 情報処理装置の情報処理方法において、
    前記情報処理装置が、
    １の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成し、
    作成された前記テーブル情報を記憶し、
    前記第２の論理チャネルが存在する場合、記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新する
    情報処理方法。
15. コンピュータを、
    １の処理部との間に確立した第１の論理チャネルに対応する、他の処理部との間に確立した第２の論理チャネルが存在しない場合、前記第１の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第１の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
    前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
    前記第２の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第２の論理チャネルについての前記テーブル情報を、前記第１の論理チャネルを前記第２の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
    して機能させるプログラム。

Images