CN101010690A - 支付处理方法和*** - Google Patents

支付处理方法和*** Download PDF

Info

Publication number
CN101010690A
CN101010690A CNA2005800286811A CN200580028681A CN101010690A CN 101010690 A CN101010690 A CN 101010690A CN A2005800286811 A CNA2005800286811 A CN A2005800286811A CN 200580028681 A CN200580028681 A CN 200580028681A CN 101010690 A CN101010690 A CN 101010690A
Authority
CN
China
Prior art keywords
dealer
transaction
payment
user
consumer
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
CNA2005800286811A
Other languages
English (en)
Inventor
R·P·尼克斯
A·默萨罗维奇
T·施沃特茨
J·杉克特
P·马斯特斯
C·克罗福特
J·蒙塔纳罗
R·L·里维斯特
S·米卡利
J·伯格朗
V·乔纳落加达
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.)
Peppercoin Inc
Original Assignee
Peppercoin Inc
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 Peppercoin Inc filed Critical Peppercoin Inc
Publication of CN101010690A publication Critical patent/CN101010690A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付处理***包括一个交易处理机，其将消费者和销售商之间的小额销售交易的相关费用数据合并在一起。该交易处理机将代表合并后的费用数据的数据发送到与该销售商相关联的收单金融实体。该***还包括另一交易处理机存储代表各个单独的小额销售交易的数据。所存储的数据可以被与该销售商相关联的一个或多个金融实体访问到。

Description

支付处理方法和***
相关申请
本申请主张下列申请的优先权：(a)U.S.临时申请号：60/583,010,2004年6月25日提交，题为“Small Payment GatewayMethod and System”；(b)U.S.临时申请号：60/648,789,2005年2月1日提交，题为“Edge Process for Small Transaction Methodand System”。
技术领域
本公开涉及处理支付，尤其是处理小额购物以降低交易成本。
背景技术
随着***和借记卡的引入以及它们在市场中越来越多的使用，产业趋势表明这些工具正在成为越来越多的消费者的首选。在2003年，消费者用电子支付方法进行的支付首次超过使用现金或基于支票的支付方法进行的支付。调查发现超过3千7百万美国人已经用卡进行小于等于5美元的销售点(POS，point of sale)购物，并且用卡购买在线内容的美国人在不到一年中已经从4百万增加到了1千4百万。另外，正在布署的基于射频识别(RFID，radio frequencyidentification)的无接触支付卡将加速这种消费者趋势。
物理POS、数字和移动市场中小额支付的数量正在以令人吃惊的速度增长。在美国5美元以下的现金支付超过了1.3万亿；数字支付超过30亿美元，并且复合年增长率(CAGR，compound annual growthrate)超过20％；移动支付超过5亿美元，CAGR＞100％；世界范围的机会甚至更大。
尽管在小额支付业务模式中有实际的销售商兴趣，但潜在的问题可能会妨碍基于小额支付的可赢利业务的产生。例如，高交易处理成本会对业务赢利能力产生负面影响。典型的交易处理成本是0.25美元再加上交易额的2％。对于1美元的小额交易，交易处理成本是0.27美元或者交易额的27％。对于为销售商支持可赢利的业务来说，这是一个实实在在的交易成本。一些金融业消息来源报告说总体的交易处理成本是0.20到0.40美元，并且企业在低于10美元的交易上会赔钱。
伴随着交易成本，客户支持成本对于收入和赢利也有实际影响。对于电话支持来说，常规的客户服务成本通常是每个事件5到10美元，对于导致退款的与支付有关的支持，每个事件的服务成本是15到30美元。提供高质量的客户支持是发展并增加业务的一个关键部分，但是，高客户支持成本会降低赢利能力。
客户购买成本可能和终身客户的价值无关。销售商可能引入大量的推销成本以吸引并留住客户。例如，广告开支的范围在快餐店每个客户2到4美元到互联网业务每个客户20到40美元之间。为了解决这些问题，销售商对于形成频繁的消费者购物的灵活且低成本的方式非常感兴趣。例如，销售商可能生产引人注目的新产品和服务、实现无争议策略、建立集成的忠实和奖励程序或者启动有目标的促销(有时和第三方伙伴一起)。
发明内容
根据本发明的一个方面，一种支付处理***包括一个交易处理机，其将消费者和销售商之间的小额销售交易相关的费用数据合并在一起。该交易处理机将表示总费用数据的数据发送到与该销售商相关的收单金融实体(acquiring banking entity)。该***还包括另一交易处理机存储表示各个单独的小额销售交易的数据。所存储的数据可以由与该销售商相关的一个或多个金融实体访问。
在一种实施例中，第二个交易处理机可以位于远离消费者和销售商的地方。第一个交易处理机可以进行多种类型的合并。例如，该处理机可以将一个销售商和至少两个消费者之间的小额销售交易的相关费用数据合并在一起或者将与两个或多个销售商相关的小额销售交易的相关费用数据合并在一起。在销售商和消费者之间可以实现各种不同的支付方法。例如，消费者可以采用按使用计费、预付费、订购、后付费或其它方式向销售商支付小额销售交易。所存储的表示各个单独的小额销售交易的数据可以由各个不同的金融实体访问，如收单金融实体或与消费者相关的发卡金融实体(issuing banking entity)。所存储的表示各个单独的小额销售交易的数据还可由消费者访问。为了提供消费者服务，第一交易处理机可以将消费者请求转发到第二交易处理机以提供消费者服务。每个处理机可以位于不同的位置。例如，第一交易处理机可以位于与消费者相关的发卡金融实体。该支付处理***还可包括第三个交易处理机跟踪至少一个小额销售交易的支付核对(reconciling)。这个第三交易处理机可以位于一个收单金融实体。该***还可包括第四交易处理机，它将总费用数据转换成第三方的格式。这个第四交易处理机可以位于包括第一交易处理机的服务器中。在该支付处理***中可以包括安全方法。例如，所存储的表示各个单独的小额销售交易的数据可以包括与一个或多个交易相关的帐号的单向散列。相应地，为了访问可以给所存储的数据解密。小额销售交易中的一个或多个可以发生在售货机设备中。该支付处理***还可以包括一个第三交易处理机将该消费者和另一销售商之间的小额销售交易相关的数据合并在一起。在一些实施例中，销售商可以向消费者提供优先处理以鼓励与该销售商的未来交易。
根据本发明的另一方面，一种处理支付的方法包括接收表示消费者和销售商之间的一个小额交易的数据。该方法还包括将该小额销售交易的费用和该消费者和该销售商之间另一小额销售交易的费用合并在一起。此外，该方法包括存储与各个小额销售交易相关的数据以使该数据可以由与该销售商相关的一个或多个金融实体访问。该方法还包括将表示总费用的数据发送到与该销售商相关的收单金融实体。
在一种实施例中，该方法还包括将与该消费者相关的小额销售交易的费用和另一消费者的相关小额销售交易的费用合并在一起。此外，该方法可以包括将与一个销售商相关的小额销售交易的费用和另一销售商的相关小额销售交易的费用合并在一起，其中这两个销售商都与该收单金融实体相关。
根据本公开的另一方面，驻留在计算机可读介质上的一种计算机程序产品所包括的指令当由一个处理器执行时使该处理器接收表示一个消费者和一个销售商之间的一个小额销售交易的数据。另外的指令使该处理器将该小额销售交易的费用和该消费者与该销售商之间另一小额销售交易的费用合并在一起。这些指令还使该处理器存储与各个小额销售交易相关的数据以使这些数据可以由与该销售商相关的一个或多个金融实体访问。另外，这些指令还使该处理器将表示总费用的数据发送到与该销售商相关的收单金融实体。
在一种实施例中，该计算机程序产品可以包括额外的指令以将与一个消费者相关的小额销售交易的费用和另一消费者的相关小额销售交易的费用合并在一起。还可以包括将与一个销售商相关的小额销售交易的费用和另一销售商的相关小额销售交易的费用合并在一起的指令。
本领域的技术人员从下面的详细说明将明了本发明的更多优势和方面，在下面的详细说明中通过对实施本发明所期望的最佳模式的说明展示并说明了本发明的实施例。将会说明，本公开可以有其它不同的实施例，并且只要不偏离本公开的精神，它的若干细节在各个明显的方面可以进行修改。因此，附图和说明在本质上将被看作是说明性而非限制性。
附图说明
图1是表示一个大规模支付***的结构图；
图2中所示结构图表示图1中所示大规模支付***中为降低交易成本的处理机分布；
图3中所示结构图表示包括分布式处理机的服务器的位置；
图4中所示结构图表示分布式处理机中包括的功能模块；
图5中所示结构图表示分布式处理机中可以包括的功能模块；
图6中所示流程图表示与小额交易相关的操作；
图7中所示结构图表示在分布式处理机之间执行的与单个销售商相关的操作；
图8中所示结构图表示在分布式处理机之间执行的与多个销售商相关的操作；
图9是表示Merkle树的结构图；
图10所示结构图表示可以包括在每个分布式处理机中的路由确定程序；
图11是表示分布式处理机的一个结点的结构图；
图12表示记帐报表及图形用户界面的一部分；
图13表示提供交易分解的图形用户界面；
图14表示识别单个交易的图形用户界面；
图15表示与客户服务相关的图形用户界面；
图16表示从客户接收服务请求的相关图形用户界面；
图17表示将客户请求提供给服务供应商的图形用户界面；
图18表示提供合并在一起的小额交易信息的图形用户界面。
具体实施方式
参考图1，所示大规模支付处理***10实实在在地降低了小额购物的交易成本。所示例子包括从销售商购买商品和/或服务的消费者。一个被称为收单银行的金融机构向销售商提供一个用于接收付款的帐户。另一被称为发卡银行的金融机构向消费者提供用于进行电子支付的工具(如***、借记卡、预付卡，等等)。一个也被称为卡网络的协会管理发卡银行和收单银行之间的关系。在有些方案中，被称为处理机的第三方处理销售商、收单银行、发卡银行和协会之间的交易。贯穿本发明，金融服务机构(即收单银行、发卡银行、协会和处理机)可以被称为FSI。
通过产生并发布使销售商、收单银行、发卡银行、处理机和协会能够在小额支付上投资的支付应用程序，可以调节广大消费者对***和借记卡的信任和偏好。为此，在与销售商通信的服务器14上执行小额交易处理机12。小额交易处理机12可以用硬件、软件或软件结合实现，它被设计用来通过扩展现有的支付基础结构优化小额交易处理的收入和赢利。
在有些方案中，小额交易处理机12是可扩展的处理平台，它使销售商、收单银行、发卡银行、处理机和协会能够通过小额支付成长和发展。通过高效、经济地处理小额交易，小额交易处理机12通过合并相关购物可以实实在在地降低小额购物的交易成本。小额交易处理机12还允许消费者用它们优选的支付工具(如***、借记卡，等等)进行购物。通过在数字、移动和物理POS环境中运行，小额交易处理机12可以作为***网关无缝集成到销售商购物体验中，而对消费者的购物体验则没有任何可见的变化。通过它的运行，给予了销售商一个工具以通过可能的业务模式(按使用支付、预付费、预订和后付费)的混合与它们的客户构建可赢利的关系。小额交易处理机12还可以通过集成帐单投递和争议解决提高客户满意度并降低客户服务成本。伴随着更低的交易成本，小额交易处理机12的使用可以为小额支付市场带来低成本的忠诚度、促销和欺诈管理技术。
小额交易处理机12为支付处理***10中所包括的各方带来了利益。例如，通常消费者希望购物的灵活性。它们想控制买什么、何时买以及如何支付。但销售商频繁地对小额支付限制卡的使用，并且最终不能提供消费者想要的方便。销售商想让消费者购买他们的商品和/或服务更容易。但对于更小的交易，卡处理及客户服务成本吃掉了销售商的很多(如果不是全部的话)利润。当消费者使用它们首选的***或借记卡支付小额商品时，销售商的收入会消失。
小额交易处理机12的运行实际上对消费者是不可见的。消费者不需要下载软件、建立帐号或对帐号预先充值、或者花最少的钱来购物。但是，消费者可以相对快速地在线检查他们的交易。对于消费者来说，支付处理***10允许他们用他们已经拥有的受信赖的和首选的支付机制(卡)进行小额购物。该***让他们能够在用各种不同类型的业务模式(如按使用付费、预付费、预定或后付费)进行购物的同时方便地接触小额的数字、移动和物理POS商品和服务。
另外，销售商想要向消费者提供合乎需要的商品和便利。通过提供灵活的支付选项，支付处理***10提供了方便。销售商还喜欢为所有的购物提供大范围的支付选择，而高昂的交易处理和客户服务费用使得销售商在小额的***和借记卡购物中无法获取利润。
支付处理***10使得小额购物成为可赢利的交易。该***降低了与小额和微额支付相关的两个主要成本-交易处理成本和客户服务成本。支付处理***10用合并方法处理交易成本。通过允许销售商将小额支付合并在一起，并修改和调节合并设置，该***提高了效率。在一种方案中，支付处理***10的一些部分被(通过Internet)在线实现。在这种方案中，提供了自动化的客户服务以便用相对较低的成本提供及时的客户服务。支付处理***10还允许销售商构思优化消费者承兑的业务-模式提供。
对于销售商来说，支付处理***10帮助销售商通过低价商品和服务增长他们的顶线(收入)和他们的底线(利润)。该***还通过支付按使用付费、预订、预付费和后付费方案而提供了业务模式灵活性。另外还为销售商带来了低成本的客户自服的成本和客户满意效益。
收单银行和支付处理机可能对提供满足销售商客户需要的产品并提高整体的交易量感兴趣。但是，收单银行和处理机通常已经不能向销售商提供低成本的小额支付解决方案。不相称的是与传统支付处理相关的高度固定和变化的费用对销售商的利润率有着不利的影响。像实现预付费卡和最小购物量的使用等替代方案可能对消费者带来经济或时间上的不便。
通过引入小额交易处理机12，处理机和收单银行能够为销售商带来可赢利的新的业务模式。销售商可以为小额和微额交易接受优选的支付工具(***和借记卡)并仍然可以赢利。随着新型交易流经该***，处理量会增长，并且随之收单银行和处理机的收入也增长。通常，小额交易处理机12可以被集成进现有的处理***以及该处理机的销售商的***中。对于收单银行和处理机来说，支付处理***10可以增加带来收入和赢利的交易流量。
发卡银行希望它们的卡在持卡人进行交易时总是处在“钱包最上面”(top of wallet，即总是被优先使用)。但对小额购物来说，高处理成本和高客户服务成本妨碍了(数字的和物理的)销售商接受***和借记卡。结果，收单银行会将失去市场份额给现金和别的支付***。
利用支付处理***10的功能，发卡银行的持卡人可以享受到用卡而不是现金购买低价商品所带来的方便。购买过程熟悉且快速，并且不需要任何帐户注册。带有它的合并功能的支付处理***10可以降低发卡银行对小额支付的客户服务成本。在一些常规***中，实时客户服务响应每次事件可能耗费高达10美元，尤其是对于低利润的小额支付。对小额支付维持这样昂贵的客户服务是没有意义的。支付处理***10提供了特别为小额支付设计的在线客户自服，它能够以相对较低的成本提供及时的服务。对于发卡银行来说，支付处理***10将现金和支票开销转换成卡，由此提高了交易流。小额交易提高了消费者进行交易的频率、为消费者使用的卡带来了“钱包最上面”的市场份额增益。支付处理***10用在线客户自服降低了成本。另外，合并经济学的一些经济特征消除了对面向小额支付的发行产品(如无接触支付卡)的销售商转出的阻碍。
通常，当前对交易处理的标准费用结构阻碍了可以赢利的小额支付的可能性。没有回应，卡网络会丢失一部分快速增长的低价数字商品市场。
支付处理***10使得持卡人和销售商能够对低价商品进行并接受卡支付而不是现金支付。消费者会感觉到更方便，因为购物过程仍然熟悉和相对快速，并且只需要最少的(如果有的话)帐户注册。支付处理***10通过降低小额支付的客户服务成本帮助了卡协会成员。通常，传统的实时客户服务响应和退款费用非常高，尤其是对低利润的小额支付。相反，支付处理***10提供了天生的在线客户自服，尤其对于小额支付，在线客户自服被设计用来以相对较低的成本提供及时的客户服务。
支付处理***10通过将低额现金和支票支付转换成卡支付而增加了交易流。该***还保护卡支付***免于来自竞争支付形式的入场许可。此外，在卡网络中使得可赢利的小额支付成为可能。
参考图2，小额支付处理机12可以被部署为支付处理***10中单方拥有和运行的软件产品，或者它可以被多方用作外包服务。
通常，小额支付处理机12包括的功能有提供小额支付网关以将支付从销售商传输到支付处理***10中。支付处理***10还提供了在线客户自服，它可以被独立于先前存在的销售商服务接口实现或者被实现在其中。支付处理***10还包括一个客户帐户处理机16和一个销售商帐户处理机18，它们帮助进行合并操作(例如，来自单个销售商的交易的合并)。另外，处理机12、16和18提供了调整合并参数以及允许销售商实际优化交易成本、交换资格、现金流和客户服务的功能。处理机12、16和18中的一个或多个还可以包括通过发卡行进行合并的技术。
支付处理***10的设计上的灵活性为大容量交易存储和处理环境中的实现做好了准备。例如，销售商帐户处理机18可以被设计用来为收单银行和它们的处理机提供销售商帐户服务。消费者帐户处理机16还可以为发卡银行和它们的处理机提供服务功能。支付处理***10还可以被设计用来使FSI能够通过低成本、安全、分布式的审计维持对分布式处理的控制。
支付处理***10的设计解决了扩展性、可靠性和安全性等设计概念。例如，可以用1000或更大的比例因子设计小额交易处理机12以处理小额交易经济的本质部分。伴随着可扩展性，可以将多级安全性实现到支付处理***10中以解决***内外的安全性问题。通过实现可扩展的设计，可以在以后引入附加功能以解决销售商和消费者的顾虑。
参考图3，在各个服务器14、20和22中包括了小额交易处理机12、消费者帐户处理机16和销售商帐户处理机18.在这种配置中，服务器14、20和22分别位于发卡行、收单行和销售商外的位置。但是，在其它方案中，服务器和处理机可以位于其它地点。此外，在这种方案中，大额支付处理机24(下面详细说明)被执行在服务器14上。
小额交易处理机12处理小额交易并为授权、收取、销售、存入和取消交易提供传统的支付卡网关接口。小额交易处理机12为销售商的金融管理和支付调节、客户服务及销售管理存储小额交易数据。小额交易处理机12还为消费者提供详细的自服务接口。小额交易处理机12可以被设计用来在销售商的位置上执行，或者如图所示，小额交易处理机可以由第三方处理机代表一个销售商、一组销售商或一个FSL执行。
消费者帐户处理机16将一组消费者帐户的小额交易合并成更大的交易。消费者帐户处理机16是消费者自服务的初始接口并为客户服务提供单一的开始入口，该入口将客户分派到适当的小额交易处理机进行自服务。在这个方案中，消费者帐户处理机16被执行在发卡银行的服务器20上。或者，消费者帐户处理机16可以被执行在用于一组销售商或一个FSI的位于第三方处理机的服务器上。
销售商帐户处理机18将大交易的支付分解成各个单独的小交易(它们各自合并产生大交易)。销售商帐户处理机18提供金融业的集中结算***和销售商的单独结算***之间的接口。与上述其它处理机类似，销售商帐户处理机18可以由代表任意类型的FSI的第三方处理机执行。但是，在这个说明性例子中，销售商帐户处理机18被执行在位于收单银行的服务器22上。
大额支付处理机24将消费者帐户处理机16和销售商帐户处理机18连接到处理大额支付的第三方支付处理机。为了提供这个接口，大额支付处理机24将数据和消息转换成第三方支付处理机使用的一种或多种格式。例如，可以为第三方支付处理机实现的转换有First Data、Paymentech、Vital等。在这个特定的配置中，大额支付处理机24被执行在执行小额交易处理机12的服务器14上。但是，在一些配置中大额支付处理机24可以被执行在位于别的位置(如位于销售商处)的服务器上。
参考图4，所示结构图表示小额交易处理机12、消费者帐户处理机16、销售商帐户处理机18以及大额支付处理机24提供的一些功能。在这个行定实现中，每个处理机包括一些相似的组件。尤其，处理机12、16、18和24中的每一个都包括引擎组件，它为交易处理实现了分布式处理应用程序接口(API)。另外，每个处理机都包括用户界面和报告API组件，它们提供交易数据并允许***的交互式使用。
参考图5，所示结构图表示图4中所示处理机12、16、18和24中的每一个都包括的分布式处理引擎26.分布式处理引擎26包括可扩展标记语言(XML)API 28和用于向其它处理机发送消息或从其它处理机接收消息的分布式交易路由确定程序。分布式处理引擎26还包括用于合并少量的低价交易的合并组件32。合并组件32可以帮助计算各种不同类型的合并。例如，可以基于消费者合并小额交易。为了帮助发卡银行，可以基于一个或多个销售商合并低价交易。分布式处理引擎26还包括组件34帮助单独的交易和/或合并在一起的交易的结算和对帐。另外，引擎26包括组件36帮助检查交易并向交易和与交易相关的数据(例如，信用***，帐号等)提供安全性。
与上述组件一起，并入小额交易处理机12的分布式处理引擎可以包括额外的组件。例如，可以包括个性化支付组件38向用户提供不同的进行支付的方法。例如，用户可以从预付费、订购、后预付、帐单到期即付和/或基于忠诚的支付***等支付方法中选择。与小额交易处理机12一起，支付处理***10中的其它处理机可以包括额外的组件。例如，消费者帐户处理机16可以包括一个允许消费者访问支付处理***10的组件.通过提供访问，消费者可以被导向适当的小额交易处理机以查看一个或多个交易。
小额交易处理机12被作为支付卡网关集成到销售商购物体验中，在消费者的购物体验中只有非常小的变化(如果有的话)。在销售商的购物体验中的某个点上，交易被提供给支付卡网关接口进行授权和结算(或拒绝)。当指向XML支付卡网关API时，销售商发送相同的支付卡交易信息并接收实际上实时的小额支付授权和结算(或拒绝)。对于消费者的购物体验来说实际上没有任何明显的不同。
作为支付卡网关，小额交易处理机12能够为各种不同类型的业务模式处理支付。例如，支付处理***10允许消费者用它们的首选支付工具(如***、借记卡、通过Paypal等支付中介，等等)进行购物。此外，尽管支付处理***10为小额交易提供了无可比拟的高效处理，但该***还能够处理任何规模的交易。
通过处理机12、16、18和24，支付处理***10将大额支付交易验证过程(如AVS、CVVS检查、欺诈检查、3D-安全确认)中的信息导成小额支付授权控制流中。处理这个信息并关于是否应该允许一个特定消费者正常交易的销售商-级决定的销售商软件继续以相同方式运行。
支付处理***10延伸了传统的产品支付卡***的轨道，提供了开放、易采用的技术，该技术实际上将实时的小额支付交易处理移动到了网络边缘同时保持了与今天的产品支付卡***完全相容。
支付处理***10从各种不同类型的客户机软件***接收电子支付交易。例如，可以从运行在有人值班的物理世界销售点并被设计用来将有卡交易灌进已有的卡支付网络的POS设备接收交易。运行在无人值班的物理世界销售点并且还传导有卡交易的售货亭设备可以提供电子支付交易。这些设备通常支持复杂的图形用户界面(与POS设备相比)，因为售货亭设备被设计用来直接与消费者交互，来自值班收银员的支持很少或没有。支付处理***10还可以从传导无卡交易的互联网网站或网页(或其它类型的电子商务***)接收电子支付交易。传导有卡和无卡交易混合的移动商务应用的移动接口可以提供交易。
对于上述各种类型的客户***，有多种体系结构将销售商应用程序连接到支付处理***10.例如，对于客户端定制，可以将使客户适应支付处理***10的业务逻辑编码到客户服务器或与销售商相关的服务器中。可以在可位于客户和控制该***的第三方之间的中间服务器上实现使客户适应支付处理***10的业务逻辑。可以通过销售商插件将使客户适应支付处理***实现为支付处理***的服务器-端模块(如插件模块)。另外，支付处理***10中包括的处理机12、16、18和24中的一个或多个可以被透明地集成到已有的支付处理机的***中。这样的集成可以包括对已经在使用预先存在的支付处理机的销售商的***的最小变化(或者实际就没有)。通常，支付处理***10中包括的各种类型的API可以实现这些方法中的一个或多个。
支付处理***10提供的个性化支付选择通常实现了4种类型的支付模式：按使用付费、预付费、订购和后付费。支付处理***10在单个交易处理平台上支持这些模式中的每一种。支付处理***10还可以支持混合模式，混合模式中销售商同时在一种或多种模式下运行并且消费者可以动态选择首选的购物方法。
个性化支付选择为销售商提供了定义一组他们在业务中接受为支付的“帐户类型”。帐户类型可以是销售商专有的，例如一个销售商可以为通话时间定义一个预付费帐户，而另一销售商可以为下载的音乐定义一个预订帐户。帐户类型有一个基础的“单位类型”，它是这种类型的帐户余额的单位类型，例如美元、通话时间的分钟数、游戏时间的分钟数或糖块。可扩展的单位类型集允许忠诚货币的实现。
帐户是帐户类型的实例，通常由消费者拥有并由“工具”支持。工具用来识别消费者，并且可以是向授权访问帐户的关键基础。工具的例子有***、借记卡、礼品卡、基于RFID的智能卡、基于RFID的移动令牌或者网站帐户标识符。工具是***中大额支付资金的来源，并且实际上可能是识别这个帐户的消费者的唯一标记。消费者可以有一个注册(名字、密码)，并将该注册与一个或多个工具以及与这些工具相关联的帐户关联在一起。参考附录A，示出了每个帐户中可以包括的一个示范信息集。
参考图6，流程图40给出了说明个性化支付选择并涉及销售商和小额支付处理机12之间随后的API-级交互的一系列操作。为了开始一个典型的交易，消费者可以将工具出示给销售商。销售商将该工具传递给小额支付处理机12。小额支付处理机12确认该工具有效并返回与该工具相关的个性化支付档案。该档案说明了已经被规定和该工具合作的一个可扩展帐户列表以及定义如何向该工具档案添加新帐户的参数。
销售商使用该档案中的信息向消费者给出为该消费者的喜好定制的支付体验以及销售商定义的业务模式。消费者按照期望完成该购买交易，销售商按照所选择的支付帐户所确定的从消费者收取资金。通常，API支持两种风格的交互，例如符合标准支付卡交易的单帐户购物。另外，可以支持复合、多帐户的购物。例如，多帐户购物可以组合美元交易和忠诚度点数更新，或者组合日元交易和免费咖啡更新。
通常，每个支付帐户都支持购物API的一个公共集合。这使得销售商能够以独立于消费者支付选择的方式编码它们的交易。附录B中示出了一个典型的购物请求列表。
在“按使用付费”模式中，消费者支付每个已完成的交易。从销售商的观点看，这种模式是有利的，因为按使用付费模式在消费者之间提供了相对较高的接受率。这个模式的简单条款鼓励消费者试用销售商的产品并且该提供为销售商产品建立了单位价值点。但是，按使用付费模式也包括了对销售商的一些挑战。例如，如果一个消费者是“低量”消费者，该关系通常就是无利可图的。交易成本相对较高并且关系通常是匿名的。除了API购物请求之外，对于按使用付费帐户，支付处理***还可以支持两个额外的请求(在附录C中说明)。
在“预付费”模式中，消费者预先购买一组交易。从销售商的观点来看，这种模式可能是有利的，因为消费者向销售商承诺了不止一个交易，并且可能经常超出他们最初的承诺。因为消费者先前已经支付了费用，所以降低了向消费者扩展信用的风险。预付费为折扣活动提供了一个平台，包括总额折扣、礼品卡和帐户、未成年人帐户以及达到无积压的供应。另外，可以调节预费用的上限金额以在很多小额交易中分期偿还交易费用。伴随着好处，预付费模式也为销售商带来了挑战。例如，与按使用付费相比的低接受率，可能需要大量的销售努力来抵消按使用付费。另一潜在的挑战是需要提供一些刺激，如总额折扣等。发行有商标的预付费卡的费用是实际的：在销售点的发卡和装卡成本约2-3美元，15-40％用于发布到销售点的卡柜，2％每笔交易费用以及消费者支持费用。遵守新兴规则(如对无人认领的预付费资金由政府强制没收)是另一种挑战。如附录D中所述，除了购物请求之外，预付费帐户支持另外的请求。
在“预订”模式中，消费者承诺为一个指定的时间段预先购买一组交易。从销售商的角度来看，这种模式的好处有消费者同意通过预订购买意味着对销售商深层次的承诺(这能够导致销售商和消费者之间更深的关系)。消费者还可以成为销售商连续的收入来源。可以降低向消费者扩展信用的风险。
预订模式也为销售商带来的挑战。例如，连续的金融承诺会降低接受率。为了提高接受率，销售商可以采用在商品供应上的实际折扣。预订业务模式不适用于所有产品类型。如附录D中所示，预订帐户可以使用按使用付费所支持的请求连同一些附加类型的请求。
在“后付费”或“记帐”模式中，销售商接受消费者的交易而不预先获取付款。销售商周期性地将消费者的交易开成帐单而不是收取付款。从销售商的角度，这种模式是有利的，因为消费者会经常自由地花费并与该销售商进行大量的交易。消费者会变成销售商连续不断的收入来源。在销售商可以期望一些消费者可被高度激励以保持他们的帐户有非常好的信用的地方(例如住宅电话或电力服务)该模式被修改为服务提供。
销售商的后付费挑战包括随着实际的不支付风险销售商承担了很大的信用风险。但是，通过保持后付费计帐周期相对较短可以减轻该风险。另外，该模式对很多产品类型无法操作。后付费帐户支持按使用付费支持的所有请求，包括附录E中列举的一些额外的请求。此外，附录F给出了由购买和帐户API使用的多种参数。
参考图7，示出了结构图42以说明在支付处理***10的一些实施例中可能包括的小额交易处理机44、46、消费者帐户处理机48以及大额支付处理机50的交互。如上所述，将相对小额的交易合并到一个大的交易中提供了一种降低交易成本的方法。通常，交易合并包括将很少小额交易转变成一个大额交易。通过合并，与处理一个大额交易相关的固定成本可以被分散到多个小额交易上。如图中所示，每个交易都被通过销售商经历的三个阶段进行说明：授权或auth：检查持卡人支付凭证并预留该交易所需资金；收取或capt：同持卡人完成该交易；以及使金融机构配合由该支付发起的交易的最后结算消息。
在这个例子中，小额交易处理机44、46从销售商的***接收一系列支付卡授权、收取、销售、信用和取消小额交易。尽管在其它方案中小额交易处理机44、46可以从多个销售商接收小额交易。每个小额交易处理机44、46与和特定支付卡相关的消费者帐户处理机48合作以将小额交易合并成数量更少的大额交易。消费者帐户处理机48接着用大额支付处理机50将表示大额交易的数据发送到第三方支付网络。在这个特定方案中，销售商帐户处理机没有被包括在实时交易流中。
作为论证交易合并的成本效益的说明性例子，假定上述一系交易被分成每笔0.99美元收费的5个小额交易。如果大额交易级别的交易处理费用是网关0.10美元、收单行0.10美元、交换0.10美元+2％，那么5个0.99美元的大额交易将需要1.60美元的交易处理费用，即交易额的32％.相反，如果这五个交易被提供给每笔交易收取0.05美元的支付处理***，五个小额交易的总费用是0.55美元，即交易额的11％，节省了1.05美元，即交易额的21％.
通过实现并入了合并引擎的处理机44、46、48和50，实现了使小额交易业务模式成为可能的一组策略。通过实现合并，降低了交易成本从而提高了销售商获利能力。但是，并非只是将成本最小化，在有些方案中，合并被以某种方式实现以平衡多种因素。例如，(通过增加合并时间)可以平衡涉及降低交易成本之间的权衡的因素以及现金流延迟和欺诈风险避免等其它因素。通过真正地优化这些因素之间的权衡(例如，解决销售商的资金成本和欺诈比率)，可以提供合并而没有实际负面影响(例如，减小现金流延迟、对危险交易的暴露、客户服务成本的增加等等)。
通常，Visa和MasterCard等协会要求它们的成员收单银行向它们的成员发卡银行支付的费用随着交换分类而变化。交换分类涉及很多规则。Visa和MasterCard定义了至少八十或更多种具有不同费率和规则的交换类别。交换类别被基于一个接一个的交易分配，并且可能取决于很多因素。例如，涉及销售商的一些因素有销售业务类型(MCC代码)、销售商是否有有卡业务或无卡交易业务、无卡业务是邮购、电话订购或电子交易、是否有无人值班的销售环境、和/或协会是否将此看作应有特殊费率的“新兴”市场。另一分类因素可能涉及所用的消费者支付工具(***、借记卡、公司卡、购物卡、特殊标记卡、EBT卡、来自国外发行者的卡，等等)。交易的交易时间细节也可能是一个因素。例如，有没有有效的刷卡、签名、或者签名借记VS密码借记，有没有AVS匹配、CVV匹配或者Visa确认的匹配或安全代码匹配，该交易对特定时间间隔是否足够小，和/或对该交易是否有1美元的预授权。同样，交易的交易后细节也会影响。例如，授权和收取之间、收取和结算之间或者授权和结算之间已经过去的时间，授权数额是否等于收取数额，或者在结算时是否提供了客户服务电话号码或网站地址等细节。
如果满足了一个销售商“最好的”交换类型的所有要求，那么该交易通常被称为“完全合格”。如果没有满足该交换类型的要求，那么该交易会被降格为一个新的“基本合格”交换类别(当前，即VisaEIRF或MasterCard Merit 1)。如果没有满足基本合格类别的要求，该交易被降格为“不合格”(当前即Visa Standard或MasterCardStandard)。特定的交换类别可以有中间基本合格降级类别(例如，如果交易中唯一的不足是丢失了刷卡记录？，在Merit 1之前可以先降格为MasterCard Key Entry)。
销售商的完全合格交换类别是一组帮助进行合并的输入。单一业务线的销售商通常有单一的交换类别。具有更复杂的业务的那些销售商根据哪些业务线进行交易有若干个类别，尽管通常这些业务线有不同的销售商帐户。支付处理***10的合并能力通过允许每种业务维持一个单独的档案在合并中使用而适应了复杂的业务。
合并的成本优势由对消费者购物行为的两个基本测量支配-他们买多少以及他们多长时间买一次。购物数额可以表示成Pi，这是消费者每次购物花费的金额；购物间隔时间表示为Ti，这是特定消费者在特定销售商处两次购物之间的间隔。消费者在销售商那里的购物行为可以看作是一系列的金额和间隔时间：
P1…T2…P2…T3…P3…T4…P4…T5…P5。
合并通过优化大额支付和大额收取/大额结算之间的时限实实在在地优化了交换类别和将更多小额交易放在已有的“合并窗口”中之间的权衡。此外，合并实实在在地针对交换降级的潜在成本影响优化了合并的效益。
参考附录G，提供了一张表格说明销售商可以设置以控制合并的参数。支付处理***10在销售商设置的参数控制下基于一个接一个的交易真正地优化了合并。在有些方案中，这些参数可以被考虑得很复杂，但缺省设置可以提供真正优化的合并结果而不需要用户学习或获得对合并参数的理解。通常，支付处理***10进行在协会一致性方针中运行的合并，保持单一销售商合并符合协会规则。
参考图8，通过合并，支付处理***52可以将遍及很多消费者、销售商和/或支付提供者的小额交易合并在一起。支付处理***52通过将成批的小额支付处理从支付网络核心转移到分布的处理机(如小额交易处理机54、56，消费者帐户处理机58以及小额支付处理机60)扩展了交易合并，同时保持了安全的支付处理***。
支付处理***52可以包括允许支付处理大量分布的密码安全选择(CSS)模块，同时保留了安全集中控制。在这种方案中，CSS模块将***操作分成了两层。第一层是分布式实时小额支付处理层，其中同销售商的消费者微支付交易被记录在小额交易处理机(例如，小额交易处理机54)上。第二层是大额支付和分布式控制层，它以非实时方式运行并与已有的支付网络对接。
通常，小额支付和大额支付层通信。例如，控制实时交易的策略(在需要时)由与小额交易处理机相关的小额支付层获取并缓存。这些策略可以授权多个小额支付交易只要它们通过了实时欺诈检查。通常，小额支付层将总的结算信息传回大额支付层，但是，详细的小额支付记录被存储在小额交易处理机中，那里费用更低。
为了实施安全控制，支付处理***52根据密码安全选择模块实现了检查协议。使用这种协议，大额支付层能够检查详细的小额交易的小子集并可靠地确保正确的支付处理已经在所有小额交易上发生。这保持了安全性同时降低了成本。
支付处理***52是为可扩展的、高度安全的操作而设计的。已经认真划分了当事人的角色和它们在***中进行的操作。在有些方案中，组件由联合的、基于公有甯钥的验证***验证。在传输和存储时对设计为要保持机密的信息加密，对需要验证的信息进行数字签名。该***紧密地控制凭证、限制它们的使用，并且可以用轻量级撤销过程撤销凭证。
密码安全选择过程通过将计算从支付网络中心转移到分布式小额交易处理机(如小额交易处理机54和56)而提供了成本优势。在支付***的中心处理支付通常需要真正的集中式计算和相当昂贵的通信基础结构。可以在便宜得多的常见硬件上进行小额交易处理机上的支付处理，并且通信也局部于电子商务网站。采用密码安全选择模块，支付处理***52提供能够以较低成本处理大量交易的低成本、可扩展的合并基础结构。
通常，销售商在小额交易级别上管理它们的业务，因为这是它们和它们的客户交互的级别。支付处理***52试图优化第三方支付网络交互以使资金以成批的大额交易为单位流向销售商。该***的结算和对帐层将资金流从成批的大额交易映射到单个的小额交易。结算层能够处理包括部分结算在内的各种因素，在部分结算中Visa已经支付了已经结清的交易的一个子集，而美国在线已经预扣了付款。也能处理退款，例如当发卡银行可以同与一个特定消费者的申诉有关的销售商发起退款过程时的退款。处理的另一因素是资金在收单银行一级和小额交易处理机一级的一组销售商之间的分割。
回到图4，小额交易处理机12包括检查和控制模块62以确保支付处理***10符合由协会运行的集中式支付处理***的相关规则。协会定义的一致性规则假定几乎每笔支付都由委托的“第三方处理机”检查。一些常规***能够检查相对大比例的大额交易，但如果需要常规***检查大比例的小额交易，处理小额交易的费用将与处理大额交易的费用相同，销售商将不能进入小额交易市场。
检查和控制模块62在小额交易处理一致性中可以提供高度的自信，而不需要检查方检查每笔小额交易。检查和控制模块62实现了2002年4月17日提交的专利合作条约(PCT)申请PCT/US02/12189中说明的密码安全选择，在此按引用引入它。附录H中提供了该PCT申请的一个副本。密码安全选择允许以一种检查者可以可靠地将结果外推到全集的方式检查小额交易的一个子集。检查和控制模块62对一部分费用提供了全面的一致性监控的好处，在小额支付处理机12上做了大约95％的工作，而在其它地方做了大约5％的工作。
检查和控制模块62检查各种问题。例如，如果批准了每个要求的交易，该模块可以检查结算批量是否总计为所要求的数额或者批量中是否存在任何重复。此外，检查和控制模块62可以确定在各个小额交易中是否有交换类别请求的适当程度的AVS匹配、CVV匹配或者由Visa验证的匹配。可以检查其它问题，如是否是在交换类别指定的界限中的授权、收取和结算之间的时间。检查和控制模块62是可扩展的并且考虑了将来要检查的其它问题。
参考图9，当销售商通过用带有时间戳的公有密钥签名签署它们的交易而提交这些交易时就建立了检查的初始条件。公有密钥签名需要大量计算。Merkle树技术用1个公有密钥签名、2*N-1个散列和每个消息多出HashSize*lgN个字节代替了一批N个公有密钥签名和N个安全的单向散列。
参考该图，在这个例子中，所示Merkle树64(其中N＝8)展示了一个被销售商数字签名的交易。例如，T010和SIGm(T010)等于相同交易T010以及Merkle树的根SIGm(v)连同Verkle树中的兄弟散列值链v011、v00、v1、v。接收者可以检查SIGm(v)和v＝H(H(H(v00，H(T010)，v011))，v1)，它表明该销售商已经产生了数字SIGm(T010)，即如果它们已经产生了Merkle树签名，它们可能已经同样直接签署了特定的交易如T010。Merkle树技术在树中的所有N个对象中共享一个签名SIGm(v)，因为密码安全散列H实际上比计算公有密钥签名便宜，计算成本大概降低了N倍。
Merkle树技术通常需要对大小为N的批量中的签名进行批处理。支付处理***10提供成批的小额交易作为它的合并和结算方法的一部分，因此该技术天然地适用于那些环境而不会改变应用程序行为。可以单独检查Merkle树中每个小额交易的签名，而不用获取树中的其它元素。该技术实质地减小了公有密钥签名的数量，但维持了不对称加密的几乎所有信任-可缩放性优势。
从小额交易处理机12开始，在小额交易T的收取时间，小额交易处理机用从{0，1}统一获取的每个比特产生一个长度为n的随机比特串R。小额交易处理机12将(T，R)对添加到计算Merkle树叶签名Hj(T，R)的Merkle树。周期性地结算销售商在小额交易处理机12上的小额交易，用消费者帐户处理机和销售商帐户处理机生成的结算时间戳给销售商在小额交易处理机上的小额交易打上时间戳，然后通过用销售商的公有密钥签名签署Merkle树的根而产生并提交一个完整的Merkle树。顶层Merkle树签名SIGm(v)连同结算总额一起被发送到消费者帐户处理机16和销售商帐户处理机18。这个签名确认了该批次中的每个小额交易并为将来的检查实际“锁”住它们。
消费者帐户处理机16或销售商帐户处理机18的后续检查可以包括任一处理机向小额交易处理机12发送请求以反回检查问题(例如，某个指定日Visa-卡交易的总额是多少)的答案。伴随着问题一起，消费者帐户处理机16和/或销售商帐户处理机18可以指定小额交易检查集合中应该由小额交易处理机12返回作为小额交易处理机计算结果的证明的那部分。消费者帐户处理机16和/或销售商帐户处理机18可以通过提供将要应用到与每个交易相关的随机比特串R的一个选择标准对(mask，match)列表而指定这个集合。选择标准mask和match(屏蔽与匹配)是长度为n的比特串，如果对于该列表中任一标准R与mask的比特级“AND”(与操作)等于match就返回一个小额交易。这个机制允许选择对所检查的小额交易中支持检查真值的一部分p，其中p可以通过选择1-比特的数量与p的二进制表示中的1相对应的1-比特数量相对应的一系列mask而任意接近地近似。
小额交易处理机12可以执行检查请求并通过检查处理机上的每个小额交易返回检查问题的精确答案，例如，在指定日的Visa-卡的总额。伴随着答案一起，小额交易处理机12可以返回匹配选择标准的小额交易子集，这个子集可以作为小额交易处理机提供该答案的证明。
消费者帐户处理机16和/或销售商帐户处理机18通过下列步骤验证小额交易处理机12的结果：(a)核对返回的小额交易上的Merkle签名以确保这些交易与先前已经提交给支付处理***10的交易相同(b)将检查的集合中的结果逐步增加1/p倍并测试以查看这些结果是否接近小额交易处理机20返回的精确结果。如果判定逐步增加的检查结果不是足够近似接近，消费者帐户处理机16和/或销售商帐户处理机18可以重复该检查，以新的检查标准发送相同的请求。可以重复这个过程直到满足消费者帐户处理机16和/或销售商帐户处理机18，或者决定必须彻底检查小额交易处理机12.对于诚实的销售商，统计可以确保在合理的时间量内用部分检查满足消费者帐户处理机16和/或销售商帐户处理机18。
支付处理***10是为可扩展的、高度安全的操作而设计的。可以仔细划分当事人的角色和它们在***中进行的操作。信任联盟组件是支付处理***10的分布式证明授权。它使用公有密钥或其它技术以它在支付处理***10中被赋予的角色验证***的每个组件。组件由联合的、基于公有密钥的验证***验证。通常，在传输和存储时对需要保持机密的信息进行加密。因此，需要跨越管理边界验证的信息被进行了数字签名并且是可检查的。支付处理***10控制凭证、限制它们的使用并且可以用轻量级撤销过程撤销所有的凭证。
通常，支付处理***10不在小额交易处理机12、消费者帐户处理机16或销售商帐户处理机18中存储帐户、CVV代码、Track-1或Track-2。相反，帐户的单向散列被存储在数据库中。单向散列还被用作交易合并的基础。在支付处理***10中，在AUTH交易期间(或SALE交易的AUTH阶段中)可以近似实时地使用帐号。如果AUTH成功，那么对进一步的大额支付***交互(后续的获取、放帐或或用AUTH返回的REFID指定它们适用的特定AUTH)就不需要帐号。如果AUTH因为某种原因失败，那么***的AUTH协议将需要调用者再次提供帐号以尝试新的AUTH。
支付处理***10中的服务器通常不在存储器中存储帐户、CVV代码、Track-1或Track-2数据。另外，这个数据通常不被写入数据库，也不被以明文写到任何服务器日志文件中。在有些方案中，支付处理***10通过将交易与帐户和过期日期的安全单向散列函数相匹配而合并交易。用于计算散列的方法可以实现SHA-1密码安全消息摘要等功能。
对于销售商客户服务目的来说，支付处理***10可以用明文保留帐户的后4位数字。客户服务代表可以看到这最后4位并检查匹配那些位以及其它交易特征的交易。支付处理***10还允许销售商客户服务代表用信用***的精确匹配查找交易。在内部，这种数据库查找由于帐号的单向散列，因为帐号通常不被存储并且不能从单向散列恢复帐号。
支付处理***10中的大额支付处理机24通过MPP插件使小额支付处理服务适应第三方支付处理机。当第三方支付处理机支持AUTH和CAPT过程(只在AUTH时由此给出帐号)，MPP插件就作为小额交易处理机12和消费者帐户处理机16运行。尤其，帐号在AUTH期间被安全地传递到支付处理***，并且通常不会被保持在存储器中。但是，一些第三方支付处理机需要在每个CAPT交互时提供帐号。为了支持这样的处理机，处理机的MPP插件在AUTH时将帐号和过期日期加密并在收取或存入时重新给出解密后的***和过期日期。
在有些方案中，加密和密钥管理被用硬件安全模块实现，例如n-Cipher n-Shield。该***还可以使用强密码如AES-128。加密的***通常只保持一段时间，这段时间可以被定义为AUTH和CAPT之间的时间窗口。当前的***规则定义这个窗口为约7到30天。在这个阶段之后，支付处理***10删除加密的帐户信息。使用安全工具(如由硬件安全模块提供的安全工具)管理密钥。HSM提供多层安全和安全的密钥管理过程。
通常，小额支付在相对低价的点上相对大量地发生。支付处理***10高度可扩展并且可以被扩展到包括成千上万个高度分布的小额支付处理机、消费者帐户处理机、销售商帐户处理机、大额支付处理机、发卡银行服务器、收单银行服务器等。还可以对＞1000x的可扩展性扩展支付处理***10，＞1000x的可扩展性可以被逐步扩展。例如，在对更大的扩展因子(例如，100-200x，1000-2000x等)扩展该***之前可以先实现10-20x的扩展因子。
通过扩展，支付处理***10能够透明地将交易处理过程划分到成千上万个分布式服务器上。这个划分可以发生在多个级别上。例如，功能划分，在功能划分中支付处理***10被设计用来分离交易处理的不同方面以使它们可以在单独的服务器上被安全有效地执行。可以把小额交易处理可和对合并成的大额交易分开。同样，可以将小额交易报告从大额交易报告分开。可以将需要长期访问需要加密的持卡人数据的***功能从不需要该访问的功能分开。该体系结构可以将出于客户服务目的的对消费者的安全验证从包含客户服务数据的小额交易记录分开。
对于组织界限划分，支付处理***10的体系结构考虑了构成支付生态***的不同组织之间的界限。这些组织包括销售商(可能有多个位置)、收单银行、收单银行的处理机、发卡银行、发卡银行的处理机以及希望他们各自的交易彼此保持私有的协会。
对于负载划分，一个客户的交易通常独立于另一客户的交易，并且出于许多目的，一个特定支付工具的交易独立于另一支付工具。各个支付工具倾向于有相对少量的交易，因此对各个消费者的交易的实时处理不是真正的实时处理，并且在不同消费者的交易之间有大量潜在的并行性。销售商通常需要与它们的业务相关的交易的综合观察，并且这可以表示大量的交易。销售商通常想得到与它们的业务有关的及时快速的信息，但对硬实时信息则倾向于有限的要求。
参考图10，在有些方案中，实现负载划分的组件是分布式交易路由确定程序66。通常支付处理***10中的大多数功能模块(如小额交易处理机、消费者帐户处理机、销售商帐户处理机等)包括一个或多个内置的路由确定程序组件。路由确定程序检查所有进出的消息流。
路由确定程序66完成各种消息操作，如对XML的快速检查、确定哪个结点应该处理一个请求等。例如，AUTH消息被按支付***和销售商划分。在找到AUTH中的***和销售商标识符之后，路由确定程序66检查相关的路由表以找到适合处理这个请求的特定服务器。在另一例子中，CAPT消息被按照匹配AUTH时返回的RefID划分。然后用一个路由表将RefID映射到合适的服务器。
有些环境下对消息额外的应用层分析可能揭示出交易应该在另一位置被处理。在那种情况下，可以重新发送该交易，并且路由确定程序66确定一个新的路线。在有些方案中路由确定是自适应的，这样大部分时间交易都能够被适当地选择路由(例如99％的正确路由确定比例)。
路由确定程序66还可以容错的并且可以处理进入和离开路由集合的结点。路由确定程序66可以管理热空闲结点，并且可能可以在相对较短的时间(如1到2秒)内用另一结点代替一个出现故障的结点。
路由确定程序66还可以通过管理与特定服务相关的一组域名而处理地理和功能划分。通过管理域名，路由确定程序66可以缓和映射到那些域名的更大的IP地址集合之间的流量。
参考图11，展示了一个示范性负载划分的处理结点68，它包括一个负载均衡器(LB)70.在这种配置中，负载均衡器70是提供“哑”HTTP负载平衡的HTTP/SSL负载均衡器。在这个方案中，包括小额交易处理机或消费者帐户处理机在内的结点通过交易路由确定程序相连并完成应用级路由确定。初始时可以根据特定的引擎交易按支付***、销售商帐号标识符、和/或销售商引用标识符划分单个的小额支付处理机或消费者帐户处理机数据库。
小额交易处理机和/或消费者帐户处理机报告以及客户自服结点通常从被近乎实时访问的公共数据库执行。可以按支付***和/或销售商划分小额交易处理机和消费者帐户处理机报告负载。尽管可以给这个报告指定较低的优先级。
一般来说，实现支付处理***10的组织通常在该***中为它们的员工分配特定的角色。例如，行政负责商店(或其它商业设施)中的所有操作，但主要用来管理用户。通常，每个商店只有这些用户中的一个。客户服务部门可以包括处理与销售商服务有关的抱怨和请求的用户。他们可以在指定的数据库中发起并解决客户服务。财务部门包括跟踪商店帐户、可以修改和跟踪交易、结算和支付的用户。这个用户还可以调节该商店的银行帐户支付记录。
伴随着单个的人一起，还可以由组织指定特定的过程(以软件、硬件或软硬件结合实现)以完成特定的操作。例如，可以实现交易API以发送交易请求文档到小额支付网关。在每个请求XML文档中可以有指定哪个销售商SDK客户是交易源头的机密。
另一可指定的过程是查询API，可以实现它以发送数据查询到小额支付网关数据库。通常，查询API接口用来将销售商业务***和支付处理***集成在一起。来自这个可指定过程的每个XML请求指定一个特定的销售商应用程序。另一可指定的过程是管理API，可以实现它以发送服务器配置和销售商应用程序管理文档到小额支付网关。来自这个可指定过程的每个XML请求可以指定一个特定的销售商应用程序和在该销售商应用程序上执行的一个操作，例如对支付的调节或对合并设置的调节。
为了和***交互，提供了用户界面。这些用户界面交互地帮助交易功能，如显示总结报告、浏览交易细节以及查询交易。用户界面还帮助结算功能，如结算总结报告、查询结算并浏览结算细节。还用一个或多个用户界面帮助与支付相关的功能。例如，可以提供与支付总结报告、查询支付、浏览支付细节以及协调支付相关的操作。
用户界面还可帮助提供客户服务消息，例如客户服务总结报告、争论/服务消息流或帮助浏览争论/服务消息集或查询争论/服务消息。还可以帮助帐户管理操作，产生帐户报告、产生并管理新帐户类型、查询有效帐户并浏览帐户细节。还可以用用户界面提供基本的用户内部工作。例如，用户帐户登录功能、用户帐号档案管理功能、用户子帐号管理功能、检查用户活动状态等等。
通常，查询API通过用户界面让销售商对可用的相同信息进行计划性的访问。销售商和FSI接口通过灵活的交互架构实现数据查询和***管理。这个架构使得***能够通过多种方法，包括web浏览器和HTTP API上的计划性XML，访问公共的查询和管理代码。
通常，这些API可以包括由查询和数据管理实现组成的业务逻辑组件。这些API还可以包括构成工作流的工具组件、使数据库访问(例如面向对象的数据访问和关系数据库管理***访问)和数据库可移植性成为可能的数据访问接口。
在小额交易流上操作可赢利的业务给业务操作的很多方面都带来了巨大的压力。例如，客户服务交互每个事件可能花费5到10美元，在很多业务中总的客户服务负担平均每笔交易能够达到0.5美元甚至更高。支付处理***10实现了基于小额交易处理机的客户自服以降低成本。另外，支付处理***10提供了在线帐单，它详细列出了在销售商的商店中的每次购物。在线自服通过集成的帐单呈递和争议解决提高了客户满意度并降低了客户服务成本。
在销售商控制下的帐单中的每笔小额交易包括能够解决特定问题(如重新下载一首已经购买过但不小心删掉的歌曲)的自动化争议解决软件向导。该向导还可以收集与其它问题有关的信息并将该信息转发到销售商客户服务人员进行解决。另外，该向导可以通过发行***、通过在销售商控制下的策略以及根据消费者在有争议的交易之前的历史而变化的策略来解决问题。
在有些方案中，支付处理***10可以实现消费者和一个或多个消费者帐户处理机和小额交易处理机对接的接口。与小额交易处理机相关的接口可以允许消费者查看交易记录、发起并解决争议以及管理和产生销售商规定的金融工具帐号。
参考图12，支付处理***10可以实现不同的方法用于向基于web的客户自服提供安全性。例如，可以通过要求使用打印出的***结算表上的信息获取访问而提供安全登录。在别的安全实现中，可以通过与销售商相关的基于web的应用程序控制登录。
例如，为了用打印出的结算表上的信息登录，消费者查看他或她的***结算表。在收费行式项目上的销售商名字后面，提供了一个8个或9个字符的标识符。在这个例子中，在来自“MYSTORE”的一笔$26.41的收费中包括的串是“Z12A782G”。这个字符串可以由***用户用来登录到图形用户界面(GUI)74中。尤其，为了向基于web的界面标识他们自己，这个字符串被输入到标为“登录号码”(Log innumber)的字段中。另外，交易帐户被输入到标为“交易总额”(Transaction total)的字段中。在这个例子中，26.41美元的费用被输入“交易总额”，然后选择标为“继续”(go)的图形按钮。
采用相同的方式，与消费者帐号处理机相关的图形用户界面允许消费者访问相关信息。与GUI 74类似可以用来自打印出的结算表的信息安全地标识消费者。除了来自打印出的结算表的字符串和交易总额之外，还可以用其它信息获取访问。例如，可以用交易日期、消费者信用***的最后4位或其它相似类型的信息安全地提供访问。
消费者可以通过各种入口进行访问。例如，消费者可以通过他或她自己的计算机***(或其它数字设备，如蜂窝电话、个人数字助理PDA等)进行访问。或者，消费者可以通过销售商的***登录。
在有些情况下销售商可能已经验证了消费者，并且愿意让该消费者访问小额交易记帐记录而不要求进一步的验证。支付处理***10通过创建了销售商能够传递给该消费者的限时帐单呈递凭证的API支持这种访问。这个凭证是“费用URL”(Charges URL)，并且对于向消费者显示他们的小额交易记帐活动的指定的时间量是有效的。访问该费用URL(通过消费者选择或销售商强制的浏览器重定向)可以向消费者呈现他们的指定费用而不需要由消费者进一步的验证。
通常，费用URL只对有限的时间(通常是30分钟或更少)有效。如果费用URL已经过期，但销售商对消费者的验证还没有过期，可以有一种机制通过要求销售商***给消费者额外的时间而刷新费用URL。如果消费者不再被销售商验证为真，消费者可以重新登录并获得一个新的费用URL。
参考图13，在获得访问时，可以向消费者呈现GUI 76，它包含已经被合并成一个大额交易的小额交易列表。用户可以选择每笔小额交易以获取更多的信息。
参考图14，示范的GUI 78呈现了从GUI 76中包括的一个行式项目中选择的小额交易的相关附加信息。
帐单中的每笔小额交易在销售商的控制下可以包括一个自动的争议解决向导，它可以解决特定的用户相关的问题(例如，重新下填鸭式一个已经购买过但不小心删掉的歌曲)。该向导可以收集与其它问题有关的信息并将该信息转发到销售商客户服务人员进行解决。另外，该向导还可以通过给消费者以信用而解决问题。用于解决问题的策略可以由销售商控制，也可以由支付处理***10中包括的反欺诈技术来驱动。
参考图15-17，一系列GUI 80、82和84展示了一些典型的用户交互。参考图15，消费者已经选择了“客户支持请求”链接并且面前呈现出销售商规定的GUI 80中的可能请求的列表。参考图16，在这个例子中，通过选择“I lost this song”的链接，显示GUI 82，它使得用户能够发送客户支持请求。参考图17，(可能与销售商相关的)客户支持人员面前显示出与通过GUI 82确定的问题相关的GUI 84.该客户支持人员可以解决与该请求相关的问题。在解决后，向该消费者发送电子邮件。另外，可以更新消费者的在线帐单。
参考图18，如果将单个销售商的交易合并在一起，相应的大额交易中的小额交易就与相同的销售商相关。那些交易可以记在那个销售商的名下。如上所述，可以跨越一组销售商合并小额交易。因此，可以合并一个消费者和多个销售商之间的小额交易。另外，可以合并单个销售商和一个消费者之间的多个小额交易。通过合并这些多笔小额交易，可以向消费者呈现与不同销售商相关的合并在一起的交易。例如，如打印出的结算表86中所示，通过第三方，根据与消费者相关的小额交易的合并可以对多个销售商(如“SmallTab.com”或“Bank SmallPayment Service”)排名。
伴随着提供跨越多个销售商的合并数据，结算表86还包括可以用来访问第三方网站的标识号。例如，通过访问网站(如http://smalltab.com)并输入该标识号(如，1875766)，可以显示出客户服务GUI 88.在这个例子中，GUI 88显示了结算表86中包括的多个销售商以及它们的相应小计的列表。通过选择与其中一个销售商相关的特定链接，可以显示与该销售商相关的各笔交易的列表。
已经说明了多种实现。但是，将会理解可以进行各种不同的改进。因此，其它实现也在所附权利要求的范围内。
附录A
信息 说明
帐户ID 这个帐户的唯一ID
工具 与这个帐户相关的支付工具
销售商 与这个帐户相关的销售商，如果这不是“全体合并”帐户的话
帐户类型 标识怎样对这个帐户进行操作(见下面的处理机)
帐户数据 由小额交易组插件使用的帐户的扩充数据
Ppcn数据 与帐户相关的内部扩充数据
状态 帐户的状态：PENDING，ACTIVE，EXPIRED，DISABLED或SUSPENDED(未激活、有效、过期、禁止或暂停)
开放授权 已经针对余额确认过但还没有收取的授权集合
授权余额 在这个帐户上开放授权金额的运行余额
最后交易 帐户中最后一笔交易的日期
交易 这个帐户中的支付交易
帐户事件 帐户中的未支付交易
附录B-购买请求
AUTH 对可能的购买的请求验证
CAPTURE 根据现有的AUTH确认实际的购买
SALE 组合在一起的AUTH和CAPTURE
VOID 将最近的CAPTURE退回，并在该客户的帐单上不显示任何交易
CREDIT 将更早的CAPTURE退回，在客户的帐单上分开显示两笔交易
INQU 关于对这个帐户早期请求的查询
附录C-按使用付费附加请求
SETSTATUS 在Enabled、Disabled、Valid、Pending(激活、禁用、有效、等待)之间改变按使用付费帐户的状态
TRANSFER 将已有的按使用付费帐户转移到一张不同的***(如果其卡被偷或过期时需要)
附录D-预订附加请求
CREATE 创建新的预订并用对它下层信用帐户的交叉收费提供资金
CANCEL 取消未完成的预订，并将任何不应得的收入退回到下层信用帐户
RENEW 延长已有的预订周期。对于预付费(按时收费)预订，立即产生对下层的帐户的交叉收费
ADJUST 调节预订周期而不产生任何交叉收费
SETSTATUS 预订帐户的状态在Enabled、Disabled、Valid、Pending(激活、禁用、有效、等待)之间的变化
TRANSFER 将已有的预订帐户转移到一张不同的***(如果其卡被偷或过期时需要)
附录E-后付费附加请求
CREATE 创建一个新的后付费帐户
BILL 将这个帐户上的后付费费用记到记帐支付工具上
ADJUST 调节后付费帐户的条款，包括改变记帐支付工具
SETSTATUS 在Enabled、Disabled、Valid、Pending(激活、禁用、有效、等待)之间改变帐户状态
TRANSFER 将已有的后付费帐户转换成不同的帐户
附录F-API参数
元素 说明
ACCT ***/借记卡帐号
ACCTCLASS 帐户的类别：按使用付费(缺省)、预付费、预订、后付费
ACCTDATA 销售商专用帐户数据的容器。这个数据由Peppercoin***存储并可由客户端程序和服务器端程序使用。
ACCTENDDATE 在该日期之后帐户将不再有效(除非被延期)
ACCTID 这个帐户的内部ID；由帐户查询返回，并用在以后的请求中
ACCTINFO 与帐户有关的元素分组信息；一个查询响应可以包含任意数量的ACCTINFO元素
ACCTSTARTDATE 帐户的生效日期
ACCTSTATUS 帐户的状态；在V3中必须是ACTV、PNDG、EXPD、DISA之一
ACCTTYPE 帐户类型。帐户类型可以通过API动态定义
ACCTTYPELABEL 帐户类型的标签-可能呈现给用户
AMT 金额
AMTDUE 对于按使用付费的帐户，验证过但还未收取的金额
AUTHBALANCE 对于预付费和有限预订的帐户，验证过但还未收取的资金数量
AUTHEXP 授权的过期日期/时间
AVSRESP AVS地址响应，仅仅是建议
BALANCE 对于预付费和预订帐户，可以收取的(以任意单元定义的)资金数量
charGE 定义支付流行为的复合元素
CITY 持卡人所在城市
COMMENT1 只用于报告目的用户定义值
COMMENT2 只用于报告目的用户定义值
COUNTRY 持卡人的3字符国家代码
CURRENCY 金额的货币
CVV 来自***正/反面的3-位或4-位CVV/CVC代码
CVVRESP CVV响应，仅仅是建议
DEBIT 用来表明余额调整必须是借记卡而非缺省的***
DEPOSIT 定义预订的资源流行为的复合元素
EDGEID 提交这个AUTH的Edge的ID
EMAIL 持卡人的email地址
EXPDATE ***的过期日期
GATEWAYRESPONSE 可选，更详细地说明AUTH失败的处理器专有数据
IMAGE 对于定单中的商品可从Internet访问的URL
INQURESPONSE 包含所查询的交易的RESPONSE对象的XML对象
MACCT 销售商的带有PPCN的帐户名
NAME 定单中商品的名字
NAMEONCARD 卡上的持卡人名字
OFFSET 定义订购收费周期结束之前的时间长度，在订购收费周期结束时将试图收取额外的收费以为订购提供资金
OPERATOR 外部应用程序可以用来识别谁提交了这笔交易的标识字符
ORDER Order(定单)消息的顶层元素
ORDERINFO 包含与Order交易中购买的物品有关的信息
PERIOD 更新订购支付或资源分配的周期
POSMODE 使用销售点(POS)设备的模式
POSTAL 持卡人的5到9位邮政编码
PPCNDATA 由Peppercoin定义并由Peppercoin提供的标
准处理机支持的帐户数据的容器
PRODUCTKEY 产品类别
QUERYID 这个请求的销售商ID。如果这是在帐户查询(ACTQ)中提供的，它将在响应中被返回
QUERY-PARAM 带有值为“BRIEF”或“FULL”的可选属性RESPONSE的空元素。如果不存在，响应将为BRIEF。
REFID 索引ID，用于收取、取消、查询交易和赊贷交易
REQUEST 从客户端发送的主要消息；通常是最高级，但可以被包含在ORDER中
REQUESTID 这个请求的销售商ID
RESPAMT 授权***的金额
RESPMSG 描述给出的响应代码的消息
RESPONSE 对请求(或ORDER)的呼应，通常是最高级，但可以被包含在INQURESPONSE中
RESULT 主要呼应代码，表示成功或失败
SERVERID 标识作为交易源的销售商服务器的帐户
SERVERKEY 作为交易源的销售商服务器的密钥/密码
STATE 美国持卡人所在州-两个字符的代码
STATUS 帐户状态：ACTIVE|PENDING|EXPIRED|DISABLED之一
STREET1 持卡人的街道地址(例如，第12大道)
STREET2 持卡人街道地址的第二行(可选)
TRACK1 来自Track1的card swipe
TRACK2 来自Track2的card swipe
TRXTYPE 交易类型；标识要进行的操作，并且隐含地确定还有哪些元素是有效和/或必需的
附录G-合并参数
智能合并参数 参数说明
业务模式 这个特定帐户的业务模式：按使用付费、预付费、订购、后付费
接受的支付工具 这个业务接受的支付工具：Visa、MasterCard、American Express、Discover
Visa和Mastercard交换分类 告诉智能合并***对这个业务销售商的完全合格的Visa和MasterCard交换类别。假定完全合格的交易将以所选择的类别的速率被处理智能合并将在优化交换资格中自动考虑交易级问题。智能合并看不到业务级交换资格问题；这里指定了错误的类别将不会影响大额交易的归类，但将导致不正确的合并优化。
对Visa和MasterCard的收单者和处理者费用 支付给为未合并的交易支付的收单者和处理者的总处理费用。这些费用是除Visa和MasterCard的交换费用之外的。
AmericanExpress/Discover处理费用 告诉智能合并***对American Express、Discover和其它基于非交换***的销售商处理费用
储备成本 每年的储备成本。这个数值用来估计金融影响，例如扩展合并窗口的投资成本
欺诈率 预计为欺诈性的交易的期望比例
客户服务率 预计触发客户服务请求的交易的期望比例
授权金额策略 设置计算每笔交易的授权金额的策略。选项包括：由销售商确定的固定金额；由销售商业务中或针对特定产品类别的平均购买行为确定的动态金额；基于过去从这个销售商的消费者购买行为的分析的动态金额；或者基于对过去在其它业务中的这个消费者购买行为的粗略分析的动态金额。交换分类考虑可以限制该金额，销售商规定的总上限也限制了这个金额。
授权最大窗口长度策 设置计算每笔交易的合并窗口中的天数的策
略 略。该计算针对交换分类优化考虑平衡观察到的行为。确定窗口大小的选项包括：由销售商确定的固定长度；由销售商业务中或针对特定产品类别的平均购买行为确定的动态长度；基于过去从这个销售商的消费者购买行为的分析的动态长度；或者基于对过去在其它业务中的这个消费者购买行为的粗略分析的动态长度。消费者的支付工具专有的交换分类考虑可以改变计算参数，销售商规定的总上限也是如此。
首次消费者策略 设置处理首次消费者的策略。策略包括：不合并首次消费者，或者将首次消息者当作低活跃度、中活跃度或高活跃度消费者。
合并交换类别策略 控制如果合并策略确定交换分类不是最有效时是否允许策略改变交换分类。通过降级的存款必须超过门极效率金额。选项包括强制合并停留在完全合格的交换类别中，允许降级到中等合格的类别，或者允许降级到不合格的类别。
最大合并交易金额 给合并成的大额交易的最大金额设置一个上限
最大小额交易金额 合并成的大额交易中一笔小额交易的最大金额
最大小额交易数量 一个合并成的大额交易中小额交易的最大数量
最大合并窗口大小 合并时间的最大天数。有多种因素可以减小实际的合并时间，包括：消费者购物的频率；基于交换分类的限制；动态的成本/收益分析；以及其它因素。
周期性合并窗口结束 在周期性的边界上结束合并，例如每天，每周的一个特定日子，或者每个月的特定一天
合并选择加入/退出 允许消费者选择加入或退出合并。控制选择加入或选择退出是缺省选项。
支付工具验证策略 在合并之前确保消费者的支付工具有效。用对目标收取金额或1美元的授权来验证支付工具。这个设置主要影响不需要提前授权的合并策略的行为
验证持续时间 先前的支付工具验证的持续天数。如果***具有比这个天数更新的验证信息就不再重新验证
AVS策略 控制是否在每笔交易上需要AVS匹配
CVV策略 控制是否必须向每笔交易提供有效的CVV代码
最大小额交易速度 限制消费者在速度检查周期中只能进行指定数量的交易。如果这个数量小于或等于零，就不检查速度。
速度检查周期 检查指定周期中的交易速度：以指定的偏移每天或每小时
欺诈记录合并截止点 欺诈记录大于这个数字的交易不会被合并
客户服务记录合并截止点 客户服务记录大于这个数字的交易不会被合并
附录H
PCT申请US02/12189
用于小额支付交易的方法和***
对相关申请的交叉引用
本申请主张下列申请的优先权：1)美国临时申请序号60/287,251，题为“用于小额支付交易的方法和***”，2001年4月27日提交；2)美国临时申请序号60/306,257，题为“用于小额支付交易的方法和***”，2001年7月18日的提交；3)美国临时申请序号60/344,025，题为“用于小额支付交易的方法和***”，2001年12月26日提交；在这里通过全文参考引入所有这些申请，下面将进行充分阐述。
背景技术
电子商务***的增长已经导致跨越电子网络发生的金融交易数量的快速增长。通过为金融在线小额服务(如信息获取服务)提供方便的方法，小额支付带来了新型的电子商务交易。小额支付的价值可能非常低，在有些情况下甚至不到1美分，但却可能被非常大量地进行。例如，信息服务提供商可能希望以很小的盈余来对它们的服务收费。可以用小额支付来支付访问的每个网页或者流向用户的每分钟音乐或视频。
一种简单形式的电子支付方式是电子支票。电子支票由数字签名而不是手签的支票组成。数字签名能让支票的接收者核对签署方的真实性以及支票内容的完整性(例如，支票的日期和金额)。关于公有密钥加密的文献提供了很多方法用于实现数字签名，例如Communications of the ACM，Vol.21，No.2，1978，S.120-126，Rivest，R.L.，Shamir，A.，和Adleman，L.A.所著“A method for obtaining digitalsignatures and public-key cryptosystems”中所说明的RSA方法。众所周知，公有密钥密码***的各方使用唯一的一对密钥。每对包括一个公有密钥和一个相应的私有(或保密)密钥。尽管公有密钥为公众所知，但相应的私有密钥只有所有者才能知道和访问，所有者保持它并保持它的机密性。不能通过计算从相应的公有密钥的信息或发现获得私有密钥。因此，将公有密钥公开不会威胁到相匹配的私有密钥的安全。因为除了所有者之外从没有任何人能够访问私有密钥，与在各方之间共享保密密钥的***相比，公有密钥加密***的安全性更高。
在公有密钥加密***中，希望安全发送消息的发送者获取接收者的公有密钥并用它来加密消息。在接收到加密消息后，接收者用他的相匹配的私有密钥将之解密并读取原始信息。不必访问相匹配的私有密钥，通过计算就能够解密加密消息。
在公有密钥数字签名方法中，消息的签署者通过将他的私有密钥应用于消息而创建他的数字签名。产生的数字签名因而对消息和用来产生该数字签名的私有密钥都是唯一的。拥有该消息和该数字签名的任何人都能够用签署者的公有密钥验证该数字签名的真实性。
在很多公有密钥数字签名方法中还使用了散列函数。散列函数是一种算法，当被应用于一个消息时，以通常具有固定长度的“散列值”的形式产生该消息的数字“指纹”。“单向抗冲突”(或安全的)散列函数是能够从消息的散列值获得原始消息甚至能够找到具有相同散列值的两个消息的散列函数。消息的散列因而能够起到识别消息“指纹”的作用，因为如果对消息进行了任何改动，即使是最轻微的改动，也一定能获得具有不同散列值的消息。
通常以“散列并签署”方式在数字签名方法中使用散列函数。为了以这种方式产生数字签名，消息的发送者将散列函数应用于消息，因而为该消息计算出了消息摘要或散列值。发送者然后将他的私有密钥应用于该散列值以获取他对该消息的数字签名。
可以用发送者的公有密钥和用来产生签名的散列函数核对数字签名的真实性以及消息内容的完整性。接收者通过重新计算该消息的散列值然后应用以这个散列值和发送者的公有密钥作为输入的验证过程就能够验证该消息是否确实是由发送者签署。例如，该验证过程可以用发送者的公有密钥作为解密密钥，如果解密得到了该消息的重新计算出的散列值就接受该消息为有效。如果验证成功，接收者就可以确认发送者确实签署了该消息并且该消息自它被签署后没有被改动过。
在典型的电子支票支付方法中，用户通过向标识一个交易的一块数据提供数字签名而向销售商支付该交易。其中该数据可以标识用户、用户的银行帐号、销售商、要支付的金额、交易时间和/或已经购买的信息、服务或商品。通常，销售商通过将他从用户接收到的电子支票发送到银行而存储该支票。
电子支票方法中的数字签名功能可以由数字证书支持。数字证书是最通用的电子文档，它表明一个特定的个体持有与证书中给出的公有密钥对应的私有密钥。换句话说，证书将一个密钥对与特定的一方关联在一起。因为证书自身是由所信任的机构签署的，数字证书通常被相信是指定方确实拥有证书中列出的公有密钥并且指定方独自控制相应的私有密钥的证据。数字证书还表明当事人被授权签署电子支票或进行其它指定活动。
在核对了电子支票上的数字签名后，银行可以为销售商存入适当的金额，并且从用户扣除适当的金额。银行还可以收取任意的交易费用或其它费用。
电子支付***，尤其在特定的小额支付***中，面临着很多挑战。小额支付的基本问题是银行对小额支付的处理费用。常常，银行处理小额支付交易的费用大于小额支付自身的价值很多倍。例如，处理***交易通常花费约25分，而典型的小额支付可能只值1分甚至更少。因而需要特别的效率以便支付小额支付；否则支付机制的成本会大大超过支付的价值。
小额支付方案因而试图通过将很多小额支付合并成更少但更大的支付而降低银行的处理费用。有很多合作策略可用。有些小额支付方案有会话-级合并：在给定“会话”期间一个用户和一个销售商之间的所有支付都被合并成更大的支付。另一策略是全局合并：跨越所有用户/销售商对合并支付。全局合并能够提供更大的灵活性和更大的费用节省。
现有多种小额支付方案，在文献中能够找到综述，例如在PeterWayner，Academic Press 1996的“Digital Cash：Commerce on the Net”中。现在知道的小额支付方案包括(在Ronald L.Rivest和Adishamir发表在Fourth Cambridge Workshop on Security Protocols，SpringerVerlag Apr.1996的“PayWord and MicroMint：Two simplemicropayment schemes”中说明的)支付字(PayWord)和(RonaldL.Rivest在Proceedings of FinanCial Cryptography 97，vol.1318 ofLecture Notes in Computer SCience.pp.307-314，Springer 1997中说明的)“电子彩票方案”(electronic lottery scheme)。其它已知的小额支付方案包括但不限于manasse等的“Millicent”，Rivest和Shamir的“MicroMint”，Anderson的“NetCard”，Jutla和Yung的“PayTree”，Hauser等的“MicroiKP”，Jarecki和Odlyzko的概率轮询方案(probabilistic polling scheme)，Wheeler对“使用bets的交易”，Pedersen的类似提义，以及Lipton和Ostrovsky对通过有效的硬币-翻转的小额支付的有关提义。jarecki/Odlyzko概率轮询方案在美国专利号5,999,919，题为“EffiCient Micropayment System”中公开，并且在1999年12月7日被发布给Stanislaw Jarecki和Andrew M.Odlyzko。
PayWord是基于公有密钥数字签名方案和单向散列函数的小额支付***。在PayWord***中，用户从银行接收一个数字证书，该证书授权用户产生散列值链，或“支付字”(payword)wi。这些支付字可以由销售商从银行以钱的方式拿回。第i个支付字通过关系式：wi＝h(wi+1)与第i+1个支付字相关，其中h是单向散列函数。因而通过计算不可能从h(wi+1)获得wi+1。通过在wi+1上运行散列函数，销售商可以用第i个支付字验证第i+1个支付字wi+1。在PayWord方案中，用户计算一个散列值链，w0，w1，......，wn，并通过将根w0的数字值发送给销售商而提交整个链。此后，用户通过依次连续地揭示支付字(w0，w1，......，wn)而向销售商进行每次成功的支付。通过在该链中的每个连续的值上运行散列函数以检查它是否被散列到支付字链中的前一个值，销售商可以验证该链中的每个连续的值。
PayWord允许销售商方便地合并购买者的支付。在已经进行了k个小额支付后，如果销售商感觉将它们合并在一起这k个小额支付能够构成一个足够大的大额支付，销售商可以向银行一次存入k分(或者其它表示每笔小额支付的合适的金钱单位)。供应商只向银行报告两个值wk，以及w0的用户签名。银行验证w0的用户签名，并在wk上重复散列函数k次以验证这个操作确实产生w0。在验证后，银行向供应商的帐户支付k分，并从用户的帐户收取k分，然后根据自己的判断收取其它交易费用。
PayWord受制于销售商不能合并不同用户的小额支付这个缺点。这是因为在PayWord中，每个用户必须与销售商建立他自己的散列值链，并且不能合并不同的散列值链。很多其它小额支付建议，如Millicent，也遇到了这个不能跨越不同的用户/销售商合并小额支付的问题。也就是说，PayWord只提供了会话级的合并，而不是全局合并。
Rivest的电子彩票方法提供了另一种合并小额支付以降低交易成本的方法。这个方法基于每个小额支付的选择比率或选择概率(0＜s＜1)：平均，每1/s个小额支付中只有一个被选择进行实际支付。选择比率s是已知的、可预测的和固定的。对于提供给销售商的每笔小额支付，销售商首先验证PayWord链的根w0上的用户签名并验证所提供的散列值wk在被反复进行了k次散列后是否产生w0。如果是，销售商就接受来自用户的小额支付。销售商然后与用户通过预定的交互协议以便确定该小额支付是否被选择存入银行。没有选中的支票不能被存入，因而对销售商来说是没有价值的；因此被销售商丢弃。只有(通过交互协议)被选中的小额支付才会被销售商真正提供给银行以接收支付。这样，银行不必处理每一笔小额支付，而是平均在1/s笔小额支付中只处理一笔。由此大大降低了银行的处理成本。为了使这个过程对销售商公平，对于每笔选中的小额支付，销售商得到的支付都比初始指定的小额支付额大1/s倍。换句话说，银行向销售商支付的是该小额支付的面值放大1/s倍后的数额。
除了优势之外，电子彩票方法遇到的问题是用户和销售商必须为每笔小额支付交互以便确定是否选择一个特定的小额支付进行存储。这个要求大大降低了电子支付***的速度，有些情况下使得该方案不切实际。
因为前面的原因，需要一种非交互的小额支付方法和***，它能够对小额支付进行全局合并以将银行处理成本降至最低，但它同时在小额支付选择过程中不需要用户-销售商的交互。
另外，希望将时间限制引入到小额支付***中。例如，在支付***中包括要求销售商在合理的时间段内在银行中存入任何应支付支票(即被适当选中进行存储的小额支付)以便从银行接收支付是有利的。这样，就不会过晚向用户收取费用，即在交易的可能费用已经不在用户的预算中时才向用户收取。这种类型的限制还给消费者带来了额外的刺激以验证支票C上的时间信息是否精确，由此提高了***的安全性。
除了由选择过程中用户-销售商交互带来的低效率之外，概率小额支付方案内在的另一问题是向用户收取的费用超出他实际花费的风险。概率小额支付方案中的用户必须应付在某些情况下不太走运时他可能不得不支付比他实际花费要多的费用(虽然概率不高)。这种情况比较少见，但这种少见的情况的相对影响会大大降低进行小额支付的数量。此外，超额收取的概率(虽然很小)会对该方案的广泛接受构成强烈妨碍。这是因为普通用户通常不习惯于管理风险。
因为前面的原因，需要一种小额支付方法和***不仅将银行处理成本降至最低还能确保用户永远不会被收取超过他实际花费的费用。
最后，试图提高它们的效率的小额支付***通常只针对已经被销售商选择进行支付的那些支票才请求银行采取行动，但这些支付通常只构成了支付总数的一小部分。但是，这种支付***没有向银行提供支付选择过程上的任何灵活性或控制。这种控制有利于银行管理风险。
因此希望有一种小额支付方案不仅减少对选择过程中用户-销售商交互的需要并将过量支付的风险从用户转移到银行或销售商，还向银行提供了支付选择过程上的灵活性或控制。
发明内容
本发明涉及概率支付方案，它们允许用户U(或其它付款人，此后称为“U”或“用户”)为至少一笔交易T向销售商(或其它收款人，此后称为“M”或“销售商”)建立支付。通常，T的价值Tv非常低，但本发明特有的方案适用于任意值的Tv。本发明特有的小额支付方案将用于处理这种小额支付必需的成本降至最低，由此大大提高了***的效率。还提供了多个额外的优势，下面将进行说明。
在本发明的第一实施例中，提供了一种小额支付协议，它允许销售商在接收到支票后马上不必和用户交互就能立即确定该交易是否应该被选择进行支付。不像现有技术的概率小额支付方案，这个实施例中的小额支付协议不需要将应支付确定延迟到交互选择协议在销售商和用户之间发生。
在本发明的第二实施例中，本发明的小额支付方案将时间限制引入到了***中并以特殊方式使用它们。这些时间限制要求在支票上提供与交易的时间和/或日期有关的信息并且支票上的时间信息满足预定标准以便该支票被选择进行支付。
在本发明的第三实施例中，提供了选择性存入协议，它降低了用户被收取的费用超出实际花费的任何风险。
最后，本发明的第四实施例特有的延迟选择协议，它向银行(或其它第三方或代理人，此后称为“银行”)提供了支付过程上的控制和灵活性。
在根据本发明第一实施例的小额支付方案中，用户U使用涉及交易T的记录以便产生与T有关的数据串C。C可以是通过使用用户的保密密钥创建对T的数字签名而签署的电子支票。用户使销售商接收支票C。在接收到C后，销售商将C与用户完全不可预测的一个数据项V关联起来。销售商可以使用只有销售商知道的保密信息SI以便将V与C关联起来。例如，V可以是销售商对C的数字签名，由SIGM(C)表示，并由销售商用公有密钥数字签名方案中销售商的保密签署密钥产生。
销售商然后确定V是否满足属性P。在优选形式中，属性P可以与给定支票C被选择进行支付的概率(0＜s＜1)有关。如果销售商确定从电子支票C获取的数据项V不满足属性P，销售商就简单丢弃支票C，并且银行永远看不到支票C。如果销售商确定数据项V(例如，SIGM(C))满足属性P，销售商就让银行接收到让银行也能够验证V是否满足P的信息I。例如，I可以是(或者可以包括)销售商用于数字签名方案的公有密钥，与销售商用来创建V的私有密钥相对应。在接收到I后，银行着手独立验证V是否满足属性P。如果银行确认V实际上满足属性P，那么银行就让销售商或除销售商、用户、或银行之外的第四方接收金额A。金额A通常大于Tv，并且在一种形式中可以与Tv和概率s的倒数的乘积有关。金额A可以由A＝[Tv *1/s]给出。
依照本发明的第一实施例为交易T建立支付的***包括用于在第一方(用户或其它方)、第二方(销售商或其它方)、第三方(银行或其它方)和第四方之间传输电子数据的通信信道。该***包括可由第一方操作以输入并存储从T获得的数据串C的装置。该***还包括可由第二方操作并响应C用于输入和存储与C的至少一部分相关并且第一方完全不可预测的数据项V的装置。该***还包括由第二方在V满足P时选择性操作以使第三方接收让第三方能够验证V是否满足P的信息的装置。该***还包括可由第三方在V满足P时选择性操作以使第四方接收金额A的装置。
在本发明的第二实施例中，时间限制被引入了上述非交互小额支付协议中。在这个实施例中，用户能够为由时间t部分表征的交易T向销售商建立支付。通常，时间t表示交易发生时的日间和/或日期。用户创建与T有关的数据串C。在这个实施例中，C必须包含与T的时间t有关的信息。用户引起销售商接收C或至少C中包括涉及t的信息的那部分。销售商将C(或接收到的C的一部分)与用户完全不可预测的数据项V相关联。数据项V是C上的时间信息的函数，例如(用销售商的私保密密钥创建的)C中包括时间信息的至少一部分的销售商数字签名。V还可以是G(C)的数字签名，其中G(C)表示C的函数或者使用C的算法。例如，G(C)可以是返回C的时间/日期信息(例如，C的完全相同的时间/日期信息，或者“上取整”后的时间/日期信息)，或者C涉及的交易T的时间/日期信息。销售商然后确定V是否满足属性P。如果V满足P，销售商在时间t’让银行接收使银行能够验证V是否满足P的属性信息I(可以包括与销售商用来创建V的私有密钥相对应的公有密钥)。
在本发明的第二实施例中，为了让银行使第四方接收金额A，t’-t必须小于预定的时间间隔。这是除了要求V满足P之外的另一个要求。换句话说，银行只在销售商提供所包含的时间(T发生时的时间)在规定时间限制内的应支付支票时才将钱存入销售商的帐户。例如，如果交易T在i天发生，可以要求销售商在i天、或i+1天或i+n天结束前存入相应的支票C，其中n是预定的整数。因而协议中的时间限制要求及时存入。要求及时存入通过确保用户不会被过晚收取费用而带来了好处；它还允许银行控制其它形式的风险，例如来自过期支票的那些风险。
在本发明的第三实施例中，提供了选择性存入协议，它确定用户不会被收取超出实际花费的费用。对于一个或多个交易Ti(i＝1，...，n)中的每笔，用户根据基础的概率支付方案获取面值为TVi的支付/小额支票Ci(可能仅仅价值银行处理Ti这样一笔交易必需成本的一部分)。
在本发明的第三实施例中，每个支票Ci包括一个优选地从1开始的渐进序号Si。序号Si优选地表示支票Ci在由用户获得的时间有序的支票序列中相对于其它支票的位置。在第三实施例中，用户的总支付金额被确保绝不大于用户实际花费的总金额，为方便起见由TVagg表示。通常，当用户签下他的第i个支票时，总金额TVagg由他的支票的总金额给出，即TVagg＝TV1+TV2+…+TVi。
例如，如果Ci是所发现的应付的第一个支票，Di是相应的支付金额，本发明的第三实施例特有的小额支付方案强制Di不大于TVagg＝TV1+TV2+…+TVi。这个保证是通过一种协议实现的，在该协议中银行跟踪它从销售商接收到的支票的序号。在向用户收取费用之前，银行必须在有序的支票序列中确定最后一张支票上的序号Smax，根据它进行支付。在一个说明性例子中，所有交易价值都等于TV。在这种情况下，如果Ci是下一个应支付支票，银行就向用户收费Di＝(Si-Smax)*TV。金额Di因而只取决于用户自上次进行支付后已经签署的支票的数量，并且总的收费金额被确保不大于Si *TV。
最后，在本发明的第四实施例中，提供了延迟选择协议，它向银行提供了对支付过程更大的控制和灵活性。如本发明先前的实施例一样，用户为价值TVi的一个或多个交易中的每一笔交易获取一个数据串或“支票”Ci，并使销售商接收Ci。
在本发明的第四实施例中，销售商唯一地将他已经收到的支票Ci分成m个列表Lk，其中k＝1，…，m。每个列表Lk包括包括数据串Ck 1，…Ck lk，共中lk表示给定列表Lk中支票的总数量。因而，如果n是所有m个列表中支票的总数量，则∑m k＝1lk＝n。
销售商通过为每个Lk计算提交CMk而提交m个列表Lk(k＝1，…，m)。提交CMk优选地是散列值H(Lk)，其中H是单向散列函数。销售商使银行接收提交CMk(k＝1，…，m)。
在接收到CMk(k＝1，…，m)后，银行通过选择一个或多个整数索引i1，i2，…，ir实现本发明的第四实施例特有的延迟选择协议。r的值任意，取决于银行。银行使销售商接收所选择的索引i1，i2，…，ir。
在接收到所选择的索引i1，i2，…，ir之后，销售商回收CMi1，CMi2，…，CMir，由此向给第三方(如银行)揭示了Li1，…，Lir。第五方(可以是银行、或除银行之外的实体)使第四方(可以是销售商或销售商之外的实体)接收存入金额CR。第五方使用户被扣除金额D。
优选地，存入金额CR与Vk有关，而Vk表示特定列表Lk中包含的所有支票的总值，即Vk＝TVk 1+…+TVk lk。存入金额CR可以由所有m个列表中包含的所有支票的总值给出，即CR＝V1+…+Vk+…+Vm＝∑m k＝1Vk。在这种情况下，当提供了对列表的提交CMi时，对值Vi的提交可能已经被提供给了银行；那么在银行通过指定它们的索引而从列表中选出一些之后所有值Vi都被回收。
或者，存入金额CR可以与那些索引被银行选中的列表中包含的所有支票的总值有关。这个存入金额CR可以按一个放大因子(如m/r，其中整数m和r是上面提到过的)与刚刚提到的总值相关，以便反映银行只看到支票的r/m部分的事实。
可以用多种方式之一获得相应的扣除金额D；获取D的方法的选择可以与计算CR的方法有关或无关。例如，值D可以与那些索引被银行选中并转发给销售商的列表中包含的所有支票的总值Vi1+Vi2+…+Vir有关；例如这个和的值可以被按照一个因子(如m/r)放大。或者，可以从存入金额CR获取值D；例如，它可以等于存入金额CR。或者，可以从以前面说明的方式选择的列表中包含的支票上的序号获得值D。在大多数应用中，将有多个不同的用户，并且向每个用户收取的金额无论如何都将取决于所选择的列表中该用户签署的那些支票。计算每个用户U的扣除金额DU的优选方法是使用基于用户U所签署的支票的序号。
附图说明
结合附图参考下面的详细说明能够更彻底地理解本发明，在附图中：
图1以示意流程图的形式提供了依照本发明的第一实施例的小额支付交易方法的概观；
图2提供了一个示意结构图，示出了依照本发明的第一实施例用于为交易建立支付的小额支付***的组件；
图3以流程图形式提供了依照本发明的第二实施例的小额支付交易方法的概观；
图4以流程图形式提供了依照本发明的第三实施例的小额支付交易方法的概观，该方法包括选择性存入协议，它消除了向用户收取的金额超出实际花费的风险；
图5提供了一个示意结构图，示出了依照本发明的第三实施例用于为交易建立支付的小额支付***的组件；
图6以流程图形式提供了依照本发明的第四实施例的小额支付交易方法的概观；
图7提供了一个示意结构图，示出了依照本发明的第四实施例用于为交易建立支付的小额支付***的组件。
具体实施方式
在本发明中，提供了提高小额支付方案的效率和灵活性的方法和***。
在本发明中，小额支付***至少涉及第一方、第二方和第三方。在本发明的一种形式中，第一方可以表示付款人，例如购买者或用户。第二方可以表示收款人，例如商品的销售商或服务的提供者。第三方可以表示代理商或银行。还可能涉及更多方。在有些情况下，单个实体可能扮演不止一方的角色：例如，第二方和第三方的角色。例如在用户希望向他自己的银行进行小额支付的情况。或者，单个实体可以扮演第二方和第四方的角色。
为引用方便起见，在下文中我们分别用术语“用户”代指“第一方”，用术语“销售商”代指第二方，用术语“银行”代理第三方。但是，将会理解第一方不必一定是用户，第二方也不必一定是销售商，第三方也不一定是代理商或银行。
最后，在依照本发明的小额支付方案中还可以涉及更多方。例如，第三方可以使第四方(可能与第二方对应)接收支付。例如，第一方可以是通过收费站的驾驶者的支付设备，第二方是收费站的设备，第三方是驾驶者的银行，第四方是收费的实体。在这种情况下，驾驶者可以向收费站设备提供小额支付，如果出现适当条件可以由驾驶者的银行向收费实体进行支付。又比如，可以涉及第五方：第三方可以使第五方向第四方或第二方进行支付。例如，详细说明前面的例子，第三方可以是支付设备的制造商或者控制或出租该支付设备的实体，第五方可以是驾驶者的银行，它最终支付第四方。相同的第五方、或第三方或另一第六方可以实际代表自己向第一方或另一方收取费用。
I.非交互小额支付方案
在本发明的第一实施例中，提供的小额支付方案消除了销售商与用户交互的以便确定是否应该选择一个特定的支付的需要。在这个实施例中，当用户希望进行支付时，用户创建一个电子文档或“支票”，并使销售商接收该支票。在这个实施例中，销售商可以在接收到支票后立即确定是否该支票应该选择提供给银行，以使对用户帐户的适当扣除和销售商帐户的适当存入能够发生。销售商不必与用户交互能够进行这样的判断。不像现有技术中的电子彩票支付方案那样，不需要将这个判断延迟到交互选择协议在用户和销售商之间发生。这样，大大提高了小额支付过程的效率。
在本发明的第一实施例中，用户通常因为一个交易T或一系列这样的交易T而需要向销售商支付费用。交易通常由交易价值Tv表征，Tv可能非常低，例如一分甚至几分之一分。如果银行要为每笔单独的交易处理支付，银行因此要承受比交易价值自身大得多的处理成本。
图1以示意流程图形式提供了依照本发明的第一实施例的小额支付交易方法的概观。当用户希望在依照本发明的支付方案中进行支付时，用户创建一个数据串或“电子支票”C，并将C发送到销售商，或者使销售商接收C。支票C通常是从交易的记录T获取的。例如，可以通过使用用户的保密密钥为交易创建数字签名SIGU(T)而创建支票C；由销售商验证用户的这个签名。用户的签名SIGU(T)可以包括或者伴随与T有关的足够信息以确保这个验证能够进行。用户还可以使销售商接收或者在C中引入使得能够验证他的数字签名的数字证书-例如，指定用来验证U的数字签名的U的数字签名的数字证书。每个支票C被选择进行支付的概率或选择比率是s(0＜s＜1)。
销售商将支票C与用户实际不可预测的用销售商的私有密钥产生的一个数据项V相关联，例如C的数字签名。销售商然后决定V是否满足特定的属性P。在本发明的优选实施例中，V满足P的概率等于选择比率s。如果销售商发现V确实满足P，销售商就使银行接收到使银行也能够验证V是否满足P的信息I。否则，销售商丢弃支票C。在接收到I之后，如果支票C上有用户的签名，银行可以验证该签名，如果签名没有通过验证就丢弃该支票。银行可以进行其它测试，例如与用户在银行的帐户的状态有关的那些测试，例如确定帐户是否具有良好的信誉(例如，是否已经取消了相关用户的数字签名)；如果没有通过这样的测试，银行选择不兑现支票。银行然后验证V是否确实满足P，仅当V满足P时银行使销售商接收金额总和。
现在更详细地涉及本发明中特有的小额支付方案的每个元素，在本发明中引起支付的“交易”覆盖了用户必须向销售商付费的大范围的可能情况。例如，用户可以向销售商付费以购买服务、或信息或物理商品。或者，用户可以只是向销售商付费而不进行任何购买，例如为了向销售商进行捐赠。典型交易T的例子包括但不限于用户一个网页一个网页(每个访问的网页代表一个单独的交易)地访问信息网站，或者音频/视频材料被一分钟一分钟(每分钟传输的音频/视频材料代表一个单独的交易T)地传输给用户。
交易的记录T可以是包括交易的说明细节的数据串。例如，记录T可以指定下列中的一个或多个：要支付的金额；要购买的商品的说明；用户和/或销售商的身份；用户和/或销售商的公有密钥；用户和/或销售商的数字证书；交易的日期和时间；任何相关第三方的标识，例如银行和金融服务提供者，以及识别用户帐户所需的额外信息。交易在下文中按照表示交易的记录T表示，即术语“交易T”将用来指代表交易的记录T。
用户获得的数据串C通常表示电子支票(有时也称作付款提交书)，它包括用户对为交易支付特定金额的提交。通常，支票C的标称面值是交易T的交易价值Tv。支票C中也可以包括其它信息。例如，C可以包括交易T，或交易T的至少一部分，或者是交易T的指示。在本发明的优选实施例中，对数据串或电子支标C或C的至少一部分进行了验证。如现有技术中已知的那样，验证可以用多种方法进行。例如，可以通过数字签名或通过消息验证代码或通过在验证过的会话中发送而验证支票C。这个验证方法在用户希望进行匿名购买的环境中尤其有用。现有技术中已知的任何其它验证也在本发明的范围内。
用户在创建支票C时可以使用用户已民知但销售商不知道的私有信息。通常，对于不知道这个保密信息的人，不可能通过计算创建支票C。在本发明的优选实施例中，创建支票C的过程涉及用户在公有密钥数字签名***中创建数字签名，用户用来创建C的私有信息是它在这个***中的保密签署密钥。在这个实施例中，数据串C包括用户在这个***中对交易T的数字签名，由SIGU(T)表示。SIGU(T)是用户用他的保密密钥创建的。用户可以用现有技术中已知的数字签名方案的任意一种创建他的数字签名。尤其，用户的数字签名方案可以包括但不限于下列方案：确定性签名方案；随机签名方案；Shamir提出的基于身份的签名方案；在线签名方案；离线签名方案；指定验证者方案。数据串C还可以包括其它信息，例如与交易T有关的信息。
在创建了电子支票C之后，用户使销售商接收C。用户使销售商接收C有多种方式。用户可以简单地将支票C发送给销售商。或者，用户可以请求另一方将支票C发送给销售商。用户可以使销售商在不同的时间接收或访问支票C的不同部分。例如，在交易T发生之前，用户可以使销售商提前访问用户的公有密钥。随后，用户可以使销售商在稍后的时间接收或访问C的用户数字签名，或C的一部分，或与T(或它的一部分)有关的一个数量。
销售商可以确定支票C是否可接受，即支票C是否确实由该用户签署，以及支票C的内容是否真实完整。为了完成这一点，销售商可以检查创建支票C的用户特有的公有验证信息。例如，这个用户专有公有验证信息可以是与用户创建C使用的私有密钥对应的公有密钥，或者更一般地说是证明用户被授权进行小额支付因而他的小额支付会被兑现的数字证书。相同的数字证书可以用于两个目的，即表明用户被授权进行小额支付和给定的公有密钥应该被用来验证小额支付支票中他的数字签名。销售商可以使用用户的公有密钥来验证支票C上的数字签名是否可信，即是否确实由用户创建。如果用户使用了基于身份的数字签名方案，该公有验证信息可以包括用户身份的说明。这个用户专有公有验证信息可以由销售商直接从用户获得。或者，这个公有验证信息可以由销售商从数字签名获得，或者从与用户有关的公开可用的信息(例如发布的公有密钥手册)获得，或者从用户与支票C一起或作为支票C的一部分发送的信息中获取。该“用户专有公有验证信息”不必对普通公众可用；它只需对销售商和银行可用。
销售商可以采取步骤检查他获得的用户专有公有验证信息的真实性。这些步骤包括但不限于：验证与用户专有公有验证信息有关的数字签名或其它验证信息；验证数字证书上的签名；检查数字证书的过期日期；以及确定数字证书是否已经被取消。销售商还可以从数字证书确认用户确实被授权签署电子支票C；这可能涉及对支票C中的金额、帐号、序号或其它信息的进一步检查。
销售商将他接收到的每个支票C与用户完全不可预测的一个数据项V关联在一起。例如，用户完全不能预测数据项V是因为用户通过计算不可能从C获得V，即用户需要进行不切实际的计算量才能得到数据项V的值。在本发明的一种实施例中，只有用销售商知道但用户不知道的保密信息SI才能从C获得数据项V。在一种实施例中，保密信息SI可以是销售商在公有密钥数字签名方案中的保密密钥。
在一种形式中，销售商将之与C相关联的数据项V可以是销售商对C的数字签名，为方便起见由SIGM(C)表示，由销售商用公有密钥数字签名方案中的私有密钥创建。销售商所用数字签名方案不必一定与用户用来创建C的签名方案相同，并且很可能是不同于用户的签名方案的签名方案。在这种情况下，如果C等于或包括SIGU(T)，那么数据项V可以由V＝SIGM(C)给出。因此，SIGM(C)对用户来说是不可预测的量，因为用户绝不可能知道销售商的私有签署密码。因此，即使用户可以用他想要的任何方式控制支票C，例如通过选择特定的交易T，但就所涉及的用户来说，SIGM(C)实质上是“随机的”。在本发明的另一形式中，V可以是MAC(消息验证代码)值，由销售商用私有MAC密钥计算；这个MAC密钥可以由销售商和银行知道但不能让用户可知。在本发明的一些形式中，可以分析C的销售商签名以包括销售商的签名或只有C的一部分(例如C中的日期或时间，C中包括的一个随机串，或者C中包含的序号)的MAC或者与C有关的一个数量的MAC。
计算数据项V的步骤在时间上不必一定跟在从用户接收C的步骤之后。例如，数据项V可以是涉及交易T的日期信息的销售商数字签名。销售商可能在接收到C之前已经计算出了这个数字签名。
在当前实施例中，销售商使用一个选择过程确定它已经接收到的支票中哪些应该被“选择”进行支付。销售商只将“选中的”支票发送给银行，并且不发送任何未被选中的支票给银行。对用户来说不可能通过计算在用户创建支票时确定该支票是否将被销售商选中。实际上，用户可能知道甚至可能不知道销售商使用一个选择过程并只将该用户的一部分支票发送到银行，尽管用户很可能最终知道这样一个选择过程。
作为该选择过程的一部分，销售商确定与C相关的数据项V是否满足属性P。在本发明的优选实施例中，确定是否选择支票C进行支付取决于V是否满足P。
在优选形式中，销售商所用选择过程使得能够对每个选中的支票估计它被选中进行支付的选择比率或“概率”。尤其，估计该选择过程可能是选择所有支票中固定的一部分。这样，属性P可以与常数s有关，0＜s＜1，并且s是特定小额支付被选择进行实际支付的概率，并且这个概率是固定的和已知的。或者，V可以以一个概率满足P，该概率可以从数据串C或它的一部分获得，或者从记录T或它的一部分获得，或者从数据串C和记录T的组合获得。换句话说，被选中的支票的比例取决于支票C中用户提供的参数。例如，它可能取决于支票的金额。或者，值s可以在将用户的公有密钥绑定到用户的用户数字证书中指定。或者，可以确保属性P对数据项V的值的固定部分为真。或者，可以确保属性P对V的特定部分F为真，部分F可以从数据串C或它的一部分获得，或者从记录T或它的一部分获得，或者从数据串C和记录T的组合获得。或者，销售商可以从银行获得用来确定s和/或属性P的信息。
可以提前指定属性P，即在交易T发生和从T获得支票C之前。这样的属性P的例子有“V的最后10个比特对应于一个小于x的数，x是一个常数”。或者，可以在交易T、支票C或它们的组合中指定或从其获得属性P。这样的属性P的例子有“V的最后10个比特所对应的数小于C的最后10个比特所对应的数”。确定选择比率s的方式可能涉及上述方法或本领域的技术人员来说显而易见的它们的变体的组合。
在一种形式中，销售商可以使用只有销售商知道的保密信息SI，以确定V是否满足P。这种保密信息S可以包括公有密钥数字签名方案中销售商的私有密钥、或者公有密钥加密***中的销售商私有密钥、或者公有密钥数字加密方案中的销售商私有密钥。优选的，销售商的数字签名算法可以是确定性的。
在本发明的一种实施例中，属性P采用下列形式：
F(V)＝F(SIGM(C))＜s    (1)
F()表示将任意比特串作为输入并返回一个0和1之间的数的公有函数，s是大于0小于1的一个常数并且代表(或至少确定)小额支付方案的选择比率，即给定支票C被选择进行支付的概率。例如，F可以将前面加上零和一个小数来操作输入串V，并将结果表示成二进制数。在这个例子中，如果V是输入串“011”，F将操作V产生“0.011”，它将被解释为十进制小数3/8。因为如上所述SIGM(C)实质上是一个随机(不可预测的)数，所以F(SIGM(C))也是0和1之间随机且足够长的数。因此，F(SIGM(C))小于比率s，因此属性P被满足，实际上用户使销售商接收所有支票C中的s部分。在另一实施例中，函数F先向它的输入应用一个散列函数或其它确定性函数，然后通过如前所述在前面加上0和小数点而继续，并将结果表示成二进制数。在另一实施例中，属性P可以采用下列形式：
F(V)＝F(SIGM(G(C)))＜s    (1’)
这里G()表示应用到支票上以产生一个数据串的函数。例如，函数G可以只返回支票C的序号。
应该强调销售商不需要与用户交互以确定一个支票是否应该被选择进行支付。如果根据等式(1)确定属性P，容易看到销售商能够立即验证支票C是否应该支付：销售商用他自己的私有签署密钥能够不费力地求出F(SIGM(C))，并比较F(SIGM(C))和选择比率s。关键是F(SIGM(C))对用户来说是完全不可预测的；它还应该是一个足够精确的数。对于实际上合理的选择比例(例如1/128或1/1024)来说，10比特长对SIGM(C)和F(SIGM(C))就足够了。而典型的数字签名是数百个比特长，因此显得过多了。
在本发明的这个实施例中，一旦销售商自己已经确定数据项V(例如SIGM(C)满足属性P，销售商就使银行访问信息I，信息I使得银行也能够验证V是否满足P。在本发明的示范实施例中，信息I可以包括与销售商用来创建SIGM(C)的私有密钥对应的公有密钥，或者那个公有密钥的销售商证书。信息I还可以包括C的销售商数字签名，即V或SIGM(C)。销售商甚至可以在生成C之前使信息I的一部分被银行访问到。例如，销售商过去可能给了银行它自己的证书，并且银行可能已经保存了该证书。如果销售商确定从电子支票C获得的数据项V不满足属性P，销售商就简单地丢弃C。银行绝不会看到C。但是，如果支票是被正确创建的，即使没有被选择进行支付，销售商仍将正常地向用户提供该支付要购买的商品/服务。只有(与C相关的)V满足属性P的那些支票C被销售商选择进行支付，并被转发到银行，银行因而被请求只对用户进行的小额支付的一部分采取行动。
因为银行只看到了由用户创建并由销售商接收到的支票中的一部分s，需要进行对支付金额的调节以(至少近似地)解决“丢失的”(未选中的)支票的价值。在进行这种调节的一种方法中，转发给银行进行存入的每张支票产生一个其值是该支票C的指定面值Tv的1/s倍的“大额支付”。这里s是可变的，适用的s是与用来选择C的过程有关的s。例如，如果s是1/1000，交易价值Tv是1分，那么平均1000个小额支付中有1个被选择进行支付，1000个小额支付中有999个被丢弃。这样，平均对1000个小额支付只会引入单笔处理费用，导致了处理费用的大量节省。
银行使用信息I(例如销售商的数字签名方案中的销售商公有密钥)对从销售商接收到的每个支票验证支票C是否确实被选择进行支付。换句话说，对从销售商接收到的每个支票C，销售用信息I也验证V是否满足属性P。如果银行确认V确实满足属性P，银行就让销售商、或除销售商、用户、或银行之外指定的第四方接收与该大额支付的价值对应的金额总和。银行通常将付款从用户的帐户取出存入销售商的帐户或一些指定的第四方的帐户。
银行在特定条件下可以根据自己的判断和/或根据它的策略拒绝支付支付，例如当用户帐户欠款时、当用户的证书被取消时、或者当销售商或用户被怀疑进行了某种欺诈时。例如，银行可以采取步骤确认销售商是否提交相同的支票两次，这样支付最多只被进行一次。银行可以拒绝支付先前已经处理过的支票。银行还可以选择暂停对支票的支付直到用户已经在他的帐户中存入了足够的资金来承担该支票。
本发明的第一实施例中特有的小额支付方案可能涉及四方，第一方、第二方、第三方和第四方，这里所有四方都完全不同。例如，第一方是经过收费站的用户，第二方是位于收费站的设备，第三方是用户的银行，第四方是高速公路所有者。或者，第一方是下载歌曲的用户，第二方是歌曲的提供者，第三方是用户的银行，第四方是歌曲发行人。或者，第三方是第一方(即用户)的银行，第四方是第二方(即销售商)的银行。这样，为了第二方的利益，第二方使用户的银行向第二方的银行进行支付。在本发明的小额支付方案中还可能涉及除第一、第二、第三和第四方的其它方。例如，第一方(用户)将支票C发送给第二方，第二方是一个设备，它将数据项V(如果属性P对V为真)转发给第三方，第三方是用户的银行。用户的银行(第三方)付款给第四方，第四方是收款人的银行，为了收款人的利益，收款人是第五方。
支付数额取决于支票的标称面值以及支票被选择进行支付的估计概率。被从用户帐号中取出然后被存入销售商帐户的支付数额可以等于支票的标称面值乘以支票被选中的估计概率的倒数然后再加上银行分别向用户和销售商收取的任何适当的银行处理费用。
如前所述，小额支付方案对于能够进行低价值商品(如网络文章或网页)的购买是非常有用的。在现有技术中，已经广泛使用了订购方法以使用户能够购买低价值商品。例如，通过订购网络服务，用户实际上将很多未来的低价值交易合并到了单个大额支付中。但，这对用户来说可能不是最优的，因为如果用户目前对一个特定商品感兴趣但不确定他将想或需要访问未来的商品，那么订购的价格可能高于用户想要支付的价格。因此，供应商可能丢失一些业务，因为用户可能决定不订购(即，“提前”进行小额支付)，并且可能放弃他想要的商品。
可以如下通过将订购和单个销售连接在一起而扩展本发明的第一实施例特有的概率小额支付方案。销售商可以向用户提供两个选项：1)让用户能够在特定时间间隔内获得很多商品的订购(例如，订购可以向购买者提供一年内对销售商的所有网页的访问)，和2)按照清单购买单个商品。用户可以根据所声明的价格Tv决定只购买单个商品。用户向销售商支付面值为Tv的概率支票，销售商将向用户提供想要的商品。但是，如果该概率支票应该被选中，该支付将实际使销售商接收高得多的金额，例如当单个支票被选择进行支付时的概率是1/1000时A＝Tv*1/s，这里s＝1/1000。销售商接收到的金额A超过了销售商的订购服务的价格。这样，用户被奖励免费获得订购。如果订购的费用高于A，可以通过作为针对从销售商购买订购的费用的信贷方获得A而奖励用户。
上述将订购和单个销售连接在一起的方法向用户提供了若干额外的激励。为简单起见，假定所有商品都有相同的价格(例如，1分)，订购费为10美元，概率支票面值为1分但在被选择进行支付时实际花费用户10美元，因为下层机制的选择概率是1/1000。然后，用户将看到平均1000个他的支票只有一个成为应支付支票，并且当他实际支付10美元时他还免费得到了一个订购。因此，在某种意义上用户永远不必决定他应该购买一个订购，或者应该按清单选择一些商品：用户可以总是去按清单购买，因为他总是或者免费获得一个商品，或者支付该商品但接着免费得到一个附送的订购。这样，即使该用户在进行1000个1分的购买之前很长时间就进行了一个10美元的支付，该小额支付***总是对用户表现得公平且有吸引力。该过程在销售商看来也是有吸引力的，因为否则他可能丢失一些绝不考虑购买订购的客户。如果销售商感到用户正在得到过多的优惠，还可以将单价Tv向上调一点以包括订购的摊派成本。
图2提供的示意结构图示出了依照本发明的一个实施例为交易T建立支付的小额支付***100的组件。***100包括通信装置110让用户、销售商和银行在它们之间传输电子数据甚至付款。电子数据包括表示电子支票的数据串或表示消息的字串。在一种实施例中，通信装置110可以允许访问远程服务器。通信装置110包括调制解调器、现有技术已知的一种或多种网络接口设备，包括但不限于网络接口卡。通信装置110包括允许在不同网络结点间传输数据的总线，例如地址总线114和数据总线115.
***110还包括第一处理装置105和第二处理装置106.第一和第二处理装置可以是计算机***，例如运行DOS或Windows操作***的数字计算机，并且与地址总线114和数据总线115相连。处理装置105和106各自通常都包括用于存储数据的存储装置121、用于输入数据的输入装置122以及实现***命令的中央处理单元(CPU)。存储装置121包括计算机存储器、硬盘、CD-ROM等数据存储设备。输入装置122可以是现有技术中已知的任何输入设备，例如常规键盘。
第一处理装置105可以由第一方操作用于获取、输入和存储与交易T有关的数据串C。第二处理装置106由第二方操作并响应C将数据项V与C的至少一部分关联在一起。第二处理装置106还可用来确定V是否满足属性P。例如，可以向第二处理装置106的CPU 123输入一组指令以使CPU获得与C(或C的一部分)相关的数据项V，并使CPU 123确定V是否满足属性P。这是必须满足的必要条件，以便由CPU 123执行下一步，即命令将使第三方能够验证V是否满足P的信息I传送到第三方(银行)。可以对CPU 123编程以在V满足P时有选择地操作以将信息I传输到第三方。
***100还包括装置140，当V满足P时由第三方操作以使第四方接受金额总和。装置140也可以是一个计算机***，具有能够被编程以在V满足P时被有选择地运行以命令将付款传送到第四方的CPU。
总之，本发明的第一实施例特有的小额支付方案在相对大量的小额支付发生的一段时间内，将处理费用降至最低，同时消除了对用户-销售商交互的需要，同时允许各方近似地支付或接收正确的期望值。
II.包括了时间限制的小额支付***
在上述第一实施例中给出的非交互架构中可以有不同的限制。尤其，在本发明的第二实施例中，能够引入时间限制。如上一节所述，该小额支付方案允许销售商随时存入应付的支票。但是，在很多情况下，对银行来说有利的是具有如果销售商给出的应付(即适当选出的)支票的时间信息表示该支票不是在从相关交易发生时的预定时间间隔内给出的就拒绝向销售商的帐户存入付款的能力。
在本发明的第二实施例中，提供了允许用户为由时间t部分表征的交易T建立支付的小额支付方案。通常，时间t表示交易T发生时的时间和/或日期。图3以流程图形式提供了依照本发明的第二实施例的小额支付交易方法的概观。用户从T获取一个数据串或电子支票C。在第二实施例中，支票C或C所指的交易T必须包含与交易T的时间t有关的信息IN。
用户使销售商接收到C中至少包含IN的一部分。销售商在接收到C的该部分之后将C与用户完全不可预测的数据项V相关联。在本发明的这个实施例中，该完全不可预测的数据项V是根据T的时间t定义的。例如，可以用公有密钥数字签名方案中的销售商私有密钥创建V，并且由SIGM(C)给出，即销售商对C或C中包含涉及t的信息的那一部分的数字签名。在后一情况中，更精确的V＝SIGM(G(C))，这里G是C的函数，返回与C有关的时间信息。
在该小额支付方案中还可以使用参数s和函数F和G确定V应该满足的属性P。满足s和函数F和G的方式以及规定属性P的方式可以用上一节中说明的规定s、F和G相似的方式变化。例如，支票C(或者C所指的交易T)可以直接规定应该和与C相关联的适当的值V一起使用的属性P。例如，函数F可以确定属性P，这里P由F(V)＝F(SIGM(C))＜s给出，s是0和1之间的数，并且表示该方案中给定支票C被选择进行支付的概率。
在本发明的第二实施例中，销售商的签名可以仅应用于C的函数G，而不是应用于C的全部。也就是说，属性P可以由F(V)＝F(SIGMG(C)))＜s给出。另外，可以用若干方式之一指定函数G。例如，它可以是固定的，或由C指定，或者由相应的交易T指定，或由(销售商的或用户的)证书指定，或者由银行提供的其它信息指定。
特别有用的函数G可以是返回C的时间信息IN的函数。这样，(用户完全不可预测的)数据项V主要是交易T的时间t的函数，因此属性P主要取决于交易T的时间t。注意由G提取的时间信息可以与t有关但不必与t相符。例如，t可以指定T的日期、小时和分钟，而G可以返回不同粒度的时间表示，例如，它可以指定t自身，但只到天(或天和小时但没有分钟)，或者t之后的下一小时。在本发明的第二实施例中，由销售商签署的值G(C)应该总是被解释成包含时间信息。
在确定了V满足P(在V满足P的情况中)并且支票通过了其它测试(例如，如果有用户签名的话是否真实)后，销售商在时间t’使银行接收到与T的时间t有关的信息IN的一些或全部。销售商可以向银行提供C的全部或至少是支票C中包含IN的那一部分。销售商还使银行接收使银行能够独立验证V是否满足P的信息I。销售商可以使银行在V甚至没有被计算出之前就接收到I的一部分。在接收到IN的相应部分之后，银行能够确定t’(即销售商将支票提供给银行的时间)是否足够接近t。如果已经过去的时间|t’-t|大于预定的数值，银行可以丢弃C。如果满足其它条件，例如C上的用户签名不能核对或者用户的帐户有欠款或者用户和/或销售商被怀疑有欺诈，银行还可以任意地或根据它的策略拒绝或延迟支付。
银行使用I独立地验证V满足P。仅当V确实满足P并且所有其它测试(例如，测试|t’-t|大于预定时间间隔)都通过时，银行才使销售商(或其它第四方)接收金额总和。预定的时间间隔可以是一天、一周甚至几个小时。
例如，如果支票C所指交易T在i天发生，小额支付***可以要求销售商在i天结束前或i+1天结束前或i+n天结束前将支票存入，这里n是表示天数，在n天之内销售商将支票存入合乎商业道理。这种类型的要求给销售商带来了额外的激励以验证他接收到的支票的时间精度，这为销售商提供了额外的安全性利益。
在一种形式中，如果t1表示用户使销售商接收到C中包括IN的那部分的时间，如果时间t1不在预定的时间限制内销售商可以拒绝进行。这种情况下销售商可以拒绝提供所请求的“商品”(商品、服务或信息)。及时存入还确保了不会过晚向用户收取费用，即当可能的费用已经不在用户的预算中时。
更详细地谈G(C)，G(C)可以是返回C的日期和/或时间或者C所指的交易T的日期和/或时间的函数。例如，如果这样的日期是2001.01.01，那么V可以由SIGM(2001.01.01)构成。如果销售商之前从未签署过这样的日期，这对用户来说这是完全不可预测的。这样，V必须满足的属性P包括将SIGM(2001.01.01)和F(SIGM(2001.01.01))与C、C的一部分、C的一些函数或预定的常量进行比较。例如，一个这样的属性P可以表示为：SIGM(2001.01.01)的所选择的m比特子串是否匹配C的所选择的m比特子串。
应该注意上述将V与C关联起来的方法有多种优势。尤其，销售商可以在甚至在2001年1月1号从用户获得C之前计算SIGM(2001.01.01)。因此，一旦那天接收到C，销售商可以快得多地验证P是否满足所需的属性P。例如，如果P由F(SIGM(2001.01.01))＜s构成，对一些固定数的s，那么P只限决于V，而不是支票。因而销售商能够确定P是否曾经成立并且对所有日期甚至在2001年1月1日以前都成立。如果P成立，那么销售商能够将他在那天接收到的所有支票都转发到银行进行支付而不进行任何进一步的验证。如果P不成立，他将丢弃他在那天接收到的所有支票而且不进行任何进一步的验证。这样，将销售商必须完成的签名的数量降至了最低。
或者，属性P可以由SIGM(2001.01.01)中特定的m比特(如10比特)是否匹配用户在C中包括的10比特串。这样，即使该属性取决于V和支票C，确定P是否成立也总是即刻完成的。实际上，即使数字签名的计算可能相当复杂，销售商只需要在2001年1月1日那些或之天计算SIGM(2001.01.01)一次，并存储该签名(或其中的任意给定m比特)。这样，对每个支票需要的销售商的工作量仅由两个10比特串的简单比较构成。这使得销售商能够使银行接收到信息I的全部，信息I使银行甚至能够在支票被接收到之前就独立验证被选择进行支付的给定支票。例如，销售商可以在2001年1月1号的开始或者甚至在它之前发送SIGM(2001.01.01)，然后只向银行发送与2001年1月1日有关的所有支票。尽管方便，但这对销售商来说不够谨慎，因为如果一个怀有恶意的用户要在2001年1月1日期间获取SIGM(2001.01.01)，他可以在那天签署绝不会被选择进行支付的支票。这个方法有很多相关领域的技术人员所熟知的变体(例如使用一个小时而不是一天的时间粒度)。
在一种形式中，本发明的第二实施例销售商通过获取一系列值VLi，用支票上的时间/日期信息关联(用户完全不可能预测的)一个数据项。销售商获取与一系列时间ti(i＝1，…，n)相关的一系列值VLi，该一系列时间中至少有一个以给定方式与交易T的时间t相关。例如，对于某一天，至少一个大于1小于n的整数m，|t-tm|小于预定量。或者，对于至少一个在1和n之间的整数m，t-tm或(tm-t)为正且不大于一天。用户使销售商接收到C中至少包含了与交易T的时间t有关的信息的那部分。
销售商然后确定P在C的那部分和值VLm之间或者C的那部分和取决于与tm相关的值VLm的数量Q之间是否成立。如果成立，销售商使银行接收到使银行能够验证是否满足属性P以使银行能够进行适当的存入和取出的信息I。
在一种形式中，销售商可以通过生成一个散列值链，用C的日期信息将(用户完全不可能预测的)一个数据项V关联到支票C。在这种形式中，销售商产生值链：w0，w1，…，wn，这里wi＝h(wi+1)，其中h是一个单向函数，并且将w0放在他的公共文件中，或者对其进行数字签名，或者将其公开。销售商因而将wi+1关联到了第i个日期/时间单位。即使销售商公开与前面的时间单位相关的所有数据项，相关的数据项wi+1是不可预测的。尽管前i个这样的数据可能已经被时间单位i发布，但wi+1仍然是完全不可预测的，因为不可能只知道wi＝h(wi+1)就能计算出wi+1。销售商将之关联到具有时间/日期信息i的支票C的不可预测的数据项V是wi+1，即日期/时间信息的第i个散列反转。属性P可以用多种方式形成。例如，如果wi的前10个比特等于C中选出的10个比特就满足P。销售商通过简单的发布信息I＝wi可以使银行能够验证P是否成立。银行通过对wi进行i次散列并查看结果是否与销售商的w0匹配可以验证wi，随即验证了P是否成立。
应该注意如果销售商使用与支票上的日期/时间信息相关的不可预测的数据项V，那么对销售商来说最好隐藏与在给定的日期/时间单位中他已经丢弃的那些支票以及他已经取消其存入的那些支票有关的任何信息。否则，怀有恶意的用户可能过早地发现值V，并用这个信息获取利益，例如生成他知道不会被选中的支票。对销售商来说最好取消给定日期/时间单位中所有“选出的”可支票支票，然后在该日期/时间单位结束时将所有选出的支票发送给银行。这样，即使怀有恶意的银行也不能勾结用户使他能够欺骗销售商。还可以通过要求用户使用让用户难以或不可能自由生成并测试大量支票以确定哪些支票将被选择进行支付的智能卡、蜂窝电话或其它设备来增强安全性。
III.包括了消除用户风险的选择性存入协议的小额支付***
概率支票方案的特征是用户预先不知道并且不能控制他的哪些支票将被选中进行支付。在本发明的实施例中，如迄今所述，可能发生用户被扣除超过他实际花费的金额，即超出他已经签署的所有支票的面值总和的金额。在传统的概率支付方案中，如果支票Ci被以概率s选中进行支付，那么通常用户被扣除的超过交易值TVi：在很多概率方案中，他被扣除的金额是(TVi *1/s)。因而，如果每笔交易Ti都有相同的面值TVi＝TV，并且不幸的是用户的前1/s个支票中有两个或更多(不是1)个变成了应支付支票，那么用户将被扣除至少两倍于实际花费的金额。当s较大时，预期对大约1/4的用户都会发生这种情况。
在本发明的第三实施例中，提供了一种选择性存入协议，它解决了用户风险问题，即用户不幸地被收取超过他已经签署的支票总面值的金额的可能性。用户风险问题是概率小额支付方案中固有的问题，例如Rivest的电子彩票方案以及前面的章节中公开的小额支付***。例如，即使概率方案的选择比率是1/1000，在不幸时会发生用户的前1000个支付中有5个而不是1个被选择进行支付。尽管超额向用户收取费用的概率很小，并且进行的小额支付的数量大大降低了用户风险的相关影响，但用户风险可能对概率小额支付方案的广泛接受构成强烈的障碍。这是因为普通用户不像较大的机构(比如银行)那样习惯于管理风险。因此，下面说明的第三实施例所发明的方案改进了基础的概率支付方案。
图4以流程图形式提供了依照本发明的小额支付交易方法的概观，该方法包括消除了用户超额支付风险的选择性存入协议。在这个实施例中，所提供的方法和***的特点是使用户能够为一系列交易Ti(i＝1，…，n)建立支付。每个交易Ti通常由非常低的交易价值TVi表征，例如1分或几分之一分。如果银行要处理每笔单独交易，银行因此要承受比交易价值TVi自身高得多的处理成本。
概率小额支付方案(例如，Rivest的彩票方案，或者前面章节中阐述的方案之一)可以因此被用户用来为每个Ti生成一个支票/小额支票Ci，Ci被作为交易Ti的付款发送给销售商。那么，或者通过像Rivest的彩票方案中用户和销售商的交互，或者通过前面的章节所述方案中的销售商不进行交互单独确定的方式，以大于0小于1的概率，确定Ci是否被选择进行支付。
从图4可以看到，对于每个Ci(i＝1，…，n)，用户使销售商接收到Ci。对于销售商接收到的每个Ci，销售商根据概率方案并以阻止用户***哪些支票将被选择进行支付的方式确定支票Ci是否被选择(即，应付)。例如，基础的概率方案可以是上面第1节中所述方案，这种情况下销售商将通过将数据项Vi与Ci相关联并确定Vi是否满足属性P而确定概率。如果销售商确定Ci不应支付，销售商就丢弃Ci。如果销售商确定Ci应该支付，销售商就使银行接收信息Ii，信息Ii使银行能够验证所选择的支票Ci是否应该支付。银行使用Ii验证Ci应该支付。当且仅当Ci应该支付时，银行才使销售商接收存入金额CRi，并且用户将被扣除金额Di。
在本发明的第三实施例中，银行必须确保Di使得向用户扣除的总金额D＝D1+D2+…+Di不大于用户已经签署的支付的总面值Tagg＝TV1+TV2+…+TV1。换句话说，对于任何使1＜＝i＜＝n的整数i，在用户已经参与了i个交易之后向用户扣除的总金额必须绝不超过用户已经从销售商购买的交易T1，…，Ti的总价值。
在优选形式中，银行通过使用来自支票的序号确保D＝D1+D2+…+Di不大于Tagg的方式确定Di。在这种形式中，用户在基础概率支付方案中产生的多个支票Ci(i＝1，…，n)中的每一张支票都包括一个序号Si。这些序号Si优选地是从1开始的连续整数。另外，第i个序号优选地代表交易Ti和支票Ci在时间上相对于其它交易(T1，…，Ti-1和Ti+1，…，Tn)和其它支票(C1，…，Ci-1和Ci+1，…，Cn)的顺序。
序号Si提供了与交易Ti和/或支票Ci相关的索引i的指示。但是，还可以使用有序但不连续的序号。例如，在特定的数P之后，可以将第i个支票与第i个素数关联在一起。对简单起见，将先说明每笔交易Ti的交易价值都相同TV＝TVi的情况。第三实施例还包括交易Ti的价值TVi不同的情况，后面更详细地对此进行说明。
银行(或另一第五方)跟踪已经被选择进行支付的支票的序号。为了确定应支付支票Ci的扣除金额Di，第三/第五方使用值Smax，这里Smax表示迄今已经提供的要进行支付的最近的支票上的序号。如果序号被从1开始顺序使用，值Smax被初始化成0.因为支票上的序号被依次排序，Smax是之前已经提供的应支付的任何支票上出现的序号中的最大值。另外，因为序号的顺序有序，Smax小于当前应支付支票Ci的序号Si。如图4中所示，对这张支票用户(被第五方)扣除的金额是：
Di＝(Si-Smax)*TV(1)
它满足了对用户已经签署的所有支票用户被扣除的总金额D是Si *TV。如果使用了不连续序号，可以定义Di＝#(Si-Smax)*TV，这里#(Si-Smax)表示Si和Smax之间序号的数量(包括Si但不包括Smax)。
金额D＝D1+D2+…Dmax表示用户已经发出的所有支票的总值。因为在已经签署了i张支票之后D绝不大于i*TV，因而消除了用户过量支付的风险。为了处理将来的小额支付，银行将Smax的值重置为Si，如上所述它是银行迄今发现的应支付的最近的支票。等式(1)还表明最终向用户收取的费用不取决于哪些支票是应支付的，而只取决于用户已经签署的支票的数量；最后对用户已经签署的支票向用户收取适当的费用。
第五方可以使第四方(可以是销售商，或除销售商之外的实体)接收存入金额CRi，它通常由下式给出：
CRi＝TV*(1/s)(2)
如果在基础的概率支付方案中有一个选择比率s，那么在本发明的方法和***中，当在大量小额支付上平均时，大约每1/s个支票中只有1个能被选中进行支付。因此，当在大量小额支付上平均时，存入金额对销售商来说也是公平的，因为它是1/s个支票的完全总值，并且销售商最后收到了正确的金额。但最后得到的方案对用户来说公平得多，因为进行过量支付的风险被从用户转到了银行。例如，如果选择比率是s＝1/1000，销售商处理1,000笔小额支付，每个价值1分，那么预计这1,000笔支付中只有一个将被选中，但被选中的这一个将使销售商收到1/s＝1000分，即10美元。如果(在1,000笔小额支付中)有不止一笔小额支付被选中，那么银行将不幸地必须多次支付10美元。根据上述序号扣除方案，银行通过将支付给销售商的付款延迟到用户总计已经支付了足够的钱以承担这个支票以及已经选择进行支付的所有先前的支票的付款而将一些风险转移给销售商。
在本发明的这个第三实施例中，用户优选地已经从银行获得了授权该用户在他在银行的帐户上签署支票的证书。这个证书可以指定用户的公有密钥；它还可以指定其它信息，例如用户被授权使用的最大序号，和/或支付的最大金额(如果支票可以有可变面值的话)。用户随他签署的每张支票一起发送这个证书，或者只将它提供给最近没有向其发送这个证书的销售商。通过让销售商在特定的时间段内缓存用户证书可以节省一些带宽。
在本发明的这个实施例的另一变体中，可以用类似于PayWord证书指定向特定销售商指定授权一系列Y个小额支付的长度为Y的散列链的方式，通过使用长度为Y的散列链来指定用户被授权使用的最大序号Y。但是，这样的话，带有授权的序号的支票可以被签署给任何销售商。用户可以向销售商提供证书以及散列链中的第i个元素以证明他被授权以序号i签署支票。(散列链中的第i个元素被定义为散列链中被连续散列i次产生散列链的根的元素)。
销售商也可以有数字证书，根据使用哪个版本的协议，用户在支付协议期间可以或不可以获取到它。如果支付协议是非交互的，用户就难以获得这个证书。另一方面，这个协议对支付协议来说不是必要的。例如，用户的支票可以包括采用“这张支票仅当和销售商公有密钥的有效证书被一起存入时才有效”或类似形式的声明，销售商可以在它存入支票时向银行提供它的证书。
出于几种原因，最好将过量支付的风险从用户转移到银行或销售商。首先，从1/s张支票中选出多张支票的概率很小。因而，银行的过量支付也很少发生。无论如何，每个这样的过量支付的金额都很普通。银行还可以在开设帐户时采取一些策略(例如向用户收取固定的费用，比如与1/s成比例的费用)来应付这样的变化。而普通金额的过量支付风险会困扰单个用户，并且妨碍他们签约概率小额支付方案(例如本发明中所公开的)，这样的风险通常不会困扰银行。原因是银行习惯于管理真正的风险。只是举个例子，银行日常管理的风险是借款人拖欠他们的借款的风险。因而，银行在制度上适合支持支付***，其中它们通过接受和管理风险而赢利。
同样，销售商通常习惯于管理大量的交易，这里每笔交易都有一些相关的风险，例如商品将被退回或者用户的支付不被实现。因此，在小额支付方案中接受一些风险对销售商来说也是可以接受的。银行和销售商因而可以同意被选择进行支付的小额支付支票将不会被实际支付给销售商直到用户帐户包含了足够了资金为止。每个被选择进行支付的支票将被维护在银行的“等待队列”中，直到用户的付款(取决于上述序号方案)足以支持这张支票以及所有先前排队的支票为止。
第二，只要银行为每笔交易收取一笔小费用，不管有多小，过量支付的概率从长远来看将变得越来越小，即风险随着小额支付交易数量的增长而降低。因而，与普通用户的概率相比，过量支付的概率对银行来说更小，因为与单个用户相比银行通常要经历多得多的交易。
除了消除用户过量支付的风险之外，本发明的第三实施例还使银行能够处罚欺诈方，或者在它们能够制造任何实质性危害之前将它们清出***。下面将更详细地说明，本发明包括若干特性允许银行防止恶意用户和/或恶意销售商欺骗。例如，如果银行注意到一个新的支票与先前过的一张支票有相同的序号，或者如果新支票的序号和时间由于某种原因相对于先前处理过的支票无序，或者如果支票的金额过高，或者如果有其它银行规定的情况发生，银行可以拒绝兑现该支票。银行甚至可以对用户罚款，和/或采取其它惩罚性措施，如果它认为适当的话。例如，银行可以保留统计并将其应支付支票导致上述任何问题的用户清出***，例如，如果使用证书的话可以取消他们的证书。例如，如果支票被不一致地编号和/或标注日期，或者属于那些其支票比预期更频繁地应被支付的用户，就可以被丢弃。同样，银行可以将不规矩的销售商赶出***，例如接收具有上述问题或者比统计上预期的更频繁地应被支付的支票的销售商。
在本发明的第三实施例中，用户被要求顺序使用序号，不能有重复。例如，序号1应该用于第一张支票，序号2应该用于第二张支票，等等。如上所述，这样用户将绝不会被收取超出他应付费用的钱。通常，在给定的时间，在最后一个应支付支票后，他将已经为额外的交易签署了另外几张支票，而这些支票不会被选择进行支付。因此，至少暂时向用户收取的钱少于他实际的花费，偶尔他会被正好收取应扣除的金额，即在最后的支票应被支付时。
但是，不诚实的用户可能试图玩弄序号以找到使扣除金额少于实际花费的方式。一种方法是多次重用一个序号。如果他这么做，与真实值相比，将减小Si-Smax以及由(Si-Smax)*TV给出的金额。但是，这种类型的欺骗不是非常有用，因为如果银行注意到一个应付的支票与先前处理过的一张支票有相同的序号，银行可以采取惩罚措施以阻止这种欺骗。例如，如果银行遇到了应支付支票中一个重复的序号，银行可以被授权向欺骗用户收取一个足够高的金额以使用户不再用这种方式欺骗。
应该注意到在本发明的第三实施例特有的小额支付方案中，用户不能预测因而也不能控制哪些他的支票将成为应支付支票。因而每次他生成具有相同序号的两张支票时，虽然概率非常小，但它们都将成为应支付支票。可以将对欺骗进行的罚款定得足够高使得它超过用户希望通过欺骗获取的收益。
若干形式的欺骗涉及支票的“背面-日期”等等。因而对销售商和银行来说重要的是检查从相同用户看到的任意两张支票C和C’，看是否C的序号小于C’的序号，C的日期/时间在C’的日期/时间之前。
如果用户在支付交易后没有马上被销售商告知他的哪些支票变成应支付支票，捕捉正在欺骗的用户的上述机制工作得更好。实际上，从这个角度看，最好尽可能使用户不知道他的哪些支票已经变成了应支付支票。原则上，用户实际上可以精确监控他已经签署了多少支票，因而不会对正当的款项扣除有争议。但是，如果争议将要出现，就会期望提供被扣除金额的证据(包括应支付支票的序号)的能力。
如果选择支票Ci进行支付的标准只取决于序号Si，可以改进上述用于查出并驱逐欺诈用户的机制。这样，如果支票是应支付支票，那么通过欺骗用相同序号产生的任何其它支票也都是应付的。例如，如果基础的概率支付***如前一节所公开的那样，用来(通过属性P)确定支票何时应支付的数量Vi(用户不可预测)可以简单地只由Si的销售商签名构成，或许还有用户的帐户和/或名字而不是整个Ci的销售商签名。
另一种用户试图少支付的方式是使用一个不按使用时间有序的序列中的序号。例如，一旦一个恶意用户确认S00是应支付支票的最低序号，他可能计划再次使用从S1到S99的序号，以确保他所用的支票不会被选中进行支付，而同时不担心他会被抓到两次使用相同的序号。但是，即使采用这种策略，恶意用户仍然很可能被抓住。原因是如果他以后(即在使用C100之后)仍然再次使用1到99之间的序号，他就无法避免非法支票成为应支付支票。这种情况有一定的发生概率，如果发生的话，银行将通知C100相对于时间为t100的交易T100为应支付支票以及用户后来为时间晚于t100的交易生成了序号小于S100的支票。此外，银行的制裁会使得用户无法用这种方式达到行骗目的。为了让这种过滤机制顺利工作，最好每张支票都携带它所支付的交易的时间并且销售商在选择过程开始之前将那些携带错误的时间标识的支票视为无效支票。
为了更好地支持这个反欺诈策略，举例来说，银行可以要求销售商使用设计用来不仅包含只取决于支票序号的部分还包含只取决于时间的部分的选择过程。本质上，可以有两个或更多的选择过程，如果这些选择过程中任一个确定出支票可以被选中就可以选中该支票。这种变化对本领域的技术人员来说是显而易见的。
恶意用户U’还可以勾结恶意销售商M’以确保由U’签署并为M’提供的商品/服务/信息所花费的支票总是应支付支票。这样，为简单起见简定每个支付值是1分，U’将总是只被银行扣除1分，而M’将总是被支付1/s分(即，10美元，如果s＝1/1000)。然后U’和M’可以共享他们的非法收入：实际上，如果U’将他自己设置为销售商(可能是用假名)，U’可以与M’是同一个人。
此外，U’和M’可能只获得少量的非法收益：如果他们试图多次重复上述方法提高他们的非法收益，就很可能被驱逐出***。这是很高的代价，特别是如果M’还在***中还有合法收益的话更是如此。如果被驱逐出去的用户和销售商不能轻易回到***中，例如用新的身份，或者如果首次进入***的代价(例如，获得初始证书的代价)足够高，非法活动就会少一些。甚至对用户还会有负回报，所涉及的费用会被银行轻易没收。
无论如何，通过让第一方使用安全硬件可以消除这种类型的欺诈。例如，这个不能纂改的部分可以负责在每次产生新的支票时正确地增大序号，并且还可以负责保护私有签署密钥并产生新支票的签名部分。因而如果恶意用户试图产生应该支付给他的销售商同谋的支票，在每次尝试时他必须也增加序号。因而，一旦产生了一个应支付支票，销售商将被付给特定的金额，但用户也将被扣除相应的适当金额。应该注意在本公开的任何地方一方可以使用和/或被要求使用安全硬件以进行至少一部分它的操作。这种安全硬件可以被包括在智能卡或移动手机中。
诚实的用户表现出恶意的概率是很小的，因为在他签署了n张支票后，只是偶然地它们中有大大多于n*s张支票已经成为了应支付支票。这样，他会被驱逐出去。采用适当的参数设置，这样的用户将会非常少。另外，可以和这些无意中造成银行损失的用户进行交流。例如，银行可以向这些用户出示表明他们的支票中有异常大量的支票被发现是应支付支票的信息。因而，这些用户可能接受在不同的条件下留在小额支付***中，例如作为用户在其中要承担被扣除金额大于实际花费的风险的概率小额支付***的用户。这样的转变也可以作为用户和银行之间的初始协议中的自动功能而引入。
如前所述，通过将被选中进行支付的支票延迟到银行已经从用户接收到足够的资金承担这张支票(以及用户从中选择进行支付的所有先前的支票)，银行可以将与统计变化相关的一些风险转移到销售商，并且现在还可以将与实施欺诈的用户相关的一些风险转移到销售商。根据上述本发明，银行将根据用户已经签署的支票的数量***地从用户接收资金，银行将从已经被选中进行支付的销售商接收支票。当用户是诚实用户并且频繁签署支票时，销售商在这种方案中不必长时间等待来自银行的付款。另外，如果银行没有向销售商全额支付每张支票，而是稍微打了些折扣，那么通常应该是用户的帐户被扣光了(或几乎扣光)，因为用户支付的频率会一定程度上超过银行存款的频率。这种情况下销售商应该期望立即付清或者在一个较短的时间内付清。以这种方式将风险转移到销售商可能是特别有效的阻止用户和销售商试图合谋欺诈银行的方式，因为银行不再因为假定对用户的被选择进行支付的支票的支付大于来自用户的收据而承担任何风险。如果采用了这个变化，银行在用户的证书中标识出与用户帐号相关的“未决的，未支付的”支票的总金额是很有用的，以使销售商可以拒绝接受用户的金额过大的支票。
本发明的第三实施例的方法和***还能够处理没有统一的固定的交易值的小额支付。一种方法是将一张价值v分的支票明确当作是v个具有连续序号的1分支票的合体。更有效的方法是让用户签署单张由一个序号段[S，S+v-1](包括两个端点S和S+v-1)而不是由单个序号表征的支票。如果这个支票成为应支付支票，用户将被扣除S+v-1-Smax分，而新的Smax是S+v-1。
在本发明的第三实施例中，当支持可变面值的支票时，确定支票为应支付支票的过程可以取决于支票的面值。也就是说，不使用单一选择概率s，而是对每个大于零的整数v有一个选择概率Sv，并且这些概率可以不同。该过程可以使用简单的“阶梯函数”，形式为：如果v小于100，v分的支票是可支付支票的概率是1/100，如果v是100或更大则概率是1，如果v至少是1000则概率是1.另外，可以使用“阶梯函数”：如果v最多是1000，则支票是应支付支票的概率是v/1000，如果v至少是1000，则概率是1.但是，这些方案的使用可能对银行检查各种形式的欺诈的能力有不利影响，所以应该谨慎使用它们。例如，只给定看到的最大序号，银行不再能够这么轻易地预测迄今已经付给销售商的金额。出于这个原因，希望保持选择概率固定。在这个方向上，一种有吸引力的方1法是银行发给用户两个或更多证书，每个证书指明它自己的允许的序号集合，它自己的最大支付额，以及它自己的选择概率s。实质上，用户就有了一组不同的“支票簿”，每个“支票簿”有它自己的参数和限制，但每个都有它自己的选择概率s。
更详细地说明不等交易值的情况，本发明的第三实施例允许用户为n个交易T1、T2、…、Tn建立支付，这里每个交易Ti由整数索引i和交易价值TVi部分表征，并且各个Ti不必等值，但每个TVi可以被表征为公共单位值UV的倍数。例如，UV可以是1分。这样，每个数据串Ci包括整数索引i以及Ti的价值TVi的信息。该信息采用的形式是由支票的“初始序号”和“最终序号”组成的一个值对(Si，Si+vi-1)。对于1和n之间的所有i，Si是依次有序的渐进序号，并且代表Ci相对于有序的连续数据串Cj(j＝1、…、n)的位置。vi是取决于i的整数并且表示Ti的值TVi，由vi＝TVi/(UV)给出。
销售商从接收到的支票Cj(1＜＝j＜＝n)中以防止消费者***哪些支票Ci将被选择为应支付支票的方式选择那些应支付的支票。一种形式是，销售商可以使用第I节中所述方法，即将一个数据项Vj(例如用销售商的私有密钥产生的销售商对Cj的数字签名)与Cj相关联，该数据项是用户完全不能预测的。销售商使第三方接收能够使该第三方验证证所选择的支票是应支付支票的信息Ij。第三方在接收到Ij之后验证所选择的支票Ci确实是应支付支票。当且仅当Cj是应支付支票，或许当也满足一些其它条件时，第五方确定Smax和vmax的值。Smax表示到目前为止被选中进行支付的任何支票的最大的最终序号，这里max是大于等于1小于等于n的整数，并且vmax＝TVmax/(UV)。第五方然后使第四方(它是收款人，可能是销售商或另一方)接收存入金额CR。第五方使第一方被扣除与Di有关的扣除金额，这里Di等于：
(Si+Vi-1-Smax)*UV
Smax随即被设置为Si+Vi-1。
用与固定交易价值情况下类似的方法抓获并处理非单一交易价值情况下的欺诈行为。例如，两张应支付支票，一个表示1分并且由S和S+v-1之间的一个序号S’表示，另一个表示v分并且由序号区间[S，S+v-1]表示，在这种情况下这两张支票将被视为欺诈的证据。v值过高的支票是不允许的，即总会被拒绝支付。否则，恶意用户可以加入支付***，签署一张大额支票，如果结果是该支票没有被选择进行支付，就决不再产生第二张支票。还可以通过在用户建立帐户时向每个用户收取“入会费”来处理这个问题，例如入费会高到足以覆盖对那个用户预期的最大“浮动”。这里“浮动”是用户已经签署但银行尚未看到的支票中的预期最大价值。对于这个发明的一些形式，这个浮动可以被计算为用户签署的支票的最大容量乘以一张支票将被选择进行支付的概率的倒数。银行还可以如前所述通过将被选择进行支付的支票延迟到银行已经从用户接收到的足够的资金来兑现这些支票(以及用户签署的并且也被选中进行支付的先前的支票)而阻止欺诈。
在一种形式下，可以用第I节中已经说明的基础的概率支付方案实现确保用户决不会被收取超过他实际花费的金额的第三实施例的方法和***。这样，在接收到交易Ti(i＝1、…、n)的支票Ci之后，销售商将支票Ci和一个用户完全不可能预测的数据项Vi关联在一起，例如Vi是用销售商的私有密钥创建的销售商对Ci或Ci的一部分的数字签名SIGM(Ci)。销售商然后确定Vi是否满足特定的属性Pi，例如下列属性：
F(SIGM(Ci))＜s
这里F是操作比特中并返回一个0和1之间的数的函数，s是待批比率(0＜s＜1)。
如果销售商发现Vi确实满足Pi，销售商就使银行接收使银行也能验证Vi是否满足Pi的信息Ii，例如与用来产生Vi的销售商私有密钥相关的销售商公有密钥。如果Vi不满足Pi，销售商就丢弃支票Ci。当且仅当银行发现Vi确实满足Pi并且可能Vi还满足任凭银行确定的其它条件，第五方(可以是银行或银行之外的实体)可以使第四方(可以是销售商或销售商之外的实体)接收存入金额CRi。第五方还使用户被扣除了扣除金额Di。
在第三实施例中，向用户收取的金额Di不一定与销售商(或其它实体)收到的金额CRi相同。但是，总的来说，通过签署他的支票，通过在包括选择性的存入协议(它确保用户被扣除的金额Di绝不大于用户的实际花费)，第三实施例的方法有别于基础的概率支付方案。换句话说，确保用户绝不会被收取超出其实际花费的金额。
图5提供的示意结构图说明了用于依照本发明的第三实施例为交易Ti建立支付的小额支付***200的组件。***200包括允许用户、销售商和银行在它们自己之间传输电子数据甚至付款的通信装置210.电子数据可以包括表示电子支票的数据串或表示消息的串。在一种实施例中，通信装置210允许访问远程服务器。通信装置210可以包括调制解调器和一个或多个本领域中已知的网络接口设备，包括但不限于网络接口卡。可以提供一个或多个总线(例如地址总线214和数据总线215)以便允许在不同网络结点间的数据传输。
***200还包括第一处理装置205和第二处理装置206.该第一和第二处理装置可以是计算机***，例如运行DOS或Windows操作***的数字计算机，并且与地址总线214和数据总线215相连。处理装置205和206各自通常都包括用于存储数据的存储装置221、用于输入数据的输入装置222以及实现***命令的中央处理单元(CPU)223.存储装置221可以包括计算机存储器以及硬盘、CD-ROM等数据存储设备。输入装置222可以是本领域中已知的任何输入设备，例如常规键盘。
第一处理装置可由用户操作进行获取、输入和存储与交易Ti(i＝1、…、n)的数据串Ci，在数据串Ci中包括支票Ci相对于有序的连续支票Cj(j＝1，…，n)中的其它支票的位置的渐进序号Si。第二处理装置106可由销售操作操作并响应Ci以将数据项Vi与Ci相关联。第二处理装置106还可用来确定Vi是否满足属性Pi。例如，可以向第二处理装置206的CPU223输入一组指令以使CPU获取与Ci(或Ci的一部分)相关的数据项Vi并使CPU223确定Vi是否满足属性Pi。这是必须满足的必要条件，以使在206中由CPU223执行的下一步(即对使银行能够验证Vi是否满足Pi的信息Ij到银行的传输的排序)。可以对处理装置106中的CPU223编程以在Vi满足Pi时运行以发送信息Ij到银行。
***200还包括装置240，当Vi满足Pi时由银行(或别的第五方)运行以使第四方(可以是销售商或别一实体)接收钱的总和。装置240还可以是一个计算机***，它的CPU可以被编程以在Vi满足Pi时被运行以：1)确定Smax的值，Smax是进行支付时最后一张支票的序号(因而目前提供给银行进行支付的任何支票上的序列号的最大值)；2)对第四方的金额CR支付的传输排序；3)使用户被扣除金额D。
总地来说，本发明的第三实施例的小额支付***和方法提供了确保用户不会被收取超出其实际花费金额的机制。这样，第三实施例中给出的***和方法大大提高了用户接收程度，这是引起小额支付***的广泛接受的关键因素。
IV.包括了由银行控制的延迟选择协议的小额支付***
本发明的第四实施例的特色是包括了延迟选择协议的概率小额支付方案，在这种方案中支付选择过程被延迟到银行从销售商接收到对一个或多个支票的提交为止。有若干种实现这种延迟选择协议的方法。第一个(也是首选的)方法如下：用户创建一个从小额支付交易T获得的并提供对交易时间t的指示的数据串或“电子支票”C，当用户想要进行支付时将C发送到销售商。销售商将他在给定时间间隔(例如，给定的一天)内从一个或多个用户收到的支票Ci(i＝1，…，n)分成m个列表Lk，其中k＝1，…，m。这里m是任意的，例如可以是等于或近似等于1/s的整数，s是期望的选择概率。优选地，每个列表包括正好满足m个互斥属性P1，…，Pm之一的所有支票。例如，如果m＝1024，每个列表Lk(k＝1，…，m)包括那天接收到的按照确定性函数H被散列后产生的前10个比特是整数k-1的10-比特二进制扩展的所有支票。每个列表Lk(k＝1，…，m)包括lk个支票Ck 1 ，…，Cklk，lk表示列表Lk中数据串的数量。当在m个列表上求和时，lk自然合计等于接收到的支票的总数n，即
l1+…+lk+…lm＝n
销售商通过为Lk计算提交而提交每个列表Lk，并使银行接收
CMk(k＝1，…，m)。
在本领域中已知，提交方案是使一方向另一方递送消息而不揭示消息的内容同时忠于这个消息的协议。该协议允许各方模拟在“上了锁的盒子”中投递消息的过程，由此发送方(在本例中为销售商)能够防止接收方(在本例中为银行)知道与盒子中的消息有关的任何事情，直到将来给了接收方盒子的钥匙时。接收方能够防止发送方在接收方已经接收到盒中的消息之后改变它。提交方案通常由两个阶段组成：第一阶段(“提交阶段”)模拟上了锁的盒子的传递。当这个阶段完成时，接收方还不知道消息，但发送方不能再做任何改变。第二阶段(“回收阶段”)模拟钥匙的传递。接收方现在能够看到消息并且验证打开的盒子中的消息确实是发送方自己提交的。
在优选形式中，Lk的提交CMk可以是一个散列值H(Lk)，H是单向抗冲突散列函数。因此，通过计算不可能从CMk得到Lk，并且在计算上不可能产生两个不同的串L1 k和L2 k使得H(L1 k)＝H(L2 k)。。
在本发明的第四实施例特有的延迟选择协议中，确定特定支票Ci是否应该被选中进行支付的支付选择过程被延迟到银行接收到销售商对列表Lk的提交CMk(k＝1，…，m)为止。这是本发明的第四实施例中说明的小额支付方案与众不同的特性。在接收到CMk(k＝1，…，m)后，银行以销售商和用户无法预测的方式选择1和m之间的一个索引k。例如，银行可以对正在讨论的日期(例如，2001.01.01)进行数字签名，然后用这个签名的前10个比特进行选择。这个签名可以在该前十个比特被提取之前被进行散列。银行的签名可以被发布(例如，放在网上)使得每人都能验证确实是银行在那天选择的索引。被选中的索引k是支付索引。销售商通过将CMk回收成原始的支票列表Lk而响应。或者，银行可以将索引k计算为销售商对列表Lk的提交CMk的函数。例如，可以从银行的签名CM1…CMk或H(CM1…CMm)提取k，H是单向散列函数；或者针对给定的函数f从f(CM1…CMm)提取k。
银行随后检查是否所有都正确。例如，银行验证回收的列表中的支票确实与正在讨论的那天有关，该列表中没有重复的支票，并且该列表中的所有支票都满足属性Pk，如果有用户签名的话用户签名有效，等等。如果没有满足这些条件中的任何一个，银行可以对销售商(或用户，例如银行发现用户签署了两个具有相同序号的支票)罚款或采取惩罚措施。否则，银行要支付Lk中支票总值的m倍。或者如果所检查的列表成功通过了检查，银行可以向销售商支付所有列表中所有支票的总金额。如前所述，如果用户的帐户中没有足够的资金来承担这些支票这些支付中有一些还可以被推迟。
随后其支票属于Lk的那些用户被以若干种可能方式之一扣除相应金额。例如，用户可以被扣除他们被选中的支票面值的m倍(像第一实施例中那样)，或者根据它们被选中的支票的序号被扣除相应金额(像第三实施例中那样)。银行可以进行详细审查或者以前面的实施例中预见的方式进行处罚。银行还可以要求销售商回收额外的列表以验证是否所有都是正确的，或者选择不止一个支付索引。在后者中，银行可以向销售商支付Lk中支票总值的m/r倍，r是被选中进行支付的列表的数量。这样，选择概率是r/m，而不是1/m。或者，银行可以检查两个或更多列表并随后向销售商支付与所有列表中的所有支票有关的总金额。
注意提交可以在发本发明的范围内被循环使用。例如，销售商不向银行发送对列表Lk(k＝1，…，m)的提交CMk(k＝1，…，m)，而是向银行发送对这m个提交的提交。例如，销售商可以向银行发送单个值C＝H(CM1…CMm)，H是单向散列函数。在银行选择了一个(或多个)索引k之后，销售商可以先回收C以便揭示CMk是什么，然后通过揭示对应的支票列表而如前那样回收CMk。例如，如果C＝H(CM1…CMm)，销售商可以通过揭示所有m个提交CM1…CMm而揭示正确的值。银行可以对这m个值进行单向散列以检查产生了相同的值C＝H(CM1…CMm)，然后获取第k个提交以便隔绝CMk。当然，销售商还可以通过向银行发送多个提交而不是单个提交C而提交m个提交CM1…CMm。例如，销售商可以发送对CM1…CM10的提交、对CM10…CM20的第二个提交。
通常，为了通过单个值V(例如通过某个单向散列函数的V＝h(V1，…，Vm))提交m个值V1，…，Vm。必须揭示/发送所有V1，…，Vn以仅回收Vi。如果m非常大和/或Vi非常大，这样就不可行。用在在所发明的***中对提交特别方便的一种方法是广义Merkle树。通过“广义Merkle树”，是指对m个值的提交，该提交使得能够只回收这些值中的一个而不必回收所有其它值。
广义Merkle树的一个特殊例子是Merkle的美国专利号4,309,569中说明的众所周知的Merkle树提交方案，在此通过参考将其引入。实现Merkle树的一种方式是在可能无向的图G中存储要提交的值，图G的一些边可以是有向的以便产生非环形(通常是树形)的子图G’(优选地与G具有相同的结点)，然后使用一个或多个基础的单向散列函数(例如，通过使用基于基础的单向散列函数的可交换单向散列)以便在每个结点中存储取决于在那个结点在G’中的子孙上存储的值以及可能的附加值的一个值。这样，改变原始值中的至少一个或多个引起G’的一个或多个根结点中存储的值也随之以压倒性的概率改变，除非已经发现了基础的单向散列函数之一中的冲突。使用这个方法，根结点上存储的值构成了对图结点中存储的原始值的提交。另外还有一些与正在被提交的值可以被存储在图中何处有关的限制(以后可由银行检查)。在任何情况下，销售商可以用广义Merkle树提交CM1…CMm。另外，可以用广义Merkle树散列列表Lk生成提交CMk。广义Merkle树的使用可以发生在本发明中使用提交的任何方面。
注意销售商会发现连同提交值CM1…CMm(可能它们自身由一个或多个提交C所提交)一起向银行发送与列表L1…Lm有关的其它数量(例如这些列表里每个列表中的总金额或支票数量)能够有所帮助。这些其它数量可以在任何提交之外被传递。例如，销售商可以向银行发送CM1…CMmQ1..Qm，Qi表示Li的净量。例如，这让银行不必进一步回收就可以求得每个列表的总金额之和。
还有其它相关方法用于实现包括了延迟选择协议的概率小额支付方案。在这些方法中，支付选择过程被延迟到银行从销售商接收到对销售商已经从多个用户接收到的一个或多个支票的提交为止。银行随后公平地、随机地确定哪些提交的支票应该是应支付支票。本发明的第四实施例的延迟选择协议还让银行能够在欺诈方产生任何实质危害之前惩罚/淘汰欺诈方。
图6以流程图形式提供了依照本发明第四实施例的小额支付交易方法的示意概观。用户创建自小额支付交易T获取的数据串或“电子支票”C，然后用户在想要进行支付时将C发送给销售商。在所示本发明的实施例中，涉及了多个交易Ti(i＝1，…，n)。用户为每笔交易Ti获取支票Ci，然后使销售商接收支票Ci(i＝1，…，n)。
销售商将他已经从用户收到的支票Ci(i＝1，…，n)分成m个列表Lk，其中k＝1，…，m。每个列表Lk(k＝1，…，m)包括lk个支票Ck1，…，Cklk，lk表示列表Lk中数据串的数量。当在m个列表上求和时，lk自然地合计等于接收到的支票的总数n，即
l1+…+lk+…lm＝n
销售商通过为Lk计算提交而提交每个列表Lk，并使银行接收
CMk(k＝1，…，m)。
可以根据销售商和银行同意的一个特定规则完成将支票分组成列表。例如，支票C可以被放在列表Li中，Li可以被计算为C的函数，例如通过使用C的序号或从C提取出一些比特或者从C的散列中提取出一些比特。
每笔交易Ti优选地由交易值TVi表征。另外，每个数据串Ci优选地包括表示(从其获得Ci的)交易Ti的交易值TVi的数据。销售商因而可以为每个列表Lk确定总值Vk，Vk由下式给出：
Vk＝TVk 1+…+TVklk
换句话说，Vk表示列表Lk中所有数据串Ck 1，…，Cklk的总值。在这种情况下，销售商除了提交值Lk之外还可以选择提交值Vk。也就是说，销售商可以向值列表(V1，V2，…，Vm)提供附加提交CV＝H(V1，V2，…，Vm)，H是单向散列函数。通过回收CV，销售商因而揭示了列表(V1，V2，…，Vm)。
在第四实施例所特有的延迟选择协议中，用于确定特定支票Ci是否应该被选择进行支付的支付选择过程被延迟到银行接收到销售商对列表Lk的提交CMk(k＝1，…，m)，并且如果选择了CV选项的话还被延迟到银行接收到对值Vk的提交CV。这个延迟是第四实施例中说明的小额支付方案与众不同的特性。在接收到CMk(k＝1，…，m)(以及可选提交CV)后，银行选择一个或多个整数索引i1，i2，…，ir，并且使销售商接收到所选择的索引i1，i2，…，ir。在本发明的第四实施例中，银行对整数i1，i2，…，ir的选择表示确定一张支票是否被选择进行支付的选择过程。
应该注意r的值是任意的，取决于银行。当有多个尝试过的欺诈的索引时，或者当怀疑特定销售商时，可以使用更大的r值。在有些情况下，银行甚至可以要求销售商回收他的所有提交(也就是说，r＝m)。推荐选择r＞1，以便有机会抓获来自相同用户具有相同序号的两张支票，而不是在以后根据统计证据驱逐这样的用户。
在接收到索引i1，i2，…，ir后，销售商回收那些其索引与他已经接收到的索引i1，i2，…，ir对应的提交CMk。换句话说，销售商回收CMi1，CMi2，…，CMir，即销售商使银行接收到CMi1，CMi2，…，CMir中每一个的回收串。如果每个CMk＝H(Lk)销售商由此向银行揭示了Li1，Li2，…Lir，如果提交CV先前被给了银行，销售商就向银行揭示列表(V1，…，Vr)。对于其索引与银行已经选择的特定索引匹配的那些列表，银行能够看到这些列表中包含的数据串，因此也能看到相应的总交易值。如果CV也被回收，银行就看到了销售商为所有列表要求的总交易值，而不只是被选中的列表。银行可以重新计算回收的列表的总交易值，并比较这些值和CV的回收以便检查代表销售商的欺诈。这样的检查还可以涉及检查每个列表只包含适合包含在那个列表中的支票以及检查出现在不止一个列表中的支票。
在本发明的第四实施例特有的小额支付方法和***的最后一步，第五方(可以是银行或银行之外的实体)完成该支付过程，即，使第四方(可以是销售商或销售商之外的实体)接收存入金额CR。在有些情况下，这个动作可以被延迟到满足特定条件，例如在与该支票的创建者相关的帐户中有足够的资金。第五方还使其支票属于所选择的列表Li1，Li2，…，Lir的用户被扣除金额D。
在优选形式中，销售商(或其它第四方实体)接收到的存入金额CR优选地是所有m个列表中包含的所有支票的总值V，即
CR＝V＝V1+…+Vk+…Vm
为了实现这个确定CR的方法，应该使用可选提交CV，以便可以从CR的回收中的值计算出CR。由银行(或其它第五方)支付给销售商的金额CR因而是销售商接收到并被分成m个列表Lk(k＝1，…，m)的所有支票的全部总值。
在本发明的一种形式中，向用户U收取的扣除金额DU由其索引与银行选择的索引相对应的列表中包含的所有该用户的支票的总值的有关值给出。例如，通过将这个总值放大m/r(即选择概率s＝r/m的倒数)倍可以确定出值DU：
DU＝(Vi1 U+Vi2 U+…+Vir U)*(m/r)
Vk U是列表Lk中包含的用户U的总值。
在本发明的第四实施例的另一版本中，每个支票Ci包含涉及序号Si的信息。优选地，Si是由创建支票的用户发布的渐进序号，(对每个用户来说)从1开始顺序有序，并且代表交易Ti关于那个用户已经同这个销售商参与的其它交易T1，…，Ti-1和Ti+1，…，Tn的时间顺序。
在本发明的这个形式中，扣除金额DU是用被银行选中进行支付的那些列表中包含的每个支票中的序号Si确定的。如果每笔交易有相等的价值TV，与单个支票Ci对应的支取金额由下式给出：
(SNi-SNmax，U)*TV
Smax，U表示在来自产生Ci的用户U且已经被处理过并被选择进行支付的最近的支票上出现的序号。关于使用支票上的序号消除用户被收取超出其实际花费的风险，在前面的III节中给出了更详细的说明。换句话说，假定相关的选择概率被理解为r/m，一旦在这个第四实施例中选择了r个列表的支票进行支付，可以用类似于本发明的第三实施例中处理支票的方式单个处理这些支票。
图7示出了用于为n个价值为TVi的交易T1，T2，…，Ti，…，Tn建立支付的***300.***300包括用于在用户、销售商、银行和第四方之间传输数据的通信装置。***300还包括第一处理装置310、第二处理装置320、第三处理装置330和第四处理装置340.所有四个处理装置通常都包括用于存储数据的存储装置351、用于输入数据的输入装置352以及实现***命令的CPU353.
第一处理装置310可由用户操作以获取、输入并存储每笔交易Ti的数据串Ci(1＜＝i＜＝n)。第二处理装置320可由销售商操作并在接收到Ci(i＝1，…，n)后用于唯一地将所述数据串Ci(i＝1，…，n)分成m个列表Lk(k＝1，…，m)并用于输入和存储所述列表Lk(k＝1，…，m)。每个列表Lk包括数据串Ck 1，…，Ck lk，并且∑m k＝1lk＝n。第二处理装置还可由销售商操作用地计算每个Lk的提交CMk，并用于输入和存储提交CMk(k＝1，…，m)。
第三处理装置330可由银行操作在接收到提交CMk之后选择一个或多个整数索引i1，i2，…，ir并使第二方接收索引i1，i2，…，ir，对所有的r，1＜＝ir＜＝m。第四处理装置340可由销售商操作在接收到索引i1，i2，…，ir之后回收CM，由此向银行揭示Li1，…，Lir。
在本发明的每个所提出的实施例中，可以使用蜂窝电话中的智能卡或处理器等抗干扰硬件提供安全性。
总之，本发明所特有的方法和***，1)消除了支付选择过程中对用户-销售交互的需要；2)向***中引入了时间限制；3)提供了选择性存入协议，消除了对用户过量收费的风险；和4)提供了延迟选择协议，向银行提供了支付过程的灵活性和控制。
尽管已经参考特定的优选实施例特别展示和说明了本发明，但本领域的技术人员应该理解只要不偏所附权利要求规定的本发明的精神和范围就可以在其中进行各种不同的形式和细节上的修改。
权利要求(附录H)
1、为交易T建立支付的一种方法，该方法包括：
A.第一方从T获取一个与T有关的数据串C，并使第二方接收到所述数据串C的至少一部分；
B.第二方将C的所述至少一部分与一个数据项关联在一起，其中V是第一方完全不可预测的；
C.第二方确定V是否满足属性P，如果满足，第二方使第三方接收到使第三方能够验证V是否满足所述属性P的信息I；
D.第三方在接收到I后验证V是否满足所述属性P；以及
E.仅当V满足所述属性P时，第三方使第四方接收到金额A。
2、根据权利要求1的方法，其中所述数据串C的至少一部分被进行了验证。
3、根据权利要求1的方法，其中第二方确定V是否满足属性P的步骤不需要第二方和第一方之间的交互。
4、根据权利要求2的方法，其中所述数据串的所述部分由第五方代表第一方验证。
5、根据权利要求1的方法，其中第一方从T获取数据串C的步骤包括第一方使用第一方的保密密钥为T的至少一部分创建数字签名的步骤。
6、根据权利要求5的方法，其中所述第一方的所述数字签名包括下列中的至少一个：
(a)确定性签名；
(b)随机性签名；
(c)离线签名；
(d)在线签名；
(e)基于身份的签名。
7、根据权利要求1的方法，其中第二方将数据项V与C关联在一起的步骤包括第二方用第二方的保密密钥为C的至少一部分创建数字签名的步骤。
8、根据权利要求7的方法，其中所述第二方的所述数字签名是确定性签名。
9、根据权利要求1的方法，其中所述数据串C包括下列中的至少一个：
i)为所述交易T的至少一部分的数字签名，其中所述数字签名是用第一方的保密密钥计算出来的；
ii)消息验证代码，其中所述消息验证代码是用第一方的保密密钥计算出来的；
iii)电子支票
10、根据权利要求1的方法，其中所述数据项V包括下列中的至少一个：
a)C的数字签名，其中所述数字签名是用第二方的保密密钥计算出来的；
b)消息验证代码值，其中所述消息验证代码值是用第二方已知的保密密钥计算出来的。
11、根据权利要求1的方法，其中所述第二方使所述第三方接收到所述信息I的步骤包括下列中的至少一个：
a)第二方将I发送到第三方；
b)第二方请求第五方将I发送到第三方；以及
c)第二方将I记在一个文件中并且所述第三方从所述文件获取I。
12、根据权利要求1的方法，还包括第二方在接收到C后检查C的真实性和完整性的步骤。
13、根据权利要求12的方法，其中第二方利用与第一方有关的公有验证信息以便检查C的真实性和完整性。
14、根据权利要求13的方法，其中所述公有验证信息包括公有密钥数字签名方案中与第一方的保密密钥对应的第一方的公有密钥。
15、根据权利要求13的方法，其中第二方利用所述公有验证信息的步骤包括下列中的至少一个：
(a)第二方从第一方获得所述公有验证信息；
(b)第二方从与所述数据串C有关联的第一方发送的信息中获得所述公有验证信息；
(c)第二方从数字证书中获得所述公有验证信息；
(d)第二方从第一方有关的可获得的公有信息中获得所述公有验证信息。
16、根据权利要求1的方法，其中第二方和第四方相同。
17、根据权利要求1的方法，其中所述第二方和所述第三方相同。
18、根据权利要求1的方法，共中仅当F(V)＜s时V满足P，其中F是函数，s是常数。
19、根据权利要求18的方法，其中0＜s＜1。
20、根据权利要求1的方法，其中F是采用任意比特串作为输入并返回一个大于0小于1的数作为输出的函数。
21、根据权利要求1的方法，其中所述交易T由交易值Tv部分表征。
22、根据权利要求21的方法，其中所述第四方接收到的金额大于Tv。
23、根据权利要求20的方法，其中所述交易T由交易值TV部分表征，并且其中所述第四方接收到的所述金额等于(Tv*1/s)。
24、根据权利要求1的方法，
(a)其中所述数据项V包括涉及所述数据串C的所述第二方的数字签名；并且
(b)其中如果F(V)小于s，V就满足P，F表示操作比特串并返0和1之间的一个数作为输出的公有函数。
25、根据权利要求1的方法，其中所述数据串C包含涉及T的信息，所述信息包括下列中的至少一个：
a)第一方的身份；
b)交易的时间；
c)交易的日期。
26、用户U为交易值为Tv的交易T向销售商M建立支付的一种方法，该方法包括：
A.该用户为第一数字签名方案建立公有密钥和相应的保密密钥，并从T获取一个数据串C＝SIU(T)以创建包含C的电子支票，其中SIGU(T)表示用户U在所述第一数字签名方案中对交易T的数字签名；
B.该用户使该销售商接收到所述数据串C；
C.该销售商为第二数字签名方案建立公有密钥和相应的保密密钥，并将所述数据串C和一个数据项V＝SIGM(C)关联在一起，其中SIGM(C)表示销售商M在所述第二数字签名方案中对所述数据串C的数字签名。
D.该销售商计算值F(V)＝F(SIGM(C))，F表示一个操作比特串以输出一个0和1之间的数的公有函数；
E.该销售商比较F(SIGM(C))和常数s以确定是否F(V)＜s，如果是就使银行获得该销售商的所述公共密钥；
F.银行用该销售商的所述公共密钥验证F(SIGM(C))＜s；并且
G.仅当F(SIGM(C))＜s时，银行使该销售商接收到金额A＝[Tv*1/s]；其中s是大于0小于1的一个常数，并且表示该电子支票被选择提交给银行的概率。
27、用于为交易T建立支付的一种***，该***包括：
A.通信装置，用于在第一方、第二方、第三方和第四方之间传输数据；
B.第一处理装置，由第一方操作用于获取、输入和存储与T有关的数据串C；
C.第二处理装置，由第二方响应C操作用于将一个数据项与C的至少一部分关联在一起并确定V是否满足属性P；其中V完全不可能由第一方预测；
D.当V满足P时由第二方选择性地操作以使第三方接收到使第三方能够验证V是否满足P的信息I的装置；和
E.当V满足P时由第三方选择地操作以使第四方接收到金额A的装置。
28、用于为交易T建立支付的一种方法，该方法包括：
A.第一方从第二方接收到数据串C的至少一部分，其中所述数据串C与T有关；
B.第一方将C的所述至少一部分与一个数据项V关联在一起，其中V完全不可能由第二方预测；和
C.第一方确定V是否满足P，仅当V满足P时第一方使第三方接收到使第三方能够验证V是否满足所述属性P的信息I，由此在确定V满足P后使第三方能够让第四方接收到金额A。
29、为交易T建立支付的一种方法，该方法包括：
A.第一方从第二方接收到使第一方能够验证数据项V是否满足属性P的信息I；其中所述数据项与第三方从T获得的数据串C的至少一部分相关联，并且其中V完全不可能由所述第三方预测；
B.第一方在接收到V之后验证V是否满足所述属性P；和
C.仅当V满足属性P时，第一方使第四方接收到金额A。
30、为由时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方从T获取与T有关的数据串C，其中C包括与所述时间t有关的信息IN；
B.第一方使第二方接收所述数据串C的至少一部分，其中C的所述至少一部分包含信息IN；
C.第二方将C的所述至少一部分与一个数据项关联在一起，其中V完全不可能由第一方预测；
D.第二方确定V是否满足属性P，如果V满足属性P第二方在时间t’使第三方接收到信息IN和使第三方能够验证V是否满足所述属性P的信息I；
E.第三方在接收到I之后验证V是否满足属性P；和
F.仅当：a)V满足属性P，并且b)|t’-t|小于预定时间间隔时第三方使第四方接收到金额A。
31、根据权利要求30的方法，其中所述预定时间间隔|t′-t|是n天，n是从1到7的一个非零整数。
32、根据权利要求30的方法，其中所述预定时间间隔|t′-t|是至少m个小时，m是从1到24的一个非零整数。
33、根据权利要求30的方法，其中第一方在步骤B中在时间t′＞t使第二方接收到C的所述部分，并且其中如果|t′-t|不小于预定数量第二方就拒绝接受C作为支付。
34、根据权利要求30的方法，其中所述数据串C包括用第一方的保密密钥创建的对T的至少一部分的数字签名。
35、根据权利要求30的方法，其中仅当V与C的至少一部分匹配时V才满足P。
36、根据权利要求30的方法，其中所述属性取决于V而不是C。
37、根据权利要求30的方法，其中仅当F(V)＜s时V才满足P，其中F是一个函数，s是一个常数且0＜s＜1。
38、根据权利要求37的方法，其中函数F的值F(V)是第一方完全不能预测的。
39、根据权利要求39的方法，其中在C中指定了所述函数F和所述常数s中的至少一个。
40、根据权利要求37的方法，其中F是下列之一：
(a)固定的公有函数；
(b)以任意比特串作为输入并返回一个大于0小于1的数作为输出的公有函数。
41、根据权利要求30的方法，其中V包括用第二方的保密密钥计算出的C的数字签名，表示为SIGM(C)。
42、根据权利要求30的方法，在第四方接收到金额A的步骤之后，还包括第三方使第一方接收到由第二方提供的对一个或多个交易TSi(i＝1，…，n)的订购的步骤，前提是对所有的i(i＝1，…，n)，所述交易TSi由时间tsi部分表征且|tsi-t|小于预定量。
43、根据权利要求30的方法，其中所述V包括下列中至少一个的数字签名：
(a)与T有关并被包含在C中的日期信息；
(b)C中包含的序号；
(c)C中包括的串；
(d)C中的随机串部分；和
(e)取决于C的一个量。
44、根据权利要求30的方法，其中所述数据项V包括G(C)的数字签名，G代表函数和算法中的至少一个。
45、根据权利要求4 4的方法，其中仅当F(V)＝F(SIGM(G(C)))＜s时所述数据项V才满足P；其中F代表一个函数；其中s代表一个常数且0＜s＜1；并且其中值F(V)完全不可能由第一方预测。
46、根据权利要求4 4的方法，其中G(C)被指定在T和C中的至少一个中。
47、根据权利要求4 4的方法，其中G(C)包括下列中的至少一个：
(a)T的一个子串；
(b)与交易T的时间t有关的信息F；
(c)与交易T发生的日期有关的信息；和
(d)由第一方选择的串W。
48、根据权利要求47的方法，其中所述串W对T是唯一的，并且是随机选择的。
49、根据权利要求47的方法，其中V＝SIGM(G(C))适合由第二方在接收到所述C的至少一部分之前计算出。
50、根据权利要求44的方法，其中如果V＝SIGM(G(C))的至少一些比特匹配C的至少一些比特，则满足所述属性P。
51、根据权利要求44的方法，其中如果在V＝SIGM(G(C))选择的m-比特匹配C中选择的m-比特则满足所述属性P，其中m是预定的正整数。
52、根据权利要求51的方法，其中m约为10.
53、为交易T建立支付的一种方法，该方法包括：
A.第一方从T获取与T有关的数据串C，并使第二方接收到的数据串C的至少一部分；
B.第二方确定P在C的所述至少一部分和一个取决于C的量Q之间是否成立，其中Q完全不可能由第一方预测，如果成立，第二方使第三方接收到使第三方能够验证满足所述属性P的信息I；
C.第三方在接收到I之后验证证是否满足所述属性P；和
D.只有在验证的述属性P在C的所述至少一部分和Q之间成立时，第三方使第四方接收到金额A。
54、根据权利要求53的方法，其中所述量Q可以被表示为G(C)，其中G是函数和算法中的至少一个。
55、根据权利要求54的方法，其中G(C)包括涉及下列中至少一个的信息：
(a)交易T发生时的时间t，和
(b)交易T发生时的日期d。
56、根据权利要求55的方法，其中仅当C的至少一些比特等于SIGM(G(C))的至少一些比特时所述属性P才成立，SIGM(G(C))表示用第二方的保密密钥创建的G(C)的数字签名。
57、为由时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方从T获得与T有关的数据串C；
B.第二方获取与一系列时间ti(i＝1，…，n)相关的一系列值VL，其中对至少一个大于1小于n的整数m，|t-tm|小于一个预定量。
C.第一方使第二方接收到所述数据串C的至少一部分，其中所述部分包括与所述交易T的时间t有关的信息；
D.第二方确定P在C的所述部分和与tm相关的所述值VLm以及取决于VLm的一个数量Q中的一个之间是否成立；
E.如果P成立，第二方使第三方接收到使第三方能够验证是否满足所述属性P的信息I；
F.第三方在接收到I之后验证Q是否满足P；并且
G.仅当Q满足所述属性P时，第三方使第四方接收到金额A。
58、根据权利要求57的方法，其中所述数量Q由Q＝F(SIGM(Vm))给出，F代表一个函数，SIGM(Vm)代表用第二方的保密密钥创建的Vm的数字签名。
59、为由交易时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方从T获取与T有关的数据串C，其中C包括与t有关的信息；
B.第二方获取与一系列时间单位ti(i＝1，…，n)相关的一系列值Vi；其中每对相邻的时间单位ti+1和ti定义了一个时间间隔Δti＝ti+1-ti；并且其中对至少一个大于1小于n的整数m，所述时间t在时间间隔Δtm之内；
C.在所述时间间隔Δtm的开始，第二方获取与Vm相关的值Qm，其中Qm完全不可能由第一方预测到；
D.在时间间隔Δtm内：
a)第一方使第二方接收到C的至少一部分；
b)第二方确定在C的所述部分和Qm之间属性P是否成立，如果成立，第二方使第三方接收到使第三方能够验证所述属性P是否被满足的信息I；
E.第三方在接收到I之后，验证Q是否满足P；并且
F.仅当Q满足所述属性P之后，第三方使第四方接收到金额A。
60、根据权利要求59的方法，其中步骤C发生在步骤B之前，并且其中仅当Q的至少一些比特匹配C的至少一些比特时才满足所述属性P。
61、根据权利要求59的方法，其中Qi由Qi＝F(SIGM(Vi))给出，F代表一个函数，SIGM(Vi)第二方的保密密钥创建的Vi的数字签名。
62、根据权利要求59的方法，其中对于所有i＝0，1，…，n，时间间隔Δti＝|ti+1-ti|是预定时间间隔。
63、根据权利要求62的方法，其中所述预定常量是一天。
64、为由时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方从T获取与T有关的数据串C，其中C包括与t有关的信息F；
B.第二方获取与一系列时间单位ti(i＝1，…，n)相关的一系列值xi(i＝1，…，n)，并将x0公开；其中对i＝0，1，…，n-1，xi＝H(xi+1)，H是个单向散列函数；其中每对相邻的时间单位ti+1和ti定义了一个时间间隔Δti＝ti+1-ti；并且其中对至少一个大于1小于n的整数m，所述时间t在时间间隔Δtm之内；
C.在所述时间间隔Δtm内，第一方使第二方接收到C的至少一部分，其中所述部分包括F；第二方获取与Vm相关的值Qm，其中Qm完全不可能由第一方预测到；
D.在所述时间间隔Δtm内：第二方确定在Qm和C的所述部分属性P是否成立，如果成立，第二方使第三方接收到使第三方能够验证所述属性P是否被满足的信息I；
E.第三方在接收到I之后，验证Q是否满足P；并且
F.仅当Q满足所述属性P之后，第三方使第四方接收到金额A。
65、根据权利要求64的方法，其中第二方将x0公开的步骤包括下列中的至少一个：
a)将x0放在一个公有文件中；
b)用第二方的保密密钥对x0进行数字签名，并将相应的公有密钥放在公有手册中；
66、根据权利要求64的方法，其中所述时间间隔Δti＝ti+1-ti对所有i＝1，…，n是一个常数。
67、为由时间t部分表征的交易T建立支付的一种***，该***包括：
A.用于在第一方、第二方、第三方和第四方之间传输数据的通信装置；
B.第一处理装置，可由第一方操作用于获取、输入和存储与T有关的数据串C，其中C包含与时间t有关的信息F；
C.第二处理装置，可由第二方操作并响应C用于将数据项V与C的至少一部分关联在一起并确定V是否满足属性P；其中V完全不可能被第一方预测到；
D.当V满足P时由第二方选择性操作以使第三方接收到F和使第三方能够验证V是否满足P以及|t′-t|是否小于一个预定数量的装置；
E.当V满足P且|t′-t|小于一个预定数量时由第三方选择性操作以使第四方接收到金额A的装置。
68、为由时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方在时间t′从第二方接收到使第一方能够验证数据V是否满足属性P的信息I；其中所述数据项V与第三方从T获得并包括了与t有关的信息的数据串C的至少一部分相关闻；并且其中V完全不可能被所述第三方预测到；
B.第一方在接收到I之后验证V是否满足所述属性P；并且
C.仅当a)V满足所述属性P，且b)|t′-t|小于一个预定数量时第一方使第四方接收到金额A。
69、为由时间t部分表征的交易T建立支付的一种方法，该方法包括：
A.第一方从第二方接收到数据串C的至少一部分，其中所述数据串C与T有关，并且C的所述部分包括了与t有关的信息；
B.第一方将C的所述至少一部分与一个数据项关联在一起，其中V完全不可能被第二方预测到；
C.第一方确定V是否满足P，如果是，第一方在时间t′使第三方接收到使第三方能够验证V是否满足P的信息I，由此使第三方在a)V满足所述属性P，且b)|t′-t|小于一个预定数量时能够使第四方接收到金额A。
70、为大量的n个交易T1，T2，…Tj，…Tn建立支付的一种方法，其中在1和n之间的索引i可以与各个交易Ti相关联，并且其中每个交易Ti由交易值TVi部分表征，该方法包括：
A.第一方用概率支付方法为每笔交易Ti产生一个支票Ci并使第二方接收到所述Ci，其中Ci包括索引i的指示；
B.第二方以让第一方不能***哪些支票Cj将被选择成为应支付支票的一种方式选择应支付的支票Cj(1＜＝j＜＝n)；
C.第二方使第三方接收到使第三方能够验证所选择的支票Cj是否应支付的信息Ij；
D.第三方在接收到Ij后，验证所选择的支票Cj是否应被支付；
E.仅当Cj应被支付时，第一方使第四方接收到存入金额CRj，并使第一方被扣除金额Di，这样对1和n之间的所有索引，并且对应支付支票的任何选择，D＝D1+D2+…+Dj不大于TVagg＝TV1+TV2+…+TVj。
71、根据权利要求70的方法，其中1到n之间的所有索引j，每个扣除金额Dj至少部分由TVj和Cj之一决定。
72、根据权利要求70的方法，其中每个扣除金额Dj被称为与Tj相关的所述索引j。
73、根据权利要求72的方法，其中每个扣除金额Dj还取决于一个先前的扣除金额Dk(1＜＝k＜j＜＝n)和为其扣除了金额D1的一个先前的索引1(1＜＝1＜j＜＝n)之一。
74、根据权利要求70的方法，还包括所述第五方使得为被选择进行支付的第个支票Cj存储索引j的指示的步骤。
75、根据权利要求74的方法，其中应支付支票Cj的每个扣除金额Dj取决于最后存储的发现应被支付的任何先前的支票的索引k。
76、根据权利要求70的方法，其中第二方使第三方接收信息Ij的步骤包括下列中的至少一个：
a)第二方将Ij发送到第三方；
b)第二方请求第五方将Ij发送到第三方；和
c)第二方将Ij放在一个文件中，所述第三方从所述文件获取Ij。
77、为大量的n个交易T1，T2，…Ti…Tn建立支付的一种方法，其中1和n之间的索引i可以与各个Ti相关联，其中交易Ti由交易值TVi部分表征，该方法包括：
A.第一方从每个交易Ti获取一个与Ti有关的数据串Ci，并使第二方接收到所述数据串Ci；
B.第二方将每个数据串Ci与一个数据项Vi关联在一起，其中Vi完全不可能被第一方预测到；
C.第二方确定Vi是否满足属性Pi，如果是，第二方使第三方接收到使第三方能够验证Vi是否满足属性Pi的信息Ii；
D.第三方在接收到Ii之后验证Vi是否满足属性Pi；和
E.仅当Vi满足属性Pi时，第五方使第四方接收到存入金额CRi，并使第一方被扣除金额Di；其中所述扣除金额Di小于或等于所述存入金额CRi。
78、根据权利要求77的方法，其中对1和n之间的所有索引，D1+D2+…+Di小于或等于TV1+TV2+…+TVi。
79、根据权利要求77的方法，其中对1和n之间的所有索引，各个扣除金额Di至少部分由TVi和Ci之一确定。
80、根据权利要求77的方法，其中每个数据串Ci包含与Ti相关的所述索引i的指示。
81、根据权利要求80的方法，其中每个扣除金额Di取决于与Ti相关的所述索引i。
82、根据权利要求81的方法，其中每个扣除金额Di还取决于一个先前的扣除金额Dj以及为其扣除了金额Dk的一个先前的索引k中的一个。
83、根据权利要求82的方法，其中对1和n之间的所有索引，D1+D2+…+Di小于或等于TV1+TV2+…+TVi。
84、根据权利要求77的方法，还包括只要Vi满足属性Pi所述第五方就促成为每个数据串Ci存储信息SNi的步骤。
85、根据权利要求84的方法，其中SNi是代表所述数据串Ci相对于其它数据串的顺序的渐进序号。
86、根据权利要求84的方法，其中各个扣除金额Di是用SNi确定的。
87、根据权利要求84的方法，其中对1和n之间的所有索引，D1+D2+…+Di小于或等于TV1+TV2+…+TVi。
88、根据权利要求84的方法，其中各个扣除金额Di是用SNi确定的。
89、为多个价值都TV的等值交易Ti，T2，…Ti…Tn建立支付的一种方法，该方法包括：
A.第一方从各个交易Ti获取与Ti有关的数据串Ci，并使第二方接收到所述数据串Ci；其中每个数据串Ci包括一个渐进序号Si，所述渐进序号Si从1开始依次有序并代表Ci相对于有序的数据串序列Cj(j＝1，…，n)中其它数据串的位置
B.第二方将Ci与一个数据项Vi关联在一起，其中Vi不可能被第一方预测到；
C.第二方确定在Ci和Vi之间属性Pi是否成立，如果成立，第二方使第三方接收到使第三方能够验证Vi是否满足Pi的信息Ii；
D.第三方验证Vi是否满足Pi；并且仅当Vi满足Pi时：
a)第五方确定Smax的值，其中Smax代表Ck中包含的任何序号的最大值，对Ck来说：
i)1＜k＜n；
ii)Ck是在接收到Ci之前被第二方接收到；
iii)第三方已经验证了Vk满足Pk；并且
iv)所述第一方已经被扣除了非零金额Dk；
b)所述第五方使第四方接收到存入金额CR；以及
c)所述第五方使第一方被扣除金额Di，Di＝(Si-Smax)*TV。
90、根据权利要求89的方法，其中仅当F(Vi)＜s时Vi才满足Pi，s是一个数，F是操作一个比特串并返回一个数的函数。
91、根据权利要求90的方法，其中由所述第四方接收到的所述存入金额CR正比于TV和1/s。
92、根据权利要求90的方法，其中F是操作一个比特串以输出一个在0和1之间的数的函数，其中s是0和1之间的一个数。
93、用户U为交易值为TVi(i＝1，…，n)的多个交易Ti(i＝1，…，n)向销售商M建立支付的一种方法，该方法包括：
A.用户U为第一数字签名方案建立公有密钥和相对应的保密密钥，从每个Ti获取一个数据串Ci＝SIGU(Ti)并创建一个包含Ci和序号Si的电子支票CHi；
其中SIGU(Ti)代表所述第一数字签名方案中用户Ui对交易Ti的数字签名；
其中Si是一个渐进序号，代表所述数据串Ci相对于所述第一方获取的有序的数据串序列Cj(j＝1，…，n)的位置；
B.用户U使销售商M接收到包含Ci和Si的所述电子支票CHi；
C.销售商M为第二数字签名方案建立公有密钥和相对应的保密密钥，并将所述数据串Ci和一个数据项Vi＝SIGM(Ci)关联在一起，其中SIGM(Ci)代表销售商M在所述第二数字签名方案中对所述数据串Ci的数字签名；
D.销售商M计算值F(Vi)＝F(SIGM(Ci))，F代表操作一个比特串以输出一个0和1之间的数的公有函数；
E.销售商M比较F(SIGM(Ci))和一个常数s(0＜s＜1)以确定是否F(Vi)＜s，如果是，就使银行获得销售商M的所述公有密钥；
F.银行用销售商的公有密钥验证是否F(SIGM(Ci))＜s；以及
G.仅当F(SIGM(Ci))＜s时：
a)第五方确定Smax的值，其中Smax代表依据其进行支付的所述有序序列中的任何CHj中包含的最大序号Sj；
b)所述第五方使第四方接收到存入金额CR；并且
c)所述第五方使第一方被扣除金额Di。
94、根据权利要求9 3的方法，其中各个交易Ti(i＝1，…，n)是等值的，所以对所有的i＝1，…，n，TVi＝TV，并且共中Di＝(Si-Smax)*TV，其中CR＝TV*(1/s)。
95、用于为大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种***，其中1和n之间的索引i可以与各个Ti相关联，并且其中各个交易Ti由交易值TVi部分表征，该***包括：
A.用于在第一方、第二方、第三方和第四方之间传输数据的通信装置；
B.第一处理装置，可由第一方操作用于获取、输入和存储数据串Ci(i小于等于n且大于等于1)，其中Ci与交易Ti有关，并且其中Ci包括渐进序号Si，Si代表支票Ci在有序支票顺序Cj(j＝1，…，n)中的其它支票的位置；
C.第二处理装置，可由第二方操作并响应Ci用于将数据项Vi与Ci的至少一部分关联在一起以及确定Vi是否满足属性Pi，其中Vi完全不可能被第一方预测到；并且其中所述第二处理装置在Vi满足Pi时被第二方选择性运行以使第三方接收到使第三方能够验证Vi是否满足Pi的信息Ii；
D.当Vi满足Pi时被第三方选择性运行的装置，用于确定Smax的值、使第四方接收到金额CRi、并使第一方被扣除金额Di，其中对1和n之间的所有索引，D1+D2+…+Di不大于TV1+TV2+…+TVi。
96、用于为大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种方法，其中1和n之间的索引i可以与各个Ti相关联，并且其中各个交易Ti由交易值TVi部分表征，该方法包括：
A.第一方从第二方接收到每个Ci的数据串Ci的至少一部分，其中每个数据串Ci是用概率支付方案从Ti生成的，并且其中每个Ci包括索引i的指示；
B.第二方以让第一方无法***哪些支票Cj将被选为应支付支票的方式选择支票Cj(j小于等于n且大于等于0)为应支付支票；
C.对于每个被选中的支票Cj，第一方使第三方接收使第三方能够验证所选择的支票Cj确实应被支付的信息Ij，由此使第三方在验证了Cj应被支付后使第四方接收到存入金额CRj并且第二方被扣除金额Di，所以对于1和n之间的所有索引j以及对应支付支票Cj的任何选择，D＝D1+D2+…+Dj不大于TVagg＝TV1+TV2+…+TVj。
97、用于为大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种方法，其中1和n之间的索引i可以与各个Ti相关联，并且其中各个交易Ti由交易值TVi部分表征，该方法包括：
A.第一方从第二方接收到使第一方能够验证支票Cj是否应被支付的信息Ij；其中所述支票Cj是被第二方从由第三方从所述大量交易Ti(i＝1，…，n)中获得的大量相应的支票Ci(i＝1，…，n)中选出的；并且其中对所述支票Cj的选择是所述第三方完全不可能预测的；
B.第一方在接收到Ij之后验证Cj是否确实应被支付；和
C.第一方使第四方接收到金额CRi并使第三方被扣除金额Di。
98、用于为大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种方法，其中各个交易Ti由交易值TVi部分表征TVi是单位值TV的倍数，该方法包括：
A.第一方从各个交易Ti获取与Ti对应的数据串Ci，并使第二方接收到所述数据串Ci；其中每个数据串Ci以向量(Si，Si+vi-1)的形式包括与所述整数索引i和Ti的所述价值TVi有关的信息；其中对1和n之间所有的i，Si是一个渐进序号Si，代表Ci相对于有序的数据串序列Cj(j＝1，…，n)中其它数据串的位置；并且其中vi是取决于i的整数并且表示Ti的价值TVi，vi＝TVi/(UV)；
B.第二方以让第一方无法***哪些支票Cj将被选为应支付支票的方式选择支票Cj(j小于等于n且大于等于0)为应支付支票；
C.第二方使第三方接收到使第三方能够验证Vi是否满足Pi的信息Ii；
D.第三方在接收到Ij之后验证所选择的Cj是否应被支付；
E.仅当Cj应被支付时：
a)第五方确定Smax的值，其中max是一个整数，满足1＜＝max＜＝n，并且Vmax＝TVmax/(UV)；并且其中Smax代表Ck(1＜k＜n)中包含的任何序号的最大值，对Ck来说：
ii)Ck是在接收到Ci之前被第二方接收到；
iii)第三方已经验证了Vk满足Pk；并且
iv)所述第一方已经被扣除了非零金额Dk；
b)所述第五方使第四方接收到存入金额CR；以及
c)所述第五方使第一方被扣除金额Di，Di＝(Si+vi-1-Smax)*TV
99、用于为大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种方法，其中1和n之间的索引i可以与各个Ti相关联，并且其中各个交易Ti由交易值TVi部分表征，TVi是单位值UV的倍数，该方法包括：
A.第一方从各个交易Ti获取与Ti对应的数据串Ci，并使第二方接收到所述数据串Ci；其中每个数据串Ci以向量(Si，Si+vi-1)的形式包括与所述整数索引i和Ti的所述价值TVi有关的信息；其中对1和n之间所有的i，Si是一个渐进序号Si，代表Ci相对于有序的数据串序列Cj(j＝1，…，n)中其它数据串的位置；并且其中vi是取决于i的整数并且表示Ti的价值TVi，vi＝TVi/(UV)；
B.第二方将Ci与一个数据项Vi关联起来，其中Vi完全不可能被第一方预测；
C.第二方确定在Ci和Vi之间属性P是否成立，如果是，第二方使第三方接收到使第三方能够验证Vi是否满足Pi的信息Ii；
D.第三方验证Vi是否满足Pi；
E.仅当Vi满足Pi时：
a)第五方确定Smax的值，其中max是一个整数，满足1＜＝max＜＝n，并且Vmax＝TVmax/(UV)；并且其中Smax代表Ck(1＜k＜n)中包含的任何序号的最大值，对Ck来说：
ii)Ck是在接收到Ci之前被第二方接收到；
iii)第三方已经验证了Vk满足Pk；并且
iv)所述第一方已经被扣除了非零金额Dk；
b)所述第五方使第四方接收到存入金额CR；以及
c)所述第五方使第一方被扣除金额Di，Di＝(Si+vi-1-Smax)*TV
100、为大量n个交易Ti(i＝1，…，n)建立支付的一种方法，每个交易Ti的值为TVi，该方法包括：
A.第一方从每个Ti获得对应与Ti有关的一个数据串Ci，并使第二方接收到所述数据串Ci；
B.第二方唯一地将所述数据串Ci(i＝1，…，n)分成m个列表Lk，k＝1，…，m；其中每个列表Lk包括数据串Ck 1，…，Ck 1k并且其中∑m k＝1lk＝n；
C.第二方通过为每个Lk计算提交CMk而提交Lk(k＝1，…，m)，并使第三方接收到CMk(k＝1，…，m)；
D.第三方在接收到CMk(k＝1，…，m)之后，选择一个或多个整数索引i1，i2，…ir，并使第二方接收到所述索引i1，i2，…ir，其中1＜＝ir＜＝m；
E.接收到i1，i2，…ir之后，第二方回收CMi1，CMi2，…CMir，由此向第三方揭示了Li1，…，Lir；并且
F.第五方使第四方接收到存入金额CR，并且使第一方被扣除金额D。
101、根据权利要求100的方法，其中对Lk的所述提交CMk是散列值H(Lk)，其中H是一个单向散列函数。
102、根据权利要求100的方法，其中每个数据串Ci包括代表所述交易值TVi的一个或多个比特。
103、根据权利要求102的方法，在步骤(b)之后，还包括第二方将相应的值Vk与各个列表Lk关联在一起的步骤，其中Vk代表列表Lk中的呢数据串Ck 1，…，Ck 1k的总值，其中Vk＝TVk 1+…+TVk 1k
104、根据权利要求102的方法，在步骤(c)后，还包括第二方为值列表(V1，…，Vm)计算提交CV的步骤，其中所述提交向第二方提交(V1，…，Vm)，其中CV是散列值H(V1，…，Vm)；并且其中H是单向散列函数，所以第二方通过回收CV可以向第三方揭示(V1，…，Vm)。
105、根据权利要求100的方法，其中第四方接收到的所述存入金额CR由下形式给出：
V＝V1+…+Vk+…Vm＝∑m k＝1Vk
106、根据权利要求100的方法，其中所述扣除金额D由下式给出：
D＝Vi1+Vi2+…+Vir乘以一个放大因子
107、根据权利要求106的方法，其中所述放大因子是m/r。
108、根据权利要求100的方法，其中所述每个数据串Ci包括代表整数SNi的信息，其中SNi是一个从1开始顺序有序的渐时序号，并且SNi代表所述交易Ti相对于所述大量n个交易Ti(i＝1，…，n)中的其它交易T1，…，Ti-1和Ti+1，…，Tn的时间顺序。
109、根据权利要求100的方法，其中第一方从Ti获取所述数据串Ci的步骤包括第一方用第一方的保密密钥为Ti的至少一部分创建数字签名的步骤。
110、根据权利要求100的方法，其中Ci的至少一部分被进行了验证。
111、根据权利要求100的方法，其中Ci包括下列中的至少一个：
a)T的至少一部分的数字签名；
b)消息验证代码；和
c)电子支票。
112、根据权利要求100的方法，其中所述第五方和所述第三方相同。
113、根据权利要求100的方法，其中所述第二方、所述第三方和所述第五方相同。
114、根据权利要求100的方法，其中所述第二方和所述第三方相同。
115、为大量n个交易Ti(i＝1，…，n)建立支付的一种方法，每个交易Ti的值为TVi，该方法包括：
A.对于每个Ti，第一方从第二方接收到从Ti获取的一个数据串Ci，并使第二方接收到所述数据串Ci；
B.第一方唯一地将所述数据串Ci(i＝1，…，n)分成m个列表Lk，k＝1，…，m；其中每个列表Lk包括数据串Ck 1，…，Ck 1k并且其中∑m k＝1lk＝n；
C.第一方通过为每个Lk计算提交CMk而提交Lk(k＝1，…，m)，并使第三方接收到CMk(k＝1，…，m)，由此使第三方能够选择一个或多个整数索引i1，i2，…ir其中1＜＝ir＜＝m；
D.接收到i1，i2，…ir之后，第一方回收CMi1，CMi2，…CMir，由此向第三方揭示了Li1，…，Lir，并且使第三方能够使第四方接收到存入金额CR以及使第二方被扣除金额D。
116、为大量n个交易Ti(i＝1，…，n)建立支付的一种方法，每个交易Ti的值为TVi，并且每个交易Ti可以由从Ti获取的一个相应的数据串Ci代表，并且其中所述数据串Ci(i＝1，…，n)可以被唯一地分成m个列表Lk(k＝1，…，m)，每个列表Lk包括数据串Ck 1，…，Ck1k(∑m k＝1lk＝n)，该方法包括：
A.第一方从第二方接收到对m个列表Lk(k＝1，…，m)中每个列表的提交CMk；
B.第一方在接收到CMk(k＝1，…，m)之后选择一个或多个整数索引i1，i2，…ir，其中1＜＝ir＜＝m，并使第二方接收到所述索引i1，i2，…ir，由此使第二方能够回收CMi1，CMi2…CMir以便向第一方揭示Li1，…，Lir；
C.第一方使第三方接收到存入金额CR，使第四方被扣除金额D。
117、用于为各自具有价值TVi的大量n个交易T1，T2，…，Ti，…，Tn建立支付的一种***，该***包括：
A.用于在第一方、第二方、第三方和第四方之间传输数据的通信装置；
B.第一处理装置，由第一方操作用于为每个Ti获取、输入和存储一个数据串Ci；
C.第二处理装置，由第二方在接收到Ci后操作用于将所述数据串Ci(i＝1，…，n)唯一分成k个列表Lk(k＝1，…，m)以及输入并存储所述更表Lk(k＝1，…，m)；其中每个列表Lk包括数据串Ck 1，…，Ck 1k并且其中∑m k＝1lk＝n；
所述第二处理装置还由第二方操作用于为每个Lk计算提交CMk以及用于输入和存储所述提交CMk(k＝1，…，m)；
D.第三处理装置，可由第三方在接收到所述提交CMk之后操作用于选择一个或多个整数索引i1，i2，…ir并使第二方接收到所述索引i1，i2，…ir，其中对所有的r都有1＜＝ir＜＝m；
E.第四处理装置，可由第二方在接收到所述索引i1，i2，…ir之后操作用于回收CM，由此向第三方揭示；以及
F.由第三方在揭示了Li1，…，Li2之后操作的装置，用于第一方被扣除金额D并使第四方接收到存入金额CR。
Figure A20058002868101071
Figure A20058002868101091
Figure A20058002868101121
Figure A20058002868101131

Claims (36)

1、一种支付处理***，包括：
第一交易处理机，它被配置用来合并与消费者和销售商之间的小额销售交易相关的费用数据，该第一交易处理机还被配置用来将代表合并后的费用数据的数据发送到与该销售商相关的收单金融实体；
第二交易处理机，它被配置用来存储代表各个单独的小额销售交易的数据，其中所存储的数据可以被与该销售商相关的至少一个金融实体访问。
2、权利要求1的支付处理***，其中该第二交易处理机位于远离消费者和销售商的地方。
3、权利要求1的支付处理***，其中该第一交易处理机还被配置用来合并与该销售商和至少两个消费者之间的小额销售交易相关的费用数据。
4、权利要求1的支付处理***，其中该第一交易处理机还被配置用来合并与至少两个销售商相关的小额销售交易的相关费用数据，其中这些销售商与相同的金融实体相关。
5、权利要求1的支付处理***，其中消费者基于按使用付费向销售商支付小额销售交易。
6、权利要求1的支付处理***，其中消费者基于预付费向销售商支付小额销售交易。
7、权利要求1的支付处理***，其中消费者基于订购向销售商支付小额销售交易。
8、权利要求1的支付处理***，其中消费者基于后付费向销售商支付小额销售交易。
9、权利要求1的支付处理***，其中所存储的代表各个单独的小额销售交易的数据可被所述收单金融实体访问。
10、权利要求1的支付处理***，其中所存储的代表各个单独的小额销售交易的数据可被与该消费者相关的发卡金融实体访问。
11、权利要求1的支付处理***，其中所存储的代表各个单独的小额销售交易的数据可被消费者访问。
12、权利要求1的支付处理***，其中所述第一交易处理机还被配置用来将消费者请求转到所述第二交易处理机以提供消费者服务。
13、权利要求1的支付处理***，其中所述第一交易处理机位于与该消费者相关的发卡金融实体。
14、权利要求1的支付处理***，还包括：
第三交易处理机，被配置用来跟踪对小额销售交易中的至少一个的支付核对。
15、权利要求14的支付处理***，其中所述第三交易处理机位于收单金融实体。
16、权利要求1的支付处理***，还包括：
第四交易处理机，被配置用来将总费用数据转换成第三方的格式。
17、权利要求16的支付处理***，其中该第四交易处理机位于包括该第一交易处理机的服务器中。
18、权利要求1的支付处理***，其中所存储的代表各个单独的小额销售交易的数据包括与交易中的至少一个相关的帐号的单向散列。
19、权利要求1的支付处理***，其中所存储的数据被解密以备访问。
20、权利要求1的支付处理***，其中的小额销售交易中至少有一个发生在售货亭设备。
21、权利要求1的支付处理***，还包括：
第三交易处理机，被配置用来合并与所述消费者和第二个销售商之间的小额销售交易相关的费用数据。
22、权利要求1的支付处理***，其中所述销售商向消费者提供了优先处理以鼓励与该销售商的未来交易。
23、一种处理支付的方法，包括：
接收代表第一个消费者和第一个销售商之间的第一个小额销售交易的数据；
将该第一个小额销售交易的费用与该消费者和该销售商之间的第二个小额销售交易的费用合并在一起；
存储与该第一个小额销售交易相关的数据以使该数据能够被与该销售商相关联的至少一个金融实体访问到；以及
将表示该总费用的数据发送到与该销售商相关联的至少一个收单金融实体。
24、权利要求23的方法，还包括：
将与第一个消费者相关联的小额销售交易的费用和与第二个消费者相关联的小额销售交易的费用合并在一起。
25、权利要求23的方法，还包括：
将与第一个销售商相关联的小额销售交易的费用和与第二个销售商相关联的小额销售交易的费用合并在一起，其中该第一和第二个销售商与该收单金融实体相关联。
26、权利要求23的方法，其中所存储的与该第一个小额销售交易相关联的数据可以被该收单金融实体访问。
27、权利要求23的方法，其中所存储的与该第一个小额销售交易相关联的数据可以被与该消费者相关联的发卡金融实体访问。
28、权利要求23的方法，其中所存储的与该第一个小额销售交易相关联的数据可以被该消费者访问到。
29、权利要求21的方法，其中存储与第一个小额销售交易相关联的数据包括向与该第一个小额销售交易相关联的帐号应用单向散列。
30、一种驻留在计算机可读介质上的计算机程序产品，具有存储在该计算机可读介质上的大量指令，当所述指令被处理器执行时使处理器：
接收代表第一个消费者和第一个销售商之间的第一个小额销售交易的数据；
将该第一个小额销售交易的费用与该消费者和该销售商之间的第二个小额销售交易的费用合并在一起；
存储与该第一个小额销售交易相关的数据以使该数据能够被与该销售商相关联的至少一个金融实体访问到；以及
将表示该总费用的数据发送到与该销售商相关联的至少一个收单金融实体。
31、权利要求30的计算机程序产品，还包括指令以：
将与第一个消费者相关联的小额销售交易的费用和与第二个消费者相关联的小额销售交易的费用合并在一起。
32、权利要求30的计算机程序产品，还包括指令以：
将与第一个销售商相关联的小额销售交易的费用和与第二个销售商相关联的小额销售交易的费用合并在一起，其中该第一和第二个销售商与该收单金融实体相关联。
33、权利要求30的计算机程序产品，其中所存储的与该第一个小额销售交易相关联的数据可以被该收单金融实体访问。
34、权利要求30的计算机程序产品，其中所存储的与该第一个小额销售交易相关联的数据可以被与该消费者相关联的发卡金融实体访问到。
35、权利要求30的计算机程序产品，其中所存储的与该第一个小额销售交易相关联的数据可以被该消费者访问到。
36、权利要求30的计算机程序产品，其中存储与第一个小额销售交易相关联的数据包括向与该第一个小额销售交易相关联的帐号应用单向散列。
CNA2005800286811A 2004-06-25 2005-06-27 支付处理方法和*** Pending CN101010690A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US58301004P 2004-06-25 2004-06-25
US60/583,010 2004-06-25
US60/648,789 2005-02-01

Publications (1)

Publication Number Publication Date
CN101010690A true CN101010690A (zh) 2007-08-01

Family

ID=38698126

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2005800286811A Pending CN101010690A (zh) 2004-06-25 2005-06-27 支付处理方法和***

Country Status (1)

Country Link
CN (1) CN101010690A (zh)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105245327A (zh) * 2015-08-21 2016-01-13 北京比特大陆科技有限公司 比特币工作量证明哈希计算芯片优化的方法、装置和电路
CN105590378A (zh) * 2015-11-24 2016-05-18 ***股份有限公司 一种pos终端和利用该pos终端进行测试的方法
CN106503996A (zh) * 2015-09-08 2017-03-15 Sk普兰尼特有限公司 基于web的支付业务提供设备、方法以及***
CN107533701A (zh) * 2015-05-11 2018-01-02 万事达卡亚太私人有限公司 在令牌化支付交易中奖励消费者的方法和***
CN107578235A (zh) * 2009-12-14 2018-01-12 Visa欧洲有限公司 便携式支付装置
CN108476207A (zh) * 2015-11-16 2018-08-31 万事达卡国际股份有限公司 用于认证网络消息的***和方法
CN109493507A (zh) * 2017-09-11 2019-03-19 K·L·埃斯灵格 产生回报行为的自动小费罐
CN110062374A (zh) * 2019-05-31 2019-07-26 贵阳朗玛通信科技有限公司 一种号码及sim卡的分配方法及装置
CN110310413A (zh) * 2019-06-14 2019-10-08 北京未来购电子商务有限公司 一种自助设备的免支付使用方法及自助设备
CN111986411A (zh) * 2020-09-10 2020-11-24 珠海优特物联科技有限公司 结算方法和***
CN112884586A (zh) * 2021-04-28 2021-06-01 支付宝(杭州)信息技术有限公司 交易执行方法和区块链节点
CN112926763A (zh) * 2021-01-15 2021-06-08 远光软件股份有限公司 支付申请的排程方法、装置、存储介质及服务器
CN116797331A (zh) * 2022-11-04 2023-09-22 武汉旻一数字科技有限公司 一种基于大数据的银行卡读卡器读取数据采集管理***

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107578235A (zh) * 2009-12-14 2018-01-12 Visa欧洲有限公司 便携式支付装置
CN107533701A (zh) * 2015-05-11 2018-01-02 万事达卡亚太私人有限公司 在令牌化支付交易中奖励消费者的方法和***
CN105245327A (zh) * 2015-08-21 2016-01-13 北京比特大陆科技有限公司 比特币工作量证明哈希计算芯片优化的方法、装置和电路
CN106503996A (zh) * 2015-09-08 2017-03-15 Sk普兰尼特有限公司 基于web的支付业务提供设备、方法以及***
CN108476207B (zh) * 2015-11-16 2021-02-02 万事达卡国际股份有限公司 用于认证网络消息的***和方法
CN108476207A (zh) * 2015-11-16 2018-08-31 万事达卡国际股份有限公司 用于认证网络消息的***和方法
CN105590378A (zh) * 2015-11-24 2016-05-18 ***股份有限公司 一种pos终端和利用该pos终端进行测试的方法
CN109493507A (zh) * 2017-09-11 2019-03-19 K·L·埃斯灵格 产生回报行为的自动小费罐
CN110062374A (zh) * 2019-05-31 2019-07-26 贵阳朗玛通信科技有限公司 一种号码及sim卡的分配方法及装置
CN110062374B (zh) * 2019-05-31 2022-06-07 贵阳朗玛通信科技有限公司 一种号码及sim卡的分配方法及装置
CN110310413A (zh) * 2019-06-14 2019-10-08 北京未来购电子商务有限公司 一种自助设备的免支付使用方法及自助设备
CN111986411A (zh) * 2020-09-10 2020-11-24 珠海优特物联科技有限公司 结算方法和***
CN111986411B (zh) * 2020-09-10 2022-11-25 珠海优特物联科技有限公司 结算方法和***
CN112926763A (zh) * 2021-01-15 2021-06-08 远光软件股份有限公司 支付申请的排程方法、装置、存储介质及服务器
CN112884586A (zh) * 2021-04-28 2021-06-01 支付宝(杭州)信息技术有限公司 交易执行方法和区块链节点
CN112884586B (zh) * 2021-04-28 2021-08-03 支付宝(杭州)信息技术有限公司 交易执行方法和区块链节点
CN116797331A (zh) * 2022-11-04 2023-09-22 武汉旻一数字科技有限公司 一种基于大数据的银行卡读卡器读取数据采集管理***
CN116797331B (zh) * 2022-11-04 2024-05-28 重庆市奉节县兴农融资担保有限责任公司 一种基于大数据的银行卡读卡器读取数据采集管理***

Similar Documents

Publication Publication Date Title
US11887077B2 (en) Generating exchange item utilization solutions in an exchange item marketplace network
CN101010690A (zh) 支付处理方法和***
US11164228B2 (en) Method and medium for determining exchange item compliance in an exchange item marketplace network
KR20070034603A (ko) 지불 처리 방법 및 시스템
KR101961899B1 (ko) 가상화폐와 명목화폐 간의 환율을 고려한 가상화폐 자동 결제 서비스 제공 방법
JP2000509859A (ja) 外国為替損失に備えるために保証証券を発生および実行するための装置および方法
CN103858141A (zh) 带有集成芯片的支付设备
US11238444B2 (en) Secure and trusted cryptocurrency acceptance system
KR20200078940A (ko) 블록체인 기반의 암호화폐 결제 및 환전 서비스 제공 방법 및 장치
US20120173436A1 (en) Method and system for authorizing, authenticating, implementing, brokering data transfers, and collecting fees for data transfers among distributed electronic devices and servers
US20230125124A1 (en) Obtaining conditions data for utilizing an exchange item
KR20090002050A (ko) 복수 계좌 연동형 카드 운용 방법 및 시스템과 그를 위한프로그램 기록매체
KR101933658B1 (ko) 암호화폐 투자의 리스크 관리를 위한 서비스 제공방법
KR20080104404A (ko) 가맹점 계좌를 이용한 매출채권 처리방법 및 시스템과 이를위한 기록매체
KR20090002052A (ko) 계좌를 이용한 복수 결제승인 처리방법 및 시스템
KR20090057193A (ko) 입금경로 별 상점 회계정보를 통한 대출금액 산출 서버
JP2010113737A (ja) 取引情報処理システム
KR20090002049A (ko) 계좌연동 쿠폰 등록 방법 및 시스템
KR20090002056A (ko) 고객 맞춤형 계좌 운용방법 및 시스템과 이를 위한기록매체
KR20090002060A (ko) 할인쿠폰 및 기금지원 복합 결제승인 처리방법 및 시스템과그를 위한 프로그램 기록매체
KR20090036162A (ko) 온라인 계좌를 이용한 자녀 용돈 충전 방법 및 시스템과이를 위한 기록매체
Ruiz-Martínez et al. Combination of a Smartcard E-Purse and E-Coin to Make Electronic Payments on the Internet.
KR20090085559A (ko) 복수 계좌 연동형 카드 운용방법
KR20090079869A (ko) 할인쿠폰 및 기금지원 복합 결제승인 처리 시스템
KR20090060245A (ko) 가치형 계좌 운용방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1110674

Country of ref document: HK

ASS Succession or assignment of patent right

Owner name: ROCK WEDGE CO., LTD.

Free format text: FORMER OWNER: PEIPERL COIN COMPANY

Effective date: 20081114

C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20081114

Address after: oregon

Applicant after: Rock wedge company

Address before: Massachusetts

Applicant before: Peppercoin Inc.

C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Open date: 20070801