以下、本開示を実施するための形態(以下実施の形態とする)について説明する。なお、説明は以下の順序で行う。
1.第1の実施の形態(NFCデバイス)
2.第2の実施の形態(コンピュータ)
<1.第1の実施の形態>
[1−1 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間の通信は、異なる2つの論理インタフェースを介して行われることになる。
その場合、これらの論理インタフェースでは、それぞれ管理する情報が異なるため、2つの論理インタフェースを使って、DHとUICCとの間でCLFを介した通信を行うことが困難である恐れがあった。
例えば、DH-UICC間の接続を確立するためには、CLFが、DH-CLF間の論理インタフェースと、UICC-CLF間の論理インタフェースを、適宜関連付ける必要がある。つまり、CLFは、一方との論理インタフェースを確立し、その一方から接続要求を受けて、他方との論理インタフェースを確立し、その2つの論理インタフェースを関連付ける必要がある。
論理インタフェースを確立するためには、相手に対して接続要求や問い合わせをしたり、応答を得るまで待機したりしなければならず、このような手順では、接続のための処理時間が増大してしまう恐れがあった。
また、例えば、UICCがNFCデバイスから着脱可能な場合、CLFは、DHから接続を要求されたときは、UICCが存在しない場合であっても、問い合わせをし、得られるはずのない応答を待たなければならなかった。このような不要な処理により接続処理時間が不要に増大する恐れもあった。
[1−2 CLFによる制御処理]
そこで、複数の処理部と、前記複数の処理部間の接続を制御する接続制御部とを備える情報処理装置において、前記接続制御部が、1の前記処理部との間に確立した第1の論理チャネルに対応する、他の処理部との間に確立した第2の論理チャネルが存在しない場合、前記第1の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、前記第2の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部とを備えるようにする。
情報処理装置は、上述したような構成を有し、各処理部間で通信を行うものであれば、どのような処理を行う装置であってもよい。また、各処理部がどのような処理を行っても良い。論理チャネルは、任意の通信規格のものであってもよい。
接続制御部は、各処理部との間に確立した論理チャネルを、テーブル情報を用いて適宜関連付ける。これにより、処理部間での通信が可能になる。しかしながら、処理部間での通信開始時にこのような処理を行うと上述したように処理時間が増大してしまう恐れがある。そこで、接続制御部は、処理部間の通信要求を受ける前に、1の処理部との間に確立した論理チャネルについて、そのテーブル情報を作成する。その際、対応関係を結ぶ相手が居ない場合であっても、その相手を特定せずに(「空」のまま)テーブル情報を作成する。対応する相手が存在する場合は、その相手のテーブル情報を更新する。
このようにすることにより、接続制御部は、不要な問い合わせ等の処理を省略することができ、接続処理の処理時間の増大を抑制することができる。したがって、情報処理装置は、異なる通信規格のインタフェースを介した通信をより容易に確立することができる。
例えば、CLFへ接続するための、2つのインタフェース(HCIおよびE-HCI)を使って、DHとUICCがCLF経由で通信できるようになる。具体的には、携帯電話内の端末ホスト(DH)にあるアプリケーションが、UICCにあるアプリケーションのデータにアクセスすることができる。たとえば、電子マネーアプリケーションがUICCにある電子マネーの残高を見たり、決済を行ったりすることができるようになる。
なお、前記接続制御部が、前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、前記テーブル作成部が、前記論理チャネル確立部により前記第1の論理チャネルが確立した場合、前記第2の論理チャネルが存在しないときは、前記第1の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成し、前記テーブル更新部が、前記論理チャネル確立部により前記第1の論理チャネルが確立した場合、前記第2の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新するようにしてもよい。
このようにすることにより、接続制御部は、論理チャネルを確立するとともに、その論理チャネルについてのテーブル情報を作成したり、その論理チャネルの情報を他の論理チャネルのテーブル情報に反映させたりすることができる。これにより、論理チャネルが確立した直後から、その処理部と他の処理部との通信をより容易に確立することができる。
前記テーブル作成部および前記テーブル更新部が、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第1の論理チャネルに対応する前記第2の論理チャネルが存在するか否かを判定するようにしてもよい。
論理チャネルがどのように形成されるかは、規格によって決定される。したがって、処理部間の通信を確立するには、その通信の目的や仕様等に応じて、適切な論理チャネルを選択し、関連付ける必要がある。そこで、このような論理チャネルとその特徴の対応表を用いることにより、論理チャネル間の関連付けをより容易に行うことができる。
前記複数の処理部が、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第1の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第2の処理部とを含むようにしてもよい。また、前記対応表が、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含むようにしてもよい。さらに、前記テーブル作成部が、前記論理チャネル確立部により前記第1の処理部との間に第1の論理チャネルが確立した場合、前記対応表に基づいて、前記第2の処理部との間に確立した、前記第1の論理チャネルの機能に対応するプロトコルの第2の論理チャネルが存在しないときは、前記第1の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成するようにしてもよい。また、前記テーブル更新部が、前記論理チャネル確立部により前記第1の処理部との間に第1の論理チャネルが確立した場合、前記対応表に基づいて、前記第2の処理部との間に確立した、前記第1の論理チャネルの機能に対応するプロトコルの第2の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新するようにしてもよい。
このように、接続制御部は、通信に用いられるプロトコルやアプリケーション等の機能に応じて論理チャネルを関連付けることができる。その場合であっても、接続制御部は、テーブル情報を作成することにより、処理部間の通信をより容易に確立することができる。
前記論理チャネル確立部が、各処理部との間に、互いに異なる通信規格の論理チャネルを確立するようにしてもよい。
上述したように論理チャネルの通信規格は任意であり、論理チャネル確立部は、互いに異なる通信規格の論理チャネルを確立することもできる。その場合であっても、接続制御部は、テーブル情報を作成することにより、処理部間の通信をより容易に確立することができる。
前記論理チャネル確立部が、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立するようにしてもよい。
このようにすることにより、処理部側からの要求に基づいて論理チャネルを確立することができる。これにより、接続制御部は、他の処理部の状況を監視する必要がなく、また、例えば、処理部の一部の機能についてのみ論理チャネルを確立することができる等、柔軟な対応が可能になる。
前記論理チャネル確立部が、確立した前記論理チャネルに識別情報を割り当てるようにしてもよい。
論理チャネルの管理は、識別番号等、所定の識別情報を用いて行うことにより、より容易になる。ただし、管理対象となる論理チャネルは、処理部の接続状況等に応じて適宜変化する可能性があるので、識別情報は適宜割り当てるようにするのが望ましい。このようにすることにより、取り扱う識別情報の数を不要に増大させることを抑制することができ、識別情報の情報量の増大を抑制することができる。
前記接続制御部が、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備えるようにしてもよい。
1度確立した論理チャネルを終了させると、その論理チャネルに関するテーブル情報は削除される。そのため、その論理チャネルを使用する通信が要求された場合、再度その論理チャネルを確立する必要がある。その際、何の情報も無ければ、接続制御部は、そのような論理チャネルが存在するのか否か(確立することができるのか否か)の確認から行わなければならない。そこで、1度確立した論理チャネルの情報を別途保持しておくことにより、接続制御部は、その論理チャネルを再確立する際に、その情報を用いて論理チャネルの状態を元に戻すことができる。これにより、接続制御部は、論理チャネルの作成やオープン等の処理を省略することができ、論理チャネルの状態をより容易に元に戻すことができる。
前記テーブル情報が、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報であるようにしてもよい。
識別情報を利用することにより、テーブル情報の情報量の増大を抑制することができる。これにより、テーブル情報の記憶に必要な記憶容量を低減することができ、コストや負荷を低減させることができる。
前記テーブル更新部が、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除するようにしてもよい。
論理チャネルの確立だけでなく、論理チャネルの切断もテーブル情報に反映させることにより、テーブル情報から現在の論理チャネルの確立状況を把握することができ、より容易に通信を確立することができる。つまり、テーブル情報により対応付けられる論理チャネルの現在の状態の確認等の処理が不要になる。
前記テーブル記憶部が、前記テーブル情報を記憶する記憶領域を予め確保するようにしてもよい。
テーブル情報は、論理チャネルの確立状況に応じて変化するが、予めその記憶領域を確保しておくことにより、容量不足等の不具合の発生を抑制することができる。
前記複数の処理部が、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含むようにしてもよい。
NFCデバイスにおけるDHやUICCと論理チャネルを確立するCLFに対して本技術を適用することができる。
前記接続制御部が、他の装置と無線通信を行う無線通信部をさらに備えるようにしてもよい。
CLFは、非接触通信(近距離無線通信)により他のデバイスとの通信を行うこともできる。
なお、本技術は、情報処理装置としてだけでなく、情報処理方法やプログラムとして実現するようにしてもよい。
[1−3 概要]
以下のケースにおける、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の場合、どれかを選択して通信チャネルを作る。
[1−4 NFCデバイス]
図1は、NFCデバイスの主な構成例を示す図である。NFC(Near Field Communication)デバイス100は、例えば、携帯電話端末等の、任意の通信装置である。図1に示されるように、NFCデバイス100は、DH111、CLF112、およびUICC113を有する。
DH(Device Host)111は、NFCデバイスを制御するエンティティ(情報処理装置)である。情報処理装置として動作するEmbedded SEでもよい。
CLF(Contactless Front-end)112は、外部デバイスとRF(例えば、非接触通信・近距離無線通信等)を介して通信できる機能を持つエンティティ(通信処理装置)である。CLF112は、そのRF通信用のアンテナ131を有する。
UICC(Universal IC Card)113は、NFCデバイス100に対して着脱可能なデバイス(例えば、携帯電話へ挿入するカード型デバイス)である。
DH111およびCLF112は、独自のロジカルインタフェース仕様であるHCI(Host Controller Interface)121により接続される。また、UICC113およびCLF112は、ETSI SCPにおいて定義されているE-HCI122により接続される。
[1−5 HCI]
HCI121は、CLF112とDH111との間のロジカルインタフェース仕様である。HCI121では、DH111から見える、NFC処理エンティティをNFCEE(NFC Execution Environment)と称する。NFCEE内部には、複数のプロトコルを処理できるエンティティを持つ。DH111がCLF112を介して接続されるNFCEEと接続する場合、コネクションを利用してDH111とNFCEEのプロトコル処理エンティティを接続する。それぞれのコネクションにはConnection IDという識別子が割り当てられ、CLF112が管理する。
DH111は、CLF112に対してNFCEEを検出するためのコマンドを送信することでCLF112が管理するNFCEEの識別子(NFCEE ID)およびNFCEEがサポートするプロトコル(NFCEE Protocol)を取得することができる。
UICC113は、NFCEEの1つの形態である。UICC113がCLF112に接続されると、CLF112は、DH111に対して、NFCEE IDとNFCEE Protocolを通知する。DH111がUICC113と接続する場合、上記の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で定義されるメッセージ構造である。
[1−6 E-HCI]
E-HCI122は、ETSI SCPで定義するCLF112とUICC113との間のロジカルインタフェース規格である。ここでは、E-HCIと称する。E-HCI122では、DH111やUICC113を含むNFC処理エンティティをホストと称する。ホストは、独立した機能を表すゲートを1つ以上持ち、CLF112内のゲートと接続してパイプを構成する。
CLF112とホストは、パイプを管理するゲートAdministration gateを必須で実装する。ホストは、デバイス内で一意のホストID(Host ID)を持つ。DH111とUICC113には固定値が割り当てられている。そのためUICC113がDH111と接続したい場合、ホストID(Host ID)を指定することになる。
[1−7 メッセージ構成]
次に、HCIのメッセージの仕様について説明する。
図2は、HCIのデータパケットの主な構成例を示す図である。このパケットは、Connection IDにより指定される論理チャネル上で交換されるメッセージの転送に使用される。
図2において、PBF(Packet Boundary Flag)は、次のパケットが連続するかどうかを示す情報である。また、Connection IDは、論理チャネルを識別する識別情報である。RFU(Reserved for future use)は、拡張用領域である。Payload Lengthは、Payloadの長さを示す情報である。Payloadは、上位層のメッセージを格納する。メッセージの形式は、使用するNFCEE Protocolによって異なる。
図3は、HCIコマンド/レスポンスパケットの主な構成例を示す図である。このパケットは、HCIのコマンド又はレスポンスを転送するために使用される。
図3において、TYPEは、パケットの内容を示す情報である。TYPEは、「要求」を表す値「001b」、「応答」を表す値「010b」、「通知」を表す「011b」のいずれかにセットされる。PBF(Packet Boundary Flag)は、次のパケットが連続するかどうかを示す情報である。GID(Group ID)は、このパケットがどの機能分類かを示す情報である。OID(Opcode ID)は、このパケットの機能を示す情報である。RFU(Reserved for future use)は、拡張用領域であり、Payload Lengthは、Payloadの長さを示す。Payloadは、コマンド又はレスポンスのパラメータを格納する。
以下に、このパケットで伝送される情報の例を示す。
図4は、HCIコネクション作成コマンドの例を示す図である。図4において、NFCEE IDは、事前に、CLF112からDH111へ通知されるものとする。NFCEE Protocolには、アプリケーションが交換するメッセージ形式に応じて、APDU(‘00’)や、T3T Command(‘02’)がセットされる。
図5は、HCIコネクション作成レスポンスの例を示す図である。図6は、HCIコネクション終了コマンドの例を示す図である。図7は、HCIコネクション終了レスポンスの例を示す図である。図8は、NFCEE接続常態通知の例を示す図である。
次に、E-HCIのメッセージの仕様について説明する。
図9は、E-HCIのHCPパケットの主な構成例を示すブロック図である。このパケットは、パイプID(Pipe ID)で指定された論理チャネル上で交換されるメッセージの転送に使用される。交換されるメッセージには、コマンド及びレスポンスも含まれる。
図9において、CB(Chaining Bit)は、次のパケットが連続するかどうかを示す情報である。pID(Pipe ID)は、このパケットが転送されるパイプを識別する識別情報である。TYPEは、このパケットの種類を示す(コマンド、レスポンス又はイベント)情報である。INSTRUCTIONは、このパケットの機能を示す情報である。Dataは、上位層のメッセージを格納する。メッセージの形式はCLFのゲートIDによって異なる。
以下に、このパケットで伝送される情報の例を示す。
図10は、E-HCIパイプ作成コマンドの例を示す図である。接続先のゲートIDを指定するため、UICC113は事前にCLF112上のIdentity management gateからゲートIDのリストを取得しておく。ETSIにおいてDH111へ接続するためのゲートIDは未定義であるため、独自のゲートID定義が必要である。たとえば、次のように定義する。
T4AT wired gate ID = ‘F0’
T4BT wired gate ID = ‘F1’
T3T wired gate ID = ‘F2’
図11は、E-HCIパイプ作成レスポンスの例を示す図である。図12は、E-HCIパイプオープンコマンドの例を示す図である。図13は、E-HCIパイプオープンレスポンスの例を示す図である。
[1−8 ロジカルチャネル確立処理]
DH111とUICC113との間で通信するための論理的な通信路を、論理チャネル(またはロジカルチャネル)と称する。DH111とCLF112との間では独自のコマンドを利用し、UICC113とCLF112との間ではE-HCIで定義されたコマンドを利用するものとする。
図14は、NFCデバイス内部のシステム構成例を示す図である。
DH111は、任意のアプリケーションを実装する事ができるが、図14においては、一例として、T4T(APDU)コマンドベースのアプリケーションであるT4Tアプリケーション(T4T application)211と、T3TコマンドベースのアプリケーションであるT3Tアプリケーション(T3T application)212とが実装されるものとする。
また、DH111とCLF112との間には、任意のコネクションが実装可能であるが、図14においては、一例として、DH-UICC間の通信用のコネクションであるT4Tコネクション(T4T conn)221およびT3Tコネクション(T3T conn)222、並びに、RF通信用のコネクションであるRFコネクション(RF conn)223が実装されるものとする。このT4Tコネクション(T4T conn)221のコネクションIDは、T4Tである(Conn ID = T4T)。また、T3Tコネクション(T3T conn)222のコネクションIDは、T3Tである(Conn ID = T3T)。また、RFコネクション(RF conn)223のコネクションIDは、RFである(Conn ID = RF)。
さらに、CLF112は、任意のゲートを実装する事ができるが、図14においては、一例として、タイプA RFカードゲート(Type A RF card gate)241およびタイプB RFカードゲート(Type B RF card gate)243を実装するものとする。CLF112は、さらに、E-HCIに定義済みのタイプF RFカードゲート(Type F RF card gate)245を実装するものとする。また、CLF112は、DH111とUICC113との間の通信用として、T4Tワイヤードゲート(Type 4 Tag(T4T)wired gate(独自))242と、T3Tワイヤードゲート(Type 3 Tag (T3T) wired gate (独自))244とを実装するものとする。
また、UICC113は、任意のゲートを実装する事ができるが、図14においては、一例として、例えばタイプA RFカードゲート(Type A RF card gate)241を制御するタイプAカードアプリケーションゲート(Type A card application gate)251を実装するものとする。また、UICC113は、例えばタイプB RFカードゲート(Type B RF card gate)243を制御するタイプBカードアプリケーションゲート(Type B card application gate)252を実装するものとする。さらに、UICC113は、例えばタイプF RFカードゲート(Type F RF card gate)245を制御するタイプFカードアプリケーションゲート(Type F card application gate)253を実装するものとする。
なお、図14においては、CLF112とUICC113との間には、タイプ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 gate241とType A card application gate251との間のパイプである。Type B RF pipeは、Type B RF card gate243とType B card application gate252との間のパイプである。Type F RF pipeは、Type F RF card gate245とType F card application gate253との間のパイプである。
T4TA pipeは、T4T wired gate242とType A card application gate251との間のパイプである。T4TB pipeは、T4T wired gate242とType B card application gate252との間のパイプである。T3T pipeは、T3T wired gate244とType F card application gate253との間のパイプである。
また、UICC113には、任意のアプリケーションを実装することができるが、図14においては、一例として、APDUコマンドベースのアプリケーションであるAPDUアプリケーション(APDU application)261と、T3TコマンドベースのアプリケーションであるタイプFアプリケーション(Type F application)262とが実装されるものとする。
DH111上のT4T application211とUICC113上のAPDU application261は、どちらもAPDUを処理できるアプリケーションであるため、これらを論理チャネルで接続することができる。
また、DH111上のT3T application212とUICC113上のType F application262は、どちらもT3Tコマンドを処理できるアプリケーションであるため、これらを論理チャネルで接続することができる。
[1−9 HCIの管理情報とE-HCIの管理情報との対応管理]
HCIとE-HCIでは、図15に示される表のように、それぞれ別の情報が管理されている。2つのインタフェースを実装するCLF112は、次のように、これらの情報の対応付けを行う。コネクションIDとパイプIDの例については、図16に示す。また、NFCEEプロトコルとゲートIDの例については、図17に示す。
[1−10 DHからUICCへの接続処理]
DH111は、UICC113との通信が必要な場合に、UICC113への接続処理を行うものとする。DH111からUICC113へ論理チャネルを確立する場合、DH111は、CLF112に対して、コネクション作成コマンド(パラメータ:NFCEE ID,NFCEE Protocol)を送信する。
CLF112は、指定されたNFCEE Protocolに対応するE-HCIパイプができている場合、対応するコネクションを作成し、コネクション作成コマンド応答(Status=OK)で応答する。パイプがない場合、エラーで応答する。E-HCIでは、CLF112からUICC113に対して、パイプを作成する機能がないため、事前に、UICC113挿入時などの初期化中に、UICC113(ホスト)がパイプを作成しておく必要がある。
[1−11 T4T/APDU application間論理チャネルの確立]
図18に示される例のように、DH111上のT4T application211がUICC113上のAPDU application261と論理チャネルを確立する場合、DH111が送信するコネクション作成コマンドにおいて、NFCEE ID=UICC,NFCEE Protocol=T4Tを指定する。
この場合、NFCEE ProtocolにT4Tが指定されたので、CLF112はDH111との間にT4Tコネクション221(Conn ID = T4T)を作成し、NFCEE Protocol = T4Tに基づくT4T wired gate242に接続されるパイプがあれば、T4TA pipe ID、T4TB pipe IDともリンクさせる。リンクができた場合、正常終了ステータスのコネクション作成コマンド応答をDH111へ送信する。パイプがなくリンクができない場合は、エラーステータスを含むコネクション作成コマンド応答をDH111へ送信する。
なお、プロトコル・ゲートID対応表は固定的に保持している。また、コネクション作成要求時、プロトコルに対応するゲートIDを探す。ゲートIDに対応するパイプIDとコネクションIDを関連付ける。プロトコルに対応するゲートIDが複数見つかった場合、1つのコネクションIDと関連付ける。
図19のフローチャートを参照して、DHからUICCへの接続処理の流れの例を説明する。
UICC113がNFCデバイス100の所定位置に装着されると、ステップS101において、CLF112は、UICC113に対して、Identityゲートへのパイプオープン要求を行う。ステップS102において、CLF112は、UICC113に対して、IdentityゲートへのゲートIDリスト取得要求を行う。CLF112は、この要求に対してUICC113から供給されたゲートIDリストを取得し、保持する。
ステップS103において、UICC113は、CLF112に対して、DH接続ゲートへのパイプ作成要求を行う。その際、UICC113は、Dest host ID,Dest gate ID,source host ID、およびsource gate IDを供給する。
ステップS104において、CLF112は、その要求に応じて、DH接続ゲートへのパイプを作成する。また、CLF112は、供給されたDest gate IDを、DH接続ゲートのゲートIDに対応するパイプIDに割り当て、表401を作成する。
ステップS105において、CLF112は、予め記憶しているプロトコル・ゲートID対応表404を参照し、要求されたDest gate IDに対応するプロトコルが存在するか否かを判定する。プロトコルが存在すると判定された場合、処理は、ステップS106に進む。
ステップS106において、CLF112は、既に作成済みの(記憶している)、そのプロトコルのコネクションIDに関するコネクションIDとパイプIDの対応表(テーブル情報)402を更新する。より具体的には、CLF112は、その対応表402の、要求されたDest gate IDに対応するプロトコルに対応するパイプIDの欄に、要求されたDest gate ID(ステップS104において設定したパイプID)を追加する。対応表402の更新が終了すると、処理は、ステップS108に進む。
また、ステップS105において、要求されたDest gate IDに対応するプロトコルが存在しないと判定された場合、処理は、ステップS107に進む。
ステップS107において、CLF112は、要求されたDest gate IDに関する、コネクションIDとパイプIDの対応表(テーブル情報)402を作成し、記憶する。その際、要求されたDest gate IDに対応付けるコネクションIDは未定であるので、CLF112は、「空」(empty)のコネクションIDをパイプID(Dest gate ID)に関連付ける。この「空」(empty)を示す値は任意である。ステップS107の処理が終了すると、処理はステップS108に進む。
このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF112は、パイプが確立次第、対応表402を作成する。これにより、CLF112は、DH111から接続要求があった場合に、この対応表402を用いて容易に通信を確立することができる。
ステップS108において、CLFは、他のパイプを作成するか否かを判定する。他のパイプを作成すると判定された場合、処理は、ステップS103に戻る。つまり、作成するパイプの数だけステップS103乃至ステップS108の処理が繰り返される。
ステップS108において、他のパイプを作成しないと判定された場合、処理は、ステップS109に進む。
ステップS109においてDH111からUICC接続用コネクション作成要求を取得すると、CLF112は、ステップS110において、その要求において指定されたプロトコルのUICC接続用コネクションを作成する。また、CLF112は、作成したコネクションに対してコネクションIDを割り当て、そのプロトコルと、そのコネクションIDとを関連付ける対応表403を作成し、記憶する。
ステップS111において、CLF112は、予め記憶しているプロトコル・ゲートID対応表404を参照し、要求されたプロトコルに対応するゲートが存在するか否かを判定する。ゲートが存在すると判定された場合、処理は、ステップS112に進む。
ステップS112において、CLF112は、既に作成済みの(記憶している)、そのゲートに関するコネクションIDとパイプIDの対応表(テーブル情報)402を更新する。より具体的には、CLF112は、その対応表402の、要求されたプロトコルに対応するゲートに対応するコネクションIDの欄に、ステップS110において割り当てられたコネクションIDを追加する。図19の例の場合、対応表402が更新され、対応表405となる。CLF112は、この対応表405を記憶する。対応表402の更新が終了すると、この接続処理が終了する。
また、ステップS111において、要求されたプロトコルに対応するゲートが存在しないと判定された場合、処理は、ステップS113に進む。
ステップS113において、CLF112は、要求されたプロトコルに関する、コネクションIDとパイプIDの対応表(テーブル情報)402を作成し、記憶する。その際、要求されたプロトコルに対応付けるパイプIDは未定であるので、CLF112は、「空」(empty)のパイプIDをそのコネクションIDに関連付ける。この「空」(empty)を示す値は任意である。ステップS113の処理が終了すると、この接続処理が終了する。
このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF112は、コネクションが確立次第、対応表402を作成する。これにより、CLF112は、UICC113から接続要求があった場合に、この対応表402を用いて容易に通信を確立することができる。
なお、上述した各種対応表等の情報を記憶する記憶領域は、CLF112からアクセス可能な場所であれば、任意の場所に設けることができる。例えば、CLF112内部にその記憶領域を設けてもよいし、CLF112の外部に設けるようにしてもよい。
[1−12 T3T/Type F application間論理チャネルの確立]
図20に示されるように、DH111上のT3T application212がUICC113上のType F application262と論理チャネルを確立する場合、DH111が送信するコネクション作成コマンドにおいて、NFCEE ID=UICC,NFCEE Protocol=T3Tを指定する。
この場合、NFCEE ProtocolにT3Tが指定されたので、CLF112はDH111との間にT3Tコネクション222(Conn ID = T3T)を作成し、NFCEE Protocol = T3Tに基づくT3T wired gate244に接続されるパイプがあれば、T3T pipe IDともリンクさせる。リンクができた場合、正常終了ステータスのコネクション作成コマンド応答をDH111へ送信する。パイプがなくリンクができない場合、CLF112は、エラーステータスを含むコネクション作成コマンド応答をDH111へ送信する。
この場合のDHからUICCへの接続処理の流れは、図21に示されるように、図19を参照して説明した場合と同様である。
ステップS104において、CLF112は、T3T wired gate244にパイプID「12」を割り当て、表421を作成する。
ステップS105において、CLF112は、予め記憶しているプロトコル・ゲートID対応表424を参照し、T3T wired gate244に対応するプロトコルが存在するか否かを判定する。
ステップS106において、CLF112は、既に作成済みの(記憶している)、プロトコルT3TのコネクションIDに関するコネクションIDとパイプIDの対応表(テーブル情報)422を更新する。
ステップS107において、CLF112は、T3T wired gate244に関する、コネクションIDとパイプIDの対応表(テーブル情報)422を作成し、記憶する。より具体的には、CLF112は、例えば、対応表421で割り当てられたパイプID「12」に対して、「空」(empty)のコネクションIDをパイプID(Dest gate ID)に関連付ける対応表422を作成する。
このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF112は、パイプが確立次第、対応表422を作成する。これにより、CLF112は、DH111から接続要求があった場合に、この対応表422を用いて容易に通信を確立することができる。
CLF112は、ステップS110において、T3TのUICC接続用コネクションを作成し、その作成したコネクションに対してコネクションID「05」を割り当て、そのT3TとコネクションIDとを関連付ける対応表423を作成し、記憶する。
ステップS111において、CLF112は、予め記憶しているプロトコル・ゲートID対応表424を参照し、プロトコルT3Tに対応するゲートが存在するか否かを判定する。
ステップS112において、CLF112は、既に作成済みの(記憶している)対応表422の、要求されたプロトコルT3Tに対応するパイプID「12」に対応するコネクションIDの欄に、ステップS110において割り当てられたコネクションID「05」を追加する。
ステップS113において、CLF112は、要求されたプロトコルT3Tに関する、コネクションID「05」と、「空」(empty)のパイプIDの対応表(テーブル情報)422を作成し、記憶する。
このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF112は、コネクションが確立次第、対応表422を作成する。これにより、CLF112は、UICC113から接続要求があった場合に、この対応表422を用いて容易に通信を確立することができる。
[1−13 DHからUICCへのパケット送信処理]
DH111上のアプリケーションは、以上のように作成したコネクションを用いて、UICC113上の対応アプリケーションへパケットを送信する。T4T application211がUICC113へパケットを送信する場合、T4T Connection IDを指定して、パケットを送信する。
CLF112は、T4T Connection IDのコネクションで受け取ったパケットを、対応するE-HCIパイプである、T4TA pipe IDとT4TB pipe IDのE-HCIパイプ(存在するパイプ)へ送信する。このとき、CLF112は、HCIのヘッダを、E-HCIのヘッダに置き換える処理を行う。
[1−14 UICCからDHへの接続処理]
次に、UICC113からDH111への接続処理について説明する。この処理は、DH111がUICC113へのコネクションを作成するよりも前に、UICC113挿入時に行われるものとする。
UICC113からDH111へ論理チャネルを確立する場合、UICC113は、CLF112に対して、ADM_CREATE_PIPEを送信する。CLF112は、指定されたゲートが実装されている場合に、ANY_OKおよび作成したパイプのpipe IDで応答する。
パイプ作成後、そのパイプを開放するために、UICC113はANY_OPEN_PIPEを送信し、CLFはANY_OKで応答する。指定されたゲートが実装されていることで、DH111へ論理チャネルを確立できることとする。Conn IDが15個と限られているため、動的に作成することで、そのリソースを効率的に使うことができる。
HCIでは、E-HCIと同様に、CLF112からDH111に対して、コネクションを作成する機能がないため、事前に、たとえば、DH111起動時の初期化中に、DH111がコネクションを作成しておく必要がある。
UICC113から接続する場合は、UICC113がCLF112にあるゲートのリストを取得するため、CLF112にあるゲートすべてについて、論理チャネルを確立することになる。
[1−15 APDU/T4T application間論理チャネルの確立]
図18において、上述した例とは逆に、UICC113上のAPDU application261がDH111上のT4T application211と論理チャネルを確立する場合、UICC113が送信するADM_CREATE_PIPEにおいて、destination HID=DH、destination GID=T4T wired gate、source GID=Type A、および/または、Type B card application gateを指定する。ここで指定するGIDは、仮想的にDH上にT4T wired gate242があるように指定する。
この場合、CLF112はT4T Connection IDのコネクションを作成し、destination GIDに基づいてT4T wired pipe ID(T4TA wired pipe又はT4TB wired pipe)とリンクさせる。
図22のフローチャートを参照して、UICCからDHへの接続処理の流れの例を説明する。
この場合の接続処理は、図19のフローチャートを参照して説明したDHからUICCへの接続処理の各ステップの処理と同様の処理が、処理順を入れ替えて行われる。
より具体的には、ステップS201乃至ステップS205において、図19のステップS109乃至ステップS113の各処理と同様の処理が行われ、その後、ステップS206乃至ステップS212において、図19のステップS101乃至ステップS106の各処理と同様の処理が行われる。
なお、図22の例の場合、ステップS210において、要求されたDest gate IDに対応するプロトコルが存在しないと判定された場合、ステップS107と同様の処理は行われずに、処理はステップS212に進む。
以上の処理の流れのより具体的な例について説明する。ステップS201においてDH111からUICC接続用コネクション作成要求を取得すると、CLF112は、ステップS202において、その要求において指定されたプロトコル「APDU」のUICC接続用コネクションを作成する。また、CLF112は、作成したコネクションに対してコネクションID「04」を割り当て、そのプロトコルと、そのコネクションIDとを関連付ける対応表441を作成し、記憶する。
また、要求されたプロトコルに対応するゲートが存在する場合、CLF112は、ステップS204において、要求されたプロトコルに対応するコネクションID「04」と、そのゲートのパイプIDの対応表(テーブル情報)442を作成し、記憶する。
さらに、要求されたプロトコルに対応するゲートが存在しない場合、CLF112は、ステップS205において、要求されたプロトコルに対応するコネクションID「04」と、「空」(empty)パイプIDの対応表(テーブル情報)442を作成し、記憶する。
このように、コネクションIDとパイプIDとの対応関係が未決定の状態であっても、CLF112は、コネクションが確立次第、対応表442を作成する。これにより、CLF112は、UICC113から接続要求があった場合に、この対応表442を用いて容易に通信を確立することができる。
また、ステップS207において、CLF112は、UICC113に対して、IdentityゲートへのゲートIDリスト取得要求を行う。CLF112は、この要求に対してUICC113から供給されたゲートIDリストを取得し、保持する。
ステップS209において、CLF112は、その要求に応じて、DH接続ゲートへのパイプを作成する。また、CLF112は、供給されたDest gate IDをパイプID「10、11」としてゲートIDに関連付け、表443を作成する。
さらに、ステップS210において、CLF112は、予め記憶しているプロトコル・ゲートID対応表444を参照し、要求されたDest gate IDに対応するプロトコルが存在するか否かを判定する。プロトコルが存在すると判定された場合、処理は、ステップS211に進む。
ステップS211において、CLF112は、既に作成済みの(記憶している)、そのプロトコルのコネクションIDに関するコネクションIDとパイプIDの対応表(テーブル情報)442を更新する。より具体的には、CLF112は、その対応表442の、コネクションID「04」に対応するパイプIDの欄に、要求されたDest gate ID「10、11」を追加する。対応表442の更新が終了すると、処理は、ステップS212に進む。
[1−16 Type F/T3T application間論理チャネルの確立]
図20において、上述した例とは逆に、UICC113上のType F application262がDH111上のT3T application212と論理チャネルを確立する場合は、UICC113が送信するADM_CREATE_PIPEにおいて、destination HID=DH、destination GID=T3T wired gate、source GID=Type F card application gateを指定する。ここで指定するGIDは、仮想的にDH111上にT3T wired gate244があるように指定する。
この場合、CLF112はT3T Connection IDのコネクションを作成し、destination GIDに基づいてT3T wired pipe IDとリンクさせる。
この場合の接続処理は、図22のフローチャートを参照して説明した場合と同様に行われるので、その説明は省略する。
[1−17 UICCからDHへのパケット送信処理]
UICC113上のアプリケーションは、成就したE-HCIパイプを用いて、DH111上の対応アプリケーションへパケットを送信する。APDU application261がDH111へパケットを送信する場合、作成したT4TA wired pipeまたはT4TB wired pipeを指定して、パケットを送信する。
2つの経路はどちらを使ってもよい。たとえば、別のアプリケーションがT4TB wired pipeを使っているときに、並行してT4TA wired pipeの経路でDHへパケットを送信することができる。このとき、CLF112は、E-HCIのヘッダを、HCIのヘッダに置き換える処理を行う。
[1−18 UICC取り出し処理]
UICC113が取り外された場合、CLF112からDH111に対して通知を行う。これにより、コネクションIDとパイプIDの対応を適時に更新することができ、実際には接続されていないエンティティへのデータ送信を行うなどの不整合な処理を防ぐことができる。CLF112からDH111へのUICC113取り出し通知は、図8で示される形式で通知される。
図23のフローチャートを参照して、UICC取り出し処理の流れの例を説明する。ステップS301において、CLF112は、DH111に対して、UICC113が取り外されたことを通知する。
ステップS302において、CLF112は、コネクションIDとパイプIDの対応表(テーブル情報)から、取り外されたUICC113に対応するパイプIDの情報を削除する。例えば、対応表461が保持されているとする。UICC113が取り外されることにより、パイプID「10」と「11」が削除されるとすると、CLF112は、対応表462に示されるように、それらのパイプIDの代わりに「空」(Empty)を示す値をセットする。ステップS302の処理が終了すると、UICC取り出し処理が終了する。
このようにして、対応するパイプが存在しなくなったコネクションIDの対応表を維持する。これにより、CLF112は、再度UICC113がセットされた場合に、この対応表462を用いて容易に通信を確立することができる。
[1−19 DHからのコネクション終了要求]
DH111からコネクション終了コマンドを送信することによって、UICC113と接続している通信チャネルを切断することができる。その場合、CLF112は、コネクションIDとパイプIDの対応を更新する。
図24のフローチャートを参照して、DHによるコネクション終了要求処理の流れの例を説明する。ステップS321において、CLF112は、DH111から供給されるコネクション終了コマンドを取得する。コネクション終了コマンドにおいては、終了するコネクションが、コネクションIDを用いて指定される。
ステップS322において、その要求に基づいて、CLF112は、コネクションIDとパイプIDの対応表(テーブル情報)を更新する。すなわち、指定されたコネクションIDの情報を、対応表から削除する。例えば、対応表481が保持されているとする。コネクションID「04」のコネクションの終了が要求されると、CLF112は、対応表482に示されるように、そのコネクションID「04」の代わりに「空」(Empty)を示す値をセットする。ステップS322の処理が終了すると、DHによるコネクション終了要求処理が終了する。
このようにして、対応するパイプが存在しなくなったパイプIDの対応表を維持する。これにより、CLF112は、再度DH111からUICC113との通信を要求された場合に、この対応表482を用いて容易に通信を確立することができる。
[1−20 パイプの状態の記憶]
ETSIに従い、CLF112はパイプの状態を不揮発に記憶しておくことが必須となっている。UICC113が挿入されたときに、CLF112はUICC113との間でSWPインタフェースの活性化を行い、その間にUICC113から送信される2バイトのSYNC IDを保持しておく。さらに、パイプの作成・オープンを行った場合、CLF112は、そのSYNC IDに関連付けて、作成・オープンしたパイプのID及び状態を保持しておく。
少なくとも1つの保持したSYNC IDが、UICCから送信されたSYNC IDと一致した場合、CLF112は、以前挿入されたUICCだと判断し、保持しておいたパイプの状態を元に戻す。これによって、パイプ作成・オープンの手続きを省略することができる。
[1−21 対応表の実装例]
CLF112は、固定のメモリをパイプIDとコネクションIDの対応表のために確保しておく。例えば、CLF112は、図25に示されるように、16個のパイプIDに対するエントリを確保しておき、すべての値を‘FF’に設定しておく。
UICC113からパイプ作成が要求された場合、CLF112は、指定されたゲートIDに対応するプロトコルを持つコネクションが見つかったとき、対応するエントリに、パイプIDとそれに関連付けるコネクションIDを書き込む。
見つからないとき、CLF112は、パイプIDとコネクションIDの両方が‘FF’になっているエントリに対して、パイプIDとそれに関連付けるコネクションIDを書き込む。
DH111からコネクション作成が要求された場合、CLF112は、指定されたプロトコルに対応するゲートIDを持つパイプが見つかったとき、対応するエントリに、コネクションIDとそれに関連付けるパイプIDを書き込む。
見つからないとき、CLF112は、パイプIDとコネクションIDの両方が‘FF’になっているエントリに対して、コネクションIDとそれに関連付けるパイプIDを書き込む。
パイプ削除が要求された場合、CLF112は、要求されたパイプIDと同じ値を見つけたら、‘FF’に設定する。コネクション削除が要求された場合、CLF112は、要求されたコネクションIDと同じ値を見つけたら、‘FF’に設定する。
<2.第2の実施の形態>
[コンピュータ]
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
図26は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
図26に示されるコンピュータ900において、CPU(Central Processing Unit)901、ROM(Read Only Memory)902、RAM(Random Access Memory)903は、バス904を介して相互に接続されている。
バス904にはまた、入出力インタフェース910も接続されている。入出力インタフェース910には、入力部911、出力部912、記憶部913、通信部914、およびドライブ915が接続されている。
入力部911は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部912は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部913は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部914は、例えば、ネットワークインタフェースよりなる。ドライブ915は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア921を駆動する。
以上のように構成されるコンピュータでは、CPU901が、例えば、記憶部913に記憶されているプログラムを、入出力インタフェース910およびバス904を介して、RAM903にロードして実行することにより、上述した一連の処理が行われる。RAM903にはまた、CPU901が各種の処理を実行する上において必要なデータなども適宜記憶される。
コンピュータ(CPU901)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア921に記録して適用することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
コンピュータでは、プログラムは、リムーバブルメディア921をドライブ915に装着することにより、入出力インタフェース910を介して、記憶部913にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部914で受信し、記憶部913にインストールすることができる。その他、プログラムは、ROM902や記憶部913に、あらかじめインストールしておくことができる。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数の構成要素(装置、モジュール(部品)等)の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、1つの筐体の中に複数のモジュールが収納されている1つの装置は、いずれも、システムである。
また、以上において、1つの装置(または処理部)として説明した構成を分割し、複数の装置(または処理部)として構成するようにしてもよい。逆に、以上において複数の装置(または処理部)として説明した構成をまとめて1つの装置(または処理部)として構成されるようにしてもよい。また、各装置(または各処理部)の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置(または処理部)の構成の一部を他の装置(または他の処理部)の構成に含めるようにしてもよい。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
例えば、本技術は、1つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、上述のフローチャートで説明した各ステップは、1つの装置で実行する他、複数の装置で分担して実行することができる。
さらに、1つのステップに複数の処理が含まれる場合には、その1つのステップに含まれる複数の処理は、1つの装置で実行する他、複数の装置で分担して実行することができる。
なお、本技術は以下のような構成も取ることができる。
(1) 複数の処理部と、
前記複数の処理部間の接続を制御する接続制御部と
を備え、
前記接続制御部は、
1の前記処理部との間に確立した第1の論理チャネルに対応する、他の処理部との間に確立した第2の論理チャネルが存在しない場合、前記第1の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
前記第2の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
を備える情報処理装置。
(2) 前記接続制御部は、
前記処理部との間に前記論理チャネルを確立する論理チャネル確立部をさらに備え、
前記テーブル作成部は、前記論理チャネル確立部により前記第1の論理チャネルが確立した場合、前記第2の論理チャネルが存在しないときは、前記第1の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成し、
前記テーブル更新部は、前記論理チャネル確立部により前記第1の論理チャネルが確立した場合、前記第2の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新する
前記(1)に記載の情報処理装置。
(3) 前記テーブル作成部および前記テーブル更新部は、それぞれ、各論理チャネルの特徴の対応表に基づいて、前記第1の論理チャネルに対応する前記第2の論理チャネルが存在するか否かを判定する
前記(2)に記載の情報処理装置。
(4) 前記複数の処理部は、前記論理チャネル確立部が機能毎に前記論理チャネルを確立する第1の処理部と、前記論理チャネル確立部がプロトコル毎に前記論理チャネルを確立する第2の処理部とを含み、
前記対応表は、前記特徴として前記機能および前記プロトコルの対応関係を示す情報を含み、
前記テーブル作成部は、前記論理チャネル確立部により前記第1の処理部との間に第1の論理チャネルが確立した場合、前記対応表に基づいて、前記第2の処理部との間に確立した、前記第1の論理チャネルの機能に対応するプロトコルの第2の論理チャネルが存在しないときは、前記第1の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成し、
前記テーブル更新部は、前記論理チャネル確立部により前記第1の処理部との間に第1の論理チャネルが確立した場合、前記対応表に基づいて、前記第2の処理部との間に確立した、前記第1の論理チャネルの機能に対応するプロトコルの第2の論理チャネルが存在するときは、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第1の論理チャネルに対応する論理チャネルとするように更新する
前記(3)に記載の情報処理装置。
(5) 前記論理チャネル確立部は、各処理部との間に、互いに異なる通信規格の論理チャネルを確立する
前記(2)乃至(4)のいずれかに記載の情報処理装置。
(6) 前記論理チャネル確立部は、各処理部からの要求に基づいて、要求された処理部との間に前記論理チャネルを確立する
前記(2)乃至(5)のいずれかに記載の情報処理装置。
(7) 前記論理チャネル確立部は、確立した前記論理チャネルに識別情報を割り当てる
前記(2)乃至(6)のいずれかに記載の情報処理装置。
(8) 前記接続制御部は、前記論理チャネル確立部により確立された論理チャネルの現在の状態を示す情報を記憶する状態記憶部をさらに備える
前記(2)乃至(7)のいずれかに記載の情報処理装置。
(9) 前記テーブル情報は、論理チャネルの識別情報を用いて、論理チャネル間の対応関係を示す情報である
前記(1)乃至(8)のいずれかに記載の情報処理装置。
(10) 前記テーブル更新部は、前記論理チャネルが切断された場合、前記テーブル記憶部に記憶されているテーブル情報から、切断された前記論理チャネルの情報を削除する
前記(1)乃至(9)のいずれかに記載の情報処理装置。
(11) 前記テーブル記憶部は、前記テーブル情報を記憶する記憶領域を予め確保する
前記(1)乃至(10)のいずれかに記載の情報処理装置。
(12) 前記複数の処理部は、前記情報処理装置の各部を制御する制御部と、前記情報処理装置に対して着脱可能なデバイスを含む
前記(1)乃至(11)のいずれかに記載の情報処理装置。
(13) 前記接続制御部は、他の装置と無線通信を行う無線通信部をさらに備える
前記(1)乃至(12)のいずれかに記載の情報処理装置。
(14) 情報処理装置の情報処理方法において、
前記情報処理装置が、
1の処理部との間に確立した第1の論理チャネルに対応する、他の処理部との間に確立した第2の論理チャネルが存在しない場合、前記第1の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成し、
作成された前記テーブル情報を記憶し、
前記第2の論理チャネルが存在する場合、記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新する
情報処理方法。
(15) コンピュータを、
1の処理部との間に確立した第1の論理チャネルに対応する、他の処理部との間に確立した第2の論理チャネルが存在しない場合、前記第1の論理チャネルについて、論理チャネル間の対応関係を示すテーブル情報を、前記第1の論理チャネルに対応する論理チャネルを指定せずに作成するテーブル作成部と、
前記テーブル作成部により作成された前記テーブル情報を記憶するテーブル記憶部と、
前記第2の論理チャネルが存在する場合、前記テーブル記憶部に記憶されている前記第2の論理チャネルについての前記テーブル情報を、前記第1の論理チャネルを前記第2の論理チャネルに対応する論理チャネルとするように更新するテーブル更新部と
して機能させるプログラム。