JP5122282B2 - 電子金融取引システム - Google Patents

Description

発明の詳細な説明

本発明は、電子金融取引に関し、詳細には、電子金融取引のシステムおよび方法ならびにそのようなシステムのコンポーネントに関する。

ＥＦＴ（ｅｌｅｃｔｒｏｎｉｃ ｆｉｎａｎｃｉａｌ ｔｒａｎｓａｃｔｉｏｎ）システムを使用して、顧客が、さまざまなタイプのデビットカードおよびクレジットカードを用いて商品およびサービスに対する支払いを行うことができるようにすることがよく知られており、以降では、これらのカードを「取引カード」あるいは単に「カード」と呼び、これらの用語は、ＥＦＴ取引において採用される同等のタイプのデータ記憶媒体などを含むものと理解され、たとえば前払いのモバイル取引のための電子バウチャーを含むことができる。このようなシステムにおいては、ＥＦＴＰＯＳ端末（ＥＦＴ ｐｏｉｎｔ ｏｆ ｓａｌｅ （ＰＯＳ） ｔｅｒｍｉｎａｌ）が、リモート「取得者」システムと通信し、このリモート「取得者」システムは、一般に銀行などの金融機関によって、またはそうした金融機関のために操作されて、取引を承認および処理する。

一般にＥＦＴＰＯＳ端末は、（通常は磁気ストリップを読み取ること、またはカード上のチップを調べることによって）顧客のカードの詳細と、（通常はキーパッドの入力によって、または関連するキャッシュレジスタシステムなどから直接）少なくとも取引の数量を含むその他の情報とを取得し、次いで電気通信リンクを介して取得者システムとオンラインで通信して、取引を承認および／または処理する。ＥＦＴ取引を承認および処理できる方法には、「小売信用限度額」を使用して、オンラインの承認が必要かどうかを判断すること、リアルタイムとバッチモードの取引処理、少しずつ進める取引処理などを含む多くのバリエーションがある。本発明は、そのようなすべてのモードのＥＦＴ処理に適用することができる。

従来のＥＦＴのシステムおよび方法については、本明細書では詳細には説明しない。そのような詳細は、当業者によく知られているためである。ただし、下記の点については留意されたい。

ＥＦＴシステムは一般に、取引を承認および処理するための標準的なプロトコルに準拠している。英国においては、そのようなプロトコルとしては、ＡＰＡＣＳ ３０／５０およびＡＰＡＣＳ ４０が含まれる。類似のプロトコルおよび／または同等のプロトコルが、その他の場所でも適用されている。本発明については、とりわけＡＰＡＣＳプロトコルを参照して説明するが、本発明は、それに限定されるものではなく、すべてのＥＦＴプロトコルと共に使用できる、あるいはそうした使用に適合できることを意図しているものであるということを理解されたい。

ＥＦＴＰＯＳ端末は一般に、１つまたは複数のカードリーダデバイスあるいはその同等物と、ディスプレイと、キーパッドおよび／またはピンパッドあるいはその同等物と、プリンタとを含み、スタンドアロンのデバイスと、複数の無線ハンドセットを有するＰＯＳシステムと、キャッシュレジスタならびに当技術分野でよく知られているその他の「ローカルな」デバイスおよびシステムなどに関連付けられている、または統合されているデバイスとを備えることができ、直接、またはやはりよく知られている１つまたは複数の中間システムを通じて、取得者システムと通信することができる。本発明は、そのようなすべてのタイプのＥＦＴＰＯＳ端末および関連するシステムに適用できることを意図されているということが理解できるであろう。とりわけ、本発明のシステムの一部として本明細書に記載されているリモートホストシステムまたはそのようなシステムのコンポーネントが、取得者システムと通信するものとして記述されている場合、そのような通信は、さらなる中間システムを含むことができるということが理解できるであろう。

本発明はまた、署名およびＰＩＮの確認、および指紋、音声、網膜スキャン認識などの生体認証による確認技術を含むすべての公知のタイプおよび提示されているタイプの顧客ＩＤ確認と共に使用できることを意図している。

ＥＦＴＰＯＳ端末が、「安全な端末」であるということ、すなわち通信の傍受や盗み読みを防止するための、偽物の端末や偽物の取得者ホストの使用を防止するための、あるいは端末に対する物理的な不正を防止するための１つまたは複数のセキュリティーメカニズムを有する端末であるということは、暗黙の了解である。実装されるセキュリティーメカニズムは、実行されている取引の性質および規模を考慮して、適正なレベルのセキュリティーを提供するだけの十分に厳格なものである必要がある。ＥＦＴシステム内で採用されるすべての通信システムが安全でなければならないことも、暗黙の了解である。エンドユーザの端末および関連するローカルシステムを除いて、ＥＦＴシステムの一部を形成するデータ処理システムは一般に、コントロールされた安全な環境内に配置され、「安全」であるとみなすことができる。

上述のようなすべてのタイプの従来のＥＦＴＰＯＳ端末においては、端末は、端末のプログラミングによって、そのユーザインターフェースを提供し、取引カードを読み取り、取引伝票を印刷し、特定の取引をどのように処理するかを決定し、取得者あるいはその他のローカルシステムまたはリモートシステムと通信する（これらの機能の一部またはすべてを端末の「ビジネスロジック」と呼ぶことができる）が、そうしたプログラミングは、ＣやＣ＋＋などの低水準言語で書かれ、端末内に「ハードコード」されている。つまりプログラミングは、ハードウェアまたはファームウェア内の端末の中に「永久に」常駐する。すなわちプログラミングは、端末の通常の電源ＯＮ／ＯＦＦサイクル中には、あるいは通常の使用においては変わらない。

従来のハードコードされた端末に伴う重大な問題は、端末プログラミングの修正、アップグレードなどには、（ａ）専門のプログラミングスキルと、（ｂ）インストールされている端末ユーザ基盤の現場での再構成とが必要になるという点である。つまり、新しいまたは改良されたビジネスロジックあるいはその他の端末機能の導入は、複雑であり、費用がかさみ、長い準備期間を必要とする。また、そのような修正および改良は必然的に、（個人のエンドユーザではなく、チェーンストアなどのユーザ組織という意味での）ユーザ、サービスプロバイダー、または取得者によってではなく、一般に元の機器製造業者またはその他の高度に専門化した供給業者によって、開発されインストールされなければならない。このことから生じる１つの結果としては、システムの開発および保守に含まれる諸経費が高くなるという点のほかに、ＥＦＴシステムのインフラストラクチャーが非常に柔軟性に欠けるという点がある。

本発明の目的は、新しいおよび改良されたビジネスロジックの開発および実装を含むシステムインフラストラクチャーの保守および開発を容易にする改良されたＥＦＴのシステム、（端末を含む）システムコンポーネント、および方法を提供することである。

本発明の特定の特徴は、一般的なコンピューティング、ネットワーキング、および通信テクノロジーのさまざまな領域から公知であるということ、あるいはそうした領域において同等のものを有するということを示すことができるのは明らかであるが、セキュリティーが最優先事項であり、ユーザおよびサービスプロバイダーが必然的に保守的になるＥＦＴシステムのコンテキストにおいて、そのような特徴を採用すること、または組み合わせることが、どこから見ても明らかであるとみなすのは正しくない。たとえば、特別にフォーマット設定されたインターネットコンテンツにユーザがアクセスできるようにする特別に修正されたブラウザを採用しているモバイルコンピューティング／通信デバイスが、知られているかもしれない。しかし、ＨＳＣ（Ｈｉｇｈ Ｓｅｃｕｒｉｔｙ Ｃｏｒｅ）やその他のＥＭＶ対応機能など、何らかのセキュリティーの高い不正行為検出ハードウェア機能が欠けているため、そのような従来のモバイルデバイスを電子金融取引用の安全な端末として使用するために検討できる有効な方法はない。

本発明は、そのさまざまな態様および好ましい特徴において、本明細書に添付されている特許請求の範囲において定義される。本発明のさらなる態様および好ましい特徴は、その好ましい実施形態に関する以降の説明から明らかになるであろう。

以降の説明では、従来のＥＦＴのシステム、機能、および用語の知識は、コンピューティング、コンピュータネットワーキング、および電気通信に関連して一般に受け入れられている用語の知識であると想定する。これには、国外および国内を問わず、ＩＥＴＦ、ＷＡＰ Ｆｏｒｕｍ、Ｕｎｉｃｏｄｅ組織、Ｗ３Ｃ、ＩＳＯ、ＥＴＳＩ、ＩＴＵ、およびその他の組織によって作成された関連する規格およびその他の文書において定義されている用語が含まれる。

次いで本発明の実施形態について、例示のみを目的として、添付の図面を参照して説明する。

本発明は、ＥＦＴ（支払い）システムのための新しい普遍的なアプローチを提供し、このアプローチによって、ビジネスロジックは、端末からリモートホストシステムへ完全に移行される。

本発明のコンテキストにおいては、端末は、リモートホストシステム内に配置されているウェブのようなアプリケーションを見るためのものとみなされる。ユーザによって入力されたデータは、すべてのアプリケーションに関して同じ方法で処理される。そうしたデータは、リモートホストシステムへ送信され、そこでアプリケーション固有の方法で処理される。

図１は、第１の実施形態によるシステムの論理図を示している。端末１０が、システムのエンドユーザと対話するために提供されている。図示されている実施形態においては、この端末は、ディスプレイ、キーパッド、ピンパッド、プリンタ、磁気カードリーダ、およびＩＣＣ（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ）リーダを備える。

端末１０は、「マイクロブラウザ」ソフトウェアアプリケーション（マイクロブラウザ）１２を実行し、このマイクロブラウザ１２は、指定されたＴＭＬ（Ｔｅｒｍｉｎａｌ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ）に従って記述されるページをレンダリングおよびナビゲートすることができ、これについては、以降でさらに詳しく説明する。

マイクロブラウザ１２は、リモートホストシステムと通信し、このリモートホストシステムは、ゲートウェイホスト１９、支払いアプリケーション２２、および設定サービス２６を備える。

ゲートウェイホスト１９は、ゲートウェイ実行可能アプリケーション１４を含む。ゲートウェイ実行可能アプリケーション１４は、コンバータ１６およびＨＴＴＰプロキシ１８と共に機能する。ゲートウェイホスト１９のオペレーションについては、以降で説明する。

ＨＴＴＰプロキシ１８は、１つまたは複数のＨＴＴＰサーバにサービスを提供し、この場合は、ＴＭＬ支払いアプリケーション２２を実行する第１のＨＴＴＰサーバ２０と、設定ウェブサービス２６を実行する第２のＨＴＴＰサーバ２４とにサービスを提供する。

第１のＨＴＴＰサーバ２０は、静的なＴＭＬページと取得者ホストのソフトウェアとの双方を含むＴＭＬアプリケーション２２を分配し、管理する。ＨＴＴＰサーバ２０はまた、ＴＭＬアプリケーションへの非公開の承認されたアクセスを提供することも担当する。端末の送信を処理している間、ＴＭＬアプリケーションのホスト部分は、その他のホストと対話することができる。任意の適切な電子取引プロトコルを使用することができる。プロトコルの選択は、使用されているハードウェアのタイプ、含まれている取引のタイプ、および端末が使用されている国の金融機関によってどのプロトコルが承認されているか、あるいは一般に使用されているかということに左右される。たとえば英国においては、ＡＰＡＣＳ ３０／５０および／またはＡＰＡＣＳ ４０の規格を使用して、取得者のホストと通信することができる。ＴＭＬアプリケーションは、ウェブＧＵＩ ２８を使用して、さらに更新および設定することができる。ＴＭＬアプリケーションはまた、データベース２００を利用し、このデータベース２００は、端末のリストおよび通信ログを整備するために使用することができる。取得者は、ＡＰＩ ２０２と対話する。

設定ウェブサービス２６は、ＲＰＣ（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌｉｎｇ）フレームワークを介してアクセスされ、端末１０を自動的に設定するために使用することができる。ウェブサービス２６は、ウェブＧＵＩ ３０を使用して更新および設定することができ、また設定サービスデータベース２０４を利用し、この設定サービスデータベース２０４は、端末のリストおよび通信ログを整備するために使用することができる。マイクロブラウザ１２は、端末１０内で作動する。マイクロブラウザ１２は、取引を完了するために必要とされるビジネスロジックを実際に実施するのではなく、別々のＴＭＬアプリケーションによって指定されるビジネスロジックのインタープリターとみなすことができる。マイクロブラウザ１２は、指定されたＴＭＬに対応するように特に設定されている端末アプリケーションである。

図２は、下記のようなマイクロブラウザ１２のコンポーネントの詳細を示している。

端末マイクロブラウザアプリケーション３２は、端末ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の要件に従って実装されるすべてのサブシステムのためのラッパーである。端末マイクロブラウザアプリケーション３２は、マイクロブラウザ１２のメイン処理ループを含み、ＯＳのイベントを処理することができる。

デフォルト設定によって、マイクロブラウザ１２は、ＯＳがロードされた直後に起動する。マイクロブラウザ１２は、インデックス、またはルート、ＵＲＩを検索し、ページのブラウズを開始する。あるいは、電源オフのイベントの後には、電源オフの前の状態を回復することができる。「終了」のＵＲＩが選択されると、マイクロブラウザ１２は、メインループを終了し、フローのコントロールをＯＳに渡す。

マイクロブラウザ１２は、磁気カードを通すことや、スマートカードを挿入することなど、ＯＳのイベントを処理する際には、イベント駆動型のアプリケーションモードで実行することができる。あらゆるイベントは、ＵＲＩに関連付けることができる。そしてマイクロブラウザ１２は、そのイベントのために指定されたＵＲＩを用いてメインループを始動させる。

端末マイクロブラウザアプリケーション３２は、端末のバッテリー充電状況（当てはまる場合には、たとえば無線端末のハンドセット用として）、およびネットワークステータスインジケータをユーザに表示することも担当する。

マイクロブラウザ１２は、設定メニューをまったく必要としない。ＴＭＬアプリケーションは、ＴＭＬ変数の値を変更すること、またはルーチンを呼び出すことによって、ブラウザ１２の設定を変更することができる。しかしマイクロブラウザ１２は、内蔵されたＴＭＬページを含み、このＴＭＬページは、ブラウザの設定を変更するために使用される。

ＴＭＬアプリケーションをダウンロードおよびブラウズすることとは別に、端末マイクロブラウザアプリケーション３２はまた、送信するデータがまったくない場合でさえ、端末１０のキャッシュおよび設定データを定期的にリフレッシュする。

設定メニューがまったくないため、またビジネスロジックが端末１０から取り除かれているため、マイクロブラウザ１２は、機能の面で非常にシンプルである。ユーザの観点からは、このことは、端末１０のエンドユーザや、支払いを処理するために端末１０を使用したいと希望する業者が、直観的かつシンプルな方法で端末を使用することができるということを意味する。しかし、おそらくはより重要なことに、システムインテグレータの観点からは、複雑なプログラミング言語の多大な知識を必要とすることなく、端末の機能を修正することができ、顧客サポートヘルプデスクを運営することができる。むしろ必要とされるのは、ＴＭＬの実用的な知識だけであり、これによって、ユーザフレンドリーな環境が提供される。

初期設定モジュール３４は、一意の端末パスワードおよびルートセキュリティー証明書を入手することを含む端末の初期設定のために、ならびに端末のスイッチがオンにされた後のデータの整合性をチェックするために使用される。端末の初期設定プロセスのさらなる詳細は、以降で提示する。

設定モジュール３６は、ＲＰＣ（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌｉｎｇ）フレームワークを介した端末の自動設定を担当する。この設定は、時刻同期、端末の設定を更新すること（たとえば、イベント駆動型のマイクロブラウザモード用のイベントに対応するＵＲＩを定義すること）、あるいはカードパーサ用のパラメータをダウンロードすることを含むことができる。設定モジュール３６は、ＨＴＴＰクライアント３８と連携して、ＲＰＣデータを用いてＨＴＴＰ要求を作成し、応答を受け取り、そしてこの応答が、端末を設定するために解析される。

ＨＴＴＰクライアント３８は、リソースをロードして解析し、それらのリソースのそれぞれは、ＵＲＩによって識別される。ＨＴＴＰパーサ４０は、バイナリーＨＴＴＰ要求を構築および解析することを担当する。要求されているリソースから他のリソースが参照されている場合には、モジュール３８は、それらの他のリソースも検索する。ＨＴＴＰクライアント３８はまた、端末１０の永続的なメモリに配置されているリソースのキャッシュを保持する。ＨＴＴＰクライアント３８は、要求されているリソースが永続的なメモリ内に存在するかどうかを最初にチェックし、そのリソースが見つからない場合には、ゲートウェイホスト１９から、またはゲートウェイホスト１９を介して、そのリソースを検索する。

ＨＴＴＰクライアント３８はまた、オフラインまたはオンラインのいずれかで、ＨＴＴＰサーバ（図１の２０、２４）へデータを送信する。ＨＴＴＰクライアント３８は、端末のメモリ内に保存されているすべての延期されている送信を印刷することができ、また送信をキャンセルすることができる。さらに、ＨＴＴＰクライアント３８は、ゲートウェイホスト１９へ接続するたびに、端末１０の自動設定を開始することができる。設定モジュールの要件を満たすように作成されたウェブサービスコンバータおよびスタブは、リモートプロシージャコーリングライブラリ（図示せず）内に含まれる。

ＨＴＴＰクライアント３８は、ＳＴＰ（ｓｅｃｕｒｅ ｔｅｒｍｉｎａｌ ｐｒｏｔｏｃｏｌ）インターフェース４２を通じて通信を行い、このＳＴＰインターフェース４２は、接続を開いたり閉じたりすること、いくつかのラップされたＨＴＴＰパケットと共に要求を送信すること、および応答を受け取ることができる。インターフェース４２は、ＴＬＳ、ＩＰスタック、および暗号ライブラリ（図示せず）を利用することができる。

ＴＭＬパーサ４４が、ＴＭＬページを解析するために提供されている。ＴＭＬパーサは、ページのフォーマットを確認し、そのページ内に導入される変数を宣言し、ＴＭＬを、レンダリングおよび処理に適したフォーマット（たとえば、Ｃ構造）へ変換する。

ＴＭＬパーサ４４は（数あるマイクロブラウザ１２のモジュールの中でも特に）変数ライブラリ４６を利用し、この変数ライブラリ４６は、新しい変数のためのスペースを別々の範囲内に割り当て、事前に定義された変数を生成し、スクリーンに関連付けられている〈ｓｅｔｖａｒ〉要素を処理し、指定された変数の名前および範囲を表す変数値を検索し、変数値を変更し、ＵＲＩによって指定されたページ内に導入されているすべての変数を削除する。

変数ライブラリ４６はまた、レンダリング／ナビゲーションモジュール４８によって使用され、このレンダリング／ナビゲーションモジュール４８は、スクロールアップおよびスクロールダウンとアクティブなリンクの強調表示とを含めてディスプレイスクリーンをレンダリングすること、リンクおよびフォーム要素を通じたナビゲーションを行うこと、プリントスクリーンを印刷すること、メッセージスクリーンおよびフォームプロンプトを（端末ディスプレイ上に）レンダリングすること、ならびにチェックされているチェックボックス要素およびチェックされていないチェックボックス要素とページアップおよびページダウンとを正しくレンダリングすることを含めて、〈ｉｎｐｕｔ〉要素を有するフォームをレンダリングすることを担当する。

フォーム処理モジュール５０が、フォームおよび送信スクリーンを処理するために提供されている。フォーム処理モジュール５０は、ユーザの入力を受け取ってチェックし、その入力を変数に割り当て、ＴＭＬの送信を構築する。データは、ユーザによって意図的に消去されない限り、ＨＴＴＰサーバ（２０、２４）へ送信されて確認応答が受け取られるまで、消去されない。データは、消去されるまで、端末の永続的なメモリ内に保存することができ、これによって、端末１０のスイッチがオフにされた場合でも失われることはない。このことはまた、顧客のドメイン内のホストにアクセスできない場合でもフォームを処理することができるということを意味する。したがって、通信が失敗しても、端末１０やゲートウェイホスト１９がフリーズする結果にはならない。

マイクロブラウザ１２のメモリ内に保持されているポストは、印刷すること、キャンセルすること、あるいは（マイクロブラウザ１２がホストとの間に形成する次の接続において、またはエンドユーザの命令に応じて）脇にプールしておくことができる。これらの機能は、パスワードで保護されたマネージャーのメニューを介して、スーパーバイザーによって保護されている。これらのパスワードは、それぞれの端末ごとにランダムに作成され、（以降で説明するように）接続証明書と共にデータベース内のゲートウェイホスト１９の中に保存される。

カードパーサモジュール５２は、カードの磁気トラックを解析すること、およびＩＣＣ（スマート）カードとの対話を解釈することを担当する。カードパーサモジュールは、端末の自動設定中に設定することができる。このモジュールのオペレーションについては、以降でさらに詳しく説明する。

ゲートウェイホスト１９は、Ｊａｖａホストアプリケーションであり、ゲートウェイ実行可能アプリケーション１４、ＨＴＴＰプロキシ１８、およびコンバータ１６を備える。ゲートウェイ実行可能アプリケーション１４は、ネットワークに導入される新しい端末ごとに（さらなる端末の認証のために使用される）一意の端末パスワードを発行すること、それらの端末にルート証明書を提供すること、および（１つまたは複数の）端末および（１つまたは複数の）ＨＴＴＰサーバのそれぞれを相互に認証することを含む機能を提供する。

ゲートウェイ実行可能アプリケーション１４は、コンバータ１６と共に、端末１０からの、および逆方向の双方向の対話において１つの要求を処理するのに最大で１００ミリ秒を要する。ゲートウェイホスト１９は、時間の９９．９％にわたって利用することができる十分に堅固なものであることを目標としており、つまり、年間のダウンタイムは約９時間のみとなるはずである。

ＨＴＴＰプロキシ１８は、端末１０のために、ＴＭＬアプリケーションおよび設定サービスを実行するＨＴＴＰサーバ２０、２４へのＨＴＴＰＳ接続またはＨＴＴＰ接続を確立することを含む機能を提供する。

コンバータ１６は、接続可能なコンポーネントであり、ＨＴＴＰおよびＸＭＬデータをテキストからバイナリーフォーマットへ、およびその逆へ変換し、イメージを標準的なビットマップから、端末１０によってレンダリングできるフォーマットへ変換する。

ゲートウェイホスト１９はまた、端末要求の処理効率を高めるために、およびページを最新に維持するために、（データベース５４内の）静的なＴＭＬページおよび設定データをキャッシュに格納することを提供する。

図３は、ゲートウェイホストの構造のさらなる詳細を示している。ゲートウェイ実行可能アプリケーション１４は、ＴＣＰ／ＩＰリスナーとして示されている。ゲートウェイ実行可能アプリケーション１４は、それぞれの端末セッションを、着信するＴＣＰ／ＩＰ接続ごとに別々のスレッド（ＳＴＰセッション）内で処理する。ＳＴＰ要求５６は、コンバータ１６へ転送され、ＨＴＴＰプロキシ１８を介してサーバ２０、２４のうちの一方へ回送される。

ゲートウェイ実行可能アプリケーション１４は、ＳＴＰパケット５６へとラップされるＨＴＴＰ要求５８ごとにコンバータ１６を呼び出す。上述のように、コンバータは、ＨＴＴＰおよびＸＭＬデータをテキストからバイナリーフォーマットへ、およびその逆へ変換する。しかしコンバータ１６は、実際には複数の「サブコンバータ」を備え、これらのサブコンバータとしては、バイナリーＨＴＴＰコンバータ、（コードテーブルを用いてパラメータ化することができる）一般的なバイナリーＸＭＬコンバータ、（特定のバージョンのＴＭＬのための一般的なＸＭＬコンバータのパラメータ化である）ＴＭＬコンバータ、イメージコンバータ、およびウェブサービスＲＰＣコンバータが含まれる。

どのコンバータが呼び出されるかは、ＳＴＰ要求５６からどのＢＨＴＴＰ要求５８が抽出されるかによる。ＳＴＰ要求に関しては、コンバータは、それぞれの抽出されたＢＨＴＴＰ要求のコンテンツのタイプを判断しなければならない。端末１０から要求が出された際には、すべての呼び出しに関してＴＭＬコンバータを使用することができる。ただし、ウェブサービスの呼び出しであると識別されたものは除く。その場合には、ウェブサービスサブコンバータが使用される。しかしＳＴＰ応答に関しては、コンテンツのタイプは、多くの異なるフォーマットとすることができ、応答がパッケージされる前に、利用可能なサブコンバータのいずれかの中から適切なサブコンバータを決定しなければならない。ＳＴＰ要求５６の場合とまったく同様に、ＳＴＰ応答は、複数のＢＨＴＴＰ応答を含むことができる。

ゲートウェイホスト１９内で使用されるサブコンポーネントが、図４に示されており、この図４では、同様のコンポーネントは、図１に示されているのと同様の参照番号を用いて示されている。

ゲートウェイホスト１９のコンポーネントは、安全なイントラネット内で展開される。しかしシステムのその他のコンポーネントは、イントラネットの外に配置することができ、したがって、ゲートウェイホスト１９とこれらの部品との間におけるすべての通信チャネルは、注意深く保護されなければならない。この目的から、プロトコルスタックを使用することができ、その場合には、端末１０は、要求５６を送信するためにバイナリーＨＴＴＰを使用する。より低いレベルの要求は、ＳＴＰ内にパックされ、ＴＬＳトンネリングを用いてＴＣＰ／ＩＰを介して転送される。初期設定中には、端末１０は、ＢＨＴＴＰおよびＩＳＴＰを伴わずに最も低い安全なトンネリングレベルのみを使用する。ＴＬＳセッションを確立する際には、ゲートウェイホスト１９は、認証のために自分のセキュリティー証明書を端末１０へ送信するという点に留意されたい。適切な保護手段のさらなる詳細については、以降で提示する。

次いでゲートウェイホスト１９のオペレーションについて、さらに詳しく説明する。

ゲートウェイホスト１９用の設定パラメータは、ゲートウェイ実行可能アプリケーション１４自体に関連し、すべての接続されている端末１０にとって共通である。設定パラメータは、ゲートウェイホスト１９が起動した際にロードされる設定ファイルから、またはウェブＧＵＩ ６０（図１を参照されたい）などのリモートインターフェースから得ることができ、そうしたリモートインターフェースからは、ゲートウェイホスト１９は、初期設定のうちのいくつかを変更する命令を受け取ることができる。共通の設定が変更された場合には、それらの設定は、変更が行われた後に接続されている端末１０に対してのみ有効となる。

新しい端末１０の初期設定を求める要求は、初期設定ポート６４を介して（別のスレッド内で）処理される。それぞれの端末は、関連付けられている一意のＴＩＤ（ｔｅｒｍｉｎａｌ ＩＤ）を有し、このＴＩＤは、たとえば８桁の文字列とすることができる。ＴＩＤは、初期設定の要求と共にゲートウェイ実行可能アプリケーション１４へ送信される。次いでゲートウェイ実行可能アプリケーション１４は、要求を行っている端末１０の信用証明書を確認するために、提供された端末１０のＴＩＤを自分のレコードと照合する。確認された場合には、一意のパスワードが作成され、そのパスワードは、（以降で説明する）ルート証明書と共に端末１０へ送信される。そしてデータベース６６が更新されて、端末１０が、起動しているものとして記録される。

ゲートウェイ実行可能アプリケーション１４は、初期設定された端末１０からの要求を、データ交換ポート６２を介してリッスンする。端末セッションは、データ交換ポート６２に対するあらゆる端末要求によって開始し、別個のスレッド内で実行される。それぞれのセッションは、端末を認証するステップと、端末の要求をＨＴＴＰサーバ２０、２４へ送信するステップと、ＨＴＴＰサーバ２０、２４から端末へ応答を返信するステップとを含む。セッションアクティビティーを記録することもできる。

端末のＴＩＤは、要求と共にゲートウェイ実行可能アプリケーション１４へ送信される。次いでゲートウェイ実行可能アプリケーション１４は、そのＴＩＤに関連付けられているパスワード上で暗号化アルゴリズムの複数の反復を実行する。使用される暗号化アルゴリズムは、ａｒｃｆｏｕｒアルゴリズムであることが好ましく、４回の反復が使用されることが好ましい。しかし、その他のアルゴリズムおよび／または異なる回数の反復を採用することもできるということが理解できるであろう。結果として生じる答えは、対照の答えに相当する。そして端末１０は、同じ暗号化アルゴリズムの同じ回数の反復を実行して、これをゲートウェイ実行可能アプリケーション１４への応答として送信するように要求される。それらの応答が一致しない場合には、ゲートウェイ実行可能アプリケーション１４は、接続を閉じ、それらの応答が一致する場合には、新しいセッション（「ＳＴＰセッション」）が作成され、別個のスレッドに割り当てられる。

端末１０の要求をＨＴＴＰサーバ２０、２４へ送信するいずれかの段階において、またはＨＴＴＰサーバ２０、２４から端末１０へ応答を送信する際にエラーが発生した場合には、これらのエラーは、応答パケットに含めて報告され、またデータベース６６内にも記録される。要求の時点であまりにも多くのスレッドがゲートウェイ実行可能アプリケーション１４によって処理されている場合には、タイムアウトまたは通信障害が生じた場合には、またはコンバータ１６が要求を処理することができない場合には、たとえば障害レポートを作成することができる。ＨＴＴＰサーバ２０、２４とウェブサービスホストとの間における接続が首尾よく完了していない場合には、ＳＴＰ接続は、それでもやはり成功しているものとみなされるが、応答パッケージには警告メッセージが含まれる。

障害レポートおよび警告メッセージは、テキストまたはエラーコードを含み、このエラーコードは、障害が発生した場所および障害の原因に関する情報を提供する。

それぞれのセッションに関連する情報は、共通のロギングインターフェースを通じてデータベース６６内に、および端末１０のメモリ内に記録することができる。記録される情報は、たとえばＳＴＰセッションおよびその他のセッションの開始時刻および終了時刻、端末の情報、使用されているポートの詳細、ならびにＨＴＴＰ要求の詳細に関連するものとすることができる。必要に応じて、その他の任意の適切なロギング情報を収集して、診断の目的で使用することができるということは明らかであろう。

サーバのオペレーションは、「通常」の状況において、または「緊急」の状況において停止することができ、「通常」の状況では、ゲートウェイホスト１９がシャットダウンする前に、システム全体におけるすべての要求が処理され、「緊急」の状況では、ＳＴＰ要求、すなわち端末１０とゲートウェイ実行可能アプリケーション１４との間における要求のみが完了される。

リモート管理は、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）を介してリモートインターフェース６０を通じて利用することができる。リモート管理を介して利用することができる機能としては、（使用されているポート、ＳＴＰセッションのパラメータ（タイムアウト）、ＨＴＴＰプロキシホスト、およびポートの情報を含む）ゲートウェイホスト１９の設定パラメータを入手および変更すること、ゲートウェイホスト１９のアクティビティーの統計データを入手すること、ならびにゲートウェイホスト１９を停止することが含まれる。

図５は、上述のシステムコンポーネントの物理的な展開の一例を示しており、同様のコンポーネントは、これまでの図において見られたのと同様の参照番号を用いて識別される。これらのコンポーネントは、ＴＣＰ／ＩＰを介して相互に通信し、セキュリティーメカニズムを含む残りの機能は、プロトコルスタック内のＴＣＰ／ＩＰ層の上に構築されている。

ゲートウェイホスト１９は、以降でさらに詳しく説明するように、ゲートウェイ実行可能アプリケーション１４を介して認証当局７０と通信する。第１のＨＴＴＰサーバ２０およびＴＭＬアプリケーション２２は、双方ともＴＭＬアプリケーションホスト７２の一部であり、第２のサーバ２４および設定サービス２６は、双方ともウェブサービスホスト７４の一部である。図５は、ウェブインターフェースホスト、データベースサーバなどのような補助的なコンポーネントを示していないという点に留意されたい。

図５に示されている実装形態は、特定の実装例のサブセクションにすぎないという点に留意されたい。このシステムのコンポーネントは、より多くの数のコンピュータまたはより少ない数のコンピュータに分散することができる。マイクロブラウザ１２でさえ、実際に端末内で実行するのではなく、端末シミュレータを使用してエミュレートすることができる。

このフレームワークを展開する際に考慮に入れるべき最も重要な関心事は、セキュリティーである。保護されたネットワークプロトコルを使用していくつかのコンポーネントを接続することができない場合には（たとえば、ゲートウェイ実行可能アプリケーション１４およびＨＴＴＰプロキシ１８が、ＨＴＴＰＳではなくＨＴＴＰを使用して通信する場合には）、これらのコンポーネントを私的なネットワーク内に、および共通のファイアウォールの後ろに配置して、システムに対する外部の攻撃のリスクを少なくすべきである。

上述のように、カードパーサ５２（マイクロブラウザ１２のコンポーネント）は、磁気カードトラックを解析すること、およびスマートカードと対話することを担当する。次いで、このパーサ５２のオペレーションについて、さらに詳しく説明する。

カードパーサ５２は、端末１０の一部であるカードリーダからのデータを解釈するためにマイクロブラウザ１２上で実行されるＴＭＬアプリケーション用のシンプルかつ一般的な手段を提供する。パーサ５２は、ライブラリ８０（図２を参照されたい）と、カードからデータを読み取って解析する機能と、カードおよびカード保有者を確認する機能と、リスクマネージメントポリシーを実施する機能とを利用する。パーサ５２は、端末の自動設定中に設定することもできる。

カードパーサ５２は、マイクロブラウザ上で実行されるＴＭＬアプリケーション用に１つのインターフェース方法のみを提供し、これは、単一の文字列パラメータのみを有する。この文字列は通常、単なるコマンドであり、パーサ５２によって実行されることになる。その他のすべての情報は、ＴＭＬで定義されている変数によってパーサ５２に渡されたり、パーサ５２から入手されたりする。

磁気カードの処理が、図６に示されている。実質的に、磁気カードを処理している間に実行されるステップは、標準的なものである。しかし、本発明の一実施形態に従って実装される電子金融取引システムがこの公知のタスクを実行する方法は、非標準的なものであり、次いでこれについて説明する。

マイクロブラウザ１２上で実行されるＴＭＬアプリケーションは、〈ｃａｒｄ〉要素を有する〈ｔｆｏｒｍ〉スクリーンを介してパーサの機能を利用することができる。呼び出されるパーサの名前は、これらの要素のｐａｒｓｅｒ属性内で指定され、パラメータは、ｐａｒｓｅｒ＿ｐａｒａｍｓ属性内で指定される。

解析を完了することができない場合には、パーサ５２は、ｂａｄｄａｔａ＿ｒｅａｓｏｎ変数を記入し、〈ｂａｄｄａｔａ〉要素内で指定されたメッセージがレンダリングされ、これによって、障害の原因に関するユーザへのフィードバックが提供される。

使用中には、ＴＭＬアプリケーションは、まずパーサ５２を呼び出して、カードが挿入され、コンテキストが確立され、カードのデータが読み取られ、カードそのものが確認されるのを待つ。この後、ＴＭＬアプリケーションは、パーサによって記入された変数を分析し、必要に応じて、取引に対応する追加のデータをユーザに要求し、再びパーサ５２を呼び出すことができる。さらなる呼び出し中に、パーサ５２は、リスクマネージメントプロセスを実行し、カードとのさらなる対話を実行するなどして、その他のＴＭＬ変数を記入することができる。さらに、たとえばＩＣＣ（スマートカード）のＰＩＮを確認することなど、カードに対する何らかの特定のアクションを実行するようにパーサ５２に要求することができる。

パーサ５２は、処理中の取引に関連するコンテキストをサポートするように設定することができ、使用されるそれぞれの新しいカードごとにこのコンテキストを見直すことになる。

さらにパーサ５２は、すべての取引に関する統計データ（たとえば、リスクマネージメントのためのオフライン取引の現時点での数量）をサポートすることができる。ＨＴＴＰクライアント３８は、延期されている送信がサーバの限度までプールされた場合には、すべてのパーサ（４０、４４、５２）に知らせて、それらのパーサは、自分のカウンタをリセットすることができる。

カードパーサ５２は、実際には、異なるタイプのカードを解析するための複数の「サブパーサ」を備える。これらのサブパーサとしては、磁気カードパーサ、ＩＣＣ ＥＭＶパーサ、およびＩＣＣ初期設定パーサが含まれる。

磁気カードパーサは、標準的なＩＳＯトラックを有するカードを取り扱う。磁気カードパーサは、カードからトラックを読み取り、それらを解析し、カードの番号およびカードの有効期限を確認することができる。さらに磁気カードパーサは、スキームごとの小売信用限度額（すなわち、どの取引を承認しなければならないかを判断するために使用される特定の限度値）に基づいてリスクマネージメントプロセスを実行する。この目的から、磁気カードパーサは、承認されたオフラインの支払い取引を追跡把握する。

磁気カードパーサは、磁気カードデータを解析するためによく知られている変数を読み取り、更新する。さらに、文字列変数ｃａｒｄ＿ｐａｒｓｅｒが定義される。磁気カードが読み取られる際に、この変数は、パーサ５２によって「ｍａｇ」と記入される。また、整数変数ｃａｒｄ＿ｉｎｐｕｔ＿ｍｏｄｅを定義することができる。たとえば整数値１は、磁気カードを通すことを表すことができ、２は、ＩＣＣを使用することを表すことができ、３は、端末のキーボードを使用してカードの詳細を入力することを表すことができる。コマンド「ｒｅａｄ＿ｄａｔａ」を用いてパーサ５２が呼び出される場合には、この変数は、１に設定されることになる。コマンド「ｒｉｓｋ＿ｍｇｍｔ」を用いてパーサ５２が呼び出される場合には、この変数がチェックされ、この変数が３であるならば、カードの番号および有効期限が確認され、レシート上に印刷されることになるカード番号の一部を表す変数が記入される。

これらの変数の機能を変更することなく、これらの変数に与えられる名前、ならびに可能な値の数および割り当てを変更することができるということが理解できるであろう。

パーサ５２は、ＴＭＬアプリケーションから見える２つのコマンド、「ｒｅａｄ＿ｄａｔａ」コマンド９０および「ｒｉｓｋ＿ｍｇｍｔ」コマンド９２をサポートする。「ｒｅａｄ＿ｄａｔａ」コマンド９０の最中に、パーサは、カードからＩＳＯトラックを読み取り、それらを解析して、変数「ｃａｒｄ＿^＊」および「ＩＳＯ^＊」を記入し、これらの変数「ｃａｒｄ＿^＊」および「ＩＳＯ^＊」は、カードの詳細、およびカードのＩＳＯトラック上に保持されている情報を提供する。さらにパーサは、カードの番号および有効期限を確認し、必要な場合には、「不良データ」の条件を作成する。

読み取りコマンド９０を発行した後、ＴＭＬアプリケーションは、取引の数量および取引のタイプについて業者に尋ねる。この情報は、オンライン処理、オフライン処理、あるいは取引の口頭確認に関する意思決定を行う上で必要となる。変数ｖｅｒｄｉｃｔが、取引の処理モードを、すなわちオフラインかオンラインかを割り当てるＴＭＬアプリケーションによって記入されるか、または拒否される。

カードの詳細が、端末のキーボードを使用して手動で入力される場合には、「ｒｅａｄ＿ｄａｔａ」コマンド９０は発行されず、ＴＭＬアプリケーションは、変数ｃａｒｄ＿ｉｎｐｕｔ＿ｍｏｄｅを３に設定する。

「ｒｉｓｋ＿ｍｇｍｔ」コマンド９２は、リスクマネージメントプロセスを実行するようパーサに要求するためにＴＭＬアプリケーションによって使用される。このプロセス中に、パーサ５２は、取引の数量およびタイプ、カードのスキームおよび発行者、ならびにその内部の統計データを分析し、ＴＭＬアプリケーションによって定義された推奨を考慮に入れて意思決定を行う。たとえば、手動で入力されたカードの詳細が正しくない場合には、取引を拒否することができる。拒否の決定および原因が、ＴＭＬアプリケーションに戻される。

「ｒｉｓｋ＿ｍｇｍｔ」コマンド９２は、オンラインでのポスティングを試みている最中にデータのポスティングが失敗した場合にも使用される。パーサ５２は、ＨＴＴＰクライアント３８によって記入される「ｅｃｏｎｎ＿ｒｅａｓｏｎ」変数９４を介して、この状況を見つけ出す。リスクマネージメントプロセスが再び実行され、設定されているポリシーを使用して、オフラインの処理が承認されるか、または取引がキャンセルされる。

ＩＣＣ ＥＭＶパーサは、ＥＭＶ支払いアプリケーションをサポートするＩＣＣ（スマート）カードと対話することを意図している。ＩＣＣ ＥＭＶパーサは、アプリケーションの選択と、静的および動的なオフラインでのデータ認証と、カード機能の発見と、オフラインでのＰＩＮの確認と、ＥＭＶリスクマネージメントと、ＴＣ、ＡＡＣ、ＡＲＱＣ、および（ＡＰＡＣＳなどの）選択された電子金融取引プロトコルのもとで行われる取引に必要なその他のデータの作成と、発行者スクリプトの実行と、結果の検索とを担当する。

ＩＣＣ ＥＭＶパーサは、ＩＣＣデータを解釈するためによく知られている変数を読み取り、更新する。さらに、磁気カードパーサによって使用されるのと同様の文字列変数ｃａｒｄ＿ｐａｒｓｅｒおよび整数変数ｃａｒｄ＿ｉｎｐｕｔ＿ｍｏｄｅが、同様に使用される。上述の例に従うと、整数変数ｃａｒｄ＿ｉｎｐｕｔ＿ｍｏｄｅは２に設定され、文字列変数ｃａｒｄ＿ｐａｒｓｅｒは、パーサによって「ｉｃｃ−ｅｍｖ」と記入される。

ＩＣＣ ＥＭＶパーサのオペレーションが、図７に示されている。実質的に、ＩＣＣ（スマートカード）を処理する際に実行されるステップは、標準的なものである。しかし、本発明の一実施形態に従って実装される電子金融取引システムがこの公知のタスクを実行する方法は、非標準的なものであり、次いでこれについて説明する。

ＴＭＬアプリケーションによってＩＣＣ ＥＭＶカードパーサに発行される第１のコマンドは、ＩＣＣアプリケーションを初期設定するために使用される「ｉｎｉｔ＿ａｐｐ」コマンド１００である。このコマンドの処理中に、パーサは、アプリケーションの選択を実行し、アプリケーションのデータを読み取り、静的なまたは動的なオフラインでのデータ認証を実行する。その結果、パーサは、カードおよびＩＣＣアプリケーションの詳細に関連する適切なＴＭＬ変数を記入する。

さらなるコマンドもＩＣＣと対話するため、カードは、取引の処理中はカードリーダ内に挿入されたままとなる。

初期設定の後、ＴＭＬアプリケーションは、カード保有者を確認しなければならない。ＴＭＬアプリケーションは、取引のデータ（数量および取引のタイプ）について業者に尋ね、パーサにＩＣＣからカード保有者の確認方法のリストを検索させるコマンドを発行し、これらの方法を「ｃｖｍ」変数内に保存する。たとえば、可能なカード確認方法としては、ホストによって実行されるオンラインでのＰＩＮの確認、ＩＣＣカードそのものによって実行されるＰＩＮの確認、業者による署名の確認を伴うＩＣＣによるＰＩＮの確認、あるいはカード保有者の確認がまったく必要とされない場合が含まれる。さらに、オフラインでのＰＩＮの確認がＩＣＣによってサポートされる場合には、ＰＩＮの暗号化のために使用されるキーが、パーサによって検索され、専用の変数内に保存される。生体認証によるＩＤ確認方法をサポートすることもできる。

そしてＴＭＬアプリケーションは、カードの確認結果の変数を記入し、この変数は、成功を確認するか、またはこの変数を、失敗のさまざまな原因を提供する複数の異なるオプションに設定することができる。

署名のチェックを含む方法が選択されると、ＴＭＬアプリケーションは、署名の要求を伴うレシートを印刷するための〈ｐｒｉｎｔ〉スクリーンへと切り替わる。そして業者は、カード保有者の署名を確認するよう要求される。署名が不良である場合には、パーサは、次なるカード保有者確認方法について尋ねられる。

次いでリスクマネージメントプロセスが実行され、これは、磁気カードパーサのリスクマネージメントプロセスと同様の方法で、取引をオンラインで実行するか、またはオフラインで実行するか、あるいは取引を拒否するかを、設定パラメータに基づいて決定する。ＩＣＣ ＥＭＶパーサの特定の例においては、ＩＣＣの取引の数および暗号化の詳細に関連する変数、ならびにＩＣＣおよび確認の結果に関するデータが、ゲートウェイホスト１９にポストされる。

リスクマネージメントプロセスからの決定が、オンラインでのデータ送信を行うことである場合には、ＴＭアプリケーションは、承認ステップを実行し、ＩＣＣからＡＡＣ（ａｐｐｌｉｃａｔｉｏｎ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｒｙｐｔｏｇｒａｐｈ）およびＴＣ（ｔｒａｎｓａｃｔｉｏｎ ｃｏｕｎｔｅｒ）を入手する。この承認の結果が成功として確認されると、カードは無効になる。

別個のパーサがまた、何の指定もない端末の初期設定中にＩＣＣと対話するために提供される。

このシステムは、端末シミュレータ１１０（図３を参照されたい）の使用に対応することができる。これは、双方のＴＭＬアプリケーションの開発者およびシステムの開発者に、デモの作成およびＴＭＬアプリケーションのデバッグのための有用なツールを提供する。ＴＭＬアプリケーションの開発者の視点からは、このシミュレータは、ロードされた端末マイクロブラウザアプリケーション３２を有する端末１０のように見える。このシミュレータは、実行可能なＷｉｎｄｏｗｓファイルとして実行して、通常の端末と同じ方法でゲートウェイホスト１９と対話することができる。システムの開発者の視点からは、シミュレータ１１０をライブラリとして見ることができ、このライブラリをマイクロブラウザアプリケーションコードにリンクさせることができ、したがってＰＣプラットフォーム上でのマイクロブラウザのデバッグが可能となり、また実験をその後の開発に役立てることができる。

シミュレータ１１０は、端末１０のアーキテクチャーやオペレーティングシステムをエミュレートしない。シミュレータ１１０は、（端末の周辺機器との対話、暗号化、イベントおよびメッセージの処理などを担当する）マイクロブラウザによって使用されるＯＳライブラリをエミュレートすること、ならびに端末マイクロブラウザアプリケーション用のランタイム環境（すなわちアプリケーションマネージャー）を実装することを求められるだけである。

ＴＭＬは、ＸＭＬベースの言語であり、いくつかの機能をＸＨＴＭＬと、およびＷＡＰ ＷＭＬと共有する。ＴＭＬは、端末にロードされる静的および動的な双方のコンテンツ、ならびに端末によってＨＴＴＰサーバにポストされるデータを定義するために使用される。

ＴＭＬアプリケーションは、いくつかのページを備えることができる。通常は、ルートページが存在し、そのルートページから、その他のすべてのページが、標準なＸＨＴＭＬの〈ｌｉｎｋ〉要素を使用して参照される。静的なページを事前にロードすることができ、そしてこれによって、静的な情報を参照するＵＲＩが現れるたびに端末がホストへ接続する必要はなくなる。ＴＭＬページをレンダリングするために使用されるＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）の仕様が、あらゆるページから参照される。デフォルト設定によって、内蔵されたＣＳＳが使用される。特定のページ上に現れるイメージもまた、〈ｌｉｎｋ〉要素を使用して参照される。

スタイルの指示およびスタイルのグループ分けの〈ｓｐａｎ〉要素および〈ｄｉｖ〉要素は、ＴＭＬにおいては認められないことが好ましい。要素に関するスタイルは、「ｃｌａｓｓ」属性および「ｉｄ」属性を使用して指定することができる。スクリプトもまた、サポートされないことが好ましい。

それぞれのＴＭＬページは、いくつかのスクリーンまたはブラウザ処理ユニットから構成される。あらゆるスクリーンはＵＲＩを有し、このＵＲＩは、ＴＭＬページのＵＲＩと、スクリーン識別子とから構築されている。複数のスクリーンを単一のＴＭＬページへとラップすることができるため、スクリーンは、ＴＭＬアプリケーションを端末にダウンロードするのをスピードアップするために導入される。さらに、それぞれのページは、そのページ内で定義されるローカル変数の範囲を制限する。

複数の異なるスクリーンタイプを使用することができ、これらのスクリーンタイプとしては、ディスプレイスクリーン、プリントスクリーン、メッセージスクリーン、フォームスクリーン、および関数呼び出しスクリーンを含むことができる。

ディスプレイスクリーンは、通常のＨＴＭＬページとみなすことができる。ディスプレイスクリーンは、ハイパーリンクを含むことができ、スクロールアップおよびスクロールダウンを行うことができる。ディスプレイスクリーンは、端末ディスプレイ上に常にレンダリングされている。

プリントスクリーンのコンテンツは、やはりＨＴＭＬと同様であるが、内蔵された端末プリンタを使用して印刷される。印刷した後には、マイクロブラウザは、指定されたＵＲＩへと切り替わる。ハイパーリンクは無視される。

メッセージスクリーンは、エラーメッセージ、警告メッセージ、あるいは成功メッセージをレンダリングするために使用される。メッセージは、指定された秒数にわたって端末ディスプレイ上にレンダリングされる。その時間が経過すると、マイクロブラウザは、指定されたＵＲＩへと切り替わる。ユーザがキーを押すと、マイクロブラウザ１２は、すぐに次のスクリーンへと切り替わる。

端末フォーム（または送信）スクリーンは、ユーザ入力を収集し、処理し、送信するために使用される。これらについては、以降でさらに詳しく説明する。

関数呼び出しスクリーンは、端末のＣ関数を名指しで呼び出すために使用される。このオプションは、端末やマイクロブラウザの設定のためのメニューを含むＴＭＬページにとって必要である。

ＴＭＬは、多数のブロックレベルおよびテキストレベルの要素を特徴とし、これらの要素は、ＸＨＴＭＬの要素と類似している。これらの要素のほとんどは、ＸＨＴＭＬの場合と同じシンタックスおよびセマンティクスを有するが、いくつかの重要な制約および機能強化がある。

たとえば、ＨＴＭＬ４のフレームは、ＴＭＬにおいてはサポートされないことが好ましい。また、〈ｉｎｐｕｔ〉要素に関してＨＴＭＬ４において使用される属性（すなわちｔｅｘｔ、ｐａｓｓｗｏｒｄ、ｃｈｅｃｋｂｏｘ、ｒａｄｉｏ、ｓｕｂｍｉｔ、ｒｅｓｅｔ、ｂｕｔｔｏｎ）に加えて、入力デバイス、すなわち通常の端末キーパッド、またはピンパッドを指定するために、さらなる属性が認められる。

ＴＭＬ変数は、（日付および時刻のように）事前に定義するか、またはユーザによって宣言することができる。変数の範囲は、単一のＴＭＬページに制限するか、または全体にわたるものとして定義することができる。変数のタイプは、文字列、日付、整数、あいまいな値（バイナリーデータ）のうちの任意のものとして定義することができる。

ＴＭＬ変数は、マイクロブラウザが新しいスクリーンへと切り替わった際には、〈ｓｅｔｖａｒ〉要素を使用して自分の値を変更することができる。この要素はまた、ユーザ入力の情報を変数に割り当てるためにも使用される。端末ディスプレイ上でレンダリングを行うための、あるいは内蔵されたプリンタを使用して印刷を行うためのＴＭＬスクリーンは、変数への参照を含むことができる。レンダリングまたは印刷中に、参照は、対応する変数の値に置き換えられる。

端末は、それらの変数の値をＨＴＴＰサーバへ送信することができ、ＨＴＴＰサーバでは、それらの変数の値が、ＴＭＬアプリケーションによって処理される。

変数はまた、システムおよびマイクロブラウザの設定を保存するために使用される。ＴＭＬアプリケーションは、マイクロブラウザの設定を更新するために変数の値を変更することができる。

ＴＭＬ要素〈ｔｆｏｒｍ〉が、ユーザによって入力できるデータを記述するために導入されている。ユーザは、磁気カードを通すこと、スマート（ＩＣＣ）カードを挿入すること、ピンパッドキーボードを使用すること、あるいは端末のキーボードを使用することによって、データを入力することができる。

ユーザによって入力されたテキストデータは、ＸＨＴＭＬの〈ｉｎｐｕｔ〉要素および〈ｔｅｘｔａｒｅａ〉要素を用いてマークアップされる。キーボードの入力をマークアップするために使用される要素は常に、簡略化されたＸＨＴＭＬの〈ｆｏｒｍ〉要素へとラップされる。これによって、いくつかの〈ｉｎｐｕｔ〉要素、〈ｔｅｘｔａｒｅａ〉要素、および〈ｎｕｍｂｅｒ〉要素を単一のフォーム内で使用して、そのフォームをその他のＸＨＴＭＬ要素（テーブル、リストなど）の内部に配置することができる。

入力されたデータは、事前に定義された（たとえば「ｐｉｎ」、「カード保有者」などの）変数、またはユーザによって定義された変数に割り当てられる。ＴＭＬは、入力されたデータの評価（これは、最大値／最小値または文字列の長さの照合を含むことができる）、ならびにまたカードの番号および／または有効期限を含むカードの詳細の確認を可能とする。

データが正しくない場合には、端末は、〈ｂａｄｄａｔａ〉要素によって指定されるエラーメッセージをレンダリングし、フォームスクリーンへと切り替わる。

フォームの処理中にユーザによって入力されたデータは、ＨＴＴＰサーバへすぐに送信されるのではなく、送信スクリーンを使用してサーバへ送信される。送信スクリーンは、ＨＴＴＰサーバへ送信される変数の値（これらは、複数の以前のスクリーン内で収集された可能性がある）を指定する。

送信は、オフラインまたはオンラインのいずれかで行うことができる。オンラインでの送信は、端末１０がゲートウェイホスト１９へすぐに接続してデータを送信することを前提としている。オフラインでの送信に関しては、端末１０は、対応する〈ｔｍｌｐｏｓｔ〉要素を構築し、それを端末の永続的なメモリ内に保存する。延期された送信は、次の端末／ゲートウェイ実行可能アプリケーションのセッション中にゲートウェイホスト１９へ転送される。

すべての送信スクリーンは、送信用の宛先ＵＲＩを指定する。端末１０によって送信されたデータは、ゲートウェイホスト１９によって処理されてから、ＨＴＴＰサーバにポストされ、そこでＴＭＬアプリケーションによって処理される。次いでＴＭＬアプリケーションは、受け取ったデータを確認し、応答を作成する。

送信要素はまた、首尾よく送信できた際にマイクロブラウザの切り替わり先となるコード内の場所を指定するＵＲＩを含む。オンラインでの送信に関しては、送信が失敗した場合の切り替わり先のＵＲＩも指定される。さらにＴＭＬアプリケーションは、マイクロブラウザが別の指定されたＵＲＩへ切り替わるようにする「他を参照されたい」旨の応答コードを有する応答を作成するか、または動的なＴＭＬコンテンツを有する応答を作成することができる（オフラインでの送信の場合には、このような応答は無視される）。ＴＭＬフォームは、グラフィカルディスプレイ、キーパッド、内蔵されたプリンタ、ピンパッド、磁気カードリーダ、スマートカードリーダ、およびオフラインでの安全なＰＩＮの入力を含む端末デバイスの機能をサポートする。さまざまなフォーマットのスマートカードおよびさまざまなモードの解析磁気トラックをサポートするために、たとえば、さまざまなタイプのスマートカード上で見つかるさまざまなタイプのデータを考慮するためにさまざまな解析ルーチンの接続を可能にするＴＭＬタグが存在する。

複数のＴＭＬアプリケーションを永続的な端末メモリ内に動的に保存することが可能である。ＴＭＬアプリケーションは、そのバイナリーフォームで、リブート後も端末メモリ内に存続する。ＴＭＬアプリケーションはまた、ＴＭＬマイクロブラウザ内でキャッシュに格納される。マイクロブラウザは、キャッシュに格納されたＴＭＬページがＨＴＴＰリソースコンテナ内で変更された場合には、またはそのＴＭＬページの有効期限が切れた場合には、そのＴＭＬページを自動的に再びロードする。ＴＭＬマイクロブラウザは、データを送信するために、または動的なＴＭＬコンテンツを入手するためにゲートウェイホスト１９に接続するたびに、キャッシュに格納された静的なコンテンツを再びロードする。

キャッシュに格納されない、または再び使用されないすべてのページには、属性「ｎｏ−ｃａｃｈｅ」を用いてマークが付けられる。そのようなページは、マイクロブラウザ１２が次のページの処理を開始する直前の時点で、端末メモリから削除される。属性「ｎｏ−ｃａｃｈｅ」は、ＨＴＴＰの「ｎｏ−ｃａｃｈｅ」指示に非常に類似している。

同様に、キャッシュに格納されるページには、ゲートウェイホスト１９によって作成される「ＥＴａｇ」ＨＴＴＰヘッダが添付される。

ゲートウェイホスト１９は、ＴＭＬページをキャッシュに格納すること、および端末にロードされたすべてのリソース（作成されたＥ−ｔａｇを含む）のキャッシュを最新の状態に維持することを担当する。端末１０は、ゲートウェイホスト１９に接続するたびに、端末メモリ内に保存されていてキャッシュへ移すことができるリソースごとにＥＴａｇを伴う条件付きのＨＴＴＰ ＧＥＴ要求を送信する。ゲートウェイホスト１９は、そのリソースが変更されていない旨を回答するか、またはそのリソースの新しいバージョンを送信することができる。

管理者権限を有するユーザは、端末内でキャッシュに格納されているすべてのリソースを削除することができる。

ＴＭＬソフトウェアのホスト部分は、ＵＲＩによって識別されるＪａｖａアプリケーションのセットに相当する。これらのＵＲＩは、送信要素にとっての宛先として指定される。ＨＴＴＰサーバは、ゲートウェイホスト１９を介して端末から受け取った指定されたポートへの要求を処理するためにＪａｖａアプリケーションを呼び出す。これらのアプリケーションは、それらの要求を処理し、対応するＨＴＴＰ応答を作成し、それらのＨＴＴＰ応答は、端末１０へ戻される。

それらの要求を処理している間、ＴＭＬアプリケーションは、その他のホストと（たとえば、ＡＰＡＣＳ ３０の規格などの適切な電子金融取引プロトコルを使用して、取得者のホストと）対話することができる。

基本的なＴＭＬ支払いアプリケーション２２は、独自仕様のＴＭＬアプリケーションを開発するための基盤として使用することができるシステムのコンポーネントである。このアプリケーションは、いくつかの（２〜３の）ＴＭＬページと、取得者のホストと通信するＪａｖａホストアプリケーションとを備える。このアプリケーションは、リモートモニタリングおよびコントロールのためのウェブインターフェースを有することが好ましい。

次いでシステムの使用および動作の側面について、さらに詳しく説明する。

端末１０は、ＴＭＬアプリケーションの静的なページをＨＴＴＰサーバ２０、２４からダウンロードする。そしてこれらは、端末のキャッシュ内に保存され、それによって、アプリケーションが修正を必要とするまでは再びロードする必要がなくなる。

図８は、端末１０がＴＭＬアプリケーションをゲートウェイホスト１９からどのようにダウンロードするかを示している。端末１０は、ＳＴＰ（ｓｅｃｕｒｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌ）を使用して、ゲートウェイホスト１９に接続する。

マイクロブラウザ１２は、（通常は最初のロードの後に、またはハイパーリンクを辿ったときに）要求されているリソースが見当たらないことを検知する。ＨＴＴＰクライアント３８は、要求されているリソースが端末１０のキャッシュ内に存在するかどうか、および最新の状態であるかどうかをチェックする。そうである場合には、そのリソースは、端末１０のキャッシュから検索され、マイクロブラウザ１２に戻される。そうでない場合には、ＨＴＴＰクライアント３８は、指定されたＵＲＩを有するバイナリーＨＴＴＰ ＧＥＴ（条件付きの、または無条件の）要求を構築し、その要求をゲートウェイ実行可能アプリケーション１４へ送信する。次いでコンバータ１６が、受け取った要求を変換し、ＨＴＴＰプロキシ１８を介してその要求をＨＴＴＰサーバ２０、２４へ返信する。プロキシ１８は、要求されているリソースを、その要求内で識別されたＵＲＩを使用して自分のキャッシュ２０６（図３を参照されたい）から検索するか、または指定されたＨＴＴＰサーバ２０、２４への接続を確立して、その要求をサーバ２０、２４へ回送し、そしてサーバ２０、２４は、これに応答して、要求されているＴＭＬページをテキストＸＭＬフォーマットで送信する。次いでコンバータ１６は、そのＸＭＬページをバイナリーＸＭＬフォーマットに変換して、端末１０へ送信する。端末１０は、ＴＭＬマークアップを解析し、（必要な場合には）リンクされたＴＭＬページ、ＣＳＳ、イメージなどをロードする。

ＴＭＬの解析が完了すると、端末１０は、ダウンロードされたＴＭＬページ内のＵＲＩによって指定されたスクリーンへと切り替わる。図９は、アプリケーションをブラウズするプロセスを示している。

１つのスクリーンから別のスクリーンへと切り替わる間、端末１０は、宛先のスクリーンに関連付けられている変数の値が、テキストを作成するために必要とされる場合には、（〈ｓｅｔｖａｒ〉要素を使用して）これらの値を更新する。そして端末は、そのタイプのスクリーンに適したものとして、そのスクリーンを処理する。

ディスプレイスクリーン、メッセージスクリーン、およびフォームスクリーンに関しては、端末は、コンテンツを端末のディスプレイ上にレンダリングする。コンテンツは、ハイパーリンクを含むことができる。テキストは、スクロールアップおよびスクロールダウンすることができ、ハイパーリンクは、端末のキーボードを使用して選択することができる。フォームスクリーンに関しては、ユーザがフォーム要素を指し示すと、端末は、そのフォーム内で指定されている入力（キーボードによる入力、磁気カードを通すこと、ｐｉｎの入力など）を受け入れるための、またはその入力をキャンセルするための用意が整う。ユーザによって入力されたデータは、変数へ格納される。

送信スクリーンを処理している間、端末は、指定された変数値を含むＴＭＬドキュメントを（バイナリーフォーマットで）構築し、そのＴＭＬドキュメントを、ゲートウェイホストを介してＨＴＴＰサーバへポストする。ゲートウェイホストのＵＲＩも、ＴＭＬページ上に規定されている。

スクリーンが処理されると、端末は、次のスクリーンへと切り替わる。ディスプレイスクリーンに関しては、これは、ユーザによって選択されたリンクを辿ることによって行われる。フォームスクリーン、メッセージスクリーン、およびプリントスクリーンに関しては、〈ｎｅｗ〉要素内で指定されているＵＲＩが辿られる。送信スクリーンに関しては、〈ｎｅｗ〉要素または〈ｅｃｏｎｎ〉要素内で指定されているＵＲＩが辿られる。ＨＴＴＰサーバは、マイクロブラウザ１２がその他の何らかの（静的なまたは動的な）ＴＭＩ、スクリーン、またはページへと切り替わるようにさせることもできる。関数呼び出しスクリーンに関しては、〈ｎｅｗ〉要素または〈ｅｒｒｏｒ〉要素内で指定されているＵＲＩが辿られる。

スクリーンタイプのいずれに関しても、そのスクリーンに対して〈ｃａｎｃｅｌ〉要素が指定されている場合にユーザが「Ｃａｎｃｅｌ」を押すと、マイクロブラウザは、〈ｃａｎｃｅｌ〉内で指定されているＵＲＩによって識別されるスクリーンへと切り替わる。ＵＲＩの代わりに「終了」という言葉が指定されると、端末は、マイクロブラウザを終了し、フローのコントロールを端末のオペレーティングシステムに渡す。

ディスプレイスクリーンまたはフォームを処理している間に「ｍｅｎｕ」キーが押されると、マイクロブラウザは、そのＴＭＬページに関する「ｍｅｎｕ」属性内で指定されているＵＲＩへと切り替わる。

要素〈ｎｅｗ〉、〈ｃａｎｃｅｌ〉、〈ｅｒｒｏｒ〉、および〈ｅｃｏｎｎ〉によって、次に処理される、またはＴＭＬ変数から入手されることになるスクリーンのためのＵＲＩを明確に識別することができる。さらに、上記の要素のために複数のＵＲＩを指定することが可能である。次のスクリーンのＵＲＩは、指定された論理式をＴＭＬの変数および定数に照らして評価した後で選択される。

次いで、ＴＭＬのブラウジングの具体的な例を示す。アプリケーションが下記のスクリーンを備えていると仮定する。
プロンプト「ＳＷＩＰＥ ＣＡＲＤ」を伴う、磁気カードを処理するためのフォームスクリーン、
プロンプト「ＥＮＴＥＲ ＡＭＯＵＮＴ」を伴う、支払われる金額を入力するためのフォーム、
オンライン取引かオフライン取引かを選択するためのディスプレイスクリーン、
２つの送信スクリーン（オンライン取引およびオフライン取引のそれぞれに１つ）、
レシートを印刷するためのプリントスクリーン、
メッセージ「ＣＡＬＬ ＡＵＴＨ ＣＥＮＴＥＲ」を伴う、拒否された支払い承認のためのメッセージスクリーン。

はじめにマイクロブラウザは、磁気カード用のフォームスクリーンを処理する。マイクロブラウザは、そのフォーム用に指定されたプロンプトをレンダリングし、カードが通されるのを待つ。カードが通されると、ブラウザは、読み取ったトラックを解析し、事前に定義されたグローバル変数（カードの番号、カードの保有者、有効期限など）に値を割り当て、金額を入力するためのフォームへと切り替わる。端末は、プロンプト「ＥＮＴＥＲ ＡＭＯＵＮＴ」をレンダリングし、端末のキーボード入力を待つ。入力された金額は、フォーム内で指定された名前と共に変数に保存される。次いでブラウザは、ディスプレイスクリーンへと切り替わる。

ディスプレイスクリーンは、「ｏｎｌｉｎｅ」および「ｏｆｆｌｉｎｅ」という名前を有する２つのリンクを含む。ユーザは、マイクロブラウザ１２を使用して、スクリーンをナビゲートすることができる。ユーザが、リンクのうちの１つに焦点を合わせて「Ｅｎｔｅｒ」を押すと、マイクロブラウザは、そのリンクを辿る。送信スクリーンを処理している間、マイクロブラウザは、ＨＴＴＰサーバにポストされるデータ（フォームスクリーン上に割り当てられる値）を構築し、それを端末メモリに保存する。

送信がオンラインである場合には、ＨＴＴＰクライアントは、すぐにデータをポストする。マイクロブラウザは、ページを切り替える前にＨＴＴＰサーバからのＰＯＳＴ応答を待つ。ＨＴＴＰサーバは、承認が成功した場合にはプリントスクリーンへ、または承認が失敗した場合にはメッセージ「ＣＡＬＬ ＡＵＴＨ ＣＥＮＴＥＲ」と共にメッセージスクリーンへ切り替わるよう端末に指示することができる。

送信がオフラインである場合には、データは、ゲートウェイホスト１９との次のセッションまで端末メモリ内に留まる。マイクロブラウザは、プリントスクリーンへすぐに切り替わる。

プリントスクリーンを処理している間、端末は、レシートを印刷し（印刷の本文は、カードの番号、金額、有効期限などの変数への参照を含むことができる）、別のクライアントにサービスを提供するために、最初のスクリーン、すなわちフォーム「ＳＷＩＰＥ ＣＡＲＤ」へと切り替わる。

次いで、ＴＭＬアプリケーションを更新する方法について説明する。

端末がゲートウェイホストと対話するたびに、ゲートウェイホストは、端末の永続的なメモリ内に保存されていてキャッシュへ移すことができるＴＭＬページごとに条件付きのＨＴＴＰ ＧＥＴ要求を端末へ送信する。

端末のＨＴＴＰクライアントは、ゲートウェイホストのＨＴＴＰプロキシによって作成される対応するＥＴａｇ（すなわち、キャッシュへ移すことができるコンテンツの識別子）のＨＴＴＰヘッダを用いてＧＥＴ要求に応答する。ゲートウェイ実行可能アプリケーションは、ＥＴａｇを評価し、それらが一致する場合には、何のコンテンツも端末へ戻さない。そうでない場合には、ＴＭＬページが再びロードされ、再び解析される。

図１０は、端末の自動設定プロセスのオペレーションを示している。端末の自動設定は、端末１０がゲートウェイホスト１９へ接続するたびに行うことができる。

端末によって送信されたデータ、ならびに設定サービス２６の応答は、ＨＴＴＰプロキシ１８によってキャッシュに格納される。

自動設定は、ＲＰＣの呼び出しを利用する。端末のＨＴＴＰクライアント３８は、バイナリー要求を構築するよう端末の設定モジュール３６に要求し、そのバイナリー要求を１つのＳＴＰパケットへとラップし、このＳＴＰパケットが、ゲートウェイホスト１９へ送信される。

次いでコンバータ１６が、そのバイナリーＨＴＴＰ要求をテキストフォームに変換して、ＨＴＴＰプロキシ１８へ回送する。ＨＴＴＰプロキシ１８は、応答をキャッシュ２０６から検索するか、またはその要求を処理のためにウェブサービスホスト２６へさらに回送することができる。

次いでコンバータ１６は、その応答をバイナリーフォームに変換して、端末のＨＴＴＰクライアント３８へ送信し、ＨＴＴＰクライアント３８は、その応答を設定モジュール３６へ戻し、そして設定モジュール３６は、その応答を解析して端末１０を設定する。

次いで、端末の自動設定の一例について考察する。

端末が小売信用限度額および時刻を更新する必要があると仮定する。ＨＴＴＰクライアント３８は、ゲートウェイホスト１９とのセッションを確立するたびに、いくつかの要求をラップした１つのＳＴＰパケットを構築する。たとえば、オフラインでの送信を伴う４つのＰＯＳＴ要求、オンラインでの送信を伴う１つのＰＯＳＴ要求、ならびにＴＭＬアプリケーションおよびスタイルシートに関する２つの条件付きのＧＥＴ要求である。そしてＨＴＴＰクライアントは、リモートプロシージャコールを伴う２つのＨＴＴＰ ＰＯＳＴ要求（一方のＲＰＣは、小売信用限度額を入手するためのものであり、別のＲＰＣは、時刻を入手するためのもの）を構築するよう設定モジュールに要求する。

ラップされた要求を伴うＳＴＰパケットは、処理のためにゲートウェイホスト１９へ送信される。ＲＰＣを伴うＨＴＴＰ ＰＯＳＴ要求および応答の双方をキャッシュに格納することができ、これによってＨＴＴＰプロキシ１８は、ＨＴＴＰサーバ２０、２４に対して要求を行うことなく応答することができる。しかし、要求されている応答がキャッシュ内に見当たらない場合には、テキストＨＴＴＰ要求が、設定ウェブサービス２６を実行しているＨＴＴＰサーバ２４へ送信される。サービス２６は、要求されているデータをデータベースから検索するリモートプロシージャコールを処理する。この場合には、時刻を入手するためのＲＰＣは、キャッシュに格納することができず（かつ、これはＨＴＴＰ要求内で指定されており）、したがって要求のうちの１つは、常にＨＴＴＰサーバ２４へ送信される。

端末のＨＴＴＰクライアント３８は、応答のＳＴＰパケットを処理し、ＲＰＣを伴うＰＯＳＴ応答（これは、条件付きのＧＥＴ応答の後ろに位置する）に出くわすと、そのＰＯＳＴ応答を処理するよう設定モジュール３６に要求する。設定モジュール３６は、その応答を処理し、端末１０の設定を更新する。

次いで、このシステムのセキュリティーの側面に関するさらなる詳細について説明する。

このシステムが直面する可能性のあるセキュリティー上の脅威としては、偽物の端末や偽物のゲートウェイホストが使用されること、送信されているデータが傍受されること、セキュリティー証明書が偽造されること、機密情報の流れにアクセスするために敵意を持ったハードウェアデバイスが物理的に接続してくること、交換されるネットワークデータパケットがすり替えられること、あるいはスマートカードや端末が盗難されることが含まれる。以降では、これらおよびその他の脅威によってもたらされる潜在的なリスクがどのようにして許容可能なレベルまで軽減されるかについて説明する。

論理的なレベルでは、このシステムのセキュリティーメカニズムは、金融システムにおいて幅広く使用されているＰＫＩ（ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）および対照の質問によるセキュリティーモデルに基づくことが好ましい。ＰＫＩは、サーバが、いわゆるルート証明書によって署名されたデジタル証明書を使用してクライアントに対して認証されることを前提としている。このシステムのセキュリティースキームにおいては、今度はクライアントが、サーバによって尋ねられる対照の質問に答えることによって、サーバによって認証される。正当なクライアントのみが、それらの質問に正しく答えることができる。偽物のクライアントは、本物のクライアントとサーバとの間における事前の合意について知らないため、正しい答えを提供することができない可能性が高い。

ＰＫＩベースのアプリケーションによって処理されるデータは、非対称キーのペアによって暗号化される。証明書には公開キーが含まれ、それらの公開キーは、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙと呼ばれる特別なサービスによって発行され、終了される。

セキュリティーアーキテクチャーを実装する際に完了すべき最初の作業は、端末のセキュリティー環境をセットアップすることである。初期設定の前には、端末は、端末のパスワードもルート証明書も有していない。これらは、端末の初期設定中にロードされることになる。

端末の初期設定には、秘密の初期設定キーが内側に印刷されているクローズドエンベロープモード、またはスマートカードモードという２つの可能なモードが存在する。新しい端末には、クローズドエンベロープまたは初期設定スマートカードのいずれかが常に添付される。

クローズドエンベロープの初期設定モードが、図１１に示されている。ユーザは、ＩＴＩＤと、エンベロープから入手した初期キー（ＰＩＮコードとも呼ばれる）とを入力する。次いで端末１０は、端末の設定内で指定されている対象のゲートウェイホスト１９とのＳＳＬセッションを開き、ＩＴＩＤを送信する。ＳＳＬのハンドシェイク中には、端末１０は、ゲートウェイホスト１９の証明書を確認しない。ゲートウェイホスト１９は、データを受け取り、ＩＴＩＤを抽出し、次いで端末の初期設定キーのコピーを探して（とりわけ初期設定されていない端末のテーブル内の）端末情報データベースを検索する。ＩＴＩＤを使用して、検索が行われる。合致する端末レコードが見つからない場合には、ゲートウェイホスト１９は、接続を閉じる。合致する端末レコードが見つかった場合には、ゲートウェイホストは、要求を行っている端末のためにランダムな一意のパスワードを発行する。

次いで、その一意のパスワードおよびルート証明書が、端末１０へ送信される。端末１０は、受け取った信用証明書を、その後の使用に備えて端末メモリに保存する。そして端末は、それまでに入力されていたセキュリティーデータを削除する。

ゲートウェイホスト１９は、端末１０から確認を受け取ると、古くなった端末レコードを端末情報データベースから削除することも行う。ゲートウェイホスト１９は、新しい端末レコードを作成し、その端末レコードを、その端末が初期設定を要求した同じゲートウェイホスト１９に関連付ける。新しいレコードは、ＩＴＩＤと、その端末がアクティブであることを示す「サービス提供中」のフラグと、一意の端末パスワードとを含む。

スマートカードの初期設定モードでは、端末のオペレータは、スマートカードを端末内へ挿入して、そのスマートカードが初期設定プロセスを自動的に完了するに任せるだけでよい。スマートカードによる初期設定は、自動的または半自動的に行うことができる。自動的な初期設定では、スマートカードは、ルート証明書を一意のパスワードおよびＩＴＩＤと共に保存することが必要である。したがって端末は、オフラインモードですぐに初期設定され、ゲートウェイホストへ接続する必要はない。半自動的な初期設定は、初期設定キーおよびＩＴＩＤのみがカードに保存されることを前提としている。端末１０は、ゲートウェイホスト１９へ接続して、証明書および一意のパスワードを受け取らなければならない。

端末の初期設定を再び行うのは、端末やその信用証明書が盗まれた場合、または端末が故障した場合のみである。どちらの場合も、同じＩＴＩＤと別のＰＩＮコードとを用いて端末を再び初期設定しなければならない。新しいクローズドエンベロープまたはスマートカードが提供される。

初期設定が済むと、端末１０は、電子的な支払いを受け入れる用意が整う。支払いを開始するために、マイクロブラウザ１２は、ＳＳＬ端末ライブラリを呼び出して、ゲートウェイホスト１９のデータ交換ポート６２への保護されたチャネルを確立する。

ハンドシェイクが済むと、端末とゲートウェイホスト１９とは、安全なチャネルを介して接続され、その端末からのいかなる要求も安全であるとみなされる。しかし、端末１０の偽造を防止するために、ＳＴＰプロトコルは、さらなる端末認証チェックを提供する。ゲートウェイホスト１９は、端末情報データベースを検索して、要求を行っている端末１０に対して「サービス提供中」のフラグが設定されているかどうかをチェックする。「サービス提供中」のフラグが設定されていない場合には、その端末はブロックされ、ゲートウェイホスト１９は、セッションを終了し、接続を解除する。その端末がサービス提供中である場合には、ゲートウェイホストは、端末のパスワードを検索して、特別なコードを実行し、この特別なコードは、ループの中で数回にわたってＡＲＣＦｏｕｒ暗号化アルゴリズムを実行する。ＡＲＣＦｏｕｒ暗号化のすべてのループは、一定の数のパスから構成される。厳密な数は、ランダムに選択されるが、２５６を下回らないことが好ましい。結果として生じるバイトは、対照の答えに相当する。そしてゲートウェイホストは、厳密に同じプロシージャを実行して、結果として生じるバイトを戻すよう端末１０に要求する。サーバおよび端末の双方の側が、同じ一意のパスワードを処理したならば、結果として生じるバイトが合致し、その端末は認証されたものとみなされる。

この瞬間から、ゲートウェイホスト１９は、端末１０を信頼し、その端末１０から来る要求の処理を開始する。

ハンドシェイクの段階で証明書を確認することが、端末の認証中に最も重要な作業である。端末１０は、ゲートウェイホスト１９の証明書を受け取り、ＣＡチェーンを確認することによって、その証明書をチェックする。

このシステムの一実施形態においては、証明書は、公に利用可能な無料のコマンドラインユーティリティーを用いて作成および署名することができる。必要とされる場合には、ユーザは、よく知られている認証当局によってルート証明書に署名することができる。

端末を別のゲートウェイホストへ切り替えること（端末の移行）も、容易かつ安全であり、システムのセキュリティーインフラストラクチャーが犠牲になることはない。これを実現するために、単一の全体にわたる端末情報データベースサーバのみが使用される。

図１２は、セキュリティーインフラストラクチャーの一例を示している。内部の端末ライブラリ１２０は、ＳＳＬ／ＴＬＳプロトコルのクライアント部分をサポートする。すべてのサーバを任意の場所に展開することができ、ユーザは、任意の数の端末を所有すること、およびゲートウェイホスト１９サーバと端末情報データベースサーバ１２２とが、任意の方法で接続されることが想定される。このようなスキームにおいては、ネットワーク全体にわたるセキュリティーリポジトリのうちのいくつかを、別々のネットワークセグメントを介して分散させることができる。このセキュリティーアーキテクチャーによって、ゲートウェイホスト１９および端末情報データベースサーバ１２２を同じコンピュータ上でホストすることができるという点に留意されたい。この展開スキームに適しているのは、単一のゲートウェイホスト１９ノードを有していて、サーバの側で必要とされるハードウェアユニットの数を最小限に抑えたいと望むユーザである。２つのサーバを一つ屋根の下でホストすることのプラスの効果は、展開スキームが、１つのあまり物理的でない接続を有するという点である。ゲートウェイホスト１９および端末情報データベースサーバ１２２は、リモートからのセキュリティー管理のためにウェブＧＵＩを使用するという点にも留意されたい。

論理的なセキュリティーガイドラインに加えて、たとえば、従来のパケット交換式のハードウェアを使用することを避けて、パケットが嗅ぎつけられるリスクを少なくすること、サーバどうしを接続する回線を保護すること（すなわち、専用の光ファイバー回線およびロックされたネットワークラックを使用すること）、システム管理者以外は誰もネットワーキングインフラストラクチャーにアクセスできないようにすること、およびいかなる疑わしい端末の動作についても、あるいは端末や安全なキーの盗難についてもシステム管理者にすぐに知らせることによって、このシステムを物理的に保護することができる。

上述の実施形態およびそれらの修正は、公知の電子金融取引システムに勝る多くの利点を提供するということを当業者ならもう認識できるであろう。

業者やその他の端末ユーザは、自分の支払いシステムが、信頼性の高い、安全な、便利な、効率のよい方法で機能することを求めている。これらのユーザにとって、この新しいシステムが取引を処理する方法は、公知の支払いシステムと同じルックアンドフィールを有するかもしれないが、ユーザのニーズによりよく対応する方法で修正することができる。

管理者権限を与えられている端末ユーザには、端末を用いた高度なアクション、たとえば、パスワードで保護された状態で設定メニューへアクセスすることを実行するように許可することができる。これによって、システムの柔軟性が高まる。

１つまたは複数のＴＭＬアプリケーションと、システムのソフトウェアが実行されているハードウェアとを所有するシステムインテグレータは、端末の展開および構成、ならびにヘルプデスクソフトウェアのサポートを担当する。システムインテグレータは、Ｃでプログラムできることなど、複雑なプログラミングスキルに習熟する必要はなく、ＴＭＬの実用的な知識を有するだけでよい。

ＴＭＬアプリケーションの開発者は、システムインテグレータ企業や、その他の何らかのサードパーティー企業（たとえば、端末の製造業者）によって採用することができる。上述のシステムは、便利なＡＰＩを備えた強力なプログラミングライブラリを彼らに提供する。彼らは、端末シミュレータを用いて、端末アプリケーションをテストしてデバッグすることもできる。

本発明の範囲から逸脱することなく、上述の実施形態に対して、さまざまな修正および改良を行うことができる。

本発明の第１の実施形態による電子金融取引システムを示す論理図である。 図１に示されている実施形態で使用されているマイクロブラウザアプリケーションを示す論理図である。 図１の電子金融取引システムで使用されているリモートホストシステムの機能的な構造を示す図である。 図３に示されているリモートホストシステムのコンポーネントを示す図である。 図１に示されている電子金融取引システムのコンポーネントの物理的な展開の一例を示す図である。 図１の電子金融取引システムによって磁気カードがどのように処理されるかを示すプロセスの流れを示す図である。 図１の電子金融取引システムによってスマートカードがどのように処理されるかを示すプロセスの流れを示す図である。 図１の電子金融取引システムで使用されている端末によってコンテンツのページがどのようにダウンロードされるかを示すプロセスの流れを示す図である。 図１の電子金融取引システムで使用されている端末によって実施されるブラウズおよびデータ処理の流れを示す図である。 端末の自動設定のプロセスを示す図である。 端末の初期設定の第１のモードを示す図である。 図１の電子金融取引システムに適用できるセキュリティーインフラストラクチャーを示す図である。

Claims (48)

1. 安全な端末とリモートホストシステムとを備える電子的支払取引システムであって、
   前記安全な端末は、
   顧客の取引カードから情報を読み取るためのカードリーダと、
   電子的支払取引に関連するユーザ入力を受け取るための入力手段と、
   情報を前記ユーザに表示するためのディスプレイと、
   電気通信ネットワークを介してリモートホストと通信するための通信手段とを
   含み、
   前記リモートホストシステムは、前記端末より開始された電子的支払取引を処理するために前記端末および取得者システムと安全に通信するように適合されており、
   前記端末が、前記リモートホストシステムからコードオブジェクトをダウンロードして解釈するように適合されている端末アプリケーションを実行し、前記コードオブジェクトが、前記端末より開始された電子的支払取引を完了するために前記端末アプリケーションによって要求されるビジネスロジックを定義し、
   前記端末アプリケーションが、取引カードから読み取られたデータを解釈するように適合されているＨＴＴＰクライアント手段、ブラウザ手段、およびカードパーサ手段を含み、
   前記コードオブジェクトが、変数をサポートするＴＭＬ（ｔｅｒｍｉｎａｌｍａｒｋ−ｕｐ ｌａｎｇｕａｇｅ）で表されているドキュメントを備え、
   前記リモートホストシステムが、前記端末と通信するゲートウェイホストを含み、前記ゲートウェイホストが、ＴＣＰ／ＩＰリスニング手段と、処理手段と、コンバータ手段と、ＨＴＴＰプロキシとを備え、前記リモートホストシステムが、前記ゲートウェイホストおよび前記取得者システムと通信するＴＭＬアプリケーションホストと、前記ゲートウェイホストと通信するウェブサービスホストとをさらに実行する、電子的支払取引システム。
2. 前記ＴＭＬが、文字列、整数、日付、およびあいまいな変数をサポートする請求項１に記載の電子的支払取引システム。
3. 前記ＴＭＬドキュメントが、十分に形作られているＸＭＬドキュメントを備える請求項１または２に記載の電子的支払取引システム。
4. 前記端末アプリケーションが、マイクロブラウザアプリケーションを備える請求項１〜３のいずれか一項に記載の電子的支払取引システム。
5. 前記端末と前記ゲートウェイホストとの間における通信のために使用されるプロトコルスタックをさらに含み、前記プロトコルスタックが、安全な伝送プロトコル層と、ＴＣＰ／ＩＰ層と、ＢＨＴＴＰ（ｂｉｎａｒｙＨＴＴＰ）層とを備える請求項１〜４のいずれか一項に記載の電子的支払取引システム。
6. 前記安全な伝送プロトコル層が、ＳＳＬまたはＴＬＳを備える請求項５に記載の電子的支払取引システム。
7. 前記ゲートウェイホストの前記ＨＴＴＰプロキシが、支払いアプリケーションと共に機能するように構成されている前記アプリケーションホストの第１のＨＴＴＰサーバ手段と、設定サービスと共に機能するように構成されている前記ウェブサービスホストの第２のＨＴＴＰサーバ手段とにサービスを提供するように構成されている請求項１〜６のいずれか一項に記載の電
   子的支払取引システム。
8. ＴＭＬドキュメントをダウンロードしたいという前記端末アプリケーションによる要求が、前記端末のＨＴＴＰクライアントから前記ゲートウェイホストへバイナリーＨＴＴＰ要求として送信され、前記ゲートウェイホストによってテキストＨＴＴＰへ変換され、前記ゲートウェイホストのＨＴＴＰプロキシから前記第１または第２のＨＴＴＰサーバへテキストＨＴＴＰ要求として送信される請求項７に記載の電子的支払取引システム。
9. ＴＭＬドキュメントをダウンロードしたいという前記端末アプリケーションによる要求への応答が、前記第１または第２のＨＴＴＰサーバから前記ゲートウェイホストのＨＴＴＰプロキシへテキストＨＴＴＰ応答として送信され、前記ゲートウェイホストによってバイナリＨＴＴＰへ変換され、前記ゲートウェイホストから前記端末のＨＴＴＰクライアントへバイナリーＨＴＴＰ応答として送信される請求項８に記載の電子的支払取引システム。
10. 前記端末および前記リモートホストシステムが、お互いに対して認証可能である請求項１〜９のいずれか一項に記載の電子的支払取引システム。
11. 前記認証が、ＰＫＩ（ｐｕｂｌｉｃｋｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を使用する請求項１０に記載の電子的支払取引システム。
12. 前記リモートホストシステムが、ルート証明書を用いて署名されたデジタル証明書によって前記端末に対して認証され、前記端末が、対照の質問に対して正しい答えを提供することによって、前記リモートホストシステムに対して認証される請求項１０または１１に記載の電子的支払取引システム。
13. 前記デジタル証明書がＸ．５０９証明書である請求項１２に記載の電子的支払取引システム。
14. 前記コードオブジェクトが、磁気カードを通すこと、ＩＣＣカードを挿入すること、ピンパッドキーボードを使用すること、または端末のキーボードを使用することによるユーザ入力を受け取るのに適したフォームスクリーンを定義するコードオブジェクトを含む請求項１〜１３のいずれか一項に記載の電子的支払取引システム。
15. 前記コードオブジェクトが、ディスプレイスクリーンと、プリントスクリーンと、エラーメッセージや通知メッセージを表示するためのスクリーンと、関数の呼び出しを送信するためのスクリーンとを含むスクリーンタイプをサポートするコードオブジェクトを含む請求項１〜１４のいずれか一項に記載の電子的支払取引システム。
16. 端末が、
    キャッシュに格納できるリソースのＩＤと共に条件付きのＨＴＴＰ要求を前記リモートホストシステムへ送信する前記端末アプリケーションと、
    キャッシュに格納できるそれぞれのリソースごとに、前記リソースを、キャッシュ内に保存されているレコードに照らしてチェックし、前記リソースの更新を前記端末アプリケーションへ戻すか、または前記リソースが変更されていないことを確認するための前記リモートホスト（１９）とから構成される請求項１〜１５のいずれか一項に記載の電子的支払取引システム。
17. 前記リモートホストシステムが、前記キャッシュから何の応答も受け取らない場合に、前記リモートホストシステムが、要求を設定サーバへ送信し、前記設定サーバが、キャッシュに格納できるそれぞれのリソースごとに、前記リソースを、キャッシュ内に保存されているレコードに照らしてチェックし、前記リソースの更新を前記リモートホストシステムへ戻すか、または前記リソースが変更されていないことを確認する請求項１６に記載の電子的支払取引システム。
18. 前記設定サーバが、ウェブアプリケーションを使用してサービスプロバイダーによって修正されるように適合されており、それによって、前記修正された設定を用いて前記端末の設定を更新することができる請求項１６に記載の電子的支払取引システム。
19. 前記条件付きのＨＴＴＰ要求が、ＲＰＣ（ｒｅｍｏｔｅｐｒｏｃｅｄｕｒｅ ｃａｌｌ）を含む請求項１６〜１８のいずれか一項に記載の電子的支払取引システム。
20. 前記端末の設定可能なパラメータが、時刻同期、端末の設定、およびカードパーサ用のパラメータのうちの少なくとも１つを含む請求項１６〜１９のいずれか一項に記載の電子的支払取引システム。
21. 前記端末が前記リモートホストシステムへ接続するたびに、前記端末の構成をチェックして設定することができる請求項１〜２０のいずれか一項に記載の電子的支払取引システム。
22. 請求項１〜２１のいずれか一項に記載の電子的支払取引システムにおいて使用するように適合されている安全な端末。
23. 請求項１〜２１のいずれか一項に記載の電子的支払取引システムにおいて使用するように適合されているリモートホストシステム。
24. 請求項１〜９のいずれか一項に記載の電子的支払取引システムにおいて使用するように適合されているゲートウェイホスト。
25. 請求項１〜９のいずれか一項に記載の電子的支払取引システムにおいて使用するように適合されているＴＭＬアプリケーションホスト。
26. 請求項１〜９のいずれか一項に記載の電子的支払取引システムにおいて使用するように適合されているウェブサービスホスト。
27. リモートホストシステムと少なくとも一つの安全な端末とを備える電子的支払取引システムが、前記端末より開始された電子支払取引を運営する方法であって、前記リモートホストシステムは、前記取引を処理するために取得者システムと前記端末と安全に通信し、当該方法は、
    前記安全な端末を使用して、
    顧客の取引カードから情報を読み取り、
    前記取引に関連するユーザ入力を受け取り、
    情報を前記ユーザに表示し、
    電気通信ネットワークを介して前記リモートホストと通信するステップと、
    前記端末上で端末アプリケーションを実行するステップであって、前記端末アプリケーションが、前記リモートホストシステムからコードオブジェクトをダウンロードして解釈するように適合されており、前記コードオブジェクトが、前記電子的支払取引を完了するために前記端末アプリケーションによって要求されるビジネスロジックを定義し、前記ビジネスロジックは、取引カードから読み取られたデータの解釈を含み、前記解釈が、ＨＴＴＰクライアント手段、ブラウザ手段、およびカードパーサ手段によって実行され、前記コードオブジェクトは、変数をサポートするＴＭＬ（ｔｅｒｍｉｎａｌｍａｒｋ−ｕｐ ｌａｎｇｕａｇｅ）で表されているドキュメントを備える、ステップと、
    前記端末と通信するゲートウェイホストを提供するステップであって、前記ゲートウェイホストが、ＴＣＰ／ＩＰリスニング手段と、処理手段と、コンバータ手段と、ＨＴＴＰプロキシとを備える、ステップと、
    を含み、
    前記リモートホストシステムは、前記ゲートウェイホストおよび前記取得者システムと通信するＴＭＬアプリケーションホストと、前記ゲートウェイホストと通信するウェブサービスホストとをさらに実行する方法。
28. 前記ＴＭＬが、文字列、整数、日付、およびあいまいな変数をサポートする請求項２７に記載の方法。
29. 前記ＴＭＬドキュメントが、十分に形作られているＸＭＬドキュメントを備える請求項２７または２８に記載の方法。
30. 前記端末アプリケーションが、マイクロブラウザアプリケーションを備える請求項２７〜２９のいずれか一項に記載の方法。
31. 前記端末と前記ゲートウェイホストとの間における通信が、プロトコルスタックを使用し、前記プロトコルスタックが、安全な伝送プロトコル層と、ＴＣＰ／ＩＰ層と、ＢＨＴＴＰ（ｂｉｎａｒｙＨＴＴＰ）層とを備える請求項２７〜３０のいずれか一項に記載の方法。
32. 前記安全な伝送プロトコル層が、ＳＳＬまたはＴＬＳを備える請求項３１に記載の方法。
33. 前記ゲートウェイホストの前記ＨＴＴＰプロキシが、支払いアプリケーションと共に機能するように構成されている前記アプリケーションホストの第１のＨＴＴＰサーバ手段と、設定サービスと共に機能するように構成されている前記ウェブサービスホストの第２のＨＴＴＰサーバ手段とにサービスを提供する請求項２７に記載の方法。
34. 前記端末のＨＴＴＰクライアントが、ＴＭＬドキュメントをダウンロードしたいという前記端末アプリケーションによる要求を前記ゲートウェイホストへバイナリーＨＴＴＰ要求として送信し、
    前記ゲートウェイホストが、前記要求をテキストＨＴＴＰへ変換し、前記ゲートウェイホストのＨＴＴＰプロキシが、前記要求を前記第１または第２のＨＴＴＰサーバへテキストＨＴＴＰ要求として送信する請求項３３に記載の方法。
35. 前記第１または第２のＨＴＴＰサーバが、ＴＭＬドキュメントをダウンロードしたいという前記端末アプリケーションによる要求への応答を前記ゲートウェイホストのＨＴＴＰプロキシへテキストＨＴＴＰ応答として送信し、
    前記ゲートウェイホストが、前記応答をバイナリーＨＴＴＰへ変換し、
    前記ゲートウェイホストが、前記応答を前記端末のＨＴＴＰクライアントへバイナリーＨＴＴＰ応答として送信する請求項３４に記載の方法。
36. 前記端末およびリモートホストシステムをお互いに対して認証するステップをさらに含む請求項２７〜３５のいずれか一項に記載の方法。
37. 前記認証が、ＰＫＩ（ｐｕｂｌｉｃｋｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を使用する請求項３６に記載の方法。
38. 前記リモートホストシステムが、ルート証明書を用いて署名されたデジタル証明書によって前記端末に対して認証され、前記端末が、対照の質問に対して正しい答えを提供することによって、前記リモートホストシステムに対して認証される請求項３６または３７に記載の方法。
39. 前記デジタル証明書がＸ．５０９証明書である請求項３８に記載の方法。
40. 前記コードオブジェクトが、磁気カードを通すこと、ＩＣＣカードを挿入すること、ピンパッドキーボードを使用すること、または端末のキーボードを使用することのうちのいずれかによるユーザ入力を受け取るフォームスクリーンを定義するコードオブジェクトを含む請求項２７〜３９のいずれか一項に記載の方法。
41. 前記コードオブジェクトが、ディスプレイスクリーンと、プリントスクリーンと、エラーメッセージや通知メッセージを表示するためのスクリーンと、関数の呼び出しを送信するためのスクリーンとを含むスクリーンタイプをサポートするコードオブジェクトを含む請求項２７〜４０のいずれか一項に記載の方法。
42. 前記端末が前記リモートホストシステムへ接続するたびに、前記端末の構成をチェックして設定することができる請求項２７〜４１のいずれか一項に記載の方法。
43. 請求項２７〜４２のいずれか一項に記載の方法において使用するための端末を設定する方法であって、前記端末アプリケーションが、キャッシュに格納できるリソースのＩＤと共に条件付きのＨＴＴＰ要求を前記リモートホストシステムへ送信し、
    前記リモートホストが、キャッシュに格納できるそれぞれのリソースごとに、前記リソースを、キャッシュ内に保存されているレコードに照らしてチェックし、前記リソースの更新を前記端末アプリケーションへ戻すか、または前記リソースが変更されていないことを確認する方法。
44. 前記リモートホストシステムが、前記キャッシュから何の応答も受け取らない場合に、前記リモートホストシステムが、要求を設定サーバへ送信し、前記設定サーバが、キャッシュに格納できるそれぞれのリソースごとに、前記リソースを、キャッシュ内に保存されているレコードに照らしてチェックし、前記リソースの更新を前記リモートホストシステムへ戻すか、または前記リソースが変更されていないことを確認する請求項４３に記載の方法。
45. 前記設定サーバが、ウェブアプリケーションを使用してサービスプロバイダーによって修正されて、前記修正された設定を用いて前記端末の設定が更新される請求項４４に記載の方法。
46. 前記条件付きのＨＴＴＰ要求が、ＲＰＣ（ｒｅｍｏｔｅｐｒｏｃｅｄｕｒｅ ｃａｌｌ）を含む請求項４３〜４５のいずれか一項に記載の方法。
47. 前記端末の設定可能なパラメータが、時刻同期、端末の設定、およびカードパーサ用のパラメータのうちの少なくとも１つを含む請求項４３〜４６のいずれか一項に記載の方法。
48. 前記端末が前記リモートホストシステムへ接続するたびに、前記端末の構成をチェックして設定することができる請求項４３〜４７のいずれか一項に記載の方法。

Images