CN1328675A - 实现交易的方法及其装置 - Google Patents

实现交易的方法及其装置 Download PDF

Info

Publication number
CN1328675A
CN1328675A CN99813754A CN99813754A CN1328675A CN 1328675 A CN1328675 A CN 1328675A CN 99813754 A CN99813754 A CN 99813754A CN 99813754 A CN99813754 A CN 99813754A CN 1328675 A CN1328675 A CN 1328675A
Authority
CN
China
Prior art keywords
payment
payee
signature
payer
payment certificate
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
Application number
CN99813754A
Other languages
English (en)
Inventor
奥列格·阿纳托列维奇·佐洛塔廖夫
伊万·弗拉基米罗维奇·库兹涅佐夫
安德列·根纳季维奇·莫申金
亚历山大·列昂尼多维奇·斯米尔诺夫
伊尔达·马加夫罗维奇·海米托夫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CN1328675A publication Critical patent/CN1328675A/zh
Pending legal-status Critical Current

Links

Images

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • 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/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Abstract

本发明提出一种用于进行交易,并在开放式电信网上进行交易期间保护交易的每个参与者的经济利益不受其它参与者的欺诈的方法。该方法用于保护付款人与受款人之间的隐私,用于进行从微观支付到企业对企业支付范围的各种支付,交易在时间上只取决于网络连接的行动速度而与交易量无关。该方法也使得能服务数量与交易系统经营者的资源成比例地增长的大量客户,能容易地被集成在任何贸易系统中,使每个客户既能支付付款也能接受付款,并能在不同银行的客户之间进行交易。该用于进行交易的方法是在软件环境中实现的。

Description

实现交易的方法及其装置
本发明涉及电子支付系统。
电子支付系统的目的是为通过开放式通信网实现交易提供合适的支付工具。除了安全和可靠程度、服务成本、执行主操作的快捷性等外，支付系统的一个重要特点是保护用户的隐私。
用户的隐私意味着任何人-即使支付系统经营者，都不能控制用户的购物。在电子支付系统中保护隐私的其中一种方式在于，购买是借助数字数据进行的，数字数据证实偿付能力，但不导致识别出付款人的身份。这种数据有时被称为电子现金。然而，电子现金以及任何数字数据能容易地被复制，所以必须防止电子现金的多重花费。
在某些支付系统中，由付款机(payer devices)(S.Brands的钱包中带有观测者的不可跟踪的脱机现金-密码预付’93中的建议，Springer-Verlag出版，302-318页)防止多重花费。为了有效地防止多重花费，这种付款机必须是抗窜改的，即它们必须防止对付款机中含有的数据的非授权访问。采用这种方法的系统的缺陷是，它们极不稳定。问题是，侵入一个付款机可能会对整个系统导致灾难性的后果，这是因为付款机中含有的数据让人能花费任意数量的未付费的电子现金。已知的抗窜改技术没有足够的防范这种风险的可靠性。
不依赖付款机抗窜改性的电子支付系统，特别必须确保人们不能伪造支付证书-即证实付款人的偿还能力的数字数据。这种伪造由加密方法-即由支付系统经营者的数字签名-来禁止。下列书籍中描述了许多数字签名的例子：B.Schneier的Applied Cryptography：Protocols，Algorithms，and Source Code in C(应用加密术：协议、算法和C语言源代码，John Wiley&Sons出版社，纽约，第二版，1996)和A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of AppliedCryptography(应用加密术手册，CRC出版社，1997)。
由支付系统经营者的数字签名来确保不可能伪造支付证书的电子支付系统，可以划分成脱机的和联机的两类。在脱机支付系统中，受款人收钱的时刻就是受款人对付款人所提供的作为付款的支付证书的成功验证的时刻。这种系统的一个优点是，无需任何第三方就能把钱从付款人转移到受款人。这里，为了防止支付证书的多重花费，将付款人的标识符以隐藏的形式附在支付证书中，进行过多重花费的付款人的标识符能被发现。这种方法的缺陷是它并不防止支付证书的多重花费，只能使人们发现这种花费，让某付款人对此负责。所以，如果骗子逍遥在外，支付系统经营者就会蒙受损失。此外，如果骗子获取了关于诚实付款人的支付证书的信息并使用了这种证书，诚实付款人的名誉也会遭受损害。已知有几种脱机支付系统。例如，下述专利中描述了这样一种系统：T.Okamoto、K.Ohta的Electronic cash system(电子现金系统)(美国专利5,224,162，1992年6月8日)。
在联机支付系统中，受款人转而要求支付系统验证每笔付款。在这种情况中，为防止多重花费，支付系统经营者存储关于以前使用过的支付证书的信息，如果某支付是借助某个支付证书进行的，经营者检查该证书以前是否被使用过。
现有技术已知有一种实现支付的方法(不可追踪的电子现金)，美国专利5,768,385，1998年6月16日)，该方法中，付款人在银行中接受支付证书的电子签名-该支付证书被称作电子货币，付款人用其既能兑换新的电子货币，又能付款。这里，银行并不知道付款人采用这两种方式中的哪一种，该事实有助于付款的不可追踪性。另外，受款人在银行中对所接收电子货币的联机验证，防止了电子货币的多重花费。然而，对如果系统的参与者通常是个付款人而不是受款人，该已知方法并不提供对该参与者的不可追踪性，这是因为，给予这样一个参与者的、由商店因交易而产生的电子货币，一般来说就是该参与者向商店付过款的证据。
现有技术已知有一种实现支付的方法(D.Chaum的Security WithoutIdentification：Transaction Systems to Make Big Brother Obsolete，美国计算机学会通信，28卷10号，1985年10月，1035-1038页)，是本发明的最接近的类似方法，本申请人选其作为设计原型。在该已知方法中，客户用他在银行中接受其签名的、称作电子货币的支付证书付款。这里，可能的票面价值(nominal value)的集合是预先确定的，银行为电子货币的每个可能的票面价值建立一个保密的和一个公开的现金钥匙(money key)。要获得一个电子货币，付款人就要借助一个随机数生成器选择该货币的号码，在愿意把相应的金额记在付款人贷方项目下的银行中获得在所选择号码上的隐蔽数字签名(blind digital signature)，并将该数字签名作为支付证书的签名-也可称作支付证书签名。在支付过程中，付款人向受款人划转一系列电子货币，然后，受款人验证电子货币的有效性，并将所收到的货币送往银行，存入其帐户。银行验证电子货币的有效性，如果这些货币尚未被使用过，就把相应的金额归于付款人的帐户。为了检查使用过的货币，银行存储使用过的货币的号码的列表，在货币的号码中含有的期限日期使银行能从列表中删除旧号码。该已知方法的缺陷在于，银行的信誉不对不诚实客户设防，而客户的钱则不对不诚实银行设防，这是因为，被银行拒绝第二次确认一个已经使用过的证书的不诚实客户可能指控银行欺诈。而已经收到一个要求验证的证书的不诚实银行则可能宣称该证书以前已经被用过。此外，银行必须在数据库中存储关于每个使用过的证书的资料，数据库的存取速度要足够地快，这导致银行的数据库的迅速膨胀，也导致有必要对证书采用期限日期。此外，在该已知方法中，付款金额是货币的票面价值的累积组合，这个事实或者限制支付的范围，或者导致支付中所用货币的数量的增长，后者也导致银行数据库的增大和付款速度的降低。
现有技术中已知一种用于实现支付的装置(T.Okamoto、K.Ohta的Method and apparatus for implementing electronic cash(实现电子现金的方法和装置)-美国专利4,977,595，1990年12月11日)，本申请人选其作为设计原型。
该实现支付的已知装置由通过电信网相连的一个付款机、一个商店和一个银行组成，付款机有一种用于通过获得银行的隐蔽货币签名来补充付款机的装置，银行有一种用于生成货币签名的装置。此外，商店还含有一种用于支付证书的脱机验证的装置，银行含有用于揭露反复花费银行债务(obligation)的骗子的装置。
该实现支付的已知装置的缺陷是，它不阻止反复花费支付证书，只能使人能检测出这种花费，去追究付款人的责任。该已知的用于实现支付的装置另一个缺陷是工作速度慢，这是因为要通过电信网传输大量数据。
所要求的发明的各种变形所解决的主要问题，是要建立用于实现支付的各种方法，这些方法要确保一种有效和可靠的通过开放式通信网付款的机制，确保保护支付系统的每个参与者不受其它参与者的欺诈，确保对普通的付款参与者的隐私的保护，以及确保支付方式的多样性。
所提出的要求的实现支付的方法的所有变形的共同技术结果是，当通过电信网实现支付时，每个参与者的经济利益得到不受其它参与者欺诈的保护，并且付款人和受款人能保护它们的隐私。此外，在主张权利的有些变体中，提供范围从微观支付(micro-payments)到企业对企业支付(business-to-business payments)的各种支付方式，实现一次支付所用的时间只取决于网络连接的行动速度而不取决于付款额，支付系统经营者所能服务的客户的数量与经营者的资源成比例地增长。实现支付的方法由一种通过程序设计手段实现的用于实现支付的装置实现。
所要求的的发明与现有技术的本质区别在于，不但保护支付操作的参与者的隐私，而且确保付款人的经济利益，这是因为，支付是根据一个签署有与一个支付证书相联系的保密钥匙(secret key)的付款人指令(payer order)而生效的。此外，在所要求的一些变形中，允许逐渐地花费支付证书并允许补充它们。
付款人的隐私是通过在支付证书上制作保密签名(secret signature)的程序得到保护的，并且，还可以这样来保护受款人的隐私-即在开帐户时，受款人不必给出标识其身份的信息。在支付系统经营者控制支付条件、特别是有关付款目的的信息的那些变形中，保护付款人和受款人的隐私的方式是，进行这种控制时不接触支付条件的保密部分。
所要求的实现支付的方法，是要完全地用于硬件或计算机实现的，这是因为，对实现支付中所用的数据的处理，特别是数字签名的制作和验证，实际上只能以硬件或计算机实现。
下文对实现支付的方法和装置的描述，旨在说明本发明，不应认为是对所申请发明的范围限制，该范围在本说明书的其它地方有更全面的说明。
下面给出本申请中所用术语的说明信息。
当实现支付如任何使用数字签名的系统中那样涉及数字签名时，就要处理在合适的材料介质上存储的、准许数字表示的数据。(B.Schneier的Applied Cryptography：Protocols，Algorithms，and Source Code inC(应用加密术：协议、算法和C语言源代码，John Wiley&Sons出版社，纽约，第二版，1996)和A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of Applied Cryptography(应用加密术手册，CRC出版社，1997))。
在有些数字签名方案中，在不接触保密钥匙的情况下在随机数据上制作数字签名是容易的。为了排除避免不借助保密钥匙的持有者就获得数字签名的可能性，从所有数据中挑选出一个有效数据集合，并在验证某些数据上的签名的有效性时包括验证这些数据的有效性。数字签名系统的概念意味着有效性标准的确定。特别地，数据的一部分与一系列位的一致就可以是有效性标准。在有效性标准的另一个例子中，一个数据被视为有效的条件是，该数据是一个数据对(X，Y)，其中F(X)＝Y并且Y是个单向函数(B.Schneier的Applied Cryptography：Protocols，Algorithms，and Source Code in C(应用加密术：协议、算法和C语言源代码)，John Wiley&Sons出版社，纽约，第二版，1996，29-30页和A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of AppliedCryptography(应用加密术手册，CRC出版社，1997)8-9页)，即，在本案例中，F是一个对任何人来说-签署者可能除外-都是不可逆计算的函数。
下文中把用于签署的钥匙简称作钥匙，并对用于其它目的的钥匙的功能(function)作具体说明。
支付系统经营者的意思是一个确保支付操作的参与者之间金钱交易的实体。特别地，支付系统经营者能保有支付操作的参与者的帐户并发行价值文件(value documents)。支付系统经营者可能由一个银行构成，或者可以包含通过各种协议相互联系的包括银行在内的几个机构。特别地，支付系统经营者的保密钥匙可能是属于支付系统经营者的机构的其中之一的秘密，支付系统经营者对第三方的义务也可能只是属于支付系统经营者的机构的其中之一的义务。如果支付系统经营者包含几个不同的银行或其它机构，则必定存在一个确定属于支付系统经营者的机构之间的相互义务的安全系统。为简化本申请的文字，以下用术语“经营者”来替代术语“支付系统经营者”。
支付服务器的意思是经营者借助其来服务于实现支付的一种装置，这种支付服务器可以由一个或几个计算机或其它设备组成。
付款机的意思是付款人借助其实现支付的一种设备，收款机的意思是受款人借助其实现支付的一种设备。支付证书的意思是表示经营者的义务的数字数据。支付证书包括基数(base)、签名和等级(level)。
支付证书的基数，也称作支付证书基数，意思是这样一种数据-在它们上面的被以公开现金钥匙验证过的签名，起着经营者的与该证书相关联的义务的一个证明的作用；所述签名被称作支付证书的签名或者支付证书签名。支付证书签名是用与用于验证该签名的公开现金钥匙对应的经营者的保密现金钥匙制作的。以下用术语“保密现金钥匙”替代术语“经营者的保密现金钥匙”。
支付证书的等级的概念，是在保密现金钥匙和公开现金钥匙的等级的基础上建立的。公开现金钥匙的等级的意思是与该公开现金钥匙相关联并定义一定货币值的一定数字特征。等级能被表示，特别是能由一个或几个数字来表示。例如，等级可由一个非负整数L来表示，以美分为单位表达等级所定义的货币值。在另一个例子中，等级能由一组非负整数L＝(L1...Lk)来表示，以美分为单位表达的货币值能由该等级通过公式L1·N1+...+Lk·Nk定义，其中是N1...Nk预先确定的非负整数。在这种情况中，各数Lj被称作数量级(orders)，一个数量级超过另一个数量级的量是逐数量级地定义的。保密现金钥匙的等级的意思对应的公开现金钥匙的等级，支付证书的等级的意思是支付证书签名的等级，即该签名能借助其得到验证的那个公开现金钥匙的等级。
下面给出由第一中变形实现支付的方法的说明。
实现一次支付包含执行付款机补充操作、开立受款人帐户的操作和支付操作本身。
通过借助支付服务器获得支付证书签名而补充付款机。这里，支付证书签名是以经营者的隐蔽现金签名的形式获得的。这导致支付证书与补充源的不可联系性，由此确保付款人的隐私。
借助初次填充支付证书的操作来补充付款机，在其过程中，在付款机中创建支付证书的基数并借助支付服务器获得支付证书签名。创建支付证书的基数的操作的单独说明在下面给出。
支付证书的基数是在付款机中创建的。为了建立支付证书的基数Base，选择受款人的任意保密钥匙DP和对应的公开钥匙EP。这种选择是在任何数字签名系统的结构中进行的。所选择的钥匙DP和EP分别被当作支付证书的保密钥匙和公开钥匙。将公开钥匙EP的标识符(identifier)附加在支付证书的基数Base中。公开钥匙的标识符的意思是唯一性地定义该公开钥匙的任意数据。特别地，可以将公开钥匙EP本身当作这样一个标识符。在另一个例子中，可以将一个关于钥匙EP的加密哈希函数(hash function)的值(B.Schneier的AppliedCryptography：Protocols，Algorithms，and Source Code in C(应用加密术：协议、算法和C语言源代码，John Wiley&Sons出版社，纽约，第二版，1996，第429页)作为标识符。还有一个例子中，可以把所接收公开钥匙在被经营者或其它实体登记时的号码当作标识符。
把公开钥匙EP的标识符附加在支付证书的基数Base中，能保障付款人在实现支付时的安全。就是说，在进行如下文所述的支付操作时，经营者只能按付款人签署的付款人指令花费与支付证书相关的值。付款人指令上的签名用保密钥匙DP制作并用公开钥匙EP验证。由于只有付款人能接触保密钥匙DP，如果没有付款人的帮助也是得不到的这种签名的。
特别地，以下述方式把公开钥匙EP的标识符附加在支付证书的基数Base中。用数据对(X，Y)作为基数，其中X＝EP，Y＝F(X)，F最好是个无冲突的单向函数(B.Schneier的Applied Cryptography：Protocols，Algorithms，and Source Code in C(应用加密术：协议、算法和C语言源代码)，John Wiley&Sons出版社，纽约，第二版，1996，第30页)。在这种情况中，在用支付证书进行操作时，可以用数据Y作为基数的标识符，用关系Y＝F(X)作为基数的有效性的标准，其中，支付证书基数的有效性的标准的意思是现金钥匙所属的数字签名系统的有效性标准。
下面给出在初次填充支付证书期间获得以经营者的隐蔽现金签名为形式的支付证书的签名的单独说明。
在初次填充一个具有基数Base的支付证书期间，借助赋予获得隐蔽数字签名的可能性的任意一个数字签名系统中的主机中用于获得经营者的隐蔽数字签名的程序而获得支付证书签名。
现有技术中已知有几个赋予制作隐蔽数字签名的可能性的数字签名系统(D.Chaum，隐蔽签名系统，美国专利4,759,063，1988年7月19日；D.Chaum，隐蔽的无法预料的签名系统，美国专利4,759,064，1988年7月19日；D.Pointcheval、J.Stern，可验证的安全隐蔽签名，计算机科学上的演讲笔记，1163，1996年Springer出版，252-265页)。当在初始数据M上制作保密数字签名时，用户向签署人提供通过隐蔽(blinding)数据M而获得的隐蔽数据(blinded data)M’。签署人向用户提供通过用签署人的保密钥匙处理隐蔽数据M’而获得的待解除隐蔽的数据S’；用户通过除去隐蔽获得初始讯息上的签名S。通过除去隐蔽所获得的数据的有关签名性质，不但能在解除隐蔽之前验证，而且能在解除隐蔽之后验证-如果所用的数字签名系统允许这样做的话。
在执行初次填充支付证书的操作时，把支付证书的基数的标识符BaseId，即标识这个基数的任意数据，当作初始数据。在通过制作隐蔽数字签名获得支付证书签名时，用对应于补充数额的保密现金钥匙处理隐蔽数据。补充数额与保密现金钥匙之间的对应，意思是补充数额与由该保密现金钥匙的等级所定义的货币值之间的对应。
接受通过对从支付服务器获得的对要解除隐蔽的数据进行解除隐蔽而获得的标识符BaseId上的签名，作为具有基数Base的支付证书签名。所制作的支付证书签名的有效性，能用在获得要解除隐蔽的数据时对应于所使用的保密现金钥匙的公开现金钥匙验证。
这样，在执行初次填充支付证书的操作之后，付款机含有一个适合于进行支付操作的支付证书。
在执行初次填充支付证书的操作时，把基数的隐蔽标识符作为在付款机中生成的现金请求(money demand)的一部分发送到支付服务器，并用该现金请求中所指出的补充源的资金补充付款机。这里，在经营者看来，付款机的补充源就是记贷的源(source of crediting)，因为作为该补充操作的结果，经营者的现金义务出现在付款机中，付款人于是变得有信用(credited)。除了补充源外，补充数额也由现金请求决定，如果所述数额不是由其它情况，例如由所述补充源的维持条件，决定的话。
特别地，付款人帐户或其银行卡可被用作补充源。这里，银行卡的意思是任意一种供划转价值的充值卡(value card)。从所指出的补充源远程提取价值的安全性，由维持该补充源的系统保证。
向经营者开立付款人帐户的操作，可以以任意方式进行。所开立的帐户最好认可远程管理的安全系统。
一个认可远程管理的安全系统的帐户的例子是具有公开钥匙的帐户，也称作公开钥匙帐户。公开钥匙帐户的意思是由经营者保管、并许可借助签过名的指令进行管理的帐户，指令上的签名可以借助与该帐户相关的公开钥匙得到验证。要管理这样一个帐户，帐户的持有者可以使用其对应于帐户的公开钥匙的保密钥匙的保密钥匙，该保密钥匙被称作帐户。通过公开钥匙帐户进行远程管理的安全性是有保障的，因为事实上经营者按照签过名的指令对该帐户进行操作，指令上的签名要用帐户的公开钥匙验证，该签名被经营者用作代表帐户持有者的证据。
除了借助签署有帐户的保密钥匙的指令进行管理外，公开钥匙帐户也能由其它方法管理。特别地，可以把这样一个帐户与标识一个负责该帐户的人，即有权管理该帐户的人，的信息联系起来。这种信息在帐户的保密钥匙丢失的情况下可能特别有用，因为这种信息将使持有者在这种情况下也能控制其帐户。
此外，如果需要保证负责帐户的人的匿名，则可以将标识所述人的信息以隐蔽的形式存储在支付服务器中，这就不允许人在没有知道这种联系的人的帮助下把该信息与负责该帐户的人相联系。例如，该隐蔽信息可以是一个关于负责帐户的人的身份数据的加密哈希函数的值与一个口令的联接，或者就是口令上的所述值。可以通过在开立帐户时以及其它时刻用帐户的保密钥匙签署的指令将标识负责帐户的人的信息与帐户联系起来。
下面给出特定一例开立公开钥匙帐户的操作的单独说明。该说明将在以下对所要求权利的发明的其它变体的说明中被用作参考。特别地，以下所述的开立帐户的操作既能在开立受款人帐户时使用也能在开立付款人帐户时使用，以这种方式开立的付款人帐户可被用作补充付款机的源。
开立公开钥匙帐户的操作尤其可以按下述方式进行。正在开立的帐户的将来持有者接受以他的一个任意保密钥匙作为帐户的保密钥匙。将对应于帐户的保密钥匙的公开钥匙发送给支付服务器，作为正在开立帐户的公开钥匙。帐户的持有者在获得由经营者签过名的、确认开立与该公开钥匙相关的帐户的讯息后，认为帐户被开立。
除了帐户的公开钥匙外，也可以将由持有者和由经营者选择的其它数据与正在开立的帐户联系起来。例如，经营者可以分配正在开立的帐户一个号码，将该号码发送给帐户的持有者。持有者将帐户与其联系起来的数据最好是说明性的，这保证自动执行，并由此保证开立帐户的操作及帐户维护的便宜。帐户持有者的隐私能得到保护，因为事实上帐户是匿名开立的。
下面给出由第一变体进行的支付操作的单独说明。下文中给出的所要求权利的发明的其它变体的说明含有对该说明的参考。在由第一变体进行支付操作时，完全花光支付证书中含有的值。由于在所要求权利的发明的其它变体中，除了这种支付操作外，还进行使得有可能逐渐花费支付证书值的支付操作，为了更加明确起见，把本变体中所用的支付操作说成是注销支付证书的支付操作。
注销支付证书的支付操作的实质是，在支付服务器中，记贷(credit)受款人的帐户，由此取消经营者的与支付证书相关联的义务。付款人帐户是在支付证书尚未被使用过、支付证书签名有效并且付款人指令上的签名有效的情况下被记贷的。判断支付证书是否已经被使用过的依据是支付服务器信息储存库中含有的关于所使用的支付证书的信息，而支付证书签名和签署有支付证书的保密钥匙的付款人指令则是借助收款机被发送到支付服务器的。下面是对注销支付证书的支付操作的更详细的说明。
在进行支付操作时，在付款机中生成一个付款人指令，付款人指令中含有关于受款人的信息和支付证书的基数的标识符。签署有支付证书的保密钥匙的付款人指令包含向收款机发送的、称作支付数据的数据。特别地，付款人指令中包含的关于受款人的信息含有支付条件和受款人帐户的标识符，如果该帐户不是由其它情况决定的话。
支付条件的意思是规定使付款生效的情况的任意数据。这种数据特别可以包括付款金额和对进行付款所花时间的限制。特别地，支付条件可能以某种对经营者隐蔽的方式含有描述由实现支付的事实所隐含的受款人的义务的数据。
在收款机中，生成称为受款人指令的数据，该受款人指令被传送到支付服务器。在此，一个数据在受款人指令中包括包含在支付数据中的付款人指令，并且，可能地，其他数据包括特别是支付条件。而且，该付款人指令可以签署有受款人帐户的保密钥匙，如果该付款人的帐户是一个公开钥匙帐户的话。
在支付服务器中，根据受款人指令(payee order)记贷受款人帐户，并生成经营者对受款人指令的答复(response)，支付操作的情况是通过该答复而判断的。这里，如果支付服务器信息储存库不含有表明支付证书已经被使用过的信息，就在受款人帐户的贷方项目下记帐。此外，在支付服务器中，在记贷受款人帐户之前，还验证支付证书的签名的有效性和付款人指令上的签名的有效性，这些签名是从收款机接收的在受款人指令中含有的付款人指令提取的。为了防止支付证书的多重花费，将关于所述支付证书的信息输入支付服务器信息储存库中。为了确认经营者使所进行的支付操作生效的权利，也将签过名的付款人指令输入支付服务器信息储存库中。将经营者对付款人指令的答复发送到收款机。
在支付操作的执行期间，付款人的经济利益因经营者有责任验证付款人指令上的签名而得到保护，而在信息储存库中存储的签过名的付款人指令则保护经营者不受对其滥用支付证书中含有的价值的错误指控的侵害。
付款人的隐私特别是由于供向支付服务器发送的付款人指令被用经营者的加密钥匙加密而得到保护，某实体的加密钥匙的意思是一种用于对发送该实体的讯息加密的钥匙。
除了付款人指令外，支付数据还可包含供受款人用的数据，尤其是要为其付费的劳务或商品的标识符。
特别地，受款人的安全，因在发送给受款人的经营者对受款人指令的答复中附加了签署有经营者的保密钥匙的受款人收据(payee receipt)的事实而得到保证。这里，受款人收据的意思是确认在受款人帐户贷方项目下记帐的事实的数据。这种收据除了含有记贷数额和被记贷帐户的标识符外，还可含有其它数据，特别是支付条件、进行记贷操作所花费时间等等。在验证过受款人收据上的经营者签名后，受款人认为支付正在进行，于是向付款人发送确认进行支付的事实的数据。
此外，在支付操作的执行期间，在收款机中，通过经营者对受款人指令的答复，还生成并向付款机发送据其判断付款人方面的支付的进行情况的数据。这些数据特别可以既包含受款人对已经为受款人成功地进行了支付操作的事实的认可，也包含签署有经营者的任意保密钥匙的付款人收据(payer receipt)。在支付服务器中，把这种收据附加发往受款人的经营者对受款人的答复中，在收款机中，从受款人所收到的经营者对受款人的答复中提取该收据。这里，付款人收据的意思是确认在支付操作的执行期间花费支付证书中含有的价值的事实的数据。此外，付款人收据还可含有其它数据，特别是支付条件和经营者进行一次支付所花费的时间。此外，在把付款人收据附加到经营者对受款人指令的答复中之前，还可以用付款人的一个任意加密钥匙对所述收据加密。此外，还可以把与受款人对由支付的事实所隐含的其义务的履行有关的数据，以及，特别是访问某种信息的口令，连同据其判断付款人方面的支付的进行情况的数据一起，发送到付款机。
在支付操作期间，支付证书中含有的价值可以花在支付目的上，也可以部分地花在其它目的上。特别地，可以将支付证书值的一部分作为找钱退还给付款机。下面给出这种操作的单独说明。
在退还一部分支付证书值时，通过初次填充支付证书或通过补充已有的支付证书来补充付款机。此外，所退还的支付证书的值，即没有花掉的那部分支付证书值，的退还方式，可以使得所退还的值对经营者来说是未知的。所退还值的这种偿还，例如可借助David Chaum的专利“Returned value blind signature system”(退还值隐蔽签名系统)，美国专利4,949,380号，1990年8月14日，中的说明而进行。在向付款机退还一部分支付证书值的操作的最佳实施例中，经营者不能区分初次填充支付证书与补充已有的支付证书，这有助于保护付款人的隐私。
受款人的安全在支付操作的执行期间是有保证的，特别是因为事实上把签署有经营者的任意保密钥匙的受款人收据附加在经营者对受款人指令的答复中，受款人方面的支付的进行情况则是根据受款人收据上的签名的有效性而判断的。
此外，付款人能控制进行支付操作的情况。为了进行这种控制，在生成付款人指令时把在支付条件附加到付款人指令中。特别地，付款人指令中含有的支付条件可包含受款人义务数据，即描述付款生效的事实所隐含的受款人义务的数据。为了保证付款人需要时可坚持要受款人履行其义务，要用受款人的任意保密钥匙签署受款人义务数据，在付款人决定进行支付操作之前，在付款机中验证受款人义务数据上签名的有效性并将签过名的受款人义务数据存储起来。如果需要对经营者隐瞒支付目的，则在生成支付数据时，在付款机中借助一个任意单向函数处理受款人义务数据，并将经处理所获得的数据作为支付条件附加在受款人指令中。
此外，在支付操作的执行期间，受款人可以扮演付款人的角色。这种支付操作可用于从付款机向付款人帐户划转价值。
注意一个进行付款机补充操作的特定情况，其中，用一个中间付款人的资金进行补充。特别地，对于这种进行付款机的补充的操作，在获得经营者的隐蔽现金签名期间在付款机中被隐蔽的数据要在中间付款人的付款机中受到附加隐蔽，从经营者接收的要解除隐蔽的数据要受到对应的附加隐蔽。这种附加隐蔽目的是保护中间付款人的隐私。
所有考虑用户隐私的排队系统的共同问题与通过网络地址信息确定用户身份的潜在可能性有关。下面的论文中描述了几个解决这个问题的理论方法：D.Chaum的“Security Without Identification：transactionSystems to Make Big Brother Obsolete”，刊于Communications of theACM(美国计算机学会通讯)，卷28第10号，1985年10月，1031-1034页)。一种实际可接受的对讯息接收者隐藏用户网络地址信息的方法可以是用邮件转发器(remailers)从它们自己的地址向接收者传送讯息。特别地，在主张权利的发明的所有变体中，在进行支付操作期间，付款人地址在某种程度上是对银行隐藏的，因为付款人指令是通过收款机发送给支付服务器的。
在由第一变体首先付款的方法的一些实施例中，从微观支付到企业对企业支付的范围的各种支付方式都是可能的，进行一次支付所用的时间只取决于网络连接的运行速度而不取决于付款额，其实现方法是：选择支付证书的等级，使得该等级所定义的值可以取所述范围内的任意值；借助预定数量的、具有预先界定的数量的适当值的支付证书，甚至借助单一的支付证书，实现支付操作。
下面给出由第二变体实现支付的操作的说明。
通过第二变体实现支付的方式与通过第一变体的方式相同，唯一的例外是，除了借助初次填充支付证书来补充付款机外，也通过补充支付证书来补充付款机。此外，在最佳实施例中，在补充付款机时，经营者不能区分初次填充支付证书与补充已有的支付证书，并且用于这种补充的资金源与用于初次填充的资金源毫无联系。
如果，在由第一变体进行支付操作时，向支付服务器提交其等级是付款机中可用的最大等级的支付证书的签名，则经营者能检测到该等级与在补充付款机时所用的现金钥匙的等级相合，这导致在付款中所用的支付证书与其补充的源的联系。这种联系的概率在支付证书的可能等级使得由等级所定义的值可取在微观支付到企业对企业支付范围内的任意值的情况下是特别高的。通过补充支付证书补充付款机显著降低这种联系的概率，因为在补充支付证书之后，其等级是几个具有保密现金钥匙的签名的等级的总和。所以支付证书的补充额外地促进对付款人隐私的保护。此外，支付证书的补充另外还既允许在一个支付证书上积累在支付操作中偿还的用过的支付证书的退还值，也允许用另一个源的资金补充所述支付证书。
下面给出借助补充支付证书补充付款机的操作的单独说明。
支付证书补充操作，即获得一个其等级超过在补充操作开始时付款机中含有的支付证书签名的等级的支付证书签名的操作，是借助获得经营者的隐蔽现金签名而进行的。这里，将付款机中含有的支付证书签名作为初始数据。为了进行支付证书补充操作，等级和现金钥匙之间的对应，必须使得与某数据Y上的等级B的签名相合的某数据X上的等级A的签名，相当于数据Y上的等级(A+B)的签名。这种对应的一个例子是当等级L由一组非负整数(L1，L2，...，Lk)表示，从1至k每个下标j有一个函数Sj，其计算需要保密钥匙Kj。如果函数Sj是互相交换的，即对于任意数据X，Si(Sj(X))＝Sj(Si(X))，则可以将允许人们计算函数SL(SL是各函数Sj的组合，每个函数在组合中以倍数Lj出现)的任意数据，作为对应于等级L的现金钥匙。在这种情况下，数据SL(X)是数据X上具有对应于等级L的现金钥匙的签名。例如，可以把这样一个钥匙表示为一组数据(L，K1，K2，...，Kk)。下文在对实现支付的方法的最佳实施例的说明中陈述了一例关于这种允许保密钥匙的经济制作和存储的函数的特定系统。注意，如果把支付证书的基数作为零等级的支付证书签名，则补充支付证书的操作是支付证书补充操作的一个特定情形。
在通过借助制作更高等级的隐蔽支付证书签名的经营者增加支付证书的等级而补充支付证书的操作的最佳实施例中，经营者不可能确定付款人是补充一个已有的支付证书还是进行填充新创建的支付证书的操作。这里，在补充一个相同的支付证书时，付款人可以使用不同的补充源，而不把它们互相联系。
下面给出由第三变体实现支付的方法。
由第三变体实现支付的方式与第一变体的相同，唯一的例外是，使用允许进行几个支付操作的支付证书。这反映在这样的事实上，即经营者开立一个与规定支付证书相关的支付帐户，并将所述帐户与支付证书签名的公开钥匙联系起来。此外，在支付操作的执行期间用用支付证书的资金记贷的支付帐户的资金，记贷受款人帐户。因此，逐渐花费包含在支付证书中的值是可能的。
支付帐户的意思是由经营者保持的一种帐户，它通过将帐户上的一部分金额转移到另一个帐户或将帐户上的一部分金额转换成一种用于将所述部分发送给受款人的不同形式来从所述帐户实现支付的可能性。这里，支付帐户含有关于花费总额的信息、关于已经被记在帐户的贷方项目下的总额的信息和关于支付帐户的等级的信息。这里，支付帐户的等级的意思是为记贷支付帐户而提交给经营者的支付证书签名的等级。特别地，有可能用公开钥匙帐户作为支付帐户。
下面给出开立支付帐户的操作的单独说明。
要开立一个与支付帐户的基数相关的支付帐户，只要把支付证书的基数的标识符发送到支付服务器。特别地，可以将开立支付帐户与与支付证书相关的第一支付操作相结合。如果用带公开钥匙的帐户作为支付帐户，则可以用支付证书的钥匙作为所述的公开钥匙。此外，为了防止开立的支付帐户没有关联的正等级的支付证书，可以将开立支付帐户的操作与记贷帐户的操作相结合。
下面给出记贷支付帐户的操作的单独说明。
在进行记贷支付帐户的操作时，向支付服务器发送一个其等级可以在支付证书的等级内任意选择的支付证书签名，并根据所发送签名的等级超过支付帐户的等级的量，记贷支付帐户。特别地，可以将记贷支付帐户的操作与支付操作相结合。此外，付款人可以在几个操作过程中记贷其支付帐户，逐步地提高经营者知道的支付证书的等级。这就允许付款人降低借助支付帐户的等级将支付帐户与填充或补充与该帐户有关的支付帐户的源相联系的可能性。
下面给出在由第三变体实现支付的方法中所使用的支付操作的单独说明。与前文所述的注销支付证书的支付操作不同的是，在由第三变体实现支付的方法中所使用的支付操作被描述成一种涉及支付帐户的支付操作。
进行涉及支付帐户的支付操作的方式与上述的注销支付证书的支付操作的相同，但有以下例外。第一，用支付帐户的资金记贷受款人帐户；第二，支付证书签名不必包含在付款人指令中。这里，受款人的行动并非不同于其在注销支付证书的支付操作的执行期间的行动。在进行注销支付证书的支付操作时，产生支付的范围的问题。其要点是，支付证书中含有的值，只能取对应于支付证书的可能等级的其中之一的值，或者对应于现金钥匙的可能等级的其中之一的值。所以，如果在注销支付证书的支付操作的执行期间只用一个支付证书，则支付额只能取预定值的其中之一。因为需要实现从微观支付到企业对企业支付的范围内的支付，在支付操作期间，要么必须处理相当复杂的现金钥匙系统，要么必须使用一系列的支付证书。复杂的现金钥匙系统的应用，一般来说导致支付操作的速度降低，因为制作现金签名和验证其有效性需要相当长的时间。另一方面，在支付操作期间使用一系列的支付证书既导致所用支付证书数量的可观增长(这种增长招致各种损失)，也导致付款人的不便，因为付款人被迫要保证有可用的具有付款机中所需总值的成批的支付证书。涉及支付帐户的支付操作的优点是没有与支付范围有关的问题，因为支付额与现金钥匙的结构无关。所以，使用支付帐户，便于实现在支付帐户的偿付能力的限度内的任意金额的支付，特别是有可能实现微观支付。对于经营者来说，使用支付帐户的优点是经营者可能能服务更多的客户，因为不要求有用于存储关于每个完成的支付的信息的资源。此外，实质上更少的与支付证书相关的记录，加速了在支付操作的执行期间对与特定支付证书相关的记录的检索，或对这种记录不存在的事实的确定。使用支付帐户的缺陷在于，有可能将所有用一个相同的支付帐户实现的支付联系起来。所以，同时使用的支付证书的最大数量是与经营者的资源成比例的。另外，由于可以通过开立支付帐户的操作的费用或者通过制作隐蔽现金签名的操作的费用来限制所使用的支付证书的数量与经营者的客户的数量的比例，因此，经营者所能服务的客户的数量与经营者的资源成比例。
进行涉及支付证书的支付操作，与用一系列支付证书进行注销支付证书的相同支付操作相比的另一个优点是，实现支付所用的时间只取决于网络连接的操作的速度，而与支付额无关，因为付款人指令是固定大小的，这使得有可能指明任何实际可能的金额作为支付额。
此外，在付款机补充操作中可以用与支付证书其中之一有关的支付帐户作为补充源。这样就能将资金从该支付帐户转移到付款机。
下面给出由第四变体实现支付的方法的单独说明。
由第四变体实现支付的方式与由第三变体实现的方式相同，唯一例外是，由于在上述由第二变体实现支付的方法中另外还进行支付证书补充操作。进行这种操作的额外优点也在上述对由第二变体实现支付的方法的说明中指出过。
下面给出实现支付的装置的说明。使用该实现支付的装置，有可能实现所要求的由第三和第四变体实现支付的方法。
实现支付的装置含有与电信网相连的一个付款机、一个收款机和一个支付服务器。这些设备可以用以相应的方式编程的计算设备实现。
这种计算设备可以选自大量的已知电子设备，例如个人电脑。这种计算设备包含，以内部或外部的方式的，存储设备，用于存储在实现支付中所涉及的数据和程序代码。此外，这种计算设备还包含使计算设备能与其它类似设备通信的辅助设备，例如调制解调器。数据在其主机中进行交换的通信环境，也可以是大量可能环境中的任何一种，包括电话线、电缆、因特网、卫星或无线传输、光纤连接等等。换言之，就所使用的设备的类型或所采用的通信的方法而言，本发明不受限制。
付款机、收款机和支付服务器可以由各种各样的根据相应算法的程序设计方法实现。这里，付款机含有一种用于通过制作经营者的隐蔽现金签名的使用而补充付款机的装置，一种用于通过用单向函数处理支付证书的公开钥匙而创建支付证书基数的装置，一种用于在存储设备中存储所创建的支付证书基数的装置，一种用于生成签署有支付证书的保密钥匙的付款人指令的装置。这里，用于通过制作经营者的隐蔽现金签名的使用而补充付款机的装置是通过用于增加支付证书签名的等级的装置而实现的。
所述用于增加支付证书签名的等级的装置有一种用于生成包含隐蔽支付证书签名的现金请求的装置，一种用于对在对现金请求的答复中包含的待解除隐蔽的数据解除隐蔽的装置，一种将解除隐蔽的结果输入所述存储设备的装置。
用于增加支付证书签名的等级的装置用于或者通过初次填充支付证书或者通过编程支付证书而补充付款机。在前一种情况下，借助用于增加支付证书签名的等级的装置来处理零等级的支付证书签名，该零等级其与借助所述用于创建支付证书基数的装置创建的支付证书的标识符相一致的。在后一种情况下，借助用于增加支付证书签名的等级的装置处理在付款机中含有的、在以前一次付款机补充操作中被输入到付款机的存储设备中的支付证书签名。在这两种情况中，支付证书的等级都因付款机的补充而增加。
收款机含有一种用于生成包含付款人指令的受款人指令的装置。此外，收款机还含有一种用于开立公开钥匙帐户的装置。
支付服务器含有一种用于制作现金签名的装置，一种用于进行支付操作的装置，一种用于服务支付帐户数据库的装置，一种用于服务帐户数据库的装置。
这里，用于任意数据库的管理的装置的意思是一种用于对数据库的记录进行操作，包括创建这种记录、读记录和修改记录，的装置。
此外，用于服务帐户数据库的装置还可以含有某种用于维护是该数据库的记录并在存储设备中存储的帐户的装置。这种装置中特别是有一种用于开立公开钥匙帐户的装置，一种用于记贷帐户的装置和一种用于记借帐户的装置。
此外，用于服务支付帐户数据库的装置还可以含有某种用于维护作为该数据库的记录存储在存储设备中的帐户的装置。这种装置中特别是有一种用于开立支付帐户的装置，一种用于验证现金签名的装置和一种用于记贷支付帐户的装置。
此外，支付服务器中含有的用于进行支付操作的装置有一种用于验证付款人指令上的签名的装置和一种用于制作签过名的受款人收据的装置。
用于处理支付服务器中含有的现金请求的装置在进行付款机补充操作时使用所述的装置用于制作现金签名。
此外，支付服务器可含有一种用于制作签过名的受款人收据的装置。收款机可含有一种用于验证签过名的受款人数据的装置。
特别地，所述的用于生成一个签署有支付证书的保密钥匙的付款人指令的装置可以有一种用于生成一个要求记贷支付帐户的请求的装置，后者又有一种用于减少支付证书签名的等级的装置。用于减少支付证书签名的等级的装置的目的如下：用付款机中含有其签名的某个等级的支付证书签名制作另一个具有更低等级的支付证书的签名，用于作为要求记贷支付帐户的请求的一部分发送给支付服务器。
特别地，付款服务器也可以含有一种用于开立公开钥匙帐户的装置。
此外，付款机、收款机和支付服务器也可配备有用于对输出讯息加密的装置和输入讯息解密的装置。
以下通过对实现本发明的具体例子的说明以及通过各附图来解释本发明。附图说明：
图1表示用于实现支付的装置的流程图；
图2表示付款机补充操作的流程图；
图3表示支付操作的流程图。
在由各个变体实现支付的方法的最佳实施例中，付款是在支付系统的主机中实现的，支付系统的经营者包含各种银行，系统有许多付款人和受款人。此外，付款人和受款人二者同时使用含有付款机和收款机二者的设备。此外，在对最佳实施例的说明中，将这种设备称作“电子钱包”。
在服务客户之前，属于支付系统的银行进行预备行动。因为这些预备行动在所申请方法的每个变体的最佳实施例中是以相同的方式进行的，所以下面给出进行这些操作的最佳方式的单独说明。
在预备行动的阶段，确定一个赋予签署隐蔽数字签名的可能性的数字签名系统。该系统的目的是签署和验证现金签名，以下称其为现金签名系统。也确定一组准许等级-即每个定义一定货币值的数量。这里，该组准许等级的选择，使得在补充付款机时代表某实际权益的任意货币值将被某等级表示。对于每个准许等级，银行在一个确定的现金签名系统的主机中选择一个对应于该等级的保密现金钥匙和一个对应于该保密现金钥匙的公开现金钥匙。这里，对应于每个准许等级的保密现金钥匙的选择，使得与某数据Y上的等级B的签名相合的某数据X上的等级A的签名，相当于数据Y上的等级(A＋B)的签名。将关于公开现金钥匙的信息和对应于各准许等级的货币值公开，并输入“电子钱包”的存储设备中。
也确定一个用于签署实现支付时使用的讯息的数字签名系统。在该系统的主机中，银行选择保密钥匙和对应的公开钥匙。将关于公开钥匙的信息公开，并输入“电子钱包”的存储设备中。
此外，还确定支付证书基数的结构和有效性标准，以及将支付证书的公开钥匙的标识符附加到支付证书的基数中的方式。为此，确定一个加密哈希函数F，该函数接受位串形式的值，并且最好是无冲突的。支付证书基数是数据对(Y，X)，其中Y是支付证书的公开钥匙，该钥匙是在确定的签名系统的主机中选择的并用作其自己的标识符。此外，一个具有这种结构的基数在F(Y)＝X时被视为是有效的。把数据X当作支付证书的基数的标识符BaseId。
通过以下例子来说明实现上述的在由每个所申请变体实现支付的方法的最佳实施例中的预备行动的可能性。例1
用户用一种基于数字RSA签名的系统(B.Schneier的AppliedCryptography：Protocols，Algorithms，and Source Code in C(应用加密术：协议、算法和C语言源代码，John Wiley&Sons出版社，纽约，第二版，1996)29-30页和A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of Applied Cryptography(应用加密术手册，CRC出版社，1997))作为现金签名系统。在该系统中，保密钥匙是数据对(N，D)，其中D是一个保密指数(secret exponent)，N是模(modulus)。这里，对应的公开钥匙是数据对(N，E)，其中E是一个公开指数，满足条件：对于与N相质的每个整数X，XE·D≡1(mod N)。该RSA系统允许几种签署隐蔽数字签名的方法。例如，在D.Chaum的专利Blind Signature System(美国专利4,759,063，1988年7月19日)中，描述了这些方法中的其中一个方法；在D.Chaum的专利Blind Unanticipated Signature System(美国专利4,759,064，1988年7月19日)中，描述了另一种方法。
把任意一组非负整数L＝(L1，L2，L3)作为一个准许等级，这样一个等级由公式L1·N1＋L2·N2＋L3·N3(其中N1＝1002，N2＝100，N3＝1)定义以美分为单位表达的货币值。
对于每个准许等级，按下列方式在RSA签名系统的主机中选择对应的保密现金钥匙和对应于保密现金钥匙的公开现金钥匙。用一个任意的RSA模N作为每一个公开现金钥匙和保密现金钥匙的模-整数E1＝3、E2＝17、E3＝5准许作为其对应的公开指数(public component)。下面，把数E1、E2、E3称作基本公开指数。用具有公开指数E＝E1 L1·E2 L2·E3 L3的钥匙作为对应于等级L的公开现金钥匙。用具有保密指数D＝D1 L1·D2 L2·D3 L3的钥匙，作为对应于等级L的保密现金钥匙，其中Dj是对应于基本公开指数Ej的保密指数。在RSA系统中创建钥匙的方法是已知的(B.Schneier的Applied Cryptography：Protocols，Algorithms，and Source Code inC(应用加密术：协议、算法和C语言源代码，John Wiley&Sons出版社，纽约，第二版，1996)和A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of Applied Cryptography(应用加密术手册，CRC出版社，1997))。把模N和基本公开指数E1、E2、E3作为关于公开现金钥匙的信息公布。把数据N1＝1002，N2＝100，N3＝1作为关于对应于准许等级的货币值的信息公布。
用作关于支付证书基数的有效性标准的加密哈希函数F的选择，使得其关于位序列X的值，由位序列H(X)和Y的联接而获得，其中H表示已知哈希函数SHA-1(A.J.Menzes、P.C.Van Oorshot、S.A.Vanstone的Handbook of Applied Cryptography(应用加密术手册，CRC出版社，1997)348页)，Y＝1111...1110，并且Y中的单元位(unit bits)的数目，使得F(X)中的总位数等于模N中的位数。
确定具有公开指数3的RSA系统，即其中公开指数是确定的并且等于3的RSA系统，作为在实现支付时使用的用于签署讯息的数字签名系统。在该系统的主机中，银行选择有关保密钥匙DB和对应的公开钥匙EB。将公开钥匙EB的模作为关于该钥匙的信息公布。
下面给出由第一变体实现支付的方法的最佳实施例的说明。
进行了上述的预备行动之后，受款人在银行开立有关公开钥匙帐户。这里，帐户是以下述方式开立的。
受款人用其在预备行动中确定的签名系统的主机中为此目的专门创建的保密钥匙，作为正在开立的帐户的保密钥匙。把对应于该帐户的保密钥匙的公开钥匙通过开放的电信网发送给支付服务器。在支付服务器中，用所发送的公开钥匙作为正在开立的帐户的公开钥匙，向正在开立的帐户分配有关号码，在帐户存储器中创建一个记录，记录中含有该帐户的号码、该帐户的公开钥匙和该帐户的其它属性。受款人在收到一个签署有银行的保密钥匙、确认开立一个与帐户的公开钥匙相联系的帐户的讯息后，考虑要开立帐户。此外，将该讯息存储在“电子钱包”的存储设备中，这使得人们将来在银行没有履行其与所开立帐户相联系的义务时向银行提出正当的索赔要求。
所述的开立帐户的变体的优点是，开立帐户是实时地远程地进行的。此外，开立帐户是在支付服务器中自动进行的，这特别是因为不需要验证标识帐户持有者身份的数据。所以，该开立帐户的变体对银行来说非常经济，对银行的客户来说非常方便。此外，每个公开钥匙帐户-即如上所述所开立的帐户-准许安全远程管理，并且帐户号码长度相对的短，便于人们特别是用手重新写出来，用于指出邮政汇款单的标志。
在最佳实施例中，付款人用允许安全远程管理的任意一个用于进行货币操作的装置作为补充其“电子钱包”的源。
当在进行初次填充支付证书的操作的过程中创建支付证书基数Base时，选择专门为此创建的钥匙作为受款人的保密钥匙DP和对应的公开钥匙EP。这里，钥匙DP和EP是在在预备行动阶段确定的签名系统的主机中选择的。
在初次填充支付证书的操作中，将支付证书的基数的隐蔽标识符BaseId作为现金请求的一部分发送给支付服务器。这里，从所用的补充源远程提取资金所必需的数据也附在现金请求中。
在进行支付操作之前，用受款人的任意保密钥匙签署受款人义务数据，在付款人决定进行支付操作之前，在付款机中验证对付款人义务数据的签名的有效性，并存储签过名的受款人义务数据。
进行支付操作时的付款人指令中所包含的有关受款人的信息，含有受款人帐户的标识符以及付款的条件。将借助一个确定的单向函数处理付款人义务数据的结果附加在支付条件中。用经营者的加密钥匙对付款人指令加密。
在受款人指令中附加一个对称加密的会话钥匙，用经营者的加密钥匙对受款人指令本身加密。
把签署有经营者的保密钥匙的受款人收据附加在经营者对受款人指令的答复中，用受款人指令中含有的会话钥匙对经营者对受款人指令的答复加密。受款人按付款人收据上的签名的有效性判断付款的进行情况。
在收款机中，通过经营者对受款人指令的答复，构造并向付款机发送确定受款人同意支付操作已经成功进行的事实的数据。
将未花在付款目的上的那部分支付证书值作为找钱退还给付款机。
通过以下的例子解释上述的由第一变体实现支付的方法的最佳实施例的实现的可能性。例2
预备行动是按上述的例1中的那样进行的。
在本例中作为销售者的受款人，按如上所述的方式在银行中开立一个具有公开钥匙ES的帐户。此外，在销售者的“电子钱包”的存储设备中，建立一个具有关于所开立帐户的信息的记录，该信息含有对应于公开钥匙ES的保密钥匙DS、所开立帐户的号码AccountId以及帐户的其它属性。
本例中，付款人的“电子钱包”的补充的源是他以与受款人完全相同的方式开立的付款人帐户。付款人通过邮政汇款单把一定数量的钱汇往其开立的帐户；为明确起见，假设钱数是100美元。
付款人用所开立的帐户作为补充源，借助初次填充支付证书的操作补充其“电子钱包”。
在初次填充支付证书的操作中，通过在具有公开指数3的RSA系统的主机中选择保密签名钥匙DP和对应的公开签名钥匙EP，创建支付证书的基数。由于公开指数是固定的，该公开钥匙由一个单一的模表示。如上文指出的那样，用于创建这种钥匙的装置是众所周知的。用数据(EP，X)作为支付证书的基数(Y，X)，其中X是借助上述例1中描述的计算函数F的方法从钥匙EP中获得的。这种方法是通过根据以上对函数F的描述进行程序设计的方法而实现的。
在初次填充支付证书的操作期间，将支付证书的基数的隐蔽标识符BaseId作为现金请求的一部分发送给支付服务器。也在现金请求中附加所需的补充数额(为明确起见，假设为200美元)和付款人的帐号，并且把用付款人帐户的保密钥匙对所述请求的签名与现金请求一起发送到支付服务器。这里，付款机是在借助现金请求中指出的帐户的公开钥匙验证现金请求中含有的签名之后，从现金请求中指出的帐户的资金中补充的。
为了隐藏支付证书基数的标识符BaseId，选择一个使得L1不超过M1、L2不超过M2、L3不超过M3的等级M＝(M1，M2，M3)，其中L＝(L1，L2，L3)是在补充付款机时将在支付服务器中使用的那个保密现金钥匙的等级。要被选择的等级M取决于以美分为单位表达的所需补充数额-本例中等于20,000。在选择等级M时，假设银行所使用的保密现金钥匙的等级L按照支付系统中预先确定的规则按以下方式定义的。
首先，用现金请求中含有的所需金额以及付款人帐户上的资金，定义补充数额。本例中，截至进行补充操作的时刻，以美分为单位表达的资金的数量是19,975。该金额的形成过程如下。因将相当于邮政汇款单的200美元的20,000美分记入帐户的贷方，银行收取了数量为50美分的佣金，于是帐户上有19,950美分。在从建立有这个数额的帐户的时刻到付款机开始补充操作的时刻所经过的时间内，银行先添加数量为30美分的利息，再收取5美分帐户维持费。结果，到进行补充的操作的时刻，帐户的资金数量为19,975美分。此外，银行还因付款机补充操作而收取60美分。这样，本例中的补充数额是19,915美分。等级L是根据补充数额(本例中等于19,915美分)定义的，所借助的是支付系统中确定的规则-使得关系L1·N1＋L2·N2＋L3·N3＝19,915美分成立。本例中，L＝(1，99，15)。
在任何情况下，所确定的根据补充数额定义等级L的规则保证，在本例中，L1不超过2，而L2和L3不超过99。所以，用数据(2，99，99)作为等级M。
选择了等级M之后，将使其在初次填充支付证书期间等于支付证书基数的标识符BaseId的初始数据X，按照关系X’＝F·X(mod N)进行隐蔽，其中，F＝RU(mod N)，U＝U1·U2·U3，U1＝E1 M1、U2＝E2 M2、U3＝E3 M3，R是一个适当大小的随机整数。
在支付服务器中，将隐蔽数据X’上的用对应于等级L的保密现金钥匙的签名作为要解除隐蔽的数据S’。所以，在本例中，将数据X’用具有模N的保密现金钥匙和保密指数D＝D1 L1·D2 L2·D3 L3进行处理。之后，将数据S’发送到付款机。
在付款人的“电子钱包”中，根据所接收的要解除隐蔽的数据S’制作支付证书的签名S，方法是按照关系S＝S’·T1(mod N)，对所接收的数据S’解除隐蔽，其中，T＝RV(mod N)，T＝RV(mod N)，V＝V1·V2·V3，V1＝E1 M1-L1，V2＝E2 M2-L2，V3＝E3 M3-L3。将所制作的签名S存储在存储设备中。结果，在付款人的“电子钱包”中出现具有价值19,915美分的支付证书。
愿向销售者付43.50美元购买一些商品的付款人准备支付数据PaymentData(把它们附在用支付证书的保密现金钥匙DP签署的付款人指令PayerOrder中)和供销售者用的数据A(本例中由付款商品的名称和商品接收者的身份数据组成)。付款人指令PayerOrder的组成是支付证书的公开钥匙EP、支付证书的签名S、销售者的帐号AccountId和定义支付条件的数据C。在本例中，付款人用销售者的帐号AccountId和关于在付款的情况下有效的销售者的义务(即向具有所指出身份数据的人提供相应的商品)的文本的哈希函数H的值，作为C。
愿接受付款的销售者，建立用银行的公开加密钥匙加密的受款人指令SellerOrder＝(AccountId，PayerOrder)并把它发送到银行。
银行经过确定用过的支付证书的列表不含具有公开钥匙EP的支付证书，借助公开钥匙EP验证付款人指令PayerOrder上签名的有效性，并验证支付证书的签名S的有效性，就把一个包含公开钥匙EP和签过名的付款人指令PayerOrder输入用过的支付证书的列表中，并将43.49美元的数量记入帐号为AccountId的帐户的贷方(假设银行为进行支付操作收取1美分)。之后，银行生成一个确认将43.49美元的数量记入帐号为AccountId的帐户的贷方的事实的付款人收据，签名，并发送给销售者，销售者验证所收到收据上银行签名的有效性后，认为付款已经生效，于是通知付款人关于成功地实现支付的消息。
支付证书的其余值-本例中数量是(19,915-4,350)美分，被通过补充付款机而退还，补充既可以通过初次填充支付证书进行，也可以通过补充一个已有的支付证书进行。为此，把其价值将因所退还的值而增加的那个支付证书的隐蔽签名附加在付款人指令中，而将与其它数据一起通过收款机发送给付款机的对应的经营者的现金签名附加在经营者对受款人指令的答复中。
下面给出由第二变体实现支付的方法的最佳实施例的说明。
在由第二变体实现支付的方法的最佳实施例中，执行在由第一变体实现支付的方法的最佳实施例中执行的所有操作。
此外，我们还执行一个额外的支付证书补充操作，其实现方式，使得经营者不能区分初次填充支付证书的操作与支付证书补充操作。在支付操作之前的一个任意时刻执行支付证书补充操作，并且用于补充一个其价值不足以进行支付操作的支付证书。
上述的由第二变体实现支付的方法的最佳实施例的实现的可能性是通过上述的例2解释的，其中，解释了由第一变体实现支付的方法的最佳实施例的实现的可能性，通过以下的例3，解释了借助补充支付证书补充付款机的最佳实施例的实现的可能性。例3
本例中，我们使用上述例1中所采用的协议和记号。
支付证书补充操作，即获得一个其等级超过在补充操作开始时付款机中含有的支付证书签名的等级的支付证书签名的操作，是通过获得经营者的隐蔽现金签名而进行的。这里，我们用付款机中含有的支付证书签名作为初始数据。
假设付款人的“电子钱包”含有一个具有等级(0，2，30)的签名S1的支付证书。假设该支付证书的值(本例中等于2美元30美分)不足以让付款人购买某商品。为了设法完成购买，付款人通过补充支付证书来补充其“电子钱包”。
为此，将支付证书的隐蔽签名S1作为现金请求的一部分发送给支付服务器。也把所需的补充数额(为确定起见，等于50美元的)和付款人的帐号附在现金请求中，并把用付款人帐户的保密钥匙对所述请求的签名连同现金请求一起发送给支付服务器。这里，付款机是在借助所述帐户的公开钥匙验证现金请求中含有的签名之后，从现金请求中所指示的帐户的资金中补充的。
为了隐藏支付证书的隐蔽签名S1，如上述例2中的那样，选择一个使得L1不超过M1、L2不超过M2、L3不超过M3的等级M＝(M1，M2，M3)，其中L＝(L1，L2，L3)是在补充付款机时将在支付服务器中使用的那个保密现金钥匙的等级。像例2中那样根据所需补充数额选择等级M。本例中，M＝(0，5，99)。
如例2中的那样，用现金请求中含有的所需金额以及付款人帐户上的资金，定义补充数额。假设本例中的补充数额是47美元13美分，即4713美分。如例2中那样根据补充数额定义等级L。本例中，L＝(0，47，13)。
选择了等级M之后，将使其在初次填充支付证书期间等于支付证书基数的标识符BaseId的初始数据X，按照关系X’＝F·X(mod N)进行隐蔽，其中，F＝RU(mod N)，U＝U1·U2·U3，U1＝E1 M1、U2＝E2 M2、U3＝E3 M3，R是一个适当大小的随机整数。
在支付服务器中，将隐蔽数据X’上的用对应于等级L的保密现金钥匙的签名作为要解除隐蔽的数据S’。所以，在本例中，将数据X’用具有模N的保密现金钥匙和保密指数D＝D1 L1·D2 L2·D3 L3进行处理。之后，将数据S’发送到付款机。
在付款人的“电子钱包”中，根据所接收的要解除隐蔽的数据S’制作支付证书的签名S，方法是按照关系S＝S’·T1(mod N)，对所接收的数据S’解除隐蔽，其中，T＝RV(mod N)，V＝V1·V2·V3，V1＝E1 M1-L1，V2＝E2 M2-L2,V3＝E3 M3-L3。将所作的签名S存储在存储设备中，取代以前存储的签名S1。这里，签名S的等级等于签名S1的等级(本例中即(0，2，30))与等级L＝(0，47，13)的总和。这样，签名S的等级等于(0，49，43)，支付证书的值已经增加到49美元43美分。
以下给出由第三变体实现支付的方法的最佳实施例的说明。
预备行动、开立受款人帐户、付款机的补充和受款人在执行支付操作期间的操作，是如上述的由第一变体实现支付的方法的最佳实施例中的那样执行的。
如上述的由第一变体实现支付的方法的最佳实施例中的那样，在付款人决定进行支付操作之前，在付款机中验证受款人义务数据上签名的有效性并存储签过名的受款人义务数据。
进行支付操作时，在付款人指令中附加受款人帐户的标识符以及付款条件，作为关于受款人的信息。将借助一个确定的单向函数处理付款人义务数据的结果附加在支付条件中。用经营者的加密钥匙对付款人指令加密。
在受款人指令中附加一个对称加密的会话钥匙，用经营者的加密钥匙对受款人指令本身加密。
把签署有经营者的保密钥匙的受款人收据附加在经营者对受款人指令的答复中，用受款人指令中含有的会话钥匙对经营者对受款人指令的答复加密。受款人按付款人收据上的签名的有效性判断付款的进行情况。
在收款机中，通过经营者对受款人指令的答复，生成并向付款机发送确定受款人同意支付操作已经成功进行的事实的数据。
经营者为每个支付证书开立一个支付帐户并建立帐户与支付证书的公开钥匙的联系，支付帐户的资金是在一个或几个支付操作中花费的。这里，用公开钥匙与支付证书的公开钥匙相合的公开钥匙帐户作为支付帐户。资金出现在支付帐户上的原因是，所进行的一个或几个从支付证书含有的值的资金记入支付帐户的贷方的操作，开立支付帐户的操作是与记入这个时间上最早的帐户的贷方的操作结合进行的。
在进行记入支付帐户的贷方的操作时，向支付服务器发送一个支付证书签名-其等级可以在支付证书的等级范围内任意选择。此外，每个记入支付帐户的贷方的操作都与一个支付操作相结合。
通过以下的例子解释上述的由第三变体实现支付的方法的最佳实施例的实现的可能性。例4
本例中，我们使用例1中所采用的协议和记号。本例中，预备行动、开立销售者的帐户、付款机的补充和销售者在执行支付操作期间的操作，是如上述例2中的那样执行的。
下面给出三个支付操作的例子。这里，下述支付操作的第一个是借助支付证书的使用的最先(时间上)进行的操作，它是与开立支付帐户及其记贷的操作结合的。下述支付操作的第二个是与记入已经开立的支付帐户的贷方的操作结合的。下述支付操作的第三个是在当支付帐户上的资金足够用于进行这种支付操作的条件下进行的。
下面给出借助支付证书的使用的最先(时间上)进行的操作的说明，该操作是与开立支付帐户及其记贷的操作结合的。
假设付款机含有一个具有基数(EP，X)和等级(2，12，45)的签名S的支付证书。该支付证书的值等于212美元45美分。此外假设该支付证书尚未在支付操作中使用过。
愿向销售者付18.999美元购买一些商品的付款人准备支付数据PaymentData(把它们附在用支付证书的保密钥匙DP签署的付款人指令PayerOrder中)和供销售者用的数据A(本例中由付款商品的名称和商品接收者的身份数据组成)。
付款人指令PayerOrder的组成是支付证书的公开钥匙EP、支付证书的签名S1、销售者的帐号AccountId和定义支付条件的数据C。在本例中，付款人用销售者的帐号AccountId和关于在付款3039的情况下有效的销售者的义务(即向具有所指出身份数据的人提供相应的商品)的文本的哈希函数H的值，作为C。
付款人指令PayerOrder中含有的公开钥匙EP在支付服务器中被用于开立与该钥匙有关的支付帐户。付款人指令PayerOrder中含有的签名S1在支付服务器中被用于对具有公开钥匙EP的支付帐户记贷。
在付款机中根据支付帐户的签名S制作签名S1。这里，选择签名S1的等级L＝(L1，...，L3)的方式，一方面要使得对应于该等级的值足够用于进行当前的支付操作，另一方面要使得它的三个数量级的每个都不超过签名S的等级。这种选择的另一个目的是对经营者隐藏付款机中含有的签名S的等级。在本例中，签名S的等级由集合(2，12，45)代表，足以进行当前支付操作的以美分为单位表达的值，在本例中是1899.9美分。所以，对等级L＝(L1，...，L3)的选择的限制如下：第一，L1不超过2，L2不超过12，L3不超过45；第二，数量L1·N1＋L2·N2＋L3·N3(其中N1＝1002，N2＝100，N3＝1)必须至少是1899.9美分。满足这些条件的等级L是借助一个随机数发生器而选择的，本例中，L＝(1，3，14)。签名S1是借助一个以对应方式编程的计算设备，按照关系S＝SV(mod N)制作的，其中，V＝V1·V2·V3，V1＝E1 M1-L1，V2＝E2 M2-L2，V3＝E3 M3-L3，并且等级(M1，...，M3)等于等级(2，12，45)，即等于签名S的等级。
愿接受付款的销售者，建立用银行的公开加密钥匙加密的受款人指令SellerOrder＝(AccountId，PayerOrder)并把它发送到银行。
银行经过确定支付帐户数据库不含具有公开钥匙EP的支付帐户，并借助一个公开钥匙或保密钥匙验证签名S1的有效性，就开立一个支付帐户，并把对应的记录输入支付帐户数据库中。这里，首先将对应于签名S1的等级L＝(1，3，14)的金额(本例中即103美元14美分的金额)记入所开立帐户的贷方。此外，将50美分的金额记入所开立帐户的借方，该金额等于开立该支付帐户的收费。之后，进行实质的支付操作。就是说，在借助支付帐户的公开钥匙EP验证付款人指令PayerOrder上的签名后，银行把签过名的付款人指令PayerOrder输入信息储存库，把1899.9美分的金额记入该支付帐户的借方，并把1799.9美分的金额记入帐户为AccountId的帐户的贷方(假设银行进行支付操作的费用是1美分)。之后，生成一个确认将1799.9美分的数量记入帐号为AccountId的帐户的贷方的事实的付款人收据，签名，并发送给销售者，销售者验证所收到收据上银行签名的有效性后，认为付款已经生效，于是通知付款人关于成功地实现支付的消息。
下面给出与为已经开立的支付帐户记贷的操作相结合的支付操作的说明。一般来说，参与这个操作的受款人与上述第一种支付操作中的受款人毫不相关。
假设付款机含有一个具有基数(EP，X)和等级(2，12，45)的签名S的支付证书。该支付证书的值等于212美元45美分。假设与给定证书相关的支付帐户已经开立，该支付帐户的消费总额不超过6732.8美分的金额，并且在以前一次记贷支付帐户的操作中发送给经营者的签名的等级不超过等级(1，3，14)。于是，在这前一次记贷操作的过程中该支付帐户已经有10,314美分的金额记在贷方项下。
愿向销售者付3699.9美分购买一些商品的付款人准备支付数据PaymentData(把它们附在用支付证书的保密钥匙DP签署的付款人指令PayerOrder中)和供销售者用的数据A(本例中由付款商品的名称和商品接收者的身份数据组成)。
由于付款额超过在以前的记贷操作中发送给该帐户的10,314美分的金额与该帐户的消费总额(有6723.8美分)的差，付款人是把支付操作与记贷支付帐户的操作结合起来的。
付款人指令PayerOrder的组成是支付证书的公开钥匙的标识符-它在本例中与预先确定的哈希函数H的关于钥匙EP的值相合、支付证书的签名S1、销售者的帐号AccountId和定义支付条件的数据C。在本例中，付款人用销售者的帐号AccountId和关于在付款的情况下有效的销售者的义务(即向具有所指出身份数据的人提供相应的商品)的文本的哈希函数H的值，作为C。
在支付服务器中用付款人指令PayerOrder中含有的公开钥匙的标识符H(EP)搜索与钥匙EP有关的支付帐户。在支付服务器中用付款人指令PayerOrder中含有的签名S1为具有公开钥匙EP的支付帐户记贷。
在付款机中根据支付帐户的签名S制作签名S1。这里，选择签名S1的等级L＝(L1，...，L3)的方式，首先要使得对应于该等级的值足够用于进行考虑了早些时候付过的费用的当前支付操作，其次要使得所述等级的三个数量级的每个都不超过签名S的等级，第三要使得所述等级的三个数量级的每个都不小于在以前一次记贷支付帐户的操作中发送给经营者的签名的等级，就是说，在本例中不小于(1，3，14)。在本例中，取L＝(2，7，15)。签名S1是借助一个以对应方式编程的计算设备，按照关系S＝SV(mod N)制作的，其中，V＝V1·V2·V3，V1＝E1 M1-L1，V2＝E2 M2-L2，V3＝E3 M3-L3，并且等级(M1，...，M3)等于等级(2，12，45)，即等于签名S的等级。
愿接受付款的销售者，建立用银行的公开加密钥匙加密的受款人指令SellerOrder＝(AccountId，PayerOrder)并把它发送到银行。
银行在检测到支付帐户数据库中一个具有公开钥匙EP的支付证书的记录，并借助一个公开钥匙或保密钥匙验证签名S1的有效性后，就把所发现帐户上的总额增加到对应于其每个数量级等于在对给定支付帐户记贷的操作中发送给银行的所有支付证书的签名的等级的相应数量级中的最大数量级的等级的数额。之后，进行实质的支付操作。这个操作是如上述的第一种支付操作的例子中的那样执行的。
下面给出一种借助已经开立的支付帐户但不与为支付帐户的记贷的操作结合的支付操作的说明。一般来说，参与这个操作的受款人与上述第一种支付操作中的受款人毫不相关。
这种操作是在当付款额不超过在以前的记贷操作中发送给该帐户的金额与该帐户的消费总额的差的情况下执行的。在这种操作中，付款人指令PayOrder不含支付证书签名，但是由支付证书的公开钥匙的标识符-它在本例中与预先确定的哈希函数H的关于钥匙EP的值相符合、销售者的帐号AccountId和定义支付条件的数据C。在本例中，付款人用销售者的帐号AccountId和关于在付款的情况下有效的销售者的义务(即向具有所指出身份数据的人提供相应的商品)的文本的哈希函数H的值，作为C。在所有其它方面，这种操作是以与上述各支付操作相同的方式进行的。
下面给出由第四变体实现支付的方法的最佳实施例的说明。
在由第四变体实现支付的方法的最佳实施例中，执行在由第三变体实现支付的方法的最佳实施例中执行的所有操作。此外，还另外执行支付证书补充操作，这个操作的最佳实施例在上文中在由第二变体实现支付的方法的最佳实施例的说明中作了说明。
上述的由第四变体实现支付的方法的最佳实施例的实现的可能性是通过上述的例4解释的，其中，解释了由第三变体实现支付的方法的最佳实施例的实现的可能性，通过上述的例3，解释了借助补充支付证书补充付款机的最佳实施例的实现的可能性。
下面给出实现支付的装置的最佳实施例的说明。
在最佳实施例中，付款机含有用于通过制作经营者的隐蔽现金签名的使用而补充付款机的装置，它是用用于增加支付证书签名的等级的装置实现的。此外，付款机还含有用于开立公开钥匙帐户的装置。此外，生成一个签署有支付证书的保密钥匙的付款人指令的装置有用于生成一个要求记贷支付帐户的请求的装置，后者又有用于增加支付证书签名的等级的装置。
收款机含有用于开立公开钥匙帐户的装置和用于验证签名过的具有经营者的公开钥匙的受款人收据的装置。
支付服务器含有服务支付帐户数据库的装置和用于服务帐户数据库的装置，用于服务帐户数据库的装置有用于开立公开钥匙帐户的装置、用于记入帐户的贷方的装置和用于记入帐户的借方的装置。用于服务支付帐户数据库的装置有用于开立支付帐户的装置、用于验证现金签名的装置和用于记入支付帐户的贷方的装置。支付服务器中含有的用于进行支付操作的装置有用于验证付款人指令上的签名的装置和用于生成签过名的受款人收据的装置。此外，支付服务器还含有用于生成签过名的受款人收据的装置。
用于在付款机的、收款机的和支付服务器的存储设备中存储信息的装置可靠性高，付款机、收款机和支付服务器配备有用于对输出讯息加密的装置和用于对输入讯息解密的装置。
通过以下例子来解释上述用于实现支付和使用这种系统的装置的最佳实施例的实现的可能性。例5
该例由图1、图2和图3表示。图1表示含有支付服务器1、付款机2和收款机3的用于实现支付的装置的流程图。这里，画在各方框之间的连线表示上述设备之间通过电信网的互连。
图2表示付款机补充操作的流程图。这里，方框4表示用于通过用单向函数处理支付证书的公开钥匙而建立支付证书的基数的装置，方框5表示存储设备，连线6表示用于在存储设备中存储所创建的支付证书基数的装置，方框7表示增加支付证书签名的等级的装置，方框8表示用于生成包含隐蔽支付证书签名在内的现金请求的装置，方框9表示用于对在对现金请求的答复中包含的要解除隐蔽的数据解除隐蔽的装置，连线10表示用于将解除隐蔽的结果输入存储设备的装置，方框11表示用于处理现金请求的装置，方框12表示用于制作现金签名的装置。此外，连线13表示用于从存储设备读取支付证书签名的装置，连线14表示将现金请求发送到支付服务器时所经过的连接，连线15表示将经营者对现金请求的答复发送给付款机时所经过的连接。
图3表示支付操作的流程图。这里，方框16表示用于生成签署有支付证书的一个保密钥匙的付款人指令的装置，方框17表示用于生成包含付款人指令的受款人指令的装置，方框18表示用于验证签过名的受款人收据的装置，方框19表示用于进行支付操作的装置，方框20表示支付帐户数据库，方框21表示帐户数据库。此外，连线22表示将付款人指令发送给收款机时所经过的连接，连线23表示将受款人指令发送给支付服务器时所经过的连接，连线24表示用于进行支付操作的装置与支付帐户数据库之间的交互，连线25表示用于进行支付操作的装置与帐户数据库之间的交互，连线26表示将经营者对受款人指令的答复发送给收款机时所经过的连接。
用于实现支付的装置是通过根据上述例2和例3中指出的算法的程序设计方法实现的。特别地，所使用的加密方法，诸如制作签名、签名的验证、加密和解密，根据的是整数算术和模算术的函数。实现这类函数的例子在本领域是众所周知的。用于计算所使用的哈希函数的方法也是众所周知的。
借助图1中所示的实现支付的装置，支付按如下方式实现。
对付款机2补充任意次数。这里，可以借助初次填充支付证书和补充一个现有的支付证书这两种方法来补充付款机。在借助初次填充支付证书来补充付款机时，使用用于建立支付证书基数的装置-其中支付证书的公开钥匙被一个单向函数处理，之后，将所建立的支付证书基数通过连线6输入存储设备5，既作为支付证书的基数，也作为零等级的支付证书签名。
在一个补充付款机2的任意操作中，支付证书签名被通过连线13输入方框7中，在此将支付证书签名隐蔽，并借助方框8生成包含隐蔽的支付证书签名的现金请求。现金请求通过连线14被发送到支付服务器1，在方框11中被处理，包括借助方框12在隐蔽的支付证书签名上制作现金签名。经营者对现金请求的答复(该答复是在方框11中生成的)通过连线15被输入付款机2中，在此借助方框9把对现金请求的答复中含有的待解除隐蔽的数据解除隐蔽。解除隐蔽的数据通过连线10被输入存储设备6，作为更高等级的支付证书签名。
在进行支付操作时，在付款机2的方框16中生成签署有支付证书的保密钥匙的付款人指令。付款人指令通过连线22被输入收款机3，在方框17中生成包含付款人指令的受款人指令。受款人指令通过连线23被输入支付服务器1，在此借助方框19进行支付操作，在其过程中，从支付帐户数据库20中存储的支付帐户的资金被记入帐户数据库21中存储的受款人帐户。这里，对支付帐户的记录的读取和修改和受款人帐户的记录的读取和修改是分别通过连线24和25进行的。在方框19中生成的并包含签署有经营者的保密钥匙的签过名的受款人收据的经营者对受款人指令的答复，通过连线26被输入收款机3的方框18，签过名的受款人收据在此被验证，由此结束支付操作。实现本发明的变体
对于主张权利的实现支付的方法的每个变体来说，本发明准许这样的实施例-即能由中间付款人的资金补充付款机。在这种情况下，当付款人补充其付款机时，向中间付款人发送隐蔽数据，中间付款人对所述隐蔽数据进一步隐蔽，并相应地对其从银行接收的待解除隐蔽的数据解除隐蔽。
如果需要的话，受款人也可以控制输入的付款。这种控制目的是为了保证没有受款人的帮助任何人都不能将款项记入受款人帐户。为了行使这种控制，将受款人指令及其用受款人保密钥匙的签名发送到支付服务器，在进行支付操作期间，验证受款人指令上的签名的有效性。此外，在生成付款人指令和受款人指令时，在这些指令中加入支付条件，在进行支付操作期间，在支付服务器中控制付款人指令和受款人指令中含有的支付条件之间的对应关系。特别地，在生成支付数据时在付款机中以及在生成受款人指令时在收款机中借助一个相同的单向函数处理受款人义务数据，将通过该处理所获得的数据附加到支付数据中和受款人指令中，作为支付条件的一部分。
由每个变体实现支付的方法的可靠性是有保障的，特别是因为，如果在进行付款中所采用的操作时在通信网中有故障，这种操作可以被恢复，一直到它们成功地完成，对所牵涉的各方没有损害。
可以用付款人帐户作为在付款机补充操作中的补充源，在以前进行的支付操作中预先将款项记入该帐户的贷方-在这种操作中，付款人当时扮演的是受款人的角色。
在进行支付操作时，受款人可以扮演付款人的角色。这种支付操作可用于把付款机中的价值划转到付款人帐户中。
防止存储关于支付证书的信息的经营者数据库的过度增长的方法可以是，对补充付款机的操作收费，或者对开立与支付证书相关的支付帐户的操作收费。
经营者与支付证书相关联的货币义务可以以各种货币表达，并且，进行支付操作和付款机补充操作二者都可以与将一种货币兑换成另一种货币的操作相结合。
为了提高采用本发明的支付系统的参与者的安全性，可以对一次补充付款机的金额以及在一定时期内补充源的花费的总额作出某种限制。
在收款机与支付服务器之间、付款机与支付服务器之间以及收款机与付款机之间的讯息交流，可以以互动的方式进行。特别地，现金请求、支付数据、受款人指令和其它数据能被分部分地发送给它们的接收人。
由支付系统经营者确认其与支付证书相关联的义务的过程，除了验证经营者自己的证书签名外，还可包括验证其它数据的有效期。
此外，在补充付款机时所收到的待解除隐蔽的数据，连同允许进行这种解除隐蔽的数据，可以被用作支付证书签名，因为它们能使第三方确信存在经营者的义务。
工业应用性
本发明可用于电子排队系统，特别是那些需要通过开放式通信网进行支付的系统。在可能的应用中，本发明可用于组织支付系统、贸易系统、服务中心以及用于许多其它领域。本发明特别可用于在银行和银行系统的工作中以组织商店、证券交易、抽奖等等。

Claims (109)

1.一种用于实现支付的方法，包含以下步骤：通过一个初次填充支付证书的操作补充一个付款机-其中，在付款机中创建支付证书的基数并通过制作经营者的隐蔽现金签名而获得一个支付证书签名；进行开立受款人帐户的操作；进行支付操作-其中，将支付证书签名和支付证书基数的标识符附加到向一个收款机发送的支付数据中，通过收款机生成一个包含支付证书签名和支付证书基数的标识符的受款人指令；将所生成的受款人指令发送到一个支付服务器，根据所传送支付证书签名的有效性，如果不存在表明支付证书被使用过的信息，则在支付服务器中根据受款人指令而记贷受款人帐户；生成经营者对受款人指令的答复，通过该答复评价支付操作，其特征在于，该方法进一步包含下列步骤：将一个公开钥匙的标识符附加到支付证书基数中，所述公开钥匙对应于付款人的一个任意保密钥匙，其中接受该公开钥匙作为支付证书的一个公开钥匙，接受付款人的保密钥匙作为支付证书的一个保密钥匙；将一个签署有支付证书的保密钥匙的付款人指令附加到支付数据中，并且将关于受款人的信息和支付证书基数的标识符附加到付款人指令中；按照受款人指令上签名的有效性进行记贷受款人帐户的步骤。
2.按照权利要求1所述的方法，其特征在于，在进行支付操作的步骤中，把签过字的付款人指令输入经营者的信息储存库。
3.按照权利要求1所述的方法，其特征在于，在补充付款机的步骤中，生成一个包含用于制作隐蔽现金签名的数据的现金请求，将其发送到支付服务器，在支付服务器中按照现金请求确定补充来源和补充数额；在制作隐蔽现金签名的步骤中，通过处理该请求中含有的用于制作隐蔽现金签名的数据，创建具有一个对应于补充数额的保密钥匙的待解除隐蔽的数据，然后通过解除隐蔽而在付款机中制作支付证书签名。
4.按照权利要求3所述的方法，其特征在于，在通过初次填充支付证书的操作补充付款机的步骤中，将所创建的支付证书基数的一个隐蔽标识符作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
5.按照权利要求1所述的方法，其特征在于，在进行支付操作的步骤中，将一个受款人收据附加到经营者对受款人指令的答复中，该收据签署有经营者的任意保密钥匙，并按照受款人收据上的签名的有效性判断受款人方面的支付的进行情况。
6.按照权利要求1的方法，特征在于，在收款机中根据经营者对受款人指令的答复进行支付操作的步骤中，生成并向付款机发送数据，按照该数据判断付款人方面的支付的进行情况。
7.按照权利要求6所述的方法，其特征在于，在进行支付操作的步骤中，将一个付款人收据附加到经营者对受款人指令的答复中和向付款机发送的数据中，该收据签署有经营者的任意保密钥匙，并按照付款人收据上的签名的有效性判断付款人方面的支付的进行情况。
8.按照权利要求7所述的方法，其特征在于，先用付款人的一个任意加密钥匙对付款人收据加密，再把所述收据附加到经营者对受款人指令的答复中。
9.按照权利要求1所述的方法，其特征在于，在用支付证书进行操作时，将由一个任意单向函数转换的支付证书的一个公开钥匙用作支付证书基数的标识符。
10.按照权利要求1所述的方法，其特征在于，在用支付证书进行操作时，将支付证书的一个公开钥匙用作支付证书的公开钥匙的标识符。
11.按照权利要求1所述的方法，其特征在于，在补充付款机的步骤中，验证所制作的支付证书签名的有效性。
12.按照权利要求1所述的方法，其特征在于，在开立帐户的步骤中，接受一个任意保密钥匙作为帐户的保密钥匙，并将对应于帐户的保密钥匙的公开钥匙作为正在开立的帐户的一个公开钥匙发送给支付服务器。
13.按照权利要求1所述的方法，其特征在于，将支付条件附加到付款人指令中。
14.按照权利要求13所述的方法，其特征在于，将受款人义务数据附加到付款人指令中包含的支付条件中。
15.按照权利要求14所述的方法，其特征在于，在进行支付操作之前，用受款人的任意保密钥匙签署受款人义务数据，付款人在进行支付操作之前验证受款人义务数据上的受款人签名。
16.按照权利要求13所述的方法，其特征在于，在生成支付数据的步骤中，在付款机中由一个任意单向函数处理受款人义务数据，并将在该处理中所获得的数据作为支付条件附加到付款人指令中。
17.按照权利要求1所述的方法，其特征在于，先用经营者的一个任意公开加密钥匙对付款人指令加密，再把它们附加到支付数据中。
18.按照权利要求1所述的方法，其特征在于，在补充付款机的步骤中，用付款人的帐户作为一个补充源。
19.按照权利要求1所述的方法，其特征在于，在补充付款机的步骤中，用银行卡作为补充源。
20.按照权利要求1所述的方法，其特征在于，在进行支付操作的步骤中，受款人以付款人的角色出现。
21.按照权利要求1的所述方法，其特征在于，在进行支付操作的步骤中，将一部分支付证书值退还给付款机。
22.按照权利要求1所述的方法，其特征在于，补充付款机的步骤是用中间付款人的资金进行的。
23.按照权利要求22所述的方法，其特征在于，在补充付款机的步骤中，付款机中的被隐蔽的数据在制作经营者的隐蔽现金签名的步骤中要在中间付款人的付款机中受到附加的隐蔽。
24.一种用于实现支付的方法，包含以下步骤：通过一个初次填充支付证书的操作补充一个付款机，其中，在付款机中创建支付证书的基数并通过制作经营者的隐蔽现金签名而获得一个支付证书签名；进行开立受款人帐户的操作；进行支付操作，其中，将支付证书签名和支付证书基数的标识符附加到向一个收款机发送的支付数据中，通过收款机生成一个包含支付证书签名和支付证书基数的标识符的受款人指令；将所生成的受款人指令发送到一个支付服务器，根据所传送支付证书签名的有效性，如果不存在表明支付证书被使用过的信息，则在支付服务器中根据受款人指令而记贷受款人帐户；生成经营者对受款人指令的答复，通过该答复评价支付操作，其特征在于，该方法进一步包含下列步骤：将一个公开钥匙的标识符附加到支付证书基数中，所述公开钥匙对应于受款人的一个任意保密钥匙，其中，接受该公开钥匙作为支付证书的公开钥匙，接受受款人的保密钥匙作为支付证书的保密钥匙；通过补充支付证书的操作进行补充付款机的操作，在该操作中，在已经在付款机中的支付证书签名上的经营者的隐蔽现金签名被制作；将一个签署有支付证书的保密钥匙的付款人指令附加到支付数据中，并将关于受款人的信息和支付证书基数的标识符附加到付款人指令中；按照受款人指令上签名的有效性进行记贷受款人帐户的步骤。
25.按照权利要求24所述的方法，其特征在于，在补充付款机的步骤中，生成一个包含用于制作隐蔽现金签名的数据的现金请求，将其发送到支付服务器，在支付服务器中按照现金请求确定补充源和补充数额；在制作隐蔽现金签名的步骤中，通过处理该请求中含有的用于制作隐蔽现金签名的数据，创建具有一个对应于补充数额的保密现金钥匙的待解除隐蔽的数据，然后通过解除隐蔽而在付款机中制作支付证书签名。
26.按照权利要求25所述的方法，其特征在于，在通过初次填充支付证书的操作补充付款机的步骤中，将所创建的支付证书基数的一个隐蔽标识符作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
27.按照权利要求25所述的方法，其特征在于，在通过补充支付证书的操作补充付款机的步骤中，将一个隐蔽支付证书签名作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
28.按照权利要求24所述的方法，其特征在于，在进行支付操作的步骤中，把签过字的付款人指令输入经营者的信息储存库。
29.按照权利要求24所述的方法，其特征在于，在进行支付操作的步骤中，将一个受款人收据附加到经营者对受款人指令的答复中，该收据签署有经营者的任意保密钥匙，并按照受款人收据上的签名的有效性判断受款人方面的支付的进行情况。
30.按照权利要求24所述的方法，其特征在于，在进行支付操作的步骤中，在收款机中根据经营者对受款人指令的答复，生成并向付款机发送数据，按照该数据判断付款人方面的支付的进行情况。
31.按照权利要求30所述的方法，其特征在于，在进行支付操作的步骤中，将一个付款人收据附加到经营者对受款人指令的答复中和向付款机发送的数据中，该收据签署有经营者的任意保密钥匙，并按照付款人收据上的签名的有效性判断付款人方面的支付的进行情况。
32.按照权利要求31所述的方法，其特征在于，先用付款人的一个任意加密钥匙对付款人收据加密，再把所述收据附加到经营者对受款人指令的答复中。
33.按照权利要求24所述的方法，其特征在于，在用支付证书进行操作时，将由一个任意单向函数转换的支付证书的一个公开钥匙用作支付证书基数的标识符。
34.按照权利要求24所述的方法，其特征在于，在用支付证书进行操作时，将支付证书的一个公开钥匙用作支付证书的公开钥匙的标识符。
35.按照权利要求24所述的方法，其特征在于，在补充付款机的步骤中，验证所制作的支付证书签名的有效性。
36.按照权利要求24所述的方法，其特征在于，在开立帐户的步骤中，接受一个任意保密钥匙作为帐户的保密钥匙，并将对应于帐户的保密钥匙的公开钥匙作为正在开立的帐户的一个公开钥匙发送给支付服务器。
37.按照权利要求24所述的方法，其特征在于，将支付条件附加到付款人指令中。
38.按照权利要求37所述的方法，其特征在于，将受款人义务数据附加到包含在付款人指令中的支付条件中。
39.按照权利要求38所述的方法，其特征在于，在进行支付操作之前，受款人义务数据签署有受款人的任意保密钥匙，付款人在进行支付操作之前验证受款人义务数据上的受款人签名。
40.按照权利要求37所述的方法，其特征在于，在生成支付数据的步骤中，在付款机中由一个任意单向函数处理受款人义务数据，并将在该处理中所获得的数据作为支付条件附加到付款人指令中。
41.按照权利要求24所述的方法，其特征在于，先用经营者的一个任意公开加密钥匙对付款人指令加密，再把它们附加到支付数据中。
42.按照权利要求24所述的方法，其特征在于，在补充付款机的步骤中，用一个付款人的帐户作为一个补充源。
43.按照权利要求24所述的方法，其特征在于，在补充付款机的步骤中，用一个银行卡作为一个补充源。
44.按照权利要求24所述的方法，其特征在于，在进行支付操作的步骤中，受款人以付款人的角色出现。
45.按照权利要求24所述的方法，其特征在于，在进行支付操作的步骤中，将一部分支付证书值退还给付款机。
46.按照权利要求24所述的方法，其特征在于，补充付款机的步骤是用中间付款人的资金进行的。
47.按照权利要求46所述的方法，其特征在于，在补充付款机的步骤中，被隐蔽在付款机中的数据在制作经营者的隐蔽现金签名的步骤中要在中间付款人的付款机中受到附加的隐蔽。
48.一种用于实现支付的方法，包含以下步骤：通过一个初次填充支付证书的操作补充一个付款机，其中，在付款机中创建支付证书的基数并通过制作经营者的隐蔽现金签名而获得一个支付证书签名；进行开立受款人帐户的操作；进行支付操作，其中，将支付证书基数的标识符附加到向一个收款机发送的支付数据中，通过收款机生成一个包含从付款人处接收的支付证书基数的标识符的受款人指令；将所生成的受款人指令发送到一个支付服务器，在支付服务器中根据受款人指令记贷受款人帐户；生成一个经营者对受款人指令的答复，通过该答复评价支付操作，其特征在于，该方法进一步包含下列步骤：将一个公开钥匙的标识符附加到支付证书基数中，所述公开钥匙对应于受款人的一个任意保密钥匙，其中，接受该公开钥匙作为支付证书的一个公开钥匙，接受付款人的保密钥匙作为支付证书的一个保密钥匙；开立与支付证书基数相关联的支付帐户；进行记贷支付帐户的操作，其中，向支付服务器发送一个支付证书签名，在支付证书的等级内任意地选择所述签名的等级，并且记贷支付证书的操作是根据所发送签名的等级超过支付证书的等级的量而进行的；将一个签署有支付证书的保密钥匙的付款人指令附加到支付数据中；将关于受款人的信息和支付证书基数的标识符附加到付款人指令中；按照受款人指令上签名的有效性用支付帐户的资金进行记贷受款人帐户的步骤。
49.按照权利要求48所述的方法，其特征在于，与支付证书基数相关联的支付帐户是在进行支付操作的步骤中开立的。
50.按照权利要求48所述的方法，其特征在于，记贷操作是在进行支付操作的步骤中执行的。
51.按照权利要求48所述的方法，其特征在于，在进行支付操作的步骤中，把签过字的付款人指令输入经营者的信息储存库。
52.按照权利要求48的方法，特征在于，在补充付款机的步骤中，生成一个包含用于制作隐蔽现金签名的数据的现金请求，将其发送到支付服务器，在支付服务器中按照现金请求确定补充源和补充数额；在制作隐蔽现金签名的步骤中，通过处理该请求中含有的用于制作隐蔽现金签名的数据，创建具有一个对应于补充数额的保密钥匙的待解除隐蔽的数据，然后通过解除隐蔽而在付款机中制作支付证书签名。
53.按照权利要求52所述的方法，其特征在于，在通过初次填充支付证书的操作补充付款机的步骤中，将所创建的支付证书基数的一个隐蔽标识符作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
54.按照权利要求48所述的方法，其特征在于，在进行支付操作的步骤中，将一个受款人收据附加到经营者对受款人指令的答复中，该收据签署有经营者的任意保密钥匙，并根据受款人收据上的签名的有效性判断受款人方面的支付的进行情况。
55.按照权利要求48所述的方法，其特征在于，在进行支付操作的步骤中，在收款机中根据经营者对受款人指令的答复，生成并向付款机发送数据，按照该数据判断付款人方面的支付的进行情况。
56.按照权利要求55所述的方法，其特征在于，在进行支付操作的步骤中，将一个付款人收据附加到经营者对受款人指令的答复中和向付款机发送的数据中，该收据签署有经营者的任意保密钥匙，并按照付款人收据上的签名的有效性判断付款人方面的支付的进行情况。
57.按照权利要求56所述的方法，其特征在于，先用付款人的一个任意加密钥匙对付款人收据加密，再把所述收据附加到经营者对受款人指令的答复中。
58.按照权利要求48所述的方法，其特征在于，在用支付证书进行操作时，将由一个任意单向函数转换的支付证书的一个公开钥匙用作支付证书基数的标识符。
59.按照权利要求48所述的方法，其特征在于，在用支付证书进行操作时，将支付证书的一个公开钥匙用作支付证书的公开钥匙的标识符。
60.按照权利要求48所述的方法，其特征在于，在补充付款机的步骤中，验证所制作的支付证书签名的有效性。
61.按照权利要求48所述的方法，其特征在于，在开立帐户的步骤中，接受一个任意保密钥匙作为帐户的保密钥匙，并将对应于帐户的保密钥匙的公开钥匙作为正在开立的帐户的一个公开钥匙发送给支付服务器。
62.按照权利要求48所述的方法，其特征在于，将支付条件附加到付款人指令中。
63.按照权利要求62所述的方法，其特征在于，将受款人义务数据附加到包含在付款人指令中的支付条件中。
64.按照权利要求63所述的方法，其特征在于，在进行支付操作之前，用受款人的任意保密钥匙签署受款人义务数据，付款人在进行支付操作之前验证受款人义务数据上的受款人签名。
65.按照权利要求62所述的方法，其特征在于，在生成支付数据的步骤中，在付款机中由一个任意单向函数处理受款人义务数据，并将在该处理中所获得的数据作为支付条件附加到付款人指令中。
66.按照权利要求48所述的方法，其特征在于，先用经营者的一个任意公开加密钥匙对付款人指令加密，再把它们附加到支付数据中。
67.按照权利要求48所述的方法，其特征在于，在补充付款机的步骤中，用一个付款人的帐户作为一个补充源。
68.按照权利要求48所述的方法，其特征在于，在补充付款机的步骤中，用一个银行卡作为一个补充源。
69.按照权利要求48所述的方法，其特征在于，在进行支付操作的步骤中，受款人以付款人的角色出现。
70.按照权利要求48所述的方法，其特征在于，在进行支付操作的步骤中，将一部分支付证书值退还给付款机。
71.按照权利要求48所述的方法，其特征在于，在补充付款机的步骤中，用与支付证书其中之一的基数相关联的支付帐户作为补充源。
72.按照权利要求48所述的方法，其特征在于，补充付款机的步骤是用中间付款人的资金进行的。
73.按照权利要求72所述的方法，其特征在于，在补充付款机的步骤中，被隐蔽在付款机中的数据在制作经营者的隐蔽现金签名的步骤中要在中间付款人的付款机中受到附加的隐蔽。
74.一种用于实现支付的方法，包含以下步骤：通过一个初次填充支付证书的操作补充一个付款机，其中，在付款机中创建支付证书的基数并通过制作经营者的隐蔽现金签名而获得一个支付证书签名；进行开立受款人帐户的操作；进行支付操作，其中，将支付证书基数的标识符附加到向一个收款机发送的支付数据中，通过收款机生成一个包含从付款人接收的支付证书基数的标识符的受款人指令；将所生成的受款人指令发送到一个支付服务器，在支付服务器中根据受款人指令记贷受款人帐户；生成一个经营者对受款人指令的答复，通过该答复评价支付操作，其特征在于，该方法进一步包含下列步骤：将一个公开钥匙的标识符附加到支付证书基数中，所述公开钥匙对应于付款人的一个任意保密钥匙，其中，接受该公开钥匙作为支付证书的公开钥匙，接受付款人的保密钥匙作为支付证书的保密钥匙；通过补充支付证书的操作进行补充付款机的操作，在该操作中，在已经在付款机中的支付证书签名上制作经营者的隐蔽现金签名；开立与支付证书基数相关联的支付帐户；进行记贷支付帐户的操作，其中，向支付服务器发送一个支付证书签名，在支付证书的等级内任意地选择所述签名的等级，并且记贷支付证书的操作是根据所发送签名的等级超过支付证书的等级的量而进行的；将一个签署有支付证书的保密钥匙的付款人指令附加到支付数据中，并将关于受款人的信息和支付证书基数的标识符附加到付款人指令中；按照受款人指令上签名的有效性用支付帐户的资金进行记贷受款人帐户的步骤。
75.按照权利要求74所述的方法，其特征在于，与支付证书基数相关联的支付帐户是在进行支付操作的步骤中开立的。
76.按照权利要求74所述的方法，其特征在于，记贷操作是在进行支付操作的步骤中执行的。
77.按照权利要求74所述的方法，其特征在于，在进行支付操作的步骤中，把签过字的付款人指令输入经营者的信息储存库。
78.按照权利要求74所述的方法，其特征在于，在补充付款机的步骤中，生成一个包含用于制作隐蔽现金签名的数据的现金请求，将其发送到支付服务器，在支付服务器中按照现金请求确定补充源和补充数额；在制作隐蔽现金签名的步骤中，通过处理该请求中含有的用于制作隐蔽现金签名的数据，创建具有一个对应于补充数额的保密钥匙的待解除隐蔽的数据，然后通过解除隐蔽而在付款机中制作支付证书签名。
79.按照权利要求78所述的方法，其特征在于，在通过初次填充支付证书的操作补充付款机的步骤中，将所创建的支付证书基数的一个隐蔽标识符作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
80.按照权利要求78所述的方法，其特征在于，在通过补充支付证书的操作补充付款机的步骤中，将一个隐蔽支付证书签名作为用于制作隐蔽现金签名的数据附加到正在生成的现金请求中。
81.按照权利要求74所述的方法，其特征在于，在进行支付操作的步骤中，将一个受款人收据附加到经营者对受款人指令的答复中，该收据签署有经营者的任意保密钥匙，并按照受款人收据上的签名的有效性判断受款人方面的支付的进行情况。
82.按照权利要求74所述的方法，其特征在于，在进行支付操作的步骤中，在收款机中根据经营者对受款人指令的答复，生成并向付款机发送数据，根据该数据判断付款人方面的支付的进行情况。
83.按照权利要求82所述的方法，其特征在于，在进行支付操作的步骤中，将一个付款人收据附加到经营者对受款人指令的答复中和向付款机发送的数据中，该收据签署有经营者的任意保密钥匙，并按照付款人收据上的签名的有效性判断付款人方面的支付的进行情况。
84.按照权利要求83所述的方法，其特征在于，先用付款人的一个任意加密钥匙对付款人收据加密，再把所述收据附加到经营者对受款人指令的答复中。
85.按照权利要求74所述的方法，其特征在于，在用支付证书进行操作时，将由一个任意单向函数转换的支付证书的一个公开钥匙用作支付证书基数的标识符。
86.按照权利要求74所述的方法，其特征在于，在用支付证书进行操作时，将支付证书的一个公开钥匙用作支付证书的公开钥匙的标识符。
87.按照权利要求74所述的方法，其特征在于，在补充付款机的步骤中，验证所制作的支付证书签名的有效性。
88.按照权利要求74所述的方法，其特征在于，在开立帐户的步骤中，接受一个任意保密钥匙作为帐户的保密钥匙，并将对应于帐户的保密钥匙的公开钥匙作为正在开立的帐户的一个公开钥匙发送给支付服务器。
89.按照权利要求74所述的方法，其特征在于，将支付条件附加到付款人指令中。
90.按照权利要求89所述的方法，其特征在于，将受款人义务数据附加到包含在付款人指令中的支付条件中。
91.按照权利要求90所述的方法，其特征在于，在进行支付操作之前，用受款人的任意保密钥匙签署受款人义务数据，付款人在进行支付操作之前验证受款人义务数据上的受款人签名。
92.按照权利要求89所述的方法，其特征在于，在生成支付数据的步骤中，在付款机中由一个任意单向函数处理受款人义务数据，并将在该处理中所获得的数据作为支付条件附加到付款人指令中。
93.按照权利要求74所述的方法，其特征在于，先用经营者的一个任意公开加密钥匙对付款人指令加密，再把它们附加到支付数据中。
94.按照权利要求74所述的方法，其特征在于，在补充付款机的步骤中，用付款人的帐户作为补充源。
95.按照权利要求74所述的方法，其特征在于，在补充付款机的步骤中，用银行卡作为补充源。
96.按照权利要求74所述的方法，其特征在于，在进行支付操作的步骤中，受款人以付款人的角色出现。
97.按照权利要求74所述的方法，其特征在于，在进行支付操作的步骤中，将一部分支付证书值退还给付款机。
98.按照权利要求74所述的方法，其特征在于，在补充付款机的步骤中，用与支付证书其中之一的基数相关联的支付帐户作为补充源。
99.按照权利要求74所述的方法，其特征在于，补充付款机的步骤是用中间付款人的资金进行的。
100.按照权利要求99所述的方法，其特征在于，在补充付款机的步骤中，被隐蔽在付款机中的数据在制作经营者的隐蔽现金签名的步骤中要在中间付款人的付款机中受到附加的隐蔽。
101.一种用于实现支付的装置，包含由电信网互连的付款机、收款机和支付服务器，付款机含有用于通过制作经营者的隐蔽现金签名的使用而补充付款机的装置，支付服务器包含用于制作现金签名的装置，其特征在于，付款机进一步含有通过用单向函数处理支付证书的公开钥匙而建立支付证书的基数的装置、用于在存储设备中存储所创建的支付证书基数的装置和用于生成签署有支付证书的保密钥匙的付款人指令的装置；收款机包含用于生成包含付款人指令的受款人指令的装置；支付服务器进一步包含用于进行支付操作的装置、用于服务支付帐户数据库的装置和用于服务帐户数据库的装置，其中，所述进行支付操作的装置具有用于验证付款人指令上的签名的装置和用于制作签过字的受款人收据的装置，所述用于服务支付帐户数据库的装置具有用于验证现金签名的装置，用于通过制作经营者的隐蔽现金签名的使用而补充付款机的装置是通过用于增加支付证书签名的等级的装置实现的。
102.按照权利要求101所述的装置，其特征在于，收款机包含一种用于开立公开钥匙帐户的装置，并且所述用于服务帐户数据库的装置有一种用于开立公开钥匙帐户的装置。
103.按照权利要求101所述的装置，其特征在于，收款机包含一种用于开立公开钥匙帐户的装置，所述用于服务帐户数据库的装置具有一种用于开立公开钥匙帐户的装置。
104.按照权利要求101所述的装置，其特征在于，所述用于增加支付证书签名的等级的装置有用于生成包含隐蔽支付证书签名的现金请求的装置、用于对在对现金请求的答复中包含的待解除隐蔽的数据进行解除隐蔽的装置和用于把解除隐蔽的结果输入所述存储设备的装置，支付服务器包含用于处理现金请求的装置，其中所述用于处理现金请求的装置有用于制作现金签名的装置。
105.按照权利要求101所述的装置，其特征在于，所述用于服务支付帐户数据库的装置有一种用于开立支付帐户的装置和一种用于记贷支付帐户的装置。
106.按照权利要求101所述的装置，其特征在于，收款机有用于验证签过字的受款人收据的装置。
107.按照权利要求101所述的装置，其特征在于，所述用于生成签署有支付证书的保密钥匙的付款人指令的装置有用于生成要求记贷支付帐户的请求的装置。
108.按照权利要求101所述的装置，其特征在于，所述用于生成要求记贷支付帐户的请求的装置有用于降低支付证书签名的等级的装置。
109.按照权利要求101所述的装置，其特征在于，付款机、收款机和支付服务器进一步设有用于对输出讯息加密的装置和用于对输入讯息解密的装置。
CN99813754A 1998-11-25 1999-07-29 实现交易的方法及其装置 Pending CN1328675A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU98120922 1998-11-25
RU98120922/09A RU2157001C2 (ru) 1998-11-25 1998-11-25 Способ проведения платежей (варианты)

Publications (1)

Publication Number Publication Date
CN1328675A true CN1328675A (zh) 2001-12-26

Family

ID=20212475

Family Applications (1)

Application Number Title Priority Date Filing Date
CN99813754A Pending CN1328675A (zh) 1998-11-25 1999-07-29 实现交易的方法及其装置

Country Status (14)

Country Link
US (1) US6859795B1 (zh)
EP (1) EP1134708A1 (zh)
JP (1) JP2002530723A (zh)
CN (1) CN1328675A (zh)
AU (1) AU770762B2 (zh)
BR (1) BR9914401A (zh)
CA (1) CA2351588C (zh)
EA (1) EA002887B1 (zh)
HK (1) HK1039529A1 (zh)
IL (1) IL142052A0 (zh)
RU (1) RU2157001C2 (zh)
UA (1) UA51845C2 (zh)
WO (1) WO2000031700A1 (zh)
ZA (1) ZA200104257B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101789934B (zh) * 2009-11-17 2012-09-05 飞天诚信科技股份有限公司 网上安全交易方法和系统
CN107851252A (zh) * 2015-05-26 2018-03-27 缇零网股份有限公司 使用加密技术在交易中对意向进行模糊
CN108805542A (zh) * 2018-06-07 2018-11-13 肇庆中能创智信息科技有限公司 一种基于信息安全的区块链网络安全交易系统
US11394560B2 (en) 2015-02-09 2022-07-19 Tzero Ip, Llc Crypto integration platform

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037311A1 (en) * 2000-02-18 2001-11-01 Mccoy James Efficient internet service cost recovery system and method
SG97913A1 (en) * 2000-08-10 2003-08-20 Payment Channel Pte Ltd System and method for the prevention of unauthorized transactions using common payment instruments over a public network
EP1205889A1 (en) * 2000-11-10 2002-05-15 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Returning of change in an electronic payment system
WO2003009195A1 (fr) * 2001-07-16 2003-01-30 Dmitry Alexandrovich Gertner Structure «crafe » de protection cryptographique individuelle
RU2300844C2 (ru) * 2002-06-18 2007-06-10 Ооо "Крейф" Персональный криптозащитный комплекс
CN1628457A (zh) * 2002-06-18 2005-06-15 诺基亚公司 将信用额存入与预订通信网络的终端相关的账户的方法
JP2008512060A (ja) * 2004-08-27 2008-04-17 株式会社エヌ・ティ・ティ・ドコモ 仮署名スキーム
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
EP2056245B1 (en) * 2007-10-22 2016-12-21 Cashbutler AB Electronic currency, method for handling such a currency and electronic currency handling system
AU2009249272B2 (en) * 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
US8458477B2 (en) 2008-12-01 2013-06-04 Novell, Inc. Communication with non-repudiation
US8806214B2 (en) * 2008-12-01 2014-08-12 Novell, Inc. Communication with non-repudiation and blind signatures
CN101794401B (zh) * 2010-01-15 2012-01-25 华为终端有限公司 闪存的安全启动方法及其数据卡
WO2012116221A1 (en) 2011-02-23 2012-08-30 Mastercard International, Inc. Demand deposit account payment system
US9935951B2 (en) * 2012-07-18 2018-04-03 TapLink, Inc. Remote blind hashing
RU2012138317A (ru) * 2012-09-10 2014-03-20 Общество С Ограниченной Ответственностью "Сиайэйчрус" Фрактальная платежная система
RU2667721C1 (ru) * 2017-07-21 2018-09-24 ПУБЛИЧНОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО "БАНК "САНКТ-ПЕТЕРБУРГ" (ПАО "Банк "Санкт-Петербург") Способ сбора платежных данных и обеспечения их актуальности при проведении безналичных платежей и система для его реализации
CN107809483A (zh) * 2017-10-27 2018-03-16 大猫网络科技（北京）股份有限公司 一种交易凭证保存方法及装置
RU2716901C1 (ru) * 2018-12-24 2020-03-17 Акционерное общество "Национальная система платежных карт" Способы моментальных денежных переводов и система для реализации способов
GB2594404A (en) * 2018-12-24 2021-10-27 Akcionernoe Obschestvo Nacionalnaya Sist Platezhnykh Kart Instant money transfer methods and system for implementing same
RU2723461C1 (ru) * 2019-04-01 2020-06-11 Олег Леонидович Курнявко Способ первичной эмиссии электронно-цифровой купюры, способ вторичной эмиссии электронно-цифровой купюры, способ совершения платежа с использованием электронно-цифровой купюры

Family Cites Families (101)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4405829A (en) 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
US4206315A (en) 1978-01-04 1980-06-03 International Business Machines Corporation Digital signature system and apparatus
US4264782A (en) 1979-06-29 1981-04-28 International Business Machines Corporation Method and apparatus for transaction and identity verification
US4309569A (en) 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
US4386233A (en) 1980-09-29 1983-05-31 Smid Miles E Crytographic key notarization methods and apparatus
US4393269A (en) 1981-01-29 1983-07-12 International Business Machines Corporation Method and apparatus incorporating a one-way sequence for transaction and identity verification
US4947430A (en) 1987-11-23 1990-08-07 David Chaum Undeniable signature systems
US4759063A (en) 1983-08-22 1988-07-19 Chaum David L Blind signature systems
US4926480A (en) 1983-08-22 1990-05-15 David Chaum Card-computer moderated systems
US4759064A (en) 1985-10-07 1988-07-19 Chaum David L Blind unanticipated signature systems
US4625076A (en) 1984-03-19 1986-11-25 Nippon Telegraph & Telephone Public Corporation Signed document transmission system
US5020105A (en) 1986-06-16 1991-05-28 Applied Information Technologies Corporation Field initialized authentication system for protective security of electronic information networks
US4881264A (en) 1987-07-30 1989-11-14 Merkle Ralph C Digital signature system and method based on a conventional encryption function
US5140634A (en) 1987-09-07 1992-08-18 U.S Philips Corporation Method and apparatus for authenticating accreditations and for authenticating and signing messages
US4893338A (en) 1987-12-31 1990-01-09 Pitney Bowes Inc. System for conveying information for the reliable authentification of a plurality of documents
US4933970A (en) 1988-01-19 1990-06-12 Yeda Research And Development Company Limited Variants of the fiat-shamir identification and signature scheme
US5005200A (en) 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5214702A (en) 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US4914698A (en) 1988-03-16 1990-04-03 David Chaum One-show blind signature systems
US4987593A (en) * 1988-03-16 1991-01-22 David Chaum One-show blind signature systems
US4926479A (en) 1988-04-29 1990-05-15 Massachusetts Institute Of Technology Multiprover interactive verification system
US4969189A (en) 1988-06-25 1990-11-06 Nippon Telegraph & Telephone Corporation Authentication system and apparatus therefor
GB8819767D0 (en) 1988-08-19 1989-07-05 Ncr Co Public key diversification method
US4949380A (en) 1988-10-20 1990-08-14 David Chaum Returned-value blind signature systems
US5016274A (en) 1988-11-08 1991-05-14 Silvio Micali On-line/off-line digital signing
EP0383985A1 (de) 1989-02-24 1990-08-29 Claus Peter Prof. Dr. Schnorr Verfahren zur Identifikation von Teilnehmern sowie zur Generierung und Verifikation von elektronischen Unterschriften in einem Datenaustauschsystem
US4977595A (en) 1989-04-03 1990-12-11 Nippon Telegraph And Telephone Corporation Method and apparatus for implementing electronic cash
US4991210A (en) 1989-05-04 1991-02-05 David Chaum Unpredictable blind signature systems
US4996711A (en) 1989-06-21 1991-02-26 Chaum David L Selected-exponent signature systems
DE69031614T2 (de) 1990-01-29 1998-05-07 Security Techn Corp Wahlweise moderierte Transaktionssysteme
EP0484603B1 (en) 1990-11-09 1995-09-13 International Business Machines Corporation Non-repudiation in computer networks
US5195133A (en) 1991-01-11 1993-03-16 Ncr Corporation Apparatus and method for producing a digitized transaction record including an encrypted signature
EP0502559A3 (en) 1991-02-07 1992-10-14 Thomson Consumer Electronics S.A. Method, identification device and verification device for identification and/or performing digital signature
US5295188A (en) 1991-04-04 1994-03-15 Wilson William J Public key encryption and decryption circuitry and method
US5224162A (en) 1991-06-14 1993-06-29 Nippon Telegraph And Telephone Corporation Electronic cash system
JP2671649B2 (ja) 1991-07-08 1997-10-29 三菱電機株式会社 認証方式
US5453601A (en) 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US5557518A (en) 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5297206A (en) 1992-03-19 1994-03-22 Orton Glenn A Cryptographic method for communication and electronic signatures
IL101623A (en) 1992-04-16 1997-06-10 Fortress U & T 2000 Ltd Digital signature device
US5315658B1 (en) 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
US5231666A (en) 1992-04-20 1993-07-27 International Business Machines Corporation Cryptographic method for updating financial records
US5299262A (en) 1992-08-13 1994-03-29 The United States Of America As Represented By The United States Department Of Energy Method for exponentiating in cryptographic systems
US5396558A (en) 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
US5442707A (en) 1992-09-28 1995-08-15 Matsushita Electric Industrial Co., Ltd. Method for generating and verifying electronic signatures and privacy communication using elliptic curves
US5627893A (en) 1992-12-22 1997-05-06 Telstra Corporation Limited Cryptographic method
US5734901A (en) 1993-02-26 1998-03-31 Apple Computer, Inc. Electronic mail information associated with native application data
US5373558A (en) 1993-05-25 1994-12-13 Chaum; David Desinated-confirmer signature systems
US5475763A (en) 1993-07-01 1995-12-12 Digital Equipment Corp., Patent Law Group Method of deriving a per-message signature for a DSS or El Gamal encryption system
NL9301348A (nl) * 1993-08-02 1995-03-01 Stefanus Alfonsus Brands Elektronisch betalingssysteem.
US5485520A (en) 1993-10-07 1996-01-16 Amtech Corporation Automatic real-time highway toll collection from moving vehicles
FR2713419B1 (fr) 1993-12-02 1996-07-05 Gemplus Card Int Procédé de génération de signatures DSA avec des appareils portables à bas coûts.
JP2762909B2 (ja) 1993-12-27 1998-06-11 日本電気株式会社 電子署名装置
FR2714780B1 (fr) 1993-12-30 1996-01-26 Stern Jacques Procédé d'authentification d'au moins un dispositif d'identification par un dispositif de vérification.
US5420926A (en) 1994-01-05 1995-05-30 At&T Corp. Anonymous credit card transactions
US5434919A (en) 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
AU1680395A (en) 1994-01-13 1995-08-01 Bankers Trust Company Cryptographic system and method with key escrow feature
US5825880A (en) 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
US5537475A (en) 1994-02-01 1996-07-16 Micali; Silvio Efficient digital signature algorithm and use thereof technical field
US5712913A (en) 1994-02-08 1998-01-27 Digicash Incorporated Limited-traceability systems
US5511121A (en) * 1994-02-23 1996-04-23 Bell Communications Research, Inc. Efficient electronic money
US5668878A (en) 1994-02-28 1997-09-16 Brands; Stefanus Alfonsus Secure cryptographic methods for electronic transfer of information
US5604805A (en) 1994-02-28 1997-02-18 Brands; Stefanus A. Privacy-protected transfer of electronic information
FR2718311A1 (fr) * 1994-03-30 1995-10-06 Trt Telecom Radio Electr Dispositif de mise en Óoeuvre d'un système de signature de message et carte à puce comportant un tel dispositif.
KR0144086B1 (ko) 1994-03-31 1998-08-17 조백제 인증교환과 전자서명 방법
US5799087A (en) 1994-04-28 1998-08-25 Citibank, N.A. Electronic-monetary system
US5493614A (en) 1994-05-03 1996-02-20 Chaum; David Private signature and proof systems
AU698454B2 (en) 1994-07-19 1998-10-29 Certco Llc Method for securely using digital signatures in a commercial cryptographic system
US5588061A (en) 1994-07-20 1996-12-24 Bell Atlantic Network Services, Inc. System and method for identity verification, forming joint signatures and session key agreement in an RSA public cryptosystem
EP0695056B1 (en) 1994-07-29 2005-05-11 Canon Kabushiki Kaisha A method for sharing secret information, generating a digital signature, and performing certification in a communication system that has a plurality of information processing apparatuses and a communication system that employs such a method
US5606617A (en) 1994-10-14 1997-02-25 Brands; Stefanus A. Secret-key certificates
US5715314A (en) 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
JP3614480B2 (ja) 1994-11-18 2005-01-26 株式会社日立製作所 電子チケット販売・払戻システム及びその販売・払戻方法
DE69532028T2 (de) * 1994-12-13 2004-06-24 Mitsubishi Corp. Verschlüsselungssystem für sichere elektronische Transaktionen
US5790667A (en) 1995-01-20 1998-08-04 Matsushita Electric Industrial Co., Ltd. Personal authentication method
US5625692A (en) 1995-01-23 1997-04-29 International Business Machines Corporation Method and system for a public key cryptosystem having proactive, robust, and recoverable distributed threshold secret sharing
US5564106A (en) 1995-03-09 1996-10-08 Motorola, Inc. Method for providing blind access to an encryption key
US5577124A (en) 1995-03-09 1996-11-19 Arithmetica, Inc. Multi-purpose high speed cryptographically secure sequence generator based on zeta-one-way functions
US5553145A (en) 1995-03-21 1996-09-03 Micali; Silvia Simultaneous electronic transactions with visible trusted parties
US5590197A (en) 1995-04-04 1996-12-31 V-One Corporation Electronic payment system and method
US5677955A (en) 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5832089A (en) 1995-06-07 1998-11-03 Sandia Corporation Off-line compatible electronic cash method and system
US5790677A (en) 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
JP3435677B2 (ja) * 1995-07-17 2003-08-11 日本電信電話株式会社 追跡可能な電子現金実施方法及びその装置
FR2737370B1 (fr) 1995-07-27 1997-08-22 Bull Cp8 Procede de communication cryptographique
US5768385A (en) * 1995-08-29 1998-06-16 Microsoft Corporation Untraceable electronic cash
US5633929A (en) 1995-09-15 1997-05-27 Rsa Data Security, Inc Cryptographic key escrow system having reduced vulnerability to harvesting attacks
US5638445A (en) 1995-09-19 1997-06-10 Microsoft Corporation Blind encryption
US5805702A (en) 1995-09-29 1998-09-08 Dallas Semiconductor Corporation Method, apparatus, and system for transferring units of value
US5671285A (en) 1995-12-13 1997-09-23 Newman; Bruce D. Secure communication system
US5812670A (en) 1995-12-28 1998-09-22 Micali; Silvio Traceable anonymous transactions
US5615269A (en) 1996-02-22 1997-03-25 Micali; Silvio Ideal electronic negotiations
US5768388A (en) 1996-03-01 1998-06-16 Goldwasser; Shafi Time delayed key escrow
US5638447A (en) 1996-05-15 1997-06-10 Micali; Silvio Compact digital signatures
US5610982A (en) 1996-05-15 1997-03-11 Micali; Silvio Compact certification with threshold signatures
US6072870A (en) * 1996-06-17 2000-06-06 Verifone Inc. System, method and article of manufacture for a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US5825884A (en) 1996-07-01 1998-10-20 Thomson Consumer Electronics Method and apparatus for operating a transactional server in a proprietary database environment
CA2261947C (en) 1996-08-07 2008-11-18 Silvio Micali Simultaneous electronic transactions with visible trusted parties
JP3599492B2 (ja) * 1996-09-10 2004-12-08 日本電信電話株式会社 番号登録式電子現金方法および利用者装置
JP3599493B2 (ja) * 1996-09-10 2004-12-08 日本銀行 発行機関分離型番号登録式電子現金方法および利用者装置
US5806063A (en) 1996-10-03 1998-09-08 Mcdonnell Douglas Corporation Date formatting and sorting for dates spanning the turn of the century

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101789934B (zh) * 2009-11-17 2012-09-05 飞天诚信科技股份有限公司 网上安全交易方法和系统
US11394560B2 (en) 2015-02-09 2022-07-19 Tzero Ip, Llc Crypto integration platform
CN107851252A (zh) * 2015-05-26 2018-03-27 缇零网股份有限公司 使用加密技术在交易中对意向进行模糊
CN107851252B (zh) * 2015-05-26 2022-07-19 缇零知识产权有限责任公司 使用加密技术在交易中对意向进行模糊
CN108805542A (zh) * 2018-06-07 2018-11-13 肇庆中能创智信息科技有限公司 一种基于信息安全的区块链网络安全交易系统

Also Published As

Publication number Publication date
RU2157001C2 (ru) 2000-09-27
IL142052A0 (en) 2002-03-10
EP1134708A1 (en) 2001-09-19
UA51845C2 (uk) 2002-12-16
EA002887B1 (ru) 2002-10-31
CA2351588C (en) 2008-07-15
JP2002530723A (ja) 2002-09-17
AU5310899A (en) 2000-06-13
EA200001234A1 (ru) 2001-08-27
ZA200104257B (en) 2002-05-17
WO2000031700A1 (fr) 2000-06-02
BR9914401A (pt) 2001-06-26
US6859795B1 (en) 2005-02-22
HK1039529A1 (zh) 2002-04-26
AU770762B2 (en) 2004-03-04
CA2351588A1 (en) 2000-06-02

Similar Documents

Publication Publication Date Title
CN1328675A (zh) 实现交易的方法及其装置
CN1201609C (zh) 通过移动电话实时远程付款和交易的系统和处理方法
CN1140088C (zh) 计算设备、信息处理系统和计算方法
CN1155919C (zh) 用移动设备的事务处理方法
CN1535440A (zh) 用于微支付交易的方法和系统
JP5130039B2 (ja) 送受信料金を伴う金融トランザクション
US10318936B2 (en) System and method for transferring funds
CN1185851A (zh) 电子货币系统
US20230169585A1 (en) System for disclosing deposit account information that can be virtual currency address
CN1259215A (zh) 可计数的电子货币系统及其方法
CN1930591A (zh) 多方受益的在线认证服务
CN1635525A (zh) 一种安全的网上支付系统及安全的网上支付认证方法
US20070215689A1 (en) Money transfers using digital cash
CN1454364A (zh) 处理因特网支付的方法与系统
CN101069204A (zh) 提供进行电子交易的现金和现金等价物的方法
CN1340784A (zh) 允许通过消费者设备使用智能卡进行网络商务
CN1313973A (zh) 认证付款系统
CN1781119A (zh) 用于标识、管理和控制通信的方法及设备
CN101079141A (zh) 用于自动确认交易的方法以及电子支付系统
CN1669035A (zh) 用于产权交易网络的方法和设备
CN1304111A (zh) 电子结算系统及其电子结算方法
US10970688B2 (en) System and method for transferring funds
CN111062717A (zh) 一种数据转移处理方法、装置和计算机可读存储介质
CN1134753C (zh) 用于安全电子商务交易的货物发送的控制和确认及用于关于所述交易的支付的执行的并行控制和确认的设备
CN1882963A (zh) 交易验证系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication
REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1039529

Country of ref document: HK