本申请涉及移动互联网领域，尤其涉及移动互联网业务数据交互中的数据处理方法、装置和系统。
背景技术：
在传统的移动互联网应用场景下，通常用户的移动客户端与诸如自动售货机、pos机之类的业务终端设备之间进行业务数据交互时，需要用户的移动客户端和业务终端设备二者同时都与业务服务器保持实时网络连接，即同时保持在线，才能完成业务数据交互过程。
然而由于环境的问题，业务终端设备的无线网络稳定性不高，或者由于缺乏维护和保养，业务终端设备无法与业务服务器保持实时网络连接，从而影响业务数据交互的成功率。
另外，业务终端设备的持续在线需求也会造成设备的采购和运营成本较高，造成移动业务数据交互的网络铺设和设备使用推广上的局限性。
因此，需求一种新的数据处理方式，以解决上述传统移动业务数据交互过程中业务终端设备无法与业务服务器实时保持在线而导致的业务数据交互成功率较低以及业务终端设备维护成本较高的问题。
技术实现要素：
本申请的主要目的在于提供一种数据处理技术，其能够解决现有技术中的上述问题。
根据本申请一个方面的实施例，提供了一种数据处理方法，其特征在于，包括：根据来自客户端的用户请求，生成与用户请求对应的业务数据信息；将业务数据信息传输给客户端；接收来自客户端的凭证数据信息，凭证数据信息是由业务服务器根据来自客户端的业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作；以及对经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求。
根据本申请一个方面的另一实施例，提供了一种数据处理装置，其特征在于，包括：业务数据生成模块，用于根据来自客户端的用户请求，生成与用户请求对应的业务数据信息；业务数据传输模块，用于将业务数据信息传输给客户端；第一凭证数据接收模块，用于接收来自客户端的凭证数据信息，凭证数据信息是由业务服务器根据来自客户端的业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作；以及凭证数据验签模块，用于对经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求。
根据本申请另一方面的实施例，提供了一种数据处理方法，其特征在于，包括：向业务终端设备发起用户请求；从业务终端设备接收由业务终端设备生成的与用户请求对应的业务数据信息；向业务服务器发送业务处理请求，以请求业务服务器基于业务数据信息完成业务处理操作并生成凭证数据信息；从业务服务器接收凭证数据信息，凭证数据信息是由业务服务器根据业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作；以及将凭证数据信息传输给业务终端设备，以由业务终端设备对凭证数据信息进行验签操作并根据验签操作的结果决定是否准予用户请求。
根据本申请另一方面的另一实施例，提供了一种数据处理装置，其特征在于，包括：用户请求发起模块，用于向业务终端设备发起用户请求；业务数据接收模块，用于从业务终端设备接收由业务终端设备生成的与用户请求对应的业务数据信息；业务处理请求发送模块，用于向业务服务器发送业务处理请求，以请求业务服务器基于所述业务数据信息完成业务处理操作并生成凭证数据信息；第二凭证数据接收模块，用于从业务服务器接收凭证数据信息，凭证数据信息是由业务服务器根据业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作；以及凭证数据传输模块，用于将凭证数据信息传输给业务终端设备，以由业务终端设备对凭证数据信息进行验签操作并根据验签操作的结果决定是否准予用户请求。
根据本申请又一方面的实施例，提供了一种数据处理方法，其特征在于，包括：接收来自客户端的业务处理请求，业务处理请求包括由业务终端设备根据来自客户端的用户请求生成的业务数据信息；根据业务数据信息，完成业务处理操作并生成凭证数据信息；对凭证数据信息进行加签操作；以及将经加签的凭证数据信息发送给客户端，以由客户端传输给业务终端设备，并由业务终端设备对凭证数据信息进行验签操作且根据验签操作的结果决定是否准予用户请求。
根据本申请又一方面的另一实施例，提供了一种数据处理装置，其特征在于，包括：业务处理请求接收模块，用于接收来自客户端的业务处理请求，业务处理请求包括由业务终端设备根据来自客户端的用户请求生成的业务数据信息；凭证数据生成模块，用于根据业务数据信息，完成业务处理操作并生成凭证数据信息；凭证数据加签模块，用于对凭证数据信息进行加签操作；以及凭证数据发送模块，用于将经加签的凭证数据信息发送给客户端，以由客户端传输给业务终端设备，并由业务终端设备对凭证数据信息进行验签操作且根据验签操作的结果决定是否准予用户请求。
根据本申请的另一方面，提供了一种数据处理系统，其特征在于，包括：
业务终端设备，其包括：业务数据生成模块，用于根据来自客户端的用户请求，生成与用户请求对应的业务数据信息；业务数据传输模块，用于将业务数据信息传输给所述客户端；第一凭证数据接收模块，用于接收来自客户端的凭证数据信息，凭证数据信息是由业务服务器根据来自客户端的业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作；和凭证数据验签模块，用于对经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求；
客户端，其包括：用户请求发起模块，用于向业务终端设备发起用户请求；业务数据接收模块，从业务终端设备接收由业务终端设备生成的与用户请求对应的业务数据信息；业务处理请求发送模块，用于向业务服务器发送业务处理请求，以请求业务服务器基于所述业务数据信息完成业务处理操作并生成凭证数据信息；第二凭证数据接收模块，用于从业务服务器接收凭证数据信息，凭证数据信息是由业务服务器根据业务数据信息完成业务处理操作后生成的，并且凭证数据信息由所述业务服务器进行了加签操作；和凭证数据传输模块，用于将凭证数据信息传输给业务终端设备，以由业务终端设备对凭证数据信息进行验签操作并根据验签操作的结果决定是否准予用户请求；以及
业务服务器，其包括：业务处理请求接收模块，用于接收来自客户端的业务处理请求，业务处理请求包括由业务终端设备根据来自客户端的用户请求生成的业务数据信息；凭证数据生成模块，用于根据业务数据信息，完成业务处理操作并生成凭证数据信息；凭证数据加签模块，用于对凭证数据信息进行加签操作；和凭证数据发送模块，用于将经加签的凭证数据信息发送给客户端，以由客户端传输给业务终端设备，并由业务终端设备对凭证数据信息进行验签操作且根据验签操作的结果决定是否准予用户请求。
与现有技术相比，根据本申请的技术方案，能够通过创建、处理和传输用于业务数据交互的凭证数据信息，来实现在业务终端设备与业务服务器断开网络连接即离线的状况下完成移动业务数据交互过程，从而降低了业务终端设备的成本，并提高了业务数据交互的成功率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1示出了根据本申请实施例的数据处理系统的架构示意图；
图2示出了根据本申请第一实施例的数据处理方法的步骤流程图；
图3示出了根据本申请第一实施例的变型实施例的数据处理方法的步骤流程图；
图4示出了根据本申请第二实施例的数据处理方法的步骤流程图；
图5示出了根据本申请第三实施例的数据处理方法的步骤流程图；
图6示出了根据本申请第四实施例的数据处理装置的结构框图；
图7示出了根据本申请第五实施例的数据处理装置的结构框图；以及
图8示出了根据本申请第六实施例的数据处理装置的结构框图。
具体实施方式
本申请的主要思想在于，通过创建、处理和传输凭证数据信息来实现在业务终端设备与业务服务器断开网络连接即离线的状况下也能够完成移动业务数据交互过程。具体而言，通过针对来自业务终端设备的业务数据信息创建凭证数据信息，基于非对称加密机制通过业务服务器和业务终端设备对该凭证数据信息进行相应的加签和/或验签处理，从而可以在业务终端设备与业务服务器断开网络连接的情况下，基于凭证数据信息来完成移动业务数据交互。更具体而言，在业务服务器侧利用业务终端设备的公钥对针对业务处理操作的凭证数据信息进行加签，并在业务终端设备侧利用业务终端设备的私钥对该凭证数据信息进行验签，从而解除了移动业务数据交互过程中业务终端设备需要持续在线(即与业务服务器实时保持网络连接)以便实时了解业务数据交互状况的限制，并且在该移动业务数据交互过程中只需要客户端保持在线，而业务终端设备可以处于离线状态，进而大大降低了业务终端设备的维护成本并提高了移动业务数据交互的成功率。
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为便于对本申请构思的理解和说明，下面结合一个典型应用场景，即移动支付来对本申请实施例进行具体描述。需要指出的是，尽管本文中将结合该典型应用场景对本申请构思的实施例进行具体描述，但本申请并不限于此，而是可以适用于现有或未来开发的其它任意适合的移动业务数据交互场景中。
<数据处理系统>
首先结合图1描述实施本申请构思的典型应用场景下的数据处理系统的整体架构。
如图1所示，根据本申请实施例的数据处理系统100可以包括业务服务器110、客户端120和业务终端设备130这三部分，以用于实施根据本申请的数据处理方法。在移动支付场景中，根据本申请实施例的数据处理方法、装置和系统可以用于实现交易的收单处理。所谓收单处理可以是指在验明支付方针对交易已经完成付款之后对支付方予以放行的处理。
在该应用场景中，业务服务器110可以为支付服务商的服务器，其可以是诸如支付宝、财付通、盛付通之类的第三方支付平台的服务器，也可以是网上银行的服务器。客户端120可以为诸如手机、个人计算机、个人数字助理、便携式设备之类的用户终端设备。特别是，客户端120可以为交易的支付方，其为交易创建者，在业务服务器侧开设有账户。业务终端设备130可以为用于收单处理的服务器设备或终端设备，即收单设备，例如pos机、自动售货机等。特别地，该业务终端设备130可以为交易的收款方所持有，以便进行收单处理。
另外，客户端120与业务服务器110之间的通信链路可以为诸如因特网、局域网、广域网之类的互联网通信链路，并且客户端120可以与业务服务器130保持实时连接。客户端120与业务终端设备130之间的通信链路可以为诸如声波、蓝牙、wifi、nfc(nearfieldcommunication，近场通信)之类的近场通信链路，需要进行数据交互时就通过近场通信链路连接来完成数据交互。业务服务器110与业务终端设备130之间通常不需要实时连接，必要时可以根据需要进行有线或无线连接以完成数据交互。
参照图1，当用户有数据交互需求例如购买需求时，可以通过用户的客户端120向业务终端设备130发起用户请求例如购买请求，该购买请求可以包括商品种类、数量等。业务终端设备130在接收到用户请求之后向用户返回相应的业务数据信息，该业务数据信息例如可以包括业务终端设备130的唯一标识符等信息。客户端120基于接收到的业务数据信息，向业务服务器110发送业务处理请求，例如申请创建交易。业务服务器110基于业务处理请求中的业务数据信息完成业务处理操作，例如创建交易并引导客户端120完成在线付款，以及向客户端120返回例如根据业务终端设备130的公钥加签后的凭证数据信息，例如交易付款成功凭证。客户端120将凭证数据信息传输给业务终端设备130。业务终端设备130例如根据业务终端设备130的私钥对该加签后的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求，例如对客户端120的用户请求予以放行或者拒绝放行。
通过上述数据处理系统架构，可以实现即使在业务终端设备与业务服务器断开连接即离线的情况下也能够完成移动数据业务交互过程，由此可以大大降低业务终端设备的维护成本以及提高移动业务数据交互成功率。例如在移动支付的收单业务场景下，可以实现离线收单处理，即在收单设备与支付服务商断开连接的情况下完成收单处理，由此可以大大降低移动支付和收单业务中收单设备的维护成本以及提高交易的成功率。
<数据处理方法>
下面分别结合图2至图5描述根据本申请第一至第三实施例的数据处理方法，其中更详细地描述在上述系统架构下的业务终端设备、客户端和业务服务器的每一侧的数据处理过程。
(第一实施例)
图2示出了根据本申请第一实施例的数据处理方法的步骤流程图，其中详细描述业务终端设备侧实施的数据处理方法。
如图2所示，在步骤s210处，业务终端设备可以根据来自客户端的用户请求，生成与用户请求对应的业务数据信息。
具体而言，如上面提及的，当用户有数据交互需求例如购买需求时，可以通过用户的客户端向业务终端设备发起用户请求例如购买请求，该购买请求可以包括商品种类、数量等。客户端可以通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式与业务终端设备建立连接，以发起用户请求。
响应于客户端的用户请求，业务终端设备可以生成创建数据交互业务所需的业务数据信息。该业务数据信息至少可以包括业务终端设备的唯一标识符。具体地，在本示例中，响应于客户端的购买请求，业务终端设备可以生成创建交易订单所需的信息，该信息可以包括待支付金额、交易时间、设备唯一标识符等。
然后，在步骤s220处，业务终端设备将生成的业务数据信息传输给客户端。
具体而言，业务终端设备可以通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式将上述业务数据信息传输给客户端，以由客户端请求业务服务器创建数据交互业务时使用。
接下来，在步骤s230处，业务终端设备接收来自客户端的凭证数据信息。
该凭证数据信息是由业务服务器根据来自客户端的上述业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作。该凭证数据信息用于指示业务服务器已经完成相关的业务处理操作。在一个实施例中，凭证数据信息至少包括业务的唯一标识符。其中，业务的唯一标识符是用于标识业务服务器针对业务数据信息创建的相应业务。业务处理时间是指业务服务器完成业务处理操作的时间。
更具体而言，在业务终端设备将业务数据信息传输给客户端之后，客户端可以在通过诸如因特网、局域网、广域网等互联网通信方式与业务服务器建立实时连接即在线的情况下，向业务服务器发送业务处理请求，以请求业务服务器基于上述业务数据信息来创建相应的数据交互业务。业务服务器创建相应的数据交互业务并完成业务数据交互过程，之后生成指示业务处理成功的凭证数据信息并对该凭证数据信息进行加签操作，例如根据业务终端设备的公钥进行加签操作。
在具体示例中，客户端可以在线向业务服务器例如支付服务商提交交易创建申请，申请内容包括待支付金额、交易时间、设备唯一标识符等业务数据信息。支付服务商根据客户端的交易创建申请，创建交易并引导客户端完成在线付款，并且生成交易付款成功凭证并对该凭证进行加签处理，然后将加签后的交易付款成功凭证返回给客户端。客户端通过诸如声波、蓝牙、wifi、nfc之类的近场双向通信方式将诸如交易付款成功凭证之类的凭证数据信息传输给业务终端设备。
在业务终端设备接收到经加签的凭证数据信息之后，在步骤s240处，对该经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予所述用户请求。
具体而言，如果凭证数据信息是根据业务服务器预先为业务终端设备设置的公钥-私钥对中的公钥进行加签的，则业务终端设备接收到该凭证数据信息后，就根据该公钥-私钥对中的私钥对该凭证数据信息进行验签操作。如果凭证数据信息是根据业务服务器预先为业务终端设备设置的公钥-私钥对中的私钥进行加签的，则业务终端设备接收到该凭证数据信息后，就根据该公钥-私钥对中的公钥对该凭证数据信息进行验签操作。在一个实施例中，业务服务器可以预先为每一个业务终端设备分别设置对应的公钥-私钥对，并且将公钥预先存储在业务服务器中，而将私钥预先存储在业务终端设备中，或者将私钥预先存储在业务服务器中，而将公钥预先存储在业务终端设备中。根据该加签-验签操作可以增强业务安全性。
如果验签成功，则业务终端设备准予用户请求。例如在移动支付的收单场景中，当对交易付款成功凭证验签成功时，例如收单设备的业务终端设备就对客户端予以放行。
如果验签失败，则业务终端设备拒绝用户请求。例如在移动支付的收单场景中，当对交易付款成功凭证验签失败时，业务终端设备就拒绝对客户端放行。
至此描述了根据本申请第一实施例的数据处理方法，其中基于对凭证数据信息的创建、传输和加签-验签处理，可以使得业务终端设备离线工作，即业务终端设备与业务服务器不需要实时连接，就可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
[变型实施例]
根据第一实施例的数据处理方法，用户有可能会重复提交凭证数据信息，这样会对移动业务数据交互造成不利影响。为防止凭证数据信息的重复提交和保证移动业务数据交互的安全性，下面结合图3描述根据本申请第一实施例的变型实施例的数据处理方法。
与第一实施例相比，该变型实施例的不同之处主要在于，在图2所示步骤s230和步骤s240之间增加预验证操作，该预验证操作对应于步骤s310。下面仅描述与第一实施例不同的操作步骤s310至s350。
如图3所示，在接收到来自客户端的凭证数据信息(参见图2的步骤s230)之后，进入步骤s310。
在步骤s310处，业务终端设备对所述凭证数据信息进行预验证操作，以验证凭证数据信息是否可信。
根据本申请的实施例，预验证操作至少可以包括以下操作中的至少一种：根据凭证数据信息中的业务处理时间，判断凭证是否过期；以及根据凭证数据信息中的签名信息，判断凭证是否被重复提交。
具体而言，在一个实施例中，当业务终端设备接收到凭证数据信息之后，可以将凭证数据信息中的业务处理时间与当前时间进行对比，如果时间差超过预定阈值，则判定凭证过期，否则判定凭证可信。
在另一个实施例中，当业务终端设备接收到凭证数据信息之后，可以将凭证数据信息中的签名信息与业务终端设备中存储的已验签名信息进行对比，如果已验签名信息中没有与该凭证数据信息中的签名信息相同的签名信息，则判定凭证可信，否则判定凭证是重复提交，不可信。
在又一个实施例中，当业务终端设备接收到凭证数据信息之后，可以先将凭证数据信息中的业务处理时间与当前时间进行对比。如果时间差超过预定阈值，则判定凭证过期，为不可信。如果时间差在预定阈值之内，则将凭证数据信息中的签名信息与业务终端设备中存储的已验签名信息进行对比，如果已验签名信息中没有与该凭证数据信息中的签名信息相同的签名信息，则判定凭证可信，否则判定凭证是重复提交，不可信。
当判定凭证数据信息不可信时，进入步骤s340，业务终端设备直接拒绝用户请求。
当判定凭证数据信息可信时，进入步骤s320。在步骤s320处，对凭证数据信息进行验签操作。该步骤类似于前述步骤s240中的操作，其细节不再赘述。
例如在移动支付的收单场景中，针对用户的购买请求，当业务终端设备接收到交易付款成功凭证之后，可以先查看交易成功凭证中的业务处理时间例如交易时间。如果该交易时间比当前时间早两天，则认为该凭证已过期，并拒绝用户的购买请求；如果该交易时间与当前时间的时间差没有超过两天，则认为该凭证有效，并继续检查业务终端设备内存储的已放行交易签名列表中是否已经存在该凭证中的签名。如果存在，则认为该凭证被重复提交，并拒绝用户的购买请求；如果不存在，则继续执行上述验签操作。
如果验签成功，则进入步骤s330，准予用户请求。
当验签成功后，在步骤s350处，将签名信息与对应的业务唯一标识符、业务处理时间保存或存储在业务终端设备中，以备预验证操作中使用。
优选地，保存时可以对超过诸如两天的时间阈值的签名记录进行自动覆盖，以便回收存储空间。
该存储步骤可以在准予用户请求之前、同时或之后，本申请对此不作任何限制。
如果验签失败，则进入步骤s340，拒绝用户请求。
由此，通过本变型实施例的数据处理方法，可以有效地防止凭证数据信息被重复提交，从而避免凭证数据信息被恶意使用，确保移动业务数据交互过程的安全性。
上述第一实施例和变型实施例中的数据处理方法仅为本申请的优选示例，本申请不限于此，而是还可以进行各种改型。例如，根据需要，业务终端设备与业务服务器之间可以进行定期或不定期的数据交互。具体而言，在移动支付的收单场景中，如果收单服务商有对账需求，可基于业务终端设备中存储的放行过的业务唯一标识符来定期地与支付服务商侧对应设备的收款明细进行对账。根据上面的示例，对账周期必须小于两个自然日，否则业务终端设备中存储的两天前的业务唯一标识符将被覆盖。基于对账结果，可以对已实现支付但未能完成凭证传递获得交易放行的交易进行退款。若觉得最大两个自然日的对账周期太短，需要延长的话，则可以把上述预验证操作中的凭证过期时间、签名记录自动覆盖时间延长，直到满足收单商自身对账周期的需要。不过需要注意的是，延长对账周期将带来签名记录自动覆盖、存储回收周期的延长，从而在业务终端设备上需要更大的存储空间，因此需根据实际需要进行权衡处理。
(第二实施例)
下面结合图4描述根据本申请第二实施例的数据处理方法，其中详细描述的是在客户端侧实施的数据处理方法。
如图4所示，在步骤s410处，客户端可以向业务终端设备发起用户请求。
具体而言，如上面提及的，当用户有数据交互需求例如购买需求时，可以通过用户的客户端向业务终端设备发起用户请求例如购买请求，该购买请求可以包括商品种类、数量等。客户端可以通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式与业务终端设备建立连接，以发起用户请求。
接下来，在步骤s420处，客户端从业务终端设备接收由业务终端设备生成的与用户请求对应的业务数据信息。
具体而言，如上面提及的，响应于客户端的用户请求，业务终端设备可以生成创建数据交互业务所需的业务数据信息，并可以通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式将上述业务数据信息传输给客户端，相应地，客户端通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式接收该业务数据信息。
接下来，在步骤s430处，客户端向业务服务器发送业务处理请求，以请求业务服务器基于上述业务数据信息完成业务处理操作并生成凭证数据信息。
具体而言，在从业务终端设备接收到业务数据信息之后，客户端可以在通过诸如因特网、局域网、广域网等互联网通信方式与业务服务器建立实时连接即在线的情况下，向业务服务器发送业务处理请求，以请求业务服务器基于上述业务数据信息来创建相应的数据交互业务并完成业务数据交互过程，并且之后生成指示业务处理成功的凭证数据信息。
在移动支付的收单场景中，客户端可以在线向业务服务器例如支付服务商提交交易创建申请，申请内容可以包括待支付金额、交易时间、设备唯一标识符等业务数据信息。支付服务商根据客户端的交易创建申请，创建交易并引导客户端完成在线付款，并且生成交易付款成功凭证。
接下来，在步骤s440处，客户端可以从业务服务器接收上述凭证数据信息。所述凭证数据信息是由业务服务器根据业务数据信息完成业务处理操作后生成的，并且凭证数据信息可以是经过业务服务器加签的。
具体而言，客户端可以通过诸如因特网、局域网、广域网等互联网通信方式从业务服务器接收诸如交易付款成功凭证之类的凭证数据信息。该凭证数据信息用于指示业务服务器已经完成相关的业务处理操作。并且该凭证数据信息可以是业务服务器例如根据业务终端设备的公钥或私钥进行了加签操作的。
然后，在步骤s450处，客户端可以将凭证数据信息传输给业务终端设备，以由业务终端设备对凭证数据信息进行验签操作并根据验签操作的结果决定是否准予用户请求。
具体而言，客户端可以通过诸如声波、蓝牙、wifi、nfc之类的近场通信方式将经加签的凭证数据信息传输给业务终端设备。如上面提及的，在业务终端设备接收到经加签的凭证数据信息之后，可以对该经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求。验签操作的具体细节可以参考前面对图2的步骤s240的相关描述，这里不再赘述。
至此描述了根据本申请第二实施例的数据处理方法，其中客户端与业务终端设备之间的通信链路可以为近场通信链路，而客户端与业务服务器之间的通信链路可以为互联网通信链路。在该方法中，可以通过对凭证数据信息的创建、传输和加签-验签处理，使得在业务终端设备离线(即业务终端设备与业务服务器不需要实时连接)的情况下也可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
(第三实施例)
图5示出了根据本申请第三实施例的数据处理方法的步骤流程图，其中详细描述业务服务器侧实施的数据处理方法。
如图5所示，在步骤s510处，业务服务器可以接收来自客户端的业务处理请求，所述业务处理请求包括由业务终端设备根据来自客户端的用户请求生成的业务数据信息。
具体而言，业务服务器可以通过诸如因特网、局域网、广域网等互联网通信方式接收客户端的业务处理请求，该业务处理请求包括前面在图2的步骤s210处描述的业务数据信息。
然后，在步骤s520处，业务服务器根据业务数据信息完成业务处理操作并生成凭证数据信息。
具体而言，响应于该业务处理请求，业务服务器可以基于上述业务数据信息来创建相应的数据交互业务并完成业务数据交互过程，并且之后生成指示业务处理成功的凭证数据信息。
在移动支付的收单场景中，客户端可以在线向业务服务器例如支付服务商提交交易创建申请，申请内容可以包括待支付金额、交易时间、设备唯一标识符等业务数据信息。支付服务商根据客户端的交易创建申请，创建交易并引导客户端完成在线付款，并且生成交易付款成功凭证。
然后，在步骤s530处，业务服务器对凭证数据信息进行加签操作。
在一个实施例中，业务服务器可以根据业务终端设备的公钥对凭证数据信息进行加签操作。在另一个实施例中，业务服务器也可以根据业务终端设备的私钥对凭证数据信息进行加签操作。
经加签的凭证数据信息可以包括例如业务唯一标识符、业务处理时间、业务终端设备唯一标识符等业务处理信息以及根据业务终端设备的公钥对业务处理信息的签名。
在一个具体示例中，例如在移动支付的收单场景下，支付服务商引导支付方客户端完成一笔交易付款后生成一个该笔交易的付款成功凭证，凭证内容可以包括付款方账号、收款方账号、交易唯一标识号、交易时间、交易金额、业务终端设备唯一标识符等交易详细信息以及支付服务商利用业务终端设备即收单设备的对应公钥对交易详细信息的签名。
接下来，在步骤s540处，业务服务器将经加签的凭证数据信息发送给客户端，以由客户端传输给业务终端设备，并由业务终端设备对凭证数据信息进行验签操作且根据验签操作的结果决定是否准予用户请求。
具体而言，业务服务器可以通过诸如因特网、局域网、广域网等互联网通信方式将加签后的上述凭证数据信息发送给客户端。然后，客户端再将经加签的凭证数据信息传输给业务终端设备，以在业务终端设备进行验签通过后准予其用户请求。验签操作的具体细节可以参考前面对图2的步骤s240的相关描述，这里不再赘述。
至此描述了根据本申请第三实施例的数据处理方法，其中基于对凭证数据信息的创建、传输和加签-验签处理，使得业务终端设备在离线状态下可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
<数据处理装置>
与上述数据处理方法类似，本申请实施例还提供了相应的装置。下面结合图6至图8描述根据本申请第四至第六实施例的数据处理装置。
(第四实施例)
图6示出了根据本申请第四实施例的数据处理装置的结构框图，其中描述了业务终端设备侧的数据处理装置600。
如图6所示，该装置600可以包括业务数据生成模块610、业务数据传输模块620、第一凭证数据接收模块630和凭证数据验签模块640。
具体而言，业务数据生成模块610可以用于根据来自客户端的用户请求，生成与用户请求对应的业务数据信息。业务数据传输模块620可以用于将业务数据信息传输给客户端。第一凭证数据接收模块630可以用于接收来自客户端的凭证数据信息，凭证数据信息是由业务服务器根据来自客户端的业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作。凭证数据验签模块640可以用于对经加签的凭证数据信息进行验签操作，并根据验签操作的结果决定是否准予用户请求。
通过本实施例的数据处理装置，基于对凭证数据信息的创建、传输和加签-验签处理，可以使得业务终端设备离线工作，即业务终端设备与业务服务器不需要实时连接，就可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
(第五实施例)
图7示出了根据本申请第五实施例的数据处理装置的结构框图，其中描述了客户端侧的数据处理装置700。
如图7所示，该装置700可以包括用户请求发起模块710、业务数据接收模块720、业务处理请求发送模块730、第二凭证数据接收模块740和凭证数据传输模块750。
具体而言，用户请求发起模块710可以用于向业务终端设备发起用户请求。业务数据接收模块720可以用于从业务终端设备接收由业务终端设备生成的与用户请求对应的业务数据信息。业务处理请求发送模块730可以用于向业务服务器发送业务处理请求，以请求业务服务器基于业务数据信息完成业务处理操作并生成凭证数据信息。第二凭证数据接收模块740可以用于从业务服务器接收凭证数据信息，凭证数据信息是由业务服务器根据业务数据信息完成业务处理操作后生成的，并且凭证数据信息由业务服务器进行了加签操作。凭证数据传输模块750可以用于将凭证数据信息传输给业务终端设备，以由业务终端设备对凭证数据信息进行验签操作并根据验签操作的结果决定是否准予用户请求。
类似地，通过本实施例的数据处理装置，基于对凭证数据信息的创建、传输和加签-验签处理，可以使得业务终端设备离线工作，即业务终端设备与业务服务器不需要实时连接，就可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
(第六实施例)
图8示出了根据本申请第六实施例的数据处理装置的结构框图，其中描述了业务服务器侧的数据处理装置800。
如图8所示，该装置800可以包括业务处理请求接收模块810、凭证数据生成模块820、凭证数据加签模块830和凭证数据发送模块840。
具体而言，业务处理请求接收模块810可以用于接收来自客户端的业务处理请求，业务处理请求包括由业务终端设备根据来自客户端的用户请求生成的业务数据信息。凭证数据生成模块820可以用于根据业务数据信息，完成业务处理操作并生成凭证数据信息。凭证数据加签模块830可以用于对凭证数据信息进行加签操作。凭证数据发送模块840可以用于将经加签的凭证数据信息发送给客户端，以由客户端传输给业务终端设备，并由业务终端设备对凭证数据信息进行验签操作且根据验签操作的结果决定是否准予用户请求。
类似地，通过本实施例的数据处理装置，基于对凭证数据信息的创建、传输和加签-验签处理，可以使得业务终端设备离线工作，即业务终端设备与业务服务器不需要实时连接，就可以完成移动业务数据交互过程。由此大大降低了业务终端设备的维护成本，并提高了移动业务数据交互的成功率。
另外，以上描述的各数据处理装置与之前描述的相应数据处理方法的处理是对应的，因此，关于更详细的技术细节，可以参见之前描述的方法。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。