CN104301293B - 数据处理方法、装置和系统 - Google Patents

Abstract

本申请涉及数据处理方法、装置和系统。该方法包括：接收来自第一客户端的凭证创建请求；根据该请求，创建凭证数据并对凭证数据进行第一加签操作；将经第一加签的凭证数据发送给第一客户端，以由第一客户端对经第一加签的凭证数据进行第二加签操作并将经第一加签和第二加签的凭证数据传输给第二客户端；接收来自第二客户端的凭证处理请求，该请求是第二客户端在接收到来自第一客户端的凭证数据并对该凭证数据进行第一验签操作成功之后发出的；根据凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作；以及向第二客户端发送凭证处理操作的结果信息。由此能增加数据交互的灵活性和方便性，方便用户的使用。

Description

数据处理方法、装置和系统

技术领域

本申请涉及计算机通信领域，尤其涉及互联网数据传输中的数据处理方法、装置和系统。

背景技术

随着互联网的迅猛发展，网上数据交互越来越普遍，当前已经成为人们生活中的主要数据交互方式。

在目前的网上数据交互的数据处理过程中，通常需要交互双方都保持实时在线，即与互联网实时连接，才能完成数据交互过程。由于环境的问题，网络稳定性不高，往往出现网络状况不良的情况，这就会影响网上数据交互的成功率，另外也阻碍了移动业务数据交互和线下业务数据交互的推广和发展，降低了网络状况不良时的用户体验。

因此，需求一种新的数据处理方式，以解决上述网络状况不良的情况下网上数据交互困难甚至无法完成的问题。

发明内容

本申请的主要目的在于提供一种数据处理技术，其能够解决现有技术中的上述问题。

根据本申请一个方面的实施例，提供一种数据处理方法，其特征在于，包括：第一客户端向服务器发送凭证创建请求；第一客户端从服务器接收凭证数据，所述凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；第一客户端对经第一加签的凭证数据进行第二加签操作以得到经第一加签和第二加签的凭证数据；以及第一客户端将所述经第一加签和第二加签的凭证数据传输给第二客户端。

根据本申请一个方面的另一实施例，提供一种数据处理装置，其特征在于，包括：第一请求发送模块，用于第一客户端向服务器发送凭证创建请求；第一加签凭证接收模块，用于第一客户端从服务器接收凭证数据，所述凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；加签模块，用于第一客户端对经第一加签的凭证数据进行第二加签操作以得到经第一加签和第二加签的凭证数据；以及凭证传输模块，用于第一客户端将所述经第一加签和第二加签的凭证数据传输给第二客户端。

根据本申请另一方面的实施例，提供一种数据处理方法，其特征在于，包括：第二客户端接收来自第一客户端的凭证数据，所述凭证数据是由服务器根据来自第一客户端的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；第二客户端对所述凭证数据进行第一验签操作；第一验签操作成功后，第二客户端向服务器发送凭证处理请求，以由服务器对所述凭证数据进行第二验签操作并针对第二验签操作成功后的凭证数据执行凭证处理操作；以及第二客户端接收来自服务器的凭证处理操作的结果信息。

根据本申请另一方面的另一实施例，提供一种数据处理装置，其特征在于，包括：凭证接收模块，用于第二客户端接收来自第一客户端的凭证数据，所述凭证数据是由服务器根据来自第一客户端的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；验签模块，用于第二客户端对所述凭证数据进行第一验签操作；第二请求发送模块，用于第一验签操作成功后，第二客户端向服务器发送凭证处理请求，以由服务器对所述凭证数据进行第二验签操作并针对第二验签操作成功后的凭证数据执行凭证处理操作；以及信息接收模块，用于第二客户端接收来自服务器的凭证处理操作的结果信息。

根据本申请又一方面的实施例，提供一种数据处理方法，其特征在于，包括：接收来自第一客户端的凭证创建请求；根据所述凭证创建请求，创建凭证数据并对凭证数据进行第一加签操作；将经第一加签的凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端；接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的凭证数据并对所述经第一加签和第二加签的凭证数据进行第一验签操作成功之后发出的；根据所述凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作；以及向第二客户端发送凭证处理操作的结果信息。

根据本申请又一方面的另一实施例，提供一种数据处理装置，其特征在于，包括：第一请求接收模块，用于接收来自第一客户端的凭证创建请求；创建和加签模块，用于根据所述凭证创建请求，创建凭证数据并对凭证数据进行第一加签操作；第一加签凭证发送模块，用于将经第一加签的凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端；第二请求接收模块，用于接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的凭证数据并对所述经第一加签和第二加签的凭证数据进行第一验签操作成功之后发出的；验签和处理模块，用于根据所述凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作；以及信息发送模块，用于向第二客户端发送凭证处理操作的结果信息。

根据本申请再一方面的实施例，提供一种数据处理系统，其特征在于，包括：

第一客户端，包括：第一请求发送模块，用于向服务器发送凭证创建请求；第一加签凭证接收模块，用于从服务器接收凭证数据，所述凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；加签模块，用于对经第一加签的凭证数据进行第二加签操作以得到经第一加签和第二加签的凭证数据；以及凭证传输模块，用于将所述经第一加签和第二加签的凭证数据传输给第二客户端；

第二客户端，包括：凭证接收模块，用于接收来自第一客户端的凭证数据，所述凭证数据是由服务器根据来自第一客户端的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；验签模块，用于对所述凭证数据进行第一验签操作；第二请求发送模块，用于在第一验签操作成功后，向服务器发送凭证处理请求，以由服务器对所述凭证数据进行第二验签操作并针对第二验签操作成功后的凭证数据执行凭证处理操作；以及信息接收模块，用于接收来自服务器的凭证处理操作的结果信息；和

服务器，包括：第一请求接收模块，用于接收来自第一客户端的凭证创建请求；创建和加签模块，用于根据所述凭证创建请求，创建凭证数据并对凭证数据进行第一加签操作；第一加签凭证发送模块，用于将经第一加签的凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端；第二请求接收模块，用于接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的凭证数据并对所述经第一加签和第二加签的凭证数据进行第一验签操作成功之后发出的；验签和处理模块，用于根据所述凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作；以及信息发送模块，用于向第二客户端发送凭证处理操作的结果信息。

与现有技术相比，根据本申请的技术方案，能够通过创建、处理和传输凭证数据来实现在用户离线的状况下完成用户之间的数据交互，从而更方便用户之间的交互。在一个典型情形中，能够实现离线支付，即使在用户离线状态下也能够完成支付，从而克服上述网络状况不良的情况下在线支付困难甚至无法完成的问题，减少实际支付中对网络的依赖，方便用户的使用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了根据本申请实施例的数据处理系统的架构示意图；

图2示出了根据本申请一个实施例的数据处理方法的流程图；

图3示出了根据本申请另一实施例的数据处理方法的流程图；

图4示出了根据本申请又一实施例的数据处理方法的流程图；

图5示出了根据本申请一个实施例的数据处理装置的结构示意图；

图6示出了根据本申请另一实施例的数据处理装置的结构示意图；以及

图7示出了根据本申请又一实施例的数据处理装置的结构示意图。

具体实施方式

本申请的主要思想就在于，通过创建、处理和传输凭证数据来实现在用户离线的状况下完成用户之间的数据交互。具体而言，在线创建凭证数据，基于非对称加密机制通过服务器和用户客户端对该凭证数据进行相应的加签和/或验签处理，从而可以基于凭证数据来离线完成用户之间的数据交互。更具体而言，利用创建凭证数据的服务器的私钥对凭证数据进行加签可以确保凭证数据的合法性，而利用请求创建凭证数据的客户端的私钥对凭证数据进行加签，则可以确保凭证数据的防抵赖特性。

在这种借助于非对称加密机制实现的基于凭证数据的数据交互过程中，除了用户本身，还可以通过第三方来基于用户请求服务器创建的凭证数据完成用户之间的数据交互。这样在数据交互过程中就可以做到数据交互完成时不记名、不在线、不需在服务器注册等。另外，可以通过多种方式存储、携带该凭证数据或是将该凭证数据传输给对方用户。此外，使得实际交互中双方用户尽可能地摆脱了对网络的依赖。由此可见，根据本申请的构思，可以增加数据交互的灵活性和方便性，方便用户的使用，增强用户体验。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步地详细说明。

为便于对本申请构思的理解，这里首先结合图1描述根据本申请实施例的数据处理系统的一个典型的应用场景，即网上支付。需要指出的是，本文中将结合该典型应用场景对本申请构思的实施例进行具体描述，但本申请并不限于此，而是可以适用于现有或未来开发的其它任意适合的数据交互场景中。

图1示出了根据本申请实施例的数据处理系统的架构示意图。如图1所示，系统100至少可以包括服务器110、第一客户端120和第二客户端130。

在本实施例的应用场景中，服务器110可以为支付服务商的服务器，其可以是诸如支付宝、财付通、盛付通之类的第三方支付平台的服务器，也可以是网上银行的服务器。第一客户端120和第二客户端130都可以为诸如手机、个人计算机、个人数字助理、便携式设备之类的终端设备。其中，第一客户端120可以为支付方，其为交易创建者，在服务器侧开设有账户。第二客户端130可以为收款方，其为交易发货者，在服务器侧也开设有账户。

第一客户端120可以通过诸如因特网、局域网、广域网等通信网络与服务器110建立连接，在线向服务器110发送凭证创建请求，以申请创建用于离线支付的凭证数据。

响应于第一客户端120的凭证创建请求，服务器110创建用于离线支付的凭证数据并且可以对该凭证数据进行加签操作(第一加签操作)。服务器110在完成对凭证数据的加签操作之后，将加签后的凭证数据通过通信网络发送给第一客户端120。

第一客户端120在接收到来自服务器110的凭证数据后，对该凭证数据再次进行加签操作(第二加签操作)，并将经第一加签和第二加签的凭证数据传输给第二客户端130，或者传输给第三方，然后由第三方传输给第二客户端130。

第二客户端130在接收到来自第一客户端120或第三方的经第一加签和第二加签的凭证数据后，对该凭证数据进行验签操作(第一验签操作)，并将验签成功的凭证数据发送给服务器110以请求收款处理。

服务器110接收来自第二客户端130的凭证数据，并对该凭证数据再次进行验签操作(第二验签操作)，并针对验签成功的凭证数据执行收款处理(凭证处理)，并向第二客户端130反馈收款处理的结果信息。

第二客户端130在接收到收款成功信息之后，对第一客户端120的用户或第三方予以放行。

以上结合图1描述了根据本申请实施例的典型场景下的总体系统架构的工作流程，但本申请并不对此作任何限制。例如，在保证支付方信用状况良好、而不会利用收款方离线无法基于凭证数据实时划账的机会来人为恶意重复使用凭证付款的前提下，还能够实现支付过程中收款方的离线。在此状况下，可以在第二客户端即收款方过一段时间之后在线时，批量完成收款处理，也就是，第二客户端收到凭证数据后即可对第一客户端或第三方予以放行。

根据本申请实施例的数据处理系统，可以在客户端离线、即与服务器断开连接的情况下通过凭证数据实现客户端之间的数据交互。在典型场景中，可以在支付方离线甚至收款方也离线的情况下，即与服务器断开连接的情况下，通过凭证数据完成与收款方之间交易的收款处理。由此可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

下面结合图2至图4更详细地描述该系统架构中的服务器(支付服务商)、第一客户端(支付方)、第二客户端(收款方)中的每一侧的数据处理过程。

图2示出了根据本申请一个实施例的数据处理方法的流程图，其中描述了第一客户端(图1的第一客户端120，支付方)侧的数据处理过程。

在步骤S210处，第一客户端120向服务器110发送凭证创建请求。

具体而言，如上面提及的，第一客户端120可以通过诸如因特网、局域网、广域网等通信网络与服务器110建立连接，在线向服务器110发送凭证创建请求，以申请创建用于离线数据交互的凭证数据。

在一个示例中，第一客户端120的用户可以在线向服务器110申请创建一笔待付款交易，并可以针对这笔待付款交易申请离线支付方式。服务器110响应于第一客户端120的上述凭证创建请求，可以创建针对这笔待付款交易的离线支付凭证数据。

更具体而言，该凭证数据可以包括例如单据号、单据类型、创建时间、付款账号、支付金额、收款账号等，但并不限于此。例如，该凭证数据可以不包括收款账号和/或支付金额，进而可以根据需要实现定向、不定向、定额或不定额支付。在一个具体示例中，该凭证数据例如可以为电子支票数据或其它类似数据。

在另一示例中，第一客户端120的用户可以在线向服务器110直接申请创建电子支票数据以进行离线支付。

接下来，在步骤S220处，第一客户端120从服务器110接收凭证数据，凭证数据由服务器110根据凭证创建请求创建并进行第一加签操作。

具体而言，响应于第一客户端120的凭证创建请求，服务器110在如上述那样创建了用于离线支付的凭证数据之后，可以对该凭证数据进行加签操作，即第一加签操作。在一个具体实施例中，可以根据服务器110的私钥对该凭证数据进行第一加签操作。在另一个具体实施例中，可以根据服务器110的公钥对该凭证数据进行第一加签操作。在一个优选实施例中，服务器110在对凭证数据进行第一加签操作的同时或之后，可以对第一客户端的账户进行相应冻结处理，即从付款账号中冻结相应的申请金额。

这里，通过服务器(支付服务商)的私钥或公钥对凭证数据进行加签操作，可以确保凭证数据的合法性。

在步骤S230处，第一客户端120对经第一加签的凭证数据进行第二加签操作以得到经第一加签和第二加签的凭证数据。

具体而言，第一客户端120在接收到来自服务器110的凭证数据后，对该凭证数据再次进行加签操作，即第二加签操作。在一个具体实施例中，可以根据第一客户端120的私钥对凭证数据进行第二加签操作，该第一客户端120的私钥是由服务器110预先为其创建的一组专属的非对称密钥即私钥-公钥对中的私钥。在另一个具体实施例中，可以根据第一客户端120的公钥对凭证数据进行第二加签操作，该第一客户端120的公钥是由服务器110预先为其创建的一组专属的非对称密钥即私钥-公钥对中的公钥。

这里，通过第一客户端(支付方)的私钥或公钥对凭证数据进行加签操作，可以确保凭证数据的防抵赖特性。

然后，在步骤S240处，第一客户端120将经第一加签和第二加签的凭证数据传输给第二客户端130。

具体而言，第一客户端120可以将经第一加签和第二加签的凭证数据以任意合适方式传输给第二客户端130。根据本申请的实施例，可以通过诸如二维码、声波、蓝牙、wifi等中的任意一种或多种方式来进行传输。

在一个示例中，第一客户端120可以通过第三方(如图1的虚线框所示)将经第一加签和第二加签的凭证数据传输给第二客户端130。具体而言，第一客户端120可以通过任意合适方式将经第一加签和第二加签的凭证数据传输给第三方，然后由第三方再将经第一加签和第二加签的凭证数据通过任意合适方式传输给第二客户端130。该第三方例如可以为第一客户端120的用户之外的任意方，其可以在服务器侧没有开设账户，也可以在服务器侧开设有账户。

在另一个示例中，第一客户端120可以直接将经第一加签和第二加签的凭证数据通过任意合适方式传输给第二客户端130，而不通过第三方。

另外，根据本申请的实施例，在网上支付场景中，在凭证数据初始创建时不包括支付金额的情况下，即不定额支付时，可以在向收款方提供凭证数据时输入或给定一个需要实际支付的金额，该金额通常不可大于不定额凭证申请中设定的最大金额值。

以上结合图2描述了第一客户端(支付方)侧的数据处理过程。在该数据处理过程中，第一客户端只需要在线申请创建离线数据交互的凭证数据，即可实现即使在离线状态下也能够基于该凭证数据与第二客户端进行数据交互。在典型场景中，支付方只需要在线申请创建离线支付的凭证数据，即可实现即使在离线状态下也能够基于该凭证数据与收款方进行交易的支付。可见，根据本实施例的数据处理方法，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

下面结合图3描述第二客户端(图1的第二客户端130，收款方)侧的数据处理过程。

如图3所示，在步骤S310处，第二客户端130接收来自第一客户端120的凭证数据(参见图1)，所述凭证数据是由服务器110根据来自第一客户端120的凭证创建请求创建并经过服务器110的第一加签操作和第一客户端120的第二加签操作。

具体而言，第二客户端130可以通过任意合适方式来接收来自第一客户端120的凭证数据。根据本申请的实施例，可以通过诸如二维码、声波、蓝牙、wifi等中的任意一种或多种方式进行接收。在一种优选情形中，第二客户端130可以在第一客户端120离线的情况下，也就是第一客户端120与服务器110断开网络连接的情况下，接收来自第一客户端120的凭证数据。

如上面提及的，该凭证数据可以包括例如单据号、单据类型、创建时间、付款账号、支付金额、收款账号等，但并不限于此。例如，该凭证数据可以不包括收款账号和/或支付金额，进而可以根据需要实现定向、不定向、定额或不定额支付。在一个具体示例中，该凭证数据例如可以为电子支票数据或其它类似数据。

在一个具体实施例中，第二客户端130接收到的凭证数据可以是经过服务器110根据服务器110的私钥或公钥加签并经过第一客户端120根据第一客户端120的私钥或公钥加签的。

接下来，在步骤S320处，第二客户端130对接收到的凭证数据进行第一验签操作。

具体而言，第二客户端130根据服务器110的公钥或私钥对上述接收到的凭证数据进行第一验签操作。在一个具体实施例中，如果接收到的凭证数据是经过服务器110根据服务器110的私钥加签的，则第二客户端130根据服务器110的公钥进行第一验签操作。在另一个具体实施例中，如果接收到的凭证数据是经过服务器110根据服务器110的公钥加签的，则第二客户端130根据服务器110的私钥进行第一验签操作。

第一验签操作成功后，在步骤S320处，第二客户端130向服务器110发送凭证处理请求，以由服务器110对所述凭证数据进行第二验签操作并针对第二验签操作成功后的凭证数据执行凭证处理操作。

具体而言，第二客户端130可以通过诸如因特网、局域网、广域网等通信网络与服务器110建立连接，在线将第一验签成功的凭证数据发送给服务器110，并请求服务器110执行凭证处理操作。服务器110在接收到该凭证处理请求之后，先对凭证数据进行验签操作(第二验签操作)，然后针对验签成功的凭证数据执行凭证处理操作。

在本申请的实施例中，凭证处理操作可以包括收款操作，其中根据例如电子支票之类的凭证数据中包括的付款账号、支付金额等信息，执行从付款账号到收款账号的资金划转操作。

接下来，在步骤S330处，第二客户端130接收来自服务器110的凭证处理操作的结果信息。

具体而言，服务器110响应于第二客户端130的凭证处理请求，可以向第二客户端130反馈凭证处理操作的结果信息。更具体而言，当凭证数据验签成功并且凭证处理操作执行成功时，第二客户端130可以接收到凭证处理操作成功的信息。当凭证数据验签失败和/或凭证处理操作执行失败时，第二客户端130可以接收到凭证处理操作失败的信息。

在一个示例场景中，当服务器对离线支付凭证数据验签成功并且收款操作执行成功时，可以向收款方发送收款成功的通知。收款方收到收款成功的通知后，可以对交易的支付方或第三方予以放行。

以上结合图3描述了第二客户端(收款方)侧的数据处理过程。在该数据处理过程中，第二客户端可以在第一客户端离线的情况下，即第一客户端与服务器断开网络连接的情况下，基于凭证数据向服务器申请完成与第一客户端的数据交互。在典型场景中，收款方可以在支付方离线的状态下基于离线支付凭证数据向服务器请求执行收款操作。可见，根据本实施例的数据处理方法，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

下面结合图4描述服务器(图1的服务器110，支付服务商)侧的数据处理过程。

如图4所示，在步骤S410处，接收来自第一客户端120的凭证创建请求(参见图1)。

具体而言，如上面提及的，服务器110可以经由与第一客户端120之间的诸如因特网、局域网、广域网等的网络连接，接收来自第一客户端120的凭证创建请求。

接下来，在步骤S420处，根据所述凭证创建请求，创建凭证数据并对凭证数据进行第一加签操作。

在一个示例中，当第一客户端120的用户在线向服务器110申请创建一笔待付款交易，并针对这笔待付款交易申请离线支付方式时，服务器110可以响应于第一客户端120的上述凭证创建请求，创建该交易并产生针对这笔待付款交易的离线支付凭证数据。

更具体而言，该凭证数据可以包括例如单据号、单据类型、创建时间、付款账号、支付金额、收款账号等，但并不限于此。例如，该凭证数据可以不包括收款账号和/或支付金额，进而可以根据需要实现定向、不定向、定额或不定额支付。在一个具体示例中，该凭证数据例如可以为电子支票数据或其它类似数据。

在另一示例中，当第一客户端120的用户在线向服务器110直接申请创建电子支票数据时，服务器110可以据此直接创建电子支票数据以由用户在各种离线支付场景中使用。

在创建了凭证数据之后，服务器110对该凭证数据进行加签操作(第一加签操作)。根据本申请的实施例，服务器110可以根据服务器的私钥或公钥对该凭证数据进行加签。更优选地，服务器110在对凭证数据进行第一加签操作的同时或之后，可以对第一客户端120的账户进行相应冻结处理，即从付款账号中冻结相应的申请金额。

接下来，在步骤S430处，将经第一加签的凭证数据发送给第一客户端120，以由第一客户端120对所述经第一加签的凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端130。

具体而言，服务器110通过与第一客户端120之间的网络连接，将经第一加签的凭证数据发送给第一客户端120。

如上面提及的，第一客户端120在接收到来自服务器110的经第一加签的凭证数据后，可以根据第一客户端120的私钥或公钥对所述经第一加签的凭证数据再次进行加签操作(第二加签操作)并将所述经第一加签和第二加签的凭证数据以任意合适方式传输给第二客户端130。

然后，在步骤S440处，接收来自第二客户端130的凭证处理请求，所述凭证处理请求是第二客户端130在接收到来自第一客户端120的经第一加签和第二加签的凭证数据并对所述经第一加签和第二加签的凭证数据进行第一验签操作成功之后发出的。

具体而言，第二客户端130在根据服务器的公钥或私钥对来自第一客户端120的经第一加签和第二加签的凭证数据进行验签操作成功之后，与服务器110建立网络连接，在线向服务器110发出凭证处理请求，因而服务器110相应地接收该请求。

接下来，在步骤S450处，根据所述凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作。

具体而言，服务器110根据第一客户端120的公钥或私钥对凭证数据进行验签操作(第二验签操作)以确定凭证数据的合法性。如果验签成功，则继续执行凭证处理操作；如果验签失败，则向第二客户端130反馈验签失败的结果信息。

在一个示例中，凭证处理操作可以包括收款操作，其中根据例如电子支票之类的凭证数据中包括的付款账号、支付金额、收款账号等信息，执行从付款账号到收款账号的资金划转操作。在一个具体实施例中，如果凭证数据中不包括收款账号，则根据凭证数据的上传方确定收款方和收款账户。在一个具体实施例中，如果在第一客户端申请创建离线支付凭证数据时，服务器110在对凭证数据进行第一加签操作的同时或之后，对第一客户端120的账户进行了相应冻结处理，则服务器110在对来自第二客户端130的凭证数据验签成功后，对冻结的支付方账户的资金进行解冻，并将资金划转到收款方账户。

接下来，在步骤S460处，向第二客户端130发送凭证处理操作的结果信息。

如果服务器110针对凭证数据验签成功并且凭证处理操作也执行成功，则通知第二客户端130操作成功。如果服务器110针对凭证数据验签失败和/或凭证处理操作执行失败，则通知第二客户端130操作失败。

之后，第二客户端130根据凭证处理操作的结果信息，可以确定是否对第一客户端120或第三方予以放行。

以上结合图4描述了服务器(支付服务商)侧的数据处理过程。在该数据处理过程中，服务器可以创建凭证数据并使得在第一客户端离线即与服务器断开网络连接的情况下基于凭证数据完成第一客户端与第二客户端之间的数据交互。在典型场景中，服务器可以在支付方离线的状态下基于来自收款方的离线支付凭证数据执行收款操作。可见，根据本实施例的数据处理方法，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

至此已经结合图2至图4描述了根据本申请实施例的数据处理方法，上述实施例仅为本申请的优选示例，本申请不限于此，而是还可以进行各种改型。例如，在本申请的其它实施例中，在保证支付方信用状况良好、而不会利用收款方离线无法基于凭证数据实时划账的机会来人为恶意重复使用凭证付款的前提下，还能够实现支付过程中收款方的离线。在此状况下，可以在第二客户端即收款方过一段时间之后在线时，批量完成收款处理，也就是，第二客户端收到凭证数据后即可对第一客户端或第三方予以放行。

与上述数据处理方法类似，本申请实施例还提供了相应的装置。

图5示出了根据本申请一个实施例的数据处理装置的结构示意图，其中描述了第一客户端(支付方)侧的数据处理装置500。

如图5所示，该装置500可以包括第一请求发送模块510、第一加签凭证接收模块520、加签模块530和凭证传输模块540。

具体而言，第一请求发送模块510可以用于向服务器发送凭证创建请求。第一加签凭证接收模块520可以用于从服务器接收凭证数据，所述凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作。加签模块530可以用于对经第一加签的凭证数据进行第二加签操作以得到经第一加签和第二加签的凭证数据。凭证传输模块540可以用于将所述经第一加签和第二加签的凭证数据传输给第二客户端。

通过本实施例的数据处理装置，第一客户端只需要在线申请创建离线数据交互的凭证数据，即可实现即使在离线状态下也能够基于该凭证数据与第二客户端进行数据交互。在典型场景中，支付方只需要在线申请创建离线支付的凭证数据，即可实现即使在离线状态下也能够基于该凭证数据与收款方进行交易的支付。可见，根据本实施例的数据处理装置，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

图6示出了根据本申请另一实施例的数据处理装置的结构示意图，其中描述了第二客户端(收款方)侧的数据处理装置600。

如图6所示，该装置600可以包括凭证接收模块610、验签模块620、第二请求发送模块630和信息接收模块640。

具体而言，凭证接收模块610可以用于接收来自第一客户端的凭证数据，所述凭证数据是由服务器根据来自第一客户端的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作。验签模块620可以用于对所述凭证数据进行第一验签操作。第二请求发送模块630可以用于在第一验签操作成功后，向服务器发送凭证处理请求，以由服务器对所述凭证数据进行第二验签操作并针对第二验签操作成功后的凭证数据执行凭证处理操作。信息接收模块640可以用于接收来自服务器的凭证处理操作的结果信息。

通过本实施例的数据处理装置，第二客户端可以在第一客户端离线的情况下，即第一客户端与服务器断开网络连接的情况下，基于凭证数据向服务器申请完成与第一客户端的数据交互。在典型场景中，收款方可以在支付方离线的状态下基于离线支付凭证数据向服务器请求执行收款操作。可见，根据本实施例的数据处理方法，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

图7示出了根据本申请又一实施例的数据处理装置的结构示意图，其中描述了服务器(支付服务商)侧的数据处理装置700。

如图7所示，该装置700可以包括第一请求接收模块710、创建和加签模块720、第一加签凭证发送模块730、第二请求接收模块740、验签和处理模块750和信息发送模块760。

具体而言，第一请求接收模块710可以用于接收来自第一客户端的凭证创建请求。创建和加签模块720可以用于根据所述凭证创建请求，创建凭证数据并对凭证数据进行第一加签操作。第一加签凭证发送模块730可以用于将经第一加签的凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端。第二请求接收模块740可以用于接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的凭证数据并对所述经第一加签和第二加签的凭证数据进行第一验签操作成功之后发出的。验签和处理模块750可以用于根据所述凭证处理请求，对凭证数据进行第二验签操作并针对第二验签操作成功的凭证数据进行凭证处理操作。信息发送模块760可以用于向第二客户端发送凭证处理操作的结果信息。

通过本实施例的数据处理装置，服务器可以创建凭证数据并使得在第一客户端离线即与服务器断开网络连接的情况下基于凭证数据完成第一客户端与第二客户端之间的数据交互。在典型场景中，服务器可以在支付方离线的状态下基于来自收款方的离线支付凭证数据执行收款操作。可见，根据本实施例的数据处理方法，可以增加数据交互(网上支付)的灵活性和方便性，方便用户的使用，增强用户体验。

另外，以上描述的各数据处理装置与之前描述的相应数据处理方法的处理是对应的，因此，关于更详细的技术细节，可以参见之前描述的方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

以上所述仅为本申请的实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

1.一种数据处理方法，其特征在于，包括：

第一客户端向服务器发送凭证创建请求，以申请创建离线数据交互凭证数据；

第一客户端从服务器接收离线数据交互凭证数据，所述离线数据交互凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；

第一客户端对经第一加签的离线数据交互凭证数据进行第二加签操作以得到经第一加签和第二加签的离线数据交互凭证数据；以及

第一客户端将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换。

2.根据权利要求1所述的方法，其特征在于，所述第一加签操作是由服务器根据服务器的私钥进行的。

3.根据权利要求1所述的方法，其特征在于，所述第二加签操作是由第一客户端根据第一客户端的私钥进行的。

4.根据权利要求1所述的方法，其特征在于，第一客户端通过第三方将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端。

5.根据权利要求1-4中任一项所述的方法，其特征在于，通过包括二维码、声波、蓝牙、wifi中的任意一种或多种方式，将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端。

6.一种数据处理方法，其特征在于，包括：

第二客户端接收来自第一客户端的离线数据交互凭证数据，所述离线数据交互凭证数据是由服务器根据来自第一客户端的用于申请创建离线数据交互凭证数据的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；

第二客户端对所述离线数据交互凭证数据进行第一验签操作；

第一验签操作成功后，第二客户端向服务器发送凭证处理请求，以由服务器对所述离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功后的离线数据交互凭证数据执行凭证处理操作；以及

第二客户端接收来自服务器的凭证处理操作的结果信息。

7.根据权利要求6所述的方法，其特征在于，所述第一加签操作是由服务器根据服务器的私钥进行的，且所述第一验签操作是由第二客户端根据服务器的公钥进行的。

8.根据权利要求6所述的方法，其特征在于，所述第二加签操作是由第一客户端根据第一客户端的私钥进行的，且所述第二验签操作是由服务器根据第一客户端的公钥进行的。

9.根据权利要求6-8中任一项所述的方法，其特征在于，第二客户端通过包括二维码、声波、蓝牙、wifi中的任意一种或多种方式接收来自第一客户端的离线数据交互凭证数据。

10.一种数据处理方法，其特征在于，包括：

接收来自第一客户端的凭证创建请求，以申请创建离线数据交互凭证数据；

根据所述凭证创建请求，创建离线数据交互凭证数据并对离线数据交互凭证数据进行第一加签操作；

将经第一加签的离线数据交互凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的离线数据交互凭证数据进行第二加签操作并将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换；

接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的离线数据交互凭证数据并对所述经第一加签和第二加签的离线数据交互凭证数据进行第一验签操作成功之后发出的；

根据所述凭证处理请求，对离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功的离线数据交互凭证数据进行凭证处理操作；以及

向第二客户端发送凭证处理操作的结果信息。

11.根据权利要求10所述的方法，其特征在于，所述第一加签操作是由服务器根据服务器的私钥进行的，且所述第一验签操作是由第二客户端根据服务器的公钥进行的。

12.根据权利要求10所述的方法，其特征在于，所述第二加签操作是由第一客户端根据第一客户端的私钥进行的，且所述第二验签操作是由服务器根据第一客户端的公钥进行的。

13.一种数据处理装置，其特征在于，包括：

第一请求发送模块，用于第一客户端向服务器发送凭证创建请求，以申请创建离线数据交互凭证数据；

第一加签凭证接收模块，用于第一客户端从服务器接收离线数据交互凭证数据，所述离线数据交互凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；

加签模块，用于第一客户端对经第一加签的离线数据交互凭证数据进行第二加签操作以得到经第一加签和第二加签的离线数据交互凭证数据；以及

凭证传输模块，用于第一客户端将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换。

14.一种数据处理装置，其特征在于，包括：

凭证接收模块，用于第二客户端接收来自第一客户端的离线数据交互凭证数据，所述离线数据交互凭证数据是由服务器根据来自第一客户端的用于申请创建离线数据交互凭证数据的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；

验签模块，用于第二客户端对所述离线数据交互凭证数据进行第一验签操作；

第二请求发送模块，用于第一验签操作成功后，第二客户端向服务器发送凭证处理请求，以由服务器对所述离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功后的离线数据交互凭证数据执行凭证处理操作；以及

信息接收模块，用于第二客户端接收来自服务器的凭证处理操作的结果信息。

15.一种数据处理装置，其特征在于，包括：

第一请求接收模块，用于接收来自第一客户端的凭证创建请求，以申请创建离线数据交互凭证数据；

创建和加签模块，用于根据所述凭证创建请求，创建离线数据交互凭证数据并对离线数据交互凭证数据进行第一加签操作；

第一加签凭证发送模块，用于将经第一加签的离线数据交互凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的离线数据交互凭证数据进行第二加签操作并将所述经第一加签和第二加签的凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换；

第二请求接收模块，用于接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的离线数据交互凭证数据并对所述经第一加签和第二加签的离线数据交互凭证数据进行第一验签操作成功之后发出的；

验签和处理模块，用于根据所述凭证处理请求，对离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功的离线数据交互凭证数据进行凭证处理操作；以及

信息发送模块，用于向第二客户端发送凭证处理操作的结果信息。

16.一种数据处理系统，其特征在于，包括：

第一客户端，包括：

第一请求发送模块，用于向服务器发送凭证创建请求，以申请创建离线数据交互凭证数据；

第一加签凭证接收模块，用于从服务器接收离线数据交互凭证数据，所述离线数据交互凭证数据由服务器根据所述凭证创建请求创建并进行第一加签操作；

加签模块，用于对经第一加签的离线数据交互凭证数据进行第二加签操作以得到经第一加签和第二加签的离线数据交互凭证数据；以及

凭证传输模块，用于将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换；

第二客户端，包括：

凭证接收模块，用于接收来自第一客户端的离线数据交互凭证数据，所述离线数据交互凭证数据是由服务器根据来自第一客户端的用于申请创建离线数据交互凭证数据的凭证创建请求创建并经过服务器的第一加签操作和第一客户端的第二加签操作；

验签模块，用于对所述离线数据交互凭证数据进行第一验签操作；

第二请求发送模块，用于在第一验签操作成功后，向服务器发送凭证处理请求，以由服务器对所述离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功后的离线数据交互凭证数据执行凭证处理操作；以及

信息接收模块，用于接收来自服务器的凭证处理操作的结果信息；和

服务器，包括：

第一请求接收模块，用于接收来自第一客户端的凭证创建请求，以申请创建离线数据交互凭证数据；

创建和加签模块，用于根据所述凭证创建请求，创建离线数据交互凭证数据并对离线数据交互凭证数据进行第一加签操作；

第一加签凭证发送模块，用于将经第一加签的离线数据交互凭证数据发送给第一客户端，以由第一客户端对所述经第一加签的离线数据交互凭证数据进行第二加签操作并将所述经第一加签和第二加签的离线数据交互凭证数据传输给第二客户端，以使第二客户端根据所述离线数据交互凭证数据与第一客户端进行相应的数据交换；

第二请求接收模块，用于接收来自第二客户端的凭证处理请求，所述凭证处理请求是第二客户端在接收到来自第一客户端的经第一加签和第二加签的离线数据交互凭证数据并对所述经第一加签和第二加签的离线数据交互凭证数据进行第一验签操作成功之后发出的；

验签和处理模块，用于根据所述凭证处理请求，对离线数据交互凭证数据进行第二验签操作并针对第二验签操作成功的离线数据交互凭证数据进行凭证处理操作；以及

信息发送模块，用于向第二客户端发送凭证处理操作的结果信息。