(57)【特許請求の範囲】
【請求項１】
支払い情報を受信および送信するネットワーク（３４、３５）に接続された顧客コンピュータおよび販売者コンピュータ（１２０、１３０）間の安全な通信を開始する方法であって、
（ａ）前記ネットワーク（３５）を介して前記顧客コンピュータおよび前記販売者コンピュータ（１２０、１３０）間の通信を確立するステップを有し
（ｂ）顧客コンピュータサポート暗号化アルゴリズムの指示を前記顧客コンピュータから前記販売者コンピュータへ送るステップを有し、
（ｃ）前記顧客コンピュータサポート暗号化アルゴリズムの１つを、前記販売者コンピュータにおいて選択するステップを有し、ここで、選択された前記顧客コンピュータサポート暗号化アルゴリズムは、前記顧客コンピュータおよび前記販売者コンピュータ（１２０、１３０）間の通信に利用される暗号化手順と解読手順（２１０〜２７０）を含んでおり、
（ｄ）前記顧客コンピュータにおいて、前記暗号化手順を用いて支払い情報を暗号化し、前記暗号化支払い情報を、前記顧客コンピュータから前記販売者コンピュータ（１２０，１３０）に送信するステップを有し、
（ｅ）前記販売者コンピュータ（１３０）で前記暗号化支払い情報（２７０）を受信し、前記解読手順（２７０）を利用して前記暗号化支払い情報を解読するステップを有し、
（ｆ）その後の支払い処理（４１０〜５６５）のために、前記暗号化支払い情報を含み第三者安全プロトコルに適合された要求を発生するステップを有し、ここで、前記第三者安全プロトコルは、暗号化支払い情報を前記顧客コンピュータと前記販売者コンピュータ間で送信するのに用いられるプロトコルとは異なる、
前記安全な通信を開始する方法。
【請求項２】
請求項１に記載の方法において、前記顧客コンピュータおよび前記販売者コンピュータ・システム間で情報を伝送するためにインターネットを利用するステップを含む方法。
【請求項３】
請求項１に記載の方法において、前記その後の支払い処理においてクレジットを許可または拒否するために、前記支払い情報を含む要求を、前記販売者コンピュータから第三コンピュータへ送信するステップを含む方法。
【請求項４】
請求項１に記載の方法において、さらに、
（ａ）前記顧客コンピュータおよび前記販売者コンピュータ間の前記安全な通信で使用するために顧客情報を得るステップと、
（ｂ）前記ネットワークを経由して前記顧客コンピュータおよび前記販売者コンピュータ間で通信を確立するステップと、
（ｃ）その後の支払い処理（４１０〜５６５）のために、前記顧客情報を用いて、第三者安全プロトコルに適合した支払い要求を、前記暗号化支払い情報として発生するステップと、を有し、
ここで、前記第三者安全プロトコルは、前記顧客コンピュータと前記販売者コンピュータ間で通信を確立するのに用いられるプロトコルとは異なる、
前記安全な通信を開始する方法。
【請求項５】
請求項４に記載の方法において、
（ｄ）前記顧客コンピュータから前記販売者コンピュータに暗号化支払い情報を送信するステップと、
（ｅ）前記販売者コンピュータで前記暗号化支払い情報を受信し、前記解読手順を利用して前記支払い情報を解読するステップと、
（ｆ）前記解読された支払い情報についてさらに支払い処理を実行するステップとを含む方法。
【請求項６】
請求項４に記載の方法において、前記顧客情報が、電話、ファックス機または電子メールの１つによって、販売者コンピュータへ送信される形に形成される方法。
【請求項７】
請求項４に記載の方法において、前記暗号化支払い情報の処理を認証するために電子署名が利用される方法。
【請求項８】
請求項６に記載の方法において、前記顧客情報が、安全プロトコルを用いて販売者コンピュータへ送信される形に形成される方法。
【請求項９】
支払い情報の受信と送信のためネットワーク（３４、３５）に接続されているソフトウェアの制御下において、顧客コンピュータおよび販売者コンピュータにより支払い処理を開始する装置であって、
（ａ）前記ネットワークを経由して前記顧客コンピュータおよび前記販売者コンピュータ間で通信を確立する手段（１０〜３５、１５０）を有し、
（ｂ）顧客コンピュータサポート暗号化アルゴリズムの指示を前記顧客コンピュータから前記販売者コンピュータへ送る手段を有し、
（ｃ）前記顧客コンピュータサポート暗号化アルゴリズムの１つを、前記販売者コンピュータにおいて選択する手段を有し、ここで、選択された前記顧客コンピュータサポート暗号化アルゴリズムは、前記顧客コンピュータおよび前記販売者コンピュータ（１２０、１３０，２１０−２７０）間の通信に利用される暗号化手順と解読手順（１０−３５、１２０−１３０、２１０〜２７０、）を含んでおり、
（ｄ）前記顧客コンピュータにおいて、前記暗号化手順を用いて、支払い情報を暗号化する手段と、前記暗号化支払い情報を、前記顧客コンピュータから前記販売者コンピュータ（１０−３５、２７０）に送信する手段を有し、
（ｅ）前記販売者コンピュータで前記暗号化支払い情報を受信し前記解読手順を利用して前記支払い情報を解読する手段（１０〜３５、２７０）を有し、
（ｆ）前記暗号化支払い情報を用いて、第三者安全プロトコルに適合した支払い要求を、その後の支払い処理（１０−３５、４１０〜５６５）のために発生する手段を有し、ここで、前記第三者安全プロトコルは、前記顧客コンピュータからの前記暗号化顧客支払い情報を送信するのに用いられるプロトコルとは異なる、
前記支払い処理を開始する装置。
【請求項１０】
請求項９に記載の装置において、前記顧客コンピュータおよび前記販売者コンピュータ間で情報を伝送するためにインターネットを利用する手段を含む装置。
【請求項１１】
請求項９に記載の装置において、前記その後の支払い処理においてクレジットを許可または拒否するために、前記暗号化支払い情報を、前記販売者コンピュータから第三コンピュータへ送信する装置。
【発明の詳細な説明】
発明の分野
本発明は、通信ネットワーク上で購入された商品およびサービスの代償としての電子支払いに関し、より具体的かつより詳細には、安全に支払い情報を顧客から販売者、支払いゲートウェイに送信し、適切で安全な許可を販売者および顧客に返送するシステム、方法および製造物に関する。
発明の背景
販売者の制御の下で操作されるコンピュータにとって、顧客によって提供され、顧客の制御の下で動作するコンピュータによって、公的にアクセス可能なパケット交換ネットワーク（例えば、インターネット）を通じて販売者の制御の下で動作するコンピュータに送信された情報を、ネットワークにアクセスする第三者の傍受に情報をさらす危険なしに獲得し、かつ情報が確かな出所からのものであることを確保することが望ましい。さらに、販売者は、情報を第三者の傍受にさらす危険なしに、顧客の代わりに支払いを行う責任を有する銀行または他の金融機関によってこうした金融機関の代わりに商取引を行うよう許可された支払いゲートウェイ・コンピュータにこのネットワークを通じて顧客によって提供された情報の下位集合を含む情報を送信することが望ましい。こうした機関には、例えば、クレジットまたはデビット・カード・サービスを提供する金融機関が含まれる。
こうした安全な伝送チャネルを提供する試みの１つが、ＶｉｓａとＭａｓｔｅｒＣａｒｄのカード連合によって共同開発され、引用によって本明細書の記載に援用する、ＶｉｓａおよびＭａｓｔｅｒＣａｒｄのＳｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓａｃｔｉｏｎ（ＳＥＴ）仕様書、１９９６年２月２３日に説明されているＳｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓａｃｔｉｏｎ（以下“ＳＥＴ”）のような安全支払い技術である。他のこうした安全支払い技術には、Ｓｅｃｕｒｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ（“ＳＴＴ”）、Ｓｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｐａｙｍｅｎｔｓ  Ｐｒｏｔｏｃｏｌ（“ＳＥＰＰ”）、Ｉｎｔｅｒｎｅｔ  Ｋｅｙｅｄ  Ｐａｙｍｅｎｔｓ（“ＩＫＰ”）、Ｎｅｔ  Ｔｒｕｓｔ、およびＣｙｂｅｒｃａｓｈ  Ｃｒｅｄｉｔ  Ｐａｙｍｅｎｔ  Ｐｒｏｔｏｃｏｌが含まれる。当業技術分野に普通に熟練した者は、これらの安全支払い技術のいずれも、不適当な実験なしにＳＥＴプロトコルの代用となることを容易に理解するだろう。こうした安全支払い技術は、安全支払い技術に適合し、第三者認証機関と対話し、それによって顧客が符号化情報を販売者に送信できるようにするソフトウェアを操作することを顧客に要求するが、顧客が送信した符号化情報の一部は販売者によって復号化され、一部は顧客によって指定された支払いゲートウェイだけが復号化できる。安全支払い技術のアプローチの欠点は、顧客が特定の安全支払い技術に適合した専用ソフトウェアを装備する必要があるため、安全支払い技術のユーザの受け入れがこのソフトウェアをインストールしようとする顧客に制限されることである。対話の対象となる対応する安全支払い技術を組み込んだ販売者のソフトウェアと支払いゲートウェイの一般的な受容がないため、顧客は一般に、こうした専用ソフトウェアのインストールには消極的である。同様に、安全支払い技術を使用するため利用可能な顧客の基盤が導入されていないため、販売者と支払いゲートウェイは安全支払い技術の実現に消極的である。これは、安全支払い技術の個々の構成部分は、他の構成部分が一般的に受け入れられるまでは一般的に受け入れられそうもない、という「鶏と卵」の問題を提示している。
こうした安全伝送チャネルを提供するもう１つの試みは、Ｆｒｅｉｅｒ、ＫａｒｌｔｏｎおよびＫｏｃｈｅｒ（以下“Ｆｒｅｉｅｒ”）、「ＳＳＬプロトコル・バージョン３．０」、１９９６年３月で説明され、引用によって本明細書の記載に援用する、Ｎｅｔｓｃａｐｅ，Ｉｎｃ．のＳｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ（以下“ＳＳＬ”）である。ＳＳＬは２つのコンピュータ間の安全な伝送の手段を提供する。ＳＳＬは、多くの人々が標準インターネット・アクセス媒体として利用している広く利用可能なソフトウェアにすでに組み込まれているため専用ソフトウェアを顧客のコンピュータにインストールする必要がなく、顧客が第三者認証機関と対話する必要がないという利点を有する。その代わり、ＳＳＬのサポートは顧客によってすでに使用されているソフトウェア、例えば、ネットスケープ・ナビゲーター・ワールド・ワイド・ウェブ・ブラウジング・ツールに組み込まれる。しかし、ＳＳＬ接続上のあるコンピュータはもう１つのコンピュータにＳＳＬ接続を開始できるが、ＳＳＬアプローチの欠点は各ＳＳＬ接続は２つのコンピュータの接続しかサポートしないことである。従って、ＳＳＬは、符号化情報を販売者に送信し、情報の下位集合が販売者にではなく支払いゲートウェイに読みとれるように支払いゲートウェイに再送信する機構を提供しない。ＳＳＬは堅牢な安全二者間データ伝送を考慮するが、堅牢な安全三者間データ伝送のための電子通商市場の根本的な必要には答えていない。汎用安全通信プロトコルの他の例には、Ｍｉｃｒｏｓｏｆｔ，Ｉｎｃ．のＰｒｉｖａｔｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｔｅｃｈｎｏｌｏｇｙ（“ＰＣＴ”）、Ｔｈｅｒｅｓａ  ＳｙｓｔｅｍｓのＳｅｃｕｒｅ  Ｈｙｐｅｒ−Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（“ＳＨＴＴＰ”）、Ｓｈｅｎ、Ｋｅｒｂｅｒｏｓ、Ｐｈｏｔｕｒｉｓ、Ｐｒｅｔｔｙ  ｇｏｏｄ  Ｐｒｉｖａｃｙ（“ＰＧＰ”）および、ＩＰＳＥＣ基準を満たすＩｐｖ６が含まれる。当業技術分野に普通に熟練した者は、これらの汎用安全通信プロトコルのいずれも、不適当な実験なしにＳＳＬ伝送プロトコルの代用となることを容易に理解するだろう。
発明の目的
顧客の受容がない場合、支払いゲートウェイによるＳＥＴのような三者間安全チャネルの配置を助長し、それによって顧客が自分のコンピュータ・システムにＳＥＴ対応ソフトウェアを設置する動機を与える混成アプローチを提供することが望ましい。販売者がＳＳＬまたは他の汎用安全通信プロトコルのような容易に配置できる安全チャネルを使用して顧客と通信し、顧客の認証に依存しない修正ＳＥＴ状プロトコルを使用して支払いゲートウェイと通信する手段と提供することがさらに望ましい。
発明の概要
本発明の好適実施形態の広範な態様によれば、インターネットのような公衆通信システムを通じて複数のコンピュータ・システム間でデータの安全な伝送が提供される。顧客コンピュータ・システムから販売者コンピュータ・システムへのデータの安全な伝送が提供され、さらに、販売者コンピュータ・システムから支払いゲートウェイ・コンピュータ・システムへのデータの安全な伝送が提供される。支払いゲートウェイ・システムは情報を評価し、クレジットの許可または拒否を安全な伝送によって販売者に返送し、それが販売者によりて顧客に伝えられる。
図面の説明
上記および他の目的、態様および利点は、以下の図面に関連する本発明の好適実施形態の以下の詳細な説明からよりよく理解される。
図１Ａは、好適実施形態による代表的なハードウェア環境のブロック図である。
図１Ｂは、好適実施形態による概観を示す。
図２は、好適実施形態によるＳｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒプロトコルの下で販売者システムと通信する顧客コンピュータ・システムのより詳細な図を示す。
図３は、好適実施形態による、支払い許可を得るために、支払い情報を支払いゲートウェイに安全に供給する方法の概観を示す。
図４は、好適実施形態による支払い許可要求を生成および送信する詳細なステップを示す。
図５Ａ〜図５Ｆは、好適実施形態による支払い許可要求とその構成部分の図を示す。
図６Ａおよび図６Ｂは、好適実施形態による、支払い許可要求を処理し、支払い許可応答を生成および送信する詳細なステップを示す。
図７Ａ〜図７Ｊは、好適実施形態による支払い許可応答とその構成部分の図を示す。
図８は、好適実施形態による、支払い許可応答を処理する詳細なステップを示す。
図９は、好適実施形態による、支払い回収情報を支払いゲートウェイに安全に供給する方法の概観を示す。
図１０は、好適実施形態による、支払い回収要求を生成および送信する詳細なステップを示す。
図１１Ａ〜図１１Ｆは、好適実施形態による支払い回収要求とその構成部分の図を示す。
図１２Ａおよび図１２Ｂは、好適実施形態による、支払い回収要求を処理し、支払い回収要求応答を生成および送信する詳細なステップを示す。
図１３Ａ〜図１３Ｆは、好適実施形態による支払い回収応答とその構成部分の図を示す。
図１４は、好適実施形態による支払い回収応答を処理する詳細なステップを示す。
詳細な説明
本発明によるシステムの好適実施形態は、好適にはＩＢＭ  ＰＳ／２、Ａｐｐｌｅ  ＭａｃｉｎｔｏｓｈコンピュータまたはＵＮＩＸベース・ワークステーションといったパーソナル・コンピュータの文脈で実施される。代表的なハードウェア環境が図１Ａに示されるが、これは、マイクロプロセッサのような中央処理ユニット１０とシステム・バス１２を経由して相互接続された多数の他のユニットを有する好適実施形態によるワークステーションの通常のハードウェア構成を示す。図１Ａに示されるワークステーションには、ランダムアクセス・メモリ（ＲＡＭ）１４、読み出し専用メモリ（ＲＯＭ）１６、ディスク記憶ユニット２０のような周辺装置をバス１２に接続するＩ／Ｏアダプタ１８、キーボード２４、マウス２６、スピーカ２８、マイクロホン３２および／またはタッチスクリーン（図示せず）のような他のユーザ・インタフェース装置をバス１２に接続するユーザ・インタフェース・アダプタ２２、ワークステーションを通信ネットワーク（例えば、データ処理ネットワーク）に接続する通信アダプタ３４および、バス１２をディスプレイ装置３８に接続するディスプレイ・アダプタ３６が含まれる。ワークステーションは通常、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓオペレーティング・システム（ＯＳ）、ＩＢＭ  ＯＳ／２オペレーティング・システム、ＭＡＣ  ＯＳまたはＵＮＩＸオペレーティング・システムといった常駐するオペレーティング・システムを有する。当業技術分野に熟練した者は、本発明がここで言及されたもの以外のプラットフォームおよびオペレーティング・システム上でも実現されることを認識するだろう。
好適実施形態はＪＡＶＡ、ＣおよびＣ＋＋言語を使用して書かれ、オブジェクト指向プログラミングの方法論を利用する。オブジェクト指向プログラミング（ＯＯＰ）は、複雑なアプリケーションを開発する際次第に使用されるようになっている。ＯＯＰがソフトウェア設計および開発の主流になるにつれて、さまざまなソフトウェア・ソリューションはＯＯＰの利益を利用することが必要になっている。ＯＯＰクラスの集合とメッセージング・インタフェースのためのオブジェクトが提供されるように、ＯＯＰの原理を電子メッセージング・システムのメッセージング・インタフェースに適用する必要がある。
ＯＯＰはオブジェクトを使用してコンピュータ・ソフトウェアを開発する処理であり、問題を分析するステップと、システムを設計するステップと、プログラムを構成するステップとが含まれる。オブジェクトはデータと関連構造および手順の集まりの両方を含むソフトウェア・パッケージである。オブジェクトはデータと構造および手順の集まりの両方を含むため、その特定のタスクを行うために他の付加的な構造、手順またはデータを必要としない自足的なコンポーネントとして見ることができる。従って、ＯＯＰは、各々が特定のタスクに対して責任を負う、オブジェクトと呼ばれる主として自律的なコンポーネントの集まりとしてコンピュータ・プログラムを見る。データ、構造および手順を１つのコンポーネントまたはモジュールにパッケージするこのコンセプトはカプセル化と呼ばれる。
一般に、ＯＯＰコンポーネントはオブジェクト・モデルに適合するインタフェースを提示する再使用可能なソフトウェア・モジュールであり、コンポーネント統合アーキテクチャを通じてランタイムにアクセスされる。コンポーネント統合アーキテクチャはアーキテクチャ機構の集合であり、ソフトウェア・モジュールが異なった処理空間で互いの能力または機能を利用できるようにする。これは一般に、アーキテクチャを構築する基礎となる共通コンポーネント・オブジェクト・モデルを仮定することによってなされる。
この時点でオブジェクトとオブジェクトのクラスを区別することは価値がある。オブジェクトはオブジェクトのクラス（単にクラスと呼ばれることが多い）の１つのインスタンスである。オブジェクトのクラスは、そこから多くのオブジェクトが形成される青写真と見ることができる。
ＯＯＰによって、プログラマは別のオブジェクトの一部であるオブジェクトを生成することができる。例えば、ピストン・エンジンを表すオブジェクトはピストンを表すオブジェクトと合成関係を有すると言える。実際には、ピストン・エンジンはピストン、バルブおよび多くの他の部品を含む。ピストンがピストン・エンジンの要素であるという事実はＯＯＰでは２つのオブジェクトによって論理的かつ意味論的に表される。
ＯＯＰはまた、他のオブジェクトに「依存する」オブジェクトの生成を可能にする。２つのオブジェクトが存在し、１つがピストンを表しもう１つがピストン・エンジンを表すが、ピストンがセラミック製である場合、２つのオブジェクト間の関係は合成ではない。セラミック・ピストン・エンジンがピストン・エンジンを構成するわけではない。むしろそれは、ピストンがセラミック製であるという、ピストン・エンジンより１つ多い制限を有するピストン・エンジンの１つの種類であるに過ぎない。この場合、セラミック・ピストン・エンジンを表すオブジェクトは導出オブジェクトと呼ばれ、ピストン・エンジンを表すオブジェクトの態様をすべて継承し、それにさらに制限または詳細を追加する。セラミック・ピストン・エンジンを表すオブジェクトは、ピストン・エンジンを表すオブジェクトに「依存する」。これらのオブジェクト関係は継承と呼ばれる。
セラミック・ピストン・エンジンを表すオブジェクトまたはクラスがピストン・エンジンを表すオブジェクトの態様をすべて継承する場合、それはピストン・エンジン・クラスで定義された標準ピストンの熱特性を継承する。しかし、セラミック・ピストン・エンジン・オブジェクトは、通常金属製ピストンに関連するものと異なっているセラミック特有の熱特性に優先する。それは元の特性を飛ばしてセラミック・ピストンに関連する新しい機能を使用する。異なった種類のピストン・エンジンは異なった特性を有するが、それに関連する同じ基本的機能（例えば、エンジンのピストン数、点火シーケンス、潤滑等）を有する。どのピストンエンジン・オブジェクトにおいてもこれらの各機能にアクセスするために、プログラマは同じ機能を同じ名前で呼ぶが、各種のピストン・エンジンは同じ名前の下で機能の異なった／優先的な実現を有する。同じ名前の下に機能の異なった実現を隠すこの能力は多相性と呼ばれ、オブジェクト間の通信をごく単純にする。
合成関係、カプセル化、継承および多相性の概念によって、オブジェクトは現実世界のほとんどすべてを表現できる。実際には、現実の我々の論理的知覚は、オブジェクト指向ソフトウェアでオブジェクトになりうる種類の物事の判断だけに制限されている。いくつかの典型的なカテゴリは以下の通りである。
・オブジェクトは、交通量シミュレーションにおける自動車、回路設計プログラムにおける電子部品、経済モデルにおける国、または航空輸送制御システムにおける飛行機といった物理的対象を表現できる。
・オブジェクトは、ウィンドウ、メニューまたはグラフィックス・オブジェクトといったコンピュータ・ユーザ環境の要素を表現できる。
・オブジェクトは個人ファイルまたは都市の緯度と経度といった目録を表現できる。
・オブジェクトは、時間、角度および複素数、または平面上の点といったユーザが定義するデータの種類を表現できる。
論理的に分離可能な事物のほとんどすべてを表現するオブジェクトのこの膨大な能力のために、ソフトウェア開発者はＯＯＰによって、現実のある態様のモデルであるコンピュータ・プログラムを、その現実が物理的実体、過程、システムまたは事物の合成の何であれ設計し実現できる。オブジェクトは何でも表現できるので、ソフトウェア開発者は、将来より大きなソフトウェア・プロジェクトの構成部分として使用されるオブジェクトを生成することができる。
新しいＯＯＰソフトウェア・プログラムの９０％が既存の再使用可能なオブジェクトから製作された検証済みの既存のコンポーネントからなるとすれば、最初から書いて試験しなければならないのは新しいソフトウェア・プログラムの残りの１０％だけである。９０％はすでに広範に試験された再使用可能なオブジェクトに由来するので、誤りが発生する可能性のある領域はプログラムの１０％だけである。その結果、ソフトウェア開発者はＯＯＰによって、他のすでに構築されたオブジェクトからオブジェクトを構築することができる。
この過程は複雑な機械が組立体および下位組立体から製造されるのによく似ている。従って、ＯＯＰ技術は、ソフトウェアが、オブジェクトとして開発者に利用可能な既存のコンポーネントから構築される点で、ソフトウェア・エンジニアリングをハードウェア・エンジニアリングにより近いものにする。これらすべてのことはソフトウェアの開発速度を高めると同時に品質を改善する。
プログラミング言語はカプセル化、継承、多相性および合成関係といったＯＯＰの原理を完全にサポートするようになりつつある。Ｃ＋＋言語の出現と共に、多くの商業的なソフトウェア開発者がＯＯＰに取り組んだ。Ｃ＋＋は高速な機械により実行可能なコードを提供するＯＯＰ言語である。さらに、Ｃ＋＋は商業的アプリケーションにもシステム・プログラミング・プロジェクトにも適している。今のところ、Ｃ＋＋は多くのＯＯＰプログラマの中で最も一般的な選択であるが、Ｓｍａｌｌｔａｌｋ、ｃｏｍｍｏｎ  ｌｉｓｐ  ｏｂｊｅｃｔ  ｓｙｓｔｅｍ（ＣＬＯＳ）、およびＥｉｆｆｅｌといった他のＯＯＰ言語のホストも存在する。さらに、ＯＯＰ能力はＰａｓｃａｌのようなより以前からの一般的なコンピュータ・プログラミング言語にも追加されている。
オブジェクト・クラスの利益は以下のように要約される。
・オブジェクトとその対応するクラスは複雑なプログラミングの問題を多くの小さく単純な問題に細分する。
・カプセル化は、互いに通信可能な小さな独立したオブジェクトにデータを組織することを通じて、データの抽象化を強化する。カプセル化はオブジェクトを事故による損害から保護するが、他のデータはオブジェクトのメンバ関数と構造を呼び出すことによってそのデータと対話できる。
・下位クラス化と継承によって、システムで利用可能な標準クラスから新しい種類のオブジェクトを導出する際にオブジェクトを拡張し修正することが可能になる。すなわち、新しい能力が最初から始める必要なしに生成される。
・多相性と多重継承によって、異なったプログラマが多くの異なったクラスの特性を混合し一致させて、予測可能な方法で関連オブジェクトと共に動作する専用オブジェクトを作成することが可能になる。
・クラス階層と封じ込め階層は、現実世界の対象とそれらの間の関係をモデル化する柔軟な機構を提供する。
・再使用可能なクラスのライブラリは多くの場合有益であるが、いくつかの制限をも有する。例えば、
・複雑さ。複雑なシステムでは、関連クラスのクラス階層は、数ダースまたは数百のクラスを有する非常に込み入ったものとなる。
・制御の流れ。クラス・ライブラリによって書かれたプログラムも制御の流れに責任を負っている（すなわち、特定のライブラリから生成されたすべてのオブジェクト間の対話を制御しなければならない）。プログラマはどの機能がどの時点でどの種類のオブジェクトを呼び出すかを決定しなければならない。
・労力の重複。クラス・ライブラリによってプログラマはコードの多くの小さな部分を使用および再使用することができるが、各プログラマはこれらの部分を異なった方法で組み合わせる。２人の別のプログラマがクラス・ライブラリの同じ組を使用して全く同じことを行う２つのプログラムを書くことがあり得るが、その内部構造（すなわち設計）は、各プログラマが開発の過程で行った数百の小さな決定によって全く違っているかもしれない。必然的に、コードの小さな部分が同じことをわずかに異なった方法で行うようになり、しかるべく一緒に動作しないことになる。
クラス・ライブラリは非常に柔軟である。プログラムがより複雑になるにつれて、プログラマは基本的な問題に対する基本的なソリューションを何度も作り直さなければならなくなる。クラス・ライブラリ概念の比較的新しい拡張はクラス・ライブラリのフレークワークを有することである。このフレームワークはより複雑で、特定のアプリケーション領域で共通の要求と設計を実現する小規模なパターンと主要な機構の両方を捕捉する共同するクラスの有意の収集からなる。それはまず、パーソナル・コンピュータ用のメニュー、ウィンドウ、ダイアログボックスおよび他の標準ユーザ・インタフェース要素を表示する際必要な退屈な仕事からアプリケーション・プログラマを解放するために開発された。
フレームワークはまた、自分が書くコードと他人が書くコードの対話に関するプログラマの考え方の変化を意味する。手続き形プログラミングの初期には、プログラマはオペレーティング・システムによって提供されるライブラリを呼び出してあるタスクを行ったが、基本的にプログラムはページを最初から最後まで実行し、プログラマ１人が制御の流れの責任を負っていた。これはペイチェックの印刷、数学的表の計算または他のプログラムが１つの方向でだけ計算される問題を解くには適切である。
グラフィカル・ユーザ・インタフェースの開発がこの手続き形プログラミングの手順を徹底的に変え始めた。このインタフェースによって、プログラム論理でなくユーザがプログラムをドライブし、ある操作が行われるべきかを決定するようになる。現在パーソナル・コンピュータ・ソフトウェアの大部分はこれを、マウス、キーボードおよび外部イベントの他のソースを監視するイベント・ループによって達成し、ユーザが行う操作によってプログラマのコードの適当な部分を呼び出す。プログラマはもはやイベントが発生する順序を決定しない。そのかわり、プログラムは予測不可能な時間に予測不可能な順序で呼び出される独立した部分に細分される。この方法で制御をユーザに譲渡することによって、開発者は使用がより容易なプログラムを作成する。それにもかかわらず、開発者によって書かれたプログラムの独立した部分はオペレーティング・システムによって提供されるライブラリを呼び出してあるタスクを達成し、プログラマは各部分がイベント・ループによって呼び出された後その制御の流れを決定しなければならない。アプリケーション・コードは依然としてシステムの「最上位に」ある。
イベント・ループ・プログラムでさえ、アプリケーション毎に別個に書く必要のない多数のコードを書くことをプログラマに要求する。アプリケーション・フレームワークの概念はイベント・ループの概念をさらに進める。基本メニュー、ウィンドウおよびダイアログボックスを構成するすべてのナットとボルトを扱い、それらをすべて一緒に動作させる代わりに、アプリケーション・フレームワークを使用するプログラマは適切に動作するアプリケーション・コードと基本ユーザ・インタフェース要素から開始する。次いで、プログラマはフレームワークの一般的な能力の一部を目的アプリケーションの特定の能力によって置換することによってそこから構築を行う。
アプリケーション・フレームワークはプログラマが最初から書かなければならないコードの合計量を低減する。しかし、フレームワークは実際にはウィンドウを表示し、コピーやペーストをサポートする等の一般的なアプリケーションであるので、プログラマはイベント・ループ・プログラムで可能な以上に制御を放棄することもできる。フレームワーク・コードはほとんどすべてのイベントの処理と流れの制御を取り扱い、プログラマのコードはフレームワークがそれを必要とする時（例えば、プロプラエタリ・データ構造を作成または操作する場合）だけ呼び出される。
フレームワーク・プログラムを書くプログラマは（イベント・ループ・プログラムの場合のように）制御をユーザに譲渡するだけでなく、プログラム内の制御の詳細な流れをフレームワークに譲渡する。このアプローチによって、同様の問題のために何度も作成されるカスタム・コードを有する孤立したプログラムと異なって、興味深い方法で一緒に動作するより複雑なシステムを作成することができる。
すなわち、上記で説明したように、フレームワークは基本的に、ある問題領域について再使用可能な設計ソリューションを作り上げる共同するクラスの収集である。それには通常デフォルト挙動（例えば、メニューやウィンドウについて）が含まれ、プログラマは、フレームワークが適当なときにアプリケーション・コードを呼び出すようにそのデフォルト挙動のいくつかを継承し、他の挙動に優先させることによってそれを使用する。フレームワークとクラス・ライブラリの間には３つの主要な相違がある。
・挙動対プロトコル。クラス・ライブラリは本質的に、プログラムにその個々の挙動が欲しい時呼び出せる挙動の収集である。一方フレームワークは、挙動だけではなく、挙動が結合される方法を管理するプロトコルまたは規則の集合を提供するが、この規則にはフレームワークが提供するものに対してプログラムが提供をサポートするものに関する規則も含まれる。
・呼び出し対優先。クラス・ライブラリでは、プログラマがオブジェクトをインスタンス生成し、それらのメンバ関数を呼び出すコードが機能する。フレームワークでも同じようにオブジェクトをインスタンス生成し呼び出すこと（すなわち、フレームワークをクラス・ライブラリとして扱う）は可能だが、フレームワークの再使用可能な設計を最大限に利用するために、プログラマは通常優先しフレームワークによって呼び出されるコードを書く。フレームワークはそのオブジェクト間の制御の流れを管理する。プログラムを書くことには、異なった部分が一緒に動作する方法を指定するのではなく、フレームワークによって呼び出されるソフトウェアの様々な部分間で責任を細分することが含まれる。
・インプリメンテーション対設計。クラス・ライブラリでは、プログラマはインプリメンテーションだけを再使用するが、フレームワークでは、設計を再使用する。フレームワークは関連プログラムまたはソフトウェアの部分のファミリが動作する方法を具現する。それはある領域の多様な固有の問題に適用される一般的な設計ソリューションを表している。例えば、同じフレームワークによって作成された２つの異なったユーザ・インタフェースが全く異なったインタフェース問題を解決するとしても、１つのフレームワークはユーザ・インタフェースが動作する方法を具現できる。
すなわち、様々な問題とプログラミング・タスクを解決するフレームワークの開発を通じて、ソフトウェアの設計および開発の労力の大きな低減が達成される。本発明の好適実施形態はハイパーテキスト・マークアップ言語（ＨＴＭＬ）を利用して、クライアントと販売者間の伝送媒体用の汎用安全通信プロトコルと共にインターネット上の文書を実現する。ＨＴＭＬは、１つのプラットフォームから別のプラットフォームへ移植可能なハイパーテキスト文書を作成するために使用される簡単なデータ形式である。ＨＴＭＬ文書は、広範な領域からの情報を表すのに適した一般的な意味論を有するＳＧＭＬ言語である。ＨＴＭＬは１９９０年以来ワールド・ワイド・ウェブ・グローバル情報イニシアティブによって使用されてきた。ＨＴＭＬは、ＩＳＯ規格８８７９：１９８６情報処理テキストおよびオフィス・システム、標準一般化マークアップ言語の応用である。
現在まで、ウェブ開発ツールには、クライアントからサーバに広がり既存のコンピューティング・リソースと相互に動作する動的なウェブ・アプリケーションを作成する能力に制限があった。最近まで、ＨＴＭＬはウェブによるソリューションを開発する際使用される支配的な技術であった。しかし、ＨＴＭＬは次の部分で不十分であることが判明した。
○性能が貧弱。
○ユーザ・インタフェース能力が制限されている。
○静的ウェブ・ページしか作成できない。
○既存のアプリケーションおよびデータとの互換性がない。
○基準化ができない。
Ｓｕｎ  ＭｉｃｒｏｓｙｓｔｅｍのＪａｖａ言語は次のことによってクライアント側の問題の多くを解決している。
○クライアント側の性能の改善。
○動的実時間ウェブ・アプリケーションの作成を可能にしている。
○広範なユーザ・インタフェース・コンポーネントを作成する能力を提供する。
Ｊａｖａでは、開発者は堅牢なユーザ・インタフェース（ＵＩ）コンポーネントを作成できる。特製の「仕掛け」（例えば、実時間株式相場表示器、動くアイコン等）が作成でき、クライアント側の性能が向上する。ＨＴＭＬと異なって、Ｊａｖａはクライアント側の妥当性検査の概念をサポートし、性能を改善するため適当な処理をクライアントに肩代わりさせる。動的実時間ウェブ・ページが作成される。上記で言及したカスタムＵＩコンポーネントを使用して、動的ウェブ・ページを作成することもできる。
ＳｕｎのＪａｖａ言語は「インターネットをプログラムする」ための業界で認められた言語として出現した。ＳｕｎはＪａｖａを次のように定義している。「簡単で、オブジェクト指向で、分散形で、解釈形で、堅牢で、安全で、アーキテクチャに中立で、移植性で、高性能で、マルチスレッドで、動的で、バズワード対応の汎用プログラミング言語である。Ｊａｖａは、プラットフォームに依存しないＪａｖａアプレットという形でインターネット用プログラミングをサポートする。」ＪａｖａアプレットはＳｕｎのＪａｖａアプリケーション・プログラミング・インタフェース（ＡＰＩ）に適合する小さな専用アプリケーションであり、開発者が「対話形コンテント」（例えば、簡単なアニメーション、ページの装飾、基本的ゲーム等）をウェブ文書に追加できるようにする。アプレットはＪａｖａ互換ブラウザ（例えば、ネットスケープ・ナビゲーター）内で、サーバからクライアントにコードをコピーすることによって実行される。言語の観点から見ると、Ｊａｖａの中核的な特徴集合はＣ＋＋に基づいている。ＳｕｎのＪａｖａ文献によれば、Ｊａｖａは基本的に、「より動的な方法の解決のためのオブジェクティブＣからの拡張を伴うＣ＋＋」である。
ＪＡＶＡと同様の機能を提供する別の技術がＭｉｃｒｏｓｏｆｔとＡｃｔｉｖｅＸテクノロジーによって提供され、開発者とウェブ設計者にインターネットおよびパーソナル・コンピュータのための動的なコンテントを構築する手段を与えている。ＡｃｔｉｖｅＸにはアニメーション、３−Ｄバーチャル・リアリティ、ビデオおよび他のマルチメディア・コンテントを開発するツールが含まれる。このツールはインターネット規格を使用し、多数のプラットフォーム上で動作し、１００を超える会社によってサポートされている。グループのビルディング・ブロックはＡｃｔｉｖｅＸコントロールと呼ばれ、開発者がハイパーテキスト・マークアップ言語（ＨＴＭＬ）ページにソフトウェアの部分を埋め込めるようにする小さくて高速のコンポーネントである。ＡｃｔｉｖｅＸコントロールは、Ｍｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｃ＋＋、Ｂｏｒｌａｎｄ  Ｄｅｌｐｈｉ、Ｍｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｂａｓｉｃプログラミング・システムおよび、将来は“Ｊａｋａｒｔａ”というコードネームのＭｉｃｒｏｓｏｆｔのＪａｖａ用開発ツールをも含む多様なプログラミング言語と共に動作する。ＡｃｔｉｖｅＸテクノロジーにはＡｃｔｉｖｅＸサーバ・フレームワークも含まれ、開発者がサーバ・アプリケーションを作成できるようにする。当業技術分野に普通に熟練した者は、ＡｃｔｉｖｅＸが、本発明を実行するために不適当な実験なしにＪＡＶＡの代用となることを容易に認識するだろう。
図１Ｂは本発明の概観を示す。顧客コンピュータ・システム１２０は販売者コンピュータ・システム１３０と通信している。顧客−販売者セッション１５０は、ＳＳＬプロトコルのような汎用安全通信プロトコルの下で行われる。販売者コンピュータ・システム１３０はさらに支払いゲートウェイ・コンピュータ・システム１４０とも通信している。支払いゲートウェイは、銀行または他の金融機関をサポートして電子通商サービスを提供し、商取引の許可と回収をサポートするために金融機関とのインタフェースを有するシステムである。顧客−金融機関セッション１７０は、ここで説明されるように、Ｍｅｒｃｈａｎｔ−Ｏｒｉｇｉｎａｔｅｄ  Ｓｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓａｃｔｉｏｎｓ（販売者起源安全電子商取引）（“ＭＯＳＥＴ”）と呼ばれる、ＳＥＴプロトコルのような安全支払い技術の一形態の下で動作するが、これはここでより十分に説明される。
＜顧客から販売者への通信＞
図２は、Ｆｒｅｉｅｒで文書化され引用によって本明細書の記載に援用するＳＳＬプロトコルの下で動作する顧客−販売者セッション１５０を使用して販売者システム１３０と通信する顧客コンピュータ・システム１２０のより詳細な図を示す。
顧客コンピュータ・システム１２０は、何らかの周知のアクセス・プロトコル、例えば、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（“ＴＣＰ／ＩＰ”）を使用して販売者コンピュータ・システム１３０との通信を開始する。このインプリメンテーションでは、顧客コンピュータ・システム１２０がクライアントとして機能し、販売者コンピュータ・システム１３０がサーバとして機能する。
顧客コンピュータ・システム１２０は、「クライアント・ハロー」メッセージ２１０を販売者コンピュータ・システム１３０に送信することによって通信を開始する。クライアントは最初にサーバに接続する時その最初のメッセージとしてクライアント・ハロー・メッセージ２１０を送信する必要がある。クライアントはまた、既存の接続でセキュリティ・パラメータを再取り決めするために自発的にハロー要求に応答してクライアント・ハロー・メッセージ２１０を送信することもできる。クライアント・ハロー・メッセージにはランダム構造が含まれ、後でプロトコル中で使用される。すなわち、ランダム構造には、送信側の内部クロックと安全乱数発生器によって生成される２８バイトのデータによる標準ＵＮＩＸ３２ビット・フォーマットの現在の時間と日付が含まれる。クライアント・ハロー・メッセージ２１０にはさらに可変長セッション識別子が含まれる。空でない場合、セッション識別子の数値は同じクライアントとクライアントがセキュリティ・パラメータの再使用を希望するサーバとのセッションを示す。セッション識別子は前の接続、現在の識別または他の現在アクティブな接続に由来する。クライアントがランダム構造と接続の導出クラスのアップデートだけを希望する場合、現在の接続を指定することが有益である。クライアントがハンドシェーク・プロトコル全体を繰り返さずに同じサーバに多数の同時独立安全接続を確立したい場合、他の現在アクティブな接続を指定することが有益である。クライアント・ハロー・メッセージ２１０にはさらに、クライアントの優先順位によって配列された、クライアントの優先の順序でクライアントによってサポートされる暗号化アルゴリズムの標識が含まれる。
ハロー・メッセージ２１０に応答して、販売者コンピュータ・システム１３０は、顧客コンピュータ・システム１２０との通信を希望する場合、サーバ・ハロー・メッセージ２２１５によって応答する。顧客コンピュータ・システム１２０との通信を希望しない場合、販売者コンピュータ・システム１３０は通信の拒否を示すメッセージ（図示せず）によって応答する。
サーバ・ハロー・メッセージ２１５にはランダム構造が含まれ、後でプロトコル中で使用される。サーバ・ハロー・メッセージ２１５中のランダム構造は、クライアント・ハロー・メッセージ２１０中のランダム構造と同じフォーマットであるが、それと無関係なコンテントを有する。すなわち、このランダム構造には、送信側の内部クロックと安全乱数発生器によって生成される２８バイトのデータによる標準ＵＮＩＸ３２ビット・フォーマットの現在の時間と日付が含まれる。サーバ・ハロー・メッセージ２１５にはさらに、可変長セッション識別子が含まれる。セッション識別子の数値は同じクライアントとサーバの間の新規または既存のセッションを示す。サーバ・ハロー・メッセージ２１５にはさらにクライアント・ハロー・メッセージ２１０によって指定されたアルゴリズムの中から選択された暗号化アルゴリズムの標識が含まれ、さらに暗号化通信のために使用される。
必要に応じて、販売者コンピュータ・システム１３０はサーバ証明２２０を送信する。送信される場合、サーバ証明１３０によって顧客コンピュータ・システム１２０は販売者コンピュータ・システム１３０の身元を確認できる。
販売者コンピュータ・システム１３０がサーバ証明２２０を送信しないか、またはサーバ証明２２０が認証にだけ適している場合、必要に応じてサーバ・キー交換メッセージ２２５が送信される。サーバ・キー交換メッセージ２２５は販売者コンピュータ・システム１３０によって送信されたメッセージをその後解読するため顧客コンピュータ・システム１２０によって使用されるキーを特定する。
サーバ・ハロー・メッセージ２１５を送信し、必要に応じてサーバ証明２２０またはサーバ・キー交換メッセージ２２５を送信した後、販売者コンピュータ・システム１３０はサーバ・ハロー終了メッセージ２３０を送信し、顧客コンピュータ・システム１２０からの次の応答を待つ。
顧客コンピュータ・システム１２０は必要に応じてクライアント証明２４０を販売者コンピュータ・システム１３０に送信する。送信される場合、クライアント証明２４０によって販売者コンピュータ・システム１３０は顧客コンピュータ・システム１２０の身元を確認できる。また、顧客コンピュータ・システム１２０はクライアント証明なし警告２４５を送信し、顧客がどの認証機関にも登録されていないことを示すこともある。
顧客コンピュータ・システム１３０がクライアント証明２４０を送信しないか、クライアント証明２４０が認証にだけ適している場合、顧客コンピュータ・システム１３０は必要に応じてクライアント・キー交換メッセージ２５０を送信する。クライアント・キー交換メッセージ２５０は、顧客コンピュータ・システム１２０によって送信されたメッセージをその後解読するため販売者コンピュータ・システム１３０によって使用されるキーを特定する。
クライアント証明２４０、クライアント証明なし警告２４５および／またはクライアント・キー交換メッセージ２５０を必要に応じて送信した後、顧客コンピュータ・システム１２０は終了メッセージ２６０を送信する。
この時点で、顧客コンピュータ・システム１２０と販売者コンピュータ・システム１３０は、
１）今後の通信で共通して使用される暗号化スキームを取り決めた。
２）２つのコンピュータ・システム間の今後の通信を解読するために使用される１組の暗号化キーを互いに伝達した。
顧客コンピュータ・システム１２０と販売者コンピュータ・システム１３０はその後第三者によって傍受される危険の少ない安全通信２７０に入る。
顧客コンピュータ・システム１２０によって販売者コンピュータ・システム１３０に伝達されるメッセージの中には、注文される商品またはサービスと、注文される商品および／またはサービスの支払いのために使用される、総称して「支払い情報」と呼ばれるクレジット・カード番号と関連情報のような支払い情報を記載するメッセージがある。支払いを得るために、販売者はこの情報を銀行または好適な支払い方法に責任を負う他の支払いゲートウェイに供給する。これによって販売者は支払い許可と支払い回収が可能になる。支払い許可は金融機関に代わって機能する支払いゲートウェイによって許可が与えられ、金融機関に代わって支払いを許可する処理である。これは、商取引の危険を査定し、ある商取引が口座名義人の債務をその口座の信用限度以上にしないことを確認し、規定の金額の信用を確保する処理である。支払い回収は金融機関から販売者の口座への資金の移動を引き起こす処理である。
＜支払い許可＞
図３は、支払い許可を得るために支払い情報を支払いゲートウェイに安全に供給する方法の概観を示す。機能ブロック３１０では、販売者コンピュータ・システム１３０は支払い許可要求３１５を生成し、それを支払いゲートウェイ・コンピュータ・システム１４０に送信する。機能ブロック３３０では、支払いゲートウェイ・システム１４０は支払い許可要求を処理し、支払い許可応答３２５を生成し、それを販売者コンピュータ・システム１３０に送信する。機能ブロック３２０では、販売者コンピュータ・システム１３０は支払い許可応答３２５を処理し、顧客が獲得を要求した商品またはサービスに対する支払いが許可されたかを判断する。
＜支払い許可要求の生成＞
図４は、支払い許可要求を生成し送信する詳細なステップを示す。図５Ａ〜図５Ｆは支払い許可要求とその構成部分の図を示す。機能ブロック４１０では、販売者コンピュータ・システム１３０が基本許可要求５１０を生成する。基本許可要求は供給が許可されるべきかまたは拒否されるべきかを決定するすべての情報を含むデータ領域である。すなわち、それには請求される当事者、請求金額、請求される当事者の口座番号および、パスワード等の請求を有効にするために必要な付加的データのような情報が含まれる。この情報は、前の顧客の商品選択に基づいて計算されるか、または顧客−販売者の汎用安全通信プロトコル・セッションで確立された安全なリンク２７０を通じて顧客によって提供される。図５Ａは基本許可要求５１０を示す。
機能ブロック４２０では、販売者コンピュータ・システム１３０は、基本許可要求５１０、販売者の暗号化公開キー証明５１５のコピーおよび販売者の署名公開キー証明５２０のコピーを結合する。販売者コンピュータ・システム１３０は、基本許可要求５１０、暗号化公開キー証明５１５および署名公開キー証明５２０を含む結合ブロック５３０の結合されたコンテントについてデジタル署名５２５を計算し、それを結合された基本許可要求５１０、暗号化公開キー証明５１５および署名公開キー証明５２０の結合に添付する。販売者コンピュータ・システムは、まず結合された基本許可要求５１０、暗号化公開キー証明５１５および署名公開キー証明５２０のコンテントに基づいて「メッセージ要約」を計算することによってデジタル署名５２５を計算する。メッセージ要約は、可変長メッセージが単方向ハッシュ関数に供給される場合生成される固定長結果である。メッセージが変更されると要約も変化するため、メッセージ要約はメッセージが変更されていないことを照合する助けになる。その後メッセージ要約は販売者コンピュータ・システム１３０のデジタル署名秘密キーを使用して暗号化され、デジタル署名を形成する。
図５Ｂは、機能ブロック４２０で形成され、基本許可要求５１０、暗号化公開キー証明５１５、署名公開キー証明５２０およびデジタル署名５２５を含む結合ブロック５３０を示す。
機能ブロック４３０では、販売者コンピュータ・システム１３０は、ＲＫ−０として示されるランダム暗号化キーＲＫ−０  ５４０を生成する。ランダム暗号化キーＲＫ−０５４０は対称暗号化キーである。対称暗号化キーは、対称キーで暗号化されたメッセーは同じキーで解読できるという特性を特徴とするキーである。これは、キーの組み合わせの１つのキーで暗号化されたメッセージは同じキーの組み合わせのもう１つのキーでしか解読できない公開キー／秘密キーの組み合わせのような非対称キー組み合わせの場合と対照的である。図５Ｃはランダム暗号化キーＲＫ−０  ５４０を示す。
機能ブロック４４０では、販売者コンピュータ・システム１３０はランダム暗号化キーＲＫ−０  ５４０を使用して結合ブロック５３０を暗号化し、暗号化結合ブロック５５０を形成する。図５Ｄは暗号化結合ブロック５５０を示す。暗号化結合ブロック５５０の暗号化状態がランダム・キー・ロック５５５によって図示され、暗号化結合ブロック５５０がランダム・キーＲＫ−０  ５４０を使用して暗号化されていることを示す。
機能ブロック４５０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・システム１４０の公開キーを使用してランダム暗号化キーＲＫ−０  ５４０を暗号化し、暗号化ランダム・キー５６０を形成する。図５Ｅは暗号化ランダム・キー５６０を示す。暗号化ランダム・キー５６０の暗号化状態が支払いゲートウェイ公開キー・ロック５６５によって図示され、暗号化ランダム・キー５６０が支払いゲートウェイ公開キーを使用して暗号化されていることを示す。
機能ブロック４６０では、販売者コンピュータ・システム１３０は暗号化結合ブロック５５０と暗号化ランダムキー５６０を連結して販売者許可要求３１５を形成する。図５Ｆは、暗号化結合ブロック５５０と暗号化ランダム・キー５６０を含む販売者許可要求３１５を示す。機能ブロック４７０では、販売者コンピュータ・システム１３０が販売者許可要求３１５を支払いゲートウェイ・システム１４０に送信する。
＜支払い許可要求の処理＞
図６は、支払い許可要求を処理し支払い許可要求応答を生成し送信する詳細なステップを示す。機能ブロック６１０〜６３０は、支払い許可要求を処理するステップを示し、機能ブロック６３５〜６８５は支払い許可要求応答を生成し送信するステップを示す。
機能ブロック６１０では、支払いゲートウェイ・コンピュータ・システム１４０はその秘密キーを受信された販売者許可要求３１５に含まれる暗号化ランダム・キー５６０に適用することによってそれを解読し、ランダム・キーＲＫ−０  ５４０の平文バージョンを得る。機能ブロック６１５では、支払いゲートウェイ・コンピュータ・システム１４０はランダム・キーＲＫ−０  ５４０を暗号化結合ブロック５５０に適用することによってそれを解読し、結合ブロック５３０の平文バージョンを得る。結合ブロック５３０は、販売者デジタル署名５２５と共に、基本許可要求５１０、販売者コンピュータ・システム１３０の暗号化公開キー証明５１５のコピーおよび、販売者コンピュータ・システム１３０の署名公開キー証明５２０のコピーを含む。
機能ブロック６２０では、支払いゲートウェイ・コンピュータ・システム１４０は、販売者コンピュータ・システム１３０の暗号化公開キー証明５１５と販売者コンピュータ・システム１３０の署名公開キー証明５２０を照合する。支払いゲートウェイ・コンピュータ・システム１４０は、各証明に関連する証明機関に呼出を行うことによってこの照合を行う。何れかの証明の照合が失敗した場合、支払いゲートウェイ・コンピュータ・システム１４０は許可要求を拒否する。
機能ブロック６２５では、支払いゲートウェイ・コンピュータ・システム１４０は販売者デジタル署名５２５を照合する。支払いゲートウェイ・コンピュータ・システム１４０は、結合基本許可要求５１０、暗号化公開キー証明５１５および署名公開キー証明５２０のコンテントについてメッセージ要約を計算することによってこの照合を行う。その後支払いゲートウェイ・コンピュータ・システム１４０はデジタル署名５２５を解読して機能ブロック４２０で販売者コンピュータ・システム１３０によって計算された同等のメッセージ要約のコピーを得る。２つのメッセージ要約が等しい場合、デジタル署名５２５の正当性が確認される。照合が失敗した場合、支払いゲートウェイ・コンピュータ・システム１４０は許可要求を拒否する。
機能ブロック６３０では、支払いゲートウェイ・コンピュータ・システム１４０は、基本許可要求５１０の検査によって許可が要求されている金融機関を判断する。支払いゲートウェイ・コンピュータ・システム１４０は安全な手段、例えば、直接ダイヤル・モデム対モデム接続または第三者にアクセスできないプロプラエタリ内部ネットワークを使用して適切な金融機関に接触し、先行技術の手段を使用して要求された支払いが許可されるかを示す応答を得る。
＜支払い許可応答の生成＞
機能ブロック６３５〜６８５は支払い許可要求応答を生成し送信するステップを示す。図７Ａ〜図７Ｊは支払い許可応答とその構成部分の図を示す。
機能ブロック６３５では、支払いゲートウェイ・コンピュータ・システム１４０は基本許可応答７１０を作成する。基本許可要求は、要求が許可されたかまたは拒否されたかを判断するためのすべての情報を含むデータ範囲である。図７Ａは基本許可応答７１０を示す。
機能ブロック６４０では、支払いゲートウェイ・コンピュータ・システム１４０は基本許可応答７１０とその署名公開キー証明７２０のコピーを結合する。支払いコンピュータ・システム１４０は基本許可応答７１０と署名公開キー証明７２０を含む結合ブロック７３０の結合されたコンテントについてデジタル署名７２５を計算し、その署名を結合された基本許可応答７１０と署名公開キー証明７２０の結合に添付する。支払いゲートウェイ・コンピュータ・システムは、まず結合された基本許可応答７１０と署名公開キー証明７２０のコンテントに基づいてメッセージ要約を計算することによってデジタル署名７２５を計算する。その後メッセージ要約は販売者コンピュータ・システム１４０のデジタル署名公開キーを使用して暗号化され、デジタル署名を形成する。
図７Ｂは機能ブロック６４０で形成され、基本許可応答７１０、署名公開キー証明７２０およびデジタル署名７２５を含む結合ブロック７３０を示す。
機能ブロック６４５では、支払いゲートウェイ・コンピュータ・システム１５０はＲＫ−１として示される第１対称ランダム暗号化キー７４０を生成する。図７Ｃは第１ランダム暗号化キーＲＫ−１  ７４０を示す。
機能ブロック６５０では、支払いゲートウェイ・コンピュータ・システム１４０はランダム暗号化キーＲＫ−１  ７４０を使用して結合ブロック７３０を暗号化し、暗号化結合ブロック７５０を形成する。図７Ｄは暗号化結合ブロック７５０を示す。暗号化結合ブロック７５０の暗号化状態がランダム・キー・ロック７５５によって図示され、暗号化結合ブロック７５０がランダム・キーＲＫ−１  ７４０を使用して暗号化されていることを示す。
機能ブロック６５５では、支払いゲートウェイ・コンピュータ・システム１４０は販売者コンピュータ・システム１３０の公開キーを使用してランダム暗号化キーＲＫ−１  ７４０を暗号化し、暗号化ランダム・キーＲＫ  ７６０を形成する。図７Ｅは暗号化ランダム・キーＲＫ−１  ７６０を示す。暗号化ランダム・キー７６０の暗号化状態が販売者公開キー・ロック７６５によって図示され、暗号化ランダム・キー７６０が販売者公開キーを使用して暗号化されていることを示す。
機能ブロック６６０では、支払いゲートウェイ・コンピュータ・システム１４０はランダム回収トークン７７０を生成する。ランダム回収トークン７７０は後続の支払い回収処理で使用され、支払い回収要求を処理される支払い許可要求に関連させる。図７Ｆは回収トークン７７５を示す。
機能ブロック６６５では、支払いゲートウェイ・コンピュータ・システム１４０はＲＫ−２として示される第２対称ランダム暗号化キー７７５を生成する。図７Ｇは第２ランダム暗号化キーＲＫ−２  ７７５を示す。
機能ブロック６７０では、支払いゲートウェイ・コンピュータ・システム１４０はランダム暗号化キーＲＫ−２  ７７０を使用して回収トークン７７０を暗号化し、暗号化回収トークン７８０を形成する。図７Ｈは暗号化回収トークン７８０を示す。暗号化回収トークン７８０の暗号化状態がランダム・キー・ロック７８５によって図示され、暗号化回収トークン７８０がランダム・キーＲＫ−２  ７７０を使用して暗号化されていることを示す。
機能ブロック６７５では、支払いゲートウェイ・コンピュータ・システム１４０はそれ自体の公開キーを使用して第２ランダム暗号化キーＲＫ−２  ７７５を暗号化し、暗号化ランダム・キーＲＫ−２  ７９０を形成する。図７Ｉは暗号化ランダムキーＲＫ−２  ７９０を示す。暗号化ランダム・キー７９０の暗号化状態が支払いゲートウェイ公開キー・ロック７９５によって図示され、暗号化ランダム・キー７９０が支払いゲートウェイ公開キーを使用して暗号化されていることを示す。
機能ブロック６８０では、支払いゲートウェイ・コンピュータ・システム１４０は、暗号化結合ブロック７５０、暗号化ランダム・キーＲＫ−１  ７６０、暗号化回収トークン７８０および暗号化ランダム・キーＲＫ−２  ７９０を連結し、販売者許可応答３２５を形成する。図７Ｊは、暗号化結合ブロック７５０、暗号化ランダム・キーＲＫ−１  ７６０、暗号化回収トークン７８０および暗号化ランダム・キーＲＫ−２  ７９０を含む販売者許可応答３２５を示す。機能ブロック６８５では、支払いゲートウェイ・コンピュータ・システム１４０は販売者許可応答３２５を販売者システム１３０に送信する。
＜支払い許可応答の処理＞
図８は支払い許可応答を処理する詳細なステップを示す。機能ブロック８１０では、販売者コンピュータ・システム１３０は、その秘密キーを受信された販売者許可応答３２５に含まれる暗号化ランダム・キーＲＫ−１  ７６０に適用することによってそれを解読し、ランダム・キーＲＫ−１  ７４０の平文バージョンを得る。
機能ブロック８２０では、販売者コンピュータ・システム１３０はランダム・キーＲＫ−１  ７４０を暗号化結合ブロック７５０に適用することによってそれを解読し、結合ブロック７３０の平文バージョンを得る。結合ブロック７３０は、支払いゲートウェイ・デジタル署名７２５と共に、基本許可応答７１０、支払いゲートウェイ・コンピュータ・システム１４０の署名公開キー証明７２０を含むことが想起される。
機能ブロック８３０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・コンピュータ・システム１４０の署名公開キー証明７２０を照合する。販売者コンピュータ・システム１３０は、その証明に関連する証明機関に呼出を行うことによってこの証明を行う。証明の照合が失敗した場合、販売者コンピュータ・システム１３０は許可応答は偽造であると結論し、許可要求が拒否されたものとして処理する。
機能ブロック８４０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・デジタル署名７２５の正当性を確認する。販売者コンピュータ・システム１３０は、結合された基本許可要求７１０と署名公開キー証明７２０のコンテントについてメッセージ要約を計算することによってこの確認を行う。その後販売者コンピュータ・システム１３０はデジタル署名７２５を解読し、機能ブロック６４０で支払いゲートウェイ・コンピュータ・システム１４０によって計算された同等のメッセージ要約のコピーを得る。２つのメッセージ要約が等しい場合、デジタル署名７２５の正当性が確認される。確認が失敗した場合、許可応答は偽造であると結論され、許可要求が拒否されたものとして処理される。
機能ブロック８５０では、販売者コンピュータ・システム１３０は、後で支払い回収の際使用するために、暗号化回収トークン７８０と暗号化ランダム・キーＲＫ−２  ７９０を保存する。機能ブロック８６０では、販売者コンピュータ・システム１３０は許可応答７１０に従って顧客購入要求を処理する。許可応答によって支払いが許可されていることが示される場合、販売者コンピュータ・システム１３０は要求された注文に応じる。許可応答によって支払いが許可されていないことが示される場合、または販売者コンピュータ・システム１３０が機能ブロック８３０または８４０で許可応答が偽造であると判断した場合、販売者コンピュータ・システム１３０は注文に応じられないことを顧客に示す。
＜支払い回収＞
図９は、支払い回収を得るために、支払い回収情報を支払いゲートウェイ１４０に安全に供給する方法の概観を示す。機能ブロック９１０では、販売者コンピュータ・システム１３０は販売者支払い回収要求９１５を生成し、それを支払いゲートウェイ・コンピュータ・システム１４０に送信する。機能ブロック９３０では、支払いゲートウェイ・システム１４０は支払い回収要求９１５を処理し、支払い回収応答９２５を生成し、それを販売者コンピュータ・システム１３０に送信する。機能ブロック９２０では、販売者コンピュータ・システム１３０は支払い回収応答９２５を処理し、顧客が獲得を要求した商品またはサービスの支払いが回収されたかを照合する。
＜支払い回収要求の生成＞
図１０は支払い回収要求を生成し送信する詳細なステップを示す。図１１Ａ〜図１１Ｆは支払い回収要求とその構成部分の図を示す。機能ブロック１０１０では、販売者コンピュータ・システム１３０が基本回収要求５１０を作成する。基本回収要求は、販売者が運用する販売者コンピュータ・システム１３０に資金の移動を引き起こすために支払いゲートウェイ・コンピュータ・システム１４０が必要とするすべての情報を含むデータ範囲である。
すなわち、回収要求には、個々の販売者に関する回収要求金額、回収トークン、日付、購入品目と販売者ＩＤ（ＭＩＤ）が含まれる。図１１Ａは基本許可要求１１１０を示す。
機能ブロック１０２０では、販売者コンピュータ・システム１３０は基本回収要求１１１０、その暗号化公開キー証明１１１５のコピーおよび、その署名公開キー証明１１２０のコピーを結合する。販売者コンピュータ・システム１３０は、基本回収要求１１１０、暗号化公開キー証明１１１５および署名公開キー証明１１２０を含む結合ブロック１１３０の結合されたコンテントについてデジタル署名１１２５を計算し、それを結合された基本回収要求１１１０、暗号化公開キー証明１１１５および署名公開キー証明１１２０の組み合わせに添付する。販売者コンピュータ・システムは、まず結合された基本回収要求１１１０、暗号化公開キー証明１１１５および署名公開キー証明１１２０のコンテントについてメッセージ要約を計算することによってデジタル署名１１２５を計算する。その後メッセージ要約は販売者コンピュータ・システム１３０のデジタル署名秘密キーを使用して暗号化され、デジタル署名を形成する。
図１１Ｂは機能ブロック１０２０で形成され、基本回収要求１１１０、暗号化公開キー証明１１１５、署名公開キー証明１１２０およびデジタル署名１１２５を含む結合ブロック１１３０を示す。
機能ブロック１０３０では、販売者コンピュータ・システム１３０はＲＫ−３として示されるランダム暗号化キー１１４０を生成する。ランダム暗号化キーＲＫ−３  １１４０は対称暗号化キーである。図１１Ｃはランダム暗号化キーＲＫ−３  １１４０を示す。
機能ブロック１０４０では、販売者コンピュータ・システム１３０はランダム暗号化キーＲＫ−３  １１４０を使用して結合ブロック１１３０を暗号化し、暗号化結合ブロック１１５０を形成する。図１１Ｄは暗号化結合ブロック１１５０を示す。暗号化結合ブロック１１５０の暗号化状態がランダム・キー・ロック１１５５によって図示され、暗号化結合ブロック１１５０がランダム・キーＲＫ−３  １１４０を使用して暗号化されていることを示す。
機能ブロック１０５０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・システム１４０の公開キーを使用してランダム暗号化キーＲＫ−３  １１４０を暗号化し、暗号化ランダム・キー１１６０を形成する。図１１Ｅは暗号化ランダム・キー１１６０を示す。暗号化ランダム・キー１１６０の暗号化状態が支払いゲートウェイ公開キー・ロック１１６５によって図示され、暗号化ランダム・キーＲＫ−３  １１６０が支払いゲートウェイ公開キーを使用して暗号化されていることを示す。
機能ブロック１０６０では、販売者コンピュータ・システム１３０は、暗号化結合ブロック１１５０、暗号化ランダム・キー１１６０と、機能ブロック８５０で保存された暗号化回収トークン７８０および暗号化ランダム・キーＲＫ−２  ７９０を連結し、販売者回収要求９１５を形成する。図１１Ｆは、暗号化結合ブロック１１５０、暗号化ランダム・キー１１６０、暗号化回収トークン７８０および暗号化ランダム・キーＲＫ−２  ７９０を含む販売者回収要求９１５を示す。機能ブロック１０７０では、販売者コンピュータ・システム１３０は販売者回収要求９１５を販売者ゲートウェイ・システム１４０に送信する。
＜支払い回収要求の処理＞
図１２は、支払い回収要求を処理し、支払い回収要求応答を生成し送信する詳細なステップを示す。機能ブロック１２１０〜１２４５は支払い回収要求を処理するステップを示し、機能ブロック１２５０〜１２８５は支払い回収要求応答を生成し送信するステップを示す。
機能ブロック１２１０では、支払いゲートウェイ・コンピュータ・システム１４０はその秘密キーを受信された販売者回収要求９１５の中に含まれる暗号化ランダム・キー１１６０に適用することによってそれを解読し、ランダム・キーＲＫ−３  １１４０の平文バージョンを得る。機能ブロック１２１５では、支払いゲートウェイ・コンピュータ・システム１４０はランダム・キーＲＫ−３  １１４０を暗号化結合ブロック１１５０に適用することによってそれを解読し、結合ブロック１１３０の平文バージョンを得る。結合ブロック１１３０は、販売者デジタル署名１１２５と共に、基本回収要求１１１０、販売者コンピュータ・システム１３０の暗号化公開キー証明１１１５のコピーおよび、販売者コンピュータ・システム１３０の署名公開キー証明１１２０のコピーを含むことが想起される。
機能ブロック１２２０では、支払いゲートウェイ・コンピュータ・システム１４０は販売者コンピュータ・システム１３０の暗号化公開キー証明１１１５と販売者コンピュータ・システム１３０の署名公開キー証明１１２０を照合する。支払いゲートウェイ・コンピュータ・システム１４０は、各証明に関連する証明機関に呼出を行うことによってこの照合を行う。何れかの証明が失敗した場合、支払いゲートウェイ・コンピュータ・システム１４０は回収要求を拒否する。
機能ブロック１２２５では、支払いゲートウェイ・コンピュータ・システム１４０は販売者デジタル署名１１２５の正当性を確認する。支払いゲートウェイ・コンピュータ・システム１４０は、結合された基本回収要求１１１０、暗号化公開キー証明１１１５および署名公開キー証明１１２０のコンテントについてメッセージ要約を計算することによってこの確認を行う。その後支払いゲートウェイ・コンピュータ・システム１４０はデジタル署名１１２５を解読して、機能ブロック１０２０で販売者コンピュータ・システム１３０によって計算された同等のメッセージ要約のコピーを得る。２つのメッセージ要約が等しい場合、デジタル署名１１２５の正当性が確認される。確認が失敗した場合、支払いゲートウェイ・コンピュータ・システム１４０は回収要求を拒否する。
機能ブロック１２３０では、支払いゲートウェイ・コンピュータ・システム１４０はその秘密キーを、受信された販売者回収要求９１５の中に含まれる暗号化ランダム・キーＲＫ−２  ７９０に適用することによってそれを解読し、ランダム・キーＲＫ−２  ７７５の平文バージョンを得る。機能ブロック１２３５では、支払いゲートウェイ・コンピュータ・システム１４０はランダム・キーＲＫ−２  ７７５を暗号化回収トークン７８０に適用することによってそれを解読し、回収トークン７７０の平文バージョンを得る。
機能ブロック１２４０では、支払いゲートウェイ・コンピュータ・システム１４０は、回収トークン７８０と回収要求１１１０の間で適切なトランザクションが伝送されていることを照合する。回収トークンはゲートウェイが許可の時点で生成するデータを含む。許可が承認されると、暗号化回収トークンは販売者に伝えられ保存される。回収の時点で、販売者は回収トークンを回収のために必要な他の情報と共にゲートウェイに返送する。回収トークンを受信すると、ゲートウェイは回収要求データからなるメッセージと回収トークン・データを比較し、この情報を従来のクレジット／デビット・ネットワークを通じて送信する。不適切にフォーマットされたトランザクションが検出されると、支払いゲートウェイ・コンピュータ・システム１４０は回収要求を拒否する。
機能ブロック１２４５では、支払いゲートウェイ・コンピュータ・システム１４０は、基本回収要求１１１０を検査することによって回収が要求される金融機関を決定する。支払いゲートウェイ・コンピュータ・システム１４０は安全な手段、例えば、直接ダイヤル・モデム対モデム接続、または第三者にアクセスできないプロプラエタリ内部ネットワークを使用して適切な金融機関に接触し、先行技術の手段を使用して、要求された資金の移動を行うよう金融機関のコンピュータに指示する。
＜支払い回収応答の生成＞
機能ブロック１２５０〜１２８５は支払い回収要求応答を生成し送信するステップを示す。図１３Ａ〜図１３Ｆは支払い回収応答とその構成部分の図を示す。
機能ブロック１２５０では、支払いゲートウェイ・コンピュータ・システム１４０は基本回収応答７１０を生成する。基本回収要求には、回収要求が認められたかまたは拒否されたかを示すすべての情報が含まれる。図１３Ａは基本許可要求１３１０を示す。
機能ブロック１２５５では、支払いゲートウェイ・コンピュータ・システム１４０は基本回収応答１３１０とその署名公開キー証明１３２０のコピーを結合する。支払いコンピュータ・システム１４０は、基本回収応答１３１０と署名公開キー証明１３２０を含む結合ブロック１３３０の結合されたコンテントについてデジタル署名１３２５を計算し、その署名を結合された基本許可要求１３１０と署名公開キー証明１３２０の組み合わせに添付する。支払いゲートウェイ・コンピュータ・システムは、まず結合された基本回収応答１３１０と署名公開キー証明７２０のコンテントについてメッセージ要約を計算することによってデジタル署名１３２５を計算する。その後メッセージ要約は販売者コンピュータ・システム１４０のデジタル署名秘密キーを使用して暗号化され、デジタル署名を形成する。
図１３Ｂは、機能ブロック１２５５で形成され、基本回収要求１３１０、署名公開キー証明１３２０およびデジタル署名１３２５を含む結合ブロック１３３０を示す。
機能ブロック１２６０では、支払いゲートウェイ・コンピュータ・システム１４０は、ＲＫ−４として示される対称ランダム暗号化キー１３４０を生成する。図１３Ｃはランダム暗号化キーＲＫ−４  １３４０を示す。
機能ブロック１２７５では、支払いゲートウェイ・コンピュータ・システム１４０は、ランダム暗号化キーＲＫ−４  １３４０を使用して結合ブロック１３３０を暗号化し、暗号化結合ブロック１３５０を形成する。図１３Ｄは暗号化結合ブロック１３５０を示す。暗号化結合ブロック１３５０の暗号化状態がランダム・キー・ロック１３５５によって図示され、暗号化結合ブロック１３５０がランダム・キーＲＫ−４  １３４０を使用して暗号化されていることを示す。
機能ブロック１２７５では、支払いゲートウェイ・コンピュータ・システム１４０は、販売者コンピュータ・システム１３０の公開キーを使用してランダム暗号化キーＲＫ−４  １３４０を暗号化し、暗号化ランダム・キーＲＫ−４  １３６０を形成する。図１３Ｅは暗号化ランダム・キーＲＫ−４  １３６０を示す。暗号化ランダム・キー１３６０の暗号化状態が販売者公開キー・ロック１３６５によって図示され、暗号化ランダム・キー１３６０が販売者公開キーを使用して暗号化されていることを示す。
機能ブロック１２８０では、支払いゲートウェイ・コンピュータ・システム１４０は暗号化結合ブロック１３５０と暗号化ランダム・キーＲＫ−４  １３６０を連結し、販売者回収応答９２５を形成する。図１３Ｆは、暗号化結合ブロック１３５０と暗号化ランダム・キーＲＫ−４  １３６０を含む販売者回収応答９２５を示す。機能ブロック１２８５では、支払いゲートウェイ・コンピュータ・システム１４０は販売者回収応答９２５を販売者システム１３０に送信する。
＜支払い回収応答の処理＞
図１４は支払い回収応答を処理する詳細なステップを示す。機能ブロック１４１０では、販売者コンピュータ・システム１３０は、その秘密キーを、受信された販売者回収応答９２５に含まれる暗号化ランダム・キーＲＫ−４  １３６０に適用することによってそれを解読し、ランダム・キーＲＫ−４  １３４０の平文バージョンを得る。
機能ブロック１４２０では、販売者コンピュータ・システム１３０はランダム・キーＲＫ−４  １３４０を暗号化結合ブロック１３５０に適用することによってそれを解読し、結合ブロック１３３０の平文バージョンを得る。結合ブロック１３３０が、支払いゲートウェイ・デジタル署名１３２５と共に、基本回収応答１３１０、支払いゲートウェイ・コンピュータ・システム１４０の署名公開キー証明１３２０を含むことが想起される。
機能ブロック１４３０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・コンピュータ・システム１４０の署名公開キー証明１３２０を照合する。販売者コンピュータ・システム１３０は、その証明に関連する証明機関に呼出を行うことによってこの照合を行う。証明の照合が失敗した場合、販売者コンピュータ・システム１３０は回収応答は偽造であると結論し、誤り状態を提起する。
機能ブロック１４４０では、販売者コンピュータ・システム１３０は支払いゲートウェイ・デジタル署名１３２５の正当性を確認する。販売者コンピュータ・システム１３０は、結合された基本許可要求１３１０と署名公開キー証明１３２０のコンテントについてメッセージ要約を計算することによってこの確認を行う。その後販売者コンピュータ・システム１３０はデジタル署名１３２５を解読し、機能ブロック１２５５で支払いゲートウェイ・コンピュータ・システム１４０によって計算された同等のメッセージ要約のコピーを得る。２つのメッセージ要約が等しい場合、デジタル署名１３２５の正当性が確認される。確認が失敗した場合、販売者コンピュータ・システム１３０は許可応答が偽造であると結論し、誤り状態を提起する。
機能ブロック１４５０では、支払いコンピュータ・システム１３０は、例えば、販売者が運用する販売者コンピュータ・システム１３０と、支払いを要求する主体であった金融機関との間の調停を行うために後で遺贈システム計算プログラムによって使用するために回収応答を保存し、トランザクションを完了する。
本発明のシステムは、消費者によって使用される公開キー暗号化インフラストラクチャを最初に確立しないでも、ＳＥＴのような安全支払い技術アーキテクチャの即時配置を可能にする。そのため、消費者がＳＥＴ対応アプリケーション・ソフトウェアに乗り換える必要なしにＳＥＴ対応トランザクション処理を即時使用することが可能である。
本明細書中で言及されたすべての刊行物と既存下位システムは、個々の刊行物または既存下位システムの各々が明確かつ個別に引用によって本明細書の記載に援用すると示されたのと同程度に、ここで引用によって本明細書の記載に援用する。
【図１Ａ】
0004166280.tif 000002
【図１Ｂ】
0004166280.tif 000003
【図２】
0004166280.tif 000004
【図３】
0004166280.tif 000005
【図４】
0004166280.tif 000006
【図５Ａ】
0004166280.tif 000007
【図５Ｂ】
0004166280.tif 000008
【図５Ｃ】
0004166280.tif 000009
【図５Ｄ】
0004166280.tif 000010
【図５Ｅ】
0004166280.tif 000011
【図５Ｆ】
0004166280.tif 000012
【図６Ａ】
0004166280.tif 000013
【図６Ｂ】
0004166280.tif 000014
【図７Ａ】
0004166280.tif 000015
【図７Ｂ】
0004166280.tif 000016
【図７Ｃ】
0004166280.tif 000017
【図７Ｄ】
0004166280.tif 000018
【図７Ｅ】
0004166280.tif 000019
【図７Ｆ】
0004166280.tif 000020
【図７Ｇ】
0004166280.tif 000021
【図７Ｈ】
0004166280.tif 000022
【図７Ｉ】
0004166280.tif 000023
【図７Ｊ】
0004166280.tif 000024
【図８】
0004166280.tif 000025
【図９】
0004166280.tif 000026
【図１０】
0004166280.tif 000027
【図１４】
0004166280.tif 000028
【図１１Ａ】
0004166280.tif 000029
【図１１Ｂ】
0004166280.tif 000030
【図１１Ｃ】
0004166280.tif 000031
【図１１Ｄ】
0004166280.tif 000032
【図１１Ｅ】
0004166280.tif 000033
【図１１Ｆ】
0004166280.tif 000034
【図１２Ａ】
0004166280.tif 000035
【図１２Ｂ】
0004166280.tif 000036
【図１３Ａ】
0004166280.tif 000037
【図１３Ｂ】
0004166280.tif 000038
【図１３Ｃ】
0004166280.tif 000039
【図１３Ｄ】
0004166280.tif 000040
【図１３Ｅ】
0004166280.tif 000041
【図１３Ｆ】
0004166280.tif 000042