JP2001504612A

JP2001504612A - 取引きシステム

Info

Publication number: JP2001504612A
Application number: JP52332298A
Authority: JP
Inventors: ヒル、ジェイク
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1996-11-20
Filing date: 1997-11-12
Publication date: 2001-04-03
Also published as: DE69721038T2; AU4957197A; GB9624127D0; WO1998022915A1; US6236981B1; EP0941524A1; DE69721038D1; EP0941524B1

Abstract

(57)【要約】ディジタル支払いシステムでは、乱数のシーケンスは支払いサーバ(600)に記憶される。記憶されたシーケンスから導き出したディジタルにコード化した乱数の組が、支払いの代わりにユーザへ送られる。トークンはカルネ(100)に記憶される。次にユーザはマーチャント(500)、例えばオンラインサービスのプロバイダへトークンを転送することによってトークンを費やすことができる。マーチャントは各トークンを支払いサーバで受取られるように戻す。支払いサーバはトークンを認証し、認証メッセージをマーチャントへ送る。マーチャント、支払いサーバ、およびユーザはインターネット接続で相互に接続することができる。

Description

【発明の詳細な説明】取引きシステム本発明は、ディジタルの支払い取引き（トランザクション）システムに関する。インターネットの成長および商業化に伴って、オンラインでの支払いを可能にする技術に対する必要性が増加している。比較的に高額の取引きの場合、このような要求は、例えば、銀行のような信頼のおけるものによって発行される電子小切手（electronic cheque）を使用するシステムによって適切に適えられる。このような電子小切手は一般的に、公開キー（public key）アルゴリズム、例えばＲＳＡを使用して暗号化されるサイン（シグネチャ）によって確認される。しかしながら、このようなアルゴリズムを使用することに関係した相当な計算上の経費(overhead)がかかる。したがって現実の生活において廉価なものを購入するとき、関係する取引きコストのために小切手が好ましくないように、電子小切手は小額の支払いには不適切である。小額の取引きによって必要とされるいわゆる“マイクロペイメント(micropaym ent)”に適した代わりの取引きシステムに対して多数の提案が行われた。しかしながら、適切なセキュリティレベルを維持しつつ、マイクロペイメント技術に要求される処理の経費を低くすることは技術的に困難であることが証明された。マイクロペイメントシステムにおける先行する提案の１例として、ＵＳの企業 Digitalによって開発された“Ｍｉｌｌｉｃｅｎｔ”として知られるものがある。このシステムは、提案者によって１セント未満の価格のものの購入を支援するのに適した軽量（lightweight、重い経費をもたらさない）のプロトコルとして記載されている。これは、売り主（ベンダ）のサーバにおける電子マネー(elect ronic cash)の分散式確認に基づいている。このシステムでディジタル支払いトークンは“スクリップ(scrip、仮証券)”と呼ばれている。このスクリップは、クレジットカードのような通常の支払い方法に代って中央支払いサービスによって発行される。こうしてベンダは商品またはより一般的にはサービスに対する支払いの際にユーザからスクリップを受取ることができる。ベンダは新しいスクリップを生成し、取引き用の小銭としてそれをユーザに戻す。スクリップは認証されていて、新しいスクリップはハッシュ関数(hash function、テキストまたは数字入力から数値（ハッシュ値）を生成するが、他のテキストは同じハッシュ値を作ることがほとんどないようにする関数）を使用してベンダによって生成される。これは潜在的なセキュリティの弱さ、すなわちハッシュ関数が損なわれたとき、スクリップが偽造および複製に対して無防備であることを表している。さらに、ベンダがハッシュ関数を使用することに関係する処理上の経費がある。これは例えばＰＧＰ暗号化サインの使用に関係する経費よりも少ないが、それにもかかわらず重大な制限がある。Ｍｉｌｌｉｃｅｎｔシステムの提案者によって認められていることは、この制限された効率の結果として、それが処理できる取引き値よりも実際には低い方の境界があることである。低い方の境界は約１／１０セントであると推定される。したがってＭｉｌｌｉｃｅｎｔは使用の際、例えばインターネットで使用する課金機構に適していない。インターネット上のパケット伝送コストは、約１／６００セントと推定される。欧州特許出願ＥＰ-A-0507669号では、スマートカード技術に基づく別のタイプの支払いシステムの例が開示されている。ここでは、セキュリティは、依存している暗号のセキュリティではなく、カードの物理的な完全性に基づいている。多数のトークン値からランダムに選んだサブセットが保留されるので、後の取引きにおいて保留されたトークン値の１つが存在することは不正が試みられたことを示すものとして役立つことができる。特定のカードに対して発行されたトークンの組は統計的にランダムではないが、全てが制限された範囲の数値に含まれ、この数値によって決定されるシーケンスにおいて命令することができる。本発明の第１の態様にしたがって、ディジタル支払い取引きシステムを動作する方法であり：ａ）支払いサーバに乱数のシーケンスを記憶することと；ｂ）前記記憶した乱数のシーケンスから導き出したディジタルにコード化した乱数シーケンスを含む１組のディジタルの支払いトークンをユーザに送ることと；ｃ）ユーザからマーチャントプラットフォームへ支払いトークンを転送することと；ｄ）段階（ｃ）でユーザから受取った支払いトークンをマーチャントプラットフォームから支払いサーバへ転送することと；ｅ）支払いサーバにおいて、マーチャントプラットフォームからの乱数のトークン値と記憶した乱数のシーケンス内の対応する位置から導き出した値とを比較することによってトークンを認証することと；ｆ）後に、支払いサーバからマーチャントプラットフォームへ認証メッセージを通信することとを含む方法を提供する。本発明は、向上した効率およびセキュリティを提供し、非常に小額の支払いを含むマイクロペイメントを行なうのに適したディジタル支払いシステムを提供する。これは、所定のシーケンス内の１組の乱数を含む“カルネ（carnet、回数券の類)”またはディジタル支払いトークンの組をユーザに送ることによって達成される。シーケンス内の数字は互いにまったく関係しておらず、トークンの数値とシーケンス内での位置とは相関関係がない。これは、暗号変換によってトークンを互いに関係付ける従来技術の提案とは対称的である。トークンを支払いサーバへ送ることによってトークンは確認され、そこ（サーバ）では、サーバに記憶した乱数のシーケンス内で対応している数字とトークンを比較する。このやり方でこのシステムは、高レベルの暗号セキュリティを与え、一方でベンダから処理の経費を完全に取り除く。明細書および特許請求の範囲では、“ランダム(random)”という用語を使用するが、真の乱数と、要求される精度レベル内で真の乱数のシーケンスの統計的性質に適合している擬似乱数との両方を含むこととする。好ましくは支払いサーバはマーチャント（商人の）プラットフォームから隔っており、マーチャントプラットフォームは通信ネットワークで支払いサーバと通信する。一般に、必ずというわけではないがユーザと、マーチャントと支払いサーバとの三者をインターネット接続によってリンクすることになる。好ましくは、ディジタル支払いトークンの組は前記シーケンスの部分を選択し、ユーザに特定のキーでシーケンスの前記部分をコード化することによって、支払いサーバに記憶した乱数のシーケンスから導き出される。ユーザに特定のキーを使用して乱数シーケンスの部分を暗号化することによってカルネを生成することは、乱数シーケンスの必要な長さ、および支払いサーバに必要とされる関係するメモリが、ユーザ数が増加するのにしたがって容認可能なようにスケール合わせができることを保証する。同時に、（当事者が関連のユーザキーをもつ場合に限ってトークンが有効に使用されるので）ユーザキーでの暗号化はこの方法のセキュリティを一層高める。好ましくは前記シーケンスの一部は対称的なブロックの暗号によってコード化される。これは、最高レベルのセキュリティを与えるものとして好ましい。その代りに、使用領域においてカルネを生成するときに含まれる計算上の経費を低減することがより重要であるとき、キーされたハッシュ関数を使用できる。上記の Millicent提案とは対称的に、ハッシング（ハッシュすること）は、記憶した乱数のシーケンスからトークン値を生成するために支払いサーバ内でのみ使用し、カルネ内の異なる数字の間の関係を判断しない。したがってシステムのセキュリティは、ハッシュ関数の完全性のみに依存しない。好ましくは方法の段階（ｄ）において、マーチャント（商人）は各支払いトークンと一緒に、支払いサーバによって発せられた認証トークンのシーケンスからの認証トークンと連絡をとる。一般にベンダと支払いサーバとの間にはより大きな信頼があるが、依然としてこれらの二者間の取引きに対してセキュリティを与える必要がある。本発明の好ましい構成で特別の効果的な方法は、支払いトークンそのものを生成するのに使用するのと同じ機構を使用することである。そこで支払いサーバはそのマーチャントにもたせる一連の認証トークンを発行する。これらの認証トークンは、支払いトークンと同じやり方で乱数のシーケンスから導き出すことができる。次にマーチャントは支払いトークンと認証トークンの対を戻すことができる。次に支払いサーバは、確認された支払いトークンとマーチャントプラットフォームから受取った認証トークンとを認証した後で、マーチャント口座記録を自動的に更新することができる。好ましくはディジタル支払いトークンを認証する段階であり：ｉ）支払いサーバに記憶した乱数のシーケンス内の位置の値に対してディジタル支払いトークンの認証を試みることと； ii）トークンが段階ｉ）で認証されないとき、前記位置から所定の最大距離以内に含まれる記憶したシーケンスの１または複数の他の値に対してディジタル支払いトークンの認証を試みることとを含み；段階（ｆ）において、認証メッセージはトークンが段階（ｉ）および段階（ ii）で首尾よく認証するときに認証が成功であることを示す。基本的な支払い機構は、ユーザおよび支払いサーバが記憶した乱数のシーケンスを段階を踏んで進めていくと仮定している。しかしながらトークンはときどき、例えば１人のマーチャントが他のマーチャントよりも清算のためにトークンを提出するのが遅いために、シーケンス通りではない順序で支払いサーバに到達することがある。本発明のこの特徴により、システムはこれらの環境でも健全に機能することができる。支払いサーバに記憶した乱数のシーケンスにおける次の乱数のみを検査する代わりに、移動するウインドウ(sliding window)を使用して（シーケンスの位置に関する）一定の範囲の記憶した乱数を選択する。提出されたトークンは、（記憶した値が先に使用されていないことを条件として）ウインドウ内に含まれる記憶した値を首尾よく確認できる。好ましくはさらに：ｆ）支払いサーバにおいてディジタル支払いトークンの組の現在の状態の記録を維持することと；ｇ）ユーザに対して送られたディジタル支払いトークンが失われるかまたは損われているとき、支払いサーバからユーザへデータを通信し、それによってディジタル支払いトークンの組を支払いサーバに記録した状態に対応する状態に更新することとを含む。本発明の好ましい構成によって提供される別の重要な長所は、カルネが破壊されるかまたは盗難にあったとき、支払いサーバによって再生できることである。好ましくはこの方法はさらに：ユーザに識別番号(PIN)を送ること；識別番号を使用して、乱数の前記記憶したシーケンスから導き出した数字を変更することと；識別番号を使用して、段階（ｃ）でマーチャントに転送されたディジタル支払いトークンをさらに変更することとを含む。この好ましい特徴は、マーチャントプラットフォームにおいて処理の経費に著しく付加することなく、システムのセキュリティを向上する。好ましくはディジタル支払いトークンを変更する段階において、支払いサーバによって送られたディジタルにコード化した値は、ブール論理演算を使用して識別番号と結合され、前記演算の結果は変更されたディジタル支払いトークンとして出力される。好ましくは、前記二値論理演算はＸＯＲである。本発明の第２の態様にしたがって、ディジタル支払い取引きシステムを動作する方法であり：ａ）ディジタルにコード化した乱数のシーケンスを含む１組のディジタル支払いトークンをユーザに送ることと：ｂ）ディジタルにコード化した乱数のシーケンスを含む１組の認証トークンをマーチャントに送ることと：ｃ）ディジタル支払いトークンをユーザからマーチャントへ転送することと；ｄ）前記ディジタル支払いトークンを転送し、ディジタル支払いトークンと共に認証トークンをマーチャントから支払いサーバへ転送することと；ｅ）ディジタル支払いトークンおよび認証トークンを支払サーバに記憶した記録に対して認証することと；ｆ）認証メッセージをマーチャントへ戻すこととを含む方法を提供する。本発明は、本発明の第１および第２の態様の方法で使用するマーチャントプラットフォーム、クライアントプラットフォーム、支払いサーバ、並びにこのようなデバイスを含むネットワークを含む。次に記載した例では、クライアントプラットフォームはウエッブブラウザを走行しているパーソナルコンピュータである。クライアントプラットフォームの他の例は、スマートカードおよびパーソナルディジタルアシスタンス(PDA)を含む。ここで本発明を実現するシステムを、添付の図面を参照して例示的に記載することにする：図１は、支払いシステムの主要な素子を示す模式図である；図２は、支払いサービス清算者モジュールの主要な実行ループを示すフローチャートである；図３は、マーチャントモジュールの主要な実行ループを示すフローチャートである；図４は、支払サービスで受取ったトークンを確認するためのプロセスを示すフローチャートである；図５は、クライアントまたはマーチャントトークンデータベースを復元するのに使用する更新用モジュールを示すフローチャートである；図６は、マーチャントコレクタモジュールを示すフローチャートである；図７は、カルネにおけるペイヤモジュールを示すフローチャートである；図８は、本発明を実現するネットワークの模式図である；図９は、別の実施形態の模式図である；図10は、移動するウインドウを使用する支払いサービスの動作を示す。図８に示したように、クライアント端末１は、この例ではパーソナルコンピュータであり、モデム２およびＰＳＴＮ（公衆交換電話網）３を介してインターネットサービスプロバイダ（ＩＳＰ）４へ接続されている。クライアント端末はインターネットを介して異なる時に、支払いサーバ６（本明細書では“支払いサービス”とも記載されている）およびオンラインのマーチャント５に接続を形成する。マーチャントは支払いに応じてサービスを提供する。例えばマーチャントは、個人仕様のニュース項目のＨＴＴＰ（ハイパーテキスト伝送プロトコル）ページを、ページごとに廉価な固定課金で供給する。その代りに、マーチャントは例えば，高速のインターネット接続へのアクセスを行なうノード５ａを制御することができる。ユーザは、例えばユーザが接続した時間長に基づいて計算できる課金で、ノードへアクセスできる。支払いトークンは、ユーザから規則正しい時間間隔で要求できるか、またはノードを通って送られる各パケットからコレクタすることができる。本発明を実現する支払いシステムは、発明者によって“ＱｕｉｃｋＰａｙ(迅速な支払いの意)”と呼ばれる。使用の際に、“カルネ”モジュールと呼ばれるモジュールがクライアント端末にインストールされる。このモジュールは、以下でさらに詳しく記載するように、マーチャントおよび支払いサービスとのインタラクション（対話）を支援するプログラムを含む。さらに、端末は、ユーザによって現在保持されている支払いトークンに関係するデータを記憶する。最初に、ユーザは支払いサービスとインターネット接続を確立し、一定の価格までトークンを購入する。この取引きは、例えばクライアントから支払いサービスへ一定の価格、例えば１０ポンドまでのトークンの要求をクレジットカード番号と共に、送ることによって実行することができる。クレジットカード番号は、多数の公開キー暗号化ツール、例えばＰＧＰの１つを使用して暗号化することができる。支払いサービスは、クレジットカードの口座から関連する合計を控除し、多数の支払いトークン、例えば価格１ｐのトークンを１０００個生成する。支払いトークンは公開キーアルゴリズムを使用して暗号化され、インターネット接続を介してユーザに独特のキーと共にユーザへ戻される。各トークンは、この例では、支払いサービスにおいてｎの乱数の大きいリストＲ＝（r０，ｒ１，ｒ２，・・・・，ｒｎ−２，ｒｎ−１）から取出した６４ビットの１６進数の乱数を含む。各ユーザに対して、支払いサービスは２つの秘密情報ｋおよびｓを保持している。ｋは対称的なブロック暗号で使用するランダムなキーである。ｓはランダムなセムに取る。さらに整数インデックス変数(integer index variable)iもある。そのセキュリティは絶対的ではないが、その完全性は重要である。クライアント端末に記憶されているカルネはｍの乱数のリストＴ＝（ｔ１，ｔ２，ｔ３・・・・，ｔｍ−１，ｔｍ)、（ｍ＜＜ｎ）を保持している。下記の表１は、カルネ内に保持されている乱数のリストの一部を示している。支払いサービスは、ユーザが登録すると、ＲからＴを導き出す。ＴはＲの暗号化されたサブセットであり；ｔ_x＝Ｅ（ｋ，ｒ_(s+Xmodn)）なお、Ｅ（ａ，ｂ）はキーａを使用してｂの暗号を示している。変数ｉはこの点で０に初期設定される。カルネはさらにこの変数のコピーを含む。マイクロペイメントを１回行なうのに、ユーザはｔｉ（ｉ番目の支払いトークン）を支払いサービスへ送る。支払いサービスは、Ｄ（ｋ，ｔ_i）＝ｒ_s-imodn であり支払いが成功したことを保証するために検査する。カルネおよび支払いサービスの両方はｉのコピーをインクリメントする。次に、ユーザはマーチャントとのインターネット接続を確立する。これは、従来はユーザが予め特定したサーチエンジンおよびサーチ基準を使用してマーチャントによって検索されたニュース項目のＨＴＭＬページを検索するためのものあってもよい。ＨＴＭＬページをダウンロードする要求に応答して、マーチャントは、例えば１０ｐの支払いを要求する。一般に、支払いに対する要求を戻すことは、マーチャントのＨＴＭＬサーバで走行しているＣＧＩスクリプトを使用して自動的に戻されることになる。マーチャントからの要求に応答して、ユーザはカルネから１０個目のトークンを送る。トークンは所定のシーケンスに含まれているので、支払いを合計するのに１０個全てのトークンを要求する代わりに、１０番目のトークンのみを転送ずれだけで十分である。トークンの発行を認証するためにユーザが端末に入力する用に要求されるＰＩＮを使用してＸＯＲオペレーションによって、このトークンはカルネモジュールによって変更される。次に変更されたトークンはインターネット接続上をマーチャントへ送られる。マーチャントは支払いサービスにオープンなインターネット接続をもつ。ユーザからトークンが受取られると、マーチャントは、支払いサービスに向けて認証トークンの対応する組(set)と一緒に、支払いトークンを含むタップル(tuple、要素集合)を送る。このマーチャントは、本明細書では“サードパーティサービスプロバイダ”（ＴＰＳＰ、第三者サービスプロバイダ）とも記載されており、１組の認証トークンを送られる。この認証トークンは、ユーザへ送られた支払いトークンと本質的に同じであり、１度限りのパスワードのように機能する。認証トークンＡの組はＲの暗号化されたサブセットであり、次のように表される。ａ_x＝Ｅ（ｋ，ｒ_s+xmodn）なお、ｋは秘密の暗号キーであり、ｓはランダムセキュリティパラメータであり、ｎはランダムデータベースＲの大きさである。ＴＰＳＰは、既に記載したようにユーザから支払いトークンｔｉを集める。各トークンを確認するために、マーチャントはトークンをａｊ（次の認証トークン）と一緒に支払いサービスへ前方送りする。支払いサービスはコンファーメーション（確認）を戻す前に、ｔｉとａｊの両方が期待値であることを確認する。マーチャントが首尾よく提出した（ｔｉ，ａｊ）の対を計数することによって、支払いシステムは、マーチャントが所有している量の記録をもつ。支払いサービスは、認証メッセージ内の認証トークンを戻す。支払いトークンが認証トークンａｊでマーチャントによって提出されたとき、支払いサーバはａ (ｊ＋１)、すなわちマーチャントによって保持されているシーケンス内の次の認証トークンを戻して、認証が成功したことを示す。支払いサーバはａ（ｊ＋１）の補数を送って、認証が失敗したことを示す。ユーザ、マーチャント、および支払いサーバによって交換されたメッセージは全て不足しており、例えばＨＴＴＰ（ハイパーテキスト伝送プロトコル）またはＭＩＭＥ（多目的インターネットメール拡張）ヘッダ内に含めるのに適している。既に記載したように支払いシステムは、いくつかのタイプの故障に対して潜在的にオープン（開かれた状態）である。これらを処理する機構は、この構成内に含まれている。回復可能な２つの主要なクラスにがある：１）カルネおよびマーチャントモジュールのインデックス変数は、支払いサービスのインデックス変数で段階から逃れることができる。これらのエラーは再同期化方法によって処理される。受取ったトークンが期待値に一致整合しないとき、支払いサービスは乱数のシーケンスの先を読み、整合する値を探す。読み進む制限範囲はシステムパラメータとして設定される。整合するトークンが範囲の組の中で見付かったとき、支払いシステムはトークンを受理する。支払いシステムは各カルネごとにスキップしたトークン数を記録する。（例えば、残っているトークン数が少なくなったときに）カルネはリフレッシュを行なうことによって、後でトークンを回復することができる。オプションとして、この方法は移動するウインドウを使用してトークンを精巧に作り上げてよい値の範囲を定めることによって、精巧なものとすることができる。２）トークンのリストまたはカルネ内のインデックス変数は損失または損われる可能性がある。カルネはリフレッシュして、その情報を支払いサービス内に保持されている情報と一致させることができる。カルネを再び初期設定するとき、支払いトークンの新しい組をユーザ用に構成する。トークン数は、先のカルネ内の未使用のトークン数と同期誤差によって損なわれたトークン数との和に等しくなる。潜在的に、回復不可能な第３のタイプの故障がある。支払いサービス情報の損失は致命的であり、防止しなければならない。これは、支払いサービスに冗長度をもたせ、異なるサイトの別のサーバ内における１つの支払いサーバからデータをモニタし、ＲＡＩＤのような丈夫な記憶技術を使用することによって達成される。この構成の別の特徴は、ユーザに送られた各カルネがディジタルシグネチャを準備していることである。サインは通常のやり方で公開キー暗号アルゴリズムを使用して形成される。この目的のためにＤＳＡまたは別のEl Gammal変数を使用することがとくに好ましい。したがってディジタルサインを問題の解決に使用することができる。例えば、ユーザがトークンを購入し、そのトークンがシステムが故障したために使用できないとき、ユーザは、カルネを発行した者から返金を請求することができる。このカルネの発行者は、カルネが送られたときにディジタルシグネチャが生成されることを検査することによってカルネが本物であることを保証することができる。ＱｕｉｃｋＰａｙ（ＱＰ）方法に関する上述の応用は例示的に記載したものであり、本発明は幅広い範囲の異なるコンテクストにおいて、安全で効率的な支払いサービスが必要なときはいつでも使用できる。本発明は、メッセージ送信コストが低いという理由でインターネットサービスのコンテクストでとくに有効であるが、他の領域においても使用することができる。例えば、カルネおよびそれと関係するクライアントのアプリケーションは、マイクロプロセッサおよび不揮発性メモリを含むスマートカードに記憶することができる。この場合マーチャントのプラットフォームは、ＥＰＯＳ（電子的ポイントオブセール）端末を介してアクセスすることができる。図９はこのようなシステムを示しており、スマートカード901上のカルネはカード読取り装置902内にあり、カード読取り装置902はマーチャントプラットフォーム903に接続されている。マーチャントプラットフォームはＰＳＴＮを介して支払いサーバ904に接続されている。カードを使用して、さらに例えば公衆電話に取付けられたカード読取り装置を介して電話サービスを購入することができる。この場合、既存の電話網のシグナリングチャンネル、例えばＮＵＰ（国内ユーザパート）およびＵＫＰＳＴＮにおけるＩＳＵＰ（ＩＳＤＮユーザパート）を、上述の第１の例におけるＴＣＰ／ＩＰシグナリングの代わりに、異なるプラットフォーム間の接続に使用することができる。別の例では、ＢＴのＮｅｔＳｕｍｍサービスの使用に対する支払いにＱｕｉｃｋＰａｙを使用する。ＮｅｔＳｕｍｍ（ＴＭ）はネットワーク形式のテキスト要約ツールである。インターネットのユーザは、ＮｅｔＳｕｍｍを使って、英語のワールドワイドウエッブ（ＷＷＷ）ドキュメントの要約を生成することができる。サービスはウエッブブラウザを介してアクセスされる。ユーザは先ずＱｕｉｃｋＰａｙウエッブサイトを訪ねる。ユーザは最初に、ユーザ名およびパスワードを与えるフォームを完了することによって、口座を設立する。ユーザ名は有効なｅ−メールアドレスでなければならず、パスワードは64 バイト長までのどんな文字列であってもよい。次にユーザは、ＱｕｉｃｋＰａｙカルネを購入できるページをみて、使用するプラットフォームのタイプ、および要求するカルネの大きさ（サイズ）を特定する別のフォームを完成する。ユーザが“購入(Ｂｕｙ)”ボタンをクリックすると、支払いサービスは新しいＱｕｉｃｋＰａｙカルネを生成して、それをクライアントへ向けてダウンロードする。次にユーザは、新しいカルネをインストールする。ユーザはＱｕｉｃｋＰａｙのクライアントがインストールされる場所を特定することができ、ＰＩＮを与えて支払いトークンを保護しなければならない。ユーザはＮｅｔＳｕｍｍホームページから、要約されるＷＷＷドキュメントのＵＲＬ（ユニフォームリソースロケータ、すなわちアドレス）を特定する。ＮｅｔＳｕｍｍはドキュメントのダイジェスト版を戻す。ドキュメント内の全てのハイパーリンクを変更して、それらをクリックすることによって、目標のドキュメントの要約を戻す。ＮｅｔＳｕｍｍはユーザへ付加的な制御も与えて、ユーザに要約規則を変更することができるようにする。ＮｅｔＳｕｍｍを使用するとき、各要約ごとに０．００２ポンド（０．２ペンス）で課金される。ページが提出されるたびに、ＮｅｔＳｕｍｍは結果を戻す前にユーザに２つのＱｕｉｃｋＰａｙトークンを課金する(この例ではトークンの価格は０．１ｐである)。ＱｕｉｃｋＰａｙマーチャントモジュールを１回呼ぶと、ＮｅｔＳｕｍｍアプリケーションはこれらのトークンを要求し、支払いが成功したか否かを示す結果を得ることができる。ＮｅｔＳｕｍｍを使用する前に、ユーザはＱｕｉｃｋＰａｙクライアントを走行しなければならない。これは、ユーザのウエッブブラウザから切り離されたアプリケーションである。このアプリケーションは単一の小さいウインドウをもち、残っているトークン数を視覚的に表示する。ウインドウはいくつかの制御を含み、それによりユーザはアプリケーションの停止、ＰＩＮの変更、カルネの更新、などを行なうことができる。ユーザはＮｅｔＳｕｍｍを使用する前にクライアントを始動できないとき、テキストの要約を試行するときにサービスからエラーページを受取ることになる。最初にＮｅｔＳｕｍｍサービスはＱｕｉｃｋＰａｙのクライアントからトークンを集めることを試行すると、ユーザはダイヤログ（対話）ボックスが与えられ、それがユーザに支払いを確認するように求める。ユーザはＰＩＮを入力して、支払いトークンをアンロックしなければならず、このマーチャントからの次の支払い要求の処理方法を選択することができる。ユーザが次の支払いの許可を選択するとき、ＮｅｔＳｕｍｍはユーザの介入なしに付加的なトークンをコレクタできるようになる。その代りに、ユーザは各要求を個々に受理するかまたは拒絶するかを選択できる。これらの規則は、ユーザがＱｕｉｃｋＰａｙクライアントアプリケーションを閉じるまで存続する。ユーザが支払いトークンの供給を使い尽くしたとき、ＱｕｉｃｋＰａｙのウエッブサイトを訪ねて、そこで“再充填カルネ”リンクにしたがうことによってさらに支払いトークンを得ることができる。先行するカルネから未使用のトークンがユーザの新しいカルネに付加されることを除いて、カルネを再充填することは、最初のカルネを購入することに非常に似ている。ユーザは認証の詳細（ユーザ名およびパスワード）を入力して、付加的なトークンを購入しなければならない。ユーザはさらに支払いの詳細（すなわち、クレジットカード番号）を提供して、所望のカルネのタイプおよび大きさを選択しなければならない。それが伝えられる前に、先のカルネから未使用のトークンが新しいカルネに付加され、ユーザの古いカルネは無効になる。ここで本発明の構成をさらに詳細に記載する。図１は、このＱｕｉｃｋｐａｙ構成における主要なソフトウェア素子を示す。支払いサービスおよびマーチャントモジュールは、バックエンドアプリケーションであり、ユーザとの対話がほとんどあるいは全くない。これらの素子は、この例ではＵＮＩＸクライアントおよびサーバのアプリケーションとして構成されており、大抵のＵＮＩＸプラットフォームにおいて走行しなければならない。カルネはそのユーザと対話し、種々のタイプのコンピュータにおいて種々の形式で構成することができる。ここでは、一般的なＵＮＩＸクライアントを記載するとし、一般的なＵＮＩＸのクライアントはＵＮＩＸワークステーション上で走行できるか、または他のプラットフォームへ転送されるスタンドアローンのクライアントを基礎として使用できる。さらにその代りとして、ＱｕｉｃｋＰａｙクライアントを他のアプリケーション、たとえばＷＷＷおよびｅメールクライアントと統合してもよい。支払いサービス支払いサービスは、クリアラ(清算手段)、クリエータ(生成手段)、アップデータ(更新手段)、および４つのデータベースを含む。データベース全ての４つのデータベースは記録の簡単な収集体である。ＵＲＤ（ユーザ登録データベース）において、エントリはアルファ数字の列（ユーザ名）によってインデックス（索引）を付けられている。全ての他のデータベースでは、エントリは数字によってシーケンスで索引を付けられている。索引の割当てが連続している必要はない。例えば、カルネのＩＤは範囲［０.．２６４−１］の中からランダムに割当てられ、１回にその一部のみが割当てられる可能性が高い。ユーザ登録データベースＵＲＤはＱｕｉｃｋＰａｙユーザに関する情報を保持する。ＵＲＤは主として管理機能を実行しているユーザの認証に使用する。ＵＲＤ内のエントリはパスワードおよびカルネＩＤを含む。カルネ情報データベースＣＩＤ（カルネ情報データベース）は、ユーザカルネおよびマーチャントモジュールの状態情報を保持する。このデータベースはクリアラによって使用されて、次に期待される支払いまたは認証トークンを識別する。このデータベースはさらに、更新手段がＲＮＤから支払いまたは認証トークンの組を再構成することを可能にする。キーは、キーされたハッシュで使用されてトークンを構成する値である。データベースID、開始オフセット、および大きさフィールドは、ＲＮＤ内のランダムデータのソースを識別する。トークンの索引は、次の期待されるトークンの索引であり、範囲［０・・大きさ］内にある。再同期化(resynchronisation)カウンタは、受取ったトークンをクリアするためにスキップしたトークン数の記録である。マーチャント情報データベースＭＩＤ（マーチャント情報データベース）は、各マーチャントに対してクリアした取り引きの記録を保持している。ＣＩＤ内のカルネに対するエントリはマーチャントへ向かうＭＩＤ内に対応するエントリがある。乱数データベース乱数のデータのプールを保持し、これを使用してＲＮＤ（乱数データベース）は支払いおよび認証トークンの組を構成する。データベース内の各エントリは６４ビット値のランダムシーケンスを含む。大きさ（サイズ）のフィールドは、このシーケンスがどのくらい大きいかを示す。ＲＮＤはハードウエアの乱数生成装置から次のようにデータで場所を埋める：プログラムRandom Comm Serverは３つの部分に分割することができる。乱数生成装置はヘッダファイルRandom Generat or.hをもつ、ソースファイル名Random Generator．cppのもとにくる。ランダムテスタはソースファイルMain Tester.cpp、tester.cpp、およびRandom IO.cppを使用し、ヘッダファイルMain Tester.h tester.h、stats.h、およびRandom IO.h .を使用する。残りの部分は、ウインドウズインターフェイスおよびサーバとして機能する。主要なソースファイルはRCServerDoc.cpp、ServerSocket.cpp、および“CommSocket.cpp”である。１．データ生成乱数は、２５６Ｋ(＝２，０９７，１５２ビット)のブロックで、ＢＴによって製造されたＬｅｃｔｏｒ３９００として知られているハードウェアの乱数生成装置を使用して生成される。乱数生成装置はカードであり、このカードはパーソナルコンピュータにはめ込まれ、ダイオードおよび増幅器を含み、増幅器はダイオード上のショットノイズを増幅し、二進数の値のランダムな流れを生成する。生成装置はわずかにバイアスをもつので、これを補正し、データは２ビットのデータを１ビットまたは０ビットに変更することによって圧縮される。００および１１は捨てられ、０１は０と１０は１とになる。これは、データの４分の３が失われ、且つバイアスが除かれることを意味する。次にこのデータは、“raw．dat”の名前でディスクに保存される。２．データのテスト２５６Ｋのブロックにおいて次のテストを使用する。（ｉ）ビットテスト：１の数に対して０の数をテストする。（ｉｉ）連続テスト：００，０１，１０，および１１の頻度をテストする。（ｉｉｉ）走行テスト：０.．０または１.．１の長いシーケンスの発生をテストする。（ｉｖ）大きさ２乃至８のポーカテスト：２-乃至８-ビット組合わせの発生をテストする。（ｖ）１乃至１０００の期間における自己相関テスト：データの周期性をテストする。（ｖｉ）Maurer汎用統計テスト（Maurer Universal Statistical Test）：データ圧縮の可能性を調べる。さらに、ビットテストは生成したデータ全てに対して累積的に計算される。これは全部のバイアスについて検査し、１２８Ｋのみのデータのテストでははっきりできない。３．データの受理／拒絶データは１％および５％の有意度レベルでテストされる。５％のレベルで失敗したテスト数は２０回に１回であり、１％の有意度レベルでは１００回に１回であることを意味する。データがこれらの１０１１テストでもっと多く失われる（５％レベルで８０＋、１％で１５＋、または１“測定不能（off-the-scale、スケール外エラー）ときには、データは拒絶されることになる。さらに特定のテストにおける失敗の得点は保持されることになる。１つのテストが続けて失敗するときは、このテストはフラグを立てられることになる。４．データの保存およびサーバとしての使用データが完全にランダムであるとして受理されるとき、２５６Ｋのファイルは８つの３２Ｋのファイルに分割され、ファイル名“use＿n.dat”（ｎは３ディジットの数字である）で保存される。これはサーバに接続されたクライアント機で使用できる。サーバは最初に最も古いファイルを使用してファイルを送り出す。ファイルがクライアントに送られてしまうと、メモリから削除される。１回で、クライアントは３２Ｋのファイルを１０００まで得ることができる。ランダムデータが送られている間にそれにアクセスできることが懸念されるとき、クライアントは受取ったランダムデータを暗号化することを進められる。生成手段(Creator) 生成手段は呼出されて、ユーザに対して新しいカルネを生成する。図２は、このプロセスに対するフローチャートである。これがユーザの第１のカルネであるとき、口座は既にＵＲＤ内に生成されていると仮定する。生成手段は、新しいカルネID、キー、データベースＩＤ、および開始オフセットをランダムに拾って、これらの詳細をＣＩＤへ付加する。次に生成手段はＲＮＤからトークンを読取り、キーを使用してそれらを暗号化し、それらを（クライアントのソフトウェアと一緒に）分配のためにインストーラ内でパッケージ化する。クリアラ(Clearer) 図３は、支払いサービスクリアラモジュールの主要な実行ループのフローチャートを与える。この手段の機能はＱｕｉｃｋＰａｙマーチャントによってコレクトされた（集められた）支払いトークンを処理することである。クリアラはネットワーク上でマーチャントからの要求を聞く。要求が行われるとき、クリアラは要素集合（タップル）｛ｉｍ，ｔｍ，ｉｃ，ｔｃ，ｎ｝（なお、ｉｍはマーチャントにおけるカルネの識別子であり、ｔｍはマーチャントにおけるカルネからのトークンであり、ｉｃはクライアントにおけるカルネの識別子であり、ｔｃはクライアントにおけるカルネからのトークンであり、ｎはクライアントからのトークン数である）を読取り、それが適切にフォーマットされていることを検査する。クリアラは｛ｉｍ，ｔｍ｝および｛ｉｃ，ｔｃ，ｎ｝（以下参照）を検査する。両方の検査が通過すると、支払いサービスはマーチャントに対する口座記録をインクリメントし、別のｎ個のトークンの受理を示す。認証メッセージはマーチャントに戻される。オプションで、認証メッセージは、マーチャントに予め送られた認証トークンのシーケンス内の次のものであってもよい。認証が失敗したとき、トークン値の補数を送ってもよい。図４は、｛ｉ，ｔ｝または｛ｉ，ｔ，ｎ｝の要素集合を確認するプロセスを記載している。クリアラはキーｋ、データベースＩＤ、開始オフセットｓ、およびトークンカウンタｃをＣＩＤから読取ることによって開始する。ｓ、ｃ、およびｎを使用して、クリアラは生のデータベースｄ内のカルネに対して次に期待されるトークンの位置を判断する。クリアラはこのトークンを読取り、ｋを使用してキーされたハッシュを形成する。結果が供給された値と同じであるとき、トークンは受理される。ときどき、カルネ内の索引ポインタが支払いサービスの索引ポインタよりも先を指している状態が生じることになる。これはコレクトされたがクリアされていないトークンの結果として発生する。クリアラはこの問題を処理する機構をもつ。ＲＮＤから検索した第１のトークンが整合しないと、クリアラは先をサーチ（探索）し、次のトークン、また次のトークンなどで試行する。クリアラは１００以内の試行（この場合の１００という数字は特定の構成の要件にしたがう変数である）で整合するトークンを受理することになる。スキップされたＲＮＤ内の各トークンに対して、クリアラはＣＩＤ内のカルネに対して再同期カウンタをインクリメントする。クリアラは数字で表したコードを戻すことによって成功または失敗を報告する。上述のように、基本的な方法は、支払いサービスにおいて現在の索引ポインタから一定の範囲を単に進めるのではなく、移動するウインドウを使用することによって一層融通性をもたせることができる。図１０は、移動するウインドウ方法を説明している。図１０は、｛ｉ，ｔ｝および｛ｉ，ｔ，ｎ｝の要素集合（タップル）組の確認の仕方を示している。クリアラはＣＩＤから、カルネｉに対するキーｋ、データベースID ｄ、開始オフセットｓ、およびトークンカウンタｃを読取ることによって開始する。クリアラは値ｓ、ｃ、およびｎを使用して、生のデータベースｄ内のカルネに対する次の期待されるトークンの位置を判断する。クリアラはこのトークンを読取り、ｋを使用してキーされたハッシュを形成する。その結果が供給された値ｔと同じであるとき、トークンは受理される。取引きのわずかな再順序付けの余裕をとるために、取引きウインドウが次の期待されるトークンの位置を取り囲んでいるように維持する。この位置の値を単にテストする代わりに、クリアラは、トークンがウインドウ内のどこかで発生するときにそれを受理することとする。最初に、ウインドウは次に期待されるトークンの位置から始める。取引きがシーケンスの外に到達するとき、クリアラはトークンをクリアする試行で、ウインドウ内で順方向にサーチする。整合が発見されると、重複して費やすのを避けるためにクリアラは、特定のトークンがクリアされたという、事実を記録する。図１０では、記憶したシーケンス内でのクリアしたトークンに対応する位置が影を付けて示されている。ウインドウの大きさは構成可能なシステムパラメータである。クリアラはフラグを記憶して、ウインドウ内の各トークンの状態を示さなければならないので、ウインドウの大きさはクリアラの記憶要求に影響を与える。トークンを費消すると、ウインドウは生のデータベース内の数字のリストに沿って前方向に進む。ウインドウは２つの状況のもとで移動する；すなわち、１．トークンがウインドウの後部でクリアされるとき、および、２．クリアラがウインドウの前部を超えて前方向にサーチして、トークンをクリアするときである。（２）の場合、ウインドウ前方向に移動するとき、トークンはウインドウの高部で失われる。クリアラはこのやり方（再一致化カウント）で失ったトークンのカウントを付加的に維持する。オプションで、ＱｕｉｃｋＰａｙシステムの構成は、１のウインドウサイズを構成することによってウインドウイングを使用しないことを選ぶことができる。このやり方では、クリアラは状態フラグをウインドウ内の項目に対して維持しないが、シーケンスから外れた取引きをクリアすることはできない。更新手段更新手段は生成手段に類似しているが、更新手段がＵＲＤおよびＣＩＤ内の既存のエントリからカルネを再構成することが異なる。更新手段を使用してクライアントまたはマーチャントのトークンデータベースを再記録するが、それは損傷を受けるか、または支払いサービスと同期しないことを条件とする。さらに更新手段を使用して、支払いサービスによって落とされた（クリアされていない）トークンを回復することができる。図５は更新手段のフローチャートを示す。更新手段はＣＩＤからカルネの大きさｓ、トークンカウンタｃ、および再同期化カウンタｒを読取る。更新手段は、残りのトークン数を計算し、新しいキー、データベースＩＤ、および開始索引を生成する。残りのアルゴリズムは生成手段に関する。マーチャントモジュールマーチャントモジュールはコレクタ、管理機能、および認証トークンデータベースを含む。コレクタマーチャントがユーザのカルネから支払いを集めたいとき、コレクタが呼出される。図６は、コレクタの実行に関するフローチャートである。段階６１ではコレクタモジュールはペイヤ（Payer、支払者）モジュール（以下に記載される）内の財布(wallet)への接続を確立する。段階６２では、Ｎ番目のトークンがペイヤから要求される。なおＮは取引きのために必要な金銭的な値を与えるのに要求されるトークン数によって決定される。段階６３では、ペイヤから応答を受取る。段階６４で応答をテストして、要求を拒絶する必要があるときは、段階６１０で失敗がシグナリングされる。さもなければ、段階６５でマーチャントは支払いサービスに接続する。段階６６で、次の値、すなわちマーチャントＩＤ（ＭＩＤ）、認証トークン(ＡＴ)、Ｎ、財布ＩＤ（ＷＩＤ）、支払いトークン（ＰＴ）を含む要素集合が送られる。段階６７では支払いサーバからの応答が受取られ、段階６８で応答がテストされる。認証のための要求が拒絶されないとき、段階６９でペイヤに成功がシグナリングされる。さもなければ、認証に対する要求が拒絶され、段階６１０で失敗がシグナリングされる。管理機能マーチャントモジュールは管理機能を含む。管理機能は未使用の認証トークンにおける残数の計数を維持し、その数が所定の閾値よりも少なくなったときに、支払いサービスへ別のトークンの要求を送る。カルネカルネはペイヤ、支払いトークンデータベース、および管理機能を含む。さらに、クライアントのプラットフォームへの最初のインストールができるインストーラも含む。ペイヤペイヤは支払いトークンに対する要求を処理することができる。ペイヤはネットワークから要求を受取り、要求を受けるか否かを決定する。この決定は多数の要素に基づいており、それにはユーザ入力、残りのトークン数、および先の取引きの履歴が含まれる。図７は、ペイヤに関するフローチャートを与える。管理機能マーチャントモジュールに関して、カルネはカルネをリフレッシュして、新しいトークンを付加する機構を含む。さらに、ユーザの装置に記憶された支払いトークンはＰＩＮ（個人識別番号）によって保護されている。インストーラインストーラはユーザの装置上でＱｕｌｃｋＰａｙクライアントを設定する。インストーラは多数のファイルおよびディレクトリを作成して、ユーザが新しくインストールした支払いトークンをＰＩＮで保護できるようにする。この例ではＱｕｉｃｋＰａｙクライアントはＵＮＩＩＸシステムに対する圧縮したタールファィル(tar file)として分配される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims

【特許請求の範囲】１．ディジタル支払い取引きシステムを動作する方法であり：ａ）支払いサーバに乱数のシーケンスを記憶することと；ｂ）前記記憶した乱数のシーケンスから導き出したディジタルコード化した乱数シーケンスを含む１組のディジタルの支払いトークンをユーザに送ることと；ｃ）ユーザからマーチャントプラットフォームへ支払いトークンを転送することと；ｄ）段階（ｃ）でユーザから受取った支払いトークンをマーチャントプラットフォームから支払いサーバへ転送することと；ｅ）支払いサーバにおいて、マーチャントプラットフォームから乱数のトークン値と記憶した乱数のシーケンス内の対応する位置から導き出した値とを比較することによってトークンを認証することと；ｆ）後に、支払いサーバからマーチャントプラットフォームへ認証メッセージを通信することとを含む方法。２．支払いサーバは、マーチャントのプラットフォームから隔っており、支払いプラットフォームは遠隔通信ネットワークにおいて支払いサーバと通信する請求項１記載の方法。３．前記シーケンスの一部を選択して、前記シーケンスの一部をユーザに特定のキーでコード化することによって、支払いサーバに記憶した乱数のシーケンスからディジタル支払いトークンの組を導き出す請求項１または２記載の方法。４．前記シーケンスの一部が対称ブロック暗号によってコード化される請求項３記載の方法。５．ユーザはマーチャントのプラットフォームから隔たっており、段階（ｃ）で支払いトークンを通信ネットワークを介してマーチャントのプラットフォームへ転送する請求項１乃至４の何れか１項記載の方法。６．ディジタル支払いトークンを認証する段階が：ｉ）支払いサーバに記憶した乱数のシーケンス内の位置の値に対してディジタル支払いトークンの認証を試みることと； ii）トークンが段階ｉ）で認証されないとき、前記位置から所定の最大距離に含まれる記憶したシーケンスの１または複数の他の値に対してディジタル支払いトークンの認証を試みることとを含み；段階（ｆ）において、認証メッセージはトークンが段階（ｉ）および段階（ ii）で首尾よく認証するときに認証が成功であることを示す請求項１乃至５の何れか１項記載の方法。７．段階（ｄ）において、マーチャントが支払いトークンと一緒に、支払いサーバから発行された認証トークンのシーケンスから認証トークンを伝える請求項１乃至６の何れか１項記載の方法。８．支払いサーバが、確認した支払いトークンおよびマーチャントプラットフォームから受取った認証トークンを認証した後にマーチャント口座記録を自動的に更新する請求項７記載の方法。９．ｆ）支払いサーバにおいてディジタル支払いトークンの組の現在の状態の記録を維持することと；ｇ）ユーザに対して送られたディジタル支払いトークンが失われるかまたは損われているとき、支払いサーバからユーザへデータを送り、それによってディジタル支払いトークンの組を支払いサーバに記録した状態に対応する状態に更新することとを含む請求項１乃至８の何れか１項記載の方法。１０．ユーザに識別番号(PIN)を送ること；識別番号を使用して、乱数の前記記憶したシーケンスから導き出した数字を変更することと；識別番号を使用して、段階（ｃ）でマーチャントに転送されたディジタル支払いトークンをさらに変更することとを含む請求項１乃至９の何れか１項記載の方法。１１．ディジタル支払いトークンを変更し、さらに変更する段階において、乱数の記憶したシーケンスから導き出したディジタルにコード化した値を、ブール論理演算を使用して識別番号と組合わせる請求項１０記載の方法。１２．前記ブール論理演算がＸＯＲであり、同じ識別番号を変更し、さらに変更する段階で使用するとき、ディジタルにコード化した値をさらに変更する段階が、乱数の前記記憶したシーケンスから導き出される元の値を再生する請求項１１記載の方法。１３．ディジタル支払い取引きシステムを動作する方法であり：ａ）ディジタルにコード化した乱数のシーケンスを含む１組のディジタル支払いトークンをユーザに送ることと；ｂ）ディジタルにコード化した乱数のシーケンスを含む１組の認証トークンをマーチャントに送ることと；ｃ）ディジタル支払いトークンをユーザからマーチャントへ転送することと；ｄ）前記ディジタル支払いトークンを転送し、ディジタル支払いトークンと共に認証トークンをマーチャントから支払いサーバへ転送することと；ｅ）ディジタル支払いトークンおよび認証トークンを支払サーバに記憶した記録に対して認証することと；ｆ）認証メッセージをマーチャントへ戻すこととを含む方法。１４．ディジタル支払いトークンを認証する段階が：ｉ）支払いサーバに記憶した乱数のシーケンス内のある位置において値に対するディジタル支払いトークンを認証しようとすることと；ｉｉ）トークンが段階ｉ）で認証されないときは、記憶したシーケンス内の１または複数の値に対してディジタル支払いトークンを認証しようとし、他の値は前記位置から所定の最大距離の間に含まれることとを含み；段階（ｆ）で、段階（ｉ）または段階（ｉｉ）の何れかでトークンを首尾よく認証したときに認証が成功したことを認証メッセージが示す請求項１３記載の方法。１５．認証トークンが認証メッセージで支払いサーバによって戻される請求項１乃至１４の何れか１項記載の方法。１６．前記認証トークンが、マーチャントへ予め送られる複数の認証トークンの１つに対応する請求項１５記載の方法。１７．マーチャントプラットフォームが：ディジタルにコード化された乱数を含むディジタル支払いトークンをユーザから受取る手段と；ディジタル支払いトークンが支払いサーバへ転送する手段と；前記ディジタル支払いトークンが認証に成功したときに、支払いサーバによって送られる認証信号に応答する手段とを含む請求項１乃至１６の何れか１項記載のマーチャントプラットフォーム。１８．支払いサーバによって送られる認証トークンのシーケンスでプログラムされたメモリをさらに含み、使用の際に認証トークンが各ディジタル支払いトークンで支払いサーバへ戻される請求項１７記載のマーチャントプラットフォーム。１９．支払いサーバが：ａ）乱数のシーケンスでプログラムされたデータメモリと；ｂ）データメモリ内のシーケンスから導き出されたディジタルにコード化された乱数のシーケンスを含むディジタル支払いトークンを送る手段と；マーチャントプラットフォームによって戻されたディジタル支払いトークンを認証する手段と；マーチャントプラットフォームへ認証メッセージを出力する手段とを含む請求項１乃至１６の何れか１項記載の方法において使用する支払いサーバ。２０．クライアントプラットフォームが：クライアントプラットフォームから隔たっている支払いサーバから、ディジタルにコード化した乱数のシーケンスを含むディジタル支払いトークンを受取る手段と；前記ディジタル支払いトークンを記憶するトークンメモリと：シーケンスからマーチャントプラットフォームへトークンを送る支払い手段とを含む請求項１乃至１６の何れか１項記載のクライアントプラットフォーム。２１．請求項１７または１８記載の１または複数のマーチャントプラットフォーム、請求項１９記載の支払いサーバ、および請求項２０記載のプラットフォームを含む通信ネットワーク。