JP5782698B2 - 通信装置、プログラム、および通信方法 - Google Patents

Description

本発明は、通信装置、プログラム、および通信方法に関し、特に、装置内におけるメッセージの伝送をより正確に行うことができるようにした通信装置、プログラム、および通信方法に関する。

従来、近距離無線通信を行うNFC（Near Field Communication）デバイス内部における、CLF（Contactless Front End）とUICC（Universal Integrated Circuit Card）との間のロジカルインタフェースを規定する仕様であるETSI（European Telecommunications Standards Institute）SCP（Smart Card Platform）HCI（Host Controller Interface）規格(TS 102 622 V7.5.0)においては、メッセージをパイプ上で送信する際に、１つのメッセージを分割し、それを分割メッセージ(fragmented message)として送信し、受信側でその分割メッセージを１つのメッセージに組み立てるという仕様がある。

また、未達（NAK）が発生した場合、パケットを複数に分割して送信する方法も考えられている（例えば、特許文献１参照）。

特開２００８−２１９３２３号公報

しかしながら、例えば、分割メッセージ送信中において、イベントが発生し、そのイベントを通知するイベントメッセージの伝送が優先されると、受信側は、そのイベントメッセージを分割メッセージの一部と認識してしまい、そのイベントメッセージを認識することができない恐れがあった。

イベントメッセージが正しく認識されないと、例えば、非接触通信を行うRF（Radio Frequency）部の状態とNFCデバイスの内部状態に不整合が生じ、NFCデバイスの処理が正しく行われなくなってしまう恐れがあった。

本発明は、このような状況に鑑みて提案されたものであり、装置内におけるメッセージの伝送をより正確に行うことができるようにすることを目的とする。

本発明の一側面は、他の装置と近距離無線通信を行う通信手段と、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段とを備え、前記通信手段は、前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記処理手段に送信し、前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する通信装置である。

前記所定のサイズは、前記フォーマットにおけるデータサイズの上限値であることができる。

前記フォーマットのパケットは、パケットヘッダと前記分割メッセージとにより構成されるようにすることができる。

前記通信手段は、前記メッセージの最後の部分でない前記分割メッセージに、最後以外の分割メッセージであることを示す情報を含む前記パケットヘッダを付加し、前記メッセージの最後の部分の前記分割メッセージに、最後の分割メッセージであることを示す情報を含む前記パケットヘッダを付加することができる。

前記通信手段は、前記終端メッセージに、最後の分割メッセージであることを示す情報を含む前記パケットヘッダを付加することができる。

前記終端メッセージは、前記メッセージを終端する理由を示す情報を含むようにすることができる。

前記他のメッセージは、発生したイベントを通知するイベントメッセージであるようにすることができる。

前記処理手段は、前記通信手段から送信される前記パケットを受信し、受信した前記パケットが前記分割メッセージを含む場合、受信した前記分割メッセージを受信済みの前記分割メッセージに合成し、受信した前記パケットが前記終端メッセージを含む場合、受信した前記終端メッセージを受信済みの前記分割メッセージに合成し、合成結果を１つの前記メッセージとして把握し、前記終端メッセージを受信後、前記他のメッセージを含む前記パケットを受信した場合、前記他のメッセージを前記メッセージと異なるメッセージとして把握することができる。

前記処理手段は、前記他の装置に送信するメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記通信手段に送信し、前記メッセージの送信中に、前記通信手段から他のメッセージを受信した場合、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記通信手段に送信することができる。

前記終端メッセージのパケットは、最後の分割メッセージであることを示す情報を含むパケットヘッダと空メッセージとにより構成されるようにすることができる。

本発明の一側面は、また、コンピュータを、他の装置と近距離無線通信を行い、前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して処理手段に送信し、前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する通信手段と、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段として機能させるためのプログラムである。

本発明の一側面は、さらに、他の装置と近距離無線通信を行う通信手段と、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段とを備える通信装置の通信手段が、前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記処理手段に送信し、前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する通信方法である。

本発明の他の側面は、他の装置と近距離無線通信を行う通信手段と、所定の規格の第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、前記第１のインターフェイスと異なる規格の第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段とを備え、前記通信手段は、前記第１の処理手段から前記第１のインターフェイスを介して、前記第２の処理手段へのメッセージである第１のメッセージを受信し、受信された前記第１のメッセージを前記第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する通信装置である。

前記通信手段は、前記第１の処理手段から前記第１のインターフェイスを介して受信された前記第１のメッセージのサイズと前記第２のインターフェイスのフォーマットにおけるデータの最大サイズとを比較し、前記第１のメッセージのサイズが前記最大サイズより大きい場合、前記最大サイズに応じて前記第１のメッセージを分割して前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された各分割メッセージを、１つずつ、前記第２のインターフェイスを介して前記第２の処理手段に送信し、前記第１のメッセージのサイズが前記最大サイズより小さい場合、前記最大サイズに応じて複数の前記第１のメッセージを合成して前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された複数の前記第１のメッセージを、一度に、前記第２のインターフェイスを介して前記第２の処理手段に送信することができる。

前記通信手段は、前記第１の処理手段から前記第１のインターフェイスを介して受信された前記第１のメッセージに付加されたフラグ情報に基づいて、前記第１のメッセージと同じ意味のあるデータから分割された後続のメッセージが存在するか否かを判定し、前記後続のメッセージが存在しないと判定された場合、複数の前記第１のメッセージの和のサイズが前記最大サイズより小さくても、更なる合成を終了して前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された複数の前記第１のメッセージを、一度に、前記第２のインターフェイスを介して前記第２の処理手段に送信することができる。

前記通信手段は、前記第２の処理手段から前記第２のインターフェイスを介して、前記第１の処理手段へのメッセージである第２のメッセージを受信し、受信された前記第２のメッセージを前記第１のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第２のメッセージのフォーマットを前記第２のインターフェイスのフォーマットから前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された前記第２のメッセージを、前記第１のインターフェイスを介して前記第１の処理手段に送信することができる。

前記通信手段は、前記第２の処理手段から前記第２のインターフェイスを介して受信された前記第２のメッセージのサイズと前記第１のインターフェイスのフォーマットにおけるデータの最大サイズとを比較し、前記第２のメッセージのサイズが前記最大サイズより大きい場合、前記最大サイズに応じて前記第２のメッセージを分割して前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された各分割メッセージを、１つずつ、前記第１のインターフェイスを介して前記第１の処理手段に送信し、前記第２のメッセージのサイズが前記最大サイズより小さい場合、前記最大サイズに応じて複数の前記第２のメッセージを合成して前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された複数の前記第２のメッセージを、一度に、前記第１のインターフェイスを介して前記第１の処理手段に送信することができる。

前記通信手段は、前記第２の処理手段から前記第２のインターフェイスを介して受信された前記第２のメッセージに付加されたフラグ情報に基づいて、前記第２のメッセージと同じ意味のあるデータから分割された後続のメッセージが存在するか否かを判定し、前記後続のメッセージが存在しないと判定された場合、複数の前記第２のメッセージの和のサイズが前記最大サイズより小さくても、更なる合成を終了して前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された複数の前記第２のメッセージを、一度に、前記第１のインターフェイスを介して前記第１の処理手段に送信することができる。

本発明の他の側面は、また、コンピュータを、他の装置と近距離無線通信を行い、第１の処理手段から所定の規格の第１のインターフェイスを介して、第２の処理手段へのメッセージである第１のメッセージを受信し、受信された前記第１のメッセージを前記第１のインターフェイスと異なる規格の第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する通信手段と、前記第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、前記第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段として機能させるためのプログラムである。

本発明の他の側面は、さらに、他の装置と近距離無線通信を行う通信手段と、所定の規格の第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、前記第１のインターフェイスと異なる規格の第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段とを備える通信装置の通信手段が、前記第１の処理手段から前記第１のインターフェイスを介して、前記第２の処理手段へのメッセージである第１のメッセージを受信し、受信された前記第１のメッセージを前記第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する通信方法である。

本発明の一側面においては、他の装置から受信したメッセージが所定のサイズ毎に分割され、得られた分割メッセージが順次所定のフォーマットでパケット化されて処理手段に送信され、メッセージの送信中に、他のメッセージを送信する場合、他のメッセージの前に、メッセージを終端するメッセージである終端メッセージがそのフォーマットでパケット化されて処理手段に送信される。

本発明の他の側面においては、第１の処理手段から第１のインターフェイスを介して、第２の処理手段へのメッセージである第１のメッセージが受信され、受信された第１のメッセージが第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成され、その第１のメッセージのフォーマットが第１のインターフェイスのフォーマットから第２のインターフェイスのフォーマットに変換され、第２のインターフェイスのフォーマットに変換された第１のメッセージが、第２のインターフェイスを介して第２の処理手段に送信される。

本発明によれば、メッセージを授受することができる。特に、装置内におけるメッセージの伝送をより正確に行うことができる。

本発明を適用した通信装置の主な構成例を示すブロック図である。 HCPパケットの構成例を示す図である。 メッセージのオプショナルデータの構成例を示す図である。 メッセージの分割の様子の例を説明する図である。 イベントの例を説明する図である。 正常終了する場合のメッセージ授受例を説明するフローチャートである。 異常終了する場合の従来のメッセージ授受例を説明するフローチャートである。 制御部およびUICC OSの主な構成例を示す機能ブロック図である。 メッセージ授受例を説明するフローチャートである。 制御部およびUICC OSの他の構成例を示す機能ブロック図である。 メッセージ授受の他の例を説明するフローチャートである。 制御部、UICC OS、およびカードOSの構成例を示す機能ブロック図である。 メッセージ授受の、さらに他の例を説明するフローチャートである。 本発明を適用した通信装置の、他の構成例を示すブロック図である。 制御部およびUICC OSの、さらに他の構成例を示す機能ブロック図である。 メッセージ授受の、さらに他の例を説明するフローチャートである。 本発明を適用した通信装置の、さらに他の構成例を示すブロック図である。 NCIメッセージフォーマットの構成例を示す図である。 制御部の構成例を示す機能ブロック図である。 IDの対応表の例を示す図である。 HCIメッセージフォーマットにNCIデータを含める場合の例を説明する図である。 NCIメッセージフォーマットにHCIデータを含める場合の例を説明する図である。 NCI-HCI変換処理の流れの例を説明するフローチャートである。 NCI-HCI変換処理の流れの例を説明する、図２３に続くフローチャートである。 NCI-HCI変換処理の流れの例を説明する、図２３に続くフローチャートである。 HCPメッセージ受信処理の流れの例を説明するフローチャートである。 NCIからHCIへの変換例を説明する図である。 NCIからHCIへの変換例を説明する図である。 NCIからHCIへの変換例を説明する図である。 HCI-NCI変換処理の流れの例を説明するフローチャートである。 HCI-NCI変換処理の流れの例を説明する、図３０に続くフローチャートである。 HCI-NCI変換処理の流れの例を説明する、図３１に続くフローチャートである。 NCIメッセージ受信処理の流れの例を説明するフローチャートである。 HCIからNCIへの変換例を説明する図である。 HCIからNCIへの変換例を説明する図である。 HCIからNCIへの変換例を説明する図である。 本発明を適用したコンピュータの主な構成例を示すブロック図である。

以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（通信装置）
２．第２の実施の形態（通信装置）
３．第３の実施の形態（通信装置）
４．第４の実施の形態（コンピュータ）

＜１．第１の実施の形態＞
［通信装置の構成］
図１は、本発明を適用した通信装置の主な構成例を示すブロック図である。

図１に示される通信装置１００は、非接触近距離無線通信機能を有するNFCデバイスである。例えば、通信装置１００は、携帯電話機、スマートフォン、PDA（Personal Digital Assistants）、パーソナルコンピュータ、UMPC（Ultra Mobile Personal Computer）、オーディオ機器、カーナビゲーションシステム等であり、所謂非接触ICカードとしての機能を有する電子機器である。

図１に示されるように、通信装置１００は、装置全体を制御する制御部であるターミナルホスト１０１、非接触近距離無線通信を行うCLF１０２、および、そのCLF１０２による非接触近距離無線通信を制御する制御部であるUICC１０３を有する。

CLF１０２とUICC１０３は、バス１０４により接続される。例えば、バス１０４は、物理的な１本の線からなる。また、ターミナルホスト１０１とCLF１０２は、バス１０５により接続される。例えば、バス１０５は、物理的な２本の線からなる。なお、ターミナルホスト１０１とUICC１０３も、例えばバス１０６により接続される。

CLF１０２は、アンテナ１１１、RF部１１２、制御部１１３、並びに、カードRFゲート１１４−１乃至カードRFゲート１１４−３を有する。

アンテナ１１１は、リーダ／ライタ（R/W）等の外部の装置に対して非接触近距離無線通信信号を送受信するためのアンテナである。アンテナ１１１として例えばループアンテナが採用される。

RF部１１２は、非接触近距離無線通信信号の送受信を行なう。例えば、RF部１１２は、制御部１１３から供給されるメッセージを非接触近距離無線通信信号として、アンテナ１１１から送信したり、外部の装置から送信される非接触近距離無線通信信号を、アンテナ１１１を介して受信し、その信号に含まれるメッセージを制御部１１３に供給したりする。

制御部１１３は、RF部１１２を制御し、非接触近距離無線通信信号の送受信を制御する。また、制御部１１３は、カードRFゲート１１４−１乃至カードRFゲート１１４−３を制御し、UICC１０３とのメッセージの授受を制御する。

ここで、CLF１０２とUICC１０３とは、ETSI SCP HCI規格により規定されるロジカルインタフェースにより接続される。このHCI規格のインタフェースでは、ゲートと称するエンドポイント同士が、パイプと称する通信路により接続される。

カードRFゲート１１４−１乃至カードRFゲート１１４−３は、このHCI規格のインタフェースにおけるCLF１０２側のゲートである。

カードRFゲート１１４−１は、このHCI規格のインタフェースにおいて送受信されるメッセージ等を格納するレジストリ１１５−１を有する。また、カードRFゲート１１４−１は、パイプ１３１−１を介して、UICC１０３側のゲートであるカードアプリケーションゲート（以下、カードAPPゲートと称する）１２１−１に接続される。つまり、カードRFゲート１１４−１およびカードAPPゲート１２１−１は、パイプ１３１−１を介して互いにメッセージ等を授受する。

同様に、カードRFゲート１１４−２は、レジストリ１１５−２を有し、パイプ１３１−２を介して、カードAPPゲート１２１−２に接続される。つまり、カードRFゲート１１４−２およびカードAPPゲート１２１−２は、パイプ１３１−２を介して互いにメッセージ等を授受する。

同様に、カードRFゲート１１４−３は、レジストリ１１５−３を有し、パイプ１３１−３を介して、カードAPPゲート１２１−３に接続される。つまり、カードRFゲート１１４−３およびカードAPPゲート１２１−３は、パイプ１３１−３を介して互いにメッセージ等を授受する。

以下において、カードRFゲート１１４−１乃至カードRFゲート１１４−３を互いに区別して説明する必要の無い場合、単にカードRFゲート１１４と称する。また、レジストリ１１５−１乃至レジストリ１１５−３を互いに区別して説明する必要の無い場合、単にレジストリ１１５と称する。

UICC１０３は、カードAPPゲート１２１−１乃至カードAPPゲート１２１−３、UICC OS（Operating System）１２３、カードOS１２４、並びに、アプリケーション１２５−１乃至アプリケーション１２５−Ｎを有する。

カードAPPゲート１２１−１乃至カードAPPゲート１２１−３は、上述したHCI規格のインタフェースにおけるUICC１０３側のゲートである。

カードAPPゲート１２１−１は、パイプ１３１−１を介して、カードRFゲート１１４−１に接続され、送受信されるメッセージ等を格納するレジストリ１２２−１を有する。

同様に、カードAPPゲート１２１−２は、パイプ１３１−２を介して、カードRFゲート１１４−２に接続され、送受信されるメッセージ等を格納するレジストリ１２２−２を有する。

同様に、カードAPPゲート１２１−３は、パイプ１３１−３を介して、カードRFゲート１１４−３に接続され、送受信されるメッセージ等を格納するレジストリ１２２−３を有する。

以下において、カードAPPゲート１２１−１乃至カードAPPゲート１２１−３を互いに区別して説明する必要の無い場合、単にカードAPPゲート１２１と称する。また、レジストリ１２２−１乃至レジストリ１２２−３を互いに区別して説明する必要の無い場合、単にレジストリ１２２と称する。

さらに、パイプ１３１−１乃至パイプ１３１−３を互いに区別して説明する必要の無い場合、単にパイプ１３１と称する。

このようなゲートおよびパイプよりなるHCI規格のインタフェースは、機能やアプリケーション毎に設けられる。CLF１０２およびUICC１０３が有するHCI規格のインタフェースの数は任意である。また、CLF１０２およびUICC１０３が、図１に示される以外のゲートやパイプを有するようにしてもよい。例えば、CLF１０２およびUICC１０３が、非接触近距離無線通信のリーダ／ライタとしての動作を実現するためのアプリケーション用のゲートやパイプを備えるようにしてもよい。

UICC OS１２３は、UICC１０３のハードウェアのインタフェースをソフトウェアに提供する基本ソフトウェアである。カードOS１２４は、非接触近距離無線通信を行う非接触ICカード機能に関するインタフェースをソフトウェアに提供する基本ソフトウェアである。

アプリケーション１２５−１乃至アプリケーション１２５−Ｎは、それぞれ、非接触近距離無線通信を用いる、互いに異なる機能を実現するためのソフトウェアである。

なお、以上においては、CLF１０２とUICC１０３との間のロジカルインタフェースについて説明したが、ターミナルホスト１０１とCLF１０２との間のロジカルインタフェース、および、ターミナルホスト１０１とUICC１０３との間のロジカルインタフェースも、それぞれ、HCI規格のインタフェースにより構成されるようにしてもよい。

［HCPパケット］
次に、HCI規格について説明する。図２は、HCP（Host Controller Protocol）パケットの構成例を示す図である。パイプを送受信されるメッセージは、データリンク層においてホストコントローラにより、図２に示されるようにパケット化される。

図２に示されるように、パケットはヘッダ（header）とメッセージ（message）とにより構成される。

ヘッダ（header）には、CB（Chaining bit）およびP_ID（Pipe Identifier）が含まれる。

CBは、そのパケットのメッセージが、最後以外の分割メッセージであるか否かを示すフラグ情報である。

例えば、そのパケットのメッセージが、分割（細分化）されたメッセージ（分割メッセージ）であり、かつ、その複数に分割されたメッセージの最後の部分ではない（すなわち、最後以外の分割メッセージである）場合、CBは「０」をとる。

また、例えば、そのパケットのメッセージが、分割されたメッセージではない、または、分割されたメッセージの最後の部分であると判定された場合、CBは、「１」をとる。

P_IDは、パケットの伝送に使用されるパイプを識別する識別情報である。つまり、P_IDは、パケットの送信先ゲートを示す情報でもある。

メッセージ（message）には、ｎバイトのメッセージが格納される。

［HCPメッセージ］
ところで、メッセージは、図３に示されるように、メッセージヘッダ（header）とデータ（data）により構成される。

メッセージヘッダ（header）には、タイプ（TYPE）と指示（INSTRUCTION）が含まれる。

タイプ（TYPE）は、指示の種類を示す識別情報である。指示には、例えば、「命令（commands）」（TYPE＝０）、「イベント（events）」（TYPE＝１）、および「（命令に対する）応答（responses to commands）」（TYPE＝２）がある。また、リザーブ（RFU）としてTYPE＝３もある。

指示の種類によらず、データを付加することができる。使用可能なイベントや命令の内容は、ゲートによって予め決められている。ゲートは、パイプが開放されているときのみイベントや命令を許可する。また、ゲートは、パイプが命令に対する応答待ちの状態の場合、イベントや命令を許可しない。

指示（INSTRUCTION）は、指示の識別情報を示す。

［分割メッセージ］
図４は、メッセージの分割の様子の例を説明する図である。メッセージは、そのサイズが、データリンク層で認められているサイズより大きい場合、分割される。以下においてこの分割されたメッセージを分割メッセージと称する。

図４に示されるように、メッセージは、メッセージヘッダ（message header）の先頭から、データ伝送の規格において定められるデータサイズの最大値（例えば、データリンク層で認められている伝送可能な所定のデータサイズの最大値）毎に分割される。したがって、メッセージヘッダ（message header）は、このような分割により生成された分割メッセージのうち、最初の分割メッセージにのみ付加されている。

しかしながら、パケットヘッダ（packet header）は、図２を参照して説明したように、全ての分割メッセージに付加される。

上述したように、１つのメッセージから生成された分割メッセージのうち、最後の分割メッセージのみ、CBの値が「１」となり、それ以外は、「０」となる。

［イベント］
図５に、カードAPPゲート１２１が対応可能なイベントの一覧を示す。

イベント「EVT_FIELD_ON」は、通信装置１００の外部のリーダ等のデバイスから供給されるRF信号がCLF１０２において検知された場合、CLF１０２からUICC１０３へ送信される。

イベント「EVT_CARD_DEACTIVATED」は、CLF１０２が、ISO（International Organization for Standardization）/IEC（International Electrotechnical Commission）14443-3 for Type B、若しくは、ISO/IEC14443-4 for Type Aにおいて定義される「deactivated」となる場合、CLF１０２からUICC１０３へ送信される。

イベント「EVT_CARD_ACTIVATED」は、CLF１０２が、ISO/IEC14443-3 for Type B、若しくは、ISO/IEC14443-4 for Type Aにおいて定義される「activated」となる場合、CLF１０２からUICC１０３へ送信される。

イベント「EVT_FIELD_OFF」は、通信装置１００の外部のリーダ等のデバイスから供給されるRF信号がCLF１０２において検知されなくなった場合、CLF１０２からUICC１０３へ送信される。

イベント「EVT_SEND_DATA」は、CLF１０２からUICC１０３にデータを送信する際に、CLF１０２からUICC１０３へ送信される。

［処理の流れ］
携帯電話等の、HCIを使用するNFCデバイスが、非接触ICカードとして動作するカードエミュレーションモードで動作するときは、リーダ／ライタ等が出力する外部のRFフィールドから電力を得て、そのリーダ／ライタからRFフィールドの変調で送信されるコマンドを受信して処理し、負荷変調によりレスポンスを返す。

リーダ／ライタからのコマンドは、CLF１０２で受信し、パイプ１３１を通じて、UICC１０３へ転送される。

このとき、リーダ／ライタから送信されるコマンドが、上述したように、パイプ上を流すデータの最大長よりも長く、複数の分割メッセージを送信しなければならない状況がある。

図６のフローチャートを参照して、分割メッセージ送信が正常終了する場合の処理の流れの例を説明する。

外部からRFデータを受信したRF部１１２は、ステップＳ１０１において、そのRFデータを制御部１１３に供給する。

制御部１１３は、ステップＳ１１１においてそのRFデータを受信すると、そのRFデータを分割し、各分割メッセージをステップＳ１１２乃至ステップＳ１１５において、カードRFゲート１１４を介して送信する。

ステップＳ１１２乃至ステップＳ１１４において送信される分割メッセージ（RF data 1、RF data 2、RF data 3）のCBは、「０」である。ステップＳ１１５において送信される最後の分割メッセージ（RF data 4）のCBは、「１」である。

CLF１０２から送信されたこれらの分割メッセージは、パイプ１３１を介してUICC１０３に供給される。

UICC OS１２３は、ステップＳ１２１乃至ステップＳ１２４において、カードAPPゲート１２１を介して、それらの分割メッセージを受信する。

CBの値が１の分割メッセージを取得すると、UICC OS１２３は、その分割メッセージを最後の分割メッセージと認識し、ステップＳ１２５において、それまでに取得した分割メッセージを組み立て、分割前のメッセージを復元する。

このような分割メッセージの送信中に、イベントが発生する場合がある。従来の方法では、そのイベントの発生により、例えば、図７に示されるフローチャートの例のように、分割メッセージの送信が異常終了してしまう恐れがあった。

例えば、図７に示されるように、図６の場合と同様に、ステップＳ１３１において、RF部１１２が、外部から受信したRFデータを制御部１１３に供給する。制御部１１３は、図６の場合と同様に、ステップＳ１４１においてそのRFデータを受信し、そのRFデータを分割し、各分割メッセージを順次送信しようとする（ステップＳ１４２乃至ステップＳ１４４）。

CLF１０２から送信されたこれらの分割メッセージは、パイプ１３１を介してUICC１０３に供給され、UICC OS１２３は、ステップＳ１５１乃至ステップＳ１５３において、カードAPPゲート１２１を介して、それらの分割メッセージを受信する。

このとき（最後の分割メッセージ（RF data 4）を送信する前）、ステップＳ１３２において、RF部１１２が、外部のリーダ／ライタからの信号を検出できなくなると、制御部１１３は、ステップＳ１４５において、その旨を把握する。制御部１１３は、ステップＳ１４６において、リーダ／ライタからの信号を検出できなくなったことを示すイベント「EVT_FIELD_OFF」を分割メッセージと同様にUICC OS１２３に送信する。

このイベントメッセージは分割メッセージで無いのでCBは「１」である。UICC OS１２３は、ステップＳ１５４において、そのイベントメッセージを受信する。CBが「１」であるのでUICC OS１２３は、その分割メッセージを最後の分割メッセージと認識し、ステップＳ１５５において、それまでに取得した分割メッセージを組み立て、分割前のメッセージを復元しようとする。

したがってUICC OS１２３は、イベント「EVT_FIELD_OFF」を認識できなくなる。これにより、RFの状態とNFCデバイスの内部状態に不整合が生じ、NFCデバイスの処理が正しく行われない恐れがあった。

カードOS１２４は、モードと呼ばれる状態を管理し、その状態に応じて対応できるコマンドを制御する。例えば、カードOS１２４は、モードによって、ポーリングに応答するか否かを制御する。しかしながら、例えば、リーダ／ライタからのコマンドによってカードOS１２４のモードが２（ポーリングに応答しない状態）になっているときに、上述したようにイベント「EVT_FIELD_OFF」を認識できないと、カードOS１２４は、モードが０（ポーリングに応答する状態）に戻らずに、その後のポーリングに応答することができなくなり、リーダ／ライタはNFCデバイスを検出することができなくなる恐れがあった。

以上においては、イベント「EVT_FIELD_OFF」について説明したが、これ以外にも、例えば、UICC１０３上で１つのカードAPPゲート１２１およびパイプ１３１を複数のアプリケーション１２５（カードアプリケーション）で共有することも考えられる。このように、複数のカードアプリケーションを同時にアクティベートするような場合、CLF１０２がイベント「EVT_ACTIVATED」やイベント「EVT_DEACTIVATED」を他のメッセージとして送信することがある。

このような場合、分割メッセージの後ろに、そのメッセージが追加されることになり、受信側（UICC OS１２３）は、分割メッセージの次のメッセージを正しく認識することができない恐れがあった。

イベント「EVT_ACTIVATED」を認識することができない場合、UICC１０３上のアプリケーションが起動していないにも関わらず、リーダ／ライタからアプリケーション用のコマンドが送信され、そのコマンドに対してレスポンスを返すことができず、アプリケーションが実行できなくなる恐れがあった。

イベント「EVT_DEACTIVATED」を認識できない場合、UICC１０３上のアプリケーションを終了していないにも関わらず、次のアプリケーション起動(EVT_ACTIVATED)のメッセージが送信されることになる。前回実行したアプリケーションの状態が残っている可能性があり、その状態がアプリケーションの動作に影響を与える場合もあり得る。たとえば、前回実行したアプリケーションで生成したセッション鍵がそのまま残っていて、次のアプリケーションのセッション鍵を誤って利用するなどが考えられる。

［機能ブロックの構成例］
そこで、制御部１１３およびUICC OS１２３は、図８に示されるような機能ブロックを有する。

図８Ａに示されるように、制御部１１３は、機能ブロックとして、メッセージ分割部３０１、メッセージ送信部３０２、異常検出部３０３、終端メッセージ送信部３０４、およびイベント送信部３０５を有する。

また、図８Ｂに示されるように、UICC OS１２３は、機能ブロックとして、メッセージ受信部３１１、フラグ判定部３１２、メッセージ合成部３１３、およびメッセージ確認部３１４を有する。

［処理の流れ］
この場合の分割メッセージ授受の例を図９のフローチャートを参照して説明する。

図６の場合と同様に、ステップＳ２０１において、RF部１１２が、外部から受信したRFデータを制御部１１３に供給する。制御部１１３のメッセージ分割部３０１は、図６の場合と同様に、ステップＳ２１１においてそのRFデータを受信し、そのRFデータを、所定のサイズごとに分割する。

メッセージ送信部３０２は、得られた分割メッセージを１つずつ、カードRFゲート１１４を介してUICC１０３に送信する。CLF１０２から送信されたこれらの分割メッセージは、パイプ１３１を介してUICC１０３に供給される。UICC OS１２３は、カードAPPゲート１２１を介して、それらの分割メッセージを受信する。

例えば、メッセージ分割部３０１が、RFデータを４つの分割メッセージに分割するとする。メッセージ送信部３０２は、ステップＳ２１２において、最初の分割メッセージ（RF data 1）を送信する。UICC OS１２３のメッセージ受信部３１１は、ステップＳ２２１においてこの分割メッセージ（RF data 1）を受信する。このパケットのCBは「０」である。フラグ判定部３１２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 1）をメッセージ合成部３１３に供給する。

次に、メッセージ送信部３０２は、ステップＳ２１３において、２番目の分割メッセージ（RF data 2）を送信する。UICC OS１２３のメッセージ受信部３１１は、ステップＳ２２２においてこの分割メッセージ（RF data 2）を受信する。このパケットのCBは「０」である。フラグ判定部３１２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 2）をメッセージ合成部３１３に供給する。

さらに、メッセージ送信部３０２は、ステップＳ２１４において、３番目の分割メッセージ（RF data 3）を送信する。UICC OS１２３のメッセージ受信部３１１は、ステップＳ２２３においてこの分割メッセージ（RF data 3）を受信する。このパケットのCBは「０」である。フラグ判定部３１２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 3）をメッセージ合成部３１３に供給する。

このとき（最後の分割メッセージ（RF data 4）が送信される前）、ステップＳ２０２において、RF部１１２が、外部のリーダ／ライタからの信号を検出できなくなる（近距離無線通信が切断される）と、制御部１１３の異常検出部３０３は、ステップＳ２１５において、その旨を検出する。

終端メッセージ送信部３０４は、ステップＳ２１６において、イベントメッセージを送信する前に、RFエラー（RF error）を通知するとともに、分割メッセージを終端させる終端メッセージを送信する。つまり、この終端メッセージは、分割メッセージを終端させるとともに、その理由が近距離無線通信の切断によるものであることを示す。この終端メッセージ（RF error）は、他の分割メッセージと同様に、カードRFゲート１１４からパイプ１３１を介してカードAPPゲート１２１に供給される。

UICC OS１２３のメッセージ受信部３１１は、ステップＳ２２２においてこの終端メッセージ（RF error）を受信する。このパケットのCBは「１」である。フラグ判定部３１２は、CBの値が「１」であると判定すると、この終端メッセージ（RF error）をメッセージ合成部３１３に供給する。

また、終端メッセージが伝送されると、イベント送信部３０５は、ステップＳ２１７において、イベント「EVT_FIELD_OFF」を分割メッセージと同様にUICC OS１２３に送信する。

このイベントメッセージは分割メッセージで無いのでCBは「１」である。UICC OS１２３のメッセージ受信部３１１は、ステップＳ２２５において、そのイベントメッセージを受信する。CBが「１」であるのでフラグ判定部３１２は、そのイベントメッセージを分割メッセージでないと認識し、メッセージ確認部３１４に供給する。

メッセージ合成部３１３は、ステップＳ２２６において、取得した分割メッセージ（RF data 1 乃至 RF data 3）と終端メッセージ（RF error）を合成する。メッセージ合成部３１３は、その合成結果をメッセージ確認部３１４に供給する。

したがってメッセージ確認部３１４は、その合成結果を１つのメッセージとして把握することができ、さらに、その合成結果とは別に供給されたイベントメッセージ「EVT_FIELD_OFF」を認識することができる。

これにより、カードOS１２４は、イベントメッセージ「EVT_FIELD_OFF」に基づいて、動作モードを、モード０に戻すことができる。つまり、CLF１０２は、その後のポーリングに応答することができるようになる。

つまり、イベント送信部３０５が他のメッセージを送信する前に、終端メッセージ送信部３０４が、分割メッセージを終端させる終端メッセージを送信するので、UICC OS１２３は、正しく分割メッセージを受信することができる。

以上のように、通信装置１００は、装置内におけるメッセージの伝送をより正確に行うことができる。

なお、分割メッセージの送信中に割り込み、送信する他のメッセージは、任意のメッセージであり、イベントメッセージ以外のメッセージであってももちろんよい。すなわち、CLF１０２は、任意の状況において、分割メッセージを送信中に（分割メッセージの送信終了を待たずに）、任意の他のメッセージを送信する場合、分割メッセージを終端させる終端メッセージを送信することにより、装置内におけるメッセージの伝送をより正確に行うことができる。

［機能ブロックの他の構成例］
なお、以上においては、制御部１１３が、RF部１１２が受信するデータをUICC１０３へ分割して転送する場合について説明したが、UICC１０３がCLF１０２に対して分割メッセージを送信する場合も考えられる。

その場合も、上述した場合と基本的に同様に、終端メッセージによって分割メッセージを終端させることができる。

この場合、制御部１１３およびUICC OS１２３は、図１０に示されるような機能ブロックを有する。

図１０Ａに示されるように、制御部１１３は、機能ブロックとして、メッセージ受信部４０１、フラグ判定部４０２、メッセージ合成部４０３、メッセージ確認部４０４、異常検出部４０５、およびイベント送信部４０６を有する。

また、図１０Ｂに示されるように、UICC OS１２３は、機能ブロックとして、メッセージ分割部４２１、メッセージ送信部４２２、イベント受信部４２３、および終端メッセージ送信部４２４を有する。

［処理の流れ］
この場合の分割メッセージ授受の例を図１１のフローチャートを参照して説明する。

UICC OS１２３のメッセージ分割部４２１は、CLF１０２に送信するメッセージを所定のサイズ毎に分割する。メッセージ送信部４２２は、得られた分割メッセージを１つずつ、カードAPPゲート１２１を介してCLF１０２に送信する。UICC１０３から送信されたこれらの分割メッセージは、パイプ１３１を介してCLF１０２に供給される。制御部１１３は、カードRFゲート１１４を介して、それらの分割メッセージを受信する。

例えば、メッセージ分割部４２１が、メッセージを４つの分割メッセージに分割するとする。メッセージ送信部４２２は、ステップＳ３２１において、最初の分割メッセージ（RF data 1）を送信する。制御部１１３のメッセージ受信部４０１は、ステップＳ３１１においてこの分割メッセージ（RF data 1）を受信する。このパケットのCBは「０」である。フラグ判定部４０２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 1）をメッセージ合成部４０３に供給する。

次に、メッセージ送信部４２２は、ステップＳ３２２において、２番目の分割メッセージ（RF data 2）を送信する。制御部のメッセージ受信部４０１は、ステップＳ３１２においてこの分割メッセージ（RF data 2）を受信する。このパケットのCBは「０」である。フラグ判定部４０２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 2）をメッセージ合成部４０３に供給する。

さらに、メッセージ送信部４２２は、ステップＳ３２３において、３番目の分割メッセージ（RF data 3）を送信する。制御部１１３のメッセージ受信部４０１は、ステップＳ３１３においてこの分割メッセージ（RF data 3）を受信する。このパケットのCBは「０」である。フラグ判定部４０２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 3）をメッセージ合成部４０３に供給する。

このとき（最後の分割メッセージ（RF data 4）が送信される前）、ステップＳ３０１において、RF部１１２が、外部のリーダ／ライタからの信号を検出できなくなると、制御部１１３の異常検出部４０５は、ステップＳ３１４において、その旨を把握する。

イベント送信部４０６は、ステップＳ３１５において、イベント「EVT_FIELD_OFF」を分割メッセージと同様にUICC OS１２３に送信する。UICC OS１２３のイベント受信部４２３は、ステップＳ３２４において、そのイベントメッセージを受信する。

イベント「EVT_FIELD_OFF」により、リーダ／ライタとの通信が不可能となったことが判明したので、終端メッセージ送信部４２４は、ステップＳ３２５において、CBが「１」のメッセージを制御部１１３に送信する。

このUICC OS１２３から制御部１１３へ向かうメッセージの場合、RFエラー（RF error）を示すフィールドが規定されていないため、エラーであることを示すことができない。しかしながら、上述したように、終端メッセージ送信部４２４は、CBが「１」の空メッセージを送信することで分割メッセージを終端させる指示を行うことができる。

制御部１１３のメッセージ受信部４０１は、ステップＳ３１６において、この空メッセージを受信する。

メッセージ合成部４０３は、ステップＳ３１７において、取得した分割メッセージ（RF data 1 乃至 RF data 3）と空メッセージを合成する。メッセージ合成部４０３は、その合成結果をメッセージ確認部４０４に供給する。

したがってメッセージ確認部４０４は、その合成結果を１つのメッセージとして解釈することができる。つまり、次に新たなメッセージ（若しくは分割メッセージ）が送信されてきても、メッセージ確認部４０４は、それを、上述した合成結果とは異なる新たなメッセージとして解釈することができる。

つまり、CLF１０２は、新たに供給されたメッセージを正しく受信することができる。

以上のように、通信装置１００は、装置内におけるメッセージの伝送をより正確に行うことができる。

［機能ブロックの、さらに他の構成例］
なお、例えば、リーダ／ライタとの近距離無線通信が不通になると、UICC OS１２３がイベント「EVT_FIELD_OFF」を受信しなくても、CLF１０２は、リーダ／ライタからのコマンド等を受信しない状態が続く。つまり、UICC OS１２３も同様にCLF１０２からのメッセージを受信しない状態が続く。

したがって、UICC OS１２３は、予め定められた所定の時間をタイムアウト時間と定め、CLF１０２からのメッセージを受信しない時間がそのタイムアウト時間以上になった場合、リーダ／ライタとの近距離無線通信が不通になったと判定し、カードOS１２４の動作モードを０に戻し、その後のポーリングに応答することができるようにするようにしてもよい。

なお、リーダ／ライタから送信されるコマンドとコマンドの間隔はアプリケーションにも依存する。したがって、NFCデバイス内でタイムアウト時間を自由に設定できるようにすることが望ましい。

図１２は、制御部、UICC OS、およびカードOSの構成例を示す機能ブロック図である。

図１２Ａに示されるように、制御部１１３は、機能ブロックとして、イベント送信部５０１、メッセージ分割部５０２、メッセージ送信部５０３、およびメッセージ受信部５０４を有する。

図１２Ｂに示されるように、UICC OS１２３は、メッセージ受信部５１１、RFフィールド更新部５１２、フラグ判定部５１３、メッセージ合成部５１４、メッセージ供給部５１５、メッセージ取得部５１６、メッセージ送信部５１７、タイムアウト判定部５１８、およびRFフィールド通知部５１９を有する。

図１２Ｃに示されるように、カードOS１２４は、メッセージ取得部５３１、モード切替部５３２、メッセージ送信部５３３、およびRFフィールド通知取得部５３４を有する。

［処理の流れ］
この場合の分割メッセージ授受の例を図１３のフローチャートを参照して説明する。

なお、UICC OS１２３は、タイムアウト時間とRFフィールドの現在の状態を保持する。RFフィールドの状態の初期値はOFFである。

また、カードOS１２４は、動作モードの設定値を保持する。カードOS１２４のモードの初期値は０である。

図１３において、リーダ／ライタによりRFフィールドが生成されると、RF部１１２は、ステップＳ４０１において、制御部１１３に対してその旨通知する。ステップＳ４１１において、その通知を取得すると、制御部１１３のイベント送信部５０１は、ステップＳ４１２において、イベント「EVT_FIELD_ON」をUICC OS１２３に送信する。

このイベントメッセージは分割メッセージで無いのでCBは「１」である。UICC OS１２３のメッセージ受信部５１１は、ステップＳ４２１において、そのイベントメッセージを受信する。RFフィールド更新部５１２は、ステップＳ４２２において、RFフィールドの状態をOFFからONに更新する。

リーダ／ライタからコマンド１を受信するとRF部１１２は、ステップＳ４０２において、制御部１１３に対して、そのコマンド１を供給する。制御部１１３は、ステップＳ４１３においてそのコマンド１を取得すると、ステップＳ４１４において、そのコマンド１をUICC OS１２３に送信する。UICC OS１２３のメッセージ受信部５１１は、ステップＳ４２３において、そのコマンド１を受信する。このコマンド１は、上述したように分割メッセージとして送信するようにしてもよい。

フラグ判定部５１３がコマンド１のメッセージが分割メッセージでないと判定すると、ステップＳ４２４において、メッセージ供給部５１５は、コマンド１をカードOS１２４に供給する。

カードOS１２４のメッセージ取得部５３１は、ステップＳ４４１において、そのコマンド１を取得する。モード切替部５３２は、ステップＳ４４２において、モードを０から２に切り替える。ステップＳ４４３において、メッセージ送信部５３３は、コマンド１に対する応答であるレスポンス１をUICC OS１２３に供給する。

ステップＳ４２５において、メッセージ取得部５１６は、レスポンス１を取得する。ステップＳ４２６において、メッセージ送信部５１７は、レスポンス１を制御部１１３に送信する。制御部１１３のメッセージ受信部５０４は、ステップＳ４１５においてそのレスポンス１を受信する。このレスポンス１は、上述したように分割メッセージとして送信するようにしてもよい。

制御部１１３は、ステップＳ４１６においてそのレスポンス１をRF部１１２に供給する。RF部１１２は、ステップＳ４０３においてそのレスポンス１を取得すると、そのレスポンス１をリーダ／ライタに送信する。

その後、リーダ／ライタが不通になり、RFフィールドが非活性化するなどして、UICC・OS１２３がタイムアウト時間以上、制御部１１３からコマンドが供給されない場合、タイムアウト判定部５１８は、タイムアウトが発生したと判定する。

タイムアウトが成立すると、RFフィールド更新部５１２は、ステップＳ４２７において、RFフィールドの状態をONからOFFに更新する。また、ステップＳ４２８において、RFフィールド通知部５１９は、RFフィールドの状態を更新した旨をカードOS１２４に通知する。

カードOS１２４のメッセージ取得部５３１は、ステップＳ４４４においてその通知を取得する。ステップＳ４４４においてモード切替部５３２は、モードを２から０に切り替える。

以上のようにタイムアウト時間を設け、それに基づいた制御を行うことにより、イベント「EVT_FIELD_OFF」を授受しなくても、カードOS１２４の動作を切り替えるようにし、次のメッセージに対して備えることができる。

以上のように、通信装置１００は、装置内におけるメッセージの伝送をより正確に行うことができる。

なお、以上のようなタイムアウトを用いた制御を、上述した終端メッセージを用いる方法に組み合わせるようにしてもよい。その場合、終端メッセージを用いて分割メッセージ送信の中断を適切に処理するとともに、終端メッセージの送信ができなかった場合であっても、タイムアウト制御によって早期に次のメッセージの受信を正しく行うことができるようにすることができる。

すなわち、通信装置１００は、装置内におけるメッセージの伝送をより正確に行うことができる。

＜２．第２の実施の形態＞
［概要］
CLFとUICC間で、別のハードウェアのラインを接続しておき、EVT_FIELD_OFFを受信できない場合については、CLFがRFフィールドの消失を検出した時点で、EVT_FIELD_OFFメッセージを送信するとともに、このラインへ信号を送出するようにしてもよい。

EVT_ACTIVATED、EVT_DEACTIVATEDについても同じライン上で信号を送出する。送出する信号は、メッセージごとに定義する必要がある。

以下により具体的に説明する。

［通信装置の構成］
図１４は、本発明を適用した通信装置の、他の構成例を示すブロック図である。

図１４に示されるように、通信装置６００も、基本的に通信装置１００と同様の構成を有し、同様の処理を行う。つまり、通信装置６００は、ターミナルホスト６０１に対応するターミナルホスト６０１、CLF１０２に対応するCLF６０２、および、UICC１０３に対応するUICC６０３、バス１０４に対応するバス６０４、バス１０５に対応するバス６０５を有する。例えば、バス６０４は、物理的な１本の線からなる。また、例えば、バス６０５は、物理的な２本の線からなる。なお、ターミナルホスト６０１とUICC６０３も、例えばバス１０６に対応するバス６０６により接続される。

CLF６０２は、アンテナ１１１に対応するアンテナ６１１、RF部１１２に対応するRF部６１２、制御部１１３に対応する制御部６１３、並びに、カードRFゲート１１４−１乃至カードRFゲート１１４−３に対応するカードRFゲート６１４−１乃至カードRFゲート６１４−３を有する。

また、カードRFゲート６１４−１乃至カードRFゲート６１４−３は、それぞれ、レジストリ１１５−１乃至レジストリ１１５−３に対応するレジストリ６１５−１乃至レジストリ６１５−３を有する。

また、カードRFゲート６１４−１乃至カードRFゲート６１４−３は、それぞれ、パイプ１３１−１乃至パイプ１３１−３に対応するパイプ６３１−１乃至パイプ６３１−３に接続される。

UICC６０３は、カードAPPゲート１２１−１乃至カードAPPゲート１２１−３にそれぞれ対応するカードAPPゲート６２１−１乃至カードAPPゲート６２１−３、UICC OS１２３に対応するUICC OS６２３、カードOS１２４に対応するカードOS６２４、並びに、アプリケーション１２５−１乃至アプリケーション１２５−Ｎにそれぞれ対応するアプリケーション６２５−１乃至アプリケーション６２５−Ｎを有する。

また、カードAPPゲート６２１−１乃至カードAPPゲート６２１−３は、それぞれ、レジストリ１２２−１乃至レジストリ１２２−３に対応するレジストリ６２２−１乃至レジストリ６２２−３を有する。

また、カードAPPゲート６２１−１乃至カードAPPゲート６２１−３は、それぞれ、パイプ６３１−１乃至パイプ６３１−３に接続される。

つまり、カードRFゲート６１４−１乃至カードRFゲート６１４−３と、カードAPPゲート６２１−１乃至カードAPPゲート６２１−３とは、それぞれ、パイプ６３１−１乃至パイプ６３１−３を介して互いに接続される。

以下において、カードRFゲート６１４−１乃至カードRFゲート６１４−３を互いに区別して説明する必要の無い場合、単にカードRFゲート６２１と称する。また、レジストリ６１５−１乃至レジストリ６１５−３を互いに区別して説明する必要の無い場合、単にレジストリ６２２と称する。

さらに、パイプ６３１−１乃至パイプ６３１−３を互いに区別して説明する必要の無い場合、単にパイプ６３１と称する。

同様に、カードAPPゲート６２１−１乃至カードAPPゲート６２１−３を互いに区別して説明する必要の無い場合、単にカードAPPゲート６２１と称する。また、レジストリ６２２−１乃至レジストリ６２２−３を互いに区別して説明する必要の無い場合、単にレジストリ６２２と称する。

CLF６０２およびUICC６０３は、上述したパイプ６３１の他に、さらにライン６４１により接続される。このライン６４１においては、パイプ６３１を介してイベントメッセージが伝送されることを示す制御信号が授受される。この制御信号は、イベントメッセージ毎に定義される信号であってもよい。その場合、制御信号を解析することにより、イベントメッセージの種類が識別可能となる。

［機能ブロックの構成例］
制御部６１３およびUICC OS６２３は、図１５に示されるような機能ブロックを有する。

図１５Ａに示されるように、制御部６１３は、機能ブロックとして、メッセージ分割部７０１、メッセージ送信部７０２、異常検出部７０３、イベント送信部７０４、および制御信号送信部７０５を有する。

また、図１５Ｂに示されるように、UICC OS６２３は、機能ブロックとして、メッセージ受信部７２１、フラグ判定部７２２、メッセージ合成部７２３、メッセージ確認部７２４、制御信号受信部７２５を有する。

［処理の流れ］
この場合の分割メッセージ授受の例を図１６のフローチャートを参照して説明する。

ステップＳ５０１において、RF部６１２が、外部から受信したRFデータを制御部６１３に供給する。制御部６１３のメッセージ分割部７０１は、ステップＳ５１１においてそのRFデータを受信し、そのRFデータを、所定のサイズごとに分割する。

メッセージ送信部７０２は、得られた分割メッセージを１つずつ、カードRFゲート６１４を介してUICC６０３に送信する。CLF６０２から送信されたこれらの分割メッセージは、パイプ６３１を介してUICC６０３に供給される。UICC OS６２３は、カードAPPゲート６２１を介して、それらの分割メッセージを受信する。

例えば、メッセージ分割部７０１が、RFデータを４つの分割メッセージに分割するとする。メッセージ送信部７０２は、ステップＳ５１２において、最初の分割メッセージ（RF data 1）を送信する。UICC OS６２３のメッセージ受信部７２１は、ステップＳ５３１においてこの分割メッセージ（RF data 1）を受信する。このパケットのCBは「０」である。フラグ判定部７２２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 1）をメッセージ合成部７２３に供給する。

次に、メッセージ送信部７０２は、ステップＳ５１３において、２番目の分割メッセージ（RF data 2）を送信する。UICC OS６２３のメッセージ受信部７２１は、ステップＳ５３２においてこの分割メッセージ（RF data 2）を受信する。このパケットのCBは「０」である。フラグ判定部７２２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 2）をメッセージ合成部７２３に供給する。

さらに、メッセージ送信部７０２は、ステップＳ５１４において、３番目の分割メッセージ（RF data 3）を送信する。UICC OS６２３のメッセージ受信部７２１は、ステップＳ５３３においてこの分割メッセージ（RF data 3）を受信する。このパケットのCBは「０」である。フラグ判定部７２２は、CBの値が「０」であると判定すると、この分割メッセージ（RF data 3）をメッセージ合成部７２３に供給する。

このとき（最後の分割メッセージ（RF data 4）が送信される前）、ステップＳ５０２において、RF部６１２が、外部のリーダ／ライタからの信号を検出できなくなると、制御部６１３の異常検出部７０３は、ステップＳ５１５において、その異常を検出する。

イベント送信部７０４は、ステップＳ５１６において、イベントメッセージを、カードRFゲート６１４およびパイプ６３１を介して、UICC６０３に送信する。このとき、制御信号送信部７０５は、ステップＳ５１７において、イベントメッセージの送信と同時に、そのイベントメッセージに対応する制御信号を、ライン６４１を介してUICC６０３に送信する。

UICC OS６２３は、ステップＳ５３５において、その制御信号を受信する。UICC OS６２３は、その制御信号を解析することにより、パイプ６３１を介して送信されるメッセージがイベントメッセージであることを把握することができる。

つまり、UICC OS６２３は、以上のように、分割メッセージの送信が途中で中断されて、イベントメッセージが送信されるような場合であっても、制御信号を用いることにより、イベントメッセージを正しく検出し、その内容を把握することができる。

以上のように、通信装置６００は、装置内におけるメッセージの伝送をより正確に行うことができる。

＜３．第３の実施の形態＞
［概要］
以上においては、通信装置が外部の装置と非接触近距離無線通信を行う際の、CLFとUICCとの間のHCI仕様の通信について説明した。

ところで、CLF（NFCC）がUICCとNFC全体の制御を行うDH（Device Host）に接続される場合、CLF（NFCC）−UICC間のインターフェイスではETSI SCP HCI規格の仕様によるデータ交換が行われ、CLF（NFCC）−DH間のインターフェイスではNFC FORUM NCI（NFC Controller Interface）規格の仕様によるデータ交換が行われる。

このような場合、CLF（NFCC）は、DH−UICC間通信のために、その２つの仕様の間での変換機能を有する必要がある。しかしながら、実際には、このような変換処理を定義する規格は存在せず、ベンダにより独自のインターフェイスが設けられていた。

そこで、本実施の形態においては、このHCIとNCIの２つの規格の間の変換処理を定義し、UICCとDHがこれらの２つのインターフェイスを介して容易にデータ交換を行うことができるようにする。

［通信装置］
図１７は、本発明を適用した通信装置の主な構成例を示すブロック図である。通信装置８００は、図１の通信装置１００と同様の非接触近距離無線通信機能を有するNFCデバイスである。

図１７に示されるように、通信装置８００は、基本的に、図１の通信装置１００と同様の構成を有し、同様の処理を行う。すなわち、通信装置８００は、CLF１０２と同様のCLF８０２と、UICC１０３と同様のUICC８０３を有する。ただし、通信装置８００は、ベンダ独自のインターフェイスを介してCLF１０２やUICC１０３と通信を行うターミナルホスト１０１の代わりに、NCI規格のインターフェイスを介してCLF８０２と通信を行うデバイスホスト８０１を有する。

デバイスホスト（DH）８０１は、通信装置８００全体の制御等を行う。デバイスホスト８０１は、バス８１１を介してCLF８０２と接続されており、このバス８１１を介してCLF８０２と通信を行う。デバイスホスト８０１は、NCI規格に従って、CLF８０２と通信を行う。

図１８に、NCI規格に準拠したNCIメッセージフォーマットの構成例を示す。図１８に示されるように、NCIメッセージは、２４バイトのヘッダ情報（NCIメッセージヘッダ）と、ＬバイトのNCIメッセージデータにより構成される。

NCIメッセージヘッダには、PBF、ConnID、Credit_Avail、およびData Length（L）が含まれる。PBFは、NCIメッセージデータが、NCIのバッファサイズ（一度に伝送可能なデータ最大長）毎に分割された分割メッセージであって、このデータに後続するデータが存在するか否かを示すフラグ情報である。PBF＝１の場合、後続のデータが存在する。なお、NCIバッファサイズ（NCI buffer size）は、コネクション作成時に指定される。

ConnIDは、コネクションを識別する識別情報である。なお、ConnIDは、コネクション作成時にCLF８０２によって割り当てられる。Credit_Availは、CLF８０２によるNCIのフロー制御に使用される。Data Length（L）は、NCIメッセージデータのデータ長を示す。

デバイスホスト８０１は、CLF８０２を介して、UICC８０３ともメッセージの授受を行う。例えば、デバイスホスト８０１は、通信装置８００において、非接触ICカードとしての機能を実現するアプリケーションを実行する。例えば、デバイスホスト８０１は、電子マネーの入出金や管理等を行うアプリケーション等を実行する。これに対して、例えば、UICC８０３に、電子マネーのデータ（入金（チャージ）された電子マネーの残高や入出金データ等）が記憶されるとする。デバイスホスト８０１のアプリケーションが、例えば、チャージされている電子マネーの残高確認の要求を行うと、その要求は、CLF８０２を介してUICC８０３に供給される。UICC８０３は、その要求に対して、残高情報を、CLF８０２を介してデバイスホスト８０１に供給する。

もちろん、授受されるデータ（メッセージ）の内容は任意である。デバイスホスト８０１とUICC８０３は、CLF８０２を介して例えばこのようなデータ（メッセージ）の授受を行うことができる。

CLF８０２は、アンテナ８２１、RF部８２２、制御部８２３、ゲート部８２４、およびゲート部８２５を有する。

アンテナ８２１は、アンテナ１１１と同様のアンテナであり、リーダ／ライタ（R/W）等の外部の装置に対して非接触近距離無線通信信号を送受信するためのアンテナである。アンテナ８２１として例えばループアンテナが採用される。

RF部８２２は、RF部１１２と同様の処理部であり、非接触近距離無線通信信号の送受信を行なう。例えば、RF部８２２は、制御部８２３から供給されるメッセージを非接触近距離無線通信信号として、アンテナ８２１から送信したり、外部の装置から送信される非接触近距離無線通信信号を、アンテナ８２１を介して受信し、その信号に含まれるメッセージを制御部８２３に供給したりする。

制御部８２３は、制御部１１３と基本的に同様の処理部であり、RF部８２２を制御し、非接触近距離無線通信信号の送受信を制御する。また、制御部８２３は、カードRFゲート１１４と同様のゲート部８２４を制御し、UICC８０３とのメッセージの授受を制御する。ここで、CLF８０２とUICC８０３とは、物理的にはバス８１２により接続されるが、論理的には、ETSI SCP HCI規格により規定されるロジカルインタフェースにより接続される。このHCI規格のインタフェースでは、ゲートと称するエンドポイント同士が、パイプと称する通信路により接続される。ゲート部８２４は、このHCI規格のインタフェースにおけるCLF８０２側のゲートである。ゲート部８２４は、パイプを介してUICC８０３とメッセージ等を授受する。つまり、制御部８２３は、このゲート部８２４を介してUICC８０３と通信を行う。

さらに、制御部８２３は、ゲート部８２５を制御し、デバイスホスト８０１とのメッセージの授受を制御する。ここで、CLF８０２とデバイスホスト８０１とは、物理的にはバス８１１により接続されるが、論理的には、NFC FORUM NCI規格により規定されるロジカルインタフェースにより接続される。このNCI規格のインタフェースでは、ゲートと称するエンドポイント同士が、パイプと称する通信路により接続される。ゲート部８２５は、このNCI規格のインタフェースにおけるCLF８０２側のゲートである。ゲート部８２５は、パイプを介してデバイスホスト８０１とメッセージ等を授受する。つまり、制御部８２３は、このゲート部８２５を介してデバイスホスト８０１と通信を行う。

つまり、制御部８２３は、ゲート部８２５を介して行われるデバイスホスト８０１との通信と、ゲート部８２４を介して行われるUICC８０３との通信との両方を制御する。さらに、制御部８２３は、HCI規格およびNCI規格の間で、メッセージのフォーマット変換を行うことができる。

例えば、制御部８２３は、デバイスホスト８０１から取得したNCI規格のメッセージを、フォーマット変換し、HCI規格のメッセージとしてUICC８０３に供給する。また、例えば、制御部８２３は、UICC８０３から取得したHCI規格のメッセージを、フォーマット変換し、NCI規格のメッセージとしてデバイスホスト８０１に供給する。

制御部８２３が、このような変換処理を行うことにより、デバイスホスト８０１は、容易に、既存のNCI規格のインターフェイスを用いてUICC８０３と通信を行うことができる。同様に、UICC８０３は、容易に、既存のHCI規格のインターフェイスを用いてデバイスホスト８０１と通信を行うことができる。

［制御部］
図１９は、制御部８２３の主な構成例を示す機能ブロック図である。図１９に示されるように、制御部８２３は、接続確立部８４１、受信部８４２、変換部８４３、および送信部８４４を有する。

接続確立部８４１は、デバイスホスト８０１との通信やUICC８０３との通信の接続を確立する。その際、接続確立部８４１は、例えば、図２０に示されるような、デバイスホスト８０１とのパイプ（コネクション）、UICC８０３とのパイプ（コネクション）、並びに、各通信の一度に伝送するデータ量であるバッファサイズの対応関係を示す対応表を生成し、管理する。

受信部８４２は、ゲート部８２４を制御して、UICC８０３からのHCIメッセージ受信に関する処理を行う。また、受信部８４２は、ゲート部８２５を制御して、デバイスホスト８０１からのNCIメッセージ受信に関する処理を行う。

変換部８４３は、受信部８４２の処理により受信されたNCIメッセージをHCIメッセージに変換する処理、若しくは、受信部８４２の処理により受信されたHCIメッセージをNCIメッセージに変換する処理を行う。

変換部８４３は、NCIメッセージをHCIメッセージに変換する場合、図２１に示されるように、HCPパケットのHCPメッセージデータ（Data）に、NCIメッセージのPBFとNCIメッセージデータ（NCI Data）を格納する。例えば、PBFのサイズは１バイトであり、0x10をPBF＝１とみなし、0x00をPBF＝０とみなす。

また、変換部８４３は、HCIメッセージをNCIメッセージに変換する場合、図２２に示されるように、NCIメッセージのNCIメッセージデータ（Data）に、HCPパケットのHCPメッセージデータ（HCI Data）を格納する。

HCI規格およびNCI規格においては、それぞれ、一度に送信可能なデータ長の最大値（バッファサイズ）が予め定められており、そのデータ長より長い意味のあるデータは、分割されて伝送される。また、両規格のバッファサイズが、互いに異なる場合も考えられる。

したがって、変換部８４３は、HCI規格とNCI規格との間の変換処理において、単にフォーマットを変換するだけでなく、データ長等に応じてデータを分割したり合成したりする。

変換部８４３は、サイズ判定部８５１、フラグ判定部８５２、分割部８５３、合成部８５４、および生成部８５５を有する。

サイズ判定部８５１は、NCIメッセージデータやHCPメッセージデータのデータサイズ（データ長）についての判定を行う。フラグ判定部８５２は、PBFやCB等のフラグの値を判定する。

分割部８５３は、メッセージデータの分割に関する処理を行う。合成部８５４は、複数のメッセージデータを１つに繋げる処理（メッセージデータの合成）に関する処理を行う。生成部８５５は、ヘッダ情報等、フォーマット変換の際に必要な情報を生成する。

送信部８４４は、ゲート部８２４を制御して、UICC８０３へのメッセージ送信に関する処理を行う。また、送信部８４４は、ゲート部８２５を制御して、デバイスホスト８０１へのメッセージ送信に関する処理を行う。

［変換処理の流れ］
次に、この制御部８２３により実行される、NCIフォーマットをHCIフォーマットに変換するNCI-HCI変換処理の流れの例を、図２３乃至図２５のフローチャートを参照して説明する。

制御部８２３は、デバイスホスト８０１から供給されるメッセージをUICC８０３に供給する際に、このNCI-HCI変換処理を実行する。

NCI-HCI変換処理が開始されると、ステップＳ６０１において、接続確立部８４１が、NCIの通信（デバイス８０１との通信）およびHCIの通信（UICC８０３との通信）の接続（コネクション）を確立する。このとき、接続確立部８４１は、例えば図２０に示されるような、各接続の識別情報およびバッファサイズの対応関係を示す対応表を生成し、管理する。その際、接続確立部８４１は、必要に応じて、識別情報やバッファサイズの設定も行う。以降の処理においては、この情報が利用される。

ステップ６０２において、受信部８４２は、ゲート部８２５を制御し、デバイスホスト８０２からNCIメッセージを受信する。ステップＳ６０３において、変換部８４３は、複数のNCIメッセージデータを合成して１つのHCPパケットを生成する場合も考慮し、今回受信したNCIメッセージがHCPパケットの最初のNCIメッセージデータであるか否かを判定する。

HCPパケットの最初のNCIメッセージデータであると判定した場合、受信部８４２は、処理をステップＳ６０４に進める。つまり、NCIメッセージデータを合成しない場合や、NCIメッセージデータを合成する場合の、その最初のNCIメッセージデータについては、図２３のステップＳ６０４以降の各処理、若しくは、図２４の各処理が行われる。

ステップＳ６０４において、サイズ判定部８５１は、PBFとNCIメッセージデータの合計データサイズがHCIバッファサイズ（HCI規格のコネクションにおいて一度に伝送可能なデータ長の最大値）より大きいか否かを判定する。例えば、HCI Transport layerがSWP（Single Wire Protocol）の場合、HCIバッファサイズ（SWP buffer size）は３０バイトである。

PBFとNCIメッセージデータの合計データサイズがHCIバッファサイズより大きい場合、NCIメッセージデータをHCIバッファサイズ毎に分割する必要がある。PBFとNCIメッセージデータの合計データサイズがHCIバッファサイズより大きいと判定された場合、サイズ判定部８５１は、処理をステップＳ６０５に進める。

ステップＳ６０５において、生成部８５５は、図３に示されるheaderのようなHCPメッセージヘッダ（図４のmessage header）を生成し、PBFとNCIメッセージデータに付加する。

ステップＳ６０６において、分割部８５３は、PBFとNCIメッセージデータを、HCPメッセージデータ（図４のdata）とし、HCPメッセージ（HCPメッセージヘッダおよびHCPメッセージデータ）をHCIバッファサイズ毎に分割する。以下において、分割された各HCPメッセージを分割HCPメッセージとも称する。

ステップＳ６０７において、生成部８５５は、図２に示されるheaderのようなHCPパケットヘッダ（図４のpacket header）を生成し、各分割HCPメッセージに付加する。また、生成部８５５は、ステップＳ６０８において、HCPメッセージの最後（最後の分割HCPメッセージ）を含むHCPパケット（HCPパケットヘッダが付加された分割HCPメッセージ）のCBを、CB＝１とし、それ以外のHCPパケットのCBをCB＝０とする。CB＝１は、その分割HCPメッセージに続く他の分割HCPメッセージが存在することを示す。CB＝０は、その分割HCPメッセージに続く他の分割HCPメッセージが存在しないこと、すなわち、HCPメッセージの最後を示す。

ステップＳ６０９において、送信部８４４は、各HCPパケットを所定順（例えば、分割HCPメッセージの並び順）に、ゲート部８２４を介してUICC８０３に送信する。

PBFおよびNCIメッセージデータの合計のデータサイズがHCIバッファサイズより大きい場合、このようにNCIメッセージデータは、このように複数に分割されて送信される。

ステップＳ６１０において、制御部８２３は、NCI-HCI変換処理を終了するか否かを判定する。まだデバイスホスト８０１からのNCIメッセージ群の受信が終了しておらず、NCI-HCI変換処理を終了しないと判定した場合、処理対象を次のNCIメッセージに更新し、処理をステップＳ６０２に戻す。

また、ステップＳ６１０において、全てのNCIメッセージの変換が終了し、NCI-HCI変換処理を終了すると判定された場合、制御部８２３は、NCI-HCI変換処理を終了する。

また、ステップＳ６０４において、PBFおよびNCIメッセージデータの合計のデータサイズがHCIバッファサイズより大きくないと判定された場合、サイズ判定部８５１は、処理を図２４のステップＳ６２１に進める。

図２４のステップＳ６２１において、サイズ判定部８５１は、PBFおよびNCIメッセージデータの合計のデータサイズがHCIバッファサイズと一致するか否かを判定する。一致すると判定された場合、複数のNCIメッセージデータを合成する必要が無いので、サイズ判定部８５１は、処理をステップＳ６２２に進め、図２４のステップＳ６２２乃至ステップＳ６２５の処理を実行させる。

つまり、ステップＳ６２２において、生成部８５５は、PBFおよびNCIメッセージデータをHCPメッセージデータとし、HCPメッセージヘッダを生成して付加することによりHCPメッセージを生成する。さらに、ステップＳ６２３において、生成部８５５は、そのHCPメッセージにHCPパケットヘッダを生成して付加することによりHCPパケットを生成する。つまり、この場合、HCPパケットには、１つのNCIメッセージデータが格納される。

したがって、後続の分割データは存在しないので、生成部８５５は、ステップＳ６２４において、そのHCPパケットのCBをCB＝１に設定する。ステップＳ６２５において、送信部８４４は、そのHCPパケットを、ゲート部８２４を介してUICC８０３に送信する。

HCPパケットが送信されると、制御部８２３は、処理を図２３のステップＳ６１０に戻し、それ以降の処理を繰り返す。

また、図２４のステップＳ６２１において、PBFおよびNCIメッセージデータの合計のデータサイズがHCIバッファサイズと一致しないと判定された場合、サイズ判定部８５１は、処理をステップＳ６２６に進める。この場合、PBFおよびNCIメッセージデータの合計のデータサイズがHCIバッファサイズより小さいことになる。

制御部８２３は、NCIメッセージデータとして供給された意味のあるデータをできるだけ少ないHCPパケットでUICC８０３に供給させる。つまり、制御部８２３は、１つの意味のあるデータが分割された複数のNCIメッセージデータを、HCIバッファサイズを超えない範囲で合成する（つなぎ合わせる）。

例えば、１つの意味のあるデータがデバイスホスト８０１により分割されて、それぞれがHCIバッファサイズよりも小さな複数のNCIメッセージデータとして送信された場合、制御部３２３は、それらのNCIメッセージデータを、HCIバッファサイズを超えない範囲で合成する（つなぎ合わせる）。

このようにすることにより、制御部８２３は、HCPパケット数を低減させることができ、不要にバス８１２の帯域を消費することを抑制し、効率よくメッセージをUICC８０３に供給することができる。

なお、複数の意味のあるデータを１つのHCPパケットに含めるようにしてもよいが、UICC８０３がそのメッセージを意味のあるデータ毎に分割する必要が生じるので、制御部８２３は、どこでメッセージを分割すべきか（意味のあるデータの切れ目）を示す必要がある。

ステップＳ６２６において、変換部８４３は、PBFおよびNCIメッセージデータをHCPメッセージデータとして保持する。ステップＳ６２６の処理が終了すると、制御部８２３は、処理を図２３のステップＳ６１０に戻し、それ以降の処理を繰り返す。

つまり、次のNCIメッセージデータが存在する場合、そのNCIメッセージデータを合成するか否かを判定する必要があるので、制御部８２３は、今回受信したNCIメッセージデータを送信せずに、次のNCIメッセージデータの受信を行う。

図２３のステップＳ６０３において、HCPパケットの最初のNCIメッセージデータでは無いと判定された場合、制御部８２３は、処理を図２５のステップＳ６３１に進める。つまり、未送信のHCPメッセージデータ（少なくとも前回受信したNCIメッセージデータを含むHCPメッセージデータ）が存在すると判定された場合、制御部８２３は、図２５の各処理を実行し、HCPメッセージデータがHCIバッファサイズを超えるか、若しくは、意味のあるデータの最後を含むNCIメッセージデータを受信するまで、NCIメッセージデータを合成する。

ステップＳ６３１において、サイズ判定部８５１は、PBFおよび今回までのNCIメッセージデータの和の合計サイズがHCIバッファサイズより小さいか否かを判定する。PBFおよび今回までのNCIメッセージデータの和の合計サイズがHCIバッファサイズより小さいと判定された場合、サイズ判定部８５１は、処理をステップＳ６３２に進める。

ステップＳ６３２において、合成部８５４は、今回のNCIメッセージデータを、制御部８２３が保持しているHCPメッセージデータに追加する。ステップＳ６３３において、フラグ判定部８５２は、今回受信したNCIメッセージのPBFがPBF＝０であるか否かを判定する。PBF＝０である、すなわち、今回取得したNCIメッセージデータが意味のあるデータの最後を含む（後続のNCIメッセージデータが存在しない）と判定された場合、フラグ判定部８５２は、処理をステップＳ６３４に進める。

ステップＳ６３４において、生成部８５５は、HCPメッセージヘッダを生成し、制御部８２３が保持しているHCPメッセージデータに付加する。なお、このとき、生成部８５５は、HCPメッセージデータのPBFをPBF＝０に設定する。さらに、生成部８５５は、ステップＳ６３５において、HCPパケットヘッダを生成し、ステップＳ６３４において生成したHCPメッセージに付加する。

このように生成されたHCPパケットに含まれるNCIメッセージデータに後続するNCIメッセージデータは存在しないので、ステップＳ６３６において、生成部８５５は、そのHCPパケットのCBをCB＝１とする。ステップＳ６３７において、送信部８４４は、このように生成されたHCPパケットを、ゲート部８２４を介してUICC８０３に送信する。送信部８４４は、HCPパケットを送信すると、処理を図２３のステップＳ６１０に戻し、それ以降の処理を繰り返す。

また、図２５のステップＳ６３３において、PBF＝１である、すなわち、今回取得したNCIメッセージデータが意味のあるデータの最後を含まない（後続のNCIメッセージデータが存在する）と判定された場合、フラグ判定部８５２は、HCPメッセージデータを送信させずに、処理を図２３のステップＳ６０２に進める。つまり、NCIメッセージデータの合成を継続する。

また、図２５のステップＳ６３１において、PBFおよび今回までのNCIメッセージデータの和の合計サイズが、HCIバッファサイズ以上であると判定された場合、サイズ判定部８５１は、処理をステップＳ６３８に進める。ステップＳ６３８において、サイズ判定部８５１は、PBFおよび今回までのNCIメッセージデータの和がHCIバッファサイズと一致するか否かを判定する。一致すると判定された場合、サイズ判定部８５１は、処理をステップＳ６３９に進める。

ステップＳ６３９において、合成部８５４は、今回のNCIメッセージデータをHCPメッセージデータに追加する。ステップＳ６４０において、生成部８５５は、HCPメッセージヘッダを生成し、HCPメッセージデータに付加する。ステップＳ６４１において、生成部８５５は、HCPパケットヘッダを生成し、ステップＳ６４０において生成されたHCPメッセージに付加することにより、HCPパケットを生成する。

ステップＳ６４２において、フラグ判定部８５２は、今回受信したNCIメッセージのPBFがPBF＝０であるか否かを判定する。PBF＝０であると判定された場合、生成部８５５は、処理をステップＳ６４３に進め、HCPパケットのCBをCB＝１に設定し、処理をステップＳ６４５に進める。また、ステップＳ６４２においてPBF＝１であると判定された場合、生成部８５５は、処理をステップＳ６４４に進め、HCPパケットのCBをCB＝０に設定し、処理をステップＳ６４５に進める。

ステップＳ６４５において、送信部８４４は、ゲート部８２４を介してUICC８０３に送信する。送信部８４４は、HCPパケットを送信すると、処理を図２３のステップＳ６１０に戻し、それ以降の処理を繰り返す。

さらに、図２５のステップＳ６３８において、PBFおよび今回までのNCIメッセージデータの和がHCIバッファサイズと一致しないと判定された場合、すなわち、PBFおよび今回までのNCIメッセージデータの和がHCIバッファサイズより大きいと判定された場合、サイズ判定部８５１は、処理をステップＳ６４６に進める。

この場合、今回受信したNCIメッセージデータをHCPメッセージデータに追加することができないので、制御部８２３は、前回までのNCIメッセージデータをHCPメッセージデータとして送信させる。

すなわち、ステップＳ６４６において、生成部８５５は、今回受信したNCIメッセージデータをHCPメッセージデータに追加させずに、HCPメッセージヘッダを生成し、HCPメッセージデータに付加する。ステップＳ６４７において、生成部８５５は、HCPパケットヘッダを生成し、ステップＳ６４６において生成されたHCPメッセージに付加する。この場合、今回受信したNCIメッセージデータの後続のNCIメッセージデータが存在するので、生成部８５５は、さらに、ステップＳ６４８において、ステップＳ６４７において生成されたHCPパケットのCBをCB＝０とする。

ステップＳ６４９において、送信部８４４は、ゲート部８２４を介してUICC８０３に送信する。送信部８４４は、HCPパケットを送信すると、処理を図２３のステップＳ６１０に戻し、それ以降の処理を繰り返す。

以上のように各処理を行うことにより、制御部８２３は、NCIフォーマットからHCIフォーマットの変換を、NCIメッセージデータを受信する度に行うことができ、例えば、意味のあるデータを全て受信してから、フォーマット変換して送信するよりも、容易かつ高速に行うことができる。

これにより、デバイスホスト８０１およびUICC８０３は、既存のNCIインターフェイスおよびHCIインターフェイスを用いて容易にメッセージの授受を行うことができる。

［HCPメッセージ受信処理の流れ］
このようにCLF８０２によりフォーマット変換されて供給されるメッセージを受信するHCPメッセージ受信処理の流れの例を、図２６のフローチャートを参照して説明する。

UICC８０３は、CLF８０２から送信されるHCPパケットを受信するために、HCPメッセージ受信処理を実行する。

ステップＳ６６１において、UICC８０３は、HCPパケットを受信する。ステップＳ６６２において、UICC８０３は、受信したHCPパケットのCBがCB＝１であるか否かを判定する。CB＝１であると判定された場合、UICC８０３は、処理をステップＳ６６３に進める。

この場合、後続のHCPメッセージデータは存在しないので、ステップＳ６６３において、UICC８０３は、今回受信したHCPパケットに含まれるHCPメッセージデータを抽出する。例えば、分割HCPメッセージを保持している場合、UICC８０３は、今回受信したHCPパケットに含まれる分割HCPメッセージを抽出し、それを、保持している分割HCPメッセージと合成し、HCPメッセージデータを抽出する。

ステップＳ６６４において、UICC８０３は、ステップＳ６６３において生成されたHCPメッセージデータのPBFがPBF＝０であるか否かを判定する。PBF＝０であると判定された場合、UICC８０３は、処理をステップＳ６６５に進め、HCPメッセージデータから、意味のあるデータ毎のNCIメッセージデータである有意NCIメッセージデータを生成する。例えば、保持しているNCIメッセージデータが存在する場合、すなわち、有意NCIメッセージデータが複数のNCIメッセージデータに分割されている場合、UICC803は、その複数のNCIメッセージデータを合成し、有意NCIメッセージデータを生成する。

有意NCIメッセージデータを生成するとUICC８０３は、HCPメッセージ受信処理を終了する。

また、ステップＳ６６４において、PBF＝１であると判定された場合、UICC８０３は、処理をステップＳ６６６に進め、NCIメッセージデータを保持し、HCPメッセージ受信処理を終了する。

さらに、ステップＳ６６２において、CB＝０であると判定された場合、UICC８０３は、処理をステップＳ６６７に進め、今回受信した分割HCPメッセージを保持し、HCPメッセージ受信処理を終了する。

HCPメッセージ受信処理は、各HCPパケットを受信するために、繰り返し実行される。

このようにすることにより、UICC８０２は、CLF８０２を介して、デバイスホスト８０１から送信されるメッセージを、外部の装置との非接触近距離無線通信の場合と同様に、HCIインターフェイスにより受信することができる。

［分割の例］
例えば、NCIメッセージデータがHCIバッファサイズ（例えばSWPバッファサイズ）より大きい場合、メッセージは、図２７のフローチャートに示されるように伝送される。

つまり、ステップＳ７１１、ステップＳ７２１、およびステップＳ７３１において、接続が確立されると、ステップＳ７１２において送信されたNCIメッセージデータ（data 1a）は、ステップＳ７２２においてCLF８０２に受信され、変換されて、例えば、ステップＳ７２３乃至ステップＳ７２５のように複数のHCPパケット（data 1a-1乃至data 1a-m）に分割されてUICC８０３に伝送される。UICC８０３は、それらのHCPパケットを、ステップＳ７３２乃至ステップＳ７３４のように受信し、それらを合成してNCIメッセージデータ（data 1a）を生成する。

同様に、ステップＳ７１３において送信されたNCIメッセージデータ（data 1b）は、ステップＳ７２６においてCLF８０２に受信され、変換されて、例えば、ステップＳ７２７乃至ステップＳ７２９のように複数のHCPパケット（data 1b-1乃至data 1b-n）に分割されてUICC８０３に伝送される。UICC８０３は、それらのHCPパケットを、ステップＳ７３５乃至ステップＳ７３７のように受信し、それらを合成してNCIメッセージデータ（data 1b）を生成する。

UICC８０３は、NCIメッセージデータ（data 1a）とNCIメッセージデータ（data 1b）とを合成し、意味のあるデータ（data 1）を生成する。

data 1a = data 1a-1 ＋ data 1a-2 ＋ … ＋ data 1a-m
data 1b = data 1b-1 ＋ data 1b-2 ＋ … ＋ data 1b-n
意味のあるデータdata 1 = data 1a ＋ data 1b

［一致の例］
例えば、NCIメッセージデータがHCIバッファサイズ（例えばSWPバッファサイズ）に一致する場合、メッセージは、図２８のフローチャートに示されるように伝送される。つまり、１つのNCIメッセージが１つのHCPパケットに変換されて伝送される。

つまり、ステップＳ７４１、ステップＳ７５１、およびステップＳ７６１において、接続が確立されると、ステップＳ７４２において送信されたNCIメッセージデータ（data 1a）は、ステップＳ７５２においてCLF８０２に受信され、変換されて、ステップＳ７５３において、HCPパケットとして、UICC８０３に伝送される。UICC８０３は、そのHCPパケットを、ステップＳ７６２において受信する。

また、ステップＳ７４３において送信されたNCIメッセージデータ（data 1b）は、ステップＳ７５４においてCLF８０２に受信され、変換されて、ステップＳ７５５において、HCPパケットとして、UICC８０３に伝送される。UICC８０３は、そのHCPパケットを、ステップＳ７６３において受信する。

UICC８０３は、NCIメッセージデータ（data 1a）とNCIメッセージデータ（data 1b）とを合成し、意味のあるデータ（data 1）を生成する。

意味のあるデータdata 1 = data 1a ＋ data 1b

［合成の例］
例えば、NCIメッセージデータがHCIバッファサイズ（例えばSWPバッファサイズ）より小さい場合、メッセージは、図２９のフローチャートに示されるように伝送される。

つまり、ステップＳ７７１、ステップＳ７８１、およびステップＳ７９１において、接続が確立されると、ステップＳ７７２乃至ステップＳ７７４のように複数のNCIメッセージデータ（data 1a乃至data 1x）がデバイスホスト８０１から送信され、それらが、ステップＳ７８２乃至ステップＳ７８４のようにCLF８０２に受信される。それらのデータは、CLF８０２において変換されて、１つのHCPパケット（data 1）にまとめられ、ステップＳ７８５において、UICC８０３に伝送される。UICC８０３は、そのHCPパケットを、ステップＳ７９２において受信する。

意味のあるデータdata 1 = data 1a ＋ data 1b

なお、図２９においては、意味のあるデータdata １のデータサイズがHCIバッファサイズ（例えばSWP buffer size）より小さい場合を例に説明したが、例えば、意味のあるデータdata 1のデータサイズがHCIバッファサイズより大きい場合、意味のあるデータdata １は、複数のHCPパケットとしてUICC８０３に送信される。この場合、CLF８０２は、HCIバッファサイズを超えるまでNCIメッセージデータを合成してから送信するようにしてもよいし、合成せずに１つのNCIメッセージデータを１HCPパケットとして送信するようにしてもよい。また、例えば、NCIメッセージデータを、各分割NCIメッセージデータのサイズがHCIバッファサイズを超えないように等分するようにしてもよい。さらに、その他の分割方法であってもよい。

また、このような合成や送信は、NCIメッセージデータを受信する毎に行うようにしてもよいし、意味のあるデータを全て受信してから行うようにしてもよい。さらに、その他のタイミングに行われるようにしてもよい。

以上のように、CLF２０８は、多様な場合において、NCIフォーマットをHCIフォーマットに適切に変換することができる。これにより、UICC８０３は、メッセージの分割や合成が必要な場合であっても、既存のHCIインターフェイスを用いて、外部の装置と非接触近距離無線通信を行う場合と同様に、容易にデバイスホスト８０２からメッセージ受信することができる。

［変換処理の流れ］
次に、制御部８２３により実行される、HCIフォーマットをNCIフォーマットに変換するHCI-NCI変換処理の流れの例を、図３０乃至図３２のフローチャートを参照して説明する。

制御部８２３は、UICC８０３から供給されるメッセージをデバイスホスト８０１に供給する際に、このHCI-NCI変換処理を実行する。

HCI-NCI変換処理が開始されると、ステップＳ８０１において、接続確立部８４１が、NCIの通信（デバイス８０１との通信）およびHCIの通信（UICC８０３との通信）の接続（コネクション）を確立する。このとき、接続確立部８４１は、例えば図２０に示されるような、各接続の識別情報およびバッファサイズの対応関係を示す対応表を生成し、管理する。その際、接続確立部８４１は、必要に応じて、識別情報やバッファサイズの設定も行う。以降の処理においては、この情報が利用される。

ステップ８０２において、受信部８４２は、ゲート部８２４を制御し、UICC８０３からHCPパケットを受信する。ステップＳ８０３において、変換部８４３は、複数のHCPパケットを合成して１つのNCIメッセージを生成する場合も考慮し、今回受信したHCPパケットがNCIメッセージデータの最初のHCPパケットであるか否かを判定する。

NCIメッセージデータの最初のHCPパケットであると判定した場合、受信部８４２は、処理をステップＳ８０４に進める。つまり、HCPパケットを合成しない場合や、HCPパケットを合成する場合の、その最初のHCPパケットについては、図３０のステップＳ８０４以降の各処理、若しくは、図３１の各処理が行われる。

ステップＳ８０４において、サイズ判定部８５１は、HCPメッセージデータのデータサイズがNCIバッファサイズ（NCI規格のコネクションにおいて一度に伝送可能なデータ長の最大値）より大きいか否かを判定する。

HCPメッセージデータのサイズがNCIバッファサイズより大きい場合、HCPメッセージデータをNCIバッファサイズ毎に分割する必要がある。HCPメッセージデータのサイズがNCIバッファサイズより大きいと判定された場合、サイズ判定部８５１は、処理をステップＳ８０５に進める。

ステップＳ８０５において、分割部８５３は、HCPメッセージデータを、NCIメッセージデータとし、そのNCIメッセージデータをNCIバッファサイズ毎に分割する。以下において、分割された各NCIメッセージを分割NCIメッセージとも称する。

ステップＳ８０６において、生成部８５５は、NCIメッセージヘッダを生成し、各分割NCIメッセージデータに付加する。ステップＳ８０７において、フラグ判定部８５２は、受信したHCPパケットのCBがCB＝１であるか否かを判定する。

CB＝１であると判定された場合、フラグ判定部８５２は、処理をステップＳ８０８に進める。この場合、同じ意味あるデータから分割された後続のHCPパケットは存在しない。したがって、ステップＳ８０８において、生成部８５５は、分割NCIメッセージデータのうち、NCIメッセージデータの最後を含むNCIメッセージのPBFをPBF＝０とし、それ以外のNCIメッセージのPBFをPBF＝１とする。ステップＳ８０８の処理が終了すると、生成部８５５は、処理をステップＳ８１０に進める。

また、ステップＳ８０７において、CB＝０と判定された場合、フラグ判定部８５２は、処理をステップＳ８０９に進める。この場合、同じ意味あるデータから分割された後続のHCPパケットが存在する。したがって、ステップＳ８０９において、生成部８５５は、全てのNCIメッセージのPBFをPBF＝１とする。ステップＳ８０９の処理が終了すると、生成部８５５は、処理をステップＳ８１０に進める。

ステップＳ８１０において、送信部８４４は、各NCIメッセージを所定順（例えば、分割NCIメッセージの並び順）に、ゲート部８２５を介してデバイスホスト８０１に送信する。

HCPメッセージデータのサイズがNCIバッファサイズより大きい場合、このようにHCPメッセージデータは、複数に分割されて送信される。

ステップＳ８１１において、制御部８２３は、HCI-NCI変換処理を終了するか否かを判定する。まだUICC８０３からのHCIパケット群の受信が終了しておらず、HCI-NCI変換処理を終了しないと判定した場合、処理対象を次のHCPパケットに更新し、処理をステップＳ８０２に戻す。

また、ステップＳ８１１において、全てのHCPパケットの変換が終了し、HCI-NCI変換処理を終了すると判定された場合、制御部８２３は、HCI-NCI変換処理を終了する。

また、ステップＳ８０４において、HCPメッセージデータのサイズがNCIバッファサイズより大きくないと判定された場合、サイズ判定部８５１は、処理を図３１のステップＳ８２１に進める。

図３１のステップＳ８２１において、サイズ判定部８５１は、HCPメッセージデータのサイズがNCIバッファサイズと一致するか否かを判定する。一致すると判定された場合、複数のHCPメッセージデータを合成する必要が無いので、サイズ判定部８５１は、処理をステップＳ８２２に進め、図３１のステップＳ８２２乃至ステップＳ８２６の処理を実行させる。

つまり、ステップＳ８２２において、生成部８５５は、HCPメッセージデータをNCIメッセージデータとし、NCIメッセージヘッダを生成して付加することによりNCIメッセージを生成する。

ステップＳ８２３において、フラグ判定部８５２は、今回受信されたHCPメッセージデータのCBがCB＝０であるか否かを判定する。CB＝０であり、後続のHCPメッセージデータが存在すると判定された場合、生成部８５５は、ステップＳ８２４において、ステップＳ８２２において生成したNCIメッセージのPBFをPBF＝１に設定し、処理をステップＳ８２６に進める。

また、ステップＳ８２３において、CB＝１であり、後続のHCPメッセージデータが存在しないと判定された場合、生成部８５５は、ステップＳ８２５において、ステップＳ８２２において生成したNCIメッセージのPBFをPBF＝０に設定し、処理をステップＳ８２６に進める。

ステップＳ８２６において、送信部８４４は、そのNCIメッセージを、ゲート部８２５を介してデバイスホスト８０１に送信する。

NCIメッセージが送信されると、制御部８２３は、処理を図３０のステップＳ８１１に戻し、それ以降の処理を繰り返す。

また、図３１のステップＳ８２１において、HCPメッセージデータの合計のデータサイズがNCIバッファサイズと一致しないと判定された場合、サイズ判定部８５１は、処理をステップＳ８２７に進める。この場合、HCPメッセージデータのサイズがNCIバッファサイズより小さいことになる。

制御部８２３は、HCPパケットとして供給された意味のあるデータをできるだけ少ないNCIメッセージでデバイスホスト８０１に送信する。つまり、制御部８２３は、１つの意味のあるデータが分割された複数のHCPメッセージデータを、NCIバッファサイズを超えない範囲で合成する（つなぎ合わせる）。

例えば、１つの意味のあるデータがUICC８０３により分割されて、それぞれがNCIバッファサイズよりも小さな複数のHCPメッセージデータとして送信された場合、制御部３２３は、それらのHCPメッセージデータを、NCIバッファサイズを超えない範囲で合成する（つなぎ合わせる）。

このようにすることにより、制御部８２３は、NCIメッセージ数を低減させることができ、不要にバス８１１の帯域を消費することを抑制し、効率よくメッセージをデバイスホスト８０１に供給することができる。

なお、複数の意味のあるデータを１つのNCIメッセージに含めるようにしてもよいが、デバイスホスト８０１がそのメッセージを意味のあるデータ毎に分割する必要が生じるので、制御部８２３は、どこでメッセージを分割すべきか（意味のあるデータの切れ目）を示す必要がある。

ステップＳ８２７において、変換部８４３は、HCPメッセージデータをNCIメッセージデータとして保持する。ステップＳ８２８において、フラグ判定部８５２は、HCPメッセージデータのCBがCB＝０であるか否かを判定する。CB＝０であり、後続のHCPメッセージが存在すると判定された場合、制御部８２３は、処理を図３０のステップＳ８０２に戻し、それ以降の処理を繰り返す。

つまり、次のHCPメッセージデータが存在する場合、そのHCPメッセージデータを合成するか否かを判定する必要があるので、制御部８２３は、今回受信したHCPメッセージデータを送信せずに、次のHCPメッセージデータの受信を行う。

また、図３１のステップＳ８２８において、CB＝１であり、後続のHCPメッセージが存在しないと判定された場合、生成部８５５は、ステップＳ８２９に処理を進め、NCIメッセージヘッダをNCIメッセージデータに付加し、NCIメッセージを生成する。ステップＳ８３０において、生成部８５５は、そのNCIメッセージのPBFをPBF＝０に設定する。ステップＳ８３１において、送信部８４４は、そのNCIメッセージを、ゲート部８２５を介してデバイスホスト８０１に送信する。

NCIメッセージが送信されると、制御部８２３は、処理を図３０のステップＳ８１１に戻し、それ以降の処理を繰り返す。

図３０のステップＳ８０３において、NCIメッセージの最初のHCPパケットでは無いと判定された場合、制御部８２３は、処理を図３２のステップＳ８４１に進める。つまり、未送信のNCIメッセージデータ（少なくとも前回受信したHCPメッセージデータを含むNCIメッセージデータ）が存在すると判定された場合、制御部８２３は、図３２の各処理を実行し、NCIメッセージデータがNCIバッファサイズを超えるか、若しくは、意味のあるデータの最後を含むHCPメッセージデータを受信するまで、HCPメッセージデータを合成する。

ステップＳ８４１において、サイズ判定部８５１は、今回までのHCPメッセージデータの和の合計サイズがNCIバッファサイズより小さいか否かを判定する。今回までのHCPメッセージデータの和の合計サイズがNCIバッファサイズより小さいと判定された場合、サイズ判定部８５１は、処理をステップＳ８４２に進める。

ステップＳ８４２において、合成部８５４は、今回のHCPメッセージデータを、制御部８２３が保持しているNCIメッセージデータに追加する。ステップＳ８４３において、フラグ判定部８５２は、今回受信したHCPメッセージのCBがCB＝０であるか否かを判定する。CB＝０である、すなわち、今回取得したHCPメッセージデータが意味のあるデータの最後を含まない（後続のNCIメッセージデータが存在する）と判定された場合、フラグ判定部８５２は、処理を図３０のステップＳ８０２に戻し、それ以降の処理を繰り返す。

また、図３２のステップＳ８４３において、CB＝１、すなわち、今回取得したHCPメッセージデータが意味のあるデータの最後を含む（後続のNCIメッセージデータが存在しない）と判定された場合、生成部８５５は、NCIメッセージヘッダを生成し、制御部８２３が保持しているNCIメッセージデータに付加し、NCIメッセージを生成する。ステップＳ８４５において、生成部８５５は、そのNCIメッセージのPBFをPBF＝０に設定する。

ステップＳ８４６において、送信部８４４は、このように生成されたNCIメッセージを、ゲート部８２５を介してデバイスホスト８０１に送信する。送信部８４４は、NCIメッセージを送信すると、処理を図３０のステップＳ８１１に戻し、それ以降の処理を繰り返す。

また、図３２のステップＳ８４１において、今回までのHCPメッセージデータの合計サイズが、NCIバッファサイズ以上であると判定された場合、サイズ判定部８５１は、処理をステップＳ８４７に進める。ステップＳ８４７において、サイズ判定部８５１は、今回までのHCPメッセージデータの和のサイズがNCIバッファサイズと一致するか否かを判定する。一致すると判定された場合、サイズ判定部８５１は、処理をステップＳ８４８に進める。

ステップＳ８４８において、合成部８５４は、今回のHCPメッセージデータを制御部８２３が保持しているNCIメッセージデータに追加する。ステップＳ８４９において、生成部８５５は、NCIメッセージヘッダを生成し、NCIメッセージデータに付加し、NCIメッセージを生成する。

ステップＳ８５０において、フラグ判定部８５２は、今回受信したHCPパケットのCBがCB＝０であるか否かを判定する。CB＝０であると判定された場合、すなわち、後続のHCPメッセージデータが存在すると判定された場合、生成部８５５は、処理をステップＳ８５１に進め、ステップＳ８４８において生成したNCIメッセージのPBFをPBF＝１に設定し、処理をステップＳ８５３に進める。

また、ステップＳ８５０においてCB＝１であると判定された場合、すなわち、後続のHCPメッセージデータが存在しないと判定された場合、生成部８５５は、処理をステップＳ８５２に進め、ステップＳ８４８において生成したNCIメッセージのPBFをPBF＝０に設定し、処理をステップＳ８５３に進める。

ステップＳ８５３において、送信部８４４は、以上のように生成されたNCIメッセージを、ゲート部８２５を介してデバイスホスト８０１に送信する。送信部８４４は、NCIメッセージを送信すると、処理を図３０のステップＳ８１１に戻し、それ以降の処理を繰り返す。

さらに、図３２のステップＳ８４７において、今回までのHCPメッセージデータの和のデータサイズがNCIバッファサイズと一致しないと判定された場合、すなわち、今回までのHCPメッセージデータの和のデータサイズがNCIバッファサイズより大きいと判定された場合、サイズ判定部８５１は、処理をステップＳ８５４に進める。

この場合、今回受信したHCPメッセージデータをNCIメッセージデータに追加することができないので、制御部８２３は、前回までのHCPメッセージデータをNCIメッセージデータとして送信させる。

すなわち、ステップＳ８５４において、生成部８５５は、今回受信したHCPメッセージデータをNCIメッセージデータに追加させずに、NCIメッセージヘッダを生成し、NCIメッセージデータに付加する。ステップＳ８５５において、生成部８５５は、そのNCIメッセージのPBFを、PBF＝１とする。

ステップＳ８５６において、送信部８４４は、ゲート部８２５を介してデバイスホスト８０１に送信する。送信部８４４は、NCIメッセージを送信すると、処理を図３０のステップＳ８１１に戻し、それ以降の処理を繰り返す。

以上のように各処理を行うことにより、制御部８２３は、HCIフォーマットからNCIフォーマットの変換を、HCIメッセージデータを受信する度に行うことができ、例えば、意味のあるデータを全て受信してから、フォーマット変換して送信するよりも、容易かつ高速に行うことができる。

これにより、デバイスホスト８０１およびUICC８０３は、既存のHCIインターフェイスおよびNCIインターフェイスを用いて容易にメッセージの授受を行うことができる。

［NCIメッセージ受信処理の流れ］
このようにCLF８０２によりフォーマット変換されて供給されるメッセージを受信するNCIメッセージ受信処理の流れの例を、図３３のフローチャートを参照して説明する。

デバイスホスト８０１は、CLF８０２から送信されるNCIメッセージを受信するために、NCIメッセージ受信処理を実行する。

ステップＳ８７１において、デバイスホスト８０１は、NCIメッセージを受信する。ステップＳ８７２において、デバイスホスト８０１は、受信したNCIメッセージのPBFがPBF＝０であるか否かを判定する。PBF＝０であると判定された場合、デバイスホスト８０１は、処理をステップＳ８７３に進める。

この場合、後続のNCIメッセージデータは存在しないので、ステップＳ８７３において、デバイスホスト８０１は、今回受信したNCIメッセージに含まれるHCPメッセージデータを抽出し、例えば、保持している他のHCP分割HCPメッセージデータと適宜合成し、意味のあるHCPメッセージデータである有意HCPメッセージデータを生成する。

また、ステップＳ８７２において、PBF＝１であると判定された場合、デバイスホスト８０１は、処理をステップＳ８７４に進める。ステップＳ８７４において、デバイスホスト８０１は、NCIメッセージから抽出されたHCPメッセージデータ保持する。

ステップＳ８７３若しくはステップＳ８７４の処理が終了すると、デバイスホスト８０１は、NCIメッセージ受信処理を終了する。

NCIメッセージ受信処理は、各NCIメッセージを受信するために、繰り返し実行される。

このようにすることにより、デバイスホスト８０１は、CLF８０２を介して、UICC８０３から送信されるメッセージを、既存のNCIインターフェイスにより受信することができる。つまり、UICC８０３は、CLF８０２を介して、デバイスホスト８０１に送信するメッセージを、外部の装置との非接触近距離無線通信の場合と同様に、HCIインターフェイスにより送信することができる。

［分割の例］
例えば、HCPメッセージデータがNCIバッファサイズより大きい場合、メッセージは、図３４のフローチャートに示されるように伝送される。

つまり、ステップＳ９１１、ステップＳ９２１、およびステップＳ９３１において、接続が確立されると、ステップＳ９３２においてUICC８０３から送信されたHCPパケット（data 1）は、ステップＳ９２２においてCLF８０２に受信され、変換されて、例えば、ステップＳ９２３乃至ステップＳ９２５のように複数のNCIメッセージ（data 1-1乃至data 1-ｎ）に分割されてホストデバイス８０１に伝送される。ホストデバイス８０１は、それらのNCIメッセージを、ステップＳ９１２乃至ステップＳ９１４のように受信し、それらを合成してHCPメッセージデータ（data 1）を生成する。

意味のあるデータdata 1 = data 1-1 ＋ data 1-2 ＋ … ＋ data 1-n

［一致の例］
例えば、HCPメッセージデータがNCIバッファサイズに一致する場合、メッセージは、図３５のフローチャートに示されるように伝送される。つまり、１つのHCPパケットが１つのNCIメッセージに変換されて伝送される。

つまり、ステップＳ９４１、ステップＳ９５１、およびステップＳ９６１において、接続が確立されると、ステップＳ９６２においてUICC８０３から送信されたHCPパケット（data 1）は、ステップＳ９５２においてCLF８０２により受信され、変換されて、ステップＳ９５３において、NCIメッセージ（data 1）として、デバイスホスト８０１に伝送される。デバイスホスト８０１は、そのNCIメッセージを、ステップＳ９４２において受信する。

また、同様に、ステップＳ９６３においてUICC８０３から送信されたHCPパケット（data 2）は、ステップＳ９５４においてCLF８０２により受信され、変換されて、ステップＳ９５５において、NCIメッセージ（data 2）として、デバイスホスト８０１に伝送される。デバイスホスト８０１は、そのNCIメッセージを、ステップＳ９４３において受信する。

この場合、NCIメッセージ（data 1）およびNCIメッセージ（data 2）は、ともに意味のあるデータである。

［合成の例］
例えば、HCPメッセージデータがNCIバッファサイズより小さい場合、メッセージは、図３６のフローチャートに示されるように伝送される。

つまり、ステップＳ９７１、ステップＳ９８１、およびステップＳ９９１において、接続が確立されると、ステップＳ９９２乃至ステップＳ９９４のように複数のHCPパケット（data 1-1乃至data 1-m）がUICC８０３から送信され、それらが、ステップＳ９８２乃至ステップＳ９８４のようにCLF８０２に受信される。それらのデータは、CLF８０２において変換されて、１つのNCIメッセージ（data 1）にまとめられ、ステップＳ９８５において、デバイスホスト８０１に伝送される。デバイスホスト８０１は、そのNCIメッセージを、ステップＳ９７２において受信する。

意味のあるデータdata 1 = data 1-1 ＋ data 1-2 ＋ … ＋ data 1-m

なお、図３６においては、意味のあるデータdata １のデータサイズがNCIバッファサイズより小さい場合を例に説明したが、例えば、意味のあるデータdata 1のデータサイズがNCIバッファサイズより大きい場合、意味のあるデータdata １は、複数のNCIメッセージとしてデバイスホスト８０１に送信される。この場合、CLF８０２は、NCIバッファサイズを超えるまでHCPメッセージデータを合成してから送信するようにしてもよいし、合成せずに１つのHCPメッセージデータを１つのNCIメッセージとして送信するようにしてもよい。また、例えば、HCPメッセージデータを、各分割HCPメッセージデータのサイズがNCIバッファサイズを超えないように等分するようにしてもよい。さらに、その他の分割方法であってもよい。

また、このような合成や送信は、HCPメッセージデータを受信する毎に行うようにしてもよいし、意味のあるデータを全て受信してから行うようにしてもよい。さらに、その他のタイミングに行われるようにしてもよい。

以上のように、CLF２０８は、多様な場合において、HCIフォーマットをNCIフォーマットに適切に変換することができる。これにより、UICC８０３は、メッセージの分割や合成が必要な場合であっても、既存のHCIインターフェイスを用いて、外部の装置と非接触近距離無線通信を行う場合と同様に、容易にデバイスホスト８０１にメッセージを送信することができる。

＜４．第４の実施の形態＞
［コンピュータ］
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。この場合、例えば、図３７に示されるようなコンピュータとして構成されるようにしてもよい。

図３７において、コンピュータ９００のCPU（Central Processing Unit）９０１は、ROM（Read Only Memory）９０２に記憶されているプログラム、または記憶部９１３からRAM（Random Access Memory）９０３にロードされたプログラムに従って各種の処理を実行する。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

CPU９０１、ROM９０２、およびRAM９０３は、バス９０４を介して相互に接続されている。このバス９０４にはまた、入出力インタフェース９１０も接続されている。例えば、バス９０４は、物理的な１本または２本の線からなる。

入出力インタフェース９１０には、キーボード、マウスなどよりなる入力部９１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部９１２、ハードディスクなどより構成される記憶部９１３、モデムなどより構成される通信部９１４が接続されている。通信部９１４は、インターネットを含むネットワークを介しての通信処理を行う。

入出力インタフェース９１０にはまた、必要に応じてドライブ９１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア９２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部９１３にインストールされる。

上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。

この記録媒体は、例えば、図３７に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア９２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM９０２や、記憶部９１３に含まれるハードディスクなどで構成される。

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

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

また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。

また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

１００ 通信装置， １０１ ターミナルホスト， １０２ CLF， １０３ UICC， １１２ RF部， １１３ 制御部， １１４ カードRFゲート， １１５ レジストリ， １２１ カードAPPゲート， １２２ レジストリ， １２３ UICC OS， １２４ カードOS， １２５ アプリケーション， ３０３ 異常検出部， ３０４ 終端メッセージ送信部， ３０５ イベント送信部， ４２４ 終端メッセージ送信部， ５１２ RFフィールド更新部， ５１８ タイムアウト判定部， ６４１ ライン， ７０５ 制御信号送信部， ７２５ 制御信号受信部

Claims (20)

1. 他の装置と近距離無線通信を行う通信手段と、
   前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段と
   を備え、
   前記通信手段は、
   前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記処理手段に送信し、
   前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する
   通信装置。
2. 前記所定のサイズは、前記フォーマットにおけるデータサイズの上限値である
   請求項１に記載の通信装置。
3. 前記フォーマットのパケットは、パケットヘッダと前記分割メッセージとにより構成される
   請求項１に記載の通信装置。
4. 前記通信手段は、
   前記メッセージの最後の部分でない前記分割メッセージに、最後以外の分割メッセージであることを示す情報を含む前記パケットヘッダを付加し、
   前記メッセージの最後の部分の前記分割メッセージに、最後の分割メッセージであることを示す情報を含む前記パケットヘッダを付加する
   請求項３に記載の通信装置。
5. 前記通信手段は、
   前記終端メッセージに、最後の分割メッセージであることを示す情報を含む前記パケットヘッダを付加する
   請求項４に記載の通信装置。
6. 前記終端メッセージは、前記メッセージを終端する理由を示す情報を含む
   請求項１に記載の通信装置。
7. 前記他のメッセージは、発生したイベントを通知するイベントメッセージである
   請求項１に記載の通信装置。
8. 前記処理手段は、
   前記通信手段から送信される前記パケットを受信し、
   受信した前記パケットが前記分割メッセージを含む場合、受信した前記分割メッセージを受信済みの前記分割メッセージに合成し、
   受信した前記パケットが前記終端メッセージを含む場合、受信した前記終端メッセージを受信済みの前記分割メッセージに合成し、合成結果を１つの前記メッセージとして把握し、
   前記終端メッセージを受信後、前記他のメッセージを含む前記パケットを受信した場合、前記他のメッセージを前記メッセージと異なるメッセージとして把握する
   請求項１に記載の通信装置。
9. 前記処理手段は、
   前記他の装置に送信するメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記通信手段に送信し、
   前記メッセージの送信中に、前記通信手段から他のメッセージを受信した場合、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記通信手段に送信する
   請求項１に記載の通信装置。
10. 前記終端メッセージのパケットは、最後の分割メッセージであることを示す情報を含むパケットヘッダと空メッセージとにより構成される
    請求項１に記載の通信装置。
11. コンピュータを、
    他の装置と近距離無線通信を行い、
    前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して処理手段に送信し、
    前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する
    通信手段と、
    前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段
    として機能させるためのプログラム。
12. 他の装置と近距離無線通信を行う通信手段と、
    前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う処理手段と
    を備える通信装置の通信手段が、
    前記他の装置から受信したメッセージを所定のサイズ毎に分割し、得られた分割メッセージを順次所定のフォーマットでパケット化して前記処理手段に送信し、
    前記メッセージの送信中に、他のメッセージを送信する場合、前記他のメッセージの前に、前記メッセージを終端するメッセージである終端メッセージを前記フォーマットでパケット化して前記処理手段に送信する
    通信方法。
13. 他の装置と近距離無線通信を行う通信手段と、
    所定の規格の第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、
    前記第１のインターフェイスと異なる規格の第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段と
    を備え、
    前記通信手段は、
    前記第１の処理手段から前記第１のインターフェイスを介して、前記第２の処理手段へのメッセージである第１のメッセージを受信し、
    受信された前記第１のメッセージを前記第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、
    前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する
    通信装置。
14. 前記通信手段は、
    前記第１の処理手段から前記第１のインターフェイスを介して受信された前記第１のメッセージのサイズと前記第２のインターフェイスのフォーマットにおけるデータの最大サイズとを比較し、
    前記第１のメッセージのサイズが前記最大サイズより大きい場合、前記最大サイズに応じて前記第１のメッセージを分割して前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された各分割メッセージを、１つずつ、前記第２のインターフェイスを介して前記第２の処理手段に送信し、
    前記第１のメッセージのサイズが前記最大サイズより小さい場合、前記最大サイズに応じて複数の前記第１のメッセージを合成して前記第２のインターフェイスのフォーマットに変換し、前記第２のインターフェイスのフォーマットに変換された複数の前記第１のメッセージを、一度に、前記第２のインターフェイスを介して前記第２の処理手段に送信する
    請求項１３に記載の通信装置。
15. 前記通信手段は、
    前記第１の処理手段から前記第１のインターフェイスを介して受信された前記第１のメッセージに付加されたフラグ情報に基づいて、前記第１のメッセージと同じ意味のあるデータから分割された後続のメッセージが存在するか否かを判定し、
    前記後続のメッセージが存在しないと判定された場合、複数の前記第１のメッセージの和のサイズが前記最大サイズより小さくても、更なる合成を終了して前記第２のインターフェイスのフォーマットに変換し、
    前記第２のインターフェイスのフォーマットに変換された複数の前記第１のメッセージを、一度に、前記第２のインターフェイスを介して前記第２の処理手段に送信する
    請求項１４に記載の通信装置。
16. 前記通信手段は、
    前記第２の処理手段から前記第２のインターフェイスを介して、前記第１の処理手段へのメッセージである第２のメッセージを受信し、
    受信された前記第２のメッセージを前記第１のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第２のメッセージのフォーマットを前記第２のインターフェイスのフォーマットから前記第１のインターフェイスのフォーマットに変換し、
    前記第１のインターフェイスのフォーマットに変換された前記第２のメッセージを、前記第１のインターフェイスを介して前記第１の処理手段に送信する
    請求項１３に記載の通信装置。
17. 前記通信手段は、
    前記第２の処理手段から前記第２のインターフェイスを介して受信された前記第２のメッセージのサイズと前記第１のインターフェイスのフォーマットにおけるデータの最大サイズとを比較し、
    前記第２のメッセージのサイズが前記最大サイズより大きい場合、前記最大サイズに応じて前記第２のメッセージを分割して前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された各分割メッセージを、１つずつ、前記第１のインターフェイスを介して前記第１の処理手段に送信し、
    前記第２のメッセージのサイズが前記最大サイズより小さい場合、前記最大サイズに応じて複数の前記第２のメッセージを合成して前記第１のインターフェイスのフォーマットに変換し、前記第１のインターフェイスのフォーマットに変換された複数の前記第２のメッセージを、一度に、前記第１のインターフェイスを介して前記第１の処理手段に送信する
    請求項１６に記載の通信装置。
18. 前記通信手段は、
    前記第２の処理手段から前記第２のインターフェイスを介して受信された前記第２のメッセージに付加されたフラグ情報に基づいて、前記第２のメッセージと同じ意味のあるデータから分割された後続のメッセージが存在するか否かを判定し、
    前記後続のメッセージが存在しないと判定された場合、複数の前記第２のメッセージの和のサイズが前記最大サイズより小さくても、更なる合成を終了して前記第１のインターフェイスのフォーマットに変換し、
    前記第１のインターフェイスのフォーマットに変換された複数の前記第２のメッセージを、一度に、前記第１のインターフェイスを介して前記第１の処理手段に送信する
    請求項１７に記載の通信装置。
19. コンピュータを、
    他の装置と近距離無線通信を行い、
    第１の処理手段から所定の規格の第１のインターフェイスを介して、第２の処理手段へのメッセージである第１のメッセージを受信し、
    受信された前記第１のメッセージを前記第１のインターフェイスと異なる規格の第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、
    前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する
    通信手段と、
    前記第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、
    前記第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段
    として機能させるためのプログラム。
20. 他の装置と近距離無線通信を行う通信手段と、
    所定の規格の第１のインターフェイスを介して前記通信手段と通信を行うことにより、前記通信手段による前記近距離無線通信を介して前記他の装置とメッセージの授受を行う第１の処理手段と、
    前記第１のインターフェイスと異なる規格の第２のインターフェイスを介して前記通信手段と通信を行う第２の処理手段と
    を備える通信装置の通信手段が、
    前記第１の処理手段から前記第１のインターフェイスを介して、前記第２の処理手段へのメッセージである第１のメッセージを受信し、
    受信された前記第１のメッセージを前記第２のインターフェイスのフォーマットにおけるデータの最大サイズに応じて分割若しくは合成し、前記第１のメッセージのフォーマットを前記第１のインターフェイスのフォーマットから前記第２のインターフェイスのフォーマットに変換し、
    前記第２のインターフェイスのフォーマットに変換された前記第１のメッセージを、前記第２のインターフェイスを介して前記第２の処理手段に送信する
    通信方法。

Images