JP2003216875A - 電子的決済方法 - Google Patents
電子的決済方法Info
- Publication number
- JP2003216875A JP2003216875A JP2002018706A JP2002018706A JP2003216875A JP 2003216875 A JP2003216875 A JP 2003216875A JP 2002018706 A JP2002018706 A JP 2002018706A JP 2002018706 A JP2002018706 A JP 2002018706A JP 2003216875 A JP2003216875 A JP 2003216875A
- Authority
- JP
- Japan
- Prior art keywords
- customer
- bank
- store
- identifier
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- C—CHEMISTRY; METALLURGY
- C23—COATING METALLIC MATERIAL; COATING MATERIAL WITH METALLIC MATERIAL; CHEMICAL SURFACE TREATMENT; DIFFUSION TREATMENT OF METALLIC MATERIAL; COATING BY VACUUM EVAPORATION, BY SPUTTERING, BY ION IMPLANTATION OR BY CHEMICAL VAPOUR DEPOSITION, IN GENERAL; INHIBITING CORROSION OF METALLIC MATERIAL OR INCRUSTATION IN GENERAL
- C23C—COATING METALLIC MATERIAL; COATING MATERIAL WITH METALLIC MATERIAL; SURFACE TREATMENT OF METALLIC MATERIAL BY DIFFUSION INTO THE SURFACE, BY CHEMICAL CONVERSION OR SUBSTITUTION; COATING BY VACUUM EVAPORATION, BY SPUTTERING, BY ION IMPLANTATION OR BY CHEMICAL VAPOUR DEPOSITION, IN GENERAL
- C23C16/00—Chemical coating by decomposition of gaseous compounds, without leaving reaction products of surface material in the coating, i.e. chemical vapour deposition [CVD] processes
- C23C16/22—Chemical coating by decomposition of gaseous compounds, without leaving reaction products of surface material in the coating, i.e. chemical vapour deposition [CVD] processes characterised by the deposition of inorganic material, other than metallic material
- C23C16/30—Deposition of compounds, mixtures or solid solutions, e.g. borides, carbides, nitrides
- C23C16/40—Oxides
- C23C16/409—Oxides of the type ABO3 with A representing alkali, alkaline earth metal or lead and B representing a refractory metal, nickel, scandium or a lanthanide
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/02—Manufacture or treatment of semiconductor devices or of parts thereof
- H01L21/02104—Forming layers
- H01L21/02107—Forming insulating materials on a substrate
- H01L21/02109—Forming insulating materials on a substrate characterised by the type of layer, e.g. type of material, porous/non-porous, pre-cursors, mixtures or laminates
- H01L21/02112—Forming insulating materials on a substrate characterised by the type of layer, e.g. type of material, porous/non-porous, pre-cursors, mixtures or laminates characterised by the material of the layer
- H01L21/02172—Forming insulating materials on a substrate characterised by the type of layer, e.g. type of material, porous/non-porous, pre-cursors, mixtures or laminates characterised by the material of the layer the material containing at least one metal element, e.g. metal oxides, metal nitrides, metal oxynitrides or metal carbides
- H01L21/02197—Forming insulating materials on a substrate characterised by the type of layer, e.g. type of material, porous/non-porous, pre-cursors, mixtures or laminates characterised by the material of the layer the material containing at least one metal element, e.g. metal oxides, metal nitrides, metal oxynitrides or metal carbides the material having a perovskite structure, e.g. BaTiO3
Landscapes
- Chemical & Material Sciences (AREA)
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Materials Engineering (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Organic Chemistry (AREA)
- Mechanical Engineering (AREA)
- Chemical Kinetics & Catalysis (AREA)
- Strategic Management (AREA)
- General Chemical & Material Sciences (AREA)
- Metallurgy (AREA)
- Inorganic Chemistry (AREA)
- Theoretical Computer Science (AREA)
- Condensed Matter Physics & Semiconductors (AREA)
- Manufacturing & Machinery (AREA)
- Computer Hardware Design (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Power Engineering (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
(57)【要約】
【課題】第１に、従来よりも安全性が高い決済方法を提
供する。第２に、従来よりもコンピュータの処理量が少
ない決済方法を提供する。 【解決手段】商店は、顧客と初回の取引を行う場合に、
当該顧客の支払能力を銀行に問い合わせる。銀行は、顧
客の口座から相当額を引き出してプールしておく。プー
ルされた金額内でのみ、顧客は支払いが可能である。よ
って、銀行および商店の危険を回避することができる。
また、少額決済方式として従来提案されていたPayWord
方式よりも、本発明の方法は、署名検証の回数を削減す
ることができる。これにより、コンピュータの処理量を
減少させることができる。
供する。第２に、従来よりもコンピュータの処理量が少
ない決済方法を提供する。 【解決手段】商店は、顧客と初回の取引を行う場合に、
当該顧客の支払能力を銀行に問い合わせる。銀行は、顧
客の口座から相当額を引き出してプールしておく。プー
ルされた金額内でのみ、顧客は支払いが可能である。よ
って、銀行および商店の危険を回避することができる。
また、少額決済方式として従来提案されていたPayWord
方式よりも、本発明の方法は、署名検証の回数を削減す
ることができる。これにより、コンピュータの処理量を
減少させることができる。
Description
【０００１】
【発明の属する技術分野】本発明は、電子的な決済方法
に関するものである。
に関するものである。
【０００２】
【従来の技術】例えば特開２００１−３３８２４３公報
の０００３段落には、少額決済方式として、RivestとSh
amirが提案したPayWord方式が紹介されている。PayWord
方式が少額決済方式に適している理由は、支払い過程で
一切ディジタル署名を使わずに、その代わりとして、ハ
ッシュチェーンを利用するためである。ハッシュチェー
ンの利用によって、計算量を抑えることができ、少ない
処理量で高速に取引をすることができるようになる。ま
た、商店側は、支払い代金に値するハッシュ値を更新す
ることによって、銀行に頻繁に精算要求しなくてすみ、
通信コストを抑えることができる。以下にPayWord方式
のプロトコルを記す。
の０００３段落には、少額決済方式として、RivestとSh
amirが提案したPayWord方式が紹介されている。PayWord
方式が少額決済方式に適している理由は、支払い過程で
一切ディジタル署名を使わずに、その代わりとして、ハ
ッシュチェーンを利用するためである。ハッシュチェー
ンの利用によって、計算量を抑えることができ、少ない
処理量で高速に取引をすることができるようになる。ま
た、商店側は、支払い代金に値するハッシュ値を更新す
ることによって、銀行に頻繁に精算要求しなくてすみ、
通信コストを抑えることができる。以下にPayWord方式
のプロトコルを記す。
【０００３】以下の説明では、決済への参加者として、
Ｂ（銀行）とＣ（顧客）とＳ（商店）とを考える。ま
た、それぞれに関連する記号を以下のように定める。
Ｂ（銀行）とＣ（顧客）とＳ（商店）とを考える。ま
た、それぞれに関連する記号を以下のように定める。
【０００４】
・ＩＢ：銀行の識別子（名前，住所などを用いる）
・ＩＣ：顧客の識別子
・ＩＳ：商店の識別子
・ＰＫＢ，ＳＫＢ：Ｂの公開鍵，秘密鍵
・ＰＫＣ，ＳＫＣ：Ｃの公開鍵，秘密鍵
・｛Ｍ｝ＳＫＢ：メッセージＭに対するＢのディジタル
署名 ・｛Ｍ｝ＳＫＣ：メッセージＭに対するＣのディジタル
署名 ・ＫＢＣ：ＢとＣの共通鍵（口座開設時に秘密に共有す
る） ・ＫＢＳ：ＢとＣの共通鍵（口座開設時に秘密に共有す
る） ・ｈ：耐衝突一方向ハッシュ関数(ｙ＝ｈ（ｘ）となる
ようなｘを求めることが難しく、かつ、ｈ(ｘ)＝ｈ
(ｘ′)をみたすｘとｘ′を見つけるのが難しい関数） なお、一般に、ハッシュ関数の処理量を１としたとき、
署名の検証処理の分量は100程度、署名の生成処理の分
量は10000程度となることが知られている。
署名 ・｛Ｍ｝ＳＫＣ：メッセージＭに対するＣのディジタル
署名 ・ＫＢＣ：ＢとＣの共通鍵（口座開設時に秘密に共有す
る） ・ＫＢＳ：ＢとＣの共通鍵（口座開設時に秘密に共有す
る） ・ｈ：耐衝突一方向ハッシュ関数(ｙ＝ｈ（ｘ）となる
ようなｘを求めることが難しく、かつ、ｈ(ｘ)＝ｈ
(ｘ′)をみたすｘとｘ′を見つけるのが難しい関数） なお、一般に、ハッシュ関数の処理量を１としたとき、
署名の検証処理の分量は100程度、署名の生成処理の分
量は10000程度となることが知られている。
【０００５】（PayWord方式の概略）
1．顧客Ｃは銀行Ｂに公開鍵ＰＫＣの認証を要求する。
2．銀行Ｂは、証明書CC＝｛IB，IC，PKC｝SKB（SKBはB
によるディジタル署名）を作成する。証明書ＣＣは、顧
客Ｃの公開鍵の証認と顧客に支払能力があることとを保
証するためのものである。 3．顧客Ｃは、自らが生成した乱数ｗｎを用いて、ハッ
シュ関数のチェーンであるハッシュチェーン（各ハッシ
ュ値が小銭に相当）ｗ０，...，ｗｎを計算する。チェ
ーン長は顧客Cが決定することができる。 4．顧客Ｃは、ハッシュチェーンのコミットメントM＝
｛CC,IS,w0,n｝SKCを生成して、商店Ｓへ送信する。 5．商店Ｓは、コミットメントＭについて公開鍵ＰＫｃ
を用いることで、正当な取引相手かどうかの検証を行
う。さらに商店は、証明書ＣＣについて、公開鍵ＰＫＢ
を用いて、銀行ＢによりＰＫＣ が認証されていること
と、顧客Ｃの支払い能力が保証されていることとの検証
を行う。 6．顧客Ｃは支払い代金としてハッシュ値（wｊ，ｊ ）
を商店に送付する。この支払い前に、既に（wｉ，ｉ )
まで支払い済みであれば、（ｊ−ｉ）によって支払い代
金の額が決まる。たとえば、ハッシュチェーンの一ステ
ップが１ドルを意味する。ここで、ｉ，ｊは、ハッシュ
チェーン番号を示すインデックスである。ｉ＝０である
場合（つまり初回の支払い）は、ｊの値が支払い代金の
額を意味する。 7．商店Ｓは、 ｗｉ＝ｈ（ｗｉ＋１），ｗｉ＋１＝ｈ
（ｗｉ＋２），...，ｗｊ−１＝ｈ（ｗｊ） が成り立つかを調べることによって、前記の支払い代金
が正当かどうかの検証を行う。 8．商店Ｓは、支払代金がすべての検証に合格したら、
商品またはサービスを顧客Ｃに送る。 9．商店Ｓは、銀行Ｂに公開鍵ＰＫＣの正しさを証明書
ＣＣの正当性で確認させる。さらに、商店Ｓは、その公
開鍵ＰＫＣを用いて、顧客Ｃと商店Ｓの取引の正しさを
コミットメントＭの検証によって確認させる。その後、
商店Ｓは、支払われるべき金額に対応するハッシュ値
（ｗｋ， ｋ）を銀行に送る。ハッシュ値（ｗｋ，ｋ）
の送り方としては、商店Ｓに売上があった時にその都度
送ってもよいし、その日の顧客Ｃからの売上を合計し
て、最新のハッシュ値（ｗｋ，ｋ）を送ることによっ
て、一日分を一括して請求してもよい。10．銀行は送ら
れた証明書ＣＣとコミットメントＭとハッシュ値
（ｗｋ，ｋ）とを、Ｂのデータベースを参照して確認す
る。正当な要求であるなら、Ｃの口座からＳの口座にお
金を移送する。さらに、銀行Ｂは、顧客Ｃが使用した最
新のｗ成分を更新して管理する。
によるディジタル署名）を作成する。証明書ＣＣは、顧
客Ｃの公開鍵の証認と顧客に支払能力があることとを保
証するためのものである。 3．顧客Ｃは、自らが生成した乱数ｗｎを用いて、ハッ
シュ関数のチェーンであるハッシュチェーン（各ハッシ
ュ値が小銭に相当）ｗ０，...，ｗｎを計算する。チェ
ーン長は顧客Cが決定することができる。 4．顧客Ｃは、ハッシュチェーンのコミットメントM＝
｛CC,IS,w0,n｝SKCを生成して、商店Ｓへ送信する。 5．商店Ｓは、コミットメントＭについて公開鍵ＰＫｃ
を用いることで、正当な取引相手かどうかの検証を行
う。さらに商店は、証明書ＣＣについて、公開鍵ＰＫＢ
を用いて、銀行ＢによりＰＫＣ が認証されていること
と、顧客Ｃの支払い能力が保証されていることとの検証
を行う。 6．顧客Ｃは支払い代金としてハッシュ値（wｊ，ｊ ）
を商店に送付する。この支払い前に、既に（wｉ，ｉ )
まで支払い済みであれば、（ｊ−ｉ）によって支払い代
金の額が決まる。たとえば、ハッシュチェーンの一ステ
ップが１ドルを意味する。ここで、ｉ，ｊは、ハッシュ
チェーン番号を示すインデックスである。ｉ＝０である
場合（つまり初回の支払い）は、ｊの値が支払い代金の
額を意味する。 7．商店Ｓは、 ｗｉ＝ｈ（ｗｉ＋１），ｗｉ＋１＝ｈ
（ｗｉ＋２），...，ｗｊ−１＝ｈ（ｗｊ） が成り立つかを調べることによって、前記の支払い代金
が正当かどうかの検証を行う。 8．商店Ｓは、支払代金がすべての検証に合格したら、
商品またはサービスを顧客Ｃに送る。 9．商店Ｓは、銀行Ｂに公開鍵ＰＫＣの正しさを証明書
ＣＣの正当性で確認させる。さらに、商店Ｓは、その公
開鍵ＰＫＣを用いて、顧客Ｃと商店Ｓの取引の正しさを
コミットメントＭの検証によって確認させる。その後、
商店Ｓは、支払われるべき金額に対応するハッシュ値
（ｗｋ， ｋ）を銀行に送る。ハッシュ値（ｗｋ，ｋ）
の送り方としては、商店Ｓに売上があった時にその都度
送ってもよいし、その日の顧客Ｃからの売上を合計し
て、最新のハッシュ値（ｗｋ，ｋ）を送ることによっ
て、一日分を一括して請求してもよい。10．銀行は送ら
れた証明書ＣＣとコミットメントＭとハッシュ値
（ｗｋ，ｋ）とを、Ｂのデータベースを参照して確認す
る。正当な要求であるなら、Ｃの口座からＳの口座にお
金を移送する。さらに、銀行Ｂは、顧客Ｃが使用した最
新のｗ成分を更新して管理する。
【０００６】ここで、次のことを注記する。PayWord方
式では、初回の取引においてのみ、顧客Ｃは手順４，６
を行う。これに対して商店Ｓは手順５，７を行い、取引
が始まる。二回目以降の取引では、Ｃが最後のハッシュ
値ｗｎを公開するまで、６から１０の手順が繰り返し行
われる。
式では、初回の取引においてのみ、顧客Ｃは手順４，６
を行う。これに対して商店Ｓは手順５，７を行い、取引
が始まる。二回目以降の取引では、Ｃが最後のハッシュ
値ｗｎを公開するまで、６から１０の手順が繰り返し行
われる。
【０００７】しかしながら、PayWord方式には、つぎの
ような問題点が存在する。最初に次の用語を定義してお
く。 ●銀行にとっての安全性：支払い保証した金額より多く
の支払い義務が生じないこと ●顧客にとっての安全性：口座から引き落とされた金額
分の購入が保証されていること ●商店にとっての安全性：商品，サービスに見合った金
額が口座に振り込まれること ● システムにとっての安全性：銀行，顧客，商店から
のクレームに対して，証拠を用いて解決できること（シ
ステムへの信頼を保つこと） まず、PayWord方式（基本方式）の問題点として、証明
書が顧客の生成したハッシュチェーンを必ず銀行が買い
戻す（証明書は顧客の支払能力を完全に保証する）とい
う立場を仮定したときの問題点を述べる。
ような問題点が存在する。最初に次の用語を定義してお
く。 ●銀行にとっての安全性：支払い保証した金額より多く
の支払い義務が生じないこと ●顧客にとっての安全性：口座から引き落とされた金額
分の購入が保証されていること ●商店にとっての安全性：商品，サービスに見合った金
額が口座に振り込まれること ● システムにとっての安全性：銀行，顧客，商店から
のクレームに対して，証拠を用いて解決できること（シ
ステムへの信頼を保つこと） まず、PayWord方式（基本方式）の問題点として、証明
書が顧客の生成したハッシュチェーンを必ず銀行が買い
戻す（証明書は顧客の支払能力を完全に保証する）とい
う立場を仮定したときの問題点を述べる。
【０００８】（PayWord方式（基本方式）の問題点）銀
行Ｂの発行する証明書ＣＣは，顧客Ｃの支払い能力を銀
行Ｂが保証するというものである。ここで、銀行Ｂは、
顧客Ｃが証明書ＣＣを自らの支払い能力内で商店Ｓに提
示すると想定して証明書ＣＣを発行している。しかしな
がら、顧客Ｃが多数の商店Ｓに対して同一の証明書ＣＣ
を含んだコミットメントＭを発行することで、顧客Ｃ
は、銀行Ｂの保証する支払い能力を超えた購入が可能と
なる。以下、この問題を、「顧客Ｃによる証明書の濫用
攻撃」と呼ぶことにする。
行Ｂの発行する証明書ＣＣは，顧客Ｃの支払い能力を銀
行Ｂが保証するというものである。ここで、銀行Ｂは、
顧客Ｃが証明書ＣＣを自らの支払い能力内で商店Ｓに提
示すると想定して証明書ＣＣを発行している。しかしな
がら、顧客Ｃが多数の商店Ｓに対して同一の証明書ＣＣ
を含んだコミットメントＭを発行することで、顧客Ｃ
は、銀行Ｂの保証する支払い能力を超えた購入が可能と
なる。以下、この問題を、「顧客Ｃによる証明書の濫用
攻撃」と呼ぶことにする。
【０００９】この「顧客による証明書の濫用攻撃」は、
顧客による銀行への攻撃である。この攻撃があると、各
商店が受けた損害を銀行が補償しなければならないこと
になる。よって、この攻撃による銀行への損害は大きく
なることが想定される。つまり、銀行にとっての安全性
が大きく損なわれる。顧客と商店が結託することで、こ
の攻撃の、銀行による検出を遅らせることができる。
顧客による銀行への攻撃である。この攻撃があると、各
商店が受けた損害を銀行が補償しなければならないこと
になる。よって、この攻撃による銀行への損害は大きく
なることが想定される。つまり、銀行にとっての安全性
が大きく損なわれる。顧客と商店が結託することで、こ
の攻撃の、銀行による検出を遅らせることができる。
【００１０】（変型PayWord方式）前記した基本的なPay
Word方式では、悪意を持った顧客、もしくは何らかの手
段で顧客の秘密鍵ＳＫＣを得た不正な人間による「証明
書の濫用攻撃」により、銀行は、被害を受ける危険があ
る。
Word方式では、悪意を持った顧客、もしくは何らかの手
段で顧客の秘密鍵ＳＫＣを得た不正な人間による「証明
書の濫用攻撃」により、銀行は、被害を受ける危険があ
る。
【００１１】この危険は、一度発行された証明書に基づ
いて、顧客が多数の商店に対して取引できたことにより
起こる。
いて、顧客が多数の商店に対して取引できたことにより
起こる。
【００１２】そこで、RivestとShamirによれば、証明書
の効力に対し、次のような制限を設けることが提案され
ている。 （i）顧客がある1つの商店に対し1日で使える限度額に
制限を設ける。 （ii）顧客が全取引先に対し1日で使える（合計）限度
額を設ける。 （iii）銀行により毎日発行される“hot list"（秘密鍵
をなくした顧客、秘密鍵が漏れた顧客、および過去に不
正な取引を行った顧客のリスト）にある顧客の証明書は
無効とする。
の効力に対し、次のような制限を設けることが提案され
ている。 （i）顧客がある1つの商店に対し1日で使える限度額に
制限を設ける。 （ii）顧客が全取引先に対し1日で使える（合計）限度
額を設ける。 （iii）銀行により毎日発行される“hot list"（秘密鍵
をなくした顧客、秘密鍵が漏れた顧客、および過去に不
正な取引を行った顧客のリスト）にある顧客の証明書は
無効とする。
【００１３】さらに、各商店と銀行との間で、「その顧
客の証明書が“hot list”に無いことを商店が確認し、
(i)の限度額内で取引をする」ことを取り決めておく。
この取り決めに反した取引による損害は商店側の負担と
する。
客の証明書が“hot list”に無いことを商店が確認し、
(i)の限度額内で取引をする」ことを取り決めておく。
この取り決めに反した取引による損害は商店側の負担と
する。
【００１４】この制限により、前記した問題点に示した
銀行の被害をある程度抑えることができる。まず、制限
(i)により、１つの商店に対する多額の取引が制限され
る。また、制限(ii)により、銀行は、限度額以上の被害
を商店に共有させることができ、自らの損害を減少させ
ることができる。
銀行の被害をある程度抑えることができる。まず、制限
(i)により、１つの商店に対する多額の取引が制限され
る。また、制限(ii)により、銀行は、限度額以上の被害
を商店に共有させることができ、自らの損害を減少させ
ることができる。
【００１５】（変型PayWord方式の問題点１）しかしな
がら、前記した「制限」は「顧客の証明書の濫用攻撃」
が検出されるのに一日の時間の遅れがあるために、この
攻撃に対する本質的な解決法にはなっていない。証明書
の有効性に対して上記の制約を設けることで、顧客と商
店の結託攻撃が抑制されることは事実だが、顧客と商店
による結託攻撃は、銀行から限度額までの金額をだまし
取れるので依然として有効である。
がら、前記した「制限」は「顧客の証明書の濫用攻撃」
が検出されるのに一日の時間の遅れがあるために、この
攻撃に対する本質的な解決法にはなっていない。証明書
の有効性に対して上記の制約を設けることで、顧客と商
店の結託攻撃が抑制されることは事実だが、顧客と商店
による結託攻撃は、銀行から限度額までの金額をだまし
取れるので依然として有効である。
【００１６】なお、この攻撃は、顧客の単独行為による
場合には、「銀行、および（限度額を超えた場合には）
商店に対する攻撃」となり、顧客と商店との共同行為に
よる場合には、「銀行に対する攻撃」となる。
場合には、「銀行、および（限度額を超えた場合には）
商店に対する攻撃」となり、顧客と商店との共同行為に
よる場合には、「銀行に対する攻撃」となる。
【００１７】（変型PayWord方式の問題点２）変型PayWo
rd方式では、証明書に「制限」をつけて、問題発生時に
商店にも負担を強いることにしたために、次の問題点が
新たに考えられる。
rd方式では、証明書に「制限」をつけて、問題発生時に
商店にも負担を強いることにしたために、次の問題点が
新たに考えられる。
【００１８】銀行は顧客の公開鍵の認証とその顧客の支
払い能力の保証を証明書ＣＣによって行っている。これ
より、銀行は実在しない顧客Ｃ′を新たに生成して、証
明書Ｃｃを用いて「なりすまし」が可能となる。PayWor
d方式では「顧客による証明書の濫用」が可能なので、
銀行は商店からの精算要求時に、「顧客（Ｃ′）による
証明書の濫用」が発生したと主張して、自らの「なりす
まし」を言い逃れることができる。
払い能力の保証を証明書ＣＣによって行っている。これ
より、銀行は実在しない顧客Ｃ′を新たに生成して、証
明書Ｃｃを用いて「なりすまし」が可能となる。PayWor
d方式では「顧客による証明書の濫用」が可能なので、
銀行は商店からの精算要求時に、「顧客（Ｃ′）による
証明書の濫用」が発生したと主張して、自らの「なりす
まし」を言い逃れることができる。
【００１９】銀行が「顧客の支払い能力を完全に保証す
る」場合には、上記の攻撃には銀行にはメリットがな
い。しかしながら、問題発生時に商店にも負担を強いる
対策をとると、この攻撃は銀行にメリットが生じるよう
になる。以下、この攻撃を「銀行によるなりすまし攻
撃」とよぶことにする。この攻撃は、銀行による商店へ
の攻撃である。なお、ここでは、顧客の公開鍵を使用す
るので、実在する顧客への攻撃にはならない。
る」場合には、上記の攻撃には銀行にはメリットがな
い。しかしながら、問題発生時に商店にも負担を強いる
対策をとると、この攻撃は銀行にメリットが生じるよう
になる。以下、この攻撃を「銀行によるなりすまし攻
撃」とよぶことにする。この攻撃は、銀行による商店へ
の攻撃である。なお、ここでは、顧客の公開鍵を使用す
るので、実在する顧客への攻撃にはならない。
【００２０】（PayWord方式の問題点のまとめ）以上を
まとめると、PayWord方式における、保証した証明書に
対する銀行の態度には、次の二つがある。 1．立場1：銀行が保証した証明書については必ず責任を
取る 2．立場２：銀行の責任を制限する 前記から明らかなように、立場１，２のどちらを取った
としても、すべての問題が同時に解決されることはな
い。変形PayWord方式では、基本方式の問題点に対して
は攻撃が抑制されるものの、完全な解決策にはなってお
らず、さらに、銀行の責任を弱めたために新たな問題点
が生じてしまう。
まとめると、PayWord方式における、保証した証明書に
対する銀行の態度には、次の二つがある。 1．立場1：銀行が保証した証明書については必ず責任を
取る 2．立場２：銀行の責任を制限する 前記から明らかなように、立場１，２のどちらを取った
としても、すべての問題が同時に解決されることはな
い。変形PayWord方式では、基本方式の問題点に対して
は攻撃が抑制されるものの、完全な解決策にはなってお
らず、さらに、銀行の責任を弱めたために新たな問題点
が生じてしまう。
【００２１】（PayWord方式の処理効率の問題点）ま
た、PayWord方式では ●銀行による証明書の作成で署名生成を1回 ●顧客による証明書の検証で署名検証を1回 ●顧客によるコミットメントＭの作成で署名生成を1回 ●商店による，証明書とコミットメントＭの検証で署名
検証を計2回 ●銀行によるコミットメントＭの検証で署名検証を1回 を実行することになる。公開鍵暗号による署名の生成処
理、検証処理は処理量が多いので、実行回数は削減する
ことが望ましい。ハッシュ関数の処理量を1としたと
き、署名検証の処理量は100程度、署名生成の処理量は1
0000程度となることが知られている。
た、PayWord方式では ●銀行による証明書の作成で署名生成を1回 ●顧客による証明書の検証で署名検証を1回 ●顧客によるコミットメントＭの作成で署名生成を1回 ●商店による，証明書とコミットメントＭの検証で署名
検証を計2回 ●銀行によるコミットメントＭの検証で署名検証を1回 を実行することになる。公開鍵暗号による署名の生成処
理、検証処理は処理量が多いので、実行回数は削減する
ことが望ましい。ハッシュ関数の処理量を1としたと
き、署名検証の処理量は100程度、署名生成の処理量は1
0000程度となることが知られている。
【００２２】
【発明が解決しようとする課題】本発明は、前記の事情
に鑑みてなされたものである。本発明の第１の目的は、
従来よりも安全性が高い決済方法を提供することであ
る。本発明の第２の目的は、従来よりもコンピュータの
処理量が少ない決済方法を提供することである。
に鑑みてなされたものである。本発明の第１の目的は、
従来よりも安全性が高い決済方法を提供することであ
る。本発明の第２の目的は、従来よりもコンピュータの
処理量が少ない決済方法を提供することである。
【００２３】
【課題を解決するための手段】請求項１記載の電子的決
済方法は、コンピュータを用いて、下記のステップを行
う構成となっている。 （１）次の情報（Ｍ）を、顧客から商店に、顧客の秘密
鍵によるディジタル署名を付して送付するステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記のディジタル署名が行われた前記ハッシュチ
ェーンの長さと前記顧客識別子と前記商店識別子とを示
す情報を前記商店から銀行に送付するステップ； （３）前記顧客の秘密鍵に対応する公開鍵を用いて顧客
の認証を行った後、前記ハッシュチェーンの長さに応じ
た金額を、前記顧客の口座から引き落とすステップ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、銀行の秘密鍵でディジタル署名して前記
商店に送付するステップ； （５）前記銀行の秘密鍵に対応する公開鍵を用いて、前
記ステップ（４）における証明を商店が検証するステッ
プ； （６）前記顧客から、支払代金として、前記ハッシュチ
ェーンのある段階におけるハッシュ値と前記段階とを示
す情報（ｗｊ，ｊ）を前記商店に送付するステップ； （７）前記ステップ（６）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記銀行に送付するステッ
プ； （８）前記ステップ（７）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。
済方法は、コンピュータを用いて、下記のステップを行
う構成となっている。 （１）次の情報（Ｍ）を、顧客から商店に、顧客の秘密
鍵によるディジタル署名を付して送付するステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記のディジタル署名が行われた前記ハッシュチ
ェーンの長さと前記顧客識別子と前記商店識別子とを示
す情報を前記商店から銀行に送付するステップ； （３）前記顧客の秘密鍵に対応する公開鍵を用いて顧客
の認証を行った後、前記ハッシュチェーンの長さに応じ
た金額を、前記顧客の口座から引き落とすステップ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、銀行の秘密鍵でディジタル署名して前記
商店に送付するステップ； （５）前記銀行の秘密鍵に対応する公開鍵を用いて、前
記ステップ（４）における証明を商店が検証するステッ
プ； （６）前記顧客から、支払代金として、前記ハッシュチ
ェーンのある段階におけるハッシュ値と前記段階とを示
す情報（ｗｊ，ｊ）を前記商店に送付するステップ； （７）前記ステップ（６）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記銀行に送付するステッ
プ； （８）前記ステップ（７）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。
【００２４】請求項２記載の電子的決済方法は、コンピ
ュータを用いて、下記のステップを行う構成となってい
る。 （１）ハッシュチェーンの長さ（ｎ）と顧客識別子（Ｉ
Ｃ）と商店識別子（ＩＳ）とを、商店から銀行が受け取
るステップ； （２）前記顧客の認証を行った後、前記ハッシュチェー
ンの長さに応じた金額を、前記顧客の口座から銀行が引
き落とすステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に銀行が送付するステップ； （４）前記ハッシュチェーンのある段階におけるハッシ
ュ値とその段階とを示す情報（ｗｊ，ｊ）、および、前
記商店と前記顧客とを示す情報（ＩＳ，ＩＣ）を前記商
店から銀行が受け取るステップ； （５）前記ステップ（４）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。
ュータを用いて、下記のステップを行う構成となってい
る。 （１）ハッシュチェーンの長さ（ｎ）と顧客識別子（Ｉ
Ｃ）と商店識別子（ＩＳ）とを、商店から銀行が受け取
るステップ； （２）前記顧客の認証を行った後、前記ハッシュチェー
ンの長さに応じた金額を、前記顧客の口座から銀行が引
き落とすステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に銀行が送付するステップ； （４）前記ハッシュチェーンのある段階におけるハッシ
ュ値とその段階とを示す情報（ｗｊ，ｊ）、および、前
記商店と前記顧客とを示す情報（ＩＳ，ＩＣ）を前記商
店から銀行が受け取るステップ； （５）前記ステップ（４）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。
【００２５】請求項３記載の電子的決済方法は、コンピ
ュータを用いて、下記のステップを行う構成となってい
る。 （１）次の情報を、顧客から商店が受け取るステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記ハッシュチェーンの長さと前記顧客識別子と
前記商店識別子とを示す情報を前記商店から銀行に送付
するステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、前記銀行から前記商店が受け取るステッ
プ； （４）前記顧客から、支払代金として、前記ハッシュチ
ェーンの任意の段階におけるハッシュ値と前記段階とを
示す情報（ｗｊ，ｊ）を前記商店が受け取るステップ； （５）前記ステップ（４）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記商店から前記銀行に送付
するステップ； （６）前記ステップ（５）における各情報を受け取った
銀行から、前記支払代金に対応する金額を前記商店の口
座に受け入れるステップ。
ュータを用いて、下記のステップを行う構成となってい
る。 （１）次の情報を、顧客から商店が受け取るステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記ハッシュチェーンの長さと前記顧客識別子と
前記商店識別子とを示す情報を前記商店から銀行に送付
するステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、前記銀行から前記商店が受け取るステッ
プ； （４）前記顧客から、支払代金として、前記ハッシュチ
ェーンの任意の段階におけるハッシュ値と前記段階とを
示す情報（ｗｊ，ｊ）を前記商店が受け取るステップ； （５）前記ステップ（４）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記商店から前記銀行に送付
するステップ； （６）前記ステップ（５）における各情報を受け取った
銀行から、前記支払代金に対応する金額を前記商店の口
座に受け入れるステップ。
【００２６】請求項４記載の支払い証明方法は、コンピ
ュータを用いて、下記のステップを行う構成となってい
る。 （１）次の情報（Ｍ）を、顧客から商店に送付するステ
ップ； 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記顧客識別子と前記商店識別子とを示す情報を
前記商店から銀行に送付するステップ； （３）前記顧客から前記商店に支払い可能となる金額
を、前記顧客の口座から前記銀行が引き落とすステッ
プ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に送付するステップ。
ュータを用いて、下記のステップを行う構成となってい
る。 （１）次の情報（Ｍ）を、顧客から商店に送付するステ
ップ； 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記顧客識別子と前記商店識別子とを示す情報を
前記商店から銀行に送付するステップ； （３）前記顧客から前記商店に支払い可能となる金額
を、前記顧客の口座から前記銀行が引き落とすステッ
プ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に送付するステップ。
【００２７】
【発明の実施の形態】本発明の実施形態に係る電子的決
済方法を、添付の図面を参照しながら説明する。まず、
図１に基づいて、この決済方法の概略を説明する。この
決済方法は、顧客Ｃと銀行Ｂと商店Ｓとの、三者間での
取引の決済に用いられるものである。顧客Ｃは、この明
細書では、商店Ｓに何らかの金銭的な支払いをなす者で
ある。銀行Ｂは、顧客Ｃから商店Ｓへの金銭的支払いを
仲介する機関である。商店Ｓは、顧客Ｃからの支払いを
受ける者である。これらの関与者は、自然人でも法人で
も人格なき機関または団体でもよい。また、以下におけ
る動作は、特に注記しないかぎり、コンピュータによっ
て行われる。ここで、例えば、顧客Ｃのコンピュータと
称したときは、顧客Ｃにより利用できるコンピュータを
意味し、その所有に係るものであるか否かを問わない。
コンピュータの所在も限定されない。さらに、分散配置
された複数のコンピュータにより機能が実現されてもよ
く、また、一つのコンピュータによって仮想的に複数の
コンピュータの機能が実現されていてもよい。また、こ
の実施形態は、サーバを用いたクライアント−サーバシ
ステムで構築しても、ピアトゥーピアのシステムで構築
してもよい。
済方法を、添付の図面を参照しながら説明する。まず、
図１に基づいて、この決済方法の概略を説明する。この
決済方法は、顧客Ｃと銀行Ｂと商店Ｓとの、三者間での
取引の決済に用いられるものである。顧客Ｃは、この明
細書では、商店Ｓに何らかの金銭的な支払いをなす者で
ある。銀行Ｂは、顧客Ｃから商店Ｓへの金銭的支払いを
仲介する機関である。商店Ｓは、顧客Ｃからの支払いを
受ける者である。これらの関与者は、自然人でも法人で
も人格なき機関または団体でもよい。また、以下におけ
る動作は、特に注記しないかぎり、コンピュータによっ
て行われる。ここで、例えば、顧客Ｃのコンピュータと
称したときは、顧客Ｃにより利用できるコンピュータを
意味し、その所有に係るものであるか否かを問わない。
コンピュータの所在も限定されない。さらに、分散配置
された複数のコンピュータにより機能が実現されてもよ
く、また、一つのコンピュータによって仮想的に複数の
コンピュータの機能が実現されていてもよい。また、こ
の実施形態は、サーバを用いたクライアント−サーバシ
ステムで構築しても、ピアトゥーピアのシステムで構築
してもよい。
【００２８】つぎに、図２に基づいて、本実施形態に係
る電子的決済方法を詳細に説明する。
る電子的決済方法を詳細に説明する。
【００２９】（ステップ１）まず、この決済方法の利用
を望む顧客Ｃは、口座開設の要求を銀行Ｂに送る。この
作業は、コンピュータによって行ってもよく、また、コ
ンピュータを介さずに人為的に行ってもよい。
を望む顧客Ｃは、口座開設の要求を銀行Ｂに送る。この
作業は、コンピュータによって行ってもよく、また、コ
ンピュータを介さずに人為的に行ってもよい。
【００３０】（ステップ２）口座開設の要求を受け取っ
た銀行Ｂは、顧客Ｃのための口座を開設する。この口座
には、顧客Ｃのために利用可能な金額が、後述するステ
ップ５の実行の前またはそれと同時に入金される。これ
らの作業も、コンピュータによって行っても、コンピュ
ータを介さずに人為的に行ってもよい。
た銀行Ｂは、顧客Ｃのための口座を開設する。この口座
には、顧客Ｃのために利用可能な金額が、後述するステ
ップ５の実行の前またはそれと同時に入金される。これ
らの作業も、コンピュータによって行っても、コンピュ
ータを介さずに人為的に行ってもよい。
【００３１】（ステップ３）口座を開設した銀行Ｂは、
その旨を顧客Ｃに通知する。この作業も、コンピュータ
によって行っても、コンピュータを介さずに人為的に行
ってもよい。
その旨を顧客Ｃに通知する。この作業も、コンピュータ
によって行っても、コンピュータを介さずに人為的に行
ってもよい。
【００３２】（ステップ４）顧客Ｃ（具体的にはそのコ
ンピュータ）は、乱数ｗｎを生成し、この乱数ｗｎに対
するハッシュチェーンを計算する。ハッシュチェーン
は、ハッシュ関数をｈとして、次のように表せる。
ンピュータ）は、乱数ｗｎを生成し、この乱数ｗｎに対
するハッシュチェーンを計算する。ハッシュチェーン
は、ハッシュ関数をｈとして、次のように表せる。
【００３３】ここで、チェーン長ｎは一般には顧客Ｃが
決定する。支払代金の額は、通常は、次のように決め
る。ハッシュ値ｗ０...ｗｉ...ｗｊ...ｗｎにおいて、
第ｉ番目までのｗｉが顧客Ｃから既に公開（送付）され
ていたときは、その後に第ｊ番目のｗｊが公開される
と、その差分（ｊ−ｉ）の値によって、支払代金の額が
決まる。ここで、ハッシュチェーンの１ステップが所定
の金額（例えば１ドル）を意味している。また、ｉ，ｊ
は、ハッシュチェーン番号を示すインデックス（ハッシ
ュチェーンの段階を示す情報に相当する。）である。し
たがって、チェーン長ｎは、いくらの金額を支払い可能
とするかという情報になる。また、本実施形態の方法に
おいて用いられるハッシュ関数ｈは、システム設計時
に、予め設定しておけばよい。もちろん、ハッシュ関数
ｈは、例えば、前記ステップ３において、顧客Ｃ毎に、
銀行Ｂから通知してもよい。
決定する。支払代金の額は、通常は、次のように決め
る。ハッシュ値ｗ０...ｗｉ...ｗｊ...ｗｎにおいて、
第ｉ番目までのｗｉが顧客Ｃから既に公開（送付）され
ていたときは、その後に第ｊ番目のｗｊが公開される
と、その差分（ｊ−ｉ）の値によって、支払代金の額が
決まる。ここで、ハッシュチェーンの１ステップが所定
の金額（例えば１ドル）を意味している。また、ｉ，ｊ
は、ハッシュチェーン番号を示すインデックス（ハッシ
ュチェーンの段階を示す情報に相当する。）である。し
たがって、チェーン長ｎは、いくらの金額を支払い可能
とするかという情報になる。また、本実施形態の方法に
おいて用いられるハッシュ関数ｈは、システム設計時
に、予め設定しておけばよい。もちろん、ハッシュ関数
ｈは、例えば、前記ステップ３において、顧客Ｃ毎に、
銀行Ｂから通知してもよい。
【００３４】（ステップ５）つぎに、顧客Ｃは、ハッシ
ュチェーンのコミットメントM＝{Ic,IS,w0,n｝SKCを生
成して、商店Ｓ（具体的にはそのコンピュータ）へ送信
する．ここで、 ｎ：ハッシュチェーンの長さ、 ｗ０：ある数に長さｎのハッシュチェーンを適用した後
の値、 ＩＳ：商店識別子、 ＩＣ：顧客識別子、 ＳＫＣ：顧客の秘密鍵、 である。
ュチェーンのコミットメントM＝{Ic,IS,w0,n｝SKCを生
成して、商店Ｓ（具体的にはそのコンピュータ）へ送信
する．ここで、 ｎ：ハッシュチェーンの長さ、 ｗ０：ある数に長さｎのハッシュチェーンを適用した後
の値、 ＩＳ：商店識別子、 ＩＣ：顧客識別子、 ＳＫＣ：顧客の秘密鍵、 である。
【００３５】また、{Ic,IS,w0,n｝SKCは、｛｝内の情報
が鍵（この例では顧客の秘密鍵）でディジタル署名され
ていることを意味する。ただし、これらの情報すべてに
ディジタル署名を付していなくてもよい。
が鍵（この例では顧客の秘密鍵）でディジタル署名され
ていることを意味する。ただし、これらの情報すべてに
ディジタル署名を付していなくてもよい。
【００３６】（ステップ６）顧客Ｃからコミットメント
Ｍを受け取った商店Ｓは、銀行Ｂ（具体的にはそのコン
ピュータ）に、コミットメントＭを送付する。これによ
り、商店Ｓは、ディジタル署名が行われたハッシュチェ
ーンの長さと顧客識別子と商店識別子とを銀行に送付す
ることになる。これは、銀行に対して、顧客Ｃから商店
Ｓへの支払い能力を問い合わせる意味を有する。
Ｍを受け取った商店Ｓは、銀行Ｂ（具体的にはそのコン
ピュータ）に、コミットメントＭを送付する。これによ
り、商店Ｓは、ディジタル署名が行われたハッシュチェ
ーンの長さと顧客識別子と商店識別子とを銀行に送付す
ることになる。これは、銀行に対して、顧客Ｃから商店
Ｓへの支払い能力を問い合わせる意味を有する。
【００３７】（ステップ７）銀行Ｂは、顧客Ｃの秘密鍵
ＳＫＣに対応する公開鍵を用いて、顧客Ｃの認証を行
う。その後、コミットメントＭに含まれるハッシュチェ
ーンの長さｎに応じた金額を、顧客Ｃの口座から引き落
とす。
ＳＫＣに対応する公開鍵を用いて、顧客Ｃの認証を行
う。その後、コミットメントＭに含まれるハッシュチェ
ーンの長さｎに応じた金額を、顧客Ｃの口座から引き落
とす。
【００３８】（ステップ８）ついで、銀行Ｂは、顧客Ｃ
から商店Ｓへの支払い能力を銀行Ｂが保証する証明書Ｃ
Ｃを、銀行Ｂの秘密鍵ＳＫＢでディジタル署名して商店
Ｓに送付する。証明書ＣＣはCC＝{IC，M，YES｝SKBと表
せる。ここで、ＣＣの要素にＹＥＳがあるということ
は、銀行が保証する旨を意味する。
から商店Ｓへの支払い能力を銀行Ｂが保証する証明書Ｃ
Ｃを、銀行Ｂの秘密鍵ＳＫＢでディジタル署名して商店
Ｓに送付する。証明書ＣＣはCC＝{IC，M，YES｝SKBと表
せる。ここで、ＣＣの要素にＹＥＳがあるということ
は、銀行が保証する旨を意味する。
【００３９】（ステップ９）ついで、商店Ｓは、銀行Ｂ
の秘密鍵ＳＫＢに対応する公開鍵ＰＫＢを用いて、ステ
ップ８における証明書ＣＣを検証する。これにより、商
店Ｓは、顧客Ｃから商店Ｓへの支払いが銀行Ｂにより保
証されていることを確認することができる。
の秘密鍵ＳＫＢに対応する公開鍵ＰＫＢを用いて、ステ
ップ８における証明書ＣＣを検証する。これにより、商
店Ｓは、顧客Ｃから商店Ｓへの支払いが銀行Ｂにより保
証されていることを確認することができる。
【００４０】（ステップ１０）ついで、顧客Ｃは、支払
代金として、ハッシュチェーンの任意の段階におけるハ
ッシュ値（ｗｊ，ｊ）を商店Ｓに公開（送付）する。既
にハッシュ値（ｗｉ，ｉ）まで公開されていた場合に
は、ハッシュ値（ｗｊ）は、ハッシュ値（ｗｉ）よりも
ｗｎ側の値である。つまり、支払いは、ｗ０からｗｎに
向かって使用することになる。
代金として、ハッシュチェーンの任意の段階におけるハ
ッシュ値（ｗｊ，ｊ）を商店Ｓに公開（送付）する。既
にハッシュ値（ｗｉ，ｉ）まで公開されていた場合に
は、ハッシュ値（ｗｊ）は、ハッシュ値（ｗｉ）よりも
ｗｎ側の値である。つまり、支払いは、ｗ０からｗｎに
向かって使用することになる。
【００４１】（ステップ１１）商店Ｓは、送付されたハ
ッシュ値（ｗｊ，ｊ）を用いて、ｗｊ−１＝ｈ（ｗｊ）
が成り立つかを調べる。商店Ｓは、ハッシュ関数ｈおよ
び乱数ｗ０の情報を有しているため、この検証が可能で
ある。例えば、この検証により、商店Ｓは、顧客Ｃによ
る支払いが正当なものかどうかを検証することができ
る。ここで、検証としては、ｗｉ＝ｈ（ｈ・・・（ｈ（ｗ
ｊ））・・・）が成り立つかどうか、つまり、第ｊ番目か
ら第ｉ番目までのハッシュチェーンが成立するかどうか
により検証することも可能である。
ッシュ値（ｗｊ，ｊ）を用いて、ｗｊ−１＝ｈ（ｗｊ）
が成り立つかを調べる。商店Ｓは、ハッシュ関数ｈおよ
び乱数ｗ０の情報を有しているため、この検証が可能で
ある。例えば、この検証により、商店Ｓは、顧客Ｃによ
る支払いが正当なものかどうかを検証することができ
る。ここで、検証としては、ｗｉ＝ｈ（ｈ・・・（ｈ（ｗ
ｊ））・・・）が成り立つかどうか、つまり、第ｊ番目か
ら第ｉ番目までのハッシュチェーンが成立するかどうか
により検証することも可能である。
【００４２】（ステップ１２）その後、商店Ｓは、商品
またはサービスを顧客Ｃに送る。この作業は、コンピュ
ータにより電子的に行われてもよいし、実際に商品やサ
ービスを顧客に人手で届けるというものであってもよ
い。電子的な送付に適する商品としては、例えば音楽や
映像やコンピュータソフトウエアなどのディジタルコン
テンツである。
またはサービスを顧客Ｃに送る。この作業は、コンピュ
ータにより電子的に行われてもよいし、実際に商品やサ
ービスを顧客に人手で届けるというものであってもよ
い。電子的な送付に適する商品としては、例えば音楽や
映像やコンピュータソフトウエアなどのディジタルコン
テンツである。
【００４３】（ステップ１３）商店Ｓは、顧客Ｃから受
け取るべき金額に対応するハッシュ値（ｗｋ，ｋ）を銀
行に送る。その日の顧客Ｃからの売上を、最新のハッシ
ュ値（ｗｋ，ｋ）を送ることで一括して請求してもよ
い。ここで、商店Ｓは、証明書ＣＣおよび／または商店
識別子ＩＳと顧客識別子ＩＣとを銀行Ｂに送る。
け取るべき金額に対応するハッシュ値（ｗｋ，ｋ）を銀
行に送る。その日の顧客Ｃからの売上を、最新のハッシ
ュ値（ｗｋ，ｋ）を送ることで一括して請求してもよ
い。ここで、商店Ｓは、証明書ＣＣおよび／または商店
識別子ＩＳと顧客識別子ＩＣとを銀行Ｂに送る。
【００４４】（ステップ１４）ステップ１３における各
情報を受け取った銀行は、まず、商店Ｓから送られたハ
ッシュ値（ｗｋ，ｋ）を、銀行Ｂのコンピュータで利用
可能なデータベースに記録されたハッシュ値と比較して
検証する。つまり、後述するように、銀行Ｂは既に使用
された段階までのハッシュ値を保存しているので、新た
に送られたハッシュ値（ｗｋ，ｋ）からのハッシュ関数
を計算して、保存しているハッシュ値に至れば、検証さ
れたものとできる。もちろん、既に使用されたハッシュ
値を保存していなくともよく、その場合は、ハッシュ値
（ｗｋ，ｋ）からのハッシュ関数を計算して最終的にｗ
０になれば、検証されたこととできる。この検証に合格
すれば、正当な請求であるものとする。なお、ここで、
ｋはハッシュチェーンのインデックスであり、ｋ＝ｊで
あってもよい。一般には、顧客が支払いに使用したステ
ップ数の合計がｋとなるので、ｋ≠ｊである。そこで、
この明細書では、混同を防ぐため、添え字としてｋを用
いた。検証に用いるハッシュチェーンは、商店Ｓおよび
顧客Ｃのためのものを使用する。ハッシュチェーンの特
定のために、ステップ１３で送られた商店識別子ＩＳや
顧客識別子ＩＣを利用することができる。商店Ｓからの
請求が検証に合格した場合は、前記ステップ７において
引き落としておいた金額から、請求額に相当する金額
を、商店Ｓの口座に移す（この作業はコンピュータによ
っても人手によってもよい）。ついで、銀行Ｂは、顧客
Ｃの使用した最新のｗ成分をデータベース上で更新して
管理する。これは、銀行Ｂから商店Ｓに支払える残高を
管理するためである。このように更新して管理すれば、
銀行Ｂにおけるデータの保存領域の増加量が少ないとい
う利点がある。
情報を受け取った銀行は、まず、商店Ｓから送られたハ
ッシュ値（ｗｋ，ｋ）を、銀行Ｂのコンピュータで利用
可能なデータベースに記録されたハッシュ値と比較して
検証する。つまり、後述するように、銀行Ｂは既に使用
された段階までのハッシュ値を保存しているので、新た
に送られたハッシュ値（ｗｋ，ｋ）からのハッシュ関数
を計算して、保存しているハッシュ値に至れば、検証さ
れたものとできる。もちろん、既に使用されたハッシュ
値を保存していなくともよく、その場合は、ハッシュ値
（ｗｋ，ｋ）からのハッシュ関数を計算して最終的にｗ
０になれば、検証されたこととできる。この検証に合格
すれば、正当な請求であるものとする。なお、ここで、
ｋはハッシュチェーンのインデックスであり、ｋ＝ｊで
あってもよい。一般には、顧客が支払いに使用したステ
ップ数の合計がｋとなるので、ｋ≠ｊである。そこで、
この明細書では、混同を防ぐため、添え字としてｋを用
いた。検証に用いるハッシュチェーンは、商店Ｓおよび
顧客Ｃのためのものを使用する。ハッシュチェーンの特
定のために、ステップ１３で送られた商店識別子ＩＳや
顧客識別子ＩＣを利用することができる。商店Ｓからの
請求が検証に合格した場合は、前記ステップ７において
引き落としておいた金額から、請求額に相当する金額
を、商店Ｓの口座に移す（この作業はコンピュータによ
っても人手によってもよい）。ついで、銀行Ｂは、顧客
Ｃの使用した最新のｗ成分をデータベース上で更新して
管理する。これは、銀行Ｂから商店Ｓに支払える残高を
管理するためである。このように更新して管理すれば、
銀行Ｂにおけるデータの保存領域の増加量が少ないとい
う利点がある。
【００４５】なお、前記において、ステップ５〜９は
「当該顧客と商店との初回取引のみ」において行われる
ものである。そして、二回目以降の取引では顧客Ｃが最
後のハッシュ値ｗｎを公開するまで、ステップ１０から
１４が繰り返し行われる。
「当該顧客と商店との初回取引のみ」において行われる
ものである。そして、二回目以降の取引では顧客Ｃが最
後のハッシュ値ｗｎを公開するまで、ステップ１０から
１４が繰り返し行われる。
【００４６】本実施形態の決済方法では、商店は顧客と
初回の取引を行う場合に、当該顧客の支払能力を銀行に
問い合わせる（ステップ６、８に相当）。この処理によ
って、銀行は取引の逐次管理が可能になる。顧客が同一
の証明書ＣＣを複数の商店で使用して起こる「顧客によ
る証明書の濫用攻撃」は、これによって防止することが
できる。
初回の取引を行う場合に、当該顧客の支払能力を銀行に
問い合わせる（ステップ６、８に相当）。この処理によ
って、銀行は取引の逐次管理が可能になる。顧客が同一
の証明書ＣＣを複数の商店で使用して起こる「顧客によ
る証明書の濫用攻撃」は、これによって防止することが
できる。
【００４７】精算時に商店と銀行の間でトラブルが生じ
た場合には、商店は、銀行の発行した「顧客の支払い能
力の証明書」を根拠に、銀行Ｂに対して支払いの保証を
求める。このため、銀行Ｂは、証明書ＣＣの発行前に、
顧客の口座から額面ｎに対応する金額を引き落としてプ
ールしている（ステップ７）。すなわち、前払い方式を
採用している。これによって、銀行Ｂは、商店に対して
顧客の支払い能力を完全に保証できることとなる。
た場合には、商店は、銀行の発行した「顧客の支払い能
力の証明書」を根拠に、銀行Ｂに対して支払いの保証を
求める。このため、銀行Ｂは、証明書ＣＣの発行前に、
顧客の口座から額面ｎに対応する金額を引き落としてプ
ールしている（ステップ７）。すなわち、前払い方式を
採用している。これによって、銀行Ｂは、商店に対して
顧客の支払い能力を完全に保証できることとなる。
【００４８】また、変形PayWord方式では、銀行の責任
を制限したために、「銀行によるなりすまし攻撃」が成
立する危険があった。しかしながら、本実施形態の方法
では、「銀行は、保証した支払いについて必ず責任を取
る」という立場を採用しているため、銀行にとって「な
りすまし」攻撃を行う意味はない。したがって、このよ
うな攻撃は回避できる。
を制限したために、「銀行によるなりすまし攻撃」が成
立する危険があった。しかしながら、本実施形態の方法
では、「銀行は、保証した支払いについて必ず責任を取
る」という立場を採用しているため、銀行にとって「な
りすまし」攻撃を行う意味はない。したがって、このよ
うな攻撃は回避できる。
【００４９】顧客によるコミットメントＭの作成におい
てディジタル署名を付した理由は、「前払い方式」を採
用したためである。すなわち、銀行が顧客の口座から前
払い金を引き落とす際に、コミットメントＭを、引き落
とし合意の証拠とするためである。もし、顧客と銀行間
で、ディジタル認証を用いずに、メッセージ認証（ＭＡ
Ｃ）を用いるとすると、銀行と顧客の利害が対立する場
合には、銀行も証拠を生成可能なので、「顧客による引
き落とし合意」の証拠とならない。
てディジタル署名を付した理由は、「前払い方式」を採
用したためである。すなわち、銀行が顧客の口座から前
払い金を引き落とす際に、コミットメントＭを、引き落
とし合意の証拠とするためである。もし、顧客と銀行間
で、ディジタル認証を用いずに、メッセージ認証（ＭＡ
Ｃ）を用いるとすると、銀行と顧客の利害が対立する場
合には、銀行も証拠を生成可能なので、「顧客による引
き落とし合意」の証拠とならない。
【００５０】また、銀行による証明書ＣＣにディジタル
署名を付した理由は、精算時にトラブルが生じた場合
に、証明書ＣＣに対する第三者による検証を可能とする
ためである。ここでも、ディジタル署名に代えてＭＡＣ
を用いると、第三者による検証が行えないことになる。
署名を付した理由は、精算時にトラブルが生じた場合
に、証明書ＣＣに対する第三者による検証を可能とする
ためである。ここでも、ディジタル署名に代えてＭＡＣ
を用いると、第三者による検証が行えないことになる。
【００５１】また、従来技術として説明したPayWord方
式では、前記したように、システム全体で、ディジタル
署名の生成を2回、検証を４回行う必要があった。これ
に対して、本実施形態の方法では ・顧客によるコミットメントＭの作成で署名生成を1
回、 ・銀行によるコミットメントＭの検証で署名検証を1
回、 ・銀行による証明書の作成で署名生成を1回、 ・商店による証明書の検証で署名検証を1回、 実行することになる。したがって、本実施形態の方法
は、PayWord方式に比べて署名検証の回数が２回削減さ
れている。これは、銀行と顧客間の通信で証明書Ｃ C を
不要とし、ステップ６，８で銀行Ｂから商店Ｓに証明書
ＣCを発行することとしたためである。
式では、前記したように、システム全体で、ディジタル
署名の生成を2回、検証を４回行う必要があった。これ
に対して、本実施形態の方法では ・顧客によるコミットメントＭの作成で署名生成を1
回、 ・銀行によるコミットメントＭの検証で署名検証を1
回、 ・銀行による証明書の作成で署名生成を1回、 ・商店による証明書の検証で署名検証を1回、 実行することになる。したがって、本実施形態の方法
は、PayWord方式に比べて署名検証の回数が２回削減さ
れている。これは、銀行と顧客間の通信で証明書Ｃ C を
不要とし、ステップ６，８で銀行Ｂから商店Ｓに証明書
ＣCを発行することとしたためである。
【００５２】つぎに、図３を参照して、前記した決済方
法において用いられるコンピュータの構成を説明する。
このコンピュータは、ＣＰＵ１とメモリ２とインタフェ
ース部３とバス４を備えた一般的なものである。メモリ
２には、前記した決済方法を各参加主体において実施す
るために必要なソフトウエアプログラムやデータが格納
されている。インタフェース部３は、利用者との入出力
や、他のコンピュータとの接続を行う機能を有している
ものである。通常は、このようなコンピュータは、顧客
C、銀行Ｂおよび商店Ｓに備えられて、ネットワーク
（インターネットやＬＡＮを含む）を介して接続されて
いる。しかし、コンピュータの所有や管理主体は制限さ
れない。
法において用いられるコンピュータの構成を説明する。
このコンピュータは、ＣＰＵ１とメモリ２とインタフェ
ース部３とバス４を備えた一般的なものである。メモリ
２には、前記した決済方法を各参加主体において実施す
るために必要なソフトウエアプログラムやデータが格納
されている。インタフェース部３は、利用者との入出力
や、他のコンピュータとの接続を行う機能を有している
ものである。通常は、このようなコンピュータは、顧客
C、銀行Ｂおよび商店Ｓに備えられて、ネットワーク
（インターネットやＬＡＮを含む）を介して接続されて
いる。しかし、コンピュータの所有や管理主体は制限さ
れない。
【００５３】なお、前記各実施形態の記載は単なる一例
に過ぎず、本発明に必須の構成を示したものではない。
各部の構成は、本発明の趣旨を達成できるものであれ
ば、上記に限らない。また、各実施形態を実現するため
のコンピュータの具体的構成は、ハードウエア、ソフト
ウエア、ネットワーク、これらの組み合わせ、その他の
任意の手段を用いることができ、このこと自体は当業者
において自明である。また、複数のコンピュータが協調
して、ある機能を実現してもよく、一つのコンピュータ
が複数の機能を実現してもよい。ネットワーク環境下で
は、そのような構成は容易に設計可能である。
に過ぎず、本発明に必須の構成を示したものではない。
各部の構成は、本発明の趣旨を達成できるものであれ
ば、上記に限らない。また、各実施形態を実現するため
のコンピュータの具体的構成は、ハードウエア、ソフト
ウエア、ネットワーク、これらの組み合わせ、その他の
任意の手段を用いることができ、このこと自体は当業者
において自明である。また、複数のコンピュータが協調
して、ある機能を実現してもよく、一つのコンピュータ
が複数の機能を実現してもよい。ネットワーク環境下で
は、そのような構成は容易に設計可能である。
【００５４】
【発明の効果】本発明によれば、PayWord方式よりも安
全性が高い決済方法を提供することができる。また、本
発明によれば、PayWord方式よりも署名検証の回数を削
減することができるので、コンピュータの処理量が少な
い決済方法を提供することができる。
全性が高い決済方法を提供することができる。また、本
発明によれば、PayWord方式よりも署名検証の回数を削
減することができるので、コンピュータの処理量が少な
い決済方法を提供することができる。
【図１】本発明の一実施形態に係る決済方法の概略的な
構成を示すブロック図である。
構成を示すブロック図である。
【図２】本発明の一実施形態に係る決済方法の手順を説
明するためのフローチャートである。
明するためのフローチャートである。
【図３】本発明の一実施形態に係る決済方法に用いるコ
ンピュータの概略的な構成を示す説明図である。
ンピュータの概略的な構成を示す説明図である。
C 顧客
B 銀行
S 商店
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 青木 聡
東京都台東区上野桜木１−３−１
(72)発明者 駒野 雄一
千葉市若葉区多部田町463−14
Ｆターム(参考） 5J104 AA07 AA09 KA01 KA05 NA02
NA12 PA10 PA12
Claims (4)
- 【請求項１】 コンピュータを用いて、下記のステップ
を行うことを特徴とする、電子的決済方法： （１）次の情報（Ｍ）を、顧客から商店に、顧客の秘密
鍵によるディジタル署名を付して送付するステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記のディジタル署名が行われた前記ハッシュチ
ェーンの長さと前記顧客識別子と前記商店識別子とを示
す情報を前記商店から銀行に送付するステップ； （３）前記顧客の秘密鍵に対応する公開鍵を用いて顧客
の認証を行った後、前記ハッシュチェーンの長さに応じ
た金額を、前記顧客の口座から引き落とすステップ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、銀行の秘密鍵でディジタル署名して前記
商店に送付するステップ； （５）前記銀行の秘密鍵に対応する公開鍵を用いて、前
記ステップ（４）における証明を商店が検証するステッ
プ； （６）前記顧客から、支払代金として、前記ハッシュチ
ェーンのある段階におけるハッシュ値と前記段階とを示
す情報（ｗｊ，ｊ）を前記商店に送付するステップ； （７）前記ステップ（６）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記銀行に送付するステッ
プ； （８）前記ステップ（７）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。 - 【請求項２】 コンピュータを用いて、下記のステップ
を行うことを特徴とする、電子的決済方法： （１）ハッシュチェーンの長さ（ｎ）と顧客識別子（Ｉ
Ｃ）と商店識別子（ＩＳ）とを、商店から銀行が受け取
るステップ； （２）前記顧客の認証を行った後、前記ハッシュチェー
ンの長さに応じた金額を、前記顧客の口座から銀行が引
き落とすステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に銀行が送付するステップ； （４）前記ハッシュチェーンのある段階におけるハッシ
ュ値とその段階とを示す情報（ｗｊ，ｊ）、および、前
記商店と前記顧客とを示す情報（ＩＳ，ＩＣ）を前記商
店から銀行が受け取るステップ； （５）前記ステップ（４）における各情報を受け取った
銀行が、前記ステップ（３）において引き落としておい
た金額の一部または全部を、前記商店の口座に移すステ
ップ。 - 【請求項３】 コンピュータを用いて、下記のステップ
を行うことを特徴とする、電子的決済方法： （１）次の情報を、顧客から商店が受け取るステップ； ハッシュチェーンの長さ（ｎ） ある数（ｗｎ）に前記ハッシュチェーンを適用した
後の値（ｗ０） 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記ハッシュチェーンの長さと前記顧客識別子と
前記商店識別子とを示す情報を前記商店から銀行に送付
するステップ； （３）前記顧客から前記商店への支払い能力を銀行が保
証する証明を、前記銀行から前記商店が受け取るステッ
プ； （４）前記顧客から、支払代金として、前記ハッシュチ
ェーンの任意の段階におけるハッシュ値と前記段階とを
示す情報（ｗｊ，ｊ）を前記商店が受け取るステップ； （５）前記ステップ（４）におけるハッシュ値と段階と
を示す情報（ｗｊ，ｊ）、および、前記商店と顧客とを
示す情報（ＩＳ，ＩＣ）を前記商店から前記銀行に送付
するステップ； （６）前記ステップ（５）における各情報を受け取った
銀行から、前記支払代金に対応する金額を前記商店の口
座に受け入れるステップ。 - 【請求項４】 コンピュータを用いて、下記のステップ
を行うことを特徴とする、電子的決済における支払い証
明方法： （１）次の情報（Ｍ）を、顧客から商店に送付するステ
ップ； 商店識別子（ＩＳ） 顧客識別子（ＩＣ） （２）前記顧客識別子と前記商店識別子とを示す情報を
前記商店から銀行に送付するステップ； （３）前記顧客から前記商店に支払い可能となる金額
を、前記顧客の口座から前記銀行が引き落とすステッ
プ； （４）前記顧客から前記商店への支払い能力を銀行が保
証する証明を前記商店に送付するステップ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002018706A JP2003216875A (ja) | 2002-01-28 | 2002-01-28 | 電子的決済方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002018706A JP2003216875A (ja) | 2002-01-28 | 2002-01-28 | 電子的決済方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003216875A true JP2003216875A (ja) | 2003-07-31 |
Family
ID=27653945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002018706A Pending JP2003216875A (ja) | 2002-01-28 | 2002-01-28 | 電子的決済方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003216875A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008152748A (ja) * | 2006-12-14 | 2008-07-03 | Shijin Kogyo Sakushinkai | 可変貨幣値の小額決済システム、方法及びそのコンピュータ可読媒体 |
| JP2009048627A (ja) * | 2007-07-27 | 2009-03-05 | Ntt Docomo Inc | 委任されたトランザクションを実行するための方法及び装置 |
| JPWO2014087738A1 (ja) * | 2012-12-05 | 2017-01-05 | ソニー株式会社 | 情報処理装置、検証処理装置、情報処理方法、検証処理方法、およびプログラム |
| JP2020525904A (ja) * | 2017-06-22 | 2020-08-27 | ジェイピーモルガン・チェース・バンク，ナショナル・アソシエーション | 銀行間情報ネットワークを実装するためのシステムおよび方法 |
-
2002
- 2002-01-28 JP JP2002018706A patent/JP2003216875A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008152748A (ja) * | 2006-12-14 | 2008-07-03 | Shijin Kogyo Sakushinkai | 可変貨幣値の小額決済システム、方法及びそのコンピュータ可読媒体 |
| US8032466B2 (en) | 2006-12-14 | 2011-10-04 | Institute For Information Industry | System, method, and computer readable medium for micropayment with varying denomination |
| JP2009048627A (ja) * | 2007-07-27 | 2009-03-05 | Ntt Docomo Inc | 委任されたトランザクションを実行するための方法及び装置 |
| JPWO2014087738A1 (ja) * | 2012-12-05 | 2017-01-05 | ソニー株式会社 | 情報処理装置、検証処理装置、情報処理方法、検証処理方法、およびプログラム |
| JP2020525904A (ja) * | 2017-06-22 | 2020-08-27 | ジェイピーモルガン・チェース・バンク，ナショナル・アソシエーション | 銀行間情報ネットワークを実装するためのシステムおよび方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7350030B2 (ja) | 複数のトランザクションをブロックチェーンに記録する方法及びシステム | |
| CN108764874B (zh) | 基于区块链的匿名转账方法、系统及存储介质 | |
| US20200127813A1 (en) | Method and system for creating a user identity | |
| US20200193432A1 (en) | Method and system for settling a blockchain transaction | |
| Franco | Understanding Bitcoin: Cryptography, engineering and economics | |
| JP2022088560A (ja) | ブロックチェーンベースの暗号通貨のためのトークンを検証する、コンピュータにより実行される方法及びシステム | |
| JP5721086B2 (ja) | 電子マネーの管理方法 | |
| EP3718069A1 (en) | Blockchain system for confidential and anonymous smart contracts | |
| JP2021529397A (ja) | ブロックチェーンアドレスおよび所有者の検証のためのシステムおよび方法 | |
| TW201944757A (zh) | 適於提升即時離線區塊鏈交易安全性的電腦實施系統與方法 | |
| RU2157001C2 (ru) | Способ проведения платежей (варианты) | |
| CN110612547A (zh) | 一种用于信息保护的系统和方法 | |
| JPH11504144A (ja) | 電子マネーシステム | |
| CN111815322A (zh) | 一种基于以太坊的具备可选隐私服务的分布式支付方法 | |
| CN111639923A (zh) | 一种基于零知识证明的数字货币交易记账方法及系统 | |
| CN113283957B (zh) | 一种基于区块链的实体产品交易方法 | |
| JPH10171887A (ja) | オンラインショッピングシステム | |
| Singh et al. | Performance comparison of executing fast transactions in bitcoin network using verifiable code execution | |
| CN111539719B (zh) | 基于盲签名的可审计混币服务方法及系统模型 | |
| JP2003216875A (ja) | 電子的決済方法 | |
| JP2020046975A (ja) | 仮想通貨の資金移動システムおよび方法 | |
| WO2021060340A1 (ja) | 取引情報処理システム | |
| WO2021144888A1 (ja) | 決済処理装置、決済処理プログラムおよび決済処理システム | |
| KR20180054974A (ko) | 수취인 증명 기반의 모바일 차용거래 방법 | |
| JP2879792B2 (ja) | 電子現金の分割使用方法およびその装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050119 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20050119 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070815 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071210 |