JP4307564B2 - トランザクションシステム - Google Patents

Description

本発明は、ディジタル支払い業務（トランザクション）システムに関する。
インターネットの発達および市場化に伴って、オンラインで支払いができる方法に要求が高まっている。この要求は、比較的に高額のトランザクション（取引）では、銀行のような信頼を受けている当事者（trusted party）によって送られる電子小切手（electronic cheques）を使用するシステムによって適切に満たされる。一般的にこのような電子小切手は、公開キーアルゴリズムを使用して暗号化されるサインによって検証確認がされる。しかしながらこのアルゴリズムの使用に関係して相当な計算のオーバーヘッド（仕事量）がある。したがって、現実の生活上で小切手が附随のトランザクションコストのために購入金額が低いときに受領されないのと同じように、エレクトロニックコマース（電子売買取引）では電子小切手は小額の支払いには適していない。
低額のトランザクションに求められるいわゆる“マイクロペイメント”を行うのに適した代わりのトランザクションシステムに対しては、多数の提案が行われてきた。１つの有望なアプローチでは、秘密の乱数または擬似乱数から一連のディジタル支払いトークンを生成するハッシュ関数のチェーンを使用する。この方法で生成される一連のデジタル支払いトークンは、コインスティック（coin stick）として知られている。ハッシュ関数は、可変の大きさをもつ入力ｍをとり、ハッシュ値と呼ばれる固定長のストリングｈを戻す変換である。このような本発明の支払いシステムを暗号化の目的で使用するとき、ハッシュ関数を選択するが、ハッシュ関数は一方向関数として選ばれ、言い換えるとハッシュ値がｈのときには、入力値ｍを計算することはコンピュータ処理上不可能である。
本発明の第１の態様にしたがって、ディジタルトランザクションシステムを動作する方法であって；
ａ）第１の当事者において、（“ブローカ”）がディジタルにコード化された秘密の番号を生成することと、
ｂ）第１の当事者において秘密の番号を記憶することと、
ｃ）第２の当事者（“ユーザ”）へディジタルにコード化された秘密の番号、または秘密の番号から導き出された番号を伝えることと、
ｄ）秘密の番号から導き出されたハッシュチェーンを生成することと、
ｅ）支払いをするときに第２の当事者から、複数の潜在的なベンダから選択される第３の当事者（“ベンダ”）へ、ハッシュチェーンからディジタルにコード化された値を伝えることとを含む方法を提供する。
本発明の第１の態様では、３以上の当事者間でコインスティックを使用する方法を提供する。この方法は、トランザクションシステムの動作の融通性を著しく増し、例えば多数のベンダとオンラインで取引するときに使用するのに適したものとしている。
動作の際に、ユーザは銀行によって秘密の乱数を発行されるようにすることができる。これはハッシュチェーンの始まりを構成している。次にユーザは周知のハッシュ関数を使用して、シリアル番号に対して演算して、第１のハッシュ値を生成し、次にハッシュ関数を使用して第１のハッシュ値に対して演算して、第２のハッシュ値を生成し、以下、同様に続ける。処理は所定回数、例えば１０回繰返されて、それぞれが所定値をもつ多数のユニットに対応している多数のハッシュ値を生成する。例えばオンラインサービスを行なうベンダへ支払いを振替えるとき、ユーザはハッシュチェーンの最後に値、すなわちこの例では１０回目のハッシュ演算の結果をベンダへ伝える。ベンダは、この値を送付元の銀行へ戻すことによってこの値を確認する。銀行は、このハッシュ関数を使用して、この値が関係する秘密の乱数から生成される１０番目のハッシュ値に対して予測される値であることを確認する。銀行はこの値が有効であることをベンダに対して確認する。そこでユーザが、例えば３つの単位の値を送りたいとすると、ユーザはベンダに、例えばハッシュチェーンに沿って３段階戻ったハッシュ値、すなわち、この例ではハッシュ関数の７番目の演算結果を伝える。ここでベンダは、銀行とさらに通信せずに、単にハッシュ関数を使用して送られたハッシュ値で演算することによって、このハッシュ値を確認することができる。ハッシュ関数は性質上一方向性であるために、ベンダはチェーンの最後の値を知っていても、ユーザによって送られた値に先行する値を生成できない。
本発明の第２の態様にしたがって、ディジタル支払いトランザクションシステムを動作する方法であって、
ａ）第１の当事者において、（“ブローカ”が）秘密の番号を生成することと、
ｂ）第１の当事者において秘密の番号を記憶することと、
ｃ）第１の当事者において、ハッシュ関数の連続的な演算によって秘密の番号から導き出された値の第１のハッシュチェーンを生成することと、
ｄ）第２の当事者（“ユーザ”）にハッシュ値のチェーンからディジタルにコード化された値を伝えることと、
ｅ）第２の当事者において、段階（ｄ）で第１の当事者によって伝えられた値から導き出された値の第２のハッシュ値のチェーンを生成することと、
ｆ）支払いをするときに前記第２のハッシュチェーンから第３の当事者（“ベンダ”）へディジタルにコード化された値を伝えることと、
ｇ）次に、段階（ｄ）で最初に伝えた値に先行する前記ハッシュチェーンの値を第１の当事者から第２の当事者へ伝えることとを含むディジタルトランザクションシステムを動作する方法を提供する。
本発明のこの態様では、ハッシュ関数が性質上一方向性であるにも関わらず、値が存在するコインスティックのユーザに送られて、値がユーザからも送られるようにできるトランザクションシステムを提供する。したがって、例えばユーザは銀行との商取引関係をもつ必要なく、ベンダはユーザに返戻できる。これに代わって、この能力を使用してユーザは、コインスティックを継ぎ足し、新しいコインスティックの生成に関係するような処理および通信のオーバーヘッドを発生せずに、銀行への別の支払いをすることができる。潜在的にユーザが使用可能な値は、ハッシュチェーンの未使用の値の数に対応する単一のポインタによって判断されるのではなく、２つのポインタとして保持される２つの値の、すなわちコインスティックを発行する当事者（“ブローカ”と呼ばれる）の値とユーザの値との差によって効果的に判断することができる。実際にどんな場合にも使用可能な値は、ユーザによって保持される最も高いポインタとこれまでベンダにこれまでに示された最も高いポインタとの間の差に対応している。値をユーザに返戻するために、ベンダはそれがブローカに示した値のいくつかに対する権利を行使しないことでブローカに同意して、ブローカはポインタを動かし、これがユーザに示した値をハッシュチェーンに戻すことに対応しており、段階（ｄ）で最初に伝えたハッシュ値に先行する値をユーザに送る。したがって、ベンダに支払うためにユーザが使用できる値についての付加的な単位となる。
好ましくは、支払いトランザクションシステムはプリペイドシステムであり、段階（ｄ）において、ハッシュチェーンからの値は第２の当事者による第１の当事者への支払いがあるときに発せられる。
好ましくは、第１、第２、および第３の当事者の少なくとも２つはすべて互いに離れて位置し、ディジタルにコード化されるハッシュ値は、当事者をリンクする通信ネットワークを介して当事者間で伝えられる。通信ネットワークはインターネットプロトコルを使用するのがよい。
上の序説に記載したように、本発明はとくにオンラインの取引、例えばインターネット上での必要性に対応することに関する。本発明のディジタル支払いトランザクションシステムが与える通信のオーバーヘッドが低減した結果、この情況についてみると本発明の使用はとくに効果的である。しかしながら本発明はこのやり方で使用するのに制限されず、さらに例えば支払いカードおよび支払いカードを読み取る電子端末で行われるトランザクションにおいても使用することができる。
本発明の第３の態様にしたがってディジタル支払いトランザクションシステムで使用する支払いサーバであって、
ａ）秘密の番号を生成する手段と、
ｂ）秘密の番号を記憶するメモリと、
ｃ）ハッシュ関数の連続的な演算によって秘密の番号からハッシュチェーンを生成する手段と、
ｄ）ハッシュ値の前記チェーンからの値をユーザに送出する手段と、
ｅ）ユーザまたは別の当事者からの要求に応答して、段階（ｄ）において最初に送られた値に先行する値の前記ハッシュチェーンからの別の値をユーザへ送る手段とを含む支払いサーバを提供する。
本発明の第４の態様にしたがって、本発明は、ディジタル支払いトランザクションシステムを動作する方法であって、異なる額面金額に対応する複数の異なるハッシュチェーンをユーザへ送ることを含む方法を提供する。第４の態様は都合のよいことには、本発明の別の態様の１または複数の方法と結合することができるが、別の態様と独立して使用することもできる。
本発明の第５の態様にしたがって、ディジタル支払いトランザクションシステムを動作する方法であって：
ａ）第１の当事者において、（“ブローカ”が）ディジタルにコード化された秘密の番号を生成することと；
ｂ）第１の当事者において秘密の番号を記憶することと；
ｃ）ディジタルにコード化された秘密の番号、または秘密の番号から導き出された番号を第２の当事者（“ユーザ”）へ伝えることと；
ｄ）秘密の番号から導き出した値のハッシュチェーンを生成することと；
ｅ）第２の当事者から、複数の潜在的なベンダから選択される第３の当事者（“ベンダ”）へのハッシュチェーンから支払いのときにディジタルにコード化された値を伝えることと；
ｆ）次に、複数の潜在的なベンダの別の１つを選択し、段階（ｄ）で生成されるハッシュチェーンから１または複数の別の値を、複数の潜在的なベンダの前記別の１つのベンダへ伝えることとを含む方法を提供する。
本発明の第５の態様は、第１ないし第４の態様と結合してもよいが、第１ないし第４の態様と独立して使用することもできる。異なるベンダ間でユーザをスイッチできるうようにすることによってコインスティックを使用する際の融通性を向上する。とくに、ユーザ間で切換え（スイッチ）が行われるときには、ブローカへの告知の責任は新しいベンダにあることが好ましい。
選択に使用できる潜在的なベンダの数は好ましくは５００以上、さらに好ましくは１０００以上である。
本発明の別の重要な特徴は、多くのベンダを含む大規模システムへのスケーラビリティ（大きさへの適応可能性）である。
ここで本発明を実現できるシステムを添付の図面を参照してさらに詳しく記載することにする。
図１は、本発明を実現するネットワークの模式図である。
図２は、図１のネットワークの構成要素をさらに詳しく示したダイヤグラムである。
図３は、コインスティックを生成するときに使用されるハッシュ機能のチェーンを示すダイヤグラムである。
図１に示したように、クライアント端末１は、この例ではパーソナルコンピュータであり、モデム２およびＰＳＴＮ（公衆交換電話ネットワーク）３を経由してインターネットサービスプロバイダ（ＩＳＰ）４へ接続される。クライアント端末は、インターネットを経由して、支払いサーバを動作するブローカ６、および多数のオンラインベンダ５の１または複数への接続を複数回形成する。この例ではベンダ５は支払いに対するサービスを提供する。例えばベンダは、ＨＴＴＰプロトコル（ハイパーテキスト転送プロトコル）を使用してページごとに廉価な課金で個人の新しい項目のページにサービスすることができる。
クライアント端末はウエッブブラウザアプリケーション、例えばマイクロソフト社のインターネットエクスプローラ（Internet Explorer）^TMを実行する。支払いアプリケーションは、プラグインまたはヘルパアプリケーションのようなウエッブブラウザと関連して実行される。ブローカ６において、支払いサーバはアプリケーションプラットフォーム、この例ではＵＮＩＸワークステーションにおいて送行する。図２は、支払いサーバおよびベンダのクライアント支払いアプリケーションの構造をさらに詳しく示す。クライアント支払いアプリケーションは支払いモジュール102、メッセージングモジュール103、およびローカルデータメモリ104を含む。支払いサーバはコインスティック送出（発行）モジュール601、確認モジュール602、メッセージングモジュール603、および決済モジュール（settlement module）609を含む。コインスティック送出モジュール601には乱数生成器604が接続されている。ローカルデータメモリ605は、ユーザに送出したコインスティックに関するデータを記憶する。ベンダは、支払いトランザクションモジュール501、確認モジュール502、およびメッセージングモジュール503を含む。ベンダのデータメモリ504はユーザから受取ったディジタル形式の支払いトークンを記憶する。ブローカは到来する要求に対して３つのインターフェイス、すなわちコインスティック送出インターフェイス606、承認インターフェイス607、および決済インターフェイス608を示す。ベンダは到来する要求に対して２つのインターフェイス、すなわち支払いインターフェイス505およびコールバックインターフェイス506を示す。
使用の際、クライアント１は最初にブローカに接触して、コインスティックを購入する。次にクライアント１はベンダ５に接触する。クライアントは購入したいときに、コインスティックからベンダへ値の振替えがされる。ベンダ５はブローカ６と通信して、クライアント１から受取った値から導き出された最後の値の有効性を確認する。有効性がクライアントに対して確認されると、例えばＨＴＴＰページの購入が行われる。ベンダ５は、クライアント１から受取った値を記憶する。次にベンダ５は受取った値をブローカ６へ戻す。それにしたがってブローカ６がベンダ５へ支払いをすることによって、支払いトランザクションが完了する。ベンダ５はさらにブローカ６と接触して、クライアント１への返金を要求する。
クライアントに対して、銀行はスティックが有効であると伝えるが、一方でベンダはスティックが有効でないと伝えるときには、ブローカがスティックからコインを取出していたとしても、スティックが有効であるとブローカが伝えたことを証明できる（ブローカは信頼できる）ので、クライアントは補いを受ける。
ここで既に概略的に記載した異なる段階についてさらに詳細に記載する。
クライアント１は最初に、ウエッブブラウザ、すなわちブローカ６のコインスティック送出モジュール601のインターフェイス606に対応するインターネットＵＲＬ（ユニフォームリソースロケータ）にアクセスすることによってブローカ６に接触する。コインスティック送出モジュール601はＣＧＩ（共通のゲートウエイインターフェイス）のスクリプトを実行して、ユーザからデータを受取って処理し、後でさらに記載するように、ユーザとディジタルにサインした契約を確立する。クライアントはブローカ６から特定の値、例えば１０ポンドのコインスティックを、特定の額面金額、例えば１０ペンスで要求する。クライアントは、例えばユーザのクレジットカード番号を暗号化して伝えることによって、ブローカにコインスティックに対して支払う。その代わりに本発明は匿名であることに注意すべきであるので、匿名の支払い方法、例えばＭｏｎｄｅｘ^TMを使用することができる。応答して、コインスティック送出モジュールは乱数生成器604から１６０ビットの値ｚ₀を読み取る。図3に示したように、コインスティック送出モジュールは、ハッシュ関数を使用してこの値ｚ₀を演算してハッシュ値ｚ₁を生成し、ハッシュ関数を使用して値ｚ₂を生成し、以下同様に続く。ハッシュ関数を使用した処理は所定回数、例えば５０回反復され、生成された値ｚ_mはクライアント１へ送出されて、コインスティックの基礎を形成する。ブローカは、クライアント１へ送出された値のハッシュチェーン内に位置ｍを記録するポインタを記憶する。（本明細書では“ポインタ”という用語を使用して、表示値または類似の記憶されたインジケータを幅広く示す）。このポインタは、“ポインタ算術（pointer arithmetic）と呼ばれるものを使用するＣ＋＋のようなプログラミング言語で実行されるポインタに制限されない。値ｚ_mは、例えば公開キーアルゴリズム、例えばＲＳＡデュアルキーを使用して、クライアント１へ送るためにコード化することができる。値ｚ_mはディジタル的にサインした契約に定められた条件の下で発せられる。この例では、契約に次のデータ、すなわち、
ｖ₀、コインスティック値、
ｄ_u、コインスティックの額面金額、
ｈ_u、ハッシュ関数、
ｉ、ブローカ内部ではユニークなコインスティック識別子、
ＵＲＬ_A、ブローカの承認インターフェイスのアドレス、を含む。
値ｚ_mを除くすべてのこれらのデータは暗号化せずに公開して伝えることができる。しかしながら、私用でないときは、メッセージのタンパプルーフを行うことが望ましい。正しい当事者からきたことが証明することができないメッセージの中（勝手にいじれない方策）にいんちきのインターフェイスが存在することを誰でもが書込めるようにするのではなく、後で使用することを意図したインターフェイス識別子が、信頼できることが分かっている最初のメッセージと一緒にパッケージ化されることが、セキュリティのために重要である。ハッシュ関数は、一般的に使用されている多数の暗号化ハッシュ関数の１つであってよい。適切なハッシュ関数は、ＳＨＡ１およびＲＩＰＥ＿ＭＤ（１６０）として知られているハッシュ関数を含む。ハッシュ関数と額面金額の両方は、各メッセージ内で直接に通信する必要はないが、標準のプロトコル名を参照することによって黙示的に知ることができるが、しかしながらインフレーションまたはハッシュ関数の数字上の妥協（mathematical compromise）が原因となってその必要が生じたときには、ハッシュ関数と額面金額の両方を明白に各メッセージ内に含むことによって、プロトコルの格上げが一層容易になる。
ブローカとクライアントとの間の契約には、コインスティックのコインがベンダにいったん示されると、該コインを超える金額を返戻するという銀行側の責任性は、ユーザに支払う責任があることからベンダに支払うという責任へ振替わることを明記している。したがってユーザは、コインスティックから値を明らかにすることによってベンダへ金額を振替えることができる。
ブローカからコインスティックを購入したとすると、クライアント１はベンダのウエッブサイトにアクセスすることになる。この例ではクライアント１は、異なる題目のもとで多数のページの個人化されたニュース情報であって、しかもそれぞれがユーザの特定の関心に対応するプロフィールに一致しているものへのアクセスを要求する。ベンダにおけるトランザクションモジュール501は要求されたページｖ_pの合計金額を計算し、クライアント１から支払いインターフェイスへのこの金額の支払いを要求する。支払いインターフェイスはベンダに置かれていて、ベンダの直接的な制御のもとで動作することができる。その代わりに、ベンダは別の当事者への支払いを下請け契約（subcontract）することができ、この場合には下請け契約者の制御のもとで支払いインターフェイスは動作する。クライアント１における支払いモジュール102は最初に、ハッシュ関数の反復回数に関係して最初のコインスティックの長さｎを、ｎ＝ｖ_o／ｄ_uで計算する。次に支払いモジュール102は最初の支払いによって不必要になった反復回数を計算する。なおｐ＝ｖ_p／ｄ_uである。ハッシュ値の対応する数ｎ−ｐは、ブローカによって与えられる秘密値ｚ_mから始めて、繰り返し計算される。生成されたハッシュチェーンの最後で値ｖ_m+n-pは、ｄ_u、ｈ_uｉ、およびＵＲＬ_Aと共にベンダに伝えられる。ｄ_u、ｈ_uの一方または両方は、標準のプロトコル名を参照することによって含まれる（黙示的に示す）ことができる。
次の段階では、ベンダはｐも計算し、ハッシュ値ｚ_m+n-pに対してこのより多くのハッシュ関数を実行して、値ｚ_m+nに到達する。ベンダはＵＲＬ_Aでブローカの承認インターフェイスに接続して、ブローカにコールバックインターフェイスＵＲＬ_cを送り、ｚ_m+nがクライアントに向けて発せられた識別子ｉをもつコインスティックの長さの値であることの確認を要求する。ブローカはその記憶したデータを確認し、ベンダによって伝えられたｚ_m+nの値と、同じハッシュシーケンスを実行することによってコインスティックｉの最後に対して期待される値とを比較する。これらの値が整合すると、ブローカはベンダに応答して、決済インターフェイスＵＲＬ_sにおいて、値ｖ₀に達するまでコインスティックを使用して支払らうことを確認する。ユーザが長さ、したがってコインスティックの値を、例えばｚ_m+n+1まで増加して、銀行に詐欺行為をしようとするときは、銀行はこのポイントでトランザクションを拒否する。
この段階で、ベンダはブローカから接続をはずすことができる。ここでベンダは品物をクライアントへ送る。
次に、品物についての後の要求するには、支払いモジュール102で要求された価格に整合するように要求されたコインスティックの額面金額の単位（ユニット）数を計算することが必要である。例えば３つの単位（ユニット）が要求されると、支払いモジュールはベンダに、現在の最後の値ｚ_m+n-pからハッシュチェーンを３段階戻ったハッシュ値を伝える。ベンダにおいてトランザクションモジュール501はこのハッシュ値を受取って、3つの別のハッシュ先の最後のハッシュ値になるかを検査し、イエスのときは、データメモリ504内の新しい最後のハッシュ値を記憶して、品物を供給する。
クライアント１は振替えられた最後のハッシュ値にポインタを維持し、これはコインスティック内の残りの値の表示を与える。クライアントは次に、ハッシュチェーン内をさらに戻った別のハッシュ値を示すことによってベンダに別の支払いを後に行うことができる。
上述に対する別のアプローチでは、クライアントはｚ_m+n-pではなく、ｚ_m+n
を直接に計算し、これをベンダに伝えて、チェーンをさらに戻った関連するハッシュ値を伝えるようにクライアントに求める前に、ベンダは上述と同じ承認段階を行うことになろう。これは支払い段階から承認を明白に分けるが、このアプローチはより多くのメッセージというコストがかかる。
ベンダは、アドレスＵＲＬにおいて最後に明らかになったハッシュ値をブローカの決済インターフェイスに伝えることによっていつでもそれにかかった金額を集めることができる。ブローカは、口座を清算（settle）する前にディジタルの証明でそれら自身を識別することをベンダに要求する。
後の段階で、例えば最初のトランザクションに応答して戻った１ページが破損して読取り不可能になったために、ベンダがクライアント１に返金したいとする。返金をするためには、モジュール501が、関係するコインスティックの識別子ｉおよび返金されることになる額面金額ユニット数、例えば２をブローカ６に伝える。次にブローカは、ベンダのコールバックインターフェイス、すなわちＵＲＬ_cを含んでいる関係するコインスティックに関するデータをメモリ605から呼び出す。ブローカは、クライアントに最初に伝えた値ｚ_mからハッシュ値を２段階戻ったハッシュ値ｚ_m-2を読み取る。返金に対する要求をユーザが騙す（spoof）ことに対してセキュリティを与えるために、ブローカはベンダから接続を解除して、ＵＲＬ_cに再び接続して、返金要求が有効であることを確認する。次にベンダは、クライアント１に返金が有効であるという信号を送る。ブローカは、ベンダがここで部分的な決算が記録されるのと同じやり方で最初に契約した額面金額よりも２つ少ない額面数が決算できることを記憶する。次にクライアントはコインスティック送出モジュール601のＵＲＬにアクセスし、ブローカから新しいハッシュ値Ｚ_m-2を受取る。次にクライアント支払いアプリケーションはポインタをリセットして、それがコインスティックｉに残っている値の２つの付加的な額面金額をもつことを示す。ブローカはその各ポインタをｍ−２にリセットする。
上述で記載した手続きで、ブローカはハッシュ関数の最初のチェーンをさらに戻ってクライアントへ新しい秘密の番号を送り、該手続きはクライアントから受取った別の支払いを戻すときに、前もって送ったコインスティックを継ぎ足すのにブローカが使用することもできる。このような構成は、新しいディジタル形式でサインしたクライアントとの契約は必要なく、新しいコインスティックを送ることと比較することによって、新しい契約と関係する処理および通信のオーバーヘッドを避けられる。
上述で概略的に記載したトランザクションシステムを実行することにおいて、ブローカおよびクライアントは１回コンピュータ処理を行って、次にハッシュチェーンにすべての値を記憶する。その代わりに、チェーン内の最初の値のみを記憶することができ、またハッシュチェーン内の特定の値がトランザクションに必要となる度毎に、そこで反復のハッシュ関数をコンピュータ処理することができる。しかしながらコンピュータ処理および記憶のオーバーヘッドにおけるコストを最適化するために、これらの２つのアプローチ間で妥協をはかることが好ましい。したがって、チェーンにおける全てのハッシュ値は最初に計算される。次にクライアントとブローカは各ｙ番目の値（ｚ_y，ｚ_2y，ｚ_3y…）のみを記憶する。次にはさらに少ない値が記憶されることになり、ハッシュ関数に必要な計算の数は低減し全チェーンを各トランザクションに対する始め（スクラッチ）から計算される。
上述の例では、全てのトランザクションはオンラインで実行されるが、この通りでなくてもよい。例えば、ユーザは、ブローカとして機能するスマートカードを採用することができる。次にコインスティックデータをブローカモジュールを支援するプラットフォームに接続されたカード読取り／書込み端末からスマートカードのメモリ内に直接にロードすることができる。同様に、ベンダとのトランザクションはユーザのスマートカードとＥＰＯＳ（電子ポイントオブセール）端末との間で行うことができる。この場合に、クライアントの機能はスマートカード上で実行することができ、ベンダ機能はＥＰＯＳで実行され、第１の例でインターネットによって実行される機能はＥＰＯＳの内部接続によって置換される。別の観点では、システムは第１の例で記載したように動作する。
上述の例では、各当事者によって提供される機能に対するインターフェイスはＣＧＩを介して処理を呼出すＵＲＬによって特徴付けられるが、これらのサービスはインターネットプロトコルおよび他のより専用の通信システムのいずれかにおいては、オブジェクトインターフェイスへの遠隔の手続き呼のような呼出し機構によって提供することができる。この場合、ウエッブブラウザは専門のクライアントモジュールによって置換することができる。
上述の例では、ブローカは単一の当事者として特徴付けられる。その代わりに、ユーザは１ブローカと、ベンダは他のブローカと対話することができ；各ブローカは、例えば従来の電子資金振替（トランスファー）システムを介して他のブローカと通信する。
ユーザに対するシステムの効果は、異なる額面金額ごとのコインスティック（例えば、０．１ペンス、１ペンス、１０ペンス、１ポンド）を送ることによって一層向上することができる。異なる額面金額は異なる開始番号によって、または異なるハッシュ関数によって、あるいは好ましくはその両者によって区別することができる。この場合に、ブローカは多数のハッシュチェーン、すなわち各額面金額ごとに１つのハッシュチェーンを生成し、関連の額面金額を識別するデータと一緒に各チェーンからユーザへ中間値を送る。次にユーザは、異なるハッシュチェーンから最も効率的な組合せの値を読み上げる（call off）ことによって支払いを行う。
この構成の別の特徴は、ユーザが部分的に使用されるコインスティックを使用してベンダ間でスイッチできることである。
ユーザがベンダＭ１からコインスティックをスイッチして、別のベンダＭ２と取引きするには３つの方法があるが、全ての場合において、銀行はコインスティックの現在の長さを伝えられて、Ｍ１との契約をこの新しい値にまで制限できるようになるまでは、Ｍ２がコインスティックを使用することを承認しない。３つの方法は：
（１）ユーザはベンダＭ１に、そのベンダとスティックを使用することを止めたいと望んでいることを示すことができて、ベンダにスティック長の共有する知識を銀行へ渡すように求める。
（２）ユーザは単にベンダＭ２にアプローチして、ベンダＭ１から銀行を介して適切なアクノリッジメントを得る責務を負うようにすることができる。
（３）ユーザは、誰がベンダＭ１のアクノリッジメントを得なければならないかに関して銀行にアプローチすることができる。
（２）の場合は、不必要なＭ２を含み、最も複雑と考えられるが、好ましいアプローチである。その理由は、（２）はＭ２の承認要素と結合できるからである。さらに、彼らがスティックを最後にどこで使用したか、またはかれらがスティックを購入した銀行はどこかを記憶する必要はない（購入した銀行の情報はスティック内にあるが、ユーザのソフトウエアがそれを読み取るか、または銀行の承認インターフェイスプロトコルを知る必要はない）。
（２）と（３）の両方の場合において、銀行は他の方法ではなくベンダＭ１と接触をとらなければならない。何れか一つが実行されると、ベンダと銀行との間で先に記載したプロトコルは、（停止メッセージを送るための）ベンダのインターフェイスを銀行へ送られた情報へ付加することによって変更される。
（２）の場合を採ると、ユーザはコインスティックを新しく銀行から買ったかのようにベンダＭ２にアプローチする。しかしながら、ベンダＭ２が承認のために銀行にアプローチするときに、銀行は異なるベンダＭ１との該スティックをカバーする契約が既に存在していることを認識する。銀行は停止メッセージをベンダ、すなわちＭ１の適切なインターフェイスへ送り、最後のハッシュ値がユーザによって送られたと確認する応答を待つ。そこで銀行は決済契約がスティックの現在の長さまで残高（バランス）が制限されていたことを確認することになる。このアクノリッジメントのときにだけ、新しい契約がベンダＭ２へ送られて、コインを重複して使用するのを防ぐ。その代わりにベンダＭ１からの決済要求は、ベンダＭ１から応答を伴うことにする。
ユーザはベンダをスイッチできることから全てを得るが、費用（コスト）は負担しないことに注意すべきである。例えば、銀行は決済料金を課金でき、したがって低額の口座を使い切った後だけに、ユーザがベンダをスイッチできるようにすることをベンダがしないようにする。したがってベンダはサービスに対する最低料金を自分に課金することにより、ユーザに向けてこの最低料金という障壁を転嫁しそうである。このやり方自身はマイクロペイメントの使用についての障壁になるので、はるかに多そうな解決案は、ベンダがこの最低支払い障壁をユーザに転嫁しないで、その代わりにこの手数料を銀行から回収するのが経済的になるまで多くのユーザから低額の支払いを全て集めることである
あらゆる場合において、ベンダＭ１は、銀行がスティックを使用する別のベンダを承認できるようになる前に、ベンダは別のコインを受領しないように警告するメッセージを受取ったことを知らせることによってユーザの口座（コインスティック）の保持を自発的に放棄しなければならない。したがって、ユーザが融通性を得たいとき、ベンダＭ１との最初の契約はこのような約束を含むことを保証しなければならない。
ここで分散した２つの段階の委託（プロセス）を生成することを避けることが必要であるので、分散した失敗モードは潜在的に困難となっている。しかしながら、上述の一連のメッセージはフェイルセーフである。
この実施形態は、上述の第２の変形例に基づく別の４番目の変形例を使用する。ベンダと銀行の間の契約は、ベンダのコールバックインターフェイス、すなわちＵＲ_Cがオフラインであったときはいつでも、ベンダは、ダウンタイム中に銀行によって停止メッセージを送る試行がなかったことを先ず銀行に確認しないで、品物と交換にハッシュ値コインを受領することによって生じる損失に責任をもつことになることを明記している。いいかえると、ベンダのコールバックインターフェイスが故障しているときに、ベンダの販売インターフェイスも故障することが最も多いので、ダウンタイムの後で、コールバックインターフェイスに対して待ち行列に入るメッセージを要求し、販売インターフェイスにおいて要求を受取る前にメッセージを処理することがベンダの責任になる。コールバックインターフェイスのみがダウンする場合、ベンダは販売を受領し続けたいのであれば、ベンダは危険を冒すことになる。
ユーザはＭ１がオンラインであってもなくてもＭ２にいつでも切換え（スイッチ）できるので、これが好ましい。通常、Ｍ１からのライブのアクノリッジメントは予測されるが、（例えば、タイムアウトの後で）これが受取られないことが明らかになったとき、銀行は単にＭ１のメッセージを待ち行列に入れ、Ｍ１が危険であること知った上で、スイッチが処理を進められるようにする。したがってコールバックインターフェイスにおけるサービス着手の拒否に対してベンダを開けておき、一方ではユーザは別のベンダにスイッチして、同時に第１のベンダから品物を購入しつづけるが、既に記載したように、ベンダがコールバックインターフェイスにおけるサービスの拒否を検出できるときは、単に販売インターフェイスを停止しなければならない。
ユーザが銀行でコインスティック（一部または全部）を現金化したいときは、ユーザがベンダを切換え（スイッチ）したいときの上述の状況と同じになるが、銀行は銀行とＭ２の２つの役割を担う。この場合、キャッシャまたは現金自動預払機はサービスとして現金を売るベンダＭ２のようになり、そこでの銀行の役割はＭ１と通信して、コインスティック口座をキャッシングサービスへ振替えることになる。
一部を使用したスティックをもつベンダを切換える（スイッチする）能力は他の従来のコインスティック支払いシステムで長所として実行することができる。

Claims (20)

1. ディジタル支払いトランザクションシステムを動作する方法であり、
   ａ）第１の当事者（“ブローカ”）において、発行モジュールが秘密の番号を生成するステップと、
   ｂ）第１の当事者においてローカルデータメモリに秘密の番号を記憶するステップと、
   ｃ）発行モジュールが、ハッシュ関数の連続的な演算によって秘密の番号から導き出される値からなる第１のハッシュチェーンを生成するステップと、
   ｄ）発行モジュールが、第１のハッシュチェーンの値のディジタルにコード化された値を、インターフェイスを介して第２の当事者（“ユーザ”）へ通信するステップと、
   ｅ）支払いモジュールが、第２の当事者において、ステップ（ｄ）で第１の当事者によって通信された値から導き出された値からなる第２のハッシュチェーンを生成するステップと、
   ｆ）支払いモジュールが、支払いにおいて、前記第２のハッシュチェーンからのディジタルにコード化された値を第３の当事者（“ベンダ”）へ通信するステップと、
   ｇ）次に、発行モジュールが、ステップ（ｄ）で最初に通信された値に先行する前記ハッシュチェーンの値を第１の当事者から第２の当事者へ通信するステップとを含む、ディジタル支払いトランザクションシステムを動作する方法。
2. 第１、第２、および第３の当事者の少なくとも２つが互いに離れて位置し、ディジタルにコード化されたハッシュ値が、当事者をリンクする通信ネットワークを経由して当事者間で通信される請求項１記載の方法。
3. 通信ネットワークがインターネットプロトコルを使用する請求項２記載の方法。
4. 支払いトランザクションシステムがプリペイドシステムであり、ステップ（ｄ）において、第１のハッシュチェーンからの値が、第２の当事者による第１の当事者への支払いに応じて通信される請求項１ないし３のいずれか１項記載の方法。
5. 第１の当事者および／または第２の当事者が最初にハッシュチェーン内の値を生成し、ハッシュ値のいくつかのみを記憶する請求項１ないし４のいずれか１項記載の方法。
6. ステップ（ｇ）が、第３の当事者から第１の当事者への要求に応答して実行され、それによって第２の当事者へ金額値を返戻する請求項１ないし５の何れか１項記載の方法。
7. ステップ（ｇ）が、第２の当事者から第１の当事者への要求に応答して、第２の当事者から第１の当事者へ支払いに応じて実行される請求項１ないし６のいずれか１項記載の方法。
8. 第２の当事者において、ハッシュ値を第３の当事者へ最初に通信する前に、支払いモジュールが、第３の当事者に対する支払いに必要なハッシュ値の数を計算し、続いてステップ（ｆ）において、ハッシュ値の前記数をハッシュ値の第２のチェーンから導き出した後で、ハッシュ値の前記第２のチェーンの最後に位置するハッシュ値を第３の当事者へ通信する請求項１ないし７の何れか１項記載の方法。
9. 異なる額面金額に対応する複数の異なるハッシュチェーンをユーザへ通信するステップを含む請求項１ないし８の何れか１項記載の方法。
10. 第３の当事者が複数の潜在的なベンダに含まれる請求項１ないし９のいずれか１項記載の方法。
11. １または複数のディジタルにコード化された値を第３の当事者へ通信した後、続いて支払いモジュールが、ステップ（ｅ）で生成されたハッシュチェーンからの１または複数の別の値を、複数の潜在的なベンダの中の別のベンダへ通信する請求項１０記載の方法。
12. ａ）第１の当事者（“ブローカ”）において、発行モジュールが、ディジタルにコード化された秘密の番号を生成するステップと、
    ｂ）第１の当事者において秘密の番号を記憶するステップと、
    ｃ）発行モジュールが、ディジタルにコード化された秘密の番号または秘密の番号から導き出した番号をインターフェイスを介して第２の当事者（“ユーザ”）へ通信するステップと、
    （ｄ）第２の当事者において、支払いモジュールが、秘密の番号から導き出される値からなるハッシュチェーンを生成するステップと、
    ｅ）支払いモジュールが、支払いのときに第２の当事者から、複数の潜在的なベンダに含まれる第３の当事者（“ベンダ”）へ、ハッシュチェーンからのディジタルにコード化された値を通信するステップと、
    ｆ）支払いモジュールが、複数の潜在的なベンダに含まれる第４の当事者に、ステップ（ｄ）で生成されたハッシュチェーンからの１または複数の別の値を通信するステップと、
    ｇ）前記第４の当事者において、ウェブブラウザが、前記１または複数の別の値に関係して、第１の当事者が第１の当事者の支払い義務を第３の当事者から前記第４の当事者へ振替える要求を、第１の当事者へ送るステップとを含む、ディジタル支払いトランザクションシステムを動作する方法。
13. 第3の当事者が一定の期間第1の当事者と通信せず、第3の当事者において、その後、第1の当事者と通信を再び確立した後には、支払いトランザクションモジュールが、支払い義務が複数のベンダの中の別のベンダに振替えられたか否かを判断するために第１の当事者にチェックする請求項１２記載の方法。
14. 選択可能な潜在的なベンダの数が５００以上である請求項１０ないし１３のいずれか1項記載の方法。
15. 選択可能な潜在的なベンダの数が１０００以上である請求項１４記載の方法。
16. 支払いモジュールが第1のブローカのコンピュータと通信し、支払いトランザクションモジュールが第2のブローカのコンピュータと通信し、第1のブローカのコンピュータと第2のブローカのコンピュータとの間で認証メッセージを交換するステップをさらに含む請求項１ないし１５のいずれか１項記載の方法。
17. 認証メッセージがクリアリングシステムを経由して第1のブローカのコンピュータと第2のブローカのコンピュータとの間で交換され、該クリアリングシステムがさらに第1のブローカのコンピュータと第2のブローカのコンピュータとの間で送金も行なう請求項１６記載の方法。
18. 発行モジュールが異なる額面金額に対応する複数の異なるハッシュチェーンをユーザに発行するステップを含む請求項１２ないし１７のいずれか１項記載の方法。
19. ａ）秘密の番号を生成する発行モジュールと、
    ｂ）秘密の番号を記憶するメモリと、
    ｃ）秘密の番号または該秘密の番号から導出した番号を第2の当事者（ユーザ）へ通信する発行モジュールと、
    ｄ）第3の当事者（ベンダ）から支払いサーバにおいて受取ったディジタルにコード化された値が前記秘密の番号から導き出したハッシュチェーン内の値に対応することを認証する承認インターフェイスと、
    ｅ）ディジタルにコード化された値が認証された場合に、前記承認インターフェイスに応答して、第3の当事者へ金額値を振替える決済インターフェイスとを含む、請求項１ないし１８のいずれか１項記載の方法で使用する支払いサーバ。
20. ディジタル支払いトランザクションシステムで使用する支払いサーバであって、
    ａ）秘密の番号を生成する手段と、
    ｂ）秘密の番号を記憶するメモリと、
    ｃ）ハッシュ関数の連続する演算によって秘密の番号からハッシュ値チェーンを生成する手段と、
    ｄ）前記ハッシュ値チェーンからの値をユーザへ発行する手段と、
    ｅ）ユーザまたは別の当事者からの要求に応答して、ユーザに発行する手段で最初に発行された前記値に先行する前記ハッシュ値チェーン内で前記発行された値に先行する値をユーザに発行する手段とを含む支払いサーバ。

Images