CN1645393A - 一种实现小额支付的通信交互方法 - Google Patents

Abstract

本发明公开了一种实现小额支付的通信交互方法，每个客户端可随时向支付中心发起请求申请自身所需的款额；支付中心通过对发起请求客户端的身份认证后，根据该客户端的需求生成多币值支付字链组，支付字链组中的每条支付字链代表不同的币值；然后，支付中心将所生成的多币值支付字链组发送给发起请求的客户端，同时，将对应不同服务提供端的相关信息分别发送给不同的服务提供端；客户端在每次交易结束进行支付时，先确定需要采用的币值，然后将所采用币值对应的每条支付字链中当前的支付字发送给对应的服务提供端；通过服务提供端的合法性验证后，服务提供端接受此支付。采用该方法能提高小额支付的安全可靠性和效率，且更适合移动通信环境的使用。

Description

一种实现小额支付的通信交互方法

技术领域

本发明涉及实现小额支付的通信交互技术，尤指一种针对移动通信环境的、通过离线兑换实现小额支付的通信交互方法。

背景技术

随着无线通信网络的发展和手持设备的迅速普及，与之相关的应用层出不穷，从电子银行到移动定位到移动广告等等，数以百万计的移动用户希望能通过手机等移动终端购买信息和服务，换句话说就是，移动用户对移动电子商务的需求越来越高。对于电子商务而言，高效和安全的支付方案是其重要的实现基础，尤其是在移动环境中，由于要考虑到更多的影响因素，比如：移动设备性能、计算能力、存储空间的限制，无线接口传输的安全可靠性，网络基础设施的构建，客户对移动电子商务应用所要求的安全保障等等，使得安全和高效成为移动电子商务中一个非常严峻的问题和挑战。

在移动电子商务中，考虑到移动通信的特点，比如：移动终端的计算能力、存储能力，空中接口的传输能力等等，采用的支付形式主要是小额支付，即每次交易的费用额度较小。小额支付主要会涉及到客户端(Consumer)、支付中心(Broker)和服务提供端(Vendor)，其中，客户端可简称C，是使用微电子货币购买商品的主体；服务提供端可简称V，为用户提供商品并接收支付；支付中心可简称B，作为可信第三方存在，用于为C和V维护账号、通过证书或其他方式认证C和V的身份、进行货币销售和清算，并解决可能引起的争端，可以是一些中介机构，也可以是银行等。相应的，实现小额支付的通信交互就涉及三个实体：客户端、服务提供端和可信第三方。

对于移动小额支付来说，速度和成本是要考虑的重要因素，对于速度的影响主要是移动支付过程中计算量与网络性能。通常，为了减少计算量可以将计算量大的过程离线处理，如：电子货币的生成、帐务清算等；另外，安全算法的选择对计算量也有很大的影响，移动支付最主要的是要尽量减少移动用户一端的计算和存储。

目前，对于小额支付已提出了一些适合于不同场景的实现方案，根据支付中货币的形式，可分为基于票据(Scrip)、或基于hash链两类。其中，基于票据的小额支付方案包括Millicent和SubScrip等；基于hash链的典型的方案有PayWord等。根据支付形式，也可以分为离线支付和在线支付，其中，在线支付有SubScrip等，离线支付包括PayWord、Millicent、MicroMint等。在线支付系统中，每一次支付都要对货币进行验证，以防止双重消费等欺诈行为，如此会造成性能瓶颈，因此在线支付不适合于移动支付。而现有的离线支付协议适合于特定的情景，同时有一定的限制，比如：Millicent对单个服务提供端交易进行了优化，但由于凭据是针对特定服务提供端的且最终由服务提供端产生和验证，所以，客户端不能验证凭据的真伪，因为针对每一个新的服务提供端，客户端都要请求一个新的票据，Millicent对经常更换服务提供端的客户端效率不高。又如：PayWord采用离线的认证和兑换方式，采用hash链作为货币形式，由于采用了强hash函数的特性，已知已花费的PayWord，导出未花费的PayWord在计算上是很困难的，这样就可以有效防止PayWord的伪造，有很好的计算性能和安全性，但PayWord也有一些问题，比如：不能保证匿名性，不能防止客户端超额消费，采用公钥签名计算量大等。

具体来说，PayWord是由密码学学者Rives及Shamir所提出的，属于一种后付费形式。PayWord架构的实体包括客户端、服务提供端和支付中心，这里，支付中心相当于可信第三方。主要交易过程如图1所示，包括以下步骤：

步骤11：完成一次交易后，客户端向支付中心发送凭证(C_U)请求，该请求中携带有本次的交易帐号；支付中心收到请求后，给客户端分配一个凭证(C_U)并发送给客户端；客户端收到支付中心所分配的凭证后，自行产生一个支付字链。

本步骤中，由于支付字属于信用式交易系统，支付字链又是客户端自行产生的，所以，为了确保收到的支付字值的合法性，支付中心必需颁发一张经由自身签章的凭证C_U给客户端，以保证服务提供端所收到的支付字值可以兑现。

这里，所述支付字凭证的形式为：C_U＝{B，U，A_U，PK_U，E，I_U}_SKB，其中，B为产生此凭证的支付中心，客户端所产生的支付字只能被此支付中心赎回；U为经授权可使用此C_U产生支付字链的客户端；A_U为客户端传送的位置，包含Intemet host address或e-mail等；PK_U为客户端的公钥，用来确认证书中客户端的数字签章；E为凭证的使用期限；I_U为其它的信息，如客户端或服务提供端或支付中心的一些详细资料。该支付字凭证以支付中心自身的私钥SK_B加密后发送给客户端。

所述客户端产生的支付字链形式为：x₀←x₁←x₂←....←x_i....←x_n-1←x_n其中，x_i＝h(x_i+1)，i＝n-1，n-2，...，1，0.，h()是一个密码学上的单向hash函数，h()可以采用SHA1等。

步骤12：客户端产生支付字链之后，将一些信息用自身的私钥SK_u签名生成承诺M后发送给服务提供端，服务提供端收到后即确认这些信息的正确性，是否为有效的支付字链。其中，客户端发送给服务提供端的信息包括：W₀、V、C_U、D、Im，这里，W₀为支付字链中的第一个支付字，即支付字链的根，用来验证后续支付字的正确性；V为服务提供端；D为当前日期；Im为附加信息。

步骤13：服务提供端对客户端发送来的信息确认无误后，以后每次交易都经由客户端发送交易讯息P给服务提供端，由服务提供端经过计算验证确认无误后最终完成每次交易。

具体来说，客户端第一次与服务提供端交互时，即产生一串支付字链和一个承诺，并将所产生的承诺传送给服务提供端；服务提供端对客户端信息验证无误后，储存W₀。当下次客户端有支付需求时，将W₁送给服务提供端，服务提供端只需比对是否h(W₁)＝W₀，若是，则完成交易并将W₀更新为W₁，在下次交易时，比对先前的支付字，直到W_N出现为止。

步骤14：服务提供端周期性的，比如每天或每个月与支付中心进行交互，向支付中心进行清算取款操作。

由于服务提供端会收到许多来自不同客户端的不同的支付字链，当服务提供端要拿这些支付字向适当的支付中心换取现金时，对于每个不同的支付字链，服务提供端必须要将以下两个信息传送给支付中心：①相应客户端对此支付字链所签署的承诺M；②已花费支付字的最高次数P_1ast。

支付中心在收到服务提供端的信息后，将W_L做L次的hash运算，将其值和从证书中得到的W₀比较是否相同，若相等，则支付中心即将所花费的金额从容户端的帐号转至服务提供端的帐号中。

目前，采用PayWord方案存在的主要问题是客户恶意透支信用，对服务提供端带来很大损害，该问题主要是由支付字的缺陷导致的，从安全和效率的角度来看，支付字有如下缺陷：a)如果除C、B和V以外的终端获取了B的公钥，则可以解密证书，并了解C的详细信息，特别是证书中地址信息的加入，将严重破坏C的匿名性；b)C必须对自身需要支付的V签署一个承诺，如果频繁互换V的话，将会带来很大的计算消耗；c)C必须针对每一个与自己进行交互的服务提供端做一次生成hash链的计算，造成C的计算消耗；d)C必须为每一个服务提供端保存不同的支付链，造成C的存储消耗；e)不能防止C的超额消费。

总之，现有的小额支付方案没有特别针对移动计算环境进行设计的，因此要从移动终端的计算能力、存储能力等方面对小额支付方案进行优化。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现小额支付的通信交互方法，能提高小额支付的安全可靠性和效率，且更适合在移动通信环境下使用。

为达到上述目的，本发明的技术方案是这样实现的：

一种实现小额支付的通信交互方法，适用于包括支付中心、一个或一个以上客户端、至少一个服务提供端的系统，其特征在于，该方法包括取款和支付两个流程，其中，取款流程包括以下步骤：

a1.客户端向支付中心发起所需金额和订单信息的取款请求，支付中心对所述客户端进行认证，认证通过后，支付中心生成包含至少一条hash链的支付字链组，每条hash链与每种币值一一对应；

b1.支付中心将所生成的支付字链组发送给发起请求的客户端，同时，支付中心将至少包含对应相应服务提供端的每条hash链的根向量、有效期信息和客户端信息的授权指令发送给相应服务提供端，相应服务提供端保存所有信息；

支付流程包括：

a2.当客户端需要提供服务时，所述客户端向对应的服务提供端发送包含当前支付字和支付字序号的支付请求；

b2.所述服务提供端验证通过后保存所收到的支付字，并返回确认以及所提供的服务。

该方法进一步包括：每个客户端将自身的相关信息发送给支付中心，支付中心对相应客户端认证通过后，为该客户端生成唯一对应该客户端的随机数，并将所生成的随机数与该客户端的相关信息和账号绑定并存储，然后，支付中心将所生成的随机数返回给相应客户端。

该方法进一步包括：每个服务提供端将自身的地址信息发送给支付中心，支付中心对相应服务提供端认证通过后，支付中心将所收到的地址信息与相应服务提供终端的账号绑定并存储。

该方法进一步包括：每个服务提供端周期性或根据需要将支付金额、含有支付字的凭证信息、订单信息及相应客户端相关信息发送给支付中心，支付中心验证支付字是否有效合法，如果验证通过，支付中心再比较支付金额与消费上限值，如果不大于，则支付中心从自身取出等于支付金额的金额，放入发送消息的服务提供端对应的账号中。

上述方案中，所述客户端同时向一个以上服务提供端发送支付请求消息。

步骤a1进一步包括：将每条支付字链切割为一个以上支付字子链，每个支付字子链对应一个服务提供端，所述生成支付字链组并切割的方法具体包括：

a11.确定支付字链的条数，每条支付字链对应一个币值；

a12.针对每个支付字链组的总金额，计算每条支付字链的长度，再将n个支付字链组中对应的每条支付字链的长度分别相加，得到每条支付字链的总长度；其中，n等于服务提供端的数目；

a13.支付中心为每条支付字链取一个随机数作为种子，生成hash链，并根据每条支付字链的长度确定分割矩阵。

上述方案中，步骤b2所述服务提供端的验证为：所述服务提供端根据自身当前保存的支付字对所述客户端发来的当前支付字进行验证。

上述方案中，所述客户端为移动通信终端。

本发明所提供的实现小额支付的通信交互方法，针对移动环境对小额支付的特殊需求，对PayWord实现方案进行了改进，具有以下的优点和特点：

1)本发明采用预支付的方式，可避免客户端恶意透支信用的现象发生。

2)由于本发明由服务提供端产生支付字链，而且，同时产生多条对应不同金额的支付字链，进一步的，每个支付字链中可以包括多段对应不同服务提供端的支付字子链，可以减少移动客户端的计算消耗，减少hash链的数据存储量、hash计算次数以及通信量。因此，与PayWord方案相比，本发明在证书和密钥的存储方面，省掉了支付中心为客户端授权的证书以及客户端对服务提供端的承诺，存储量明显降低了。从图2的实验数据可以看出，采用PayWord协议，支付字数随金额的增长线性增长，而本发明的方案支付字数没有明显的增长，如果一个客户端同多个服务提供端进行交易，总金额较大时，本发明方案的优势就很明显了。图2和图3中，曲线a为采用本发明方案的效果，曲线b为采用PayWord技术方案的效果。

另外，从图3的实验数据可以看出，与单个客户端交易的服务提供端数目对存储的影响本质上是交易金额。另一方面，服务提供端数目的变化，对客户端而言，采用PayWord方案要为每个服务提供端保存一个20字节的支付字根和2字节的当前支付字序号，而采用本发明，则只需保存一个支付矩阵的分割矩阵和一个支付字序号矩阵，如采用四条链，则每个服务提供端只要8个字节。

3)本发明大大降低了计算消耗。假设在常见的工作站平台上每秒可产生2次RSA签名、200次RSA签名验证或20,000次hash计算，那么，以hash计算作为单位，进行分析比较。

首先，从客户端要进行的签名的角度来看，PayWord方案在首次支付要对每个服务提供端签署一次支付承诺，相当于10000次hash计算；而本发明的方案中，对任意个服务提供端，只要在申请取款时进行一次签名即可。

从图4中看出，对于针对多个服务提供端的情况，本发明客户端的签名计算量大大减少，并且唯一的签名是在申请取款时，可以离线进行，所以采用本发明交易中计算性能大大提高。

其次，比较生成支付字所需要的计算量，由于本发明方案中支付字是由支付中心生成的，所以在客户端根本没有计算。那么，采用单位币值为{50，10，5，1}的方案，图5显示出了PayWord方案与本发明方案生成支付字时进行hash计算的比较结果，显然，本发明的计算量要少得多。其中，图4和图5中，曲线a为采用本发明方案的效果，曲线b为采用PayWord技术方案的效果。

最后，比较服务提供端和支付中心的计算，采用PayWord，对服务提供端需要进行两次签名验证，第一次是使用支付中心的证书来验证用户证书，第二次是使用用户证书来验证支付承诺，相当于2*100次hash计算；而采用本发明的方案，服务提供端只要进行一次签名验证即可，相当于100次hash计算。两种方案，支付中心在交易过程中都没有计算，但本发明在申请取款时要进行支付字的生成和签名计算，但计算主要在取款阶段，可采取离线方式，因此对系统的实时性能影响也不大。

4)由于本发明所生成的每条支付字链中都包括多段对应不同服务提供端的支付字子链，也就是说，本发明中每个用户可以同时与多个服务提供端针对不同金额的商品进行交易，用户使用起来更方便、灵活，更符合用户的使用习惯。

附图说明

图1为现有技术中PayWord方案实现小额支付的消息时序图；

图2为PayWord方案与本发明方案支付字存储量的比较效果图；

图3为服务提供端数量与存储量关系示意图；

图4为客户端签名计算量的示意图；

图5为生成支付字进行hash计算的计算量示意图；

图6为本发明中客户端和服务提供端进行开户注册的处理流程示意图；

图7为本发明兑换流程的实现过程示意图；

图8为本发明取款过程的实现流程示意图；

图9为本发明支付过程的实现流程示意图。

具体实施方式

本发明的核心思想是：由支付中心生成包括多条支付字链的多币值支付字链组，每个支付字链为一条hash链，对应一种币值，且每条支付字链由一个或多个对应不同服务提供端的支付字子链组成。具体说就是：每个客户端可以随时向支付中心发起请求，申请自身所需的款额；支付中心通过对发起请求客户端的身份认证后，根据该客户端的需求，比如：需要进行交易的服务提供端数目、需要申请的金额等等信息，遵循尽量减小支付字链长度以及减少hash链验证计算量的原则，生成多币值支付字链组，支付字链组中的每条支付字链代表不同的币值；然后，支付中心将所生成的多币值支付字链组发送给发起请求的客户端，同时，将对应不同服务提供端的相关信息，比如：支付字字根、客户端信息、订单信息，分别发送给不同的服务提供端；那么，客户端在每次交易结束进行支付时，先确定需要采用的币值，然后将所采用币值对应的每条支付字链中当前的支付字发送给对应的服务提供端；通过服务提供端的合法性验证后，服务提供端就接受此支付。

本发明实现支付的前提是：每个向支付中心申请款额的客户端要预先在支付中心进行注册，开设自己的账户；同样，每个服务提供端也需要在支付中心开设自身的账户。具体开户注册过程如图6所示，包括以下步骤：

步骤61：客户端将自身的相关信息CI发送给支付中心。这里，所述相关信息为终端信息、信用卡号等，该信息CI可采用客户端自身的私钥SK_C加密。

步骤62：支付中心对CI进行认证通过后，为该客户生成一个随机数ID_C，该ID_C与客户的真实身份没有关系，但该ID_C必须是唯一的，将ID_C及CI与客户端的账户绑定并存储，并将确认信息ACK和ID_C用支付中心的私钥SK_B进行加密后发送给客户端。

步骤63～64：服务提供端将自身的相关信息A_v发送给支付中心。这里，A_v可采用服务提供端自身的私钥SK_V加密；支付中心对A_v进行验证后，将A_v与服务提供端的账户绑定并存储，然后返回确认信息ACK。

在每次支付过程结束后，实际上服务提供端只是得到了相应的合法支付字，所以在实际应用中，还存在每个服务提供端周期性或根据自身需要与支付中心进行交互，将支付字作为凭证交给支付中心，得到真正的货币，该过程称为兑换过程，如图7所示。服务提供端发送经过公钥PK_i加密的、包含N_i、ID_C、ID_B、OI_i、P_i信息的兑换请求消息给支付中心，其中，N_i为兑换金额；P_i为支付字；ID_C、ID_B分别为客户端和支付中心的标识；OI_i为某个订单信息。支付中心检查Expiry是否过期，并验证支付字Pi的有效性，以及相关信息的真实性；通过验证后，支付中心将相应的金额转到发起请求的服务提供端的账户中；支付中心还将Pi与消费上限值比较，如果客户端消费金额小于消费上限值，则支付中心将剩余金额返还给客户端的账户中。完成兑换后，支付中心从自身的数据库中删除用来验证兑换请求有效性的相关信息。其中，消费上限值是用户申请取款时设定的，一般根据订单信息中的子订单OIi和取款金额Ni来设定。

本发明中实现小额支付的通信交互方法主要就包括两个流程：客户端从支付中心获取申请款额的取款流程，以及客户端向服务提供端付款的支付流程。

在取款过程中，客户端从特定的服务提供端获得服务前，要通过客户端软件浏览服务提供端所提供的服务以及信息产品，选择自己想要的商品。本发明中，客户端可以同时同n个服务提供端进行交易，而只发送一次取款请求即可。具体的取款流程如图8所示，包括以下步骤：

步骤81：客户端生成订单信息(OI)，OI由n个子订单OI_i(i＝1...n)组成，OI_i可以包括服务提供端V_i的地址A_Vi、取款金额N_i等信息；然后客户端发送包含{ID_C，OI，n}信息的取款请求到支付中心。其中，ID_C为该客户端的标识，n为客户端需要进行交互的服务提供端数目，所述{ID_C，OI，n}信息可采用公钥PK_B加密。

步骤82：支付中心收到取款请求后，根据自身存储的信息和请求中的信息，对该客户端进行认证，如果认证通过，支付中心从该客户端对应的账户中扣除相应的金额，并根据客户端的需求如所购商品的价格，生成多币值支付字链组。

这里，支付中心需要维护一张表，该表中包括每个客户端的ID_C和公钥PK_C，支付中心通过共享的公钥PK_C对取款请求进行解密，并对客户端进行验证。

本步骤中，如果确定客户端的身份无误，支付中心就会从该客户端对应的账户中扣除相应的金额，这就相当于客户端对所购的信息或服务进行了预支付，如此就可以防止可能发生的欺诈行为，降低了服务提供端的风险。

本步骤中，支付中心生成hash链的方法有两个特点：①采用多币值支付字链技术，以减小hash链长度和对hash链验证的计算量。具体说就是：采用多条hash链作为支付字链组，每条支付字链对应的一个hash值代表不同的金额，如1分、5分、10分等。②将多币值支付字链组切割成n份，每份相当于一个支付字子链组，对应一个服务提供端，这样一次计算得到的多币值支付字链组就可以与n个服务提供端进行交易。

生成多币值支付字链组并切割的具体方法是：

a.确定支付字链的条数α，每条链币值的基数为δ₁分、δ₂分、...、δ_α分；

b.针对每个多币值支付字链组的总金额N_i，计算各个链的长度，再将n个多币值支付字链组中对应的各个链的长度相加，得到各个链的总长度。即：为第1个多币值支付字链组确定每条链的长度，假定链长为β₁₁，β₁₂，...，β_1α，第1个多币值支付字链组总金额 $N_1=\underset{j=1}{\overset{\mathrm{\α}}{\mathrm{\Σ}}}{\mathrm{\δ}}_j\×{\mathrm{\β}}_{\mathrm{ij}};$ 以此类推，第i个多币值支付字链组每条链的长度为β_i1，β_i2，...，β_iα，第i个多币值支付字链组总金额 $N_i=\underset{j=1}{\overset{\mathrm{\α}}{\mathrm{\Σ}}}{\mathrm{\δ}}_j\×{\mathrm{\β}}_{\mathrm{ij}};$ 第n个多币值支付字链组每条链的长度为β_n1，β_n2，...，β_nα，第n个多币值支付字链组总金额 $N_n=\underset{j=1}{\overset{\mathrm{\α}}{\mathrm{\Σ}}}{\mathrm{\δ}}_j\×{\mathrm{\β}}_{\mathrm{ij}}.$

然后，由这n个多币值支付字链组合成一个总的多币值支付字链组，每条支付字链的长度为：β_1k+β_2k+...+β_nk+2，k＝1，...，α，多币值支付字链组总金额

$N=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{N}_i.$

c.支付中心为每条支付字链取一个随机数W_{i(β1i+β2i+...+βni)+1}，i＝1，...，α作种子，用来生成hash链，则得到：

$\left(\begin{array}{c}{W}_{i(\mathrm{\β}1i+\mathrm{\β}2i...+\mathrm{\βni})}=H\left(W_{i(\mathrm{\β}1i+\mathrm{\β}2i+...+\mathrm{\βni})+1}\right)\\ \·\·\·\\ W_{i0}=H\left(W_{i1}\right)\end{array}\right)$

其中，种子W_{i(β1i+β2i+...+βni)+1}不作为支付的货币，由种子组成的向量{W_{1(β11+...+βi1+...+βn1)+1}，W_{2(β12+...+βi2+...+βn2)+1}，...，W_{α(β1α...+βiα+...+βnα)+1}}作为消费上限值，保存在支付中心中，用来防止客户端超额消费和伪造支付字。W_i0是最后一个hash值，叫做hash链的根，也不作为支付的货币，W_i0被用来验证W_i1，W_i2，...，W_{ii(β1i+β2i+...+βni)}的有效性，最终交付给客户端的hash多链PL形式如下：

$\left(\begin{array}{c}{W}_{11},...,W_{1\left(\mathrm{\β}11\right)},...W_{1(\mathrm{\β}11+...+\mathrm{\βi}1)},...,W_{1(\mathrm{\β}11+...+\mathrm{\βi}1+...+\mathrm{\βn}1)}\\ W_{21},...,W_{2\left(\mathrm{\β}12\right)},...W_{2(\mathrm{\β}12+...+\mathrm{\βi}2)},...,W_{2(\mathrm{\β}12+...+\mathrm{\βi}2+...+\mathrm{\βn}2)}\\ \·\·\·\\ W_{\mathrm{\α}1},...,W_{\mathrm{\α}\left(\mathrm{\β}1\mathrm{\α}\right)},...,W_{\mathrm{\α}(\mathrm{\β}1\mathrm{\α}+...+\mathrm{\βi\α})},...,W_{\mathrm{\α}(\mathrm{\β}1\mathrm{\α}+...+\mathrm{\βi\α}...+\mathrm{\β}\mathrm{n\α})}\end{array}\right)$

其中，支付字{W_{1(β11+...+βi1}，W_{2(β12+...+βi2)}，...，W_{α(β1α+...+βiα)}}作为服务提供端V_i-1的消费上限值。所以，对应一个PL有一个矩阵S规定PL的分割方法，S表示如下：

$\left(\begin{array}{c}{\mathrm{\β}}_{11}...{\mathrm{\β}}_{i1}...{\mathrm{\β}}_{n1}\\ {\mathrm{\β}}_{12}...{\mathrm{\β}}_{i2}...{\mathrm{\β}}_{n2}\\ \·\·\·\\ {\mathrm{\β}}_{1\mathrm{\α}}...{\mathrm{\β}}_{\mathrm{i\α}}...{\mathrm{\β}}_{\mathrm{n\α}}\end{array}\right)$

步骤83：支付中心生成包含多条hash链的多币值支付字链组后，向发起取款请求的客户端返回取款响应，格式为：{N，PL，S，Expiry}PK_C。其中，N为取出的总金额；Expiry用来指定hash链的有效日期，同时，该参数也限定了客户端和服务提供端存储hash链的时间长度；S就是分割矩阵。支付中心保存了客户端所有取款信息的参数以及从客户端账户中取出的金额。

步骤84：支付中心同时也给服务提供端V_i发送授权指令：{R_i0，ID_C，ID_B，Expiry，OI_i}PK_V。其中，R_i0是V_i的hash链的根向量，即支付字根，V_i用R_i0来验证支付字的有效性；V_i检查了授权的有效性后，保存所有相关的信息。支付中心要保存{R₁₀，R₂₀，...R_n0}，以备将来验证服务提供端V_i的兑换请求。具体R₁₀，R₂₀，...R_n0的取值如下：

$\left(\begin{array}{c}{R}_{10}=\{W_{10},W_{20},...W_{\mathrm{\α}0}\};\\ R_{20}=\{W_{1\left(\mathrm{\β}11\right)},W_{2\left(\mathrm{\β}12\right)},...W_{\mathrm{\α}\left(\mathrm{\β}1\mathrm{\α}\right)}\}\\ R_{i0}=\{W_{1(\mathrm{\β}11+...+\mathrm{\β}(i-1)1)},W_{2(\mathrm{\β}12+...+\mathrm{\β}(i-1)2)},...,W_{\mathrm{\α}(\mathrm{\β}1\mathrm{\α}+...+\mathrm{\β}(i-1)\mathrm{\α})}\},i>2\end{array}\right)$

具体的支付过程如图9所示，当客户端要从某个服务提供端V_i购买商品，客户端发送支付请求消息{ID_C，P_i}给服务提供端V_i，其中P_i＝{(W_{1(β11+...+β(i-1)1+γ1)}，γ₁)，(W_{2(β12+...+β(i-1)2+γ2)}，γ₂)，...，(W_{α(β1α+...+β(i-1)α+γα)}，γ_α)}，其中，γ₁≤β_i1，γ₂≤β_i2，...，γ_α≤β_iα，且每次支付的金额 小于已申请的总金额N_i，P_i包括当前支付字和支付字序号。客户端按照次序花费自己的支付字，可以多次支付，序号最大为{β_i1，β_i2，...，β_iα}。第一次支付，服务提供端通过以下运算鉴定P_i的有效性：

后续的支付，服务提供端用P_i来验证P_i+1

服务提供端V_i验证了P_i的有效性后，将P_i保存，以备到支付中心兑换，同时，保存最后一个收到的支付字，防止客户端的双重消费；然后服务提供端向客户端返回收据和信息商品或服务，格式为{the receipt of the payment，item}，其中，the receipt of the payment为返回的收据，item代表服务提供端所提供的信息或服务项。

这样进行多次支付行为，直到{γ₁，γ₂，...γ_α}＝{β_i1，β_i2...β_iα}。

举例来说，由于是小额支付，所以商品的价值都是有限的，比如都不大于10元。那么，客户端、服务提供端和支付中心三方可先协商一个合适的货币金额方案，如：币值单位分别为500分，100分，50分，10分，1分，所协商的货币金额方案要适合消费的规律。然后，当客户端向支付中心发起取款请求时，客户端所生成的订单OI中要包含客户端要购买的每个服务提供端所提供的商品或服务中最高的单价M，比如150分，则支付中心为此服务提供端生成hash矩阵时所采用的每条hash链对应的币值要小于等于150分，即：可采用币值为100分，50分，10分，1分对应的hash链生成hash矩阵。这里采用均衡模式确定总价S分割方案：找出所有可能的分割方法，从中选出合适的方案，使每条hash链尽可能的一样长。

客户端从hash矩阵中找出合适的金额策略，在消费时，先从比想购买的商品价格P小的币值最大的

hash链中去找合适的支付字进行支付。

上述取款流程和支付流程，只有取款流程是在线的。对于每个客户端来说，进行一次取款流程，就可以完成多次支付流程，获得多次信息或服务，而且，可以从不同的服务提供端获得，比现有技术中一次支付就要对应一次取款的形式简单、方便了很多，减少找零钱的现象，更符合用户的消费和使用需求。并且，从计算量、存储量、传输量以及交互次数的角度来说，大大降低了对计算、存储、传输的要求，减轻了小额支付实现过程的复杂度，保证了整个小额支付过程的安全可靠性。

上例所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (8)

1、一种实现小额支付的通信交互方法，适用于包括支付中心、一个或一个以上客户端、至少一个服务提供端的系统，其特征在于，该方法包括取款和支付两个流程，其中，取款流程包括以下步骤：

a1.客户端向支付中心发起所需金额和订单信息的取款请求，支付中心对所述客户端进行认证，认证通过后，支付中心生成包含至少一条hash链的支付字链组，每条hash链与每种币值一一对应；

b1.支付中心将所生成的支付字链组发送给发起请求的客户端，同时，支付中心将至少包含对应相应服务提供端的每条hash链的根向量、有效期信息和客户端信息的授权指令发送给相应服务提供端，相应服务提供端保存所有信息；

支付流程包括：

a2.当客户端需要提供服务时，所述客户端向对应的服务提供端发送包含当前支付字和支付字序号的支付请求；

b2.所述服务提供端验证通过后保存所收到的支付字，并返回确认以及所提供的服务。

2、根据权利要求1所述的方法，其特征在于，该方法进一步包括：每个客户端将自身的相关信息发送给支付中心，支付中心对相应客户端认证通过后，为该客户端生成唯一对应该客户端的随机数，并将所生成的随机数与该客户端的相关信息和账号绑定并存储，然后，支付中心将所生成的随机数返回给相应客户端。

3、根据权利要求2所述的方法，其特征在于，该方法进一步包括：每个服务提供端将自身的地址信息发送给支付中心，支付中心对相应服务提供端认证通过后，支付中心将所收到的地址信息与相应服务提供终端的账号绑定并存储。

4、根据权利要求1、2或3所述的方法，其特征在于，该方法进一步包括：每个服务提供端周期性或根据需要将支付金额、含有支付字的凭证信息、订单信息及相应客户端相关信息发送给支付中心，支付中心验证支付字是否有效合法，如果验证通过，支付中心再比较支付金额与消费上限值，如果不大于，则支付中心从自身取出等于支付金额的金额，放入发送消息的服务提供端对应的账号中。

5、根据权利要求1、2或3所述的方法，其特征在于，所述客户端同时向一个以上服务提供端发送支付请求消息。

6、根据权利要求1所述的方法，其特征在于，步骤a1进一步包括：将每条支付字链切割为一个以上支付字子链，每个支付字子链对应一个服务提供端，所述生成支付字链组并切割的方法具体包括：

a11.确定支付字链的条数，每条支付字链对应一个币值；

a12.针对每个支付字链组的总金额，计算每条支付字链的长度，再将n个支付字链组中对应的每条支付字链的长度分别相加，得到每条支付字链的总长度；其中，n等于服务提供端的数目；

a13.支付中心为每条支付字链取一个随机数作为种子，生成hash链，并根据每条支付字链的长度确定分割矩阵。

7、根据权利要求1所述的方法，其特征在于，步骤b2所述服务提供端的验证为：所述服务提供端根据自身当前保存的支付字对所述客户端发来的当前支付字进行验证。

8、根据权利要求1所述的方法，其特征在于，所述客户端为移动通信终端。

Images