(57)【要約】  本発明は、支払い端末と通信端末との間で交換されるメッセージを、ｉＰｏｄアクセサリ・プロトコル、ｉＡＰ、を用いて前記支払い端末と前記通信端末との間を接続することによって多重化する方法に関する。この発明によれば、このような方法には、前記通信端末を用いて、外部通信インターフェースを初期化するステップ（３１１）と、リモート仮想チャネルを作る要求を、前記通信端末に前記外部通信インターフェースを経由して送信する第１の送信ステップ（３１２）と、前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作るステップ（３１３）と、前記外部通信インタフェースによって、前記ローカル仮想チャネルに関連したデータ・フレームを送信する第２の送信ステップ（３２）とを含んでいる。
2014517951.tif 000002
【特許請求の範囲】
【請求項１】
支払い端末と通信端末との間で交換されるメッセージを、ｉＡＰプロトコルを用いて前記支払い端末と前記通信端末との間を接続することによって多重送信する方法であって、
前記通信端末を用いて、外部通信インターフェースを初期化するステップ（３１１）と、
リモート仮想チャネルを作る要求を、前記支払い端末から前記通信端末に前記外部通信インターフェースを経由して送信する第１の送信ステップ（３１２）と、
前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作るステップ（３１３）と、
前記外部通信インターフェースによって、関連したデータ・フレームを前記ローカル仮想チャネルに送信する第２の送信ステップ（３２）と
を含んでいる方法。
【請求項２】
前記外部通信インターフェースがＲＳ２３２インターフェースであることを特徴とする請求項１に記載の方法。
【請求項３】
前記方法は、通信インターフェースを初期化する前記ステップ（３１１）の前に、前記通信端末に関連して前記支払い端末を認証するステップ（３０）をさらに含み、
該ステップ（３０）は、
認証証明書を取得するステップ（３０１）と
前記認証証明書によって前記通信端末と対にされた前記支払い端末の認定を検証するステップ（３０２）とを含んでいることを特徴とする請求項１に記載の方法。
【請求項４】
関連したデータ・フレームを前記ローカル仮想チャネルに送信する前記第２の送信ステップ（３２）は、
前記通信端末に向けられたＦＬＶフレームが前記仮想チャネルの中に存在することを検証するステップ（３２１）を含み、
前記チャネルの１つがそのようなフレームを有している場合、
ｉＡＰメッセージ（３２２１）の中に前記ＦＬＶフレームをカプセル化するステップ（３２２）を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記仮想チャネルは、
銀行取引上のデータを交換する仮想「トランザクション」チャネルと、
サービス情報の一部を交換する仮想「コンフィギュレーション」チャネルと、
前記支払い端末と前記通信端末との間のデータ送信を暗号化する仮想「ＳＳＬ」チャネルと、
プリント・データを送信する仮想「プリンタ」チャネルと、
バーコードの読み取りを管理する仮想「バーコード」チャネルと
を含むグループに属することを特徴とする請求項１に記載の方法。
【請求項６】
仮想チャネルはキューの形式で作られ、前記キューは前記仮想チャネルに向けられたＦＬＶフレームの受信、記録及び消去を可能にするように構成されることを特徴とする請求項１に記載の方法。
【請求項７】
支払端末と通信端末との間で、前記支払端末と前記通信端末との間の接続によって交換されたメッセージを、ｉＡＰプロトコルを用いながら多重送信するディバイスであって、
外部通信インターフェースを前記通信端末を用いて初期化する手段（３１１）と、
リモート仮想チャネルを作る要求を、前記支払い端末から前記通信端末に前記外部通信インターフェースを介して送信する第１の送信手段（３１２）と、
前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作成する手段（３１３）と、
関連したデータ・フレームを、前記ローカル仮想チャネルに前記外部通信インターフェースによって送信する第２の送信手段（３２）とを備えていることを特徴とするディバイス。
【請求項８】
通信ネットワークからダウンロード可能な、及び／又はコンピュータが読取り可能な担体上に記憶された、及び／又はマイクロプロセッサが実行可能なコンピュータプログラム製品であって、コンピュータ上で実行するとき、請求項１〜請求項６の少なくとも１つによる方法を実行するプログラム・コード命令を含むことを特徴とするコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子支払い端末の分野に関する。より詳細には、本発明は組み合わせることができる新規な種類の電子支払いディバイスに関する。本発明は、より詳細には、電子支払いディバイスを形成する２つの端末間のデータ送信にも関係する。
【背景技術】
【０００２】
現在、支払い端末は、セールス・ポイントで商品やサービスを購入するための支払いを可能にするために主に使用されている。これらの端末は一般に、スマートカード・リーダーと磁気カード・リーダーとを備えている。これらの端末は取引に含まれる金額などの情報を見るために特に使用されるスクリーン、及びそれらの金額や顧客が入力した機密コードを入力するためのキーパッドも備えている。あるいはまた、それらはタッチセンシティブ・スクリーンを備えている。
【０００３】
最近の端末は、通信ネットワークを介してキャッシュ・レジスタ及び／又はコンピュータに接続されている。そのような接続は、例えば、イーサネット（登録商標）型のケーブル接続とすることができ、あるいは無線接続であっても良い。これらの接続は、例えば、口座振替の承認を得るために、認証サーバに又は銀行サーバにリンクアップするために使用される。
【０００４】
外部のサーバと、特に銀行サーバと通信できるようにするために、端末支払い手段は１つ又は複数の接続手段を使用する。これらの手段の１つは、無線通信ネットワーク、例えば、ＧＰＲＳ（General Packet Radio Service、汎用パケット無線サービス）ネットワークの使用を含んでいる。この場合、支払い端末は単独で動作する。支払端末は、ＳＩＭ（Subscriber Identity Module、加入者識別モジュール）カードを備えている。これは、マイクロコントローラとメモリとを含むチップである。このＳＩＭカードは、取引先が支払わなければならない（データ送信タイプの）電話加入に関連付けられている。この種の加入は比較的高価であるという事実は別にして、通信機能は支払い端末に割り当てられる。従って、支払い機能に加えて、端末は本来、支払い端末に期待される機能ではない通信機能を管理する必要がある。
【０００５】
特に、ＧＰＲＳ通信に関連付けられた加入費用の問題を緩和するために、新規タイプの支払い端末が、例えば、ＷｉＦｉ（Wireless Fidelity、ワイヤレス・フィデリティー）型のネットワークによって通信する。取引先はその後、特別な加入を行うことを強要されることはない。支払端末は、取引先のＷｉＦｉネットワークに接続して、有線接続と同様に、銀行サーバにアクセスすることができる。しかしながら、支払い端末の使用はこの時、ＷｉＦｉネットワークのサービス地域に限定される。このことは、移動使用する用途（例えば、自身の患者を訪ねる医師又はタクシーの運転手）には適していない。
【０００６】
図１を参照して、発明者らは一般的なハードウェア・アーキテクチャを示す。この場合、支払い端末は、端末が単独でない場合（ケース１）及びそれが単独である場合（ケース２）に、銀行取引を実行できるように動作する。
【０００７】
従って、無線通信ネットワークを使用することにより移動使用する取引先が使用できる支払い端末を提案すること、同時にそのような支払い端末を使用する費用を最小限に低減することに対する要求が存在する。それゆえ、この目的のために、支払い端末を既存の通信端末（例えば、ｉＰｈｏｎｅ（登録商標）又はｉＰｏｄ（登録商標））と組み合わせて、対端末を形成することが提案されている。対端末は、本来、対にされない場合は支払い端末には存在しないような多数の機能を備えている。
【０００８】
問題はどのような新規の支払い端末も、一連の認証試験を受ける必要があることである。これらの認証試験は「ＰＣＩ／ＰＥＤ」試験と呼ばれている。それらは非常に高価である。支払い端末の製造業者は、このため、これらの試験が適切な条件のもとで実行されるように注意している。
【０００９】
従って、通信端末の新しいバージョン又は新しいタイプ（例えば、新しいｉＰｈｏｎｅ（登録商標）又は新しいｉＰｏｄ（登録商標））を対にするすることが望まれるたびに新たな認証試験を必要とせず、対端末を形成するように、通信端末と対にすることができる支払い端末を提案する必要性が存在する。
【発明の概要】
【００１０】
本発明は、これら従来技術の欠点を有していない。本発明は、より詳細には、支払い端末と通信端末との間で交換されるメッセージを、ｉＡＰプロトコルを用いて前記支払い端末と前記通信端末との間を接続することによって多重送信する方法に関する。本発明によれば、そのような方法は、
前記通信端末を用いて、外部通信インターフェースを初期化するステップと、
リモート仮想チャネルを作る要求を、前記支払い端末から前記通信端末に前記外部通信インターフェースを経由して送信する第１の送信ステップと、
前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作るステップと、
前記外部通信インタフェースによって、関連したデータ・フレームを前記ローカル仮想チャネルに送信する第２の送信ステップと
を含んでいる。
【００１１】
従って、本発明は、シリアル通信インターフェイスの使用において多数のチャネルによるデータ送信の実行を可能にする。
【００１２】
１つの特定の特徴によれば、前記外部通信インターフェースはＲＳ２３２インターフェースである。
【００１３】
１つの特定の実施形態によれば、前記方法は、通信インターフェースを初期化する前記ステップの前に、
認証証明書を取得するステップ、及び
前記認証証明書によって前記通信端末と対にされた前記支払い端末の認定を検証するステップを含む、
前記通信端末に関連する前記支払い端末を認証するステップをさらに含んでいる。
【００１４】
１つの特定の実施形態によれば、関連したデータ・フレームを前記ローカル仮想チャネルに送信する前記第２の送信ステップは、
通信端末に対するＦＬＶフレームが前記仮想チャネルの中に存在することを検証するステップを含み、
前記チャネルの１つがそのようなフレームを有している場合、
ｉＡＰメッセージの中に前記ＦＬＶフレームをカプセル化するステップ
を含んでいる。
【００１５】
１つの特定の特徴によれば、前記仮想チャネルは、
銀行取引上のデータを交換する仮想「トランザクション」チャネルと、
サービス情報を交換する仮想「コンフィギュレーション」チャネルと、
前記支払い端末と前記通信端末との間のデータ送信を暗号化する仮想「ＳＳＬ」チャネルと、
プリント・データを送信する仮想「プリンタ」チャネルと、
バーコードの読み取りを管理する仮想「バーコード」チャネルと
を備えるグループに属する。
【００１６】
１つの特定の特徴によれば、仮想チャネルは、キューの形式で作られ、前記キューは前記仮想チャネルを対象にしたＦＬＶフレームの受信、記録及び消去を可能にするように構成されている。
【００１７】
別の態様によれば、本発明は、支払端末と通信端末との間で前記支払端末と前記通信端末との間を接続によって交換されるメッセージをｉＡＰプロトコルを用いながら多重送信するためのディバイスにも関係する。
【００１８】
本発明によれば、そのようなディバイスは、
外部通信インターフェースを前記通信端末を用いて初期化する手段と、
リモート仮想チャネルを作る要求を、前記支払い端末から前記通信端末に前記外部通信インターフェースを介して送信する手段と、
前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作成する手段と、
関連したデータ・フレームを、前記ローカル仮想チャネルに前記外部通信インターフェースによって送信する手段と
を備えている。
【００１９】
好ましい実施形態によれば、本発明による方法の種々のステップは、コンピュータのソフトウェア・プログラムによって実行される。このソフトウェア・プログラムは、本発明による支払い端末のデータ・プロセッサが実行するためのソフトウェア命令を含み、この方法の種々のステップの実行を指令するように設計されている。
【００２０】
その結果、本発明はまた、コンピュータ又はデータ・プロセッサが実行することができるプログラムを得ることを求める。このプログラムは、本願で上述したように、方法のステップの実行を指令する命令を含んでいる。
【００２１】
このプログラムは、どのような任意のプログラミング言語も使用することができ、ソース・コード、オブジェクト・コード、又は部分的にコンパイルされた形態又は何らかの任意の他の望ましい形態のような、ソース・コードとオブジェクト・コードとの間の中間コードの形態とすることができる。
【００２２】
本発明は、本願で上述したように、データ・プロセッサが読取り可能で、プログラムの命令を含む情報担体を得ることも目的にしている。
【００２３】
この情報担体は、プログラムを記憶できるどのような任意のエンティティ又はディバイスであってもよい。例えば、この担体は、例えば、ＣＤ−ＲＯＭ又はマイクロ電気回路型ＲＯＭなどのＲＯＭ、あるいはまた、例えば、フロッピー（登録商標）ディスク又はハードディスク・ドライブなどの磁気記録手段といった記憶手段を備えることができる。
【００２４】
さらに、情報担体は、電気ケーブル又は光ケーブル、無線、又は他の手段によって伝達することができる電気信号又は光信号などの伝達可能な担体とすることができる。本発明によるプログラムは、特に、インターネット型ネットワークからダウンロードすることができる。
【００２５】
代替的に、情報担体は、プログラムが組み込まれた集積回路とすることができ、この回路は当該方法を実行し、又はその実行のために使用される。
【００２６】
１つの実施形態によれば、本発明は、ソフトウェア及び／又はハードウェア構成部品によって実現される。この点において、用語 「モジュール」は、本書では、ソフトウェア構成部品及びハードウェア構成部品の両方、又はハードウェア構成部品及びソフトウェア構成部品のセットに対応することができる。
【００２７】
ソフトウェア構成部品は、１つ又は複数のコンピュータ・プログラム、プログラムの１つ又は複数のサブプログラム、又はより一般的には、本願で以下に説明される内容に係る機能又は機能のセットを実行できるプログラムの任意の要素又はソフトウェアのアイテムに対応する。この種のソフトウェア構成部品は、物理的エンティティ（支払い端末）のデータ・プロセッサによって実行され、この物理的エンティティのハードウェア・リソース（メモリ、記録媒体、通信バス、入力/出力電子ボード、ユーザ・インターフェースなど）にアクセスすることができる。
【００２８】
同様に、ハードウェア構成部品は、該当するモジュールに対して本願で以下に説明する内容に係る機能又は機能のセットを実行できるハードウェア・ユニットの任意の要素に対応する。それはプログラム可能なハードウェア構成部品、又はソフトウェアを実行するための集積プロセッサ、例えば、集積回路、スマートカード、メモリカード、ファームウェアを実行する電子ボード等を有する構成部品とすることができる。
【００２９】
本発明の他の特徴及び利点は、単純な例示的で非網羅的な例として与えられる好ましい実施形態の以下の説明から、及び添付した図面からさらに明らかになるであろう。
【図面の簡単な説明】
【００３０】
【図１】既に提示された、支払い端末が動作する支払いシステムのハードウェア・アーキテクチャを例示する図である。
【図２】支払い端末内で実行されるソフトウェア層を説明するブロック図である。
【図３】１つの実施形態による多重送信方法を示す図である。
【図４】ｉＡＰメッセージのフォーマットを示す図である。
【図５】多重送信を実行する間に作成された仮想チャネルに対応するキューを示す図である。
【図６】多重送信ディバイスのハードウェア・アーキテクチャを簡単に説明する図である。
【発明の詳細な説明】
【００３１】
１．１  本発明の原理の確認
本発明は、通信端末及び支払い端末から構成されるユニットが（用語「ＰＣＩ／ＰＥＤ認証」で理解されるように）認証される必要なしに通信端末（例えば、ｉＰｏｄ（登録商標）又はｉＰｈｏｎｅ（登録商標））と対にするべく、現存する支払い端末を再利用するという目標を追求する。
【００３２】
この目的のために、本発明は、支払端末と通信端末との間で交換されるメッセージの双方向多重送信を行う多重送信ディバイスを実現することを提案する。提案されたソフトウェア・アーキテクチャは、通信端末及び支払い端末が「スタックＩＰ」（ｉＰｈｏｎｅ（登録商標）型）の使用のために直接許可していない移動可能製品とＩＰ（又はスタックＩＰ）データ交換を実行するときに働く解決策に対して、既に承認された現行のアプリケーションを再利用できるようにする。
【００３３】
より詳細には、多重送信はｉＡＰプロトコルによって実行される。このｉＡＰプロトコルは、本発明が解決することを目指している問題（ｉＡＰによって作られたボトルネック）の原因である。このため、支払い端末は、通信端末のアクセサリと見られている。実際には、通信端末は、支払い端末にはない多数の機能を備えており、有利なことに、支払い端末の機能を補完することができる。
【００３４】
多重送信ディバイスは、通信端末のデータであって通信端末から来るデータの支払い端末による送信及び／または受信につながる一連のステップを実施する。特定の実施形態によれば、ｉＡＰプロトコルを用いる接続によってメッセージを多重送信する方法は、ドッキング・ステーションと自動車用のアダプタといったようなｉＰｏｄ（登録商標）／ｉＰｈｏｎｅ（登録商標）とアクセサリとの間の通信に用いられるｉＰｏｄアクセサリ・プロトコル／ｉＡＰ（アップル・アクセサリ・プロトコル／ＡＡＰとしても知られている）を有している。このｉＡＰは、ｉＰｏｄ／ｉＰｈｏｎｅの読み取りを制御するため、及び読み取られるトラックやアルバム・カバー上のメタデータなどのデータを送信するために主に使用される。ｉＡＰの最近のバージョンでは、アクセサリがｉＰｈｏｎｅのＯＳ上で動作するアプリケーションと通信することも可能である。
【００３５】
しかしながら、ｉＡＰ及びそのアップル端末上での実施には、ビット・レートという大きな問題がある。実際に、ｉＡＰのビット・レートは、使用されるバージョン及び送信されるデータに応じて、約１９，２００から５７，６００ボーの範囲に限られている。実際は、端末とアクセサリとの間の通信は、ｉＡＰが使用しているＲＳ２３２インターフェース（シリアル・インターフェース）によって行われる。
【００３６】
今では、このインターフェースは、支払い端末と通信端末との間のデータ伝送には適合していない。このデータ伝送は、むしろＵＳＢインターフェースを介して得られなければならない。このＵＳＢインターフェースにより、大量のデータの高速伝送が可能になる。より詳細には、通信端末及び支払い端末は、ＵＳＢインターフェースによって互いに接続され、データ伝送は、ＰＰＰ（Point-to-Point Protocol、ポイント−ツー−ポイント・プロトコル）を実行する場合、直列リンクのエミュレーションによって行われる。ＰＰＰはそれ自体、支払い端末及び通信端末がそれぞれＩＰアドレスを持てるようにするＩＰ（Internet Protocol、インターネット・プロトコル）を実行する。その部分については、可変長のデータが、ＴＬＶ（Type-Length-Value、タイプ−長さ−値）技術に基づいて送信される。
【００３７】
換言すると、２つの端末間のＵＳＢリンクは、無論、高速であるが、多くのデータのカプセル化がなされる。これは、ＵＳＢリンクの効率をかなり実質的に損失させることになり、多数のカプセル化（ＩＰ、ＰＰＰ、ＵＳＢ）は、ＲＳ２３２インターフェースを介して送信することに対して、同じ技術を使用できるようにはしていない。
【００３８】
さらに、アップル端末と通信可能にするために、「リンゴー（lingos）」を使用する必要がある。ｉＡＰプロトコルは、アップル（登録商標）通信端末（ｉＰｈｏｎｅ（登録商標）、ｉＰｏｄ（登録商標）など）とこの通信端末に接続されたアクセサリ（ドッキング・ステーション、ヘッドセットなど）との間でデータ交換するためのチャネルである４つの「リンゴー」を定義している。４つのリンゴーは、一般的リンゴー（一般的なリンゴー）、ディスプレイ・リモート・リンゴー（表示転送）、拡張インターフェース・リンゴー（拡張インターフェース）、ディジタル・オーディオ・リンゴー（オーディオ・データの送信）を指す。通信端末との他の通信手段は使用できない。このため、発明者らは支払い端末に適したデータ伝送可能な技術を実行してきた。実際、ｉＡＰプロトコルを使用する通信端末が提供する送信手段（リンゴー）は、支払いアプリケーションを実行するのに明らかに適していない。
【００３９】
従って、本発明は、支払い端末と通信端末との間のデータ伝送を管理することができるリンク層を実現することを提案する。このリンク層により、端末の間で送信される（ＦＬＶフレーム形式の）データ・ストリームを管理することができる。
【００４０】
図２を参照すると、１つの実施形態に基づいて支払い端末の中で実施されたソフトウェア層を説明するブロック図が示されている。
【００４１】
このソフトウェア層は、端末のハードウェア構成部品と直接対話するソフトウェア・モジュールを含む「低レベル」層として知られる層を備えている。この「低レベル」層は、支払い端末のハードウェア・ディバイスを駆動することができ、またドライバを備えている。この「低レベル」ソフトウェア層は、オペレーティング・システム（ＯＳ）によって使用される。オペレーティング・システムは、特にライブラリを含む。オペレーティング・システムは、それ自体、支払い端末の種々のアプリケーションを制御するアプリケーション・マネージャによって使用される。実行可能なアプリケーションの中に、支払いアプリケーション（シンプル、分割払いによる繰り延べ）、ポイントカード、電子財布などの管理、を挙げることができる。
【００４２】
１．２  １つの実施形態の説明
支払い端末とｉＰｏｄ（登録商標）又はｉＰｈｏｎｅ（登録商標）型通信端末との間のリンクの関連でこの使用に適合しない「連続」型のリンクを介してデータ伝送を可能にするために、本発明はこの実施形態の中でメッセージの多重送信を実行するように提案する。
【００４３】
より詳細には、目的が、通信端末及び支払い端末によって構成されたユニットを認証を要求されることなく（ＰＣＩ／ＰＥＤ認証で理解されるように）、通信端末（ｉＰｏｄ（登録商標）又はｉＰｈｏｎｅ（登録商標））と対にするために現存する支払い端末を再利用できるようにすることであるため、発明者らは更新することができる単純な解決策を提供する。この目的のために、発明者らは、支払い端末とｉＰｈｏｎｅ（登録商標）又はｉＰｏｄ（登録商標）との間のインターフェースとして機能する多重化ディバイスを実現した。
【００４４】
より詳細には、１つの実施形態では、このインターフェースは、先ず第１に、メッセージを移動端末に送信すること及び移動端末から受信することを可能にするソフトウェア又はハードウェアのどちらかのインターフェース・モジュールである。第１の特定の実施形態によれば、多重送信ディバイスは、支払い端末の中で実現される。このため、それは支払い端末内で実施される安全対策（ＰＣＩ−ＰＥＤ認証を可能にするために取られる対策）の恩恵を受ける。第２の特定の実施形態によれば、インターフェース多重送信ディバイスは、支払い端末と移動端末との間の電子接続基板内で実施される。この第２の実施形態では、電子接続基板は、以下のものが取り付けられたプリント回路、すなわち、
カードを支払いディバイスに接続するための第１のコネクタ、
カードを通信端末に接続するための第２のコネクタ、及び
カードを外部ディバイス（例えば、充電器）に接続するための第３のコネクタ
が取り付けられたプリント回路を備えている。
【００４５】
本発明によれば、インターフェース多重送信ディバイスは、支払い端末と移動端末との間のメッセージを多重送信する方法を実施するように構成されている。この多重送信方法は、図３を参照して提示され、支払い端末から見た下記のステップを含んでいる。すなわち、
外部通信インターフェースを前記通信端末で初期化するステップ（３１１）と、
リモート仮想チャネルを作る要求を前記通信端末に前記外部通信インターフェースを介して送信する第１の送信ステップ（３１２）と、
前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作成するステップ（３１３）と、
前記ローカル仮想チャネルに関連したデータ・フレームを、前記外部通信インターフェースによって送信する第２の送信ステップ（３２）と
を含んでいる。
【００４６】
従って、支払い端末は、データを仮想チャネルによって通信端末に送信することができる。
【００４７】
下記は、仮想チャネルのリストである、すなわち、
銀行取引に関するデータを送信及び受信する「取引」仮想チャネル、
サービス情報（同期、更新、等）の交換を可能にする「構成」仮想チャネル、
支払い端末と通信端末との間のデータ伝送を確保するために、プロトコルのあとに名祖的に名付けられた（eponymously named）「ＳＳＬ」チャネル、
取引の結果から生じるデータなどのプリント・データとして知られているデータ（一般に、「カード・レシート」と呼ばれる）を送信する「プリンタ」チャネル、
支払い端末がバーコード・リーダを備えている場合、バーコードの読み取りを管理することができる「バーコード」仮想チャネル、である。
【００４８】
外部通信インターフェースを通信端末で初期化する前に、本発明の方法は、前記通信端末に関連する前記支払い端末を認証する第１の認証ステップ（３０）をさらに含んでいる。通信端末と接続することを支払い端末に認めることを確実にするためにこのステップを使用する。
【００４９】
この認証する第１の認証ステップ（３０）は、支払い端末から見て、（例えば、支払い端末内に配置された専用のプロセッサから）認証を得るためのステップ（３０１）、及び誰何／応答型（チャレンジ／レスポンス・タイプ、challenge/response type）の検証ステップ（３０２）を含んでいる。この検証ステップで、通信端末は対にされる支払い端末の認定を検証する。支払い端末内に組み付けられているこの目的専用のプロセッサは、通信端末の製造業者（例えば、アップル（登録商標）社）が提供するプロセッサとすることができる。
【００５０】
図示されていない特定の１実施形態では、有利なことに、認証する第１の認証ステップの後に認証する第２の認証ステップが続いている。この第２のステップでは、立証責任は支払い端末側ではなく通信端末側にある。この第２のステップは、このように、通信端末に、対にされた支払い端末と真に対にされる資格が与えられることを確実にすることを目的にしている。この認証するステップは、「誰何／応答」型又は任意の他の適切な型とすることができる。この認証する第２のステップは、有利なことに、通信端末のＳＩＭカードに含まれた暗号化装置を使用できる。このため、相互認証のためにこれを使用することにより、機密データを（この目的のために設計されていない）通信端末に配置することや、この目的のために高価な解決策を開発することの必要性が避けられる。
【００５１】
本発明の１つの実施形態によれば、前記支払い端末の中に、通信端末によって作られた前記仮想チャネルに対応する仮想チャネルを作るステップ（３１３）の後、多重送信する方法は、前記仮想チャネルの中に、通信端末に向けられたＦＬＶフレームの存在を検証するステップ（３２１）を含み、チャネルの１つがこの種のフレームを備える場合、このＦＬＶフレームをｉＡＰメッセージ（３２２１）の中でカプセル化するステップ（３２２）を含んでいる。
【００５２】
本発明の１つの特定の実施形態によれば、図４を参照して示された、送信されたｉＡＰメッセージ（３２２１）のフォーマットは、下記の通りである、すなわち、
長さ１バイトの「リンゴ」識別子（４０１）、
長さ１バイトのフレーム識別子（４０２）、
長さ２バイトのトランザクション識別子（４０３）、
長さ２バイトのセッション識別子（４０３）（仮想チャネル番号（４０４）に対応する）、
可変長ＴＬＶのデータ（４０５）、
ＣＲＣ整合性チェック・コード（４０６）
である。
【００５３】
こうして、カプセル化データが大幅に最小化され、このため、より多くのペイロード・データが制限された物理チャネルの中で送信される。
【００５４】
本発明の１つの態様によれば、多重送信する方法はまた、通信端末側に、通信端末の仮想チャネル内に、支払い端末に向けられたＦＬＶフレームが存在することを検証するステップ（３２３）と、またチャネルの１つがそのようなフレームを含んでいる場合、ｉＡＰメッセージの中のこのＦＬＶフレームをカプセル化するステップ（３２４）とを含んでいる。
【００５５】
従って、通信インターフェースは、双方向インターフェースとして使用される。
【００５６】
より詳細には、図５を参照して説明される１つの特定の実施形態では、仮想チャネルが、複数のＦＩＦＯ型キューの形式で作成される（支払い端末側でＦ１〜Ｆ５及び通信端末側でＦ’１〜Ｆ’５）。これらのキューは、下記のように機能する。
【００５７】
キューは、支払い端末のアプリケーション（ＡＰＰｘ、ＡＰＰｙ、ＡＰＰｚ）の視点からは見えない。これが、既に認証されているこれらのアプリケーションを変更する必要がない理由である。実際に、支払い端末のアプリケーションはデータ伝送チャネルを使用する。このように、支払い端末のアプリケーションに関して、操作は前の操作と同一である。すなわち、アプリケーションは実行するために必要なチャネルを使用する。
【００５８】
相違点は、チャネルが取る形式にある。実際に、チャネルは２つの装置間のデータ伝送の実際の経路であったが、本発明はここでチャネルをＦＩＦＯ型のキューの形式にする。このため、例えば、（支払い端末のアプリケーションによって）ＦＬＶフレームが挿入される、又は（通信端末から）得られる５つのキュー（すなわち、仮想チャネルと同数のキュー）が存在する。キューは、多重送信ディバイス（ＭＰ）によって管理される。このディバイスは、キューの内容（Ｆ１〜Ｆ５）を検証すること、あらかじめ図４を参照して説明したメッセージの形式でＦＬＶフレームをカプセル化すること、及びこれらのメッセージを通信端末に送信することを管理する。その反面、このディバイスは、ｉＡＰメッセージを通信端末から受け取り、このメッセージの中に含まれたＦＬＶフレームを挿入しなければならないキュー（Ｆ１〜Ｆ５）を識別する。それはｉＡＰメッセージのカプセル化を解除し（すなわち、それはＦＬＶヘッダ情報を取り除く）、そしてメッセージに含まれた仮想チャネル番号を使用して、ＦＬＶフレームをキューの中に配置する。このＦＬＶフレームが向けられるアプリケーションは、処理するためにそれを取り出し、そしてＦＬＶフレームは多重送信ディバイスによってキューから消去される。多重送信ディバイスは、ハードウェア構成部品又はソフトウェア構成部品の形式で実施することができる。
【００５９】
１．３  他のオプションの特徴及び利点
図６を参照すると、本発明に係る多重送信ディバイスの実施形態が示されている。
【００６０】
例えば、多重送信ディバイスは、バッファ・メモリで構成されるメモリ６１、例えば、マイクロプロセッサを備えた処理ユニット６２及びランダムアクセス・メモリを備え、本発明に係る多重送信方法を実行するコンピュータ・プログラム６２によって駆動される。
【００６１】
初期化時に、コンピュータ・プログラムのコード命令６３は、例えば、メモリにロードされ、次に、処理ユニット６２のプロセッサによって実行される。
【００６２】
処理ユニット６２は、支払い端末のアプリケーションが送信したフレームＦＬＶを入力する。このフレームＦＬＶは、当初は、通信チャネルによる送信に向けられている。このディバイスは、このＦＬＶフレームをインターセプトして、これを仮想チャネルに対応するキューの中に格納する。この仮想チャネルは、通信チャネルをエミュレートする。
【００６３】
処理ユニット６２は、キューに挿入されたばかりのＦＬＶフレームのｉＡＰメッセージの形式で、並行してカプセル化を実行し、このｉＡＰメッセージを通信端末に送信する。本発明の１つの実施形態によれば、この送信は、ｉＡＰプロトコルの「一般的な」リンゴーによって実行される。
【００６４】
処理ユニット６２のマイクロプロセッサは、多重送信方法のステップを実行して、コンピュータ・プログラム６３の命令に従って、ｉＡＰメッセージを送信できるようにする。
【００６５】
この目的のために、多重送信ディバイスは、バッファ・メモリ６１に加えて、前記通信端末を用いて外部通信インターフェースを初期化する手段と、リモート仮想チャネルを作るための要求を、前記支払い端末から前記通信端末に前記外部通信インターフェースを介して送信する手段（３１２）と、前記支払い端末の中に、前記リモート仮想チャネルに対応するローカル仮想チャネルを作る手段と、関連するデータ・フレームを、前記リモート仮想チャネルに前記外部通信インターフェースを介して前記ローカル仮想チャネルに送信する手段とを備えている。これらの手段は、処理ユニット６２のマイクロプロセッサによって駆動される。
【図１】
2014517951.tif 000003
【図２】
2014517951.tif 000004
【図３】
2014517951.tif 000005
【図４】
2014517951.tif 000006
【図５】
2014517951.tif 000007
【図６】
2014517951.tif 000008
【国際調査報告】
2014517951.tif 000009
2014517951.tif 000010
2014517951.tif 000011
2014517951.tif 000012
2014517951.tif 000013
2014517951.tif 000014