CN108470279B - 电子票的转让及验证方法、客户端、服务器、票务系统 - Google Patents

Abstract

本发明公开了一种电子票的转让方法及验证方法、客户端、服务器、票务系统。该电子票的转让方法实现第一用户所持有的目标电子票转让给第二用户，由第一用户对应的客户端实施，包括：获取第二用户的身份验证数据；根据本地存储的第一用户的身份验证数据、获取的第二用户的身份验证数据，对本地存储的目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据；将目标票据数据以及对应的转让授权数据，提供给第二用户，以实施目标电子票的转让。根据本发明，实现电子票的线下转让，同时确保转让电子票的安全性。提升用户的电子票使用体验。

Description

电子票的转让及验证方法、客户端、服务器、票务系统

技术领域

本发明涉及电子票务技术领域，更具体地，涉及一种电子票的转让及验证方法、客户端、服务器、票务系统。

背景技术

用户使用提供在线购票服务的票务应用(例如安装于手机上的购票APP)，可以通过互联网购买观看演出、电影、体育赛事的座位，获取对应的电子票就能完成购票，极大方便日常生活。

这类电子票，通常是由票务应用，根据用户的购票数据，生成对应的二维码图像作为电子票，发送给用户保存，用户可以通过展示二维码图像完成兑换、验票等环节。但是，目前这类电子票在转让时，通常需要通过服务器在线将转让者的电子票(原二维码图像)作废、重新生成新的电子票(新二维码图像)下发给受让者，因此，电子票只能在线上流通，无法实现线下流通。

发明内容

本发明的一个目的是提供一种用于电子票的转让的新技术方案。

根据本发明的第一方面，提供了一种电子票的转让方法，实现第一用户所持有的目标电子票转让给第二用户，由所述第一用户对应的客户端实施，包括：

获取所述第二用户的身份验证数据；

根据本地存储的所述第一用户的身份验证数据、获取的所述第二用户的身份验证数据，对本地存储的所述目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据；

将所述目标票据数据以及对应的转让授权数据，提供给所述第二用户，以实施所述目标电子票的转让。

可选地，所述身份验证数据至少包括对应用户的用户公钥；

所述生成对应的转让授权数据的步骤包括：

使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理，生成对应的转让签名数据；

根据所述第一用户的用户公钥以及所述转让签名数据，生成对应的转让授权数据。

可选地，所述生成对应的转让授权数据的步骤包括：

对所述第二用户的用户公钥进行哈希计算，得到对应的第二用户哈希值；

对所述目标票据数据进行哈希计算，得到对应的目标票据哈希值；

使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户哈希值和目标票据哈希值进行数字签名处理，得到对应的转让签名数据。

可选地，所述第二用户的身份验证数据中还包括第二用户的身份签名数据；

所述第二用户的身份签名数据，是使用与所述第二用户的用户公钥对应的用户私钥对所述第二用户的用户公钥，进行数字签名处理得到的数据；

所述方法还包括：

使用所述第二用户的用户公钥，对所述第二用户的身份签名数据验证通过后，才执行所述生成对应的转让授权数据的步骤。

可选地，

所述获取第二用户的身份验证数据的步骤包括：

扫描包含所述第二用户的身份验证数据的二维码图像，获取所述第二用户的身份验证数据；或者，通过近距离通信方式，接收所述第二用户发送的身份验证数据；

和/或，

将所述目标票据数据以及对应的转让授权数据，提供给所述第二用户的步骤包括：

根据所述目标票据数据以及对应的转让授权数据，生成对应的二维码图像以供所述第二用户扫描获取；或者，通过近距离通信方式，将所述目标票据数据以及对应的转让授权数据，发送给所述第二用户。

根据本发明的第二方面，提供一种电子票的转让方法，实现第一用户所持有的目标电子票转让给第二用户，由所述第二用户对应的客户端实施，包括：

向所述第一用户提供本地存储的所述第二用户的身份验证数据；

通过所述第一用户获取目标票据数据以及对应的转让授权数据；

其中，所述目标票据数据与所述目标电子票对应，所述转让授权数据根据本发明的第一方面提供的电子票的转让方法生成；

从所述转让授权数据中获取所述第一用户的身份验证数据，

根据所述第一用户的身份验证数据以及所述第二用户的身份验证数据，对所述转让授权数据进行验证，在验证通过后确定所述目标电子票转让成功。

可选地，所述身份验证数据中至少包括对应用户的用户公钥；

所述转让授权数据中包括所述第一用户的用户公钥以及转让签名数据；

所述转让签名数据，是使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理得到的数据；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥，对所述转让签名数据中包括的所述第二用户的用户公钥进行验证，验证通过后确定所述目标电子票转让成功。

可选地，所述转让签名数据是使用与所述第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；所述第二用户哈希值是对所述第二用户的用户公钥进行哈希计算得到的数值；所述目标票据哈希值是对所述目标票据数据进行哈希计算得到的数值；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥通过哈希计算得到的哈希值，对所述转让签名数据中包括的所述第二用户哈希值进行验证，验证通过后确定所述目标电子票转让成功。

可选地，所述第二用户的身份验证数据中还包括第二用户的身份签名数据；

所述方法还包括：

使用与所述第二用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥进行数字签名处理，得到所述第二用户的身份签名数据。

可选地，

所述提供所述第二用户的身份验证数据的步骤包括：

根据本地存储的第二用户的身份验证数据生成对应的二维码图像，以供所述第一用户扫描获取，或者，通过近距离通信方式，向所述第一用户发送所述第二用户的身份验证数据；

和/或，

所述获取目标票据数据以及对应的转让授权数据的步骤包括：

扫描包含所述目标票据数据以及所述转让授权数据的二维码图像，获取所述目标票据数据以及转让授权数据，或者，通过近距离通信方式，接收所述第一用户发送的目标票据数据以及所述转让授权数据。

本发明另一个目的是提供一种用于电子票的验证的新技术方案。

根据本发明的第三方面，提供一种电子票的验证方法，用于验证第一用户转让给第二用户的目标电子票，通过服务器实施，包括：

接收第二用户发送的验票请求；

其中，所述验票请求中至少包括与所述目标电子票对应的目标票据数据以及对应的转让授权数据；所述目标票据数据以及所述转让授权数据，由所述第一用户根据权利要求1-5任意一项所述的方法提供给所述第二用户；

对所述目标票据数据进行验证，以及根据本地存储的第一用户的身份验证数据、第二用户的身份验证数据对所述转让授权数据进行验证，在所述目标票据数据、所述转让授权数据均验证通过后，确定所述目标电子票验证通过。

可选地，所述身份验证数据中包括对应用户的用户公钥；

所述转让授权数据中包括所述第一用户的用户公钥以及转让签名数据；

所述转让签名数据，是使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理得到的数据；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥，对所述转让签名数据中包括的所述第二用户的用户公钥进行验证，验证通过后确定所述转让授权数据验证通过。

可选地，所述转让签名数据是使用与所述第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；所述第二用户哈希值是对所述第二用户的用户公钥进行哈希计算得到的数值；所述目标票据哈希值是对所述目标票据数据进行哈希计算得到的数值；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥通过哈希计算得到的哈希值，对所述转让签名数据中包括的所述第二用户哈希值进行验证，验证通过后确定所述转让授权数据验证通过。

根据本发明的第五方面，提供一种客户端，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述客户端，执行如本发明的第一方面提供的任意一项的电子票转让方法。

根据本发明的第六方面，提供一种客户端，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述客户端，执行如本发明的第二方面提供的任意一项的电子票转让方法。

根据本发明的第七方面，提供一种服务器，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述客户端，执行如本发明的第三方面提供的任意一项的电子票验证方法。

根据本发明的第八方面，提供一种票务系统，其中，包括：

本发明的第五方面提供的客户端；

本发明的第六方面提供的客户端；

本发明的第七方面提供的服务器。

根据本公开的一个实施例，提供一种电子票的转让方法以及客户端，通过与持有目标电子票的第一用户对应的客户端，获取受让目标电子票的第二用户的身份验证数据，根据转让双方的身份验证数据对目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据，并将目标票据数据以及转让授权数据提供给第二用户，完成目标电子票的转让，无需通过线上服务器处理，实现电子票的线下流通，同时确保电子票转让的安全性。提升用户的电子票使用体验。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

被结合在说明书中并构成说明书的一部分的附图示出了本发明的实施例，并且连同其说明一起用于解释本发明的原理。

图1是显示可用于实现本发明的实施例的系统1000的硬件配置的例子的框图。

图2示出了本发明第一实施例的电子票的转让方法的流程图。

图3示出了本发明第一实施例的生成转让授权数据步骤的流程图。

图4示出了本发明第一实施例的生成转让签名数据步骤的流程图。

图5示出了本发明第一实施例的客户端的框图。

图6示出了本发明第二实施例的电子票的转让方法的流程图。

图7示出了本发明第二实施例的验证转让授权数据步骤的流程图。

图8示出了本发明第二实施例的客户端的框图。

图9示出了本发明第三实施例的电子票的验证方法的流程图。

图10示出了本发明第三实施例的验证转让授权数据步骤的流程图。

图11示出了本发明第三实施例的服务器的框图。

图12示出了本发明第四实施例的票务系统的框图。

图13示出了本发明第四实施例的电子票的线下流通方法的例子的示意图。

具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

在这里示出和讨论的所有例子中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它例子可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

此外，应当理解的是，下文的“第一”、“第二”仅是为了便于理解所做的名词限定，并不代表对顺序、数值、时间先后的限制。

<硬件配置>

如图1所示，系统1000包括服务器1100、客户端1200以及网络1300。

服务器1100例如可以是刀片服务器等。在一个例子中，服务器1100可以是一台计算机。在在另一个例子中，服务器1100可以如图1所示，包括处理器1110、存储器1120、接口装置1130、通信装置1140、显示装置1150、输入装置1160。尽管服务器也可以包括扬声器、麦克风等等，但是，这些部件与本发明无关，故在此省略。其中，处理器1110例如可以是中央处理器CPU、微处理器MCU等。存储器1120例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置1130例如包括USB接口、串行接口等。通信装置1140例如能够进行有线或无线通信。显示装置1150例如是液晶显示屏。输入装置1160例如可以包括触摸屏、键盘等。

客户端1200可以是便携式电脑(1200-1)、台式计算机(1200-2)、手机(1200-3)、平板电脑(1200-4)等。如图1所示，客户端1200可以包括处理器1210、存储器1220、接口装置1230、通信装置1240、显示装置1250、输入装置1260、扬声器1270、麦克风1280，等等。其中，处理器1210可以是中央处理器CPU、微处理器MCU等。存储器1220例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置1230例如包括USB接口、耳机接口等。通信装置1240例如能够进行有线或无线通信。显示装置1250例如是液晶显示屏、触摸显示屏等。输入装置1260例如可以包括触摸屏、键盘等。用户可以通过扬声器1270和麦克风1280输入/输出语音信息。

通信网络1300可以是无线网络也可以网络，可以是局域网也可以是广域网。在图1所示的配置环境1000中，客户端1200-1、1200-2、1200-3、1200-4以及服务器1100可以通过通信网络1300进行通信。

图1所示的配置环境1100仅是解释性的，并且决不是为了要限制本发明、其应用或用途。应用于本发明的实施例中，服务器1100的所述存储器1120用于存储指令，所述指令用于控制所述处理器1110进行操作以执行本发明实施例提供的任意一项电子票的验证方法。

此外，客户端1200的所述存储器1220用于存储指令，所述指令用于控制所述处理器1210进行操作以执行本发明实施例提供的任意一项电子票的转让方法。

本领域技术人员应当理解，尽管在图1中对服务器1100以及客户端1200都示出了多个装置，但是，本发明可以仅涉及其中的部分装置，例如，服务器1100只涉及处理器1110和存储装置1120，或者客户端1200只涉及处理器1210和存储装置1220等。技术人员可以根据本发明所公开方案设计指令。指令如何控制处理器进行操作，这是本领域公知，故在此不再详细描述。

<第一实施例>

在本实施例中，提供一种电子票的转让方法，实现第一用户所持有的目标电子票转让给第二用户，由第一用户对应的客户端实施。

目标电子票由第一用户持有，可以是第一用户通过购买、兑换、转让等途径得到的提供对应票务服务的票据的电子形式，例如，该目标电子票可以是二维码图像形式。

该客户端与第一用户对应，可以是由第一用户持有、登录或者使用的客户端。该客户端可以是手机、平板、掌上电脑、平板电脑、台式计算机等电子设备。例如，可以如图1所示的客户端1200。在一个例子中，该客户端可以是安装有票务应用的手机。

该电子票转让方法，如图2所示，包括：步骤S2100-S2300。

步骤S2100，获取第二用户的身份验证数据。

在本实施例中，用户的身份验证数据是用于验证对应用户的身份的数据。例如，可以是用于标识该第二用户的用户身份标识、用户账户名称等。

在实际应用中，用户的身份验证数据仅包括用户身份标识等简单数据时，会带来易于被恶意冒用身份的风险。

因此，在一个例子中，用户身份验证数据至少包括对应用户的用户公钥。

该用户公钥是基于不对称加密算法验证用户身份所使用的密钥对中的公钥。该密钥对中还包括与用户公钥对应的用户私钥。该密钥对可以由客户端在向服务器通过登录、注册等行为获取用户身份时，由服务器分配后获取存储于本地存储中，也可以通过外部接口写入、预先存储在客户端的本地存储中。通过用户公钥，可以基于不对称加密算法验证用户身份，提高安全性，降低被恶意冒用身份的风险。

在某些应用场景中，对于安全性由较高的要求，因此，在上例中，第二用户的身份验证数据中还可以包括第二用户的身份签名数据；

所述第二用户的身份签名数据，是使用第二用户的用户公钥对应的用户私钥对第二用户的用户公钥进行数字签名处理得到的数据。

数字签名技术是将原文的摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后利用收到的原文以同样的方式产生摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，验证通过，否则说明信息被修改过，因此数字签名能够验证信息的完整性

在本例中，数字签名是个加密过程，是使用第二用户的用户私钥，对第二用户的用户公钥的摘要信息加密得到加密数据，得到包括第二用户的用户公钥与加密数据的签名身份数据。该用户公钥的摘要信息可以使用哈希函数产生，哈希函数是可以将任意长度的消息压缩到某一固定长度的消息摘要的函数。

对应地，本实施例中的步骤S2100中，获取第二用户的签名身份数据后，还包括对签名身份数据的验证步骤：

使用第二用户的用户公钥，对第二用户的身份签名数据验证通过后，才执行后续生成对应的转让授权数据的步骤S2200。

在本例中，验证第二用户的身份签名数据时，可以使用第二用户的用户公钥对身份签名数据中的摘要信息解密，再对身份签名数据中的原文(用户公钥)产生摘要信息，与解密的摘要信息比对，两者相同是，身份签名数据验证通过。

在本例中，还可以进一步计算第二用户的用户公钥的哈希值，该哈希值是对第二用户的用户公钥进行哈希计算得到的固定长度的数值，与第二用户的用户公钥唯一对应；使用第二用户的用户私钥对第二用户的用户公钥的哈希值进行数字签名处理，得到对应的身份签名数据；对应地，该身份签名数据的验证步骤，可以与前述的验证步骤类似，验证身份签名数据中的第二用户的用户公钥的哈希值的完整性。进一步提升身份验证的安全性。

在本实施例中，可以通过多种方式获取上述的第二用户的身份验证数据。例如，可以通过扫描包含第二用户的身份验证数据的二维码图像，获取第二用户的身份验证数据，或者，通过近距离通信方式，接收第二用户发送的身份验证数据。该近距离通信方式可以包括WIFI、蓝牙、NFC、ZigBee等支持近距离内信息交互的通信方式。

步骤S2200，根据本地存储的第一用户的身份验证数据、第二用户的身份验证数据，对本地存储的目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据。

第一用户的身份验证数据可以与第二用户的身份验证数据包括相同类型的数据。该身份验证数据已经在上文中详细描述，在此不再赘述。

第一用户持有目标电子票，与其对应的客户端本地存储中，存储有与目标电子票的目标票据数据。该目标票据数据通常包括对应的活动项目信息以及持有目标电子票的用户信息。该活动项目信息可以包括项目标识、项目时间、电子票所在场馆、座位、电子票出票时间等。该用户信息可以包括用户标识、用户购买信息、用户支付信息等。在一个例子中，第一用户是通过第二实施例中提供的电子票转让方法，通过转让获取的目标电子票时，目标票据数据中还可以包括在先转让用户的转让授权数据。

在本实施例中，基于第一用户、第二用户的身份验证数据对目标票据数据处理，生成转让授权数据，使得转让授权数据中包含本次转让涉及的用户身份、电子票的具体信息，受让方通过接收转让授权数据以及对应目标票据就能完成电子票的转让，无需通过线上服务器处理，实现电子票的线下流通，同时确保电子票转让的安全性。

在本实施例中，可以通过多种方式生成对应的转让授权数据。

例如，身份验证数据至少包括对应用户的用户公钥时，可以通过如图3所示的步骤生成对应的转让授权数据，包括：步骤S2210-S2220。

步骤S2210，使用与第一用户的用户公钥对应的用户私钥，对第二用户的用户公钥以及目标票据数据进行数字签名处理，生成对应的转让签名数据。

在本步骤中，可以将第二用户的用户公钥与目标票据数据组合得到对应的原文数据，使用第一用户的用户私钥对原文数据加密得到加密数据，完成数据签名处理，得到包括原文数据和加密数据的转让签名数据。

在一个例子中，步骤S2210还可以如图4所示，包括步骤S2211-S2213。

步骤S2211，对第二用户的用户公钥进行哈希计算，得到对应的第二用户哈希值。

步骤S2212，对目标票据数据进行哈希计算，得到对应的目标票据哈希值。

在本例中，哈希计算时通过基于哈希函数对输入的数据进行计算，得到对应的缩减数据长度的某个固定长度的哈希值，该哈希值与输入的数据唯一对应。

步骤S2213，使用与第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理，得到对应的转让签名数据。

在本步骤中，对第二用户哈希值和目标票据哈希值进行数字签名处理，与对第二用户的用户公钥与目标票据数据进行数字签名处理的方法类似，在此不再赘述。

步骤S2220，根据第一用户的用户公钥以及转让签名数据，生成对应的转让授权数据。

在本例中，可以将第一用户的用户公钥和转让签名数据组合得到的数据，生成对应的转让授权数据，使得转让授权数据中包含表征本次转让涉及的用户身份、电子票的信息，受让方通过接收转让授权数据以及对应目标票据就能完成电子票的转让，无需通过线上服务器处理，实现电子票的线下流通，同时确保电子票转让的安全性。

在一个例子中，转让授权数据还可以包括步骤S2212中获取的目标票据哈希值，以使得获取转让授权数据的一方，可以基于接收的目标票据数据计算哈希值，与转让授权数据中的目标票据哈希值比对，进一步验证目标票据数据，提升安全性。

步骤S2300，将目标票据数据以及对应的转让授权数据，提供给第二用户，以实施所述目标电子票的转让。

在本实施例中，第一用户对应的客户端，可以通过多种方式将目标票据数据以及对应的转让授权收据，提供给第二用户。例如，根据目标票据数据以及对应的转让授权数据，生成对应的二维码图像以供第二用户扫描获取；或者，通过近距离通信方式，将目标票据数据以及对应的转让授权数据，发送给第二用户。该近距离通信方式可以包括WIFI、蓝牙、NFC、ZigBee等支持近距离内信息交互的通信方式。

<客户端>

在本实施例中，还提供一种客户端200，如图5所示，包括：

存储器210，用于存储可执行的指令；

处理器220，用于根据可执行的指令的控制，运行客户端200，执行如本实施例提供的任意一项的电子票转让方法。

在本实施例中，并不限定客户端200的实体形式，客户端200可以是手机、平板电脑、掌上电脑、计算机等电子设备。客户端200还可以包括其他模块，例如，可以如图1所示的客户端1200。

本领域技术人员应当明白，可以通过各种方式来实现客户端200。例如，可以通过指令配置处理器来实现客户端200。例如，可以将指令存储在ROM中，并且当启动设备时，将指令从ROM读取到可编程器件中来实现客户端200。例如，可以将客户端200固化到专用器件(例如ASIC)中。可以将客户端200分成相互独立的单元，或者可以将它们合并在一起实现。客户端200可以通过上述各种实现方式中的一种来实现，或者可以通过上述各种实现方式中的两种或更多种方式的组合来实现。

以上已经结合附图和例子说明了本实施例，本实施例中提供一种电子票的转让方法以及客户端，通过与持有目标电子票的第一用户对应的客户端，获取受让目标电子票的第二用户的身份验证数据，根据转让双方的身份验证数据对目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据，并将目标票据数据以及转让授权数据提供给第二用户，完成目标电子票的转让，无需通过线上服务器处理，实现电子票的线下流通，同时确保电子票转让的安全性。提升用户的电子票使用体验。

<第二实施例>

在本实施例中，提供一种电子票的转让方法，实现第一用户所持有的目标电票转让给第二用户，由第二用户对应的客户端实施。

该客户端与第二用户对应，可以是由第二用户持有、登录或者使用的客户端。该客户端可以是手机、平板、掌上电脑、平板电脑、台式计算机等电子设备。例如，可以如图1所示的客户端1200。在一个例子中，该客户端可以是安装有票务应用的手机。

目标电子票由第一用户持有，可以是第一用户通过购买、兑换、转让等途径得到的提供对应票务服务的票据的电子形式，例如，该目标电子票可以是二维码图像形式。

该电子票的转让方法，如图6所示，包括：步骤S3100-S3400。

步骤S3100，向第一用户提供本地存储的第二用户的身份验证数据。

在本实施例中，用户的身份验证数据是用于验证对应用户的身份的数据。例如，可以是用于标识该第二用户的用户身份标识、用户账户名称等。

在实际应用中，用户的身份验证数据仅包括用户身份标识等简单数据时，会带来易于被恶意冒用身份的风险。

因此，在一个例子中，用户身份验证数据至少包括对应用户的用户公钥。

该用户公钥是基于不对称加密算法验证用户身份所使用的密钥对中的公钥。该密钥对中还包括与用户公钥对应的用户私钥。该密钥对可以由客户端在向服务器通过登录、注册等行为获取用户身份时，由服务器分配后获取存储于本地存储中，也可以通过外部接口写入、预先存储在客户端的本地存储中。通过用户公钥，可以基于不对称加密算法验证用户身份，提高安全性，降低被恶意冒用身份的风险。

在某些应用场景中，对于安全性由较高的要求，因此，在上例中，第二用户的身份验证数据中还可以包括第二用户的身份签名数据，对应地，本实施例中提供的方法还包括：

使用与第二用户的用户公钥对应的用户私钥，对第二用户的用户公钥进行数字签名处理，得到第二用户的身份签名数据。

数字签名技术是将原文的摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用收到的原文也产生摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，验证通过，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

在本例中，数字签名是个加密过程，是使用第二用户的用户私钥，对第二用户的用户公钥的摘要信息加密得到加密数据，得到包括第二用户的用户公钥与加密数据的签名身份数据。该用户公钥的摘要信息可以使用哈希函数产生，哈希函数是可以将任意长度的消息压缩到某一固定长度的消息摘要的函数。

将第二用户的身份签名数据提供给第一用户，可以供第一用户基于身份签名数据进一步验证第二用户的身份，提升安全性。对应的第一用户的验证步骤在第一实施例中已经描述，在此不再赘述。

在本例中，还可以进一步计算第二用户的用户公钥的哈希值，该哈希值是对第二用户的用户公钥进行哈希计算得到的固定长度的数值，与第二用户的用户公钥唯一对应；使用第二用户的用户私钥对第二用户的用户公钥的哈希值进行数字签名处理，得到对应的身份签名数据，供第一用户基于身份签名数据验证第二用户的身份。进一步提升身份验证的安全性。

在本实施例中，可以通过多种方式向第一用户提供上述的第二用户的身份验证数据。例如，根据本地存储的第二用户的身份验证数据生成对应的二维码图像，以供第一用户扫描获取，或者，通过近距离通信方式，向第一用户发送第二用户的身份验证数据。该近距离通信方式可以包括WIFI、蓝牙、NFC、ZigBee等支持近距离内信息交互的通信方式。

步骤S3200，通过第一用户获取目标票据数据以及对应的转让授权数据。

在本实施例中，目标票据数据与目标电子票对应，转让授权数据根据第一实施例中的方法由第一用户根据其身份验证数据、第二用户的身份验证数据以及目标票据数据处理生成，在此不再赘述。

在本实施例中，第二用户对应的客户端，可以通过多种方法通过第一用户获取目标票据数据以及对应的转让授权数据。例如，扫描包含目标票据数据以及转让授权数据的二维码图像，获取目标票据数据以及转让授权数据，或者，通过近距离通信方式，接收第一用户发送的目标票据数据以及转让授权数据。该近距离通信方式可以包括WIFI、蓝牙、NFC、ZigBee等支持近距离内信息交互的通信方式。

步骤S3300，从转让授权数据中获取第一用户的身份验证数据。

该转让授权数据根据第一用户的身份验证数据、第二用户的身份验证数据对目标票据数据处理生成，因此，第二用户从转让授权数据中可以根据与转让授权数据的生成方法的解析方法，获取第一用户的身份验证数据。

在一个例子中，身份验证数据中至少包括对应用户的用户公钥；转让授权数据中包括第一用户的用户公钥以及转让签名数据，第二用户可以直接解析转让授权数据，从中提取第一用户的用户公钥。

步骤S3400，根据第一用户的身份验证数据以及第二用户的身份验证数据，对转让授权数据进行验证，在验证通过后确定目标电子票转让成功。

转让授权数据是基于第一用户的身份验证数据、第二用户的身份验证数据对目标票据数据处理生成，第二用户只要通过第一用户获取目标票据数据以及转让授权数据，就能完成目标电子票的转让，无需通过线上服务器的处理，实现电子票的线上流通。第二用户对转让授权数据进行验证，在验证通过后确定目标电子票转让成功，确保电子票转让的安全性。

在一个例子中，身份验证数据中至少包括对应用户的用户公钥；转让授权数据中包括第一用户的用户公钥以及转让签名数据；转让签名数据，是使用与第一用户的用户公钥对应的用户私钥，对第二用户的用户公钥以及目标票据数据进行数字签名处理得到的数据。对应的生成转让签名数据的步骤在第一实施例中已经描述，在此不再赘述。

对应地，对转让授权数据进行验证的步骤S3400，如图7所示，包括步骤S3410-S3420。

步骤S3410，使用第一用户的用户公钥，验证转让签名数据。

在本例中，验证转让签名数据的过程与生成转让签名数据的步骤对应。该转让签名数据是使用与第一用户的用户私钥，对第二用户的用户公钥以及目标票据数据进行数字签名处理得到的数据。具体地，可以是将第二用户的用户公钥与目标票据数据组合得到对应的原文数据，使用第一用户的用户私钥对原文数据加密得到加密数据，完成数据签名处理，得到包括原文数据和加密数据的转让签名数据。

对该转让签名数据验证，可以使用第一用户的用户公钥对加密数据解密，将解密后得到的加密数据与接收到的原文数据比较，如果两者相同，则该转让签名数据验证通过。

在本例中，转让签名数据还可以是使用与第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；该第二用户哈希值是对第二用户的用户公钥进行哈希计算得到的数值；该目标票据哈希值是对目标票据数据进行哈希计算得到的数值。对应的生成该让签名数据的步骤在第一实施例中已经描述，在此不再赘述。

对应地，在步骤S3410中，验证该转让签名数据的步骤类似地，可以使用第一用户的用户公钥对转让签名数据解密，将解密得到的第二用户哈希值和目标票据哈希值，与接收的转让签名数据中第二用户哈希值和目标票据哈希值的原文比较，比较结果相同时，则该转让签名数据验证通过。

步骤S3420，在转让签名数据验证通过后，使用第二用户的用户公钥，对转让签名数据中包括的第二用户的用户公钥进行验证，验证通过后确定目标电子票转让成功。

在转让签名数据验证通过后，可以从转让签名数据中获取第二用户的用户公钥，使用本地存储的第二用户公钥进行比对，当两者相同时，验证通过后确定目标电子票转让成功。

在一个例子中，转让签名数据验证通过后，可以从转让前面数据中获取第二用户的用户公钥哈希值，对应地，步骤S3420包括：

在转让签名数据验证通过后，使用第二用户的用户公钥通过哈希计算得到的哈希值，对转让签名数据中包括的第二用户哈希值进行验证，验证通过后确定目标电子票转让成功。

<客户端>

在本实施例中，还提供一种客户端300，如图8所示，包括：

存储器310，用于存储可执行的指令；

处理器320，用于根据可执行的指令的控制，运行客户端300，执行如本实施例提供的任意一项的电子票转让方法。

在本实施例中，并不限定客户端300的实体形式，客户端300可以是手机、平板电脑、掌上电脑、计算机等电子设备。客户端300还可以包括其他模块，例如，可以如图1所示的客户端1200。

本领域技术人员应当明白，可以通过各种方式来实现客户端300。例如，可以通过指令配置处理器来实现客户端300。例如，可以将指令存储在ROM中，并且当启动设备时，将指令从ROM读取到可编程器件中来实现客户端300。例如，可以将客户端300固化到专用器件(例如ASIC)中。可以将客户端300分成相互独立的单元，或者可以将它们合并在一起实现。客户端300可以通过上述各种实现方式中的一种来实现，或者可以通过上述各种实现方式中的两种或更多种方式的组合来实现。

以上已经结合附图和例子说明了本实施例，本实施例中提供一种电子票的转让方法以及客户端，通过第二用户对应的客户端，向持有目标电子票的第一用户提供第二用户的身份验证数据，通过第一用户获取根据转让双方的身份验证数据对目标电子票对应的目标票据数据进行处理得到的转让授权数据和目标票据数据，完成目标电子票的转让，无需通过线上服务器处理，实现电子票的线下流通，同时通过验证转让授权数据确定目标电子票转让成功，确保电子票转让的安全性。提升用户的电子票使用体验。

<第三实施例>

在本实施例中，提供一种电子票的验证方法，用于验证第一用户转让给第二用户的目标电子票，通过服务器实施。

目标电子票由第一用户转让给第二用户，可以是第一用户通过购买、兑换、转让等途径得到的提供对应票务服务的票据的电子形式，例如，该目标电子票可以是二维码图像形式。

该服务器可以是云端服务器、刀片服务器或者任意可以提供数据服务的电子设备。例如，该服务器是提供票务相关的数据服务的电子设备。具体地，该服务器可以是图1所示的服务器1100。

该电子票的验证方法，如图9所示，包括：步骤S4100-S4200。

步骤S4100，接收第二用户发送的验票请求。

该验票请求中至少包括与目标电子票对应的目标票据数据以及对应的转让授权数据。该目标票据数据以及所述转让授权数据，由第一用户通过第一实施例中的提供的电子票转让方法提供给第二用户，在此不再赘述。

在本实施例中，服务器可以通过无线或有线通信协议接收第二用户发送的验票请求。例如，第二用户的验票请求中包括的目标票据数据和转让授权数据是以二维码图像的形式提供给与服务器建立连接的验票设备，该验票设备扫描该二维码图像时，服务器通过验票设备接收第二用户的验票请求。

步骤S4200，对目标票据数据进行验证，以及根据本地存储的第一用户的身份验证数据、第二用户的身份验证数据对转让授权数据进行验证，在目标票据数据、所述转让授权数据均验证通过后，确定所述目标电子票验证通过。

在本实施例中，用户的身份验证数据是用于验证对应用户的身份的数据。例如，可以是用于标识该用户的用户身份标识、用户账户名称等。该用户的身份验证数据，通常可以是用户向服务器通过登录、注册等行为获取用户身份时，由服务器进行分配或者服务器从用户对应的客户端获取，服务器在本地存储中会备份对应的用户的身份验证数据。

在实际应用中，用户的身份验证数据仅包括用户身份标识等简单数据时，会带来易于被恶意冒用身份的风险。

因此，在一个例子中，用户身份验证数据至少包括对应用户的用户公钥。

该用户公钥是基于不对称加密算法验证用户身份所使用的密钥对中的公钥。该密钥对中还包括与用户公钥对应的用户私钥。该密钥对可以由客户端在向服务器通过登录、注册等行为获取用户身份时，由服务器分配给用户或者由服务器向用户获取。

在一个例子中，身份验证数据中包括对应用户的用户公钥；转让授权数据中包括第一用户的用户公钥以及转让签名数据；转让签名数据，是使用与第一用户的用户公钥对应的用户私钥，对第二用户的用户公钥以及目标票据数据进行数字签名处理得到的数据。该转让签名数据的生成方法在第一实施例中已经描述，在此不再赘述。

对应地，对转让授权数据进行验证的步骤可以如图10所示，包括步骤S4210-S4220。

步骤S4210，使用第一用户的用户公钥，验证转让签名数据。

在本例中，转让签名数据还可以是使用与第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；该第二用户哈希值是对第二用户的用户公钥进行哈希计算得到的数值；该目标票据哈希值是对目标票据数据进行哈希计算得到的数值。对应的生成该让签名数据的步骤在第一实施例中已经描述，在此不再赘述。

上述验证转让签名数据S4210，与第二实施例中图7所示的步骤S3410类似，在此不再赘述。

步骤S3420，在转让签名数据验证通过后，使用第二用户的用户公钥，对转让签名数据中包括的第二用户的用户公钥进行验证，验证通过后确定转让授权数据验证通过。

该步骤，与第二实施例中图7所示的步骤S3420类似，在转让签名数据验证通过后，可以从转让签名数据中获取第二用户的用户公钥，使用本地存储的第二用户公钥进行比对，当两者相同时，验证通过后确定转让授权数据验证通过。

在一个例子中，转让签名数据验证通过后，可以从转让前面数据中获取第二用户的用户公钥哈希值，对应地，步骤S3420包括：

在转让签名数据验证通过后，使用第二用户的用户公钥通过哈希计算得到的哈希值，对转让签名数据中包括的第二用户哈希值进行验证，验证通过后确定转让授权数据验证通过。

在实际应用中，目标票据数据通常由服务器在用户通过购买、兑换获取目标电子票是，根据对应用户信息、购票信息、对应的票务信息生成，在本实施例中，可以基于具体应用中与产生目标票据数据对应的步骤，验证目标票据数据。在此不做限制。

目标票据数据验证通过，表征对应的目标电子票真实有效；转让授权数据验证通过，表征第一用户向第二用户线下转让的目标电子票的交易信息真实有效。在目标票据数据、转让授权数据均验证通过后，确定目标电子票验证通过，实现对线下转让的电子票的线上验证，以支持电子票的线下流通，同时确保转让电子票的安全性，提升用户的电子票使用体验。

应当理解的是，第一用户向第二用户转让的目标电子票，也可能是第一用户经由其他在先用户转让获取，因此，与目标电子票对应的目标电子票据中，还包括其他在先用户向第一用户转让电子票时产生的转让授权数据，对应的，在本实施例中，对这样的目标电子票验证时，还可以基于如图10所示的方法，验证其他在先用户产生的转让授权数据，在此不再赘述。

<服务器>

在本实施例中，还提供一种服务器400，如图11所示，包括

存储器410，用于存储可执行的指令；

处理器420，用于根据可执行的指令的控制，运行服务器400，执行如本实施例提供的任意一项的电子票转让方法。

在本实施例中，并不限定服务器400的实体形式，服务器400可以是云端服务器、刀片服务器、服务器群组。服务器还可以包括其他模块，例如，如图1所示的服务器1100。

本领域技术人员应当明白，可以通过各种方式来实现服务器400。例如，可以通过指令配置处理器来实现服务器400。例如，可以将指令存储在ROM中，并且当启动设备时，将指令从ROM读取到可编程器件中来实现服务器400。例如，可以将服务器400固化到专用器件(例如ASIC)中。可以将服务器400分成相互独立的单元，或者可以将它们合并在一起实现。服务器400可以通过上述各种实现方式中的一种来实现，或者可以通过上述各种实现方式中的两种或更多种方式的组合来实现。

以上已经结合附图描述了本发明的实施例，根据本实施例，提供一种电子票的验证方法及服务器，通过服务器对第二用户持有的、通过第一用户转让的目标电子票进行验证，对目标电子票对应的目标票据数据以及根据转让双方的身份验证数据生成的转让授权数据分别进行验证，均验证通过时确定目标电子票验证通过，实现对线下转让的电子票的线上验证，以支持电子票的线下流通。同时确保转让电子票的安全性，提升用户的电子票使用体验。

<第四实施例>

在本实施例中，提供一种票务系统500，如图12所示，包括：

第一实施例中提供的客户端200；

第二实施例中提供的客户端300；

第三实施例中提供的服务器400。

在本实施例中，通过票务系统500，可以支持电子票的线下流通，对线下流通的电子票的线上验证。在本实施例中，并不限制票务系统500的具体实施形式。例如，票务系统500包括的客户端200、客户端300可以是相同类型的客户端，例如，都是安装相同的票务应用的手机。或者，票务系统500还可以如图1所示的系统1000。

<例子>

以下将结合图13进一步说明通过本实施例中票务系统500实现的电子票线下流通方法。

在本例中，客户端200是由转让目标电子票的第一用户持有的客户端，客户端300是由受让目标电子票的第二用户持有的客户端。客户端200、客户端300均是安装有票务应用的手机。

该电子票的线下流通方法，如图13所示，包括：步骤S501-S506。

步骤S501，客户端200从客户端300获取第二用户的身份验证数据。

在本例中，身份验证数据是对应用户的用户公钥。客户端200扫描客户端300提供的二维码图像获取第二用户的用户公钥。

步骤S502，客户端200根据本地存储的第一用户的身份验证数据、获取的第二用户的身份验证数据对与目标电子票对应的目标票据数据处理，生成转让授权数据。

在本例中，可以使用与第一用户的用户公钥对应的用户私钥，对基于第二用户的用户公钥进行哈希计算得到的第二用户哈希值以及基于目标票据数据进行哈希计算得到的目标票据哈希值进行数字签名处理，得到转让签名数据，将转让签名数据和目标票据数据组合得到转让授权数据。

步骤S503，客户端200将目标票据数据、转让授权数据提供给客户端300。

在本例中，客户端300通过客户端200提供的二维码获取对应的目标票据数据、转让授权数据。

步骤S504，客户端300验证转让授权数据，确定目标电子票转让成功。

在本例中，客户端300从转让授权数据中获取第一用户的用户公钥，使用第一用户的用户公钥解密转让授权数据中转让签名数据，根据转让签名数据中的原文数据计算对应的摘要信息，将摘要信息与解密的转让签名数据比对，两者一致后，验证转让签名数据通过，再根据第二用户的用户公钥计算对应哈希值，与转让签名数据中解密后得到的第二用户的哈希值比对，比对相同后，转让授权数据验证通过，确定目标电子票转让成功

步骤S505，客户端300向服务器400发送验票请求，验票请求中包括目标票据数据和转让授权数据。

步骤S506，服务器400分别验证目标票据数据以及转让授权数据，均验证通过后，确定目标电子票验证通过。

在本例中，验证目标票据数据的步骤可以与对应的生成目标票据数据的步骤对应，在此不做限制。验证转让授权数据的步骤与步骤S506类似，在此不再赘述。

通过本例中的票务系统500，通过客户端200与客户端300实现目标电子票的线下转让，通过服务器400实现对线下转让的目标电子票的线上验证，以此支持电子票的线下流通，提高电子票的流通效率。同时提升用户的电子票使用体验。

本发明可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本发明的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本发明操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。本发明的范围由所附权利要求来限定。

Claims (16)

1.一种电子票的转让方法，实现第一用户所持有的目标电子票转让给第二用户，由所述第一用户对应的客户端实施，包括：

获取所述第二用户的身份验证数据；

根据本地存储的所述第一用户的身份验证数据、获取的所述第二用户的身份验证数据，对本地存储的所述目标电子票对应的目标票据数据进行处理，生成对应的转让授权数据；其中，所述目标票据数据包括对应的活动项目信息以及持有所述目标电子票的用户信息；所述转让授权数据包括表征本次转让涉及的用户身份和所述目标电子票的信息；

将所述目标票据数据以及对应的转让授权数据，提供给所述第二用户，以实施所述目标电子票的转让；

所述身份验证数据至少包括对应用户的用户公钥；

所述生成对应的转让授权数据的步骤包括：

使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理，生成对应的转让签名数据；

根据所述第一用户的用户公钥以及所述转让签名数据，生成对应的转让授权数据。

2.根据权利要求1所述的方法，其中，

所述生成对应的转让授权数据的步骤包括：

对所述第二用户的用户公钥进行哈希计算，得到对应的第二用户哈希值；

对所述目标票据数据进行哈希计算，得到对应的目标票据哈希值；

使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户哈希值和目标票据哈希值进行数字签名处理，得到对应的转让签名数据。

3.根据权利要求1所述的方法，其中，

所述第二用户的身份验证数据中还包括第二用户的身份签名数据；

所述第二用户的身份签名数据，是使用与所述第二用户的用户公钥对应的用户私钥对所述第二用户的用户公钥，进行数字签名处理得到的数据；

所述方法还包括：

使用所述第二用户的用户公钥，对所述第二用户的身份签名数据验证通过后，才执行所述生成对应的转让授权数据的步骤。

4.根据权利要求1所述的方法，其中，

所述获取第二用户的身份验证数据的步骤包括：

扫描包含所述第二用户的身份验证数据的二维码图像，获取所述第二用户的身份验证数据；或者，通过近距离通信方式，接收所述第二用户发送的身份验证数据；

和/或，

将所述目标票据数据以及对应的转让授权数据，提供给所述第二用户的步骤包括：

根据所述目标票据数据以及对应的转让授权数据，生成对应的二维码图像以供所述第二用户扫描获取；或者，通过近距离通信方式，将所述目标票据数据以及对应的转让授权数据，发送给所述第二用户。

5.一种电子票的转让方法，实现第一用户所持有的目标电子票转让给第二用户，由所述第二用户对应的客户端实施，包括：

向所述第一用户提供本地存储的所述第二用户的身份验证数据；

通过所述第一用户获取目标票据数据以及对应的转让授权数据；

其中，所述目标票据数据与所述目标电子票对应，所述转让授权数据根据权利要求1-4所述的任意一项的 方法生成；

从所述转让授权数据中获取所述第一用户的身份验证数据，

根据所述第一用户的身份验证数据以及所述第二用户的身份验证数据，对所述转让授权数据进行验证，在验证通过后确定所述目标电子票转让成功。

6.根据权利要求5所述的方法，其中，

所述身份验证数据中至少包括对应用户的用户公钥；

所述转让授权数据中包括所述第一用户的用户公钥以及转让签名数据；

所述转让签名数据，是使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理得到的数据；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥，对所述转让签名数据中包括的所述第二用户的用户公钥进行验证，验证通过后确定所述目标电子票转让成功。

7.根据权利要求6所述的方法，其中，

所述转让签名数据是使用与所述第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；所述第二用户哈希值是对所述第二用户的用户公钥进行哈希计算得到的数值；所述目标票据哈希值是对所述目标票据数据进行哈希计算得到的数值；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥通过哈希计算得到的哈希值，对所述转让签名数据中包括的所述第二用户哈希值进行验证，验证通过后确定所述目标电子票转让成功。

8.根据权利要求6所述的方法，其中，

所述第二用户的身份验证数据中还包括第二用户的身份签名数据；

所述方法还包括：

使用与所述第二用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥进行数字签名处理，得到所述第二用户的身份签名数据。

9.根据权利要求5所述的方法，其中，

所述提供所述第二用户的身份验证数据的步骤包括：

根据本地存储的第二用户的身份验证数据生成对应的二维码图像，以供所述第一用户扫描获取，或者，通过近距离通信方式，向所述第一用户发送所述第二用户的身份验证数据；

和/或，

所述获取目标票据数据以及对应的转让授权数据的步骤包括：

扫描包含所述目标票据数据以及所述转让授权数据的二维码图像，获取所述目标票据数据以及转让授权数据，或者，通过近距离通信方式，接收所述第一用户发送的目标票据数据以及所述转让授权数据。

10.一种电子票的验证方法，用于验证第一用户转让给第二用户的目标电子票，通过服务器实施，包括：

接收第二用户发送的验票请求；

其中，所述验票请求中至少包括与所述目标电子票对应的目标票据数据以及对应的转让授权数据；所述目标票据数据以及所述转让授权数据，由所述第一用户根据权利要求1-4任意一项所述的方法提供给所述第二用户；

对所述目标票据数据进行验证，以及根据本地存储的第一用户的身份验证数据、第二用户的身份验证数据对所述转让授权数据进行验证，在所述目标票据数据、所述转让授权数据均验证通过后，确定所述目标电子票验证通过。

11.根据权利要求10所述的方法，其中，

所述身份验证数据中包括对应用户的用户公钥；

所述转让授权数据中包括所述第一用户的用户公钥以及转让签名数据；

所述转让签名数据，是使用与所述第一用户的用户公钥对应的用户私钥，对所述第二用户的用户公钥以及所述目标票据数据进行数字签名处理得到的数据；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥，对所述转让签名数据中包括的所述第二用户的用户公钥进行验证，验证通过后确定所述转让授权数据验证通过。

12.根据权利要求11所述的方法，其中，

所述转让签名数据是使用与所述第一用户的用户公钥对应的用户私钥，对第二用户哈希值和目标票据哈希值进行数字签名处理得到的数据；所述第二用户哈希值是对所述第二用户的用户公钥进行哈希计算得到的数值；所述目标票据哈希值是对所述目标票据数据进行哈希计算得到的数值；

所述对转让授权数据进行验证的步骤包括：

使用所述第一用户的用户公钥，验证所述转让签名数据；

在所述转让签名数据验证通过后，使用所述第二用户的用户公钥通过哈希计算得到的哈希值，对所述转让签名数据中包括的所述第二用户哈希值进行验证，验证通过后确定所述转让授权数据验证通过。

13.一种客户端，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述客户端，执行如权利要求1-4所述的任意一项的电子票转让方法。

14.一种客户端，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述客户端，执行如权利要求5-9所述的任意一项的电子票转让方法。

15.一种服务器，其中，包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述可执行的指令的控制，运行所述服务器，执行如权利要求10-12所述的任意一项的电子票的验证方法。

16.一种票务系统，其中，包括：

如权利要求13所述的客户端；

如权利要求14所述的客户端；

如权利要求15所述的服务器。

Images