CN113516786A - 闸机验票方法及系统 - Google Patents

Abstract

本申请公开了一种闸机验票方法，前置端与闸机端之间通过局域网通信，与服务端之间通过互联网通信，该方法包括：服务端根据用户购票订单获取票务数据；前置端从服务端下载票务数据后存储至本地数据库备用；闸机端获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向前置端发送用户的关键信息；前置端根据所述用户关键信息和所述票务数据进行票证比对，判断是否验票通过；通知闸机端验票结果，并记录在本地数据库中；将所述验票结果定时同步至所述服务端。本申请还公开了一种闸机验票系统、验票设备、电子装置和计算机可读存储介质。由此，能够支持灵活的现场中心管理模型，同时满足安全合规、网络条件、快速检票的综合情况。

Description

闸机验票方法及系统

技术领域

本申请涉及数据处理技术领域，尤其涉及一种闸机验票方法、系统、验票设备、电子装置及计算机可读存储介质。

背景技术

目前的闸机验票解决方案主要包括安装在安卓手机端的验票应用、安装在特别设备的PDA(Personal Digital Assistant，掌上电脑)验票应用客户端或者完全基于网络通信的闸机系统。但是，安卓手机端和PDA验票应用客户端模式不符合公安的安全要求，且在人群密集状态下，现场移动网络速度也会变差，具体表现为网络信号弱或者延迟变大。而完全基于网络通信的闸机系统对于展览场馆等现场情况需要较大的成本并有较大风险，不符合现场的环境要求。展览场馆通常是提供短期(例如2-7天)使用，且不同展览之间的网络环境、网络设备等有所不同，无法满足完全组网状态下的网络通信。并且，对于现场网络中断的情况，上述方案无法满足现场验票需要。

需要说明的是，上述内容并不用于限制申请保护范围。

发明内容

本申请的主要目的在于提出一种闸机验票方法、系统、验票设备、电子装置及计算机可读存储介质，旨在解决如何在有限网络条件下安全快速地进行闸机现场验票的问题。

为实现上述目的，本申请实施例提供了一种闸机验票方法，所述方法包括：

服务端根据用户在终端的购票订单获取票务数据；

前置端从所述服务端下载所述票务数据后存储至本地数据库备用；

闸机端获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向所述前置端发送所述用户的关键信息；

所述前置端根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；将所述验票结果定时同步至所述服务端；

其中，所述前置端与所述闸机端之间通过局域网通信，所述前置端与所述服务端之间通过互联网通信。

可选地，所述方法还包括：

当所述前置端与所述服务端之间的互联网正常时，所述前置端定时向所述服务端请求同步数据，以不断更新本地和云端数据。

可选地，所述方法还包括：

当所述互联网出现故障时，所述前置端通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

可选地，所述票证比对包括依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道。

可选地，所述定时向服务端请求同步数据，以不断更新本地和云端数据包括：

将上次同步完成时间与本次同步时间之间的部分验票结果数据筛选出来，批量向所述服务端发起同步请求，以使所述服务端在接收到所述部分验票结果数据之后与所述服务端本地的数据合并；

接收所述服务端批量下发的上次同步完成时间与本次同步时间之间发生变更的票务数据，保存至所述本地数据库中。

此外，为实现上述目的，本申请实施例还提供一种验票设备，所述设备包括：

服务端，用于根据用户在终端的购票订单获取票务数据；

前置端，用于从所述服务端下载所述票务数据后存储至本地数据库备用；

闸机端，用于获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向所述前置端发送所述用户的关键信息；

所述前置端还用于根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；将所述验票结果定时同步至所述服务端；

其中，所述前置端与所述闸机端之间通过局域网通信，所述前置端与所述服务端之间通过互联网通信。

为实现上述目的，本申请实施例还提供一种闸机验票方法，应用于前置端，所述前置端与闸机端之间通过局域网通信，所述前置端与服务端之间通过互联网通信，所述方法包括：

从所述服务端下载票务数据后存储至本地数据库备用，所述票务数据为所述服务端根据用户在终端的购票订单获取得到；

接收所述闸机端在对用户进行人证比对通过后发送的用户关键信息；

根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；

通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；

将所述验票结果定时同步至所述服务端。

可选地，所述方法还包括：

当与所述服务端之间的互联网正常时，定时向所述服务端请求同步数据，以不断更新本地和云端数据。

可选地，所述方法还包括：

当所述互联网出现故障时，通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

可选地，所述定时向所述服务端请求同步数据，以不断更新本地和云端数据包括：

将上次同步完成时间与本次同步时间之间的部分验票结果数据筛选出来，批量向所述服务端发起同步请求，以使所述服务端在接收到所述部分验票结果数据之后与服务端本地的数据合并；

接收服务端批量下发的上次同步完成时间与本次同步时间之间发生变更的票务数据，保存至所述本地数据库中。

为实现上述目的，本申请实施例还提供一种闸机验票系统，应用于前置端，所述前置端与闸机端之间通过局域网通信，所述前置端与服务端之间通过互联网通信，所述系统包括：

获取模块，用于从所述服务端下载票务数据后存储至本地数据库备用，所述票务数据为所述服务端根据用户在终端的购票订单获取得到；

接收模块，用于接收所述闸机端在对用户进行人证比对通过后发送的用户关键信息；

判断模块，用于根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；

通知模块，用于通知闸机端验票结果，并将所述验票结果记录在所述本地数据库中；

同步模块，用于将所述验票结果定时同步至所述服务端。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的闸机验票程序，所述闸机验票程序被所述处理器执行时实现如上述的闸机验票方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有闸机验票程序，所述闸机验票程序被处理器执行时实现如上述的闸机验票方法。

本申请实施例提出的闸机验票方法、系统、验票设备、电子装置及计算机可读存储介质，能够通过现场前置端支持灵活的现场中心管理模型，同时满足安全合规、网络条件、快速检票的综合情况，增加竞争力，满足该场景下多种实际需要。

附图说明

图1为本申请第一实施例提出的一种验票设备的应用环境架构图；

图2为本申请第二实施例提出的一种闸机验票方法的流程图；

图3为图2中步骤S106的细化流程示意图；

图4为本申请第三实施例提出的一种闸机验票方法的流程图；

图5为本申请第四实施例提出的一种闸机验票方法的流程图；

图6为本申请第五实施例提出的一种电子装置的硬件架构示意图；

图7为本申请第六实施例提出的一种闸机验票系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

实施例一

请参阅图1，图1为本申请第一实施例提供的一种验票设备的应用环境架构图。所述验票设备包括，但不仅限于闸机端2、前置端4、服务端6。

其中，所述闸机端2包括门禁、摄像头、身份识别卡在内的软硬件系统，由一个或多个闸机组成。所述闸机端2用于在用户通过时，获取用户身份证图像和人脸图像，识别身份证照片与人脸图像进行人证比对，并在人证比对通过后，向前置端4提供用户关键信息。

所述服务端6为后台云端服务器，用于根据用户在终端(可以为移动端，例如手机；或者固定终端，例如展览场馆的购票机)的购票订单获取票务数据。

所述前置端4为基于MacOS或者WinOS等操作系统的软硬件混合系统，也称为现场控制平台。所述前置端4用于从服务端6下载票务数据后存储至本地数据库备用，并在收到闸机端2提供的用户关键信息后从所述本地数据库中进行票证比对，当所有条件均满足时告知闸机端2验票通过，将该用户验票结果记录在所述本地数据库中，并将所述验票结果定时同步至所述服务端6。

其中，所述前置端4和所述闸机端2之间通过路由器、交换机(图中未示出)组成局域网模式。所述闸机端2的每台闸机是局域网模式下的客户端系统，负责提供单个用户的验票数据和请求。所述前置端4是局域网模式下的服务端系统，负责统一验票和回传闸机请求，并写入验票结果。

同时，所述前置端4和所述服务端6在互联网环境下组成互联网模式。所述前置端4可以自行定时发送请求到服务端6，若互联网络通畅，则可保持定时与服务端6的数据交换和同步，以不断更新本地和云端数据；若互联网不通畅(发生故障)，不中断现场验票操作(以局域网模式进行)，仅保持局域网下的数据正常；直到互联网再次通畅后将本地在故障期间保存的数据批量同步至服务端6。

实施例二

如图2所示，为本申请第二实施例提出的一种闸机验票方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S100，服务端根据用户在终端的购票订单获取票务数据。

以展览场馆的购票和检票为例，通常用户在终端(可以为移动端，例如手机；或者固定终端，例如展览场馆的购票机)查询展会类信息，并在选择好展会场次之后下单、填写必要信息(包括实名证件、日期、场次、票种等)，支付完成后该订单正式生成。每个订单具有唯一编号，会存储在服务端中，服务端根据所述订单可以获取对应的票务数据。所述票务数据可以包括订票标识、场次ID、价格、状态、加密凭证、票种名称、展览项目、检票时间、用户ID(例如用户身份证号)、订单ID、后端更新时间等。

S102，前置端从所述服务端下载所述票务数据后存储至本地数据库备用。

对于每一场独立的展览，前置端在开始检票之前从服务端中将本次展览的票务数据全部下载到本地数据库中进行存储备用。所述票务数据以单场项目计算，连续多天的项目为同一个。

S104，闸机端获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向所述前置端发送所述用户的关键信息。

在本实施例中，验票的方式支持实名验票模式，即实施人脸、身份证、门票三者一致方可通过闸机进入场馆的方式。

当用户(参观展览的观众，通常认为是已经购票的人)从闸机前通过时，系统提示放置身份证，并保持人脸正对闸机屏幕(含摄像头)。闸机获取用户身份证图像和人脸图像，然后识别身份证中的照片，与人脸图像进行比对。当人证比对通过(身份证照片与人脸图像的相似度达到阈值)后，闸机向前置端提供该用户的关键信息，例如身份证信息等。若人证比对未通过(身份证照片与人脸图像的相似度未达到阈值)，则闸机直接向该用户给出错误提示。

另外，在人证比对阶段还可以检查出该用户是否为公安系统指定的特别名单，并由现场公安盘查。

S106，所述前置端根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过。

闸机端向前置端提供所述用户关键信息，以请求形式再次发出。在本实施例中，由于采用实名验票模式且闸机端已进行人证比对，因此前置端主要是根据所述用户关键信息中的身份证信息和所述本地数据库中的票务数据进行票证比对，当票证一致时判断验票通过。

具体而言，前置端根据所述用户关键信息在本地数据库中依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道等条件。在进行上述各个条件的校验过程中，只要存在一条校验不通过，则判断为验票未通过。若所有条件均满足，则判断为验票通过。

进一步参阅图3，为上述步骤S106的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S106具体包括：

S1060，获取所述用户关键信息中的身份证信息。

S1061，判断所述身份证信息是否有效。当有效时，执行步骤S1062；当无效时，执行步骤S1069。

所述有效包括在身份证颁发的有效期限内且不在公安(或主办单位等)的黑名单中。若不满足上述条件，则判断所述身份证信息为无效。

S1062，从所述票务数据中查询所述身份证信息绑定的门票列表。

所述门票列表中可以将门票按时间(例如展览时间)排序。

S1063，判断是否具有可用票种。也就是所述门票列表中是否有该展览对应的门票，即该用户是否购票。当具有可用票种时，执行步骤S1064；当没有可用票种时，执行步骤S1069。

S1064，判断该可用票种的门票是否验过。若该门票已验过，则表示为重复验证(即重复入场)，执行步骤S1069，否则执行S1065。

S1065，从所述票务数据中查询所述门票对应的场次信息。

S1066，判断当前验票时间是否在所述场次信息对应的有效时间内。也就是判断该门票是否为本场次票种。若是，则执行步骤S1067，否则执行步骤S1069。

S1067，判断该门票是否为当前闸机允许的票种。也就是判断该门票是否允许走该闸机通道(即该用户入场是否走的正确通道)。若是，则执行步骤S1068，否则执行步骤S1069。

S1068，判断该用户验票通过。

S1069，判断该用户验票未通过。

回到图2，S108，所述前置端通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中。

当验票未通过时，前置端返回错误提示至闸机端，告知用户。当验票通过时，前置端通知闸机端验票通过，用户可以顺利通过该闸机。并且，前置端将该用户的验票结果记录在本地数据库中(也可以只在验票通过时记录该用户的验票结果，验票未通过的不记录)。

并且，本实施例还支持现场工作人员按照现场的实际情况实时增加或约束用户，并根据现场的人群流动情况，实时调整单个闸机的验票票种、时间等状态，达到提高验票效率的目标。前置端也可向现场工作人员显示本场次的实时验票情况(例如每个用户的验票结果)等主要信息，以供现场工作人员实时查看。

另外，本实施例也支持现场工作人员依据现场情况在前置端插入临时票务数据，达到线下操作数据同时回流至线上的目的。现场工作人员在闸机验票的同时，也可以通过手持的PDA验票应用客户端对用户进行验票，PDA验票应用客户端也将用户关键信息发送至前置端进行票证比对。

S110，所述前置端将所述验票结果定时同步至所述服务端。

除了将所述验票结果实时通知至所述闸机端外，所述前置端还会定时将所述验票结果同步至所述服务端。在本实施例中，云端服务数据同步是在互联网环境下，由前置端发起网络请求，并同步数据。前置端保持定时向服务端请求同步数据的机制。

在有互联网的情况下，前置端在与服务端的数据同步过程中，会不断更新本地数据(存储到本地数据库中)，以满足各类现场临时票务需求。数据同步的过程为:前置端将上次同步完成时间与本次同步时间之间的部分验票结果数据筛选出来，批量向服务端发起同步请求。服务端接收到该部分验票结果数据后，与服务端本地数据做合并处理。此时，如果数据来源于前置端校验且和服务端数据状态冲突，则依然保存到服务端。此部分数据实际数量较少，且目标是用于后续优化使用，不影响现场检票过程。

同样，服务端也会将该时间段内(上次同步完成时间与本次同步时间之间)变更的票务数据批量下发到前置端，供前置端检票时使用。前置端会完全接收服务端下发的变更部分数据，保存至本地数据库中，之后在前置端进行的检票过程中会按照前述比对过程操作。在前置端是依照队列对所述本地数据库进行操作，因此不会出现数据混乱情况。

若前置端与服务端之间的互联网出现故障，则前置端继续尝试向服务端请求，在网络请求失败时也不做中断现场的验票操作。由于现场验票操作主要是依靠前置端和闸机端之间的局域网模式，因此不受互联网故障的影响。

在互联网故障期间，前置端会将所有验票数据(例如每个用户的验票结果)保存在本地数据库中。当所述互联网恢复正常后，前置端再将所述本地数据库在故障期间保存的所有数据批量同步至所述服务端。

另外，在每个展览项目结束之后，前置端的数据可全部通过互联网回传至服务端(此时可以不是展览现场的互联网络)。所有数据可由票务相关的产品、技术人员进行数据分析使用。

本实施例提出的闸机验票方法，可以支持灵活的现场中心管理模型，同时满足安全合规、网络条件、快速检票的综合情况，增加竞争力，满足该场景下多种实际需要。并且，可以支持有限条件(不稳定)网络环境下的实名验票核验方式，不仅支持互联网正常情况下的云数据同步，也支持现场离线状态下的数据在互联网恢复时统一回传至服务端。

实施例三

如图4所示，为本申请第三实施例提出的一种闸机验票方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述前置端4作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，从服务端下载票务数据后存储至本地数据库备用。

以展览场馆的购票和检票为例，通常用户在终端(可以为移动端，例如手机；或者固定终端，例如展览场馆的购票机)查询展会类信息，并在选择好展会场次之后下单、填写必要信息(包括实名证件、日期、场次、票种等)，支付完成后该订单正式生成。每个订单具有唯一编号，会存储在服务端中，服务端根据所述订单可以获取对应的票务数据。所述票务数据可以包括订票标识、场次ID、价格、状态、加密凭证、票种名称、展览项目、检票时间、用户ID(例如用户身份证号)、订单ID、后端更新时间等。

对于每一场独立的展览，前置端在开始检票之前从服务端中将本次展览的票务数据全部下载到本地数据库中进行存储备用。所述票务数据以单场项目计算，连续多天的项目为同一个。

S202，接收闸机端在对用户进行人证比对通过后发送的用户关键信息。

在本实施例中，验票的方式支持实名验票模式，即实施人脸、身份证、门票三者一致方可通过闸机进入场馆的方式。

当用户(参观展览的观众，通常认为是已经购票的人)从闸机前通过时，系统提示放置身份证，并保持人脸正对闸机屏幕(含摄像头)。闸机获取用户身份证图像和人脸图像，然后识别身份证中的照片，与人脸图像进行比对。当人证比对通过(身份证照片与人脸图像的相似度达到阈值)后，闸机向前置端提供该用户的关键信息，例如身份证信息等。若人证比对未通过(身份证照片与人脸图像的相似度未达到阈值)，则闸机直接向该用户给出错误提示。

另外，在人证比对阶段还可以检查出该用户是否为公安系统指定的特别名单，并由现场公安盘查。

S204，根据所述用户关键信息和所述本地数据库中的票务数据进行票证比对，判断是否验票通过。

闸机端向前置端提供所述用户关键信息，以请求形式再次发出。在本实施例中，由于采用实名验票模式且闸机端已进行人证比对，因此前置端主要是根据所述用户关键信息中的身份证信息和所述本地数据库中的票务数据进行票证比对，当票证一致时判断验票通过。

具体而言，前置端根据所述用户关键信息在本地数据库中依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道等条件。在进行上述各个条件的校验过程中，只要存在一条校验不通过，则判断为验票未通过。若所有条件均满足，则判断为验票通过。

S206，通知闸机端验票结果，并将所述用户的验票结果记录在所述本地数据库中。

当验票未通过时，前置端返回错误提示至闸机端，告知用户。当验票通过时，前置端通知闸机端验票通过，用户可以顺利通过该闸机。并且，前置端将该用户的验票结果记录在本地数据库中(也可以只在验票通过时记录该用户的验票结果，验票未通过的不记录)。

并且，本实施例还支持现场工作人员按照现场的实际情况实时增加或约束用户，并根据现场的人群流动情况，实时调整单个闸机的验票票种、时间等状态，达到提高验票效率的目标。前置端也可向现场工作人员显示本场次的实时验票情况(例如每个用户的验票结果)等主要信息，以供现场工作人员实时查看。

另外，本实施例也支持现场工作人员依据现场情况在前置端插入临时票务数据，达到线下操作数据同时回流至线上的目的。现场工作人员在闸机验票的同时，也可以通过手持的PDA验票应用客户端对用户进行验票，PDA验票应用客户端也将用户关键信息发送至前置端进行票证比对。

S208，将所述验票结果定时同步至所述服务端。

除了将所述验票结果实时通知至所述闸机端外，所述前置端还会定时将所述验票结果同步至所述服务端。

本实施例提出的闸机验票方法，可以通过现场前置端支持灵活的现场中心管理模型，同时满足安全合规、网络条件、快速检票的综合情况，增加竞争力，满足该场景下多种实际需要。

实施例四

如图5所示，为本申请第四实施例提出的一种闸机验票方法的流程图。在第四实施例中，所述闸机验票方法在上述第三实施例的基础上，还包括步骤S308-310。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S300，从服务端下载票务数据后存储至本地数据库备用。

以展览场馆的购票和检票为例，通常用户在终端(可以为移动端，例如手机；或者固定终端，例如展览场馆的购票机)查询展会类信息，并在选择好展会场次之后下单、填写必要信息(包括实名证件、日期、场次、票种等)，支付完成后该订单正式生成。每个订单具有唯一编号，会存储在服务端中，服务端根据所述订单可以获取对应的票务数据。所述票务数据可以包括订票标识、场次ID、价格、状态、加密凭证、票种名称、展览项目、检票时间、用户ID(例如用户身份证号)、订单ID、后端更新时间等。

对于每一场独立的展览，前置端在开始检票之前从服务端中将本次展览的票务数据全部下载到本地数据库中进行存储备用。所述票务数据以单场项目计算，连续多天的项目为同一个。

S302，接收闸机端在对用户进行人证比对通过后发送的用户关键信息。

在本实施例中，验票的方式支持实名验票模式，即实施人脸、身份证、门票三者一致方可通过闸机进入场馆的方式。

当用户(参观展览的观众，通常认为是已经购票的人)从闸机前通过时，系统提示放置身份证，并保持人脸正对闸机屏幕(含摄像头)。闸机获取用户身份证图像和人脸图像，然后识别身份证中的照片，与人脸图像进行比对。当人证比对通过(身份证照片与人脸图像的相似度达到阈值)后，闸机向前置端提供该用户的关键信息，例如身份证信息等。若人证比对未通过(身份证照片与人脸图像的相似度未达到阈值)，则闸机直接向该用户给出错误提示。

S304，根据所述用户关键信息和所述本地数据库中的票务数据进行票证比对，判断是否验票通过。

闸机端向前置端提供所述用户关键信息，以请求形式再次发出。在本实施例中，由于采用实名验票模式且闸机端已进行人证比对，因此前置端主要是根据所述用户关键信息中的身份证信息和所述本地数据库中的票务数据进行票证比对，当票证一致时判断验票通过。

具体而言，前置端根据所述用户关键信息在本地数据库中依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道等条件。在进行上述各个条件的校验过程中，只要存在一条校验不通过，则判断为验票未通过。若所有条件均满足，则判断为验票通过。

S306，通知闸机端验票结果，并将所述用户的验票结果记录在所述本地数据库中。

当验票未通过时，前置端返回错误提示至闸机端，告知用户。当验票通过时，前置端通知闸机端验票通过，用户可以顺利通过该闸机。并且，前置端将该用户的验票结果记录在本地数据库中(也可以只在验票通过时记录该用户的验票结果，验票未通过的不记录)。

S308，将所述验票结果定时同步至所述服务端。

除了将所述验票结果实时通知至所述闸机端外，所述前置端还会定时将所述验票结果同步至所述服务端。

S310，当互联网正常时，定时向服务端请求同步数据，以不断更新本地和云端数据。

在本实施例中，云端服务数据同步是在互联网环境下，由前置端发起网络请求，并同步数据。前置端保持定时向服务端请求同步数据的机制。

在有互联网的情况下，前置端在与服务端的数据同步过程中，会不断更新本地数据(存储到本地数据库中)，以满足各类现场临时票务需求。数据同步的过程为:前置端将上次同步完成时间与本次同步时间之间的验票结果数据筛选出来，批量向服务端发起同步请求。服务端接收到该部分数据后，与服务端本地数据做合并处理。此时，如果数据来源于前置端校验且和服务端数据状态冲突，则依然保存到服务端。此部分数据实际数量较少，且目标是用于后续优化使用，不影响现场检票过程。

同样，服务端也会将该时间段内(上次同步完成时间与本次同步时间之间)变更的票务数据批量下发到前置端，供前置端检票时使用。前置端会完全接收服务端下发的变更部分数据，保存至本地数据库中，之后在前置端进行的检票过程中会按照前述比对过程操作。在前置端是依照队列对所述本地数据库进行操作，因此不会出现数据混乱情况。

S312，当互联网出现故障时，通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

若前置端与服务端之间的互联网出现故障，则前置端继续尝试向服务端请求，在网络请求失败时也不做中断现场的验票操作。由于现场验票操作主要是依靠前置端和闸机端之间的局域网模式，因此不受互联网故障的影响。

在互联网故障期间，前置端会将所有验票数据(例如每个用户的验票结果)保存在本地数据库中。当所述互联网恢复正常后，前置端再将所述本地数据库在故障期间保存的所有数据批量同步至所述服务端。

另外，在每个展览项目结束之后，前置端的数据可全部通过互联网回传至服务端(此时可以不是展览现场的互联网络)。所有数据可由票务相关的产品、技术人员进行数据分析使用。

本实施例提出的闸机验票方法，可以支持有限条件(不稳定)网络环境下的实名验票核验方式，不仅支持互联网正常情况下的云数据同步，也支持现场离线状态下的数据在互联网恢复时统一回传至服务端。

实施例五

如图6所示，为本申请第五实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图6仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述前置端4。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如闸机验票系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述闸机验票系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例六

如图7所示，为本申请第六实施例提出一种闸机验票系统60的模块示意图。所述闸机验票系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述闸机验票系统60包括：

下载模块600，用于从服务端下载票务数据后存储至本地数据库备用。

以展览场馆的购票和检票为例，通常用户在终端(可以为移动端，例如手机；或者固定终端，例如展览场馆的购票机)查询展会类信息，并在选择好展会场次之后下单、填写必要信息(包括实名证件、日期、场次、票种等)，支付完成后该订单正式生成。每个订单具有唯一编号，会存储在服务端中，服务端根据所述订单可以获取对应的票务数据。所述票务数据可以包括订票标识、场次ID、价格、状态、加密凭证、票种名称、展览项目、检票时间、用户ID(例如用户身份证号)、订单ID、后端更新时间等。

对于每一场独立的展览，获取模块600在开始检票之前从服务端中将本次展览的票务数据全部下载到本地数据库中进行存储备用。所述票务数据以单场项目计算，连续多天的项目为同一个。

接收模块602，用于接收闸机端在对用户进行人证比对通过后发送的用户关键信息。

在本实施例中，验票的方式支持实名验票模式，即实施人脸、身份证、门票三者一致方可通过闸机进入场馆的方式。

当用户(参观展览的观众，通常认为是已经购票的人)从闸机前通过时，系统提示放置身份证，并保持人脸正对闸机屏幕(含摄像头)。闸机获取用户身份证图像和人脸图像，然后识别身份证中的照片，与人脸图像进行比对。当人证比对通过(身份证照片与人脸图像的相似度达到阈值)后，闸机向前置端提供该用户的关键信息，例如身份证信息等。若人证比对未通过(身份证照片与人脸图像的相似度未达到阈值)，则闸机直接向该用户给出错误提示。

判断模块604，用于根据所述用户关键信息和所述本地数据库中的票务数据进行票证比对，判断是否验票通过。

闸机端向前置端提供所述用户关键信息，以请求形式再次发出。在本实施例中，由于采用实名验票模式且闸机端已进行人证比对，因此判断模块604主要是根据所述用户关键信息中的身份证信息和所述本地数据库中的票务数据进行票证比对，当票证一致时判断验票通过。

具体而言，判断模块604根据所述用户关键信息在本地数据库中依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道等条件。在进行上述各个条件的校验过程中，只要存在一条校验不通过，则判断为验票未通过。若所有条件均满足，则判断为验票通过。

通知模块606，用于通知闸机端验票结果，并将所述用户的验票结果记录在所述本地数据库中。

当验票未通过时，通知模块606返回错误提示至闸机端，告知用户。当验票通过时，通知模块606通知闸机端验票通过，用户可以顺利通过该闸机。并且，通知模块606将该用户的验票结果记录在本地数据库中(也可以只在验票通过时记录该用户的验票结果，验票未通过的不记录)。

同步模块608，用于将所述验票结果定时同步至所述服务端。

除了将所述验票结果实时通知至所述闸机端外，所述前置端还会定时将所述验票结果同步至所述服务端。所述同步模块608，还用于当互联网正常时，定时向服务端请求同步数据，以不断更新本地和云端数据。

在本实施例中，云端服务数据同步是在互联网环境下，由前置端发起网络请求，并同步数据。同步模块608保持定时向服务端请求同步数据的机制。

在有互联网的情况下，同步模块608在与服务端的数据同步过程中，会不断更新本地数据(存储到本地数据库中)，以满足各类现场临时票务需求。数据同步的过程为:同步模块608将上次同步完成时间与本次同步时间之间的数据筛选出来，批量向服务端发起同步请求。服务端接收到该部分数据后，与服务端本地数据做合并处理。此时，如果数据来源于前置端校验且和服务端数据状态冲突，则依然保存到服务端。此部分数据实际数量较少，且目标是用于后续优化使用，不影响现场检票过程。

同样，服务端也会将该时间段内(上次同步完成时间与本次同步时间之间)变更的数据批量下发到前置端，供前置端检票时使用。同步模块608会完全接收服务端下发的变更部分数据，保存至本地数据库中，之后在前置端进行的检票过程中会按照前述比对过程操作。在前置端是依照队列对所述本地数据库进行操作，因此不会出现数据混乱情况。

所述同步模块608，还用于当互联网出现故障时，通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

若前置端与服务端之间的互联网出现故障，则同步模块608继续尝试向服务端请求，在网络请求失败时也不做中断现场的验票操作。由于现场验票操作主要是依靠前置端和闸机端之间的局域网模式，因此不受互联网故障的影响。在互联网故障期间，前置端会将所有验票数据(例如每个用户的验票结果)保存在本地数据库中。当所述互联网恢复正常后，同步模块608再将所述本地数据库在故障期间保存的所有数据批量同步至所述服务端。

另外，在每个展览项目结束之后，前置端的数据可全部通过互联网回传至服务端(此时可以不是展览现场的互联网络)。所有数据可由票务相关的产品、技术人员进行数据分析使用。

本实施例提出的闸机验票系统，可以支持灵活的现场中心管理模型，同时满足安全合规、网络条件、快速检票的综合情况，增加竞争力，满足该场景下多种实际需要。并且，还可以支持有限条件(不稳定)网络环境下的实名验票核验方式，不仅支持互联网正常情况下的云数据同步，也支持现场离线状态下的数据在互联网恢复时统一回传至服务端。

实施例七

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有闸机验票程序，所述闸机验票程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的闸机验票方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (13)

1.一种闸机验票方法，其特征在于，所述方法包括：

服务端根据用户在终端的购票订单获取票务数据；

前置端从所述服务端下载所述票务数据后存储至本地数据库备用；

闸机端获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向所述前置端发送所述用户的关键信息；

所述前置端根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；将所述验票结果定时同步至所述服务端；

其中，所述前置端与所述闸机端之间通过局域网通信，所述前置端与所述服务端之间通过互联网通信。

2.根据权利要求1所述的闸机验票方法，其特征在于，所述方法还包括：

当所述前置端与所述服务端之间的互联网正常时，所述前置端定时向所述服务端请求同步数据，以不断更新本地和云端数据。

3.根据权利要求2所述的闸机验票方法，其特征在于，所述方法还包括：

当所述互联网出现故障时，所述前置端通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

4.根据权利要求1至3任一项所述的闸机验票方法，其特征在于，所述票证比对包括依次校验是否具有可用票种、是否重复入场、是否本场次票种、是否正确通道。

5.根据权利要求2或3所述的闸机验票方法，其特征在于，所述定时向服务端请求同步数据，以不断更新本地和云端数据包括：

将上次同步完成时间与本次同步时间之间的部分验票结果数据筛选出来，批量向所述服务端发起同步请求，以使所述服务端在接收到所述部分验票结果数据之后与所述服务端本地的数据合并；

接收所述服务端批量下发的上次同步完成时间与本次同步时间之间发生变更的票务数据，保存至所述本地数据库中。

6.一种验票设备，其特征在于，所述设备包括：

服务端，用于根据用户在终端的购票订单获取票务数据；

前置端，用于从所述服务端下载所述票务数据后存储至本地数据库备用；

闸机端，用于获取用户的身份证图像和人脸图像并进行人证比对，当比对通过后向所述前置端发送所述用户的关键信息；

所述前置端还用于根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；将所述验票结果定时同步至所述服务端；

其中，所述前置端与所述闸机端之间通过局域网通信，所述前置端与所述服务端之间通过互联网通信。

7.一种闸机验票方法，应用于前置端，其特征在于，所述前置端与闸机端之间通过局域网通信，所述前置端与服务端之间通过互联网通信，所述方法包括：

从所述服务端下载票务数据后存储至本地数据库备用，所述票务数据为所述服务端根据用户在终端的购票订单获取得到；

接收所述闸机端在对用户进行人证比对通过后发送的用户关键信息；

根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；

通知所述闸机端验票结果，并将所述验票结果记录在所述本地数据库中；

将所述验票结果定时同步至所述服务端。

8.根据权利要求7所述的闸机验票方法，其特征在于，所述方法还包括：

当与所述服务端之间的互联网正常时，定时向所述服务端请求同步数据，以不断更新本地和云端数据。

9.根据权利要求8所述的闸机验票方法，其特征在于，所述方法还包括：

当所述互联网出现故障时，通过与所述闸机端之间的局域网执行现场验票操作，并在所述互联网恢复正常后将所述本地数据库在故障期间保存的数据批量同步至所述服务端。

10.根据权利要求8或9所述的闸机验票方法，其特征在于，所述定时向所述服务端请求同步数据，以不断更新本地和云端数据包括：

将上次同步完成时间与本次同步时间之间的部分验票结果数据筛选出来，批量向所述服务端发起同步请求，以使所述服务端在接收到所述部分验票结果数据之后与服务端本地的数据合并；

接收服务端批量下发的上次同步完成时间与本次同步时间之间发生变更的票务数据，保存至所述本地数据库中。

11.一种闸机验票系统，应用于前置端，其特征在于，所述前置端与闸机端之间通过局域网通信，所述前置端与服务端之间通过互联网通信，所述系统包括：

下载模块，用于从所述服务端下载票务数据后存储至本地数据库备用，所述票务数据为所述服务端根据用户在终端的购票订单获取得到；

接收模块，用于接收所述闸机端在对用户进行人证比对通过后发送的用户关键信息；

判断模块，用于根据所述用户关键信息和所述本地数据库中的所述票务数据进行票证比对，判断是否验票通过；

通知模块，用于通知闸机端验票结果，并将所述验票结果记录在所述本地数据库中；

同步模块，用于将所述验票结果定时同步至所述服务端。

12.一种电子装置，其特征在于，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的闸机验票程序，所述闸机验票程序被所述处理器执行时实现如权利要求7至10中任一项所述的闸机验票方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有闸机验票程序，所述闸机验票程序被处理器执行时实现如权利要求1至5或7至10中任一项所述的闸机验票方法。

Images