JPH11511876A - コンピュータネットワーク上での購買関連取引の電子的な支払い方法 - Google Patents

Abstract

(57)【要約】 供給者サーバー２０と顧客の端末３０とが接続される公衆コミュニケーションネットワーク１０を使用した方法であって、−供給者と顧客とのあいだで認識された購買に関連し、かつ、前記供給者、前記顧客、前記購買対象物および価格に関する情報からなる支払いチケットを、供給者サーバーにより作成すること、−支払いサーバー４０へコンピュータネットワークを介して前記支払いチケットを転送すること、−前記支払いサーバーによって、代価の支払いを顧客が認めたかどうかの自動的照合を、支払いサーバーにより保持され、かつ、少額の支払いのために意図された、顧客のカスタマーアカウントの問合わせ、または高額の支払いのために、コンピュータネットワーク１０とは独立した銀行ネットワーク５０の問合わせのいずれかによって、支払われるべき額のレベルに応じて実行すること、−前記照合がポジティブなばあい、支払いサーバーが取引の許可、または支払いチケット情報の少なくとの１つを含むデータを作成すること、および−購買の完了を許可するために、供給者のサーバーに伝票を送ることからなる。

Description

【発明の詳細な説明】 コンピュータネットワーク上での 購買関連取引の電子的な支払い方法 本発明は、供給者によって提供される「商品」を、供給者のサーバーと顧客の 端末が接続されている公衆コンピュータテレコミュニケーションを介したオンラ インサービスによって購買する形態の取引を実行可能にする電子的な支払い方法 に関する。ここで、「公衆コンピュータテレコミュニケーション」とは、アドレ スさえ所有していれば、個人または会社が自由に接続可能な、「インターネット 」などのネットワークを指す。また、「商品」とは、取引が完了した後にネット ワーク外部で提供される製品またはサービス、さらに、コンピュータネットワー クを介して提供される、情報などの非物質的商品を指す。 種々の電子的な支払い方法が提案されており、中には既に使用されているもの もある。 幾つかの方法は、新しい形態の通貨に基づいている。これらは、純粋にソフト ウエアの形態をとったり、「スマートカード」等、一部物理的な形態をとること ができる、そしてときに「トークン」と呼ばれる、電子的な表現を伴う。これら の方法は、コンピュータネットワーク上における通貨の流通を必要とするため、 偽造通貨の作製に関する困難なセキュリティー問題が発生する。 他の公知の電子的な支払い方法は、銀行または銀行ネットワークとの直接的関 係を必要とする。これらの代表 格は、銀行カード回線（bank card circuit）にリンクされた店頭端末（point-o f-sale terminals）を用いる良く知られている方法や、購買者が許可のために電 子署名を用いる電子チェックを採用した方法等、クレジットカードネットワーク （credit card networks）で使用されている方法である。これは、購買者によっ て発行された誓約書の形態をしており、この誓約書は売り手に回収され、銀行に よって受領および認可される。 取引の途中で従来の銀行システムともたねばならない関係、および従来の銀行 システムにおいて取引を実行することを必要とする方法には或る種の不都合があ る。銀行システムの取引には物的なコスト（real cost）がかかるが、これは、 たとえば１つのデータベースでの調査（query）に基づく額など、購買総額が非 常に低いばあいには不当な額となる。そして、コンピュータネットワークは、取 引がネットワーク自身で実行されるため、低価格の商品、とくに情報を提供する 商品の販売に非常に適している。さらに、銀行ネットワーク（bank network）ま たは銀行カードネットワーク（bank card network）に対するアクセスは、非常 に高いレベルのセキュリティーを必要とするため、ここには、潜在的な購買者が 自分で接続できる「インターネット」など、公衆コンピュータネットワークから アクセスする可能性は実質的に排除されている。 本発明の目的は、従来の方法のもつ問題を回避できる方法、特に、電子通貨を 流通させるまでもなく、そして、従来の銀行システムからは許可（authorisatio n）を必要とする高価な商品から、安価な、さらに、非常に安価 な商品に到るまで、コンピュータネットワーク上での商品の購買に関する簡単で 信頼できる取引が実行可能な方法を提供することにある。 前記目的は、本明細書の冒頭で定義したタイプの方法によって達成された。す なわち、本発明によるその方法は、つぎの工程を有する。すなわち、 −ネットワークに接続された供給者のサーバーが、供給者と顧客とのあいだで認 識された購買に関して、供給者、顧客、購買対象物、および価格に関する情報を 備えた取引許可請求または「支払いチケット」を作成する工程、−顧客の局およ び供給者のサーバーとは別の支払いサーバー（payment server）に、コンピュー タネットワークを通じて、支払いチケットが送られる工程、 −支払いサーバーによって、代価の支払いを該当顧客が認めたかどうか、自動的 に照合がなされ、該照合は、支払われるべき額のレベルに応じて、支払いサーバ ーによって保持され、かつ、少額の支払いに意図された、顧客アカウント（acco unt）の問合わせ（interrogation）、または、高額の支払いのために、コンピュ ータネットワークとは独立した銀行ネットワークの問合わせによって実行される 工程、 −照合がポジティブ（positive）であるばあい、支払いサーバーが、取引の許可 、または支払いチケット情報の少なくとも一部を含む伝票を作成する工程、およ び −購買の完了を許可するために、伝票をコンピュータネットワークを通じて供給 者のサーバーに送る工程である。 すなわち、電子通貨の作成も不要で、コンピュータネ ットワーク上での電子通貨の流通も不要である点で、本発明による手順は有益で ある。 取引の管理は、銀行ネットワークまたは銀行カードネットワークに唯一アクセ ス可能な支払いサーバーによってなされ、少額の取引は、この支払いサーバーが 運営しているノンバンク顧客アカウントによって実行可能である。 また、前記支払いサーバーは少額取引に使用されるノンバンク供給者アカウン トをも運営している。このように、支払いサーバーによって保持されている顧客 アカウントの問合わせによる照合の後で伝票が送られると、購買総額は顧客アカ ウントから引き落とされ、支払いサーバーによって保持されている関連供給者の アカウントに振り込まれるので、その間、高い処理費用は発生しない。 各顧客がこの支払い方法を用いるためには、自分自身の身分証明（identity） が必要である。顧客にはまた、実際の銀行口座、好ましくは、従来の銀行カード によって運営することが可能なアカウントが必要である。支払いサーバーによる 照合には、支払いチケットの内容から顧客の身分証明を確認するための第１段階 が含まれる。身分証明の確認は、顧客アカウントへのアクセス（購買総額が低い ばあい）または銀行ネットワークへのアクセス（購買総額が高いばあい）に先行 して行われる。支払いサーバーは、コンピュータネットワーク上での取引に使用 された顧客の身分証明と、銀行ネットワーク上での取引に使用された銀行の身分 証明（銀行アカウントまたはクレジットカード番号）とのあいだの関係を記憶し て おく手段、たとえばデータベースを有することが望ましい。こうすれば、コンピ ュータネットワーク上に銀行での身分証明が流れるのを防止できる。 以下に、本発明の実行方法を、非限定的な例として、添付図面を参照しつつ記 載する。それらの図面とは、すなわち、 −図１は、本発明による電子的な支払いシステムの概念説明図であり、 −図２は、図１のシステムの支払いサーバーをブロックダイヤグラムで示した説 明図であり、 −図３は、図１のシステムを用いた購買に関する操作の進行を示す説明図であり 、 −図４Ａから４Ｃは、支払いサーバーによって実行される操作を概念的に示すフ ローチャートである。 図１は、供給者サーバー２０、顧客の端末３０、および少なくとも一つの支払 いサーバー４０が接続されたコンピュータテレコミュニケーションネットワーク １０を概念的に示している。 コンピュータネットワーク１０は、開放された、または公衆のネットワーク、 たとえば「インターネット」として知られているネットワークである。供給者サ ーバー２０は、インターネットに接続されたオンラインサービスに現在用いられ ているような装置、たとえば、ＵＮＩＸベースのマルチプロセッサー装置（UNIX -based multi-processor machines）を中心として組織された装置である。顧客 の端末３０は、基本的に、インターネットネットワーク１０に接続するための手 段、たとえば「Ｗｅｂ」インタフェースの形態を備えたマイクロコンピュー タである。供給者サーバー２０と顧客の端末３０では、たとえば、ＨＴＴＰプロ トコルを採用した「ワールドワイドウエブ」（「ＷＷＷ」）として良く知られた 公知のソフトウエアプロトコルが用いられうる。 図２に詳細に示した支払いサーバー４０は、いずれもインターネット１０に接 続された、フロントユニット（front unit）４１およびリアユニット（rear uni t）４２からなる。フロントユニット４１は、インターネットなどのネットワー クに接続された標準的なサーバーと同様のアーキテクチャーを備えている。リア ユニット４２は、１つまたはそれ以上のプロセッサーを含むプロセスユニット（ processing unit）４３と、この支払いシステムに申し込みをしている供給者お よび顧客に関する情報を含むデータベース４４と、取引レジスター４５と、銀行 ネットワークまたは銀行カードネットワーク５０と接続するためのインタフェー スユニット４６と、コミュニケーションバス（communication bus）４７または ユニットの別の構成部分との接続を可能にする他の類似リンクとを有する。セキ ュリティ接続（secure connection）４８は、フロントユニット４１とプロセス ユニット４３のあいだの二方向通信を可能にする。ネットワーク１０との通信は 、フロントユニツト４１によって管理され、データベース４４の管理と銀行ネッ トワークとの通信の管理はリアユニット４２によって確保される。 データベース４４は、この支払いシステムに申し込みをしている顧客および供 給者に関する情報を含む。個々の顧客毎にデータベース４４は、その顧客が最初 にシステムに申し込みを行ったときに割り当てられたシステム の身分証明（「ＣＩｄ」）、少額支払い用の顧客アカウントまたは電子財布（el ectronic wallet）（「ＰＭＥ」）、および現実のアカウントのアカウント番号 またはクレジットカード番号などの銀行の身分証明、さらに可能ならば顧客自身 のアクセス用パスワードまたは「キー」を含んでいる。個々の供給者ごとに、デ ータベース４４は、その供給者が最初にこのシステムに申し込みを行ったときに 割り当てられた、供給者／商人間のシステムの身分証明（「ＭＩｄ」）、少額の 受領のための供給者のアカウント、または、電子的なキャッシュレジスター（el ectronic cash register）（「ＴＣＥ」）、および、銀行口座番号などの銀行の 身分証明を含んでいる。 図３は、申し込んでいる顧客による、申し込んでいる供給者からの商品の購買 に関する取引の異なるステージを概略的に示している。これは、取引完了後に顧 客への引き渡しが行われる物質的商品のケースであっても良いし、電子的な支払 いが実行されると即時にコンピュータネットワークを通じて顧客に提供すること の可能な非物質的商品（情報など）のケースであっても良い。 （１）顧客による参照 インターネット１０に接続後、顧客は、供給者のサーバー２０にアクセスして 、供給者の売り物を顧客の端末３０のスクリーンで見ることによって、オンライ ン上のあらゆる供給者のカタログまたは「ウインドウ」を参照することができる 。顧客のシステムの身分証明の提示があれば、供給者のサーバー２０は、潜在的 な取引に適用可能と思われる特別な金融条件（たとえば割引き）を顧客に示すこ とができる。 （２）購買の要求 顧客が商品（対象物）Ｏを一旦選択したら、その選択は、商品の認識（identi ty）（Ｏｌｄ）と顧客の身分証明（ＣＩｄ）を含んだメッセージの形で供給者の サーバーに送られる。必要ならば、たとえば選択された商品の最終的な引き渡し に際して、供給者のサーバーは、住所や希望引き渡し時期など、補足的な情報を 要求することができる。これは顧客によって書き込まれるネットワーク上で送ら れる電子的なフォームによって実施するのが便利である。 直面する取引が高額のばあい、または、法的な条件を必要とするばあいには、 顧客の予備的なオーセンティケーション（authentication）が望まれるかも知れ ない。後述の詳細によって明らかになるように、顧客のオーセンティケーション は支払いサーバー４０によって実行される。また、供給者から寄せられたオーセ ンティケーション要求も、額面無しの支払いチケットという形態で有利に発行さ れ、顧客の端末を介したコンピュータネットワークから支払いサーバーに送られ 、良好というオーセンティケーションがえられたばあいには、支払いサーバーか ら供給者のサーバーへ、あくまで顧客の端末を通じて、伝票が戻される。支払い チケットの確立と、伝票の差し戻しの手順についてはつぎに詳細に記述する。 顧客から発せられた購買要求は単一の商品でも良く、グループ状の「バスケッ ト購入（basket purchase）」として提供される複数の商品でも良い。 （３）支払い要求の作成 購買要求に応じて、供給者のサーバーは、つぎの情報 を含んだ支払い要求を作成する。 −供給者の身分証明（「ＭＩｄ」）、 −オーダーされた商品、または、グループ化された購入のばあいには、バスケッ ト内の各商品の記載、 −取引のタイプ（単品またはバスケット）、 −顧客の身分証明（「ＣＩｄ」）、 −商品またはバスケット内の商品群の認識（「ＯＩｄ」）、 −商品の価格（「Ｏｉｄ）」）、 −付加価値税、ＶＡＴ、（適用されるならば）、 −支払いチケット発行の日時（供給者サーバーによる時刻と日付のスタンプ）、 −支払いチケットの有効期限、および −供給者のキャッシュレジスタ内のシリアルナンバー（とくに、取引が予備オー センティケーションの段階を含んでいるばあい）。 前記情報を組み合わせたものは、支払いチケットの隠しチャネル（hidden cha nnel）（またはオーダーされた商品のＵＲＬ、ここで、ＵＲＬはＨＴＴＰプロト コルを備えたＷＷＷソフトウエア中に用いられている「ユニフォーム リソース ロケーター（Uniform Resource Locator）の略号」に含まれた一連のバイトと して、つぎのように暗号化される。 ＵＲＬ http：＜ＳＰ＞＜オーダー内容の記載＞ ここで、ＳＰは支払いサーバーのインターネットアドレスである。支払いチケ ットは、顧客の端末宛に差し出される。これは、顧客がキャンセルまたは確認を 実行できる２個の論理「アンカー（anchors）」であり、完全 なものとされる。 （４）支払いオーダーの送付 顧客が支払いオーダーのＵＲＬを確認するだけで簡単に支払いオーダーは支払 いサーバーに送られる。既に理解されているように、支払いチケットは顧客の端 末を介した転送においてのみ通過可能である。 （５）伝票の発行 支払いオーダーを受けると、支払いサーバー４０は、伝票または支払い拒否を 返す前に、支払いオーダーを解読し、顧客オーセンティケーションを行い、支払 いが許可されるかどうかを確認する。顧客オーセンティケーションおよび支払い の許可については、図４を参照しつつさらに詳細に記載する。 照合過程にて支払いの許可がえられないばあいは、説明的な拒否の通知（たと えば、アカウントに入っている金額の不足、顧客に許可されている上限を超えて いるなどを示す）が支払いサーバーによって顧客に送られる。照合過程にて支払 いの許可がえられたばあいは、支払いチケット内に含まれる情報を、取引レジス ター４５内のシリアルナンバー、時刻スタンプ、有効期限（通常は数十秒）、お よび証明情報を構成する支払いサーバーのシール（seal）によって完成される。 前記情報の組み合わせは、支払いサーバーに属するパブリックキー（public key ）／プライベートキー（private key）暗号化システムのプライベートキー部分 を用いてデジタル方式で署名（これは支払いの許可の有効性と完全性とを保証す る）されたのち、伝票または引き渡しＵＲＬの隠しチャネルを構成する一連のバ イトの形に、つぎのように暗号化さ れる。 ＵＲＬ http：＜Ｍ＞＜伝票の記載＞ ここでＭは供給者のインターネットアドレス。 （６）引き渡しの依頼 前記伝票は顧客の端末を介して供給者のサーバーに送られる。これは、顧客の 端末にインストールされているソフトウエアにより、本発明の属する分野の当業 者に良く知られた、ＵＲＬの再発送能力を用いて自動的に実行される。供給者の サーバーは、商品の引き渡しを許可する前に、受け取った伝票を解読し照合する 。該照合には、支払いサーバーのプライベートキーの使用、有効期限が過ぎてい ないことの確認、および伝票の内容と要求された支払いの比較が含まれる。 （７）商品の引き渡し 伝票が供給者サーバーによって確認されると、購入された商品が情報であるば あいには、このサーバーは顧客の端末に直接引き渡しを実行することができ、ま た、商品の収集を可能にし、特に、引き渡しの場所および受取人の名前を特定す る資料を顧客の端末に発送することができる。 グループ化されたまたはバスケット購入のばあいには、供給者のサーバーは単 一の身分証明を割り当てられた対象、およびバスケットに含まれる各々の商品の ＵＲＬのリストを作成する。この対象がＵＲＬ商品オーダーに表示され、購入さ れた商品の詳細が支払いサーバーの取引レジスターへの記録を可能にする。 図４Ａから４Ｃは、支払いオーダーの受取りに応じて支払いサーバー４０が実 行する操作を示している。 フロントユニット４１（図４Ａ）では、支払いオーダーが解読され（ステージ ６１）、その有効性がとくに有効期限の見地から調査される（テスト６２）。調 査結果がネガティブ（negative）であれば拒否の通知が顧客の端末に送られる（ ステージ６３）。調査結果がポジティブであれば顧客のオーセンティケーション に移る（ステージ６４）。この操作の詳細は図４Ｃを参照しながら詳細に記載す る。オーセンティケーションがネガティブであれば（テスト６５）、拒否の通知 が顧客に送られる（ステージ６３）。オーセンティケーションによってポジティ ブな結果が出たら、支払いオーダー（顧客身分証明ＣＩｄと、供給者身分証明Ｍ Ｉｄと、価格とに限られたものであって良い）が通信ステージ６８を介して図２ に示された支払いサーバーのリアユニット４２に送られる（ステージ６６）。前 述の接続４８は、ネットワーク１０に接続している人がリアユニットに接続する ことを防止するセキュリティ接続である。 つぎにフロントユニット４１は、リアユニットが支払いを許可するかどうか決 定するのを待つ（ステージ６７）。支払いが認められなければ（テスト６８）、 拒否の通知が顧客の端末に送られる（ステージ６３）。支払いが許可されたら、 ステージ６２で記録された情報を用いて伝票が用意される（ステージ６９）。伝 票はフロントユニット４１のメモリーに格納され（ステージ７０）、顧客の端末 を介して供給者サーバーに送られる（ステージ７１）。 支払いサーバーのリアユニット４２（図４Ｂ）では、新たに受け取られ、オー センティケーションされた支払 いオーダーについて、このオーダーが顧客アカウントＰＭＥから許可されるべき か、それとも銀行ネットワークから許可されるべきか決定するための調査がなさ れる。ここでは、価格が最低しきい値と比較される（テスト７２）。前記しきい 値は、たとえば数十フランスフランである。 もし、しきい値を超過したら、支払い操作を実行する要求が、データベース４ ４の問合わせからえられた顧客の身分証明ＣＩｄに対応した銀行身分証明を用い て、銀行ネットワークに送られる（ステージ７３）。銀行ネットワークからポジ ティブまたはネガティブな回答が届くと（ステージ７４）、これは、フロントユ ニット４１に送られる（ステージ７５）。 しきい値を超過していなかったら、支払いはＰＭＥ顧客アカウントから行われ る。 このばあい、顧客アカウントが、充分な資金があるかどうかを判断するために 調査される（テスト７６）。充分な資金がなければ、支払い許可の拒否がリアユ ニットからフロントユニットヘ送られる（ステージ７５）。充分な資金があれば 、ＰＭＥ顧客アカウントから代金が引き落とされ、身分証明ＭＩｄに対応するＴ ＣＥ供給者アカウントに同額が振り込まれる（ステージ７７）、この取引が取引 レジスター４５に記入され（ステージ７８）、支払い許可、言い換えれば、ポジ ティブな回答が、取引レジスター内に記入されたシリアルナンバーの表示と共に フロントユニット４１に転送される（ステージ７５）。 図４Ａのステージ６４における、支払いサーバーでの 許可手順（図４Ｃ）は、アクセスキーまたはパスワードの、好ましくはセキュリ ティ（暗号化された）フォームでの、要求を顧客の端末へ送ること（ステージ６ ４１）を含む。アクセスキーをセキュリティフォームで受け取ると（ステージ６ ４）、データベース４４に含まれている情報との比較が行われる（テスト６４３ ）。比較の結果がネガティブであり、不合格の試みが最大回数に達していないば あいは（テスト６４４）、プロセスはステージ６４１に戻る。前記最大回数に達 したら、許可できないことが記されて、警告が発せられ（ステージ６４５）、ネ ガティブの回答が顧客の端末に送られる（ステージ６４６）。警告には、ＰＭＥ アカウントの抹消や、新たな使用の試みを検知するために行われるアカウントの 監視が含まれていても良い。段階６４３でのテストがポジティブであれば、許可 が記録され（ステージ６４７）、ポジティブな回答が提供される（ステージ６４ ８）。 コンピュータネットワーク内における数値情報の安全な転送を可能にする暗号 化技術には、とくにアクセスキーの要求と転送に関しては、良く知られたものが 幾つかある。 ここに開示されている許可手順では、顧客の予備許可を、必要に応じて、供給 者のサーバーによる支払い要求が確立する前に実行することが可能となる。前記 許可には、前述したように、額面ゼロの支払いチケットを作成すれば充分である 。 フロントユニット内で伝票を記録することによって、顧客と供給者には、管理 と、ばあいによってはこれらのコピーを入手することが可能になる。リアユニッ トに取 引を記録することによって、たとえば、顧客と供給者のあいだに生じる論争など 、次回の潜在的な使用のために取引記録を保存することが可能となる。 支払いサーバーによって管理される顧客アカウントＰＭＥにおける残高には限 度があり、本発明の好適な実施態様では、これらのアカウントは利子の支払いを 受けない（支払いシステムは銀行界とは分離されている）。顧客による自分自身 のＰＭＥアカウントへの補充は、銀行施設にオーダーすることによって、自分の 銀行アカウントから行うことができる。 支払いサーバーによって管理されている供給者アカウントＴＣＥは、たとえば 毎日でも空にできる供給者の現実の銀行口座と結びつけて考えられる。 ここでは、本発明による方法を、インターネット環境で、ＨＴＴＰプロトコル を用いたＷＷＷソフトウエアにて実行する例で記載したが、本方法をインターネ ット以外の、さらに、供給者サーバーと顧客を結ぶ、ＷＷＷのＨＴＴＰプロトコ ルを使用しないソフトウエアでも用いることができることは、当業者であれば容 易に理解できるであろう。さらに、アクセスキーの代わりに、スマートカード読 取り装置または声紋認識手段などの装置を用いた安全なオーセンティケーション 方法が予測可能である。当業者に着想されるこれらのまたは他の変形は、本発明 の範囲内である。

Claims (1)

1. 【特許請求の範囲】 １．供給者のサーバーと顧客の端末とが接続される公衆コンピュータネットワー クを介し供給者によって顧客に提供される商品の購買に関連する取引のための電 子的な支払いを達成する方法であって、 （ａ）ネットワークに接続された供給者のサーバーが、供給者と顧客とのあい だで認識された購買に関し、かつ、供給者、顧客、購買対象物および価格に関す る情報を備えた取引許可請求または支払いチケットを作成する工程、 （ｂ）顧客の端末および供給者のサーバーとは別の支払いサーバーに、コンピ ュータネットワークを介して支払いチケットを送る工程、 （ｃ）前記支払いサーバーによって、代価の支払いを顧客が認めたかどうかの 自動的照合を、支払いサーバーにより保持され、かつ、少額の支払いのために意 図された、顧客のカスタマーアカウントの問合わせ、または高額の支払いのため に、コンピュータネットワークとは独立した銀行ネットワークの問合わせのいず れかによって、支払われるべき額のレベルに応じて実行する工程、 （ｄ）前記照合がポジティブであるばあい、支払いサーバーが取引の許可、ま たは支払いチケット情報の少なくとも１つを含むデータを作成する工程、および （ｅ）購買の完了を許可するために、伝票をコンピュータネットワークを介し て供給者のサーバーに送る工程 からなることを特徴とする方法。 ２．前記支払いサーバーによって保持されている顧客アカウントの照合ののち伝 票が送られてくると、購買総額が顧客アカウントから引き落とされ、支払いサー バーによって保持されている関連供給者のアカウントに振り込まれることを特徴 とする請求の範囲第１項記載の方法。 ３．前記支払いサーバーによる照合が予備的な顧客オーセンティケーション段階 からなることを特徴とする請求の範囲第１項または第２項記載の方法。 ４．前記オーセンティケーションが、顧客の端末から支払いサーバーへコンピュ ータネットワークによって転送されるアクセスキーの承認により達成されること を特徴とする請求の範囲第３項記載の方法。 ５．前記支払いチケットに関する情報および証明情報の少なくとも１つからなる 伝票の、前記支払いサーバーによる作成を含むことを特徴とする請求の範囲第１ 項、第２項、第３項または第４項記載の方法。 ６．前記照合の内容の少なくとも一部を蓄えることによる、許可された取引の、 支払いサーバーによる記憶を含むことを特徴とする請求の範囲第１項、第２項、 第３項、第４項または第５項記載の方法。 ７．前記支払いチケットが支払いサーバーから供給者サーバーに顧客の端末の媒 介によって転送されることを特徴とする請求の範囲第１項、第２項、第３項、第 ４項、第５項または第６項記載の方法。 ８．前記照合が、支払いサーバーから供給者サーバーに顧客の端末の媒介によっ て転送されることを特徴とす る請求の範囲第１項、第２項、第３項、第４項、第５項、第６項または第７項記 載の方法。 ９．顧客の端末および供給者サーバーからなり、公衆コンピュータネットワーク を介して供給者によって顧客に提供される商品の購買に関連する取引のための電 子的な支払いシステムであって、 当該システムが、前記顧客の端末および供給者サーバーとは異なる少なくとも １つの支払いサーバーをさらに含み、 当該支払いサーバーが、 公衆ネットワークと接続する手段を有するフロントユニットと、 前記公衆ネットワークから独立した銀行ネットワークと接続する手段を有する リアユニットと、 フロントユニットおよびリアユニット間で情報を伝送する手段と、 顧客のアカウントおよび供給者のアカウントを記憶する手段と、 取引許可請求または支払いチケットの前記フロントユニットによる受取りに応 じて、供給者と顧客とのあいだで認識された購買に関して、顧客のアカウントま たは銀行ネットワークに問合わせすることにより顧客に代価の支払いが認められ たかどうか、または前記照合がポジティブであるかどうかの照合に関する処理を 行い、かつ、前記フロントユニットを介して公衆ネットワークに照合を伝えるた めに取引の許可または伝票を作成する手段 とからなることを特徴とする支払いシステム。 10．前記支払いサーバーが許可された取引を記憶する手段を含むことを特徴とす る請求の範囲第９項記載の支払いシステム。